PC-relative TLS support

[Alan Modra]

Supporting TLS for -mpcrel turns out to be relatively simple, in part
due to deciding that !TARGET_TLS_MARKERS with -mpcrel is silly.  No
assembler that I know of supporting prefix insns lacks TLS marker
support.  Also, at some point powerpc gcc ought to remove
!TARGET_TLS_MARKERS generally and simplify all the occurrences of
IS_NOMARK_TLSGETADDR in rs6000.md rather than complicating them.

Mike, the rs6000_option_override_internal hunk is new compared to
the patch you had from me.

* config/rs6000/predicates.md (unspec_tls): Allow const0_rtx for got
element of unspec vec.
* config/rs6000/rs6000.c (rs6000_option_override_internal): Disable
-mpcrel if -mno-tls-markers.
(rs6000_legitimize_tls_address): Support PC-relative TLS.
* config/rs6000/rs6000.md (UNSPEC_TLSTLS_PCREL): New unspec.
(tls_gd_pcrel, tls_ld_pcrel): New insns.
(tls_dtprel, tls_tprel): Set attr prefixed when tls_size is not 16.
(tls_got_tprel_pcrel, tls_tls_pcrel): New insns.

diff --git a/gcc/config/rs6000/predicates.md b/gcc/config/rs6000/predicates.md
index fba87946ec7..4ea588e1027 100644
--- a/gcc/config/rs6000/predicates.md
+++ b/gcc/config/rs6000/predicates.md
@@ -995,9 +995,9 @@
   if (CONST_INT_P (op))
 return 1;
   if (XINT (op, 1) == UNSPEC_TLSGD)
-return REG_P (XVECEXP (op, 0, 1));
+return REG_P (XVECEXP (op, 0, 1)) || XVECEXP (op, 0, 1) == const0_rtx;
   if (XINT (op, 1) == UNSPEC_TLSLD)
-return REG_P (XVECEXP (op, 0, 0));
+return REG_P (XVECEXP (op, 0, 0)) || XVECEXP (op, 0, 0) == const0_rtx;
   return 0;
 })
 
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 6aca0ce5bf3..c04206ab139 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -4216,6 +4216,16 @@ rs6000_option_override_internal (bool global_init_p)
| OPTION_MASK_PCREL_OPT);
 }
 
+  /* -mpcrel requires tls marker support.  */
+  if (TARGET_PCREL && !TARGET_TLS_MARKERS)
+{
+  if ((rs6000_isa_flags_explicit & OPTION_MASK_PCREL) != 0)
+   error ("%qs requires %qs", "-mpcrel", "-mtls-markers");
+
+  rs6000_isa_flags &= ~(OPTION_MASK_PCREL
+   | OPTION_MASK_PCREL_OPT);
+}
+
   /* Check -mfuture debug switches.  */
   if (!TARGET_PCREL && TARGET_PCREL_OPT)
 {
@@ -8613,7 +8623,8 @@ rs6000_legitimize_tls_address (rtx addr, enum tls_model 
model)
 return rs6000_legitimize_tls_address_aix (addr, model);
 
   dest = gen_reg_rtx (Pmode);
-  if (model == TLS_MODEL_LOCAL_EXEC && rs6000_tls_size == 16)
+  if (model == TLS_MODEL_LOCAL_EXEC
+  && (rs6000_tls_size == 16 || rs6000_pcrel_p (cfun)))
 {
   rtx tlsreg;
 
@@ -8660,7 +8671,9 @@ rs6000_legitimize_tls_address (rtx addr, enum tls_model 
model)
 them in the .got section.  So use a pointer to the .got section,
 not one to secondary TOC sections used by 64-bit -mminimal-toc,
 or to secondary GOT sections used by 32-bit -fPIC.  */
-  if (TARGET_64BIT)
+  if (rs6000_pcrel_p (cfun))
+   got = const0_rtx;
+  else if (TARGET_64BIT)
got = gen_rtx_REG (Pmode, 2);
   else
{
@@ -8735,7 +8748,7 @@ rs6000_legitimize_tls_address (rtx addr, enum tls_model 
model)
  rtx uns = gen_rtx_UNSPEC (Pmode, vec, UNSPEC_TLS_GET_ADDR);
  set_unique_reg_note (get_last_insn (), REG_EQUAL, uns);
 
- if (rs6000_tls_size == 16)
+ if (rs6000_tls_size == 16 || rs6000_pcrel_p (cfun))
{
  if (TARGET_64BIT)
insn = gen_tls_dtprel_64 (dest, tmp1, addr);
@@ -8776,7 +8789,14 @@ rs6000_legitimize_tls_address (rtx addr, enum tls_model 
model)
  else
insn = gen_tls_got_tprel_32 (tmp2, got, addr);
  emit_insn (insn);
- if (TARGET_64BIT)
+ if (rs6000_pcrel_p (cfun))
+   {
+ if (TARGET_64BIT)
+   insn = gen_tls_tls_pcrel_64 (dest, tmp2, addr);
+ else
+   insn = gen_tls_tls_pcrel_32 (dest, tmp2, addr);
+   }
+ else if (TARGET_64BIT)
insn = gen_tls_tls_64 (dest, tmp2, addr);
  else
insn = gen_tls_tls_32 (dest, tmp2, addr);
diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index 0e7d90e5357..6e32d8fdff1 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -88,6 +88,7 @@
UNSPEC_TLSTPRELLO
UNSPEC_TLSGOTTPREL
UNSPEC_TLSTLS
+   UNSPEC_TLSTLS_PCREL
UNSPEC_FIX_TRUNC_TF ; fadd, rounding towards zero
UNSPEC_STFIWX
UNSPEC_POPCNTB
@@ -9514,6 +9515,15 @@
 
 ;; TLS support.
 
+(define_insn "*tls_gd_pcrel"
+  [(set (match_operand:P 0 "gpc_reg_operand" "=b")
+   (unspec:P [(match_operand:P 1 "rs6000_tls_symbol_ref" "")
+  (const_int 0)]
+ UNSPEC_TLSGD))]
+  "HAVE_AS_TLS && TARGET_TLS_MARKERS"
+  "la %0,%1@got@tlsgd@pcrel"
+  [(set_attr "prefixed" "yes")])
+
 

Re: Patch to support extended characters in C/C++ identifiers

[Jason Merrill]

On 8/12/19 6:01 PM, Lewis Hyatt wrote:

Hello-

The attached patch for libcpp adds support for extended characters (e.g. UTF-8)
in identifiers. A preliminary version of the patch was posted on PR c/67224 as
Comment 26 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224#c26) and
discussed with Joseph Myers. Here is an updated patch incorporating all
feedback received so far. I hope it is suitable now; please let me know if I
can do anything else to make it ready for you to apply. I am happy to work on
it further, whatever is needed. I can't easily test on anything other than
x86_64-linux though. I did bootstrap all languages and run all tests on that
platform, everything was good.

The (relatively short) changes to libcpp are included inline here. I attached
the test cases as a gzipped patch to avoid any problems with the encoding (the
test cases contain some invalid UTF-8 and also other encodings such as latin-1
as part of the testing).

Thanks for taking a look at it!


Looks good to me.  Joseph?

Jason

Re: PowerPC 'future' patches introduction

[Segher Boessenkool]

Hi Mike,

On Wed, Aug 14, 2019 at 04:57:32PM -0400, Michael Meissner wrote:
> to the current location instead of a base register, giving pc-relative
> addressing.  Pc-relative addressing will be supported in the next ABI (3.1) as
> an alternative to the current TOC based addressing.

That's not an ABI version, that's an ISA version.  But it will be in a
future ELFv2 ABI version, yes.

> The fifth patch switches the default when you use -mcpu=future to use
> pc-relative instructions instead of using the TOC by default.

As David reminded me, you should only do this on OSes where this works.
Only for ABIs that support PCREL, even?  Or both.

> The seventh patch adds a new RTL pass to implement the PCREL_OPT relocations
> that will be part of the ISA 3.1 specification.

Some version of the ELFv2 ABI again?


Segher

Re: [PATCH] i386: Expand roundeven for SSE4.1+

[Joseph Myers]

On Sun, 14 Jul 2019, Uros Bizjak wrote:

> > This patch is for expanding roundeven inline for SSE4.1 and later.
> > Note that this patch is to be applied on top of
> > . The patch
> > is bootstrapped and regression tested on x86_64-linux-gnu.
> 
> Actually, your patch at [1] is the way to go, but you need several
> other changes to get x87 mode switching in order. Please also note
> that there is no corresponding non-SSE4 ix86_expand_... function for
> roundeven, so non-SSE4 SSE FP-math 2 expander has
> to be disabled for ROUNDEVEN int iterator. Please see (otherwise
> untested) attached patch which fixes both issues.

This needs md.texi updates to document the new roundeven insn 
pattern.

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

[PATCH], Patch #10 of 10, Add pc-relative tests

[Michael Meissner]

This patch adds tests to make sure the appropriate pc-relative instructions are
generated for -mcpu=future.

The tests in this patch all pass with patches 1-7 applied on a little endian
power8 system running Linux.  Once patches 1-7 have been applied, can I check
these patches into the trunk?

2019-08-14  Michael Meissner  

* gcc/testsuite/gcc.target/powerpc/prefix-large.h: New set of
tests to test prefixed addressing on 'future' system with
pc-relative addreses.
* gcc/testsuite/gcc.target/powerpc/prefix-pcrel-dd.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-pcrel-df.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-pcrel-di.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-pcrel-hi.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-pcrel-kf.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-pcrel-qi.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-pcrel-sd.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-pcrel-sf.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-pcrel-si.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-pcrel-udi.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-pcrel-uhi.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-pcrel-uqi.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-pcrel-usi.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-pcrel-v2df.c: New test.

Index: gcc/testsuite/gcc.target/powerpc/prefix-pcrel-dd.c
===
--- gcc/testsuite/gcc.target/powerpc/prefix-pcrel-dd.c  (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/prefix-pcrel-dd.c  (working copy)
@@ -0,0 +1,13 @@
+/* { dg-do compile { target { powerpc*-*-* } } } */
+/* { dg-require-effective-target powerpc_future_ok } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* Tests for prefixed instructions testing whether pc-relative prefixed
+   instructions are generated for SImode.  */
+
+#define TYPE _Decimal64
+
+#include "prefix-pcrel.h"
+
+/* { dg-final { scan-assembler-times {\mplfd\M}  2 } } */
+/* { dg-final { scan-assembler-times {\mpstfd\M} 2 } } */
Index: gcc/testsuite/gcc.target/powerpc/prefix-pcrel-df.c
===
--- gcc/testsuite/gcc.target/powerpc/prefix-pcrel-df.c  (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/prefix-pcrel-df.c  (working copy)
@@ -0,0 +1,13 @@
+/* { dg-do compile { target { powerpc*-*-* } } } */
+/* { dg-require-effective-target powerpc_future_ok } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* Tests for prefixed instructions testing whether pc-relative prefixed
+   instructions are generated for DFmode.  */
+
+#define TYPE double
+
+#include "prefix-pcrel.h"
+
+/* { dg-final { scan-assembler-times {\mplfd\M}  2 } } */
+/* { dg-final { scan-assembler-times {\mpstfd\M} 2 } } */
Index: gcc/testsuite/gcc.target/powerpc/prefix-pcrel-di.c
===
--- gcc/testsuite/gcc.target/powerpc/prefix-pcrel-di.c  (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/prefix-pcrel-di.c  (working copy)
@@ -0,0 +1,13 @@
+/* { dg-do compile { target { powerpc*-*-* } } } */
+/* { dg-require-effective-target powerpc_future_ok } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* Tests for prefixed instructions testing whether pc-relative prefixed
+   instructions are generated for DImode.  */
+
+#define TYPE long
+
+#include "prefix-pcrel.h"
+
+/* { dg-final { scan-assembler-times {\mpld\M}  2 } } */
+/* { dg-final { scan-assembler-times {\mpstd\M} 2 } } */
Index: gcc/testsuite/gcc.target/powerpc/prefix-pcrel-hi.c
===
--- gcc/testsuite/gcc.target/powerpc/prefix-pcrel-hi.c  (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/prefix-pcrel-hi.c  (working copy)
@@ -0,0 +1,13 @@
+/* { dg-do compile { target { powerpc*-*-* } } } */
+/* { dg-require-effective-target powerpc_future_ok } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* Tests for prefixed instructions testing whether pc-relative prefixed
+   instructions are generated for HImode.  */
+
+#define TYPE short
+
+#include "prefix-pcrel.h"
+
+/* { dg-final { scan-assembler-times {\mplh[az]\M}  2 } } */
+/* { dg-final { scan-assembler-times {\mpsth\M} 2 } } */
Index: gcc/testsuite/gcc.target/powerpc/prefix-pcrel-kf.c
===
--- gcc/testsuite/gcc.target/powerpc/prefix-pcrel-kf.c  (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/prefix-pcrel-kf.c  (working copy)
@@ -0,0 +1,13 @@
+/* { dg-do compile { target { powerpc*-*-* } } } */
+/* { dg-require-effective-target powerpc_future_ok } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* Tests for prefixed instructions testing whether pc-relative prefixed
+   instructions are 

[PATCH], Patch #9 of 10, Add tests with large memory offsets

[Michael Meissner]

This patch adds tests for all of the types using large address offsets that
would not fit into 16 bits, and verifies that prefixed instructions are 
generated.

The tests in this patch all succeed when patches 1-7 are applied on a little
endian power8 system.  Can I check these patches into the trunk when the
previous patches have been applied?

2019-08-14  Michael Meissner  

* gcc/testsuite/gcc.target/powerpc/prefix-large.h: New set of
tests to test prefixed addressing on 'future' system with large
numeric offsets.
* gcc/testsuite/gcc.target/powerpc/prefix-large-dd.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-large-df.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-large-di.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-large-hi.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-large-kf.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-large-qi.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-large-sd.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-large-sf.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-large-si.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-large-udi.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-large-uhi.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-large-uqi.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-large-usi.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-large-v2df.c: New test.

Index: gcc/testsuite/gcc.target/powerpc/prefix-large-dd.c
===
--- gcc/testsuite/gcc.target/powerpc/prefix-large-dd.c  (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/prefix-large-dd.c  (working copy)
@@ -0,0 +1,13 @@
+/* { dg-do compile { target { powerpc*-*-* } } } */
+/* { dg-require-effective-target powerpc_future_ok } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* Tests for prefixed instructions testing whether we can generate a prefixed
+   load/store instruction that has a 34-bit offset.  */
+
+#define TYPE _Decimal64
+
+#include "prefix-large.h"
+
+/* { dg-final { scan-assembler-times {\mplfd\M}  2 } } */
+/* { dg-final { scan-assembler-times {\mpstfd\M} 2 } } */
Index: gcc/testsuite/gcc.target/powerpc/prefix-large-df.c
===
--- gcc/testsuite/gcc.target/powerpc/prefix-large-df.c  (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/prefix-large-df.c  (working copy)
@@ -0,0 +1,13 @@
+/* { dg-do compile { target { powerpc*-*-* } } } */
+/* { dg-require-effective-target powerpc_future_ok } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* Tests for prefixed instructions testing whether we can generate a prefixed
+   load/store instruction that has a 34-bit offset.  */
+
+#define TYPE double
+
+#include "prefix-large.h"
+
+/* { dg-final { scan-assembler-times {\mplfd\M}  2 } } */
+/* { dg-final { scan-assembler-times {\mpstfd\M} 2 } } */
Index: gcc/testsuite/gcc.target/powerpc/prefix-large-di.c
===
--- gcc/testsuite/gcc.target/powerpc/prefix-large-di.c  (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/prefix-large-di.c  (working copy)
@@ -0,0 +1,13 @@
+/* { dg-do compile { target { powerpc*-*-* } } } */
+/* { dg-require-effective-target powerpc_future_ok } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* Tests for prefixed instructions testing whether we can generate a prefixed
+   load/store instruction that has a 34-bit offset.  */
+
+#define TYPE long
+
+#include "prefix-large.h"
+
+/* { dg-final { scan-assembler-times {\mpld\M}  2 } } */
+/* { dg-final { scan-assembler-times {\mpstd\M} 2 } } */
Index: gcc/testsuite/gcc.target/powerpc/prefix-large-hi.c
===
--- gcc/testsuite/gcc.target/powerpc/prefix-large-hi.c  (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/prefix-large-hi.c  (working copy)
@@ -0,0 +1,13 @@
+/* { dg-do compile { target { powerpc*-*-* } } } */
+/* { dg-require-effective-target powerpc_future_ok } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* Tests for prefixed instructions testing whether we can generate a prefixed
+   load/store instruction that has a 34-bit offset.  */
+
+#define TYPE short
+
+#include "prefix-large.h"
+
+/* { dg-final { scan-assembler-times {\mplh[az]\M}  2 } } */
+/* { dg-final { scan-assembler-times {\mpsth\M} 2 } } */
Index: gcc/testsuite/gcc.target/powerpc/prefix-large-kf.c
===
--- gcc/testsuite/gcc.target/powerpc/prefix-large-kf.c  (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/prefix-large-kf.c  (working copy)
@@ -0,0 +1,13 @@
+/* { dg-do compile { target { powerpc*-*-* } } } */
+/* { dg-require-effective-target powerpc_future_ok } */
+/* { dg-options "-O2 

[PATCH], Patch #8 of 10, Miscellaneous future tests

[Michael Meissner]

This patch adds miscellaneous tests for the new prefixed addressing.

With patches 1-7 applied, these patches all succeed.  Can I check these patches
into the trunk?

2019-08-14  Michael Meissner  

* gcc/testsuite/gcc.target/powerpc/prefix-odd-memory.c: New test.
* gcc/testsuite/gcc.target/powerpc/paddi-1.c: New test.
* gcc/testsuite/gcc.target/powerpc/paddi-2.c: New test.
* gcc/testsuite/gcc.target/powerpc/paddi-3.c: New test.
* gcc/testsuite/gcc.target/powerpc/prefix-premodify.c: New test.

Index: gcc/testsuite/gcc.target/powerpc/paddi-1.c
===
--- gcc/testsuite/gcc.target/powerpc/paddi-1.c  (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/paddi-1.c  (working copy)
@@ -0,0 +1,12 @@
+/* { dg-do compile { target { powerpc*-*-* } } } */
+/* { dg-require-effective-target powerpc_future_ok } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* Test that PADDI is generated to add a large constant.  */
+unsigned long
+add (unsigned long a)
+{
+  return a + 0x12345678UL;
+}
+
+/* { dg-final { scan-assembler {\mpaddi\M} } } */
Index: gcc/testsuite/gcc.target/powerpc/paddi-2.c
===
--- gcc/testsuite/gcc.target/powerpc/paddi-2.c  (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/paddi-2.c  (working copy)
@@ -0,0 +1,12 @@
+/* { dg-do compile { target { powerpc*-*-* } } } */
+/* { dg-require-effective-target powerpc_future_ok } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* Test that PLI (PADDI) is generated to load a large constant.  */
+unsigned long
+large (void)
+{
+  return 0x12345678UL;
+}
+
+/* { dg-final { scan-assembler {\mpli\M} } } */
Index: gcc/testsuite/gcc.target/powerpc/paddi-3.c
===
--- gcc/testsuite/gcc.target/powerpc/paddi-3.c  (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/paddi-3.c  (working copy)
@@ -0,0 +1,12 @@
+/* { dg-do compile { target { powerpc*-*-* } } } */
+/* { dg-require-effective-target powerpc_future_ok } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* 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} } } */
Index: gcc/testsuite/gcc.target/powerpc/prefix-odd-memory.c
===
--- gcc/testsuite/gcc.target/powerpc/prefix-odd-memory.c(revision 0)
+++ gcc/testsuite/gcc.target/powerpc/prefix-odd-memory.c(working copy)
@@ -0,0 +1,156 @@
+/* { dg-do compile { target { powerpc*-*-* && lp64 } } } */
+/* { dg-require-effective-target powerpc_future_ok } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* Tests whether we can generate a prefixed load/store operation for addresses
+   that don't meet DS/DQ alignment constraints.  */
+
+unsigned long
+load_uc_odd (unsigned char *p)
+{
+  return p[1]; /* should generate LBZ.  */
+}
+
+long
+load_sc_odd (signed char *p)
+{
+  return p[1]; /* should generate LBZ + EXTSB.  */
+}
+
+unsigned long
+load_us_odd (unsigned char *p)
+{
+  return *(unsigned short *)(p + 1);   /* should generate LHZ.  */
+}
+
+long
+load_ss_odd (unsigned char *p)
+{
+  return *(short *)(p + 1);/* should generate LHA.  */
+}
+
+unsigned long
+load_ui_odd (unsigned char *p)
+{
+  return *(unsigned int *)(p + 1); /* should generate LWZ.  */
+}
+
+long
+load_si_odd (unsigned char *p)
+{
+  return *(int *)(p + 1);  /* should generate PLWA.  */
+}
+
+unsigned long
+load_ul_odd (unsigned char *p)
+{
+  return *(unsigned long *)(p + 1);/* should generate PLD.  */
+}
+
+long
+load_sl_odd (unsigned char *p)
+{
+  return *(long *)(p + 1); /* should generate PLD.  */
+}
+
+float
+load_float_odd (unsigned char *p)
+{
+  return *(float *)(p + 1);/* should generate LFS.  */
+}
+
+double
+load_double_odd (unsigned char *p)
+{
+  return *(double *)(p + 1);   /* should generate LFD.  */
+}
+
+__ieee128
+load_ieee128_odd (unsigned char *p)
+{
+  return *(__ieee128 *)(p + 1);/* should generate PLXV.  */
+}
+
+void
+store_uc_odd (unsigned char uc, unsigned char *p)
+{
+  p[1] = uc;   /* should generate STB.  */
+}
+
+void
+store_sc_odd (signed char sc, signed char *p)
+{
+  p[1] = sc;   /* should generate STB.  */
+}
+
+void
+store_us_odd (unsigned short us, unsigned char *p)
+{
+  *(unsigned short *)(p + 1) = us; /* should generate STH.  */
+}
+
+void
+store_ss_odd (signed short ss, unsigned char *p)
+{
+  *(signed short *)(p + 1) = ss;   /* should generate STH.  */
+}
+
+void
+store_ui_odd (unsigned int ui, unsigned char *p)
+{
+  *(unsigned int *)(p + 1) = ui;   /* should generate STW.  */
+}
+
+void
+store_si_odd (signed int si, unsigned char *p)
+{
+  

[PATCH], Patch #7 of 10, Add support for PCREL_OPT

[Michael Meissner]

This patch adds a new RTL pass that occurs before the final pass to implement
the PCREL_OPT optimization that is implemented by the linker.

Without this optimization, access to external symbols loads up the address from
a .GOT section and does the normal operation.  For example:

extern unsigned int esym;

/* ... */

esym = 1;

would generate:

pld 9,esym@got@pcrel
li 10,1
stw 10,0(9)

I.e. load the address of 'esym' into r9, and do a normal 'stw'.

With the PCREL_OPT optimization, the compiler would generate:

li 9,1
pld 10,esym@got@pcrel
.Lpcrel1:
.reloc .Lpcrel1-8,R_PPC64_PCREL_OPT,.-(.Lpcrel1-8)
stw 9,0(10)

When the module is linked, if the object file is in the main program and the
'esym' variable is also in the main program, the linker will change the code
to:

li 9,1
pstw 9,esym@pcrel
nop

If either the object file is in a shared library, or the variable 'esym' is in
a shared library, then the old code is used:

li 9,1
pld 10,esym.got@pcrel
stw 9,0(10)

.section .got
esym.got:
.quad esym

When optimizing loads with PCREL_OPT, this patch makes sure that the register
being loaded is not live between the PLD instruction loading the address and
the normal load instruction.

Similarly, when optimizing stores with PCREL_OPT, this patch makes sures values
being stored must be live at the time the address is loaded and still live at
the time the store is done.

If there is more than reference to the external symbol in the basic block, or
the load of the address is in one basic block and the memory reference is in
another basic block, this pass does not optimize the reference to use
PCREL_OPT.  For example:

extern unsigned int esym;

void inc (void)
{
  esym++;
}

Generates:

pld 10,esym@got@pcrel
lwz 9,0(10)
addi 9,9,1
stw 9,0(10)

As with the other patches, I have bootstraped the changes on a little endian
power8 system and there were no regressions.  Once the previous patches are
checked in, can I check this patch into the trunk?

[gcc]
2019-08-14   Michael Meissner  

* config/rs6000/pcrel.md: New file.
* config/rs6000/predicates.md (one_reg_memory_operand): New
predicate.
* config/rs6000/rs6000-cpus.def (ISA_FUTURE_MASKS_SERVER): Add
-mpcrel-opt.
(OTHER_FUTURE_MASKS): Add -mpcrel-opt.
(POWERPC_MASKS): Add -mpcrel-opt.
* config/rs6000/rs6000-passes.def: Add pc-relative optimization
pass.
* config/rs6000/rs6000-pcrel.c: New file.
* config/rs6000/rs6000-prefixed.c (pcrel_opt_label_num): New
static variable.
(rs6000_final_prescan_insn): Add support for pc-relative
optimization pass.
(rs6000_asm_output_opcode): Add support for pc-relative
optimization pass.
* config/rs6000/rs6000-protos.h (rs6000_final_prescan_insn):
Change calling signature.
(make_pass_pcrel_opt): New declaration.
* config/rs6000/rs6000.c (rs6000_option_override_internal): Add
support for -mpcrel-opt.
(rs6000_opt_masks): Add -mpcrel-opt.
* config/rs6000/rs6000.h (FINAL_PRESCAN_INSN): Update
rs6000_final_prescan_insn call.
* config/rs6000/rs6000.md: Include pcrel.md.
(pcrel_opt attribute): New RTL attribute.
* config/rs6000/rs6000.opt (-mpcrel-opt): New option.
* config/rs6000/t-rs6000 (rs6000-pcrel.o): Add build rule.
(MD_INCLUDES): Add pcrel.md.
* config.gcc (powerpc*-*-*): Add rs6000-pcrel.o.
(rs6000*-*-*): Add rs6000-pcrel.o.

[gcc/testsuite]
2019-08-07   Michael Meissner  

* gcc.target/powerpc/pcrel-opt-di.c: New test.

Index: gcc/config/rs6000/pcrel.md
===
--- gcc/config/rs6000/pcrel.md  (revision 0)
+++ gcc/config/rs6000/pcrel.md  (working copy)
@@ -0,0 +1,563 @@
+;; PC relative support.
+;; Copyright (C) 2019 Free Software Foundation, Inc.
+;; Contributed by Peter Bergner  and
+;;   Michael Meissner 
+
+;; This file is part of GCC.
+
+;; GCC 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.
+
+;; GCC 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.
+
+;; You should have received a copy of the GNU General Public License
+;; along with GCC; see the file COPYING3.  If not see
+;; .
+
+;;
+;; UNSPEC usage
+;;
+
+(define_c_enum "unspec"
+  [UNSPEC_PCREL_LD
+   UNSPEC_PCREL_ST
+  ])
+
+
+;; Optimize references to 

[PATCH], Patch #6 of 10, Add 'future' support to function attributes

[Michael Meissner]

This patch adds support for using cpu=future in the "target" function
attribute, "target" pragma support, and "target_clones" function attributes.

In addition, it adds support for the following arguments to
__builtin_cpu_supports:

"arch_3_1"  Whether ISA 3.1 is supported by the machine;
"mma"   Whether the MMA extension is supported by the machine.

The hwcap2 bits used in the auxv table will be appearing in future Linux
kernels.  At this present time, there is no support for:

__builtin_cpu_is ("future")

I have built each of the patches on a little endian power8 system and there
were no regressions in either the bootstrap or make check operations.  Can I
check this patch into the trunk after the other patches have been checked in?

[gcc]
2019-08-14   Michael Meissner  

* config/rs6000/ppc-auxv.h (PPC_FEATURE2_ARCH_3_1): New hwcap2
bit.
(PPC_FEATURE2_MMA): New hwcap2 bit.
* config/rs6000/rs6000-call.c (cpu_supports_info): Add arch 3.1
and mma bits.
* config/rs6000/rs6000.c (rs6000_clone_map): Add 'future' system
to target_clone support.

[gcc/testsuite]
2019-08-14  Michael Meissner  

* gcc.target/powerpc/clone3.c: New test for using 'future' with
the target_clones attribute.

Index: gcc/config/rs6000/ppc-auxv.h
===
--- gcc/config/rs6000/ppc-auxv.h(revision 274173)
+++ gcc/config/rs6000/ppc-auxv.h(working copy)
@@ -93,6 +93,9 @@
 #define PPC_FEATURE2_SCV0x0010
 #define PPC_FEATURE2_HTM_NO_SUSPEND 0x0008
 
+/* These are not yet official.  */
+#define PPC_FEATURE2_ARCH_3_1   0x0004
+#define PPC_FEATURE2_MMA0x0002
 
 /* Thread Control Block (TCB) offsets of the AT_PLATFORM, AT_HWCAP and
AT_HWCAP2 values.  These must match the values defined in GLIBC.  */
Index: gcc/config/rs6000/rs6000-call.c
===
--- gcc/config/rs6000/rs6000-call.c (revision 274173)
+++ gcc/config/rs6000/rs6000-call.c (working copy)
@@ -171,7 +171,9 @@ static const struct
   { "arch_3_00",   PPC_FEATURE2_ARCH_3_00, 1 },
   { "ieee128", PPC_FEATURE2_HAS_IEEE128,   1 },
   { "darn",PPC_FEATURE2_DARN,  1 },
-  { "scv", PPC_FEATURE2_SCV,   1 }
+  { "scv", PPC_FEATURE2_SCV,   1 },
+  { "arch_3_1",PPC_FEATURE2_ARCH_3_1,  1 },
+  { "mma", PPC_FEATURE2_MMA,   1 },
 };
 
 static void altivec_init_builtins (void);
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 274178)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -259,6 +259,7 @@ enum {
   CLONE_ISA_2_06,  /* ISA 2.06 (power7).  */
   CLONE_ISA_2_07,  /* ISA 2.07 (power8).  */
   CLONE_ISA_3_00,  /* ISA 3.00 (power9).  */
+  CLONE_ISA_3_1,   /* ISA 3.1 (future).  */
   CLONE_MAX
 };
 
@@ -274,6 +275,7 @@ static const struct clone_map rs6000_clone_map[CLO
   { OPTION_MASK_POPCNTD,   "arch_2_06" },  /* ISA 2.06 (power7).  */
   { OPTION_MASK_P8_VECTOR, "arch_2_07" },  /* ISA 2.07 (power8).  */
   { OPTION_MASK_P9_VECTOR, "arch_3_00" },  /* ISA 3.00 (power9).  */
+  { OPTION_MASK_FUTURE,"arch_3_1" },   /* ISA 3.1 (future).  */
 };
 
 
Index: gcc/testsuite/gcc.target/powerpc/clone3.c
===
--- gcc/testsuite/gcc.target/powerpc/clone3.c   (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/clone3.c   (working copy)
@@ -0,0 +1,33 @@
+/* { dg-do compile { target { powerpc*-*-linux* && lp64 } } } */
+/* { dg-options "-mdejagnu-cpu=power8 -O2" } */
+/* { dg-require-effective-target powerpc_p9vector_ok } */
+/* { dg-require-effective-target ppc_cpu_supports_hw } */
+
+/* Power9 (aka, ISA 3.0) has a MODSD instruction to do modulus, while Power8
+   (aka, ISA 2.07) has to do modulus with divide and multiply.  Make sure
+   both clone functions are generated.
+
+   FUTURE has pc-relative instructions to access static values, while earlier
+   systems used TOC addressing.
+
+   Restrict ourselves to Linux, since IFUNC might not be supported in other
+   operating systems.  */
+
+static long s;
+long *p = 
+
+__attribute__((target_clones("cpu=future,cpu=power9,default")))
+long mod_func (long a, long b)
+{
+  return (a % b) + s;
+}
+
+long mod_func_or (long a, long b, long c)
+{
+  return mod_func (a, b) | c;
+}
+
+/* { dg-final { scan-assembler-times {\mdivd\M}  1 } } */
+/* { dg-final { scan-assembler-times {\mmulld\M} 1 } } */
+/* { dg-final { scan-assembler-times {\mmodsd\M} 2 } } */
+/* { dg-final { scan-assembler-times {\mpld\M}   1 } } */

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, 

Re: [PATCH 0/8] eBPF support for GCC

[Jose E. Marchesi]

> The second patch adds the new GCC port proper.  Machine description,
> implementation of target hooks and macros, command-line options and
> the like.

Looks like [PATCH 2/8] didn't make it to the mailing list for some
reason (maybe it exceeded a size limit?)

Yeah the Oracle smtpmail server seems to not be routing 2/8... how
annoying.  I just sent it again using my GNU account.

[PATCH 2/8] bpf: new GCC port

[Jose E. Marchesi]

This patch adds a port for the Linux kernel eBPF architecture to GCC.

ChangeLog:

  * configure.ac: Support for bpf-*-* targets.
  * configure: Regenerate.

contrib/ChangeLog:

  * config-list.mk (LIST): Disable go in bpf-*-* targets.

gcc/ChangeLog:

  * config.gcc: Support for bpf-*-* targets.
  * common/config/bpf/bpf-common.c: New file.
  * config/bpf/t-bpf: Likewise.
  * config/bpf/predicates.md: Likewise.
  * config/bpf/constraints.md: Likewise.
  * config/bpf/bpf.opt: Likewise.
  * config/bpf/bpf.md: Likewise.
  * config/bpf/bpf.h: Likewise.
  * config/bpf/bpf.c: Likewise.
  * config/bpf/bpf-protos.h: Likewise.
  * config/bpf/bpf-opts.h: Likewise.
  * config/bpf/bpf-helpers.h: Likewise.
  * config/bpf/bpf-helpers.def: Likewise.
---
 ChangeLog  |5 +
 configure  |   68 ++-
 configure.ac   |   54 +-
 contrib/ChangeLog  |4 +
 contrib/config-list.mk |2 +-
 gcc/ChangeLog  |   16 +
 gcc/common/config/bpf/bpf-common.c |   57 ++
 gcc/config.gcc |9 +
 gcc/config/bpf/bpf-helpers.def |  194 ++
 gcc/config/bpf/bpf-helpers.h   |  324 ++
 gcc/config/bpf/bpf-opts.h  |   56 ++
 gcc/config/bpf/bpf-protos.h|   33 ++
 gcc/config/bpf/bpf.c   | 1136 
 gcc/config/bpf/bpf.h   |  565 ++
 gcc/config/bpf/bpf.md  |  528 +
 gcc/config/bpf/bpf.opt |  119 
 gcc/config/bpf/constraints.md  |   29 +
 gcc/config/bpf/predicates.md   |  105 
 gcc/config/bpf/t-bpf   |0
 19 files changed, 3300 insertions(+), 4 deletions(-)
 create mode 100644 gcc/common/config/bpf/bpf-common.c
 create mode 100644 gcc/config/bpf/bpf-helpers.def
 create mode 100644 gcc/config/bpf/bpf-helpers.h
 create mode 100644 gcc/config/bpf/bpf-opts.h
 create mode 100644 gcc/config/bpf/bpf-protos.h
 create mode 100644 gcc/config/bpf/bpf.c
 create mode 100644 gcc/config/bpf/bpf.h
 create mode 100644 gcc/config/bpf/bpf.md
 create mode 100644 gcc/config/bpf/bpf.opt
 create mode 100644 gcc/config/bpf/constraints.md
 create mode 100644 gcc/config/bpf/predicates.md
 create mode 100644 gcc/config/bpf/t-bpf

diff --git a/configure b/configure
index 63b1e33f41c..4f8e68a4085 100755
--- a/configure
+++ b/configure
@@ -754,6 +754,7 @@ infodir
 docdir
 oldincludedir
 includedir
+runstatedir
 localstatedir
 sharedstatedir
 sysconfdir
@@ -919,6 +920,7 @@ datadir='${datarootdir}'
 sysconfdir='${prefix}/etc'
 sharedstatedir='${prefix}/com'
 localstatedir='${prefix}/var'
+runstatedir='${localstatedir}/run'
 includedir='${prefix}/include'
 oldincludedir='/usr/include'
 docdir='${datarootdir}/doc/${PACKAGE}'
@@ -1171,6 +1173,15 @@ do
   | -silent | --silent | --silen | --sile | --sil)
 silent=yes ;;
 
+  -runstatedir | --runstatedir | --runstatedi | --runstated \
+  | --runstate | --runstat | --runsta | --runst | --runs \
+  | --run | --ru | --r)
+ac_prev=runstatedir ;;
+  -runstatedir=* | --runstatedir=* | --runstatedi=* | --runstated=* \
+  | --runstate=* | --runstat=* | --runsta=* | --runst=* | --runs=* \
+  | --run=* | --ru=* | --r=*)
+runstatedir=$ac_optarg ;;
+
   -sbindir | --sbindir | --sbindi | --sbind | --sbin | --sbi | --sb)
 ac_prev=sbindir ;;
   -sbindir=* | --sbindir=* | --sbindi=* | --sbind=* | --sbin=* \
@@ -1308,7 +1319,7 @@ fi
 for ac_var in  exec_prefix prefix bindir sbindir libexecdir datarootdir \
datadir sysconfdir sharedstatedir localstatedir includedir \
oldincludedir docdir infodir htmldir dvidir pdfdir psdir \
-   libdir localedir mandir
+   libdir localedir mandir runstatedir
 do
   eval ac_val=\$$ac_var
   # Remove trailing slashes.
@@ -1468,6 +1479,7 @@ Fine tuning of the installation directories:
   --sysconfdir=DIRread-only single-machine data [PREFIX/etc]
   --sharedstatedir=DIRmodifiable architecture-independent data [PREFIX/com]
   --localstatedir=DIR modifiable single-machine data [PREFIX/var]
+  --runstatedir=DIR   modifiable per-process data [LOCALSTATEDIR/run]
   --libdir=DIRobject code libraries [EPREFIX/lib]
   --includedir=DIRC header files [PREFIX/include]
   --oldincludedir=DIR C header files for non-gcc [/usr/include]
@@ -3353,6 +3365,9 @@ case "${target}" in
 # No hosted I/O support.
 noconfigdirs="$noconfigdirs target-libssp"
 ;;
+  bpf-*-*)
+noconfigdirs="$noconfigdirs target-libssp"
+;;
   powerpc-*-aix* | rs6000-*-aix*)
 noconfigdirs="$noconfigdirs target-libssp"
 ;;
@@ -3387,12 +3402,43 @@ if test "${ENABLE_LIBSTDCXX}" = "default" ; then
 avr-*-*)
   noconfigdirs="$noconfigdirs target-libstdc++-v3"
   ;;
+bpf-*-*)
+  noconfigdirs="$noconfigdirs target-libstdc++-v3"
+  ;;
 ft32-*-*)
   noconfigdirs="$noconfigdirs target-libstdc++-v3"
 

Re: [PATCHv4] Fix not 8-byte aligned ldrd/strd on ARMv5 (PR 89544)

[Bernd Edlinger]

On 8/14/19 2:00 PM, Richard Biener wrote:
> On Thu, 8 Aug 2019, Bernd Edlinger wrote:
> 
>> On 8/2/19 9:01 PM, Bernd Edlinger wrote:
>>> On 8/2/19 3:11 PM, Richard Biener wrote:
 On Tue, 30 Jul 2019, Bernd Edlinger wrote:

>
> I have no test coverage for the movmisalign optab though, so I
> rely on your code review for that part.

 It looks OK.  I tried to make it trigger on the following on
 i?86 with -msse2:

 typedef int v4si __attribute__((vector_size (16)));

 struct S { v4si v; } __attribute__((packed));

 v4si foo (struct S s)
 {
   return s.v;
 }

>>>
>>> Hmm, the entry_parm need to be a MEM_P and an unaligned one.
>>> So the test case could be made to trigger it this way:
>>>
>>> typedef int v4si __attribute__((vector_size (16)));
>>>
>>> struct S { v4si v; } __attribute__((packed));
>>>
>>> int t;
>>> v4si foo (struct S a, struct S b, struct S c, struct S d,
>>>   struct S e, struct S f, struct S g, struct S h,
>>>   int i, int j, int k, int l, int m, int n,
>>>   int o, struct S s)
>>> {
>>>   t = o;
>>>   return s.v;
>>> }
>>>
>>
>> Ah, I realized that there are already a couple of very similar
>> test cases: gcc.target/i386/pr35767-1.c, gcc.target/i386/pr35767-1d.c,
>> gcc.target/i386/pr35767-1i.c and gcc.target/i386/pr39445.c,
>> which also manage to execute the movmisalign code with the latest patch
>> version.  So I thought that it is not necessary to add another one.
>>
>>> However the code path is still not reached, since 
>>> targetm.slow_ualigned_access
>>> is always FALSE, which is probably a flaw in my patch.
>>>
>>> So I think,
>>>
>>> +  else if (MEM_P (data->entry_parm)
>>> +  && GET_MODE_ALIGNMENT (promoted_nominal_mode)
>>> + > MEM_ALIGN (data->entry_parm)
>>> +  && targetm.slow_unaligned_access (promoted_nominal_mode,
>>> +MEM_ALIGN (data->entry_parm)))
>>>
>>> should probably better be
>>>
>>> +  else if (MEM_P (data->entry_parm)
>>> +  && GET_MODE_ALIGNMENT (promoted_nominal_mode)
>>> + > MEM_ALIGN (data->entry_parm)
>>> +&& (((icode = optab_handler (movmisalign_optab, 
>>> promoted_nominal_mode))
>>> + != CODE_FOR_nothing)
>>> +|| targetm.slow_unaligned_access (promoted_nominal_mode,
>>> +  MEM_ALIGN 
>>> (data->entry_parm
>>>
>>> Right?
>>>
>>> Then the modified test case would use the movmisalign optab.
>>> However nothing changes in the end, since the i386 back-end is used to work
>>> around the middle end not using movmisalign optab when it should do so.
>>>
>>
>> I prefer the second form of the check, as it offers more test coverage,
>> and is probably more correct than the former.
>>
>> Note there are more variations of this misalign check in expr.c,
>> some are somehow odd, like expansion of MEM_REF and VIEW_CONVERT_EXPR:
>>
>> && mode != BLKmode
>> && align < GET_MODE_ALIGNMENT (mode))
>>   {
>> if ((icode = optab_handler (movmisalign_optab, mode))
>> != CODE_FOR_nothing)
>>   [...]
>> else if (targetm.slow_unaligned_access (mode, align))
>>   temp = extract_bit_field (temp, GET_MODE_BITSIZE (mode),
>> 0, TYPE_UNSIGNED (TREE_TYPE (exp)),
>> (modifier == EXPAND_STACK_PARM
>>  ? NULL_RTX : target),
>> mode, mode, false, alt_rtl);
>>
>> I wonder if they are correct this way, why shouldn't we use the movmisalign
>> optab if it exists, regardless of TARGET_SLOW_UNALIGNED_ACCESSS ?
> 
> Doesn't the code do exactly this?  Prefer movmisalign over 
> extrct_bit_field?
> 

Ah, yes.  How could I miss that.

>>
>>> I wonder if I should try to add a gcc_checking_assert to the mov 
>>> expand
>>> patterns that the memory is properly aligned ?
>>>
>>
>> Wow, that was a really exciting bug-hunt with those assertions around...
> 
> :)
> 
 @@ -3292,6 +3306,23 @@ assign_parm_setup_reg (struct assign_parm_data_all

did_conversion = true;
  }
 +  else if (MEM_P (data->entry_parm)
 +  && GET_MODE_ALIGNMENT (promoted_nominal_mode)
 + > MEM_ALIGN (data->entry_parm)

 we arrive here by-passing

   else if (need_conversion)
 {
   /* We did not have an insn to convert directly, or the sequence
  generated appeared unsafe.  We must first copy the parm to a
  pseudo reg, and save the conversion until after all
  parameters have been moved.  */

   int save_tree_used;
   rtx tempreg = gen_reg_rtx (GET_MODE (data->entry_parm));

   emit_move_insn (tempreg, validated_mem);

 but this move instruction is invalid in the 

[PATCH], Patch #5 of 10, Make -mpcrel default for -mcpu=future

[Michael Meissner]

This patch changes the default for -mcpu=future to turn on pc-relative
addressing by default.

I have built each of the patches in turn on a little endian power8 system doing
a bootstrap and make check.  There were no regressions.  Can I check this patch
into the trunk once the previous patches are checked in?

2019-08-14   Michael Meissner  

* config/rs6000/rs6000-cpus.def (ISA_FUTURE_MASKS_SERVER): Enable
pc-relative support by default on 'future' systems.

Index: gcc/config/rs6000/rs6000-cpus.def
===
--- gcc/config/rs6000/rs6000-cpus.def   (revision 274173)
+++ gcc/config/rs6000/rs6000-cpus.def   (working copy)
@@ -75,10 +75,10 @@
 | OPTION_MASK_P8_VECTOR\
 | OPTION_MASK_P9_VECTOR)
 
-/* Support for a future processor's features.  Do not enable -mpcrel until it
-   is fully functional.  */
+/* Support for a future processor's features.  */
 #define ISA_FUTURE_MASKS_SERVER(ISA_3_0_MASKS_SERVER   
\
 | OPTION_MASK_FUTURE   \
+| OPTION_MASK_PCREL\
 | OPTION_MASK_PREFIXED_ADDR)
 
 /* Flags that need to be turned off if -mno-future.  */

-- 
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 0/8] eBPF support for GCC

[David Malcolm]

On Wed, 2019-08-14 at 23:36 +0200, Jose E. Marchesi wrote:
> Hi people!
> 

[...]

> The second patch adds the new GCC port proper.  Machine description,
> implementation of target hooks and macros, command-line options and
> the like.

Looks like [PATCH 2/8] didn't make it to the mailing list for some
reason (maybe it exceeded a size limit?)

[...]

Dave

[PATCH], Patch #4 of 10, Adjust costs based on insn sizes

[Michael Meissner]

Some of the cost functions in the PowerPC compiler uses the length of the
instruction to factor in the costs.  This patches adjusts this calculation so
that prefixed instructions are treated as the same cost as non-prefixed
instructions.

I forgot to mention in the previous patchs, all 10 of the patches have been
bootstrapped on a little endian power8 system in progression, and there were no
regressions.  Once the previous patches have been checked in, can I check this
patch into the trunk?

2019-08-14   Michael Meissner  

* config/rs6000/rs6000.c (rs6000_num_insns): New function.
(rs6000_insn_cost): Use rs6000_num_insns to treat prefixed
load/store instructions with the same case as non-prefixed
instructions.

Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 274177)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -21369,7 +21369,43 @@ rs6000_debug_rtx_costs (rtx x, machine_mode mode,
   return ret;
 }
 
+/* How many real instructions are generated for this insn?  This is slightly
+   different from the length attribute, in that the length attribute counts the
+   number of bytes.  With prefixed instructions, we don't want to count a
+   prefixed instruction (length 12 bytes including possible NOP) as taking 3
+   instructions, but just one.  */
+
 static int
+rs6000_num_insns (rtx_insn *insn)
+{
+  /* Try to figure it out based on the length and whether there are prefixed
+ instructions.  While prefixed instructions are only 8 bytes, we have to
+ use 12 as the size of the first prefixed instruction in case the
+ instruction needs to be aligned.  Back to back prefixed instructions would
+ only take 20 bytes, since it is guaranteed that one of the prefixed
+ instructions does not need the alignment.  */
+  int length = get_attr_length (insn);
+
+  if (length >= 12 && TARGET_PREFIXED_ADDR
+  && get_attr_prefixed (insn) == PREFIXED_YES)
+{
+  /* Single prefixed instruction.  */
+  if (length == 12)
+   return 1;
+
+  /* A normal instruction and a prefixed instruction (16) or two back
+to back prefixed instructions (20).  */
+  if (length == 16 || length == 20)
+   return 2;
+
+  /* Guess for larger instruction sizes.  */
+  return 2 + (length - 20) / 4;
+}
+
+  return length / 4;
+}
+
+static int
 rs6000_insn_cost (rtx_insn *insn, bool speed)
 {
   if (recog_memoized (insn) < 0)
@@ -21382,7 +21418,7 @@ rs6000_insn_cost (rtx_insn *insn, bool speed)
   if (cost > 0)
 return cost;
 
-  int n = get_attr_length (insn) / 4;
+  int n = rs6000_num_insns (insn);
   enum attr_type type = get_attr_type (insn);
 
   switch (type)

-- 
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], Patch #3 of 10, Add prefixed addressing support

[Michael Meissner]

This patch adds prefixed memory support to all offsettable instructions.

Unlike previous versions of the patch, this patch combines all of the
modifications for addressing to one patch.  Previously, I had 3 separate
patches (one for PADDI, one for scalar types, and one for vector types).

2019-08-14   Michael Meissner  

* config/rs6000/predicates.md (add_operand): Add support for the
PADDI instruction.
(non_add_cint_operand): Add support for the PADDI instruction.
(lwa_operand): Add support for the prefixed PLWA instruction.
* config/rs6000/rs6000.c (rs6000_hard_regno_mode_ok_uncached):
Only treat modes < 16 bytes as scalars.
(rs6000_debug_print_mode): Print whether the mode supports
prefixed addressing.
(setup_insn_form): Enable prefixed addressing for all modes whose
default instruction form includes offset addressing.
(num_insns_constant_gpr): Add support for the PADDI instruction.
(quad_address_p): Add support for prefixed addressing.
(mem_operand_gpr): Add support for prefixed addressing.
(mem_operand_ds_form): Add support for prefixed addressing.
(rs6000_legitimate_offset_address_p): Add support for prefixed
addressing.
(rs6000_legitimate_address_p): Add support for prefixed
addressing.
(rs6000_mode_dependent_address): Add support for prefixed
addressing.
(rs6000_rtx_costs): Make PADDI cost the same as ADDI or ADDIS.
* config/rs6000/rs6000.md (add3): Add support for PADDI.
(movsi_internal1): Add support for prefixed addressing, and using
PADDI to load up large integers.
(movsi splitter): Do not split up a PADDI instruction.
(mov_64bit_dm): Add support for prefixed addressing.
(movtd_64bit_nodm): Add support for prefixed addressing.
(movdi_internal64): Add support for prefixed addressing, and using
PADDI to load up large integers.
(movdi splitter): Update comment about PADDI.
(stack_protect_setdi): Add support for prefixed addressing.
(stack_protect_testdi): Add support for prefixed addressing.
* config/rs6000/vsx.md (vsx_mov_64bit): Add support for
prefixed addressing.
(vsx_extract___load): Add support for prefixed
addressing.
(vsx_extract___load): Add support for prefixed
addressing.

Index: gcc/config/rs6000/predicates.md
===
--- gcc/config/rs6000/predicates.md (revision 274174)
+++ gcc/config/rs6000/predicates.md (working copy)
@@ -839,7 +839,8 @@
 (define_predicate "add_operand"
   (if_then_else (match_code "const_int")
 (match_test "satisfies_constraint_I (op)
-|| satisfies_constraint_L (op)")
+|| satisfies_constraint_L (op)
+|| satisfies_constraint_eI (op)")
 (match_operand 0 "gpc_reg_operand")))
 
 ;; Return 1 if the operand is either a non-special register, or 0, or -1.
@@ -852,7 +853,8 @@
 (define_predicate "non_add_cint_operand"
   (and (match_code "const_int")
(match_test "!satisfies_constraint_I (op)
-   && !satisfies_constraint_L (op)")))
+   && !satisfies_constraint_L (op)
+   && !satisfies_constraint_eI (op)")))
 
 ;; Return 1 if the operand is a constant that can be used as the operand
 ;; of an AND, OR or XOR.
@@ -933,6 +935,13 @@
 return false;
 
   addr = XEXP (inner, 0);
+
+  /* The LWA instruction uses the DS-form format where the bottom two bits of
+ the offset must be 0.  The prefixed PLWA does not have this
+ restriction.  */
+  if (prefixed_local_addr_p (addr, mode, INSN_FORM_DS))
+return true;
+
   if (GET_CODE (addr) == PRE_INC
   || GET_CODE (addr) == PRE_DEC
   || (GET_CODE (addr) == PRE_MODIFY
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 274175)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -1828,7 +1828,7 @@ rs6000_hard_regno_mode_ok_uncached (int regno, mac
 
   if (ALTIVEC_REGNO_P (regno))
{
- if (GET_MODE_SIZE (mode) != 16 && !reg_addr[mode].scalar_in_vmx_p)
+ if (GET_MODE_SIZE (mode) < 16 && !reg_addr[mode].scalar_in_vmx_p)
return 0;
 
  return ALTIVEC_REGNO_P (last_regno);
@@ -2146,6 +2146,11 @@ rs6000_debug_print_mode (ssize_t m)
   rs6000_debug_insn_form (reg_addr[m].insn_form[RELOAD_REG_FPR]),
   rs6000_debug_insn_form (reg_addr[m].insn_form[RELOAD_REG_VMX]));
 
+  if (reg_addr[m].prefixed_memory_p)
+fprintf (stderr, "  Prefix");
+  else
+spaces += sizeof ("  Prefix") - 1;
+
   if ((reg_addr[m].reload_store != CODE_FOR_nothing)
   || (reg_addr[m].reload_load != CODE_FOR_nothing))
 {
@@ -2838,11 +2843,16 @@ setup_insn_form (void)
   else
def_rc = RELOAD_REG_GPR;
 
-  

[PATCH], Patch #2 of 10, Add RTL prefixed attribute

[Michael Meissner]

This patch adds the RTL attribute "prefixed" that says this particular
instruction is a prefixed instruction.

The target hooks FINAL_SCAN_INSN and ASM_OUTPUT_OPCODE are defined.  If the
insn is prefixed, ASM_OUTPUT_OPCODE will emit a leading 'p' before the
instruction is emitted.  For example, a load word and zero extend instruction
would have the output template:

lwz%U1%X1 %0,%1

If the insn is prefixed, ASM_OUTPUT_OPCODE will emit the leading 'p' and the
assembler would see something like:

plwz 3,foo@pcrel

The RTL length attribute looks a the RTL prefixed attribute to set the default
length to either 4 or 12.

In order to simplify setting the length for complex insns that aren't yet
split, I have added two new RTL attributes ("non_prefixed_length" and
"prefixed_length") that the length attribute uses.  Normally these values would
be 4 and 12 bytes, unless this is overwritten by the insn attributes.

In previous versions of the patch, I had a maybe_prefixed attribute that was
used to say this instruction might be prefixed, and to check whether the
instruction was prefixed externally.  Now, I use the type RTL attribute, and I
only look if the type is one of the load types, one of the store types, or one
of the integer and add types.

Due to some of the existing load and store insns not using the traditional
operands[0] and operands[1], the functions that test whether an insn is
prefixed only use the insn and not the operands directly.

Most of the new  code is in a new file (rs6000-prefixed.c).

2019-08-14   Michael Meissner  

* config/rs6000/rs6000-prefixed.c: New file.
* config/rs6000/rs6000-protos.h (rs6000_final_prescan_insn):
Update calling signature.
(prefixed_load_p): New function.
(prefixed_store_p): New function.
(prefixed_paddi_p): New function.
* config/rs6000/rs6000.c (rs6000_emit_move): Add support for
loading up pc-relatve addresses.
* config/rs6000/rs6000.h (FINAL_SCAN_INSN): New target hook.
(ASM_OUTPUT_OPCODE): New target hook.
* config/rs6000/rs6000.md (prefixed attribute): New attribute.
(prefixed_length attribute): New attribute.
(non_prefixed_length attribute): New attribute.
(length attribute): Calculate length in terms of the prefixed,
prefixed_length, and non_prefixed_length attributes.
(pcrel_addr): New insn for pc-relative support.
(pcrel_ext_addr): New insn for pc-relative support.
* config/rs6000/t-rs6000 (rs6000-prefixed.o): Add build rule.
* config.gcc (powerpc*-*-*): Add rs6000-prefixed.c.
(rs6000*-*-*): Add rs6000-prefixed.c.

Index: gcc/config/rs6000/rs6000-prefixed.c
===
--- gcc/config/rs6000/rs6000-prefixed.c (revision 0)
+++ gcc/config/rs6000/rs6000-prefixed.c (working copy)
@@ -0,0 +1,188 @@
+/* Subroutines used to support prefixed addressing on the PowerPC.
+   Copyright (C) 2019 Free Software Foundation, Inc.
+
+   This file is part of GCC.
+
+   GCC 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.
+
+   GCC 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.
+
+   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"
+#include "backend.h"
+#include "rtl.h"
+#include "tree.h"
+#include "memmodel.h"
+#include "df.h"
+#include "tm_p.h"
+#include "ira.h"
+#include "print-tree.h"
+#include "varasm.h"
+#include "explow.h"
+#include "expr.h"
+#include "output.h"
+#include "tree-pass.h"
+#include "rtx-vector-builder.h"
+#include "print-rtl.h"
+#include "insn-attr.h"
+#include "insn-config.h"
+#include "recog.h"
+#include "tm-constrs.h"
+
+/* Whether the next instruction needs a 'p' prefix issued before the
+   instruction is printed out.  */
+static bool next_insn_prefixed_p;
+
+/* Define FINAL_PRESCAN_INSN if some processing needs to be done before
+   outputting the assembler code.  On the PowerPC, we remember if the current
+   insn is a prefixed insn where we need to emit a 'p' before the insn.  */
+void
+rs6000_final_prescan_insn (rtx_insn *insn)
+{
+  next_insn_prefixed_p = (get_attr_prefixed (insn) != PREFIXED_NO);
+  return;
+}
+
+/* Define ASM_OUTPUT_OPCODE to do anything special before emitting an opcode.
+   We use it to emit a 'p' for prefixed insns that is set in
+   FINAL_PRESCAN_INSN.  We also use it for PCREL_OPT to emit the relocation
+   that ties the load of the GOT 

[PATCH 6/8] bpf: adjust GCC testsuite to eBPF limitations

[Jose E. Marchesi]

This patch makes many tests in gcc.dg and gcc.c-torture to be skipped
in bpf-*-* targets.  This is due to the many limitations imposed by
eBPF to what would be perfectly valid C code: no support for indirect
calls, no support for more than 5 arguments to function calls, no
support for indirect jumps, a very limited range for direct jumps, the
stack limit, lack of standard header files, etc.

Hopefully some of these restrictions will be relaxed in the future.
In particular, I expect the stack limit will be significantly
increased at some point.  Also, as semantics associated with object
linking get developed in eBPF, it may be possible at some point to
provide a set of standard run-time libraries for eBPF programs.

gcc/testsuite/ChangeLog:

* gcc.dg/builtins-config.h: eBPF doesn't support C99 standard
functions.
* gcc.c-torture/compile/2211-1.c: Skip if target bpf-*-*.
* gcc.c-torture/compile/2403-1.c: Likewise.
* gcc.c-torture/compile/2609-1.c: Likewise.
* gcc.c-torture/compile/2804-1.c: Likewise.
* gcc.c-torture/compile/20001226-1.c: Likewise.
* gcc.c-torture/compile/20010102-1.c: Likewise.
* gcc.c-torture/compile/20010107-1.c: Likewise.
* gcc.c-torture/compile/20011109-1.c: Likewise.
* gcc.c-torture/compile/20011218-1.c: Likewise.
* gcc.c-torture/compile/20011229-1.c: Likewise.
* gcc.c-torture/compile/20020129-1.c: Likewise.
* gcc.c-torture/compile/20020304-1.c: Likewise.
* gcc.c-torture/compile/20020320-1.c: Likewise.
* gcc.c-torture/compile/20020604-1.c: Likewise.
* gcc.c-torture/compile/20020706-1.c: Likewise.
* gcc.c-torture/compile/20020706-2.c: Likewise.
* gcc.c-torture/compile/20021015-1.c: Likewise.
* gcc.c-torture/compile/20021205-1.c: Likewise.
* gcc.c-torture/compile/20030903-1.c: Likewise.
* gcc.c-torture/compile/20030921-1.c: Likewise.
* gcc.c-torture/compile/20031023-1.c: Likewise.
* gcc.c-torture/compile/20031023-2.c: Likewise.
* gcc.c-torture/compile/20031023-3.c: Likewise.
* gcc.c-torture/compile/20031023-4.c: Likewise.
* gcc.c-torture/compile/20031125-1.c: Likewise.
* gcc.c-torture/compile/20040101-1.c: Likewise.
* gcc.c-torture/compile/20040317-2.c: Likewise.
* gcc.c-torture/compile/20040614-1.c: Likewise.
* gcc.c-torture/compile/20040726-1.c: Likewise.
* gcc.c-torture/compile/20040909-1.c: Likewise.
* gcc.c-torture/compile/20050122-1.c: Likewise.
* gcc.c-torture/compile/20050202-1.c: Likewise.
* gcc.c-torture/compile/20050303-1.c: Likewise.
* gcc.c-torture/compile/20050622-1.c: Likewise.
* gcc.c-torture/compile/20051216-1.c: Likewise.
* gcc.c-torture/compile/20060208-1.c: Likewise.
* gcc.c-torture/compile/20060421-1.c: Likewise.
* gcc.c-torture/compile/20071207-1.c: Likewise.
* gcc.c-torture/compile/20080903-1.c: Likewise.
* gcc.c-torture/compile/20081108-1.c: Likewise.
* gcc.c-torture/compile/20101217-1.c: Likewise.
* gcc.c-torture/compile/20121027-1.c: Likewise.
* gcc.c-torture/compile/20150327.c: Likewise.
* gcc.c-torture/compile/20151204.c: Likewise.
* gcc.c-torture/compile/900313-1.c: Likewise.
* gcc.c-torture/compile/920428-2.c: Likewise.
* gcc.c-torture/compile/920501-12.c: Likewise.
* gcc.c-torture/compile/920501-4.c: Likewise.
* gcc.c-torture/compile/920501-7.c: Likewise.
* gcc.c-torture/compile/920625-1.c: Likewise.
* gcc.c-torture/compile/920723-1.c: Likewise.
* gcc.c-torture/compile/920928-5.c: Likewise.
* gcc.c-torture/compile/921202-1.c: Likewise.
* gcc.c-torture/compile/930117-1.c: Likewise.
* gcc.c-torture/compile/930421-1.c: Likewise.
* gcc.c-torture/compile/930607-1.c: Likewise.
* gcc.c-torture/compile/930623-1.c: Likewise.
* gcc.c-torture/compile/931003-1.c: Likewise.
* gcc.c-torture/compile/931004-1.c: Likewise.
* gcc.c-torture/compile/950719-1.c: Likewise.
* gcc.c-torture/compile/951222-1.c: Likewise.
* gcc.c-torture/compile/961004-1.c: Likewise.
* gcc.c-torture/compile/980504-1.c: Likewise.
* gcc.c-torture/compile/980816-1.c: Likewise.
* gcc.c-torture/compile/990517-1.c: Likewise.
* gcc.c-torture/compile/990625-1.c: Likewise.
* gcc.c-torture/compile/991213-2.c: Likewise.
* gcc.c-torture/compile/DFcmp.c: Likewise.
* gcc.c-torture/compile/HIcmp.c: Likewise.
* gcc.c-torture/compile/HIset.c: Likewise.
* gcc.c-torture/compile/QIcmp.c: Likewise.
* gcc.c-torture/compile/QIset.c: Likewise.
* gcc.c-torture/compile/SFset.c: Likewise.
* gcc.c-torture/compile/SIcmp.c: Likewise.
* gcc.c-torture/compile/SIset.c: Likewise.
* 

[PATCH 7/8] bpf: manual updates for eBPF

[Jose E. Marchesi]

gcc/ChangeLog:

* doc/invoke.texi (Option Summary): Cover eBPF.
(eBPF Options): New section.
* doc/extend.texi (BPF Built-in Functions): Likewise.
(BPF Kernel Helpers): Likewise.
---
 gcc/ChangeLog   |   7 +++
 gcc/doc/extend.texi | 171 
 gcc/doc/invoke.texi |  30 +
 3 files changed, 208 insertions(+)

diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 1666972d5eb..554ce452000 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -13595,6 +13595,8 @@ instructions, but allow the compiler to schedule those 
calls.
 * ARM ARMv8-M Security Extensions::
 * AVR Built-in Functions::
 * Blackfin Built-in Functions::
+* BPF Built-in Functions::
+* BPF Kernel Helpers::
 * FR-V Built-in Functions::
 * MIPS DSP Built-in Functions::
 * MIPS Paired-Single Support::
@@ -14592,6 +14594,175 @@ void __builtin_bfin_csync (void)
 void __builtin_bfin_ssync (void)
 @end smallexample
 
+@node BPF Built-in Functions
+@subsection BPF Built-in Functions
+
+The following built-in functions are available for eBPF targets.
+
+@deftypefn {Built-in Function} unsigned long long __builtin_bpf_load_byte 
(unsigned long long @var{offset})
+Load a byte from the @code{struct sk_buff} packet data pointed by the register 
@code{%r6} and return it.
+@end deftypefn
+
+@deftypefn {Built-in Function} unsigned long long __builtin_bpf_load_half 
(unsigned long long @var{offset})
+Load 16-bits from the @code{struct sk_buff} packet data pointed by the 
register @code{%r6} and return it.
+@end deftypefn
+
+@deftypefn {Built-in Function} unsigned long long __builtin_bpf_load_word 
(unsigned long long @var{offset})
+Load 32-bits from the @code{struct sk_buff} packet data pointed by the 
register @code{%r6} and return it.
+@end deftypefn
+
+@node BPF Kernel Helpers
+@subsection BPF Kernel Helpers
+
+These built-in functions are available for calling kernel helpers, and
+they are available depending on the kernel version selected as the
+CPU.
+
+Rather than using the built-ins directly, it is preferred for programs
+to include @file{bpf-helpers.h} and use the wrappers defined there.
+
+For a full description of what the helpers do, the arguments they
+take, and the returned value, see the
+@file{linux/include/uapi/linux/bpf.h} in a Linux source tree.
+
+@smallexample
+void *__builtin_bpf_helper_map_lookup_elem (void *map, void *key)
+int   __builtin_bpf_helper_map_update_elem (void *map, void *key,
+void *value,
+unsigned long long flags)
+int   __builtin_bpf_helper_map_delete_elem (void *map, const void *key)
+int   __builtin_bpf_helper_map_push_elem (void *map, const void *value,
+  unsigned long long flags)
+int   __builtin_bpf_helper_map_pop_elem (void *map, void *value)
+int   __builtin_bpf_helper_map_peek_elem (void *map, void *value)
+int __builtin_bpf_helper_clone_redirect (void *skb,
+ unsigned int ifindex,
+ unsigned long long flags)
+int __builtin_bpf_helper_skb_get_tunnel_key (void *ctx, void *key, int size, 
int flags)
+int __builtin_bpf_helper_skb_set_tunnel_key (void *ctx, void *key, int size, 
int flags)
+int __builtin_bpf_helper_skb_get_tunnel_opt (void *ctx, void *md, int size)
+int __builtin_bpf_helper_skb_set_tunnel_opt (void *ctx, void *md, int size)
+int __builtin_bpf_helper_skb_get_xfrm_state (void *ctx, int index, void *state,
+int size, int flags)
+static unsigned long long __builtin_bpf_helper_skb_cgroup_id (void *ctx)
+static unsigned long long __builtin_bpf_helper_skb_ancestor_cgroup_id
+ (void *ctx, int level)
+int __builtin_bpf_helper_skb_vlan_push (void *ctx, __be16 vlan_proto, __u16 
vlan_tci)
+int __builtin_bpf_helper_skb_vlan_pop (void *ctx)
+int __builtin_bpf_helper_skb_ecn_set_ce (void *ctx)
+
+int __builtin_bpf_helper_skb_load_bytes (void *ctx, int off, void *to, int len)
+int __builtin_bpf_helper_skb_load_bytes_relative (void *ctx, int off, void 
*to, int len, __u32 start_header)
+int __builtin_bpf_helper_skb_store_bytes (void *ctx, int off, void *from, int 
len, int flags)
+int __builtin_bpf_helper_skb_under_cgroup (void *ctx, void *map, int index)
+int __builtin_bpf_helper_skb_change_head (void *, int len, int flags)
+int __builtin_bpf_helper_skb_pull_data (void *, int len)
+int __builtin_bpf_helper_skb_change_proto (void *ctx, __be16 proto, __u64 
flags)
+int __builtin_bpf_helper_skb_change_type (void *ctx, __u32 type)
+int __builtin_bpf_helper_skb_change_tail (void *ctx, __u32 len, __u64 flags)
+int __builtin_bpf_helper_skb_adjust_room (void *ctx, __s32 len_diff, __u32 
mode,
+ unsigned long long flags)
+@end smallexample
+
+Other helpers:
+
+@smallexample
+int __builtin_bpf_helper_probe_read 

[PATCH 4/8] bpf: gcc.target eBPF testsuite

[Jose E. Marchesi]

This patch adds a new testsuite to gcc.target, with eBPF specific
tests.

Tests are included for:
- Target specific diagnostics.
- All built-in functions.

testsuite/ChangeLog:

* gcc.target/bpf/bpf.exp: New file.
* gcc.target/bpf/builtin-load.c: Likewise.
* cc.target/bpf/constant-calls.c: Likewise.
* gcc.target/bpf/diag-funargs.c: Likewise.
* cc.target/bpf/diag-indcalls.c: Likewise.
* gcc.target/bpf/helper-bind.c: Likewise.
* cc.target/bpf/helper-bpf-redirect.c: Likewise.
* gcc.target/bpf/helper-clone-redirect.c: Likewise.
* gcc.target/bpf/helper-csum-diff.c: Likewise.
* gcc.target/bpf/helper-csum-update.c: Likewise.
* gcc.target/bpf/helper-current-task-under-cgroup.c: Likewise.
* gcc.target/bpf/helper-fib-lookup.c: Likewise.
* gcc.target/bpf/helper-get-cgroup-classid.c: Likewise.
* gcc.target/bpf/helper-get-current-cgroup-id.c: Likewise.
* gcc.target/bpf/helper-get-current-comm.c: Likewise.
* gcc.target/bpf/helper-get-current-pid-tgid.c: Likewise.
* gcc.target/bpf/helper-get-current-task.c: Likewise.
* gcc.target/bpf/helper-get-current-uid-gid.c: Likewise.
* gcc.target/bpf/helper-get-hash-recalc.c: Likewise.
* gcc.target/bpf/helper-get-listener-sock.c: Likewise.
* gcc.target/bpf/helper-get-local-storage.c: Likewise.
* gcc.target/bpf/helper-get-numa-node-id.c: Likewise.
* gcc.target/bpf/helper-get-prandom-u32.c: Likewise.
* gcc.target/bpf/helper-get-route-realm.c: Likewise.
* gcc.target/bpf/helper-get-smp-processor-id.c: Likewise.
* gcc.target/bpf/helper-get-socket-cookie.c: Likewise.
* gcc.target/bpf/helper-get-socket-uid.c: Likewise.
* gcc.target/bpf/helper-getsockopt.c: Likewise.
* gcc.target/bpf/helper-get-stack.c: Likewise.
* gcc.target/bpf/helper-get-stackid.c: Likewise.
* gcc.target/bpf/helper-ktime-get-ns.c: Likewise.
* gcc.target/bpf/helper-l3-csum-replace.c: Likewise.
* gcc.target/bpf/helper-l4-csum-replace.c: Likewise.
* gcc.target/bpf/helper-lwt-push-encap.c: Likewise.
* gcc.target/bpf/helper-lwt-seg6-action.c: Likewise.
* gcc.target/bpf/helper-lwt-seg6-adjust-srh.c: Likewise.
* gcc.target/bpf/helper-lwt-seg6-store-bytes.c: Likewise.
* gcc.target/bpf/helper-map-delete-elem.c: Likewise.
* gcc.target/bpf/helper-map-lookup-elem.c: Likewise.
* gcc.target/bpf/helper-map-peek-elem.c: Likewise.
* gcc.target/bpf/helper-map-pop-elem.c: Likewise.
* gcc.target/bpf/helper-map-push-elem.c: Likewise.
* gcc.target/bpf/helper-map-update-elem.c: Likewise.
* gcc.target/bpf/helper-msg-apply-bytes.c: Likewise.
* gcc.target/bpf/helper-msg-cork-bytes.c: Likewise.
* gcc.target/bpf/helper-msg-pop-data.c: Likewise.
* gcc.target/bpf/helper-msg-pull-data.c: Likewise.
* gcc.target/bpf/helper-msg-push-data.c: Likewise.
* gcc.target/bpf/helper-msg-redirect-hash.c: Likewise.
* gcc.target/bpf/helper-msg-redirect-map.c: Likewise.
* gcc.target/bpf/helper-override-return.c: Likewise.
* gcc.target/bpf/helper-perf-event-output.c: Likewise.
* gcc.target/bpf/helper-perf-event-read.c: Likewise.
* gcc.target/bpf/helper-perf-event-read-value.c: Likewise.
* gcc.target/bpf/helper-perf-prog-read-value.c: Likewise.
* gcc.target/bpf/helper-probe-read.c: Likewise.
* gcc.target/bpf/helper-probe-read-str.c: Likewise.
* gcc.target/bpf/helper-probe-write-user.c: Likewise.
* gcc.target/bpf/helper-rc-keydown.c: Likewise.
* gcc.target/bpf/helper-rc-pointer-rel.c: Likewise.
* gcc.target/bpf/helper-rc-repeat.c: Likewise.
* gcc.target/bpf/helper-redirect-map.c: Likewise.
* gcc.target/bpf/helper-set-hash.c: Likewise.
* gcc.target/bpf/helper-set-hash-invalid.c: Likewise.
* gcc.target/bpf/helper-setsockopt.c: Likewise.
* gcc.target/bpf/helper-skb-adjust-room.c: Likewise.
* gcc.target/bpf/helper-skb-cgroup-id.c: Likewise.
* gcc.target/bpf/helper-skb-change-head.c: Likewise.
* gcc.target/bpf/helper-skb-change-proto.c: Likewise.
* gcc.target/bpf/helper-skb-change-tail.c: Likewise.
* gcc.target/bpf/helper-skb-change-type.c: Likewise.
* gcc.target/bpf/helper-skb-ecn-set-ce.c: Likewise.
* gcc.target/bpf/helper-skb-get-tunnel-key.c: Likewise.
* gcc.target/bpf/helper-skb-get-tunnel-opt.c: Likewise.
* gcc.target/bpf/helper-skb-get-xfrm-state.c: Likewise.
* gcc.target/bpf/helper-skb-load-bytes.c: Likewise.
* gcc.target/bpf/helper-skb-load-bytes-relative.c: Likewise.
* gcc.target/bpf/helper-skb-pull-data.c: Likewise.
* gcc.target/bpf/helper-skb-set-tunnel-key.c: Likewise.
* gcc.target/bpf/helper-skb-set-tunnel-opt.c: Likewise.

[PATCH 8/8] bpf: add myself as the maintainer for the eBPF port

[Jose E. Marchesi]

ChangeLog:

* MAINTAINERS: Add myself as the maintainer for the eBPF port.
---
 ChangeLog   | 4 
 MAINTAINERS | 1 +
 2 files changed, 5 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 912663c4497..cbd6f904944 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -57,6 +57,7 @@ arm port  Ramana Radhakrishnan

 arm port   Kyrylo Tkachov  
 avr port   Denis Chertykov 
 bfin port  Jie Zhang   
+bpf port   Jose E. Marchesi
 c6x port   Bernd Schmidt   
 cris port  Hans-Peter Nilsson  
 c-sky port Xianmiao Qu 
-- 
2.11.0

[PATCH 5/8] bpf: make target-supports.exp aware of eBPF

[Jose E. Marchesi]

This patch makes the several effective target checks in
target-supports.exp to be aware of eBPF targets.

gcc/testsuite/ChangeLog:

* lib/target-supports.exp (check_effective_target_malloc): New
function.
(check_effective_target_trampolines): Adapt to eBPF.
(check_effective_target_stack_size): Likewise.
(dg-effective-target-value): Likewise.
(check_effective_target_indirect_jumps): Likewise.
(check_effective_target_nonlocal_goto): Likewise.
(check_effective_target_global_constructor): Likewise.
(check_effective_target_return_address): Likewise.
---
 gcc/testsuite/ChangeLog   | 11 +++
 gcc/testsuite/lib/target-supports.exp | 27 +++
 2 files changed, 30 insertions(+), 8 deletions(-)

diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index a33822f7631..85e31b74113 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -514,7 +514,8 @@ proc check_effective_target_trampolines { } {
 || [istarget nvptx-*-*]
 || [istarget hppa2.0w-hp-hpux11.23]
 || [istarget hppa64-hp-hpux11.23]
-|| [istarget pru-*-*] } {
+|| [istarget pru-*-*]
+ || [istarget bpf-*-*] } {
return 0;
 }
 return 1
@@ -526,6 +527,9 @@ proc check_effective_target_stack_size { } {
 if [target_info exists gcc,stack_size] {
return 1
 }
+if [istarget bpf-*-*] {
+   return 1
+}
 return 0
 }
 
@@ -534,7 +538,11 @@ proc check_effective_target_stack_size { } {
 proc dg-effective-target-value { effective_target } {
 if { "$effective_target" == "stack_size" } {
if [check_effective_target_stack_size] {
-   return [target_info gcc,stack_size]
+   if [istarget bpf-*-*] {
+   return "512"
+   } else {
+   return [target_info gcc,stack_size]
+   }
}
 }
 
@@ -769,7 +777,7 @@ proc add_options_for_tls { flags } {
 # Return 1 if indirect jumps are supported, 0 otherwise.
 
 proc check_effective_target_indirect_jumps {} {
-if { [istarget nvptx-*-*] } {
+if { [istarget nvptx-*-*] || [istarget bpf-*-*] } {
return 0
 }
 return 1
@@ -778,7 +786,7 @@ proc check_effective_target_indirect_jumps {} {
 # Return 1 if nonlocal goto is supported, 0 otherwise.
 
 proc check_effective_target_nonlocal_goto {} {
-if { [istarget nvptx-*-*] } {
+if { [istarget nvptx-*-*] || [istarget bpf-*-*] } {
return 0
 }
 return 1
@@ -787,10 +795,9 @@ proc check_effective_target_nonlocal_goto {} {
 # Return 1 if global constructors are supported, 0 otherwise.
 
 proc check_effective_target_global_constructor {} {
-if { [istarget nvptx-*-*] } {
-   return 0
-}
-if { [istarget amdgcn-*-*] } {
+if { [istarget nvptx-*-*]
+|| [istarget amdgcn-*-*]
+|| [istarget bpf-*-*] } {
return 0
 }
 return 1
@@ -813,6 +820,10 @@ proc check_effective_target_return_address {} {
 if { [istarget nvptx-*-*] } {
return 0
 }
+# No notion of return address in eBPF.
+if { [istarget bpf-*-*] } {
+   return 0
+}
 # It could be supported on amdgcn, but isn't yet.
 if { [istarget amdgcn*-*-*] } {
return 0
-- 
2.11.0

[PATCH 0/8] eBPF support for GCC

[Jose E. Marchesi]

Hi people!

This patch series introduces a port of GCC to eBPF, which is a virtual
machine that resides in the Linux kernel.  Initially intended for
user-level packet capture and filtering, eBPF is nowadays generalized
to serve as a general-purpose infrastructure also for non-networking
purposes.

The binutils support is already upstream.  See
https://sourceware.org/ml/binutils/2019-05/msg00306.html.

eBPF architecture and ABI
=
   
Documentation for eBPF can be found in the linux kernel source tree,
file Documentation/networking/filter.txt.  It covers the instructions
set, the way the interpreter works and the many restrictions imposed
by the kernel verifier.
   
As for the ABI, att this moment compiled eBPF doesn't have very well
established conventions.  The details on what is expected to be in an
ELF file containing eBPF is determined, in practice, by what the llvm
BPF backend generates and what is expected by the the two existing
kernel loaders: bpf_load.c and libbpf.

We hope that the addition of this port to the GNU toolchain will help
to mature this domain.

Overview of the patch series

   
The first patch is preparatory.  It updates config.guess and
config.sub from the 'config' upstream project, in order to recognize
bpf-*-* triplets.

The second patch adds the new GCC port proper.  Machine description,
implementation of target hooks and macros, command-line options and
the like.

The third patch adds a libgcc port for eBPF.  At the moment, it is
minimal and it basically addresses the limitations imposed by the
target, by excluding a few functions in libgcc2 (all of them related
to TImodes) whose default implementations exceed the eBPF stack limit.

The fourth, fifth and sixth patches deal with testing the new
port. The gcc.target testsuite is extended with eBPF-specific tests,
covering the backend-specific built-in functions and diagnostics.  The
check-effective-target functions are made aware of eBPF targets. Many
tests in the gcc.c-torture/compile testsuite are annotated to be
skipped in bpf-*-* targets, since they violate some restriction
imposed by the hardware (such as surpassing the stack limit.)  The
resulting testsuite doesn't have unexpected failures, and is currently
the principal way to check for regressions in the port.  Likewise,
many tests in the gcc.dg testsuite are annotated to be skipped in
bpf-*-* targets.

The seventh patch adds documentation updates to the GCC manual,
including information on the new command line options and compiler
built-ins.

Finally, the eight patch adds myself as the maintainer of the BPF
port.  I personally commit to evolve and maintain the port for as long
as necessary, and to find a suitable replacement in case I have to
step down for whatever reason.

Some notes on the port
==

As a compilation target, eBPF is rather peculiar.  This is mainly due
to the quite hard restrictions imposed by the kernel verifier, and
also due to the security-driven design of the architecture itself.

To list a few examples:

. The stack is disjoint, and each stack frame corresponding to a
  function activation is isolated: it is not possible for a callee to
  access the stack frame of the caller, nor for a caller to access the
  stack frame of it's callees.  The frame pointer register is
  read-only.

. Therefore it is not possible to pass arguments in the stack.

. Argument passing is restricted to 5 arguments.

. Each stack frame is limited to 512 bytes.

. The instruction set doesn't support indirect jumps.

. The instruction set doesn't support indirect calls.

. The architecture doesn't provide an explicit stack pointer.
  Instead, the eBPF "hardware" (in this case the kernel verifier)
  examines the compiled program and, by looking at the way the stack
  is accessed, estimates the size of the stack frame for each
  function.

. eBPF "programs" are not ELF executables, but relocatable ELF
  objects.  This is because the kernel loaders need access to certain
  relocations, and each object contains several entry points, which
  are different kind of eBPF kernel programs hooked to different parts
  of the kernel.  We are working on a more "Elf conventional"
  alternative load model for eBPF programs, but that's a tangent at
  this point.

Restrictions like the above impact the port in several ways, some of
which are good to keep in mind while reviewing the patches:

. Only (a subset of) C is supported at the moment.  It should be
  possible to add more languages in the future, as the eBPF kernel
  verifier gets smarter and therefore more sophisticated programs are
  allowed.

. The back end tries to issue errors when an eBPF restriction is
  violated.  This is to increase the chances of the resulting objects
  to be palatable to the kernel verifier, shortening the development
  cycle.

. Dynamic stack allocation (alloca and VLAs) is achieved by using what
  otherwise would be a perfectly normal 

[PATCH 1/8] Update config.sub and config.guess.

[Jose E. Marchesi]

* config.sub: Import upstream version 2019-06-30.
* config.guess: Import upstream version 2019-07-24.
---
 ChangeLog|   5 ++
 config.guess | 264 +++
 config.sub   |  50 +--
 3 files changed, 240 insertions(+), 79 deletions(-)

diff --git a/config.guess b/config.guess
index 8e2a58b864f..97ad0733304 100755
--- a/config.guess
+++ b/config.guess
@@ -2,7 +2,7 @@
 # Attempt to guess a canonical system name.
 #   Copyright 1992-2019 Free Software Foundation, Inc.
 
-timestamp='2019-01-03'
+timestamp='2019-07-24'
 
 # This file is free software; you can redistribute it and/or modify it
 # under the terms of the GNU General Public License as published by
@@ -262,6 +262,9 @@ case 
"$UNAME_MACHINE:$UNAME_SYSTEM:$UNAME_RELEASE:$UNAME_VERSION" in
 *:SolidBSD:*:*)
echo "$UNAME_MACHINE"-unknown-solidbsd"$UNAME_RELEASE"
exit ;;
+*:OS108:*:*)
+   echo "$UNAME_MACHINE"-unknown-os108_"$UNAME_RELEASE"
+   exit ;;
 macppc:MirBSD:*:*)
echo powerpc-unknown-mirbsd"$UNAME_RELEASE"
exit ;;
@@ -275,8 +278,8 @@ case 
"$UNAME_MACHINE:$UNAME_SYSTEM:$UNAME_RELEASE:$UNAME_VERSION" in
echo "$UNAME_MACHINE"-unknown-redox
exit ;;
 mips:OSF1:*.*)
-echo mips-dec-osf1
-exit ;;
+   echo mips-dec-osf1
+   exit ;;
 alpha:OSF1:*:*)
case $UNAME_RELEASE in
*4.0)
@@ -385,20 +388,7 @@ case 
"$UNAME_MACHINE:$UNAME_SYSTEM:$UNAME_RELEASE:$UNAME_VERSION" in
echo sparc-hal-solaris2"`echo "$UNAME_RELEASE"|sed -e 's/[^.]*//'`"
exit ;;
 sun4*:SunOS:5.*:* | tadpole*:SunOS:5.*:*)
-   set_cc_for_build
-   SUN_ARCH=sparc
-   # If there is a compiler, see if it is configured for 64-bit objects.
-   # Note that the Sun cc does not turn __LP64__ into 1 like gcc does.
-   # This test works for both compilers.
-   if [ "$CC_FOR_BUILD" != no_compiler_found ]; then
-   if (echo '#ifdef __sparcv9'; echo IS_64BIT_ARCH; echo '#endif') | \
-   (CCOPTS="" $CC_FOR_BUILD -E - 2>/dev/null) | \
-   grep IS_64BIT_ARCH >/dev/null
-   then
-   SUN_ARCH=sparcv9
-   fi
-   fi
-   echo "$SUN_ARCH"-sun-solaris2"`echo "$UNAME_RELEASE"|sed -e 
's/[^.]*//'`"
+   echo sparc-sun-solaris2"`echo "$UNAME_RELEASE" | sed -e 's/[^.]*//'`"
exit ;;
 i86pc:AuroraUX:5.*:* | i86xen:AuroraUX:5.*:*)
echo i386-pc-auroraux"$UNAME_RELEASE"
@@ -998,22 +988,50 @@ EOF
exit ;;
 mips:Linux:*:* | mips64:Linux:*:*)
set_cc_for_build
+   IS_GLIBC=0
+   test x"${LIBC}" = xgnu && IS_GLIBC=1
sed 's/^//' << EOF > "$dummy.c"
#undef CPU
-   #undef ${UNAME_MACHINE}
-   #undef ${UNAME_MACHINE}el
+   #undef mips
+   #undef mipsel
+   #undef mips64
+   #undef mips64el
+   #if ${IS_GLIBC} && defined(_ABI64)
+   LIBCABI=gnuabi64
+   #else
+   #if ${IS_GLIBC} && defined(_ABIN32)
+   LIBCABI=gnuabin32
+   #else
+   LIBCABI=${LIBC}
+   #endif
+   #endif
+
+   #if ${IS_GLIBC} && defined(__mips64) && defined(__mips_isa_rev) && 
__mips_isa_rev>=6
+   CPU=mipsisa64r6
+   #else
+   #if ${IS_GLIBC} && !defined(__mips64) && defined(__mips_isa_rev) && 
__mips_isa_rev>=6
+   CPU=mipsisa32r6
+   #else
+   #if defined(__mips64)
+   CPU=mips64
+   #else
+   CPU=mips
+   #endif
+   #endif
+   #endif
+
#if defined(__MIPSEL__) || defined(__MIPSEL) || defined(_MIPSEL) || 
defined(MIPSEL)
-   CPU=${UNAME_MACHINE}el
+   MIPS_ENDIAN=el
#else
#if defined(__MIPSEB__) || defined(__MIPSEB) || defined(_MIPSEB) || 
defined(MIPSEB)
-   CPU=${UNAME_MACHINE}
+   MIPS_ENDIAN=
#else
-   CPU=
+   MIPS_ENDIAN=
#endif
#endif
 EOF
-   eval "`$CC_FOR_BUILD -E "$dummy.c" 2>/dev/null | grep '^CPU'`"
-   test "x$CPU" != x && { echo "$CPU-unknown-linux-$LIBC"; exit; }
+   eval "`$CC_FOR_BUILD -E "$dummy.c" 2>/dev/null | grep 
'^CPU\|^MIPS_ENDIAN\|^LIBCABI'`"
+   test "x$CPU" != x && { echo 
"$CPU${MIPS_ENDIAN}-unknown-linux-$LIBCABI"; exit; }
;;
 mips64el:Linux:*:*)
echo "$UNAME_MACHINE"-unknown-linux-"$LIBC"
@@ -1126,7 +1144,7 @@ EOF
*Pentium)UNAME_MACHINE=i586 ;;
*Pent*|*Celeron) UNAME_MACHINE=i686 ;;
esac
-   echo 
"$UNAME_MACHINE-unknown-sysv${UNAME_RELEASE}${UNAME_SYSTEM}{$UNAME_VERSION}"
+   echo 
"$UNAME_MACHINE-unknown-sysv${UNAME_RELEASE}${UNAME_SYSTEM}${UNAME_VERSION}"
exit ;;
 i*86:*:3.2:*)
if test -f /usr/options/cb.name; then
@@ -1310,38 +1328,39 @@ EOF
echo "$UNAME_MACHINE"-apple-rhapsody"$UNAME_RELEASE"
exit ;;
 *:Darwin:*:*)
-   UNAME_PROCESSOR=`uname -p` || UNAME_PROCESSOR=unknown
-   set_cc_for_build
-   if test "$UNAME_PROCESSOR" = unknown ; then
-   

[PATCH 3/8] bpf: new libgcc port

[Jose E. Marchesi]

This patch adds an eBPF port to libgcc.

As of today, compiled eBPF programs do not support a single-entry
point schema.  Instead, a BPF "executable" is a relocatable ELF object
file containing multiple entry points, in certain named sections.

Also, the BPF loaders in the kernel do not execute .ini/.fini
constructors/destructors.  Therefore, this patch provides empty crtn.S
and cri.S files.

libgcc/ChangeLog:

* config.host: Set cpu_type for bpf-*-* targets.
* config/bpf/t-bpf: Likewise.
* config/bpf/crtn.S: Likewise.
* config/bpf/crti.S: New file.
---
 libgcc/ChangeLog |  7 +++
 libgcc/config.host   |  7 +++
 libgcc/config/bpf/crti.S |  0
 libgcc/config/bpf/crtn.S |  0
 libgcc/config/bpf/t-bpf  | 24 
 5 files changed, 38 insertions(+)
 create mode 100644 libgcc/config/bpf/crti.S
 create mode 100644 libgcc/config/bpf/crtn.S
 create mode 100644 libgcc/config/bpf/t-bpf

diff --git a/libgcc/config.host b/libgcc/config.host
index 503ebb6be20..2e9fbc35482 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -107,6 +107,9 @@ avr-*-*)
 bfin*-*)
cpu_type=bfin
;;
+bpf-*-*)
+cpu_type=bpf
+;;
 cr16-*-*)
;;
 crisv32-*-*)
@@ -526,6 +529,10 @@ bfin*-*)
tmake_file="$tmake_file bfin/t-bfin t-fdpbit"
extra_parts="crtbegin.o crtend.o crti.o crtn.o"
 ;;
+bpf-*-*)
+tmake_file="$tmake_file ${cpu_type}/t-${cpu_type}"
+extra_parts="crti.o crtn.o"
+   ;;
 cr16-*-elf)
tmake_file="${tmake_file} cr16/t-cr16 cr16/t-crtlibid t-fdpbit"
extra_parts="$extra_parts crti.o crtn.o crtlibid.o"
diff --git a/libgcc/config/bpf/crti.S b/libgcc/config/bpf/crti.S
new file mode 100644
index 000..e69de29bb2d
diff --git a/libgcc/config/bpf/crtn.S b/libgcc/config/bpf/crtn.S
new file mode 100644
index 000..e69de29bb2d
diff --git a/libgcc/config/bpf/t-bpf b/libgcc/config/bpf/t-bpf
new file mode 100644
index 000..c1bda7c98cb
--- /dev/null
+++ b/libgcc/config/bpf/t-bpf
@@ -0,0 +1,24 @@
+HOST_LIBGCC2_CFLAGS += -O0
+LIB2ADDEH = 
+
+crti.o: $(srcdir)/config/bpf/crti.S
+   $(crt_compile) $(CRTSTUFF_T_CFLAGS) -c $<
+
+crtn.o: $(srcdir)/config/bpf/crtn.S
+   $(crt_compile) $(CRTSTUFF_T_CFLAGS) -c $<
+
+# Some of the functions defined in libgcc2 exceed the eBPF stack
+# limit, or other restrictions imposed by this peculiar target.
+# Therefore we have to exclude them here.
+#
+# Patterns in bpf.md must guarantee that no calls to the excluded
+# functions are ever generated, and compiler tests should make sure
+# this holds.
+#
+# Note that the modes in the function names below are misleading: di
+# means TImode.
+LIB2FUNCS_EXCLUDE = _mulvdi3 _divdi3 _moddi3 _divmoddi4 _udivdi3 _umoddi3 \
+_udivmoddi4
+
+# Prevent building "advanced" stuff (for example, gcov support).
+INHIBIT_LIBC_CFLAGS = -Dinhibit_libc
-- 
2.11.0

[PATCH], Patch #1 of 10, Add instruction format enumeration

[Michael Meissner]

This patch implements the insn_form enumeration that identifies which types of
instruction format is used for memory instruction.  While the PowerPC has
additional formats, the instruction formats that we need to use are:

INSN_FORM_D -- Traditional D-form instructions (16 bits offset);
INSN_FORM_DS-- Traditional DS-form instructions (14 bits offset);
INSN_FORM_DQ-- Traditional DQ-form instructions (12 bits offset).

In the previous patches, these were called offset_format instead of insn_form.
I changed the way the insn_form values are computed to use the mask bits in the
reg_addr data structure, instead of having a function that set this up in a
confusing manner.

Previous patches did not have the support for external addresses, and these are
added in this new patch.

This patch includes the notation of a default instruction format.  This is used
in the absence of the actual register used.  The default instruction format is
based on the anticipated usage.

For example, in 64-bit mode, a DImode integer's default instruction format is
INSN_FORM_DS because the LD and STD instructions use the DS instruction
encoding.  But if you were loading the DImode into a traditional FPR register,
the LFD and STFD instructins are D format.

Similarly, for SFmode and DFmode, the traditional FPR memory instructions uses
D format instruction, but the traditional Altivec memory instructions use the
DS format.  In this case the traditional instruction format is D format.

The new prefixed memory and pc-relative lookup functions now take the default
insn_form as an argument.  This is important if the default format is DS format
or DQ format, and the offset has the bottom 2 or 4 bits non-zero.  In this
case, we can do the memory operation using a prefixed load or store instead of
requiring the offset to be loaded into a GPR.

The pc-relative match function (pcrel_addr_p) now optionally returns the base
address and offset to allow print_operand_address and other functions that
would otherwise need to decode the instruction to have the values available
directly.

There is a new function (reg_to_insn_form) that takes a register and an address
and returns the instruction format for that particular memory address.  This is
due to the fact that when offset addressing was added to the PowerPC
traditional Altivec registers, the instruction format used was DS format
instead of D format for the scalar values.  If the register is a pseudo
register, the function returns the default instruction format.  This function
will primarily be used in the next patch to identify whether an insn uses a
prefixed instruction or not.

2019-08-14   Michael Meissner  

* config/rs6000/predicates.md (pcrel_address): Rewrite to use
pcrel_addr_p.
(pcrel_external_address): Rewrite to use pcrel_addr_p.
(prefixed_mem_operand): Rewrite to use prefixed_local_addr_p.
(pcrel_external_mem_operand): Rewrite to use pcrel_addr_p.
* config/rs6000/rs6000-protos.h (reg_to_insn_form): New
declaration.
(pcrel_info_type): New declaration.
(PCREL_NULL): New macro.
(pcrel_addr_p): New declaration.
(rs6000_prefixed_address_mode_p): Delete.
* config/rs6000/rs6000.c (struct rs6000_reg_addr): Add fields for
instruction format and prefixed memory support.
(rs6000_debug_insn_form): New debug function.
(rs6000_debug_print_mode): Print instruction formats.
(setup_insn_form): New function.
(rs6000_init_hard_regno_mode_ok): Call setup_insn_form.
(print_operand_address): Call pcrel_addr_p instead of
pcrel_address.  Add support for external pc-relative labels.
(mode_supports_prefixed_address_p): Delete.
(rs6000_prefixed_address_mode_p): Delete, replace with
prefixed_local_addr_p.
(prefixed_local_addr_p): Replace rs6000_prefixed_address_mode_p.
Add argument to specify the instruction format.
(pcrel_addr_p): New function.
(reg_to_insn_form): New function.
* config/rs6000/rs6000.md (enum insn_form): New enumeration.

Index: gcc/config/rs6000/predicates.md
===
--- gcc/config/rs6000/predicates.md (revision 274173)
+++ gcc/config/rs6000/predicates.md (working copy)
@@ -1626,32 +1626,11 @@
   return GET_CODE (op) == UNSPEC && XINT (op, 1) == UNSPEC_TOCREL;
 })
 
-;; Return true if the operand is a pc-relative address.
+;; Return true if the operand is a pc-relative address to a local symbol.
 (define_predicate "pcrel_address"
   (match_code "label_ref,symbol_ref,const")
 {
-  if (!rs6000_pcrel_p (cfun))
-return false;
-
-  if (GET_CODE (op) == CONST)
-op = XEXP (op, 0);
-
-  /* Validate offset.  */
-  if (GET_CODE (op) == PLUS)
-{
-  rtx op0 = XEXP (op, 0);
-  rtx op1 = XEXP (op, 1);
-
-  if (!CONST_INT_P (op1) || !SIGNED_34BIT_OFFSET_P (INTVAL (op1)))
- 

C++ PATCH to implement C++20 P1143R2, constinit (PR c++/91360)

[Marek Polacek]

This patch implements the C++20 specifier constinit, as described in
.  It makes sure that the compiler requires constant
initialization of a variable (it can only be applied to variables with static
or thread storage duration).  Note the variable is *not* const; it is posssible
to modify it even after initialization has taken place.

The main bits are in store_init_value.  The c-family/ and parser.c bits
handle parsing this new decl-specifier.  decl.c is sprinkled with various
checks, e.g. you can't have a parameter declared "constinit".

It was also needed to add the -Wc++20-compat option to warn when "constinit"
was used as an identifier.  Note that I am a bit presumptuous about C++20 here,
perhaps I should be only adding -Wc++2a-compat at this point.

As an extension, I'm also adding the __constinit keyword, so that you can
use this feature in C++17 and lesser, effectively supplanting the clang
require_constant_initialization attribute.

I spent significant time writing the tests (I stol^Wborrowed a couple of
reference-related tests from clang, I'll cop to that).

Here's an example of the new diagnostic.  For

  int nonconst;
  constinit int i = nonconst;

we now issue:

q.C:2:15: error: ‘constinit’ variable ‘i’ does not have a constant initializer
2 | constinit int i = nonconst;
  |   ^
q.C:2:19: error: the value of ‘nonconst’ is not usable in a constant expression
2 | constinit int i = nonconst;
  |   ^~~~
q.C:1:5: note: ‘int nonconst’ is not const
1 | int nonconst;
  | ^~~~

I'm not crazy about the two errors, but I felt that revamping the diagnostics
would be out of scope for this patch.

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

2019-08-14  Marek Polacek  

PR c++/91360 - Implement C++20 P1143R2: constinit.
* c-common.c (c_common_reswords): Add constinit and __constinit.
(keyword_is_decl_specifier): Handle RID_CONSTINIT.
* c-common.h (enum rid): Add RID_CONSTINIT, RID_FIRST_CXX20, and
RID_LAST_CXX20.
(D_CXX20): Define.
* c-cppbuiltin.c (c_cpp_builtins): Define __cpp_constinit.
* c-format.c (cxx_keywords): Add "constinit".
* c.opt (Wc++2a-compat, Wc++20-compat): New options.

* cp-tree.h (DECL_DECLARED_CONSTINIT_P): Define.
(enum cp_decl_spec): Add ds_constinit.
* decl.c (duplicate_decls): Set DECL_DECLARED_CONSTINIT_P.
(check_tag_decl): Give an error for constinit in type declarations.
(check_initializer): Also check DECL_DECLARED_CONSTINIT_P.
(cp_finish_decl): Add checking for a constinit declaration.
(grokdeclarator): Add checking for a declaration with the constinit
specifier.  Set DECL_DECLARED_CONSTINIT_P for VAR_Ps.
* lex.c (init_reswords): Handle D_CXX20.
* parser.c (cp_lexer_get_preprocessor_token): Pass a better location
to warning_at.  Warn about C++20 keywords.
(cp_keyword_starts_decl_specifier_p): Handle RID_CONSTINIT.
(cp_parser_diagnose_invalid_type_name): Add an inform about constinit.
(cp_parser_decl_specifier_seq): Handle RID_CONSTINIT.
(set_and_check_decl_spec_loc): Add "constinit".
* typeck2.c (store_init_value): If a constinit variable wasn't
initialized using a constant initializer, give an error.

* doc/invoke.texi: Document -Wc++20-compat.

* g++.dg/cpp2a/constinit1.C: New test.
* g++.dg/cpp2a/constinit2.C: New test.
* g++.dg/cpp2a/constinit3.C: New test.
* g++.dg/cpp2a/constinit4.C: New test.
* g++.dg/cpp2a/constinit5.C: New test.
* g++.dg/cpp2a/constinit6.C: New test.
* g++.dg/cpp2a/constinit7.C: New test.
* g++.dg/cpp2a/constinit8.C: New test.
* g++.dg/cpp2a/constinit9.C: New test.
* g++.dg/cpp2a/constinit10.C: New test.
* g++.dg/cpp2a/constinit11.C: New test.
* g++.dg/cpp2a/constinit12.C: New test.

diff --git gcc/c-family/c-common.c gcc/c-family/c-common.c
index 610cb905814..eb0f1ba9993 100644
--- gcc/c-family/c-common.c
+++ gcc/c-family/c-common.c
@@ -326,8 +326,9 @@ static bool nonnull_check_p (tree, unsigned HOST_WIDE_INT);
C --std=c89: D_C99 | D_CXXONLY | D_OBJC | D_CXX_OBJC
C --std=c99: D_CXXONLY | D_OBJC
ObjC is like C except that D_OBJC and D_CXX_OBJC are not set
-   C++ --std=c++98: D_CONLY | D_CXX11 | D_OBJC
-   C++ --std=c++11: D_CONLY | D_OBJC
+   C++ --std=c++98: D_CONLY | D_CXX11 | D_CXX20 | D_OBJC
+   C++ --std=c++11: D_CONLY | D_CXX20 | D_OBJC
+   C++ --std=c++2a: D_CONLY | D_OBJC
ObjC++ is like C++ except that D_OBJC is not set
 
If -fno-asm is used, D_ASM is added to the mask.  If
@@ -392,6 +393,7 @@ const struct c_common_resword c_common_reswords[] =
   { "__complex__", RID_COMPLEX,0 },
   { "__const", RID_CONST,  0 },
   { "__const__",   RID_CONST,  0 },
+  { "__constinit", RID_CONSTINIT,  

PowerPC 'future' patches introduction

[Michael Meissner]

I will be submitting 10 patches will that will add support to GCC for a
possible future PowerPC processor.  These patches add support for new
instructions that extend the offsettable memory instructions (D, DS, or DQ
instruction formats) to have 34 bit offsets (instead of 16, 14, or 12 bits
respectively).  These instructions use reserved encodings for the first 32 bits
and the second 32 bits may either be the traditional instruction that is being
extended or a new encoding.  These new 64-bit instructions are called
'prefixed' instructions.

These new instructions also have a mode that uses the 34 bit offset and adds it
to the current location instead of a base register, giving pc-relative
addressing.  Pc-relative addressing will be supported in the next ABI (3.1) as
an alternative to the current TOC based addressing.

The first patch adds the new insn_form enumeration to describe the instruction
format.  This is similar to the previous patch, except the name is now
insn_form instead of offset_format, and I simplified the set up for the
instruction format, using the existing reg_addr structure.

The second patch adds the basic infrastructure using RTL attributes on the
insns to say whether an instructin is prefixed or not.  I tried to simplify
this over previous versions of patch, by only having a "prefixed" attribute
instead of a "maybe_prefixed" and "prefixed" attributes.

The third patch adds support for all offsettable memory instructions to use the
new instructions.  After this patch is installed, you would be able to generate
the new pc-relative instructions if you use the -mpcrel option.

The fourth patch adjusts the costs when you use prefixed instructions (prefixed
instructions are larger than traditional instructions, so we need to adjust the
costs based on instruction size).

The fifth patch switches the default when you use -mcpu=future to use
pc-relative instructions instead of using the TOC by default.

The sixth patch adds support for the 'future' machine to the target_clones and
target function attributes, as well as the __builtin_cpu_supports built in
function.

The seventh patch adds a new RTL pass to implement the PCREL_OPT relocations
that will be part of the ISA 3.1 specification.  This optimization allows the
linker to optimize accessing external symbols that are local to the main
program in some cases.

The eighth, ninth, and tenth passes adds tests for the 'future' machine to the
testsuite.

After these patches are installed, Alan Modra will have a set of patches update
the thread local storage (TLS) for use with pc-relative addressing.

-- 
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: [SVE] PR86753

[Richard Sandiford]

Richard Biener  writes:
> On Wed, Aug 14, 2019 at 6:49 PM Richard Biener
>  wrote:
>>
>> On Wed, Aug 14, 2019 at 5:06 PM Prathamesh Kulkarni
>>  wrote:
>> >
>> > Hi,
>> > The attached patch tries to fix PR86753.
>> >
>> > For following test:
>> > void
>> > f1 (int *restrict x, int *restrict y, int *restrict z)
>> > {
>> >   for (int i = 0; i < 100; ++i)
>> > x[i] = y[i] ? z[i] : 10;
>> > }
>> >
>> > vect dump shows:
>> >   vect_cst__42 = { 0, ... };
>> >   vect_cst__48 = { 0, ... };
>> >
>> >   vect__4.7_41 = .MASK_LOAD (vectp_y.5_38, 4B, loop_mask_40);
>> >   _4 = *_3;
>> >   _5 = z_12(D) + _2;
>> >   mask__35.8_43 = vect__4.7_41 != vect_cst__42;
>> >   _35 = _4 != 0;
>> >   vec_mask_and_46 = mask__35.8_43 & loop_mask_40;
>> >   vect_iftmp.11_47 = .MASK_LOAD (vectp_z.9_44, 4B, vec_mask_and_46);
>> >   iftmp.0_13 = 0;
>> >   vect_iftmp.12_50 = VEC_COND_EXPR > > vect_iftmp.11_47, vect_cst__49>;
>> >
>> > and following code-gen:
>> > L2:
>> > ld1wz0.s, p2/z, [x1, x3, lsl 2]
>> > cmpne   p1.s, p3/z, z0.s, #0
>> > cmpne   p0.s, p2/z, z0.s, #0
>> > ld1wz0.s, p0/z, [x2, x3, lsl 2]
>> > sel z0.s, p1, z0.s, z1.s
>> >
>> > We could reuse vec_mask_and_46 in vec_cond_expr since the conditions
>> > vect__4.7_41 != vect_cst__48 and vect__4.7_41 != vect_cst__42
>> > are equivalent, and vect_iftmp.11_47 depends on vect__4.7_41 != 
>> > vect_cst__48.
>> >
>> > I suppose in general for vec_cond_expr  if T comes from masked 
>> > load,
>> > which is conditional on C, then we could reuse the mask used in load,
>> > in vec_cond_expr ?
>> >
>> > The patch maintains a hash_map cond_to_vec_mask
>> > from  vec_mask (with loop predicate applied).
>> > In prepare_load_store_mask, we record  -> vec_mask & 
>> > loop_mask,
>> > and in vectorizable_condition, we check if  exists in
>> > cond_to_vec_mask
>> > and if found, the corresponding vec_mask is used as 1st operand of
>> > vec_cond_expr.
>> >
>> >  is represented with cond_vmask_key, and the patch
>> > adds tree_cond_ops to represent condition operator and operands coming
>> > either from cond_expr
>> > or a gimple comparison stmt. If the stmt is not comparison, it returns
>> >  and inserts that into cond_to_vec_mask.
>> >
>> > With patch, the redundant p1 is eliminated and sel uses p0 for above test.
>> >
>> > For following test:
>> > void
>> > f2 (int *restrict x, int *restrict y, int *restrict z, int fallback)
>> > {
>> >   for (int i = 0; i < 100; ++i)
>> > x[i] = y[i] ? z[i] : fallback;
>> > }
>> >
>> > input to vectorizer has operands swapped in cond_expr:
>> >   _36 = _4 != 0;
>> >   iftmp.0_14 = .MASK_LOAD (_5, 32B, _36);
>> >   iftmp.0_8 = _4 == 0 ? fallback_12(D) : iftmp.0_14;
>> >
>> > So we need to check for inverted condition in cond_to_vec_mask,
>> > and swap the operands.
>> > Does the patch look OK so far ?
>> >
>> > One major issue remaining with the patch is value  numbering.
>> > Currently, it does value numbering for entire function using sccvn
>> > during start of vect pass, which is too expensive since we only need
>> > block based VN. I am looking into that.
>>
>> Why do you need it at all?  We run VN on the if-converted loop bodies btw.

This was my suggestion, but with the idea being to do the numbering
per-statement as we vectorise.  We'll then see pattern statements too.

That's important because we use pattern statements to set the right
vector boolean type (e.g. vect_recog_mask_conversion_pattern).
So some of the masks we care about don't exist after if converison.

> Also I can't trivially see the equality of the masks and probably so
> can't VN.  Is it that we just don't bother to apply loop_mask to
> VEC_COND but there's no harm if we do?

Yeah.  The idea of the optimisation is to decide when it's more profitable
to apply the loop mask, even though doing so isn't necessary.  It would
be hard to do after vectorisation because the masks aren't equivalent.
We're relying on knowledge of how the vectoriser uses the result.

Thanks,
Richard

Re: [PATCH] fold more string comparison with known result (PR 90879)

[Martin Sebor]

On 8/13/19 4:46 PM, Jeff Law wrote:

On 8/13/19 3:43 PM, Martin Sebor wrote:

On 8/13/19 2:07 PM, Jeff Law wrote:

On 8/9/19 10:51 AM, Martin Sebor wrote:


PR tree-optimization/90879 - fold zero-equality of strcmp between a
longer string and a smaller array

gcc/c-family/ChangeLog:

 PR tree-optimization/90879
 * c.opt (-Wstring-compare): New option.

gcc/testsuite/ChangeLog:

 PR tree-optimization/90879
 * gcc.dg/Wstring-compare-2.c: New test.
 * gcc.dg/Wstring-compare.c: New test.
 * gcc.dg/strcmpopt_3.c: Scan the optmized dump instead of strlen.
 * gcc.dg/strcmpopt_6.c: New test.
 * gcc.dg/strlenopt-65.c: Remove uinnecessary declarations, add
 test cases.
 * gcc.dg/strlenopt-66.c: Run it.
 * gcc.dg/strlenopt-68.c: New test.

gcc/ChangeLog:

 PR tree-optimization/90879
 * builtins.c (check_access): Avoid using maxbound when null.
 * calls.c (maybe_warn_nonstring_arg): Adjust to get_range_strlen
change.
 * doc/invoke.texi (-Wstring-compare): Document new warning option.
 * gimple-fold.c (get_range_strlen_tree): Make setting maxbound
 conditional.
 (get_range_strlen): Overwrite initial maxbound when non-null.
 * gimple-ssa-sprintf.c (get_string_length): Adjust to
get_range_strlen
 change.
 * tree-ssa-strlen.c (maybe_diag_stxncpy_trunc): Same.
 (used_only_for_zero_equality): New function.
 (handle_builtin_memcmp): Call it.
 (determine_min_objsize): Return an integer instead of tree.
 (get_len_or_size, strxcmp_eqz_result): New functions.
 (maybe_warn_pointless_strcmp): New function.
 (handle_builtin_string_cmp): Call it.  Fold zero-equality of strcmp
 between a longer string and a smaller array.




diff --git a/gcc/tree-ssa-strlen.c b/gcc/tree-ssa-strlen.c
index 4af47855e7c..31e012b741b 100644
--- a/gcc/tree-ssa-strlen.c
+++ b/gcc/tree-ssa-strlen.c



@@ -3079,196 +3042,388 @@ determine_min_objsize (tree dest)
       type = TYPE_MAIN_VARIANT (type);
   -  /* We cannot determine the size of the array if it's a flexible
array,
- which is declared at the end of a structure.  */
-  if (TREE_CODE (type) == ARRAY_TYPE
-  && !array_at_struct_end_p (dest))
+  /* The size of a flexible array cannot be determined.  Otherwise,
+ for arrays with more than one element, return the size of its
+ type.  GCC itself misuses arrays of both zero and one elements
+ as flexible array members so they are excluded as well.  */
+  if (TREE_CODE (type) != ARRAY_TYPE
+  || !array_at_struct_end_p (dest))
   {
-  tree size_t = TYPE_SIZE_UNIT (type);
-  if (size_t && TREE_CODE (size_t) == INTEGER_CST
-  && !integer_zerop (size_t))
-    return size_t;
+  tree type_size = TYPE_SIZE_UNIT (type);
+  if (type_size && TREE_CODE (type_size) == INTEGER_CST
+  && !integer_onep (type_size)
+  && !integer_zerop (type_size))
+    return tree_to_uhwi (type_size);

So I nearly commented on this when looking at the original patch.  Can
we really depend on the size when we've got an array at the end of a
struct with a declared size other than 0/1?   While 0/1 are by far the
most common way to declare them, couldn't someone have used other sizes?
   I think we pondered doing that at one time to cut down on the noise
from Coverity for RTL and TREE operand accessors.

Your code makes us safer, so I'm not saying you've done anything wrong,
just trying to decide if we need to tighten this up even further.


This patch issues a warning in these cases, i.e., when it sees
a call like, say, strcmp("foobar", A) with an A that's smaller
than the string, because it seems they are likely (rare) bugs.
I haven't seen the warning in any of the projects I tested it
with (Binutils/GDB, GCC, Glibc, the Linux kernel, and LLVM).

The warning uses strcmp to detect these mistakes (or misuses)
but I'd like to add similar warnings for other string functions
as well and have code out there that does this on purpose use
true flexible array members (or the zero-length extension)
instead.  That makes the intent clear.

It's a judgment call whether to also fold (or do something else
like insert a trap) in addition to issuing a warning.  In this
case (reading) I don't think it matters as much as it does for
writes.  Either way, it would be nice to set a policy and
document it in the manual so users know what to expect and
so we don't have to revisit this question for each patch that
touches on this subject.

The GCC manual documents zero length arrays at the end of an aggregate
as a GNU extension for variable length objects.  The manual also
documents that it could be done with single element arrays, but that
doing so does contribute to the base size of the aggregate, but
otherwise it's handled like a zero length array.

So both zero and one element arrays are documented as supported for this
use case.  However, I could easily see someone making the case that any
size should work here and I could easily 

[PATCH] Deprecate std::__is_nullptr_t type trait

[Jonathan Wakely]

This non-standard extension is redundant and unused by the library.

* include/std/type_traits (__is_nullptr_t): Add deprecated attribute.

We support std::is_null_pointer so don't need a non-standard trait
that does the same thing.

Tested x86_64-linux, committed to trunk.

commit 8068073ad959c806a925b6c031965f6db6b70c90
Author: Jonathan Wakely 
Date:   Wed Aug 14 12:26:24 2019 +0100

Deprecate std::__is_nullptr_t type trait

This non-standard extension is redundant and unused by the library.

* include/std/type_traits (__is_nullptr_t): Add deprecated 
attribute.

diff --git a/libstdc++-v3/include/std/type_traits 
b/libstdc++-v3/include/std/type_traits
index b31c26ab381..d3f853d4ce2 100644
--- a/libstdc++-v3/include/std/type_traits
+++ b/libstdc++-v3/include/std/type_traits
@@ -597,11 +597,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 : public __is_null_pointer_helper::type>::type
 { };
 
-  /// __is_nullptr_t (extension).
+  /// __is_nullptr_t (deprecated extension).
   template
 struct __is_nullptr_t
 : public is_null_pointer<_Tp>
-{ };
+{ } _GLIBCXX_DEPRECATED;
 
   // Composite type categories.
 

Re: [PATCH] Properly register dead cgraph_nodes in passes.c.

[Jeff Law]

On 8/9/19 6:41 AM, Martin Liška wrote:
> Hi.
> 
> The patch prevents crashes caused by fact that do_per_function_toporder
> uses get_uid () to register all dead cgraph_nodes. That does not work
> now as cgraph_nodes are directly released via ggc_free and so that one
> will see a garbage here. Second steps is to register all cgraph hooks
> and correctly hold add removed nodes. Doing that we'll not need the GGC nodes
> array.
> 
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> I can also build xalancbmk with -O2 -ffast-math where I previously saw
> the ICE.
> 
> Ready to be installed?
> Thanks,
> Martin
> 
> gcc/ChangeLog:
> 
> 2019-08-09  Martin Liska  
> 
>   PR ipa/91404
>   * passes.c (order): Remove.
>   (uid_hash_t): Likewise).
>   (remove_cgraph_node_from_order): Remove from set
>   of pointers (cgraph_node *).
>   (insert_cgraph_node_to_order): New.
>   (duplicate_cgraph_node_to_order): New.
>   (do_per_function_toporder): Register all 3 cgraph hooks.
>   Skip removed_nodes now as we know about all of them.
So this turns out to fix the kernel build failure my tester was tripping
over as well.

OK for the trunk.

jeff

[PATCH, i386]: Use *mmx_pinsrb some more

[Uros Bizjak]

We can generate {v,}pinsrb in ix86_expand_vector_init_one_nonzero and
ix86_expand_vector_init_one_var. {v,}pinsrd is already generated where
optimal.

2019-08-14  Uroš Bizjak  

* config/i386/i386-expand.c (ix86_expand_vector_init_one_nonzero)
: Use vector_set path for
TARGET_MMX_WITH_SSE && TARGET_SSE4_1.
(ix86_expand_vector_init_one_var) :
Do not widen for TARGET_MMX_WITH_SSE && TARGET_SSE4_1.

Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

Committed to mainline SVN.

Uros.
diff --git a/gcc/config/i386/i386-expand.c b/gcc/config/i386/i386-expand.c
index d1d5a9435f13..b6a2dbf402a1 100644
--- a/gcc/config/i386/i386-expand.c
+++ b/gcc/config/i386/i386-expand.c
@@ -13383,6 +13383,9 @@ ix86_expand_vector_init_one_nonzero (bool mmx_ok, 
machine_mode mode,
 case E_V8HImode:
   use_vector_set = TARGET_SSE2;
   break;
+case E_V8QImode:
+  use_vector_set = TARGET_MMX_WITH_SSE && TARGET_SSE4_1;
+  break;
 case E_V4HImode:
   use_vector_set = TARGET_SSE || TARGET_3DNOW_A;
   break;
@@ -13590,6 +13593,8 @@ ix86_expand_vector_init_one_var (bool mmx_ok, 
machine_mode mode,
   wmode = V8HImode;
   goto widen;
 case E_V8QImode:
+  if (TARGET_MMX_WITH_SSE && TARGET_SSE4_1)
+   break;
   wmode = V4HImode;
   goto widen;
 widen:

Re: C++ PATCH for c++/91264 - detect modifying const objects in constexpr

[Jason Merrill]

On Thu, Aug 8, 2019 at 3:25 PM Marek Polacek  wrote:
>
> On Thu, Aug 08, 2019 at 11:06:17AM -0400, Jason Merrill wrote:
> > On 8/6/19 3:20 PM, Marek Polacek wrote:
> > > On Mon, Aug 05, 2019 at 03:54:19PM -0400, Jason Merrill wrote:
> > > > On 7/31/19 3:26 PM, Marek Polacek wrote:
> > > > > One of the features of constexpr is that it doesn't allow UB; and 
> > > > > such UB must
> > > > > be detected at compile-time.  So running your code in a context that 
> > > > > requires
> > > > > a constant expression should ensure that the code in question is free 
> > > > > of UB.
> > > > > In effect, constexpr can serve as a sanitizer.  E.g. this article 
> > > > > describes in
> > > > > in more detail:
> > > > > 
> > > > >
> > > > > [dcl.type.cv]p4 says "Any attempt to modify a const object during its 
> > > > > lifetime
> > > > > results in undefined behavior." However, as the article above points 
> > > > > out, we
> > > > > aren't detecting that case in constexpr evaluation.
> > > > >
> > > > > This patch fixes that.  It's not that easy, though, because we have 
> > > > > to keep in
> > > > > mind [class.ctor]p5:
> > > > > "A constructor can be invoked for a const, volatile or const volatile 
> > > > > object.
> > > > > const and volatile semantics are not applied on an object under 
> > > > > construction.
> > > > > They come into effect when the constructor for the most derived 
> > > > > object ends."
> > > > >
> > > > > I handled this by keeping a hash set which tracks objects under 
> > > > > construction.
> > > > > I considered other options, such as going up call_stack, but that 
> > > > > wouldn't
> > > > > work with trivial constructor/op=.  It was also interesting to find 
> > > > > out that
> > > > > the definition of TREE_HAS_CONSTRUCTOR says "When appearing in a 
> > > > > FIELD_DECL,
> > > > > it means that this field has been duly initialized in its 
> > > > > constructor" though
> > > > > nowhere in the codebase do we set TREE_HAS_CONSTRUCTOR on a 
> > > > > FIELD_DECL as far
> > > > > as I can see.  Unfortunately, using this bit proved useless for my 
> > > > > needs here.
> > > >
> > > > > Also, be mindful of mutable subobjects.
> > > > >
> > > > > Does this approach look like an appropriate strategy for tracking 
> > > > > objects'
> > > > > construction?
> > > >
> > > > For scalar objects, we should be able to rely on INIT_EXPR vs. 
> > > > MODIFY_EXPR
> > > > to distinguish between initialization and modification; for class 
> > > > objects, I
> > >
> > > This is already true: only class object go into the hash set.
> > >
> > > > wonder about setting a flag on the CONSTRUCTOR after initialization is
> > > > complete to indicate that the value is now constant.
> > >
> > > But here we're not dealing with CONSTRUCTORs in the gcc sense (i.e. exprs 
> > > with
> > > TREE_CODE == CONSTRUCTOR).  We have a CALL_EXPR like Y::Y ((struct Y *) 
> > > ),
> > > which initializes the object "y".  Setting a flag on the CALL_EXPR or its 
> > > underlying
> > > function decl wouldn't help.
> > >
> > > Am I missing something?
> >
> > I was thinking that where in your current patch you call
> > remove_object_under_construction, we could instead mark the object's value
> > CONSTRUCTOR as immutable.
>
> Ah, what you meant was to look at DECL_INITIAL of the object we're
> constructing, which could be a CONSTRUCTOR.  Unfortunately, this
> DECL_INITIAL is null (in all the new tests when doing
> remove_object_under_construction), so there's nothing to mark as 
> TREE_READONLY :/.

There's a value in ctx->values, isn't there?

Jason

Re: [PATCH 0/3] add support for POD struct convention (PR 61339)

[Pedro Alves]

On 7/12/19 9:24 AM, Jakub Jelinek wrote:
> I'd just arrange that when being compiled with clang we compile with
> -Wno-mismatched-tags to get rid of their misdesigned warning and not add
> such misdesigned warning to GCC, that will just help people spread this
> weirdo requirement further.

FWIW and FYI, this is what GDB does (gdb/warning.m4).

Thanks,
Pedro Alves

Re: Monotonically increasing counter (was Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git)

[Jason Merrill]

On Mon, Aug 5, 2019 at 2:22 PM Jason Merrill  wrote:
> On 8/5/19 11:34 AM, Jakub Jelinek wrote:
> > On Mon, Aug 05, 2019 at 11:20:09AM -0400, Jason Merrill wrote:
> >> I agree.  But for those who want a monotonically increasing
> >> identifier, there's already one in git: CommitDate.  In the discussion
> >> of this issue four years ago,
> >
> > While commit date is monotonically increasing, it has the problem that at
> > certain dates there are very few commits, at others many.  When doing
> > bisection by hand, one does the revision computation (min+max)/2 in head
> > (it doesn't have to be precise of course, just roughly, and isn't perfect
> > either, because in svn all of trunk and branches contribute to the revision
> > numbers), with dates it would be division into further uneven chunks.
>
> That's true, but is it a major problem?  If you have multiple commits on
> one day, you (can) have multiple binaries with the same date and
> different times, and you can adjust your heuristic for choosing the next
> bisection point accordingly.  Over longer periods, the number of commits
> per day averages out.
>
> > Could we tag the branchpoints, say when we branch off gcc 10, we tag the
> > branchpoint as tags/r11 and then we could use r11-123 as 123th commit on the
> > trunk since the branchpoint, and let bugzilla and web redirection handle
> > those rNN- style identifiers?
> > git describe --all --match 'r[0-9]*' ... | sed ...
> > to map hashes etc. to these rNN- identifiers and something to map them
> > back to hashes say for git web?
>
> Well, having such tags would allow git describe to produce identifiers
> that you might find more readable.  For instance, if I do
>
> git tag -a -m 'GCC 9 branchpoint' b9 $(git merge-base trunk gcc-9-branch)

Though I guess what you were suggesting is slightly different: this
will put the tag in the history of both trunk and branch, and it would
be better for "r11" to be only in the history of GCC 11.  So probably
best to tag the commit that bumps BASE-VER instead, i.e.

$ git tag -a -m 'GCC 10 stage 1 open' gcc10
70f448fa5347ba24e0916201dd8549bc16783ff0
$ git tag -a -m 'GCC 9 stage 1 open' gcc9
949bc65ce4d0d7dd036ccfb279bffe63d02feee6
$ git tag -a -m 'GCC 8 stage 1 open' gcc8
498621e8159c1f494a9b8a5f2c3e5225c74ed242
...
$ git describe trunk
gcc10-2527-gac18cc031cd
$ git describe gcc-9-branch
gcc9-7633-g28a024c36af

Does this sound good to you?  Anyone have thoughts about naming for the tags?

Since alphabetical sorting won't do well with gcc9 and gcc10, you may
want to use the beginning of time tag for naming your binaries.  Also
because the stage 1 boundary isn't that interesting for bisection.

Jason

> git tag -a -m'Beginning of Time' r1 3cf0d8938a953ef13e57239613d42686f152b4fe
> git describe --match r1 trunk
>
> r1-170718-gdb868bacf6a
>
> These tags don't need to be shared, this works fine locally.
>
> Note that when you feed such an identifier to other git commands, they
> ignore the first two parts and just use the hash.
>
> This might be a good alternative to dates for you, and people could
> refer to them interchangeably with raw hashes in the web interface.

Re: Add TIGERLAKE and COOPERLAKE to GCC

[Jeff Law]

On 8/14/19 1:38 AM, Cui, Lili wrote:
> Resend this mail for GCC Patches rejected my message, thanks.
> 
> -Original Message-
> 
> Hi Uros and all:
> 
> This patch is about to add TIGERLAKE and COOPERLAKE to GCC.
> TIGERLAKE is based on ICELAKE_CLIENT and plus new ISA 
> MOVEDIRI/MOVDIR64B/AVX512VP2INTERSECT.
> COOPERLAKE is based on CASCADELAKE and plus new ISA AVX512BF16.
>  
> Bootstrap is ok, and no regressions for i386/x86-64 testsuite.
> 
> Changelog:
> gcc/
>   * common/config/i386/i386-common.c
>   (processor_names): Add tigerlake and cooperlake.
>   (processor_alias_table): Add tigerlake and cooperlake.
>   * config.gcc: Add -march=tigerlake and cooperlake.
>   * config/i386/driver-i386.c
>(host_detect_local_cpu): Detect tigerlake and cooperlake.
>   * config/i386/i386-builtins.c
>   (processor_model) : Add M_INTEL_COREI7_TIGERLAKE and 
> M_INTEL_COREI7_COOPERLAKE.
>   (arch_names_table): Add tigerlake and cooperlake.
>   (get_builtin_code_for_version) : Handle PROCESSOR_TIGERLAKE and 
> PROCESSOR_COOPERLAKE.
>   * config/i386/i386-c.c
>   (ix86_target_macros_internal): Handle tigerlake and cooperlake.
>   (ix86_target_macros_internal): Handle 
> OPTION_MASK_ISA_AVX512VP2INTERSECT.
>   * config/i386/i386-options.c
>   (m_TIGERLAKE)  : Define.
>   (m_COOPERLAKE) : Ditto.
>   (m_CORE_AVX512): Ditto.
>   (processor_cost_table): Add cascadelake.
>   (ix86_target_string)  : Handle -mavx512vp2intersect.
>   (ix86_valid_target_attribute_inner_p) : Handle avx512vp2intersect.
>   (ix86_option_override_internal): Hadle PTA_SHSTK, PTA_MOVDIRI,
>PTA_MOVDIR64B, PTA_AVX512VP2INTERSECT.
>   * config/i386/i386.h
>   (ix86_size_cost) : Define TARGET_TIGERLAKE and TARGET_COOPERLAKE.
>   (processor_type) : Add PROCESSOR_TIGERLAKE and PROCESSOR_COOPERLAKE.
>   (PTA_SHSTK) : Define.
>   (PTA_MOVDIRI): Ditto.
>   (PTA_MOVDIR64B): Ditto.
>   (PTA_COOPERLAKE) : Ditto.
>   (PTA_TIGERLAKE)  : Ditto.
>   (TARGET_AVX512VP2INTERSECT) : Ditto.
>   (TARGET_AVX512VP2INTERSECT_P(x)) : Ditto.
>   (processor_type) : Add PROCESSOR_TIGERLAKE and PROCESSOR_COOPERLAKE.
>   * doc/extend.texi: Add tigerlake and cooperlake.
> 
> gcc/testsuite/
>   * gcc.target/i386/funcspec-56.inc: Handle new march.
>   * g++.target/i386/mv16.C: Handle new march
> 
> libgcc/
>   * config/i386/cpuinfo.h: Add INTEL_COREI7_TIGERLAKE and 
> INTEL_COREI7_COOPERLAKE.
> 
ENOPATCH

Note that HJ's reworking of the cost tables may require this patch to
change for the trunk.

Jeff

Re: Add IFN_COND functions for shifting

[Jeff Law]

On 8/14/19 6:27 AM, Richard Sandiford wrote:
> This patch adds support for IFN_COND shifts left and shifts right.
> This is mostly mechanical, but since we try to handle conditional
> operations in the same way as unconditional operations in match.pd,
> we need to support IFN_COND shifts by scalars as well as vectors.
> E.g.:
> 
>IFN_COND_SHL (cond, a, { 1, 1, ... }, fallback)
> 
> and:
> 
>IFN_COND_SHL (cond, a, 1, fallback)
> 
> are the same operation, with:
> 
>(for shiftrotate (lrotate rrotate lshift rshift)
> ...
> /* Prefer vector1 << scalar to vector1 << vector2
>if vector2 is uniform.  */
> (for vec (VECTOR_CST CONSTRUCTOR)
>  (simplify
>   (shiftrotate @0 vec@1)
>   (with { tree tem = uniform_vector_p (@1); }
>(if (tem)
>   (shiftrotate @0 { tem; }))
> 
> preferring the latter.  The patch copes with this by extending
> create_convert_operand_from to handle scalar-to-vector conversions.
> 
> Tested on aarch64-linux-gnu (with and without SVE), aarch64_be-elf
> and x86_64-linux-gnu.  OK for the generic bits?
> 
> Richard
> 
> 
> 2019-08-14  Richard Sandiford  
>   Prathamesh Kulkarni  
> 
> gcc/
>   * internal-fn.def (IFN_COND_SHL, IFN_COND_SHR): New internal functions.
>   * internal-fn.c (FOR_EACH_CODE_MAPPING): Handle shifts.
>   * match.pd (UNCOND_BINARY, COND_BINARY): Likewise.
>   * optabs.def (cond_ashl_optab, cond_ashr_optab, cond_lshr_optab): New
>   optabs.
>   * optabs.h (create_convert_operand_from): Expand comment.
>   * optabs.c (maybe_legitimize_operand): Allow implicit broadcasts
>   when mapping scalar rtxes to vector operands.
>   * config/aarch64/iterators.md (SVE_INT_BINARY): Add ashift,
>   ashiftrt and lshiftrt.
>   (sve_int_op, sve_int_op_rev, sve_pred_int_rhs2_operand): Handle them.
>   * config/aarch64/aarch64-sve.md (*cond__2_const)
>   (*cond__any_const): New patterns.
> 
> gcc/testsuite/
>   * gcc.target/aarch64/sve/cond_shift_1.c: New test.
>   * gcc.target/aarch64/sve/cond_shift_1_run.c: Likewise.
>   * gcc.target/aarch64/sve/cond_shift_2.c: Likewise.
>   * gcc.target/aarch64/sve/cond_shift_2_run.c: Likewise.
>   * gcc.target/aarch64/sve/cond_shift_3.c: Likewise.
>   * gcc.target/aarch64/sve/cond_shift_3_run.c: Likewise.
>   * gcc.target/aarch64/sve/cond_shift_4.c: Likewise.
>   * gcc.target/aarch64/sve/cond_shift_4_run.c: Likewise.
>   * gcc.target/aarch64/sve/cond_shift_5.c: Likewise.
>   * gcc.target/aarch64/sve/cond_shift_5_run.c: Likewise.
>   * gcc.target/aarch64/sve/cond_shift_6.c: Likewise.
>   * gcc.target/aarch64/sve/cond_shift_6_run.c: Likewise.
>   * gcc.target/aarch64/sve/cond_shift_7.c: Likewise.
>   * gcc.target/aarch64/sve/cond_shift_7_run.c: Likewise.
>   * gcc.target/aarch64/sve/cond_shift_8.c: Likewise.
>   * gcc.target/aarch64/sve/cond_shift_8_run.c: Likewise.
>   * gcc.target/aarch64/sve/cond_shift_9.c: Likewise.
>   * gcc.target/aarch64/sve/cond_shift_9_run.c: Likewise.
Generic bits OK.
jeff

Re: [PATCH] Add generic support for "noinit" attribute

[Christophe Lyon]

On Wed, 14 Aug 2019 at 19:07, Christophe Lyon
 wrote:
>
> On Wed, 14 Aug 2019 at 17:59, Tamar Christina  wrote:
> >
> > Hi Christoph,
> >
> > The noinit testcase is currently failing on x86_64.
> >
> > Is the test supposed to be running there?
> >
> No, there's an effective-target to skip it.
> But I notice a typo:
> +/* { dg-require-effective-target noinit */
> (missing closing brace)
> Could it explain why it's failing on x86_64 ?

I fixed the typo as obvious in r274489.

>
> > Thanks,
> > Tamar
> >
> > -Original Message-
> > From: gcc-patches-ow...@gcc.gnu.org  On 
> > Behalf Of Christophe Lyon
> > Sent: Wednesday, August 14, 2019 2:18 PM
> > To: Christophe Lyon ; Martin Sebor 
> > ; gcc Patches ; Richard Earnshaw 
> > ; ni...@redhat.com; Jozef Lawrynowicz 
> > ; Richard Sandiford 
> > Subject: Re: [PATCH] Add generic support for "noinit" attribute
> >
> > On Wed, 14 Aug 2019 at 14:14, Richard Sandiford  
> > wrote:
> > >
> > > Sorry for the slow response, I'd missed that there was an updated patch...
> > >
> > > Christophe Lyon  writes:
> > > > 2019-07-04  Christophe Lyon  
> > > >
> > > >   * lib/target-supports.exp (check_effective_target_noinit): New
> > > >   proc.
> > > > * gcc.c-torture/execute/noinit-attribute.c: New test.
> > >
> > > Second line should be indented by tabs rather than spaces.
> > >
> > > > @@ -2224,6 +2234,54 @@ handle_weak_attribute (tree *node, tree name,
> > > >return NULL_TREE;
> > > >  }
> > > >
> > > > +/* Handle a "noinit" attribute; arguments as in struct
> > > > +   attribute_spec.handler.  Check whether the attribute is allowed
> > > > +   here and add the attribute to the variable decl tree or otherwise
> > > > +   issue a diagnostic.  This function checks NODE is of the expected
> > > > +   type and issues diagnostics otherwise using NAME.  If it is not of
> > > > +   the expected type *NO_ADD_ATTRS will be set to true.  */
> > > > +
> > > > +static tree
> > > > +handle_noinit_attribute (tree * node,
> > > > +   tree   name,
> > > > +   tree   args,
> > > > +   intflags ATTRIBUTE_UNUSED,
> > > > +   bool *no_add_attrs)
> > > > +{
> > > > +  const char *message = NULL;
> > > > +
> > > > +  gcc_assert (DECL_P (*node));
> > > > +  gcc_assert (args == NULL);
> > > > +
> > > > +  if (TREE_CODE (*node) != VAR_DECL)
> > > > +message = G_("%qE attribute only applies to variables");
> > > > +
> > > > +  /* Check that it's possible for the variable to have a section.
> > > > + */  else if ((TREE_STATIC (*node) || DECL_EXTERNAL (*node) || 
> > > > in_lto_p)
> > > > +&& DECL_SECTION_NAME (*node))
> > > > +message = G_("%qE attribute cannot be applied to variables "
> > > > +  "with specific sections");
> > > > +
> > > > +  if (!targetm.have_switchable_bss_sections)
> > > > +message = G_("%qE attribute is specific to ELF targets");
> > >
> > > Maybe make this an else if too?  Or make the VAR_DECL an else if if
> > > you think the ELF one should win.  Either way, it seems odd to have
> > > the mixture between else if and not.
> > >
> > Right, I changed this into an else if.
> >
> > > > +  if (message)
> > > > +{
> > > > +  warning (OPT_Wattributes, message, name);
> > > > +  *no_add_attrs = true;
> > > > +}
> > > > +  else
> > > > +  /* If this var is thought to be common, then change this.  Common
> > > > + variables are assigned to sections before the backend has a
> > > > + chance to process them.  Do this only if the attribute is
> > > > + valid.  */
> > >
> > > Comment should be indented two spaces more.
> > >
> > > > +if (DECL_COMMON (*node))
> > > > +  DECL_COMMON (*node) = 0;
> > > > +
> > > > +  return NULL_TREE;
> > > > +}
> > > > +
> > > > +
> > > >  /* Handle a "noplt" attribute; arguments as in
> > > > struct attribute_spec.handler.  */
> > > >
> > > > diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index
> > > > f2619e1..f1af1dc 100644
> > > > --- a/gcc/doc/extend.texi
> > > > +++ b/gcc/doc/extend.texi
> > > > @@ -7129,6 +7129,14 @@ The @code{visibility} attribute is described
> > > > in  The @code{weak} attribute is described in  @ref{Common Function
> > > > Attributes}.
> > > >
> > > > +@item noinit
> > > > +@cindex @code{noinit} variable attribute Any data with the
> > > > +@code{noinit} attribute will not be initialized by the C runtime
> > > > +startup code, or the program loader.  Not initializing data in this
> > > > +way can reduce program startup times.  Specific to ELF targets,
> > > > +this attribute relies on the linker to place such data in the right
> > > > +location.
> > >
> > > Maybe:
> > >
> > >This attribute is specific to ELF targets and relies on the linker to
> > >place such data in the right location.
> > >
> > Thanks, I thought I had chosen a nice turn of phrase :-)
> >
> >
> > > > diff --git a/gcc/testsuite/gcc.c-torture/execute/noinit-attribute.c
> > > > 

Re: enforce canonicalization of value_range's

[Jeff Law]

On 8/13/19 6:51 PM, Aldy Hernandez wrote:
>> Presumably this was better than moving the implementation earlier.
> 
> Actually, it was for ease of review.  I made some changes to the
> function, and I didn't want the reviewer to miss them because I had
> moved the function wholesale.  I can move the function earlier, after we
> agree on the changes (see below).
Either works for me.  I think there was an informal effort to avoid
these kinds of forward decls eons ago because our inliner sucked, but in
the IPA world order in the source file really shouldn't matter.

> 
>>
>> If we weren't on a path to kill VRP I'd probably suggest a distinct
>> effort to constify this code.  Some of the changes were a bit confusing
>> when it looked like we'd dropped a call to set the range of an object.
>> But those were just local copies, so setting the type/min/max directly
>> was actually fine.  constification would make this a bit clearer.  But
>> again, I don't think it's worth the effort given the long term
>> trajectory for tree-vrp.c.
> 
> I shouldn't be introducing any new confusion.  Did I add any new methods
> that should've been const that aren't?  I can't see any??.  I'm happy to
> fix anything I introduced.
IIRC we had an incoming range object passed by value, which we locally
modified and called the setter.

I spotted the dropped call to the setter and was going to call it out as
possibly broken.  But in investigating further I realized the object was
passed by value, so dropping the setter wasn't really a problem.

THe funny thing was we were doing this on source operands rather than
the destination operand.  Arguably the ranges for the source operands
should be constant which would have flagged that code as fishy from its
inception and I'm sure the code would have been restructured
appropriately and would have avoided the confusion.

So in summary, you didn't break anything.  It was a safe change you
made, but it wasn't immediately obvious it was safe.  If we had a
constified codebase the intent of the code would have been more obvious.


> 
>>
>>
>> So where does the handle_pointers stuff matter?   I'm a bit surprised we
>> have to do anything special for them.
> 
> I've learned to touch as little of VRP as is necessary, as changing
> anything to be more consistent breaks things in unexpected ways ;-).
> 
> In this particular case, TYPE_MIN_VALUE and TYPE_MAX_VALUE are not
> defined for pointers, and I didn't want to change the meaning of
> vrp_val_{min,max} throughout.  I was trying to minimize the changes to
> existing behavior.  If it bothers you too much, we could remove it as a
> follow up when we are sure there are no expected side-effects from the
> rest of the patch. ??
I don't mind exploring this as a follow-up.  I guess that a min/max
doesn't really have significant meaning for pointers.

I think rather than digging too deep into this, let's table it for now.
 I think the time to revisit will be as we work through removal of
tree-vrp at some point in the future.

> 
>>
>>
>> OK.  I don't expect the answers to the minor questions above will
>> ultimately change anything.
> 
> I could appreciate a final nod before I commit.  And even then, I will
> wait until the other patch is approved and commit them simultaneously.
> They are a bit intertwined.
I'm nodding :-)

jeff

Re: [PATCH 1/2] PR c++/91436 fix C++ dialect for std::make_unique fix-it hint

[David Malcolm]

On Wed, 2019-08-14 at 16:53 +0100, Jonathan Wakely wrote:
> On 14/08/19 10:39 -0400, David Malcolm wrote:
> > On Wed, 2019-08-14 at 12:02 +0100, Jonathan Wakely wrote:
> > > On 13/08/19 16:07 -0400, Jason Merrill wrote:
> > > > On 8/13/19 9:32 AM, Jonathan Wakely wrote:
> > > > > * g++.dg/lookup/missing-std-include-6.C: Don't check
> > > > > make_unique in
> > > > > test that runs for C++11.
> > > > 
> > > > I'm not comfortable removing this test coverage
> > > > entirely.  Doesn't
> > > > it
> > > > give a useful diagnostic in C++11 mode as well?
> > > 
> > > It does:
> > > 
> > > mu.cc:3:15: error: 'make_unique' is not a member of 'std'
> > > 3 | auto p = std::make_unique();
> > >   |   ^~~
> > > mu.cc:3:15: note: 'std::make_unique' is only available from C++14
> > > onwards
> > > mu.cc:3:27: error: expected primary-expression before 'int'
> > > 3 | auto p = std::make_unique();
> > >   |   ^~~
> > > 
> > > So we can add it to g++.dg/lookup/missing-std-include-8.C
> > > instead,
> > > which runs for c++98_only and checks for the "is only available
> > > for"
> > > cases. Here's a patch doing that.
> > 
> > FWIW this eliminates the testing that when we do have C++14
> > onwards,
> > that including  is suggested.
> 
> Do we really care?
> 
> Are we testing that *every* entry in the array gives the right answer
> for both missing-header and bad-std-option, or are we just testing a
> subset of them to be sure the logic works as expected?
> 
> Because if we're testing every entry then:
> 
> 1) we're missing LOTS of tests, and
> 
> 2) we're just as likely to test the wrong thing and not actually
> catch
>bugs (as was already happening for both make_unique and
>complex_literals).
> 
> > Maybe we need a C++14-onwards missing-std-include-* test, and to
> > move
> > the existing test there?  (and to add the new test for before-C++-
> > 14)
> 
> We could, but is it worth it?

Fair enough.

Dave

[COMMITTED] Set memory alignment in expand_builtin_init_descriptor

[Bernd Edlinger]

Committed as r274487 with approval in 
https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00974.html


Index: gcc/builtins.c
===
--- gcc/builtins.c  (revision 274486)
+++ gcc/builtins.c  (revision 274487)
@@ -5756,6 +5756,7 @@ expand_builtin_init_descriptor (tree exp)
   r_descr = expand_normal (t_descr);
   m_descr = gen_rtx_MEM (BLKmode, r_descr);
   MEM_NOTRAP_P (m_descr) = 1;
+  set_mem_align (m_descr, GET_MODE_ALIGNMENT (ptr_mode));
 
   r_func = expand_normal (t_func);
   r_chain = expand_normal (t_chain);
Index: gcc/ChangeLog
===
--- gcc/ChangeLog   (revision 274486)
+++ gcc/ChangeLog   (revision 274487)
@@ -1,3 +1,7 @@
+2019-08-14  Bernd Edlinger  
+
+   * builtins.c (expand_builtin_init_descriptor): Set memory alignment.
+
 2019-08-14  Martin Sebor  
 
PR tree-optimization/91294


Thanks
Bernd.

Re: types for VR_VARYING

[Jeff Law]

On 8/13/19 6:39 PM, Aldy Hernandez wrote:
> 
> 
> On 8/12/19 7:46 PM, Jeff Law wrote:
>> On 8/12/19 12:43 PM, Aldy Hernandez wrote:
>>> This is a fresh re-post of:
>>>
>>> https://gcc.gnu.org/ml/gcc-patches/2019-07/msg6.html
>>>
>>> Andrew gave me some feedback a week ago, and I obviously don't remember
>>> what it was because I was about to leave on PTO.  However, I do remember
>>> I addressed his concerns before getting drunk on rum in tropical islands.
>>>
>> FWIW found a great coffee infused rum while in Kauai last week.  I'm not
>> a coffee fan, but it was wonderful.  The one bottle we brought back
>> isn't going to last until Cauldron and I don't think I can get a special
>> order filled before I leave :(
> 
> You must bring some to Cauldron before we believe you. :)
That's the problem.  The nearest place I can get it is in Vegas and
there's no distributor in Montreal.   I can special order it in our
state run stores, but it won't be here in time.

Of course, I don't mind if you don't believe me.  More for me in that
case...


>> Is the supports_type_p stuff there to placate the calls from ipa-cp?  I
>> can live with it in the short term, but it really feels like there
>> should be something in the ipa-cp client that avoids this silliness.
> 
> I am not happy with this either, but there are various places where
> statements that are !stmt_interesting_for_vrp() are still setting a
> range of VARYING, which is then being ignored at a later time.
> 
> For example, vrp_initialize:
> 
>   if (!stmt_interesting_for_vrp (phi))
> {
>   tree lhs = PHI_RESULT (phi);
>   set_def_to_varying (lhs);
>   prop_set_simulate_again (phi, false);
> }
> 
> Also in evrp_range_analyzer::record_ranges_from_stmt(), where we if the
> statement is interesting for VRP but extract_range_from_stmt() does not
> produce a useful range, we also set a varying for a range we will never
> use.  Similarly for a statement that is not interesting in this hunk.
Ugh.  One could perhaps argue that setting any kind of range in these
circumstances is silly.   But I suspect it's necessary due to the
optimistic handling of VR_UNDEFINED in value_range_base::union_helper.
It's all coming back to me now...


> 
> Then there is vrp_prop::visit_stmt() where we also set VARYING for types
> that VRP will never handle:
> 
>   case IFN_ADD_OVERFLOW:
>   case IFN_SUB_OVERFLOW:
>   case IFN_MUL_OVERFLOW:
>   case IFN_ATOMIC_COMPARE_EXCHANGE:
> /* These internal calls return _Complex integer type,
>    which VRP does not track, but the immediate uses
>    thereof might be interesting.  */
> if (lhs && TREE_CODE (lhs) == SSA_NAME)
>   {
> imm_use_iterator iter;
> use_operand_p use_p;
> enum ssa_prop_result res = SSA_PROP_VARYING;
> 
> set_def_to_varying (lhs);
> 
> I've adjusted the patch so that set_def_to_varying will set the range to
> VR_UNDEFINED if !supports_type_p.  This is a fail safe, as we can't
> really do anything with a nonsensical range.  I just don't want to leave
> the range in an indeterminate state.
> 
I think VR_UNDEFINED is unsafe due to value_range_base::union_helper.
And that's a more general than this patch.  VR_UNDEFINED is _not_ a safe
range to set something to if we can't handle it.  We have to use VR_VARYING.

Why?  See the beginning of value_range_base::union_helper:

   /* VR0 has the resulting range if VR1 is undefined or VR0 is varying.  */
   if (vr1->undefined_p ()
   || vr0->varying_p ())
 return *vr0;

   /* VR1 has the resulting range if VR0 is undefined or VR1 is varying.  */
   if (vr0->undefined_p ()
   || vr1->varying_p ())
 return *vr1;
This can get called for something like

  a =  ? name1 : name2;

If name1 was set to VR_UNDEFINED thinking that VR_UNDEFINED was a safe
value for something we can't handle, then we'll incorrectly return the
range for name2.

VR_UNDEFINED can only be used for the ranges of objects we haven't
processed.  If we can't produce a range for an object because the
statement is something we don't handle or just doesn't produce anythign
useful, then the right result is VR_VARYING.

This may be worth commenting at the definition site for VR_*.

> 
> I also noticed that Andrew's patch was setting num_vr_values to
> num_ssa_names + num_ssa_names / 10.  I think he meant num_vr_values +
> num_vr_values / 10.  Please verify the current incantation makes sense.
Going to assume this will be adjusted per the other messages in this thread.


> diff --git a/gcc/tree-ssa-threadedge.c b/gcc/tree-ssa-threadedge.c
> index 39ea22f0554..663dd6e2398 100644
> --- a/gcc/tree-ssa-threadedge.c
> +++ b/gcc/tree-ssa-threadedge.c
> @@ -182,8 +182,10 @@ record_temporary_equivalences_from_phis (edge e,
>   new_vr->deep_copy (vr_values->get_value_range (src));
> else if (TREE_CODE (src) == INTEGER_CST)
>   new_vr->set (src);
> +   else if 

[PATCH] Simplify and generalize rust-demangle's unescaping logic.

[Eduard-Mihai Burtescu]

Previously, rust-demangle.c was special-casing a fixed number
of '$uXY$' escapes, but 'XY' can technically be any hex value,
representing some Unicode codepoint.

This patch adds more general support for '$u...$' escapes,
similar to https://github.com/alexcrichton/rustc-demangle/pull/29,
but only for the the ASCII subset. More complete Unicode support
may come at a later time, but right now I want to keep it simple.

Escapes that decode to ASCII control codes are considered invalid,
as the Rust compiler should never emit them, and to avoid any
undesirable effects from accidentally outputting a control code.

Additionally, the switch statements, which had one case for each
alphanumeric character, were replaced with if-else chains.

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

2019-08-14  Eduard-Mihai Burtescu  
libiberty/ChangeLog:
* rust-demangle.c (unescape): Remove.
(parse_lower_hex_nibble): New function.
(parse_legacy_escape): New function.
(is_prefixed_hash): Use parse_lower_hex_nibble.
(looks_like_rust): Use parse_legacy_escape.
(rust_demangle_sym): Use parse_legacy_escape.
* testsuite/rust-demangle-expected: Add 'llv$u6d$' test.

diff --git a/libiberty/rust-demangle.c b/libiberty/rust-demangle.c
index 2302db45b6f..da591902db1 100644
--- a/libiberty/rust-demangle.c
+++ b/libiberty/rust-demangle.c
@@ -50,7 +50,7 @@ extern void *memset(void *s, int c, size_t n);
 #include "rust-demangle.h"
 
 
-/* Mangled Rust symbols look like this:
+/* Mangled (legacy) Rust symbols look like this:
  
_$LT$std..sys..fd..FileDesc$u20$as$u20$core..ops..Drop$GT$::drop::hc68340e1baa4987a
 
The original symbol is:
@@ -74,16 +74,7 @@ extern void *memset(void *s, int c, size_t n);
">"  =>  $GT$
"("  =>  $LP$
")"  =>  $RP$
-   " "  =>  $u20$
-   "\"" =>  $u22$
-   "'"  =>  $u27$
-   "+"  =>  $u2b$
-   ";"  =>  $u3b$
-   "["  =>  $u5b$
-   "]"  =>  $u5d$
-   "{"  =>  $u7b$
-   "}"  =>  $u7d$
-   "~"  =>  $u7e$
+   "\u{XY}"  =>  $uXY$
 
A double ".." means "::" and a single "." means "-".
 
@@ -95,7 +86,8 @@ static const size_t hash_len = 16;
 
 static int is_prefixed_hash (const char *start);
 static int looks_like_rust (const char *sym, size_t len);
-static int unescape (const char **in, char **out, const char *seq, char value);
+static int parse_lower_hex_nibble (char nibble);
+static char parse_legacy_escape (const char **in);
 
 /* INPUT: sym: symbol that has been through C++ (gnu v3) demangling
 
@@ -149,7 +141,7 @@ is_prefixed_hash (const char *str)
   const char *end;
   char seen[16];
   size_t i;
-  int count;
+  int count, nibble;
 
   if (strncmp (str, hash_prefix, hash_prefix_len))
 return 0;
@@ -157,12 +149,12 @@ is_prefixed_hash (const char *str)
 
   memset (seen, 0, sizeof(seen));
   for (end = str + hash_len; str < end; str++)
-if (*str >= '0' && *str <= '9')
-  seen[*str - '0'] = 1;
-else if (*str >= 'a' && *str <= 'f')
-  seen[*str - 'a' + 10] = 1;
-else
-  return 0;
+{
+  nibble = parse_lower_hex_nibble (*str);
+  if (nibble < 0)
+return 0;
+  seen[nibble] = 1;
+}
 
   /* Count how many distinct digits seen */
   count = 0;
@@ -179,57 +171,17 @@ looks_like_rust (const char *str, size_t len)
   const char *end = str + len;
 
   while (str < end)
-switch (*str)
-  {
-  case '$':
-   if (!strncmp (str, "$C$", 3))
- str += 3;
-   else if (!strncmp (str, "$SP$", 4)
-|| !strncmp (str, "$BP$", 4)
-|| !strncmp (str, "$RF$", 4)
-|| !strncmp (str, "$LT$", 4)
-|| !strncmp (str, "$GT$", 4)
-|| !strncmp (str, "$LP$", 4)
-|| !strncmp (str, "$RP$", 4))
- str += 4;
-   else if (!strncmp (str, "$u20$", 5)
-|| !strncmp (str, "$u22$", 5)
-|| !strncmp (str, "$u27$", 5)
-|| !strncmp (str, "$u2b$", 5)
-|| !strncmp (str, "$u3b$", 5)
-|| !strncmp (str, "$u5b$", 5)
-|| !strncmp (str, "$u5d$", 5)
-|| !strncmp (str, "$u7b$", 5)
-|| !strncmp (str, "$u7d$", 5)
-|| !strncmp (str, "$u7e$", 5))
- str += 5;
-   else
- return 0;
-   break;
-  case '.':
-   /* Do not allow three or more consecutive dots */
-   if (!strncmp (str, "...", 3))
- return 0;
-   /* Fall through */
-  case 'a': case 'b': case 'c': case 'd': case 'e': case 'f':
-  case 'g': case 'h': case 'i': case 'j': case 'k': case 'l':
-  case 'm': case 'n': case 'o': case 'p': case 'q': case 'r':
-  case 's': case 't': case 'u': case 'v': case 'w': case 'x':
-  case 'y': case 'z':
-  case 'A': case 'B': case 'C': case 'D': case 'E': case 'F':
-  case 'G': case 'H': case 'I': case 'J': case 'K': case 'L':
-  case 'M': case 'N': case 'O': case 'P': case 'Q': case 'R':
-  case 'S': 

Re: Rewrite some jump.c routines to use flags

[Joseph Myers]

On Fri, 12 Jul 2019, Richard Sandiford wrote:

> At least AIUI, __builtin_isunordered etc. don't raise an exception even
> for signalling NaNs.

__builtin_isunordered should raise "invalid" for signaling NaNs.  
(isunordered is the IEEE 754 operation compareQuietUnordered, and IEEE 754 
specifies for comparisons that "Invalid operation is the only exception 
that a comparison predicate can signal. All predicates signal the invalid 
operation exception on signaling NaN operands. The predicates named Quiet 
shall not signal any exception, unless an operand is a signaling NaN. The 
predicates named Signaling shall signal the invalid operation exception on 
quiet NaN operands.".)

Note that __builtin_isunordered (x, x) is thus not the same as 
__builtin_isnan (x), because isnan binds to isNaN and isNaN is a 
non-computational operation for which IEEE 754 specifies "Implementations 
shall provide the following non-computational operations for all supported 
arithmetic formats and should provide them for all supported interchange 
formats. They are never exceptional, even for signaling NaNs.".

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

Re: [PATCH] Automatics in equivalence statements

[Jeff Law]

On 8/14/19 2:45 AM, Mark Eggleston wrote:
> I now have commit access.
> 
> gcc/fortran
> 
>     Jeff Law 
>     Mark Eggleston 
> 
>     * gfortran.h: Add gfc_check_conflict declaration.
>     * symbol.c (check_conflict): Rename cfg_check_conflict and remove
>     static.
>     * symbol.c (cfg_check_conflict): Remove automatic in equivalence
>     conflict check.
>     * symbol.c (save_symbol): Add check for in equivalence to stop the
>     the save attribute being added.
>     * trans-common.c (build_equiv_decl): Add is_auto parameter and
>     add !is_auto to condition where TREE_STATIC (decl) is set.
>     * trans-common.c (build_equiv_decl): Add local variable is_auto,
>     set it true if an atomatic attribute is encountered in the variable
>     list.  Call build_equiv_decl with is_auto as an additional parameter.
>     flag_dec_format_defaults is enabled.
>     * trans-common.c (accumulate_equivalence_attributes) : New subroutine.
>     * trans-common.c (find_equivalence) : New local variable dummy_symbol,
>     accumulated equivalence attributes from each symbol then check for
>     conflicts.
> 
> gcc/testsuite
> 
>     Mark Eggleston 
> 
>     * gfortran.dg/auto_in_equiv_1.f90: New test.
>     * gfortran.dg/auto_in_equiv_2.f90: New test.
>     * gfortran.dg/auto_in_equiv_3.f90: New test.
> 
> OK to commit?
> 
> How do I know that I have approval to commit?
Yes, this is OK to commit.  Steve acked it in a private message to me.

Normally you'll get an ACK/OK on the public list.  But private ACKs or
ACKs on IRC also count as approval :-)

jeff

Re: [PATCH] Add generic support for "noinit" attribute

[Christophe Lyon]

On Wed, 14 Aug 2019 at 17:59, Tamar Christina  wrote:
>
> Hi Christoph,
>
> The noinit testcase is currently failing on x86_64.
>
> Is the test supposed to be running there?
>
No, there's an effective-target to skip it.
But I notice a typo:
+/* { dg-require-effective-target noinit */
(missing closing brace)
Could it explain why it's failing on x86_64 ?

> Thanks,
> Tamar
>
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org  On Behalf 
> Of Christophe Lyon
> Sent: Wednesday, August 14, 2019 2:18 PM
> To: Christophe Lyon ; Martin Sebor 
> ; gcc Patches ; Richard Earnshaw 
> ; ni...@redhat.com; Jozef Lawrynowicz 
> ; Richard Sandiford 
> Subject: Re: [PATCH] Add generic support for "noinit" attribute
>
> On Wed, 14 Aug 2019 at 14:14, Richard Sandiford  
> wrote:
> >
> > Sorry for the slow response, I'd missed that there was an updated patch...
> >
> > Christophe Lyon  writes:
> > > 2019-07-04  Christophe Lyon  
> > >
> > >   * lib/target-supports.exp (check_effective_target_noinit): New
> > >   proc.
> > > * gcc.c-torture/execute/noinit-attribute.c: New test.
> >
> > Second line should be indented by tabs rather than spaces.
> >
> > > @@ -2224,6 +2234,54 @@ handle_weak_attribute (tree *node, tree name,
> > >return NULL_TREE;
> > >  }
> > >
> > > +/* Handle a "noinit" attribute; arguments as in struct
> > > +   attribute_spec.handler.  Check whether the attribute is allowed
> > > +   here and add the attribute to the variable decl tree or otherwise
> > > +   issue a diagnostic.  This function checks NODE is of the expected
> > > +   type and issues diagnostics otherwise using NAME.  If it is not of
> > > +   the expected type *NO_ADD_ATTRS will be set to true.  */
> > > +
> > > +static tree
> > > +handle_noinit_attribute (tree * node,
> > > +   tree   name,
> > > +   tree   args,
> > > +   intflags ATTRIBUTE_UNUSED,
> > > +   bool *no_add_attrs)
> > > +{
> > > +  const char *message = NULL;
> > > +
> > > +  gcc_assert (DECL_P (*node));
> > > +  gcc_assert (args == NULL);
> > > +
> > > +  if (TREE_CODE (*node) != VAR_DECL)
> > > +message = G_("%qE attribute only applies to variables");
> > > +
> > > +  /* Check that it's possible for the variable to have a section.
> > > + */  else if ((TREE_STATIC (*node) || DECL_EXTERNAL (*node) || in_lto_p)
> > > +&& DECL_SECTION_NAME (*node))
> > > +message = G_("%qE attribute cannot be applied to variables "
> > > +  "with specific sections");
> > > +
> > > +  if (!targetm.have_switchable_bss_sections)
> > > +message = G_("%qE attribute is specific to ELF targets");
> >
> > Maybe make this an else if too?  Or make the VAR_DECL an else if if
> > you think the ELF one should win.  Either way, it seems odd to have
> > the mixture between else if and not.
> >
> Right, I changed this into an else if.
>
> > > +  if (message)
> > > +{
> > > +  warning (OPT_Wattributes, message, name);
> > > +  *no_add_attrs = true;
> > > +}
> > > +  else
> > > +  /* If this var is thought to be common, then change this.  Common
> > > + variables are assigned to sections before the backend has a
> > > + chance to process them.  Do this only if the attribute is
> > > + valid.  */
> >
> > Comment should be indented two spaces more.
> >
> > > +if (DECL_COMMON (*node))
> > > +  DECL_COMMON (*node) = 0;
> > > +
> > > +  return NULL_TREE;
> > > +}
> > > +
> > > +
> > >  /* Handle a "noplt" attribute; arguments as in
> > > struct attribute_spec.handler.  */
> > >
> > > diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index
> > > f2619e1..f1af1dc 100644
> > > --- a/gcc/doc/extend.texi
> > > +++ b/gcc/doc/extend.texi
> > > @@ -7129,6 +7129,14 @@ The @code{visibility} attribute is described
> > > in  The @code{weak} attribute is described in  @ref{Common Function
> > > Attributes}.
> > >
> > > +@item noinit
> > > +@cindex @code{noinit} variable attribute Any data with the
> > > +@code{noinit} attribute will not be initialized by the C runtime
> > > +startup code, or the program loader.  Not initializing data in this
> > > +way can reduce program startup times.  Specific to ELF targets,
> > > +this attribute relies on the linker to place such data in the right
> > > +location.
> >
> > Maybe:
> >
> >This attribute is specific to ELF targets and relies on the linker to
> >place such data in the right location.
> >
> Thanks, I thought I had chosen a nice turn of phrase :-)
>
>
> > > diff --git a/gcc/testsuite/gcc.c-torture/execute/noinit-attribute.c
> > > b/gcc/testsuite/gcc.c-torture/execute/noinit-attribute.c
> > > new file mode 100644
> > > index 000..ffcf8c6
> > > --- /dev/null
> > > +++ b/gcc/testsuite/gcc.c-torture/execute/noinit-attribute.c
> > > @@ -0,0 +1,59 @@
> > > +/* { dg-do run } */
> > > +/* { dg-require-effective-target noinit */
> > > +/* { dg-options "-O2" } */
> > > +
> > > +/* This test checks that noinit 

Re: [PATCH 2/2] Clean next_nested properly.

[Jeff Law]

On 8/14/19 5:17 AM, Martin Liska wrote:
> 
> gcc/ChangeLog:
> 
> 2019-08-14  Martin Liska  
> 
>   PR ipa/91438
>   * cgraph.c (cgraph_node::remove): When setting
>   n->origin = NULL for all nested functions, reset
>   also next_nested.
> ---
>  gcc/cgraph.c | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
OK
jeff

Re: [PATCH 1/2] Add ::verify for cgraph_node::origin/nested/next_nested.

[Jeff Law]

On 8/14/19 5:15 AM, Martin Liska wrote:
> 
> gcc/ChangeLog:
> 
> 2019-08-14  Martin Liska  
> 
>   * cgraph.c (cgraph_node::verify_node): Verify origin, nested
>   and next_nested.
> ---
>  gcc/cgraph.c | 24 
>  1 file changed, 24 insertions(+)
> 
OK.
Jeff

Re: [PATCH] Make GIMPLE forwprop DCE dead stmts

[Jeff Law]

On 8/14/19 7:36 AM, Richard Biener wrote:
> 
> The following patch makes forwprop DCE the stmts that become dead
> because of propagation of copies and constants.  For this to work
> we actually have to do that reliably rather than relying on
> fold_stmt doing this for us.
> 
> This hits fortran/trans-intrinsic.c in a way that we do "interesting"
> jump threading exposing a bogus uninit warning.  I'll open a PR
> for this with an (unreduced) testcase after committing.
Feel free to mark it as a regression, if for no other reason than that
guarantees that I look at it during stage3/stage4.  I can adjust the
marker at that time based on what I find.

jeff

Re: types for VR_VARYING

[Jeff Law]

On 8/14/19 8:15 AM, Aldy Hernandez wrote:
> 
> 
> On 8/14/19 9:50 AM, Andrew MacLeod wrote:
>> On 8/13/19 8:39 PM, Aldy Hernandez wrote:
>>>
>>>
>>> Yes, it was 2X.
>>>
>>> I noticed that Richi made some changes to the lattice handling for
>>> VARYING while the discussion was on-going.  I missed these, and had
>>> failed to adapt the patch for it.  I would appreciate a final review
>>> of the attached patch, especially the vr-values.c changes, which I
>>> have modified to play nice with current trunk.
>>>
>>> I also noticed that Andrew's patch was setting num_vr_values to
>>> num_ssa_names + num_ssa_names / 10.  I think he meant num_vr_values +
>>> num_vr_values / 10.  Please verify the current incantation makes sense.
>>>
>> no, I meant num_ssa_names.  We are resizing the vector because
>> num_vr_values is out of date (and smaller than num_ssa_names is now),
>> so we need to resize the vector to be at least the number of
>> ssa-names... and I added 10% just in case we arent done adding new ones.
>>
>>
>> if num_vr_values is 100, and we've added 200 ssa-names, num_ssa_names
>> would now be 300.   if you resize based on num_vr_values, you could
>> still go off the end of the vector.
> 
> OK, I've changed the resize to allocate 2X as well.  So now we'll have:
> 
> +  unsigned int old_sz = num_vr_values;
> +  num_vr_values = num_ssa_names * 2;
> +  vr_value = XRESIZEVEC (value_range *, vr_value, num_vr_values);
> etc
> 
> And the original allocation will also be 2X.
I don't think we want the resize to be 2X, we've tried to get away from
those kinds of growth patterns.  The 10% from Andrew's patch seems like
a better choice for the resize.

jeff

Re: [SVE] PR86753

[Richard Biener]

On Wed, Aug 14, 2019 at 6:49 PM Richard Biener
 wrote:
>
> On Wed, Aug 14, 2019 at 5:06 PM Prathamesh Kulkarni
>  wrote:
> >
> > Hi,
> > The attached patch tries to fix PR86753.
> >
> > For following test:
> > void
> > f1 (int *restrict x, int *restrict y, int *restrict z)
> > {
> >   for (int i = 0; i < 100; ++i)
> > x[i] = y[i] ? z[i] : 10;
> > }
> >
> > vect dump shows:
> >   vect_cst__42 = { 0, ... };
> >   vect_cst__48 = { 0, ... };
> >
> >   vect__4.7_41 = .MASK_LOAD (vectp_y.5_38, 4B, loop_mask_40);
> >   _4 = *_3;
> >   _5 = z_12(D) + _2;
> >   mask__35.8_43 = vect__4.7_41 != vect_cst__42;
> >   _35 = _4 != 0;
> >   vec_mask_and_46 = mask__35.8_43 & loop_mask_40;
> >   vect_iftmp.11_47 = .MASK_LOAD (vectp_z.9_44, 4B, vec_mask_and_46);
> >   iftmp.0_13 = 0;
> >   vect_iftmp.12_50 = VEC_COND_EXPR  > vect_iftmp.11_47, vect_cst__49>;
> >
> > and following code-gen:
> > L2:
> > ld1wz0.s, p2/z, [x1, x3, lsl 2]
> > cmpne   p1.s, p3/z, z0.s, #0
> > cmpne   p0.s, p2/z, z0.s, #0
> > ld1wz0.s, p0/z, [x2, x3, lsl 2]
> > sel z0.s, p1, z0.s, z1.s
> >
> > We could reuse vec_mask_and_46 in vec_cond_expr since the conditions
> > vect__4.7_41 != vect_cst__48 and vect__4.7_41 != vect_cst__42
> > are equivalent, and vect_iftmp.11_47 depends on vect__4.7_41 != 
> > vect_cst__48.
> >
> > I suppose in general for vec_cond_expr  if T comes from masked 
> > load,
> > which is conditional on C, then we could reuse the mask used in load,
> > in vec_cond_expr ?
> >
> > The patch maintains a hash_map cond_to_vec_mask
> > from  vec_mask (with loop predicate applied).
> > In prepare_load_store_mask, we record  -> vec_mask & 
> > loop_mask,
> > and in vectorizable_condition, we check if  exists in
> > cond_to_vec_mask
> > and if found, the corresponding vec_mask is used as 1st operand of
> > vec_cond_expr.
> >
> >  is represented with cond_vmask_key, and the patch
> > adds tree_cond_ops to represent condition operator and operands coming
> > either from cond_expr
> > or a gimple comparison stmt. If the stmt is not comparison, it returns
> >  and inserts that into cond_to_vec_mask.
> >
> > With patch, the redundant p1 is eliminated and sel uses p0 for above test.
> >
> > For following test:
> > void
> > f2 (int *restrict x, int *restrict y, int *restrict z, int fallback)
> > {
> >   for (int i = 0; i < 100; ++i)
> > x[i] = y[i] ? z[i] : fallback;
> > }
> >
> > input to vectorizer has operands swapped in cond_expr:
> >   _36 = _4 != 0;
> >   iftmp.0_14 = .MASK_LOAD (_5, 32B, _36);
> >   iftmp.0_8 = _4 == 0 ? fallback_12(D) : iftmp.0_14;
> >
> > So we need to check for inverted condition in cond_to_vec_mask,
> > and swap the operands.
> > Does the patch look OK so far ?
> >
> > One major issue remaining with the patch is value  numbering.
> > Currently, it does value numbering for entire function using sccvn
> > during start of vect pass, which is too expensive since we only need
> > block based VN. I am looking into that.
>
> Why do you need it at all?  We run VN on the if-converted loop bodies btw.

Also I can't trivially see the equality of the masks and probably so can't VN.
Is it that we just don't bother to apply loop_mask to VEC_COND but there's
no harm if we do?

Richard.

> Richard.
>
> >
> > Thanks,
> > Prathamesh

Re: [SVE] PR86753

[Richard Biener]

On Wed, Aug 14, 2019 at 5:06 PM Prathamesh Kulkarni
 wrote:
>
> Hi,
> The attached patch tries to fix PR86753.
>
> For following test:
> void
> f1 (int *restrict x, int *restrict y, int *restrict z)
> {
>   for (int i = 0; i < 100; ++i)
> x[i] = y[i] ? z[i] : 10;
> }
>
> vect dump shows:
>   vect_cst__42 = { 0, ... };
>   vect_cst__48 = { 0, ... };
>
>   vect__4.7_41 = .MASK_LOAD (vectp_y.5_38, 4B, loop_mask_40);
>   _4 = *_3;
>   _5 = z_12(D) + _2;
>   mask__35.8_43 = vect__4.7_41 != vect_cst__42;
>   _35 = _4 != 0;
>   vec_mask_and_46 = mask__35.8_43 & loop_mask_40;
>   vect_iftmp.11_47 = .MASK_LOAD (vectp_z.9_44, 4B, vec_mask_and_46);
>   iftmp.0_13 = 0;
>   vect_iftmp.12_50 = VEC_COND_EXPR  vect_iftmp.11_47, vect_cst__49>;
>
> and following code-gen:
> L2:
> ld1wz0.s, p2/z, [x1, x3, lsl 2]
> cmpne   p1.s, p3/z, z0.s, #0
> cmpne   p0.s, p2/z, z0.s, #0
> ld1wz0.s, p0/z, [x2, x3, lsl 2]
> sel z0.s, p1, z0.s, z1.s
>
> We could reuse vec_mask_and_46 in vec_cond_expr since the conditions
> vect__4.7_41 != vect_cst__48 and vect__4.7_41 != vect_cst__42
> are equivalent, and vect_iftmp.11_47 depends on vect__4.7_41 != vect_cst__48.
>
> I suppose in general for vec_cond_expr  if T comes from masked load,
> which is conditional on C, then we could reuse the mask used in load,
> in vec_cond_expr ?
>
> The patch maintains a hash_map cond_to_vec_mask
> from  vec_mask (with loop predicate applied).
> In prepare_load_store_mask, we record  -> vec_mask & 
> loop_mask,
> and in vectorizable_condition, we check if  exists in
> cond_to_vec_mask
> and if found, the corresponding vec_mask is used as 1st operand of
> vec_cond_expr.
>
>  is represented with cond_vmask_key, and the patch
> adds tree_cond_ops to represent condition operator and operands coming
> either from cond_expr
> or a gimple comparison stmt. If the stmt is not comparison, it returns
>  and inserts that into cond_to_vec_mask.
>
> With patch, the redundant p1 is eliminated and sel uses p0 for above test.
>
> For following test:
> void
> f2 (int *restrict x, int *restrict y, int *restrict z, int fallback)
> {
>   for (int i = 0; i < 100; ++i)
> x[i] = y[i] ? z[i] : fallback;
> }
>
> input to vectorizer has operands swapped in cond_expr:
>   _36 = _4 != 0;
>   iftmp.0_14 = .MASK_LOAD (_5, 32B, _36);
>   iftmp.0_8 = _4 == 0 ? fallback_12(D) : iftmp.0_14;
>
> So we need to check for inverted condition in cond_to_vec_mask,
> and swap the operands.
> Does the patch look OK so far ?
>
> One major issue remaining with the patch is value  numbering.
> Currently, it does value numbering for entire function using sccvn
> during start of vect pass, which is too expensive since we only need
> block based VN. I am looking into that.

Why do you need it at all?  We run VN on the if-converted loop bodies btw.

Richard.

>
> Thanks,
> Prathamesh

Re: [PATCH] fix and improve strlen conditional handling of merged stores (PR 91183, 91294, 91315)

[Martin Sebor]

Do you want me to post another revision with
the gimple_assign_single_p test removed?

I think remove that hunk, bootstrap, test, commit and post for archival
purposes.  I do not think another round of review is necessary.


Done in r274486 (also attached).


I should add that the early store merging on loosely aligned
targets makes the strlen tests prone to failures on strictly
aligned targets (or even ILP32 targets).  The handle_store
function can now deal with all sorts of MEM_REF assignments
that result from the store merging, but because
the handle_builtin_memcpy function lacks the same support,
the tests that expect the assignments to be folded fail when
they are not merged.  For example, the strlen call below is
folded on i386:

  const char a4[32] = "0123";
  const char b4[32] = "3210";

  void f (int i)
  {
char a[32];
memcpy (a, i ? a4 + 1 : b4, 8);   // copy just 8 bytes
if (strlen (a) < 3)
  abort ();
  }

but the equivalent call below is not:

  void g (int i)
  {
char a[32];
memcpy (a, i ? a4 + 1 : b4, 16);   // copy 16 bytes
if (strlen (a) < 3)
  abort ();
  }

This pattern may not be very common in the wild but having
the pass behave consistently without these target dependencies
would be helpful in avoiding these test failures.  I will try
to remember to extend the same enhancement as in handle_store
to handle_builtin_memcpy (ideally by factoring the code out
of handle_store into a helper and letting both functions call
it to do the folding).

Martin

Re: [PATCH] fix and improve strlen conditional handling of merged stores (PR 91183, 91294, 91315)

[Martin Sebor]

On 8/12/19 1:57 PM, Jeff Law wrote:

On 8/9/19 5:42 PM, Martin Sebor wrote:

@@ -3408,7 +3457,13 @@ static bool
   }
       gimple *stmt = SSA_NAME_DEF_STMT (exp);
-  if (gimple_code (stmt) != GIMPLE_PHI)
+  if (gimple_assign_single_p (stmt))
+    {
+  tree rhs = gimple_assign_rhs1 (stmt);
+  return count_nonzero_bytes (rhs, offset, nbytes, lenrange,
nulterm,
+  allnul, allnonnul, snlim);
+    }
+  else if (gimple_code (stmt) != GIMPLE_PHI)
   return false;

What cases are you handling here?  Are there any cases where a single
operand expression on the RHS affects the result.  For example, if we've
got a NOP_EXPR which zero extends RHS?  Does that change the nonzero
bytes in a way that is significant?

I'm not opposed to handling single operand objects here, I'm just
concerned that we're being very lenient in just stripping away the
operator and looking at the underlying object.


I remember adding the code because of a test failure but not
the specifics anymore.  No tests fail with it removed so it
may not be needed.  As you know, I've been juggling a few
enhancements in this area and copying code between them as
I need it so it's possible that I copied too much, or that
some other change has obviated it, or also that the test
failed somewhere else and I forgot to copy the test along
with the code  I'll remove it until it's needed.

Let's pull it for now.  If we come across the need again, we can
obviously revisit with a testcase.





@@ -3795,7 +3824,14 @@ handle_store (gimple_stmt_iterator *gsi)
   }
     else
   si->nonzero_chars = build_int_cst (size_type_node, offset);
-  si->full_string_p = full_string_p;
+
+  /* Set FULL_STRING_P only if the length of the strings being
+ written is the same, and clear it if the strings have
+ different lengths.  In the latter case the length stored
+ in si->NONZERO_CHARS becomes the lower bound.
+ FIXME: Handle the upper bound of the length if possible.  */
+  si->full_string_p = full_string_p && lenrange[0] == lenrange[1];

So there seems to be a disconnect between the comment and the code.

The comment indicates you care about the lengths of the two strings
being the same.  But what you're really comparing when the lenrange[0]
== lenrange[1] test is that the min and max of RHS are the same.


The comment tries to make clear that all the arrays on the RHS
of the assignment must have the same length in order to set
FULL_STRING_P.  Like here where LENRANGE = { 4, 4, 4 }:

   void f (char *s)
   {
     if (__builtin_strlen (s) != 2)
   return;

     *(int*)a = i ? 0x : 0x;
   }

but not here where LENRANGE = { 1, 4, 4 }:

     *(int*)a = i < 0 ? 0x : i ? 0x0022 : 0x3300;

If the bounds of the range of lengths of all the strings on
the RHS are the same they're all the same length.

I'm open to phrasing it better.

Oh, I think I see what I was missing.  In the case where RHS is a
conditional (or perhaps a SSA_NAME which was set from a PHI) LENRANGE
will have the min/max/# bytes for the RHS was a whole, not just a single
component of the RHS.



It generally looks reasonable, so I think we just need to reach a
conclusion on the gimple_assign_single_p cases we're trying to handle
and the possible mismatch between the comment and the code.


Do you want me to post another revision with
the gimple_assign_single_p test removed?

I think remove that hunk, bootstrap, test, commit and post for archival
purposes.  I do not think another round of review is necessary.


Done in r274486 (also attached).

Martin
Index: gcc/tree-ssa-strlen.c
===
--- gcc/tree-ssa-strlen.c	(revision 274485)
+++ gcc/tree-ssa-strlen.c	(revision 274486)
@@ -1195,14 +1195,13 @@ adjust_last_stmt (strinfo *si, gimple *stmt, bool
to constants.  */
 
 tree
-set_strlen_range (tree lhs, wide_int max, tree bound /* = NULL_TREE */)
+set_strlen_range (tree lhs, wide_int min, wide_int max,
+		  tree bound /* = NULL_TREE */)
 {
   if (TREE_CODE (lhs) != SSA_NAME
   || !INTEGRAL_TYPE_P (TREE_TYPE (lhs)))
 return NULL_TREE;
 
-  wide_int min = wi::zero (max.get_precision ());
-
   if (bound)
 {
   /* For strnlen, adjust MIN and MAX as necessary.  If the bound
@@ -1312,7 +1311,8 @@ maybe_set_strlen_range (tree lhs, tree src, tree b
 	}
 }
 
-  return set_strlen_range (lhs, max, bound);
+  wide_int min = wi::zero (max.get_precision ());
+  return set_strlen_range (lhs, min, max, bound);
 }
 
 /* Handle a strlen call.  If strlen of the argument is known, replace
@@ -1434,6 +1434,12 @@ handle_builtin_strlen (gimple_stmt_iterator *gsi)
 		  tree adj = fold_build2_loc (loc, MINUS_EXPR,
 	  TREE_TYPE (lhs), lhs, old);
 		  adjust_related_strinfos (loc, si, adj);
+		  /* Use the constant minimim length as the lower bound
+		 of the non-constant length.  */
+		  wide_int min = 

Re: [PATCH 0/3] Libsanitizer: merge from trunk

[Jeff Law]

On 8/14/19 2:50 AM, Martin Liška wrote:
> On 8/13/19 5:02 PM, Jeff Law wrote:
>> On 8/13/19 7:07 AM, Martin Liska wrote:
>>> Hi.
>>>
>>> For this year, I decided to make a first merge now and the
>>> next (much smaller) at the end of October.
>>>
>>> The biggest change is rename of many files from .cc to .cpp.
>>>
>>> I bootstrapped the patch set on x86_64-linux-gnu and run
>>> asan/ubsan/tsan tests on x86_64, ppc64le (power8) and
>>> aarch64.
>>>
>>> Libasan SONAME has been already bumped compared to GCC 9.
>>>
>>> For other libraries, I don't see a reason for library bumping:
>>>
>>> $ abidiff /usr/lib64/libubsan.so.1.0.0 
>>> ./x86_64-pc-linux-gnu/libsanitizer/ubsan/.libs/libubsan.so.1.0.0 --stat
>>> Functions changes summary: 0 Removed, 0 Changed, 4 Added functions
>>> Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
>>> Function symbols changes summary: 3 Removed, 0 Added function symbols not 
>>> referenced by debug info
>>> Variable symbols changes summary: 0 Removed, 0 Added variable symbol not 
>>> referenced by debug info
>>>
>>> $ abidiff /usr/lib64/libtsan.so.0.0.0  
>>> ./x86_64-pc-linux-gnu/libsanitizer/tsan/.libs/libtsan.so.0.0.0 --stat
>>> Functions changes summary: 0 Removed, 0 Changed, 47 Added functions
>>> Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
>>> Function symbols changes summary: 1 Removed, 2 Added function symbols not 
>>> referenced by debug info
>>> Variable symbols changes summary: 0 Removed, 0 Added variable symbol not 
>>> referenced by debug info
>>>
>>> Ready to be installed?
>> ISTM that a sanitizer merge during stage1 should be able to move forward
>> without ACKs.  Similarly for other runtimes where we pull from some
>> upstream master.
> 
> Good then. I've just installed the patch and also the refresh of 
> LOCAL_PATCHES.
Sounds good.  My tester will spin them on a variety of platforms over
the next couple days.  I won't be at all surprised if the MIPS bits are
still flakey.

Jeff

Re: [PATCH] fold more string comparison with known result (PR 90879)

[Martin Sebor]

On 8/12/19 7:40 AM, Michael Matz wrote:

Hi,

On Fri, 9 Aug 2019, Martin Sebor wrote:


The solution introduced in C99 is a flexible array.  C++
compilers usually support it as well.  Those that don't are
likely to support the zero-length array (even Visual C++ does).
If there's a chance that some don't support either do you really
think it's safe to assume they will do something sane with
the [1] hack?


As the [1] "hack" is the traditional pre-C99 (and C++) idiom to
implement flexible trailing char arrays, yes, I do expect all existing
(and not any more existing) compilers to do the obvious and sane thing
with it.  IOW: it's more portable in practice than our documented
zero-length extension.  And that's what matters for the things compiled by
the host compiler.

Without requiring C99 (which would be a different discussion) and a
non-existing C++ standard we can't write this code (in this form) in a
standard conforming way, no matter what we wish for.  Hence it seems
prudent to use the most portable variant of all the non-standard ways, the
trailing [1] array.


There are a few reasons why these legacy C idioms should be
replaced with better/newer/safer alternatives.

First, with two C revisions since C99 and with support for
superior alternatives widely available, pre-C99 idioms have less
and less relevance.

Second, since most of GCC requires a C++98 compiler to compile,
ancient C code needs to adjust to the more strict C++ requirements.
As C++ evolves, dependencies on legacy extensions like this one
make it increasingly difficult to upgrade to newer revisions of
the standard.  C++ 11 already requires compilers to reject
undefined behavior in constexpr contexts, including accesses
to arrays outside of their bounds.  Once GCC adopts C++ 11 it
won't be able to make use of constexpr with code that relies
on the hack.

Third, the safest and most secure approach to dealing with past-
the-end accesses is to diagnose and prevent them.  Accommodating
code that disregards the array bounds compromises this goal.  This
is evident from the gaps in _FORTIFY_SOURCE and -Wstringop-overflow
that other compilers like Clang and ICC don't suffer from(*).  It's
in everyone's best interest to proactively drive them to extinction
and replace them by safer alternatives that let compilers distinguish
the intentional accesses from accidental ones.  It not only makes it
easier to find bugs but also emit more efficient object code.

Martin

PS Unlike GCC, both Clang and ICC diagnose past-the-end accesses
to trailing arrays with more than one element.  They do recognize
the struct hack even in C++ and, outside constexpr contexts, avoid
diagnosing past-the-end accesses to trailing one-element arrays.
This isn't so much an issue today because neither allows statically
initializing struct objects with such arrays to more elements than
the bound specifies.  But it will likely change when the C++
proposal for constexpr functions to use new expressions is adopted 
(P0784R1).

Re: [PATCH 2/3] C++20 constexpr lib part 2/3 - swappish functions.

[Jonathan Wakely]

On 14/08/19 11:06 -0400, Ed Smith-Rowland wrote:

I this OK after it passes testing?

Ed






2019-08-14  Edward Smith-Rowland  <3dw...@verizon.net>

Implement C++20 p0879 - Constexpr for swap and swap related functions.
* include/bits/algorithmfwd.h (__cpp_lib_constexpr_swap_algorithms):
New macro.
* include/std/version: Ditto.


It looks like this line was inserted in the wrong place, as the lines
that follow it are not part of . The entry for
include/std/version should be after include/std/type_traits.



(iter_swap, make_heap, next_permutation, partial_sort_copy, pop_heap)
(prev_permutation, push_heap, reverse, rotate, sort_heap, swap)
(swap_ranges, nth_element, partial_sort, sort): Add constexpr.
* include/bits/move.h (swap): Add constexpr.
* include/bits/stl_algo.h (__move_median_to_first, __reverse, reverse)
(__gcd, __rotate, rotate, __partition, __heap_select)
(__partial_sort_copy, partial_sort_copy, __unguarded_partition)
(__unguarded_partition_pivot, __partial_sort, __introsort_loop, __sort)
(__introselect, __chunk_insertion_sort, next_permutation)
(prev_permutation, partition, partial_sort, nth_element, sort)
(__iter_swap::iter_swap, iter_swap, swap_ranges): Add constexpr.
* include/bits/stl_algobase.h (__iter_swap::iter_swap, iter_swap)
(swap_ranges): Add constexpr.
* include/bits/stl_heap.h (__push_heap, push_heap, __adjust_heap,
__pop_heap, pop_heap, __make_heap, make_heap, __sort_heap, sort_heap):
Add constexpr.
* include/std/type_traits (swap): Add constexpr.


i.e. here.

OK for trunk with that change if testing passes. Thanks!

RE: [PATCH] Add generic support for "noinit" attribute

[Tamar Christina]

Hi Christoph,

The noinit testcase is currently failing on x86_64.

Is the test supposed to be running there?

Thanks,
Tamar

-Original Message-
From: gcc-patches-ow...@gcc.gnu.org  On Behalf 
Of Christophe Lyon
Sent: Wednesday, August 14, 2019 2:18 PM
To: Christophe Lyon ; Martin Sebor 
; gcc Patches ; Richard Earnshaw 
; ni...@redhat.com; Jozef Lawrynowicz 
; Richard Sandiford 
Subject: Re: [PATCH] Add generic support for "noinit" attribute

On Wed, 14 Aug 2019 at 14:14, Richard Sandiford  
wrote:
>
> Sorry for the slow response, I'd missed that there was an updated patch...
>
> Christophe Lyon  writes:
> > 2019-07-04  Christophe Lyon  
> >
> >   * lib/target-supports.exp (check_effective_target_noinit): New
> >   proc.
> > * gcc.c-torture/execute/noinit-attribute.c: New test.
>
> Second line should be indented by tabs rather than spaces.
>
> > @@ -2224,6 +2234,54 @@ handle_weak_attribute (tree *node, tree name,
> >return NULL_TREE;
> >  }
> >
> > +/* Handle a "noinit" attribute; arguments as in struct
> > +   attribute_spec.handler.  Check whether the attribute is allowed
> > +   here and add the attribute to the variable decl tree or otherwise
> > +   issue a diagnostic.  This function checks NODE is of the expected
> > +   type and issues diagnostics otherwise using NAME.  If it is not of
> > +   the expected type *NO_ADD_ATTRS will be set to true.  */
> > +
> > +static tree
> > +handle_noinit_attribute (tree * node,
> > +   tree   name,
> > +   tree   args,
> > +   intflags ATTRIBUTE_UNUSED,
> > +   bool *no_add_attrs)
> > +{
> > +  const char *message = NULL;
> > +
> > +  gcc_assert (DECL_P (*node));
> > +  gcc_assert (args == NULL);
> > +
> > +  if (TREE_CODE (*node) != VAR_DECL)
> > +message = G_("%qE attribute only applies to variables");
> > +
> > +  /* Check that it's possible for the variable to have a section.  
> > + */  else if ((TREE_STATIC (*node) || DECL_EXTERNAL (*node) || in_lto_p)
> > +&& DECL_SECTION_NAME (*node))
> > +message = G_("%qE attribute cannot be applied to variables "
> > +  "with specific sections");
> > +
> > +  if (!targetm.have_switchable_bss_sections)
> > +message = G_("%qE attribute is specific to ELF targets");
>
> Maybe make this an else if too?  Or make the VAR_DECL an else if if 
> you think the ELF one should win.  Either way, it seems odd to have 
> the mixture between else if and not.
>
Right, I changed this into an else if.

> > +  if (message)
> > +{
> > +  warning (OPT_Wattributes, message, name);
> > +  *no_add_attrs = true;
> > +}
> > +  else
> > +  /* If this var is thought to be common, then change this.  Common
> > + variables are assigned to sections before the backend has a
> > + chance to process them.  Do this only if the attribute is
> > + valid.  */
>
> Comment should be indented two spaces more.
>
> > +if (DECL_COMMON (*node))
> > +  DECL_COMMON (*node) = 0;
> > +
> > +  return NULL_TREE;
> > +}
> > +
> > +
> >  /* Handle a "noplt" attribute; arguments as in
> > struct attribute_spec.handler.  */
> >
> > diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index 
> > f2619e1..f1af1dc 100644
> > --- a/gcc/doc/extend.texi
> > +++ b/gcc/doc/extend.texi
> > @@ -7129,6 +7129,14 @@ The @code{visibility} attribute is described 
> > in  The @code{weak} attribute is described in  @ref{Common Function 
> > Attributes}.
> >
> > +@item noinit
> > +@cindex @code{noinit} variable attribute Any data with the 
> > +@code{noinit} attribute will not be initialized by the C runtime 
> > +startup code, or the program loader.  Not initializing data in this 
> > +way can reduce program startup times.  Specific to ELF targets, 
> > +this attribute relies on the linker to place such data in the right 
> > +location.
>
> Maybe:
>
>This attribute is specific to ELF targets and relies on the linker to
>place such data in the right location.
>
Thanks, I thought I had chosen a nice turn of phrase :-)


> > diff --git a/gcc/testsuite/gcc.c-torture/execute/noinit-attribute.c 
> > b/gcc/testsuite/gcc.c-torture/execute/noinit-attribute.c
> > new file mode 100644
> > index 000..ffcf8c6
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.c-torture/execute/noinit-attribute.c
> > @@ -0,0 +1,59 @@
> > +/* { dg-do run } */
> > +/* { dg-require-effective-target noinit */
> > +/* { dg-options "-O2" } */
> > +
> > +/* This test checks that noinit data is handled correctly.  */
> > +
> > +extern void _start (void) __attribute__ ((noreturn)); extern void 
> > +abort (void) __attribute__ ((noreturn)); extern void exit (int) 
> > +__attribute__ ((noreturn));
> > +
> > +int var_common;
> > +int var_zero = 0;
> > +int var_one = 1;
> > +int __attribute__((noinit)) var_noinit; int var_init = 2;
> > +
> > +int __attribute__((noinit)) func(); /* { dg-warning "attribute only 
> > +applies to variables" } */ int 

Re: [PATCH 1/2] PR c++/91436 fix C++ dialect for std::make_unique fix-it hint

[Jonathan Wakely]

On 14/08/19 10:39 -0400, David Malcolm wrote:

On Wed, 2019-08-14 at 12:02 +0100, Jonathan Wakely wrote:

On 13/08/19 16:07 -0400, Jason Merrill wrote:
> On 8/13/19 9:32 AM, Jonathan Wakely wrote:
> > * g++.dg/lookup/missing-std-include-6.C: Don't check
> > make_unique in
> > test that runs for C++11.
>
> I'm not comfortable removing this test coverage entirely.  Doesn't
> it
> give a useful diagnostic in C++11 mode as well?

It does:

mu.cc:3:15: error: 'make_unique' is not a member of 'std'
3 | auto p = std::make_unique();
  |   ^~~
mu.cc:3:15: note: 'std::make_unique' is only available from C++14
onwards
mu.cc:3:27: error: expected primary-expression before 'int'
3 | auto p = std::make_unique();
  |   ^~~

So we can add it to g++.dg/lookup/missing-std-include-8.C instead,
which runs for c++98_only and checks for the "is only available for"
cases. Here's a patch doing that.


FWIW this eliminates the testing that when we do have C++14 onwards,
that including  is suggested.


Do we really care?

Are we testing that *every* entry in the array gives the right answer
for both missing-header and bad-std-option, or are we just testing a
subset of them to be sure the logic works as expected?

Because if we're testing every entry then:

1) we're missing LOTS of tests, and

2) we're just as likely to test the wrong thing and not actually catch
  bugs (as was already happening for both make_unique and
  complex_literals).


Maybe we need a C++14-onwards missing-std-include-* test, and to move
the existing test there?  (and to add the new test for before-C++-14)


We could, but is it worth it?

Re: [PATCH 2/3] C++20 constexpr lib part 2/3 - swappish functions.

[Ed Smith-Rowland via gcc-patches]

On 8/13/19 7:14 AM, Jonathan Wakely wrote:

On 01/08/19 13:16 -0400, Ed Smith-Rowland via libstdc++ wrote:

Greetings,

Here is a patch for C++20 p0879 - Constexpr for swap and swap related 
functions.


This essentially constexprifies the rest of .

Built and tested with C++20 (and pre-c++20) on x86_64-linux.

Ok?

Regards,

Ed Smith-Rowland





2019-08-01?? Edward Smith-Rowland <3dw...@verizon.net>

Implement C++20 p0879 - Constexpr for swap and swap related 
functions.

* include/bits/algorithmfwd.h (__cpp_lib_constexpr_swap_algorithms):
New macro. (iter_swap, make_heap, next_permutation, 
partial_sort_copy,


There should be a newline after "New macro." and before the next
parenthesized list of identifiers.

The parenthesized lists should not span multiple lines, so close and
reopen the parens, i.e.

 Implement C++20 p0879 - Constexpr for swap and swap related 
functions.
 * include/bits/algorithmfwd.h 
(__cpp_lib_constexpr_swap_algorithms):

 New macro.
 (iter_swap, make_heap, next_permutation, partial_sort_copy, 
pop_heap)

 (prev_permutation, push_heap, reverse, rotate, sort_heap, swap)
 (swap_ranges, nth_element, partial_sort, sort): Add constexpr.


@@ -193,6 +193,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION

#if __cplusplus > 201703L
#?? define __cpp_lib_constexpr_algorithms 201711L
+#?? define __cpp_lib_constexpr_swap_algorithms 201712L


Should this value be 201806L?

Indeed.


The new macro also needs to be added to .


Done.

I this OK after it passes testing?

Ed



2019-08-14  Edward Smith-Rowland  <3dw...@verizon.net>

Implement C++20 p0879 - Constexpr for swap and swap related functions.
* include/bits/algorithmfwd.h (__cpp_lib_constexpr_swap_algorithms):
New macro.
* include/std/version: Ditto.
(iter_swap, make_heap, next_permutation, partial_sort_copy, pop_heap)
(prev_permutation, push_heap, reverse, rotate, sort_heap, swap)
(swap_ranges, nth_element, partial_sort, sort): Add constexpr.
* include/bits/move.h (swap): Add constexpr.
* include/bits/stl_algo.h (__move_median_to_first, __reverse, reverse)
(__gcd, __rotate, rotate, __partition, __heap_select)
(__partial_sort_copy, partial_sort_copy, __unguarded_partition)
(__unguarded_partition_pivot, __partial_sort, __introsort_loop, __sort)
(__introselect, __chunk_insertion_sort, next_permutation)
(prev_permutation, partition, partial_sort, nth_element, sort)
(__iter_swap::iter_swap, iter_swap, swap_ranges): Add constexpr.
* include/bits/stl_algobase.h (__iter_swap::iter_swap, iter_swap)
(swap_ranges): Add constexpr.
* include/bits/stl_heap.h (__push_heap, push_heap, __adjust_heap,
__pop_heap, pop_heap, __make_heap, make_heap, __sort_heap, sort_heap):
Add constexpr.
* include/std/type_traits (swap): Add constexpr.
* testsuite/25_algorithms/headers/algorithm/synopsis.cc: Add constexpr.
* testsuite/25_algorithms/iter_swap/constexpr.cc: New test.
* testsuite/25_algorithms/make_heap/constexpr.cc: New test.
* testsuite/25_algorithms/next_permutation/constexpr.cc: New test.
* testsuite/25_algorithms/nth_element/constexpr.cc: New test.
* testsuite/25_algorithms/partial_sort/constexpr.cc: New test.
* testsuite/25_algorithms/partial_sort_copy/constexpr.cc: New test.
* testsuite/25_algorithms/partition/constexpr.cc: New test.
* testsuite/25_algorithms/pop_heap/constexpr.cc: New test.
* testsuite/25_algorithms/prev_permutation/constexpr.cc: New test.
* testsuite/25_algorithms/push_heap/constexpr.cc: New test.
* testsuite/25_algorithms/reverse/constexpr.cc: New test.
* testsuite/25_algorithms/rotate/constexpr.cc: New test.
* testsuite/25_algorithms/sort/constexpr.cc: New test.
* testsuite/25_algorithms/sort_heap/constexpr.cc: New test.
* testsuite/25_algorithms/swap/constexpr.cc: New test.
* testsuite/25_algorithms/swap_ranges/constexpr.cc: New test.

Index: include/bits/algorithmfwd.h
===
--- include/bits/algorithmfwd.h (revision 274411)
+++ include/bits/algorithmfwd.h (working copy)
@@ -193,6 +193,7 @@
 
 #if __cplusplus > 201703L
 #  define __cpp_lib_constexpr_algorithms 201711L
+#  define __cpp_lib_constexpr_swap_algorithms 201806L
 #endif
 
 #if __cplusplus >= 201103L
@@ -377,6 +378,7 @@
 #endif
 
   template
+_GLIBCXX20_CONSTEXPR
 void
 iter_swap(_FIter1, _FIter2);
 
@@ -391,10 +393,12 @@
 lower_bound(_FIter, _FIter, const _Tp&, _Compare);
 
   template
+_GLIBCXX20_CONSTEXPR
 void
 make_heap(_RAIter, _RAIter);
 
   template
+_GLIBCXX20_CONSTEXPR
 void
 make_heap(_RAIter, _RAIter, _Compare);
 
@@ -478,10 +482,12 @@
   // mismatch
 
   template
+

[SVE] PR86753

[Prathamesh Kulkarni]

Hi,
The attached patch tries to fix PR86753.

For following test:
void
f1 (int *restrict x, int *restrict y, int *restrict z)
{
  for (int i = 0; i < 100; ++i)
x[i] = y[i] ? z[i] : 10;
}

vect dump shows:
  vect_cst__42 = { 0, ... };
  vect_cst__48 = { 0, ... };

  vect__4.7_41 = .MASK_LOAD (vectp_y.5_38, 4B, loop_mask_40);
  _4 = *_3;
  _5 = z_12(D) + _2;
  mask__35.8_43 = vect__4.7_41 != vect_cst__42;
  _35 = _4 != 0;
  vec_mask_and_46 = mask__35.8_43 & loop_mask_40;
  vect_iftmp.11_47 = .MASK_LOAD (vectp_z.9_44, 4B, vec_mask_and_46);
  iftmp.0_13 = 0;
  vect_iftmp.12_50 = VEC_COND_EXPR ;

and following code-gen:
L2:
ld1wz0.s, p2/z, [x1, x3, lsl 2]
cmpne   p1.s, p3/z, z0.s, #0
cmpne   p0.s, p2/z, z0.s, #0
ld1wz0.s, p0/z, [x2, x3, lsl 2]
sel z0.s, p1, z0.s, z1.s

We could reuse vec_mask_and_46 in vec_cond_expr since the conditions
vect__4.7_41 != vect_cst__48 and vect__4.7_41 != vect_cst__42
are equivalent, and vect_iftmp.11_47 depends on vect__4.7_41 != vect_cst__48.

I suppose in general for vec_cond_expr  if T comes from masked load,
which is conditional on C, then we could reuse the mask used in load,
in vec_cond_expr ?

The patch maintains a hash_map cond_to_vec_mask
from  vec_mask (with loop predicate applied).
In prepare_load_store_mask, we record  -> vec_mask & loop_mask,
and in vectorizable_condition, we check if  exists in
cond_to_vec_mask
and if found, the corresponding vec_mask is used as 1st operand of
vec_cond_expr.

 is represented with cond_vmask_key, and the patch
adds tree_cond_ops to represent condition operator and operands coming
either from cond_expr
or a gimple comparison stmt. If the stmt is not comparison, it returns
 and inserts that into cond_to_vec_mask.

With patch, the redundant p1 is eliminated and sel uses p0 for above test.

For following test:
void
f2 (int *restrict x, int *restrict y, int *restrict z, int fallback)
{
  for (int i = 0; i < 100; ++i)
x[i] = y[i] ? z[i] : fallback;
}

input to vectorizer has operands swapped in cond_expr:
  _36 = _4 != 0;
  iftmp.0_14 = .MASK_LOAD (_5, 32B, _36);
  iftmp.0_8 = _4 == 0 ? fallback_12(D) : iftmp.0_14;

So we need to check for inverted condition in cond_to_vec_mask,
and swap the operands.
Does the patch look OK so far ?

One major issue remaining with the patch is value  numbering.
Currently, it does value numbering for entire function using sccvn
during start of vect pass, which is too expensive since we only need
block based VN. I am looking into that.

Thanks,
Prathamesh
diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
index b0cbbac0cb5..bf54f80dd8b 100644
--- a/gcc/tree-vect-loop.c
+++ b/gcc/tree-vect-loop.c
@@ -8608,6 +8608,7 @@ vect_transform_loop (loop_vec_info loop_vinfo)
 {
   basic_block bb = bbs[i];
   stmt_vec_info stmt_info;
+  loop_vinfo->cond_to_vec_mask = new cond_vmask_map_type (8);
 
   for (gphi_iterator si = gsi_start_phis (bb); !gsi_end_p (si);
 	   gsi_next ())
@@ -8717,6 +8718,9 @@ vect_transform_loop (loop_vec_info loop_vinfo)
 		}
 	}
 	}
+
+  delete loop_vinfo->cond_to_vec_mask;
+  loop_vinfo->cond_to_vec_mask = 0;
 }/* BBs in loop */
 
   /* The vectorization factor is always > 1, so if we use an IV increment of 1.
diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
index 1e2dfe5d22d..862206b3256 100644
--- a/gcc/tree-vect-stmts.c
+++ b/gcc/tree-vect-stmts.c
@@ -1989,17 +1989,31 @@ check_load_store_masking (loop_vec_info loop_vinfo, tree vectype,
 
 static tree
 prepare_load_store_mask (tree mask_type, tree loop_mask, tree vec_mask,
-			 gimple_stmt_iterator *gsi)
+			 gimple_stmt_iterator *gsi, tree mask,
+			 cond_vmask_map_type *cond_to_vec_mask)
 {
   gcc_assert (useless_type_conversion_p (mask_type, TREE_TYPE (vec_mask)));
   if (!loop_mask)
 return vec_mask;
 
   gcc_assert (TREE_TYPE (loop_mask) == mask_type);
+
+  tree *slot = 0;
+  if (cond_to_vec_mask)
+{
+  cond_vmask_key cond (mask, loop_mask);
+  slot = _to_vec_mask->get_or_insert (cond);
+  if (*slot)
+	return *slot;
+}
+
   tree and_res = make_temp_ssa_name (mask_type, NULL, "vec_mask_and");
   gimple *and_stmt = gimple_build_assign (and_res, BIT_AND_EXPR,
 	  vec_mask, loop_mask);
   gsi_insert_before (gsi, and_stmt, GSI_SAME_STMT);
+
+  if (slot)
+*slot = and_res;
   return and_res;
 }
 
@@ -3514,8 +3528,10 @@ vectorizable_call (stmt_vec_info stmt_info, gimple_stmt_iterator *gsi,
 			  gcc_assert (ncopies == 1);
 			  tree mask = vect_get_loop_mask (gsi, masks, vec_num,
 			  vectype_out, i);
+			  tree scalar_mask = gimple_call_arg (gsi_stmt (*gsi), mask_opno);
 			  vargs[mask_opno] = prepare_load_store_mask
-			(TREE_TYPE (mask), mask, vargs[mask_opno], gsi);
+			(TREE_TYPE (mask), mask, vargs[mask_opno], gsi,
+			 scalar_mask, vinfo->cond_to_vec_mask);
 			}
 
 		  gcall *call;
@@ -3564,9 +3580,11 @@ vectorizable_call (stmt_vec_info stmt_info, gimple_stmt_iterator 

Re: [PATCH 1/2] PR c++/91436 fix C++ dialect for std::make_unique fix-it hint

[Jason Merrill]

On 8/14/19 10:39 AM, David Malcolm wrote:

On Wed, 2019-08-14 at 12:02 +0100, Jonathan Wakely wrote:

On 13/08/19 16:07 -0400, Jason Merrill wrote:

On 8/13/19 9:32 AM, Jonathan Wakely wrote:

 * g++.dg/lookup/missing-std-include-6.C: Don't check
make_unique in
 test that runs for C++11.


I'm not comfortable removing this test coverage entirely.  Doesn't
it
give a useful diagnostic in C++11 mode as well?


It does:

mu.cc:3:15: error: 'make_unique' is not a member of 'std'
 3 | auto p = std::make_unique();
   |   ^~~
mu.cc:3:15: note: 'std::make_unique' is only available from C++14
onwards
mu.cc:3:27: error: expected primary-expression before 'int'
 3 | auto p = std::make_unique();
   |   ^~~

So we can add it to g++.dg/lookup/missing-std-include-8.C instead,
which runs for c++98_only and checks for the "is only available for"
cases. Here's a patch doing that.


FWIW this eliminates the testing that when we do have C++14 onwards,
that including  is suggested.

Maybe we need a C++14-onwards missing-std-include-* test, and to move
the existing test there?  (and to add the new test for before-C++-14)


We can also check for different messages in different std modes, i.e.

{ dg-message "one" "" { target c++11_down } .-1 }
{ dg-message "two" "" { target c++14 } .-2 }

Jason

Re: C++ PATCH for c++/91391 - bogus -Wcomma-subscript warning

[Jason Merrill]

On 8/14/19 9:15 AM, Marek Polacek wrote:

Ping.

On Wed, Aug 07, 2019 at 04:05:53PM -0400, Marek Polacek wrote:

When implementing -Wcomma-subscript I failed to realize that a comma in
a template-argument-list shouldn't be warned about.

But we can't simply ignore any commas inside < ... > because the following
needs to be caught:

   a[b < c, b > c];

This patch from Jakub fixes it by moving the warning to cp_parser_expression
where we can better detect top-level commas (and avoid saving tokens).

I've extended the patch to revert the cp_parser_skip_to_closing_square_bracket
changes I made in r274121 -- they are no longer needed.

Apologies for the thinko.

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


OK.

Jason

Re: [PATCH 1/2] PR c++/91436 fix C++ dialect for std::make_unique fix-it hint

[David Malcolm]

On Wed, 2019-08-14 at 12:02 +0100, Jonathan Wakely wrote:
> On 13/08/19 16:07 -0400, Jason Merrill wrote:
> > On 8/13/19 9:32 AM, Jonathan Wakely wrote:
> > > * g++.dg/lookup/missing-std-include-6.C: Don't check
> > > make_unique in
> > > test that runs for C++11.
> > 
> > I'm not comfortable removing this test coverage entirely.  Doesn't
> > it 
> > give a useful diagnostic in C++11 mode as well?
> 
> It does:
> 
> mu.cc:3:15: error: 'make_unique' is not a member of 'std'
> 3 | auto p = std::make_unique();
>   |   ^~~
> mu.cc:3:15: note: 'std::make_unique' is only available from C++14
> onwards
> mu.cc:3:27: error: expected primary-expression before 'int'
> 3 | auto p = std::make_unique();
>   |   ^~~
> 
> So we can add it to g++.dg/lookup/missing-std-include-8.C instead,
> which runs for c++98_only and checks for the "is only available for"
> cases. Here's a patch doing that.

FWIW this eliminates the testing that when we do have C++14 onwards,
that including  is suggested.

Maybe we need a C++14-onwards missing-std-include-* test, and to move
the existing test there?  (and to add the new test for before-C++-14)


> Tested x86_64-linux.
> 
> OK for trunk?
> 
> OK for gcc-9-branch and gcc-8-branch too, since PR c++/91436 affects
> those branches?
> 

Re: [PATCH 1/2] PR c++/91436 fix C++ dialect for std::make_unique fix-it hint

[Jason Merrill]

On Wed, Aug 14, 2019 at 7:02 AM Jonathan Wakely  wrote:
>
> On 13/08/19 16:07 -0400, Jason Merrill wrote:
> >On 8/13/19 9:32 AM, Jonathan Wakely wrote:
> >> * g++.dg/lookup/missing-std-include-6.C: Don't check make_unique in
> >> test that runs for C++11.
> >
> >I'm not comfortable removing this test coverage entirely.  Doesn't it
> >give a useful diagnostic in C++11 mode as well?
>
> It does:
>
> mu.cc:3:15: error: 'make_unique' is not a member of 'std'
> 3 | auto p = std::make_unique();
>   |   ^~~
> mu.cc:3:15: note: 'std::make_unique' is only available from C++14 onwards
> mu.cc:3:27: error: expected primary-expression before 'int'
> 3 | auto p = std::make_unique();
>   |   ^~~
>
> So we can add it to g++.dg/lookup/missing-std-include-8.C instead,
> which runs for c++98_only and checks for the "is only available for"
> cases. Here's a patch doing that.
>
> Tested x86_64-linux.
>
> OK for trunk?
>
> OK for gcc-9-branch and gcc-8-branch too, since PR c++/91436 affects
> those branches?

OK.

Jason

Re: types for VR_VARYING

[Aldy Hernandez]

On 8/14/19 9:50 AM, Andrew MacLeod wrote:

On 8/13/19 8:39 PM, Aldy Hernandez wrote:



Yes, it was 2X.

I noticed that Richi made some changes to the lattice handling for 
VARYING while the discussion was on-going.  I missed these, and had 
failed to adapt the patch for it.  I would appreciate a final review 
of the attached patch, especially the vr-values.c changes, which I 
have modified to play nice with current trunk.


I also noticed that Andrew's patch was setting num_vr_values to 
num_ssa_names + num_ssa_names / 10.  I think he meant num_vr_values + 
num_vr_values / 10.  Please verify the current incantation makes sense.


no, I meant num_ssa_names.  We are resizing the vector because 
num_vr_values is out of date (and smaller than num_ssa_names is now), so 
we need to resize the vector to be at least the number of ssa-names... 
and I added 10% just in case we arent done adding new ones.



if num_vr_values is 100, and we've added 200 ssa-names, num_ssa_names 
would now be 300.   if you resize based on num_vr_values, you could 
still go off the end of the vector.


OK, I've changed the resize to allocate 2X as well.  So now we'll have:

+  unsigned int old_sz = num_vr_values;
+  num_vr_values = num_ssa_names * 2;
+  vr_value = XRESIZEVEC (value_range *, vr_value, num_vr_values);
etc

And the original allocation will also be 2X.

Aldy

Re: [PATCH 5/9] Come up with an abstraction.

[Richard Biener]

On Wed, Aug 14, 2019 at 3:19 PM Martin Liška  wrote:
>
> On 8/14/19 3:04 PM, Richard Biener wrote:
> > On Mon, Aug 12, 2019 at 3:56 PM Martin Liška  wrote:
> >>
> >> On 8/12/19 2:43 PM, Richard Biener wrote:
> >>> On Mon, Aug 12, 2019 at 1:49 PM Martin Liška  wrote:
> 
>  On 8/12/19 1:40 PM, Richard Biener wrote:
> > On Mon, Aug 12, 2019 at 1:19 PM Martin Liška  wrote:
> >>
> >> On 8/8/19 5:55 PM, Michael Matz wrote:
> >>> Hi,
> >>>
> >>> On Mon, 10 Jun 2019, Martin Liska wrote:
> >>>
>  2019-07-24  Martin Liska  
> 
>   * fold-const.c (operand_equal_p): Rename to ...
>   (operand_compare::operand_equal_p): ... this.
>   (add_expr):  Rename to ...
>   (operand_compare::hash_operand): ... this.
>   (operand_compare::operand_equal_valueize): Likewise.
>   (operand_compare::hash_operand_valueize): Likewise.
>   * fold-const.h (operand_equal_p): Set default
>   value for last argument.
>   (class operand_compare): New.
> >>>
> >>> Hmpf.  A class without any data?  That doesn't sound like a good 
> >>> design.
> >>
> >> Yes, the base class (current operand_equal_p) does not have a data.
> >> But the ICF derive class has a data and e.g. 
> >> func_checker::operand_equal_valueize
> >> will use m_label_bb_map.get (t1). Which are member data of class 
> >> func_checker.
> >>
> >>> You seem to need it only to have the possibility of virtual functions,
> >>> i.e. fancy callbacks.  AFAICS you only have one derived class, i.e. a
> >>> simple distinction of two cases.  What do you think about encoding the
> >>> additional new (ICF) case in the (existing) 'flags' argument to
> >>> operand_equal_p (and in case the ICF flag is set simply call the
> >>> "callback" directly)?
> >>
> >> That's possible. I can add two more callbacks to the operand_equal_p 
> >> function
> >> (hash_operand_valueize and operand_equal_valueize).
> >>
> >> Is Richi also supporting this approach?
> >
> > I still see no value in the abstraction since you invoke none of the
> > (virtual) methods from the base class operand_equal_p.
> 
>  I call operand_equal_valueize (and hash_operand) from operand_equal_p.
>  These are then used in IPA ICF (patch 6/9).
> >>>
> >>> Ugh.  I see you call that after
> >>>
> >>>   if (TREE_CODE (arg0) != TREE_CODE (arg1))
> >>> {
> >>> ...
> >>> }
> >>>   else
> >>> return false;
> >>> }
> >>>
> >>> and also after
> >>>
> >>>   /* Check equality of integer constants before bailing out due to
> >>>  precision differences.  */
> >>>   if (TREE_CODE (arg0) == INTEGER_CST && TREE_CODE (arg1) == INTEGER_CST)
> >>>
> >>> which means for arg0 == SSA_NAME and arg1 == INTEGER_CST you return false
> >>> instead of valueizing arg0 to the possibly same or same "lose" value
> >>> and returning true.
> >>
> >> Yes. ICF does not allow to have anything where TREE_CODEs do not match.
> >>
> >>>
> >>> Also
> >>>
> >>> +  int val = operand_equal_valueize (arg0, arg1, flags);
> >>> +  if (val == 1)
> >>> +return 1;
> >>> +  if (val == 0)
> >>> +return 0;
> >>>
> >>> suggests that you pass in arbirtrary trees for "valueization" but it
> >>> isn't actually
> >>> valueization that is performed but instead it should do an alternate 
> >>> comparison
> >>> of arg0 and arg1 with valueization.  Why's this done this way instead of
> >>> sth like
> >>>
> >>>   if (TREE_CODE (arg0) == SSA_NAME)
> >>>arg0 = operand_equal_valueize (arg0, flags);
> >>>  if (TREE_CODE (arg1) == SSA_NAME)
> >>>arg1 = operand_equal_valueize (arg1, flags);
> >>
> >> Because I want to be given a pair of trees about which the function
> >> operand_equal_valueize returns match/no-match/dunno.
> >>
> >>>
> >>> and why's this done with virtual functions rather than a callback that we 
> >>> can
> >>> cheaply check for NULLness in the default implementation?
> >>
> >> I can transform it into a hook. But as mentioned I'll need two hooks.
> >>
> >>>
> >>> So - what does ICF want to make "equal" that isn't equal normally and 
> >>> how's
> >>> that "valueization"?
> >>
> >> E.g. for a FUNCTION_DECL, ICF always return true because it can only calls
> >> the operand_equal_p after callgraph is compared. Similarly for LABEL_DECLs,
> >> we have a map (m_label_bb_map). Please take a look at patch 6/9 in this
> >> series.
> >
> > Hmm, ok, so you basically replace recursive calls to operand_equal_p with

_recursive calls_

> >
> >   operand_equal_valueize (t1, t2, 0)
> >   || operand_equal_p (t1, t2, 0)
> >
> > no?
>
> This is not going to work ..

I wonder if

class base
{
  virtual operand_equal_p (tree a, tree b, int f);
};

base::operand_equal_p (tree a, tree b, int f)
{
  as-is now, recursing to virtual operand_equal_p
}

class deriv : public base
{
  vritual 

Re: types for VR_VARYING

[Andrew MacLeod]

On 8/13/19 8:39 PM, Aldy Hernandez wrote:



Yes, it was 2X.

I noticed that Richi made some changes to the lattice handling for 
VARYING while the discussion was on-going.  I missed these, and had 
failed to adapt the patch for it.  I would appreciate a final review 
of the attached patch, especially the vr-values.c changes, which I 
have modified to play nice with current trunk.


I also noticed that Andrew's patch was setting num_vr_values to 
num_ssa_names + num_ssa_names / 10.  I think he meant num_vr_values + 
num_vr_values / 10.  Please verify the current incantation makes sense.


no, I meant num_ssa_names.  We are resizing the vector because 
num_vr_values is out of date (and smaller than num_ssa_names is now), so 
we need to resize the vector to be at least the number of ssa-names... 
and I added 10% just in case we arent done adding new ones.



if num_vr_values is 100, and we've added 200 ssa-names, num_ssa_names 
would now be 300.   if you resize based on num_vr_values, you could 
still go off the end of the vector.



Andrew

[PATCH] Make GIMPLE forwprop DCE dead stmts

[Richard Biener]

The following patch makes forwprop DCE the stmts that become dead
because of propagation of copies and constants.  For this to work
we actually have to do that reliably rather than relying on
fold_stmt doing this for us.

This hits fortran/trans-intrinsic.c in a way that we do "interesting"
jump threading exposing a bogus uninit warning.  I'll open a PR
for this with an (unreduced) testcase after committing.

Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.

I've done this when seeing the number of copyprop passes we have
and knowing the expense of the SSA propagation machinery so
eventually forwprop (in a cheaper mode, not folding all stmts)
could replace copyprop.

Richard.

2019-08-14  Richard Biener  

* tree-ssa-forwprop.c (pass_forwprop::execute): Fully
propagate lattice, DCE stmts that became dead because of that.

fortran/
* trans-intrinsic.c (gfc_conv_intrinsic_findloc): Initialize
forward_branch to avoid bogus uninitialized warning.

* gcc.dg/tree-ssa/forwprop-31.c: Adjust.

Index: gcc/tree-ssa-forwprop.c
===
--- gcc/tree-ssa-forwprop.c (revision 274422)
+++ gcc/tree-ssa-forwprop.c (working copy)
@@ -2299,13 +2299,14 @@ pass_forwprop::execute (function *fun)
   int postorder_num = pre_and_rev_post_order_compute_fn (cfun, NULL,
 postorder, false);
   auto_vec to_fixup;
+  auto_vec to_remove;
   to_purge = BITMAP_ALLOC (NULL);
   for (int i = 0; i < postorder_num; ++i)
 {
   gimple_stmt_iterator gsi;
   basic_block bb = BASIC_BLOCK_FOR_FN (fun, postorder[i]);
 
-  /* Propagate into PHIs and record degenerate ones in the lattice.  */
+  /* Record degenerate PHIs in the lattice.  */
   for (gphi_iterator si = gsi_start_phis (bb); !gsi_end_p (si);
   gsi_next ())
{
@@ -2321,17 +2322,20 @@ pass_forwprop::execute (function *fun)
  FOR_EACH_PHI_ARG (use_p, phi, it, SSA_OP_USE)
{
  tree use = USE_FROM_PTR (use_p);
- tree tem = fwprop_ssa_val (use);
  if (! first)
-   first = tem;
- else if (! operand_equal_p (first, tem, 0))
-   all_same = false;
- if (tem != use
- && may_propagate_copy (use, tem))
-   propagate_value (use_p, tem);
+   first = use;
+ else if (! operand_equal_p (first, use, 0))
+   {
+ all_same = false;
+ break;
+   }
}
  if (all_same)
-   fwprop_set_lattice_val (res, first);
+   {
+ if (may_propagate_copy (res, first))
+   to_remove.safe_push (phi);
+ fwprop_set_lattice_val (res, first);
+   }
}
 
   /* Apply forward propagation to all stmts in the basic-block.
@@ -2648,148 +2652,227 @@ pass_forwprop::execute (function *fun)
 
   /* Combine stmts with the stmts defining their operands.
 Note we update GSI within the loop as necessary.  */
-  for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi);)
+  for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next ())
{
  gimple *stmt = gsi_stmt (gsi);
- gimple *orig_stmt = stmt;
- bool changed = false;
- bool was_noreturn = (is_gimple_call (stmt)
-  && gimple_call_noreturn_p (stmt));
 
  /* Mark stmt as potentially needing revisiting.  */
  gimple_set_plf (stmt, GF_PLF_1, false);
 
- if (fold_stmt (, fwprop_ssa_val))
-   {
- changed = true;
- stmt = gsi_stmt (gsi);
- if (maybe_clean_or_replace_eh_stmt (orig_stmt, stmt))
-   bitmap_set_bit (to_purge, bb->index);
- if (!was_noreturn
- && is_gimple_call (stmt) && gimple_call_noreturn_p (stmt))
-   to_fixup.safe_push (stmt);
- /* Cleanup the CFG if we simplified a condition to
-true or false.  */
- if (gcond *cond = dyn_cast  (stmt))
-   if (gimple_cond_true_p (cond)
-   || gimple_cond_false_p (cond))
- cfg_changed = true;
- update_stmt (stmt);
-   }
-
- switch (gimple_code (stmt))
-   {
-   case GIMPLE_ASSIGN:
- {
-   tree rhs1 = gimple_assign_rhs1 (stmt);
-   enum tree_code code = gimple_assign_rhs_code (stmt);
+ /* Substitute from our lattice.  We need to do so only once.  */
+ bool substituted_p = false;
+ use_operand_p usep;
+ ssa_op_iter iter;
+ FOR_EACH_SSA_USE_OPERAND (usep, stmt, iter, SSA_OP_USE)
+   {
+ tree use = USE_FROM_PTR (usep);
+ tree val = fwprop_ssa_val (use);
+ if (val && val != use && may_propagate_copy (use, 

Re: [PATCH 5/9] Come up with an abstraction.

[Martin Liška]

On 8/14/19 3:04 PM, Richard Biener wrote:
> On Mon, Aug 12, 2019 at 3:56 PM Martin Liška  wrote:
>>
>> On 8/12/19 2:43 PM, Richard Biener wrote:
>>> On Mon, Aug 12, 2019 at 1:49 PM Martin Liška  wrote:

 On 8/12/19 1:40 PM, Richard Biener wrote:
> On Mon, Aug 12, 2019 at 1:19 PM Martin Liška  wrote:
>>
>> On 8/8/19 5:55 PM, Michael Matz wrote:
>>> Hi,
>>>
>>> On Mon, 10 Jun 2019, Martin Liska wrote:
>>>
 2019-07-24  Martin Liska  

  * fold-const.c (operand_equal_p): Rename to ...
  (operand_compare::operand_equal_p): ... this.
  (add_expr):  Rename to ...
  (operand_compare::hash_operand): ... this.
  (operand_compare::operand_equal_valueize): Likewise.
  (operand_compare::hash_operand_valueize): Likewise.
  * fold-const.h (operand_equal_p): Set default
  value for last argument.
  (class operand_compare): New.
>>>
>>> Hmpf.  A class without any data?  That doesn't sound like a good design.
>>
>> Yes, the base class (current operand_equal_p) does not have a data.
>> But the ICF derive class has a data and e.g. 
>> func_checker::operand_equal_valueize
>> will use m_label_bb_map.get (t1). Which are member data of class 
>> func_checker.
>>
>>> You seem to need it only to have the possibility of virtual functions,
>>> i.e. fancy callbacks.  AFAICS you only have one derived class, i.e. a
>>> simple distinction of two cases.  What do you think about encoding the
>>> additional new (ICF) case in the (existing) 'flags' argument to
>>> operand_equal_p (and in case the ICF flag is set simply call the
>>> "callback" directly)?
>>
>> That's possible. I can add two more callbacks to the operand_equal_p 
>> function
>> (hash_operand_valueize and operand_equal_valueize).
>>
>> Is Richi also supporting this approach?
>
> I still see no value in the abstraction since you invoke none of the
> (virtual) methods from the base class operand_equal_p.

 I call operand_equal_valueize (and hash_operand) from operand_equal_p.
 These are then used in IPA ICF (patch 6/9).
>>>
>>> Ugh.  I see you call that after
>>>
>>>   if (TREE_CODE (arg0) != TREE_CODE (arg1))
>>> {
>>> ...
>>> }
>>>   else
>>> return false;
>>> }
>>>
>>> and also after
>>>
>>>   /* Check equality of integer constants before bailing out due to
>>>  precision differences.  */
>>>   if (TREE_CODE (arg0) == INTEGER_CST && TREE_CODE (arg1) == INTEGER_CST)
>>>
>>> which means for arg0 == SSA_NAME and arg1 == INTEGER_CST you return false
>>> instead of valueizing arg0 to the possibly same or same "lose" value
>>> and returning true.
>>
>> Yes. ICF does not allow to have anything where TREE_CODEs do not match.
>>
>>>
>>> Also
>>>
>>> +  int val = operand_equal_valueize (arg0, arg1, flags);
>>> +  if (val == 1)
>>> +return 1;
>>> +  if (val == 0)
>>> +return 0;
>>>
>>> suggests that you pass in arbirtrary trees for "valueization" but it
>>> isn't actually
>>> valueization that is performed but instead it should do an alternate 
>>> comparison
>>> of arg0 and arg1 with valueization.  Why's this done this way instead of
>>> sth like
>>>
>>>   if (TREE_CODE (arg0) == SSA_NAME)
>>>arg0 = operand_equal_valueize (arg0, flags);
>>>  if (TREE_CODE (arg1) == SSA_NAME)
>>>arg1 = operand_equal_valueize (arg1, flags);
>>
>> Because I want to be given a pair of trees about which the function
>> operand_equal_valueize returns match/no-match/dunno.
>>
>>>
>>> and why's this done with virtual functions rather than a callback that we 
>>> can
>>> cheaply check for NULLness in the default implementation?
>>
>> I can transform it into a hook. But as mentioned I'll need two hooks.
>>
>>>
>>> So - what does ICF want to make "equal" that isn't equal normally and how's
>>> that "valueization"?
>>
>> E.g. for a FUNCTION_DECL, ICF always return true because it can only calls
>> the operand_equal_p after callgraph is compared. Similarly for LABEL_DECLs,
>> we have a map (m_label_bb_map). Please take a look at patch 6/9 in this
>> series.
> 
> Hmm, ok, so you basically replace recursive calls to operand_equal_p with
> 
>   operand_equal_valueize (t1, t2, 0)
>   || operand_equal_p (t1, t2, 0)
> 
> no?

This is not going to work ..

>  But the same could be achieved by actually making t1 and t2 equal
> according to operand_equal_p rules via the valueization hook?  So replace
> FUNCTION_DECLs with their prevailing ones, LABEL_DECLs with theirs, etc.
> 
> As given your abstraction is quite awkward to use, say, from value-numbering
> which knows how to "valueize" a single tree but doesn't compare things.
> 
> To make it work for your case you'd valueize not only SSA names but also
> all DECL_P I guess.  After all your operand_equal_valueize only does
> something for "leafs" but is called for 

Re: [PATCH] Add generic support for "noinit" attribute

[Christophe Lyon]

On Wed, 14 Aug 2019 at 14:14, Richard Sandiford
 wrote:
>
> Sorry for the slow response, I'd missed that there was an updated patch...
>
> Christophe Lyon  writes:
> > 2019-07-04  Christophe Lyon  
> >
> >   * lib/target-supports.exp (check_effective_target_noinit): New
> >   proc.
> > * gcc.c-torture/execute/noinit-attribute.c: New test.
>
> Second line should be indented by tabs rather than spaces.
>
> > @@ -2224,6 +2234,54 @@ handle_weak_attribute (tree *node, tree name,
> >return NULL_TREE;
> >  }
> >
> > +/* Handle a "noinit" attribute; arguments as in struct
> > +   attribute_spec.handler.  Check whether the attribute is allowed
> > +   here and add the attribute to the variable decl tree or otherwise
> > +   issue a diagnostic.  This function checks NODE is of the expected
> > +   type and issues diagnostics otherwise using NAME.  If it is not of
> > +   the expected type *NO_ADD_ATTRS will be set to true.  */
> > +
> > +static tree
> > +handle_noinit_attribute (tree * node,
> > +   tree   name,
> > +   tree   args,
> > +   intflags ATTRIBUTE_UNUSED,
> > +   bool *no_add_attrs)
> > +{
> > +  const char *message = NULL;
> > +
> > +  gcc_assert (DECL_P (*node));
> > +  gcc_assert (args == NULL);
> > +
> > +  if (TREE_CODE (*node) != VAR_DECL)
> > +message = G_("%qE attribute only applies to variables");
> > +
> > +  /* Check that it's possible for the variable to have a section.  */
> > +  else if ((TREE_STATIC (*node) || DECL_EXTERNAL (*node) || in_lto_p)
> > +&& DECL_SECTION_NAME (*node))
> > +message = G_("%qE attribute cannot be applied to variables "
> > +  "with specific sections");
> > +
> > +  if (!targetm.have_switchable_bss_sections)
> > +message = G_("%qE attribute is specific to ELF targets");
>
> Maybe make this an else if too?  Or make the VAR_DECL an else if
> if you think the ELF one should win.  Either way, it seems odd to
> have the mixture between else if and not.
>
Right, I changed this into an else if.

> > +  if (message)
> > +{
> > +  warning (OPT_Wattributes, message, name);
> > +  *no_add_attrs = true;
> > +}
> > +  else
> > +  /* If this var is thought to be common, then change this.  Common
> > + variables are assigned to sections before the backend has a
> > + chance to process them.  Do this only if the attribute is
> > + valid.  */
>
> Comment should be indented two spaces more.
>
> > +if (DECL_COMMON (*node))
> > +  DECL_COMMON (*node) = 0;
> > +
> > +  return NULL_TREE;
> > +}
> > +
> > +
> >  /* Handle a "noplt" attribute; arguments as in
> > struct attribute_spec.handler.  */
> >
> > diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> > index f2619e1..f1af1dc 100644
> > --- a/gcc/doc/extend.texi
> > +++ b/gcc/doc/extend.texi
> > @@ -7129,6 +7129,14 @@ The @code{visibility} attribute is described in
> >  The @code{weak} attribute is described in
> >  @ref{Common Function Attributes}.
> >
> > +@item noinit
> > +@cindex @code{noinit} variable attribute
> > +Any data with the @code{noinit} attribute will not be initialized by
> > +the C runtime startup code, or the program loader.  Not initializing
> > +data in this way can reduce program startup times.  Specific to ELF
> > +targets, this attribute relies on the linker to place such data in the
> > +right location.
>
> Maybe:
>
>This attribute is specific to ELF targets and relies on the linker to
>place such data in the right location.
>
Thanks, I thought I had chosen a nice turn of phrase :-)


> > diff --git a/gcc/testsuite/gcc.c-torture/execute/noinit-attribute.c 
> > b/gcc/testsuite/gcc.c-torture/execute/noinit-attribute.c
> > new file mode 100644
> > index 000..ffcf8c6
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.c-torture/execute/noinit-attribute.c
> > @@ -0,0 +1,59 @@
> > +/* { dg-do run } */
> > +/* { dg-require-effective-target noinit */
> > +/* { dg-options "-O2" } */
> > +
> > +/* This test checks that noinit data is handled correctly.  */
> > +
> > +extern void _start (void) __attribute__ ((noreturn));
> > +extern void abort (void) __attribute__ ((noreturn));
> > +extern void exit (int) __attribute__ ((noreturn));
> > +
> > +int var_common;
> > +int var_zero = 0;
> > +int var_one = 1;
> > +int __attribute__((noinit)) var_noinit;
> > +int var_init = 2;
> > +
> > +int __attribute__((noinit)) func(); /* { dg-warning "attribute only 
> > applies to variables" } */
> > +int __attribute__((section ("mysection"), noinit)) var_section1; /* { 
> > dg-warning "because it conflicts with attribute" } */
> > +int __attribute__((noinit, section ("mysection"))) var_section2; /* { 
> > dg-warning "because it conflicts with attribute" } */
> > +
> > +
> > +int
> > +main (void)
> > +{
> > +  /* Make sure that the C startup code has correctly initialized the 
> > ordinary variables.  */
> > +  if (var_common != 0)
> > +abort ();
> > +
> > +  /* Initialized 

Re: C++ PATCH for c++/91391 - bogus -Wcomma-subscript warning

[Marek Polacek]

Ping.

On Wed, Aug 07, 2019 at 04:05:53PM -0400, Marek Polacek wrote:
> When implementing -Wcomma-subscript I failed to realize that a comma in
> a template-argument-list shouldn't be warned about.
> 
> But we can't simply ignore any commas inside < ... > because the following
> needs to be caught:
> 
>   a[b < c, b > c];
> 
> This patch from Jakub fixes it by moving the warning to cp_parser_expression
> where we can better detect top-level commas (and avoid saving tokens).
> 
> I've extended the patch to revert the cp_parser_skip_to_closing_square_bracket
> changes I made in r274121 -- they are no longer needed.
> 
> Apologies for the thinko.
> 
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
> 
> 2019-08-07  Jakub Jelinek  
> Marek Polacek  
> 
>   PR c++/91391 - bogus -Wcomma-subscript warning.
>   * parser.c (cp_parser_postfix_open_square_expression): Don't warn about
>   a deprecated comma here.  Pass warn_comma_subscript down to
>   cp_parser_expression.
>   (cp_parser_expression): New bool parameter.  Warn about uses of a comma
>   operator within a subscripting expression.
>   (cp_parser_skip_to_closing_square_bracket): Revert to pre-r274121 state.
>   (cp_parser_skip_to_closing_square_bracket_1): Remove.
> 
>   * g++.dg/cpp2a/comma5.C: New test.
> 
> diff --git gcc/cp/parser.c gcc/cp/parser.c
> index 14b724095c4..eccc3749fd0 100644
> --- gcc/cp/parser.c
> +++ gcc/cp/parser.c
> @@ -2102,7 +2102,7 @@ static cp_expr cp_parser_assignment_expression
>  static enum tree_code cp_parser_assignment_operator_opt
>(cp_parser *);
>  static cp_expr cp_parser_expression
> -  (cp_parser *, cp_id_kind * = NULL, bool = false, bool = false);
> +  (cp_parser *, cp_id_kind * = NULL, bool = false, bool = false, bool = 
> false);
>  static cp_expr cp_parser_constant_expression
>(cp_parser *, bool = false, bool * = NULL, bool = false);
>  static cp_expr cp_parser_builtin_offsetof
> @@ -2669,8 +2669,6 @@ static bool cp_parser_init_statement_p
>(cp_parser *);
>  static bool cp_parser_skip_to_closing_square_bracket
>(cp_parser *);
> -static int cp_parser_skip_to_closing_square_bracket_1
> -  (cp_parser *, enum cpp_ttype);
>  
>  /* Concept-related syntactic transformations */
>  
> @@ -7524,33 +7522,9 @@ cp_parser_postfix_open_square_expression (cp_parser 
> *parser,
> index = cp_parser_braced_list (parser, _nonconst_p);
>   }
>else
> - {
> -   /* [depr.comma.subscript]: A comma expression appearing as
> -  the expr-or-braced-init-list of a subscripting expression
> -  is deprecated.  A parenthesized comma expression is not
> -  deprecated.  */
> -   if (warn_comma_subscript)
> - {
> -   /* Save tokens so that we can put them back.  */
> -   cp_lexer_save_tokens (parser->lexer);
> -
> -   /* Look for ',' that is not nested in () or {}.  */
> -   if (cp_parser_skip_to_closing_square_bracket_1 (parser,
> -   CPP_COMMA) == -1)
> - {
> -   auto_diagnostic_group d;
> -   warning_at (cp_lexer_peek_token (parser->lexer)->location,
> -   OPT_Wcomma_subscript,
> -   "top-level comma expression in array subscript "
> -   "is deprecated");
> - }
> -
> -   /* Roll back the tokens we skipped.  */
> -   cp_lexer_rollback_tokens (parser->lexer);
> - }
> -
> -   index = cp_parser_expression (parser);
> - }
> + index = cp_parser_expression (parser, NULL, /*cast_p=*/false,
> +   /*decltype_p=*/false,
> +   /*warn_comma_p=*/warn_comma_subscript);
>  }
>  
>parser->greater_than_is_operator_p = saved_greater_than_is_operator_p;
> @@ -9932,12 +9906,13 @@ cp_parser_assignment_operator_opt (cp_parser* parser)
> CAST_P is true if this expression is the target of a cast.
> DECLTYPE_P is true if this expression is the immediate operand of 
> decltype,
>   except possibly parenthesized or on the RHS of a comma (N3276).
> +   WARN_COMMA_P is true if a comma should be diagnosed.
>  
> Returns a representation of the expression.  */
>  
>  static cp_expr
>  cp_parser_expression (cp_parser* parser, cp_id_kind * pidk,
> -   bool cast_p, bool decltype_p)
> +   bool cast_p, bool decltype_p, bool warn_comma_p)
>  {
>cp_expr expression = NULL_TREE;
>location_t loc = UNKNOWN_LOCATION;
> @@ -9984,6 +9959,17 @@ cp_parser_expression (cp_parser* parser, cp_id_kind * 
> pidk,
>   break;
>/* Consume the `,'.  */
>loc = cp_lexer_peek_token (parser->lexer)->location;
> +  if (warn_comma_p)
> + {
> +   /* [depr.comma.subscript]: A comma expression appearing as
> +  the expr-or-braced-init-list of a subscripting expression
> +  

Re: [PATCH 5/9] Come up with an abstraction.

[Richard Biener]

On Mon, Aug 12, 2019 at 3:56 PM Martin Liška  wrote:
>
> On 8/12/19 2:43 PM, Richard Biener wrote:
> > On Mon, Aug 12, 2019 at 1:49 PM Martin Liška  wrote:
> >>
> >> On 8/12/19 1:40 PM, Richard Biener wrote:
> >>> On Mon, Aug 12, 2019 at 1:19 PM Martin Liška  wrote:
> 
>  On 8/8/19 5:55 PM, Michael Matz wrote:
> > Hi,
> >
> > On Mon, 10 Jun 2019, Martin Liska wrote:
> >
> >> 2019-07-24  Martin Liska  
> >>
> >>  * fold-const.c (operand_equal_p): Rename to ...
> >>  (operand_compare::operand_equal_p): ... this.
> >>  (add_expr):  Rename to ...
> >>  (operand_compare::hash_operand): ... this.
> >>  (operand_compare::operand_equal_valueize): Likewise.
> >>  (operand_compare::hash_operand_valueize): Likewise.
> >>  * fold-const.h (operand_equal_p): Set default
> >>  value for last argument.
> >>  (class operand_compare): New.
> >
> > Hmpf.  A class without any data?  That doesn't sound like a good design.
> 
>  Yes, the base class (current operand_equal_p) does not have a data.
>  But the ICF derive class has a data and e.g. 
>  func_checker::operand_equal_valueize
>  will use m_label_bb_map.get (t1). Which are member data of class 
>  func_checker.
> 
> > You seem to need it only to have the possibility of virtual functions,
> > i.e. fancy callbacks.  AFAICS you only have one derived class, i.e. a
> > simple distinction of two cases.  What do you think about encoding the
> > additional new (ICF) case in the (existing) 'flags' argument to
> > operand_equal_p (and in case the ICF flag is set simply call the
> > "callback" directly)?
> 
>  That's possible. I can add two more callbacks to the operand_equal_p 
>  function
>  (hash_operand_valueize and operand_equal_valueize).
> 
>  Is Richi also supporting this approach?
> >>>
> >>> I still see no value in the abstraction since you invoke none of the
> >>> (virtual) methods from the base class operand_equal_p.
> >>
> >> I call operand_equal_valueize (and hash_operand) from operand_equal_p.
> >> These are then used in IPA ICF (patch 6/9).
> >
> > Ugh.  I see you call that after
> >
> >   if (TREE_CODE (arg0) != TREE_CODE (arg1))
> > {
> > ...
> > }
> >   else
> > return false;
> > }
> >
> > and also after
> >
> >   /* Check equality of integer constants before bailing out due to
> >  precision differences.  */
> >   if (TREE_CODE (arg0) == INTEGER_CST && TREE_CODE (arg1) == INTEGER_CST)
> >
> > which means for arg0 == SSA_NAME and arg1 == INTEGER_CST you return false
> > instead of valueizing arg0 to the possibly same or same "lose" value
> > and returning true.
>
> Yes. ICF does not allow to have anything where TREE_CODEs do not match.
>
> >
> > Also
> >
> > +  int val = operand_equal_valueize (arg0, arg1, flags);
> > +  if (val == 1)
> > +return 1;
> > +  if (val == 0)
> > +return 0;
> >
> > suggests that you pass in arbirtrary trees for "valueization" but it
> > isn't actually
> > valueization that is performed but instead it should do an alternate 
> > comparison
> > of arg0 and arg1 with valueization.  Why's this done this way instead of
> > sth like
> >
> >   if (TREE_CODE (arg0) == SSA_NAME)
> >arg0 = operand_equal_valueize (arg0, flags);
> >  if (TREE_CODE (arg1) == SSA_NAME)
> >arg1 = operand_equal_valueize (arg1, flags);
>
> Because I want to be given a pair of trees about which the function
> operand_equal_valueize returns match/no-match/dunno.
>
> >
> > and why's this done with virtual functions rather than a callback that we 
> > can
> > cheaply check for NULLness in the default implementation?
>
> I can transform it into a hook. But as mentioned I'll need two hooks.
>
> >
> > So - what does ICF want to make "equal" that isn't equal normally and how's
> > that "valueization"?
>
> E.g. for a FUNCTION_DECL, ICF always return true because it can only calls
> the operand_equal_p after callgraph is compared. Similarly for LABEL_DECLs,
> we have a map (m_label_bb_map). Please take a look at patch 6/9 in this
> series.

Hmm, ok, so you basically replace recursive calls to operand_equal_p with

  operand_equal_valueize (t1, t2, 0)
  || operand_equal_p (t1, t2, 0)

no?  But the same could be achieved by actually making t1 and t2 equal
according to operand_equal_p rules via the valueization hook?  So replace
FUNCTION_DECLs with their prevailing ones, LABEL_DECLs with theirs, etc.

As given your abstraction is quite awkward to use, say, from value-numbering
which knows how to "valueize" a single tree but doesn't compare things.

To make it work for your case you'd valueize not only SSA names but also
all DECL_P I guess.  After all your operand_equal_valueize only does
something for "leafs" but is called for all intermediate expressions as well.

Richard.

> Thanks,
> Martin
>
> >
> > Thanks,
> > Richard.
> >
> >> Martin
> >>
> >>>

Add IFN_COND functions for shifting

[Richard Sandiford]

This patch adds support for IFN_COND shifts left and shifts right.
This is mostly mechanical, but since we try to handle conditional
operations in the same way as unconditional operations in match.pd,
we need to support IFN_COND shifts by scalars as well as vectors.
E.g.:

   IFN_COND_SHL (cond, a, { 1, 1, ... }, fallback)

and:

   IFN_COND_SHL (cond, a, 1, fallback)

are the same operation, with:

   (for shiftrotate (lrotate rrotate lshift rshift)
...
/* Prefer vector1 << scalar to vector1 << vector2
   if vector2 is uniform.  */
(for vec (VECTOR_CST CONSTRUCTOR)
 (simplify
  (shiftrotate @0 vec@1)
  (with { tree tem = uniform_vector_p (@1); }
   (if (tem)
(shiftrotate @0 { tem; }))

preferring the latter.  The patch copes with this by extending
create_convert_operand_from to handle scalar-to-vector conversions.

Tested on aarch64-linux-gnu (with and without SVE), aarch64_be-elf
and x86_64-linux-gnu.  OK for the generic bits?

Richard


2019-08-14  Richard Sandiford  
Prathamesh Kulkarni  

gcc/
* internal-fn.def (IFN_COND_SHL, IFN_COND_SHR): New internal functions.
* internal-fn.c (FOR_EACH_CODE_MAPPING): Handle shifts.
* match.pd (UNCOND_BINARY, COND_BINARY): Likewise.
* optabs.def (cond_ashl_optab, cond_ashr_optab, cond_lshr_optab): New
optabs.
* optabs.h (create_convert_operand_from): Expand comment.
* optabs.c (maybe_legitimize_operand): Allow implicit broadcasts
when mapping scalar rtxes to vector operands.
* config/aarch64/iterators.md (SVE_INT_BINARY): Add ashift,
ashiftrt and lshiftrt.
(sve_int_op, sve_int_op_rev, sve_pred_int_rhs2_operand): Handle them.
* config/aarch64/aarch64-sve.md (*cond__2_const)
(*cond__any_const): New patterns.

gcc/testsuite/
* gcc.target/aarch64/sve/cond_shift_1.c: New test.
* gcc.target/aarch64/sve/cond_shift_1_run.c: Likewise.
* gcc.target/aarch64/sve/cond_shift_2.c: Likewise.
* gcc.target/aarch64/sve/cond_shift_2_run.c: Likewise.
* gcc.target/aarch64/sve/cond_shift_3.c: Likewise.
* gcc.target/aarch64/sve/cond_shift_3_run.c: Likewise.
* gcc.target/aarch64/sve/cond_shift_4.c: Likewise.
* gcc.target/aarch64/sve/cond_shift_4_run.c: Likewise.
* gcc.target/aarch64/sve/cond_shift_5.c: Likewise.
* gcc.target/aarch64/sve/cond_shift_5_run.c: Likewise.
* gcc.target/aarch64/sve/cond_shift_6.c: Likewise.
* gcc.target/aarch64/sve/cond_shift_6_run.c: Likewise.
* gcc.target/aarch64/sve/cond_shift_7.c: Likewise.
* gcc.target/aarch64/sve/cond_shift_7_run.c: Likewise.
* gcc.target/aarch64/sve/cond_shift_8.c: Likewise.
* gcc.target/aarch64/sve/cond_shift_8_run.c: Likewise.
* gcc.target/aarch64/sve/cond_shift_9.c: Likewise.
* gcc.target/aarch64/sve/cond_shift_9_run.c: Likewise.

Index: gcc/internal-fn.def
===
--- gcc/internal-fn.def 2019-06-18 09:35:54.921869466 +0100
+++ gcc/internal-fn.def 2019-08-14 13:22:08.625843346 +0100
@@ -167,6 +167,10 @@ DEF_INTERNAL_OPTAB_FN (COND_IOR, ECF_CON
   cond_ior, cond_binary)
 DEF_INTERNAL_OPTAB_FN (COND_XOR, ECF_CONST | ECF_NOTHROW,
   cond_xor, cond_binary)
+DEF_INTERNAL_OPTAB_FN (COND_SHL, ECF_CONST | ECF_NOTHROW,
+  cond_ashl, cond_binary)
+DEF_INTERNAL_SIGNED_OPTAB_FN (COND_SHR, ECF_CONST | ECF_NOTHROW, first,
+ cond_ashr, cond_lshr, cond_binary)
 
 DEF_INTERNAL_OPTAB_FN (COND_FMA, ECF_CONST, cond_fma, cond_ternary)
 DEF_INTERNAL_OPTAB_FN (COND_FMS, ECF_CONST, cond_fms, cond_ternary)
Index: gcc/internal-fn.c
===
--- gcc/internal-fn.c   2019-07-10 19:41:21.623936245 +0100
+++ gcc/internal-fn.c   2019-08-14 13:22:08.625843346 +0100
@@ -3286,7 +3286,9 @@ #define FOR_EACH_CODE_MAPPING(T) \
   T (MAX_EXPR, IFN_COND_MAX) \
   T (BIT_AND_EXPR, IFN_COND_AND) \
   T (BIT_IOR_EXPR, IFN_COND_IOR) \
-  T (BIT_XOR_EXPR, IFN_COND_XOR)
+  T (BIT_XOR_EXPR, IFN_COND_XOR) \
+  T (LSHIFT_EXPR, IFN_COND_SHL) \
+  T (RSHIFT_EXPR, IFN_COND_SHR)
 
 /* Return a function that only performs CODE when a certain condition is met
and that uses a given fallback value otherwise.  For example, if CODE is
Index: gcc/match.pd
===
--- gcc/match.pd2019-07-29 09:39:48.690173827 +0100
+++ gcc/match.pd2019-08-14 13:22:08.625843346 +0100
@@ -83,12 +83,14 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
   plus minus
   mult trunc_div trunc_mod rdiv
   min max
-  bit_and bit_ior bit_xor)
+  bit_and bit_ior bit_xor
+  lshift rshift)
 (define_operator_list COND_BINARY
   IFN_COND_ADD IFN_COND_SUB
   IFN_COND_MUL IFN_COND_DIV IFN_COND_MOD IFN_COND_RDIV
   IFN_COND_MIN IFN_COND_MAX
-  IFN_COND_AND 

Re: [PATCH] Add generic support for "noinit" attribute

[Richard Sandiford]

Sorry for the slow response, I'd missed that there was an updated patch...

Christophe Lyon  writes:
> 2019-07-04  Christophe Lyon  
> 
>   * lib/target-supports.exp (check_effective_target_noinit): New
>   proc.
> * gcc.c-torture/execute/noinit-attribute.c: New test.

Second line should be indented by tabs rather than spaces.

> @@ -2224,6 +2234,54 @@ handle_weak_attribute (tree *node, tree name,
>return NULL_TREE;
>  }
>  
> +/* Handle a "noinit" attribute; arguments as in struct
> +   attribute_spec.handler.  Check whether the attribute is allowed
> +   here and add the attribute to the variable decl tree or otherwise
> +   issue a diagnostic.  This function checks NODE is of the expected
> +   type and issues diagnostics otherwise using NAME.  If it is not of
> +   the expected type *NO_ADD_ATTRS will be set to true.  */
> +
> +static tree
> +handle_noinit_attribute (tree * node,
> +   tree   name,
> +   tree   args,
> +   intflags ATTRIBUTE_UNUSED,
> +   bool *no_add_attrs)
> +{
> +  const char *message = NULL;
> +
> +  gcc_assert (DECL_P (*node));
> +  gcc_assert (args == NULL);
> +
> +  if (TREE_CODE (*node) != VAR_DECL)
> +message = G_("%qE attribute only applies to variables");
> +
> +  /* Check that it's possible for the variable to have a section.  */
> +  else if ((TREE_STATIC (*node) || DECL_EXTERNAL (*node) || in_lto_p)
> +&& DECL_SECTION_NAME (*node))
> +message = G_("%qE attribute cannot be applied to variables "
> +  "with specific sections");
> +
> +  if (!targetm.have_switchable_bss_sections)
> +message = G_("%qE attribute is specific to ELF targets");

Maybe make this an else if too?  Or make the VAR_DECL an else if
if you think the ELF one should win.  Either way, it seems odd to
have the mixture between else if and not.

> +  if (message)
> +{
> +  warning (OPT_Wattributes, message, name);
> +  *no_add_attrs = true;
> +}
> +  else
> +  /* If this var is thought to be common, then change this.  Common
> + variables are assigned to sections before the backend has a
> + chance to process them.  Do this only if the attribute is
> + valid.  */

Comment should be indented two spaces more.

> +if (DECL_COMMON (*node))
> +  DECL_COMMON (*node) = 0;
> +
> +  return NULL_TREE;
> +}
> +
> +
>  /* Handle a "noplt" attribute; arguments as in
> struct attribute_spec.handler.  */
>  
> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> index f2619e1..f1af1dc 100644
> --- a/gcc/doc/extend.texi
> +++ b/gcc/doc/extend.texi
> @@ -7129,6 +7129,14 @@ The @code{visibility} attribute is described in
>  The @code{weak} attribute is described in
>  @ref{Common Function Attributes}.
>  
> +@item noinit
> +@cindex @code{noinit} variable attribute
> +Any data with the @code{noinit} attribute will not be initialized by
> +the C runtime startup code, or the program loader.  Not initializing
> +data in this way can reduce program startup times.  Specific to ELF
> +targets, this attribute relies on the linker to place such data in the
> +right location.

Maybe:

   This attribute is specific to ELF targets and relies on the linker to
   place such data in the right location.

> diff --git a/gcc/testsuite/gcc.c-torture/execute/noinit-attribute.c 
> b/gcc/testsuite/gcc.c-torture/execute/noinit-attribute.c
> new file mode 100644
> index 000..ffcf8c6
> --- /dev/null
> +++ b/gcc/testsuite/gcc.c-torture/execute/noinit-attribute.c
> @@ -0,0 +1,59 @@
> +/* { dg-do run } */
> +/* { dg-require-effective-target noinit */
> +/* { dg-options "-O2" } */
> +
> +/* This test checks that noinit data is handled correctly.  */
> +
> +extern void _start (void) __attribute__ ((noreturn));
> +extern void abort (void) __attribute__ ((noreturn));
> +extern void exit (int) __attribute__ ((noreturn));
> +
> +int var_common;
> +int var_zero = 0;
> +int var_one = 1;
> +int __attribute__((noinit)) var_noinit;
> +int var_init = 2;
> +
> +int __attribute__((noinit)) func(); /* { dg-warning "attribute only applies 
> to variables" } */
> +int __attribute__((section ("mysection"), noinit)) var_section1; /* { 
> dg-warning "because it conflicts with attribute" } */
> +int __attribute__((noinit, section ("mysection"))) var_section2; /* { 
> dg-warning "because it conflicts with attribute" } */
> +
> +
> +int
> +main (void)
> +{
> +  /* Make sure that the C startup code has correctly initialized the 
> ordinary variables.  */
> +  if (var_common != 0)
> +abort ();
> +
> +  /* Initialized variables are not re-initialized during startup, so
> + check their original values only during the first run of this
> + test.  */
> +  if (var_init == 2)
> +if (var_zero != 0 || var_one != 1)
> +  abort ();
> +
> +  switch (var_init)
> +{
> +case 2:
> +  /* First time through - change all the values.  */
> +  var_common = var_zero = var_one = var_noinit = var_init = 

Re: [PATCHv4] Fix not 8-byte aligned ldrd/strd on ARMv5 (PR 89544)

[Richard Biener]

On Thu, 8 Aug 2019, Bernd Edlinger wrote:

> On 8/2/19 9:01 PM, Bernd Edlinger wrote:
> > On 8/2/19 3:11 PM, Richard Biener wrote:
> >> On Tue, 30 Jul 2019, Bernd Edlinger wrote:
> >>
> >>>
> >>> I have no test coverage for the movmisalign optab though, so I
> >>> rely on your code review for that part.
> >>
> >> It looks OK.  I tried to make it trigger on the following on
> >> i?86 with -msse2:
> >>
> >> typedef int v4si __attribute__((vector_size (16)));
> >>
> >> struct S { v4si v; } __attribute__((packed));
> >>
> >> v4si foo (struct S s)
> >> {
> >>   return s.v;
> >> }
> >>
> > 
> > Hmm, the entry_parm need to be a MEM_P and an unaligned one.
> > So the test case could be made to trigger it this way:
> > 
> > typedef int v4si __attribute__((vector_size (16)));
> > 
> > struct S { v4si v; } __attribute__((packed));
> > 
> > int t;
> > v4si foo (struct S a, struct S b, struct S c, struct S d,
> >   struct S e, struct S f, struct S g, struct S h,
> >   int i, int j, int k, int l, int m, int n,
> >   int o, struct S s)
> > {
> >   t = o;
> >   return s.v;
> > }
> > 
> 
> Ah, I realized that there are already a couple of very similar
> test cases: gcc.target/i386/pr35767-1.c, gcc.target/i386/pr35767-1d.c,
> gcc.target/i386/pr35767-1i.c and gcc.target/i386/pr39445.c,
> which also manage to execute the movmisalign code with the latest patch
> version.  So I thought that it is not necessary to add another one.
> 
> > However the code path is still not reached, since 
> > targetm.slow_ualigned_access
> > is always FALSE, which is probably a flaw in my patch.
> > 
> > So I think,
> > 
> > +  else if (MEM_P (data->entry_parm)
> > +  && GET_MODE_ALIGNMENT (promoted_nominal_mode)
> > + > MEM_ALIGN (data->entry_parm)
> > +  && targetm.slow_unaligned_access (promoted_nominal_mode,
> > +MEM_ALIGN (data->entry_parm)))
> > 
> > should probably better be
> > 
> > +  else if (MEM_P (data->entry_parm)
> > +  && GET_MODE_ALIGNMENT (promoted_nominal_mode)
> > + > MEM_ALIGN (data->entry_parm)
> > +&& (((icode = optab_handler (movmisalign_optab, 
> > promoted_nominal_mode))
> > + != CODE_FOR_nothing)
> > +|| targetm.slow_unaligned_access (promoted_nominal_mode,
> > +  MEM_ALIGN 
> > (data->entry_parm
> > 
> > Right?
> > 
> > Then the modified test case would use the movmisalign optab.
> > However nothing changes in the end, since the i386 back-end is used to work
> > around the middle end not using movmisalign optab when it should do so.
> > 
> 
> I prefer the second form of the check, as it offers more test coverage,
> and is probably more correct than the former.
> 
> Note there are more variations of this misalign check in expr.c,
> some are somehow odd, like expansion of MEM_REF and VIEW_CONVERT_EXPR:
> 
> && mode != BLKmode
> && align < GET_MODE_ALIGNMENT (mode))
>   {
> if ((icode = optab_handler (movmisalign_optab, mode))
> != CODE_FOR_nothing)
>   [...]
> else if (targetm.slow_unaligned_access (mode, align))
>   temp = extract_bit_field (temp, GET_MODE_BITSIZE (mode),
> 0, TYPE_UNSIGNED (TREE_TYPE (exp)),
> (modifier == EXPAND_STACK_PARM
>  ? NULL_RTX : target),
> mode, mode, false, alt_rtl);
> 
> I wonder if they are correct this way, why shouldn't we use the movmisalign
> optab if it exists, regardless of TARGET_SLOW_UNALIGNED_ACCESSS ?

Doesn't the code do exactly this?  Prefer movmisalign over 
extrct_bit_field?

> 
> > I wonder if I should try to add a gcc_checking_assert to the mov 
> > expand
> > patterns that the memory is properly aligned ?
> >
> 
> Wow, that was a really exciting bug-hunt with those assertions around...

:)

> >> @@ -3292,6 +3306,23 @@ assign_parm_setup_reg (struct assign_parm_data_all
> >>
> >>did_conversion = true;
> >>  }
> >> +  else if (MEM_P (data->entry_parm)
> >> +  && GET_MODE_ALIGNMENT (promoted_nominal_mode)
> >> + > MEM_ALIGN (data->entry_parm)
> >>
> >> we arrive here by-passing
> >>
> >>   else if (need_conversion)
> >> {
> >>   /* We did not have an insn to convert directly, or the sequence
> >>  generated appeared unsafe.  We must first copy the parm to a
> >>  pseudo reg, and save the conversion until after all
> >>  parameters have been moved.  */
> >>
> >>   int save_tree_used;
> >>   rtx tempreg = gen_reg_rtx (GET_MODE (data->entry_parm));
> >>
> >>   emit_move_insn (tempreg, validated_mem);
> >>
> >> but this move instruction is invalid in the same way as the case
> >> you fix, no?  So wouldn't it be better to do
> >>
> > 
> > We could do that, but I 

[PATCH 2/2] Clean next_nested properly.

[Martin Liska]

gcc/ChangeLog:

2019-08-14  Martin Liska  

PR ipa/91438
* cgraph.c (cgraph_node::remove): When setting
n->origin = NULL for all nested functions, reset
also next_nested.
---
 gcc/cgraph.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/gcc/cgraph.c b/gcc/cgraph.c
index eb38b905879..ea8ab38d806 100644
--- a/gcc/cgraph.c
+++ b/gcc/cgraph.c
@@ -1767,8 +1767,6 @@ cgraph_node::release_body (bool keep_arguments)
 void
 cgraph_node::remove (void)
 {
-  cgraph_node *n;
-
   if (symtab->ipa_clones_dump_file && symtab->cloned_nodes.contains (this))
 fprintf (symtab->ipa_clones_dump_file,
 	 "Callgraph removal;%s;%d;%s;%d;%d\n", asm_name (), order,
@@ -1785,8 +1783,13 @@ cgraph_node::remove (void)
  */
   force_output = false;
   forced_by_abi = false;
-  for (n = nested; n; n = n->next_nested)
+  cgraph_node *next = nested;
+  for (cgraph_node *n = nested; n; n = next)
+  {
+next = n->next_nested;
 n->origin = NULL;
+n->next_nested = NULL;
+  }
   nested = NULL;
   if (origin)
 {
@@ -1840,7 +1843,7 @@ cgraph_node::remove (void)
  */
   if (symtab->state != LTO_STREAMING)
 {
-  n = cgraph_node::get (decl);
+  cgraph_node *n = cgraph_node::get (decl);
   if (!n
 	  || (!n->clones && !n->clone_of && !n->global.inlined_to
 	  && ((symtab->global_info_ready || in_lto_p)

[PATCH 1/2] Add ::verify for cgraph_node::origin/nested/next_nested.

[Martin Liska]

gcc/ChangeLog:

2019-08-14  Martin Liska  

* cgraph.c (cgraph_node::verify_node): Verify origin, nested
and next_nested.
---
 gcc/cgraph.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/gcc/cgraph.c b/gcc/cgraph.c
index ed46d81a513..eb38b905879 100644
--- a/gcc/cgraph.c
+++ b/gcc/cgraph.c
@@ -3464,6 +3464,30 @@ cgraph_node::verify_node (void)
 	  e->aux = 0;
 	}
 }
+
+  if (nested != NULL)
+{
+  for (cgraph_node *n = nested; n != NULL; n = n->next_nested)
+	{
+	  if (n->origin == NULL)
+	{
+	  error ("missing origin for a node in a nested list");
+	  error_found = true;
+	}
+	  else if (n->origin != this)
+	{
+	  error ("origin points to a different parent");
+	  error_found = true;
+	  break;
+	}
+	}
+}
+  if (next_nested != NULL && origin == NULL)
+{
+  error ("missing origin for a node in a nested list");
+  error_found = true;
+}
+
   if (error_found)
 {
   dump (stderr);

[PATCH 0/2] Fix dangling pointer in next_nested.

[Martin Liska]

Hi.

First patch is about addition of a nested/origin/next_nested verification.
The verification can find the issue in Ada run-time library on x86_64
without bootstrap.

The second patch is fix where we need to clean up the field.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin

Martin Liska (2):
  Add ::verify for cgraph_node::origin/nested/next_nested.
  Clean next_nested properly.

 gcc/cgraph.c | 35 +++
 1 file changed, 31 insertions(+), 4 deletions(-)

-- 
2.22.0

Re: [PATCH] PR libstdc++/90361 add missing macro definition

[Jonathan Wakely]

On 12/08/19 17:41 +0100, Jonathan Wakely wrote:

The src/c++17/string-inst.cc file needs to override the default string
ABI so that it still contains the expected symbols even when the library
is configured with --with-default-libstdcxx-abi=gcc4-compatible.

PR libstdc++/90361
* src/c++17/string-inst.cc: Use _GLIBCXX_USE_CXX11_ABI=1 by default.

Tested x86_64-linux, committed to trunk.


This documents the bug in the gcc-9 release notes.

Committed to CVS.

Index: htdocs/gcc-9/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-9/changes.html,v
retrieving revision 1.74
diff -u -r1.74 changes.html
--- htdocs/gcc-9/changes.html	12 Aug 2019 07:31:04 -	1.74
+++ htdocs/gcc-9/changes.html	14 Aug 2019 11:17:34 -
@@ -70,8 +70,18 @@
 definition of std::rotate is not used.
   
   
-  The automatic template instantiation at link time (https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/C_002b_002b-Dialect-Options.html#index-frepo;>-frepo) has been deprecated and
-will be removed in a future release.
+The automatic template instantiation at link time
+(https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/C_002b_002b-Dialect-Options.html#index-frepo;>-frepo)
+has been deprecated and will be removed in a future release.
+  
+  
+The --with-default-libstdcxx-abi=gcc4-compatible configure
+option is broken in the 9.1 and 9.2 releases, producing a shared library
+with missing symbols
+(see https://gcc.gnu.org/PR90361;>Bug 90361).
+As a workaround, configure without that option and build GCC as normal,
+then edit the installed bits/c++config.h headers
+to define the _GLIBCXX_USE_CXX11_ABI macro to 0.
   
 
 

Re: [PATCHv3] Fix not 8-byte aligned ldrd/strd on ARMv5 (PR 89544)

[Richard Biener]

On Fri, 2 Aug 2019, Bernd Edlinger wrote:

> On 8/2/19 3:11 PM, Richard Biener wrote:
> > On Tue, 30 Jul 2019, Bernd Edlinger wrote:
> > 
> >>
> >> I have no test coverage for the movmisalign optab though, so I
> >> rely on your code review for that part.
> > 
> > It looks OK.  I tried to make it trigger on the following on
> > i?86 with -msse2:
> > 
> > typedef int v4si __attribute__((vector_size (16)));
> > 
> > struct S { v4si v; } __attribute__((packed));
> > 
> > v4si foo (struct S s)
> > {
> >   return s.v;
> > }
> > 
> 
> Hmm, the entry_parm need to be a MEM_P and an unaligned one.
> So the test case could be made to trigger it this way:
> 
> typedef int v4si __attribute__((vector_size (16)));
> 
> struct S { v4si v; } __attribute__((packed));
> 
> int t;
> v4si foo (struct S a, struct S b, struct S c, struct S d,
>   struct S e, struct S f, struct S g, struct S h,
>   int i, int j, int k, int l, int m, int n,
>   int o, struct S s)
> {
>   t = o;
>   return s.v;
> }
> 
> However the code path is still not reached, since targetm.slow_ualigned_access
> is always FALSE, which is probably a flaw in my patch.
> 
> So I think,
> 
> +  else if (MEM_P (data->entry_parm)
> +  && GET_MODE_ALIGNMENT (promoted_nominal_mode)
> + > MEM_ALIGN (data->entry_parm)
> +  && targetm.slow_unaligned_access (promoted_nominal_mode,
> +MEM_ALIGN (data->entry_parm)))
> 
> should probably better be
> 
> +  else if (MEM_P (data->entry_parm)
> +  && GET_MODE_ALIGNMENT (promoted_nominal_mode)
> + > MEM_ALIGN (data->entry_parm)
> +&& (((icode = optab_handler (movmisalign_optab, 
> promoted_nominal_mode))
> + != CODE_FOR_nothing)
> +|| targetm.slow_unaligned_access (promoted_nominal_mode,
> +  MEM_ALIGN (data->entry_parm
> 
> Right?

Ah, yes.  So it's really the presence of a movmisalign optab makes it
a must for unaligned moves and if it is not present then
targetm.slow_unaligned_access tells whether we need to use the bitfield
extraction/insertion code.

> Then the modified test case would use the movmisalign optab.
> However nothing changes in the end, since the i386 back-end is used to work
> around the middle end not using movmisalign optab when it should do so.

Yeah, in the past it would have failed though.  I wonder if movmisalign
is still needed for x86...

> I wonder if I should try to add a gcc_checking_assert to the mov expand
> patterns that the memory is properly aligned ?

I suppose gen* could add asserts that there is no movmisalign_optab
that would match when expanding a mov.  Eventually it's enough
to guard the mov_optab use in emit_move_insn_1 that way?  Or even
try movmisalign there...

> 
> > but nowadays x86 seems to be happy with regular moves operating on
> > unaligned memory, using unaligned moves where necessary.
> > 
> > (insn 5 2 8 2 (set (reg:V4SI 82 [ _2 ])
> > (mem/c:V4SI (reg/f:SI 16 argp) [2 s.v+0 S16 A32])) "t.c":7:11 1229 
> > {movv4si_internal}
> >  (nil))
> > 
> > and with GCC 4.8 we ended up with the following expansion which is
> > also correct.
> > 
> > (insn 2 4 3 2 (set (subreg:V16QI (reg/v:V4SI 61 [ s ]) 0)
> > (unspec:V16QI [
> > (mem/c:V16QI (reg/f:SI 16 argp) [0 s+0 S16 A32])
> > ] UNSPEC_LOADU)) t.c:6 1164 {sse2_loaddqu}
> >  (nil))
> > 
> > So it seems it has been too long and I don't remember what is
> > special with arm that it doesn't work...  it possibly simply
> > trusts GET_MODE_ALIGNMENT, never looking at MEM_ALIGN which
> > I think is OK-ish?
> > 
> 
> Yes, that is what Richard said as well.
> 
> > Similarly the very same issue should exist on x86_64 which is
> > !STRICT_ALIGNMENT, it's just the ABI seems to provide the appropriate
> > alignment on the caller side.  So the STRICT_ALIGNMENT check is
> > a wrong one.
> >
> 
>  I may be plain wrong here, but I thought that !STRICT_ALIGNMENT targets
>  just use MEM_ALIGN to select the right instructions.  MEM_ALIGN
>  is always 32-bit align on the DImode memory.  The x86_64 vector 
>  instructions
>  would look at MEM_ALIGN and do the right thing, yes?
> >>>
> >>> No, they need to use the movmisalign optab and end up with UNSPECs
> >>> for example.
> >> Ah, thanks, now I see.
> >>
>  It seems to be the definition of STRICT_ALIGNMENT targets that all RTL
>  instructions need to have MEM_ALIGN >= GET_MODE_ALIGNMENT, so the target
>  does not even have to look at MEM_ALIGN except in the mov_misalign_optab,
>  right?
> >>>
> >>> Yes, I think we never losened that.  Note that RTL expansion has to
> >>> fix this up for them.  Note that strictly speaking SLOW_UNALIGNED_ACCESS
> >>> specifies that x86 is strict-align wrt vector modes.
> >>>
> >>
> >> Yes I agree, the code would be incorrect for x86 as well when the 
> >> 

[committed][AArch64] Use SVE BIC for conditional arithmetic

[Richard Sandiford]

This patch uses BIC to pattern-match conditional AND with an inverted
third input.  It also adds extra tests for AND, ORR and EOR.

Tested on aarch64-linux-gnu (with and without SVE) and aarch64_be-elf.
Applied as r274480.

Richard


2019-08-14  Richard Sandiford  
Kugan Vivekanandarajah  

gcc/
* config/aarch64/aarch64-sve.md (*cond_bic_2)
(*cond_bic_any): New patterns.

gcc/testsuite/
* gcc.target/aarch64/sve/cond_logical_1.c: New test.
* gcc.target/aarch64/sve/cond_logical_1_run.c: Likewise.
* gcc.target/aarch64/sve/cond_logical_2.c: Likewise.
* gcc.target/aarch64/sve/cond_logical_2_run.c: Likewise.
* gcc.target/aarch64/sve/cond_logical_3.c: Likewise.
* gcc.target/aarch64/sve/cond_logical_3_run.c: Likewise.
* gcc.target/aarch64/sve/cond_logical_4.c: Likewise.
* gcc.target/aarch64/sve/cond_logical_4_run.c: Likewise.
* gcc.target/aarch64/sve/cond_logical_5.c: Likewise.
* gcc.target/aarch64/sve/cond_logical_5_run.c: Likewise.

Index: gcc/config/aarch64/aarch64-sve.md
===
--- gcc/config/aarch64/aarch64-sve.md   2019-08-14 12:00:23.761690128 +0100
+++ gcc/config/aarch64/aarch64-sve.md   2019-08-14 12:02:29.540770835 +0100
@@ -2274,6 +2274,50 @@ (define_insn_and_rewrite "*bic3"
   }
 )
 
+;; Predicated integer BIC, merging with the first input.
+(define_insn "*cond_bic_2"
+  [(set (match_operand:SVE_I 0 "register_operand" "=w, ?")
+   (unspec:SVE_I
+ [(match_operand: 1 "register_operand" "Upl, Upl")
+  (and:SVE_I
+(not:SVE_I (match_operand:SVE_I 3 "register_operand" "w, w"))
+(match_operand:SVE_I 2 "register_operand" "0, w"))
+  (match_dup 2)]
+ UNSPEC_SEL))]
+  "TARGET_SVE"
+  "@
+   bic\t%0., %1/m, %0., %3.
+   movprfx\t%0, %2\;bic\t%0., %1/m, %0., %3."
+  [(set_attr "movprfx" "*,yes")]
+)
+
+;; Predicated integer BIC, merging with an independent value.
+(define_insn_and_rewrite "*cond_bic_any"
+  [(set (match_operand:SVE_I 0 "register_operand" "=, , , ?")
+   (unspec:SVE_I
+ [(match_operand: 1 "register_operand" "Upl, Upl, Upl, Upl")
+  (and:SVE_I
+(not:SVE_I (match_operand:SVE_I 3 "register_operand" "w, w, w, w"))
+(match_operand:SVE_I 2 "register_operand" "0, w, w, w"))
+  (match_operand:SVE_I 4 "aarch64_simd_reg_or_zero" "Dz, Dz, 0, w")]
+ UNSPEC_SEL))]
+  "TARGET_SVE && !rtx_equal_p (operands[2], operands[4])"
+  "@
+   movprfx\t%0., %1/z, %0.\;bic\t%0., %1/m, 
%0., %3.
+   movprfx\t%0., %1/z, %2.\;bic\t%0., %1/m, 
%0., %3.
+   movprfx\t%0., %1/m, %2.\;bic\t%0., %1/m, 
%0., %3.
+   #"
+  "&& reload_completed
+   && register_operand (operands[4], mode)
+   && !rtx_equal_p (operands[0], operands[4])"
+  {
+emit_insn (gen_vcond_mask_ (operands[0], operands[2],
+operands[4], operands[1]));
+operands[4] = operands[2] = operands[0];
+  }
+  [(set_attr "movprfx" "yes")]
+)
+
 ;; -
 ;;  [INT] Shifts
 ;; -
Index: gcc/testsuite/gcc.target/aarch64/sve/cond_logical_1.c
===
--- /dev/null   2019-07-30 08:53:31.317691683 +0100
+++ gcc/testsuite/gcc.target/aarch64/sve/cond_logical_1.c   2019-08-14 
12:02:29.540770835 +0100
@@ -0,0 +1,62 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -ftree-vectorize" } */
+
+#include 
+
+#define bit_and(A, B) ((A) & (B))
+#define bit_or(A, B) ((A) | (B))
+#define bit_xor(A, B) ((A) ^ (B))
+#define bit_bic(A, B) ((A) & ~(B))
+
+#define DEF_LOOP(TYPE, OP) \
+  void __attribute__ ((noinline, noclone)) \
+  test_##TYPE##_##OP (TYPE *__restrict r,  \
+ TYPE *__restrict a,   \
+ TYPE *__restrict b,   \
+ TYPE *__restrict c, int n)\
+  {\
+for (int i = 0; i < n; ++i)\
+  r[i] = a[i] < 20 ? OP (b[i], c[i]) : b[i];   \
+  }
+
+#define TEST_TYPE(T, TYPE) \
+  T (TYPE, bit_and) \
+  T (TYPE, bit_or) \
+  T (TYPE, bit_xor) \
+  T (TYPE, bit_bic)
+
+#define TEST_ALL(T) \
+  TEST_TYPE (T, int8_t) \
+  TEST_TYPE (T, uint8_t) \
+  TEST_TYPE (T, int16_t) \
+  TEST_TYPE (T, uint16_t) \
+  TEST_TYPE (T, int32_t) \
+  TEST_TYPE (T, uint32_t) \
+  TEST_TYPE (T, int64_t) \
+  TEST_TYPE (T, uint64_t)
+
+TEST_ALL (DEF_LOOP)
+
+/* { dg-final { scan-assembler-times {\tand\tz[0-9]+\.b, p[0-7]/m,} 2 } } */
+/* { dg-final { scan-assembler-times {\tand\tz[0-9]+\.h, p[0-7]/m,} 2 } } */
+/* { dg-final { scan-assembler-times {\tand\tz[0-9]+\.s, p[0-7]/m,} 2 } } */
+/* { dg-final { scan-assembler-times {\tand\tz[0-9]+\.d, 

Re: [PATCH 1/2] PR c++/91436 fix C++ dialect for std::make_unique fix-it hint

[Jonathan Wakely]

On 13/08/19 16:07 -0400, Jason Merrill wrote:

On 8/13/19 9:32 AM, Jonathan Wakely wrote:

* g++.dg/lookup/missing-std-include-6.C: Don't check make_unique in
test that runs for C++11.


I'm not comfortable removing this test coverage entirely.  Doesn't it 
give a useful diagnostic in C++11 mode as well?


It does:

mu.cc:3:15: error: 'make_unique' is not a member of 'std'
   3 | auto p = std::make_unique();
 |   ^~~
mu.cc:3:15: note: 'std::make_unique' is only available from C++14 onwards
mu.cc:3:27: error: expected primary-expression before 'int'
   3 | auto p = std::make_unique();
 |   ^~~

So we can add it to g++.dg/lookup/missing-std-include-8.C instead,
which runs for c++98_only and checks for the "is only available for"
cases. Here's a patch doing that.

Tested x86_64-linux.

OK for trunk?

OK for gcc-9-branch and gcc-8-branch too, since PR c++/91436 affects
those branches?

commit 5ad7b3202e4818f2d6d84e22e7e489b39a65c851
Author: Jonathan Wakely 
Date:   Tue Aug 13 13:25:39 2019 +0100

PR c++/91436 fix C++ dialect for std::make_unique fix-it hint

The std::make_unique function wasn't added until C++14, and neither was
the std::complex_literals namespace.

gcc/cp:

PR c++/91436
* name-lookup.c (get_std_name_hint): Fix min_dialect field for
complex_literals and make_unique entries.

gcc/testsuite:

PR c++/91436
* g++.dg/lookup/missing-std-include-5.C: Limit test to C++14 and up.
* g++.dg/lookup/missing-std-include-6.C: Don't check make_unique in
test that runs for C++11.
* g++.dg/lookup/missing-std-include-8.C: Check make_unique here.

diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
index d5e491e9072..16c74287bb1 100644
--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -5559,7 +5559,7 @@ get_std_name_hint (const char *name)
 {"bitset", "", cxx11},
 /* .  */
 {"complex", "", cxx98},
-{"complex_literals", "", cxx98},
+{"complex_literals", "", cxx14},
 /* . */
 {"condition_variable", "", cxx11},
 {"condition_variable_any", "", cxx11},
@@ -5632,7 +5632,7 @@ get_std_name_hint (const char *name)
 {"allocator", "", cxx98},
 {"allocator_traits", "", cxx11},
 {"make_shared", "", cxx11},
-{"make_unique", "", cxx11},
+{"make_unique", "", cxx14},
 {"shared_ptr", "", cxx11},
 {"unique_ptr", "", cxx11},
 {"weak_ptr", "", cxx11},
diff --git a/gcc/testsuite/g++.dg/lookup/missing-std-include-5.C b/gcc/testsuite/g++.dg/lookup/missing-std-include-5.C
index fe880a6263b..3ec9abd9316 100644
--- a/gcc/testsuite/g++.dg/lookup/missing-std-include-5.C
+++ b/gcc/testsuite/g++.dg/lookup/missing-std-include-5.C
@@ -1,2 +1,3 @@
+// { dg-do compile { target c++14 } }
 using namespace std::complex_literals; // { dg-error "" }
 // { dg-message "#include " "" { target *-*-* } .-1 }
diff --git a/gcc/testsuite/g++.dg/lookup/missing-std-include-6.C b/gcc/testsuite/g++.dg/lookup/missing-std-include-6.C
index d9eeb4284e8..a8f27473e6d 100644
--- a/gcc/testsuite/g++.dg/lookup/missing-std-include-6.C
+++ b/gcc/testsuite/g++.dg/lookup/missing-std-include-6.C
@@ -11,15 +11,6 @@ void test_make_shared ()
   // { dg-error "expected primary-expression before '\\)' token" "" { target *-*-* } .-3 }
 }
 
-template
-void test_make_unique ()
-{
-  auto p = std::make_unique(); // { dg-error "'make_unique' is not a member of 'std'" }
-  // { dg-message "'#include '" "" { target *-*-* } .-1 }
-  // { dg-error "expected primary-expression before '>' token" "" { target *-*-* } .-2 }
-  // { dg-error "expected primary-expression before '\\)' token" "" { target *-*-* } .-3 }
-}
-
 std::shared_ptr test_shared_ptr; // { dg-error "'shared_ptr' in namespace 'std' does not name a template type" }
 // { dg-message "'#include '" "" { target *-*-* } .-1 }
 
diff --git a/gcc/testsuite/g++.dg/lookup/missing-std-include-8.C b/gcc/testsuite/g++.dg/lookup/missing-std-include-8.C
index 68b208299f2..73532c82968 100644
--- a/gcc/testsuite/g++.dg/lookup/missing-std-include-8.C
+++ b/gcc/testsuite/g++.dg/lookup/missing-std-include-8.C
@@ -13,6 +13,15 @@ void test_make_shared ()
   // { dg-error "expected primary-expression before '\\)' token" "" { target *-*-* } .-3 }
 }
 
+template
+void test_make_unique ()
+{
+  std::make_unique(); // { dg-error "'make_unique' is not a member of 'std'" }
+  // { dg-message "'std::make_unique' is only available from C\\+\\+14 onwards" "" { target *-*-* } .-1 }
+  // { dg-error "expected primary-expression before '>' token" "" { target *-*-* } .-2 }
+  // { dg-error "expected primary-expression before '\\)' token" "" { target *-*-* } .-3 }
+}
+
 void test_array ()
 {
   std::array a; // { dg-error "'array' is not a member of 'std'" }

[committed][AArch64] Use SVE UXT[BHW] as a form of predicated AND

[Richard Sandiford]

UXTB, UXTH and UXTW are equivalent to predicated ANDs with the constants
0xff, 0x and 0x respectively.  This patch uses them in the
patterns for IFN_COND_AND.

Tested on aarch64-linux-gnu (with and without SVE) and aarch64_be-elf.
Applied as r274479.

Richard


2019-08-14  Richard Sandiford  

gcc/
* config/aarch64/aarch64.c (aarch64_print_operand): Allow %e to
take the equivalent mask, as well as a bit count.
* config/aarch64/predicates.md (aarch64_sve_uxtb_immediate)
(aarch64_sve_uxth_immediate, aarch64_sve_uxt_immediate)
(aarch64_sve_pred_and_operand): New predicates.
* config/aarch64/iterators.md (sve_pred_int_rhs2_operand): New
code attribute.
* config/aarch64/aarch64-sve.md
(cond_): Use it.
(*cond_uxt_2, *cond_uxt_any): New patterns.

gcc/testsuite/
* gcc.target/aarch64/sve/cond_uxt_1.c: New test.
* gcc.target/aarch64/sve/cond_uxt_1_run.c: Likewise.
* gcc.target/aarch64/sve/cond_uxt_2.c: Likewise.
* gcc.target/aarch64/sve/cond_uxt_2_run.c: Likewise.
* gcc.target/aarch64/sve/cond_uxt_3.c: Likewise.
* gcc.target/aarch64/sve/cond_uxt_3_run.c: Likewise.
* gcc.target/aarch64/sve/cond_uxt_4.c: Likewise.
* gcc.target/aarch64/sve/cond_uxt_4_run.c: Likewise.

Index: gcc/config/aarch64/aarch64.c
===
--- gcc/config/aarch64/aarch64.c2019-08-14 10:18:10.642319210 +0100
+++ gcc/config/aarch64/aarch64.c2019-08-14 12:00:03.209840337 +0100
@@ -8328,7 +8328,8 @@ sizetochar (int size)
  'D':  Take the duplicated element in a vector constant
and print it as an unsigned integer, in decimal.
  'e':  Print the sign/zero-extend size as a character 8->b,
-   16->h, 32->w.
+   16->h, 32->w.  Can also be used for masks:
+   0xff->b, 0x->h, 0x->w.
  'I':  If the operand is a duplicated vector constant,
replace it with the duplicated scalar.  If the
operand is then a floating-point constant, replace
@@ -8399,27 +8400,22 @@ aarch64_print_operand (FILE *f, rtx x, i
 
 case 'e':
   {
-   int n;
-
-   if (!CONST_INT_P (x)
-   || (n = exact_log2 (INTVAL (x) & ~7)) <= 0)
+   x = unwrap_const_vec_duplicate (x);
+   if (!CONST_INT_P (x))
  {
output_operand_lossage ("invalid operand for '%%%c'", code);
return;
  }
 
-   switch (n)
+   HOST_WIDE_INT val = INTVAL (x);
+   if ((val & ~7) == 8 || val == 0xff)
+ fputc ('b', f);
+   else if ((val & ~7) == 16 || val == 0x)
+ fputc ('h', f);
+   else if ((val & ~7) == 32 || val == 0x)
+ fputc ('w', f);
+   else
  {
- case 3:
-   fputc ('b', f);
-   break;
- case 4:
-   fputc ('h', f);
-   break;
- case 5:
-   fputc ('w', f);
-   break;
- default:
output_operand_lossage ("invalid operand for '%%%c'", code);
return;
  }
Index: gcc/config/aarch64/predicates.md
===
--- gcc/config/aarch64/predicates.md2019-08-14 10:18:10.642319210 +0100
+++ gcc/config/aarch64/predicates.md2019-08-14 12:00:03.209840337 +0100
@@ -606,11 +606,26 @@ (define_predicate "aarch64_sve_inc_dec_i
   (and (match_code "const,const_vector")
(match_test "aarch64_sve_inc_dec_immediate_p (op)")))
 
+(define_predicate "aarch64_sve_uxtb_immediate"
+  (and (match_code "const_vector")
+   (match_test "GET_MODE_UNIT_BITSIZE (GET_MODE (op)) > 8")
+   (match_test "aarch64_const_vec_all_same_int_p (op, 0xff)")))
+
+(define_predicate "aarch64_sve_uxth_immediate"
+  (and (match_code "const_vector")
+   (match_test "GET_MODE_UNIT_BITSIZE (GET_MODE (op)) > 16")
+   (match_test "aarch64_const_vec_all_same_int_p (op, 0x)")))
+
 (define_predicate "aarch64_sve_uxtw_immediate"
   (and (match_code "const_vector")
(match_test "GET_MODE_UNIT_BITSIZE (GET_MODE (op)) > 32")
(match_test "aarch64_const_vec_all_same_int_p (op, 0x)")))
 
+(define_predicate "aarch64_sve_uxt_immediate"
+  (ior (match_operand 0 "aarch64_sve_uxtb_immediate")
+   (match_operand 0 "aarch64_sve_uxth_immediate")
+   (match_operand 0 "aarch64_sve_uxtw_immediate")))
+
 (define_predicate "aarch64_sve_logical_immediate"
   (and (match_code "const,const_vector")
(match_test "aarch64_sve_bitmask_immediate_p (op)")))
@@ -670,6 +685,10 @@ (define_predicate "aarch64_sve_add_opera
(match_operand 0 "aarch64_sve_sub_arith_immediate")
(match_operand 0 "aarch64_sve_inc_dec_immediate")))
 
+(define_predicate "aarch64_sve_pred_and_operand"
+  (ior (match_operand 0 

[committed][AArch64] Add SVE conditional conversion patterns

[Richard Sandiford]

This patch adds patterns to match conditional conversions between
integers and like-sized floats.  The patterns are actually more
general than that, but the other combinations can only be tested
via the ACLE.

Tested on aarch64-linux-gnu (with and without SVE) and aarch64_be-elf.
Applied as r274478.

Richard


2019-08-14  Richard Sandiford  

gcc/
* config/aarch64/aarch64-sve.md
(*cond__nontrunc)
(*cond__nonextend):
New patterns.

gcc/testsuite/
* gcc.target/aarch64/sve/cond_convert_1.c: New test.
* gcc.target/aarch64/sve/cond_convert_1_run.c: Likewise.
* gcc.target/aarch64/sve/cond_convert_2.c: Likewise.
* gcc.target/aarch64/sve/cond_convert_2_run.c: Likewise.
* gcc.target/aarch64/sve/cond_convert_3.c: Likewise.
* gcc.target/aarch64/sve/cond_convert_3_run.c: Likewise.
* gcc.target/aarch64/sve/cond_convert_4.c: Likewise.
* gcc.target/aarch64/sve/cond_convert_4_run.c: Likewise.
* gcc.target/aarch64/sve/cond_convert_5.c: Likewise.
* gcc.target/aarch64/sve/cond_convert_5_run.c: Likewise.
* gcc.target/aarch64/sve/cond_convert_6.c: Likewise.
* gcc.target/aarch64/sve/cond_convert_6_run.c: Likewise.

Index: gcc/config/aarch64/aarch64-sve.md
===
--- gcc/config/aarch64/aarch64-sve.md   2019-08-14 11:53:04.636898923 +0100
+++ gcc/config/aarch64/aarch64-sve.md   2019-08-14 11:55:33.251813494 +0100
@@ -4071,6 +4071,39 @@ (define_insn "*aarch64_sve__trunc
   "fcvtz\t%0., %1/m, %2."
 )
 
+;; Predicated float-to-integer conversion with merging, either to the same
+;; width or wider.
+;;
+;; The first alternative doesn't need the earlyclobber, but the only case
+;; it would help is the uninteresting one in which operands 2 and 3 are
+;; the same register (despite having different modes).  Making all the
+;; alternatives earlyclobber makes things more consistent for the
+;; register allocator.
+(define_insn_and_rewrite "*cond__nontrunc"
+  [(set (match_operand:SVE_HSDI 0 "register_operand" "=, , ?")
+   (unspec:SVE_HSDI
+ [(match_operand: 1 "register_operand" "Upl, Upl, Upl")
+  (unspec:SVE_HSDI
+[(match_operand 4)
+ (match_operand:SI 5 "aarch64_sve_gp_strictness")
+ (match_operand:SVE_F 2 "register_operand" "w, w, w")]
+SVE_COND_FCVTI)
+  (match_operand:SVE_HSDI 3 "aarch64_simd_reg_or_zero" "0, Dz, w")]
+ UNSPEC_SEL))]
+  "TARGET_SVE
+   &&  >= 
+   && aarch64_sve_pred_dominates_p ([4], operands[1])"
+  "@
+   fcvtz\t%0., %1/m, %2.
+   movprfx\t%0., %1/z, 
%2.\;fcvtz\t%0., %1/m, %2.
+   movprfx\t%0, %3\;fcvtz\t%0., %1/m, %2."
+  "&& !rtx_equal_p (operands[1], operands[4])"
+  {
+operands[4] = copy_rtx (operands[1]);
+  }
+  [(set_attr "movprfx" "*,yes,yes")]
+)
+
 ;; -
 ;;  [INT<-FP] Packs
 ;; -
@@ -4155,6 +4188,39 @@ (define_insn "aarch64_sve__extend
   "cvtf\t%0., %1/m, %2."
 )
 
+;; Predicated integer-to-float conversion with merging, either to the same
+;; width or narrower.
+;;
+;; The first alternative doesn't need the earlyclobber, but the only case
+;; it would help is the uninteresting one in which operands 2 and 3 are
+;; the same register (despite having different modes).  Making all the
+;; alternatives earlyclobber makes things more consistent for the
+;; register allocator.
+(define_insn_and_rewrite "*cond__nonextend"
+  [(set (match_operand:SVE_F 0 "register_operand" "=, , ?")
+   (unspec:SVE_F
+ [(match_operand: 1 "register_operand" "Upl, Upl, Upl")
+  (unspec:SVE_F
+[(match_operand 4)
+ (match_operand:SI 5 "aarch64_sve_gp_strictness")
+ (match_operand:SVE_HSDI 2 "register_operand" "w, w, w")]
+SVE_COND_ICVTF)
+  (match_operand:SVE_F 3 "aarch64_simd_reg_or_zero" "0, Dz, w")]
+ UNSPEC_SEL))]
+  "TARGET_SVE
+   &&  >= 
+   && aarch64_sve_pred_dominates_p ([4], operands[1])"
+  "@
+   cvtf\t%0., %1/m, %2.
+   movprfx\t%0., %1/z, 
%2.\;cvtf\t%0., %1/m, %2.
+   movprfx\t%0, %3\;cvtf\t%0., %1/m, %2."
+  "&& !rtx_equal_p (operands[1], operands[4])"
+  {
+operands[4] = copy_rtx (operands[1]);
+  }
+  [(set_attr "movprfx" "*,yes,yes")]
+)
+
 ;; -
 ;;  [FP<-INT] Packs
 ;; -
Index: gcc/testsuite/gcc.target/aarch64/sve/cond_convert_1.c
===
--- /dev/null   2019-07-30 08:53:31.317691683 +0100
+++ gcc/testsuite/gcc.target/aarch64/sve/cond_convert_1.c   2019-08-14 
11:55:33.251813494 +0100
@@ -0,0 +1,37 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -ftree-vectorize -fno-trapping-math" } */
+

[committed][AArch64] Add SVE conditional floating-point unary patterns

[Richard Sandiford]

This patch adds patterns to match conditional unary operations
on floating-point modes.  At the moment we rely on combine to merge
separate arithmetic and vcond_mask operations, and since the latter
doesn't accept zero operands, we miss out on the opportunity to use
the movprfx /z alternative.  (This alternative is tested by the ACLE
patches though.)

Tested on aarch64-linux-gnu (with and without SVE) and aarch64_be-elf.
Applied as r274477.

Richard


2019-08-14  Richard Sandiford  
Kugan Vivekanandarajah  

gcc/
* config/aarch64/aarch64-sve.md
(*cond__2): New pattern.
(*cond__any): Likewise.

gcc/testsuite/
* gcc.target/aarch64/sve/cond_unary_1.c: Add tests for
floating-point types.
* gcc.target/aarch64/sve/cond_unary_2.c: Likewise.
* gcc.target/aarch64/sve/cond_unary_3.c: Likewise.
* gcc.target/aarch64/sve/cond_unary_4.c: Likewise.

Index: gcc/config/aarch64/aarch64-sve.md
===
--- gcc/config/aarch64/aarch64-sve.md   2019-08-14 11:48:45.114792555 +0100
+++ gcc/config/aarch64/aarch64-sve.md   2019-08-14 11:51:07.537753363 +0100
@@ -1624,6 +1624,62 @@ (define_insn "*2"
   "\t%0., %1/m, %2."
 )
 
+;; Predicated floating-point unary arithmetic, merging with the first input.
+(define_insn_and_rewrite "*cond__2"
+  [(set (match_operand:SVE_F 0 "register_operand" "=w, ?")
+   (unspec:SVE_F
+ [(match_operand: 1 "register_operand" "Upl, Upl")
+  (unspec:SVE_F
+[(match_operand 3)
+ (match_operand:SI 4 "aarch64_sve_gp_strictness")
+ (match_operand:SVE_F 2 "register_operand" "0, w")]
+SVE_COND_FP_UNARY)
+  (match_dup 2)]
+ UNSPEC_SEL))]
+  "TARGET_SVE && aarch64_sve_pred_dominates_p ([3], operands[1])"
+  "@
+   \t%0., %1/m, %0.
+   movprfx\t%0, %2\;\t%0., %1/m, %2."
+  "&& !rtx_equal_p (operands[1], operands[3])"
+  {
+operands[3] = copy_rtx (operands[1]);
+  }
+  [(set_attr "movprfx" "*,yes")]
+)
+
+;; Predicated floating-point unary arithmetic, merging with an independent
+;; value.
+;;
+;; The earlyclobber isn't needed for the first alternative, but omitting
+;; it would only help the case in which operands 2 and 3 are the same,
+;; which is handled above rather than here.  Marking all the alternatives
+;; as earlyclobber helps to make the instruction more regular to the
+;; register allocator.
+(define_insn_and_rewrite "*cond__any"
+  [(set (match_operand:SVE_F 0 "register_operand" "=, ?, ?")
+   (unspec:SVE_F
+ [(match_operand: 1 "register_operand" "Upl, Upl, Upl")
+  (unspec:SVE_F
+[(match_operand 4)
+ (match_operand:SI 5 "aarch64_sve_gp_strictness")
+ (match_operand:SVE_F 2 "register_operand" "w, w, w")]
+SVE_COND_FP_UNARY)
+  (match_operand:SVE_F 3 "aarch64_simd_reg_or_zero" "0, Dz, w")]
+ UNSPEC_SEL))]
+  "TARGET_SVE
+   && !rtx_equal_p (operands[2], operands[3])
+   && aarch64_sve_pred_dominates_p ([4], operands[1])"
+  "@
+   \t%0., %1/m, %2.
+   movprfx\t%0., %1/z, %2.\;\t%0., %1/m, 
%2.
+   movprfx\t%0, %3\;\t%0., %1/m, %2."
+  "&& !rtx_equal_p (operands[1], operands[4])"
+  {
+operands[4] = copy_rtx (operands[1]);
+  }
+  [(set_attr "movprfx" "*,yes,yes")]
+)
+
 ;; -
 ;;  [PRED] Inverse
 ;; -
Index: gcc/testsuite/gcc.target/aarch64/sve/cond_unary_1.c
===
--- gcc/testsuite/gcc.target/aarch64/sve/cond_unary_1.c 2019-08-14 
11:48:45.114792555 +0100
+++ gcc/testsuite/gcc.target/aarch64/sve/cond_unary_1.c 2019-08-14 
11:51:07.537753363 +0100
@@ -15,15 +15,22 @@ #define DEF_LOOP(TYPE, OP)  
\
   r[i] = pred[i] ? OP (a[i]) : a[i];   \
   }
 
-#define TEST_TYPE(T, TYPE) \
+#define TEST_INT_TYPE(T, TYPE) \
   T (TYPE, abs) \
   T (TYPE, neg)
 
+#define TEST_FLOAT_TYPE(T, TYPE, SUFFIX) \
+  T (TYPE, __builtin_fabs##SUFFIX) \
+  T (TYPE, neg)
+
 #define TEST_ALL(T) \
-  TEST_TYPE (T, int8_t) \
-  TEST_TYPE (T, int16_t) \
-  TEST_TYPE (T, int32_t) \
-  TEST_TYPE (T, int64_t)
+  TEST_INT_TYPE (T, int8_t) \
+  TEST_INT_TYPE (T, int16_t) \
+  TEST_INT_TYPE (T, int32_t) \
+  TEST_INT_TYPE (T, int64_t) \
+  TEST_FLOAT_TYPE (T, _Float16, f16) \
+  TEST_FLOAT_TYPE (T, float, f) \
+  TEST_FLOAT_TYPE (T, double, )
 
 TEST_ALL (DEF_LOOP)
 
@@ -37,6 +44,14 @@ TEST_ALL (DEF_LOOP)
 /* { dg-final { scan-assembler-times {\tneg\tz[0-9]+\.s, p[0-7]/m,} 1 } } */
 /* { dg-final { scan-assembler-times {\tneg\tz[0-9]+\.d, p[0-7]/m,} 1 } } */
 
+/* { dg-final { scan-assembler-times {\tfabs\tz[0-9]+\.h, p[0-7]/m,} 1 } } */
+/* { dg-final { scan-assembler-times {\tfabs\tz[0-9]+\.s, p[0-7]/m,} 1 } } */
+/* { dg-final { scan-assembler-times {\tfabs\tz[0-9]+\.d, 

[committed][AArch64] Add SVE conditional integer unary patterns

[Richard Sandiford]

This patch adds patterns to match conditional unary operations
on integers.  At the moment we rely on combine to merge separate
arithmetic and vcond_mask operations, and since the latter doesn't
accept zero operands, we miss out on the opportunity to use the
movprfx /z alternative.  (This alternative is tested by the ACLE
patches though.)

Tested on aarch64-linux-gnu (with and without SVE) and aarch64_be-elf.
Applied as r274476.

Richard


2019-08-14  Richard Sandiford  
Kugan Vivekanandarajah  

gcc/
* config/aarch64/aarch64-sve.md
(*cond__2): New pattern.
(*cond__any): Likewise.

gcc/testsuite/
* gcc.target/aarch64/sve/cond_unary_1.c: New test.
* gcc.target/aarch64/sve/cond_unary_1_run.c: Likewise.
* gcc.target/aarch64/sve/cond_unary_2.c: Likewise.
* gcc.target/aarch64/sve/cond_unary_2_run.c: Likewise.
* gcc.target/aarch64/sve/cond_unary_3.c: Likewise.
* gcc.target/aarch64/sve/cond_unary_3_run.c: Likewise.
* gcc.target/aarch64/sve/cond_unary_4.c: Likewise.
* gcc.target/aarch64/sve/cond_unary_4_run.c: Likewise.

Index: gcc/config/aarch64/aarch64-sve.md
===
--- gcc/config/aarch64/aarch64-sve.md   2019-08-14 10:28:46.145666799 +0100
+++ gcc/config/aarch64/aarch64-sve.md   2019-08-14 11:47:53.151171700 +0100
@@ -1454,6 +1454,45 @@ (define_insn "*2"
   "\t%0., %1/m, %2."
 )
 
+;; Predicated integer unary arithmetic, merging with the first input.
+(define_insn "*cond__2"
+  [(set (match_operand:SVE_I 0 "register_operand" "=w, ?")
+   (unspec:SVE_I
+ [(match_operand: 1 "register_operand" "Upl, Upl")
+  (SVE_INT_UNARY:SVE_I
+(match_operand:SVE_I 2 "register_operand" "0, w"))
+  (match_dup 2)]
+ UNSPEC_SEL))]
+  "TARGET_SVE"
+  "@
+   \t%0., %1/m, %0.
+   movprfx\t%0, %2\;\t%0., %1/m, %2."
+  [(set_attr "movprfx" "*,yes")]
+)
+
+;; Predicated integer unary arithmetic, merging with an independent value.
+;;
+;; The earlyclobber isn't needed for the first alternative, but omitting
+;; it would only help the case in which operands 2 and 3 are the same,
+;; which is handled above rather than here.  Marking all the alternatives
+;; as earlyclobber helps to make the instruction more regular to the
+;; register allocator.
+(define_insn "*cond__any"
+  [(set (match_operand:SVE_I 0 "register_operand" "=, ?, ?")
+   (unspec:SVE_I
+ [(match_operand: 1 "register_operand" "Upl, Upl, Upl")
+  (SVE_INT_UNARY:SVE_I
+(match_operand:SVE_I 2 "register_operand" "w, w, w"))
+  (match_operand:SVE_I 3 "aarch64_simd_reg_or_zero" "0, Dz, w")]
+ UNSPEC_SEL))]
+  "TARGET_SVE && !rtx_equal_p (operands[2], operands[3])"
+  "@
+   \t%0., %1/m, %2.
+   movprfx\t%0., %1/z, %2.\;\t%0., %1/m, 
%2.
+   movprfx\t%0, %3\;\t%0., %1/m, %2."
+  [(set_attr "movprfx" "*,yes,yes")]
+)
+
 ;; -
 ;;  [INT] Logical inverse
 ;; -
Index: gcc/testsuite/gcc.target/aarch64/sve/cond_unary_1.c
===
--- /dev/null   2019-07-30 08:53:31.317691683 +0100
+++ gcc/testsuite/gcc.target/aarch64/sve/cond_unary_1.c 2019-08-14 
11:47:53.151171700 +0100
@@ -0,0 +1,44 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -ftree-vectorize" } */
+
+#include 
+
+#define abs(A) ((A) < 0 ? -(A) : (A))
+#define neg(A) (-(A))
+
+#define DEF_LOOP(TYPE, OP) \
+  void __attribute__ ((noipa)) \
+  test_##TYPE##_##OP (TYPE *__restrict r, TYPE *__restrict a,  \
+ TYPE *__restrict pred, int n) \
+  {\
+for (int i = 0; i < n; ++i)\
+  r[i] = pred[i] ? OP (a[i]) : a[i];   \
+  }
+
+#define TEST_TYPE(T, TYPE) \
+  T (TYPE, abs) \
+  T (TYPE, neg)
+
+#define TEST_ALL(T) \
+  TEST_TYPE (T, int8_t) \
+  TEST_TYPE (T, int16_t) \
+  TEST_TYPE (T, int32_t) \
+  TEST_TYPE (T, int64_t)
+
+TEST_ALL (DEF_LOOP)
+
+/* { dg-final { scan-assembler-times {\tabs\tz[0-9]+\.b, p[0-7]/m,} 1 } } */
+/* { dg-final { scan-assembler-times {\tabs\tz[0-9]+\.h, p[0-7]/m,} 1 } } */
+/* { dg-final { scan-assembler-times {\tabs\tz[0-9]+\.s, p[0-7]/m,} 1 } } */
+/* { dg-final { scan-assembler-times {\tabs\tz[0-9]+\.d, p[0-7]/m,} 1 } } */
+
+/* { dg-final { scan-assembler-times {\tneg\tz[0-9]+\.b, p[0-7]/m,} 1 } } */
+/* { dg-final { scan-assembler-times {\tneg\tz[0-9]+\.h, p[0-7]/m,} 1 } } */
+/* { dg-final { scan-assembler-times {\tneg\tz[0-9]+\.s, p[0-7]/m,} 1 } } */
+/* { dg-final { scan-assembler-times {\tneg\tz[0-9]+\.d, p[0-7]/m,} 1 } } */
+
+/* { dg-final { scan-assembler-not {\tmov\tz} } } */
+/* { dg-final { scan-assembler-not 

[PING] [PATCHv4] Fix not 8-byte aligned ldrd/strd on ARMv5 (PR 89544)

[Bernd Edlinger]

Hi!

I'd like to ping for this patch:
https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00546.html


Thanks
Bernd.

Re: [PATCH 2/2] Add more entries to the C++ get_std_name_hint array

[Jonathan Wakely]

On 13/08/19 16:08 -0400, Jason Merrill wrote:

On 8/13/19 9:36 AM, Jonathan Wakely wrote:

This adds some commonly-used C++11/14 names, and some new C++17/20
names. The latter aren't available when using the -std=gnu++14
default, so the fix-it suggesting to use a newer dialect is helpful.

* name-lookup.c (get_std_name_hint): Add more entries.

Tested x86_64-linux. OK for trunk?


OK.


I realised as I was about to commit it that cxx17 is the wrong dialect
for remove_cvref and remove_cvref_t, so I corrected them to cxx2a
before committing it.

(I've tried to use remove_cvref_t in C++17 a few times, so this
diagnostic should help me!)

[Ada] Improve performance of Containers.Functional_Base

[Pierre-Marie de Rodat]

This patch modifies the implementation of Functional_Base to damp the
cost of its subprograms at runtime in specific cases. Instead of copying
the entire underlying array to create a new container, containers can
share the same Array_Base attribute. Performance on common use cases of
formal and functional containers is improved with this patch.

Tested on x86_64-pc-linux-gnu, committed on trunk

2019-08-14  Joffrey Huguet  

gcc/ada/

* libgnat/a-cofuba.ads: Add a Length attribute to type
Container. Add a type Array_Base which replaces the previous
Elements attribute of Container.
(Content_Init): New subprogram. It is used to initialize the
Base attribute of Container.
* libgnat/a-cofuba.adb (Resize): New subprogram. It is used to
resize the underlying array of a container if necessary.
(=, <=, Find, Get, Intersection, Length, Num_Overlaps, Set,
Union): Update to match changes in type declarations.
(Add): Modify body to damp the time and space cost in a specific
case.
(Content_Init): New subprogram. It is used to initialize the
Base attribute of Container.
(Remove): Modify body to damp the time and space cost in a
specific case.--- gcc/ada/libgnat/a-cofuba.adb
+++ gcc/ada/libgnat/a-cofuba.adb
@@ -30,6 +30,7 @@
 --
 
 pragma Ada_2012;
+with Ada.Unchecked_Deallocation;
 
 package body Ada.Containers.Functional_Base with SPARK_Mode => Off is
 
@@ -47,18 +48,22 @@ package body Ada.Containers.Functional_Base with SPARK_Mode => Off is
--  Search a container C for an element equal to E.all, returning the
--  position in the underlying array.
 
+   procedure Resize (Base : Array_Base_Access);
+   --  Resize the underlying array if needed so that it can contain one more
+   --  element.
+
-
-- "=" --
-
 
function "=" (C1 : Container; C2 : Container) return Boolean is
begin
-  if C1.Elements'Length /= C2.Elements'Length then
+  if C1.Length /= C2.Length then
  return False;
   end if;
 
-  for I in C1.Elements'Range loop
- if C1.Elements (I).all /= C2.Elements (I).all then
+  for I in 1 .. C1.Length loop
+ if C1.Base.Elements (I).all /= C2.Base.Elements (I).all then
 return False;
  end if;
   end loop;
@@ -72,8 +77,8 @@ package body Ada.Containers.Functional_Base with SPARK_Mode => Off is
 
function "<=" (C1 : Container; C2 : Container) return Boolean is
begin
-  for I in C1.Elements'Range loop
- if Find (C2, C1.Elements (I)) = 0 then
+  for I in 1 .. C1.Length loop
+ if Find (C2, C1.Base.Elements (I)) = 0 then
 return False;
  end if;
   end loop;
@@ -90,31 +95,58 @@ package body Ada.Containers.Functional_Base with SPARK_Mode => Off is
   I : Index_Type;
   E : Element_Type) return Container
is
-  A : constant Element_Array_Access :=
-new Element_Array'(1 .. C.Elements'Last + 1 => <>);
-  P : Count_Type := 0;
-
begin
-  for J in 1 .. C.Elements'Last + 1 loop
- if J /= To_Count (I) then
-P := P + 1;
-A (J) := C.Elements (P);
- else
-A (J) := new Element_Type'(E);
- end if;
-  end loop;
-
-  return Container'(Elements => A);
+  if To_Count (I) = C.Length + 1 and then C.Length = C.Base.Max_Length then
+ Resize (C.Base);
+ C.Base.Max_Length := C.Base.Max_Length + 1;
+ C.Base.Elements (C.Base.Max_Length) := new Element_Type'(E);
+
+ return Container'(Length => C.Base.Max_Length, Base => C.Base);
+  else
+ declare
+A : constant Array_Base_Access := Content_Init (C.Length);
+P : Count_Type := 0;
+ begin
+A.Max_Length := C.Length + 1;
+for J in 1 .. C.Length + 1 loop
+   if J /= To_Count (I) then
+  P := P + 1;
+  A.Elements (J) := C.Base.Elements (P);
+   else
+  A.Elements (J) := new Element_Type'(E);
+   end if;
+end loop;
+
+return Container'(Length => A.Max_Length,
+  Base   => A);
+ end;
+  end if;
end Add;
 
+   --
+   -- Content_Init --
+   --
+
+   function Content_Init (L : Count_Type := 0) return Array_Base_Access
+   is
+  Max_Init : constant Count_Type := 100;
+  Size : constant Count_Type :=
+(if L < Count_Type'Last - Max_Init then L + Max_Init
+ else Count_Type'Last);
+  Elements : constant Element_Array_Access :=
+new Element_Array'(1 .. Size => <>);
+   begin
+  return new Array_Base'(Max_Length => 0, Elements => Elements);
+   end Content_Init;
+
--
-- Find --
--
 
function Find (C : 

[Ada] Fix internal error on inlined subprogram instance

[Pierre-Marie de Rodat]

This fixes a long-standing oddity in the procedure analyzing the
instantiation of a generic subprogram, which would set the
Is_Generic_Instance flag on the enclosing package generated for the
instantiation but only to reset it a few lines below.  Now this flag is
relied upon by the machinery which computes the set of public entities
to be exposed by a package.

Tested on x86_64-pc-linux-gnu, committed on trunk

2019-08-14  Eric Botcazou  

gcc/ada/

* sem_ch12.adb (Analyze_Instance_And_Renamings): Do not reset
the Is_Generic_Instance flag previously set on the package
generated for the instantiation of a generic subprogram.

gcc/testsuite/

* gnat.dg/generic_inst11.adb, gnat.dg/generic_inst11_pkg.adb,
gnat.dg/generic_inst11_pkg.ads: New testcase.--- gcc/ada/sem_ch12.adb
+++ gcc/ada/sem_ch12.adb
@@ -5264,10 +5264,6 @@ package body Sem_Ch12 is
 
  Analyze (Pack_Decl);
  Check_Formal_Packages (Pack_Id);
- Set_Is_Generic_Instance (Pack_Id, False);
-
- --  Why do we clear Is_Generic_Instance??? We set it 20 lines
- --  above???
 
  --  Body of the enclosing package is supplied when instantiating the
  --  subprogram body, after semantic analysis is completed.

--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/generic_inst11.adb
@@ -0,0 +1,9 @@
+--  { dg-do compile }
+--  { dg-options "-O -gnatn" }
+
+with Generic_Inst11_Pkg;
+
+procedure Generic_Inst11 is
+begin
+   Generic_Inst11_Pkg.Proc;
+end;

--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/generic_inst11_pkg.adb
@@ -0,0 +1,21 @@
+with System;
+
+package body Generic_Inst11_Pkg is
+
+   Data : Integer;
+
+   generic
+  Reg_Address : System.Address;
+   procedure Inner_G with Inline;
+
+   procedure Inner_G is
+  Reg : Integer with Address => Reg_Address;
+   begin
+  null;
+   end;
+
+   procedure My_Inner_G is new Inner_G (Data'Address);
+
+   procedure Proc renames My_Inner_G;
+
+end Generic_Inst11_Pkg;

--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/generic_inst11_pkg.ads
@@ -0,0 +1,5 @@
+package Generic_Inst11_Pkg is
+
+   procedure Proc with Inline;
+
+end Generic_Inst11_Pkg;

[Ada] Compiler speedup with inlining across units

[Pierre-Marie de Rodat]

This change is aimed at speeding up the inlining across units done by
the Ada compiler when -gnatn is specified and in the presence of units
instantiating a lot of generic packages.

The current implementation is as follows: when a generic package is
being instantiated, the compiler scans its spec for the presence of
subprograms with an aspect/pragma Inline and, upon finding one,
schedules the instantiation of its body.  That's not very efficient
because the compiler doesn't know yet if one of those inlined
subprograms will eventually be called from the main unit.

The new implementation arranges for the compiler to instantiate the body
on demand, i.e. when it encounters a call to one of the inlined
subprograms.  That's still not optimal because, at this point, the
compiler has not yet computed whether the call itself is reachable from
the main unit (it will do this computation at the very end of the
processing, just before sending the inlined units to the code generator)
but that's nevertheless a net progress.

The patch also enhances the -gnatd.j option to make it output the list
of instances "inlined" this way.  The following package is a simple
example:

with Q;

procedure P is
begin
  Q.Proc;
end;

package Q is

  procedure Proc;
  pragma Inline (Proc);

end Q;

with G;

package body Q is

  package My_G is new G (1);

  procedure Proc is
Val : constant Integer := My_G.Func;
  begin
if Val /= 1 then
  raise Program_Error;
end if;
  end;

end Q;

generic

  Value : Integer;

package G is

  function Func return Integer;
  pragma Inline (Func);

end G;

package body G is

  function Func return Integer is
  begin
return Value;
  end;

end G;

Tested on x86_64-pc-linux-gnu, committed on trunk

2019-08-14  Eric Botcazou  

gcc/ada/

* einfo.ads (Is_Called): Document new usage on E_Package
entities.
* einfo.adb (Is_Called): Accept E_Package entities.
(Set_Is_Called): Likewise.
* exp_ch6.adb (Expand_Call_Helper): Move code dealing with
instances for back-end inlining to Add_Inlined_Body.
* inline.ads: Remove with clauses for Alloc and Table.
(Pending_Instantiations): Move to...
* inline.adb: Add with clauses for Alloc, Uintp, Table and
GNAT.HTable.
(Backend_Instances): New variable.
(Pending_Instantiations): ...here.
(Called_Pending_Instantiations): New table.
(Node_Table_Size): New constant.
(Node_Header_Num): New subtype.
(Node_Hash): New function.
(To_Pending_Instantiations): New hash table.
(Add_Inlined_Body): Bail out early for subprograms in the main
unit or subunit.  Likewise if the Is_Called flag is set.  If the
subprogram is an instance, invoke Add_Inlined_Instance.  Call
Set_Is_Called earlier.  If the subrogram is within an instance,
invoke Add_Inlined_Instance.  Also deal with the case where the
call itself is within an instance.
(Add_Inlined_Instance): New procedure.
(Add_Inlined_Subprogram): Remove conditions always fulfilled.
(Add_Pending_Instantiation): Move the defence against ludicruous
number of instantiations to here. When back-end inlining is
enabled, associate an instantiation with its index in table and
mark a few selected kinds of instantiations as always needed.
(Initialize): Set Backend_Instances to No_Elist.
(Instantiate_Body): New procedure doing the work extracted
from...
(Instantiate_Bodies): ...here.  When back-end inlining is
enabled, loop over Called_Pending_Instantiations instead of
Pending_Instantiations.
(Is_Nested): Minor tweak.
(List_Inlining_Info): Also list the contents of
Backend_Instances.
* sem_ch12.adb (Might_Inline_Subp): Return early if Is_Inlined
is set and otherwise set it before returning true.
(Analyze_Package_Instantiation): Remove the defence against
ludicruous number of instantiations.  Invoke
Remove_Dead_Instance instead of doing the removal manually if
there is a guaranteed ABE.

patch.diff.gz
Description: application/gzip

[Ada] Check SPARK restriction on Old/Loop_Entry with pointers

[Pierre-Marie de Rodat]

SPARK RM rule 3.10(14) restricts the use of Old and Loop_Entry
attributes on prefixes of an owning or observing type (i.e. a type with
access inside).

There is no impact on compilation.

Tested on x86_64-pc-linux-gnu, committed on trunk

2019-08-14  Yannick Moy  

gcc/ada/

* sem_spark.adb (Check_Old_Loop_Entry): New procedure to check
correct use of Old  and Loop_Entry.
(Check_Node): Check subprogram contracts.
(Check_Pragma): Check Loop_Variant.
(Check_Safe_Pointers): Apply checking to library-level
subprogram  declarations as well, in order to check their
contract.
--- gcc/ada/sem_spark.adb
+++ gcc/ada/sem_spark.adb
@@ -663,6 +663,9 @@ package body Sem_SPARK is
procedure Check_Node (N : Node_Id);
--  Main traversal procedure to check safe pointer usage
 
+   procedure Check_Old_Loop_Entry (N : Node_Id);
+   --  Check SPARK RM 3.10(14) regarding 'Old and 'Loop_Entry
+
procedure Check_Package_Body (Pack : Node_Id);
 
procedure Check_Package_Spec (Pack : Node_Id);
@@ -2583,6 +2586,43 @@ package body Sem_SPARK is

 
procedure Check_Node (N : Node_Id) is
+
+  procedure Check_Subprogram_Contract (N : Node_Id);
+  --  Check the postcondition-like contracts for use of 'Old
+
+  ---
+  -- Check_Subprogram_Contract --
+  ---
+
+  procedure Check_Subprogram_Contract (N : Node_Id) is
+  begin
+ if Nkind (N) = N_Subprogram_Declaration
+   or else Acts_As_Spec (N)
+ then
+declare
+   E: constant Entity_Id := Unique_Defining_Entity (N);
+   Post : constant Node_Id :=
+ Get_Pragma (E, Pragma_Postcondition);
+   Cases: constant Node_Id :=
+ Get_Pragma (E, Pragma_Contract_Cases);
+begin
+   Check_Old_Loop_Entry (Post);
+   Check_Old_Loop_Entry (Cases);
+end;
+
+ elsif Nkind (N) = N_Subprogram_Body then
+declare
+   E: constant Entity_Id := Defining_Entity (N);
+   Ref_Post : constant Node_Id :=
+ Get_Pragma (E, Pragma_Refined_Post);
+begin
+   Check_Old_Loop_Entry (Ref_Post);
+end;
+ end if;
+  end Check_Subprogram_Contract;
+
+   --  Start of processing for Check_Node
+
begin
   case Nkind (N) is
  when N_Declaration =>
@@ -2602,14 +2642,17 @@ package body Sem_SPARK is
Check_Package_Body (N);
 end if;
 
- when N_Subprogram_Body
-| N_Entry_Body
-| N_Task_Body
- =>
+ when N_Subprogram_Body =>
 if not Is_Generic_Unit (Unique_Defining_Entity (N)) then
+   Check_Subprogram_Contract (N);
Check_Callable_Body (N);
 end if;
 
+ when N_Entry_Body
+| N_Task_Body
+ =>
+Check_Callable_Body (N);
+
  when N_Protected_Body =>
 Check_List (Declarations (N));
 
@@ -2622,6 +2665,9 @@ package body Sem_SPARK is
  when N_Pragma =>
 Check_Pragma (N);
 
+ when N_Subprogram_Declaration =>
+Check_Subprogram_Contract (N);
+
  --  Ignored constructs for pointer checking
 
  when N_Abstract_Subprogram_Declaration
@@ -2655,7 +2701,6 @@ package body Sem_SPARK is
 | N_Procedure_Instantiation
 | N_Raise_xxx_Error
 | N_Record_Representation_Clause
-| N_Subprogram_Declaration
 | N_Subprogram_Renaming_Declaration
 | N_Task_Type_Declaration
 | N_Use_Package_Clause
@@ -2677,6 +2722,65 @@ package body Sem_SPARK is
   end case;
end Check_Node;
 
+   --
+   -- Check_Old_Loop_Entry --
+   --
+
+   procedure Check_Old_Loop_Entry (N : Node_Id) is
+
+  function Check_Attribute (N : Node_Id) return Traverse_Result;
+
+  -
+  -- Check_Attribute --
+  -
+
+  function Check_Attribute (N : Node_Id) return Traverse_Result is
+ Attr_Id : Attribute_Id;
+ Aname   : Name_Id;
+ Pref: Node_Id;
+
+  begin
+ if Nkind (N) = N_Attribute_Reference then
+Attr_Id := Get_Attribute_Id (Attribute_Name (N));
+Aname   := Attribute_Name (N);
+
+if Attr_Id = Attribute_Old
+  or else Attr_Id = Attribute_Loop_Entry
+then
+   Pref := Prefix (N);
+
+   if Is_Deep (Etype (Pref)) then
+  if Nkind (Pref) /= N_Function_Call then
+ if Emit_Messages then
+Error_Msg_Name_1 := Aname;
+Error_Msg_N
+  ("prefix of % attribute must be a function call "
+ 

[Ada] Alignment may be specified as zero

[Pierre-Marie de Rodat]

An Alignment clause or an aspect_specification for Alignment may be
specified as 0, which is treated the same as 1.

Tested on x86_64-pc-linux-gnu, committed on trunk

2019-08-14  Bob Duff  

gcc/ada/

* sem_ch13.adb (Get_Alignment_Value): Return 1 for Alignment 0,
and do not give an error.
* doc/gnat_rm/representation_clauses_and_pragmas.rst: Update the
corresponding documentation.
* gnat_rm.texi: Regenerate.

gcc/testsuite/

* gnat.dg/alignment15.adb: New testcase.--- gcc/ada/doc/gnat_rm/representation_clauses_and_pragmas.rst
+++ gcc/ada/doc/gnat_rm/representation_clauses_and_pragmas.rst
@@ -30,9 +30,11 @@ Alignment Clauses
 
 .. index:: Alignment Clause
 
-GNAT requires that all alignment clauses specify a power of 2, and all
-default alignments are always a power of 2.  The default alignment
-values are as follows:
+GNAT requires that all alignment clauses specify 0 or a power of 2, and
+all default alignments are always a power of 2. Specifying 0 is the
+same as specifying 1.
+
+The default alignment values are as follows:
 
 * *Elementary Types*.
 
@@ -610,23 +612,23 @@ alignment of the type (this is true for all types). In some cases the
  end record;
 
 
-On a typical 32-bit architecture, the X component will occupy four bytes 
-and the Y component will occupy one byte, for a total of 5 bytes. As a 
-result ``R'Value_Size`` will be 40 (bits) since this is the minimum size 
-required to store a value of this type. For example, it is permissible 
-to have a component of type R in an array whose component size is 
-specified to be 40 bits. 
-
-However, ``R'Object_Size`` will be 64 (bits). The difference is due to 
-the alignment requirement for objects of the record type. The X 
-component will require four-byte alignment because that is what type 
-Integer requires, whereas the Y component, a Character, will only 
-require 1-byte alignment. Since the alignment required for X is the 
-greatest of all the components' alignments, that is the alignment 
-required for the enclosing record type, i.e., 4 bytes or 32 bits. As 
-indicated above, the actual object size must be rounded up so that it is 
-a multiple of the alignment value. Therefore, 40 bits rounded up to the 
-next multiple of 32 yields 64 bits. 
+On a typical 32-bit architecture, the X component will occupy four bytes
+and the Y component will occupy one byte, for a total of 5 bytes. As a
+result ``R'Value_Size`` will be 40 (bits) since this is the minimum size
+required to store a value of this type. For example, it is permissible
+to have a component of type R in an array whose component size is
+specified to be 40 bits.
+
+However, ``R'Object_Size`` will be 64 (bits). The difference is due to
+the alignment requirement for objects of the record type. The X
+component will require four-byte alignment because that is what type
+Integer requires, whereas the Y component, a Character, will only
+require 1-byte alignment. Since the alignment required for X is the
+greatest of all the components' alignments, that is the alignment
+required for the enclosing record type, i.e., 4 bytes or 32 bits. As
+indicated above, the actual object size must be rounded up so that it is
+a multiple of the alignment value. Therefore, 40 bits rounded up to the
+next multiple of 32 yields 64 bits.
 
 For all other types, the ``Object_Size``
 and ``Value_Size`` are the same (and equivalent to the RM attribute ``Size``).

--- gcc/ada/gnat_rm.texi
+++ gcc/ada/gnat_rm.texi
@@ -21,7 +21,7 @@
 
 @copying
 @quotation
-GNAT Reference Manual , Jul 31, 2019
+GNAT Reference Manual , Aug 01, 2019
 
 AdaCore
 
@@ -18369,9 +18369,11 @@ and this section describes the additional capabilities provided.
 
 @geindex Alignment Clause
 
-GNAT requires that all alignment clauses specify a power of 2, and all
-default alignments are always a power of 2.  The default alignment
-values are as follows:
+GNAT requires that all alignment clauses specify 0 or a power of 2, and
+all default alignments are always a power of 2. Specifying 0 is the
+same as specifying 1.
+
+The default alignment values are as follows:
 
 
 @itemize *

--- gcc/ada/sem_ch13.adb
+++ gcc/ada/sem_ch13.adb
@@ -11509,7 +11509,7 @@ package body Sem_Ch13 is
   if Align = No_Uint then
  return No_Uint;
 
-  elsif Align <= 0 then
+  elsif Align < 0 then
 
  --  This error is suppressed in ASIS mode to allow for different ASIS
  --  back ends or ASIS-based tools to query the illegal clause.
@@ -11520,6 +11520,11 @@ package body Sem_Ch13 is
 
  return No_Uint;
 
+  --  If Alignment is specified to be 0, we treat it the same as 1
+
+  elsif Align = 0 then
+ return Uint_1;
+
   else
  for J in Int range 0 .. 64 loop
 declare

--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/alignment15.adb
@@ -0,0 +1,17 @@
+--  { dg-compile }
+
+procedure Alignment15 is
+   type T0 is record
+  

[Ada] Incorrect error on inline protected function

[Pierre-Marie de Rodat]

This patch fixes a bug where if a protected function has a pragma
Inline, and has no local variables, and the body consists of a single
extended_return_statement, and the result type is an indefinite
composite subtype, and inlining is enabled, the compiler gives an error,
even though the program is legal.

Tested on x86_64-pc-linux-gnu, committed on trunk

2019-08-14  Bob Duff  

gcc/ada/

* inline.adb (Check_And_Split_Unconstrained_Function): Ignore
protected functions to get rid of spurious error. The
transformation done by this procedure triggers legality errors
in the generated code in this case.

gcc/testsuite/

* gnat.dg/inline19.adb, gnat.dg/inline19.ads: New testcase.--- gcc/ada/inline.adb
+++ gcc/ada/inline.adb
@@ -2041,6 +2041,8 @@ package body Inline is
  Original_Body   : Node_Id;
  Body_To_Analyze : Node_Id;
 
+  --  Start of processing for Build_Body_To_Inline
+
   begin
  pragma Assert (Current_Scope = Spec_Id);
 
@@ -2448,6 +2450,18 @@ package body Inline is
   elsif Present (Body_To_Inline (Decl)) then
  return;
 
+  --  Do not generate a body to inline for protected functions, because the
+  --  transformation generates a call to a protected procedure, causing
+  --  spurious errors. We don't inline protected operations anyway, so
+  --  this is no loss. We might as well ignore intrinsics and foreign
+  --  conventions as well -- just allow Ada conventions.
+
+  elsif not (Convention (Spec_Id) = Convention_Ada
+or else Convention (Spec_Id) = Convention_Ada_Pass_By_Copy
+or else Convention (Spec_Id) = Convention_Ada_Pass_By_Reference)
+  then
+ return;
+
   --  Check excluded declarations
 
   elsif Present (Declarations (N))

--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/inline19.adb
@@ -0,0 +1,17 @@
+--  { dg-do compile }
+--  { dg-options "-O2" }
+
+package body Inline19 is
+
+   S : String := "Hello";
+
+   protected body P is
+  function F return String is
+  begin
+ return Result : constant String := S do
+null;
+ end return;
+  end F;
+   end P;
+
+end Inline19;

--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/inline19.ads
@@ -0,0 +1,8 @@
+package Inline19 is
+
+   protected P is
+  function F return String;
+  pragma Inline (F);
+   end P;
+
+end Inline19;

[Ada] Fix spurious ownership error in GNATprove

[Pierre-Marie de Rodat]

Like Is_Path_Expression, function Is_Subpath_Expression should consider
the possibility that the subpath is a type conversion or type
qualification over the actual subpath node. This avoids spurious
ownership errors in GNATprove.

There is no impact on compilation.

Tested on x86_64-pc-linux-gnu, committed on trunk

2019-08-14  Yannick Moy  

gcc/ada/

* sem_spark.adb (Is_Subpath_Expression): Take into account
conversion and qualification.--- gcc/ada/sem_spark.adb
+++ gcc/ada/sem_spark.adb
@@ -4266,6 +4266,12 @@ package body Sem_SPARK is
is
begin
   return Is_Path_Expression (Expr, Is_Traversal)
+
+or else (Nkind_In (Expr, N_Qualified_Expression,
+ N_Type_Conversion,
+ N_Unchecked_Type_Conversion)
+  and then Is_Subpath_Expression (Expression (Expr)))
+
 or else (Nkind (Expr) = N_Attribute_Reference
   and then
 (Get_Attribute_Id (Attribute_Name (Expr)) =
@@ -4276,7 +4282,8 @@ package body Sem_SPARK is
  or else
  Get_Attribute_Id (Attribute_Name (Expr)) =
Attribute_Image))
-   or else Nkind (Expr) = N_Op_Concat;
+
+or else Nkind (Expr) = N_Op_Concat;
end Is_Subpath_Expression;
 
---

[Ada] Warn about unknown condition in Compile_Time_Warning

[Pierre-Marie de Rodat]

The compiler now warns if the condition in a pragma Compile_Time_Warning
or Compile_Time_Error does not have a compile-time-known value. The
warning is not given for pragmas in a generic template, but is given for
pragmas in an instance.

The -gnatw_c and -gnatw_C switches turn the warning on and off. The
default is on.

Tested on x86_64-pc-linux-gnu, committed on trunk

2019-08-14  Bob Duff  

gcc/ada/

* sem_prag.ads, sem_prag.adb
(Process_Compile_Time_Warning_Or_Error): In parameterless
version, improve detection of whether we are in a generic unit
to cover the case of an instance within a generic unit.
(Process_Compile_Time_Warning_Or_Error): Rename the
two-parameter version to be
Validate_Compile_Time_Warning_Or_Error, and do not export it.
Issue a warning if the condition is not known at compile time.
The key point is that the warning must be given only for pragmas
deferred to the back end, because the back end discovers
additional values that are known at compile time.  Previous
changes in this ticket have enabled this by deferring to the
back end without checking for special cases such as 'Size.
(Validate_Compile_Time_Warning_Or_Error): Rename to be
Defer_Compile_Time_Warning_Error_To_BE.
* warnsw.ads, warnsw.adb (Warn_On_Unknown_Compile_Time_Warning):
Add new switches -gnatw_c and -gnatw_C to control the above
warning.
* doc/gnat_ugn/building_executable_programs_with_gnat.rst:
Document new switches.
* gnat_ugn.texi: Regenerate.

gcc/testsuite/

* gnat.dg/warn27.adb: New testcase.

patch.diff.gz
Description: application/gzip

[Ada] Crash on quantified expression in disabled assertion

[Pierre-Marie de Rodat]

The defining identifier of a quantified expression may be the freeze
point of its type.  If the quantified expression appears in an assertion
that is disavbled, the freeze node for that type may appear in a tree
that will be discarded when the enclosing pragma is elaborated. To
ensure that the freeze node is reachable for subsquent uses we must
generate its freeze node explicitly when the quantified expression is
analyzed.

Tested on x86_64-pc-linux-gnu, committed on trunk

2019-08-14  Ed Schonberg  

gcc/ada/

* exp_ch4.adb (Expand_N_Quantified_Expression): Freeze
explicitly the type of the loop parameter.

gcc/testsuite/

* gnat.dg/assert2.adb, gnat.dg/assert2.ads: New testcase.--- gcc/ada/exp_ch4.adb
+++ gcc/ada/exp_ch4.adb
@@ -10337,8 +10337,30 @@ package body Exp_Ch4 is
   Flag  : Entity_Id;
   Scheme: Node_Id;
   Stmts : List_Id;
+  Var   : Entity_Id;
 
begin
+  --  Ensure that the bound variable is properly frozen. We must do
+  --  this before expansion because the expression is about to be
+  --  converted into a loop, and resulting freeze nodes may end up
+  --  in the wrong place in the tree.
+
+  if Present (Iter_Spec) then
+ Var := Defining_Identifier (Iter_Spec);
+  else
+ Var := Defining_Identifier (Loop_Spec);
+  end if;
+
+  declare
+ P : Node_Id := Parent (N);
+  begin
+ while Nkind (P) in N_Subexpr loop
+P := Parent (P);
+ end loop;
+
+ Freeze_Before (P, Etype (Var));
+  end;
+
   --  Create the declaration of the flag which tracks the status of the
   --  quantified expression. Generate:
 

--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/assert2.adb
@@ -0,0 +1,5 @@
+--  { dg-do compile }
+
+package body Assert2 is
+   procedure Dummy is null;
+end Assert2;

--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/assert2.ads
@@ -0,0 +1,15 @@
+package Assert2
+with SPARK_Mode
+is
+   type Living is new Integer;
+   function Is_Martian (Unused : Living) return Boolean is (False);
+
+   function Is_Green (Unused : Living) return Boolean is (True);
+
+   pragma Assert
+ (for all M in Living => (if Is_Martian (M) then Is_Green (M)));
+   pragma Assert
+ (for all M in Living => (if Is_Martian (M) then not Is_Green (M)));
+
+   procedure Dummy;
+end Assert2;

[Ada] Strengthen Locked flag

[Pierre-Marie de Rodat]

This patch strengthens the Locked flag, by Asserting that it is False on
operations that might cause reallocation.

No change in behavior (except in the presence of compiler bugs), so no
test.

Tested on x86_64-pc-linux-gnu, committed on trunk

2019-08-14  Bob Duff  

gcc/ada/

* table.adb: Assert that the table is not locked when increasing
Last, even if it doesn't cause reallocation.  In other words,
assert that on operations that MIGHT cause reallocation.
* table.ads: Fix comment accordingly.--- gcc/ada/table.adb
+++ gcc/ada/table.adb
@@ -80,6 +80,7 @@ package body Table is
 
   procedure Append (New_Val : Table_Component_Type) is
   begin
+ pragma Assert (not Locked);
  Set_Item (Table_Index_Type (Last_Val + 1), New_Val);
   end Append;
 
@@ -120,6 +121,7 @@ package body Table is
 
   procedure Increment_Last is
   begin
+ pragma Assert (not Locked);
  Last_Val := Last_Val + 1;
 
  if Last_Val > Max then
@@ -384,6 +386,8 @@ package body Table is
 
   procedure Set_Last (New_Val : Table_Index_Type) is
   begin
+ pragma Assert (Int (New_Val) <= Last_Val or else not Locked);
+
  if Int (New_Val) < Last_Val then
 Last_Val := Int (New_Val);
 

--- gcc/ada/table.ads
+++ gcc/ada/table.ads
@@ -130,14 +130,15 @@ package Table is
   --  First .. Last.
 
   Locked : Boolean := False;
-  --  Table expansion is permitted only if this switch is set to False. A
-  --  client may set Locked to True, in which case any attempt to expand
-  --  the table will cause an assertion failure. Note that while a table
-  --  is locked, its address in memory remains fixed and unchanging. This
-  --  feature is used to control table expansion during Gigi processing.
-  --  Gigi assumes that tables other than the Uint and Ureal tables do
-  --  not move during processing, which means that they cannot be expanded.
-  --  The Locked flag is used to enforce this restriction.
+  --  Increasing the value of Last is permitted only if this switch is set
+  --  to False. A client may set Locked to True, in which case any attempt
+  --  to increase the value of Last (which might expand the table) will
+  --  cause an assertion failure. Note that while a table is locked, its
+  --  address in memory remains fixed and unchanging. This feature is used
+  --  to control table expansion during Gigi processing.  Gigi assumes that
+  --  tables other than the Uint and Ureal tables do not move during
+  --  processing, which means that they cannot be expanded.  The Locked
+  --  flag is used to enforce this restriction.
 
   procedure Init;
   --  This procedure allocates a new table of size Initial (freeing any