On Wed, Aug 10, 2011 at 12:09 AM, roucaries bastien <[email protected]> wrote: > On Tue, Aug 9, 2011 at 5:03 PM, Bernhard R. Link <[email protected]> wrote: >> * Bastien ROUCARIES <[email protected]> [110808 22:00]: >>> Le 8 août 2011 17:45, "Bernhard R. Link" <[email protected]> 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/CAE2SPAaV2wcUSpxsW6TDM8pV6nsybp=nec_a4yuyaqmh1rr...@mail.gmail.com
