This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] [Annotalysis] Bugfix for spurious thread safety warnings with shared mutexes


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 <aaw@google.com> wrote:
> On Mon, Oct 10, 2011 at 3:37 PM, Delesley Hutchins <delesley@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 | delesley@google.com | 505-206-0315


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]