[Bug c++/30470] New: Compiling C++ programs with -mno-80387 and -O3 failes
Compiling a program with -O3 and -mno-80387 fails when processing strtold in stdlib.h even though it's not actually invoked. -- Summary: Compiling C++ programs with -mno-80387 and -O3 failes Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bugzilla at bennee dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30470
[Bug c++/30470] Compiling C++ programs with -mno-80387 and -O3 failes
--- Comment #1 from bugzilla at bennee dot com 2007-01-15 09:14 --- Created an attachment (id=12905) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12905&action=view) Testcase C++ source Source code of failing example -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30470
[Bug c++/30470] Compiling C++ programs with -mno-80387 and -O3 failes
--- Comment #2 from bugzilla at bennee dot com 2007-01-15 09:15 --- Created an attachment (id=12906) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12906&action=view) --save-temps output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30470
[Bug c++/30470] Compiling C++ programs with -mno-80387 and -O3 failes
--- Comment #3 from bugzilla at bennee dot com 2007-01-15 09:17 --- Output of failed compile: 09:09 [EMAIL PROTECTED] [no387] > g++-4.1 --save-temps -O3 -mno-80387 no387.cc /usr/include/stdlib.h: In function long double strtold(const char*, char**): /usr/include/stdlib.h:355: error: x87 register return with x87 disabled -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30470
[Bug c++/30470] Compiling C++ programs with -mno-80387 and -O3 failes
--- Comment #6 from bugzilla at bennee dot com 2007-01-15 17:34 --- (In reply to comment #5) > and this is a bug why? > Well for starters why should the act of #include'ing stdlib.h cause any instructions to be emitted if strtold isn't even invoked? I don't understand exactly what the relationship between the -O options and -mno-80387 is. I got lost in a maze of glibc headers trying to work out exactly what getting instantiated. As far as I can tell it boils down to (gccs?) internal implementation of strtold. However if the -mno-80387 option is meant to disable x87 instructions then it should be possible to build something without causing and x87 instructions to be emitted shouldn't it? The reason I want to disable the x87 is otherwise Signalling NaN's can get silently supressed being passed through the x87 unit. I didn't want that and wanted my SIGFPE's to be generated in some SSE code I had written. Or does your question imply this is not gcc's problem but something in glibc? -- bugzilla at bennee dot com changed: What|Removed |Added Component|target |c++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30470
[Bug c++/30470] Compiling C++ programs with -mno-80387 and -O3 failes
--- Comment #8 from bugzilla at bennee dot com 2007-01-16 11:28 --- (In reply to comment #7) > >However if the -mno-80387 option is meant to disable x87 instructions then it > > should be possible to build something without causing and x87 instructions > > to > > be emitted shouldn't it? > > Yes and that means you can not use (or reference, even via a prototype) any > function that would cause x87 which is all functions which return a > float/double. I can see why it breaks now. The headers instantiate something passed "long double" hence the code generation. Looking at my SuSE and Redhat box headers the headers are different. This could be an Ubuntu-ism - it's glibc seems to be older than that of RHAT4. It should be perfectly possible to use the -mno-80387 build flag as long as the program your compiling doesn't use the "long double" data type or call anything that returns it. According to the X86_64 ABI (3.2.3 Parameter Passing): " 6. If the class is X87, the value is returned on the X87 stack in %st0 as 80-bit x87 number. 7. If the class is X87UP, the value is returned together with the previous X87 value in %st0. 8. If the class is COMPLEX_X87, the real part of the value is returned in %st0 and the imaginary part in %st1. " Where the X87 classes are: " The 64-bit mantissa of arguments of type long double belongs to class X87, the 16-bit exponent plus 6 bytes of padding belongs to class X87UP. " and " A variable of type complex long double is classified as type COM- PLEX_X87. " -- bugzilla at bennee dot com changed: What|Removed |Added Component|target |c++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30470
[Bug c++/30470] Compiling C++ programs with -mno-80387 and -O3 failes
--- Comment #10 from bugzilla at bennee dot com 2007-01-17 10:35 --- (In reply to comment #9) > (In reply to comment #4) > > Testcase compiles OK with gcc version 4.3.0 20070115 (experimental). > > Uh, I was compiling in 32bit mode. For x86_64 compilation fails as documented > in comment #3. > What glibc version do you have? And what platform are you building on? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30470
