Compiling a program with and -mno-80387 fails when processing strtold in
stdlib.h even though it's not actually invoked.

Comment #1 from bugzilla at bennee dot com 2007-01-15 09:14
Created an attachment (id=12905)
()
Testcase C++ source
Source code of failing example

Comment #2 from bugzilla at bennee dot com 2007-01-15 09:15
Created an attachment (id=12906)
()
output

Comment #3 from bugzilla at bennee dot com 2007-01-15 09:17
of failed compile:
09:09 ajb@ajb-laptop [no387] g4.1 -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

Comment #4 from ubizjak at gmail dot com 2007-01-15 15:24
Testcase compiles K with gcc version 4.3.0 20070115 (experimental).

Comment #5 from pinskia at gcc dot gnu dot org 2007-01-15 17:03
and this is a bug why?

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 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.

does your question imply this is not gcc's problem but something in glibc?

Comment #7 from pinskia at gcc dot gnu dot org 2007-01-15 17:44
>Well for starters why should the act of #include'ing stdlib.h cause any
instructions to be emitted if strtold isn't even invoked?
Not really.

>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.

>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.

You cannot without changing the ABI and changing the abi would mean you can't
do any thing.

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 CMPLEX_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 CM-
PLEX_X87.
"

Comment #9 from ubizjak at gmail dot com 2007-01-17 06:58
(In reply to comment #4)
Testcase compiles K 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.

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 K 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?

Comment #11 from ubizjak at gmail dot com 2007-01-17 12:39
(In reply to comment #10)
What glibc version do you have? And what platform are you building on?
GNU C Library development release version 2.3.6
2.6.17-1.2142_FC4smp on i686-pc-linux-gnu and x86_64-pc-linux-gnu.