similar to: call_once and TSan

> On 2 Sep 2016, at 11:18, Dmitry Vyukov via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Thu, Sep 1, 2016 at 2:30 PM, Kuba Brecka <kuba.brecka at gmail.com> wrote: >> Hi, >> >> I'm trying to write a TSan interceptor for the C++11 call_once function. There are currently false positive reports, because the inner __call_once function is located in

> On 2 Sep 2016, at 12:11, Dmitry Vyukov <dvyukov at google.com> wrote: > > On Fri, Sep 2, 2016 at 12:09 PM, Kuba Brecka <kuba.brecka at gmail.com> wrote: >> >>> On 2 Sep 2016, at 11:18, Dmitry Vyukov via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> On Thu, Sep 1, 2016 at 2:30 PM, Kuba Brecka <kuba.brecka at gmail.com>

Same problem exists, thread A can still be within REAL(call_once), but after it ran user code and set the flag to ~0. Roughly, call_once does: __call_once(flag, arg, func) { mutex_lock(mut); if (flag == BEING_INITIALIZED) { wait } else if (flag == NOT_INITIALIZED_AT_ALL) { flag = BEING_INITIALIZED; mutex_unlock(mut); func(arg); // <=== user code callback

Adding Jiangning Liu to the thread. Jiangning reported a similar issue on the llvm-commits list on Debian aarch64. In general it sounds like std::call_once may not really be bug free. Jiangning, can you please provide your gcc/libstdc++ version? Thanks, -Chris > On Nov 4, 2014, at 9:38 AM, Bill Schmidt <wschmidt at linux.vnet.ibm.com> wrote: > > On Tue, 2014-11-04 at 12:17

Ok, I'll put a patch together to fix this later today. I'll probably do what Reid was suggesting and use what is already in there for Windows. Thanks, Samuel Bill Schmidt <wschmidt at linux.vnet.ibm.com> wrote on 11/04/2014 12:11:08 PM: > From: Bill Schmidt <wschmidt at linux.vnet.ibm.com> > To: Samuel F Antao/Watson/IBM at IBMUS > Cc: azanella at

It seems the crash of llvm/clang build on aarch64 Debian has been fixed by r220941. Thanks, -Jiangning 2014-11-05 8:45 GMT+08:00 Jiangning Liu <liujiangning1 at gmail.com>: > The versions I'm using right now are > > * gcc: (Debian/Linaro 4.9.1-14) 4.9.1 > * libstdc++: libstdc++.so.6.0.20 > > Thanks, > -Jiangning > > 2014-11-05 4:46 GMT+08:00 Chris Bieneman

Hi Bill, You can find the same issue in the buildbot: http://lab.llvm.org:8011/builders/clang-ppc64-elf-linux2/builds/16444/steps/compile.llvm.stage2/logs/stdio It is failing for me both in BE (gcc 4.8.2) and LE(4.9.1). I am compiling with clang 3.5, but those are the gcc toolchains I am using. What do you think is the best way to fix this? Thanks! Samuel Bill Schmidt <wschmidt at

Hi all, I observe that r220932 (Removing the static initializer in ManagedStatic.cpp by using llvm_call_once to initialize the ManagedStatic mutex.) is causing tablegen to segfault in PPC platforms during static initialization. The crash happens while calling std::call_once introduced by this patch in the wrapper used in getManagedStaticMutex. I understand this call is buggy for some platforms

I am guessing that sanitizers are not supported with static linking. The AddressSanitizer document says so explicitly but the others do not. Yet the interceptors use dlsym to set up certain system calls, so by definition they can't support static linking. Given that sanitizers won't work with static linking, why are static libraries created for them? Should there be an error check in the

Hello, I trying TSAN on Darwin on LLVM itself (sanitizing multi-threaded ThinLTO link). However I see two main issues on my debug build: 1) Statistics: the pre/post increment is not safe, it seems to be acknowledge in the code itself: // FIXME: This function and all those that follow carefully use an // atomic operation to update the value safely in the presence of // concurrent

Hmm, I'm confused. The DSO is compiled with gcc. Do I need to compile it with clang instead? I don't believe the JITted code uses the thread support library directly, although I suppose it may be hidden with templates and/or inline functions... On Mon, Sep 28, 2020 at 10:43 PM Lang Hames <lhames at gmail.com> wrote: > > Hi Geoff, > > If you want to access the variable

Hi, I triggered a build failure on a Windows-sanitizer by making the sanity checking in `ASAN_INTERCEPT_FUNC` a bit stricter. My best guess is that the type of the defined interceptor is not compatible (in C++ typing terms) with the “real” function. This seems to be the case for the following 2 functions: CreateThread “no conversion”: From: 'DWORD (__cdecl *)(void * ,

(+correct cfe-dev list) On Tue, Jan 12, 2016 at 2:57 PM, Alexey Samsonov <vonosmas at gmail.com> wrote: > Hi Yuri, > > On Mon, Jan 11, 2016 at 9:53 AM, Yury Gribov via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi all, >> >> UndefinedBehaviorSanitizer currently does not check for undefined >> behaviors which result from improper usage

Sorry, I mean only disable this for THREADS-WIN32, not threads-posix. On Fri, Jun 20, 2014 at 11:14 AM, Zachary Turner <zturner at google.com> wrote: > #2 is better if we can detect threads-win32 vs threads-posix on MinGW, and > only disable this for threads-posix. We can check for > _GLIBCXX_HAS_GTHREADS, but that seems somewhat hackish, so I wonder if > there's a better

Hi JITters, I have some JIT-compiled C++ code that uses symbols from a DSO which uses C++14's thread support library. When I compile it I get the following error message: Symbols not found: [ __emutls_v._ZSt15__once_callable, __emutls_v._ZSt11__once_call ] Those seem to correspond to std::__once_callable and std::__once_call, which are indeed present in the C++ standard library. And I

Posting to the list first, rather than filing a bug because I'm not sure this is still an intended configuration: With LLVM configured as: CXX=clang++ CC=clang cmake ../llvm/ \ -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_INSTALL_PREFIX=~/install/llvm-master/ \ -DLLVM_TARGETS_TO_BUILD=host \ -DLLVM_ENABLE_ASSERTIONS=true \ -DLLVM_ENABLE_LIBCXX=yes \ -DLLVM_ENABLE_LIBCXXABI=yes The check-all target

OK, sounds like we're screwed. There's two options: 1. Revert and give up on C++11 threading libraries for now. 2. Do what Eric suggests. Move all the mutex usage under #ifdef LLVM_ENABLE_THREADS, and disable LLVM_ENABLE_THREADS by default on MinGW. MinGW plus LLVM_ENABLE_THREADS would become unsupported. Do people have objections to 2? I don't really like it either. On Fri, Jun

Hi all, UndefinedBehaviorSanitizer currently does not check for undefined behaviors which result from improper usage of standard library functions. One notorious instance of such errors is invalid usage of qsort or bsearch routines (or std::sort and friends in case of C++): * using comparison function that violates ordering axioms (reflexivity, symmetry, transitivity) * returning unstable

Hi Manuel, I believe you're maintaining Phabricator at reviews.llvm.org <http://reviews.llvm.org/>. Duncan likes to send his patch comments via email, like in the example below. Do you know why don't his replies get imported into the web interface? The reply was sent to "reviews+D24569+public+a5763c0a090df06f at reviews.llvm.org

On 01/13/2016 03:10 AM, Kostya Serebryany wrote: > FTR, here is one way to implement this in the library: > https://gcc.gnu.org/svn/gcc/branches/google/gcc-4_9/libstdc++-v3/include/bits/stl_algo.h > Search for "check sort predicate for strict weak ordering" Nice, although this wouldn't catch violations of transitivity (which is probably the most important type of bug).