https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122540
--- 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:8e3291f507757e40336600e09ead9d1123eefe1e commit r16-5438-g8e3291f507757e40336600e09ead9d1123eefe1e Author: Jakub Jelinek <[email protected]> Date: Thu Nov 20 07:59:13 2025 +0100 c++: Fix error recovery for enums with bad underlying type [PR122540] The r16-4698 patch to use fold_convert in finish_enum_value_list instead of copy_node + set TREE_TYPE caused UB in the compiler as detected e.g. by valgrind on the g++.dg/parse/pr96442.C g++.dg/cpp0x/auto9.C testcases. If underlying type is valid, start_enum does: else if (CP_INTEGRAL_TYPE_P (underlying_type)) { copy_type_enum (enumtype, underlying_type); ENUM_UNDERLYING_TYPE (enumtype) = underlying_type; } and the copy_type_enum ensures the ENUMERAL_TYPE has the same TYPE_PRECISION, TYPE_SIZE etc. But if the underlying type is erroneous, it errors and for error recovery sets ENUM_UNDERLYING_TYPE (enumtype) = integer_type_node; This means TYPE_PRECISION on the ENUMERAL_TYPE remains 0, TYPE_SIZE NULL etc. and then later on when we try to fold_convert the enumerator values to that type, we invoke UB in the wide_int code because it really doesn't like casts to 0 precision integral types. The following patch fixes it by calling also copy_type_enum from integer_type_node when we set such underlying type. 2025-11-20 Jakub Jelinek <[email protected]> PR c++/122540 * decl.cc (start_enum): When setting ENUM_UNDERLYING_TYPE to integer_type_node during error recovery, also call copy_type_enum.
