fdlibm is not C99 conformant

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

fdlibm is not C99 conformant

Nicolas Cellier
 
Hi,
I suggest using replacements for __HI() and __LO() without illegal
pointer dereferencing.
One stupid possibility is to use an explicit memory copy, like in this
example: (see test_fdlibm.c attachment)

I've tested with:
    gcc -m64 -Wall -02 -D__LITTLE_ENDIAN test_fdlibm.c
    ./a.out
and obtained
    x=-3.14159

Of course, it'll be a bit slower, but we don't care.
More problematic is that we would have to change all the fdlibm sources...

Nicolas

test_fdlibm.c (458 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: fdlibm is not C99 conformant

David T. Lewis
 
On Wed, Dec 29, 2010 at 09:21:29PM +0100, Nicolas Cellier wrote:

>  
> Hi,
> I suggest using replacements for __HI() and __LO() without illegal
> pointer dereferencing.
> One stupid possibility is to use an explicit memory copy, like in this
> example: (see test_fdlibm.c attachment)
>
> I've tested with:
>     gcc -m64 -Wall -02 -D__LITTLE_ENDIAN test_fdlibm.c
>     ./a.out
> and obtained
>     x=-3.14159
>
> Of course, it'll be a bit slower, but we don't care.
> More problematic is that we would have to change all the fdlibm sources...
Thanks Nicolas,

But the __HI and __LO macros look fine to me, and they seem to work as
expected (see attached update to your test). Is there an alignment issue
here that I'm missing?

Dave


test2.c (852 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: fdlibm is not C99 conformant

Nicolas Cellier

2010/12/29 David T. Lewis <[hidden email]>:

>
> On Wed, Dec 29, 2010 at 09:21:29PM +0100, Nicolas Cellier wrote:
>>
>> Hi,
>> I suggest using replacements for __HI() and __LO() without illegal
>> pointer dereferencing.
>> One stupid possibility is to use an explicit memory copy, like in this
>> example: (see test_fdlibm.c attachment)
>>
>> I've tested with:
>>     gcc -m64 -Wall -02 -D__LITTLE_ENDIAN test_fdlibm.c
>>     ./a.out
>> and obtained
>>     x=-3.14159
>>
>> Of course, it'll be a bit slower, but we don't care.
>> More problematic is that we would have to change all the fdlibm sources...
>
> Thanks Nicolas,
>
> But the __HI and __LO macros look fine to me, and they seem to work as
> expected (see attached update to your test). Is there an alignment issue
> here that I'm missing?
>
> Dave
>


OK, got it, you have to compile with -D__LITTLE_ENDIAN
This macro is set automatically in fdlibm.h when compiled ith -m32 but
not when compiled with -m64

Nicolas
Reply | Threaded
Open this post in threaded view
|

Re: fdlibm is not C99 conformant

Nicolas Cellier
 
>
> OK, got it, you have to compile with -D__LITTLE_ENDIAN
> This macro is set automatically in fdlibm.h when compiled ith -m32 but
> not when compiled with -m64
>
> Nicolas
>

We can add something like
  || defined(__x86_64)
in fdlibm.h

your macro definitions can be obtained via
gcc -E -dM - < /dev/null

Nicolas
Reply | Threaded
Open this post in threaded view
|

Re: fdlibm is not C99 conformant

David T. Lewis
 
On Thu, Dec 30, 2010 at 01:48:55AM +0100, Nicolas Cellier wrote:

>  
> >
> > OK, got it, you have to compile with -D__LITTLE_ENDIAN
> > This macro is set automatically in fdlibm.h when compiled ith -m32 but
> > not when compiled with -m64
> >
> > Nicolas
> >
>
> We can add something like
>   || defined(__x86_64)
> in fdlibm.h
>
> your macro definitions can be obtained via
> gcc -E -dM - < /dev/null
>
> Nicolas
Bravo, good catch! This solves the problem, and all KernelTests-Numbers
are now green with a 64-bit Linux VM.

Patching fdlibm.h solves the problem, but it is probably not good policy
to be making local patches to the library, so I think a more general fix
is to set __LITTLE_ENDIAN properly in the build system.

Attached is a platforms/unix/plugins/FloatMathPlugin/config.cmake that
addresses this, and that also sets the -O0 flag to disable gcc optimization.

I'll forward this to Ian also for the platforms/unix update.

Igor and Esteban, you may need to do something similar if you build a
32/64 bit Mac VM.

Eliot, I'm not sure if something needs to be done for the Cog platform
tree, but if so I would expect that it is a matter of adjusting the
makefiles to use " -D__LITTLE_ENDIAN=1 -O0"

Dave


config.cmake (388 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: fdlibm is not C99 conformant

David T. Lewis
 
On Thu, Dec 30, 2010 at 02:25:01PM -0500, David T. Lewis wrote:

> On Thu, Dec 30, 2010 at 01:48:55AM +0100, Nicolas Cellier wrote:
> >  
> > >
> > > OK, got it, you have to compile with -D__LITTLE_ENDIAN
> > > This macro is set automatically in fdlibm.h when compiled ith -m32 but
> > > not when compiled with -m64
> > >
> > > Nicolas
> > >
> >
> > We can add something like
> >   || defined(__x86_64)
> > in fdlibm.h
> >
> > your macro definitions can be obtained via
> > gcc -E -dM - < /dev/null
> >
> > Nicolas
>
> Bravo, good catch! This solves the problem, and all KernelTests-Numbers
> are now green with a 64-bit Linux VM.
>
> Patching fdlibm.h solves the problem, but it is probably not good policy
> to be making local patches to the library, so I think a more general fix
> is to set __LITTLE_ENDIAN properly in the build system.
>
> Attached is a platforms/unix/plugins/FloatMathPlugin/config.cmake that
> addresses this, and that also sets the -O0 flag to disable gcc optimization.
Checking Mantis 7592, I note Andreas' earlier recommendation to also
use -mno-fused-madd. Updated config.cmake attached.

Dave


>
> I'll forward this to Ian also for the platforms/unix update.
>
> Igor and Esteban, you may need to do something similar if you build a
> 32/64 bit Mac VM.
>
> Eliot, I'm not sure if something needs to be done for the Cog platform
> tree, but if so I would expect that it is a matter of adjusting the
> makefiles to use " -D__LITTLE_ENDIAN=1 -O0"
>
> Dave
>

> PLUGIN_DEFINITIONS (-DNO_ISNAN=1)
> TEST_BIG_ENDIAN(IS_BIGENDER)
> IF (NOT IS_BIGENDER)
> # fdlibm.h does not handle x86_64, so set it here for all platforms
> PLUGIN_DEFINITIONS (-D__LITTLE_ENDIAN=1)
> ENDIF()
> # The fdlibm library must be compiled with no gcc optimization. Add -O0 to
> # the CFLAGS string to override the optimization setting.
> SET (CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -O0")


config.cmake (464 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: fdlibm is not C99 conformant

Igor Stasenko
In reply to this post by David T. Lewis

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

>
> On Thu, Dec 30, 2010 at 01:48:55AM +0100, Nicolas Cellier wrote:
>>
>> >
>> > OK, got it, you have to compile with -D__LITTLE_ENDIAN
>> > This macro is set automatically in fdlibm.h when compiled ith -m32 but
>> > not when compiled with -m64
>> >
>> > Nicolas
>> >
>>
>> We can add something like
>>   || defined(__x86_64)
>> in fdlibm.h
>>
>> your macro definitions can be obtained via
>> gcc -E -dM - < /dev/null
>>
>> Nicolas
>
> Bravo, good catch! This solves the problem, and all KernelTests-Numbers
> are now green with a 64-bit Linux VM.
>
> Patching fdlibm.h solves the problem, but it is probably not good policy
> to be making local patches to the library, so I think a more general fix
> is to set __LITTLE_ENDIAN properly in the build system.
>
> Attached is a platforms/unix/plugins/FloatMathPlugin/config.cmake that
> addresses this, and that also sets the -O0 flag to disable gcc optimization.
>
> I'll forward this to Ian also for the platforms/unix update.
>
> Igor and Esteban, you may need to do something similar if you build a
> 32/64 bit Mac VM.
>

yes. done.
Thanks for good harvesting & team work!

> Eliot, I'm not sure if something needs to be done for the Cog platform
> tree, but if so I would expect that it is a matter of adjusting the
> makefiles to use " -D__LITTLE_ENDIAN=1 -O0"
>
> Dave
>
>
>



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

Re: fdlibm is not C99 conformant

Nicolas Cellier
In reply to this post by David T. Lewis
 
2010/12/30 David T. Lewis <[hidden email]>:
>
> Patching fdlibm.h solves the problem, but it is probably not good policy
> to be making local patches to the library, so I think a more general fix
> is to set __LITTLE_ENDIAN properly in the build system.
>

Agree, unless the library is abandonware.

Nicolas