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 ...
