On Wed, Oct 12, 2011 at 9:58 AM, Delesley Hutchins wrote:
>
> 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.
Oh, I see. This change looks fine for google/gcc-4_6, then.
> If I understand
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
On Mon, Oct 10, 2011 at 3:37 PM, Delesley Hutchins 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(
This patch fixes an error where Annotalysis generates bogus warnings
when a shared lock is released in a function that has a "universal
lock" -- typically produced when gcc cannot parse a lock expression.
Bootstrapped and passed gcc regression testsuite on
x86_64-unknown-linux-gnu. Okay for googl
