public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit 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: Sat, 27 Jan 2024 04:30:23 +0000	[thread overview]
Message-ID: <bug-105608-4-Q1bMmXdOQk@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 #5 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Lewis Hyatt <lhyatt@gcc.gnu.org>:

https://gcc.gnu.org/g:5200ef26ac1771a75596394c20c5f1a348694d5e

commit r14-8465-g5200ef26ac1771a75596394c20c5f1a348694d5e
Author: Lewis Hyatt <lhyatt@gmail.com>
Date:   Tue Dec 5 11:33:39 2023 -0500

    c-family: Fix ICE with large column number after restoring a PCH [PR105608]

    Users are allowed to define macros prior to restoring a precompiled header
    file, as long as those macros are not defined (or are defined identically)
    in the PCH.  However, the PCH restoration process destroys all the macro
    definitions, so libcpp has to record them before restoring the PCH and then
    redefine them afterward.

    This process does not currently assign great locations to the macros after
    redefining them. Some work is needed to also remember the original
locations
    and get the line_maps instance in the right state (since, like all other
    data structures, the line_maps instance is also reset after restoring a
PCH).
    The new testcase line-map-3.C contains XFAILed examples where the locations
    are wrong.

    This patch addresses a more pressing issue, which is that we ICE in some
    cases since GCC 11, hitting an assert in line-maps.cc. It happens if the
    first line encountered after the PCH restore requires an LC_RENAME map,
such
    as will happen if the line is sufficiently long.  This is much easier to
    fix, since we just need to call linemap_line_start before asking libcpp to
    redefine the stored macros, instead of afterward, to avoid the unexpected
    need for an LC_RENAME before an LC_ENTER has been seen.

    gcc/c-family/ChangeLog:

            PR preprocessor/105608
            * c-pch.cc (c_common_read_pch): Start a new line map before asking
            libcpp to restore macros defined prior to reading the PCH, instead
            of afterward.

    gcc/testsuite/ChangeLog:

            PR preprocessor/105608
            * g++.dg/pch/line-map-1.C: New test.
            * g++.dg/pch/line-map-1.Hs: New test.
            * g++.dg/pch/line-map-2.C: New test.
            * g++.dg/pch/line-map-2.Hs: New test.
            * g++.dg/pch/line-map-3.C: New test.
            * g++.dg/pch/line-map-3.Hs: New test.

  parent reply	other threads:[~2024-01-27  4:30 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 [this message]
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
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-Q1bMmXdOQk@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).