From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 8841738582B7; Tue, 30 Jan 2024 22:05:45 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8841738582B7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1706652345; bh=vM9TdwsA4z/eJJ9pcnWDRyCw1nS6X3x1GCW2wakyBiE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=DsDHOGKHQ+FA6csg9TrmZkFYh6CwSo9Mtq14V+F2cV8h4P4Rmo44/ClbJDPdB5ISL ViclNpdCgVRcyeva9yLNnxlDRc+JbsWUpeauzSgH1/pGfV9bZHmuvWf3bM0JVbRwRW KqLsZsBCB4fvuYLjMzTSqN0IIS2fNYvBkNWIbyu4= From: "lhyatt at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug preprocessor/105608] [11/12/13/14 Regression] ICE: in linemap_add with a really long defined macro on the command line r11-338-g2a0225e47868fbfc Date: Tue, 30 Jan 2024 22:05:44 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: preprocessor X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: patch X-Bugzilla-Severity: normal X-Bugzilla-Who: lhyatt at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 11.5 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=3D105608 --- Comment #13 from Lewis Hyatt --- I think I understand why it is platform dependent. The location being assig= ned to the restored macros is pfile->directive_line, which was stored relative = to the original line map instance, before replacing it with the one from the P= CH. So looking that location up in the new line_maps instance produces some val= ue that is dependent on exactly what was stored in the old and new line maps. = In particular it will depend on stuff that was included internally such as /usr/include/stdc-predef.h. The output with -fdump-internal-locations would confirm it, but I am not sure it's too important to understand all the ways that this location is wrong, since it needs to just get fixed regardless... it's not even trying to be correct right now. This patch in libcpp would stabilize the output to be the same on all platforms: =3D=3D=3D=3D=3D diff --git a/libcpp/pch.cc b/libcpp/pch.cc index e156fe257b3..08df0f8a86d 100644 --- a/libcpp/pch.cc +++ b/libcpp/pch.cc @@ -838,7 +838,7 @@ cpp_read_state (cpp_reader *r, const char *name, FILE *= f, !=3D NULL) { _cpp_clean_line (r); - if (!_cpp_create_definition (r, h, 0)) + if (!_cpp_create_definition (r, h, r->line_table->highest_lin= e)) abort (); _cpp_pop_buffer (r); } =3D=3D=3D=3D=3D It would change the location to be always line 3 in the source file, matchi= ng the "wrong" result you get now on i386-pc-solaris2.11 . The test case would need adjustment to match. I am going to ask if it can be approved for GCC 1= 4, I think it is worth it to not use an unpredictable location here.=