------- Comment #17 from amacleod at redhat dot com 2006-04-26 20:38 ------- Created an attachment (id=11336) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11336&action=view) Possible patch
Maybe. there is a work around I have an initial patch for. It re-covers up the problem I think :-) The reason it is triggering in the ssa portion is because of the Schizophrenic way we find referenced variables. find_referenced_vars() uses a hash table of variable addresses (vars_found in the walk_state struct) to determine whether a variable has been seen or not. If it hasn't been seen, it eventually calls add_referenced_var(). add_referenced_var() assumes if it is called that the variable truly hasn't been added, and it creates an entry in the referenced_var hash table, which is hashed by DECL_UID rather than by address. What happens in this test case is with two addresses with the same DECL_UID, add_referenced_var() gets back the same hash slot for the second variable, and simply overwrites the hash slot info with the second variable's info (so the first one's info is gone). When SSA is deleted, the second variables annotation is deleted because it is in the referenced_var hash table, but the first one's is never seen. Next function comes along, and boom, the first var already has ann annotation and hellfire begins to spread. The fix that I have removes the first hashtable. Diego thinks it may have been there for historical reasons, but there is certainly no need for it now. Instead of maintaining and checking thats vars_found table, we can simple check the referenced_var table to see if we have seen a given DECL_UID yet. This should be fixed anyway since it is wasteful, and as a bonus it appears to cover the problem back up again. I ran this a couple of weeks ago on 4.1 but never got back to it. Someone want to try it out and see if it causes any other problems? It bootstrapped and caused no new testsuite regressions on x86-linux then. I'll re-run it tonight. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26757 ------- You are receiving this mail because: ------- You reported the bug, or are watching the reporter. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
