[PATCH] D142279: [cmake] Use LLVM_ENABLE_ASSERTIONS to enable assertions in libstdc++

David Blaikie via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Jan 30 11:02:27 PST 2023


dblaikie added a comment.

In D142279#4090165 <https://reviews.llvm.org/D142279#4090165>, @rovka wrote:

> In D142279#4088057 <https://reviews.llvm.org/D142279#4088057>, @foad wrote:
>
>> I've investigated a bit more. It's a difference between libstdc++-11 and libstdc++-12, caused by this patch:
>>
>> https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=a54ce8865a885bca5ab9c4aa6ec725cd13c09901
>>
>> Previously a failed assertion would print a message with `__builtin_printf`. Now it prints a message by calling `__glibcxx_assert_fail` which is defined in the library.
>>
>> What's the way forward for the flang runtime library? Can we disable libstdc++ assertions? Can we provide our own implementation of __glibcxx_assert_fail?
>
> Well, the flang runtime library definitely doesn't want <https://flang.llvm.org/docs/IORuntimeInternals.html#:~:text=it%20is%20intended%20to%20not%20have%20any%20link%2Dtime%20dependences%20on%20the%20C%2B%2B%20runtime%20support%20library> a dependency on libstdc++.
>
> I'm not sure what to say about enabling or disabling the libstdc++ assertions. What do other runtimes do? It might be sensible to disable them, since flang users wouldn't be able to control this and may not even be aware of whether or not their flang was built with assertions enabled. From what I can see, for now the assertions only appear in the IO part of the runtime, so we wouldn't be introducing unwanted asserts in people's performance-sensitive code, but it still feels safer to disable these for the runtime libraries (FortranRuntime and FortranDecimal).
>
> EDIT: I asked on the flang slack instance, hopefully we'll get an opinion from someone more actively involved.

It looks like compiler-rt uses the standard library & it seems OK to me that that runtime could be built with different flags/with assertions or not? What's the concern? That someone might have a runtime library that performs poorly without knowing it? Presumably that's already possible if they build the runtime library without optimizations enabled?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142279



More information about the llvm-commits mailing list