[Bug c++/30470] New: Compiling C++ programs with -mno-80387 and -O3 failes

[Bug c++/30470] New: Compiling C++ programs with -mno-80387 and -O3 failes

[bugzilla at bennee dot com]

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

[bugzilla at bennee dot com]

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

[bugzilla at bennee dot com]

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

[bugzilla at bennee dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 394 bytes --]



------- Comment #3 from bugzilla at bennee dot com  2007-01-15 09:17 -------
Output of failed compile:

09:09 ajb@ajb-laptop [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

[ubizjak at gmail dot com]

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


-- 

ubizjak at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30470

[Bug target/30470] Compiling C++ programs with -mno-80387 and -O3 failes

[pinskia at gcc dot gnu dot org]

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


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c++                         |target


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30470

[Bug c++/30470] Compiling C++ programs with -mno-80387 and -O3 failes

[bugzilla at bennee dot com]

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

[pinskia at gcc dot gnu dot org]

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


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30470

[Bug c++/30470] Compiling C++ programs with -mno-80387 and -O3 failes

[bugzilla at bennee dot com]

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

[ubizjak at gmail dot com]

------- Comment #9 from ubizjak at gmail dot com  2007-01-17 06:58 -------
(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.


-- 

ubizjak at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|4.3.0                       |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30470

[Bug c++/30470] Compiling C++ programs with -mno-80387 and -O3 failes

[bugzilla at bennee dot com]

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

[Bug c++/30470] Compiling C++ programs with -mno-80387 and -O3 failes

[ubizjak at gmail dot com]

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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30470