On 6/5/22 06:09, Roger Sayle wrote:

Hi Jason,
My apologies for the long delay, but I've finally got around to
implementing your suggested improvements (implied by your review):
https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591504.html
of my patch for PR c++/96442:
https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590716.html

The "How does that happen?" is insightful and leads to a cleaner
solution, setting ENUM_UNDERLYING_TYPE to integer_type_node when
issuing an error, so that this invariant holds during the parser's
error recovery.  I've also moved the new testcase to the g++.dg/parse
subdirectory as per your feedback on my previous ICE-on-invalid fixes.

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?

OK.

2022-06-05  Roger Sayle  <ro...@nextmovesoftware.com>

gcc/cp/ChangeLog
         PR c++/96442
         * decl.cc (start_enum): When emitting a "must be integral" error,
         set ENUM_UNDERLYING_TYPE to integer_type_node, to avoid an ICE
         downstream in build_enumeration.

gcc/testsuite/ChangeLog
         PR c++/96442
         * g++.dg/parse/pr96442.C: New test cae.

Thanks again,
Roger
--

-----Original Message-----
From: Jason Merrill <ja...@redhat.com>
Sent: 10 March 2022 05:06
To: Roger Sayle <ro...@nextmovesoftware.com>; gcc-patches@gcc.gnu.org
Subject: Re: [C++ PATCH] PR c++/96442: Another improved error recovery in
enumerations.

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
--



Reply via email to