[Bug target/101175] New: builtin_clz generates wrong bsr instruction

[mytbk920423 at gmail dot com via Gcc-bugs]

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

Bug ID: 101175
   Summary: builtin_clz generates wrong bsr instruction
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mytbk920423 at gmail dot com
  Target Milestone: ---

Built with '-march=x86-64-v3 -O1', the following code generates a bsr
instruction, which has undefined behavior when the source operand is zero, thus
gives wrong result (code also in https://gcc.godbolt.org/z/zzT7x57MT):

static inline int test_clz32(uint32_t value)
{
if (value != 0) {
return __builtin_clz(value);
} else {
return 32;
}
}

/* returns -1 if x == 0 */
int firstone(uint32_t x)
{
return 31 - test_clz32(x);
}

The result assembly:

firstone:
bsr eax, edi
ret

Note that the lzcnt instruction has a defined behavior to return the operand
size when operand is zero.

[Bug c++/101174] [12 Regression] CTAD causes instantiation of invalid specialization since r12-926

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

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

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
Summary|[12 Regression] CTAD causes |[12 Regression] CTAD causes
   |instantiation of invalid|instantiation of invalid
   |specialization  |specialization since
   ||r12-926
   Keywords||rejects-valid
 CC||jason at gcc dot gnu.org

--- Comment #1 from Patrick Palka  ---
Started with r12-926, before which we accepted the testcase.

[Bug c++/101113] g++ thinks constructor suppressed by a requires clause is actually a bad copy constructor

[gcc at nospam dot scs.stanford.edu via Gcc-bugs]

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

--- Comment #3 from David Mazieres  ---
(In reply to TC from comment #2)
> https://eel.is/c++draft/class.copy.ctor#5
> 
> I don't think this code is valid. The constraint (which isn't checked until
> overload resolution time anyway) can't suppress the outright ill-formedness
> of the declaration.

Admittedly, 11.4.5.3/5 makes no mention of constraints:

A declaration of a constructor for a class X is ill-formed if its first
parameter is of type cv X and either there are no other parameters or else all
other parameters have default arguments.
A member function template is never instantiated to produce such a constructor
signature.
- https://timsong-cpp.github.io/cppwp/n4868/class.copy.ctor#5

On the other hand, suppressed functions should not participate in overload
resolution.  Here's some normative language to the same effect 12.4.3/3:

Second, for a function to be viable, if it has associated constraints
([temp.constr.decl]), those constraints shall be satisfied
([temp.constr.constr]).
- https://timsong-cpp.github.io/cppwp/n4868/over.match.viable#3

So here's another example that doesn't involve 11.4.5.3/5:

#include 

template struct S2 {
  static T *fn() requires (!std::is_reference_v) { return nullptr; }
  static std::nullptr_t fn() requires std::is_reference_v { return {}; }
};

void
f()
{
  auto p = S2::fn();
}

$ g++ -std=c++20-c -o constructor.o constructor.cc
constructor.cc: In instantiation of 'struct S2':
constructor.cc:11:20:   required from here
constructor.cc:4:13: error: forming pointer to reference type 'int&'
4 |   static T *fn() requires (!std::is_reference_v) { return nullptr; }
  | ^~
make: *** [: constructor.o] Error 1

So I guess your argument is that there's a certain level of well-formedness
required even before the constraints can be evaluated, and an X::X(X) method is
as non-sensical as a type like "int&*".  That seems like a reasonable position,
though I wish the standard were more explicit.

I apologize for wasting your time if this was a bogus bug report.

For the record, in case the closed bug report comes up in anyone's web search,
an easy fix is to rely on the fact that templates won't be instantiated to bad
copy constructors:

template struct S {
  S() {}
  template S(S) requires B2 {}
};
S sf;
S st;

[Bug c++/101174] New: [12 Regression] CTAD causes instantiation of invalid specialization

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

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

Bug ID: 101174
   Summary: [12 Regression] CTAD causes instantiation of invalid
specialization
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ppalka at gcc dot gnu.org
  Target Milestone: ---

The following testcase

struct S { using type = int; };

template
struct multiset {
  using type = typename U::type;
  multiset(T);
  multiset(U);
};

template
multiset(T) -> multiset;

multiset c(42);

is rejected by GCC 12 with

: In instantiation of ‘struct multiset’:
:13:14:   required from here
:5:9: error: ‘int’ is not a class, struct, or union type
:7:3: error: ‘multiset::multiset(U) [with T = int; U = int]’
cannot be overloaded with ‘multiset::multiset(T) [with T = int; U = int]’
:6:3: note: previous declaration ‘multiset::multiset(T) [with T =
int; U = int]’

[Bug target/94780] [8/9 Regression] ICE in walk_body at gcc/tree-nested.c:713 since r6-3632-gf6f69fb09c5f81df

[xry111 at mengyan1223 dot wang via Gcc-bugs]

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at mengyan1223 dot wang

--- Comment #11 from Xi Ruoyao  ---
It's still not fixed on mips after one year :(.

Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573464.html

[Bug tree-optimization/101173] wrong code at -O3 on x86_64-linux-gnu

[qrzhang at gatech dot edu via Gcc-bugs]

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

--- Comment #1 from Qirun Zhang  ---
My bisection points to g:fbdec14e80e9399cd301ed3

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

[qrzhang at gatech dot edu via Gcc-bugs]

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

Bug ID: 101173
   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: qrzhang at gatech dot edu
  Target Milestone: ---

It affects gcc-8 to the trunk. Gcc-7.5.0 works.

$ gcc-trunk -v
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210622 (experimental) [master revision
f0e40ea0640:393ac5ed7d8:7822285515cd4dab86f722a9f4969b6952904a37] (GCC)



$ gcc-trunk abc.c ; ./a.out > 1.txt
$ gcc-trunk -O3 abc.c ; ./a.out > 2.txt

$ diff 1.txt 2.txt
11c11
< 0
---
> 8

$ cat abc.c
int a[6][9];
char b, c;
short d;
int e, f;
int main() {
  a[1][3] = 8;
  b = 1;
  for (; b <= 5; b++) {
d = 0;
for (; d <= 5; d++) {
  c = 0;
  for (; c <= 5; c++)
a[b][c] = a[b][c + 2] & 216;
}
  }
  for (; e < 6; e++) {
f = 0;
for (; f < 9; f++)
  printf("%d\n", a[e][f]);
  }
}

[Bug c/101172] New: [12 regression] ICE Segmentation fault

[anbu1024.me at gmail dot com via Gcc-bugs]

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

Bug ID: 101172
   Summary: [12 regression] ICE Segmentation fault
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anbu1024.me at gmail dot com
  Target Milestone: ---

$ cat 36.c 

union U
{
  int a[3];
  struct
  {
int a : 3;
struct this_struct var;
  } b;
};

const union U hello = {.a = {1, 2, 3}};


void foo()
{
  int x = hello.b.a;
}

---

$ gcc-sp12 --version
gcc (GCC) 12.0.0 20210620 (experimental)
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

---

$ gcc-sp12 36.c 
36.c:8:24: error: field ‘var’ has incomplete type
8 | struct this_struct var;
  |^~~
36.c: In function ‘foo’:
36.c:17:18: internal compiler error: Segmentation fault
   17 |   int x = hello.b.a;
  |   ~~~^~
0xe600af crash_signal
../../gcc-12-20210620/gcc/toplev.c:327
0xb85ab1 fold_const_aggregate_ref_1(tree_node*, tree_node* (*)(tree_node*))
../../gcc-12-20210620/gcc/gimple-fold.c:8184
0xb86e49 fold_const_aggregate_ref(tree_node*)
../../gcc-12-20210620/gcc/gimple-fold.c:8250
0xb86e49 maybe_fold_reference
../../gcc-12-20210620/gcc/gimple-fold.c:333
0xb8bc86 fold_gimple_assign
../../gcc-12-20210620/gcc/gimple-fold.c:483
0xb8bc86 fold_stmt_1
../../gcc-12-20210620/gcc/gimple-fold.c:6250
0xbd1071 gimplify_modify_expr
../../gcc-12-20210620/gcc/gimplify.c:5982
0xbb909f gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-12-20210620/gcc/gimplify.c:14094
0xbbc9f6 gimplify_stmt(tree_node**, gimple**)
../../gcc-12-20210620/gcc/gimplify.c:6865
0xbbe8d6 gimplify_and_add(tree_node*, gimple**)
../../gcc-12-20210620/gcc/gimplify.c:494
0xbbe8d6 internal_get_tmp_var
../../gcc-12-20210620/gcc/gimplify.c:647
0xbb887e get_formal_tmp_var(tree_node*, gimple**)
../../gcc-12-20210620/gcc/gimplify.c:668
0xbb887e gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-12-20210620/gcc/gimplify.c:15083
0xbb9363 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-12-20210620/gcc/gimplify.c:14399
0xbd0dff gimplify_modify_expr
../../gcc-12-20210620/gcc/gimplify.c:5806
0xbb909f gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-12-20210620/gcc/gimplify.c:14094
0xbbc9f6 gimplify_stmt(tree_node**, gimple**)
../../gcc-12-20210620/gcc/gimplify.c:6865
0xbc3c9d gimplify_and_add(tree_node*, gimple**)
../../gcc-12-20210620/gcc/gimplify.c:494
0xbc3c9d gimplify_decl_expr
../../gcc-12-20210620/gcc/gimplify.c:1831
0xbb939a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-12-20210620/gcc/gimplify.c:14291
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

---

$ gcc-sp11 --version
gcc (GCC) 11.1.1 20210619
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

---

$ gcc-sp11 36.c 
36.c:8:24: error: field ‘var’ has incomplete type
8 | struct this_struct var;
  |^~~
36.c:17: confused by earlier errors, bailing out

[Bug c/101171] New: [12 Regression] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in c_expr_sizeof_expr, at c/c-typeck.c:3006

[anbu1024.me at gmail dot com via Gcc-bugs]

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

Bug ID: 101171
   Summary: [12 Regression] ICE: tree check: expected class
‘type’, have ‘exceptional’ (error_mark) in
c_expr_sizeof_expr, at c/c-typeck.c:3006
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anbu1024.me at gmail dot com
  Target Milestone: ---

$ cat 34.c 

extern void foo(void);
int x = 0x1234;

int bar()
{
  if (x !=  ( sizeof( (enum t) 0x1234) ) )
foo();
}

---

$ gcc-sp12 --version
gcc (GCC) 12.0.0 20210620 (experimental)
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

---

$ gcc-sp12 34.c 
34.c: In function ‘bar’:
34.c:7:29: error: conversion to incomplete type
7 |   if (x !=  ( sizeof( (enum t) 0x1234) ) )
  | ^
34.c:7:29: internal compiler error: tree check: expected class ‘type’, have
‘exceptional’ (error_mark) in c_expr_sizeof_expr, at c/c-typeck.c:3006
0x7a313c tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc-12-20210620/gcc/tree.c:8734
0x65d005 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../gcc-12-20210620/gcc/tree.h:3494
0x65d005 c_expr_sizeof_expr(unsigned int, c_expr)
../../gcc-12-20210620/gcc/c/c-typeck.c:3006
0x8c573e c_parser_sizeof_expression
../../gcc-12-20210620/gcc/c/c-parser.c:8299
0x8c573e c_parser_unary_expression
../../gcc-12-20210620/gcc/c/c-parser.c:8196
0x8c6309 c_parser_cast_expression
../../gcc-12-20210620/gcc/c/c-parser.c:8066
0x8c657c c_parser_binary_expression
../../gcc-12-20210620/gcc/c/c-parser.c:7869
0x8c7835 c_parser_conditional_expression
../../gcc-12-20210620/gcc/c/c-parser.c:7592
0x8c7e70 c_parser_expr_no_commas
../../gcc-12-20210620/gcc/c/c-parser.c:7507
0x8c80f1 c_parser_expression
../../gcc-12-20210620/gcc/c/c-parser.c:10638
0x8c0853 c_parser_postfix_expression
../../gcc-12-20210620/gcc/c/c-parser.c:9086
0x8c4b4a c_parser_unary_expression
../../gcc-12-20210620/gcc/c/c-parser.c:8224
0x8c6309 c_parser_cast_expression
../../gcc-12-20210620/gcc/c/c-parser.c:8066
0x8c66f4 c_parser_binary_expression
../../gcc-12-20210620/gcc/c/c-parser.c:7992
0x8c7835 c_parser_conditional_expression
../../gcc-12-20210620/gcc/c/c-parser.c:7592
0x8c7e70 c_parser_expr_no_commas
../../gcc-12-20210620/gcc/c/c-parser.c:7507
0x8c80f1 c_parser_expression
../../gcc-12-20210620/gcc/c/c-parser.c:10638
0x8c9655 c_parser_expression_conv
../../gcc-12-20210620/gcc/c/c-parser.c:10677
0x8c9655 c_parser_condition
../../gcc-12-20210620/gcc/c/c-parser.c:6277
0x8c973b c_parser_paren_condition
../../gcc-12-20210620/gcc/c/c-parser.c:6297
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

---

$ gcc-sp11 --version
gcc (GCC) 11.1.1 20210619
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

---

$ gcc-sp11 34.c 
34.c: In function ‘bar’:
34.c:7:29: error: conversion to incomplete type
7 |   if (x !=  ( sizeof( (enum t) 0x1234) ) )
  | ^

[Bug middle-end/101170] [12 Regression] ICE in df_ref_record building libgomp for ColdFire

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #2 from joseph at codesourcery dot com  ---
No.  It's still broken as of commit 
f61e5d4d8b6d4cfa96863187fa61b8c6b057a491.

[Bug middle-end/101170] [12 Regression] ICE in df_ref_record building libgomp for ColdFire

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Doesn't r12-1727-g9b613e825d706b18f69e40edaee3eaf27d28f5cb aka PR101160 fix
this?

[Bug middle-end/101170] New: [12 Regression] ICE in df_ref_record building libgomp for ColdFire

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

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

Bug ID: 101170
   Summary: [12 Regression] ICE in df_ref_record building libgomp
for ColdFire
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
CC: jason at gcc dot gnu.org
  Target Milestone: ---
Target: m68k-linux-gnu

Created attachment 51051
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51051=edit
preprocessed source

Commit 7232f7c4c2d727431096a7ecfcf4ad4db71dcf2a ("expand: empty class return
optimization [PR88529]") introduces an ICE building libgomp for m68k-linux-gnu
(configure --with-arch=cf --disable-multilib).  Compile the attached test with
-g -O2 (the -g is required):

during RTL pass: reload
/scratch/jmyers/glibc/many12/src/gcc/libgomp/ordered.c: In function
'GOMP_doacross_ull_wait':
/scratch/jmyers/glibc/many12/src/gcc/libgomp/ordered.c:827:1: internal compiler
error: in df_ref_record, at df-scan.c:2598
  827 | }
  | ^
0x851ce2 df_ref_record
/scratch/jmyers/glibc/many12/src/gcc/gcc/df-scan.c:2598
0x8524bb df_uses_record
/scratch/jmyers/glibc/many12/src/gcc/gcc/df-scan.c:2859
0x852c78 df_insn_refs_collect
/scratch/jmyers/glibc/many12/src/gcc/gcc/df-scan.c:3213
0x8560fe df_bb_refs_record(int, bool)
/scratch/jmyers/glibc/many12/src/gcc/gcc/df-scan.c:3339
0x856674 df_scan_blocks()
/scratch/jmyers/glibc/many12/src/gcc/gcc/df-scan.c:588
0xabbc1d do_reload
/scratch/jmyers/glibc/many12/src/gcc/gcc/ira.c:5886
0xabbc1d execute
/scratch/jmyers/glibc/many12/src/gcc/gcc/ira.c:6008
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

https://sourceware.org/pipermail/libc-testresults/2021q2/008114.html

[Bug testsuite/101169] New: [12 regression] test case gcc.target/powerpc/fold-vec-extract-char.p7.c fails after r10-9880

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

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

Bug ID: 101169
   Summary: [12 regression] test case
gcc.target/powerpc/fold-vec-extract-char.p7.c fails
after r10-9880
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:eb13f3f81d56910626529af52e03e74770ffca98, r10-9880
make  -k check-gcc
RUNTESTFLAGS="powerpc.exp=gcc.target/powerpc/fold-vec-extract-char.p7.c"
FAIL: gcc.target/powerpc/fold-vec-extract-char.p7.c scan-assembler-times
\\maddi\\M 6
# of expected passes7
# of unexpected failures1


Previously there were 6 addi instructions and now there are 9.  This may have a
performance impact.


commit eb13f3f81d56910626529af52e03e74770ffca98
Author: Vladimir N. Makarov 
Date:   Tue Jan 12 11:26:15 2021 -0500

[PR97969] LRA: Transform pattern `plus (plus (hard reg, const),
pseudo)` after elimination

[Bug c++/101107] Misleading error message in aggregate initialization in CRTP base class

[rs2740 at gmail dot com via Gcc-bugs]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #1 from TC  ---
Since `*this` can't initialize an `A`, it's assuming brace elision. Not sure
how the diagnostic can be made clearer though...perhaps it can report that
assumption?

[Bug testsuite/101114] new test case libgomp.c/../libgomp.c-c++-common/struct-elem-5.c fails after its introduction in r12-1565

[skpgkp2 at gmail dot com via Gcc-bugs]

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

Sunil Pandey  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #1 from Sunil Pandey  ---
Also saw the same issue  on x86 target.

On Linux/x86_64,

275c736e732d29934e4d22e8f030d5aae8c12a52 is the first bad commit
commit 275c736e732d29934e4d22e8f030d5aae8c12a52
Author: Chung-Lin Tang 
Date:   Thu Jun 17 21:33:32 2021 +0800

libgomp: Structure element mapping for OpenMP 5.0

caused

FAIL: libgomp.c/../libgomp.c-c++-common/struct-elem-5.c execution test


with GCC configured with

../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r12-1565/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/x86_64-linux/libgomp/testsuite && make check
RUNTESTFLAGS="c++.exp=libgomp.c-c++-common/struct-elem-5.c
--target_board='unix{-m32}'"
$ cd {build_dir}/x86_64-linux/libgomp/testsuite && make check
RUNTESTFLAGS="c++.exp=libgomp.c-c++-common/struct-elem-5.c
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/x86_64-linux/libgomp/testsuite && make check
RUNTESTFLAGS="c++.exp=libgomp.c-c++-common/struct-elem-5.c
--target_board='unix{-m64}'"
$ cd {build_dir}/x86_64-linux/libgomp/testsuite && make check
RUNTESTFLAGS="c++.exp=libgomp.c-c++-common/struct-elem-5.c
--target_board='unix{-m64\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me
at skpgkp2 at gmail dot com)

[Bug c++/101113] g++ thinks constructor suppressed by a requires clause is actually a bad copy constructor

[rs2740 at gmail dot com via Gcc-bugs]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #2 from TC  ---
https://eel.is/c++draft/class.copy.ctor#5

I don't think this code is valid. The constraint (which isn't checked until
overload resolution time anyway) can't suppress the outright ill-formedness of
the declaration.

[Bug inline-asm/100953] Add memory clobbers just for reads or just for writes

[foom at fuhm dot net via Gcc-bugs]

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

James Y Knight  changed:

   What|Removed |Added

 CC||foom at fuhm dot net

--- Comment #3 from James Y Knight  ---
For the compiler-barrier use-cases, you can use the __atomic_signal_fence
builtin instead of an empty inline-asm statement.

E.g. if you want to make sure that all writes apperaing after a barrier are
actually emitted after all reads/writes appearing before the barrier, use
__atomic_signal_fence(__ATOMIC_RELEASE).

[Bug fortran/93524] [ISO C Binding][F2018] CFI_allocate – elem_size mishandled + sm wrongly set?

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

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #5 from sandra at gcc dot gnu.org ---
I've checked in a patch that fixes the problem in the description, and I think
that none of the other bugs reported in other comments are still present.

I think this patch ought to be backported to GCC 11 and possibly other branches
as well, since it's a pretty small bug fix.  What branches have similar fixes
for C interoperability features been going on?

[Bug fortran/93524] [ISO C Binding][F2018] CFI_allocate – elem_size mishandled + sm wrongly set?

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Sandra Loosemore :

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

commit r12-1733-gf61e5d4d8b6d4cfa96863187fa61b8c6b057a491
Author: Sandra Loosemore 
Date:   Tue Jun 22 12:42:17 2021 -0700

Fortran: fix sm computation in CFI_allocate [PR93524]

This patch fixes a bug in setting the step multiplier field in the
C descriptor for array dimensions > 2.

2021-06-21  Sandra Loosemore  
Tobias Burnus  

libgfortran/
PR fortran/93524
* runtime/ISO_Fortran_binding.c (CFI_allocate): Fix
sm computation.

gcc/testsuite/
PR fortran/93524
* gfortran.dg/pr93524.c: New.
* gfortran.dg/pr93524.f90: New.

[Bug gcov-profile/80223] RFE: Exclude functions from profile instrumentation

[ndesaulniers at google dot com via Gcc-bugs]

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

--- Comment #16 from Nick Desaulniers  ---
Clang patch (no_profile -> no_profile_instrument_function):
https://reviews.llvm.org/D104658
Kernel patches v2:
https://lore.kernel.org/lkml/20210621231822.2848305-1-ndesaulni...@google.com/

[Bug c++/101168] New: gnu++14 complains about altivec types defined with using keyword in the same file with preprocessor macros

[tuliom at ascii dot art.br via Gcc-bugs]

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

Bug ID: 101168
   Summary: gnu++14 complains about altivec types defined with
using keyword in the same file with preprocessor
macros
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tuliom at ascii dot art.br
  Target Milestone: ---

Step to reproduce the error:

$ cat issue.cc 
#include 
using vdbl =  __vector double;

#define BREAK 1
$ g++ -std=gnu++14 -c issue.cc 
issue.cc:4:15: error: expected type-specifier before numeric constant
4 | #define BREAK 1
  |   ^
issue.cc:4:9: note: in expansion of macro ‘BREAK’
4 | #define BREAK 1
  | ^

The error does not reproduce when using -std=c++14.

[Bug middle-end/101157] [12 regression] ICE compiling gcc.target/powerpc/stack-limit.c after r12-1702

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

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

--- Comment #4 from Martin Liška  ---
Apparently, the same issue breaks gcc bootstrap on s390x:

[ 4191s] during RTL pass: reload
[ 4191s] ../../gcc/fortran/check.c: In function 'gfc_calculate_transfer_sizes':
[ 4191s] ../../gcc/fortran/check.c:6205: internal compiler error: in
df_ref_record, at df-scan.c:2598
[ 4191s]  6205 | }
[ 4191s]   | 
[ 4191s] 0x12c2f07 df_ref_record
[ 4191s]../../gcc/df-scan.c:2598
[ 4191s] 0x12c34f9 df_uses_record
[ 4191s]../../gcc/df-scan.c:2857
[ 4191s] 0x12c3c19 df_insn_refs_collect
[ 4191s]../../gcc/df-scan.c:3212
[ 4191s] 0x12c6f07 df_bb_refs_record(int, bool)
[ 4191s]../../gcc/df-scan.c:3339
[ 4191s] 0x12c7fc7 df_scan_blocks()
[ 4191s]../../gcc/df-scan.c:588
[ 4191s] 0x14c4497 do_reload
[ 4191s]../../gcc/ira.c:5886
[ 4191s] 0x14c4497 execute
[ 4191s]../../gcc/ira.c:6008
[ 4191s] Please submit a full bug report,
[ 4191s] with preprocessed source if appropriate.
[ 4191s] Please include the complete backtrace with any bug report.
[ 4191s] See  for instructions.
[ 4191s] make[4]: *** [/tmp/cc3oPIcv.mk:257: /tmp/ccvUgWTy.ltrans85.ltrans.o]
Error 1
[ 4191s] lto-wrapper: fatal error: make returned 2 exit status

[Bug libstdc++/100806] deadlock in std::counting_semaphore

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

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Thomas Rodgers
:

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

commit r11-8638-gc24384efbbaeeca3dbc53e7d1226a57bc16e9ad5
Author: Thomas Rodgers 
Date:   Tue Jun 22 10:59:07 2021 -0700

libstdc++: Fix for deadlock in std::counting_semaphore [PR100806]

libstdc++-v3/ChangeLog:
PR libstdc++/100806
* include/bits/semaphore_base.h (__atomic_semaphore::_M_release):
Force _M_release() to wake all waiting threads.
* testsuite/30_threads/semaphore/100806.cc: New test.

(cherry picked from commit e02840c1a92abecd211ffaf05b28329bcb534583)

[Bug libstdc++/100806] deadlock in std::counting_semaphore

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Thomas Rodgers :

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

commit r12-1732-ge02840c1a92abecd211ffaf05b28329bcb534583
Author: Thomas Rodgers 
Date:   Tue Jun 22 10:59:07 2021 -0700

libstdc++: Fix for deadlock in std::counting_semaphore [PR100806]

libstdc++-v3/ChangeLog:
PR libstdc++/100806
* include/bits/semaphore_base.h (__atomic_semaphore::_M_release):
Force _M_release() to wake all waiting threads.
* testsuite/30_threads/semaphore/100806.cc: New test.

[Bug analyzer/101143] [12 Regression] ICE: incompatible types: 'unsigned int' and 'long unsigned int'

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

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

David Malcolm  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from David Malcolm  ---
Should be fixed by the above commit.

[Bug analyzer/101143] [12 Regression] ICE: incompatible types: 'unsigned int' and 'long unsigned int'

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by David Malcolm :

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

commit r12-1731-gea4e32181d7a36055b57421abd0ced4735654cf6
Author: David Malcolm 
Date:   Tue Jun 22 13:44:57 2021 -0400

analyzer: fix ICE on malloc/alloca param type mismatch [PR101143]

gcc/analyzer/ChangeLog:
PR analyzer/101143
* region-model.cc (compat_types_p): New function.
(region_model::create_region_for_heap_alloc): Convert assertion to
an error check.
(region_model::create_region_for_alloca): Likewise.

gcc/testsuite/ChangeLog:
PR analyzer/101143
* gcc.dg/analyzer/pr101143.c: New test.

Signed-off-by: David Malcolm 

[Bug other/101166] Add SPDX license identifiers

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

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

--- Comment #1 from Andrew Pinski  ---
I think this is a good idea.

[Bug middle-end/101167] Miscompilation of task_reduction

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Keywords||openmp, wrong-code
   Last reconfirmed||2021-06-22
 Status|UNCONFIRMED |ASSIGNED

[Bug middle-end/101167] New: Miscompilation of task_reduction

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

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

Bug ID: 101167
   Summary: Miscompilation of task_reduction
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: jakub at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

struct S { int a, b, c[2]; };

void
init (struct S *x)
{
  x->a = 0;
  x->b = 0;
  x->c[0] = 0;
  x->c[1] = 0;
}

void
merge (struct S *x, struct S *y)
{
  x->a += y->a;
  x->b += y->b;
}

#pragma omp declare reduction (+: struct S : merge (_out, _in))
initializer (init (_priv))

void
foo (struct S x)
{
  #pragma omp taskgroup task_reduction (+: x)
  {
#pragma omp task in_reduction (+: x)
{
  x.a++;
  x.b++;
}
#pragma omp task in_reduction (+: x)
{
  x.a += 4;
  x.b += 14;
}
#pragma omp task in_reduction (+: x)
{
  x.a += 9;
  x.b += 19;
}
  }
  if (x.a != 56 || x.b != 86)
__builtin_abort ();
}

int
main ()
{
  struct S x = { 42, 52 };
  #pragma omp parallel master
  foo (x);
  return 0;
}

is miscompiled, merge is called with the same argument twice instead of merging
from the task privatized variable(s) into the PARM_DECL.

[Bug other/101166] New: Add SPDX license identifiers

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

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

Bug ID: 101166
   Summary: Add SPDX license identifiers
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
  Target Milestone: ---

Add appropriate SPDX license identifiers to GCC source code files.

https://spdx.org/licenses/

[Bug c++/101165] [C++23] P2266R1 - Simpler implicit move

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

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-06-22
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Clickable link: https://wg21.link/p2266

[Bug c++/101165] New: [C++23] P2266R1 - Simpler implicit move

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

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

Bug ID: 101165
   Summary: [C++23] P2266R1 - Simpler implicit move
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
Blocks: 98940
  Target Milestone: ---

See .


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98940
[Bug 98940] Implement C++23 language features

[Bug middle-end/101134] Bogus -Wstringop-overflow warning about non-existent overflow

[dangelog at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Giuseppe D'Angelo  ---
(In reply to Martin Sebor from comment #5)
> It wouldn't be right to change the wording of just one warning because the
> problem applies to all flow based diagnostics.  They all depend on various
> optimizations that propagate constants, add or remove tests, and change the
> control flow graph.  A statement that in the source code is conditional on
> the values of various parameters might in the intermediate representation
> appear unconditional with constants as a result, even be unconditionally
> invalid but unreachable.  This is true at function scope as well as across
> function call boundaries thanks to inlining.  Changing the wording for all
> of them to try to somehow reflect this wouldn't help because then all
> instances of them all would have to use the new form.

Sorry, why wouldn't help? That is, given the fact that these warnings do have
false positives, why would it bad for such warnings to say "something bad MIGHT
be happening here" vs "something bad IS happening here"? 

For an end user, it makes a lot of difference to know if the compiler has
definitely found something wrong vs. the compiler may or may not have found it.
Just a tiny language change in the printed mesage would reassure the user that
the warning could, in fact, be a false positive. (Compare this to "there IS
something bad here". You read the code in question, and you don't see what's
bad, and you start digging around trying to understand "why is the compiler
telling me that there IS something bad? Am I not seeing something?".)


> -Wuninitialized and -Wmaybe-uninitialized aren't substantially different in
> this.  The latter is unique only in that it diagnoses arguments of PHI
> nodes, which are the results of conditional expressions.  This property is
> described by the following sentence in the manual:
> 
> "...if there exists a path from the function entry to a use of the object
> that is initialized, but there exist some other paths for which the object
> is not initialized, the compiler emits a warning if it cannot prove the
> uninitialized paths are not executed at run time."
> 
> This is only roughly what happens but there are many instances of
> -Wuninitialized that could be described using the same sentence, even though
> it doesn't consider PHI nodes.  If we do introduce a similar distinction in
> other warnings like -Wstringop-overflow it will be on top of the instances
> already issued by them, not a subset of them.
> 
> This is a general property of all flow based warnings in GCC except those
> emitted by the static analyzer which doesn't depend on the same
> optimizations (only a very small subset of them).  All warnings (flow based
> or otherwise, including those issued by the analyzer) should always be
> viewed as documented, i.e., as "messages that report constructions that are
> not inherently erroneous but that are risky or suggest there may have been
> an error."

"not inherently erroneous" is as per language rules (i.e. the program isn't
ill-formed). But "there may have been" an error is the key I'm trying to point
out. The compiler can prove that something is a mistake, or can only estimate
that, and so raise a false positive. I'd rather have a message telling me
whether a given warning is because of a proof or an estimate.

gcc-11 - arm cross-compiler with golang build error. runtime.inc

[Lance Fredrickson via Gcc-bugs]

I build an arm cross-compiler  with support for golang, but am getting 
build error on gcc-11.  I've tried a couple toolchain creators (ie 
crosstool-ng) with the same results.


kernel 2.6.36.4
arm soft-float (no fpu)
using uclibc-ng for my c-library

runtime.inc (which I guess is generated because it's not present until 
building) seems to be missing a couple struct definitions? I don't see 
any includes, so I'm wondering if they somehow get missed in generation?


Please cc me.
thanks,
Lance

In file included from ../../../libgo/runtime/runtime.h:105,
 from ../../../libgo/runtime/go-main.c:17:
./runtime.inc:1357:29: error: field ‘__state’ has incomplete type
 1357 | struct ___mbstate_t __state;
  | ^~~
./runtime.inc:1360:33: error: field ‘__lock’ has incomplete type
 1360 | struct _pthread_mutex_t __lock;
  | ^~

[Bug middle-end/101134] Bogus -Wstringop-overflow warning about non-existent overflow

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

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

--- Comment #5 from Martin Sebor  ---
It wouldn't be right to change the wording of just one warning because the
problem applies to all flow based diagnostics.  They all depend on various
optimizations that propagate constants, add or remove tests, and change the
control flow graph.  A statement that in the source code is conditional on the
values of various parameters might in the intermediate representation appear
unconditional with constants as a result, even be unconditionally invalid but
unreachable.  This is true at function scope as well as across function call
boundaries thanks to inlining.  Changing the wording for all of them to try to
somehow reflect this wouldn't help because then all instances of them all would
have to use the new form.

-Wuninitialized and -Wmaybe-uninitialized aren't substantially different in
this.  The latter is unique only in that it diagnoses arguments of PHI nodes,
which are the results of conditional expressions.  This property is described
by the following sentence in the manual:

"...if there exists a path from the function entry to a use of the object that
is initialized, but there exist some other paths for which the object is not
initialized, the compiler emits a warning if it cannot prove the uninitialized
paths are not executed at run time."

This is only roughly what happens but there are many instances of
-Wuninitialized that could be described using the same sentence, even though it
doesn't consider PHI nodes.  If we do introduce a similar distinction in other
warnings like -Wstringop-overflow it will be on top of the instances already
issued by them, not a subset of them.

This is a general property of all flow based warnings in GCC except those
emitted by the static analyzer which doesn't depend on the same optimizations
(only a very small subset of them).  All warnings (flow based or otherwise,
including those issued by the analyzer) should always be viewed as documented,
i.e., as "messages that report constructions that are not inherently erroneous
but that are risky or suggest there may have been an error."

[Bug middle-end/101157] [12 regression] ICE compiling gcc.target/powerpc/stack-limit.c after r12-1702

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

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

--- Comment #3 from seurer at gcc dot gnu.org ---
OK, there is another similar error compiling a different test case traced to
the same revision.  And these are occurring on more than just power 10s.

Executing on host: /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/ exceptions_enabled961334.cc   
-fdiagnostics-plain-output  -S -o exceptions_enabled961334.s(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/ exceptions_enabled961334.cc
-fdiagnostics-plain-output -S -o exceptions_enabled961334.s
FAIL: gcc.target/powerpc/pr48344-1.c (test for excess errors)
Excess errors:
during RTL pass: no-opt dfinit
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/pr48344-1.c:8:1:
internal compiler error: in df_ref_record, at df-scan.c:2598
0x1057f137 df_ref_record
/home/seurer/gcc/git/gcc-test/gcc/df-scan.c:2598
0x1057feab df_uses_record
/home/seurer/gcc/git/gcc-test/gcc/df-scan.c:3033
0x1057fd97 df_uses_record
/home/seurer/gcc/git/gcc-test/gcc/df-scan.c:2888
0x1058089f df_insn_refs_collect
/home/seurer/gcc/git/gcc-test/gcc/df-scan.c:3212
0x105849bb df_bb_refs_record(int, bool)
/home/seurer/gcc/git/gcc-test/gcc/df-scan.c:3339
0x1058520b df_scan_blocks()
/home/seurer/gcc/git/gcc-test/gcc/df-scan.c:588
0x10563e47 rest_of_handle_df_initialize
/home/seurer/gcc/git/gcc-test/gcc/df-core.c:715
0x10563e47 execute
/home/seurer/gcc/git/gcc-test/gcc/df-core.c:747

[Bug tree-optimization/101014] [12 Regression] Big compile time hog with -O3 since r12-1268-g9858cd1a6827ee7a

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

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

--- Comment #18 from Martin Liška  ---
Thank you for the patch. I can confirm it fixes both the attached yarpgen
test-case and cam4 finishes (PR101148).

[Bug c++/86439] CTAD with deleted copy constructor fails due to deduction-guide taking by value

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

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

--- Comment #1 from Patrick Palka  ---
Another side effect of this is that GCC incorrectly rejects the following use
of CTAD + braced-init-lists:

struct B { };
struct C { };

template
struct A {
  A(T, B);
};

template
A(T, C) -> A;

A a(0, {});

The problem is that building the call to the deduction guide has the side
effect of changing the type of the {} to C, which causes later overload
resolution to fail because C isn't convertible to B.

[Bug analyzer/101143] [12 Regression] ICE: incompatible types: 'unsigned int' and 'long unsigned int'

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

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

David Malcolm  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #2 from David Malcolm  ---
Thanks for filing this; am working on a fix.

[Bug c++/101164] slow compilation for huge classes (>200k member variables)

[rbuergel at web dot de via Gcc-bugs]

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

--- Comment #5 from René Bürgel  ---
Thanks for the explanations

[Bug tree-optimization/101014] [12 Regression] Big compile time hog with -O3 since r12-1268-g9858cd1a6827ee7a

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #17 from Andrew Macleod  ---
Created attachment 51050
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51050=edit
patch to fix the issue

The gift that keeps on giving eh.
OK, this should solve the infinite loop. Give it a try, I'm running it through
testing now.

When I introduced the sparse on-entry cache, it is limited to 15 unique ranges
for any given ssa-name, then  it reverts to varying for any additional values
to be safe.

The cache propagation engine works by combining incoming ranges and if that is
different than that current on-entry range, stores that  and proceeds to push
this new value on outgoing edges.

What was happening here is this new value that was calculated was beyond the 15
allowed. When it was stored, it was stored as VARYING.  This block was in a
cycle feeding back to itself, so when it calculated the on-enty value again and
compared, it though it needed to update again.  Which of course failed again...
and the endless loop of trying to propagate was born.

This patch checks that the value being stored to the cache is the same as the
value when it is immediately reloaded. If that fails, we stop trying to
propagate that value.

Please check that it solves both this problam, and likely the 101148 problem

[Bug middle-end/101156] [9/10/11 Regression] ICE: ‘verify_gimple’ failed, verify_gimple_in_seq(gimple*)

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.5
Version|tree-ssa|12.0
  Known to fail||7.5.0, 8.5.0
Summary|ICE: ‘verify_gimple’|[9/10/11 Regression] ICE:
   |failed, |‘verify_gimple’ failed,
   |verify_gimple_in_seq(gimple |verify_gimple_in_seq(gimple
   |*)  |*)
   Keywords||ice-on-valid-code,
   ||wrong-code
  Known to work||12.0
  Component|c   |middle-end

--- Comment #5 from Richard Biener  ---
Fixed on trunk sofar, unsure if worth backporting - we've not hit this in 5
years ;)

[Bug c/101156] ICE: ‘verify_gimple’ failed, verify_gimple_in_seq(gimple*)

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Richard Biener :

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

commit r12-1729-gb4e21c80462682c4e6e5e487fe87107b27f8b4bd
Author: Richard Biener 
Date:   Tue Jun 22 12:13:44 2021 +0200

middle-end/101156 - remove not working optimization in gimplification

This removes a premature and not working optimization from the
gimplifier.  When gimplification is requested not to produce a SSA
name we try to avoid generating a copy when we did so anyway but
instead replace the LHS of its definition.  But that only works in
case there are no uses of the SSA name already which is something
we cannot easily check, so the following removes said optimization.

Statistics on the whole bootstrap shows we hit this optimization
only for libiberty/cp-demangle.c and overall we have 21652112
gimplifications where just 240 copies are elided.  Preserving
the optimization would require scanning the original expression
and the pre and post sequences for SSA names and uses, that seems
excessive to avoid these 240 copies.

2021-06-22  Richard Biener  

PR middle-end/101156
* gimplify.c (gimplify_expr): Remove premature incorrect
optimization.

* gcc.dg/pr101156.c: New testcase.

[Bug tree-optimization/101159] [12 Regression] ICE Segmentation fault since r12-1707-ge08a125b208e717f

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:3adb9ac6626c15ba21e4eaf27fec95688a3ca8c2

commit r12-1728-g3adb9ac6626c15ba21e4eaf27fec95688a3ca8c2
Author: Jakub Jelinek 
Date:   Tue Jun 22 15:22:51 2021 +0200

testsuite: Add testcase for recently fixed PR [PR101159]

On Tue, Jun 22, 2021 at 11:00:51AM +0200, Richard Biener wrote:
> 2021-06-22  Richard Biener  
>
>   PR tree-optimization/101159
>   * tree-vect-patterns.c (vect_recog_popcount_pattern): Add
>   missing NULL vectype check.

The following patch adds the testcase for it, IMHO it can't hurt and
from my experience testcases often trigger other bugs later on (rather
than the original bugs reappearing, though even that happens),
and also fixes a couple of typos in the new function.

2021-06-22  Jakub Jelinek  

PR tree-optimization/101159
* tree-vect-patterns.c (vect_recog_popcount_pattern): Fix some
comment typos.

* gcc.c-torture/compile/pr101159.c: New test.

[Bug middle-end/101160] [12 Regression] ICE in df_word_lr_local_compute, at df-problems.c:2962 since r12-1702-g7232f7c4c2d72743

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r12-1727-g9b613e825d706b18f69e40edaee3eaf27d28f5cb
Author: Jakub Jelinek 
Date:   Tue Jun 22 15:21:35 2021 +0200

expand: Fix up empty class return optimization [PR101160]

On Mon, Jun 14, 2021 at 11:24:22PM -0400, Jason Merrill via Gcc-patches
wrote:
> The x86_64 psABI says that an empty class isn't passed or returned in
memory or
> registers, so we shouldn't set %eax in this function.  Is this a
reasonable
> place to implement that?  Another possibility would be to remove the hack
to
> prevent i386.c:function_value_64 from returning NULL in this case and fix
the
> callers to deal, but that seems like more work.
>
> The df-scan hunk catches the case where we look at a 0-length reg and
build
> a range the length of unsigned int, which happened before I changed
> assign_parms to match expand_function_end.

The assign_params change unfortunately breaks e.g. the following testcase.
The problem is that some passes (e.g. subreg lowering but assign_parms
comments also talk about delayed slot scheduling) rely on crtl->return_rtx
not to contain pseudo registers, and the assign_parms change results
in the pseudo in there not being replaced with a hard register.

The following patch instead clears the crtl->return_rtx if a function
returns TYPE_EMPTY_P structure, that way (use (pseudo)) is not emitted
into the IL and it is treated like more like functions returning void.

I've also changed the effective target on the empty-class1.C testcase, so
that it doesn't fail on x86_64-linux with -m32 testing.

2021-06-22  Jakub Jelinek  

PR middle-end/101160
* function.c (assign_parms): For decl_result with TYPE_EMPTY_P type
clear crtl->return_rtx instead of keeping it referencing a pseudo.

* g++.target/i386/empty-class1.C: Require lp64 effective target
instead of x86_64-*-*.
* g++.target/i386/empty-class2.C: New test.

[Bug tree-optimization/101162] [12 Regression] ICE (verify_gimple failed) for switch returning pointer-to-members since r12-1608

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:92d9c9e705f039f42734139c233202888d2bf01b

commit r12-1726-g92d9c9e705f039f42734139c233202888d2bf01b
Author: Jakub Jelinek 
Date:   Tue Jun 22 15:20:14 2021 +0200

fold-const: Return corresponding integral type for OFFSET_TYPE in
range_check_type [PR101162]

Andrew's recent r12-1608-g2f1686ff70b25fceb04ca2ffc0a450fb682913ef change
to fail verification on various unary and binary operations with
OFFSET_TYPE
revealed that e.g. switchconv happily performs multiplications and
additions
in OFFSET_TYPE.

2021-06-22  Jakub Jelinek  
Andrew Pinski  

PR tree-optimization/101162
* fold-const.c (range_check_type): Handle OFFSET_TYPE like pointer
types.

* g++.dg/opt/pr101162.C: New test.

[Bug c++/101164] slow compilation for huge classes (>200k member variables)

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

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

--- Comment #4 from Jonathan Wakely  ---
For example, the C++ front end has to be prepared to handle this:

struct S {
  int i;
  decltype(i) j;
  int k[sizeof(i)];
};

The C++ compiler has to keep track of every name from its point of declaration,
in case it's used in later member declarations.

[Bug tree-optimization/101097] Vectorizer is too eager to use vec_unpack

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #11 from rsandifo at gcc dot gnu.org  
---
FWIW, you could try something similar to how aarch64 handles this
for Advanced SIMD, with a combination of:

- TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_MODES
- TARGET_VECTORIZE_RELATED_MODE.

We get the optimal code for these tests on aarch64, even when
the loop vectoriser is used.  E.g.:

void bar (short unsigned int * p1, short unsigned int * p2, int * restrict p3)
{
  vector(4) int vect__11.26;
  vector(4) int vect__8.25;
  vector(4) short unsigned int vect__7.24;
  vector(4) int vect__5.21;
  vector(4) short unsigned int vect__4.20;

   [local count: 214748371]:
  vect__4.20_34 = MEM  [(short unsigned int
*)p1_15(D)];
  vect__5.21_35 = (vector(4) int) vect__4.20_34;
  vect__7.24_38 = MEM  [(short unsigned int
*)p2_16(D)];
  vect__8.25_39 = (vector(4) int) vect__7.24_38;
  vect__11.26_40 = vect__5.21_35 + vect__8.25_39;
  MEM  [(int *)p3_17(D)] = vect__11.26_40;
  return;
}

which for -O2 -ftree-vectorize is produced by the loop vectorizer
rather than SLP.

[Bug tree-optimization/101162] [12 Regression] ICE (verify_gimple failed) for switch returning pointer-to-members since r12-1608

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #4 from Martin Liška  ---
Just for the record, started with r12-1608-g2f1686ff70b25fce.

[Bug c++/101137] std::conjunction result error

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #5 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #3)
> I think the problem is a simple typo in your is_signed_integral_convert_copy
> trait, you use boost::mp11::mp_first>
> ^
> 
> Presumably that's supposed to be boost::mp11::mp_first>.

So not a bug.
   ^

[Bug c++/101164] slow compilation for huge classes (>200k member variables)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
No, that is not really useful, the C FE as well as the languages are
substantially different and what is possible in the C FE isn't possible for
C++, C doesn't have using decls, type:: nor many other language features
relevant for the name lookup.
So C can tie the lookup to the identifiers and pop that at the end of
aggregates, C++ can't.

[Bug c++/101164] slow compilation for huge classes (>200k member variables)

[rbuergel at web dot de via Gcc-bugs]

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

--- Comment #2 from René Bürgel  ---
it might be worth taking a look how the C frontend handles it and why this
issue doesn't exist there? Just guessing...

[Bug c++/101164] slow compilation for huge classes (>200k member variables)

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

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

Richard Biener  changed:

   What|Removed |Added

 Depends on||101163

--- Comment #1 from Richard Biener  ---
I believe it's exactly the same issue as with functions.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101163
[Bug 101163] slow compilation for huge classes (>20k members functions)

[Bug c++/101163] slow compilation for huge classes (>20k members functions)

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

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

--- Comment #4 from Richard Biener  ---
OTOH the "binary search tables" are vectors which of course makes them hard to
build incrementally since insert is O(n).  It might be possible to use
a hash-table in the storage place of said vector storage during construction
and then compact that down to the current binary search vector when finalized.

[Bug c++/101164] New: slow compilation for huge classes (>200k member variables)

[rbuergel at web dot de via Gcc-bugs]

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

Bug ID: 101164
   Summary: slow compilation for huge classes (>200k member
variables)
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rbuergel at web dot de
  Target Milestone: ---

Created attachment 51049
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51049=edit
clean example

similar to bug #101163, this also happens for member variables.

What puzzles me here: using gcc instead of g++ works perfectly fine


g++-4.9 slow-member-var.c -ftime-report

Execution times (seconds)
 phase setup :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall 
  1445 kB ( 7%) ggc
 phase parsing   :   7.96 (100%) usr   0.16 (100%) sys   8.14 (100%)
wall   18470 kB (92%) ggc
 phase finalize  :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall 
 0 kB ( 0%) ggc
 |name lookup:   7.74 (97%) usr   0.07 (44%) sys   7.82 (96%) wall 
  2073 kB (10%) ggc
 preprocessing   :   0.00 ( 0%) usr   0.06 (38%) sys   0.07 ( 1%) wall 
  5046 kB (25%) ggc
 parser (global) :   0.02 ( 0%) usr   0.02 (12%) sys   0.03 ( 0%) wall 
  3886 kB (19%) ggc
 parser struct body  :   7.94 (100%) usr   0.08 (50%) sys   8.04 (99%) wall
   9536 kB (48%) ggc
 TOTAL :   7.96 0.16 8.15 
19975 kB


gcc-4.9 slow-member-var.c -ftime-report

Execution times (seconds)
 phase setup :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall 
  1124 kB ( 9%) ggc
 phase parsing   :   0.12 (100%) usr   0.10 (100%) sys   0.22 (100%)
wall   10866 kB (90%) ggc
 preprocessing   :   0.04 (33%) usr   0.03 (30%) sys   0.07 (32%) wall 
  4811 kB (40%) ggc
 lexical analysis:   0.05 (42%) usr   0.02 (20%) sys   0.08 (36%) wall 
 0 kB ( 0%) ggc
 parser struct body  :   0.03 (25%) usr   0.05 (50%) sys   0.07 (32%) wall 
  5951 kB (49%) ggc
 TOTAL :   0.12 0.10 0.22 
12045 kB

[Bug c++/101163] slow compilation for huge classes (>20k members)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
There are binary search tables used for name-lookup later on (once the type is
completed), linear searches are used while the class is constructed.
Perhaps a way out of this would be to have a hybrid lookup during the
construction, use linear searches like now, but once more than certain number
of members is added (a few hundred?), (re)build partial binary search tables
after each such number of new members is added and if not found in the binary
search tables, do the linear search on the rest.

[Bug tree-optimization/101151] [11 Regression] ICE at -O1 and above on x86_64-linux-gnu: verify_ssa failed since r11-3705-gdae673abd37d4004

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|[11/12 Regression] ICE at   |[11 Regression] ICE at -O1
   |-O1 and above on|and above on
   |x86_64-linux-gnu:   |x86_64-linux-gnu:
   |verify_ssa failed since |verify_ssa failed since
   |r11-3705-gdae673abd37d4004  |r11-3705-gdae673abd37d4004
  Known to work||12.0

--- Comment #5 from Richard Biener  ---
Fixed on trunk sofar.

[Bug tree-optimization/101151] [11/12 Regression] ICE at -O1 and above on x86_64-linux-gnu: verify_ssa failed since r11-3705-gdae673abd37d4004

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Richard Biener :

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

commit r12-1718-ga2ef8395fa970498985764514044e5fd00f7d5c0
Author: Richard Biener 
Date:   Tue Jun 22 10:14:02 2021 +0200

tree-optimization/101151 - fix irreducible region check for sinking

The check whether two blocks are in the same irreducible region
and thus post-dominance checks being unreliable was incomplete
since an irreducible region can contain reducible sub-regions but
if one block is in the irreducible part and one not the check
still doesn't work as expected.

2021-06-22  Richard Biener  

PR tree-optimization/101151
* tree-ssa-sink.c (statement_sink_location): Expand irreducible
region check.

* gcc.dg/torture/pr101151.c: New testcase.

[Bug tree-optimization/101159] [12 Regression] ICE Segmentation fault since r12-1707-ge08a125b208e717f

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #7 from rguenther at suse dot de  ---
On Tue, 22 Jun 2021, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101159
> 
> Jakub Jelinek  changed:
> 
>What|Removed |Added
> 
>  CC||jakub at gcc dot gnu.org
> 
> --- Comment #6 from Jakub Jelinek  ---
> No testcase for the testsuite?

It's unlikely to come back and the fix is quite obvious so I indeed
didn't bother ...

[Bug c++/101163] slow compilation for huge classes (>20k members)

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2021-06-22
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Keywords||compile-time-hog
 CC||nathan at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
Confirmed on trunk.  There are linked-lists involved, so not unexpected I
guess.

The top functions in a profile of an unoptimized cc1plus are
fields_linear_search
and member_vec_linear_search called from get_class_binding[_direct] called
ultimatively from lookup_member.

Nathan did a lot of name-lookup refactoring for modules but the core data
structures stayed the same I guess.

In the linear list walk a quite big chunk of the constant overhead is the
anon aggregate check:

static tree
fields_linear_search (tree klass, tree name, bool want_type)
{
  for (tree fields = TYPE_FIELDS (klass); fields; fields = DECL_CHAIN (fields))
{
  tree decl = fields;

  if (TREE_CODE (decl) == FIELD_DECL
  && ANON_AGGR_TYPE_P (TREE_TYPE (decl)))
{
  if (tree temp = search_anon_aggr (TREE_TYPE (decl), name, want_type))
return temp;
}

  if (DECL_NAME (decl) != name)
continue;

if there was a bit on the FIELD_DECL instead of the extra indirection that
would help this a lot (by a constant factor).

Of course a linear search should be a no-go ...

[Bug tree-optimization/101159] [12 Regression] ICE Segmentation fault since r12-1707-ge08a125b208e717f

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
No testcase for the testsuite?

[Bug middle-end/101160] [12 Regression] ICE in df_word_lr_local_compute, at df-problems.c:2962 since r12-1702-g7232f7c4c2d72743

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Status|NEW |ASSIGNED

--- Comment #3 from Jakub Jelinek  ---
Created attachment 51048
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51048=edit
gcc12-pr101160.patch

Untested fix.

[Bug c++/101163] slow compilation for huge classes (>20k members)

[rbuergel at web dot de via Gcc-bugs]

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

--- Comment #1 from René Bürgel  ---
-ftime-report for trunk-gcc says:
Time variable   usr   sys  wall
  GGC
 phase setup:   0.00 (  0%)   0.00 (  0%)   0.01 (  0%)
 1562k (  4%)
 phase parsing  :   4.75 (100%)   0.11 (100%)   5.09 (100%)
   36M ( 96%)
 |name lookup   :   4.51 ( 95%)   0.05 ( 45%)   4.76 ( 93%)
 2088k (  5%)
 garbage collection :   0.01 (  0%)   0.00 (  0%)   0.01 (  0%)
0  (  0%)
 preprocessing  :   0.04 (  1%)   0.05 ( 45%)   0.07 (  1%)
 4449k ( 12%)
 parser (global):   0.02 (  0%)   0.00 (  0%)   0.04 (  1%)
 3647k (  9%)
 parser struct body :   4.63 ( 97%)   0.05 ( 45%)   4.91 ( 96%)
 9128k ( 24%)
 symout :   0.05 (  1%)   0.01 (  9%)   0.06 (  1%)
   19M ( 51%)
 TOTAL  :   4.75  0.11  5.10   
   37M


It seems to be an issue in the name lookup, if I interpret that right...

[Bug middle-end/101160] [12 Regression] ICE in df_word_lr_local_compute, at df-problems.c:2962 since r12-1702-g7232f7c4c2d72743

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
x86_64 at least.
Before the change, the first function contained
(insn 12 3 13 2 (clobber (reg:TI 82 [  ])) "param3.C":12:1 -1
 (expr_list:REG_UNUSED (reg:TI 82 [  ])
(nil)))
(insn 13 12 9 2 (set (reg:TI 82 [  ])
(const_int 0 [0])) "param3.C":12:1 -1
 (nil))
(insn 9 13 10 2 (set (reg/i:TI 0 ax)
(reg:TI 82 [  ])) "param3.C":12:1 73 {*movti_internal}
 (expr_list:REG_DEAD (reg:TI 82 [  ])
(nil)))
(insn 10 9 0 2 (use (reg/i:TI 0 ax)) "param3.C":12:1 -1
 (nil))
in split1, now it has:
(insn 11 3 12 2 (clobber (reg:TI 82 [  ])) "param2.C":12:1 -1
 (expr_list:REG_UNUSED (reg:TI 82 [  ])
(nil)))
(insn 12 11 9 2 (set (reg:TI 82 [  ])
(const_int 0 [0])) "param2.C":12:1 -1
 (nil))
(insn 9 12 0 2 (use (reg:TI 82 [  ])) "param2.C":12:1 -1
 (nil))
instead and triggers the
2956  if (bb_index == EXIT_BLOCK)
2957{
2958  unsigned regno;
2959  bitmap_iterator bi;
2960  EXECUTE_IF_SET_IN_BITMAP (df->exit_block_uses,
FIRST_PSEUDO_REGISTER,
2961regno, bi)
2962gcc_unreachable ();
2963}
assertion because pseudo 82 is in df->exit_block_uses.

[Bug c++/101163] New: slow compilation for huge classes (>20k members)

[rbuergel at web dot de via Gcc-bugs]

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

Bug ID: 101163
   Summary: slow compilation for huge classes (>20k members)
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rbuergel at web dot de
  Target Milestone: ---

Created attachment 51047
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51047=edit
clean example

Hi,

we have a real-world-use-case using a class with ~20k member functions.
Compilation speed decreases awefully when just including that header in another
file: from 2 to 60 seconds.

we're using gcc-6.3 in production, but i tested other versions on
https://godbolt.org/

clang doesn't seem to have that problem, but it seems to be present in newer
gccs, too

[Bug tree-optimization/101162] [12 Regression] ICE (verify_gimple failed) for switch returning pointer-to-members since r12-1608

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

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 51046
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51046=edit
gcc12-pr101162.patch

Untested fix.

[Bug tree-optimization/101162] [12 Regression] ICE (verify_gimple failed) for switch returning pointer-to-members since r12-1608

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

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

--- Comment #2 from Andrew Pinski  ---
I was just about to assign this to myself as I had just came up with a fix:
diff --git a/gcc/fold-const.c b/gcc/fold-const.c
index 85e90f42b8e..5e4bdeace1e 100644
--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -5361,7 +5361,7 @@ range_check_type (tree etype)
   else
return NULL_TREE;
 }
-  else if (POINTER_TYPE_P (etype))
+  else if (POINTER_TYPE_P (etype) || TREE_CODE (etype) == OFFSET_TYPE)
 etype = unsigned_type_for (etype);
   return etype;
 }

[Bug tree-optimization/101162] [12 Regression] ICE (verify_gimple failed) for switch returning pointer-to-members

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 CC||jakub at gcc dot gnu.org
   Last reconfirmed||2021-06-22

[Bug target/83466] Wrong TLS GD sequence for ILP32

[dongjianqiang2 at huawei dot com via Gcc-bugs]

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

--- Comment #8 from John Dong  ---
Created attachment 51045
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51045=edit
patch to fix pr83466

patch to fix this issue for SYMBOL_SMALL_TLSDESC and SYMBOL_SMALL_TLSIE.

[Bug tree-optimization/101158] [10/11 Regression] ICE in gimple_call_arg, at gimple.h:3247

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|ICE in gimple_call_arg, at  |[10/11 Regression] ICE in
   |gimple.h:3247   |gimple_call_arg, at
   ||gimple.h:3247
   Priority|P3  |P2
   Target Milestone|--- |10.4
  Known to work||12.0

--- Comment #3 from Richard Biener  ---
Fixed on trunk, I think the issue is latent in GCC 11 and GCC 10.

[Bug tree-optimization/101159] [12 Regression] ICE Segmentation fault since r12-1707-ge08a125b208e717f

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Richard Biener  ---
Fixed.

[Bug other/86656] [meta-bug] Issues found with -fsanitize=address

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86656
Bug 86656 depends on bug 101154, which changed state.

Bug 101154 Summary: [12 Regression] AddressSanitizer: 
dynamic-stack-buffer-overflow on address: in vect_build_slp_tree_2 
../../gcc/tree-vect-slp.c:2039
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101154

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug tree-optimization/101154] [12 Regression] AddressSanitizer: dynamic-stack-buffer-overflow on address: in vect_build_slp_tree_2 ../../gcc/tree-vect-slp.c:2039

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Richard Biener  ---
Fixed.

[Bug tree-optimization/101158] ICE in gimple_call_arg, at gimple.h:3247

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:7a22d8a764418265680a6bb9a9aec31e984eb015

commit r12-1715-g7a22d8a764418265680a6bb9a9aec31e984eb015
Author: Richard Biener 
Date:   Tue Jun 22 09:24:24 2021 +0200

tree-optimization/101158 - adjust SLP call matching sequence

This moves the check for same operands after verifying we're
facing compatible calls.

2021-06-22  Richard Biener  

PR tree-optimization/101158
* tree-vect-slp.c (vect_build_slp_tree_1): Move same operand
checking after checking for matching operation.

* gfortran.dg/pr101158.f90: New testcase.

[Bug tree-optimization/101159] [12 Regression] ICE Segmentation fault since r12-1707-ge08a125b208e717f

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Richard Biener :

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

commit r12-1714-ga5b773d3f86dd4333696cab0fe3a6953d3db74a3
Author: Richard Biener 
Date:   Tue Jun 22 09:12:42 2021 +0200

tree-optimization/101159 - fix missing NULL check in popcount pattern

This fixes a missing check for a NULL vectype in the new popcount
pattern.

2021-06-22  Richard Biener  

PR tree-optimization/101159
* tree-vect-patterns.c (vect_recog_popcount_pattern): Add
missing NULL vectype check.

[Bug tree-optimization/101154] [12 Regression] AddressSanitizer: dynamic-stack-buffer-overflow on address: in vect_build_slp_tree_2 ../../gcc/tree-vect-slp.c:2039

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:26f05f5a823030ebb52b107a8c303d07f77fe317

commit r12-1713-g26f05f5a823030ebb52b107a8c303d07f77fe317
Author: Richard Biener 
Date:   Tue Jun 22 09:10:56 2021 +0200

tree-optimization/101154 - fix out-of bound access in SLP

This fixes an out-of-bound access of matches.

2021-06-22  Richard Biener  

PR tree-optimization/101154
* tree-vect-slp.c (vect_build_slp_tree_2): Fix out-of-bound access.

[Bug middle-end/101134] Bogus -Wstringop-overflow warning about non-existent overflow

[dangelog at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Giuseppe D'Angelo  ---
Could the warning messages then be changed to point out that the issue is only
a mere possibility? Using an "assertive" wording makes users believe that GCC
has positively and conclusively proved that there's something wrong, whilst
it's exactly the opposite (it didn't prove anything, and it's a false
positive).

Uninitialized warnings have this distinction and warn in two different ("may be
used uninitialized" vs "is used initialized"). If here the distinction cannot
be made, AND false positives are allowed to warn, I'd really prefer the "may be
overflowing" wording than the "is overflowing" existing one.

[Bug tree-optimization/101162] [12 Regression] ICE (verify_gimple failed) for switch returning pointer-to-members

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c++ |tree-optimization

--- Comment #1 from Andrew Pinski  ---
>This regression was introduced between 2021-06-14 and 2021-06-21.

I added the extra checks during that time period.
But the problem was latent before hand.  Multiplying on offset_type does not
make sense.

[Bug c++/101162] [12 Regression] ICE (verify_gimple failed) for switch returning pointer-to-members

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
 CC||pinskia at gcc dot gnu.org

[Bug c++/101162] New: [12 Regression] ICE (verify_gimple failed) for switch returning pointer-to-members

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

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

Bug ID: 101162
   Summary: [12 Regression] ICE (verify_gimple failed) for switch
returning pointer-to-members
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

The following valid testcase triggers an ICE on trunk when compiled with "-O2":

===
struct A
{
  int i1, i2, i3, i4, i5, i6;
};

int A::* foo(int i)
{
  switch (i)
  {
case 1: return ::i1;
case 2: return ::i2;
case 3: return ::i3;
case 4: return ::i4;
case 5: return ::i5;
case 6: return ::i6;
  }

  return 0;
}
===

bug.cc: In function 'int A::* foo(int)':
bug.cc:19:1: error: invalid types for 'mult_expr'
   19 | }
  | ^
<<< Unknown tree: offset_type >>>
<<< Unknown tree: offset_type >>>
<<< Unknown tree: offset_type >>>
_7 = 4 * _6;
during GIMPLE pass: switchconv
bug.cc:19:1: internal compiler error: verify_gimple failed
0x11025aa verify_gimple_in_cfg(function*, bool)
../../gcc/gcc/tree-cfg.c:5531
0xfe1587 execute_function_todo
../../gcc/gcc/passes.c:2042
0xfe1fab execute_todo
../../gcc/gcc/passes.c:2096
Please submit a full bug report, [etc.]

This regression was introduced between 2021-06-14 and 2021-06-21.

[Bug target/11877] gcc should use xor trick with -Os

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

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r12-1712-gd58a66aa0faa64bfbd85e528be5104293dd41d0e
Author: Jakub Jelinek 
Date:   Tue Jun 22 10:16:18 2021 +0200

i386: Use xor to write zero to memory with -Os even for more than 4 stores
[PR11877]

> > 2021-06-20  Roger Sayle  
> >
> > gcc/ChangeLog
> > PR target/11877
> > * config/i386/i386.md: New define_peephole2s to shrink writing
> > 1, 2 or 4 consecutive zeros to memory when optimizing for size.

It unfortunately doesn't extend well to larger memory clearing.
Consider e.g.
void
foo (int *p)
{
  p[0] = 0;
  p[7] = 0;
  p[23] = 0;
  p[41] = 0;
  p[48] = 0;
  p[59] = 0;
  p[69] = 0;
  p[78] = 0;
  p[83] = 0;
  p[89] = 0;
  p[98] = 0;
  p[121] = 0;
  p[132] = 0;
  p[143] = 0;
  p[154] = 0;
}
where with the patch we emit:
xorl%eax, %eax
xorl%edx, %edx
xorl%ecx, %ecx
xorl%esi, %esi
xorl%r8d, %r8d
movl%eax, (%rdi)
movl%eax, 28(%rdi)
movl%eax, 92(%rdi)
movl%eax, 164(%rdi)
movl%edx, 192(%rdi)
movl%edx, 236(%rdi)
movl%edx, 276(%rdi)
movl%edx, 312(%rdi)
movl%ecx, 332(%rdi)
movl%ecx, 356(%rdi)
movl%ecx, 392(%rdi)
movl%ecx, 484(%rdi)
movl%esi, 528(%rdi)
movl%esi, 572(%rdi)
movl%r8d, 616(%rdi)
Here is an incremental patch that emits:
xorl%eax, %eax
movl%eax, (%rdi)
movl%eax, 28(%rdi)
movl%eax, 92(%rdi)
movl%eax, 164(%rdi)
movl%eax, 192(%rdi)
movl%eax, 236(%rdi)
movl%eax, 276(%rdi)
movl%eax, 312(%rdi)
movl%eax, 332(%rdi)
movl%eax, 356(%rdi)
movl%eax, 392(%rdi)
movl%eax, 484(%rdi)
movl%eax, 528(%rdi)
movl%eax, 572(%rdi)
movl%eax, 616(%rdi)
instead.

2021-06-22  Jakub Jelinek  

PR target/11877
* config/i386/i386-protos.h (ix86_last_zero_store_uid): Declare.
* config/i386/i386-expand.c (ix86_last_zero_store_uid): New
variable.
* config/i386/i386.c (ix86_expand_prologue): Clear it.
* config/i386/i386.md (peephole2s for 1/2/4 stores of const0_rtx):
Remove "" from match_operand.  Emit new insns using emit_move_insn
and
set ix86_last_zero_store_uid to INSN_UID of the last store.
Add peephole2s for 1/2/4 stores of const0_rtx following previous
successful peep2s.

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

[Bug tree-optimization/101151] [11/12 Regression] ICE at -O1 and above on x86_64-linux-gnu: verify_ssa failed since r11-3705-gdae673abd37d4004

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

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

--- Comment #3 from Richard Biener  ---
The

  /* If the blocks are possibly within the same irreducible
 cycle the above check breaks down.  */

check is incomplete.  Testing fix.

[Bug c/101156] ICE: ‘verify_gimple’ failed, verify_gimple_in_seq(gimple*)

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

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

--- Comment #3 from Richard Biener  ---
OK, so the issue is we're calling gimplify_expr (, false /*allow_ssa*/)
on 'p--' and the gimplified sequence looks like the following on the pre_p
sequence:

 p.0_1 = p;
 p = p.0_1 + 18446744073709551612;

and the gimplify_expr result is just p.0_1.  Then we do

  /* Avoid the extra copy if possible.  */
  *expr_p = create_tmp_reg (TREE_TYPE (name));
  if (!gimple_nop_p (SSA_NAME_DEF_STMT (name)))
gimple_set_lhs (SSA_NAME_DEF_STMT (name), *expr_p);
  release_ssa_name (name);

but obviously that disregards that there's other uses of p.0_1 already.
I suppose the above might be premature optimization but I'm going to gather
some statistics on that I guess.

[Bug tree-optimization/101159] [12 Regression] ICE Segmentation fault since r12-1707-ge08a125b208e717f

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

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #3 from Richard Biener  ---
Will test that.

[Bug tree-optimization/101158] ICE in gimple_call_arg, at gimple.h:3247

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

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Last reconfirmed||2021-06-22
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Richard Biener  ---
I will have a look.

[Bug tree-optimization/101159] [12 Regression] ICE Segmentation fault since r12-1707-ge08a125b208e717f

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

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

--- Comment #2 from Andrew Pinski  ---
A simple patch to check the return value of get_vectype_for_scalar_type to make
sure it is non-null should fix the testcase and return NULL.

[Bug middle-end/101157] [12 regression] ICE compiling gcc.target/powerpc/stack-limit.c after r12-1702

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug c/101156] ICE: ‘verify_gimple’ failed, verify_gimple_in_seq(gimple*)

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

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #2 from Richard Biener  ---
I will have a look.

[Bug tree-optimization/101154] [12 Regression] AddressSanitizer: dynamic-stack-buffer-overflow on address: in vect_build_slp_tree_2 ../../gcc/tree-vect-slp.c:2039

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

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

--- Comment #2 from Martin Liška  ---
Good. Hope you can reproduce it. Tell me if you need bisection or not?

[Bug tree-optimization/101154] [12 Regression] AddressSanitizer: dynamic-stack-buffer-overflow on address: in vect_build_slp_tree_2 ../../gcc/tree-vect-slp.c:2039

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

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #1 from Richard Biener  ---
I will have a look.

[Bug target/101153] [12 regression] gcc.target/powerpc/float128-minmax.c fails after r12-1605

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug tree-optimization/101151] [11/12 Regression] ICE at -O1 and above on x86_64-linux-gnu: verify_ssa failed since r11-3705-gdae673abd37d4004

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
Version|unknown |11.1.1

--- Comment #2 from Richard Biener  ---
Meh.

[Bug tree-optimization/101159] [12 Regression] ICE Segmentation fault since r12-1707-ge08a125b208e717f

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||zsojka at seznam dot cz

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

[Bug tree-optimization/101161] [12 Regression] ICE: SIGSEGV in tree_class_check at -O3 during GIMPLE pass: slp

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 101159.

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

[Bug tree-optimization/101161] New: [12 Regression] ICE: SIGSEGV in tree_class_check at -O3 during GIMPLE pass: slp

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 101161
   Summary: [12 Regression] ICE: SIGSEGV in tree_class_check at
-O3 during GIMPLE pass: slp
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O3 testcase.c -wrapper valgrind,-q
==5080== Invalid read of size 2
==5080==at 0xDE26C2: tree_class_check (tree.h:3493)
==5080==by 0xDE26C2: direct_optab_supported_p(optab_tag,
std::pair, optimization_type) (internal-fn.c:3533)
==5080==by 0x1CCD7FE: vect_recog_popcount_pattern(vec_info*,
_stmt_vec_info*, tree_node**) (tree-vect-patterns.c:1388)
==5080==by 0x1CD088A: vect_pattern_recog_1(vec_info*, vect_recog_func*,
_stmt_vec_info*) (tree-vect-patterns.c:5584)
==5080==by 0x1CD7661: vect_pattern_recog(vec_info*)
(tree-vect-patterns.c:5742)
==5080==by 0x1340443: vect_slp_analyze_bb_1 (tree-vect-slp.c:5561)
==5080==by 0x1340443: vect_slp_region (tree-vect-slp.c:5669)
==5080==by 0x1340443: vect_slp_bbs(vec)
(tree-vect-slp.c:5819)
==5080==by 0x1342464: vect_slp_function(function*) (tree-vect-slp.c:5905)
==5080==by 0x1348982: (anonymous
namespace)::pass_slp_vectorize::execute(function*) (tree-vectorizer.c:1445)
==5080==by 0xF8EDC7: execute_one_pass(opt_pass*) (passes.c:2567)
==5080==by 0xF8F72F: execute_pass_list_1(opt_pass*) (passes.c:2656)
==5080==by 0xF8F741: execute_pass_list_1(opt_pass*) (passes.c:2657)
==5080==by 0xF8F741: execute_pass_list_1(opt_pass*) (passes.c:2657)
==5080==by 0xF8F768: execute_pass_list(function*, opt_pass*)
(passes.c:2667)
==5080==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==5080== 
during GIMPLE pass: slp
testcase.c: In function 'foo':
testcase.c:4:1: internal compiler error: Segmentation fault
4 | foo (__int128 i)
  | ^~~
0x108adbf crash_signal
/repo/gcc-trunk/gcc/toplev.c:327
0xde26c2 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
/repo/gcc-trunk/gcc/tree.h:3493
0xde26c2 direct_optab_supported_p
/repo/gcc-trunk/gcc/internal-fn.c:3533
0x1ccd7fe vect_recog_popcount_pattern
/repo/gcc-trunk/gcc/tree-vect-patterns.c:1388
0x1cd088a vect_pattern_recog_1
/repo/gcc-trunk/gcc/tree-vect-patterns.c:5584
0x1cd7661 vect_pattern_recog(vec_info*)
/repo/gcc-trunk/gcc/tree-vect-patterns.c:5742
0x1340443 vect_slp_analyze_bb_1
/repo/gcc-trunk/gcc/tree-vect-slp.c:5561
0x1340443 vect_slp_region
/repo/gcc-trunk/gcc/tree-vect-slp.c:5669
0x1340443 vect_slp_bbs
/repo/gcc-trunk/gcc/tree-vect-slp.c:5819
0x1342464 vect_slp_function(function*)
/repo/gcc-trunk/gcc/tree-vect-slp.c:5905
0x1348982 execute
/repo/gcc-trunk/gcc/tree-vectorizer.c:1445
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ 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-r12-1707-20210622104011-ge08a125b208-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.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-r12-1707-20210622104011-ge08a125b208-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20210622 (experimental) (GCC)

[Bug c/101108] ICE: segmentation fault: gimplify_target_expr, gimplify.c:6760

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2021-06-22
 Status|UNCONFIRMED |NEW

--- Comment #1 from Martin Liška  ---
Confirmed, old issue.

[Bug analyzer/101143] [12 Regression] ICE: incompatible types: 'unsigned int' and 'long unsigned int'

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-06-22
 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Started with r12-1481-g9a2c9579fdbf5d24.

[Bug middle-end/101157] [12 regression] ICE compiling gcc.target/powerpc/stack-limit.c after r12-1702

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

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Martin Liška from comment #1)
> Likely dup of PR101160.

No I doubt it.  Both might be exposed two different latent bugs.  The
df_ref_record hunk looks like it is catching latent bugs really.

[Bug middle-end/101160] [12 Regression] ICE in df_word_lr_local_compute, at df-problems.c:2962 since r12-1702-g7232f7c4c2d72743

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

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

--- Comment #1 from Andrew Pinski  ---
What target?

[Bug tree-optimization/101151] [11/12 Regression] ICE at -O1 and above on x86_64-linux-gnu: verify_ssa failed since r11-3705-gdae673abd37d4004

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

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |11.2
 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-06-22
Summary|ICE at -O1 and above on |[11/12 Regression] ICE at
   |x86_64-linux-gnu:   |-O1 and above on
   |verify_ssa failed   |x86_64-linux-gnu:
   ||verify_ssa failed since
   ||r11-3705-gdae673abd37d4004

--- Comment #1 from Martin Liška  ---
Started with r11-3705-gdae673abd37d4004.