Re: RE : ntl

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

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.

>

>>>      * Symbol files would be nice. A c++ library isn't the most easy
>>>        case, though.
>> Second issue is more difficult
>
> Is this the second issue you are refering to or something else?

Yes it is

>
>> Question. What vcs did you use?
>
> http://anonscm.debian.org/gitweb/?p=debian-science/packages/libntl.git;a=summary
> The upstreamtarballs is just all the tarballs from upstream's website
> imported and "old" is the old .dsc files imported (minus some artefacts
> from the .diff files that should never have been there), while
> "oldpatched" is the debian/patches/* files imported.

Ok will try to get a glimpse a t it tommorow

>        Bernhard R. Link
>
>
> --
> To UNSUBSCRIBE, email to debian-science-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: [🔎] 20110809150336.GA9021@pcpool00.mathematik.uni-freiburg.de">http://lists.debian.org/[🔎] 20110809150336.GA9021@pcpool00.mathematik.uni-freiburg.de
>
>