[Bug lto/106274] New: Loss of macro tracking information with -flto

[lhyatt at gcc dot gnu.org]

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

            Bug ID: 106274
           Summary: Loss of macro tracking information with -flto
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
          Assignee: unassigned at gcc dot gnu.org
          Reporter: lhyatt at gcc dot gnu.org
                CC: marxin at gcc dot gnu.org
  Target Milestone: ---

This is related to PR101551 but easier to demonstrate a testcase for:

=======
#define X(p) p == 0
int f(void *) __attribute__((nonnull));
int f(void *p) {
    return X(p);
}
========

When compiled without -flto, there is information on the macro expansion in the
diagnostics:

$ gcc -c t5.c -Wnonnull-compare
/home/lewis/t5.c: In function ‘f’:
/home/lewis/t5.c:1:16: warning: nonnull argument ‘p’ compared to NULL
[-Wnonnull-compare]
    1 | #define X(p) p == 0
      |                ^
/home/lewis/t5.c:4:12: note: in expansion of macro ‘X’
    4 |     return X(p);
      |            ^

However, if you add -flto, you don't get the extra information:

$ gcc -c t5.c -Wnonnull-compare -flto
/home/lewis/t5.c: In function ‘f’:
/home/lewis/t5.c:1:16: warning: nonnull argument ‘p’ compared to NULL
[-Wnonnull-compare]
    1 | #define X(p) p == 0
      |                ^

The reason is that this warning is generated after the ipa_free_lang_data pass,
and that does this:

========
/* If we are the LTO frontend we have freed lang-specific data already.  */
  if (in_lto_p
      || (!flag_generate_lto && !flag_generate_offload))
    {
      /* Rebuild type inheritance graph even when not doing LTO to get
         consistent profile data.  */
      rebuild_type_inheritance_graph ();
      return 0;
    }

...

    /* Reset diagnostic machinery.  */
    tree_diagnostics_defaults (global_dc);

========

With -flto, flag_generate_lto is true, so it doesn't return early, and proceeds
to the last line, which resets the diagnostic finalizer to
default_diagnostic_finalizer, which is not aware of virtual locations.

PR101551 is about more or less the same thing except it's the other case that
prevents this function from returning early (flag_generate_offload == true). I
am not sure to what extent they are otherwise related.

Is it possible to avoid resetting the diagnostics machinery in either of these
cases? Thanks...