On 2/22/22 08:02, Roger Sayle wrote:
This patch resolves PR c++/96442, another ICE-after-error regression.
In this case, invalid code attempts to use a non-integral type as the
underlying type for an enumeration (a record_type in the example given
in the bugzilla PR), for which the parser emits an error message but
allows the inappropriate type to leak to downstream code.
How does that happen?
Would it help to change dependent_type_p in start_enum to WILDCARD_TYPE_P?
The minimal
safe fix is to double check that the enumeration's underlying type
EUTYPE satisfies INTEGRAL_TYPE_P before calling int_fits_type_p in
build_enumerator. This is a one line fix, but correcting indentation
and storing a common subexpression in a variable makes the change look
a little bigger.
This patch has been tested on x86_64-pc-linunx-gnu with make bootstrap
and make -k check with no new (unexpected) failures. Ok for mainline?
2022-02-22 Roger Sayle <ro...@nextmovesoftware.com>
gcc/cp/ChangeLog
PR c++/96442
* decl.cc (build_enumeration): Check ENUM_UNDERLYING_TYPE is
INTEGRAL_TYPE_P before calling int_fits_type_p.
gcc/testsuite/ChangeLog
PR c++/96442
* g++.dg/pr96442.C: New test cae.
Thanks in advance,
Roger
--
