| Issue |
104734
|
| Summary |
FR: Have -fno-exceptions cause noexcept operator/std::is_nothrow_...() to treat functions as if they were non-throwing
|
| Labels |
new issue
|
| Assignees |
|
| Reporter |
pkasting
|
Chromium compiles (everything, including the STL) with `-fno-exceptions`. However, tests like the `noexcept` operator or `std::is_nothrow_move_constructible<>()` still treat functions as potentially-throwing unless they are explicitly marked `noexcept`. This means authors must still mark various places (e.g. move constructors of objects potentially stored in vectors) as `noexcept` to avoid potential pessimizations.
I believe it's also potentially pessimizing to blindly mark every function as `noexcept`, especially if functions we author call into third-party code not so marked; IIRC, the compiler has to emit code to handle potential exceptions from such code? When I discussed this a few years ago with some LLVM person (I forget who), I think this was a reason that we wouldn't want `-fno-exceptions` to actually compile code equivalent to if the coder had written `noexcept` on every declaration. (Sorry, memory is fuzzy; I just remember there was a good reason to not do "the simple thing" here.)
One possible way to have our cake and eat it too would be to have `-fno-exceptions` cause the `noexcept` operator, along with builtins like `__is_nothrow_constructible()` (which I think are what libc++ implements the STL in terms of), always claim that functions so queried were, indeed, non-throwing. Presumably this would lead to crashes or worse if code compiled this way was linked against a library not compiled this way; we'd be OK with that.
Hopefully, this would result in things like `constexpr if` fast-paths for non-throwing code always being taken, without the downsides of actually treating all contexts as `noexcept`, and without authors having to remember to so tag code.
![]()
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
