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++/102548] [9/10/11/12 Regression] ICE with cdecl attribute on a builtin function since r7-4737-g48330c9355e32a41 Date: Tue, 05 Oct 2021 20:29:11 +0000 [thread overview] Message-ID: <bug-102548-4-tE5sb5qbGb@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-102548-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102548 --- Comment #7 from CVS 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:737f95bab557584d876f02779ab79fe3cfaacacf commit r12-4198-g737f95bab557584d876f02779ab79fe3cfaacacf Author: Jakub Jelinek <jakub@redhat.com> Date: Tue Oct 5 22:28:38 2021 +0200 c++: Fix apply_identity_attributes [PR102548] The following testcase ICEs on x86_64-linux with -m32 due to a bug in apply_identity_attributes. The function is being smart and attempts not to duplicate the chain unnecessarily, if either there are no attributes that affect type identity or there is possibly empty set of attributes that do not affect type identity in the chain followed by attributes that do affect type identity, it reuses that attribute chain. The function mishandles the cases where in the chain an attribute affects type identity and is followed by one or more attributes that don't affect type identity (and then perhaps some further ones that do). There are two bugs. One is that when we notice first attribute that doesn't affect type identity after first attribute that does affect type identity (with perhaps some further such attributes in the chain after it), we want to put into the new chain just attributes starting from (inclusive) first_ident and up to (exclusive) the current attribute a, but the code puts into the chain all attributes starting with first_ident, including the ones that do not affect type identity and if e.g. we have doesn't0 affects1 doesn't2 affects3 affects4 sequence of attributes, the resulting sequence would have affects1 doesn't2 affects3 affects4 affects3 affects4 attributes, i.e. one attribute that shouldn't be there and two attributes duplicated. That is fixed by the a2 -> a2 != a change. The second one is that we ICE once we see second attribute that doesn't affect type identity after an attribute that affects it. That is because first_ident is set to error_mark_node after handling the first attribute that doesn't affect type identity (i.e. after we've copied the [first_ident, a) set of attributes to the new chain) to denote that from that time on, each attribute that affects type identity should be copied whenever it is seen (the if (as && as->affects_type_identity) code does that correctly). But that condition is false and first_ident is error_mark_node, we enter else if (first_ident) and use TREE_PURPOSE /TREE_VALUE/TREE_CHAIN on error_mark_node, which ICEs. When first_ident is error_mark_node and a doesn't affect type identity, we want to do nothing. So that is the && first_ident != error_mark_node chunk. 2021-10-05 Jakub Jelinek <jakub@redhat.com> PR c++/102548 * tree.c (apply_identity_attributes): Fix handling of the case where an attribute in the list doesn't affect type identity but some attribute before it does. * g++.target/i386/pr102548.C: New test.
next prev parent reply other threads:[~2021-10-05 20:29 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-09-30 18:20 [Bug c++/102548] New: gcc segmentation fault in cc1plus (with repro case) ulatekh at yahoo dot com 2021-09-30 22:13 ` [Bug c++/102548] " pinskia at gcc dot gnu.org 2021-09-30 22:16 ` mpolacek at gcc dot gnu.org 2021-09-30 22:18 ` pinskia at gcc dot gnu.org 2021-09-30 22:45 ` [Bug c++/102548] [9/10/11/12 Regression] ICE with cdecl attribute on a builtin function pinskia at gcc dot gnu.org 2021-10-01 6:31 ` rguenth at gcc dot gnu.org 2021-10-01 8:43 ` [Bug c++/102548] [9/10/11/12 Regression] ICE with cdecl attribute on a builtin function since r7-4737-g48330c9355e32a41 marxin at gcc dot gnu.org 2021-10-04 18:39 ` jakub at gcc dot gnu.org 2021-10-05 20:29 ` cvs-commit at gcc dot gnu.org [this message] 2021-10-05 20:31 ` cvs-commit at gcc dot gnu.org 2021-10-05 21:09 ` [Bug c++/102548] [9/10 " jakub at gcc dot gnu.org 2021-10-05 22:20 ` ulatekh at yahoo dot com 2022-05-10 8:21 ` cvs-commit at gcc dot gnu.org 2022-05-11 6:22 ` cvs-commit at gcc dot gnu.org 2022-05-11 6:36 ` jakub 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-102548-4-tE5sb5qbGb@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).