On Fri, Nov 17, 2017 at 12:10 AM, Marc Glisse <marc.gli...@inria.fr> wrote:
> On Thu, 16 Nov 2017, Richard Biener wrote:
>
>> On Thu, Nov 16, 2017 at 3:33 PM, Wilco Dijkstra <wilco.dijks...@arm.com>
>> wrote:
>>>
>>> GCC currently defaults to -ftrapping-math. This is supposed to generate
>>> code for correct user-visible traps and FP status flags.
>>>
>>> However it doesn't work as expected since it doesn't block any floating
>>> point optimizations. For example it continues to perform CSE, moves FP
>>> operations across calls, moves FP operations out of loops, constant folds
>>> and removes dead floating point operations that cause exceptions.
>>>
>>> Given the majority of code doesn't contain user trap handlers or inspects
>>> FP status flags, there is no point in enabling it even if it worked as
>>> expected.
>>>
>>> Simple case that should cause a FP exception:
>>>
>>> void f(void)
>>> {
>>> 0.0 / 0.0;
>>> }
>>>
>>> Compiles to:
>>>
>>> f:
>>> ret
>>
>>
>> We are generally not preserving traps but we guard any transform that
>> might introduce traps with -ftrapping-math. That's similar to how we
>> treat
>> -ftrapv and pointer dereferences.
>
>
> Joseph seems to have a different opinion in PR 53805. Splitting the option
> (one strict version that preserves floating point status changes, one weak
> version that only avoids introducing new traps but may remove existing ones)
> would help clarify the situation.
Maybe. Though we certainly don't handle the situation consistently.
>> We're mitigating the "bad" effect of the -ftrapping-math default
>> by defaulting to -fno-signalling-nans.
>>
>> If it doesn't block any optimizations what's the point of the patch?
>>
>> Richard.
>>
>>> OK for commit?
>>>
>>> 2017-11-16 Wilco Dijkstra <wdijk...@arm.com>
>
>
> You could mention PR 54192 here.
>
>>> * common.opt (ftrapping-math): Change default to 0.
>>> * doc/invoke.texi (-ftrapping-math): Update documentation.
>
>
> I am surprised that no testsuite change is needed.
Indeed. Would be a good time to add some tests then, esp. for the cases
that we should now optimize by default (still wondering which case
this should be).
Richard.
> --
> Marc Glisse
