[LLVMdev] Issue with std::call_once in PPC64 platform
Jiangning Liu
liujiangning1 at gmail.com
Tue Nov 4 16:45:24 PST 2014
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 <beanz at apple.com>:
> 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 -0500, Samuel F Antao wrote:
> >> 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.
> >
> > Hm, better hold off on that. Ulrich Weigand has noted that there is
> > invalid code generation occurring around a TLS call. Looks like is is
> > probably a PPC back end problem at the moment.
> >
> > Thanks,
> > Bill
> >
> >>
> >> 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 linux.vnet.ibm.com, beanz at apple.com, Hal Finkel
> >>> <hfinkel at anl.gov>, LLVM Dev <llvmdev at cs.uiuc.edu>
> >>> Date: 11/04/2014 12:11 PM
> >>> Subject: Re: Issue with std::call_once in PPC64 platform
> >>>
> >>> On Tue, 2014-11-04 at 11:59 -0500, Samuel F Antao wrote:
> >>>> 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?
> >>>
> >>> I don't know what the best fix is, but clearly a fix or revert is
> >> needed
> >>> since the patch is breaking some platforms.
> >>>
> >>> Thanks,
> >>> Bill
> >>>
> >>>>
> >>>> 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/20141105/9038361c/attachment.html>
More information about the llvm-dev
mailing list