public inbox for gcc-cvs@sourceware.org
help / color / mirror / Atom feed
From: Alexandre Oliva <aoliva@gcc.gnu.org>
To: gcc-cvs@gcc.gnu.org
Subject: [gcc(refs/users/aoliva/heads/testme)] libcpp: Stabilize the location for macros restored after PCH load [PR105608]
Date: Mon, 19 Feb 2024 21:41:09 +0000 (GMT)	[thread overview]
Message-ID: <20240219214109.E8C543858C78@sourceware.org> (raw)

https://gcc.gnu.org/g:8133137ddba85fc6cc9fc8ead2ebf5c145813e7e

commit 8133137ddba85fc6cc9fc8ead2ebf5c145813e7e
Author: Lewis Hyatt <lhyatt@gmail.com>
Date:   Mon Feb 19 18:03:31 2024 -0300

    libcpp: Stabilize the location for macros restored after PCH load [PR105608]
    
    libcpp currently lacks the infrastructure to assign correct locations to
    macros that were defined prior to loading a PCH and then restored
    afterwards. While I plan to address that fully for GCC 15, this patch
    improves things by using at least a valid location, even if it's not the
    best one. Without this change, libcpp uses pfile->directive_line as the
    location for the restored macros, but this location_t applies to the old
    line map, not the one that was just restored from the PCH, so the resulting
    location is unpredictable and depends on what was stored in the line maps
    before. With this change, all restored macros get assigned locations at the
    line of the #include that triggered the PCH restore. A future patch will
    store the actual file name and line number of each definition and then
    synthesize locations in the new line map pointing to the right place.
    
    gcc/c-family/ChangeLog:
    
            PR preprocessor/105608
            * c-pch.cc (c_common_read_pch): Adjust line map so that libcpp
            assigns a location to restored macros which is the same location
            that triggered the PCH include.
    
    libcpp/ChangeLog:
    
            PR preprocessor/105608
            * pch.cc (cpp_read_state): Set a valid location for restored
            macros.
    
    (cherry picked from commit 019dc63819befb2b82077fb2d76b5dd670946f36)

Diff:
---
 gcc/c-family/c-pch.cc | 23 +++++++++++++++--------
 libcpp/pch.cc         |  9 ++++++++-
 2 files changed, 23 insertions(+), 9 deletions(-)

diff --git a/gcc/c-family/c-pch.cc b/gcc/c-family/c-pch.cc
index 9ee6f1790023..d60972ba9308 100644
--- a/gcc/c-family/c-pch.cc
+++ b/gcc/c-family/c-pch.cc
@@ -318,6 +318,7 @@ c_common_read_pch (cpp_reader *pfile, const char *name,
   struct save_macro_data *smd;
   expanded_location saved_loc;
   bool saved_trace_includes;
+  int cpp_result;
 
   timevar_push (TV_PCH_RESTORE);
 
@@ -343,20 +344,26 @@ c_common_read_pch (cpp_reader *pfile, const char *name,
   cpp_set_line_map (pfile, line_table);
   rebuild_location_adhoc_htab (line_table);
   line_table->trace_includes = saved_trace_includes;
-  linemap_add (line_table, LC_ENTER, 0, saved_loc.file, saved_loc.line);
+
+  /* Set the current location to the line containing the #include (or the
+     #pragma GCC pch_preprocess) for the purpose of assigning locations to any
+     macros that are about to be restored.  */
+  linemap_add (line_table, LC_ENTER, 0, saved_loc.file,
+	       saved_loc.line > 1 ? saved_loc.line - 1 : saved_loc.line);
 
   timevar_push (TV_PCH_CPP_RESTORE);
-  if (cpp_read_state (pfile, name, f, smd) != 0)
-    {
-      fclose (f);
-      timevar_pop (TV_PCH_CPP_RESTORE);
-      goto end;
-    }
-  timevar_pop (TV_PCH_CPP_RESTORE);
+  cpp_result = cpp_read_state (pfile, name, f, smd);
 
+  /* Set the current location to the line following the #include, where we
+     were prior to processing the PCH.  */
+  linemap_line_start (line_table, saved_loc.line, 0);
 
+  timevar_pop (TV_PCH_CPP_RESTORE);
   fclose (f);
 
+  if (cpp_result != 0)
+    goto end;
+
   /* Give the front end a chance to take action after a PCH file has
      been loaded.  */
   if (lang_post_pch_load)
diff --git a/libcpp/pch.cc b/libcpp/pch.cc
index a9f4ff19bf1e..17e423f44b80 100644
--- a/libcpp/pch.cc
+++ b/libcpp/pch.cc
@@ -838,7 +838,14 @@ cpp_read_state (cpp_reader *r, const char *name, FILE *f,
 	      != NULL)
 	    {
 	      _cpp_clean_line (r);
-	      if (!_cpp_create_definition (r, h, 0))
+
+	      /* ??? Using r->line_table->highest_line is not ideal here, but we
+		 do need to use some location that is relative to the new line
+		 map just loaded, not the old one that was in effect when these
+		 macros were lexed.  The proper fix is to remember the file name
+		 and line number where each macro was defined, and then add
+		 these locations into the new line map.  See PR105608.  */
+	      if (!_cpp_create_definition (r, h, r->line_table->highest_line))
 		abort ();
 	      _cpp_pop_buffer (r);
 	    }

             reply	other threads:[~2024-02-19 21:41 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-19 21:41 Alexandre Oliva [this message]
2024-02-19 21:51 Alexandre Oliva

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=20240219214109.E8C543858C78@sourceware.org \
    --to=aoliva@gcc.gnu.org \
    --cc=gcc-cvs@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).