[Bug target/112276] [14 Regression] wrong code with -O2 -msse4.2 since r14-4964-g7eed861e8ca3f5

[zsojka at seznam dot cz via Gcc-bugs]

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

--- Comment #5 from Zdenek Sojka  ---
(In reply to Hongtao.liu from comment #4)
> -(define_split
> -  [(set (match_operand:V2HI 0 "register_operand")
> -(eq:V2HI
> -  (eq:V2HI
> -(us_minus:V2HI
> -  (match_operand:V2HI 1 "register_operand")
> -  (match_operand:V2HI 2 "register_operand"))
> -(match_operand:V2HI 3 "const0_operand"))
> -  (match_operand:V2HI 4 "const0_operand")))]
> -  "TARGET_SSE4_1"
> -  [(set (match_dup 0)
> -(umin:V2HI (match_dup 1) (match_dup 2)))
> -   (set (match_dup 0)
> -(eq:V2HI (match_dup 0) (match_dup 2)))])
> 
> the splitter is wrong when op1 == op2.(the original pattern returns 0, after
> splitter, it returns 1)
> So remove the splitter.

Thank you for having a look. I have other testcases, possibly related, that are
being reduced now, failing at -O2 only; so -msse4.2 might not be the only
broken target. I will open a new PR if those will still be broken after this is
fixed; alternatively, I can upload the testcases here, once they are reduced.

[Bug target/112276] [14 Regression] wrong code with -O2 -msse4.2 since r14-4964-g7eed861e8ca3f5

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Hongtao.liu  ---
-(define_split
-  [(set (match_operand:V2HI 0 "register_operand")
-(eq:V2HI
-  (eq:V2HI
-(us_minus:V2HI
-  (match_operand:V2HI 1 "register_operand")
-  (match_operand:V2HI 2 "register_operand"))
-(match_operand:V2HI 3 "const0_operand"))
-  (match_operand:V2HI 4 "const0_operand")))]
-  "TARGET_SSE4_1"
-  [(set (match_dup 0)
-(umin:V2HI (match_dup 1) (match_dup 2)))
-   (set (match_dup 0)
-(eq:V2HI (match_dup 0) (match_dup 2)))])

the splitter is wrong when op1 == op2.(the original pattern returns 0, after
splitter, it returns 1)
So remove the splitter.

[Bug ipa/106627] Exception from multiversion function cannot be caught

[xry111 at gcc dot gnu.org via Gcc-bugs]

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org

--- Comment #7 from Xi Ruoyao  ---
(In reply to CVS Commits from comment #4)
> The master branch has been updated by Richard Biener :
> 
> https://gcc.gnu.org/g:0b0a3cdbff64d97e7de3e0e2c26e965708064193
> 
> commit r13-2360-g0b0a3cdbff64d97e7de3e0e2c26e965708064193
> Author: Simon Rainer 
> Date:   Wed Aug 31 23:00:08 2022 +0200
> 
> ipa: Fix throw in multi-versioned functions [PR106627]

Is this issue fixed then?

[Bug tree-optimization/112282] [14 Regression] wrong code (generated code hangs) at -O3 on x86_64-linux-gnu since r14-4777-g88c27070c25309

[sjames at gcc dot gnu.org via Gcc-bugs]

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

Sam James  changed:

   What|Removed |Added

Summary|[14 Regression] wrong code  |[14 Regression] wrong code
   |(generated code hangs) at   |(generated code hangs) at
   |-O3 on x86_64-linux-gnu |-O3 on x86_64-linux-gnu
   ||since
   ||r14-4777-g88c27070c25309
 CC||tnfchris at gcc dot gnu.org

--- Comment #7 from Sam James  ---
88c27070c253094fb7e366583fbe09cec2371e8b is the first bad commit
commit 88c27070c253094fb7e366583fbe09cec2371e8b
Author: Tamar Christina 
Date:   Fri Oct 20 08:09:45 2023 +0100

ifcvt: Support bitfield lowering of multiple-exit loops

i.e. r14-4777-g88c27070c25309

[Bug target/104610] memcmp () == 0 can be optimized better for avx512f

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #23 from CVS Commits  ---
The master branch has been updated by hongtao Liu :

https://gcc.gnu.org/g:8c40b72036c967fbb1d1150515cf70aec382f0a2

commit r14-5002-g8c40b72036c967fbb1d1150515cf70aec382f0a2
Author: liuhongt 
Date:   Mon Oct 9 15:07:54 2023 +0800

Improve memcmpeq for 512-bit vector with vpcmpeq + kortest.

When 2 vectors are equal, kmask is allones and kortest will set CF,
else CF will be cleared.

So CF bit can be used to check for the result of the comparison.

Before:
vmovdqu (%rsi), %ymm0
vpxorq  (%rdi), %ymm0, %ymm0
vptest  %ymm0, %ymm0
jne .L2
vmovdqu 32(%rsi), %ymm0
vpxorq  32(%rdi), %ymm0, %ymm0
vptest  %ymm0, %ymm0
je  .L5
.L2:
movl$1, %eax
xorl$1, %eax
vzeroupper
ret

After:
vmovdqu64   (%rsi), %zmm0
xorl%eax, %eax
vpcmpeqd(%rdi), %zmm0, %k0
kortestw%k0, %k0
setc%al
vzeroupper
ret

gcc/ChangeLog:

PR target/104610
* config/i386/i386-expand.cc (ix86_expand_branch): Handle
512-bit vector with vpcmpeq + kortest.
* config/i386/i386.md (cbranchxi4): New expander.
* config/i386/sse.md: (cbranch4): Extend to V16SImode
and V8DImode.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr104610-2.c: New test.

[Bug target/111449] memcmp (p,q,16) == 0 can be optimized better on ppc64 with vector comparison instructions

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by HaoChen Gui :

https://gcc.gnu.org/g:8111b5c23bd14f80607bd35af58ec31e38a0378e

commit r14-5001-g8111b5c23bd14f80607bd35af58ec31e38a0378e
Author: Haochen Gui 
Date:   Mon Oct 30 10:59:51 2023 +0800

Expand: Checking available optabs for scalar modes in by pieces operations

The former patch (f08ca5903c7) examines the scalar modes by target
hook scalar_mode_supported_p.  It causes some i386 regression cases
as XImode and OImode are not enabled in i386 target function.  This
patch examines the scalar mode by checking if the corresponding optabs
are available for the mode.

gcc/
PR target/111449
* expr.cc (qi_vector_mode_supported_p): Rename to...
(by_pieces_mode_supported_p): ...this, and extends it to do
the checking for both scalar and vector mode.
(widest_fixed_size_mode_for_size): Call
by_pieces_mode_supported_p to examine the mode.
(op_by_pieces_d::smallest_fixed_size_mode_for_size): Likewise.

[Bug target/112276] [14 Regression] wrong code with -O2 -msse4.2 since r14-4964-g7eed861e8ca3f5

[crazylht at gmail dot com via Gcc-bugs]

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

Hongtao.liu  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #3 from Hongtao.liu  ---
Mine, I'll take a look.

[Bug tree-optimization/112282] [14 Regression] wrong code (generated code hangs) at -O3 on x86_64-linux-gnu

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #5)
> But doing intializing au allows it work. that is:
> struct b au = {};

But I put a `__builtin_trap();` any place where au might be used as
uninitalized, and we don't reach those section of code.  So 

[Bug tree-optimization/112282] [14 Regression] wrong code (generated code hangs) at -O3 on x86_64-linux-gnu

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Andrew Pinski  ---
Hmm it is not ah:
struct b ah = {};
still causes the infinite loop.



But doing intializing au allows it work. that is:
struct b au = {};

[Bug tree-optimization/112282] [14 Regression] wrong code (generated code hangs) at -O3 on x86_64-linux-gnu

[sjames at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Sam James  ---
(In reply to Sam James from comment #3)
> I can't reproduce with 20231022, so I'll wait until today's snapshot
> finishes. That gives us a nice narrow window anyway...

Sorry, I was wrong there. -ftrivial-auto-var-init=zero (which I've been playing
with locally) was masking it.

[Bug tree-optimization/112282] [14 Regression] wrong code (generated code hangs) at -O3 on x86_64-linux-gnu

[sjames at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Sam James  ---
I can't reproduce with 20231022, so I'll wait until today's snapshot finishes.
That gives us a nice narrow window anyway...

[Bug tree-optimization/112282] [14 Regression] wrong code (generated code hangs) at -O3 on x86_64-linux-gnu

[sjames at gcc dot gnu.org via Gcc-bugs]

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #2 from Sam James  ---
I will have a go at a bisect.

[Bug tree-optimization/112282] [14 Regression] wrong code (generated code hangs) at -O3 on x86_64-linux-gnu

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-10-29
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Confirmed. Looks bitfields and ifcvt related.
GCC 13 didn't vectorize the code and using -fno-tree-vectorize fixes the
infinite loop.

[Bug tree-optimization/112113] [14 Regression] wrong code at -O3 on x86_64-linux-gnu since r14-2852-gf5fb9ff2396fd4

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=111652

--- Comment #4 from Andrew Pinski  ---
Looks almost the same code as what was in PR 111652 (maybe it is a dup after
all).

[Bug tree-optimization/112282] [14 Regression] wrong code (generated code hangs) at -O3 on x86_64-linux-gnu

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|wrong code (generated code  |[14 Regression] wrong code
   |hangs) at -O3 on|(generated code hangs) at
   |x86_64-linux-gnu|-O3 on x86_64-linux-gnu
   Target Milestone|--- |14.0
   Keywords||wrong-code

[Bug tree-optimization/112282] New: wrong code (generated code hangs) at -O3 on x86_64-linux-gnu

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 112282
   Summary: wrong code (generated code hangs) at -O3 on
x86_64-linux-gnu
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

The code is very tough to reduce, but it appears to be a recent regression. 

Although the reduced code is still quite hairy, it does seem valid.

Compiler Explorer: https://godbolt.org/z/TxGdP87EW


[621] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20231029 (experimental) (GCC) 
[622] % 
[622] % gcctk -O2 small.c; ./a.out
[623] % 
[623] % gcctk -O3 small.c
[624] % timeout -s 9 10 ./a.out
Killed
[625] % cat small.c
int printf(const char *, ...);
void __assert_fail();
int a, g, h, i, v, w = 2, x, y, ab, ac, ad, ae, af, ag;
static int f, j, m, n, p, r, u, aa;
struct b {
  int c : 20;
  int d : 20;
  int e : 10;
};
static struct b l, o, q = {3, 3, 5};
int s(int z) {
  struct b ah;
  int ai = 1, aj[7] = {1, 1, 1, 1, 1, 1, 1};
ak:
  for (u = -22; u < 2; ++u) {
struct b al[8] = {{2, 7, 9}, {8, 7, 1}, {2, 7, 9}, {8, 7, 1}, {2, 7, 9},
{8, 7, 1}, {2, 7, 9}};
y = z = 0;
for (; z < 2; z++) {
  int am[18], k;
  ab = ac = 0;
  for (; ac < 1; ac++)
for (k = 0; k < 9; k++)
  am[k] = 0;
  n = 0;
  while (1) {
v = u < 0 || a;
h = z < ~u && 4 & q.c;
if ((aa <= l.c) > q.d && p)
  return o.c;
if (w)
  break;
return q.e;
  }
  a = j;
}
  }
  for (x = 0; x < 2; x++) {
struct b an = {1, 8, 4};
int ao[28] = {5, 0, 0, 9, 0, 3, 0, 5, 0, 0, 9, 0, 3, 0, 5, 0, 0, 9, 0, 3,
0, 5, 0, 0, 9, 0, 3, 0};
if (q.e) {
  int ap = ai || l.c + q.c, aq = q.d, ar = p & f;
  q.d = q.d || ar || ap;
  p = 0;
  if (!j && ai)
goto as;
  if (q.d) {
printf("", l);
q.d = f >> j;
  }
  p = l.c = aq;
  an = q;
} else {
  int at[12][1] = {{9}, {9}, {5}, {9}, {9}, {5}, {9}, {9}, {5}, {9}, {9},
{5}};
  struct b au;
  if (o.c)
aa = ah.e;
  if (an.d)
ah.e = (j & (aa * m)) ^ au.d;
  o.c = m + aa;
  int av = o.c || 0, aw = ai || q.c & l.c, ax = n;
  if (q.e < ai)
q = an;
  if (r)
break;
  ai = aw - av;
  an.e = 0;
  if (ai) {
an.e = l.c || 0;
f = q.c;
ah.e = l.c % q.d;
q.c = au.e;
if ((q.d && q.c) || ah.e)
  __assert_fail();
q.c = 0;
if (au.d > m || ah.e)
  w = au.c | (n & ah.c);
  as:
ae = af = ah.c;
int ay = au.d & q.e & au.c || o.c, az = 0 || o.c, ba = m & ah.d;
if (n)
  au.c = au.e = (q.e || ah.d) ^ (o.c + (az / au.e));
n = au.c || au.e;
if (ba) {
  printf("", ax);
  x = q.e | m;
  continue;
}
m = ay;
n = printf("", au);
  }
  if (ah.d)
o.c = l.c & o.c & q.c;
  if (q.d)
__assert_fail();
  printf("", an);
  printf("", q);
  printf("", au);
  if (ah.e)
while (u++) {
  struct b al[7] = {{7, 9, 8}, {7, 1, 2}, {7, 9, 8}, {7, 1, 2}, {7, 9,
8}, {7, 1, 2}, {7, 9, 0}};
  if (an.d) {
int d[8] = {0, 1, 0, 1, 0, 1, 0, 1};
if (ad)
  goto ak;
while (ag)
  g = an.d = i = m;
f = j;
  }
  n++;
}
  f = q.d;
}
if (l.c && m) {
  int d[7] = {1, 0, 1, 0, 1, 0, 1};
  if (x)
h = an.d;
  else
g = 0;
}
  }
  int bb = (q.d ^ ah.c) | aa | (q.e & q.c) | (f & ah.d);
  if (bb)
return x;
  return 0;
}
int main() {
  j = 1;
  s(0);
  return 0;
}

[Bug target/112279] ICE building sqlite-3.43.2 on s390 (internal compiler error: in extract_insn)

[sjames at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Sam James  ---
Minimised.

```
$ s390-ibm-linux-gnu-gcc -c sqlite-shell.i -O3 -march=arch13 -mzarch -c
sqlite-shell.i
sqlite-shell.i: In function 'shellAddSchemaName':
sqlite-shell.i:7:1: error: unrecognizable insn:
7 | }
  | ^
(insn 7 6 8 2 (set (reg:SI 65)
(plus:SI (reg/f:SI 61)
(const_int 1 [0x1]))) "sqlite-shell.i":4:10 -1
 (nil))
during RTL pass: vregs
sqlite-shell.i:7:1: internal compiler error: in extract_insn, at recog.cc:2791
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
sqlite-shell.i: In function 'shellAddSchemaName':
sqlite-shell.i:7:1: error: unrecognizable insn:
7 | }
  | ^
(insn 7 6 8 2 (set (reg:SI 65)
(plus:SI (reg/f:SI 61)
(const_int 1 [0x1]))) "sqlite-shell.i":4:10 -1
 (nil))
during RTL pass: vregs
sqlite-shell.i:7:1: internal compiler error: in extract_insn, at recog.cc:2791
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
```

```
$ cat sqlite-shell.i
char *shellAddSchemaName___trans_tmp_1;
void shellAddSchemaName() {
  char *z2 = "TABLE";
  while (*z2)
z2++;
  shellAddSchemaName___trans_tmp_1 = z2;
}
```

[Bug target/112279] ICE building sqlite-3.43.2 on s390 (internal compiler error: in extract_insn)

[sjames at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Sam James  ---
I can hit this with both a 13 cross compiler and 14 native.

[Bug target/112280] [14 regression] ICE building libgcrypt-1.10.2 on s390 (during GIMPLE pass: ccp)

[sjames at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Sam James  ---
(In reply to Sam James from comment #2)
> I can't hit this with a 13 cross compiler.

(-> 14 regression)

[Bug target/112280] [14 regression] ICE building libgcrypt-1.10.2 on s390 (during GIMPLE pass: ccp)

[sjames at gcc dot gnu.org via Gcc-bugs]

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

Sam James  changed:

   What|Removed |Added

Summary|ICE building|[14 regression] ICE
   |libgcrypt-1.10.2 on s390|building libgcrypt-1.10.2
   |(during GIMPLE pass: ccp)   |on s390 (during GIMPLE
   ||pass: ccp)

--- Comment #2 from Sam James  ---
I can't hit this with a 13 cross compiler.

[Bug tree-optimization/112281] [12/13/14 Regression] wrong code at -O3 on x86_64-linux-gnu

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-10-29
 Status|UNCONFIRMED |NEW
   Keywords||needs-bisection

--- Comment #2 from Andrew Pinski  ---
Confirmed.

[Bug tree-optimization/112281] [12/13/14 Regression] wrong code at -O3 on x86_64-linux-gnu

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Andrew Pinski  ---
-fno-tree-loop-distribution fixes the issue.

Looks like loop distribution is pulling out the assignment of `b = d[c + 1];`
from the loop even though the loop does assignment to a field of that `d[c +
1].a = 0;`.

[Bug tree-optimization/112281] [12/13/14 Regression] wrong code at -O3 on x86_64-linux-gnu

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.4
Summary|wrong code at -O3 on|[12/13/14 Regression] wrong
   |x86_64-linux-gnu|code at -O3 on
   ||x86_64-linux-gnu

[Bug tree-optimization/112281] New: wrong code at -O3 on x86_64-linux-gnu

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 112281
   Summary: wrong code at -O3 on x86_64-linux-gnu
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

This is a regression from 11.*, and affects 12.* and later. It should be
distinct from those couple of open issues with loop splitting. 

Compiler Explorer: https://godbolt.org/z/1anT983Td

[573] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20231029 (experimental) (GCC) 
[574] % 
[574] % gcctk -O2 small.c; ./a.out
[575] % 
[575] % gcctk -O3 small.c; ./a.out
Aborted
[576] % gcctk -O3 -fno-split-loops small.c; ./a.out
Aborted
[577] % 
[577] % cat small.c
struct {
  int : 8;
  int a;
} b, d[4] = {{0}, {0}, {0}, {5}};
int c, e;
int main() {
  for (c = 2; c; c--)
for (e = 0; e < 2; e++) {
  d[c] = b = d[c + 1];
  d[c + 1].a = 0;
}
  if (b.a != 0)
__builtin_abort();
  return 0;
}

[Bug target/112280] ICE building libgcrypt-1.10.2 on s390 (during GIMPLE pass: ccp)

[sjames at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Sam James  ---
s390-ibm-linux-gnu-gcc -c rijndael.i -O3 -march=arch13 -mzarch is enough to
reproduce (getting rid of -march=native)

[Bug target/112280] New: ICE building libgcrypt-1.10.2 on s390 (during GIMPLE pass: ccp)

[sjames at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 112280
   Summary: ICE building libgcrypt-1.10.2 on s390 (during GIMPLE
pass: ccp)
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

Created attachment 56471
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56471=edit
rijndael.i.xz

Reproduces with just s390-ibm-linux-gnu-gcc -c rijndael.i -O3 -march=native.

```
$ s390-ibm-linux-gnu-gcc -DHAVE_CONFIG_H -I.
-I/var/tmp/portage/dev-libs/libgcrypt-1.10.2/work/libgcrypt-1.10.2/cipher -I..
-I../src -I/var/tmp/portage/dev-libs/libgcrypt-1.10.2/work/libgcrypt-1.10.2/src
-I../mpi -I/var/tmp/portage/dev-libs/libgcrypt-1.10.2/work/libgcrypt-1.10.2/mpi
-O3 -pipe -march=native -fvisibility=hidden -fno-delete-null-pointer-checks
-Wall -c
/var/tmp/portage/dev-libs/libgcrypt-1.10.2/work/libgcrypt-1.10.2/cipher/rijndael.c
 -fPIC -DPIC -o .libs/rijndael.o
during GIMPLE pass: ccp
/var/tmp/portage/dev-libs/libgcrypt-1.10.2/work/libgcrypt-1.10.2/cipher/rijndael.c:
In function ‘_gcry_aes_xts_crypt’:
/var/tmp/portage/dev-libs/libgcrypt-1.10.2/work/libgcrypt-1.10.2/cipher/rijndael.c:1467:1:
internal compiler error: Segmentation fault
 1467 | _gcry_aes_xts_crypt (void *context, unsigned char *tweak,
  | ^~~
0x578a8971 internal_error(char const*, ...)
???:0
0x561044b4 gen_rtx_SUBREG(machine_mode, rtx_def*, poly_int<1u, unsigned long
long>)
???:0
0x56cff0b5 s390_vectorize_vec_perm_const(machine_mode, machine_mode, rtx_def*,
rtx_def*, rtx_def*, vec_perm_indices const&)
???:0
0x56565995 can_vec_perm_const_p(machine_mode, machine_mode, vec_perm_indices
const&, bool)
???:0
0x5777c0bf gimple_simplify_VEC_PERM_EXPR(gimple_match_op*, gimple**, tree_node*
(*)(tree_node*), code_helper, tree_node*, tree_node*, tree_node*, tree_node*)
???:0
0x56ea311d gimple_simplify(gimple_match_op*, gimple**, tree_node*
(*)(tree_node*), code_helper, tree_node*, tree_node*, tree_node*, tree_node*)
???:0
0x56fa3df9 gimple_simplify(gimple*, gimple_match_op*, gimple**, tree_node*
(*)(tree_node*), tree_node* (*)(tree_node*))
???:0
0x56242f6f gimple_fold_stmt_to_constant_1(gimple*, tree_node* (*)(tree_node*),
tree_node* (*)(tree_node*))
???:0
0x56a19947 ssa_propagation_engine::simulate_stmt(gimple*)
???:0
0x56a19d8d ssa_propagation_engine::simulate_block(basic_block_def*)
???:0
0x56a1a411 ssa_propagation_engine::ssa_propagate()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
```

```
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/s390-ibm-linux-gnu/14/lto-wrapper
Target: s390-ibm-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20231022-r1/work/gcc-14-20231022/configure
--host=s390-ibm-linux-gnu --build=s390-ibm-linux-gnu --prefix=/usr
--bindir=/usr/s390-ibm-linux-gnu/gcc-bin/14
--includedir=/usr/lib/gcc/s390-ibm-linux-gnu/14/include
--datadir=/usr/share/gcc-data/s390-ibm-linux-gnu/14
--mandir=/usr/share/gcc-data/s390-ibm-linux-gnu/14/man
--infodir=/usr/share/gcc-data/s390-ibm-linux-gnu/14/info
--with-gxx-include-dir=/usr/lib/gcc/s390-ibm-linux-gnu/14/include/g++-v14
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/s390-ibm-linux-gnu/14/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--disable-libunwind-exceptions --enable-checking=yes,extra,rtl
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo
14.0.0_pre20231022-r1 p7' --with-gcc-major-version-only --enable-libstdcxx-time
--enable-lto --disable-libstdcxx-pch --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --disable-multilib
--disable-fixed-point --enable-libgomp --disable-libssp --disable-libada
--disable-cet --disable-systemtap --disable-valgrind-annotations
--disable-vtable-verify --disable-libvtv --without-zstd --without-isl
--disable-libsanitizer --enable-default-pie --enable-host-pie
--disable-host-bind-now --enable-default-ssp
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20231022 (experimental) (Gentoo 14.0.0_pre20231022-r1 p7)
```

[Bug target/112279] ICE building sqlite-3.43.2 on s390 (internal compiler error: in extract_insn)

[sjames at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Sam James  ---
getting rid of -march=native: s390-ibm-linux-gnu-gcc -c sqlite3-shell.i -O3
-march=arch13 -mzarch ICEs for me

[Bug target/112279] ICE building sqlite-3.43.2 on s390 (internal compiler error: in extract_insn)

[sjames at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Sam James  ---
```
# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/s390-ibm-linux-gnu/14/lto-wrapper
Target: s390-ibm-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20231022-r1/work/gcc-14-20231022/configure
--host=s390-ibm-linux-gnu --build=s390-ibm-linux-gnu --prefix=/usr
--bindir=/usr/s390-ibm-linux-gnu/gcc-bin/14
--includedir=/usr/lib/gcc/s390-ibm-linux-gnu/14/include
--datadir=/usr/share/gcc-data/s390-ibm-linux-gnu/14
--mandir=/usr/share/gcc-data/s390-ibm-linux-gnu/14/man
--infodir=/usr/share/gcc-data/s390-ibm-linux-gnu/14/info
--with-gxx-include-dir=/usr/lib/gcc/s390-ibm-linux-gnu/14/include/g++-v14
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/s390-ibm-linux-gnu/14/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--disable-libunwind-exceptions --enable-checking=yes,extra,rtl
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo
14.0.0_pre20231022-r1 p7' --with-gcc-major-version-only --enable-libstdcxx-time
--enable-lto --disable-libstdcxx-pch --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --disable-multilib
--disable-fixed-point --enable-libgomp --disable-libssp --disable-libada
--disable-cet --disable-systemtap --disable-valgrind-annotations
--disable-vtable-verify --disable-libvtv --without-zstd --without-isl
--disable-libsanitizer --enable-default-pie --enable-host-pie
--disable-host-bind-now --enable-default-ssp
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20231022 (experimental) (Gentoo 14.0.0_pre20231022-r1 p7)
```

[Bug target/112279] New: ICE building sqlite-3.43.2 on s390 (internal compiler error: in extract_insn)

[sjames at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 112279
   Summary: ICE building sqlite-3.43.2 on s390 (internal compiler
error: in extract_insn)
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

Created attachment 56470
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56470=edit
sqlite-shell.i.xz

Hit this when building sqlite-3.43.2 on s390.

```
# s390-ibm-linux-gnu-gcc -c sqlite3-shell.i -O3 -march=native
shell.c: In function ‘display_stats.constprop.isra’:
shell.c:19108:1: error: unrecognizable insn:
(insn 509 508 510 28 (set (reg:SI 273)
(plus:SI (reg/f:SI 269)
(const_int 1 [0x1]))) "shell.c":884:10 discrim 1 -1
 (nil))
during RTL pass: vregs
shell.c:19108:1: internal compiler error: in extract_insn, at recog.cc:2791
0x5765f971 internal_error(char const*, ...)
???:0
0x55b1dad3 fancy_abort(char const*, int, char const*)
???:0
0x55afd665 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
???:0
0x55afd721 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
???:0
0x5640a593 extract_insn(rtx_insn*)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
```

```
# for t in param target; do cmd="gcc -Q -O1 --help=$t"; diff -U0 <(LANG=C $cmd)
<(LANG=C $cmd -march=native); done
--- /dev/fd/63  2023-10-29 16:33:05.114542515 -0400
+++ /dev/fd/62  2023-10-29 16:33:05.114542515 -0400
@@ -122,2 +122,2 @@
-  --param=max-completely-peel-times=   16
-  --param=max-completely-peeled-insns= 200
+  --param=max-completely-peel-times=   64
+  --param=max-completely-peeled-insns= 2000
@@ -188,2 +188,2 @@
-  --param=max-unroll-times=8
-  --param=max-unrolled-insns=  200
+  --param=max-unroll-times=32
+  --param=max-unrolled-insns=  100
@@ -286 +286 @@
-  --param=vect-partial-vector-usage=<0,2>  0
+  --param=vect-partial-vector-usage=<0,2>  1
--- /dev/fd/63  2023-10-29 16:33:05.114542515 -0400
+++ /dev/fd/62  2023-10-29 16:33:05.114542515 -0400
@@ -5 +5 @@
-  -march=  arch5
+  -march=  arch13
@@ -10 +10 @@
-  -mesa[enabled]
+  -mesa[disabled]
@@ -17 +17 @@
-  -mhard-dfp   [disabled]
+  -mhard-dfp   [enabled]
@@ -20 +20 @@
-  -mhtm[disabled]
+  -mhtm[enabled]
@@ -41 +41 @@
-  -mtune=  arch5
+  -mtune=  arch13
@@ -45 +45 @@
-  -mvx [disabled]
+  -mvx [enabled]
@@ -49 +49 @@
-  -mzarch  [disabled]
+  -mzarch  [enabled]
```

[Bug target/112276] [14 Regression] wrong code with -O2 -msse4.2 since r14-4964-g7eed861e8ca3f5

[tkoenig at gcc dot gnu.org via Gcc-bugs]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||liuhongt at gcc dot gnu.org
Summary|[14 Regression] wrong code  |[14 Regression] wrong code
   |with -O2 -msse4.2   |with -O2 -msse4.2 since
   ||r14-4964-g7eed861e8ca3f5

--- Comment #2 from Thomas Koenig  ---
Bisected to r14-4964-g7eed861e8ca3f5 .

[Bug c++/112267] "inline function constexpr used but never defined" warning in SFINAE context

[falemagn at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Fabio Alemagna  ---
With a tweak(In reply to Andrew Pinski from comment #3)
> (In reply to Fabio Alemagna from comment #1)
> > Changing the return type of the function func() from int to auto makes the
> > warning disappear.
> > 
> > Incidentally it causes an error on clang, though, which prompts the
> > question: is this a clang bug, for erroring out, or a gcc bug, for not
> > erroring out?
> 
> I tested MSVC also. It errors out with /std:c++20 but not with /std:c++17 so
> maybe there was a change for C++20 that clang decided it applies for
> previous C++ too (and GCC did not implement that rule yet).


Making the function a template, while keeping the return type as 'auto', and
making its template parameter depend on the template parameter of the caller,
solves the error and silences the warning on gcc.


Making the return value 'bool', even if the function is a template, still makes
the warning appear.


On Compiler Explorer: https://godbolt.org/z/E5qMT55MW

[Bug d/110712] d: ICE: verify_gimple_failed (conversion of register to a different size in 'view_convert_expr')

[ibuclaw at gcc dot gnu.org via Gcc-bugs]

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

ibuclaw at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||ibuclaw at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED

--- Comment #7 from ibuclaw at gcc dot gnu.org ---
Fix committed and backported.

[Bug d/110712] d: ICE: verify_gimple_failed (conversion of register to a different size in 'view_convert_expr')

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Iain Buclaw
:

https://gcc.gnu.org/g:77f7d469e923f2bb1d21d3875290ce738262d42b

commit r12-9951-g77f7d469e923f2bb1d21d3875290ce738262d42b
Author: Iain Buclaw 
Date:   Sun Oct 29 20:13:14 2023 +0100

d: Fix ICE: verify_gimple_failed (conversion of register to a different
size in 'view_convert_expr')

Static arrays in D are passed around by value, rather than decaying to a
pointer.  On x86_64 __builtin_va_list is an exception to this rule, but
semantically it's still treated as a static array.

This makes certain assignment operations fail due a mismatch in types.
As all examples in the test program are rejected by C/C++ front-ends,
these are now errors in D too to be consistent.

PR d/110712

gcc/d/ChangeLog:

* d-codegen.cc (d_build_call): Update call to convert_for_argument.
* d-convert.cc (is_valist_parameter_type): New function.
(check_valist_conversion): New function.
(convert_for_assignment): Update signature.  Add check whether
assigning va_list is permissible.
(convert_for_argument): Likewise.
* d-tree.h (convert_for_assignment): Update signature.
(convert_for_argument): Likewise.
* expr.cc (ExprVisitor::visit (AssignExp *)): Update call to
convert_for_assignment.

gcc/testsuite/ChangeLog:

* gdc.dg/pr110712.d: New test.

(cherry picked from commit ea8ffdcadb388b531adf4772287e7987a82a84b7)

[Bug d/110712] d: ICE: verify_gimple_failed (conversion of register to a different size in 'view_convert_expr')

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Iain Buclaw
:

https://gcc.gnu.org/g:46024d05a2cbbc1c2397e5728a98f90449b20ca4

commit r13-7992-g46024d05a2cbbc1c2397e5728a98f90449b20ca4
Author: Iain Buclaw 
Date:   Sun Oct 29 20:13:14 2023 +0100

d: Fix ICE: verify_gimple_failed (conversion of register to a different
size in 'view_convert_expr')

Static arrays in D are passed around by value, rather than decaying to a
pointer.  On x86_64 __builtin_va_list is an exception to this rule, but
semantically it's still treated as a static array.

This makes certain assignment operations fail due a mismatch in types.
As all examples in the test program are rejected by C/C++ front-ends,
these are now errors in D too to be consistent.

PR d/110712

gcc/d/ChangeLog:

* d-codegen.cc (d_build_call): Update call to convert_for_argument.
* d-convert.cc (is_valist_parameter_type): New function.
(check_valist_conversion): New function.
(convert_for_assignment): Update signature.  Add check whether
assigning va_list is permissible.
(convert_for_argument): Likewise.
* d-tree.h (convert_for_assignment): Update signature.
(convert_for_argument): Likewise.
* expr.cc (ExprVisitor::visit (AssignExp *)): Update call to
convert_for_assignment.

gcc/testsuite/ChangeLog:

* gdc.dg/pr110712.d: New test.

(cherry picked from commit ea8ffdcadb388b531adf4772287e7987a82a84b7)

[Bug d/110712] d: ICE: verify_gimple_failed (conversion of register to a different size in 'view_convert_expr')

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

https://gcc.gnu.org/g:ea8ffdcadb388b531adf4772287e7987a82a84b7

commit r14-4997-gea8ffdcadb388b531adf4772287e7987a82a84b7
Author: Iain Buclaw 
Date:   Sun Oct 29 20:13:14 2023 +0100

d: Fix ICE: verify_gimple_failed (conversion of register to a different
size in 'view_convert_expr')

Static arrays in D are passed around by value, rather than decaying to a
pointer.  On x86_64 __builtin_va_list is an exception to this rule, but
semantically it's still treated as a static array.

This makes certain assignment operations fail due a mismatch in types.
As all examples in the test program are rejected by C/C++ front-ends,
these are now errors in D too to be consistent.

PR d/110712

gcc/d/ChangeLog:

* d-codegen.cc (d_build_call): Update call to convert_for_argument.
* d-convert.cc (is_valist_parameter_type): New function.
(check_valist_conversion): New function.
(convert_for_assignment): Update signature.  Add check whether
assigning va_list is permissible.
(convert_for_argument): Likewise.
* d-tree.h (convert_for_assignment): Update signature.
(convert_for_argument): Likewise.
* expr.cc (ExprVisitor::visit (AssignExp *)): Update call to
convert_for_assignment.

gcc/testsuite/ChangeLog:

* gdc.dg/pr110712.d: New test.

[Bug target/110551] [11/12/13/14 Regression] an extra mov when doing 128bit multiply

[moncef.mechri at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Moncef Mechri  ---
I confirm the extra mov disappears thanks to Roger's patch.

However, the codegen still seems suboptimal to me when using -march=haswell or
newer, even with Roger's patch:

uint64_t mulx64(uint64_t x)
{
__uint128_t r = (__uint128_t)x * 0x9E3779B97F4A7C15ull;
return (uint64_t)r ^ (uint64_t)( r >> 64 );
}


With -O2:

mulx64(unsigned long):
movabs  rax, -7046029254386353131
mul rdi
xor rax, rdx
ret

With -O2 -march=haswell

mulx64(unsigned long):
movabs  rdx, -7046029254386353131
mulxrdi, rsi, rdi
mov rax, rdi
xor rax, rsi
ret

So it looks like there is still one extra mov, since I think the optimal
codegen using mulx should be:

mulx64(unsigned long):
movabs  rdx, -7046029254386353131
mulxrax, rsi, rdi
xor rax, rsi
ret

[Bug rtl-optimization/112278] lra: ICE in partial_subreg_p for mixture of AdvSIMD & SVE register asms

[rsandifo at gcc dot gnu.org via Gcc-bugs]

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

Richard Sandiford  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-10-29
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org

--- Comment #1 from Richard Sandiford  ---
Testing a patch.

[Bug rtl-optimization/112278] New: lra: ICE in partial_subreg_p for mixture of AdvSIMD & SVE register asms

[rsandifo at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 112278
   Summary: lra: ICE in partial_subreg_p for mixture of AdvSIMD &
SVE register asms
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rsandifo at gcc dot gnu.org
  Target Milestone: ---

The following test, compiled with -march=armv8.2-a+sve, ICEs in
partial_subreg_p, called from new_insn_reg:

#include 
#include 

void
f (void)
{
  {
register svint8_t v0 asm ("z0");
asm volatile ("" : "=w" (v0));
  }
  {
register int8x8x4_t v0 asm ("v0");
asm volatile ("" : "=w" (v0));
  }
}

GCC 10 behaves similarly, so I don't think this is a regression.

[Bug c++/112267] "inline function constexpr used but never defined" warning in SFINAE context

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Fabio Alemagna from comment #1)
> Changing the return type of the function func() from int to auto makes the
> warning disappear.
> 
> Incidentally it causes an error on clang, though, which prompts the
> question: is this a clang bug, for erroring out, or a gcc bug, for not
> erroring out?

I tested MSVC also. It errors out with /std:c++20 but not with /std:c++17 so
maybe there was a change for C++20 that clang decided it applies for previous
C++ too (and GCC did not implement that rule yet).

[Bug c++/112267] "inline function constexpr used but never defined" warning in SFINAE context

[falemagn at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Fabio Alemagna  ---
Sorry, "from int to auto" should have been "from bool to auto". You get the
point.

[Bug c++/112267] "inline function constexpr used but never defined" warning in SFINAE context

[falemagn at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Fabio Alemagna  ---
Changing the return type of the function func() from int to auto makes the
warning disappear.

Incidentally it causes an error on clang, though, which prompts the question:
is this a clang bug, for erroring out, or a gcc bug, for not erroring out?

See it on Compiler Explorer: https://godbolt.org/z/4ETs4ca3d

[Bug c++/112269] [14 Regression] x86_64 GNU/Linux '-m32' multilib 'libstdc++-v3/include/complex:1493: internal compiler error: in tsubst_expr, at cp/pt.cc:21534' since r14-4796-g3e3d73ed5e85e7

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-10-29
   Keywords||needs-reduction
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #4 from Andrew Pinski  ---
(In reply to Andreas Schwab from comment #2)
> Similar failures on m68k.

That gives more evidence that is excess-precision related really.

[Bug tree-optimization/112272] suboptimal zero-initialization of struct of mixed pointer and integer types

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug tree-optimization/112277] Missed optimization of loop deletion because of missed loopUnswitch and useless instruction elimination

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||missed-optimization

[Bug c++/112273] gcc crashs when checking satisfaction a constraint of lambda function and using decltype of a variable argument template

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-10-29
Summary|gcc crashs when checking|gcc crashs when checking
   |satisfaction a constraint   |satisfaction a constraint
   |of lambda function  |of lambda function and
   ||using decltype of a
   ||variable argument template
 Status|UNCONFIRMED |NEW
   Keywords||c++-lambda
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed, slightly reduced/changed:
```
template  struct Tp {};

template  struct make_delayed {
  static constexpr inline bool value = true;
};

template 
concept K = make_delayed::value;


template
constexpr auto ice(t... arg) {
  using Tp_t = Tp;
  return []() requires K
  { return 1; };
};

int main() {
  constexpr auto l = ice(1);
  static_assert(l() == 1);
  return 0;
}
```

If I replace `decltype(arg)` with `t`, GCC no longer ICEs. This is why I moved
away from using auto here to show a case where it is working correctly.

[Bug c++/19538] [DR 407] Bogus diagnostic for typedef name in elaborated type specifier

[egallager at gcc dot gnu.org via Gcc-bugs]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #5 from Eric Gallager  ---
(In reply to Jonathan Wakely from comment #4)
> Un-suspending, and changing from accepts-invalid to rejects-valid.
> 
> Both [1] and [2] are valid now and should be accepted.

Still a diagnostic issue even it's now rejects-valid instead of accepts-valid,
IMO.

[Bug target/112276] [14 Regression] wrong code with -O2 -msse4.2

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-10-29
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Confirmed.

[Bug target/112276] [14 Regression] wrong code with -O2 -msse4.2

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug rtl-optimization/82111] kcoreaddons-5.37.0: desktopfileparser.cpp miscompiled in dbr pass

[danglin at gcc dot gnu.org via Gcc-bugs]

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

John David Anglin  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #3 from John David Anglin  ---
gcc-12 is known to work.

[Bug c++/112275] target_clones breaks exception handling

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Andrew Pinski  ---
Dup of bug 106627

*** This bug has been marked as a duplicate of bug 106627 ***

[Bug ipa/106627] Exception from multiversion function cannot be caught

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||erosenberger at kinetica dot 
com

--- Comment #6 from Andrew Pinski  ---
*** Bug 112275 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/112277] New: Missed optimization of loop deletion because of missed loopUnswitch and useless instruction elimination

[652023330028 at smail dot nju.edu.cn via Gcc-bugs]

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

Bug ID: 112277
   Summary: Missed optimization of loop deletion because of missed
loopUnswitch and useless instruction elimination
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 652023330028 at smail dot nju.edu.cn
  Target Milestone: ---

Hello, we noticed that the loop in the code below is not necessary. But GCC
misses this loop deletion optimization, probably because of the missing in loop
Unswitch and useless instruction elimination annotated below.

https://godbolt.org/z/vMPGnhc9n
int b, c;
int n;
void test() {
  for (int i = 0; i < 1000; i += b) {
if(c < 0){
c = n;
}
  }
}

GCC -O3:
test():
mov ecx, DWORD PTR c[rip]
mov edi, DWORD PTR n[rip]
xor esi, esi
xor eax, eax
mov edx, DWORD PTR b[rip]
testecx, ecx
jns .L3
.L2:  #Loop
add eax, edx
mov esi, 1
mov ecx, edi  #Loop invariants: edi
cmp eax, 999
jg  .L13
testecx, ecx  #Loop invariants: ecx
js  .L2   #Missed LoopUnswitch
.L3:  #Useless instructions
add eax, edx
cmp eax, 999
jle .L3   #Useless instructions
testsil, sil
je  .L1
.L13:
mov DWORD PTR c[rip], ecx
.L1:
ret

Expected code:
test():
mov eax, DWORD PTR c[rip]
testeax, eax
js  .L4
ret
.L4:
mov eax, DWORD PTR n[rip]
mov DWORD PTR c[rip], eax
ret

Thank you very much for your time and effort! We look forward to hearing from
you.

[Bug target/112276] New: [14 Regression] wrong code with -O2 -msse4.2

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 112276
   Summary: [14 Regression] wrong code with -O2 -msse4.2
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 56469
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56469=edit
reduced testcase

Output:
$ x86_64-pc-linux-gnu-gcc -O2 -msse4.2 testcase.c
$ ./a.out 
Aborted

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-4995-20231029071248-gc6929b08558-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-4995-20231029071248-gc6929b08558-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231029 (experimental) (GCC)

[Bug c++/112275] New: target_clones breaks exception handling

[erosenberger at kinetica dot com via Gcc-bugs]

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

Bug ID: 112275
   Summary: target_clones breaks exception handling
   Product: gcc
   Version: 11.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: erosenberger at kinetica dot com
  Target Milestone: ---

Given the following code:

#include 

__attribute__((target_clones("default,avx2")))
void foo()
{
throw std::runtime_error("");
}

int main()
{
try { foo(); } catch (...) { }
}

The program will immediately terminate when the exception is thrown, instead of
catching it in the try. Removing the target_clones attribute causes the program
to behave as expected.

Using Compiler Explorer it appears that this is working in 13, but is broken
for all prior versions.

gcc -v:
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
11.4.0-1ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-11
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-11-XeT9lY/gcc-11-11.4.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-XeT9lY/gcc-11-11.4.0/debian/tmp-gcn/usr
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)

[Bug c/112274] New: Bug due to unused expressions on s390x

[22s302h0659 at sonline20 dot sen.go.kr via Gcc-bugs]

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

Bug ID: 112274
   Summary: Bug due to unused expressions on s390x
   Product: gcc
   Version: 11.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 22s302h0659 at sonline20 dot sen.go.kr
  Target Milestone: ---

### Environment

- Compiler: s390x-linux-gnu-gcc (64bit)
- Version: gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)
- Platform: Windows 11_5.15.90.1-microsoft-standard-WSL2
- Build Optimization Options: O0, O1, O2, O3

I installed the s390x-linux-gnu toolchain using the 'apt' package manager in
Ubuntu and utilized s390x-linux-gnu-gcc (version 11.4.0) from it.

### build script & excution script

```bash
s390x-linux-gnu-gcc ./bug_Poc.c -o test_O0 -g -O0 -fsanitize=undefined -Wall
-Wextra -fno-strict-aliasing #-fwrapv
s390x-linux-gnu-gcc ./bug_Poc.c -o test_O1 -g -O1 -fsanitize=undefined -Wall
-Wextra -fno-strict-aliasing #-fwrapv
s390x-linux-gnu-gcc ./bug_Poc.c -o test_O2 -g -O2 -fsanitize=undefined -Wall
-Wextra -fno-strict-aliasing #-fwrapv
s390x-linux-gnu-gcc ./bug_Poc.c -o test_O3 -g -O3 -fsanitize=undefined -Wall
-We
gcc ./bug_Poc.c -o gcc_O0 -g -O0 -fsanitize=undefined -Wall -Wextra
-fno-strict-aliasing #-fwrapv
gcc ./bug_Poc.c -o gcc_O1 -g -O1 -fsanitize=undefined -Wall -Wextra
-fno-strict-aliasing #-fwrapv
gcc ./bug_Poc.c -o gcc_O2 -g -O2 -fsanitize=undefined -Wall -Wextra
-fno-strict-aliasing #-fwrapv
gcc ./bug_Poc.c -o gcc_O3 -g -O3 -fsanitize=undefined -Wall -Wextra
-fno-strict-aliasing #-fwrapv

clang ./bug_Poc.c -o clang_O0 -g -O0 -fsanitize=undefined -Wall -Wextra
-fno-strict-aliasing #-fwrapv
clang ./bug_Poc.c -o clang_O1 -g -O1 -fsanitize=undefined -Wall -Wextra
-fno-strict-aliasing #-fwrapv
clang ./bug_Poc.c -o clang_O2 -g -O2 -fsanitize=undefined -Wall -Wextra
-fno-strict-aliasing #-fwrapv
clang ./bug_Poc.c -o clang_O3 -g -O3 -fsanitize=undefined -Wall -Wextra
-fno-strict-aliasing #-fwrapv
```

```bash
qemu-s390x-static -L /usr/s390x-linux-gnu/ ./test_O0
qemu-s390x-static -L /usr/s390x-linux-gnu/ ./test_O1
qemu-s390x-static -L /usr/s390x-linux-gnu/ ./test_O2
qemu-s390x-static -L /usr/s390x-linux-gnu/ ./test_O3

./gcc_O0
./gcc_O1
./gcc_O2
./gcc_O3

./clang_O0
./clang_O1
./clang_O2
./clang_O3
```

### Source Code

```c
0 // bug_Poc.c
1 #include 
2 short g_4 = 2;
3 short g_8 = 1;
4 int main()
5 {
6printf("bug = %d\n", (g_4 < (((g_8 << 0) / g_4), g_8)));
7 return 0;
8 }
```

The output varies based on optimization options on the 6th line. I've attempted
several approaches to understand the cause. Even though the left expression of
the comma operator is an unused value, removing the expression triggers the
bug.

### Result

```c
bug = 0
bug = 0
bug = 1
bug = 1
bug = 0
bug = 0
bug = 0
bug = 0
bug = 0
bug = 0
bug = 0
bug = 0
```

### Coclusion

I reported a bug on s390x architecture some time ago. Back then, incorrect
values were generated in O0 and O1, but this time incorrect values are produced
in O2 and O3. When such bugs intersect with other vulnerabilities, it could be
exploited as a powerful attack vector.

[Bug target/94758] ICE: in extract_insn, at recog.c:2310 on hppa64 with __thread variable

[sjames at gcc dot gnu.org via Gcc-bugs]

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

Sam James  changed:

   What|Removed |Added

   Last reconfirmed||2023-10-29
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Sam James  ---
(Re)confirmed with 12.3.1 20230512.

[Bug c++/112273] New: gcc crashs when checking satisfaction a constraint of lambda function

[rungecc at gmail dot com via Gcc-bugs]

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

Bug ID: 112273
   Summary: gcc crashs when checking satisfaction a constraint of
lambda function
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rungecc at gmail dot com
  Target Milestone: ---

Created attachment 56468
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56468=edit
ICE output

```c++
template  struct Tp {};

template  struct make_delayed {
  static constexpr inline bool value = true;
};

template 
concept K = make_delayed::value;

[[maybe_unused]] constexpr auto ice(auto... arg) {
  using Tp_t = Tp;
  return []()
requires K
  { return 1; };
};

int main() {
  constexpr auto l = ice(1, 2);
  static_assert(l() == 1);
  return 0;
}
```

See also [online compiler](https://godbolt.org/z/r8K4bK199).

Gcc (checked version 14.0, 13.2, 12.3) with flag `-std=c++2b` crashed on the
above code snippets.

Output, see the attachment.

**NOTE**:

Seems we need 1) a dependent constraint attached to some function and 2) such
constraint refers to a type contains a (dependent) pack expansion in it's
definition to trigger this ICE.

[Bug c++/112269] [14 Regression] x86_64 GNU/Linux '-m32' multilib 'libstdc++-v3/include/complex:1493: internal compiler error: in tsubst_expr, at cp/pt.cc:21534'

[schwab--- via Gcc-bugs]

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

Andreas Schwab  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #3 from Andreas Schwab  ---
Bisected to commit 3e3d73ed5e85

Author: Patrick Palka 
Date:   Fri Oct 20 11:21:54 2023 -0400

c++: merge tsubst_copy into tsubst_copy_and_build

[Bug target/112112] Improper Arithmetic Type Conversion in s390x-linux-gnu-gcc

[tkoenig at gcc dot gnu.org via Gcc-bugs]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #5 from Thomas Koenig  ---
(In reply to 김대영 from comment #4)
> From your perspective, do you think this could be a compiler bug? When
> tested with various compiler options following the GCC bug reporting
> guidelines, the binary compiles without any warnings, yet exhibits these
> behaviors

It definitely sounds wrong, there should be consistent results.

Just to make the effect of the signs clear: Could you maybe run the
program

$ cat a.c
#include 
SIGN char v1 = -1;
short v2 = 1;
int main()
{   
printf("result for " OPT " \"" STR "\" = %d\n", v1 <= v2);
return 0;
}

with the shell script

$ cat do_all.sh 
for s in signed unsigned ""
do
for o in -O0 -O1 -O2 -O3
do
gcc $o -DOPT='"'$o'"' -DSTR='"'$s'"' -DSIGN=$s a.c && ./a.out
done
done

and post the results?  For reference, on x86_64 (which has signed
chars) this gets

result for -O0 "signed" = 1
result for -O1 "signed" = 1
result for -O2 "signed" = 1
result for -O3 "signed" = 1
result for -O0 "unsigned" = 0
result for -O1 "unsigned" = 0
result for -O2 "unsigned" = 0
result for -O3 "unsigned" = 0
result for -O0 "" = 1
result for -O1 "" = 1
result for -O2 "" = 1
result for -O3 "" = 1

[Bug c++/112269] [14 Regression] x86_64 GNU/Linux '-m32' multilib 'libstdc++-v3/include/complex:1493: internal compiler error: in tsubst_expr, at cp/pt.cc:21534'

[schwab--- via Gcc-bugs]

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

Andreas Schwab  changed:

   What|Removed |Added

 Target|x86_64 i?86 |x86_64 i?86 m68k-*-*

--- Comment #2 from Andreas Schwab  ---
Similar failures on m68k.

g++.dg/cpp0x/initlist13.C  -std=c++20 (internal compiler error: in tsubst_expr,
at cp/pt.cc:21534)
g++.dg/cpp0x/udlit-general.C  -std=c++20 (internal compiler error: in
tsubst_expr, at cp/pt.cc:21534)
g++.dg/cpp1y/complex_literals1.C  -std=c++20 (internal compiler error: in
tsubst_expr, at cp/pt.cc:21534)
g++.dg/cpp1y/udlit-userdef-string.C  -std=c++20 (internal compiler error: in
tsubst_expr, at cp/pt.cc:21534)
g++.dg/modules/xtreme-header-5_a.H -std=c++2a (internal compiler error: in
tsubst_expr, at cp/pt.cc:21534)
g++.dg/modules/xtreme-header-5_a.H -std=c++2b (internal compiler error: in
tsubst_expr, at cp/pt.cc:21534)
g++.dg/modules/xtreme-header_a.H -std=c++2a (internal compiler error: in
tsubst_expr, at cp/pt.cc:21534)
g++.dg/modules/xtreme-header_a.H -std=c++2b (internal compiler error: in
tsubst_expr, at cp/pt.cc:21534)
g++.dg/modules/xtreme-tr1_a.H -std=c++2a (internal compiler error: in
tsubst_expr, at cp/pt.cc:21534)
g++.dg/modules/xtreme-tr1_a.H -std=c++2b (internal compiler error: in
tsubst_expr, at cp/pt.cc:21534)
g++.dg/opt/nrv17.C  -std=c++20 (internal compiler error: in tsubst_expr, at
cp/pt.cc:21534)
g++.old-deja/g++.brendan/crash20.C  -std=c++20 (internal compiler error: in
tsubst_expr, at cp/pt.cc:21534)
g++.old-deja/g++.law/ctors6.C  -std=c++20 (internal compiler error: in
tsubst_expr, at cp/pt.cc:21534)
g++.old-deja/g++.law/operators4.C  -std=c++20 (internal compiler error: in
tsubst_expr, at cp/pt.cc:21534)
g++.old-deja/g++.other/headers1.C  -std=c++20 (internal compiler error: in
tsubst_expr, at cp/pt.cc:21534)
g++.old-deja/g++.robertl/eb3.C  -std=c++20 (internal compiler error: in
tsubst_expr, at cp/pt.cc:21534)

[Bug tree-optimization/112272] New: suboptimal zero-initialization of struct of mixed pointer and integer types

[lh_mouse at 126 dot com via Gcc-bugs]

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

Bug ID: 112272
   Summary: suboptimal zero-initialization of struct of mixed
pointer and integer types
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lh_mouse at 126 dot com
  Target Milestone: ---

Testcase:
(https://gcc.godbolt.org/z/97cThnszM)

```
struct data_mixed
  {
int* p1;
int* p2;
__INTPTR_TYPE__ i3;
int* p4;

constexpr data_mixed() noexcept : p1(), p2(), i3(), p4() { }
  };

data_mixed
create_data_mixed()
  {
return {};  // somehow suboptimal ↓↓
//mov QWORD PTR [rdi+16], 0
//mov QWORD PTR [rdi+24], 0
//vmovdqu XMMWORD PTR [rdi], xmm0
  }


struct data_ptrs
  {
int* p1;
int* p2;
void* p3;
int* p4;

constexpr data_ptrs() noexcept : p1(), p2(), p3(), p4() { }
  };

data_ptrs
create_data_ptrs()
  {
return {}; // vmovdqu YMMWORD PTR [rdi], ymm0
  }


struct data_ints
  {
__INTPTR_TYPE__ p1;
__INTPTR_TYPE__ p2;
__INTPTR_TYPE__ p3;
__INTPTR_TYPE__ p4;

constexpr data_ints() noexcept : p1(), p2(), p3(), p4() { }
  };

data_ints
create_data_ints()
  {
return {};  // vmovdqu YMMWORD PTR [rdi], ymm0
  }
```

I believe these structs should be initialized in the same way, by storing a
zero YMM register. However mixed use of pointer and integer types seems to
prevent that. This is not specific to GCC 13; in GCC 12 it used to prevent
vectorization completely.

[Bug tree-optimization/109334] tree-object-size: Improve size computation in arguments

[sjames at gcc dot gnu.org via Gcc-bugs]

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

Sam James  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Target Milestone|--- |14.0
 Status|UNCONFIRMED |NEW
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=104970
   Last reconfirmed||2023-10-29

--- Comment #4 from Sam James  ---
Fixed for 14 then?

[Bug tree-optimization/109334] tree-object-size: Improve size computation in arguments

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Martin Uecker :

https://gcc.gnu.org/g:d96757842a13cad3500b74a352ab34d27a8be622

commit r14-4993-gd96757842a13cad3500b74a352ab34d27a8be622
Author: Martin Uecker 
Date:   Wed Oct 25 23:24:34 2023 +0200

tree-optimization/109334: Improve computation for access attribute

The fix for PR104970 restricted size computations to the case
where the access attribute was specified explicitly (no VLA).
It also restricted it to void pointers or elements with constant
sizes.  The second restriction is enough to fix the original bug.
Revert the first change to again allow size computations for VLA
parameters and for VLA parameters together with an explicit access
attribute.

gcc/ChangeLog:

PR tree-optimization/109334
* tree-object-size.cc (parm_object_size): Allow size
computation for implicit access attributes.

gcc/testsuite/ChangeLog:

PR tree-optimization/109334
* gcc.dg/builtin-dynamic-object-size-0.c
(test_parmsz_simple3): Supported again.
(test_parmsz_external4): New test.
* gcc.dg/builtin-dynamic-object-size-20.c: New test.
* gcc.dg/pr104970.c: New test.