GCC supports these attributes for warning if a function is actually used. They are subtly different than __attribute__((deprecated(""))) in that they are emitted after DCE. They also give a different type of warning: [enabled by default] instead of [-Wdeprecated-declarations] I don't know much about LLVM internals, but you might need to take care for the case where the attribute is on an inline function.
(In reply to comment #0) > They are subtly different than __attribute__((deprecated(""))) in that they > are emitted after DCE. It's unlikely that we will ever implement these semantics because we generally don't believe in optimization-dependent warnings.
(In reply to comment #1) > It's unlikely that we will ever implement these semantics because we > generally don't believe in optimization-dependent warnings. That's true... but DiagRuntimeBehavior is probably a good enough approximation considering that people generally like their code to compile at -O0.
In the following testcase, clang already generates *no* calls to the function. __attribute__((error("this would be a linker error"))) void dont_call_me(); inline void wrapper() { dont_call_me(); } void conditional() { if (0) dont_call_me(); }
*** Bug 10300 has been marked as a duplicate of this bug. ***
I don't understand how this would be an optimization-dependent warning. It is a common need to break the build if some condition is violated. A simple example would be checking that the size of ondisk data structures hasn't changed. SIZE_CHECK(logfs_disk_super, 256); The Linux kernel currently has ~1500 instances of BUILD_BUG_ON, so there is a large need. You can create an array with a negative size, but the resulting error message is somewhat misleading. __attribute__((error(""))) is a much nicer solution. I'm currently spreading this pattern to malloc code and cannot use __attribute__((error(""))) if I want to support llvm. Makes me wonder if I need to support llvm.
Take the following testcase: __attribute((error("asdf"))) int f(); int g() { int g = 1; if (g == 0) f(); } In gcc, this produces an error at -O0, but not -O2, hence "optimization-dependent". If you just want something like the Linux kernel's BUILD_BUG_ON, you can just use C11 static_assert.
static_assert() works for me. And it finally gives me an excuse to s/c99/c11/ everywhere. Thank you!
These attributes are used extensively through the Linux kernel to provide ergonomic build failures. See also: https://github.com/ClangBuiltLinux/linux/issues/1173, https://lore.kernel.org/lkml/CAKwvOdko=t=wBsiwwMaWOLuir09jLi-r_oyr=1q-HRsi=-DjoA@mail.gmail.com/
Sorry, https://lore.kernel.org/lkml/6b25ce92-7ffa-9fdb-c114-e7aa8f987b06@pobox.com/ is more representative of why the Linux kernel cannot switch to _Static_assert wholesale.
`diagnose_if` is what we use in FORTIFY for similar effect. It's always going to be functionally different than __attribute__(({error,warning}(""))), since it's not evaluated after optimizations, but it's as close as we can get today (and IDK how much people like the idea of post-optimization errors/warnings a la __attribute__((error))/etc). example: https://godbolt.org/z/4x8bGe dunno how much it'd buy you in the kernel, though.
https://reviews.llvm.org/D106030
Should be fixed in clang-14: - https://reviews.llvm.org/rG846e562dcc6a9a611d844dc0d123da95629a0567 - https://reviews.llvm.org/rGb72fd31bdaf2cba3bac03a1d83a231266160527c