Hi!
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.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2025-11-19 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.
--- gcc/cp/decl.cc.jj 2025-11-15 11:57:53.020056413 +0100
+++ gcc/cp/decl.cc 2025-11-18 17:47:56.029713633 +0100
@@ -18723,6 +18723,7 @@ start_enum (tree name, tree enumtype, tr
{
error ("underlying type %qT of %qT must be an integral type",
underlying_type, enumtype);
+ copy_type_enum (enumtype, integer_type_node);
ENUM_UNDERLYING_TYPE (enumtype) = integer_type_node;
}
}
Jakub
