https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108534
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
CC| |rguenth at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Last reconfirmed| |2026-09-04
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
So the reason for streaming PWD is to fixup compile vs. link-time PWD changes.
At link time we do
if (file_change)
{
const bool pwd_change = bp_unpack_value (&bp, 1);
if (pwd_change)
{
const char *pwd = bp_unpack_string (data_in, &bp);
const char *src_pwd = get_src_pwd ();
stream_relative_path_prefix
= strcmp (pwd, src_pwd) == 0 ? nullptr
: canon_relative_path_prefix (pwd, src_pwd);
}
stream_file = canon_file_name (stream_relative_path_prefix,
bp_unpack_string (data_in, &bp));
ISTR there are also issues with compile-time vs. link-time remapping.
Just streaming remapped src_pwd as proposed will probably at least wreck
the above. Instead the compile-time vs. link-time remapping would need
to be resolved somehow. We do not stream the remapping options (so they
seem to be only applied at compile-time).
I don't see how the originally causing rev. can work when remapping
both PWDs - the remapping might not yield a workable combination to
produce a relative path prefix, but we are also not set up to remap
the path late. I'm unsure whether we can somehow fixup things by
streaming both the original and the remapped compile-time PWD?
A workaround is to make sure to always remap to an absolute path.
