[Bug tree-optimization/105414] constant folding for fmin/max(snan, snan) is wrong

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105414

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #9)
> (In reply to HaoChen Gui from comment #8)
> > (In reply to Jakub Jelinek from comment #7)
> > > Sure, but you don't want to do that at least if flag_trapping_math.
> > > Otherwise, the predicate would be tree_expr_signaling_nan_p and real_nan
> > > function with "", 1 as the middle 2 arguments can create it.  But note that
> > > nothing in match.pd does that right now, so I don't think we should do it in
> > > this case either.
> > 
> > If either of arguments is sNaN, fmin/max should return a qNaN. So I really
> > want to create a pattern in match.pd to do this. It needs to create a qNaN
> 
> A sNaN should primarily raise an exception or raise a signal when used.
> So better not to fold it.
> Given that we don't fold anything else with sNaN, starting from sNaN +
> whatever
> etc., just folding it for something so rare as fmin/fmax would be weird.

Agreed btw.  Iff then such propagation / simplification should belong in
a pass like forwprop or value-numbering which can do this in a cheaper way
than adding patterns for all kinds of operations with NaNs.  One might also
say that we should diagnose any arithmetic with known NaNs ...