From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id A3DA738582AF; Tue, 30 Jan 2024 14:38:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A3DA738582AF DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1706625488; bh=RMHy5KoRRhyIIJwr70r1VGKbOPmDlwrdn2uR6Tr5CUE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=r+0c4E1YidGvezv9WQ0jl4CkHzoJ+Smk1Ao5GUjlvZfTlOmqsztHqnFo1u/o668YK zVQqIhET7OEwamIzrXZa8loLrmYJRyI1EtdHjepUD1B6ZZvpBAw3vozFqhRF/7If/b GOS+sRkLr4doN1QKblVIJkGVTKSJmlVTM5LbwJh4= 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 14:38:06 +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 #11 from Lewis Hyatt --- Oh interesting. So the purpose of this test was just to record that GCC out= puts incorrect locations for this case, I wanted to xfail it and then fix it properly for GCC 15. I did not consider that it might output different wrong locations for different platforms, but I could buy that it may happen, for a similar reason why this switched from being silently broken to ICEing since r11-338 which was seemingly unrelated. It seems like in one case the wrong location is inside the header file and in the other case, the wrong locatio= n is the line just following the include. It may have to do with line endings or some other issue with the treatment of EOF? If this test is causing problem= s we could just skip it on some architectures maybe? Once the underlying issue is fixed, the location (line 2 of the .C file) will be correct everywhere. I am curious why it gets a different wrong output though, if there is a compile = farm machine with this architecture I could look into it.=