On Wed, Apr 30, 2025 at 12:00 AM Andrew MacLeod <amacl...@redhat.com> wrote: > > > On 3/28/25 10:36, Andrew MacLeod wrote: > > On 3/28/25 03:19, Richard Biener wrote: > >> On Fri, Mar 28, 2025 at 12:28 AM Andrew MacLeod <amacl...@redhat.com> > >> wrote: > >>> This patch fixes both 119471 and the remainder of 110992. > >>> > >>> At issue is we do not recognize that if > >>> > >>> "a * b != 0" , then neither "a" nor "b" can be zero. > >>> > >>> This is fairly trivial with range-ops. op1_range and op2_range for > >>> operator_mult are taught that if the LHS does not contain zero, than > >>> neither does either operand. > >>> > >>> Included are patches for trunk (gcc15), gcc14, and gcc13. All are > >>> basically the same few lines. > >>> > >>> I presume we want to wait for stage 1 to check this into trunk . > >>> > >>> Bootstraps with no regressions on x86_64-pc-linux-gnu on all 3 > >>> branches. OK for gcc13 and gcc14 branches? > >> This is OK for branches only after it was on trunk. Since one of the > >> PRs is a regression it's technically OK for trunk now. > >> > >> Richard. > >> > > OK, it should be perfectly safe. Committed to trunk. > > > > Andrew > > > This patch was in trunk when gcc15 was forked, so gcc15 is already > covered. Attached are the patches for gcc14 and gcc13. > > Bootstrapped with no regressions on x86_64-pc-linux-gnu. > > Do you want me to check it in for either or both branches?
None of them I think, only one of the PRs is marked as regression but it doesn't look important enough and we should be careful about optimization regressions fixing "late" in the cycle (usually OK for N.2, but not so much later). So definitely not 13, not 14 either unless somebody else expresses a strong opinion here. Richard. > > Andrew >
