public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org Subject: [gcc r11-8765] stor-layout: Avoid DECL_BIT_FIELD_REPRESENTATIVE with NULL TREE_TYPE [PR101172] Date: Sun, 18 Jul 2021 23:28:41 +0000 (GMT) [thread overview] Message-ID: <20210718232841.3F3B6385BC23@sourceware.org> (raw) https://gcc.gnu.org/g:2b99794806d83e47249fd7c05bf521caee1fdcd4 commit r11-8765-g2b99794806d83e47249fd7c05bf521caee1fdcd4 Author: Jakub Jelinek <jakub@redhat.com> Date: Thu Jun 24 12:22:14 2021 +0200 stor-layout: Avoid DECL_BIT_FIELD_REPRESENTATIVE with NULL TREE_TYPE [PR101172] finish_bitfield_representative has an early out if the field after a bitfield has error_mark_node type, but that early out leads to TREE_TYPE of the DECL_BIT_FIELD_REPRESENTATIVE being NULL, which breaks assumptions on code that uses the DECL_BIT_FIELD_REPRESENTATIVE during error-recovery. The following patch instead sets TREE_TYPE of the representative to error_mark_node, something the users can deal with better. At this point the representative can be set as DECL_BIT_FIELD_REPRESENTATIVE for multiple bitfields, so making sure that we clear the DECL_BIT_FIELD_REPRESENTATIVE instead would be harder (but doable, e.g. with the error_mark_node TREE_TYPE set by this patch set some flag in the caller and if the flag is there, walk all the fields once again and clear all DECL_BIT_FIELD_REPRESENTATIVE that have error_mark_node TREE_TYPE). 2021-06-24 Jakub Jelinek <jakub@redhat.com> PR middle-end/101172 * stor-layout.c (finish_bitfield_representative): If nextf has error_mark_node type, set repr type to error_mark_node too. * gcc.dg/pr101172.c: New test. (cherry picked from commit 65371066d8967560e3508af4a804e0ddb90acee7) Diff: --- gcc/stor-layout.c | 5 ++++- gcc/testsuite/gcc.dg/pr101172.c | 20 ++++++++++++++++++++ 2 files changed, 24 insertions(+), 1 deletion(-) diff --git a/gcc/stor-layout.c b/gcc/stor-layout.c index 9f850c3951e..242452f2acf 100644 --- a/gcc/stor-layout.c +++ b/gcc/stor-layout.c @@ -2086,7 +2086,10 @@ finish_bitfield_representative (tree repr, tree field) /* If there was an error, the field may be not laid out correctly. Don't bother to do anything. */ if (TREE_TYPE (nextf) == error_mark_node) - return; + { + TREE_TYPE (repr) = error_mark_node; + return; + } maxsize = size_diffop (DECL_FIELD_OFFSET (nextf), DECL_FIELD_OFFSET (repr)); if (tree_fits_uhwi_p (maxsize)) diff --git a/gcc/testsuite/gcc.dg/pr101172.c b/gcc/testsuite/gcc.dg/pr101172.c new file mode 100644 index 00000000000..b9d098bb644 --- /dev/null +++ b/gcc/testsuite/gcc.dg/pr101172.c @@ -0,0 +1,20 @@ +/* PR middle-end/101172 */ +/* { dg-do compile } */ +/* { dg-options "-O2" } */ + +union U +{ + int a[3]; + struct + { + int a : 3; + struct this_struct var; /* { dg-error "field 'var' has incomplete type" } */ + } b; +}; + +const union U hello = {.a = {1, 2, 3}}; + +void foo() +{ + int x = hello.b.a; +}
reply other threads:[~2021-07-18 23:28 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=20210718232841.3F3B6385BC23@sourceware.org \ --to=jakub@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).