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

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

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.

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.

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