Why is there a Known Compiler Bug from 2012 still in?

General FreeBASIC programming questions.
Manpcnin
Posts: 30
Joined: Feb 25, 2007 1:43
Location: N.Z.

Re: Why is there a Known Compiler Bug from 2012 still in?

Postby Manpcnin » Jan 21, 2021 1:13

D.J.Peters wrote:@Manpcnin
do you use double or float (single) ?
do you run 32-bit exe on 64-bit windows ?
are the 3D data created on the fly or loaded from file ?
can you upload the code ?

Joshy


Single. (for the relevant code.) There are some parts of the code that use double precision, but that shouldn't affect anything, and I pay attention to my bit width.
32 bit executable, on 64bit windows. But compiling to 64bit has the same behavior.
I've tracked down the problematic code, reduced it, and posted it above ^. Seems to be a weird interaction with using singles as array indices.
paul doe
Posts: 1367
Joined: Jul 25, 2017 17:22
Location: Argentina

Re: Why is there a Known Compiler Bug from 2012 still in?

Postby paul doe » Jan 21, 2021 1:49

Manpcnin wrote:...
I've tracked down the problematic code, reduced it, and posted it above ^. Seems to be a weird interaction with using singles as array indices.

Mmm, that seems like a pretty unsafe bet to me:

Code: Select all

dim as single index = 0.8f

dim as integer values( ... ) = { 1, 2 }

? values( index )

sleep()

One would expect the index to be truncated (floor), but as the above code shows, it's rounded to the nearest integer (ceil). NAN or INF pose a similar problem...
Manpcnin
Posts: 30
Joined: Feb 25, 2007 1:43
Location: N.Z.

Re: Why is there a Known Compiler Bug from 2012 still in?

Postby Manpcnin » Jan 21, 2021 2:13

I'm aware of FB's rounding policy. Rounding doesn't account for the problem.
coderJeff
Site Admin
Posts: 3410
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Why is there a Known Compiler Bug from 2012 still in?

Postby coderJeff » Jan 23, 2021 22:18

Manpcnin wrote:... this code fails and crashes under "-gen gcc -O 1" (and -O 2 / -O 3)


I found a bug that is related to float to integer conversions in the gcc backend. For float/integer conversions fbc will generate an inline C function something like the following:

Code: Select all

static inline int32 fb_F2I( float value )
{
   volatile int32 result;
   __asm__(
      "fld %1;"
      "fistp %0;"
      :"=m" (result)
      :"m" (value)
   );
   return result;
}


The only way I could get a CRASH was to mix intel and att asm syntax. If you compile the BAS to C (intel syntax) and then use the resulting C file with gcc expecting att syntax, it will compile because the 'fistp' instruction is valid but wrong, should be 'fistpl'. That's not a bug, just something to be aware of if compiling the generated C directly and there was in fact a crash - maybe due to accessing memory outside of the array bounds. Something could check for by compiling with -exx in fbc.

I was able to reproduce FAILUREs readily, where all results of the example program are zero on 32-bit -gen gcc -O 1/2/3. Here's where the bug is: the generated __asm__(*) block doesn't give any indication that x87 stack gets clobbered. And because the gcc optimizer uses st(7) for doing some fxch's on either side of fb_F2I() usage it doesn't know that st(7) gets clobbered. This could also explain extra NAN's in the resulting calculations.

Rounding specifics aside if there are any, this is easy to patch, basically adding a ' :"st" ' line at the end of the __asm__ block to indicate that x87 stack gets clobbered and gcc will optimize differently.
Manpcnin
Posts: 30
Joined: Feb 25, 2007 1:43
Location: N.Z.

Re: Why is there a Known Compiler Bug from 2012 still in?

Postby Manpcnin » Jan 30, 2021 21:05

WOOT! Sound like you found the problem! Nice work!

Return to “General”

Who is online

Users browsing this forum: No registered users and 17 guests