This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix PR optimization/11637 (x86)
- From: "Zack Weinberg" <zack at codesourcery dot com>
- To: Eric Botcazou <ebotcazou at libertysurf dot fr>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Sat, 13 Sep 2003 17:50:20 -0700
- Subject: Re: [PATCH] Fix PR optimization/11637 (x86)
- References: <200309131036.19639.ebotcazou@libertysurf.fr>
Eric Botcazou <ebotcazou@libertysurf.fr> writes:
> Hi,
>
> This is again a problem with -fnon-call-exceptions, a regression present on
> the 3.3 branch (and latent on mainline).
>
> The compiler emits
>
> movl 5.0000000745058059692383e-2, (%eax)
>
> in the assembly file, which is not quite a pure x86 idiom.
Decimal floating point literals should never appear in assembly
output. The real bug is that print_operand tried to do that. There's
nothing wrong with the movsf_1 pattern. I *think* what happened is
that the CONST_DOUBLE in question was marked as one of [DXT]Fmode for
some reason, thus hitting the
/* These float cases don't actually occur as immediate operands. */
else if (GET_CODE (x) == CONST_DOUBLE && GET_MODE (x) == DFmode)
...
else if (GET_CODE (x) == CONST_DOUBLE
&& (GET_MODE (x) == XFmode || GET_MODE (x) == TFmode))
...
cases in i386.c:print_operand. So there are actually two bugs:
(1) that print_operand uses real_to_decimal at all, (2) that we
a non-SFmode CONST_DOUBLE at this point. Please look into those.
zw