FloatMathPlugin crashes the VM if compiled with gcc optimization

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

FloatMathPlugin crashes the VM if compiled with gcc optimization

David T. Lewis
 
VM builders:

Recent updates in Squeak trunk expose an issue with the FloatMathPlugin.
This plugin should be built with compiler optimization turned off,
otherwise the plugin can crash the VM.

The Mantis report is at http://bugs.squeak.org/view.php?id=7592
and the discussion on squeak-dev is at
http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-December/156132.html

Although this has not been verified on all platforms, the working
assumption should be that optimization must be turned off for
FloatMathPlugin when using gcc.

Dave

Reply | Threaded
Open this post in threaded view
|

Re: FloatMathPlugin crashes the VM if compiled with gcc optimization

Igor Stasenko
 
Yep.


On 26 December 2010 20:23, David T. Lewis <[hidden email]> wrote:

>
> VM builders:
>
> Recent updates in Squeak trunk expose an issue with the FloatMathPlugin.
> This plugin should be built with compiler optimization turned off,
> otherwise the plugin can crash the VM.
>
> The Mantis report is at http://bugs.squeak.org/view.php?id=7592
> and the discussion on squeak-dev is at
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-December/156132.html
>
> Although this has not been verified on all platforms, the working
> assumption should be that optimization must be turned off for
> FloatMathPlugin when using gcc.
>

Yep.. i noticed that when extracting the knowledge from makefiles and
putting it into ST code:

configureFloatMathPlugin: maker
        "extra rules for FloatMathPlugin"

        maker addCrossSources: #(
                'acos.c' 'acosh.c' 'asin.c' 'asinh.c' 'atan.c' 'atan2.c' 'atanh.c'
                'copysign.c' 'cos.c' 'cosh.c' 'exp.c' 'expm1.c' 'finite.c' 'fmod.c'
                'hypot.c' 'isnan.c' 'k_cos.c' 'k_rem_pio2.c' 'k_sin.c' 'k_tan.c' 'ldexp.c'
                'log.c' 'log10.c' 'log1p.c' 'modf.c' 'pow.c' 'rem_pio2.c' 'rint.c'
                'scalb.c' 'scalbn.c' 'sin.c' 'sinh.c' 'sqrt.c' 'tan.c' 'tanh.c' ).

        "On windoze, lib should be built without optimizations?
        On *nix & mac with -DNO_ISNAN "
       
        maker puts:'
if (${WIN32})
        add_definitions(-Werror-implicit-function-declaration -O0)
else(${WIN32})
        add_definitions(-DNO_ISNAN)
endif (${WIN32})'.



Note, that on unix and mac it defines -DNO_ISNAN
while on win32, it compiles with -O0 flag, which turns off all optimizations.

It would be good to know why optimization(s) causing crash, and how we
could fix that in code,
 because i'm not in favor having VM  which stability depends on
compiler peculiarities.


> Dave
>
>



--
Best regards,
Igor Stasenko AKA sig.
Reply | Threaded
Open this post in threaded view
|

Re: FloatMathPlugin crashes the VM if compiled with gcc optimization

Andreas.Raab
 
On 12/26/2010 8:40 PM, Igor Stasenko wrote:
> Note, that on unix and mac it defines -DNO_ISNAN
> while on win32, it compiles with -O0 flag, which turns off all optimizations.
>
> It would be good to know why optimization(s) causing crash, and how we
> could fix that in code,
>   because i'm not in favor having VM  which stability depends on
> compiler peculiarities.

Because fdlibm aliases integer pointers with floating point values.
Compilers generally don't assume that, i.e.,

        double foo = 1.0;
#ifdef BIGENDIAN
        unsigned int *highWord = (unsigned int*)&foo;
#else
        unsigned int *highWord = ((unsigned int*)&foo)++;
#endif
        *highWord |= 0x8000000;

might change the sign of foo and that it would invalidate a prior value
in an fpu register. But fdlibm does this kind of stuff *all the time*.

Cheers,
   - andreas
Reply | Threaded
Open this post in threaded view
|

Re: FloatMathPlugin crashes the VM if compiled with gcc optimization

Igor Stasenko

On 26 December 2010 21:57, Andreas Raab <[hidden email]> wrote:

>
> On 12/26/2010 8:40 PM, Igor Stasenko wrote:
>>
>> Note, that on unix and mac it defines -DNO_ISNAN
>> while on win32, it compiles with -O0 flag, which turns off all
>> optimizations.
>>
>> It would be good to know why optimization(s) causing crash, and how we
>> could fix that in code,
>>  because i'm not in favor having VM  which stability depends on
>> compiler peculiarities.
>
> Because fdlibm aliases integer pointers with floating point values.
> Compilers generally don't assume that, i.e.,
>
>        double foo = 1.0;
> #ifdef BIGENDIAN
>        unsigned int *highWord = (unsigned int*)&foo;
> #else
>        unsigned int *highWord = ((unsigned int*)&foo)++;
> #endif
>        *highWord |= 0x8000000;
>
> might change the sign of foo and that it would invalidate a prior value in
> an fpu register. But fdlibm does this kind of stuff *all the time*.
>

omg..

low level C code which pretending to know how to do it 'right' +
C compiler , who also knowing how to do it 'right' ===>> mess in result :)

> Cheers,
>  - andreas
>



--
Best regards,
Igor Stasenko AKA sig.
Reply | Threaded
Open this post in threaded view
|

Re: FloatMathPlugin crashes the VM if compiled with gcc optimization

Igor Stasenko
 
btw, how old that fdlibm portions there?
maybe updating it will be a simple solution to that issue?

Oh, and please, can you shed some light on the history, why for floating-point
math in Squeak, VM using non-standard math lib, which comes with any C
compiler, but instead,
a  portions of separate 3rd party library?



--
Best regards,
Igor Stasenko AKA sig.
Reply | Threaded
Open this post in threaded view
|

Re: FloatMathPlugin crashes the VM if compiled with gcc optimization

Andreas.Raab
 
On 12/26/2010 10:24 PM, Igor Stasenko wrote:
> btw, how old that fdlibm portions there?
> maybe updating it will be a simple solution to that issue?

I've never found any newer release than here:

http://www.netlib.org/fdlibm/

> Oh, and please, can you shed some light on the history, why for floating-point
> math in Squeak, VM using non-standard math lib, which comes with any C
> compiler, but instead, a  portions of separate 3rd party library?

You would be surprised to find out just how much the results of the C
compiler libraries differ when it comes to edge cases. I've run the
experiment in the past:

Using Python 2.4:
 >>> import math
 >>> math.cos(1.0e32)

WinXP:    -0.39929634612021897
LinuxX86: -0.49093671143542561

In short, the results *dramatically* vary depending on processor family,
processor version, C compiler libraries, and so on. None of the
libraries produce cross-platform bit-identical results. fdlibm does.

Cheers,
   - Andreas
Reply | Threaded
Open this post in threaded view
|

Re: FloatMathPlugin crashes the VM if compiled with gcc optimization

Andreas.Raab
In reply to this post by Igor Stasenko
 
On 12/26/2010 10:19 PM, Igor Stasenko wrote:
> low level C code which pretending to know how to do it 'right' +
> C compiler , who also knowing how to do it 'right' ===>>  mess in result :)

Well, I'm sorry but the C code does bit manipulation according to IEEE
754 so it's hard to blame that code for overly aggressive gcc
optimizations. FWIW, the FloatMathPlugin must also be compiled with
-mno-fused-madd as this would produce another source of differences
depending on whether a compiler chooses to use fmadd or not.

Cheers,
   - Andreas
Reply | Threaded
Open this post in threaded view
|

Re: FloatMathPlugin crashes the VM if compiled with gcc optimization

Igor Stasenko
In reply to this post by Andreas.Raab

On 26 December 2010 22:52, Andreas Raab <[hidden email]> wrote:

>
> On 12/26/2010 10:24 PM, Igor Stasenko wrote:
>>
>> btw, how old that fdlibm portions there?
>> maybe updating it will be a simple solution to that issue?
>
> I've never found any newer release than here:
>
> http://www.netlib.org/fdlibm/
>

oh , yeah..
http://www.netlib.org/fdlibm/readme
actually says about that:

NOT FIXED YET

    3. Compiler failure on non-standard code
        Statements like
                    *(1+(int*)&t1) = 0;
        are not standard C and cause some optimizing compilers (e.g. GCC)
        to generate bad code under optimization.    These cases
        are to be addressed in the next release.

>> Oh, and please, can you shed some light on the history, why for
>> floating-point
>> math in Squeak, VM using non-standard math lib, which comes with any C
>> compiler, but instead, a  portions of separate 3rd party library?
>
> You would be surprised to find out just how much the results of the C
> compiler libraries differ when it comes to edge cases. I've run the
> experiment in the past:
>
> Using Python 2.4:
>>>> import math
>>>> math.cos(1.0e32)
>
> WinXP:    -0.39929634612021897
> LinuxX86: -0.49093671143542561
>
> In short, the results *dramatically* vary depending on processor family,
> processor version, C compiler libraries, and so on. None of the libraries
> produce cross-platform bit-identical results. fdlibm does.
>

i see. And it looks like this library used by java vm. It is very
strange that Oracle having no interest in maintaining it anymore:

http://mailman.oakapple.net/pipermail/numeric-interest/2010-September/002054.html



> Cheers,
>  - Andreas
>



--
Best regards,
Igor Stasenko AKA sig.
Reply | Threaded
Open this post in threaded view
|

Re: FloatMathPlugin crashes the VM if compiled with gcc optimization

Igor Stasenko
In reply to this post by Andreas.Raab

On 26 December 2010 23:32, Andreas Raab <[hidden email]> wrote:

>
> On 12/26/2010 10:19 PM, Igor Stasenko wrote:
>>
>> low level C code which pretending to know how to do it 'right' +
>> C compiler , who also knowing how to do it 'right' ===>>  mess in result
>> :)
>
> Well, I'm sorry but the C code does bit manipulation according to IEEE 754
> so it's hard to blame that code for overly aggressive gcc optimizations.
> FWIW, the FloatMathPlugin must also be compiled with -mno-fused-madd as this
> would produce another source of differences depending on whether a compiler
> chooses to use fmadd or not.
>
ok. added :)

Btw, i found another library:
http://www.jhauser.us/arithmetic/SoftFloat.html

looks like this one don't have problems with gcc -O2,
because at "SoftFloat speed" it says that it is compiled with this option.


> Cheers,
>  - Andreas
>



--
Best regards,
Igor Stasenko AKA sig.
Reply | Threaded
Open this post in threaded view
|

Re: FloatMathPlugin crashes the VM if compiled with gcc optimization

Igor Stasenko

On 27 December 2010 00:17, Igor Stasenko <[hidden email]> wrote:

> On 26 December 2010 23:32, Andreas Raab <[hidden email]> wrote:
>>
>> On 12/26/2010 10:19 PM, Igor Stasenko wrote:
>>>
>>> low level C code which pretending to know how to do it 'right' +
>>> C compiler , who also knowing how to do it 'right' ===>>  mess in result
>>> :)
>>
>> Well, I'm sorry but the C code does bit manipulation according to IEEE 754
>> so it's hard to blame that code for overly aggressive gcc optimizations.
>> FWIW, the FloatMathPlugin must also be compiled with -mno-fused-madd as this
>> would produce another source of differences depending on whether a compiler
>> chooses to use fmadd or not.
>>
> ok. added :)
>
> Btw, i found another library:
> http://www.jhauser.us/arithmetic/SoftFloat.html
>
> looks like this one don't have problems with gcc -O2,
> because at "SoftFloat speed" it says that it is compiled with this option.
>
oh , forget it.. it  only contains basic operations like add , mul, pow etc
but not sin / cos / tan

>
>> Cheers,
>>  - Andreas
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>



--
Best regards,
Igor Stasenko AKA sig.
Reply | Threaded
Open this post in threaded view
|

Re: FloatMathPlugin crashes the VM if compiled with gcc optimization

Nicolas Cellier
In reply to this post by Andreas.Raab

2010/12/26 Andreas Raab <[hidden email]>:

>
> On 12/26/2010 10:24 PM, Igor Stasenko wrote:
>>
>> btw, how old that fdlibm portions there?
>> maybe updating it will be a simple solution to that issue?
>
> I've never found any newer release than here:
>
> http://www.netlib.org/fdlibm/
>
>> Oh, and please, can you shed some light on the history, why for
>> floating-point
>> math in Squeak, VM using non-standard math lib, which comes with any C
>> compiler, but instead, a  portions of separate 3rd party library?
>
> You would be surprised to find out just how much the results of the C
> compiler libraries differ when it comes to edge cases. I've run the
> experiment in the past:
>
> Using Python 2.4:
>>>> import math
>>>> math.cos(1.0e32)
>
> WinXP:    -0.39929634612021897
> LinuxX86: -0.49093671143542561
>

Yes, I like this one.

Considering that 1.0e32 is exactly  100000000000000005366162204393472,
my own approximation would be:
(1.0e32 asArbitraryPrecisionFloatNumBits: 53) cos asFloat storeString
-> '0.8108648261576407'

which is in agreement with fdlibm because enough decimals of pi are
considered for computing the modulo
1.0e32 cos storeString
-> '0.8108648261576407'

But considering that 1.0e32 ulp -> 1.8014398509482e16, the least
rounding error leads to an uncertainty interval [-1,1] on this result.
So this kind of computation has no meaning at all, bit identical or
not, and should better be forbidden.
The IEEE 754 conceivers could as well have stated that the right
answer was NaN (meaning undefined here).

Nicolas

> In short, the results *dramatically* vary depending on processor family,
> processor version, C compiler libraries, and so on. None of the libraries
> produce cross-platform bit-identical results. fdlibm does.
>
> Cheers,
>  - Andreas
>
Reply | Threaded
Open this post in threaded view
|

Re: FloatMathPlugin crashes the VM if compiled with gcc optimization

stephane ducasse-2
In reply to this post by Igor Stasenko

>
>>> Oh, and please, can you shed some light on the history, why for
>>> floating-point
>>> math in Squeak, VM using non-standard math lib, which comes with any C
>>> compiler, but instead, a  portions of separate 3rd party library?
>>
>> You would be surprised to find out just how much the results of the C
>> compiler libraries differ when it comes to edge cases. I've run the
>> experiment in the past:
>>
>> Using Python 2.4:
>>>>> import math
>>>>> math.cos(1.0e32)
>>
>> WinXP:    -0.39929634612021897
>> LinuxX86: -0.49093671143542561


Thanks for the info.
Scary. It is amazing how we can forget this ugly things in the comfort of our images.
I remember a talk of dave thomas (VA) and he said that they burned tons of smart people on such issues.

>>
>> In short, the results *dramatically* vary depending on processor family,
>> processor version, C compiler libraries, and so on. None of the libraries
>> produce cross-platform bit-identical results. fdlibm does.
>>
>
> i see. And it looks like this library used by java vm. It is very
> strange that Oracle having no interest in maintaining it anymore:
>
> http://mailman.oakapple.net/pipermail/numeric-interest/2010-September/002054.html

Strange. May be not for free.

Stef