undefined reference to __tsan_atomic64_compare_exchange_val ATTN: Dmitry

[GoogleCodeExporter]

Using Dmitry's atomics patch for tsan, I eventually managed to build my project 
with clang and libc++, it was not easy on linux! 

I have some linker errors remaining that look like this in calls to 
compare_exchange_strong:

error: undefined reference to `__tsan_atomic64_compare_exchange_val'

I see in the tsan binary, the symbols:

__tsan_atomic64_compare_exchange_strong
__tsan_atomic64_compare_exchange_weak

Are defined, but not _val, not sure if the problem there is in libc++ or in 
tsan, but no doubt you guys would know best. Let me know if you need any more 
information.

I'm eager to continue trying tsan against this codebase, which utilizes a lot 
of tricky synchronization and lock-free algorithms.

Cheers,
Dan

Original issue reported on code.google.com by dan.el...@gmail.com on 8 Nov 2012 at 2:06

[GoogleCodeExporter]

It's worth mentioning that I use std:atomic<struct> where struct has a single 
64 bit member, possibly it's this that's tripping things up?

Original comment by dan.el...@gmail.com on 8 Nov 2012 at 2:00

[GoogleCodeExporter]

Original comment by konstant...@gmail.com on 9 Nov 2012 at 11:22

[GoogleCodeExporter]

Sorry, for some reason I wasn't subscribed to this group...
You need this revision:
http://www.llvm.org/viewvc/llvm-project?view=rev&revision=167611

Original comment by dvyu...@google.com on 10 Nov 2012 at 10:20

• Changed state: Fixed

[GoogleCodeExporter]

>I'm eager to continue trying tsan against this codebase, which utilizes a lot 
of tricky synchronization and lock-free algorithms.

Unfortunately ThreadSanitizer does not fully support *tricky* algorithms. It's 
main goal is to be able to function on real programs, that may consist of 
millions of lines of code, consume GBs of memory and run for hours.
100% precise memory model modeling is practically impossible on such scale. Not 
saying that verification of tricky algorithms require examination of zillions 
of possible executions. But we are trying to model some aspects, if it does not 
sacrifice other properties. I've taught ThreadSanitizer about acuire-release 
synchronization, basic understanding of release sequences, etc. But AFAIR 
stand-alone memory fences are still no-ops. Having said that, we are able to 
verify huge real programs w/o any problems (they rely mostly on acquire-release 
synchronization).
It would be interesting to hear about your experience. Whether you observe any 
false positives and on what code.

Original comment by dvyu...@google.com on 10 Nov 2012 at 10:32