https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124826
--- Comment #4 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <[email protected]>: https://gcc.gnu.org/g:6f5a97f5a3bfcdcf312f5cd1df8c16398859e8d8 commit r16-8597-g6f5a97f5a3bfcdcf312f5cd1df8c16398859e8d8 Author: Jakub Jelinek <[email protected]> Date: Tue Apr 14 09:27:09 2026 +0200 bitintlower: Handle BIT_FIELD_REF load [PR124826] The following testcase ends up with a BIT_FIELD_REF from a VECTOR_TYPE union member to _BitInt(256). gimple-lower-bitint.cc already contains code to handle BIT_FIELD_REFs with SSA_NAME first operand to BITINT_TYPE (for constant index limb access by adjusting the BIT_FIELD_REF to use different bitsize and index, for variable index (huge _BitInt with limbs accessed in a loop) by forcing the SSA_NAME into memory), but that doesn't trigger here, because gimple_assign_load_p predicate is true on it and so it is handled as load and not BIT_FIELD_REF. Anyway, the problem is that we end up with _7 = VIEW_CONVERT_EXPR<unsigned long[4]>(BIT_FIELD_REF <u.v, 256, 0>)[_2]; which tree-cfg.cc verifier doesn't like because BIT_FIELD_REF is not toplevel reference in there. The following patch just strips the BIT_FIELD_REF away if it has zero bit offset, that is the only case I've managed to reproduce, and in that case we are still later on using VCE to convert to array and using ARRAY_REF on that. If offset could be non-zero but multiple of BITS_PER_UNIT, another approach would be to replace BIT_FIELD_REF with a MEM_REF. Anyway, as I haven't managed to reproduce it with anything but 0, the following patch is enough. 2026-04-14 Jakub Jelinek <[email protected]> PR tree-optimization/124826 * gimple-lower-bitint.cc (bitint_large_huge::handle_load): Look through BIT_FIELD_REF with zero bit offset. * gcc.dg/bitint-128.c: New test. Reviewed-by: Andrew Pinski <[email protected]>
