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

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code

--- Comment #4 from Jakub Jelinek  ---
Another reduction, which is accepted by g++ 7.x and clang++ and ICEs the same
way by 8-trunk:
template  using a = int;
template  struct b;
template  struct c;
template  struct i;
template  using e = typename i::f;
template  using g = e::h>;
template  struct j;
template  struct k {
  static long o();
  template  using n = a::den>;
  template , l struct q {};
};

Re: [PATCH] aarch64: Fix up 2 other combine opt regressions vs. GCC8 [PR100075]

[Richard Sandiford via Gcc-patches]

Jakub Jelinek  writes:
> --- gcc/config/aarch64/aarch64.md.jj  2021-04-15 10:45:02.798853095 +0200
> +++ gcc/config/aarch64/aarch64.md 2021-04-15 13:28:04.734754364 +0200
> @@ -3572,6 +3572,18 @@ (define_insn "*neg__si2_uxtw"
>[(set_attr "autodetect_type" "alu_shift__op2")]
>  )
>  
> +(define_insn "*neg_asr_si2_extr"
> +  [(set (match_operand:SI 0 "register_operand" "r")
> + (neg:SI (match_operator 4 "subreg_lowpart_operator"

Very minor, but it might be better to have the :SI on the match_operator
too, like in the pattern below.

> +   [(sign_extract:DI
> +  (match_operand:DI 1 "register_operand" "r")
> +  (match_operand 3 "aarch64_simd_shift_imm_offset_si" "n")
> +  (match_operand 2 "aarch64_simd_shift_imm_offset_si" 
> "n"))])))]
> +  "INTVAL (operands[2]) + INTVAL (operands[3]) == 32"
> +  "neg\\t%w0, %w1, asr %2"
> +  [(set_attr "autodetect_type" "alu_shift_asr_op2")]
> +)
> +
>  (define_insn "mul3"
>[(set (match_operand:GPI 0 "register_operand" "=r")
>   (mult:GPI (match_operand:GPI 1 "register_operand" "r")
> @@ -5382,6 +5394,22 @@ (define_insn "*extrsi5_insn_uxtw_alt"
>"extr\\t%w0, %w1, %w2, %4"
>[(set_attr "type" "rotate_imm")]
>  )
> +
> +(define_insn "*extrsi5_insn_di"
> +  [(set (match_operand:SI 0 "register_operand" "=r")
> + (ior:SI (ashift:SI (match_operand:SI 1 "register_operand" "r")
> +(match_operand 3 "const_int_operand" "n"))
> + (match_operator:SI 6 "subreg_lowpart_operator"
> +   [(zero_extract:DI
> +  (match_operand:DI 2 "register_operand" "r")
> +  (match_operand 5 "const_int_operand" "n")
> +  (match_operand 4 "const_int_operand" "n"))])))]
> +  "UINTVAL (operands[3]) < 32
> +   && UINTVAL (operands[3]) + UINTVAL (operands[4]) == 32
> +   && UINTVAL (operands[4]) + UINTVAL (operands[5]) - 32 <= 64"

Could you explain this condition?  With operand 5 being the size
and operand 4 being the position, I was expecting something like:

  "UINTVAL (operands[3]) < 32
   && UINTVAL (operands[3]) == UINTVAL (operands[5])
   && UINTVAL (operands[4]) + UINTVAL (operands[5]) == 32"

i.e. the %w1 shift must equal the size of the %w2 extraction
and the %w2 extraction must align with the top of the register.
Or, writing it in more the style of the original condition,
the final line would be:

   && UINTVAL (operands[3]) == UINTVAL (operands[5])"

instead of:

   && UINTVAL (operands[4]) + UINTVAL (operands[5]) - 32 <= 64"

Not tested though, and it's late, so I could have got that completely
wrong :-)

Thanks,
Richard

> +  "extr\\t%w0, %w1, %w2, %4"
> +  [(set_attr "type" "rotate_imm")]
> +)
>  
>  (define_insn "*ror3_insn"
>[(set (match_operand:GPI 0 "register_operand" "=r")
> --- gcc/testsuite/gcc.target/aarch64/pr100075.c.jj2021-04-15 
> 13:23:31.188852983 +0200
> +++ gcc/testsuite/gcc.target/aarch64/pr100075.c   2021-04-15 
> 13:23:10.612086048 +0200
> @@ -0,0 +1,20 @@
> +/* PR target/100075 */
> +/* { dg-do compile } */
> +/* { dg-options "-O2" } */
> +/* { dg-final { scan-assembler-not {\tsbfx\tx[0-9]+, x[0-9]+, 16, 16} } } */
> +/* { dg-final { scan-assembler {\tneg\tw[0-9]+, w[0-9]+, asr 16} } } */
> +/* { dg-final { scan-assembler {\textr\tw[0-9]+, w[0-9]+, w[0-9]+, 16} } } */
> +
> +struct S { short x, y; };
> +
> +struct S
> +f1 (struct S p)
> +{
> +  return (struct S) { -p.y, p.x };
> +}
> +
> +struct S
> +f2 (struct S p)
> +{
> +  return (struct S) { p.y, -p.x };
> +}
>
>   Jakub

[Bug c++/100104] New: std::transform is 1.5 times faster than std::copy with -O3

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 100104
   Summary: std::transform is 1.5 times faster than std::copy with
-O3
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

Consider:

std::vector v1(100, 0);

// copy using copy
std::vector v2;
std::copy(v1.begin(), v1.end(), std::back_inserter(v2));

// copy using transform
std::vector v2;
std::transform(v1.begin(), v1.end(), std::back_inserter(v2), [](auto x) {
return x; });

Those two will generate similar assembly code under -O2, but is very different
under -O3/-Ofast, and transform will be 1.5 times faster than the copy. I don’t
know if this is a bug since these two represent the same thing, and correct me
if I am wrong.

quick-bench with -O2:
https://quick-bench.com/q/uKT8QEmPkS1wr153s3P-DRt90eY
quick-bench with -O3:
https://quick-bench.com/q/syuBCQYVtCoVwT2MRtLT25P-MQI
goldbot: 
https://godbolt.org/z/7ee77cs8W

[Bug target/100099] Compilation speed of #include is too slow. Just include the header takes 0.342 seconds

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||compile-time-hog
  Component|preprocessor|target
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-04-15
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
One thing which could be done is similar to what AARCH64 did for SVE/SVE2
builtins and just implement the majority of the intrinsics in the front-end.

The aarch64 target does this in the user include header:
#pragma GCC aarch64 "arm_sve.h"
Which just interjects the intrinsics as builtins at that point.

Re: [PATCH v2] x86: Use crc32 target option for CRC32 intrinsics

[Uros Bizjak via Gcc-patches]

On Thu, Apr 15, 2021 at 6:51 PM H.J. Lu  wrote:
>
> On Thu, Apr 15, 2021 at 9:34 AM Uros Bizjak  wrote:
> >
> > On Thu, Apr 15, 2021 at 6:26 PM H.J. Lu  wrote:
> > >
> > > On Thu, Apr 15, 2021 at 9:14 AM Uros Bizjak  wrote:
> > > >
> > > > On Thu, Apr 15, 2021 at 5:11 PM H.J. Lu  wrote:
> > > > >
> > > > > Use crc32 target option for CRC32 intrinsics to support CRC32 
> > > > > intrinsics
> > > > > without enabling SSE vector instructions.
> > > >
> > > > There is no CRC32 ISA. crc32 is part of SSE4.2 [1] and current
> > > > situation reflects that correctly.
> > >
> > > CRC32 is similar to POPCNT which was originally in SSE4.2.   Now POPCNT
> >
> > It is not similar, POPCNT has its own CPUID flag and can be enabled
> > independently of SSE4.2.
> >
> > > is a separate feature which is also enabled by SSE4.2.   Enable CRC32 only
> > > with SSE4.2 makes it impossible to use CRC32 with -mgeneral-regs-only.   
> > > This
> > > patch addresses this issue the same way as POPCNT.
> >
> > CRC32 doesn't have its own CPUID flag, so PTA_CRC32 is pointless.
>
> PTA_CRC32 shouldn't be added.
>
> > OTOH, the situation is similar with MONITOR and MWAIT. These are
>
> There are no intrinsics for  MONITOR nor MWAIT.
>
> > enabled with SSE3 and don't use XMM registers. Also somewhat similar
> > is FISTTP, but there is no intrinsic for this insn.
>
> True.
>
> Here is the v2 patch without PTA_CRC32.

--- a/gcc/config/i386/gnu-property.c
+++ b/gcc/config/i386/gnu-property.c
@@ -92,6 +92,7 @@ file_end_indicate_exec_stack_and_gnu_property (void)
   /* GNU_PROPERTY_X86_ISA_1_V2.  */
   if (TARGET_CMPXCHG16B
   || (TARGET_64BIT && TARGET_SAHF)
+  || TARGET_CRC32
   || TARGET_POPCNT
   || TARGET_SSE3
   || TARGET_SSSE3

This is not needed. CRC32 is not an ISA, and if someone uses
-mx86-64-v2 -mno-crc32 it does what the documentation says - disables
builtin function.

Otherwise OK, but please also obtain RM's approval at this stage.

Thanks,
Uros.

> --
> H.J.

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

[omer.rosler at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Omer Rosler  ---
It seems that 

Reduced:

template
struct A
{
constexpr A(int) {}
};

A(int) -> A;


template //template works fine
struct B 
{
template
B(T);
};

template
B(T) -> B; //see below


int main()
{
B t(42);
}


specifying A explicitly also works, it's the deduction that triggers the bug

If the initializer of `A` is not dependent on the template parameter of the
guide (i.e `T`) than the bug isn't showing

[PATCH] testsuite: Enable zero-scratch-regs-{8,9,10,11}.c on s390*

[Stefan Schulze Frielinghaus via Gcc-patches]

On s390* the only missing part for the mentioned testcases was a load of
a double floating-point zero via a move (in particular for quite old
machines) which was added in commit 46c47420a5fefd4d9d02b0db347235dd74e20fb2.
Common code implementation is sufficient in order to clear volatile
GPRs, FPRs, and VRs.  Access registers a0 and a1 are nonvolatile and not
cleared.  Therefore, target hook TARGET_ZERO_CALL_USED_REGS is not
implemented for s390*.

Added a target specific test in order to ensure that all call clobbered
GPRs, FPRs, and VRs are zeroed and all call saved registers are kept.

Ok for mainline?

gcc/testsuite/ChangeLog:

* c-c++-common/zero-scratch-regs-8.c: Enable on s390*.
* c-c++-common/zero-scratch-regs-9.c: Likewise.
* c-c++-common/zero-scratch-regs-10.c: Likewise.
* c-c++-common/zero-scratch-regs-11.c: Likewise.
* gcc.target/s390/zero-scratch-regs-1.c: New test.
---
 .../c-c++-common/zero-scratch-regs-10.c   |  2 +-
 .../c-c++-common/zero-scratch-regs-11.c   |  2 +-
 .../c-c++-common/zero-scratch-regs-8.c|  2 +-
 .../c-c++-common/zero-scratch-regs-9.c|  2 +-
 .../gcc.target/s390/zero-scratch-regs-1.c | 65 +++
 5 files changed, 69 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/s390/zero-scratch-regs-1.c

diff --git a/gcc/testsuite/c-c++-common/zero-scratch-regs-10.c 
b/gcc/testsuite/c-c++-common/zero-scratch-regs-10.c
index ab17143bc4b..96e0b79b328 100644
--- a/gcc/testsuite/c-c++-common/zero-scratch-regs-10.c
+++ b/gcc/testsuite/c-c++-common/zero-scratch-regs-10.c
@@ -1,5 +1,5 @@
 /* { dg-do run } */
-/* { dg-skip-if "not implemented" { ! { i?86*-*-* x86_64*-*-* sparc*-*-* 
aarch64*-*-* nvptx*-*-* } } } */
+/* { dg-skip-if "not implemented" { ! { i?86*-*-* x86_64*-*-* sparc*-*-* 
aarch64*-*-* nvptx*-*-* s390*-*-* } } } */
 /* { dg-options "-O2" } */
 
 #include 
diff --git a/gcc/testsuite/c-c++-common/zero-scratch-regs-11.c 
b/gcc/testsuite/c-c++-common/zero-scratch-regs-11.c
index 6642a377798..0714f95a04f 100644
--- a/gcc/testsuite/c-c++-common/zero-scratch-regs-11.c
+++ b/gcc/testsuite/c-c++-common/zero-scratch-regs-11.c
@@ -1,5 +1,5 @@
 /* { dg-do run } */
-/* { dg-skip-if "not implemented" { ! { i?86*-*-* x86_64*-*-* sparc*-*-* 
aarch64*-*-* arm*-*-* nvptx*-*-* } } } */
+/* { dg-skip-if "not implemented" { ! { i?86*-*-* x86_64*-*-* sparc*-*-* 
aarch64*-*-* arm*-*-* nvptx*-*-* s390*-*-* } } } */
 /* { dg-options "-O2 -fzero-call-used-regs=all" } */
 
 #include "zero-scratch-regs-10.c"
diff --git a/gcc/testsuite/c-c++-common/zero-scratch-regs-8.c 
b/gcc/testsuite/c-c++-common/zero-scratch-regs-8.c
index 867c6bdce2c..aceda7e5cb8 100644
--- a/gcc/testsuite/c-c++-common/zero-scratch-regs-8.c
+++ b/gcc/testsuite/c-c++-common/zero-scratch-regs-8.c
@@ -1,5 +1,5 @@
 /* { dg-do run } */
-/* { dg-skip-if "not implemented" { ! { i?86*-*-* x86_64*-*-* sparc*-*-* 
aarch64*-*-* arm*-*-* nvptx*-*-* } } } */
+/* { dg-skip-if "not implemented" { ! { i?86*-*-* x86_64*-*-* sparc*-*-* 
aarch64*-*-* arm*-*-* nvptx*-*-* s390*-*-* } } } */
 /* { dg-options "-O2 -fzero-call-used-regs=all-arg" } */
 
 #include "zero-scratch-regs-1.c"
diff --git a/gcc/testsuite/c-c++-common/zero-scratch-regs-9.c 
b/gcc/testsuite/c-c++-common/zero-scratch-regs-9.c
index 4b45d7061df..f3152a7a732 100644
--- a/gcc/testsuite/c-c++-common/zero-scratch-regs-9.c
+++ b/gcc/testsuite/c-c++-common/zero-scratch-regs-9.c
@@ -1,5 +1,5 @@
 /* { dg-do run } */
-/* { dg-skip-if "not implemented" { ! { i?86*-*-* x86_64*-*-* sparc*-*-* 
aarch64*-*-* arm*-*-* nvptx*-*-* } } } */
+/* { dg-skip-if "not implemented" { ! { i?86*-*-* x86_64*-*-* sparc*-*-* 
aarch64*-*-* arm*-*-* nvptx*-*-* s390*-*-* } } } */
 /* { dg-options "-O2 -fzero-call-used-regs=all" } */
 
 #include "zero-scratch-regs-1.c"
diff --git a/gcc/testsuite/gcc.target/s390/zero-scratch-regs-1.c 
b/gcc/testsuite/gcc.target/s390/zero-scratch-regs-1.c
new file mode 100644
index 000..c394c4b69e7
--- /dev/null
+++ b/gcc/testsuite/gcc.target/s390/zero-scratch-regs-1.c
@@ -0,0 +1,65 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fzero-call-used-regs=all -march=z13" } */
+
+/* Ensure that all call clobbered GPRs, FPRs, and VRs are zeroed and all call
+   saved registers are kept. */
+
+void foo (void) { }
+
+/* { dg-final { scan-assembler-times "lhi\t" 6 { target { ! lp64 } } } } */
+/* { dg-final { scan-assembler "lhi\t%r0,0" { target { ! lp64 } } } } */
+/* { dg-final { scan-assembler "lhi\t%r1,0" { target { ! lp64 } } } } */
+/* { dg-final { scan-assembler "lhi\t%r2,0" { target { ! lp64 } } } } */
+/* { dg-final { scan-assembler "lhi\t%r3,0" { target { ! lp64 } } } } */
+/* { dg-final { scan-assembler "lhi\t%r4,0" { target { ! lp64 } } } } */
+/* { dg-final { scan-assembler "lhi\t%r5,0" { target { ! lp64 } } } } */
+
+/* { dg-final { scan-assembler-times "lzdr\t" 14 { target { ! lp64 } } } } */
+/* { dg-final { scan-assembler "lzdr\t%f0" { target { ! lp64 } } } } */
+/* 

Re: [PATCH] aarch64: Avoid duplicating bti j insns for jump tables [PR99988]

[Richard Sandiford via Gcc-patches]

Looks good in general, but like you say, it's GCC 12 material.

Alex Coplan  writes:
> diff --git a/gcc/config/aarch64/aarch64-bti-insert.c 
> b/gcc/config/aarch64/aarch64-bti-insert.c
> index 936649769c7..943fa3c1097 100644
> --- a/gcc/config/aarch64/aarch64-bti-insert.c
> +++ b/gcc/config/aarch64/aarch64-bti-insert.c
> @@ -120,6 +120,13 @@ aarch64_pac_insn_p (rtx x)
>return false;
>  }
>  
> +static bool
> +aarch64_bti_j_insn_p (rtx_insn *insn)
> +{
> +  rtx pat = PATTERN (insn);
> +  return GET_CODE (pat) == UNSPEC_VOLATILE && XINT (pat, 1) == UNSPECV_BTI_J;
> +}
> +

Nit, but even a simple function like this should have a comment. :-)

>  /* Insert the BTI instruction.  */
>  /* This is implemented as a late RTL pass that runs before branch
> shortening and does the following.  */
> @@ -165,6 +172,9 @@ rest_of_insert_bti (void)
> for (j = GET_NUM_ELEM (vec) - 1; j >= 0; --j)
>   {
> label = as_a  (XEXP (RTVEC_ELT (vec, j), 0));
> +   if (aarch64_bti_j_insn_p (next_nonnote_insn (label)))
> + continue;
> +

This should be next_nonnote_nondebug_insn (quite the mouthful),
otherwise debug instructions could affect the choice.

The thing returned by next_nonnote_nondebug_insn isn't in general
guaranteed to be an insn (unlike next_real_nondebug_insn).  It might
also be null in very odd cases.  I think we should therefore check
for null and INSN_P before checking PATTERN.

Thanks,
Richard

> bti_insn = gen_bti_j ();
> emit_insn_after (bti_insn, label);
>   }
> diff --git a/gcc/testsuite/gcc.target/aarch64/pr99988.c 
> b/gcc/testsuite/gcc.target/aarch64/pr99988.c
> new file mode 100644
> index 000..2d87f41a717
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/aarch64/pr99988.c
> @@ -0,0 +1,66 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -mbranch-protection=standard" } */
> +/* { dg-final { scan-assembler-times {bti j} 13 } } */
> +int a;
> +int c();
> +int d();
> +int e();
> +int f();
> +int g();
> +void h() {
> +  switch (a) {
> +  case 0:
> +  case 56:
> +  case 57:
> +break;
> +  case 58:
> +  case 59:
> +  case 61:
> +  case 62:
> +c();
> +  case 64:
> +  case 63:
> +d();
> +  case 66:
> +  case 65:
> +d();
> +  case 68:
> +  case 67:
> +d();
> +  case 69:
> +  case 70:
> +d();
> +  case 71:
> +  case 72:
> +  case 88:
> +  case 87:
> +d();
> +  case 90:
> +  case 89:
> +d();
> +  case 92:
> +  case 1:
> +d();
> +  case 93:
> +  case 73:
> +  case 4:
> +e();
> +  case 76:
> +  case 5:
> +f();
> +  case 7:
> +  case 8:
> +  case 84:
> +  case 85:
> +break;
> +  case 6:
> +  case 299:
> +  case 9:
> +  case 80:
> +  case 2:
> +  case 3:
> +e();
> +  default:
> +g();
> +  }
> +}

[Bug jit/100096] libgccjit.so.0: Cannot write-enable text segment: Permission denied on NetBSD 9.1

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

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

--- Comment #16 from David Malcolm  ---
(In reply to Sascha Wilde from comment #10)
> (In reply to David Malcolm from comment #8)
> > It would be good to know exactly where that error message is being emitted.
> > 
> > If you add:
> >   gcc_jit_context_set_logfile (ctxt, stderr, 0, 0);
> > to the test code (e.g. immediately after the call to
> > gcc_jit_context_acquire), libgccjit ought to spew out a copious amount of
> > logging (see
> > https://gcc.gnu.org/onlinedocs/jit/internals/index.html#example-of-log-file)
> > 
> > Can you attach the log you get please?
> 
> With security.pax.mprotect.global=1 it produces no extra output.
> I'll attach the output produced when security.pax.mprotect.global is
> disabled.

Thanks!  I was wondering if the error message was:
  (a) due to a problem dynamically linking libgccjit into the process, or
  (b) a later problem with linking the code that libgccjit generates into the
process.

Given that there's no extra log output at all with the protection flag, it
sounds like it's (a) - though you may run into a similar problem with (b)
if/when (a) gets solved.

Re: GCC association with the FSF

[Christopher Dimech via Gcc]

> Sent: Friday, April 16, 2021 at 4:24 AM
> From: "Richard Biener via Gcc" 
> To: "Jason Merrill" 
> Cc: "Thomas Koenig" , "gcc mailing list" 
> 
> Subject: Re: GCC association with the FSF
>
> On April 15, 2021 6:02:50 PM GMT+02:00, Jason Merrill  
> wrote:
> >On Wed, Apr 14, 2021 at 8:08 AM Richard Biener via Gcc
> > wrote:
> >> On April 14, 2021 12:19:16 PM GMT+02:00, Jonathan Wakely via Gcc
> > wrote:
> >> >N.B. Jeff is no longer @redhat.com so I've changed the CC
> >> >On Wed, 14 Apr 2021 at 11:03, Thomas Koenig 
> >> >wrote:
> >> >> - All gfortran developers move to the new branch.  This will not
> >> >>happen, I can guarantee you that.
> >> >
> >> >This is the part I'm curious about (the rest is obvious, it follows
> >> >from there being finite resources and the nature of any fork). But
> >I'm
> >> >not going to press for reasons.
> >>
> >> Note the only viable fork will be on the current hosting (which isn't
> >FSF controlled) with the downside of eventually losing the gcc.gnu.org
> >DNS and thus a need to "switch" to a sourceware.org name.
> >
> >It seems wrong to call such a scenario a fork.  If someone wanted to
> >fork GCC they are free to do so, but changing the relationship with
> >GNU/FSF is not a fork, as there would continue to be one primary
> >source repository.

Correct, but whatever happens, the association with RMS will remain.
Thusly the impasse is not going away.  A fork would work, but then
the secessionists' intention is to carry on with the Gcc tag, because
of its respected position in the world of science and technology.


> True. That's definitely better communication.
>
> Richard.
>
> >Jason
>
>

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

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|ICE in tsubst, at   |[8/9/10/11 Regression] ICE
   |cp/pt.c:15310   |in tsubst, at cp/pt.c:15310
   Target Milestone|--- |8.5
   Priority|P3  |P2
 CC||jason at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Started to ICE with r8-2724-g88b811bd29063036fd4536ee1312b1269cade6ed

[Bug tree-optimization/100102] ICE in tsubst, at cp/pt.c:15310

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Reduced testcase (though invalid):
template  using a = int;
template  struct b;
template  struct c {
  static long m_fn1();
  template  using d = a::den>;
  class e d;
};

Re: [PATCH v2] x86: Use crc32 target option for CRC32 intrinsics

[H.J. Lu via Gcc-patches]

On Thu, Apr 15, 2021 at 9:53 AM Uros Bizjak  wrote:
>
> On Thu, Apr 15, 2021 at 6:51 PM H.J. Lu  wrote:
> >
> > On Thu, Apr 15, 2021 at 9:34 AM Uros Bizjak  wrote:
> > >
> > > On Thu, Apr 15, 2021 at 6:26 PM H.J. Lu  wrote:
> > > >
> > > > On Thu, Apr 15, 2021 at 9:14 AM Uros Bizjak  wrote:
> > > > >
> > > > > On Thu, Apr 15, 2021 at 5:11 PM H.J. Lu  wrote:
> > > > > >
> > > > > > Use crc32 target option for CRC32 intrinsics to support CRC32 
> > > > > > intrinsics
> > > > > > without enabling SSE vector instructions.
> > > > >
> > > > > There is no CRC32 ISA. crc32 is part of SSE4.2 [1] and current
> > > > > situation reflects that correctly.
> > > >
> > > > CRC32 is similar to POPCNT which was originally in SSE4.2.   Now POPCNT
> > >
> > > It is not similar, POPCNT has its own CPUID flag and can be enabled
> > > independently of SSE4.2.
> > >
> > > > is a separate feature which is also enabled by SSE4.2.   Enable CRC32 
> > > > only
> > > > with SSE4.2 makes it impossible to use CRC32 with -mgeneral-regs-only.  
> > > >  This
> > > > patch addresses this issue the same way as POPCNT.
> > >
> > > CRC32 doesn't have its own CPUID flag, so PTA_CRC32 is pointless.
> >
> > PTA_CRC32 shouldn't be added.
> >
> > > OTOH, the situation is similar with MONITOR and MWAIT. These are
> >
> > There are no intrinsics for  MONITOR nor MWAIT.
>
> pmmintrin.h:
>
> extern __inline void __attribute__((__gnu_inline__, __always_inline__,
> __artificial__))
> _mm_monitor (void const * __P, unsigned int __E, unsigned int __H)
> {
>   __builtin_ia32_monitor (__P, __E, __H);
> }
>
> extern __inline void __attribute__((__gnu_inline__, __always_inline__,
> __artificial__))
> _mm_mwait (unsigned int __E, unsigned int __H)
> {
>   __builtin_ia32_mwait (__E, __H);
> }

They can be moved to mwaitintrin.h with -mmwait.

> >
> > > enabled with SSE3 and don't use XMM registers. Also somewhat similar
> > > is FISTTP, but there is no intrinsic for this insn.
> >
> > True.
> >
> > Here is the v2 patch without PTA_CRC32.
> >
> > --
> > H.J.



-- 
H.J.

Re: removing toxic emailers

[David Malcolm via Gcc]

On Thu, 2021-04-15 at 09:49 -0400, Eric S. Raymond wrote:
> Joseph Myers :
> > On Wed, 14 Apr 2021, Eric S. Raymond wrote:
> > 
> > > I'm not judging RMS's behavior (or anyone else's) one way or
> > > another. I am simply pointing out that there is a Schelling point
> > > in
> > > possible community norms that is well expressed as "you shall judge
> > > by
> > > the code alone".  This list is not full of contention from
> > > affirming
> > > that norm, but from some peoples' attempt to repudiate it.
> > 
> > Since RMS, FSF and GNU are not contributing code to the toolchain and
> > haven't been for a very long time, the most similar basis to judge
> > them 
> > would seem to be based on their interactions with toolchain
> > development.  
> > I think those interactions generally show that FSF and GNU have been
> > bad 
> > umbrella organizations for the toolchain since at least when the GCC
> > 4.4 
> > release was delayed waiting for a slow process of developing the GCC 
> > Runtime Library Exception.
> 
> I do not have standing to argue this point.
> 
> I will, however, point out that it is a very *different* point from
> "RMS has iupset some people and should therefore be canceled".

[I'm sorry to everyone who's sick of these threads, but I feel I have
to respond to this one; sorry about writing another long email]

Eric: I don't know if you're just being glib, or you're deliberately
trying to caricature those of us who are upset by RMS's behavior.

I think the words "canceled" and "cancel culture" have effectively
become meaningless and should be avoided if we want to have a nuanced
discussion - no-one seems to have a definition of what counts as
"canceling" vs "consequences" vs "fair and measured responses".

At one time, both you and RMS were heroes of mine, and I was a true
believer (of what, I'm no longer sure); I own copies of both "The
Cathedral and the Bazaar" and "Free Software - Free Society", though
both are currently in my attic, gathering dust.

I've long felt that there was a massive hole in the GNU project and FSF
where effective technical leadership should have been - various
maintainers on gcc, gdb, etc have been implementing things, and things
were humming along, and those of us in Red Hat working on them tried to
coordinate on features we felt were important - but where was the top-
level response to, say, LLVM/clang? (to name just one of many changes
in the industry)  In many ways the last 8 years of my career have been
an attempt to get gcc to respond to the appearance of LLVM/clang (I've
added JIT-compilation, improved diagnostics, and I'm implementing a
static analysis pass) - I'm lucky that my managers inside Red Hat are
happy to pay me to hack on this stuff and make GCC better - it helps
our customers, but it also helps GCC, and the broader FLOSS communities
using both toolchains).

Where has the technical leadership from RMS been?  Instead the long-
standing opposition by RMS to exposing the compiler's IR has hobbled
GCC, and partly contributed to the pile of technical debt we have to
dig our way out of.  The only "leadership" coming out of GNU/FSF seem
to me to be dictats from on high about ChangeLog formats and coding
conventions.  The GNU project seems to me to be stuck in the 1980s. 
Perhaps a pronouncement like: "try to make everything be consumable as
libraries with APIs, as well as as standalone binaries" might have
helped (and still could; can we do that please?)

Similarly, I agree with Joseph's observations of the ways that the FSF
and GNU have been bad umbrella organizations for the toolchain.

But beyond the failure of technical leadership, and the organizational
incompetence/incoherence, is RMS's behavior, and the extent to which
it, as you put it "upset some people".

RMS's defenders seem to have fixated on his 2019 comments on Marvin
Minsky, the uproar over those, and his responses to them (then and
recently), and seem keen to assure us that everything's OK now, or, at
least on a road to improvement.

But in the time since those 2019 comments, I've been reconsidering my
views on RMS.  In particular, I have read of many alleged incidents
such as:
 - spontaneously licking a female conference member on the arm
 - appearing to hit on anyone female, even if they're underage
 - asking which female audience members at his talk were virgins

At least one of the above was from a former colleage of mine, which
when I read it was about the point that broke me.

As part of my reconsidering my views on RMS, I recalled an event
described in Sam Williams' biography of RMS in which Williams describes
RMS's then girlfriend talking about how she "admired the way Richard
built up an entire political movement to address an issue of profound
personal concern", which she identified as "crushing loneliness".

When I first read that, years ago, I felt sorry and pity for RMS, and a
vague feeling that community is an important part of FLOSS, or somesuch
sentiment (and a feeling of trying 

Re: [PATCH 1/3] openacc: Add support for gang local storage allocation in shared memory

[Thomas Schwinge]

Hi!

On 2021-02-26T04:34:50-0800, Julian Brown  wrote:
> This patch

Thanks, Julian, for your continued improving of these changes!

This has iterated through several conceptually different designs and
implementations, by several people, over the past several years.

It's now been made my task to finish it up -- but I'll very much
appreciate your input (Julian's, primarily) on the following remarks,
which are basically my open work items.


> implements a method to track the "private-ness" of
> OpenACC variables declared in offload regions in gang-partitioned,
> worker-partitioned or vector-partitioned modes. Variables declared
> implicitly in scoped blocks and those declared "private" on enclosing
> directives (e.g. "acc parallel") are both handled. Variables that are
> e.g. gang-private can then be adjusted so they reside in GPU shared
> memory.
>
> The reason for doing this is twofold: correct implementation of OpenACC
> semantics

ACK, and as mentioned before, this very much relates to
 "OpenACC: predetermined private levels for
variables declared in blocks" (plus the corresponding use of 'private'
clauses, implicit/explicit, including 'firstprivate') and
 "Predetermined private levels for variables
declared in OpenACC accelerator routines", which we thus should refer in
testcases/ChangeLog/commit log, as appropriate.  I do understand we're
not yet addressing all of that (and that's fine!), but we should capture
remaining work items of the PRs and Cesar's list in
),
as appropriate.


I was surprised that we didn't really have to fix up any existing libgomp
testcases, because there seem to be quite some that contain a pattern
(exemplified by the 'tmp' variable) as follows:

int main()
{
#define N 123
  int data[N];
  int tmp;

#pragma acc parallel // implicit 'firstprivate(tmp)'
  {
// 'tmp' now conceptually made gang-private here.
#pragma acc loop gang
for (int i = 0; i < 123; ++i)
  {
tmp = i + 234;
data[i] = tmp;
  }
  }

  for (int i = 0; i < 123; ++i)
if (data[i] != i + 234)
  __builtin_abort ();

  return 0;
}

With the code changes as posted, this actually now does *not* use
gang-private memory for 'tmp', but instead continues to use
"thread-private registers", as before.

Same for:

--- s3.c2021-04-13 17:26:49.628739379 +0200
+++ s3_2.c  2021-04-13 17:29:43.484579664 +0200
@@ -4,6 +4,6 @@
   int data[N];
-  int tmp;

-#pragma acc parallel // implicit 'firstprivate(tmp)'
+#pragma acc parallel
   {
+int tmp;
 // 'tmp' now conceptually made gang-private here.
 #pragma acc loop gang

I suppose that's due to conditionalizing this transformation on
'TREE_ADDRESSABLE' (as you're doing), so we should be mostly "safe"
regarding such existing testcases (but I haven't verified that yet in
detail).

That needs to be documented in testcases, with some kind of dump scanning
(host compilation-side even; see below).

A note for later: if this weren't just a 'gang' loop, but 'gang' plus
'worker' and/or 'vector', we'd actually be fixing up user code with
undefined behavior into "correct" code (by *not* making 'tmp'
gang-private, but thread-private), right?

As that may not be obvious to the reader, I'd like to have the
'TREE_ADDRESSABLE' conditionalization be documented in the code.  You had
explained that in
: "a
non-addressable variable [...]".


> and optimisation, since shared memory might be faster than
> the main memory on a GPU.

Do we potentially have a problem that making more use of (scarce)
gang-private memory may negatively affect peformance, because potentially
fewer OpenACC gangs may then be launched to the GPU hardware in parallel?
(Of course, OpenACC semantics conformance firstly is more important than
performance, but there may be ways to be conformant and performant;
"quality of implementation".)  Have you run any such performance testing
with the benchmarking codes that we've got set up?

(As I'm more familiar with that, I'm using nvptx offloading examples in
the following, whilst assuming that similar discussion may apply for GCN
offloading, which uses similar hardware concepts, as far as I remember.)

Looking at the existing 'libgomp.oacc-c-c++-common/private-variables.c'
(random example), for nvptx offloading, '-O0', we see the following PTX
JIT compilation changes (word-'diff' of 'GOMP_DEBUG=1' at run-time):

info: Function properties for 'local_g_1$_omp_fn$0':
info: used 27 registers, 32 stack, [-176-]{+256+} bytes smem, 328 bytes 
cmem[0], 0 bytes lmem
info: Function properties for 'local_w_1$_omp_fn$0':
info: used 40 registers, 48 stack, [-176-]{+256+} bytes smem, 328 bytes 

[Bug middle-end/90115] OpenACC: predetermined private levels for variables declared in blocks

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

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

Thomas Schwinge  changed:

   What|Removed |Added

 Blocks||90114

--- Comment #1 from Thomas Schwinge  ---
Very much related is privatization via the corresponding 'private' clauses, at
the respective level.  (Thus not filing a new PR for that.)

OpenACC 3.1, 2.5.12 "private clause" (similar 2.5.13 "firstprivate clause")
states that on compute constructs, "The 'private' clause [...] declares that a
copy of each item on the list will be created for each gang", and OpenACC 3.1,
2.9.10 "private clause" states:

| The 'private' clause on a 'loop' construct specifies that a copy of each item
in var-list will be created. If the body of the loop is executed in
'vector-partitioned' mode, a copy of the item is created for each thread
associated with each vector lane. If the body of the loop is executed in
'worker-partitioned' 'vector-single' mode, a copy of the item is created for
and shared across the set of threads associated with all the vector lanes of
each worker. Otherwise, a copy of the item is created for and shared across the
set of threads associated with all the vector lanes of all the workers of each
gang.


Also related is PR90114 "Predetermined private levels for variables declared in
OpenACC accelerator routines".


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90114
[Bug 90114] Predetermined private levels for variables declared in OpenACC
accelerator routines

[Bug c++/99861] [modules] ICE in hashtab_chk_error

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

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

--- Comment #4 from Alexander Lelyakin  ---
After every few commits one sequence stops to reproduce this error, but some
another appears.

See current status here: http://lelyakin.de/modules/in%20hashtab_chk_error/

Today shortest sequence is:

/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header cerrno
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header unordered_map
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header cstring
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header stdexcept
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header algorithm

hash table checking failed: equal operator returns true for a pair of values
with a different hash value
In file included from /usr/local/include/c++/11.0.1/vector:66,
 from /usr/local/include/c++/11.0.1/functional:62,
 from
/usr/local/include/c++/11.0.1/pstl/glue_algorithm_defs.h:13,
 from /usr/local/include/c++/11.0.1/algorithm:74:
/usr/local/include/c++/11.0.1/bits/stl_uninitialized.h: In static member
function ‘static _ForwardIterator
std::__uninitialized_copy::__uninit_copy(_InputIterator, _InputIterator,
_ForwardIterator)’:
/usr/local/include/c++/11.0.1/bits/stl_uninitialized.h:110:23: internal
compiler error: in hashtab_chk_error, at hash-table.c:137
  110 | { return std::copy(__first, __last, __result); }
  |   ^~~~
0x92f4b5 hashtab_chk_error()
../../gcc/gcc/hash-table.c:137
0xb3e835 hash_table::verify(spec_entry*
const&, unsigned int)
../../gcc/gcc/hash-table.h:1033
0xb3edbe hash_table::find_slot_with_hash(spec_entry* const&, unsigned int,
insert_option)
../../gcc/gcc/hash-table.h:968
0xafba1b match_mergeable_specialization(bool, spec_entry*)
../../gcc/gcc/cp/pt.c:3
0xa74b08 trees_in::key_mergeable(int, merge_kind, tree_node*, tree_node*,
tree_node*, tree_node*, bool)
../../gcc/gcc/cp/module.cc:10670
0xa78704 trees_in::decl_value()
../../gcc/gcc/cp/module.cc:7903
0xa71567 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9153
0xa77b8b module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14811
0xa7808d module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18082
0xa7814f module_state::lazy_load(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18740
0xa723d0 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9664
0xa7788b module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14717
0xa7808d module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18082
0xa7814f module_state::lazy_load(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18740
0xa723d0 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9664
0xa7788b module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14717
0xa7808d module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18082
0xa7814f module_state::lazy_load(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18740
0xa723d0 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9664
0xa7788b module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14717
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

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

[Bug c++/81714] incorrect location for uninitialised variable

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

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

Martin Sebor  changed:

   What|Removed |Added

 CC||skvadrik at gmail dot com

--- Comment #3 from Martin Sebor  ---
*** Bug 60741 has been marked as a duplicate of this bug. ***

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

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

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

Bug 60741 Summary: -Wmaybe-uninitialized wrong location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60741

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

[Bug middle-end/60741] -Wmaybe-uninitialized wrong location

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

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Martin Sebor  ---
The poor location in C++ is also tracked in pr81714.  Let me keep that bug open
since it has a simpler test case and resolve this one as its dupe.

(The C front end does point to the + expression.)

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

[Bug c++/100101] [11 Regression] ICE with -Wzero-as-null-pointer-constant

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

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

--- Comment #4 from Jakub Jelinek  ---
--- gcc/cp/error.c.jj   2021-02-25 23:27:46.561918450 +0100
+++ gcc/cp/error.c  2021-04-15 19:10:38.389850343 +0200
@@ -1554,10 +1554,12 @@ find_typenames_r (tree *tp, int *walk_su
 /* Add the typename without any cv-qualifiers.  */
 mv = TYPE_MAIN_VARIANT (*tp);

-  if (PACK_EXPANSION_P (*tp))
+  if (PACK_EXPANSION_P (*tp) || EXPR_P (*tp))
 {
   /* Don't mess with parameter packs since we don't remember
-the pack expansion context for a particular typename.  */
+the pack expansion context for a particular typename.
+Similarly, don't walk into expressions such as
+those inside of TYPE_RAISES_EXCEPTIONS.  */
   *walk_subtrees = false;
   return NULL_TREE;
 }
passed make check-c++-all and fixes the testcase.

[Bug c++/100101] [11 Regression] ICE with -Wzero-as-null-pointer-constant

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug target/99540] [10 Regression] ICE: Segmentation fault in aarch64_add_offset

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

   Target Milestone|10.4|8.5

--- Comment #13 from rsandifo at gcc dot gnu.org  
---
I think it should be backported back to GCC 8.

[Bug c++/100091] [11 Regression] decltype([]{}) rejected as a default template parameter

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #5 from Jason Merrill  ---
Fixed in r11-8199

[Bug c++/99700] [10/11 Regression] uninitialized variable accepted as a constant expression in C++ 20

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #3 from Patrick Palka  ---
It seems reduced_constant_expression_p needs to check that a
CONSTRUCTOR_NO_CLEARING array ctor initializes all elements.

I'm testing:

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index c8d9dae36fb..6e530f9c88d 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -46,6 +46,7 @@ do { 
\

 static HOST_WIDE_INT find_array_ctor_elt (tree ary, tree dindex,
  bool insert = false);
+static int array_index_cmp (tree key, tree index);

 /* Returns true iff FUN is an instantiation of a constexpr function
template or a defaulted constexpr function.  */
@@ -2912,7 +2913,25 @@ reduced_constant_expression_p (tree t)
  else if (cxx_dialect >= cxx20
   /* An ARRAY_TYPE doesn't have any TYPE_FIELDS.  */
   && TREE_CODE (TREE_TYPE (t)) == ARRAY_TYPE)
-   field = NULL_TREE;
+   {
+ tree min = TYPE_MIN_VALUE (TYPE_DOMAIN (TREE_TYPE (t)));
+ tree max = TYPE_MAX_VALUE (TYPE_DOMAIN (TREE_TYPE (t)));
+ if (find_array_ctor_elt (t, min) == -1
+ || find_array_ctor_elt (t, max) == -1)
+   return false;
+ tree cursor = size_zero_node;
+ FOR_EACH_CONSTRUCTOR_ELT (CONSTRUCTOR_ELTS (t), i, idx, val)
+   {
+ if (!reduced_constant_expression_p (val))
+   return false;
+ if (array_index_cmp (cursor, idx) != 0)
+   return false;
+ if (TREE_CODE (idx) == RANGE_EXPR)
+   cursor = TREE_OPERAND (idx, 1);
+ cursor = int_const_binop (PLUS_EXPR, cursor, size_one_node);
+   }
+ return true;
+   }
  else if (cxx_dialect >= cxx20
   && TREE_CODE (TREE_TYPE (t)) == UNION_TYPE)
{

Re: [PATCH v2] x86: Use crc32 target option for CRC32 intrinsics

[Uros Bizjak via Gcc-patches]

On Thu, Apr 15, 2021 at 6:51 PM H.J. Lu  wrote:
>
> On Thu, Apr 15, 2021 at 9:34 AM Uros Bizjak  wrote:
> >
> > On Thu, Apr 15, 2021 at 6:26 PM H.J. Lu  wrote:
> > >
> > > On Thu, Apr 15, 2021 at 9:14 AM Uros Bizjak  wrote:
> > > >
> > > > On Thu, Apr 15, 2021 at 5:11 PM H.J. Lu  wrote:
> > > > >
> > > > > Use crc32 target option for CRC32 intrinsics to support CRC32 
> > > > > intrinsics
> > > > > without enabling SSE vector instructions.
> > > >
> > > > There is no CRC32 ISA. crc32 is part of SSE4.2 [1] and current
> > > > situation reflects that correctly.
> > >
> > > CRC32 is similar to POPCNT which was originally in SSE4.2.   Now POPCNT
> >
> > It is not similar, POPCNT has its own CPUID flag and can be enabled
> > independently of SSE4.2.
> >
> > > is a separate feature which is also enabled by SSE4.2.   Enable CRC32 only
> > > with SSE4.2 makes it impossible to use CRC32 with -mgeneral-regs-only.   
> > > This
> > > patch addresses this issue the same way as POPCNT.
> >
> > CRC32 doesn't have its own CPUID flag, so PTA_CRC32 is pointless.
>
> PTA_CRC32 shouldn't be added.
>
> > OTOH, the situation is similar with MONITOR and MWAIT. These are
>
> There are no intrinsics for  MONITOR nor MWAIT.

pmmintrin.h:

extern __inline void __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_monitor (void const * __P, unsigned int __E, unsigned int __H)
{
  __builtin_ia32_monitor (__P, __E, __H);
}

extern __inline void __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_mwait (unsigned int __E, unsigned int __H)
{
  __builtin_ia32_mwait (__E, __H);
}

>
> > enabled with SSE3 and don't use XMM registers. Also somewhat similar
> > is FISTTP, but there is no intrinsic for this insn.
>
> True.
>
> Here is the v2 patch without PTA_CRC32.
>
> --
> H.J.

[Bug target/99540] [10 Regression] ICE: Segmentation fault in aarch64_add_offset

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

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

--- Comment #12 from Alex Coplan  ---
Looks like this can be closed?

[PATCH v2] x86: Use crc32 target option for CRC32 intrinsics

[H.J. Lu via Gcc-patches]

On Thu, Apr 15, 2021 at 9:34 AM Uros Bizjak  wrote:
>
> On Thu, Apr 15, 2021 at 6:26 PM H.J. Lu  wrote:
> >
> > On Thu, Apr 15, 2021 at 9:14 AM Uros Bizjak  wrote:
> > >
> > > On Thu, Apr 15, 2021 at 5:11 PM H.J. Lu  wrote:
> > > >
> > > > Use crc32 target option for CRC32 intrinsics to support CRC32 intrinsics
> > > > without enabling SSE vector instructions.
> > >
> > > There is no CRC32 ISA. crc32 is part of SSE4.2 [1] and current
> > > situation reflects that correctly.
> >
> > CRC32 is similar to POPCNT which was originally in SSE4.2.   Now POPCNT
>
> It is not similar, POPCNT has its own CPUID flag and can be enabled
> independently of SSE4.2.
>
> > is a separate feature which is also enabled by SSE4.2.   Enable CRC32 only
> > with SSE4.2 makes it impossible to use CRC32 with -mgeneral-regs-only.   
> > This
> > patch addresses this issue the same way as POPCNT.
>
> CRC32 doesn't have its own CPUID flag, so PTA_CRC32 is pointless.

PTA_CRC32 shouldn't be added.

> OTOH, the situation is similar with MONITOR and MWAIT. These are

There are no intrinsics for  MONITOR nor MWAIT.

> enabled with SSE3 and don't use XMM registers. Also somewhat similar
> is FISTTP, but there is no intrinsic for this insn.

True.

Here is the v2 patch without PTA_CRC32.

-- 
H.J.
From 918c28ae8843df90d1d73838e7afe05ccdfb4cbf Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Thu, 15 Apr 2021 05:59:48 -0700
Subject: [PATCH v2] x86: Use crc32 target option for CRC32 intrinsics

Use crc32 target option for CRC32 intrinsics to support CRC32 intrinsics
without enabling SSE vector instructions.

	* config/i386/gnu-property.c
	(file_end_indicate_exec_stack_and_gnu_property): Also check
	TARGET_CRC32 for GNU_PROPERTY_X86_ISA_1_V2.
	* config/i386/i386-c.c (ix86_target_macros_internal): Define
	__CRC32__ for -mcrc32.
	* config/i386/i386-options.c (ix86_option_override_internal):
	Enable crc32 instruction for -msse4.2.
	* config/i386/i386.md (sse4_2_crc32): Remove TARGET_SSE4_2
	check.
	(sse4_2_crc32di): Likewise.
	* config/i386/ia32intrin.h: Use crc32 target option for CRC32
	intrinsics.
---
 gcc/config/i386/gnu-property.c |  1 +
 gcc/config/i386/i386-c.c   |  2 ++
 gcc/config/i386/i386-options.c |  5 +
 gcc/config/i386/i386.md|  4 ++--
 gcc/config/i386/ia32intrin.h   | 28 ++--
 5 files changed, 24 insertions(+), 16 deletions(-)

diff --git a/gcc/config/i386/gnu-property.c b/gcc/config/i386/gnu-property.c
index 4ba04403002..b6a3bdf62ce 100644
--- a/gcc/config/i386/gnu-property.c
+++ b/gcc/config/i386/gnu-property.c
@@ -92,6 +92,7 @@ file_end_indicate_exec_stack_and_gnu_property (void)
   /* GNU_PROPERTY_X86_ISA_1_V2.  */
   if (TARGET_CMPXCHG16B
 	  || (TARGET_64BIT && TARGET_SAHF)
+	  || TARGET_CRC32
 	  || TARGET_POPCNT
 	  || TARGET_SSE3
 	  || TARGET_SSSE3
diff --git a/gcc/config/i386/i386-c.c b/gcc/config/i386/i386-c.c
index be46d0506ad..5ed0de006fb 100644
--- a/gcc/config/i386/i386-c.c
+++ b/gcc/config/i386/i386-c.c
@@ -532,6 +532,8 @@ ix86_target_macros_internal (HOST_WIDE_INT isa_flag,
 def_or_undef (parse_in, "__LZCNT__");
   if (isa_flag & OPTION_MASK_ISA_TBM)
 def_or_undef (parse_in, "__TBM__");
+  if (isa_flag & OPTION_MASK_ISA_CRC32)
+def_or_undef (parse_in, "__CRC32__");
   if (isa_flag & OPTION_MASK_ISA_POPCNT)
 def_or_undef (parse_in, "__POPCNT__");
   if (isa_flag & OPTION_MASK_ISA_FSGSBASE)
diff --git a/gcc/config/i386/i386-options.c b/gcc/config/i386/i386-options.c
index 91da2849c49..7e59ccd988d 100644
--- a/gcc/config/i386/i386-options.c
+++ b/gcc/config/i386/i386-options.c
@@ -2617,6 +2617,11 @@ ix86_option_override_internal (bool main_args_p,
 opts->x_ix86_isa_flags
   |= OPTION_MASK_ISA_POPCNT & ~opts->x_ix86_isa_flags_explicit;
 
+  /* Enable crc32 instruction for -msse4.2.  */
+  if (TARGET_SSE4_2_P (opts->x_ix86_isa_flags))
+opts->x_ix86_isa_flags
+  |= OPTION_MASK_ISA_CRC32 & ~opts->x_ix86_isa_flags_explicit;
+
   /* Enable lzcnt instruction for -mabm.  */
   if (TARGET_ABM_P(opts->x_ix86_isa_flags))
 opts->x_ix86_isa_flags
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 9ff35d9a607..1f1d74e6275 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -20998,7 +20998,7 @@
 	  [(match_operand:SI 1 "register_operand" "0")
 	   (match_operand:SWI124 2 "nonimmediate_operand" "m")]
 	  UNSPEC_CRC32))]
-  "TARGET_SSE4_2 || TARGET_CRC32"
+  "TARGET_CRC32"
   "crc32{}\t{%2, %0|%0, %2}"
   [(set_attr "type" "sselog1")
(set_attr "prefix_rep" "1")
@@ -21019,7 +21019,7 @@
 	  [(match_operand:DI 1 "register_operand" "0")
 	   (match_operand:DI 2 "nonimmediate_operand" "rm")]
 	  UNSPEC_CRC32))]
-  "TARGET_64BIT && (TARGET_SSE4_2 || TARGET_CRC32)"
+  "TARGET_64BIT && TARGET_CRC32"
   "crc32{q}\t{%2, %0|%0, %2}"
   [(set_attr "type" "sselog1")
(set_attr "prefix_rep" "1")
diff --git a/gcc/config/i386/ia32intrin.h b/gcc/config/i386/ia32intrin.h
index 591394076cc..5422b0fc9e0 100644
--- 

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

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

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

Bug 81962 Summary: -Wmaybe-uninitialized refers to wrong line (and only works 
with -O3) (Fortran)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81962

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

[Bug middle-end/63943] wrong location for -Wmaybe-uninitialized in inlined function

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

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

Martin Sebor  changed:

   What|Removed |Added

   See Also|https://gcc.gnu.org/bugzill |
   |a/show_bug.cgi?id=81962 |
 CC||janus at gcc dot gnu.org

--- Comment #6 from Martin Sebor  ---
*** Bug 81962 has been marked as a duplicate of this bug. ***

[Bug middle-end/81962] -Wmaybe-uninitialized refers to wrong line (and only works with -O3) (Fortran)

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

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

Martin Sebor  changed:

   What|Removed |Added

   See Also|https://gcc.gnu.org/bugzill |
   |a/show_bug.cgi?id=63943 |
 CC||msebor at gcc dot gnu.org
 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #5 from Martin Sebor  ---
This is, in fact, a duplicate of pr63943.

A C test case that reproduces the same effect is below.  I doubt this will ever
be perfect.

$ cat a.c && gcc -O2 -S -Wall -fdump-tree-uninit-lineno=/dev/stdout a.c
int z;

void f (int i)
{
  z = i + 1;
}

void g (int a, int b, int c)
{
  int x;
  if (a && b)
x = a + b;

  if (b && c) 
f (x + 1);
}

;; Function f (f, funcdef_no=0, decl_uid=1944, cgraph_uid=1, symbol_order=1)

void f (int i)
{
  int _1;

   [local count: 1073741824]:
  [a.c:5:9] _1 = i_2(D) + 1;
  [a.c:5:5] z = _1;
  [a.c:6:1] return;

}



;; Function g (g, funcdef_no=1, decl_uid=1949, cgraph_uid=2, symbol_order=2)

...

a.c: In function ‘g’:
a.c:5:9: warning: ‘x’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
5 |   z = i + 1;
  |   ~~^~~
a.c:10:7: note: ‘x’ was declared here
   10 |   int x;
  |   ^
void g (int a, int b, int c)
{
  int x;
  _Bool _1;
  _Bool _2;
  _Bool _3;
  _Bool _4;
  _Bool _5;
  int _14;

   [local count: 1073741824]:
  [a.c:11:7] _1 = a_8(D) != 0;
  [a.c:11:9] _2 = b_9(D) != 0;
  [a.c:11:9] _3 = _1 & _2;
  [a.c:11:6] if (_3 != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870912]:
  goto ; [100.00%]

   [local count: 536870913]:
  [a.c:12:7] x_11 = a_8(D) + b_9(D);

   [local count: 1073741824]:
  # x_6 = PHI 
  [a.c:14:9] _4 = c_12(D) != 0;
  [a.c:14:9] _5 = _2 & _4;
  [a.c:14:6] if (_5 != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870912]:
  goto ; [100.00%]

   [local count: 536870913]:
  [a.c:5:9] _14 = x_6 + 2;
  [a.c:5:5] z = _14;

   [local count: 1073741824]:
  [a.c:16:1] return;

}

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

[Bug c++/100101] [11 Regression] ICE with -Wzero-as-null-pointer-constant

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

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

--- Comment #3 from Jakub Jelinek  ---
In particular it is the TYPENAME_TYPE type seen in bar's noexcept expression.

Does find_typenames_r ever want to walk into expressions?
I.e. couldn't the fix be
  if (EXPR_P (*tp))
*walk_subtrees = 0;
?

Re: [PATCH] libstdc++: Add -latomic to test flags for 32-bit sparc-linux

[Jonathan Wakely via Gcc-patches]

On 15/04/21 18:23 +0200, Eric Botcazou wrote:

Without this I see a number of tests failing when -m32 is used.

libstdc++-v3/ChangeLog:

* testsuite/lib/dg-options.exp (add_options_for_libatomic): Also
add libatomic options for 32-bit sparc*-*-linux-gnu.

Eric, are you OK with this? It adds -latomic and the appropriate -L
options to tests that use { dg-add-options libatomic }, because
sparcv8 needs libatomic for some std::atomic ops.


Sure, thanks.


Thanks, pushed to trunk.

[pushed] c++: lambda in default type template-argument [PR100091]

[Jason Merrill via Gcc-patches]

My patch for 99478 relied on local_variables_forbidden_p for distinguishing
between a template parameter and its default argument, but that flag wasn't
set for a default type template-argument.

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

gcc/cp/ChangeLog:

PR c++/100091
PR c++/99478
* parser.c (cp_parser_default_type_template_argument): Set
parser->local_variables_forbidden_p.

gcc/testsuite/ChangeLog:

PR c++/100091
* g++.dg/cpp2a/lambda-uneval15.C: New test.
---
 gcc/cp/parser.c  | 4 
 gcc/testsuite/g++.dg/cpp2a/lambda-uneval15.C | 5 +
 2 files changed, 9 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/lambda-uneval15.C

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 3a107206318..940751b5f05 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -16923,6 +16923,10 @@ cp_parser_default_type_template_argument (cp_parser 
*parser)
 
   cp_token *token = cp_lexer_peek_token (parser->lexer);
 
+  /* Tell cp_parser_lambda_expression this is a default argument.  */
+  auto lvf = make_temp_override (parser->local_variables_forbidden_p);
+  parser->local_variables_forbidden_p = LOCAL_VARS_AND_THIS_FORBIDDEN;
+
   /* Parse the default-argument.  */
   push_deferring_access_checks (dk_no_deferred);
   tree default_argument = cp_parser_type_id (parser,
diff --git a/gcc/testsuite/g++.dg/cpp2a/lambda-uneval15.C 
b/gcc/testsuite/g++.dg/cpp2a/lambda-uneval15.C
new file mode 100644
index 000..ae72ea3c56b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/lambda-uneval15.C
@@ -0,0 +1,5 @@
+// PR c++/100091
+// { dg-do compile { target c++20 } }
+
+template
+void f() {}

base-commit: b5f644a98b3f3543d3a8d2dfea7785c22879013f
-- 
2.27.0

Re: [PATCH] x86: Use crc32 target option for CRC32 intrinsics

[Uros Bizjak via Gcc-patches]

On Thu, Apr 15, 2021 at 6:26 PM H.J. Lu  wrote:
>
> On Thu, Apr 15, 2021 at 9:14 AM Uros Bizjak  wrote:
> >
> > On Thu, Apr 15, 2021 at 5:11 PM H.J. Lu  wrote:
> > >
> > > Use crc32 target option for CRC32 intrinsics to support CRC32 intrinsics
> > > without enabling SSE vector instructions.
> >
> > There is no CRC32 ISA. crc32 is part of SSE4.2 [1] and current
> > situation reflects that correctly.
>
> CRC32 is similar to POPCNT which was originally in SSE4.2.   Now POPCNT

It is not similar, POPCNT has its own CPUID flag and can be enabled
independently of SSE4.2.

> is a separate feature which is also enabled by SSE4.2.   Enable CRC32 only
> with SSE4.2 makes it impossible to use CRC32 with -mgeneral-regs-only.   This
> patch addresses this issue the same way as POPCNT.

CRC32 doesn't have its own CPUID flag, so PTA_CRC32 is pointless.

OTOH, the situation is similar with MONITOR and MWAIT. These are
enabled with SSE3 and don't use XMM registers. Also somewhat similar
is FISTTP, but there is no intrinsic for this insn.

Uros.

>
> > [1] https://en.wikipedia.org/wiki/SSE4
> >
> > Uros.
> >
> > > * config/i386/gnu-property.c
> > > (file_end_indicate_exec_stack_and_gnu_property): Also check
> > > TARGET_CRC32 for GNU_PROPERTY_X86_ISA_1_V2.
> > > * config/i386/i386-c.c (ix86_target_macros_internal): Define
> > > __CRC32__ for -mcrc32.
> > > * config/i386/i386-options.c (ix86_option_override_internal):
> > > Handle PTA_CRC32.  Enable crc32 instruction for -msse4.2.
> > > * config/i386/i386.h (PTA_CRC32): New.
> > > (PTA_X86_64_V2): Add PTA_CRC32.
> > > (PTA_NEHALEM): Likewise.
> > > * config/i386/i386.md (sse4_2_crc32): Remove TARGET_SSE4_2
> > > check.
> > > (sse4_2_crc32di): Likewise.
> > > * config/i386/ia32intrin.h: Use crc32 target option for CRC32
> > > intrinsics.
> > > ---
> > >  gcc/config/i386/gnu-property.c |  1 +
> > >  gcc/config/i386/i386-c.c   |  2 ++
> > >  gcc/config/i386/i386-options.c |  8 
> > >  gcc/config/i386/i386.h |  6 --
> > >  gcc/config/i386/i386.md|  4 ++--
> > >  gcc/config/i386/ia32intrin.h   | 28 ++--
> > >  6 files changed, 31 insertions(+), 18 deletions(-)
> > >
> > > diff --git a/gcc/config/i386/gnu-property.c 
> > > b/gcc/config/i386/gnu-property.c
> > > index 4ba04403002..b6a3bdf62ce 100644
> > > --- a/gcc/config/i386/gnu-property.c
> > > +++ b/gcc/config/i386/gnu-property.c
> > > @@ -92,6 +92,7 @@ file_end_indicate_exec_stack_and_gnu_property (void)
> > >/* GNU_PROPERTY_X86_ISA_1_V2.  */
> > >if (TARGET_CMPXCHG16B
> > >   || (TARGET_64BIT && TARGET_SAHF)
> > > + || TARGET_CRC32
> > >   || TARGET_POPCNT
> > >   || TARGET_SSE3
> > >   || TARGET_SSSE3
> > > diff --git a/gcc/config/i386/i386-c.c b/gcc/config/i386/i386-c.c
> > > index be46d0506ad..5ed0de006fb 100644
> > > --- a/gcc/config/i386/i386-c.c
> > > +++ b/gcc/config/i386/i386-c.c
> > > @@ -532,6 +532,8 @@ ix86_target_macros_internal (HOST_WIDE_INT isa_flag,
> > >  def_or_undef (parse_in, "__LZCNT__");
> > >if (isa_flag & OPTION_MASK_ISA_TBM)
> > >  def_or_undef (parse_in, "__TBM__");
> > > +  if (isa_flag & OPTION_MASK_ISA_CRC32)
> > > +def_or_undef (parse_in, "__CRC32__");
> > >if (isa_flag & OPTION_MASK_ISA_POPCNT)
> > >  def_or_undef (parse_in, "__POPCNT__");
> > >if (isa_flag & OPTION_MASK_ISA_FSGSBASE)
> > > diff --git a/gcc/config/i386/i386-options.c 
> > > b/gcc/config/i386/i386-options.c
> > > index 91da2849c49..959ee163d2f 100644
> > > --- a/gcc/config/i386/i386-options.c
> > > +++ b/gcc/config/i386/i386-options.c
> > > @@ -2162,6 +2162,9 @@ ix86_option_override_internal (bool main_args_p,
> > > if (((processor_alias_table[i].flags & PTA_CX16) != 0)
> > > && !(opts->x_ix86_isa_flags2_explicit & 
> > > OPTION_MASK_ISA2_CX16))
> > >   opts->x_ix86_isa_flags2 |= OPTION_MASK_ISA2_CX16;
> > > +   if (((processor_alias_table[i].flags & PTA_CRC32) != 0)
> > > +   && !(opts->x_ix86_isa_flags_explicit & OPTION_MASK_ISA_CRC32))
> > > + opts->x_ix86_isa_flags |= OPTION_MASK_ISA_CRC32;
> > > if (((processor_alias_table[i].flags & (PTA_POPCNT | PTA_ABM)) != 
> > > 0)
> > > && !(opts->x_ix86_isa_flags_explicit & 
> > > OPTION_MASK_ISA_POPCNT))
> > >   opts->x_ix86_isa_flags |= OPTION_MASK_ISA_POPCNT;
> > > @@ -2617,6 +2620,11 @@ ix86_option_override_internal (bool main_args_p,
> > >  opts->x_ix86_isa_flags
> > >|= OPTION_MASK_ISA_POPCNT & ~opts->x_ix86_isa_flags_explicit;
> > >
> > > +  /* Enable crc32 instruction for -msse4.2.  */
> > > +  if (TARGET_SSE4_2_P (opts->x_ix86_isa_flags))
> > > +opts->x_ix86_isa_flags
> > > +  |= OPTION_MASK_ISA_CRC32 & ~opts->x_ix86_isa_flags_explicit;
> > > +
> > >/* Enable lzcnt instruction for -mabm.  */
> > >if 

[Bug fortran/100103] New: Automatic reallocation fails inside select rank

[jrfsousa at gmail dot com via Gcc-bugs]

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

Bug ID: 100103
   Summary: Automatic reallocation fails inside select rank
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jrfsousa at gmail dot com
  Target Milestone: ---

Created attachment 50606
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50606=edit
Fortran code showing problem

Hi All!

Automatic reallocation on intrinsic assignment fails inside select rank
construct.

Seen on:

GNU Fortran (GCC) 11.0.1 20210415 (experimental)
GNU Fortran (GCC) 10.3.1 20210415

Thank you very much.

Best regards,
José Rui

[Bug tree-optimization/70392] [openacc] inconsistent line numbers in uninitialised warnings for if clause

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

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2017-12-30 00:00:00 |2021-4-15
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=81714
  Known to fail||10.2.0, 11.0, 6.3.0, 7.0.1,
   ||8.3.0, 9.3.0
 CC||msebor at gcc dot gnu.org

--- Comment #5 from Martin Sebor  ---
Reconfirmed with GCC 11.

The cases in I. comment #0 are also the subject of pr81714 so let's use this to
track just the openacc subset.

Re: [PATCH] x86: Use crc32 target option for CRC32 intrinsics

[H.J. Lu via Gcc-patches]

On Thu, Apr 15, 2021 at 9:14 AM Uros Bizjak  wrote:
>
> On Thu, Apr 15, 2021 at 5:11 PM H.J. Lu  wrote:
> >
> > Use crc32 target option for CRC32 intrinsics to support CRC32 intrinsics
> > without enabling SSE vector instructions.
>
> There is no CRC32 ISA. crc32 is part of SSE4.2 [1] and current
> situation reflects that correctly.

CRC32 is similar to POPCNT which was originally in SSE4.2.   Now POPCNT
is a separate feature which is also enabled by SSE4.2.   Enable CRC32 only
with SSE4.2 makes it impossible to use CRC32 with -mgeneral-regs-only.   This
patch addresses this issue the same way as POPCNT.

> [1] https://en.wikipedia.org/wiki/SSE4
>
> Uros.
>
> > * config/i386/gnu-property.c
> > (file_end_indicate_exec_stack_and_gnu_property): Also check
> > TARGET_CRC32 for GNU_PROPERTY_X86_ISA_1_V2.
> > * config/i386/i386-c.c (ix86_target_macros_internal): Define
> > __CRC32__ for -mcrc32.
> > * config/i386/i386-options.c (ix86_option_override_internal):
> > Handle PTA_CRC32.  Enable crc32 instruction for -msse4.2.
> > * config/i386/i386.h (PTA_CRC32): New.
> > (PTA_X86_64_V2): Add PTA_CRC32.
> > (PTA_NEHALEM): Likewise.
> > * config/i386/i386.md (sse4_2_crc32): Remove TARGET_SSE4_2
> > check.
> > (sse4_2_crc32di): Likewise.
> > * config/i386/ia32intrin.h: Use crc32 target option for CRC32
> > intrinsics.
> > ---
> >  gcc/config/i386/gnu-property.c |  1 +
> >  gcc/config/i386/i386-c.c   |  2 ++
> >  gcc/config/i386/i386-options.c |  8 
> >  gcc/config/i386/i386.h |  6 --
> >  gcc/config/i386/i386.md|  4 ++--
> >  gcc/config/i386/ia32intrin.h   | 28 ++--
> >  6 files changed, 31 insertions(+), 18 deletions(-)
> >
> > diff --git a/gcc/config/i386/gnu-property.c b/gcc/config/i386/gnu-property.c
> > index 4ba04403002..b6a3bdf62ce 100644
> > --- a/gcc/config/i386/gnu-property.c
> > +++ b/gcc/config/i386/gnu-property.c
> > @@ -92,6 +92,7 @@ file_end_indicate_exec_stack_and_gnu_property (void)
> >/* GNU_PROPERTY_X86_ISA_1_V2.  */
> >if (TARGET_CMPXCHG16B
> >   || (TARGET_64BIT && TARGET_SAHF)
> > + || TARGET_CRC32
> >   || TARGET_POPCNT
> >   || TARGET_SSE3
> >   || TARGET_SSSE3
> > diff --git a/gcc/config/i386/i386-c.c b/gcc/config/i386/i386-c.c
> > index be46d0506ad..5ed0de006fb 100644
> > --- a/gcc/config/i386/i386-c.c
> > +++ b/gcc/config/i386/i386-c.c
> > @@ -532,6 +532,8 @@ ix86_target_macros_internal (HOST_WIDE_INT isa_flag,
> >  def_or_undef (parse_in, "__LZCNT__");
> >if (isa_flag & OPTION_MASK_ISA_TBM)
> >  def_or_undef (parse_in, "__TBM__");
> > +  if (isa_flag & OPTION_MASK_ISA_CRC32)
> > +def_or_undef (parse_in, "__CRC32__");
> >if (isa_flag & OPTION_MASK_ISA_POPCNT)
> >  def_or_undef (parse_in, "__POPCNT__");
> >if (isa_flag & OPTION_MASK_ISA_FSGSBASE)
> > diff --git a/gcc/config/i386/i386-options.c b/gcc/config/i386/i386-options.c
> > index 91da2849c49..959ee163d2f 100644
> > --- a/gcc/config/i386/i386-options.c
> > +++ b/gcc/config/i386/i386-options.c
> > @@ -2162,6 +2162,9 @@ ix86_option_override_internal (bool main_args_p,
> > if (((processor_alias_table[i].flags & PTA_CX16) != 0)
> > && !(opts->x_ix86_isa_flags2_explicit & OPTION_MASK_ISA2_CX16))
> >   opts->x_ix86_isa_flags2 |= OPTION_MASK_ISA2_CX16;
> > +   if (((processor_alias_table[i].flags & PTA_CRC32) != 0)
> > +   && !(opts->x_ix86_isa_flags_explicit & OPTION_MASK_ISA_CRC32))
> > + opts->x_ix86_isa_flags |= OPTION_MASK_ISA_CRC32;
> > if (((processor_alias_table[i].flags & (PTA_POPCNT | PTA_ABM)) != 0)
> > && !(opts->x_ix86_isa_flags_explicit & OPTION_MASK_ISA_POPCNT))
> >   opts->x_ix86_isa_flags |= OPTION_MASK_ISA_POPCNT;
> > @@ -2617,6 +2620,11 @@ ix86_option_override_internal (bool main_args_p,
> >  opts->x_ix86_isa_flags
> >|= OPTION_MASK_ISA_POPCNT & ~opts->x_ix86_isa_flags_explicit;
> >
> > +  /* Enable crc32 instruction for -msse4.2.  */
> > +  if (TARGET_SSE4_2_P (opts->x_ix86_isa_flags))
> > +opts->x_ix86_isa_flags
> > +  |= OPTION_MASK_ISA_CRC32 & ~opts->x_ix86_isa_flags_explicit;
> > +
> >/* Enable lzcnt instruction for -mabm.  */
> >if (TARGET_ABM_P(opts->x_ix86_isa_flags))
> >  opts->x_ix86_isa_flags
> > diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
> > index 97700d797a7..c50f9ab24fa 100644
> > --- a/gcc/config/i386/i386.h
> > +++ b/gcc/config/i386/i386.h
> > @@ -2504,12 +2504,14 @@ constexpr wide_int_bitmask PTA_HRESET (0, 
> > HOST_WIDE_INT_1U << 23);
> >  constexpr wide_int_bitmask PTA_KL (0, HOST_WIDE_INT_1U << 24);
> >  constexpr wide_int_bitmask PTA_WIDEKL (0, HOST_WIDE_INT_1U << 25);
> >  constexpr wide_int_bitmask PTA_AVXVNNI (0, HOST_WIDE_INT_1U << 26);
> > +constexpr wide_int_bitmask PTA_CRC32 (0, HOST_WIDE_INT_1U << 27);
> >
> >  

Re: GCC association with the FSF

[Richard Biener via Gcc]

On April 15, 2021 6:02:50 PM GMT+02:00, Jason Merrill  wrote:
>On Wed, Apr 14, 2021 at 8:08 AM Richard Biener via Gcc
> wrote:
>> On April 14, 2021 12:19:16 PM GMT+02:00, Jonathan Wakely via Gcc
> wrote:
>> >N.B. Jeff is no longer @redhat.com so I've changed the CC
>> >On Wed, 14 Apr 2021 at 11:03, Thomas Koenig 
>> >wrote:
>> >> - All gfortran developers move to the new branch.  This will not
>> >>happen, I can guarantee you that.
>> >
>> >This is the part I'm curious about (the rest is obvious, it follows
>> >from there being finite resources and the nature of any fork). But
>I'm
>> >not going to press for reasons.
>>
>> Note the only viable fork will be on the current hosting (which isn't
>FSF controlled) with the downside of eventually losing the gcc.gnu.org
>DNS and thus a need to "switch" to a sourceware.org name.
>
>It seems wrong to call such a scenario a fork.  If someone wanted to
>fork GCC they are free to do so, but changing the relationship with
>GNU/FSF is not a fork, as there would continue to be one primary
>source repository.

True. That's definitely better communication. 

Richard. 

>Jason

Re: [PATCH] libstdc++: Add -latomic to test flags for 32-bit sparc-linux

[Eric Botcazou]

> Without this I see a number of tests failing when -m32 is used.
> 
> libstdc++-v3/ChangeLog:
> 
>   * testsuite/lib/dg-options.exp (add_options_for_libatomic): Also
>   add libatomic options for 32-bit sparc*-*-linux-gnu.
> 
> Eric, are you OK with this? It adds -latomic and the appropriate -L
> options to tests that use { dg-add-options libatomic }, because
> sparcv8 needs libatomic for some std::atomic ops.

Sure, thanks.

-- 
Eric Botcazou

Re: [PATCH] Deprecate gimple-builder.h API

[Richard Biener]

On April 15, 2021 6:08:44 PM GMT+02:00, Martin Sebor  wrote:
>On 4/15/21 5:01 AM, Richard Biener wrote:
>> This adds a deprecation note to the undocumented gimple-builder.h
>> API only used by asan and sancov.
>> 
>> Pushed.
>> 
>> 2021-04-15  Richard Biener  
>> 
>>  * gimple-builder.h: Add deprecation note.
>> ---
>>   gcc/gimple-builder.h | 2 ++
>>   1 file changed, 2 insertions(+)
>> 
>> diff --git a/gcc/gimple-builder.h b/gcc/gimple-builder.h
>> index 61cf08c8dcb..ae273ce9041 100644
>> --- a/gcc/gimple-builder.h
>> +++ b/gcc/gimple-builder.h
>> @@ -21,6 +21,8 @@ along with GCC; see the file COPYING3.  If not see
>>   #ifndef GCC_GIMPLE_BUILDER_H
>>   #define GCC_GIMPLE_BUILDER_H
>>   
>> +/* ???  This API is legacy and should not be used in new code.  */
>
>What do the question marks mean? (IMO, they're misleading and might
>make the reader wonder whether the note really means what it says.)

It means the API should be removed instead which shouldn't be too hard... 

Richard. 

>Martin
>
>
>> +
>>   gassign *build_assign (enum tree_code, tree, int, tree lhs =
>NULL_TREE);
>>   gassign *build_assign (enum tree_code, gimple *, int, tree lhs =
>NULL_TREE);
>>   gassign *build_assign (enum tree_code, tree, tree, tree lhs =
>NULL_TREE);
>> 

Re: removing toxic emailers

[Gabriel Ravier via Gcc]

On 4/15/21 8:00 AM, Thomas Koenig via Gcc wrote:

My 0.02 Euro-Cent:

There is a minor problem with contributors being overly harsh/
borderline abusive on the mailing list.  In my > 15 years with
the project, I have only had that problem with one single
person, and I have resolved that by never again touching the
system that particular person is responsible for, also not
for testing.

The _real_ problem is in bugzilla, mostly with abusive users
complaining about the time it sometimes takes to fix bugs
("Why didn't you fix this?  Are you stupid or what? That bug
has been open for _weeks_!") or who will not understand that
their program has an error, and insist on the compiler sanctioning
their particular non-standard usage.


As much as I hate to say it, this is a problem in the wider communities 
around C and C++, too. My teacher will often insist that "GCC and Clang 
make convenient assumptions at O2 and higher" without comprehending that 
the assumptions are "your code conforms to what the C/C++ standard says" 
and that this is the entire reason we have a standard, despite all my 
efforts at explaining things to him.




On bugzilla, there is also a rather minor problem with contributors
being overly harsh/borderline abusive, but that is also quite
restrictive.

If we talk about gcc becoming a more welcoming place, bugzilla
is the place to start. 

[Bug libstdc++/96657] [9/10 Regression] libsupc++.a missing required functions from src/c++98/atomicity.cc when atomic builtins are not supported

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

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

Jonathan Wakely  changed:

   What|Removed |Added

Summary|[9/10/11 Regression]|[9/10 Regression]
   |libsupc++.a missing |libsupc++.a missing
   |required functions from |required functions from
   |src/c++98/atomicity.cc when |src/c++98/atomicity.cc when
   |atomic builtins are not |atomic builtins are not
   |supported   |supported

--- Comment #6 from Jonathan Wakely  ---
Fixed on trunk. Backports to follow.

Re: [PATCH] x86: Use crc32 target option for CRC32 intrinsics

[Uros Bizjak via Gcc-patches]

On Thu, Apr 15, 2021 at 5:11 PM H.J. Lu  wrote:
>
> Use crc32 target option for CRC32 intrinsics to support CRC32 intrinsics
> without enabling SSE vector instructions.

There is no CRC32 ISA. crc32 is part of SSE4.2 [1] and current
situation reflects that correctly.

[1] https://en.wikipedia.org/wiki/SSE4

Uros.

> * config/i386/gnu-property.c
> (file_end_indicate_exec_stack_and_gnu_property): Also check
> TARGET_CRC32 for GNU_PROPERTY_X86_ISA_1_V2.
> * config/i386/i386-c.c (ix86_target_macros_internal): Define
> __CRC32__ for -mcrc32.
> * config/i386/i386-options.c (ix86_option_override_internal):
> Handle PTA_CRC32.  Enable crc32 instruction for -msse4.2.
> * config/i386/i386.h (PTA_CRC32): New.
> (PTA_X86_64_V2): Add PTA_CRC32.
> (PTA_NEHALEM): Likewise.
> * config/i386/i386.md (sse4_2_crc32): Remove TARGET_SSE4_2
> check.
> (sse4_2_crc32di): Likewise.
> * config/i386/ia32intrin.h: Use crc32 target option for CRC32
> intrinsics.
> ---
>  gcc/config/i386/gnu-property.c |  1 +
>  gcc/config/i386/i386-c.c   |  2 ++
>  gcc/config/i386/i386-options.c |  8 
>  gcc/config/i386/i386.h |  6 --
>  gcc/config/i386/i386.md|  4 ++--
>  gcc/config/i386/ia32intrin.h   | 28 ++--
>  6 files changed, 31 insertions(+), 18 deletions(-)
>
> diff --git a/gcc/config/i386/gnu-property.c b/gcc/config/i386/gnu-property.c
> index 4ba04403002..b6a3bdf62ce 100644
> --- a/gcc/config/i386/gnu-property.c
> +++ b/gcc/config/i386/gnu-property.c
> @@ -92,6 +92,7 @@ file_end_indicate_exec_stack_and_gnu_property (void)
>/* GNU_PROPERTY_X86_ISA_1_V2.  */
>if (TARGET_CMPXCHG16B
>   || (TARGET_64BIT && TARGET_SAHF)
> + || TARGET_CRC32
>   || TARGET_POPCNT
>   || TARGET_SSE3
>   || TARGET_SSSE3
> diff --git a/gcc/config/i386/i386-c.c b/gcc/config/i386/i386-c.c
> index be46d0506ad..5ed0de006fb 100644
> --- a/gcc/config/i386/i386-c.c
> +++ b/gcc/config/i386/i386-c.c
> @@ -532,6 +532,8 @@ ix86_target_macros_internal (HOST_WIDE_INT isa_flag,
>  def_or_undef (parse_in, "__LZCNT__");
>if (isa_flag & OPTION_MASK_ISA_TBM)
>  def_or_undef (parse_in, "__TBM__");
> +  if (isa_flag & OPTION_MASK_ISA_CRC32)
> +def_or_undef (parse_in, "__CRC32__");
>if (isa_flag & OPTION_MASK_ISA_POPCNT)
>  def_or_undef (parse_in, "__POPCNT__");
>if (isa_flag & OPTION_MASK_ISA_FSGSBASE)
> diff --git a/gcc/config/i386/i386-options.c b/gcc/config/i386/i386-options.c
> index 91da2849c49..959ee163d2f 100644
> --- a/gcc/config/i386/i386-options.c
> +++ b/gcc/config/i386/i386-options.c
> @@ -2162,6 +2162,9 @@ ix86_option_override_internal (bool main_args_p,
> if (((processor_alias_table[i].flags & PTA_CX16) != 0)
> && !(opts->x_ix86_isa_flags2_explicit & OPTION_MASK_ISA2_CX16))
>   opts->x_ix86_isa_flags2 |= OPTION_MASK_ISA2_CX16;
> +   if (((processor_alias_table[i].flags & PTA_CRC32) != 0)
> +   && !(opts->x_ix86_isa_flags_explicit & OPTION_MASK_ISA_CRC32))
> + opts->x_ix86_isa_flags |= OPTION_MASK_ISA_CRC32;
> if (((processor_alias_table[i].flags & (PTA_POPCNT | PTA_ABM)) != 0)
> && !(opts->x_ix86_isa_flags_explicit & OPTION_MASK_ISA_POPCNT))
>   opts->x_ix86_isa_flags |= OPTION_MASK_ISA_POPCNT;
> @@ -2617,6 +2620,11 @@ ix86_option_override_internal (bool main_args_p,
>  opts->x_ix86_isa_flags
>|= OPTION_MASK_ISA_POPCNT & ~opts->x_ix86_isa_flags_explicit;
>
> +  /* Enable crc32 instruction for -msse4.2.  */
> +  if (TARGET_SSE4_2_P (opts->x_ix86_isa_flags))
> +opts->x_ix86_isa_flags
> +  |= OPTION_MASK_ISA_CRC32 & ~opts->x_ix86_isa_flags_explicit;
> +
>/* Enable lzcnt instruction for -mabm.  */
>if (TARGET_ABM_P(opts->x_ix86_isa_flags))
>  opts->x_ix86_isa_flags
> diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
> index 97700d797a7..c50f9ab24fa 100644
> --- a/gcc/config/i386/i386.h
> +++ b/gcc/config/i386/i386.h
> @@ -2504,12 +2504,14 @@ constexpr wide_int_bitmask PTA_HRESET (0, 
> HOST_WIDE_INT_1U << 23);
>  constexpr wide_int_bitmask PTA_KL (0, HOST_WIDE_INT_1U << 24);
>  constexpr wide_int_bitmask PTA_WIDEKL (0, HOST_WIDE_INT_1U << 25);
>  constexpr wide_int_bitmask PTA_AVXVNNI (0, HOST_WIDE_INT_1U << 26);
> +constexpr wide_int_bitmask PTA_CRC32 (0, HOST_WIDE_INT_1U << 27);
>
>  constexpr wide_int_bitmask PTA_X86_64_BASELINE = PTA_64BIT | PTA_MMX | 
> PTA_SSE
>| PTA_SSE2 | PTA_NO_SAHF | PTA_FXSR;
>  constexpr wide_int_bitmask PTA_X86_64_V2 = (PTA_X86_64_BASELINE
> & (~PTA_NO_SAHF))
> -  | PTA_CX16 | PTA_POPCNT | PTA_SSE3 | PTA_SSE4_1 | PTA_SSE4_2 | PTA_SSSE3;
> +  | PTA_CRC32 | PTA_CX16 | PTA_POPCNT | PTA_SSE3 | PTA_SSE4_1 | PTA_SSE4_2
> +  | PTA_SSSE3;
>  constexpr wide_int_bitmask PTA_X86_64_V3 = PTA_X86_64_V2
>| PTA_AVX | PTA_AVX2 | PTA_BMI | 

[Bug jit/100096] libgccjit.so.0: Cannot write-enable text segment: Permission denied on NetBSD 9.1

[swilde--- via Gcc-bugs]

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

--- Comment #15 from Sascha Wilde  ---
(In reply to Jakub Jelinek from comment #13)
> readelf -wi libgccjit.so.0 | grep DW_AT_producer | grep -v 'fPIC\|fpic'

FWIW, I had the command running for quite some while without spotting any
line not containing -fPIC -- but these might still come though...


(In reply to Jakub Jelinek from comment #14)
> Though, DW_AT_producer lines don't really provide the filename and comp_dir,
> so guess what I need is better
> readelf -wi libgccjit.so.0 | grep -A4 DW_AT_producer | bzip2 -9
> output.

Ill provide you with the output.  Please allow me some time, as this really 
runs _long_ on the system in question (a small Atom CPU N270).

I hope to provide the output tomorrow...

[committed] libstdc++: Move atomic functions to libsupc++ [PR 96657]

[Jonathan Wakely via Gcc-patches]

The changes for PR libstdc++/64735 mean that libsupc++ function might
now depend on the __exchange_and_add and __atomic_add functions defined
in config/cpu/*/atomicity.h which is not compiled into libsupc++. This
causes a link failure for some targets when trying to use libsupc++
without the rest of libstdc++.

This patch simply moves the definitions of those functions into
libsupc++ so that they are available there.

libstdc++-v3/ChangeLog:

PR libstdc++/96657
* libsupc++/Makefile.am: Add atomicity.cc here.
* src/c++98/Makefile.am: Remove it from here.
* libsupc++/Makefile.in: Regenerate.
* src/c++98/Makefile.in: Regenerate.
* testsuite/18_support/exception_ptr/96657.cc: New test.

Tested powerpc64le-linux and sparc64-linux (-m32/-m64).

Committed to trunk.

commit 6c0c7fc6236470a533675cd3cd1ebb1cc3dd112c
Author: Jonathan Wakely 
Date:   Wed Apr 14 20:48:54 2021

libstdc++: Move atomic functions to libsupc++ [PR 96657]

The changes for PR libstdc++/64735 mean that libsupc++ function might
now depend on the __exchange_and_add and __atomic_add functions defined
in config/cpu/*/atomicity.h which is not compiled into libsupc++. This
causes a link failure for some targets when trying to use libsupc++
without the rest of libstdc++.

This patch simply moves the definitions of those functions into
libsupc++ so that they are available there.

libstdc++-v3/ChangeLog:

PR libstdc++/96657
* libsupc++/Makefile.am: Add atomicity.cc here.
* src/c++98/Makefile.am: Remove it from here.
* libsupc++/Makefile.in: Regenerate.
* src/c++98/Makefile.in: Regenerate.
* testsuite/18_support/exception_ptr/96657.cc: New test.

diff --git a/libstdc++-v3/libsupc++/Makefile.am 
b/libstdc++-v3/libsupc++/Makefile.am
index 3563a3b421d..10ac4bb0124 100644
--- a/libstdc++-v3/libsupc++/Makefile.am
+++ b/libstdc++-v3/libsupc++/Makefile.am
@@ -48,6 +48,7 @@ sources = \
array_type_info.cc \
atexit_arm.cc \
atexit_thread.cc \
+   atomicity.cc \
bad_alloc.cc \
bad_array_length.cc \
bad_array_new.cc \
@@ -127,6 +128,9 @@ cp-demangle.lo: cp-demangle.c
 cp-demangle.o: cp-demangle.c
$(C_COMPILE) -DIN_GLIBCPP_V3 -Wno-error -c $<
 
+atomicity_file = ${glibcxx_srcdir}/$(ATOMICITY_SRCDIR)/atomicity.h
+atomicity.cc: ${atomicity_file}
+   $(LN_S) ${atomicity_file} ./atomicity.cc || true
 
 # AM_CXXFLAGS needs to be in each subdirectory so that it can be
 # modified in a per-library or per-sub-library way.  Need to manually
diff --git a/libstdc++-v3/src/c++98/Makefile.am 
b/libstdc++-v3/src/c++98/Makefile.am
index 2a9fc1b5f5d..0fa6ab95fb4 100644
--- a/libstdc++-v3/src/c++98/Makefile.am
+++ b/libstdc++-v3/src/c++98/Makefile.am
@@ -39,7 +39,6 @@ endif
 # particular host.
 host_sources = \
$(cow_string_host_sources) \
-   atomicity.cc \
codecvt_members.cc \
collate_members.cc \
messages_members.cc \
@@ -65,10 +64,6 @@ numeric_members.cc: ${glibcxx_srcdir}/$(CNUMERIC_CC)
 time_members.cc: ${glibcxx_srcdir}/$(CTIME_CC)
$(LN_S) ${glibcxx_srcdir}/$(CTIME_CC) . || true
 
-atomicity_file = ${glibcxx_srcdir}/$(ATOMICITY_SRCDIR)/atomicity.h
-atomicity.cc: ${atomicity_file}
-   $(LN_S) ${atomicity_file} ./atomicity.cc || true
-
 if ENABLE_DUAL_ABI
 collate_members_cow.cc: ${glibcxx_srcdir}/$(CCOLLATE_CC)
$(LN_S) ${glibcxx_srcdir}/$(CCOLLATE_CC) ./$@ || true
diff --git a/libstdc++-v3/testsuite/18_support/exception_ptr/96657.cc 
b/libstdc++-v3/testsuite/18_support/exception_ptr/96657.cc
new file mode 100644
index 000..61572668385
--- /dev/null
+++ b/libstdc++-v3/testsuite/18_support/exception_ptr/96657.cc
@@ -0,0 +1,17 @@
+// { dg-options "-nodefaultlibs -lsupc++ -lgcc_s -lc" { target 
sparc*-*-linux-gnu } }
+// { dg-do link { target c++11 } }
+
+#include 
+
+void
+test01()
+{
+  // PR libstdc++/96657 undefined references in libsupc++
+  std::make_exception_ptr(1);
+}
+
+int
+main()
+{
+  test01();
+}

[Bug libstdc++/64735] std::future broken on armel

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

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

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

https://gcc.gnu.org/g:6c0c7fc6236470a533675cd3cd1ebb1cc3dd112c

commit r11-8198-g6c0c7fc6236470a533675cd3cd1ebb1cc3dd112c
Author: Jonathan Wakely 
Date:   Wed Apr 14 20:48:54 2021 +0100

libstdc++: Move atomic functions to libsupc++ [PR 96657]

The changes for PR libstdc++/64735 mean that libsupc++ function might
now depend on the __exchange_and_add and __atomic_add functions defined
in config/cpu/*/atomicity.h which is not compiled into libsupc++. This
causes a link failure for some targets when trying to use libsupc++
without the rest of libstdc++.

This patch simply moves the definitions of those functions into
libsupc++ so that they are available there.

libstdc++-v3/ChangeLog:

PR libstdc++/96657
* libsupc++/Makefile.am: Add atomicity.cc here.
* src/c++98/Makefile.am: Remove it from here.
* libsupc++/Makefile.in: Regenerate.
* src/c++98/Makefile.in: Regenerate.
* testsuite/18_support/exception_ptr/96657.cc: New test.

[Bug libstdc++/96657] [9/10/11 Regression] libsupc++.a missing required functions from src/c++98/atomicity.cc when atomic builtins are not supported

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

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

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

https://gcc.gnu.org/g:6c0c7fc6236470a533675cd3cd1ebb1cc3dd112c

commit r11-8198-g6c0c7fc6236470a533675cd3cd1ebb1cc3dd112c
Author: Jonathan Wakely 
Date:   Wed Apr 14 20:48:54 2021 +0100

libstdc++: Move atomic functions to libsupc++ [PR 96657]

The changes for PR libstdc++/64735 mean that libsupc++ function might
now depend on the __exchange_and_add and __atomic_add functions defined
in config/cpu/*/atomicity.h which is not compiled into libsupc++. This
causes a link failure for some targets when trying to use libsupc++
without the rest of libstdc++.

This patch simply moves the definitions of those functions into
libsupc++ so that they are available there.

libstdc++-v3/ChangeLog:

PR libstdc++/96657
* libsupc++/Makefile.am: Add atomicity.cc here.
* src/c++98/Makefile.am: Remove it from here.
* libsupc++/Makefile.in: Regenerate.
* src/c++98/Makefile.in: Regenerate.
* testsuite/18_support/exception_ptr/96657.cc: New test.

Re: [PATCH] Deprecate gimple-builder.h API

[Martin Sebor via Gcc-patches]

On 4/15/21 5:01 AM, Richard Biener wrote:

This adds a deprecation note to the undocumented gimple-builder.h
API only used by asan and sancov.

Pushed.

2021-04-15  Richard Biener  

* gimple-builder.h: Add deprecation note.
---
  gcc/gimple-builder.h | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/gcc/gimple-builder.h b/gcc/gimple-builder.h
index 61cf08c8dcb..ae273ce9041 100644
--- a/gcc/gimple-builder.h
+++ b/gcc/gimple-builder.h
@@ -21,6 +21,8 @@ along with GCC; see the file COPYING3.  If not see
  #ifndef GCC_GIMPLE_BUILDER_H
  #define GCC_GIMPLE_BUILDER_H
  
+/* ???  This API is legacy and should not be used in new code.  */


What do the question marks mean? (IMO, they're misleading and might
make the reader wonder whether the note really means what it says.)

Martin



+
  gassign *build_assign (enum tree_code, tree, int, tree lhs = NULL_TREE);
  gassign *build_assign (enum tree_code, gimple *, int, tree lhs = NULL_TREE);
  gassign *build_assign (enum tree_code, tree, tree, tree lhs = NULL_TREE);

[PATCH 2/2] Add IEEE 128-bit fp conditional move on PowerPC.

[Michael Meissner via Gcc-patches]

[PATCH 2/2] Add IEEE 128-bit fp conditional move on PowerPC.

This patch adds the support for power10 IEEE 128-bit floating point conditional
move and for automatically generating min/max.

In this patch, I simplified things.  Instead of allowing any four of the modes
to be used for the conditional move comparison and the move itself could use
different modes, I restricted the conditional move to just the same mode.
I.e. you can do:

_Float128 a, b, c, d, e, r;

r = (a == b) ? c : d;

But you can't do:

_Float128 c, d, r;
double a, b;

r = (a == b) ? c : d;

or:

_Float128 a, b;
double c, d, r;

r = (a == b) ? c : d;

This eliminates a lot of the complexity of the code, because you don't have to
worry about the sizes being different, and the IEEE 128-bit types being
restricted to Altivec registers, while the SF/DF modes can use any VSX
register.

I did not modify the existing support that allowed conditional moves where
SFmode operands are compared and DFmode operands are moved (and vice versa).

This simplification also eliminates having to insert a XXPERMDI instruction if
you are comparing 64-bit values and doing a conditional move with 128-bit
values.

I modified the test cases that I added to reflect this change.  I have also
fixed the test for not equal to use '!=' instead of '=='.

I have built bootstrap compilers on both a little endian power9 Linux system
and a big endian power8 Linux system.  There were no regressions in either
build in the test suites.  Can I check these changes into the trunk for gcc 11?

gcc/
2021-04-14 Michael Meissner  

* config/rs6000/rs6000.c (have_compare_and_set_mask): Add IEEE
128-bit floating point types.
* config/rs6000/rs6000.md (movcc, IEEE128 iterator): New insn.
(movcc_p10, IEEE128 iterator): New insn.
(movcc_invert_p10, IEEE128 iterator): New insn.
(fpmask, IEEE128 iterator): New insn.
(xxsel, IEEE128 iterator): New insn.

gcc/testsuite/
2021-04-14  Michael Meissner  

* gcc.target/powerpc/float128-cmove.c: New test.
* gcc.target/powerpc/float128-minmax-3.c: New test.
---
 gcc/config/rs6000/rs6000.c|   8 +-
 gcc/config/rs6000/rs6000.md   | 106 ++
 .../gcc.target/powerpc/float128-cmove.c   |  58 ++
 .../gcc.target/powerpc/float128-minmax-3.c|  15 +++
 4 files changed, 185 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/float128-cmove.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/float128-minmax-3.c

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 8d00f99e9fd..f979d7320ad 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -15706,8 +15706,8 @@ rs6000_emit_vector_cond_expr (rtx dest, rtx op_true, 
rtx op_false,
   return 1;
 }
 
-/* Possibly emit the xsmaxcdp and xsmincdp instructions to emit a maximum or
-   minimum with "C" semantics.
+/* Possibly emit the xsmaxc{dp,qp} and xsminc{dp,qp} instructions to emit a
+   maximum or minimum with "C" semantics.
 
Unless you use -ffast-math, you can't use these instructions to replace
conditions that implicitly reverse the condition because the comparison
@@ -15843,6 +15843,10 @@ have_compare_and_set_mask (machine_mode mode)
 case E_DFmode:
   return TARGET_P9_MINMAX;
 
+case E_KFmode:
+case E_TFmode:
+  return TARGET_POWER10 && TARGET_FLOAT128_HW && FLOAT128_IEEE_P (mode);
+
 default:
   break;
 }
diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index 17b2fdc1cdd..c74fc8ce6fc 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -5429,6 +5429,112 @@ (define_insn "*xxsel"
   "xxsel %x0,%x4,%x3,%x1"
   [(set_attr "type" "vecmove")])
 
+;; Support for ISA 3.1 IEEE 128-bit conditional move.  The mode used in the
+;; comparison must be the same as used in the conditional move.
+(define_expand "movcc"
+   [(set (match_operand:IEEE128 0 "gpc_reg_operand")
+(if_then_else:IEEE128 (match_operand 1 "comparison_operator")
+  (match_operand:IEEE128 2 "gpc_reg_operand")
+  (match_operand:IEEE128 3 "gpc_reg_operand")))]
+  "TARGET_POWER10 && TARGET_FLOAT128_HW && FLOAT128_IEEE_P (mode)"
+{
+  if (rs6000_emit_cmove (operands[0], operands[1], operands[2], operands[3]))
+DONE;
+  else
+FAIL;
+})
+
+(define_insn_and_split "*movcc_p10"
+  [(set (match_operand:IEEE128 0 "altivec_register_operand" "=,v")
+   (if_then_else:IEEE128
+(match_operator:CCFP 1 "fpmask_comparison_operator"
+   [(match_operand:IEEE128 2 "altivec_register_operand" "v,v")
+(match_operand:IEEE128 3 "altivec_register_operand" "v,v")])
+(match_operand:IEEE128 4 "altivec_register_operand" "v,v")
+(match_operand:IEEE128 5 "altivec_register_operand" "v,v")))
+   (clobber 

[Bug tree-optimization/100102] ICE in tsubst, at cp/pt.c:15310

[schnetter at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Erik Schnetter  ---
Created attachment 50605
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50605=edit
Compressed preprocessed source code

Re: GCC association with the FSF

[Jason Merrill via Gcc]

On Wed, Apr 14, 2021 at 8:08 AM Richard Biener via Gcc  wrote:
> On April 14, 2021 12:19:16 PM GMT+02:00, Jonathan Wakely via Gcc 
>  wrote:
> >N.B. Jeff is no longer @redhat.com so I've changed the CC
> >On Wed, 14 Apr 2021 at 11:03, Thomas Koenig 
> >wrote:
> >> - All gfortran developers move to the new branch.  This will not
> >>happen, I can guarantee you that.
> >
> >This is the part I'm curious about (the rest is obvious, it follows
> >from there being finite resources and the nature of any fork). But I'm
> >not going to press for reasons.
>
> Note the only viable fork will be on the current hosting (which isn't FSF 
> controlled) with the downside of eventually losing the gcc.gnu.org DNS and 
> thus a need to "switch" to a sourceware.org name.

It seems wrong to call such a scenario a fork.  If someone wanted to
fork GCC they are free to do so, but changing the relationship with
GNU/FSF is not a fork, as there would continue to be one primary
source repository.

Jason

[Bug tree-optimization/100102] New: ICE in tsubst, at cp/pt.c:15310

[schnetter at gmail dot com via Gcc-bugs]

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

Bug ID: 100102
   Summary: ICE in tsubst, at cp/pt.c:15310
   Product: gcc
   Version: 10.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: schnetter at gmail dot com
  Target Milestone: ---

I am using GCC 10.3.0 on x86_64 GNU/Linux. GCC was built via Spack, and is
called from nvcc.

I encounter the following ICE:

cd
/tmp/eschnetter/spack-stage/spack-stage-amrex-21.04-eiivnj5bgmpnqg6o7ofgmy4yvdfgxasa/spack-build-eiivnj5/Src
&&
/home/eschnetter/src/CarpetX/spack/opt/spack/linux-ubuntu18.04-skylake_avx512/gcc-10.3.0/cuda-11.2.2-jbyezwujy3vielujb4xz3izwi6q36jnb/bin/nvcc
-forward-unknown-to-host-compiler
-ccbin=/home/eschnetter/src/CarpetX/Cactus/view-cuda-compilers/bin/g++
-Damrex_EXPORTS
-I/tmp/eschnetter/spack-stage/spack-stage-amrex-21.04-eiivnj5bgmpnqg6o7ofgmy4yvdfgxasa/spack-src/Src/Base
-I/tmp/eschnetter/spack-stage/spack-stage-amrex-21.04-eiivnj5bgmpnqg6o7ofgmy4yvdfgxasa/spack-src/Src/Boundary
-I/tmp/eschnetter/spack-stage/spack-stage-amrex-21.04-eiivnj5bgmpnqg6o7ofgmy4yvdfgxasa/spack-src/Src/AmrCore
-I/tmp/eschnetter/spack-stage/spack-stage-amrex-21.04-eiivnj5bgmpnqg6o7ofgmy4yvdfgxasa/spack-src/Src/Amr
-I/tmp/eschnetter/spack-stage/spack-stage-amrex-21.04-eiivnj5bgmpnqg6o7ofgmy4yvdfgxasa/spack-src/Src/LinearSolvers/MLMG
-I/tmp/eschnetter/spack-stage/spack-stage-amrex-21.04-eiivnj5bgmpnqg6o7ofgmy4yvdfgxasa/spack-src/Src/LinearSolvers/Projections
-I/tmp/eschnetter/spack-stage/spack-stage-amrex-21.04-eiivnj5bgmpnqg6o7ofgmy4yvdfgxasa/spack-src/Src/Particle
-I/tmp/eschnetter/spack-stage/spack-stage-amrex-21.04-eiivnj5bgmpnqg6o7ofgmy4yvdfgxasa/spack-build-eiivnj5
-isystem=/home/eschnetter/src/CarpetX/spack/opt/spack/linux-ubuntu18.04-skylake_avx512/gcc-10.3.0/openmpi-4.0.5-jl7qr7jpt3fe6z5rdfkgj2n4t5b4xbdn/include
-isystem=/home/eschnetter/src/CarpetX/spack/opt/spack/linux-ubuntu18.04-skylake_avx512/gcc-10.3.0/hdf5-1.10.7-gkflrn3su7geakoyly56sqebg2pqa2yr/include
-isystem=/home/eschnetter/src/CarpetX/spack/opt/spack/linux-ubuntu18.04-skylake_avx512/gcc-10.3.0/zlib-1.2.11-dd2emzewyp4o4c22f3niqq3dyhjhqkzs/include
-m64 --expt-relaxed-constexpr --expt-extended-lambda
-Wno-deprecated-gpu-targets -gencode=arch=compute_75,code=sm_75
-maxrregcount=255 -Xcudafe --diag_suppress=esa_on_defaulted_function_ignored
--use_fast_math -Xcudafe --display_error_number --Wext-lambda-captures-this
--Werror ext-lambda-captures-this --Werror cross-execution-space-call
--generate-line-info --source-in-ptx -O2 -g -DNDEBUG -Xcompiler=-fPIC
-Xcompiler=-fopenmp -Xcompiler=-Werror=return-type -Xcompiler -pthread
-std=c++14 -MD -MT Src/CMakeFiles/amrex.dir/Base/AMReX_BlockMutex.cpp.o -MF
CMakeFiles/amrex.dir/Base/AMReX_BlockMutex.cpp.o.d -x cu -dc
/tmp/eschnetter/spack-stage/spack-stage-amrex-21.04-eiivnj5bgmpnqg6o7ofgmy4yvdfgxasa/spack-src/Src/Base/AMReX_BlockMutex.cpp
-o CMakeFiles/amrex.dir/Base/AMReX_BlockMutex.cpp.o
/home/eschnetter/src/CarpetX/spack/opt/spack/linux-ubuntu18.04-skylake_avx512/gcc-10.1.0/gcc-10.3.0-74t7ecp2jgn6myrtnrziqo5hg6bncbb4/include/c++/10.3.0/chrono:
In substitution of 'template template using __is_harmonic =
std::__bool_constant<(std::ratio<((_Period2::num / std::chrono::duration<_Rep,
_Period>::_S_gcd(_Period2::num, _Period::num)) * (_Period::den /
std::chrono::duration<_Rep, _Period>::_S_gcd(_Period2::den, _Period::den))),
((_Period2::den / std::chrono::duration<_Rep, _Period>::_S_gcd(_Period2::den,
_Period::den)) * (_Period::num / std::chrono::duration<_Rep,
_Period>::_S_gcd(_Period2::num, _Period::num)))>::den == 1)> [with _Period2 =
_Period2; _Rep = _Rep; _Period = _Period]':
/home/eschnetter/src/CarpetX/spack/opt/spack/linux-ubuntu18.04-skylake_avx512/gcc-10.1.0/gcc-10.3.0-74t7ecp2jgn6myrtnrziqo5hg6bncbb4/include/c++/10.3.0/chrono:473:154:
  required from here
/home/eschnetter/src/CarpetX/spack/opt/spack/linux-ubuntu18.04-skylake_avx512/gcc-10.1.0/gcc-10.3.0-74t7ecp2jgn6myrtnrziqo5hg6bncbb4/include/c++/10.3.0/chrono:428:27:
internal compiler error: Segmentation fault
  428 |  _S_gcd(intmax_t __m, intmax_t __n) noexcept
  |   ^~
0xc5d6af crash_signal
   
/tmp/eschnetter/spack-stage/spack-stage-gcc-10.3.0-74t7ecp2jgn6myrtnrziqo5hg6bncbb4/spack-src/gcc/toplev.c:328
0x754d6d tsubst(tree_node*, tree_node*, int, tree_node*)
   
/tmp/eschnetter/spack-stage/spack-stage-gcc-10.3.0-74t7ecp2jgn6myrtnrziqo5hg6bncbb4/spack-src/gcc/cp/pt.c:15310
0x767d76 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
   
/tmp/eschnetter/spack-stage/spack-stage-gcc-10.3.0-74t7ecp2jgn6myrtnrziqo5hg6bncbb4/spack-src/gcc/cp/pt.c:13225
0x760766 tsubst_aggr_type
   
/tmp/eschnetter/spack-stage/spack-stage-gcc-10.3.0-74t7ecp2jgn6myrtnrziqo5hg6bncbb4/spack-src/gcc/cp/pt.c:13428
0x76aa5f tsubst_function_decl
   

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

[andysem at mail dot ru via Gcc-bugs]

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

--- Comment #6 from andysem at mail dot ru ---
Hmm, it looks like the original code has changed enough so that the problem no
longer reproduces, with or without __restrict__. I don't have the older version
of the code, so I can't tell what changed exactly. Data alignment most probably
did change, but data layout of A (its equivalent in the original code) as well
as the operation on it certainly didn't. Sorry for the confusion.

[PATCH] libstdc++: Add -latomic to test flags for 32-bit sparc-linux

[Jonathan Wakely via Gcc-patches]

Without this I see a number of tests failing when -m32 is used.

libstdc++-v3/ChangeLog:

* testsuite/lib/dg-options.exp (add_options_for_libatomic): Also
add libatomic options for 32-bit sparc*-*-linux-gnu.

Eric, are you OK with this? It adds -latomic and the appropriate -L
options to tests that use { dg-add-options libatomic }, because
sparcv8 needs libatomic for some std::atomic ops.



commit bbee87be3bfaa1ef19521870df998386f83d7ac2
Author: Jonathan Wakely 
Date:   Thu Apr 15 16:39:55 2021

libstdc++: Add -latomic to test flags for 32-bit sparc-linux

Without this I see a number of tests failing when -m32 is used.

libstdc++-v3/ChangeLog:

* testsuite/lib/dg-options.exp (add_options_for_libatomic): Also
add libatomic options for 32-bit sparc*-*-linux-gnu.

diff --git a/libstdc++-v3/testsuite/lib/dg-options.exp 
b/libstdc++-v3/testsuite/lib/dg-options.exp
index 5160e4a72d1..7894973bcca 100644
--- a/libstdc++-v3/testsuite/lib/dg-options.exp
+++ b/libstdc++-v3/testsuite/lib/dg-options.exp
@@ -264,6 +264,7 @@ proc add_options_for_libatomic { flags } {
 if { [istarget hppa*-*-hpux*]
 || ([istarget powerpc*-*-*] && [check_effective_target_ilp32])
 || [istarget riscv*-*-*]
+|| ([istarget sparc*-*-linux-gnu] && [check_effective_target_ilp32])
} {
return "$flags -L../../libatomic/.libs -latomic"
 }

[PATCH 1/2] Add IEEE 128-bit min/max support on PowerPC.

[Michael Meissner via Gcc-patches]

[PATCH 1/2] Add IEEE 128-bit min/max support on PowerPC.

This patch adds the support for the IEEE 128-bit floating point C minimum and
maximum instructions.  The next patch will add the support for using the
compare and set mask instruction to implement conditional moves.

I removed the FLOAT128_MIN_MAX_FPMASK_P macro that was in the last iteration of
the patch.

I have built bootstrap compilers on both a little endian power9 Linux system
and a big endian power8 Linux system.  There were no regressions in either
build in the test suites.  Can I check these changes into the trunk for gcc 11?

gcc/
2021-04-14  Michael Meissner  

* config/rs6000/rs6000.c (rs6000_emit_minmax): Add support for ISA
3.1 IEEE 128-bit floating point xsmaxcqp and xsmincqp instructions.
* config/rs6000/rs6000.md (s3, IEEE128 iterator):
New insns.

gcc/testsuite/
2021-04-14  Michael Meissner  

* gcc.target/powerpc/float128-minmax-2.c: New test.
---
 gcc/config/rs6000/rs6000.c|  3 ++-
 gcc/config/rs6000/rs6000.md   | 11 +++
 .../gcc.target/powerpc/float128-minmax-2.c| 15 +++
 3 files changed, 28 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/float128-minmax-2.c

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 48b8efd732b..8d00f99e9fd 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -16111,7 +16111,8 @@ rs6000_emit_minmax (rtx dest, enum rtx_code code, rtx 
op0, rtx op1)
   /* VSX/altivec have direct min/max insns.  */
   if ((code == SMAX || code == SMIN)
   && (VECTOR_UNIT_ALTIVEC_OR_VSX_P (mode)
- || (mode == SFmode && VECTOR_UNIT_VSX_P (DFmode
+ || (mode == SFmode && VECTOR_UNIT_VSX_P (DFmode))
+ || (TARGET_POWER10 && TARGET_FLOAT128_HW && FLOAT128_IEEE_P (mode
 {
   emit_insn (gen_rtx_SET (dest, gen_rtx_fmt_ee (code, mode, op0, op1)));
   return;
diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index c8cdc42533c..17b2fdc1cdd 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -5194,6 +5194,17 @@ (define_insn "*s3_vsx"
 }
   [(set_attr "type" "fp")])
 
+;; Min/max for ISA 3.1 IEEE 128-bit floating point
+(define_insn "s3"
+  [(set (match_operand:IEEE128 0 "altivec_register_operand" "=v")
+   (fp_minmax:IEEE128
+(match_operand:IEEE128 1 "altivec_register_operand" "v")
+(match_operand:IEEE128 2 "altivec_register_operand" "v")))]
+  "TARGET_POWER10"
+  "xscqp %0,%1,%2"
+  [(set_attr "type" "vecfloat")
+   (set_attr "size" "128")])
+
 ;; The conditional move instructions allow us to perform max and min operations
 ;; even when we don't have the appropriate max/min instruction using the FSEL
 ;; instruction.
diff --git a/gcc/testsuite/gcc.target/powerpc/float128-minmax-2.c 
b/gcc/testsuite/gcc.target/powerpc/float128-minmax-2.c
new file mode 100644
index 000..c71ba08c9f8
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/float128-minmax-2.c
@@ -0,0 +1,15 @@
+/* { dg-require-effective-target ppc_float128_hw } */
+/* { dg-require-effective-target power10_ok } */
+/* { dg-options "-mdejagnu-cpu=power10 -O2 -ffast-math" } */
+
+#ifndef TYPE
+#define TYPE _Float128
+#endif
+
+/* Test that the fminf128/fmaxf128 functions generate if/then/else and not a
+   call.  */
+TYPE f128_min (TYPE a, TYPE b) { return __builtin_fminf128 (a, b); }
+TYPE f128_max (TYPE a, TYPE b) { return __builtin_fmaxf128 (a, b); }
+
+/* { dg-final { scan-assembler {\mxsmaxcqp\M} } } */
+/* { dg-final { scan-assembler {\mxsmincqp\M} } } */
-- 
2.22.0


-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[Bug c++/100101] [11 Regression] ICE with -Wzero-as-null-pointer-constant

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

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

--- Comment #2 from Jakub Jelinek  ---
So maybe find_typenames doesn't want to walk into TYPE_RAISES_EXCEPTIONS?

[PATCH 0/2] Add IEEE 128-bit min/max/conditional move

[Michael Meissner via Gcc-patches]

These patches add support for the XSMAXCQP, XSMINCQP, XSCMPEQQP, XSCMPGTQP, and
XSCMPGEQP instructions that were added to the PowerPC ISA 3.1 (power10).

These patches address the comments raised from the last version of the patches.

In this iteration, I simplified the first patch, eliminating a new macro.

The second patch I removed the support for conditional moves where the modes of
the operands being compared is different from the mode of the operands being
moved because this greatly complicated the patch.  This means you can do:

_Float128 a, b, c, d, r;

r = (a == b) ? c : d;

But you can't do:

_Float128 c, d, r;
double a, b;

r = (a == b) ? c : d;

I did leave in the existing support for doing this mixed conditional move
between float/double, but I did not extended it for the two IEEE 128-bit
types.

I modified the test cases that I added to reflect this change.  I have also
fixed the test for not equal to use '!=' instead of '=='.

I have built bootstrap compilers on both a little endian power9 Linux system
and a big endian power8 Linux system.  There were no regressions in either
build in the test suites.  Can I check these changes into the trunk for gcc 11?

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[Bug fortran/100094] Undefined pointers have incorrect rank when using optimization

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
Isn't the code invalid Fortran because it references an undefined pointer?
If yes, the compiler is allows to do whatever it wants with the code.

[PATCH] testsuite: Move gimplefe40.c and gimplefe41.c

[Robin Dapp via Gcc-patches]

Hi,

the gimplefe40 and gimplefe41.c tests expect vector capabilities 
(vect_float etc.) yet are not in the vect subdirectory.  This causes 
both to be called unconditionally without prior target-specific vector 
setup normally performed by vect/vect.exp.


There is a target-specific option for powerpc

 /* { dg-additional-options "-maltivec" { target { powerpc*-*-* && 
powerpc_altivec_ok } } } */


which enables Altivec on supported targets but I'd rather not create 
another special case for s390.  I suppose the better solution is to move 
these tests to the vect subdirectory.


Is this OK?

Regards
 Robin

--

gcc/testsuite/ChangeLog:

* gcc.dg/gimplefe-40.c: Moved to...
* gcc.dg/vect/gimplefe-40.c: ...here.
* gcc.dg/gimplefe-41.c: Moved to...
* gcc.dg/vect/gimplefe-41.c: ...here.
commit 1acd4d01c41aeea78ec3c188beb25b245dda4c8b
Author: Robin Dapp 
Date:   Wed Mar 17 09:08:42 2021 +0100

[PATCH] testsuite: Move gimplefe-4[0|1] tests.

The gimplefe-40.c and gimplefe-41.c test cases require vect_* effective
targets even though they reside in gcc.dg.  By default e.g.
DEFAULT_VECTCFLAGS which is used to add target-specific machine or build
flags is only applied in the ./vect subdirectory.  Move these tests
there.

diff --git a/gcc/testsuite/gcc.dg/gimplefe-40.c b/gcc/testsuite/gcc.dg/vect/gimplefe-40.c
similarity index 100%
rename from gcc/testsuite/gcc.dg/gimplefe-40.c
rename to gcc/testsuite/gcc.dg/vect/gimplefe-40.c
diff --git a/gcc/testsuite/gcc.dg/gimplefe-41.c b/gcc/testsuite/gcc.dg/vect/gimplefe-41.c
similarity index 100%
rename from gcc/testsuite/gcc.dg/gimplefe-41.c
rename to gcc/testsuite/gcc.dg/vect/gimplefe-41.c

[Bug c++/100101] [11 Regression] ICE with -Wzero-as-null-pointer-constant

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[PATCH] aarch64: Fix up 2 other combine opt regressions vs. GCC8 [PR100075]

[Jakub Jelinek via Gcc-patches]

Hi!

The testcase used to be compiled at -O2 by GCC8 and earlier to:
f1:
neg w1, w0, asr 16
and w1, w1, 65535
orr w0, w1, w0, lsl 16
ret
f2:
neg w1, w0
extrw0, w1, w0, 16
ret
but since GCC9 (r9-3594 for f1 and r9-6926 for f2) we compile it into:
f1:
mov w1, w0
sbfxx0, x1, 16, 16
neg w0, w0
bfi w0, w1, 16, 16
ret
f2:
neg w1, w0
sbfxx0, x0, 16, 16
bfi w0, w1, 16, 16
ret
instead, i.e. one insn longer each.  With this patch we get:
f1:
mov w1, w0
neg w0, w1, asr 16
bfi w0, w1, 16, 16
ret
f2:
neg w1, w0
extrw0, w1, w0, 16
ret
i.e. identical f2 and same number of insns as in GCC8 in f1.
The combiner unfortunately doesn't try splitters when doing 2 -> 1
combination, so it can't be implemented as combine splitters, but
it could be implemented as define_insn_and_split if desirable.

Bootstrapped/regtested on aarch64-linux, ok for trunk?

2021-04-15  Jakub Jelinek  

PR target/100075
* config/aarch64/aarch64.md (*neg_asr_si2_extr, *extrsi5_insn_di): New
define_insn patterns.

* gcc.target/aarch64/pr100075.c: New test.

--- gcc/config/aarch64/aarch64.md.jj2021-04-15 10:45:02.798853095 +0200
+++ gcc/config/aarch64/aarch64.md   2021-04-15 13:28:04.734754364 +0200
@@ -3572,6 +3572,18 @@ (define_insn "*neg__si2_uxtw"
   [(set_attr "autodetect_type" "alu_shift__op2")]
 )
 
+(define_insn "*neg_asr_si2_extr"
+  [(set (match_operand:SI 0 "register_operand" "r")
+   (neg:SI (match_operator 4 "subreg_lowpart_operator"
+ [(sign_extract:DI
+(match_operand:DI 1 "register_operand" "r")
+(match_operand 3 "aarch64_simd_shift_imm_offset_si" "n")
+(match_operand 2 "aarch64_simd_shift_imm_offset_si" 
"n"))])))]
+  "INTVAL (operands[2]) + INTVAL (operands[3]) == 32"
+  "neg\\t%w0, %w1, asr %2"
+  [(set_attr "autodetect_type" "alu_shift_asr_op2")]
+)
+
 (define_insn "mul3"
   [(set (match_operand:GPI 0 "register_operand" "=r")
(mult:GPI (match_operand:GPI 1 "register_operand" "r")
@@ -5382,6 +5394,22 @@ (define_insn "*extrsi5_insn_uxtw_alt"
   "extr\\t%w0, %w1, %w2, %4"
   [(set_attr "type" "rotate_imm")]
 )
+
+(define_insn "*extrsi5_insn_di"
+  [(set (match_operand:SI 0 "register_operand" "=r")
+   (ior:SI (ashift:SI (match_operand:SI 1 "register_operand" "r")
+  (match_operand 3 "const_int_operand" "n"))
+   (match_operator:SI 6 "subreg_lowpart_operator"
+ [(zero_extract:DI
+(match_operand:DI 2 "register_operand" "r")
+(match_operand 5 "const_int_operand" "n")
+(match_operand 4 "const_int_operand" "n"))])))]
+  "UINTVAL (operands[3]) < 32
+   && UINTVAL (operands[3]) + UINTVAL (operands[4]) == 32
+   && UINTVAL (operands[4]) + UINTVAL (operands[5]) - 32 <= 64"
+  "extr\\t%w0, %w1, %w2, %4"
+  [(set_attr "type" "rotate_imm")]
+)
 
 (define_insn "*ror3_insn"
   [(set (match_operand:GPI 0 "register_operand" "=r")
--- gcc/testsuite/gcc.target/aarch64/pr100075.c.jj  2021-04-15 
13:23:31.188852983 +0200
+++ gcc/testsuite/gcc.target/aarch64/pr100075.c 2021-04-15 13:23:10.612086048 
+0200
@@ -0,0 +1,20 @@
+/* PR target/100075 */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+/* { dg-final { scan-assembler-not {\tsbfx\tx[0-9]+, x[0-9]+, 16, 16} } } */
+/* { dg-final { scan-assembler {\tneg\tw[0-9]+, w[0-9]+, asr 16} } } */
+/* { dg-final { scan-assembler {\textr\tw[0-9]+, w[0-9]+, w[0-9]+, 16} } } */
+
+struct S { short x, y; };
+
+struct S
+f1 (struct S p)
+{
+  return (struct S) { -p.y, p.x };
+}
+
+struct S
+f2 (struct S p)
+{
+  return (struct S) { p.y, -p.x };
+}

Jakub

[Bug c++/100101] [11 Regression] ICE with -Wzero-as-null-pointer-constant

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |11.0
   Last reconfirmed||2021-04-15
 Ever confirmed|0   |1

--- Comment #1 from Patrick Palka  ---
Seems to have started with r11-7953.

[Bug target/99767] [9/10/11 Regression] ICE in expand_direct_optab_fn, at internal-fn.c:3360

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix that does that.

Patch, fortran] PR fortran/100097 PR fortran/100098 - [Unlimited] polymorphic pointers and allocatables have incorrect rank

[José Rui Faustino de Sousa via Gcc-patches]

Hi All!

Proposed patch to:

PR100097 - Unlimited polymorphic pointers and allocatables have 
incorrect rank

PR100098 - Polymorphic pointers and allocatables have incorrect rank

Patch tested only on x86_64-pc-linux-gnu.

Pointers, and allocatables, must carry TKR information even when 
undefined. The patch adds code to initialize, for both pointers and 
allocatables, the class descriptor element size, rank and type as soon 
as possible to do so.


Thank you very much.

Best regards,
José Rui

Fortran: Add missing TKR initialization to class variables [PR100097, 
PR100098]


gcc/fortran/ChangeLog:

PR fortran/100097
PR fortran/100098
* trans-array.c (gfc_trans_class_array): new function to
initialize class descriptor's TKR information.
* trans-array.h (gfc_trans_class_array): add function prototype.
* trans-decl.c (gfc_trans_deferred_vars): add calls to the new
function for both pointers and allocatables.

gcc/testsuite/ChangeLog:

PR fortran/100097
* gfortran.dg/PR100097.f90: New test.

PR fortran/100098
* gfortran.dg/PR100098.f90: New test.

diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index be5eb89350f..acd44a347e2 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -10808,6 +10808,52 @@ gfc_alloc_allocatable_for_assignment (gfc_loopinfo *loop,
 }
 
 
+/* Initialize class descriptor's TKR infomation.  */
+
+void
+gfc_trans_class_array (gfc_symbol * sym, gfc_wrapped_block * block)
+{
+  tree type, etype;
+  tree tmp;
+  tree descriptor;
+  stmtblock_t init;
+  locus loc;
+  int rank;
+
+  /* Make sure the frontend gets these right.  */
+  gcc_assert (sym->ts.type == BT_CLASS && CLASS_DATA (sym)
+	  && (CLASS_DATA (sym)->attr.class_pointer
+		  || CLASS_DATA (sym)->attr.allocatable));
+
+  gcc_assert (VAR_P (sym->backend_decl)
+	  || TREE_CODE (sym->backend_decl) == PARM_DECL);
+
+  if (sym->attr.dummy)
+return;
+
+  descriptor = gfc_class_data_get (sym->backend_decl);
+  type = TREE_TYPE (descriptor);
+
+  if (type == NULL || !GFC_DESCRIPTOR_TYPE_P (type))
+return;
+
+  gfc_save_backend_locus ();
+  gfc_set_backend_locus (>declared_at);
+  gfc_init_block ();
+
+  rank = CLASS_DATA (sym)->as ? (CLASS_DATA (sym)->as->rank) : (0);
+  gcc_assert (rank>=0);
+  tmp = gfc_conv_descriptor_dtype (descriptor);
+  etype = gfc_get_element_type (type);
+  tmp = fold_build2_loc (input_location, MODIFY_EXPR, TREE_TYPE (tmp), tmp,
+			 gfc_get_dtype_rank_type (rank, etype));
+  gfc_add_expr_to_block (, tmp);
+
+  gfc_add_init_cleanup (block, gfc_finish_block (), NULL_TREE);
+  gfc_restore_backend_locus ();
+}
+
+
 /* NULLIFY an allocatable/pointer array on function entry, free it on exit.
Do likewise, recursively if necessary, with the allocatable components of
derived types.  This function is also called for assumed-rank arrays, which
diff --git a/gcc/fortran/trans-array.h b/gcc/fortran/trans-array.h
index e4d443d7118..d2768f1be61 100644
--- a/gcc/fortran/trans-array.h
+++ b/gcc/fortran/trans-array.h
@@ -67,6 +67,8 @@ tree gfc_check_pdt_dummy (gfc_symbol *, tree, int, gfc_actual_arglist *);
 
 tree gfc_alloc_allocatable_for_assignment (gfc_loopinfo*, gfc_expr*, gfc_expr*);
 
+/* Add initialization for class descriptors  */
+void gfc_trans_class_array (gfc_symbol *, gfc_wrapped_block *);
 /* Add initialization for deferred arrays.  */
 void gfc_trans_deferred_array (gfc_symbol *, gfc_wrapped_block *);
 /* Generate an initializer for a static pointer or allocatable array.  */
diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index 34a0d49bae7..6a0d80bccb0 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -4929,7 +4929,7 @@ gfc_trans_deferred_vars (gfc_symbol * proc_sym, gfc_wrapped_block * block)
   else if ((!sym->attr.dummy || sym->ts.deferred)
 		&& (sym->ts.type == BT_CLASS
 		&& CLASS_DATA (sym)->attr.class_pointer))
-	continue;
+	gfc_trans_class_array (sym, block);
   else if ((!sym->attr.dummy || sym->ts.deferred)
 		&& (sym->attr.allocatable
 		|| (sym->attr.pointer && sym->attr.result)
@@ -5013,6 +5013,10 @@ gfc_trans_deferred_vars (gfc_symbol * proc_sym, gfc_wrapped_block * block)
 		  tmp = NULL_TREE;
 		}
 
+	  /* Initialize descriptor's TKR information.  */
+	  if (sym->ts.type == BT_CLASS)
+		gfc_trans_class_array (sym, block);
+
 	  /* Deallocate when leaving the scope. Nullifying is not
 		 needed.  */
 	  if (!sym->attr.result && !sym->attr.dummy && !sym->attr.pointer
diff --git a/gcc/testsuite/gfortran.dg/PR100097.f90 b/gcc/testsuite/gfortran.dg/PR100097.f90
new file mode 100644
index 000..926eb6cc779
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/PR100097.f90
@@ -0,0 +1,41 @@
+! { dg-do run }
+!
+! Test the fix for PR100097
+!
+
+program main_p
+
+  implicit none
+
+  class(*), pointer :: bar_p(:)
+  class(*), allocatable :: bar_a(:)
+
+  call foo_p(bar_p)
+  call 

Re: removing toxic emailers

[Paul Koning via Gcc]

> On Apr 15, 2021, at 11:17 AM, Iain Sandoe  wrote:
> 
> ...
> responding in general to this part of the thread.
> 
> * The GCC environment is not hostile, and has not been for the 15 or so
> years I’ve been part of the community.

Glad to see you feel that way; my view matches yours.

> * We would notice if it became so, I’m not sure about the idea that the wool
>  can be so easily pulled over our eyes.
> 
> I confess to being concerned with the equation “code” > “conduct”; it is not
> so in my professional or personal experience.   I have seen an engineering
> team suffer great losses of performance from the excesses of one (near genius,
> but very antisocial) member - the balance was not met.  Likewise, it has been
> seen to be a poor balance when there are three gifted individuals in a 
> household
> but one persecutes the other two (for diagnosed reaons).. again balance is not
> met
> 
> One could see the equation becoming a self-fullfilling prophecy viz.
> 
> *  let us say compilers are complex, and  any significant input over length 
> of time
>   will require a resonably competent engineer.
> 
> * reasonably competent engineers with a good social habit are welcome 
> everywhere
> 
> * reasonably competent engineers with poor social habit are welcome in few 
> places.

All true.

> - those few places will easily be able to demonstrate that their progress is 
> made
>  despite the poor atmosphere, with no way to know that something better was 
> possible.
> 
> responding to the thread in general..
> 
> * Please could we try to seek concensus?
> 
> - it is disappointing to see people treating this as some kind of 
> point-scoring game
>  when to those working on the compiler day to day it is far from a game.

I'm not sure what the consensus is you're looking for.  Consensus on the 
principle that people should behave in a civil fashion? Yes, I agree with that. 
 

The difficulty, as I mentioned, is in deciding in concrete situations whether 
that principle was violated and what should be done about it.  So I think the 
easy part is the principle; the hard part is the process that will enforce the 
principle in those cases where it needs to be -- and ONLY in those cases.  
Again, if the question had come up 10 years ago I wouldn't be so worried; but 
in 2021 after years of watching people being blacklisted for daring to speak 
the wrong politics of the day, I can no longer do so.

paul

[Bug c++/100091] [11 Regression] decltype([]{}) rejected as a default template parameter

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[committed] Make SVE ACLE tests work with --with-cpu

[Richard Sandiford via Gcc-patches]

This patch follows on from a previous one and adds -mtune=generic
to the SVE ACLE assembler tests.  These tests are pure assembly
tests (execution tests are elsewhere) and they already require
dg-additional-options to be used to add new options.  We therefore
don't need aarch64-with-arch-dg-options.

Tested on an aarch64-linux-gnu toolchain configured with
--with-cpu=a64fx, pushed to trunk.

Richard


gcc/testsuite/
* g++.target/aarch64/sve/acle/aarch64-sve-acle-asm.exp: Add
-mtune=generic to the SVE flags.
* g++.target/aarch64/sve2/acle/aarch64-sve2-acle-asm.exp: Likewise.
* gcc.target/aarch64/sve/acle/aarch64-sve-acle-asm.exp: Likewise.
* gcc.target/aarch64/sve2/acle/aarch64-sve2-acle-asm.exp: Likewise.
---
 .../g++.target/aarch64/sve/acle/aarch64-sve-acle-asm.exp  | 2 +-
 .../g++.target/aarch64/sve2/acle/aarch64-sve2-acle-asm.exp| 4 
 .../gcc.target/aarch64/sve/acle/aarch64-sve-acle-asm.exp  | 2 +-
 .../gcc.target/aarch64/sve2/acle/aarch64-sve2-acle-asm.exp| 4 
 4 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/g++.target/aarch64/sve/acle/aarch64-sve-acle-asm.exp 
b/gcc/testsuite/g++.target/aarch64/sve/acle/aarch64-sve-acle-asm.exp
index 84ae95e2ccc..070a049c149 100644
--- a/gcc/testsuite/g++.target/aarch64/sve/acle/aarch64-sve-acle-asm.exp
+++ b/gcc/testsuite/g++.target/aarch64/sve/acle/aarch64-sve-acle-asm.exp
@@ -39,7 +39,7 @@ if { [check_effective_target_aarch64_sve] } {
 
 # Turn off any codegen tweaks by default that may affect expected assembly.
 # Tests relying on those should turn them on explicitly.
-set sve_flags "$sve_flags -moverride=tune=none"
+set sve_flags "$sve_flags -mtune=generic -moverride=tune=none"
 
 global gcc_runtest_parallelize_limit_minor
 if { [info exists gcc_runtest_parallelize_limit_minor] } {
diff --git 
a/gcc/testsuite/g++.target/aarch64/sve2/acle/aarch64-sve2-acle-asm.exp 
b/gcc/testsuite/g++.target/aarch64/sve2/acle/aarch64-sve2-acle-asm.exp
index c3a3a01a7ed..4989818664c 100644
--- a/gcc/testsuite/g++.target/aarch64/sve2/acle/aarch64-sve2-acle-asm.exp
+++ b/gcc/testsuite/g++.target/aarch64/sve2/acle/aarch64-sve2-acle-asm.exp
@@ -37,6 +37,10 @@ if { [check_effective_target_aarch64_sve2] } {
 set sve2_flags "-march=armv8.5-a+sve2"
 }
 
+# Turn off any codegen tweaks by default that may affect expected assembly.
+# Tests relying on those should turn them on explicitly.
+set sve2_flags "$sve2_flags -mtune=generic -moverride=tune=none"
+
 set gcc_subdir [string replace $subdir 0 2 gcc]
 lappend extra_flags "-fno-ipa-icf" "-I$srcdir/$gcc_subdir/../../sve/acle/asm"
 
diff --git a/gcc/testsuite/gcc.target/aarch64/sve/acle/aarch64-sve-acle-asm.exp 
b/gcc/testsuite/gcc.target/aarch64/sve/acle/aarch64-sve-acle-asm.exp
index fcd07aaa040..35229910da8 100644
--- a/gcc/testsuite/gcc.target/aarch64/sve/acle/aarch64-sve-acle-asm.exp
+++ b/gcc/testsuite/gcc.target/aarch64/sve/acle/aarch64-sve-acle-asm.exp
@@ -39,7 +39,7 @@ if { [check_effective_target_aarch64_sve] } {
 
 # Turn off any codegen tweaks by default that may affect expected assembly.
 # Tests relying on those should turn them on explicitly.
-set sve_flags "$sve_flags -moverride=tune=none"
+set sve_flags "$sve_flags -mtune=generic -moverride=tune=none"
 
 global gcc_runtest_parallelize_limit_minor
 if { [info exists gcc_runtest_parallelize_limit_minor] } {
diff --git 
a/gcc/testsuite/gcc.target/aarch64/sve2/acle/aarch64-sve2-acle-asm.exp 
b/gcc/testsuite/gcc.target/aarch64/sve2/acle/aarch64-sve2-acle-asm.exp
index 632d3508e32..67f817dd21f 100644
--- a/gcc/testsuite/gcc.target/aarch64/sve2/acle/aarch64-sve2-acle-asm.exp
+++ b/gcc/testsuite/gcc.target/aarch64/sve2/acle/aarch64-sve2-acle-asm.exp
@@ -37,6 +37,10 @@ if { [check_effective_target_aarch64_sve2] } {
 set sve2_flags "-march=armv8.5-a+sve2"
 }
 
+# Turn off any codegen tweaks by default that may affect expected assembly.
+# Tests relying on those should turn them on explicitly.
+set sve_flags "$sve_flags -mtune=generic -moverride=tune=none"
+
 lappend extra_flags "-fno-ipa-icf"
 
 global gcc_runtest_parallelize_limit_minor

[committed] Make SVE tests work with --with-cpu

[Richard Sandiford via Gcc-patches]

A lot of the SVE assembly tests are for generic-tuned SVE codegen
and so can fail when run on a toolchain configured with --with-cpu.

This could easily be solved by forcing -mtune=generic, like we already
do for -moverride=tune=none.  However, the testsuite also has some
useful execution tests that it would be better to run with as
few flag changes as possible.  Also, the flags in $sve_flags are
printed as part of the test results, so each change to $sve_flags
results in a change to the test summaries.

This patch instead intercepts dg-options and tailors the list
of additional options based on what the test is trying to do.
It also gets rid of DEFAULT_CFLAGS, which are never useful
for these tests.

Tested on an aarch64-linux-gnu toolchain configured with
--with-cpu=a64fx, pushed to trunk.

Richard


gcc/testsuite/
* lib/gcc-defs.exp (aarch64-arch-dg-options): New procedure.
(aarch64-with-arch-dg-options): Likewise.
* g++.target/aarch64/sve/aarch64-sve.exp: Run the tests inside
aarch64-with-arch-dg-options.  Move the default architecture
flags to the final dg-runtest argument.
* gcc.target/aarch64/sve/aarch64-sve.exp: Likewise.  Dispense with
DEFAULT_CFLAGS.
* gcc.target/aarch64/sve2/aarch64-sve2.exp: Likewise.
---
 .../g++.target/aarch64/sve/aarch64-sve.exp| 10 ++-
 .../gcc.target/aarch64/sve/aarch64-sve.exp| 19 ++
 .../gcc.target/aarch64/sve2/aarch64-sve2.exp  | 14 ++---
 gcc/testsuite/lib/gcc-defs.exp| 62 +++
 4 files changed, 76 insertions(+), 29 deletions(-)

diff --git a/gcc/testsuite/g++.target/aarch64/sve/aarch64-sve.exp 
b/gcc/testsuite/g++.target/aarch64/sve/aarch64-sve.exp
index d4761f2d807..2b850232229 100644
--- a/gcc/testsuite/g++.target/aarch64/sve/aarch64-sve.exp
+++ b/gcc/testsuite/g++.target/aarch64/sve/aarch64-sve.exp
@@ -38,12 +38,10 @@ if { [check_effective_target_aarch64_sve] } {
 set sve_flags "-march=armv8.2-a+sve"
 }
 
-# Turn off any codegen tweaks by default that may affect expected assembly.
-# Tests relying on those should turn them on explicitly.
-set sve_flags "$sve_flags -moverride=tune=none"
-
-# Main loop.
-dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/*.C]] $sve_flags ""
+aarch64-with-arch-dg-options $sve_flags {
+# Main loop.
+dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/*.C]] "" $sve_flags
+}
 
 # All done.
 dg-finish
diff --git a/gcc/testsuite/gcc.target/aarch64/sve/aarch64-sve.exp 
b/gcc/testsuite/gcc.target/aarch64/sve/aarch64-sve.exp
index 1d3f56690e6..439a012ce43 100644
--- a/gcc/testsuite/gcc.target/aarch64/sve/aarch64-sve.exp
+++ b/gcc/testsuite/gcc.target/aarch64/sve/aarch64-sve.exp
@@ -28,26 +28,15 @@ if {![istarget aarch64*-*-*] } then {
 # Load support procs.
 load_lib gcc-dg.exp
 
-# If a testcase doesn't have special options, use these.
-global DEFAULT_CFLAGS
-if ![info exists DEFAULT_CFLAGS] then {
-set DEFAULT_CFLAGS " -ansi -pedantic-errors"
-}
-
 # Initialize `dg'.
 dg-init
 
-# Force SVE if we're not testing it already.
 if { [check_effective_target_aarch64_sve] } {
 set sve_flags ""
 } else {
 set sve_flags "-march=armv8.2-a+sve"
 }
 
-# Turn off any codegen tweaks by default that may affect expected assembly.
-# Tests relying on those should turn them on explicitly.
-set sve_flags "$sve_flags -moverride=tune=none"
-
 # Most of the code-quality tests are written for LP64.  Just do the
 # correctness tests for ILP32.
 if { [check_effective_target_ilp32] } {
@@ -56,9 +45,11 @@ if { [check_effective_target_ilp32] } {
 set pattern "*"
 }
 
-# Main loop.
-dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/$pattern.\[cCS\]]] \
-$sve_flags $DEFAULT_CFLAGS
+aarch64-with-arch-dg-options $sve_flags {
+# Main loop.
+dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/$pattern.\[cCS\]]] \
+   "" $sve_flags
+}
 
 # All done.
 dg-finish
diff --git a/gcc/testsuite/gcc.target/aarch64/sve2/aarch64-sve2.exp 
b/gcc/testsuite/gcc.target/aarch64/sve2/aarch64-sve2.exp
index fcff0d21899..28d61555ff2 100644
--- a/gcc/testsuite/gcc.target/aarch64/sve2/aarch64-sve2.exp
+++ b/gcc/testsuite/gcc.target/aarch64/sve2/aarch64-sve2.exp
@@ -28,12 +28,6 @@ if {![istarget aarch64*-*-*] } then {
 # Load support procs.
 load_lib gcc-dg.exp
 
-# If a testcase doesn't have special options, use these.
-global DEFAULT_CFLAGS
-if ![info exists DEFAULT_CFLAGS] then {
-set DEFAULT_CFLAGS " -ansi -pedantic-errors"
-}
-
 # Initialize `dg'.
 dg-init
 
@@ -44,9 +38,11 @@ if { [check_effective_target_aarch64_sve2] } {
 set sve2_flags "-march=armv8.5-a+sve2"
 }
 
-# Main loop.
-dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/*.\[cCS\]]] \
-$sve2_flags $DEFAULT_CFLAGS
+aarch64-with-arch-dg-options $sve2_flags {
+# Main loop.
+dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/*.\[cCS\]]] \
+   "" $sve2_flags
+}
 
 # All done.
 dg-finish
diff --git a/gcc/testsuite/lib/gcc-defs.exp 

Re: removing toxic emailers

[Iain Sandoe]

Eric S. Raymond  wrote:


Paul Koning via Gcc :
On Apr 14, 2021, at 4:39 PM, Ian Lance Taylor via Gcc   
wrote:

So we don't get the choice between "everyone is welcome" and "some
people are kicked off the list."  We get the choice between "some
people decline to participate because it is unpleasant" and "some
people are kicked off the list."

Given the choice of which group of people are going to participate and
which group are not, which group do we want?


My answer is "it depends".  More precisely, in the past I would have
favored those who decline because the environment is unpleasant --
with the implied assumption being that their objections are
reasonable.  Given the emergency of cancel culture, that assumption
is no longer automatically valid.


I concur on both counts.

You (the GCC project) are no longer in a situation where any random
person saying "your environment is hostile" is a reliable signal of a
real problem.  Safetyism is being gamed by outsiders for purposes that
are not yours and have nothing to do with shipping good code.

Complaints need to be discounted accordingly, to a degree that would
not have been required before the development of a self-reinforcing
culture of complaint and rage-mobbing around 2014.


responding to Ian’s original statement:

I am one of the people who would not be “here” if the environment was
hostile.  That is not a theoretical statement - I declined to contribute to  
one

project already because of the hostility of the interactions.

Although I love to be paid to work on GCC, the truth is that almost all my
contributions are voluntary and I would not choose to spend my spare time
in a conflicted environment, period.

For those of us who are ‘freelance’ these lists and the IRC channel are
pretty much our workplace, it needs to be civilised (for me anyway).

responding in general to this part of the thread.

* The GCC environment is not hostile, and has not been for the 15 or so
 years I’ve been part of the community.

* We would notice if it became so, I’m not sure about the idea that the wool
  can be so easily pulled over our eyes.

I confess to being concerned with the equation “code” > “conduct”; it is not
so in my professional or personal experience.   I have seen an engineering
team suffer great losses of performance from the excesses of one (near  
genius,

but very antisocial) member - the balance was not met.  Likewise, it has been
seen to be a poor balance when there are three gifted individuals in a  
household
but one persecutes the other two (for diagnosed reaons).. again balance is  
not

met

One could see the equation becoming a self-fullfilling prophecy viz.

 *  let us say compilers are complex, and  any significant input over length of 
time
   will require a resonably competent engineer.

 * reasonably competent engineers with a good social habit are welcome 
everywhere

 * reasonably competent engineers with poor social habit are welcome in few 
places.

 - those few places will easily be able to demonstrate that their progress is 
made
  despite the poor atmosphere, with no way to know that something better was 
possible.

responding to the thread in general..

* Please could we try to seek concensus?

 - it is disappointing to see people treating this as some kind of 
point-scoring game
  when to those working on the compiler day to day it is far from a game.

Iain

[PATCH] x86: Use crc32 target option for CRC32 intrinsics

[H.J. Lu via Gcc-patches]

Use crc32 target option for CRC32 intrinsics to support CRC32 intrinsics
without enabling SSE vector instructions.

* config/i386/gnu-property.c
(file_end_indicate_exec_stack_and_gnu_property): Also check
TARGET_CRC32 for GNU_PROPERTY_X86_ISA_1_V2.
* config/i386/i386-c.c (ix86_target_macros_internal): Define
__CRC32__ for -mcrc32.
* config/i386/i386-options.c (ix86_option_override_internal):
Handle PTA_CRC32.  Enable crc32 instruction for -msse4.2.
* config/i386/i386.h (PTA_CRC32): New.
(PTA_X86_64_V2): Add PTA_CRC32.
(PTA_NEHALEM): Likewise.
* config/i386/i386.md (sse4_2_crc32): Remove TARGET_SSE4_2
check.
(sse4_2_crc32di): Likewise.
* config/i386/ia32intrin.h: Use crc32 target option for CRC32
intrinsics.
---
 gcc/config/i386/gnu-property.c |  1 +
 gcc/config/i386/i386-c.c   |  2 ++
 gcc/config/i386/i386-options.c |  8 
 gcc/config/i386/i386.h |  6 --
 gcc/config/i386/i386.md|  4 ++--
 gcc/config/i386/ia32intrin.h   | 28 ++--
 6 files changed, 31 insertions(+), 18 deletions(-)

diff --git a/gcc/config/i386/gnu-property.c b/gcc/config/i386/gnu-property.c
index 4ba04403002..b6a3bdf62ce 100644
--- a/gcc/config/i386/gnu-property.c
+++ b/gcc/config/i386/gnu-property.c
@@ -92,6 +92,7 @@ file_end_indicate_exec_stack_and_gnu_property (void)
   /* GNU_PROPERTY_X86_ISA_1_V2.  */
   if (TARGET_CMPXCHG16B
  || (TARGET_64BIT && TARGET_SAHF)
+ || TARGET_CRC32
  || TARGET_POPCNT
  || TARGET_SSE3
  || TARGET_SSSE3
diff --git a/gcc/config/i386/i386-c.c b/gcc/config/i386/i386-c.c
index be46d0506ad..5ed0de006fb 100644
--- a/gcc/config/i386/i386-c.c
+++ b/gcc/config/i386/i386-c.c
@@ -532,6 +532,8 @@ ix86_target_macros_internal (HOST_WIDE_INT isa_flag,
 def_or_undef (parse_in, "__LZCNT__");
   if (isa_flag & OPTION_MASK_ISA_TBM)
 def_or_undef (parse_in, "__TBM__");
+  if (isa_flag & OPTION_MASK_ISA_CRC32)
+def_or_undef (parse_in, "__CRC32__");
   if (isa_flag & OPTION_MASK_ISA_POPCNT)
 def_or_undef (parse_in, "__POPCNT__");
   if (isa_flag & OPTION_MASK_ISA_FSGSBASE)
diff --git a/gcc/config/i386/i386-options.c b/gcc/config/i386/i386-options.c
index 91da2849c49..959ee163d2f 100644
--- a/gcc/config/i386/i386-options.c
+++ b/gcc/config/i386/i386-options.c
@@ -2162,6 +2162,9 @@ ix86_option_override_internal (bool main_args_p,
if (((processor_alias_table[i].flags & PTA_CX16) != 0)
&& !(opts->x_ix86_isa_flags2_explicit & OPTION_MASK_ISA2_CX16))
  opts->x_ix86_isa_flags2 |= OPTION_MASK_ISA2_CX16;
+   if (((processor_alias_table[i].flags & PTA_CRC32) != 0)
+   && !(opts->x_ix86_isa_flags_explicit & OPTION_MASK_ISA_CRC32))
+ opts->x_ix86_isa_flags |= OPTION_MASK_ISA_CRC32;
if (((processor_alias_table[i].flags & (PTA_POPCNT | PTA_ABM)) != 0)
&& !(opts->x_ix86_isa_flags_explicit & OPTION_MASK_ISA_POPCNT))
  opts->x_ix86_isa_flags |= OPTION_MASK_ISA_POPCNT;
@@ -2617,6 +2620,11 @@ ix86_option_override_internal (bool main_args_p,
 opts->x_ix86_isa_flags
   |= OPTION_MASK_ISA_POPCNT & ~opts->x_ix86_isa_flags_explicit;
 
+  /* Enable crc32 instruction for -msse4.2.  */
+  if (TARGET_SSE4_2_P (opts->x_ix86_isa_flags))
+opts->x_ix86_isa_flags
+  |= OPTION_MASK_ISA_CRC32 & ~opts->x_ix86_isa_flags_explicit;
+
   /* Enable lzcnt instruction for -mabm.  */
   if (TARGET_ABM_P(opts->x_ix86_isa_flags))
 opts->x_ix86_isa_flags
diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
index 97700d797a7..c50f9ab24fa 100644
--- a/gcc/config/i386/i386.h
+++ b/gcc/config/i386/i386.h
@@ -2504,12 +2504,14 @@ constexpr wide_int_bitmask PTA_HRESET (0, 
HOST_WIDE_INT_1U << 23);
 constexpr wide_int_bitmask PTA_KL (0, HOST_WIDE_INT_1U << 24);
 constexpr wide_int_bitmask PTA_WIDEKL (0, HOST_WIDE_INT_1U << 25);
 constexpr wide_int_bitmask PTA_AVXVNNI (0, HOST_WIDE_INT_1U << 26);
+constexpr wide_int_bitmask PTA_CRC32 (0, HOST_WIDE_INT_1U << 27);
 
 constexpr wide_int_bitmask PTA_X86_64_BASELINE = PTA_64BIT | PTA_MMX | PTA_SSE
   | PTA_SSE2 | PTA_NO_SAHF | PTA_FXSR;
 constexpr wide_int_bitmask PTA_X86_64_V2 = (PTA_X86_64_BASELINE
& (~PTA_NO_SAHF))
-  | PTA_CX16 | PTA_POPCNT | PTA_SSE3 | PTA_SSE4_1 | PTA_SSE4_2 | PTA_SSSE3;
+  | PTA_CRC32 | PTA_CX16 | PTA_POPCNT | PTA_SSE3 | PTA_SSE4_1 | PTA_SSE4_2
+  | PTA_SSSE3;
 constexpr wide_int_bitmask PTA_X86_64_V3 = PTA_X86_64_V2
   | PTA_AVX | PTA_AVX2 | PTA_BMI | PTA_BMI2 | PTA_F16C | PTA_FMA | PTA_LZCNT
   | PTA_MOVBE | PTA_XSAVE;
@@ -2519,7 +2521,7 @@ constexpr wide_int_bitmask PTA_X86_64_V4 = PTA_X86_64_V3
 constexpr wide_int_bitmask PTA_CORE2 = PTA_64BIT | PTA_MMX | PTA_SSE | PTA_SSE2
   | PTA_SSE3 | PTA_SSSE3 | PTA_CX16 | PTA_FXSR;
 constexpr wide_int_bitmask PTA_NEHALEM = PTA_CORE2 | PTA_SSE4_1 | PTA_SSE4_2
-  | PTA_POPCNT;
+  | PTA_CRC32 | 

[Bug jit/100096] libgccjit.so.0: Cannot write-enable text segment: Permission denied on NetBSD 9.1

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

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

--- Comment #14 from Jakub Jelinek  ---
Though, DW_AT_producer lines don't really provide the filename and comp_dir,
so guess what I need is better
readelf -wi libgccjit.so.0 | grep -A4 DW_AT_producer | bzip2 -9
output.

[Bug jit/100096] libgccjit.so.0: Cannot write-enable text segment: Permission denied on NetBSD 9.1

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

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

--- Comment #13 from Jakub Jelinek  ---
The important question is what TUs are compiled without -fPIC/-fpic, those with
those options are fine.
So perhaps
readelf -wi libgccjit.so.0 | grep DW_AT_producer | grep -v 'fPIC\|fpic'
?

[Bug target/99767] [9/10/11 Regression] ICE in expand_direct_optab_fn, at internal-fn.c:3360

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

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

--- Comment #5 from Jakub Jelinek  ---
Note, we have already:
  /* Stub out scalar statements that must not survive vectorization.
 Doing this here helps with grouped statements, or statements that
 are involved in patterns.  */
  for (gimple_stmt_iterator gsi = gsi_start_bb (bb);
   !gsi_end_p (gsi); gsi_next ())
{
  gcall *call = dyn_cast  (gsi_stmt (gsi));
  if (call && gimple_call_internal_p (call, IFN_MASK_LOAD))
{
  tree lhs = gimple_get_lhs (call);
  if (!VECTOR_TYPE_P (TREE_TYPE (lhs)))
{
  tree zero = build_zero_cst (TREE_TYPE (lhs));
  gimple *new_stmt = gimple_build_assign (lhs, zero);
  gsi_replace (, new_stmt, true);
}
}
}
in tree-vect-loop.c.
Perhaps we should handle similarly IFN_COND_* ?
Instead of using zero for those perhaps we could just use the last argument of
those calls (i.e. the ELSE part).

[Bug jit/100096] libgccjit.so.0: Cannot write-enable text segment: Permission denied on NetBSD 9.1

[swilde--- via Gcc-bugs]

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

--- Comment #12 from Sascha Wilde  ---
(In reply to Jakub Jelinek from comment #9)
> Perhaps
> readelf -wi libgccjit.so.0 | grep DW_AT_producer
> would make it clearer on what is and what is not built with -fpic/-fPIC.

This runs quite long and only yields lines like:

   DW_AT_producer: (indirect string, offset: 0x155c1): GNU C++14
10.2.0 -mtune=generic -march=i486 -g -O2 -fPIC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables
<30387>   DW_AT_producer: (indirect string, offset: 0x155c1): GNU C++14
10.2.0 -mtune=generic -march=i486 -g -O2 -fPIC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables
<3ccf4>   DW_AT_producer: (indirect string, offset: 0x155c1): GNU C++14
10.2.0 -mtune=generic -march=i486 -g -O2 -fPIC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables

[...]

If this is really helpful to you, I'm fully willing to let it run through all 
the way and provide you with the complete output, of course.

[Bug c++/99387] ICE when mixing CNTTP with deduction guides

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

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

--- Comment #3 from Patrick Palka  ---
Reduced:

template  struct A { };
template  struct B { };

template class Tmpl, Tmpl V>
void f (A);

int main() {
  A{}> x;
  f(x);
}

[Bug c++/100101] New: [11 Regression] ICE with -Wzero-as-null-pointer-constant

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

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

Bug ID: 100101
   Summary: [11 Regression] ICE with
-Wzero-as-null-pointer-constant
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

Compiling the following valid code snippet with
"-Wzero-as-null-pointer-constant" triggers an assertion on trunk.
This is a recent regression from within the last month.

==
template  struct A
{
template  static char foo(U*, int* = 0);
static const bool value = sizeof(foo(static_cast(nullptr))) > 0;
};

template  struct B
{
static const bool value = b;
};

template  struct C
{
typedef B::value> type;
};

template 
void bar() noexcept(A::value && C::type::value) {}

void baz()
{
  bar();
}
==

'
Internal compiler error: Error reporting routines re-entered.
0x8cfbf8 convert_default_arg(tree_node*, tree_node*, tree_node*, int, int)
../../gcc/gcc/cp/call.c:8348
0x8dc177 build_over_call
../../gcc/gcc/cp/call.c:9230
0x8da248 build_new_method_call_1
../../gcc/gcc/cp/call.c:10783
0x8db2af build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../../gcc/gcc/cp/call.c:10858
0xae76dd finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc/gcc/cp/semantics.c:2751
0xa99115 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:20484
0xa969ec tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:19958
0xa957f3 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:19876
0xaa0e48 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:19164
0x06 instantiate_decl(tree_node*, bool, bool)
../../gcc/gcc/cp/pt.c:26117
0x98fc9a maybe_instantiate_decl(tree_node*)
../../gcc/gcc/cp/decl2.c:5460
0x990ff8 maybe_instantiate_decl(tree_node*)
../../gcc/gcc/cp/decl2.c:5663
0x990ff8 mark_used(tree_node*, int)
../../gcc/gcc/cp/decl2.c:5689
0xa951f0 tsubst_qualified_id
../../gcc/gcc/cp/pt.c:16466
0xa96ee8 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:19914
0xaa0e48 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:19164
0xab59ce tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:13384
0xabed23 tsubst_aggr_type
../../gcc/gcc/cp/pt.c:13587
0xa9dd10 tsubst_decl
../../gcc/gcc/cp/pt.c:14847
0xacc3dd instantiate_class_template_1
../../gcc/gcc/cp/pt.c:12031
Please submit a full bug report, [etc.]

[Bug jit/100096] libgccjit.so.0: Cannot write-enable text segment: Permission denied on NetBSD 9.1

[swilde--- via Gcc-bugs]

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

--- Comment #11 from Sascha Wilde  ---
Created attachment 50603
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50603=edit
tut01-hello-world log output

Re: removing toxic emailers

[Eric S. Raymond]

Adrian via Gcc :
> Eric S. Raymond :
> > there is actually a value conflict between being "welcoming" in that
> sense and the actual purpose of this list, which is to ship code.
> 
> Speaking as a "high functioning autist", I'm aware of the difficulties that
> some of us have with social interactions - and also that many of us
> construct a persona or multiple personae to interact with others, a
> phenomenon known as "masking".
> 
> I understand why "Asshole" can function as a viable mask for many people,
> because there are cultures where it's tolerated, particularly in
> remote-working groups like mailing lists, where physical altercations are
> unlikely and no-one has to confront the results of their interactions with
> others if they don't want to.
> 
> It doesn't necessarily follow that "smart" == "asshole" though.

I did not intend that claim.

I intended the weaker observation that driving away a large number of
smart autistic assholes (and non-assholes with poor social skills)
is not necessarily a good trade for the people the project might
recruit by being "more welcoming".

Possibly that *would* be a good trade.  I have decades of experience
that makes me doubt this.  I think the claim needs to be examined
skeptically, not just uncritically accepted because we value being
"nice".

In general, I think efforts to guilt-bomb hackers into being "more
inclusive" should be resisted without a clear grasp on what we might
be throwing away by accepting them.  Just because you live inside a
culture doesn't mean you can predict what mutating its assumptions
will do to it, and we have work to do that should not be casually
disrupted.

Note: I am not an autist myself, so I'm not guarding my own flanks
here.  I'm sort of autist-sympathetic, in that I think it is a good
thing autists can join the hacker culture and have a place where their
quirks are useful and tolerated.  I would be a little sad if that were
lost.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

[Bug jit/100096] libgccjit.so.0: Cannot write-enable text segment: Permission denied on NetBSD 9.1

[swilde--- via Gcc-bugs]

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

--- Comment #10 from Sascha Wilde  ---
(In reply to David Malcolm from comment #8)
> It would be good to know exactly where that error message is being emitted.
> 
> If you add:
>   gcc_jit_context_set_logfile (ctxt, stderr, 0, 0);
> to the test code (e.g. immediately after the call to
> gcc_jit_context_acquire), libgccjit ought to spew out a copious amount of
> logging (see
> https://gcc.gnu.org/onlinedocs/jit/internals/index.html#example-of-log-file)
> 
> Can you attach the log you get please?

With security.pax.mprotect.global=1 it produces no extra output.
I'll attach the output produced when security.pax.mprotect.global is
disabled.

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

[Alex Coplan via Gcc-patches]

Hi all,

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

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

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

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

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

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

Another notable change here is that we only do:

  emit_move_insn (neg_bval, const1_rtx);

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

Testing:
 * Bootstrapped and regtested on arm-linux-gnueabihf, no regressions.
 * Regtested an arm-eabi cross configured with --with-arch=armv8-m.base, no
 regressions. The patch fixes the gcc.dg/ia64-sync-3.c test in this config.

OK for trunk?

Thanks,
Alex

gcc/ChangeLog:

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

gcc/testsuite/ChangeLog:

PR target/99977
* gcc.target/arm/pr99977.c: New test.
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 475fb0d827f..8d19b8a73fd 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -30737,13 +30737,31 @@ arm_split_compare_and_swap (rtx operands[])
 }
   else
 {
-  emit_move_insn (neg_bval, const1_rtx);
   cond = gen_rtx_NE (VOIDmode, rval, oldval);
   if (thumb1_cmpneg_operand (oldval, SImode))
-   emit_unlikely_jump (gen_cbranchsi4_scratch (neg_bval, rval, oldval,
-   label2, cond));
+   {
+ rtx src = rval;
+ if (!satisfies_constraint_L (oldval))
+   {
+ gcc_assert (satisfies_constraint_J (oldval));
+
+ /* For such immediates, ADDS needs the source and destination regs
+to be the same.
+
+Normally this would be handled by RA, but this is all happening
+after RA.  */
+ emit_move_insn (neg_bval, rval);
+ src = neg_bval;
+   }
+
+ emit_unlikely_jump (gen_cbranchsi4_neg_late (neg_bval, src, oldval,
+  label2, cond));
+   }
   else
-   emit_unlikely_jump (gen_cbranchsi4_insn (cond, rval, oldval, label2));
+   {
+ emit_move_insn (neg_bval, const1_rtx);
+ emit_unlikely_jump (gen_cbranchsi4_insn (cond, rval, oldval, label2));
+   }
 }
 
   arm_emit_store_exclusive (mode, neg_bval, mem, newval, use_release);
diff --git a/gcc/config/arm/sync.md b/gcc/config/arm/sync.md
index e4682c039b9..b9fa8702606 100644
--- a/gcc/config/arm/sync.md
+++ b/gcc/config/arm/sync.md
@@ -187,20 +187,20 @@
 ;; Constraints of this pattern must be at least as strict as those of the
 ;; cbranchsi operations in thumb1.md and aim to be 

Re: removing toxic emailers

[Christopher Dimech via Gcc]

> Sent: Thursday, April 15, 2021 at 10:20 PM
> From: "Aaron Gyes" 
> To: gcc@gcc.gnu.org
> Cc: dim...@gmx.com
> Subject: Re: removing toxic emailers
>
> > On Apr 14, 2021, at 5:10 PM, Christopher Dimech  wrote:
> 
> > What are we?  Adults or Children?  You know, as I know, that identities
> > can be made up.  There are many computing specialists who can do that.
> > They can even be made so it looks as though they were sent by you, or 
> > from your work and home address.  They could even be made up to look as
> > though your children sent them.
> 
> That’s far out man, like outer space far out. It’s fortunate, though, that
> despite this confusing world of tricksters you find yourself in, you have
> maintained the kind of confidence and composure required to put in thisn 
> insincere
> kind of low-effort trolling to defend your principals, in a serious discussion
> that were it to go the wrong way, could well potentially also require you to 
> take
> responsibility for your behavior in public. 

I can easily write articles in the international press and take interviews.
 
> > So my point here — if it’s okay just to have a point when people should 
> > already be drinking and dancing — my point is let’s not get confused. 
> 
> 
> Do you imagine people may one day solemnly read through these archives here, 
> shaking
> their heads at how Mr. Stallman was treated, how mean and irrational it all 
> was, even as
> even you tried your best to outwit the members into doing the right thing… 
> Just as people do
> when reading Socrates' Apology, or Tacitus talking about the suffering under 
> emperors?
> 
> That would be sad because the annals of the mailing list will be available 
> verbatim, probably
> Literally forever, so obviously that can’t happen.

Do you plan to start quoting me?  Thank you.

> Aaron

[Bug c++/99963] [11 Regression] [concepts] template vs concept auto reports ambiguous overload

[ldalessandro at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Luke Dalessandro  ---
I understand. Thank you (I've forwarded this on to clang, which _does_ accept
the ambiguous form).

Re: removing toxic emailers

[Christopher Dimech via Gcc]

> Sent: Thursday, April 15, 2021 at 9:18 PM
> From: "Jonathan Wakely" 
> To: "Christopher Dimech" 
> Cc: "Nathan Sidwell" , "gcc@gcc.gnu.org" 
> Subject: Re: removing toxic emailers
>
> On Thu, 15 Apr 2021 at 02:18, Christopher Dimech wrote:
> > What are we?  Adults or Children?  You know, as I know, that identities
> > can be made up.  There are many computing specialists who can do that.
> > They can even be made so it looks as though they were sent by you, or
> > from your work and home address.  They could even be made up to look as
> > though your children sent them.
> >
> > I remember a closing comment by Eben Moglen during a full-day program at
> > Columbia Law School in 2016.  And I agree with him.
> >
> > So my point here — if it’s okay just to have a point when people should 
> > already be drinking and dancing — my point is let’s not get confused. This 
> > is not war time. This is diplomacy time. Skill counts. Agility counts. 
> > Discretion counts. Long credibility counts. Ammunition? Ammunition is 
> > worthless because wherever we fire it, we work everywhere and it’s only 
> > going to hit us. - Eben Moglen
> 
> Interesting choice of quote from the guy who made the very first reply
> to the whole thing with "What is this?  The usual rant of freaked out
> madness!!!"
> https://gcc.gnu.org/pipermail/gcc/2021-March/235092.html

Yes, I am that individual who was quoted saying that on the international
press.  Don't you have something bad to say about Eben Moglen too.  
He is proud of what anarchism achieved, a path that is certainly at odds
with Nathan's arguments.  
 
> and followed soon after with "More rats for the wood pile. "
> https://gcc.gnu.org/pipermail/gcc/2021-March/235109.html

Correct.  He brought it upon himself.
 
> But now you're lecturing us about diplomacy.

Something you and Nathan are incapable of.  

I'd just like to eject the jerks... And yes, I fully realize there are
other ways I can choose to not associate with them here. - Nathan


> Fuck off, Christopher. Just fuck off. You've added nothing of value to
> this entire discussion, just riled people up and stirred up trouble.
> Fuck off.

That is a dream, because you have to be asleep to believe it.

[Bug target/100067] Unexpected warning for -mcpu=neoverse-n1 when configured with --with-fpu

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

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

--- Comment #5 from Christophe Lyon  ---
(In reply to Richard Earnshaw from comment #4)
> (In reply to Christophe Lyon from comment #3)
> > Unfortunately this is causing many regressions in the GCC testsuite.
> 
> Sigh!  I'm not entirely surprised.  I suspect most of this is testisms,
> though.
> 
:-)
Yes, probably.

> > --target arm-none-linux-gnueabi
> > --with-mode arm
> > --with-cpu cortex-a9
> > --with-fpu default
> > Dejagnu flags: -march=armv5t
> > gcc.target/arm/aes-fuse-1.c is compiled with
> > 
> > -march=armv5t -mfpu=crypto-neon-fp-armv8 -mfloat-abi=softfp -mcpu=cortex-a72
> > cc1: warning: switch '-mcpu=cortex-a72' conflicts with switch 
> > '-march=armv5t'
> 
> The warning is correct.  That's a stupid combination to pass to the compiler
> (arch=armv5 and cpu=).  What's less clear is why this wasn't
> happening before.

Indeed. I just checked the command line was the same before your patch (i.e.
your patch has no impact on the effective-targets that could change the flags
used)

FTR, even before your patch there were several such annoying warnings.

Re: [PATCH] testsuite: Fix unroll-and-jam.c on IBM Z

[Richard Biener via Gcc-patches]

On Thu, Apr 15, 2021 at 2:51 PM Stefan Schulze Frielinghaus via
Gcc-patches  wrote:
>
> For z10 and newer inner loops are completely unrolled which leaves no
> inner loops to jam which renders this testcase to fail.  Reverting
> max-completely-peel-times to the default value fixes this testcase.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/unroll-and-jam.c: Revert max-completely-peel-times to
> the default value on IBM Z.
>
> Ok for mainline?

OK.

> ---
>  gcc/testsuite/gcc.dg/unroll-and-jam.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/gcc/testsuite/gcc.dg/unroll-and-jam.c 
> b/gcc/testsuite/gcc.dg/unroll-and-jam.c
> index 7eb64217a05..b8f4f16dc74 100644
> --- a/gcc/testsuite/gcc.dg/unroll-and-jam.c
> +++ b/gcc/testsuite/gcc.dg/unroll-and-jam.c
> @@ -1,5 +1,6 @@
>  /* { dg-do run } */
>  /* { dg-options "-O3 -floop-unroll-and-jam -fno-tree-loop-im --param 
> unroll-jam-min-percent=0 -fdump-tree-unrolljam-details" } */
> +/* { dg-additional-options "--param max-completely-peel-times=16" { target { 
> s390*-*-* } } } */
>  /* { dg-require-effective-target int32plus } */
>
>  #include 
> --
> 2.23.0
>

[Bug jit/100096] libgccjit.so.0: Cannot write-enable text segment: Permission denied on NetBSD 9.1

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

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

--- Comment #9 from Jakub Jelinek  ---
So I see 236 R_386_RELATIVE text relocations and 231 other text relocations.
Seems the compiler itself is built with -fpic/-fPIC, but some of the libraries
that are linked into it are not, e.g. libintl.a, at least parts of libgcc (the
dfp stuff), libbacktrace.
Perhaps
readelf -wi libgccjit.so.0 | grep DW_AT_producer
would make it clearer on what is and what is not built with -fpic/-fPIC.
On i686-linux I certainly can't reproduce this, there are no text relocations.

Re: removing toxic emailers

[Eric S. Raymond]

Paul Koning via Gcc :
> > On Apr 14, 2021, at 4:39 PM, Ian Lance Taylor via Gcc  
> > wrote:
> > So we don't get the choice between "everyone is welcome" and "some
> > people are kicked off the list."  We get the choice between "some
> > people decline to participate because it is unpleasant" and "some
> > people are kicked off the list."
> > 
> > Given the choice of which group of people are going to participate and
> > which group are not, which group do we want?
> 
> My answer is "it depends".  More precisely, in the past I would have
> favored those who decline because the environment is unpleasant --
> with the implied assumption being that their objections are
> reasonable.  Given the emergency of cancel culture, that assumption
> is no longer automatically valid.

I concur on both counts.

You (the GCC project) are no longer in a situation where any random
person saying "your environment is hostile" is a reliable signal of a
real problem.  Safetyism is being gamed by outsiders for purposes that
are not yours and have nothing to do with shipping good code.

Complaints need to be discounted accordingly, to a degree that would
not have been required before the development of a self-reinforcing
culture of complaint and rage-mobbing around 2014.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

[Bug target/100067] Unexpected warning for -mcpu=neoverse-n1 when configured with --with-fpu

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

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

--- Comment #4 from Richard Earnshaw  ---
(In reply to Christophe Lyon from comment #3)
> Unfortunately this is causing many regressions in the GCC testsuite.

Sigh!  I'm not entirely surprised.  I suspect most of this is testisms, though.

> 
> For instance:
> --target arm-none-linux-gnueabi
> --with-mode arm
> --with-cpu cortex-a9
> --with-fpu default
> gcc.target/arm/armv8_2-fp16-neon-1.c is compiled with
> -mfloat-abi=softfp -march=armv8.2-a+fp16
> 
> /gcc/testsuite/gcc.target/arm/armv8_2-fp16-neon-1.c: In function
> 'test_vceqz_16x4':
> /gcc/testsuite/gcc.target/arm/armv8_2-fp16-neon-1.c:139:13: warning:
> implicit declaration of function 'vceqz_f16'; did you mean 'vceqq_u16'?
> [-Wimplicit-function-declaration]
> /gcc/testsuite/gcc.target/arm/armv8_2-fp16-neon-1.c:10:25: note: in
> definition of macro 'MSTRCAT'
> /gcc/testsuite/gcc.target/arm/armv8_2-fp16-neon-1.c:139:1: note: in
> expansion of macro 'VCMP1_TEST'
> /gcc/testsuite/gcc.target/arm/armv8_2-fp16-neon-1.c:139:13: error:
> incompatible types when returning type 'int' but 'uint16x4_t' was expected
> [...]

It's not obvious what's happening here.  I'll look.

> 
> 
> --target arm-none-linux-gnueabi
> --with-mode arm
> --with-cpu cortex-a9
> --with-fpu default
> Dejagnu flags: -march=armv5t
> gcc.target/arm/aes-fuse-1.c is compiled with
> 
> -march=armv5t -mfpu=crypto-neon-fp-armv8 -mfloat-abi=softfp -mcpu=cortex-a72
> cc1: warning: switch '-mcpu=cortex-a72' conflicts with switch '-march=armv5t'

The warning is correct.  That's a stupid combination to pass to the compiler
(arch=armv5 and cpu=).  What's less clear is why this wasn't happening
before.

Re: removing toxic emailers

[Eric S. Raymond]

Joseph Myers :
> On Wed, 14 Apr 2021, Eric S. Raymond wrote:
> 
> > I'm not judging RMS's behavior (or anyone else's) one way or
> > another. I am simply pointing out that there is a Schelling point in
> > possible community norms that is well expressed as "you shall judge by
> > the code alone".  This list is not full of contention from affirming
> > that norm, but from some peoples' attempt to repudiate it.
> 
> Since RMS, FSF and GNU are not contributing code to the toolchain and 
> haven't been for a very long time, the most similar basis to judge them 
> would seem to be based on their interactions with toolchain development.  
> I think those interactions generally show that FSF and GNU have been bad 
> umbrella organizations for the toolchain since at least when the GCC 4.4 
> release was delayed waiting for a slow process of developing the GCC 
> Runtime Library Exception.

I do not have standing to argue this point.

I will, however, point out that it is a very *different* point from
"RMS has iupset some people and should therefore be canceled".
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

[Bug jit/100096] libgccjit.so.0: Cannot write-enable text segment: Permission denied on NetBSD 9.1

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

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

--- Comment #8 from David Malcolm  ---
(In reply to Sascha Wilde from comment #6)
> However, please note that
> "Cannot write-enable text segment: Permission denied"
> is the more pressing problem, as it prevents libgccjit to be used
> on NetBSD with default security settings.

It would be good to know exactly where that error message is being emitted.

If you add:
  gcc_jit_context_set_logfile (ctxt, stderr, 0, 0);
to the test code (e.g. immediately after the call to gcc_jit_context_acquire),
libgccjit ought to spew out a copious amount of logging (see
https://gcc.gnu.org/onlinedocs/jit/internals/index.html#example-of-log-file)

Can you attach the log you get please?

[Bug jit/100096] libgccjit.so.0: Cannot write-enable text segment: Permission denied on NetBSD 9.1

[schwab--- via Gcc-bugs]

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

--- Comment #7 from Andreas Schwab  ---
That's just the consequence of text relocations.

[Bug jit/100096] libgccjit.so.0: Cannot write-enable text segment: Permission denied on NetBSD 9.1

[swilde--- via Gcc-bugs]

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

--- Comment #6 from Sascha Wilde  ---
However, please note that
"Cannot write-enable text segment: Permission denied"
is the more pressing problem, as it prevents libgccjit to be used
on NetBSD with default security settings.

Re: [pushed] c++: debug location of variable cleanups [PR88742]

[Christophe Lyon via Gcc-patches]

Hi,

On Wed, 14 Apr 2021 at 02:20, Jason Merrill via Gcc-patches
 wrote:
>
> PR49951 complained about the debugger jumping back to the declaration of a
> local variable when we run its destructor.  That was fixed in 4.7, but broke
> again in 4.8.  PR58123 fixed an inconsistency in the behavior, but not the
> jumping around.  This patch addresses the issue by setting EXPR_LOCATION on
> a cleanup destructor call to the location of the closing brace of the
> compound-statement, or whatever token ends the scope of the variable.
>
> The change to cp_parser_compound_statement is so input_location is the }
> rather than the ; of the last substatement.
>
> Tested x86_64-pc-linux-gnu, applying to trunk.
>
> gcc/cp/ChangeLog:
>
> PR c++/88742
> PR c++/49951
> PR c++/58123
> * semantics.c (set_cleanup_locs): New.
> (do_poplevel): Call it.
> * parser.c (cp_parser_compound_statement): Consume the }
> before finish_compound_stmt.
>
> gcc/testsuite/ChangeLog:
>
> PR c++/88742
> * g++.dg/debug/cleanup1.C: New test.
> * c-c++-common/Wimplicit-fallthrough-6.c: Adjust diagnostic line.
> * c-c++-common/Wimplicit-fallthrough-7.c: Likewise.
> * g++.dg/cpp2a/constexpr-dtor3.C: Likewise.

This change is causing a regression on arm:
FAIL: g++.dg/cpp2a/constexpr-dtor3.C  -std=c++2a  (test for warnings, line 154)

the logs contain:
[...]
/gcc/testsuite/g++.dg/cpp2a/constexpr-dtor3.C:131:22:   in 'constexpr'
expansion of '((W5*)(& w13))->W5::~W5()'
/gcc/testsuite/g++.dg/cpp2a/constexpr-dtor3.C:72:34: error: inline
assembly is not a constant expression
/gcc/testsuite/g++.dg/cpp2a/constexpr-dtor3.C:72:34: note: only
unevaluated inline assembly is allowed in a 'constexpr' function in
C++20
/gcc/testsuite/g++.dg/cpp2a/constexpr-dtor3.C:133:35:   in 'constexpr'
expansion of '((W6*))->W6::~W6()'
/gcc/testsuite/g++.dg/cpp2a/constexpr-dtor3.C:80:34: error: inline
assembly is not a constant expression
/gcc/testsuite/g++.dg/cpp2a/constexpr-dtor3.C:80:34: note: only
unevaluated inline assembly is allowed in a 'constexpr' function in
C++20
/gcc/testsuite/g++.dg/cpp2a/constexpr-dtor3.C: At global scope:
/gcc/testsuite/g++.dg/cpp2a/constexpr-dtor3.C:156:23:   in 'constexpr'
expansion of 'f4()'
/gcc/testsuite/g++.dg/cpp2a/constexpr-dtor3.C:152:12:   in 'constexpr'
expansion of '(& w13)->W7::~W7()'
/gcc/testsuite/g++.dg/cpp2a/constexpr-dtor3.C:88:34: error: inline
assembly is not a constant expression
/gcc/testsuite/g++.dg/cpp2a/constexpr-dtor3.C:88:34: note: only
unevaluated inline assembly is allowed in a 'constexpr' function in
C++20
/gcc/testsuite/g++.dg/cpp2a/constexpr-dtor3.C:165:23:   in 'constexpr'
expansion of 'f5()'
[...]

Can you check?

Thanks

Christophe

> * g++.dg/ext/constexpr-attr-cleanup1.C: Likewise.
> * g++.dg/tm/inherit2.C: Likewise.
> * g++.dg/tm/unsafe1.C: Likewise.
> * g++.dg/warn/Wimplicit-fallthrough-1.C: Likewise.
> * g++.dg/gcov/gcov-2.C: Adjust coverage counts.
> ---
>  gcc/cp/parser.c   |  5 ++-
>  gcc/cp/semantics.c| 19 +
>  .../c-c++-common/Wimplicit-fallthrough-6.c| 16 
>  .../c-c++-common/Wimplicit-fallthrough-7.c|  4 +-
>  gcc/testsuite/g++.dg/cpp2a/constexpr-dtor3.C  |  4 +-
>  gcc/testsuite/g++.dg/debug/cleanup1.C | 41 +++
>  .../g++.dg/ext/constexpr-attr-cleanup1.C  |  4 +-
>  gcc/testsuite/g++.dg/gcov/gcov-2.C|  4 +-
>  gcc/testsuite/g++.dg/tm/inherit2.C|  4 +-
>  gcc/testsuite/g++.dg/tm/unsafe1.C |  4 +-
>  .../g++.dg/warn/Wimplicit-fallthrough-1.C |  4 +-
>  11 files changed, 85 insertions(+), 24 deletions(-)
>  create mode 100644 gcc/testsuite/g++.dg/debug/cleanup1.C
>
> diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
> index 8b7801b2be7..aec3aa3587f 100644
> --- a/gcc/cp/parser.c
> +++ b/gcc/cp/parser.c
> @@ -12126,11 +12126,12 @@ cp_parser_compound_statement (cp_parser *parser, 
> tree in_statement_expr,
>if (function_body)
>  maybe_splice_retval_cleanup (compound_stmt);
>
> -  /* Finish the compound-statement.  */
> -  finish_compound_stmt (compound_stmt);
>/* Consume the `}'.  */
>braces.require_close (parser);
>
> +  /* Finish the compound-statement.  */
> +  finish_compound_stmt (compound_stmt);
> +
>return compound_stmt;
>  }
>
> diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
> index 8eaaaefe2d6..125772238d3 100644
> --- a/gcc/cp/semantics.c
> +++ b/gcc/cp/semantics.c
> @@ -602,6 +602,22 @@ add_decl_expr (tree decl)
>add_stmt (r);
>  }
>
> +/* Set EXPR_LOCATION of the cleanups of any CLEANUP_STMT in STMTS to LOC.  */
> +
> +static void
> +set_cleanup_locs (tree stmts, location_t loc)
> +{
> +  if (TREE_CODE (stmts) == CLEANUP_STMT)
> +{
> +  protected_set_expr_location (CLEANUP_EXPR (stmts), loc);
> +  set_cleanup_locs (CLEANUP_BODY (stmts), loc);
> +}
> +  else if (TREE_CODE 

[Bug jit/100096] libgccjit.so.0: Cannot write-enable text segment: Permission denied on NetBSD 9.1

[swilde--- via Gcc-bugs]

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

--- Comment #5 from Sascha Wilde  ---
(In reply to Jakub Jelinek from comment #3)
> So, how many text relocations do you see?
> E.g. readelf -Wa libgccjit.so.0 output attached here would be useful.

I attached the requested output (its nearly 9MiB uncompressed, so used bzip2 
to stay below the file size limit of 1000K)

[Bug c++/100091] [11 Regression] decltype([]{}) rejected as a default template parameter

[pilarlatiesa at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Pilar Latiesa  ---
> Of course such use of a lambda is quite pointless 

Not as pointless as it might appear. This defaulted template parameter enables
a form of stateful metaprogramming:

#include 

template
class T {};

static_assert(!std::is_same_v, T>); // passes with GCC 10

I don’t know if that is valid C++, and would love to know whether or not it is.

On the other hand, sometimes it is convenient to use lambdas this way:

template
class my_functor
{
  [[no_unique_address]] TOp const Op = {};
};

[Bug jit/100096] libgccjit.so.0: Cannot write-enable text segment: Permission denied on NetBSD 9.1

[swilde--- via Gcc-bugs]

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

--- Comment #4 from Sascha Wilde  ---
Created attachment 50602
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50602=edit
Output of: readelf -Wa /usr/local/lib/libgccjit.so

[Bug target/100067] Unexpected warning for -mcpu=neoverse-n1 when configured with --with-fpu

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

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #3 from Christophe Lyon  ---
Unfortunately this is causing many regressions in the GCC testsuite.

For instance:
--target arm-none-linux-gnueabi
--with-mode arm
--with-cpu cortex-a9
--with-fpu default
gcc.target/arm/armv8_2-fp16-neon-1.c is compiled with
-mfloat-abi=softfp -march=armv8.2-a+fp16

/gcc/testsuite/gcc.target/arm/armv8_2-fp16-neon-1.c: In function
'test_vceqz_16x4':
/gcc/testsuite/gcc.target/arm/armv8_2-fp16-neon-1.c:139:13: warning: implicit
declaration of function 'vceqz_f16'; did you mean 'vceqq_u16'?
[-Wimplicit-function-declaration]
/gcc/testsuite/gcc.target/arm/armv8_2-fp16-neon-1.c:10:25: note: in definition
of macro 'MSTRCAT'
/gcc/testsuite/gcc.target/arm/armv8_2-fp16-neon-1.c:139:1: note: in expansion
of macro 'VCMP1_TEST'
/gcc/testsuite/gcc.target/arm/armv8_2-fp16-neon-1.c:139:13: error: incompatible
types when returning type 'int' but 'uint16x4_t' was expected
[...]


--target arm-none-linux-gnueabi
--with-mode arm
--with-cpu cortex-a9
--with-fpu default
Dejagnu flags: -march=armv5t
gcc.target/arm/aes-fuse-1.c is compiled with

-march=armv5t -mfpu=crypto-neon-fp-armv8 -mfloat-abi=softfp -mcpu=cortex-a72
cc1: warning: switch '-mcpu=cortex-a72' conflicts with switch '-march=armv5t'
FAIL: gcc.target/arm/aes-fuse-1.c (test for excess errors)

For a full picture of the regressions I noticed:
https://people.linaro.org/~christophe.lyon/cross-validation/gcc/trunk/r11-8168-gd1e4368ddb76a92c44f824c8e4ca1a3de8149342/report-build-info.html

(click on "log" to download the corresponding gcc.log and see the error
messages)
(you can ignore the regressions in g++, they are caused by a previous commit)

[Bug jit/100096] libgccjit.so.0: Cannot write-enable text segment: Permission denied on NetBSD 9.1

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

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

--- Comment #3 from Jakub Jelinek  ---
So, how many text relocations do you see?
E.g. readelf -Wa libgccjit.so.0 output attached here would be useful.

[Bug jit/100096] libgccjit.so.0: Cannot write-enable text segment: Permission denied on NetBSD 9.1

[swilde--- via Gcc-bugs]

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

--- Comment #2 from Sascha Wilde  ---
> How did you build libgccjit.so.0?
> Have you used --enable-host-shared during configure?

Yes, AFAIK this is mandatory?

Here is the configuration I used:

../gcc-10.2.0/configure \
  --with-bugurl='https://github.com/jashandeep-sohi/libgccjit-pkg/issues' \
  --enable-shared \
  --enable-host-shared \
  --enable-checking=release \
  --enable-languages=jit \
  --disable-multilib \
  --disable-libssp \
  --disable-lto \
  --disable-libquadmath \
  --disable-liboffloadmic \
  --disable-libada \
  --disable-libsanitizer \
  --disable-libquadmath-support \
  --disable-libgomp \
  --disable-libvtv \
  --disable-libsanitizer \
  --with-gmp=/usr/local \
  --with-mpc=/usr/local \
  --with-mpfr=/usr/local