Re: [PATCH] [range-ops] Implement sqrt.

[Joseph Myers <joseph@codesourcery.com>]

On Thu, 17 Nov 2022, Jakub Jelinek via Gcc-patches wrote:

> On Thu, Nov 17, 2022 at 06:59:45PM +0000, Joseph Myers wrote:
> > On Thu, 17 Nov 2022, Aldy Hernandez via Gcc-patches wrote:
> > 
> > > So... is the optimization wrong?  Are we not allowed to substitute
> > > that NAN if we know it's gonna happen?  Should we also allow F F F F F
> > > in the test?  Or something else?
> > 
> > This seems like the usual ambiguity about what transformations 
> > -ftrapping-math (on by default) is meant to prevent.
> > 
> > Generally it's understood to prevent transformations that add *or remove* 
> > exceptions, so folding a case that raises "invalid" to a NaN (with 
> > "invalid" no longer raised) is invalid with -ftrapping-math.  But that 
> > doesn't tend to be applied if the operation raising the exceptions has a 
> > result that is otherwise unused - in such a case the operation may still 
> > be removed completely (the exception isn't properly treated as a side 
> > effect to avoid dead code elimination; cf. Marc Glisse's -ffenv-access 
> > patches from August 2020).  And it may often also not be applied to 
> > "inexact".
> 
> The problem is that the above model I'm afraid is largely incompatible with
> the optimizations ranger provides.

That model is more an empirical description of when the nominal 
-ftrapping-math semantics tend to be respected, than a coherent design for 
any kind of API commitment to what the option does or what the default 
trapping-math rules are.

-- 
Joseph S. Myers
joseph@codesourcery.com