[flang-commits] [PATCH] D158957: [flang][runtime] Avoid dependency on libc++ for `std::__libcpp_verbose_abort`

[Martin Storsjö via Phabricator via flang-commits]

mstorsjo added a comment.

In D158957#4620530 <https://reviews.llvm.org/D158957#4620530>, @mmuetzel wrote:

> I might be misunderstanding how that is supposed to work. But according to this, users are meant to be able to override this specific symbol from libc++:
> https://libcxx.llvm.org/UsingLibcxx.html#overriding-the-default-termination-handler

Right, so this specific symbol is something that user code is allowed to override, when using libc++. I'm quite uneasy in having C++-library-agnostic code defining functions specific for one C++ library implementation. (Yes, admittedly, defining this if using another C++ standard library is probably harmless.)

The main question to me is that, as far as I know, the flang runtime isn't supposed to rely on the C++ runtime. Right?

Yet there is something in the C++ headers that generates this reference to `__libcpp_verbose_abort` in that case. As start to figuring out where this dependency creeps in - I see in the error message `>>> referenced by libFortranRuntime.a(io-api.cpp.obj):(std::__1::__throw_bad_variant_access[abi:v170000]())` (and a couple other object files). So, what produces the calls to `__throw_bad_variant_access`? I guess this is generated from header inline code. From grepping libc++ headers, I find calls to `__throw_bad_variant_access` in the `<variant>` header - and the flang runtime indeed seems to be using `<variant>`.

So the situation is that the flang runtime isn't supposed to depend on the standard C++ library - yet the flang runtime uses `<variant>` from the C++ standard library - I guess this is done while hoping that this ends up as all inline code not producing any references to symbols that would need to be linked from the C++ library. But I presume that no C++ standard library gives any guarantees about what things you can or cannot use from headers without actually linking to the C++ library. And the flang runtime should work with any of the C++ standard libraries anyway.

I wonder why this isn't an issue in other cases. Perhaps it will be when more toolchains upgrade to a new enough version of libc++? For those cases, I guess this is a somewhat harmless workaround - but IMO it's just a brittle workaround for the flang runtime using parts of the C++ library while not wanting to link against it.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D158957/new/

https://reviews.llvm.org/D158957