[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.

Re: GCC association with the FSF

[David Malcolm via Gcc]

On Thu, 2021-04-08 at 20:21 +0200, John Darrington wrote:
> On Thu, Apr 08, 2021 at 10:54:25AM -0400, David Malcolm wrote: 

[...]

>  Some of us don't want RMS in a leadership position in a project
> we're
>  associated with (be it the FSF or GNU, and thus, GCC).
> 
> RMS was the first person to be involved in GNU and GCC.  Others
> became
> involved later (under his leadership).  Their contribution was and
> continues to be welcome.  They are also free to stop contributing any
> time they wish to do so.

I intend to continue contributing to GCC (and to Free Software in
general), but RMS is not my leader.

>  
>  My opinions, not my employer's, as usual.
> 
> Then why do you write this from your employer's email?

My employer gives me permission.

>   That is like
> writing it on the company letterhead.

I disagree.

>   I suggest that when speaking
> for yourself you use your own email.

Given the reaction that some have faced for questioning RMS, I'd prefer
to keep that address private.

As before, these are my opinions, not my employer's.

Dave

[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)

Re: [PATCH] lra: Canonicalize mult to shift in address reloads

[Maciej W. Rozycki]

On Thu, 8 Apr 2021, Maciej W. Rozycki wrote:

> > Does the patch also help to optimise my example above?  If so,
> > it sounds like a good thing for that reason alone.
> 
>  Nope, it actually regresses code produced, causing an extra instruction 
> to be used where it doesn't have to:
> 
> --- test-ira/test.s
> +++ test-lra-legitimate-address-ashift/test.s
> @@ -8,7 +8,8 @@
>   .word 0
>   subl2 $4,%sp
>   calls $0,foo
> - addl3 8(%ap),$3,%r1
> + movl 8(%ap),%r1
> + addl2 $12,%r0
>   moval 0[%r1],%r1
>   addl2 %r1,%r0
>   ret
> 
> (old code is either IRA, or LRA without my change to accept ASHIFT in 
> TARGET_LEGITIMATE_ADDRESS_P).  Please observe that the original ADDL3 
> instruction completes the index calculation (as desired, as noted above), 
> and then the rest boils down to combining it with the base component as 
> handed over by `foo'.
> 
>  NB (%reg) is a base register and [%reg] is an index register, implicitly 
> scaled by the data width determined by the relevant suffix of the mnemonic 
> (`l' here stands for "longword", so 32-bit).  And MOVA is "move address" 
> like x86's LEA.
> 
>  Though frankly what we really want anyway is:
> 
>   calls $0,foo
>   addl3 8(%ap),$3,%r1
>   moval (%r0)[%r1],%r0
>   ret
> 
> because what we need to do here to complete the calculation is to combine 
> the base in %r0 with the index in %r1 -- there's no performance penalty 
> for the use of a base register (an index costs an extra cycle) and the 
> encoding is much shorter:
> 
>   11: de 41 9f 00 moval *0x0[r1],r1
>   15: 00 00 00 51 

 FAOD mind that MOVAL produced here does not come from indexed addressing 
but rather from the ASHIFT pattern, as also shown by the original insn:

(insn 23 22 24 2 (set (reg:SI 1 %r1 [36])
(ashift:SI (reg/v:SI 1 %r1 [orig:29 x ] [29])
(const_int 2 [0x2]))) "test.c":2:56 432 {ashlsi3}
 (nil))

I quoted in last message, or in the past-reload form:

(insn 27 26 28 (parallel [
(set (reg:SI 1 %r1 [36])
(ashift:SI (reg/v:SI 1 %r1 [orig:29 x ] [29])
(const_int 2 [0x2])))
(clobber (reg:CC 16 %psl))
]) "test.c":2:56 433 {*ashlsi3}
 (expr_list:REG_UNUSED (reg:CC 16 %psl)
(nil)))

>   19: c0 51 50addl2 r1,r0
> 
> vs:
> 
>   11: de 41 60 50 moval (r0)[r1],r0
> 
> (because in the absence of a base register the absolute address mode has 
> to be used, which always uses full 32-bit extension, unlike displacements 
> optionally used with a base register).  But while we're not there, we're 
> moving away from rather than towards the desired solution.  This seems to 
> be an unfortunate consequence of how reload works though, so I gather it 
> needs to be fixed in reload.

 So I thought of another experiment and I applied my ASHIFT patch to the 
old reload configuration.  In its unmodified form it caused an ICE with 
your example:

during RTL pass: final
test.c: In function 'bar':
test.c:2:56: internal compiler error: in print_operand_address, at 
config/vax/vax.c:419
2 | long *bar (long *ptr, long x) { return  ()[x + 3]; }
  |^
0x1188489f print_operand_address(_IO_FILE*, rtx_def*)
.../gcc/config/vax/vax.c:419
0x111acbbb default_print_operand_address(_IO_FILE*, machine_mode, rtx_def*)
.../gcc/targhooks.c:367
0x10b3115f output_address(machine_mode, rtx_def*)
.../gcc/final.c:4085
0x10b3088b output_asm_insn(char const*, rtx_def**)
.../gcc/final.c:3942
0x10b2ea63 final_scan_insn_1
.../gcc/final.c:3125
0x10b2eda7 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
.../gcc/final.c:3171
0x10b2bd1f final_1
.../gcc/final.c:2022
0x10b327e3 rest_of_handle_final
.../gcc/final.c:4676
0x10b32d23 execute
.../gcc/final.c:4754
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

coming from:

(plus:SI (ashift:SI (reg/v:SI 1 %r1 [orig:29 x ] [29])
(const_int 2 [0x2]))
(reg:SI 0 %r0 [33]))

and serving as a proof that backends used not to expect ASHIFT in 
addresses.  Anyway I went ahead and converted `print_operand_address' too, 
yielding this code:

calls $0,foo
movl 8(%ap),%r1
moval 12(%r0)[%r1],%r0
ret

or:

   c:   d0 ac 08 51 movl 0x8(ap),r1
  10:   de 41 a0 0c moval 0xc(r0)[r1],r0
  14:   50 
  15:   04  ret

which does use indexed addressing:

(insn 24 23 17 (parallel [
(set (reg/i:SI 0 %r0)
(plus:SI (plus:SI (ashift:SI (reg/v:SI 1 %r1 [orig:29 x ] [29])
(const_int 2 [0x2]))
(reg:SI 0 %r0 [33]))
(const_int 12 [0xc])))
(clobber (reg:CC 16 %psl))
]) "test.c":2:56 623 {*movaddrsi}
 

[committed] libstdc++: Remove spurious line break in doxygen comment

[Jonathan Wakely via Gcc-patches]

libstdc++-v3/ChangeLog:

* include/bits/basic_string.h: Tweak doxygen comment.

Tested powerpc64le-linux. Committed to trunk.

commit 96292c3e3439aa167ed7ae595f89b8776e705897
Author: Jonathan Wakely 
Date:   Thu Apr 8 23:39:29 2021

libstdc++: Remove spurious line break in doxygen comment

libstdc++-v3/ChangeLog:

* include/bits/basic_string.h: Tweak doxygen comment.

diff --git a/libstdc++-v3/include/bits/basic_string.h 
b/libstdc++-v3/include/bits/basic_string.h
index 7d819bb1bb7..3c5309d16e6 100644
--- a/libstdc++-v3/include/bits/basic_string.h
+++ b/libstdc++-v3/include/bits/basic_string.h
@@ -4709,8 +4709,7 @@ _GLIBCXX_END_NAMESPACE_CXX11
*  @brief  Insert a string_view.
*  @param __pos1  Position in string to insert at.
*  @param __svt   The object convertible to string_view to insert from.
-   *  @param __pos2  Position in string_view to insert
-   *  from.
+   *  @param __pos2  Position in string_view to insert from.
*  @param __nThe number of characters to insert.
*  @return  Reference to this string.
   */

[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).

gcc-8-20210408 is now available

[GCC Administrator via Gcc]

Snapshot gcc-8-20210408 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/8-20210408/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 8 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-8 
revision 3a4f14984603b0a9969bb71d3cd1a3acc225d107

You'll find:

 gcc-8-20210408.tar.xzComplete GCC

  SHA256=d09559d3bb4a6322326e94ed119b3bd6569fee8a5e65f19778deafd08a4c484e
  SHA1=6c23725ef4b76e92780fbb202d1406a1234eba0a

Diffs from 8-20210401 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-8
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

[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

[PATCH] propagate attributes to local redeclaration (PR 99420)

[Martin Sebor via Gcc-patches]

The C front end ordinarily merges function type attributes upon
the redeclaration of a function but it doesn't do that for those
at local scope, unless the declaration refers to a built-in.

Because the new -Warray-parameter warning relies on the internal
access attribute on the type of the function added by the C front
end for parameters declared using the array notation, it triggers
when it sees a redeclaration of a function in a local scope even
when both declarations use the same array form, issuing a false
positive.

The same problem affects other similar redeclarations involving
attributes, such as unused_result, causing false negatives there.
(Clang and ICC behave as I expect.)

The attached patch lets the front end propagate the type attributes
for all redeclarations, resolving this class of problems for all
affected attributes.

There's another similar piece of code in pushdecl() that I didn't
touch, although  I couldn't come up with a test case showing it's
necessary.  Both hunks go back ages so I wonder if they might have
been obviated by other improvements.

Martin
PR c/99420 - bogus -Warray-parameter on a function redeclaration in function scope
PR c/99972 - missing -Wunused-result on a call to a locally redeclared warn_unused_result function

gcc/c/ChangeLog:

	PR c/99420
	PR c/99972
	* c-decl.c (pushdecl): Always propagate type attribute.

gcc/testsuite/ChangeLog:

	PR c/99420
	PR c/99972
	* gcc.dg/Warray-parameter-9.c: New test.
	* gcc.dg/Wnonnull-6.c: New test.
	* gcc.dg/Wreturn-type3.c: New test.
	* gcc.dg/Wunused-result.c: New test.
	* gcc.dg/attr-noreturn.c: New test.
	* gcc.dg/attr-returns-nonnull.c: New test.

diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
index 3b2241bfd97..677bfd73a50 100644
--- a/gcc/c/c-decl.c
+++ b/gcc/c/c-decl.c
@@ -3263,11 +3263,10 @@ pushdecl (tree x)
 	  else
 	thistype = type;
 	  b->u.type = TREE_TYPE (b->decl);
-	  if (TREE_CODE (b->decl) == FUNCTION_DECL
-	  && fndecl_built_in_p (b->decl))
-	thistype
-	  = build_type_attribute_variant (thistype,
-	  TYPE_ATTRIBUTES (b->u.type));
+	  /* Propagate the type attributes to the decl.  */
+	  thistype
+	= build_type_attribute_variant (thistype,
+	TYPE_ATTRIBUTES (b->u.type));
 	  TREE_TYPE (b->decl) = thistype;
 	  bind (name, b->decl, scope, /*invisible=*/false, /*nested=*/true,
 		locus);
diff --git a/gcc/testsuite/gcc.dg/Warray-parameter-9.c b/gcc/testsuite/gcc.dg/Warray-parameter-9.c
new file mode 100644
index 000..b5d3d963c88
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/Warray-parameter-9.c
@@ -0,0 +1,54 @@
+/* PR c/99420 - bogus -Warray-parameter on a function redeclaration
+   in function scope
+   { dg-do compile }
+   { dg-options "-Wall" } */
+
+extern int a1[1], a2[2], a3[3], a4[4];
+
+void fa1 (int [1]); // { dg-message "previously declared as 'int\\\[1]'" }
+void fa1 (int [1]);
+
+
+void nested_decl (void)
+{
+  void fa2 (int [2]);
+
+  fa2 (a1); // { dg-warning "\\\[-Warray-bounds|-Wstringop-overflow" }
+  fa2 (a2);
+  fa2 (a3);
+
+  void fa3 (int [3]);
+
+  fa3 (a2); // { dg-warning "\\\[-Warray-bounds|-Wstringop-overflow" }
+  fa3 (a3);
+}
+
+
+void nested_redecl (void)
+{
+  void fa1 (int [2]);   // { dg-warning "argument 1 of type 'int\\\[2]' with mismatched bound" }
+
+  fa1 (a1 + 1); // { dg-warning "\\\[-Warray-bounds|-Wstringop-overflow" }
+  fa1 (a1);
+
+  void fa2 (int [2]);   // { dg-bogus "\\\[-Warray-parameter" }
+
+  fa2 (a1); // { dg-warning "\\\[-Warray-bounds|-Wstringop-overflow" }
+  fa2 (a2);
+  fa2 (a3);
+
+  void fa3 (int [3]);   // { dg-bogus "\\\[-Warray-parameter" }
+
+  fa3 (a2); // { dg-warning "\\\[-Warray-bounds|-Wstringop-overflow" }
+  fa3 (a3);
+
+  void fa4 (int [4]);
+}
+
+void fa4 (int [5]); // { dg-warning "\\\[-Warray-parameter" }
+
+void call_fa4 (void)
+{
+  fa4 (a4);
+  fa4 (a3); // { dg-warning "\\\[-Warray-bounds|-Wstringop-overflow" }
+}
diff --git a/gcc/testsuite/gcc.dg/Wnonnull-6.c b/gcc/testsuite/gcc.dg/Wnonnull-6.c
new file mode 100644
index 000..48f09da996f
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/Wnonnull-6.c
@@ -0,0 +1,93 @@
+/* Verify that attribute nonnull on global and local function declarations
+   or those to pointers to functions is merged.
+   { dg-do compile }
+   { dg-options "-Wall" } */
+
+void fnonnull_local_local (void)
+{
+  extern __attribute__ ((nonnull)) void fnonnull1 (void*);
+
+  fnonnull1 (0);// { dg-warning "\\\[-Wnonnull" }
+}
+
+void gnonnull_local_local (void)
+{
+  extern void fnonnull1 (void*);
+
+  fnonnull1 (0);// { dg-warning "\\\[-Wnonnull" }
+}
+
+
+void fnonnull_local_global (void)
+{
+  extern __attribute__ ((nonnull)) void fnonnull2 (void*);
+
+  fnonnull2 (0);// { dg-warning "\\\[-Wnonnull" }
+}
+
+extern void fnonnull2 (void*);
+
+void gnonnull_local_global (void)
+{
+  fnonnull2 (0);// { dg-warning "\\\[-Wnonnull" }
+}
+
+
+extern __attribute__ ((nonnull)) void fnonnull3 

[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.

Re: [PATCH] lra: Canonicalize mult to shift in address reloads

[Maciej W. Rozycki]

On Thu, 25 Mar 2021, Richard Sandiford wrote:

> "Maciej W. Rozycki"  writes:
> > On Wed, 26 Aug 2020, Vladimir Makarov via Gcc-patches wrote:
> >
> >> On 2020-08-26 5:06 a.m., Richard Sandiford wrote:
> >> > 
> >> > I don't think we should we restrict this to (plus (mult X Y) Z),
> >> > since addresses can be more complicated than that.  One way to
> >> > search for all MULTs is:
> >> > 
> >> >subrtx_iterator::array_type array;
> >> >FOR_EACH_SUBRTX (iter, array, x, NONCONST)
> >> >  {
> >> >rtx x = *iter;
> >> >if (GET_CODE (x) == MULT && CONST_INT_P (XEXP (x, 1)))
> >> >  ...
> >> >  }
> >> > 
> >> > (Needs rtl-iter.h)
> >> 
> >> I am agree it would be nice to process a general case.  Alex, you can do 
> >> this
> >> as a separate patch if you want.
> >> 
> >> Richard, thank you for looking at this patch too.
> >
> > [From ; 
> > also commit 6b3034eaba83.]
> >
> >  Guys, this triggers a backend's functional regression and an ICE in the 
> > test suite with the LRA conversion I'm currently working on for the VAX 
> > backend.  Before I go ahead and paper it over in the backend I'd like to 
> > understand why this change was considered correct in the first place.
> >
> >  Contrary to what the change description suggests the ASHIFT form is not 
> > documented to be the canonical form for constant multiplication involving 
> > a power of two for addresses used outside `mem'.
> 
> One thing to note here is that, outside of a mem, there's no distinction
> between an address calculation and normal integer arithmetic.  In other
> words, “addresses used outside of a ‘mem’” aren't a distinct category of
> rtx that can be separated from other things outside of a “mem“.  So…

 In principle you're right, however my interpretation would be that 
whenever TARGET_LEGITIMATE_ADDRESS_P is called the middle end does 
consider the rtx passed an address calculation rather than normal integer 
arithmetic even if potentially.  So I would expect the middle end to 
convert the calculation to the canonical address form before such 
invocation even if to convert it back (revert to the original unconverted 
form) right after the return from TARGET_LEGITIMATE_ADDRESS_P.

 And it seems to me like this change has broken the contract for rtx's 
passed to TARGET_LEGITIMATE_ADDRESS_P that have been produced by the 
middle end rather than individual backends (which I guess may have not 
kept to the contract as indicated by the PR target/43766 fix for x86).

 Have I got my interpretation wrong here?

> > What our rules only say 
> > is that for addresses inside `mem' the MULT form is:
> >
> >* Within address computations (i.e., inside 'mem'), a left shift is
> >  converted into the appropriate multiplication by a power of two.
> >
> >  This change does the reverse of the conversion described above and makes
> > TARGET_LEGITIMATE_ADDRESS_P and possibly other backend code be presented 
> > with either form for indexed addresses, which complicates handling.  The 
> > ICE mentioned above specifically is caused by:
> >
> > (plus:SI (plus:SI (mult:SI (reg:SI 30 [ _10 ])
> > (const_int 4 [0x4]))
> > (reg/f:SI 26 [ _6 ]))
> > (const_int 12 [0xc]))
> 
> …if you write:
> 
> ---
> long *foo ();
> long *bar (long *ptr, long x) { return  ()[x + 3]; }
> ---
> 
> then the rtl you get is:
> 
> ---
> …
> (insn 10 9 11 2 (set (reg:SI 32)
> (plus:SI (reg/v:SI 29 [ x ])
> (const_int 3 [0x3]))) "/tmp/foo.c":2:47 -1
>  (nil))
> (insn 11 10 12 2 (set (reg:SI 33)
> (ashift:SI (reg:SI 32)
> (const_int 2 [0x2]))) "/tmp/foo.c":2:47 -1
>  (nil))
> (insn 12 11 13 2 (set (reg:SI 31)
> (plus:SI (reg/f:SI 23 [ _1 ])
> (reg:SI 33))) "/tmp/foo.c":2:40 -1
>  (nil))
> …
> ---
> 
> where the address uses “ashift” rather than “mult”.  Then combine
> tries to generate the same kind of address as the one you quote above,
> but with “ashift” rather than “mult”:
> 
> ---
> Trying 10, 11 -> 12:
>10: r32:SI=r29:SI+0x3
>   REG_DEAD r29:SI
>11: r33:SI=r32:SI<<0x2
>   REG_DEAD r32:SI
>12: r31:SI=r34:SI+r33:SI
>   REG_DEAD r34:SI
>   REG_DEAD r33:SI
> Failed to match this instruction:
> (set (reg:SI 31)
> (plus:SI (plus:SI (ashift:SI (reg/v:SI 29 [ x ])
> (const_int 2 [0x2]))
> (reg:SI 34))
> (const_int 12 [0xc])))
> ---
> 
> So I don't see your VAX change as papering over the issue.  The above
> “ashift” form is what address calculations normally look like outside
> of a “mem”.  

[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.

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

[Patrick Palka via Gcc-patches]

On Thu, 8 Apr 2021, Jason Merrill wrote:

> On 4/7/21 12:10 PM, Patrick Palka wrote:
> > 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 we need to be able to get at all in-scope template
> > parameters and the corresponding template arguments during constraint
> > checking of a lambda's op().  And this information is not easily
> > available where 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.
> 
> I'm a little surprised you didn't use a TEMPLATE_INFO for these, but this way
> is fine too.

Using a TEMPLATE_INFO here works nicely here, I hadn't considered it.
Like so?  Tested on x86_64-pc-linux-gnu.

-- >8 --

Subject: [PATCH] c++: Use a TEMPLATE_INFO to hold regenerated lambda info

A TEMPLATE_INFO is a natural fit for what LAMBDA_EXPR_REGENERATED_FROM
and LAMBDA_EXPR_REGENERATING_TARGS hold, so let's use it instead.

gcc/cp/ChangeLog:

* cp-tree.h (LAMBDA_EXPR_REGENERATED_FROM)
(LAMBDA_EXPR_REGENERATING_TARGS): Replace these with ...
(LAMBDA_EXPR_REGEN_INFO): ... this.
(tree_lambda_expr::regenerated_from)
(tree_lambda_expr::regenerating_targs): Replace these with ...
(tree_lambda_expr::regen_info): ... this.
* constraint.cc (satisfy_declaration_constraints): Adjust
accordingly.
* lambda.c (build_lambda_expr): Likewise.
* pt.c (regenerated_lambda_fn_p): Likewise.
(most_general_lambda): Likewise.
(tsubst_lambda_expr): Likewise.
---
 gcc/cp/constraint.cc |  4 ++--
 gcc/cp/cp-tree.h | 18 +++---
 gcc/cp/lambda.c  |  3 +--
 gcc/cp/pt.c  | 15 +--
 4 files changed, 19 insertions(+), 21 deletions(-)

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index 0a9d1bfea0f..0ddb2990dd9 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -3193,7 +3193,7 @@ satisfy_declaration_constraints (tree t, sat_info info)
 arguments that were used to regenerate the lambda.  */
   gcc_assert (!args || TMPL_ARGS_DEPTH (args) == 1);
   tree lambda = CLASSTYPE_LAMBDA_EXPR (DECL_CONTEXT (t));
-  tree outer_args = LAMBDA_EXPR_REGENERATING_TARGS (lambda);
+  tree outer_args = TI_ARGS (LAMBDA_EXPR_REGEN_INFO (lambda));
   if (args)
args = add_to_template_args (outer_args, args);
   else
@@ -3256,7 +3256,7 @@ satisfy_declaration_constraints (tree t, tree args, 
sat_info info)
   /* As in the two-parameter version of this function.  */
   gcc_assert (TMPL_ARGS_DEPTH (args) == 1);
   tree lambda = CLASSTYPE_LAMBDA_EXPR (DECL_CONTEXT (t));
-  tree outer_args = LAMBDA_EXPR_REGENERATING_TARGS (lambda);
+  tree outer_args = TI_ARGS (LAMBDA_EXPR_REGEN_INFO (lambda));
   args = add_to_template_args (outer_args, args);
 }
   else
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index bf9d5add0cf..e42b82ae5a4 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -1456,15 +1456,12 @@ enum cp_lambda_default_capture_mode_type {
 #define LAMBDA_EXPR_PENDING_PROXIES(NODE) \
   (((struct tree_lambda_expr *)LAMBDA_EXPR_CHECK (NODE))->pending_proxies)
 
-/* The immediate LAMBDA_EXPR from which NODE was regenerated, or NULL_TREE
-   (if NODE was not regenerated via tsubst_lambda_expr).  */
-#define LAMBDA_EXPR_REGENERATED_FROM(NODE) \
-  (((struct tree_lambda_expr *)LAMBDA_EXPR_CHECK (NODE))->regenerated_from)
-
-/* The full set of template arguments used to regenerate NODE, or NULL_TREE
-   (if NODE was not regenerated via tsubst_lambda_expr).  */
-#define LAMBDA_EXPR_REGENERATING_TARGS(NODE) \
-  (((struct tree_lambda_expr *)LAMBDA_EXPR_CHECK (NODE))->regenerating_targs)
+/* If NODE was regenerated via tsubst_lambda_expr, this is a TEMPLATE_INFO
+   whose TI_TEMPLATE is the immediate LAMBDA_EXPR from which NODE was
+   regenerated, and TI_ARGS is the full set of template arguments used
+   to regenerate NODE from the most general lambda.  */
+#define LAMBDA_EXPR_REGEN_INFO(NODE) \
+  (((struct tree_lambda_expr *)LAMBDA_EXPR_CHECK (NODE))->regen_info)
 
 /* The closure type of the lambda, which is also the type of 

Re: [PATCH v2] c++: Fix two issues with auto function parameter [PR99806]

[Marek Polacek via Gcc-patches]

On Thu, Apr 08, 2021 at 04:37:00PM -0400, Patrick Palka wrote:
> On Thu, 8 Apr 2021, Marek Polacek via Gcc-patches wrote:
> 
> > When we have a member function with auto parameter like this:
> > 
> >   struct S {
> > void f(auto);
> >   };
> > 
> > cp_parser_member_declaration -> grokfield produces a FUNCTION_DECL
> > "void S::foo(auto:1)", and then finish_fully_implicit_template turns
> > that FUNCTION_DECL into a TEMPLATE_DECL.  The bug here is that we only
> > call cp_parser_save_default_args for a FUNCTION_DECL.  As a consequence,
> > abbrev10.C is rejected because we complain that the default argument has
> > not been defined, and abbrev11.C ICEs, because we don't re-parse the
> > delayed noexcept, so the DEFERRED_PARSE tree leaks into tsubst* where we
> > crash.  This patch fixes both issues.
> > 
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/10.4?
> > 
> > gcc/cp/ChangeLog:
> > 
> > PR c++/99806
> > * parser.c (cp_parser_member_declaration): Call
> > cp_parser_save_default_args even for function templates.
> > (cp_parser_save_default_args): Extract the function declaration
> > from a function template.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > PR c++/99806
> > * g++.dg/concepts/abbrev10.C: New test.
> > * g++.dg/concepts/abbrev11.C: New test.
> > ---
> >  gcc/cp/parser.c  |  8 +---
> >  gcc/testsuite/g++.dg/concepts/abbrev10.C | 18 ++
> >  gcc/testsuite/g++.dg/concepts/abbrev11.C | 10 ++
> >  3 files changed, 33 insertions(+), 3 deletions(-)
> >  create mode 100644 gcc/testsuite/g++.dg/concepts/abbrev10.C
> >  create mode 100644 gcc/testsuite/g++.dg/concepts/abbrev11.C
> > 
> > diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
> > index 59adac4492a..eef6bb3003e 100644
> > --- a/gcc/cp/parser.c
> > +++ b/gcc/cp/parser.c
> > @@ -26433,7 +26433,8 @@ cp_parser_member_declaration (cp_parser* parser)
> >   || !DECL_DECLARES_FUNCTION_P (decl))
> > finish_member_declaration (decl);
> >  
> > - if (TREE_CODE (decl) == FUNCTION_DECL)
> > + if (TREE_CODE (decl) == FUNCTION_DECL
> > + || DECL_FUNCTION_TEMPLATE_P (decl))
> 
> I guess you could use DECL_DECLARES_FUNCTION_P here.

Right, thanks.

> > cp_parser_save_default_args (parser, decl);
> >   else if (TREE_CODE (decl) == FIELD_DECL
> >&& DECL_INITIAL (decl))
> > @@ -30959,9 +30960,10 @@ cp_parser_late_parsing_for_member (cp_parser* 
> > parser, tree member_function)
> >  static void
> >  cp_parser_save_default_args (cp_parser* parser, tree decl)
> >  {
> > -  tree probe;
> > +  if (DECL_FUNCTION_TEMPLATE_P (decl))
> > +decl = DECL_TEMPLATE_RESULT (decl);
> 
> Not sure if it'd be an improvement, but could use STRIP_TEMPLATE here
> instead (or perhaps on the caller side).

Might as well.  How's this?

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/10?

-- >8 --
When we have a member function with auto parameter like this:

  struct S {
void f(auto);
  };

cp_parser_member_declaration -> grokfield produces a FUNCTION_DECL
"void S::foo(auto:1)", and then finish_fully_implicit_template turns
that FUNCTION_DECL into a TEMPLATE_DECL.  The bug here is that we only
call cp_parser_save_default_args for a FUNCTION_DECL.  As a consequence,
abbrev10.C is rejected because we complain that the default argument has
not been defined, and abbrev11.C ICEs, because we don't re-parse the
delayed noexcept, so the DEFERRED_PARSE tree leaks into tsubst* where we
crash.  This patch fixes both issues.

gcc/cp/ChangeLog:

PR c++/99806
* parser.c (cp_parser_member_declaration): Call
cp_parser_save_default_args even for function templates.  Use
STRIP_TEMPLATE on the declaration we're passing.

gcc/testsuite/ChangeLog:

PR c++/99806
* g++.dg/concepts/abbrev10.C: New test.
* g++.dg/concepts/abbrev11.C: New test.
---
 gcc/cp/parser.c  |  4 ++--
 gcc/testsuite/g++.dg/concepts/abbrev10.C | 18 ++
 gcc/testsuite/g++.dg/concepts/abbrev11.C | 10 ++
 3 files changed, 30 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/concepts/abbrev10.C
 create mode 100644 gcc/testsuite/g++.dg/concepts/abbrev11.C

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 59adac4492a..e6e6ed72a42 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -26433,8 +26433,8 @@ cp_parser_member_declaration (cp_parser* parser)
  || !DECL_DECLARES_FUNCTION_P (decl))
finish_member_declaration (decl);
 
- if (TREE_CODE (decl) == FUNCTION_DECL)
-   cp_parser_save_default_args (parser, decl);
+ if (DECL_DECLARES_FUNCTION_P (decl))
+   cp_parser_save_default_args (parser, STRIP_TEMPLATE (decl));
  else if (TREE_CODE (decl) == FIELD_DECL
   && DECL_INITIAL (decl))
/* 

[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.

[committed] libstdc++: Improve error reporting if PDF generation fails

[Jonathan Wakely via Gcc-patches]

If pdflatex runs out of memory the build fails with no hint what's
wrong. This adds another grep command to the makefile so that an
out-of-memory error will result in more information being shown.

As suggested in https://bugzilla.redhat.com/show_bug.cgi?id=1841056
using lualatex can be used as a workaround.

libstdc++-v3/ChangeLog:

* doc/Makefile.am (stamp-pdf-doxygen): Also grep for
out-of-memory error in log file.
* doc/Makefile.in: Regenerate.

Tested x86_64-linux. Committed to trunk.

commit be8d5f99f50cf282c21632e60fe1d8857bb5a554
Author: Jonathan Wakely 
Date:   Thu Apr 8 18:37:59 2021

libstdc++: Improve error reporting if PDF generation fails

If pdflatex runs out of memory the build fails with no hint what's
wrong. This adds another grep command to the makefile so that an
out-of-memory error will result in more information being shown.

As suggested in https://bugzilla.redhat.com/show_bug.cgi?id=1841056
using lualatex can be used as a workaround.

libstdc++-v3/ChangeLog:

* doc/Makefile.am (stamp-pdf-doxygen): Also grep for
out-of-memory error in log file.
* doc/Makefile.in: Regenerate.

diff --git a/libstdc++-v3/doc/Makefile.am b/libstdc++-v3/doc/Makefile.am
index 2e0eb187f91..cb9b68ffaea 100644
--- a/libstdc++-v3/doc/Makefile.am
+++ b/libstdc++-v3/doc/Makefile.am
@@ -267,6 +267,7 @@ stamp-pdf-doxygen: stamp-latex-doxygen ${doxygen_outdir}/pdf
else \
  echo "... error"; \
  grep -F 'LaTeX Error' ${doxygen_outdir}/latex/refman.log; \
+ grep -F 'TeX capacity exceeded, sorry' 
${doxygen_outdir}/latex/refman.log; \
  exit 12; \
fi
$(STAMP) stamp-pdf-doxygen

Re: [committed] libstdc++: Fix doxygen markup for group close commands

[Jonathan Wakely via Gcc-patches]

On 06/04/21 16:54 +0100, Jonathan Wakely wrote:

A change in Doxygen 1.8.16 means that "// @}" is no longer recognized by
Doxygen, so doesn't close a @{ group. A "///" comment needs to be used.


There are a few cases of /* @} */ which need a similar fix.

Tested powerpc64le-linux. Committed to trunk.


commit 014b6dbcaa80fc46c792c270244e7eeef7dce75f
Author: Jonathan Wakely 
Date:   Thu Apr 8 18:22:51 2021

libstdc++: Fix more doxygen markup for group close commands

Similar to r11-8009 but for /* @} */ comments this time, which should
be /** @} */ for Doxygen to recognize them.

libstdc++-v3/ChangeLog:

* include/bits/random.h: Fix doxygen group commands.
* include/bits/regex_constants.h: Likewise.
* include/tr1/random.h: Likewise.

diff --git a/libstdc++-v3/include/bits/random.h b/libstdc++-v3/include/bits/random.h
index 877ac3406b6..1b9cc5f16a9 100644
--- a/libstdc++-v3/include/bits/random.h
+++ b/libstdc++-v3/include/bits/random.h
@@ -1675,7 +1675,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 };
   };
 
-  /* @} */ // group random_generators
+  /// @} group random_generators
 
   /**
* @addtogroup random_distributions Random Number Distributions
@@ -1951,7 +1951,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 operator>>(std::basic_istream<_CharT, _Traits>&,
 	   std::uniform_real_distribution<_RealType>&);
 
-  /* @} */ // group random_distributions_uniform
+  /// @} group random_distributions_uniform
 
   /**
* @addtogroup random_distributions_normal Normal Distributions
@@ -3506,7 +3506,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 { return !(__d1 == __d2); }
 
 
-  /* @} */ // group random_distributions_normal
+  /// @} group random_distributions_normal
 
   /**
* @addtogroup random_distributions_bernoulli Bernoulli Distributions
@@ -4402,7 +4402,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 { return !(__d1 == __d2); }
 
 
-  /* @} */ // group random_distributions_bernoulli
+  /// @} group random_distributions_bernoulli
 
   /**
* @addtogroup random_distributions_poisson Poisson Distributions
@@ -6048,9 +6048,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 { return !(__d1 == __d2); }
 
 
-  /* @} */ // group random_distributions_poisson
+  /// @} group random_distributions_poisson
 
-  /* @} */ // group random_distributions
+  /// @} *group random_distributions
 
   /**
* @addtogroup random_utilities Random Number Utilities
@@ -6101,9 +6101,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 std::vector _M_v;
   };
 
-  /* @} */ // group random_utilities
+  /// @} group random_utilities
 
-  /* @} */ // group random
+  /// @} group random
 
 _GLIBCXX_END_NAMESPACE_VERSION
 } // namespace std
diff --git a/libstdc++-v3/include/bits/regex_constants.h b/libstdc++-v3/include/bits/regex_constants.h
index 340421a5abd..1c3dd36d57c 100644
--- a/libstdc++-v3/include/bits/regex_constants.h
+++ b/libstdc++-v3/include/bits/regex_constants.h
@@ -409,7 +409,7 @@ namespace regex_constants
 
   ///@}
 } // namespace regex_constants
-/* @} */ // group regex
+/// @} group regex
 
 _GLIBCXX_END_NAMESPACE_VERSION
 } // namespace std
diff --git a/libstdc++-v3/include/tr1/random.h b/libstdc++-v3/include/tr1/random.h
index 57c434f6966..9c79cfd8035 100644
--- a/libstdc++-v3/include/tr1/random.h
+++ b/libstdc++-v3/include/tr1/random.h
@@ -1543,7 +1543,7 @@ namespace tr1
 #endif
   };
 
-  /* @} */ // group tr1_random_generators
+  /// @} group tr1_random_generators
 
   /**
* @addtogroup tr1_random_distributions Random Number Distributions
@@ -2046,7 +2046,7 @@ namespace tr1
   bool  _M_easy;
 };
 
-  /* @} */ // group tr1_random_distributions_discrete
+  /// @} group tr1_random_distributions_discrete
 
   /**
* @addtogroup tr1_random_distributions_continuous Continuous Distributions
@@ -2403,9 +2403,9 @@ namespace tr1
   result_type _M_l_d;
 };
 
-  /* @} */ // group tr1_random_distributions_continuous
-  /* @} */ // group tr1_random_distributions
-  /* @} */ // group tr1_random
+  /// @} group tr1_random_distributions_continuous
+  /// @} group tr1_random_distributions
+  /// @} group tr1_random
 }
 
 _GLIBCXX_END_NAMESPACE_VERSION

Re: [PATCH] c++: Fix two issues with auto function parameter [PR99806]

[Patrick Palka via Gcc-patches]

On Thu, 8 Apr 2021, Marek Polacek via Gcc-patches wrote:

> When we have a member function with auto parameter like this:
> 
>   struct S {
> void f(auto);
>   };
> 
> cp_parser_member_declaration -> grokfield produces a FUNCTION_DECL
> "void S::foo(auto:1)", and then finish_fully_implicit_template turns
> that FUNCTION_DECL into a TEMPLATE_DECL.  The bug here is that we only
> call cp_parser_save_default_args for a FUNCTION_DECL.  As a consequence,
> abbrev10.C is rejected because we complain that the default argument has
> not been defined, and abbrev11.C ICEs, because we don't re-parse the
> delayed noexcept, so the DEFERRED_PARSE tree leaks into tsubst* where we
> crash.  This patch fixes both issues.
> 
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/10.4?
> 
> gcc/cp/ChangeLog:
> 
>   PR c++/99806
>   * parser.c (cp_parser_member_declaration): Call
>   cp_parser_save_default_args even for function templates.
>   (cp_parser_save_default_args): Extract the function declaration
>   from a function template.
> 
> gcc/testsuite/ChangeLog:
> 
>   PR c++/99806
>   * g++.dg/concepts/abbrev10.C: New test.
>   * g++.dg/concepts/abbrev11.C: New test.
> ---
>  gcc/cp/parser.c  |  8 +---
>  gcc/testsuite/g++.dg/concepts/abbrev10.C | 18 ++
>  gcc/testsuite/g++.dg/concepts/abbrev11.C | 10 ++
>  3 files changed, 33 insertions(+), 3 deletions(-)
>  create mode 100644 gcc/testsuite/g++.dg/concepts/abbrev10.C
>  create mode 100644 gcc/testsuite/g++.dg/concepts/abbrev11.C
> 
> diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
> index 59adac4492a..eef6bb3003e 100644
> --- a/gcc/cp/parser.c
> +++ b/gcc/cp/parser.c
> @@ -26433,7 +26433,8 @@ cp_parser_member_declaration (cp_parser* parser)
> || !DECL_DECLARES_FUNCTION_P (decl))
>   finish_member_declaration (decl);
>  
> -   if (TREE_CODE (decl) == FUNCTION_DECL)
> +   if (TREE_CODE (decl) == FUNCTION_DECL
> +   || DECL_FUNCTION_TEMPLATE_P (decl))

I guess you could use DECL_DECLARES_FUNCTION_P here.

>   cp_parser_save_default_args (parser, decl);
> else if (TREE_CODE (decl) == FIELD_DECL
>  && DECL_INITIAL (decl))
> @@ -30959,9 +30960,10 @@ cp_parser_late_parsing_for_member (cp_parser* 
> parser, tree member_function)
>  static void
>  cp_parser_save_default_args (cp_parser* parser, tree decl)
>  {
> -  tree probe;
> +  if (DECL_FUNCTION_TEMPLATE_P (decl))
> +decl = DECL_TEMPLATE_RESULT (decl);

Not sure if it'd be an improvement, but could use STRIP_TEMPLATE here
instead (or perhaps on the caller side).

>  
> -  for (probe = TYPE_ARG_TYPES (TREE_TYPE (decl));
> +  for (tree probe = TYPE_ARG_TYPES (TREE_TYPE (decl));
> probe;
> probe = TREE_CHAIN (probe))
>  if (TREE_PURPOSE (probe))
> diff --git a/gcc/testsuite/g++.dg/concepts/abbrev10.C 
> b/gcc/testsuite/g++.dg/concepts/abbrev10.C
> new file mode 100644
> index 000..b611346e926
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/concepts/abbrev10.C
> @@ -0,0 +1,18 @@
> +// PR c++/99806
> +// { dg-do compile { target c++14 } }
> +// { dg-additional-options "-fconcepts" }
> +
> +struct S {
> +  void f(auto, auto, int = 3);
> +  void f2(auto, auto, int = 3) { }
> +  template static T g(T, auto, int = 3);
> +};
> +
> +void
> +g ()
> +{
> +  S::g(1, 2);
> +  S s;
> +  s.f(1, 2);
> +  s.f2(1, 2);
> +}
> diff --git a/gcc/testsuite/g++.dg/concepts/abbrev11.C 
> b/gcc/testsuite/g++.dg/concepts/abbrev11.C
> new file mode 100644
> index 000..ddb479313df
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/concepts/abbrev11.C
> @@ -0,0 +1,10 @@
> +// PR c++/99806
> +// { dg-do compile { target c++14 } }
> +// { dg-additional-options "-fconcepts" }
> +
> +template  concept C = requires (T a) { a.f(0); };
> +struct S {
> +  void f(auto) noexcept(B);
> +  static constexpr bool B = true;
> +};
> +static_assert(C, "");
> 
> base-commit: 123b3e03c911a43054c1f88f5d3110e1d084dd4e
> -- 
> 2.30.2
> 
> 

Re: GCC association with the FSF

[Christopher Dimech via Gcc]

> Sent: Friday, April 09, 2021 at 7:48 AM
> From: "Mark Wielaard" 
> To: "David Malcolm" 
> Cc: "GCC Development" 
> Subject: Re: GCC association with the FSF
>
> Hi David,
>
> On Wed, Apr 07, 2021 at 10:04:21AM -0400, David Malcolm wrote:
> > On Wed, 2021-04-07 at 00:22 +0200, Mark Wielaard wrote:
> > > I admit it isn't looking very good and their last announcement is
> > > certainly odd: https://status.fsf.org/notice/3833062
> > >
> > > But apparently the board is still meeting this week to discuss and
> > > might provide a better statement about the way out of this. So lets
> > > give them a couple more days before writing them off completely.
> > >
> > > > Is there any incident where FSF being the copyright holder for GCC
> > > > has
> > > > made a difference?
> > >
> > > Yes, at least in my experience it has been helpful that the FSF held
> > > copyright of code that had been assigned by various individuals and
> > > companies. It allowed the merger of GNU Classpath and libgcj for
> > > example. There have been various intances where it was helpful that
> > > the FSF could unilatrally adjust the license terms especially when
> > > the
> > > original contributor couldn't be found or didn't exist (as company)
> > > anymore.
> >
> > This benefit arises from having a single entity own the copyright in
> > the code.  It doesn't necessarily have to be the FSF to gain this
> > benefit; it just happens that the FSF currently owns the copyright on
> > the code.
>
> Yes, I admit that it doesn't have to be the FSF specifically. But
> having a shared copyright pool held by one legal entity has benefits.
>
> > Another, transitional approach might be to find another Free Software
> > non-profit and for contributors to start assigning copyright on ongoing
> > work to that other non-profit.  That way there would be only two
> > copyright holders on the code; if the FSF somehow survives its current
> > death-spiral then the other nonprofit could assign copyright back to
> > the FSF;  if it doesn't, well, we've already got bigger problems.
>
> Yes, having all new copyrights pooled together so we have just two
> copyright holders would provide most of the same benefits. And makes
> it easier to deal with the legacy FSF copyrights since there would be
> just one legal entity having to deal with them instead of each
> individual copyright holder on their own.
>
> If it has to come to this then we could take a look at what the
> Conservancy already does for aggregating copyright for their member
> projects, the Linux kernel and Debian project:
> https://sfconservancy.org/copyleft-compliance/
>
> I like their idea of having a counsel of developers that gets involved
> in any action taken on behave of the collective:
> https://sfconservancy.org/docs/blank_linux-enforcement-agreement.pdf
>
> > > And it is really helpful that we don't have to ask permission of
> > > every
> > > individual contributor to be able to create the GCC manual (because
> > > the GPL code and GFDL text could otherwise not be combined) but that
> > > the FSF can grant an exception to one of the developers to create it.
> >
> > Alternatively, the copyright holder could relicense the documentation
> > to a license that is explicitly compatible with the GPL, such as the
> > GPL itself, and not require us to jump through hoops.  (Or we could
> > start a non-GFDL body of documentation under a different copyright
> > holder, but I'm not volunteering for that effort).  In case it's not
> > clear, I think the GFDL is a terrible license, and that it's always a
> > mistake to use it for software documentation.
>
> Yes, I am not clear on why this (relicensing the documentation under
> the GPL) hasn't been done yet. Is this something the Steering
> Committee could start a discussion on with the FSF?
>
> > > > Are there any GPL violations involving GCC code
> > > > that were resolved only because all copyright resides with a single
> > > > entity, that couldn't have been resolved on behalf of individual
> > > > copyright holders?
> > >
> > > I think it has been very helpful preventing those violations. If you
> > > only have individual copyright holders instead of an organisation
> > > with
> > > the means to actually resolve such violations people pay much more
> > > attention to play by the rules. See for example the linux kernel
> > > project. I believe there are so many GPL violations precisely because
> > > almost no individual has the means to take up a case.
> >
> > Again, the "single entity" doesn't need to be the FSF.
>
> It doesn't, but it would be convenient if it was possible.  We have to
> see what the board does to win the confidence of use GNU hackers back.
> They still have to answer the questions we sent them about the GNU/FSF
> relationship:
> https://gnu.wildebeest.org/blog/mjw/2019/12/27/proposals-for-the-new-gnu-fsf-relationship/
> Maybe if the whole board is replaced we can finally have that conversation.
>
> > It's not clear to me to what 

Re: GCC association with the FSF

[David Brown]

On 08/04/2021 19:22, Giacomo Tesio wrote:
> No, David, 
> 
> On April 8, 2021 3:00:57 PM UTC, David Brown  wrote:
> 
>>  (And yes, I mean FOSS here, not just free software.)
> 
> you are not talking about Free Software, but Open Source.
> 
> FOSS, as a term, has been very successful to spread confusion.
> 

You have snipped the context.  Let me repeat it:

"""
... no one can
be in doubt that [RMS's] attitudes and behaviour are not acceptable by
modern standards and are discouraging to developers and users in the
FOSS community.  (And yes, I mean FOSS here, not just free software.)
"""

For most people that have enough interest in software to be aware of the
concepts of free and/or open source software, lump them together.  That
applies to users and developers.  To the majority of gcc users, they do
not care whether the project refers to itself as "free software" or
"open source software".  They often care that it is easily available at
zero cost (though some pay for it - I and my company have, at times,
bought gcc packages), and they like the fact that all the source code is
available even if they don't look at the source themselves.

But whoever you blame for spreading confusion, or for artificially
creating distinctions that rarely matter (this viewpoint has its
supporters too), the fact remains that the mix-up is real.  In almost
all circumstances, to almost all people, it is all "FOSS".  And the GNU
project, along with Linux, LibreOffice (or still OpenOffice, in most
people's minds), Firefox, and a few other big projects are viewed
together as a group and the opposite of "big company" software such as
MS Windows and Office, Apple software, and Adobe Photoshop (to take some
well-known examples).  The attitudes of GNU leaders have an influence on
all of this, as do other public leader figures such as Linus Torvalds.
Their influence (for good or bad) extends well outside the direct
hierarchy of their official positions within their projects.

> 
>> his attitudes and behaviour are not acceptable by
>> modern standards and are discouraging to developers and users in the
>> FOSS community.
> 
> In fact, I'm actively looking for alternatives to GCC (and LLVM) because I 
> cannot trust a 
> GCC anymore and I cannot review each and every change.
> 

That is your choice, obviously.  I don't agree with your points
expressed in this list so far, but you make your own decisions here.
Call me naïve, but I trust the maintainers of gcc to make good technical
decisions and make changes that improve the compiler suite.

I do think it is entirely possible that - for example - Facebook will
pay an employee to add features to gcc with the specific aim of
improving the efficiency of the code Facebook uses.  I think that would
be entirely reasonable, and I would be quite happy with it - either the
changes will coincidentally improve that is useful to me, or it will do
it no harm.  I think it is /implausible/ that any company would exert an
influence over gcc in order to make it worse for competitors or other
users.  This is an open source project (in addition to being free
software) - it is hard to make hidden changes when all changes are
reviewed and visible to many people.  I don't believe in conspiracy
theories - they require the cooperation of too many people who would
disagree and make a noise.

(Mistakes happen, and attacks from outside occasionally happen in open
source projects, but that's another matter.)

> I won't contribute my port and in general will suggest people to look for 
> alternatives.
> 
> 
> But that's not a problem for you, because you do not actually care about real 
> developers 
> and users, just about the US corporations you effectively mentioned and now 
> control 
> several GNU projects:

No, I have no particular interest in any companies (other than loyalty
to my own company).  I am not an American, nor do I live in America - I
am Scottish and live in Norway.  Not that that matters here.

And yes, I care about the gcc developers and their ability and freedom
to work as they want on the project.  I care about potential new
developers too - and I do not want to see them reject the idea of
working for gcc (or any other project) because they perceive a foul
atmosphere of bullying, sexual harassment or misogyny.  Nor would I want
anyone to avoid contributing to gcc because of perceived bias for or
against any particular country, culture, religion, or any other aspect
of life that has no relevance for code development.

And yes, I care about users - I am one, having used gcc for some 25
years on perhaps a dozen different targets.

I don't think any corporations control any GNU projects (with which I am
familiar) in the sense of deciding what goes into them, who works on
them, what direction they should take, or anything of that sort.  But a
big development project takes resources - it costs a lot of money.  This
usually comes from corporations that have an interest in the project's
success - 

[PATCH] c++: Fix two issues with auto function parameter [PR99806]

[Marek Polacek via Gcc-patches]

When we have a member function with auto parameter like this:

  struct S {
void f(auto);
  };

cp_parser_member_declaration -> grokfield produces a FUNCTION_DECL
"void S::foo(auto:1)", and then finish_fully_implicit_template turns
that FUNCTION_DECL into a TEMPLATE_DECL.  The bug here is that we only
call cp_parser_save_default_args for a FUNCTION_DECL.  As a consequence,
abbrev10.C is rejected because we complain that the default argument has
not been defined, and abbrev11.C ICEs, because we don't re-parse the
delayed noexcept, so the DEFERRED_PARSE tree leaks into tsubst* where we
crash.  This patch fixes both issues.

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/10.4?

gcc/cp/ChangeLog:

PR c++/99806
* parser.c (cp_parser_member_declaration): Call
cp_parser_save_default_args even for function templates.
(cp_parser_save_default_args): Extract the function declaration
from a function template.

gcc/testsuite/ChangeLog:

PR c++/99806
* g++.dg/concepts/abbrev10.C: New test.
* g++.dg/concepts/abbrev11.C: New test.
---
 gcc/cp/parser.c  |  8 +---
 gcc/testsuite/g++.dg/concepts/abbrev10.C | 18 ++
 gcc/testsuite/g++.dg/concepts/abbrev11.C | 10 ++
 3 files changed, 33 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/concepts/abbrev10.C
 create mode 100644 gcc/testsuite/g++.dg/concepts/abbrev11.C

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 59adac4492a..eef6bb3003e 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -26433,7 +26433,8 @@ cp_parser_member_declaration (cp_parser* parser)
  || !DECL_DECLARES_FUNCTION_P (decl))
finish_member_declaration (decl);
 
- if (TREE_CODE (decl) == FUNCTION_DECL)
+ if (TREE_CODE (decl) == FUNCTION_DECL
+ || DECL_FUNCTION_TEMPLATE_P (decl))
cp_parser_save_default_args (parser, decl);
  else if (TREE_CODE (decl) == FIELD_DECL
   && DECL_INITIAL (decl))
@@ -30959,9 +30960,10 @@ cp_parser_late_parsing_for_member (cp_parser* parser, 
tree member_function)
 static void
 cp_parser_save_default_args (cp_parser* parser, tree decl)
 {
-  tree probe;
+  if (DECL_FUNCTION_TEMPLATE_P (decl))
+decl = DECL_TEMPLATE_RESULT (decl);
 
-  for (probe = TYPE_ARG_TYPES (TREE_TYPE (decl));
+  for (tree probe = TYPE_ARG_TYPES (TREE_TYPE (decl));
probe;
probe = TREE_CHAIN (probe))
 if (TREE_PURPOSE (probe))
diff --git a/gcc/testsuite/g++.dg/concepts/abbrev10.C 
b/gcc/testsuite/g++.dg/concepts/abbrev10.C
new file mode 100644
index 000..b611346e926
--- /dev/null
+++ b/gcc/testsuite/g++.dg/concepts/abbrev10.C
@@ -0,0 +1,18 @@
+// PR c++/99806
+// { dg-do compile { target c++14 } }
+// { dg-additional-options "-fconcepts" }
+
+struct S {
+  void f(auto, auto, int = 3);
+  void f2(auto, auto, int = 3) { }
+  template static T g(T, auto, int = 3);
+};
+
+void
+g ()
+{
+  S::g(1, 2);
+  S s;
+  s.f(1, 2);
+  s.f2(1, 2);
+}
diff --git a/gcc/testsuite/g++.dg/concepts/abbrev11.C 
b/gcc/testsuite/g++.dg/concepts/abbrev11.C
new file mode 100644
index 000..ddb479313df
--- /dev/null
+++ b/gcc/testsuite/g++.dg/concepts/abbrev11.C
@@ -0,0 +1,10 @@
+// PR c++/99806
+// { dg-do compile { target c++14 } }
+// { dg-additional-options "-fconcepts" }
+
+template  concept C = requires (T a) { a.f(0); };
+struct S {
+  void f(auto) noexcept(B);
+  static constexpr bool B = true;
+};
+static_assert(C, "");

base-commit: 123b3e03c911a43054c1f88f5d3110e1d084dd4e
-- 
2.30.2

[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.)

Re: GCC association with the FSF

[Mark Wielaard]

Hi David,

On Wed, Apr 07, 2021 at 10:04:21AM -0400, David Malcolm wrote:
> On Wed, 2021-04-07 at 00:22 +0200, Mark Wielaard wrote:
> > I admit it isn't looking very good and their last announcement is
> > certainly odd: https://status.fsf.org/notice/3833062
> > 
> > But apparently the board is still meeting this week to discuss and
> > might provide a better statement about the way out of this. So lets
> > give them a couple more days before writing them off completely.
> > 
> > > Is there any incident where FSF being the copyright holder for GCC
> > > has
> > > made a difference?
> > 
> > Yes, at least in my experience it has been helpful that the FSF held
> > copyright of code that had been assigned by various individuals and
> > companies. It allowed the merger of GNU Classpath and libgcj for
> > example. There have been various intances where it was helpful that
> > the FSF could unilatrally adjust the license terms especially when
> > the
> > original contributor couldn't be found or didn't exist (as company)
> > anymore.
> 
> This benefit arises from having a single entity own the copyright in
> the code.  It doesn't necessarily have to be the FSF to gain this
> benefit; it just happens that the FSF currently owns the copyright on
> the code.

Yes, I admit that it doesn't have to be the FSF specifically. But
having a shared copyright pool held by one legal entity has benefits.

> Another, transitional approach might be to find another Free Software
> non-profit and for contributors to start assigning copyright on ongoing
> work to that other non-profit.  That way there would be only two
> copyright holders on the code; if the FSF somehow survives its current
> death-spiral then the other nonprofit could assign copyright back to
> the FSF;  if it doesn't, well, we've already got bigger problems.

Yes, having all new copyrights pooled together so we have just two
copyright holders would provide most of the same benefits. And makes
it easier to deal with the legacy FSF copyrights since there would be
just one legal entity having to deal with them instead of each
individual copyright holder on their own.

If it has to come to this then we could take a look at what the
Conservancy already does for aggregating copyright for their member
projects, the Linux kernel and Debian project:
https://sfconservancy.org/copyleft-compliance/

I like their idea of having a counsel of developers that gets involved
in any action taken on behave of the collective:
https://sfconservancy.org/docs/blank_linux-enforcement-agreement.pdf

> > And it is really helpful that we don't have to ask permission of
> > every
> > individual contributor to be able to create the GCC manual (because
> > the GPL code and GFDL text could otherwise not be combined) but that
> > the FSF can grant an exception to one of the developers to create it.
> 
> Alternatively, the copyright holder could relicense the documentation
> to a license that is explicitly compatible with the GPL, such as the
> GPL itself, and not require us to jump through hoops.  (Or we could
> start a non-GFDL body of documentation under a different copyright
> holder, but I'm not volunteering for that effort).  In case it's not
> clear, I think the GFDL is a terrible license, and that it's always a
> mistake to use it for software documentation.

Yes, I am not clear on why this (relicensing the documentation under
the GPL) hasn't been done yet. Is this something the Steering
Committee could start a discussion on with the FSF?

> > > Are there any GPL violations involving GCC code
> > > that were resolved only because all copyright resides with a single
> > > entity, that couldn't have been resolved on behalf of individual
> > > copyright holders?
> > 
> > I think it has been very helpful preventing those violations. If you
> > only have individual copyright holders instead of an organisation
> > with
> > the means to actually resolve such violations people pay much more
> > attention to play by the rules. See for example the linux kernel
> > project. I believe there are so many GPL violations precisely because
> > almost no individual has the means to take up a case.
> 
> Again, the "single entity" doesn't need to be the FSF.

It doesn't, but it would be convenient if it was possible.  We have to
see what the board does to win the confidence of use GNU hackers back.
They still have to answer the questions we sent them about the GNU/FSF
relationship:
https://gnu.wildebeest.org/blog/mjw/2019/12/27/proposals-for-the-new-gnu-fsf-relationship/
Maybe if the whole board is replaced we can finally have that conversation.

> It's not clear to me to what extent "GNU" is a thing that exists.  I
> agree with much of Andy Wingo's October 2019 blog post:
> http://www.wingolog.org/archives/2019/10/08/thoughts-on-rms-and-gnu
> 
> IMHO, "GNU" can mean various things:
> - the small family of "g"-prefixed toolchain/low-level projects (gcc,
> glibc, gdb) that work together and attend the GNU 

Re: GCC association with the FSF

[Gabriel Ravier via Gcc]

On 4/8/21 6:43 PM, Christopher Dimech via Gcc wrote:

Sent: Friday, April 09, 2021 at 3:00 AM
From: "David Brown" 
To: "Jonathan Wakely" , "David Malcolm" 

Cc: "GCC Development" , "Mark Wielaard" 
Subject: Re: GCC association with the FSF

On 07/04/2021 19:17, Jonathan Wakely via Gcc wrote:

On Wed, 7 Apr 2021 at 15:04, David Malcolm wrote:

For myself, I'm interested in copyleft low-level tools being used to
build a Free Software operating system, but the "GNU" name may be
permanently tarnished for me; I have no wish to be associated with a
self-appointed "chief GNUisance".  I hope the FSF can be saved, since
it would be extremely inconvenient to have to move.

This matches my feelings. If the FSF can be saved, fine, but I don't
think GCC needs to remain associated with it.

If the GNU name is a problem, rename the projects to be simply "GCC",
"Glibc", "GDB" etc without being an initialism.


It should remain an acronym, but it should now stand for "GCC Compiler
Collection".  That allows the project to be disassociated from the GNU
name while still subtly acknowledging its heritage.

I am a gcc user, but not a developer or contributor.  I think it is
important to appreciate the good RMS has done for the software world,
and to accept history as it has happened rather than how we wish it had
been.  But going forward I don't think any project or organisation has
anything to gain by association with RMS, but will have much to lose.
To a large extent, he has done his job - the free and open source worlds
are now far too big and well-established to fail easily.  The time for
fanaticism, ideology and childish (ref. "Chief GNUisance") and
anti-social leadership is over - pragmatism, practicality and
cooperation are the way of the future.  It is time for the FSF to say to
RMS, "Thank you for all you have done.  Now move over for the next
generation, have a happy retirement, and please don't spoil the future
for the rest of us".  (We still need a few ideologists involved, to
remind us of important principles if anyone strays too far.  It's like a
healthy democratic parliament requiring a few representatives from the
greens, communists and other niche parties - you just don't want them
running the show.)

For me as a person, I cannot condone certain aspects of RMS' behaviour.
  I strongly disapprove of "proof by accusation and rumour" or "trial by
public opinion", but there is enough documented evidence in his own
publications and clearly established personal accounts that no one can
be in doubt that his attitudes and behaviour are not acceptable by
modern standards and are discouraging to developers and users in the
FOSS community.  (And yes, I mean FOSS here, not just free software.)

 From a practical viewpoint, I am concerned that opinions about him will
spread.  If the gcc project is not disassociated from anything involving
RMS, I fear the project will suffer from that assosiation, no matter how
unfair it may be.  At some point, someone in the public relations
department at IBM, Google, Facebook, ARM, or other big supporters of the
project will get the impression that the FSF and GNU are lead by a
misogynist who thinks child abuse is fine if the child consents, and
will cut off all support from the top down.  The other companies will
immediately follow.  The gcc lead developers like Ian, Jonathan, Joseph
and Nathan will be given the choice of leaving gcc or leaving the job
that puts food on their tables.  gcc is not a hobby project run by
amateurs in their free time - it is a serious project that needs
commercial backing as well as the massive personal dedication it receives.

If RMS in not indispensable, Ian, Jonathan, Joseph and Nathan are likewise
not indispensable.  Someone could that over and make their own project and
lead it how they wish.  There are many projects where the original author
knows best where to lead.  Classic examples include medical project Gnu
Health and my project.  Although can also mess a project up, mistakes are
allowed.  Einstein did not get his ideas from committees, neither did Stallman.
At work, I have never encountered any committee that done me any good.


RMS is not indispensible because he does not contribute to GCC and 
doesn't bring much to it, and otherwise takes more away from it. If you 
were to remove all of Ian, Jonathan, Joseph and Nathan you would be 
removing ~13% of active contribution to GCC (counting in commits). If 
you also remove all the major contributors that are from corporations 
(counting a major contributor as someone with 10 or more commits), 
you're removing ~63% of active contribution. If you also remove the 
major organizations contributing to GCC, like Adacore and the GDC 
project, you're removing ~18% more of active contribution, meaning 
you're left with 19% of active contribution. While I do not doubt that 
all of the contributors that would remain are talented individuals, GCC 
would undoubtedly, in the best case, heavily suffer from the 

[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.

Re: GCC association with the FSF

[Christopher Dimech via Gcc]

> Sent: Friday, April 09, 2021 at 6:21 AM
> From: "John Darrington" 
> To: "David Malcolm" 
> Cc: g...@gnu.org, "Alfred M. Szmidt" , "Mark Wielaard" 
> 
> Subject: Re: GCC association with the FSF
>
> On Thu, Apr 08, 2021 at 10:54:25AM -0400, David Malcolm wrote:
>
>  I think it's important to distinguish between the figurative and
>  literal here.
>
>  No one is literally calling for anyone's head.
>
>
> Nobody has explicitly done so.  However in the last 2 or 3 years there
> has been a growing campaign of hatred.  The people feeding that
> campaign are unhappy with things that RMS and others have said.
> However they have taken it further than that.  These people seek
> eliminate *anyone* who holds certain opinions - they don't care how
> they get eliminated - so long as they go.  What's more, they cite
> numerous putative moralistic justifications to give an air of
> legitmacy to that hatred.
>
> Once such hatefulness becomes accepted, people DON'T any longer make that
> literal--figurative distinction.
>
>  Some of us don't want RMS in a leadership position in a project we're
>  associated with (be it the FSF or GNU, and thus, GCC).
>
> RMS was the first person to be involved in GNU and GCC.  Others became
> involved later (under his leadership).  Their contribution was and
> continues to be welcome.  They are also free to stop contributing any
> time they wish to do so.
>
>
>  My opinions, not my employer's, as usual.
>
> Then why do you write this from your employer's email?  That is like
> writing it on the company letterhead.  I suggest that when speaking
> for yourself you use your own email.

Fair points John.

> J'
>

[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.

Re: GCC association with the FSF

[David Brown]

On 08/04/2021 18:43, Christopher Dimech wrote:
> 
>> Sent: Friday, April 09, 2021 at 3:00 AM
>> From: "David Brown" 
>> To: "Jonathan Wakely" , "David Malcolm" 
>> 
>> Cc: "GCC Development" , "Mark Wielaard" 
>> Subject: Re: GCC association with the FSF
>>

>> From a practical viewpoint, I am concerned that opinions about him will
>> spread.  If the gcc project is not disassociated from anything involving
>> RMS, I fear the project will suffer from that assosiation, no matter how
>> unfair it may be.  At some point, someone in the public relations
>> department at IBM, Google, Facebook, ARM, or other big supporters of the
>> project will get the impression that the FSF and GNU are lead by a
>> misogynist who thinks child abuse is fine if the child consents, and
>> will cut off all support from the top down.  The other companies will
>> immediately follow.  The gcc lead developers like Ian, Jonathan, Joseph
>> and Nathan will be given the choice of leaving gcc or leaving the job
>> that puts food on their tables.  gcc is not a hobby project run by
>> amateurs in their free time - it is a serious project that needs
>> commercial backing as well as the massive personal dedication it receives.
> 
> If RMS in not indispensable, Ian, Jonathan, Joseph and Nathan are likewise
> not indispensable.  Someone could that over and make their own project and
> lead it how they wish.  There are many projects where the original author
> knows best where to lead.  Classic examples include medical project Gnu
> Health and my project.  Although can also mess a project up, mistakes are
> allowed.  Einstein did not get his ideas from committees, neither did 
> Stallman.
> At work, I have never encountered any committee that done me any good.
> 

RMS was key to getting GNU and the whole concept of Free Software off
the ground.  He was key to the initial development of several important
pieces of software.  He is no longer key to the development of any
software in a technical sense, nor is he key to the philosophical or
ideological parts of the process.

I don't think that any of Ian, Jonathan, and the others are
indispensable.  But I think all of them together are.  If any one or two
of the key gcc developers left the project, life would go on.  If my
feared scenario occurred and many or all of the current gcc developers
who are employed by major IT and hardware companies had to leave, the
project would be dead.

> A good book to read is Maskell's "The New Idea of a University".
> If some think serious maintainers care about some public relations
> group at IBM, Google, or Facebook, they are highly mistaken.  I
> don't care.

As I said, I am a user.  I don't speak for the main developers of gcc,
or the maintainers of subprojects.  I expect that they do care about the
attitudes of the companies that employ them, at the very least.

> 
> Stallman can think whatever he likes.  There exist many valid opinions
> on questions like exactly how young people can be to get married or be
> depicted in pornography.  New Hampshire law allows 13 year olds to get
> married.  The only problem is that many western people are too far
> freaked out in relation to children, sex, and colonial guilt.
> 

Stallman can indeed think whatever he likes, in that no one else can
decide his opinions for him.  He cannot /do/ whatever he likes - I
believe (but do not claim to be able to prove) that some of his past
actions would fall foul of laws against sexual harassment.

However, those of us who think differently on such matters - and that
is, I think, the solid majority of people (not just westerns) - will not
want anything to do with a person who holds such opinions and encourages
such attitudes.

Re: GCC association with the FSF

[Thomas Rodgers]

On 2021-04-08 10:22, Giacomo Tesio wrote:


No, David,

On April 8, 2021 3:00:57 PM UTC, David Brown  
wrote:



(And yes, I mean FOSS here, not just free software.)


you are not talking about Free Software, but Open Source.

FOSS, as a term, has been very successful to spread confusion.


his attitudes and behaviour are not acceptable by
modern standards and are discouraging to developers and users in the
FOSS community.


In fact, I'm actively looking for alternatives to GCC (and LLVM) 
because I cannot trust a

GCC anymore and I cannot review each and every change.

I won't contribute my port and in general will suggest people to look 
for alternatives.




I've had some luck with the compiler offerings from Intel and Microsoft 
and I understand IBM has a compiler, and of course there's Nvidia's 
offerings (formerly PGI).


But that's not a problem for you, because you do not actually care 
about real developers
and users, just about the US corporations you effectively mentioned and 
now control

several GNU projects:


someone in the public relations
department at IBM, Google, Facebook, ARM, or other big supporters of
the project will get the impression ...


As you explained, GCC itself is completelly  controlled by few US 
corporations with

strong and long term ties with the US DoD.

For sure, it's a big software. And a big threat to everybody outside 
the US.


Thanks for coming out.

Giacomo

Re: GCC association with the FSF

[John Darrington]

On Thu, Apr 08, 2021 at 10:54:25AM -0400, David Malcolm wrote:
 
 I think it's important to distinguish between the figurative and
 literal here.
 
 No one is literally calling for anyone's head.


Nobody has explicitly done so.  However in the last 2 or 3 years there
has been a growing campaign of hatred.  The people feeding that
campaign are unhappy with things that RMS and others have said.
However they have taken it further than that.  These people seek
eliminate *anyone* who holds certain opinions - they don't care how
they get eliminated - so long as they go.  What's more, they cite
numerous putative moralistic justifications to give an air of
legitmacy to that hatred.  

Once such hatefulness becomes accepted, people DON'T any longer make that
literal--figurative distinction.
 
 Some of us don't want RMS in a leadership position in a project we're
 associated with (be it the FSF or GNU, and thus, GCC).

RMS was the first person to be involved in GNU and GCC.  Others became
involved later (under his leadership).  Their contribution was and
continues to be welcome.  They are also free to stop contributing any
time they wish to do so.

 
 My opinions, not my employer's, as usual.

Then why do you write this from your employer's email?  That is like
writing it on the company letterhead.  I suggest that when speaking
for yourself you use your own email.

J'

[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;
  |^~~~

Re: GCC association with the FSF

[Giacomo Tesio]

No, David, 

On April 8, 2021 3:00:57 PM UTC, David Brown  wrote:

>  (And yes, I mean FOSS here, not just free software.)

you are not talking about Free Software, but Open Source.

FOSS, as a term, has been very successful to spread confusion.


> his attitudes and behaviour are not acceptable by
> modern standards and are discouraging to developers and users in the
> FOSS community.

In fact, I'm actively looking for alternatives to GCC (and LLVM) because I 
cannot trust a 
GCC anymore and I cannot review each and every change.

I won't contribute my port and in general will suggest people to look for 
alternatives.


But that's not a problem for you, because you do not actually care about real 
developers 
and users, just about the US corporations you effectively mentioned and now 
control 
several GNU projects:

> someone in the public relations
> department at IBM, Google, Facebook, ARM, or other big supporters of
> the project will get the impression ...

As you explained, GCC itself is completelly  controlled by few US corporations 
with 
strong and long term ties with the US DoD.

For sure, it's a big software. And a big threat to everybody outside the US.


Thanks for coming out.


Giacomo

[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.

[committed] c-family: Fix various comment typos in c-warn.c

[Jakub Jelinek via Gcc-patches]

Hi!

When looking into PR99420, I have noticed several comment typos.

Fixed thusly, committed to trunk as obvious.

2021-04-08  Jakub Jelinek  

* c-warn.c (do_warn_double_promotion): Fix comment typo,
occured -> occurred.
(check_alignment_of_packed_member): Fix a comment typo,
memeber -> member.
(warn_parm_ptrarray_mismatch): Fix comment typos, os -> of
and onless -> unless.
(warn_parm_array_mismatch): Fix comment typos, declaratation
-> declaration and woud -> would.  Fix up comment indentation.

--- gcc/c-family/c-warn.c.jj2021-03-25 13:41:55.601948169 +0100
+++ gcc/c-family/c-warn.c   2021-04-08 18:43:29.020958538 +0200
@@ -2394,7 +2394,7 @@ do_warn_double_promotion (tree result_ty
  warn about it.  */
   if (c_inhibit_evaluation_warnings)
 return;
-  /* If an invalid conversion has occured, don't warn.  */
+  /* If an invalid conversion has occurred, don't warn.  */
   if (result_type == error_mark_node)
 return;
   if (TYPE_MAIN_VARIANT (result_type) != double_type_node
@@ -2900,7 +2900,7 @@ warn_for_multistatement_macros (location
"this %qs clause", guard_tinfo_to_string (keyword));
 }
 
-/* Return struct or union type if the alignment of data memeber, FIELD,
+/* Return struct or union type if the alignment of data member, FIELD,
is less than the alignment of TYPE.  Otherwise, return NULL_TREE.
If RVALUE is true, only arrays evaluate to pointers.  */
 
@@ -3151,7 +3151,7 @@ vla_bound_parm_decl (tree expr)
 }
 
 /* Diagnose mismatches in VLA bounds between function parameters NEWPARMS
-   of pointer types on a redeclaration os a function previously declared
+   of pointer types on a redeclaration of a function previously declared
with CURPARMS at ORIGLOC.  */
 
 static void
@@ -3220,7 +3220,7 @@ warn_parm_ptrarray_mismatch (location_t
   if (origloc == UNKNOWN_LOCATION)
origloc = newloc;
 
-  /* Issue -Warray-parameter onless one or more mismatches involves
+  /* Issue -Warray-parameter unless one or more mismatches involves
 a VLA bound; then issue -Wvla-parameter.  */
   int opt = OPT_Warray_parameter_;
   /* Traverse the two array types looking for variable bounds and
@@ -3335,15 +3335,15 @@ expr_to_str (pretty_printer , tree ex
 
 /* Detect and diagnose a mismatch between an attribute access specification
on the original declaration of FNDECL and that on the parameters NEWPARMS
-   from its refeclaration.  ORIGLOC is the location of the first declaration
+   from its redeclaration.  ORIGLOC is the location of the first declaration
(FNDECL's is set to the location of the redeclaration).  */
 
 void
 warn_parm_array_mismatch (location_t origloc, tree fndecl, tree newparms)
 {
-/* The original parameter list (copied from the original declaration
-   into the current [re]declaration, FNDECL)).  The two are equal if
-   and only if FNDECL is the first declaratation.  */
+  /* The original parameter list (copied from the original declaration
+ into the current [re]declaration, FNDECL)).  The two are equal if
+ and only if FNDECL is the first declaration.  */
   tree curparms = DECL_ARGUMENTS (fndecl);
   if (!curparms || !newparms || curparms == newparms)
 return;
@@ -3375,7 +3375,7 @@ warn_parm_array_mismatch (location_t ori
   return;
 }
   /* ...otherwise, if at least one spec isn't empty there may be mismatches,
- such as  between f(T*) and f(T[1]), where the former mapping woud be
+ such as between f(T*) and f(T[1]), where the former mapping would be
  empty.  */
 
   /* Create an empty access specification and use it for pointers with

Jakub

[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.

[committed] libstdc++: Simplify noexcept-specifiers for move constructors

[Jonathan Wakely via Gcc-patches]

This puts the logic for the noexcept-specifier in one place, and then
reuses it elsewhere. This means checking whether the move constructor
can throw doesn't need to do overload resolution and then check whether
some other constructor can throw, we just get the answer directly.

libstdc++-v3/ChangeLog:

* include/bits/hashtable.h (_Hashtable::_S_nothrow_move()):
New function to determine noexcept-specifier for move
constructors.
(_Hashtable): Use _S_nothrow_move() on move constructors.
* testsuite/23_containers/unordered_map/cons/noexcept_move_construct.cc:
Correct static assertion message.
* 
testsuite/23_containers/unordered_multimap/cons/noexcept_move_construct.cc:
Likewise.
* 
testsuite/23_containers/unordered_multiset/cons/noexcept_move_construct.cc:
Likewise.
* testsuite/23_containers/unordered_set/cons/noexcept_move_construct.cc:
Likewise.

Tested powerpc64le-linux. Committed to trunk.

commit 1cbba49e3417d9b0661e70301d6fb7a7f52fd360
Author: Jonathan Wakely 
Date:   Thu Apr 8 16:29:11 2021

libstdc++: Simplify noexcept-specifiers for move constructors

This puts the logic for the noexcept-specifier in one place, and then
reuses it elsewhere. This means checking whether the move constructor
can throw doesn't need to do overload resolution and then check whether
some other constructor can throw, we just get the answer directly.

libstdc++-v3/ChangeLog:

* include/bits/hashtable.h (_Hashtable::_S_nothrow_move()):
New function to determine noexcept-specifier for move
constructors.
(_Hashtable): Use _S_nothrow_move() on move constructors.
* 
testsuite/23_containers/unordered_map/cons/noexcept_move_construct.cc:
Correct static assertion message.
* 
testsuite/23_containers/unordered_multimap/cons/noexcept_move_construct.cc:
Likewise.
* 
testsuite/23_containers/unordered_multiset/cons/noexcept_move_construct.cc:
Likewise.
* 
testsuite/23_containers/unordered_set/cons/noexcept_move_construct.cc:
Likewise.

diff --git a/libstdc++-v3/include/bits/hashtable.h 
b/libstdc++-v3/include/bits/hashtable.h
index fa80675ad91..39872ce5342 100644
--- a/libstdc++-v3/include/bits/hashtable.h
+++ b/libstdc++-v3/include/bits/hashtable.h
@@ -472,10 +472,19 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
__hashtable_alloc(__node_alloc_type(__a))
   { }
 
+  template
+   static constexpr bool
+   _S_nothrow_move()
+   {
+ if _GLIBCXX17_CONSTEXPR (_No_realloc)
+   if _GLIBCXX17_CONSTEXPR (is_nothrow_copy_constructible<_Hash>())
+ return is_nothrow_copy_constructible<_Equal>();
+ return false;
+   }
+
   _Hashtable(_Hashtable&& __ht, __node_alloc_type&& __a,
 true_type /* alloc always equal */)
-   noexcept(std::is_nothrow_copy_constructible<_Hash>::value &&
-std::is_nothrow_copy_constructible<_Equal>::value);
+   noexcept(_S_nothrow_move());
 
   _Hashtable(_Hashtable&&, __node_alloc_type&&,
 false_type /* alloc always equal */);
@@ -508,19 +517,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   // Use delegating constructors.
   _Hashtable(_Hashtable&& __ht)
-   noexcept( noexcept(
- _Hashtable(std::declval<_Hashtable>(),
-std::declval<__node_alloc_type>(),
-true_type{})) )
+   noexcept(_S_nothrow_move())
   : _Hashtable(std::move(__ht), std::move(__ht._M_node_allocator()),
   true_type{})
   { }
 
   _Hashtable(_Hashtable&& __ht, const allocator_type& __a)
-   noexcept( noexcept(
- _Hashtable(std::declval<_Hashtable>(),
-std::declval<__node_alloc_type>(),
-typename __node_alloc_traits::is_always_equal{})) )
+   noexcept(_S_nothrow_move<__node_alloc_traits::_S_always_equal()>())
   : _Hashtable(std::move(__ht), __node_alloc_type(__a),
   typename __node_alloc_traits::is_always_equal{})
   { }
@@ -1400,8 +1403,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   _Hash, _RangeHash, _Unused, _RehashPolicy, _Traits>::
 _Hashtable(_Hashtable&& __ht, __node_alloc_type&& __a,
   true_type /* alloc always equal */)
-noexcept(std::is_nothrow_copy_constructible<_Hash>::value &&
-std::is_nothrow_copy_constructible<_Equal>::value)
+noexcept(_S_nothrow_move())
 : __hashtable_base(__ht),
   __map_base(__ht),
   __rehash_base(__ht),
diff --git 
a/libstdc++-v3/testsuite/23_containers/unordered_map/cons/noexcept_move_construct.cc
 
b/libstdc++-v3/testsuite/23_containers/unordered_map/cons/noexcept_move_construct.cc
index 96245aa4c88..015646adf23 100644
--- 
a/libstdc++-v3/testsuite/23_containers/unordered_map/cons/noexcept_move_construct.cc
+++ 

[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.

Re: Default debug format for AVR

[David Edelsohn via Gcc]

On Thu, Apr 8, 2021 at 12:09 PM David Edelsohn  wrote:
>
> On Thu, Apr 8, 2021 at 10:41 AM Jeff Law  wrote:
> >
> > On 4/8/2021 8:06 AM, Simon Marchi via Gcc wrote:
> > > On 2021-04-08 9:11 a.m., David Edelsohn wrote:
> >  AIX continues to use and support STABS, although it is transitioning
> >  to DWARF.  If this is intended as a general statement about removal of
> >  STABS support in GCC,
> > >>> Yes, it is.
> > >>>
> > >>> Richard.
> > >> Richard,
> > >>
> > >> It is inappropriate to unilaterally make this decision without
> > >> discussion with all affected ports and maintainers, without warning,
> > >> and without deprecation.  I request that you rescind this decision.
> > >>
> > >> It is somewhat ironic to act as a dictator when we are having a
> > >> discussion about dictatorial behavior in GCC leadership.
> > > I don't really want to start such a debate about GCC politics.  If stabs
> > > is not ready to be deleted, that's fine.  But it would be good to go
> > > through all targets for which it is the default (like avr), and see if
> > > they are ready to be switched to DWARF.  That's a baby step towards
> > > eventually deleting it.
> >
> > Agreed.  I'd bet AIX is the outlier here and that most, if not all,
> > other ports that may currently be stabs-by-default can switch to
> > dwarf-by-default with no significant fallout.  So we fix everything we
> > can while we wait for AIX to move forward.
>
> I am not requesting a continuation of support for STABS to be
> obstinate.  AIX has some support for DWARF, but STABS continues to be
> the primary debug format on AIX.  Binutils does not fully function on
> AIX and the AIX native tools support for DWARF is incomplete.  Also,
> AIX uses XCOFF file format, not ELF, so DWARF syntax needs to be
> adapted and all of the tools need to agree on the way that AIX symbols
> are represented in DWARF.
>
> IBM is adding support for AIX to LLVM and LLVM does not support STABS
> debugging, which has both exposed problems and is motivating work to
> resolve the gaps, but the additional features and fixes require time
> to implement and deploy.
>
> I am eager to transition to DWARF on AIX, but I continue to ask that
> the support not be removed until DWARF can be used as a complete
> substitute on AIX.  I hope that full support for DWARF in AIX will be
> completed in 2022 and removal of GCC support for STABS can be targeted
> for GCC 13, not GCC 12.
>

I have discussed the STABS debugging situation internally and the AIX
team has accepted that STABS support will be removed in GCC 12.  This
also will mean that I will remove the AIX 6.1 and AIX 7.1
configurations for GCC 12.

If you want to delete all STABS debugging support in Stage 1, go ahead.

Thanks, David

Re: GCC association with the FSF

[Christopher Dimech via Gcc]

> Sent: Friday, April 09, 2021 at 3:00 AM
> From: "David Brown" 
> To: "Jonathan Wakely" , "David Malcolm" 
> 
> Cc: "GCC Development" , "Mark Wielaard" 
> Subject: Re: GCC association with the FSF
>
> On 07/04/2021 19:17, Jonathan Wakely via Gcc wrote:
> > On Wed, 7 Apr 2021 at 15:04, David Malcolm wrote:
> >> For myself, I'm interested in copyleft low-level tools being used to
> >> build a Free Software operating system, but the "GNU" name may be
> >> permanently tarnished for me; I have no wish to be associated with a
> >> self-appointed "chief GNUisance".  I hope the FSF can be saved, since
> >> it would be extremely inconvenient to have to move.
> >
> > This matches my feelings. If the FSF can be saved, fine, but I don't
> > think GCC needs to remain associated with it.
> >
> > If the GNU name is a problem, rename the projects to be simply "GCC",
> > "Glibc", "GDB" etc without being an initialism.
> >
>
> It should remain an acronym, but it should now stand for "GCC Compiler
> Collection".  That allows the project to be disassociated from the GNU
> name while still subtly acknowledging its heritage.
>
> I am a gcc user, but not a developer or contributor.  I think it is
> important to appreciate the good RMS has done for the software world,
> and to accept history as it has happened rather than how we wish it had
> been.  But going forward I don't think any project or organisation has
> anything to gain by association with RMS, but will have much to lose.
> To a large extent, he has done his job - the free and open source worlds
> are now far too big and well-established to fail easily.  The time for
> fanaticism, ideology and childish (ref. "Chief GNUisance") and
> anti-social leadership is over - pragmatism, practicality and
> cooperation are the way of the future.  It is time for the FSF to say to
> RMS, "Thank you for all you have done.  Now move over for the next
> generation, have a happy retirement, and please don't spoil the future
> for the rest of us".  (We still need a few ideologists involved, to
> remind us of important principles if anyone strays too far.  It's like a
> healthy democratic parliament requiring a few representatives from the
> greens, communists and other niche parties - you just don't want them
> running the show.)
>
> For me as a person, I cannot condone certain aspects of RMS' behaviour.
>  I strongly disapprove of "proof by accusation and rumour" or "trial by
> public opinion", but there is enough documented evidence in his own
> publications and clearly established personal accounts that no one can
> be in doubt that his attitudes and behaviour are not acceptable by
> modern standards and are discouraging to developers and users in the
> FOSS community.  (And yes, I mean FOSS here, not just free software.)
>
> From a practical viewpoint, I am concerned that opinions about him will
> spread.  If the gcc project is not disassociated from anything involving
> RMS, I fear the project will suffer from that assosiation, no matter how
> unfair it may be.  At some point, someone in the public relations
> department at IBM, Google, Facebook, ARM, or other big supporters of the
> project will get the impression that the FSF and GNU are lead by a
> misogynist who thinks child abuse is fine if the child consents, and
> will cut off all support from the top down.  The other companies will
> immediately follow.  The gcc lead developers like Ian, Jonathan, Joseph
> and Nathan will be given the choice of leaving gcc or leaving the job
> that puts food on their tables.  gcc is not a hobby project run by
> amateurs in their free time - it is a serious project that needs
> commercial backing as well as the massive personal dedication it receives.

If RMS in not indispensable, Ian, Jonathan, Joseph and Nathan are likewise
not indispensable.  Someone could that over and make their own project and
lead it how they wish.  There are many projects where the original author
knows best where to lead.  Classic examples include medical project Gnu
Health and my project.  Although can also mess a project up, mistakes are
allowed.  Einstein did not get his ideas from committees, neither did Stallman.
At work, I have never encountered any committee that done me any good.

A good book to read is Maskell's "The New Idea of a University".
If some think serious maintainers care about some public relations
group at IBM, Google, or Facebook, they are highly mistaken.  I
don't care.

Stallman can think whatever he likes.  There exist many valid opinions
on questions like exactly how young people can be to get married or be
depicted in pornography.  New Hampshire law allows 13 year olds to get
married.  The only problem is that many western people are too far
freaked out in relation to children, sex, and colonial guilt.

> It is my opinion - entirely personal, and as a long and happy user
> rather than a developer, and not speaking for my company or anyone else
> - that gcc would be a stronger project if 

[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;

}

Re: Default debug format for AVR

[David Edelsohn via Gcc]

On Thu, Apr 8, 2021 at 10:41 AM Jeff Law  wrote:
>
> On 4/8/2021 8:06 AM, Simon Marchi via Gcc wrote:
> > On 2021-04-08 9:11 a.m., David Edelsohn wrote:
>  AIX continues to use and support STABS, although it is transitioning
>  to DWARF.  If this is intended as a general statement about removal of
>  STABS support in GCC,
> >>> Yes, it is.
> >>>
> >>> Richard.
> >> Richard,
> >>
> >> It is inappropriate to unilaterally make this decision without
> >> discussion with all affected ports and maintainers, without warning,
> >> and without deprecation.  I request that you rescind this decision.
> >>
> >> It is somewhat ironic to act as a dictator when we are having a
> >> discussion about dictatorial behavior in GCC leadership.
> > I don't really want to start such a debate about GCC politics.  If stabs
> > is not ready to be deleted, that's fine.  But it would be good to go
> > through all targets for which it is the default (like avr), and see if
> > they are ready to be switched to DWARF.  That's a baby step towards
> > eventually deleting it.
>
> Agreed.  I'd bet AIX is the outlier here and that most, if not all,
> other ports that may currently be stabs-by-default can switch to
> dwarf-by-default with no significant fallout.  So we fix everything we
> can while we wait for AIX to move forward.

I am not requesting a continuation of support for STABS to be
obstinate.  AIX has some support for DWARF, but STABS continues to be
the primary debug format on AIX.  Binutils does not fully function on
AIX and the AIX native tools support for DWARF is incomplete.  Also,
AIX uses XCOFF file format, not ELF, so DWARF syntax needs to be
adapted and all of the tools need to agree on the way that AIX symbols
are represented in DWARF.

IBM is adding support for AIX to LLVM and LLVM does not support STABS
debugging, which has both exposed problems and is motivating work to
resolve the gaps, but the additional features and fixes require time
to implement and deploy.

I am eager to transition to DWARF on AIX, but I continue to ask that
the support not be removed until DWARF can be used as a complete
substitute on AIX.  I hope that full support for DWARF in AIX will be
completed in 2022 and removal of GCC support for STABS can be targeted
for GCC 13, not GCC 12.

Thanks, David

[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.

[pushed] c++: improve reference binding diagnostic [PR91849]

[Jason Merrill via Gcc-patches]

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.

Tested x86_64-pc-linux-gnu, applying to trunk.

gcc/cp/ChangeLog:

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

gcc/testsuite/ChangeLog:

PR c++/91849
* g++.dg/conversion/ref7.C: New test.
---
 gcc/cp/call.c | 15 +--
 gcc/testsuite/g++.dg/conversion/pr66211.C |  2 +-
 gcc/testsuite/g++.dg/conversion/ref7.C| 17 +
 3 files changed, 31 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/conversion/ref7.C

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 4b81d0ff333..c9a8c0d305f 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -7898,8 +7898,19 @@ convert_like_internal (conversion *convs, tree expr, 
tree fn, int argnum,
 "lvalue of type %qI", totype, extype);
else if (!TYPE_REF_IS_RVALUE (ref_type) && !lvalue_p (expr)
 && !CP_TYPE_CONST_NON_VOLATILE_P (TREE_TYPE (ref_type)))
- error_at (loc, "cannot bind non-const lvalue reference of "
-   "type %qH to an rvalue of type %qI", totype, extype);
+ {
+   conversion *next = next_conversion (convs);
+   if (next->kind == ck_std)
+ {
+   next = next_conversion (next);
+   error_at (loc, "cannot bind non-const lvalue reference of "
+ "type %qH to a value of type %qI",
+ totype, next->type);
+ }
+   else
+ error_at (loc, "cannot bind non-const lvalue reference of "
+   "type %qH to an rvalue of type %qI", totype, 
extype);
+ }
else if (!reference_compatible_p (TREE_TYPE (totype), extype))
  {
/* If we're converting from T[] to T[N], don't talk
diff --git a/gcc/testsuite/g++.dg/conversion/pr66211.C 
b/gcc/testsuite/g++.dg/conversion/pr66211.C
index 770e8a0e20f..5c1ae13c76d 100644
--- a/gcc/testsuite/g++.dg/conversion/pr66211.C
+++ b/gcc/testsuite/g++.dg/conversion/pr66211.C
@@ -7,5 +7,5 @@ int main()
 {
   int x = 0;
   double y = 1;
-  f(1 > 0 ? x : y); // { dg-error "cannot bind .* to an rvalue" }
+  f(1 > 0 ? x : y); // { dg-error "cannot bind non-const lvalue reference of 
type .int&. to a value of type .double" }
 }
diff --git a/gcc/testsuite/g++.dg/conversion/ref7.C 
b/gcc/testsuite/g++.dg/conversion/ref7.C
new file mode 100644
index 000..99347cb1c27
--- /dev/null
+++ b/gcc/testsuite/g++.dg/conversion/ref7.C
@@ -0,0 +1,17 @@
+// PR c++/91849
+
+struct A { operator float(); };
+
+void
+g ()
+{
+  float f = 1.f;
+  int  = f;  // { dg-error "float" }
+  int  = A();   // { dg-error "float" }
+}
+
+void
+g2 ()
+{
+  int  = 1.f;// { dg-error "float" }
+}

base-commit: ac24fa46e449fbff0ff571951cfcc78b8488f6e7
-- 
2.27.0

[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)
  |   ~^~

[committed] VAX: Fix comment for `*bit' pattern's peephole

[Maciej W. Rozycki]

The comment for a peephole provided for the `*bit' pattern to be 
produced in comparison elimination from a sequence involving a bitwise 
complement operation of one input operand followed by a bitwise AND 
operation between a bitwise complement of said intermediate result and 
the other input operand (which corresponds to a sequence of MCOM and BIC 
machine instructions) incorrectly refers to the first operation as MNEG 
(which is the machine instruction for arithmetic negation) rather than 
MCOM as it is supposed to.  Fix it.

gcc/
* config/vax/vax.md: Fix comment for `*bit' pattern's 
peephole.
---
Hi,

 Committed as an obvious trivial inline documentation fix.

  Maciej
---
 gcc/config/vax/vax.md |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

gcc-vax-mcom-bic-bit.diff
Index: gcc/gcc/config/vax/vax.md
===
--- gcc.orig/gcc/config/vax/vax.md
+++ gcc/gcc/config/vax/vax.md
@@ -1228,7 +1228,7 @@
 ;; the "*bit" pattern does for the purpose of the compare
 ;; elimination pass.  Try to get rid of the extra operation by hand
 ;; and where the sequence is used to set the condition codes only
-;; convert MNEG/BIC => BIT.
+;; convert MCOM/BIC => BIT.
 (define_peephole2
   [(parallel
  [(set (match_operand:VAXint 0 "register_operand")

[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