public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "jakub at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug debug/43051] [4.5 Regression] VTA causes a stack living parameter unavailable in most of the function
Date: Mon, 15 Feb 2010 14:10:00 -0000 [thread overview]
Message-ID: <20100215141037.4603.qmail@sourceware.org> (raw)
In-Reply-To: <bug-43051-87@http.gcc.gnu.org/bugzilla/>
------- Comment #5 from jakub at gcc dot gnu dot org 2010-02-15 14:10 -------
While the patch bootstrapped/regtested on i686-linux (all,obj-c++,lto but no
ada) and resulted in quite substantial changes on .debug_info/.debug_loc -
.debug_info on cc1 grew by ~ 11.1% from 16513941 to 18581214 bytes and
.debug_loc grew by 48.1% from 6749001 to 13013048 bytes (one would hope that is
better debug info quality), it unfortunately didn't bootstrap on x86_64-linux
(all,obj-c++,lto,ada), with an ICE while compiling 32-bit g-sehash.adb
in delete_slot_part - the gcc_assert (changed) line.
p debug_rtx (loc)
(mem/c:SI (value/s/u:SI 175:3747 @0x1f4c4b8/0x1f4d2e0) [22 %sfp+-332 S4 A32])
p debug_rtx (var->var_part[0].cur_loc)
(mem/c:SI (value/s/u:SI 148:3703 @0x1f4c170/0x1f4be30) [26 S4 A32])
I guess this is related to the patch, the two VALUEs probably either at some
point or even currently point to the same thing. The question is what should
we do about it, easiest would be just not to assert changed is true, but just
set it if the location list is empty. Is that the only spot that needs
changing though? E.g. dataflow_set_remove_mem_locs does something similar...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43051
next prev parent reply other threads:[~2010-02-15 14:10 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-12 13:27 [Bug debug/43051] New: " jakub at gcc dot gnu dot org
2010-02-12 13:28 ` [Bug debug/43051] " jakub at gcc dot gnu dot org
2010-02-12 13:48 ` jakub at gcc dot gnu dot org
2010-02-12 14:05 ` jakub at gcc dot gnu dot org
2010-02-12 16:45 ` jakub at gcc dot gnu dot org
2010-02-12 17:02 ` jakub at gcc dot gnu dot org
2010-02-15 12:21 ` jakub at gcc dot gnu dot org
2010-02-15 14:10 ` jakub at gcc dot gnu dot org [this message]
2010-02-15 16:13 ` jakub at gcc dot gnu dot org
2010-02-22 17:10 ` jakub at gcc dot gnu dot org
2010-02-22 17:23 ` jakub at gcc dot gnu dot org
2010-02-22 18:17 ` jakub at gcc dot gnu dot org
2010-02-22 19:21 ` jakub at gcc dot gnu dot org
2010-03-16 10:52 ` jakub at gcc dot gnu dot org
2010-03-16 10:53 ` jakub at gcc dot gnu dot 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=20100215141037.4603.qmail@sourceware.org \
--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).