On Tue, Jan 12, 2016 at 1:12 PM, Uros Bizjak <ubiz...@gmail.com> wrote: > On Tue, Jan 12, 2016 at 12:18 PM, Jakub Jelinek <ja...@redhat.com> wrote: >> 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. > > Eh, today is just not the day for science. > > Hopefully, the logic in the patch below is correct: > > diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h > index 6c63871..5b42e89 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
Using this patch, SSE math won't be emitted for a simple testcase using " -O2 -msse -m32 -std=c99 -mfpmath=sse" compile flags: float test (float a, float b) { return a + b; } since we start with: test (float a, float b) { long double _2; long double _4; long double _5; float _6; <bb 2>: _2 = (long double) a_1(D); _4 = (long double) b_3(D); _5 = _2 + _4; _6 = (float) _5; return _6; } This is counter-intuitive, so I'd say we leave things as they are. The situation where only floats are evaluated as floats and doubles are evaluated as long doubles is not covered in the FLT_EVAL_METHOD spec. Uros.