public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug debug/105415] [9/10/11/12/13 Regression] '-fcompare-debug' failure w/ -O2 -ftree-parallelize-loops=2 since r7-4900-g59ec925b1199f9
Date: Mon, 02 May 2022 09:34:00 +0000	[thread overview]
Message-ID: <bug-105415-4-H9JYvlAVTZ@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-105415-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:02f03c5c826d0cb7c32398af0c4282921e6e072a

commit r13-68-g02f03c5c826d0cb7c32398af0c4282921e6e072a
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Mon May 2 11:30:58 2022 +0200

    expand: Throw away non-external decls without varpool nodes [PR105415]

    The following testcase fails -fcompare-debug on aarch64-linux.  The problem
    is that for the n variable we create a varpool node, then remove it again
    because the var isn't really used, but it keeps being referenced in debug
    stmts/insns with -g.  Later during sched1 pass we ask whether the n var
    can be modified through some store to an anchored variable and with -g
    we create a new varpool node for it again just so that we can find its
    ultimate alias target.  Even later on we create some cgraph node for the
    loop parallelization, but as there has been an extra varpool node creation
    in between, we get higher node->order with -g than without.

    The patch fixes that by throwing variables without varpool nodes away
    during expansion time, they are very unlikely to actually end up with
    useful debug info anyway.

    I've bootstrapped/regtested the following on x86_64-linux and i686-linux,
    then bootstrapped with the patch reverted, reapplied the patch and did make
    cc1plus in stage3.  The debug section sizes are identical, .debug_info and
    .debug_loc is identical too, so I think we don't lose any debug info
through
    it.
    So at least on cc1plus it makes no difference.

    2022-05-02  Jakub Jelinek  <jakub@redhat.com>

            PR debug/105415
            * cfgexpand.cc (expand_debug_expr): Don't make_decl_rtl_for_debug
            if there is no symtab node for the VAR_DECL.

            * gcc.dg/pr105415.c: New test.

  parent reply	other threads:[~2022-05-02  9:34 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-28  2:43 [Bug debug/105415] New: [10/11/12 Regression] '-fcompare-debug' failure w/ -O2 -ftree-parallelize-loops=2 asolokha at gmx dot com
2022-04-28  7:08 ` [Bug debug/105415] " rguenth at gcc dot gnu.org
2022-04-28  7:34 ` marxin at gcc dot gnu.org
2022-04-28  8:24 ` [Bug debug/105415] [9/10/11/12 Regression] '-fcompare-debug' failure w/ -O2 -ftree-parallelize-loops=2 since r7-4900-g59ec925b1199f9 marxin at gcc dot gnu.org
2022-04-28  9:57 ` jakub at gcc dot gnu.org
2022-04-28 10:04 ` jakub at gcc dot gnu.org
2022-04-28 11:51 ` jakub at gcc dot gnu.org
2022-05-02  9:34 ` cvs-commit at gcc dot gnu.org [this message]
2022-05-02  9:36 ` jakub at gcc dot gnu.org
2022-05-17 12:08 ` [Bug debug/105415] [9/10/11/12/13 " asolokha at gmx dot com
2022-05-17 12:24 ` jakub at gcc dot gnu.org
2022-06-28 10:49 ` [Bug debug/105415] [10/11/12 " jakub at gcc dot gnu.org
2022-07-26 11:44 ` rguenth at gcc dot gnu.org
2023-07-07 10:43 ` [Bug middle-end/105415] [11/12 " 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-105415-4-H9JYvlAVTZ@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).