Re: [PATCH] range-op-float: Fix up float_widen_lhs_range [PR126641]

On 8/6/26 11:50, Aldy Hernandez wrote:
> On Thu, Aug 06, 2026 at 04:27:41PM +0200, Jakub Jelinek wrote:
>> On Thu, Aug 06, 2026 at 04:11:12PM +0200, Aldy Hernandez wrote:
>>> I still think we should put in an assert in the real.cc code that dies
>>> hard if we try to blow past the significant size, like I had in the
>>> PR.  That way we can at least catch problems in this space without
>>> having to go through the hell of memory corruption.
>> I'm certainly not against that assert, perhaps it can be gcc_checking_assert
>> only though.
>>
>>> Overall, I'm not a big fan of having to expose the internals of frange
>>> in this manner.  The fact that we have to do this, means we're either
>>> doing something wrong, or the API is missing something.  What could we
>>> provide to make this cleaner?
>> I admit it is ugly, but I think that is the sign the APIs protect developers
>> properly from using hacks like this.  In most cases, it is just fine if
>> one needs to go through the union_ way you've used, if we add APIs that
>> allow to change arbitrary bounds (e.g. set_lower_bound (i, value),
>> set_upper_bound (i, value), set_num_ranges or something like that, it will
>> make it easier to do such hacks everywhere.
>> I'd hope this is the only spot that needs to do such stuff, which is why
>> I went with the friend declaration.
> Again, speaking from a deep well of ignorance here, maybe if we
> absolutely need to touch internals here, we should make it a proper
> member of the frange class?
>
> Andrew, Richi, thoughts?
>
> Aldy

Not sure I completely follow exactly, but can you simply make 
float_widen_lhs_range a public method of frange? it always seems to be a 
copy that is been adjusted anyway.. so instead of

frange wlhs = float_widen_lhs_range (type, lhs); you'd do something like 
frange wlhs = lhs; wlhs.widen (type);

Then it would naturally have access to everything it needs.. it seems 
that range-ops is natural consumer that needs this functionaility...

Andrew