https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125674
--- Comment #3 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:50ba4a8ca7a51a72514aae55d9fb81732ef7a3bd commit r17-1522-g50ba4a8ca7a51a72514aae55d9fb81732ef7a3bd Author: Jakub Jelinek <[email protected]> Date: Fri Jun 12 22:43:06 2026 +0200 c++: Diagnose invalid type of bitfield widths in templates [PR125674] As the first testcase shows, outside of templates or when the bitfield width is not type dependent, we diagnose it in grokbitfield: if (width != error_mark_node) { /* The width must be an integer type. */ if (!type_dependent_expression_p (width) && !INTEGRAL_OR_UNSCOPED_ENUMERATION_TYPE_P (TREE_TYPE (width))) error ("width of bit-field %qD has non-integral type %qT", value, TREE_TYPE (width)); else if (!check_for_bare_parameter_packs (width)) { /* Temporarily stash the width in DECL_BIT_FIELD_REPRESENTATIVE. check_bitfield_decl picks it from there later and sets DECL_SIZE accordingly. */ DECL_BIT_FIELD_REPRESENTATIVE (value) = width; SET_DECL_C_BIT_FIELD (value); } } Later on in check_bitfield_decl we verify it is a constant expression, folded into INTEGER_CST, non-negative etc. But during instantiation, we don't repeat that check, so only call check_bitfield_decl later on which can sometimes emit different diagnostics (so e.g. bit-field âD<1.0e+0>::dâ width not an integer constant instead of width of bit-field âD<N>::dâ has non-integral type âdoubleâ ) but what the second testcase shows, we can ICE during cxx_constant_value even before that if the type is even more problematic. The following patch fixes that by repeating the test from grokbitfield during tsubst_decl. 2026-06-12 Jakub Jelinek <[email protected]> PR c++/125674 * pt.cc (tsubst_decl): Diagnose bit-field widths with invalid type. * g++.dg/template/bitfield5.C: New test. * g++.dg/template/bitfield6.C: New test. Reviewed-by: Jason Merrill <[email protected]>
