[Bug debug/108843] New: timeout with -g -O3 ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 108843
   Summary: timeout with -g -O3 ?
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

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

The attached code does this:

$ (ulimit -t 60; time /home/dcb36/gcc/results/bin/gcc -c -w -O3 bug886.c)

real0m0.637s
user0m0.608s
sys 0m0.018s
$ (ulimit -t 60; time /home/dcb36/gcc/results/bin/gcc -c -w -g -O3 bug886.c)
gcc: fatal error: Killed signal terminated program cc1
compilation terminated.

real1m0.732s
user0m59.485s
sys 0m0.629s
$

[Bug tree-optimization/108825] [13 Regression] error during GIMPLE pass: unrolljam

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #9 from David Binderman  ---
(In reply to David Binderman from comment #8)
> (In reply to Andrew Pinski from comment #7)
> > (In reply to David Binderman from comment #6)
> > > git range now seems to be g:0cbb756fe9c8e13a .. g:bd044dae51caea3c,
> > > which is 6 commits.
> > 
> > Most likely r13-3875-g9e11ceef165bc0 .
> 
> Agreed. Over to Richard for their best advice.

Bisection finished. It does appear to be this revision.

[Bug tree-optimization/108825] [13 Regression] error during GIMPLE pass: unrolljam

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||rguenther at suse dot de

--- Comment #8 from David Binderman  ---
(In reply to Andrew Pinski from comment #7)
> (In reply to David Binderman from comment #6)
> > git range now seems to be g:0cbb756fe9c8e13a .. g:bd044dae51caea3c,
> > which is 6 commits.
> 
> Most likely r13-3875-g9e11ceef165bc0 .

Agreed. Over to Richard for their best advice.

[Bug tree-optimization/108825] [13 Regression] error during GIMPLE pass: unrolljam

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #6 from David Binderman  ---
git range now seems to be g:0cbb756fe9c8e13a .. g:bd044dae51caea3c,
which is 6 commits.

[Bug tree-optimization/108825] [13 Regression] error during GIMPLE pass: unrolljam

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #5 from David Binderman  ---
(In reply to David Binderman from comment #4)
> git range now seems to be g:59ad8b684dd67e17 .. g:3b54cc9d04c2efb2,
> which is 103 commits.

git range now seems to be g:0cbb756fe9c8e13a .. g:3b54cc9d04c2efb2,
which is 26 commits.

[Bug tree-optimization/108825] [13 Regression] error during GIMPLE pass: unrolljam

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #4 from David Binderman  ---
git range now seems to be g:59ad8b684dd67e17 .. g:3b54cc9d04c2efb2,
which is 103 commits.

[Bug tree-optimization/108825] [13 Regression] error during GIMPLE pass: unrolljam

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #3 from David Binderman  ---
(In reply to David Binderman from comment #2)
> Trying revision 1191a412bb17a734.

Seems bad. Trying 59ad8b684dd67e17.

[Bug tree-optimization/108825] [13 Regression] error during GIMPLE pass: unrolljam

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #2 from David Binderman  ---
Trying revision 1191a412bb17a734.

[Bug c/108825] New: error during GIMPLE pass: unrolljam

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 108825
   Summary: error during GIMPLE pass: unrolljam
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For this C code: 

safe_mul_func_uint8_t_u_u_ui2, g_231, g_277_1, g_568, func_35___trans_tmp_10;
g_81[7];
g_96[];
char func_35___trans_tmp_11;
safe_add_func_int32_t_s_s(si1, si2) { return si1 > 647 - si2 ?: si1; }
func_35() {
  for (; g_277_1; g_277_1 += 1) {
g_231 = 0;
for (; g_231 <= 6; g_231 += 1) {
  func_35___trans_tmp_10 =
  safe_add_func_int32_t_s_s(g_81[g_231], g_568 || g_96[1]);
  func_35___trans_tmp_11 =
  func_35___trans_tmp_10 * safe_mul_func_uint8_t_u_u_ui2;
  g_81[g_231] = func_35___trans_tmp_11;
}
  }
}

compiled by recent gcc, does this:

$ ~/gcc/results/bin/gcc -c -O3 -w bug885.c
bug885.c: In function ‘func_35’:
bug885.c:6:1: error: definition in block 43 does not dominate use in block 44
6 | func_35() {
  | ^~~
for SSA_NAME: _96 in statement:
_99 = (char) _96;
during GIMPLE pass: unrolljam
bug885.c:6:1: internal compiler error: verify_ssa failed
0x1027185 verify_ssa(bool, bool)
../../trunk.d1/gcc/tree-ssa.cc:1211

The bug first seems to occur sometime between g:4acc4c2be84d6607,
dated 20221101 and g:d0a3d55ae4a2656f, dated 20221130.

[Bug middle-end/108721] [10/11/12/13 Regression] csmith: really old bug with -O2

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #3 from David Binderman  ---
Created attachment 54471
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54471=edit
C source code

After a short reduction.

[Bug c/108718] [10/11/12/13 Regression] csmith: possible bad code with -O2

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #11 from David Binderman  ---
(In reply to Martin Liška from comment #10)
> However, I see a segfault that happens for the code snippet now.

In the compiler or the generated code ?

No crashes here. Are you running an asan+ubsan gcc build on x86_64, perhaps ?

[Bug c/108718] [10/11/12/13 Regression] csmith: possible bad code with -O2

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #9 from David Binderman  ---
Created attachment 54463
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54463=edit
C source code

After a further hour of reduction, a partially reduced program.

cvise doesn't seem able to make much further progress with it.

[Bug c/108718] [10/11/12/13 Regression] csmith: possible bad code with -O2

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #8 from David Binderman  ---
(In reply to David Binderman from comment #7)
> After about 20 minutes of reduction, cvise started going the wrong way.

Second reduction now running, with better script:

/usr/bin/gcc -c -w bug883.c && \
/home/dcb36/gcc/results/bin/gcc -w -O1 bug883.c && (./a.out 1 | fgrep
"g_5[i][j].f4 : C953D56F") && /home/dcb36/gcc/results/bin/gcc -w -O2 bug883.c
&& (./a.out 1 | fgrep "g_5[i][j].f4 : 367D9AB8")

[Bug middle-end/108657] [13 Regression] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #14 from David Binderman  ---
After five hours of reduction, cvise has:

crc32_tab[256];
unsigned crc32_context = 4294967295;
void crc32_byte(b) {
  crc32_context = crc32_context >> 8 ^ crc32_tab[(crc32_context ^ b) & 255];
}
void transparent_crc(long val, char *vname) {
  crc32_context = crc32_context >> 8 ^ crc32_tab[(crc32_context ^ val) & 255];
  crc32_byte(val >> 8);
  crc32_byte(val >> 16);
  crc32_byte(val >> 24);
  crc32_byte(val >> 32);
  crc32_byte(val >> 40);
  crc32_byte(val >> 48);
  crc32_byte(val >> 56);
  printf("...checksum after hashing %s : %lX\n", vname,
 crc32_context ^ 4294967295);
}
g_21 = -8;
short g_41;
g_78;
static *g_451 = _78;
g_452;
func_11___trans_tmp_13;
main_i;
unsigned main_crc;
main_j;
void main() {
  for (; main_i < 256; main_i++) {
main_crc = main_i;
main_j = 8;
for (; main_j; main_j--)
  if (main_crc & 1)
main_crc = main_crc >> 1 ^ 3988292384;
  else
main_crc >>= 1;
crc32_tab[main_i] = main_crc;
  }
  int l_794;
  g_41 = 53935 & g_21;
  g_21 = -18;
  g_78 = 1;
  for (; g_78 >= 0; g_78 -= 1) {
g_452 = l_794 = 0;
for (; l_794 <= 3; l_794 += 1) {
  short l_895[1];
  if (g_452)
break;
  g_452 ^= func_11___trans_tmp_13;
}
  }
  *g_451 = 8 || 0;
  transparent_crc(g_21, "");
  transparent_crc(g_41, "");
  transparent_crc(2185655400, "");
  transparent_crc(g_78, "g_78");
}

[Bug middle-end/108657] [13 Regression] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #13 from David Binderman  ---
I tried adding flag 1 to the run of the two binaries. Here is 
the bash history:

 1003  gcc bug880.c
 1004  ./a.out > /tmp/0
 1005  ~/gcc/results/bin/gcc -w -O3 -ftrivial-auto-var-init=zero bug880.c -o
b.out
 1006  ./b.out > /tmp/1
 1007  diff /tmp/0 /tmp/1
 1008  ./a.out 1 > /tmp/0
 1009  ./b.out 1 > /tmp/1
 1010  diff /tmp/0 /tmp/1

and got this:

4,12c4,12
< ...checksum after hashing g_78 : 42AE7A83
< ...checksum after hashing g_86 : EA4E5BB
< ...checksum after hashing g_87 : 829B71B1
< ...checksum after hashing g_93 : 454CD723
< ...checksum after hashing g_105 : 589C9AA7
< ...checksum after hashing g_111 : D1C885DD
< ...checksum after hashing g_132 : A790B35F
< ...checksum after hashing g_133 : A9573918
< ...checksum after hashing g_134[i] : 9B3BD0DE
---
> ...checksum after hashing g_78 : 8E047A1D
> ...checksum after hashing g_86 : A0CC742A
> ...checksum after hashing g_87 : 3BE1496
> ...checksum after hashing g_93 : B496D289
> ...checksum after hashing g_105 : F7D808E0
> ...checksum after hashing g_111 : EC796901
> ...checksum after hashing g_132 : BA05A088
> ...checksum after hashing g_133 : 2662148D
> ...checksum after hashing g_134[i] : 3530834A

So someplace in g_78 looks to be the culprit.

[Bug c/108718] [10/11/12/13 Regression] csmith: possible bad code with -O2

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #7 from David Binderman  ---
Created attachment 54449
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54449=edit
C source code

After about 20 minutes of reduction, cvise started going the wrong way.

[Bug c/108718] [10/11/12/13 Regression] csmith: possible bad code with -O2

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #4 from David Binderman  ---
(In reply to Andrew Pinski from comment #3)
> This also changes with  -fno-strict-aliasing  ...

So does that mean that csmith is producing C code with UB and so
this bug isn't valid ?

It might also mean that all future uses of csmith I make must have
-fno-strict-aliasing.

[Bug c/108721] New: csmith: really old bug with -O2

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 108721
   Summary: csmith: really old bug with -O2
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

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

For the attached C code, generated from csmith, does this:

$ ../results/bin/gcc -w -O1 bug884.c && ./a.out
checksum = 749D4681
$ ../results/bin/gcc -w -O2 bug884.c && ./a.out
checksum = F8019D24
$ 

The bug seems to exist since sometime before 20220206, about a year ago.

$ ../results.20220206/bin/gcc -w -O2 bug884.c && ./a.out
checksum = F8019D24
$ 

The git hash for 20220206 is g:8eb329e963593342855b6072e5692659107337b7

[Bug c/108718] New: csmith: possible bad code with -O2

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 108718
   Summary: csmith: possible bad code with -O2
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

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

The attached C code, produced by csmith, does this:

$ ../results/bin/gcc -w -O1 bug883.c && ./a.out
checksum = 7A94E377
$ ../results/bin/gcc -w -O2 bug883.c && ./a.out
checksum = 842F1622
$ 

The bug seems to exist since sometime before 20220703

$ ../results.20220703/bin/gcc -w -O2 bug883.c && ./a.out
checksum = 842F1622
$ 

I will have a go at a reduction.

[Bug middle-end/108657] [13 Regression] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||rguenther at suse dot de

--- Comment #12 from David Binderman  ---
Perhaps Richard would be willing to offer their best advice.

[Bug c/108688] New: error: ‘bit_field_ref’ of non-mode-precision operand

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 108688
   Summary: error: ‘bit_field_ref’ of non-mode-precision operand
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For this C code:

union {
  signed f1 : 7;
  signed f2 : 2
} func_6_l_2225;
g_139, g_417, func_6___trans_tmp_7;
main() {
  for (; g_417; g_417 -= 1) {
func_6_l_2225.f1 = g_139;
func_6_l_2225.f2 ^= func_6___trans_tmp_7;
  }
}

Compiled by recent gcc, does this:

$ ~/gcc/results/bin/gcc -c -O2 -w bug882.c
bug882.c: In function ‘main’:
bug882.c:6:1: error: ‘bit_field_ref’ of non-mode-precision operand
6 | main() {
  | ^~~~
_ifc__31 = BIT_FIELD_REF <_2, 2, 0>;
during GIMPLE pass: ifcvt
bug882.c:6:1: internal compiler error: verify_gimple failed

$ ~/gcc/results/bin/gcc -v 2>&1 | fgrep exp
gcc version 13.0.1 20230206 (experimental) (45e01229af33a3dc) 
$

The bug first seems to occur sometime between date 20221002
and 20221028.

[Bug middle-end/108657] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #10 from David Binderman  ---
Bingo ! 

>From snapshot 20220703, with g:f3a5e75cb66dc96e, to 20220807, with
g:ef54eb74cab17737, it goes wrong.

Perhaps someone who has the git history would like to bisect this.

[Bug middle-end/108657] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #9 from David Binderman  ---
Same thing, back to 20220807.

[Bug middle-end/108657] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #8 from David Binderman  ---
(In reply to David Binderman from comment #7)
> I will have a look at how to get at dates before the clone date.

I used snapshots instead. I tried 20221002, and got

$ ./results.20221002/bin/gcc -w -O3 -ftrivial-auto-var-init=zero 
~/gcc/foundBugs/bug880.c && ./a.out
checksum = BCC02729
$ ./results.20221002/bin/gcc -v 2>&1 | fgrep exp
gcc version 13.0.0 20221002 (experimental) (GCC) 
$

[Bug c/108679] New: ice in modify_call, at ipa-param-manipulation.cc:656

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 108679
   Summary: ice in modify_call, at ipa-param-manipulation.cc:656
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For this C code:

struct S1 {
  signed f0;
};
struct S2 {
  struct S1 f2;
  short f8;
} g_18;
g_732, func_6_l_17;
static *func_12();
static func_6(struct S2 p_7) { func_12(func_6_l_17, p_7.f2, g_18, 0); }
*func_12(int, struct S1 p_14) {
  safe_lshift_func_int16_t_s_u();
  safe_unary_minus_func_uint64_t_u();
  g_732 = safe_mul_func_uint8_t_u_u(0, p_14);
}
main() {
  struct S2 l_10 = {3};
  func_6(l_10);
}

compiled by recent gcc, does this:

$ /home/dcb36/gcc/results/bin/gcc -w -O2 -ftrivial-auto-var-init=zero bug881.c 
during IPA pass: inline
bug881.c: In function ‘main’:
bug881.c:18:3: internal compiler error: in modify_call, at
ipa-param-manipulation.cc:656
   18 |   func_6(l_10);
  |   ^~~~
0xb64d40 ipa_param_adjustments::modify_call(cgraph_edge*, bool)
../../trunk.d1/gcc/ipa-param-manipulation.cc:656

The bug first seems to occur sometime between g:d0a3d55ae4a2656f
and g:1530a9b1f45a7ceb

[Bug middle-end/108657] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #7 from David Binderman  ---
I can only go back as far as 20221028, when the git tree was installed.

$ /home/dcb36/gcc/results.20221028/bin/gcc -w -O3 -ftrivial-auto-var-init=zero
bug880.c
$ ./a.out
checksum = BCC02729
$ /home/dcb36/gcc/results.20221028/bin/gcc -v 2>&1 | fgrep exp
gcc version 13.0.0 20221028 (experimental) (8f2358724fa4) 
$ 

I will have a look at how to get at dates before the clone date.

[Bug middle-end/108657] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #6 from David Binderman  ---
(In reply to David Binderman from comment #5)
> (In reply to David Binderman from comment #0)
> > Also, the possible bug seems to have first occurred sometime before 20230103
> 
> Also before 20221201:

And before 20221101:

$ /home/dcb36/gcc/results.20221101/bin/gcc -w -O3 -ftrivial-auto-var-init=zero
bug880.c
$ ./a.out
checksum = BCC02729
$ /home/dcb36/gcc/results.20221101/bin/gcc -v 2>&1 | fgrep exp
gcc version 13.0.0 20221101 (experimental) (4acc4c2be84d6607) 
$

[Bug middle-end/108657] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #5 from David Binderman  ---
(In reply to David Binderman from comment #0)
> Also, the possible bug seems to have first occurred sometime before 20230103

Also before 20221201:

$ /home/dcb36/gcc/results.20221201/bin/gcc -w -O3 -ftrivial-auto-var-init=zero
bug880.c
$ ./a.out
checksum = BCC02729
$ /home/dcb36/gcc/results.20221201/bin/gcc -v 2>&1 | fgrep exp
gcc version 13.0.0 20221130 (experimental) (d0a3d55ae4a2656f) 
$

[Bug middle-end/108657] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #3 from David Binderman  ---
(In reply to Andrew Pinski from comment #2)
> If I initialize __trans_tmp_13 explictly to 0, the issue goes away 

$ fgrep trans_tmp_13 bug880.c
   int64_t __trans_tmp_13;
   (g_452) ^= (__trans_tmp_13);
$ 

This now looks like a bug in csmith.

[Bug c/108657] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from David Binderman  ---
Created attachment 54403
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54403=edit
C source code

After 90 minutes reduction, about 12% of the original is left.

[Bug c/108657] New: csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 108657
   Summary: csmith: possible wrong checksum with -O3 and
-ftrivial-auto-var-init=zero
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

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

For the attached C code, derived from csmith output, I get:

$ ~/gcc/results/bin/gcc -w bug880.c
$ ./a.out
checksum = F3A34B53
$ ~/gcc/results/bin/gcc -w -O2 bug880.c
$ ./a.out
checksum = F3A34B53
$ ~/gcc/results/bin/gcc -w -O2 -ftrivial-auto-var-init=zero bug880.c
$ ./a.out
checksum = F3A34B53
$ ~/gcc/results/bin/gcc -w -O3 -ftrivial-auto-var-init=zero bug880.c
$ ./a.out
checksum = BCC02729
$ ~/gcc/results/bin/gcc -w -O3  bug880.c
$ ./a.out
checksum = F3A34B53
$ 

Also, the possible bug seems to have first occurred sometime before 20230103

$ ~/gcc/results.20230103.asan.ubsan/bin/gcc -w -O3 -ftrivial-auto-var-init=zero
bug880.c
$ ./a.out
checksum = BCC02729
$

[Bug c/108638] New: Another ice in decompose, at wide-int.h:984

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 108638
   Summary: Another ice in decompose, at wide-int.h:984
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For this C code:

long orte_pre_condition_transports_print_j;
int orte_pre_condition_transports_print_int_ptr_0;
orte_pre_condition_transports_print() {
  for (;;)
if (orte_pre_condition_transports_print_int_ptr_0)
  for (; orte_pre_condition_transports_print_j < sizeof(int);)
orte_pre_condition_transports_print_int_ptr_0 |=
orte_pre_condition_transports_print_j
<< orte_pre_condition_transports_print_j;
}

compiled by recent gcc, does this:

$ /home/dcb36/gcc/results/bin/gcc -c -w -O1 bug879.c 2>&1 | fgrep "internal c"
bug879.c:3:1: internal compiler error: in decompose, at wide-int.h:984
$ 

This was ok at g:da3aca031be736fe, dated 20230129, but not ok at
g:77906341efc5cb69, dated  20230131.

[Bug rtl-optimization/108596] [10/11/12 Regression] error: EDGE_CROSSING missing across section boundary

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #7 from David Binderman  ---
(In reply to Jakub Jelinek from comment #6)
> Fixed on the trunk so far.

linux-6.2-rc6 builds fine, when built with -O3.

Thanks for the quick fix.

[Bug c/108596] New: error: EDGE_CROSSING missing across section boundary

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 108596
   Summary: error: EDGE_CROSSING missing across section boundary
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For this C code, derived from yesterday's linux-6.2-rc6:

enum { false, true };
__attribute__((__cold__)) _printk();
_static_cpu_has() {
  asm goto("" : : : : t_yes, t_no);
t_yes:
  return true;
t_no:
  return false;
}
acpi_sleep_prepare() {
  _Bool __trans_tmp_1 = _static_cpu_has();
  if (!__trans_tmp_1)
acpi_set_waking_vector();
  _printk();
}

does this:

$ /home/dcb36/gcc/results/bin/gcc -c -w -std=gnu11   -O2 bug878.c 
bug878.c: In function ‘acpi_sleep_prepare’:
bug878.c:15:1: error: EDGE_CROSSING missing across section boundary
   15 | }
  | ^
during RTL pass: bbpart
bug878.c:15:1: internal compiler error: verify_flow_info failed
0x8818f1 verify_flow_info()
../../trunk.d1/gcc/cfghooks.cc:285

$ /home/dcb36/gcc/results/bin/gcc -c -w -std=gnu11   -O1 bug878.c 
$

The bug first seems to occur sometime before g:9b111debbfb79a0a,
dated 20221229.

[Bug c++/88853] ICE: verify_type failed (error: type variant differs by TYPE_PACKED) with -fpack-struct -g

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #4 from David Binderman  ---
I get something similar for this C code:

enum fmt_type parse_num_range(const enum fmt_type);
enum __attribute__((packed)) fmt_type {
  FMT_NUMBER_OF_FORMATS
} parse_number(const enum fmt_type) {}

$ /usr/bin/gcc -c -g bug877.c
$ ~/gcc/results/bin/gcc -c -g bug877.c
bug877.c: In function ‘parse_number’:
bug877.c:4:27: error: type variant differs by TYPE_PACKED
4 | } parse_number(const enum fmt_type) {}
  |   ^~~~
 

This error seems like a regression in gcc-13. 

The bug first appears sometime before 9b111debbfb79a0a.

[Bug c/102760] ICE: in decompose, at wide-int.h:984

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #8 from David Binderman  ---
(In reply to Andrew Pinski from comment #7)
> (In reply to David Binderman from comment #6)
> > I see very similar for this legal C code:
> 
> That seems like a different issue, please file it seperately.

Done, see 108547.

[Bug c/108547] New: ice in decompose, at wide-int.h:984 for -O2 with -Wall

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 108547
   Summary: ice in decompose, at wide-int.h:984 for -O2 with -Wall
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

This legal C source code:

int li_4, li_5, us_8;
unsigned char func_7_ptr_13, func_7_uc_14;
void func_7_ptr_18() {
  if (li_5) {
for (;;)
  ;
short s_15;
for (; func_7_uc_14;) {
  us_8 = 7;
  for (; us_8; us_8 += 1)
  lblD2AF1FAB:
if (us_8)
  li_4 = 1;
  func_7_uc_14 += func_7_ptr_18;
  if (func_7_ptr_13 & 1 && (func_7_uc_14 &= func_7_ptr_13))
s_15 %= func_7_uc_10li_19(s_15);
}
  }
  goto lblD2AF1FAB;
}

when compiled with recent gcc trunk, does this:

$ ~/gcc/results//bin/gcc -c -O2 -Wall bug876.c 
bug876.c: In function ‘func_7_ptr_18’:
bug876.c:14:20: warning: assignment to ‘unsigned char’ from ‘void (*)()’ makes
integer from pointer without a cast [-Wint-conversion]
   14 |   func_7_uc_14 += func_7_ptr_18;
  |^~
bug876.c:16:17: warning: implicit declaration of function ‘func_7_uc_10li_19’
[-Wimplicit-function-declaration]
   16 | s_15 %= func_7_uc_10li_19(s_15);
  | ^
during GIMPLE pass: uninit
bug876.c:3:6: internal compiler error: in decompose, at wide-int.h:984
3 | void func_7_ptr_18() {
  |  ^
0x1df0eb9 value_sat_pred_p(tree_node*, tree_node*, tree_code, bool)
../../trunk.d1/gcc/wide-int.h:0

The bug first seems to appear sometime before git hash g:9b111debbfb79a0a
dated 20221229.

[Bug c/102760] ICE: in decompose, at wide-int.h:984

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #6 from David Binderman  ---
I see very similar for this legal C code:

int li_4, li_5, us_8;
unsigned char func_7_ptr_13, func_7_uc_14;
void func_7_ptr_18() {
  if (li_5) {
for (;;)
  ;
short s_15;
for (; func_7_uc_14;) {
  us_8 = 7;
  for (; us_8; us_8 += 1)
  lblD2AF1FAB:
if (us_8)
  li_4 = 1;
  func_7_uc_14 += func_7_ptr_18;
  if (func_7_ptr_13 & 1 && (func_7_uc_14 &= func_7_ptr_13))
s_15 %= func_7_uc_10li_19(s_15);
}
  }
  goto lblD2AF1FAB;
}

when compiled as follows:

$ ~/gcc/results//bin/gcc -c -O2 -Wall bug876.c 
bug876.c: In function ‘func_7_ptr_18’:
bug876.c:14:20: warning: assignment to ‘unsigned char’ from ‘void (*)()’ makes
integer from pointer without a cast [-Wint-conversion]
   14 |   func_7_uc_14 += func_7_ptr_18;
  |^~
bug876.c:16:17: warning: implicit declaration of function ‘func_7_uc_10li_19’
[-Wimplicit-function-declaration]
   16 | s_15 %= func_7_uc_10li_19(s_15);
  | ^
during GIMPLE pass: uninit
bug876.c:3:6: internal compiler error: in decompose, at wide-int.h:984
3 | void func_7_ptr_18() {

[Bug tree-optimization/108523] [13 Regression] -O1 -fcode-hoisting causes long compilation time ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #16 from David Binderman  ---
cvise produces:

int g_149, g_167, g_481;
main() {
  int *l_1478 = _149;
  *l_1478 ^= g_167;
lbl_1481:
  for (;;) {
g_481 = 1;
for (; g_481; g_481 += 1) {
  g_167 ^= *l_1478;
  if (g_149)
goto lbl_1481;
}
  }
}

[Bug tree-optimization/108523] [13 Regression] -O1 -fcode-hoisting causes long compilation time ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #15 from David Binderman  ---
(In reply to Richard Biener from comment #14)
> Fixed, but I'll see if somebody comes up with a reduced testcase.

I have a reduction running with cvise.

[Bug tree-optimization/108523] -O1 -fcode-hoisting causes long compilation time ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||rguenther at suse dot de

--- Comment #8 from David Binderman  ---
Commit g:fd8dd6c0384969170e594be34da278a072d5eb76 dated 2022-11-29
looks to be the one that causes the bug.

fd8dd6c0384969170e594be34da278a072d5eb76 is the first bad commit
commit fd8dd6c0384969170e594be34da278a072d5eb76
Author: Richard Biener 
Date:   Tue Nov 29 12:56:22 2022 +0100


Over to Richard for their best advice.

[Bug tree-optimization/108523] -O1 -fcode-hoisting causes long compilation time ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #7 from David Binderman  ---
Git range now seems to be g:4d08c674b0114622 .. g:36cabc257dfb7dd4
which is 8 commits.

[Bug tree-optimization/108523] -O1 -fcode-hoisting causes long compilation time ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #6 from David Binderman  ---
Git range now seems to be g:4d08c674b0114622 .. g:b2aa75ded65f8c02
which is a range of 33 commits.

[Bug tree-optimization/108523] -O1 -fcode-hoisting causes long compilation time ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #5 from David Binderman  ---
Current range seems to be g:4d08c674b0114622 .. g:400d9fc1f0433611
which is 133 commits.

[Bug tree-optimization/108523] -O1 -fcode-hoisting causes long compilation time ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #4 from David Binderman  ---
Seems to run fine in about 0.1 seconds with g:4d08c674b0114622,
dated 20221129.

That seems to be about 533 commits.

I'll have a go at a git bisect.

[Bug tree-optimization/108523] -O1 -fcode-hoisting causes long compilation time ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #3 from David Binderman  ---
Problem seems to start sometime before git hash g:9b111debbfb79a0a,
dated 20221229.

I'll try a build of a month earlier.

[Bug tree-optimization/108523] -O1 -fcode-hoisting causes long compilation time ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #2 from David Binderman  ---
Doesn't complete in 1200 seconds.

[Bug tree-optimization/108523] -O1 -fcode-hoisting causes long compilation time ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from David Binderman  ---
Also won't run to completion with a ulimit of 750 seconds. 

Trying 1200 seconds.

[Bug c/108523] New: -O1 -fcode-hoisting causes long compilation time ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 108523
   Summary: -O1 -fcode-hoisting causes long compilation time  ?
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

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

The attached C code takes about 0.1 seconds to compile normally:

$ (ulimit -t 300; time ../results.20230124.release/bin/gcc -c -w -O1   
-fno-var-tracking bug875.c)

real0m0.133s
user0m0.095s
sys 0m0.013s

Add in -fcode-hoisting and it seems to take a lot longer:

$ (ulimit -t 300; time ../results.20230124.release/bin/gcc -c -w -O1 
-fcode-hoisting  -fno-var-tracking bug875.c)
gcc: fatal error: Killed signal terminated program cc1
compilation terminated.

real5m3.155s
user4m59.955s
sys 0m0.017s

$ ../results.20230124.release/bin/gcc -v
Using built-in specs.
COLLECT_GCC=../results.20230124.release/bin/gcc
COLLECT_LTO_WRAPPER=/home/dcb36/gcc/results.20230124.release/libexec/gcc/x86_64-pc-linux-gnu/13.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../trunk.d1/configure
--prefix=/home/dcb36/gcc/results.20230124.release --disable-multilib
--disable-bootstrap --with-pkgversion=e304e9283a97e28d
--enable-checking=release --enable-languages=c
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.1 20230124 (experimental) (e304e9283a97e28d)

[Bug tree-optimization/108482] [13 Regression] ice in expand_LOOP_DIST_ALIAS with -O3 -ftrivial-auto-var-init=zero

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #11 from David Binderman  ---
It looks to me like g:af96500eea72c674a5686b35c66202ef2bd9688f
is the culprit.

Over to Richard for their best advice.

[Bug tree-optimization/108482] [13 Regression] ice in expand_LOOP_DIST_ALIAS with -O3 -ftrivial-auto-var-init=zero

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||rguenther at suse dot de

--- Comment #10 from David Binderman  ---
(In reply to David Binderman from comment #9)
> (In reply to David Binderman from comment #8)
> > Current range is about 151 revisions.
> 
> After a few more rounds, current range seems to be g:fbad7a74aaaddea3
> to g:c16c40808331a029, some 10 commits.

Both remaining revisions are by Richard, so adding them in.

[Bug tree-optimization/108482] [13 Regression] ice in expand_LOOP_DIST_ALIAS with -O3 -ftrivial-auto-var-init=zero

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #9 from David Binderman  ---
(In reply to David Binderman from comment #8)
> Current range is about 151 revisions.

After a few more rounds, current range seems to be g:fbad7a74aaaddea3
to g:c16c40808331a029, some 10 commits.

[Bug tree-optimization/108482] [13 Regression] ice in expand_LOOP_DIST_ALIAS with -O3 -ftrivial-auto-var-init=zero

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #8 from David Binderman  ---
(In reply to David Binderman from comment #7)
> (In reply to David Binderman from comment #6)
> > (In reply to David Binderman from comment #5)
> > > (In reply to David Binderman from comment #0)
> > > > The bug seems to exist since sometime before g:02c031088ac0bbf7, dated 
> > > > 20221220.
> > > 
> > > I tried out a revision from a month earlier, dated 2022-11-20,
> > > g:59cc4da605e5cb8e, and the bug seems to exist there too.
> > > 
> > > I will try g:8f2358724fa4
> > 
> > That worked, so the current range is 
> > [g:8f2358724fa4,g:59cc4da605e5cb8e].
> > 
> > I will try a git bisect.
> 
> Git hash g:e7c8f5005bf87e4b seemed good, so I am trying g:3e070cff11f81051.

That seems bad, so trying g:51a233b97cc9c51e.

Current range is about 151 revisions.

[Bug tree-optimization/108482] [13 Regression] ice in expand_LOOP_DIST_ALIAS with -O3 -ftrivial-auto-var-init=zero

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #7 from David Binderman  ---
(In reply to David Binderman from comment #6)
> (In reply to David Binderman from comment #5)
> > (In reply to David Binderman from comment #0)
> > > The bug seems to exist since sometime before g:02c031088ac0bbf7, dated 
> > > 20221220.
> > 
> > I tried out a revision from a month earlier, dated 2022-11-20,
> > g:59cc4da605e5cb8e, and the bug seems to exist there too.
> > 
> > I will try g:8f2358724fa4
> 
> That worked, so the current range is [g:8f2358724fa4,g:59cc4da605e5cb8e].
> 
> I will try a git bisect.

Git hash g:e7c8f5005bf87e4b seemed good, so I am trying g:3e070cff11f81051.

[Bug tree-optimization/108482] [13 Regression] ice in expand_LOOP_DIST_ALIAS with -O3 -ftrivial-auto-var-init=zero

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #6 from David Binderman  ---
(In reply to David Binderman from comment #5)
> (In reply to David Binderman from comment #0)
> > The bug seems to exist since sometime before g:02c031088ac0bbf7, dated 
> > 20221220.
> 
> I tried out a revision from a month earlier, dated 2022-11-20,
> g:59cc4da605e5cb8e, and the bug seems to exist there too.
> 
> I will try g:8f2358724fa4

That worked, so the current range is [g:8f2358724fa4,g:59cc4da605e5cb8e].

I will try a git bisect.

[Bug tree-optimization/108482] [13 Regression] ice in expand_LOOP_DIST_ALIAS with -O3 -ftrivial-auto-var-init=zero

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #5 from David Binderman  ---
(In reply to David Binderman from comment #0)
> The bug seems to exist since sometime before g:02c031088ac0bbf7, dated 
> 20221220.

I tried out a revision from a month earlier, dated 2022-11-20,
g:59cc4da605e5cb8e, and the bug seems to exist there too.

I will try 8f2358.

[Bug c/108482] ice in expand_LOOP_DIST_ALIAS, at internal-fn.cc:2737

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from David Binderman  ---
Reduced code seems to be:

int g_30, g_261, g_263, func_1___trans_tmp_17;
int **g_120;
int *g_530;
void func_1() {
  int *l_29 = _30;
  *l_29 = 1;
  g_263 = 0;
  for (; g_263 <= 1; g_263 += 1) {
g_530 = 0;
if (*l_29) {
  char *l_1694 = _261;
  *l_1694 &= **g_120;
} else
  *l_29 ^= func_1___trans_tmp_17;
  }
}

This case came from about 20,000 executions of csmith.

[Bug c/108482] New: ice in expand_LOOP_DIST_ALIAS, at internal-fn.cc:2737

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 108482
   Summary: ice in expand_LOOP_DIST_ALIAS, at internal-fn.cc:2737
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

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

For the attached C code, compiled as follows:

$ /home/dcb36/gcc/results/bin/gcc  -c -O3 -w -ftrivial-auto-var-init=zero 
bug874.c
during RTL pass: expand
testFile.21840.c: In function ‘func_1.isra’:
testFile.21840.c:112:16: internal compiler error: in expand_LOOP_DIST_ALIAS, at
internal-fn.cc:2737
0xb17ff4 expand_LOOP_DIST_ALIAS(internal_fn, gcall*)
../../trunk.d1/gcc/internal-fn.cc:2737
0x86d30e expand_call_stmt(gcall*)
../../trunk.d1/gcc/cfgexpand.cc:2737
0x86d30e expand_gimple_stmt_1(gimple*)
../../trunk.d1/gcc/cfgexpand.cc:3880
0x86d30e expand_gimple_stmt(gimple*)
../../trunk.d1/gcc/cfgexpand.cc:4044

The bug seems to exist since sometime before g:02c031088ac0bbf7,
dated 20221220.

I have a reduction running.

[Bug c++/86426] g++ ICE at on valid code in tree_operand_check, at tree.h:3615

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #11 from David Binderman  ---
Probably still broken. One for Jason ?

[Bug ipa/108384] error: conversion of register to a different size in ‘view_convert_expr’

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #8 from David Binderman  ---
(In reply to David Binderman from comment #4)
> I suspect a grep pattern could help guide the reduction.
> I tried a few patterns, but didn't make any real progress.

Using this pattern:

$ grep "func_23[^,]*,[^)]*)" bug873.c

I got the following reduced code:

struct S0 {
  int f0;
  short f1;
  unsigned f2 : 7;
  short f3
} func_2_l_27;
g_389;
func_23(struct S0 p_24, struct S0 p_25) {
  int *l_1051 = g_389;
  if (safe_sub_func_int16_t_s_s())
for (;;)
  safe_lshift_func_uint8_t_u_s(p_24.f1);
  *l_1051 = p_25.f0;
}
func_2() {
  struct S0 l_26[] = {4, 5, 4, 6, 4, 5, 4, 6};
  func_23(l_26[1], func_2_l_27);
}

$ fgrep func_23 bug873.c
func_23(struct S0 p_24, struct S0 p_25) {
  func_23(l_26[1], func_2_l_27);
$

[Bug ipa/108384] error: conversion of register to a different size in ‘view_convert_expr’

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||mjambor at suse dot cz

--- Comment #7 from David Binderman  ---
(In reply to David Binderman from comment #6)
> (In reply to David Binderman from comment #5)
> > (In reply to David Binderman from comment #4)
> > > Meanwhile, I try a bisection. Trying git hash g:0333892db367b2b9
> > 
> > Seems good. Trying g:d3328df5f5c9908c
> 
> Seems good. Trying g:5b918b20d18b9cce

It appears to me that Martin Jambor's revision g:c389991432da2bcc
is the one at fault.

Adding Martin for their best opinion.

[Bug ipa/108384] error: conversion of register to a different size in ‘view_convert_expr’

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #6 from David Binderman  ---
(In reply to David Binderman from comment #5)
> (In reply to David Binderman from comment #4)
> > Meanwhile, I try a bisection. Trying git hash g:0333892db367b2b9
> 
> Seems good. Trying g:d3328df5f5c9908c

Seems good. Trying g:5b918b20d18b9cce

[Bug ipa/108384] error: conversion of register to a different size in ‘view_convert_expr’

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #5 from David Binderman  ---
(In reply to David Binderman from comment #4)
> Meanwhile, I try a bisection. Trying git hash g:0333892db367b2b9

Seems good. Trying g:d3328df5f5c9908c

[Bug ipa/108384] error: conversion of register to a different size in ‘view_convert_expr’

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #4 from David Binderman  ---
(In reply to David Binderman from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > The code is undefined ...
> > 
> >   func_23(l_26[1]);
> > 
> > func_23(struct S0 p_24, struct S0 p_25)
> 
> Interesting. It looks like the reduction has not preserved the two
> parameters required of func_23.

I suspect a grep pattern could help guide the reduction.
I tried a few patterns, but didn't make any real progress.

Meanwhile, I try a bisection. Trying git hash g:0333892db367b2b9

[Bug ipa/108384] error: conversion of register to a different size in ‘view_convert_expr’

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #3 from David Binderman  ---
(In reply to Andrew Pinski from comment #2)
> The code is undefined ...
> 
>   func_23(l_26[1]);
> 
> func_23(struct S0 p_24, struct S0 p_25)

Interesting. It looks like the reduction has not preserved the two
parameters required of func_23.

>From the original csmith produced code:

$ fgrep func_23 bug873.c
static union U2 * func_23(struct S0 p_24, const struct S1 p_25);
if *l_9) &= 0x3631L) ,
(safe_div_func_int32_t_s_s((safe_sub_func_int8_t_s_ssafe_mod_func_uint32_t_u_u(((func_17(func_23(l_26[1],
l_27), l_9, ((*l_1367) = l_1366),
(safe_add_func_uint32_t_u_u(((safe_div_func_uint8_t_u_u(((safe_rshift_func_uint8_t_u_s((l_27.f0
> p_3), 1)) || (((safe_div_func_int64_t_s_s(p_3, p_3)) != 0x47247D4EED584808LL)
|| g_1119)), 0x21L)) > g_1165[0]), 0xB3A4A36DL)), l_27.f4.f0) <=
0x334C102EE31FC4EFLL) & p_3), g_7.f0)) & g_1165[0]) || l_1397), 0L)),
0x55B9621EL
static union U2 * func_23(struct S0 p_24, const struct S1 p_25)

Two parameters in the first declaration, two in the call and two in the
definition.

[Bug c/108384] error: conversion of register to a different size in ‘view_convert_expr’

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from David Binderman  ---
Reduced C code seems to be:

struct S0 {
  int f0;
  short f1;
  unsigned f2 : 7;
  short f3
};
g_389;
static *func_23();
func_2() {
  struct S0 l_26[] = {4, 5, 4, 6, 4, 5, 4, 6};
  func_23(l_26[1]);
}
*func_23(struct S0 p_24, struct S0 p_25) {
  int *l_1051 = g_389;
  if (safe_sub_func_int16_t_s_s())
safe_lshift_func_uint8_t_u_s(p_24.f1);
  *l_1051 = p_25.f0;
}

[Bug c/108384] New: error: conversion of register to a different size in ‘view_convert_expr’

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 108384
   Summary: error: conversion of register to a different size in
‘view_convert_expr’
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

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

The attached C code does this:

$ ~/gcc/results/bin/gcc -c -w -O3 -ftrivial-auto-var-init=zero bug873.c
testFile.4557.c: In function ‘func_1.isra’:
testFile.4557.c:130:16: error: conversion of register to a different size in
‘view_convert_expr’
VIEW_CONVERT_EXPR(removed_ipa_cp.834_390);

_393 = VIEW_CONVERT_EXPR(removed_ipa_cp.834_390);
during GIMPLE pass: fixup_cfg
testFile.4557.c:130:16: internal compiler error: verify_gimple failed
0xeaab49 verify_gimple_in_cfg(function*, bool, bool)
../../trunk.d1/gcc/tree-cfg.cc:5647
0xd46c5b execute_function_todo(function*, void*)
../../trunk.d1/gcc/passes.cc:2091

The bug first seems to occur sometime between git hash g:d901bf8a44a85e12
and g:b399afd22c6ea507.

A reduction is running now.

[Bug middle-end/108278] [13 Regression] runtime error with -O1 -Wall

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #16 from David Binderman  ---
(In reply to Richard Biener from comment #15)
> So this bug is fixed?

Jakub and I seem to think so. Good enough ?

[Bug middle-end/108278] [13 Regression] runtime error with -O1 -Wall

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #14 from David Binderman  ---
(In reply to Florian Weimer from comment #8)
> I believe the revert in 455acc43518744b89d6a795bbba5045bd228060b should have
> fixed this?

It looks to me like it does.

> I also brought up the initialization issue on the gcc list:
> 
> Default initialization of poly-ints
> 

This is the second time I have noticed this issue has occurred with a 
data type in gcc. It would be safer if there was a default initialisation
to zero for all gcc data types.

[Bug middle-end/108278] [13 Regression] runtime error with -O1 -Wall

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #13 from David Binderman  ---
(In reply to David Binderman from comment #12)
> Let's try that out:
> 
> g:d423e8dc59045d8f and g:fee53a3194c0d8b7

Seems to work. Good.

[Bug middle-end/108278] [13 Regression] runtime error with -O1 -Wall

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #12 from David Binderman  ---
(In reply to Jakub Jelinek from comment #10)
> BTW, please use g: prefix for git hashes or r13-4989-g345dffd0d4ebff7 or
> r13-4989 styles, anything else is quite useless as it doesn't create
> hyperlinks in bugzilla.

Let's try that out:

g:d423e8dc59045d8f and g:fee53a3194c0d8b7

I am a novice at git, so where does the 4989 in r13-4989-g* come from ?
The 4989 looks like a useful serial number to me.

[Bug middle-end/108278] [13 Regression] runtime error with -O1 -Wall

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #7 from David Binderman  ---
(In reply to David Binderman from comment #4)
> (In reply to David Binderman from comment #3)
> > Trying revision aeee4812442c996f in bisect.
> 
> That seems fine, so trying 3b6cac2b44b384cd.

That seems ok, so git range seems to be: 3b6cac2b44b384cd..fee53a3194c0d8b7

[Bug middle-end/108278] [13 Regression] runtime error with -O1 -Wall

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||fweimer at redhat dot com

--- Comment #6 from David Binderman  ---
The Author list for the revisions under test is:

Author: GCC Administrator 
Author: Alexander Monakov 
Author: Florian Weimer 
Author: Florian Weimer 
Author: Florian Weimer 
Author: Iain Sandoe 
Author: Jakub Jelinek 

Alex, Iain and Jakub make what look like unrelated changes, so adding
Florian for their opinion.

[Bug middle-end/108278] [13 Regression] runtime error with -O1 -Wall

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #5 from David Binderman  ---
Another runtime bug, probably related:

../../trunk.d1/gcc/expmed.cc:3282:26: runtime error: signed integer overflow:
-9223372036854775808 - 1 cannot be represented in type 'long int'

I am not sure if this one should be a separate bug report or not.

[Bug middle-end/108278] [13 Regression] runtime error with -O1 -Wall

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #4 from David Binderman  ---
(In reply to David Binderman from comment #3)
> Trying revision aeee4812442c996f in bisect.

That seems fine, so trying 3b6cac2b44b384cd.

[Bug middle-end/108278] [13 Regression] runtime error with -O1 -Wall

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #3 from David Binderman  ---
Trying revision aeee4812442c996f in bisect.

[Bug c++/108278] runtime error with -O1 -Wall

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from David Binderman  ---
Reduced C++ code is

typedef int mbstate_t;
namespace std {
struct Trans_NS___cxx11_basic_string {
  char *c_str();
};
template  _Facet use_facet(int);
template  struct __codecvt_abstract_base {
  typedef _ExternT extern_type;
  int length(int, extern_type *, const extern_type *, long);
};
template 
struct codecvt : __codecvt_abstract_base<_ExternT> {};
} // namespace std
template  struct intrusive_ptr {
  intrusive_ptr(T *);
  T *operator->();
};
long attach___trans_tmp_3;
struct basic_ostringstreambuf {
  struct {
std::Trans_NS___cxx11_basic_string storage;
long max_size;
  } m_storage_state;
  void attach() {
attach___trans_tmp_3 = 9223372036854775807 / 2;
long size = attach___trans_tmp_3;
m_storage_state.max_size = size;
length_until_boundary(m_storage_state.storage.c_str(),
  m_storage_state.max_size);
  }
  void length_until_boundary(char *s, long max_size) {
int loc;
std::codecvt fac =
std::use_facet>(loc);
mbstate_t mbs(fac.length(mbs, s, s + max_size, 0));
  }
};
struct Trans_NS_v2_mt_posix_basic_formatting_ostream {
  basic_ostringstreambuf m_streambuf;
  void attach(std::Trans_NS___cxx11_basic_string) { m_streambuf.attach(); }
};
template 
struct Trans_NS_v2_mt_posix_basic_record_ostream
: Trans_NS_v2_mt_posix_basic_formatting_ostream {
  typedef std::Trans_NS___cxx11_basic_string string_type;
  void init_stream();
};
struct attribute_value_impl {
  attribute_value_impl(std::Trans_NS___cxx11_basic_string);
  std::Trans_NS___cxx11_basic_string get();
};
template 
void Trans_NS_v2_mt_posix_basic_record_ostream::init_stream() {
  typedef attribute_value_impl message_impl_type;
  intrusive_ptr p = new message_impl_type(string_type());
  attach(p->get());
}
template class Trans_NS_v2_mt_posix_basic_record_ostream;

I will have a go at a git bisect in the morning.

[Bug c++/108278] New: runtime error with -O1 -Wall

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 108278
   Summary: runtime error with -O1 -Wall
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 54182
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54182=edit
gzipped C++ source code

The attached C++ code does this:

$ ../results/bin/g++ -c -O1 -Wall bug872.cc 
../../trunk.d1/gcc/poly-int.h:753:21: runtime error: signed integer overflow:
4611686018427387903 * 8 cannot be represented in type 'long int'
$ 

The bug first seems to occur sometime between git hash d423e8dc59045d8f,
from a couple of days ago and fee53a3194c0d8b7, from today, a distance
of 14 commits.

I have a reduction running.

[Bug modula2/108136] New: Modula2 meets cppcheck

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 108136
   Summary: Modula2 meets cppcheck
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

I ran the C/C++ static analyser cppcheck over the source code of the Modula2
compiler and library.

For errors, this one might be significant:

trunk.d1/gcc/m2/pge-boot/GRTco.c:113:1: error: Found an exit path from function
with non-void return type that has missing return statement [missingReturn]

For style:

trunk.d1/gcc/m2/mc-boot/GM2Dependent.c:453:15: style: Array index 'i' is used
before limits check. [arrayIndexThenCheck]
trunk.d1/gcc/m2/pge-boot/GM2Dependent.c:461:15: style: Array index 'i' is used
before limits check. [arrayIndexThenCheck]
trunk.d1/gcc/m2/mc-boot/GArgs.c:86:42: style: Array index 'j' is used before
limits check. [arrayIndexThenCheck]
trunk.d1/gcc/m2/pge-boot/GArgs.c:84:42: style: Array index 'j' is used before
limits check. [arrayIndexThenCheck]
trunk.d1/gcc/m2/mc-boot/Gkeyc.c:603:241: style: Same expression 'seenUIntMax'
found multiple times in chain of '||' operators. [duplicateExpression]
trunk.d1/gcc/m2/mc-boot/Gkeyc.c:603:128: style: Same expression 'seenUIntMin'
found multiple times in chain of '||' operators. [duplicateExpression]

for performance, relatively little:

trunk.d1/gcc/m2/mc-boot/Gdecl.c:14011:58: performance: Function parameter 's'
should be passed by const reference. [passedByValue]
trunk.d1/gcc/m2/mc-boot/Gdecl.c:16906:57: performance: Function parameter 's'
should be passed by const reference. [passedByValue]
trunk.d1/gcc/m2/mc-boot/Gdecl.c:16918:64: performance: Function parameter 's'
should be passed by const reference. [passedByValue]

[Bug modula2/108135] New: Modula2 meets clang

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 108135
   Summary: Modula2 meets clang
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

A build of gcc trunk with clang produces the following:

./../../../trunk.d1/libgm2/libm2min/../../gcc/m2/gm2-libs-min/libc.c:27:6:
warning: conflicting types for built-in function ‘abort’; expected ‘void(void)’
[-Wbuiltin-declaration-mismatch]
../../trunk.d1/gcc/m2/gm2-gcc/m2statement.cc:88:1: warning: function
'gm2_gimplify_function_node' is not needed and will not be emitted
[-Wunneeded-internal-declaration]
../../trunk.d1/gcc/m2/m2.flex:135:45: warning: misleading indentation;
statement is not part of the previous 'else' [-Wmisleading-indentation]
../../trunk.d1/gcc/m2/m2pp.cc:554:1: warning: function 'hextree' is not needed
and will not be emitted [-Wunneeded-internal-declaration]
../../trunk.d1/gcc/m2/mc-boot/GDynamicStrings.c:1877:44: warning:
self-comparison always evaluates to false [-Wtautological-compare]
../../trunk.d1/gcc/m2/mc-boot/GDynamicStrings.c:1882:44: warning:
self-comparison always evaluates to false [-Wtautological-compare]
../../trunk.d1/gcc/m2/pge-boot/GDynamicStrings.c:1880:44: warning:
self-comparison always evaluates to false [-Wtautological-compare]
../../trunk.d1/gcc/m2/pge-boot/GDynamicStrings.c:1885:44: warning:
self-comparison always evaluates to false [-Wtautological-compare]
m2/gm2-compiler-boot/M2GCCDeclare.c:5403:13: warning: function 'AddSymToWatch'
is not needed and will not be emitted [-Wunneeded-internal-declaration]
m2/gm2-compiler-boot/M2Quads.c:10267:16: warning: variable 'Dim' set but not
used [-Wunused-but-set-variable]
m2/gm2-compiler-boot/M2Quads.c:18370:54: warning: unused parameter 'withTok'
[-Wunused-parameter]
m2/gm2-libs-boot/DynamicStrings.c:1877:44: warning: self-comparison always
evaluates to false [-Wtautological-compare]
m2/gm2-libs-boot/DynamicStrings.c:1882:44: warning: self-comparison always
evaluates to false [-Wtautological-compare]

[Bug rust/108126] New: rust meets cppcheck

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 108126
   Summary: rust meets cppcheck
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rust
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
CC: dkm at gcc dot gnu.org, gcc-rust at gcc dot gnu.org
  Target Milestone: ---

I just ran the C/C++ static analyser over the new source code of rust.

First the errors:

trunk.d1/gcc/rust/ast/rust-cond-compilation.h:228:65: error: Member variable
'cfg_attrs' is initialized by itself. [selfInitialization]
trunk.d1/gcc/rust/typecheck/rust-tyty.h:1635:46: error: Reference to local
variable returned. [returnReference]
trunk.d1/gcc/rust/typecheck/rust-tyty.h:1636:58: error: Reference to local
variable returned. [returnReference]
trunk.d1/gcc/rust/typecheck/rust-tyty.h:558:58: error: Reference to local
variable returned. [returnReference]
trunk.d1/gcc/rust/util/rust-optional.h:157:12: error: Reference to local
variable returned. [returnReference]

Next, the warnings:

trunk.d1/gcc/rust/parse/rust-parse-impl.h:12423:21: warning: Access of moved
variable 'outer_attrs'. [accessMoved]
trunk.d1/gcc/rust/typecheck/rust-tyty-rules.h:394:7: warning: Class 'BaseRules'
does not have a copy constructor which is recommended since it has dynamic
memory/resource allocation(s). [noCopyConstructor]
trunk.d1/gcc/rust/typecheck/rust-tyty-rules.h:394:7: warning: Class 'BaseRules'
does not have a operator= which is recommended since it has dynamic
memory/resource allocation(s). [noOperatorEq]
trunk.d1/gcc/rust/typecheck/rust-substitution-mapper.h:146:7: warning: Class
'SubstMapper' does not have a copy constructor which is recommended since it
has dynamic memory/resource allocation(s). [noCopyConstructor]
trunk.d1/gcc/rust/typecheck/rust-substitution-mapper.h:146:7: warning: Class
'SubstMapper' does not have a operator= which is recommended since it has
dynamic memory/resource allocation(s). [noOperatorEq]
trunk.d1/gcc/rust/typecheck/rust-substitution-mapper.h:261:7: warning: Class
'SubstMapperInternal' does not have a copy constructor which is recommended
since it has dynamic memory/resource allocation(s). [noCopyConstructor]
trunk.d1/gcc/rust/typecheck/rust-substitution-mapper.h:261:7: warning: Class
'SubstMapperInternal' does not have a operator= which is recommended since it
has dynamic memory/resource allocation(s). [noOperatorEq]
trunk.d1/gcc/rust/typecheck/rust-tyty-call.h:75:7: warning: Class
'TypeCheckCallExpr' does not have a copy constructor which is recommended since
it has dynamic memory/resource allocation(s). [noCopyConstructor]
trunk.d1/gcc/rust/typecheck/rust-tyty-call.h:75:7: warning: Class
'TypeCheckCallExpr' does not have a operator= which is recommended since it has
dynamic memory/resource allocation(s). [noOperatorEq]
trunk.d1/gcc/rust/typecheck/rust-hir-type-check-struct.cc:29:5: warning: Class
'TypeCheckStructExpr' does not have a copy constructor which is recommended
since it has dynamic memory/resource allocation(s). [noCopyConstructor]
trunk.d1/gcc/rust/typecheck/rust-hir-type-check-struct.cc:29:5: warning: Class
'TypeCheckStructExpr' does not have a operator= which is recommended since it
has dynamic memory/resource allocation(s). [noOperatorEq]
trunk.d1/gcc/rust/typecheck/rust-tyty.h:664:9: warning: Either the condition
'argument!=nullptr' is redundant or there is possible null pointer dereference:
argument. [nullPointerRedundantCheck]
trunk.d1/gcc/rust/typecheck/rust-tyty.h:740:29: warning: Either the condition
'index>mappings.size()' is redundant or 'index' can have the value
mappings.size(). Expression 'mappings.at(index)' cause access out of bounds.
[containerOutOfBounds]
trunk.d1/gcc/rust/expand/rust-macro-substitute-ctx.cc:77:25: warning: Either
the condition 'it==fragments.end()' is redundant or there is possible
dereference of an invalid iterator: it. [derefInvalidIteratorRedundantCheck]
trunk.d1/gcc/rust/backend/rust-tree.cc:155:5: warning: Label 'CASE_CONVERT' is
not used. Should this be a 'case' of the enclosing switch()?
[unusedLabelSwitch]
trunk.d1/gcc/rust/backend/rust-tree.cc:45:5: warning: Label 'CASE_CONVERT' is
not used. Should this be a 'case' of the enclosing switch()?
[unusedLabelSwitch]
trunk.d1/gcc/rust/ast/rust-expr.h:1853:3: warning: Member variable
'CallExpr::fndeclRef' is not initialized in the constructor. [uninitMemberVar]
trunk.d1/gcc/rust/ast/rust-expr.h:1862:3: warning: Member variable
'CallExpr::fndeclRef' is not initialized in the copy constructor.
[uninitMemberVar]
trunk.d1/gcc/rust/util/rust-canonical-path.h:51:18: warning: Member variable
'CanonicalPath::crate_num' is not assigned a value in
'CanonicalPath::operator='. [operatorEqVarError]
trunk.d1/gcc/rust/util/rust-canonical-path.h:49:3: warning: Member variable
'CanonicalPath::crate_num' is not initialized in the copy constructor.

[Bug ipa/108110] [13 Regression] ice in modify_call, at ipa-param-manipulation.cc:700 with -std=c++14 -O3 -march=native

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #10 from David Binderman  ---
That's the bad revision.

  ipa: Better way of applying both IPA-CP and IPA-SRA (PR 103227)

[Bug ipa/108110] [13 Regression] ice in modify_call, at ipa-param-manipulation.cc:700 with -std=c++14 -O3 -march=native

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #9 from David Binderman  ---
(In reply to David Binderman from comment #8)
> 803a91330bf20174 seems bad, so trying 095a13eda2caf684.

That seems bad, so trying 4834e9360f7bf42f.

[Bug ipa/108110] [13 Regression] ice in modify_call, at ipa-param-manipulation.cc:700 with -std=c++14 -O3 -march=native

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #8 from David Binderman  ---
803a91330bf20174 seems bad, so trying 095a13eda2caf684.

[Bug ipa/108110] [13 Regression] ice in modify_call, at ipa-param-manipulation.cc:700 with -std=c++14 -O3 -march=native

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||mjambor at suse dot cz

--- Comment #7 from David Binderman  ---
That one seems bad. Trying 803a91330bf20174. Range seems
to be [7450b25566b7a738..512098a3316f07d4], so some 9 commits.

7 of them are by Martin Jambor , one is a daily bump
and one is unrelated.

Over to Martin.

[Bug ipa/108110] [13 Regression] ice in modify_call, at ipa-param-manipulation.cc:700 with -std=c++14 -O3 -march=native

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #6 from David Binderman  ---
(In reply to David Binderman from comment #5)
> That revision seems good. Trying 7450b25566b7a738.

Seems good. Trying 512098a3316f07d4.

[Bug ipa/108110] [13 Regression] ice in modify_call, at ipa-param-manipulation.cc:700 with -std=c++14 -O3 -march=native

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #5 from David Binderman  ---
That revision seems good. Trying 7450b25566b7a738.

For the reduced code, -march=zen3 not required.

[Bug ipa/108110] [13 Regression] ice in modify_call, at ipa-param-manipulation.cc:700 with -std=c++14 -O3 -march=native

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #4 from David Binderman  ---
Git bisect now running. Trying 15f04af347e3b65f.

[Bug ipa/108110] [13 Regression] ice in modify_call, at ipa-param-manipulation.cc:700 with -std=c++14 -O3 -march=native

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #3 from David Binderman  ---
Reduced C++ code seems to be:

namespace std {
template  struct integral_constant {
  static constexpr int value = __v;
};
using true_type = integral_constant;
using false_type = integral_constant;
template  struct __conditional {
  template  using type = _Tp;
};
template 
using __conditional_t = typename __conditional<_Cond>::type<_If, _Else>;
template  struct remove_cv { using type = _Tp; };
template  struct remove_reference { using type = _Tp; };
template 
struct __decay_selector
: __conditional_t, _Up> {};
template  struct decay {
  using type = typename __decay_selector<_Tp>::type;
};
template  using decay_t = typename decay<_Tp>::type;
template  using enable_if_t = _Tp;
template  _Tp &(typename remove_reference<_Tp>::type &);
long max(long __b) {
  if (__b)
return __b;
}
} // namespace std
enum layout_type { row_major };
template  struct svector {
  using size_type = long;
  using value_type = long;
  using const_reference = value_type;
  const_reference operator[](size_type) const;
  long *m_begin;
};
template 
auto svector::operator[](size_type idx) const -> const_reference {
  return m_begin[idx];
}
template  struct xcontainer_inner_types;
template  class xarray_container;
template 
using xarray = xarray_container;
template  struct xrange {
  using size_type = int;
  xrange(size_type, size_type) noexcept;
  size_type m_size;
};
template  struct xrange_adaptor {
  xrange_adaptor(int, int, int) : m_start() {}
  std::enable_if_t::value, xrange>
  get(long size) {
long __trans_tmp_8, __trans_tmp_7;
if (m_start)
  std::max(size);
if (m_stop)
  std::max(size);
return xrange(__trans_tmp_7, __trans_tmp_8);
  }
  int m_start;
  int m_stop;
};
template  auto range(A, B stop_val) {
  return xrange_adaptor(0, stop_val, int());
}
template  struct slice_implementation_getter {
  template  auto operator()(E e, SL slice, long index) {
return get_slice(e, slice, index, std::integral_constant<1>());
  }
  template 
  auto get_slice(E, SL slice, long, std::true_type) {
using int_type = std::decay_t;
return slice < int_type() ?: slice;
  }
};
template 
struct slice_implementation_getter> {
  template  auto operator()(E e, SL adaptor, long index) {
const svector __trans_tmp_6 = e.shape();
long __trans_tmp_2 = __trans_tmp_6[index];
return adaptor.get(__trans_tmp_2);
  }
};
long get_slice_implementation_index;
template  auto get_slice_implementation(E e, SL &) {
  slice_implementation_getter> getter;
  return getter(e, slice, get_slice_implementation_index);
}
template  xrange::xrange(size_type, size_type) noexcept {}
template  struct xcontainer {
  using derived_type = D;
  using inner_types = xcontainer_inner_types;
  using inner_shape_type = typename inner_types::inner_shape_type;
  constexpr const inner_shape_type () const noexcept;
  const derived_type _cast() const 
};
template  struct xstrided_container : xcontainer {
  using base_type = xcontainer;
  using typename base_type::inner_shape_type;
  const inner_shape_type _impl() const noexcept;
  inner_shape_type m_shape;
};
template 
constexpr auto xcontainer::shape() const noexcept
-> const inner_shape_type & {
  return derived_cast().shape_impl();
}
template 
auto xcontainer::derived_cast() const  -> const derived_type & {
  return *static_cast(this);
}
template 
auto xstrided_container::shape_impl() const noexcept
-> const inner_shape_type & {
  return m_shape;
}
template 
struct xcontainer_inner_types> {
  using shape_type = SC;
  using inner_shape_type = shape_type;
};
template 
struct xarray_container
: xstrided_container>> {};
struct xview {
  template  xview(CTA, FSL);
};
template  void make_view_impl(E e, S &&...slices) {
  using view_type = xview;
  view_type(get_slice_implementation(e, std::forward(slices))...);
}
template  void view(E e, S... slices) {
  make_view_impl(e, std::forward(slices)...);
}
void TestBody() {
  xarray a, arr;
  xrange_adaptor __trans_tmp_3 = range(1, 4),
__trans_tmp_4 = range(1, 3);
  view(a, 1, __trans_tmp_3);
  view(arr, 1, __trans_tmp_4);
}

[Bug rust/108111] New: Rust meets clang

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 108111
   Summary: Rust meets clang
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rust
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
CC: dkm at gcc dot gnu.org, gcc-rust at gcc dot gnu.org
  Target Milestone: ---

Since the new Rust code landed in gcc, I thought I'd give it 
compile with clang. The following 14 warning messages were produced:

./../trunk.d1/gcc/rust/ast/rust-item.h:2186:23: warning: 'as_string' overrides
a member function but is not marked 'override'
[-Winconsistent-missing-override]
../../trunk.d1/gcc/rust/ast/rust-item.h:2189:16: warning: 'accept_vis'
overrides a member function but is not marked 'override'
[-Winconsistent-missing-override]
../../trunk.d1/gcc/rust/ast/rust-item.h:2191:12: warning: 'get_locus' overrides
a member function but is not marked 'override'
[-Winconsistent-missing-override]
../../trunk.d1/gcc/rust/ast/rust-item.h:2196:8: warning: 'mark_for_strip'
overrides a member function but is not marked 'override'
[-Winconsistent-missing-override]
../../trunk.d1/gcc/rust/ast/rust-item.h:2197:8: warning: 'is_marked_for_strip'
overrides a member function but is not marked 'override'
[-Winconsistent-missing-override]
../../trunk.d1/gcc/rust/ast/rust-pattern.h:894:12: warning: 'get_locus'
overrides a member function but is not marked 'override'
[-Winconsistent-missing-override]
../../trunk.d1/gcc/rust/hir/tree/rust-hir-type.h:35:8: warning: private field
'in_parens' is not used [-Wunused-private-field]
../../trunk.d1/gcc/rust/lex/rust-lex.h:156:10: warning: explicitly defaulted
move assignment operator is implicitly deleted [-Wdefaulted-function-deleted]
../../trunk.d1/gcc/rust/parse/rust-parse-impl.h:14918:23: warning: operator
'?:' has lower precedence than '<<'; '<<' will be evaluated first
[-Wparentheses]
../../trunk.d1/gcc/rust/typecheck/rust-substitution-mapper.h:332:19: warning:
private field 'concrete' is not used [-Wunused-private-field]
../../trunk.d1/gcc/rust/typecheck/rust-tyty-call.h:140:31: warning: private
field 'context' is not used [-Wunused-private-field]
../../trunk.d1/gcc/rust/typecheck/rust-tyty-call.h:83:31: warning: private
field 'context' is not used [-Wunused-private-field]
/usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/new_allocator.h:181:4:
warning: destructor called on non-final 'Rust::TyTy::TypeBoundPredicate' that
has virtual functions but non-virtual destructor
[-Wdelete-non-abstract-non-virtual-dtor]
/usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_construct.h:151:7:
warning: destructor called on non-final 'Rust::TyTy::TypeBoundPredicate' that
has virtual functions but non-virtual destructor
[-Wdelete-non-abstract-non-virtual-dtor]

Some, all or none of these might be worth fixing.

[Bug ipa/108110] ice in modify_call, at ipa-param-manipulation.cc:700 with -std=c++14 -O3 -march=native

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from David Binderman  ---
CPU is AMD Ryzen 7 5700G, so -march flag is zen3.

[Bug c++/108110] New: ice in modify_call, at ipa-param-manipulation.cc:700 with -std=c++14 -O3 -march=native

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 108110
   Summary: ice in modify_call, at ipa-param-manipulation.cc:700
with -std=c++14 -O3 -march=native
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 54093
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54093=edit
gzipped C++ source code

The attached C++ source code does this:

during IPA pass: inline
In file included from
/home/dcb36/rpmbuild/BUILD/xtensor-0.23.1/test/test_xview.
cpp:33:
In function ‘auto xt::view(E&&, S&& ...) [with E =
xarray_container >, xt::layout_type::row_major, svector, true>, xtensor_expression_tag>&; S = 
{int, xrange_adaptor}]’,
inlined from ‘virtual void xt::xview_access_Test::TestBody()’ at
/home/dcb36
/rpmbuild/BUILD/xtensor-0.23.1/test/test_xview.cpp:335:51:
/home/dcb36/rpmbuild/BUILD/xtensor-0.23.1/include/xtensor/xview.hpp:1670:127:
in
ternal compiler error: in modify_call, at ipa-param-manipulation.cc:700
 1670 | return detail::make_view_impl(std::forward(e),
std::make_inde
x_sequence(), std::forward(slices)...);
  | 
  ^
0xe33c71 ipa_param_adjustments::modify_call(cgraph_edge*, bool)
../../trunk.d1/gcc/ipa-param-manipulation.cc:700

I have a reduction running. Problem seems to be recent (today or yesterday).
Command line is

$ ~/gcc/results.20221214.asan.ubsan/bin/g++ -c -march=native -std=c++14 -O3
bug867.cc

$ ~/gcc/results.20221213.asan.ubsan/bin/g++ -v 2>&1 | fgrep exp
gcc version 13.0.0 20221213 (experimental) (0a43f7b1a73c8e3b) 
$ ~/gcc/results.20221214.asan.ubsan/bin/g++ -v 2>&1 | fgrep exp
gcc version 13.0.0 20221214 (experimental) (330b9a8d87dd73e1) 
$ 

Native is zen2 or maybe zen3.

[Bug c++/108047] ice: unexpected expression of kind implicit_conv_expr

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #3 from David Binderman  ---
09c91caeb84e7c36 worked fine. 

The remaining interval seems to be [09c91caeb84e7c36..7410032a772a9e77], 
which is six revisions, four of which are by Jason and two unrelated
non-C++.

Jason's best opinion sought.

[Bug c++/108047] ice: unexpected expression of kind implicit_conv_expr

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #2 from David Binderman  ---
That worked fine, so trying 09c91caeb84e7c36.

[Bug c++/108047] ice: unexpected expression of kind implicit_conv_expr

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from David Binderman  ---
I am having a go at a git bisect. Trying 892e8c520be37d0a.

[Bug c++/108047] New: ice: unexpected expression of kind implicit_conv_expr

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 108047
   Summary: ice: unexpected expression of kind implicit_conv_expr
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For this C++ source code:

namespace std {
template  class initializer_list;
struct Trans_NS___cxx11_basic_string;
struct vector {
  vector(initializer_list);
};
struct Trans_NS___cxx11_basic_string {
  Trans_NS___cxx11_basic_string(const char *);
};
} // namespace std
constexpr auto kBufVecX = "";
template  struct TestXswap {
  std::vector BuffersIn() { return {kBufVecX}; }
};


does this 

$ ~/gcc/results.20221208.asan.ubsan/bin/g++ -c -w bug866.cc
bug866.cc: In member function ‘std::vector TestXswap< 
>::BuffersIn()’:
bug866.cc:13:45: internal compiler error: unexpected expression
‘(std::Trans_NS___cxx11_basic_string)kBufVecX’ of kind implicit_conv_expr
   13 |   std::vector BuffersIn() { return {kBufVecX}; }
  | ^
0x7386ae cxx_eval_constant_expression(constexpr_ctx const*, tree_node*,
value_cat, bool*, bool*, tree_node**)
../../trunk.d1/gcc/cp/constexpr.cc:8013

It was ok the day before:

$ ~/gcc/results.20221207.asan.ubsan/bin/g++ -c -w bug866.cc
$ 

The git hashes are 3ad0f470c16d5528 and 7410032a772a9e77, a range
of 24 commits.

[Bug tree-optimization/107937] [13 Regression] ice in find_var_cmp_const, at gimple-predicate-analysis.cc:257

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #3 from David Binderman  ---
The bug first seems to appear sometime between git hash 4d08c674b0114622
from yesterday and d0a3d55ae4a2656f, from today.

[Bug c/107937] New: ice in find_var_cmp_const, at gimple-predicate-analysis.cc:257

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 107937
   Summary: ice in find_var_cmp_const, at
gimple-predicate-analysis.cc:257
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

This reduced C code:

double getk_intersect_line_with_ycylinder_r,
getk_intersect_line_with_ycylinder_a;
getk_intersect_line_with_ycylinder_i;
getk_intersect_line_with_ycylinder(double *k2) {
  if (getk_intersect_line_with_ycylinder_r < 0.)
return sqrt(getk_intersect_line_with_ycylinder_r);
  *k2 = 0 / getk_intersect_line_with_ycylinder_a;
  {
double k2;
for (; getk_intersect_line_with_ycylinder_i;
 getk_intersect_line_with_ycylinder_i++)
  getk_intersect_line_with_ycylinder();
vecscale(k2);
  }
}

when compiled by recent gcc trunk and compiler flags -O3 -Wall, does this:

during GIMPLE pass: uninit
bug865.c:4:1: internal compiler error: in find_var_cmp_const, at
gimple-predicate-analysis.cc:257
4 | getk_intersect_line_with_ycylinder(double *k2) {
  | ^~
0x1b3ad6c find_var_cmp_const(vec, va_heap,
vl_ptr>, gphi*, gimple**, tree_node**)
../../trunk.d1/gcc/gimple-predicate-analysis.cc:257
0x1b3ad6c uninit_analysis::overlap(gphi*, unsigned int, hash_set >*, predicate const&)
../../trunk.d1/gcc/gimple-predicate-analysis.cc:648

I'll have a go at finding a git range for the problem.

[Bug c/107826] New: ice during GIMPLE pass: slp

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 107826
   Summary: ice during GIMPLE pass: slp
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For the following reduced C code, compiled as follows:

$ ~/gcc/results/bin/gcc -c -O2 -std=c99 bug864B.c
during GIMPLE pass: slp
bug864B.c:3:1: internal compiler error: Segmentation fault
3 | cpl_image_multiply_scalar_self() {
  | ^~
0xd7e3a9 crash_signal(int)
../../trunk.d1/gcc/toplev.cc:314
0x105cabc contains_struct_check(tree_node*, tree_node_structure_enum, char
const
*, int, char const*)
../../trunk.d1/gcc/tree.h:3645
0x105cabc complex_mul_pattern::matches(_complex_operation, hash_map<_slp_tree*, 
_complex_perm_kinds, simple_hashmap_traits,
_com
plex_perm_kinds> >*, hash_map,
nofree_ptr_h
ash<_slp_tree> >, bool,
simple_hashmap_traits, nofree_ptr_hash<_slp_tree> > >, bool> >*, _slp_tree**,
v
ec<_slp_tree*, va_heap, vl_ptr>*)

C code is:

enum { CPL_TYPE_FLOAT, CPL_TYPE_FLOAT_COMPLEX } __assert_fail;
cpl_image_multiply_scalar_nxy;
cpl_image_multiply_scalar_self() {
  switch (cpl_image_get_type()) {
double *pio;
unsigned long i;
pio[i] *= 0;
  case CPL_TYPE_FLOAT:
for (; cpl_image_multiply_scalar_nxy; i++)
  pio[i] *= 0;
for (; cpl_image_multiply_scalar_nxy;)
case CPL_TYPE_FLOAT_COMPLEX: {
  _Complex *pio = cpl_image_multiply_scalar_self;
  _Complex cscalar = __assert_fail;
  for (;; i++)
pio[i] *= cscalar;
}
  }
}

The code seems to first go wrong sometime between git hash 2b2f2ee49a33419f
and 59cc4da605e5cb8e, a day later.

[Bug middle-end/107734] [13 Regression] valgrind error for gcc/testsuite/cc.target/i386/pr46051.c

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #10 from David Binderman  ---
(In reply to Andrew Pinski from comment #9)
> Fixed.

Thanks for that. 

Would it ok to manually check all uses of sbitmap, to make sure they initialise
bits appropriately, or would it be better to define a constructor which sets 
the internal bitmap data to something sensible ?