Re: [PATCH] match.pd: Fix x * 0.0 -> 0.0 folding [PR104389]

[Richard Biener via Gcc-patches]

> Am 05.02.2022 um 09:21 schrieb Xi Ruoyao <xry...@mengyan1223.wang>:
> 
> On Sat, 2022-02-05 at 08:21 +0100, Richard Biener via Gcc-patches wrote:
>> 
>> 
>>>> Am 05.02.2022 um 00:08 schrieb Jakub Jelinek via Gcc-patches 
>>>> <gcc-patches@gcc.gnu.org>:
>>> 
>>> Hi!
>>> 
>>> The recent PR95115 change to punt in const_binop on folding operation
>>> with non-NaN operands into NaN if flag_trapping_math broke the following
>>> testcase, because the x * 0.0 simplification punts just if
>>> x maybe a NaN (because NaN * 0.0 is NaN not 0.0) or if one of the operands
>>> could be negative zero.  But Inf * 0.0 or -Inf * 0.0 is also NaN, not
>>> 0.0, so when NaNs are honored we need to punt for possible infinities too.
> 
> Sorry for the trouble, but some warning here: even with this patch
> applied, Python would still need to replace inf * 0.0 with nan("") or
> something.  Now with folding for inf * 0.0 disabled, the multiplication
> will be evaluated at runtime and raise FE_INVALID, which is likely
> unwanted by Python.  However, raising FE_INVALID is the correct behavior
> no matter if we like or dislike it...
> 
>>> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk
>>> and 11/10 where the PR95115 change has been unfortunately backported to
>>> as well?
> 
> As there may be many packages (unfortunately) using the nasty "inf *
> 0.0" pattern to get NaN, maybe we should just revert the PR95115 change
> for 11/10, apply PR104389 patch for trunk, and announce the behavior
> change in gcc-12/changes.html?

That probably makes sense.  We could also revisit turning on -fno 
-trapping-math by default .


> -- 
> Xi Ruoyao <xry...@mengyan1223.wang>
> School of Aerospace Science and Technology, Xidian University