This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [m68k] Fix PR target/13292: -msoft-float seems to corrupt builtindefines
Gunther Nikl wrote:
On Tue, Jun 15, 2004 at 02:21:34PM +0200, Bernardo Innocenti wrote:
Gunther Nikl wrote:
On Sat, Jun 12, 2004 at 04:40:11AM +0200, Bernardo Innocenti wrote:
The -msoft-float option incorrectly removed MASK_68040_ONLY
in addition to MASK_68881. This leads to incorrect
predefines and unwanted degradation of integer code.
There was just one place where we were using
TARGET_68040_ONLY to generate a floating-point
instruction without taking TARGET_68881 into account.
Tested on m68k-unknown-uclinux by comparing assembly
output of some selected testcases from gcc.c-torture.
OK for mainline? 3_4-branch?
Shouldn't this go to the 3.3 branch as well?
I clearly remember posting the patch to reorganize the m68k predefines
during the 3.4 timeframe.
I didn't notice that this reorganization affects this patch.
[See below]
Before that patch, we had that mess with CPP_SPEC which used to set
all of the __m680x0__ predefines even in the 68040 case, which was
inappropriate but consistent with previous versions of GCC.
I thought this patch corrects an inapproriate usage of
TARGET_68040_ONLY where GCC didn't generate valid 68040 integer
instructions. Where is the conflicht with the predefines?
The patch was primary meant to fix PR13292, which is about
the __m680x0__ (with x=1,2,3) predefines magically appearing
when one specifies -msoft-float along with -m68040.
The problem was caused by -msoft-float removing
MASK_68040_ONLY to be absolutely sure no FP instructions
would be generated.
This would leave target flags with MASK_68040, which
is a superset of MASK_68030 (and hence MASK_68020...).
So I changed -msoft-float to only touch MASK_68881 and
examined the places where (TARGET|MASK)_68040_ONLY were
used to generate FP code. As turned out, there was only
one such places in m68k.md.
Now -msoft-float is the exact opposite of -m68881, which
is good :)
I vaguely remember you objecting that the new predefines
made it hard to do something useful in math-68881.h. Is
it still the case with this patch applied? If so, what
was the original workaround you had suggested?
--
// Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/ http://www.develer.com/