[Bug middle-end/105204] -Wuse-after-free=1 inconsistency with conditional free

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||rguenth at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
The diagnostic is confused about a PRE where we transform

   [local count: 1073741824]:
  _8 = MEM[(const struct shared_ptr &)sp_2(D)].ref_count;
  _9 = *_8;
  _20 = _9 + 1;
  *_8 = _20;
  if (_20 == 0)
goto ; [33.00%]
  else
goto ; [67.00%]

   [local count: 354334800]:
  free (_8);

   [local count: 1073741824]:
  _16 = *_8;
  _17 = _16 + 18446744073709551615;
  *_8 = _17;

to

   [local count: 1073741824]:
  _8 = MEM[(const struct shared_ptr &)sp_2(D)].ref_count;
  _9 = *_8;
  _20 = _9 + 1;
  *_8 = _20;
  if (_20 == 0)
goto ; [33.00%]
  else
goto ; [67.00%]

   [local count: 354334800]:
  free (_8);
  pretmp_5 = *_8;
  _25 = pretmp_5 + 18446744073709551615;

   [local count: 1073741824]:
  # prephitmp_10 = PHI <_9(2), _25(3)>
  *_8 = prephitmp_10;

I think this is both a missed diagnostic without PRE (the free () falls
through to a dereference to the freed pointer) and a missed optimization
where the

  _8 = MEM[(const struct shared_ptr &)sp_2(D)].ref_count;
  _9 = *_8;
  _20 = _9 + 1;
  *_8 = _20;
  if (_20 == 0)

test is not constant folded.  Note this is because your code is not
resilent against overflow of ref_count and also not resilent against
a ref_count of zero incoming into the copy ctor.  The latter is what
provokes the diagnostic in the end and also causes the missed
optimization.

changing the CTOR to sth like

shared_ptr(const shared_ptr& other) : ref_count(other.ref_count) {
if (*ref_count == 0)
  __builtin_unreachable ();
(*ref_count)++;
}

avoids the diagnostic and optimizes the example3 to an empty function
(since we never will need to free the reference count).

So what this bug shows is a missed diagnostic without PRE, but otherwise
it works as expected.

[Bug target/104613] ICE in dwarf2out_frame_debug_adjust_cfa, at dwarf2cfi.c:1189

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2022-04-11
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #3 from Martin Liška  ---
Any update on this, please?

[Bug middle-end/105206] mis-optimization with -ffast-math and __builtin_powf

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
   Keywords||missed-optimization
 Ever confirmed|0   |1
   Last reconfirmed||2022-04-11
 Status|UNCONFIRMED |WAITING

--- Comment #2 from Richard Biener  ---
Hm, it works for me on linux with glibc, can you be more specific as to what
OS/libc (version) you are using?

foof:
.LFB0:
.cfi_startproc
mulss   .LC0(%rip), %xmm0
jmp expf

food:
.LFB1:
.cfi_startproc
mulsd   .LC1(%rip), %xmm0
jmp exp

[Bug target/105215] New: IA64: ICE on openssl-1.1.1n in create_block_for_bookkeeping, at sel-sched.cc:4549 -O3 -g3

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

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

Bug ID: 105215
   Summary: IA64: ICE on openssl-1.1.1n in
create_block_for_bookkeeping, at sel-sched.cc:4549 -O3
-g3
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at gcc dot gnu.org
  Target Milestone: ---
Target: ia64-unknown-linux-gnu

Not sure yet if a regression or not. Also not sure if it's an ia64-specific
failure of more generic problem. We have a few similar bugs on other targets.

Reduced reproducer:

int OPENSSL_sk_push();
void ERR_put_error();
typedef struct {
  int modified;
} ASN1_ENCODING;
int sk_X509_REVOKED_push(int *sk) {
  int ptr = 0;
  return OPENSSL_sk_push(sk, ptr);
}
struct X509_crl_info_st {
  int *revoked;
  ASN1_ENCODING enc;
} X509_CRL_add0_revoked_crl;
int X509_CRL_add0_revoked() {
  struct X509_crl_info_st *inf = &X509_CRL_add0_revoked_crl;
  if (inf->revoked == 0)
ERR_put_error();
  if (inf->revoked == 0 || sk_X509_REVOKED_push(inf->revoked)) {
ERR_put_error(0, 0, "");
return 0;
  }
  inf->enc.modified = 1;
  return 1;
}

$ ia64-unknown-linux-gnu-gcc -Wall -O3 -c x_crl.o.c -o bug.o -g2
during RTL pass: mach
x_crl.o.c: In function 'X509_CRL_add0_revoked':
x_crl.o.c:25:1: internal compiler error: in create_block_for_bookkeeping, at
sel-sched.cc:4549
   25 | }
  | ^
0x684775 create_block_for_bookkeeping
../../gcc-12-20220410/gcc/sel-sched.cc:4549
0x684775 find_place_for_bookkeeping
../../gcc-12-20220410/gcc/sel-sched.cc:4686
0x684775 generate_bookkeeping_insn
../../gcc-12-20220410/gcc/sel-sched.cc:4786
0x684775 move_op_at_first_insn
../../gcc-12-20220410/gcc/sel-sched.cc:6063
0xdbb488 code_motion_path_driver
../../gcc-12-20220410/gcc/sel-sched.cc:6657
0xdbb856 code_motion_process_successors
../../gcc-12-20220410/gcc/sel-sched.cc:6342
0xdbb856 code_motion_path_driver
../../gcc-12-20220410/gcc/sel-sched.cc:6608
0xdbbf48 move_op
../../gcc-12-20220410/gcc/sel-sched.cc:6702
0xdbbf48 move_exprs_to_boundary
../../gcc-12-20220410/gcc/sel-sched.cc:5223
0xdbbf48 schedule_expr_on_boundary
../../gcc-12-20220410/gcc/sel-sched.cc:5436
0xdbf843 fill_insns
../../gcc-12-20220410/gcc/sel-sched.cc:5578
0xdbf843 schedule_on_fences
../../gcc-12-20220410/gcc/sel-sched.cc:7353
0xdbf843 sel_sched_region_2
../../gcc-12-20220410/gcc/sel-sched.cc:7491
0xdc0cc6 sel_sched_region_1
../../gcc-12-20220410/gcc/sel-sched.cc:7533
0xdc22fb sel_sched_region(int)
../../gcc-12-20220410/gcc/sel-sched.cc:7634
0xdc22fb sel_sched_region(int)
../../gcc-12-20220410/gcc/sel-sched.cc:7619
0xdc24d9 run_selective_scheduling()
../../gcc-12-20220410/gcc/sel-sched.cc:7720
0x1163d7c ia64_reorg
../../gcc-12-20220410/gcc/config/ia64/ia64.cc:9859
0xd8e909 execute
../../gcc-12-20220410/gcc/reorg.cc:3927

$ ia64-unknown-linux-gnu-gcc -v |& unnix
Using built-in specs.
COLLECT_GCC=/<>/ia64-unknown-linux-gnu-stage-final-gcc-debug-12.0.0/bin/ia64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/<>/ia64-unknown-linux-gnu-stage-final-gcc-debug-12.0.0/libexec/gcc/ia64-unknown-linux-gnu/12.0.1/lto-wrapper
Target: ia64-unknown-linux-gnu
Configured with:
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.1 20220410 (experimental) (GCC)

[Bug target/105209] internal compiler error: in store_data_bypass_p_1

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to fail||10.3.1, 12.0
   Last reconfirmed||2022-04-11
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

(gdb) p debug_rtx (out_insn)
(insn 37 36 38 5 (parallel [
(set (reg:DI 93)
(plus:DI (reg:DI 71 [ _3 ])
(reg:DI 82 [ _25 ])))
(trap_if (ne (plus:TI (sign_extend:TI (reg:DI 71 [ _3 ]))
(sign_extend:TI (reg:DI 82 [ _25 ])))
(sign_extend:TI (plus:DI (reg:DI 71 [ _3 ])
(reg:DI 82 [ _25 ]
(const_int 0 [0]))
]) "t.c":21:24 13 {addvdi3}
 (expr_list:REG_DEAD (reg:DI 82 [ _25 ])
(expr_list:REG_DEAD (reg:DI 71 [ _3 ])
(nil

looks like store_data_bypass_p_1 does not handle trap_if in PATTERN.

#1  0x0124c228 in store_data_bypass_p_1 (out_insn=0x76522980, 
in_set=0x7663d948) at /home/rguenther/src/trunk/gcc/recog.cc:4233
#2  0x0124c29e in store_data_bypass_p (out_insn=0x76522980, 
in_insn=0x765229c0) at /home/rguenther/src/trunk/gcc/recog.cc:4251
#3  0x01ddc520 in internal_insn_latency (insn_code=9, insn2_code=2, 
insn=0x76522980, insn2=0x765229c0) at insn-automata.cc:3171
#4  0x01ddc9a4 in insn_latency (insn=0x76522980, 
insn2=0x765229c0) at insn-automata.cc:3382
#5  0x01f5aec9 in dep_cost_1 (link=0x2d8af28, dw=0)
at /home/rguenther/src/trunk/gcc/haifa-sched.cc:1488
#6  0x01f5af4e in dep_cost (link=0x2d8af28)
at /home/rguenther/src/trunk/gcc/haifa-sched.cc:1510
#7  0x01f5b46a in priority (insn=0x76522980, force_recompute=false)
at /home/rguenther/src/trunk/gcc/haifa-sched.cc:1661
#8  0x01f6871d in set_priorities (head=0x76522900, 
tail=0x765223c0) at /home/rguenther/src/trunk/gcc/haifa-sched.cc:7166
#9  0x012b9868 in compute_priorities ()
at /home/rguenther/src/trunk/gcc/sched-rgn.cc:3025

note that this is likely an error in the alpha machine description which
uses store_data_bypass_p in the ev4 pipeline description and wrongly(?)
tags addvsi3 with such part of the pipeline.

[Bug target/105213] Extend __builtin_{un,}pack_{longdouble,ibm128} valid for soft-float

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

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

Richard Biener  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug target/105214] [12 Regression] ICE: in connect_traces, at dwarf2cfi.cc:3074 with custom flags

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug rtl-optimization/105203] [11/12 Regression] '-fcompare-debug' failure w/ -O2 -ftracer -fPIC since r11-3078-g69ca5f3a988266da

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

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

--- Comment #6 from Martin Liška  ---
@Segher: Have you tried running it on x86_64-linux-gnu?

gcc -O2 -fcompare-debug -ftracer -fPIC -w -c
gcc/testsuite/gfortran.dg/g77/pr9258.f --save-temps --verbose
Using built-in specs.
COLLECT_GCC=gcc
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,ada,go,d,jit
--enable-offload-targets=nvptx-none,amdgcn-amdhsa, --without-cuda-driver
--enable-host-shared --enable-checking=release --disable-werror
--with-gxx-include-dir=/usr/include/c++/11 --enable-ssp --disable-libssp
--disable-libvtv --enable-cet=auto --disable-libcc1 --enable-plugin
--with-bugurl=https://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--with-slibdir=/lib64 --with-system-zlib --enable-libstdcxx-allocator=new
--disable-libstdcxx-pch --enable-libphobos
--enable-version-specific-runtime-libs --with-gcc-major-version-only
--enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function
--program-suffix=-11 --without-system-libunwind --enable-multilib
--with-arch-32=x86-64 --with-tune=generic
--with-build-config=bootstrap-lto-lean --enable-link-mutex
--build=x86_64-suse-linux --host=x86_64-suse-linux
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.1 20220316 [revision 6a1150d1524aeda3381b2171712e1a6611d441d6]
(SUSE Linux) 
COLLECT_GCC_OPTIONS='-O2' '-fcompare-debug=-gtoggle' '-ftracer' '-fPIC' '-w'
'-c' '-save-temps' '-v' '-mtune=generic' '-march=x86-64'
 /usr/lib64/gcc/x86_64-suse-linux/11/f951
gcc/testsuite/gfortran.dg/g77/pr9258.f -ffixed-form -quiet -dumpbase pr9258.f
-dumpbase-ext .f -mtune=generic -march=x86-64 -O2 -w -version
-fcompare-debug=-gtoggle -ftracer -fPIC -fintrinsic-modules-path
/usr/lib64/gcc/x86_64-suse-linux/11/finclude
-fpre-include=/usr/include/finclude/math-vector-fortran.h
-frandom-seed=0x56af55577b39fac1 -fdump-final-insns=pr9258.f.gkd -o pr9258.s
GNU Fortran (SUSE Linux) version 11.2.1 20220316 [revision
6a1150d1524aeda3381b2171712e1a6611d441d6] (x86_64-suse-linux)
compiled by GNU C version 11.2.1 20220316 [revision
6a1150d1524aeda3381b2171712e1a6611d441d6], GMP version 6.2.1, MPFR version
4.1.0-p7, MPC version 1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2008 (SUSE Linux) version 11.2.1 20220316 [revision
6a1150d1524aeda3381b2171712e1a6611d441d6] (x86_64-suse-linux)
compiled by GNU C version 11.2.1 20220316 [revision
6a1150d1524aeda3381b2171712e1a6611d441d6], GMP version 6.2.1, MPFR version
4.1.0-p7, MPC version 1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
COLLECT_GCC_OPTIONS='-O2' '-fcompare-debug=-gtoggle' '-ftracer' '-fPIC' '-w'
'-c' '-save-temps' '-v' '-mtune=generic' '-march=x86-64'
 /usr/lib64/gcc/x86_64-suse-linux/11/../../../../x86_64-suse-linux/bin/as -v -W
--64 -o pr9258.o pr9258.s
GNU assembler version 2.38 (x86_64-suse-linux) using BFD version (GNU Binutils;
openSUSE Tumbleweed) 2.38.20220304-3
gcc: note: recompiling with ‘-fcompare-debug’
COLLECT_GCC_OPTIONS='-O2' '-fcompare-debug=-gtoggle' '-ftracer' '-fPIC' '-w'
'-c' '-save-temps' '-v' '-mtune=generic' '-march=x86-64' '-w' '-S' '-o'
'/dev/null' '-fcompare-debug-second' '-gtoggle'
 /usr/lib64/gcc/x86_64-suse-linux/11/f951
gcc/testsuite/gfortran.dg/g77/pr9258.f -ffixed-form -quiet -dumpbase
pr9258.gk.f -dumpbase-ext .f -mtune=generic -march=x86-64 -gtoggle -O2 -w -w
-version -fcompare-debug=-gtoggle -ftracer -fPIC -fcompare-debug-second -o
/dev/null -fintrinsic-modules-path /usr/lib64/gcc/x86_64-suse-linux/11/finclude
-fpre-include=/usr/include/finclude/math-vector-fortran.h
-frandom-seed=0x56af55577b39fac1 -fdump-final-insns=pr9258.gk.f.gkd
GNU Fortran (SUSE Linux) version 11.2.1 20220316 [revision
6a1150d1524aeda3381b2171712e1a6611d441d6] (x86_64-suse-linux)
compiled by GNU C version 11.2.1 20220316 [revision
6a1150d1524aeda3381b2171712e1a6611d441d6], GMP version 6.2.1, MPFR version
4.1.0-p7, MPC version 1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2008 (SUSE Linux) version 11.2.1 20220316 [revision
6a1150d1524aeda3381b2171712e1a6611d441d6] (x86_64-suse-linux)
compiled by GNU C version 11.2.1 20220316 [revision
6a1150d1524aeda3381b2171712e1a6611d441d6], GMP version 6.2.1, MPFR version
4.1.0-p7, MPC version 1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
gcc: note: comparing final insns dumps
gcc: error: gcc/testsuite/gfortran.dg/g77/pr9258.f: ‘-fcompare-debug’ failure

[Bug tree-optimization/105216] New: [12 regression] 8% regression for m-queens compared to gcc11 O2

[crazylht at gmail dot com via Gcc-bugs]

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

Bug ID: 105216
   Summary: [12 regression] 8% regression for m-queens compared to
gcc11 O2
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: crazylht at gmail dot com
  Target Milestone: ---

Created attachment 52778
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52778&action=edit
g++ -O2 main.c;./a.out

Regression happens in pass_pre

  while (posib != UINT_FAST32_MAX) {
// The standard trick for getting the rightmost bit in the mask
uint_fast32_t bit = ~posib & (posib + 1);
posib ^= bit; // Eliminate the tried possibility.
uint_fast32_t new_diagl = (bit << 1) | diagl_shifted;
uint_fast32_t new_diagr = (bit >> 1) | diagr_shifted;
bit |= cols[d];
uint_fast32_t new_posib = (bit | new_diagl | new_diagr);

if (new_posib != UINT_FAST32_MAX) {
uint_fast32_t lookahead1 = (bit | (new_diagl << (LOOKAHEAD - 2)) |
(new_diagr >> (LOOKAHEAD - 2)));
uint_fast32_t lookahead2 = (bit | (new_diagl << (LOOKAHEAD - 1)) |
(new_diagr >> (LOOKAHEAD - 1)));
uint_fast32_t allowed2 = l_rest > (int8_t)0;

if(allowed2 && ((lookahead2 == UINT_FAST32_MAX) || (lookahead1 ==
UINT_FAST32_MAX))) {
continue;
}


  if(l_rest == (STORE_LEVEL + 1)) {
start_level4[level4_cnt][0] = bit;   // cols
start_level4[level4_cnt][1] = new_diagl; // diagl
start_level4[level4_cnt][2] = new_diagr; // diagr
level4_cnt++;
continue;
  }

  l_rest--;

  // The next two lines save stack depth + backtrack operations
  // when we passed the last possibility in a row.
  // Go lower in the stack, avoid branching by writing above the
current
  // position
  posibs[d] = posib;
  d += posib != UINT_FAST32_MAX; // avoid branching with this trick
  posib = new_posib;


  // make values current
  cols[d] = bit;
  diagl[d] = new_diagl;
  diagr[d] = new_diagr;
  rest[d] = l_rest;
  diagl_shifted = new_diagl << 1;
  diagr_shifted = new_diagr >> 1;
}
  }
  d--;
  posib = posibs[d]; // backtrack ...
}

For bit |= cols[d]; cols[d] is loop invariant if loop latch from *continue*,
GCC11 catches it, GCC12 not.

[Bug target/105197] [12 Regression] SVE: wrong code with -O -ftree-vectorize

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

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

--- Comment #4 from Richard Biener  ---
The following improves the output from if-conversion by simplifying ~cond ? a :
b
to cond ? b : a, possibly reducing the number of conds.  Ideally if-conversion
would track predicates in a more concious way of course.

diff --git a/gcc/tree-if-conv.cc b/gcc/tree-if-conv.cc
index 7495ed653c0..dd3d5255a38 100644
--- a/gcc/tree-if-conv.cc
+++ b/gcc/tree-if-conv.cc
@@ -472,6 +472,14 @@ fold_build_cond_expr (tree type, tree cond, tree rhs, tree
lhs)
  && (integer_zerop (op1)))
cond = op0;
 }
+  gassign *ass;
+  if (TREE_CODE (cond) == SSA_NAME
+  && (ass = dyn_cast  (SSA_NAME_DEF_STMT (cond)))
+  && gimple_assign_rhs_code (ass) == BIT_NOT_EXPR)
+{
+  cond = gimple_assign_rhs1 (ass);
+  std::swap (rhs, lhs);
+}
   cond_expr = fold_ternary (COND_EXPR, type, cond, rhs, lhs);

   if (cond_expr == NULL_TREE)

[Bug tree-optimization/105216] [12 regression] 8% regression for m-queens compared to gcc11 O2

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

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

--- Comment #1 from Andrew Pinski  ---
Does -fno-tree-vectorizer help? There is definitely another big recording the
fact pre had to turn something off while vectorization is turned on.

[Bug gcov-profile/105210] gcc/auto-profile.cc:391:11: warning: variable 'level' set but not used

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2022-04-11

--- Comment #6 from Martin Liška  ---
I'm going to prepare a patch for next stage 1.

[Bug tree-optimization/105216] [12 regression] 8% regression for m-queens compared to gcc11 O2

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |12.0
   Last reconfirmed||2022-04-11
   Keywords||missed-optimization,
   ||needs-bisection
 Target||x86_64-*-*
 CC||rguenth at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
I suppose it's good again with -fno-tree-vectorize?  With vectorization enabled
we tame down PRE to avoid creating loop carried dependences the vectorizer
cannot handle.  For the "important" opportunities we try to recover after
vectorization with predictive commoning.

Hmm, confirmed with -fno-tree-vectorize even.

Possibly caused by r12-7389-ge25dce50133405

[Bug tree-optimization/105216] [12 regression] 8% regression for m-queens compared to gcc11 O2

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Hongtao.liu  ---
(In reply to Andrew Pinski from comment #1)
> Does -fno-tree-vectorizer help? There is definitely another big recording
> the fact pre had to turn something off while vectorization is turned on.

No, not related to O2 vectorizer.

[Bug tree-optimization/105216] [12 regression] 8% regression for m-queens compared to gcc11 O2

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

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

--- Comment #4 from Richard Biener  ---
(In reply to Richard Biener from comment #2)
> I suppose it's good again with -fno-tree-vectorize?  With vectorization
> enabled we tame down PRE to avoid creating loop carried dependences the
> vectorizer cannot handle.  For the "important" opportunities we try to
> recover after vectorization with predictive commoning.
> 
> Hmm, confirmed with -fno-tree-vectorize even.
> 
> Possibly caused by r12-7389-ge25dce50133405

Nope, reverting that doesn't fix it.

Note it seems the GCC 11 branch head also regressed compared to
r11-8866-g056e324ce46a79 but not as much as trunk.  Note I can reproduce
~2% regression from that 11 branch rev on the branch and ~4% towards trunk
so it's also a bit noisy.

[Bug c++/105186] [9/10/11/12 Regression] ICE in canonicalize_attr_name, at attribs.h:146

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

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

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

https://gcc.gnu.org/g:083e8e66d2e90992fa83a53bfc3553dfa91abda1

commit r12-8077-g083e8e66d2e90992fa83a53bfc3553dfa91abda1
Author: Jakub Jelinek 
Date:   Mon Apr 11 10:41:07 2022 +0200

c-family: Initialize ridpointers for __int128 etc. [PR105186]

The following testcase ICEs with C++ and is incorrectly rejected with C.
The reason is that both FEs use ridpointers identifiers for CPP_KEYWORD
and value or u.value for CPP_NAME e.g. when parsing attributes or OpenMP
directives etc., like:
 /* Save away the identifier that indicates which attribute
this is.  */
 identifier = (token->type == CPP_KEYWORD)
   /* For keywords, use the canonical spelling, not the
  parsed identifier.  */
   ? ridpointers[(int) token->keyword]
   : id_token->u.value;

 identifier = canonicalize_attr_name (identifier);
I've tried to change those to use ridpointers only if non-NULL and
otherwise
use the value/u.value even for CPP_KEYWORDS, but that was a large 10 hunks
patch.

The following patch instead just initializes ridpointers for the __intNN
keywords.  It can't be done earlier before we record_builtin_type as there
are 2 different spellings and if we initialize those ridpointers early, the
second record_builtin_type fails miserably.

2022-04-11  Jakub Jelinek  

PR c++/105186
* c-common.cc (c_common_nodes_and_builtins): After registering
__int%d
and __int%d__ builtin types, initialize corresponding ridpointers
entry.

* c-c++-common/pr105186.c: New test.

[Bug tree-optimization/104639] [12 Regression] Useless loop not fully optimized anymore

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

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

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

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

commit r12-8078-ga42aa68bf1ad745a6b36ab9beed1fc2e77ac3f88
Author: Jakub Jelinek 
Date:   Mon Apr 11 10:44:28 2022 +0200

phiopt: Optimize (x != cst1 ? x : cst2) != cst3 [PR104639]

Here is an attempt to resolve a P1 regression, where due to threading
changes we no longer optimize
bool foo(int i) {
while (i == 4)
i += 2;
return i;
}
to just return i != 0; by enhancing the phiopt value_replacement
optimization.  Normally it will optimize x != cst1 ? x : cst1 to x.
Here we extend it to also optimize x != cst1 ? x : cst2 to x if
it (phi result) has a single immediate use which is a comparison
with some INTEGER_CST cst3 and we can prove that we don't care
whether x is cst1 or cst2 because both compare the same against cst3.

2022-04-11  Jakub Jelinek  

PR tree-optimization/104639
* tree-ssa-phiopt.cc: Include tree-ssa-propagate.h.
(value_replacement): Optimize (x != cst1 ? x : cst2) != cst3
into x != cst3.

* gcc.dg/tree-ssa/pr104639-1.c: New test.
* gcc.dg/tree-ssa/pr104639-2.c: New test.

[Bug tree-optimization/104639] [12 Regression] Useless loop not fully optimized anymore

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #15 from Jakub Jelinek  ---
Regression fixed, but for GCC 13 we as Richi noted we want some better
approach.

[Bug c++/105186] [9/10/11 Regression] ICE in canonicalize_attr_name, at attribs.h:146

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[9/10/11/12 Regression] ICE |[9/10/11 Regression] ICE in
   |in canonicalize_attr_name,  |canonicalize_attr_name, at
   |at attribs.h:146|attribs.h:146

--- Comment #5 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug target/102772] [12 regression] g++.dg/torture/pr80334.C FAILs

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

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

--- Comment #45 from Jakub Jelinek  ---
I'd like to ping the #c44 question.  Thanks.

[Bug rtl-optimization/105211] ICE: SIGSEGV in contains_struct_check (tree.h:3570) with -Os -ffast-math and __builtin_roundf()

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 52779
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52779&action=edit
gcc12-pr105211.patch

Untested fix.

[Bug tree-optimization/105216] [12 regression] 8% regression for m-queens compared to gcc11 O2 on CLX.

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Hongtao.liu  ---
My bisect shows it's caused by
r12-3876-g4a960d548b7d7d942f316c5295f6d849b74214f5

[Bug tree-optimization/105216] [12 regression] 8% regression for m-queens compared to gcc11 O2 on CLX.

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Hongtao.liu  ---
(In reply to Hongtao.liu from comment #5)
> My bisect shows it's caused by
> r12-3876-g4a960d548b7d7d942f316c5295f6d849b74214f5

pre dump before vs after

-goto ; [11.00%]
-
-   [local count: 105119324]:
-  pretmp_379 = cols[d_243];  miss optimization here.
-
-   [local count: 955630226]:
-  # level4_cnt_250 = PHI 
-  # d_252 = PHI 
-  # posib_254 = PHI 
-  # diagl_shifted_255 = PHI 
-  # diagr_shifted_256 = PHI 
-  # l_rest_257 = PHI 
-  # prephitmp_380 = PHI 
+goto ; [11.00%]
+
+   [local count: 955630226]:
+  # level4_cnt_250 = PHI 
+  # d_252 = PHI 
+  # posib_254 = PHI 
+  # diagl_shifted_255 = PHI 
+  # diagr_shifted_256 = PHI 
+  # l_rest_257 = PHI 
   _30 = ~posib_254;
   _31 = posib_254 + 1;
   bit_189 = _30 & _31;
@@ -1030,15 +1037,16 @@ uint64_t nqueens (uint_fast8_t n)
   new_diagl_191 = _32 | diagl_shifted_255;
   _33 = bit_189 >> 1;
   new_diagr_192 = _33 | diagr_shifted_256;
-  bit_193 = bit_189 | prephitmp_380;
+  _34 = cols[d_252];
+  bit_193 = _34 | bit_189;

[Bug tree-optimization/105216] [12 regression] 8% regression for m-queens compared to gcc11 O2 on CLX.

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #7 from rguenther at suse dot de  ---
On Mon, 11 Apr 2022, crazylht at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105216
> 
> --- Comment #5 from Hongtao.liu  ---
> My bisect shows it's caused by
> r12-3876-g4a960d548b7d7d942f316c5295f6d849b74214f5

So it's a missed jump threading - care to investigate which?

[Bug target/105214] [12 Regression] ICE: in connect_traces, at dwarf2cfi.cc:3074 with custom flags

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Priority|P3  |P1
 Ever confirmed|0   |1
   Last reconfirmed||2022-04-11
 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
With r12-3221-g1313111fdec0d0de4228b5e839ca728b3e4b106e this started to ICE:
pr105214.c: In function ‘foo’:
pr105214.c:5:1: error: dead statement in EH table
5 | foo (void)
  | ^~~
# _7 = VDEF <.MEM_5>
_8 = __builtin_alloca_with_align (6400, 32);
during GIMPLE pass: asan
pr105214.c:5:1: internal compiler error: verify_gimple failed
0x13781be verify_gimple_in_cfg(function*, bool)
../../gcc/tree-cfg.c:5531
0x11bebdf execute_function_todo
../../gcc/passes.c:2042
0x11bdb7b do_per_function
../../gcc/passes.c:1687
0x11bedcf execute_todo
../../gcc/passes.c:2096
and with r12-7214-gf0c7367b8802c47efaad87b1f2126fe6350d8b47
that turned into the connect_traces ICE.

[Bug rtl-optimization/85409] [9/10/11/12 Regression] ICE in alloc_succs_info, at sel-sched-ir.c:4730

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

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

Jiu Fu Guo  changed:

   What|Removed |Added

 CC||guojiufu at gcc dot gnu.org

--- Comment #9 from Jiu Fu Guo  ---
The latest trunk has fixed this issue. As check the fix is r11-321
998fbe9f1f7e5ef53ca79fbd28f8a3875a477baa.  This fix is handling the debug_insn
which was also mentioned in comment 4.

Just wondering if need to backport to gcc10/9.

[Bug target/105209] internal compiler error: in store_data_bypass_p_1

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Uroš Bizjak  ---
Created attachment 52780
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52780&action=edit
Proposed patch

This patch introduces alpha-specific version of store_data_bypass_p that
ignores TRAP_IF that would result in assertion failure (and internal compiler
error)
in the generic store_data_bypass_p function.

While at it, also remove ev4_ist_c reservation, store_data_bypass_p can handle
the patterns with multiple sets since some time ago.

The patch is only compile tested, someone should at least bootstrap and
regression test it on alpha target.

[Bug tree-optimization/105216] [12 regression] 8% regression for m-queens compared to gcc11 O2 on CLX.

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Hongtao.liu  ---
(In reply to rguent...@suse.de from comment #7)
> On Mon, 11 Apr 2022, crazylht at gmail dot com wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105216
> > 
> > --- Comment #5 from Hongtao.liu  ---
> > My bisect shows it's caused by
> > r12-3876-g4a960d548b7d7d942f316c5295f6d849b74214f5
> 
> So it's a missed jump threading - care to investigate which?

The commit is about jump threading, but the regression is present without
-fopenmp， so there's no jump threading?
Somehow it affects PRE.

[Bug sanitizer/105214] [12 Regression] ICE: in connect_traces, at dwarf2cfi.cc:3074 with custom flags

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||dodji at gcc dot gnu.org,
   ||dvyukov at gcc dot gnu.org,
   ||kcc at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
  Component|target  |sanitizer

--- Comment #2 from Richard Biener  ---
I can take a look if you are not working on it.

[Bug sanitizer/105214] [12 Regression] ICE: in connect_traces, at dwarf2cfi.cc:3074 with custom flags

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

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

--- Comment #3 from Richard Biener  ---
possibly started earlier if you also add -fexceptions

[Bug target/105214] [12 Regression] ICE: in connect_traces, at dwarf2cfi.cc:3074 with custom flags

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

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

Richard Biener  changed:

   What|Removed |Added

  Component|sanitizer   |target

--- Comment #4 from Richard Biener  ---
oh, no - misread the bisect

[Bug tree-optimization/105216] [12 regression] 8% regression for m-queens compared to gcc11 O2 on CLX.

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Hongtao.liu  ---
(In reply to Hongtao.liu from comment #8)
> (In reply to rguent...@suse.de from comment #7)
> > On Mon, 11 Apr 2022, crazylht at gmail dot com wrote:
> > 
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105216
> > > 
> > > --- Comment #5 from Hongtao.liu  ---
> > > My bisect shows it's caused by
> > > r12-3876-g4a960d548b7d7d942f316c5295f6d849b74214f5
> > 
> > So it's a missed jump threading - care to investigate which?
> 
> The commit is about jump threading, but the regression is present without
> -fopenmp， so there's no jump threading?
> Somehow it affects PRE.
Please ignore this comment, obviously i had poor understanding of jump
threading.

[Bug libstdc++/97841] [C++17] is_invocable handling of incomplete return type is wrong

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|11.3|11.4

[Bug libstdc++/104301] --enable-cstdio=stdio_pure not passed down to libstdc++-v3

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Jonathan Wakely  ---
Fixed for 11.3

[Bug c++/100370] [11/12 Regression] Incorrect -Wplacement-new with union

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:790b02af6a1fcfa07dba6129909b3578a55a51fa

commit r12-8079-g790b02af6a1fcfa07dba6129909b3578a55a51fa
Author: Jason Merrill 
Date:   Tue Apr 5 22:29:06 2022 -0400

c++: -Wplacement-new and anon union member [PR100370]

This bug was an object/value confusion; we are interested in the size
of *b.ip, but instead the code was calculating the size of b.ip itself.

This seems to be because compute_objsize will compute the size of whatever
object it can find in the argument: if you pass it a VAR_DECL, it gives you
the size of that variable.  If you pass it an ADDR_EXPR of a VAR_DECL, it
again gives you the size of the variable.  The way you can tell the
difference is by looking at the deref member of access_ref: if it's -1, the
argument is a pointer to the object.  Since that's what we're interested
in,
we should check for that, like check_dangling_stores does.

This regressed some tests because compute_objsize_r was wrongly zeroing
deref in the POINTER_PLUS_EXPR handling; adding an offset to a pointer
doesn't change whether the pointer is itself a variable or a pointer to
one.  In fact, handling POINTER_PLUS_EXPR only really makes sense for deref
== -1, where we're adjusting a pointer to the variable.

PR c++/100370

gcc/cp/ChangeLog:

* init.cc (warn_placement_new_too_small): Check deref.

gcc/ChangeLog:

* pointer-query.cc (compute_objsize_r) [POINTER_PLUS_EXPR]: Require
deref == -1.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wplacement-new-size-11.C: New test.

[Bug c/50486] No warning at signed -> unsigned casting

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

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

--- Comment #3 from Manuel López-Ibáñez  ---
Clang warns:

 :16:18: warning: implicit conversion changes signedness: 'int' to
'enum e' [-Wsign-conversion]
return a(-1);
   ~ ^~

Not sure why gcc doesn't but it should.

[Bug tree-optimization/105217] New: Likely wrong code with -D_FORTIFY_SOURCE=3

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

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

Bug ID: 105217
   Summary: Likely wrong code with -D_FORTIFY_SOURCE=3
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: siddhesh at gcc dot gnu.org
  Target Milestone: ---

Created attachment 52781
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52781&action=edit
test-case

Isolated from autogen, where we originally created the following issue:
https://sourceforge.net/p/autogen/bugs/212/

I isolated that to the attached test-case:

$ head -c 20k  /tmp/1
$ gcc snippet.c -O2 -D_FORTIFY_SOURCE=3 -g && ./a.out /tmp/1
fread: data=0x2052c0, rem_sz=16340
.. read rdct=16340
realloc to=0x20a490-0x20f489 (newsize=20473)
.. diferent buffer!
fread: data=0x20e484, rem_sz=4096
.. read rdct=4096
realloc to=0x20a490-0x210489 (newsize=24569)
fread: data=0x20f484, rem_sz=4096
*** buffer overflow detected ***: terminated
Aborted (core dumped)

$ clang snippet.c -O2 -D_FORTIFY_SOURCE=3 -g && ./a.out /tmp/1
fread: data=0x4052c0, rem_sz=16340
.. read rdct=16340
realloc to=0x40a490-0x40f489 (newsize=20473)
.. diferent buffer!
fread: data=0x40e484, rem_sz=4096
.. read rdct=4096
realloc to=0x40a490-0x410489 (newsize=24569)
fread: data=0x40f484, rem_sz=4096
.. read rdct=44
fread: data=0x40f4b0, rem_sz=4052
.. read rdct=0

[Bug tree-optimization/105217] Likely wrong code with -D_FORTIFY_SOURCE=3

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2022-04-11
   Target Milestone|--- |12.0
 Ever confirmed|0   |1
   Priority|P3  |P1
 Status|UNCONFIRMED |NEW

[Bug rtl-optimization/102178] [12 Regression] SPECFP 2006 470.lbm regressions on AMD Zen CPUs after r12-897-gde56f95afaaa22

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed|2021-09-03 00:00:00 |2022-4-11

--- Comment #31 from Richard Biener  ---
For the testcase I still see 58 vmovq GPR <-> XMM at -Ofast -march=znver2,
resulting from spilling of xmms.  And there's still cases like

movq.LC0(%rip), %rax
...
vmovq   %rax, %xmm2
vmovq   %rax, %xmm4

Honza - you said you wanted to have some look here.  As I understand Vlad
costing isn't taken into account when choosing alternatives for reloading.

[Bug bootstrap/105218] New: [12 regression] bootstrap build error in mpc in stage3

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

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

Bug ID: 105218
   Summary: [12 regression] bootstrap build error in mpc in stage3
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

This happens during stage 3 and started overnight.  I am still looking for
where it started.

libtool: compile:  /home/seurer/gcc/git/build/gcc-test/./prev-gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/./prev-gcc/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/bin/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/bin/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/lib/
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/include
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/sys-include
-fchecking=1 -DHAVE_CONFIG_H -I. -I/home/seurer/gcc/git/gcc-test/mpc/src -I..
-I/home/seurer/gcc/git/build/gcc-test/./gmp
-I/home/seurer/gcc/git/gcc-test/mpfr/src -g -O2 -fchecking=1 -MT mul.lo -MD -MP
-MF .deps/mul.Tpo -c /home/seurer/gcc/git/gcc-test/mpc/src/mul.c -o mul.o
/home/seurer/gcc/git/gcc-test/mpc/src/mul.c: In function 'mpc_mul_karatsuba':
/home/seurer/gcc/git/gcc-test/mpc/src/mul.c:204:1: error: definition in block
13 does not dominate use in block 14
  204 | mpc_mul_karatsuba (mpc_ptr rop, mpc_srcptr op1, mpc_srcptr op2,
mpc_rnd_t rnd)
  | ^
for SSA_NAME: rnd_re_274 in statement:
# DEBUG D#5 => rnd_re_274 != 3 ? rnd_re_274 : 2
during GIMPLE pass: phiopt
/home/seurer/gcc/git/gcc-test/mpc/src/mul.c:204:1: internal compiler error:
verify_ssa failed
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
make[5]: *** [Makefile:584: mul.lo] Error 1

[Bug tree-optimization/105217] Likely wrong code with -D_FORTIFY_SOURCE=3

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

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

Siddhesh Poyarekar  changed:

   What|Removed |Added

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

[Bug target/105214] [12 Regression] ICE: in connect_traces, at dwarf2cfi.cc:3074 with custom flags

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 52782
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52782&action=edit
gcc12-pr105214.patch

Untested fix.
Another option would be not to call emit_jump (label2); but instead
  emit_jump_insn (targetm.gen_jump (label2));
  emit_barrier ();
Either we need to do pending stack adjustment before the conditional jump,
or can't do it on the unconditional jump (in the function it basically emits if
(cond) { ... } else { ... }).

[Bug target/105219] New: [12 Regression] SVE: Wrong code with -O3 -msve-vector-bits=128 -mtune=thunderx

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

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

Bug ID: 105219
   Summary: [12 Regression] SVE: Wrong code with -O3
-msve-vector-bits=128 -mtune=thunderx
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acoplan at gcc dot gnu.org
  Target Milestone: ---

The following C program appears to be miscompiled with -O3 -march=armv8.2-a+sve
-msve-vector-bits=128 -mtune=thunderx :

int a;
char b[60];
short c[18];
short d[4][19];
long long f;
void e(int g, int h, short k[][19]) {
  for (signed i = 0; i < 3; i += 2)
for (signed j = 1; j < h + 14; j++) {
  b[i * 14 + j] = 1;
  c[i + j] = k[2][j];
  a = g ? k[i][j] : 0;
}
}
int main() {
  e(9, 1, d);
  for (long l = 0; l < 6; ++l)
for (long m = 0; m < 4; ++m)
  f ^= b[l + m * 4];
  if (f)
__builtin_abort ();
}

Of course the choice of tuning is not sensible when asking for SVE, but GCC
shouldn't produce wrong code in any case. I can't reproduce the problem with
GCC 11.

[Bug bootstrap/105218] [12 regression] bootstrap build error in mpc in stage3

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Can you please attach preprocessed source + command line?
Seems it is caused by my r12-8078-ga42aa68bf1ad745a6b36ab9beed1fc2e77ac3f88
change...

[Bug tree-optimization/105217] Likely wrong code with -D_FORTIFY_SOURCE=3 since r12-6482-g06bc1b0c539e3a60

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|Likely wrong code with  |Likely wrong code with
   |-D_FORTIFY_SOURCE=3 |-D_FORTIFY_SOURCE=3 since
   ||r12-6482-g06bc1b0c539e3a60

--- Comment #1 from Martin Liška  ---
Started with r12-6482-g06bc1b0c539e3a60.

[Bug bootstrap/105218] [12 regression] bootstrap build error in mpc in stage3

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

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

--- Comment #2 from Jakub Jelinek  ---
Actually, I've managed to reproduce even on x86_64-linux.

[Bug c++/105220] New: Incorrect concept evaluation when friend class is involved

[martin.koch at bachmann dot info via Gcc-bugs]

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

Bug ID: 105220
   Summary: Incorrect concept evaluation when friend class is
involved
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: martin.koch at bachmann dot info
  Target Milestone: ---

Assume we have a concept which checks whether a type implements a method foo:
template 
concept fooable = requires(const T &t) {
t.foo();
};

And a class makes use of this concept:
template 
requires fooable
struct A { ... }

And some other class declares A as a friend:
class B {
   private:
friend struct A;
void foo() const {
std::cout << "foo called" << std::endl;
}
};

In this case B is not considered "fooable" in the template specialization of
A.
With clang it works fine. See: https://godbolt.org/z/8qWrPfd4b

[Bug bootstrap/105218] [12 regression] bootstrap build error in mpc in stage3

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Last reconfirmed||2022-04-11
   Priority|P3  |P1
   Target Milestone|--- |12.0

--- Comment #3 from Jakub Jelinek  ---
Reduced testcase for -O2 -g:
int a, c;

void
foo (void)
{
  int b;
  if (a)
b = c;
  if (a)
b = b == 2 ? b == 2 : b;
  while (b)
;
}

[Bug target/105197] [12 Regression] SVE: wrong code with -O -ftree-vectorize

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Tamar Christina :

https://gcc.gnu.org/g:78c718490bc2843d4dadcef8a0ae14aed1d15a32

commit r12-8080-g78c718490bc2843d4dadcef8a0ae14aed1d15a32
Author: Tamar Christina 
Date:   Mon Apr 11 15:09:05 2022 +0100

middle-end: Prevent the use of the cond inversion detection code when both
conditions are external. [PR105197]

Previously ifcvt used to enforce that a mask A and the inverse of said mask
be
represented as ~A. So for the masks

  _25 = _6 != 0;
  _44 = _4 != 0;

ifcvt would produce for an operation requiring the inverse of said mask

  _26 = ~_25;
  _43 = ~_44;

but now that VN is applied to the entire function body we get a
simplification
on the mask and produce:

  _26 = _6 == 0;
  _43 = _4 == 0;

This in itself is not a problem semantically speaking (though it does
create
more masks that need to be tracked) but when vectorizing the masked
conditional
we would still detect _26 and _43 to be inverses of _25 and _44 and mark
them
as requiring their operands be swapped.

When vectorizing we swap the operands but don't find the BIT_NOT_EXPR to
remove
and so we leave the condition as is which produces invalid code:

-->vectorizing statement: _ifc__41 = _43 ? 0 : _ifc__40;
created new init_stmt: vect_cst__136 = { 0, ... }
add new stmt: _137 = mask__43.26_135 & loop_mask_111
note:  add new stmt: vect__ifc__41.27_138 = VEC_COND_EXPR <_137,
vect__ifc__40.25_133, vect_cst__136>;

This fixes disabling the inversion detection code when the loop isn't
masked
since both conditional would be external.  We'd then not use the new
cond_code
and would incorrectly still swap the operands.

The resulting code is also better than GCC-11 with most operations now
predicated on the loop mask rather than a ptrue.

gcc/ChangeLog:

PR target/105197
* tree-vect-stmts.cc (vectorizable_condition): Prevent cond swap
when
not masked.

gcc/testsuite/ChangeLog:

PR target/105197
* gcc.target/aarch64/sve/pr105197-1.c: New test.
* gcc.target/aarch64/sve/pr105197-2.c: New test.

[Bug target/102772] [12 regression] g++.dg/torture/pr80334.C FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #46 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #44 from Jakub Jelinek  ---
> Rainer, for pr80334.C, have you been able to test the #c43 patch?

I did: the test FAILs (SEGV) at -m32 -O0 only, same as for unmodified
trunk.

> As for TLS and alignment, to confirm it is a ld bug, can you try #c29 testcase
> with all of gas + gld, gas + sunld and sunas + sunld (or perhaps just the 
> first
> and last from these)?  If gas + gld works and sunas + sunld don't, it would
> confirm the sun ld bug.

I get the same behaviour in all three cases: foo () returns an 8-byte
aligned address.

[Bug target/102772] [12 regression] g++.dg/torture/pr80334.C FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #47 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #45 from Jakub Jelinek  ---
> I'd like to ping the #c44 question.  Thanks.

Sorry for the delay: I haven't been well lately.

[Bug analyzer/105103] RFE: detect bogus use of varargs in analyzer

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

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

David Malcolm  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-04-11
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from David Malcolm  ---
I have a prototype implementation of this in my patch queue for GCC 13.

[Bug gcov-profile/105210] gcc/auto-profile.cc:391:11: warning: variable 'level' set but not used

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

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug target/105197] [12 Regression] SVE: wrong code with -O -ftree-vectorize

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

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

Tamar Christina  changed:

   What|Removed |Added

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

--- Comment #6 from Tamar Christina  ---
Fixed and no regression from codegen in GCC-11.

[Bug c++/105221] New: gcc rejects true ? [](auto) noexcept {} : [](int) {}

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 105221
   Summary: gcc rejects true ? [](auto) noexcept {} : [](int) {}
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

int main() {
  true ? [](auto) noexcept {} : [](int) {};
}

GCC-trunk only accepts the above code in C++14 but rejects it in C++17/20.
https://godbolt.org/z/7r4dKbo73

But it seems like it should be well-formed, you can see the explanation in SO:
https://stackoverflow.com/questions/71826315/ternary-operator-applied-to-different-lambdas-produces-inconsistent-results

[Bug bootstrap/105218] [12 regression] bootstrap build error in mpc in stage3

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

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 52783
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52783&action=edit
gcc12-pr105218.patch

Untested fix.

[Bug c++/105222] New: gcc rejects valid syntax of ternary operator for lambda in requires clause

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 105222
   Summary: gcc rejects valid syntax of ternary operator for
lambda in requires clause
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

int main() {
  auto b = requires { true ? [] {} : [] {}; };
}

[Bug c++/105222] gcc rejects valid syntax of ternary operator for lambda in requires clause

[hewillk at gmail dot com via Gcc-bugs]

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

--- Comment #1 from 康桓瑋  ---
gcc rejects this valid syntax with

source>:2:32: error: expected ':' before '{' token
2 |   auto b = requires { true ? [] {} : [] {}; };
  |^~
  |:
:2:33: error: expected primary-expression before '{' token
2 |   auto b = requires { true ? [] {} : [] {}; };
  | ^
:2:35: error: expected ';' before ':' token
2 |   auto b = requires { true ? [] {} : [] {}; };
  |   ^~
  |   ;

https://godbolt.org/z/4c3PPb5Pb

[Bug c++/105222] gcc rejects valid syntax of ternary operator for lambda in requires clause

[hewillk at gmail dot com via Gcc-bugs]

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

--- Comment #2 from 康桓瑋  ---
And gcc accepts the following invalid syntax:

int main() {
  auto b = requires { true ? [] : [] {}; };
}

https://godbolt.org/z/xeE1oYs1Y

[Bug middle-end/105206] mis-optimization with -ffast-math and __builtin_powf

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

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

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to Richard Biener from comment #2)
> Hm, it works for me on linux with glibc, can you be more specific as to what
> OS/libc (version) you are using?
> 
> foof:
> .LFB0:
> .cfi_startproc
> mulss   .LC0(%rip), %xmm0
> jmp expf
> 
> food:
> .LFB1:
> .cfi_startproc
> mulsd   .LC1(%rip), %xmm0
> jmp exp

Richard, I'm using x86_64-*-freebsd.  I just checked with powl(), and got 
fool:
.LFB5:
.cfi_startproc
pushq   %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
subq$16, %rsp
flds.LC0(%rip)
pushq   24(%rbp)
pushq   16(%rbp)
fstpt   -16(%rbp)
movq-16(%rbp), %rax
movl-8(%rbp), %edx
pushq   %rdx
pushq   %rax
callpowl
addq$32, %rsp
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc

with -ffast-math.

This might be related to PR89125.  The patch I attached to that PR has never
found its way into the repository.  I'll do some more testing later today.

[Bug c++/105222] gcc rejects valid syntax of ternary operator for lambda in requires clause

[hewillk at gmail dot com via Gcc-bugs]

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

--- Comment #3 from 康桓瑋  ---
(In reply to 康桓瑋 from comment #2)
> And gcc accepts the following invalid syntax:
> 
> int main() {
>   auto b = requires { true ? [] : [] {}; };
> }
> 
> https://godbolt.org/z/xeE1oYs1Y

It seems like the single [] makes gcc totally broken.

int main() {
  auto b = requires { true ? [] : []!-!-[]?[]; };
}

https://godbolt.org/z/EPTE6zf5E

[Bug target/104853] [RISC-V] -march=rv64g not including extension Zifencei

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

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Kito Cheng :

https://gcc.gnu.org/g:4132f6ba9583e128a00d55961ae8c8e7245b2223

commit r12-8084-g4132f6ba9583e128a00d55961ae8c8e7245b2223
Author: Kito Cheng 
Date:   Mon Apr 11 16:29:34 2022 +0800

RISC-V: Support -misa-spec for arch-canonicalize and multilib-generator.
[PR104853]

We migrate the default ISA spec version from 2.2 to 20191213, but those
scripts
aren't updated at the same time, this patch is making both scripts support
different ISA spec versions.

gcc/ChangeLog:

PR target/104853
* config.gcc: Pass -misa-spec to arch-canonicalize and
multilib-generator.
* config/riscv/arch-canonicalize: Adding -misa-spec option.
(SUPPORTED_ISA_SPEC): New.
(arch_canonicalize): New argument `isa_spec`.
Handle multiple ISA spec versions.
* config/riscv/multilib-generator: Adding -misa-spec option.

[Bug c++/105220] Incorrect concept evaluation when friend class is involved

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

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

Patrick Palka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2022-04-11
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 CC||ppalka at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||10.3.0, 11.2.0, 12.0

--- Comment #1 from Patrick Palka  ---
Confirmed, reduced rejects-valid testcase:

template
concept fooable = requires(T t) { t.foo(); };

template
struct A;// #1

template
struct A { }; // #2

struct B {
private:
  friend struct A;
  void foo();
};

A a; // should use #2


When determining whether to use #1 or #2 for A, we check #2's constraints in
the context of the template rather than the context of the specialization, so
the friend declaration doesn't apply.  Thus one workaround is to declare a
template friend instead:

  template friend struct A;

[Bug target/104253] libgcc missing __floatdiif

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

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

--- Comment #22 from CVS Commits  ---
The master branch has been updated by Alexandre Oliva :

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

commit r12-8087-gab0f04e4df1b7b312a4c9fa9b4d675778a0bae86
Author: Alexandre Oliva 
Date:   Mon Apr 11 12:11:10 2022 -0300

ppc: testsuite: require target effectively [PR104253]

The testcase was missing dg- before require-effective-target.

While at that, I'm also pruning the excess-error warning I got when
the test failed to be disabled because of the above.  I suppose it
might be useful for some target variants.


for gcc/testsuite/ChangeLog

PR target/104253
* gcc.target/powerpc/pr104253.c: Add missing dg- before
require-effective-target.  Prune warning about -mfloat128
possibly not being fully supported.

[Bug target/102772] [12 regression] g++.dg/torture/pr80334.C FAILs

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

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

--- Comment #48 from Jakub Jelinek  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #47)
> Sorry for the delay: I haven't been well lately.

I'm sorry to hear that.

Anyway, I'm out of ideas and unfortunately Solaris/x86 is not on GCCFarm.

Why is this a P1 when Solaris/x86 is neither primary nor secondary though?
Unless it reproduces also on Solaris/SPARC, which is primary but is on GCCFarm.

[Bug target/105219] [12 Regression] SVE: Wrong code with -O3 -msve-vector-bits=128 -mtune=thunderx

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

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

Tamar Christina  changed:

   What|Removed |Added

 CC||tnfchris at gcc dot gnu.org
   Last reconfirmed||2022-4-11

--- Comment #1 from Tamar Christina  ---
Smaller reproducer getting rid of the loop nest and simplify the inner
condition.

int a; 
   
   
   char b[60];
short d[19];
long long f;

__attribute__ ((noinline, noipa))  
   
   
   void e(int g, int h, short k[19]) {
for (signed j = 1; j < h + 14; j++) {
  int i = 0;
  b[j] = 1;
  i = 2;
  b[i * 14 + j] = 1;
  a = g ? k[j] : 0;
}
}

__attribute__ ((optimize("O0")))
int main() {
  e(9, 1, d);
  for (long l = 0; l < 6; ++l)
for (long m = 0; m < 4; ++m)
  f ^= b[l + m * 4];
  if (f)
__builtin_abort ();
}

and the -mtune=thunderx doesn't seem needed. I can reproduce with just -O3
-march=armv8.2-a+sve -msve-vector-bits=128.

the write to `a` itself is significant not for the result but to block the loop
from being optimized to a memset.

[Bug tree-optimization/105217] Likely wrong code with -D_FORTIFY_SOURCE=3 since r12-6482-g06bc1b0c539e3a60

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

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

--- Comment #2 from Siddhesh Poyarekar  ---
OK, taking a closer look, it looks like clang simply fails to fortify fread
(probably due to https://reviews.llvm.org/D109967 or something similar). 
Modifying the code to use __fread_chk directly:

size_t rdct = __fread_chk (data, __builtin_dynamic_object_size (data, 0),
(size_t)1, rem_sz, fp);

causes clang to crash too because it too comes up with the same __bdos estimate
for size:

```
fread: data=0xf792c0 (dsize: 16344, size: 18446744073709551615), rem_sz=16340
.. read rdct=16340
realloc to=0xf7e490-0xf83489 (newsize=20473)
.. diferent buffer!
fread: data=0xf82484 (dsize: 4101, size: 18446744073709551615), rem_sz=4096
.. read rdct=4096
realloc to=0xf7e490-0xf84489 (newsize=24569)
fread: data=0xf83484 (dsize: 5, size: 18446744073709551615), rem_sz=4096
*** buffer overflow detected ***: terminated
Aborted (core dumped)
```

dsize and size are the actual values that __bdos and __bos resolve to; I simply
modified the fprintf to this:

fprintf(stderr, "fread: data=%p (dsize: %zu, size: %zu), rem_sz=%d\n",
data, __builtin_dynamic_object_size (data, 0), __builtin_object_size (data, 0),
rem_sz);

I haven't looked too closely at the failure mechanism (I will tomorrow), but
this has got me inclined to think that it's an actual autogen bug that got
exposed with _FORTIFY_SOURCE=3.

[Bug ipa/103818] [12 Regression] ICE: in insert, at ipa-modref-tree.c:591 since r12-3202-gf5ff3a8ed4ca9173

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
For 128-bit math, you can e.g. use poly_offset_int, which generally looks like
a better type for these offsets and sizes (especially if they are counted in
bits not bytes).
Just to perform the <= comparison on the wider poly_offset_int, perhaps:
--- gcc/ipa-modref-tree.cc.jj   2022-04-06 16:44:44.0 +0200
+++ gcc/ipa-modref-tree.cc  2022-04-11 17:50:02.937784764 +0200
@@ -380,9 +380,13 @@ modref_access_node::update2 (poly_int64
 new_max_size = max_size2;
   else
 {
-  new_max_size = max_size2 + offset2 - offset1;
-  if (known_le (new_max_size, max_size1))
+  poly_offset_int n = max_size2;
+  n += offset2;
+  n -= offset1;
+  if (known_le (n, max_size1))
new_max_size = max_size1;
+  else
+   new_max_size = max_size2 + offset2 - offset1;
 }

   update (parm_offset1, offset1,
(though, not sure how can you narrow that back to poly_int64).
Though, the big question is what should one do with these overflows or
underflows that aren't representable, update2 can't fail right now and the
above still ICEs.
Is there some way how to indicate it is an access to an unknown offset?

[Bug target/105219] [12 Regression] SVE: Wrong code with -O3 -msve-vector-bits=128 -mtune=thunderx

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

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |12.0
 CC||ktkachov at gcc dot gnu.org
   Priority|P3  |P1

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Confirmed then.

[Bug target/104853] [RISC-V] -march=rv64g not including extension Zifencei

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

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Kito Cheng :

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

commit r11-9809-gfa21fcfb67587837c1704703a710496999393c1d
Author: Kito Cheng 
Date:   Mon Apr 11 16:29:34 2022 +0800

RISC-V: Support -misa-spec for arch-canonicalize and multilib-generator.
[PR104853]

We migrate the default ISA spec version from 2.2 to 20191213, but those
scripts
aren't updated at the same time, this patch is making both scripts support
different ISA spec versions.

gcc/ChangeLog:

PR target/104853
* config.gcc: Pass -misa-spec to arch-canonicalize and
multilib-generator.
* config/riscv/arch-canonicalize: Adding -misa-spec option.
(SUPPORTED_ISA_SPEC): New.
(arch_canonicalize): New argument `isa_spec`.
Handle multiple ISA spec versions.
* config/riscv/multilib-generator: Adding -misa-spec option.

(cherry picked from commit 4132f6ba9583e128a00d55961ae8c8e7245b2223)

[Bug target/104853] [RISC-V] -march=rv64g not including extension Zifencei

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

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

--- Comment #13 from Kito Cheng  ---
Hi rvalue:

Pushed the fix to trunk and GCC 11 branch for fixing both arch-canonicalize and
multilib-generator script.

Tested GCC 11/trunk with --with-isa-spec=2.2/20191213.

Could you try that to make sure that work to you?

[Bug target/105219] [12 Regression] SVE: Wrong code with -O3 -msve-vector-bits=128 -mtune=thunderx

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

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

--- Comment #3 from Alex Coplan  ---
(In reply to Tamar Christina from comment #1)
> Smaller reproducer getting rid of the loop nest and simplify the inner
> condition.

Hmm, I can't reproduce the issue with this locally (with or without the -mtune
option). I also seem to need the -mtune option with the original reproducer.
Are you definitely setting the right VL when running the compiled program?

[Bug c++/105223] New: [12 Regression] filter_memfn_lookup internal compiler error

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

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

Bug ID: 105223
   Summary: [12 Regression] filter_memfn_lookup internal compiler
error
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

Started with r12-7714-g47da5198766256:

commit 47da5198766256be658b4c321cecfd6039b0b91b
Author: Jason Merrill 
Date:   Fri Feb 25 15:07:15 2022 -0400

c++: using lookup within class defn [PR104476]


$ ./cc1plus -quiet ice.C
ice.C: In instantiation of ‘ServiceReference< 
>::ServiceReference(ServiceReferenceBase) [with  = int;
ServiceReferenceBase = ServiceReferenceBase]’:
ice.C:75:54:   required from here
ice.C:50:53: internal compiler error: Segmentation fault
   50 |   ServiceReference(ServiceReferenceBase) { operator=(0); }
  |~^~~
0x1773b61 crash_signal
/home/mpolacek/src/gcc/gcc/toplev.cc:322
0xae557e tree_check(tree_node*, char const*, int, char const*, tree_code)
/home/mpolacek/src/gcc/gcc/tree.h:3456
0xe17756 operator()
/home/mpolacek/src/gcc/gcc/cp/pt.cc:16411
0xe1799d filter_memfn_lookup
/home/mpolacek/src/gcc/gcc/cp/pt.cc:16417
0xe180ce tsubst_baselink
/home/mpolacek/src/gcc/gcc/cp/pt.cc:16506
0xe32588 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:21028
0xe30427 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:20658
0xe2ae60 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:19473
0xe22d0e tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:18486
0xe25b2d tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:18815
0xe22a79 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:18458
0xe25b2d tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:18815
0xe49a1f instantiate_body
/home/mpolacek/src/gcc/gcc/cp/pt.cc:26393
0xe4b3eb instantiate_decl(tree_node*, bool, bool)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:26685
0xe4b787 instantiate_pending_templates(int)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:26764
0xc4a2b6 c_parse_final_cleanups()
/home/mpolacek/src/gcc/gcc/cp/decl2.cc:5113
0xf9f06d c_common_parse_file()
/home/mpolacek/src/gcc/gcc/c-family/c-opts.cc:1262

$ cat ice.C
namespace std {
template  class reverse_iterator {
public:
  typename _Iterator::pointer operator->();
};
template 
bool operator!=(reverse_iterator<_Iterator>, reverse_iterator<_Iterator>);
} // namespace std
template  class __normal_iterator {
public:
  typedef _Iterator pointer;
};
namespace std {
template  class allocator;
template  struct allocator_traits;
template  struct allocator_traits> {
  using pointer = _Tp *;
};
} // namespace std
class ServiceRegistrationBase;
struct __alloc_traits
: std::allocator_traits> {};
namespace std {
class __shared_ptr {
public:
  using element_type = int;
  element_type *get();
};
struct _Vector_base {
  typedef __alloc_traits::pointer pointer;
};
class vector {
public:
  typedef std::reverse_iterator<__normal_iterator<_Vector_base::pointer>>
  reverse_iterator;
  reverse_iterator rbegin();
  reverse_iterator rend();
};
template  struct atomic;
template  struct atomic<_Tp *> { _Tp *load(); };
} // namespace std
class ServiceReferenceBasePrivate;
class ServiceReferenceBase {
public:
  void operator=(decltype(nullptr));
  std::atomic d;
};
template  class ServiceReference : public ServiceReferenceBase {
public:
  ServiceReference(ServiceReferenceBase) { operator=(0); }
  using ServiceReferenceBase::operator=;
};
class Bundle {
  friend std::__shared_ptr GetPrivate(Bundle);
};
class ServiceRegistrationBase {
public:
  ServiceReferenceBase GetReference();
};
class BundleContext {
public:
  Bundle GetBundle();
};
class ServiceReferenceBasePrivate {
public:
  std::__shared_ptr GetService(int *);
};
void ServiceHooksFilterServiceEventReceivers() {
  BundleContext __trans_tmp_3;
  std::vector eventListenerHooks;
  auto selfBundle = __trans_tmp_3.GetBundle();
  for (auto sriIter = eventListenerHooks.rbegin(),
sriEnd = eventListenerHooks.rend();
   sriIter != sriEnd;) {
ServiceReference sr = sriIter->GetReference();
int __trans_tmp_2 = *GetPrivate(selfBundle).get();
std::__shared_ptr __trans_tmp_1 = sr.d.load()->GetService(&__trans_tmp_2),
  elh(__trans_tmp_1);
  }
}

[Bug c++/105223] [12 Regression] filter_memfn_lookup internal compiler error

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

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

Marek Polacek  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |12.0
 CC||jason at gcc dot gnu.org
   Keywords||ice-on-valid-code

[Bug target/105219] [12 Regression] SVE: Wrong code with -O3 -msve-vector-bits=128 -mtune=thunderx

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

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

--- Comment #4 from Tamar Christina  ---
(In reply to Alex Coplan from comment #3)
> (In reply to Tamar Christina from comment #1)
> > Smaller reproducer getting rid of the loop nest and simplify the inner
> > condition.
> 
> Hmm, I can't reproduce the issue with this locally (with or without the
> -mtune option). I also seem to need the -mtune option with the original
> reproducer. Are you definitely setting the right VL when running the
> compiled program?

Ah, my sve-max-vq was in the wrong place... I indeed see that the thunderx is
significant now. Will try to reduce a bit again.

[Bug c++/105224] New: [modules] g++.dg/modules/virt-2_a.C: inline key methods: c++ modules and arm aapcs clash

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

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

Bug ID: 105224
   Summary: [modules] g++.dg/modules/virt-2_a.C: inline key
methods: c++ modules and arm aapcs clash
   Product: gcc
   Version: unknown
   URL: https://gcc.gnu.org/pipermail/gcc-patches/2022-April/5
92763.html
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aoliva at gcc dot gnu.org
Blocks: 103524
  Target Milestone: ---
Target: arm-eabi

g++.dg/modules/virt-2_a.C fails on arm-eabi and many other arm targets that use
the AAPCS variant.  ARM is the only target that overrides
TARGET_CXX_KEY_METHOD_MAY_BE_INLINE.  It's not clear to me which way the clash
between AAPCS and C++ Modules design should be resolved, but currently it
favors AAPCS and thus the test fails.

Skipping the test or conditionally dropping the inline keyword breaks
subsequent tests.  The patchlet in the URL XFAILs the expectations of the keyed
symbols on
arm*-*-*.
https://gcc.gnu.org/pipermail/gcc-patches/2022-April/592763.html


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
[Bug 103524] [meta-bug] modules issue

[Bug c++/105222] gcc totally broken with ternary operator for lambda in requires clause

[hewillk at gmail dot com via Gcc-bugs]

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

--- Comment #4 from 康桓瑋  ---
maybe dup of PR99546.

[Bug c++/105223] [12 Regression] filter_memfn_lookup internal compiler error

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #1 from Patrick Palka  ---
struct ServiceReferenceBase {
  void operator=(int);
};

template
struct ServiceReference : ServiceReferenceBase {
  void foo() { operator=(0); }
  using ServiceReferenceBase::operator=;
};

int main() {
  ServiceReference sr;
  sr.foo();
}

[Bug go/105225] New: build failure with musl libc 1.2.3 due to sysinfo.go error: redefinition of 'SYS_SECCOMP'

[ncopa at alpinelinux dot org via Gcc-bugs]

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

Bug ID: 105225
   Summary: build failure with musl libc 1.2.3 due to sysinfo.go
error: redefinition of 'SYS_SECCOMP'
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: ncopa at alpinelinux dot org
CC: cmang at google dot com
  Target Milestone: ---

Building gcc 11.2.1 with musl libc 1.2.3 fails with:

11.2.1_git20220219/libgo/go/syscall/time_nofake.go
/home/ncopa/aports/main/gcc/src/gcc-11.2.1_git20220219/libgo/go/syscall/timestruct.go
libcalls.go sysinfo.go syscall_arch.go syscall_linknames.go epoll.go  -fPIC -o
.libs/syscall.o
sysinfo.go:6606:7: error: redefinition of 'SYS_SECCOMP'
 6606 | const SYS_SECCOMP = _SYS_SECCOMP
  |   ^
sysinfo.go:6600:7: note: previous definition of 'SYS_SECCOMP' was here
 6600 | const SYS_SECCOMP = _SYS_seccomp
  |   ^
make[2]: *** [Makefile:3001: syscall.lo] Error 1

The generation of sysinfo.go will try extract syscalls and convert them to
uppercase. It gets duplicated by the uppercase SYS_SECCOMP introduced in with
musl commit:
https://git.musl-libc.org/cgit/musl/commit/?id=3dcbd896907d9d474da811b7c6b769342abaf651

A possible fix is to only grep for syscalls with lowercase letters:
diff --git a/libgo/mksysinfo.sh b/libgo/mksysinfo.sh
index 6fef104..06289a4 100755
--- a/libgo/mksysinfo.sh
+++ b/libgo/mksysinfo.sh
@@ -126,7 +126,7 @@ if ! grep '^const SIGCLD ' ${OUT} >/dev/null 2>&1; then
 fi

 # The syscall numbers.  We force the names to upper case.
-grep '^const _SYS_' gen-sysinfo.go | \
+grep '^const _SYS_[a-z]' gen-sysinfo.go | \
   sed -e 's/const _\(SYS_[^= ]*\).*$/\1/' | \
   while read sys; do
 sup=`echo $sys | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`

[Bug c/105226] New: [10/11/12 Regression] ICE in gimple_split_edge, at tree-cfg.cc:2960

[gscfq--- via Gcc-bugs]

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

Bug ID: 105226
   Summary: [10/11/12 Regression] ICE in gimple_split_edge, at
tree-cfg.cc:2960
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20190609 and 20190616, at -O3 or -Ofast :


$ cat z1.c
#include 
struct longjmp_buf {
  jmp_buf buf;
};
void g ();
void f ()
{
  int i, n;
  long *a;
  long *args;
  struct longjmp_buf b;
  setjmp (b.buf);
  for (;;)
{
  for (i = 0; i < n; i++)
a[i] = args[i];
  g ();
}
}


$ gcc-10-20190609 -c z1.c -Ofast
$ gcc-12-20220410 -c z1.c -O2
$
$ gcc-12-20220410 -c z1.c -Ofast
during GIMPLE pass: vect
z1.c: In function 'f':
z1.c:6:6: internal compiler error: in gimple_split_edge, at tree-cfg.cc:2960
6 | void f ()
  |  ^
0xe53d86 gimple_split_edge
../../gcc/tree-cfg.cc:2960
0x89f16c split_edge(edge_def*)
../../gcc/cfghooks.cc:668
0x10eec7c vect_loop_versioning(_loop_vec_info*, gimple*)
../../gcc/tree-vect-loop-manip.cc:3636
0x10e4e01 vect_transform_loop(_loop_vec_info*, gimple*)
../../gcc/tree-vect-loop.cc:9691
0x111ec35 vect_transform_loops
../../gcc/tree-vectorizer.cc:1007
0x111f2e6 try_vectorize_loop_1
../../gcc/tree-vectorizer.cc:1136
0x111f2e6 try_vectorize_loop
../../gcc/tree-vectorizer.cc:1167
0x111f914 execute
../../gcc/tree-vectorizer.cc:1281

[Bug c++/105227] New: [12 Regression] ICE in type_in_anonymous_namespace_p, at ipa-utils.h:233

[gscfq--- via Gcc-bugs]

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

Bug ID: 105227
   Summary: [12 Regression] ICE in type_in_anonymous_namespace_p,
at ipa-utils.h:233
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

This started between 2024 and 20211121,
with file g++.dg/ext/attr-alias-2.C at -Ofast :


$ g++-12-2024 -c attr-alias-2.C -fPIC -flto -Ofast
$ g++-12-20220410 -c attr-alias-2.C -fPIC -flto -O3
$
$ g++-12-20220410 -c attr-alias-2.C -fPIC -flto -Ofast
during IPA pass: visibility
attr-alias-2.C:37:1: internal compiler error: Segmentation fault
   37 | }
  | ^
0xda8c2f crash_signal
../../gcc/toplev.cc:322
0xb58561 type_in_anonymous_namespace_p(tree_node const*)
../../gcc/ipa-utils.h:233
0xb58561 maybe_record_node
../../gcc/ipa-devirt.cc:2427
0xb5a918 possible_polymorphic_call_targets(tree_node*, long,
ipa_polymorphic_call_context, bool*, void**, bool)
../../gcc/ipa-devirt.cc:3241
0xbd28b9 possible_polymorphic_call_targets(cgraph_edge*, bool*, void**, bool)
../../gcc/ipa-utils.h:131
0xbd28b9 walk_polymorphic_call_targets
../../gcc/ipa.cc:183
0xbd28b9 symbol_table::remove_unreachable_nodes(_IO_FILE*)
../../gcc/ipa.cc:431
0xccedbd execute_todo
../../gcc/passes.cc:2153

---

$ g++-12-20220410 -c attr-alias-2.C -fPIC -flto -Ofast   # test version
during IPA pass: visibility
attr-alias-2.C:37:1: internal compiler error: tree check: expected class
'type', have 'declaration' (translation_unit_decl) in type_with_linkage_p, at
ipa-utils.h:198
   37 | }
  | ^
0x6c96a5 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/tree.cc:8829
0xe1a61a tree_class_check(tree_node const*, tree_code_class, char const*, int,
char const*)
../../gcc/tree.h:3836
0xe1a61a type_with_linkage_p(tree_node const*)
../../gcc/ipa-utils.h:198
0xe1a61a type_in_anonymous_namespace_p(tree_node const*)
../../gcc/ipa-utils.h:229
0xe14011 maybe_record_node
../../gcc/ipa-devirt.cc:2427
0xe16221 possible_polymorphic_call_targets(tree_node*, long,
ipa_polymorphic_call_context, bool*, void**, bool)
../../gcc/ipa-devirt.cc:3241
0xea0837 possible_polymorphic_call_targets(cgraph_edge*, bool*, void**, bool)
../../gcc/ipa-utils.h:131
0xea0837 walk_polymorphic_call_targets
../../gcc/ipa.cc:183
0xea0837 symbol_table::remove_unreachable_nodes(_IO_FILE*)
../../gcc/ipa.cc:431
0xfd533d execute_todo
../../gcc/passes.cc:2153

[Bug c++/105228] New: [9/10/11/12 Regression] ICE tree check: expected tree that contains 'decl minimal' structure, have 'error_mark' in decl_anon_ns_mem_p, at cp/tree.cc:3826

[gscfq--- via Gcc-bugs]

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

Bug ID: 105228
   Summary: [9/10/11/12 Regression] ICE tree check: expected tree
that contains 'decl minimal' structure, have
'error_mark' in decl_anon_ns_mem_p, at cp/tree.cc:3826
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with r7 :
(gcc configured with --enable-checking=yes)


$ cat z1.cc
template class> struct A
{
  template
  static void foo() { foo(); }
};


$ g++-12-20220410 -c z1.cc
z1.cc:1:19: error: 'void' is not a valid type for a template non-type parameter
1 | template class> struct A
  |   ^~~~
z1.cc: In substitution of 'template >
class > template static void A<
 >::foo() [with Args = ;
 = {}]':
z1.cc:4:26:   required from here
z1.cc:4:15: internal compiler error: tree check: expected tree that contains
'decl minimal' structure, have 'error_mark' in decl_anon_ns_mem_p, at
cp/tree.cc:3826
4 |   static void foo() { foo(); }
  |   ^~~
0x6c9ab3 tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
../../gcc/tree.cc:8953
0xa1b4ac contains_struct_check(tree_node const*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/tree.h:3827
0xa1b4ac decl_anon_ns_mem_p(tree_node const*)
../../gcc/cp/tree.cc:3826
0x8182b7 determine_visibility(tree_node*)
../../gcc/cp/decl2.cc:2867
0x9ae8bf tsubst_function_decl
../../gcc/cp/pt.cc:14305
0x9924f3 tsubst_decl
../../gcc/cp/pt.cc:14585
0x97ad67 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.cc:15565
0x9b4cb2 instantiate_template_1
../../gcc/cp/pt.cc:21625
0x9b4cb2 instantiate_template(tree_node*, tree_node*, int)
../../gcc/cp/pt.cc:21684
0x9bc656 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
../../gcc/cp/pt.cc:22150
0x72543b add_template_candidate_real
../../gcc/cp/call.cc:3544
0x7265a1 add_template_candidate
../../gcc/cp/call.cc:3636
0x7265a1 add_candidates
../../gcc/cp/call.cc:6176
0x736240 add_candidates
../../gcc/cp/call.cc:10994
0x736240 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../../gcc/cp/call.cc:11038
0x9e7dde finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc/cp/semantics.cc:2791
0x9189d8 cp_parser_postfix_expression
../../gcc/cp/parser.cc:7880
0x92ffb1 cp_parser_unary_expression
../../gcc/cp/parser.cc:9029
0x8fd91f cp_parser_cast_expression
../../gcc/cp/parser.cc:9933
0x8fe1e1 cp_parser_binary_expression
../../gcc/cp/parser.cc:10035

[Bug c++/105229] New: [11/12 Regression] ICE in lookup_template_class_1, at cp/pt.cc:10111

[gscfq--- via Gcc-bugs]

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

Bug ID: 105229
   Summary: [11/12 Regression] ICE in lookup_template_class_1, at
cp/pt.cc:10111
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20200503 and 20200510 :


$ cat z1.cc
template  void bar ()
{
  []  {}.operator () <> ();
}
void foo ()
{
  bar ();
}


$ g++-12-20220410 -c z1.cc
z1.cc: In instantiation of 'void bar() [with  = int]':
z1.cc:7:12:   required from here
z1.cc:3:28: internal compiler error: in lookup_template_class_1, at
cp/pt.cc:10111
3 |   []  {}.operator () <> ();
  |   ~^
0x990981 lookup_template_class_1
../../gcc/cp/pt.cc:10111
0x990981 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc/cp/pt.cc:10350
0x990cb2 tsubst_aggr_type
../../gcc/cp/pt.cc:13738
0x97a962 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.cc:15649
0x9a717b tsubst_baselink
../../gcc/cp/pt.cc:16453
0x976d2b tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.cc:21028
0x975385 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.cc:20658
0x99b274 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.cc:19473
0x99918d tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.cc:18486
0x999b9f tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.cc:18458
0x99b233 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.cc:18815
0x97f679 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.cc:18444
0x97f679 instantiate_body
../../gcc/cp/pt.cc:26393
0x980da7 instantiate_decl(tree_node*, bool, bool)
../../gcc/cp/pt.cc:26685
0x9c780b instantiate_pending_templates(int)
../../gcc/cp/pt.cc:26764
0x8281e6 c_parse_final_cleanups()
../../gcc/cp/decl2.cc:5113

[Bug c++/105228] [9/10/11/12 Regression] ICE tree check: expected tree that contains 'decl minimal' structure, have 'error_mark' in decl_anon_ns_mem_p, at cp/tree.cc:3826

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

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-04-11
   Target Milestone|--- |9.5
   Keywords||error-recovery
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug fortran/105230] New: [9/10/11/12 Regression] ICE in find_array_section, at fortran/expr.cc:1634

[gscfq--- via Gcc-bugs]

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

Bug ID: 105230
   Summary: [9/10/11/12 Regression] ICE in find_array_section, at
fortran/expr.cc:1634
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with r8 :


$ cat z1.f90
program p
   integer, parameter :: a(:) = [1, 2]
   print *, reshape([3, 4], a(1:2))
end


$ cat z2.f90
program p
   integer, parameter :: a(:) = [1, 2]
   print *, reshape(a, a(1:2))
end


$ cat z3.f90
program p
   integer, parameter :: a(:) = [1, 2]
   print *, reshape(a(1:2), a(1:2))
end


$ gfortran-12-20220410 -c z1.f90
z1.f90:2:29:

2 |integer, parameter :: a(:) = [1, 2]
  | 1
Error: Parameter array 'a' at (1) cannot be automatic or of deferred shape
f951: internal compiler error: Segmentation fault
0xe7751f crash_signal
../../gcc/toplev.cc:322
0x736956 find_array_section
../../gcc/fortran/expr.cc:1634
0x73868a simplify_const_ref
../../gcc/fortran/expr.cc:1934
0x7391be gfc_simplify_expr(gfc_expr*, int)
../../gcc/fortran/expr.cc:2325
0x73942b simplify_parameter_variable
../../gcc/fortran/expr.cc:2154
0x739155 gfc_simplify_expr(gfc_expr*, int)
../../gcc/fortran/expr.cc:2292
0x70a47d gfc_check_reshape(gfc_expr*, gfc_expr*, gfc_expr*, gfc_expr*)
../../gcc/fortran/check.cc:4723
0x74b359 do_check
../../gcc/fortran/intrinsic.cc:4792
0x74b359 check_specific
../../gcc/fortran/intrinsic.cc:4805
0x7533e4 gfc_intrinsic_func_interface(gfc_expr*, int)
../../gcc/fortran/intrinsic.cc:5042
0x7a7cf8 resolve_unknown_f
../../gcc/fortran/resolve.cc:2990
0x7a7cf8 resolve_function
../../gcc/fortran/resolve.cc:3347
0x7a7cf8 gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.cc:7187
0x7adeb4 gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.cc:7154
0x7adeb4 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.cc:11949
0x7aca8f gfc_resolve_blocks(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.cc:10965
0x7acde8 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.cc:11939
0x7afac7 resolve_codes
../../gcc/fortran/resolve.cc:17567
0x7afb8e gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.cc:17602
0x797b14 resolve_all_program_units
../../gcc/fortran/parse.cc:6604

gcc-bugs@gcc.gnu.org

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:73da9ec55609efa532b9ac85ac2dbe121c134e18

commit r12-8089-g73da9ec55609efa532b9ac85ac2dbe121c134e18
Author: Jonathan Wakely 
Date:   Mon Apr 11 17:44:14 2022 +0100

libstdc++: Fix std::basic_stacktrace special members [PR105031]

The PR points out that there is a non-constant condition used for an
if-constexpr statement, but there are several other problems with the
copy, move and swap members of std::basic_stacktrace.

libstdc++-v3/ChangeLog:

PR libstdc++/105031
* include/std/stacktrace (basic_stacktrace::basic_stacktrace):
Fix allocator usage in constructors.
(basic_stacktrace::operator=(const basic_stacktrace&)): Do not
try to reallocate using const allocator.
(basic_stacktrace::operator=(basic_stacktrace&&)): Fix
if-constexpr with non-constant condition. Do not allocate new
storage if allocator propagates. Do not set _M_size if
allocation fails.
(basic_stacktrace::swap(basic_stacktrace&)): Fix typo. Add
assertion that non-propagating allocators are equal.
* testsuite/19_diagnostics/stacktrace/stacktrace.cc: New test.

gcc-bugs@gcc.gnu.org

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Jonathan Wakely  ---
Fixed, thanks for the report.

[Bug c++/98249] [9/10/11/12 Regression] Improper ADL on the `arg` in `new (arg) T`

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

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

Jason Merrill  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2022-04-11
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 CC||jason at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug bootstrap/105218] [12 regression] bootstrap build error in mpc in stage3

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

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

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

https://gcc.gnu.org/g:1774ab84863202f5db694914b67e3aef8c6dd807

commit r12-8090-g1774ab84863202f5db694914b67e3aef8c6dd807
Author: Jakub Jelinek 
Date:   Mon Apr 11 19:06:59 2022 +0200

phiopt: Fix up debug handling in the (x != cst1 ? x : cst2) != cst3 opt
[PR105218]

In the PR104639 optimization, I've added code to emit
  # DEBUG D#1 => arg != carg ? arg : oarg
instruction and replace debug uses of the phi with that debug
temp, so that the debug info is still accurrate.
Unfortunately, that is only correct if the middle-bb and
phi bb contain 1 and 2 predecessors, i.e. the ones that
we are using in the optimization (in particular middle-bb has
cond-bb as pred and phi bb cond-bb and middle-bb).
If that is not the case, then we can reach these from another bb
and so the arg SSA_NAME might not be valid there (its definition
doesn't dominate all incoming edges), or, even if it is valid,
might be wrong-debug, e.g. phi argument from some unrelated other
incoming edge might have the carg value that the debug stmt
remaps to oarg.  In theory we could check for that case and
if middle-bb doesn't have a single pred or phi bb 2 preds
check if arg SSA_NAME dominates the phi bb and if all other
phi arguments are expr_not_equal_to the carg value, but this patch
just uses a simpler approach and resets already if we have some
extra incoming edges.

2022-04-11  Jakub Jelinek  

PR tree-optimization/105218
* tree-ssa-phiopt.cc (value_replacement): If middle_bb has
more than one predecessor or phi's bb more than 2 predecessors,
reset phi result uses instead of adding a debug temp.

* gcc.dg/pr105218.c: New test.

[Bug bootstrap/105218] [12 regression] bootstrap build error in mpc in stage3

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Fixed now.

[Bug c++/105229] [11/12 Regression] ICE in lookup_template_class_1, at cp/pt.cc:10111

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

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

Marek Polacek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||mpolacek at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-04-11
   Target Milestone|--- |11.3

--- Comment #1 from Marek Polacek  ---
Confirmed.  Started with r11-86-gef3479afc5ab41

commit ef3479afc5ab415f00a53fc6f6a990df7f6a0747
Author: Marek Polacek 
Date:   Tue Apr 28 22:30:44 2020 -0400

c++: Member template function lookup failure [PR94799]

which changed

$ ./cc1plus.r11-85 -quiet ~/105229.C -std=c++2a
/home/mpolacek/105229.C: In function ‘void bar()’:
/home/mpolacek/105229.C:3:12: error: expected ‘(’ before ‘{’ token
3 |   []  {}.operator () <> ();
  |^
  |(
/home/mpolacek/105229.C:3:28: error: expected primary-expression before ‘>’
token
3 |   []  {}.operator () <> ();
  |^
/home/mpolacek/105229.C:3:31: error: expected primary-expression before ‘)’
token
3 |   []  {}.operator () <> ();
  |   ^

to

$ ./cc1plus.r11-86 -quiet ~/105229.C -std=c++2a
/home/mpolacek/105229.C: In function ‘void bar()’:
/home/mpolacek/105229.C:3:12: error: expected ‘(’ before ‘{’ token
3 |   []  {}.operator () <> ();
  |^
  |(
/home/mpolacek/105229.C: In instantiation of ‘void bar() [with
 = int]’:
/home/mpolacek/105229.C:7:13:   required from here
/home/mpolacek/105229.C:3:28: internal compiler error: in
lookup_template_class_1, at cp/pt.c:9891
3 |   []  {}.operator () <> ();
  |   ~^
unrecognized DWARF version in .debug_info at 6
0xbc18c9 lookup_template_class_1
../../gcc/cp/pt.c:9891
0xbc3176 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc/cp/pt.c:10114
0xbd10d0 tsubst_aggr_type
../../gcc/cp/pt.c:13382
0xbdd578 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.c:15169
0xbe0fe1 tsubst_baselink
../../gcc/cp/pt.c:16001
0xbf8c92 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:20188
0xbf638e tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:19730
0xbf1cd2 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:18753
0xbea656 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:17865
0xbea3e8 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:17835
0xbed092 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:18154
0xc11905 instantiate_decl(tree_node*, bool, bool)
../../gcc/cp/pt.c:25714
0xc122c4 instantiate_pending_templates(int)
../../gcc/cp/pt.c:25830

[Bug target/104253] libgcc missing __floatdiif

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

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

--- Comment #23 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Alexandre Oliva
:

https://gcc.gnu.org/g:20bde90da2ac415d4a06e7a8b2ba770d50385208

commit r11-9810-g20bde90da2ac415d4a06e7a8b2ba770d50385208
Author: Alexandre Oliva 
Date:   Mon Apr 11 12:11:10 2022 -0300

ppc: testsuite: require target effectively [PR104253]

The testcase was missing dg- before require-effective-target.

While at that, I'm also pruning the excess-error warning I got when
the test failed to be disabled because of the above.  I suppose it
might be useful for some target variants.


for gcc/testsuite/ChangeLog

PR target/104253
* gcc.target/powerpc/pr104253.c: Add missing dg- before
require-effective-target.  Prune warning about -mfloat128
possibly not being fully supported.

(cherry picked from commit ab0f04e4df1b7b312a4c9fa9b4d675778a0bae86)

[Bug c++/105223] [12 Regression] filter_memfn_lookup internal compiler error

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

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

--- Comment #2 from Patrick Palka  ---
The implicitly declared ServiceReference::operator= members lack a
TEMPLATE_INFO, but filter_memfn_lookup expects it (along with all other
non-template member functions from the instantiated class) to have one.

Not sure what the best solution here is, but we can at least work around this
by making filter_memfn_lookup tolerate missing TEMPLATE_INFO in this case:

 gcc/cp/pt.cc | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 78519562953..f359e596846 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -16404,6 +16404,13 @@ filter_memfn_lookup (tree oldfns, tree newfns, tree
newtype)
 look in the old lookup set for the TEMPLATE_DECL from which
 it was specialized.  */
   return visible_set.contains (DECL_TI_TEMPLATE (fn));
+else if (!DECL_TEMPLATE_INFO (fn))
+  {
+   /* FN is an implicitly declared special member function and thus
+  could not have been in the old lookup set.  */
+   gcc_checking_assert (DECL_ARTIFICIAL (fn) && DECL_DEFAULTED_FN (fn));
+   return false;
+  }
 else
   /* FN is a non-template member function from the current class;
 look in the old lookup set for the FUNCTION_DECL from which

[Bug target/104253] libgcc missing __floatdiif

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

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

--- Comment #24 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Alexandre Oliva
:

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

commit r10-10530-g3ebf64eaf264e1dcb4e72b77f67308fe58d993f8
Author: Alexandre Oliva 
Date:   Mon Apr 11 12:11:10 2022 -0300

ppc: testsuite: require target effectively [PR104253]

The testcase was missing dg- before require-effective-target.

While at that, I'm also pruning the excess-error warning I got when
the test failed to be disabled because of the above.  I suppose it
might be useful for some target variants.


for gcc/testsuite/ChangeLog

PR target/104253
* gcc.target/powerpc/pr104253.c: Add missing dg- before
require-effective-target.  Prune warning about -mfloat128
possibly not being fully supported.

(cherry picked from commit ab0f04e4df1b7b312a4c9fa9b4d675778a0bae86)

[Bug c++/105223] [12 Regression] filter_memfn_lookup internal compiler error

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

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

--- Comment #3 from Patrick Palka  ---
FWIW, the problematic hunk from r12-7714 appears to be:

--- a/gcc/cp/class.cc
+++ b/gcc/cp/class.cc
...
@@ -7700,14 +7723,17 @@ finish_struct (tree t, tree attributes)
 lookup not to fail or recurse into bases.  This isn't added
 to the template decl list so we drop this at instantiation
 time.  */
-  tree ass_op = build_lang_decl (USING_DECL, assign_op_identifier,
-NULL_TREE);
-  DECL_CONTEXT (ass_op) = t;
-  USING_DECL_SCOPE (ass_op) = t;
-  DECL_DEPENDENT_P (ass_op) = true;
-  DECL_ARTIFICIAL (ass_op) = true;
-  DECL_CHAIN (ass_op) = TYPE_FIELDS (t);
-  TYPE_FIELDS (t) = ass_op;
+  if (!get_class_binding_direct (t, assign_op_identifier, false))
+   {
+ tree ass_op = build_lang_decl (USING_DECL, assign_op_identifier,
+NULL_TREE);
+ DECL_CONTEXT (ass_op) = t;
+ USING_DECL_SCOPE (ass_op) = t;
+ DECL_DEPENDENT_P (ass_op) = true;
+ DECL_ARTIFICIAL (ass_op) = true;
+ DECL_CHAIN (ass_op) = TYPE_FIELDS (t);
+ TYPE_FIELDS (t) = ass_op;
+   }

   TYPE_SIZE (t) = bitsize_zero_node;
   TYPE_SIZE_UNIT (t) = size_zero_node;


This hunk causes us to no longer create a dependent USING_DECL representing the
implicitly declared operator= for ServiceReference, which means name lookup
for operator= at parse time yields only the ServiceReferenceBase::operator=
members.  This allows us to prune the overload set for the call 'operator=(0)'
ahead of time and hence we end up calling filter_memfn_lookup later at
instantiation time where we crash due comment #2.

[Bug tree-optimization/105227] [12 Regression] ICE in type_in_anonymous_namespace_p, at ipa-utils.h:233

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

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2022-04-11
   Priority|P3  |P1
  Component|c++ |tree-optimization
 CC||jason at gcc dot gnu.org

--- Comment #1 from Jason Merrill  ---
Confirmed.

The problem seems to be that free_lang_data_in_decl changes DECL_CONTEXT of
Klass::implementation to be the global scope because it isn't virtual, but
eventually update_vtable_references changes the vtable entry for Klass::magic
to refer to (a local alias for) Klass::implementation, so maybe_record_node's
attempts to ask about its class context fail.

Currently free_lang_data_in_decl works around this issue for destructors
specifically, but not for other member functions.

Not sure if the component should be tree-optimization or lto, but it isn't a
front-end issue.

[Bug fortran/105230] [9/10/11/12 Regression] ICE in find_array_section, at fortran/expr.cc:1634

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-04-11
 CC||kargl at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from kargl at gcc dot gnu.org ---
Started with 22015e77d3e4.

I cannot work out the logic here in expr.cc:1595-1603


  if ((begin && begin->expr_type != EXPR_CONSTANT)
  || (finish && finish->expr_type != EXPR_CONSTANT)
  || (step && step->expr_type != EXPR_CONSTANT)
  || (!begin && !lower)
  || (!finish && !upper))
{
  t = false;
  goto cleanup;
}

upper is NULL and later in 1634 it is dereferenced.  This patch fixes
the problem, but the above logic likely needs fixing.

diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
index 86d61fed302..4fcdf009b4b 100644
--- a/gcc/fortran/expr.cc
+++ b/gcc/fortran/expr.cc
@@ -1630,6 +1630,11 @@ find_array_section (gfc_expr *expr, gfc_ref *ref)
  if (ref->u.ar.dimen_type[d] == DIMEN_ELEMENT)
mpz_set (end [d], begin->value.integer);

+ if (!upper || !lower)
+   {
+ t = false;
+ goto cleanup;
+   }
  /* Check the bounds.  */
  if (mpz_cmp (ctr[d], upper->value.integer) > 0
  || mpz_cmp (end[d], upper->value.integer) > 0

[Bug ipa/105227] [12 Regression] ICE in type_in_anonymous_namespace_p, at ipa-utils.h:233

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
  Component|tree-optimization   |ipa
 CC||marxin at gcc dot gnu.org

[Bug c++/104142] [9/10/11/12 Regression] Spurios warning unused-variable on const static variable and defaulted constructor

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug rtl-optimization/105231] New: [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 105231
   Summary: [12 Regression] ICE: in rtl_verify_bb_insns, at
cfgrtl.cc:2797 (flow control insn inside a basic
block) with custom flags
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -Os -fsanitize-coverage=trace-pc
-fnon-call-exceptions --param=max-cse-insns=1 -frounding-math -mstack-arg-probe
-fsanitize=thread -m32 testcase.c
testcase.c: In function 'foo':
testcase.c:7:1: error: in basic block 3:
7 | }
  | ^
testcase.c:7:1: error: flow control insn inside a basic block
(insn 78 22 24 3 (set (reg:XF 99)
(float_extend:XF (mem/u/c:SF (symbol_ref/u:SI ("*.LC0") [flags 0x2]) [0
 S4 A32]))) 166 {*extendsfxf2_i387}
 (expr_list:REG_EH_REGION (const_int 1 [0x1])
(nil)))
during RTL pass: combine
testcase.c:7:1: internal compiler error: in rtl_verify_bb_insns, at
cfgrtl.cc:2797
0x76ddbe _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/repo/gcc-trunk/gcc/rtl-error.cc:108
0xe954e3 rtl_verify_bb_insns
/repo/gcc-trunk/gcc/cfgrtl.cc:2797
0xe9ea5c rtl_verify_flow_info_1
/repo/gcc-trunk/gcc/cfgrtl.cc:2883
0xe83dfa verify_flow_info()
/repo/gcc-trunk/gcc/cfghooks.cc:282
0x22a4bb8 checking_verify_flow_info
/repo/gcc-trunk/gcc/cfghooks.h:214
0x22a4bb8 try_optimize_cfg
/repo/gcc-trunk/gcc/cfgcleanup.cc:2980
0x22a4bb8 cleanup_cfg(int)
/repo/gcc-trunk/gcc/cfgcleanup.cc:3143
0x22d0820 rest_of_handle_combine
/repo/gcc-trunk/gcc/combine.cc:14942
0x22d0820 execute
/repo/gcc-trunk/gcc/combine.cc:14976
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
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-8090-20220411190659-g1774ab84863-checking-yes-rtl-df-extra-nobootstrap-pr105211-pr105214-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.1/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-8090-20220411190659-g1774ab84863-checking-yes-rtl-df-extra-nobootstrap-pr105211-pr105214-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220411 (experimental) (GCC)

Both vanilla gcc r12-8090 and with pr105211 and pr105214 patches applies ICE
the same way.