On Fri, Nov 17, 2017 at 12:10 AM, Marc Glisse wrote:
> On Thu, 16 Nov 2017, Richard Biener wrote:
>
>> On Thu, Nov 16, 2017 at 3:33 PM, Wilco Dijkstra
>> wrote:
>>>
>>> GCC currently defaults to -ftrapping-math. This is supposed to generate
>>> code for correct user-visible traps and FP status f
On Thu, 16 Nov 2017, Richard Biener wrote:
On Thu, Nov 16, 2017 at 3:33 PM, Wilco Dijkstra 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 fl
I'd expect (considering the whole GNU toolchain, not just GCC in
isolation) this to require a corresponding glibc change to build with
-ftrapping-math (added alongside the use of -frounding-math - adding the
option is of course save independently of the GCC change).
Also, GCC tests involving fl
Richard Biener wrote:
> 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.
Right. It appears it's mostly concerned about division - if it is about division
by zero
On Thu, Nov 16, 2017 at 3:33 PM, Wilco Dijkstra 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 examp
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,
