[llvm-dev] Are C++17 host applications supported?

James Y Knight via llvm-dev llvm-dev at lists.llvm.org
Tue Nov 26 12:41:22 PST 2019


On Tue, Nov 26, 2019 at 1:52 PM Reid Kleckner via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> It looks like this was added here:
>
> https://github.com/llvm/llvm-project/commit/aa60b3fd875c3df1f23b9d4f491c08888e48d823
>
> IIRC Abseil has a similar problem, and they chose not to support the use
> case of ABI compat between TUs with different standard versions.
>

Abseil changed their mind, and do currently intend to *try* 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
https://github.com/abseil/abseil-cpp/blob/master/absl/base/options.h)

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.

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.
>

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.


> 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.
>

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).


> Either way, I don't think the user should have to do anything.
>
> On Mon, Nov 25, 2019 at 3:04 AM Machiel van Hooren via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi,
>>
>> I am using the llvm libraries compiled with the C++14 standard with a
>> host application that is compiled with the C++17 standard (Both on
>> Windows/MSVC). I am running into an incompatibility for which I filed a
>> bug report: https://bugs.llvm.org/show_bug.cgi?id=44131
>>
>> However, I was wondering if C++17 host applications are even supported?
>>
>> Regards,
>>
>> Machiel van Hooren
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191126/49146e4e/attachment.html>


More information about the llvm-dev mailing list