Re: RE : ntl
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
>
>
Reply to:
- Follow-Ups:
- Re: RE : ntl
- From: roucaries bastien <roucaries.bastien+debian@gmail.com>
- Re: RE : ntl
- From: "Bernhard R. Link" <brlink@debian.org>
- References:
- RE : ntl
- From: Bastien ROUCARIES <roucaries.bastien@gmail.com>
- Re: RE : ntl
- From: "Bernhard R. Link" <brlink@debian.org>