From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 1688D3858C60; Mon, 24 Jan 2022 09:20:27 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1688D3858C60 From: "cvs-commit at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/103587] [10/11 Regression] ICE in c_parser_consume_token, at c/c-parser.c:850 since r10-4633-g4e03c3a7c1149a8e Date: Mon, 24 Jan 2022 09:20:26 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: 12.0 X-Bugzilla-Keywords: ice-on-invalid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: cvs-commit at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org X-Bugzilla-Target-Milestone: 10.4 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2022 09:20:27 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D103587 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:c239267759be2cf3e1afadea86aff5ba3517d934 commit r11-9490-gc239267759be2cf3e1afadea86aff5ba3517d934 Author: Jakub Jelinek Date: Tue Dec 14 12:02:55 2021 +0100 c: Fix ICE on deferred pragma in unknown attribute arguments [PR103587] We ICE on the following testcase, because c_parser_balanced_token_seque= nce when encountering a deferred pragma will just use c_parser_consume_token which the FE doesn't allow for CPP_PRAGMA tokens (and if that wasn't the case, it could ICE on CPP_PRAGMA_EOL similarly). We don't know in what exact context the pragma appears when we don't know what those arguments semantically mean, so I think we should just skip over them, like e.g. the C++ FE does. And, I think (/[/{ vs. )/]/} from outside of the pragma shouldn't be paired with those inside of the pragma and it doesn't seem to be necessary to check that inside of the pragma line itself all the paren kinds are balanced. 2021-12-14 Jakub Jelinek PR c/103587 * c-parser.c (c_parser_balanced_token_sequence): For CPP_PRAGMA, consume the pragma and silently skip to the pragma eol. * gcc.dg/pr103587.c: New test. (cherry picked from commit e163dbbc4433e598cad7e6011b255d1d6ad93a3b)=