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/114930] [14/15 regression] ICE in fld_incomplete_type_of when building libwebp with -std=c23 -flto Date: Tue, 25 Jun 2024 06:37:48 +0000 [thread overview] Message-ID: <bug-114930-4-kbH9mfukvO@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-114930-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114930 --- Comment #8 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:777cc6a01d1cf783a36d0fa67ab20f0312f35d7a commit r15-1597-g777cc6a01d1cf783a36d0fa67ab20f0312f35d7a Author: Jakub Jelinek <jakub@redhat.com> Date: Tue Jun 25 08:35:56 2024 +0200 c: Fix ICE related to incomplete structures in C23 [PR114930] Here is a version of the c_update_type_canonical fixes which passed bootstrap/regtest. The non-trivial part is the handling of the case when build_qualified_type (TYPE_CANONICAL (t), TYPE_QUALS (x)) returns a type with NULL TYPE_CANONICAL. That should happen only if TYPE_CANONICAL (t) == t, because otherwise c_update_type_canonical should have been already called on the other type. c, the returned type, is usually x and in that case it should have TYPE_CANONICAL set to itself, or worst for whatever reason x is not the right canonical type (say it has attributes or whatever disqualifies it from check_qualified_type). In that case either it finds some pre-existing type from the variant chain of t which is later in the chain and we haven't processed it yet (but then get_qualified_type moves it right after t in: /* Put the found variant at the head of the variant list so frequently searched variants get found faster. The C++ FE benefits greatly from this. */ tree t = *tp; *tp = TYPE_NEXT_VARIANT (t); TYPE_NEXT_VARIANT (t) = TYPE_NEXT_VARIANT (mv); TYPE_NEXT_VARIANT (mv) = t; return t; optimization), or creates a fresh new type using build_variant_type_copy, which again places the new type right after t: /* Add the new type to the chain of variants of TYPE. */ TYPE_NEXT_VARIANT (t) = TYPE_NEXT_VARIANT (m); TYPE_NEXT_VARIANT (m) = t; TYPE_MAIN_VARIANT (t) = m; At this point we want to make c its own canonical type (i.e. TYPE_CANONICAL (c) = c;), but also need to process pointers to it and only then return back to processing x. Processing the whole chain from c again could be costly, we could have hundreds of types in the chain already processed, and while the loop would just quickly skip them for (tree x = t, l = NULL_TREE; x; l = x, x = TYPE_NEXT_VARIANT (x)) { if (x != t && TYPE_STRUCTURAL_EQUALITY_P (x)) ... else if (x != t) continue; it feels costly. So, this patch instead moves c from right after t to right before x in the chain (that shouldn't change anything, because clearly build_qualified_type didn't find any matches in the chain before x) and continues processing the c at that position, so should handle the x that encountered this in the next iteration. We could avoid some of the moving in the chain if we processed the chain twice, once deal only with x != t && TYPE_STRUCTURAL_EQUALITY_P (x) && TYPE_CANONICAL (t) == t && check_qualified_type (t, x, TYPE_QUALS (x)) types (in that case set TYPE_CANONICAL (x) = x) and once the rest. There is still the theoretical case where build_qualified_type would return a new type and in that case we are back to the moving the type around and needing to handle it though. 2024-06-25 Jakub Jelinek <jakub@redhat.com> Martin Uecker <uecker@tugraz.at> PR c/114930 PR c/115502 gcc/c/ * c-decl.cc (c_update_type_canonical): Assert t is main variant with 0 TYPE_QUALS. Simplify and don't use check_qualified_type. Deal with the case where build_qualified_type returns TYPE_STRUCTURAL_EQUALITY_P type. gcc/testsuite/ * gcc.dg/pr114574-1.c: Require lto effective target. * gcc.dg/pr114574-2.c: Likewise. * gcc.dg/pr114930.c: New test. * gcc.dg/pr115502.c: New test.
prev parent reply other threads:[~2024-06-25 6:37 UTC|newest] Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-05-03 1:19 [Bug ipa/114930] New: " sjames at gcc dot gnu.org 2024-05-03 1:40 ` [Bug ipa/114930] " sjames at gcc dot gnu.org 2024-05-03 1:41 ` pinskia at gcc dot gnu.org 2024-05-03 2:55 ` [Bug ipa/114930] [14/15 regression] " sjames at gcc dot gnu.org 2024-05-03 6:32 ` rguenth at gcc dot gnu.org 2024-05-07 7:46 ` rguenth at gcc dot gnu.org 2024-05-18 15:44 ` sjames at gcc dot gnu.org 2024-05-21 8:50 ` rguenth at gcc dot gnu.org 2024-06-02 10:16 ` [Bug c/114930] " uecker at gcc dot gnu.org 2024-06-12 14:25 ` sjames at gcc dot gnu.org 2024-06-25 6:37 ` cvs-commit at gcc dot gnu.org [this message]
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-114930-4-kbH9mfukvO@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).