[PATCH 4/6] Backport Power10 PC-relative tests.

[Michael Meissner via Gcc-patches]

Backport Power10 PC-relative tests.

These tests whether the power10 PC-relative load/store instructions are
generated.  These tests have been on the master branch since June.  No changes
were needed to backport them to the GCC 10 branch.  Can I check these into the
GCC 10 branch?

gcc/testsuite/
2020-08-03  Michael Meissner  

Backport from the master branch:
2020-06-28  David Edelsohn  

* gcc.target/powerpc/prefix-pcrel-dd.c: Require DFP.
* gcc.target/powerpc/prefix-pcrel-sd.c: Require DFP.
* gcc.target/powerpc/prefix-pcrel-kf.c: Require float128.

2020-06-27  Michael Meissner  

* gcc.target/powerpc/prefix-pcrel-dd.c: New test.
* gcc.target/powerpc/prefix-pcrel-df.c: New test.
* gcc.target/powerpc/prefix-pcrel-di.c: New test.
* gcc.target/powerpc/prefix-pcrel-hi.c: New test.
* gcc.target/powerpc/prefix-pcrel-kf.c: New test.
* gcc.target/powerpc/prefix-pcrel-qi.c: New test.
* gcc.target/powerpc/prefix-pcrel-sd.c: New test.
* gcc.target/powerpc/prefix-pcrel-sf.c: New test.
* gcc.target/powerpc/prefix-pcrel-si.c: New test.
* gcc.target/powerpc/prefix-pcrel-udi.c: New test.
* gcc.target/powerpc/prefix-pcrel-uhi.c: New test.
* gcc.target/powerpc/prefix-pcrel-uqi.c: New test.
* gcc.target/powerpc/prefix-pcrel-usi.c: New test.
* gcc.target/powerpc/prefix-pcrel-v2df.c: New test.
* gcc.target/powerpc/prefix-pcrel.h: Include file for new tests.

---
 gcc/testsuite/gcc.target/powerpc/prefix-pcrel-dd.c | 14 
 gcc/testsuite/gcc.target/powerpc/prefix-pcrel-df.c | 13 +++
 gcc/testsuite/gcc.target/powerpc/prefix-pcrel-di.c | 14 
 gcc/testsuite/gcc.target/powerpc/prefix-pcrel-hi.c | 13 +++
 gcc/testsuite/gcc.target/powerpc/prefix-pcrel-kf.c | 14 
 gcc/testsuite/gcc.target/powerpc/prefix-pcrel-qi.c | 13 +++
 gcc/testsuite/gcc.target/powerpc/prefix-pcrel-sd.c | 16 +
 gcc/testsuite/gcc.target/powerpc/prefix-pcrel-sf.c | 13 +++
 gcc/testsuite/gcc.target/powerpc/prefix-pcrel-si.c | 13 +++
 .../gcc.target/powerpc/prefix-pcrel-udi.c  | 14 
 .../gcc.target/powerpc/prefix-pcrel-uhi.c  | 13 +++
 .../gcc.target/powerpc/prefix-pcrel-uqi.c  | 13 +++
 .../gcc.target/powerpc/prefix-pcrel-usi.c  | 13 +++
 .../gcc.target/powerpc/prefix-pcrel-v2df.c | 13 +++
 gcc/testsuite/gcc.target/powerpc/prefix-pcrel.h| 41 ++
 15 files changed, 230 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/prefix-pcrel-dd.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/prefix-pcrel-df.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/prefix-pcrel-di.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/prefix-pcrel-hi.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/prefix-pcrel-kf.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/prefix-pcrel-qi.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/prefix-pcrel-sd.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/prefix-pcrel-sf.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/prefix-pcrel-si.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/prefix-pcrel-udi.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/prefix-pcrel-uhi.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/prefix-pcrel-uqi.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/prefix-pcrel-usi.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/prefix-pcrel-v2df.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/prefix-pcrel.h

diff --git a/gcc/testsuite/gcc.target/powerpc/prefix-pcrel-dd.c 
b/gcc/testsuite/gcc.target/powerpc/prefix-pcrel-dd.c
new file mode 100644
index 000..053ca32
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/prefix-pcrel-dd.c
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_pcrel } */
+/* { dg-require-effective-target dfp } */
+/* { dg-options "-O2 -mdejagnu-cpu=power10" } */
+
+/* Tests whether pc-relative prefixed instructions are generated for the
+   _Decimal64 type.  */
+
+#define TYPE _Decimal64
+
+#include "prefix-pcrel.h"
+
+/* { dg-final { scan-assembler-times {\mplfd\M}  2 } } */
+/* { dg-final { scan-assembler-times {\mpstfd\M} 2 } } */
diff --git a/gcc/testsuite/gcc.target/powerpc/prefix-pcrel-df.c 
b/gcc/testsuite/gcc.target/powerpc/prefix-pcrel-df.c
new file mode 100644
index 000..b7fd84e
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/prefix-pcrel-df.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_pcrel } */
+/* { dg-options "-O2 -mdejagnu-cpu=power10" } */
+
+/* Tests whether pc-relative prefixed instructions are generated for the
+   double type.  */
+
+#define TYPE double
+
+#include "prefix-pcrel.h"
+
+/* { dg-final { scan-assembler-times {\mplfd\M}  2 } } */
+/* { dg-final { scan-assembler-times {\mpstfd\M} 2 } } */
diff --git 

[PATCH 3/6] Backport Power10 prefix tests with large offsets.

[Michael Meissner via Gcc-patches]

Backport Power10 prefix tests with large offsets.

These tests test whether a prefixed instruction is generated if the offset is
larger than the 16-bits used by the traditional instructions, but smaller than
the 34-bit limit of the prefixed instructions.  These tests have been on the
master branch since June, and no changes were needed for GCC 10.  Can I check
these into the GCC 10 branch?

gcc/testsuite/
2020-08-03  Michael Meissner  

Backport from the master branch:
2020-06-28  David Edelsohn  

* gcc.target/powerpc/prefix-large-dd.c: Require DFP.
* gcc.target/powerpc/prefix-large-sd.c: Require DFP.
* gcc.target/powerpc/prefix-large-kf.c: Require float128.

2020-06-27  Michael Meissner  

* gcc.target/powerpc/prefix-large-dd.c: New test.
* gcc.target/powerpc/prefix-large-df.c: New test.
* gcc.target/powerpc/prefix-large-di.c: New test.
* gcc.target/powerpc/prefix-large-hi.c: New test.
* gcc.target/powerpc/prefix-large-kf.c: New test.
* gcc.target/powerpc/prefix-large-qi.c: New test.
* gcc.target/powerpc/prefix-large-sd.c: New test.
* gcc.target/powerpc/prefix-large-sf.c: New test.
* gcc.target/powerpc/prefix-large-si.c: New test.
* gcc.target/powerpc/prefix-large-udi.c: New test.
* gcc.target/powerpc/prefix-large-uhi.c: New test.
* gcc.target/powerpc/prefix-large-uqi.c: New test.
* gcc.target/powerpc/prefix-large-usi.c: New test.
* gcc.target/powerpc/prefix-large-v2df.c: New test.
* gcc.target/powerpc/prefix-large.h: Include file for new tests.

---
 gcc/testsuite/gcc.target/powerpc/prefix-large-dd.c | 14 
 gcc/testsuite/gcc.target/powerpc/prefix-large-df.c | 13 +++
 gcc/testsuite/gcc.target/powerpc/prefix-large-di.c | 14 
 gcc/testsuite/gcc.target/powerpc/prefix-large-hi.c | 13 +++
 gcc/testsuite/gcc.target/powerpc/prefix-large-kf.c | 14 
 gcc/testsuite/gcc.target/powerpc/prefix-large-qi.c | 13 +++
 gcc/testsuite/gcc.target/powerpc/prefix-large-sd.c | 20 +++
 gcc/testsuite/gcc.target/powerpc/prefix-large-sf.c | 13 +++
 gcc/testsuite/gcc.target/powerpc/prefix-large-si.c | 13 +++
 .../gcc.target/powerpc/prefix-large-udi.c  | 14 
 .../gcc.target/powerpc/prefix-large-uhi.c  | 13 +++
 .../gcc.target/powerpc/prefix-large-uqi.c  | 13 +++
 .../gcc.target/powerpc/prefix-large-usi.c  | 13 +++
 .../gcc.target/powerpc/prefix-large-v2df.c | 13 +++
 gcc/testsuite/gcc.target/powerpc/prefix-large.h| 40 ++
 15 files changed, 233 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/prefix-large-dd.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/prefix-large-df.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/prefix-large-di.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/prefix-large-hi.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/prefix-large-kf.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/prefix-large-qi.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/prefix-large-sd.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/prefix-large-sf.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/prefix-large-si.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/prefix-large-udi.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/prefix-large-uhi.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/prefix-large-uqi.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/prefix-large-usi.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/prefix-large-v2df.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/prefix-large.h

diff --git a/gcc/testsuite/gcc.target/powerpc/prefix-large-dd.c 
b/gcc/testsuite/gcc.target/powerpc/prefix-large-dd.c
new file mode 100644
index 000..a498b18
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/prefix-large-dd.c
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_prefixed_addr } */
+/* { dg-require-effective-target dfp } */
+/* { dg-options "-O2 -mdejagnu-cpu=power10" } */
+
+/* Tests whether prefixed instructions with large numeric offsets are generated
+   for the _Decimal64 type.  */
+
+#define TYPE _Decimal64
+
+#include "prefix-large.h"
+
+/* { dg-final { scan-assembler-times {\mplfd\M}  2 } } */
+/* { dg-final { scan-assembler-times {\mpstfd\M} 2 } } */
diff --git a/gcc/testsuite/gcc.target/powerpc/prefix-large-df.c 
b/gcc/testsuite/gcc.target/powerpc/prefix-large-df.c
new file mode 100644
index 000..49a049b
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/prefix-large-df.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_prefixed_addr } */
+/* { dg-options "-O2 -mdejagnu-cpu=power10" } */
+
+/* Tests whether prefixed instructions with large numeric offsets are generated
+   for the double type.  */
+
+#define TYPE double
+

[PATCH 2/6] Backport Power10 prefix test for DS/DQ.

[Michael Meissner via Gcc-patches]

Backport Power10 prefix test for DS/DQ.

This patch adds a test to make sure offsets that are not legal for non-prefixed
DS/DQ instructions are legal for a prefixed instruction.  This test has been in
the master branch since June, and no changes were needed to backport it to GCC
10.  Can I check this into the GCC 10 branch?

gcc/testsuite/
2020-08-03  Michael Meissner  

Backport from the master branch:
2020-06-27  Michael Meissner  

* gcc.target/powerpc/prefix-ds-dq.c: New test.

---
 gcc/testsuite/gcc.target/powerpc/prefix-ds-dq.c | 161 
 1 file changed, 161 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/prefix-ds-dq.c

diff --git a/gcc/testsuite/gcc.target/powerpc/prefix-ds-dq.c 
b/gcc/testsuite/gcc.target/powerpc/prefix-ds-dq.c
new file mode 100644
index 000..554cd0c
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/prefix-ds-dq.c
@@ -0,0 +1,161 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_prefixed_addr } */
+/* { dg-require-effective-target lp64 } */
+/* { dg-options "-O2 -mdejagnu-cpu=power10" } */
+
+/* Tests whether we generate a prefixed load/store operation for addresses that
+   don't meet DS/DQ offset constraints.  64-bit is needed for testing the use
+   of the PLWA instruciton.  */
+
+struct packed_struct
+{
+  long long pad;   /* offset  0 bytes.  */
+  unsigned char pad_uc;/* offset  8 bytes.  */
+  unsigned char uc;/* offset  9 bytes.  */
+
+  unsigned char pad_sc[sizeof (long long) - sizeof (unsigned char)];
+  unsigned char sc;/* offset  17 bytes.  */
+
+  unsigned char pad_us[sizeof (long long) - sizeof (signed char)];
+  unsigned short us;   /* offset  25 bytes.  */
+
+  unsigned char pad_ss[sizeof (long long) - sizeof (unsigned short)];
+  short ss;/* offset 33 bytes.  */
+
+  unsigned char pad_ui[sizeof (long long) - sizeof (short)];
+  unsigned int ui; /* offset 41 bytes.  */
+
+  unsigned char pad_si[sizeof (long long) - sizeof (unsigned int)];
+  unsigned int si; /* offset 49 bytes.  */
+
+  unsigned char pad_f[sizeof (long long) - sizeof (int)];
+  float f; /* offset 57 bytes.  */
+
+  unsigned char pad_d[sizeof (long long) - sizeof (float)];
+  double d;/* offset 65 bytes.  */
+  __float128 f128; /* offset 73 bytes.  */
+} __attribute__((packed));
+
+unsigned char
+load_uc (struct packed_struct *p)
+{
+  return p->uc;/* LBZ 3,9(3).  */
+}
+
+signed char
+load_sc (struct packed_struct *p)
+{
+  return p->sc;/* LBZ 3,17(3) + EXTSB 3,3.  */
+}
+
+unsigned short
+load_us (struct packed_struct *p)
+{
+  return p->us;/* LHZ 3,25(3).  */
+}
+
+short
+load_ss (struct packed_struct *p)
+{
+  return p->ss;/* LHA 3,33(3).  */
+}
+
+unsigned int
+load_ui (struct packed_struct *p)
+{
+  return p->ui;/* LWZ 3,41(3).  */
+}
+
+int
+load_si (struct packed_struct *p)
+{
+  return p->si;/* PLWA 3,49(3).  */
+}
+
+float
+load_float (struct packed_struct *p)
+{
+  return p->f; /* LFS 1,57(3).  */
+}
+
+double
+load_double (struct packed_struct *p)
+{
+  return p->d; /* LFD 1,65(3).  */
+}
+
+__float128
+load_float128 (struct packed_struct *p)
+{
+  return p->f128;  /* PLXV 34,73(3).  */
+}
+
+void
+store_uc (struct packed_struct *p, unsigned char uc)
+{
+  p->uc = uc;  /* STB 4,9(3).  */
+}
+
+void
+store_sc (struct packed_struct *p, signed char sc)
+{
+  p->sc = sc;  /* STB 4,17(3).  */
+}
+
+void
+store_us (struct packed_struct *p, unsigned short us)
+{
+  p->us = us;  /* STH 4,25(3).  */
+}
+
+void
+store_ss (struct packed_struct *p, signed short ss)
+{
+  p->ss = ss;  /* STH 4,33(3).  */
+}
+
+void
+store_ui (struct packed_struct *p, unsigned int ui)
+{
+  p->ui = ui;  /* STW 4,41(3).  */
+}
+
+void
+store_si (struct packed_struct *p, signed int si)
+{
+  p->si = si;  /* STW 4,49(3).  */
+}
+
+void
+store_float (struct packed_struct *p, float f)
+{
+  p->f = f;/* STFS 1,57(3).  */
+}
+
+void
+store_double (struct packed_struct *p, double d)
+{
+  p->d = d;/* STFD 1,65(3).  */
+}
+
+void
+store_float128 (struct packed_struct *p, __float128 f128)
+{
+  p->f128 = f128;  /* PSTXV 34,1(3).  */
+}
+
+/* { dg-final { scan-assembler-times {\mextsb\M} 1 } } */
+/* { dg-final { scan-assembler-times {\mlbz\M}   2 } } */
+/* { dg-final { scan-assembler-times {\mlfd\M}   1 } } */
+/* { dg-final { 

[PATCH 1/6] Backport Power10 paddi/pli tests

[Michael Meissner via Gcc-patches]

Backport Power10 paddi/pli tests

This backport patch adds test for the PADDI instruction (and the PLI variant)
to add or load up 34 bit constants.  It has been in the master branch since
June, and no changes were needed for GCC 10.  Can I check this into the GCC 10
branch?

gcc/testsuite/
2020-08-03  Michael Meissner  

Backport from the master branch:
2020-06-27  Michael Meissner  

* gcc.target/powerpc/prefix-add.c: New test.
* gcc.target/powerpc/prefix-si-constant.c: New test.
* gcc.target/powerpc/prefix-di-constant.c: New test.

---
 gcc/testsuite/gcc.target/powerpc/prefix-add.c | 14 ++
 gcc/testsuite/gcc.target/powerpc/prefix-di-constant.c | 13 +
 gcc/testsuite/gcc.target/powerpc/prefix-si-constant.c | 12 
 3 files changed, 39 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/prefix-add.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/prefix-di-constant.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/prefix-si-constant.c

diff --git a/gcc/testsuite/gcc.target/powerpc/prefix-add.c 
b/gcc/testsuite/gcc.target/powerpc/prefix-add.c
new file mode 100644
index 000..0027406
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/prefix-add.c
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_prefixed_addr } */
+/* { dg-options "-O2 -mdejagnu-cpu=power10" } */
+
+/* Test that PADDI is generated to add a large constant.  */
+unsigned long
+add (unsigned long a)
+{
+  return a + 0x12345U;
+}
+
+/* { dg-final { scan-assembler {\mpaddi\M} } } */
+/* { dg-final { scan-assembler-not {\maddi\M}  } } */
+/* { dg-final { scan-assembler-not {\maddis\M} } } */
diff --git a/gcc/testsuite/gcc.target/powerpc/prefix-di-constant.c 
b/gcc/testsuite/gcc.target/powerpc/prefix-di-constant.c
new file mode 100644
index 000..aca7897
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/prefix-di-constant.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_prefixed_addr } */
+/* { dg-require-effective-target lp64 } */
+/* { dg-options "-O2 -mdejagnu-cpu=power10" } */
+
+/* Test that PLI (PADDI) is generated to load a large constant.  */
+unsigned long long
+large (void)
+{
+  return 0x12345678ULL;
+}
+
+/* { dg-final { scan-assembler {\mpli\M} } } */
diff --git a/gcc/testsuite/gcc.target/powerpc/prefix-si-constant.c 
b/gcc/testsuite/gcc.target/powerpc/prefix-si-constant.c
new file mode 100644
index 000..6403aa8
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/prefix-si-constant.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_prefixed_addr } */
+/* { dg-options "-O2 -mdejagnu-cpu=power10" } */
+
+/* Test that PLI (PADDI) is generated to load a large constant for SImode.  */
+void
+large_si (unsigned int *p)
+{
+  *p = 0x12345U;
+}
+
+/* { dg-final { scan-assembler {\mpli\M} } } */
-- 
1.8.3.1


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

[PATCH 0/6] Backport power10 prefixed instruction tests to GCC 10

[Michael Meissner via Gcc-patches]

The following 6 patches backport the tests on the master branch that were added
to test the new prefixed instructions being added to the Power10 processor.
These patches include changes made by David Edelsohn to make the patches work
on AIX.  I have tested them on a GCC 10 compiler on a little endian Linux
power8 system, and all of the tests now pass.  Can I check these patches into
the GCC 10 branch?

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

Re: [PATCH v5] dse: Remove partial load after full store for high part access[PR71309]

[luoxhu via Gcc-patches]

On 2020/8/3 22:01, Richard Sandiford wrote:


/* Try a wider mode if truncating the store mode to NEW_MODE
 requires a real instruction.  */
if (maybe_lt (GET_MODE_SIZE (new_mode), GET_MODE_SIZE (store_mode))
@@ -1779,6 +1780,25 @@ find_shift_sequence (poly_int64 access_size,
  && !targetm.modes_tieable_p (new_mode, store_mode))
continue;
  
+  if (multiple_p (GET_MODE_BITSIZE (new_mode), shift)


Like I mentioned before, this should be the other way around:

 multiple_p (shift, GET_MODE_BITSIZE (new_mode))

i.e. for the subreg to be valid, the shift amount must be a multiple
of the outer mode size in bits.

OK with that change, thanks, and sorry for the multiple review cycles.


Appreciate your time and patience to make it better :).
Updated the change and lp64 requirements from Segher and committed by
r11-2526-g265d817b1eb4644c7a9613ad6920315d98e2e0a4, thank you all.

Xionghu



Richard

Re : [PATCH PR96366][AARCH64] Add support for unpacked vector sub

[bule]

Thanks for the review and Commit.

Regards,
Bruce

-邮件原件-
发件人: Richard Sandiford [mailto:richard.sandif...@arm.com] 
发送时间: 2020年8月3日 23:40
收件人: bule 
抄送: gcc-patches@gcc.gnu.org
主题: Re: [PATCH PR96366][AARCH64] Add support for unpacked vector sub

bule  writes:
> Hi, 
>
> The test case bb-slp-20.c in the gcc testsuit will cause an ICE in the expand 
> pass due to the lack of a pattern for subtraction of the VNx2SI mode. I think 
> the problem has been fully discussed on PR 96366.
>
> The attached file is the patch to solve this problem. Bootstrapped and tested 
> on aarch64-linux-gnu. Ok for trunk?

Thanks, pushed to trunk.

Richard

[committed] c++: Remove unused declaration.

[Marek Polacek via Gcc-patches]

gcc/cp/ChangeLog:

* cp-tree.h (after_nsdmi_defaulted_late_checks): Remove.
---
 gcc/cp/cp-tree.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 1e583efd61d..fc54e6bb9bd 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -6809,7 +6809,6 @@ extern tree forward_parm  (tree);
 extern bool is_trivially_xible (enum tree_code, tree, tree);
 extern bool is_xible   (enum tree_code, tree, tree);
 extern tree get_defaulted_eh_spec  (tree, tsubst_flags_t = 
tf_warning_or_error);
-extern void after_nsdmi_defaulted_late_checks   (tree);
 extern bool maybe_explain_implicit_delete  (tree);
 extern void explain_implicit_non_constexpr (tree);
 extern void deduce_inheriting_ctor (tree);

base-commit: 2b6a53238f312e8bd05844795b8638a5d12402db
-- 
2.26.2

Re: [PATCH v5] dse: Remove partial load after full store for high part access[PR71309]

[Segher Boessenkool]

Hi Xiong Hu,

Very sorry I notice this only just now...

On Mon, Aug 03, 2020 at 02:58:45PM +0800, luoxhu wrote:
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/pr71309.c
> @@ -0,0 +1,33 @@
> +/* { dg-do compile } */
> +/* { dg-require-effective-target powerpc_p9vector_ok } */

This needs

/* { dg-require-effective-target lp64 } */

as well:

> +/* { dg-final { scan-assembler-times {\mld\M} 2 } } */
> +/* { dg-final { scan-assembler-times {\mstd\M} 2 } } */

... or those insns will not be generated.


Well done getting this fixed!  Thanks,


Segher

libgcc patch committed: Increase x86_64 split-stack backoff size

[Ian Lance Taylor via Gcc-patches]

With the ever increasing number of vector registers, and the use of
the xsavec instruction in the dynamic linker trampolines in newer
glibc, we need to ensure a lot more space on the stack when using
-fsplit-stack.  This patch adds 2048 additional bytes to the required
stack space with -fsplit-stack.  Discovered by running the Go
testsuite on x86_64-pc-linux-gnu with glibc 2.30.  This patch fixes
that problem.  Ran all Go tests on x86_64-pc-linux-gnu.  Committed to
mainline.

Ian
commit b3dc3bc7a785c33106aac50cbe39601e6d6b7e95
Author: Ian Lance Taylor 
Date:   Mon Aug 3 15:59:45 2020 -0700

libgcc: increase required stack space for x86_64 -fsplit-stack

This accomodates increased space required by use of the xsavec
instruction in the dynamic linker trampoline.

libgcc/ChangeLog:

* config/i386/morestack.S (BACKOFF) [x86_64]: Add 2048 bytes.

diff --git a/libgcc/config/i386/morestack.S b/libgcc/config/i386/morestack.S
index 519bbbc8c13..1c31783c754 100644
--- a/libgcc/config/i386/morestack.S
+++ b/libgcc/config/i386/morestack.S
@@ -79,7 +79,7 @@
 #ifndef __x86_64__
 #define BACKOFF (1024)
 #else
-#define BACKOFF (1536)
+#define BACKOFF (3584)
 #endif
 
 

Re: [PATCH 2/2] rs6000: Define define_insn_and_split to split unspec sldi+or to rldimi

[Segher Boessenkool]

On Mon, Aug 03, 2020 at 01:21:21PM +0200, Andreas Schwab wrote:
> On Jul 09 2020, Xiong Hu Luo via Gcc-patches wrote:
> 
> > diff --git a/gcc/testsuite/gcc.target/powerpc/vector_float.c 
> > b/gcc/testsuite/gcc.target/powerpc/vector_float.c
> > new file mode 100644
> > index 000..414824ad264
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/powerpc/vector_float.c
> > @@ -0,0 +1,14 @@
> > +/* { dg-do compile  } */
> > +/* { dg-options "-O2 -mdejagnu-cpu=power9" } */
> > +
> > +vector float
> > +test (float *a, float *b, float *c, float *d)
> > +{
> > +  return (vector float){*a, *b, *c, *d};
> > +}
> > +
> > +/* { dg-final { scan-assembler-not {\mlxsspx\M} } } */
> > +/* { dg-final { scan-assembler-not {\mlfs\M} } } */
> > +/* { dg-final { scan-assembler-times {\mlwz\M} 4 } } */
> > +/* { dg-final { scan-assembler-times {\mrldimi\M} 2 } } */
> > +/* { dg-final { scan-assembler-times {\mmtvsrdd\M} 1 } } */
> 
> This fails with -m32.

Fixed ( https://gcc.gnu.org/g:c004b383aa41 ).  Thanks!


Segher

Re: [PATCH] Treat { 0 } specially for structs with the designated_init attribute.

[Asher Gordon via Gcc-patches]

Joseph Myers  writes:

> These patches are on my list for review as and when I get time, if no-one 
> else gets to them first.  I don't believe there is anything else you need 
> to do at present.

Ah, that's fine. I just wanted to make sure you haven't forgotten about
it. :-)

Thanks,
Asher

-- 
Reader, suppose you were an idiot.  And suppose you were a member of
Congress.  But I repeat myself.
-- Mark Twain
   
I prefer to send and receive mail encrypted. Please send me your
public key, and if you do not have my public key, please let me
know. Thanks.

GPG fingerprint: 38F3 975C D173 4037 B397  8095 D4C9 C4FC 5460 8E68


signature.asc
Description: PGP signature

Re: [PATCH] c++: cxx_eval_vec_init after zero initialization [PR96282]

[Patrick Palka via Gcc-patches]

On Mon, 3 Aug 2020, Jason Merrill wrote:

> On 8/3/20 2:45 PM, Patrick Palka wrote:
> > On Mon, 3 Aug 2020, Jason Merrill wrote:
> > 
> > > On 8/3/20 8:53 AM, Patrick Palka wrote:
> > > > On Mon, 3 Aug 2020, Patrick Palka wrote:
> > > > 
> > > > > In the first testcase below, expand_aggr_init_1 sets up t's default
> > > > > constructor such that the ctor first zero-initializes the entire base
> > > > > b,
> > > > > followed by calling b's default constructor, the latter of which just
> > > > > default-initializes the array member b::m via a VEC_INIT_EXPR.
> > > > > 
> > > > > So upon constexpr evaluation of this latter VEC_INIT_EXPR, ctx->ctor
> > > > > is
> > > > > nonempty due to the prior zero-initialization, and we proceed in
> > > > > cxx_eval_vec_init to append new constructor_elts to the end of
> > > > > ctx->ctor
> > > > > without first checking if a matching constructor_elt already exists.
> > > > > This leads to ctx->ctor having two matching constructor_elts for each
> > > > > index.
> > > > > 
> > > > > This patch partially fixes this issue by making the RANGE_EXPR
> > > > > optimization in cxx_eval_vec_init truncate ctx->ctor before adding the
> > > > > single RANGE_EXPR constructor_elt.  This isn't a complete fix because
> > > > > the RANGE_EXPR optimization applies only when the constant initializer
> > > > > is relocatable, so whenever it's not relocatable we can still build up
> > > > > an invalid CONSTRUCTOR, e.g. if in the first testcase we add an NSDMI
> > > > > such as 'e *p = this;' to struct e, then the ICE still occurs even
> > > > > with
> > > > > this patch.
> > > > 
> > > > A complete but more risky one-line fix would be to always truncate
> > > > ctx->ctor beforehand, not just when the RANGE_EXPR optimization applies.
> > > > If it's true that the initializer of a VEC_INIT_EXPR can't observe the
> > > > previous elements of the target array, then it should be safe to always
> > > > truncate I think?
> > > 
> > > What if default-initialization of the array element type doesn't fully
> > > initialize the elements, e.g. if 'e' had another member without a default
> > > initializer?  Does truncation first mean we lose the zero-initialization
> > > of
> > > such a member?
> > 
> > Hmm, it looks like we would lose the zero-initialization of such a
> > member with or without truncation first (so with any one of the three
> > proposed fixes).  I think it's because the evaluation loop in
> > cxx_eval_vec_init disregards each element's prior (zero-initialized)
> > state.
> > 
> > > 
> > > We could probably still do the truncation, but clear the
> > > CONSTRUCTOR_NO_CLEARING flag on the element initializer.
> > 
> > Ah, this seems to work well.  Like this?
> > 
> > -- >8 --
> > 
> > Subject: [PATCH] c++: cxx_eval_vec_init after zero initialization [PR96282]
> > 
> > In the first testcase below, expand_aggr_init_1 sets up t's default
> > constructor such that the ctor first zero-initializes the entire base b,
> > followed by calling b's default constructor, the latter of which just
> > default-initializes the array member b::m via a VEC_INIT_EXPR.
> > 
> > So upon constexpr evaluation of this latter VEC_INIT_EXPR, ctx->ctor is
> > nonempty due to the prior zero-initialization, and we proceed in
> > cxx_eval_vec_init to append new constructor_elts to the end of ctx->ctor
> > without first checking if a matching constructor_elt already exists.
> > This leads to ctx->ctor having two matching constructor_elts for each
> > index.
> > 
> > This patch fixes this issue by truncating a zero-initialized array
> > object in cxx_eval_vec_init_1 before we begin appending default-initialized
> > array elements to it.  Since default-initialization may leave parts of
> > the element type unitialized, we also preserve the array's prior
> > zero-initialized state by clearing CONSTRUCTOR_NO_CLEARING on each
> > appended element initializers.
> > 
> > gcc/cp/ChangeLog:
> > 
> > PR c++/96282
> > * constexpr.c (cxx_eval_vec_init_1): Truncate ctx->ctor and
> > then clear CONSTRUCTOR_NO_CLEARING on each appended element
> > initializer if we're default-initializing a previously
> > zero-initialized array object.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > PR c++/96282
> > * g++.dg/cpp0x/constexpr-array26.C: New test.
> > * g++.dg/cpp0x/constexpr-array27.C: New test.
> > * g++.dg/cpp2a/constexpr-init18.C: New test.
> > ---
> >   gcc/cp/constexpr.c | 17 -
> >   gcc/testsuite/g++.dg/cpp0x/constexpr-array26.C | 13 +
> >   gcc/testsuite/g++.dg/cpp0x/constexpr-array27.C | 13 +
> >   gcc/testsuite/g++.dg/cpp2a/constexpr-init18.C  | 16 
> >   4 files changed, 58 insertions(+), 1 deletion(-)
> >   create mode 100644 gcc/testsuite/g++.dg/cpp0x/constexpr-array26.C
> >   create mode 100644 gcc/testsuite/g++.dg/cpp0x/constexpr-array27.C
> >   create mode 100644 gcc/testsuite/g++.dg/cpp2a/constexpr-init18.C
> > 

[committed] aarch64: Fix up __aarch64_cas16_acq_rel fallback [PR96402]

[Jakub Jelinek via Gcc-patches]

Hi!

As mentioned in the PR, the fallback path when LSE is unavailable writes
incorrect registers to the memory if the previous content compares equal
to x0, x1 - it writes copy of x0, x1 from the start of function, but it
should write x2, x3.

Fixed thusly, bootstrapped/regtested on aarch64-linux (without LSE),
preapproved in the PR by Kyrylo, committed to trunk and 10.3.

2020-08-03  Jakub Jelinek  

PR target/96402
* config/aarch64/lse.S (__aarch64_cas16_acq_rel): Use x2, x3 instead
of x(tmp0), x(tmp1) in STXP arguments.

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

--- gcc/testsuite/gcc.target/aarch64/pr96402.c.jj   2020-08-03 
11:11:50.136698905 +0200
+++ gcc/testsuite/gcc.target/aarch64/pr96402.c  2020-08-03 11:13:38.087168812 
+0200
@@ -0,0 +1,16 @@
+/* PR target/96402 */
+/* { dg-do run { target int128 } } */
+/* { dg-options "-moutline-atomics" } */
+
+int
+main ()
+{
+  __int128 a = 0;
+  __sync_val_compare_and_swap (, (__int128) 0, (__int128) 1);
+  if (a != 1)
+__builtin_abort ();
+  __sync_val_compare_and_swap (, (__int128) 1, (((__int128) 
0xdeadbeeffeedbac1ULL) << 64) | 0xabadcafe00c0ffeeULL);
+  if (a != __int128) 0xdeadbeeffeedbac1ULL) << 64) | 
0xabadcafe00c0ffeeULL))
+__builtin_abort ();
+  return 0;
+}
--- libgcc/config/aarch64/lse.S.jj  2020-07-28 15:39:10.134754495 +0200
+++ libgcc/config/aarch64/lse.S 2020-08-03 11:04:17.544113977 +0200
@@ -203,7 +203,7 @@ STARTFN NAME(cas)
cmp x0, x(tmp0)
ccmpx1, x(tmp1), #0, eq
bne 1f
-   STXPw(tmp2), x(tmp0), x(tmp1), [x4]
+   STXPw(tmp2), x2, x3, [x4]
cbnzw(tmp2), 0b
 1: ret
 


Jakub

Re: Ellipsis in varadic macro definitions

[Jonathan Wakely via Gcc-patches]

On Mon, 3 Aug 2020 at 14:53, Richard Sandiford
 wrote:
>
> Jonathan Wakely via Gcc  writes:
> > On Mon, 3 Aug 2020 at 11:28, Florian Weimer wrote:
> >>
> >> * Jonathan Wakely via Gcc:
> >>
> >> > On Sun, 2 Aug 2020 at 15:49, Philip R Brenan via Gcc  
> >> > wrote:
> >> >>
> >> >> Hi *GCC*:
> >> >>
> >> >> On page:
> >> >>
> >> >> https://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html#Variadic-Macros
> >> >>
> >> >> you say:
> >> >>
> >> >> #define eprintf(args…) fprintf (stderr, args)
> >> >>
> >> >> but do you in fact mean:
> >> >>
> >> >> #define eprintf(args...) fprintf (stderr, args)
> >> >>
> >> >> The first variant produces:
> >> >>
> >> >> error: expected ',' or ')', found "…"
> >> >>
> >> >>  the second variant works well using GCC10.2 on Kubuntu 18.04.
> >> >
> >> > Yes, the texinfo source uses @dots which gets turned into  in
> >> > the HTML, which isn't necessarily displayed as three separate dots in
> >> > the browser. I don't know why @dots is used rather than ...
> >>
> >> It was introduced with:
> >>
> >> commit 1c5dd43ff7c78bbdba5e89a6cb16a3e50e1abff9
> >> Author: Zack Weinberg 
> >> Date:   Fri Jun 15 17:57:48 2001 +
> >>
> >> cpp.texi: Formatting corrections.
> >>
> >> * doc/cpp.texi: Formatting corrections.
> >> Correct buggy example of use of __GNUC__ etc.
> >> Clarify $ in identifiers.
> >> * doc/cpp.1: Regenerate.
> >>
> >> From-SVN: r43404
> >>
> >> Some of these changes were clearly correct, but the ... C token should
> >> have not been changed.  Looks like a simple oversight to me.
> >
> > Thanks for the archaeology, Florian.
> >
> > Here's a patch to replace those inappropriate @dots macros with the
> > literal ... token.
> >
> > Tested by building the docs and inspecting the .info and .html output.
> >
> > OK for trunk?
>
> OK, thanks.  (And for branches too.)

Pushed to all branches, thanks.

Re: [PATCH] Add C++2a synchronization support

[Jonathan Wakely via Gcc-patches]

On 03/08/20 15:09 +0100, Jonathan Wakely wrote:

On 05/06/20 17:29 -0700, Thomas Rodgers wrote:

diff --git a/libstdc++-v3/include/bits/semaphore_base.h 
b/libstdc++-v3/include/bits/semaphore_base.h
new file mode 100644
index 000..f0c4235d91c
--- /dev/null
+++ b/libstdc++-v3/include/bits/semaphore_base.h
@@ -0,0 +1,272 @@
+// -*- C++ -*- header.
+
+// Copyright (C) 2020 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// Under Section 7 of GPL version 3, you are granted additional
+// permissions described in the GCC Runtime Library Exception, version
+// 3.1, as published by the Free Software Foundation.
+
+// You should have received a copy of the GNU General Public License and
+// a copy of the GCC Runtime Library Exception along with this program;
+// see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+// .
+
+/** @file bits/semaphore_base.h
+ *  This is an internal header file, included by other library headers.
+ *  Do not attempt to use it directly. @headername{semaphore}
+ */
+
+#ifndef _GLIBCXX_SEMAPHORE_BASE_H
+#define _GLIBCXX_SEMAPHORE_BASE_H 1
+
+#pragma GCC system_header
+
+#include 
+#include 
+#include 
+
+#if defined _POSIX_SEMAPHORES  && __has_include()
+#define _GLIBCXX_HAVE_POSIX_SEMAPHORE 1
+#include 
+#endif
+
+#include 
+#include 
+
+namespace std _GLIBCXX_VISIBILITY(default)
+{
+_GLIBCXX_BEGIN_NAMESPACE_VERSION
+
+#ifdef _GLIBCXX_HAVE_POSIX_SEMAPHORE
+  template
+struct __platform_semaphore


Why is this a template?

It means we'll instantiate identical code for counting_semaphore<3>
and counting_semaphore<4>, but they're distinct types that will bloat
the binary.

Can't we just have a single __platform_semaphore type for all max
values, and just make sure we don't instantiate it for values larger
than SEM_VALUE_MAX?


+{


I think we want to delete the copy constructor and copy assignment
operator for this type and __atomic_semaphore.


+  using __clock_t = chrono::system_clock;
+
+  explicit __platform_semaphore(ptrdiff_t __count) noexcept
+  {
+   static_assert( __least_max_value <= SEM_VALUE_MAX, "");


I think it would be useful for __platform_semaphore to define a static
constexpr member like:

static constexpr ptrdiff_t _S_max = SEM_VALUE_MAX;

And then __atomic_semaphore could define:

static constexpr _Tp _S_max = __gnu_cxx::__int_traits<_Tp>::__max;

And then the alias __semaphore_base could be defined as:

#if _GLIBCXX_HAVE_LINUX_FUTEX && ! _GLIBCXX_REQUIRE_POSIX_SEMAPHORE
  // Use futex if available and user didn't force use of POSIX:
  using __fast_semaphore_base = __atomic_semaphore<__platform_wait_t>;
#elif _GLIBCXX_HAVE_POSIX_SEMAPHORE
  // Otherwise, use POSIX if available:
  using __fast_semaphore_base = __platform_semaphore;
#else
// Otherwise, use atomics:
  using __fast_semaphore_base = __atomic_semaphore;
#endif

  template
using __semaphore_base = conditional_t<
  __least_max_value <= __fast_semaphore_base::_S_max,
  __fast_semaphore_base, __atomic_semaphore;

Would that make sense?

Do the comments above reflect the intent?



+#ifdef _GLIBCXX_REQUIRE_POSIX_SEMAPHORE


What is this case for? This macro seems to only exist for use by a
single testcase.

Is it supposed to be something users can set? If so, it needs to be
documented as ABI-breaking and as implying that counting_semaphore
cannot be use with counts higher than SEM_VALUE_MAX.


+  template
+using __semaphore_base = __platform_semaphore<__least_max_value>;
+#else
+#  ifdef _GLIBCXX_HAVE_LINUX_FUTEX
+  template
+using __semaphore_base = conditional_t<(
+ __least_max_value >= 0


This condition is redundant, we already know that counting_semaphore
has checked the value is non-negative.


+   && __least_max_value <= 
__detail::__platform_wait_max_value),
+ __atomic_semaphore<__detail::__platform_wait_t>,
+ __atomic_semaphore>;
+
+// __platform_semaphore
+#  elif defined _GLIBCXX_HAVE_POSIX_SEMAPHORE
+  template
+using __semaphore_base = conditional_t<(
+ __least_max_value >= 0


Redundant condition again.


+   && __least_max_value <= SEM_VALUE_MAX),
+ __platform_semaphore<__least_max_value>,
+ __atomic_semaphore>;
+#  else
+  template
+using 

Re: [PATCH] Treat { 0 } specially for structs with the designated_init attribute.

[Joseph Myers]

On Mon, 3 Aug 2020, Asher Gordon via Gcc-patches wrote:

> Hello,
> 
> Asher Gordon  writes:
> 
> > My copyright assignment finally got finished, so you should be able to
> > apply my patches now.
> 
> Is there any reason my patches haven't been applied yet? Is there
> anything else I need to do?

These patches are on my list for review as and when I get time, if no-one 
else gets to them first.  I don't believe there is anything else you need 
to do at present.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] c++: Member initializer list diagnostic locations [PR94024]

[Jason Merrill via Gcc-patches]

On 8/3/20 2:49 PM, Patrick Palka wrote:

On Mon, 3 Aug 2020, Jason Merrill wrote:


On 8/3/20 10:14 AM, Patrick Palka wrote:

This patch preserves the source locations of each node in a member
initializer list so that during processing of the list we can set
input_location appropriately for generally more accurate diagnostic
locations.  Since TREE_LIST nodes are tcc_exceptional, they can't have
source locations, so we instead store the location in a dummy
tcc_expression node within the TREE_TYPE of the list node.



Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK to
commit?

gcc/cp/ChangeLog:

PR c++/94024
* init.c (sort_mem_initializers): Preserve TREE_TYPE of the
member initializer list node.
(emit_mem_initializers): Set input_location when performing each
member initialization.
* parser.c (cp_parser_mem_initializer_list): Attach the source
location of this initializer to a dummy EMPTY_CLASS_EXPR within
the TREE_TYPE of the list node.
* pt.c (tsubst_initializer_list): Preserve TREE_TYPE of the
member initializer list node.

gcc/testsuite/ChangeLog:

PR c++/94024
* g++.dg/diagnostic/mem-init1.C: New test.
---
   gcc/cp/init.c   |  6 +
   gcc/cp/parser.c |  8 ++
   gcc/cp/pt.c |  3 +++
   gcc/testsuite/g++.dg/diagnostic/mem-init1.C | 29 +
   4 files changed, 46 insertions(+)
   create mode 100644 gcc/testsuite/g++.dg/diagnostic/mem-init1.C

diff --git a/gcc/cp/init.c b/gcc/cp/init.c
index cb9bd2dbfba..3f089404cf2 100644
--- a/gcc/cp/init.c
+++ b/gcc/cp/init.c
@@ -1151,6 +1151,8 @@ sort_mem_initializers (tree t, tree mem_inits)
   /* Record the initialization.  */
 TREE_VALUE (subobject_init) = TREE_VALUE (init);
+  /* Carry over the dummy TREE_TYPE node containing the source
location.  */
+  TREE_TYPE (subobject_init) = TREE_TYPE (init);
 next_subobject = subobject_init;
   }
   @@ -1367,6 +1369,10 @@ emit_mem_initializers (tree mem_inits)
 /* Initialize the data members.  */
 while (mem_inits)
   {
+  /* If this initializer was explicitly provided, then the dummy
TREE_TYPE
+node contains the source location.  */
+  iloc_sentinel ils (EXPR_LOCATION (TREE_TYPE (mem_inits)));
+
 perform_member_init (TREE_PURPOSE (mem_inits),
   TREE_VALUE (mem_inits));
 mem_inits = TREE_CHAIN (mem_inits);
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index ab088874ba7..2f9b8786121 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -15326,6 +15326,14 @@ cp_parser_mem_initializer_list (cp_parser* parser)
{
  TREE_CHAIN (mem_initializer) = mem_initializer_list;
  mem_initializer_list = mem_initializer;
+
+ /* We can't attach the source location of this initializer directly
to
+the list node, so we instead attach it to a dummy
EMPTY_CLASS_EXPR
+within the TREE_TYPE of the list node.  */
+ TREE_TYPE (mem_initializer) = build0 (EMPTY_CLASS_EXPR, NULL_TREE);
+ SET_EXPR_LOCATION (TREE_TYPE (mem_initializer),
+make_location (token->location,
+   token->location, input_location));


Why not do this in cp_parser_mem_initializer?

Also, use parser->lexer for the last argument to make_location.


That's a much better spot for it :) Done and done.  Does the following
look OK after testing completes?


OK.


-- >8 --

Subject: [PATCH] c++: Member initializer list diagnostic locations [PR94024]

This patch preserves the source locations of each node in a member
initializer list so that during processing of the list we can set
input_location appropriately for generally more accurate diagnostic
locations.  Since TREE_LIST nodes are tcc_exceptional, they can't have
source locations, so we instead store the location in a dummy
tcc_expression node within the TREE_TYPE of the list node.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK to
commit?

gcc/cp/ChangeLog:

PR c++/94024
* init.c (sort_mem_initializers): Preserve TREE_TYPE of the
member initializer list node.
(emit_mem_initializers): Set input_location when performing each
member initialization.
* parser.c (cp_parser_mem_initializer): Attach the source
location of this initializer to a dummy EMPTY_CLASS_EXPR
within the TREE_TYPE of the list node.
* pt.c (tsubst_initializer_list): Preserve TREE_TYPE of the
member initializer list node.

gcc/testsuite/ChangeLog:

PR c++/94024
* g++.dg/diagnostic/mem-init1.C: New test.
---
  gcc/cp/init.c   |  6 +
  gcc/cp/parser.c | 13 -
  gcc/cp/pt.c |  3 +++
  

docs: refer to c++20

[Nathan Sidwell]

I noticed a bunch of references to c++2a.  fixed thusly

gcc/
* doc/invoke.texi: Refer to c++20

nathan
--
Nathan Sidwell
diff --git i/gcc/doc/invoke.texi w/gcc/doc/invoke.texi
index eb73f306051..4aa492452ae 100644
--- i/gcc/doc/invoke.texi
+++ w/gcc/doc/invoke.texi
@@ -2833,7 +2833,7 @@ This flag is enabled by default for @option{-std=c++17}.
 @itemx -fno-char8_t
 @opindex fchar8_t
 @opindex fno-char8_t
-Enable support for @code{char8_t} as adopted for C++2a.  This includes
+Enable support for @code{char8_t} as adopted for C++20.  This includes
 the addition of a new @code{char8_t} fundamental type, changes to the
 types of UTF-8 string and character literals, new signatures for
 user-defined literals, associated standard library updates, and new
@@ -2899,10 +2899,10 @@ exhaustion is signalled by throwing @code{std::bad_alloc}.  See also
 @itemx -fconcepts-ts
 @opindex fconcepts
 @opindex fconcepts-ts
-Below @option{-std=c++2a}, @option{-fconcepts} enables support for the
+Below @option{-std=c++20}, @option{-fconcepts} enables support for the
 C++ Extensions for Concepts Technical Specification, ISO 19217 (2015).
 
-With @option{-std=c++2a} and above, Concepts are part of the language
+With @option{-std=c++20} and above, Concepts are part of the language
 standard, so @option{-fconcepts} defaults to on.  But the standard
 specification of Concepts differs significantly from the TS, so some
 constructs that were allowed in the TS but didn't make it into the
@@ -3286,7 +3286,7 @@ about ABI tags.
 @opindex Wcomma-subscript
 @opindex Wno-comma-subscript
 Warn about uses of a comma expression within a subscripting expression.
-This usage was deprecated in C++2a.  However, a comma expression wrapped
+This usage was deprecated in C++20.  However, a comma expression wrapped
 in @code{( )} is not deprecated.  Example:
 
 @smallexample
@@ -3298,7 +3298,7 @@ void f(int *a, int b, int c) @{
 @end group
 @end smallexample
 
-Enabled by default with @option{-std=c++2a}.
+Enabled by default with @option{-std=c++20}.
 
 @item -Wctor-dtor-privacy @r{(C++ and Objective-C++ only)}
 @opindex Wctor-dtor-privacy
@@ -3819,7 +3819,7 @@ non-class type, @code{volatile}-qualified function return type,
 @code{volatile}-qualified parameter type, and structured bindings of a
 @code{volatile}-qualified type.  This usage was deprecated in C++20.
 
-Enabled by default with @option{-std=c++2a}.
+Enabled by default with @option{-std=c++20}.
 
 @item -Wzero-as-null-pointer-constant @r{(C++ and Objective-C++ only)}
 @opindex Wzero-as-null-pointer-constant
@@ -6273,7 +6273,7 @@ This is the warning level of @option{-Wshift-overflow} and is enabled
 by default in C99 and C++11 modes (and newer).  This warning level does
 not warn about left-shifting 1 into the sign bit.  (However, in C, such
 an overflow is still rejected in contexts where an integer constant expression
-is required.)  No warning is emitted in C++2A mode (and newer), as signed left
+is required.)  No warning is emitted in C++20 mode (and newer), as signed left
 shifts always wrap.
 
 @item -Wshift-overflow=2

Re: [PATCH] CSKY: Add -mfloat-abi= option.

[Joseph Myers]

My glibc bot is showing the build of libgcc for csky-linux-gnuabiv2 
(configured --with-float=hard --disable-multilib) has recently broken, 
likely from this change.

https://sourceware.org/pipermail/libc-testresults/2020q3/006566.html

The errors are of the form:

/tmp/cc7H0Zu7.s: Assembler messages:
/tmp/cc7H0Zu7.s:24: Error: The instruction is not recognized.
/tmp/cc7H0Zu7.s:28: Error: The instruction is not recognized.
/tmp/cc7H0Zu7.s:42: Error: The instruction is not recognized.
/tmp/cc7H0Zu7.s:52: Error: The instruction is not recognized.
/tmp/cc7H0Zu7.s:63: Error: The instruction is not recognized.
/tmp/cc7H0Zu7.s:67: Error: The instruction is not recognized.
/tmp/cc7H0Zu7.s:73: Error: The instruction is not recognized.
Makefile:501: recipe for target '_powisf2.o' failed

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] c++: Variable template and template parameter pack [PR96218]

[Jason Merrill via Gcc-patches]

On 8/3/20 2:58 PM, Marek Polacek wrote:

On Wed, Jul 29, 2020 at 05:56:56PM -0400, Jason Merrill via Gcc-patches wrote:

On 7/16/20 11:06 AM, Marek Polacek wrote:

This is DR 2032 which says that the restrictions regarding template
parameter packs and default arguments apply to variable templates as
well, but we weren't detecting that.

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

gcc/cp/ChangeLog:

DR 2032
PR c++/96218
* pt.c (check_default_tmpl_args): Also consider variable
templates.

gcc/testsuite/ChangeLog:

DR 2032
PR c++/96218
* g++.dg/cpp1y/var-templ67.C: New test.
---
   gcc/cp/pt.c  |  5 +++--
   gcc/testsuite/g++.dg/cpp1y/var-templ67.C | 16 
   2 files changed, 19 insertions(+), 2 deletions(-)
   create mode 100644 gcc/testsuite/g++.dg/cpp1y/var-templ67.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 4e1c77a6bd7..b74074a092b 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -5481,14 +5481,15 @@ check_default_tmpl_args (tree decl, tree parms, bool 
is_primary,
   /* Don't complain about an enclosing partial
  specialization.  */
   && parm_level == parms
-  && TREE_CODE (decl) == TYPE_DECL
+  && (TREE_CODE (decl) == TYPE_DECL || VAR_P (decl))


Can we remove this part of the test entirely, since the enclosing if already
excludes functions?


I'm afraid we can't -- we can still get here for function templates in C++98.
Then we error like this:

q.C:1:10: error: parameter pack ‘_Args’ must be at the end of the template 
parameter list
 1 | template


Ah, I was forgetting that we allow libstdc++ variadic templates in C++98 
mode even though they're part of C++11.


The patch is OK.

Jason

Re: [PATCH] c++: cxx_eval_vec_init after zero initialization [PR96282]

[Jason Merrill via Gcc-patches]

On 8/3/20 2:45 PM, Patrick Palka wrote:

On Mon, 3 Aug 2020, Jason Merrill wrote:


On 8/3/20 8:53 AM, Patrick Palka wrote:

On Mon, 3 Aug 2020, Patrick Palka wrote:


In the first testcase below, expand_aggr_init_1 sets up t's default
constructor such that the ctor first zero-initializes the entire base b,
followed by calling b's default constructor, the latter of which just
default-initializes the array member b::m via a VEC_INIT_EXPR.

So upon constexpr evaluation of this latter VEC_INIT_EXPR, ctx->ctor is
nonempty due to the prior zero-initialization, and we proceed in
cxx_eval_vec_init to append new constructor_elts to the end of ctx->ctor
without first checking if a matching constructor_elt already exists.
This leads to ctx->ctor having two matching constructor_elts for each
index.

This patch partially fixes this issue by making the RANGE_EXPR
optimization in cxx_eval_vec_init truncate ctx->ctor before adding the
single RANGE_EXPR constructor_elt.  This isn't a complete fix because
the RANGE_EXPR optimization applies only when the constant initializer
is relocatable, so whenever it's not relocatable we can still build up
an invalid CONSTRUCTOR, e.g. if in the first testcase we add an NSDMI
such as 'e *p = this;' to struct e, then the ICE still occurs even with
this patch.


A complete but more risky one-line fix would be to always truncate
ctx->ctor beforehand, not just when the RANGE_EXPR optimization applies.
If it's true that the initializer of a VEC_INIT_EXPR can't observe the
previous elements of the target array, then it should be safe to always
truncate I think?


What if default-initialization of the array element type doesn't fully
initialize the elements, e.g. if 'e' had another member without a default
initializer?  Does truncation first mean we lose the zero-initialization of
such a member?


Hmm, it looks like we would lose the zero-initialization of such a
member with or without truncation first (so with any one of the three
proposed fixes).  I think it's because the evaluation loop in
cxx_eval_vec_init disregards each element's prior (zero-initialized)
state.



We could probably still do the truncation, but clear the
CONSTRUCTOR_NO_CLEARING flag on the element initializer.


Ah, this seems to work well.  Like this?

-- >8 --

Subject: [PATCH] c++: cxx_eval_vec_init after zero initialization [PR96282]

In the first testcase below, expand_aggr_init_1 sets up t's default
constructor such that the ctor first zero-initializes the entire base b,
followed by calling b's default constructor, the latter of which just
default-initializes the array member b::m via a VEC_INIT_EXPR.

So upon constexpr evaluation of this latter VEC_INIT_EXPR, ctx->ctor is
nonempty due to the prior zero-initialization, and we proceed in
cxx_eval_vec_init to append new constructor_elts to the end of ctx->ctor
without first checking if a matching constructor_elt already exists.
This leads to ctx->ctor having two matching constructor_elts for each
index.

This patch fixes this issue by truncating a zero-initialized array
object in cxx_eval_vec_init_1 before we begin appending default-initialized
array elements to it.  Since default-initialization may leave parts of
the element type unitialized, we also preserve the array's prior
zero-initialized state by clearing CONSTRUCTOR_NO_CLEARING on each
appended element initializers.

gcc/cp/ChangeLog:

PR c++/96282
* constexpr.c (cxx_eval_vec_init_1): Truncate ctx->ctor and
then clear CONSTRUCTOR_NO_CLEARING on each appended element
initializer if we're default-initializing a previously
zero-initialized array object.

gcc/testsuite/ChangeLog:

PR c++/96282
* g++.dg/cpp0x/constexpr-array26.C: New test.
* g++.dg/cpp0x/constexpr-array27.C: New test.
* g++.dg/cpp2a/constexpr-init18.C: New test.
---
  gcc/cp/constexpr.c | 17 -
  gcc/testsuite/g++.dg/cpp0x/constexpr-array26.C | 13 +
  gcc/testsuite/g++.dg/cpp0x/constexpr-array27.C | 13 +
  gcc/testsuite/g++.dg/cpp2a/constexpr-init18.C  | 16 
  4 files changed, 58 insertions(+), 1 deletion(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/constexpr-array26.C
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/constexpr-array27.C
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/constexpr-init18.C

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index b1c1d249c6e..706bef323b2 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -4171,6 +4171,17 @@ cxx_eval_vec_init_1 (const constexpr_ctx *ctx, tree 
atype, tree init,
pre_init = true;
  }
  
+  bool zero_initialized_p = false;

+  if ((pre_init || value_init || !init) && initializer_zerop (ctx->ctor))


Does initializer_zerop capture the difference between a 
default-initialized or value-initialized containing object?  I would 
expect it to be true for both.  Maybe check CONSTRUCTOR_NO_CLEARING 
(ctx->ctor) 

[pushed] Darwin: Guard two macros in darwin.h.

[Iain Sandoe]

Hi

Work on the Arm64 port shows that these two macros can be declared
ahead of the version in darwin.h which needs to override (for X86
and PPC this wasn't needed).

tested across the Darwin range currently supported.
pushed to master.
thanks
Iain

gcc/ChangeLog:

* config/darwin.h (ASM_DECLARE_FUNCTION_NAME): UNDEF before
use.
(DEF_MIN_OSX_VERSION): Only define if there's no existing
def.
---
 gcc/config/darwin.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gcc/config/darwin.h b/gcc/config/darwin.h
index f528b1766bf..55a5361cadb 100644
--- a/gcc/config/darwin.h
+++ b/gcc/config/darwin.h
@@ -652,6 +652,7 @@ extern GTY(()) int darwin_ms_struct;
that the name *is* defined in this module, so it doesn't need to
make them indirect.  */
 
+#undef ASM_DECLARE_FUNCTION_NAME
 #define ASM_DECLARE_FUNCTION_NAME(FILE, NAME, DECL)\
   do { \
 const char *xname = NAME;  \
@@ -1059,7 +1060,9 @@ extern void darwin_driver_init (unsigned int *,struct 
cl_decoded_option **);
providing an osx-version-min of this unless overridden by the User.
10.5 is the only version that fully supports all our archs so that's the
fall-back default.  */
+#ifndef DEF_MIN_OSX_VERSION
 #define DEF_MIN_OSX_VERSION "10.5"
+#endif
 
 /* Later versions of ld64 support coalescing weak code/data without requiring
that they be placed in specially identified sections.  This is the earliest
-- 
2.24.1

Re: [PATCH] c++: Variable template and template parameter pack [PR96218]

[Marek Polacek via Gcc-patches]

On Wed, Jul 29, 2020 at 05:56:56PM -0400, Jason Merrill via Gcc-patches wrote:
> On 7/16/20 11:06 AM, Marek Polacek wrote:
> > This is DR 2032 which says that the restrictions regarding template
> > parameter packs and default arguments apply to variable templates as
> > well, but we weren't detecting that.
> > 
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > 
> > gcc/cp/ChangeLog:
> > 
> > DR 2032
> > PR c++/96218
> > * pt.c (check_default_tmpl_args): Also consider variable
> > templates.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > DR 2032
> > PR c++/96218
> > * g++.dg/cpp1y/var-templ67.C: New test.
> > ---
> >   gcc/cp/pt.c  |  5 +++--
> >   gcc/testsuite/g++.dg/cpp1y/var-templ67.C | 16 
> >   2 files changed, 19 insertions(+), 2 deletions(-)
> >   create mode 100644 gcc/testsuite/g++.dg/cpp1y/var-templ67.C
> > 
> > diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
> > index 4e1c77a6bd7..b74074a092b 100644
> > --- a/gcc/cp/pt.c
> > +++ b/gcc/cp/pt.c
> > @@ -5481,14 +5481,15 @@ check_default_tmpl_args (tree decl, tree parms, 
> > bool is_primary,
> >/* Don't complain about an enclosing partial
> >   specialization.  */
> >&& parm_level == parms
> > -  && TREE_CODE (decl) == TYPE_DECL
> > +  && (TREE_CODE (decl) == TYPE_DECL || VAR_P (decl))
> 
> Can we remove this part of the test entirely, since the enclosing if already
> excludes functions?

I'm afraid we can't -- we can still get here for function templates in C++98.
Then we error like this:

q.C:1:10: error: parameter pack ‘_Args’ must be at the end of the template 
parameter list
1 | template

We could move the cxx_dialect == cxx98 check probably, but not sure if that's
any better than my fix.

Marek

[pushed] Darwin: Handle poly_int machine modes.

[Iain Sandoe]

Hi

I’ve started looking at the changes to the Darwin port that will be
needed to support the AArch64 version of the OS.  One of those is
that it will be necessary to support poly-int machine modes where
the number of coeffs > 1.

@richard, as discussed on irc, this removes the ‘IN_TARGET_CODE’
change from darwin.c.  Actually, the specific routines using the machine
mode sizes really *are* shared between ports and therefore are not
really candidates for splitting into files stored per arch (although some
of the other macho-pic code probably will be.

This has been tested across the old 32b powerpc and i686 ports and on
the latest x86-64 and my prototype arm64 one, but if there’s a goof I’d
welcome any pointers

tested as described,
pushed to master,

thanks
Iain



The common code that selects suitable sections for literals needs
to inspect the machine_mode.  For some sub-targets that might be
represented as a poly-int.

There was a workaround in place that allowed for cases where the poly
int had only one component.  This removes the workaround and handles
the cases where we care about the machine_mode size.

gcc/ChangeLog:

* config/darwin.c (IN_TARGET_CODE): Remove.
(darwin_mergeable_constant_section): Handle poly-int machine modes.
(machopic_select_rtx_section): Likewise.
---
 gcc/config/darwin.c | 62 -
 1 file changed, 33 insertions(+), 29 deletions(-)

diff --git a/gcc/config/darwin.c b/gcc/config/darwin.c
index d3c0af8a4b6..2c6da2b47c4 100644
--- a/gcc/config/darwin.c
+++ b/gcc/config/darwin.c
@@ -18,8 +18,6 @@ You should have received a copy of the GNU General Public 
License
 along with GCC; see the file COPYING3.  If not see
 .  */
 
-#define IN_TARGET_CODE 1
-
 #include "config.h"
 #include "system.h"
 #include "coretypes.h"
@@ -1351,34 +1349,40 @@ darwin_mergeable_constant_section (tree exp,
   unsigned HOST_WIDE_INT align,
   bool zsize)
 {
-  machine_mode mode = DECL_MODE (exp);
-  unsigned int modesize = GET_MODE_BITSIZE (mode);
-
   if (zsize)
 return darwin_sections[zobj_const_section];
 
-  if (flag_merge_constants
-  && mode != VOIDmode
-  && mode != BLKmode
-  && modesize <= align
-  && align >= 8
-  && align <= 256
-  && (align & (align -1)) == 0)
-{
-  tree size = TYPE_SIZE_UNIT (TREE_TYPE (exp));
+  machine_mode mode = DECL_MODE (exp);
+  if (!flag_merge_constants
+  || mode == VOIDmode
+  || mode == BLKmode
+  || align < 8
+  || align > 256
+  || (align & (align -1)) != 0)
+return readonly_data_section;
 
-  if (TREE_CODE (size) == INTEGER_CST)
-   {
- if (wi::to_wide (size) == 4)
-   return darwin_sections[literal4_section];
- else if (wi::to_wide (size) == 8)
-   return darwin_sections[literal8_section];
- else if (HAVE_GAS_LITERAL16
-  && TARGET_64BIT
-  && wi::to_wide (size) == 16)
-   return darwin_sections[literal16_section];
-   }
-}
+  /* This will ICE if the mode is not a constant size, but that is reasonable,
+ since one cannot put a variable-sized thing into a constant section, we
+ shouldn't be trying.  */
+  const unsigned int modesize = GET_MODE_BITSIZE (mode).to_constant ();
+
+  if (modesize > align)
+return readonly_data_section;
+
+  tree size = TYPE_SIZE_UNIT (TREE_TYPE (exp));
+
+  if (TREE_CODE (size) != INTEGER_CST)
+return readonly_data_section;
+
+  unsigned isize = TREE_INT_CST_LOW (size);
+  if (isize == 4)
+return darwin_sections[literal4_section];
+  else if (isize == 8)
+return darwin_sections[literal8_section];
+  else if (HAVE_GAS_LITERAL16
+  && TARGET_64BIT
+  && isize == 16)
+return darwin_sections[literal16_section];
 
   return readonly_data_section;
 }
@@ -1747,19 +1751,19 @@ section *
 machopic_select_rtx_section (machine_mode mode, rtx x,
 unsigned HOST_WIDE_INT align ATTRIBUTE_UNUSED)
 {
-  if (GET_MODE_SIZE (mode) == 8
+  if (known_eq (GET_MODE_SIZE (mode), 8)
   && (GET_CODE (x) == CONST_INT
  || GET_CODE (x) == CONST_WIDE_INT
  || GET_CODE (x) == CONST_DOUBLE))
 return darwin_sections[literal8_section];
-  else if (GET_MODE_SIZE (mode) == 4
+  else if (known_eq (GET_MODE_SIZE (mode), 4)
   && (GET_CODE (x) == CONST_INT
   || GET_CODE (x) == CONST_WIDE_INT
   || GET_CODE (x) == CONST_DOUBLE))
 return darwin_sections[literal4_section];
   else if (HAVE_GAS_LITERAL16
   && TARGET_64BIT
-  && GET_MODE_SIZE (mode) == 16
+  && known_eq (GET_MODE_SIZE (mode), 16)
   && (GET_CODE (x) == CONST_INT
   || GET_CODE (x) == CONST_WIDE_INT
   || GET_CODE (x) == CONST_DOUBLE
-- 
2.24.1

Re: [PATCH] Treat { 0 } specially for structs with the designated_init attribute.

[Asher Gordon via Gcc-patches]

Hello,

Asher Gordon  writes:

> My copyright assignment finally got finished, so you should be able to
> apply my patches now.

Is there any reason my patches haven't been applied yet? Is there
anything else I need to do?

Thanks,
Asher

-- 
 eek, not another one...
 Seems ever developer and their mother now has a random
   signature using irc quotes ...
 WHAT HAVE I STARTED HERE??
   
I prefer to send and receive mail encrypted. Please send me your
public key, and if you do not have my public key, please let me
know. Thanks.

GPG fingerprint: 38F3 975C D173 4037 B397  8095 D4C9 C4FC 5460 8E68


signature.asc
Description: PGP signature

Re: [PATCH] c++: Member initializer list diagnostic locations [PR94024]

[Patrick Palka via Gcc-patches]

On Mon, 3 Aug 2020, Jason Merrill wrote:

> On 8/3/20 10:14 AM, Patrick Palka wrote:
> > This patch preserves the source locations of each node in a member
> > initializer list so that during processing of the list we can set
> > input_location appropriately for generally more accurate diagnostic
> > locations.  Since TREE_LIST nodes are tcc_exceptional, they can't have
> > source locations, so we instead store the location in a dummy
> > tcc_expression node within the TREE_TYPE of the list node.
> 
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK to
> > commit?
> > 
> > gcc/cp/ChangeLog:
> > 
> > PR c++/94024
> > * init.c (sort_mem_initializers): Preserve TREE_TYPE of the
> > member initializer list node.
> > (emit_mem_initializers): Set input_location when performing each
> > member initialization.
> > * parser.c (cp_parser_mem_initializer_list): Attach the source
> > location of this initializer to a dummy EMPTY_CLASS_EXPR within
> > the TREE_TYPE of the list node.
> > * pt.c (tsubst_initializer_list): Preserve TREE_TYPE of the
> > member initializer list node.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > PR c++/94024
> > * g++.dg/diagnostic/mem-init1.C: New test.
> > ---
> >   gcc/cp/init.c   |  6 +
> >   gcc/cp/parser.c |  8 ++
> >   gcc/cp/pt.c |  3 +++
> >   gcc/testsuite/g++.dg/diagnostic/mem-init1.C | 29 +
> >   4 files changed, 46 insertions(+)
> >   create mode 100644 gcc/testsuite/g++.dg/diagnostic/mem-init1.C
> > 
> > diff --git a/gcc/cp/init.c b/gcc/cp/init.c
> > index cb9bd2dbfba..3f089404cf2 100644
> > --- a/gcc/cp/init.c
> > +++ b/gcc/cp/init.c
> > @@ -1151,6 +1151,8 @@ sort_mem_initializers (tree t, tree mem_inits)
> >   /* Record the initialization.  */
> > TREE_VALUE (subobject_init) = TREE_VALUE (init);
> > +  /* Carry over the dummy TREE_TYPE node containing the source
> > location.  */
> > +  TREE_TYPE (subobject_init) = TREE_TYPE (init);
> > next_subobject = subobject_init;
> >   }
> >   @@ -1367,6 +1369,10 @@ emit_mem_initializers (tree mem_inits)
> > /* Initialize the data members.  */
> > while (mem_inits)
> >   {
> > +  /* If this initializer was explicitly provided, then the dummy
> > TREE_TYPE
> > +node contains the source location.  */
> > +  iloc_sentinel ils (EXPR_LOCATION (TREE_TYPE (mem_inits)));
> > +
> > perform_member_init (TREE_PURPOSE (mem_inits),
> >TREE_VALUE (mem_inits));
> > mem_inits = TREE_CHAIN (mem_inits);
> > diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
> > index ab088874ba7..2f9b8786121 100644
> > --- a/gcc/cp/parser.c
> > +++ b/gcc/cp/parser.c
> > @@ -15326,6 +15326,14 @@ cp_parser_mem_initializer_list (cp_parser* parser)
> > {
> >   TREE_CHAIN (mem_initializer) = mem_initializer_list;
> >   mem_initializer_list = mem_initializer;
> > +
> > + /* We can't attach the source location of this initializer directly
> > to
> > +the list node, so we instead attach it to a dummy
> > EMPTY_CLASS_EXPR
> > +within the TREE_TYPE of the list node.  */
> > + TREE_TYPE (mem_initializer) = build0 (EMPTY_CLASS_EXPR, NULL_TREE);
> > + SET_EXPR_LOCATION (TREE_TYPE (mem_initializer),
> > +make_location (token->location,
> > +   token->location, input_location));
> 
> Why not do this in cp_parser_mem_initializer?
> 
> Also, use parser->lexer for the last argument to make_location.

That's a much better spot for it :) Done and done.  Does the following
look OK after testing completes?

-- >8 --

Subject: [PATCH] c++: Member initializer list diagnostic locations [PR94024]

This patch preserves the source locations of each node in a member
initializer list so that during processing of the list we can set
input_location appropriately for generally more accurate diagnostic
locations.  Since TREE_LIST nodes are tcc_exceptional, they can't have
source locations, so we instead store the location in a dummy
tcc_expression node within the TREE_TYPE of the list node.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK to
commit?

gcc/cp/ChangeLog:

PR c++/94024
* init.c (sort_mem_initializers): Preserve TREE_TYPE of the
member initializer list node.
(emit_mem_initializers): Set input_location when performing each
member initialization.
* parser.c (cp_parser_mem_initializer): Attach the source
location of this initializer to a dummy EMPTY_CLASS_EXPR
within the TREE_TYPE of the list node.
* pt.c (tsubst_initializer_list): Preserve TREE_TYPE of the
member initializer list node.

gcc/testsuite/ChangeLog:

PR c++/94024
* g++.dg/diagnostic/mem-init1.C: New test.
---
 gcc/cp/init.c  

Re: [PATCH] c++: cxx_eval_vec_init after zero initialization [PR96282]

[Patrick Palka via Gcc-patches]

On Mon, 3 Aug 2020, Jason Merrill wrote:

> On 8/3/20 8:53 AM, Patrick Palka wrote:
> > On Mon, 3 Aug 2020, Patrick Palka wrote:
> > 
> > > In the first testcase below, expand_aggr_init_1 sets up t's default
> > > constructor such that the ctor first zero-initializes the entire base b,
> > > followed by calling b's default constructor, the latter of which just
> > > default-initializes the array member b::m via a VEC_INIT_EXPR.
> > > 
> > > So upon constexpr evaluation of this latter VEC_INIT_EXPR, ctx->ctor is
> > > nonempty due to the prior zero-initialization, and we proceed in
> > > cxx_eval_vec_init to append new constructor_elts to the end of ctx->ctor
> > > without first checking if a matching constructor_elt already exists.
> > > This leads to ctx->ctor having two matching constructor_elts for each
> > > index.
> > > 
> > > This patch partially fixes this issue by making the RANGE_EXPR
> > > optimization in cxx_eval_vec_init truncate ctx->ctor before adding the
> > > single RANGE_EXPR constructor_elt.  This isn't a complete fix because
> > > the RANGE_EXPR optimization applies only when the constant initializer
> > > is relocatable, so whenever it's not relocatable we can still build up
> > > an invalid CONSTRUCTOR, e.g. if in the first testcase we add an NSDMI
> > > such as 'e *p = this;' to struct e, then the ICE still occurs even with
> > > this patch.
> > 
> > A complete but more risky one-line fix would be to always truncate
> > ctx->ctor beforehand, not just when the RANGE_EXPR optimization applies.
> > If it's true that the initializer of a VEC_INIT_EXPR can't observe the
> > previous elements of the target array, then it should be safe to always
> > truncate I think?
> 
> What if default-initialization of the array element type doesn't fully
> initialize the elements, e.g. if 'e' had another member without a default
> initializer?  Does truncation first mean we lose the zero-initialization of
> such a member?

Hmm, it looks like we would lose the zero-initialization of such a
member with or without truncation first (so with any one of the three
proposed fixes).  I think it's because the evaluation loop in
cxx_eval_vec_init disregards each element's prior (zero-initialized)
state.

> 
> We could probably still do the truncation, but clear the
> CONSTRUCTOR_NO_CLEARING flag on the element initializer.

Ah, this seems to work well.  Like this?

-- >8 --

Subject: [PATCH] c++: cxx_eval_vec_init after zero initialization [PR96282]

In the first testcase below, expand_aggr_init_1 sets up t's default
constructor such that the ctor first zero-initializes the entire base b,
followed by calling b's default constructor, the latter of which just
default-initializes the array member b::m via a VEC_INIT_EXPR.

So upon constexpr evaluation of this latter VEC_INIT_EXPR, ctx->ctor is
nonempty due to the prior zero-initialization, and we proceed in
cxx_eval_vec_init to append new constructor_elts to the end of ctx->ctor
without first checking if a matching constructor_elt already exists.
This leads to ctx->ctor having two matching constructor_elts for each
index.

This patch fixes this issue by truncating a zero-initialized array
object in cxx_eval_vec_init_1 before we begin appending default-initialized
array elements to it.  Since default-initialization may leave parts of
the element type unitialized, we also preserve the array's prior
zero-initialized state by clearing CONSTRUCTOR_NO_CLEARING on each
appended element initializers.

gcc/cp/ChangeLog:

PR c++/96282
* constexpr.c (cxx_eval_vec_init_1): Truncate ctx->ctor and
then clear CONSTRUCTOR_NO_CLEARING on each appended element
initializer if we're default-initializing a previously
zero-initialized array object.

gcc/testsuite/ChangeLog:

PR c++/96282
* g++.dg/cpp0x/constexpr-array26.C: New test.
* g++.dg/cpp0x/constexpr-array27.C: New test.
* g++.dg/cpp2a/constexpr-init18.C: New test.
---
 gcc/cp/constexpr.c | 17 -
 gcc/testsuite/g++.dg/cpp0x/constexpr-array26.C | 13 +
 gcc/testsuite/g++.dg/cpp0x/constexpr-array27.C | 13 +
 gcc/testsuite/g++.dg/cpp2a/constexpr-init18.C  | 16 
 4 files changed, 58 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/constexpr-array26.C
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/constexpr-array27.C
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/constexpr-init18.C

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index b1c1d249c6e..706bef323b2 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -4171,6 +4171,17 @@ cxx_eval_vec_init_1 (const constexpr_ctx *ctx, tree 
atype, tree init,
   pre_init = true;
 }
 
+  bool zero_initialized_p = false;
+  if ((pre_init || value_init || !init) && initializer_zerop (ctx->ctor))
+{
+  /* We're default-initializing an array object that had been
+zero-initialized 

Re: libgo patch committed: Update to go1.15rc1

[Ian Lance Taylor via Gcc-patches]

On Mon, Aug 3, 2020 at 10:28 AM Andreas Schwab  wrote:
>
> On Aug 03 2020, Ian Lance Taylor wrote:
>
> > On Sun, Aug 2, 2020 at 12:50 AM Andreas Schwab  
> > wrote:
> >>
> >> This breaks ia64-linux.  According to
> >> arch/ia64/kernel/syscalls/syscall.tbl, the getrandom syscall is 315 and
> >> copy_file_range is 323.
> >>
> >> ../../../libgo/go/internal/syscall/unix/copy_file_range_linux.go:13:42: 
> >> error: reference to undefined name 'copyFileRangeTrap'
> >>13 | r1, _, errno := syscall.Syscall6(copyFileRangeTrap,
> >>   |  ^
> >> ../../../libgo/go/internal/syscall/unix/getrandom_linux.go:35:41: error: 
> >> reference to undefined name 'getrandomTrap'
> >>35 | r1, _, errno := syscall.Syscall(getrandomTrap,
> >>   | ^
> >> make[4]: *** [internal/syscall/unix.lo] Error 1
> >> make[4]: *** Waiting for unfinished jobs
> >
> > Thanks.  Fixed like so.  Committed to mainline.
>
> Actually, on ia64 syscall numbers are offset by 1024, thus the correct
> numbers are 1339 and 1347.

Ah ha.  I wondered why the number for the getrandom syscall was
different.  I committed this patch.

Ian
76eb0434a40f44f3f9c8a81cf22f56bbeccad12a
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index 39849522124..0bc8e1b5a59 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-82a0db12bcb205748a5319b03e070d5502246ba7
+7f0d3834ac40cf3bcbeb9b13926ab5ccb2523537
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
diff --git a/libgo/go/internal/syscall/unix/sysnum_linux_ia64.go 
b/libgo/go/internal/syscall/unix/sysnum_linux_ia64.go
index bb7c363cdc2..6a5d0c90fbe 100644
--- a/libgo/go/internal/syscall/unix/sysnum_linux_ia64.go
+++ b/libgo/go/internal/syscall/unix/sysnum_linux_ia64.go
@@ -5,6 +5,6 @@
 package unix
 
 const (
-   getrandomTrap uintptr = 315
-   copyFileRangeTrap uintptr = 323
+   getrandomTrap uintptr = 1339
+   copyFileRangeTrap uintptr = 1347
 )

Re: *PING* – Re: [Patch] OpenMP: Fix tmp-var handling with tree-nested.c [PR93553]

[Jakub Jelinek via Gcc-patches]

On Mon, Aug 03, 2020 at 06:01:40PM +0200, Tobias Burnus wrote:
> On 7/20/20 11:20 PM, Tobias Burnus wrote:
> > On 7/20/20 9:12 PM, Jakub Jelinek wrote:
> > > I don't like this global variable.
> > > Can you please instead stick it into struct nesting_info and make
> > > sure it is
> > > cleared where it is allocated?
> > 
> > Done. The existing code uses
> >struct nesting_info *info = XCNEW (struct nesting_info);
> > in create_nesting_tree; hence, the clearing is already done.

Sorry for the delay, wanted to look at it in more detail and didn't get to
it until now.
I think the patch as posted isn't the best thing to do, one thing is that
it will create the clauses even when OpenMP isn't enabled or the current
location isn't nested in an OpenMP region, or even when it is, but it isn't
inside of the clauses that contain gimple sequences.
I don't understand why convert_local_* has been changed at all.
Now, I guess one could get around that by having the
convert_nonlocal_*clauses* function set the pointer to address of a local
variable when it will deal with this and keep NULL otherwise and only add
clauses in those cases.
But it seems better to me to follow what we do in all the other cases.
E.g. if the outer function's PARM_DECL is referenced inside of OMP_PARALLEL
body, then it works fine because OMP_PARALLEL handling does:
  save_local_var_chain = info->new_local_var_chain;
  info->new_local_var_chain = NULL;
before the body walk and
  if (info->new_local_var_chain)
declare_vars (info->new_local_var_chain,
  gimple_seq_first_stmt (gimple_omp_body (stmt)),
  false);
  info->new_local_var_chain = save_local_var_chain;
afterwards, which means we don't really need any extra clauses, because the
temporaries will be declared inside of the parallel body rather than at some
outer scope.
I think we want to follow the suit with all the walks for clauses that
contain gimple sequences, so around the
OMP_CLAUSE_REDUCTION_GIMPLE_INIT
walk, around the
OMP_CLAUSE_REDUCTION_GIMPLE_MERGE
walk, around
OMP_CLAUSE_LASTPRIVATE_GIMPLE_SEQ
and
OMP_CLAUSE_LINEAR_GIMPLE_SEQ.
And probably both in the convert_nonlocal* case and in the convert_local*
case too.

Can you try that?  Or do you want me to try?

Jakub

Re: libgo patch committed: Update to go1.15rc1

[Andreas Schwab]

On Aug 03 2020, Ian Lance Taylor wrote:

> On Sun, Aug 2, 2020 at 12:50 AM Andreas Schwab  wrote:
>>
>> This breaks ia64-linux.  According to
>> arch/ia64/kernel/syscalls/syscall.tbl, the getrandom syscall is 315 and
>> copy_file_range is 323.
>>
>> ../../../libgo/go/internal/syscall/unix/copy_file_range_linux.go:13:42: 
>> error: reference to undefined name 'copyFileRangeTrap'
>>13 | r1, _, errno := syscall.Syscall6(copyFileRangeTrap,
>>   |  ^
>> ../../../libgo/go/internal/syscall/unix/getrandom_linux.go:35:41: error: 
>> reference to undefined name 'getrandomTrap'
>>35 | r1, _, errno := syscall.Syscall(getrandomTrap,
>>   | ^
>> make[4]: *** [internal/syscall/unix.lo] Error 1
>> make[4]: *** Waiting for unfinished jobs
>
> Thanks.  Fixed like so.  Committed to mainline.

Actually, on ia64 syscall numbers are offset by 1024, thus the correct
numbers are 1339 and 1347.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: libgo patch committed: Update to go1.15rc1

[Ian Lance Taylor via Gcc-patches]

On Sun, Aug 2, 2020 at 12:50 AM Andreas Schwab  wrote:
>
> This breaks ia64-linux.  According to
> arch/ia64/kernel/syscalls/syscall.tbl, the getrandom syscall is 315 and
> copy_file_range is 323.
>
> ../../../libgo/go/internal/syscall/unix/copy_file_range_linux.go:13:42: 
> error: reference to undefined name 'copyFileRangeTrap'
>13 | r1, _, errno := syscall.Syscall6(copyFileRangeTrap,
>   |  ^
> ../../../libgo/go/internal/syscall/unix/getrandom_linux.go:35:41: error: 
> reference to undefined name 'getrandomTrap'
>35 | r1, _, errno := syscall.Syscall(getrandomTrap,
>   | ^
> make[4]: *** [internal/syscall/unix.lo] Error 1
> make[4]: *** Waiting for unfinished jobs

Thanks.  Fixed like so.  Committed to mainline.

Ian
d8ea6acb5f586aabbde0dc18ca3c2f3aced45a49
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index 89d1f3c7623..39849522124 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-2c390ba951e83b547f6387cc9e19436c085b3775
+82a0db12bcb205748a5319b03e070d5502246ba7
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
diff --git a/libgo/go/internal/syscall/unix/getrandom_linux_alpha.go 
b/libgo/go/internal/syscall/unix/getrandom_linux_alpha.go
deleted file mode 100644
index 9587b5aa4ca..000
--- a/libgo/go/internal/syscall/unix/getrandom_linux_alpha.go
+++ /dev/null
@@ -1,9 +0,0 @@
-// Copyright 2016 The Go Authors. All rights reserved.
-// Use of this source code is governed by a BSD-style
-// license that can be found in the LICENSE file.
-
-package unix
-
-// Linux getrandom system call number.
-// See GetRandom in getrandom_linux.go.
-const randomTrap uintptr = 511
diff --git a/libgo/go/internal/syscall/unix/getrandom_linux_amd64p32.go 
b/libgo/go/internal/syscall/unix/getrandom_linux_amd64p32.go
deleted file mode 100644
index 911b6089ff3..000
--- a/libgo/go/internal/syscall/unix/getrandom_linux_amd64p32.go
+++ /dev/null
@@ -1,9 +0,0 @@
-// Copyright 2018 The Go Authors. All rights reserved.
-// Use of this source code is governed by a BSD-style
-// license that can be found in the LICENSE file.
-
-package unix
-
-// Linux getrandom system call number.
-// See GetRandom in getrandom_linux.go.
-const randomTrap uintptr = 0x4000 + 318
diff --git a/libgo/go/internal/syscall/unix/getrandom_linux_ia64.go 
b/libgo/go/internal/syscall/unix/getrandom_linux_ia64.go
deleted file mode 100644
index d20ba238fcf..000
--- a/libgo/go/internal/syscall/unix/getrandom_linux_ia64.go
+++ /dev/null
@@ -1,9 +0,0 @@
-// Copyright 2016 The Go Authors. All rights reserved.
-// Use of this source code is governed by a BSD-style
-// license that can be found in the LICENSE file.
-
-package unix
-
-// Linux getrandom system call number.
-// See GetRandom in getrandom_linux.go.
-const randomTrap uintptr = 1339
diff --git a/libgo/go/internal/syscall/unix/getrandom_linux_m68k.go 
b/libgo/go/internal/syscall/unix/getrandom_linux_m68k.go
deleted file mode 100644
index 5559d30d331..000
--- a/libgo/go/internal/syscall/unix/getrandom_linux_m68k.go
+++ /dev/null
@@ -1,9 +0,0 @@
-// Copyright 2017 The Go Authors. All rights reserved.
-// Use of this source code is governed by a BSD-style
-// license that can be found in the LICENSE file.
-
-package unix
-
-// Linux getrandom system call number.
-// See GetRandom in getrandom_linux.go.
-const randomTrap uintptr = 352
diff --git a/libgo/go/internal/syscall/unix/getrandom_linux_mips64p32x.go 
b/libgo/go/internal/syscall/unix/getrandom_linux_mips64p32x.go
deleted file mode 100644
index 4d8f6c53a99..000
--- a/libgo/go/internal/syscall/unix/getrandom_linux_mips64p32x.go
+++ /dev/null
@@ -1,11 +0,0 @@
-// Copyright 2016 The Go Authors. All rights reserved.
-// Use of this source code is governed by a BSD-style
-// license that can be found in the LICENSE file.
-
-// +build mips64p32 mips64p32le
-
-package unix
-
-// Linux getrandom system call number.
-// See GetRandom in getrandom_linux.go.
-const randomTrap uintptr = 6317
diff --git a/libgo/go/internal/syscall/unix/getrandom_linux_s390.go 
b/libgo/go/internal/syscall/unix/getrandom_linux_s390.go
deleted file mode 100644
index e3bc4ee355c..000
--- a/libgo/go/internal/syscall/unix/getrandom_linux_s390.go
+++ /dev/null
@@ -1,9 +0,0 @@
-// Copyright 2016 The Go Authors. All rights reserved.
-// Use of this source code is governed by a BSD-style
-// license that can be found in the LICENSE file.
-
-package unix
-
-// Linux getrandom system call number.
-// See GetRandom in getrandom_linux.go.
-const randomTrap uintptr = 349
diff --git a/libgo/go/internal/syscall/unix/getrandom_linux_shx.go 
b/libgo/go/internal/syscall/unix/getrandom_linux_shx.go
deleted file mode 100644
index e0e3521a704..000
--- a/libgo/go/internal/syscall/unix/getrandom_linux_shx.go
+++ /dev/null

Re: [PATCH wwwdocs] Explicitly list powerpc64le-unknown-linux-gnu as a primary platform

[David Edelsohn via Gcc-patches]

On Mon, Jul 13, 2020 at 8:06 AM Florian Weimer  wrote:
>
> The intent was that this was implied by powerpc64-unknown-linux-gnu,
> but this not very obvious because of the ELFv1 vs ELFv2 ABI
> differences.

It's okay to _add_ PPC64LE without removing PPC64.  This is okay.

I'm not certain why it's useful to retroactively add the criterion to
GCC9 and GCC10, but whatever.

Thanks, David

[pushed] PR tree-optimization/96430: Avoid shifting by amounts larger than target int in irange self-tests.

[Aldy Hernandez via Gcc-patches]

Fixes PR.

Pushed.
commit 6c4763fa5b55f6e883ed7077b67c6175c2da63d1
Author: Aldy Hernandez 
Date:   Mon Aug 3 18:30:30 2020 +0200

Avoid shifting by amounts larger than target int in irange self-tests.

gcc/ChangeLog:

PR tree-optimization/96430
* range-op.cc (operator_tests): Do not shift by 31 on targets with
integer's smaller than 32 bits.

diff --git a/gcc/range-op.cc b/gcc/range-op.cc
index c62e3977ce5..b7b708b488b 100644
--- a/gcc/range-op.cc
+++ b/gcc/range-op.cc
@@ -3527,15 +3527,16 @@ operator_tests ()
   }
 
   // signed: ~[-1] = OP1 >> 31
-  {
-widest_irange lhs (INT (-1), INT (-1), VR_ANTI_RANGE);
-widest_irange shift (INT (31), INT (31));
-widest_irange op1;
-op_rshift.op1_range (op1, integer_type_node, lhs, shift);
-widest_irange negatives = range_negatives (integer_type_node);
-negatives.intersect (op1);
-ASSERT_TRUE (negatives.undefined_p ());
-  }
+  if (TYPE_PRECISION (integer_type_node) > 31)
+{
+  widest_irange lhs (INT (-1), INT (-1), VR_ANTI_RANGE);
+  widest_irange shift (INT (31), INT (31));
+  widest_irange op1;
+  op_rshift.op1_range (op1, integer_type_node, lhs, shift);
+  widest_irange negatives = range_negatives (integer_type_node);
+  negatives.intersect (op1);
+  ASSERT_TRUE (negatives.undefined_p ());
+}
 }
 
 // Run all of the selftests within this file.

*PING* – Re: [Patch] OpenMP: Fix tmp-var handling with tree-nested.c [PR93553]

[Tobias Burnus]

On 7/20/20 11:20 PM, Tobias Burnus wrote:

On 7/20/20 9:12 PM, Jakub Jelinek wrote:

I don't like this global variable.
Can you please instead stick it into struct nesting_info and make
sure it is
cleared where it is allocated?


Done. The existing code uses
   struct nesting_info *info = XCNEW (struct nesting_info);
in create_nesting_tree; hence, the clearing is already done.

Tobias


-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

[Qing Zhao via Gcc-patches]

Hi, Uros,

Thanks a lot for your review on X86 parts.

Hi, Richard,

Could you please take a look at the middle-end part to see whether the 
rewritten addressed your previous concern?

Thanks a lot.

Qing


> On Jul 31, 2020, at 12:57 PM, Uros Bizjak  wrote:
> 
> 
> 22:05, tor., 28. jul. 2020 je oseba Qing Zhao  > napisala:
> >
> >
> > Richard and Uros,
> >
> > Could you please review the change that H.J and I rewrote based on your 
> > comments in the previous round of discussion?
> >
> > This patch is a nice security enhancement for GCC that has been requested 
> > by security people for quite some time.  
> >
> > Thanks a lot for your time.
> 
> I'll be away from the keyboard for the next week, but the patch needs a 
> middle end approval first.
> 
> That said, x86 parts looks OK.
> 
> 

> Uros.
> > Qing
> >
> > > On Jul 14, 2020, at 9:45 AM, Qing Zhao via Gcc-patches 
> > > mailto:gcc-patches@gcc.gnu.org>> wrote:
> > > 
> > > Hi, Gcc team,
> > > 
> > > This patch is a follow-up on the previous patch and corresponding 
> > > discussion:
> > > https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545101.html 
> > >  
> > >  > > >
> > > 
> > > From the previous round of discussion, the major issues raised were:
> > > 
> > > A. should be rewritten by using regsets infrastructure.  
> > > B. Put the patch into middle-end instead of x86 backend. 
> > > 
> > > This new patch is rewritten based on the above 2 comments.  The major 
> > > changes compared to the previous patch are:
> > > 
> > > 1. Change the names of the option and attribute from 
> > > -mzero-caller-saved-regs=[skip|used-gpr|all-gpr|used|all]  and 
> > > zero_caller_saved_regs("skip|used-gpr|all-gpr||used|all”)
> > > to:
> > > -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]   and  
> > > zero_call_used_regs("skip|used-gpr|all-gpr||used|all”) 
> > > Add the new option and  new attribute in general. 
> > > 2. The main code generation part is moved from i386 backend to middle-end;
> > > 3. Add 4 target-hooks;
> > > 4. Implement these 4 target-hooks on i386 backend. 
> > > 5. On a target that does not implement the target hook, issue error for 
> > > the new option, issue warning for the new attribute.
> > > 
> > > The patch is as following:
> > > 
> > > [PATCH] Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]
> > > command-line option and
> > > zero_call_used_regs("skip|used-gpr|all-gpr||used|all") function attribue:
> > > 
> > >  1. -fzero-call-used-regs=skip and zero_call_used_regs("skip")
> > > 
> > >  Don't zero call-used registers upon function return.
> > > 
> > >  2. -fzero-call-used-regs=used-gpr and zero_call_used_regs("used-gpr")
> > > 
> > >  Zero used call-used general purpose registers upon function return.
> > > 
> > >  3. -fzero-call-used-regs=all-gpr and zero_call_used_regs("all-gpr")
> > > 
> > >  Zero all call-used general purpose registers upon function return.
> > > 
> > >  4. -fzero-call-used-regs=used and zero_call_used_regs("used")
> > > 
> > >  Zero used call-used registers upon function return.
> > > 
> > >  5. -fzero-call-used-regs=all and zero_call_used_regs("all")
> > > 
> > >  Zero all call-used registers upon function return.
> > > 
> > > The feature is implemented in middle-end. But currently is only valid on 
> > > X86.
> > > 
> > > Tested on x86-64 and aarch64 with bootstrapping GCC trunk, making
> > > -fzero-call-used-regs=used-gpr, -fzero-call-used-regs=all-gpr
> > > -fzero-call-used-regs=used, and -fzero-call-used-regs=all enabled
> > > by default on x86-64.
> > > 
> > > Please take a look and let me know any more comment?
> > > 
> > > thanks.
> > > 
> > > Qing
> > > 
> > > 
> > > 
> > > 
> > > gcc/ChangeLog:
> > > 
> > > 2020-07-13  qing zhao   > >   > > >>
> > > 2020-07-13  H.J. Lu mailto:hjl.to...@gmail.com> 
> > > >>
> > > 
> > >   * common.opt: Add new option -fzero-call-used-regs.
> > >   * config/i386/i386.c (ix86_zero_call_used_regno_p): New function.
> > >   (ix86_zero_call_used_regno_mode): Likewise.
> > >   (ix86_zero_all_vector_registers): Likewise.
> > >   (ix86_expand_prologue): Replace gen_prologue_use with
> > >   gen_pro_epilogue_use.
> > >   (TARGET_ZERO_CALL_USED_REGNO_P): Define.
> > >   (TARGET_ZERO_CALL_USED_REGNO_MODE): Define.
> > >   (TARGET_PRO_EPILOGUE_USE): Define.
> > >   (TARGET_ZERO_ALL_VECTOR_REGISTERS): Define.
> > >   * config/i386/i386.md: Replace UNSPECV_PROLOGUE_USE
> > >   with UNSPECV_PRO_EPILOGUE_USE.
> > >   * coretypes.h (enum zero_call_used_regs): New type.
> > >   * doc/extend.texi: Document the new 

Re: [PATCH PR96366][AARCH64] Add support for unpacked vector sub

[Richard Sandiford]

bule  writes:
> Hi, 
>
> The test case bb-slp-20.c in the gcc testsuit will cause an ICE in the expand 
> pass due to the lack of a pattern for subtraction of the VNx2SI mode. I think 
> the problem has been fully discussed on PR 96366.
>
> The attached file is the patch to solve this problem. Bootstrapped and tested 
> on aarch64-linux-gnu. Ok for trunk?

Thanks, pushed to trunk.

Richard

[Patch] OpenMP: Handle cpp_implicit_alias in declare-target discovery (PR96390)

[Tobias Burnus]

It turned out that the omp_discover_declare_target_tgt_fn_r
discovered all nodes – but as it tagged the C++ alias nodes
and not the streamed-out nodes, no device function was created
and one got link errors if offloading devices were configured.
(Only with -O0 as otherwise inlining happened.)

(Testcase is based on a sollve_vv testcase which in turn was
based on an LLVM bugreport.)

OK?

Tobias

-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter
OpenMP: Handle cpp_implicit_alias in declare-target discovery (PR96390)

gcc/ChangeLog:

	PR middle-end/96390
	* omp-offload.c (omp_discover_declare_target_tgt_fn_r): Handle
	cpp_implicit_alias nodes.

libgomp/ChangeLog:

	PR middle-end/96390
	* testsuite/libgomp.c++/pr96390.C: New test.

 gcc/omp-offload.c   |  8 ++
 libgomp/testsuite/libgomp.c++/pr96390.C | 49 +
 2 files changed, 57 insertions(+)

diff --git a/gcc/omp-offload.c b/gcc/omp-offload.c
index 32c2485abd4..4aef7dbea6c 100644
--- a/gcc/omp-offload.c
+++ b/gcc/omp-offload.c
@@ -207,6 +207,14 @@ omp_discover_declare_target_tgt_fn_r (tree *tp, int *walk_subtrees, void *data)
   symtab_node *node = symtab_node::get (*tp);
   if (node != NULL)
 	{
+	  if (node->cpp_implicit_alias)
+	{
+	  node = node->get_alias_target ();
+	  if (!omp_declare_target_fn_p (node->decl))
+		((vec *) data)->safe_push (node->decl);
+	  DECL_ATTRIBUTES (node->decl)
+		= tree_cons (id, NULL_TREE, DECL_ATTRIBUTES (node->decl));
+	}
 	  node->offloadable = 1;
 	  if (ENABLE_OFFLOADING)
 	g->have_offload = true;
diff --git a/libgomp/testsuite/libgomp.c++/pr96390.C b/libgomp/testsuite/libgomp.c++/pr96390.C
new file mode 100644
index 000..098cb103919
--- /dev/null
+++ b/libgomp/testsuite/libgomp.c++/pr96390.C
@@ -0,0 +1,49 @@
+/* { dg-do run } */
+/* { dg-additional-options "-O0 -fdump-tree-omplower" } */
+
+#include 
+#include 
+
+template struct V {
+  int version_called;
+
+  template::type>
+  V ()
+  {
+version_called = 1;
+  }
+
+  template::type>::value)>::type>
+  V (TArg0)
+  {
+version_called = 2;
+  }
+};
+
+template struct S {
+  V v;
+};
+
+int
+main ()
+{
+  int version_set[2] = {-1, -1};
+
+#pragma omp target map(from: version_set[0:2])
+  {
+S<0> s;
+version_set[0] = s.v.version_called;
+V<1> v2((unsigned long) 1);
+version_set[1] = v2.version_called;
+  }
+
+  if (version_set[0] != 1 || version_set[1] != 2)
+abort ();
+  return 0;
+}
+
+/* "3" for S<0>::S, V<0>::V<>, and V<1>::V:  */
+/* { dg-final { scan-tree-dump-times "__attribute__..omp declare target" 3 "omplower" } } */

Re: [PATCH] c: Fix bogus vector initialisation error [PR96377]

[Richard Sandiford]

Jakub Jelinek  writes:
> On Mon, Aug 03, 2020 at 01:26:34PM +0200, Andreas Schwab wrote:
>> On Jul 31 2020, Richard Sandiford wrote:
>> 
>> >* gcc.dg/pr96377-1.c: New test.
>> >* gcc.dg/pr96377-2.c: Likewise.
>> 
>> Excess errors:
>> /daten/gcc/gcc-20200801/gcc/testsuite/gcc.dg/pr96377-2.c:11:1: warning: GCC 
>> vector passed by reference: non-standard ABI extension with no compatibility 
>> guarantee [-Wpsabi]
>> 
>> Excess errors:
>> /daten/gcc/gcc-20200801/gcc/testsuite/gcc.dg/pr96377-2.c:11:1: warning: GCC 
>> vector passed by reference: non-standard ABI extension with no compatibility 
>> guarantee [-Wpsabi]
>
> Usually we add -Wno-psabi -w to dg-options for such tests.

I just went for -Wno-psabi here.  Since the tests are tests for
diagnostics, I'd prefer not to add -w as well.

Tested on powerpc-linux-gnu.  Pushed to trunk and GCC 10 as obvious.

Richard


gcc/testsuite/
* gcc.dg/pr96377-1.c: Add -Wno-psabi.
* gcc.dg/pr96377-2.c: Likewise.
---
 gcc/testsuite/gcc.dg/pr96377-1.c | 2 +-
 gcc/testsuite/gcc.dg/pr96377-2.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/pr96377-1.c b/gcc/testsuite/gcc.dg/pr96377-1.c
index 2bf3f816331..75b0c9618ef 100644
--- a/gcc/testsuite/gcc.dg/pr96377-1.c
+++ b/gcc/testsuite/gcc.dg/pr96377-1.c
@@ -1,4 +1,4 @@
-/* { dg-options "-fno-lax-vector-conversions" } */
+/* { dg-options "-fno-lax-vector-conversions -Wno-psabi" } */
 /* { dg-message "use '-flax-vector-conversions' to permit conversions" "" { 
target *-*-* } 0 } */
 
 typedef int v4si __attribute__((vector_size(16)));
diff --git a/gcc/testsuite/gcc.dg/pr96377-2.c b/gcc/testsuite/gcc.dg/pr96377-2.c
index f58b06d9076..83550401156 100644
--- a/gcc/testsuite/gcc.dg/pr96377-2.c
+++ b/gcc/testsuite/gcc.dg/pr96377-2.c
@@ -1,4 +1,4 @@
-/* { dg-options "-flax-vector-conversions" } */
+/* { dg-options "-flax-vector-conversions -Wno-psabi" } */
 
 typedef int v4si __attribute__((vector_size(16)));
 typedef short v8hi __attribute__((vector_size(16)));

Re: [PATCH] c++: cxx_eval_vec_init after zero initialization [PR96282]

[Jason Merrill via Gcc-patches]

On 8/3/20 8:53 AM, Patrick Palka wrote:

On Mon, 3 Aug 2020, Patrick Palka wrote:


In the first testcase below, expand_aggr_init_1 sets up t's default
constructor such that the ctor first zero-initializes the entire base b,
followed by calling b's default constructor, the latter of which just
default-initializes the array member b::m via a VEC_INIT_EXPR.

So upon constexpr evaluation of this latter VEC_INIT_EXPR, ctx->ctor is
nonempty due to the prior zero-initialization, and we proceed in
cxx_eval_vec_init to append new constructor_elts to the end of ctx->ctor
without first checking if a matching constructor_elt already exists.
This leads to ctx->ctor having two matching constructor_elts for each
index.

This patch partially fixes this issue by making the RANGE_EXPR
optimization in cxx_eval_vec_init truncate ctx->ctor before adding the
single RANGE_EXPR constructor_elt.  This isn't a complete fix because
the RANGE_EXPR optimization applies only when the constant initializer
is relocatable, so whenever it's not relocatable we can still build up
an invalid CONSTRUCTOR, e.g. if in the first testcase we add an NSDMI
such as 'e *p = this;' to struct e, then the ICE still occurs even with
this patch.


A complete but more risky one-line fix would be to always truncate
ctx->ctor beforehand, not just when the RANGE_EXPR optimization applies.
If it's true that the initializer of a VEC_INIT_EXPR can't observe the
previous elements of the target array, then it should be safe to always
truncate I think?


What if default-initialization of the array element type doesn't fully 
initialize the elements, e.g. if 'e' had another member without a 
default initializer?  Does truncation first mean we lose the 
zero-initialization of such a member?


We could probably still do the truncation, but clear the 
CONSTRUCTOR_NO_CLEARING flag on the element initializer.



Another complete fix would be to replace the uses of CONSTRUCTOR_APPEND_ELT
with get_or_insert_ctor_field, which does the right thing when a
matching constructor_elt already exists.  But get_or_insert_ctor_field
was introduced only in GCC 10, .

I'm not sure which fix we should go with in light of this being an
8/9/10/11 regression..



A side benefit of the approach taken by this patch is that constexpr
evaluation of a simple VEC_INIT_EXPR for a high-dimensional array no
longer scales exponentially with the number of dimensions.  This is
because after the RANGE_EXPR optimization, the CONSTRUCTOR for each
array dimension now consists of a single constructor_elt (with index
0...max-1) instead of two constructor_elts (with indexes 0 and 1...max-1
respectively).  This is verified by the second testcase below.

Bootstrapped and regtested on x86_64-pc-linux-gnu.  Does this look OK
for trunk and perhaps for backports?

gcc/cp/ChangeLog:

PR c++/96282
* constexpr.c (cxx_eval_vec_init_1): Move the i == 0 test to the
if statement that guards the RANGE_EXPR optimization. Consider the
RANGE_EXPR optimization before we append the first element.
Truncate ctx->ctor when performing the RANGE_EXPR optimization.
Make the built RANGE_EXPR start at index 0 instead of 1.  Don't
call unshare_constructor.

gcc/testsuite/ChangeLog:

PR c++/96282
* g++.dg/cpp0x/constexpr-array26.C: New test.
* g++.dg/cpp0x/constexpr-array27.C: New test.
---
  gcc/cp/constexpr.c| 36 ++-
  .../g++.dg/cpp0x/constexpr-array26.C  | 13 +++
  .../g++.dg/cpp0x/constexpr-array27.C  | 18 ++
  3 files changed, 51 insertions(+), 16 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/constexpr-array26.C
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/constexpr-array27.C

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index b1c1d249c6e..3808a0713ba 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -4189,7 +4189,7 @@ cxx_eval_vec_init_1 (const constexpr_ctx *ctx, tree 
atype, tree init,
  if (value_init || init == NULL_TREE)
{
  eltinit = NULL_TREE;
- reuse = i == 0;
+ reuse = true;
}
  else
eltinit = cp_build_array_ref (input_location, init, idx, complain);
@@ -4206,7 +4206,7 @@ cxx_eval_vec_init_1 (const constexpr_ctx *ctx, tree 
atype, tree init,
return ctx->ctor;
  eltinit = cxx_eval_constant_expression (_ctx, init, lval,
  non_constant_p, overflow_p);
- reuse = i == 0;
+ reuse = true;
}
else
{
@@ -4222,33 +4222,37 @@ cxx_eval_vec_init_1 (const constexpr_ctx *ctx, tree 
atype, tree init,
}
if (*non_constant_p && !ctx->quiet)
break;
-  if (new_ctx.ctor != ctx->ctor)
-   {
- /* We appended this element above; update the value.  */
- gcc_assert ((*p)->last().index == idx);
- (*p)->last().value 

Re: [PATCH] c++: Member initializer list diagnostic locations [PR94024]

[Jason Merrill via Gcc-patches]

On 8/3/20 10:14 AM, Patrick Palka wrote:

This patch preserves the source locations of each node in a member
initializer list so that during processing of the list we can set
input_location appropriately for generally more accurate diagnostic
locations.  Since TREE_LIST nodes are tcc_exceptional, they can't have
source locations, so we instead store the location in a dummy
tcc_expression node within the TREE_TYPE of the list node.



Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK to
commit?

gcc/cp/ChangeLog:

PR c++/94024
* init.c (sort_mem_initializers): Preserve TREE_TYPE of the
member initializer list node.
(emit_mem_initializers): Set input_location when performing each
member initialization.
* parser.c (cp_parser_mem_initializer_list): Attach the source
location of this initializer to a dummy EMPTY_CLASS_EXPR within
the TREE_TYPE of the list node.
* pt.c (tsubst_initializer_list): Preserve TREE_TYPE of the
member initializer list node.

gcc/testsuite/ChangeLog:

PR c++/94024
* g++.dg/diagnostic/mem-init1.C: New test.
---
  gcc/cp/init.c   |  6 +
  gcc/cp/parser.c |  8 ++
  gcc/cp/pt.c |  3 +++
  gcc/testsuite/g++.dg/diagnostic/mem-init1.C | 29 +
  4 files changed, 46 insertions(+)
  create mode 100644 gcc/testsuite/g++.dg/diagnostic/mem-init1.C

diff --git a/gcc/cp/init.c b/gcc/cp/init.c
index cb9bd2dbfba..3f089404cf2 100644
--- a/gcc/cp/init.c
+++ b/gcc/cp/init.c
@@ -1151,6 +1151,8 @@ sort_mem_initializers (tree t, tree mem_inits)
  
/* Record the initialization.  */

TREE_VALUE (subobject_init) = TREE_VALUE (init);
+  /* Carry over the dummy TREE_TYPE node containing the source location.  
*/
+  TREE_TYPE (subobject_init) = TREE_TYPE (init);
next_subobject = subobject_init;
  }
  
@@ -1367,6 +1369,10 @@ emit_mem_initializers (tree mem_inits)

/* Initialize the data members.  */
while (mem_inits)
  {
+  /* If this initializer was explicitly provided, then the dummy TREE_TYPE
+node contains the source location.  */
+  iloc_sentinel ils (EXPR_LOCATION (TREE_TYPE (mem_inits)));
+
perform_member_init (TREE_PURPOSE (mem_inits),
   TREE_VALUE (mem_inits));
mem_inits = TREE_CHAIN (mem_inits);
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index ab088874ba7..2f9b8786121 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -15326,6 +15326,14 @@ cp_parser_mem_initializer_list (cp_parser* parser)
{
  TREE_CHAIN (mem_initializer) = mem_initializer_list;
  mem_initializer_list = mem_initializer;
+
+ /* We can't attach the source location of this initializer directly to
+the list node, so we instead attach it to a dummy EMPTY_CLASS_EXPR
+within the TREE_TYPE of the list node.  */
+ TREE_TYPE (mem_initializer) = build0 (EMPTY_CLASS_EXPR, NULL_TREE);
+ SET_EXPR_LOCATION (TREE_TYPE (mem_initializer),
+make_location (token->location,
+   token->location, input_location));


Why not do this in cp_parser_mem_initializer?

Also, use parser->lexer for the last argument to make_location.


}
/* If the next token is not a `,', we're done.  */
if (cp_lexer_next_token_is_not (parser->lexer, CPP_COMMA))
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 3a168d506cf..bed1a3532e7 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -26014,6 +26014,9 @@ tsubst_initializer_list (tree t, tree argvec)
if (decl)
  {
init = build_tree_list (decl, init);
+ /* Carry over the dummy TREE_TYPE node containing the source
+location.  */
+ TREE_TYPE (init) = TREE_TYPE (t);
TREE_CHAIN (init) = inits;
inits = init;
  }
diff --git a/gcc/testsuite/g++.dg/diagnostic/mem-init1.C 
b/gcc/testsuite/g++.dg/diagnostic/mem-init1.C
new file mode 100644
index 000..b749c72cd8b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/diagnostic/mem-init1.C
@@ -0,0 +1,29 @@
+// PR c++/94024
+// { dg-do compile }
+
+struct A {
+A()
+: a()   // { dg-error "reference type" }
+, b(1)  // { dg-error "incompatible" }
+, c(0)  // { dg-bogus "" }
+{}
+
+int 
+int b[1];
+char c;
+};
+
+template
+struct B {
+B()
+: a()   // { dg-error "reference type" }
+, b(1)  // { dg-error "incompatible" }
+, c(0)  // { dg-bogus "" }
+{}
+
+T a;
+U b;
+char c;
+};
+
+B b;

[committed] MSP430: Don't pass redundant -md option to the assembler

[Jozef Lawrynowicz]

The MSP430 GAS option "-md" is supposed to indicate that the CRT startup
code should copy data from ROM to RAM at startup. However, this option
has no effect; GAS handles the related behaviour automatically.

Lightly regtested on trunk by running dg.exp with and without -mlarge.

Committed as obvious.
>From cc8c0049749736cdd88bc9c90f5df3961b97c67c Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz 
Date: Mon, 3 Aug 2020 15:54:52 +0100
Subject: [PATCH] MSP430: Don't pass redundant -md option to the assembler

The MSP430 GAS option "-md" is supposed to indicate that the CRT startup
code should copy data from ROM to RAM at startup. However, this option
has no effect; GAS handles the related behaviour automatically.

gcc/ChangeLog:

* config/msp430/msp430.h (ASM_SPEC): Don't pass on "-md" option.
---
 gcc/config/msp430/msp430.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/gcc/config/msp430/msp430.h b/gcc/config/msp430/msp430.h
index e97e833a10c..25007716d24 100644
--- a/gcc/config/msp430/msp430.h
+++ b/gcc/config/msp430/msp430.h
@@ -65,8 +65,6 @@ extern bool msp430x;
   "%{mrelax=-mQ} " /* Pass the relax option on to the assembler.  */ \
   /* Tell the assembler if we are building for the LARGE pointer model.  */ \
   "%{mlarge:-ml} " \
-  /* Copy data from ROM to RAM if necessary.  */ \
-  "%{!msim:-md} %{msim:%{mlarge:-md}} " \
   "%{msilicon-errata=*:-msilicon-errata=%*} " \
   "%{msilicon-errata-warn=*:-msilicon-errata-warn=%*} " \
   /* Create DWARF line number sections for -ffunction-sections.  */ \
-- 
2.27.0

RE: [PATCH] driver: Fix several memory leaks

[Alex Coplan]

Ping.

> -Original Message-
> From: Jit  On Behalf Of Alex Coplan
> Sent: 14 July 2020 10:08
> To: gcc-patches@gcc.gnu.org; j...@gcc.gnu.org
> Subject: [PATCH] driver: Fix several memory leaks
> 
> Updating the subject since this is really just a driver change (and
> therefore needs a review from those who can approve patches there).
> 
> Thanks,
> Alex
> 
> -Original Message-
> From: Jit  On Behalf Of Alex Coplan
> Sent: 09 July 2020 21:13
> To: gcc-patches@gcc.gnu.org; j...@gcc.gnu.org
> Cc: nd 
> Subject: [PATCH] libgccjit: Fix several memory leaks in the driver
> 
> Hello,
> 
> This patch fixes several memory leaks in the driver, all of which relate
> to the handling of static specs. We introduce functions
> set_static_spec_{shared,owned}() which are used to enforce proper memory
> management when updating the strings in the static_specs table.
> 
> This is achieved by making use of the alloc_p field in the table
> entries. Similarly to set_spec(), each time we update an entry, we check
> whether alloc_p is set, and free the old value if so. We then set
> alloc_p correctly based on whether we "own" this memory or whether we're
> just taking a pointer to a shared string which we shouldn't free.
> 
> The following table shows the number of leaks found by AddressSanitizer
> when running a minimal libgccjit program on AArch64. The test program
> does the whole libgccjit compilation cycle in a loop (including acquiring
> and releasing the context), and the table below shows the number of leaks
> for different iterations of that loop.
> 
> +--+-+-+--+---+
> | # of runs >  | 1   | 2   | 3| Leaks per run |
> +--+-+-+--+---+
> | Before patch | 463 | 940 | 1417 | 477   |
> +--+-+-+--+---+
> | After patch  | 416 | 846 | 1276 | 430   |
> +--+-+-+--+---+
> 
> Ensuring that we minimize "leaks per run" (ultimately eliminating all of
> them) is important in order for long-running applications to be able to
> make use of in-process libgccjit.
> 
> Testing:
>  * Bootstrap and regtest on aarch64-linxu-gnu, x86_64-linux-gnu.
>  * Bootstrap and regtest on aarch64-linux-gnu with bootstrap-asan config.
>  * Smoke test of libgccjit, ran regressions on a --disable-bootstrap
> build on
>aarch64-linux-gnu.
> 
> OK for master?
> 
> Thanks,
> Alex
> 
> ---
> 
> gcc/ChangeLog:
> 
> 2020-07-09  Alex Coplan  
> 
>   * gcc.c (set_static_spec): New.
>   (set_static_spec_owned): New.
>   (set_static_spec_shared): New.
>   (driver::maybe_putenv_COLLECT_LTO_WRAPPER): Use
>   set_static_spec_owned() to take ownership of lto_wrapper_file
>   such that it gets freed in driver::finalize.
>   (driver::maybe_run_linker): Use set_static_spec_shared() to
>   ensure that we don't try and free() the static string "ld",
>   also ensuring that any previously-allocated string in
>   linker_name_spec is freed. Likewise with argv0.
>   (driver::finalize): Use set_static_spec_shared() when resetting
>   specs that previously had allocated strings; remove if(0)
>   around call to free().

[PATCH] c++: Member initializer list diagnostic locations [PR94024]

[Patrick Palka via Gcc-patches]

This patch preserves the source locations of each node in a member
initializer list so that during processing of the list we can set
input_location appropriately for generally more accurate diagnostic
locations.  Since TREE_LIST nodes are tcc_exceptional, they can't have
source locations, so we instead store the location in a dummy
tcc_expression node within the TREE_TYPE of the list node.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK to
commit?

gcc/cp/ChangeLog:

PR c++/94024
* init.c (sort_mem_initializers): Preserve TREE_TYPE of the
member initializer list node.
(emit_mem_initializers): Set input_location when performing each
member initialization.
* parser.c (cp_parser_mem_initializer_list): Attach the source
location of this initializer to a dummy EMPTY_CLASS_EXPR within
the TREE_TYPE of the list node.
* pt.c (tsubst_initializer_list): Preserve TREE_TYPE of the
member initializer list node.

gcc/testsuite/ChangeLog:

PR c++/94024
* g++.dg/diagnostic/mem-init1.C: New test.
---
 gcc/cp/init.c   |  6 +
 gcc/cp/parser.c |  8 ++
 gcc/cp/pt.c |  3 +++
 gcc/testsuite/g++.dg/diagnostic/mem-init1.C | 29 +
 4 files changed, 46 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/diagnostic/mem-init1.C

diff --git a/gcc/cp/init.c b/gcc/cp/init.c
index cb9bd2dbfba..3f089404cf2 100644
--- a/gcc/cp/init.c
+++ b/gcc/cp/init.c
@@ -1151,6 +1151,8 @@ sort_mem_initializers (tree t, tree mem_inits)
 
   /* Record the initialization.  */
   TREE_VALUE (subobject_init) = TREE_VALUE (init);
+  /* Carry over the dummy TREE_TYPE node containing the source location.  
*/
+  TREE_TYPE (subobject_init) = TREE_TYPE (init);
   next_subobject = subobject_init;
 }
 
@@ -1367,6 +1369,10 @@ emit_mem_initializers (tree mem_inits)
   /* Initialize the data members.  */
   while (mem_inits)
 {
+  /* If this initializer was explicitly provided, then the dummy TREE_TYPE
+node contains the source location.  */
+  iloc_sentinel ils (EXPR_LOCATION (TREE_TYPE (mem_inits)));
+
   perform_member_init (TREE_PURPOSE (mem_inits),
   TREE_VALUE (mem_inits));
   mem_inits = TREE_CHAIN (mem_inits);
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index ab088874ba7..2f9b8786121 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -15326,6 +15326,14 @@ cp_parser_mem_initializer_list (cp_parser* parser)
{
  TREE_CHAIN (mem_initializer) = mem_initializer_list;
  mem_initializer_list = mem_initializer;
+
+ /* We can't attach the source location of this initializer directly to
+the list node, so we instead attach it to a dummy EMPTY_CLASS_EXPR
+within the TREE_TYPE of the list node.  */
+ TREE_TYPE (mem_initializer) = build0 (EMPTY_CLASS_EXPR, NULL_TREE);
+ SET_EXPR_LOCATION (TREE_TYPE (mem_initializer),
+make_location (token->location,
+   token->location, input_location));
}
   /* If the next token is not a `,', we're done.  */
   if (cp_lexer_next_token_is_not (parser->lexer, CPP_COMMA))
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 3a168d506cf..bed1a3532e7 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -26014,6 +26014,9 @@ tsubst_initializer_list (tree t, tree argvec)
   if (decl)
 {
   init = build_tree_list (decl, init);
+ /* Carry over the dummy TREE_TYPE node containing the source
+location.  */
+ TREE_TYPE (init) = TREE_TYPE (t);
   TREE_CHAIN (init) = inits;
   inits = init;
 }
diff --git a/gcc/testsuite/g++.dg/diagnostic/mem-init1.C 
b/gcc/testsuite/g++.dg/diagnostic/mem-init1.C
new file mode 100644
index 000..b749c72cd8b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/diagnostic/mem-init1.C
@@ -0,0 +1,29 @@
+// PR c++/94024
+// { dg-do compile }
+
+struct A {
+A()
+: a()   // { dg-error "reference type" }
+, b(1)  // { dg-error "incompatible" }
+, c(0)  // { dg-bogus "" }
+{}
+
+int 
+int b[1];
+char c;
+};
+
+template
+struct B {
+B()
+: a()   // { dg-error "reference type" }
+, b(1)  // { dg-error "incompatible" }
+, c(0)  // { dg-bogus "" }
+{}
+
+T a;
+U b;
+char c;
+};
+
+B b;
-- 
2.28.0.89.g85b4e0a6dc

Re: [PATCH] Add C++2a synchronization support

[Jonathan Wakely via Gcc-patches]

On 05/06/20 17:29 -0700, Thomas Rodgers wrote:

diff --git a/libstdc++-v3/include/bits/semaphore_base.h 
b/libstdc++-v3/include/bits/semaphore_base.h
new file mode 100644
index 000..f0c4235d91c
--- /dev/null
+++ b/libstdc++-v3/include/bits/semaphore_base.h
@@ -0,0 +1,272 @@
+// -*- C++ -*- header.
+
+// Copyright (C) 2020 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// Under Section 7 of GPL version 3, you are granted additional
+// permissions described in the GCC Runtime Library Exception, version
+// 3.1, as published by the Free Software Foundation.
+
+// You should have received a copy of the GNU General Public License and
+// a copy of the GCC Runtime Library Exception along with this program;
+// see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+// .
+
+/** @file bits/semaphore_base.h
+ *  This is an internal header file, included by other library headers.
+ *  Do not attempt to use it directly. @headername{semaphore}
+ */
+
+#ifndef _GLIBCXX_SEMAPHORE_BASE_H
+#define _GLIBCXX_SEMAPHORE_BASE_H 1
+
+#pragma GCC system_header
+
+#include 
+#include 
+#include 
+
+#if defined _POSIX_SEMAPHORES  && __has_include()
+#define _GLIBCXX_HAVE_POSIX_SEMAPHORE 1
+#include 
+#endif
+
+#include 
+#include 
+
+namespace std _GLIBCXX_VISIBILITY(default)
+{
+_GLIBCXX_BEGIN_NAMESPACE_VERSION
+
+#ifdef _GLIBCXX_HAVE_POSIX_SEMAPHORE
+  template
+struct __platform_semaphore
+{


I think we want to delete the copy constructor and copy assignment
operator for this type and __atomic_semaphore.


+  using __clock_t = chrono::system_clock;
+
+  explicit __platform_semaphore(ptrdiff_t __count) noexcept
+  {
+   static_assert( __least_max_value <= SEM_VALUE_MAX, "");
+   auto __e = sem_init(&_M_semaphore, 0, __count);
+   if (__e)
+ std::terminate();


I don't think we should bother checking the return value. The failure
conditions are EINVAL if __count > SEM_VALUE_MAX, and ENOSYS if the
second argument is non-zero. Both conditions should be impossible.


+  }
+
+  ~__platform_semaphore()
+  {
+   auto __e = sem_destroy(&_M_semaphore);
+   if (__e)
+ std::terminate();


Likewise here. The only error condition is EINVAL, which is impossible
if _M_semaphore is a valid semaphore, which the constructor already
ensured.

If somehow _M_semaphore is invalid it means the user broke something
(e.g. by scribbling over *this) and we don't need to detect and handle
that case.


+  }
+
+  _GLIBCXX_ALWAYS_INLINE void
+  acquire() noexcept
+  {
+   auto __err = sem_wait(&_M_semaphore);
+   if (__err)
+ std::terminate();


What about the EINTR case where the wait is interrupted by a signal?
I think that should retry, but it shouldn't terminate.


+  template
+   bool
+   __try_acquire_until_impl(const chrono::time_point<__clock_t>& __atime) 
noexcept
+   {
+ auto __s = chrono::time_point_cast(__atime);
+ auto __ns = chrono::duration_cast(__atime - __s);
+
+ struct timespec __ts =
+ {
+   static_cast(__s.time_since_epoch().count()),
+   static_cast(__ns.count())
+ };
+
+ auto __err = sem_timedwait(&_M_semaphore, &__ts);
+ if (__err && (errno == ETIMEDOUT))
+ return false;
+ else if (__err)
+ std::terminate();


I think this needs to handle both EINTR and EINVAL:

   EINVAL The value of abs_timeout.tv_nsecs is less than 0, or greater than 
or equal to 1000 million.

Alternatively, just return immediately without waiting for a time
before the epoch, i.e.  __abs_time < time_point<__clock_t>{}

Otherwise time_point(-20ns) will cause EINVAL and terminate.



+ return true;
+   }
+
+  template
+   bool
+   try_acquire_until(const chrono::time_point<_Clock, _Duration>& __atime) 
noexcept
+   {
+ if constexpr (std::is_same<__clock_t, _Clock>::value)
+   {
+ return __try_acquire_until_impl(__atime);
+   }
+ else
+   {
+ const typename _Clock::time_point __c_entry = _Clock::now();
+ const __clock_t __s_entry = __clock_t::now();
+ const auto __delta = __atime - __c_entry;
+ const auto __s_atime = __s_entry + __delta;
+ if (__try_acquire_until_impl(__s_atime))
+   return true;
+
+ // We 

Re: [PATCH PR95696] regrename creates overlapping register allocations for vliw

[Richard Sandiford]

"Yangfei (Felix)"  writes:
> Hi Richard,
>
> Thanks for reviewing this fix and the detailed suggestions : -)
> Looks like my colleague Yunde was having some issue setting up his local 
> repo.
> I have prepared one for him.  Attached please find the patch.
> Bootstrapped and tested on aarch64-linux-gnu.  Please help install if 
> it's good to go.

Thanks, pushed to trunk.

Richard

Re: [PATCH v5] dse: Remove partial load after full store for high part access[PR71309]

[Richard Sandiford]

luoxhu  writes:
> Thanks, the v5 update as comments:
>  1. Move const_rhs shift out of loop;
>  2. Iterate from int size for read_mode.
>
>
> This patch could optimize(works for char/short/int/void*):
>
> 6: r119:TI=[r118:DI+0x10]
> 7: [r118:DI]=r119:TI
> 8: r121:DI=[r118:DI+0x8]
>
> =>
>
> 6: r119:TI=[r118:DI+0x10]
> 16: r122:DI=r119:TI#8
>
> Final ASM will be as below without partial load after full store(stxv+ld):
>   ld 10,16(3)
>   mr 9,3
>   ld 3,24(3)
>   std 10,0(9)
>   std 3,8(9)
>   blr
>
> It could achieve ~25% performance improvement for typical cases on
> Power9.  Bootstrap and regression tested on Power9-LE.
>
> For AArch64, one ldr is replaced by mov with this patch:
>
> ldp x2, x3, [x0, 16]
> stp x2, x3, [x0]
> ldr x0, [x0, 8]
>
> =>
>
> mov x1, x0
> ldp x2, x0, [x0, 16]
> stp x2, x0, [x1]
>
> gcc/ChangeLog:
>
> 2020-08-03  Xionghu Luo  
>
>   PR rtl-optimization/71309
>   * dse.c (find_shift_sequence): Use subreg of shifted from high part
>   register to avoid loading from address.
>
> gcc/testsuite/ChangeLog:
>
> 2020-08-03  Xionghu Luo  
>
>   PR rtl-optimization/71309
>   * gcc.target/powerpc/pr71309.c: New test.
> ---
>  gcc/dse.c  | 78 ++
>  gcc/testsuite/gcc.target/powerpc/pr71309.c | 33 +
>  2 files changed, 82 insertions(+), 29 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/powerpc/pr71309.c
>
> diff --git a/gcc/dse.c b/gcc/dse.c
> index bbe792e48e8..b67b5c2ba35 100644
> --- a/gcc/dse.c
> +++ b/gcc/dse.c
> @@ -1720,6 +1720,35 @@ find_shift_sequence (poly_int64 access_size,
>scalar_int_mode new_mode;
>rtx read_reg = NULL;
>  
> +  /* If a constant was stored into memory, try to simplify it here,
> + otherwise the cost of the shift might preclude this optimization
> + e.g. at -Os, even when no actual shift will be needed.  */
> +  if (store_info->const_rhs)
> +{
> +  auto new_mode = smallest_int_mode_for_size (access_size * 
> BITS_PER_UNIT);
> +  auto byte = subreg_lowpart_offset (new_mode, store_mode);
> +  rtx ret
> + = simplify_subreg (new_mode, store_info->const_rhs, store_mode, byte);
> +  if (ret && CONSTANT_P (ret))
> + {
> +   rtx shift_rtx = gen_int_shift_amount (new_mode, shift);
> +   ret = simplify_const_binary_operation (LSHIFTRT, new_mode, ret,
> +  shift_rtx);
> +   if (ret && CONSTANT_P (ret))
> + {
> +   byte = subreg_lowpart_offset (read_mode, new_mode);
> +   ret = simplify_subreg (read_mode, ret, new_mode, byte);
> +   if (ret && CONSTANT_P (ret)
> +   && (set_src_cost (ret, read_mode, speed)
> +   <= COSTS_N_INSNS (1)))
> + return ret;
> + }
> + }
> +}
> +
> +  if (require_cst)
> +return NULL_RTX;
> +
>/* Some machines like the x86 have shift insns for each size of
>   operand.  Other machines like the ppc or the ia-64 may only have
>   shift insns that shift values within 32 or 64 bit registers.
> @@ -1729,7 +1758,7 @@ find_shift_sequence (poly_int64 access_size,
>  
>opt_scalar_int_mode new_mode_iter;
>FOR_EACH_MODE_FROM (new_mode_iter,
> -   smallest_int_mode_for_size (access_size * BITS_PER_UNIT))
> +   smallest_int_mode_for_size (GET_MODE_BITSIZE (read_mode)))
>  {
>rtx target, new_reg, new_lhs;
>rtx_insn *shift_seq, *insn;
> @@ -1739,34 +1768,6 @@ find_shift_sequence (poly_int64 access_size,
>if (GET_MODE_BITSIZE (new_mode) > BITS_PER_WORD)
>   break;
>  
> -  /* If a constant was stored into memory, try to simplify it here,
> -  otherwise the cost of the shift might preclude this optimization
> -  e.g. at -Os, even when no actual shift will be needed.  */
> -  if (store_info->const_rhs)
> - {
> -   poly_uint64 byte = subreg_lowpart_offset (new_mode, store_mode);
> -   rtx ret = simplify_subreg (new_mode, store_info->const_rhs,
> -  store_mode, byte);
> -   if (ret && CONSTANT_P (ret))
> - {
> -   rtx shift_rtx = gen_int_shift_amount (new_mode, shift);
> -   ret = simplify_const_binary_operation (LSHIFTRT, new_mode,
> -  ret, shift_rtx);
> -   if (ret && CONSTANT_P (ret))
> - {
> -   byte = subreg_lowpart_offset (read_mode, new_mode);
> -   ret = simplify_subreg (read_mode, ret, new_mode, byte);
> -   if (ret && CONSTANT_P (ret)
> -   && (set_src_cost (ret, read_mode, speed)
> -   <= COSTS_N_INSNS (1)))
> - return ret;
> - }
> - }
> - }
> -
> -  if (require_cst)
> - return NULL_RTX;
> -
>/* Try a wider mode if truncating the store mode to NEW_MODE
>requires a real instruction.  */
>  

Re: [PATCH PR94442] [AArch64] Redundant ldp/stp instructions emitted at -O3

[Richard Sandiford]

xiezhiheng  writes:
>> -Original Message-
>> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
>> Sent: Friday, July 31, 2020 5:03 PM
>> To: xiezhiheng 
>> Cc: Richard Biener ; gcc-patches@gcc.gnu.org
>> Subject: Re: [PATCH PR94442] [AArch64] Redundant ldp/stp instructions
>> emitted at -O3
>> 
>> xiezhiheng  writes:
>> >> -Original Message-
>> >> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
>> >> Sent: Friday, July 17, 2020 5:04 PM
>> >> To: xiezhiheng 
>> >> Cc: Richard Biener ;
>> gcc-patches@gcc.gnu.org
>> >> Subject: Re: [PATCH PR94442] [AArch64] Redundant ldp/stp instructions
>> >> emitted at -O3
>> >>
>> >
>> > Cut...
>> >
>> >>
>> >> Thanks, pushed to master.
>> >>
>> >> Richard
>> >
>> > And I have finished the second part.
>> >
>> > In function aarch64_general_add_builtin, I add an argument ATTRS to
>> > pass attributes for each built-in function.
>> >
>> > And some new functions are added:
>> > aarch64_call_properties: return flags for each built-in function based
>> > on command-line options.  When the built-in function handles
>> > floating-points, add FLAG_FP flag.
>> >
>> > aarch64_modifies_global_state_p: True if the function would modify
>> > global states.
>> >
>> > aarch64_reads_global_state_p: True if the function would read
>> > global states.
>> >
>> > aarch64_could_trap_p: True if the function would raise a signal.
>> >
>> > aarch64_add_attribute: Add attributes in ATTRS.
>> >
>> > aarch64_get_attributes: return attributes for each built-in functons
>> > based on flags and command-line options.
>> >
>> > In function aarch64_init_simd_builtins, attributes are get by flags
>> > and pass them to function aarch64_general_add_builtin.
>> >
>> >
>> > Bootstrap is tested OK on aarch64 Linux platform, but regression
>> > FAIL one test case  pr93423.f90.
>> > However, I found that this test case would fail randomly in trunk.
>> >   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93423
>> >   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96041
>> > Some PRs have tracked it.  After my patch, this test case would
>> > always fail.  I guess the syntax errors in fortran crash some structures
>> > result in illegal memory access but I can't find what exactly it is.
>> > But I think my patch should have no influence on it.
>> 
>> Yeah, I agree.  And FWIW, I didn't see this in my testing.
>> 
>> I've pushed the patch with one trivial change: to remove the “and”
>> before “CODE” in:
>> 
>> >  /* Wrapper around add_builtin_function.  NAME is the name of the
>> built-in
>> > function, TYPE is the function type, and CODE is the function subcode
>> > -   (relative to AARCH64_BUILTIN_GENERAL).  */
>> > +   (relative to AARCH64_BUILTIN_GENERAL), and ATTRS is the function
>> > +   attributes.  */
>> 
>> BTW, one thing to be careful of in future is that not all FP intrinsics
>> raise FP exceptions.  So while:
>> 
>> > +  switch (d->mode)
>> > +{
>> > +/* Floating-point.  */
>> > +case E_BFmode:
>> > +case E_V4BFmode:
>> > +case E_V8BFmode:
>> > +case E_HFmode:
>> > +case E_V4HFmode:
>> > +case E_V8HFmode:
>> > +case E_SFmode:
>> > +case E_V2SFmode:
>> > +case E_V4SFmode:
>> > +case E_DFmode:
>> > +case E_V1DFmode:
>> > +case E_V2DFmode:
>> > +  flags |= FLAG_FP;
>> > +  break;
>> > +
>> > +default:
>> > +  break;
>> > +}
>> 
>> is a good, conservatively-correct default, we might need an additional
>> flag to suppress it for certain intrinsics.
>> 
>
> I agree.
>
>> I've just realised that the code above could have used FLOAT_MODE_P,
>> but I didn't think of that before pushing the patch :-)
>> 
>
> Sorry, I should have used it.  And I prepare a patch to use FLOAT_MODE_P
> macro and add a flag FLAG_SUPPRESS_FP_EXCEPTIONS to suppress
> FLAG_RAISE_FP_EXCEPTIONS for certain intrinsics in future.

The same thing is true for reading FPCR as well, so I think the flag
should suppress the FLOAT_MODE_P check, instead of fixing up the flags
afterwards.

I'm struggling to think of a good name though.  How about adding
FLAG_AUTO_FP and making the FLOAT_MODE_P check dependent on FLAG_AUTO_FP
being set?

We could leave FLAG_AUTO_FP out of FLAG_ALL, since FLAG_ALL already
includes FLAG_FP.  Including it in FLAG_ALL wouldn't do no any harm
though.

Thanks,
Richard

Re: Ellipsis in varadic macro definitions

[Richard Sandiford]

Jonathan Wakely via Gcc  writes:
> On Mon, 3 Aug 2020 at 11:28, Florian Weimer wrote:
>>
>> * Jonathan Wakely via Gcc:
>>
>> > On Sun, 2 Aug 2020 at 15:49, Philip R Brenan via Gcc  
>> > wrote:
>> >>
>> >> Hi *GCC*:
>> >>
>> >> On page:
>> >>
>> >> https://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html#Variadic-Macros
>> >>
>> >> you say:
>> >>
>> >> #define eprintf(args…) fprintf (stderr, args)
>> >>
>> >> but do you in fact mean:
>> >>
>> >> #define eprintf(args...) fprintf (stderr, args)
>> >>
>> >> The first variant produces:
>> >>
>> >> error: expected ',' or ')', found "…"
>> >>
>> >>  the second variant works well using GCC10.2 on Kubuntu 18.04.
>> >
>> > Yes, the texinfo source uses @dots which gets turned into  in
>> > the HTML, which isn't necessarily displayed as three separate dots in
>> > the browser. I don't know why @dots is used rather than ...
>>
>> It was introduced with:
>>
>> commit 1c5dd43ff7c78bbdba5e89a6cb16a3e50e1abff9
>> Author: Zack Weinberg 
>> Date:   Fri Jun 15 17:57:48 2001 +
>>
>> cpp.texi: Formatting corrections.
>>
>> * doc/cpp.texi: Formatting corrections.
>> Correct buggy example of use of __GNUC__ etc.
>> Clarify $ in identifiers.
>> * doc/cpp.1: Regenerate.
>>
>> From-SVN: r43404
>>
>> Some of these changes were clearly correct, but the ... C token should
>> have not been changed.  Looks like a simple oversight to me.
>
> Thanks for the archaeology, Florian.
>
> Here's a patch to replace those inappropriate @dots macros with the
> literal ... token.
>
> Tested by building the docs and inspecting the .info and .html output.
>
> OK for trunk?

OK, thanks.  (And for branches too.)

Richard

Re: [PATCH] Use exact=false for vec_safe_grow{,_cleared} functions.

[Richard Biener via Gcc-patches]

On Thu, Jul 30, 2020 at 3:22 PM Martin Liška  wrote:
>
> On 7/29/20 3:47 PM, Richard Biener wrote:
> > On Tue, Jul 28, 2020 at 12:23 PM Martin Liška  wrote:
> >>
> >> On 7/27/20 1:31 PM, Richard Biener wrote:
> >>> No, add gro*_exact variants and replace existing ones with this, then 
> >>> switch
> >>> to exact = false for the non-_exact variants.  Or add a exact=false 
> >>> argument
> >>> to all of them and make all existing calls explicitly passing true.
> >>
> >> -EBITLAZY
> >
> > Indeed you are - you're missing to update a lot of vec_safe_grow[_cleared]
> > calls.  Esp. the lto-streamer ones warrant a , true arg since we explicitly
> > streamed the number of elements.
>
> Yep, these should probably use exact allocation.
>
> >
> > How did you select the ones you updated and those you did not?
>
> Based on testing, I only kept changes in selective scheduling which caused
> some ICEs.
>
> (which
> > is why I asked for a boiler-plate replacement of , true first, then making
>
> This step would require to change about 250 places in the source code :(
>
> > the parameter defaulted to false and adjusting those cases you found)
>
> What about rather doing exact = true and changing the few places which don't 
> need
> it (as they make their of growth calculations)?

But that would be inconsistent with the other 'exact' defaulted params in vec.h.

I think your patch points at the valid issue that the usually
defaulted 'exact' is
overridden in non _exact named functions without any way to change that
override.  But then we shouldn't change behavior when correcting that mistake.

Which is why my original suggestion added non-defaulted 'exact' paramters
to those places (to discover all places that need adjustment) and only after
that default it and remove the cases now equal to the defaulted case ...

Richard.

> Martin
>
> >> Anyway, I prepared a patch that adds exact=false for all the grow 
> >> functions.
> >> Apart from selective scheduling, all other consumers seems happy. And I 
> >> removed
> >> the artificial capacity growth calculations at places mentioned by Honza.
> >>
> >> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> >>
> >> Ready to be installed?
> >> Thanks,
> >> Martin
>

Re: [PATCH] fix a typo in tm.texi

[Richard Sandiford]

Wei Wentao  writes:
> This patch fix a typo in tm.texi.

Thanks, applied as below.  tm.texi is generated from tm.texi.in,
so both files need the fix.

Richard

>From 5e97638b0adfb822d3b156c07da27d41091ce137 Mon Sep 17 00:00:00 2001
From: Wei Wentao 
Date: Mon, 3 Aug 2020 14:01:42 +0100
Subject: [PATCH] doc: fix a typo in tm.texi

gcc/
	* doc/tm.texi.in (VECTOR_STORE_FLAG_VALUE): Fix a typo.
	* doc/tm.texi: Regenerate.
---
 gcc/doc/tm.texi| 2 +-
 gcc/doc/tm.texi.in | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index 437187694b6..fb902b36d99 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -11284,7 +11284,7 @@ this macro.
 @end defmac
 
 @defmac VECTOR_STORE_FLAG_VALUE (@var{mode})
-A C expression that gives a rtx representing the nonzero true element
+A C expression that gives an rtx representing the nonzero true element
 for vector comparisons.  The returned rtx should be valid for the inner
 mode of @var{mode} which is guaranteed to be a vector mode.  Define
 this macro on machines that have vector comparison operations that
diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
index d76c85d5800..412e22c89ab 100644
--- a/gcc/doc/tm.texi.in
+++ b/gcc/doc/tm.texi.in
@@ -7661,7 +7661,7 @@ this macro.
 @end defmac
 
 @defmac VECTOR_STORE_FLAG_VALUE (@var{mode})
-A C expression that gives a rtx representing the nonzero true element
+A C expression that gives an rtx representing the nonzero true element
 for vector comparisons.  The returned rtx should be valid for the inner
 mode of @var{mode} which is guaranteed to be a vector mode.  Define
 this macro on machines that have vector comparison operations that
-- 
2.17.1

[committed] doc: Add missing comma after octeontx2f95mm

[Richard Sandiford]

Applied to trunk and GCC 10 (which was the first release to support
octeontx2f95mm).

Richard


gcc/
* doc/invoke.texi: Add missing comma after octeontx2f95mm entry.
---
 gcc/doc/invoke.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index afe09a93b1d..eb73f306051 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -17353,7 +17353,7 @@ performance of the code.  Permissible values for this 
option are:
 @samp{octeontx81},  @samp{octeontx83},
 @samp{octeontx2}, @samp{octeontx2t98}, @samp{octeontx2t96}
 @samp{octeontx2t93}, @samp{octeontx2f95}, @samp{octeontx2f95n},
-@samp{octeontx2f95mm}
+@samp{octeontx2f95mm},
 @samp{a64fx},
 @samp{thunderx}, @samp{thunderxt88},
 @samp{thunderxt88p1}, @samp{thunderxt81}, @samp{tsv110},
-- 
2.17.1

Re: [PATCH] aarch64: Add A64FX machine model

[Richard Sandiford]

Qian Jianhua  writes:
> This patch add support for Fujitsu A64FX, as the first step of adding
> A64FX machine model.
>
> A64FX is used in FUJITSU Supercomputer PRIMEHPC FX1000,
> PRIMEHPC FX700, and supercomputer Fugaku.
> The official microarchitecture information of A64FX can be read at
> https://github.com/fujitsu/A64FX.
>
> Changelog:
> 2020-08-03 Qian jianhua 
>
>   * config/aarch64/aarch64-cores.def: Add the chip name.
>   * config/aarch64/aarch64-tune.md: Regenerated.
>   * config/aarch64/aarch64.c: Add tuning table for the chip.
>   * doc/invoke.texi: Add the new name to the list.
>   
> Test results:
> * Bootstrap on aarch64 --- [OK]
> * Regression tests --- [OK]
> * Compile with -mcpu=a64fx --- [OK]

Thanks for doing this, looks great.  Pushed to trunk and the GCC 10 branch.

Would you like the patch to be backported further than GCC 10?  I wasn't
sure whether GCC 9 and earlier would be useful, given that those releases
didn't support the ACLE and were missing optimisations that went into GCC 10.

Very minor, but I tweaked the changelog entry slightly to:

2020-08-03  Qian jianhua  

gcc/
* config/aarch64/aarch64-cores.def (a64fx): New core.
* config/aarch64/aarch64-tune.md: Regenerated.
* config/aarch64/aarch64.c (a64fx_prefetch_tune, a64fx_tunings): New.
* doc/invoke.texi: Add a64fx to the list.

before committing.  The changelog entries are automatically applied to files
like gcc/ChangeLog on a nightly basis, and doing that would lose the context
in the covering message about which chip the patch is supporting.

Does the attached patch to document the addition to GCC 10.3 look OK?
We'll need something similar for GCC 11, but personally I tend to prefer
adding the notes closer to the release.

Thanks,
Richard

>From 671bc9f0c545040b2c2a255b68f461d9f26aa302 Mon Sep 17 00:00:00 2001
From: Richard Sandiford 
Date: Mon, 3 Aug 2020 12:34:31 +0100
Subject: [PATCH] Document A64FX support in GCC 10.3

---
 htdocs/gcc-10/changes.html | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index b40f9a57..be396747 100644
--- a/htdocs/gcc-10/changes.html
+++ b/htdocs/gcc-10/changes.html
@@ -1093,6 +1093,24 @@ known to be fixed in the 10.2 release. This list might 
not be
 complete (that is, it is possible that some PRs that have been fixed
 are not listed here).
 
+
+GCC 10.3
+
+Target Specific Changes
+
+AArch64
+
+  GCC now supports the Fujitsu A64FX.  The associated -mcpu
+  and -mtune options are -mcpu=a64fx and
+  -mtune=a64fx respectively.  In particular,
+  -mcpu=a64fx generates code for Armv8.2-A with SVE and tunes
+  the code for the A64FX.  This tuning includes optimizing SVE code
+  for a 512-bit vector length, although by default the code is still
+  length-agnostic and so works for all SVE implementations.
+  Adding -msve-vector-bits=512 makes the code specific
+  to 512-bit SVE.
+
+
 
 
 
-- 
2.17.1

Re: [committed] libstdc++: Constrain reverse_iterator and move_iterator conversions [LWG 3435]

[Jonathan Wakely via Gcc-patches]

On 01/08/20 00:49 +0200, Martin Jambor wrote:

Hi Jonathan,

On Wed, Jul 22 2020, Jonathan Wakely via Gcc-patches wrote:

libstdc++-v3/ChangeLog:

* include/bits/stl_iterator.h (reverse_iterator): Constrain
converting constructor and converting assignment operator.
Access source iterator's data member directly instead of
calling base().
(move_iterator): Likewise.
* testsuite/24_iterators/move_iterator/dr3435.cc: New test.
* testsuite/24_iterators/reverse_iterator/dr3435.cc: New test.

Tested powerpc64le-linux, committed to trunk.



with this patch, I fail to build 541.leela_r from SPEC INT 2017 even
when I specifically pass -std=c++98 to all compiler invocations.  Is
that expected?

A simple reproducer is:

-- aaa.cpp --
#include 

typedef unsigned long long int uint64;
std::vector ko_hash_history;
uint64 ko_hash;

bool bar(std::vector::const_reverse_iterator fisrst,
std::vector::const_reverse_iterator last,
std::vector::const_reverse_iterator res);

bool foo(void) {
   std::vector::const_reverse_iterator first = ko_hash_history.rbegin();
   std::vector::const_reverse_iterator last = ko_hash_history.rend();
   std::vector::const_reverse_iterator res;

   return bar(first, last, res);
}
--

$ /home/mjambor/gcc/mine/inst/bin/g++ -std=c++98 -m64 -c -O2 -g aaa.cpp

In file included from 
/home/mjambor/gcc/mine/inst/include/c++/11.0.0/bits/stl_algobase.h:67,
from /home/mjambor/gcc/mine/inst/include/c++/11.0.0/vector:60,
from aaa.cpp:1:
/home/mjambor/gcc/mine/inst/include/c++/11.0.0/bits/stl_iterator.h: In instantiation of 
‘std::reverse_iterator<_Iterator>::reverse_iterator(const std::reverse_iterator<_Iter>&) [with _Iter = 
__gnu_cxx::__normal_iterator >; _Iterator = 
__gnu_cxx::__normal_iterator >]’:
aaa.cpp:12:80:   required from here
/home/mjambor/gcc/mine/inst/include/c++/11.0.0/bits/stl_iterator.h:203:23: error: 
‘__gnu_cxx::__normal_iterator > 
std::reverse_iterator<__gnu_cxx::__normal_iterator > >::current’ is protected within this context
 203 | : current(__x.current) { }
 |   ^~~
/home/mjambor/gcc/mine/inst/include/c++/11.0.0/bits/stl_iterator.h:146:17: 
note: declared protected here
 146 |   _Iterator current;
 | ^~~

...which is exactly the error I get from leela.  The error goes away
when I use -std=c++11 instead (I promise I'll switch to building my
benchmarks with that or c++14 over the remaining of this year :-).

Is there a problem in the test (and the benchmark)?  Should I file a PR?


FTR I replied to Martin off-list, pointing out this was already filed
as https://gcc.gnu.org/PR96382 and is fixed already.

[PATCH] lto/96385 - avoid unused global UNDEFs in debug objects

[Richard Biener]

Unused global UNDEFs can have side-effects in some circumstances so
the following patch avoids them by treating them the same as other
to be discarded DEFs - make them local.

Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed to trunk.

2020-08-03  Richard Biener  

PR lto/96385
* simple-object-elf.c
(simple_object_elf_copy_lto_debug_sections): Localize global
UNDEFs and reuse the prevailing name.
---
 libiberty/simple-object-elf.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/libiberty/simple-object-elf.c b/libiberty/simple-object-elf.c
index c62d5bba551..7c9d492f6a4 100644
--- a/libiberty/simple-object-elf.c
+++ b/libiberty/simple-object-elf.c
@@ -1467,6 +1467,11 @@ simple_object_elf_copy_lto_debug_sections 
(simple_object_read *sobj,
   && st_shndx < shnum
   && pfnret[st_shndx - 1] == -1)
discard = 1;
+ /* We also need to remove global UNDEFs which can
+cause link fails later.  */
+ else if (st_shndx == SHN_UNDEF
+  && ELF_ST_BIND (*st_info) == STB_GLOBAL)
+   discard = 1;
 
  if (discard)
{
-- 
2.26.2

Re: [PATCH] c++: cxx_eval_vec_init after zero initialization [PR96282]

[Patrick Palka via Gcc-patches]

On Mon, 3 Aug 2020, Patrick Palka wrote:

> In the first testcase below, expand_aggr_init_1 sets up t's default
> constructor such that the ctor first zero-initializes the entire base b,
> followed by calling b's default constructor, the latter of which just
> default-initializes the array member b::m via a VEC_INIT_EXPR.
> 
> So upon constexpr evaluation of this latter VEC_INIT_EXPR, ctx->ctor is
> nonempty due to the prior zero-initialization, and we proceed in
> cxx_eval_vec_init to append new constructor_elts to the end of ctx->ctor
> without first checking if a matching constructor_elt already exists.
> This leads to ctx->ctor having two matching constructor_elts for each
> index.
> 
> This patch partially fixes this issue by making the RANGE_EXPR
> optimization in cxx_eval_vec_init truncate ctx->ctor before adding the
> single RANGE_EXPR constructor_elt.  This isn't a complete fix because
> the RANGE_EXPR optimization applies only when the constant initializer
> is relocatable, so whenever it's not relocatable we can still build up
> an invalid CONSTRUCTOR, e.g. if in the first testcase we add an NSDMI
> such as 'e *p = this;' to struct e, then the ICE still occurs even with
> this patch.

A complete but more risky one-line fix would be to always truncate
ctx->ctor beforehand, not just when the RANGE_EXPR optimization applies.
If it's true that the initializer of a VEC_INIT_EXPR can't observe the
previous elements of the target array, then it should be safe to always
truncate I think?

Another complete fix would be to replace the uses of CONSTRUCTOR_APPEND_ELT
with get_or_insert_ctor_field, which does the right thing when a
matching constructor_elt already exists.  But get_or_insert_ctor_field
was introduced only in GCC 10, .

I'm not sure which fix we should go with in light of this being an
8/9/10/11 regression..

> 
> A side benefit of the approach taken by this patch is that constexpr
> evaluation of a simple VEC_INIT_EXPR for a high-dimensional array no
> longer scales exponentially with the number of dimensions.  This is
> because after the RANGE_EXPR optimization, the CONSTRUCTOR for each
> array dimension now consists of a single constructor_elt (with index
> 0...max-1) instead of two constructor_elts (with indexes 0 and 1...max-1
> respectively).  This is verified by the second testcase below.
> 
> Bootstrapped and regtested on x86_64-pc-linux-gnu.  Does this look OK
> for trunk and perhaps for backports?
> 
> gcc/cp/ChangeLog:
> 
>   PR c++/96282
>   * constexpr.c (cxx_eval_vec_init_1): Move the i == 0 test to the
>   if statement that guards the RANGE_EXPR optimization. Consider the
>   RANGE_EXPR optimization before we append the first element.
>   Truncate ctx->ctor when performing the RANGE_EXPR optimization.
>   Make the built RANGE_EXPR start at index 0 instead of 1.  Don't
>   call unshare_constructor.
> 
> gcc/testsuite/ChangeLog:
> 
>   PR c++/96282
>   * g++.dg/cpp0x/constexpr-array26.C: New test.
>   * g++.dg/cpp0x/constexpr-array27.C: New test.
> ---
>  gcc/cp/constexpr.c| 36 ++-
>  .../g++.dg/cpp0x/constexpr-array26.C  | 13 +++
>  .../g++.dg/cpp0x/constexpr-array27.C  | 18 ++
>  3 files changed, 51 insertions(+), 16 deletions(-)
>  create mode 100644 gcc/testsuite/g++.dg/cpp0x/constexpr-array26.C
>  create mode 100644 gcc/testsuite/g++.dg/cpp0x/constexpr-array27.C
> 
> diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
> index b1c1d249c6e..3808a0713ba 100644
> --- a/gcc/cp/constexpr.c
> +++ b/gcc/cp/constexpr.c
> @@ -4189,7 +4189,7 @@ cxx_eval_vec_init_1 (const constexpr_ctx *ctx, tree 
> atype, tree init,
> if (value_init || init == NULL_TREE)
>   {
> eltinit = NULL_TREE;
> -   reuse = i == 0;
> +   reuse = true;
>   }
> else
>   eltinit = cp_build_array_ref (input_location, init, idx, complain);
> @@ -4206,7 +4206,7 @@ cxx_eval_vec_init_1 (const constexpr_ctx *ctx, tree 
> atype, tree init,
>   return ctx->ctor;
> eltinit = cxx_eval_constant_expression (_ctx, init, lval,
> non_constant_p, overflow_p);
> -   reuse = i == 0;
> +   reuse = true;
>   }
>else
>   {
> @@ -4222,33 +4222,37 @@ cxx_eval_vec_init_1 (const constexpr_ctx *ctx, tree 
> atype, tree init,
>   }
>if (*non_constant_p && !ctx->quiet)
>   break;
> -  if (new_ctx.ctor != ctx->ctor)
> - {
> -   /* We appended this element above; update the value.  */
> -   gcc_assert ((*p)->last().index == idx);
> -   (*p)->last().value = eltinit;
> - }
> -  else
> - CONSTRUCTOR_APPEND_ELT (*p, idx, eltinit);
> +
>/* Reuse the result of cxx_eval_constant_expression call
>from the first iteration to all others if it is a constant
>initializer that doesn't require relocations.  */
> -  if 

[PATCH] c++: cxx_eval_vec_init after zero initialization [PR96282]

[Patrick Palka via Gcc-patches]

In the first testcase below, expand_aggr_init_1 sets up t's default
constructor such that the ctor first zero-initializes the entire base b,
followed by calling b's default constructor, the latter of which just
default-initializes the array member b::m via a VEC_INIT_EXPR.

So upon constexpr evaluation of this latter VEC_INIT_EXPR, ctx->ctor is
nonempty due to the prior zero-initialization, and we proceed in
cxx_eval_vec_init to append new constructor_elts to the end of ctx->ctor
without first checking if a matching constructor_elt already exists.
This leads to ctx->ctor having two matching constructor_elts for each
index.

This patch partially fixes this issue by making the RANGE_EXPR
optimization in cxx_eval_vec_init truncate ctx->ctor before adding the
single RANGE_EXPR constructor_elt.  This isn't a complete fix because
the RANGE_EXPR optimization applies only when the constant initializer
is relocatable, so whenever it's not relocatable we can still build up
an invalid CONSTRUCTOR, e.g. if in the first testcase we add an NSDMI
such as 'e *p = this;' to struct e, then the ICE still occurs even with
this patch.

A side benefit of the approach taken by this patch is that constexpr
evaluation of a simple VEC_INIT_EXPR for a high-dimensional array no
longer scales exponentially with the number of dimensions.  This is
because after the RANGE_EXPR optimization, the CONSTRUCTOR for each
array dimension now consists of a single constructor_elt (with index
0...max-1) instead of two constructor_elts (with indexes 0 and 1...max-1
respectively).  This is verified by the second testcase below.

Bootstrapped and regtested on x86_64-pc-linux-gnu.  Does this look OK
for trunk and perhaps for backports?

gcc/cp/ChangeLog:

PR c++/96282
* constexpr.c (cxx_eval_vec_init_1): Move the i == 0 test to the
if statement that guards the RANGE_EXPR optimization. Consider the
RANGE_EXPR optimization before we append the first element.
Truncate ctx->ctor when performing the RANGE_EXPR optimization.
Make the built RANGE_EXPR start at index 0 instead of 1.  Don't
call unshare_constructor.

gcc/testsuite/ChangeLog:

PR c++/96282
* g++.dg/cpp0x/constexpr-array26.C: New test.
* g++.dg/cpp0x/constexpr-array27.C: New test.
---
 gcc/cp/constexpr.c| 36 ++-
 .../g++.dg/cpp0x/constexpr-array26.C  | 13 +++
 .../g++.dg/cpp0x/constexpr-array27.C  | 18 ++
 3 files changed, 51 insertions(+), 16 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/constexpr-array26.C
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/constexpr-array27.C

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index b1c1d249c6e..3808a0713ba 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -4189,7 +4189,7 @@ cxx_eval_vec_init_1 (const constexpr_ctx *ctx, tree 
atype, tree init,
  if (value_init || init == NULL_TREE)
{
  eltinit = NULL_TREE;
- reuse = i == 0;
+ reuse = true;
}
  else
eltinit = cp_build_array_ref (input_location, init, idx, complain);
@@ -4206,7 +4206,7 @@ cxx_eval_vec_init_1 (const constexpr_ctx *ctx, tree 
atype, tree init,
return ctx->ctor;
  eltinit = cxx_eval_constant_expression (_ctx, init, lval,
  non_constant_p, overflow_p);
- reuse = i == 0;
+ reuse = true;
}
   else
{
@@ -4222,33 +4222,37 @@ cxx_eval_vec_init_1 (const constexpr_ctx *ctx, tree 
atype, tree init,
}
   if (*non_constant_p && !ctx->quiet)
break;
-  if (new_ctx.ctor != ctx->ctor)
-   {
- /* We appended this element above; update the value.  */
- gcc_assert ((*p)->last().index == idx);
- (*p)->last().value = eltinit;
-   }
-  else
-   CONSTRUCTOR_APPEND_ELT (*p, idx, eltinit);
+
   /* Reuse the result of cxx_eval_constant_expression call
 from the first iteration to all others if it is a constant
 initializer that doesn't require relocations.  */
-  if (reuse
- && max > 1
+  if (i == 0
+ && reuse
  && (eltinit == NULL_TREE
  || (initializer_constant_valid_p (eltinit, TREE_TYPE (eltinit))
  == null_pointer_node)))
{
  if (new_ctx.ctor != ctx->ctor)
eltinit = new_ctx.ctor;
- tree range = build2 (RANGE_EXPR, size_type_node,
-  build_int_cst (size_type_node, 1),
-  build_int_cst (size_type_node, max - 1));
- CONSTRUCTOR_APPEND_ELT (*p, range, unshare_constructor (eltinit));
+ vec_safe_truncate (*p, 0);
+ if (max > 1)
+   idx = build2 (RANGE_EXPR, size_type_node,
+ build_int_cst (size_type_node, 0),
+ build_int_cst 

Re: [committed] libstdc++: Add std::from_chars for floating-point types

[Jonathan Wakely via Gcc-patches]

On 03/08/20 13:47 +0200, Florian Weimer wrote:

* Jonathan Wakely:


What seems to be missing is a function that takes an explicit buffer
length.  A static reference to the C locale object would be helpful as
well, I assume.


How expensive is it to do newlocale("C", nullptr), uselocale, and
freelocale?


freelocale does nothing in this situation.  newlocale has a bunch of
conditional branches to detect this situation.  uselocale has fewer
branches, but has more memory accesses.

At least there's no locking involved.  (But I believe uselocale is
thread-unsafe regarding setlocale in the glibc implementation or
something like that.)


Maybe this is sufficiently clean that we can export this for libstdc++'s
use?  Without repeating the libio mess?


I think we could beat strtod's performance with a handwritten
implementation, so I don't know if it's worth adding glibc extensions
if we would stop using them eventually anyway.


I was reminded of this query:

 Robustly parse string to unsigned integer (strtoul?)/docs
 

It suggests to me that we need better interfaces.


Yes, the ISO C interfaces for this are poor.

Their error reporting is tricky. You have to check a combination of
the return value, the endptr argument, and errno.
https://movementarian.org/blog/posts/2009-03-14-its-not-just-atol-nicholas/

They are too general. strtod is a single function that parses three
different number formats, with no way to restrict it only one of those
formats.

They require null-terminated strings, making them unsuitable for
certain uses e.g. a byte sequence containing several Pascal-style
length-prefixed strings like "\x05123.4\x351".

They're locale-dependent, which is not useful for machine-readable I/O
where the format of numbers must not be localized e.g. JSON.

And strtoul accepts negative numbers (srsly?!)

C++ has decided to ignore these C functions and has defined better
ones. The fact that libstdc++ currently uses strtod internally is a
temporary kluge.

Replicating the C++ API in glibc might be useful for C devs, but to be
useful for libstdc++ we'd need to copy the code into libstdc++ itself
so we could use it for targets using musl, newlib, BSD, mingw etc.


I also noticed some strings give an underflow error with glibc's
strtod, but are valid for the Microsoft implementation. For example,
this one:
https://github.com/microsoft/STL/blob/master/tests/std/tests/P0067R5_charconv/double_from_chars_test_cases.hpp#L265

Without the final '1' digit glibc returns DBL_MIN, but with the final
'1' digit (so a number larger than DBL_MIN) it underflows. Is that
expected?


I don't know.  I think you should bring this up on libc-alpha.


Joseph answered this part, clarifying that glibc is correct to report
underflow.

Re: Ellipsis in varadic macro definitions

[Jonathan Wakely via Gcc-patches]

On Mon, 3 Aug 2020 at 11:28, Florian Weimer wrote:
>
> * Jonathan Wakely via Gcc:
>
> > On Sun, 2 Aug 2020 at 15:49, Philip R Brenan via Gcc  
> > wrote:
> >>
> >> Hi *GCC*:
> >>
> >> On page:
> >>
> >> https://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html#Variadic-Macros
> >>
> >> you say:
> >>
> >> #define eprintf(args…) fprintf (stderr, args)
> >>
> >> but do you in fact mean:
> >>
> >> #define eprintf(args...) fprintf (stderr, args)
> >>
> >> The first variant produces:
> >>
> >> error: expected ',' or ')', found "…"
> >>
> >>  the second variant works well using GCC10.2 on Kubuntu 18.04.
> >
> > Yes, the texinfo source uses @dots which gets turned into  in
> > the HTML, which isn't necessarily displayed as three separate dots in
> > the browser. I don't know why @dots is used rather than ...
>
> It was introduced with:
>
> commit 1c5dd43ff7c78bbdba5e89a6cb16a3e50e1abff9
> Author: Zack Weinberg 
> Date:   Fri Jun 15 17:57:48 2001 +
>
> cpp.texi: Formatting corrections.
>
> * doc/cpp.texi: Formatting corrections.
> Correct buggy example of use of __GNUC__ etc.
> Clarify $ in identifiers.
> * doc/cpp.1: Regenerate.
>
> From-SVN: r43404
>
> Some of these changes were clearly correct, but the ... C token should
> have not been changed.  Looks like a simple oversight to me.

Thanks for the archaeology, Florian.

Here's a patch to replace those inappropriate @dots macros with the
literal ... token.

Tested by building the docs and inspecting the .info and .html output.

OK for trunk?
commit 81034f739112019f29c62a704d0920e9894add6f
Author: Jonathan Wakely 
Date:   Mon Aug 3 12:47:58 2020

cpp: Do not use @dots for ... tokens in code examples

This prevents a ... token in code examples from being turned into a
single HORIZONTAL ELLIPSIS glyph (e.g. via the HTML  entity).

gcc/ChangeLog:

* doc/cpp.texi (Variadic Macros): Use the exact ... token in
code examples.

diff --git a/gcc/doc/cpp.texi b/gcc/doc/cpp.texi
index 8c3dfcc708a..33f876ab706 100644
--- a/gcc/doc/cpp.texi
+++ b/gcc/doc/cpp.texi
@@ -1631,7 +1631,7 @@ a function can.  The syntax for defining the macro is 
similar to that of
 a function.  Here is an example:
 
 @smallexample
-#define eprintf(@dots{}) fprintf (stderr, __VA_ARGS__)
+#define eprintf(...) fprintf (stderr, __VA_ARGS__)
 @end smallexample
 
 This kind of macro is called @dfn{variadic}.  When the macro is invoked,
@@ -1655,11 +1655,11 @@ below for an important special case for @samp{##}.)
 If your macro is complicated, you may want a more descriptive name for
 the variable argument than @code{@w{__VA_ARGS__}}.  CPP permits
 this, as an extension.  You may write an argument name immediately
-before the @samp{@dots{}}; that name is used for the variable argument.
+before the @samp{...}; that name is used for the variable argument.
 The @code{eprintf} macro above could be written
 
 @smallexample
-#define eprintf(args@dots{}) fprintf (stderr, args)
+#define eprintf(args...) fprintf (stderr, args)
 @end smallexample
 
 @noindent
@@ -1670,7 +1670,7 @@ You can have named arguments as well as variable 
arguments in a variadic
 macro.  We could define @code{eprintf} like this, instead:
 
 @smallexample
-#define eprintf(format, @dots{}) fprintf (stderr, format, __VA_ARGS__)
+#define eprintf(format, ...) fprintf (stderr, format, __VA_ARGS__)
 @end smallexample
 
 @noindent
@@ -1709,7 +1709,7 @@ invocation expands to its argument; but if the variable 
argument does
 not have any tokens, the @code{@w{__VA_OPT__}} expands to nothing:
 
 @smallexample
-#define eprintf(format, @dots{}) \
+#define eprintf(format, ...) \
   fprintf (stderr, format __VA_OPT__(,) __VA_ARGS__)
 @end smallexample
 
@@ -1722,7 +1722,7 @@ the introduction of @code{@w{__VA_OPT__}}, this extension 
remains
 supported in GNU CPP, for backward compatibility.  If you write
 
 @smallexample
-#define eprintf(format, @dots{}) fprintf (stderr, format, ##__VA_ARGS__)
+#define eprintf(format, ...) fprintf (stderr, format, ##__VA_ARGS__)
 @end smallexample
 
 @noindent
@@ -1758,7 +1758,7 @@ replacement list of a variadic macro.
 Variadic macros became a standard part of the C language with C99.  
 GNU CPP previously supported them
 with a named variable argument
-(@samp{args@dots{}}, not @samp{@dots{}} and @code{@w{__VA_ARGS__}}), which
+(@samp{args...}, not @samp{...} and @code{@w{__VA_ARGS__}}), which
 is still supported for backward compatibility.
 
 @node Predefined Macros

Re: [committed] libstdc++: Add std::from_chars for floating-point types

[Florian Weimer via Gcc-patches]

* Jonathan Wakely:

>>What seems to be missing is a function that takes an explicit buffer
>>length.  A static reference to the C locale object would be helpful as
>>well, I assume.
>
> How expensive is it to do newlocale("C", nullptr), uselocale, and
> freelocale?

freelocale does nothing in this situation.  newlocale has a bunch of
conditional branches to detect this situation.  uselocale has fewer
branches, but has more memory accesses.

At least there's no locking involved.  (But I believe uselocale is
thread-unsafe regarding setlocale in the glibc implementation or
something like that.)

>>Maybe this is sufficiently clean that we can export this for libstdc++'s
>>use?  Without repeating the libio mess?
>
> I think we could beat strtod's performance with a handwritten
> implementation, so I don't know if it's worth adding glibc extensions
> if we would stop using them eventually anyway.

I was reminded of this query:

  Robustly parse string to unsigned integer (strtoul?)/docs
  

It suggests to me that we need better interfaces.

> I also noticed some strings give an underflow error with glibc's
> strtod, but are valid for the Microsoft implementation. For example,
> this one:
> https://github.com/microsoft/STL/blob/master/tests/std/tests/P0067R5_charconv/double_from_chars_test_cases.hpp#L265
>
> Without the final '1' digit glibc returns DBL_MIN, but with the final
> '1' digit (so a number larger than DBL_MIN) it underflows. Is that
> expected?

I don't know.  I think you should bring this up on libc-alpha.

Thanks,
Florian

[committed] tree-optimization: Fix typos in comments

[Jonathan Wakely via Gcc-patches]

The only two changes which aren't obvious are s/dirified/specified/ and
s/edirially/especially/ which appear to be caused by a s/spec/dir/ edit
that went too far.

gcc/ChangeLog:

* gimple-ssa-sprintf.c: Fix typos in comments.

Committed as obvious.

commit d2ae6d5c053315c94143103eeae1d3cba005ad9d
Author: Jonathan Wakely 
Date:   Mon Aug 3 10:38:44 2020

tree-optimization: Fix typos in comments

The only two changes which aren't obvious are s/dirified/specified/ and
s/edirially/especially/ which appear to be caused by a s/spec/dir/ edit
that went too far.

gcc/ChangeLog:

* gimple-ssa-sprintf.c: Fix typos in comments.

diff --git a/gcc/gimple-ssa-sprintf.c b/gcc/gimple-ssa-sprintf.c
index 011c3e21e63..3d77459d811 100644
--- a/gcc/gimple-ssa-sprintf.c
+++ b/gcc/gimple-ssa-sprintf.c
@@ -29,7 +29,7 @@ along with GCC; see the file COPYING3.  If not see
For all functions (bounded or not) the pass uses the size of the
destination object.  That means that it will diagnose calls to
snprintf not on the basis of the size specified by the function's
-   second argument but rathger on the basis of the size the first
+   second argument but rather on the basis of the size the first
argument points to (if possible).  For bound-checking built-ins
like __builtin___snprintf_chk the pass uses the size typically
determined by __builtin_object_size and passed to the built-in
@@ -39,7 +39,7 @@ along with GCC; see the file COPYING3.  If not see
including character, integer, floating point, pointer, and strings,
with the standard C flags, widths, and precisions.  For integers
and strings it computes the length of output itself.  For floating
-   point it uses MPFR to fornmat known constants with up and down
+   point it uses MPFR to format known constants with up and down
rounding and uses the resulting range of output lengths.  For
strings it uses the length of string literals and the sizes of
character arrays that a character pointer may point to as a bound
@@ -123,7 +123,7 @@ struct result_range
  that result in a range of bytes [MIN, MAX], LIKELY is somewhere
  in that range.  */
   unsigned HOST_WIDE_INT likely;
-  /* In rare cases (e.g., for nultibyte characters) UNLIKELY gives
+  /* In rare cases (e.g., for multibyte characters) UNLIKELY gives
  the worst cases maximum result of a directive.  In most cases
  UNLIKELY == MAX.  UNLIKELY is used to control the return value
  optimization but not in diagnostics.  */
@@ -599,7 +599,7 @@ struct directive
  returns the formatting result.  */
   fmtresult (*fmtfunc) (const directive &, tree, const vr_values *);
 
-  /* Return True when a the format flag CHR has been used.  */
+  /* Return True when the format flag CHR has been used.  */
   bool get_flag (char chr) const
   {
 unsigned char c = chr & 0xff;
@@ -1595,7 +1595,7 @@ format_floating_max (tree type, char spec, HOST_WIDE_INT 
prec)
   if (MODE_COMPOSITE_P (mode))
 mode = DFmode;
 
-  /* Get the real type format desription for the target.  */
+  /* Get the real type format description for the target.  */
   const real_format *rfmt = REAL_MODE_FORMAT (mode);
   REAL_VALUE_TYPE rv;
 
@@ -1891,7 +1891,7 @@ format_floating (const directive , tree arg, const 
vr_values *)
   /* The minimum and maximum number of bytes produced by the directive.  */
   fmtresult res;
 
-  /* Get the real type format desription for the target.  */
+  /* Get the real type format description for the target.  */
   const REAL_VALUE_TYPE *rvp = TREE_REAL_CST_PTR (arg);
   const real_format *rfmt = REAL_MODE_FORMAT (TYPE_MODE (TREE_TYPE (arg)));
 
@@ -1948,8 +1948,8 @@ format_floating (const directive , tree arg, const 
vr_values *)
   {
/* Convert the GCC real value representation with the precision
   of the real type to the mpfr_t format rounding down in the
-  first iteration that computes the minimm and up in the second
-  that computes the maximum.  This order is arbibtrary because
+  first iteration that computes the minimum and up in the second
+  that computes the maximum.  This order is arbitrary because
   rounding in either direction can result in longer output.  */
mpfr_t mpfrval;
mpfr_init2 (mpfrval, rfmt->p);
@@ -1982,7 +1982,7 @@ format_floating (const directive , tree arg, const 
vr_values *)
 
   /* For the same floating point constant, unless width or precision
  is unknown, use the longer output as the likely maximum since
- with round to nearest either is equally likely.  Otheriwse, when
+ with round to nearest either is equally likely.  Otherwise, when
  precision is unknown, use the greater of the minimum and 3 as
  the likely output (for "0.0" since zero precision is unlikely).  */
   if (res.knownrange)
@@ -2075,7 +2075,7 @@ get_string_length (tree str, unsigned eltsize, const 
vr_values *vr)
   /* Set 

[PATCH PR96366][AARCH64] Add support for unpacked vector sub

[bule]

Hi, 

The test case bb-slp-20.c in the gcc testsuit will cause an ICE in the expand 
pass due to the lack of a pattern for subtraction of the VNx2SI mode. I think 
the problem has been fully discussed on PR 96366.

The attached file is the patch to solve this problem. Bootstrapped and tested 
on aarch64-linux-gnu. Ok for trunk?

Thanks,
Bruce




0001-PATCH-PR96366-AARCH64-Add-support-for-unpacked-sub.patch
Description: 0001-PATCH-PR96366-AARCH64-Add-support-for-unpacked-sub.patch

Re: [PATCH] c: Fix bogus vector initialisation error [PR96377]

[Jakub Jelinek via Gcc-patches]

On Mon, Aug 03, 2020 at 01:26:34PM +0200, Andreas Schwab wrote:
> On Jul 31 2020, Richard Sandiford wrote:
> 
> > * gcc.dg/pr96377-1.c: New test.
> > * gcc.dg/pr96377-2.c: Likewise.
> 
> Excess errors:
> /daten/gcc/gcc-20200801/gcc/testsuite/gcc.dg/pr96377-2.c:11:1: warning: GCC 
> vector passed by reference: non-standard ABI extension with no compatibility 
> guarantee [-Wpsabi]
> 
> Excess errors:
> /daten/gcc/gcc-20200801/gcc/testsuite/gcc.dg/pr96377-2.c:11:1: warning: GCC 
> vector passed by reference: non-standard ABI extension with no compatibility 
> guarantee [-Wpsabi]

Usually we add -Wno-psabi -w to dg-options for such tests.

Jakub

Re: [testsuite] Test case for PR rtl-optimization/60473

[H.J. Lu via Gcc-patches]

On Mon, Aug 3, 2020 at 2:20 AM Richard Biener via Gcc-patches
 wrote:
>
> On Sun, Aug 2, 2020 at 6:31 PM Roger Sayle  wrote:
> >
> >
> >
> > PR rtl-optimization/60473 was a code quality regression that has
> >
> > been cured by improvements to register allocation.  For the function
> >
> > in the test case, GCC 4.4, 4.5 and 4.6 generated very poor code
> >
> > requiring two mov instructions:
> >
> >
> >
> > foo:rdtsc
> >
> > mov rcx, rax
> >
> > mov rax, rdx
> >
> > sal rax, 32
> >
> > or  rax, rcx
> >
> > ret
> >
> >
> >
> > GCC 4.7 and 4.8 (when the PR was filed) produced better but
> >
> > still poor code with one mov instruction:
> >
> >
> >
> > foo:rtdsc
> >
> > sal rdx, 32
> >
> > or  rdx, rax
> >
> > mov rax, rdx
> >
> > ret
> >
> >
> >
> > Since GCC 4.9 (including current mainline), it generates optimal
> >
> > code with no mov instructions, matching what used to be generated
> >
> > in GCC 4.1.
> >
> >
> >
> > foo:rdtsc
> >
> > sal rdx, 32
> >
> > or  rax, rdx
> >
> > ret
> >
> >
> >
> > This test case, which has been tested on x86_64-pc-linux-gnu,
> >
> > simply checks that we don't regress again in future.
> >
> > Ok for mainline?
>
> I think you need to restrict this to lp64, at least it fails for me with -m32.
> It also passes with -mx32 but not sure how the perfect target selector
> would look like.

/* { dg-do compile { target { ! ia32 } } } */

> Otherwise looks OK.
>
> Richard.
>

-- 
H.J.

Re: [PATCH] c: Fix bogus vector initialisation error [PR96377]

[Andreas Schwab]

On Jul 31 2020, Richard Sandiford wrote:

>   * gcc.dg/pr96377-1.c: New test.
>   * gcc.dg/pr96377-2.c: Likewise.

Excess errors:
/daten/gcc/gcc-20200801/gcc/testsuite/gcc.dg/pr96377-2.c:11:1: warning: GCC 
vector passed by reference: non-standard ABI extension with no compatibility 
guarantee [-Wpsabi]

Excess errors:
/daten/gcc/gcc-20200801/gcc/testsuite/gcc.dg/pr96377-2.c:11:1: warning: GCC 
vector passed by reference: non-standard ABI extension with no compatibility 
guarantee [-Wpsabi]

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: [PATCH 2/2] rs6000: Define define_insn_and_split to split unspec sldi+or to rldimi

[Andreas Schwab]

On Jul 09 2020, Xiong Hu Luo via Gcc-patches wrote:

> diff --git a/gcc/testsuite/gcc.target/powerpc/vector_float.c 
> b/gcc/testsuite/gcc.target/powerpc/vector_float.c
> new file mode 100644
> index 000..414824ad264
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/vector_float.c
> @@ -0,0 +1,14 @@
> +/* { dg-do compile  } */
> +/* { dg-options "-O2 -mdejagnu-cpu=power9" } */
> +
> +vector float
> +test (float *a, float *b, float *c, float *d)
> +{
> +  return (vector float){*a, *b, *c, *d};
> +}
> +
> +/* { dg-final { scan-assembler-not {\mlxsspx\M} } } */
> +/* { dg-final { scan-assembler-not {\mlfs\M} } } */
> +/* { dg-final { scan-assembler-times {\mlwz\M} 4 } } */
> +/* { dg-final { scan-assembler-times {\mrldimi\M} 2 } } */
> +/* { dg-final { scan-assembler-times {\mmtvsrdd\M} 1 } } */

This fails with -m32.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: [PATCH] SLP: support entire BB.

[Richard Biener via Gcc-patches]

On Fri, Jul 31, 2020 at 12:30 PM Martin Liška  wrote:
>
> Hey.
>
> Motivation of the patch is to allow vectorization of an entire BB.
> So far we bail out a sub-BB region when we reach a stmt for which
> vect_find_stmt_data_reference returns false. That's replaced with
> recoding of groups of the data references.
>
> We can newly vectorize code like:
>
> void foo();
> void bar (int i, double *a, double *b)
> {
>double tem1 = a[2*i];
>double tem2 = 2*a[2*i+1];
>foo ();
>b[2*i] = 2*tem1;
>b[2*i+1] = tem2;
> }
>
> into:
> [local count: 1073741824]:
>_1 = i_12(D) * 2;
>_2 = (long unsigned int) _1;
>_3 = _2 * 8;
>_4 = a_13(D) + _3;
>vect_tem1_15.5_24 = MEM  [(double *)_4];
>vect__10.6_25 = vect_tem1_15.5_24 * { 2.0e+0, 2.0e+0 };
>foo ();
>_9 = b_18(D) + _3;
>MEM  [(double *)_9] = vect__10.6_25;
>return;
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

OK with some minor changes, see below

> Thoughs?
> Martin
>
> gcc/ChangeLog:
>
> * tree-vect-data-refs.c (dr_group_sort_cmp): Work on
> data_ref_pair.
> (vect_analyze_data_ref_accesses): Work on groups.
> (vect_find_stmt_data_reference): Add group_id argument and fill
> up dataref_groups vector.
> * tree-vect-loop.c (vect_get_datarefs_in_loop): Pass new
> arguments.
> (vect_analyze_loop_2): Likewise.
> * tree-vect-slp.c (vect_slp_analyze_bb_1): Pass argument.
> (vect_slp_bb_region): Likewise.
> (vect_slp_region): Likewise.
> (vect_slp_bb):Work on the entire BB.
> * tree-vectorizer.h (vect_analyze_data_ref_accesses): Add new
> argument.
> (vect_find_stmt_data_reference): Likewise.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/vect/bb-slp-38.c: Adjust pattern as now we only process
> a single vectorization and now 2 partial.
> * gcc.dg/vect/bb-slp-45.c: New test.
> ---
>   gcc/testsuite/gcc.dg/vect/bb-slp-38.c |  2 +-
>   gcc/testsuite/gcc.dg/vect/bb-slp-45.c | 36 
>   gcc/tree-vect-data-refs.c | 63 +---
>   gcc/tree-vect-loop.c  |  5 +-
>   gcc/tree-vect-slp.c   | 82 ++-
>   gcc/tree-vectorizer.h |  5 +-
>   6 files changed, 118 insertions(+), 75 deletions(-)
>   create mode 100644 gcc/testsuite/gcc.dg/vect/bb-slp-45.c
>
> diff --git a/gcc/testsuite/gcc.dg/vect/bb-slp-38.c 
> b/gcc/testsuite/gcc.dg/vect/bb-slp-38.c
> index 59aec54fffd..9c57ea3c2c1 100644
> --- a/gcc/testsuite/gcc.dg/vect/bb-slp-38.c
> +++ b/gcc/testsuite/gcc.dg/vect/bb-slp-38.c
> @@ -41,4 +41,4 @@ int main()
>   }
>
>   /* { dg-final { scan-tree-dump "basic block vectorized" "slp2" { target 
> vect_perm } } } */
> -/* { dg-final { scan-tree-dump-times "basic block part vectorized" 2 "slp2" 
> { target vect_perm } } } */
> +/* { dg-final { scan-tree-dump "basic block part vectorized" "slp2" { target 
> vect_perm } } } */
> diff --git a/gcc/testsuite/gcc.dg/vect/bb-slp-45.c 
> b/gcc/testsuite/gcc.dg/vect/bb-slp-45.c
> new file mode 100644
> index 000..4107a34cb93
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/vect/bb-slp-45.c
> @@ -0,0 +1,36 @@
> +/* { dg-require-effective-target vect_double } */
> +
> +#include "tree-vect.h"
> +
> +extern void abort (void);
> +
> +double a[8], b[8];
> +int x;
> +
> +void __attribute__((noinline,noclone))
> +bar (void)
> +{
> +  x = 1;
> +}
> +
> +void __attribute__((noinline,noclone))
> +foo(int i)
> +{
> +  double tem1 = a[2*i];
> +  double tem2 = 2*a[2*i+1];
> +  bar ();
> +  b[2*i] = 2*tem1;
> +  b[2*i+1] = tem2;
> +}
> +
> +int main()
> +{
> +  int i;
> +  check_vect ();
> +  for (i = 0; i < 8; ++i)
> +b[i] = i;
> +  foo (2);
> +  return 0;
> +}
> +
> +/* { dg-final { scan-tree-dump "basic block vectorized" "slp2" } } */
> diff --git a/gcc/tree-vect-data-refs.c b/gcc/tree-vect-data-refs.c
> index a78ae61d1b0..36e10ff3619 100644
> --- a/gcc/tree-vect-data-refs.c
> +++ b/gcc/tree-vect-data-refs.c
> @@ -2757,14 +2757,18 @@ vect_analyze_data_ref_access (vec_info *vinfo, 
> dr_vec_info *dr_info)
> return vect_analyze_group_access (vinfo, dr_info);
>   }
>
> +typedef std::pair data_ref_pair;
> +
>   /* Compare two data-references DRA and DRB to group them into chunks
>  suitable for grouping.  */
>
>   static int
>   dr_group_sort_cmp (const void *dra_, const void *drb_)
>   {
> -  data_reference_p dra = *(data_reference_p *)const_cast(dra_);
> -  data_reference_p drb = *(data_reference_p *)const_cast(drb_);
> +  data_ref_pair dra_pair = *(data_ref_pair *)const_cast(dra_);
> +  data_ref_pair drb_pair = *(data_ref_pair *)const_cast(drb_);
> +  data_reference_p dra = dra_pair.first;
> +  data_reference_p drb = drb_pair.first;
> int cmp;
>
> /* Stabilize sort.  */
> @@ -2772,10 +2776,13 @@ dr_group_sort_cmp (const void *dra_, const void *drb_)
>   return 0;
>
> /* DRs in different loops never belong 

Re: [PATCH] x86_64: Integer min/max improvements.

[Uros Bizjak via Gcc-patches]

On Thu, Jul 30, 2020 at 1:23 PM Roger Sayle  wrote:
>
>
> This patch tweaks the way that min and max are expanded, so that the
> semantics of these operations are visible to the early RTL optimization
> passes, until split into explicit comparison and conditional move
> instructions. The good news is that i386.md already contains all of
> the required logic (many thanks to Richard Biener and Uros Bizjak),
> but this is currently only to enable scalar-to-vector (STV) synthesis
> of min/max instructions.  This change enables this functionality for
> all TARGET_CMOVE architectures for SImode, HImode and DImode.
>
> My first attempt to support "min(reg,reg)" as an instruction revealed
> why this functionality isn't already enabled: In PR rtl-optimization 91154
> we end up generating a cmp instead of a test in gcc.target/i386/minmax-3.c
> which has poor performance on AMD Opteron.  My solution to this is to
> actually support "min(reg,general_operand)" allowing us to inspect
> any immediate constant at the point this operation is split.  This
> allows us to use "test" instructions for min/max against 0, 1 and -1.
> As an added benefit it allows us to CSE large immediate constants,
> reducing code size.
>
> Previously, "int foo(int x) { return max(x,12345); }" would generate:
>
> foo:cmpl$12345, %edi
> movl$12345, %eax
> cmovge  %edi, %eax
> ret
>
> with this patch we instead generate:
>
> foo:movl$12345, %eax
> cmpl%eax, %edi
> cmovge  %edi, %eax
> ret
>
>
> I've also included a peephole2 to avoid the "movl $0,%eax" instructions
> being produced by the register allocator.  Materializing constants as
> late as possible reduces register pressure, but for const0_rtx on x86,
> it's preferable to use "xor" by moving this set from between a flags
> setting operation and its use.  This should also help instruction macro
> fusion on some microarchitectures, where test/cmp and the following
> instruction can sometimes be combined.
>
> Previously, "int foo(int x) { return max(x,0); }" would generate:
>
> foo:testl   %edi, %edi
> movl$0, %eax
> cmovns  %edi, %eax
> ret
>
> with this patch we instead generate:
> foo:xorl%eax, %eax
> testl   %edi, %edi
> cmovns  %edi, %eax
> ret
>
> The benefits of having min/max explicit at the RTL level can be seen
> from compiling the following example with "-O2 -fno-tree-reassoc".
>
>
> #define max(a,b) (((a) > (b))? (a) : (b))
>
> int foo(int x)
> {
>   int y = max(x,5);
>   return max(y,10);
> }
>
> where GCC currently produces:
>
> foo:cmpl$5, %edi
> movl$5, %eax
> movl$10, %edx
> cmovge  %edi, %eax
> cmpl$10, %eax
> cmovl   %edx, %eax
> ret
>
> and with this patch it instead now produces:
>
> foo:movl$10, %eax
> cmpl%eax, %edi
> cmovge  %edi, %eax
> ret
>
>
> The original motivation was from looking at a performance critical
> function in a quantum mechanics code, that performed MIN_EXPR and
> MAX_EXPR of the same arguments (effectively a two-element sort),
> where GCC was performing the comparison twice.  I'd hoped that it
> might be possible to fuse these together, perhaps in combine, but
> this patch is an intermediate step towards that goal.
>
> This patch has been tested on x86_64-pc-linux-gnu with a make
> bootstrap followed by make -k check with no new regressions.
> Ok for mainline?
>
>
> 2020-07-30  Roger Sayle  
>
> * config/i386/i386.md (MAXMIN_IMODE): No longer needed.
> (3):  Support SWI248 and general_operand for
> second operand, when TARGET_CMOVE.
> (3_1 splitter): Optimize comparisons against
> 0, 1 and -1 to use "test" instead of "cmp".
> (*di3_doubleword): Likewise, allow general_operand
> and enable on TARGET_CMOVE.
> (peephole2): Convert clearing a register after a flag setting
> instruction into an xor followed by the original flag setter.
>
>
> Many thanks in advance.  Almost all of the credit goes to Uros and
> Richard for already implementing this feature, I've just copied the
> transformations from optab expansion, that allow it to be enabled
> without penalty (this late in the compilation).

LGTM, modulo the below part:

+;; Avoid clearing a register between a flags setting comparison and its use,
+;; i.e. prefer "xorl %eax,%eax; test/cmp" over "test/cmp; movl $0, %eax".
+(define_peephole2
+  [(set (reg FLAGS_REG) (match_operand 0))
+   (set (match_operand:SWI48 1 "register_operand") (const_int 0))]
+  "peep2_regno_dead_p (0, FLAGS_REG)
+   && !reg_overlap_mentioned_p (operands[1], operands[0])"
+  [(parallel [(set (match_dup 1) (const_int 0))
+  (clobber (reg:CC FLAGS_REG))])
+   (set (match_dup 2) (match_dup 0))]
+{
+  operands[2] = gen_rtx_REG (GET_MODE (operands[0]), FLAGS_REG);
+})

Please use ix86_expand_clear (operands[1]); in the 

[committed] d: Fix ICE using non-local variable: internal compiler error: Segmentation fault

[Iain Buclaw via Gcc-patches]

Hi,

This patch moves no frame access error to own function, adding use of it
for both when get_framedecl() cannot find a path to the outer function
frame, and guarding get_decl_tree() from recursively calling itself.

Bootstrapped and regression tested on x86_64-linux-gnu with multilib
configurations -m32 and -mx32.  Committed to mainline.

Regards
Iain

---
gcc/d/ChangeLog:

PR d/96254
* d-codegen.cc (error_no_frame_access): New.
(get_frame_for_symbol): Use fdparent name in error message.
(get_framedecl): Replace call to assert with error.
* d-tree.h (error_no_frame_access): Declare.
* decl.cc (get_decl_tree): Detect recursion and error.

gcc/testsuite/ChangeLog:

PR d/96254
* gdc.dg/pr96254a.d: New test.
* gdc.dg/pr96254b.d: New test.
---
 gcc/d/d-codegen.cc  | 53 +++--
 gcc/d/d-tree.h  |  1 +
 gcc/d/decl.cc   |  5 
 gcc/testsuite/gdc.dg/pr96254a.d | 28 +
 gcc/testsuite/gdc.dg/pr96254b.d | 24 +++
 5 files changed, 89 insertions(+), 22 deletions(-)
 create mode 100644 gcc/testsuite/gdc.dg/pr96254a.d
 create mode 100644 gcc/testsuite/gdc.dg/pr96254b.d

diff --git a/gcc/d/d-codegen.cc b/gcc/d/d-codegen.cc
index 2dce09d7187..296d62a91a4 100644
--- a/gcc/d/d-codegen.cc
+++ b/gcc/d/d-codegen.cc
@@ -2127,6 +2127,17 @@ build_vthis_function (tree basetype, tree type)
   return fntype;
 }
 
+/* Raise an error at that the context pointer of the function or object SYM is
+   not accessible from the current scope.  */
+
+tree
+error_no_frame_access (Dsymbol *sym)
+{
+  error_at (input_location, "cannot get frame pointer to %qs",
+   sym->toPrettyChars ());
+  return null_pointer_node;
+}
+
 /* If SYM is a nested function, return the static chain to be
used when calling that function from the current function.
 
@@ -2191,7 +2202,7 @@ get_frame_for_symbol (Dsymbol *sym)
{
  error_at (make_location_t (sym->loc),
"%qs is a nested function and cannot be accessed from %qs",
-   fd->toPrettyChars (), thisfd->toPrettyChars ());
+   fdparent->toPrettyChars (), thisfd->toPrettyChars ());
  return null_pointer_node;
}
 
@@ -2202,39 +2213,35 @@ get_frame_for_symbol (Dsymbol *sym)
   while (fd != dsym)
{
  /* Check if enclosing function is a function.  */
- FuncDeclaration *fd = dsym->isFuncDeclaration ();
+ FuncDeclaration *fdp = dsym->isFuncDeclaration ();
+ Dsymbol *parent = dsym->toParent2 ();
 
- if (fd != NULL)
+ if (fdp != NULL)
{
- if (fdparent == fd->toParent2 ())
+ if (fdparent == parent)
break;
 
- gcc_assert (fd->isNested () || fd->vthis);
- dsym = dsym->toParent2 ();
+ gcc_assert (fdp->isNested () || fdp->vthis);
+ dsym = parent;
  continue;
}
 
  /* Check if enclosed by an aggregate.  That means the current
 function must be a member function of that aggregate.  */
- AggregateDeclaration *ad = dsym->isAggregateDeclaration ();
+ AggregateDeclaration *adp = dsym->isAggregateDeclaration ();
 
- if (ad == NULL)
-   goto Lnoframe;
- if (ad->isClassDeclaration () && fdparent == ad->toParent2 ())
-   break;
- if (ad->isStructDeclaration () && fdparent == ad->toParent2 ())
-   break;
-
- if (!ad->isNested () || !ad->vthis)
+ if (adp != NULL)
{
-   Lnoframe:
- error_at (make_location_t (thisfd->loc),
-   "cannot get frame pointer to %qs",
-   sym->toPrettyChars ());
- return null_pointer_node;
+ if ((adp->isClassDeclaration () || adp->isStructDeclaration ())
+ && fdparent == parent)
+   break;
}
 
- dsym = dsym->toParent2 ();
+ /* No frame to outer function found.  */
+ if (!adp || !adp->isNested () || !adp->vthis)
+   return error_no_frame_access (sym);
+
+ dsym = parent;
}
 }
 
@@ -2724,8 +2731,10 @@ get_framedecl (FuncDeclaration *inner, FuncDeclaration 
*outer)
break;
 }
 
+  if (fd != outer)
+return error_no_frame_access (outer);
+
   /* Go get our frame record.  */
-  gcc_assert (fd == outer);
   tree frame_type = FRAMEINFO_TYPE (get_frameinfo (outer));
 
   if (frame_type != NULL_TREE)
diff --git a/gcc/d/d-tree.h b/gcc/d/d-tree.h
index df317d557eb..2be80dd1867 100644
--- a/gcc/d/d-tree.h
+++ b/gcc/d/d-tree.h
@@ -575,6 +575,7 @@ extern tree d_build_call (TypeFunction *, tree, tree, 
Expressions *);
 extern tree d_assert_call (const Loc &, libcall_fn, tree = NULL_TREE);
 extern tree build_float_modulus (tree, tree, tree);
 extern tree build_vthis_function (tree, tree);

Re: [testsuite] Test case for PR rtl-optimization/60473

[Uros Bizjak via Gcc-patches]

>> Since GCC 4.9 (including current mainline), it generates optimal
>>
>> code with no mov instructions, matching what used to be generated
>>
>> in GCC 4.1.
>>
>>
>>
>> foo:rdtsc
>>
>> sal rdx, 32
>>
>> or  rax, rdx
>>
>> ret
>>
>>
>>
>> This test case, which has been tested on x86_64-pc-linux-gnu,
>>
>> simply checks that we don't regress again in future.
>>
>> Ok for mainline?
>
> I think you need to restrict this to lp64, at least it fails for me with -m32.
> It also passes with -mx32 but not sure how the perfect target selector
> would look like.

/* { dg-do compile { target { ! ia32 } } } */

should do the trick.

> Otherwise looks OK.

+/* { dg-final { scan-assembler-not "mov" } } */

This test is maybe too fragile, some targets generate frame setup
instructions, e.g.:

movl%esp, %ebp

that will trigger the FAIL. If there are false positives, we can add a
target selector for *-*-linux to scan-assembler-not.

Uros.

Re: [testsuite] Test case for PR rtl-optimization/60473

[Richard Biener via Gcc-patches]

On Sun, Aug 2, 2020 at 6:31 PM Roger Sayle  wrote:
>
>
>
> PR rtl-optimization/60473 was a code quality regression that has
>
> been cured by improvements to register allocation.  For the function
>
> in the test case, GCC 4.4, 4.5 and 4.6 generated very poor code
>
> requiring two mov instructions:
>
>
>
> foo:rdtsc
>
> mov rcx, rax
>
> mov rax, rdx
>
> sal rax, 32
>
> or  rax, rcx
>
> ret
>
>
>
> GCC 4.7 and 4.8 (when the PR was filed) produced better but
>
> still poor code with one mov instruction:
>
>
>
> foo:rtdsc
>
> sal rdx, 32
>
> or  rdx, rax
>
> mov rax, rdx
>
> ret
>
>
>
> Since GCC 4.9 (including current mainline), it generates optimal
>
> code with no mov instructions, matching what used to be generated
>
> in GCC 4.1.
>
>
>
> foo:rdtsc
>
> sal rdx, 32
>
> or  rax, rdx
>
> ret
>
>
>
> This test case, which has been tested on x86_64-pc-linux-gnu,
>
> simply checks that we don't regress again in future.
>
> Ok for mainline?

I think you need to restrict this to lp64, at least it fails for me with -m32.
It also passes with -mx32 but not sure how the perfect target selector
would look like.

Otherwise looks OK.

Richard.

>
>
>
>
> 2020-08-02  Roger Sayle  
>
>
>
> gcc/testsuite/ChangeLog
>
> PR rtl-optimization/60473
>
> * gcc.target/i386/pr60473.c: New test.
>
>
>
> Thanks in advance,
>
> Roger
>
> --
>
> Roger Sayle
>
> NextMove Software
>
> Cambridge, UK
>
>
>

Re: [PATCH] PR rtl-optimization 61494: Preserve x-0.0 with HONOR_SNANS.

[Richard Biener via Gcc-patches]

On Sun, Aug 2, 2020 at 12:02 PM Roger Sayle  wrote:
>
>
> The following patch avoids simplifying x-0.0 to x when -fsignaling-nans is
> specified,
> which resolves PR rtl-optimization 61494.  Indeed, running the test program
> attached
> to that PR now reports no failures.  Alas reducing that validation program
> to a portable
> test for the GCC testsuite is a challenge that I plan to leave to a
> volunteer.  The fix
> itself is a trivial one-liner, so it's curious that the compiler has been
> broken for so long.
> Hopefully folks agree that correctness is more important than testability
> (but both
> are desirable).
>
> The following patch has been tested on x86_64-pc-linux-gnu with a "make
> bootstrap"
> and "make -k check" with no new regressions.
> Ok for mainline?

Heh, and I thought we do no FP math simplifications on RTL ...

OK.

Thanks,
Richard.

> 2020-08-02  Roger Sayle  
>
> gcc/ChangeLog
> PR rtl-optimization/61494
> * simplify-rtx.c (simplify_binary_operation_1) [MINUS]: Don't
> simplify x - 0.0 with -fsignaling-nans.
>
> Thanks in advance,
> Roger
> --
> Roger Sayle
> NextMove Software
> Cambridge, UK
>

Re: [PATCH] genmatch: Avoid unused parameter warnings in generated code.

[Richard Biener via Gcc-patches]

On Sat, Aug 1, 2020 at 8:46 PM Roger Sayle  wrote:
>
>
> This patch silences a number of unused parameter warnings whilst
> compiling both generic-match.c and gimple-match.c.  The problem is
> that multiple (polymorphic) functions are generated for generic_simplify
> and gimple_simplify, each handling tree codes with a specific number
> of children.  Currently, there are no simplifications for tree codes
> with four or five children, leading to functions with "empty" bodies
> and unused function arguments.  This patch detects those cases, and
> generates stub functions (with anonymous arguments) to silence these
> warnings.
>
> Previously, genmatch would generate:
>
> static bool
> gimple_simplify (gimple_match_op *res_op, gimple_seq *seq,
>  tree (*valueize)(tree) ATTRIBUTE_UNUSED,
>  code_helper code, const tree type, tree _p0, tree _p1, tree
> _p2, tree _p3)
> {
>   switch (code.get_rep())
> {
> default:;
> }
>   return false;
> }
>
> which results in:
>  gimple_simplify (gimple_match_op *res_op, gimple_seq *seq,
>  ^
> gimple-match.c:130408:1: warning: unused parameter 'seq'
> [-Wunused-parameter]
> gimple-match.c:130408:1: warning: unused parameter 'type'
> [-Wunused-parameter]
> gimple-match.c:130408:1: warning: unused parameter '_p0'
> [-Wunused-parameter]
> gimple-match.c:130408:1: warning: unused parameter '_p1'
> [-Wunused-parameter]
> gimple-match.c:130408:1: warning: unused parameter '_p2'
> [-Wunused-parameter]
> gimple-match.c:130408:1: warning: unused parameter '_p3'
> [-Wunused-parameter]
> gimple-match.c:130420:1: warning: unused parameter 'res_op'
> [-Wunused-parameter]
>
> With this patch genmatch now generates:
> static bool
> gimple_simplify (gimple_match_op*, gimple_seq*,
>  tree (*)(tree), code_helper,
>  const tree, tree, tree, tree, tree)
> {
>   return false;
> }
>
> which has the same signature but no compilation warnings.
>
> This patch has been tested on x86_64-pc-linux-gnu with a full
> "make bootstrap" and "make -k check" with no new failures.
> Ok for mainline?

OK.

Thanks,
Richard.

>
> 2020-08-01  Roger Sayle  
>
> * gcc/genmatch.c (decision_tree::gen): Emit stub functions for
> tree code operand counts that have no simplifications.
> (main): Correct comment typo.
>
> Thanks in advance,
> Roger
> --
> Roger Sayle
> NextMove Software
> Cambridge, UK
>

Re: Simplify X * C1 == C2 with undefined overflow

[Richard Biener via Gcc-patches]

On Sat, Aug 1, 2020 at 9:29 AM Marc Glisse  wrote:
>
> Hello,
>
> this transformation is quite straightforward, without overflow, 3*X==15 is
> the same as X==5 and 3*X==5 cannot happen. Adding a single_use restriction
> for the first case didn't seem necessary, although of course it can
> slightly increase register pressure in some cases.
>
> Bootstrap+regtest on x86_64-pc-linux-gnu.

OK with using constant_boolean_node (cmp == NE_EXPR, type).

ISTR we had the x * 0 == CST simplification somewhere
but maybe it was x * y == 0 ...  ah, yes:

/* Transform comparisons of the form X * C1 CMP 0 to X CMP 0 in the
   signed arithmetic case.  That form is created by the compiler
   often enough for folding it to be of value.  One example is in
   computing loop trip counts after Operator Strength Reduction.  */
(for cmp (simple_comparison)
 scmp (swapped_simple_comparison)
 (simplify
  (cmp (mult@3 @0 INTEGER_CST@1) integer_zerop@2)

As it is placed after your pattern it will be never matched I think
(but we don't warn because of INTEGER_CST vs. integer_zerop).

But I think your pattern subsumes it besides of the X * 0 == 0
compare - oh, and the other pattern also handles relational compares
(those will still trigger).

Maybe place the patterns next to each other?  Also see whether
moving yours after the above will cease the testcases to be handled
because it's no longer matched - if not this might be the better
order.

Richard.

> 2020-08-03  Marc Glisse  
>
> PR tree-optimization/95433
> * match.pd (X * C1 == C2): New transformation.
>
> * gcc.c-torture/execute/pr23135.c: Add -fwrapv to avoid
> undefined behavior.
> * gcc.dg/tree-ssa/pr95433.c: New file.
>
> --
> Marc Glisse

RE: [PATCH][GCC][aarch64] Generation of adjusted ldp/stp for vector types

[Przemyslaw Wirkus]

Commited cd91a084877dabcc53aec57ab70ca4fc32f3d985

> -Original Message-
> From: Przemyslaw Wirkus
> Sent: 22 July 2020 09:49
> To: Richard Sandiford 
> Cc: gcc-patches@gcc.gnu.org
> Subject: RE: [PATCH][GCC][aarch64] Generation of adjusted ldp/stp for vector
> types
> 
> [snip...]
> 
> > Przemek, if you don't have commit access already, please follow the
> > steps on https://gcc.gnu.org/gitwrite.html (happy to sponsor).
> 
> Done.
> 
> Thank you, Richard, for sponsoring this and all the support!
> 
> Kind regards,
> Przemek

[Patch, committed] libgfortran/caf/single.c: Fix typo.

[Tobias Burnus]

Committed as obvious.

-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter
commit 58cfec3a6e756b534b33787e51c52f5fc63b53ab
Author: Tobias Burnus 
Date:   Mon Aug 3 09:41:24 2020 +0200

libgfortran/caf/single.c: Fix typo.

libgfortran/ChangeLog

* caf/single.c (_gfortran_caf_lock): Fix typo.
---
 libgfortran/caf/single.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/libgfortran/caf/single.c b/libgfortran/caf/single.c
index 7bd022d7ff8..8c1abbf9c23 100644
--- a/libgfortran/caf/single.c
+++ b/libgfortran/caf/single.c
@@ -2961,7 +2961,8 @@ _gfortran_caf_event_query (caf_token_t token, size_t index,
 void
 _gfortran_caf_lock (caf_token_t token, size_t index,
 		int image_index __attribute__ ((unused)),
-		int *aquired_lock, int *stat, char *errmsg, size_t errmsg_len)
+		int *acquired_lock, int *stat, char *errmsg,
+		size_t errmsg_len)
 {
   const char *msg = "Already locked";
   bool *lock = &((bool *) MEMTOK (token))[index];
@@ -2969,16 +2970,16 @@ _gfortran_caf_lock (caf_token_t token, size_t index,
   if (!*lock)
 {
   *lock = true;
-  if (aquired_lock)
-	*aquired_lock = (int) true;
+  if (acquired_lock)
+	*acquired_lock = (int) true;
   if (stat)
 	*stat = 0;
   return;
 }
 
-  if (aquired_lock)
+  if (acquired_lock)
 {
-  *aquired_lock = (int) false;
+  *acquired_lock = (int) false;
   if (stat)
 	*stat = 0;
 return;

Re: [PATCH] Amend match.pd syntax with force-simplified results

[Richard Biener]

On Fri, 31 Jul 2020, Marc Glisse wrote:

> On Fri, 31 Jul 2020, Richard Biener wrote:
> 
> > Or we simply automatically disable those patterns for GENERIC
> > (though that would probably be unexpected).
> 
> Since the definition is not clear, whatever we do will be unexpected at least
> in some cases. Disabling it for GENERIC for now seems ok to me, we can always
> extend it later...

Fair enough.  I'm going to test and install the following which means
! using patterns need to be guarded with #if GIMPLE for now.

Richard.

>From 3237456abe8d384ada9ef6b972ee0bd81caf8112 Mon Sep 17 00:00:00 2001
From: Richard Biener 
Date: Mon, 3 Aug 2020 10:30:49 +0200
Subject: [PATCH] mark match.pd ! not implemented on GENERIC

This makes us error when the ! operator modifier is encountered
when not targeting GIMPLE.

2020-08-03  Richard Biener  

* genmatch.c (parser::gimple): New.
(parser::parser): Initialize gimple flag member.
(parser::parse_expr): Error on ! operator modifier when
not targeting GIMPLE.
(main): Pass down gimple flag to parser ctor.

* doc/match-and-simplify.texi: Amend accordingly.
---
 gcc/doc/match-and-simplify.texi |  3 ++-
 gcc/genmatch.c  | 11 ---
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/gcc/doc/match-and-simplify.texi b/gcc/doc/match-and-simplify.texi
index 41980acbfe9..8752bd2afe1 100644
--- a/gcc/doc/match-and-simplify.texi
+++ b/gcc/doc/match-and-simplify.texi
@@ -374,7 +374,8 @@ for example
 
 which moves the outer @code{plus} operation to the inner arms
 of the @code{vec_cond} expression but only if the actual plus
-operations both simplify.
+operations both simplify.  Note this is currently only supported
+for code generation targeting @code{GIMPLE}.
 
 As intermediate conversions are often optional there is a way to
 avoid the need to repeat patterns both with and without such
diff --git a/gcc/genmatch.c b/gcc/genmatch.c
index 88459d9686e..109dce2d469 100644
--- a/gcc/genmatch.c
+++ b/gcc/genmatch.c
@@ -3946,7 +3946,7 @@ write_header (FILE *f, const char *head)
 class parser
 {
 public:
-  parser (cpp_reader *);
+  parser (cpp_reader *, bool gimple);
 
 private:
   const cpp_token *next ();
@@ -3983,6 +3983,7 @@ private:
   void finish_match_operand (operand *);
 
   cpp_reader *r;
+  bool gimple;
   vec active_ifs;
   vec > active_fors;
   hash_set *oper_lists_set;
@@ -4249,6 +4250,9 @@ parser::parse_expr ()
   && token->type == CPP_NOT
   && !(token->flags & PREV_WHITE))
 {
+  if (!gimple)
+   fatal_at (token, "forcing simplification to a leaf is not supported "
+ "for GENERIC");
   eat_token (CPP_NOT);
   e->force_leaf = true;
 }
@@ -5042,9 +5046,10 @@ parser::finish_match_operand (operand *op)
 
 /* Main entry of the parser.  Repeatedly parse outer control structures.  */
 
-parser::parser (cpp_reader *r_)
+parser::parser (cpp_reader *r_, bool gimple_)
 {
   r = r_;
+  gimple = gimple_;
   active_ifs = vNULL;
   active_fors = vNULL;
   simplifiers = vNULL;
@@ -5151,7 +5156,7 @@ main (int argc, char **argv)
 #include "internal-fn.def"
 
   /* Parse ahead!  */
-  parser p (r);
+  parser p (r, gimple);
 
   if (gimple)
 write_header (stdout, "gimple-match-head.c");
-- 
2.26.2

Re: [PATCH] libgccjit: Add new gcc_jit_context_new_blob entry point

[Andrea Corallo]

David Malcolm  writes:

> On Fri, 2020-07-24 at 18:05 -0400, David Malcolm via Gcc-patches wrote:
>
> [...]
>
>> I haven't thought this through in detail, and I'm not sure exactly
>> how
>> it would work for arbitrary types, but I thought it worth sharing. 
>> (For example I can think of nasty issues if we ever want to support
>> cross-compilation, e.g. where sizeof types or  endianness differs
>> between host and target).
>
> ...which is an argument in favor of retaining the name "blob", perhaps
> as the name of the argument in the header file e.g.:
>
> extern void
> gcc_jit_global_set_initializer (gcc_jit_lvalue *global,
>  const void *blob,
>  size_t num_bytes);
>  
>
> as a subtle hint to the user that they need to be wary about binary
> layouts ("here be dragons").
>
> [...]

Hi Dave & all,

following up this is my take on the implementation of:

gcc_jit_global_set_initializer (gcc_jit_lvalue *global,
const void *blob,
size_t num_bytes);

'global' must be an array but in the seek of generality it now supports
all the various integral types and is not limited to char[].

As you anticipated the implementation I came up is currently not safe
for cross-compilation, not sure is requirement tho.

make check-jit is clean

Feedback very welcome

Thanks!

  Andrea

gcc/jit/ChangeLog

2020-08-01  Andrea Corallo  

* docs/topics/compatibility.rst (LIBGCCJIT_ABI_14): New ABI tag.
* docs/topics/expressions.rst (gcc_jit_global_set_initializer):
Document new entry point in section 'Global variables'.
* jit-playback.c (global_new_decl, global_finalize_lvalue): New
method.
(playback::context::new_global): Make use of global_new_decl,
global_finalize_lvalue.
(load_blob_in_ctor): New template function in use by the
following.
(playback::context::new_global_initialized): New method.
* jit-playback.h (class context): Decl 'new_global_initialized',
'global_new_decl', 'global_finalize_lvalue'.
(lvalue::set_initializer): Add implementation.
* jit-recording.c (recording::memento_of_get_pointer::get_size)
(recording::memento_of_get_type::get_size): Add implementation.
(recording::global::write_initializer_reproducer): New function in
use by 'recording::global::write_reproducer'.
(recording::global::replay_into)
(recording::global::write_to_dump)
(recording::global::write_reproducer): Handle
initialized case.
* jit-recording.h (class type): Decl 'get_size' and
'num_elements'.
* libgccjit++.h (class lvalue): Declare new 'set_initializer'
method.
(class lvalue): Decl 'is_global' and 'set_initializer'.
(class class global) Decl 'write_initializer_reproducer'. Add
'm_initializer', 'm_initializer_num_bytes' fields.  Implement
'set_initializer'.
* libgccjit.c (gcc_jit_global_set_initializer): New function.
* libgccjit.h (gcc_jit_global_set_initializer): New function
declaration.
* libgccjit.map (LIBGCCJIT_ABI_14): New ABI tag.

gcc/testsuite/ChangeLog

2020-08-01  Andrea Corallo  

* jit.dg/all-non-failing-tests.h: Add test-blob.c.
* jit.dg/test-global-set-initializer.c: New testcase.

>From 74bd96fde6d4baed978555279d17898b989c00ad Mon Sep 17 00:00:00 2001
From: Andrea Corallo 
Date: Sat, 30 May 2020 10:33:08 +0100
Subject: [PATCH] Add new gcc_jit_global_set_initializer entry point

gcc/jit/ChangeLog

2020-08-01  Andrea Corallo  

* docs/topics/compatibility.rst (LIBGCCJIT_ABI_14): New ABI tag.
* docs/topics/expressions.rst (gcc_jit_global_set_initializer):
Document new entry point in section 'Global variables'.
* jit-playback.c (global_new_decl, global_finalize_lvalue): New
method.
(playback::context::new_global): Make use of global_new_decl,
global_finalize_lvalue.
(load_blob_in_ctor): New template function in use by the
following.
(playback::context::new_global_initialized): New method.
* jit-playback.h (class context): Decl 'new_global_initialized',
'global_new_decl', 'global_finalize_lvalue'.
(lvalue::set_initializer): Add implementation.
* jit-recording.c (recording::memento_of_get_pointer::get_size)
(recording::memento_of_get_type::get_size): Add implementation.
(recording::global::write_initializer_reproducer): New function in
use by 'recording::global::write_reproducer'.
(recording::global::replay_into)
(recording::global::write_to_dump)
(recording::global::write_reproducer): Handle
initialized case.
* jit-recording.h (class type): Decl 'get_size' and
'num_elements'.
* libgccjit++.h (class lvalue): Declare new 'set_initializer'

[PATCH] fix a typo in tm.texi

[Wei Wentao]

This patch fix a typo in tm.texi.

Regards!
weiwt

---
 gcc/doc/tm.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index 6e7d9dc54a9..9b780f757fe 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -11277,7 +11277,7 @@ this macro.
 @end defmac
 
 @defmac VECTOR_STORE_FLAG_VALUE (@var{mode})
-A C expression that gives a rtx representing the nonzero true element
+A C expression that gives an rtx representing the nonzero true element
 for vector comparisons.  The returned rtx should be valid for the inner
 mode of @var{mode} which is guaranteed to be a vector mode.  Define
 this macro on machines that have vector comparison operations that
-- 
2.18.1

RE: [PATCH] x86_64: Integer min/max improvements.

[Roger Sayle]

Hi Richard,

As requested here are some additional test cases for this patch, derived
from the examples in my post.  For minmax-8 and minmax-9, the tests are
run at -Os, to avoid limiting code generation options (for speed) on future
architectures, i.e. CSE may or may not always be a win for performance, but
it is always smaller.  Tested on x86_64-pc-linux-gnu (with the above patch).

2020-08-03  Roger Sayle  

gcc/testsuite/ChangeLog
* gcc.target/i386/minmax-8.c: New test.
* gcc.target/i386/minmax-9.c: New test.
* gcc.target/i386/minmax-10.c: New test.
* gcc.target/i386/minmax-11.c: New test.


Cheers,
Roger
--

-Original Message-
From: Richard Biener  
Sent: 30 July 2020 13:21
To: Roger Sayle 
Cc: GCC Patches ; Uros Bizjak 
Subject: Re: [PATCH] x86_64: Integer min/max improvements.

On Thu, Jul 30, 2020 at 1:24 PM Roger Sayle  wrote:
>
>
> This patch tweaks the way that min and max are expanded, so that the 
> semantics of these operations are visible to the early RTL 
> optimization passes, until split into explicit comparison and 
> conditional move instructions. The good news is that i386.md already 
> contains all of the required logic (many thanks to Richard Biener and 
> Uros Bizjak), but this is currently only to enable scalar-to-vector 
> (STV) synthesis of min/max instructions.  This change enables this 
> functionality for all TARGET_CMOVE architectures for SImode, HImode and 
> DImode.
>
> My first attempt to support "min(reg,reg)" as an instruction revealed 
> why this functionality isn't already enabled: In PR rtl-optimization 
> 91154 we end up generating a cmp instead of a test in 
> gcc.target/i386/minmax-3.c which has poor performance on AMD Opteron.  
> My solution to this is to actually support "min(reg,general_operand)" 
> allowing us to inspect any immediate constant at the point this 
> operation is split.  This allows us to use "test" instructions for min/max 
> against 0, 1 and -1.
> As an added benefit it allows us to CSE large immediate constants, 
> reducing code size.
>
> Previously, "int foo(int x) { return max(x,12345); }" would generate:
>
> foo:cmpl$12345, %edi
> movl$12345, %eax
> cmovge  %edi, %eax
> ret
>
> with this patch we instead generate:
>
> foo:movl$12345, %eax
> cmpl%eax, %edi
> cmovge  %edi, %eax
> ret
>
>
> I've also included a peephole2 to avoid the "movl $0,%eax" 
> instructions being produced by the register allocator.  Materializing 
> constants as late as possible reduces register pressure, but for 
> const0_rtx on x86, it's preferable to use "xor" by moving this set 
> from between a flags setting operation and its use.  This should also 
> help instruction macro fusion on some microarchitectures, where 
> test/cmp and the following instruction can sometimes be combined.
>
> Previously, "int foo(int x) { return max(x,0); }" would generate:
>
> foo:testl   %edi, %edi
> movl$0, %eax
> cmovns  %edi, %eax
> ret
>
> with this patch we instead generate:
> foo:xorl%eax, %eax
> testl   %edi, %edi
> cmovns  %edi, %eax
> ret
>
> The benefits of having min/max explicit at the RTL level can be seen 
> from compiling the following example with "-O2 -fno-tree-reassoc".
>
>
> #define max(a,b) (((a) > (b))? (a) : (b))
>
> int foo(int x)
> {
>   int y = max(x,5);
>   return max(y,10);
> }
>
> where GCC currently produces:
>
> foo:cmpl$5, %edi
> movl$5, %eax
> movl$10, %edx
> cmovge  %edi, %eax
> cmpl$10, %eax
> cmovl   %edx, %eax
> ret
>
> and with this patch it instead now produces:
>
> foo:movl$10, %eax
> cmpl%eax, %edi
> cmovge  %edi, %eax
> ret
>
>
> The original motivation was from looking at a performance critical 
> function in a quantum mechanics code, that performed MIN_EXPR and 
> MAX_EXPR of the same arguments (effectively a two-element sort), where 
> GCC was performing the comparison twice.  I'd hoped that it might be 
> possible to fuse these together, perhaps in combine, but this patch is 
> an intermediate step towards that goal.
>
> This patch has been tested on x86_64-pc-linux-gnu with a make 
> bootstrap followed by make -k check with no new regressions.
> Ok for mainline?

May I ask for a testcase or two?  You have good examples above.
Btw, I'm sure some variants of those are in bugzilla as well.

Richard.

>
> 2020-07-30  Roger Sayle  
>
> * config/i386/i386.md (MAXMIN_IMODE): No longer needed.
> (3):  Support SWI248 and general_operand for
> second operand, when TARGET_CMOVE.
> (3_1 splitter): Optimize comparisons against
> 0, 1 and -1 to use "test" instead of "cmp".
> (*di3_doubleword): Likewise, allow general_operand
> and enable on TARGET_CMOVE.
> (peephole2): Convert clearing a register after a flag 

RE: [PATCH PR95696] regrename creates overlapping register allocations for vliw

[Yangfei (Felix)]

Hi Richard,

Thanks for reviewing this fix and the detailed suggestions : -)
Looks like my colleague Yunde was having some issue setting up his local 
repo.
I have prepared one for him.  Attached please find the patch.
Bootstrapped and tested on aarch64-linux-gnu.  Please help install if it's 
good to go.

Felix

> -Original Message-
> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> Sent: Friday, July 31, 2020 5:33 PM
> To: Zhongyunde 
> Cc: gcc-patches@gcc.gnu.org; Yangfei (Felix) 
> Subject: Re: [PATCH PR95696] regrename creates overlapping register
> allocations for vliw
> 
> Thanks for the update, looks good.  Could you post a changelog too so that I
> can use it when committing?
> 
> The changelog was the only reason I didn't just push the patch, but FWIW, a
> couple of very minor things…
> 
> Zhongyunde  writes:
> > diff --git a/gcc/regrename.c b/gcc/regrename.c old mode 100644 new
> > mode 100755 index 637b3cbe6d7..815ed22805d
> > --- a/gcc/regrename.c
> > +++ b/gcc/regrename.c
> > @@ -684,10 +684,12 @@ merge_chains (du_head_p c1, du_head_p c2)
> >c1->cannot_rename |= c2->cannot_rename;  }
> >
> > -/* Analyze the current function and build chains for renaming.  */
> > +/* Analyze the current function and build chains for renaming.
> > +   If INCLUDE_ALL_BLOCKS_P is set to true, should process all blocks,
> > +   ignoring BB_DISABLE_SCHEDULE.  The default value is true.  */
> 
> I think s/should// here, since GCC comments usually use an imperative style.
> 
> > @@ -737,6 +739,14 @@ regrename_analyze (bitmap bb_mask)
> >if (dump_file)
> > fprintf (dump_file, "\nprocessing block %d:\n", bb1->index);
> >
> > +  if (!include_all_block_p && (bb1->flags & BB_DISABLE_SCHEDULE) != 0)
> > +   {
> > + if (dump_file)
> > +   fprintf (dump_file, "avoid disrupting the sms schedule of bb %d\n",
> > +bb1->index);
> 
> bb1->index should be indented below “dump_file”.
> 
> Richard


pr95696-v0.diff
Description: pr95696-v0.diff

[PATCH v5] dse: Remove partial load after full store for high part access[PR71309]

[luoxhu via Gcc-patches]

Thanks, the v5 update as comments:
 1. Move const_rhs shift out of loop;
 2. Iterate from int size for read_mode.


This patch could optimize(works for char/short/int/void*):

6: r119:TI=[r118:DI+0x10]
7: [r118:DI]=r119:TI
8: r121:DI=[r118:DI+0x8]

=>

6: r119:TI=[r118:DI+0x10]
16: r122:DI=r119:TI#8

Final ASM will be as below without partial load after full store(stxv+ld):
  ld 10,16(3)
  mr 9,3
  ld 3,24(3)
  std 10,0(9)
  std 3,8(9)
  blr

It could achieve ~25% performance improvement for typical cases on
Power9.  Bootstrap and regression tested on Power9-LE.

For AArch64, one ldr is replaced by mov with this patch:

ldp x2, x3, [x0, 16]
stp x2, x3, [x0]
ldr x0, [x0, 8]

=>

mov x1, x0
ldp x2, x0, [x0, 16]
stp x2, x0, [x1]

gcc/ChangeLog:

2020-08-03  Xionghu Luo  

PR rtl-optimization/71309
* dse.c (find_shift_sequence): Use subreg of shifted from high part
register to avoid loading from address.

gcc/testsuite/ChangeLog:

2020-08-03  Xionghu Luo  

PR rtl-optimization/71309
* gcc.target/powerpc/pr71309.c: New test.
---
 gcc/dse.c  | 78 ++
 gcc/testsuite/gcc.target/powerpc/pr71309.c | 33 +
 2 files changed, 82 insertions(+), 29 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/pr71309.c

diff --git a/gcc/dse.c b/gcc/dse.c
index bbe792e48e8..b67b5c2ba35 100644
--- a/gcc/dse.c
+++ b/gcc/dse.c
@@ -1720,6 +1720,35 @@ find_shift_sequence (poly_int64 access_size,
   scalar_int_mode new_mode;
   rtx read_reg = NULL;
 
+  /* If a constant was stored into memory, try to simplify it here,
+ otherwise the cost of the shift might preclude this optimization
+ e.g. at -Os, even when no actual shift will be needed.  */
+  if (store_info->const_rhs)
+{
+  auto new_mode = smallest_int_mode_for_size (access_size * BITS_PER_UNIT);
+  auto byte = subreg_lowpart_offset (new_mode, store_mode);
+  rtx ret
+   = simplify_subreg (new_mode, store_info->const_rhs, store_mode, byte);
+  if (ret && CONSTANT_P (ret))
+   {
+ rtx shift_rtx = gen_int_shift_amount (new_mode, shift);
+ ret = simplify_const_binary_operation (LSHIFTRT, new_mode, ret,
+shift_rtx);
+ if (ret && CONSTANT_P (ret))
+   {
+ byte = subreg_lowpart_offset (read_mode, new_mode);
+ ret = simplify_subreg (read_mode, ret, new_mode, byte);
+ if (ret && CONSTANT_P (ret)
+ && (set_src_cost (ret, read_mode, speed)
+ <= COSTS_N_INSNS (1)))
+   return ret;
+   }
+   }
+}
+
+  if (require_cst)
+return NULL_RTX;
+
   /* Some machines like the x86 have shift insns for each size of
  operand.  Other machines like the ppc or the ia-64 may only have
  shift insns that shift values within 32 or 64 bit registers.
@@ -1729,7 +1758,7 @@ find_shift_sequence (poly_int64 access_size,
 
   opt_scalar_int_mode new_mode_iter;
   FOR_EACH_MODE_FROM (new_mode_iter,
- smallest_int_mode_for_size (access_size * BITS_PER_UNIT))
+ smallest_int_mode_for_size (GET_MODE_BITSIZE (read_mode)))
 {
   rtx target, new_reg, new_lhs;
   rtx_insn *shift_seq, *insn;
@@ -1739,34 +1768,6 @@ find_shift_sequence (poly_int64 access_size,
   if (GET_MODE_BITSIZE (new_mode) > BITS_PER_WORD)
break;
 
-  /* If a constant was stored into memory, try to simplify it here,
-otherwise the cost of the shift might preclude this optimization
-e.g. at -Os, even when no actual shift will be needed.  */
-  if (store_info->const_rhs)
-   {
- poly_uint64 byte = subreg_lowpart_offset (new_mode, store_mode);
- rtx ret = simplify_subreg (new_mode, store_info->const_rhs,
-store_mode, byte);
- if (ret && CONSTANT_P (ret))
-   {
- rtx shift_rtx = gen_int_shift_amount (new_mode, shift);
- ret = simplify_const_binary_operation (LSHIFTRT, new_mode,
-ret, shift_rtx);
- if (ret && CONSTANT_P (ret))
-   {
- byte = subreg_lowpart_offset (read_mode, new_mode);
- ret = simplify_subreg (read_mode, ret, new_mode, byte);
- if (ret && CONSTANT_P (ret)
- && (set_src_cost (ret, read_mode, speed)
- <= COSTS_N_INSNS (1)))
-   return ret;
-   }
-   }
-   }
-
-  if (require_cst)
-   return NULL_RTX;
-
   /* Try a wider mode if truncating the store mode to NEW_MODE
 requires a real instruction.  */
   if (maybe_lt (GET_MODE_SIZE (new_mode), GET_MODE_SIZE (store_mode))
@@ -1779,6 +1780,25 @@ find_shift_sequence (poly_int64 access_size,
  && !targetm.modes_tieable_p (new_mode, 

[committed] d: Merge upstream dmd c2274e56a (PR96250).

[Iain Buclaw via Gcc-patches]

Hi,

This patch merges the D front-end implementation with upstream dmd
c2274e56a, fixing a couple ICE bugs found in the front-end.

1. Fixes an ICE in the front-end if a struct symbol were to appear twice
in the compilation unit.

2. Fixes a rejects-valid bug in the front-end where `(symbol)' was being
resolved as a `var' expression, instead of `this.var'.

Bootstrapped and regression tested on x86_64-linux-gnu, and committed to
mainline.

Regards
Iain.

---
gcc/d/ChangeLog:

PR d/96250
* dmd/MERGE: Merge upstream dmd c2274e56a.
---
 gcc/d/dmd/MERGE   |  2 +-
 gcc/d/dmd/dstruct.c   |  9 -
 gcc/d/dmd/expressionsem.c | 10 +
 gcc/d/dmd/parse.c |  1 +
 gcc/testsuite/gdc.test/compilable/b9490.d | 39 +++
 gcc/testsuite/gdc.test/compilable/ice14739.d  | 19 +
 .../gdc.test/fail_compilation/fail17492.d | 20 +-
 .../gdc.test/fail_compilation/ice21060.d  | 15 +++
 .../imports/ice21060a/package.d   |  1 +
 .../imports/ice21060b/package.d   |  5 +++
 .../imports/ice21060c/package.d   |  1 +
 .../imports/ice21060d/package.d   |  5 +++
 gcc/testsuite/gdc.test/runnable/b16278.d  |  6 +++
 13 files changed, 129 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/gdc.test/compilable/b9490.d
 create mode 100644 gcc/testsuite/gdc.test/compilable/ice14739.d
 create mode 100644 gcc/testsuite/gdc.test/fail_compilation/ice21060.d
 create mode 100644 
gcc/testsuite/gdc.test/fail_compilation/imports/ice21060a/package.d
 create mode 100644 
gcc/testsuite/gdc.test/fail_compilation/imports/ice21060b/package.d
 create mode 100644 
gcc/testsuite/gdc.test/fail_compilation/imports/ice21060c/package.d
 create mode 100644 
gcc/testsuite/gdc.test/fail_compilation/imports/ice21060d/package.d
 create mode 100644 gcc/testsuite/gdc.test/runnable/b16278.d

diff --git a/gcc/d/dmd/MERGE b/gcc/d/dmd/MERGE
index b99e9f3353d..daa3e565ff7 100644
--- a/gcc/d/dmd/MERGE
+++ b/gcc/d/dmd/MERGE
@@ -1,4 +1,4 @@
-8508c4e683f065eb3deab76b610f7fecb3258a8e
+c2274e56a3220ea636c6199fd06cd54fcdf6bad9
 
 The first line of this file holds the git revision number of the last
 merge done from the dlang/dmd repository.
diff --git a/gcc/d/dmd/dstruct.c b/gcc/d/dmd/dstruct.c
index 86bb6c8aa76..2b87154142c 100644
--- a/gcc/d/dmd/dstruct.c
+++ b/gcc/d/dmd/dstruct.c
@@ -1206,6 +1206,13 @@ void StructDeclaration::semantic(Scope *sc)
 }
 }
 
+if (type->ty == Tstruct && ((TypeStruct *)type)->sym != this)
+{
+// https://issues.dlang.org/show_bug.cgi?id=19024
+StructDeclaration *sd = ((TypeStruct *)type)->sym;
+error("already exists at %s. Perhaps in another function with the same 
name?", sd->loc.toChars());
+}
+
 if (global.errors != errors)
 {
 // The type is no good.
@@ -1220,8 +1227,6 @@ void StructDeclaration::semantic(Scope *sc)
 deferred->semantic2(sc);
 deferred->semantic3(sc);
 }
-
-assert(type->ty != Tstruct || ((TypeStruct *)type)->sym == this);
 }
 
 Dsymbol *StructDeclaration::search(const Loc , Identifier *ident, int 
flags)
diff --git a/gcc/d/dmd/expressionsem.c b/gcc/d/dmd/expressionsem.c
index ac6b5bc81f3..9f21dabb7e4 100644
--- a/gcc/d/dmd/expressionsem.c
+++ b/gcc/d/dmd/expressionsem.c
@@ -812,6 +812,16 @@ public:
 exp->type->resolve(exp->loc, sc, , , , true);
 if (e)
 {
+// `(Type)` is actually `(var)` so if `(var)` is a member 
requiring `this`
+// then rewrite as `(this.var)` in case it would be followed by a 
DotVar
+// to fix https://issues.dlang.org/show_bug.cgi?id=9490
+VarExp *ve = e->isVarExp();
+if (ve && ve->var && exp->parens && !ve->var->isStatic() && 
!(sc->stc & STCstatic) &&
+sc->func && sc->func->needThis() && 
ve->var->toParent2()->isAggregateDeclaration())
+{
+// printf("apply fix for issue 9490: add `this.` to 
`%s`...\n", e->toChars());
+e = new DotVarExp(exp->loc, new ThisExp(exp->loc), ve->var, 
false);
+}
 //printf("e = %s %s\n", Token::toChars(e->op), e->toChars());
 e = semantic(e, sc);
 }
diff --git a/gcc/d/dmd/parse.c b/gcc/d/dmd/parse.c
index f4cd28ed2fb..d1017ac462c 100644
--- a/gcc/d/dmd/parse.c
+++ b/gcc/d/dmd/parse.c
@@ -7531,6 +7531,7 @@ Expression *Parser::parseUnaryExp()
 return NULL;
 }
 e = new TypeExp(loc, t);
+e->parens = 1;
 e = parsePostExp(e);
 }
 else
diff --git a/gcc/testsuite/gdc.test/compilable/b9490.d 
b/gcc/testsuite/gdc.test/compilable/b9490.d
new file mode 100644
index 000..d0148b1a738
--- /dev/null
+++ 

Re: [PATCH wwwdocs] Explicitly list powerpc64le-unknown-linux-gnu as a primary platform

[Florian Weimer via Gcc-patches]

* Florian Weimer via Gcc-patches:

> The intent was that this was implied by powerpc64-unknown-linux-gnu,
> but this not very obvious because of the ELFv1 vs ELFv2 ABI
> differences.
>
> ---
>  htdocs/gcc-10/criteria.html | 1 +
>  htdocs/gcc-11/criteria.html | 1 +
>  htdocs/gcc-9/criteria.html  | 1 +
>  3 files changed, 3 insertions(+)
>
> diff --git a/htdocs/gcc-10/criteria.html b/htdocs/gcc-10/criteria.html
> index b870b829..10144710 100644
> --- a/htdocs/gcc-10/criteria.html
> +++ b/htdocs/gcc-10/criteria.html
> @@ -111,6 +111,7 @@ application testing.
>  i686-pc-linux-gnu
>  mipsisa64-elf
>  powerpc64-unknown-linux-gnu
> +powerpc64le-unknown-linux-gnu
>  sparc-sun-solaris2.11
>  x86_64-pc-linux-gnu
>  
> diff --git a/htdocs/gcc-11/criteria.html b/htdocs/gcc-11/criteria.html
> index cef92821..adf566e1 100644
> --- a/htdocs/gcc-11/criteria.html
> +++ b/htdocs/gcc-11/criteria.html
> @@ -111,6 +111,7 @@ application testing.
>  i686-pc-linux-gnu
>  mipsisa64-elf
>  powerpc64-unknown-linux-gnu
> +powerpc64le-unknown-linux-gnu
>  sparc-sun-solaris2.11
>  x86_64-pc-linux-gnu
>  
> diff --git a/htdocs/gcc-9/criteria.html b/htdocs/gcc-9/criteria.html
> index d434646c..f75bf990 100644
> --- a/htdocs/gcc-9/criteria.html
> +++ b/htdocs/gcc-9/criteria.html
> @@ -111,6 +111,7 @@ application testing.
>  i686-pc-linux-gnu
>  mipsisa64-elf
>  powerpc64-unknown-linux-gnu
> +powerpc64le-unknown-linux-gnu
>  sparc-sun-solaris2.11
>  x86_64-pc-linux-gnu
>  

Ping?

Thanks,
Florian