[Bug debug/44832] [4.6 Regression] -fcompare-debug failure for C++ i386.c

["rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #37 from rguenther at suse dot de  2010-07-08 11:31 -------
Subject: Re:  [4.6 Regression] -fcompare-debug failure for
 C++ i386.c

On Thu, 8 Jul 2010, amylaar at gcc dot gnu dot org wrote:

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

?  We don't allow the relative order of decl_uids to become random.  Where
do you think that happens?

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

This is what we have the -nouid modifier for.

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

?  You have lost me here again.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44832