On Mon, 28 Jul 2025, Jakub Jelinek wrote: > On Sun, Jul 27, 2025 at 09:27:30PM -0400, Pietro Monteiro wrote: > > On Mon, Jul 14, 2025, at 10:43 PM, Hans-Peter Nilsson wrote: > > > Tested to fix build for MMIX (and to fix a few type-generic-builtin > > > test-cases; c-c++-common/pr111309-1.c, gcc.dg/torture/pr116480-1.c). > > > Also regtested cris-elf and native x86_64-pc-linux-gnu. > > > > FYI, this patch also fixes PR120144, similar ICE related to > > MAX_FIXED_MODE_SIZE/int128 when building libstdc++ for mips64-elf. > > The patch looks wrong to me. > The FE lowering of the wider integer bit queries needs to perform > shifts etc., so it shouldn't be larger than MAX_FIXED_MODE_SIZE.
No, those operations actually work fine (here after the change and everywhere else). It is only this recently-added generic-type-support code that fails. > If you have a target with bogus MAX_FIXED_MODE_SIZE definition, you should > just fix that. That macro should be avoided, for one because it's misleading and ends up being used for other than target tweaking (QED). There's likely a need for a macro or other mechanism that has the upper limit on "what the target *can* support" (as opposed to its semantic "what gcc *should* use for this target") but it's not this macro in its current form. IMO the value of that macro *could* cause the operation to decompose into even smaller-sized operation, but such an nonoptimal value must not cause the operation to fail. Even if you disagree with that, this is an opportunity to eliminate a use of a problematic macro. Win-win IMHO: We already know the incoming size (here int128) is supported, or it wouldn't get to the code here. The patch changes the compare to twice the size of long-long instead on MAX_FIXED_MODE_SIZE. The occurrences of "MAX_FIXED_MODE_SIZE / 2" in the decomposed expression is a clue that it's not quite right. Ok now? brgds, H-P
