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 r12-8196] c++: Fix up CONSTRUCTOR_PLACEHOLDER_BOUNDARY handling [PR105256] Date: Tue, 19 Apr 2022 16:28:29 +0000 (GMT) [thread overview] Message-ID: <20220419162829.E82323858C83@sourceware.org> (raw) https://gcc.gnu.org/g:eb03e424598d30fed68801af6d6ef6236d32e32e commit r12-8196-geb03e424598d30fed68801af6d6ef6236d32e32e Author: Jakub Jelinek <jakub@redhat.com> Date: Tue Apr 19 18:27:41 2022 +0200 c++: Fix up CONSTRUCTOR_PLACEHOLDER_BOUNDARY handling [PR105256] The CONSTRUCTOR_PLACEHOLDER_BOUNDARY bit is supposed to separate PLACEHOLDER_EXPRs that should be replaced by one object or subobjects of it (variable, TARGET_EXPR slot, ...) from other PLACEHOLDER_EXPRs that should be replaced by different objects or subobjects. The bit is set when finding PLACEHOLDER_EXPRs inside of a CONSTRUCTOR, not looking into nested CONSTRUCTOR_PLACEHOLDER_BOUNDARY ctors, and we prevent elision of TARGET_EXPRs (through TARGET_EXPR_NO_ELIDE) whose initializer is a CONSTRUCTOR_PLACEHOLDER_BOUNDARY ctor. The following testcase ICEs though, we don't replace the placeholders in there at all, because CONSTRUCTOR_PLACEHOLDER_BOUNDARY isn't set on the TARGET_EXPR_INITIAL ctor, but on a ctor nested in such a ctor. replace_placeholders should be run on the whole TARGET_EXPR slot. So, the following patch fixes it by moving the CONSTRUCTOR_PLACEHOLDER_BOUNDARY bit from nested CONSTRUCTORs to the CONSTRUCTOR containing those (but only if it is closely nested, if there is some other tree sandwiched in between, it doesn't do it). 2022-04-19 Jakub Jelinek <jakub@redhat.com> PR c++/105256 * typeck2.cc (process_init_constructor_array, process_init_constructor_record, process_init_constructor_union): Move CONSTRUCTOR_PLACEHOLDER_BOUNDARY flag from CONSTRUCTOR elements to the containing CONSTRUCTOR. * g++.dg/cpp0x/pr105256.C: New test. Diff: --- gcc/cp/typeck2.cc | 31 +++++++++++++++++++++++++++++++ gcc/testsuite/g++.dg/cpp0x/pr105256.C | 18 ++++++++++++++++++ 2 files changed, 49 insertions(+) diff --git a/gcc/cp/typeck2.cc b/gcc/cp/typeck2.cc index 23ed81ec063..63d95c1529a 100644 --- a/gcc/cp/typeck2.cc +++ b/gcc/cp/typeck2.cc @@ -1515,6 +1515,14 @@ process_init_constructor_array (tree type, tree init, int nested, int flags, strip_array_types (TREE_TYPE (ce->value))))); picflags |= picflag_from_initializer (ce->value); + /* Propagate CONSTRUCTOR_PLACEHOLDER_BOUNDARY to outer + CONSTRUCTOR. */ + if (TREE_CODE (ce->value) == CONSTRUCTOR + && CONSTRUCTOR_PLACEHOLDER_BOUNDARY (ce->value)) + { + CONSTRUCTOR_PLACEHOLDER_BOUNDARY (init) = 1; + CONSTRUCTOR_PLACEHOLDER_BOUNDARY (ce->value) = 0; + } } /* No more initializers. If the array is unbounded, we are done. Otherwise, @@ -1560,6 +1568,14 @@ process_init_constructor_array (tree type, tree init, int nested, int flags, } picflags |= picflag_from_initializer (next); + /* Propagate CONSTRUCTOR_PLACEHOLDER_BOUNDARY to outer + CONSTRUCTOR. */ + if (TREE_CODE (next) == CONSTRUCTOR + && CONSTRUCTOR_PLACEHOLDER_BOUNDARY (next)) + { + CONSTRUCTOR_PLACEHOLDER_BOUNDARY (init) = 1; + CONSTRUCTOR_PLACEHOLDER_BOUNDARY (next) = 0; + } if (len > i+1) { tree range = build2 (RANGE_EXPR, size_type_node, @@ -1754,6 +1770,13 @@ process_init_constructor_record (tree type, tree init, int nested, int flags, if (fldtype != TREE_TYPE (field)) next = cp_convert_and_check (TREE_TYPE (field), next, complain); picflags |= picflag_from_initializer (next); + /* Propagate CONSTRUCTOR_PLACEHOLDER_BOUNDARY to outer CONSTRUCTOR. */ + if (TREE_CODE (next) == CONSTRUCTOR + && CONSTRUCTOR_PLACEHOLDER_BOUNDARY (next)) + { + CONSTRUCTOR_PLACEHOLDER_BOUNDARY (init) = 1; + CONSTRUCTOR_PLACEHOLDER_BOUNDARY (next) = 0; + } CONSTRUCTOR_APPEND_ELT (v, field, next); } @@ -1894,6 +1917,14 @@ process_init_constructor_union (tree type, tree init, int nested, int flags, ce->value = massage_init_elt (TREE_TYPE (ce->index), ce->value, nested, flags, complain); + /* Propagate CONSTRUCTOR_PLACEHOLDER_BOUNDARY to outer CONSTRUCTOR. */ + if (ce->value + && TREE_CODE (ce->value) == CONSTRUCTOR + && CONSTRUCTOR_PLACEHOLDER_BOUNDARY (ce->value)) + { + CONSTRUCTOR_PLACEHOLDER_BOUNDARY (init) = 1; + CONSTRUCTOR_PLACEHOLDER_BOUNDARY (ce->value) = 0; + } return picflag_from_initializer (ce->value); } diff --git a/gcc/testsuite/g++.dg/cpp0x/pr105256.C b/gcc/testsuite/g++.dg/cpp0x/pr105256.C new file mode 100644 index 00000000000..98ce5e8b7bf --- /dev/null +++ b/gcc/testsuite/g++.dg/cpp0x/pr105256.C @@ -0,0 +1,18 @@ +// PR c++/105256 +// { dg-do compile { target c++11 } } + +int bar (int &); + +struct S { + struct T { + struct U { + int i = bar (i); + } u; + }; +}; + +void +foo (S::T *p) +{ + *p = {}; +};
reply other threads:[~2022-04-19 16: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=20220419162829.E82323858C83@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).