[Bug c/70477] -Wtautological-compare too aggressive?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70477 --- Comment #9 from Eric Gallager --- *** Bug 92668 has been marked as a duplicate of this bug. ***
[Bug c/70477] -Wtautological-compare too aggressive?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70477 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #8 from Martin Sebor --- A cast suppresses the warning so that might be a solution (or a workaround) in the _Static_assert case: _Static_assert ((void*)&a == (void*)A, "&a must be A");
[Bug c/70477] -Wtautological-compare too aggressive?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70477
Petr Vandrovec changed:
What|Removed |Added
CC||petr at vandrovec dot name
--- Comment #7 from Petr Vandrovec ---
Would it be possible to special-case parameter for _Static_assert, as whole
purpose of _Static_assert is to have constant value that is non-zero?
We have in our code base code that ends up calling _Static_assert() with really
complicated constant expression.
When regular gcc is used, code compiles fine with all optimization levels, as
gcc recognizes there are complicated macros involved, and backs off. When
ccache is used, it preprocesses source in separate step, and gcc will complain
about tautological compare inside _Static_assert :-(
Would it be possible to either suppress warning when used as parameter for
_Static_assert, or remove tautological-compare warnings if -fpreprocessed is
passed to the compiler, as macro heuristics are subverted by doing
preprocessing in separate step?
Example (our code is more complicated, this is simplest example I came up
with):
$ cat test.c
#define A &a
int a;
void test(void) {
_Static_assert(&a == A, "&a must be A");
}
$ gcc -c -Wall -Werror test.c
$ gcc -c -Wall -Werror test.c -no-integrated-cpp
x.c: In function 'test':
x.c.:5:22: error: self-comparison always evaluates to true
[-Werror=tautological-compare]
_Static_assert(&a == A, "&a must be A");
cc1: all warnings being treated as errors
It happens with 8.2.0, as well as with 6.4.0.
$ gcc --version
gcc (Debian 8.2.0-6) 8.2.0
[Bug c/70477] -Wtautological-compare too aggressive?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70477 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #6 from Manuel López-Ibáñez --- (In reply to ecloud from comment #5) > If a macro exists in order to test something and generate different code > depending on the test result, then in any given use case of the macro, we > can say that the test inside the macro is a tautology, right? But that > shouldn't mean that doing tests inside macros is bad. We want to avoid warning for macros in general because of that, and we already avoid some cases. However, GCC can only detect that something comes from a macro if it expands to something for which GCC tracks locations. GCC currently does not track locations for constants (0), variable-uses (x) and some simple expressions that may get folded too early. So if you have !!0 or 0 != 1, GCC right now cannot tell whether this is the result of macro expansion (at the point of warning). It is not likely that the bug will get fixed in the near term, so if you think that you may still want this warning in general, a work-around is to disable this warning for the relevant line using #pragma GCC diagnostic.
[Bug c/70477] -Wtautological-compare too aggressive?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70477 ecloud changed: What|Removed |Added CC||s at ecloud dot org --- Comment #5 from ecloud --- >From my perspective it looks like https://bugreports.qt.io/browse/QTBUG-53373 is also a case of -Wtautological-compare being too aggressive too; but I'm not an expert on that code, and it might turn out that someone comes up with some solution other than disabling the warning. If a macro exists in order to test something and generate different code depending on the test result, then in any given use case of the macro, we can say that the test inside the macro is a tautology, right? But that shouldn't mean that doing tests inside macros is bad.
[Bug c/70477] -Wtautological-compare too aggressive?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70477 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-04-18 Ever confirmed|0 |1 --- Comment #4 from Marek Polacek --- Yep, so I'm going to confirm this, though I can't readily see any nice solution.
[Bug c/70477] -Wtautological-compare too aggressive?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70477 --- Comment #3 from ktkachov at gcc dot gnu.org --- (In reply to Marek Polacek from comment #2) > ...because neither LHS nor RHS have any location here. Hi Marek, does that mean you can reproduce?
[Bug c/70477] -Wtautological-compare too aggressive?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70477 --- Comment #2 from Marek Polacek --- ...because neither LHS nor RHS have any location here.
[Bug c/70477] -Wtautological-compare too aggressive?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70477 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- I already added 1360 /* Don't warn for various macro expansions. */ 1361 if (from_macro_expansion_at (loc) 1362 || from_macro_expansion_at (EXPR_LOCATION (lhs)) 1363 || from_macro_expansion_at (EXPR_LOCATION (rhs))) 1364 return; so it /shouldn't/ be triggering :(.
