[Bug tree-optimization/100284] ICE in operation_could_trap_p with -march=armv8.2-a+sve -O3

[gilles.gouaillardet at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Gilles Gouaillardet  
---
Created attachment 50695
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50695=edit
preprocessed reproducer

$ ~/local/gcc-11.1.0/bin/gcc -march=armv8.2-a+sve -O3 -c bug.i

The bug has been fixed in master, thanks for the quick action!

I have attached the preprocessed bug.i, and here is the stack trace on the just
released gcc 11.1.0

during GIMPLE pass: vrp
bug.c: In function 'Ptngc_pack_array_xtc3':
bug.c:107:16: internal compiler error: in operation_could_trap_p, at
tree-eh.c:2546
  107 | unsigned char *Ptngc_pack_array_xtc3(int *input, int *length, const int
natoms, int speed)
  |^
0xda9a07 operation_could_trap_p(tree_code, bool, bool, tree_node*)
../../../src/gcc/gcc/tree-eh.c:2546
0x11c0497 maybe_resimplify_conditional_op
../../../src/gcc/gcc/gimple-match-head.c:156
0x11c0153 gimple_resimplify3
../../../src/gcc/gcc/gimple-match-head.c:404
0x11c1317 gimple_match_op::resimplify(gimple**, tree_node* (*)(tree_node*))
../../../src/gcc/gcc/gimple-match-head.c:493
0x11c1317 gimple_simplify_383
/home/users/u0001043/build/gcc-11.1.0/gcc/gimple-match.c:21030
0x11c399b gimple_simplify_PLUS_EXPR
/home/users/u0001043/build/gcc-11.1.0/gcc/gimple-match.c:58341
0x11d2a27 gimple_resimplify2
../../../src/gcc/gcc/gimple-match-head.c:318
0x121847b try_conditional_simplification
../../../src/gcc/gcc/gimple-match-head.c:872
0x121847b gimple_simplify(gimple*, gimple_match_op*, gimple**, tree_node*
(*)(tree_node*), tree_node* (*)(tree_node*))
../../../src/gcc/gcc/gimple-match-head.c:1046
0xa320ab fold_stmt_1
../../../src/gcc/gcc/gimple-fold.c:6001
0xf0e80b substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
../../../src/gcc/gcc/tree-ssa-propagate.c:1155
0x17fd477 dom_walker::walk(basic_block_def*)
../../../src/gcc/gcc/domwalk.c:309
0xf0d7a3 substitute_and_fold_engine::substitute_and_fold(basic_block_def*)
../../../src/gcc/gcc/tree-ssa-propagate.c:1283
0x103edb7 execute_vrp
../../../src/gcc/gcc/tree-vrp.c:4531
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug debug/100304] New: [11/12 Regression] -fcompare-debug failure (length) with custom flags

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 100304
   Summary: [11/12 Regression] -fcompare-debug failure (length)
with custom flags
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
CC: aoliva at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

Created attachment 50694
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50694=edit
auto-reduced testcase (from OpenTTD sources)

The same set of compiler flags after reduction was observed twice on two
different testcases, so it might be important.

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O2 -fno-cse-follow-jumps
-fno-guess-branch-probability -fno-tree-coalesce-vars -fno-tree-forwprop
-funroll-loops -fno-web -fcompare-debug testcase.C -w
x86_64-pc-linux-gnu-gcc: error: testcase.C: '-fcompare-debug' failure (length)


$ 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-174-20210427141825-g37d2b98100c-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--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-174-20210427141825-g37d2b98100c-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20210427 (experimental) (GCC)

[Bug debug/100303] New: [11/12 Regression] -fcompare-debug failure (length) with -O -fno-dce -ftracer

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 100303
   Summary: [11/12 Regression] -fcompare-debug failure (length)
with -O -fno-dce -ftracer
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
CC: aoliva at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

Created attachment 50693
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50693=edit
auto-reduced testcase (from OpenTTD sources)

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -fno-dce -ftracer -fcompare-debug testcase.C -w
x86_64-pc-linux-gnu-gcc: error: testcase.C: '-fcompare-debug' failure (length)

$ 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-174-20210427141825-g37d2b98100c-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--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-174-20210427141825-g37d2b98100c-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20210427 (experimental) (GCC)

[Bug rtl-optimization/97756] Inefficient handling of 128-bit arguments

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||dushistov at mail dot ru

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

[Bug target/100301] sum of __int128 - regression since 8.2

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
GCC has always had issues with double register integer types and sometimes the
register allocator choses worse and sometimes better.

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

[Bug target/100302] New: ICE in abs_hwi, at hwint.h:324

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 100302
   Summary: ICE in abs_hwi, at hwint.h:324
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: aarch64-linux-gnu

gcc-11.0.1-alpha20210426 snapshot (g:d3212299e2cfc3c16dd23bab26ec6c49024105f8)
ICEs when compiling the following testcase w/ -mcpu=zeus -O1
-ftree-loop-vectorize -fno-tree-scev-cprop --param vect-partial-vector-usage=0:

long int ct;

void
pt (void)
{
  for (ct = 0; ct >= 0; ++ct)
;
}

% aarch64-linux-gnu-gcc-11.0.1 -mcpu=zeus -O1 -ftree-loop-vectorize
-fno-tree-scev-cprop --param vect-partial-vector-usage=0 -c ppzrgnc5.c
during RTL pass: expand
ppzrgnc5.c: In function 'pt':
ppzrgnc5.c:4:1: internal compiler error: in abs_hwi, at hwint.h:324
4 | pt (void)
  | ^~
0x7f23c9 abs_hwi(long)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210426/work/gcc-11-20210426/gcc/hwint.h:324
0x7f23c9 abs_hwi(long)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210426/work/gcc-11-20210426/gcc/hwint.h:322
0x7f23c9 aarch64_add_offset_1_temporaries
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210426/work/gcc-11-20210426/gcc/config/aarch64/aarch64.c:4739
0x7f23c9 aarch64_offset_temporaries
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210426/work/gcc-11-20210426/gcc/config/aarch64/aarch64.c:4854
0x12a1c6c aarch64_legitimate_constant_p
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210426/work/gcc-11-20210426/gcc/config/aarch64/aarch64.c:18023
0xe455bb general_operand(rtx_def*, machine_mode)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210426/work/gcc-11-20210426/gcc/recog.c:1434
0xb23e7a copy_to_mode_reg(machine_mode, rtx_def*)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210426/work/gcc-11-20210426/gcc/explow.c:648
0xdbc022 prepare_cmp_insn
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210426/work/gcc-11-20210426/gcc/optabs.c:4397
0xdbc8e6 emit_cmp_and_jump_insns(rtx_def*, rtx_def*, rtx_code, rtx_def*,
machine_mode, int, rtx_def*, profile_probability)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210426/work/gcc-11-20210426/gcc/optabs.c:4583
0xa91020 do_compare_rtx_and_jump(rtx_def*, rtx_def*, rtx_code, int,
machine_mode, rtx_def*, rtx_code_label*, rtx_code_label*, profile_probability)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210426/work/gcc-11-20210426/gcc/dojump.c:1220
0xa92574 do_compare_and_jump
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210426/work/gcc-11-20210426/gcc/dojump.c:1294
0xa93c83 do_jump_1
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210426/work/gcc-11-20210426/gcc/dojump.c:242
0xa230cd expand_gimple_cond
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210426/work/gcc-11-20210426/gcc/cfgexpand.c:2646
0xa2396c expand_gimple_basic_block
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210426/work/gcc-11-20210426/gcc/cfgexpand.c:5904
0xa2539f execute
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210426/work/gcc-11-20210426/gcc/cfgexpand.c:6729

[Bug libstdc++/100287] Using iterator after std::move in ranges::partition

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r12-178-gd91e7eab3a2c3957c2220ad71e62d9fc78cccb9b
Author: Patrick Palka 
Date:   Tue Apr 27 23:21:19 2021 -0400

libstdc++: Fix various bugs in ranges_algo.h [PR100187, ...]

This fixes some bugs with our ranges algorithms in uncommon situations,
such as when the return type of a predicate is a non-copyable class type
that's implicitly convertible to bool (PR100187), when a comparison
predicate isn't invocable as an rvalue (PR100237), and when the return
type of a projection function is non-copyable (PR100249).

This also fixes PR100287, which reports that we're moving __first twice
when constructing with it an empty subrange in ranges::partition.

libstdc++-v3/ChangeLog:

PR libstdc++/100187
PR libstdc++/100237
PR libstdc++/100249
PR libstdc++/100287
* include/bits/ranges_algo.h (__search_n_fn::operator()): Give
the __value_comp lambda an explicit bool return type.
(__is_permutation_fn::operator()): Give the __proj_scan local
variable auto&& return type.  Give the __comp_scan lambda an
explicit bool return type.
(__remove_fn::operator()): Give the __pred lambda an explicit
bool return type.
(__partition_fn::operator()): Don't std::move __first twice
when returning an empty subrange.
(__min_fn::operator()): Don't std::move __comp.
(__max_fn::operator()): Likewise.
(__minmax_fn::operator()): Likewise.

[Bug libstdc++/100249] missing forwarding std::__invoke result in ranges::is_permutation and ranges::clamp

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r12-178-gd91e7eab3a2c3957c2220ad71e62d9fc78cccb9b
Author: Patrick Palka 
Date:   Tue Apr 27 23:21:19 2021 -0400

libstdc++: Fix various bugs in ranges_algo.h [PR100187, ...]

This fixes some bugs with our ranges algorithms in uncommon situations,
such as when the return type of a predicate is a non-copyable class type
that's implicitly convertible to bool (PR100187), when a comparison
predicate isn't invocable as an rvalue (PR100237), and when the return
type of a projection function is non-copyable (PR100249).

This also fixes PR100287, which reports that we're moving __first twice
when constructing with it an empty subrange in ranges::partition.

libstdc++-v3/ChangeLog:

PR libstdc++/100187
PR libstdc++/100237
PR libstdc++/100249
PR libstdc++/100287
* include/bits/ranges_algo.h (__search_n_fn::operator()): Give
the __value_comp lambda an explicit bool return type.
(__is_permutation_fn::operator()): Give the __proj_scan local
variable auto&& return type.  Give the __comp_scan lambda an
explicit bool return type.
(__remove_fn::operator()): Give the __pred lambda an explicit
bool return type.
(__partition_fn::operator()): Don't std::move __first twice
when returning an empty subrange.
(__min_fn::operator()): Don't std::move __comp.
(__max_fn::operator()): Likewise.
(__minmax_fn::operator()): Likewise.

[Bug libstdc++/100187] Helper lambda in ranges_algo.h misses forwarding return type

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r12-178-gd91e7eab3a2c3957c2220ad71e62d9fc78cccb9b
Author: Patrick Palka 
Date:   Tue Apr 27 23:21:19 2021 -0400

libstdc++: Fix various bugs in ranges_algo.h [PR100187, ...]

This fixes some bugs with our ranges algorithms in uncommon situations,
such as when the return type of a predicate is a non-copyable class type
that's implicitly convertible to bool (PR100187), when a comparison
predicate isn't invocable as an rvalue (PR100237), and when the return
type of a projection function is non-copyable (PR100249).

This also fixes PR100287, which reports that we're moving __first twice
when constructing with it an empty subrange in ranges::partition.

libstdc++-v3/ChangeLog:

PR libstdc++/100187
PR libstdc++/100237
PR libstdc++/100249
PR libstdc++/100287
* include/bits/ranges_algo.h (__search_n_fn::operator()): Give
the __value_comp lambda an explicit bool return type.
(__is_permutation_fn::operator()): Give the __proj_scan local
variable auto&& return type.  Give the __comp_scan lambda an
explicit bool return type.
(__remove_fn::operator()): Give the __pred lambda an explicit
bool return type.
(__partition_fn::operator()): Don't std::move __first twice
when returning an empty subrange.
(__min_fn::operator()): Don't std::move __comp.
(__max_fn::operator()): Likewise.
(__minmax_fn::operator()): Likewise.

[Bug libstdc++/100237] Unnecessary std::move in ranges::min, ranges::max and ranges::minmax

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r12-178-gd91e7eab3a2c3957c2220ad71e62d9fc78cccb9b
Author: Patrick Palka 
Date:   Tue Apr 27 23:21:19 2021 -0400

libstdc++: Fix various bugs in ranges_algo.h [PR100187, ...]

This fixes some bugs with our ranges algorithms in uncommon situations,
such as when the return type of a predicate is a non-copyable class type
that's implicitly convertible to bool (PR100187), when a comparison
predicate isn't invocable as an rvalue (PR100237), and when the return
type of a projection function is non-copyable (PR100249).

This also fixes PR100287, which reports that we're moving __first twice
when constructing with it an empty subrange in ranges::partition.

libstdc++-v3/ChangeLog:

PR libstdc++/100187
PR libstdc++/100237
PR libstdc++/100249
PR libstdc++/100287
* include/bits/ranges_algo.h (__search_n_fn::operator()): Give
the __value_comp lambda an explicit bool return type.
(__is_permutation_fn::operator()): Give the __proj_scan local
variable auto&& return type.  Give the __comp_scan lambda an
explicit bool return type.
(__remove_fn::operator()): Give the __pred lambda an explicit
bool return type.
(__partition_fn::operator()): Don't std::move __first twice
when returning an empty subrange.
(__min_fn::operator()): Don't std::move __comp.
(__max_fn::operator()): Likewise.
(__minmax_fn::operator()): Likewise.

[Bug libstdc++/100249] missing forwarding std::__invoke result in ranges::is_permutation and ranges::clamp

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

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

--- Comment #6 from Patrick Palka  ---
(In reply to 康桓瑋 from comment #5)
> (In reply to Patrick Palka from comment #4)
> > (In reply to 康桓瑋 from comment #0)
> > > when the type of __proj_val is an rvalue reference, we need to convert it 
> > > to
> > > rvalue for the next std::__invoke call: https://godbolt.org/z/1G7aqxs3c.
> > 
> > So it seems the projection application limit of 3 makes it impossible for
> > ranges::clamp to perfectly support the case where the projection returns an
> > rvalue reference.
> 
> Maybe this can help:
> 
>   auto&& __proj_val = std::__invoke(__proj, __val);
>   if (std::__invoke(__comp,
> std::forward(__proj_val), std::__invoke(__proj, __lo)))
> return __lo;

We could safely forward __proj_val only in the second invocation of __comp,
after which __proj_val is no longer used, but I'm not sure that's worthwhile...

[Bug c++/94483] [9 Regression] ICE: tree check: expected type_pack_expansion, have error_mark in add_capture, at cp/lambda.c:607

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

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

Patrick Palka  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|9.4 |10.0

--- Comment #5 from Patrick Palka  ---
This doesn't seem appropriate to backport because it's "only" a rejects-valid
-> ice-on-valid regression.  Before r9-4041, we just didn't support pack
expansions in lambda init-capture.

[Bug c++/100209] multiple inheritance with crtp pattern fails on sequentioal member access

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

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

Patrick Palka  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |12.0

--- Comment #5 from Patrick Palka  ---
Fixed for GCC 12, thanks for the bug report.

[Bug c/100301] New: sum of __int128 - regression since 8.2

[dushistov at mail dot ru via Gcc-bugs]

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

Bug ID: 100301
   Summary: sum of __int128 - regression since 8.2
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dushistov at mail dot ru
  Target Milestone: ---

For such simple function:

__int128 add1(__int128 a, __int128 b) {
return a + b;
}

gcc 8.2 generates for a + b:

mov r9, rdi
mov r10, rsi
add r9, rdx
adc r10, rcx
mov rax, r9
mov rdx, r10
ret
and for b + a:

add1(__int128, __int128):
mov rax, rdx
mov rdx, rcx
add rax, rdi
adc rdx, rsi
ret

but gcc 11.1 generates for both cases:
add1(__int128, __int128):
mov r9, rdi
mov rax, rdx
mov r8, rsi
mov rdx, rcx
add rax, r9
adc rdx, r8
ret

4 moves instead of 2.

Recent versions of clang and icc generates the same number and type of
instruction of both cases,
and only 2 moves and 2 additions:

icc:
add1(__int128, __int128):
add   rdi, rdx
mov   rax, rdi
adc   rsi, rcx
mov   rdx, rsi
ret

add1(__int128, __int128):
add   rdx, rdi
mov   rax, rdx
adc   rcx, rsi
mov   rdx, rcx
ret   

clang:

add1(__int128, __int128):
mov rax, rdi
add rax, rdx
adc rsi, rcx
mov rdx, rsi
ret

add1(__int128, __int128): 
mov rax, rdi
add rax, rdx
adc rsi, rcx
mov rdx, rsi
ret

Not sure is this target specific issue,
I get this example from this article: https://habr.com/ru/post/554760/ ,
where risc-v gcc 8.2.0 has similar problem that "a + b" and "b + a" uses
different number of instructions.

[Bug c++/100277] ICE on cuda host code

[ed.gcc at pobox dot com via Gcc-bugs]

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

Eduard Rozenberg  changed:

   What|Removed |Added

 CC||ed.gcc at pobox dot com

--- Comment #2 from Eduard Rozenberg  ---
Similar issues (related to Nvidia nvcc, nccl) reported here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100102
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100240

My issue started after moving from gcc 10.2.0 to 10.3.0.

10.2.0 worked fine
10.3.0 ICEs with that same `intmax_t __n` segfault

I can't figure out what the problem is, and hoping there will be a patch for
10.3.x because I have to use the gcc my OS provides (10.3.0 currently). Also
there's very litle chance that Nvidia will support gcc 11 or 12 anytime soon
(took them years to support gcc9 and eventually 10).

[Bug libstdc++/100249] missing forwarding std::__invoke result in ranges::is_permutation and ranges::clamp

[hewillk at gmail dot com via Gcc-bugs]

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

--- Comment #5 from 康桓瑋  ---
(In reply to Patrick Palka from comment #4)
> (In reply to 康桓瑋 from comment #0)
> > when the type of __proj_val is an rvalue reference, we need to convert it to
> > rvalue for the next std::__invoke call: https://godbolt.org/z/1G7aqxs3c.
> 
> So it seems the projection application limit of 3 makes it impossible for
> ranges::clamp to perfectly support the case where the projection returns an
> rvalue reference.

Maybe this can help:

  auto&& __proj_val = std::__invoke(__proj, __val);
  if (std::__invoke(__comp, std::forward(__proj_val),
std::__invoke(__proj, __lo)))
return __lo;

[Bug tree-optimization/100102] [8/9/10/11/12 Regression] ICE in tsubst, at cp/pt.c:15310

[ed.gcc at pobox dot com via Gcc-bugs]

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

Eduard Rozenberg  changed:

   What|Removed |Added

 CC||ed.gcc at pobox dot com

--- Comment #7 from Eduard Rozenberg  ---
The same/similar issue also reported in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100240

In my case no problems with GCC 10.2.0, problems started with GCC 10.3.0.

[Bug fortran/100300] New: compile-time infinite loop if using execute_command_line

[john.harper at vuw dot ac.nz via Gcc-bugs]

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

Bug ID: 100300
   Summary: compile-time infinite loop if using
execute_command_line
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: john.harper at vuw dot ac.nz
  Target Milestone: ---

The program writetest.f90 below writes a file and then uses
execute_command_line to compile readtest.f90, which was supposed to read the
file, but its syntax error drove gfortran into an infinite loop pointing the
error out. Linux system evidence:

cayley[~/Jfh] % gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl
--with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit
--enable-cet=auto --enable-checking=release --enable-clocale=gnu
--enable-default-pie --enable-default-ssp --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id
--enable-lto --enable-multilib --enable-plugin --enable-shared
--enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-libunwind-exceptions --disable-werror
gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.0 (GCC)

cayley[~/Jfh] % cat writetest.f90
! Use execute_command_line to start a second program readtest.f90 that
! reads a file, testfile.txt, written by this program.
  implicit none
  integer u,i
  open(newunit=u,file='testfile.txt',action='WRITE',position='REWIND',&
   form='FORMATTED',access='SEQUENTIAL')
  write(u,"(A,I0)") ('line ',i,i=1,2)
  call execute_command_line('gfortran readtest.f90 ; ./a.out')
end program

cayley[~/Jfh] % cat readtest.f90
  implicit none
  character(40) lines(2)
  integer u
  open(newunit=u,,file='testfile.txt')
  read(u,"(A)") lines(:)
  print  "(A)",'readtest gave '//lines(:)
end program

The second program has a syntax error (,,) correctly found by gfortran but 
compiling it by calling execute_command_line in the first program gave an
infinite loop repeating this 5-line message until I stopped it manually:
quote--
readtest.f90:4:18:

4 |   open(newunit=u,,file='testfile.txt')
  |  1
Error: Syntax error in OPEN statement at (1)
unquote

Correcting the error by removing one of the commas made the program compile
and run.

[Bug c++/100240] Compiler crashes with segmentation fault on a chrono library using nvcc

[ed.gcc at pobox dot com via Gcc-bugs]

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

Eduard Rozenberg  changed:

   What|Removed |Added

 CC||ed.gcc at pobox dot com

--- Comment #9 from Eduard Rozenberg  ---
I run into similar errors (probably the same issue), when trying to use Nvidia
NCCL.

For ex. when trying to run `make` on the nccl tests
(https://github.com/NVIDIA/nccl-tests.git), I get:

nccl-tests/src'
Compiling  all_reduce.cu   > ../build/all_reduce.o
/usr/include/c++/10.3.0/chrono: In substitution of ‘template template using __is_harmonic =
std::__bool_constant<(std::ratio<((_Period2::num / std::chrono::duration<_Rep,
_Period>::_S_gcd(_Period2::num, _Period::num)) * (_Period::den /
std::chrono::duration<_Rep, _Period>::_S_gcd(_Period2::den, _Period::den))),
((_Period2::den / std::chrono::duration<_Rep, _Period>::_S_gcd(_Period2::den,
_Period::den)) * (_Period::num / std::chrono::duration<_Rep,
_Period>::_S_gcd(_Period2::num, _Period::num)))>::den == 1)> [with _Period2 =
_Period2; _Rep = _Rep; _Period = _Period]’:
/usr/include/c++/10.3.0/chrono:473:154:   required from here
/usr/include/c++/10.3.0/chrono:428:27: internal compiler error: Segmentation
fault
  428 |  _S_gcd(intmax_t __m, intmax_t __n) noexcept
  |   ^~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[1]: *** [Makefile:84: ../build/all_reduce.o] Error 1


And I get build errors when trying to build pytorch since it also tries to use
Nvidia nccl.

The following might be relevant/related but can't tell for sure:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100101
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100102

Even if the issue eventually gets fixed in GCC 11/12, what will the solution be
for GCC 10.3 (10.x) users? Asking because it normally takes operating systems
and Nvidia months or years to move to or support the next major GCC version,
and in particular it's recommended to use the same GCC version as the operating
system's kernel is built with, so I wouldn't be able to decide to just use GCC
11 or 12.

[Bug c++/100299] New: cc1plus taking all RAM

[vincent.lextrait at gmail dot com via Gcc-bugs]

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

Bug ID: 100299
   Summary: cc1plus taking all RAM
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincent.lextrait at gmail dot com
  Target Milestone: ---

Created attachment 50692
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50692=edit
ii file to reproduce the issue. gunzip first.

While compiling a relatively large file (ii file ~2 MB), g++ compilation in -O3
aborts after suddenly allocating in a few steps within a few seconds all the
RAM (128 GB!).

Compiles just fine with -O2 (and it takes 5 times longer than to abort in -O3).

To my utter surprise, it compiles with -O2 -fgcse-after-reload -fipa-cp-clone
-floop-interchange -floop-unroll-and-jam -fpeel-loops -fpredictive-commoning
-fsplit-loops -fsplit-paths -ftree-loop-distribution -ftree-loop-vectorize
-ftree-partial-pre -ftree-slp-vectorize -funswitch-loops -fvect-cost-model
-fvect-cost-model=dynamic -fversion-loops-for-strides

While the specific 11.1 man specifies that these options are equivalent to -O3.
Excerpt of man:

-O3 Optimize yet more.  -O3 turns on all optimizations specified by -O2 and
also turns on the following optimization flags:

   -fgcse-after-reload -fipa-cp-clone -floop-interchange
-floop-unroll-and-jam -fpeel-loops -fpredictive-commoning -fsplit-loops
   -fsplit-paths -ftree-loop-distribution -ftree-loop-vectorize
-ftree-partial-pre -ftree-slp-vectorize -funswitch-loops
   -fvect-cost-model -fvect-cost-model=dynamic
-fversion-loops-for-strides

The man must not be correct, some other option must be added in -O3.

I am on x86_64-linux-gnu (Ubuntu 20.04) - but I am fairly sure it is not
platform-dependent.

gcc is configured using 

./configure -v --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu --prefix=/usr/local/gcc-11.1
--enable-checking=release --enable-languages=c,c++ --disable-multilib
--program-suffix=-11.1

The complete command line that triggers the bug:

g++-11.1 -std=c++20 -O3 -c test.ii

The error:

g++-11.1: fatal error: Killed signal terminated program cc1plus
compilation terminated.

gzipped test.ii attached to this bug report.

Previous versions of gcc do not exhibit the bug, but do compile very very
slowly compared to -O0 option, or compared to clang.

[Bug libstdc++/100298] New: noexcept is missing for thread::hardware_concurrency clang refuses the code

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 100298
   Summary: noexcept is missing for thread::hardware_concurrency
clang refuses the code
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

In file included from In file included from
/home/cqwrteur/myhome/libstdcxx_wasm_build/include/bits/atomic_futex.h:39:
In file included from
/home/cqwrteur/myhome/libstdcxx_wasm_build/include/mutex:47:
In file included from
/home/cqwrteur/myhome/libstdcxx_wasm_build/include/thread:43:
/home/cqwrteur/myhome/libstdcxx_wasm_build/include/bits/std_thread.h:273:31:
error: 'hardware_concurrency' is missing exception specification 'noexcept'
  inline unsigned int thread::hardware_concurrency() { return 0; }
  ^
/home/cqwrteur/myhome/libstdcxx_wasm_build/include/bits/std_thread.h:196:5:
note: previous declaration is here
hardware_concurrency() noexcept;
^
1 warning and 1 error generated.
1 warning generated.
2 warnings generated.
1 warning and 1 error generated.
4 warnings generated.
make[3]: *** [Makefile:648: future.lo] Error 1
5 warnings generated.
make[3]: *** [Makefile:648: futex.lo] Error 1

[Bug c++/67762] [C++1z] 'not a constant expression" errors only with -fsanitize=undefined

[dushistov at mail dot ru via Gcc-bugs]

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

--- Comment #7 from Evgeniy Dushistov  ---
Here simple example extracted from Qt 6 git:

```
template
struct Prop {
void notify()
{
if constexpr (Signal != nullptr) {
}
}
};

class QObjectPrivate {
public:
struct ExtraData
{
inline void nameChangedForwarder()  {}
};
};

int main()
{
Prop<::ExtraData::nameChangedForwarder>  prop;
prop.notify();
}

```

"g++ -std=c++17" compiles it just fine,
while "g++ -std=c++17 -fsanitize=undefined" gitves such error:

test2.cpp: In instantiation of 'void Prop::notify() [with auto Signal =
::ExtraData::nameChangedForwarder]':
test2.cpp:21:13:   required from here
test2.cpp:5:34: error: '(QObjectPrivate::ExtraData::nameChangedForwarder != 0)'
is not a constant expression
5 | if constexpr (Signal != nullptr) {
  |   ~~~^~


This is with gcc 11.1.0

[Bug fortran/97571] long parsing phase for simple array constructor

[molah at ucar dot edu via Gcc-bugs]

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

--- Comment #11 from Mark J Olah  ---
(In reply to Steve Kargl from comment #10)

> gfortran is mostly maintained by volunteers.  I started fixing
> bugs 2 decades ago, because gfortran was the only Fortran compiler
> available for FreeBSD.  I no longer contribute patches back to
> gcc due to a few reasons.  gfortran could use a new volunteer
> to step up.

Steve, thanks for your years of effort.  I understand that all fixes are
community contributed.  If I knew how to fix this myself, I would.

I would be satisfied with acknowledgment that there is an issue, and it effects
the usability of the compiler for actual real-world use cases.

It also is a clear regression between versions, arising from a deliberate and
arguably inefficiently implemented change in the way the compiler is generating
the code.

A simple revision to previous behavior, or a flag to disable the new behavior
would be sufficient to enable the new compiler to continue to work with
existing codebases.

Also, on further timing analysis the behavior appears to be approximately
quadratic in N (not exponential), but with a big enough constant that it
becomes problematic at reasonable sizes of N.

[Bug fortran/100154] [9/10/11/12 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.c:6131

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #14 from anlauf at gcc dot gnu.org ---
Fixed on mainline for gcc-12, and on all affected branches (9/10/11).  Closing.

Thanks for the report!

[Bug fortran/100154] [9/10/11/12 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.c:6131

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

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

--- Comment #13 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:21992a791aded6d818da39079546c067f3362e8b

commit r9-9469-g21992a791aded6d818da39079546c067f3362e8b
Author: Harald Anlauf 
Date:   Sat Apr 24 20:51:41 2021 +0200

PR fortran/100154 - ICE in gfc_conv_procedure_call, at
fortran/trans-expr.c:6131

Add appropriate static checks for the character and status arguments to
the GNU Fortran intrinsic extensions fget[c], fput[c].  Extend variable
check to allow a function reference having a data pointer result.

gcc/fortran/ChangeLog:

PR fortran/100154
* check.c (variable_check): Allow function reference having a data
pointer result.
(arg_strlen_is_zero): New function.
(gfc_check_fgetputc_sub): Add static check of character and status
arguments.
(gfc_check_fgetput_sub): Likewise.
* intrinsic.c (add_subroutines): Fix argument name for the
character argument to intrinsic subroutines fget[c], fput[c].

gcc/testsuite/ChangeLog:

PR fortran/100154
* gfortran.dg/pr100154.f90: New test.

(cherry picked from commit d0e7833b94953ba6b4a915150666969ad9fc66af)

[Bug fortran/97571] long parsing phase for simple array constructor

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #10 from Steve Kargl  ---
On Tue, Apr 27, 2021 at 06:03:16PM +, molah at ucar dot edu wrote:

> I would expect a compiler must do a reasonable job to compile correct Fortran
> code in a reasonable amount of time.  The response for reporting significant
> algorithmic internal deficiencies of a compiler cannot be "change your code",
> otherwise the solution of your users will have to be "change the compiler".

gfortran is mostly maintained by volunteers.  I started fixing
bugs 2 decades ago, because gfortran was the only Fortran compiler
available for FreeBSD.  I no longer contribute patches back to
gcc due to a few reasons.  gfortran could use a new volunteer
to step up.

[Bug fortran/100154] [9/10/11/12 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.c:6131

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

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:

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

commit r10-9773-ge06c76270de946c56e9b38a7a87532d7eb72298a
Author: Harald Anlauf 
Date:   Sat Apr 24 20:51:41 2021 +0200

PR fortran/100154 - ICE in gfc_conv_procedure_call, at
fortran/trans-expr.c:6131

Add appropriate static checks for the character and status arguments to
the GNU Fortran intrinsic extensions fget[c], fput[c].  Extend variable
check to allow a function reference having a data pointer result.

gcc/fortran/ChangeLog:

PR fortran/100154
* check.c (variable_check): Allow function reference having a data
pointer result.
(arg_strlen_is_zero): New function.
(gfc_check_fgetputc_sub): Add static check of character and status
arguments.
(gfc_check_fgetput_sub): Likewise.
* intrinsic.c (add_subroutines): Fix argument name for the
character argument to intrinsic subroutines fget[c], fput[c].

gcc/testsuite/ChangeLog:

PR fortran/100154
* gfortran.dg/pr100154.f90: New test.

(cherry picked from commit d0e7833b94953ba6b4a915150666969ad9fc66af)

[Bug libstdc++/100290] join_view::_Iterator::operator++ copies _M_parent->_M_inner when _S_ref_is_glvalue is false

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

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

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

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

commit r11-8310-gc6a94ee07e378632c4fcea2eead30a18ce15a6c3
Author: Patrick Palka 
Date:   Tue Apr 27 14:07:46 2021 -0400

libstdc++: Fix up lambda in join_view::_Iterator::operator++ [PR100290]

Currently, the return type of this lambda is decltype(auto), so the
lambda ends up returning a copy of _M_parent->_M_inner rather than a
reference to it when _S_ref_glvalue is false.  This means _M_inner and
ranges::end(__inner_range) are respectively an iterator and sentinel for
different ranges, so comparing them is undefined.

libstdc++-v3/ChangeLog:

PR libstdc++/100290
* include/std/ranges (join_view::_Iterator::operator++): Correct
the return type of the lambda to avoid returning a copy of
_M_parent->_M_inner.
* testsuite/std/ranges/adaptors/join.cc (test10): New test.

(cherry picked from commit 85ef4b8d4eb3313a48b79c7e752891f9646bb246)

[Bug c++/99683] Deduction failure when using CTAD of CNTTP inside a deduction guide

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

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

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

https://gcc.gnu.org/g:9532344edcf77c7c7b0fa5da31c1b9dd2850288e

commit r11-8309-g9532344edcf77c7c7b0fa5da31c1b9dd2850288e
Author: Patrick Palka 
Date:   Sat Apr 24 00:14:29 2021 -0400

c++: do_class_deduction and dependent init [PR93383]

Here we're crashing during CTAD with a dependent initializer (performed
from convert_template_argument) because one of the initializer's
elements has an empty TREE_TYPE, which ends up making resolve_args
unhappy.

Besides the case where we're initializing one template placeholder
from another, which is already specifically handled earlier in
do_class_deduction, it seems we can't in general correctly resolve a
template placeholder using a dependent initializer, so this patch makes
the function just punt until instantiation time instead.

gcc/cp/ChangeLog:

PR c++/89565
PR c++/93383
PR c++/95291
PR c++/99200
PR c++/99683
* pt.c (do_class_deduction): Punt if the initializer is
type-dependent.

gcc/testsuite/ChangeLog:

PR c++/89565
PR c++/93383
PR c++/95291
PR c++/99200
PR c++/99683
* g++.dg/cpp2a/nontype-class39.C: Remove dg-ice directive.
* g++.dg/cpp2a/nontype-class45.C: New test.
* g++.dg/cpp2a/nontype-class46.C: New test.
* g++.dg/cpp2a/nontype-class47.C: New test.
* g++.dg/cpp2a/nontype-class48.C: New test.

(cherry picked from commit bcd77b7b9f35bd5b559ed593c3b3e346c1e6f364)

[Bug c++/99200] __PRETTY_FUNCTION__ used as template parameter causes internal compiler error (segmentation fault)

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:9532344edcf77c7c7b0fa5da31c1b9dd2850288e

commit r11-8309-g9532344edcf77c7c7b0fa5da31c1b9dd2850288e
Author: Patrick Palka 
Date:   Sat Apr 24 00:14:29 2021 -0400

c++: do_class_deduction and dependent init [PR93383]

Here we're crashing during CTAD with a dependent initializer (performed
from convert_template_argument) because one of the initializer's
elements has an empty TREE_TYPE, which ends up making resolve_args
unhappy.

Besides the case where we're initializing one template placeholder
from another, which is already specifically handled earlier in
do_class_deduction, it seems we can't in general correctly resolve a
template placeholder using a dependent initializer, so this patch makes
the function just punt until instantiation time instead.

gcc/cp/ChangeLog:

PR c++/89565
PR c++/93383
PR c++/95291
PR c++/99200
PR c++/99683
* pt.c (do_class_deduction): Punt if the initializer is
type-dependent.

gcc/testsuite/ChangeLog:

PR c++/89565
PR c++/93383
PR c++/95291
PR c++/99200
PR c++/99683
* g++.dg/cpp2a/nontype-class39.C: Remove dg-ice directive.
* g++.dg/cpp2a/nontype-class45.C: New test.
* g++.dg/cpp2a/nontype-class46.C: New test.
* g++.dg/cpp2a/nontype-class47.C: New test.
* g++.dg/cpp2a/nontype-class48.C: New test.

(cherry picked from commit bcd77b7b9f35bd5b559ed593c3b3e346c1e6f364)

[Bug c++/95291] ICE in resolve_args at gcc/cp/call.c:4482

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

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:9532344edcf77c7c7b0fa5da31c1b9dd2850288e

commit r11-8309-g9532344edcf77c7c7b0fa5da31c1b9dd2850288e
Author: Patrick Palka 
Date:   Sat Apr 24 00:14:29 2021 -0400

c++: do_class_deduction and dependent init [PR93383]

Here we're crashing during CTAD with a dependent initializer (performed
from convert_template_argument) because one of the initializer's
elements has an empty TREE_TYPE, which ends up making resolve_args
unhappy.

Besides the case where we're initializing one template placeholder
from another, which is already specifically handled earlier in
do_class_deduction, it seems we can't in general correctly resolve a
template placeholder using a dependent initializer, so this patch makes
the function just punt until instantiation time instead.

gcc/cp/ChangeLog:

PR c++/89565
PR c++/93383
PR c++/95291
PR c++/99200
PR c++/99683
* pt.c (do_class_deduction): Punt if the initializer is
type-dependent.

gcc/testsuite/ChangeLog:

PR c++/89565
PR c++/93383
PR c++/95291
PR c++/99200
PR c++/99683
* g++.dg/cpp2a/nontype-class39.C: Remove dg-ice directive.
* g++.dg/cpp2a/nontype-class45.C: New test.
* g++.dg/cpp2a/nontype-class46.C: New test.
* g++.dg/cpp2a/nontype-class47.C: New test.
* g++.dg/cpp2a/nontype-class48.C: New test.

(cherry picked from commit bcd77b7b9f35bd5b559ed593c3b3e346c1e6f364)

[Bug c++/93383] ICE on accessing field of a structure which is non-type template parameter, -std=c++2a

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

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

--- Comment #14 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:9532344edcf77c7c7b0fa5da31c1b9dd2850288e

commit r11-8309-g9532344edcf77c7c7b0fa5da31c1b9dd2850288e
Author: Patrick Palka 
Date:   Sat Apr 24 00:14:29 2021 -0400

c++: do_class_deduction and dependent init [PR93383]

Here we're crashing during CTAD with a dependent initializer (performed
from convert_template_argument) because one of the initializer's
elements has an empty TREE_TYPE, which ends up making resolve_args
unhappy.

Besides the case where we're initializing one template placeholder
from another, which is already specifically handled earlier in
do_class_deduction, it seems we can't in general correctly resolve a
template placeholder using a dependent initializer, so this patch makes
the function just punt until instantiation time instead.

gcc/cp/ChangeLog:

PR c++/89565
PR c++/93383
PR c++/95291
PR c++/99200
PR c++/99683
* pt.c (do_class_deduction): Punt if the initializer is
type-dependent.

gcc/testsuite/ChangeLog:

PR c++/89565
PR c++/93383
PR c++/95291
PR c++/99200
PR c++/99683
* g++.dg/cpp2a/nontype-class39.C: Remove dg-ice directive.
* g++.dg/cpp2a/nontype-class45.C: New test.
* g++.dg/cpp2a/nontype-class46.C: New test.
* g++.dg/cpp2a/nontype-class47.C: New test.
* g++.dg/cpp2a/nontype-class48.C: New test.

(cherry picked from commit bcd77b7b9f35bd5b559ed593c3b3e346c1e6f364)

[Bug c++/89565] [C++2a] ICE on template instantiating user defined non-type template from template value member

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:9532344edcf77c7c7b0fa5da31c1b9dd2850288e

commit r11-8309-g9532344edcf77c7c7b0fa5da31c1b9dd2850288e
Author: Patrick Palka 
Date:   Sat Apr 24 00:14:29 2021 -0400

c++: do_class_deduction and dependent init [PR93383]

Here we're crashing during CTAD with a dependent initializer (performed
from convert_template_argument) because one of the initializer's
elements has an empty TREE_TYPE, which ends up making resolve_args
unhappy.

Besides the case where we're initializing one template placeholder
from another, which is already specifically handled earlier in
do_class_deduction, it seems we can't in general correctly resolve a
template placeholder using a dependent initializer, so this patch makes
the function just punt until instantiation time instead.

gcc/cp/ChangeLog:

PR c++/89565
PR c++/93383
PR c++/95291
PR c++/99200
PR c++/99683
* pt.c (do_class_deduction): Punt if the initializer is
type-dependent.

gcc/testsuite/ChangeLog:

PR c++/89565
PR c++/93383
PR c++/95291
PR c++/99200
PR c++/99683
* g++.dg/cpp2a/nontype-class39.C: Remove dg-ice directive.
* g++.dg/cpp2a/nontype-class45.C: New test.
* g++.dg/cpp2a/nontype-class46.C: New test.
* g++.dg/cpp2a/nontype-class47.C: New test.
* g++.dg/cpp2a/nontype-class48.C: New test.

(cherry picked from commit bcd77b7b9f35bd5b559ed593c3b3e346c1e6f364)

[Bug fortran/100218] Allow target of the pointer resulting from the evaluation of function-reference in a variable definition context

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
Fixed on mainline for gcc-12, and on 11-branch.  Closing.

[Bug fortran/100218] Allow target of the pointer resulting from the evaluation of function-reference in a variable definition context

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

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:5aee8c2a33ae0d3f375ed0ca6e03718b284d2574

commit r11-8308-g5aee8c2a33ae0d3f375ed0ca6e03718b284d2574
Author: Harald Anlauf 
Date:   Sat Apr 24 20:38:06 2021 +0200

Fortran - allow target of pointer from evaluation of function-reference

Fortran allows the target of a pointer from the evaluation of a
function-reference in a variable definition context (e.g. F2018:R902).

gcc/fortran/ChangeLog:

PR fortran/100218
* expr.c (gfc_check_vardef_context): Extend check to allow pointer
from a function reference.

gcc/testsuite/ChangeLog:

PR fortran/100218
* gfortran.dg/ptr-func-4.f90: New test.

(cherry picked from commit 32c4d970ea3a9fc330d6aa8fd83f9dae0b9afc64)

[Bug fortran/100154] [9/10/11/12 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.c:6131

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

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

--- Comment #11 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:

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

commit r11-8307-g3efd52599ae47e8084f9485cd4c84b17419273ba
Author: Harald Anlauf 
Date:   Sat Apr 24 20:51:41 2021 +0200

PR fortran/100154 - ICE in gfc_conv_procedure_call, at
fortran/trans-expr.c:6131

Add appropriate static checks for the character and status arguments to
the GNU Fortran intrinsic extensions fget[c], fput[c].  Extend variable
check to allow a function reference having a data pointer result.

gcc/fortran/ChangeLog:

PR fortran/100154
* check.c (variable_check): Allow function reference having a data
pointer result.
(arg_strlen_is_zero): New function.
(gfc_check_fgetputc_sub): Add static check of character and status
arguments.
(gfc_check_fgetput_sub): Likewise.
* intrinsic.c (add_subroutines): Fix argument name for the
character argument to intrinsic subroutines fget[c], fput[c].

gcc/testsuite/ChangeLog:

PR fortran/100154
* gfortran.dg/pr100154.f90: New test.

(cherry picked from commit d0e7833b94953ba6b4a915150666969ad9fc66af)

[Bug c++/94492] no way to silence -Wdeprecated-copy for aggregates

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug fortran/100274] [9/10/11/12 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.c:6131

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
Patch: https://gcc.gnu.org/pipermail/fortran/2021-April/056000.html

[Bug fortran/100297] FAIL: gfortran.dg/allocatable_function_1.f90 gfortran.dg/reshape_8.f90

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

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
This is on x86_64-linux.  I don't see these failures in the results recently
reported to gcc-testresults.

Pr83904 also reports some failures in the Fortran test suite, including
gfortran.dg/allocatable_function_1.f90

[Bug fortran/100297] New: FAIL: gfortran.dg/allocatable_function_1.f90 gfortran.dg/reshape_8.f90

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

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

Bug ID: 100297
   Summary: FAIL: gfortran.dg/allocatable_function_1.f90
gfortran.dg/reshape_8.f90
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

A build of today's trunk of GCC 12 shows the following test failures in the
Fortran test suite:

Running /test/src/gcc/master/gcc/testsuite/gfortran.dg/dg.exp ...
FAIL: gfortran.dg/allocatable_function_1.f90   -O0   scan-tree-dump-times
original "free" 10
FAIL: gfortran.dg/allocatable_function_1.f90   -O1   scan-tree-dump-times
original "free" 10
FAIL: gfortran.dg/allocatable_function_1.f90   -O2   scan-tree-dump-times
original "free" 10
FAIL: gfortran.dg/allocatable_function_1.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions   scan-tree-dump-times
original "free" 10
FAIL: gfortran.dg/allocatable_function_1.f90   -O3 -g   scan-tree-dump-times
original "free" 10
FAIL: gfortran.dg/allocatable_function_1.f90   -Os   scan-tree-dump-times
original "free" 10
FAIL: gfortran.dg/reshape_8.f90   -O   scan-tree-dump-times original "data" 4

=== gfortran Summary ===

# of expected passes13
# of unexpected failures7

[Bug ada/98171] adaint.c doesn't compile on AIX 7.2

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

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

--- Comment #1 from David Edelsohn  ---
gcc119 should be functioning again.

[Bug ada/95549] [9/10/11/12 regression] gnat1 doesn't link on AIX

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

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

David Edelsohn  changed:

   What|Removed |Added

 CC||dje at gcc dot gnu.org

--- Comment #3 from David Edelsohn  ---
I don't know why the vtable is not emitted.  It seems that it should be in
gcc-rich-location.o. This could be a situation of a conflict between a symbol
label and a symbol qualname.  The AIX backend has special code to try to handle
it.  I'm unsure why it's failing for gnat1 and not other languages.

[Bug fortran/100274] [9/10/11/12 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.c:6131

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

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
The patch in comment#1 would turn the ICE into an accepts-invalid, since
we would only get a warning instead of an error.  This happens because
the character length check in gfc_compare_actual_formal returns too early
after emitting the warning.

The simplest fix would be to continue doing the checking:

diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index 60736123550..9e3e8aa9da9 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -3255,10 +3255,13 @@ gfc_compare_actual_formal (gfc_actual_arglist **ap,
gfc_formal_arglist *formal,
  && f->sym->attr.flavor != FL_PROCEDURE)
{
  if (a->expr->ts.type == BT_CHARACTER && !f->sym->as && where)
-   gfc_warning (0, "Character length of actual argument shorter "
-"than of dummy argument %qs (%lu/%lu) at %L",
-f->sym->name, actual_size, formal_size,
->expr->where);
+   {
+ gfc_warning (0, "Character length of actual argument shorter "
+  "than of dummy argument %qs (%lu/%lu) at %L",
+  f->sym->name, actual_size, formal_size,
+  >expr->where);
+ goto skip_size_check;
+   }
   else if (where)
{
  /* Emit a warning for -std=legacy and an error otherwise. */

This regtests cleanly and allows to emit the same error message as for
matching character length.

[Bug target/89096] [8/9/10/11/12 regression] AIX 7 linker rejects _.ro_ sections by default

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

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

David Edelsohn  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WONTFIX

[Bug c/100293] MinGW-w64 of nvptx offload engine fails

[brechtsanders at users dot sourceforge.net via Gcc-bugs]

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

--- Comment #3 from Brecht Sanders  
---
My bad, yes I was using nvptx-tools (master from
https://github.com/MentorEmbedded/nvptx-tools).

my configure command for nvptx offload engine looks like this
./configure --prefix=/R/winlibs64_stage/inst_gcc-offload-nvptx-11.1.0/share/gcc
--build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=nvptx-none
--enable-as-accelerator-for=x86_64-w64-mingw32
--with-build-time-tools=/d/Prog/winlibs64_stage/custombuilt/share/nvptx-tools/nvptx-none/bin
--with-gnu-as --with-gnu-ld --disable-serial-configure
--enable-checking=release --without-libbacktrace --without-included-gettext
--without-cuda-driver --enable-multiarch --enable-newlib-io-long-long
--enable-linker-build-id --enable-multilib --disable-sjlj-exceptions
--disable-libunwind-exceptions --disable-libgomp
--enable-languages=c,c++,lto,objc,obj-c++,d

So yes, --disable-sjlj-exceptions --enable-newlib-io-long-long is there.

Note that the same build scripts worked fine with GCC 10.3.0 and older.

[Bug c++/92145] -Wdeprecated-copy false-positive when inheriting base assignment operators

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

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

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

https://gcc.gnu.org/g:37846c42f1f5ac4d9ba190d49c4373673c89c8b5

commit r12-175-g37846c42f1f5ac4d9ba190d49c4373673c89c8b5
Author: Jason Merrill 
Date:   Fri Apr 23 16:41:35 2021 -0400

c++: -Wdeprecated-copy and using operator= [PR92145]

For the purpose of [depr.impldec] "if the class has a user-declared copy
assignment operator", an operator= brought in from a base class with
'using'
may be a copy-assignment operator, but it isn't a copy-assignment operator
for the derived class.

gcc/cp/ChangeLog:

PR c++/92145
* class.c (classtype_has_depr_implicit_copy): Check DECL_CONTEXT
of operator=.

gcc/testsuite/ChangeLog:

PR c++/92145
* g++.dg/cpp0x/depr-copy3.C: New test.

[Bug c++/100296] [10.x regression] offsetof with non-constant-expression offset no longer accepted in C++ mode

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Jakub Jelinek  ---
Dup.

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

[Bug c++/95942] [11 regression] offsetof on an array: error: 'e' is not a constant expression

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||davem at devkitpro dot org

--- Comment #7 from Jakub Jelinek  ---
*** Bug 100296 has been marked as a duplicate of this bug. ***

[Bug bootstrap/100246] [11/12 Regression] GCC will not bootstrap with clang 3.4/3.5 [xcode 5/6, Darwin 12/13]

[gcc--- via Gcc-bugs]

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

Denis Excoffier  changed:

   What|Removed |Added

 CC||g...@denis-excoffier.org

--- Comment #2 from Denis Excoffier  ---
My linux (2.6.32-39-pve) fails bootstrapping recent GCC 11.1.0 using
gcc (Debian 4.9.2-10+deb8u2) 4.9.2, with the following errors:

In file included from
/tmp/lcl/tmp/gcc/gcc-11.1.0/gcc/config/i386/i386-options.c:94:0:
/tmp/lcl/tmp/gcc/gcc-11.1.0/gcc/config/i386/x86-tune-costs.h:32:56: error:
uninitialized const member 'stringop_algs::stringop_strategy::max'
   {rep_prefix_1_byte, {{-1, rep_prefix_1_byte, false;
^
/tmp/lcl/tmp/gcc/gcc-11.1.0/gcc/config/i386/x86-tune-costs.h:32:56: warning:
missing initializer for member 'stringop_algs::stringop_strategy::max'
[-Wmissing-field-initializers]
/tmp/lcl/tmp/gcc/gcc-11.1.0/gcc/config/i386/x86-tune-costs.h:32:56: error:
uninitialized const member 'stringop_algs::stringop_strategy::alg'
(...hundreds of similar messages...)

Applying this patch clears the issue.

[Bug c++/100296] New: [10.x regression] offsetof with non-constant-expression offset no longer accepted in C++ mode

[davem at devkitpro dot org via Gcc-bugs]

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

Bug ID: 100296
   Summary: [10.x regression] offsetof with
non-constant-expression offset no longer accepted in
C++ mode
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: davem at devkitpro dot org
  Target Milestone: ---

The following code compiles fine as C but produces " error: 'idx' is not a
constant expression" with gcc 11.1.0

#include 
#include 

struct foo
{
uint8_t things[12];
};

uintptr_t getThing(const unsigned idx)
{
return offsetof(struct foo, things[idx]);
}

The code compiles fine with gcc 6.x through 10.x

gcc 5.x says "error: 'idx' cannot appear in a constant-expression"

[Bug tree-optimization/100292] [12 Regression] ICE: verify_gimple failed: invalid operands in ternary operation (during GIMPLE pass: veclower) with vectors

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||jakub at gcc dot gnu.org
   Last reconfirmed||2021-04-27
 Ever confirmed|0   |1
   Target Milestone|--- |12.0

--- Comment #1 from Jakub Jelinek  ---
Started with r12-117-gb972e036f40c12b106f9070c3e8adea0eb8a45fa

[Bug fortran/100276] [12 regression] Many failures after r12-119

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

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

--- Comment #2 from Tobias Burnus  ---
(In reply to Thomas Schwinge from comment #1)
> Yeah, sorry for that -- unfortunate difference in diagnostics for GCC build
> configuration without vs. with offloading enabled. [...] now resolved.

Namely by the commit r12-135-gbd7ebe9da745a62184052dd1b15f4dd10fbdc9f4 – which
also explains the background. (In between was
r12-130-g5a26ba75de623f75fb44cddc2a9c982d31c96213, which did not help.)

[Bug c/100293] MinGW-w64 of nvptx offload engine fails

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Did you follow https://gcc.gnu.org/wiki/Offloading
in particular have you installed nvptx-tools, linked in the right nvptx newlib,
added --disable-sjlj-exceptions --enable-newlib-io-long-long
?
PTX doesn't use binutils, but uses nvptx-tools instead.

[Bug fortran/100276] [12 regression] Many failures after r12-119

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

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

Thomas Schwinge  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
   Assignee|unassigned at gcc dot gnu.org  |burnus at gcc dot 
gnu.org
 Target|powerpc64-linux-gnu |
  Build|powerpc64-linux-gnu |
   Host|powerpc64-linux-gnu |
 CC|kischde at gmx dot net |tschwinge at gcc dot 
gnu.org
   Keywords||openacc

--- Comment #1 from Thomas Schwinge  ---
Yeah, sorry for that -- unfortunate difference in diagnostics for GCC build
configuration without vs. with offloading enabled.  See

and following; now resolved.

[Bug target/94177] TLS global-dynamic model clobbers function parameter on AIX

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

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

David Edelsohn  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |12.0

--- Comment #3 from David Edelsohn  ---
Fixed.

[Bug c/100293] MinGW-w64 of nvptx offload engine fails

[brechtsanders at users dot sourceforge.net via Gcc-bugs]

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

--- Comment #1 from Brecht Sanders  
---
Also tried with unpatched binutils 2.36.1, same outcome.

Building GCC targetting nvptx (--target=nvptx-none) also stops with the same
error. libatomic/config.log reports:

configure:3756: checking whether the C compiler works
configure:3778:
/R/winlibs64_stage/nvptx-gcc-11.1.0/gcc-11.1.0/build_nvptx_gcc/./gcc/xgcc
-B/R/winlibs64_stage/nvptx-gcc-11.1.0/gcc-11.1.0/build_nvptx_gcc/./gcc/
-nostdinc
-B/R/winlibs64_stage/nvptx-gcc-11.1.0/gcc-11.1.0/build_nvptx_gcc/nvptx-none/newlib/
-isystem
/R/winlibs64_stage/nvptx-gcc-11.1.0/gcc-11.1.0/build_nvptx_gcc/nvptx-none/newlib/targ-include
-isystem /R/winlibs64_stage/nvptx-gcc-11.1.0/gcc-11.1.0/newlib/libc/include
-B/R/winlibs64_stage/inst_nvptx-gcc-11.1.0/share/nvptx-gcc/nvptx-none/bin/
-B/R/winlibs64_stage/inst_nvptx-gcc-11.1.0/share/nvptx-gcc/nvptx-none/lib/
-isystem
/R/winlibs64_stage/inst_nvptx-gcc-11.1.0/share/nvptx-gcc/nvptx-none/include
-isystem
/R/winlibs64_stage/inst_nvptx-gcc-11.1.0/share/nvptx-gcc/nvptx-none/sys-include
   -g -O2   conftest.c  >&5
error reading R:\winlibs64_stage\_TMP_\ccKq7IbV.o
collect2.exe: error: ld returned 1 exit status

[Bug c++/100295] New: Internal compiler error from generic lambda capturing parameter pack and expanding it in if constexpr

[davidfromonline at gmail dot com via Gcc-bugs]

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

Bug ID: 100295
   Summary: Internal compiler error from generic lambda capturing
parameter pack and expanding it in if constexpr
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: davidfromonline at gmail dot com
  Target Milestone: ---

The following well-formed translation unit

```
template
void f(Ts... ts) {
auto lambda = [=](auto x) {
if constexpr (sizeof((..., ts), x) != 0) {
(..., ts);
}
};
lambda(0);
}

void g() {
f(0);
}
```

causes gcc to crash with

```
: In instantiation of ‘f(int):: [with auto:1 =
int]’:
:8:8:   required from ‘void f(Ts ...) [with Ts = {int}]’
:12:3:   required from here
:5:31: internal compiler error: trying to capture ‘ts#0’ in
instantiation of generic lambda
5 | (..., ts);
  |   ^~
0x9c9318 add_capture(tree_node*, tree_node*, tree_node*, bool, bool)
../../source/gcc/cp/lambda.c:637
0x9c9391 add_default_capture(tree_node*, tree_node*, tree_node*)
../../source/gcc/cp/lambda.c:697
0xaa68ef tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../source/gcc/cp/pt.c:20834
0xaa3ea8 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../source/gcc/cp/pt.c:20949
0xaaf3d7 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../source/gcc/cp/pt.c:19204
0xaae9d1 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../source/gcc/cp/pt.c:18229
0xaae9d1 gen_elem_of_pack_expansion_instantiation
../../source/gcc/cp/pt.c:12568
0xaae9d1 tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*)
../../source/gcc/cp/pt.c:13233
0xaa163f tsubst_fold_expr_pack
../../source/gcc/cp/pt.c:12646
0xaa163f tsubst_unary_left_fold
../../source/gcc/cp/pt.c:12685
0xaa163f tsubst_copy
../../source/gcc/cp/pt.c:17343
0xaa56f2 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../source/gcc/cp/pt.c:20962
0xaaf3d7 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../source/gcc/cp/pt.c:19204
0xab11f9 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../source/gcc/cp/pt.c:18274
0xab0aa3 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../source/gcc/cp/pt.c:18595
0xab4503 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../source/gcc/cp/pt.c:18564
0xab0aa3 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../source/gcc/cp/pt.c:18595
0xab0aa3 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../source/gcc/cp/pt.c:18595
0xab8308 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../source/gcc/cp/pt.c:18229
0xab8308 instantiate_body
../../source/gcc/cp/pt.c:25921
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
Compiler returned: 1
```

[Bug c++/100279] [ICE in trunk] ICE caused by negative double NTTP. Error: Two symbols with same comdat_group are not linked by the same_comdat_group list.

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

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

Patrick Palka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||ppalka at gcc dot gnu.org
   Last reconfirmed||2021-04-27
 Ever confirmed|0   |1
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=98216

--- Comment #4 from Patrick Palka  ---
Confirmed, seems closely related to PR98216.

[Bug c++/88580] Parameter pack expansion fails (variadic constructor template inside a variadic class template)

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

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

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #6 from Patrick Palka  ---
Thanks for the bug report.  This should now be fixed for GCC 12.

[Bug analyzer/100294] New: need attribute takes_ownership

[felix-gcc at fefe dot de via Gcc-bugs]

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

Bug ID: 100294
   Summary: need attribute takes_ownership
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: felix-gcc at fefe dot de
  Target Milestone: ---

Now that -fanalyzer is here to track leaking memory, I need a way to tell gcc
that a function takes ownership of a pointer.

You could call it takes_ownership or maybe free.

Here's my setup: I have a function that does I/O batching for you. You have a
batch as a context variable, then you add buffers to it, then you write the
whole batch to a descriptor (or callback). The idea is that the descriptor can
point to a non-blocking socket and the abstraction takes care of repeatedly
writing the next bit in the vector after a partial write.

Anyway, I have a function that adds a buffer to the batch, and I have a
function that adds a buffer to the batch plus the batch takes ownership of the
pointer, i.e. when you are done with the batch and close it, all those pointers
will be freed.

-fanalyze now (rightly) complains that I'm leaking the memory of the pointer I
gave to the function that takes ownership.

I need a way to either say "takes ownership" or maybe, even better, a way to
say how the free will happen, so malloc+free matching in gcc 11 can apply.

[Bug c++/88580] Parameter pack expansion fails (variadic constructor template inside a variadic class template)

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:37d2b98100cefcb9d312d379473c12aa6d61fc62

commit r12-174-g37d2b98100cefcb9d312d379473c12aa6d61fc62
Author: Patrick Palka 
Date:   Tue Apr 27 14:18:25 2021 -0400

c++: Fix Bases(args...)... base initialization [PR88580]

When substituting into the arguments of a base initializer pack
expansion, tsubst_initializer_list uses a dummy EXPR_PACK_EXPANSION
in order to expand an initializer such as Bases(args)... into
Bases#{0}(args#{0}) and so on.  But when an argument inside the base
initializer is itself a pack expansion, as in Bases(args...)..., the
argument is already an EXPR_PACK_EXPANSION so we don't need to wrap it.
It's also independent from the outer expansion of Bases, so we need to
"multiplicatively" append the expansion of args... onto the argument
list of each expanded base.

gcc/cp/ChangeLog:

PR c++/88580
* pt.c (tsubst_initializer_list): Correctly handle the case
where an argument inside a base initializer pack expansion is
itself a pack expansion.

gcc/testsuite/ChangeLog:

PR c++/88580
* g++.dg/cpp0x/variadic182.C: New test.

[Bug libstdc++/100290] join_view::_Iterator::operator++ copies _M_parent->_M_inner when _S_ref_is_glvalue is false

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:85ef4b8d4eb3313a48b79c7e752891f9646bb246

commit r12-173-g85ef4b8d4eb3313a48b79c7e752891f9646bb246
Author: Patrick Palka 
Date:   Tue Apr 27 14:07:46 2021 -0400

libstdc++: Fix up lambda in join_view::_Iterator::operator++ [PR100290]

Currently, the return type of this lambda is decltype(auto), so the
lambda ends up returning a copy of _M_parent->_M_inner rather than a
reference to it when _S_ref_glvalue is false.  This means _M_inner and
ranges::end(__inner_range) are respectively an iterator and sentinel for
different ranges, so comparing them is undefined.

libstdc++-v3/ChangeLog:

PR libstdc++/100290
* include/std/ranges (join_view::_Iterator::operator++): Correct
the return type of the lambda to avoid returning a copy of
_M_parent->_M_inner.
* testsuite/std/ranges/adaptors/join.cc (test10): New test.

[Bug fortran/97571] long parsing phase for simple array constructor

[molah at ucar dot edu via Gcc-bugs]

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

--- Comment #9 from Mark J Olah  ---
Thank you Karl and Jerry for the suggestions on transforming the code.  It is
not my own code, and I cannot modify it.  It is however correct Fortran code,
that currently builds fine with GCC 10.2.0, and all other Fortran compilers I
have access to.  I would like to be able to continue to compile this code with
modern GCC-10.3.0+, but that is not practically possible without resolving this
severe performance issue.

I have read the explanation of the code generation, but this fails to explain
why GCC is implementing an *exponential* algorithm to compute what should be a
*linear  complexity* operation.

Moreover, testing shows the expense cannot be a result of MPFR.  I can compute
32k acos() computations with MPFR to 53 bits of precision in about 3 sec.  Also
MPFR shows a perfectly linear scaling with N.

Therefore the remaining ~1920 sec of compilation time representing 99.8% of the
runtime must be spent doing something wasteful, and the exponential dependence
on N is a result of a poor internal algorithm that is implemented by GCC.  

I would expect a compiler must do a reasonable job to compile correct Fortran
code in a reasonable amount of time.  The response for reporting significant
algorithmic internal deficiencies of a compiler cannot be "change your code",
otherwise the solution of your users will have to be "change the compiler".

[Bug c/100293] New: MinGW-w64 of nvptx offload engine fails

[brechtsanders at users dot sourceforge.net via Gcc-bugs]

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

Bug ID: 100293
   Summary: MinGW-w64 of nvptx offload engine fails
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: brechtsanders at users dot sourceforge.net
  Target Milestone: ---

Created attachment 50691
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50691=edit
libatomic/config.log

When doing a Windows native build of the GCC 11.1.0 nvptx offload engine on
Windows using MinGW-w64 and binutils 2.36.1 with:
--target=nvptx-none --enable-as-accelerator-for=x86_64-w64-mingw32
or:
--target=nvptx-none --enable-as-accelerator-for=i686-w64-mingw32
the following error is shown:

configure: error: in
`/R/winlibs64_stage/gcc-offload-nvptx-11.1.0/gcc-11.1.0/build_win_offload-nvptx/nvptx-none/libatomic':
configure: error: C compiler cannot create executables
See `config.log' for more details

Note that binutils is version 2.36.1 but had patches applied as advises in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 as these were needed to
build the earlier GCC 11 snapshots.

[Bug tree-optimization/100284] ICE in operation_could_trap_p with -march=armv8.2-a+sve -O3

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Richard Sandiford :

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

commit r12-168-gd0a57b030f1c7df33c6bc3c661d16c9cb79e96dd
Author: Richard Sandiford 
Date:   Tue Apr 27 18:30:36 2021 +0100

Fix handling of VEC_COND_EXPR trap tests [PR100284]

Now that VEC_COND_EXPR has normal unnested operands,
operation_could_trap_p can treat it like any other expression.

This fixes many testsuite ICEs for SVE, but it turns out that none
of the tests in gcc.target/aarch64/sve were affected.  Anyone testing
on non-SVE aarch64 therefore wouldn't have seen it.

gcc/
PR middle-end/100284
* gimple.c (gimple_could_trap_p_1): Remove VEC_COND_EXPR test.
* tree-eh.c (operation_could_trap_p): Handle VEC_COND_EXPR rather
than asserting on it.

gcc/testsuite/
PR middle-end/100284
* gcc.target/aarch64/sve/pr81003.c: New test.

[Bug c++/100291] [8/9/10/11/12 Regression] internal compiler error: trying to capture ‘this’ in instantiation of generic lambda

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

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

Marek Polacek  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |8.5
   Keywords||ice-on-invalid-code
Summary|internal compiler error:|[8/9/10/11/12 Regression]
   |trying to capture ‘this’ in |internal compiler error:
   |instantiation of generic|trying to capture ‘this’ in
   |lambda  |instantiation of generic
   ||lambda
 CC||nathan at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
I think this is ICE-on-invalid.  Started with r245065:

/home/mpolacek/w.C:119:57: internal compiler error: in
finish_member_declaration, at cp/semantics.c:2969
[&](auto, auto cmp) { SingleStepper::time(cmp.state); });
  ~~~^~~
0x9ac65b finish_member_declaration(tree_node*)
../../gcc/cp/semantics.c:2966
0xa52ce3 add_capture(tree_node*, tree_node*, tree_node*, bool, bool)
../../gcc/cp/lambda.c:600
0xa53090 add_default_capture(tree_node*, tree_node*, tree_node*)
../../gcc/cp/lambda.c:669
0xa538dd lambda_expr_this_capture(tree_node*, bool)
../../gcc/cp/lambda.c:760
0xa53ca1 maybe_resolve_dummy(tree_node*, bool)
../../gcc/cp/lambda.c:827
0x787891 build_new_method_call_1
../../gcc/cp/call.c:8760
0x787f30 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../../gcc/cp/call.c:8870
0x83ef22 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:17279
0x83a881 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:16401
0x834e7e tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:15669
0x8369b0 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:15879
0x8369b0 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:15879
0x858968 instantiate_decl(tree_node*, int, bool)
../../gcc/cp/pt.c:22817
0x8c2790 maybe_instantiate_decl
../../gcc/cp/decl2.c:5008
0x8c3060 mark_used(tree_node*, int)
../../gcc/cp/decl2.c:5107
0x784968 build_over_call
../../gcc/cp/call.c:8088
0x77593c build_op_call_1
../../gcc/cp/call.c:4518
0x775acc build_op_call(tree_node*, vec**, int)
../../gcc/cp/call.c:4544
0x9aa173 finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc/cp/semantics.c:2458
0x83ef56 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:17286

[Bug tree-optimization/100292] New: [12 Regression] ICE: verify_gimple failed: invalid operands in ternary operation (during GIMPLE pass: veclower) with vectors

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 100292
   Summary: [12 Regression] ICE: verify_gimple failed: invalid
operands in ternary operation (during GIMPLE pass:
veclower) with vectors
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

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

This seems to be a recent regression; r12-100 is OK, r12-159 is BAD.
I searched the bug database, and even though I am triggering this often on
various targets, I didn't find any duplicate.

Compiler output:
$ x86_64-pc-linux-gnu-gcc testcase.c
testcase.c: In function 'foo':
testcase.c:6:1: error: invalid operands in ternary operation
6 | foo (char c)
  | ^~~
_13 = (signed char) c.1_2 >= 0 ? -1 : 0;
during GIMPLE pass: veclower
testcase.c:6:1: internal compiler error: verify_gimple failed
0x10b888a verify_gimple_in_cfg(function*, bool)
/repo/gcc-trunk/gcc/tree-cfg.c:5507
0xf6f67f execute_function_todo
/repo/gcc-trunk/gcc/passes.c:2042
0xf704f3 do_per_function
/repo/gcc-trunk/gcc/passes.c:1687
0xf704f3 execute_todo
/repo/gcc-trunk/gcc/passes.c:2096
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

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

[Bug c++/100291] New: internal compiler error: trying to capture ‘this’ in instantiation of generic lambda

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

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

Bug ID: 100291
   Summary: internal compiler error: trying to capture ‘this’ in
instantiation of generic lambda
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

template  struct integral_constant {
  static constexpr _Tp value = __v;
};
template  using bool_constant = integral_constant;
template  struct conditional;
template  struct __and_;
template 
struct __and_<_B1, _B2> : conditional<_B2>::type {};
template  _Up __declval(int);
template  auto declval() -> decltype(__declval<_Tp>(0));
template  struct conditional { typedef _Iftrue type; };
template  using void_t = void;
template  struct iterator_traits;
template  struct iterator_traits<_Tp *> {
  typedef _Tp reference;
};
struct pointer_traits {
  template  using rebind = _Up *;
};
template  class __normal_iterator {
public:
  typename iterator_traits<_Iterator>::reference operator*();
};
template  class allocator {
public:
  typedef _Tp value_type;
};
template  struct allocator_traits {
  template  struct _Ptr {
using type = pointer_traits::rebind<_Tp>;
  };
  using const_pointer = typename _Ptr::type;
};
template  struct _Vector_base {
  typedef allocator_traits<_Alloc> _Tp_alloc_type;
};
template > class vector {
  typedef typename _Vector_base<_Alloc>::_Tp_alloc_type _Alloc_traits;
public:
  __normal_iterator begin() const;
};
template  class, class...> struct detector;
template  class Op, class... Args>
struct detector>, Op, Args...> {
  using value_t = integral_constant;
};
template  class Op, class... Args>
using is_detected = typename detector::value_t;
template 
constexpr bool require = __and_...>::value;
template  class M,
  typename... Arguments>
constexpr bool has_method = M::template tv::value;
template  struct time_t {
  template  struct fptr_meta {
template 
using type =
integral_constant()...))
(T_::*)(
  Arguments_...) const,
  _::time>;
  };
  template 
  using fptr_meta_t = typename fptr_meta::template type;
  template  struct tv {
static constexpr bool value = is_detected::value;
  };
};
template  struct output_step_size_t {
  template  struct fptr_meta {
template 
using type =
integral_constant()...)) (T_::*)(Arguments_...)
  const,
  _::outputStepSize>;
  };
  template 
  using fptr_meta_t = typename fptr_meta::template type;
  template  struct tv {
static constexpr bool value = is_detected::value;
  };
};
template 
struct Trans_NS_Stepper_StepperConcept {
  constexpr static bool time_exists =
  has_method;
  constexpr static bool output_step_size_exists =
  has_method;
  constexpr static bool value = require;
};
template 
constexpr bool StepperConcept =
Trans_NS_Stepper_StepperConcept::value;
template  class Propagator {
  static_assert(StepperConcept);
};
template  class EigenStepper {
public:
  struct State {};
  void time(State);
};
template 
void accumulate(_InputIterator __first, _Tp __init,
_BinaryOperation __binary_op) {
  __binary_op(__init, *__first);
}
template 
class MultiEigenStepper : EigenStepper<> {
public:
  using SingleStepper = EigenStepper;
  using SingleState = State;
  struct State {
struct Component {
  SingleState state;
};
vector components;
  };
  void time(const State ) const {
accumulate(state.components.begin(), 0.0,
   [&](auto, auto cmp) { SingleStepper::time(cmp.state); });
  }
  void outputStepSize(const State &) const;
};
using MultiStepper = MultiEigenStepper<>;
using MultiPropagator = Propagator;
MultiPropagator makePropagator() { return {}; }

gives

$ ./cc1plus -quiet w.C
w.C: In instantiation of ‘MultiEigenStepper<>::time(const
MultiEigenStepper<>::State&) const:: [with auto:1 =
double; auto:2 = MultiEigenStepper<>::State::Component]’:
w.C:104:14:   required from ‘void accumulate(_InputIterator, _Tp,
_BinaryOperation) [with _InputIterator =
__normal_iterator::State::Component*>; _Tp = double;
_BinaryOperation = MultiEigenStepper<>::time(const MultiEigenStepper<>::State&)
const::]’
w.C:118:15:   required from ‘void
MultiEigenStepper::time(const
MultiEigenStepper::State&) const [with extensionlist_t = int]’
w.C:60:27:   required by substitution of ‘template template template using type =
integral_constant)()...))
(T_::*)(Arguments_ ...) const, (& T_::time)> [with Arguments_ = {const
MultiEigenStepper<>::State&}; T_ = MultiEigenStepper<>; T =
MultiEigenStepper<>;  = double; Arguments = {const
MultiEigenStepper<>::State&}]’
w.C:63:9:   required by substitution of ‘template template using fptr_meta_t =
typename time_t,
Arguments>::fptr_meta::type [with T_ = 

[Bug testsuite/100272] some incomplete dg-commands

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

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Sebor  ---
Fixed.

[Bug testsuite/100272] some incomplete dg-commands

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

https://gcc.gnu.org/g:2ae2a45c287d254c2890feff2cca46ed2ddb06ca

commit r12-167-g2ae2a45c287d254c2890feff2cca46ed2ddb06ca
Author: Martin Sebor 
Date:   Tue Apr 27 11:00:53 2021 -0600

Remove malformed dg-warning directives.

gcc/testsuite/ChangeLog:
PR testsuite/100272
* g++.dg/ext/flexary13.C: Remove malformed directives.

[Bug c++/100161] [10/11 Regression] Impossible to suppress Wtype-limits warning involving template parameter.

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Marek Polacek
:

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

commit r11-8306-gfb7c736c2f17ad054ee7815b688fa91135690f6d
Author: Marek Polacek 
Date:   Tue Apr 20 20:24:09 2021 -0400

c++: Prevent bogus -Wtype-limits warning with NTTP [PR100161]

Recently, we made sure that we never call value_dependent_expression_p
on an expression that isn't potential_constant_expression.  That caused
this bogus warning with a non-type template parameter, something that
users don't want to see.

The problem is that in tsubst_copy_and_build/LE_EXPR 't' is "i < n",
which, due to 'i', is not p_c_e, therefore we call t_d_e_p.  But the
type of 'n' isn't dependent, so we think the whole 't' expression is
not dependent.  It seems we need to test both op0 and op1 separately
to suppress this warning.

gcc/cp/ChangeLog:

PR c++/100161
* pt.c (tsubst_copy_and_build) : Test op0 and
op1 separately for value- or type-dependence.

gcc/testsuite/ChangeLog:

PR c++/100161
* g++.dg/warn/Wtype-limits6.C: New test.

(cherry picked from commit 244dfb95119106e9267f37583caac565c39eb0ec)

[Bug c++/96380] [10/11 Regression] ICE in tree check: expected integer_cst, have view_convert_expr in get_len, at tree.h:5954

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

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Marek Polacek
:

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

commit r11-8305-gaf53e450e5c61e36bd01aa2db1251483a60be007
Author: Marek Polacek 
Date:   Tue Apr 20 12:16:04 2021 -0400

c++: Don't allow defining types in enum-base [PR96380]

In r11-2064 I made cp_parser_enum_specifier commit to tentative parse
when seeing a '{'.  That still looks like the correct thing to do, but
it caused an ICE-on-invalid as well as accepts-invalid.

When we have something sneaky like this, which is broken in multiple
ways:

  template 
  enum struct c : union enum struct c { e = b, f = a };

we parse the "enum struct c" part (that's OK) and then we see that
we have an enum-base, so we consume ':' and then parse the type-specifier
that follows the :.  "union enum" is clearly invalid, but we're still
parsing tentatively and we parse everything up to the ;, and then
throw away the underlying type.  We parsed everything because we were
tricked into parsing an enum-specifier in an enum-base of another
enum-specifier!  Not good.

Since the grammar for enum-base doesn't allow a defining-type-specifier,
only a type-specifier, we should set type_definition_forbidden_message
which fixes all the problems in this PR.

gcc/cp/ChangeLog:

PR c++/96380
* parser.c (cp_parser_enum_specifier): Don't allow defining
types in enum-base.

gcc/testsuite/ChangeLog:

PR c++/96380
* g++.dg/cpp0x/enum_base4.C: New test.
* g++.dg/cpp0x/enum_base5.C: New test.

(cherry picked from commit 001c63d15e31bc0a1545426d889a0b9f671b4961)

[Bug target/94177] TLS global-dynamic model clobbers function parameter on AIX

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by David Edelsohn :

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

commit r12-165-ga21b399708175f6fc0ac723a0cebc127da421c60
Author: David Edelsohn 
Date:   Sun Apr 11 19:41:26 2021 -0400

aix: TLS precompute register parameters (PR 94177)

AIX uses a compiler-managed TOC for global data, including TLS symbols.
The GCC TOC implementation manages the TOC entries through the constant
pool.

TLS symbols sometimes require a function call to obtain the TLS base
pointer.  The arguments to the TLS call can conflict with arguments to
a normal function call if the TLS symbol is an argument in the normal call.
GCC specifically checks for this situation and precomputes the TLS
arguments, but the mechanism to check for this requirement utilizes
legitimate_constant_p().  The necessary result of legitimate_constant_p()
for correct TOC behavior and for correct TLS argument behavior is in
conflict.

This patch adds a new target hook precompute_tls_p() to decide if an
argument should be precomputed regardless of the result from
legitmate_constant_p().

gcc/ChangeLog:

PR target/94177
* calls.c (precompute_register_parameters): Additionally test
targetm.precompute_tls_p to pre-compute argument.
* config/rs6000/aix.h (TARGET_PRECOMPUTE_TLS_P): Define.
* config/rs6000/rs6000.c (rs6000_aix_precompute_tls_p): New.
* target.def (precompute_tls_p): New.
* doc/tm.texi.in (TARGET_PRECOMPUTE_TLS_P): Add hook documentation.
* doc/tm.texi: Regenerated.

[Bug c++/97533] ICE encountering operator() within lambda expression within templated struct

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Fixed by r11-7418.

[Bug target/99912] Unnecessary / inefficient spilling of AVX2 ymm registers

[schnetter at gmail dot com via Gcc-bugs]

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

--- Comment #11 from Erik Schnetter  ---
The number of active local variables is likely much larger than the number of
registers, and I expect there to be a lot of spilling. I hope that the compiler
is clever about changing the order in which expressions are evaluated to reduce
spilling as much as possible.

Because the loop is so large, I split it into two, each calculating about half
of the output variables. The code here looks at one of the loops. To simplify
the code, each loop still loads all variables (via masked loads), but may not
use all of them. The unused masked loads do not surprise me per se, but I
expect the compiler to remove them.

[Bug target/100200] [10 Regression] UB evaluating aarch64_plus_immediate predicate

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:

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

commit r11-8303-ge89e883a450126d021874536ae102f60a1cacb78
Author: Jakub Jelinek 
Date:   Tue Apr 27 17:50:53 2021 +0200

aarch64: Fix up last commit [PR100200]

Pedantically signed vs. unsigned mismatches in va_arg are only well defined
if the value can be represented in both signed and unsigned integer types.

2021-04-27  Jakub Jelinek  

PR target/100200
* config/aarch64/aarch64.c (aarch64_print_operand): Cast -UINTVAL
back to HOST_WIDE_INT.

(cherry picked from commit 1c0c371d0ea297af2e3180c64cd18f2bfce919b1)

[Bug target/100200] [10 Regression] UB evaluating aarch64_plus_immediate predicate

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

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

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

https://gcc.gnu.org/g:1c0c371d0ea297af2e3180c64cd18f2bfce919b1

commit r12-164-g1c0c371d0ea297af2e3180c64cd18f2bfce919b1
Author: Jakub Jelinek 
Date:   Tue Apr 27 17:50:53 2021 +0200

aarch64: Fix up last commit [PR100200]

Pedantically signed vs. unsigned mismatches in va_arg are only well defined
if the value can be represented in both signed and unsigned integer types.

2021-04-27  Jakub Jelinek  

PR target/100200
* config/aarch64/aarch64.c (aarch64_print_operand): Cast -UINTVAL
back to HOST_WIDE_INT.

[Bug target/100106] [10/11 Regression] ICE in gen_movdi, at config/arm/arm.md:6187 since r10-2840-g70cdb21e

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

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

Bernd Edlinger  changed:

   What|Removed |Added

Summary|[10/11/12 Regression] ICE   |[10/11 Regression] ICE in
   |in gen_movdi, at|gen_movdi, at
   |config/arm/arm.md:6187  |config/arm/arm.md:6187
   |since r10-2840-g70cdb21e|since r10-2840-g70cdb21e
 Status|NEW |ASSIGNED

--- Comment #5 from Bernd Edlinger  ---
fixed on trunk

[Bug target/100106] [10/11/12 Regression] ICE in gen_movdi, at config/arm/arm.md:6187 since r10-2840-g70cdb21e

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Bernd Edlinger :

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

commit r12-163-gc33db31d9ad96f6414460315c12b4b505fad5dd7
Author: Bernd Edlinger 
Date:   Wed Apr 21 14:13:04 2021 +0200

Fix target/100106 ICE in gen_movdi

As the test case shows, the outer mode may have a higher alignment
requirement than the inner mode here.

2021-04-27  Bernd Edlinger  

PR target/100106
* simplify-rtx.c (simplify_context::simplify_subreg): Check the
memory alignment for the outer mode.

* gcc.c-torture/compile/pr100106.c: New testcase.

[Bug libgcc/98952] powerpc*: __trampoline_setup inverted test for trampoline size

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

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #9 from Michael Meissner  ---
Patches applied to trunk, GCC 11, GCC 10, GCC 9, and GCC 8 branches.

[Bug libstdc++/100249] missing forwarding std::__invoke result in ranges::is_permutation and ranges::clamp

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

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

--- Comment #4 from Patrick Palka  ---
(In reply to 康桓瑋 from comment #0)
> when the type of __proj_val is an rvalue reference, we need to convert it to
> rvalue for the next std::__invoke call: https://godbolt.org/z/1G7aqxs3c.

So it seems the projection application limit of 3 makes it impossible for
ranges::clamp to perfectly support the case where the projection returns an
rvalue reference.

[Bug libstdc++/99277] C++2a synchronisation is inefficient in GCC 11

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|11.2|12.0

--- Comment #9 from Jonathan Wakely  ---
Agreed

[Bug libstdc++/100249] missing forwarding std::__invoke result in ranges::is_permutation and ranges::clamp

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

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

--- Comment #3 from Patrick Palka  ---
(In reply to 康桓瑋 from comment #0)
> So I think it should be relatively safe to inline all std::__invoke calls.

I'm not sure we can inline these std::__invoke calls actually, because the
standard has strict limits about the number of times these algorithms can apply
the projection function, see https://eel.is/c++draft/alg.is.permutation#7 and
https://eel.is/c++draft/alg.clamp#5.

So if we e.g. inlined __proj_val in ranges::clamp, we'd be performing up to 4
projection applications instead of 3.

[Bug tree-optimization/100284] ICE in operation_could_trap_p with -march=armv8.2-a+sve -O3

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

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

--- Comment #5 from Alex Coplan  ---
Ok, so Gilles: it would still be useful if you could attach a preprocessed
testcase and post the backtrace you're seeing with GCC 11.

[Bug middle-end/90773] Improve piecewise operation

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

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

commit r12-162-g3bb41228d76b3a3cbd9923d57388f0903f7683de
Author: H.J. Lu 
Date:   Mon Apr 26 15:36:18 2021 -0700

op_by_pieces_d::run: Change a while loop to a do-while loop

Change a while loop in op_by_pieces_d::run to a do-while loop to prepare
for offset adjusted operation for the remaining bytes on the last piece
operation of a memory region.

PR middle-end/90773
* expr.c (op_by_pieces_d::get_usable_mode): New member function.
(op_by_pieces_d::run): Cange a while loop to a do-while loop.

[Bug c/99363] [10,11 regression] gcc.dg/attr-flatten-1.c fails starting with r11-7469

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

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

Jason Merrill  changed:

   What|Removed |Added

   Target Milestone|11.2|10.4
 Resolution|--- |FIXED
 Status|REOPENED|RESOLVED

--- Comment #9 from Jason Merrill  ---
Indeed.

[Bug c++/100281] ICE with SImode pointer assignment in C++

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

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

Andreas Krebbel  changed:

   What|Removed |Added

  Attachment #50685|0   |1
is obsolete||

--- Comment #5 from Andreas Krebbel  ---
Created attachment 50689
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50689=edit
Fixed patch with testcase

[Bug c/99363] [10,11 regression] gcc.dg/attr-flatten-1.c fails starting with r11-7469

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

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

--- Comment #8 from Hans-Peter Nilsson  ---
Shouldn't this be closed as fixed?

[Bug target/93372] cris performance regressions due to de-cc0 work

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

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

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

--- Comment #9 from Hans-Peter Nilsson  ---
Whoops, this should be closed.  All observed related regressions were fixed for
gcc-11.

[Bug libgcc/98952] powerpc*: __trampoline_setup inverted test for trampoline size

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Michael Meissner
:

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

commit r11-8302-g9e80a135fffa5c1b36b6007e7e57d303535fbe84
Author: Michael Meissner 
Date:   Tue Apr 27 10:52:57 2021 -0400

[PATCH] Backport fix for PR target/98952

The test in the PowerPC 32-bit trampoline support is backwards.  It aborts
if the trampoline size is greater than the expected size.  It should abort
when the trampoline size is less than the expected size.  I fixed the test
so the operands are reversed.  I then folded the load immediate into the
compare instruction.

I verified this by creating a 32-bit trampoline program and manually
changing the size of the trampoline to be 48 instead of 40.  The program
aborted with the larger size.  I updated this code and ran the test again
and it passed.

I added a test case that runs on PowerPC 32-bit Linux systems and it calls
the __trampoline_setup function with a larger buffer size than the
compiler uses.  The test is not run on 64-bit systems, since the function
__trampoline_setup is not called.  I also limited the test to just Linux
systems, in case trampolines are handled differently in other systems.

libgcc/
2021-04-27  Michael Meissner  

PR target/98952
* config/rs6000/tramp.S (__trampoline_setup, elfv1 #ifdef): Fix
trampoline size comparison in 32-bit by reversing test and
combining load immediate with compare.  Fix backported from trunk
change on 4/23, 886b6c1e8af502b69e3f318b9830b73b88215878.
(__trampoline_setup, elfv2 #ifdef): Fix trampoline size comparison
in 32-bit by reversing test and combining load immediate with
compare.

gcc/testsuite/
2021-04-27  Michael Meissner  

PR target/98952
* gcc.target/powerpc/pr98952.c: New test.  Test backported from
trunk change on 4/23, 886b6c1e8af502b69e3f318b9830b73b88215878.

[Bug c++/86594] Crash on trying to capture 'this' in instantiation of generic lambda

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

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

Marek Polacek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
Fixed for GCC 9+.

[Bug c++/89522] [8 Regression] ICE: trying to capture 'f' in instantiation of generic lambda

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

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #4 from Marek Polacek  ---
Fixed, testcase added.

[Bug libstdc++/99277] C++2a synchronisation is inefficient in GCC 11

[thiago at kde dot org via Gcc-bugs]

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

--- Comment #8 from Thiago Macieira  ---
This one is probably 12.0.

[Bug target/99977] arm: ICE with __sync_bool_compare_and_swap and -mcpu=cortex-m23

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

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

--- Comment #5 from Alex Coplan  ---
Fixed for trunk so far, needs backports.

[Bug target/99912] Unnecessary / inefficient spilling of AVX2 ymm registers

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

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

--- Comment #10 from Richard Biener  ---
So with the latest patches I now see real spilling dominating (oops).  I also
see, on the GIMPLE level

  _64425 = (unsigned long) SR.3210_122492;
  _64416 = _64425 + ivtmp.5307_121062;
  _62971 = (double &) _64416;
  __builtin_ia32_maskloadpd256 (_62971, _61513);

that is, dead masked loads (that's odd).

There's also still some dead / redundant code from the abstraction to remove.

[Bug target/100200] [10 Regression] UB evaluating aarch64_plus_immediate predicate

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[10/11/12 Regression] UB|[10 Regression] UB
   |evaluating  |evaluating
   |aarch64_plus_immediate  |aarch64_plus_immediate
   |predicate   |predicate

--- Comment #6 from Jakub Jelinek  ---
Fixed on the trunk and for 11.2 so far.

[Bug tree-optimization/100239] [10 Regression] ICE: in expand_expr_real_2, at expr.c:9865 with __builtin_shuffle()

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[10/11/12 Regression] ICE:  |[10 Regression] ICE: in
   |in expand_expr_real_2, at   |expand_expr_real_2, at
   |expr.c:9865 with|expr.c:9865 with
   |__builtin_shuffle() |__builtin_shuffle()

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

[Bug target/99977] arm: ICE with __sync_bool_compare_and_swap and -mcpu=cortex-m23

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Alex Coplan :

https://gcc.gnu.org/g:42a10bb884c0d5af2583b8bfe4d239ce95bf9e43

commit r12-161-g42a10bb884c0d5af2583b8bfe4d239ce95bf9e43
Author: Alex Coplan 
Date:   Tue Apr 27 14:56:15 2021 +0100

arm: Fix ICEs with compare-and-swap and -march=armv8-m.base [PR99977]

The PR shows two ICEs with __sync_bool_compare_and_swap and
-mcpu=cortex-m23 (equivalently, -march=armv8-m.base): one in LRA and one
later on, after the CAS insn is split.

The LRA ICE occurs because the
@atomic_compare_and_swap_1 pattern attempts to tie
two output operands together (operands 0 and 1 in the third
alternative). LRA can't handle this, since it doesn't make sense for an
insn to assign to the same operand twice.

The later (post-splitting) ICE occurs because the expansion of the
cbranchsi4_scratch insn doesn't quite go according to plan. As it
stands, arm_split_compare_and_swap calls gen_cbranchsi4_scratch,
attempting to pass a register (neg_bval) to use as a scratch register.
However, since the RTL template has a match_scratch here,
gen_cbranchsi4_scratch ignores this argument and produces a scratch rtx.
Since this is all happening after RA, this is doomed to fail (and we get
an ICE about the insn not matching its constraints).

It seems that the motivation for the choice of constraints in the
atomic_compare_and_swap pattern comes from an attempt to satisfy the
constraints of the cbranchsi4_scratch insn. This insn requires the
scratch register to be the same as the input register in the case that
we use a larger negative immediate (one that satisfies J, but not L).

Of course, as noted above, LRA refuses to assign two output operands to
the same register, so this was never going to work.

The solution I'm proposing here is to collapse the alternatives to the
CAS insn (allowing the two output register operands to be matched to
different registers) and to ensure that the constraints for
cbranchsi4_scratch are met in arm_split_compare_and_swap. We do this by
inserting a move to ensure the source and destination registers match if
necessary (i.e. in the case of large negative immediates).

Another notable change here is that we only do:

  emit_move_insn (neg_bval, const1_rtx);

for non-negative immediates. This is because the ADDS instruction used in
the negative case suffices to leave a suitable value in neg_bval: if the
operands compare equal, we don't take the branch (so neg_bval will be
set by the load exclusive). Otherwise, the ADDS will leave a nonzero
value in neg_bval, which will correctly signal that the CAS has failed
when it is later negated.

gcc/ChangeLog:

PR target/99977
* config/arm/arm.c (arm_split_compare_and_swap): Fix up codegen
with negative immediates: ensure we expand cbranchsi4_scratch
correctly and ensure we satisfy its constraints.
* config/arm/sync.md
(@atomic_compare_and_swap_1): Don't
attempt to tie two output operands together with constraints;
collapse two alternatives.
(@atomic_compare_and_swap_1): Likewise.
* config/arm/thumb1.md (cbranchsi4_neg_late): New.

gcc/testsuite/ChangeLog:

PR target/99977
* gcc.target/arm/pr99977.c: New test.

[Bug target/100200] [10/11/12 Regression] UB evaluating aarch64_plus_immediate predicate

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:

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

commit r11-8301-g3fe1c1fd0eb5e4bbc1af313b3e9dd4605ec5a134
Author: Jakub Jelinek 
Date:   Tue Apr 27 15:46:16 2021 +0200

aarch64: Fix UB in the compiler [PR100200]

The following patch fixes UBs in the compiler when negativing
a CONST_INT containing HOST_WIDE_INT_MIN.  I've changed the spots where
there wasn't an obvious earlier condition check or predicate that
would fail for such CONST_INTs.

2021-04-27  Jakub Jelinek  

PR target/100200
* config/aarch64/predicates.md (aarch64_sub_immediate,
aarch64_plus_immediate): Use -UINTVAL instead of -INTVAL.
* config/aarch64/aarch64.md (casesi, rotl3): Likewise.
* config/aarch64/aarch64.c (aarch64_print_operand,
aarch64_split_atomic_op, aarch64_expand_subvti): Likewise.

(cherry picked from commit 618ae596ebcd1de03857d20485d1324931852569)

[Bug tree-optimization/100239] [10/11/12 Regression] ICE: in expand_expr_real_2, at expr.c:9865 with __builtin_shuffle()

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

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

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

https://gcc.gnu.org/g:80dc24f813a9d8951d75eea7324f6d713b872bca

commit r11-8300-g80dc24f813a9d8951d75eea7324f6d713b872bca
Author: Jakub Jelinek 
Date:   Tue Apr 27 15:42:47 2021 +0200

veclower: Fix up vec_shl matching of VEC_PERM_EXPR [PR100239]

The following testcase ICEs at -O0, because lower_vec_perm sees the
  _1 = { 0, 0, 0, 0, 0, 0, 0, 0 };
  _2 = VEC_COND_EXPR <_1, { -1, -1, -1, -1, -1, -1, -1, -1 }, { 0, 0, 0, 0,
0, 0, 0, 0 }>;
  _3 = { 6, 0, 0, 0, 0, 0, 0, 0 };
  _4 = VEC_PERM_EXPR <{ 0, 0, 0, 0, 0, 0, 0, 0 }, _2, _3>;
and as the ISA is SSE2, there is no support for the particular permutation
nor for variable mask permutation.  But, the code to match vec_shl matches
it, because the permutation has the first operand a zero vector and the
mask picks all elements randomly from that vector.
So, in the end that isn't a vec_shl, but the permutation could be in theory
optimized into the first argument.  As we keep it as is, it will fail
during expansion though, because that for vec_shl correctly requires that
it actually is a shift:
  unsigned firstidx = 0;
  for (unsigned int i = 0; i < nelt; i++)
{
  if (known_eq (sel[i], nelt))
{
  if (i == 0 || firstidx)
return NULL_RTX;
  firstidx = i;
}
  else if (firstidx
   ? maybe_ne (sel[i], nelt + i - firstidx)
   : maybe_ge (sel[i], nelt))
return NULL_RTX;
}

  if (firstidx == 0)
return NULL_RTX;
  first = firstidx;
The if (firstidx == 0) return NULL; is what is missing a counterpart
on the lower_vec_perm side.
As with optimize != 0 we fold it in other spots, I think it is not needed
to optimize this cornercase in lower_vec_perm (which would mean we'd need
to recurse on the newly created _4 = { 0, 0, 0, 0, 0, 0, 0, 0 };
whether it is supported or not).

2021-04-27  Jakub Jelinek  

PR tree-optimization/100239
* tree-vect-generic.c (lower_vec_perm): Don't accept constant
permutations with all indices from the first zero element as
vec_shl.

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

(cherry picked from commit 83d26d0e1b3625ab6c2d83610a13976b52f63e0a)