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 r13-3528] c++: Fix ICE on g++.dg/modules/adl-3_c.C [PR107379] Date: Thu, 27 Oct 2022 18:10:54 +0000 (GMT) [thread overview] Message-ID: <20221027181103.6E0DC384BC20@sourceware.org> (raw) https://gcc.gnu.org/g:a33d623d2d3a78f5ef6f9e854946303e063eef63 commit r13-3528-ga33d623d2d3a78f5ef6f9e854946303e063eef63 Author: Jakub Jelinek <jakub@redhat.com> Date: Thu Oct 27 20:10:18 2022 +0200 c++: Fix ICE on g++.dg/modules/adl-3_c.C [PR107379] As mentioned in the PR, apparently my r13-2887 P1467R9 changes regressed these tests on powerpc64le-linux with IEEE quad by default. I believe my changes just uncovered a latent bug. The problem is that push_namespace calls find_namespace_slot, which does: tree *slot = DECL_NAMESPACE_BINDINGS (ns) ->find_slot_with_hash (name, name ? IDENTIFIER_HASH_VALUE (name) : 0, create_p ? INSERT : NO_INSERT); In the <identifier_node 0x7fffe9f55ac0 details> ns case, slot is non-NULL above with a binding_vector in it. Then pushdecl is called and this does: slot = find_namespace_slot (ns, name, ns == current_namespace); where ns == current_namespace (ns is :: and name is details) is true. So this again calls tree *slot = DECL_NAMESPACE_BINDINGS (ns) ->find_slot_with_hash (name, name ? IDENTIFIER_HASH_VALUE (name) : 0, create_p ? INSERT : NO_INSERT); but this time with create_p and so INSERT. At this point we reach if (insert == INSERT && m_size * 3 <= m_n_elements * 4) expand (); and when we are unlucky and the occupancy of the hash table just reached 3/4, expand () is called and the hash table is reallocated. But when that happens, it means the slot pointer in the pushdecl caller (push_namespace) points to freed memory and so any accesses to it in make_namespace_finish will be UB. The following patch fixes it by calling find_namespace_slot again even if it was non-NULL, just doesn't assert it is *slot == ns in that case (because it often is not). 2022-10-27 Jakub Jelinek <jakub@redhat.com> PR c++/107379 * name-lookup.cc (push_namespace): Call find_namespace_slot again after pushdecl as the hash table might be expanded during pushdecl. Diff: --- gcc/cp/name-lookup.cc | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/gcc/cp/name-lookup.cc b/gcc/cp/name-lookup.cc index 14e937d81cb..dfa6fb40675 100644 --- a/gcc/cp/name-lookup.cc +++ b/gcc/cp/name-lookup.cc @@ -8596,6 +8596,13 @@ push_namespace (tree name, bool make_inline) /* This should find the slot created by pushdecl. */ gcc_checking_assert (slot && *slot == ns); } + else + { + /* pushdecl could have expanded the hash table, so + slot might be invalid. */ + slot = find_namespace_slot (current_namespace, name); + gcc_checking_assert (slot); + } make_namespace_finish (ns, slot); /* Add the anon using-directive here, we don't do it in
reply other threads:[~2022-10-27 18:10 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=20221027181103.6E0DC384BC20@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).