> Am 17.07.2026 um 17:40 schrieb Roger Sayle <[email protected]>:
>
>
> 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.
I read it the opposite way (but maybe I am missing a UNDEFINED check on the
range)
> 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
>>> --
>
