[libcxx] r285382 - Add __libcpp_version file and __libcpp_library_version function.

[Richard Smith via cfe-commits]

On Mon, Oct 31, 2016 at 11:21 AM, Joerg Sonnenberger via cfe-commits <
cfe-commits at lists.llvm.org> wrote:

> On Mon, Oct 31, 2016 at 10:45:05AM -0700, Richard Smith via cfe-commits
> wrote:
> > On Sun, Oct 30, 2016 at 12:32 PM, Joerg Sonnenberger <joerg at bec.de>
> wrote:
> >
> > > On Sun, Oct 30, 2016 at 12:54:28PM -0600, Eric Fiselier wrote:
> > > > Richard requested this change. Take a look at
> > > > https://reviews.llvm.org/D26044 for more rational.
> > >
> > > I don't see much rational and in fact, I disagree with some of the
> > > mentioned items. E.g. presence of libc++ won't tell you if you can use
> > > sized deallocation as that's a ABI library issue.
> >
> >
> > The real situation is a lot more subtle than that. Every one of
> libc++abi,
> > libcxxrt, libc++, libsupc++, and libstdc++ provides definitions of global
> > operator new and operator delete. It's obviously not part of the Itanium
> > C++ ABI, so it's not the responsibility of a pure "ABI library" to
> provide
> > it, but the boundary between the ABI library and the standard library has
> > never been formally defined.
>
> That doesn't actually invalidate anything I said.


No, but that was just introduction to the part of my reply that you
snipped, which does: libc++, not the ABI library, provides the definition
of the symbols of interest in this case, so it's the libc++ version that we
care about.

But the make the
> argument even more explicit: any detection based on magic files in the
> include directories are breaking important properties. A preprocessed
> file is now no longer independent of the build system.


Yes, this requires distributed build systems like distcc (that preprocess
locally before distributing) to have the complete toolchain, including the
runtime libraries and standard library headers, present on each build
worker, not just the compiler. And if we're using any part of GCC in a
compilation, that complete toolchain includes the selected GCC
installation. But that is not actually a new requirement; the detected GCC
installation already affects, for instance, the default setting for
-fuse-init-array.

We could alternatively control the language features based only on the
selected language mode, and only use version detection to power a warning
for the (currently fairly common, but becoming less so) case where the
selected runtime library isn't new enough to implement the requested
features. That would cause a bunch of scenarios to break when upgrading to
clang 4.0, but at least the fix would be pretty clear.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20161031/5e28e89e/attachment.html>