Issue |
152561
|
Summary |
-Wunreachable-code-aggressive behaves strangely w/macros
|
Labels |
new issue
|
Assignees |
|
Reporter |
pkasting
|
Summary: `-Wunreachable-code-aggressive` triggers differently in the presence of macros, in some cases in bogus ways that seemingly can't be worked around.
Full description:
With `-Wunreachable-code-aggressive`, the following code somewhat-expectedly produces a warning that `f()` is unreachable:
```
true || f();
```
It also tells me to surround `true` with parens to silence, which indeed works.
Strangely, if this is instead a macro:
```
#define GOOD true
GOOD || f();
```
...then the warning is silent. I wouldn't have expected a difference since the two should be identical after the preprocessor runs.
Worse, however, is that if the macro has parens:
```
#define BAD (true)
BAD || f();
```
...then not only does the warning return, the note has disappeared, and there's no obvious way to silence the warning: Using `(BAD) || f();` or `(BAD || f());` or `BAD ? (void)0 : f();` all still warn. (Of course `f() || BAD;` would work, but calls `f()` in more scenarios, which may be undesirable.)
Sample code: https://godbolt.org/z/4ExznMTWr
This is problematic in Chromium, where we want to do things like
```
void f() {
InitSomething(ON_PLATFORM_X() || HaveFeatureY());
}
```
...and `ON_PLATFORM_X()` is a macro set by the build system to be `(0)` or `(1)`. It might be possible to un-parenthesize what the macro evaluates to, but that seems very risky for widely-used low-level macros and IMO ought not to be necessary.
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs