[cfe-dev] C++11 ABI Compatibility and Static Initialization

[Richard Smith]

On Mon, Apr 14, 2014 at 8:46 AM, Kevin Locke <kevin at kevinlocke.name> wrote:

>
> On Sun, 2014-04-13 at 17:36 -0700, Richard Smith wrote:
> > On Mon, Apr 7, 2014 at 3:11 PM, Kevin Locke <kevin at kevinlocke.name>
> wrote:
> >> I've been trying to track down an EXC_BAD_ACCESS error (Bus error: 10)
> >> which occurs during static initialization when linking a program using
> >> boost to a library using boost.  The problem occurred, for me, with
> >> QuantLib, but it has been reported to occur with mlpack[1] and likely
> >> affects other boost-using libraries as well.  I have determined that
> >> the issue occurs when a library is compiled with -std=c++11 and the
> >> program is not (or vice versa).
> >
> > This is a known issue that we've discussed in the past (though I can't
> find
> > a record of the discussion right now). The issue, in the general case, is
> > that it's possible for a common variable (local static or static data
> > member of a class template specialization or variable template
> > specialization) to have static initialization in one translation unit and
> > dynamic initialization in another.
> >
> > The approach we came up with was:
> >
> >   * put the variable and its guard variable in a COMDAT together, as the
> > ABI document suggests (LLVM doesn't yet have the machinery for this)
> >   * if we constant-initialize a common variable, but we can't prove that
> > every other translation unit that sees it will also constant-initialize
> it,
> > emit a guard variable statically initialized to the 'already initialized'
> > value
> >
> > ... but we've not implemented anything like this yet.
>
> That explains it very well.  Thanks!
>
> Do you know if there is a bug filed for tracking progress on the
> issue?  I didn't see anything in Bugzilla but may not have been
> searching with the right keywords.


I don't know of one; please go ahead and file one. Duplicates are cheap :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140414/591f88e3/attachment.html>