public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c/114931] [14/15 regression] ICE in get_alias_set when building tcl with -std=c23 Date: Fri, 03 May 2024 09:01:04 +0000 [thread overview] Message-ID: <bug-114931-4-VDG5hr8TVx@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-114931-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114931 --- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #12) > Anyway, such changes are a partial shift towards the model to update derived > types which you said you don't want; it doesn't actually update them, but > basically forces new types after the base type(s) is/are finalized. Yes, I was wondering if when we make TYPE_STRUCTURAL_EQUALITY_P part of the hash we're papering over the issue that we have recorded equal types we didn't mark for structural compare. Though that would only be a missed optimization I think (setting TYPE_STRUCTURAL_EQUALITY_P is). > Another possibility might be simply in all the spots where we set > TYPE_CANONICAL (t) = something; to add if (TYPE_STRUCTURAL_EQUALITY_P > (TYPE_CANONICAL (t))) SET_TYPE_STRUCTURAL_EQUALITY (t); But if TYPE_STRUCTURAL_EQUALITY_P (TYPE_CANONICAL (t)) then that canonical type is broken. We should avoid (at all cost) creating such a type. > On the build_function_type it could be > --- gcc/tree.cc.jj 2024-04-16 09:56:16.463008446 +0200 > +++ gcc/tree.cc 2024-05-03 10:21:04.119086667 +0200 > @@ -7511,17 +7511,25 @@ build_function_type (tree value_type, tr > hashval_t hash = type_hash_canon_hash (t); > t = type_hash_canon (hash, t); > > - /* Set up the canonical type. */ > - any_structural_p = TYPE_STRUCTURAL_EQUALITY_P (value_type); > - any_noncanonical_p = TYPE_CANONICAL (value_type) != value_type; > - canon_argtypes = maybe_canonicalize_argtypes (arg_types, > - &any_structural_p, > - &any_noncanonical_p); > - if (any_structural_p) > - SET_TYPE_STRUCTURAL_EQUALITY (t); > - else if (any_noncanonical_p) > - TYPE_CANONICAL (t) = build_function_type (TYPE_CANONICAL (value_type), > - canon_argtypes); > + if (TYPE_CANONICAL (t) == t) > + { > + /* Set up the canonical type. */ > + any_structural_p = TYPE_STRUCTURAL_EQUALITY_P (value_type); > + any_noncanonical_p = TYPE_CANONICAL (value_type) != value_type; > + canon_argtypes = maybe_canonicalize_argtypes (arg_types, > + &any_structural_p, > + &any_noncanonical_p); > + if (any_structural_p) > + SET_TYPE_STRUCTURAL_EQUALITY (t); > + else if (any_noncanonical_p) > + { > + TYPE_CANONICAL (t) > + = build_function_type (TYPE_CANONICAL (value_type), > + canon_argtypes); we shouldn't get a structual equality type here when !any_structural_p Yes, ensuring this within type_hash_canon only papers over the issue in different ways (to some extent). But this is how things are. I guess another option might be to have the FE set TYPE_STRUCTURAL_EQUALITY_P on _all_ types that possibly get "finalized" only later and have a second sweep over all those types after the unit is finished and recompute TYPE_CANONICAL there, making sure to catch all derived types. Like LTO re-computes TYPE_CANONICAL. > + if (TYPE_STRUCTURAL_EQUALITY_P (TYPE_CANONICAL (t))) > + SET_TYPE_STRUCTURAL_EQUALITY (t); > + } > + } > > if (!COMPLETE_TYPE_P (t)) > layout_type (t);
next prev parent reply other threads:[~2024-05-03 9:01 UTC|newest] Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-05-03 2:37 [Bug rtl-optimization/114931] New: " sjames at gcc dot gnu.org 2024-05-03 2:38 ` [Bug rtl-optimization/114931] " sjames at gcc dot gnu.org 2024-05-03 2:43 ` [Bug c/114931] " pinskia at gcc dot gnu.org 2024-05-03 2:52 ` pinskia at gcc dot gnu.org 2024-05-03 3:10 ` sjames at gcc dot gnu.org 2024-05-03 6:34 ` [Bug c/114931] [14/15 regression] " rguenth at gcc dot gnu.org 2024-05-03 7:11 ` rguenth at gcc dot gnu.org 2024-05-03 7:16 ` rguenth at gcc dot gnu.org 2024-05-03 7:25 ` rguenth at gcc dot gnu.org 2024-05-03 7:41 ` jakub at gcc dot gnu.org 2024-05-03 7:56 ` rguenth at gcc dot gnu.org 2024-05-03 8:22 ` rguenth at gcc dot gnu.org 2024-05-03 8:25 ` jakub at gcc dot gnu.org 2024-05-03 9:01 ` rguenth at gcc dot gnu.org [this message] 2024-05-03 9:05 ` rguenth at gcc dot gnu.org 2024-05-03 9:50 ` rguenth at gcc dot gnu.org 2024-05-03 11:01 ` cvs-commit at gcc dot gnu.org 2024-05-07 7:46 ` rguenth at gcc dot gnu.org 2024-05-07 11:05 ` cvs-commit at gcc dot gnu.org 2024-05-07 11:07 ` [Bug c/114931] [14 " rguenth at gcc dot gnu.org 2024-05-07 12:30 ` rguenth at gcc dot gnu.org 2024-05-07 18:10 ` sjames at gcc dot gnu.org 2024-05-15 16:09 ` cvs-commit at gcc dot gnu.org 2024-05-15 16:09 ` cvs-commit at gcc dot gnu.org 2024-05-15 16:09 ` 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-114931-4-VDG5hr8TVx@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).