[Bug libgomp/99984] New: bootstrap failure on uclibc for libgomp. error: 'local_thr' may be used uninitialized [-Werror=maybe-uninitialized]

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 99984
   Summary: bootstrap failure on uclibc for libgomp. error:
'local_thr' may be used uninitialized
[-Werror=maybe-uninitialized]
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Makefile:873: warning: overriding recipe for target 'all-multi'
Makefile:864: warning: ignoring old recipe for target 'all-multi'
Makefile:873: warning: overriding recipe for target 'all-multi'
Makefile:864: warning: ignoring old recipe for target 'all-multi'
Makefile:873: warning: overriding recipe for target 'all-multi'
Makefile:864: warning: ignoring old recipe for target 'all-multi'
../../../../gcc/libgomp/team.c: In function 'gomp_thread_start':
../../../../gcc/libgomp/team.c:81:3: error: 'local_thr' may be used
uninitialized [-Werror=maybe-uninitialized]
   81 |   pthread_setspecific (gomp_tls_key, thr);
  |   ^~~
In file included from ../../../../gcc/libgomp/libgomp.h:50,
 from ../../../../gcc/libgomp/team.c:29:
D:/msys64/x86_64-linux-uclibc/x86_64-linux-uclibc/include/pthread.h:595:12:
note: by argument 2 of type 'const void *' to 'pthread_setspecific' declared
here
  595 | extern int pthread_setspecific (pthread_key_t __key,
  |^~~
../../../../gcc/libgomp/team.c:79:22: note: 'local_thr' declared here
   79 |   struct gomp_thread local_thr;
  |  ^
cc1.exe: all warnings being treated as errors
make[4]: *** [Makefile:798: team.lo] Error 1
make[3]: *** [Makefile:1021: all-recursive] Error 1
make[2]: *** [Makefile:622: all] Error 2
make[1]: *** [Makefile:16010: all-target-libgomp] Error 2
make[1]: *** Waiting for unfinished jobs
make: *** [Makefile:976: all] Error 2

[Bug libstdc++/99433] [11 Regression] custom friend pipe-operator| conflicts with range adaptor?

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

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

--- Comment #6 from Patrick Palka  ---
(In reply to gcc-bugs from comment #5)
> Thank you for the fix, but the following code does not compile any more:
> 
> ```c++
> #include 
> #include 
> 
> int main()
> {
>   std::list list;
> 
>   constexpr auto drop = [](urng_t &&
> urange, size_t drop_size)
>   {
> // does not work:
> return std::forward(urange) | std::views::drop(drop_size);
> 
> // does work:
> // return std::forward(urange) | std::views::drop(0);
>   };
>   drop(list, 0);
> }
> ```
> 
> Should I open a new issue?

Reduced:

#include 
#include 

int main() {
  std::list list;
  std::views::drop(list, 0ul);
}

The constraint satisfaction failure diagnostic says:

libstdc++-v3/include/std/ranges:2100:10:   required for the satisfaction of
‘__can_drop_view<_Range, _Tp>’ [with _Range = std::__cxx11::list >&; _Tp = lon
g unsigned int]
libstdc++-v3/include/std/ranges:2101:6:   in requirements  [with _Tp = long
unsigned int; _Range = std::__cxx11::list >&]
libstdc++-v3/include/std/ranges:2101:24: note: the required expression
‘drop_view<...auto...>{declval<_Range>(), declval<_Tp>()}’ is invalid, because
 2101 |   = requires { drop_view{std::declval<_Range>(),
std::declval<_Tp>()}; };
  |   
^~

but it strangely doesn't explain why the expression is invalid.  Turns out if
we pass -Wsystem-headers to the command line, then we do get an explanation in
the form of a warning:


libstdc++-v3/include/std/ranges:2101:24: warning: narrowing conversion of
‘std::declval()’ from ‘long unsigned int’ to
‘std::ranges::range_difference_t
> >’ {aka ‘long int’} [-Wnarrowing]

So I suppose we're correct to reject the testcase, since narrowing conversions
aren't permitted in braced init lists (and views​::​drop(E, F) is specified to
be expression-equivalent to the braced init ranges​::​drop_­view{E, F}).

But it's perhaps a frontend bug that we need to pass -Wsystem-headers to get
the warning here in the first place; I'll file a PR for this issue.

[Bug bootstrap/99983] [10 regression] ICE in bootstrap while building libstdc++

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

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 Target||powerpc64*-linux-gnu
   Host||powerpc64*-linux-gnu
  Build||powerpc64*-linux-gnu

--- Comment #1 from seurer at gcc dot gnu.org ---
The failures shown were on a power 8 LE system for
g:348fb9db7858b0fe852da3cd1195b90b2211b983, r10-9675.  I have something running
to look for what revision started it.

[Bug bootstrap/99983] New: [10 regression] ICE in bootstrap while building libstdc++

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

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

Bug ID: 99983
   Summary: [10 regression] ICE in bootstrap while building
libstdc++
   Product: gcc
   Version: 10.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

make[3]: Entering directory
'/home/seurer/gcc/git/build/gcc-10-test/powerpc64le-unknown-linux-gnu/libstdc++-v3'
make "AR_FLAGS=rc" "CC_FOR_BUILD=gcc"
"CC_FOR_TARGET=/home/seurer/gcc/git/build/gcc-10-test/./gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-10-test/./gcc/" "CFLAGS=-g -O2" "CXXFLAGS=-g
-O2 -D_GNU_SOURCE" "CFLAGS_FOR_BUILD=-g -O2" "CFLAGS_FOR_TARGET=-g -O2"
"INSTALL=/usr/bin/install -c" "INSTALL_DATA=/usr/bin/install -c -m 644"
"INSTALL_PROGRAM=/usr/bin/install -c" "INSTALL_SCRIPT=/usr/bin/install -c"
"LDFLAGS=" "LIBCFLAGS=-g -O2" "LIBCFLAGS_FOR_TARGET=-g -O2" "MAKE=make"
"MAKEINFO=makeinfo --split-size=500 --split-size=500
--split-size=500 " "SHELL=/bin/sh" "RUNTESTFLAGS="
"exec_prefix=/home/seurer/gcc/git/install/gcc-10-test"
"infodir=/home/seurer/gcc/git/install/gcc-10-test/share/info"
"libdir=/home/seurer/gcc/git/install/gcc-10-test/lib"
"includedir=/home/seurer/gcc/git/install/gcc-10-test/include"
"prefix=/home/seurer/gcc/git/install/gcc-10-test"
"tooldir=/home/seurer/gcc/git/install/gcc-10-test/powerpc64le-unknown-linux-gnu"
"gxx_include_dir=/home/seurer/gcc/git/install/gcc-10-test/include/c++/10.3.1"
"AR=ar" "AS=/home/seurer/gcc/git/build/gcc-10-test/./gcc/as"
"LD=/home/seurer/gcc/git/build/gcc-10-test/./gcc/collect-ld" "RANLIB=ranlib"
"NM=/home/seurer/gcc/git/build/gcc-10-test/./gcc/nm" "NM_FOR_BUILD="
"NM_FOR_TARGET=nm" "DESTDIR=" "WERROR=" all-recursive
make[4]: Entering directory
'/home/seurer/gcc/git/build/gcc-10-test/powerpc64le-unknown-linux-gnu/libstdc++-v3'
Making all in include
make[5]: Entering directory
'/home/seurer/gcc/git/build/gcc-10-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include'
mkdir -p ./powerpc64le-unknown-linux-gnu/bits/stdc++.h.gch
/home/seurer/gcc/git/build/gcc-10-test/./gcc/xgcc -shared-libgcc
-B/home/seurer/gcc/git/build/gcc-10-test/./gcc -nostdinc++
-L/home/seurer/gcc/git/build/gcc-10-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/src
-L/home/seurer/gcc/git/build/gcc-10-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/seurer/gcc/git/build/gcc-10-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/home/seurer/gcc/git/install/gcc-10-test/powerpc64le-unknown-linux-gnu/bin/
-B/home/seurer/gcc/git/install/gcc-10-test/powerpc64le-unknown-linux-gnu/lib/
-isystem
/home/seurer/gcc/git/install/gcc-10-test/powerpc64le-unknown-linux-gnu/include
-isystem
/home/seurer/gcc/git/install/gcc-10-test/powerpc64le-unknown-linux-gnu/sys-include
  -fno-checking -x c++-header -nostdinc++ -g -O2 -D_GNU_SOURCE 
-I/home/seurer/gcc/git/build/gcc-10-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-10-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/git/gcc-10-test/libstdc++-v3/libsupc++  -O2 -g -std=gnu++0x
/home/seurer/gcc/git/gcc-10-test/libstdc++-v3/include/precompiled/stdc++.h \
-o powerpc64le-unknown-linux-gnu/bits/stdc++.h.gch/O2ggnu++0x.gch
In file included from
/home/seurer/gcc/git/build/gcc-10-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/unordered_map:46,
 from
/home/seurer/gcc/git/gcc-10-test/libstdc++-v3/include/precompiled/stdc++.h:117:
/home/seurer/gcc/git/build/gcc-10-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/hashtable.h:1317:56:
internal compiler error: in merge_exception_specifiers, at cp/typeck2.c:2564
 1317 |   std::is_nothrow_copy_constructible<_Equal>::value)
  |^
0x109e97e3 merge_exception_specifiers(tree_node*, tree_node*)
/home/seurer/gcc/git/gcc-10-test/gcc/cp/typeck2.c:2564
0x109ac773 merge_types(tree_node*, tree_node*)
/home/seurer/gcc/git/gcc-10-test/gcc/cp/typeck.c:873
0x1066ef2b duplicate_decls(tree_node*, tree_node*, bool)
/home/seurer/gcc/git/gcc-10-test/gcc/cp/decl.c:2259
0x1069c1ff grokfndecl
/home/seurer/gcc/git/gcc-10-test/gcc/cp/decl.c:9893
0x106ab2bb grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
/home/seurer/gcc/git/gcc-10-test/gcc/cp/decl.c:13622
0x106bcc37 start_function(cp_decl_specifier_seq*, cp_declarator const*,
tree_node*)
/home/seurer/gcc/git/gcc-10-test/gcc/cp/decl.c:16541
0x1081181f cp_parser_function_definition_from_specifiers_and_declarator
/home/seurer/gcc/git/gcc-10-test/gcc/cp/parser.c:28909
0x107fb643 cp_parser_init_declarator
/home/seurer/gcc/git/gcc-10-test/gcc/cp/parser.c:20694
0x108137b7 cp_parser_single_declaration

[Bug middle-end/90323] powerpc should convert equivalent sequences to vec_sel()

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

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

--- Comment #11 from luoxhu at gcc dot gnu.org ---
I noticed that you added the below optimization with commit
a62436c0a505155fc8becac07a8c0abe2c265bfe. But it doesn't even handle this case,
cse1 pass will call simplify_binary_operation_1, both op0 and op1 are REGs
instead of AND operators, do you have a test case to cover that piece of code?

__attribute__ ((noinline))
 long without_sel3( long l,  long r) {
long tmp = {0x0ff00fff};
l =  ( (l ^ r) & tmp) ^ l;
return l;
}


without_sel3:
xor 4,3,4
rlwinm 4,4,0,20,11
rldicl 4,4,0,36
xor 3,4,3
blr
.long 0
.byte 0,0,0,0,0,0,0,0


+2016-11-09  Segher Boessenkool  
+
+   * simplify-rtx.c (simplify_binary_operation_1): Simplify
+   (xor (and (xor A B) C) B) to (ior (and A C) (and B ~C)) and
+   (xor (and (xor A B) C) A) to (ior (and A ~C) (and B C)) if C
+   is a const_int.

diff --git a/gcc/simplify-rtx.c b/gcc/simplify-rtx.c
index 5c3dea1a349..11a2e0267c7 100644
--- a/gcc/simplify-rtx.c
+++ b/gcc/simplify-rtx.c
@@ -2886,6 +2886,37 @@ simplify_binary_operation_1 (enum rtx_code code,
machine_mode mode,
}
}

+  /* If we have (xor (and (xor A B) C) A) with C a constant we can instead
+do (ior (and A ~C) (and B C)) which is a machine instruction on some
+machines, and also has shorter instruction path length.  */
+  if (GET_CODE (op0) == AND
+ && GET_CODE (XEXP (op0, 0)) == XOR
+ && CONST_INT_P (XEXP (op0, 1))
+ && rtx_equal_p (XEXP (XEXP (op0, 0), 0), trueop1))
+   {
+ rtx a = trueop1;
+ rtx b = XEXP (XEXP (op0, 0), 1);
+ rtx c = XEXP (op0, 1);
+ rtx nc = simplify_gen_unary (NOT, mode, c, mode);
+ rtx a_nc = simplify_gen_binary (AND, mode, a, nc);
+ rtx bc = simplify_gen_binary (AND, mode, b, c);
+ return simplify_gen_binary (IOR, mode, a_nc, bc);
+   }
+  /* Similarly, (xor (and (xor A B) C) B) as (ior (and A C) (and B ~C)) 
*/
+  else if (GET_CODE (op0) == AND
+ && GET_CODE (XEXP (op0, 0)) == XOR
+ && CONST_INT_P (XEXP (op0, 1))
+ && rtx_equal_p (XEXP (XEXP (op0, 0), 1), trueop1))
+   {
+ rtx a = XEXP (XEXP (op0, 0), 0);
+ rtx b = trueop1;
+ rtx c = XEXP (op0, 1);
+ rtx nc = simplify_gen_unary (NOT, mode, c, mode);
+ rtx b_nc = simplify_gen_binary (AND, mode, b, nc);
+ rtx ac = simplify_gen_binary (AND, mode, a, c);
+ return simplify_gen_binary (IOR, mode, ac, b_nc);
+   }

[Bug fortran/99982] New: INTERFACE selects wrong module procedure involving C_PTR and C_FUNPTR

[brtnfld at hdfgroup dot org via Gcc-bugs]

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

Bug ID: 99982
   Summary: INTERFACE selects wrong module procedure involving
C_PTR and C_FUNPTR
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: brtnfld at hdfgroup dot org
  Target Milestone: ---

Created attachment 50532
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50532=edit
program uses interface and module procedure to select between subroutines with
type C_PTR and C_FUNPTR

The attached program always selects the TYPE(C_FUNPTR) when selecting between a
(overloaded) subroutine with TYPE(C_PTR) and TYPE(C_FUNPTR), even when the
variable type is TYPE(C_PTR).

It does this for both passing a variable as the argument or using the C_LOC or
c_funloc directly in the call.

I tried it with 7.5.0, 10.2.0, same behavior.
Intel and NAG both select the correct subroutine.

[Bug libgcc/99964] android(bionic) cannot find crti.o and crtn.o on aarch64

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #9 from cqwrteur  ---
(In reply to Marek Polacek from comment #7)
> Why do you keep adding Jakub to CC?  He's not a mingw maintainer.

You get the same error on Linux hosted system too because gcc needs to find
crti.o and crtn.o for aarch64-linux-android targets, no matter what hosted
system you are. It has nothing to do with MinGW-w64 or Msys2 etc.

[Bug libgcc/99964] android(bionic) cannot find crti.o and crtn.o on aarch64

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #8 from cqwrteur  ---
(In reply to Marek Polacek from comment #7)
> Why do you keep adding Jakub to CC?  He's not a mingw maintainer.

This is not mingw issue. it is libgcc's issue.

[Bug libgcc/99964] android(bionic) cannot find crti.o and crtn.o on aarch64

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #7 from Marek Polacek  ---
Why do you keep adding Jakub to CC?  He's not a mingw maintainer.

[Bug libgcc/99964] android(bionic) cannot find crti.o and crtn.o on aarch64

[unlvsur at live dot com via Gcc-bugs]

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

cqwrteur  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from cqwrteur  ---
Hi Jakub.
Any guideline on how to remove crti.o and crtn.o requirement in libgcc for
aarch64-linux-android? I would like to submit a patch to support android (for
x86_64, i686, armv7 and aarch64) on GCC, including the bug fix of libstdc++.

[Bug libstdc++/99979] [DR 2135] condition_variable_any has wrong behavior if Lock::lock() throws

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2021-04-08
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
Summary|condition_variable_any has  |[DR 2135]
   |wrong behavior if   |condition_variable_any has
   |Lock::lock() throws |wrong behavior if
   ||Lock::lock() throws

--- Comment #2 from Jonathan Wakely  ---
Looks like I tried to implement LWG 2135 in r228217, but only for
std::condition_variable, not std::condition_variable_any.

[Bug libstdc++/99979] condition_variable_any has wrong behavior if Lock::lock() throws

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

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

--- Comment #1 from Jonathan Wakely  ---
The _Unlock type was introduced for PR libstdc++/50862 (and then modified
slightly by PR libstdc++/53830).

[Bug libstdc++/96029] [8 Regression] Inconsistencies with associative/unordered containers

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

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

Jonathan Wakely  changed:

   What|Removed |Added

Summary|[8/9 Regression]|[8 Regression]
   |Inconsistencies with|Inconsistencies with
   |associative/unordered   |associative/unordered
   |containers  |containers
  Known to fail||10.3.0, 8.4.0, 9.3.0

--- Comment #8 from Jonathan Wakely  ---
And 9.4 too.

[Bug libstdc++/96029] [8/9 Regression] Inconsistencies with associative/unordered containers

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jonathan Wakely
:

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

commit r9-9328-g5f63261c3e54995b45dd411ad76526870c4b8be3
Author: François Dumont 
Date:   Mon Jan 20 19:15:43 2020 +0100

libstdc++: Fix unordered containers move constructors noexcept
qualification

_Hashtable move constructor is wrongly qualified as noexcept(true)
regardless of
_Equal and _H1 copy constructor qualifications.
_Hashtable allocator-aware move constructor is missing its noexcept
qualification like the depending unordered containers ones.

This backport also includes the changes from r11-8062 and r11-2438.

libstdc++-v3/ChangeLog:

PR libstdc++/96029
* include/bits/hashtable.h
(_Hashtable(_Hashtable&& __ht, __node_alloc_type&& __a,
true_type)):
Add noexcept qualification.
(_Hashtable(_Hashtable&&)): Fix noexcept qualification.
(_Hashtable(_Hashtable&&, const allocator_type&)): Add noexcept
qualification.
* include/bits/unordered_map.h
(unordered_map(unordered_map&&, const allocator_type&)): Add
noexcept
qualification.
(unordered_multimap(unordered_multimap&&, const allocator_type&)):
Likewise.
* include/bits/unordered_set.h
(unordered_set(unordered_set&&, const allocator_type&)): Likewise.
(unordered_multiset(unordered_multiset&&, const allocator_type&)):
Likewise.
* include/debug/unordered_map
(unordered_map(unordered_map&&, const allocator_type&)): Likewise.
(unordered_multimap(unordered_multimap&&, const allocator_type&)):
Likewise.
* include/debug/unordered_set
(unordered_set(unordered_set&&, const allocator_type&)): Likewise.
(unordered_multiset(unordered_multiset&&, const allocator_type&)):
Likewise.
* testsuite/23_containers/unordered_map/allocator/default_init.cc:
New test.
*
testsuite/23_containers/unordered_map/cons/noexcept_default_construct.cc:
New test.
*
testsuite/23_containers/unordered_map/cons/noexcept_move_construct.cc:
New test.
* testsuite/23_containers/unordered_map/modifiers/move_assign.cc:
New test.
*
testsuite/23_containers/unordered_multimap/cons/noexcept_default_construct.cc:
New test.
*
testsuite/23_containers/unordered_multimap/cons/noexcept_move_construct.cc:
New test.
*
testsuite/23_containers/unordered_multiset/cons/noexcept_default_construct.cc:
New test.
*
testsuite/23_containers/unordered_multiset/cons/noexcept_move_construct.cc:
New test.
* testsuite/23_containers/unordered_set/allocator/default_init.cc:
New test.
*
testsuite/23_containers/unordered_set/cons/noexcept_default_construct.cc:
New test.
*
testsuite/23_containers/unordered_set/cons/noexcept_move_construct.cc:
New test.

(cherry picked from commit 12324b9a934654a5c3bf4a614853ded2e0a958af)

[Bug libstdc++/96029] [8/9 Regression] Inconsistencies with associative/unordered containers

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:1228154b8726a3bc903f1967f9b3aac8fd192e46

commit r9-9327-g1228154b8726a3bc903f1967f9b3aac8fd192e46
Author: François Dumont 
Date:   Fri Jul 3 08:13:19 2020 +0200

libstdc++: Fix [multi]map/[multi]set move constructors noexcept
qualification

Container move constructors shall not consider their allocator move
constructor qualification.

For the backport to gcc-9 the _Rb_tree_impl move constructor must be
user-provided, because prior to the implementation of P1286R2 in
r10-4094, a defaulted special member with a different exception would be
deleted.

libstdc++-v3/ChangeLog:

PR libstdc++/96029
* include/bits/stl_tree.h (_Rb_tree_impl(_Rb_tree_impl&&)): Add
noexcept
qualification based only on _Compare one.
* testsuite/23_containers/map/cons/noexcept_move_construct.cc: Add
static asserts.
* testsuite/23_containers/multimap/cons/noexcept_move_construct.cc:
Likewise.
* testsuite/23_containers/multiset/cons/noexcept_move_construct.cc:
Likewise.
* testsuite/23_containers/set/cons/noexcept_move_construct.cc:
Likewise.

(cherry picked from commit c832cf1c1d114aed70c2f84566cf4d63de0a56d0)

[Bug libstdc++/99433] [11 Regression] custom friend pipe-operator| conflicts with range adaptor?

[gcc-bugs at marehr dot dialup.fu-berlin.de via Gcc-bugs]

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

--- Comment #5 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
Thank you for the fix, but the following code does not compile any more:

```c++
#include 
#include 

int main()
{
  std::list list;

  constexpr auto drop = [](urng_t &&
urange, size_t drop_size)
  {
// does not work:
return std::forward(urange) | std::views::drop(drop_size);

// does work:
// return std::forward(urange) | std::views::drop(0);
  };
  drop(list, 0);
}
```

Should I open a new issue?

[Bug rtl-optimization/99930] Failure to optimize floating point -abs(x) in nontrivial code at -O2/3

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

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

--- Comment #10 from Segher Boessenkool  ---
That is a USE of a constant, which is a no-op always.  Here we have a USE
of a register, which is not.  We actually have *two* uses of pseudos, and
combine cannot know what that means for the target (all PARALLELs are split
up in combine).

[Bug c/99972] missing -Wunused-result on a call to a locally redeclared warn_unused_result function

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

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

Martin Sebor  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
   Last reconfirmed||2021-04-08
   Keywords||patch
 Status|UNCONFIRMED |ASSIGNED

--- Comment #3 from Martin Sebor  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-April/567800.html

[Bug c/99420] [11 Regression] bogus -Warray-parameter on a function redeclaration in function scope

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

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org

--- Comment #6 from Martin Sebor  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-April/567800.html

[Bug tree-optimization/84202] missing -Wnonnull on a returns_nonnull function returning null

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

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2018-08-05 00:00:00 |2021-4-8

--- Comment #4 from Martin Sebor  ---
No progress in GCC 11.

Clang diagnoses the first test case:

$ cat pr84202.c && clang -S -Wall pr84202.c

void* __attribute__ ((returns_nonnull)) f ()
{
  return 0;   // missing -Wnonnull
}
pr84202.c:4:3: warning: null returned from function that requires a non-null
  return value [-Wnonnull]
  return 0;   // missing -Wnonnull
  ^  ~
1 warning generated.

[Bug c++/99241] [modules] ICE in install_entity, at cp/module.cc:7584

[alexander.lelyakin at googlemail dot com via Gcc-bugs]

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

--- Comment #4 from Alexander Lelyakin  ---
The ICE in "install entity" can have different stacktrace. 
Stacktrace is same up to 'module_state::load_section'
but then it has at least two different variants:

1
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header memory
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header streambuf
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header regex

In file included from /usr/local/include/c++/11.0.1/sstream:38,
 from /usr/local/include/c++/11.0.1/regex:46:
/usr/local/include/c++/11.0.1/istream:58:42: internal compiler error: in
install_entity, at cp/module.cc:7468
   58 | class basic_istream : virtual public basic_ios<_CharT, _Traits>
  |  ^
0xa6f888 trees_in::install_entity(tree_node*)
../../gcc/gcc/cp/module.cc:7468
0xa77da6 trees_in::decl_value()
../../gcc/gcc/cp/module.cc:7980
0xa70767 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9153
0xa76d8b module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14811
0xa7728d module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18082
0xa7734f module_state::lazy_load(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18740
0xa715d0 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9664
0xa76a8b module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14717
0xa7728d module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18082
0xa77448 lazy_load_binding(unsigned int, tree_node*, tree_node*, binding_slot*)
../../gcc/gcc/cp/module.cc:18773
0xa8906e name_lookup::search_namespace_only(tree_node*)
../../gcc/gcc/cp/name-lookup.c:928
0xa8a6bb name_lookup::search_unqualified(tree_node*, cp_binding_level*)
../../gcc/gcc/cp/name-lookup.c:1158
0xa8d3c4 lookup_name_1
../../gcc/gcc/cp/name-lookup.c:7804
0xa8d5aa lookup_name(tree_node*, LOOK_where, LOOK_want)
../../gcc/gcc/cp/name-lookup.c:7824
0xa9c282 lookup_name(tree_node*, LOOK_want)
../../gcc/gcc/cp/name-lookup.h:401
0xa9c282 cp_parser_lookup_name
../../gcc/gcc/cp/parser.c:29386
0xac4eef cp_parser_template_name
../../gcc/gcc/cp/parser.c:17711
0xac5432 cp_parser_template_id
../../gcc/gcc/cp/parser.c:17326
0xac5d4b cp_parser_class_name
../../gcc/gcc/cp/parser.c:24703
0xabd1fa cp_parser_qualifying_entity
../../gcc/gcc/cp/parser.c:7002
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

and compare:

2
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header array
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header stdexcept
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header valarray

In file included from /usr/local/include/c++/11.0.1/bits/hashtable.h:35,
 from /usr/local/include/c++/11.0.1/unordered_map:46,
 from /usr/local/include/c++/11.0.1/functional:61,
 from
/usr/local/include/c++/11.0.1/pstl/glue_algorithm_defs.h:13,
 from /usr/local/include/c++/11.0.1/algorithm:74,
 from /usr/local/include/c++/11.0.1/valarray:38:
/usr/local/include/c++/11.0.1/bits/hashtable_policy.h:63:51: internal compiler
error: in install_entity, at cp/module.cc:7468
   63 | inline typename std::iterator_traits<_Iterator>::difference_type
  |   ^
0xa6f888 trees_in::install_entity(tree_node*)
../../gcc/gcc/cp/module.cc:7468
0xa77da6 trees_in::decl_value()
../../gcc/gcc/cp/module.cc:7980
0xa70767 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9153
0xa76d8b module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14811
0xa7728d module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18082
0xa7734f module_state::lazy_load(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18740
0xa715d0 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9664
0xa76a8b module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14717
0xa7728d module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18082
0xa7734f module_state::lazy_load(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18740
0xa715d0 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9664
0xa76a8b module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14717
0xa7728d module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18082
0xa7734f module_state::lazy_load(unsigned int, binding_slot*)

[Bug c++/86879] G++ should warn about redundant tests for null pointers returned from functions with __attribute__((returns_nonnull))

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

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2018-08-07 00:00:00 |2021-4-8

--- Comment #2 from Martin Sebor  ---
No progress in GCC 11.

Clang issues -Wpointer-bool-conversion and -Wundefined-bool-conversion:

 cat pr86879.C && clang -S -Wall pr86879.C
void* get() __attribute__((returns_nonnull));

int f() { return get() ? 0 : 1; }

int& ref();

int g()
{
  return () ? 0 : 1;
}
pr86879.C:3:18: warning: nonnull function call 'get()' will evaluate to 'true'
  on first encounter [-Wpointer-bool-conversion]
int f() { return get() ? 0 : 1; }
 ^ ~
pr86879.C:1:28: note: declared 'returns_nonnull' here
void* get() __attribute__((returns_nonnull));
   ^
pr86879.C:9:11: warning: reference cannot be bound to dereferenced null pointer
  in well-defined C++ code; pointer may be assumed to always convert to
true
  [-Wundefined-bool-conversion]
  return () ? 0 : 1;
  ^ ~
pr86879.C:5:6: note: 'ref' returns a reference
int& ref();
 ^
2 warnings generated.

[Bug middle-end/64463] Add warning: returns_nonnull attribute on a function compared against NULL

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

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2015-07-25 00:00:00 |2021-4-8
 Blocks||87403

--- Comment #6 from Martin Sebor  ---
No progress in GCC 11.

Clang issues -Wpointer-bool-conversion for these cases:

$ cat pr64463.c && clang -S -Wall pr64463.c
__attribute__ ((returns_nonnull)) char* f (void);

void g (void)
{
  if (!f ())
__builtin_abort ();
}
pr64463.c:5:8: warning: nonnull function call 'f()' will evaluate to 'true' on
  first encounter [-Wpointer-bool-conversion]
  if (!f ())
  ~^~~~
pr64463.c:1:17: note: declared 'returns_nonnull' here
__attribute__ ((returns_nonnull)) char* f (void);
^
1 warning generated.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403
[Bug 87403] [Meta-bug] Issues that suggest a new warning

[Bug c++/99879] [modules] ICE in open

[alexander.lelyakin at googlemail dot com via Gcc-bugs]

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

--- Comment #2 from Alexander Lelyakin  ---
The last sequence sometimes gives ICE in open, and sometimes in install entity:

/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header memory
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header cstdio
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header span
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header shared_mutex
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header cstdint
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header clocale
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header bitset
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header semaphore
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header exception
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header numbers
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header charconv
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header locale
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header string
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header ranges
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header cstring
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header regex

In module imported at /usr/local/include/c++/11.0.1/regex:45:1:
/usr/local/include/c++/11.0.1/memory: note: unable to represent further
imported source locations
In file included from /usr/local/include/c++/11.0.1/sstream:38,
 from /usr/local/include/c++/11.0.1/regex:46:
/usr/local/include/c++/11.0.1/istream:58:42: internal compiler error: in
install_entity, at cp/module.cc:7468
   58 | class basic_istream : virtual public basic_ios<_CharT, _Traits>
  |  ^
0xa700a8 trees_in::install_entity(tree_node*)
../../gcc/gcc/cp/module.cc:7468
0xa785c6 trees_in::decl_value()
../../gcc/gcc/cp/module.cc:7980
0xa70f87 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9153
0xa775ab module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14811
0xa77aad module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18082
0xa77b6f module_state::lazy_load(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18740
0xa71df0 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9664
0xa772ab module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14717
0xa77aad module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18082
0xa77b6f module_state::lazy_load(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18740
0xa71df0 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9664
0xa772ab module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14717
0xa77aad module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18082
0xa77c68 lazy_load_binding(unsigned int, tree_node*, tree_node*, binding_slot*)
../../gcc/gcc/cp/module.cc:18773
0xa8988e name_lookup::search_namespace_only(tree_node*)
../../gcc/gcc/cp/name-lookup.c:928
0xa8aedb name_lookup::search_unqualified(tree_node*, cp_binding_level*)
../../gcc/gcc/cp/name-lookup.c:1158
0xa8dbe4 lookup_name_1
../../gcc/gcc/cp/name-lookup.c:7804
0xa8ddca lookup_name(tree_node*, LOOK_where, LOOK_want)
../../gcc/gcc/cp/name-lookup.c:7824
0xa9caa2 lookup_name(tree_node*, LOOK_want)
../../gcc/gcc/cp/name-lookup.h:401
0xa9caa2 cp_parser_lookup_name
../../gcc/gcc/cp/parser.c:29386
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug middle-end/90323] powerpc should convert equivalent sequences to vec_sel()

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

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

--- Comment #10 from Segher Boessenkool  ---
You cannot fix a simplify-rtx problem in much earlier passes!  It may be
useful of course (I have no idea, I don't know gimple well enough), but
it is no solution to the problem at all.  The xor/and/xor thing should be
simplified to something proper.

((A^B))^A = (A&~C)^(B) = (A&~C)|(B)

This should already be done by the expand pass.  At gimple level the logical
complement is counted as an operation, making the contorted xor/and/xor form
the best form to use, but in a system that considers more than just operation
counts (like in RTL) this is not the best form at all.  But, anyway, RTL
simplification should be able to do this.

Similar problems happen all over the place, fwiw -- see the various rl* tests
for rs6000, for example.

[Bug c++/97679] [10 Regression] [concepts] ICE with CTAD for a nested class template with constrained constructor

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

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

Patrick Palka  changed:

   What|Removed |Added

Summary|[10/11 Regression]  |[10 Regression] [concepts]
   |[concepts] ICE with CTAD|ICE with CTAD for a nested
   |for a nested class template |class template with
   |with constrained|constrained constructor
   |constructor |

--- Comment #4 from Patrick Palka  ---
Fixed for GCC 11 so far.

[Bug c++/99974] attributes not propagated across function redeclarations at local scope

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Related to PR 99843 where there is a friend function declaration instead of
just a local scope declaration of the function.
But I suspect they are all the same issue where the merging of the attributes
is lost.

[Bug c++/99981] New: Misleading "conflicting declaration" error message

[jmarshall at hey dot com via Gcc-bugs]

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

Bug ID: 99981
   Summary: Misleading "conflicting declaration" error message
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jmarshall at hey dot com
  Target Milestone: ---

For the following C++ snippet,

 forward.cpp
struct foo;

typedef struct {
int i;
} foo;



both GCC 10.2.0 and current trunk (according to godbolt.org) produce

forward.cpp:5:3: error: conflicting declaration 'typedef struct foo foo'
5 | } foo;
  |   ^~~
forward.cpp:1:8: note: previous declaration as 'struct foo'
1 | struct foo;
  |^~~

It is a relatively minor issue, but "typedef struct foo foo" in the first
diagnostic is misleading. I would have expected to see "typedef struct ... foo"
or similar.

(If the code had indeed been "typedef struct foo { /*...*/ } foo", there would
be no error.)

[Bug c++/99974] attributes not propagated across function redeclarations at local scope

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

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

--- Comment #2 from Martin Sebor  ---
Here's another test case that shows a similar inconsistency between a function
declaration at local scope and a subsequent one at file scope, as well as an
inconsistency between the C and C++ front ends.  G++ fails to diagnose the the
conflicting attribute on the redeclaration of f2 (the C front end does the
right thing).

$ (set -x && cat z.c && gcc -O2 -S -Wall -xc z.c && gcc -O2 -S -Wall -xc++ z.c)
+ cat z.c
__attribute__ ((alloc_size (1))) int*
f1 (int, int);
__attribute__ ((alloc_size (2))) int*
f1 (int, int); // -Wattributes (good)

void g (void)
{
  __attribute__ ((alloc_size (1))) int*
  f2 (int, int);
}

__attribute__ ((alloc_size (2)))
int* f2 (int, int);// C++ missing -Wattributes
+ gcc -O2 -S -Wall -xc z.c
z.c:4:1: warning: ignoring attribute ‘alloc_size (2)’ because it conflicts with
previous ‘alloc_size (1)’ [-Wattributes]
4 | f1 (int, int); // -Wattributes (good)
  | ^~
z.c:2:1: note: previous declaration here
2 | f1 (int, int);
  | ^~
z.c:13:1: warning: ignoring attribute ‘alloc_size (2)’ because it conflicts
with previous ‘alloc_size (1)’ [-Wattributes]
   13 | int* f2 (int, int);// C++ missing -Wattributes
  | ^~~
z.c:9:3: note: previous declaration here
9 |   f2 (int, int);
  |   ^~
+ gcc -O2 -S -Wall -xc++ z.c
z.c:4:13: warning: ignoring attribute ‘alloc_size (2)’ because it conflicts
with previous ‘alloc_size (1)’ [-Wattributes]
4 | f1 (int, int); // -Wattributes (good)
  | ^
z.c:2:1: note: previous declaration here
2 | f1 (int, int);
  | ^~

[Bug c++/99806] [10/11 Regression] ICE: in tsubst_copy, at cp/pt.c:17247

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

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

--- Comment #6 from Marek Polacek  ---
Since Comment 3 isn't a regression, I've opened bug 99980.

[Bug c++/99980] Delayed parsing of noexcept doesn't work in member function template

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

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

Marek Polacek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Keywords||rejects-valid
   Last reconfirmed||2021-04-08

--- Comment #1 from Marek Polacek  ---
Not a regression.  Mine for GCC 12.

[Bug c++/99980] New: Delayed parsing of noexcept doesn't work in member function template

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

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

Bug ID: 99980
   Summary: Delayed parsing of noexcept doesn't work in member
function template
   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: ---

We should accept this:

struct S {
  template
  void f(T) noexcept(B);
  static constexpr bool B = true;
};

but we don't; we need something like

--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -30526,7 +30526,8 @@ cp_parser_single_declaration (cp_parser* parser,
  || decl_specifiers.type != error_mark_node))
 {
   decl = cp_parser_init_declarator (parser,
-   CP_PARSER_FLAGS_TYPENAME_OPTIONAL,
+   CP_PARSER_FLAGS_TYPENAME_OPTIONAL
+   | CP_PARSER_FLAGS_DELAY_NOEXCEPT,
_specifiers,
checks,
/*function_definition_allowed_p=*/true,

(but not when friend_p).  Found while looking into
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99806#c3.

[Bug libstdc++/99433] [11 Regression] custom friend pipe-operator| conflicts with range adaptor?

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #4 from Patrick Palka  ---
Fixed for GCC 11 as part of a larger rewriting of the range adaptors, thanks
for the report.

[Bug c++/99874] [11 Regression] ICE Segmentation fault when declared variable template of template lambda

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #4 from Patrick Palka  ---
Fixed, thanks for the bug report.

[Bug libstdc++/99979] New: condition_variable_any has wrong behavior if Lock::lock() throws

[redbeard0531 at gmail dot com via Gcc-bugs]

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

Bug ID: 99979
   Summary: condition_variable_any has wrong behavior if
Lock::lock() throws
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redbeard0531 at gmail dot com
  Target Milestone: ---

https://eel.is/c++draft/thread.condvarany.wait says "Postconditions: lock is
locked by the calling thread. […] Remarks: If the function fails to meet the
postcondition, terminate() is invoked […] This can happen if the re-locking of
the mutex throws an exception." This wording was changed in C++14 for
https://cplusplus.github.io/LWG/issue2135, but given that it is borderline
impossible to use a condition_variable[_any] correctly if it doesn't guarantee
relocking, it seems best to do the same in C++11 mode as well.

Unfortunately, std::condition_variable_any::__Unlock::~__Unlock() either
ignores[1] or propagates any exception thrown by lock(), which means that the
postcondition of wait() may not be fulfilled. I think the correct behavior
would be to remove the noexcept(false), allowing the destructor's default
noexecpt to apply, and just unconditionally call _M_lock.lock() without any
try/catch.

[1] It ignores if std::uncaught_exception() returns true. I'm not 100% sure why
that dispatch is there. It seems like it may be trying to detect if
_M_cond.wait() threw, but a) that is noexcept and b) that doesn't work
correctly if some thread waits on a condvar inside a destructor that is
triggered during exception unwinding (this is why std::uncaught_exceptions()
was introduced).

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

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
ICEs already in r242085 (first revision I have around since cortex-m23 support
has been added).

[Bug c++/90451] [8/9/10/11 Regression] "static" function which added "deprecated" print deprecated warning >1 times (twice or even 3 times)

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug target/99900] feature request: 16-bit x86 C compiler / support compilation of (VirtualBox) BIOS

[u1049321969 at caramail dot com via Gcc-bugs]

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

--- Comment #7 from tk  ---
Hello Andrew,

Incidentally, the patches for binutils-ia16
(https://github.com/tkchia/binutils-ia16) to support IA-16 relocations
(https://github.com/tkchia/build-ia16/blob/master/elf16-writeup.md), could
perhaps also benefit from a rethink.

Thank you!

[Bug c++/99806] [10/11 Regression] ICE: in tsubst_copy, at cp/pt.c:17247

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

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

--- Comment #5 from Marek Polacek  ---
Another related test that we should probably accept:

// PR c++/99806

struct S {
  void f(auto, auto, int = 3);
};

void
g ()
{
  S s;
  s.f(1, 2);
}

[Bug libstdc++/96029] [8/9 Regression] Inconsistencies with associative/unordered containers

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

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

Jonathan Wakely  changed:

   What|Removed |Added

Summary|[8/9/10 Regression] |[8/9 Regression]
   |Inconsistencies with|Inconsistencies with
   |associative/unordered   |associative/unordered
   |containers  |containers

--- Comment #5 from Jonathan Wakely  ---
Fixed for 10.4 too.

[Bug c/99978] New: attribute section rejected on an extern declaration in local scope

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

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

Bug ID: 99978
   Summary: attribute section rejected on an extern declaration in
local scope
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC rejects a declaration of an extern variable with the section attribute in a
local scope.  The error it issues suggests it confuses the declaration with one
of a automatic variable.

Other Linux compilers (Clang and ICC) accept the code.

$ cat a.c && gcc -S -Wall a.c
extern __attribute__ ((section ("foo"))) int i_in_foo;

int f (void)
{
  extern __attribute__ ((section ("foo"))) int i_in_foo;
  return i_in_foo;
}
a.c: In function ‘f’:
a.c:5:48: error: section attribute cannot be specified for local variables
5 |   extern __attribute__ ((section ("foo"))) int i_in_foo;
  |^~~~

[Bug ada/98724] [11 Regression] gnat build failure on alpha-linux-gnu

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Priority|P3  |P4

[Bug c++/99874] [11 Regression] ICE Segmentation fault when declared variable template of template lambda

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

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

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

https://gcc.gnu.org/g:123b3e03c911a43054c1f88f5d3110e1d084dd4e

commit r11-8065-g123b3e03c911a43054c1f88f5d3110e1d084dd4e
Author: Patrick Palka 
Date:   Thu Apr 8 13:07:43 2021 -0400

c++: Don't substitute into constraints on lambdas [PR99874]

We currently substitute through a lambda's constraints whenever we
regenerate it via tsubst_lambda_expr.  This is the wrong approach
because it can lead to hard errors due to constraints being evaluated
out of order (as in the testcase concepts-lambda17.C below), and because
it doesn't mesh well with the recently added REQUIRES_EXPR_EXTRA_ARGS
mechanism for delaying substitution into requires-expressions, which is
the cause of this PR.

But in order to avoid substituting through a lambda's constraints during
regeneration, we need to be able to get at all in-scope template
parameters and corresponding template arguments during constraint
checking of a lambda's op().  And this information is not easily
available when we need it, it seems.

To that end, the approach that this patch takes is to add two new fields
to LAMBDA_EXPR (and remove one): LAMBDA_EXPR_REGENERATED_FROM
(replacing LAMBDA_EXPR_INSTANTIATED), and LAMBDA_EXPR_REGENERATING_TARGS.
The former allows us to obtain the complete set of template parameters
that are in-scope for a lambda's op(), and the latter gives us all outer
template arguments that were used to regenerate the lambda (analogous to
the TI_TEMPLATE and TI_ARGS of a TEMPLATE_INFO, respectively).

LAMBDA_EXPR_REGENERATING_TARGS is not strictly necessary -- in an
earlier prototype, I walked LAMBDA_EXPR_EXTRA_SCOPE to build up this set
of outer template arguments on demand, but it seems cleaner to do it this
way.  (We'd need to walk LAMBDA_EXPR_EXTRA_SCOPE and not DECL/TYPE_CONTEXT
because the latter skips over variable template scopes.)

This patch also renames the predicate instantiated_lambda_fn_p to
regenerated_lambda_fn_p, for sake of consistency with the rest of the
patch which uses "regenerated" instead of "instantiated".

gcc/cp/ChangeLog:

PR c++/99874
* constraint.cc (get_normalized_constraints_from_decl): Handle
regenerated lambdas.
(satisfy_declaration_constraints): Likewise.  Check for
dependent args later.
* cp-tree.h (LAMBDA_EXPR_INSTANTIATED): Replace with ...
(LAMBDA_EXPR_REGENERATED_FROM): ... this.
(LAMBDA_EXPR_REGENERATING_TARGS): New.
(tree_lambda_expr::regenerated_from): New data member.
(tree_lambda_expr::regenerating_targs): New data member.
(add_to_template_args): Declare.
(regenerated_lambda_fn_p): Likewise.
(most_general_lambda): Likewise.
* lambda.c (build_lambda_expr): Set LAMBDA_EXPR_REGENERATED_FROM
and LAMBDA_EXPR_REGENERATING_TARGS.
* pt.c (add_to_template_args): No longer static.
(tsubst_function_decl): Unconditionally propagate constraints on
the substituted function decl.
(instantiated_lambda_fn_p): Rename to ...
(regenerated_lambda_fn_p): ... this.  Check
LAMBDA_EXPR_REGENERATED_FROM instead of
LAMBDA_EXPR_INSTANTIATED.
(most_general_lambda): Define.
(enclosing_instantiation_of): Adjust after renaming
instantiated_lambda_fn_p.
(tsubst_lambda_expr): Don't set LAMBDA_EXPR_INSTANTIATED.  Set
LAMBDA_EXPR_REGENERATED_FROM and LAMBDA_EXPR_REGENERATING_TARGS.
Don't substitute or set constraints on the regenerated lambda.

gcc/testsuite/ChangeLog:

PR c++/99874
* g++.dg/cpp2a/concepts-lambda16.C: New test.
* g++.dg/cpp2a/concepts-lambda17.C: New test.

[Bug c++/97679] [10/11 Regression] [concepts] ICE with CTAD for a nested class template with constrained constructor

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

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

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

https://gcc.gnu.org/g:05708d6eef87a3dd0c68b1aed7f8d9c3824062b8

commit r11-8064-g05708d6eef87a3dd0c68b1aed7f8d9c3824062b8
Author: Patrick Palka 
Date:   Thu Apr 8 13:07:37 2021 -0400

c++: constrained CTAD for nested class template [PR97679]

In the testcase below, we're crashing during constraint checking of the
implicitly generated deduction guides for the nested class template A::B
because we never substitute the outer template arguments (for A) into
the constraint, neither ahead of time nor as part of satisfaction.

Ideally we'd like to avoid substituting into a constraint ahead of
time, but the "flattening" vector 'tsubst_args' is constructed under the
assumption that all outer template arguments are already substituted in,
and eliminating this assumption to yield a flattening vector that
includes outer (generic) template arguments suitable for substituting
into the constraint would be tricky and error-prone.  So this patch
takes the approximate approach of substituting the outer arguments into
the constraint ahead of time, so that the subsequent substitution of
'tsubst_args' is coherent and so later satisfaction just works.

gcc/cp/ChangeLog:

PR c++/97679
* pt.c (build_deduction_guide): Document OUTER_ARGS.  Substitute
them into the propagated constraints.

gcc/testsuite/ChangeLog:

PR c++/97679
* g++.dg/cpp2a/concepts-ctad3.C: New test.

[Bug testsuite/99605] [11 regression] new test case g++.dg/modules/builtin-3_a.C fails for 32 bits

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

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

--- Comment #3 from Nathan Sidwell  ---
I removed the scans, they're too brittle, didn't realize this report was a
thing

* 671f9f5c0f0 2021-04-06 | c++: Simplify va_arg test

[Bug c++/99805] [9 Regression] filesystem::path::parent_path got a wrong path

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

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||10.3.1, 11.0
Summary|[9/10 Regression]   |[9 Regression]
   |filesystem::path::parent_pa |filesystem::path::parent_pa
   |th got a wrong path |th got a wrong path

--- Comment #9 from Jonathan Wakely  ---
Fixed for 10.4 too.

[Bug libstdc++/96029] [8/9/10 Regression] Inconsistencies with associative/unordered containers

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

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:

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

commit r10-9673-g1c4e8a96cd695c03ff85299bf2392476feae99bb
Author: François Dumont 
Date:   Mon Jan 20 19:15:43 2020 +0100

libstdc++: Fix unordered containers move constructors noexcept
qualification

_Hashtable move constructor is wrongly qualified as noexcept(true)
regardless of
_Equal and _H1 copy constructor qualifications.
_Hashtable allocator-aware move constructor is missing its noexcept
qualification like the depending unordered containers ones.

This backport also includes the changes from r11-8062.

libstdc++-v3/ChangeLog:

PR libstdc++/96029
* include/bits/hashtable.h
(_Hashtable(_Hashtable&& __ht, __node_alloc_type&& __a,
true_type)):
Add noexcept qualification.
(_Hashtable(_Hashtable&&)): Fix noexcept qualification.
(_Hashtable(_Hashtable&&, const allocator_type&)): Add noexcept
qualification.
* include/bits/unordered_map.h
(unordered_map(unordered_map&&, const allocator_type&)): Add
noexcept
qualification.
(unordered_multimap(unordered_multimap&&, const allocator_type&)):
Likewise.
* include/bits/unordered_set.h
(unordered_set(unordered_set&&, const allocator_type&)): Likewise.
(unordered_multiset(unordered_multiset&&, const allocator_type&)):
Likewise.
* include/debug/unordered_map
(unordered_map(unordered_map&&, const allocator_type&)): Likewise.
(unordered_multimap(unordered_multimap&&, const allocator_type&)):
Likewise.
* include/debug/unordered_set
(unordered_set(unordered_set&&, const allocator_type&)): Likewise.
(unordered_multiset(unordered_multiset&&, const allocator_type&)):
Likewise.
* testsuite/23_containers/unordered_map/allocator/default_init.cc:
New test.
*
testsuite/23_containers/unordered_map/cons/noexcept_default_construct.cc:
New test.
*
testsuite/23_containers/unordered_map/cons/noexcept_move_construct.cc:
New test.
* testsuite/23_containers/unordered_map/modifiers/move_assign.cc:
New test.
*
testsuite/23_containers/unordered_multimap/cons/noexcept_default_construct.cc:
New test.
*
testsuite/23_containers/unordered_multimap/cons/noexcept_move_construct.cc:
New test.
*
testsuite/23_containers/unordered_multiset/cons/noexcept_default_construct.cc:
New test.
*
testsuite/23_containers/unordered_multiset/cons/noexcept_move_construct.cc:
New test.
* testsuite/23_containers/unordered_set/allocator/default_init.cc:
New test.
*
testsuite/23_containers/unordered_set/cons/noexcept_default_construct.cc:
New test.
*
testsuite/23_containers/unordered_set/cons/noexcept_move_construct.cc:
New test.

(cherry picked from commit 12324b9a934654a5c3bf4a614853ded2e0a958af)

[Bug libstdc++/96029] [8/9/10 Regression] Inconsistencies with associative/unordered containers

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

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:

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

commit r10-9672-g2feec6285c304d33c72e42e022d9e42d561a7607
Author: François Dumont 
Date:   Fri Jul 3 08:13:19 2020 +0200

libstdc++: Fix [multi]map/[multi]set move constructors noexcept
qualification

Container move constructors shall not consider their allocator move
constructor qualification.

libstdc++-v3/ChangeLog:

PR libstdc++/96029
* include/bits/stl_tree.h (_Rb_tree_impl(_Rb_tree_impl&&)): Add
noexcept
qualification based only on _Compare one.
* testsuite/23_containers/map/cons/noexcept_move_construct.cc: Add
static asserts.
* testsuite/23_containers/multimap/cons/noexcept_move_construct.cc:
Likewise.
* testsuite/23_containers/multiset/cons/noexcept_move_construct.cc:
Likewise.
* testsuite/23_containers/set/cons/noexcept_move_construct.cc:
Likewise.

(cherry picked from commit c832cf1c1d114aed70c2f84566cf4d63de0a56d0)

[Bug c++/99805] [9/10 Regression] filesystem::path::parent_path got a wrong path

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:

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

commit r10-9671-gbeb485ddeb066d03b2568bb1bebaa2902b4dbf97
Author: Jonathan Wakely 
Date:   Wed Apr 7 16:05:42 2021 +0100

libstdc++: Fix filesystem::path construction from COW string [PR 99805]

Calling the non-const data() member on a COW string makes it "leaked",
possibly resulting in reallocating the string to ensure a unique owner.

The path::_M_split_cmpts() member parses its _M_pathname string using
string_view objects and then calls _M_pathname.data() to find the offset
of each string_view from the start of the string. However because
_M_pathname is non-const that will cause a COW string to reallocate if
it happens to be shared with another string object. This results in the
offsets calculated for each component being wrong (i.e. undefined)
because the string views no longer refer to substrings of the
_M_pathname member. The fix is to use the parse.offset(c) member which
gets the offset safely.

The bug only happens for the path(string_type&&) constructor and only
for COW strings. When constructed from an lvalue string the string's
contents are copied rather than just incrementing the refcount, so
there's no reallocation when calling the non-const data() member. The
testsuite changes check the lvalue case anyway, because we should
probably change the deep copying to just be a refcount increment (by
adding a path(const string_type&) constructor or an overload for
__effective_range(const string_type&), for COW strings only).

libstdc++-v3/ChangeLog:

PR libstdc++/99805
* src/c++17/fs_path.cc (path::_M_split_cmpts): Do not call
non-const member on _M_pathname, to avoid copy-on-write.
* testsuite/27_io/filesystem/path/decompose/parent_path.cc:
Check construction from strings that might be shared.

(cherry picked from commit e06d3f5dd7d0c6b4a20fe813e6ee5addd097f560)

[Bug tree-optimization/97009] [9 Regression] Inlining with non-standard selected_int_kind leads to errors

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

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #13 from Martin Jambor  ---
Fixed.

[Bug tree-optimization/97009] [9 Regression] Inlining with non-standard selected_int_kind leads to errors

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

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Martin Jambor
:

https://gcc.gnu.org/g:3181f66afc7926950115d9802de1516fba3822a2

commit r9-9326-g3181f66afc7926950115d9802de1516fba3822a2
Author: Martin Jambor 
Date:   Thu Apr 8 18:57:48 2021 +0200

sra: Fix bug in grp_write propagation (PR 97009)

SRA represents parts of aggregates which are arrays accessed with
unknown index as "unscalarizable regions."  When there are two such
regions one within another and the outer is only read whereas the
inner is written to, SRA fails to propagate that write information
across assignments.  This means that a second aggregate can contain
data while SRA thinks it does not and the pass can wrongly eliminate
big chunks of assignment from that second aggregate into a third
aggregate, which is what happens in PR 97009.

Fixed by checking all children of unscalariable accesses for the
grp_write flag.

gcc/ChangeLog:

2021-03-31  Martin Jambor  

PR tree-optimization/97009
* tree-sra.c (access_or_its_child_written): New function.
(propagate_subaccesses_from_rhs): Use it instead of a simple
grp_write
test.

gcc/testsuite/ChangeLog:

2021-03-31  Martin Jambor  

PR tree-optimization/97009
* gcc.dg/tree-ssa/pr97009.c: New test.

(cherry picked from commit 19d71674616e6494a60432a2a28adcd762a6c877)

[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 #1 from Alex Coplan  ---
I should have mentioned the testcase was reduced from gcc.dg/ia64-sync-3.c.

[Bug c/99972] missing -Wunused-result on a call to a locally redeclared warn_unused_result function

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

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

--- Comment #2 from Martin Sebor  ---
The code (obviously) needs to be compiled as C to show the C bug (the C++ front
end is also buggy but differently; pr99974 tracks that):

$ gcc -S -Wall pr99972.c
pr99972.c: In function ‘gwur’:
pr99972.c:20:3: warning: ignoring return value of ‘fwur’ declared with
attribute ‘warn_unused_result’ [-Wunused-result]
   20 |   fwur ();   // -Wunused-result (good)
  |   ^~~

[Bug target/99977] New: 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

Bug ID: 99977
   Summary: arm: ICE with __sync_bool_compare_and_swap and
-mcpu=cortex-m23
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acoplan at gcc dot gnu.org
  Target Milestone: ---

The following fails:

$ cat t1.c
int a[1];
void f() { __sync_bool_compare_and_swap(a, -1, 0); }
$ arm-eabi-gcc -c t1.c -mcpu=cortex-m23
t1.c: In function 'f':
t1.c:2:52: error: insn does not satisfy its constraints:
2 | void f() { __sync_bool_compare_and_swap(a, -1, 0); }
  |^
(jump_insn 29 28 30 (parallel [
(set (pc)
(if_then_else (ne (reg:SI 0 r0 [115])
(const_int -1 [0x]))
(label_ref 32)
(pc)))
(clobber (scratch:SI))
]) "t1.c":2:12 950 {cbranchsi4_scratch}
 (int_list:REG_BR_PROB 536868 (nil))
 -> 32)
during RTL pass: mach
t1.c:2:52: internal compiler error: in extract_constrain_insn, at recog.c:2671
0xcc1fd5 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/alecop01/toolchain/src/gcc/gcc/rtl-error.c:108
0xcc2006 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/alecop01/toolchain/src/gcc/gcc/rtl-error.c:118
0xc91f2f extract_constrain_insn(rtx_insn*)
/home/alecop01/toolchain/src/gcc/gcc/recog.c:2671
0x1194ac1 note_invalid_constants
/home/alecop01/toolchain/src/gcc/gcc/config/arm/arm.c:18053
0x1194ac1 arm_reorg
/home/alecop01/toolchain/src/gcc/gcc/config/arm/arm.c:19195
0xcc1c9f execute
/home/alecop01/toolchain/src/gcc/gcc/reorg.c:4045
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

If we change the second argument to -8, we ICE in LRA instead:

$ cat t2.c
int a[1];
void f() { __sync_bool_compare_and_swap(a, -8, 0); }
$ arm-eabi-gcc -c t2.c -mcpu=cortex-m23
during RTL pass: reload
t2.c: In function 'f':
t2.c:2:52: internal compiler error: in curr_insn_transform, at
lra-constraints.c:4638
2 | void f() { __sync_bool_compare_and_swap(a, -8, 0); }
  |^
0xb7d9b4 curr_insn_transform
/home/alecop01/toolchain/src/gcc/gcc/lra-constraints.c:4638
0xb7ea1b lra_constraints(bool)
/home/alecop01/toolchain/src/gcc/gcc/lra-constraints.c:5169
0xb65c5c lra(_IO_FILE*)
/home/alecop01/toolchain/src/gcc/gcc/lra.c:2336
0xb1781c do_reload
/home/alecop01/toolchain/src/gcc/gcc/ira.c:5835
0xb1781c execute
/home/alecop01/toolchain/src/gcc/gcc/ira.c:6021
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c/99420] [11 Regression] bogus -Warray-parameter on a function redeclaration in function scope

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

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Sebor  ---
The attributes need to be copied/merged across redeclarations of the same
symbol regardless of the scope.  See pr99972 for another example where failing
to do it causes a false positive.

[Bug c++/99976] New: gcc accepts requires-clause contains unexpanded parameter pack

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 99976
   Summary: gcc accepts requires-clause contains unexpanded
parameter pack
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

https://godbolt.org/z/ax7MKM483

template  concept C = requires (Ts) { true; };
static_assert(C);

gcc accepts it.

[Bug tree-optimization/94905] [10/11 Regression] Bogus warning -Werror=maybe-uninitialized

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

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org
  Component|c++ |tree-optimization

--- Comment #11 from Jason Merrill  ---
Changing component.

[Bug c++/83503] [8 Regression] bogus -Wattributes for const and pure on function template specialization

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

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

--- Comment #24 from Jason Merrill  ---
*** Bug 83502 has been marked as a duplicate of this bug. ***

[Bug c++/83502] [8/9/10/11 Regression] bogus -Wattributes for always_inline and noinline on function template specialization

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

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE
   Target Milestone|8.5 |8.0
 CC||jason at gcc dot gnu.org

--- Comment #7 from Jason Merrill  ---
This seems to have been fixed by the patch for PR83503.

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

[Bug c/99420] [11 Regression] bogus -Warray-parameter on a function redeclaration in function scope

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
If not copying over the attribute is intentional when it isn't builtin, we
could still copy over just the single attribute, like:
--- gcc/c/c-decl.c.jj   2021-03-16 00:21:29.464233163 +0100
+++ gcc/c/c-decl.c  2021-04-08 18:19:24.762093841 +0200
@@ -3268,6 +3268,17 @@ pushdecl (tree x)
thistype
  = build_type_attribute_variant (thistype,
  TYPE_ATTRIBUTES (b->u.type));
+ else if (!lookup_attribute ("access", TYPE_ATTRIBUTES (thistype)))
+   if (tree access = lookup_attribute ("access",
+   TYPE_ATTRIBUTES (b->u.type)))
+ {
+   /* Otherwise, copy over the access attribute.  */
+   tree attr = tree_cons (TREE_PURPOSE (access),
+  TREE_VALUE (access),
+  TYPE_ATTRIBUTES (thistype));
+   thistype
+ = build_type_attribute_variant (thistype, attr);
+ }
  TREE_TYPE (b->decl) = thistype;
  bind (name, b->decl, scope, /*invisible=*/false, /*nested=*/true,
locus);
Except that the access attribute unfortunately seems to mean a lot of different
things, it is a user attribute with some arguments that is later rewritten into
a different form and that other form is reused also for the array parameters
and the -Warray-parameter stuff using that.
So, if both decls of f1 should have different attributes, then doing the above
is undesirable because it would also result in user's access attributes being
copied over, or that for user access attribute on the second declaration would
result in it not being copied.
Perhaps we can copy the attribute under a different attribute name (something
with space in it so that it isn't user accessible) and use that for
-Warray-parameter purposes in preference over "access"?
Also, I'd argue that the rewritten "access" attribute shouldn't be called
"access" but with some internal name.

[Bug c++/99975] wrong variable alignment on a locally redeclared overaligned extern variable

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

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

--- Comment #1 from Martin Sebor  ---
Surprisingly, other variable attributes such as deprecated and alloc_size (the
latter applied to a pointer to a function) do work as expected:

$ cat z.C && gcc -S -Wall z.C
int f ()
{
  extern __attribute__ ((deprecated ("I was deprecated in f()"))) int i;

  return i;
}

int gv()
{
  extern int i;

  return i;
}
z.C: In function ‘int f()’:
z.C:5:10: warning: ‘i’ is deprecated: I was deprecated in f()
[-Wdeprecated-declarations]
5 |   return i;
  |  ^
z.C:3:71: note: declared here
3 |  extern __attribute__ ((deprecated ("I was deprecated in f()"))) int i;
  |  ^

z.C: In function ‘int gv()’:
z.C:12:10: warning: ‘i’ is deprecated: I was deprecated in f()
[-Wdeprecated-declarations]
   12 |   return i;
  |  ^
z.C:3:71: note: declared here
3 |  extern __attribute__ ((deprecated ("I was deprecated in f()"))) int i;
  |  ^

[Bug libstdc++/98384] new test case 20_util/to_chars/long_double.cc in r11-6249 fails

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Priority|P1  |P3

[Bug c++/86960] [8/9/10/11 Regression] ICE on specialization of member template with fixed parameter pack

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

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

--- Comment #9 from Jason Merrill  ---
Created attachment 50531
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50531=edit
WIP patches

Here's that 2019 work in progress, relative to r267647.

[Bug c++/99975] New: wrong variable alignment on a locally redeclared overaligned extern variable

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

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

Bug ID: 99975
   Summary: wrong variable alignment on a locally redeclared
overaligned extern variable
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Perhaps due to the same underlying bug as pr99974, the C++ front end determines
the wrong alignment from an overaligned extern variable redeclared locally
without the alignment attribute.

Both the C front end as well as other compilers (Clang and ICC) behave
correctly and determine the same alignment in both functions.

$ cat z.C && /build/gcc-master/gcc/xgcc -B /build/gcc-master/gcc -O -S -Wall
-fdump-tree-optimized=/dev/stdout z.C
extern __attribute__ ((aligned (32))) int i;

int fa32 ()
{
  return __alignof__ (i);   // folded to 32 (good)
}

int ga32 ()
{
  extern int i;
  return __alignof__ (i);   // folded to 4 (bug)
}

;; Function fa32 (_Z4fa32v, funcdef_no=0, decl_uid=2347, cgraph_uid=1,
symbol_order=0)

int fa32 ()
{
   [local count: 1073741824]:
  return 32;

}



;; Function ga32 (_Z4ga32v, funcdef_no=1, decl_uid=2349, cgraph_uid=2,
symbol_order=1)

int ga32 ()
{
   [local count: 1073741824]:
  return 4;

}

[Bug tree-optimization/86465] [8/9/10/11 Regression] C++17 triggers: ‘’ may be used uninitialized in this function

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

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org
  Component|c++ |tree-optimization

--- Comment #12 from Jason Merrill  ---
Changing component.

[Bug c++/91849] [8/9/10 Regression] Misleading diagnostic message when binding reference to unrelated type

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

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

Jason Merrill  changed:

   What|Removed |Added

Summary|[8/9/10/11 Regression]  |[8/9/10 Regression]
   |Misleading diagnostic   |Misleading diagnostic
   |message when binding|message when binding
   |reference to unrelated type |reference to unrelated type
  Known to work||11.0

--- Comment #7 from Jason Merrill  ---
Fixed for 11 so far.

[Bug c++/91849] [8/9/10/11 Regression] Misleading diagnostic message when binding reference to unrelated type

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

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

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

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

commit r11-8058-g9f74f9cf47ed9d65e65a06378041e9dd5698e49d
Author: Jason Merrill 
Date:   Thu Apr 8 08:23:17 2021 -0400

c++: improve reference binding diagnostic [PR91849]

Here we were complaining about binding the lvalue reference to the rvalue
result of converting from float to int, but didn't mention that conversion.
Talk about the type of the initializer instead.

gcc/cp/ChangeLog:

PR c++/91849
* call.c (convert_like_internal): Improve reference diagnostic.

gcc/testsuite/ChangeLog:

PR c++/91849
* g++.dg/conversion/pr66211.C: Adjust diagnostic.
* g++.dg/conversion/ref7.C: New test.

[Bug c++/99974] attributes not propagated across function redeclarations at local scope

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

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
This never worked correctly so it's not a regression.

Clang behaves as expected in both C and C++ modes and issues the following
warnings:

z.C:18:3: warning: ignoring return value of function declared with
  'warn_unused_result' attribute [-Wunused-result]
  fwur ();   // -Wunused-result (good)
  ^~~~
z.C:25:3: warning: ignoring return value of function declared with
  'warn_unused_result' attribute [-Wunused-result]
  fwur ();   // missing -Wunused-result (bug)
  ^~~~
2 warnings generated.

[Bug c++/99974] New: attributes not propagated across function redeclarations at local scope

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

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

Bug ID: 99974
   Summary: attributes not propagated across function
redeclarations at local scope
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The C++ front end fails to merge the noreturn and warn_unused_result function
attributes from one declaration at function scope to another.  This is unlike
the C front end which merges some but not others (see pr99972).

$ cat z.C && gcc -S -Wall z.C
int gnr ()
{ 
  extern __attribute__ ((noreturn)) int fnr ();
  fnr ();
}  // no return, no warning (good)

int hnr ()
{
  extern int fnr ();

  fnr ();
}  // bogus -Wreturn-type (bug)


void gwur ()
{
  extern __attribute__ ((warn_unused_result)) int fwur ();
  fwur ();   // -Wunused-result (good)
}

void hwur ()
{
  extern int fwur (); 

  fwur ();   // missing -Wunused-result (bug)
}
z.C: In function ‘int hnr()’:
z.C:12:1: warning: no return statement in function returning non-void
[-Wreturn-type]
   12 | }  // bogus -Wreturn-type (bug)
  | ^
z.C: In function ‘void gwur()’:
z.C:18:8: warning: ignoring return value of ‘int fwur()’ declared with
attribute ‘warn_unused_result’ [-Wunused-result]
   18 |   fwur ();   // -Wunused-result (good)
  |   ~^~

[Bug c++/91849] [8/9/10/11 Regression] Misleading diagnostic message when binding reference to unrelated type

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c/99972] missing -Wunused-result on a call to a locally redeclared warn_unused_result function

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

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

Martin Sebor  changed:

   What|Removed |Added

  Known to fail||10.2.0, 11.0, 4.7.0, 4.8.4,
   ||4.9.4, 5.5.0, 6.4.0, 7.2.0,
   ||8.3.0, 9.1.0
   Keywords||diagnostic

--- Comment #1 from Martin Sebor  ---
This never worked correctly so it's not a regression.

Clang does the right thing and warns where expected:

z.c:20:3: warning: ignoring return value of function declared with
  'warn_unused_result' attribute [-Wunused-result]
  fwur ();   // -Wunused-result (good)
  ^~~~
z.c:27:3: warning: ignoring return value of function declared with
  'warn_unused_result' attribute [-Wunused-result]
  fwur ();   // missing -Wunused-result (bug)
  ^~~~
2 warnings generated.

[Bug debug/99973] New: -gsplit-dwarf uses host objcopy for cross compilers

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

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

Bug ID: 99973
   Summary: -gsplit-dwarf uses host objcopy for cross compilers
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rsandifo at gcc dot gnu.org
  Target Milestone: ---

ASM_FINAL_SPEC has:

  "%{gsplit-dwarf: \n\
   objcopy --extract-dwo \
 %{c:%{o*:%*}%{!o*:%w%b%O}}%{!c:%U%O} \
 %b.dwo \n\
   objcopy --strip-dwo \
 %{c:%{o*:%*}%{!o*:%w%b%O}}%{!c:%U%O} \
}"

which hard-codes the assumption that a command called “objcopy”
will work for the target.  This is true for native compilers but
isn't usually true for cross compilers.

This is causing:

FAIL: gcc.dg/lto/pr83719 c_lto_pr83719_0.o assemble,  -flto -g -gsplit-dwarf

[Bug c/99972] New: missing -Wunused-result on a call to a locally redeclared warn_unused_result function

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

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

Bug ID: 99972
   Summary: missing -Wunused-result on a call to a locally
redeclared warn_unused_result function
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The test case below (related to pr99420) shows that GCC doesn't consistently
propagate function attributes across redeclarations of extern functions at
function scope.

The noreturn attribute on fnr() is copied from the declaration in gnr() to the
one in hnr() and successfully suppresses -Wreturn-type in both callers.  That's
how it's supposed to work.

But the warn_unused_result on fwur() is clearly not copied from the declaration
inb gwur() to the one in hwur() because only the call to the function in gwur()
triggers -Wunused-result but the call in hwur() doesn't.  That's a bug with the
same root cause as pr99420.

$ cat z.c && gcc -S -Wall -xc++ z.c
int gnr (void)
{ 
  __attribute__ ((noreturn)) int fnr (void);
  fnr ();
  // no return, no warning (good)
}

int hnr (void)
{
  int fnr (void);

  fnr ();
  // no return, no warning (good)
}


void gwur (void)
{
  __attribute__ ((warn_unused_result)) int fwur (void);
  fwur ();   // -Wunused-result (good)
}

void hwur (void)
{
  int fwur (void); 

  fwur ();   // missing -Wunused-result (bug)
}
z.c: In function ‘int hnr()’:
z.c:14:1: warning: no return statement in function returning non-void
[-Wreturn-type]
   14 | }
  | ^
z.c: In function ‘void gwur()’:
z.c:20:8: warning: ignoring return value of ‘int fwur()’ declared with
attribute ‘warn_unused_result’ [-Wunused-result]
   20 |   fwur ();   // -Wunused-result (good)
  |   ~^~

[Bug c++/99859] constexpr evaluation with member function is incorrect

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||vittorio.romeo at outlook dot 
com

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

[Bug c++/80039] `constexpr` member function calls in a `constexpr` constructor are ignored if the object is defined locally

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Handled in PR99859.

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

[Bug libstdc++/98384] new test case 20_util/to_chars/long_double.cc in r11-6249 fails

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

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

Patrick Palka  changed:

   What|Removed |Added

Summary|[11 Regression] new test|new test case
   |case|20_util/to_chars/long_doubl
   |20_util/to_chars/long_doubl |e.cc in r11-6249 fails
   |e.cc in r11-6249 fails on   |
   |powerpc64 BE|

--- Comment #33 from Patrick Palka  ---
After the above commit, all reported FAILs should now be addressed one way or
another so I'm removing the [11 Regression] marker.

I suppose we should keep the bug open as a reminder that the test is fragile
and could use rewriting.

[Bug c++/99859] constexpr evaluation with member function is incorrect

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

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

--- Comment #17 from Jakub Jelinek  ---
Fixed on the trunk, I think we want to backport this though eventually.

[Bug c++/99859] constexpr evaluation with member function is incorrect

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

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

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

https://gcc.gnu.org/g:559d2f1e0eafd96c19dc5324db1a466286c0e7fc

commit r11-8056-g559d2f1e0eafd96c19dc5324db1a466286c0e7fc
Author: Jakub Jelinek 
Date:   Thu Apr 8 17:15:39 2021 +0200

c++: Don't cache constexpr functions which are passed pointers to heap or
static vars being constructed [PR99859]

When cxx_bind_parameters_in_call is called e.g. on a method on an automatic
variable, we evaluate the argument and because ADDR_EXPR of an automatic
decl is not TREE_CONSTANT, we set *non_constant_args and don't cache it.
But when it is called on an object located on the heap (allocated using
C++20 constexpr new) where we represent it as TREE_STATIC artificial
var, or when it is called on a static var that is currently being
constructed, such ADDR_EXPRs are TREE_CONSTANT and we happily cache
such calls, but they can in those cases have side-effects in the heap
or static var objects and so caching them means such side-effects will
happen only once and not as many times as that method or function is
called.
Furthermore, as Patrick mentioned in the PR, the argument doesn't need to
be
just ADDR_EXPR of the heap or static var or its components, but it could be
a CONSTRUCTOR that has the ADDR_EXPR embedded anywhere.
And the incorrectly cached function doesn't need to modify the pointed vars
or their components, but some caller could be changing them in between the
call that was cached and the call that used the cached result.

The following patch fixes it by setting *non_constant_args also when
the argument contains somewhere such an ADDR_EXPR, either of a heap
artificial var or component thereof, or of a static var currently being
constructed (where for that it uses the same check as
cxx_eval_store_expression, ctx->global->values.get (...); addresses of
other static variables would be rejected by cxx_eval_store_expression
and therefore it is ok to cache such calls).

2021-04-08  Jakub Jelinek  

PR c++/99859
* constexpr.c (addr_of_non_const_var): New function.
(cxx_bind_parameters_in_call): Set *non_constant_args to true
even if cp_walk_tree on arg with addr_of_non_const_var callback
returns true.

* g++.dg/cpp1y/constexpr-99859-1.C: New test.
* g++.dg/cpp1y/constexpr-99859-2.C: New test.
* g++.dg/cpp2a/constexpr-new18.C: New test.
* g++.dg/cpp2a/constexpr-new19.C: New test.

[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE

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

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

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

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

commit r11-8055-gca4641a3b536c9301a6dcb6cb2e26bd4717b47d9
Author: Patrick Palka 
Date:   Thu Apr 8 11:10:58 2021 -0400

libstdc++: Address remaining to_chars/long_double.cc FAILs [PR98384]

This works around the remaining reported execution FAILs of this test on
AIX, Solaris and Darwin.  Eventually we should rewrite this test to be
less fragile, but there's not enough time to do that for GCC 11.

libstdc++-v3/ChangeLog:

PR libstdc++/98384
* testsuite/20_util/to_chars/long_double.cc: Don't run the test
on targets without a large long double.  XFAIL the execution on
targets with a non-conforming printf.

[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes

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

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

Bug 99883 Summary: A couple of minor misspellings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99883

   What|Removed |Added

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

[Bug middle-end/99883] A couple of minor misspellings

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

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

Martin Sebor  changed:

   What|Removed |Added

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

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

[Bug middle-end/99883] A couple of minor misspellings

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

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

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

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

commit r11-8054-gd6cc745cb87aa62f9e17699aedf5aa2d9831fbd8
Author: Martin Sebor 
Date:   Thu Apr 8 09:08:39 2021 -0600

PR middle-end/99883 - A couple of minor misspellings

gcc/c-family/ChangeLog:

PR middle-end/99883
* c.opt (Wmismatched-new-delete): Correct spelling.

gcc/lto/ChangeLog:

PR middle-end/99883
* lto-lang.c (lto_post_options): Correct spelling.

[Bug c++/99970] gcc accepts invalid comparison between pointer and integer in template function

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||accepts-invalid
   Last reconfirmed||2021-04-08
 Ever confirmed|0   |1

[Bug c++/99879] [modules] ICE in open

[alexander.lelyakin at googlemail dot com via Gcc-bugs]

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

--- Comment #1 from Alexander Lelyakin  ---
There is a shorter sequence:

/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header memory
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header cstdio
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header span
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header shared_mutex
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header cstdint
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header clocale
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header bitset
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header semaphore
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header exception
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header numbers
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header charconv
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header locale
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header string
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header ranges
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header cstring
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header regex

In module imported at /usr/local/include/c++/11.0.1/regex:53:
/usr/local/include/c++/11.0.1/cstring: note: unable to represent further
imported source locations
/usr/local/include/c++/11.0.1/regex:53: internal compiler error: in open, at
cp/module.cc:13628
   53 | #include 
  | 
0x6df11d loc_spans::open(unsigned int)
../../gcc/gcc/cp/module.cc:13628
0xa62db5 preprocess_module(module_state*, unsigned int, bool, bool, bool,
cpp_reader*)
../../gcc/gcc/cp/module.cc:19432
0xa2ccef module_token_filter::resume(int, int, tree_node*, unsigned int)
../../gcc/gcc/cp/lex.c:520
0xa2ccef module_token_lang(int, int, tree_node*, unsigned int, unsigned long)
../../gcc/gcc/cp/lex.c:557
0xae0d53 cp_lexer_new_main
../../gcc/gcc/cp/parser.c:660
0xae0d53 c_parse_file()
../../gcc/gcc/cp/parser.c:45264
0xc05d0d c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1218
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.

g++ (GCC) 11.0.1 20210408 (experimental)
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug debug/99830] [11 Regression] ICE: in lra_eliminate_regs_1, at lra-eliminations.c:659 with -O2 -fno-expensive-optimizations -fno-split-wide-types -g

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 50530
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50530=edit
gcc11-pr99830.patch

Untested fix.

[Bug tree-optimization/99971] GCC generates partially vectorized and scalar code at once

[andysem at mail dot ru via Gcc-bugs]

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

--- Comment #1 from andysem at mail dot ru ---
For reference, an ideal version of this code should look something like this:

test(A&, A const&, A const&):
movdqu  (%rsi), %xmm0
movdqu  (%rdi), %xmm1
movdqu  (%rdx), %xmm2
paddd   %xmm1, %xmm0
psubd   %xmm2, %xmm0
movups  %xmm0, (%rdi)
ret

[Bug target/99900] feature request: 16-bit x86 C compiler / support compilation of (VirtualBox) BIOS

[u1049321969 at caramail dot com via Gcc-bugs]

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

--- Comment #6 from tk  ---
Hello Andrew,

> A bug bounty might be useful here since I highly doubt this will be done 
> otherwise.

The gcc-ia16 port is working, but internals-wise, some parts of the IA-16
patches are still rather hacky --- some of the changes affect the
machine-independent middle-end in not-so-elegant ways, or depend on
undocumented (and unreliable) properties in the middle-end.

So I guess it might still be useful to have some sort of bounty(s), if this
means someone could help rethink the changes and reduce technical debt.

Thank you!

[Bug c++/99970] gcc accepts invalid comparison between pointer and integer in requires-clause

[hewillk at gmail dot com via Gcc-bugs]

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

--- Comment #1 from 康桓瑋  ---
The requires-expression is a red herring, so it can be simplified to:

template 
void f() { x == nullptr; };

int main() { 
  f(); 
}

Is this ill-formed?

[Bug tree-optimization/99971] New: GCC generates partially vectorized and scalar code at once

[andysem at mail dot ru via Gcc-bugs]

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

Bug ID: 99971
   Summary: GCC generates partially vectorized and scalar code at
once
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andysem at mail dot ru
  Target Milestone: ---

Consider the following code sample:

struct A
{
unsigned int a, b, c, d;

A& operator+= (A const& that)
{
a += that.a;
b += that.b;
c += that.c;
d += that.d;
return *this;
}

A& operator-= (A const& that)
{
a -= that.a;
b -= that.b;
c -= that.c;
d -= that.d;
return *this;
}
};

void test(A& x, A const& y1, A const& y2)
{
x += y1;
x -= y2;
}

The code, when compiled with options "-O3 -march=nehalem", generates:

test(A&, A const&, A const&):
pushq   %rbp
movdqu  (%rdi), %xmm1
pushq   %rbx
movl4(%rsi), %r8d
movdqu  (%rsi), %xmm0
movl(%rsi), %r9d
paddd   %xmm1, %xmm0
movl8(%rsi), %ecx
movl12(%rsi), %eax
movl%r8d, %esi
movl(%rdi), %ebp
movl4(%rdi), %ebx
movl8(%rdi), %r11d
movl12(%rdi), %r10d
movups  %xmm0, (%rdi)
subl(%rdx), %r9d
subl4(%rdx), %esi
subl8(%rdx), %ecx
subl12(%rdx), %eax
addl%ebp, %r9d
addl%ebx, %esi
movl%r9d, (%rdi)
popq%rbx
addl%r11d, %ecx
popq%rbp
movl%esi, 4(%rdi)
addl%r10d, %eax
movl%ecx, 8(%rdi)
movl%eax, 12(%rdi)
ret

https://gcc.godbolt.org/z/Mzchj8bxG

Here you can see that the compiler has partially vectorized the test function -
it converted "x += y1" to paddd, as expected, but failed to vectorize "x -=
y2". But at the same time the compiler also generated scalar code, including
for the already vectorized "x += y1" line, basically duplicating it.

Note that when either "x += y1" or "x -= y2" is commented, the compiler is able
to vectorize the line that is left. It is also able to vectorize both lines
when the += and -= operators are applied to different objects instead of x.

This is reproducible since gcc 8 up to and including 10.2. gcc 7 doesn't
vectorize this code. With the current trunk on godbolt the generated code is
different:

test(A&, A const&, A const&):
movdqu  (%rsi), %xmm0
movdqu  (%rdi), %xmm1
paddd   %xmm1, %xmm0
movups  %xmm0, (%rdi)
movd%xmm0, %eax
subl(%rdx), %eax
movl%eax, (%rdi)
pextrd  $1, %xmm0, %eax
subl4(%rdx), %eax
movl%eax, 4(%rdi)
pextrd  $2, %xmm0, %eax
subl8(%rdx), %eax
movl%eax, 8(%rdi)
pextrd  $3, %xmm0, %eax
subl12(%rdx), %eax
movl%eax, 12(%rdi)
ret

Here the compiler is able to vectorize "x += y1" but not "x -= y2". At least,
it removed the duplicate scalar version of "x += y1".

Given that the compiler is able to vectorize each line in isolation, I would
expect it to be able to vectorize them combined. Generating duplicate versions
of code is certainly not expected.

[Bug libstdc++/99433] [11 Regression] custom friend pipe-operator| conflicts with range adaptor?

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

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

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

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

commit r11-8053-ga25321ca06f61e5aeadc00923249f83af72059c5
Author: Patrick Palka 
Date:   Thu Apr 8 10:40:19 2021 -0400

libstdc++: Reimplement range adaptors [PR99433]

This rewrites our range adaptor implementation for more comprehensible
error messages, improved SFINAE behavior and conformance to P2281.

The diagnostic improvements mostly come from using appropriately named
functors instead of lambdas in the generic implementation of partial
application and composition of range adaptors, and in the definition of
each of the standard range adaptors.  This makes their pretty printed
types much shorter and more self-descriptive.

The improved SFINAE behavior comes from constraining the range adaptors'
member functions appropriately.  This improvement fixes PR99433, and is
also necessary in order to implement the wording changes of P2281.

Finally, P2281 clarified that partial application and composition of
range adaptors behaves like a perfect forwarding call wrapper.  This
patch implements this, except that we don't bother adding overloads for
forwarding captured state entities as non-const lvalues, since it seems
sufficient to handle the const lvalue and non-const rvalue cases for now,
given the current set of standard range adaptors.  But such overloads
can be easily added if they turn out to be needed.

libstdc++-v3/ChangeLog:

PR libstdc++/99433
* include/std/ranges (__adaptor::__maybe_refwrap): Remove.
(__adaptor::__adaptor_invocable): New concept.
(__adaptor::__adaptor_partial_app_viable): New concept.
(__adaptor::_RangeAdaptorClosure): Rewrite, turning it into a
non-template base class.
(__adaptor::_RangeAdaptor): Rewrite, turning it into a CRTP base
class template.
(__adaptor::_Partial): New class template that represents
partial application of a range adaptor non-closure.
(__adaptor::__pipe_invocable): New concept.
(__adaptor::_Pipe): New class template.
(__detail::__can_ref_view): New concept.
(__detail::__can_subrange): New concept.
(all): Replace the lambda here with ...
(_All): ... this functor.  Add appropriate constraints.
(__detail::__can_filter_view): New concept.
(filter, _Filter): As in all/_All.
(__detail::__can_transform): New concept.
(transform, _Transform): As in all/_All.
(__detail::__can_take_view): New concept.
(take, _Take): As in all/_All.
(__detail::__can_take_while_view): New concept.
(take_while, _TakeWhile): As in all/_All.
(__detail::__can_drop_view): New concept.
(drop, _Drop): As in all/_All.
(__detail::__can_drop_while_view): New concept.
(drop_while, _DropWhile): As in all/_All.
(__detail::__can_join_view): New concept.
(join, _Join): As in all/_All.
(__detail::__can_split_view): New concept.
(split, _Split): As in all/_All.  Rename template parameter
_Fp to _Pattern.
(__detail::__already_common): New concept.
(__detail::__can_common_view): New concept.
(common, _Common): As in all/_All.
(__detail::__can_reverse_view): New concept.
(reverse, _Reverse): As in all/_All.
(__detail::__can_elements_view): New concept.
(elements, _Elements): As in all/_All.
(keys, values): Adjust.
* testsuite/std/ranges/adaptors/99433.cc: New test.
* testsuite/std/ranges/adaptors/all.cc: No longer expect that
adding empty range adaptor closure objects to a pipeline doesn't
increase the size of the pipeline.
(test05): New test.
* testsuite/std/ranges/adaptors/common.cc (test03): New test.
* testsuite/std/ranges/adaptors/drop.cc (test09): New test.
* testsuite/std/ranges/adaptors/drop_while.cc (test04): New test.
* testsuite/std/ranges/adaptors/elements.cc (test04): New test.
* testsuite/std/ranges/adaptors/filter.cc (test06): New test.
* testsuite/std/ranges/adaptors/join.cc (test09): New test.
* testsuite/std/ranges/adaptors/p2281.cc: New test.
* testsuite/std/ranges/adaptors/reverse.cc (test07): New test.
* testsuite/std/ranges/adaptors/split.cc (test01, test04):
Adjust.
(test09): New test.
* testsuite/std/ranges/adaptors/split_neg.cc (test01): Adjust
expected error message.
(test02): Likewise.  Extend 

[Bug target/99900] feature request: 16-bit x86 C compiler / support compilation of (VirtualBox) BIOS

[u1049321969 at caramail dot com via Gcc-bugs]

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

tk  changed:

   What|Removed |Added

 CC||u1049321969 at caramail dot com

--- Comment #5 from tk  ---
Hello all,

> I've no idea whether the (not merged) ia16 port can do this, or whether 
> the person currently maintaining a version of that port for GCC 6 is 
> covered by an FSF copyright assignment.

I am the maintainer behind the https://github.com/tkchia/gcc-ia16 fork.

Yes, I have done the copyright assignments for my IA-16 patches for GCC (in
2017) and also for Binutils (in 2018).  I believe that the previous developers,
Mr. Lambertsen and Mr. Jenner, have also made the needed copyright assignments.

The current gcc-ia16 code can produce code to run on an 8086, 80186, or 80286
machine, and also has support for far pointers --- including far function
pointers.  The texinfo documentation has been updated to lay out the features
that the IA-16 port has.

Thank you!

[Bug testsuite/99605] [11 regression] new test case g++.dg/modules/builtin-3_a.C fails for 32 bits

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

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from seurer at gcc dot gnu.org ---
Actually, it was failing until yesterday.

Wed Apr 7 15:35:24 CDT 2021
 < previous run: g:c84491827990e4f2746442c23294fc17923b265d, r11-7959: 120
failures
 > this run: g:12029c04d01c7ba0f775cdc208edf29490ee5db6, r11-8032: 113
failures

 < FAIL: g++.dg/modules/builtin-3_a.C -std=c++17  scan-lang-dump module "Wrote
fixed:[0-9]* pointer_type:'::__builtin_va_list'"
 < FAIL: g++.dg/modules/builtin-3_a.C -std=c++2a  scan-lang-dump module "Wrote
fixed:[0-9]* pointer_type:'::__builtin_va_list'"
 < FAIL: g++.dg/modules/builtin-3_a.C -std=c++2b  scan-lang-dump module "Wrote
fixed:[0-9]* pointer_type:'::__builtin_va_list'"
. . .

[Bug c++/99970] New: gcc accepts invalid comparison between pointer and integer in requires-clause

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 99970
   Summary: gcc accepts invalid comparison between pointer and
integer in requires-clause
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

https://godbolt.org/z/qs44TqzKe

template 
void f() requires requires { x == "hello world"; } {};
int main() { f(); }

gcc accepts this.

[Bug libstdc++/96029] [8/9/10 Regression] Inconsistencies with associative/unordered containers

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

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

Jonathan Wakely  changed:

   What|Removed |Added

Summary|[8/9/10/11 Regression]  |[8/9/10 Regression]
   |Inconsistencies with|Inconsistencies with
   |associative/unordered   |associative/unordered
   |containers  |containers

--- Comment #2 from Jonathan Wakely  ---
The RB tree regression was fixed on trunk by r11-1910.

The unordered_xxx one was fixed on trunk by r11-2397.

[Bug middle-end/99857] [11 Regression] FAIL: libgomp.c/declare-variant-1.c (test for excess errors) by r11-7926

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Priority|P3  |P1

[Bug middle-end/99857] [11 Regression] FAIL: libgomp.c/declare-variant-1.c (test for excess errors) by r11-7926

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug rtl-optimization/99469] [8/9/10/11 Regression] ICE: qsort checking failed with selective scheduling on aarch64

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.5

[Bug middle-end/93181] [9/10/11 Regression] -Wuninitialized fails to warn about uninitialized value

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.4

[Bug middle-end/88897] [9/10/11 Regression] Bogus maybe-uninitialized warning on class field (missed CSE)

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.4

[Bug tree-optimization/81958] [9/10/11 Regression] spurious -Wmaybe-uninitialized warning in gcc-8, or with -O1

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.4