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
Uros.
