Re: RE : ntl

[roucaries bastien <roucaries.bastien+debian@gmail.com>]

On Wed, Aug 10, 2011 at 12:09 AM, roucaries bastien
<roucaries.bastien+debian@gmail.com> wrote:
> On Tue, Aug 9, 2011 at 5:03 PM, Bernhard R. Link <brlink@debian.org> wrote:
>> * Bastien ROUCARIES <roucaries.bastien@gmail.com> [110808 22:00]:
>>> Le 8 août 2011 17:45, "Bernhard R. Link" <brlink@debian.org> a écrit :
>>>> Open issues:
>>>>      * The build process creates a mach_desc.h from testing the
>>>>        build machine. I'm a bit uneasy about especially one part
>>>>        of it: register extended doubles.
>>>>
>>>>        If it finds those active of the build machine, it adds on
>>>>        i386/Linux some code to change some register to disable
>>>>        that behaviour whenever doing operations that might effect.
>>>>
>>>>        Does anyone know if those register is garanteed to be set
>>>>        on i386/Linux? If that is variable, a buildd might not have
>>>>        set it, thus the setting not compiled in thus the library
>>>>        producing different behaviour on other machines.
>>>>
>>>>        (As I read it, that flag is almost the only one not directly
>>>>        calculateable from values in limits.h or stdint.h, so it
>>>>        might make sense to patch that file with a static architecture-
>>>>        independant variant and just check at compile them whether the
>>>>        assumptions are true, instead of calculating those at runtime).
>>
>>> First issue is solved by memory by a gnulib module, it will be better to
>>> use.
>>
>> I don't find anything in gnulib documentation. Do you have a pointer?
>
> http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob_plain;f=modules/fpucw
>
>>> This approach is only suitable in main program not in library.
>>
>> The gnulib approach? Then it would not be interesting for ntl anyway.
>
> Yes but a library should not modify fpu control word.
>
>>> It is a
>>> well know i386 fpu problem. Another option is to use a special gcc flag
>>> (floating store) but library will be slower
>>
>> I think the behaviour ntl is using (some assembler on i386 to unset and
>> restore the CPU bit to control this behaviour) looks itself sane
>> (assuming it is inly relevant on i386).
>
> Not sane. Think about using another lib that need to use long double.
> It will give bad result see for instance
> http://sources.redhat.com/bugzilla/show_bug.cgi?id=706
>
> It is well know bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
>
> See example of this kind of bug here
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=247465
>
>> The possible problem I see is
>> the automatic detection by trying the build machine. I thing simply
>> hardcoding this could be safer.
>
> Not safe if your main program link to other library.
>
> Another think to try will to compile with -ffloat-store gcc option on
> i386. It will disable the excess precision. An help her.

and/or depending the case -fexcess-precision=standard

And if you are really curious see for mess instance
http://www.usenix.org/event/jvm02/full_papers/ogasawara/ogasawara.pdf

Good introduction is also here http://www.vinc17.org/research/extended.en.html

You could contact Vincent Lefèvre if you need piece of advice about
his issue. It is the man who know.

Bastien