<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 26, 2019 at 1:52 PM Reid Kleckner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">It looks like this was added here:<div><a href="https://github.com/llvm/llvm-project/commit/aa60b3fd875c3df1f23b9d4f491c08888e48d823" target="_blank">https://github.com/llvm/llvm-project/commit/aa60b3fd875c3df1f23b9d4f491c08888e48d823</a>  <br></div><div>IIRC Abseil has a similar problem, and they chose not to support the use case of ABI compat between TUs with different standard versions.</div></div></blockquote><div><br></div><div>Abseil changed their mind, and do currently intend to <i>try</i> to support this usage, by making the options which do things like switch class implementations be configure-time selected, rather than autodetected. (See the beginnings of this in <a href="https://github.com/abseil/abseil-cpp/blob/master/absl/base/options.h">https://github.com/abseil/abseil-cpp/blob/master/absl/base/options.h</a>)</div><div><br></div><div>It turns out users really do want to be able to do this. And it's especially important if you're depending on a distro-provided libabseil.so -- which they want to support. Having application code be unable to opt-into a newer C++ version than the default version used by the distro is not a great situation.</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"><div dir="ltr"><div></div><div>Personally, IMO LLVM should support this use case. I think it was a mistake to add inline functions to Compiler.h, which is supposed to be all about feature detection and macro definitions.</div><div></div></div></blockquote><div><br></div><div>This sort of thing is hard to make a guarantee about it. But I would argue that LLVM could try to support it similarly to how we try to support mixing NDEBUG and !NDEBUG.</div><div>  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>Alternatively if people want to keep things the way they are, we should change LLVM's CMake to build with C++17 if it is supported. If the user can link against LLVM and enable C++17, then the standard library shared by the user and LLVM *must* have an aligned allocation function.</div></div></blockquote><div><br></div><div>That option wouldn't work either, if the function remains in the header. It'll just break user code built with standards earlier than C++17, rather than breaking user code built with C++17. (Neither allocating with aligned-new and freeing with unaligned-delete, nor allocating with unaligned-new and freeing with aligned-delete is acceptable).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>Either way, I don't think the user should have to do anything.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 25, 2019 at 3:04 AM Machiel van Hooren via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
I am using the llvm libraries compiled with the C++14 standard with a <br>
host application that is compiled with the C++17 standard (Both on <br>
Windows/MSVC). I am running into an incompatibility for which I filed a <br>
bug report: <a href="https://bugs.llvm.org/show_bug.cgi?id=44131" rel="noreferrer" target="_blank">https://bugs.llvm.org/show_bug.cgi?id=44131</a><br>
<br>
However, I was wondering if C++17 host applications are even supported?<br>
<br>
Regards,<br>
<br>
Machiel van Hooren<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>