public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Roger Sayle <sayle@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org Subject: [gcc r12-3278] C: PR c/79412: Poison decls with error_mark_node after type mismatch Date: Wed, 1 Sep 2021 07:39:37 +0000 (GMT) [thread overview] Message-ID: <20210901073937.D945C3858400@sourceware.org> (raw) https://gcc.gnu.org/g:823685221de986afb729910a6f2237f07a377f17 commit r12-3278-g823685221de986afb729910a6f2237f07a377f17 Author: Roger Sayle <roger@nextmovesoftware.com> Date: Wed Sep 1 08:38:39 2021 +0100 C: PR c/79412: Poison decls with error_mark_node after type mismatch This patch fixes an ICE during error-recovery regression in the C front-end. The symptom is that the middle-end's sanity checking assertions fail during gimplification when being asked to increment an array, which is non-sense. The issue is that the C-front end has detected the type mismatch and reported an error to the user, but hasn't provided any indication of this to the middle-end, simply passing bogus trees that the optimizers recognize as invalid. This appears to be a frequently reported ICE with 94730, 94731, 101036 and 101365 all marked as duplicates. I believe the correct (polite) fix is to mark the mismatched types as problematic/dubious in the front-end, when the error is spotted, so that the middle-end has a heads-up and can be a little more forgiving. This patch to c-decl.c's duplicate_decls sets (both) mismatched types to error_mark_node if they are significantly different, and we've issued an error message. Alas, this is too punitive for FUNCTION_DECLs where we store return types, parameter lists, parameter types and attributes in the type, but fortunately the middle-end is already more cautious about trusting possibly suspect function types. This fix required one minor change to the testsuite, typedef-var-2.c where after conflicting type definitions, we now no longer assume that the (first or) second definition is the correct one. This change only affects the behaviour after seen_error(), so should be relatively safe. 2021-09-01 Roger Sayle <roger@nextmovesoftware.com> Joseph Myers <joseph@codesourcery.com> gcc/c/ChangeLog PR c/79412 * c-decl.c (duplicate_decls): On significant mismatches, mark the types of both (non-function) decls as error_mark_node, so that the middle-end can see the code is malformed. (free_attr_access_data): Don't process if the type has been set to error_mark_node. gcc/testsuite/ChangeLog PR c/79412 * gcc.dg/pr79412.c: New test case. * gcc.dg/typedef-var-2.c: Update expeted errors. Diff: --- gcc/c/c-decl.c | 13 ++++++++++++- gcc/testsuite/gcc.dg/pr79412.c | 9 +++++++++ gcc/testsuite/gcc.dg/typedef-var-2.c | 5 +++-- 3 files changed, 24 insertions(+), 3 deletions(-) diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c index 221a67fe57b..3482d82fae1 100644 --- a/gcc/c/c-decl.c +++ b/gcc/c/c-decl.c @@ -2957,6 +2957,17 @@ duplicate_decls (tree newdecl, tree olddecl) { /* Avoid `unused variable' and other warnings for OLDDECL. */ suppress_warning (olddecl, OPT_Wunused); + /* If the types are completely different, poison them both with + error_mark_node. */ + if (TREE_CODE (TREE_TYPE (newdecl)) != TREE_CODE (TREE_TYPE (olddecl)) + && olddecl != error_mark_node + && seen_error ()) + { + if (TREE_CODE (olddecl) != FUNCTION_DECL) + TREE_TYPE (olddecl) = error_mark_node; + if (TREE_CODE (newdecl) != FUNCTION_DECL) + TREE_TYPE (newdecl) = error_mark_node; + } return false; } @@ -12209,7 +12220,7 @@ free_attr_access_data () attr_access::free_lang_data (attrs); tree fntype = TREE_TYPE (n->decl); - if (!fntype) + if (!fntype || fntype == error_mark_node) continue; tree attrs = TYPE_ATTRIBUTES (fntype); if (!attrs) diff --git a/gcc/testsuite/gcc.dg/pr79412.c b/gcc/testsuite/gcc.dg/pr79412.c new file mode 100644 index 00000000000..b60d5e1b2e3 --- /dev/null +++ b/gcc/testsuite/gcc.dg/pr79412.c @@ -0,0 +1,9 @@ +/* { dg-do compile } */ +/* { dg-options "-O2" } */ +int a; +/* { dg-message "note: previous declaration" "previous declaration" { target *-*-* } .-1 } */ +void fn1 () +{ + a++; +} +int a[] = {2}; /* { dg-error "conflicting types" } */ diff --git a/gcc/testsuite/gcc.dg/typedef-var-2.c b/gcc/testsuite/gcc.dg/typedef-var-2.c index 716d29ca323..bc119a0558e 100644 --- a/gcc/testsuite/gcc.dg/typedef-var-2.c +++ b/gcc/testsuite/gcc.dg/typedef-var-2.c @@ -4,12 +4,13 @@ int f (void) { extern float v; - +/* { dg-message "note: previous declaration" "previous declaration" { target *-*-* } .-1 } */ return (v > 0.0f); } extern int t; +/* { dg-message "note: previous declaration" "previous declaration" { target *-*-* } .-1 } */ typedef float t; /* { dg-error "redeclared as different kind of symbol" } */ -t v = 4.5f; +t v = 4.5f; /* { dg-error "conflicting types" } */
reply other threads:[~2021-09-01 7:39 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20210901073937.D945C3858400@sourceware.org \ --to=sayle@gcc.gnu.org \ --cc=gcc-cvs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).