https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105608
--- Comment #13 from Lewis Hyatt <lhyatt at gcc dot gnu.org> ---
I think I understand why it is platform dependent. The location being assigned
to the restored macros is pfile->directive_line, which was stored relative to
the original line map instance, before replacing it with the one from the PCH.
So looking that location up in the new line_maps instance produces some value
that is dependent on exactly what was stored in the old and new line maps. In
particular it will depend on stuff that was included internally such as
/usr/include/stdc-predef.h. The output with -fdump-internal-locations would
confirm it, but I am not sure it's too important to understand all the ways
that this location is wrong, since it needs to just get fixed regardless...
it's not even trying to be correct right now.
This patch in libcpp would stabilize the output to be the same on all
platforms:
=====
diff --git a/libcpp/pch.cc b/libcpp/pch.cc
index e156fe257b3..08df0f8a86d 100644
--- a/libcpp/pch.cc
+++ b/libcpp/pch.cc
@@ -838,7 +838,7 @@ cpp_read_state (cpp_reader *r, const char *name, FILE *f,
!= NULL)
{
_cpp_clean_line (r);
- if (!_cpp_create_definition (r, h, 0))
+ if (!_cpp_create_definition (r, h, r->line_table->highest_line))
abort ();
_cpp_pop_buffer (r);
}
=====
It would change the location to be always line 3 in the source file, matching
the "wrong" result you get now on i386-pc-solaris2.11 . The test case would
need adjustment to match. I am going to ask if it can be approved for GCC 14, I
think it is worth it to not use an unpredictable location here.
