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/97172] [11 Regression] ICE: tree code ‘ssa_name’ is not supported in LTO streams since r11-3303-g6450f07388f9fe57 Date: Tue, 01 Dec 2020 07:42:21 +0000 [thread overview] Message-ID: <bug-97172-4-NbVgUpJTcy@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-97172-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97172 --- Comment #17 from Richard Biener <rguenth at gcc dot gnu.org> --- Well - you're the first to add nontrivial (non-constant) trees to attributes. In GIMPLE all effects are supposed to be reflected in the IL and thus things like variable TYPE_SIZE or TYPE_MIN/MAX_VALUE are actually gimplified with code generated during that inserted at the respective DECL_EXPR (which is where gimplification is triggered from for the types). Honestly I am not sure what you think you can do with arbitrary expressions in an attribute down the GIMPLE pipeline given there's no connection to actual variable values. That said, the idea of sticking this additional information in attributes in form of some random plain tree expressions doesn't work. You'd have to sanitize them at least if, say, expressions based purely on other formal function arguments is what you are after. That would for example be done by unsharing the expressions without locations which you could try. But for example the PR97133 case, attributes <tree_list 0x7fffea94d8e8 purpose <identifier_node 0x7fffea937910 arg spec> value <tree_list 0x7fffea94d898 value <string_cst 0x7fffea936860 constant "[$]\000"> chain <tree_list 0x7fffea94d870 value <eq_expr 0x7fffea94d758 type <integer_type 0x7fffea8105e8 int> side-effects arg:0 <c_maybe_const_expr 0x7fffea94d730 type <pointer_type 0x7fffea930c78> side-effects arg:0 <compound_expr 0x7fffea94d708 type <void_type 0x7fffea810f18 void> side-effects arg:1 <bind_expr 0x7fffea949330>> arg:1 <compound_literal_expr 0x7fffea936780 type <pointer_type 0x7fffea930c78> side-effects arg:0 <decl_expr 0x7fffea936760>>> arg:1 <integer_cst 0x7fffea94f030 constant 0> certainly is missing constant evaluation (I can bet whatever is supposed to consume the access attributes gives up on the above anyway). C_MAYBE_CONST_EXPR is a frontend specific tree code and thus it shouldn't even survive GENERICization. So I would stronly suggest to revisit the way you try to record "every information for accesses" for GCC 12 and for GCC 11 restrict the information to CONSTANT_CLASS_P trees.
next prev parent reply other threads:[~2020-12-01 7:42 UTC|newest] Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-09-23 7:25 [Bug c/97172] New: " marxin at gcc dot gnu.org 2020-09-23 7:25 ` [Bug c/97172] " marxin at gcc dot gnu.org 2020-09-23 8:02 ` rguenth at gcc dot gnu.org 2020-09-23 23:00 ` msebor at gcc dot gnu.org 2020-10-01 13:46 ` hubicka at gcc dot gnu.org 2020-10-01 15:36 ` msebor at gcc dot gnu.org 2020-10-01 15:39 ` msebor at gcc dot gnu.org 2020-10-05 20:18 ` msebor at gcc dot gnu.org 2020-10-12 11:48 ` rguenth at gcc dot gnu.org 2020-10-15 15:10 ` marxin at gcc dot gnu.org 2020-10-18 16:42 ` hubicka at gcc dot gnu.org 2020-10-18 17:55 ` msebor at gcc dot gnu.org 2020-10-18 19:58 ` hubicka at ucw dot cz 2020-11-10 9:02 ` marxin at gcc dot gnu.org 2020-11-30 15:00 ` rguenth at gcc dot gnu.org 2020-11-30 15:29 ` msebor at gcc dot gnu.org 2020-11-30 17:32 ` msebor at gcc dot gnu.org 2020-11-30 21:02 ` hubicka at ucw dot cz 2020-12-01 1:11 ` msebor at gcc dot gnu.org 2020-12-01 7:42 ` rguenth at gcc dot gnu.org [this message] 2020-12-01 16:12 ` msebor at gcc dot gnu.org 2020-12-01 16:16 ` Jan Hubicka 2020-12-01 16:16 ` hubicka at ucw dot cz 2020-12-02 7:38 ` rguenther at suse dot de 2020-12-18 12:58 ` marxin at gcc dot gnu.org 2020-12-18 17:02 ` msebor at gcc dot gnu.org 2020-12-19 0:55 ` msebor at gcc dot gnu.org 2021-01-22 9:05 ` ktkachov at gcc dot gnu.org 2021-01-26 18:57 ` jakub at gcc dot gnu.org 2021-01-27 22:51 ` msebor at gcc dot gnu.org 2021-02-01 16:10 ` cvs-commit at gcc dot gnu.org 2021-02-01 16:12 ` msebor at gcc dot gnu.org 2021-02-19 2:28 ` msebor at gcc dot gnu.org 2021-02-19 18:07 ` cvs-commit at gcc dot gnu.org 2021-02-23 14:38 ` marxin at gcc dot gnu.org 2021-02-23 14:49 ` rguenth at gcc dot gnu.org 2021-02-23 17:16 ` msebor at gcc dot gnu.org 2021-02-23 19:20 ` msebor at gcc dot gnu.org 2021-02-24 15:59 ` cvs-commit at gcc dot gnu.org 2021-02-24 16:01 ` msebor at gcc dot gnu.org 2021-02-25 16:03 ` cvs-commit 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-97172-4-NbVgUpJTcy@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).