<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Oct 31, 2016 at 11:21 AM, Joerg Sonnenberger via cfe-commits <span dir="ltr"><<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_-3777240293980226567gmail-">On Mon, Oct 31, 2016 at 10:45:05AM -0700, Richard Smith via cfe-commits wrote:<br>
> On Sun, Oct 30, 2016 at 12:32 PM, Joerg Sonnenberger <<a href="mailto:joerg@bec.de" target="_blank">joerg@bec.de</a>> wrote:<br>
><br>
> > On Sun, Oct 30, 2016 at 12:54:28PM -0600, Eric Fiselier wrote:<br>
> > > Richard requested this change. Take a look at<br>
> > > <a href="https://reviews.llvm.org/D26044" rel="noreferrer" target="_blank">https://reviews.llvm.org/D2604<wbr>4</a> for more rational.<br>
> ><br>
> > I don't see much rational and in fact, I disagree with some of the<br>
> > mentioned items. E.g. presence of libc++ won't tell you if you can use<br>
> > sized deallocation as that's a ABI library issue.<br>
><br>
><br>
> The real situation is a lot more subtle than that. Every one of libc++abi,<br>
> libcxxrt, libc++, libsupc++, and libstdc++ provides definitions of global<br>
> operator new and operator delete. It's obviously not part of the Itanium<br>
> C++ ABI, so it's not the responsibility of a pure "ABI library" to provide<br>
> it, but the boundary between the ABI library and the standard library has<br>
> never been formally defined.<br>
<br>
</span>That doesn't actually invalidate anything I said.</blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">But the make the<br>
argument even more explicit: any detection based on magic files in the<br>
include directories are breaking important properties. A preprocessed<br>
file is now no longer independent of the build system.</blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div></div></div></div>