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] Loss of macro tracking information with -flto
Date: Wed, 13 Jul 2022 12:13:38 +0000	[thread overview]
Message-ID: <bug-106274-4-BYUm7o2uB5@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-106274-4@http.gcc.gnu.org/bugzilla/>

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.

  parent reply	other threads:[~2022-07-13 12:13 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-12 19:51 [Bug lto/106274] New: " lhyatt at gcc dot gnu.org
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 [this message]
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-BYUm7o2uB5@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: link
Be 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).