This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug debug/43051] [4.5 Regression] VTA causes a stack living parameter unavailable in most of the function
- From: "jakub at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 15 Feb 2010 14:10:37 -0000
- Subject: [Bug debug/43051] [4.5 Regression] VTA causes a stack living parameter unavailable in most of the function
- References: <bug-43051-87@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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