https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106992
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target|aarch64 |aarch64, x86_64-*-*
Ever confirmed|0 |1
Last reconfirmed| |2022-09-21
Status|UNCONFIRMED |NEW
Target Milestone|--- |12.3
Blocks| |24639
Priority|P3 |P2
Summary|aarch64: Unexpected |[12/13 Regression] aarch64:
|maybe-uninitialized warning |Unexpected
|when compiling fdlibm |maybe-uninitialized warning
| |when compiling fdlibm
CC| |rguenth at gcc dot gnu.org
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed without -fno-strict-aliasing and with -fno-tree-vectorize
-fno-strict-aliasing on x86_64.
It's a bit odd - I traced walk_aliased_vdefs and indeed it didn't come along
a definition of fq. We diagnose a PRE hoisted fq[0] but even with
-fno-tree-pre -fno-code-hoisting we diagnose that.
-fno-thread-jumps avoids the diagnostic. The reference we diagnose is
introduced by thread2:
k_rem_pio2.c.195t.thread2: _508 = fq[0];
This case is
jump thread: (80, 136) incoming edge; (88, 90) normal (90, 94) nocopy;
<bb 80> [local count: 437174]:
<L145>:
if (jz_117 >= 0)
goto <bb 86>; [89.00%]
else
goto <bb 88>; [11.00%]
<bb 88> [local count: 437174]:
# fw_363 = PHI <fw_260(87), 0.0(80)>
if (ih_111 != 0)
goto <bb 90>; [50.00%]
else
goto <bb 89>; [50.00%]
<bb 90> [local count: 218587]:
iftmp.2_253 = -fw_363;
*y_237(D) = iftmp.2_253;
_85 = fq[0];
fw_255 = _85 - fw_363;
if (jz_117 > 0)
goto <bb 91>; [89.00%]
else
goto <bb 94>; [11.00%]
so it might be that we somehow thread a jz < 0 case (which would skip
the init loop) but I still can't see how ...
I've used
-Wall -O2 -std=c11 k_rem_pio2.c -fno-tree-vectorize -fno-strict-aliasing
-fno-code-hoisting -fno-tree-pre
for the above.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues
