On Wed, Nov 19, 2025 at 09:24:26AM +0100, Jakub Jelinek wrote:
> 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;
Ah right.
> 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.
Patch looks good. It won't affect our compare_reflections.
> 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;
> }
> }
Marek
