From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 464A6395B071; Wed, 16 Nov 2022 14:41:41 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 464A6395B071 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1668609701; bh=r6WKXSG9qXDleO+UzEj6MZeHKCv0hSUWJbHk1bieqTE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=WztIkxWTh590vUlZhJw2Vh/AjDjN7zcEnKbxEIiWXeyS3lm5BnOkbqPmNJJ9Mik2n 3iFJAlQLD74h0jZFgfz8avlAIICGZ7u+JC87PXZbCLAQDiU/Z+OibzpeUsjawS+58X 6uJX1Jr7wLdPuUK9YsVb1XN7dU5B4dwX5R/ivG9w= From: "dmalcolm at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug analyzer/107711] internal compiler error: Segmentation fault Date: Wed, 16 Nov 2022 14:41:40 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: analyzer X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: dmalcolm at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: dmalcolm at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D107711 --- Comment #1 from David Malcolm --- Thanks for filing this bug report. Unfortunately I can't reproduce the ICE with the attachment. I have a suspicion that this relates to commits r13-4073-gd8aba860b34203 an= d/or r13-4074-g86a90006864840 and that it relates to accessing preprocessor macr= os for named constants relating to file descriptors. To confirm this hypothesis, does the crash go away if you first use -E to r= un the preprocessor on its own, and then use -fanalyzer on the preprocessed source? (with the same other options as before) (I'd hoped that we could look at the analyzer dump file to confirm this, but unfortunately the code in question runs before the analyzer's logging code starts up)=