Re: [PATCH] Add --with-diagnostics-urls configuration option and GCC_URLS env var

2019-12-20 Thread 王昊然
I think this is good idea since it is consistent with env var
GCC_COLORS -- the color support will be disabled even with
-fdiagnostics-color=always, if GCC_COLORS is set to empty.
And I has experienced more serious problem when I ssh(1) to the remote
machine from a even older terminal, GNOME Terminal 2.30.2. The
terminal bells made noticeable delays; The whole terminal window would
hang for several seconds when gcc(1) emits too many warnings in at a
time...

2019-12-20 4:48 GMT+08:00, Jakub Jelinek :
> On Thu, Dec 19, 2019 at 03:24:19PM -0500, David Malcolm wrote:
>> Currently -fdiagnostics-urls defaults to "auto" and this works
>> (e.g. for recent gnome-terminal, and is gracefully discarded by
>> konsole5), but there have been reports of incompatibilities of the
>> feature with various other terminals.
>>
>> This patch adds a configuration option to change this default, based
>> on Jakub's analogous change to -fdiagnostics-color (r217540).  One
>> possible configure-time option is --with-diagnostics-urls=auto-if-env,
>> which adds support for a GCC_URLS environment variable to control
>> the default (again by analogy with the --with-diagnostics-color
>> configure-time support for changing -fdiagnostics-color).
>
> I think it would be better to have GCC_URLS env var to be be more
> consistent
> with GCC_COLORS, so yes, have the never,auto,auto-if-env,always
> configure possibilities like for colors and for auto-if-env don't print
> URLS if the env var is not present, but on top of that, parse also the
> value
> of the env var like parse_gcc_colors does, and have a way to disable urls
> even with -fdiagnostics-urls=always (like GCC_COLORS= disables colors),
> and perhaps use the env var to select between the ST and BEL terminator
> as apparently some terminals like one or the other more.
> So perhaps accept GCC_URLS= and GCC_URLS=no as disabling, GCC_URLS=bel
> as the (default) case for BEL termination and GCC_URLS=st for the ST
> termination?
> E.g. have a way even for a compiler configured that it will work with new
> terminals most of them time and thus --with-diagnostics-urls=always that
> if somebody sshs to some machine from some old host, GCC_URLS=no (or none?)
> can be still used to disable it, without the need to tweak build system to
> inject there some flags.
>
>> Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu; I
>> tested the --with-diagnostics-urls=auto-if-env and GCC_URLS behavior
>> manually.
>>
>> Jakub: does this look sane to you?  (given that this is heavily based
>> on your 2014 patches for --with-diagnostics-color).
>
>   Jakub
>
>


[PATCH] libada: Fix shared library installation with `--disable-libada'

2019-12-20 Thread Maciej W. Rozycki
Provide a default value of $(toolexeclibdir) for $(ADA_RTL_DSO_DIR), so 
that in a `--disable-libada' configuration `make install' places shared 
gnatlib libraries, built with `make -C gcc gnatlib-shared', in their 
intended version-specific location, fixing a commit r276424 ("libada: 
Respect `--enable-version-specific-runtime-libs'") regression.

gcc/ada/
* gcc-interface/Makefile.in (toolexeclibdir): New variable.
---
On Fri, 20 Dec 2019, Eric Botcazou wrote:

> >  I have rebuilt GCC with `--disable-libada' and it didn't cause any
> > anomalies I could notice whether `--enable-version-specific-runtime-libs'
> > or `--disable-version-specific-runtime-libs' has been used.  I wouldn't
> > expect any anyway, as shared libgnat and libgnarl libraries are not built
> > in this case, so $(toolexeclibdir) is not supposed to be used.
> 
> Yes, shared libraries are built with "make -C gcc gnatlib-shared gnattools".

 Oops, I think it was missed in the original review.

 Fixed thus, and verified with and without `--disable-libada', ensuring 
that shared libgnat and libgnarl libraries arrive at their intended places 
upon `make install'.

 OK to apply?

  Maciej
---
 gcc/ada/gcc-interface/Makefile.in |6 ++
 1 file changed, 6 insertions(+)

gcc-ada-toolexeclibdir.diff
Index: gcc/gcc/ada/gcc-interface/Makefile.in
===
--- gcc.orig/gcc/ada/gcc-interface/Makefile.in
+++ gcc/gcc/ada/gcc-interface/Makefile.in
@@ -880,6 +880,12 @@ b_gnatm.o : b_gnatm.adb
$(CC) -c $(ALL_ADAFLAGS) $(ADA_INCLUDES) -gnatws -gnatyN \
$< $(OUTPUT_OPTION)
 
+# Provide a `toolexeclibdir' definition for when `gnat-install-lib' is
+# wired through gcc/ in a configuration with top-level libada disabled.
+# It will be overriden with the value configured when `gnat-install-lib'
+# is invoked through libada/.
+toolexeclibdir = $(ADA_RTL_OBJ_DIR)
+
 ADA_INCLUDE_DIR = $(libsubdir)/adainclude
 ADA_RTL_OBJ_DIR = $(libsubdir)/adalib
 ADA_RTL_DSO_DIR = $(toolexeclibdir)


Re: [patch] allow $ in scan-tree-dump expressions matching symbol names

2019-12-20 Thread Mike Stump
On Dec 20, 2019, at 8:13 AM, Olivier Hainque  wrote:
> 
> This change adjusts a few scan-tree-dump expressions
> to allow '$' as well as '.' when matching symbol names,
> 
> Ok to commit ?

Ok.



Re: [patch] Prevent redefinition of WCHAR_MAX from testsuite/gcc.dg/cpp/ucs.c

2019-12-20 Thread Mike Stump
On Dec 20, 2019, at 9:27 AM, Olivier Hainque  wrote:
> gcc/testsuite/gcc.dg/cpp/ucs.c #include 
> and then crafts a definition of WCHAR_MAX depending
> on __WCHAR_TYPE__.

> Ok to commit ?

Ok.



Re: undefine OFFSET in testsuite/gcc.dg/vect/tree-vect.h

2019-12-20 Thread Mike Stump
On Dec 20, 2019, at 10:11 AM, Olivier Hainque  wrote:
> 
> The attached patch is a proposal for a basic solution
> to an issue which might be an improper thing done by a
> system header on VxWorks, but which is a big pain to fix
> at this level and very simple to address super locally.

> Is this OK to commit ?

Ok, but I will comment it would be much better to fix includes the header to be 
namespace clean, longer run.  I know why that probably won't work, but I'll 
mention it anyway.  If fixincluding the header works better than I expect, 
please do that fix instead.

Re: [PING][PATCH v2 2/2] testsuite: Fix run-time tracking down of `libgcc_s'

2019-12-20 Thread Mike Stump
On Dec 9, 2019, at 1:30 PM, Maciej W. Rozycki  wrote:
> 
> On Fri, 29 Nov 2019, Maciej W. Rozycki wrote:
> 
>> Fix a catastrophic libgo testsuite failure in cross-compilation where 
>> the shared `libgcc_s' library cannot be found by the loader at run time 
>> in build-tree testing and consequently all test cases fail the execution 
>> stage, giving output (here with the `x86_64-linux-gnu' host and the 
>> `riscv64-linux-gnu' target, with RISC-V QEMU in the Linux user emulation 
>> mode as the target board) like:
>> 
>> spawn qemu-riscv64 -E 
>> LD_LIBRARY_PATH=.:.../riscv64-linux-gnu/lib64/lp64d/libgo/.libs ./a.exe
>> ./a.exe: error while loading shared libraries: libgcc_s.so.1: cannot open 
>> shared object file: No such file or directory
>> FAIL: archive/tar
> 
> Ping for:
> 
> 

Ok.

Watch for any breakage.

Re: [PING^4][PATCH 0/4] Fix library testsuite compilation for build sysroot

2019-12-20 Thread Mike Stump
On Dec 16, 2019, at 4:06 PM, Maciej W. Rozycki  wrote:
> 
> On Mon, 11 Nov 2019, Maciej W. Rozycki wrote:
> 
>> This patch series addresses a problem with the testsuite compiler being 
>> set up across libatomic, libffi, libgo, libgomp with no correlation 
>> whatsoever to the target compiler being used in GCC compilation.  
>> Consequently there in no arrangement made to set up the compilation 
>> sysroot according to the build sysroot specified for GCC compilation, 
>> causing a catastrophic failure across the testsuites affected from the 
>> inability to link executables.
> 
> Ping for:
> 
> 
> 
> 

Hum...  I'm wondering who should review this...  Feels like I should, the 
problem is it intertwines with the build system as well.   So, let me approve 
the testsuite parts so that can clear the way for someone else to approve the 
remaining bits (if not obvious).

Please do watch out for breakages as it goes in.  Thanks.


[PATCH] V11 patch #15 of 15, Add tests for -mcpu=future vec_extract from memory with a large offset

2019-12-20 Thread Michael Meissner
These are new tests.  They verify if you are doing a vec_extract of a vector in
memory and the vector's address contains a large offset and the element number
is constant, it generates a prefixed load instruction when -mcpu=future.

Once all of the other V11 patches are checked in, can I check this patch into
the trunk?

2019-12-20  Michael Meissner  

* gcc.target/powerpc/vec-extract-large-si.c: New test for
vec_extract from a vector unsigned int in memory with a large
offset.
* gcc.target/powerpc/vec-extract-large-di.c: New test for
vec_extract from a vector long in memory with a large offset.
* gcc.target/powerpc/vec-extract-large-sf.c: New test for
vec_extract from a vector float in memory with a large offset.
* gcc.target/powerpc/vec-extract-large-df.c: New test for
vec_extract from a vector double in memory with a large offset.

Index: gcc/testsuite/gcc.target/powerpc/vec-extract-large-df.c
===
--- gcc/testsuite/gcc.target/powerpc/vec-extract-large-df.c (revision 
279691)
+++ gcc/testsuite/gcc.target/powerpc/vec-extract-large-df.c (working copy)
@@ -0,0 +1,30 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_prefixed_addr } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* Test if we generate prefixed loads for vec_extract of a vector double in
+   memory, and the memory address has a large offset.  */
+
+#include 
+
+#ifndef TYPE
+#define TYPE double
+#endif
+
+#ifndef LARGE
+#define LARGE 0x5
+#endif
+
+TYPE
+get0 (vector TYPE *p)
+{
+  return vec_extract (p[LARGE], 0);/* PLFD.  */
+}
+
+TYPE
+get1 (vector TYPE *p)
+{
+  return vec_extract (p[LARGE], 1);/* PLFD.  */
+}
+
+/* { dg-final { scan-assembler-times {\mplfd\M}  2 } } */
Index: gcc/testsuite/gcc.target/powerpc/vec-extract-large-di.c
===
--- gcc/testsuite/gcc.target/powerpc/vec-extract-large-di.c (revision 
279691)
+++ gcc/testsuite/gcc.target/powerpc/vec-extract-large-di.c (working copy)
@@ -0,0 +1,30 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_prefixed_addr } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* Test if we generate prefixed loads for vec_extract of a vector unsigned long
+   in memory, and the memory address has a large offset.  */
+
+#include 
+
+#ifndef TYPE
+#define TYPE unsigned long
+#endif
+
+#ifndef LARGE
+#define LARGE 0x5
+#endif
+
+TYPE
+get0 (vector TYPE *p)
+{
+  return vec_extract (p[LARGE], 0);/* PLD.  */
+}
+
+TYPE
+get1 (vector TYPE *p)
+{
+  return vec_extract (p[LARGE], 1);/* PLD.  */
+}
+
+/* { dg-final { scan-assembler-times {\mpld\M}  2 } } */
Index: gcc/testsuite/gcc.target/powerpc/vec-extract-large-sf.c
===
--- gcc/testsuite/gcc.target/powerpc/vec-extract-large-sf.c (revision 
279691)
+++ gcc/testsuite/gcc.target/powerpc/vec-extract-large-sf.c (working copy)
@@ -0,0 +1,30 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_prefixed_addr } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* Test if we generate prefixed loads for vec_extract of a vector float in
+   memory, and the memory address has a large offset.  */
+
+#include 
+
+#ifndef TYPE
+#define TYPE float
+#endif
+
+#ifndef LARGE
+#define LARGE 0x5
+#endif
+
+TYPE
+get0 (vector TYPE *p)
+{
+  return vec_extract (p[LARGE], 0);/* PLFS.  */
+}
+
+TYPE
+get1 (vector TYPE *p)
+{
+  return vec_extract (p[LARGE], 1);/* PLFS.  */
+}
+
+/* { dg-final { scan-assembler-times {\mplfs\M}  2 } } */
Index: gcc/testsuite/gcc.target/powerpc/vec-extract-large-si.c
===
--- gcc/testsuite/gcc.target/powerpc/vec-extract-large-si.c (revision 
279691)
+++ gcc/testsuite/gcc.target/powerpc/vec-extract-large-si.c (working copy)
@@ -0,0 +1,30 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_prefixed_addr } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* Test if we generate prefixed loads for vec_extract of a vector unsigned int
+   in memory, and the memory address has a large offset.  */
+
+#include 
+
+#ifndef TYPE
+#define TYPE unsigned int
+#endif
+
+#ifndef LARGE
+#define LARGE 0x5
+#endif
+
+TYPE
+get0 (vector TYPE *p)
+{
+  return vec_extract (p[LARGE], 0);/* PLWZ.  */
+}
+
+TYPE
+get1 (vector TYPE *p)
+{
+  return vec_extract (p[LARGE], 1);/* PLWZ.  */
+}
+
+/* { dg-final { scan-assembler-times {\mplwz\M}  2 } } */

-- 
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] V11 patch #14 of 15, Add tests for vec_extract from memory with PC-relative addrss

2019-12-20 Thread Michael Meissner
These tests are new.  These tests check that the vector extract from a vector
in memory works correctly for both constant and variable element numbers.

These tests pass with all of the previoius pataches applied.  Can I check these
patches into the trunk?

2019-12-20  Michael Meissner  

* gcc.target/powerpc/vec-extract-pcrel-si.c: New test for
vec_extract from a PC-relative address.
* gcc.target/powerpc/vec-extract-pcrel-di.c: New test for
vec_extract from a PC-relative address.
* gcc.target/powerpc/vec-extract-pcrel-sf.c: New test for
vec_extract from a PC-relative address.
* gcc.target/powerpc/vec-extract-pcrel-df.c: New test for
vec_extract from a PC-relative address.

Index: gcc/testsuite/gcc.target/powerpc/vec-extract-pcrel-df.c
===
--- gcc/testsuite/gcc.target/powerpc/vec-extract-pcrel-df.c (revision 
279615)
+++ gcc/testsuite/gcc.target/powerpc/vec-extract-pcrel-df.c (working copy)
@@ -0,0 +1,37 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_pcrel } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* Test if we can support vec_extract on V2DF vectors with a PC-relative
+   address.  */
+
+#include 
+
+#ifndef TYPE
+#define TYPE double
+#endif
+
+static vector TYPE v;
+vector TYPE *p = 
+
+TYPE
+get0 (void)
+{
+  return vec_extract (v, 0);
+}
+
+TYPE
+get1 (void)
+{
+  return vec_extract (v, 1);
+}
+
+TYPE
+getn (unsigned long n)
+{
+  return vec_extract (v, n);
+}
+
+/* { dg-final { scan-assembler-times {[@]pcrel}  3 } } */
+/* { dg-final { scan-assembler-times {\mplfd\M}  2 } } */
+/* { dg-final { scan-assembler-times {\mpla\M}   1 } } */
Index: gcc/testsuite/gcc.target/powerpc/vec-extract-pcrel-di.c
===
--- gcc/testsuite/gcc.target/powerpc/vec-extract-pcrel-di.c (revision 
279615)
+++ gcc/testsuite/gcc.target/powerpc/vec-extract-pcrel-di.c (working copy)
@@ -0,0 +1,37 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_pcrel } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* Test if we can support vec_extract on V2DI vectors with a PC-relative
+   address.  */
+
+#include 
+
+#ifndef TYPE
+#define TYPE unsigned long
+#endif
+
+static vector TYPE v;
+vector TYPE *p = 
+
+TYPE
+get0 (void)
+{
+  return vec_extract (v, 0);
+}
+
+TYPE
+get1 (void)
+{
+  return vec_extract (v, 1);
+}
+
+TYPE
+getn (unsigned long n)
+{
+  return vec_extract (v, n);
+}
+
+/* { dg-final { scan-assembler-times {[@]pcrel}  3 } } */
+/* { dg-final { scan-assembler-times {\mpld\M}   2 } } */
+/* { dg-final { scan-assembler-times {\mpla\M}   1 } } */
Index: gcc/testsuite/gcc.target/powerpc/vec-extract-pcrel-sf.c
===
--- gcc/testsuite/gcc.target/powerpc/vec-extract-pcrel-sf.c (revision 
279615)
+++ gcc/testsuite/gcc.target/powerpc/vec-extract-pcrel-sf.c (working copy)
@@ -0,0 +1,37 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_pcrel } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* Test if we can support vec_extract on V4SF vectors with a PC-relative
+   address.  */
+
+#include 
+
+#ifndef TYPE
+#define TYPE float
+#endif
+
+static vector TYPE v;
+vector TYPE *p = 
+
+TYPE
+get0 (void)
+{
+  return vec_extract (v, 0);
+}
+
+TYPE
+get1 (void)
+{
+  return vec_extract (v, 1);
+}
+
+TYPE
+getn (unsigned long n)
+{
+  return vec_extract (v, n);
+}
+
+/* { dg-final { scan-assembler-times {[@]pcrel}  3 } } */
+/* { dg-final { scan-assembler-times {\mplfs\M}  2 } } */
+/* { dg-final { scan-assembler-times {\mpla\M}   1 } } */
Index: gcc/testsuite/gcc.target/powerpc/vec-extract-pcrel-si.c
===
--- gcc/testsuite/gcc.target/powerpc/vec-extract-pcrel-si.c (revision 
279615)
+++ gcc/testsuite/gcc.target/powerpc/vec-extract-pcrel-si.c (working copy)
@@ -0,0 +1,37 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_pcrel } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* Test if we can support vec_extract on V4SI vectors with a PC-relative
+   address.  */
+
+#include 
+
+#ifndef TYPE
+#define TYPE unsigned int
+#endif
+
+static vector TYPE v;
+vector TYPE *p = 
+
+TYPE
+get0 (void)
+{
+  return vec_extract (v, 0);
+}
+
+TYPE
+get1 (void)
+{
+  return vec_extract (v, 1);
+}
+
+TYPE
+getn (unsigned long n)
+{
+  return vec_extract (v, n);
+}
+
+/* { dg-final { scan-assembler-times {[@]pcrel}  3 } } */
+/* { dg-final { scan-assembler-times {\mplwz\M}  2 } } */
+/* { dg-final { scan-assembler-times {\mpla\M}   1 } } */

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


[PATCH] V11 patch #13 of 15, Add test for -mcpu=future -fstack-protect-strong with large stacks

2019-12-20 Thread Michael Meissner
This is patch V8 #6.  It makes sure the stack protect insns work when
-mcpu=future and -fstack-protector-strong are used together.  We discovered
this failure when we attempted to build GLIBC using -mcpu=future.
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00089.html

This test now passes when I run it as part of the test suite, can I check it
in to the trunk?

2019-12-20  Michael Meissner  

* gcc.target/powerpc/prefix-stack-protect.c: New test to make sure
-fstack-protect-strong works with prefixed addressing.

Index: gcc/testsuite/gcc.target/powerpc/prefix-stack-protect.c
===
--- gcc/testsuite/gcc.target/powerpc/prefix-stack-protect.c (revision 
279324)
+++ gcc/testsuite/gcc.target/powerpc/prefix-stack-protect.c (working copy)
@@ -0,0 +1,20 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_prefixed_addr } */
+/* { dg-options "-O2 -mdejagnu-cpu=future -fstack-protector-strong" } */
+
+/* Test that we can handle large stack frames with -fstack-protector-strong and
+   prefixed addressing.  This was originally discovered in trying to build
+   glibc with -mcpu=future, and vfwprintf.c failed because it used
+   -fstack-protector-strong.  */
+
+extern long foo (char *);
+
+long
+bar (void)
+{
+  char buffer[0x2];
+  return foo (buffer) + 1;
+}
+
+/* { dg-final { scan-assembler {\mpld\M}  } } */
+/* { dg-final { scan-assembler {\mpstd\M} } } */

-- 
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] analyzer: ensure .dot output is valid for an empty BB

2019-12-20 Thread David Malcolm
This patch fixes an issue with the output of -fdump-analyzer-supergraph
on BBs with no statements, where the resulting files were unreadable by
dot e.g.:

Error: syntax error in line 1
...  ...
in label of node node_10

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to the dmalcolm/analyzer branch on the GCC git mirror.

gcc/analyzer/ChangeLog:
* supergraph.cc (supernode::dump_dot): Ensure that the TABLE
element has at least one TR.

gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/dot-output.c: Add test coverage for a BB with
no statements.
---
 gcc/analyzer/supergraph.cc | 16 
 gcc/testsuite/gcc.dg/analyzer/dot-output.c | 16 
 2 files changed, 32 insertions(+)

diff --git a/gcc/analyzer/supergraph.cc b/gcc/analyzer/supergraph.cc
index ba7f7c6d2994..dc20a0234cb6 100644
--- a/gcc/analyzer/supergraph.cc
+++ b/gcc/analyzer/supergraph.cc
@@ -444,6 +444,8 @@ supernode::dump_dot (graphviz_out *gv, const dump_args_t 
) const
   pp_string (pp, "");
   pp_write_text_to_stream (pp);
 
+  bool had_row = false;
+
   if (m_returning_call)
 {
   gv->begin_tr ();
@@ -458,18 +460,22 @@ supernode::dump_dot (graphviz_out *gv, const dump_args_t 
) const
   if (args.m_node_annotator)
args.m_node_annotator->add_stmt_annotations (gv, m_returning_call);
   pp_newline (pp);
+
+  had_row = true;
 }
 
   if (entry_p ())
 {
   pp_string (pp, "ENTRY");
   pp_newline (pp);
+  had_row = true;
 }
 
   if (return_p ())
 {
   pp_string (pp, "EXIT");
   pp_newline (pp);
+  had_row = true;
 }
 
   /* Phi nodes.  */
@@ -486,6 +492,7 @@ supernode::dump_dot (graphviz_out *gv, const dump_args_t 
) const
args.m_node_annotator->add_stmt_annotations (gv, stmt);
 
   pp_newline (pp);
+  had_row = true;
 }
 
   /* Statements.  */
@@ -502,6 +509,15 @@ supernode::dump_dot (graphviz_out *gv, const dump_args_t 
) const
args.m_node_annotator->add_stmt_annotations (gv, stmt);
 
   pp_newline (pp);
+  had_row = true;
+}
+
+  /* Graphviz requires a TABLE element to have at least one TR
+ (and each TR to have at least one TD).  */
+  if (!had_row)
+{
+  pp_string (pp, "(empty)");
+  pp_newline (pp);
 }
 
   pp_string (pp, ">];\n\n");
diff --git a/gcc/testsuite/gcc.dg/analyzer/dot-output.c 
b/gcc/testsuite/gcc.dg/analyzer/dot-output.c
index 586e14421e0e..25cb31f2d894 100644
--- a/gcc/testsuite/gcc.dg/analyzer/dot-output.c
+++ b/gcc/testsuite/gcc.dg/analyzer/dot-output.c
@@ -27,6 +27,22 @@ int *test (int *buf, int n, int *out)
   return result;
 }
 
+/* Test that we can generate valid .dot files given a BB with no
+   statements.  */
+extern int func ();
+int test_2 (void)
+{
+  int c1;
+  do
+{
+  c1 = func ();
+  if (c1 == '\0')
+   break;
+}
+  while (c1);
+  return c1;
+}
+
 /* { dg-final { dg-check-dot "dot-output.c.callgraph.dot" } } */
 /* { dg-final { dg-check-dot "dot-output.c.eg.dot" } } */
 /* { dg-final { dg-check-dot "dot-output.c.state-purge.dot" } } */
-- 
2.21.0



[PATCH] V11 patch #12 of 15, Add new PC-relative tests for -mcpu=future

2019-12-20 Thread Michael Meissner
This is a reworking of patch V8 #5.  It adds a bunch of PC-relative tests for
the -mcpu=future target.
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00085.html

This test passes when I run it.  Can I check it in?

2019-12-20  Michael Meissner  

* gcc.target/powerpc/prefix-pcrel.h: New set of tests to test
prefixed addressing on 'future' system with PC-relative addresses
for various types.
* gcc.target/powerpc/prefix-pcrel-dd.c: New test for prefixed
loads/stores with PC-relative addresses for the _Decimal64 type.
* gcc.target/powerpc/prefix-pcrel-df.c: New test for prefixed
loads/stores with PC-relative addresses for the double type.
* gcc.target/powerpc/prefix-pcrel-di.c: New test for prefixed
loads/stores with PC-relative addresses for the long type.
* gcc.target/powerpc/prefix-pcrel-hi.c: New test for prefixed
loads/stores with PC-relative addresses for the short type.
* gcc.target/powerpc/prefix-pcrel-kf.c: New test for prefixed
loads/stores with PC-relative addresses for the __float128 type.
* gcc.target/powerpc/prefix-pcrel-qi.c: New test for prefixed
loads/stores with PC-relative addresses for the signed char type.
* gcc.target/powerpc/prefix-pcrel-sd.c: New test for prefixed
loads/stores with PC-relative addresses for the _Decimal32 type.
* gcc.target/powerpc/prefix-pcrel-sf.c: New test for prefixed
loads/stores with PC-relative addresses for the float type.
* gcc.target/powerpc/prefix-pcrel-si.c: New test for prefixed
loads/stores with PC-relative addresses for the int type.
* gcc.target/powerpc/prefix-pcrel-udi.c: New test for prefixed
loads/stores with PC-relative addresses for the unsigned long
type.
* gcc.target/powerpc/prefix-pcrel-uhi.c: New test for prefixed
loads/stores with PC-relative addresses for the unsigned short
type.
* gcc.target/powerpc/prefix-pcrel-uqi.c: New test for prefixed
loads/stores with PC-relative addresses for the unsigned char
type.
* gcc.target/powerpc/prefix-pcrel-usi.c: New test for prefixed
loads/stores with PC-relative addresses for the unsigned int
type.
* gcc.target/powerpc/prefix-pcrel-v2df.c: New test for prefixed
loads/stores with PC-relative addresses for the vector double
type.

Index: gcc/testsuite/gcc.target/powerpc/prefix-pcrel.h
===
--- gcc/testsuite/gcc.target/powerpc/prefix-pcrel.h (revision 279322)
+++ gcc/testsuite/gcc.target/powerpc/prefix-pcrel.h (working copy)
@@ -0,0 +1,58 @@
+/* Common tests for prefixed instructions testing whether pc-relative prefixed
+   instructions are generated for each type.  */
+
+typedef signed charschar;
+typedef unsigned char  uchar;
+typedef unsigned short ushort;
+typedef unsigned int   uint;
+typedef unsigned long  ulong;
+typedef long doubleldouble;
+typedef vector double  v2df;
+typedef vector longv2di;
+typedef vector float   v4sf;
+typedef vector int v4si;
+
+#ifndef TYPE
+#define TYPE ulong
+#endif
+
+#ifndef ITYPE
+#define ITYPE TYPE
+#endif
+
+#ifndef OTYPE
+#define OTYPE TYPE
+#endif
+
+static TYPE a;
+TYPE *p = 
+
+#if !defined(DO_ADD) && !defined(DO_VALUE) && !defined(DO_SET)
+#define DO_ADD 1
+#define DO_VALUE   1
+#define DO_SET 1
+#endif
+
+#if DO_ADD
+void
+add (TYPE b)
+{
+  a += b;
+}
+#endif
+
+#if DO_VALUE
+OTYPE
+value (void)
+{
+  return (OTYPE)a;
+}
+#endif
+
+#if DO_SET
+void
+set (ITYPE b)
+{
+  a = (TYPE)b;
+}
+#endif
Index: gcc/testsuite/gcc.target/powerpc/prefix-pcrel-dd.c
===
--- gcc/testsuite/gcc.target/powerpc/prefix-pcrel-dd.c  (revision 279322)
+++ gcc/testsuite/gcc.target/powerpc/prefix-pcrel-dd.c  (working copy)
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_pcrel } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* Tests for prefixed instructions testing whether pc-relative prefixed
+   instructions are generated for the _Decimal64 type.  */
+
+#define TYPE _Decimal64
+
+#include "prefix-pcrel.h"
+
+/* { dg-final { scan-assembler-times {[@]pcrel}  4 } } */
+/* { 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 279322)
+++ gcc/testsuite/gcc.target/powerpc/prefix-pcrel-df.c  (working copy)
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_pcrel } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* Tests for prefixed instructions testing whether pc-relative prefixed
+   instructions are generated 

[PATCH] V11 patch #11 of 15, Add new tests for generating prefixed loads/stores on -mcpu=future with large offsets

2019-12-20 Thread Michael Meissner
This is a reworking of the tests I submitted previously in V8 #4.  It generates
a bunch of loads and stores for various types using large addresses, and
verifies that the number of prefixed loads and stores is correct.
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00084.html

This patch works when I run the testsuite.  Can I check it in?

2019-12-20  Michael Meissner  

* gcc.target/powerpc/prefix-large.h: New set of tests to test
prefixed addressing on 'future' system with large numeric offsets
for various types.
* gcc.target/powerpc/prefix-large-dd.c: New test for prefixed
loads/stores with large offsets for the _Decimal64 type.
* gcc.target/powerpc/prefix-large-df.c: New test for prefixed
loads/stores with large offsets for the double type.
* gcc.target/powerpc/prefix-large-di.c: New test for prefixed
loads/stores with large offsets for the long type.
* gcc.target/powerpc/prefix-large-hi.c: New test for prefixed
loads/stores with large offsets for the short type.
* gcc.target/powerpc/prefix-large-kf.c: New test for prefixed
loads/stores with large offsets for the __float128 type.
* gcc.target/powerpc/prefix-large-qi.c: New test for prefixed
loads/stores with large offsets for the signed char type.
* gcc.target/powerpc/prefix-large-sd.c: New test for prefixed
loads/stores with large offsets for the _Decimal32 type.
* gcc.target/powerpc/prefix-large-sf.c: New test for prefixed
loads/stores with large offsets for the float type.
* gcc.target/powerpc/prefix-large-si.c: New test for prefixed
loads/stores with large offsets for the int type.
* gcc.target/powerpc/prefix-large-udi.c: New test for prefixed
loads/stores with large offsets for the unsigned long type.
* gcc.target/powerpc/prefix-large-uhi.c: New test for prefixed
loads/stores with large offsets for the unsigned short type.
* gcc.target/powerpc/prefix-large-uqi.c: New test for prefixed
loads/stores with large offsets for the unsigned char type.
* gcc.target/powerpc/prefix-large-usi.c: New test for prefixed
loads/stores with large offsets for the unsigned int type.
* gcc.target/powerpc/prefix-large-v2df.c: New test for prefixed
loads/stores with large offsets for the vector double type.

Index: gcc/testsuite/gcc.target/powerpc/prefix-large.h
===
--- gcc/testsuite/gcc.target/powerpc/prefix-large.h (revision 279319)
+++ gcc/testsuite/gcc.target/powerpc/prefix-large.h (working copy)
@@ -0,0 +1,59 @@
+/* Common tests for prefixed instructions testing whether we can generate a
+   34-bit offset using 1 instruction.  */
+
+typedef signed charschar;
+typedef unsigned char  uchar;
+typedef unsigned short ushort;
+typedef unsigned int   uint;
+typedef unsigned long  ulong;
+typedef long doubleldouble;
+typedef vector double  v2df;
+typedef vector longv2di;
+typedef vector float   v4sf;
+typedef vector int v4si;
+
+#ifndef TYPE
+#define TYPE ulong
+#endif
+
+#ifndef ITYPE
+#define ITYPE TYPE
+#endif
+
+#ifndef OTYPE
+#define OTYPE TYPE
+#endif
+
+#if !defined(DO_ADD) && !defined(DO_VALUE) && !defined(DO_SET)
+#define DO_ADD 1
+#define DO_VALUE   1
+#define DO_SET 1
+#endif
+
+#ifndef CONSTANT
+#define CONSTANT   0x123450UL
+#endif
+
+#if DO_ADD
+void
+add (TYPE *p, TYPE a)
+{
+  p[CONSTANT] += a;
+}
+#endif
+
+#if DO_VALUE
+OTYPE
+value (TYPE *p)
+{
+  return p[CONSTANT];
+}
+#endif
+
+#if DO_SET
+void
+set (TYPE *p, ITYPE a)
+{
+  p[CONSTANT] = a;
+}
+#endif
Index: gcc/testsuite/gcc.target/powerpc/prefix-large-dd.c
===
--- gcc/testsuite/gcc.target/powerpc/prefix-large-dd.c  (revision 279319)
+++ gcc/testsuite/gcc.target/powerpc/prefix-large-dd.c  (working copy)
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_prefixed_addr } */
+/* { 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 for _Decimal64 objects.  */
+
+#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 279319)
+++ gcc/testsuite/gcc.target/powerpc/prefix-large-df.c  (working copy)
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_prefixed_addr } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* Tests for prefixed instructions testing whether we can generate a prefixed
+   

[PATCH] V11 patch #10 of 15, Make sure we don't generate pre-modify prefixed insns with -mcpu=future

2019-12-20 Thread Michael Meissner
This is V10 patch #12.  It adds a test to make sure we don't generate a
prefixed instruction with PRE_INC, PRE_DEC, or PRE_MODIFY.
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00846.html

This test passes when I run it.  Can I check this into the trunk?

2019-12-20  Michael Meissner  

* gcc.target/powerpc/prefix-no-premodify.c: Make sure we do not
generate the non-existent PLWZU instruction if -mcpu=future.

Index: gcc/testsuite/gcc.target/powerpc/prefix-no-premodify.c
===
--- gcc/testsuite/gcc.target/powerpc/prefix-no-premodify.c  (revision 
279259)
+++ gcc/testsuite/gcc.target/powerpc/prefix-no-premodify.c  (working copy)
@@ -0,0 +1,50 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_prefixed_addr } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* Make sure that we don't generate a prefixed form of the load and store with
+   update instructions (i.e. instead of generating LWZU we have to generate
+   PLWZ plus a PADDI).  */
+
+#ifndef SIZE
+#define SIZE 5
+#endif
+
+struct foo {
+  unsigned int field;
+  char pad[SIZE];
+};
+
+struct foo *inc_load (struct foo *p, unsigned int *q)
+{
+  *q = (++p)->field;   /* PLWZ, PADDI, STW.  */
+  return p;
+}
+
+struct foo *dec_load (struct foo *p, unsigned int *q)
+{
+  *q = (--p)->field;   /* PLWZ, PADDI, STW.  */
+  return p;
+}
+
+struct foo *inc_store (struct foo *p, unsigned int *q)
+{
+  (++p)->field = *q;   /* LWZ, PADDI, PSTW.  */
+  return p;
+}
+
+struct foo *dec_store (struct foo *p, unsigned int *q)
+{
+  (--p)->field = *q;   /* LWZ, PADDI, PSTW.  */
+  return p;
+}
+
+/* { dg-final { scan-assembler-times {\mlwz\M}2 } } */
+/* { dg-final { scan-assembler-times {\mstw\M}2 } } */
+/* { dg-final { scan-assembler-times {\mpaddi\M}  4 } } */
+/* { dg-final { scan-assembler-times {\mplwz\M}   2 } } */
+/* { dg-final { scan-assembler-times {\mpstw\M}   2 } } */
+/* { dg-final { scan-assembler-not   {\mplwzu\M}} } */
+/* { dg-final { scan-assembler-not   {\mpstwu\M}} } */
+/* { dg-final { scan-assembler-not   {\maddis\M}} } */
+/* { dg-final { scan-assembler-not   {\maddi\M} } } */

-- 
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: [C++ PATCH] Avoid weird inform without previos error during SFINAE (PR c++/92965)

2019-12-20 Thread Jakub Jelinek
On Fri, Dec 20, 2019 at 06:18:04PM -0500, Jason Merrill wrote:
> > BTW, is the testcase valid in C++17 mode?  GCC 7/8/9/trunk accept it,
> > but clang++ rejects it.
> 
> No, non-template parameters of class types are a C++20 feature.

Trunk accepts it since r276248 aka PR91923 in -std=c++17 mode.

Jakub



[PATCH] V11 patch #9 of 15, Add test to validate generating prefixed memory when the offset is invalid for DS/DQ insns

2019-12-20 Thread Michael Meissner
This is V10 patch #11.  This adds a new test to validate that for -mcpu=future,
we generate a prefixed load/store if the offset would have been illegal for a
non-prefixed DS or DQ instruction.
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00845.html

This test passes when I run the testsuite.  Can I check it in?

2019-12-20  Michael Meissner  

* gcc.target/powerpc/prefix-ds-dq.c: New test to verify that we
generate the prefix load/store instructions for traditional
instructions with an offset that doesn't match DS/DQ
requirements.

Index: gcc/testsuite/gcc.target/powerpc/prefix-ds-dq.c
===
--- gcc/testsuite/gcc.target/powerpc/prefix-ds-dq.c (revision 279256)
+++ gcc/testsuite/gcc.target/powerpc/prefix-ds-dq.c (working copy)
@@ -0,0 +1,156 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_prefixed_addr } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* Tests whether we generate a prefixed load/store operation for addresses that
+   don't meet DS/DQ offset constraints.  */
+
+unsigned long
+load_uc_offset1 (unsigned char *p)
+{
+  return p[1]; /* should generate LBZ.  */
+}
+
+long
+load_sc_offset1 (signed char *p)
+{
+  return p[1]; /* should generate LBZ + EXTSB.  */
+}
+
+unsigned long
+load_us_offset1 (unsigned char *p)
+{
+  return *(unsigned short *)(p + 1);   /* should generate LHZ.  */
+}
+
+long
+load_ss_offset1 (unsigned char *p)
+{
+  return *(short *)(p + 1);/* should generate LHA.  */
+}
+
+unsigned long
+load_ui_offset1 (unsigned char *p)
+{
+  return *(unsigned int *)(p + 1); /* should generate LWZ.  */
+}
+
+long
+load_si_offset1 (unsigned char *p)
+{
+  return *(int *)(p + 1);  /* should generate PLWA.  */
+}
+
+unsigned long
+load_ul_offset1 (unsigned char *p)
+{
+  return *(unsigned long *)(p + 1);/* should generate PLD.  */
+}
+
+long
+load_sl_offset1 (unsigned char *p)
+{
+  return *(long *)(p + 1); /* should generate PLD.  */
+}
+
+float
+load_float_offset1 (unsigned char *p)
+{
+  return *(float *)(p + 1);/* should generate LFS.  */
+}
+
+double
+load_double_offset1 (unsigned char *p)
+{
+  return *(double *)(p + 1);   /* should generate LFD.  */
+}
+
+__float128
+load_float128_offset1 (unsigned char *p)
+{
+  return *(__float128 *)(p + 1);   /* should generate PLXV.  */
+}
+
+void
+store_uc_offset1 (unsigned char uc, unsigned char *p)
+{
+  p[1] = uc;   /* should generate STB.  */
+}
+
+void
+store_sc_offset1 (signed char sc, signed char *p)
+{
+  p[1] = sc;   /* should generate STB.  */
+}
+
+void
+store_us_offset1 (unsigned short us, unsigned char *p)
+{
+  *(unsigned short *)(p + 1) = us; /* should generate STH.  */
+}
+
+void
+store_ss_offset1 (signed short ss, unsigned char *p)
+{
+  *(signed short *)(p + 1) = ss;   /* should generate STH.  */
+}
+
+void
+store_ui_offset1 (unsigned int ui, unsigned char *p)
+{
+  *(unsigned int *)(p + 1) = ui;   /* should generate STW.  */
+}
+
+void
+store_si_offset1 (signed int si, unsigned char *p)
+{
+  *(signed int *)(p + 1) = si; /* should generate STW.  */
+}
+
+void
+store_ul_offset1 (unsigned long ul, unsigned char *p)
+{
+  *(unsigned long *)(p + 1) = ul;  /* should generate PSTD.  */
+}
+
+void
+store_sl_offset1 (signed long sl, unsigned char *p)
+{
+  *(signed long *)(p + 1) = sl;/* should generate PSTD.  */
+}
+
+void
+store_float_offset1 (float f, unsigned char *p)
+{
+  *(float *)(p + 1) = f;   /* should generate STF.  */
+}
+
+void
+store_double_offset1 (double d, unsigned char *p)
+{
+  *(double *)(p + 1) = d;  /* should generate STD.  */
+}
+
+void
+store_float128_offset1 (__float128 f128, unsigned char *p)
+{
+  *(__float128 *)(p + 1) = f128;   /* should generate PSTXV.  */
+}
+
+/* { dg-final { scan-assembler-times {\mextsb\M} 1 } } */
+/* { dg-final { scan-assembler-times {\mlbz\M}   2 } } */
+/* { dg-final { scan-assembler-times {\mlfd\M}   1 } } */
+/* { dg-final { scan-assembler-times {\mlfs\M}   1 } } */
+/* { dg-final { scan-assembler-times {\mlha\M}   1 } } */
+/* { dg-final { scan-assembler-times {\mlhz\M}   1 } } */
+/* { dg-final { scan-assembler-times {\mlwz\M}   1 } } */
+/* { dg-final { scan-assembler-times {\mpld\M}   2 } } */
+/* { dg-final { scan-assembler-times {\mplwa\M}  1 } } */
+/* { dg-final { scan-assembler-times {\mplxv\M}  1 } } */
+/* { dg-final { scan-assembler-times {\mpstd\M}  2 } } */
+/* { dg-final { scan-assembler-times {\mpstxv\M} 1 } } */
+/* { dg-final { scan-assembler-times {\mstb\M}   2 } } */
+/* { dg-final { scan-assembler-times {\mstfd\M}  1 } } */
+/* { dg-final { scan-assembler-times {\mstfs\M}  1 } } */
+/* { dg-final { scan-assembler-times {\msth\M}   2 } } */
+/* { dg-final { scan-assembler-times {\mstw\M}   2 } } */

-- 

[PATCH] V11 patch #8 of 15, Add new tests for using PADDI and PLI with -mcpu=future

2019-12-20 Thread Michael Meissner
This is V10 patch #10. It adds 3 new tests to verify that we generate PADDI/PLI
for large constants when -mcpu=future is used.
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00843.html

This test passes when the preceeding patches are applied.  Can I check this in?

2019-12-20  Michael Meissner  

* gcc.target/powerpc/prefix-add.c: New test for -mcpu=future
generating PADDI for large constant adds.
* gcc.target/powerpc/prefix-di-constant.c: New test for
-mcpu=future generating PLI to load up large DImode constants.
* gcc.target/powerpc/prefix-si-constant.c: New test for
-mcpu=future generating PLI to load up large SImode constants.

Index: gcc/testsuite/gcc.target/powerpc/prefix-add.c
===
--- gcc/testsuite/gcc.target/powerpc/prefix-add.c   (revision 279252)
+++ gcc/testsuite/gcc.target/powerpc/prefix-add.c   (working copy)
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_prefixed_addr } */
+/* { 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/prefix-di-constant.c
===
--- gcc/testsuite/gcc.target/powerpc/prefix-di-constant.c   (revision 
279252)
+++ gcc/testsuite/gcc.target/powerpc/prefix-di-constant.c   (working copy)
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_prefixed_addr } */
+/* { 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/prefix-si-constant.c
===
--- gcc/testsuite/gcc.target/powerpc/prefix-si-constant.c   (revision 
279252)
+++ gcc/testsuite/gcc.target/powerpc/prefix-si-constant.c   (working copy)
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_prefixed_addr } */
+/* { 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} } } */

-- 
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] V11 patch #7 of 15, Add new target_supports cases for -mcpu=future tests.

2019-12-20 Thread Michael Meissner
This is V10 patch #9.  It adds new target_supports tests for the new patches:
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00842.html

All of the new tests work with these target supports.  Can I check it into the
trunk?

2019-12-20  Michael Meissner  

* lib/target-supports.exp (check_effective_target_powerpc_pcrel):
New target for PowerPC -mcpu=future support.
(check_effective_target_powerpc_prefixed_addr): New target for
PowerPC -mcpu=future support.

Index: gcc/testsuite/lib/target-supports.exp
===
--- gcc/testsuite/lib/target-supports.exp   (revision 279547)
+++ gcc/testsuite/lib/target-supports.exp   (working copy)
@@ -2161,6 +2161,23 @@ proc check_p9modulo_hw_available { } {
 }]
 }
 
+# Return 1 if the target generates PC-relative instructions automatically
+proc check_effective_target_powerpc_pcrel { } {
+return [check_no_messages_and_pattern powerpc_pcrel \
+   {\mpld\M.*[@]pcrel} assembly {
+   static long s;
+   long *p = 
+   long foo (void) { return s; }
+   } {-O2 -mcpu=future}]
+}
+
+# Return 1 if the target generates prefixed instructions automatically
+proc check_effective_target_powerpc_prefixed_addr { } {
+return [check_no_messages_and_pattern powerpc_prefixed_addr \
+   {\mpld\M} assembly {
+   long foo (long *p) { return p[0x12345]; }
+   } {-O2 -mcpu=future}]
+}
 
 # Return 1 if the target supports executing FUTURE instructions, 0 otherwise.
 # Cache the result.  It is assumed that if a simulator does not support the

-- 
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] V11 patch #6 of 15, Make -mpcrel the default for -mcpu=future on Linux 64-bit

2019-12-20 Thread Michael Meissner
This is the same as V10 patch #8.  Once the vector extract patches are
committed, this patch flips the default to use PC-relative addressing on 64-bit
Linux systems when the uses -mcpu=future.
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00841.html

I have bootstrapped the compiler on a little endian power8 system and ran the
testsuite with no regressions.  Once the preceeding V11 patches have been
checked in, can I check these patches into the trunk?

2019-12-20  Michael Meissner  

* config/rs6000/linux64.h (PREFIXED_ADDR_SUPPORTED_BY_OS): Set to
1 to enable prefixed addressing if -mcpu=future.
(PCREL_SUPPORTED_BY_OS): Set to 1 to enable PC-relative addressing
if -mcpu=future.
* config/rs6000/rs6000-cpus.h (ISA_FUTURE_MASKS_SERVER): Do not
enable -mprefixed-addr or -mpcrel by default.
(ADDRESSING_FUTURE_MASKS): New macro.
(OTHER_FUTURE_MASKS): Use ADDRESSING_FUTURE_MASKS.
* config/rs6000/rs6000.c (PREFIXED_ADDR_SUPPORTED_BY_OS): Disable
prefixed addressing unless the target OS tm.h says we should
enable it.
(PCREL_SUPPORTED_BY_OS): Disable PC-relative addressing unless the
target OS tm.h says we should enable it.
(rs6000_debug_reg_global): Print whether prefixed addressing and
PC-relative addressing is enabled by default if -mcpu=future.
(rs6000_option_override_internal): Move setting prefixed
addressing and PC-relative addressing after the sub-target option
handling is done.  Only enable prefixed addressing or PC-relative
address on -mcpu=future system if the target OS says to enable
it.  Disallow prefixed addressing on 32-bit systems or if the
target object file is not ELF v2.

Index: gcc/config/rs6000/linux64.h
===
--- gcc/config/rs6000/linux64.h (revision 279141)
+++ gcc/config/rs6000/linux64.h (working copy)
@@ -640,3 +640,11 @@ extern int dot_symbols;
enabling the __float128 keyword.  */
 #undef TARGET_FLOAT128_ENABLE_TYPE
 #define TARGET_FLOAT128_ENABLE_TYPE 1
+
+/* Enable support for pc-relative and numeric prefixed addressing on the
+   'future' system.  */
+#undef  PREFIXED_ADDR_SUPPORTED_BY_OS
+#define PREFIXED_ADDR_SUPPORTED_BY_OS  1
+
+#undef  PCREL_SUPPORTED_BY_OS
+#define PCREL_SUPPORTED_BY_OS  1
Index: gcc/config/rs6000/rs6000-cpus.def
===
--- gcc/config/rs6000/rs6000-cpus.def   (revision 279141)
+++ gcc/config/rs6000/rs6000-cpus.def   (working copy)
@@ -75,15 +75,22 @@
 | 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.  The prefixed and pc-relative
+   addressing bits are not added here.  Instead, they are added if the target
+   OS tm.h says that it supports the addressing modes by default when
+   -mcpu=future is used.  */
 #define ISA_FUTURE_MASKS_SERVER(ISA_3_0_MASKS_SERVER   
\
-| OPTION_MASK_FUTURE   \
+| OPTION_MASK_FUTURE)
+
+/* Addressing related flags on a future processor.  These are options that need
+   to be cleared if the target OS is not capable of supporting prefixed
+   addressing at all (such as 32-bit mode or if the object file format is not
+   ELF v2).  */
+#define ADDRESSING_FUTURE_MASKS(OPTION_MASK_PCREL  
\
 | OPTION_MASK_PREFIXED_ADDR)
 
 /* Flags that need to be turned off if -mno-future.  */
-#define OTHER_FUTURE_MASKS (OPTION_MASK_PCREL  \
-| OPTION_MASK_PREFIXED_ADDR)
+#define OTHER_FUTURE_MASKS ADDRESSING_FUTURE_MASKS
 
 /* Flags that need to be turned off if -mno-power9-vector.  */
 #define OTHER_P9_VECTOR_MASKS  (OPTION_MASK_FLOAT128_HW\
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 279202)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -98,6 +98,16 @@
 #endif
 #endif
 
+/* Set up the defaults for whether prefixed addressing is used, and if it is
+   used, whether we want to turn on pc-relative support by default.  */
+#ifndef PREFIXED_ADDR_SUPPORTED_BY_OS
+#define PREFIXED_ADDR_SUPPORTED_BY_OS  0
+#endif
+
+#ifndef PCREL_SUPPORTED_BY_OS
+#define PCREL_SUPPORTED_BY_OS  0
+#endif
+
 /* Support targetm.vectorize.builtin_mask_for_load.  */
 GTY(()) tree altivec_builtin_mask_for_load;
 
@@ -2535,6 +2545,14 @@ rs6000_debug_reg_global (void)
   if (TARGET_DIRECT_MOVE_128)
 fprintf (stderr, DEBUG_FMT_D, "VSX easy 64-bit mfvsrld element",
 

Re: *Ping* Introduce -finline-arg-packing

2019-12-20 Thread Jakub Jelinek
On Sun, Dec 15, 2019 at 07:11:25PM +0100, Thomas Koenig wrote:
> Am 10.12.19 um 22:22 schrieb Thomas Koenig:
> > Steve made an excellent suggestion: -finline-arg-packing .
> > 
> > So, OK with that change?
> 
> In other words, is
> 
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00485.html
> 
> OK with renaming the option to -finline-arg-packing ?

This patch broke:
+FAIL: compiler driver --help=fortran option(s): "^ +-.*[^:.]\$" absent from 
output: "  -finline-arg-packingPerform argument packing inline"
That test verifies that the help texts of all options are terminated
with dot or semicolon.

Fixed thusly, tested with make check-gcc RUNTESTFLAGS=help.exp.
I've additionally noticed you've swapped the two ChangeLog entries,
testsuite/ one went into fortran/ and vice versa, swapped that too
(and that is the reason why I'm posting exactly what I've committed
as obvious, rather than ChangeLog entry before patch + patch).

--- fortran/lang.opt(revision 279686)
+++ fortran/lang.opt(revision 279687)
@@ -649,7 +649,7 @@ Enum(gfc_init_local_real) String(-inf) V
 
 finline-arg-packing
 Fortran  Var(flag_inline_arg_packing) Init(-1)
--finline-arg-packing   Perform argument packing inline
+-finline-arg-packing   Perform argument packing inline.
 
 finline-matmul-limit=
 Fortran RejectNegative Joined UInteger Var(flag_inline_matmul_limit) Init(-1)
--- testsuite/ChangeLog (revision 279686)
+++ testsuite/ChangeLog (revision 279687)
@@ -51,12 +51,7 @@
 
PR middle-end/91512
PR fortran/92738
-   * invoke.texi: Document -finline-arg-packing.
-   * lang.opt: Add -finline-arg-packing.
-   * options.c (gfc_post_options): Handle -finline-arg-packing.
-   * trans-array.c (gfc_conv_array_parameter): Use
-   flag_inline_arg_packing instead of checking for optimize and
-   optimize_size.
+   * gfortran.dg/inline_pack_25.f90: New test.
 
 2019-12-20  Tobias Burnus  
 
--- fortran/ChangeLog   (revision 279686)
+++ fortran/ChangeLog   (revision 279687)
@@ -1,8 +1,19 @@
+2019-12-20  Jakub Jelinek  
+
+   PR middle-end/91512
+   PR fortran/92738
+   * lang.opt (-finline-arg-packing): Add trailing dot to help text.
+
 2019-12-20  Thomas Koenig  
 
PR middle-end/91512
PR fortran/92738
-   * gfortran.dg/inline_pack_25.f90: New test.
+   * invoke.texi: Document -finline-arg-packing.
+   * lang.opt: Add -finline-arg-packing.
+   * options.c (gfc_post_options): Handle -finline-arg-packing.
+   * trans-array.c (gfc_conv_array_parameter): Use
+   flag_inline_arg_packing instead of checking for optimize and
+   optimize_size.
 
 2019-12-20  Tobias Burnus  
 


Jakub



[PATCH] V11 patch #5 of 15, Optimize vec_extract of a vector in memory with a PC-relative address

2019-12-20 Thread Michael Meissner
This patch recognizes when we are doing the optimization of vector extract with
a constant element number when the vector is in memory and the vector's address
is PC-relative, to directly re-form the address using a PC-relative load,
instead of loading the address into a temporary register, and then doing an
indirect load.

I have bootstrapped a compiler on a little endian power8 machine and ran the
testsuite with no regressions.  Can I check this into the trunk?

2019-12-20  Michael Meissner  

* config/rs6000/rs6000.c (rs6000_reg_to_addr_mask): New helper
function to identify the address mask of a hard register.
(rs6000_adjust_vec_address): If we have a PC-relative address and
a constant vector element number, fold the element number into the
PC-relative address.

Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 279597)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -6722,6 +6722,30 @@ rs6000_expand_vector_extract (rtx target
 }
 }
 
+/* Helper function to return an address mask based on a physical register.  */
+
+static addr_mask_type
+rs6000_reg_to_addr_mask (rtx reg, machine_mode mode)
+{
+  unsigned int r = reg_or_subregno (reg);
+  addr_mask_type addr_mask;
+
+  gcc_assert (HARD_REGISTER_NUM_P (r));
+  if (INT_REGNO_P (r))
+addr_mask = reg_addr[mode].addr_mask[RELOAD_REG_GPR];
+
+  else if (FP_REGNO_P (r))
+addr_mask = reg_addr[mode].addr_mask[RELOAD_REG_FPR];
+
+  else if (ALTIVEC_REGNO_P (r))
+addr_mask = reg_addr[mode].addr_mask[RELOAD_REG_VMX];
+
+  else
+gcc_unreachable ();
+
+  return addr_mask;
+}
+
 /* Adjust a memory address (MEM) of a vector type to point to a scalar field
within the vector (ELEMENT) with a mode (SCALAR_MODE).  Use a base register
temporary (BASE_TMP) to fixup the address.  Return the new memory address
@@ -6854,6 +6878,51 @@ rs6000_adjust_vec_address (rtx scalar_re
}
 }
 
+  /* For references to local static variables, try to fold a constant offset
+ into the address.  */
+  else if (pcrel_local_address (addr, Pmode) && CONST_INT_P (element_offset))
+{
+  if (GET_CODE (addr) == CONST)
+   addr = XEXP (addr, 0);
+
+  if (GET_CODE (addr) == PLUS)
+   {
+ rtx op0 = XEXP (addr, 0);
+ rtx op1 = XEXP (addr, 1);
+ if (CONST_INT_P (op1))
+   {
+ HOST_WIDE_INT offset
+   = INTVAL (XEXP (addr, 1)) + INTVAL (element_offset);
+
+ if (offset == 0)
+   new_addr = op0;
+
+ else if (SIGNED_INTEGER_34BIT_P (offset))
+   {
+ rtx plus = gen_rtx_PLUS (Pmode, op0, GEN_INT (offset));
+ new_addr = gen_rtx_CONST (Pmode, plus);
+   }
+
+ else
+   {
+ emit_move_insn (base_tmp, addr);
+ new_addr = gen_rtx_PLUS (Pmode, base_tmp, element_offset);
+   }
+   }
+ else
+   {
+ emit_move_insn (base_tmp, addr);
+ new_addr = gen_rtx_PLUS (Pmode, base_tmp, element_offset);
+   }
+   }
+
+  else
+   {
+ rtx plus = gen_rtx_PLUS (Pmode, addr, element_offset);
+ new_addr = gen_rtx_CONST (Pmode, plus);
+   }
+}
+
   else
 {
   /* Make sure base_tmp is not the same as element_offset.  This can happen
@@ -6869,21 +6938,8 @@ rs6000_adjust_vec_address (rtx scalar_re
   if (GET_CODE (new_addr) == PLUS)
 {
   rtx op1 = XEXP (new_addr, 1);
-  addr_mask_type addr_mask;
-  unsigned int scalar_regno = reg_or_subregno (scalar_reg);
-
-  gcc_assert (HARD_REGISTER_NUM_P (scalar_regno));
-  if (INT_REGNO_P (scalar_regno))
-   addr_mask = reg_addr[scalar_mode].addr_mask[RELOAD_REG_GPR];
-
-  else if (FP_REGNO_P (scalar_regno))
-   addr_mask = reg_addr[scalar_mode].addr_mask[RELOAD_REG_FPR];
-
-  else if (ALTIVEC_REGNO_P (scalar_regno))
-   addr_mask = reg_addr[scalar_mode].addr_mask[RELOAD_REG_VMX];
-
-  else
-   gcc_unreachable ();
+  addr_mask_type addr_mask
+   = rs6000_reg_to_addr_mask (scalar_reg, scalar_mode);
 
   if (REG_P (op1) || SUBREG_P (op1))
valid_addr_p = (addr_mask & RELOAD_REG_INDEXED) != 0;
@@ -6891,9 +6947,21 @@ rs6000_adjust_vec_address (rtx scalar_re
valid_addr_p = (addr_mask & RELOAD_REG_OFFSET) != 0;
 }
 
+  /* An address that is a single register is always valid for either indexed or
+ offsettable loads.  */
   else if (REG_P (new_addr) || SUBREG_P (new_addr))
 valid_addr_p = true;
 
+  /* If we have a PC-relative address, check if offsetable loads are
+ allowed.  */
+  else if (pcrel_local_address (new_addr, Pmode))
+{
+  addr_mask_type addr_mask
+   = rs6000_reg_to_addr_mask (scalar_reg, scalar_mode);
+
+  valid_addr_p = (addr_mask & RELOAD_REG_OFFSET) != 0;
+}
+
   else
 

[PATCH] V11 patch #4 of 15, Update 'Q' constraint documentation.

2019-12-20 Thread Michael Meissner
In doing V11 patch #3, I noticed that the documentation for the 'Q' was
misleading.  This patch updates the documentation.  Can I check this patch into
the trunk?

2019-12-20  Michael Meissner  

* config/rs6000/constraints.md (Q constraint): Update
documentation.
* doc/md.tet (PowerPC constraints): Update 'Q' constraint
documentation.

Index: gcc/config/rs6000/constraints.md
===
--- gcc/config/rs6000/constraints.md(revision 279547)
+++ gcc/config/rs6000/constraints.md(working copy)
@@ -211,8 +211,7 @@ several times, or that might not access
(match_test "GET_RTX_CLASS (GET_CODE (XEXP (op, 0))) != RTX_AUTOINC")))
 
 (define_memory_constraint "Q"
-  "Memory operand that is an offset from a register (it is usually better
-to use @samp{m} or @samp{es} in @code{asm} statements)"
+  "A memory operand whose address which uses a single register with no offset."
   (and (match_code "mem")
(match_test "REG_P (XEXP (op, 0))")))
 
Index: gcc/doc/md.texi
===
--- gcc/doc/md.texi (revision 279547)
+++ gcc/doc/md.texi (working copy)
@@ -3381,8 +3381,7 @@ allowed when @samp{<} or @samp{>} is use
 as @samp{m} without @samp{<} and @samp{>}.
 
 @item Q
-Memory operand that is an offset from a register (it is usually better
-to use @samp{m} or @samp{es} in @code{asm} statements)
+A memory operand whose address which uses a single register with no offset.
 
 @item Z
 Memory operand that is an indexed or indirect from a register (it is

-- 
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] V11 patch #3 of 15, Use 'Q' constraint for variable vector extract from memory

2019-12-20 Thread Michael Meissner
As I mentioned in the intro, for the case where we are optimizing the extract
of a variable element from a vector in memory, the current code takes a regular
address, and the temporary that holds the byte offset, and tries to generate a
new address.  In particular, it failed when the vector was a PC-relative
address, because it didn't have enough temporary registers, and it used the
temporary to hold the byte offset to hold the address.

Initially in doing these patches, I reworked the constraints for prefixed and
non-prefixed memory so we could identify when we needed a second temporary.
Then I realized that eventaully we will want to generate an X-FORM (register +
register) address, and it was just simpler to use the 'Q' constraint, and have
the register allocator put the address into a register.

I have verified that the bug is indeed fixed (patch #15 will include the new
tests for this).  I have also bootstrapped the compiler on a little endian
power8 machine and there were no regressions in the test suite.  Can I check
this patch into the trunk?

2019-12-20  Michael Meissner  

* config/rs6000/vsx.md (vsx_extract__var, VSX_D iterator):
Use 'Q' for memory constraints because we need to do an X-FORM
load with the variable index.
(vsx_extract_v4sf_var): Use 'Q' for memory constraints because we
need to do an X-FORM load with the variable index.
(vsx_extract__var, VSX_EXTRACT_I iterator):Use 'Q' for
memory constraints because we need to do an X-FORM load with the
variable index.
(vsx_extract__mode_var): Use 'Q' for memory
constraints because we need to do an X-FORM load with the variable
index.

Index: gcc/config/rs6000/vsx.md
===
--- gcc/config/rs6000/vsx.md(revision 279597)
+++ gcc/config/rs6000/vsx.md(working copy)
@@ -3245,10 +3245,11 @@ (define_insn "vsx_vslo_"
   "vslo %0,%1,%2"
   [(set_attr "type" "vecperm")])
 
-;; Variable V2DI/V2DF extract
+;; Variable V2DI/V2DF extract.  Use 'Q' for the memory because we will
+;; ultimately have to convert the address into base + index.
 (define_insn_and_split "vsx_extract__var"
   [(set (match_operand: 0 "gpc_reg_operand" "=v,wa,r")
-   (unspec: [(match_operand:VSX_D 1 "input_operand" "v,m,m")
+   (unspec: [(match_operand:VSX_D 1 "input_operand" "v,Q,Q")
 (match_operand:DI 2 "gpc_reg_operand" "r,r,r")]
UNSPEC_VSX_EXTRACT))
(clobber (match_scratch:DI 3 "=r,,"))
@@ -3318,7 +3319,7 @@ (define_insn_and_split "*vsx_extract_v4s
 ;; Variable V4SF extract
 (define_insn_and_split "vsx_extract_v4sf_var"
   [(set (match_operand:SF 0 "gpc_reg_operand" "=wa,wa,?r")
-   (unspec:SF [(match_operand:V4SF 1 "input_operand" "v,m,m")
+   (unspec:SF [(match_operand:V4SF 1 "input_operand" "v,Q,Q")
(match_operand:DI 2 "gpc_reg_operand" "r,r,r")]
   UNSPEC_VSX_EXTRACT))
(clobber (match_scratch:DI 3 "=r,,"))
@@ -3681,7 +3682,7 @@ (define_insn_and_split "*vsx_extract__var"
   [(set (match_operand: 0 "gpc_reg_operand" "=r,r,r")
(unspec:
-[(match_operand:VSX_EXTRACT_I 1 "input_operand" "v,v,m")
+[(match_operand:VSX_EXTRACT_I 1 "input_operand" "v,v,Q")
  (match_operand:DI 2 "gpc_reg_operand" "r,r,r")]
 UNSPEC_VSX_EXTRACT))
(clobber (match_scratch:DI 3 "=r,r,"))
@@ -3701,7 +3702,7 @@ (define_insn_and_split "*vsx_extract_ 0 "gpc_reg_operand" "=r,r,r")
(zero_extend:
 (unspec:
- [(match_operand:VSX_EXTRACT_I 1 "input_operand" "v,v,m")
+ [(match_operand:VSX_EXTRACT_I 1 "input_operand" "v,v,Q")
   (match_operand:DI 2 "gpc_reg_operand" "r,r,r")]
  UNSPEC_VSX_EXTRACT)))
(clobber (match_scratch:DI 3 "=r,r,"))

-- 
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] V11 patch #2 of 15, Use prefixed load for vector extract with large offset

2019-12-20 Thread Michael Meissner
This patch incorporates large offsets for -mcpu=future when we optimization a
vector extract from memory and the memory address previously had been a
prefixed address with a large offset.

The current code would generate loading up the constant into a temporary and
then doing an indexed load.  Successive passes would eventually optimize that
back into the form we want (having the base register plus a large offset), but
it is better to generate the optimial code sooner.

I have bootstrapped this change on a little endian power8 system and there were
no regressions.  Can I check this into the trunk?

2019-12-20  Michael Meissner  

* config/rs6000/rs6000.c (rs6000_adjust_vec_address): Add support
for the offset being 34-bits when -mcpu=future is used.

Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 279553)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -6792,9 +6792,17 @@ rs6000_adjust_vec_address (rtx scalar_re
  HOST_WIDE_INT offset = INTVAL (op1) + INTVAL (element_offset);
  rtx offset_rtx = GEN_INT (offset);
 
- if (IN_RANGE (offset, -32768, 32767)
+ /* 16-bit offset.  */
+ if (SIGNED_INTEGER_16BIT_P (offset)
  && (scalar_size < 8 || (offset & 0x3) == 0))
new_addr = gen_rtx_PLUS (Pmode, op0, offset_rtx);
+
+ /* 34-bit offset if we have prefixed addresses.  */
+ else if (TARGET_PREFIXED_ADDR && SIGNED_INTEGER_34BIT_P (offset))
+   new_addr = gen_rtx_PLUS (Pmode, op0, offset_rtx);
+
+ /* Offset overflowed, move offset to the temporary (which will likely
+be split), and do X-FORM addressing.  */
  else
{
  emit_move_insn (base_tmp, offset_rtx);
@@ -6825,6 +6833,12 @@ rs6000_adjust_vec_address (rtx scalar_re
  emit_insn (insn);
}
 
+ /* Make sure we don't overwrite the temporary if the element being
+extracted is variable, and we've put the offset into base_tmp
+previously.  */
+ else if (rtx_equal_p (base_tmp, element_offset))
+   emit_insn (gen_add2_insn (base_tmp, op1));
+
  else
{
  /* Make sure base_tmp is not the same as element_offset.  This

-- 
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] Fix wrong-code x86 issue with avx512{f,vl} fma (PR target/93009)

2019-12-20 Thread Jakub Jelinek
Hi!

As mentioned in the PR, the following testcase is miscompiled with avx512vl.
The reason is that the fma *_bcst_1 define_insns have two alternatives:
"=v,v" "0,v" "v,0" "m,m" and use the same
vfmadd213* %3, %2, %0
pattern.  If the first alternative is chosen, everything is ok, but if the
second alternative is chosen, %2 and %0 are the same register, so instead
of doing dest=dest*another+membcst we do dest=dest*dest+membcst.
Now, to fix this, either we'd need separate:
  "vfmadd213\t{%3, %2, 
%0|%0, %2, %3}
   vfmadd213\t{%3, %1, 
%0|%0, %1, %3}"
where for the second alternative, we'd just use %1 instead of %2, but
what I think is actually cleaner is just use a single alternative and
make the two multiplication operands commutative, which they really are.

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

2019-12-20  Jakub Jelinek  

PR target/93009
* config/i386/sse.md
(*fma_fmadd__bcst_1,
*fma_fmsub__bcst_1,
*fma_fnmadd__bcst_1,
*fma_fnmsub__bcst_1): Use
just a single alternative instead of two, make operands 1 and 2
commutative.

* gcc.target/i386/avx512vl-pr93009.c: New test.

--- gcc/config/i386/sse.md.jj   2019-12-09 11:12:30.0 +0100
+++ gcc/config/i386/sse.md  2019-12-20 21:44:58.165432773 +0100
@@ -4172,12 +4172,12 @@ (define_insn "fma_fmadd
(set_attr "mode" "")])
 
 (define_insn "*fma_fmadd__bcst_1"
-  [(set (match_operand:VF_AVX512 0 "register_operand" "=v,v")
+  [(set (match_operand:VF_AVX512 0 "register_operand" "=v")
(fma:VF_AVX512
- (match_operand:VF_AVX512 1 "register_operand" "0,v")
- (match_operand:VF_AVX512 2 "register_operand" "v,0")
+ (match_operand:VF_AVX512 1 "register_operand" "%0")
+ (match_operand:VF_AVX512 2 "register_operand" "v")
  (vec_duplicate:VF_AVX512
-   (match_operand: 3 "memory_operand" "m,m"]
+   (match_operand: 3 "memory_operand" "m"]
   "TARGET_AVX512F && "
   "vfmadd213\t{%3, %2, 
%0|%0, %2, %3}"
   [(set_attr "type" "ssemuladd")
@@ -4289,13 +4289,13 @@ (define_insn "fma_fmsub
(set_attr "mode" "")])
 
 (define_insn "*fma_fmsub__bcst_1"
-  [(set (match_operand:VF_AVX512 0 "register_operand" "=v,v")
+  [(set (match_operand:VF_AVX512 0 "register_operand" "=v")
(fma:VF_AVX512
- (match_operand:VF_AVX512 1 "register_operand" "0,v")
- (match_operand:VF_AVX512 2 "register_operand" "v,0")
+ (match_operand:VF_AVX512 1 "register_operand" "%0")
+ (match_operand:VF_AVX512 2 "register_operand" "v")
  (neg:VF_AVX512
(vec_duplicate:VF_AVX512
- (match_operand: 3 "memory_operand" "m,m")]
+ (match_operand: 3 "memory_operand" "m")]
   "TARGET_AVX512F && "
   "vfmsub213\t{%3, %2, 
%0|%0, %2, %3}"
   [(set_attr "type" "ssemuladd")
@@ -4411,13 +4411,13 @@ (define_insn "fma_fnmad
(set_attr "mode" "")])
 
 (define_insn "*fma_fnmadd__bcst_1"
-  [(set (match_operand:VF_AVX512 0 "register_operand" "=v,v")
+  [(set (match_operand:VF_AVX512 0 "register_operand" "=v")
(fma:VF_AVX512
  (neg:VF_AVX512
-   (match_operand:VF_AVX512 1 "register_operand" "0,v"))
- (match_operand:VF_AVX512 2 "register_operand" "v,0")
+   (match_operand:VF_AVX512 1 "register_operand" "%0"))
+ (match_operand:VF_AVX512 2 "register_operand" "v")
  (vec_duplicate:VF_AVX512
-   (match_operand: 3 "memory_operand" "m,m"]
+   (match_operand: 3 "memory_operand" "m"]
   "TARGET_AVX512F && "
   "vfnmadd213\t{%3, %2, 
%0|%0, %2, %3}"
   [(set_attr "type" "ssemuladd")
@@ -4535,14 +4535,14 @@ (define_insn "fma_fnmsu
(set_attr "mode" "")])
 
 (define_insn "*fma_fnmsub__bcst_1"
-  [(set (match_operand:VF_AVX512 0 "register_operand" "=v,v")
+  [(set (match_operand:VF_AVX512 0 "register_operand" "=v")
(fma:VF_AVX512
  (neg:VF_AVX512
-   (match_operand:VF_AVX512 1 "register_operand" "0,v"))
- (match_operand:VF_AVX512 2 "register_operand" "v,0")
+   (match_operand:VF_AVX512 1 "register_operand" "%0"))
+ (match_operand:VF_AVX512 2 "register_operand" "v")
  (neg:VF_AVX512
(vec_duplicate:VF_AVX512
- (match_operand: 3 "memory_operand" "m,m")]
+ (match_operand: 3 "memory_operand" "m")]
   "TARGET_AVX512F && "
   "vfnmsub213\t{%3, %2, 
%0|%0, %2, %3}"
   [(set_attr "type" "ssemuladd")
--- gcc/testsuite/gcc.target/i386/avx512vl-pr93009.c.jj 2019-12-20 
21:54:11.158011954 +0100
+++ gcc/testsuite/gcc.target/i386/avx512vl-pr93009.c2019-12-20 
21:53:50.375328425 +0100
@@ -0,0 +1,38 @@
+/* PR target/93009 */
+/* { dg-do run { target { avx512vl } } } */
+/* { dg-options "-O2 -mavx512vl" } */
+
+#define AVX512VL
+#define AVX512F_LEN 512
+#define AVX512F_LEN_HALF 256
+
+#include "avx512f-check.h"
+
+typedef double v2df __attribute__((vector_size (16)));
+
+__attribute__((noipa)) v2df
+foo 

[C++ PATCH] Fix up parsing of T (__attribute__(()) fn) (int) in C++17 mode (PR c++/92438)

2019-12-20 Thread Jakub Jelinek
Hi!

In C++17/2a mode, cp_parser_constructor_declarator_p because of deduction
guides considers constructor_p in more cases and returns true on
typedef struct S { int x; } T;
T (__attribute__((unused)) qux) (T x);
just because constructor arguments may start with __attribute__ keyword
(as the testcase tests, yes, they can, but parenthesized declarator can
too), and so we reject the above declaration, even when it is valid and
accepted in C++98/11/14 modes too.
The testcase shows this causing problems already before, e.g. declaring
methods with parenthesized declarator starting with attribute used to be
considered as constructor and rejected for quite a while.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?

2019-12-20  Jakub Jelinek  

PR c++/92438
* parser.c (cp_parser_constructor_declarator_p): If open paren
is followed by RID_ATTRIBUTE, skip over the attribute tokens and
try to parse type specifier.

* g++.dg/ext/attrib61.C: New test.

--- gcc/cp/parser.c.jj  2019-12-20 17:51:44.979483292 +0100
+++ gcc/cp/parser.c 2019-12-20 19:15:40.011165334 +0100
@@ -28493,7 +28493,15 @@ cp_parser_constructor_declarator_p (cp_p
  /* A parameter declaration begins with a decl-specifier,
 which is either the "attribute" keyword, a storage class
 specifier, or (usually) a type-specifier.  */
- && !cp_lexer_next_token_is_decl_specifier_keyword (parser->lexer)
+ && (!cp_lexer_next_token_is_decl_specifier_keyword (parser->lexer)
+ /* GNU attributes can actually appear both at the start of
+a parameter and parenthesized declarator.
+S (__attribute__((unused)) int);
+is a constructor, but
+S (__attribute__((unused)) foo) (int);
+is a function declaration.  */
+ || (cp_parser_allow_gnu_extensions_p (parser)
+ && cp_next_tokens_can_be_gnu_attribute_p (parser)))
  /* A parameter declaration can also begin with [[attribute]].  */
  && !cp_next_tokens_can_be_std_attribute_p (parser))
{
@@ -28501,6 +28509,13 @@ cp_parser_constructor_declarator_p (cp_p
  tree pushed_scope = NULL_TREE;
  unsigned saved_num_template_parameter_lists;
 
+ if (cp_next_tokens_can_be_gnu_attribute_p (parser))
+   {
+ unsigned int n = cp_parser_skip_gnu_attributes_opt (parser, 1);
+ while (--n)
+   cp_lexer_consume_token (parser->lexer);
+   }
+
  /* Names appearing in the type-specifier should be looked up
 in the scope of the class.  */
  if (current_class_type)
--- gcc/testsuite/g++.dg/ext/attrib61.C.jj  2019-12-20 19:22:30.073916272 
+0100
+++ gcc/testsuite/g++.dg/ext/attrib61.C 2019-12-20 19:19:44.325450755 +0100
@@ -0,0 +1,26 @@
+// PR c++/92438
+// { dg-do compile }
+
+typedef struct S { int x; } T;
+T (foo) (T x);
+T __attribute__((unused)) bar (T x);
+struct S (__attribute__((unused)) baz) (T x);
+T (__attribute__((unused)) qux) (T x);
+
+struct U
+{
+  U (__attribute__((unused)) int);
+  U (__attribute__((unused)) corge) (int);
+};
+
+void
+test ()
+{
+  T a, b;
+  a = foo (b);
+  b = bar (a);
+  a = baz (b);
+  b = qux (a);
+  U u (5);
+  U v = u.corge (3);
+}

Jakub



[PATCH] V11 patch #1 of 15, Fix bug in vec_extract

2019-12-20 Thread Michael Meissner
This patch fixes the bug pointed out in the V10 patch review that the code
modified an input argument to vector extract with a variable element number.

I also added two gcc_asserts to the vector extract address code to signal an
internal error if the temporary base register was used for two different
purposes.  This shows up if you have a vector whose address is a PC-relative
address and the element number was variable.

Later patches will fix the case that I know of that generates the bad code, but
it is still important to make sure the same case doesn't happen in the future.

With this patch applied, the compiler will signal an error.  FWIW, I did build
all of Spec 2017 and Spec 2006 with this patch applied, but not the others, and
we did not get an assertion failure.

I have bootstrapped the compiler and there were no regression test failures on
a little endian Power8 system.

2019-12-20  Michael Meissner  

* config/rs6000/rs6000.c (rs6000_adjust_vec_address): Add
assertion to make sure that we don't load an address into a
temporary that is already used.
(rs6000_split_vec_extract_var): Do not overwrite the element when
masking it.  Use the base register temporary instead.

Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 279549)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -6757,6 +6757,8 @@ rs6000_adjust_vec_address (rtx scalar_re
 
   else
{
+ /* If we are called from rs6000_split_vec_extract_var, base_tmp may
+be the same as element.  */
  if (TARGET_POWERPC64)
emit_insn (gen_ashldi3 (base_tmp, element, GEN_INT (byte_shift)));
  else
@@ -6825,6 +6827,11 @@ rs6000_adjust_vec_address (rtx scalar_re
 
  else
{
+ /* Make sure base_tmp is not the same as element_offset.  This
+can happen if the element number is variable and the address
+is not a simple address.  Otherwise we lose the offset, and
+double the address.  */
+ gcc_assert (!reg_mentioned_p (base_tmp, element_offset));
  emit_move_insn (base_tmp, op1);
  emit_insn (gen_add2_insn (base_tmp, element_offset));
}
@@ -6835,6 +6842,10 @@ rs6000_adjust_vec_address (rtx scalar_re
 
   else
 {
+  /* Make sure base_tmp is not the same as element_offset.  This can happen
+if the element number is variable and the address is not a simple
+address.  Otherwise we lose the offset, and double the address.  */
+  gcc_assert (!reg_mentioned_p (base_tmp, element_offset));
   emit_move_insn (base_tmp, addr);
   new_addr = gen_rtx_PLUS (Pmode, base_tmp, element_offset);
 }
@@ -6902,9 +6913,10 @@ rs6000_split_vec_extract_var (rtx dest,
   int num_elements = GET_MODE_NUNITS (mode);
   rtx num_ele_m1 = GEN_INT (num_elements - 1);
 
-  emit_insn (gen_anddi3 (element, element, num_ele_m1));
+  /* Make sure the element number is in bounds.  */
   gcc_assert (REG_P (tmp_gpr));
-  emit_move_insn (dest, rs6000_adjust_vec_address (dest, src, element,
+  emit_insn (gen_anddi3 (tmp_gpr, element, num_ele_m1));
+  emit_move_insn (dest, rs6000_adjust_vec_address (dest, src, tmp_gpr,
   tmp_gpr, scalar_mode));
   return;
 }

-- 
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: [C++ PATCH] PR c++/92745 - bogus error when initializing array of vectors.

2019-12-20 Thread Marek Polacek
On Fri, Dec 20, 2019 at 05:56:39PM -0500, Jason Merrill wrote:
> On 12/20/19 3:27 PM, Marek Polacek wrote:
> > In r268428 I changed reshape_init_r in such a way that when it sees
> > a nested { } in a CONSTRUCTOR with missing braces, it just returns
> > the initializer:
> > + else if (COMPOUND_LITERAL_P (stripped_init)
> > ...
> > + ++d->cur;
> > + gcc_assert (!BRACE_ENCLOSED_INITIALIZER_P (stripped_init));
> > + return init;
> > 
> > But as this test shows, that's incorrect: if TYPE is an array, we need
> > to proceed to reshape_init_array_1 which will iterate over the array
> > initializers:
> >   6006   /* Loop until there are no more initializers.  */
> >   6007   for (index = 0;
> >   6008d->cur != d->end && (!sized_array_p || index <= 
> > max_index_cst);
> >   6009++index)
> >   6010 {
> > and update d.cur accordingly.  In other words, when reshape_init gets
> > 
> > {{col[0][0], col[1][0], col[2][0], col[3][0]},
> >   {col[0][1], col[1][1], col[2][1], col[3][1]},
> >   {col[0][2], col[1][2], col[2][2], col[3][2]},
> >   {col[0][3], col[1][3], col[2][3], col[3][3]}}
> > 
> > we recurse on the first element:
> >{col[0][0], col[1][0], col[2][0], col[3][0]}
> > and we can't just move d.cur to point to
> >{col[0][1], col[1][1], col[2][1], col[3][1]}
> > and return; we need to iterate, so that d.cur ends up being properly
> > updated, and after all initializers have been seen, points to d.end.
> > Currently we skip the loop, wherefore we hit this:
> > 
> >   6502   /* Make sure all the element of the constructor were used. 
> > Otherwise,
> >   6503  issue an error about exceeding initializers.  */
> >   6504   if (d.cur != d.end)
> >   6505 {
> >   6506   if (complain & tf_error)
> >   6507 error ("too many initializers for %qT", type);
> >   6508   return error_mark_node;
> >   6509 }
> > 
> > Bootstrapped/regtested on x86_64-linux, built cmcstl2, ok for trunk
> > and branches?
> > 
> > 2019-12-20  Marek Polacek  
> > 
> > PR c++/92745 - bogus error when initializing array of vectors.
> > * decl.c (reshape_init_r): For a nested compound literal, do
> > call reshape_init_{class,array,vector}.
> > 
> > * g++.dg/cpp0x/initlist118.C: New test.
> > 
> > diff --git gcc/cp/decl.c gcc/cp/decl.c
> > index 7d4c947fb58..c15cbfa3bd3 100644
> > --- gcc/cp/decl.c
> > +++ gcc/cp/decl.c
> > @@ -6399,14 +6399,13 @@ reshape_init_r (tree type, reshape_iter *d, bool 
> > first_initializer_p,
> >by the front end.  Here we have e.g. {.__pfn=0B, .__delta=0},
> >which is missing outermost braces.  We should warn below, and
> >one of the routines below will wrap it in additional { }.  */;
> > - /* For a nested compound literal, there is no need to reshape since
> > -we called reshape_init in finish_compound_literal, before calling
> > -digest_init.  */
> > - else if (COMPOUND_LITERAL_P (stripped_init)
> > -  /* Similarly, a CONSTRUCTOR of the target's type is a
> > - previously digested initializer.  */
> > -  || same_type_ignoring_top_level_qualifiers_p (type,
> > -init_type))
> > + /* For a nested compound literal, proceed to specialized routines,
> > +to handle initialization of arrays and similar.  */
> > + else if (COMPOUND_LITERAL_P (stripped_init))
> > +   gcc_assert (!BRACE_ENCLOSED_INITIALIZER_P (stripped_init));
> > + /* A CONSTRUCTOR of the target's type is a previously
> > +digested initializer.  */
> > + else if (same_type_ignoring_top_level_qualifiers_p (type, init_type))
> > {
> >   ++d->cur;
> >   gcc_assert (!BRACE_ENCLOSED_INITIALIZER_P (stripped_init));
> 
> Incidentally, asserting !BRACE_ENCLOSED_INITIALIZER_P seems pretty
> pointless, since that checks for init_list_type_node, and a compound literal
> won't have that type, nor will we see that type if we just checked that it's
> something else.

True, would an obvious patch to remove that assert be OK?

--
Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA



Re: [C++ PATCH] Avoid weird inform without previos error during SFINAE (PR c++/92965)

2019-12-20 Thread Jason Merrill

On 12/17/19 3:51 PM, Jakub Jelinek wrote:

Hi!

On the following testcase, complain & tf_error is 0 during sfinae, so we
don't emit error, but we called structural_type_p with explain=true anyway,
which emitted the inform messages.
Fixed by doing it only when we emit the error.

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


OK.


BTW, is the testcase valid in C++17 mode?  GCC 7/8/9/trunk accept it,
but clang++ rejects it.


No, non-template parameters of class types are a C++20 feature.


2019-12-17  Jakub Jelinek  

PR c++/92965
* pt.c (invalid_nontype_parm_type_p): Call structural_type_p with
explain=true only if emitting error.

* g++.dg/cpp2a/nontype-class27.C: New test.

--- gcc/cp/pt.c.jj  2019-12-11 18:19:03.188162534 +0100
+++ gcc/cp/pt.c 2019-12-17 14:21:48.903024760 +0100
@@ -25829,11 +25829,13 @@ invalid_nontype_parm_type_p (tree type,
return true;
if (!structural_type_p (type))
{
- auto_diagnostic_group d;
  if (complain & tf_error)
-   error ("%qT is not a valid type for a template non-type parameter "
-  "because it is not structural", type);
- structural_type_p (type, true);
+   {
+ auto_diagnostic_group d;
+ error ("%qT is not a valid type for a template non-type "
+"parameter because it is not structural", type);
+ structural_type_p (type, true);
+   }
  return true;
}
return false;
--- gcc/testsuite/g++.dg/cpp2a/nontype-class27.C.jj 2019-12-17 
14:35:42.339473136 +0100
+++ gcc/testsuite/g++.dg/cpp2a/nontype-class27.C2019-12-17 
14:26:13.461040058 +0100
@@ -0,0 +1,15 @@
+// PR c++/92965
+// { dg-do compile { target c++2a } }
+
+template
+class TS {
+  int x;   // { dg-bogus "is not public" }
+public:
+  constexpr TS(int) {}
+};
+TS(int) -> TS<1>;
+
+template void foo() {}
+template void foo() {}
+
+void test() { foo<2>(); }

Jakub





Re: [C++ PATCH] Fix bad defaulted comparison operator error recovery (PR c++/92966)

2019-12-20 Thread Jason Merrill

On 12/17/19 3:57 PM, Jakub Jelinek wrote:

Hi!

When the prototype of defaulted comparison operator is incorrect, we set
DECL_MAYBE_DELETED, but don't set DECL_DEFAULTED_FN and other flags, so we
ICE during synthetize_method.

Seems only marking DECL_MAYBE_DELETED those operators that we are also going
to mark DECL_DEFAULTED_FN results in better error recovery.

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


OK.


2019-12-17  Jakub Jelinek  

PR c++/92966
* method.c (early_check_defaulted_comparison): Don't set
DECL_MAYBE_DELETED when returning false.

* g++.dg/cpp2a/spaceship-eq8.C: New test.

--- gcc/cp/method.c.jj  2019-12-11 18:19:03.185162579 +0100
+++ gcc/cp/method.c 2019-12-17 15:28:57.819285145 +0100
@@ -1146,7 +1146,7 @@ early_check_defaulted_comparison (tree f
  }
  
/* We still need to deduce deleted/constexpr/noexcept and maybe return. */

-  DECL_MAYBE_DELETED (fn) = true;
+  DECL_MAYBE_DELETED (fn) = ok;
  
return ok;

  }
--- gcc/testsuite/g++.dg/cpp2a/spaceship-eq8.C.jj   2019-12-17 
15:46:35.390322157 +0100
+++ gcc/testsuite/g++.dg/cpp2a/spaceship-eq8.C  2019-12-17 15:46:31.493380971 
+0100
@@ -0,0 +1,8 @@
+// PR c++/92966
+// { dg-do compile { target c++2a } }
+
+struct S {
+  int operator==(const S&) const = default;// { dg-error "must return 
'bool'" }
+  int s;   // { dg-message "declared here" 
"" { target *-*-* } .-1 }
+};
+static_assert(S{} == S{}); // { dg-error "" }

Jakub





PowerPC -mcpu=future patches, V11

2019-12-20 Thread Michael Meissner
This set of patches reworks the vector extract issues in the V10 patches.

If you recall, in V10, you pointed out that for vector extract, the existing
code overwrote an input argument, and that is fixed in these patches.

In V10, I added two new constraints (ep and em) to categorize whether a memory
is prefixed or not prefixed, and we had some discussion about how to write the
predicates.

However, yesterday I realized that for the case adding new constraints (vector
extract with a variable element number, where the vector is in memory, and we
are optimizing the load to just load up the element being extract), what we
want is just the address of the vector in a base register.

This is because in order access the element where the element number is
variable, we eventually will need to do an X-FORM load, with the vector address
in one register, and the byte offset in another.

Instead of adding new alternatives and new scratch registers, I could just
simplify the code and use the 'Q' constraint that says use a single register as
the address.  The register allocator will do the necessary work to load up the
address during register allocation.

I did notice that the documentation for 'Q' was wrong, so one of the patches
updates the documentation.

In addition, after committing the first 3 patches from V10 that added PADDI and
PLI support for -mcpu=future, Segher asked me to do a patch to rename two of
the macros.  That patch is now checked in, and some of these patches include
changes due to the macro renaming.

After the vector extract patch rework, I included the remaining patch to the
compiler (make -mpcrel default on Linux 64-bit for -mcpu=future).  I included
the tests after doing the -mpcrel default changes.  In addition to the tests in
V10, I added some new tests for the vector extract code.

-- 
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: [C++ PATCH] Disallow defaulted comparison operators in C++11-17 modes (PR c++/92973)

2019-12-20 Thread Jason Merrill

On 12/17/19 3:59 PM, Jakub Jelinek wrote:

Hi!

As discussed on IRC, defaulted comparison operators were added only in
C++2a, so we shouldn't accept it in older standard modes.

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


OK.


2019-12-17  Jakub Jelinek  

PR c++/92973
* method.c (early_check_defaulted_comparison): For C++17 and earlier
diagnose defaulted comparison operators.

* g++.dg/cpp0x/spaceship-eq1.C: New test.

--- gcc/cp/method.c.jj  2019-12-17 15:28:57.819285145 +0100
+++ gcc/cp/method.c 2019-12-17 16:21:24.462870308 +0100
@@ -1092,6 +1092,13 @@ early_check_defaulted_comparison (tree f
  ctx = DECL_FRIEND_CONTEXT (fn);
bool ok = true;
  
+  if (cxx_dialect < cxx2a)

+{
+  error_at (loc, "defaulted %qD only available with %<-std=c++2a%> or "
+"%<-std=gnu++2a%>", fn);
+  return false;
+}
+
if (!DECL_OVERLOADED_OPERATOR_IS (fn, SPACESHIP_EXPR)
&& !same_type_p (TREE_TYPE (TREE_TYPE (fn)), boolean_type_node))
  {
--- gcc/testsuite/g++.dg/cpp0x/spaceship-eq1.C.jj   2019-12-17 
16:24:55.303697061 +0100
+++ gcc/testsuite/g++.dg/cpp0x/spaceship-eq1.C  2019-12-17 16:24:29.070091886 
+0100
@@ -0,0 +1,5 @@
+// PR c++/92973
+// { dg-do compile { target c++11 } }
+
+struct S { bool operator==(const S&) const = default; int s; };// { dg-error "only 
available with" "" { target c++17_down } }
+struct T { bool operator!=(const T&) const = default; int t; };// { dg-error "only 
available with" "" { target c++17_down } }

Jakub





Re: [C++ PATCH] Fix -Wunused-but-set-* false positives in arg passing to ... (PR c++/92666)

2019-12-20 Thread Jason Merrill

On 12/18/19 6:44 PM, Jakub Jelinek wrote:

Hi!

convert_arg_to_ellipsis used to call decay_conversion for all types
(which calls mark_rvalue_use), but it doesn't anymore in GCC 10,
and while for INTEGRAL_OR_ENUMERATION_TYPE_P args it calls
cp_perform_integral_promotions which does that too and for aggregate
args keeps calling decay_conversion, for floating point or decltype(nullptr)
args there is nothing that would shut up -Wunused-but-set-* warning
(and I guess equally also handle lambda captures).

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?


OK.


2019-12-19  Jakub Jelinek  

PR c++/92666
* call.c (convert_arg_to_ellipsis): For floating point or
decltype(nullptr) arguments call mark_rvalue_use.

* g++.dg/warn/Wunused-var-36.C: New test.

--- gcc/cp/call.c.jj2019-12-17 10:19:51.013282361 +0100
+++ gcc/cp/call.c   2019-12-18 18:23:01.441357443 +0100
@@ -7819,10 +7819,12 @@ convert_arg_to_ellipsis (tree arg, tsubs
"implicit conversion from %qH to %qI when passing "
"argument to function",
arg_type, double_type_node);
+  arg = mark_rvalue_use (arg);
arg = convert_to_real_nofold (double_type_node, arg);
  }
else if (NULLPTR_TYPE_P (arg_type))
  {
+  arg = mark_rvalue_use (arg);
if (TREE_SIDE_EFFECTS (arg))
arg = cp_build_compound_expr (arg, null_pointer_node, complain);
else
--- gcc/testsuite/g++.dg/warn/Wunused-var-36.C.jj   2019-12-18 
18:05:50.804946325 +0100
+++ gcc/testsuite/g++.dg/warn/Wunused-var-36.C  2019-12-18 18:40:19.130654606 
+0100
@@ -0,0 +1,25 @@
+// PR c++/92666
+// { dg-do compile }
+// { dg-options "-Wunused-but-set-variable" }
+
+int bar (int, ...);
+#if __cplusplus >= 201103L
+enum class E : int { F = 0, G = 1 };
+#endif
+struct S { int s; };
+
+void
+foo ()
+{
+  float r = 1.0f;  // { dg-bogus "set but not used" }
+  int i = 2;   // { dg-bogus "set but not used" }
+#if __cplusplus >= 201103L
+  decltype(nullptr) n = nullptr;   // { dg-bogus "set but not used" }
+  E e = E::F;  // { dg-bogus "set but not used" }
+#else
+  void *n = (void *) 0;
+  int e = 4;
+#endif
+  S s = { 3 }; // { dg-bogus "set but not used" }
+  bar (0, r, i, n, e, s);
+}

Jakub





Re: [C++] Fix ICE for binding lax vector conversions to references (PR 93014)

2019-12-20 Thread Jason Merrill

On 12/19/19 11:33 AM, Richard Sandiford wrote:

This test:

typedef unsigned int v4si __attribute__ ((vector_size(16)));
typedef unsigned char v16qi __attribute__ ((vector_size(16)));
extern v16qi x;
v4si  = x;

ICEs with:

a.c:4:11: internal compiler error: in convert_like_real, at cp/call.c:7670

This started with r260780, which had the effect of making lvalue_kind
look through VIEW_CONVERT_EXPR in all cases, not just for location
wrappers.  This also means that:

typedef unsigned int v4si __attribute__ ((vector_size(16)));
typedef unsigned char v16qi __attribute__ ((vector_size(16)));
extern v16qi x;
v4si  = reinterpret_cast(x);

is now valid despite the result of the cast being an rvalue.

There might be two separate problems here:

(1) Vector conversions aren't being treated as rvalues when they should
 be.  The patch below attempts to fix that by calling rvalue on the
 input to the conversion, so that the tree looks the same as for:

   extern v16qi x;
   v4si  = (v4si)x;

 which is already handled correctly.


Yes, I think this is the problem.


(2) The convert_like_real check seems to be trying (at least partially)
 to reproduce the logic in reference_binding that led to bad_p being
 set to true.  But the "from" type it's using is the result of the
 implicit conversion added by reference_binding rather than the
 "from" type that reference_binding was using.  AFAICT he result of
 that implicit converson should always be reference-compatible with
 the reference type, so we don't get the error we expected for that
 case.

 The patch doesn't attempt to fix this though.
I think this is only an issue because of the value category problem 
above; the implicit_conversion should produce an rvalue.



Tested on aarch64-linux-gnu and x86_64-linux-gnu.  OK to install?


OK.


Richard


2019-12-19  Richard Sandiford  

gcc/cp/
PR c++/93014
* cvt.c (ocp_convert): Apply rvalue to the source of vector
conversions.
* typeck.c (build_reinterpret_cast_1): Likewise.

gcc/testsuite/
PR c++/93014
* g++.dg/ext/vector39.C: New test.

Index: gcc/cp/cvt.c
===
--- gcc/cp/cvt.c2019-12-10 09:17:17.688010184 +
+++ gcc/cp/cvt.c2019-12-19 16:28:40.340411914 +
@@ -744,7 +744,7 @@ ocp_convert (tree type, tree expr, int c
else if (TREE_CODE (type) == COMPLEX_TYPE)
return convert_to_complex_maybe_fold (type, e, dofold);
else if (VECTOR_TYPE_P (type))
-   return convert_to_vector (type, e);
+   return convert_to_vector (type, rvalue (e));
else if (TREE_CODE (e) == TARGET_EXPR)
{
  /* Don't build a NOP_EXPR of class type.  Instead, change the
@@ -881,7 +881,7 @@ ocp_convert (tree type, tree expr, int c
  in_vtype, type);
  return error_mark_node;
}
-  return convert_to_vector (type, e);
+  return convert_to_vector (type, rvalue (e));
  }
if (code == REAL_TYPE || code == COMPLEX_TYPE)
  {
Index: gcc/cp/typeck.c
===
--- gcc/cp/typeck.c 2019-12-19 13:21:34.914651487 +
+++ gcc/cp/typeck.c 2019-12-19 16:28:40.344411888 +
@@ -7858,7 +7858,7 @@ build_reinterpret_cast_1 (location_t loc
return build_nop_reinterpret (type, expr);
  }
else if (gnu_vector_type_p (type))
-return convert_to_vector (type, expr);
+return convert_to_vector (type, rvalue (expr));
else if (gnu_vector_type_p (intype)
   && INTEGRAL_OR_ENUMERATION_TYPE_P (type))
  return convert_to_integer_nofold (type, expr);
Index: gcc/testsuite/g++.dg/ext/vector39.C
===
--- /dev/null   2019-09-17 11:41:18.176664108 +0100
+++ gcc/testsuite/g++.dg/ext/vector39.C 2019-12-19 16:28:40.344411888 +
@@ -0,0 +1,96 @@
+// { dg-options "-flax-vector-conversions" }
+
+typedef unsigned char v16qi __attribute__((vector_size(16)));
+typedef unsigned int v4si __attribute__((vector_size(16)));
+
+extern v4si normal_v4si;
+extern const v4si const_v4si;
+extern v4si *normal_v4si_ptr;
+extern const v4si *const_v4si_ptr;
+extern v4si _v4si_ref;
+extern const v4si _v4si_ref;
+
+extern v16qi normal_v16qi;
+extern const v16qi const_v16qi;
+extern v16qi *normal_v16qi_ptr;
+extern const v16qi *const_v16qi_ptr;
+extern v16qi _v16qi_ref;
+extern const v16qi _v16qi_ref;
+
+namespace nonconst_refs {
+  v16qi _normal_v4si = normal_v4si; // { dg-error {cannot bind non-const 
lvalue} }
+  v16qi _const_v4si = const_v4si; // { dg-error {cannot bind non-const 
lvalue} }
+  v16qi _normal_v4si_ptr = *normal_v4si_ptr; // { dg-error {cannot bind 
non-const lvalue} }
+  v16qi _const_v4si_ptr = *const_v4si_ptr; // { dg-error {cannot bind 
non-const lvalue} }
+  v16qi _normal_v4si_ref = normal_v4si_ref; // { dg-error {cannot bind 
non-const lvalue} 

Re: [C++ PATCH] Don't ignore side-effects on decltype(nullptr) typed args passed to ... (PR c++/92992)

2019-12-20 Thread Jason Merrill

On 12/18/19 6:40 PM, Jakub Jelinek wrote:

Hi!

While looking at PR92666, I've spotted a wrong-code issue where we ignore
any side-effects on arguments passed to ellipsis if they have
decltype(nullptr) type.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk and release branches?

2019-12-19  Jakub Jelinek  

PR c++/92992
* call.c (convert_arg_to_ellipsis): For decltype(nullptr) arguments
that have side-effects use cp_build_compound_expr.


OK.


* g++.dg/cpp0x/nullptr45.C: New test.

--- gcc/cp/call.c.jj2019-12-17 10:19:51.013282361 +0100
+++ gcc/cp/call.c   2019-12-18 18:23:01.441357443 +0100
@@ -7822,7 +7822,12 @@ convert_arg_to_ellipsis (tree arg, tsubs
arg = convert_to_real_nofold (double_type_node, arg);
  }
else if (NULLPTR_TYPE_P (arg_type))
-arg = null_pointer_node;
+{
+  if (TREE_SIDE_EFFECTS (arg))
+   arg = cp_build_compound_expr (arg, null_pointer_node, complain);
+  else
+   arg = null_pointer_node;
+}
else if (INTEGRAL_OR_ENUMERATION_TYPE_P (arg_type))
  {
if (SCOPED_ENUM_P (arg_type))
--- gcc/testsuite/g++.dg/cpp0x/nullptr45.C.jj   2019-12-18 18:37:48.537933751 
+0100
+++ gcc/testsuite/g++.dg/cpp0x/nullptr45.C  2019-12-18 18:37:17.290406672 
+0100
@@ -0,0 +1,24 @@
+// PR c++/92992
+// { dg-do run { target c++11 } }
+
+int a;
+
+void
+bar (int, ...)
+{
+}
+
+decltype (nullptr)
+baz ()
+{
+  a++;
+  return nullptr;
+}
+
+int
+main ()
+{
+  bar (0, baz ());
+  if (a != 1)
+__builtin_abort ();
+}

Jakub





Re: [C++ PATCH] PR c++/92745 - bogus error when initializing array of vectors.

2019-12-20 Thread Jason Merrill

On 12/20/19 3:27 PM, Marek Polacek wrote:

In r268428 I changed reshape_init_r in such a way that when it sees
a nested { } in a CONSTRUCTOR with missing braces, it just returns
the initializer:
+ else if (COMPOUND_LITERAL_P (stripped_init)
...
+ ++d->cur;
+ gcc_assert (!BRACE_ENCLOSED_INITIALIZER_P (stripped_init));
+ return init;

But as this test shows, that's incorrect: if TYPE is an array, we need
to proceed to reshape_init_array_1 which will iterate over the array
initializers:
  6006   /* Loop until there are no more initializers.  */
  6007   for (index = 0;
  6008d->cur != d->end && (!sized_array_p || index <= max_index_cst);
  6009++index)
  6010 {
and update d.cur accordingly.  In other words, when reshape_init gets

{{col[0][0], col[1][0], col[2][0], col[3][0]},
  {col[0][1], col[1][1], col[2][1], col[3][1]},
  {col[0][2], col[1][2], col[2][2], col[3][2]},
  {col[0][3], col[1][3], col[2][3], col[3][3]}}

we recurse on the first element:
   {col[0][0], col[1][0], col[2][0], col[3][0]}
and we can't just move d.cur to point to
   {col[0][1], col[1][1], col[2][1], col[3][1]}
and return; we need to iterate, so that d.cur ends up being properly
updated, and after all initializers have been seen, points to d.end.
Currently we skip the loop, wherefore we hit this:

  6502   /* Make sure all the element of the constructor were used. Otherwise,
  6503  issue an error about exceeding initializers.  */
  6504   if (d.cur != d.end)
  6505 {
  6506   if (complain & tf_error)
  6507 error ("too many initializers for %qT", type);
  6508   return error_mark_node;
  6509 }

Bootstrapped/regtested on x86_64-linux, built cmcstl2, ok for trunk
and branches?

2019-12-20  Marek Polacek  

PR c++/92745 - bogus error when initializing array of vectors.
* decl.c (reshape_init_r): For a nested compound literal, do
call reshape_init_{class,array,vector}.

* g++.dg/cpp0x/initlist118.C: New test.

diff --git gcc/cp/decl.c gcc/cp/decl.c
index 7d4c947fb58..c15cbfa3bd3 100644
--- gcc/cp/decl.c
+++ gcc/cp/decl.c
@@ -6399,14 +6399,13 @@ reshape_init_r (tree type, reshape_iter *d, bool 
first_initializer_p,
   by the front end.  Here we have e.g. {.__pfn=0B, .__delta=0},
   which is missing outermost braces.  We should warn below, and
   one of the routines below will wrap it in additional { }.  */;
- /* For a nested compound literal, there is no need to reshape since
-we called reshape_init in finish_compound_literal, before calling
-digest_init.  */
- else if (COMPOUND_LITERAL_P (stripped_init)
-  /* Similarly, a CONSTRUCTOR of the target's type is a
- previously digested initializer.  */
-  || same_type_ignoring_top_level_qualifiers_p (type,
-init_type))
+ /* For a nested compound literal, proceed to specialized routines,
+to handle initialization of arrays and similar.  */
+ else if (COMPOUND_LITERAL_P (stripped_init))
+   gcc_assert (!BRACE_ENCLOSED_INITIALIZER_P (stripped_init));
+ /* A CONSTRUCTOR of the target's type is a previously
+digested initializer.  */
+ else if (same_type_ignoring_top_level_qualifiers_p (type, init_type))
{
  ++d->cur;
  gcc_assert (!BRACE_ENCLOSED_INITIALIZER_P (stripped_init));


Incidentally, asserting !BRACE_ENCLOSED_INITIALIZER_P seems pretty 
pointless, since that checks for init_list_type_node, and a compound 
literal won't have that type, nor will we see that type if we just 
checked that it's something else.


Jason



Re: [C++ PATCH] PR c++/92974 - bogus location for enum and non-enum in ?: warning.

2019-12-20 Thread Jason Merrill

On 12/19/19 6:05 PM, Marek Polacek wrote:

build_min_non_dep wasn't setting any location so when we were emitting the
warning in the following test while instantiating a template, it's location
was UNKNOWN_LOCATION.  Rather than adding a location_t parameter, let's use
the location from the original expression.

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

2019-12-19  Marek Polacek  

PR c++/92974 - bogus location for enum and non-enum in ?: warning.
* tree.c (build_min_non_dep): Use the location of NON_DEP when
building the expression.


OK.


* g++.dg/diagnostic/enum1.C: New test.
* g++.dg/gomp/loop-2.C: Adjust dg-error.
* g++.dg/gomp/for-21.C: Likewise.

diff --git gcc/cp/tree.c gcc/cp/tree.c
index eb3e87fa546..df2470a750b 100644
--- gcc/cp/tree.c
+++ gcc/cp/tree.c
@@ -3356,6 +3356,7 @@ build_min_non_dep (enum tree_code code, tree non_dep, ...)
  non_dep = TREE_OPERAND (non_dep, 0);
  
t = make_node (code);

+  SET_EXPR_LOCATION (t, cp_expr_loc_or_input_loc (non_dep));
length = TREE_CODE_LENGTH (code);
TREE_TYPE (t) = unlowered_expr_type (non_dep);
TREE_SIDE_EFFECTS (t) = TREE_SIDE_EFFECTS (non_dep);
diff --git gcc/testsuite/g++.dg/diagnostic/enum1.C 
gcc/testsuite/g++.dg/diagnostic/enum1.C
new file mode 100644
index 000..e91e970dab4
--- /dev/null
+++ gcc/testsuite/g++.dg/diagnostic/enum1.C
@@ -0,0 +1,14 @@
+// PR c++/92974 - bogus location for enum and non-enum in ?: warning.
+// { dg-options "-Wextra" }
+
+enum { X };
+
+struct S {
+  template 
+  void f(T) { unsigned int g(X ?: g); } // { dg-warning "enumerated and 
non-enumerated type in conditional expression" }
+};
+
+struct S2 {
+  S m;
+  void l() { m.f(1); }
+};
diff --git gcc/testsuite/g++.dg/gomp/for-21.C gcc/testsuite/g++.dg/gomp/for-21.C
index 774f8889759..fbdaa71619a 100644
--- gcc/testsuite/g++.dg/gomp/for-21.C
+++ gcc/testsuite/g++.dg/gomp/for-21.C
@@ -34,8 +34,8 @@ void
  f4 (int a[10][10])
  {
#pragma omp for collapse (2)
-  for (int i = 0; i < 10; ++i)  // { dg-error "initializer expression 
refers to iteration variable 'i'" }
-for (auto j : a[i])
+  for (int i = 0; i < 10; ++i)
+for (auto j : a[i])// { dg-error "initializer expression refers 
to iteration variable 'i'" }
;
  }
  
diff --git gcc/testsuite/g++.dg/gomp/loop-2.C gcc/testsuite/g++.dg/gomp/loop-2.C

index f05a8cbdd4a..9deeaa5d887 100644
--- gcc/testsuite/g++.dg/gomp/loop-2.C
+++ gcc/testsuite/g++.dg/gomp/loop-2.C
@@ -87,16 +87,16 @@ f1 (int x)
  for (j = baz (); j < 16; j += 2) /* { dg-error "initializer expression 
refers to iteration variable" } */
;
#pragma omp for collapse(2)
-  for (i = 0; i < 16; i++) /* { dg-error "condition expression refers to iteration 
variable" } */
-for (j = 16; j > (i & x); j--)
+  for (i = 0; i < 16; i++)
+for (j = 16; j > (i & x); j--) /* { dg-error "condition expression refers to 
iteration variable" } */
;
#pragma omp for collapse(2)
-  for (i = 0; i < 16; i++) /* { dg-error "condition expression refers to iteration 
variable" } */
-for (j = 0; j < i; j++)
+  for (i = 0; i < 16; i++)
+for (j = 0; j < i; j++) /* { dg-error "condition expression refers to iteration 
variable" } */
;
#pragma omp for collapse(2)
-  for (i = 0; i < 16; i++) /* { dg-error "condition expression refers to iteration 
variable" } */
-for (j = 0; j < i + 4; j++)
+  for (i = 0; i < 16; i++)
+for (j = 0; j < i + 4; j++) /* { dg-error "condition expression refers to 
iteration variable" } */
;
#pragma omp for collapse(2)
for (i = 0; i < j + 4; i++) /* { dg-error "condition expression refers to 
iteration variable" } */
@@ -111,8 +111,8 @@ f1 (int x)
  for (j = 0; j < 16; j++)
;
#pragma omp for collapse(2)
-  for (i = 0; i < 16; i++) /* { dg-error "condition expression refers to iteration 
variable" } */
-for (j = 0; j < baz (); j++)
+  for (i = 0; i < 16; i++)
+for (j = 0; j < baz (); j++) /* { dg-error "condition expression refers to 
iteration variable" } */
;
#pragma omp for collapse(2)
for (i = 0; i < 16; i += j) /* { dg-error "increment expression refers to 
iteration variable" } */
@@ -221,20 +221,20 @@ f2 (int x)
  for (int j = baz (); j < 16; j += 2) /* { dg-error "initializer expression 
refers to iteration variable" } */
;
#pragma omp for collapse(2)
-  for (int i = 0; i < 16; i++) /* { dg-error "condition expression refers to 
iteration variable" } */
-for (int j = 16; j > (i & x); j--)
+  for (int i = 0; i < 16; i++)
+for (int j = 16; j > (i & x); j--) /* { dg-error "condition expression refers 
to iteration variable" } */
;
#pragma omp for collapse(2)
-  for (int i = 0; i < 16; i++) /* { dg-error "condition expression refers to 
iteration variable" } */
-for (int j = 0; j < i; j++)
+  for (int i = 0; i < 16; i++)
+for (int j = 0; j < i; j++) /* { dg-error 

Re: [C++ PATCH] PR c++/92745 - bogus error when initializing array of vectors.

2019-12-20 Thread Jason Merrill

On 12/20/19 3:27 PM, Marek Polacek wrote:

In r268428 I changed reshape_init_r in such a way that when it sees
a nested { } in a CONSTRUCTOR with missing braces, it just returns
the initializer:
+ else if (COMPOUND_LITERAL_P (stripped_init)
...
+ ++d->cur;
+ gcc_assert (!BRACE_ENCLOSED_INITIALIZER_P (stripped_init));
+ return init;

But as this test shows, that's incorrect: if TYPE is an array, we need
to proceed to reshape_init_array_1 which will iterate over the array
initializers:
  6006   /* Loop until there are no more initializers.  */
  6007   for (index = 0;
  6008d->cur != d->end && (!sized_array_p || index <= max_index_cst);
  6009++index)
  6010 {
and update d.cur accordingly.  In other words, when reshape_init gets

{{col[0][0], col[1][0], col[2][0], col[3][0]},
  {col[0][1], col[1][1], col[2][1], col[3][1]},
  {col[0][2], col[1][2], col[2][2], col[3][2]},
  {col[0][3], col[1][3], col[2][3], col[3][3]}}

we recurse on the first element:
   {col[0][0], col[1][0], col[2][0], col[3][0]}
and we can't just move d.cur to point to
   {col[0][1], col[1][1], col[2][1], col[3][1]}
and return; we need to iterate, so that d.cur ends up being properly
updated, and after all initializers have been seen, points to d.end.
Currently we skip the loop, wherefore we hit this:

  6502   /* Make sure all the element of the constructor were used. Otherwise,
  6503  issue an error about exceeding initializers.  */
  6504   if (d.cur != d.end)
  6505 {
  6506   if (complain & tf_error)
  6507 error ("too many initializers for %qT", type);
  6508   return error_mark_node;
  6509 }

Bootstrapped/regtested on x86_64-linux, built cmcstl2, ok for trunk
and branches?


OK.


2019-12-20  Marek Polacek  

PR c++/92745 - bogus error when initializing array of vectors.
* decl.c (reshape_init_r): For a nested compound literal, do
call reshape_init_{class,array,vector}.

* g++.dg/cpp0x/initlist118.C: New test.

diff --git gcc/cp/decl.c gcc/cp/decl.c
index 7d4c947fb58..c15cbfa3bd3 100644
--- gcc/cp/decl.c
+++ gcc/cp/decl.c
@@ -6399,14 +6399,13 @@ reshape_init_r (tree type, reshape_iter *d, bool 
first_initializer_p,
   by the front end.  Here we have e.g. {.__pfn=0B, .__delta=0},
   which is missing outermost braces.  We should warn below, and
   one of the routines below will wrap it in additional { }.  */;
- /* For a nested compound literal, there is no need to reshape since
-we called reshape_init in finish_compound_literal, before calling
-digest_init.  */
- else if (COMPOUND_LITERAL_P (stripped_init)
-  /* Similarly, a CONSTRUCTOR of the target's type is a
- previously digested initializer.  */
-  || same_type_ignoring_top_level_qualifiers_p (type,
-init_type))
+ /* For a nested compound literal, proceed to specialized routines,
+to handle initialization of arrays and similar.  */
+ else if (COMPOUND_LITERAL_P (stripped_init))
+   gcc_assert (!BRACE_ENCLOSED_INITIALIZER_P (stripped_init));
+ /* A CONSTRUCTOR of the target's type is a previously
+digested initializer.  */
+ else if (same_type_ignoring_top_level_qualifiers_p (type, init_type))
{
  ++d->cur;
  gcc_assert (!BRACE_ENCLOSED_INITIALIZER_P (stripped_init));
diff --git gcc/testsuite/g++.dg/cpp0x/initlist118.C 
gcc/testsuite/g++.dg/cpp0x/initlist118.C
new file mode 100644
index 000..2e1b96953e3
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp0x/initlist118.C
@@ -0,0 +1,25 @@
+// PR c++/92745 - bogus error when initializing array of vectors.
+// { dg-do compile { target c++11 } }
+
+template  struct c {
+  typedef a d[b];
+};
+
+template  struct array {
+  typename c::d e;
+  a operator[](long);
+};
+
+template
+using vec4_t __attribute__((vector_size(4*sizeof(T = float;
+
+array, 4>
+transpose(array, 4> col)
+{
+  array, 4>
+ret{vec4_t{col[0][0], col[1][0], col[2][0], col[3][0]},
+vec4_t{col[0][1], col[1][1], col[2][1], col[3][1]},
+vec4_t{col[0][2], col[1][2], col[2][2], col[3][2]},
+vec4_t{col[0][3], col[1][3], col[2][3], col[3][3]}};
+  return ret;
+}





[Patch] PR92990 - fix error message for invalid argument of NULLIFY

2019-12-20 Thread Harald Anlauf
The fix for PR70853 changed an ICE-on-invalid for NULLIFY into a
misleading error message.  The patch below rectifies that.

OK for trunk?

Regtested on x86_64-pc-linux-gnu.

Thanks,
Harald

Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c (Revision 279645)
+++ gcc/fortran/match.c (Arbeitskopie)
@@ -4588,6 +4588,23 @@ gfc_match_nullify (void)
  goto cleanup;
}

+  /* Check for valid array pointer object.  Bounds remapping is not
+allowed with NULLIFY.  */
+  if (p->ref)
+   {
+ gfc_ref *remap = p->ref;
+ for (; remap; remap = remap->next)
+   if (!remap->next && remap->type == REF_ARRAY
+   && remap->u.ar.type != AR_FULL)
+ break;
+ if (remap)
+   {
+ gfc_error ("NULLIFY does not allow bounds remapping for "
+"pointer object at %C");
+ goto cleanup;
+   }
+   }
+
   /* build ' => NULL() '.  */
   e = gfc_get_null_expr (_current_locus);

Index: gcc/testsuite/gfortran.dg/pr92990.f90
===
--- gcc/testsuite/gfortran.dg/pr92990.f90   (nicht existent)
+++ gcc/testsuite/gfortran.dg/pr92990.f90   (Arbeitskopie)
@@ -0,0 +1,12 @@
+! { dg-do compile }
+! PR fortran/92990
+! Verify fix of error message for NULLIFY vs. pointer assignment (PR70853)
+program p
+  integer, pointer :: x(:)
+  type t
+ integer, pointer :: y(:)
+  end type t
+  type(t) :: z
+  nullify (x(1:2)) ! { dg-error "does not allow bounds remapping" }
+  nullify (z%y(:)) ! { dg-error "does not allow bounds remapping" }
+end


2019-12-20  Harald Anlauf  

PR fortran/92990
* match.c (gfc_match_nullify): Check for valid pointer object.
Reject bounds remapping.


2019-12-20  Harald Anlauf  

PR fortran/92990
* gfortran.dg/pr92990.f90: New test.



[C++ PATCH] PR c++/92745 - bogus error when initializing array of vectors.

2019-12-20 Thread Marek Polacek
In r268428 I changed reshape_init_r in such a way that when it sees
a nested { } in a CONSTRUCTOR with missing braces, it just returns
the initializer:
+ else if (COMPOUND_LITERAL_P (stripped_init)
...
+ ++d->cur;
+ gcc_assert (!BRACE_ENCLOSED_INITIALIZER_P (stripped_init));
+ return init;

But as this test shows, that's incorrect: if TYPE is an array, we need
to proceed to reshape_init_array_1 which will iterate over the array
initializers:
 6006   /* Loop until there are no more initializers.  */
 6007   for (index = 0;
 6008d->cur != d->end && (!sized_array_p || index <= max_index_cst);
 6009++index)
 6010 {
and update d.cur accordingly.  In other words, when reshape_init gets

{{col[0][0], col[1][0], col[2][0], col[3][0]},
 {col[0][1], col[1][1], col[2][1], col[3][1]},
 {col[0][2], col[1][2], col[2][2], col[3][2]},
 {col[0][3], col[1][3], col[2][3], col[3][3]}}

we recurse on the first element:
  {col[0][0], col[1][0], col[2][0], col[3][0]}
and we can't just move d.cur to point to
  {col[0][1], col[1][1], col[2][1], col[3][1]}
and return; we need to iterate, so that d.cur ends up being properly
updated, and after all initializers have been seen, points to d.end.
Currently we skip the loop, wherefore we hit this:

 6502   /* Make sure all the element of the constructor were used. Otherwise,
 6503  issue an error about exceeding initializers.  */
 6504   if (d.cur != d.end)
 6505 {
 6506   if (complain & tf_error)
 6507 error ("too many initializers for %qT", type);
 6508   return error_mark_node;
 6509 }

Bootstrapped/regtested on x86_64-linux, built cmcstl2, ok for trunk
and branches?

2019-12-20  Marek Polacek  

PR c++/92745 - bogus error when initializing array of vectors.
* decl.c (reshape_init_r): For a nested compound literal, do
call reshape_init_{class,array,vector}.

* g++.dg/cpp0x/initlist118.C: New test.

diff --git gcc/cp/decl.c gcc/cp/decl.c
index 7d4c947fb58..c15cbfa3bd3 100644
--- gcc/cp/decl.c
+++ gcc/cp/decl.c
@@ -6399,14 +6399,13 @@ reshape_init_r (tree type, reshape_iter *d, bool 
first_initializer_p,
   by the front end.  Here we have e.g. {.__pfn=0B, .__delta=0},
   which is missing outermost braces.  We should warn below, and
   one of the routines below will wrap it in additional { }.  */;
- /* For a nested compound literal, there is no need to reshape since
-we called reshape_init in finish_compound_literal, before calling
-digest_init.  */
- else if (COMPOUND_LITERAL_P (stripped_init)
-  /* Similarly, a CONSTRUCTOR of the target's type is a
- previously digested initializer.  */
-  || same_type_ignoring_top_level_qualifiers_p (type,
-init_type))
+ /* For a nested compound literal, proceed to specialized routines,
+to handle initialization of arrays and similar.  */
+ else if (COMPOUND_LITERAL_P (stripped_init))
+   gcc_assert (!BRACE_ENCLOSED_INITIALIZER_P (stripped_init));
+ /* A CONSTRUCTOR of the target's type is a previously
+digested initializer.  */
+ else if (same_type_ignoring_top_level_qualifiers_p (type, init_type))
{
  ++d->cur;
  gcc_assert (!BRACE_ENCLOSED_INITIALIZER_P (stripped_init));
diff --git gcc/testsuite/g++.dg/cpp0x/initlist118.C 
gcc/testsuite/g++.dg/cpp0x/initlist118.C
new file mode 100644
index 000..2e1b96953e3
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp0x/initlist118.C
@@ -0,0 +1,25 @@
+// PR c++/92745 - bogus error when initializing array of vectors.
+// { dg-do compile { target c++11 } }
+
+template  struct c {
+  typedef a d[b];
+};
+
+template  struct array {
+  typename c::d e;
+  a operator[](long);
+};
+
+template
+using vec4_t __attribute__((vector_size(4*sizeof(T = float;
+
+array, 4>
+transpose(array, 4> col)
+{
+  array, 4>
+ret{vec4_t{col[0][0], col[1][0], col[2][0], col[3][0]},
+vec4_t{col[0][1], col[1][1], col[2][1], col[3][1]},
+vec4_t{col[0][2], col[1][2], col[2][2], col[3][2]},
+vec4_t{col[0][3], col[1][3], col[2][3], col[3][3]}};
+  return ret;
+}



[PATCH 2/2] analyzer: fix tests for UNKNOWN_LOCATION

2019-12-20 Thread David Malcolm
In the reproducer for PR analyzer/58237 I noticed that some events were
missing locations (and text); for example event 3 here:

|   15 |   while (fgets(buf, 10, fp) != NULL)
|  | ~
|  | |
|  | (2) following 'false' branch...
|
  'f1': event 3
|
|cc1:
|
  'f1': event 4
|
|:19:1:
|   19 | }
|  | ^
|  | |
|  | (4) 'fp' leaks here; was opened at (1)
|

The root cause is that various places in the analyzer compare locations
against UNKNOWN_LOCATION, which fails to detect an unknown location for
the case where an unknown_location has been wrapped into an ad-hoc
location to record a block.

This patch fixes the issue by using get_pure_location whenever testing
against UNKNOWN_LOCATION to look through ad-hoc wrappers.

For the case above, it thus picks a better location in
supernode::get_start_location for event (3) above, improving it to:

|   15 |   while (fgets(buf, 10, fp) != NULL)
|  | ~
|  | |
|  | (2) following 'false' branch...
|..
|   19 | }
|  | ~
|  | |
|  | (3) ...to here
|  | (4) 'fp' leaks here; was opened at (1)
|

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to the dmalcolm/analyzer branch on the GCC git mirror.

gcc/analyzer/ChangeLog:
PR analyzer/58237
* engine.cc (leak_stmt_finder::find_stmt): Use get_pure_location
when comparing against UNKNOWN_LOCATION.
(stmt_requires_new_enode_p): Likewise.
(exploded_graph::dump_exploded_nodes): Likewise.
* supergraph.cc (supernode::get_start_location): Likewise.
(supernode::get_end_location): Likewise.

gcc/testsuite/ChangeLog:
PR analyzer/58237
* gcc.dg/analyzer/file-paths-1.c: New test.
---
 gcc/analyzer/engine.cc   |  8 +++
 gcc/analyzer/supergraph.cc   | 10 
 gcc/testsuite/gcc.dg/analyzer/file-paths-1.c | 25 
 3 files changed, 35 insertions(+), 8 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/file-paths-1.c

diff --git a/gcc/analyzer/engine.cc b/gcc/analyzer/engine.cc
index 162940a2bfa9..6bbedc2072e6 100644
--- a/gcc/analyzer/engine.cc
+++ b/gcc/analyzer/engine.cc
@@ -388,7 +388,7 @@ public:
const program_point _point = dst_node->get_point ();
const gimple *stmt = dst_point.get_stmt ();
if (stmt)
- if (stmt->location != UNKNOWN_LOCATION)
+ if (get_pure_location (stmt->location) != UNKNOWN_LOCATION)
return stmt;
   }
 
@@ -2270,8 +2270,8 @@ stmt_requires_new_enode_p (const gimple *stmt,
  could be consolidated into PREV_STMT, giving us an event with
  no location.  Ensure that STMT gets its own exploded_node to
  avoid this.  */
-  if (prev_stmt->location == UNKNOWN_LOCATION
-  && stmt->location != UNKNOWN_LOCATION)
+  if (get_pure_location (prev_stmt->location) == UNKNOWN_LOCATION
+  && get_pure_location (stmt->location) != UNKNOWN_LOCATION)
 return true;
 
   return false;
@@ -3067,7 +3067,7 @@ exploded_graph::dump_exploded_nodes () const
{
  if (const gimple *stmt = enode->get_stmt ())
{
- if (richloc.get_loc () == UNKNOWN_LOCATION)
+ if (get_pure_location (richloc.get_loc ()) == UNKNOWN_LOCATION)
richloc.set_range (0, stmt->location, SHOW_RANGE_WITH_CARET);
  else
richloc.add_range (stmt->location,
diff --git a/gcc/analyzer/supergraph.cc b/gcc/analyzer/supergraph.cc
index 59c9264d5a08..ba7f7c6d2994 100644
--- a/gcc/analyzer/supergraph.cc
+++ b/gcc/analyzer/supergraph.cc
@@ -525,13 +525,14 @@ supernode::dump_dot_id (pretty_printer *pp) const
 location_t
 supernode::get_start_location () const
 {
-  if (m_returning_call && m_returning_call->location != UNKNOWN_LOCATION)
+  if (m_returning_call
+  && get_pure_location (m_returning_call->location) != UNKNOWN_LOCATION)
 return m_returning_call->location;
 
   int i;
   gimple *stmt;
   FOR_EACH_VEC_ELT (m_stmts, i, stmt)
-if (stmt->location != UNKNOWN_LOCATION)
+if (get_pure_location (stmt->location) != UNKNOWN_LOCATION)
   return stmt->location;
 
   if (entry_p ())
@@ -555,10 +556,11 @@ supernode::get_end_location () const
   int i;
   gimple *stmt;
   FOR_EACH_VEC_ELT_REVERSE (m_stmts, i, stmt)
-if (stmt->location != UNKNOWN_LOCATION)
+if (get_pure_location (stmt->location) != UNKNOWN_LOCATION)
   return stmt->location;
 
-  if (m_returning_call && m_returning_call->location != UNKNOWN_LOCATION)
+  if (m_returning_call
+  && get_pure_location (m_returning_call->location) != UNKNOWN_LOCATION)
 return m_returning_call->location;
 
   if (entry_p ())
diff --git a/gcc/testsuite/gcc.dg/analyzer/file-paths-1.c 
b/gcc/testsuite/gcc.dg/analyzer/file-paths-1.c
new file mode 100644
index ..1c8bf61dd3fd
--- 

[PATCH 1/2] (analyzer) tree-diagnostic-path.cc: properly handle ad-hoc wrappers of UNKNOWN_LOCATION

2019-12-20 Thread David Malcolm
In the reproducer for PR analyzer/58237 I noticed that some events that
were missing locations were also missing text; for example event 3 here:

|   15 |   while (fgets(buf, 10, fp) != NULL)
|  | ~
|  | |
|  | (2) following 'false' branch...
|
  'f1': event 3
|
|cc1:
|

The root cause is that the path_summary-printing code doesn't consider
ad-hoc locations when looking for reserved locations, and so fails to
detect an unknown location for the case where an unknown location has
been wrapped into an ad-hoc location to record a block.

This patch fixes the issue by using get_pure_location, thus looking
through ad-hoc wrappers, improving the result to:

|   15 |   while (fgets(buf, 10, fp) != NULL)
|  | ~
|  | |
|  | (2) following 'false' branch...
|
  'f1': event 3
|
|cc1:
| (3): ...to here
|

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to the dmalcolm/analyzer branch on the GCC git mirror.

gcc/ChangeLog:
* tree-diagnostic-path.cc (path_summary::event_range::print):
When testing for UNKNOWN_LOCATION, look through ad-hoc wrappers
using get_pure_location.
---
 gcc/tree-diagnostic-path.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/tree-diagnostic-path.cc b/gcc/tree-diagnostic-path.cc
index 243f05a5fb14..32dc054519b7 100644
--- a/gcc/tree-diagnostic-path.cc
+++ b/gcc/tree-diagnostic-path.cc
@@ -172,7 +172,7 @@ class path_summary
 In particular the label for the event won't get printed.
 Fail more gracefully in this case by showing the event
 index and text, at no particular location.  */
-  if (initial_loc <= BUILTINS_LOCATION)
+  if (get_pure_location (initial_loc) <= BUILTINS_LOCATION)
{
  for (unsigned i = m_start_idx; i <= m_end_idx; i++)
{
-- 
2.21.0



ACLE intrinsics: BFloat16 load intrinsics for AArch32

2019-12-20 Thread Delia Burduv
This patch adds the ARMv8.6 ACLE BFloat16 load intrinsics vld{q}_bf16 
as part of the BFloat16 extension.
(https://developer.arm.com/architectures/instruction-sets/simd-isas/neon/intrinsics)
The intrinsics are declared in arm_neon.h .
A new test is added to check assembler output.

This patch depends on the Arm back-end patche. 
(https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01448.html)

Tested for regression on arm-none-eabi and armeb-none-eabi. I don't have 
commit rights, so if this is ok can someone please commit it for me?

gcc/ChangeLog:

2019-11-14  Delia Burduv  

* config/arm/arm_neon.h (bfloat16_t): New typedef.
 (bfloat16x4x2_t): New typedef.
 (bfloat16x8x2_t): New typedef.
 (bfloat16x4x3_t): New typedef.
 (bfloat16x8x3_t): New typedef.
 (bfloat16x4x4_t): New typedef.
 (bfloat16x8x4_t): New typedef.
 (vld2_bf16): New.
(vld2q_bf16): New.
(vld3_bf16): New.
(vld3q_bf16): New.
(vld4_bf16): New.
(vld4q_bf16): New.
(vld2_dup_bf16): New.
(vld2q_dup_bf16): New.
(vld3_dup_bf16): New.
(vld3q_dup_bf16): New.
(vld4_dup_bf16): New.
(vld4q_dup_bf16): New.
 * config/arm/arm-builtins.c (E_V2BFmode): New mode.
 (VAR13): New.
 (arm_simd_types[Bfloat16x2_t]):New type.
 * config/arm/arm-modes.def (V2BF): New mode.
 * config/arm/arm-simd-builtin-types.def
 (Bfloat16x2_t): New entry.
 * config/arm/arm_neon_builtins.def
 (vld2): Changed to VAR13 and added v4bf, v8bf
 (vld2_dup): Changed to VAR8 and added v4bf, v8bf
 (vld3): Changed to VAR13 and added v4bf, v8bf
 (vld3_dup): Changed to VAR8 and added v4bf, v8bf
 (vld4): Changed to VAR13 and added v4bf, v8bf
 (vld4_dup): Changed to VAR8 and added v4bf, v8bf
 * config/arm/iterators.md (VDXBF): New iterator.
 (VQ2BF): New iterator.
 (V_elem): Added V4BF, V8BF.
 (V_sz_elem): Added V4BF, V8BF.
 (V_mode_nunits): Added V4BF, V8BF.
 (q): Added V4BF, V8BF.
 *config/arm/neon.md (vld2): Used new iterators.
 (vld2_dup): Used new iterators.
 (vld2_dupv8bf): New.
 (vst3): Used new iterators.
 (vst3qa): Used new iterators.
 (vst3qb): Used new iterators.
 (vld3_dup): Used new iterators.
 (vld3_dupv8bf): New.
 (vst4): Used new iterators.
 (vst4qa): Used new iterators.
 (vst4qb): Used new iterators.
 (vld4_dup): Used new iterators.
 (vld4_dupv8bf): New.


gcc/testsuite/ChangeLog:

2019-11-14  Delia Burduv  

* gcc.target/arm/simd/bf16_vldn_1.c: New test.
diff --git a/gcc/config/arm/arm-builtins.c b/gcc/config/arm/arm-builtins.c
index df09a6bb1fce5f9216337d71cba51a890fd57baf..551d76a44fadc58a35a6155486ec1fb16c959da0 100644
--- a/gcc/config/arm/arm-builtins.c
+++ b/gcc/config/arm/arm-builtins.c
@@ -318,6 +318,7 @@ arm_set_sat_qualifiers[SIMD_MAX_BUILTIN_ARGS]
 #define v4bf_UP  E_V4BFmode
 #define v2si_UP  E_V2SImode
 #define v2sf_UP  E_V2SFmode
+#define v2bf_UP  E_V2BFmode
 #define di_UPE_DImode
 #define v16qi_UP E_V16QImode
 #define v8hi_UP  E_V8HImode
@@ -381,6 +382,9 @@ typedef struct {
 #define VAR12(T, N, A, B, C, D, E, F, G, H, I, J, K, L) \
   VAR11 (T, N, A, B, C, D, E, F, G, H, I, J, K) \
   VAR1 (T, N, L)
+#define VAR13(T, N, A, B, C, D, E, F, G, H, I, J, K, L, M) \
+  VAR12 (T, N, A, B, C, D, E, F, G, H, I, J, K, L) \
+  VAR1 (T, N, M)
 
 /* The builtin data can be found in arm_neon_builtins.def, arm_vfp_builtins.def
and arm_acle_builtins.def.  The entries in arm_neon_builtins.def require
@@ -1013,6 +1017,7 @@ arm_init_simd_builtin_types (void)
   arm_simd_types[Float32x4_t].eltype = float_type_node;
 
   /* Init Bfloat vector types with underlying __bf16 scalar type.  */
+  arm_simd_types[Bfloat16x2_t].eltype = arm_bf16_type_node;
   arm_simd_types[Bfloat16x4_t].eltype = arm_bf16_type_node;
   arm_simd_types[Bfloat16x8_t].eltype = arm_bf16_type_node;
 
diff --git a/gcc/config/arm/arm-modes.def b/gcc/config/arm/arm-modes.def
index 80c3c1a6eb258d116b07ad71fafafc9befb76e8b..9533d177059d98fa2a9e9d1d6321f3d92dad7592 100644
--- a/gcc/config/arm/arm-modes.def
+++ b/gcc/config/arm/arm-modes.def
@@ -80,6 +80,7 @@ VECTOR_MODE (FLOAT, HF, 2);   /* V2HF */
 
 FLOAT_MODE (BF, 2, 0);
 ADJUST_FLOAT_FORMAT (BF, _bfloat_half_format);
+VECTOR_MODE (FLOAT, BF, 2);   /* V2BF.  */
 VECTOR_MODE (FLOAT, BF, 4);   /*		 V4BF.  */
 VECTOR_MODE (FLOAT, BF, 8);   /*		 V8BF.  */
 
diff --git a/gcc/config/arm/arm-simd-builtin-types.def b/gcc/config/arm/arm-simd-builtin-types.def
index ee240f85c5618417fff039ec43b81641b187c126..f52f679156d5041ab109909393dc37fda33a390d 100644
--- a/gcc/config/arm/arm-simd-builtin-types.def
+++ b/gcc/config/arm/arm-simd-builtin-types.def
@@ -48,5 +48,6 @@
   ENTRY (Float16x8_t, V8HF, none, 128, float16, 19)
   ENTRY 

ACLE intrinsics: BFloat16 store (vst{q}_bf16) intrinsics for AArch32

2019-12-20 Thread Delia Burduv
This patch adds the ARMv8.6 ACLE BFloat16 store intrinsics 
vst{q}_bf16 as part of the BFloat16 extension.
(https://developer.arm.com/architectures/instruction-sets/simd-isas/neon/intrinsics)
The intrinsics are declared in arm_neon.h .
A new test is added to check assembler output.

This patch depends on the Arm back-end patche. 
(https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01448.html)

Tested for regression on arm-none-eabi and armeb-none-eabi. I don't have 
commit rights, so if this is ok can someone please commit it for me?

gcc/ChangeLog:

2019-11-14  Delia Burduv  

* config/arm/arm_neon.h (bfloat16_t): New typedef.
 (bfloat16x4x2_t): New typedef.
 (bfloat16x8x2_t): New typedef.
 (bfloat16x4x3_t): New typedef.
 (bfloat16x8x3_t): New typedef.
 (bfloat16x4x4_t): New typedef.
 (bfloat16x8x4_t): New typedef.
 (vst2_bf16): New.
(vst2q_bf16): New.
(vst3_bf16): New.
(vst3q_bf16): New.
(vst4_bf16): New.
(vst4q_bf16): New.
 * config/arm/arm-builtins.c (E_V2BFmode): New mode.
 (VAR13): New.
 (arm_simd_types[Bfloat16x2_t]):New type.
 * config/arm/arm-modes.def (V2BF): New mode.
 * config/arm/arm-simd-builtin-types.def
 (Bfloat16x2_t): New entry.
 * config/arm/arm_neon_builtins.def
 (vst2): Changed to VAR13 and added v4bf, v8bf
 (vst3): Changed to VAR13 and added v4bf, v8bf
 (vst4): Changed to VAR13 and added v4bf, v8bf
 * config/arm/iterators.md (VDXBF): New iterator.
 (VQ2BF): New iterator.
 (V_elem): Added V4BF, V8BF.
 (V_sz_elem): Added V4BF, V8BF.
 (V_mode_nunits): Added V4BF, V8BF.
 (q): Added V4BF, V8BF.
 *config/arm/neon.md (vst2): Used new iterators.
 (vst3): Used new iterators.
 (vst3qa): Used new iterators.
 (vst3qb): Used new iterators.
 (vst4): Used new iterators.
 (vst4qa): Used new iterators.
 (vst4qb): Used new iterators.


gcc/testsuite/ChangeLog:

2019-11-14  Delia Burduv  

* gcc.target/arm/simd/bf16_vstn_1.c: New test.
diff --git a/gcc/config/arm/arm-builtins.c b/gcc/config/arm/arm-builtins.c
index df09a6bb1fce5f9216337d71cba51a890fd57baf..551d76a44fadc58a35a6155486ec1fb16c959da0 100644
--- a/gcc/config/arm/arm-builtins.c
+++ b/gcc/config/arm/arm-builtins.c
@@ -318,6 +318,7 @@ arm_set_sat_qualifiers[SIMD_MAX_BUILTIN_ARGS]
 #define v4bf_UP  E_V4BFmode
 #define v2si_UP  E_V2SImode
 #define v2sf_UP  E_V2SFmode
+#define v2bf_UP  E_V2BFmode
 #define di_UPE_DImode
 #define v16qi_UP E_V16QImode
 #define v8hi_UP  E_V8HImode
@@ -381,6 +382,9 @@ typedef struct {
 #define VAR12(T, N, A, B, C, D, E, F, G, H, I, J, K, L) \
   VAR11 (T, N, A, B, C, D, E, F, G, H, I, J, K) \
   VAR1 (T, N, L)
+#define VAR13(T, N, A, B, C, D, E, F, G, H, I, J, K, L, M) \
+  VAR12 (T, N, A, B, C, D, E, F, G, H, I, J, K, L) \
+  VAR1 (T, N, M)
 
 /* The builtin data can be found in arm_neon_builtins.def, arm_vfp_builtins.def
and arm_acle_builtins.def.  The entries in arm_neon_builtins.def require
@@ -1013,6 +1017,7 @@ arm_init_simd_builtin_types (void)
   arm_simd_types[Float32x4_t].eltype = float_type_node;
 
   /* Init Bfloat vector types with underlying __bf16 scalar type.  */
+  arm_simd_types[Bfloat16x2_t].eltype = arm_bf16_type_node;
   arm_simd_types[Bfloat16x4_t].eltype = arm_bf16_type_node;
   arm_simd_types[Bfloat16x8_t].eltype = arm_bf16_type_node;
 
diff --git a/gcc/config/arm/arm-modes.def b/gcc/config/arm/arm-modes.def
index 80c3c1a6eb258d116b07ad71fafafc9befb76e8b..9533d177059d98fa2a9e9d1d6321f3d92dad7592 100644
--- a/gcc/config/arm/arm-modes.def
+++ b/gcc/config/arm/arm-modes.def
@@ -80,6 +80,7 @@ VECTOR_MODE (FLOAT, HF, 2);   /* V2HF */
 
 FLOAT_MODE (BF, 2, 0);
 ADJUST_FLOAT_FORMAT (BF, _bfloat_half_format);
+VECTOR_MODE (FLOAT, BF, 2);   /* V2BF.  */
 VECTOR_MODE (FLOAT, BF, 4);   /*		 V4BF.  */
 VECTOR_MODE (FLOAT, BF, 8);   /*		 V8BF.  */
 
diff --git a/gcc/config/arm/arm-simd-builtin-types.def b/gcc/config/arm/arm-simd-builtin-types.def
index ee240f85c5618417fff039ec43b81641b187c126..f52f679156d5041ab109909393dc37fda33a390d 100644
--- a/gcc/config/arm/arm-simd-builtin-types.def
+++ b/gcc/config/arm/arm-simd-builtin-types.def
@@ -48,5 +48,6 @@
   ENTRY (Float16x8_t, V8HF, none, 128, float16, 19)
   ENTRY (Float32x4_t, V4SF, none, 128, float32, 19)
 
+  ENTRY (Bfloat16x2_t, V2BF, none, 32, bfloat16, 20)
   ENTRY (Bfloat16x4_t, V4BF, none, 64, bfloat16, 20)
   ENTRY (Bfloat16x8_t, V8BF, none, 128, bfloat16, 20)
diff --git a/gcc/config/arm/arm_neon.h b/gcc/config/arm/arm_neon.h
index 71e7568e4315a9354062dee5442ca4af9d9660a9..2bed33800facb65c20ea95646a5c4053dd5673de 100644
--- a/gcc/config/arm/arm_neon.h
+++ b/gcc/config/arm/arm_neon.h
@@ -91,6 +91,85 @@ typedef float float32_t;
 #ifdef __ARM_FEATURE_BF16_VECTOR_ARITHMETIC
 typedef __simd128_bfloat16_t bfloat16x8_t;
 typedef 

[GCC][PATCH][AArch32] ACLE intrinsics bfloat16 vmmla and vfma for AArch32 AdvSIMD

2019-12-20 Thread Delia Burduv
This patch adds the ARMv8.6 ACLE intrinsics for vmmla, vfmab and vfmat 
as part of the BFloat16 extension.
(https://developer.arm.com/docs/101028/latest.)
The intrinsics are declared in arm_neon.h and the RTL patterns are 
defined in neon.md.
Two new tests are added to check assembler output and lane indices.

This patch depends on the Arm back-end patche. 
(https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01448.html)

Tested for regression on arm-none-eabi and armeb-none-eabi. I don't have 
commit rights, so if this is ok can someone please commit it for me?

gcc/ChangeLog:

2019-11-12  Delia Burduv  

* config/arm/arm_neon.h (vbfmmlaq_f32): New.
  (vbfmlalbq_f32): New.
  (vbfmlaltq_f32): New.
  (vbfmlalbq_lane_f32): New.
  (vbfmlaltq_lane_f32): New.
  (vbfmlalbq_laneq_f32): New.
  (vbfmlaltq_laneq_f32): New.
* config/arm/arm_neon_builtins.def (vbfmmla): New.
   (vbfmab): New.
   (vbfmat): New.
   (vbfmab_lane): New.
   (vbfmat_lane): New.
   (vbfmab_laneq): New.
   (vbfmat_laneq): New.
* config/arm/iterators.md (BF_MA): New int iterator.
   (bt): New int attribute.
   (VQXBF): Copy of VQX with V8BF.
   (V_HALF): Added V8BF.
* config/arm/neon.md (neon_vbfmmlav8hi): New insn.
   (neon_vbfmav8hi): New insn.
   (neon_vbfma_lanev8hi): New insn.
   (neon_vbfma_laneqv8hi): New expand.
   (neon_vget_high): Changed iterator to VQXBF.
* config/arm/unspecs.md (UNSPEC_BFMMLA): New UNSPEC.
   (UNSPEC_BFMAB): New UNSPEC.
   (UNSPEC_BFMAT): New UNSPEC.

2019-11-12  Delia Burduv  

 * gcc.target/arm/simd/bf16_ma_1.c: New test.
 * gcc.target/arm/simd/bf16_ma_2.c: New test.
 * gcc.target/arm/simd/bf16_mmla_1.c: New test.
diff --git a/gcc/config/arm/arm_neon.h b/gcc/config/arm/arm_neon.h
index 71e7568e4315a9354062dee5442ca4af9d9660a9..097d7bb30ad0109ca2f41885206b1cfb2ce962dc 100644
--- a/gcc/config/arm/arm_neon.h
+++ b/gcc/config/arm/arm_neon.h
@@ -91,6 +91,60 @@ typedef float float32_t;
 #ifdef __ARM_FEATURE_BF16_VECTOR_ARITHMETIC
 typedef __simd128_bfloat16_t bfloat16x8_t;
 typedef __simd64_bfloat16_t bfloat16x4_t;
+
+__extension__ extern __inline float32x4_t
+__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
+vbfmmlaq_f32 (float32x4_t __r, bfloat16x8_t __a, bfloat16x8_t __b)
+{
+  return __builtin_neon_vbfmmlav8bf (__r, __a, __b);
+}
+
+__extension__ extern __inline float32x4_t
+__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
+vbfmlalbq_f32 (float32x4_t __r, bfloat16x8_t __a, bfloat16x8_t __b)
+{
+  return __builtin_neon_vbfmabv8bf (__r, __a, __b);
+}
+
+__extension__ extern __inline float32x4_t
+__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
+vbfmlaltq_f32 (float32x4_t __r, bfloat16x8_t __a, bfloat16x8_t __b)
+{
+  return __builtin_neon_vbfmatv8bf (__r, __a, __b);
+}
+
+__extension__ extern __inline float32x4_t
+__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
+vbfmlalbq_lane_f32 (float32x4_t __r, bfloat16x8_t __a, bfloat16x4_t __b,
+		const int __index)
+{
+  return __builtin_neon_vbfmab_lanev8bf (__r, __a, __b, __index);
+}
+
+__extension__ extern __inline float32x4_t
+__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
+vbfmlaltq_lane_f32 (float32x4_t __r, bfloat16x8_t __a, bfloat16x4_t __b,
+		const int __index)
+{
+  return __builtin_neon_vbfmat_lanev8bf (__r, __a, __b, __index);
+}
+
+__extension__ extern __inline float32x4_t
+__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
+vbfmlalbq_laneq_f32 (float32x4_t __r, bfloat16x8_t __a, bfloat16x8_t __b,
+		 const int __index)
+{
+  return __builtin_neon_vbfmab_laneqv8bf (__r, __a, __b, __index);
+}
+
+__extension__ extern __inline float32x4_t
+__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
+vbfmlaltq_laneq_f32 (float32x4_t __r, bfloat16x8_t __a, bfloat16x8_t __b,
+		 const int __index)
+{
+  return __builtin_neon_vbfmat_laneqv8bf (__r, __a, __b, __index);
+}
+
 #endif
 #pragma GCC pop_options
 #pragma GCC pop_options
diff --git a/gcc/config/arm/arm_neon_builtins.def b/gcc/config/arm/arm_neon_builtins.def
index bcccf93f7fa2750e9006e5856efecbec0fb331b9..169781fa9a07930eb755165019427be055dc36ef 100644
--- a/gcc/config/arm/arm_neon_builtins.def
+++ b/gcc/config/arm/arm_neon_builtins.def
@@ -373,3 +373,12 @@ VAR2 (MAC_LANE_PAIR, vcmlaq_lane0, v4sf, v8hf)
 VAR2 (MAC_LANE_PAIR, vcmlaq_lane90, v4sf, v8hf)
 VAR2 (MAC_LANE_PAIR, vcmlaq_lane180, v4sf, v8hf)
 VAR2 (MAC_LANE_PAIR, vcmlaq_lane270, v4sf, v8hf)
+
+VAR1 (TERNOP, vbfmmla, v8bf)
+
+VAR1 (TERNOP, vbfmab, v8bf)
+VAR1 (TERNOP, vbfmat, v8bf)
+VAR1 (MAC_LANE, vbfmab_lane, v8bf)
+VAR1 (MAC_LANE, vbfmat_lane, v8bf)
+VAR1 (MAC_LANE, vbfmab_laneq, v8bf)
+VAR1 (MAC_LANE, vbfmat_laneq, v8bf)
diff --git a/gcc/config/arm/iterators.md 

[GCC][PATCH][AArch64] ACLE intrinsics for BFCVTN, BFCVTN2 (AArch64 AdvSIMD) and BFCVT (AArch64 FP)

2019-12-20 Thread Delia Burduv
This patch adds the Armv8.6-a ACLE intrinsics for bfmmla, bfmlalb and 
bfmlalt as part of the BFloat16 extension.
(https://developer.arm.com/architectures/instruction-sets/simd-isas/neon/intrinsics)
The intrinsics are declared in arm_bf16.h and arm_neon.h and the RTL 
patterns are defined in aarch64-simd.md.
A new test is added to check assembler output.

This patch depends on the two Aarch64 back-end patches. 
(https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01323.html and 
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01324.html)

Tested for regression on aarch64-none-elf and aarch64_be-none-elf. I 
don't have commit rights, so if this is ok can someone please commit it 
for me?

gcc/ChangeLog:

2019-11-06  Delia Burduv  

 * config/aarch64/aarch64-simd-builtins.def
   (bfcvtn): New built-in function.
   (bfcvtn_q): New built-in function.
   (bfcvtn2): New built-in function.
   (bfcvt): New built-in function.
 * config/aarch64/aarch64-simd.md
   (aarch64_bfcvtn): New pattern.
   (aarch64_bfcvtn2v8bf): New pattern.
   (aarch64_bfcvtbf): New pattern.
 * config/aarch64/arm_bf16.h (float32_t): New typedef.
   (vcvth_bf16_f32): New intrinsic.
 * config/aarch64/arm_bf16.h (vcvt_bf16_f32): New intrinsic.
   (vcvtq_low_bf16_f32): New intrinsic.
   (vcvtq_high_bf16_f32): New intrinsic.
 * config/aarch64/iterators.md (V4SF_TO_BF): New mode iterator.
   (UNSPEC_BFCVTN): New UNSPEC.
   (UNSPEC_BFCVTN2): New UNSPEC.
   (UNSPEC_BFCVT): New UNSPEC.
 * config/arm/types.md (bf_cvt): New type.


gcc/testsuite/ChangeLog:

2019-11-06  Delia Burduv  

 * gcc.target/aarch64/advsimd-intrinsics/bfcvt-compile.c: New test.
diff --git a/gcc/config/aarch64/aarch64-simd-builtins.def b/gcc/config/aarch64/aarch64-simd-builtins.def
index f4ca35a59704c761fe2ac2b6d401fff7c8aba80d..30a425bd3aec121e78f269f44e188bdb8d39e75f 100644
--- a/gcc/config/aarch64/aarch64-simd-builtins.def
+++ b/gcc/config/aarch64/aarch64-simd-builtins.def
@@ -682,3 +682,9 @@
   BUILTIN_VSFDF (UNOP, frint32x, 0)
   BUILTIN_VSFDF (UNOP, frint64z, 0)
   BUILTIN_VSFDF (UNOP, frint64x, 0)
+
+  /* Implemented by aarch64_bfcvtn{q}{2}  */
+  VAR1 (UNOP, bfcvtn, 0, v4bf)
+  VAR1 (UNOP, bfcvtn_q, 0, v8bf)
+  VAR1 (BINOP, bfcvtn2, 0, v8bf)
+  VAR1 (UNOP, bfcvt, 0, bf)
diff --git a/gcc/config/aarch64/aarch64-simd.md b/gcc/config/aarch64/aarch64-simd.md
index 55660ae248f4fa75d35ba2949cd4b9d5139ff5f5..ff7a1f5f34a19b05eba48dba96c736dfdfdf7bac 100644
--- a/gcc/config/aarch64/aarch64-simd.md
+++ b/gcc/config/aarch64/aarch64-simd.md
@@ -7027,3 +7027,32 @@
   "xtn\t%0., %1."
   [(set_attr "type" "neon_shift_imm_narrow_q")]
 )
+
+;; bfcvtn
+(define_insn "aarch64_bfcvtn"
+  [(set (match_operand:V4SF_TO_BF 0 "register_operand" "=w")
+(unspec:V4SF_TO_BF [(match_operand:V4SF 1 "register_operand" "w")]
+UNSPEC_BFCVTN))]
+  "TARGET_BF16_SIMD"
+  "bfcvtn\\t%0.4h, %1.4s"
+  [(set_attr "type" "f_cvt")]
+)
+
+(define_insn "aarch64_bfcvtn2v8bf"
+  [(set (match_operand:V8BF 0 "register_operand" "=w")
+(unspec:V8BF [(match_operand:V8BF 1 "register_operand" "w")
+  (match_operand:V4SF 2 "register_operand" "w")]
+  UNSPEC_BFCVTN2))]
+  "TARGET_BF16_SIMD"
+  "bfcvtn2\\t%0.8h, %2.4s"
+  [(set_attr "type" "f_cvt")]
+)
+
+(define_insn "aarch64_bfcvtbf"
+  [(set (match_operand:BF 0 "register_operand" "=w")
+(unspec:BF [(match_operand:SF 1 "register_operand" "w")]
+UNSPEC_BFCVT))]
+  "TARGET_BF16_SIMD"
+  "bfcvt\\t%h0, %s1"
+  [(set_attr "type" "f_cvt")]
+)
diff --git a/gcc/config/aarch64/arm_bf16.h b/gcc/config/aarch64/arm_bf16.h
index aedb0972735ce549fac1870bacd1ef3101e8fd26..1b9ab3690d35e153cd4f24b9e3bbb5b4cc4b4f4d 100644
--- a/gcc/config/aarch64/arm_bf16.h
+++ b/gcc/config/aarch64/arm_bf16.h
@@ -34,7 +34,15 @@
 #ifdef __ARM_FEATURE_BF16_SCALAR_ARITHMETIC
 
 typedef __bf16 bfloat16_t;
-
+typedef float float32_t;
+
+__extension__ extern __inline bfloat16_t
+__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
+vcvth_bf16_f32 \
+  (float32_t __a)
+{
+  return __builtin_aarch64_bfcvtbf (__a);
+}
 
 #endif
 #pragma GCC pop_options
diff --git a/gcc/config/aarch64/arm_neon.h b/gcc/config/aarch64/arm_neon.h
index 6cdbf381f0156ed993f03b847228b36ebbdd14f8..120f4b7d8827aee51834e75aeaa6ab8f8451980e 100644
--- a/gcc/config/aarch64/arm_neon.h
+++ b/gcc/config/aarch64/arm_neon.h
@@ -34610,6 +34610,35 @@ vrnd64xq_f64 (float64x2_t __a)
 
 #include "arm_bf16.h"
 
+#pragma GCC push_options
+#pragma GCC target ("arch=armv8.2-a+bf16")
+#ifdef __ARM_FEATURE_BF16_VECTOR_ARITHMETIC
+
+__extension__ extern __inline bfloat16x4_t
+__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
+vcvt_bf16_f32 (float32x4_t __a)
+{
+  return __builtin_aarch64_bfcvtnv4bf (__a);
+
+}
+
+__extension__ extern __inline bfloat16x8_t
+__attribute__ 

[GCC][PATCH][AArch64] ACLE intrinsics bfmmla and bfmlal for AArch64 AdvSIMD

2019-12-20 Thread Delia Burduv
This patch adds the ARMv8.6 ACLE intrinsics for bfmmla, bfmlalb and 
bfmlalt as part of the BFloat16 extension.
(https://developer.arm.com/architectures/instruction-sets/simd-isas/neon/intrinsics)
The intrinsics are declared in arm_neon.h and the RTL patterns are 
defined in aarch64-simd.md.
Two new tests are added to check assembler output.

This patch depends on the two Aarch64 back-end patches. 
(https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01323.html and 
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01324.html)

Tested for regression on aarch64-none-elf and aarch64_be-none-elf. I 
don't have commit rights, so if this is ok can someone please commit it 
for me?

gcc/ChangeLog:

2019-10-29  Delia Burduv  

 * config/aarch64/aarch64-simd-builtins.def
   (bfmmla): New built-in function.
   (bfmlalb): New built-in function.
   (bfmlalt): New built-in function.
   (bfmlalb_lane): New built-in function.
   (bfmlalt_lane): New built-in function.
   (bfmlalb_laneq): New built-in function.
   (bfmlalt_laneq): New built-in function
 * config/aarch64/aarch64-simd.md (bfmmla): New pattern.
   (bfmlal): New patterns.
 * config/aarch64/arm_neon.h (vbfmmlaq_f32): New intrinsic.
   (vbfmlalbq_f32): New intrinsic.
   (vbfmlaltq_f32): New intrinsic.
   (vbfmlalbq_lane_f32): New intrinsic.
   (vbfmlaltq_lane_f32): New intrinsic.
   (vbfmlalbq_laneq_f32): New intrinsic.
   (vbfmlaltq_laneq_f32): New intrinsic.
 * config/aarch64/iterators.md (UNSPEC_BFMMLA): New UNSPEC.
   (UNSPEC_BFMLALB): New UNSPEC.
   (UNSPEC_BFMLALT): New UNSPEC.
   (BF_MLA): New int iterator.
   (bt): Added UNSPEC_BFMLALB, UNSPEC_BFMLALT.
 * config/arm/types.md (bf_mmla): New type.
   (bf_mla): New type.

gcc/testsuite/ChangeLog:

2019-10-29  Delia Burduv  

 * gcc.target/aarch64/advsimd-intrinsics/bfmlalbt-compile.c: New 
test.
 * gcc.target/aarch64/advsimd-intrinsics/bfmmla-compile.c: New test.
 * 
gcc.target/aarch64/advsimd-intrinsics/vbfmlalbt_lane_f32_indices_1.c:
   New test.
diff --git a/gcc/config/aarch64/aarch64-simd-builtins.def b/gcc/config/aarch64/aarch64-simd-builtins.def
index f4ca35a59704c761fe2ac2b6d401fff7c8aba80d..5e9f50f090870d0c63916540a48f5ac132d2630d 100644
--- a/gcc/config/aarch64/aarch64-simd-builtins.def
+++ b/gcc/config/aarch64/aarch64-simd-builtins.def
@@ -682,3 +682,14 @@
   BUILTIN_VSFDF (UNOP, frint32x, 0)
   BUILTIN_VSFDF (UNOP, frint64z, 0)
   BUILTIN_VSFDF (UNOP, frint64x, 0)
+
+  /* Implemented by aarch64_bfmmlaqv4sf  */
+  VAR1 (TERNOP, bfmmlaq, 0, v4sf)
+
+  /* Implemented by aarch64_bfmlal{_lane{q}}v4sf  */
+  VAR1 (TERNOP, bfmlalb, 0, v4sf)
+  VAR1 (TERNOP, bfmlalt, 0, v4sf)
+  VAR1 (QUADOP_LANE, bfmlalb_lane, 0, v4sf)
+  VAR1 (QUADOP_LANE, bfmlalt_lane, 0, v4sf)
+  VAR1 (QUADOP_LANE, bfmlalb_laneq, 0, v4sf)
+  VAR1 (QUADOP_LANE, bfmlalt_laneq, 0, v4sf)
diff --git a/gcc/config/aarch64/aarch64-simd.md b/gcc/config/aarch64/aarch64-simd.md
index 55660ae248f4fa75d35ba2949cd4b9d5139ff5f5..66a6c4116a1fdd26dd4eec8b0609e28eb2c38fa1 100644
--- a/gcc/config/aarch64/aarch64-simd.md
+++ b/gcc/config/aarch64/aarch64-simd.md
@@ -7027,3 +7027,57 @@
   "xtn\t%0., %1."
   [(set_attr "type" "neon_shift_imm_narrow_q")]
 )
+
+;; bfmmla
+(define_insn "aarch64_bfmmlaqv4sf"
+  [(set (match_operand:V4SF 0 "register_operand" "=w")
+(plus:V4SF (match_operand:V4SF 1 "register_operand" "0")
+   (unspec:V4SF [(match_operand:V8BF 2 "register_operand" "w")
+ (match_operand:V8BF 3 "register_operand" "w")]
+UNSPEC_BFMMLA)))]
+  "TARGET_BF16_SIMD"
+  "bfmmla\\t%0.4s, %2.8h, %3.8h"
+  [(set_attr "type" "neon_mla_s_q")]
+)
+
+;; bfmlal
+(define_insn "aarch64_bfmlalv4sf"
+  [(set (match_operand:V4SF 0 "register_operand" "=w")
+(plus: V4SF (match_operand:V4SF 1 "register_operand" "0")
+(unspec:V4SF [(match_operand:V8BF 2 "register_operand" "w")
+  (match_operand:V8BF 3 "register_operand" "w")]
+ BF_MLA)))]
+  "TARGET_BF16_SIMD"
+  "bfmlal\\t%0.4s, %2.8h, %3.8h"
+  [(set_attr "type" "neon_fp_mla_s")]
+)
+
+(define_insn "aarch64_bfmlal_lanev4sf"
+  [(set (match_operand:V4SF 0 "register_operand" "=w")
+(plus: V4SF (match_operand:V4SF 1 "register_operand" "0")
+(unspec:V4SF [(match_operand:V8BF 2 "register_operand" "w")
+  (match_operand:V4BF 3 "register_operand" "w")
+  (match_operand:SI 4 "const_int_operand" "n")]
+ BF_MLA)))]
+  "TARGET_BF16_SIMD"
+{
+  operands[4] = aarch64_endian_lane_rtx (V4BFmode, INTVAL (operands[4]));
+  return "bfmlal\\t%0.4s, %2.8h, %3.h[%4]";
+}
+  [(set_attr "type" "neon_fp_mla_s")]
+)
+
+(define_insn "aarch64_bfmlal_laneqv4sf"
+  [(set 

Re: [PATCH] rs6000: Fix PR92923, __builtin_vec_xor() causes subregs to be used when not using V4SImode vectors

2019-12-20 Thread Peter Bergner
On 12/20/19 9:35 AM, Segher Boessenkool wrote:
> Something automated to verify what we implement is what we have documented
> would be neat to have.  Maybe this becomes feasible with the rewrite of
> the builtin stuff :-)

Agreed!



>> This passed bootstrap and regression testing with no errors.  Ok for trunk?
> 
> On what kind of system did you test?
> 
> I'd like to see this tested on both BE and LE, and various processor
> generations -- but we'll see if it regresses anyway, and it is still
> stage 3.  So, okay for trunk, just please keep an eye out for
> regressions (in January that is :-) )

It was an LE test.  I fixed up the problems below and have kicked off
a BE run now and will run the testsuite in both 32-bit and 64-bit modes.
I leave on vacation tomorrow, so I'll wait until I return next week
before committing so I can watch for any regressions.


>>  * config/rs6000/rs6000-builtin.def (VAND, VANDC, VNOR, VOR,
>>  VXOR): Delete.
> 
> You can end a changelog line in a colon just fine, fwiw.

Ok.



>> --- gcc/testsuite/gcc.target/powerpc/pr92923-1.c (nonexistent)
>> +++ gcc/testsuite/gcc.target/powerpc/pr92923-1.c (working copy)
>> @@ -0,0 +1,454 @@
>> +/* { dg-do compile { target { powerpc*-*-* } } } */
> 
> You don't need this target clause, everything in gc.target/powerpc has it
> already.
> 
>> +/* { dg-skip-if "" { powerpc*-*-darwin* } } */
> 
> I'm not sure if this is necessary, or just cargo culting :-)

I think maybe both of those were cut/paste issues.  I've removed them both.




>> +/* { dg-final { scan-tree-dump-times "VIEW_CONVERT_EXPR" 0 "gimple" } } */
> 
> That's scan-tree-dump-not.

Ahh, that is better.  Fixed.


> Same comments for the p8 test of course.  Okay with or without those
> adjusted (they aren't wrong, just weird style).

Fixed too.


Peter





undefine OFFSET in testsuite/gcc.dg/vect/tree-vect.h

2019-12-20 Thread Olivier Hainque
Hello,

The attached patch is a proposal for a basic solution
to an issue which might be an improper thing done by a
system header on VxWorks, but which is a big pain to fix
at this level and very simple to address super locally.

A number of tests based on gcc.dg/vect/tree-vect.h
#define and then use a macro named OFFSET, which conflicts
with a macro of the same name exposed by a system
header on VxWorks.

The patch proposed here simply #undef's OFFSET from
tree-vect.h to prevent the possible conflict.

Is this OK to commit ?

Thanks a lot in advance,

With Kind Regards,

Olivier

2019-12-20  Olivier Hainque  

testsuite/
* gcc.dg/vect/tree-vect.h: #undef OFFSET.

 gcc/testsuite/gcc.dg/vect/tree-vect.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/gcc/testsuite/gcc.dg/vect/tree-vect.h 
b/gcc/testsuite/gcc.dg/vect/tree-vect.h
index 69c93ac8092..5d8d9eba3f8 100644
--- a/gcc/testsuite/gcc.dg/vect/tree-vect.h
+++ b/gcc/testsuite/gcc.dg/vect/tree-vect.h
@@ -85,3 +85,9 @@ check_vect (void)
 #else
 #  define VECTOR_BITS 128
 #endif
+
+/* Which most of our tests are going to #define for internal use, and
+   which might be exposed by system headers related to signal.h on some
+   targets, notably VxWorks.  */
+#undef OFFSET
+   
-- 
2.17.1



Backports to 9.x

2019-12-20 Thread Jakub Jelinek
Hi!

I've backported following 25 patches from trunk to 9.x,
bootstrapped/regtested on x86_64-linux and i686-linux, committed
to gcc-9-branch.

Jakub
2019-12-20  Jakub Jelinek  

Backported from mainline
2019-11-21  Jakub Jelinek  
Jason Merrill  

PR c++/90842
* parser.c (cp_parser_decl_specifier_seq): For concept or typedef
break early if CP_PARSER_FLAGS_ONLY_MUTABLE_OR_CONSTEXPR.
For type specifiers, set CP_PARSER_FLAGS_NO_TYPE_DEFINITIONS
if CP_PARSER_FLAGS_ONLY_MUTABLE_OR_CONSTEXPR is set.

* g++.dg/cpp1y/lambda-generic-90842.C: New test.

--- gcc/cp/parser.c (revision 278537)
+++ gcc/cp/parser.c (revision 278538)
@@ -13998,6 +13998,10 @@ cp_parser_decl_specifier_seq (cp_parser*
 case RID_CONCEPT:
   ds = ds_concept;
   cp_lexer_consume_token (parser->lexer);
+
+ if (flags & CP_PARSER_FLAGS_ONLY_MUTABLE_OR_CONSTEXPR)
+   break;
+
  /* In C++20 a concept definition is just 'concept name = expr;'
 Support that syntax by pretending we've seen 'bool'.  */
  if (cp_lexer_next_token_is (parser->lexer, CPP_NAME)
@@ -14025,6 +14029,10 @@ cp_parser_decl_specifier_seq (cp_parser*
  ds = ds_typedef;
  /* Consume the token.  */
  cp_lexer_consume_token (parser->lexer);
+
+ if (flags & CP_PARSER_FLAGS_ONLY_MUTABLE_OR_CONSTEXPR)
+   break;
+
  /* A constructor declarator cannot appear in a typedef.  */
  constructor_possible_p = false;
  /* The "typedef" keyword can only occur in a declaration; we
@@ -14120,6 +14128,9 @@ cp_parser_decl_specifier_seq (cp_parser*
  bool is_cv_qualifier;
  tree type_spec;
 
+ if (flags & CP_PARSER_FLAGS_ONLY_MUTABLE_OR_CONSTEXPR)
+   flags |= CP_PARSER_FLAGS_NO_TYPE_DEFINITIONS;
+
  type_spec
= cp_parser_type_specifier (parser, flags,
decl_specs,
--- gcc/testsuite/g++.dg/cpp1y/lambda-generic-90842.C   (nonexistent)
+++ gcc/testsuite/g++.dg/cpp1y/lambda-generic-90842.C   (revision 278538)
@@ -0,0 +1,7 @@
+// PR c++/90842
+// { dg-do compile { target c++14 } }
+
+auto a = [](auto x) struct C { void foo (); } {};  // { dg-error 
"expected" }
+   // { dg-error 
"type-specifier invalid in lambda" "" { target *-*-* } .-1 }
+auto b = [](auto x) mutable typedef {};// { dg-error 
"'typedef' invalid in lambda" }
+auto d = [](auto x) mutable friend {}; // { dg-error "'friend' 
invalid in lambda" }
2019-12-20  Jakub Jelinek  

Backported from mainline
2019-11-22  Jakub Jelinek  

PR c/90677
* c-common.h (identifier_global_tag): Declare.
* c-format.c (get_pointer_to_named_type): Renamed to ...
(get_named_type): ... this.  Use identifier_global_tag instead of
identifier_global_value, handle the return value being a TYPE_P.
(init_dynamic_diag_info): Adjust get_pointer_to_named_type callers
to call get_named_type instead.  Formatting fixes.

* c-decl.c (identifier_global_tag): Define.

* cp-objcp-common.c (identifier_global_tag): Define.

* c-c++-common/pr90677.c: New test.

--- gcc/c-family/c-common.h (revision 278633)
+++ gcc/c-family/c-common.h (revision 278634)
@@ -800,6 +800,7 @@ extern void c_register_addr_space (const
 extern bool in_late_binary_op;
 extern const char *c_addr_space_name (addr_space_t as);
 extern tree identifier_global_value (tree);
+extern tree identifier_global_tag (tree);
 extern tree c_linkage_bindings (tree);
 extern void record_builtin_type (enum rid, const char *, tree);
 extern tree build_void_list_node (void);
--- gcc/c-family/c-format.c (revision 278633)
+++ gcc/c-family/c-format.c (revision 278634)
@@ -4899,31 +4899,32 @@ init_dynamic_gfc_info (void)
 }
 }
 
-/* Lookup the type named NAME and return a pointer-to-NAME type if found.
-   Otherwise, return void_type_node if NAME has not been used yet, or 
NULL_TREE if
-   NAME is not a type (issuing an error).  */
+/* Lookup the type named NAME and return a NAME type if found.
+   Otherwise, return void_type_node if NAME has not been used yet,
+   or NULL_TREE if NAME is not a type (issuing an error).  */
 
 static tree
-get_pointer_to_named_type (const char *name)
+get_named_type (const char *name)
 {
-  tree result;
-  if ((result = maybe_get_identifier (name)))
+  if (tree result = maybe_get_identifier (name))
 {
-  result = identifier_global_value (result);
+  result = identifier_global_tag (result);
   if (result)
{
- if (TREE_CODE (result) != TYPE_DECL)
+ if (TYPE_P (result))
+   ;
+ else if (TREE_CODE (result) == TYPE_DECL)
+   result = TREE_TYPE (result);
+ else
{
  error ("%qs is not 

[patch] Fix small glitch with -fdump-ada-spec

2019-12-20 Thread Eric Botcazou
This fixes the following discrepancy: when a C or C++ file contains no 
translation unit but only preprocessor macro definitions, -fdump-ada-spec 
outputs nothing but -fdump-ada-spec-slim does.  This changes the former to 
behaving as the latter in this case.

Tested on x86_64-suse-linux, applied on the mainline.


2019-12-20  Eric Botcazou  

c-family/
* c-ada-spec.h (decl_sloc): Delete.
* c-ada-spec.c (decl_sloc): Make static.
c/
* c-decl.c (collect_source_ref_cb): Delete.
(for_each_global_decl): Rename into...
(collect_source_refs): ...this.  Call collect_source_ref directly.
(c_parse_final_cleanups): Always call collect_source_ref on the main
input filename.
cp/
* decl2.c (c_parse_final_cleanups): Always call collect_source_ref on
the main input filename.

-- 
Eric BotcazouIndex: c/c-decl.c
===
--- c/c-decl.c	(revision 279540)
+++ c/c-decl.c	(working copy)
@@ -11787,15 +11787,6 @@ c_write_global_declarations_1 (tree glob
   while (reconsider);
 }
 
-/* Callback to collect a source_ref from a DECL.  */
-
-static void
-collect_source_ref_cb (tree decl)
-{
-  if (!DECL_IS_BUILTIN (decl))
-collect_source_ref (LOCATION_FILE (decl_sloc (decl, false)));
-}
-
 /* Preserve the external declarations scope across a garbage collect.  */
 static GTY(()) tree ext_block;
 
@@ -11813,10 +11804,10 @@ collect_all_refs (const char *source_fil
   collect_ada_nodes (BLOCK_VARS (ext_block), source_file);
 }
 
-/* Iterate over all global declarations and call CALLBACK.  */
+/* Collect source file references at global level.  */
 
 static void
-for_each_global_decl (void (*callback) (tree decl))
+collect_source_refs (void)
 {
   tree t;
   tree decls;
@@ -11827,11 +11818,13 @@ for_each_global_decl (void (*callback) (
 { 
   decls = DECL_INITIAL (t);
   for (decl = BLOCK_VARS (decls); decl; decl = TREE_CHAIN (decl))
-	callback (decl);
+	if (!DECL_IS_BUILTIN (decl))
+	  collect_source_ref (DECL_SOURCE_FILE (decl));
 }
 
   for (decl = BLOCK_VARS (ext_block); decl; decl = TREE_CHAIN (decl))
-callback (decl);
+if (!DECL_IS_BUILTIN (decl))
+  collect_source_ref (DECL_SOURCE_FILE (decl));
 }
 
 /* Perform any final parser cleanups and generate initial debugging
@@ -11865,10 +11858,9 @@ c_parse_final_cleanups (void)
   if (flag_dump_ada_spec || flag_dump_ada_spec_slim)
 {
   /* Build a table of files to generate specs for */
-  if (flag_dump_ada_spec_slim)
-	collect_source_ref (main_input_filename);
-  else
-	for_each_global_decl (collect_source_ref_cb);
+  collect_source_ref (main_input_filename);
+  if (!flag_dump_ada_spec_slim)
+	collect_source_refs ();
 
   dump_ada_specs (collect_all_refs, NULL);
 }
Index: c-family/c-ada-spec.c
===
--- c-family/c-ada-spec.c	(revision 279540)
+++ c-family/c-ada-spec.c	(working copy)
@@ -630,7 +630,7 @@ static const char *current_source_file;
 
 /* Return sloc of DECL, using sloc of last field if LAST is true.  */
 
-location_t
+static location_t
 decl_sloc (const_tree decl, bool last)
 {
   tree field;
Index: c-family/c-ada-spec.h
===
--- c-family/c-ada-spec.h	(revision 279540)
+++ c-family/c-ada-spec.h	(working copy)
@@ -36,7 +36,6 @@ enum cpp_operation {
   IS_TRIVIAL
 };
 
-extern location_t decl_sloc (const_tree, bool);
 extern void collect_ada_nodes (tree, const char *);
 extern void collect_source_ref (const char *);
 extern void dump_ada_specs (void (*)(const char *),
Index: cp/decl2.c
===
--- cp/decl2.c	(revision 279540)
+++ cp/decl2.c	(working copy)
@@ -4815,9 +4815,8 @@ c_parse_final_cleanups (void)
   /* Handle -fdump-ada-spec[-slim] */
   if (flag_dump_ada_spec || flag_dump_ada_spec_slim)
 {
-  if (flag_dump_ada_spec_slim)
-	collect_source_ref (main_input_filename);
-  else
+  collect_source_ref (main_input_filename);
+  if (!flag_dump_ada_spec_slim)
 	collect_source_refs (global_namespace);
 
   dump_ada_specs (collect_all_refs, cpp_check);


Re: [PATCH] enable -fweb and -frename-registers at -O3 for rs6000

2019-12-20 Thread Segher Boessenkool
Hi!

On Fri, Dec 20, 2019 at 02:34:05PM +0800, Jiufu Guo wrote:
> Previously, limited unrolling was enabled at O2 for powerpc in r278034.  At 
> that
> time, -fweb and -frename-registers were not enabled together with 
> -funroll-loops
> even for -O3.  After that, we notice there are some performance degradation on
> SPEC2006fp which caused by without web and rnreg.

And 2017 was fine on all tests.  Annoying :-(

> This patch enable -fweb
> and -frename-registers for -O3 to align original behavior before r278034.

Okay.  Hopefully we can find a way to determine in what circumstances web
and rnreg help instead of hurt, but until then, the old behaviour is
certainly the safe choice.

> --- a/gcc/testsuite/gcc.dg/torture/stackalign/builtin-return-1.c
> +++ b/gcc/testsuite/gcc.dg/torture/stackalign/builtin-return-1.c
> @@ -2,6 +2,7 @@
>  /* Originator: Andrew Church  */
>  /* { dg-do run } */
>  /* { dg-require-effective-target untyped_assembly } */
> +/* { dg-additional-options "-fno-rename-registers" { target { powerpc*-*-* } 
> } } */

What is this for?  What happens without it?

The rs6000/ parts are okay for trunk.  Thanks!


Segher


[patch] Prevent redefinition of WCHAR_MAX from testsuite/gcc.dg/cpp/ucs.c

2019-12-20 Thread Olivier Hainque
Hello,

gcc/testsuite/gcc.dg/cpp/ucs.c #include 
and then crafts a definition of WCHAR_MAX depending
on __WCHAR_TYPE__.

The test fails in VxWorks configurations because WCHAR_MAX
is already exposed by the system limits.h.

The attached patch simply guards the tentative definition
by a check verifying if the macro is defined already, so
we're using the value exposed by limits.h in this case.

This allows the test to pass on the configurations where
we saw it failing, and bootstrap+regtest fine on x86_64-linux.

Ok to commit ?

Thanks in advance,

With Kind Regards,

Olivier


2019-12-20  Olivier Hainque  

* testsuite/gcc.dg/cpp/ucs.c: Prevent redefinition
of WCHAR_MAX if already exposed by limits.h.

 gcc/testsuite/gcc.dg/cpp/ucs.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/gcc/testsuite/gcc.dg/cpp/ucs.c b/gcc/testsuite/gcc.dg/cpp/ucs.c
index cac83f3cf14..f52cd571258 100644
--- a/gcc/testsuite/gcc.dg/cpp/ucs.c
+++ b/gcc/testsuite/gcc.dg/cpp/ucs.c
@@ -16,6 +16,8 @@
 #define short   +2 
 #define long+3
 
+#if !defined(WCHAR_MAX)
+
 #if __WCHAR_TYPE__ == 0
 # define WCHAR_MAX  INT_MAX
 #elif __WCHAR_TYPE__ == 1
@@ -28,6 +30,8 @@
 # error wacky wchar_t
 #endif
 
+#endif
+
 #undef unsigned
 #undef int
 #undef char
-- 
2.17.1



Re: [PATCH 4/4]: C++ P1423R3 char8_t remediation: New tests

2019-12-20 Thread Jonathan Wakely

On 19/12/19 09:36 +, Jonathan Wakely wrote:

On 05/12/19 17:12 +0100, Christophe Lyon wrote:

On Thu, 5 Dec 2019 at 12:43, Jonathan Wakely  wrote:


On 05/12/19 09:00 +0100, Christophe Lyon wrote:

On Tue, 3 Dec 2019 at 10:16, Jonathan Wakely  wrote:


On 03/12/19 09:11 +0100, Christophe Lyon wrote:
>On Mon, 16 Sep 2019 at 04:34, Tom Honermann  wrote:
>>
>> A revised patch is attached that modifies the tests for deleted ostream
>> inserters to require C++2a.  This is required by the revision of patch
>> 2/4 that adds proper preprocessor conditionals to the definitions.
>>
>> Tom.
>>
>> On 9/15/19 3:40 PM, Tom Honermann wrote:
>> > This patch adds new tests to validate new deleted overloads of wchar_t,
>> > char8_t, char16_t, and char32_t for ordinary and wide formatted
>> > character and string ostream inserters.
>> >
>> > Additionally, new tests are added to validate invocations of u8path with
>> > sequences of char8_t for both the C++17 and filesystem TS implementations.
>> >
>> > libstdc++-v3/ChangeLog:
>> >
>> > 2019-09-15  Tom Honermann  
>> >
>> >   *
>> > 
libstdc++-v3/testsuite/27_io/basic_ostream/inserters_character/char/deleted.cc:
>> >
>> > New test to validate deleted overloads of character and string
>> > inserters for narrow ostreams.
>> >   *
>> > 
libstdc++-v3/testsuite/27_io/basic_ostream/inserters_character/wchar_t/deleted.cc:
>> >
>> > New test to validate deleted overloads of character and string
>> > inserters for wide ostreams.
>> >   *
>> > libstdc++-v3/testsuite/27_io/filesystem/path/factory/u8path-char8_t.cc:
>> > New test to validate u8path invocations with sequences of
>> > char8_t.
>> >   *
>> > 
libstdc++-v3/testsuite/experimental/filesystem/path/factory/u8path-char8_t.cc
>> >
>> > New test to validate u8path invocations with sequences of
>> > char8_t.
>> >
>
>Hi,
>
>I've noticed that the new test
>27_io/filesystem/path/factory/u8path-char8_t.cc
>fails to compile on arm-none-eabi with default cpu/fpu, because:
>/tools/arm-none-eabi/bin/ld:
>/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/src/.libs/libstdc++.a(string-inst.o):
>in function `_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEaSEOS4_':
>string-inst.cc:(.text._ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEaSEOS4_[_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEaSEOS4_]+0xf4):
>undefined reference to `_ZSt15__alloc_on_moveISaIcEEvRT_S2_'
>[etc...]

That function is defined inline and so should be instantiated in any
TU that needs it, and so should not give linker errors. There was a
similar bug reported the other day that turned out to be pilot error:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92733


Hi,
Sorry for the delay, it took me a while to reproduce the problem manually.
I think I see this because I build that particular configuration with
CXXFLAGS_FOR_TARGET=-fno-threadsafe-statics

Does that sound plausible?


Not really ... I still don't know why that function template would
ever be undefined.



Hmmm that's because doing CXXFLAGS_FOR_TARGET means that the generated
Makefile contains:
CXXFLAGS = -fno-threadsafe-statics
while if I don't define CXXFLAGS_FOR_TARGET, it contains
CXXFLAGS = -g -O2 -D_GNU_SOURCE

Re-compiling string-inst with -O2 removes the undefined reference

Sigh... looks like I fixed something similar 7 years ago :-(
https://gcc.gnu.org/viewcvs/gcc?view=revision=189046

So... the current configure.ac code makes sure -O2 and -g are present
in CXXFLAGS_FOR_TARGET only if it's derived from CXXFLAGS, which
happens only when CXXFLAGS_FOR_TARGET is NOT overridden, and not
cross-compiling...

We have:
  case " $CXXFLAGS " in
*" -O2 "*) ;;
*) CXXFLAGS_FOR_TARGET="-O2 $CXXFLAGS_FOR_TARGET" ;;
  esac

Why isn't it case "$CXXFLAGS_FOR_TARGET" instead? And that whole
case/esac should be after the 'fi'.
Or is it that way on purpose?

So it seems the fix for the problem I saw is for me to use
CXXFLAGS_FOR_TARGET="-O2 -g  -fno-threadsafe-statics"


This is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92927 and thanks
to the bisected revision number in the PR I see what the problem is.


To be clear, PR 92927 is about the undefined references when building
with -O0, and will be fixed soon by the attached patch that I've just
committed to trunk.

I don't know the answer to the question about CXXFLAGS_FOR_TARGET, and
don't know if it's that way on purpose. Please feel free to create a
bug for it, or propose a patch.


commit 5adbd32971c31ec3f0d05f883aba6015f98fbc33
Author: Jonathan Wakely 
Date:   Fri Dec 20 11:03:40 2019 +

libstdc++: Add inline to maybe-constexpr functions (PR 92927)

Originally these functions were always inline. I changed them in r277342
to be always constexpr, then in r277588 changed them to be constexpr for
C++14, but I didn't restore the 'inline' for C++11. That leads to linker
errors when libstdc++.so is built unoptimized, because those functions

Re: [PATCH] Add OpenACC 2.6 `acc_get_property' support

2019-12-20 Thread Harwath, Frederik
Hi Thomas,
thanks for the review! I have attached a revised patch.

> > There is no AMD GCN support yet. This will be added later on.
>
> ACK, just to note that there now is a 'libgomp/plugin/plugin-gcn.c' that
> at least needs to get a stub implementation (can mostly copy from
> 'libgomp/plugin/plugin-hsa.c'?) as otherwise the build will fail.

Yes, I have added a stub. A full implementation will follow soon.
The implementation in the OG9 branch that Andrew mentioned will need a
bit of polishing.

> Tobias has generally reviewed the Fortran bits, correct?

Yes, he has done that internally.

> | Before Frederik starts working on integrating this into GCC trunk, do you
> | (Jakub) agree with the libgomp plugin interface changes as implemented by
> | Maciej?  For example, top-level 'GOMP_OFFLOAD_get_property' function in
> | 'struct gomp_device_descr' instead of stuffing this into its
> | 'acc_dispatch_t openacc'.  (I never understood why the OpenACC functions
> | need to be segregated like they are.)
>
> Jakub didn't answer, but I now myself decided that we should group this
> with the other OpenACC libgomp-plugin functions, as this interface is
> defined in terms of OpenACC-specific stuff such as 'acc_device_t'.
> Frederik, please work on that, also try to move function definitions etc.
> into appropriate places in case they aren't; ask if you need help.
> That needs to be updated.

Is it ok to do this in a separate follow-up patch?


> >  .../acc-get-property-2.c  |  68 +
> >  .../acc-get-property-3.c  |  19 +++
> >  .../acc-get-property-aux.c|  60 
> >  .../acc-get-property.c|  75 ++
> >  .../libgomp.oacc-fortran/acc-get-property.f90 |  80 ++
>
> Please name all these 'acc_get_property*', which is the name of the
> interface tested.

Ok.


> > --- a/include/gomp-constants.h
> > +++ b/include/gomp-constants.h
> > @@ -178,6 +178,20 @@ enum gomp_map_kind
> >=20=20
> >  #define GOMP_DEVICE_ICV-1
> >  #define GOMP_DEVICE_HOST_FALLBACK  -2
> > +#define GOMP_DEVICE_CURRENT-3
> [...]
>
> Not should if this should be grouped with 'GOMP_DEVICE_ICV',
> 'GOMP_DEVICE_HOST_FALLBACK', for it is not related to there.
>
> [...]
>
> Should this actually get value '-1' instead of '-3'?  Or, is the OpenACC
> 'acc_device_t' code already paying special attention to negative values
> '-1', '-2'?  (I don't think so.)
> | Also, 'acc_device_current' is a libgomp-internal thing (doesn't interface
> | with the compiler proper), so strictly speaking 'GOMP_DEVICE_CURRENT'
> | isn't needed in 'include/gomp-constants.h'.  But probably still a good
> | idea to list it there, in this canonical place, to keep the several lists
> | of device types coherent.
> still wonder about that...  ;-)

I have removed GOMP_DEVICE_CURRENT from gomp-constants.h.
Changing the value of GOMP_DEVICE_ICV violates the following static asserts in 
oacc-parallel.c:

 /* In the ABI, the GOACC_FLAGs are encoded as an inverted bitmask, so that we
   continue to support the following two legacy values.  */
_Static_assert (GOACC_FLAGS_UNMARSHAL (GOMP_DEVICE_ICV) == 0,
"legacy GOMP_DEVICE_ICV broken");
_Static_assert (GOACC_FLAGS_UNMARSHAL (GOMP_DEVICE_HOST_FALLBACK)
== GOACC_FLAG_HOST_FALLBACK,
"legacy GOMP_DEVICE_HOST_FALLBACK broken");

> > +/* Device property codes.  Keep in sync with
> > +   libgomp/{openacc.h,openacc.f90,openacc_lib.h}:acc_device_property_t
>
> | Same thing, libgomp-internal, not sure whether to list these here?
>
> > +   as well as libgomp/libgomp-plugin.h.  */
>
> (Not sure why 'libgomp/libgomp-plugin.h' is relevant here?)

It does not seem to be relevant. Right now, openacc_lib.h is also not relevant.
I have removed both file names from the comment.

> > +#define GOMP_DEVICE_PROPERTY_MEMORY1
> > +#define GOMP_DEVICE_PROPERTY_FREE_MEMORY   2
> > +#define GOMP_DEVICE_PROPERTY_NAME  0x10001
> > +#define GOMP_DEVICE_PROPERTY_VENDOR0x10002
> > +#define GOMP_DEVICE_PROPERTY_DRIVER0x10003
> > +
> > +/* Internal property mask to tell numeric and string values apart.  */
> > +#define GOMP_DEVICE_PROPERTY_STRING_MASK   0x1
>
> (Maybe should use an 'enum'?)

I have changed this to an enum. However, this does not improve the code much,
since we cannot use the enum for the function arguments in the plugins
because gomp-constants.h is not included from there.

> Maybe this stuff should move from 'include/gomp-constants.h' to
> 'libgomp/oacc-int.h'.  I'll think about that again, when I'm awake again
> tomorrow.  ;-)

Have you made up your mind yet? :-)


> > --- a/libgomp/libgomp-plugin.h
> > +++ b/libgomp/libgomp-plugin.h
> > @@ -54,6 +54,13 @@ enum offload_target_type
> >OFFLOAD_TARGET_TYPE_GCN =3D 8
> >  };
> >=20=20
> > +/* Container type for passing device properties.  */
> > +union 

Re: [PATCH] PowerPC, Rename SIGNED_BIT_OFFSET_P to SIGNED_INTEGER_BIT_P

2019-12-20 Thread Segher Boessenkool
Hi!

On Wed, Dec 18, 2019 at 05:15:21PM -0500, Michael Meissner wrote:
> In the patch:
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01201.html
> 
> Segher Boessenkool asked me to submit a patch to rename the macros used to see
> if a number is a valid signed 16 or 34-bit value:
> 
> > Please follow up with a patch to not call random numbers "OFFSET".
> 
> This patch does this, renaming:
> 
>   SIGNED_34BIT_OFFSET_P   -> SIGNED_INTEGER_34BIT_P
>   SIGNED_16BIT_OFFSET_P   -> SIGNED_INTEGER_16BIT_P
> 
> I did not change the secondary macros (SIGNED_34BIT_OFFSET_EXTRA_P and
> SIGNED_16BIT_OFFSET_P), since those are exclusively used for offset
> calculations.  But I can if you prefer it that way.

No, that is fine.  It is also fine to keep the SIGNED_16BIT_OFFSET_P etc.
names around as well; that might be nicer code, too?  Names matter as well,
not just what the code does.

> @@ -24770,7 +24770,7 @@ address_to_insn_form (rtx addr,
>  return INSN_FORM_BAD;
>  
>HOST_WIDE_INT offset = INTVAL (op1);
> -  if (!SIGNED_34BIT_OFFSET_P (offset))
> +  if (!SIGNED_INTEGER_34BIT_P (offset))
>  return INSN_FORM_BAD;

So you might want to keep this one?

> @@ -24789,7 +24789,7 @@ address_to_insn_form (rtx addr,
>  return INSN_FORM_BAD;
>  
>/* Large offsets must be prefixed.  */
> -  if (!SIGNED_16BIT_OFFSET_P (offset))
> +  if (!SIGNED_INTEGER_16BIT_P (offset))

And this.

That is so few that this is fine, sure.

> +/* Whether a given VALUE is a valid 16 or 34-bit signed integer.  */
> +#define SIGNED_INTEGER_NBIT_P(VALUE, N)  
> \
>IN_RANGE ((VALUE), \
> + -(HOST_WIDE_INT_1 << ((N)-1)),  \
> + (HOST_WIDE_INT_1 << ((N)-1)) - 1)

(This evaluates N twice.  Macros are evil.)

Okay for trunk.  Thanks!


Segher


[C++ Patch] Improve delete expressions locations

2019-12-20 Thread Paolo Carlini

Hi,

more of the last idea, this time applied to cp_parser_delete_expression 
/ delete_sanity (thus build_delete and build_vec_delete which provide 
tests). Nothing particularly remarkable in this case. Tested x86_64-linux.


Thanks, Paolo.

///

/gcc/cp
2019-12-20  Paolo Carlini  

* decl2.c (delete_sanity): Add location_t parameter and use
it throughout.
* init.c (build_vec_delete_1): Likewise.
(build_delete): Likewise.
(build_vec_delete): Likewise.
(perform_target_ctor): Adjust call.
(perform_member_init): Likewise.
(build_vec_init): Likewise.
* decl.c (cxx_maybe_build_cleanup): Likewise.
* pt.c (tsubst_copy_and_build): Likewise.
* parser.c (cp_parser_delete_expression): Likewise, pass the
combined_loc.
* cp-tree.h: Update declarations.

/libcc1
2019-12-20  Paolo Carlini  

* libcp1plugin.cc (plugin_build_unary_expr): Update delete_sanity
call.

/gcc/testsuite
2019-12-18  Paolo Carlini  

* g++.dg/init/delete1.C: Check locations too.
* g++.dg/ipa/pr85607.C: Likewise.
* g++.dg/warn/Wdelete-incomplete-1.C: Likewise.
* g++.dg/warn/delete-non-virtual-dtor.C: Likewise.
* g++.dg/warn/incomplete1.C: Likewise.
Index: gcc/cp/cp-tree.h
===
--- gcc/cp/cp-tree.h(revision 279563)
+++ gcc/cp/cp-tree.h(working copy)
@@ -6583,7 +6583,8 @@ extern bool vague_linkage_p   (tree);
 extern void grokclassfn(tree, tree,
 enum overload_flags);
 extern tree grok_array_decl(location_t, tree, tree, bool);
-extern tree delete_sanity  (tree, tree, bool, int, 
tsubst_flags_t);
+extern tree delete_sanity  (location_t, tree, tree, bool,
+int, tsubst_flags_t);
 extern tree check_classfn  (tree, tree, tree);
 extern void check_member_template  (tree);
 extern tree grokfield (const cp_declarator *, cp_decl_specifier_seq *,
@@ -6725,11 +6726,11 @@ extern tree build_new   
(vec **, tre
 extern tree get_temp_regvar(tree, tree);
 extern tree build_vec_init (tree, tree, tree, bool, int,
  tsubst_flags_t);
-extern tree build_delete   (tree, tree,
+extern tree build_delete   (location_t, tree, tree,
 special_function_kind,
 int, int, tsubst_flags_t);
 extern void push_base_cleanups (void);
-extern tree build_vec_delete   (tree, tree,
+extern tree build_vec_delete   (location_t, tree, tree,
 special_function_kind, int,
 tsubst_flags_t);
 extern tree create_temporary_var   (tree);
Index: gcc/cp/decl.c
===
--- gcc/cp/decl.c   (revision 279563)
+++ gcc/cp/decl.c   (working copy)
@@ -17311,7 +17311,7 @@ cxx_maybe_build_cleanup (tree decl, tsubst_flags_t
   else
addr = build_address (decl);
 
-  call = build_delete (TREE_TYPE (addr), addr,
+  call = build_delete (input_location, TREE_TYPE (addr), addr,
   sfk_complete_destructor, flags, 0, complain);
   if (call == error_mark_node)
cleanup = error_mark_node;
Index: gcc/cp/decl2.c
===
--- gcc/cp/decl2.c  (revision 279563)
+++ gcc/cp/decl2.c  (working copy)
@@ -475,8 +475,8 @@ grok_array_decl (location_t loc, tree array_expr,
Implements ARM $5.3.4.  This is called from the parser.  */
 
 tree
-delete_sanity (tree exp, tree size, bool doing_vec, int use_global_delete,
-  tsubst_flags_t complain)
+delete_sanity (location_t loc, tree exp, tree size, bool doing_vec,
+  int use_global_delete, tsubst_flags_t complain)
 {
   tree t, type;
 
@@ -489,14 +489,16 @@ tree
   DELETE_EXPR_USE_GLOBAL (t) = use_global_delete;
   DELETE_EXPR_USE_VEC (t) = doing_vec;
   TREE_SIDE_EFFECTS (t) = 1;
+  SET_EXPR_LOCATION (t, loc);
   return t;
 }
 
+  location_t exp_loc = cp_expr_loc_or_loc (exp, loc);
+
   /* An array can't have been allocated by new, so complain.  */
   if (TREE_CODE (TREE_TYPE (exp)) == ARRAY_TYPE
   && (complain & tf_warning))
-warning_at (cp_expr_loc_or_input_loc (exp), 0,
-   "deleting array %q#E", exp);
+warning_at (exp_loc, 0, "deleting array %q#E", exp);
 
   t = build_expr_type_conversion (WANT_POINTER, exp, true);
 
@@ -503,7 +505,7 @@ 

[PATCH] fortran: Fix PR number in comment of testcase for PR 69497

2019-12-20 Thread Jonathan Wakely
The testcase was originally committed with an incorrect changelog and PR
number. The changelog was fixed later, but not the comment in the test.

PR fortran/69497
* gfortran.dg/pr69497.f90: Fix PR number in comment.

I'm going to commit this to trunk as obvious.


commit 1c52a87af8a3931fc4bad440430d908264087a47
Author: Jonathan Wakely 
Date:   Fri Dec 20 15:07:34 2019 +

fortran: Fix PR number in comment of testcase for PR 69497

The testcase was originally committed with an incorrect changelog and PR
number. The changelog was fixed later, but not the comment in the test.

PR fortran/69497
* gfortran.dg/pr69497.f90: Fix PR number in comment.

diff --git a/gcc/testsuite/gfortran.dg/pr69497.f90 
b/gcc/testsuite/gfortran.dg/pr69497.f90
index 7b57ee13368..1698ebbf4ec 100644
--- a/gcc/testsuite/gfortran.dg/pr69497.f90
+++ b/gcc/testsuite/gfortran.dg/pr69497.f90
@@ -1,5 +1,5 @@
 ! { dg-do compile }
-! PR89497
+! PR69497
 program p
block
do


[patch] allow $ in scan-tree-dump expressions matching symbol names

2019-12-20 Thread Olivier Hainque
Hello,

This change adjusts a few scan-tree-dump expressions
to allow '$' as well as '.' when matching symbol names,

This improves results on VxWorks targets configured with:

  #undef NO_DOLLAR_IN_LABEL
  #define NO_DOT_IN_LABEL

Bootstrapped and regression tested fine on x86_64-linux-gnu.

Ok to commit ?

Thanks in advance,

Regards,

Olivier

2019-12-20  Olivier Hainque  
Jerome Lambourg  

testsuite/
* c-c++-common/pr56493.c: Allow '$' in addition to '.'
scan-tree-dump expressions matching symbol names.
* gcc.dg/tree-ssa/sra-17.c: Likewise.
* gcc.dg/tree-ssa/sra-18.c: Likewise.

 gcc/testsuite/c-c++-common/pr56493.c   | 2 +-
 gcc/testsuite/gcc.dg/tree-ssa/sra-17.c | 2 +-
 gcc/testsuite/gcc.dg/tree-ssa/sra-18.c | 8 
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/gcc/testsuite/c-c++-common/pr56493.c 
b/gcc/testsuite/c-c++-common/pr56493.c
index aa7f6f4fc25..bc9928da941 100644
--- a/gcc/testsuite/c-c++-common/pr56493.c
+++ b/gcc/testsuite/c-c++-common/pr56493.c
@@ -12,4 +12,4 @@ foo (void)
 }
 
 /* Verify we narrow the addition from unsigned long long to unsigned int type. 
 */
-/* { dg-final { scan-tree-dump "  (\[a-zA-Z._0-9]*) = \\(unsigned int\\) 
\[^;\n\r]*;.*  (\[a-zA-Z._0-9]*) = \\(unsigned int\\) \[^;\n\r]*;.* = \\1 \\+ 
\\2;" "gimple" { target { ilp32 || lp64 } } } } */
+/* { dg-final { scan-tree-dump "  (\[a-zA-Z._0-9$]*) = \\(unsigned int\\) 
\[^;\n\r]*;.*  (\[a-zA-Z._0-9$]*) = \\(unsigned int\\) \[^;\n\r]*;.* = \\1 \\+ 
\\2;" "gimple" { target { ilp32 || lp64 } } } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/sra-17.c 
b/gcc/testsuite/gcc.dg/tree-ssa/sra-17.c
index a66344b5f33..221d96b6cd9 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/sra-17.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/sra-17.c
@@ -17,4 +17,4 @@ main (int argc, char **argv)
 }
 
 /* { dg-final { scan-tree-dump-times "Removing load: a = \\\*.?L.?C.?.?.?0;" 1 
"esra" } } */
-/* { dg-final { scan-tree-dump-times "SR\\.\[0-9_\]+ = \\\*.?L.?C.?.?.?0\\\[" 
4 "esra" } } */
+/* { dg-final { scan-tree-dump-times "SR\[.$\]\[0-9_\]+ = 
\\\*.?L.?C.?.?.?0\\\[" 4 "esra" } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/sra-18.c 
b/gcc/testsuite/gcc.dg/tree-ssa/sra-18.c
index 47fa204390e..f5e6a21c2ae 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/sra-18.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/sra-18.c
@@ -23,7 +23,7 @@ main (int argc, char **argv)
 }
 
 /* { dg-final { scan-tree-dump-times "Removing load: a = \\\*.?L.?C.?.?.?0;" 1 
"esra" } } */
-/* { dg-final { scan-tree-dump-times "SR\\.\[0-9_\]+ = 
\\\*.?L.?C.?.?.?0\\.b\\\[0\\\]\\.f\\\[0\\\]\\.x" 1 "esra" } } */
-/* { dg-final { scan-tree-dump-times "SR\\.\[0-9_\]+ = 
\\\*.?L.?C.?.?.?0\\.b\\\[0\\\]\\.f\\\[1\\\]\\.x" 1 "esra" } } */
-/* { dg-final { scan-tree-dump-times "SR\\.\[0-9_\]+ = 
\\\*.?L.?C.?.?.?0\\.b\\\[1\\\]\\.f\\\[0\\\]\\.x" 1 "esra" } } */
-/* { dg-final { scan-tree-dump-times "SR\\.\[0-9_\]+ = 
\\\*.?L.?C.?.?.?0\\.b\\\[1\\\]\\.f\\\[1\\\]\\.x" 1 "esra" } } */
+/* { dg-final { scan-tree-dump-times "SR\[.$\]\[0-9_\]+ = 
\\\*.?L.?C.?.?.?0\\.b\\\[0\\\]\\.f\\\[0\\\]\\.x" 1 "esra" } } */
+/* { dg-final { scan-tree-dump-times "SR\[.$\]\[0-9_\]+ = 
\\\*.?L.?C.?.?.?0\\.b\\\[0\\\]\\.f\\\[1\\\]\\.x" 1 "esra" } } */
+/* { dg-final { scan-tree-dump-times "SR\[.$\]\[0-9_\]+ = 
\\\*.?L.?C.?.?.?0\\.b\\\[1\\\]\\.f\\\[0\\\]\\.x" 1 "esra" } } */
+/* { dg-final { scan-tree-dump-times "SR\[.$\]\[0-9_\]+ = 
\\\*.?L.?C.?.?.?0\\.b\\\[1\\\]\\.f\\\[1\\\]\\.x" 1 "esra" } } */
-- 
2.17.1





Re: [PATCH] rs6000: Fix PR92923, __builtin_vec_xor() causes subregs to be used when not using V4SImode vectors

2019-12-20 Thread Segher Boessenkool
Hi!

On Tue, Dec 17, 2019 at 07:06:19PM -0600, Peter Bergner wrote:
> PR92923 shows a problem where builtin function usage is causing performance
> problems due to unneeded subreg usage.  These are being caused by the front-
> end emitting unneeded VIEW_CONVERT_EXPR's on the builtin functions operands.
> These in tern where caused by a lack of overloaded builtin entries in the
> rs6000 backend.  The following patch adds just enough new definitions to
> match what our vector documentation says we must support.  I have also
> added new test cases so that we will catch any regressions in this area.

Something automated to verify what we implement is what we have documented
would be neat to have.  Maybe this becomes feasible with the rewrite of
the builtin stuff :-)

> This passed bootstrap and regression testing with no errors.  Ok for trunk?

On what kind of system did you test?

I'd like to see this tested on both BE and LE, and various processor
generations -- but we'll see if it regresses anyway, and it is still
stage 3.  So, okay for trunk, just please keep an eye out for
regressions (in January that is :-) )

> This is a bug on the release branches too, but given how big this patch
> ended up being, I don't think we want to backport this.

Yes, and no user hit problems here anyway.

>   * config/rs6000/rs6000-builtin.def (VAND, VANDC, VNOR, VOR,
>   VXOR): Delete.

You can end a changelog line in a colon just fine, fwiw.

> --- gcc/testsuite/gcc.target/powerpc/pr92923-1.c  (nonexistent)
> +++ gcc/testsuite/gcc.target/powerpc/pr92923-1.c  (working copy)
> @@ -0,0 +1,454 @@
> +/* { dg-do compile { target { powerpc*-*-* } } } */

You don't need this target clause, everything in gc.target/powerpc has it
already.

> +/* { dg-skip-if "" { powerpc*-*-darwin* } } */

I'm not sure if this is necessary, or just cargo culting :-)

> +/* { dg-final { scan-tree-dump-times "VIEW_CONVERT_EXPR" 0 "gimple" } } */

That's scan-tree-dump-not.

Same comments for the p8 test of course.  Okay with or without those
adjusted (they aren't wrong, just weird style).

Thanks,


Segher


Re: [PATCH][Arm] Enable CLI for Armv8.6-a: armv8.6-a, i8mm and bf16

2019-12-20 Thread Kyrill Tkachov

Hi Dennis,

On 12/12/19 5:30 PM, Dennis Zhang wrote:

Hi all,

On 22/11/2019 14:33, Dennis Zhang wrote:
> Hi all,
>
> This patch is part of a series adding support for Armv8.6-A features.
> It enables options including -march=armv8.6-a, +i8mm and +bf16.
> The +i8mm and +bf16 features are optional for Armv8.2-a and onward.
> Documents are at https://developer.arm.com/docs/ddi0596/latest
>
> Regtested for arm-none-linux-gnueabi-armv8-a.
>

This is an update to rebase the patch to the top.
Some issues are fixed according to the recent CLI patch for AArch64.
ChangeLog is updated as following:

gcc/ChangeLog:

2019-12-12  Dennis Zhang  

    * config/arm/arm-c.c (arm_cpu_builtins): Define
    __ARM_FEATURE_MATMUL_INT8, __ARM_FEATURE_BF16_VECTOR_ARITHMETIC,
    __ARM_FEATURE_BF16_SCALAR_ARITHMETIC, and
    __ARM_BF16_FORMAT_ALTERNATIVE when enabled.
    * config/arm/arm-cpus.in (armv8_6, i8mm, bf16): New features.
    * config/arm/arm-tables.opt: Regenerated.
    * config/arm/arm.c (arm_option_reconfigure_globals): Initialize
    arm_arch_i8mm and arm_arch_bf16 when enabled.
    * config/arm/arm.h (TARGET_I8MM): New macro.
    (TARGET_BF16_FP, TARGET_BF16_SIMD): Likewise.
    * config/arm/t-aprofile: Add matching rules for -march=armv8.6-a.
    * config/arm/t-arm-elf (all_v8_archs): Add armv8.6-a.
    * config/arm/t-multilib: Add matching rules for -march=armv8.6-a.
    (v8_6_a_simd_variants): New.
    (v8_*_a_simd_variants): Add i8mm and bf16.
    * doc/invoke.texi (armv8.6-a, i8mm, bf16): Document new options.

gcc/testsuite/ChangeLog:

2019-12-12  Dennis Zhang  

    * gcc.target/arm/multilib.exp: Add combination tests for 
armv8.6-a.


Is it OK for trunk?



This is ok for trunk.

Please follow the steps at https://gcc.gnu.org/svnwrite.html to get 
write permission to the repo (listing me as approver).


You can then commit it yourself :)

Thanks,

Kyrill




Many thanks!
Dennis


[PATCH] Avoid segfault when doing IPA-VRP but not IPA-CP (PR 93015)

2019-12-20 Thread Martin Jambor
Hi,

PR 93015 testcase - an empty main function compiled with -O0 -fipa-vrp
-flto - shows that IPA-VRA can segfault when trying to access results of
an analysis that has not been performed because of zero optimization
level, -fno-ipa-cp etc.

Rather than adding another chain of opt_for_fn() the patch fixes it by
what IPA-CP-BITS does, which is simply checking that info of a node is
not NULL.

Bootstrapped and tested on x86_64-linux.  OK for trunk?

Thanks,

Martin


2019-12-20  Martin Jambor  

PR ipa/93015
* ipa-cp.c (ipcp_store_vr_results): Check that info exists

testsuite/
* gcc.dg/lto/pr93015_0.c: New test.


---
 gcc/ipa-cp.c | 2 +-
 gcc/testsuite/gcc.dg/lto/pr93015_0.c | 6 ++
 2 files changed, 7 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.dg/lto/pr93015_0.c

diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
index 243b064ee2c..329e259ede3 100644
--- a/gcc/ipa-cp.c
+++ b/gcc/ipa-cp.c
@@ -5661,7 +5661,7 @@ ipcp_store_vr_results (void)
   ipa_node_params *info = IPA_NODE_REF (node);
   bool found_useful_result = false;
 
-  if (!opt_for_fn (node->decl, flag_ipa_vrp))
+  if (!info || !opt_for_fn (node->decl, flag_ipa_vrp))
{
  if (dump_file)
fprintf (dump_file, "Not considering %s for VR discovery "
diff --git a/gcc/testsuite/gcc.dg/lto/pr93015_0.c 
b/gcc/testsuite/gcc.dg/lto/pr93015_0.c
new file mode 100644
index 000..d084b5ad1e2
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/lto/pr93015_0.c
@@ -0,0 +1,6 @@
+/* { dg-lto-do link } */
+/* { dg-lto-options { { -O0 -fipa-vrp -flto } } } */
+
+int main() {
+
+}
-- 
2.24.0



Re: [pach, fortran] Fix PR 92961, ICE on division by zero error in array bounds

2019-12-20 Thread Thomas Koenig




the attached patch fixes an ICE in an array declaration where the
specified size came from 0/0. This is an 8/9/10 regression.


Actually, it does not fix all testcases in the PR, so some more
tweaking is still needed.

Regards

Thomas


Re: [patch] Test setrlimit with c++ in libstdc++/configure

2019-12-20 Thread Jonathan Wakely

On 16/12/19 14:51 +0100, Jérôme Lambourg wrote:

Hello,

In libstdc++, the test for the presence of setrlimit on the target is currently
performed in C as opposed to the other similar tests there. This leads on only a
warning being issued during configure as opposed to the expected error, and thus
improper definition of _GLIBCXX_RES_LIMITS.

This happens in particular on VxWorks where the standard header files are
available and the "struct rlimit" type definition is there. During configure,
only the setrlimit function prototype is missing so the compilation in C only
yield warnings and the test passes.

This patch fixes that by switching to C++ before testing setrlimit. It was
implemented first on gcc-8 for our internal needs, then ported to gcc-9 and now
mainline for contribution.

This change shouldn't impact targets where setrlimit is actually defined. I
tested the change on Linux to check that the result of the configure stage is
not changed by this patch.

Best regards,
Jerome


2019-12-16  Corentin Gay  
  Jerome Lambourg  

libstdc++
* acinclude.m4 (GLIBCXX_CHECK_SETRLIMIT): Test with AC_LANG_CPLUSPLUS.
* configure: Regenerate.



OK for trunk, thanks.


diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index 016b0c583d0..0c58d722988 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -316,6 +316,8 @@ AC_DEFUN([GLIBCXX_CHECK_SETRLIMIT_ancilliary], [
])

AC_DEFUN([GLIBCXX_CHECK_SETRLIMIT], [
+  AC_LANG_SAVE
+  AC_LANG_CPLUSPLUS
  setrlimit_have_headers=yes
  AC_CHECK_HEADERS(unistd.h sys/time.h sys/resource.h,
  [],
@@ -352,6 +354,7 @@ AC_DEFUN([GLIBCXX_CHECK_SETRLIMIT], [
  else
ac_res_limits=no
  fi
+  AC_LANG_RESTORE
  AC_MSG_RESULT($ac_res_limits)
])






Re: [GCC][PATCH][AArch64]Add ACLE intrinsics for bfdot for ARMv8.6 Extension

2019-12-20 Thread Richard Sandiford
Stam Markianos-Wright  writes:
> Hi all,
>
> This patch adds the ARMv8.6 Extension ACLE intrinsics for the bfloat bfdot 
> operation.
>
> The functions are declared in arm_neon.h with the armv8.2-a+bf16 target 
> option 
> as required.
>
> RTL patterns are defined to generate assembler.
>
> Tests added to verify expected assembly and perform adequate lane checks.
>
> This patch depends on:
>
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00857.html
>
> for testuite effective_target update and on:
>
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01323.html
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01324.html
>
> for back-end Bfloat enablement.
>
> Cheers,
> Stam
>
>
> gcc/ChangeLog:
>
> 2019-11-04  Stam Markianos-Wright  
>
>   * config/aarch64/aarch64-simd-builtins.def (aarch64_bfdot,
>aarch64_bfdot_lane, aarch64_bfdot_laneq): New.
>   * config/aarch64/aarch64-simd.md
>(aarch64_bfdot, aarch64_bfdot_lane): New.
>   * config/aarch64/arm_neon.h (vbfdot_f32, vbfdotq_f32, vbfdot_lane_f32,
>vbfdotq_lane_f32, vbfdot_laneq_f32, vbfdotq_laneq_f32): New.
>   * config/aarch64/iterators.md (UNSPEC_BFDOT, VBF, isquadop, Vbfdottype,
>VBFMLA_W): New.

Changelog nit: the continuation lines should be indened by a tab only.

> diff --git a/gcc/config/aarch64/aarch64-simd.md 
> b/gcc/config/aarch64/aarch64-simd.md
> index 
> c4858ab7cffd786066646a5cd95a168311990b76..bdc26c190610580e57e9749804b7729ee4e34793
>  100644
> --- a/gcc/config/aarch64/aarch64-simd.md
> +++ b/gcc/config/aarch64/aarch64-simd.md
> @@ -7027,3 +7027,37 @@
>"xtn\t%0., %1."
>[(set_attr "type" "neon_shift_imm_narrow_q")]
>  )
> +
> +(define_insn "aarch64_bfdot"
> +  [(set (match_operand:VDQSF 0 "register_operand" "=w")
> + (plus:VDQSF (match_operand:VDQSF 1 "register_operand" "0")
> + (unspec:VDQSF [(match_operand: 2
> + "register_operand" "w")
> +(match_operand: 3
> + "register_operand" "w")]
> +UNSPEC_BFDOT)))]

The operands to the plus should be the other way around, so that
the more complicated operand comes first,

> +  "TARGET_BF16_SIMD"
> +  "bfdot\t%0., %2., %3."
> +  [(set_attr "type" "neon_dot")]
> +)
> +
> +
> +(define_insn "aarch64_bfdot_lane"
> +  [(set (match_operand:VDQSF 0 "register_operand" "=w")
> + (plus:VDQSF (match_operand:VDQSF 1 "register_operand" "0")
> + (unspec:VDQSF [(match_operand: 2
> + "register_operand" "w")
> +(match_operand: VBF 3

Nit: should be no space before "VBF".

> + "register_operand" "w")
> +(match_operand:SI 4
> + "const_int_operand" "n")]
> +UNSPEC_BFDOT)))]
> +  "TARGET_BF16_SIMD"
> +{
> +  int nunits = GET_MODE_NUNITS (mode).to_constant ();
> +  int lane = INTVAL (operands[4]);
> +  operands[4] =  gen_int_mode (ENDIAN_LANE_N (nunits / 2, lane), SImode);

Should only be one space after "=".

> +  return "bfdot\t%0., %2., %3.2h[%4]";
> +}
> +  [(set_attr "type" "neon_dot")]
> +)
> diff --git a/gcc/config/aarch64/arm_neon.h b/gcc/config/aarch64/arm_neon.h
> index 
> 5996df0a612caff3c881fc15b0aa12b8f91a193b..0357d97cc4143c3a9c56260d9a9cc24138afc049
>  100644
> --- a/gcc/config/aarch64/arm_neon.h
> +++ b/gcc/config/aarch64/arm_neon.h
> @@ -34612,6 +34612,57 @@ vrnd64xq_f64 (float64x2_t __a)
>  
>  #include "arm_bf16.h"
>  
> +#pragma GCC push_options
> +#pragma GCC target ("arch=armv8.2-a+bf16")
> +
> +__extension__ extern __inline float32x2_t
> +__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
> +vbfdot_f32 (float32x2_t __r, bfloat16x4_t __a, bfloat16x4_t __b)
> +{
> +  return __builtin_aarch64_bfdotv2sf (__r, __a, __b);
> +}
> +
> +__extension__ extern __inline float32x4_t
> +__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
> +vbfdotq_f32 (float32x4_t __r, bfloat16x8_t __a, bfloat16x8_t __b)
> +{
> +  return __builtin_aarch64_bfdotv4sf (__r, __a, __b);
> +}
> +
> +__extension__ extern __inline float32x2_t
> +__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
> +vbfdot_lane_f32 \
> +  (float32x2_t __r, bfloat16x4_t __a, bfloat16x4_t __b, const int 
> __index)

Stray backslash (same comment as for the USDOT/SUDOT review
just posted).

> diff --git 
> a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/bfdot-compile-1.c 
> b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/bfdot-compile-1.c
> new file mode 100644
> index 
> ..62ac715c2a9c4468eb7c143464390dbf1144d6d6
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/bfdot-compile-1.c
> @@ -0,0 +1,80 @@
> +/* { dg-do assemble { target { aarch64*-*-* } 

[GCC][PATCH][ARM] Add Bfloat16_t scalar type, vector types and machine modes to ARM back-end

2019-12-20 Thread Stam Markianos-Wright
Hi all,

This patch was developed at the same time as the aarch64 version. Richards' 
feedback on that one also applies here and we'll be addressing them in a respin.

However, it's still useful to get this up for everyone (including ARM 
maintainers) to look and and comment, too.

For reference , the latest emails in the Aarch64 thread are at:
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01364.html
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01362.html

(The respin will also be split into two in a similar fashion to the Aarch64 
version)

Regression testing on arm-none-eabi passed successfully.

This patch depends on:

https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00857.html

for test suite effective_target update.

Cheers,
Stam


ACLE documents are at https://developer.arm.com/docs/101028/latest
ISA documents are at https://developer.arm.com/docs/ddi0596/latest

Details on ARM Bfloat can be found here:
https://community.arm.com/developer/ip-products/processors/b/ml-ip-blog/posts/bfloat16-processing-for-neural-networks-on-armv8_2d00_a
 



gcc/ChangeLog:

2019-12-16  Stam Markianos-Wright  

* config.gcc: Add arm_bf16.h.
* config/arm/arm-builtins.c (arm_mangle_builtin_type): Fix comment.
(arm_simd_builtin_std_type): Add BFmode.
(arm_init_simd_builtin_types): Define element types for vector types.
(arm_init_bf16_types): New function.
(arm_init_builtins): Add arm_init_bf16_types function call.
* config/arm/arm-modes.def: Add BFmode and V4BF, V8BF vector modes.
* config/arm/arm-simd-builtin-types.def: Add V4BF, V8BF.
* config/arm/arm.c (aapcs_vfp_sub_candidate): Add BFmode.
(arm_hard_regno_mode_ok): Add BFmode and tidy up statements.
(arm_vector_mode_supported_p): Add V4BF, V8BF.
(arm_invalid_conversion): New function for target hook.
(arm_invalid_unary_op): New function for target hook.
(arm_invalid_binary_op): New function for target hook.
* config/arm/arm.h: Add V4BF, V8BF to VALID_NEON_DREG_MODE,
  VALID_NEON_QREG_MODE respectively. Add export arm_bf16_type_node,
  arm_bf16_ptr_type_node.
* config/arm/arm.md: New enabled_for_bfmode_scalar,
  enabled_for_bfmode_vector attributes. Add BFmode to movhf expand.
  pattern and define_split between ARM registers.
* config/arm/arm_bf16.h: New file.
* config/arm/arm_neon.h: Add arm_bf16.h and Bfloat vector types.
* config/arm/iterators.md (ANY64_BF, VDXMOV, VHFBF, HFBF, fporbf): New.
  (VQXMOV): Add V8BF.
* config/arm/neon.md: Add BF vector types to NEON move patterns.
* config/arm/vfp.md: Add BFmode to movhf_vfp pattern.

2019-12-16  Stam Markianos-Wright  

* gcc.target/arm/bfloat16_compile-1.c: New test.
* gcc.target/arm/bfloat16_compile-2.c: New test.
* gcc.target/arm/bfloat16_compile-3.c: New test.
* gcc.target/arm/bfloat16_compile-4.c: New test.
* gcc.target/arm/bfloat16_scalar_typecheck.c: New test.
* gcc.target/arm/bfloat16_vector_typecheck1.c: New test.
* gcc.target/arm/bfloat16_vector_typecheck2.c: New test.

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 5aa0130135fa3ce95df502b3f84e78832b368375..bf1b6319643cf21970495f846392983255bd 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -344,7 +344,7 @@ arc*-*-*)
 arm*-*-*)
 	cpu_type=arm
 	extra_objs="arm-builtins.o aarch-common.o"
-	extra_headers="mmintrin.h arm_neon.h arm_acle.h arm_fp16.h arm_cmse.h"
+	extra_headers="mmintrin.h arm_neon.h arm_acle.h arm_fp16.h arm_cmse.h arm_bf16.h"
 	target_type_format_char='%'
 	c_target_objs="arm-c.o"
 	cxx_target_objs="arm-c.o"
diff --git a/gcc/config/arm/arm-builtins.c b/gcc/config/arm/arm-builtins.c
index 2d902d0b325bc1fe5e22831ef8a59a2bb37c1225..b998a4b935d522ca9ec7b5a928fc6bcc6649d5a3 100644
--- a/gcc/config/arm/arm-builtins.c
+++ b/gcc/config/arm/arm-builtins.c
@@ -315,12 +315,14 @@ arm_set_sat_qualifiers[SIMD_MAX_BUILTIN_ARGS]
 #define v8qi_UP  E_V8QImode
 #define v4hi_UP  E_V4HImode
 #define v4hf_UP  E_V4HFmode
+#define v4bf_UP  E_V4BFmode
 #define v2si_UP  E_V2SImode
 #define v2sf_UP  E_V2SFmode
 #define di_UPE_DImode
 #define v16qi_UP E_V16QImode
 #define v8hi_UP  E_V8HImode
 #define v8hf_UP  E_V8HFmode
+#define v8bf_UP  E_V8BFmode
 #define v4si_UP  E_V4SImode
 #define v4sf_UP  E_V4SFmode
 #define v2di_UP  E_V2DImode
@@ -328,9 +330,10 @@ arm_set_sat_qualifiers[SIMD_MAX_BUILTIN_ARGS]
 #define ei_UP	 E_EImode
 #define oi_UP	 E_OImode
 #define hf_UP	 E_HFmode
+#define bf_UPE_BFmode
 #define si_UP	 E_SImode
 #define void_UP	 E_VOIDmode
-
+#define sf_UP	 E_SFmode
 #define UP(X) X##_UP
 
 typedef struct {
@@ -806,6 +809,11 @@ static struct arm_simd_type_info arm_simd_types [] = {
 
 /* The user-visible __fp16 type.  */
 tree arm_fp16_type_node = NULL_TREE;
+
+/* Back-end node type for brain float (bfloat) types.  */
+tree arm_bf16_type_node = NULL_TREE;
+tree arm_bf16_ptr_type_node = 

OpenACC regression and development pace

2019-12-20 Thread Thomas Koenig

Hi, I just saw this:

FAIL: gfortran.dg/goacc/finalize-1.f   -O   scan-tree-dump-times gimple 
"(?n)#pragma omp target oacc_enter_exit_data 
map\\(delete:MEM\\[\\(c_char \\*\\)[^\\]]+\\] \\[len: [^\\]]+\\]\\) 
map\\(to:del_f_p \\[pointer set, len: [0-9]+\\]\\) 
map\\(alloc:del_f_p\\.data \\[pointer assign, bias: [^\\]]+\\]\\) 
finalize$" 1
FAIL: gfortran.dg/goacc/finalize-1.f   -O   scan-tree-dump-times gimple 
"(?n)#pragma omp target oacc_enter_exit_data 
map\\(force_from:MEM\\[\\(c_char \\*\\)[^\\]]+\\] \\[len: [^\\]]+\\]\\) 
map\\(to:cpo_f_p \\[pointer set, len: [0-9]+\\]\\) 
map\\(alloc:cpo_f_p\\.data \\[pointer assign, bias: [^\\]]+\\]\\) 
finalize$" 1


Regarding what is currently going on with OpenACC: I do not claim to
understand this area of the compiler, but it certainly seems that the
current development is too hasty - too many patches flying around,
too many regressions occurring.  It might be better to slow this
down somewhat, and to conduct a more throrough review process before
committing.

Regards

Thomas


[pach, fortran] Fix PR 92961, ICE on division by zero error in array bounds

2019-12-20 Thread Thomas Koenig

Hello world,

the attached patch fixes an ICE in an array declaration where the
specified size came from 0/0. This is an 8/9/10 regression.

The actual ICE fix was the NULL check in simplify_intrinsic_op, which in
turn led to strange error messages, which are then corrected by
the rest of the patch. Rather than try to transport state across I
do not know how many levels of calls, I chose a global variable.

Regression-tested. OK for all affected branches?

Regards

Thomas

2019-12-20  Thomas Koenig  

PR fortran/92961
* gfortran.h (gfc_seen_div0): Add declaration.
* arith.h (gfc_seen_div0): Add definition.
(eval_intrinsic): For integer division by zero, issue
gfc_error_now and set gfc_seen_div0.
* decl.c (variable_decl): If a division by zero error has been
seen previously, do not issue an addtional error.
* expr.c (simplify_intrinsic_op): Return NULL if op1 is NULL.

2019-12-20  Thomas Koenig  

PR fortran/92961
* gfortran.dg/arith_divide_2.f90: New test.
Index: gfortran.h
===
--- gfortran.h	(Revision 279639)
+++ gfortran.h	(Arbeitskopie)
@@ -2995,6 +2995,8 @@ void gfc_arith_done_1 (void);
 arith gfc_check_integer_range (mpz_t p, int kind);
 bool gfc_check_character_range (gfc_char_t, int);
 
+extern bool gfc_seen_div0;
+
 /* trans-types.c */
 bool gfc_check_any_c_kind (gfc_typespec *);
 int gfc_validate_kind (bt, int, bool);
Index: arith.c
===
--- arith.c	(Revision 279639)
+++ arith.c	(Arbeitskopie)
@@ -32,6 +32,8 @@ along with GCC; see the file COPYING3.  If not see
 #include "target-memory.h"
 #include "constructor.h"
 
+bool gfc_seen_div0;
+
 /* MPFR does not have a direct replacement for mpz_set_f() from GMP.
It's easily implemented with a few calls though.  */
 
@@ -1617,7 +1619,15 @@ eval_intrinsic (gfc_intrinsic_op op,
 
   if (rc != ARITH_OK)
 {
-  gfc_error (gfc_arith_error (rc), >where);
+  if (rc == ARITH_DIV0 && op2->ts.type == BT_INTEGER)
+	{
+	  gfc_error_now (gfc_arith_error (rc), >where);
+	  gfc_seen_div0 = true;
+	  return NULL;
+	}
+  else
+	gfc_error (gfc_arith_error (rc), >where);
+
   if (rc == ARITH_OVERFLOW)
 	goto done;
   return NULL;
Index: decl.c
===
--- decl.c	(Revision 279639)
+++ decl.c	(Arbeitskopie)
@@ -2535,6 +2535,10 @@ variable_decl (int elem)
 	  goto cleanup;
 	}
 
+  /* eval_intrinsic may signal a division by zero.  */
+
+  gfc_seen_div0 = false;
+
   /* F2018:C830 (R816) An explicit-shape-spec whose bounds are not
 	 constant expressions shall appear only in a subprogram, derived
 	 type definition, BLOCK construct, or interface body.  */
@@ -2573,7 +2577,15 @@ variable_decl (int elem)
 
 	  if (not_constant)
 	{
-	  gfc_error ("Explicit shaped array with nonconstant bounds at %C");
+	  /* If there is a division by zero error, it will have been reported
+		 previously using gfc_error_now in eval_intrinsic.  */
+
+	  if (!gfc_seen_div0)
+		gfc_error ("Explicit shaped array with nonconstant bounds at "
+			   "%C");
+
+	  gfc_seen_div0 = false;
+
 	  m = MATCH_ERROR;
 	  goto cleanup;
 	}
Index: expr.c
===
--- expr.c	(Revision 279639)
+++ expr.c	(Arbeitskopie)
@@ -1153,6 +1153,9 @@ simplify_intrinsic_op (gfc_expr *p, int type)
   op2 = p->value.op.op2;
   op  = p->value.op.op;
 
+  if (op1 == NULL)
+return false;
+
   if (!gfc_simplify_expr (op1, type))
 return false;
   if (!gfc_simplify_expr (op2, type))
! { dg-do compile }
! This used to ICE. Original test case by Gerhard Steinmetz.
program p
   integer :: a((0)/0)! { dg-error "Division by zero" }
   integer :: b(0/(0))! { dg-error "Division by zero" }
   integer :: c((0)/(0))  ! { dg-error "Division by zero" }
   integer :: d(0/0)  ! { dg-error "Division by zero" }
end


Re: [GCC][PATCH][AArch64]Add ACLE intrinsics for dot product (usdot - vector, dot - by element) for AArch64 AdvSIMD ARMv8.6 Extension

2019-12-20 Thread Richard Sandiford
Stam Markianos-Wright  writes:
> diff --git a/gcc/config/aarch64/aarch64-simd.md 
> b/gcc/config/aarch64/aarch64-simd.md
> index 
> ad4676bc167f08951e693916c7ef796e3501762a..eba71f004ef67af654f9c512b720aa6cfdd1d7fc
>  100644
> --- a/gcc/config/aarch64/aarch64-simd.md
> +++ b/gcc/config/aarch64/aarch64-simd.md
> @@ -506,6 +506,19 @@
>[(set_attr "type" "neon_dot")]
>  )
>  
> +;; These instructions map to the __builtins for the armv8.6a I8MM usdot
> +;; (vector) Dot Product operation.
> +(define_insn "aarch64_usdot"
> +  [(set (match_operand:VS 0 "register_operand" "=w")
> + (plus:VS (match_operand:VS 1 "register_operand" "0")
> + (unspec:VS [(match_operand: 2 "register_operand" "w")
> + (match_operand: 3 "register_operand" "w")]
> + UNSPEC_USDOT)))]
> +  "TARGET_SIMD && TARGET_I8MM"
> +  "usdot\\t%0., %2., %3."
> +  [(set_attr "type" "neon_dot")]
> +)
> +
>  ;; These expands map to the Dot Product optab the vectorizer checks for.
>  ;; The auto-vectorizer expects a dot product builtin that also does an
>  ;; accumulation into the provided register.

Sorry for not raising it last time, but this should just be "TARGET_I8MM".
TARGET_SIMD is always true when TARGET_I8MM is.

> @@ -573,6 +586,25 @@
>[(set_attr "type" "neon_dot")]
>  )
>  
> +;; These instructions map to the __builtins for the armv8.6a I8MM usdot, 
> sudot
> +;; (by element) Dot Product operations.
> +(define_insn "aarch64_dot_lane"
> +  [(set (match_operand:VS 0 "register_operand" "=w")
> + (plus:VS (match_operand:VS 1 "register_operand" "0")
> + (unspec:VS [(match_operand: 2 "register_operand" "w")
> + (match_operand:VB 3 "register_operand" "w")
> + (match_operand:SI 4 "immediate_operand" "i")]
> + DOTPROD_I8MM)))]
> +  "TARGET_SIMD && TARGET_I8MM"
> +  {
> +int nunits = GET_MODE_NUNITS (mode).to_constant ();
> +int lane = INTVAL (operands[4]);
> +operands[4] = gen_int_mode (ENDIAN_LANE_N (nunits / 4, lane), SImode);
> +return "dot\\t%0., %2., 
> %3.4b[%4]";
> +  }
> +  [(set_attr "type" "neon_dot")]
> +)
> +
>  (define_expand "copysign3"
>[(match_operand:VHSDF 0 "register_operand")
> (match_operand:VHSDF 1 "register_operand")

Same here.  Another thing I should have noticed last time is that the
canonical order for (plus ...) is to have the more complicated expression
first.  Operand 1 and the (unpec ...) should therefore be the other
way around in the expression above.  (Having operand 1 "later" than
operands 2, 3 and 4 is OK.)

> diff --git a/gcc/config/aarch64/arm_neon.h b/gcc/config/aarch64/arm_neon.h
> index 
> 8b861601a48b2150aa5768d717c61e0d1416747f..95b92dff69343e2b6c74174b39f3cd9d9838ddab
>  100644
> --- a/gcc/config/aarch64/arm_neon.h
> +++ b/gcc/config/aarch64/arm_neon.h
> @@ -34606,6 +34606,89 @@ vrnd64xq_f64 (float64x2_t __a)
>  
>  #pragma GCC pop_options
>  
> +/* AdvSIMD 8-bit Integer Matrix Multiply (I8MM) intrinsics.  */
> +
> +#pragma GCC push_options
> +#pragma GCC target ("arch=armv8.2-a+i8mm")
> +
> +__extension__ extern __inline int32x2_t
> +__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
> +vusdot_s32 (int32x2_t __r, uint8x8_t __a, int8x8_t __b)
> +{
> +  return __builtin_aarch64_usdotv8qi_ssus (__r, __a, __b);
> +}
> +
> +__extension__ extern __inline int32x4_t
> +__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
> +vusdotq_s32 (int32x4_t __r, uint8x16_t __a, int8x16_t __b)
> +{
> +  return __builtin_aarch64_usdotv16qi_ssus (__r, __a, __b);
> +}
> +
> +__extension__ extern __inline int32x2_t
> +__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
> +vusdot_lane_s32 (int32x2_t __r, uint8x8_t __a, int8x8_t __b, const int 
> __index)
> +{
> +  return __builtin_aarch64_usdot_lanev8qi_ssuss (__r, __a, __b, __index);
> +}
> +
> +__extension__ extern __inline int32x2_t
> +__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
> +vusdot_laneq_s32 \
> +  (int32x2_t __r, uint8x8_t __a, int8x16_t __b, const int __index)

Stray backslash.  It's probably easier to split the line after "__b,"
instead of before "(".  Same for later function.

> diff --git 
> a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vdot-compile-3-1.c 
> b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vdot-compile-3-1.c
> new file mode 100755
> index 
> ..6a4ff054589b736c224bb2fabdcfa48439a8a420
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vdot-compile-3-1.c
> @@ -0,0 +1,133 @@
> +/* { dg-do assemble { target { aarch64*-*-* } } } */
> +/* { dg-require-effective-target arm_v8_2a_i8mm_ok } */
> +/* { dg-add-options arm_v8_2a_i8mm }  */
> +/* { dg-additional-options "--save-temps" } */
> +/* { dg-final { check-function-bodies "**" "" "-DCHECK_ASM" } } */
> +
> +#include 
> +
> +/* Unsigned-Signed Dot Product instructions.  */
> +
> +/*
> +**ufoo:
> +**   

[GCC][PATCH][AArch64]Add ACLE intrinsics for bfdot for ARMv8.6 Extension

2019-12-20 Thread Stam Markianos-Wright
Hi all,

This patch adds the ARMv8.6 Extension ACLE intrinsics for the bfloat bfdot 
operation.

The functions are declared in arm_neon.h with the armv8.2-a+bf16 target option 
as required.

RTL patterns are defined to generate assembler.

Tests added to verify expected assembly and perform adequate lane checks.

This patch depends on:

https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00857.html

for testuite effective_target update and on:

https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01323.html
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01324.html

for back-end Bfloat enablement.

Cheers,
Stam


gcc/ChangeLog:

2019-11-04  Stam Markianos-Wright  

* config/aarch64/aarch64-simd-builtins.def (aarch64_bfdot,
   aarch64_bfdot_lane, aarch64_bfdot_laneq): New.
* config/aarch64/aarch64-simd.md
   (aarch64_bfdot, aarch64_bfdot_lane): New.
* config/aarch64/arm_neon.h (vbfdot_f32, vbfdotq_f32, vbfdot_lane_f32,
   vbfdotq_lane_f32, vbfdot_laneq_f32, vbfdotq_laneq_f32): New.
* config/aarch64/iterators.md (UNSPEC_BFDOT, VBF, isquadop, Vbfdottype,
   VBFMLA_W): New.

gcc/testsuite/ChangeLog:

2019-11-04  Stam Markianos-Wright  

* gcc.target/aarch64/advsimd-intrinsics/bfdot-compile-1.c: New.
* gcc.target/aarch64/advsimd-intrinsics/bfdot-compile-2.c: New.
* gcc.target/aarch64/advsimd-intrinsics/bfdot-compile-3.c: New.
diff --git a/gcc/config/aarch64/aarch64-simd-builtins.def b/gcc/config/aarch64/aarch64-simd-builtins.def
index f4ca35a59704c761fe2ac2b6d401fff7c8aba80d..6c5b61c37bcb340f963861723c6e365e32f6ca95 100644
--- a/gcc/config/aarch64/aarch64-simd-builtins.def
+++ b/gcc/config/aarch64/aarch64-simd-builtins.def
@@ -682,3 +682,8 @@
   BUILTIN_VSFDF (UNOP, frint32x, 0)
   BUILTIN_VSFDF (UNOP, frint64z, 0)
   BUILTIN_VSFDF (UNOP, frint64x, 0)
+
+  /* Implemented by aarch64_bfdot{_lane}{q}.  */
+  VAR2 (TERNOP, bfdot, 0, v2sf, v4sf)
+  VAR2 (QUADOP_LANE_PAIR, bfdot_lane, 0, v2sf, v4sf)
+  VAR2 (QUADOP_LANE_PAIR, bfdot_laneq, 0, v2sf, v4sf)
diff --git a/gcc/config/aarch64/aarch64-simd.md b/gcc/config/aarch64/aarch64-simd.md
index c4858ab7cffd786066646a5cd95a168311990b76..bdc26c190610580e57e9749804b7729ee4e34793 100644
--- a/gcc/config/aarch64/aarch64-simd.md
+++ b/gcc/config/aarch64/aarch64-simd.md
@@ -7027,3 +7027,37 @@
   "xtn\t%0., %1."
   [(set_attr "type" "neon_shift_imm_narrow_q")]
 )
+
+(define_insn "aarch64_bfdot"
+  [(set (match_operand:VDQSF 0 "register_operand" "=w")
+	(plus:VDQSF (match_operand:VDQSF 1 "register_operand" "0")
+		(unspec:VDQSF [(match_operand: 2
+		"register_operand" "w")
+   (match_operand: 3
+		"register_operand" "w")]
+   UNSPEC_BFDOT)))]
+  "TARGET_BF16_SIMD"
+  "bfdot\t%0., %2., %3."
+  [(set_attr "type" "neon_dot")]
+)
+
+
+(define_insn "aarch64_bfdot_lane"
+  [(set (match_operand:VDQSF 0 "register_operand" "=w")
+	(plus:VDQSF (match_operand:VDQSF 1 "register_operand" "0")
+		(unspec:VDQSF [(match_operand: 2
+		"register_operand" "w")
+   (match_operand: VBF 3
+		"register_operand" "w")
+   (match_operand:SI 4
+		"const_int_operand" "n")]
+   UNSPEC_BFDOT)))]
+  "TARGET_BF16_SIMD"
+{
+  int nunits = GET_MODE_NUNITS (mode).to_constant ();
+  int lane = INTVAL (operands[4]);
+  operands[4] =  gen_int_mode (ENDIAN_LANE_N (nunits / 2, lane), SImode);
+  return "bfdot\t%0., %2., %3.2h[%4]";
+}
+  [(set_attr "type" "neon_dot")]
+)
diff --git a/gcc/config/aarch64/arm_neon.h b/gcc/config/aarch64/arm_neon.h
index 5996df0a612caff3c881fc15b0aa12b8f91a193b..0357d97cc4143c3a9c56260d9a9cc24138afc049 100644
--- a/gcc/config/aarch64/arm_neon.h
+++ b/gcc/config/aarch64/arm_neon.h
@@ -34612,6 +34612,57 @@ vrnd64xq_f64 (float64x2_t __a)
 
 #include "arm_bf16.h"
 
+#pragma GCC push_options
+#pragma GCC target ("arch=armv8.2-a+bf16")
+
+__extension__ extern __inline float32x2_t
+__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
+vbfdot_f32 (float32x2_t __r, bfloat16x4_t __a, bfloat16x4_t __b)
+{
+  return __builtin_aarch64_bfdotv2sf (__r, __a, __b);
+}
+
+__extension__ extern __inline float32x4_t
+__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
+vbfdotq_f32 (float32x4_t __r, bfloat16x8_t __a, bfloat16x8_t __b)
+{
+  return __builtin_aarch64_bfdotv4sf (__r, __a, __b);
+}
+
+__extension__ extern __inline float32x2_t
+__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
+vbfdot_lane_f32 \
+  (float32x2_t __r, bfloat16x4_t __a, bfloat16x4_t __b, const int __index)
+{
+  return __builtin_aarch64_bfdot_lanev2sf (__r, __a, __b, __index);
+}
+
+__extension__ extern __inline float32x4_t
+__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
+vbfdotq_lane_f32 \
+  (float32x4_t __r, bfloat16x8_t __a, bfloat16x4_t __b, const int __index)
+{
+  return __builtin_aarch64_bfdot_lanev4sf (__r, __a, __b, __index);
+}
+
+__extension__ extern __inline float32x2_t
+__attribute__ ((__always_inline__, __gnu_inline__, 

Re: [GCC][testsuite][ARM][AArch64] Add ARM v8.6 effective target checks to target-supports.exp

2019-12-20 Thread Stam Markianos-Wright


On 12/18/19 4:47 PM, Richard Sandiford wrote:
> Stam Markianos-Wright  writes:
>> On 12/13/19 11:15 AM, Richard Sandiford wrote:
>>> Stam Markianos-Wright  writes:
 Hi all,

 This small patch adds support for the ARM v8.6 extensions +bf16 and
 +i8mm to the testsuite. This will be tested through other upcoming
 patches, which is why we are not providing any explicit tests here.

 Ok for trunk?

 Also I don't have commit rights, so if someone could commit on my
 behalf, that would be great :)

 The functionality here depends on CLI patches:
 https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02415.html
 https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02195.html

 but this patch applies cleanly without them, too.

 Cheers,
 Stam


 gcc/testsuite/ChangeLog:

 2019-12-11  Stam Markianos-Wright  

* lib/target-supports.exp
(check_effective_target_arm_v8_2a_i8mm_ok_nocache): New.
(check_effective_target_arm_v8_2a_i8mm_ok): New.
(add_options_for_arm_v8_2a_i8mm): New.
(check_effective_target_arm_v8_2a_bf16_neon_ok_nocache): New.
(check_effective_target_arm_v8_2a_bf16_neon_ok): New.
(add_options_for_arm_v8_2a_bf16_neon): New.
>>>
>>> The new effective-target keywords need to be documented in
>>> doc/sourcebuild.texi.
>>
>> Added in new diff :)
>>
>>>
>>> LGTM otherwise.  For:
>>>
 diff --git a/gcc/testsuite/lib/target-supports.exp 
 b/gcc/testsuite/lib/target-supports.exp
 index 5b4cc02f921..36fb63e9929 100644
 --- a/gcc/testsuite/lib/target-supports.exp
 +++ b/gcc/testsuite/lib/target-supports.exp
 @@ -4781,6 +4781,49 @@ proc add_options_for_arm_v8_2a_dotprod_neon { flags 
 } {
return "$flags $et_arm_v8_2a_dotprod_neon_flags"
}

 +# Return 1 if the target supports ARMv8.2+i8mm Adv.SIMD Dot Product
 +# instructions, 0 otherwise.  The test is valid for ARM and for AArch64.
 +# Record the command line options needed.
 +
 +proc check_effective_target_arm_v8_2a_i8mm_ok_nocache { } {
 +global et_arm_v8_2a_i8mm_flags
 +set et_arm_v8_2a_i8mm_flags ""
 +
 +if { ![istarget arm*-*-*] && ![istarget aarch64*-*-*] } {
 +return 0;
 +}
 +
 +# Iterate through sets of options to find the compiler flags that
 +# need to be added to the -march option.
 +foreach flags {"" "-mfloat-abi=hard -mfpu=neon-fp-armv8" 
 "-mfloat-abi=softfp -mfpu=neon-fp-armv8" } {
 +if { [check_no_compiler_messages_nocache \
 +  arm_v8_2a_i8mm_ok object {
 +#include 
 +#if !defined (__ARM_FEATURE_MATMUL_INT8)
 +#error "__ARM_FEATURE_MATMUL_INT8 not defined"
 +#endif
 +} "$flags -march=armv8.2-a+i8mm"] } {
 +set et_arm_v8_2a_i8mm_flags "$flags -march=armv8.2-a+i8mm"
 +return 1
 +}
 +}
>>>
>>> I wondered whether it would be better to add no options if testing
>>> with something that already supports i8mm (e.g. -march=armv8.6).
>>> That would mean trying:
>>>
>>> "" "-march=armv8.2-a+i8mm" "-march=armv8.2-a+i8mm -mfloat-abi..." ...
>>>
>>> instead.  But there are arguments both ways, and the above follows
>>> existing style, so OK.
>>
>> Not quite sure if I understanding this right, but I think that's what
>> the "" option in foreach flags{} is for?
>>
>> i.e. currently what I'm seeing is:
>>
>> +/* { dg-require-effective-target arm_v8_2a_i8mm_ok } */
>> +/* { dg-add-options arm_v8_2a_i8mm }  */
>>
>> will pull through the first option that compiles to object file with no
>> errors (check_no_compiler_messages_nocache arm_v8_2a_i8mm_ok object).
>>
>> So in a lot of cases it should just be fine for "" and only pull in
>> -march=armv8.2-a+i8mm.
>>
>> I think that's right? Lmk if I'm not reading it properly!
> 
> Yeah, that's right, but it's also the "problem".  The point was that
> some people will run the tests with options like -march=armv8.6-a that
> already support these instructions, e.g. using
> 
>--target_board unix/-march=armv8.6-a
> 
> on a native box.  The code above will then override that -march option
> with -march=armv8.2-a+i8mm even though the original option was OK.
> The tests won't then actually get run with -march=armv8.6-a as the
> dominant option, despite being Armv8.6 tests. :-)
> 
> The alternative above would have tried with no options at all and only
> added -march= if that failed.  But like I say, the current version
> follows existing practice and so is fine too.


Oh right, I get you now, thank you so much for elaborating! :D

So maybe it might be a good idea to get this in as is, i.e. following existing 
practice, and then make a note internally to come back to this as a quality 
issue at a later date (since the same comment applies to many of these 
effective-target 

Re: [GCC][PATCH][AArch64]Add ACLE intrinsics for dot product (usdot - vector, dot - by element) for AArch64 AdvSIMD ARMv8.6 Extension

2019-12-20 Thread Stam Markianos-Wright


On 12/13/19 11:02 AM, Richard Sandiford wrote:
> Stam Markianos-Wright  writes:
>> @@ -573,6 +586,44 @@
>> [(set_attr "type" "neon_dot")]
>>   )
>>   
>> +;; These instructions map to the __builtins for the armv8.6a I8MM usdot, 
>> sudot
>> +;; (by element) Dot Product operations.
>> +(define_insn "aarch64_dot_lane"
>> +  [(set (match_operand:VS 0 "register_operand" "=w")
>> +(plus:VS (match_operand:VS 1 "register_operand" "0")
>> +(unspec:VS [(match_operand: 2 "register_operand" "w")
>> +(match_operand:V8QI 3 "register_operand" "")
>> +(match_operand:SI 4 "immediate_operand" "i")]
>> +DOTPROD_I8MM)))]
>> +  "TARGET_SIMD && TARGET_I8MM"
>> +  {
>> +int nunits = GET_MODE_NUNITS (V8QImode).to_constant ();
>> +int lane = INTVAL (operands[4]);
>> +operands[4]
>> +=  gen_int_mode (ENDIAN_LANE_N (nunits / 4, lane), SImode);
>> +return "dot\\t%0., %2., %3.4b[%4]";
>> +  }
>> +  [(set_attr "type" "neon_dot")]
>> +)
>> +
>> +(define_insn "aarch64_dot_laneq"
>> +  [(set (match_operand:VS 0 "register_operand" "=w")
>> +(plus:VS (match_operand:VS 1 "register_operand" "0")
>> +(unspec:VS [(match_operand: 2 "register_operand" "w")
>> +(match_operand:V16QI 3 "register_operand" "")
> 
> Using  seems a bit redundant when it's always "w" in this context,
> but either's fine.

Done!

> 
>> +(match_operand:SI 4 "immediate_operand" "i")]
>> +DOTPROD_I8MM)))]
>> +  "TARGET_SIMD && TARGET_I8MM"
>> +  {
>> +int nunits = GET_MODE_NUNITS (V16QImode).to_constant ();
>> +int lane = INTVAL (operands[4]);
>> +operands[4]
>> +=  gen_int_mode (ENDIAN_LANE_N (nunits / 4, lane), SImode);
> 
> Nit: = should be indented two spaces more, and there should be only
> one space afterwards.  But the statement fits on one line, so probably
> better not to have the line break at all.

I put put all onto one line.
> 
>> +return "dot\\t%0., %2., %3.4b[%4]";
>> +  }
>> +  [(set_attr "type" "neon_dot")]
>> +)
> 
> These two patterns can be merged using :VB for operand 3.

Merged them.

I also changed the tests to use the new check-function-bodies according to 
downstream comments.
This helps check that the assembler scans are done in the right order and 
ensures that the correct assembler was generated from the right function call 
(as opposed to "somewhere in the output file").

Hope this looks better :D

Cheers,
Stam
> 
> LGTM otherwise, thanks.
> 
> Richard
> 

diff --git a/gcc/config/aarch64/aarch64-builtins.c b/gcc/config/aarch64/aarch64-builtins.c
index c35a1b1f0299ce5af8ca1a3df0209614f7bd0f25..6bd26889f2f26a9f82dd6d40f50125eaeee41740 100644
--- a/gcc/config/aarch64/aarch64-builtins.c
+++ b/gcc/config/aarch64/aarch64-builtins.c
@@ -107,6 +107,9 @@ enum aarch64_type_qualifiers
   /* Lane indices selected in pairs. - must be in range, and flipped for
  bigendian.  */
   qualifier_lane_pair_index = 0x800,
+  /* Lane indices selected in quadtuplets. - must be in range, and flipped for
+ bigendian.  */
+  qualifier_lane_quadtup_index = 0x1000,
 };
 
 typedef struct
@@ -173,6 +176,10 @@ aarch64_types_ternopu_imm_qualifiers[SIMD_MAX_BUILTIN_ARGS]
   = { qualifier_unsigned, qualifier_unsigned,
   qualifier_unsigned, qualifier_immediate };
 #define TYPES_TERNOPUI (aarch64_types_ternopu_imm_qualifiers)
+static enum aarch64_type_qualifiers
+aarch64_types_ternop_ssus_qualifiers[SIMD_MAX_BUILTIN_ARGS]
+  = { qualifier_none, qualifier_none, qualifier_unsigned, qualifier_none };
+#define TYPES_TERNOP_SSUS (aarch64_types_ternop_ssus_qualifiers)
 
 
 static enum aarch64_type_qualifiers
@@ -191,6 +198,19 @@ aarch64_types_quadopu_lane_qualifiers[SIMD_MAX_BUILTIN_ARGS]
   qualifier_unsigned, qualifier_lane_index };
 #define TYPES_QUADOPU_LANE (aarch64_types_quadopu_lane_qualifiers)
 
+static enum aarch64_type_qualifiers
+aarch64_types_quadopssus_lane_quadtup_qualifiers[SIMD_MAX_BUILTIN_ARGS]
+  = { qualifier_none, qualifier_none, qualifier_unsigned,
+  qualifier_none, qualifier_lane_quadtup_index };
+#define TYPES_QUADOPSSUS_LANE_QUADTUP \
+	(aarch64_types_quadopssus_lane_quadtup_qualifiers)
+static enum aarch64_type_qualifiers
+aarch64_types_quadopsssu_lane_quadtup_qualifiers[SIMD_MAX_BUILTIN_ARGS]
+  = { qualifier_none, qualifier_none, qualifier_none,
+  qualifier_unsigned, qualifier_lane_quadtup_index };
+#define TYPES_QUADOPSSSU_LANE_QUADTUP \
+	(aarch64_types_quadopsssu_lane_quadtup_qualifiers)
+
 static enum aarch64_type_qualifiers
 aarch64_types_quadopu_imm_qualifiers[SIMD_MAX_BUILTIN_ARGS]
   = { qualifier_unsigned, qualifier_unsigned, qualifier_unsigned,
@@ -1260,6 +1280,7 @@ typedef enum
   SIMD_ARG_LANE_INDEX,
   SIMD_ARG_STRUCT_LOAD_STORE_LANE_INDEX,
   SIMD_ARG_LANE_PAIR_INDEX,
+  SIMD_ARG_LANE_QUADTUP_INDEX,
   SIMD_ARG_STOP
 } builtin_simd_arg;
 
@@ -1349,9 +1370,25 @@ aarch64_simd_expand_args (rtx target, int icode, int have_retval,

[PATCH] Fix versioned namespace test failures

2019-12-20 Thread François Dumont

Comitted as trivial.

After this I only have 1 failure left specific to versioned namespace in 
pretty printers tests.


    * testsuite/23_containers/map/48101_neg.cc: Add versioned namespace
    pattern to tested error message.
    * testsuite/23_containers/multimap/48101_neg.cc: Likewise.
    * testsuite/30_threads/headers/stop_token/synopsis.cc: Add
    dg-require-normal-namepace.

François

diff --git a/libstdc++-v3/testsuite/23_containers/map/48101_neg.cc b/libstdc++-v3/testsuite/23_containers/map/48101_neg.cc
index 8a7429c85a8..ed80ba6 100644
--- a/libstdc++-v3/testsuite/23_containers/map/48101_neg.cc
+++ b/libstdc++-v3/testsuite/23_containers/map/48101_neg.cc
@@ -29,8 +29,8 @@ test01()
   c2.find(2); // { dg-error "here" }
 }
 
-// { dg-error "_Compare = std::less" "" { target *-*-* } 0 }
-// { dg-error "_Compare = std::allocator" "" { target *-*-* } 0 }
+// { dg-error "_Compare = std::(__8::)?less" "" { target *-*-* } 0 }
+// { dg-error "_Compare = std::(__8::)?allocator" "" { target *-*-* } 0 }
 // { dg-error "comparison object must be invocable" "" { target *-*-* } 0 }
 // { dg-prune-output "no match for call" }
 // { dg-prune-output "invalid conversion" }
diff --git a/libstdc++-v3/testsuite/23_containers/multimap/48101_neg.cc b/libstdc++-v3/testsuite/23_containers/multimap/48101_neg.cc
index 7bd56cc9c73..513822cc96f 100644
--- a/libstdc++-v3/testsuite/23_containers/multimap/48101_neg.cc
+++ b/libstdc++-v3/testsuite/23_containers/multimap/48101_neg.cc
@@ -29,8 +29,8 @@ test01()
   c2.find(2); // { dg-error "here" }
 }
 
-// { dg-error "_Compare = std::less" "" { target *-*-* } 0 }
-// { dg-error "_Compare = std::allocator" "" { target *-*-* } 0 }
+// { dg-error "_Compare = std::(__8::)?less" "" { target *-*-* } 0 }
+// { dg-error "_Compare = std::(__8::)?allocator" "" { target *-*-* } 0 }
 // { dg-error "comparison object must be invocable" "" { target *-*-* } 0 }
 // { dg-prune-output "no match for call" }
 // { dg-prune-output "invalid conversion" }
diff --git a/libstdc++-v3/testsuite/30_threads/headers/stop_token/synopsis.cc b/libstdc++-v3/testsuite/30_threads/headers/stop_token/synopsis.cc
index b185bc7be39..59b3e772d99 100644
--- a/libstdc++-v3/testsuite/30_threads/headers/stop_token/synopsis.cc
+++ b/libstdc++-v3/testsuite/30_threads/headers/stop_token/synopsis.cc
@@ -17,6 +17,7 @@
 
 // { dg-options "-std=gnu++2a" }
 // { dg-do compile { target c++2a } }
+// { dg-require-normal-namespace "" }
 
 #include 
 


Re: [PATCH 10/13] OpenACC 2.6 deep copy: Fortran front-end parts

2019-12-20 Thread Tobias Burnus

Hi Julian,

thanks for the patch and the post-review fixes. (The revised patch was 
committed as r279628. And I have committed a few minor follow-up 
improvements.)


I still have an issues with the following.

On 12/18/19 11:51 PM, Tobias Burnus wrote:

+  /* Disallow duplicate bare variable references and multiple
+ subarrays of the same array here, but allow multiple 
components of
+ the same (e.g. derived-type) variable.  For the latter, 
duplicate

+ components are detected elsewhere.  */

Do we have a test case for "the latter"?


Seemingly, the latter is neither tested-for nor diagnosed:

type t
  integer, allocatable :: i
end type t
type(t) :: x

!$acc enter data copyin(x%i, x, x%i) ! Bad: accepted

!$acc data pcopy(x) pcopy(x) ! OK – rejected: Symbol 'x' present on multiple 
clauses at (1)
!$acc end data
end


Thirdly, I am not sure whether the following will work with your code:
…
!$acc data copy (x(:)%k, x(:)%j(3))

This data is strided; I don't quickly see whether that's rejected. (I 
also

didn't check whether it is valid, but I think it is not.)


For attach/detach, the crucial bit is that the sub-references are
*allocatable* or *pointer* variables, otherwise it does not make sense to
talk about attach/detach. — For those, already the Fortran semantic
gives an error. I have attached a test case (strided-alloc-ptr.f90),
which shows that this is correctly rejected.

However, the other question is how component access w/o allocatables
or pointers is handled (i.e. they are all in the same aggregated type).
I attached a test case for this (mapping-tests.f90).

In particular:
* "copy(x, x%k)" – rejected by OpenMP and, hence, OpenACC for C/C++
   Accepted by gfortran for OpenACC  (for gfortran: missing OpenMP 4.5 feature)

* "copy(y(:)%i)" – strided access, i.e. y(1)%i + y(2)%i + …
  Is this valid OpenACC or not?
  [Currently equivalent to "copy(y)"]

* "copy(z(1)%cc(:)%i)" – also strided access, but gives an ICE

See also: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93025

Tobias

implicit none
type t
  integer, allocatable :: i, j(:)
  integer, pointer :: k, ll(:)
end type t
type(t) :: x(2)

!$acc enter data copyin(x)

!$acc enter data copyin(x(:)%i)
! { dg-error "Component to the right of a part reference with nonzero rank must not have the ALLOCATABLE attribute" "" { target "*-*-*" } 10 }
! { dg-error "Error: 'x' in MAP clause at .1. is not a proper array section"  "" { target "*-*-*" } 10 }

!$acc enter data copyin(x(:)%j(3))
! { dg-error "Component to the right of a part reference with nonzero rank must not have the ALLOCATABLE attribute" "" { target "*-*-*" } 14 }
! { dg-error "Error: 'x' in MAP clause at .1. is not a proper array section"  "" { target "*-*-*" } 14 }

!$acc enter data copyin(x(:)%j)
! { dg-error "Component to the right of a part reference with nonzero rank must not have the ALLOCATABLE attribute" "" { target "*-*-*" } 18 }
! { dg-error "Error: 'x' in MAP clause at .1. is not a proper array section"  "" { target "*-*-*" } 18 }


!$acc enter data copyin(x(:)%k)
! { dg-error "Component to the right of a part reference with nonzero rank must not have the POINTER attribute" "" { target "*-*-*" } 23 }
! { dg-error "Error: 'x' in MAP clause at .1. is not a proper array section"  "" { target "*-*-*" } 23 }

!$acc enter data copyin(x(:)%ll(3))
! { dg-error "Component to the right of a part reference with nonzero rank must not have the POINTER attribute" "" { target "*-*-*" } 27 }
! { dg-error "Error: 'x' in MAP clause at .1. is not a proper array section"  "" { target "*-*-*" } 27 }

!$acc enter data copyin(x(:)%ll)
! { dg-error "Component to the right of a part reference with nonzero rank must not have the POINTER attribute" "" { target "*-*-*" } 31 }
! { dg-error "Error: 'x' in MAP clause at .1. is not a proper array section"  "" { target "*-*-*" } 31 }
end
subroutine foo
  type t
integer :: i, j
  end type t

  type t2
type(t) :: cc(3)
  end type t2

  type(t) x, y(3)
  type(t2) :: z(3)

  ! OK - map whole aggregated variable
!$acc enter data copyin(x)
  ! map(to:x [len: 8])

  ! OK - map two components of the aggregated variable
!$acc enter data copyin(x%j, x%i)
  ! map(struct:x [len: 2]) map(to:x.i [len: 4]) map(to:x.j [len: 4])

  ! WRONG? Accepted – but should it?
  ! Maps whole 'x' plus 'x%j' again.
  ! In gcc/g++ rejected for OpenMP and, hence, for OpenACC.
  ! - only "x.i, x.j" or "x" is accepted by OpenMP.
  ! gfortran: not yet implemented OpenMP 4.5 feature.
!$acc enter data copyin(x, x%i)
  !   map(to:x [len: 8]) map(to:x.i [len: 4])
  ! I think this only works by chance.

  ! WRONG? Strided access of 'x'
  ! No C/C++ equivalent
!$acc enter data copyin(y(:)%i)
  ! In terms of Fortran semantic this is equivalent to
  !   copyin(y(1)%i, y(2)%i, y(3)%i).
  ! Dump shows:
  !map(to:MEM[(c_char *)_6] [len: _5])
  ! which is  map(to:y [len: 3*sizeof(t)]),
  ! i.e. equivalent to "copyin(y)".
  ! I am not sure what the expected input is


[committed] Improve is-coindexed check for OpenACC/OpenMP (was: [PATCH 10/13] OpenACC 2.6 deep copy: Fortran front-end parts)

2019-12-20 Thread Tobias Burnus

Julian has committed that patch as Rev. 279628.

Follow up regarding coarrays:

I had proposed to use 'gfc_is_coindexed' instead of only checking the 
rightmost array reference. However, it turned out that this check comes 
too late. (As did the check before Julian's patch.)


Namely, when checking in resolve_omp_clauses the gfc_resolve_expr seems 
to have called – and this changes the expression.  Example: "A[2]" will 
be converted into a function call "_F.caf_get[[A]]" with -fcoarray=lib — 
or to "A" with -fcoarray=single.


Hence, I moved the coindexed check directly after parsing and added a 
test case for it. Coarrays by itself should be fine as they act as 
normal local variables – just that they are allocated by 
_gfortran_caf_register instead of malloc, stack or static allocation.


Committed as Rev. 279637.

Cheers,

Tobias

Index: gcc/testsuite/gfortran.dg/goacc/coindexed-1.f90
===
--- gcc/testsuite/gfortran.dg/goacc/coindexed-1.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/goacc/coindexed-1.f90	(revision 279637)
@@ -0,0 +1,37 @@
+! { dg-do compile }
+! { dg-additional-options "-fcoarray=single" }
+! 
+subroutine check_coindexed()
+implicit none
+type t
+  integer :: i
+end type t
+type t2
+  integer, allocatable :: i[:]
+  type(t), allocatable :: x[:]
+end type t2
+type(t), allocatable :: A(:)[:], B(:)[:]
+type(t) :: D(1)[*], E[*]
+type(t2) :: C
+save :: D, E
+
+! Coarrays are fine if they are local/not coindexed:
+
+!$acc enter data copyin(D(1)%i)
+!$acc enter data copyin(A(1))
+!$acc enter data copyin(B(1)%i)
+!$acc enter data copyin(C%i)
+!$acc enter data copyin(C%x%i) 
+!$acc enter data copyin(C%i)
+!$acc enter data copyin(C%x%i) 
+
+! Does not like the '[' after the identifier:
+!$acc enter data copyin(E[2]) ! { dg-error "Syntax error in OpenMP variable list" }
+
+!$acc enter data copyin(D(1)[2]%i) ! { dg-error "List item shall not be coindexed" }
+!$acc enter data copyin(A(1)[4])   ! { dg-error "List item shall not be coindexed" }
+!$acc enter data copyin(B(1)[4]%i) ! { dg-error "List item shall not be coindexed" }
+!$acc enter data copyin(C%i[2])! { dg-error "List item shall not be coindexed" }
+!$acc enter data copyin(C%x[4]%i)  ! { dg-error "List item shall not be coindexed" }
+
+end
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog	(revision 279636)
+++ gcc/testsuite/ChangeLog	(revision 279637)
@@ -1,5 +1,9 @@
 2019-12-20  Tobias Burnus  
 
+	* gfortran.dg/goacc/coindexed-1.f90: New.
+
+2019-12-20  Tobias Burnus  
+
 	* gfortran.dg/goacc/data-clauses.f95: Remove now
 	obsolete dg-error.
 
Index: gcc/fortran/openmp.c
===
--- gcc/fortran/openmp.c	(revision 279636)
+++ gcc/fortran/openmp.c	(revision 279637)
@@ -274,6 +274,11 @@
 		default:
 		  break;
 		}
+	  if (gfc_is_coindexed (expr))
+		{
+		  gfc_error ("List item shall not be coindexed at %C");
+		  goto cleanup;
+		}
 	}
 	  gfc_set_sym_referenced (sym);
 	  p = gfc_get_omp_namelist ();
@@ -4544,9 +4549,6 @@
 		  gfc_error ("%qs in %s clause at %L is not a proper "
  "array section", n->sym->name, name,
  >where);
-		else if (gfc_is_coindexed (n->expr))
-		  gfc_error ("Entry shall not be coindexed in %s "
- "clause at %L", name, >where);
 		else
 		  {
 			int i;
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog	(revision 279636)
+++ gcc/fortran/ChangeLog	(revision 279637)
@@ -1,3 +1,8 @@
+2019-12-20  Tobias Burnus  
+
+	* openmp.c (resolve_omp_clauses): Move is-coindexed check from here ...
+	(gfc_match_omp_variable_list): ... to here.
+
 2019-12-19  Julian Brown  
 
 	* openmp.c (resolve_oacc_data_clauses): Don't disallow allocatable


Re: [Patch, Fortran] PR 92996 – fix rank resolution EXPR_ARRAY

2019-12-20 Thread Thomas Koenig

Hi Tobias,


One has the choice between
(a) Using the location where the expression was defined (in the
     scoping unit) – currently done
     (i.e. replacing expr->where by expr->symtree->n.sym->where)
(b) using the location where the parameter is used, i.e. keeping
     expr->where despite simplification.


Or you could use both.  With the nice colorization of error messages
that David introduced gcc10, this is quite readable.

Hm... this would require an additional member in the gfc_expr structure.
While this may be a nice addition, it is certainly not necessary to get
this patch in.

So, OK for trunk, and thanks for the patch!

Regards

Thomas


[PATCH] MAINTAINERS: add myself

2019-12-20 Thread Jérôme Lambourg
Add myself to MAINTAINERS file

2019-12-20  Jerome Lambourg 

 * MAINTAINERS: Add myself to Write After Approval



maintainers.patch
Description: Binary data


Re: [PATCH] Fix pretty printers tests

2019-12-20 Thread Jonathan Wakely

On 13/12/19 22:27 +0100, François Dumont wrote:
Here is a patch to fix prettyprinters.exp failures in normal and debug 
modes.


In 80276.cc I replicate the #define with comment from other tests even 
if it isn't true that cxx11 abi string isn't supported. It's just that 
it doesn't appear as 'std::string', the aliasing doesn't work.


I still have failures when running with versioned namespace which I am 
going to check now.


    * python/libstdcxx/v6/printers.py (lookup_node_type): Remove redundant
    call to lookup_node_type.
    * testsuite/libstdc++-prettyprinters/80276.cc: Define
    _GLIBCXX_USE_CXX11_ABI to 0.
    * testsuite/libstdc++-prettyprinters/91997.cc: Use regexp-test to check
    'a' content.

Ok to commit ?


OK for trunk, thanks.



Re: [PATCH] Fix libstdc++ testsuite to handle VxWorks gthreads implementation

2019-12-20 Thread Jonathan Wakely

On 10/12/19 15:58 +0100, Corentin Gay wrote:

Hello there !



When implementing the support for gthreads in VxWorks, we stumbled on a
problem in the testsuite. In the libstdc++ testsuite, we
indiscriminately add the `-pthread` switch to the tests that require
linking against the pthread library. In certain cases, such as VxWorks,
the gthread interface relies on the system native threads lilbrary and 
the `-pthread` switch does not exist.


This patch adds a condition for the use of the `-pthread` switch. It
adds it only if the target supports it. The patch also adds
`dg-require-gthreads` in tests that were lacking it.

This patch was tested on x86_64-linux and is part of our nightly testing
on all platforms, including VxWorks.


Was it tested on AIX?

I think dg-require-gthreads will prevent the tests running for the
single-threaded multilib on AIX, so it will work OK. But there's a
chance it will need fixing. Let's wait and see (I'm currently unable
to build GCC on AIX).

OK for trunk, thanks.



Re: [PATCH 2/2] libada: Respect `--enable-version-specific-runtime-libs'

2019-12-20 Thread Eric Botcazou
>  Can you please be a little more specific as to what kind of breakage you
> see and/or specific configuration options and steps required to reproduce
> it?

/usr/bin/install: missing destination file operand after 'rts/libgnat-21.so'
Try '/usr/bin/install --help' for more information.
ln: failed to create symbolic link '/libgnat.so': Permission denied
/usr/bin/install: missing destination file operand after 'rts/libgnarl-21.so'
Try '/usr/bin/install --help' for more information.
ln: failed to create symbolic link '/libgnarl.so': Permission denied

>  I have rebuilt GCC with `--disable-libada' and it didn't cause any
> anomalies I could notice whether `--enable-version-specific-runtime-libs'
> or `--disable-version-specific-runtime-libs' has been used.  I wouldn't
> expect any anyway, as shared libgnat and libgnarl libraries are not built
> in this case, so $(toolexeclibdir) is not supposed to be used.

Yes, shared libraries are built with "make -C gcc gnatlib-shared gnattools".

-- 
Eric Botcazou


[patch,committed] Fix testsuite-fallout of OpenACC deep-copy patch (was: [PATCH 10/13] OpenACC 2.6 deep copy: Fortran front-end parts)

2019-12-20 Thread Tobias Burnus
Julian's patch (r279628) removed several now obsolete dg-errors about 
ALLOCATABLE and POINTER.


But seemingly, one was missed and two (for no_create) were added between 
posting the patch and committing that patch.


Committed the attached patch as obvious in Rev.279634.

Cheers,

Tobias

Index: gcc/testsuite/gfortran.dg/goacc/data-clauses.f95
===
--- gcc/testsuite/gfortran.dg/goacc/data-clauses.f95	(revision 279633)
+++ gcc/testsuite/gfortran.dg/goacc/data-clauses.f95	(revision 279634)
@@ -111,9 +111,9 @@
   !$acc end data
 
 
-  !$acc parallel no_create (tip) ! { dg-error "POINTER" }
+  !$acc parallel no_create (tip)
   !$acc end parallel
-  !$acc parallel no_create (tia) ! { dg-error "ALLOCATABLE" }
+  !$acc parallel no_create (tia)
   !$acc end parallel
   !$acc parallel deviceptr (i) no_create (i) ! { dg-error "multiple clauses" }
   !$acc end parallel
@@ -132,7 +132,7 @@
   !$acc end data
 
 
-  !$acc parallel present (tip) ! { dg-error "POINTER" }
+  !$acc parallel present (tip)
   !$acc end parallel
   !$acc parallel present (tia)
   !$acc end parallel
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog	(revision 279633)
+++ gcc/testsuite/ChangeLog	(revision 279634)
@@ -1,3 +1,8 @@
+2019-12-20  Tobias Burnus  
+
+	* gfortran.dg/goacc/data-clauses.f95: Remove now
+	obsolete dg-error.
+
 2019-12-20  Jakub Jelinek  
 
 	PR target/92841
@@ -8,11 +13,11 @@
 
 2019-12-19  Julian Brown  
 
-* gfortran.dg/goacc/derived-types.f90: New test.
-* gfortran.dg/goacc/derived-types-2.f90: New test.
-* gfortran.dg/goacc/derived-types-3.f90: New test.
-* gfortran.dg/goacc/data-clauses.f95: Adjust for expected errors.
-* gfortran.dg/goacc/enter-exit-data.f95: Likewise.
+	* gfortran.dg/goacc/derived-types.f90: New test.
+	* gfortran.dg/goacc/derived-types-2.f90: New test.
+	* gfortran.dg/goacc/derived-types-3.f90: New test.
+	* gfortran.dg/goacc/data-clauses.f95: Adjust for expected errors.
+	* gfortran.dg/goacc/enter-exit-data.f95: Likewise.
 
 2019-12-19  Julian Brown  
 	Cesar Philippidis  


Re: [Patch, Fortran] PR 92996 – fix rank resolution EXPR_ARRAY

2019-12-20 Thread Tobias Burnus

Hi Steve,

On 12/20/19 1:26 AM, Steve Kargl wrote:

On Thu, Dec 19, 2019 at 09:30:49PM +0100, Tobias Burnus wrote:

The latter could be "solved" by using %C instead of %L after
gfc_simplify_expr in gfc_match_stopcode.
[The "ref" has its own address (e->ref->u.ar->where); hence,
the a(1,1) error would be still fine.]
(Though, this potentially effects more.)

See patch in comment #2 of PR.  It regression tests cleanly,
so it seems your parenthetical statement is not a issue.


One has the choice between
(a) Using the location where the expression was defined (in the
scoping unit) – currently done
(i.e. replacing expr->where by expr->symtree->n.sym->where)
(b) using the location where the parameter is used, i.e. keeping
expr->where despite simplification.

What I meant is that there are more locations one to change from
%L to %C if one wants to get good diagnostic and keep using the
location of the declaration (as done currently) – instead of moving
to keeping the location of the expression used (as proposed).

In my opinion (b) is the most robust version while (a) can give in
_some_ cases a better diagnostic – as mentioned in the last email
and as shown by the dg-error changed I had to do in two test cases.

I played around and found two examples where the currently shown
location is not helpful.

The current compiler shows such errors:

5 | use m
  |1
Error: ‘dim’ argument of ‘size’ intrinsic at (1) is not a valid dimension index

1 | complex, parameter :: x(1) = 1
  |1
Error: STOP code at (1) must be either INTEGER or CHARACTER type


Using approach (b), one gets for those:

3 | stop x(1)
  |1
Error: STOP code at (1) must be either INTEGER or CHARACTER type

6 | print size([1,2],dim=d(1))
  | 1
Error: ‘dim’ argument of ‘size’ intrinsic at (1) is not a valid dimension index


I think the latter diagnostic is much more helpful! I have to admit that I had 
to
move the "e->where = p->where" further down – after the gfc_simplify_expr call
as that one again changed the location. — I also added the two examples.

OK for the trunk?

Tobias

	PR fortran/92996
	* expr.c (simplify_parameter_variable): Call gfc_resolve_ref and
	gfc_expression_rank; fix location info.
	* gfortran.h (gfc_resolve_ref, gfc_expression_rank): Declare.
	* match.c (gfc_match_stopcode): Remove redundant setting of
	gfc_init_expr_flag; early return if gfc_simplify_expr has an error.
	* resolve.c (gfc_expression_rank): Renamed from expression_rank;
	minor cleanup.
	(gfc_resolve_ref): Removed static and renamed from resolve_ref.
	(resolve_variable, resolve_typebound_function,
	resolve_typebound_subroutine, resolve_ppc_call, resolve_expr_ppc,
	gfc_resolve_expr, resolve_procedure): Update calls.

	PR fortran/92996
	* gfortran.dg/array_simplify_4.f90: New.
	* gfortran.dg/pr91565.f90: Update dg-error.
	* gfortran.dg/pr91801.f90: Likewise.

 gcc/fortran/expr.c | 10 +++
 gcc/fortran/gfortran.h |  2 ++
 gcc/fortran/match.c|  5 ++--
 gcc/fortran/resolve.c  | 38 +++---
 gcc/testsuite/gfortran.dg/array_simplify_4.f90 | 28 +++
 gcc/testsuite/gfortran.dg/pr91565.f90  |  8 +++---
 gcc/testsuite/gfortran.dg/pr91801.f90  |  4 +--
 7 files changed, 64 insertions(+), 31 deletions(-)

diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index 9e3c8c42297..fc67a9dd5b0 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -2044,6 +2044,15 @@ simplify_parameter_variable (gfc_expr *p, int type)
   gfc_expr *e;
   bool t;
 
+  /* Set rank and check array ref; as resolve_variable calls
+ gfc_simplify_expr, call gfc_resolve_ref + gfc_expression_rank instead.  */
+  if (!gfc_resolve_ref (p))
+{
+  gfc_error_check ();
+  return false;
+}
+  gfc_expression_rank (p);
+
   if (gfc_is_size_zero_array (p))
 {
   if (p->expr_type == EXPR_ARRAY)
@@ -2073,6 +2082,7 @@ simplify_parameter_variable (gfc_expr *p, int type)
   if (e->expr_type != EXPR_CONSTANT && p->ref != NULL)
 e->ref = gfc_copy_ref (p->ref);
   t = gfc_simplify_expr (e, type);
+  e->where = p->where;
 
   /* Only use the simplification if it eliminated all subobject references.  */
   if (t && !e->ref)
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 7919b690ec0..b38238a9faa 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -3352,6 +3352,8 @@ void gfc_free_statements (gfc_code *);
 void gfc_free_association_list (gfc_association_list *);
 
 /* resolve.c */
+void gfc_expression_rank (gfc_expr *);
+bool gfc_resolve_ref (gfc_expr *);
 bool gfc_resolve_expr (gfc_expr *);
 void gfc_resolve (gfc_namespace *);
 void gfc_resolve_code (gfc_code *, gfc_namespace *);
diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
index b5945049de5..d3e3abcb700 100644
--- a/gcc/fortran/match.c
+++