[Bug tree-optimization/80147] missing maybe-uninitialized warning on variable with no side effects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80147 Martin Sebor changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |RESOLVED CC||msebor at gcc dot gnu.org --- Comment #7 from Martin Sebor --- Eric explained the reason for the missing warning with -O1 in the test case in comment #0. The code in the test case in comment #3 is folded away very early on so there's nothing for the warning to complain about. My guess is that Clang warns during parsing. GCC much later on, to avoid warning for dead code. It's a deliberate decision. I don't think there's anything to fix here.
[Bug tree-optimization/80147] missing maybe-uninitialized warning on variable with no side effects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80147 --- Comment #6 from Eric Gallager --- (In reply to Manuel López-Ibáñez from comment #2) > (In reply to Eric Gallager from comment #1) > > ...but if that's the case, then why doesn't the warning go away for i1, too? > > Because "is-used" is given before optimization, while may-be-used are given > after optimization. I don't think this is a bug, but expected behaviour > given that optimization should allow more precise warnings (hence, > discarding a false positive). It would be nice if we could avoid warning > about f1(i1), but that is hard with the current Wuninitialized > implementation (and a different already reported bug). Which other bug is that?
[Bug tree-optimization/80147] missing maybe-uninitialized warning on variable with no side effects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80147 --- Comment #5 from Vincent Lefèvre --- (In reply to Andrew Pinski from comment #4) > For that example you need -ftrapping-math (which may or may not be enabled > by default soon). The man page says: "The default is -ftrapping-math." But even when given explicitly, no warnings are generated. Anyway, for the integer case, 0 / 0 is undefined behavior, so that warnings are expected to make sure that one doesn't get undefined behavior.
[Bug tree-optimization/80147] missing maybe-uninitialized warning on variable with no side effects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80147 --- Comment #4 from Andrew Pinski --- >Or even on common architectures... Consider the following code: For that example you need -ftrapping-math (which may or may not be enabled by default soon).
[Bug tree-optimization/80147] missing maybe-uninitialized warning on variable with no side effects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80147
Vincent Lefèvre changed:
What|Removed |Added
Status|RESOLVED|NEW
Resolution|INVALID |---
--- Comment #3 from Vincent Lefèvre ---
(In reply to Manuel López-Ibáñez from comment #2)
> Because "is-used" is given before optimization, while may-be-used are given
> after optimization. I don't think this is a bug, but expected behaviour
> given that optimization should allow more precise warnings (hence,
> discarding a false positive).
No, this is not a false positive. Even though f1 doesn't use its parameter, the
argument is evaluated, and if the value is a trap representation (which is
possible for some architectures), the behavior is undefined (6.2.6.1#5). Thus
the calls f1(i1) and f1(j1) are possibly incorrect.
Or even on common architectures... Consider the following code:
void f (int b)
{
double x, y;
(void) (x * x);
if (b)
(void) (y * y);
}
If x or y is a signaling NaN, this could raise the invalid exception, which
could mean a possible trap. But the warnings are always missing.
Same issue with:
void f (int b)
{
int x, y;
(void) (x / x);
if (b)
(void) (y / y);
}
Clang 4.0 gives warnings as expected.
[Bug tree-optimization/80147] missing maybe-uninitialized warning on variable with no side effects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80147 Manuel López-Ibáñez changed: What|Removed |Added Status|NEW |RESOLVED CC||manu at gcc dot gnu.org Resolution|--- |INVALID --- Comment #2 from Manuel López-Ibáñez --- (In reply to Eric Gallager from comment #1) > ...but if that's the case, then why doesn't the warning go away for i1, too? Because "is-used" is given before optimization, while may-be-used are given after optimization. I don't think this is a bug, but expected behaviour given that optimization should allow more precise warnings (hence, discarding a false positive). It would be nice if we could avoid warning about f1(i1), but that is hard with the current Wuninitialized implementation (and a different already reported bug).
[Bug tree-optimization/80147] missing maybe-uninitialized warning on variable with no side effects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80147
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-10-01
Ever confirmed|0 |1
--- Comment #1 from Eric Gallager ---
Confirmed, probably because optimization lets gcc take advantage of knowledge
that f1 doesn't actually use its parameter:
$ /usr/local/bin/gcc -c -Wall -Wextra -O1 80147.c
80147.c: In function ‘f1’:
80147.c:2:21: warning: unused parameter ‘i’ [-Wunused-parameter]
static void f1 (int i) { }
^
80147.c: In function ‘g’:
80147.c:8:2: warning: ‘i1’ is used uninitialized in this function
[-Wuninitialized]
f1 (i1);
^~~
80147.c:9:2: warning: ‘i2’ is used uninitialized in this function
[-Wuninitialized]
f2 (i2);
^~~
80147.c:3:26: warning: ‘j2’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
static void f2 (int i) { f0 (i); }
^~
80147.c:7:18: note: ‘j2’ was declared here
int i1, i2, j1, j2;
^~
$
...but if that's the case, then why doesn't the warning go away for i1, too?
