[Bug c/111860] New: error: stmt with wrong VUSE

[Bug c/111860] New: error: stmt with wrong VUSE

[dcb314 at hotmail dot com]

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

            Bug ID: 111860
           Summary: error: stmt with wrong VUSE
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 56137
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56137&action=edit
C source code

foundBugs $ ../results/bin/gcc -c -w -O3 bug967.c
foundBugs $ ../results/bin/gcc -c -w -O3 -march=znver2 bug967.c
foundBugs $ ../results/bin/gcc -c -w -O3 -march=znver3 bug967.c
Create_POPMUSIC_CandidateSet.c: In function ‘optimize_path’:
Create_POPMUSIC_CandidateSet.c:170:13: error: stmt with wrong VUSE
# VUSE <.MEM_103>
_1958 = *_1959;
expected .MEM_1937

This worked yesterday, so it is recent breakage.

The bug seems to first appear sometime between g:ce55521bcd149fdc
and g:60c231cb65807fb9

I will have a go at a reduction.

[Bug c/111860] error: stmt with wrong VUSE

[dcb314 at hotmail dot com]

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

--- Comment #1 from David Binderman <dcb314 at hotmail dot com> ---
Reduced code seems to be:

int optimize_path_n, optimize_path_d;
int *optimize_path_d_0;
extern void path_threeOpt( long);
void optimize_path() {
  int i;
  long length;
  i = 0;
  for (; i <= optimize_path_n; i++)
    optimize_path_d = 0;
  i = 0;
  for (; i < optimize_path_n; i++)
    length += optimize_path_d_0[i];
  path_threeOpt(length);
}

[Bug c/111860] error: stmt with wrong VUSE

[dcb314 at hotmail dot com]

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

David Binderman <dcb314 at hotmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tamar.christina at arm dot com

--- Comment #2 from David Binderman <dcb314 at hotmail dot com> ---
I tried a reduction and the current range is g:7370c479dd34024f
.. g:60c231cb65807fb9

In this range, the Authors are 

Author: Tamar Christina <tamar.christina@arm.com>
Author: Tamar Christina <tamar.christina@arm.com>
Author: Tamar Christina <tamar.christina@arm.com>
Author: Tamar Christina <tamar.christina@arm.com>
Author: Juzhe-Zhong <juzhe.zhong@rivai.ai>
Author: Tobias Burnus <tobias@codesourcery.com>
Author: Haochen Jiang <haochen.jiang@intel.com>
Author: Haochen Jiang <haochen.jiang@intel.com>

Adding Tamar for their opinion.

[Bug c/111860] error: stmt with wrong VUSE

[dcb314 at hotmail dot com]

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

--- Comment #3 from David Binderman <dcb314 at hotmail dot com> ---
As expected:

$ git bisect good 0c8522870effb87f9ea0f0f5897d5b0084c32b50
60c231cb65807fb963624acc4f82d2935e305f93 is the first bad commit
commit 60c231cb65807fb963624acc4f82d2935e305f93
Author: Tamar Christina <tamar.christina@arm.com>
Date:   Wed Oct 18 09:03:06 2023 +0100

    middle-end: maintain LCSSA throughout loop peeling

[Bug c/111860] error: stmt with wrong VUSE

[tnfchris at gcc dot gnu.org]

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

Tamar Christina <tnfchris at gcc dot gnu.org> changed:

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

--- Comment #4 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
Hmm how odd, probably an incorrect edge.

Thanks! taking a look.

[Bug tree-optimization/111860] error: stmt with wrong VUSE

[tnfchris at gcc dot gnu.org]

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

Tamar Christina <tnfchris at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
            Version|unknown                     |14.0
          Component|c                           |tree-optimization
   Target Milestone|---                         |14.0

[Bug tree-optimization/111860] error: stmt with wrong VUSE

[tnfchris at gcc dot gnu.org]

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

Tamar Christina <tnfchris at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2023-10-18
     Ever confirmed|0                           |1

--- Comment #5 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
Confirmed,

looks like the rename failed on one edge, BB 15 has:

;;   basic block 15, loop depth 0, count 94607391 (estimated locally, freq
0.8010), maybe hot
;;    prev block 10, next block 18, flags: (NEW, VISITED)
;;    pred:       7 [11.0% (guessed)]  count:94607391 (estimated locally, freq
0.8010) (FALSE_VALUE,EXECUTABLE)
  # length_13 = PHI <length_17(7)>
  # .MEM_8 = PHI <.MEM_30(7)>

and BB 19 has:

;;   basic block 19, loop depth 0, count 105119324 (estimated locally, freq
0.8900), maybe hot
;;    prev block 17, next block 8, flags: (NEW, REACHABLE, VISITED)
;;    pred:       16 [33.3% (guessed)]  count:81467477 (estimated locally, freq
0.6898) (FALSE_VALUE,EXECUTABLE)
;;                15 [25.0% (guessed)]  count:23651848 (estimated locally, freq
0.2003) (TRUE_VALUE)
  # length_47 = PHI <length_21(16), _61(15)>
  # .MEM_48 = PHI <.MEM_30(16), .MEM_30(15)>

It looks like after the loop guard is added after peeling that the use for the
edge coming in from BB 15 wasn't updated.

Most likely find_guard failed.  Working on it.

Odd that it only fails on x86 though.

[Bug tree-optimization/111860] [14 Regression] incorrect vUSE after guard block loop skip block during vectorization.

[tnfchris at gcc dot gnu.org]

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

--- Comment #6 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
Ok, so the problem is that the loop never creates memory references, and so
after redirecting the edges when we update the new references we do so by
trying to update the PHI nodes.

But since the loop has no MEM phi node there's nothing to update but we created
a new artificial node during redirect.

Because there's no PHI node that means that adjust_phi_and_debug_stmts isn't
strong enough here.

So I can either remove phi nodes whom's SSA vars haven't been defined inside
the loop have not been defined in the body, or I'll need to replace
adjust_phi_and_debug_stmts with something that goes through all uses inside the
new loop and exit.

Which do you prefer richi? It seems like removing the PHI node after redirect
is the simplest one and one less thing to keep updated.

[Bug tree-optimization/111860] [14 Regression] incorrect vUSE after guard block loop skip block during vectorization.

[tnfchris at gcc dot gnu.org]

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

Tamar Christina <tnfchris at gcc dot gnu.org> changed:

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

--- Comment #7 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
*** Bug 111868 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/111860] [14 Regression] incorrect vUSE after guard block loop skip block during vectorization.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
.

[Bug tree-optimization/111860] [14 Regression] incorrect vUSE after guard block loop skip block during vectorization.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |shaohua.li at inf dot ethz.ch

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 111869 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/111860] [14 Regression] incorrect vUSE after guard block loop skip block during vectorization.

[pinskia at gcc dot gnu.org]

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

--- Comment #10 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Just an FYI, I do get a similar ICE on:
libgomp/testsuite/libgomp.fortran/simd3.f90

Testcase on aarch64-linux-gnu now too.

Maybe since it was in the libgomp testsuite you missed it when you tested your
patch.


/home/ubuntu/src/upstream-gcc-aarch64/gcc/libgomp/testsuite/libgomp.fortran/simd3.f90:56:18:
Error: stmt with wrong VUSE^M
# VUSE <.MEM_68>^M
_21 = D.3326[_50];^M
expected .MEM_95^M
/home/ubuntu/src/upstream-gcc-aarch64/gcc/libgomp/testsuite/libgomp.fortran/simd3.f90:56:18:
Error: PHI node with wrong VUSE on edge from BB 32^M
.MEM_131 = PHI <.MEM_68(32), .MEM_68(29)>^M
expected .MEM_95^M
/home/ubuntu/src/upstream-gcc-aarch64/gcc/libgomp/testsuite/libgomp.fortran/simd3.f90:56:18:
Error: PHI node with wrong VUSE on edge from BB 29^M
.MEM_131 = PHI <.MEM_68(32), .MEM_68(29)>^M
expected .MEM_95^M
during GIMPLE pass: vect^M
/home/ubuntu/src/upstream-gcc-aarch64/gcc/libgomp/testsuite/libgomp.fortran/simd3.f90:56:18:
internal compiler error: verify_ssa failed^M
0x12312eb verify_ssa(bool, bool)^M

[Bug tree-optimization/111860] [14 Regression] incorrect vUSE after guard block loop skip block during vectorization.

[dcb314 at hotmail dot com]

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

--- Comment #11 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to Andrew Pinski from comment #10)
> Maybe since it was in the libgomp testsuite you missed it when you tested
> your patch.

I usually find that compiling all the C,C++ and Fortran code
in the gcc/testsuite directory and below with "-g -O3 -march=native -Wall"
and searching for "internal compiler error" can be useful.

testsuite $ find . -name \*.c -print | wc -l
51192
testsuite $ find . \( -name \*.C -o -name \*.cc -o -name \*.cpp -o -name \*.cxx
\) | wc -l
20083
testsuite $ find . -type f -print | grep -E -i "\.f$|\.f[0-9][0-9]$" | wc -l
8036
testsuite $ 

Bonus points for two different architectures (arm & x86_64 ?).

[Bug tree-optimization/111860] [14 Regression] incorrect vUSE after guard block loop skip block during vectorization.

[tnfchris at gcc dot gnu.org]

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

--- Comment #12 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
yes, patch was tested on both aarch64 and x86, but I did not test libgomp
indeed.

In any case, waiting for regression run to finish and will submit patch.

[Bug tree-optimization/111860] [14 Regression] incorrect vUSE after guard block loop skip block during vectorization.

[tnfchris at gcc dot gnu.org]

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

--- Comment #13 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
Patch posted https://gcc.gnu.org/pipermail/gcc-patches/2023-October/633569.html

[Bug tree-optimization/111860] [14 Regression] incorrect vUSE after guard block loop skip block during vectorization.

[cvs-commit at gcc dot gnu.org]

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

--- Comment #14 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tamar Christina <tnfchris@gcc.gnu.org>:

https://gcc.gnu.org/g:217a0fcb852aeb4aa9e3fb9baec6ff947c8de3d4

commit r14-4746-g217a0fcb852aeb4aa9e3fb9baec6ff947c8de3d4
Author: Tamar Christina <tamar.christina@arm.com>
Date:   Thu Oct 19 13:44:01 2023 +0100

    middle-end: don't create LC-SSA PHI variables for PHI nodes who dominate
loop

    As the testcase shows, when a PHI node dominates the loop there is no new
    definition inside the loop.  As such there would be no PHI nodes to update.

    When we maintain LCSSA form we create an intermediate node in between the
two
    loops to thread alongt the value.  However later on when we update the
second
    loop we don't have any PHI nodes to update and so
adjust_phi_and_debug_stmts
    does nothing.   This leaves us with an incorrect phi node.  Normally this
does
    nothing and just gets ignored.  But in the case of the vUSE chain we end up
    corrupting the chain.

    As such whenever a PHI node's argument dominates the loop, we should remove
    the newly created PHI node after edge redirection.

    The one exception to this is when the loop has been versioned.  In such
cases
    the versioned loop may not use the value but the second loop can.

    When this happens and we add the loop guard unless the join block has the
PHI
    it can't find the original value for use inside the guard block.

    The next refactoring in the series moves the formation of the guard block
    inside peeling itself.  Here we have all the information and wouldn't
    need to re-create it later.

    gcc/ChangeLog:

            PR tree-optimization/111860
            * tree-vect-loop-manip.cc (slpeel_tree_duplicate_loop_to_edge_cfg):
            Remove PHI nodes that dominate loop.

    gcc/testsuite/ChangeLog:

            PR tree-optimization/111860
            * gcc.dg/vect/pr111860.c: New test.

[Bug tree-optimization/111860] [14 Regression] incorrect vUSE after guard block loop skip block during vectorization.

[tnfchris at gcc dot gnu.org]

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

Tamar Christina <tnfchris at gcc dot gnu.org> changed:

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

--- Comment #15 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
Fixed, thanks for the report

[Bug tree-optimization/111860] [14 Regression] incorrect vUSE after guard block loop skip block during vectorization.

[dcb314 at hotmail dot com]

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

--- Comment #16 from David Binderman <dcb314 at hotmail dot com> ---
Created attachment 56153
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56153&action=edit
C source code

[Bug tree-optimization/111860] [14 Regression] incorrect vUSE after guard block loop skip block during vectorization.

[tnfchris at gcc dot gnu.org]

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

Tamar Christina <tnfchris at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |zsojka at seznam dot cz

--- Comment #17 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
*** Bug 111877 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/111860] [14 Regression] incorrect vUSE after guard block loop skip block during vectorization.

[tnfchris at gcc dot gnu.org]

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

Tamar Christina <tnfchris at gcc dot gnu.org> changed:

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

--- Comment #18 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
Fix is too conservative, when there's no use in either loop it fails as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111877 shows.

[Bug tree-optimization/111860] [14 Regression] incorrect vUSE after guard block loop skip block during vectorization.

[dcb314 at hotmail dot com]

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

David Binderman <dcb314 at hotmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dcb314 at hotmail dot com

--- Comment #19 from David Binderman <dcb314 at hotmail dot com> ---
Created attachment 56154
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56154&action=edit
C source code

You might like to have a go at getting the attached code working:

$ ~/gcc/results/bin/gcc -c -w -O3  bug967B.c
bug967B.c: In function ‘__wcstod128_l_internal’:
bug967B.c:10:1: error: stmt with wrong VUSE
   10 | __wcstod128_l_internal() {
      | ^~~~~~~~~~~~~~~~~~~~~~

I have 20+ other cases. I can provide them, if you like.

[Bug tree-optimization/111860] [14 Regression] incorrect vUSE after guard block loop skip block during vectorization.

[tnfchris at gcc dot gnu.org]

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

--- Comment #20 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
(In reply to David Binderman from comment #19)
> Created attachment 56154 [details]
> C source code
> 
> You might like to have a go at getting the attached code working:
> 
> $ ~/gcc/results/bin/gcc -c -w -O3  bug967B.c
> bug967B.c: In function ‘__wcstod128_l_internal’:
> bug967B.c:10:1: error: stmt with wrong VUSE
>    10 | __wcstod128_l_internal() {
>       | ^~~~~~~~~~~~~~~~~~~~~~
> 
> I have 20+ other cases. I can provide them, if you like.

No need :) They're all the same bug.  The idea for the fix was correct, but the
way I checked if the loop was versioned wasn't strong enough.

All the reported testcases now pass. I'll start regressions.

[Bug tree-optimization/111860] [14 Regression] incorrect vUSE after guard block loop skip block during vectorization.

[tnfchris at gcc dot gnu.org]

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

--- Comment #21 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
patch submitted
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/633734.html

[Bug tree-optimization/111860] [14 Regression] incorrect vUSE after guard block loop skip block during vectorization.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manuel.lauss at googlemail dot com

--- Comment #22 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 111902 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/111860] [14 Regression] incorrect vUSE after guard block loop skip block during vectorization.

[cvs-commit at gcc dot gnu.org]

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

--- Comment #23 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tamar Christina <tnfchris@gcc.gnu.org>:

https://gcc.gnu.org/g:9ed6b22eb4188c57bb3f5cdba5a7effa95395186

commit r14-4861-g9ed6b22eb4188c57bb3f5cdba5a7effa95395186
Author: Tamar Christina <tamar.christina@arm.com>
Date:   Mon Oct 23 14:07:20 2023 +0100

    middle-end: don't keep .MEM guard nodes for PHI nodes who dominate loop
[PR111860]

    The previous patch tried to remove PHI nodes that dominated the first loop,
    however the correct fix is to only remove .MEM nodes.

    This patch thus makes the condition a bit stricter and only tries to remove
    MEM phi nodes.

    I couldn't figure out a way to easily determine if a particular PHI is vUSE
    related, so the patch does:

    1. check if the definition is a vDEF and not defined in main loop.
    2. check if the definition is a PHI and not defined in main loop.
    3. check if the definition is a default definition.

    For no 2 and 3 we may misidentify the PHI, in both cases the value is
defined
    outside of the loop version block which also makes it ok to remove.

    gcc/ChangeLog:

            PR tree-optimization/111860
            * tree-vect-loop-manip.cc (slpeel_tree_duplicate_loop_to_edge_cfg):
            Drop .MEM nodes only.

    gcc/testsuite/ChangeLog:

            PR tree-optimization/111860
            * gcc.dg/vect/pr111860-2.c: New test.
            * gcc.dg/vect/pr111860-3.c: New test.

[Bug tree-optimization/111860] [14 Regression] incorrect vUSE after guard block loop skip block during vectorization.

[tnfchris at gcc dot gnu.org]

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

Tamar Christina <tnfchris at gcc dot gnu.org> changed:

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

--- Comment #24 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
ok, should be actually fixed now

[Bug tree-optimization/111860] [14 Regression] incorrect vUSE after guard block loop skip block during vectorization.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |19373742 at buaa dot edu.cn

--- Comment #25 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 111951 has been marked as a duplicate of this bug. ***