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