From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id D3526385828A; Tue, 30 Jan 2024 14:54:31 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D3526385828A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1706626471; bh=W2iqxbUQ+YIMhTZYCglKQQjE6+2WAl2DSCAodTYhDYw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=uAnhvrSu3hHzn7eLgY3xseQtHU+kCPia/DUrG1Sw5+bfhPqAuW7BnAX85LP8N6w3M XtpVNwQzV5fLVJcxa/83RdrDamPei14YuXS3V2sRy/3hrqY8ZdiOZWSwxs1bJ6gsT0 YXLnFym75BVzC8USF/hDGBV3JOavNKjbEUKSXW20= From: "ro at CeBiTec dot Uni-Bielefeld.DE" 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:54:31 +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: ro at CeBiTec dot Uni-Bielefeld.DE 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 #12 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #11 from Lewis Hyatt --- > Oh interesting. So the purpose of this test was just to record that GCC o= utputs > 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 wr= ong > locations for different platforms, but I could buy that it may happen, fo= r a > similar reason why this switched from being silently broken to ICEing sin= ce > 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 locat= ion 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 probl= ems we It's still weird given that it's exactly the same version of Solaris on both SPARC and x86. > could just skip it on some architectures maybe? Once the underlying issue= is I guess that's best for now. I'll check if the test behaves differently for a 64-bit-default (amd64-pc-solaris2.11) compiler. > 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 compil= e farm > machine with this architecture I could look into it. There's no Solaris/x86 system in the cfarm right now, unfortunately. The only one runs Solaris 11.3/SPARC, where the test works just like everywhere else. That said, I've accquired systems to add to the cfarm that will both be running current Solaris 11.4 (SPARC and x86). I'm working on installing and integrating them as we speak, but I don't have an ETA yet.=