On Tue, Jan 12, 2016 at 12:10:20PM +0100, Uros Bizjak wrote:
> On Tue, Jan 12, 2016 at 1:15 AM, Joseph Myers <jos...@codesourcery.com> wrote:
> > On Mon, 11 Jan 2016, H.J. Lu wrote:
> >
> >> Here is the updated patch. Joseph, is this OK?
> >
> > I have no objections to this patch.
>
> Thinking some more, it looks to me that we also have to return 2 when
> SSE2 (SSE doubles) is not enabled.
>
> I'm testing following patch:
That looks weird. If TARGET_80387 and !TARGET_SSE_MATH, then no matter
whether sse2 is enabled or not, normal floating point operations will be
performed in 387 stack and thus FLT_EVAL_METHOD should be 2, not 0.
Do you want to do this because some instructions might be vectorized and
therefore end up in sse registers? For -std=c99 that shouldn't happen,
already the C FE would promote all the arithmetics to be done in long
doubles, and for -std=gnu99 it is acceptable if non-vectorized computations
honor FLT_EVAL_METHOD and vectorized ones don't.
>
> diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
> index 6c63871..b71cf4f 100644
> --- a/gcc/config/i386/i386.h
> +++ b/gcc/config/i386/i386.h
> @@ -693,8 +693,9 @@ extern const char *host_detect_local_cpu (int
> argc, const char **argv);
> only SSE, rounding is correct; when using both SSE and the FPU,
> the rounding precision is indeterminate, since either may be chosen
> apparently at random. */
> -#define TARGET_FLT_EVAL_METHOD \
> - (TARGET_MIX_SSE_I387 ? -1 : (TARGET_80387 && !TARGET_SSE_MATH) ? 2 : 0)
> +#define TARGET_FLT_EVAL_METHOD \
> + (TARGET_MIX_SSE_I387 ? -1 \
> + : (TARGET_80387 && !TARGET_SSE2 && !TARGET_SSE_MATH) ? 2 : 0)
>
> /* Whether to allow x87 floating-point arithmetic on MODE (one of
> SFmode, DFmode and XFmode) in the current excess precision
>
> Uros.
Jakub
