On 10/6/21 7:47 AM, Aldy Hernandez via Gcc-patches wrote:
The pending patch I have from Richi fixes this. Even so, it's the
uninit code that's confused.
Sigh...every single change to the threading code shines the light on
some warning bug.
If you take the calls.ii file from the aarch64 bootstrap and break on
the warning, you can see that the uninitalized use is for
const_upper_3934 here:
<bb 102> [local count: 315357954]:
# const_upper_3934 = PHI <const_upper_3937(D)(101), _6707(293)>
if (_881 != 0)
goto <bb 103>; [50.00%]
else
goto <bb 106>; [50.00%]
<bb 103> [local count: 157678977]:
if (const_upper_3934 > _6699)
goto <bb 105>; [89.00%]
else
goto <bb 294>; [11.00%]
<bb 294> [local count: 17344687]:
<bb 104> [local count: 157678977]:
goto <bb 107>; [100.00%]
<bb 105> [local count: 140334290]:
stack_usage_map.481_3930 = stack_usage_map;
_6441 = const_upper_3934 - _6699;
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PROBLEMATIC READ HERE
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
_4819 = stack_usage_map.481_3930 + _6699;
__builtin_memset (_4819, 1, _6441);
goto <bb 104>; [11.00%]
const_upper_3934 could be undefined if it comes from BB101
(const_upper_3937(D)), but it only gets read for _881 != 0, so it
shouldn't warn.
I suggest -Wmaybe-uninitialized be turned off for that file until the
warning is fixed.
-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
And yes, the proposed patch will also cure this, but the underlying
problem in the warning is still there.
Aldy
On Wed, Oct 6, 2021 at 3:24 PM Andreas Schwab <sch...@linux-m68k.org> wrote:
On Okt 05 2021, Aldy Hernandez via Gcc-patches wrote:
From 5abe65668f602d53b8f3dc515508dc4616beb048 Mon Sep 17 00:00:00 2001
From: Aldy Hernandez <al...@redhat.com>
Date: Tue, 5 Oct 2021 15:03:34 +0200
Subject: [PATCH] Loosen loop crossing restriction in threader.
Crossing loops is generally discouraged from the threader, but we can
make an exception when we don't cross the latch or enter another loop,
since this is just an early exit out of the loop.
This breaks bootstrap on aarch64 (in stage2):
In function 'void mark_stack_region_used(poly_uint64, poly_uint64)',
inlined from 'rtx_def* emit_library_call_value_1(int, rtx, rtx,
libcall_type, machine_mode, int, rtx_mode_t*)' at ../../gcc/calls.c:4536:29:
../../gcc/calls.c:206:26: error: 'const_upper' may be used uninitialized in
this function [-Werror=maybe-uninitialized]
206 | stack_usage_map[i] = 1;
| ~~~~~~~~~~~~~~~~~~~^~~
../../gcc/calls.c: In function 'rtx_def* emit_library_call_value_1(int, rtx,
rtx, libcall_type, machine_mode, int, rtx_mode_t*)':
../../gcc/calls.c:202:39: note: 'const_upper' was declared here
202 | unsigned HOST_WIDE_INT const_lower, const_upper;
| ^~~~~~~~~~~
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
