public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug debug/63572] [10/11/12/13/14 Regression] ICF breaks user debugging experience
Date: Tue, 30 May 2023 18:12:13 +0000	[thread overview]
Message-ID: <bug-63572-4-hPuDniDR6W@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-63572-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #31 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
In theory, what we could do (expensive though) is keep the IL of the functions
that were ICF merged with the picked up candidate, just mark them in cgraph
specially so that e.g. IPA doesn't consider references to functions/vars from
the other copies as distinct references, compile those functions right after
compiling their chosen ICF winner (or right before it), but don't emit into
assembly, instead compare with how the ICF winner
and emit just debug info for the other copies after building some mapping
between the debug related labels in the different functions.  If we compiled it
into different code, something bad happened (e.g. some debug counter or
similar) and we'd just not emit the debug info for the other copies (like we
don't emit it currently for those).

  parent reply	other threads:[~2023-05-30 18:12 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-17  9:06 [Bug debug/63572] New: [5 " jakub at gcc dot gnu.org
2014-10-17  9:20 ` [Bug debug/63572] " rguenth at gcc dot gnu.org
2014-10-17  9:29 ` jakub at gcc dot gnu.org
2014-10-17  9:34 ` trippels at gcc dot gnu.org
2014-10-17  9:56 ` jakub at gcc dot gnu.org
2014-10-17 10:12 ` jakub at gcc dot gnu.org
2014-11-20 12:28 ` rguenth at gcc dot gnu.org
2015-02-09 15:43 ` marxin at gcc dot gnu.org
2015-02-09 21:58 ` jakub at gcc dot gnu.org
2015-03-02 17:49 ` hubicka at gcc dot gnu.org
2015-03-03 16:06 ` law at redhat dot com
2015-03-04 10:58 ` marxin at gcc dot gnu.org
2015-03-19 19:16 ` howarth at bromo dot med.uc.edu
2015-04-22 12:02 ` [Bug debug/63572] [5/6 " jakub at gcc dot gnu.org
2015-07-16  9:15 ` rguenth at gcc dot gnu.org
2020-11-23  7:53 ` [Bug debug/63572] [8/9/10/11 " hubicka at gcc dot gnu.org
2020-11-23 10:34 ` rguenth at gcc dot gnu.org
2020-11-23 10:36 ` jakub at gcc dot gnu.org
2021-05-14  9:47 ` [Bug debug/63572] [9/10/11/12 " jakub at gcc dot gnu.org
2021-06-01  8:06 ` rguenth at gcc dot gnu.org
2022-05-27  9:35 ` [Bug debug/63572] [10/11/12/13 " rguenth at gcc dot gnu.org
2022-06-28 10:31 ` jakub at gcc dot gnu.org
2023-05-30 18:12 ` jakub at gcc dot gnu.org [this message]
2023-07-07 10:30 ` [Bug debug/63572] [11/12/13/14 " rguenth 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-63572-4-hPuDniDR6W@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).