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