From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4668 invoked by alias); 15 Feb 2010 14:10:58 -0000 Received: (qmail 4604 invoked by uid 48); 15 Feb 2010 14:10:37 -0000 Date: Mon, 15 Feb 2010 14:10:00 -0000 Message-ID: <20100215141037.4603.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug debug/43051] [4.5 Regression] VTA causes a stack living parameter unavailable in most of the function In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "jakub at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-02/txt/msg01406.txt.bz2 ------- 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