Portability problems: compiler flags

2011/1/25 Andreas Raab <[hidden email]>:

>
> On 1/25/2011 11:38 AM, Igor Stasenko wrote:
>>>
>>> Squeak uses highly unportable flag "-mno-fused-madd".
>>> It isn't present in many systems, even those using GCC,
>>> since many systems use older compilers.
>>>
>>> Also, why do you build fdlibm? It is old stuff that works not so well,
>>> we have better libm. Is there a way to use our libm?
>>>
>> I asked  same question few weeks ago.
>> Check mailing list archive for discussion.
>> In short: differrent libm implementations work differently and some
>> have bad support of IEEE standard.
>
> Actually, that's not quite the point. The issue is that Croquet requires
> bit-identical computations including floating point. For FPU computations,
> the use of -mno-fused-madd avoids the use of the fused multiply-add
> operation by compilers which support it which would generate different
> results from compilers not using fused madd.
>
> The usage of fdlibm is similar. As Nicolas has pointed out elsewhere, fdlibm
> is in some cases actually inferior of the platform libms (one might say
> outright broken) but the requirement for the usage in Croquet isn't really
> whether it's "correct" or "good". The requirement is bit-identical results
> across all platforms. The results can be wrong as long as they are
> consistently wrong. But they mustn't be different.
>

Yes, I was disappointed by exp(1), but fdlibm sin(pi+epsilon) is far
far superior to i86 hardwired answer (i86 approximation of pi is well
known to be poor).

Nicolas

> Having said that, for your regular Squeak VM (i.e., not requiring
> bit-identical floating point results) there really isn't a requirement to
> use either -mno-fused-madd or fdlibm.
>
> Cheers,
>  - Andreas
>

 

On 4/10/2011 18:35, Mariano Martinez Peck wrote:

Sorry for arriving late to the thread. I have a simiar problem now trying to compile Cog in a Windows box with MinGW.

The problem is described in another thread: http://forum.world.st/Cannot-generate-VM-in-Windows-with-CMake-and-Git-tp3434566p3434566.html

So...if we remove "-mno-fused-madd"  from windows confs like CogMsWindowsConfig, then Corquet wouldn't behave correctly ?  but if we keep them, it is difficult to compile in some platforms. So...I wonder, I am the only one trying to compile this on Windows?  Who do the Croquet guys do to compile with this flag in Windows?

gcc 3.x accepts -mno-fused-madd fine.

Cheers,
  - Andreas

Thanks

Mariano

On Tue, Jan 25, 2011 at 9:05 PM, Nicolas Cellier <[hidden email]> wrote:

2011/1/25 Andreas Raab <[hidden email]>:

>
> On 1/25/2011 11:38 AM, Igor Stasenko wrote:
>>>
>>> Squeak uses highly unportable flag "-mno-fused-madd".
>>> It isn't present in many systems, even those using GCC,
>>> since many systems use older compilers.
>>>
>>> Also, why do you build fdlibm? It is old stuff that works not so well,
>>> we have better libm. Is there a way to use our libm?
>>>
>> I asked  same question few weeks ago.
>> Check mailing list archive for discussion.
>> In short: differrent libm implementations work differently and some
>> have bad support of IEEE standard.
>
> Actually, that's not quite the point. The issue is that Croquet requires
> bit-identical computations including floating point. For FPU computations,
> the use of -mno-fused-madd avoids the use of the fused multiply-add
> operation by compilers which support it which would generate different
> results from compilers not using fused madd.
>
> The usage of fdlibm is similar. As Nicolas has pointed out elsewhere, fdlibm
> is in some cases actually inferior of the platform libms (one might say
> outright broken) but the requirement for the usage in Croquet isn't really
> whether it's "correct" or "good". The requirement is bit-identical results
> across all platforms. The results can be wrong as long as they are
> consistently wrong. But they mustn't be different.
>

Yes, I was disappointed by exp(1), but fdlibm sin(pi+epsilon) is far
far superior to i86 hardwired answer (i86 approximation of pi is well
known to be poor).

Nicolas

> Having said that, for your regular Squeak VM (i.e., not requiring
> bit-identical floating point results) there really isn't a requirement to
> use either -mno-fused-madd or fdlibm.
>
> Cheers,
>  - Andreas
>

--
Mariano
http://marianopeck.wordpress.com

 

Please read this thread from a month ago.

http://forum.world.st/Failed-to-build-FloatMathPlugin-on-FreeBSD-td3346374.html#a3346695

Cheers,
Henry

On 10.04.2011 21:17, Mariano Martinez Peck wrote:

On Sun, Apr 10, 2011 at 9:08 PM, Andreas Raab <[hidden email]> wrote:

 

On 4/10/2011 18:35, Mariano Martinez Peck wrote:

Sorry for arriving late to the thread. I have a simiar problem now trying to compile Cog in a Windows box with MinGW.

The problem is described in another thread: http://forum.world.st/Cannot-generate-VM-in-Windows-with-CMake-and-Git-tp3434566p3434566.html

So...if we remove "-mno-fused-madd"  from windows confs like CogMsWindowsConfig, then Corquet wouldn't behave correctly ?  but if we keep them, it is difficult to compile in some platforms. So...I wonder, I am the only one trying to compile this on Windows?  Who do the Croquet guys do to compile with this flag in Windows?

gcc 3.x accepts -mno-fused-madd fine.

Weird...I have

$ gcc --version
gcc.exe (GCC) 3.4.5 (mingw-vista special r3)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even fo

and I have the error:

Scanning dependencies of target FloatMathPlugin
[ 13%] Building C object FloatMathPlugin/CMakeFiles/FloatMathPlugin.dir/C_/maria                   no/squeak/vm/cogVM/blessed/src/plugins/FloatMathPlugin/FloatMathPlugin.c.obj
cc1.exe: error: invalid option `no-fused-madd'
make[2]: *** [FloatMathPlugin/CMakeFiles/FloatMathPlugin.dir/C_/mariano/squeak/v                   m/cogVM/blessed/src/plugins/FloatMathPlugin/FloatMathPlugin.c.obj] Error 1
make[1]: *** [FloatMathPlugin/CMakeFiles/FloatMathPlugin.dir/all] Error 2
make: *** [all] Error 2
r MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
 

Cheers

mariano

Cheers,
  - Andreas

Thanks

Mariano

On Tue, Jan 25, 2011 at 9:05 PM, Nicolas Cellier <[hidden email]> wrote:

2011/1/25 Andreas Raab <[hidden email]>:

>
> On 1/25/2011 11:38 AM, Igor Stasenko wrote:
>>>
>>> Squeak uses highly unportable flag "-mno-fused-madd".
>>> It isn't present in many systems, even those using GCC,
>>> since many systems use older compilers.
>>>
>>> Also, why do you build fdlibm? It is old stuff that works not so well,
>>> we have better libm. Is there a way to use our libm?
>>>
>> I asked  same question few weeks ago.
>> Check mailing list archive for discussion.
>> In short: differrent libm implementations work differently and some
>> have bad support of IEEE standard.
>
> Actually, that's not quite the point. The issue is that Croquet requires
> bit-identical computations including floating point. For FPU computations,
> the use of -mno-fused-madd avoids the use of the fused multiply-add
> operation by compilers which support it which would generate different
> results from compilers not using fused madd.
>
> The usage of fdlibm is similar. As Nicolas has pointed out elsewhere, fdlibm
> is in some cases actually inferior of the platform libms (one might say
> outright broken) but the requirement for the usage in Croquet isn't really
> whether it's "correct" or "good". The requirement is bit-identical results
> across all platforms. The results can be wrong as long as they are
> consistently wrong. But they mustn't be different.
>

Yes, I was disappointed by exp(1), but fdlibm sin(pi+epsilon) is far
far superior to i86 hardwired answer (i86 approximation of pi is well
known to be poor).

Nicolas

> Having said that, for your regular Squeak VM (i.e., not requiring
> bit-identical floating point results) there really isn't a requirement to
> use either -mno-fused-madd or fdlibm.
>
> Cheers,
>  - Andreas
>

--
Mariano
http://marianopeck.wordpress.com

--
Mariano
http://marianopeck.wordpress.com