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

["amylaar at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #47 from amylaar at gcc dot gnu dot org  2010-07-08 20:00 -------
Created an attachment (id=21150)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21150&action=view)
proposed patch

(In reply to comment #46)
> Could we use a different bit that is currently unused for LABEL_DECLs?
> (With a suitable accessor macro, of course.)

Hmm, actually, there should be no problem with changing TREE_USED of a
LABEL_DECL once lang_hooks.parse_file is done with emitting warnings about
undefined-but-used / used-but-not-defined labels.

The problem is clearing them all at or before the start of
remove_unused_locals. It's be easy to do in one frontend, when we do the
warnings, but requiring all the frontends to do it is messy, and it when
remove_unused_locals is called multiple times that'd not reset the used flag
for labels the used of which have been optimized away in the meantime.

I think the TREE_USED as given from the frontends is probably a good enough
approximation if we also take DECL_IGNORED_P into account.

As it happens, TREE_USED is actually cleared by init_vars_expansion, although,
as stated before, it should be good enough without that.

I'm currently testing the attached patch.

Regarding a testcase for our testsuite, I think that would best be done in the
context of PR other/44874.  Although we should be able to reproducibly get
scrabled DECL_UIDs with the old compiler logic, having this translate into
different ssa name versioning or even generated code is less reliable when
you change bits of the compiler or the compiler host / target.
With a dump option to enumerate declarations / labels in DECL_UID order, the
regression test can verify that order matches.
I think this dump option should be default for -fcompare-debug; in that case,
the testcase should be relatively simple.


-- 


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