[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