On 10/6/2021 10:22 AM, Aldy Hernandez via Gcc-patches wrote:
On Wed, Oct 6, 2021 at 5:03 PM Martin Sebor <mse...@gmail.com> wrote:
On 10/6/21 7:47 AM, Aldy Hernandez via Gcc-patches wrote:
-Wmaybe-uninitialized certainly suffers from a high rate of false
positives (I count 40 open PRs). Even after all this time debugging
it I still struggle with the code for it but in all the bug reports
I've reviewed, only a small subset seems to be due to bugs or even
limitations in it. Most are inherent in its design goal to warn
for reads from variables that cannot be proven to have been
initialized.
If this one is a bug with some chance of getting fixed it would
be good to distill it to a small test case (even though it's not
unlikely that there already is an existing report with the same
root cause).
That said, from from your description and the IL above it sounds
to me like the uninitialized read here is possible (it takes place
when _881 != 0), and so -Wmaybe-uininitialized triggers as it's
supposed to.
Either way, rather than suppressing the warning for the whole file
I would suggest to consider initializing the local variable instead.
Looking at the code in calls.c, I can't convince myself that
the variable cannot, in fact, be used uninitialized.
Martin
FWIW, libgomp/team.c suffers from the same problem if you remove the
stop-gap in gomp_team_start():
struct gomp_thread_start_data *start_data = NULL;
The use of start_data in the block predicated by "if (nested)" is the
only path that can use start_data without passing through its
initialization. But the only way to elide the initialization is from:
if (!nested)
{
...
....
if (i == nthreads)
goto do_release;
}
So the use of start_data either crosses the gomp_alloca
initialization, or is predicated by if(nested).
It may simply be the case that the uninit analysis gave up or it may
have failed to simplify its predicates enough to realize the use is
properly guarded. These things certainly do happen.
Of course this is all part of why we try so hard to thread jumps to
aggressively. Missed jump threads closely correlate with bogus
uninitialized warnings due to infeasible paths in the CFG. In my mind
the predicate analysis we do for uninit is primarily there to catch
cases that jump threading discovers, but does not optimize due to cost.
Jeff
