Hello!
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?
No "-mno-fused-madd" in our compiler.
--- unix/plugins/FloatMathPlugin/config.cmake.orig 2011-01-25 04:56:17.000000000 +0300 +++ unix/plugins/FloatMathPlugin/config.cmake 2011-01-25 05:15:59.000000000 +0300 @@ -10,7 +10,7 @@ # GCC optimizations break fdlibm so disable them for now.
IF (CMAKE_COMPILER_IS_GNUCC) - SET (LIBM_CFLAGS "${CMAKE_C_FLAGS} -O0 -mno-fused-madd") + SET (LIBM_CFLAGS "${CMAKE_C_FLAGS}") ELSE () SET (LIBM_CFLAGS "${CMAKE_C_FLAGS}") ENDIF ()
On 25 January 2011 03:26, Aleksej Saushev asau@inbox.ru wrote:
Hello!
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.
No "-mno-fused-madd" in our compiler.
--- unix/plugins/FloatMathPlugin/config.cmake.orig 2011-01-25 04:56:17.000000000 +0300 +++ unix/plugins/FloatMathPlugin/config.cmake 2011-01-25 05:15:59.000000000 +0300 @@ -10,7 +10,7 @@ # GCC optimizations break fdlibm so disable them for now.
IF (CMAKE_COMPILER_IS_GNUCC)
- SET (LIBM_CFLAGS "${CMAKE_C_FLAGS} -O0 -mno-fused-madd")
- SET (LIBM_CFLAGS "${CMAKE_C_FLAGS}")
ELSE () SET (LIBM_CFLAGS "${CMAKE_C_FLAGS}") ENDIF ()
-- HE CE3OH...
Igor Stasenko siguctua@gmail.com writes:
On 25 January 2011 03:26, Aleksej Saushev asau@inbox.ru wrote:
Hello!
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.
Then it's better to detect those "bad" implementations and not to build bad replacement for good ones.
On Tue, 25 Jan 2011, Aleksej Saushev wrote:
Igor Stasenko siguctua@gmail.com writes:
On 25 January 2011 03:26, Aleksej Saushev asau@inbox.ru wrote:
Hello!
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.
Then it's better to detect those "bad" implementations and not to build bad replacement for good ones.
See Andreas' answer. If libm can be ported to all platforms and it gives bit identical results on all platforms, then it's fine, otherwise it's not. The same applies to any possible replacement library.
Levente
-- HE CE3OH...
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.
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 Tue, Jan 25, 2011 at 12:05:32PM +0100, Andreas Raab wrote:
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.
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.
In terms of requirements, is it true that bit-identical behavior for FloatMathPlugin is a requirement if and only if CroquetPlugin is present at runtime?
Dave
On 25 January 2011 14:30, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Jan 25, 2011 at 12:05:32PM +0100, Andreas Raab wrote:
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.
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.
In terms of requirements, is it true that bit-identical behavior for FloatMathPlugin is a requirement if and only if CroquetPlugin is present at runtime?
well, i think it is good to have for everything , not just for Croquet
Dave
Igor Stasenko siguctua@gmail.com writes:
On 25 January 2011 14:30, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Jan 25, 2011 at 12:05:32PM +0100, Andreas Raab wrote:
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.
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.
In terms of requirements, is it true that bit-identical behavior for FloatMathPlugin is a requirement if and only if CroquetPlugin is present at runtime?
well, i think it is good to have for everything , not just for Croquet
I don't like this attitude.
Is it possible to provide a switch to use better libm than fdlibm?
2011/1/25 Andreas Raab andreas.raab@gmx.de:
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
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-tp343...
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?
Thanks
Mariano
On Tue, Jan 25, 2011 at 9:05 PM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
2011/1/25 Andreas Raab andreas.raab@gmx.de:
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-tp343...
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 <nicolas.cellier.aka.nice@gmail.com mailto:nicolas.cellier.aka.nice@gmail.com> wrote:
2011/1/25 Andreas Raab <andreas.raab@gmx.de <mailto:andreas.raab@gmx.de>>: > > 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
On Sun, Apr 10, 2011 at 9:08 PM, Andreas Raab andreas.raab@gmx.de 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-tp343...
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 < nicolas.cellier.aka.nice@gmail.com> wrote:
2011/1/25 Andreas Raab andreas.raab@gmx.de:
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.h...
Cheers, Henry
On 10.04.2011 21:17, Mariano Martinez Peck wrote:
On Sun, Apr 10, 2011 at 9:08 PM, Andreas Raab <andreas.raab@gmx.de mailto:andreas.raab@gmx.de> 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 <nicolas.cellier.aka.nice@gmail.com <mailto:nicolas.cellier.aka.nice@gmail.com>> wrote: 2011/1/25 Andreas Raab <andreas.raab@gmx.de <mailto:andreas.raab@gmx.de>>: > > 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
Thanks Henry. I've just read it.... so I would remove it hehehehe at least for the default CMakeVMMaker configurations...
Cheers
Mariano
On Mon, Apr 11, 2011 at 10:28 PM, Henrik Sperre Johansen < henrik.s.johansen@veloxit.no> wrote:
Please read this thread from a month ago.
http://forum.world.st/Failed-to-build-FloatMathPlugin-on-FreeBSD-td3346374.h...
Cheers, Henry
On 10.04.2011 21:17, Mariano Martinez Peck wrote:
On Sun, Apr 10, 2011 at 9:08 PM, Andreas Raab andreas.raab@gmx.de 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-tp343...
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 < nicolas.cellier.aka.nice@gmail.com> wrote:
2011/1/25 Andreas Raab andreas.raab@gmx.de:
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
On 12 April 2011 18:56, Mariano Martinez Peck marianopeck@gmail.com wrote:
Thanks Henry. I've just read it.... so I would remove it hehehehe at least for the default CMakeVMMaker configurations...
yes, remove it.
less options -> less things to be aware of -> things getting simpler
vm-dev@lists.squeakfoundation.org