forums.silverfrost.com

[acw]

On v 5.21, yhe following generates a "reference to undefined variable" error at the print when using a checkmate build. A breakpoint set on the print shows i1 as "undefined":

integer*1:: i1
i1 = 0
i1 = ibset(i1, 7)
print *, i1

When running a debug build i1 is still shown as undefined in the debugger, but the program doesn't stop and prints the correct -128.

The problem doesn't seem to occur when setting the top bit on an integer*2 or *3.

[PaulLaidler]

Thank you for the bug report.
We will investigate this as soon as we can.

[PaulLaidler]

inset(i1, 7) gives Z'80' which is 128 and is out of range.

It also happens to be the "undefined" state used by FTN95 for INTEGER*1 variables.

[acw]

Erm, I've alway known Z'80' in a signed 8-bit integer to be -128 - a single signed byte's range being -128 to +127. The ftn95 help under "Arithmetic overflow checking" also has this for INTEGER(KIND=1). I can see how you might argue that ibset is casting from a >8 bit integer in which case it would be out of range (although I'd argue that is not correct since all I want to do is set bit 7 of the variable and I shouldn't need to consider what's going on within ibset) - wouldn't that then generate an overflow ?

I do buy the "undefined" explanation for checkmate build however, and that does explain the checkmate problem, however I don't see that the debugger has a problem with it in my debug builds as I don't have /undef enabled in (I can't use undefined variable checks as my program processes binary data - which is a pity).

[PaulLaidler]

What I should have said was that the assignment i1 = Z'80' where i1 is INTEGER*1, is flagged by the compiler as out of range because the default integer size on the RHS is INTEGER*4. So the RHS is 128 and the assignment is out of range.

I will take another look at it and report back.

[PaulLaidler]

This bug/limitation has be removed for the next release.