[Bug middle-end/104986] [12 Regression] bogus writing 1 byte into a region of size 0 with -fwrapv and -O2 -fpeel-loops since r12-4698-gf6d012338bf87f42

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
The strlen pass itself for its original purpose doesn't use the ranger at all,
it is just the warning code that uses the strlen infrastructure and is invoked
during the pass that does.

[Bug c/100545] ICE with -g: in gen_typedef_die with mode attribute and aligned attribute

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

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

--- Comment #3 from Jason Merrill  ---
Created attachment 52829
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52829=edit
fix

[PATCH] testsuite: Skip target not support -pthread [pr104676].

[jiawei]

The "ftree-parallelize-loops=" imply -pthread option in gcc/gcc.cc,
some target are not support pthread like elf target use newlib,
and will get an error:

"*-*-elf-gcc: error: unrecognized command-line option '-pthread'"

so we add an additional condition "{target pthread}" to make sure the
dg-additional-options runs on support targets.

---
 gcc/testsuite/gcc.dg/torture/pr104676.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/torture/pr104676.c 
b/gcc/testsuite/gcc.dg/torture/pr104676.c
index 50845bb9e15..0991b78f758 100644
--- a/gcc/testsuite/gcc.dg/torture/pr104676.c
+++ b/gcc/testsuite/gcc.dg/torture/pr104676.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-additional-options "-ftree-loop-distribution 
-ftree-parallelize-loops=2" } */
+/* { dg-additional-options "-ftree-loop-distribution 
-ftree-parallelize-loops=2" { target pthread } } */
 
 struct S {
   int f;
-- 
2.25.1

[Bug libquadmath/105101] incorrect rounding for sqrtq

[already5chosen at yahoo dot com via Gcc-bugs]

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

--- Comment #11 from Michael_S  ---
(In reply to Michael_S from comment #10)
> BTW, the same ideas as in the code above could improve speed of division
> operation (on modern 64-bit HW) by factor of 3 (on Intel) or 2 (on AMD).

Did it.
On Intel it's even better than anticipated. 5x speedup on Haswell and Skylake,
4.5x on Ivy Bridge.
Unfortunately, right now I have no connection to my Zen3 test system, so can't
measure on it with final variant. But according to preliminary tests the
speedup should be slightly better than 2x.

[COMMITTED] readings.html: Add replacement URL for CRIS Programmer's Manual

[Hans-Peter Nilsson via Gcc-patches]

Also available through the wayback machine, but only a valid
currently-working URL is appropriate on that page, IMHO.

Thanks to Paul Koning for finding it.
---
 htdocs/readings.html | 1 +
 1 file changed, 1 insertion(+)

diff --git a/htdocs/readings.html b/htdocs/readings.html
index 2467945b1cb6..4269e9f0aa5c 100644
--- a/htdocs/readings.html
+++ b/htdocs/readings.html
@@ -118,6 +118,7 @@ names.
Manufacturer: Axis Communications
Acronym stands for: Code Reduced Instruction Set
The CRIS architecture is used in the ETRAX system-on-a-chip series.
+   https://www.axis.com/files/tech_notes/etrax_100lx_prog_man-050519.pdf;>Programmer's
 Manual for CRIS v10
  
  
  C-SKY
-- 
2.30.2

Re: [PATCH] mksigtab.sh: Add support for musl libc

[Ian Lance Taylor via Gcc-patches]

On Fri, Apr 15, 2022 at 6:38 AM Sören Tempel  wrote:
>
> Attached are two small git-format-patch(1) files which add support for
> musl libc to gofrontend's mksigtab.sh script. They address the following
> issues:
>
> * Signal 34 is special on musl and is used internally for
>   setgid .
> * SIGPOLL uses the same signal number as SIGIO on musl. This
>   causes a build failure as the map keys are not unique then.
>
> Let me know if you need me to provide more information or if the patches
> need to be revised in any way.

Thanks, both committed.

Going forward please use the process at
https://go.dev/doc/gccgo_contribute or also send the patches to
gcc-patches@gcc.gnu.org.  Thanks.

Ian
208b7d85d73cbd166e207f0e062cccbdfbf52bb3
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index bcb526c85b9..eeff61d82f8 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-62fc90f52da2f52cbe3b4f10e560dc6aa59baeb5
+8336fe4a5da68d9188dfbc4fb647ccbbe4d60ba4
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
diff --git a/libgo/go/runtime/signal_gccgo.go b/libgo/go/runtime/signal_gccgo.go
index 2eece687e35..82e6996ab7e 100644
--- a/libgo/go/runtime/signal_gccgo.go
+++ b/libgo/go/runtime/signal_gccgo.go
@@ -106,7 +106,8 @@ func getsig(i uint32) uintptr {
if sigaction(i, nil, ) < 0 {
// On GNU/Linux glibc rejects attempts to call
// sigaction with signal 32 (SIGCANCEL) or 33 (SIGSETXID).
-   if GOOS == "linux" && (i == 32 || i == 33) {
+   // On musl signal 34 (SIGSYNCCALL) also needs to be treated 
accordingly.
+   if GOOS == "linux" && (i == 32 || i == 33 || i == 34) {
return _SIG_DFL
}
throw("sigaction read failure")
diff --git a/libgo/mksigtab.sh b/libgo/mksigtab.sh
index 11e4ec436bd..cdf6fcd823f 100644
--- a/libgo/mksigtab.sh
+++ b/libgo/mksigtab.sh
@@ -95,10 +95,12 @@ checksig _SIGLOST '   {_SigNotify, "SIGLOST: resource lost 
(Sun); server died (G
 
 # Special handling of signals 32 and 33 on GNU/Linux systems,
 # because they are special to glibc.
+# Signal 34 is additionally special to Linux systems with musl.
 if test "${GOOS}" = "linux"; then
-SIGLIST=$SIGLIST"_32__33_"
+SIGLIST=$SIGLIST"_32__33__34_"
 echo ' 32: {_SigSetStack + _SigUnblock, "signal 32"}, /* SIGCANCEL; 
see issue 6997 */'
 echo ' 33: {_SigSetStack + _SigUnblock, "signal 33"}, /* SIGSETXID; 
see issues 3871, 9400, 12498 */'
+echo ' 34: {_SigSetStack + _SigUnblock, "signal 34"}, /* musl 
SIGSYNCCALL; see issue 39343 */'
 fi
 
 if test "${GOOS}" = "aix"; then
ace4928a29b79ac6aa0c84d6fd78f5dce5fa6190
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index eeff61d82f8..2321f67ca5d 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-8336fe4a5da68d9188dfbc4fb647ccbbe4d60ba4
+22b0ccda3aa4d16f770a26a3eb251f8da615c318
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
diff --git a/libgo/mksigtab.sh b/libgo/mksigtab.sh
index cdf6fcd823f..bea8739957e 100644
--- a/libgo/mksigtab.sh
+++ b/libgo/mksigtab.sh
@@ -26,7 +26,6 @@ SIGLIST=""
 # Handle signals valid on all Unix systems.
 
 addsig() {
-echo " $1: $2,"
 # Get the signal number and add it to SIGLIST
 signum=`grep "const $1 = " gen-sysinfo.go | sed -e 's/.* = //'`
 if echo "$signum" | grep '^_SIG[A-Z0-9_]*$' >/dev/null 2>&1; then
@@ -34,7 +33,12 @@ addsig() {
 # This is needed for some MIPS signals defined as aliases of other 
signals
 signum=`grep "const $signum = " gen-sysinfo.go | sed -e 's/.* = //'`
 fi
-SIGLIST=$SIGLIST"_${signum}_"
+# Only add signal if the signal number isn't in the list yet.
+# For example, musl libc uses signal 29 for both SIGIO and SIGPOLL.
+if ! echo "$SIGLIST" | grep "_${signum}_" >/dev/null 2>&1; then
+echo " $1: $2,"
+SIGLIST=$SIGLIST"_${signum}_"
+fi
 }
 
 echo ' 0:  {0, "SIGNONE: no trap"},'

[PATCH v2] c++: Fall through for arrays of T vs T cv [PR104996]

[Ed Catmur]

If two arrays do not have the exact same element type including qualification, 
this could be e.g. f(int (&&)[]) vs. f(int const (&)[]), which can still be 
distinguished by the lvalue-rvalue tiebreaker.

By tightening this branch (in accordance with the letter of the Standard) we 
fall through to the next branch, which tests whether they have different 
element type ignoring qualification and returns 0 in that case; thus we only 
actually fall through in the T[...] vs. T cv[...] case, eventually considering 
the lvalue-rvalue tiebreaker at the end of compare_ics.

Bootstrapped and tested on x86_64-pc-linux-gnu.

Signed-off-by: Ed Catmur 

PR c++/104996

gcc/cp/ChangeLog:

* call.cc (compare_ics): When comparing list-initialization sequences, 
do not return early.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/initlist129.C: New test.
---
 gcc/cp/call.cc   | 7 ++-
 gcc/testsuite/g++.dg/cpp0x/initlist129.C | 6 ++
 2 files changed, 8 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/initlist129.C

diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
index 51d8f6c3fb1..fa18d7f8f9d 100644
--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -11546,12 +11546,9 @@ compare_ics (conversion *ics1, conversion *ics2)
 P0388R4.)  */
   else if (t1->kind == ck_aggr
   && TREE_CODE (t1->type) == ARRAY_TYPE
-  && TREE_CODE (t2->type) == ARRAY_TYPE)
+  && TREE_CODE (t2->type) == ARRAY_TYPE
+  && same_type_p (TREE_TYPE (t1->type), TREE_TYPE (t2->type)))
{
- /* The type of the array elements must be the same.  */
- if (!same_type_p (TREE_TYPE (t1->type), TREE_TYPE (t2->type)))
-   return 0;
-
  tree n1 = nelts_initialized_by_list_init (t1);
  tree n2 = nelts_initialized_by_list_init (t2);
  if (tree_int_cst_lt (n1, n2))
diff --git a/gcc/testsuite/g++.dg/cpp0x/initlist129.C 
b/gcc/testsuite/g++.dg/cpp0x/initlist129.C
new file mode 100644
index 000..4d4faa9e08d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/initlist129.C
@@ -0,0 +1,6 @@
+// PR c++/104996
+// { dg-do compile { target c++11 } }
+
+template char f(int (&&)[size]);
+template int f(int const (&)[size]);
+static_assert(sizeof(f({1, 2, 3})) == 1, "");
-- 
2.30.2

[Bug go/105302] gccgo for Windows using MinGW-w64

[ian at airs dot com via Gcc-bugs]

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

--- Comment #4 from Ian Lance Taylor  ---
> What exactly would be the file(s) being opened in this case?

The file that should be opened is the file internal/cpu.gox in the libgo build
directory.

> When can we expect the libgo cleanup needed for MinGW(-w64) support?

I don't know of anybody who is working on this.

[Bug go/105302] gccgo for Windows using MinGW-w64

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

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

--- Comment #3 from Brecht Sanders  
---
What exactly would be the file(s) being opened in this case?

When can we expect the libgo cleanup needed for MinGW(-w64) support?

[Bug go/105302] gccgo for Windows using MinGW-w64

[ian at airs dot com via Gcc-bugs]

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

--- Comment #2 from Ian Lance Taylor  ---
I have no idea why you would get a "Permission denied" error opening an import
package.

That said I would not expect this to work.  Somebody would have to clean up
libgo to support Windows.

[ping][PATCH 0/8][RFC] Support BTF decl_tag and type_tag annotations

[David Faust via Gcc-patches]

Gentle ping :)

Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-April/592685.html

The series adds support for new attribues btf_type_tag and btf_decl_tag, 
for recording arbitrary string tags in DWARF and BTF debug info. The 
feature is to support kernel use cases.


Thanks,
David

On 4/1/22 12:42, David Faust via Gcc-patches wrote:

Hello,

This patch series is a first attempt at adding support for:

- Two new C-language-level attributes that allow to associate (to "tag")
   particular declarations and types with arbitrary strings. As explained below,
   this is intended to be used to, for example, characterize certain pointer
   types.

- The conveyance of that information in the DWARF output in the form of a new
   DIE: DW_TAG_GNU_annotation.

- The conveyance of that information in the BTF output in the form of two new
   kinds of BTF objects: BTF_KIND_DECL_TAG and BTF_KIND_TYPE_TAG.

All of these facilities are being added to the eBPF ecosystem, and support for
them exists in some form in LLVM. However, as we shall see, we have found some
problems implementing them so some discussion is in order.

Purpose
===

1)  Addition of C-family language constructs (attributes) to specify free-text
 tags on certain language elements, such as struct fields.

 The purpose of these annotations is to provide additional information about
 types, variables, and function paratemeters of interest to the kernel. A
 driving use case is to tag pointer types within the linux kernel and eBPF
 programs with additional semantic information, such as '__user' or '__rcu'.

 For example, consider the linux kernel function do_execve with the
 following declaration:

   static int do_execve(struct filename *filename,
  const char __user *const __user *__argv,
  const char __user *const __user *__envp);

 Here, __user could be defined with these annotations to record semantic
 information about the pointer parameters (e.g., they are user-provided) in
 DWARF and BTF information. Other kernel facilites such as the eBPF verifier
 can read the tags and make use of the information.

2)  Conveying the tags in the generated DWARF debug info.

 The main motivation for emitting the tags in DWARF is that the Linux kernel
 generates its BTF information via pahole, using DWARF as a source:

 ++  BTF  BTF   +--+
 | pahole |---> vmlinux.btf --->| verifier |
 ++ +--+
 ^^
 ||
   DWARF |BTF |
 ||
  vmlinux  +-+
  module1.ko   | BPF program |
  module2.ko   +-+
...

 This is because:

 a)  Unlike GCC, LLVM will only generate BTF for BPF programs.

 b)  GCC can generate BTF for whatever target with -gbtf, but there is no
 support for linking/deduplicating BTF in the linker.

 In the scenario above, the verifier needs access to the pointer tags of
 both the kernel types/declarations (conveyed in the DWARF and translated
 to BTF by pahole) and those of the BPF program (available directly in BTF).

 Another motivation for having the tag information in DWARF, unrelated to
 BPF and BTF, is that the drgn project (another DWARF consumer) also wants
 to benefit from these tags in order to differentiate between different
 kinds of pointers in the kernel.

3)  Conveying the tags in the generated BTF debug info.

 This is easy: the main purpose of having this info in BTF is for the
 compiled eBPF programs. The kernel verifier can then access the tags
 of pointers used by the eBPF programs.


For more information about these tags and the motivation behind them, please
refer to the following linux kernel discussions:

   https://lore.kernel.org/bpf/20210914223004.244411-1-...@fb.com/
   https://lore.kernel.org/bpf/20211012164838.3345699-1-...@fb.com/
   https://lore.kernel.org/bpf/2022012604.1504583-1-...@fb.com/


What is in this patch series


This patch series adds support for these annotations in GCC. The implementation
is largely complete. However, in some cases the produced debug info (both DWARF
and BTF) differs significantly from that produced by LLVM. This issue is
discussed in detail below, along with a few specific questions for both GCC and
LLVM. Any input would be much appreciated.


Implementation Overview
===

To enable these annotations, two new C language attributes are added:
__attribute__((btf_decl_tag("foo")) and __attribute__((btf_type_tag("bar"))).
Both attributes accept a single arbitrary string constant argument, 

[Bug c++/104981] [coroutines] Internal compiler error when promise object's constructor takes a base class of the object parameter

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

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

--- Comment #1 from Iain Sandoe  ---
the coroutines code appears to be passing reasonable input to the CTOR build
call.

coroutines.cc:4922:
r = build_special_member_call (p, complete_ctor_identifier, NULL,
   promise_type, LOOKUP_NORMAL,
   tf_warning_or_error);


I think I will need some help from folks more knowledgeable about the lookup
code.

Re: [PATCH] libstdc++: Micro-optimize __from_chars_pow2_base

[Jonathan Wakely via Gcc-patches]

On Mon, 18 Apr 2022, 15:39 Patrick Palka via Libstdc++, <
libstd...@gcc.gnu.org> wrote:

> At the first iteration of __from_chars_pow2_base's main loop, we need
> to remember the value of the leading significant digit for sake of the
> overflow check at the end of the function (for bases other than 2).
>
> This patch manually unrolls this first iteration so as to not encumber
> the entire loop with logic that only the first iteration needs.  This
> seems to significantly improve performance:
>

Great, I was going to suggest looking into that change.



> Base  Before  After (seconds, lower is better)
>29.36   9.37
>83.66   2.93
>   162.93   1.91
>   322.39   2.24
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
>

OK, thanks!



> libstdc++-v3/ChangeLog:
>
> * include/std/charconv (__from_chars_pow2_base): Manually
> unroll the first iteration of the main loop and simplify
> accordingly.
> ---
>  libstdc++-v3/include/std/charconv | 30 +-
>  1 file changed, 21 insertions(+), 9 deletions(-)
>
> diff --git a/libstdc++-v3/include/std/charconv
> b/libstdc++-v3/include/std/charconv
> index dda4ec87779..cd7f52e2195 100644
> --- a/libstdc++-v3/include/std/charconv
> +++ b/libstdc++-v3/include/std/charconv
> @@ -469,25 +469,37 @@ namespace __detail
>while (__i < __len && __first[__i] == '0')
> ++__i;
>const ptrdiff_t __leading_zeroes = __i;
> +  if (__i >= __len) [[__unlikely__]]
> +   {
> + __first += __i;
> + return true;
> +   }
> +
> +  // Remember the leading significant digit value if necessary.
> +  unsigned char __leading_c;
> +  if (__base != 2)
> +   {
> + __leading_c = __from_chars_alnum_to_val<_DecOnly>(__first[__i]);
> + // __glibcxx_assert(__leading_c != 0);
> + if (__leading_c >= __base) [[__unlikely__]]
> +   {
> + __first += __i;
> + return true;
> +   }
> + __val = __leading_c;
> + ++__i;
> +   }
>
> -  unsigned char __leading_c = 0;
>for (; __i < __len; ++__i)
> {
>   const unsigned char __c =
> __from_chars_alnum_to_val<_DecOnly>(__first[__i]);
>   if (__c >= __base)
> break;
>   __val = (__val << __log2_base) | __c;
> -
> - if (__i == __leading_zeroes)
> -   {
> - // At the first iteration, remember the leading significant
> digit.
> - // __glibcxx_assert(__leading_c == 0 && __c != 0);
> - __leading_c = __c;
> -   }
> }
>__first += __i;
>auto __significant_bits = (__i - __leading_zeroes) * __log2_base;
> -  if (__base != 2 && __leading_c != 0)
> +  if (__base != 2)
> // Compensate for a leading significant digit that didn't use all
> // of its available bits.
> __significant_bits -= __log2_base - __bit_width(__leading_c);
> --
> 2.36.0.rc2.10.g1ac7422e39
>
>

[Bug c++/104981] [coroutines] Internal compiler error when promise object's constructor takes a base class of the object parameter

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

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

Iain Sandoe  changed:

   What|Removed |Added

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

[Bug c++/103963] Coroutine return type needs not be copy- or move-constructible

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

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

Iain Sandoe  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-04-18
 CC||iains at gcc dot gnu.org

[Bug c++/98056] coroutines: ICE tree check: expected record_type or union_type or qual_union_type, have array_type since r11-2183-g0f66b8486cea8668

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

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

Iain Sandoe  changed:

   What|Removed |Added

 CC||me at xecycle dot info

--- Comment #18 from Iain Sandoe  ---
*** Bug 104020 has been marked as a duplicate of this bug. ***

[Bug c++/104020] [coroutines] ICE in co_await function call with initializer_list arguments

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

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #2 from Iain Sandoe  ---
As Avi says, this is a dup of 98056.

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

[Bug c++/105104] [coroutines] ICE during GIMPLE pass: coro-early-expand-ifns

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

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

Iain Sandoe  changed:

   What|Removed |Added

   Last reconfirmed|2022-03-30 00:00:00 |2022-4-18
 CC||iains at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org
 Status|WAITING |NEW
   Keywords||ice-on-valid-code

--- Comment #6 from Iain Sandoe  ---
Initial analysis - perhaps some issue with constexpr processing:

When we have a void await_return() in  the final_awaiter class:

 final.suspend:
 frame_ptr->_Coro_resume_fn = 0B;
 {
 struct final_awaiter Fs [value-expr: frame_ptr->Fs_1_2];

 frame_ptr->_Coro_resume_index = 4;
 _15 = _ptr->_Coro_self_handle;
 D.9844 = std::__n4861::coroutine_handle::operator
std::__n4861::coroutine_handle (_15);
 return_object::promise_type::final_awaiter::await_suspend (D.9844);
 D.9768 = .CO_YIELD (4, 1, , , frame_ptr);
 retval.2 = D.9768;
 switch (retval.2) , case 0: , case 1: >
 :
 .CO_SUSPN ();
 :
 goto resume.4;
 :
 goto destroy.4;
 destroy.4:
 goto coro.delete.promise;
 resume.4:
 return_object::promise_type::final_awaiter::await_resume ();
 }

when the await_resume() function is made to return an int.

 final.suspend:
 frame_ptr->_Coro_resume_fn = 0B;
 {

 destroy.4:
 goto coro.delete.promise;
 resume.4:
 }

So we have a dangling label at the end of that scope (which then gives rise to
the crash).

* If I remove the 'contexpr' from the await_resume() function, then it all
works as expected.

* AFAICT, the content is correct in "expand_one_await_expression()".

* Altering the coroutines code to cast the result of the await_resume() to void
makes no difference.

[Bug c++/105289] [11/12 Regression] ICE on partial specialization

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

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

Patrick Palka  changed:

   What|Removed |Added

  Known to fail||11.2.0, 12.0
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
   Target Milestone|--- |11.4
   Last reconfirmed||2022-04-18
 Ever confirmed|0   |1
Summary|[11 Regression] ICE on  |[11/12 Regression] ICE on
   |partial specialization  |partial specialization
 Status|UNCONFIRMED |ASSIGNED
   Keywords||ice-on-valid-code
 CC||ppalka at gcc dot gnu.org
  Known to work||10.3.0, 9.4.0

--- Comment #1 from Patrick Palka  ---
Confirmed, started with r11-6483-ge2e2f3f2c9400f.

[Bug fortran/103662] [12 Regression] TBAA problem in Fortran FE triggering in gfortran.dg/unlimited_polymorphic_3.f03

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

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

--- Comment #13 from Mikael Morin  ---
(In reply to Mikael Morin from comment #12)
> ... so I must be missing important.

I must be missing *something* important.

Re: [AArch64] PR105162: emit barrier for __sync and __atomic builtins on CPUs without LSE

[Pop, Sebastian via Gcc-patches]

Hi,


Wilco pointed out in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105162#c7? 
that

"Only __sync needs the extra full barrier, but __atomic does not."

The attached patch does that by adding out-of-line functions for 
MEMMODEL_SYNC_*.

Those new functions contain a barrier on the path without LSE instructions.


I tested the patch on aarch64-linux with bootstrap and make check.


Sebastian



From: Pop, Sebastian
Sent: Thursday, April 7, 2022 3:15 PM
To: gcc-patches@gcc.gnu.org
Cc: Kyrylo Tkachov
Subject: [AArch64] PR105162: emit barrier for __sync and __atomic builtins on 
CPUs without LSE


Hi,


With -moutline-atomics gcc stops generating a barrier for __sync builtins: 
https://gcc.gnu.org/PR105162

This is a problem on CPUs without LSE instructions where the ld/st exclusives 
do not guarantee a full barrier.

The attached patch adds the barrier to the outline-atomics functions on the 
path without LSE instructions.

In consequence, under -moutline-atomics __atomic and __sync builtins now behave 
the same with and without LSE instructions.

To complete the change, the second patch makes gcc emit the barrier for 
__atomic builtins as well, i.e., independently of is_mm_sync().


Sebastian
From b45842c209ddcb560d6de477ced444f4d948ea76 Mon Sep 17 00:00:00 2001
From: Sebastian Pop 
Date: Mon, 18 Apr 2022 15:13:20 +
Subject: [PATCH] [AArch64] add barriers to ool __sync builtins

---
 gcc/config/aarch64/aarch64-protos.h   |  2 +-
 gcc/config/aarch64/aarch64.cc | 18 --
 .../gcc.target/aarch64/sync-comp-swap-ool.c   |  6 
 .../gcc.target/aarch64/sync-op-acquire-ool.c  |  6 
 .../gcc.target/aarch64/sync-op-full-ool.c |  9 +
 .../gcc.target/aarch64/target_attr_20.c   |  2 +-
 .../gcc.target/aarch64/target_attr_21.c   |  2 +-
 libgcc/config/aarch64/lse.S   | 33 +--
 libgcc/config/aarch64/t-lse   |  8 ++---
 9 files changed, 74 insertions(+), 12 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/aarch64/sync-comp-swap-ool.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/sync-op-acquire-ool.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/sync-op-full-ool.c

diff --git a/gcc/config/aarch64/aarch64-protos.h b/gcc/config/aarch64/aarch64-protos.h
index 46bade28ed6..0b325e1e32b 100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -1051,7 +1051,7 @@ bool aarch64_high_bits_all_ones_p (HOST_WIDE_INT);
 
 struct atomic_ool_names
 {
-const char *str[5][4];
+const char *str[5][7];
 };
 
 rtx aarch64_atomic_ool_func(machine_mode mode, rtx model_rtx,
diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index 18f80499079..3b02ee379f5 100644
--- a/gcc/config/aarch64/aarch64.cc
+++ b/gcc/config/aarch64/aarch64.cc
@@ -22670,14 +22670,14 @@ aarch64_emit_unlikely_jump (rtx insn)
   add_reg_br_prob_note (jump, profile_probability::very_unlikely ());
 }
 
-/* We store the names of the various atomic helpers in a 5x4 array.
+/* We store the names of the various atomic helpers in a 5x7 array.
Return the libcall function given MODE, MODEL and NAMES.  */
 
 rtx
 aarch64_atomic_ool_func(machine_mode mode, rtx model_rtx,
 			const atomic_ool_names *names)
 {
-  memmodel model = memmodel_base (INTVAL (model_rtx));
+  memmodel model = memmodel_from_int (INTVAL (model_rtx));
   int mode_idx, model_idx;
 
   switch (mode)
@@ -22717,6 +22717,15 @@ aarch64_atomic_ool_func(machine_mode mode, rtx model_rtx,
 case MEMMODEL_SEQ_CST:
   model_idx = 3;
   break;
+case MEMMODEL_SYNC_ACQUIRE:
+  model_idx = 4;
+  break;
+case MEMMODEL_SYNC_RELEASE:
+  model_idx = 5;
+  break;
+case MEMMODEL_SYNC_SEQ_CST:
+  model_idx = 6;
+  break;
 default:
   gcc_unreachable ();
 }
@@ -22729,7 +22738,10 @@ aarch64_atomic_ool_func(machine_mode mode, rtx model_rtx,
   { "__aarch64_" #B #N "_relax", \
 "__aarch64_" #B #N "_acq", \
 "__aarch64_" #B #N "_rel", \
-"__aarch64_" #B #N "_acq_rel" }
+"__aarch64_" #B #N "_acq_rel", \
+"__aarch64_" #B #N "_sync_acq", \
+"__aarch64_" #B #N "_sync_rel", \
+"__aarch64_" #B #N "_sync_seq" }
 
 #define DEF4(B)  DEF0(B, 1), DEF0(B, 2), DEF0(B, 4), DEF0(B, 8), \
 		 { NULL, NULL, NULL, NULL }
diff --git a/gcc/testsuite/gcc.target/aarch64/sync-comp-swap-ool.c b/gcc/testsuite/gcc.target/aarch64/sync-comp-swap-ool.c
new file mode 100644
index 000..cb28db21d17
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/sync-comp-swap-ool.c
@@ -0,0 +1,6 @@
+/* { dg-do compile } */
+/* { dg-options "-march=armv8-a+nolse -O2 -fno-ipa-icf -moutline-atomics" } */
+
+#include "sync-comp-swap.x"
+
+/* { dg-final { scan-assembler-times "bl.*__aarch64_cas4_sync_seq" 1 } } */
diff --git a/gcc/testsuite/gcc.target/aarch64/sync-op-acquire-ool.c 

[Bug fortran/103662] [12 Regression] TBAA problem in Fortran FE triggering in gfortran.dg/unlimited_polymorphic_3.f03

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

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #12 from Mikael Morin  ---
Created attachment 52828
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52828=edit
Fix attempt

I think the attached patch avoids the multiple declarations for __class_STAR_p,
but the testsuite FAIL remains, so I must be missing important.
Is there a -fdump-tree-types or something so that the problem can be seen in
dumps (both for eyeballing and for matching with the testsuite)?

[Bug c++/105293] g++-8/i586: internal compiler error trying to compile with g++ (evtl. related to qt5/moc bug)

[estellnb at elstel dot org via Gcc-bugs]

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

--- Comment #5 from Elmar Stellnberger  ---
Created attachment 52827
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52827=edit
2nd version of patch that should be useable under gcc-8-8.3.0/debian/patches/

  Last time I reported that I could not test the patch posted here because the
result of package creation with dpkg-buildpackage had vanished. Luckily I found
gcc/xg++ and gcc/xgcc which were the required executables that could be
installed into /bin/ and tested whether they compiled the new Firefox.

  g++ with the last patch did not do this. Consequently I have checked out
10.2.2, newer than the last known working good one (10.1.1) from Debian 11 and
analysed all changes along the backtrace again. What I found is condensed in
the patch above:

discover_nonconstant_array_refs ();   -  was moved up in addition to the other
change tested already before

  If the error is evoked by what is called along the backtrace this needs to
resolve it. (I assume now that the Qt5/moc bug is independent and do not use it
as reference for the gcc version to compare against any more). Otherwise, the
error may stem from something done in a previous pass:

during RTL pass: expand

  Unfortunately this time I was not even able to compile gcc/xg++. Makefiles
were garbled, xgcc did not produce a.out (test in Makefile), texinfo files were
invalid and I had to copy them from a fresh root and ultimately xg++ stayed the
same after all. I had rescued the original g++ as /bin/g++ and that one turned
into a link (I know it was a regular file before) although all debian/rules
Makefiles only ship into debian/tmp/usr/... and not /.
  Absolutely no chance to test this second patch! Perhaps someone else can do.

GSoC Proposal

[Abhigyan Kashyap via Gcc]

[PATCH v3 1/2] rs6000: Move g++.dg powerpc PR tests to g++.target

[Paul A. Clarke via Gcc-patches]

Also adjust DejaGnu directives, as specifically requiring "powerpc*-*-*" is no
longer required.

2021-04-18  Paul A. Clarke  

gcc/testsuite
* g++.dg/pr65240.h: Move to g++.target/powerpc.
* g++.dg/pr93974.C: Likewise.
* g++.dg/pr65240-1.C: Move to g++.target/powerpc, adjust dg directives.
* g++.dg/pr65240-2.C: Likewise.
* g++.dg/pr65240-3.C: Likewise.
* g++.dg/pr65240-4.C: Likewise.
* g++.dg/pr65242.C: Likewise.
* g++.dg/pr67211.C: Likewise.
* g++.dg/pr69667.C: Likewise.
* g++.dg/pr71294.C: Likewise.
* g++.dg/pr84264.C: Likewise.
* g++.dg/pr84279.C: Likewise.
* g++.dg/pr85657.C: Likewise.
---
 gcc/testsuite/{g++.dg => g++.target/powerpc}/pr65240-1.C | 5 +++--
 gcc/testsuite/{g++.dg => g++.target/powerpc}/pr65240-2.C | 5 +++--
 gcc/testsuite/{g++.dg => g++.target/powerpc}/pr65240-3.C | 5 +++--
 gcc/testsuite/{g++.dg => g++.target/powerpc}/pr65240-4.C | 5 +++--
 gcc/testsuite/{g++.dg => g++.target/powerpc}/pr65240.h   | 0
 gcc/testsuite/{g++.dg => g++.target/powerpc}/pr65242.C   | 5 +++--
 gcc/testsuite/{g++.dg => g++.target/powerpc}/pr67211.C   | 5 +++--
 gcc/testsuite/{g++.dg => g++.target/powerpc}/pr69667.C   | 5 +++--
 gcc/testsuite/{g++.dg => g++.target/powerpc}/pr71294.C   | 2 +-
 gcc/testsuite/{g++.dg => g++.target/powerpc}/pr84264.C   | 2 +-
 gcc/testsuite/{g++.dg => g++.target/powerpc}/pr84279.C   | 5 +++--
 gcc/testsuite/{g++.dg => g++.target/powerpc}/pr85657.C   | 2 +-
 gcc/testsuite/{g++.dg => g++.target/powerpc}/pr93974.C   | 0
 13 files changed, 27 insertions(+), 19 deletions(-)
 rename gcc/testsuite/{g++.dg => g++.target/powerpc}/pr65240-1.C (68%)
 rename gcc/testsuite/{g++.dg => g++.target/powerpc}/pr65240-2.C (68%)
 rename gcc/testsuite/{g++.dg => g++.target/powerpc}/pr65240-3.C (67%)
 rename gcc/testsuite/{g++.dg => g++.target/powerpc}/pr65240-4.C (65%)
 rename gcc/testsuite/{g++.dg => g++.target/powerpc}/pr65240.h (100%)
 rename gcc/testsuite/{g++.dg => g++.target/powerpc}/pr65242.C (92%)
 rename gcc/testsuite/{g++.dg => g++.target/powerpc}/pr67211.C (90%)
 rename gcc/testsuite/{g++.dg => g++.target/powerpc}/pr69667.C (96%)
 rename gcc/testsuite/{g++.dg => g++.target/powerpc}/pr71294.C (96%)
 rename gcc/testsuite/{g++.dg => g++.target/powerpc}/pr84264.C (79%)
 rename gcc/testsuite/{g++.dg => g++.target/powerpc}/pr84279.C (89%)
 rename gcc/testsuite/{g++.dg => g++.target/powerpc}/pr85657.C (90%)
 rename gcc/testsuite/{g++.dg => g++.target/powerpc}/pr93974.C (100%)

diff --git a/gcc/testsuite/g++.dg/pr65240-1.C 
b/gcc/testsuite/g++.target/powerpc/pr65240-1.C
similarity index 68%
rename from gcc/testsuite/g++.dg/pr65240-1.C
rename to gcc/testsuite/g++.target/powerpc/pr65240-1.C
index ff8910df6a1a..23026673e76b 100644
--- a/gcc/testsuite/g++.dg/pr65240-1.C
+++ b/gcc/testsuite/g++.target/powerpc/pr65240-1.C
@@ -1,5 +1,6 @@
-/* { dg-do compile { target { powerpc*-*-* && lp64 } } } */
-/* { dg-skip-if "" { powerpc*-*-darwin* } } */
+/* { dg-do compile { target lp64 } } */
+/* Never tested on darwin, so skip there.  */
+/* { dg-skip-if "" { *-*-darwin* } } */
 /* { dg-require-effective-target powerpc_p8vector_ok } */
 /* { dg-options "-mdejagnu-cpu=power8 -O3 -ffast-math -mcmodel=small 
-mno-fp-in-toc -Wno-return-type" } */
 
diff --git a/gcc/testsuite/g++.dg/pr65240-2.C 
b/gcc/testsuite/g++.target/powerpc/pr65240-2.C
similarity index 68%
rename from gcc/testsuite/g++.dg/pr65240-2.C
rename to gcc/testsuite/g++.target/powerpc/pr65240-2.C
index bdb7a62d73d2..ddd3b3b75f43 100644
--- a/gcc/testsuite/g++.dg/pr65240-2.C
+++ b/gcc/testsuite/g++.target/powerpc/pr65240-2.C
@@ -1,5 +1,6 @@
-/* { dg-do compile { target { powerpc*-*-* && lp64 } } } */
-/* { dg-skip-if "" { powerpc*-*-darwin* } } */
+/* { dg-do compile { target lp64 } } */
+/* Never tested on darwin, so skip there.  */
+/* { dg-skip-if "" { *-*-darwin* } } */
 /* { dg-require-effective-target powerpc_p8vector_ok } */
 /* { dg-options "-mdejagnu-cpu=power8 -O3 -ffast-math -mcmodel=small 
-mfp-in-toc -Wno-return-type" } */
 
diff --git a/gcc/testsuite/g++.dg/pr65240-3.C 
b/gcc/testsuite/g++.target/powerpc/pr65240-3.C
similarity index 67%
rename from gcc/testsuite/g++.dg/pr65240-3.C
rename to gcc/testsuite/g++.target/powerpc/pr65240-3.C
index f37db9025d12..9e826c46ae7f 100644
--- a/gcc/testsuite/g++.dg/pr65240-3.C
+++ b/gcc/testsuite/g++.target/powerpc/pr65240-3.C
@@ -1,5 +1,6 @@
-/* { dg-do compile { target { powerpc*-*-* && lp64 } } } */
-/* { dg-skip-if "" { powerpc*-*-darwin* } } */
+/* { dg-do compile { target lp64 } } */
+/* Never tested on darwin, so skip there.  */
+/* { dg-skip-if "" { *-*-darwin* } } */
 /* { dg-require-effective-target powerpc_p8vector_ok } */
 /* { dg-options "-mdejagnu-cpu=power8 -O3 -ffast-math -mcmodel=medium 
-Wno-return-type" } */
 
diff --git a/gcc/testsuite/g++.dg/pr65240-4.C 
b/gcc/testsuite/g++.target/powerpc/pr65240-4.C
similarity index 65%
rename from gcc/testsuite/g++.dg/pr65240-4.C
rename to 

[PATCH v3 2/2] rs6000: Remove a few needless 'lp64' contraints.

[Paul A. Clarke via Gcc-patches]

A few tests need not be restricted to 'lp64', so remove the restriction.

A few of those need a simple change to the DejaGnu directives to suppress
'-mcmodel' flags for '-m32'.

2022-04-18  Paul A. Clarke  

gcc/testsuite
* g++.target/powerpc/pr65240-1.C: Adjust DejaGnu directives.
* g++.target/powerpc/pr65240-2.C: Likewise.
* g++.target/powerpc/pr65240-3.C: Likewise.
* g++.target/powerpc/pr65240-4.C: Likewise.
* g++.target/powerpc/pr65242.C: Likewise.
* g++.target/powerpc/pr67211.C: Likewise.
* g++.target/powerpc/pr69667.C: Likewise.
* g++.target/powerpc/pr71294.C: Likewise.
---
 gcc/testsuite/g++.target/powerpc/pr65240-1.C | 4 ++--
 gcc/testsuite/g++.target/powerpc/pr65240-2.C | 4 ++--
 gcc/testsuite/g++.target/powerpc/pr65240-3.C | 4 ++--
 gcc/testsuite/g++.target/powerpc/pr65240-4.C | 2 +-
 gcc/testsuite/g++.target/powerpc/pr65242.C   | 2 +-
 gcc/testsuite/g++.target/powerpc/pr67211.C   | 2 +-
 gcc/testsuite/g++.target/powerpc/pr69667.C   | 2 +-
 gcc/testsuite/g++.target/powerpc/pr71294.C   | 2 +-
 8 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/gcc/testsuite/g++.target/powerpc/pr65240-1.C 
b/gcc/testsuite/g++.target/powerpc/pr65240-1.C
index 23026673e76b..40682d5fe857 100644
--- a/gcc/testsuite/g++.target/powerpc/pr65240-1.C
+++ b/gcc/testsuite/g++.target/powerpc/pr65240-1.C
@@ -1,8 +1,8 @@
-/* { dg-do compile { target lp64 } } */
 /* Never tested on darwin, so skip there.  */
 /* { dg-skip-if "" { *-*-darwin* } } */
 /* { dg-require-effective-target powerpc_p8vector_ok } */
-/* { dg-options "-mdejagnu-cpu=power8 -O3 -ffast-math -mcmodel=small 
-mno-fp-in-toc -Wno-return-type" } */
+/* { dg-options "-mdejagnu-cpu=power8 -O3 -ffast-math -mno-fp-in-toc 
-Wno-return-type" } */
+/* { dg-additional-options "-mcmodel=small" { target lp64 } } */
 
 /* target/65240, compiler got a 'insn does not satisfy its constraints' error. 
 */
 
diff --git a/gcc/testsuite/g++.target/powerpc/pr65240-2.C 
b/gcc/testsuite/g++.target/powerpc/pr65240-2.C
index ddd3b3b75f43..4e4a1c2bb897 100644
--- a/gcc/testsuite/g++.target/powerpc/pr65240-2.C
+++ b/gcc/testsuite/g++.target/powerpc/pr65240-2.C
@@ -1,8 +1,8 @@
-/* { dg-do compile { target lp64 } } */
 /* Never tested on darwin, so skip there.  */
 /* { dg-skip-if "" { *-*-darwin* } } */
 /* { dg-require-effective-target powerpc_p8vector_ok } */
-/* { dg-options "-mdejagnu-cpu=power8 -O3 -ffast-math -mcmodel=small 
-mfp-in-toc -Wno-return-type" } */
+/* { dg-options "-mdejagnu-cpu=power8 -O3 -ffast-math -mfp-in-toc 
-Wno-return-type" } */
+/* { dg-additional-options "-mcmodel=small" { target lp64 } } */
 
 /* target/65240, compiler got a 'insn does not satisfy its constraints' error. 
 */
 
diff --git a/gcc/testsuite/g++.target/powerpc/pr65240-3.C 
b/gcc/testsuite/g++.target/powerpc/pr65240-3.C
index 9e826c46ae7f..6acd278cab50 100644
--- a/gcc/testsuite/g++.target/powerpc/pr65240-3.C
+++ b/gcc/testsuite/g++.target/powerpc/pr65240-3.C
@@ -1,8 +1,8 @@
-/* { dg-do compile { target lp64 } } */
 /* Never tested on darwin, so skip there.  */
 /* { dg-skip-if "" { *-*-darwin* } } */
 /* { dg-require-effective-target powerpc_p8vector_ok } */
-/* { dg-options "-mdejagnu-cpu=power8 -O3 -ffast-math -mcmodel=medium 
-Wno-return-type" } */
+/* { dg-options "-mdejagnu-cpu=power8 -O3 -ffast-math -Wno-return-type" } */
+/* { dg-additional-options "-mcmodel=medium" { target lp64 } } */
 
 /* target/65240, compiler got a 'insn does not satisfy its constraints' error. 
 */
 
diff --git a/gcc/testsuite/g++.target/powerpc/pr65240-4.C 
b/gcc/testsuite/g++.target/powerpc/pr65240-4.C
index 6047f136536e..57f2c769a3f3 100644
--- a/gcc/testsuite/g++.target/powerpc/pr65240-4.C
+++ b/gcc/testsuite/g++.target/powerpc/pr65240-4.C
@@ -1,4 +1,4 @@
-/* { dg-do compile { target lp64 } } */
+/* { dg-do compile } */
 /* Never tested on darwin, so skip there.  */
 /* { dg-skip-if "" { *-*-darwin* } } */
 /* { dg-require-effective-target powerpc_vsx_ok } */
diff --git a/gcc/testsuite/g++.target/powerpc/pr65242.C 
b/gcc/testsuite/g++.target/powerpc/pr65242.C
index 09f5bb35f11d..64ca67e246f8 100644
--- a/gcc/testsuite/g++.target/powerpc/pr65242.C
+++ b/gcc/testsuite/g++.target/powerpc/pr65242.C
@@ -1,4 +1,4 @@
-/* { dg-do compile { target lp64 } } */
+/* { dg-do compile } */
 /* Never tested on darwin, so skip there.  */
 /* { dg-skip-if "" { *-*-darwin* } } */
 /* { dg-require-effective-target powerpc_p8vector_ok } */
diff --git a/gcc/testsuite/g++.target/powerpc/pr67211.C 
b/gcc/testsuite/g++.target/powerpc/pr67211.C
index 5cd00ba98ee4..946802e44cde 100644
--- a/gcc/testsuite/g++.target/powerpc/pr67211.C
+++ b/gcc/testsuite/g++.target/powerpc/pr67211.C
@@ -1,4 +1,4 @@
-/* { dg-do compile { target lp64 } } */
+/* { dg-do compile } */
 /* Never tested on darwin, so skip there.  */
 /* { dg-skip-if "" { *-*-darwin* } } */
 /* { dg-require-effective-target powerpc_p8vector_ok } */
diff --git a/gcc/testsuite/g++.target/powerpc/pr69667.C 

[PATCH v3 0/2] rs6000: Move g++.dg powerpc tests to g++.target

[Paul A. Clarke via Gcc-patches]

v3: moved "not tested on Darwin" changes into 1/2, where they belong.

v2:
- v1 patches 1/3 and 2/3 have been merged after reviews / approval.
- Previous 3/3 is now 1/2, and new 2/2 is per review from Segher...

Some tests in g++.dg are target-specific for powerpc. Move those to
g++.target/powerpc. Update the DejaGnu directives as needed, since
the target restriction is perhaps no longer needed when residing in the
target-specific powerpc subdirectory.

In addition (new patch 2/2), as suggested by Segher, remove 'lp64' restriction
for a handful of tests, protecting uses of '-mcmodel' flag with
dg-additional-options.

Tested on Linux/Power9 (BE) and Linux Power8 (LE 32 and 64), full "make check".

OK for trunk?

Paul A. Clarke (2):
  rs6000: Move g++.dg powerpc PR tests to g++.target
  rs6000: Remove a few needless 'lp64' contraints.

 gcc/testsuite/g++.dg/pr65240-1.C | 8 
 gcc/testsuite/g++.dg/pr65240-2.C | 8 
 gcc/testsuite/g++.dg/pr65240-3.C | 8 
 gcc/testsuite/g++.target/powerpc/pr65240-1.C | 9 +
 gcc/testsuite/g++.target/powerpc/pr65240-2.C | 9 +
 gcc/testsuite/g++.target/powerpc/pr65240-3.C | 9 +
 gcc/testsuite/{g++.dg => g++.target/powerpc}/pr65240-4.C | 5 +++--
 gcc/testsuite/{g++.dg => g++.target/powerpc}/pr65240.h   | 0
 gcc/testsuite/{g++.dg => g++.target/powerpc}/pr65242.C   | 5 +++--
 gcc/testsuite/{g++.dg => g++.target/powerpc}/pr67211.C   | 5 +++--
 gcc/testsuite/{g++.dg => g++.target/powerpc}/pr69667.C   | 5 +++--
 gcc/testsuite/{g++.dg => g++.target/powerpc}/pr71294.C   | 2 +-
 gcc/testsuite/{g++.dg => g++.target/powerpc}/pr84264.C   | 2 +-
 gcc/testsuite/{g++.dg => g++.target/powerpc}/pr84279.C   | 5 +++--
 gcc/testsuite/{g++.dg => g++.target/powerpc}/pr85657.C   | 2 +-
 gcc/testsuite/{g++.dg => g++.target/powerpc}/pr93974.C   | 0
 16 files changed, 45 insertions(+), 37 deletions(-)
 delete mode 100644 gcc/testsuite/g++.dg/pr65240-1.C
 delete mode 100644 gcc/testsuite/g++.dg/pr65240-2.C
 delete mode 100644 gcc/testsuite/g++.dg/pr65240-3.C
 create mode 100644 gcc/testsuite/g++.target/powerpc/pr65240-1.C
 create mode 100644 gcc/testsuite/g++.target/powerpc/pr65240-2.C
 create mode 100644 gcc/testsuite/g++.target/powerpc/pr65240-3.C
 rename gcc/testsuite/{g++.dg => g++.target/powerpc}/pr65240-4.C (68%)
 rename gcc/testsuite/{g++.dg => g++.target/powerpc}/pr65240.h (100%)
 rename gcc/testsuite/{g++.dg => g++.target/powerpc}/pr65242.C (93%)
 rename gcc/testsuite/{g++.dg => g++.target/powerpc}/pr67211.C (91%)
 rename gcc/testsuite/{g++.dg => g++.target/powerpc}/pr69667.C (97%)
 rename gcc/testsuite/{g++.dg => g++.target/powerpc}/pr71294.C (96%)
 rename gcc/testsuite/{g++.dg => g++.target/powerpc}/pr84264.C (79%)
 rename gcc/testsuite/{g++.dg => g++.target/powerpc}/pr84279.C (89%)
 rename gcc/testsuite/{g++.dg => g++.target/powerpc}/pr85657.C (90%)
 rename gcc/testsuite/{g++.dg => g++.target/powerpc}/pr93974.C (100%)

-- 
2.27.0

Re: [PATCH] doc/invoke.texi: CRIS: Remove references to cris-axis-linux-gnu

[Hans-Peter Nilsson via Gcc-patches]

> From: Hans-Peter Nilsson 

> gcc:
>   * doc/install.texi : Remove references to removed websites and
>   adjust for cris-*-elf being the only remaining toolchain.

Oops, cutnpasto for the ChangeLog entry. :(
This one fits better:

* doc/invoke.texi : Remove references to options for removed
subtarget cris-axis-linux-gnu and tweak wording accordingly.

brgds, H-P

[PATCH] doc/invoke.texi: CRIS: Remove references to cris-axis-linux-gnu

[Hans-Peter Nilsson via Gcc-patches]

I'm about to commit this to master.

I'd like to also install this on the gcc-11 branch.

Ok?

-- 8< --

...and related options.  These stale bits were overlooked when support
for "Linux/GNU" and CRIS v32 was removed, before the gcc-11 release.

Resulting pdf, html and info inspected for sanity.

gcc:
* doc/install.texi : Remove references to removed websites and
adjust for cris-*-elf being the only remaining toolchain.
---
 gcc/doc/invoke.texi | 29 +++--
 1 file changed, 7 insertions(+), 22 deletions(-)

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 1a51759e6e45..cee625c92dd6 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -854,12 +854,12 @@ Objective-C and Objective-C++ Dialects}.
 -msim  -msdata=@var{sdata-type}}
 
 @emph{CRIS Options}
-@gccoptlist{-mcpu=@var{cpu}  -march=@var{cpu}  -mtune=@var{cpu} @gol
--mmax-stack-frame=@var{n}  -melinux-stacksize=@var{n} @gol
+@gccoptlist{-mcpu=@var{cpu}  -march=@var{cpu}
+-mtune=@var{cpu} -mmax-stack-frame=@var{n} @gol
 -metrax4  -metrax100  -mpdebug  -mcc-init  -mno-side-effects @gol
 -mstack-align  -mdata-align  -mconst-align @gol
--m32-bit  -m16-bit  -m8-bit  -mno-prologue-epilogue  -mno-gotplt @gol
--melf  -maout  -melinux  -mlinux  -sim  -sim2 @gol
+-m32-bit  -m16-bit  -m8-bit  -mno-prologue-epilogue @gol
+-melf  -maout  -sim  -sim2 @gol
 -mmul-bug-workaround  -mno-mul-bug-workaround}
 
 @emph{CR16 Options}
@@ -22365,8 +22365,7 @@ These options are defined specifically for the CRIS 
ports.
 Generate code for the specified architecture.  The choices for
 @var{architecture-type} are @samp{v3}, @samp{v8} and @samp{v10} for
 respectively ETRAX@w{ }4, ETRAX@w{ }100, and ETRAX@w{ }100@w{ }LX@.
-Default is @samp{v0} except for cris-axis-linux-gnu, where the default is
-@samp{v10}.
+Default is @samp{v0}.
 
 @item -mtune=@var{architecture-type}
 @opindex mtune
@@ -22450,27 +22449,13 @@ option only together with visual inspection of the 
compiled code: no
 warnings or errors are generated when call-saved registers must be saved,
 or storage for local variables needs to be allocated.
 
-@item -mno-gotplt
-@itemx -mgotplt
-@opindex mno-gotplt
-@opindex mgotplt
-With @option{-fpic} and @option{-fPIC}, don't generate (do generate)
-instruction sequences that load addresses for functions from the PLT part
-of the GOT rather than (traditional on other architectures) calls to the
-PLT@.  The default is @option{-mgotplt}.
-
 @item -melf
 @opindex melf
-Legacy no-op option only recognized with the cris-axis-elf and
-cris-axis-linux-gnu targets.
-
-@item -mlinux
-@opindex mlinux
-Legacy no-op option only recognized with the cris-axis-linux-gnu target.
+Legacy no-op option.
 
 @item -sim
 @opindex sim
-This option, recognized for the cris-axis-elf, arranges
+This option arranges
 to link with input-output functions from a simulator library.  Code,
 initialized data and zero-initialized data are allocated consecutively.
 
-- 
2.30.2

[PATCH v2 1/2] rs6000: Move g++.dg powerpc PR tests to g++.target

[Paul A. Clarke via Gcc-patches]

Also adjust DejaGnu directives, as specifically requiring "powerpc*-*-*" is no
longer required.

2021-04-18  Paul A. Clarke  

gcc/testsuite
* g++.dg/pr65240.h: Move to g++.target/powerpc.
* g++.dg/pr93974.C: Likewise.
* g++.dg/pr65240-1.C: Move to g++.target/powerpc, adjust dg directives.
* g++.dg/pr65240-2.C: Likewise.
* g++.dg/pr65240-3.C: Likewise.
* g++.dg/pr65240-4.C: Likewise.
* g++.dg/pr65242.C: Likewise.
* g++.dg/pr67211.C: Likewise.
* g++.dg/pr69667.C: Likewise.
* g++.dg/pr71294.C: Likewise.
* g++.dg/pr84264.C: Likewise.
* g++.dg/pr84279.C: Likewise.
* g++.dg/pr85657.C: Likewise.
---
 gcc/testsuite/{g++.dg => g++.target/powerpc}/pr65240-1.C | 4 ++--
 gcc/testsuite/{g++.dg => g++.target/powerpc}/pr65240-2.C | 4 ++--
 gcc/testsuite/{g++.dg => g++.target/powerpc}/pr65240-3.C | 4 ++--
 gcc/testsuite/{g++.dg => g++.target/powerpc}/pr65240-4.C | 4 ++--
 gcc/testsuite/{g++.dg => g++.target/powerpc}/pr65240.h   | 0
 gcc/testsuite/{g++.dg => g++.target/powerpc}/pr65242.C   | 4 ++--
 gcc/testsuite/{g++.dg => g++.target/powerpc}/pr67211.C   | 4 ++--
 gcc/testsuite/{g++.dg => g++.target/powerpc}/pr69667.C   | 4 ++--
 gcc/testsuite/{g++.dg => g++.target/powerpc}/pr71294.C   | 2 +-
 gcc/testsuite/{g++.dg => g++.target/powerpc}/pr84264.C   | 2 +-
 gcc/testsuite/{g++.dg => g++.target/powerpc}/pr84279.C   | 4 ++--
 gcc/testsuite/{g++.dg => g++.target/powerpc}/pr85657.C   | 2 +-
 gcc/testsuite/{g++.dg => g++.target/powerpc}/pr93974.C   | 0
 13 files changed, 19 insertions(+), 19 deletions(-)
 rename gcc/testsuite/{g++.dg => g++.target/powerpc}/pr65240-1.C (71%)
 rename gcc/testsuite/{g++.dg => g++.target/powerpc}/pr65240-2.C (71%)
 rename gcc/testsuite/{g++.dg => g++.target/powerpc}/pr65240-3.C (70%)
 rename gcc/testsuite/{g++.dg => g++.target/powerpc}/pr65240-4.C (68%)
 rename gcc/testsuite/{g++.dg => g++.target/powerpc}/pr65240.h (100%)
 rename gcc/testsuite/{g++.dg => g++.target/powerpc}/pr65242.C (93%)
 rename gcc/testsuite/{g++.dg => g++.target/powerpc}/pr67211.C (91%)
 rename gcc/testsuite/{g++.dg => g++.target/powerpc}/pr69667.C (97%)
 rename gcc/testsuite/{g++.dg => g++.target/powerpc}/pr71294.C (96%)
 rename gcc/testsuite/{g++.dg => g++.target/powerpc}/pr84264.C (79%)
 rename gcc/testsuite/{g++.dg => g++.target/powerpc}/pr84279.C (90%)
 rename gcc/testsuite/{g++.dg => g++.target/powerpc}/pr85657.C (90%)
 rename gcc/testsuite/{g++.dg => g++.target/powerpc}/pr93974.C (100%)

diff --git a/gcc/testsuite/g++.dg/pr65240-1.C 
b/gcc/testsuite/g++.target/powerpc/pr65240-1.C
similarity index 71%
rename from gcc/testsuite/g++.dg/pr65240-1.C
rename to gcc/testsuite/g++.target/powerpc/pr65240-1.C
index ff8910df6a1a..f735a1f7834a 100644
--- a/gcc/testsuite/g++.dg/pr65240-1.C
+++ b/gcc/testsuite/g++.target/powerpc/pr65240-1.C
@@ -1,5 +1,5 @@
-/* { dg-do compile { target { powerpc*-*-* && lp64 } } } */
-/* { dg-skip-if "" { powerpc*-*-darwin* } } */
+/* { dg-do compile { target lp64 } } */
+/* { dg-skip-if "" { *-*-darwin* } } */
 /* { dg-require-effective-target powerpc_p8vector_ok } */
 /* { dg-options "-mdejagnu-cpu=power8 -O3 -ffast-math -mcmodel=small 
-mno-fp-in-toc -Wno-return-type" } */
 
diff --git a/gcc/testsuite/g++.dg/pr65240-2.C 
b/gcc/testsuite/g++.target/powerpc/pr65240-2.C
similarity index 71%
rename from gcc/testsuite/g++.dg/pr65240-2.C
rename to gcc/testsuite/g++.target/powerpc/pr65240-2.C
index bdb7a62d73d2..e201e3a74d71 100644
--- a/gcc/testsuite/g++.dg/pr65240-2.C
+++ b/gcc/testsuite/g++.target/powerpc/pr65240-2.C
@@ -1,5 +1,5 @@
-/* { dg-do compile { target { powerpc*-*-* && lp64 } } } */
-/* { dg-skip-if "" { powerpc*-*-darwin* } } */
+/* { dg-do compile { target lp64 } } */
+/* { dg-skip-if "" { *-*-darwin* } } */
 /* { dg-require-effective-target powerpc_p8vector_ok } */
 /* { dg-options "-mdejagnu-cpu=power8 -O3 -ffast-math -mcmodel=small 
-mfp-in-toc -Wno-return-type" } */
 
diff --git a/gcc/testsuite/g++.dg/pr65240-3.C 
b/gcc/testsuite/g++.target/powerpc/pr65240-3.C
similarity index 70%
rename from gcc/testsuite/g++.dg/pr65240-3.C
rename to gcc/testsuite/g++.target/powerpc/pr65240-3.C
index f37db9025d12..0821f68a5cf9 100644
--- a/gcc/testsuite/g++.dg/pr65240-3.C
+++ b/gcc/testsuite/g++.target/powerpc/pr65240-3.C
@@ -1,5 +1,5 @@
-/* { dg-do compile { target { powerpc*-*-* && lp64 } } } */
-/* { dg-skip-if "" { powerpc*-*-darwin* } } */
+/* { dg-do compile { target lp64 } } */
+/* { dg-skip-if "" { *-*-darwin* } } */
 /* { dg-require-effective-target powerpc_p8vector_ok } */
 /* { dg-options "-mdejagnu-cpu=power8 -O3 -ffast-math -mcmodel=medium 
-Wno-return-type" } */
 
diff --git a/gcc/testsuite/g++.dg/pr65240-4.C 
b/gcc/testsuite/g++.target/powerpc/pr65240-4.C
similarity index 68%
rename from gcc/testsuite/g++.dg/pr65240-4.C
rename to gcc/testsuite/g++.target/powerpc/pr65240-4.C
index efb6a6c06e7c..92d31acb20d9 100644
--- a/gcc/testsuite/g++.dg/pr65240-4.C
+++ 

[PATCH v2 2/2] rs6000: Remove a few needless 'lp64' contraints.

[Paul A. Clarke via Gcc-patches]

A few tests need not be restricted to 'lp64', so remove the restriction.

A few of those need a simple change to the DejaGnu directives to suppress
'-mcmodel' flags for '-m32'.

2022-04-18  Paul A. Clarke  

gcc/testsuite
* g++.target/powerpc/pr65240-1.C: Adjust DejaGnu directives.
* g++.target/powerpc/pr65240-2.C: Likewise.
* g++.target/powerpc/pr65240-3.C: Likewise.
* g++.target/powerpc/pr65240-4.C: Likewise.
* g++.target/powerpc/pr65242.C: Likewise.
* g++.target/powerpc/pr67211.C: Likewise.
* g++.target/powerpc/pr69667.C: Likewise.
* g++.target/powerpc/pr71294.C: Likewise.
---
 gcc/testsuite/g++.target/powerpc/pr65240-1.C | 5 +++--
 gcc/testsuite/g++.target/powerpc/pr65240-2.C | 5 +++--
 gcc/testsuite/g++.target/powerpc/pr65240-3.C | 5 +++--
 gcc/testsuite/g++.target/powerpc/pr65240-4.C | 3 ++-
 gcc/testsuite/g++.target/powerpc/pr65242.C   | 3 ++-
 gcc/testsuite/g++.target/powerpc/pr67211.C   | 3 ++-
 gcc/testsuite/g++.target/powerpc/pr69667.C   | 3 ++-
 gcc/testsuite/g++.target/powerpc/pr71294.C   | 2 +-
 8 files changed, 18 insertions(+), 11 deletions(-)

diff --git a/gcc/testsuite/g++.target/powerpc/pr65240-1.C 
b/gcc/testsuite/g++.target/powerpc/pr65240-1.C
index f735a1f7834a..40682d5fe857 100644
--- a/gcc/testsuite/g++.target/powerpc/pr65240-1.C
+++ b/gcc/testsuite/g++.target/powerpc/pr65240-1.C
@@ -1,7 +1,8 @@
-/* { dg-do compile { target lp64 } } */
+/* Never tested on darwin, so skip there.  */
 /* { dg-skip-if "" { *-*-darwin* } } */
 /* { dg-require-effective-target powerpc_p8vector_ok } */
-/* { dg-options "-mdejagnu-cpu=power8 -O3 -ffast-math -mcmodel=small 
-mno-fp-in-toc -Wno-return-type" } */
+/* { dg-options "-mdejagnu-cpu=power8 -O3 -ffast-math -mno-fp-in-toc 
-Wno-return-type" } */
+/* { dg-additional-options "-mcmodel=small" { target lp64 } } */
 
 /* target/65240, compiler got a 'insn does not satisfy its constraints' error. 
 */
 
diff --git a/gcc/testsuite/g++.target/powerpc/pr65240-2.C 
b/gcc/testsuite/g++.target/powerpc/pr65240-2.C
index e201e3a74d71..4e4a1c2bb897 100644
--- a/gcc/testsuite/g++.target/powerpc/pr65240-2.C
+++ b/gcc/testsuite/g++.target/powerpc/pr65240-2.C
@@ -1,7 +1,8 @@
-/* { dg-do compile { target lp64 } } */
+/* Never tested on darwin, so skip there.  */
 /* { dg-skip-if "" { *-*-darwin* } } */
 /* { dg-require-effective-target powerpc_p8vector_ok } */
-/* { dg-options "-mdejagnu-cpu=power8 -O3 -ffast-math -mcmodel=small 
-mfp-in-toc -Wno-return-type" } */
+/* { dg-options "-mdejagnu-cpu=power8 -O3 -ffast-math -mfp-in-toc 
-Wno-return-type" } */
+/* { dg-additional-options "-mcmodel=small" { target lp64 } } */
 
 /* target/65240, compiler got a 'insn does not satisfy its constraints' error. 
 */
 
diff --git a/gcc/testsuite/g++.target/powerpc/pr65240-3.C 
b/gcc/testsuite/g++.target/powerpc/pr65240-3.C
index 0821f68a5cf9..6acd278cab50 100644
--- a/gcc/testsuite/g++.target/powerpc/pr65240-3.C
+++ b/gcc/testsuite/g++.target/powerpc/pr65240-3.C
@@ -1,7 +1,8 @@
-/* { dg-do compile { target lp64 } } */
+/* Never tested on darwin, so skip there.  */
 /* { dg-skip-if "" { *-*-darwin* } } */
 /* { dg-require-effective-target powerpc_p8vector_ok } */
-/* { dg-options "-mdejagnu-cpu=power8 -O3 -ffast-math -mcmodel=medium 
-Wno-return-type" } */
+/* { dg-options "-mdejagnu-cpu=power8 -O3 -ffast-math -Wno-return-type" } */
+/* { dg-additional-options "-mcmodel=medium" { target lp64 } } */
 
 /* target/65240, compiler got a 'insn does not satisfy its constraints' error. 
 */
 
diff --git a/gcc/testsuite/g++.target/powerpc/pr65240-4.C 
b/gcc/testsuite/g++.target/powerpc/pr65240-4.C
index 92d31acb20d9..57f2c769a3f3 100644
--- a/gcc/testsuite/g++.target/powerpc/pr65240-4.C
+++ b/gcc/testsuite/g++.target/powerpc/pr65240-4.C
@@ -1,4 +1,5 @@
-/* { dg-do compile { target lp64 } } */
+/* { dg-do compile } */
+/* Never tested on darwin, so skip there.  */
 /* { dg-skip-if "" { *-*-darwin* } } */
 /* { dg-require-effective-target powerpc_vsx_ok } */
 /* { dg-options "-mdejagnu-cpu=power7 -O3 -ffast-math -Wno-return-type" } */
diff --git a/gcc/testsuite/g++.target/powerpc/pr65242.C 
b/gcc/testsuite/g++.target/powerpc/pr65242.C
index b2984d1d6083..64ca67e246f8 100644
--- a/gcc/testsuite/g++.target/powerpc/pr65242.C
+++ b/gcc/testsuite/g++.target/powerpc/pr65242.C
@@ -1,4 +1,5 @@
-/* { dg-do compile { target lp64 } } */
+/* { dg-do compile } */
+/* Never tested on darwin, so skip there.  */
 /* { dg-skip-if "" { *-*-darwin* } } */
 /* { dg-require-effective-target powerpc_p8vector_ok } */
 /* { dg-options "-mdejagnu-cpu=power8 -O3" } */
diff --git a/gcc/testsuite/g++.target/powerpc/pr67211.C 
b/gcc/testsuite/g++.target/powerpc/pr67211.C
index b58c08234272..946802e44cde 100644
--- a/gcc/testsuite/g++.target/powerpc/pr67211.C
+++ b/gcc/testsuite/g++.target/powerpc/pr67211.C
@@ -1,4 +1,5 @@
-/* { dg-do compile { target lp64 } } */
+/* { dg-do compile } */
+/* Never tested on darwin, so skip there.  */
 /* { dg-skip-if "" { 

[PATCH v2 0/2] rs6000: Move g++.dg powerpc tests to g++.target

[Paul A. Clarke via Gcc-patches]

V1 patches 1/3 and 2/3 have been merged after reviews / approval.

Previous 3/3 is now 1/2, and new 2/2 is per review from Segher...

Some tests in g++.dg are target-specific for powerpc. Move those to
g++.target/powerpc. Update the DejaGnu directives as needed, since
the target restriction is perhaps no longer needed when residing in the
target-specific powerpc subdirectory.

In addition (new patch 2/2), as suggested by Segher, remove 'lp64' restriction
for a handful of tests, protecting uses of '-mcmodel' flag with
dg-additional-options.

Tested on Linux/Power9 (BE) and Linux Power8 (LE 32 and 64), full "make check".

OK for trunk?

Paul A. Clarke (2):
  rs6000: Move g++.dg powerpc PR tests to g++.target
  rs6000: Remove a few needless 'lp64' contraints.

 gcc/testsuite/g++.dg/pr65240-1.C | 8 
 gcc/testsuite/g++.dg/pr65240-2.C | 8 
 gcc/testsuite/g++.dg/pr65240-3.C | 8 
 gcc/testsuite/g++.target/powerpc/pr65240-1.C | 9 +
 gcc/testsuite/g++.target/powerpc/pr65240-2.C | 9 +
 gcc/testsuite/g++.target/powerpc/pr65240-3.C | 9 +
 gcc/testsuite/{g++.dg => g++.target/powerpc}/pr65240-4.C | 5 +++--
 gcc/testsuite/{g++.dg => g++.target/powerpc}/pr65240.h   | 0
 gcc/testsuite/{g++.dg => g++.target/powerpc}/pr65242.C   | 5 +++--
 gcc/testsuite/{g++.dg => g++.target/powerpc}/pr67211.C   | 5 +++--
 gcc/testsuite/{g++.dg => g++.target/powerpc}/pr69667.C   | 5 +++--
 gcc/testsuite/{g++.dg => g++.target/powerpc}/pr71294.C   | 2 +-
 gcc/testsuite/{g++.dg => g++.target/powerpc}/pr84264.C   | 2 +-
 gcc/testsuite/{g++.dg => g++.target/powerpc}/pr84279.C   | 4 ++--
 gcc/testsuite/{g++.dg => g++.target/powerpc}/pr85657.C   | 2 +-
 gcc/testsuite/{g++.dg => g++.target/powerpc}/pr93974.C   | 0
 16 files changed, 44 insertions(+), 37 deletions(-)
 delete mode 100644 gcc/testsuite/g++.dg/pr65240-1.C
 delete mode 100644 gcc/testsuite/g++.dg/pr65240-2.C
 delete mode 100644 gcc/testsuite/g++.dg/pr65240-3.C
 create mode 100644 gcc/testsuite/g++.target/powerpc/pr65240-1.C
 create mode 100644 gcc/testsuite/g++.target/powerpc/pr65240-2.C
 create mode 100644 gcc/testsuite/g++.target/powerpc/pr65240-3.C
 rename gcc/testsuite/{g++.dg => g++.target/powerpc}/pr65240-4.C (68%)
 rename gcc/testsuite/{g++.dg => g++.target/powerpc}/pr65240.h (100%)
 rename gcc/testsuite/{g++.dg => g++.target/powerpc}/pr65242.C (93%)
 rename gcc/testsuite/{g++.dg => g++.target/powerpc}/pr67211.C (91%)
 rename gcc/testsuite/{g++.dg => g++.target/powerpc}/pr69667.C (97%)
 rename gcc/testsuite/{g++.dg => g++.target/powerpc}/pr71294.C (96%)
 rename gcc/testsuite/{g++.dg => g++.target/powerpc}/pr84264.C (79%)
 rename gcc/testsuite/{g++.dg => g++.target/powerpc}/pr84279.C (90%)
 rename gcc/testsuite/{g++.dg => g++.target/powerpc}/pr85657.C (90%)
 rename gcc/testsuite/{g++.dg => g++.target/powerpc}/pr93974.C (100%)

-- 
2.27.0

[PATCH] doc/install.texi: CRIS: Remove gone websites. Adjust CRIS targets

[Hans-Peter Nilsson via Gcc-patches]

I'm about to commit this to master.

I'd like to also install this on the gcc-11 branch.

Ok?

-- 8< --

That is, support for cris-linux-gnu was removed in gcc-11, but
install.texi wasn't adjusted accordingly.  Also, unfortunately the
developer-related sites are gone with no replacements.  And, CRIS is
used in other chip series as well, but allude rather than list.

The generated manpages, info, pdf and html were sanity-checked.

gcc:
* doc/install.texi : Remove references to removed websites and
adjust for cris-*-elf being the only remaining toolchain.
---
 gcc/doc/install.texi | 21 -
 1 file changed, 4 insertions(+), 17 deletions(-)

diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index ab67a639836b..304785767027 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -3901,8 +3901,8 @@ configure GCC@ for building a CR16 uclinux cross-compiler.
 @end html
 @anchor{cris}
 @heading CRIS
-CRIS is the CPU architecture in Axis Communications ETRAX system-on-a-chip
-series.  These are used in embedded applications.
+CRIS is a CPU architecture in Axis Communications systems-on-a-chip, for
+example the ETRAX series.  These are used in embedded applications.
 
 @ifnothtml
 @xref{CRIS Options,, CRIS Options, gcc, Using the GNU Compiler
@@ -3913,21 +3913,8 @@ See ``CRIS Options'' in the main manual
 @end ifhtml
 for a list of CRIS-specific options.
 
-There are a few different CRIS targets:
-@table @code
-@item cris-axis-elf
-Mainly for monolithic embedded systems.  Includes a multilib for the
-@samp{v10} core used in @samp{ETRAX 100 LX}.
-@item cris-axis-linux-gnu
-A GNU/Linux port for the CRIS architecture, currently targeting
-@samp{ETRAX 100 LX} by default.
-@end table
-
-Pre-packaged tools can be obtained from
-@uref{ftp://ftp.axis.com/@/pub/@/axis/@/tools/@/cris/@/compiler-kit/}.  More
-information about this platform is available at
-@uref{http://developer.axis.com/}.
-
+Use @samp{configure --target=cris-elf} to configure GCC@ for building
+a cross-compiler for CRIS.
 @html
 
 @end html
-- 
2.30.2

[Bug c++/105304] New: ICE segfault using ad-hoc concept with -Wall

[bjoern at hoehrmann dot de via Gcc-bugs]

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

Bug ID: 105304
   Summary: ICE segfault using ad-hoc concept with -Wall
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bjoern at hoehrmann dot de
  Target Milestone: ---

GCC 11.2.0 on Linux

 ❯  g++-11 -Wall -std=c++2a -o x ../mini.cxx   
../mini.cxx: In function 'int main()':
../mini.cxx:23:18: internal compiler error: Segmentation fault
   23 | }) {
  |  ^
Please submit a full bug report,

Code:

#include 
#include 

class X
{
public:
  int m(int, int, int = 7) { return 123; }
};

template
void
invoke_m(std::index_sequence_for is)
{
  X o;
  o.m(Ts()...);
}

int
main()
{
  if constexpr (requires {
  invoke_m(std::make_index_sequence<4>());
}) {
std::cerr << "ok" << '\n';
  }

  return 0;
}

Compiles when omitting -Wall.

[COMMITTED] readings.html: developer.axis.com is gone, remove

[Hans-Peter Nilsson via Gcc-patches]

Unfortunately I know of no replacement.
---
 htdocs/readings.html | 1 -
 1 file changed, 1 deletion(-)

diff --git a/htdocs/readings.html b/htdocs/readings.html
index 8689eab8b2d1..2467945b1cb6 100644
--- a/htdocs/readings.html
+++ b/htdocs/readings.html
@@ -118,7 +118,6 @@ names.
Manufacturer: Axis Communications
Acronym stands for: Code Reduced Instruction Set
The CRIS architecture is used in the ETRAX system-on-a-chip series.
-   http://developer.axis.com/;>Site with CPU documentation
  
  
  C-SKY
-- 
2.30.2

[Bug c++/104051] [coroutines] ICE: tree check: expected target_expr, have call_expr in coro_diagnose_throwing_final_aw_expr, at cp/coroutines.cc:880 since r11-7528-g9ee91079fd5879cb

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

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

Iain Sandoe  changed:

   What|Removed |Added

   Last reconfirmed||2022-04-18
   Assignee|unassigned at gcc dot gnu.org  |iains at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Iain Sandoe  ---
candidate patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593320.html

[PATCH] c++, coroutines: Improve check for throwing final await [PR104051].

[Iain Sandoe via Gcc-patches]

We check that the final_suspend () method returns a sane type (i.e. a class
or structure) but, unfortunately, that check has to be later than the one
for a throwing case.  If the user returns some nonsensical type from the
method, we need to handle that in the checking for noexcept.

tested on x86_64-darwin, OK for mainline? (when?),
thanks
Iain

Signed-off-by: Iain Sandoe 

PR c++/104051

gcc/cp/ChangeLog:

* coroutines.cc (coro_diagnose_throwing_final_aw_expr): Handle
non-target expression inputs.

gcc/testsuite/ChangeLog:

* g++.dg/coroutines/pr104051.C: New test.
---
 gcc/cp/coroutines.cc   | 13 +-
 gcc/testsuite/g++.dg/coroutines/pr104051.C | 29 ++
 2 files changed, 36 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/coroutines/pr104051.C

diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index d2a765cac11..cb9bbed51e6 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -883,13 +883,14 @@ coro_diagnose_throwing_fn (tree fndecl)
 static bool
 coro_diagnose_throwing_final_aw_expr (tree expr)
 {
-  tree t = TARGET_EXPR_INITIAL (expr);
+  if (TREE_CODE (expr) == TARGET_EXPR)
+expr = TARGET_EXPR_INITIAL (expr);
   tree fn = NULL_TREE;
-  if (TREE_CODE (t) == CALL_EXPR)
-fn = CALL_EXPR_FN(t);
-  else if (TREE_CODE (t) == AGGR_INIT_EXPR)
-fn = AGGR_INIT_EXPR_FN (t);
-  else if (TREE_CODE (t) == CONSTRUCTOR)
+  if (TREE_CODE (expr) == CALL_EXPR)
+fn = CALL_EXPR_FN (expr);
+  else if (TREE_CODE (expr) == AGGR_INIT_EXPR)
+fn = AGGR_INIT_EXPR_FN (expr);
+  else if (TREE_CODE (expr) == CONSTRUCTOR)
 return false;
   else
 {
diff --git a/gcc/testsuite/g++.dg/coroutines/pr104051.C 
b/gcc/testsuite/g++.dg/coroutines/pr104051.C
new file mode 100644
index 000..ce7ae55405a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/coroutines/pr104051.C
@@ -0,0 +1,29 @@
+// { dg-additional-options "-fsyntax-only" }
+#include 
+#include 
+template  struct promise {
+  struct final_awaitable {
+bool await_ready() noexcept;
+template 
+std::coroutine_handle<>
+await_suspend(std::coroutine_handle) noexcept;
+void await_resume() noexcept;
+  };
+  auto get_return_object() {
+return std::coroutine_handle::from_promise(*this);
+  }
+  auto initial_suspend() { return std::suspend_always(); }
+  auto final_suspend() noexcept { return true; }
+  void unhandled_exception();
+};
+template  struct task {
+  using promise_type = promise;
+  task(std::coroutine_handle>);
+  bool await_ready();
+  std::coroutine_handle<> await_suspend(std::coroutine_handle<>);
+  T await_resume();
+};
+task> foo() { // { dg-error {awaitable type 'bool' is not a 
structure} }
+  while ((co_await foo()).empty())
+;
+}
-- 
2.24.3 (Apple Git-128)

[Bug target/105162] [AArch64] outline-atomics drops dmb ish barrier on __sync builtins

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

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

Sebastian Pop  changed:

   What|Removed |Added

  Attachment #52762|0   |1
is obsolete||

--- Comment #8 from Sebastian Pop  ---
Created attachment 52826
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52826=edit
patch

You are right.  Please see attached an amended patch that only adds the
barriers to __sync builtins.

[Bug ada/105303] New: Assertion_Policy (Pre => Ignore) executes precondition

[simon at pushface dot org via Gcc-bugs]

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

Bug ID: 105303
   Summary: Assertion_Policy (Pre => Ignore) executes precondition
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: simon at pushface dot org
  Target Milestone: ---

System.Generic_Array_Operations starts with

   --  Preconditions in this unit are meant for analysis only, not for run-time
   --  checking, so that the expected exceptions are raised. This is enforced
   --  by setting the corresponding assertion policy to Ignore. Postconditions
   --  and contract cases should not be executed at runtime as well, in order
   --  not to slow down the execution of these functions.

   pragma Assertion_Policy (Pre=> Ignore,
Post   => Ignore,
Contract_Cases => Ignore,
Ghost  => Ignore);

and yet, given this clearly wrong code (compiled with -gnata)

   with System.Generic_Array_Operations;
   procedure Transposition is
  type Matrix is array (Integer range <>, Integer range <>) of Float;
  procedure Transpose is new System.Generic_Array_Operations.Transpose
(Scalar => Float,
 Matrix => Matrix);
  Input : Matrix (1 .. 3, 1 .. 4);
  Output : Matrix (1 .. 3, 1 .. 2);
   begin
  Transpose (Input, Output);
   end Transposition;

Ada.Assertions.Assertion_Error is in fact raised, contrary to ARM2012
11.4.2(10):

   $ ./transposition 

   raised ADA.ASSERTIONS.ASSERTION_ERROR : failed precondition from
s-gearop.ads:569 instantiated at transposition.adb:4

The comment noted above is confusing, if not wrong:

"Preconditions ... not meant for runtime checking, so that the expected
exceptions are raised" -- the checks should not be performed, and the
exceptions should not be raised.

[Bug c++/100052] [11/12 regression] ICE in compiling g++.dg/modules/xtreme-header-3_b.C after r11-8118

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

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

--- Comment #11 from seurer at gcc dot gnu.org ---
These failures are still occurring.  The revision change doesn't appear to have
anything to do with it given it was the "daily bump".


Regressions on 11 (power8) on update from
5fb29a72faff6960f6b0c94119ae53af9a013d24, r11-9884-g5fb29a72faff69 to
97eda33b5fa29c2d0b602a44bdc375b034f4f9f3, r11-9885-g97eda33b5fa29c

FAIL: g++.dg/modules/xtreme-header-3_a.H module-cmi
(gcm.cache/\$srcdir/g++.dg/modules/xtreme-header-3_a.H.gcm)
FAIL: g++.dg/modules/xtreme-header-3_a.H module-cmi
(gcm.cache/\$srcdir/g++.dg/modules/xtreme-header-3_a.H.gcm)
FAIL: g++.dg/modules/xtreme-header-3_a.H module-cmi
(gcm.cache/\$srcdir/g++.dg/modules/xtreme-header-3_a.H.gcm)
FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++17 (internal compiler error)
FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++2a (internal compiler error)
FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++2b (internal compiler error)
FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-3_b.C -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-3_b.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-3_b.C -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-3_c.C -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-3_c.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-3_c.C -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/xtreme-header_a.H module-cmi
(gcm.cache/\$srcdir/g++.dg/modules/xtreme-header_a.H.gcm)
FAIL: g++.dg/modules/xtreme-header_a.H module-cmi
(gcm.cache/\$srcdir/g++.dg/modules/xtreme-header_a.H.gcm)
FAIL: g++.dg/modules/xtreme-header_a.H module-cmi
(gcm.cache/\$srcdir/g++.dg/modules/xtreme-header_a.H.gcm)
FAIL: g++.dg/modules/xtreme-header_a.H -std=c++17 (internal compiler error)
FAIL: g++.dg/modules/xtreme-header_a.H -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/xtreme-header_a.H -std=c++2a (internal compiler error)
FAIL: g++.dg/modules/xtreme-header_a.H -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/xtreme-header_a.H -std=c++2b (internal compiler error)
FAIL: g++.dg/modules/xtreme-header_a.H -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/xtreme-header_b.C -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/xtreme-header_b.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/xtreme-header_b.C -std=c++2b (test for excess errors)

[Bug debug/104050] '-fcompare-debug' failure w/ -std=c++20 -O1

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

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

--- Comment #2 from Iain Sandoe  ---
(In reply to Martin Liška from comment #1)
> Confirmed. Interesting that one needs -save-temps. Likely started with GCC
> 11.

I compared the simple from the FE with -save-temps (FAILS) and without (OK)

the only difference between the two cases is that the temporary numbers are
different by two (the numbers are +2 for the case without save temps).  That is
the same as the difference shown in the report - but not sure how to analyse
that further right now ...

Switch statement optimization

[Paul Koning via Gcc]

In switch statements with dense case values, the typical result is a jump 
table, which is fast.  If the values are sparse, a tree of compares is 
generated instead.

What if nearly all cases are dense but there are a few outliers?  An example 
appears in the NFS protocol parser, where you get a switch statement with cases 
for each of the opcode values.  All but one are small integers assigned in 
sequence, but one is 10044.  So the "sparse" case kicks in and a compare tree 
is generated for everything.

I can avoid this by putting in special case code for the 10044 case, then all 
the rest ends up being a jump table.  That brings up the question if GCC should 
recognize such scenarios and break up the switch statement into "dense parts" 
handled by a jump table, leaving the sorting between those as a compare tree.

paul

[PATCH] libstdc++: Micro-optimize __from_chars_pow2_base

[Patrick Palka via Gcc-patches]

At the first iteration of __from_chars_pow2_base's main loop, we need
to remember the value of the leading significant digit for sake of the
overflow check at the end of the function (for bases other than 2).

This patch manually unrolls this first iteration so as to not encumber
the entire loop with logic that only the first iteration needs.  This
seems to significantly improve performance:

Base  Before  After (seconds, lower is better)
   29.36   9.37
   83.66   2.93
  162.93   1.91
  322.39   2.24

Tested on x86_64-pc-linux-gnu, does this look OK for trunk?

libstdc++-v3/ChangeLog:

* include/std/charconv (__from_chars_pow2_base): Manually
unroll the first iteration of the main loop and simplify
accordingly.
---
 libstdc++-v3/include/std/charconv | 30 +-
 1 file changed, 21 insertions(+), 9 deletions(-)

diff --git a/libstdc++-v3/include/std/charconv 
b/libstdc++-v3/include/std/charconv
index dda4ec87779..cd7f52e2195 100644
--- a/libstdc++-v3/include/std/charconv
+++ b/libstdc++-v3/include/std/charconv
@@ -469,25 +469,37 @@ namespace __detail
   while (__i < __len && __first[__i] == '0')
++__i;
   const ptrdiff_t __leading_zeroes = __i;
+  if (__i >= __len) [[__unlikely__]]
+   {
+ __first += __i;
+ return true;
+   }
+
+  // Remember the leading significant digit value if necessary.
+  unsigned char __leading_c;
+  if (__base != 2)
+   {
+ __leading_c = __from_chars_alnum_to_val<_DecOnly>(__first[__i]);
+ // __glibcxx_assert(__leading_c != 0);
+ if (__leading_c >= __base) [[__unlikely__]]
+   {
+ __first += __i;
+ return true;
+   }
+ __val = __leading_c;
+ ++__i;
+   }
 
-  unsigned char __leading_c = 0;
   for (; __i < __len; ++__i)
{
  const unsigned char __c = 
__from_chars_alnum_to_val<_DecOnly>(__first[__i]);
  if (__c >= __base)
break;
  __val = (__val << __log2_base) | __c;
-
- if (__i == __leading_zeroes)
-   {
- // At the first iteration, remember the leading significant digit.
- // __glibcxx_assert(__leading_c == 0 && __c != 0);
- __leading_c = __c;
-   }
}
   __first += __i;
   auto __significant_bits = (__i - __leading_zeroes) * __log2_base;
-  if (__base != 2 && __leading_c != 0)
+  if (__base != 2)
// Compensate for a leading significant digit that didn't use all
// of its available bits.
__significant_bits -= __log2_base - __bit_width(__leading_c);
-- 
2.36.0.rc2.10.g1ac7422e39

[Bug c++/105301] [11/12 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'overload' in coro_promise_type_found_p, at cp/coroutines.cc:516

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

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

--- Comment #2 from Iain Sandoe  ---
candidate patch.
https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593318.html

[Bug analyzer/105287] [12 Regression] ICE in analyzer get_region_for_local on C++ await cond_var

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

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

--- Comment #4 from Iain Sandoe  ---
candidate patch for the ICE (I am not sure if there's anything needed on the
analyser side).

https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593317.html

[Bug c++/103868] ICE at end of coroutine when using asio

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

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

Iain Sandoe  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |iains at gcc dot gnu.org

--- Comment #5 from Iain Sandoe  ---
candidate patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593316.html

[PATCH] c++, coroutines: Account for overloaded promise return_value() [PR105301].

[Iain Sandoe via Gcc-patches]

Whether it was intended or not, it is possible to define a coroutine promise
with multiple return_value() methods [which need not even have the same type].

We were not accounting for this possibility in the check to see whether both
return_value and return_void are specifier (which is prohibited by the
standard).  Fixed thus and provided an adjusted diagnostic for the case that
multiple return_value() methods are present.

tested on x86_64-darwin, OK for mainline? / Backports? (when?)
thanks,
Iain

Signed-off-by: Iain Sandoe 

PR c++/105301

gcc/cp/ChangeLog:

* coroutines.cc (coro_promise_type_found_p): Account for possible
mutliple overloads of the promise return_value() method.

gcc/testsuite/ChangeLog:

* g++.dg/coroutines/pr105301.C: New test.
---
 gcc/cp/coroutines.cc   | 10 -
 gcc/testsuite/g++.dg/coroutines/pr105301.C | 49 ++
 2 files changed, 57 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/coroutines/pr105301.C

diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index dcc2284171b..d2a765cac11 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -513,8 +513,14 @@ coro_promise_type_found_p (tree fndecl, location_t loc)
  coro_info->promise_type);
  inform (DECL_SOURCE_LOCATION (BASELINK_FUNCTIONS (has_ret_void)),
  "% declared here");
- inform (DECL_SOURCE_LOCATION (BASELINK_FUNCTIONS (has_ret_val)),
- "% declared here");
+ has_ret_val = BASELINK_FUNCTIONS (has_ret_val);
+ const char *message = "% declared here";
+ if (TREE_CODE (has_ret_val) == OVERLOAD)
+   {
+ has_ret_val = OVL_FIRST (has_ret_val);
+ message = "% first declared here";
+   }
+ inform (DECL_SOURCE_LOCATION (has_ret_val), message);
  coro_info->coro_co_return_error_emitted = true;
  return false;
}
diff --git a/gcc/testsuite/g++.dg/coroutines/pr105301.C 
b/gcc/testsuite/g++.dg/coroutines/pr105301.C
new file mode 100644
index 000..33a0b03cf5d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/coroutines/pr105301.C
@@ -0,0 +1,49 @@
+// { dg-additional-options "-fsyntax-only" }
+namespace std {
+template 
+struct traits_sfinae_base {};
+
+template 
+struct coroutine_traits : public traits_sfinae_base {};
+}
+
+template struct coro {};
+template 
+struct std::coroutine_traits, Ps...> {
+  using promise_type = Promise;
+};
+
+struct awaitable {
+  bool await_ready() noexcept;
+  template 
+  void await_suspend(F) noexcept;
+  void await_resume() noexcept;
+} a;
+
+struct suspend_always {
+  bool await_ready() noexcept { return false; }
+  template 
+  void await_suspend(F) noexcept;
+  void await_resume() noexcept {}
+};
+
+namespace std {
+template 
+struct coroutine_handle {};
+}
+
+struct bad_promise_6 {
+  coro get_return_object();
+  suspend_always initial_suspend();
+  suspend_always final_suspend() noexcept;
+  void unhandled_exception();
+  void return_void();
+  void return_value(int) const;
+  void return_value(int);
+};
+
+coro
+bad_implicit_return() // { dg-error {.aka 'bad_promise_6'. declares both 
'return_value' and 'return_void'} }
+{
+  co_await a;
+}
-- 
2.24.3 (Apple Git-128)

[PATCH] c++, coroutines: Make sure our temporaries are in a bind expr [PR105287]

[Iain Sandoe via Gcc-patches]

There are a few cases where we can generate a temporary that does not need
to be added to the coroutine frame (i.e. these are genuinely ephemeral).  The
intent was that unnamed temporaries should not be 'promoted' to coroutine
frame entries.  However there was a thinko and these were not actually ever
added to the bind expressions being generated for the expanded awaits.  This
meant that they were showing in the global namspace, leading to an empty
DECL_CONTEXT and the ICE reported.

tested on x86_64-darwin, OK for mainline? / Backports? (when?)
thanks,
Iain

Signed-off-by: Iain Sandoe 

PR c++/105287

gcc/cp/ChangeLog:

* coroutines.cc (maybe_promote_temps): Ensure generated temporaries
are added to the bind expr.
(add_var_to_bind): Fix local var naming to use portable punctuation.
(register_local_var_uses): Do not add synthetic names to unnamed
temporaries.

gcc/testsuite/ChangeLog:

* g++.dg/coroutines/pr105287.C: New test.
---
 gcc/cp/coroutines.cc   | 17 
 gcc/testsuite/g++.dg/coroutines/pr105287.C | 48 ++
 2 files changed, 56 insertions(+), 9 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/coroutines/pr105287.C

diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index a9ce6e050dd..dcc2284171b 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -3103,7 +3103,7 @@ maybe_promote_temps (tree *stmt, void *d)
 If the initializer is a conditional expression, we need to collect
 and declare any promoted variables nested within it.  DTORs for such
 variables must be run conditionally too.  */
-  if (t->var && DECL_NAME (t->var))
+  if (t->var)
{
  tree var = t->var;
  DECL_CHAIN (var) = vlist;
@@ -3304,7 +3304,7 @@ add_var_to_bind (tree& bind, tree var_type,
   tree b_vars = BIND_EXPR_VARS (bind);
   /* Build a variable to hold the condition, this will be included in the
  frame as a local var.  */
-  char *nam = xasprintf ("%s.%d", nam_root, nam_vers);
+  char *nam = xasprintf ("`__%s_%d", nam_root, nam_vers);
   tree newvar = build_lang_decl (VAR_DECL, get_identifier (nam), var_type);
   free (nam);
   DECL_CHAIN (newvar) = b_vars;
@@ -3949,7 +3949,7 @@ register_local_var_uses (tree *stmt, int *do_subtree, 
void *d)
 scopes with identically named locals and still be able to
 identify them in the coroutine frame.  */
  tree lvname = DECL_NAME (lvar);
- char *buf;
+ char *buf = NULL;
 
  /* The outermost bind scope contains the artificial variables that
 we inject to implement the coro state machine.  We want to be able
@@ -3959,14 +3959,13 @@ register_local_var_uses (tree *stmt, int *do_subtree, 
void *d)
  else if (lvname != NULL_TREE)
buf = xasprintf ("%s_%u_%u", IDENTIFIER_POINTER (lvname),
 lvd->nest_depth, lvd->bind_indx);
- else
-   buf = xasprintf ("_D%u_%u_%u", DECL_UID (lvar), lvd->nest_depth,
-lvd->bind_indx);
  /* TODO: Figure out if we should build a local type that has any
 excess alignment or size from the original decl.  */
- local_var.field_id
-   = coro_make_frame_entry (lvd->field_list, buf, lvtype, lvd->loc);
- free (buf);
+ if (buf) {
+   local_var.field_id
+ = coro_make_frame_entry (lvd->field_list, buf, lvtype, lvd->loc);
+   free (buf);
+ }
  /* We don't walk any of the local var sub-trees, they won't contain
 any bind exprs.  */
}
diff --git a/gcc/testsuite/g++.dg/coroutines/pr105287.C 
b/gcc/testsuite/g++.dg/coroutines/pr105287.C
new file mode 100644
index 000..9790945287d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/coroutines/pr105287.C
@@ -0,0 +1,48 @@
+// { dg-additional-options "-fanalyzer" }
+// { dg-excess-errors "lots of analyzer output, but no ICE" }
+namespace std {
+template  struct coroutine_traits : _Result {};
+template  struct coroutine_handle {
+  operator coroutine_handle<>();
+};
+}
+struct coro1 {
+  using handle_type = std::coroutine_handle<>;
+  coro1(handle_type);
+  struct suspend_always_prt {
+bool await_ready() noexcept;
+void await_suspend(handle_type) noexcept;
+void await_resume() noexcept;
+  };
+  struct promise_type {
+std::coroutine_handle<> ch_;
+auto get_return_object() { return ch_; }
+auto initial_suspend() { return suspend_always_prt{}; }
+auto final_suspend() noexcept { return suspend_always_prt{}; }
+void unhandled_exception();
+  };
+};
+struct BoolAwaiter {
+  BoolAwaiter(bool);
+  bool await_ready();
+  void await_suspend(std::coroutine_handle<>);
+  bool await_resume();
+};
+struct IntAwaiter {
+  IntAwaiter(int);
+  bool await_ready();
+  void await_suspend(std::coroutine_handle<>);
+  int await_resume();
+};
+coro1 my_coro() {
+ int a = 1;
+ if (a 

Re: [PATCH] c++: Fix up CONSTRUCTOR_PLACEHOLDER_BOUNDARY handling [PR105256]

[Patrick Palka via Gcc-patches]

On Sun, Apr 17, 2022 at 6:24 PM Jason Merrill  wrote:
>
> On 4/15/22 07:22, Jakub Jelinek wrote:
> > Hi!
> >
> > The CONSTRUCTOR_PLACEHOLDER_BOUNDARY bit is supposed to separate
> > PLACEHOLDER_EXPRs that should be replaced by one object or subobjects of it
> > (variable, TARGET_EXPR slot, ...) from other PLACEHOLDER_EXPRs that should
> > be replaced by different objects or subobjects.
> > The bit is set when finding PLACEHOLDER_EXPRs inside of a CONSTRUCTOR, not
> > looking into nested CONSTRUCTOR_PLACEHOLDER_BOUNDARY ctors, and we prevent
> > elision of TARGET_EXPRs (through TARGET_EXPR_NO_ELIDE) whose initializer
> > is a CONSTRUCTOR_PLACEHOLDER_BOUNDARY ctor.  The following testcase ICEs
> > though, we don't replace the placeholders in there at all, because
> > CONSTRUCTOR_PLACEHOLDER_BOUNDARY isn't set on the TARGET_EXPR_INITIAL
> > ctor, but on a ctor nested in such a ctor.  replace_placeholders should be
> > run on the whole TARGET_EXPR slot.
> >
> > So, the following patch fixes it by moving the 
> > CONSTRUCTOR_PLACEHOLDER_BOUNDARY
> > bit from nested CONSTRUCTORs to the CONSTRUCTOR containing those (but only
> > if it is closely nested, if there is some other tree sandwiched in between,
> > it doesn't do it).
>
> Hmm, Patrick made a similar change and then reverted it for PR90996.
> But it makes sense to me; when we replace placeholders, it's appropriate
> to look at the whole aggregate initialization rather than the innermost
> CONSTRUCTOR that has DMIs.  Patrick, was there a reason that change
> seemed wrong to you, or was it just unnecessary for the bug you were
> working on?

That change was just not strictly necessary for PR90996 I think.  For
that testcase:

struct S {
  int & = 2;
  int b[1] {a};
};

S c[] {{2}};

we first call replace_placeholders from store_init_value for the
overall initiializer for c

  {{.a=(int &) &_ZGR1c_, .b={*(&)->a}}

but CONSTRUCTOR_PLACEHOLDER_BOUNDARY set on the middle pair of {}
prevents the placeholder from being resolved to c[0].  The reverted
change would have allowed us to resolve the placeholder at this point,
since the flag would have been moved to the outermost {} IIUC.

But fortunately split_nonconstant_init then factors out the
initialization of c[0].b into an INIT_EXPR:

  c[0].b[0] = *(&)->a;

during gimplification of which we attempt replace_placeholders again
which succeeds this time at resolving the placeholder, due to the
other change in r10-7587 that made replace_placeholders look through
all handled components, not just COMPONENT_REF (mirroring
replace_placeholders_r).

So I reverted the rest of r10-7587 after Martin noticed it had no
effect: https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543918.html

The reverted change and Jakub's more general patch seem right/safe to
me FWIW, I just couldn't come up with a testcase that demonstrated its
need at the time unfortunately.



>
> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> >
> > 2022-04-15  Jakub Jelinek  
> >
> >   PR c++/105256
> >   * typeck2.cc (process_init_constructor_array,
> >   process_init_constructor_record, process_init_constructor_union): Move
> >   CONSTRUCTOR_PLACEHOLDER_BOUNDARY flag from CONSTRUCTOR elements to the
> >   containing CONSTRUCTOR.
> >
> >   * g++.dg/cpp0x/pr105256.C: New test.
> >
> > --- gcc/cp/typeck2.cc.jj  2022-04-07 09:09:54.432995137 +0200
> > +++ gcc/cp/typeck2.cc 2022-04-14 16:02:12.438432494 +0200
> > @@ -1515,6 +1515,14 @@ process_init_constructor_array (tree typ
> > strip_array_types (TREE_TYPE (ce->value);
> >
> > picflags |= picflag_from_initializer (ce->value);
> > +  /* Propagate CONSTRUCTOR_PLACEHOLDER_BOUNDARY to outer
> > +  CONSTRUCTOR.  */
> > +  if (TREE_CODE (ce->value) == CONSTRUCTOR
> > +   && CONSTRUCTOR_PLACEHOLDER_BOUNDARY (ce->value))
> > + {
> > +   CONSTRUCTOR_PLACEHOLDER_BOUNDARY (init) = 1;
> > +   CONSTRUCTOR_PLACEHOLDER_BOUNDARY (ce->value) = 0;
> > + }
> >   }
> >
> > /* No more initializers. If the array is unbounded, we are done. 
> > Otherwise,
> > @@ -1560,6 +1568,14 @@ process_init_constructor_array (tree typ
> > }
> >
> >   picflags |= picflag_from_initializer (next);
> > + /* Propagate CONSTRUCTOR_PLACEHOLDER_BOUNDARY to outer
> > +CONSTRUCTOR.  */
> > + if (TREE_CODE (next) == CONSTRUCTOR
> > + && CONSTRUCTOR_PLACEHOLDER_BOUNDARY (next))
> > +   {
> > + CONSTRUCTOR_PLACEHOLDER_BOUNDARY (init) = 1;
> > + CONSTRUCTOR_PLACEHOLDER_BOUNDARY (next) = 0;
> > +   }
> >   if (len > i+1)
> > {
> >   tree range = build2 (RANGE_EXPR, size_type_node,
> > @@ -1754,6 +1770,13 @@ process_init_constructor_record (tree ty
> > if (fldtype != TREE_TYPE (field))
> >   next = cp_convert_and_check (TREE_TYPE (field), next, complain);
> > picflags |= 

[Bug c++/105301] [11/12 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'overload' in coro_promise_type_found_p, at cp/coroutines.cc:516

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |11.3
Summary|[12 Regression] ICE: tree   |[11/12 Regression] ICE:
   |check: expected tree that   |tree check: expected tree
   |contains 'decl minimal' |that contains 'decl
   |structure, have 'overload'  |minimal' structure, have
   |in  |'overload' in
   |coro_promise_type_found_p,  |coro_promise_type_found_p,
   |at cp/coroutines.cc:516 |at cp/coroutines.cc:516
 CC||jakub at gcc dot gnu.org
   Priority|P3  |P2

--- Comment #1 from Jakub Jelinek  ---
Started to ICE with r11-431-g29f0e90d9904d8e0965443d4da4c95ddde5edb1e in
fold_builtin*, and since r11-4076-gb003c4b14b3f889e6707db68d2c6545eda7a203b
ICEs in checking from coro_promise_type_found_p.

[Bug target/105292] [sparc64] ICE in expand_expr_real_2 on sparc64 when compiling with -mcpu=niagara4

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #1 from Mikael Pettersson  ---
I can reproduce with a gcc-11.2.0 cross to sparc64-linux-gnu. ICEs with -mcpu
selecting ultrasparc3 or niagara[2347]. Doesn't ice if -mcpu select plain
ultrasparc or niagara. Also doesn't ICE if -O3 is reduced to -O2.

Still ICEs with gcc-12-20220417.

[Bug c++/105301] [12 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'overload' in coro_promise_type_found_p, at cp/coroutines.cc:516

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

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

Iain Sandoe  changed:

   What|Removed |Added

   Last reconfirmed||2022-04-18
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |iains at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

[Bug go/105302] gccgo for Windows using MinGW-w64

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

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

--- Comment #1 from Brecht Sanders  
---
P.S.: This attempt was with snapshot version 12-20220417

[Bug go/105302] New: gccgo for Windows using MinGW-w64

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

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

Bug ID: 105302
   Summary: gccgo for Windows using MinGW-w64
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: brechtsanders at users dot sourceforge.net
CC: cmang at google dot com
  Target Milestone: ---

I thought I's give building gccgo for Windows using MinGW-w64 another try.

First of all I had to change `configure` to allow me to do that:
```
patch -ulbf configure << EOF
@@ -3577,3 +3577,3 @@
 case "\${target}" in
-*-*-darwin* | *-*-cygwin* | *-*-mingw* | bpf-* )
+*-*-darwin* | *-*-cygwin* | bpf-* )
 unsupported_languages="\$unsupported_languages go"
@@ -3609,3 +3609,3 @@
;;
-*-*-cygwin* | *-*-mingw*)
+*-*-cygwin*)
noconfigdirs="\$noconfigdirs target-libgo"
EOF
```

Then I added `go` to `--enable-languages=` and I added `--enable-libgo` to the
`./configure` line.

It got pretty far this time, and I actually go a working `gccgo.exe`, but libgo
wasn't such a success:
```
libtool: compile: 
/d/Prog/winlibs64-11.2.0ucrt/home/gcc-12-20220417/build_mingw/./gcc/gccgo
-B/d/Prog/winlibs64-11.2.0ucrt/home/gcc-12-20220417/build_mingw/./gcc/
-L/R/winlibs64-11.2.0ucrt/inst_gcc-12-20220417/share/gcc/x86_64-w64-mingw32/lib
-L/R/winlibs64-11.2.0ucrt/inst_gcc-12-20220417/share/gcc/mingw/lib -isystem
/R/winlibs64-11.2.0ucrt/inst_gcc-12-20220417/share/gcc/x86_64-w64-mingw32/include
-isystem /R/winlibs64-11.2.0ucrt/inst_gcc-12-20220417/share/gcc/mingw/include
-B/R/winlibs64-11.2.0ucrt/inst_gcc-12-20220417/share/gcc/x86_64-w64-mingw32/bin/
-B/R/winlibs64-11.2.0ucrt/inst_gcc-12-20220417/share/gcc/x86_64-w64-mingw32/lib/
-isystem
/R/winlibs64-11.2.0ucrt/inst_gcc-12-20220417/share/gcc/x86_64-w64-mingw32/include
-isystem
/R/winlibs64-11.2.0ucrt/inst_gcc-12-20220417/share/gcc/x86_64-w64-mingw32/sys-include
--sysroot=/d/Prog/winlibs64-11.2.0ucrt/home/gcc-12-20220417/build_mingw/mingw-w64
-minline-all-stringops -O2 -g -I . -c -fgo-pkgpath=internal/bytealg
../../../libgo/go/internal/bytealg/bytealg.go
../../../libgo/go/internal/bytealg/compare_native.go
../../../libgo/go/internal/bytealg/count_generic.go
../../../libgo/go/internal/bytealg/equal_generic.go
../../../libgo/go/internal/bytealg/equal_native.go
../../../libgo/go/internal/bytealg/gccgo.go
../../../libgo/go/internal/bytealg/index_native.go
../../../libgo/go/internal/bytealg/indexbyte_native.go  -DDLL_EXPORT -o
internal/.libs/bytealg.o
../../../libgo/go/internal/bytealg/bytealg.go:8:21: warning: ./internal/cpu:
Permission denied
8 | "internal/cpu"
  | ^
../../../libgo/go/internal/bytealg/bytealg.go:8:21: error: error in import data
at 2329: invalid magic string
```

I feel we're getting closer. Any idea what caused this error?

[Bug c++/105301] New: [12 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'overload' in coro_promise_type_found_p, at cp/coroutines.cc:516

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 105301
   Summary: [12 Regression] ICE: tree check: expected tree that
contains 'decl minimal' structure, have 'overload' in
coro_promise_type_found_p, at cp/coroutines.cc:516
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: C++-Coroutine, ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
CC: iains at gcc dot gnu.org
  Target Milestone: ---

Created attachment 52825
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52825=edit
Testcase

g++ 12.0.1 20220417 snapshot (g:000c1b89d259fadb466e1f2e63c79da45fd17372) ICEs
when compiling the attached testcase, reduced from
clang/testsuite/SemaCXX/coroutines.cpp from the clang 14.0.1 test suite, w/
-fcoroutines:

% g++-12.0.1 -fcoroutines -c lvhljakz.cpp
lvhljakz.cpp: In function 'coro bad_implicit_return()':
lvhljakz.cpp:43:21: error: the coroutine promise type
'std::coroutine_traits >::promise_type' {aka
'bad_promise_6'} declares both 'return_value' and 'return_void'
   43 | coro bad_implicit_return() { co_await a; }
  | ^~~
lvhljakz.cpp:39:8: note: 'return_void' declared here
   39 |   void return_void();
  |^~~
lvhljakz.cpp:43:54: internal compiler error: tree check: expected tree that
contains 'decl minimal' structure, have 'overload' in
coro_promise_type_found_p, at cp/coroutines.cc:516
   43 | coro bad_implicit_return() { co_await a; }
  |  ^
0x8796d0 tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220417/work/gcc-12-20220417/gcc/tree.cc:8972
0x692cd6 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220417/work/gcc-12-20220417/gcc/tree.h:3571
0x692cd6 coro_promise_type_found_p
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220417/work/gcc-12-20220417/gcc/cp/coroutines.cc:516
0x9b2693 finish_co_await_expr(unsigned int, tree_node*)
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220417/work/gcc-12-20220417/gcc/cp/coroutines.cc:1165
0xaf9271 cp_parser_unary_expression
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220417/work/gcc-12-20220417/gcc/cp/parser.cc:8866
0xac7237 cp_parser_binary_expression
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220417/work/gcc-12-20220417/gcc/cp/parser.cc:10035
0xac7e2e cp_parser_assignment_expression
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220417/work/gcc-12-20220417/gcc/cp/parser.cc:10339
0xac991c cp_parser_expression
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220417/work/gcc-12-20220417/gcc/cp/parser.cc:10509
0xacd017 cp_parser_expression_statement
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220417/work/gcc-12-20220417/gcc/cp/parser.cc:12705
0xada2ca cp_parser_statement
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220417/work/gcc-12-20220417/gcc/cp/parser.cc:12501
0xadb45d cp_parser_statement_seq_opt
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220417/work/gcc-12-20220417/gcc/cp/parser.cc:12850
0xadb537 cp_parser_compound_statement
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220417/work/gcc-12-20220417/gcc/cp/parser.cc:12802
0xafc145 cp_parser_function_body
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220417/work/gcc-12-20220417/gcc/cp/parser.cc:25069
0xafc145 cp_parser_ctor_initializer_opt_and_function_body
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220417/work/gcc-12-20220417/gcc/cp/parser.cc:25120
0xafd0fa cp_parser_function_definition_after_declarator
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220417/work/gcc-12-20220417/gcc/cp/parser.cc:31251
0xafe3b8 cp_parser_function_definition_from_specifiers_and_declarator
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220417/work/gcc-12-20220417/gcc/cp/parser.cc:31167
0xafe3b8 cp_parser_init_declarator
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220417/work/gcc-12-20220417/gcc/cp/parser.cc:22591
0xad7ee9 cp_parser_simple_declaration
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220417/work/gcc-12-20220417/gcc/cp/parser.cc:15280
0xb09675 cp_parser_declaration
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220417/work/gcc-12-20220417/gcc/cp/parser.cc:14966
0xb0a039 cp_parser_toplevel_declaration
   
/var/tmp/portage/sys-devel/gcc-12.0.1_p20220417/work/gcc-12-20220417/gcc/cp/parser.cc:14987