https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #48 from Eric Botcazou <ebotcazou at gcc dot gnu.org> --- > OK, we can certainly try to enforce this. Just to make sure - this > refers to TREE_TYPE (TREE_OPERAND (bfr, 0)), not the base of the > component-ref chain eventually rooted here? Yes, formally it's the former, i.e. the type of operand #0 of BIT_FIELD_REF. > On GIMPLE, if we want to extract some bits from a register that happens to > be a non-"base" type this means we have to use shifting and masking. I > suppose the same issue hits BIT_INSERT_EXPR. This makes it somewhat > awkward (aka non-canonical) on the GIMPLE side :/ Yes, I think that the handling of BIT_INSERT_EXPR should be symmetrical. > The most natural thing there would then be to disallow such types in the IL. Yes, as type of operand #0 of BIT_FIELD_REF/BIT_INSERT_EXPR. > Btw, are PSImode / int : 24 "bona-fide base types"? Thus, is the criteria > that precision matches TYPE_SIZE? GET_MODE_PRECISION? GET_MODE_BITSIZE? > I know we try to avoid introducing bit-precision ops during GIMPLE > optimization but FEs happily leak those into the IL (as in this testcase). The predicate type_has_mode_precision_p is the one used by the RTL expander to identify bit-field types. Moreover it's also already used in a few GIMPLE optimization passes (fwprop, vrp, vectorize) so it seems to be fit the bill. So a base type would be (!INTEGRAL_TYPE_P || type_has_mode_precision_p).
