[???] FBC 1.01.0 misevaluation (addition+wrap+compare)

[DOS386]

Code: Select all

#define incv(Q) Q=Q+1
type UINT8 as UBYTE
DIM KK8 AS UINT8
KK8=251 : ? "!!! BUG (addition+wrap+compare) !!!"
DO
  ? STR$(KK8) + " " ;
  IF ((KK8+1)>128) THEN '' Broken in FBC 1.01.0 !!!
    ? "Truue" ;
  ELSE
    ? "False" ;
  ENDIF
  ? " " ;
  IF (CAST(UINT8,(KK8+1))>128) THEN '' This evaluates OK !!!
    ? "Truue" ;
  ELSE
    ? "False" ;
  ENDIF
  ? : incv(KK8)
  IF (KK8=4) THEN EXIT DO '' Enough !!!
LOOP

seems that the compiler "optimizes" my ((KK8+1)>128) into (KK8>127) ... NOT the idea behind my code :-(

http://www.freebasic.net/wiki/wikka.php ... PgLiterals
http://www.freebasic.net/wiki/wikka.php ... blVarTypes

[counting_pine]

The compiler doesn't optimise things like that - it doesn't try to rebalance comparisons.
I would have expected any operands to have been cast up to Integer. Especially 'KK8+1'.
I can't test at the moment. My guess is either that both sides are treated as signed bytes, or that 128 is being treated as -128 somehow.

What architecture and compiler parameters are you using?

[DOS386]

compiler doesn't optimise things like that - it doesn't try to rebalance comparisons.

Nevertheless the result is wrong. Can anyone reproduce it ?

> I would have expected any operands to have been cast up to Integer

But this is AFAIK NOT supposed to happen.

> What architecture and compiler parameters are you using?

Very default simple compilation to target DOS or Win32.

[dkl]

I think the result is ok - the comparisons and math operations are indeed done at Integer precision, not at UByte precision. That's also why the cast to UByte is needed to truncate the value to the range of a UByte, if that is wanted.

[counting_pine]

I see - yes, the result is as expected.
Most operations will have a return type at least as big as the operands passed to it. I don't think FB makes any guarantees to limit the size of the return type.
Besides, the '1' in 'KK8+1' is an Integer. Perhaps upcasting on UByte+UByte isn't desirable, but surely it is on UByte+Integer.

[DOS386]

I see - yes, the result is as expected. Most operations will have a return type at least as big as the operands passed to it.

All operands in my code are UINT8, so I expected 8-bit processing.

Besides, the '1' in 'KK8+1' is an Integer

Then the documentation http://www.freebasic.net/wiki/wikka.php ... PgLiterals is bad:

> Integer size suffixes
> If an integer literal suffix is not given, the number field size required to hold the
> literal is automatically calculated. Specifying a size suffix guarantees that the
> compiler will consider a number as a specific integer size.

I was under the assumption that "1" is UINT8 and "1UL" is UINT32. But if "1" is already UINT32, then the "UL" suffix seems to be pretty pointless. Is the precision and wrapping documented somewhere ? I can't find anything .... http://www.freebasic.net/wiki/wikka.php ... KeyPgOpAdd ...