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
