Hi Richard,
> From: Richard Biener <[email protected]> > Sent: 17 July 2026 10:46 > To: Roger Sayle <[email protected]> > Cc: GCC Patches <[email protected]>; Andrew Pinski > <[email protected]> > Subject: Re: [PATCH] PR tree-optimization/126242: Check range is defined to > avoid ICE. > > On Wed, Jul 15, 2026 at 10:05 PM Roger Sayle <[email protected]> > wrote: > > > > > > This patch resolves PR tree-opt/126242, an unanticipated interaction > > between the two recent (float)i == 1.0 patches to match.pd. The issue > > is that value range information is getting queried in circumstances > > (on paths) where we've failed to initialize the range and/or ranger > > has failed to bound the value. The correction below fixes this in two > > ways: initialize the range information in more cases, and check that > > the range has been successfully initialized before using it. > > > > The motivation/benefit for the first approach is seen in the example: > > > > unsigned char t = x & 63; > > return (float)t > 100.0; > > > > Previously, because unsigned char can be safely represented in a float > > we'd use the bounds [0,255], and transform this to t > 100. > > Obviously, there's benefit in using ranger to reduce the range to > > [0,63], even when the integer type fits the floating point type, > > allowing the above expression to be simplified even further to false. > > [Admittedly, this gets cleaned up in later passes/optimizations, but > > this shows a potential benefit rather than just an inefficiency for > > safety's sake]. > > > > > > This patch has been tested on x86_64-pc-linux-gnu with make bootstrap > > and make -k check, both with and without --target_board=unix{-m32} > > with no new failures. Ok for mainline? > > I'm trying to follow the logic of itype_ok and value_ok. It might be easier > to > follow if hoisting i{min,max}_val out of the if (!exception_p) like > > wide_int imin_val = wi::min_value (itype); > wide_int imax_val = wi::max_value (itype); > bool value_ok = fmt.can_represent_integral_type_p (itype); #if GIMPLE > if (!value_ok > && gimple_match_range_of_expr (vr, @0, @2) > && fmt.can_represent_range_value_p (&vr)) > { > imin_val = vr.lower_bound (); > imax_val = vr.upper_bound (); > value_ok = true; > } > #endif > > and elide itype_ok? > > OK with that change. No, the original fix is better. In your suggestion above, the range is only calculated if the type fits, and then only used if the range fits. See the text of my explanation (especially the example) for how things can be improved (for -Ofast where value_ok is irrelevant). But I agree there's no point in having both itype_ok and value_ok. My original patch from 2024 didn’t have any of these problems. > > 2026-07-15 Roger Sayle <[email protected]> > > > > gcc/ChangeLog > > PR tree-optimization/126242 > > * match.pd ((FTYPE) N CMP CST): Always attempt to initialize > > value range information. Check undefined_p before using range > > bounds. > > > > gcc/testsuite/ChangeLog > > PR tree-optimization/126242 > > * gfortran.dg/pr126242.f90: New reduced test case. > > * gfortran.dg/pr41928-2.f90: Also compile pr41928.f90 with -Ofast. > > > > > > Thanks in advance (and my apologies for any inconvenience), Roger > > --
