[Bug middle-end/102700] New: [Diagnostics] uninitialized warning missing after O2 vectorization.

[Bug middle-end/102700] New: [Diagnostics] uninitialized warning missing after O2 vectorization.

[crazylht at gmail dot com]

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

            Bug ID: 102700
           Summary: [Diagnostics] uninitialized warning missing after O2
                    vectorization.
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Keywords: diagnostic
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: crazylht at gmail dot com
  Target Milestone: ---
              Host: x86_64-pc-linux-gnu

testcase is from g++.dg/warn/Wuninitialized-13.C
struct shared_count {
  shared_count () { }
  shared_count (shared_count &r)
    : pi (r.pi) { }     // { dg-warning "\\\[-Wuninitialized" "" { xfail {
i?86-*-* x86_64-*-* } } }
  int pi;
};

// There's another (redundant) -Wuninitialized on the line below.
struct shared_ptr {
  int ptr;
  shared_count refcount;
};

struct Bar {
  Bar (int, shared_ptr);
};

void g () {
  shared_ptr foo;
  Bar (0, foo);
}

After vectorization
.C.211.uninit1

;; Function g (_Z1gv, funcdef_no=6, decl_uid=4497, cgraph_uid=13,
symbol_order=12)

void g ()
{
  int * vectp.11;
  vector(2) int * vectp.10;
  vector(2) int vect__6.9;
  int * vectp.8;
  vector(2) int * vectp_foo.7;
  struct shared_ptr foo;
  struct shared_ptr D.4566;
  struct Bar D.4567;

  <bb 2> [local count: 1073741824]:
  [test2.C:6:19] MEM[(struct shared_count *)[test2.C:23:14] &foo + 4B] ={v}
{CLOBBER};
  [test2.C:13:8] vect__6.9_12 = MEM <vector(2) int> [(int *)&foo]; 
  [test2.C:8:5] MEM[(struct shared_count *)[test2.C:24:3] &D.4566 + 4B] ={v}
{CLOBBER};
  [test2.C:13:8] MEM <vector(2) int> [(int *)&D.4566] = vect__6.9_12;
  [test2.C:24:3] Bar::Bar ([test2.C:24:3] &D.4567, 0, [test2.C:24:3] &D.4566);
  [test2.C:24:3] D.4567 ={v} {CLOBBER};
  [test2.C:24:3] D.4566 ={v} {CLOBBER};
  foo ={v} {CLOBBER};
  [test2.C:25:1] return;

}

MEM <vector(2) int> [(int *)&foo];  is used instead of _6 = foo.ptr; which is
missed by warn_uninitialized_vars?

[Bug middle-end/102700] [Diagnostics] uninitialized warning missing after O2 vectorization.

[crazylht at gmail dot com]

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

--- Comment #1 from Hongtao.liu <crazylht at gmail dot com> ---
Maybe i should i -fno-tree-vectorize to this testcase.

[Bug middle-end/102700] [Diagnostics] uninitialized warning missing after O2 vectorization.

[egallager at gcc dot gnu.org]

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

Eric Gallager <egallager at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager <egallager at gcc dot gnu.org> ---
Why is this put as blocking the Wstringop-overflow meta-bug instead of the
Wuninitialized one?

[Bug middle-end/102700] [12 Regression] wrong location in -Wuninitialized after -O2 vectorization

[msebor at gcc dot gnu.org]

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

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-10-12
                 CC|                            |msebor at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
            Summary|[Diagnostics] uninitialized |[12 Regression] wrong
                   |warning missing after O2    |location in -Wuninitialized
                   |vectorization.              |after -O2 vectorization
             Blocks|88443                       |24639

--- Comment #3 from Martin Sebor <msebor at gcc dot gnu.org> ---
It looks like it's just the the location of the warning that's off, the warning
itself is still issued but it's swallowed by the dg-prune-output directive.

Since the test was added to verify the fix for an ICE without vectorization I
think disabling vectorization should be fine.  Ideally, we would understand why
the location is wrong so let's keep this bug open and add a comment to the test
referencing this bug.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
[Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

[Bug middle-end/102700] [12 Regression] wrong location in -Wuninitialized after -O2 vectorization

[crazylht at gmail dot com]

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

--- Comment #4 from Hongtao.liu <crazylht at gmail dot com> ---
(In reply to Martin Sebor from comment #3)
> It looks like it's just the the location of the warning that's off, the
> warning itself is still issued but it's swallowed by the dg-prune-output
> directive.
> 
> Since the test was added to verify the fix for an ICE without vectorization
> I think disabling vectorization should be fine.  Ideally, we would
> understand why the location is wrong so let's keep this bug open and add a
> comment to the test referencing this bug.

Add -fno-tree-vectorize and relative comments in r12-4386

[Bug middle-end/102700] [12 Regression] wrong location in -Wuninitialized after -O2 vectorization

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |12.0

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
Vectorization can only maintain one of the locations:

-  [t.ii:9:8] _6 = foo.ptr;
-  [t.ii:9:8] [t.ii:9:8] D.2488.ptr = _6;
+  [t.ii:9:8] vect__6.9_12 = MEM <vector(2) int> [(int *)&foo];
   [t.ii:4:5] MEM[(struct shared_count *)[t.ii:20:3] &D.2488 + 4B] ={v}
{CLOBBER};
-  [t.ii:4:13] _7 = [t.ii:4:13] MEM[(struct shared_count &)[t.ii:20:11] &foo +
4].pi;
-  [t.ii:4:7] [t.ii:4:7] MEM[(struct shared_count *)[t.ii:20:3] &D.2488 +
4B].pi = _7;
+  [t.ii:9:8] MEM <vector(2) int> [(int *)&D.2488] = vect__6.9_12;

so we combine the reads at t.ii:9:8 and t.ii:4:7 (that's the uninitialized one)
into a vector read at t.ii:9:8.  I don't see how GCCs IL allows us to do
better.

[Bug middle-end/102700] [12 Regression] wrong location in -Wuninitialized after -O2 vectorization

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |WONTFIX
             Status|NEW                         |RESOLVED

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
There is nothing to fix, the only possibility would be to move uninit
diagnostics earlier.  The "regression" is that we now vectorize at -O2, but
that's a feature.
So you can argue this behavior is a feature.

So, WONTFIX.

[Bug middle-end/102700] [12 Regression] wrong location in -Wuninitialized after -O2 vectorization

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #5)
> Vectorization can only maintain one of the locations:
> 
> -  [t.ii:9:8] _6 = foo.ptr;
> -  [t.ii:9:8] [t.ii:9:8] D.2488.ptr = _6;
> +  [t.ii:9:8] vect__6.9_12 = MEM <vector(2) int> [(int *)&foo];
>    [t.ii:4:5] MEM[(struct shared_count *)[t.ii:20:3] &D.2488 + 4B] ={v}
> {CLOBBER};
> -  [t.ii:4:13] _7 = [t.ii:4:13] MEM[(struct shared_count &)[t.ii:20:11] &foo
> + 4].pi;
> -  [t.ii:4:7] [t.ii:4:7] MEM[(struct shared_count *)[t.ii:20:3] &D.2488 +
> 4B].pi = _7;
> +  [t.ii:9:8] MEM <vector(2) int> [(int *)&D.2488] = vect__6.9_12;
> 
> so we combine the reads at t.ii:9:8 and t.ii:4:7 (that's the uninitialized
> one)
> into a vector read at t.ii:9:8.  I don't see how GCCs IL allows us to do
> better.

Well, if DWARF6 agrees on some way how to debug vectorized code, maybe we'll
need to figure out a way how to encode multiple locations.