[Bug tree-optimization/106992] [12/13 Regression] aarch64: Unexpected maybe-uninitialized warning when compiling fdlibm

[rguenth at gcc dot gnu.org]

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