integer*1 range problems

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.

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

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.

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).

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

I will take another look at it and report back.

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