From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7033 invoked by alias); 8 Jul 2010 11:04:42 -0000 Received: (qmail 6295 invoked by uid 48); 8 Jul 2010 11:04:30 -0000 Date: Thu, 08 Jul 2010 11:04:00 -0000 Message-ID: <20100708110430.6294.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "amylaar 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-07/txt/msg00841.txt.bz2 ------- Comment #36 from amylaar at gcc dot gnu dot org 2010-07-08 11:04 ------- (In reply to comment #35) > The ordering issue in VRP needs to be fixed. The sorting can use > LABEL_DECL_UID which is dense in a given function. (but watch out > for a -1 value where no UID has been assigned) I think that is too late; it would solve this particular failure, but AAUI, once we allow the relative order of decl_uids to become random, we've lost. There is also the wider issue that this entire business of allowing decl_uids to drift as long as ordering is preserved makes impossible to use dump comparisons as an effective means to determine in what pass things go wrong. It appears that in general, we use negative decl_uids for debug symbols, yet we may retain / copy non-debug symbols for reasons of debugging and let them have positive numbers. I wonder if it would be feasible to allocate new negative the uids for such symbols when they only remain for purposes of debugging, and when we somehow end up merging a debug and non-debug copy, the non-debug with its positive decl_uid should prevail. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832