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 jos...@codesourcery.com
