Bug 90302 - Implement __builtin_warning
Summary: Implement __builtin_warning
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: unknown
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: diagnostic
Depends on: 94978
Blocks: 48655 97320
  Show dependency treegraph
 
Reported: 2019-05-01 16:04 UTC by Thomas Koenig
Modified: 2023-05-09 13:20 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2019-05-01 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Koenig 2019-05-01 16:04:41 UTC
It would be useful to implement a __builtin_warning function
to delay a warning which may be removed later by dead code
elimination.  One application could be PR48655, where warnings
are issued about temporary Fortran arrays which are eliminated
by the middle end.

See the discussion at https://gcc.gnu.org/ml/gcc/2019-04/msg00275.html .

(Come to think of it, a __builtin_error function could also be
useful in some contexts).
Comment 1 Andrew Pinski 2019-05-01 16:25:37 UTC
Error can be implement using the error attribute on a function.
Comment 2 Martin Sebor 2019-05-01 17:01:42 UTC
As Jeff said this would be useful to avoid false positives in cases like bug 89337 comment #12.
Comment 3 Richard Biener 2019-05-02 11:42:38 UTC
I'm not sure a function call is the proper way to handle this.  It would maybe be better to use a DEBUG-stmt like thing (maybe even actually a debug stmt!).

In theory it would be possible to emit those into DWARF and trigger the
warnings at runtime (under inspection of an appropriate tool like valgrind).
Comment 4 Thomas Koenig 2020-05-21 08:35:24 UTC
There is a prototype patch by Martin Sebor at

https://gcc.gnu.org/pipermail/gcc-patches/2019-October/531812.html
Comment 5 Jonathan Wakely 2023-05-09 13:18:49 UTC
This would be very useful for the C++ library where we currently have precondition checks that:

- abort at runtime if you compile with -D_GLIBCXX_ASSERTIONS, or
- fail at compile-time if they are constexpr **and** are actually evaluated during constexpr evaluation

The runtime assertions are good, but not enabled by default, and an earlier warning at compile time means the problem can be found sooner.

The constexpr errors are good, but don't apply to non-constexpr calls, even if all the arguments are known during compilation.

It would be nice to be able to also issue warnings for non-constexpr calls, when compiled without -D_GLIBCXX_ASSERTIONS.