Quantcast

Portability problems: compiler flags

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Portability problems: compiler flags

Aleksej Saushev-2
 
  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 ()



--
HE CE3OH...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Portability problems: compiler flags

Igor Stasenko

On 25 January 2011 03:26, Aleksej Saushev <[hidden email]> 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...
>



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

Re: Portability problems: compiler flags

Aleksej Saushev-2

Igor Stasenko <[hidden email]> writes:

> On 25 January 2011 03:26, Aleksej Saushev <[hidden email]> 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.


--
HE CE3OH...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Portability problems: compiler flags

Andreas.Raab
In reply to this post by Igor Stasenko
 
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Portability problems: compiler flags

Levente Uzonyi-2
In reply to this post by Aleksej Saushev-2
 
On Tue, 25 Jan 2011, Aleksej Saushev wrote:

>
> Igor Stasenko <[hidden email]> writes:
>
>> On 25 January 2011 03:26, Aleksej Saushev <[hidden email]> 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...
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Portability problems: compiler flags

David T. Lewis
In reply to this post by Andreas.Raab
 
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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Portability problems: compiler flags

Igor Stasenko

On 25 January 2011 14:30, David T. Lewis <[hidden email]> 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
>
>



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

Re: Portability problems: compiler flags

Aleksej Saushev-2

Igor Stasenko <[hidden email]> writes:

> On 25 January 2011 14:30, David T. Lewis <[hidden email]> 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?


--
HE CE3OH...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Portability problems: compiler flags

Nicolas Cellier
In reply to this post by Andreas.Raab

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
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Portability problems: compiler flags

Mariano Martinez Peck
 
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?

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Portability problems: compiler flags

Andreas.Raab
 
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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Portability problems: compiler flags

Mariano Martinez Peck
 


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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Portability problems: compiler flags

Henrik Sperre Johansen
 
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Portability problems: compiler flags

Mariano Martinez Peck
 
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 <[hidden email]> wrote:
 
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






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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Portability problems: compiler flags

Igor Stasenko

On 12 April 2011 18:56, Mariano Martinez Peck <[hidden email]> 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



--
Best regards,
Igor Stasenko AKA sig.
Loading...