This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/19379] [4.0 Regression] ICE during build of newlib's e_atan2.c when soft-float
- From: "rth at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 12 Jan 2005 19:47:20 -0000
- Subject: [Bug target/19379] [4.0 Regression] ICE during build of newlib's e_atan2.c when soft-float
- References: <20050111163457.19379.joel@gcc.gnu.org>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From rth at gcc dot gnu dot org 2005-01-12 19:47 -------
In reply to comment #5:
Perhaps I am out of touch with what's extant in the embedded space.
I havn't been paid to care about that in quite some time. I'll defer.
Using "-MASK_80387|-MASK_FLOAT_RETURNS" is incorrect. It should
be "-(MASK_80387|MASK_FLOAT_RETURNS)". I agree with Ralf's later
comment that -mno-80387 and -msoft-float should probably stay in
sync. Though of course -msoft-float doesn't really mean as much
as it sounds like it ought in conjunction with -mfpmath.
In reply to comment #7:
Yes, I did mean trap #7 handler for an fpu emulator. Though of
course there are different levels of emulation. One thing that
has been done before for MIPS is to provide a trap handler, but
only implement the move instructions. This allows the ABI to
remain unchanged by pretending that the appropriate registers
exist, but not having to incur most of the overhead for trapping
for all arithmetic instructions.
Since RTEMS is multilibed, this is much less of an advantage.
In any case, Joel, would you please take ownership of this bug
and see it through? You're the one that would have to be doing
the RTEMS testing anyway...
--
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|rth at gcc dot gnu dot org |unassigned at gcc dot gnu
| |dot org
Status|WAITING |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19379