I don't think that will fix this bug. The bug occurs if: (1) The exclusive lock set has error_mark_node. (2) The shared lock set has the actual lock.
In this case, remove_lock_from_lockset thinks that it has found the lock in the exclusive lock set, and fails to remove it from the shared lock set. To fix the bug, the first call to lock_set_contains should ignore the universal lock and return null, so that remove_lock will continue on to search the shared lock set. If I understand your suggested fix correctly, lock_set_contains would still return non-null when the universal lock was present, which is not what we want. IMHO, lock_set_contains is operating correctly; it was just passed the wrong arguments. -DeLesley On Tue, Oct 11, 2011 at 2:34 PM, Ollie Wild <a...@google.com> wrote: > On Mon, Oct 10, 2011 at 3:37 PM, Delesley Hutchins <deles...@google.com> > wrote: >> >> --- gcc/tree-threadsafe-analyze.c (revision 179771) >> +++ gcc/tree-threadsafe-analyze.c (working copy) >> @@ -1830,14 +1830,27 @@ remove_lock_from_lockset (tree lockable, struct po > > This feels like a bug in lock_set_contains(), not > remove_lock_from_lockset(). I'd modify lock_set_contains() as > follows: > > 1) During the universal lock conditional, remove the return statement. > Instead, set default_lock = lock (where default_lock is a new > variable initialized to NULL_TREE). > > 2) Anywhere NULL_TREE is returned later, replace it with default_lock. > > Ollie > -- DeLesley Hutchins | Software Engineer | deles...@google.com | 505-206-0315
