This is the mail archive of the gcc-bugs@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]

[Bug sanitizer/78158] Strange data race detection with thread sanitizer


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78158

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Or the sync special bit (0x4000)?
That said,
            if (!tree_fits_uhwi_p (last_arg)
                || memmodel_base (tree_to_uhwi (last_arg)) >= MEMMODEL_LAST)
actually just ignores the higher bits (all 3 I've mentioned), it is a compile
time if (last_arg & 0x3fff) >= 6, and if that is false, it actually passes the
argument through unmodified.  So it depends on what the library will do with
those bits, and the check only guards for the not yet implemented other values,
so indeed I could perhaps leave that out for now.

Then there is the weak cas case, the GCC builtins have a bool argument whether
the cas is weak or strong, while tsan has separate libcalls for strong vs.
weak.
The way this is implemented in tsan.c actually is that if the argument is
compile time known non-zero (i.e. true), then the weak tsan atomics are used,
otherwise the strong tsan atomics are used (even when it is a variable which
evaluates to true).  As the documentation says that the weak argument is just
an optimization hint and can be ignored, this is probably the right thing.

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