Bug !!!

[Antoni]

Code: Select all

Dim m As UInteger
m=&hffffffff
Print m
m=4.2e9
Print m

prints

Code: Select all

4294967295     <----OK!
2147483648     <----Very wrong!!

FB 0.17 for Win32 official version

[sir_mud]

You defined m as a uinteger so weird things will happen when you asign it a floating point value.

[Antoni]

Conversion between built-in types should give correct results, if there is no overflow.

[anonymous1337]

It gives me an implicit conversion warning. ^^;; I'm not sure if that code should work or not, but you seem to be a little more expertized in this region.

[sir_mud]

I changed it to m = cuint(4.2e9) and it still gives the same answer but the compiler warning is removed. Looks like overflow to me.

[D.J.Peters]

it's right from my point of view.
you can't convert 32 bits in 31 bits

Code: Select all

? 2^32
? 2^31 ' minus one bit for the sign
dim m as uinteger = &HFFFFFFFF
dim f as single
asm fild dword ptr [m]
asm fstp dword ptr [f]
? m,f
f=4.2e9
asm fld dword ptr [f]
asm fistd dword ptr [m]
? m,f
sleep

[ikkejw]

You defined m as a uinteger so weird things will happen when you asign it a floating point value.

4.2e9 = 4 200 000 000 != floating point.

[Zippy]

4.2e9 is not floating point.. And it is within the limits of a uint. The implicit conversion is to a signed integer.

There's a discussion around here somewhere about the inability to append type suffixes.

m=4.2e9u

doesn't work. And if you can't spec the rhs type on a bare assignment then it will default to.. a signed integer. Sorta:

This is particular behavior is new in 17b. The sci-notation assigment worked as expected in both 15 and 16b.

[D.J.Peters]

4.2e9 is not floating point.

an exponent asignment is no floating point ?!?

[DrV]

4.2e9 is indeed floating point. The only valid forms for integer literals are one or more decimal digits, &H followed by one or more hexadecimal digits, or &O followed by one or more octal digits. If a decimal point or exponentation (e) occurs, the literal is definitely not an integer literal.

EDIT: Forgot binary (&b), but anyway: http://www.freebasic.net/wiki/wikka.php ... PgLiterals

[D.J.Peters]

hello Drv
if you take a look on my posted code i made an error

asm fistd dword Ptr [m]

it must be fistp (integer store and pop) but freebasic or as accept fistd (integer store and dop) :-)
is it legal code?

Joshy

[Zippy]

My bad. Joshy is always correct here (he's not selecting my women or my beer so that makes him correct IN ALL THINGS).

The number represented by 4.2e9 can be construed as a unint (too large for int). It is assigned correctly (as uint, in the OP example) in fb 15 and 16b.

So.. Is the behavior change intended, is it correct, or what? Will the integer size suffixes apply to sci-notation or not?

[coderJeff]

I think there something wrong there, but I can't quite put my finger on it.

Try this:

Code: Select all

dim m as uinteger, d as double
d = 4.2e9
print d
m = d '' << correctly assigns 420000000 to m
print m

I tried out some backup copies I had of the compiler, and I think the bug was introduced in october/november of 2006. In earlier versions, the DOUBLE literal would be emitted to ASM with a .double directive. But in later versions (like 0.17 final) it is emitted as an immediate value. I also think the bug shows up only after the compiler has been used to compile itself.

[coderJeff]

it must be fistp (integer store and pop) but freebasic or as accept fistd (integer store and dop) :-)
is it legal code?

Apparently GAS allows suffixes on the opcode mnemonic even in INTEL syntax mode. e.g. incb [eax] / incw [eax] / incd [eax] are all valid. But I could not find any GNU docs that actually say 'd' is a supported suffix.


If I go back and recompile current sources using 0.16 + 0.17-july-2006, the problem shown by Antoni goes away. If I compile the compiler again, it comes back.

Now, one thing I noticed that does behave the same since at least 0.15 is the result of this snippet of code:

Code: Select all

print cuint( 4200000000# )

const d as double = 4200000000#
print cuint( d )

dim e as double
e = 4200000000#
print cuint( e )

Only the last print will display the expected conversion. So it would seem that the problem is in how the compiler is handling compile-time conversions. I will add the problem to the TODO list since I think the problem is more than a minor regression. v1c made some significant changes to the compiler around the time I think this problem was started. I dunno, at the time, the intent might have been to go one step back so that some time later can go two steps forward.

[Zippy]

Code: Select all

dim m as uinteger
asm AAAAAAAAAAAAAAAAAAAAAA:
m=4.2e9
asm BBBBBBBBBBBBBBBBBBBBBB:
print m
sleep

0.15b
AAAAAAAAAAAAAAAAAAAAAA:
fld qword ptr [Lt_0003]
sub esp, 8
fistp qword ptr [esp]
pop dword ptr [_M]
add esp, 4
BBBBBBBBBBBBBBBBBBBBBB:

0.16b
AAAAAAAAAAAAAAAAAAAAAA:
fld qword ptr [_Lt_0003]
sub esp, 8
fistp qword ptr [esp]
pop dword ptr [ebp-8]
add esp, 4
BBBBBBBBBBBBBBBBBBBBBB:

0.18b
AAAAAAAAAAAAAAAAAAAAAA:
mov dword ptr [ebp-8], -2147483648
BBBBBBBBBBBBBBBBBBBBBB: