[flang-commits] [PATCH] D158957: [flang][runtime] Avoid dependency on libc++ for `std::__libcpp_verbose_abort`
Peter Klausler via Phabricator via flang-commits
flang-commits at lists.llvm.org
Fri Sep 1 09:28:49 PDT 2023
klausler added a comment.
In D158957#4634584 <https://reviews.llvm.org/D158957#4634584>, @mmuetzel wrote:
> In D158957#4634449 <https://reviews.llvm.org/D158957#4634449>, @klausler wrote:
>
>> Is it known which files in flang/runtime produce this dependency on __libcpp_verbose_abort()? Or which functions? The runtime never uses std::get() on a variant, so there's no chance of that going wrong.
>>
>> If the dependency on __libcpp_verbose_abort() arises from just a few code sites, there's a good chance that we could adjust them to avoid the problem.
>
> I guess one of the places could be here (where `_u` is a `std::variant` afaict):
> https://github.com/llvm/llvm-project/blob/1c35c1a73907a95ce54b5a0edca513591e2bc069/flang/runtime/io-stmt.h#L113-L122
If so, then that's IMO a bug in whatever C++ compiler or STL that you're using, and a workaround would be justified.
Is there a chance that the call to __libcpp_verbose_abort() might be coming from the use of std::reference_wrapper<>::get() instead? I could imagine that an implementation of that member function might want to check for a bad or uninitialized internal pointer. If so, this usage of std::reference_wrapper<> could easily be changed into plain old pointers. (They are never null, and they would be C++ references (&) if those could be used in a std::variant<>.).
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D158957/new/
https://reviews.llvm.org/D158957
More information about the flang-commits
mailing list