This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug debug/43051] [4.5 Regression] VTA causes a stack living parameter unavailable in most of the function



------- 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]