public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/96901] [11 Regression] Many libstdc++ tests FAIL on i686-linux due to a PCH FE bug Date: Fri, 11 Sep 2020 07:47:50 +0000 [thread overview] Message-ID: <bug-96901-4-wXHZgQBNiJ@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-96901-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96901 --- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-10 branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:3dfe983656318c1aaa33c7f9a5a341c5904aa5b6 commit r10-8732-g3dfe983656318c1aaa33c7f9a5a341c5904aa5b6 Author: Jakub Jelinek <jakub@redhat.com> Date: Thu Sep 3 21:53:40 2020 +0200 c++: Fix another PCH hash_map issue [PR96901] The recent libstdc++ changes caused lots of libstdc++-v3 tests FAILs on i686-linux, all of them in the same spot during constexpr evaluation of a recursive _S_gcd call. The problem is yet another hash_map that used the default hasing of tree keys through pointer hashing which is preserved across PCH write/read. During PCH handling, the addresses of GC objects are changed, which means that the hash values of the keys in such hash tables change without those hash tables being rehashed. Which in the fundef_copies_table case usually means we just don't find a copy of a FUNCTION_DECL body for recursive uses and start from scratch. But when the hash table keeps growing, the "dead" elements in the hash table can sometimes reappear and break things. In particular what I saw under the debugger is when the fundef_copies_table hash map has been used on the outer _S_gcd call, it didn't find an entry for it, so returned a slot with *slot == NULL, which is treated as that the function itself is used directly (i.e. no recursion), but that addition of a hash table slot caused the recursive _S_gcd call to actually find something in the hash table, unfortunately not the new *slot == NULL spot, but a different one from the pre-PCH streaming which contained the returned toplevel (non-recursive) call entry for it, which means that for the recursive _S_gcd call we actually used the same trees as for the outer ones rather than a copy of those, which breaks constexpr evaluation. 2020-09-03 Jakub Jelinek <jakub@redhat.com> PR c++/96901 * tree.h (struct decl_tree_traits): New type. (decl_tree_map): New typedef. * constexpr.c (fundef_copies_table): Change type from hash_map<tree, tree> * to decl_tree_map *. (cherry picked from commit ba6730bd18371a3dff1e37d2c2ee27233285b597)
next prev parent reply other threads:[~2020-09-11 7:47 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-09-02 16:51 [Bug c++/96901] New: " jakub at gcc dot gnu.org 2020-09-02 16:52 ` [Bug c++/96901] " jakub at gcc dot gnu.org 2020-09-02 16:57 ` jakub at gcc dot gnu.org 2020-09-03 19:54 ` cvs-commit at gcc dot gnu.org 2020-09-11 7:47 ` cvs-commit at gcc dot gnu.org [this message] 2020-10-16 12:07 ` rguenth at gcc dot gnu.org
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=bug-96901-4-wXHZgQBNiJ@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@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).