llvm dev - Nov 2019 - Are C++17 host applications supported?

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

We don’t claim it’s unsupported, therefore by default it should be
supported imo.  That said, I don’t think anyone has ever explicitly asked
this or tried it before.  Usually these types of things are community
supported — ie someone sees a problem and takes t upon themselves to fix it.

So I think it’s reasonable to move these implementations to the cpp file as
you suggested in the bug report



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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191125/77bca4d6/attachment.html>

Compiler.h seems to be all about feature detection.  There may be other 
issues related to feature detection that are still undiscovered and it's 
hard to prevent new issues from being introduced this way.

Perhaps a better solution is to explicitly not support the mixing of C++ 
standards between the LLVM libraries and the application that's using 
them. This would for the most part squash this class of bugs. An error 
would need to be generated at compile time of the application if mixed 
standards are detected.

This does not mean that C++17 applications are not supported, just that 
you'd have to also compile LLVM with C++17 enabled.

Machiel

On 26-Nov-19 05:46, Zachary Turner wrote:
> We don’t claim it’s unsupported, therefore by default it should be 
> supported imo.  That said, I don’t think anyone has ever explicitly 
> asked this or tried it before. Usually these types of things are 
> community supported — ie someone sees a problem and takes t upon 
> themselves to fix it.
>
> So I think it’s reasonable to move these implementations to the cpp 
> file as you suggested in the bug report
>

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.

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.

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.

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191126/528d0f06/attachment.html>

On Tue, Nov 26, 2019 at 10:51 AM Reid Kleckner <rnk at google.com> 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.
>
FWIW, they did this because it is *hard*.

>
> Personally, IMO LLVM should support this use case.
>
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.

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

> 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.
>
> 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191126/6f7fde9c/attachment.html>

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>