llvm dev - Nov 2014 - [LLVMdev] Issue with std::call_once in PPC64 platform

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 (or probably some oldish
libstdc++ versions). Is this a known issue? Should we guard
LLVM_DEFINE_ONCE_FLAG definition with platform specific macros to avoid the
crash, at least for the moment?

Thanks!
Samuel
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141103/68792fa3/attachment.html>

The MSVC STL has a similar problem, and call_once isn't available in
mingw64-win32. We have some hand-rolled double checked locking that you can
probably use to workaround it.

That said, in the long term I would like to be able to rely on standard
C++11 constructs.

On Mon, Nov 3, 2014 at 5:19 PM, Samuel F Antao <sfantao at us.ibm.com>
wrote:
> 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 (or probably some
> oldish libstdc++ versions). Is this a known issue? Should we guard
> LLVM_DEFINE_ONCE_FLAG definition with platform specific macros to avoid the
> crash, at least for the moment?
>
> Thanks!
> Samuel
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141103/26a7aad0/attachment.html>

Hi Samuel,

I haven't encountered this problem.  What gcc/libstdc++ are you using?
BE or LE?

Copying Adhemerval in case he has heard of any related issues.

Thanks,
Bill

On Mon, 2014-11-03 at 20:19 -0500, Samuel F Antao wrote:
> 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 (or probably some
> oldish libstdc++ versions). Is this a known issue? Should we guard
> LLVM_DEFINE_ONCE_FLAG definition with platform specific macros to
> avoid the crash, at least for the moment?
> 
> Thanks!
> Samuel
> 
>

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 linux.vnet.ibm.com> wrote on 11/04/2014 11:45:06
AM:
> From: Bill Schmidt <wschmidt at linux.vnet.ibm.com>
> To: Samuel F Antao/Watson/IBM at IBMUS
> Cc: LLVM Dev <llvmdev at cs.uiuc.edu>, beanz at apple.com, Hal Finkel
> <hfinkel at anl.gov>, azanella at linux.vnet.ibm.com
> Date: 11/04/2014 11:45 AM
> Subject: Re: Issue with std::call_once in PPC64 platform
>
> Hi Samuel,
>
> I haven't encountered this problem.  What gcc/libstdc++ are you using?
> BE or LE?
>
> Copying Adhemerval in case he has heard of any related issues.
>
> Thanks,
> Bill
>
> On Mon, 2014-11-03 at 20:19 -0500, Samuel F Antao wrote:
> > 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 (or probably some
> > oldish libstdc++ versions). Is this a known issue? Should we guard
> > LLVM_DEFINE_ONCE_FLAG definition with platform specific macros to
> > avoid the crash, at least for the moment?
> >
> > Thanks!
> > Samuel
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141104/1a321051/attachment.html>

On Tue, 2014-11-04 at 10:45 -0600, Bill Schmidt wrote:
> Hi Samuel,
> 
> I haven't encountered this problem.  What gcc/libstdc++ are you using?
> BE or LE?
Never mind!  We see this, but only when building for self-host.  The
PPC64 clang self-host buildbot has been failing with problem as well.

It would be good to have a fix for this issue, however temporary.

Thanks,
Bill
> 
> Copying Adhemerval in case he has heard of any related issues.
> 
> Thanks,
> Bill
> 
> On Mon, 2014-11-03 at 20:19 -0500, Samuel F Antao wrote:
> > 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 (or probably some
> > oldish libstdc++ versions). Is this a known issue? Should we guard
> > LLVM_DEFINE_ONCE_FLAG definition with platform specific macros to
> > avoid the crash, at least for the moment?
> > 
> > Thanks!
> > Samuel
> > 
> > 
>