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