[Bug target/112374] New: --with-arch=native bootstrap is broken on `Xeon(R) D-2166NT`

[Bug target/112374] New: --with-arch=native bootstrap is broken on `Xeon(R) D-2166NT`

[pinskia at gcc dot gnu.org]

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

            Bug ID: 112374
           Summary: --with-arch=native bootstrap is broken on `Xeon(R)
                    D-2166NT`
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Keywords: build
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
            Target: x86_64-linux-gnu

Part of the log:

```
make[3]: Leaving directory '/bajas/pinskia/src/upstream-gcc-git/gcc/objdir'
Comparing stages 2 and 3
Bootstrap comparison failure!
gcc/i386-expand.o differs
make[2]: *** [Makefile:29937: compare] Error 1
make[2]: Leaving directory '/bajas/pinskia/src/upstream-gcc-git/gcc/objdir'
make[1]: *** [Makefile:29917: stage3-bubble] Error 2
make[1]: Leaving directory '/bajas/pinskia/src/upstream-gcc-git/gcc/objdir'
make: *** [Makefile:29980: bootstrap] Error 2
gcc_build: error: Could not bootstrap the compiler
```

Also noticed here:
https://gcc.gnu.org/pipermail/gcc-regression/2023-November/078409.html

[Bug target/112374] --with-arch=native bootstrap is broken on `Xeon(R) D-2166NT`

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Testing with `--with-arch=skylake`, if that works will try with
`skylake-avx512`.

[Bug target/112374] [14 Regression] --with-arch=native bootstrap is broken on `Xeon(R) D-2166NT`

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|--with-arch=native          |[14 Regression]
                   |bootstrap is broken on      |--with-arch=native
                   |`Xeon(R) D-2166NT`          |bootstrap is broken on
                   |                            |`Xeon(R) D-2166NT`
   Target Milestone|---                         |14.0

[Bug target/112374] [14 Regression] --with-arch=native bootstrap is broken on `Xeon(R) D-2166NT`

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #1)
> Testing with `--with-arch=skylake`, if that works will try with
> `skylake-avx512`.

`--with-arch=skylake` worked.

[Bug target/112374] [14 Regression] `--with-arch=skylake-avx512 --with-cpu=skylake-avx512` causes a comparison failure

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
               Host|                            |x86_64-linux-gnu
           Severity|normal                      |major
            Summary|[14 Regression]             |[14 Regression]
                   |--with-arch=native          |`--with-arch=skylake-avx512
                   |bootstrap is broken on      |--with-cpu=skylake-avx512`
                   |`Xeon(R) D-2166NT`          |causes a comparison failure
              Build|                            |x86_64-linux-gnu

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Ok, it is `--with-arch=skylake-avx512 --with-cpu=skylake-avx512` that fails.  I
am 75% sure it was caused by r14-5076-g01c18f58d37865d5f3bbe93e666183b54ec .

[Bug target/112374] [14 Regression] `--with-arch=skylake-avx512 --with-cpu=skylake-avx512` causes a comparison failure

[pinskia at gcc dot gnu.org]

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

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

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #3)
> Ok, it is `--with-arch=skylake-avx512 --with-cpu=skylake-avx512` that fails.
> I am 75% sure it was caused by r14-5076-g01c18f58d37865d5f3bbe93e666183b54ec
> .

I can confirm, it was working right before this patch.

And since it was failing after r14-5081 and r14-5076 is the only patch that
touches code that might change code gen, it is that patch.

[Bug target/112374] [14 Regression] `--with-arch=skylake-avx512 --with-cpu=skylake-avx512` causes a comparison failure

[haochen.jiang at intel dot com]

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

Haochen Jiang <haochen.jiang at intel dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |haochen.jiang at intel dot com

--- Comment #5 from Haochen Jiang <haochen.jiang at intel dot com> ---
It seems that after the latest patch in PR112361, the fail still not got fixed.

https://gcc.gnu.org/pipermail/gcc-regression/2023-November/078446.html

[Bug target/112374] [14 Regression] `--with-arch=skylake-avx512 --with-cpu=skylake-avx512` causes a comparison failure

[rdapp at gcc dot gnu.org]

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

--- Comment #6 from Robin Dapp <rdapp at gcc dot gnu.org> ---
How does the test suite look without bootstrapping?  Are there still new FAILs?

[Bug target/112374] [14 Regression] `--with-arch=skylake-avx512 --with-cpu=skylake-avx512` causes a comparison failure

[crazylht at gmail dot com]

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

Hongtao.liu <crazylht at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |crazylht at gmail dot com

--- Comment #7 from Hongtao.liu <crazylht at gmail dot com> ---
*** Bug 112441 has been marked as a duplicate of this bug. ***

[Bug target/112374] [14 Regression] `--with-arch=skylake-avx512 --with-cpu=skylake-avx512` causes a comparison failure

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
From the dup:
The only difference between stage2-gcc/i386-expand.o and
stage3-gcc/i386-expand.o is 
```
< ./stage2-gcc/i386-expand.o:     file format elf64-x86-64
---
> ./stage3-gcc/i386-expand.o:     file format elf64-x86-64

11207c11207
<     b48c:     39 ca                   cmp    %ecx,%edx
---
>     b48c:     39 d1                   cmp    %edx,%ecx

```

This gives off vibes of unstable sort somewhere or a difference due to debug
info.
And maybe just exposed by r14-5076-g01c18f58d37865d5f3bbe93e666183b54ec ...

I am going to test a few things.

[Bug target/112374] [14 Regression] `--with-arch=skylake-avx512 --with-cpu=skylake-avx512` causes a comparison failure

[crazylht at gmail dot com]

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

--- Comment #9 from Hongtao.liu <crazylht at gmail dot com> ---
When I remove all cond_<op><mode> patterns, it passed bootstrap. continue to
rootcause the exact pattern which cause the bootstrapped failure

[Bug target/112374] [14 Regression] `--with-arch=skylake-avx512 --with-cpu=skylake-avx512` causes a comparison failure

[crazylht at gmail dot com]

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

--- Comment #10 from Hongtao.liu <crazylht at gmail dot com> ---
Below patch can pass bootstrap --with-arch=skylake-avx512
--with-cpu=skylake-avx512, but didn't observe obvious typo/bug in the pattern.

diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 9eefe9ed45b..b6423037ad1 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -17760,24 +17760,6 @@ (define_expand "<code><mode>3"
   DONE;
 })

-(define_expand "cond_<code><mode>"
-  [(set (match_operand:VI48_AVX512VL 0 "register_operand")
-       (vec_merge:VI48_AVX512VL
-         (any_logic:VI48_AVX512VL
-           (match_operand:VI48_AVX512VL 2 "vector_operand")
-           (match_operand:VI48_AVX512VL 3 "vector_operand"))
-         (match_operand:VI48_AVX512VL 4 "nonimm_or_0_operand")
-         (match_operand:<avx512fmaskmode> 1 "register_operand")))]
-  "TARGET_AVX512F"
-{
-  emit_insn (gen_<code><mode>3_mask (operands[0],
-                                    operands[2],
-                                    operands[3],
-                                    operands[4],
-                                    operands[1]));
-  DONE;
-})
-
 (define_expand "<code><mode>3_mask"
   [(set (match_operand:VI48_AVX512VL 0 "register_operand")
        (vec_merge:VI48_AVX512VL

[Bug target/112374] [14 Regression] `--with-arch=skylake-avx512 --with-cpu=skylake-avx512` causes a comparison failure

[rdapp at gcc dot gnu.org]

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

--- Comment #11 from Robin Dapp <rdapp at gcc dot gnu.org> ---
Thanks for figuring that out.  No idea if the pattern is the problem, most
likely not?  I rather suppose there is still a missing fixup somewhere in the
vectorizer that I didn't encounter with my testing.

So the testsuite without bootstrap is really unchanged?  We still have a SPEC
build problem on aarch64 caused by my initial patch that's caused by not
handling COND_OPs in vect_bool_pattern somewhere.  I didn't get to checking
that yet but will soon.  Maybe there is something similar here?

[Bug target/112374] [14 Regression] `--with-arch=skylake-avx512 --with-cpu=skylake-avx512` causes a comparison failure

[crazylht at gmail dot com]

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

--- Comment #12 from Hongtao.liu <crazylht at gmail dot com> ---
> So the testsuite without bootstrap is really unchanged?  We still have a

Yes, no extra regression observed from gcc testsuite(both w/ and w/o 
--with-arch=skylake-avx512 --with-cpu=skylake-avx512 in configure) except for
the one reported in PR112361 which you have already fixed.

[Bug target/112374] [14 Regression] `--with-arch=skylake-avx512 --with-cpu=skylake-avx512` causes a comparison failure

[pinskia at gcc dot gnu.org]

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

--- Comment #13 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I wonder if there is some debug comparison failure going on that gets exposed
via having those patterns. Maybe try compiling i386-expand.cc with
-fcompare-debug manually might be able to detect it.

[Bug target/112374] [14 Regression] Failed bootstrap with `--with-arch=skylake-avx512 --with-cpu=skylake-avx512`, causes a comparison failure

[sjames at gcc dot gnu.org]

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

Sam James <sjames at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[14 Regression]             |[14 Regression] Failed
                   |`--with-arch=skylake-avx512 |bootstrap with
                   |--with-cpu=skylake-avx512`  |`--with-arch=skylake-avx512
                   |causes a comparison failure |--with-cpu=skylake-avx512`,
                   |                            |causes a comparison failure
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2023-11-15

--- Comment #14 from Sam James <sjames at gcc dot gnu.org> ---
Confirming given pinskia hit it & h.j continues to:
https://gcc.gnu.org/pipermail/gcc-regression/2023-November/078409.html.

[Bug target/112374] [14 Regression] Failed bootstrap with `--with-arch=skylake-avx512 --with-cpu=skylake-avx512`, causes a comparison failure since r14-5076-g01c18f58d37865d5f3bbe93e666183b54ec

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

[Bug target/112374] [14 Regression] Failed bootstrap with `--with-arch=skylake-avx512 --with-cpu=skylake-avx512`, causes a comparison failure since r14-5076-g01c18f58d37865d5f3bbe93e666183b54ec

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I have tried to add just -fcompare-debug -march=skylake-avx512
-mtune=skylake-avx512 options to my stage3 i386-expand.o recompilation and it
didn't fail, but I'm using yes,rtl,extra checking bootstrap, so whether
-fcompare-debug would fail with other configurations is unknown.

[Bug target/112374] [14 Regression] Failed bootstrap with `--with-arch=skylake-avx512 --with-cpu=skylake-avx512`, causes a comparison failure since r14-5076-g01c18f58d37865d5f3bbe93e666183b54ec

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Managed to reproduce now as -fcompare-debug failure:
/home/jakub/src/gcc/obj46/./prev-gcc/xg++
-B/home/jakub/src/gcc/obj46/./prev-gcc/ -O2 -fno-exceptions -fno-rtti
-fno-common -S pr112374.ii -Wno-narrowing -fcompare-debug -march=skylake-avx512
-mtune=skylake-avx512
xg++: error: pr112374.ii: ‘-fcompare-debug’ failure (length)
Will try to reduce this now.

[Bug target/112374] [14 Regression] Failed bootstrap with `--with-arch=skylake-avx512 --with-cpu=skylake-avx512`, causes a comparison failure since r14-5076-g01c18f58d37865d5f3bbe93e666183b54ec

[pinskia at gcc dot gnu.org]

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

--- Comment #17 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #16)
> Managed to reproduce now as -fcompare-debug failure:
> /home/jakub/src/gcc/obj46/./prev-gcc/xg++
> -B/home/jakub/src/gcc/obj46/./prev-gcc/ -O2 -fno-exceptions -fno-rtti
> -fno-common -S pr112374.ii -Wno-narrowing -fcompare-debug
> -march=skylake-avx512 -mtune=skylake-avx512
> xg++: error: pr112374.ii: ‘-fcompare-debug’ failure (length)
> Will try to reduce this now.

I can also reproduce using the compare debug failure using the above options,
using a preprocessed source for  i386-expand.cc from May 2023. I will also try
to reduce it too.

[Bug target/112374] [14 Regression] Failed bootstrap with `--with-arch=skylake-avx512 --with-cpu=skylake-avx512`, causes a comparison failure since r14-5076-g01c18f58d37865d5f3bbe93e666183b54ec

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I'm already at 79804 bytes with the reduction, will get there soon.

[Bug target/112374] [14 Regression] Failed bootstrap with `--with-arch=skylake-avx512 --with-cpu=skylake-avx512`, causes a comparison failure since r14-5076-g01c18f58d37865d5f3bbe93e666183b54ec

[jakub at gcc dot gnu.org]

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

--- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
enum E { F } a, b;
char c;
bool d;
int e;
int (*f) (int, int);
int foo (int, int);

void
bar (void)
{
  if (d)
    for (e = 0; c; e++ && a) switch (b) case F:
      f = foo;
}

./xgcc -B ./ -fcompare-debug -O2 -march=skylake-avx512 -S pr112374.C
xgcc: error: pr112374.C: ‘-fcompare-debug’ failure
Though, that is because of different discriminators, so feels to be
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603673.html
related.
Guess I'll start another reduction with additional -gno-statement-frontiers.

[Bug target/112374] [14 Regression] Failed bootstrap with `--with-arch=skylake-avx512 --with-cpu=skylake-avx512`, causes a comparison failure since r14-5076-g01c18f58d37865d5f3bbe93e666183b54ec

[pinskia at gcc dot gnu.org]

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

--- Comment #20 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #19)
> enum E { F } a, b;
> char c;
> bool d;
> int e;
> int (*f) (int, int);
> int foo (int, int);
> 
> void
> bar (void)
> {
>   if (d)
>     for (e = 0; c; e++ && a) switch (b) case F:
>       f = foo;
> }
> 
> ./xgcc -B ./ -fcompare-debug -O2 -march=skylake-avx512 -S pr112374.C
> xgcc: error: pr112374.C: ‘-fcompare-debug’ failure
> Though, that is because of different discriminators, so feels to be
> https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603673.html
> related.

My reduced testcase:
```
extern const unsigned char mode_class[2];
extern int gen_reg_rtx (int);
int gen_lowpart (int, int);
void ix86_avx256_split_vector_move_misalign (int op0, int op1, unsigned code,
int mode) {
  switch (mode_class[mode])
  { 
    case 1:
          if (mode != 1)  { if (code != 0) { op0 = gen_reg_rtx (1); } op1 =
gen_lowpart (1, op1);  }       break;
  }
}

```

Note the if and branch are all on the same line. And yes that seems like a
statement-frontiers issue too.


> Guess I'll start another reduction with additional -gno-statement-frontiers.
Likewise.

[Bug target/112374] [14 Regression] Failed bootstrap with `--with-arch=skylake-avx512 --with-cpu=skylake-avx512`, causes a comparison failure since r14-5076-g01c18f58d37865d5f3bbe93e666183b54ec

[jakub at gcc dot gnu.org]

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

--- Comment #21 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Another reduction, unfortunately with uninitialized var use:
void foo (int, int);
struct S { char s[4]; };
int a, b, c;

void
bar ()
{
  struct S d;
  long e = 0;
  for (c = 0; c < 4; ++c)
    e |= (d.s[c] ? 3 : 0) << c;
  if (e)
    foo (a, b);
}

[Bug target/112374] [14 Regression] Failed bootstrap with `--with-arch=skylake-avx512 --with-cpu=skylake-avx512`, causes a comparison failure since r14-5076-g01c18f58d37865d5f3bbe93e666183b54ec

[jakub at gcc dot gnu.org]

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

--- Comment #22 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
This one starts to differ during RTL expansion, -fdump-tree-optimized differs
only
with addition of DEBUG stmts, but expand dump already has:
-(insn 1007 1006 1008 (parallel [
+(insn 1007 8 1008 (parallel [
             (set (reg:DI 106)
                 (plus:DI (reg/f:DI 93 virtual-stack-vars)
-                    (const_int -32 [0xffffffffffffffe0])))
+                    (const_int -4 [0xfffffffffffffffc])))
             (clobber (reg:CC 17 flags))
         ]) "pr112374.C":11:14 -1
      (nil))

[Bug target/112374] [14 Regression] Failed bootstrap with `--with-arch=skylake-avx512 --with-cpu=skylake-avx512`, causes a comparison failure since r14-5076-g01c18f58d37865d5f3bbe93e666183b54ec

[pinskia at gcc dot gnu.org]

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

--- Comment #23 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #22)
> This one starts to differ during RTL expansion, -fdump-tree-optimized
> differs only
> with addition of DEBUG stmts, but expand dump already has:
> -(insn 1007 1006 1008 (parallel [
> +(insn 1007 8 1008 (parallel [
>              (set (reg:DI 106)
>                  (plus:DI (reg/f:DI 93 virtual-stack-vars)
> -                    (const_int -32 [0xffffffffffffffe0])))
> +                    (const_int -4 [0xfffffffffffffffc])))
>              (clobber (reg:CC 17 flags))
>          ]) "pr112374.C":11:14 -1
>       (nil))

That looks like a different issue than the original though. I am getting the
feeling we are going to find a lot of compare debug issues with this one
testcase.

[Bug target/112374] [14 Regression] Failed bootstrap with `--with-arch=skylake-avx512 --with-cpu=skylake-avx512`, causes a comparison failure since r14-5076-g01c18f58d37865d5f3bbe93e666183b54ec

[pinskia at gcc dot gnu.org]

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

--- Comment #24 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #22)
> This one starts to differ during RTL expansion, -fdump-tree-optimized
> differs only
> with addition of DEBUG stmts, but expand dump already has:
> -(insn 1007 1006 1008 (parallel [
> +(insn 1007 8 1008 (parallel [
>              (set (reg:DI 106)
>                  (plus:DI (reg/f:DI 93 virtual-stack-vars)
> -                    (const_int -32 [0xffffffffffffffe0])))
> +                    (const_int -4 [0xfffffffffffffffc])))
>              (clobber (reg:CC 17 flags))
>          ]) "pr112374.C":11:14 -1
>       (nil))

With debug:
```
Partition 0: size 4 align 1
        dD.4933
```
Without:
```
Partition 0: size 4 align 32
        dD.4933
```

So the alignment is different there.

[Bug target/112374] [14 Regression] Failed bootstrap with `--with-arch=skylake-avx512 --with-cpu=skylake-avx512`, causes a comparison failure since r14-5076-g01c18f58d37865d5f3bbe93e666183b54ec

[jakub at gcc dot gnu.org]

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

--- Comment #25 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Ok, yet another reduction then:
./xgcc -B ./ -fcompare-debug -march=skylake-avx512 -O2 -S pr112374.c -da
--param min-nondebug-insn-uid=1000 -fdump-tree-all

void foo (int, int);
struct S { char s[64]; } *p;
char a, b;
unsigned char c;
int d, e;

void
bar (void)
{
  unsigned i;
  long j = 0;
  for (i = 0; i < b; ++i)
    j |= (p->s[i] ? 3 : 0) << i;
  if (p->s[i + 1])
  lab:
    for (;;)
      ;
  for (i = 0; i < 4; ++i)
    j |= p->s[i] << i;
  for (; i; i += 2)
    if (c + 1 != a)
      goto lab;
  for (; i < 8; ++i)
    j |= p->s[i] >= 6;
  if (j)
    foo (d, e);
}

This starts to differ during ivopts.  And the actual assembly difference is the
same
as in the original i386-expand.o for me:
@@ -3357,10 +3357,10 @@ Disassembly of section .text:
     2b77:      74 23                   je     2b9c
<_ZL21expand_vec_perm_blendP17expand_vec_perm_d+0x9c>
     2b79:      0f 1f 80 00 00 00 00    nopl   0x0(%rax)
     2b80:      0f b6 54 03 18          movzbl 0x18(%rbx,%rax,1),%edx
-    2b85:      39 d0                   cmp    %edx,%eax
+    2b85:      39 c2                   cmp    %eax,%edx
     2b87:      74 0b                   je     2b94
<_ZL21expand_vec_perm_blendP17expand_vec_perm_d+0x94>
     2b89:      8d 0c 07                lea    (%rdi,%rax,1),%ecx
-    2b8c:      39 ca                   cmp    %ecx,%edx
+    2b8c:      39 d1                   cmp    %edx,%ecx
     2b8e:      0f 85 a6 00 00 00       jne    2c3a
<_ZL21expand_vec_perm_blendP17expand_vec_perm_d+0x13a>
     2b94:      48 ff c0                inc    %rax
     2b97:      48 39 c6                cmp    %rax,%rsi
in i386-expand.o and
diff -up pr112374.s{1,2} | grep -v '^+\.L\(M\|VL\|text\)' | sed
'/\.debug_frame/,$d'
--- pr112374.s1 2023-11-15 21:30:09.701035543 +0100
+++ pr112374.s2 2023-11-15 21:30:12.124001924 +0100
@@ -1,82 +1,149 @@
        .file   "pr112374.c"
        .text
        .p2align 4
        .globl  bar
        .type   bar, @function
 bar:
 .LFB0:
        movsbl  b(%rip), %r8d
        movq    p(%rip), %rcx
        testb   %r8b, %r8b
        je      .L10
        movl    %r8d, %edi
        xorl    %eax, %eax
        xorl    %esi, %esi
        movl    $3, %r9d
        .p2align 4,,10
        .p2align 3
 .L4:
        cmpb    $0, (%rcx,%rax)
        je      .L3
        shlx    %eax, %r9d, %edx
        movslq  %edx, %rdx
        orq     %rdx, %rsi
 .L3:
        incq    %rax
-       cmpq    %rax, %rdi
+       cmpq    %rdi, %rax
        jne     .L4
        leal    1(%r8), %eax
 .L2:
        cmpb    $0, (%rcx,%rax)
        jne     .L6
        xorl    %edx, %edx
 .L5:
        movsbl  (%rcx,%rdx), %eax
        shlx    %edx, %eax, %eax
        incq    %rdx
        cltq
        orq     %rax, %rsi
        cmpq    $4, %rdx
        jne     .L5
        movzbl  c(%rip), %edx
        movsbl  a(%rip), %edi
        movl    $2147483646, %eax
        incl    %edx
        jmp     .L7
        .p2align 4,,10
        .p2align 3
 .L20:
        decl    %eax
        je      .L19
 .L7:
        cmpl    %edi, %edx
        je      .L20
 .L6:
 .L16:
        jmp     .L16
        .p2align 4,,10
        .p2align 3
 .L10:
        movl    $1, %eax
        xorl    %esi, %esi
        jmp     .L2
 .L19:
        leaq    8(%rcx), %rdx
 .L8:
        xorl    %eax, %eax
        cmpb    $5, (%rcx)
        setg    %al
        incq    %rcx
        orq     %rax, %rsi
-       cmpq    %rdx, %rcx
+       cmpq    %rcx, %rdx
        jne     .L8
        testq   %rsi, %rsi
        jne     .L21
        ret
 .L21:
        movl    e(%rip), %esi
        movl    d(%rip), %edi
        jmp     foo
 .LFE0:
        .size   bar, .-bar
        .globl  e
@@ -113,6 +180,31 @@ a:
        .size   p, 8
 p:
        .zero   8

Will have a look tomorrow.

[Bug target/112374] [14 Regression] Failed bootstrap with `--with-arch=skylake-avx512 --with-cpu=skylake-avx512`, causes a comparison failure since r14-5076-g01c18f58d37865d5f3bbe93e666183b54ec

[jakub at gcc dot gnu.org]

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

--- Comment #26 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Though the original might be yet another problem, because I see some
differences e.g. in SSA_NAME_VERSIONs already in earlier dumps (slp1, will look
at others).

[Bug target/112374] [14 Regression] Failed bootstrap with `--with-arch=skylake-avx512 --with-cpu=skylake-avx512`, causes a comparison failure since r14-5076-g01c18f58d37865d5f3bbe93e666183b54ec

[jakub at gcc dot gnu.org]

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

--- Comment #27 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Indeed, the vect dump already has different SSA_NAME_VERSIONs on the original.

[Bug target/112374] [14 Regression] Failed bootstrap with `--with-arch=skylake-avx512 --with-cpu=skylake-avx512`, causes a comparison failure since r14-5076-g01c18f58d37865d5f3bbe93e666183b54ec

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #28 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
E.g. on the referenced r14-5076 commit, I'm completely lost in what that
+       {
+       /* In case of a COND_OP (mask, op1, op2, op1) reduction we might have
+          op1 twice (once as definition, once as else) in the same operation.
+          Allow this.  */
+         if (cond_fn_p)
+           {
+             gcall *call = dyn_cast<gcall *> (use_stmt);
+             unsigned else_pos
+               = internal_fn_else_index (internal_fn (op.code));
+
+             for (unsigned int j = 0; j < gimple_call_num_args (call); ++j)
+               {
+                 if (j == else_pos)
+                   continue;
+                 if (gimple_call_arg (call, j) == op.ops[opi])
+                   cnt++;
+               }
+           }
hunk wants to do.  This is in
4103          FOR_EACH_IMM_USE_STMT (op_use_stmt, imm_iter, op.ops[opi])
loop which iterates over immediate use statements, but this new stuff doesn't
refer to the immediate use statements at all (op_use_stmt).  So, effectively it
repeats the same stuff unconditionally on the original use_stmt as many times
as there are immediate uses, including GIMPLE_DEBUG statements.
On the original i386-expand.o, I see e.g.
(gdb) p debug_gimple_stmt (use_stmt)
_ifc__247 = .COND_IOR (_346, mask_505, _367, mask_505);
where op.ops[opi] is mask_505, it iterates on the
_ifc__247 = .COND_IOR (_346, mask_505, _367, mask_505);
op_use_stmt statement where it increments cnt together by 1, then on
# DEBUG D#437 => D#438 | mask_505
where it doesn't use op_use_stmt but use_stmt (i.e. the above stmt again) and
increments again by 1 and then because cnt != 1 will fail.

Robin, did you mean to test if (cond_fn_p && op_use_stmt == use_stmt) instead,
or actually
use op_use_stmt instead of use_stmt (and only if it actually is also a call),
or something else?

[Bug target/112374] [14 Regression] Failed bootstrap with `--with-arch=skylake-avx512 --with-cpu=skylake-avx512`, causes a comparison failure since r14-5076-g01c18f58d37865d5f3bbe93e666183b54ec

[jakub at gcc dot gnu.org]

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

--- Comment #29 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
--- gcc/tree-vect-loop.cc.jj    2023-11-14 10:35:52.000000000 +0100
+++ gcc/tree-vect-loop.cc       2023-11-15 22:42:32.782007408 +0100
@@ -4105,9 +4105,9 @@ pop:
        /* In case of a COND_OP (mask, op1, op2, op1) reduction we might have
           op1 twice (once as definition, once as else) in the same operation.
           Allow this.  */
-         if (cond_fn_p)
+         if (cond_fn_p && op_use_stmt == use_stmt)
            {
-             gcall *call = dyn_cast<gcall *> (use_stmt);
+             gcall *call = as_a<gcall *> (use_stmt);
              unsigned else_pos
                = internal_fn_else_index (internal_fn (op.code));

doesn't cure the -fcompare-debug failure though.

[Bug target/112374] [14 Regression] Failed bootstrap with `--with-arch=skylake-avx512 --with-cpu=skylake-avx512`, causes a comparison failure since r14-5076-g01c18f58d37865d5f3bbe93e666183b54ec

[pinskia at gcc dot gnu.org]

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

--- Comment #30 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Here is another reduced testcase:
```
struct t
{
  long coef[1];
  t(const unsigned long &a) : coef{a} {};
  t(const t &a);
};
extern void gen_int_mode(t, int);
struct expand_vec_perm_d {
  unsigned char perm[64];
  int vmode;
  unsigned char nelt;
};
void expand_vec_perm_blend(struct expand_vec_perm_d *d) {
  unsigned long mask = 0;
  for (unsigned i = 0; i < 4; ++i)
    mask |= (d->perm[i] >= 4 ? 3 : 0) << (i * 2);
  gen_int_mode(mask, 0);
}
```

The first difference between -g0 vs -g2 starts in curoll where ssa names are
different.

[Bug tree-optimization/112374] [14 Regression] Failed bootstrap with `--with-arch=skylake-avx512 --with-cpu=skylake-avx512`, causes a comparison failure since r14-5076-g01c18f58d37865d5f3bbe93e666183b54ec

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Build|x86_64-linux-gnu            |
               Host|x86_64-linux-gnu            |
             Target|x86_64-linux-gnu            |x86_64-linux-gnu
                   |                            |aarch64-linux-gnu
          Component|target                      |tree-optimization

--- Comment #31 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #30)
> Here is another reduced testcase:

Note the testcase in comment #30, I get comparison failure also on aarch64
with:
 `-O2 -fno-exceptions -fno-rtti -fno-common   -Wno-narrowing 
-gno-statement-frontiers -march=armv9-a+sve2  -fcompare-debug` .

[Bug tree-optimization/112374] [14 Regression] Failed bootstrap with `--with-arch=skylake-avx512 --with-cpu=skylake-avx512`, causes a comparison failure since r14-5076-g01c18f58d37865d5f3bbe93e666183b54ec

[pinskia at gcc dot gnu.org]

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

--- Comment #32 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I suspect we need a dump option to dump the freed ssa names after each pass.
This will allow proving if r14-5076 is at fault or not.

[Bug tree-optimization/112374] [14 Regression] Failed bootstrap with `--with-arch=skylake-avx512 --with-cpu=skylake-avx512`, causes a comparison failure since r14-5076-g01c18f58d37865d5f3bbe93e666183b54ec

[rguenther at suse dot de]

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

--- Comment #33 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 15 Nov 2023, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112374
> 
> --- Comment #29 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> --- gcc/tree-vect-loop.cc.jj    2023-11-14 10:35:52.000000000 +0100
> +++ gcc/tree-vect-loop.cc       2023-11-15 22:42:32.782007408 +0100
> @@ -4105,9 +4105,9 @@ pop:
>         /* In case of a COND_OP (mask, op1, op2, op1) reduction we might have
>            op1 twice (once as definition, once as else) in the same operation.
>            Allow this.  */
> -         if (cond_fn_p)
> +         if (cond_fn_p && op_use_stmt == use_stmt)
>             {
> -             gcall *call = dyn_cast<gcall *> (use_stmt);
> +             gcall *call = as_a<gcall *> (use_stmt);
>               unsigned else_pos
>                 = internal_fn_else_index (internal_fn (op.code));
> 
> doesn't cure the -fcompare-debug failure though.

Looks like a relevant fix tho.

[Bug tree-optimization/112374] [14 Regression] Failed bootstrap with `--with-arch=skylake-avx512 --with-cpu=skylake-avx512`, causes a comparison failure since r14-5076-g01c18f58d37865d5f3bbe93e666183b54ec

[rdapp at gcc dot gnu.org]

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

--- Comment #34 from Robin Dapp <rdapp at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #29)
> --- gcc/tree-vect-loop.cc.jj	2023-11-14 10:35:52.000000000 +0100
> +++ gcc/tree-vect-loop.cc	2023-11-15 22:42:32.782007408 +0100
> @@ -4105,9 +4105,9 @@ pop:
>  	/* In case of a COND_OP (mask, op1, op2, op1) reduction we might have
>  	   op1 twice (once as definition, once as else) in the same operation.
>  	   Allow this.  */
> -	  if (cond_fn_p)
> +	  if (cond_fn_p && op_use_stmt == use_stmt)
>  	    {
> -	      gcall *call = dyn_cast<gcall *> (use_stmt);
> +	      gcall *call = as_a<gcall *> (use_stmt);
>  	      unsigned else_pos
>  		= internal_fn_else_index (internal_fn (op.code));
>  
> doesn't cure the -fcompare-debug failure though.

Yeah that's what I meant to mean in the first place ;)
Thanks for the debugging efforts.  I'm going to check with your reduced
example,   could reproduce it locally with it.

[Bug tree-optimization/112374] [14 Regression] Failed bootstrap with `--with-arch=skylake-avx512 --with-cpu=skylake-avx512`, causes a comparison failure since r14-5076-g01c18f58d37865d5f3bbe93e666183b54ec

[rdapp at gcc dot gnu.org]

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

--- Comment #35 from Robin Dapp <rdapp at gcc dot gnu.org> ---
What does get rid of the comparison failures in the three last posted reduced
examples is:

          gcall *call = dyn_cast<gcall *> (op_use_stmt);
          internal_fn ifn;
          if (call && gimple_call_internal_p (call))
            {
              ifn = gimple_call_internal_fn (call);
              unsigned else_pos = internal_fn_else_index (ifn);
              for (unsigned int j = 0; j < gimple_call_num_args (call); ++j)
                {
                  if (j == else_pos)
                    continue;
                  if (gimple_call_arg (call, j) == op.ops[opi])
                    cnt++;
                }
            }

i.e. ignoring the else altogether.

[Bug tree-optimization/112374] [14 Regression] Failed bootstrap with `--with-arch=skylake-avx512 --with-cpu=skylake-avx512`, causes a comparison failure since r14-5076-g01c18f58d37865d5f3bbe93e666183b54ec

[jakub at gcc dot gnu.org]

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

--- Comment #36 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Actually, while i386-expand.o compilation fails with -fcompare-debug even after
the above patch, seems that is only because of the discriminator issue, the
*.gkd difference is then:
--- i386-expand.cc.gkd  2023-11-16 09:57:22.666238096 +0100
+++ i386-expand.gk.cc.gkd       2023-11-16 09:59:09.207704622 +0100
@@ -245675,14 +245675,14 @@ Declarations used by ix86_expand_vector_
 (note # 0 0 NOTE_INSN_DELETED)
 (insn:TI # 0 0 11 (set (reg:QI 0 ax [360])
         (mem:QI (plus:DI (reg/f:DI 0 ax [orig:192 rt ] [192])
-                (const_int 3 [0x3])) [ MEM <unsigned char> [(struct rtx_def
*)tmp_295 + 3B]+0 S1 A8])) "../../gcc/config/i386/i386-expand.cc":17709:451
discrim 6# {*movqi_internal}
+                (const_int 3 [0x3])) [ MEM <unsigned char> [(struct rtx_def
*)tmp_295 + 3B]+0 S1 A8])) "../../gcc/config/i386/i386-expand.cc":17709:451
discrim 5# {*movqi_internal}
      (nil))
 (insn:TI # 0 0 11 (parallel [
             (set (reg:SI 0 ax [360])
                 (and:SI (reg:SI 0 ax [360])
                     (const_int -29 [0xffffffffffffffe3])))
             (clobber (reg:CC 17 flags))
-        ]) "../../gcc/config/i386/i386-expand.cc":17709:451 discrim 6#
{*andsi_1}
+        ]) "../../gcc/config/i386/i386-expand.cc":17709:451 discrim 5#
{*andsi_1}
      (expr_list:REG_UNUSED (reg:CC 17 flags)
         (nil)))
 (insn:TI # 0 0 11 (parallel [
@@ -245690,12 +245690,12 @@ Declarations used by ix86_expand_vector_
                 (ior:SI (reg:SI 0 ax [360])
                     (const_int 24 [0x18])))
             (clobber (reg:CC 17 flags))
-        ]) "../../gcc/config/i386/i386-expand.cc":17709:451 discrim 6#
{*iorsi_1}
+        ]) "../../gcc/config/i386/i386-expand.cc":17709:451 discrim 5#
{*iorsi_1}
      (expr_list:REG_UNUSED (reg:CC 17 flags)
         (nil)))
 (insn:TI # 0 0 11 (set (mem:QI (plus:DI (reg/v/f:DI 3 bx [orig:192 rt ] [192])
                 (const_int 3 [0x3])) [ MEM <unsigned char> [(struct rtx_def
*)tmp_295 + 3B]+0 S1 A8])
-        (reg:QI 0 ax [362])) "../../gcc/config/i386/i386-expand.cc":17709:451
discrim 6# {*movqi_internal}
+        (reg:QI 0 ax [362])) "../../gcc/config/i386/i386-expand.cc":17709:451
discrim 5# {*movqi_internal}
      (expr_list:REG_DEAD (reg:QI 0 ax [362])
         (nil)))
 (jump_insn # 0 0 11 (set (pc)

So, this should no longer fail normal bootstrap comparison (but of course fail
-fcompare-debug bootstrap).  And with -fcompare-debug -gno-statement-frontiers
it compiles fine.

[Bug tree-optimization/112374] [14 Regression] Failed bootstrap with `--with-arch=skylake-avx512 --with-cpu=skylake-avx512`, causes a comparison failure since r14-5076-g01c18f58d37865d5f3bbe93e666183b54ec

[jakub at gcc dot gnu.org]

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

--- Comment #37 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Robin Dapp from comment #35)
> What does get rid of the comparison failures in the three last posted
> reduced examples is:
> 
> 	  gcall *call = dyn_cast<gcall *> (op_use_stmt);
> 	  internal_fn ifn;
> 	  if (call && gimple_call_internal_p (call))
> 	    {
> 	      ifn = gimple_call_internal_fn (call);
> 	      unsigned else_pos = internal_fn_else_index (ifn);
> 	      for (unsigned int j = 0; j < gimple_call_num_args (call); ++j)
> 		{
> 		  if (j == else_pos)
> 		    continue;
> 		  if (gimple_call_arg (call, j) == op.ops[opi])
> 		    cnt++;
> 		}
> 	    }
> 
> i.e. ignoring the else altogether.

The above isn't complete, so one just has to guess what you mean outside of
that, but the above doesn't seem to be correct.  There are many internal calls,
and most of them shouldn't have the above handling.  Say if there is
.MUL_OVERFLOW (op.ops[opi], op.ops[opi]) call, it should count as 2 uses, not
one.

[Bug tree-optimization/112374] [14 Regression] Failed bootstrap with `--with-arch=skylake-avx512 --with-cpu=skylake-avx512`, causes a comparison failure since r14-5076-g01c18f58d37865d5f3bbe93e666183b54ec

[jakub at gcc dot gnu.org]

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

--- Comment #38 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
And the #c29 change actually seems to fix all the testcases here with
-fcompare-debug -gno-statement-frontiers:
$ ~/src/gcc/obj48/gcc/xg++ -B ~/src/gcc/obj48/gcc/ -fcompare-debug
-gno-statement-frontiers pr112374-0.C -O2 -march=skylake-avx512 -S
$ ~/src/gcc/obj48/gcc/xgcc -B ~/src/gcc/obj48/gcc/ -fcompare-debug
-gno-statement-frontiers pr112374-1.c -O2 -march=skylake-avx512 -S
xgcc: error: pr112374-1.c: ‘-fcompare-debug’ failure (length)
$ ~/src/gcc/obj48/gcc/xgcc -B ~/src/gcc/obj48/gcc/ -fcompare-debug
-gno-statement-frontiers pr112374-2.c -O2 -march=skylake-avx512 -S
xgcc: error: pr112374-2.c: ‘-fcompare-debug’ failure (length)
$ ~/src/gcc/obj48/gcc/xg++ -B ~/src/gcc/obj48/gcc/ -fcompare-debug
-gno-statement-frontiers pr112374-3.C -O2 -march=skylake-avx512 -S
pr112374-3.C: In constructor ‘t::t(const long unsigned int&)’:
pr112374-3.C:4:36: warning: narrowing conversion of ‘(long unsigned int)a’ from
‘long unsigned int’ to ‘long int’ [-Wnarrowing]
    4 |   t(const unsigned long &a) : coef{a} {};
      |                                    ^
xg++: error: pr112374-3.C: ‘-fcompare-debug’ failure
$ ./xg++ -B ./ -fcompare-debug -gno-statement-frontiers pr112374-0.C -O2
-march=skylake-avx512 -S
$ ./xgcc -B ./ -fcompare-debug -gno-statement-frontiers pr112374-1.c -O2
-march=skylake-avx512 -S
$ ./xgcc -B ./ -fcompare-debug -gno-statement-frontiers pr112374-2.c -O2
-march=skylake-avx512 -S
$ ./xg++ -B ./ -fcompare-debug -gno-statement-frontiers pr112374-3.C -O2
-march=skylake-avx512 -S
pr112374-3.C: In constructor ‘t::t(const long unsigned int&)’:
pr112374-3.C:4:36: warning: narrowing conversion of ‘(long unsigned int)a’ from
‘long unsigned int’ to ‘long int’ [-Wnarrowing]
    4 |   t(const unsigned long &a) : coef{a} {};
      |                                    ^
where ~/src/gcc/obj48/gcc/ is build dir of last night's trunk and ./ is build
dir of trunk patched with #c29 patch.
pr112374-0.C is #c19, pr112374-1.c is #c21, pr112374-2.c is #c25 and
pr112374-3.C is #c30.
So, pr112374-0.C is not useful with -gno-statement-frontiers, guess I'll add
the rest into the testsuite for the patch after trying to fix the narrowing
warning in #c30.

[Bug tree-optimization/112374] [14 Regression] Failed bootstrap with `--with-arch=skylake-avx512 --with-cpu=skylake-avx512`, causes a comparison failure since r14-5076-g01c18f58d37865d5f3bbe93e666183b54ec

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #39 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 56601
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56601&action=edit
gcc14-pr112374.patch

So the following then?

[Bug tree-optimization/112374] [14 Regression] Failed bootstrap with `--with-arch=skylake-avx512 --with-cpu=skylake-avx512`, causes a comparison failure since r14-5076-g01c18f58d37865d5f3bbe93e666183b54ec

[rdapp at gcc dot gnu.org]

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

--- Comment #40 from Robin Dapp <rdapp at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #37)
[..]

> The above isn't complete, so one just has to guess what you mean outside of
> that, but the above doesn't seem to be correct.  There are many internal
> calls, and most of them shouldn't have the above handling.  Say if there is
> .MUL_OVERFLOW (op.ops[opi], op.ops[opi]) call, it should count as 2 uses,
> not one.

But we would count MUL_OVERFLOW as two uses because its else_pos = -1?
For clarity we could maybe move the else pos check into the if condition, yes.

One other thing, though.  The else branch checks for is_gimple_debug and
flow_bb_inside_loop_p.  We could handle this separately and continue.
Maybe something like this is clearer, replacing the whole loop (and moved the
else_idx check)?

      FOR_EACH_IMM_USE_STMT (op_use_stmt, imm_iter, op.ops[opi])
        {
          if (is_gimple_debug (op_use_stmt)
              || (*code == ERROR_MARK
                  && !flow_bb_inside_loop_p (loop,
                                             gimple_bb (op_use_stmt))))
            continue;

          /* In case of a COND_OP (mask, op1, op2, op1) reduction we might have
             op1 twice (once as definition, once as else) in the same
operation.
             Allow this.  */
          gcall *call = dyn_cast<gcall *> (op_use_stmt);
          internal_fn ifn;
          if (call && gimple_call_internal_p (call)
              && (ifn = gimple_call_internal_fn (call))
                  && internal_fn_else_index (ifn) > -1)
            {
              unsigned else_idx = internal_fn_else_index (ifn);
              for (unsigned int j = 0; j < gimple_call_num_args (call); ++j)
                {
                  if (j == else_idx)
                    continue;
                  if (gimple_call_arg (call, j) == op.ops[opi])
                    cnt++;
                }
            }
          else
            FOR_EACH_IMM_USE_ON_STMT (use_p, imm_iter)
              cnt++;
        }

[Bug tree-optimization/112374] [14 Regression] Failed bootstrap with `--with-arch=skylake-avx512 --with-cpu=skylake-avx512`, causes a comparison failure since r14-5076-g01c18f58d37865d5f3bbe93e666183b54ec

[rguenth at gcc dot gnu.org]

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

--- Comment #41 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #39)
> Created attachment 56601 [details]
> gcc14-pr112374.patch
> 
> So the following then?

LGTM.  Refactoring to more explicitly handle debug stmts like with

  if (is_gimple_debug (op_use_stmt))
    continue;
  else if (cond_fn_p && ...)

would also be fine but it isn't technically necessary after this fix.

[Bug tree-optimization/112374] [14 Regression] Failed bootstrap with `--with-arch=skylake-avx512 --with-cpu=skylake-avx512`, causes a comparison failure since r14-5076-g01c18f58d37865d5f3bbe93e666183b54ec

[pinskia at gcc dot gnu.org]

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

--- Comment #42 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Just one suggestion for the testcases, add:
/* { dg-additional-options "-march=armv9-a" { target aarch64*-*-* } } */

So it at least it will be tested on another target.

[Bug tree-optimization/112374] [14 Regression] Failed bootstrap with `--with-arch=skylake-avx512 --with-cpu=skylake-avx512`, causes a comparison failure since r14-5076-g01c18f58d37865d5f3bbe93e666183b54ec

[jakub at gcc dot gnu.org]

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

--- Comment #43 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Robin Dapp from comment #40)
> (In reply to Jakub Jelinek from comment #37)
> [..]
> 
> > The above isn't complete, so one just has to guess what you mean outside of
> > that, but the above doesn't seem to be correct.  There are many internal
> > calls, and most of them shouldn't have the above handling.  Say if there is
> > .MUL_OVERFLOW (op.ops[opi], op.ops[opi]) call, it should count as 2 uses,
> > not one.
> 
> But we would count MUL_OVERFLOW as two uses because its else_pos = -1?
> For clarity we could maybe move the else pos check into the if condition,
> yes.
> 
> One other thing, though.  The else branch checks for is_gimple_debug and
> flow_bb_inside_loop_p.  We could handle this separately and continue.
> Maybe something like this is clearer, replacing the whole loop (and moved
> the else_idx check)?
> 
>       FOR_EACH_IMM_USE_STMT (op_use_stmt, imm_iter, op.ops[opi])
> 	{
> 	  if (is_gimple_debug (op_use_stmt)
> 	      || (*code == ERROR_MARK
> 		  && !flow_bb_inside_loop_p (loop,
> 					     gimple_bb (op_use_stmt))))
> 	    continue;
> 
> 	  /* In case of a COND_OP (mask, op1, op2, op1) reduction we might have
> 	     op1 twice (once as definition, once as else) in the same operation.
> 	     Allow this.  */
> 	  gcall *call = dyn_cast<gcall *> (op_use_stmt);
> 	  internal_fn ifn;
> 	  if (call && gimple_call_internal_p (call)
> 	      && (ifn = gimple_call_internal_fn (call))
> 		  && internal_fn_else_index (ifn) > -1)
> 	    {
> 	      unsigned else_idx = internal_fn_else_index (ifn);
> 	      for (unsigned int j = 0; j < gimple_call_num_args (call); ++j)
> 		{
> 		  if (j == else_idx)
> 		    continue;
> 		  if (gimple_call_arg (call, j) == op.ops[opi])
> 		    cnt++;
> 		}
> 	    }
> 	  else
> 	    FOR_EACH_IMM_USE_ON_STMT (use_p, imm_iter)
> 	      cnt++;
> 	}

Then
      bool cond_fn_p = op.code.is_internal_fn ()
        && (conditional_internal_fn_code (internal_fn (op.code))
            != ERROR_MARK);
would be unused and would cause bootstrap error.
Anyway, it really depends on what you want to achieve with this code.
My (admittedly limited) understanding of this is that use_stmt ought to be
always
one of the statements among the op_use_stmt statements (I believe it must be a
use statement of op.ops[opi]) and I think should be also inside of the loop and
because after this loop it fails if cnt != 1, I think before your changes it
basically made sure that there is exactly one non-debug use in the loop (the
use_stmt one) and not other, and that on use_stmt there is just one use.
Now, the patch changed it to allow one extra use in certain cases (but I think
only on use_stmt, because there should be one use on use_stmt and if there is
some other in the loop, that would be already too much).  So I think my patch
ought to work and the above would be more expensive (as it would need to check
each op_use_stmt for being suitable internal call).
the code before

[Bug tree-optimization/112374] [14 Regression] Failed bootstrap with `--with-arch=skylake-avx512 --with-cpu=skylake-avx512`, causes a comparison failure since r14-5076-g01c18f58d37865d5f3bbe93e666183b54ec

[jakub at gcc dot gnu.org]

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

--- Comment #44 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #42)
> Just one suggestion for the testcases, add:
> /* { dg-additional-options "-march=armv9-a" { target aarch64*-*-* } } */
> 
> So it at least it will be tested on another target.

Does aarch64*-*-* support -march=armv9-a regardless of whether e.g. assembler
has support for it?  I mean, x86 does that, but I think e.g. powerpc didn't or
doesn't.

[Bug tree-optimization/112374] [14 Regression] Failed bootstrap with `--with-arch=skylake-avx512 --with-cpu=skylake-avx512`, causes a comparison failure since r14-5076-g01c18f58d37865d5f3bbe93e666183b54ec

[pinskia at gcc dot gnu.org]

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

--- Comment #45 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #44)
> (In reply to Andrew Pinski from comment #42)
> > Just one suggestion for the testcases, add:
> > /* { dg-additional-options "-march=armv9-a" { target aarch64*-*-* } } */
> > 
> > So it at least it will be tested on another target.
> 
> Does aarch64*-*-* support -march=armv9-a regardless of whether e.g.
> assembler has support for it?  I mean, x86 does that, but I think e.g.
> powerpc didn't or doesn't.

Yes -march=armv9-a is supported even if the assembler does not support it.

[Bug tree-optimization/112374] [14 Regression] Failed bootstrap with `--with-arch=skylake-avx512 --with-cpu=skylake-avx512`, causes a comparison failure since r14-5076-g01c18f58d37865d5f3bbe93e666183b54ec

[rdapp at gcc dot gnu.org]

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

--- Comment #46 from Robin Dapp <rdapp at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #43)

> Now, the patch changed it to allow one extra use in certain cases (but I
> think only on use_stmt, because there should be one use on use_stmt and if
> there is some other in the loop, that would be already too much).  So I
> think my patch ought to work and the above would be more expensive (as it
> would need to check each op_use_stmt for being suitable internal call).
> the code before

Your patch looks good.  What I wanted to do, originally, is to just skip the
reduction variable's next use in the else value and this is what your patch
ensures.  I agree, I don't think we actually need to check other uses in that
manner (because even the use as a proper op would be too much) so what I posted
last will do more work than necessary - it might just make the whole thing a
bit clearer.

[Bug tree-optimization/112374] [14 Regression] Failed bootstrap with `--with-arch=skylake-avx512 --with-cpu=skylake-avx512`, causes a comparison failure since r14-5076-g01c18f58d37865d5f3bbe93e666183b54ec

[rdapp at gcc dot gnu.org]

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

--- Comment #47 from Robin Dapp <rdapp at gcc dot gnu.org> ---
And, just to confirm: Testsuite is unchanged on riscv with your patch.

[Bug tree-optimization/112374] [14 Regression] Failed bootstrap with `--with-arch=skylake-avx512 --with-cpu=skylake-avx512`, causes a comparison failure since r14-5076-g01c18f58d37865d5f3bbe93e666183b54ec

[cvs-commit at gcc dot gnu.org]

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

--- Comment #48 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:172a72da368146e0fe34194020eb7a6636db4438

commit r14-5556-g172a72da368146e0fe34194020eb7a6636db4438
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Nov 17 15:09:44 2023 +0100

    vect: Fix check_reduction_path [PR112374]

    As mentioned in the PR, the intent of the r14-5076 changes was that
    it doesn't count one of the uses on the use_stmt, but what actually
    got implemented is that it does this processing on any op_use_stmt,
    even if it is not the use_stmt statement, which means that it
    can increase count even on debug stmts (-fcompare-debug failures),
    or if there would be some other use stmt with 2+ uses it could count
    that as a single use.  Though, because it fails whenever cnt != 1
    and I believe use_stmt must be one of the uses, it would probably
    fail in the latter case anyway.

    The following patch fixes that by doing this extra processing only when
    op_use_stmt is use_stmt, and using the normal processing otherwise
    (so ignore debug stmts, and increase on any uses on the stmt).

    2023-11-17  Jakub Jelinek  <jakub@redhat.com>

            PR tree-optimization/112374
            * tree-vect-loop.cc (check_reduction_path): Perform the cond_fn_p
            special case only if op_use_stmt == use_stmt, use as_a rather than
            dyn_cast in that case.

            * gcc.dg/pr112374-1.c: New test.
            * gcc.dg/pr112374-2.c: New test.
            * g++.dg/opt/pr112374.C: New test.

[Bug tree-optimization/112374] [14 Regression] Failed bootstrap with `--with-arch=skylake-avx512 --with-cpu=skylake-avx512`, causes a comparison failure since r14-5076-g01c18f58d37865d5f3bbe93e666183b54ec

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #49 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Should be fixed now.