<div dir="ltr"><div dir="ltr">On Tue, Nov 26, 2019 at 10:51 AM Reid Kleckner <<a href="mailto:rnk@google.com">rnk@google.com</a>> wrote:<br></div><div class="gmail_quote"><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" class="cremed">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>FWIW, they did this because it is *hard*.</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><br></div><div>Personally, IMO LLVM should support this use case.</div></div></blockquote><div><br></div><div>FWIW, I think that LLVM should make the same decision as Abseil in general here. ABI compatibility between TUs with different standard versions is extremely hard IMO if you care deeply about inlining.</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> 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></blockquote><div><br></div><div>Sure, happy to see the inline functions moved elsewhere. However, I think we'll find that will just kick the can down the road. I don't think it will fully address the underlying issues here.</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><br></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><br></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" class="cremed">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" class="cremed">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" class="cremed">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="cremed">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
</blockquote></div></div>