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