public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "lhyatt at gcc dot gnu.org" <gcc-bugzilla@gcc.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	[thread overview]
Message-ID: <bug-105608-4-1HA7ZcHUhV@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-105608-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105608

--- Comment #11 from Lewis Hyatt <lhyatt at gcc dot gnu.org> ---
Oh interesting. So the purpose of this test was just to record that GCC outputs
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 location 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 problems 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.

  parent reply	other threads:[~2024-01-30 14:38 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-15  8:08 [Bug preprocessor/105608] New: [13 Regression] ICE: in linemap_add, at libcpp/line-map.cc:502 on ovito-3.7.1 slyfox at gcc dot gnu.org
2022-05-16  7:12 ` [Bug preprocessor/105608] [11/12/13 Regression] ICE: in linemap_add, at libcpp/line-map.cc:502 on ovito-3.7.1 since r11-338-g2a0225e47868fbfc marxin at gcc dot gnu.org
2022-05-16  7:30 ` pinskia at gcc dot gnu.org
2022-05-16  8:12 ` rguenth at gcc dot gnu.org
2023-05-02 20:56 ` [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 lhyatt at gcc dot gnu.org
2023-05-29 10:07 ` jakub at gcc dot gnu.org
2023-12-15 21:30 ` lhyatt at gcc dot gnu.org
2024-01-27  4:30 ` cvs-commit at gcc dot gnu.org
2024-01-27 12:56 ` cvs-commit at gcc dot gnu.org
2024-01-27 17:08 ` cvs-commit at gcc dot gnu.org
2024-01-27 21:51 ` cvs-commit at gcc dot gnu.org
2024-01-27 21:53 ` lhyatt at gcc dot gnu.org
2024-01-30 13:57 ` ro at gcc dot gnu.org
2024-01-30 14:38 ` lhyatt at gcc dot gnu.org [this message]
2024-01-30 14:54 ` ro at CeBiTec dot Uni-Bielefeld.DE
2024-01-30 22:05 ` lhyatt at gcc dot gnu.org
2024-01-31 14:49 ` lhyatt at gcc dot gnu.org
2024-02-01 14:17 ` cvs-commit at gcc dot gnu.org
2024-02-22 14:45 ` cvs-commit at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-105608-4-1HA7ZcHUhV@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).