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

[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...

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

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2022-07-13
            Version|unknown                     |12.1.0
           Keywords|                            |diagnostic, lto
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
I think the point is that in free-lang-data we are bulldozering over data
structures that the frontend might not be happy about (in the attempt to make
the streamed IL small), so we try to reset all callbacks into frontend code
that might crash.

I'm not sure to what extent this is still required with respect to the
diagnostic context though - you'd have to try.

There's also the old long-standing TODO to perform this "frontend scrapping"
also when not using -flto just to save on memory for the followup optimization
(but this runs into the same issue that late diagnostics then appear
"mangled").

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

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
I think it's a dup of PR80922.

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

[lhyatt at gcc dot gnu.org]

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

--- Comment #3 from Lewis Hyatt <lhyatt at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #2)
> I think it's a dup of PR80922.

I think it's a bit different, if I understand correctly, PR80922 is asking for
something much more difficult, it wants the LTO streaming process to be able to
remember that it saw a diagnostic pragma, so that the LTO frontend can know
about it when reading the data back in, and so suppress new warnings it is able
to generate due to the power of the interprocedural analysis it has access to.
That seems pretty challenging, given we still have a lot of bugs with just
handling diagnostic pragmas properly in the non-LTO case.

In my testcase here, the diagnostic is emitted by cc1/cc1plus while producing
the data for LTO, not by the LTO frontend, and everything is fine with it
except that it gets printed with a barebones printer, rather than a virtual
location aware printer.

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

[lhyatt at gcc dot gnu.org]

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

--- Comment #4 from Lewis Hyatt <lhyatt at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #1)
> I'm not sure to what extent this is still required with respect to the
> diagnostic context though - you'd have to try.

Thanks for the explanation, the general nature of it makes sense to me now.
There is one current testcase (g++.dg/20090121-1.C) which demonstrates that
it's not OK to simply skip calling tree_diagnostics_defaults () entirely for
-flto... For that testcase, the -Wuninitialized diagnostic calling back into
the C+ frontend (cp_printer) would ICE after ipa-free-lang-data pass if so.

It seems like it should be doable to address this, maybe frontends could
specify how they want ipa-free-lang-data to adjust their diagnostic context, so
it wouldn't have to be all or nothing. I can look into that sometime, perhaps
it would help with enabling this pass to run during non-LTO compilation as
well.