LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 16428 - support __attribute__((warning(""))) and __attribute__((error("")))
Summary: support __attribute__((warning(""))) and __attribute__((error("")))
Status: RESOLVED FIXED
Alias: None
Product: clang
Classification: Unclassified
Component: -New Bugs (show other bugs)
Version: unspecified
Hardware: PC Linux
: P enhancement
Assignee: Nick Desaulniers
URL:
Keywords:
: 10300 (view as bug list)
Depends on:
Blocks: 4068
  Show dependency tree
 
Reported: 2013-06-23 23:59 PDT by Ben Longbons
Modified: 2021-08-25 15:47 PDT (History)
8 users (show)

See Also:
Fixed By Commit(s):


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ben Longbons 2013-06-23 23:59:48 PDT
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.
Comment 1 Sean Silva 2013-06-24 01:38:55 PDT
(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.
Comment 2 Eli Friedman 2013-06-24 10:54:24 PDT
(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.
Comment 3 Ben Longbons 2013-11-02 15:47:36 PDT
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();
}
Comment 4 Aaron Ballman 2014-01-27 15:07:36 PST
*** Bug 10300 has been marked as a duplicate of this bug. ***
Comment 5 Jörn Engel 2016-05-04 15:10:09 PDT
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.
Comment 6 Eli Friedman 2016-05-04 15:43:35 PDT
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.
Comment 7 Jörn Engel 2016-05-04 15:55:05 PDT
static_assert() works for me.  And it finally gives me an excuse to s/c99/c11/ everywhere.

Thank you!
Comment 8 Nick Desaulniers 2021-01-21 11:44:18 PST
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/
Comment 9 Nick Desaulniers 2021-01-21 11:50:35 PST
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.
Comment 10 George Burgess 2021-01-21 12:09:21 PST
`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.
Comment 11 Nick Desaulniers 2021-07-14 19:00:51 PDT
https://reviews.llvm.org/D106030