public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "lhyatt at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug lto/106274] New: Loss of macro tracking information with -flto Date: Tue, 12 Jul 2022 19:51:32 +0000 [thread overview] Message-ID: <bug-106274-4@http.gcc.gnu.org/bugzilla/> (raw) 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...
next reply other threads:[~2022-07-12 19:51 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-07-12 19:51 lhyatt at gcc dot gnu.org [this message] 2022-07-13 6:38 ` [Bug lto/106274] " rguenth at gcc dot gnu.org 2022-07-13 7:15 ` marxin at gcc dot gnu.org 2022-07-13 12:13 ` lhyatt at gcc dot gnu.org 2022-07-13 17:48 ` lhyatt at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-106274-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).