[Bug tree-optimization/65178] incorrect -Wmaybe-uninitialized when using nested loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65178 Martin Sebor changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |7.0 Resolution|--- |FIXED CC||msebor at gcc dot gnu.org --- Comment #18 from Martin Sebor --- Bisection points to r246021 as the fix.
[Bug tree-optimization/65178] incorrect -Wmaybe-uninitialized when using nested loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65178 --- Comment #17 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:b362d7947b37059fdb6de62145fa5146258dd58f commit r12-2475-gb362d7947b37059fdb6de62145fa5146258dd58f Author: Martin Sebor Date: Thu Jul 22 11:49:33 2021 -0600 Add new test for PR65178. gcc/testsuite/ChangeLog: PR tree-optimization/65178 * gcc.dg/uninit-pr65178.c: New test.
[Bug tree-optimization/65178] incorrect -Wmaybe-uninitialized when using nested loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65178 --- Comment #16 from Leon Winter --- I just checked again with gcc 9.2.1 and the issue disappeared.
[Bug tree-optimization/65178] incorrect -Wmaybe-uninitialized when using nested loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65178 --- Comment #15 from Manuel López-Ibáñez --- (In reply to Leon Winter from comment #14) > I am not sure how smart he diagnostic of GCC is supposed to be it seems that > the source base of GCC itself has fallen victim to the false warning. -Wmaybe-uninitialized has many well-known bugs (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639) and, in addition, it can never be perfect (see Problem 6 at https://gcc.gnu.org/wiki/Better_Uninitialized_Warnings#Current_Situation).
[Bug tree-optimization/65178] incorrect -Wmaybe-uninitialized when using nested loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65178 --- Comment #14 from Leon Winter --- I am not sure how smart he diagnostic of GCC is supposed to be it seems that the source base of GCC itself has fallen victim to the false warning. The following commit fixes a -Wmaybe-uninitialized warning: commit 4dae4a1aef68d3947f10a2901c957784958f212a Author: jakub Date: Sun Jan 17 18:04:47 2016 + * omp-low.c (mark_loops_in_oacc_kernels_region): Work around -Wmaybe-uninitialized warning. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@232484 138bc75d-0d04-0410-961f-82ee72b054a4 However looking at the source code at the point of the actual usage of the variable it must be set. The branch-return-condition before ensures nr_outer_loops == 1 which can only be true if it was set in the loop. If that is true, the variable single_outer must be set to loop which is again must be != null (as per loop breaking condition). The commiter called the change a "work around" which indicates he was aware the initialization might not have been needed.
[Bug tree-optimization/65178] incorrect -Wmaybe-uninitialized when using nested loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65178 --- Comment #13 from Leon Winter --- The incorrect warning is only displayed when using an optimization level better than none (-O0) (this applies to your testcase and my real-world code). Your minimized test case is already wrongfully blamed by gcc-4.8. My non-testcase real-world code (C++ in -O1 and -O2 and -O3) is even more exciting since g++-4.8 complains, g++-4.9 does not but g++-5 complains again. So there might be a recurring regression in place. I will try to track down the regression from 4.9 to 5.3 since it is the latest version.
[Bug tree-optimization/65178] incorrect -Wmaybe-uninitialized when using nested loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65178 --- Comment #12 from Leon Winter --- > Are you saying that GCC 4.9 does not warn? That would be surprising and a > regression. If you could find the revision that started warning, that would > be helpful. Funny you would ask, it turns out that only in -O2 it does warn. However my test case is a simplified version of real project for which no warning is generated (even in -O2) which fails to build with GCC 5 (due to -Werror). I will try to come up with a test case more like the actual code and which would then also compile just fine (without warnings) using gcc-4.9. Your minimal testcase triggers the warning also for gcc-4.9 on every optimization level.
[Bug tree-optimization/65178] incorrect -Wmaybe-uninitialized when using nested loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65178 --- Comment #11 from Leon Winter --- Created attachment 37855 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37855&action=edit Current test case gcc version 4.9.3 $ gcc -std=gnu99 -O1 -Wall -Wextra -o foo main.c $ gcc -std=gnu99 -O2 -Wall -Wextra -o foo main.c main.c: In function 'foo': main.c:19:3: warning: 'buf' may be used uninitialized in this function [-Wmaybe-uninitialized] return buf; ^ $ gcc -std=gnu99 -O3 -Wall -Wextra -o foo main.c gcc version 5.3.1 20160205 (Debian 5.3.1-8bfw1) $ gcc-5 -O1 -Wall -Wextra -o foo main.c -std=gnu99 main.c: In function 'foo': main.c:19:10: warning: 'buf' may be used uninitialized in this function [-Wmaybe-uninitialized] return buf; ^ $ gcc-5 -O2 -Wall -Wextra -o foo main.c -std=gnu99 main.c: In function 'foo': main.c:19:10: warning: 'buf' may be used uninitialized in this function [-Wmaybe-uninitialized] return buf; ^ $ gcc-5 -O3 -Wall -Wextra -o foo main.c -std=gnu99 main.c: In function 'foo': main.c:19:10: warning: 'buf' may be used uninitialized in this function [-Wmaybe-uninitialized] return buf; ^
[Bug tree-optimization/65178] incorrect -Wmaybe-uninitialized when using nested loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65178 --- Comment #10 from Manuel López-Ibáñez --- (In reply to Leon Winter from comment #9) > > If you declare it outside the loop body, gcc generates exactly the same code > > for a 'for' and a 'do-while'. > > You are right. When I did the testing, I mistakenly left out "-O1" or such > so I did not see the warning :/ > Probably there is no way to hint to the compiler a code path is always > visited (similar to "likely()"/"unlikely()") so we will stick with gcc-4.9.x > for the time being. If you initialize buff that would silence the warning. If GCC is not able to remove the initialization at -O2, -O3, -Os, that would be a missed optimization worth reporting as a new PR. There are more devs working on optimizations than on diagnostics (I guess the former is more important to paying customers than the latter). Sometimes it just takes fixing the missed optimization to fix the warning, but other times it takes more work. Are you saying that GCC 4.9 does not warn? That would be surprising and a regression. If you could find the revision that started warning, that would be helpful.
[Bug tree-optimization/65178] incorrect -Wmaybe-uninitialized when using nested loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65178 --- Comment #9 from Leon Winter --- > If you declare it outside the loop body, gcc generates exactly the same code > for a 'for' and a 'do-while'. You are right. When I did the testing, I mistakenly left out "-O1" or such so I did not see the warning :/ Probably there is no way to hint to the compiler a code path is always visited (similar to "likely()"/"unlikely()") so we will stick with gcc-4.9.x for the time being.
[Bug tree-optimization/65178] incorrect -Wmaybe-uninitialized when using nested loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65178 --- Comment #8 from Manuel López-Ibáñez --- (In reply to Leon Winter from comment #7) > Maybe a better solution is to hint the compiler that the loop body will be > run at least once. A do-while seems to imply that (and the compiler does not > print a warning). Not for the minimized testcase. Unless you declare 'a' within the loop body, which is not exactly equivalent. If you declare it outside the loop body, gcc generates exactly the same code for a 'for' and a 'do-while'.
[Bug tree-optimization/65178] incorrect -Wmaybe-uninitialized when using nested loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65178 --- Comment #7 from Leon Winter --- > #pragma GCC diagnostic ignored "-Wuninitialized" > > is your friend. We do like this warning and threat it as an error as such situations normally are a mistake which could lead to errors later on this switching it off - even temporarily - is very much undesired. Maybe a better solution is to hint the compiler that the loop body will be run at least once. A do-while seems to imply that (and the compiler does not print a warning).
[Bug tree-optimization/65178] incorrect -Wmaybe-uninitialized when using nested loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65178 --- Comment #6 from Richard Biener --- I think the issue is that uninit doesn't even try to see whether the loop PHI node has its backedge always executed and that results in an always initialized PHI result. It's also not that easy as it doesn't perform any dataflow. With PR63278 fixed we'd fully unroll the inner loop / SCCP it and then jump-threading would "solve" this issue. But in reality we need uninit re-written in a completely different way ... #pragma GCC diagnostic ignored "-Wuninitialized" is your friend.
[Bug tree-optimization/65178] incorrect -Wmaybe-uninitialized when using nested loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65178 --- Comment #5 from Leon Winter --- Still persists.
[Bug tree-optimization/65178] incorrect -Wmaybe-uninitialized when using nested loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65178 Leon Winter changed: What|Removed |Added Version|5.0 |5.2.1 --- Comment #4 from Leon Winter --- Bug still persists.
[Bug tree-optimization/65178] incorrect -Wmaybe-uninitialized when using nested loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65178 Leon Winter changed: What|Removed |Added Version|4.9.1 |5.0 --- Comment #3 from Leon Winter --- Like, Manuel mentioned already, this in fact applies to gcc-5.0 as I was mistaken on the version (executing gcc -v on the wrong machine)
[Bug tree-optimization/65178] incorrect -Wmaybe-uninitialized when using nested loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65178 Richard Biener changed: What|Removed |Added Depends on||63278 --- Comment #2 from Richard Biener --- Related to PR63278.
[Bug tree-optimization/65178] incorrect -Wmaybe-uninitialized when using nested loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65178
Manuel López-Ibáñez changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-02-23
CC||manu at gcc dot gnu.org
Blocks||24639
Ever confirmed|0 |1
--- Comment #1 from Manuel López-Ibáñez ---
A minimized testcase:
void *bar(int);
char *
foo (void)
{
char *c = "bla";
char *buf;
for (int a = 1;; a = 0)
{
for (char *s = c; *s; ++s)
{
}
if (!a) break;
buf = (char *) bar (1);
}
return buf;
}
It fails in GCC 5.0 with -O1, -O2 and -O3. I think we have several reports
about this: GCC simply does not understand that the loop body is executed at
least once, thus there should be no (default) entry edge for the PHI node of
buf.
I think it is a missed optimization also: If buf were initialized, the initial
value could be dropped.
