[Bug tree-optimization/105109] New: [12 Regression] False positive warning on complex float code since r12-155

[Bug tree-optimization/105109] New: [12 Regression] False positive warning on complex float code since r12-155

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105109

            Bug ID: 105109
           Summary: [12 Regression] False positive warning on complex
                    float code since r12-155
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

Since r12-155-gd8e1f1d24179690fd9c0f63c27b12e030010d9ea with -O -Wall on
static void foo(int dim,float _Complex f0[])
{
  int d;
  f0[0] -= 3.14;
  for (d = 0; d < dim; ++d) f0[0] += 3.14;
}
void bar(int dim, const float _Complex u_t[], float _Complex f0[])
{
  float _Complex exp[1] = {0.};
  foo(dim, exp);
  f0[0] = u_t[0] - exp[0];
}
we emit
In function ‘foo’,
    inlined from ‘bar’ at rh2066856.c:10:3:
rh2066856.c:4:9: warning: ‘exp[0]’ is used uninitialized [-Wuninitialized]
    4 |   f0[0] -= 3.14;
      |   ~~~~~~^~~~~~~
rh2066856.c: In function ‘bar’:
rh2066856.c:9:18: note: ‘exp[0]’ was declared here
    9 |   float _Complex exp[1] = {0.};
      |                  ^~~

Before dce3 we have:
  IMAGPART_EXPR <exp$0> = 0.0;
  REALPART_EXPR <exp$0> = -3.1400001049041748046875e+0;
and then only read or modify REALPART_EXPR <exp$0> before final
  exp$0 ={v} {CLOBBER};
dce3 seems to decide that because nothing reads IMAGPART_EXPR <exp$0>, the
store of it is useless too.
And later on, ccp3 puts exp$0 into SSA form and changes it into:
  _5 = IMAGPART_EXPR <exp$0_12(D)>;
  exp$0_26 = COMPLEX_EXPR <-3.1400001049041748046875e+0, _5>;
and
  _1 = IMAGPART_EXPR <exp$0_2>;
  exp$0_11 = COMPLEX_EXPR <_19, _1>;
etc.
And the uninit1 pass later complains because the second argument of
COMPLEX_EXPR is IMAGPART_EXPR of uninitialized SSA_NAME.

So, should DCE avoid doing that?  Or better when turning it into SSA form find
out that only one half of it is ever used and just rewrite that half into a
SSA_NAME?

[Bug tree-optimization/105109] [12 Regression] False positive warning on complex float code since r12-155

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105109

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2022-03-30
           Priority|P3                          |P1
   Target Milestone|---                         |12.0

[Bug tree-optimization/105109] [12 Regression] False positive warning on complex float code since r12-155

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105109

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
We have code in uninit to avoid diagnosing partly initialized variables, not
sure if this is such a case.  Let me have a look.

[Bug tree-optimization/105109] [12 Regression] False positive warning on complex float code since r12-155

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105109

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
There isn't really a good way (w/o further analysis) to improve what
update_address_taken does.  While it probably could use a BIT_INSERT_EXPR
instead of reading the other component and using a COMPLEX_EXPR the latter
is what is considered canonical.

There's the opportunity to "simplify"

  _5 = IMAGPART_EXPR <exp$0_12(D)>;
  exp$0_26 = COMPLEX_EXPR <-3.1400001049041748046875e+0, _5>;

to just

  exp$0_26 = COMPLEX_EXPR <-3.1400001049041748046875e+0, _5(D)>;

but that would lose diagnostics.  gimplify_modify_expr_complex_part does

  ocode = code == REALPART_EXPR ? IMAGPART_EXPR : REALPART_EXPR;
  other = build1 (ocode, TREE_TYPE (rhs), lhs);
  suppress_warning (other);

so it suppresses diagnostics on the fake read.  I'm going to do the same
for the rewriting in update_address_taken.

[Bug tree-optimization/105109] [12 Regression] False positive warning on complex float code since r12-155

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105109

--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:97ad0b831386e56ecb125a25fff00b2cb0b1a2b9

commit r12-7934-g97ad0b831386e56ecb125a25fff00b2cb0b1a2b9
Author: Richard Biener <rguenther@suse.de>
Date:   Thu Mar 31 09:21:27 2022 +0200

    tree-optimization/105109 - bogus uninit diagnostic with _Complex

    When update_address_taken rewrites a _Complex into SSA it changes
    stores to real/imaginary parts to loads of the other component and
    a COMPLEX_EXPR.  That matches what gimplification does but it misses
    suppression of diagnostics for the load of the other component.
    The following patch adds that, syncing up gimplification and
    update_address_taken behavior.

    2022-03-31  Richard Biener  <rguenther@suse.de>

            PR tree-optimization/105109
            * tree-ssa.cc (execute_update_addresses_taken): Suppress
            diagnostics on the load of the other complex component.

            * gcc.dg/uninit-pr105109.c: New testcase.

[Bug tree-optimization/105109] [12 Regression] False positive warning on complex float code since r12-155

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105109

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed.