On 8 Mar 2014 at 19:18, Andrey Semashev wrote:
Even nop requires decoding effort, so it does have a cost.
As I said before, on a recent out of order CPU it usually has no statistically significant cost.
And I was referring to ThreadSanitizer markup. Does it use the same markup as valgrind does?
Firstly, the only valid reason to use AddressSanitiser over valgrind memcheck is when valgrind is too slow. The problem with AddressSanitiser, like some other clang/GCC sanitisers, is that *everything* in the process space needs to be compiled with the sanitiser turned on. Otherwise memory corruption caused by an uninstrumented bit of code can magically appear in other places, and forget about debugging the cause easily. I personally use those sanitisers which require everything to be compiled with them as a quick smoke check, but use valgrind for finding causes. The ThreadSanitiser doesn't need everything to be instrumented, and it has the huge advantage of speed and memory consumption over valgrind's helgrind or DRD. ThreadSanitiser has two versions, one based on valgrind where a subset of DRD/helgrind instrumentation is recognised, the other based on a clang backend which currently does not recognise DRD/helgrind instrumentation. The DRD/helgrind markup is really about *documentation* of use of non-standard threading constructs, plus you can subvert the macros to do other useful things e.g. auto-generate a ThreadSanitiser suppressions file for you. The clang/GCC ThreadSanitizer is still in beta, and reusing DRD/helgrind markup is a very likely feature add in the future. Hope this explains everything. Niall -- Currently unemployed and looking for work in Ireland. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/