Re: [PATCH] Add pattern for pointer-diff on addresses with same base/offset (PR 94234)

[Marc Glisse]

On Tue, 16 Jun 2020, Feng Xue OS wrote:

Here is an question about pointer operation: 


Pointer is treated as unsigned in comparison operation, while distance between
pointers is signed. Then we can not assume the below conclusion is true?

(ptr_a > ptr_b) => (ptr_a - ptr_b) >= 0


Yes you can. It is illegal to use either expression if ptr_a and ptr_b do 
not point inside the same object, and objects are not allowed to be larger 
than half the address space.


Comparing arbitrary pointers (not in the same object) is done with 
(uintptr_t)ptr_a > (uintptr_t)ptr_b.


--
Marc Glisse

[PATCH] middle-end/95690 - avoid MEM_EXPRs for constants

[Richard Biener]

[the following fixes fallout of the last change which introduced
an assert - after this change we can likely trim down the set
of tree codes we "ignore"]

The following avoids calling set_mem_attributes on the
DECL_INITIAL of a CONST_DECL which seems pointless since there
cannot be a sensible MEM_EXPR derived from that.  We're overwriting
both other possibly useful info, alias-set and alignment immediately
so the following patch simply removes the call instead of making
the function deal with even more (unexpected) trees that are not
memory accesses.

Bootstrap and regtest ongoing on x86_64-unknown-linux-gnu.

Richard.

2020-06-16  Richard Biener  

PR middle-end/95690
* varasm.c (build_constant_desc): Remove set_mem_attributes call.

* gfortran.dg/pr95690.f90: New testcase.
---
 gcc/testsuite/gfortran.dg/pr95690.f90 | 9 +
 gcc/varasm.c  | 1 -
 2 files changed, 9 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gfortran.dg/pr95690.f90

diff --git a/gcc/testsuite/gfortran.dg/pr95690.f90 
b/gcc/testsuite/gfortran.dg/pr95690.f90
new file mode 100644
index 000..2da08912a4d
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr95690.f90
@@ -0,0 +1,9 @@
+! { dg-do compile }
+module m
+contains
+   subroutine s
+  print *, (erfc) ! { dg-error "not a floating constant" }
+   end
+   function erfc()
+   end
+end
diff --git a/gcc/varasm.c b/gcc/varasm.c
index f062e48071f..4070f9c17e8 100644
--- a/gcc/varasm.c
+++ b/gcc/varasm.c
@@ -3399,7 +3399,6 @@ build_constant_desc (tree exp)
   TREE_CONSTANT_POOL_ADDRESS_P (symbol) = 1;
 
   rtl = gen_const_mem (TYPE_MODE (TREE_TYPE (exp)), symbol);
-  set_mem_attributes (rtl, exp, 1);
   set_mem_alias_set (rtl, 0);
 
   /* Putting EXP into the literal pool might have imposed a different
-- 
2.16.4

[PATCH take 2] middle-end: Optimize (A&C)^(B&C) to (A^B)&C in simplify_rtx.

[Roger Sayle]

As suggested by Richard Sandiford, this patch splits out the
previous RTL simplification, of (X&C)^(Y&C) to (X^Y)&C, to its
own function, simplify_distributive_operation, and calls it when
appropriate for IOR, XOR and AND.

Instrumenting a bootstrap reveals this optimization triggers
393358 times during stage2, stage3 and building the libraries,
and a further 263659 times during make check.  By order of
occurrence the RTL transformation opportunities are:

 284447 01 and ior
 156798 00 xor and
 131110 11 and ior
  47253 00 and ior
  28035 00 ior and
   2804 01 ior and
   2698 11 ior and
   2262 01 xor and
602 11 xor and
312 00 xor xor
298 00 xor rotate
120 00 and ashift
108 00 ior lshiftrt
 60 00 and ashiftrt
 54 00 ior ashift
 18 00 and lshiftrt
 12 10 xor and
 12 00 xor rotatert
  8 00 xor lshiftrt
  4 10 ior and
  2 00 ior ashiftrt

where the two binary digits denote the surviving inner unique operands,
so "00 xor and" corresponds to the original (xor (and X Z) (and Y Z)),
and "01 and ior" corresponds to (and (ior X Y) (ior Y Z)).

Many thanks also to Richard for pointing out simplify_rtx_c_tests, the
self-testing framework in simplify-rtx.c, which is new since my day.
This patch supplements the existing vector mode testing, with a suite
of scalar integer mode tests that confirm that many of the expected
integer simplifications in simplify-rtx are being applied as expected.
This includes three tests of the new simplify_distributive_operation.

Before:
xgcc -xc -fself-test: 59693 pass(es) in 0.820956 seconds
xgcc -xc++ -fself-test: 59723 pass(es) in 0.786662 seconds
After:
xgcc -xc -fself-test: 60003 pass(es) in 0.860637 seconds
xgcc -xc++ -fself-test: 60033 pass(es) in 0.794624 seconds


I do have one thought/suggestion around test_scalar_ops for future
generations.  These tests are extremely strict; instead of an
unexpected failure in the testsuite, breaking a self-test stops
the build.  Instead of reverting this patch, should anything go
wrong (in future on a misbehaving platform), might I instead
propose simply commenting out the call to test_scalar_ops in
simplify_rtx_c_tests as a mitigation strategy whilst the build is
restored.  In fact, removing the "static" from test_scalar_ops
would avoid the "defined but not used" complication from this
disaster recovery plan.

This patch has been tested with "make bootstrap" and "make -k check"
on x86_64-pc-linux-gnu with no regressions.


2020-06-16  Roger Sayle  
Richard Sandiford  

* simplify-rtx.c (simplify_distributive_operation): New function
to un-distribute a binary operation of two binary operations.
(X & C) ^ (Y & C) to (X ^ Y) & C, when C is simple (i.e. a constant).
(simplify_binary_operation_1) : Call it from here
when appropriate.
(test_scalar_int_ops): New function for unit self-testing
scalar integer transformations in simplify-rtx.c.
(test_scalar_ops): Call test_scalar_int_ops for each integer mode.
(simplify_rtx_c_tests): Call test_scalar_ops.


Many thanks in advance,
Roger
--
Roger Sayle,
NextMove Software
Cambridge, UK

diff --git a/gcc/simplify-rtx.c b/gcc/simplify-rtx.c
index 28c2dc6..0f93e17 100644
--- a/gcc/simplify-rtx.c
+++ b/gcc/simplify-rtx.c
@@ -2392,6 +2392,54 @@ simplify_binary_operation_series (rtx_code code, 
machine_mode mode,
   return gen_vec_series (mode, new_base, new_step);
 }
 
+/* Subroutine of simplify_binary_operation_1.  Un-distribute a binary
+   operation CODE with result mode MODE, operating on OP0 and OP1.
+   e.g. simplify (xor (and A C) (and (B C)) to (and (xor (A B) C).
+   Returns NULL_RTX if no simplification is possible.  */
+
+static rtx
+simplify_distributive_operation (enum rtx_code code, machine_mode mode,
+rtx op0, rtx op1)
+{
+  enum rtx_code op = GET_CODE (op0);
+  gcc_assert (GET_CODE (op1) == op);
+
+  if (rtx_equal_p (XEXP (op0, 1), XEXP (op1, 1))
+  && ! side_effects_p (XEXP (op0, 1)))
+return simplify_gen_binary (op, mode,
+   simplify_gen_binary (code, mode,
+XEXP (op0, 0),
+XEXP (op1, 0)),
+   XEXP (op0, 1));
+
+  if (GET_RTX_CLASS (op) == RTX_COMM_ARITH)
+{
+  if (rtx_equal_p (XEXP (op0, 0), XEXP (op1, 0))
+ && ! side_effects_p (XEXP (op0, 0)))
+   return simplify_gen_binary (op, mode,
+   simplify_gen_binary (code, mode,
+XEXP (op0, 1),
+XEXP (op1, 1)),
+   XEXP (op0, 0));
+  if (rtx_equal_p (XEXP (op0, 0), XEXP (op1, 1))
+ && ! side_effects_p (XEXP (op0, 0)))
+   return simplify_gen_binary (op, mode,
+   simplify_gen_

Re: [PATCH 4/5] libgcc: vxworks: don't set __GTHREAD_HAS_COND for vxworks 5.x

[Olivier Hainque]

Hi Rasmus,

> On 26 May 2020, at 16:52, Rasmus Villemoes  wrote:
> 
> The vxworks-cond.c file fails to compile for vxworks 5.x:
> 
> libgcc/config/gthr-vxworks-cond.c:29:
> ./gthr-default.h:274:3: error: unknown type name 'TASK_ID'
>  274 |   TASK_ID task_id;
>  |   ^~~
> 
> There is a TASK_ID typedef in our system headers, but (1) is is
> commented out, (2) lives in some obscure header that nothing really
> pulls in and (3) it is defined as a "struct wind_task *", which isn't
> really consistent with taskCreate() returning an int.
> 
> In order to allow building gcc, let's just disable __GTHREAD_HAS_COND
> for vxworks 5.x. To simplify the makefile fragments, keep including
> gthr-vxworks-cond.c, but guard the actual code by __GTHREAD_HAS_COND -
> that way, the logic for deciding whether to support gthread condition
> variables is kept in gthr-vxworks.h.

This one is OK for me, with a ChangeLog please. Thanks.

Olivier

> ---
> libgcc/config/gthr-vxworks-cond.c | 4 
> libgcc/config/gthr-vxworks.h  | 4 
> 2 files changed, 8 insertions(+)
> 
> diff --git a/libgcc/config/gthr-vxworks-cond.c 
> b/libgcc/config/gthr-vxworks-cond.c
> index d65d07aebc3..f0585624c05 100644
> --- a/libgcc/config/gthr-vxworks-cond.c
> +++ b/libgcc/config/gthr-vxworks-cond.c
> @@ -31,6 +31,8 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  
> If not, see
> 
> /* --- Condition Variables  */
> 
> +#if __GTHREAD_HAS_COND
> +
> void
> __gthread_cond_init (__gthread_cond_t *cond)
> {
> @@ -81,3 +83,5 @@ __gthread_cond_wait_recursive (__gthread_cond_t *cond,
> {
>   return __gthread_cond_wait (cond, mutex);
> }
> +
> +#endif
> diff --git a/libgcc/config/gthr-vxworks.h b/libgcc/config/gthr-vxworks.h
> index e38174730bf..91e3d94ac67 100644
> --- a/libgcc/config/gthr-vxworks.h
> +++ b/libgcc/config/gthr-vxworks.h
> @@ -234,6 +234,8 @@ extern int __gthread_setspecific (__gthread_key_t __key, 
> void *__ptr);
> 
> /* -- Base condition variables support --- */
> 
> +#if _VXWORKS_MAJOR_GE(6)
> +
> #define __GTHREAD_HAS_COND 1
> 
> typedef SEM_ID __gthread_cond_t;
> @@ -254,6 +256,8 @@ extern int __gthread_cond_wait (__gthread_cond_t *cond,
> extern int __gthread_cond_wait_recursive (__gthread_cond_t *cond,
> __gthread_recursive_mutex_t *mutex);
> 
> +#endif /* _VXWORKS_MAJOR_GE(6) */
> +
> /* ---  C++0x thread support - */
> 
> /* We do not support C++0x threads on that VxWorks 653, which we can
> -- 
> 2.23.0
> 

[PATCH] S/390: Emit vector alignment hints for z13 if AS accepts them

[Stefan Schulze Frielinghaus via Gcc-patches]

Since 87cb9423add vector alignment hints are emitted for target z13,
too.  This patch changes this behaviour in the sense that alignment
hints are only emitted for target z13 if the assembler accepts them.

Bootstrapped and regtested on S/390. Ok for master?

gcc/ChangeLog:

* config.in: Regenerate.
* config/s390/s390.c (print_operand): Emit vector alignment hints
for target z13, if AS accepts them.  For other targets the logic
stays the same.
* config/s390/s390.h (TARGET_VECTOR_LOADSTORE_ALIGNMENT_HINTS): Define
macro.
* configure: Regenerate.
* configure.ac: Check HAVE_AS_VECTOR_LOADSTORE_ALIGNMENT_HINTS_ON_Z13.
---
 gcc/config.in  |  7 +++
 gcc/config/s390/s390.c |  4 +---
 gcc/config/s390/s390.h |  7 +++
 gcc/configure  | 31 +++
 gcc/configure.ac   |  5 +
 5 files changed, 51 insertions(+), 3 deletions(-)

diff --git a/gcc/config.in b/gcc/config.in
index 809e7b26823..364eba47737 100644
--- a/gcc/config.in
+++ b/gcc/config.in
@@ -706,6 +706,13 @@
 #endif
 
 
+/* Define if your assembler supports vl/vst/vlm/vstm with an optional
+   alignment hint argument on z13. */
+#ifndef USED_FOR_TARGET
+#undef HAVE_AS_VECTOR_LOADSTORE_ALIGNMENT_HINTS_ON_Z13
+#endif
+
+
 /* Define if your assembler supports VSX instructions. */
 #ifndef USED_FOR_TARGET
 #undef HAVE_AS_VSX
diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c
index 56e3e87425a..758315c0c72 100644
--- a/gcc/config/s390/s390.c
+++ b/gcc/config/s390/s390.c
@@ -7853,15 +7853,13 @@ print_operand (FILE *file, rtx x, int code)
   switch (code)
 {
 case 'A':
-#ifdef HAVE_AS_VECTOR_LOADSTORE_ALIGNMENT_HINTS
-  if (TARGET_Z13 && MEM_P (x))
+  if (TARGET_VECTOR_LOADSTORE_ALIGNMENT_HINTS && MEM_P (x))
{
  if (MEM_ALIGN (x) >= 128)
fprintf (file, ",4");
  else if (MEM_ALIGN (x) == 64)
fprintf (file, ",3");
}
-#endif
   return;
 case 'C':
   fprintf (file, s390_branch_condition_mnemonic (x, FALSE));
diff --git a/gcc/config/s390/s390.h b/gcc/config/s390/s390.h
index 2e29dbe97e8..e4ef63e4080 100644
--- a/gcc/config/s390/s390.h
+++ b/gcc/config/s390/s390.h
@@ -167,6 +167,13 @@ enum processor_flags
(TARGET_VX && TARGET_CPU_VXE2)
 #define TARGET_VXE2_P(opts)\
(TARGET_VX_P (opts) && TARGET_CPU_VXE2_P (opts))
+#if defined(HAVE_AS_VECTOR_LOADSTORE_ALIGNMENT_HINTS_ON_Z13)
+#define TARGET_VECTOR_LOADSTORE_ALIGNMENT_HINTS TARGET_Z13
+#elif defined(HAVE_AS_VECTOR_LOADSTORE_ALIGNMENT_HINTS)
+#define TARGET_VECTOR_LOADSTORE_ALIGNMENT_HINTS TARGET_Z14
+#else
+#define TARGET_VECTOR_LOADSTORE_ALIGNMENT_HINTS 0
+#endif
 
 #ifdef HAVE_AS_MACHINE_MACHINEMODE
 #define S390_USE_TARGET_ATTRIBUTE 1
diff --git a/gcc/configure b/gcc/configure
index def9d9a48be..f224679ed3e 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -28241,6 +28241,37 @@ if test 
$gcc_cv_as_s390_vector_loadstore_alignment_hints = yes; then
 
 $as_echo "#define HAVE_AS_VECTOR_LOADSTORE_ALIGNMENT_HINTS 1" >>confdefs.h
 
+fi
+
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking assembler for vector 
load/store alignment hints on z13" >&5
+$as_echo_n "checking assembler for vector load/store alignment hints on z13... 
" >&6; }
+if ${gcc_cv_as_s390_vector_loadstore_alignment_hints_on_z13+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+  gcc_cv_as_s390_vector_loadstore_alignment_hints_on_z13=no
+  if test x$gcc_cv_as != x; then
+$as_echo ' vl %v24,0(%r15),3 ' > conftest.s
+if { ac_try='$gcc_cv_as $gcc_cv_as_flags -mzarch -march=z13 -o conftest.o 
conftest.s >&5'
+  { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
+  test $ac_status = 0; }; }
+then
+   gcc_cv_as_s390_vector_loadstore_alignment_hints_on_z13=yes
+else
+  echo "configure: failed program was" >&5
+  cat conftest.s >&5
+fi
+rm -f conftest.o conftest.s
+  fi
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: 
$gcc_cv_as_s390_vector_loadstore_alignment_hints_on_z13" >&5
+$as_echo "$gcc_cv_as_s390_vector_loadstore_alignment_hints_on_z13" >&6; }
+if test $gcc_cv_as_s390_vector_loadstore_alignment_hints_on_z13 = yes; then
+
+$as_echo "#define HAVE_AS_VECTOR_LOADSTORE_ALIGNMENT_HINTS_ON_Z13 1" 
>>confdefs.h
+
 fi
 
 
diff --git a/gcc/configure.ac b/gcc/configure.ac
index e769c9c87d4..e83f0833ef3 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -5106,6 +5106,11 @@ configured with --enable-newlib-nano-formatted-io.])
   [vl %v24,0(%r15),3 ],,
   [AC_DEFINE(HAVE_AS_VECTOR_LOADSTORE_ALIGNMENT_HINTS, 1,
  [Define if your assembler supports vl/vst/vlm/vstm with an optional 
alignment hint argument.])])
+gcc_GAS_CHECK_FEATURE([vector load/store alignment hints on z13],
+  gcc_cv_as_s390_vector_loads

Re: [PATCH] wwwdocs: Document devel/omp/gcc-10 branch

[Thomas Schwinge]

Hi Kwok!

On 2020-06-15T22:08:50+0100, Kwok Cheung Yeung  wrote:
> I have now moved the entry for devel/omp/gcc-9 into the inactive branches
> section and reworded it slightly.
>
> Okay to push?

Yes, thanks.

Reviewed-by: Thomas Schwinge 


Grüße
 Thomas


> On 12/06/2020 9:35 am, Thomas Schwinge wrote:
>>> or by topic (in which case it should
>>> probably go after openacc-gcc-9-branch)?
>>
>> By topic makes most sense to me.  And, 'devel/omp/gcc-9' definitively
>> should group right next to 'openacc-gcc-9-branch', as it began as a
>> direct translation of the latter.
>>
>> For historical reasons, I have a (at least slight) preference to keep all
>> these branches right after the 'gomp-4_0-branch' -- where it all began.
>> This is a history chapter, after all.
>>
> commit b719899acf24974fd4c51f14538b426f99259384
> Author: Kwok Cheung Yeung 
> Date:   Wed Jun 10 06:08:06 2020 -0700
>
> Document devel/omp/gcc-10 branch
>
> This also moves the old devel/omp/gcc-9 branch to the inactive branches
> section.
>
> diff --git a/htdocs/git.html b/htdocs/git.html
> index 8c28bc0..f7f87a9 100644
> --- a/htdocs/git.html
> +++ b/htdocs/git.html
> @@ -280,15 +280,15 @@ in Git.
>Makarov mailto:vmaka...@redhat.com";>vmaka...@redhat.com.
>
>
> -   href="https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=shortlog;h=refs/heads/devel/omp/gcc-9";>devel/omp/gcc-9
> +   href="https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=shortlog;h=refs/heads/devel/omp/gcc-10";>devel/omp/gcc-10
>This branch is for collaborative development of
>https://gcc.gnu.org/wiki/OpenACC";>OpenACC and
>https://gcc.gnu.org/wiki/openmp";>OpenMP support and related
>functionality, such
>as https://gcc.gnu.org/wiki/Offloading";>offloading support 
> (OMP:
>offloading and multi processing).
> -  The branch is based on releases/gcc-9.
> -  Please send patch emails with a short-hand [og9] tag in the
> +  The branch is based on releases/gcc-10.
> +  Please send patch emails with a short-hand [og10] tag in the
>subject line, and use ChangeLog.omp files.
>
>unified-autovect
> @@ -944,8 +944,16 @@ merged.
>These branches were used for development of
>https://gcc.gnu.org/wiki/OpenACC";>OpenACC support and related
>functionality, based on gcc-7-branch, gcc-8-branch, and gcc-9-branch
> -  respectively.
> -  Work is now proceeding on the devel/omp/gcc-9 branch.
> +  respectively.
> +
> +   href="https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=shortlog;h=refs/heads/devel/omp/gcc-9";>devel/omp/gcc-9
> +  This branch was used for collaborative development of
> +  https://gcc.gnu.org/wiki/OpenACC";>OpenACC and
> +  https://gcc.gnu.org/wiki/openmp";>OpenMP support and related
> +  functionality as the successor to openacc-gcc-9-branch after the move to
> +  Git.
> +  The branch was based on releases/gcc-9.
> +  Development has now moved to the devel/omp/gcc-10 branch.
>
>hammer-3_3-branch
>The goal of this branch was to have a stable compiler based on GCC 3.3
-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter

Re: [PATCH 5/5] libgcc: vxworks: don't set __GTHREAD_CXX0X for vxworks 5.x

[Olivier Hainque]

Hi Rasmus,

> On 26 May 2020, at 16:52, Rasmus Villemoes  wrote:
> 
> As for __GTHREAD_HAS_COND, use __GTHREAD_CXX0X to guard the actual
> contents of gthr-vxworks-thread.c.

Good for me.
 
> That should also allow dropping the
> t-gthr-vxworksae fragment and simply use t-gthr-vxworks.

Indeed. 

Thanks.

Olivier

Re: [PATCH] Optimize V*QImode shift by constant using same operation on V*HImode [PR95524]

[Jakub Jelinek via Gcc-patches]

On Tue, Jun 16, 2020 at 10:09:08AM +0800, Hongtao Liu via Gcc-patches wrote:
> > +  machine_mode qimode, himode;
> > +  unsigned int shift_constant, and_constant, xor_constant;
> > +  rtx vec_const_and, vec_const_xor;
> > +  rtx tmp, op1_subreg;
> > +  rtx (*gen_shift) (rtx, rtx, rtx);
> > +  rtx (*gen_and) (rtx, rtx, rtx);
> > +  rtx (*gen_xor) (rtx, rtx, rtx);
> > +  rtx (*gen_sub) (rtx, rtx, rtx);
> > +
> > +  /* Only optimize shift by constant.  */
> > +  if (!CONST_INT_P (op2))
> > +return false;
> > +
> > +  qimode = GET_MODE (dest);
> > +  shift_constant = INTVAL (op2);
> >
> > I wonder if shift_constant shouldn't be unsigned HOST_WIDE_INT
> i don't think there would be some usage with shift_constant greater
> than UINT_MAX(4294967295),
> shouldn't unsigned int enough here?

What I mean is that op2 is a CONST_INT, which in theory can have any
HOST_WIDE_INT values.
By assigning that to unsigned int variable, you are effectively
testing shift % 0x1ULL instead of the shift.

So, it is fine to use unsigned int (or even unsigned char) var for the
shift_constant (shouldn't that be shift_amount?), but the test if it is
outside of range then should be performed on if (UINTVAL (op2) > 7).
And perhaps just don't bother with the out of bounds shifts, so just
  if (UINTVAL (op2) > 7)
return false;
because that is just UB and no need to optimize invalid code.

Jakub

[PATCH PR95199 v2] vect: CSE for bump and offset in strided load/store operations

[zhoukaipeng (A)]

Hi,

I try to eliminate the common stmts for *vec_offset also.  But I am not sure
it is a good way.

New patch attached.  Bootstraped and testsuites are being tested.

Kaipeng Zhou

> -Original Message-
> From: Richard Biener [mailto:rguent...@suse.de]
> Sent: Monday, June 15, 2020 2:21 PM
> To: zhoukaipeng (A) 
> Cc: Richard Sandiford ; gcc-
> patc...@gcc.gnu.org; am...@gcc.gnu.org; rgue...@gcc.gnu.org
> Subject: RE: [PATCH PR95199] vect: Remove extra variable created for
> memory reference
> 
> On Sun, 14 Jun 2020, zhoukaipeng (A) wrote:
> 
> > Hi,
> >
> > I modified the issue you mentioned.  Bootstrap and tested on aarch64
> Linux platform again.  No new regression witnessed.
> >
> > For "*vec_offset", it is indeed a point optimizable.  However, it is
> > not able to eliminate it by the same way as "*dataref_bump".  The
> > cse_and_gimplify_to_preheader will return the cached operand if
> > operand_compare::operand_equal_p for the cached one and the new one
> > returns true.  But it did not work well for "*vec_offset".
> 
> You have to see what is actually in *vec_offset, if there's partly gimplified 
> but
> not CSEd stmts in there then that's the issue.
> 
> Richard.
> 
> > Do you have any suggestions for the problem?
> >
> > Thanks,
> > Kaipeng Zhou
> >
> > > -Original Message-
> > > From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> > > Sent: Friday, June 12, 2020 3:48 PM
> > > To: zhoukaipeng (A) 
> > > Cc: gcc-patches@gcc.gnu.org; rguent...@suse.de; am...@gcc.gnu.org;
> > > rgue...@gcc.gnu.org
> > > Subject: Re: [PATCH PR95199] vect: Remove extra variable created for
> > > memory reference
> > >
> > > "zhoukaipeng (A)"  writes:
> > > > Hi,
> > > >
> > > > This is a fix for pr95199.
> > > > In vectorization, vinfo->ivexpr_map is supposed to catch those "IV
> > > > base
> > > and/or step expressions".  Just call cse_and_gimplify_to_preheader
> > > to handle gathering/scattering to avoid the extra variable.
> > > >
> > > > Bootstrap and tested on aarch64/x86_64 Linux platform. No new
> > > regression witnessed.
> > > >
> > > > Is it ok?
> > > >
> > > > Thanks,
> > > > Kaipeng Zhou
> > > >
> > > > From 12cf9b362576735e4c584c48cd6db3d2b0f2e14b Mon Sep 17
> 00:00:00
> > > 2001
> > > > From: Kaipeng Zhou 
> > > > Date: Fri, 12 Jun 2020 00:54:15 +0800
> > > > Subject: [PATCH] vect: Remove extra variable created for memory
> > > > reference in  loop vectorization.
> > > >
> > > > Vectorization create two copies of the same IV and IVOPTs does not
> > > > perform CSE.  But vinfo->ivexpr_map is supposed to catch those "IV
> > > > base and/or step expressions".  Just call
> > > > cse_and_gimplify_to_preheader to handle gathering/scattering to
> > > > avoid
> > > the extra variable.
> > > >
> > > > 2020-06-12  Bin Cheng 
> > > > Kaipeng Zhou  
> > > >
> > > > PR tree-optimization/95199
> > > > * tree-vect-stmts.c: Use CSE map to catch the IV step and 
> > > > eliminate
> > > > extra variable.
> > > >
> > > > 2020-06-12  Bin Cheng 
> > > > Kaipeng Zhou  
> > > >
> > > > PR tree-optimization/95199
> > > > * gcc.dg/vect/pr95199.c: New test.
> > > > ---
> > > >  gcc/ChangeLog   |  7 +++
> > > >  gcc/testsuite/ChangeLog |  6 ++
> > > >  gcc/testsuite/gcc.dg/vect/pr95199.c | 17 +
> > > >  gcc/tree-vect-stmts.c   |  1 +
> > > >  4 files changed, 31 insertions(+)  create mode 100644
> > > > gcc/testsuite/gcc.dg/vect/pr95199.c
> > > >
> > > > diff --git a/gcc/ChangeLog b/gcc/ChangeLog index
> > > > c92582df7fe..753d70fc94b 100644
> > > > --- a/gcc/ChangeLog
> > > > +++ b/gcc/ChangeLog
> > > > @@ -1,3 +1,10 @@
> > > > +2020-06-12  Bin Cheng 
> > > > +   Kaipeng Zhou  
> > > > +
> > > > +   PR tree-optimization/95199
> > > > +   * tree-vect-stmts.c: Use CSE map to catch the IV step and 
> > > > eliminate
> > > > +   extra variable.
> > > > +
> > > >  2020-06-08  Tobias Burnus  
> > > >
> > > > PR lto/94848
> > > > diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
> > > > index
> > > > 60d9ecca3ed..a27dd3fa072 100644
> > > > --- a/gcc/testsuite/ChangeLog
> > > > +++ b/gcc/testsuite/ChangeLog
> > > > @@ -1,3 +1,9 @@
> > > > +2020-06-12  Bin Cheng 
> > > > +   Kaipeng Zhou  
> > > > +
> > > > +   PR tree-optimization/95199
> > > > +   * gcc.dg/vect/pr95199.c: New test.
> > > > +
> > > >  2020-06-08  Harald Anlauf  
> > > >
> > > > PR fortran/95195
> > > > diff --git a/gcc/testsuite/gcc.dg/vect/pr95199.c
> > > > b/gcc/testsuite/gcc.dg/vect/pr95199.c
> > > > new file mode 100644
> > > > index 000..ec201feaec8
> > > > --- /dev/null
> > > > +++ b/gcc/testsuite/gcc.dg/vect/pr95199.c
> > > > @@ -0,0 +1,17 @@
> > > > +/* { dg-do compile { target aarch64-*-* } } */
> > > > +/* { dg-options "-O3 -march=armv8.2-a+fp+sve" } */
> > > > +
> > > > +void
> > > > +foo (double *a, double *b, double m, int inc_x, in

Re: [PATCH] vectorizer: add _bb_vec_info::const_iterator

[Richard Sandiford]

Martin Liška  writes:
> > Also, one minor formatting nit, sorry: the other functions instead
> > indent the “{” block by the same amount as the function prototype,
> > which seems more consistent with the usual out-of-class formatting.
>
> Hope I fixed that.

Sorry, I meant the other functions were IMO formatted correctly, with the
“{” directly under the function name.  It looks like the new patch instead
indents all “{” by two spaces relative to the function name or “struct”
keyword.  I.e. IMO:

  struct const_iterator
  {
  };

seems better than:
  
  struct const_iterator
{
};

and:

  const const_iterator &
  operator++ ()
  {
  }

seems better than:

  const const_iterator &
  operator++ ()
{
}

This makes the formatting consistent with definitions in column 0.

> About rbiener's comment, I wrapper the iterators with bb_vinfo::region_stmts..

Sorry for dragging this on longer, but…

> @@ -5120,20 +5120,14 @@ vect_determine_precisions (vec_info *vinfo)
>else
>  {
>bb_vec_info bb_vinfo = as_a  (vinfo);
> -  gimple_stmt_iterator si = bb_vinfo->region_end;
> -  gimple *stmt;
> -  do
> +  for ( _bb_vec_info::reverse_iterator it = 
> bb_vinfo->region_stmts.rbegin ();
> +it != bb_vinfo->region_stmts.rend (); ++it)
>   {
> -   if (!gsi_stmt (si))
> - si = gsi_last_bb (bb_vinfo->bb);
> -   else
> - gsi_prev (&si);
> -   stmt = gsi_stmt (si);
> +   gimple *stmt = *it;
> stmt_vec_info stmt_info = vinfo->lookup_stmt (stmt);
> if (stmt_info && STMT_VINFO_VECTORIZABLE (stmt_info))
>   vect_determine_stmt_precisions (vinfo, stmt_info);
>   }
> -  while (stmt != gsi_stmt (bb_vinfo->region_begin));
>  }
>  }

I think this should be a similar style, i.e.

 for (gimple *stmt : bb_vinfo->reverse_region_stmts ())

rather than using iterators directly.

> @@ -5492,10 +5486,8 @@ vect_pattern_recog (vec_info *vinfo)
>else
>  {
>bb_vec_info bb_vinfo = as_a  (vinfo);
> -  for (si = bb_vinfo->region_begin;
> -gsi_stmt (si) != gsi_stmt (bb_vinfo->region_end); gsi_next (&si))
> +  for (gimple *stmt : bb_vinfo->region_stmts)
>   {
> -   gimple *stmt = gsi_stmt (si);
> stmt_vec_info stmt_info = bb_vinfo->lookup_stmt (stmt);
> if (!stmt_info || !STMT_VINFO_VECTORIZABLE (stmt_info))
>   continue;
> diff --git a/gcc/tree-vect-slp.c b/gcc/tree-vect-slp.c
> index 303410c2fc4..f4809c2207d 100644
> --- a/gcc/tree-vect-slp.c
> +++ b/gcc/tree-vect-slp.c
> @@ -2546,20 +2546,15 @@ vect_detect_hybrid_slp (loop_vec_info loop_vinfo)
>  /* Initialize a bb_vec_info struct for the statements between
> REGION_BEGIN_IN (inclusive) and REGION_END_IN (exclusive).  */
>  
> -_bb_vec_info::_bb_vec_info (gimple_stmt_iterator region_begin_in,
> - gimple_stmt_iterator region_end_in,
> +_bb_vec_info::_bb_vec_info (gimple_stmt_iterator region_begin,
> + gimple_stmt_iterator region_end,
>   vec_info_shared *shared)
>: vec_info (vec_info::bb, init_cost (NULL), shared),
> -bb (gsi_bb (region_begin_in)),
> -region_begin (region_begin_in),
> -region_end (region_end_in)
> +bb (gsi_bb (region_begin)),
> +region_stmts (region_begin, region_end)
>  {
> -  gimple_stmt_iterator gsi;
> -
> -  for (gsi = region_begin; gsi_stmt (gsi) != gsi_stmt (region_end);
> -   gsi_next (&gsi))
> +  for (gimple *stmt : this->region_stmts)
>  {
> -  gimple *stmt = gsi_stmt (gsi);
>gimple_set_uid (stmt, 0);
>if (is_gimple_debug (stmt))
>   continue;
> @@ -2575,10 +2570,9 @@ _bb_vec_info::_bb_vec_info (gimple_stmt_iterator 
> region_begin_in,
>  
>  _bb_vec_info::~_bb_vec_info ()
>  {
> -  for (gimple_stmt_iterator si = region_begin;
> -   gsi_stmt (si) != gsi_stmt (region_end); gsi_next (&si))
> +  for (gimple *stmt : this->region_stmts)
>  /* Reset region marker.  */
> -gimple_set_uid (gsi_stmt (si), -1);
> +gimple_set_uid (stmt, -1);
>  
>bb->aux = NULL;
>  }
> @@ -3012,16 +3006,13 @@ vect_bb_vectorization_profitable_p (bb_vec_info 
> bb_vinfo)
>  static void
>  vect_slp_check_for_constructors (bb_vec_info bb_vinfo)
>  {
> -  gimple_stmt_iterator gsi;
> -
> -  for (gsi = bb_vinfo->region_begin;
> -   gsi_stmt (gsi) != gsi_stmt (bb_vinfo->region_end); gsi_next (&gsi))
> +  for (gimple *stmt : bb_vinfo->region_stmts)
>  {
> -  gassign *stmt = dyn_cast  (gsi_stmt (gsi));
> -  if (!stmt || gimple_assign_rhs_code (stmt) != CONSTRUCTOR)
> +  gassign *assign = dyn_cast  (stmt);
> +  if (!assign || gimple_assign_rhs_code (assign) != CONSTRUCTOR)
>   continue;
>  
> -  tree rhs = gimple_assign_rhs1 (stmt);
> +  tree rhs = gimple_assign_rhs1 (assign);
>if (!VECTOR_TYPE_P (TREE_TYPE (rhs))
> || maybe_ne (TYPE_VECTOR_SUBPARTS (TREE_TYPE (rhs)),
>  CONSTRUCTOR_NELTS (rhs))
> @@ -3029,7 

Re: [PATCH] Defined libcall_arg_t

[Richard Sandiford]

Thanks for doing this.

Kamlesh Kumar via Gcc-patches  writes:
> diff --git a/gcc/rtl.h b/gcc/rtl.h
> index 0872cc4..c023ff0 100644
> --- a/gcc/rtl.h
> +++ b/gcc/rtl.h
> @@ -2238,6 +2238,18 @@ struct address_info {
>enum rtx_code base_outer_code;
>  };
>  
> +/* This is used for passing args in emit_library_* functions */
> +typedef struct libcall_arg {

There's not really any need for a typedef here.  We should just
use “libcall_arg” directly.

> +  rtx value;
> +  machine_mode mode;
> +  bool unsigned_p;
> +  libcall_arg (rtx v, machine_mode m, bool u) {
> +value = v;
> +mode = m;
> +unsigned_p = u;
> +  }

Please use member initialisation for the fields instead.

Now that we're C++11, the constructor might as well be constexpr.

Thanks,
Richard

> +} libcall_arg_t;
> +
>  /* This is used to bundle an rtx and a mode together so that the pair
> can be used with the wi:: routines.  If we ever put modes into rtx
> integer constants, this should go away and then just pass an rtx in.  */

[PATCH][documentation] Fix typo in access function attribute example

[Forrest Timour via Gcc-patches]

Hi,

This patch fixes an off-by-one typo in the documentation example of the
access function attribute.

This is my first contribution and I don't have write access, so I will need
somebody to submit for me on approval.

Thanks,
Forrest

---
Fix typo in documentation example of access function
attribute where the ref-indices should be one-indexed
instead of zero-indexed

2020-06-16  Forrest Timour  

gcc/ChangeLog:

* doc/extend.texi:
---
 gcc/doc/extend.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index e656e66a80c..10dc32e6d2d 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -2527,7 +2527,7 @@ the @code{memcpy} function.
 
 @smallexample
 __attribute__ ((access (read_only, 1))) int puts (const char*);
-__attribute__ ((access (read_only, 1, 2))) void* memcpy (void*, const void*, size_t);
+__attribute__ ((access (read_only, 2, 3))) void* memcpy (void*, const void*, size_t);
 @end smallexample
 
 The @code{read_write} access mode applies to arguments of pointer types

Re: [PATCH] avoid false positives due to compute_objsize (PR 95353)

[Richard Biener via Gcc-patches]

On Mon, Jun 15, 2020 at 7:11 PM Martin Sebor via Gcc-patches
 wrote:
>
> On 6/14/20 12:37 PM, Jeff Law wrote:
> > On Sat, 2020-06-13 at 17:49 -0600, Martin Sebor wrote:
> >> On 6/13/20 3:50 PM, Sandra Loosemore wrote:
> >>> On 6/2/20 6:12 PM, Martin Sebor via Gcc-patches wrote:
>  The compute_objsize() function started out as a thin wrapper around
>  compute_builtin_object_size(), but over time developed its own
>  features to compensate for the other function's limitations (such
>  as its inability to work with ranges).  The interaction of these
>  features and the limitations has started to become increasingly
>  problematic as the former function is used in more contexts.
> 
>  A complete "fix" for all the problems (as well as some other
>  limitations) that I'm working on will be more extensive and won't
>  be appropriate for backports.  Until then, the attached patch
>  cleans up the extensions compute_objsize() has accumulated over
>  the years to avoid a class of false positives.
> 
>  To make the warnings issued based on the results of the function
>  easier to understand and fix, the patch also adds an informative
>  message to many instances of -Wstringop-overflow to point to
>  the object to which the warning refers.  This is especially
>  helpful when the object is referenced by a series of pointer
>  operations.
> 
>  Tested by boostrapping on x86_64-linux and building Binutils/GDB,
>  Glibc, and the Linux kernel with no new warnings.
> 
>  Besides applying it to trunk I'm looking to backport the fix to
>  GCC 10.
> >>>
> >>> This patch (commit a2c2cee92e5defff9bf23d3b1184ee96e57e5fdd) has broken
> >>> glibc builds on nios2-linux-gnu, when building 
> >>> sysdeps/posix/getaddrinfo.c:
> >>>
> >>> ../sysdeps/posix/getaddrinfo.c: In function 'gaih_inet.constprop':
> >>> ../sysdeps/posix/getaddrinfo.c:1081:3: error: 'memcpy' writing 16 bytes
> >>> into a region of size 8 overflows the destination
> >>> [-Werror=stringop-overflow=]
> >>>1081 |   memcpy (&sin6p->sin6_addr,
> >>> |   ^~
> >>>1082 |at2->addr, sizeof (struct in6_addr));
> >>> |
> >>> In file included from ../include/netinet/in.h:3,
> >>>from ../resolv/bits/types/res_state.h:5,
> >>>from ../include/bits/types/res_state.h:1,
> >>>from ../nptl/descr.h:35,
> >>>from ../sysdeps/nios2/nptl/tls.h:45,
> >>>from ../sysdeps/generic/libc-tsd.h:44,
> >>>from ../include/../locale/localeinfo.h:224,
> >>>from ../include/ctype.h:26,
> >>>from ../sysdeps/posix/getaddrinfo.c:57:
> >>> ../inet/netinet/in.h:249:19: note: destination object 'sin_zero'
> >>> 249 | unsigned char sin_zero[sizeof (struct sockaddr)
> >>> |   ^~~~
> >>>
> >>>
> >>> I have to say that I don't understand the "note" diagnostic here at all.
> >>>:-(  Why does it think the destination object is a field of struct
> >>> sockaddr_in, while this memcpy is filling in a field of struct
> >>> sockaddr_in6?  (And, the sin6_addr field is indeed of type struct
> >>> in6_addr, matching the sizeof expression.)
> >>
> >> Most likely because some earlier pass (from my exchange with Jeff
> >> about this instance of the warning I suspect it's PRE) substitutes
> >> one member for the other in the IL when offsets into them happen
> >> to evaluate to the same offset from the start of the enclosing
> >> object.  The Glibc code does this:
> > Yes, this is the same issue we were discussing privately.
> >
> >>
> >>  struct sockaddr_in6 *sin6p =
> >>(struct sockaddr_in6 *) ai->ai_addr;
> >>
> >>  sin6p->sin6_port = st2->port;
> >>  sin6p->sin6_flowinfo = 0;
> >>  memcpy (&sin6p->sin6_addr,
> >>  at2->addr, sizeof (struct in6_addr));
> >>
> >> and the warning doesn't see sin6p->sin6_addr as the destination
> >> but something like
> >>
> >> &MEM  [(void *)ai_10 + 4B].sin_zero;
> >>
> >> The details in this and all other middle end warnings are only as
> >> reliable as the IL they work with.  If the IL that doesn't correspond
> >> to the original source code they're going to be confusing (and may
> >> trigger false positives).
> > True, but the transformation done by PRE is valid.  PRE is concerned only 
> > with
> > value equivalences and the two addresses are the same and PRE can and will
> > replace one with the other.
>
> That's fine.  Since they are treated as equivalent it shouldn't
> matter which of the equivalent alternatives is chosen (there
> may be many).  It's the particular choice of the smaller member
> that makes it a problem: both in the terms of triggering a false
> positive and in terms of the note referencing a member th

Re: [Patch] testsuite: Add offloading_enabled check and use it for xfail (PR95622)

[Thomas Schwinge]

Hi Tobias!

On 2020-06-12T16:12:44+0200, Tobias Burnus  wrote:
> For real offloading compilers, the configure-time ENABLE_OFFLOAD
> macro is set to true.

I once toyed with the idea of getting rid of that configure-time
'ENABLE_OFFLOAD' flag, moving it to GCC run time, implicitly set by
'-fopenacc' etc.  But it's not trivial, in particular inside libgomp, if
I now remember correctly.

And, that wouldn't help with this issue here, anyway.  ;-)

> If it is set, some additional code paths
> are enabled – which can affect code generation with -fopenmp/-fopenacc.
>
> As the PR shows, this can make differences for passing/failing a
> testcase. – In principle, it is supposed to *pass* with ENABLE_OFFLOAD
> but until the PR is fixed, XFAIL those test cases.
>
> OK for the trunk and GCC 10?
> (The patches causing the to-be-xfailed issue will be backported.)

OK, thanks.

Reviewed-by: Thomas Schwinge 

> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -997,6 +997,12 @@ proc check_effective_target_fgraphite {} {
>  } "-O1 -fgraphite"]
>  }
>
> +# Return 1 if compiled with --enable-offload-targets=
> +# This affects host compilation as ENABLE_OFFLOAD then evaluates to true.
> +proc check_effective_target_offloading_enabled {} {
> +return [check_configured_with "--enable-offload-targets"]

Ah, nice and easy!  :-)

Eh, actually too easy, strictly speaking: we'd need to 'return 0' if
(only!) configured with '--enable-offload-targets=hsa'.  But, as Martin
Jambor recently has gotten approved his "Request to deprecate offloading
to HSAIL in GCC", we probably don't have to worry about that now.

> +}
> +
>  # Return 1 if compilation with -fopenacc is error-free for trivial
>  # code, 0 otherwise.
>


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

Re: [PATCH PR95199 v2] vect: CSE for bump and offset in strided load/store operations

[Richard Biener]

On Tue, 16 Jun 2020, zhoukaipeng (A) wrote:

> Hi,
> 
> I try to eliminate the common stmts for *vec_offset also.  But I am not sure
> it is a good way.
> 
> New patch attached.  Bootstraped and testsuites are being tested.

Looks good to me and certainly worth if it makes a difference for
IV calculation (that was the main motivation of the machinery).

Richard.

> Kaipeng Zhou
> 
> > -Original Message-
> > From: Richard Biener [mailto:rguent...@suse.de]
> > Sent: Monday, June 15, 2020 2:21 PM
> > To: zhoukaipeng (A) 
> > Cc: Richard Sandiford ; gcc-
> > patc...@gcc.gnu.org; am...@gcc.gnu.org; rgue...@gcc.gnu.org
> > Subject: RE: [PATCH PR95199] vect: Remove extra variable created for
> > memory reference
> > 
> > On Sun, 14 Jun 2020, zhoukaipeng (A) wrote:
> > 
> > > Hi,
> > >
> > > I modified the issue you mentioned.  Bootstrap and tested on aarch64
> > Linux platform again.  No new regression witnessed.
> > >
> > > For "*vec_offset", it is indeed a point optimizable.  However, it is
> > > not able to eliminate it by the same way as "*dataref_bump".  The
> > > cse_and_gimplify_to_preheader will return the cached operand if
> > > operand_compare::operand_equal_p for the cached one and the new one
> > > returns true.  But it did not work well for "*vec_offset".
> > 
> > You have to see what is actually in *vec_offset, if there's partly 
> > gimplified but
> > not CSEd stmts in there then that's the issue.
> > 
> > Richard.
> > 
> > > Do you have any suggestions for the problem?
> > >
> > > Thanks,
> > > Kaipeng Zhou
> > >
> > > > -Original Message-
> > > > From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> > > > Sent: Friday, June 12, 2020 3:48 PM
> > > > To: zhoukaipeng (A) 
> > > > Cc: gcc-patches@gcc.gnu.org; rguent...@suse.de; am...@gcc.gnu.org;
> > > > rgue...@gcc.gnu.org
> > > > Subject: Re: [PATCH PR95199] vect: Remove extra variable created for
> > > > memory reference
> > > >
> > > > "zhoukaipeng (A)"  writes:
> > > > > Hi,
> > > > >
> > > > > This is a fix for pr95199.
> > > > > In vectorization, vinfo->ivexpr_map is supposed to catch those "IV
> > > > > base
> > > > and/or step expressions".  Just call cse_and_gimplify_to_preheader
> > > > to handle gathering/scattering to avoid the extra variable.
> > > > >
> > > > > Bootstrap and tested on aarch64/x86_64 Linux platform. No new
> > > > regression witnessed.
> > > > >
> > > > > Is it ok?
> > > > >
> > > > > Thanks,
> > > > > Kaipeng Zhou
> > > > >
> > > > > From 12cf9b362576735e4c584c48cd6db3d2b0f2e14b Mon Sep 17
> > 00:00:00
> > > > 2001
> > > > > From: Kaipeng Zhou 
> > > > > Date: Fri, 12 Jun 2020 00:54:15 +0800
> > > > > Subject: [PATCH] vect: Remove extra variable created for memory
> > > > > reference in  loop vectorization.
> > > > >
> > > > > Vectorization create two copies of the same IV and IVOPTs does not
> > > > > perform CSE.  But vinfo->ivexpr_map is supposed to catch those "IV
> > > > > base and/or step expressions".  Just call
> > > > > cse_and_gimplify_to_preheader to handle gathering/scattering to
> > > > > avoid
> > > > the extra variable.
> > > > >
> > > > > 2020-06-12  Bin Cheng 
> > > > >   Kaipeng Zhou  
> > > > >
> > > > >   PR tree-optimization/95199
> > > > >   * tree-vect-stmts.c: Use CSE map to catch the IV step and 
> > > > > eliminate
> > > > >   extra variable.
> > > > >
> > > > > 2020-06-12  Bin Cheng 
> > > > >   Kaipeng Zhou  
> > > > >
> > > > >   PR tree-optimization/95199
> > > > >   * gcc.dg/vect/pr95199.c: New test.
> > > > > ---
> > > > >  gcc/ChangeLog   |  7 +++
> > > > >  gcc/testsuite/ChangeLog |  6 ++
> > > > >  gcc/testsuite/gcc.dg/vect/pr95199.c | 17 +
> > > > >  gcc/tree-vect-stmts.c   |  1 +
> > > > >  4 files changed, 31 insertions(+)  create mode 100644
> > > > > gcc/testsuite/gcc.dg/vect/pr95199.c
> > > > >
> > > > > diff --git a/gcc/ChangeLog b/gcc/ChangeLog index
> > > > > c92582df7fe..753d70fc94b 100644
> > > > > --- a/gcc/ChangeLog
> > > > > +++ b/gcc/ChangeLog
> > > > > @@ -1,3 +1,10 @@
> > > > > +2020-06-12  Bin Cheng 
> > > > > + Kaipeng Zhou  
> > > > > +
> > > > > + PR tree-optimization/95199
> > > > > + * tree-vect-stmts.c: Use CSE map to catch the IV step and 
> > > > > eliminate
> > > > > + extra variable.
> > > > > +
> > > > >  2020-06-08  Tobias Burnus  
> > > > >
> > > > >   PR lto/94848
> > > > > diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
> > > > > index
> > > > > 60d9ecca3ed..a27dd3fa072 100644
> > > > > --- a/gcc/testsuite/ChangeLog
> > > > > +++ b/gcc/testsuite/ChangeLog
> > > > > @@ -1,3 +1,9 @@
> > > > > +2020-06-12  Bin Cheng 
> > > > > + Kaipeng Zhou  
> > > > > +
> > > > > + PR tree-optimization/95199
> > > > > + * gcc.dg/vect/pr95199.c: New test.
> > > > > +
> > > > >  2020-06-08  Harald Anlauf  
> > > > >
> > > > >   PR fortran/95195
> > > > > diff --git a/gcc/testsuite/gcc.dg/v

[RFC PATCH] Fix plugin build errors on systems where unistd.h includes getopt.h

[Ilya Leoshkevich via Gcc-patches]

Hello,

I ran into an issue with building plugins, which appears to be fairly
old [1].  Below is my attempt to fix it - I'm currently verifying it on
various farm machines, and so far it's looking good.  I'm not sure
whether I went in the right direction with the fix though (portability
is hard!), so it would be great if someone knowledgeable could have a
look.

Best regards,
Ilya

[1] https://gcc.gnu.org/legacy-ml/gcc/2010-08/msg00106.html

---

On certain systems gcc plugin builds fail with


install/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.0/plugin/include/system.h:476:53:
 error: declaration of ‘int getopt(int, char* const*, const char*)’ has a 
different exception specifier
 extern int getopt (int, char * const *, const char *);
 ^
In file included from /usr/include/unistd.h:893:0,
 from 
install/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.0/plugin/include/system.h:294,
 from 
install/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.0/plugin/include/gcc-plugin.h:28,
 from plugin.cpp:3:
/usr/include/getopt.h:151:12: error: from previous declaration ‘int 
getopt(int, char* const*, const char*) throw ()’
 extern int getopt (int ___argc, char *const *___argv, const char 
*__shortopts)

errors.  The problem occurs on e.g. CentOS 7, but not on e.g. Fedora 31.
The difference is that unistd.h includes getopt.h on the former and
bits/getopt_posix.h on the latter.

gcc includes its own version of getopt.h, which is autoconf-aware: it
does not declare getopt if HAVE_DECL_GETOPT=1.  The important things
about it are that it is not installed and that it shadows platform's
getopt.h.

system.h, which is used during autoconf tests, includes unistd.h and
also declares getopt (unless HAVE_DECL_GETOPT=1).   When doing the
getopt presence test, autoconf defines HAVE_DECL_GETOPT=1 and includes
system.h.  On systems where unistd.h does not include getopt.h, no
shadowing happens, system.h ends up providing getopt, and autoconf
correctly concludes that HAVE_DECL_GETOPT=1.  On systems where unistd.h
does include getopt.h, shadowing happens, system.h ends up not
providing getopt, and autoconf incorrectly concludes that
HAVE_DECL_GETOPT=0.

When a plugin includes installed system.h, it gets two conflicting
definitions of getopt: one from platform's unistd.h, and one from
system.h itself - the latter arises because the installed auto-host.h
contains the incorrect #define HAVE_DECL_GETOPT 0.

The root cause is header shadowing causing the incorrect autoconf
decision, so fix this by removing getopt.h and moving the necessary
bits into the new gcc-getopt.h.

---
 gcc/Makefile.in |   3 +-
 gcc/config.in   |  54 +++
 gcc/configure   |  54 +--
 gcc/configure.ac|  16 -
 gcc/gcov-dump.c |   2 +-
 gcc/gcov-tool.c |   2 +-
 gcc/gcov.c  |   2 +-
 gcc/gengtype.c  |   2 +-
 gcc/system.h|   6 +-
 gcc/tsystem.h   |  11 ---
 include/gcc-getopt.h|  79 +
 include/getopt.h| 143 --
 libiberty/Makefile.in   |   6 +-
 libiberty/config.in |  30 
 libiberty/configure | 147 
 libiberty/configure.ac  |  24 ++-
 libiberty/cp-demangle.c |   2 +-
 libiberty/getopt.c  |   2 +-
 libiberty/getopt1.c |   2 +-
 19 files changed, 395 insertions(+), 192 deletions(-)
 create mode 100644 include/gcc-getopt.h
 delete mode 100644 include/getopt.h

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 4f70c189b9d..37534247539 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -979,7 +979,8 @@ C_COMMON_H = c-family/c-common.h c-family/c-common.def 
$(TREE_H) \
 C_PRAGMA_H = c-family/c-pragma.h $(CPPLIB_H)
 C_TREE_H = c/c-tree.h $(C_COMMON_H) $(DIAGNOSTIC_H)
 SYSTEM_H = system.h hwint.h $(srcdir)/../include/libiberty.h \
-   $(srcdir)/../include/safe-ctype.h $(srcdir)/../include/filenames.h
+   $(srcdir)/../include/safe-ctype.h $(srcdir)/../include/filenames.h \
+   $(srcdir)/../include/gcc-getopt.h
 PREDICT_H = predict.h predict.def
 CPPLIB_H = $(srcdir)/../libcpp/include/line-map.h \
$(srcdir)/../libcpp/include/cpplib.h
diff --git a/gcc/config.in b/gcc/config.in
index 364eba47737..e835d5b842f 100644
--- a/gcc/config.in
+++ b/gcc/config.in
@@ -947,6 +947,13 @@
 #endif
 
 
+/* Define to 1 if we found a declaration for 'getopt_long', otherwise define
+   to 0. */
+#ifndef USED_FOR_TARGET
+#undef HAVE_DECL_GETOPT_LONG
+#endif
+
+
 /* Define to 1 if we found a declaration for 'getpagesize', otherwise define
to 0. */
 #ifndef USED_FOR_TARGET
@@ -1003,6 +1010,27 @@
 #endif
 
 
+/* Define to 1 if we found a declaration for 'no_argument', otherwise define
+   to 0. */
+#ifndef USED_FOR_TARGET
+#undef HAVE_DECL_NO_ARGUMENT
+#endif
+
+
+/* Define to 1 if we found a declaration for '

Re: [PATCH] recog: Use parameter packs for operator()

[Richard Sandiford]

Jonathan Wakely  writes:
> +  template
> +  rtx_insn *operator() (Ts... args...) const
>
> Why is this declared as a variadic template **and** a varargs function?
>
> I think the second ellipsis is wrong, it should be just:
>
> +  template
> +  rtx_insn *operator() (Ts... args) const

Oops, yes.

> And this seems like a more direct way to say "a list of N rtx types"
> where N is sizeof...(args):
>
> diff --git a/gcc/recog.h b/gcc/recog.h
> index 0a71a02c4a9..fd22c58c92a 100644
> --- a/gcc/recog.h
> +++ b/gcc/recog.h
> @@ -294,10 +294,13 @@ struct insn_gen_fn
>  {
>typedef void (*stored_funcptr) (void);
>  
> +  template using rtx_t = rtx;
> +
>template
> -  rtx_insn *operator() (Ts... args...) const
> +  rtx_insn *operator() (Ts... args) const
>{
> -return ((rtx_insn *(*) (decltype(args, NULL_RTX)...)) func) (args...);
> +using funcptr = rtx_insn * (*) (rtx_t...);
> +return ((funcptr) func) (args...);
>}
>  
>// This is for compatibility of code that invokes functions like
>
> The rtx_t alias is the type 'rtx' for any T. The pack expansion
> rtx_t... is a list of rtx the same length as the pack Ts.

Yeah.  As mentioned on IRC, I'd originally done it like this, but didn't
like the ad-hoc type alias.  I can't remember what name I'd used, but the
problem in both cases is/was that the ad-hoc name looks odd when you're
used to seeing plain “rtx”.  It also felt weird to expose this kind of
internal, function-specific implementation detail at insn_gen_fn scope.

Using decltype also gave nicer error messages, e.g.:

invalid conversion from ‘int’ to ‘rtx {aka rtx_def*}’

instead of:

invalid conversion from ‘int’ to ‘insn_gen_fn::rtx_t {aka rtx_def*}’

I think the latter is likely to confuse people when they see it
for the first time.

So in some ways I'd prefer to keep the decltype and just add a void cast
to suppress the warning.  (Seems odd to warn about expressions having no
effect in an unevaluated context.)

But how about the below instead?  Hopefully the alias name is mnemonic
enough.

> The 'funcptr' alias sin't necessary, but (IMHO) simplifies the
> following line, by splitting the definition of the complicated
> function pointer type from its use.

OK, I'll split it out.

Tested on aarch64-linux-gnu and x86_64-linux-gnu.

Richard


Fixes a “left operand of comma has no effect” warning that some were
seeing.  Also fixes a spurious ellipsis that Jonathan Wakely pointed
out.

2020-06-16  Richard Sandiford  

gcc/
* coretypes.h (first_type): New alias template.
* recog.h (insn_gen_fn::operator()): Use it instead of a decltype.
Remove spurious “...” and split the function type out into a typedef.
---
 gcc/coretypes.h | 4 
 gcc/recog.h | 5 +++--
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/gcc/coretypes.h b/gcc/coretypes.h
index cda22697cc3..01ec2e23ce2 100644
--- a/gcc/coretypes.h
+++ b/gcc/coretypes.h
@@ -359,6 +359,10 @@ struct kv_pair
   const ValueType value;   /* the value of the name */
 };
 
+/* Alias of the first type, ignoring the second.  */
+template
+using first_type = T1;
+
 #else
 
 struct _dont_use_rtx_here_;
diff --git a/gcc/recog.h b/gcc/recog.h
index 0a71a02c4a9..d674d384723 100644
--- a/gcc/recog.h
+++ b/gcc/recog.h
@@ -295,9 +295,10 @@ struct insn_gen_fn
   typedef void (*stored_funcptr) (void);
 
   template
-  rtx_insn *operator() (Ts... args...) const
+  rtx_insn *operator() (Ts... args) const
   {
-return ((rtx_insn *(*) (decltype(args, NULL_RTX)...)) func) (args...);
+typedef rtx_insn *(*funcptr) (first_type...);
+return ((funcptr) func) (args...);
   }
 
   // This is for compatibility of code that invokes functions like

[PATCH][GCC-10 Backport] arm: Fix unintentional fall throughs in arm.c

[Srinath Parvathaneni]

Hi all,

This small patch fix some unintentional fall-throughs in
`mve_vector_mem_operand'.

Regtested and bootstraped on arm-linux-gnueabihf.

Okay for GCC-10 branch?

Regards,
Srinath

gcc/ChangeLog

2020-06-09  Srinath Parvathaneni  

Backported from mainline
2020-05-28  Andrea Corallo  

* config/arm/arm.c (mve_vector_mem_operand): Fix unwanted
fall-throughs.


### Attachment also inlined for ease of reply###


diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 
01bc1b8ae9b72700ca5ae0840ee4496fd686b623..a7b7c55a763c66382bc140a4c504840c509df84c
 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -13302,26 +13302,31 @@ mve_vector_mem_operand (machine_mode mode, rtx op, 
bool strict)
if (abs_hwi (val))
  return ((reg_no < LAST_ARM_REGNUM && reg_no != SP_REGNUM)
  || (!strict && reg_no >= FIRST_PSEUDO_REGISTER));
+   return FALSE;
  case E_V8HImode:
  case E_V8HFmode:
if (abs (val) <= 255)
  return ((reg_no < LAST_ARM_REGNUM && reg_no != SP_REGNUM)
  || (!strict && reg_no >= FIRST_PSEUDO_REGISTER));
+   return FALSE;
  case E_V8QImode:
  case E_V4QImode:
if (abs_hwi (val))
  return (reg_no <= LAST_LO_REGNUM
  || (!strict && reg_no >= FIRST_PSEUDO_REGISTER));
+   return FALSE;
  case E_V4HImode:
  case E_V4HFmode:
if (val % 2 == 0 && abs (val) <= 254)
  return (reg_no <= LAST_LO_REGNUM
  || (!strict && reg_no >= FIRST_PSEUDO_REGISTER));
+   return FALSE;
  case E_V4SImode:
  case E_V4SFmode:
if (val % 4 == 0 && abs (val) <= 508)
  return ((reg_no < LAST_ARM_REGNUM && reg_no != SP_REGNUM)
  || (!strict && reg_no >= FIRST_PSEUDO_REGISTER));
+   return FALSE;
  case E_V2DImode:
  case E_V2DFmode:
  case E_TImode:

diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 
01bc1b8ae9b72700ca5ae0840ee4496fd686b623..a7b7c55a763c66382bc140a4c504840c509df84c
 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -13302,26 +13302,31 @@ mve_vector_mem_operand (machine_mode mode, rtx op, 
bool strict)
if (abs_hwi (val))
  return ((reg_no < LAST_ARM_REGNUM && reg_no != SP_REGNUM)
  || (!strict && reg_no >= FIRST_PSEUDO_REGISTER));
+   return FALSE;
  case E_V8HImode:
  case E_V8HFmode:
if (abs (val) <= 255)
  return ((reg_no < LAST_ARM_REGNUM && reg_no != SP_REGNUM)
  || (!strict && reg_no >= FIRST_PSEUDO_REGISTER));
+   return FALSE;
  case E_V8QImode:
  case E_V4QImode:
if (abs_hwi (val))
  return (reg_no <= LAST_LO_REGNUM
  || (!strict && reg_no >= FIRST_PSEUDO_REGISTER));
+   return FALSE;
  case E_V4HImode:
  case E_V4HFmode:
if (val % 2 == 0 && abs (val) <= 254)
  return (reg_no <= LAST_LO_REGNUM
  || (!strict && reg_no >= FIRST_PSEUDO_REGISTER));
+   return FALSE;
  case E_V4SImode:
  case E_V4SFmode:
if (val % 4 == 0 && abs (val) <= 508)
  return ((reg_no < LAST_ARM_REGNUM && reg_no != SP_REGNUM)
  || (!strict && reg_no >= FIRST_PSEUDO_REGISTER));
+   return FALSE;
  case E_V2DImode:
  case E_V2DFmode:
  case E_TImode:

[PATCH][GCC-10 Backport] arm: Fix the wrong code-gen generated by MVE vector load/store intrinsics (PR94959).

[Srinath Parvathaneni]

Hello,

Few MVE intrinsics like vldrbq_s32, vldrhq_s32 etc., the assembler instructions
generated by current compiler are wrong.
eg: vldrbq_s32 generates an assembly instructions `vldrb.s32 q0,[ip]`.
But as per Arm-arm second argument in above instructions must also be a low
register (<= r7). This patch fixes this issue by creating a new predicate
"mve_memory_operand" and constraint "Ux" which allows low registers as arguments
to the generated instructions depending on the mode of the argument. A new 
constraint
"Ul" is created to handle loading to PC-relative addressing modes for vector
store/load intrinsiscs.
All the corresponding MVE intrinsic generating wrong code-gen as vldrbq_s32
are modified in this patch.

Please refer to M-profile Vector Extension (MVE) intrinsics [1] and Armv8-M 
Architecture Reference Manual [2] for more details.
[1] 
https://developer.arm.com/architectures/instruction-sets/simd-isas/helium/mve-intrinsics
[2] https://developer.arm.com/docs/ddi0553/latest

Regression tested on arm-none-eabi and found no regressions.

Ok for gcc-10 branch?

Thanks,
Srinath.

gcc/ChangeLog:

2020-06-09  Srinath Parvathaneni  

Backported from mainline
2020-05-20  Srinath Parvathaneni  
Andre Vieira  

PR target/94959
* config/arm/arm-protos.h (arm_mode_base_reg_class): Function
declaration.
(mve_vector_mem_operand): Likewise.
* config/arm/arm.c (thumb2_legitimate_address_p): For MVE target check
the load from memory to a core register is legitimate for give mode.
(mve_vector_mem_operand): Define function.
(arm_print_operand): Modify comment.
(arm_mode_base_reg_class): Define.
* config/arm/arm.h (MODE_BASE_REG_CLASS): Modify to add check for
TARGET_HAVE_MVE and expand to arm_mode_base_reg_class on TRUE.
* config/arm/constraints.md (Ux): Likewise.
(Ul): Likewise.
* config/arm/mve.md (mve_mov): Replace constraint Us with Ux and also
add support for missing Vector Store Register and Vector Load Register.
Add a new alternative to support load from memory to PC (or label) in
vector store/load.
(mve_vstrbq_): Modify constraint Us to Ux.
(mve_vldrbq_): Modify constriant Us to Ux, predicate to
mve_memory_operand and also modify the MVE instructions to emit.
(mve_vldrbq_z_): Modify constraint Us to Ux.
(mve_vldrhq_fv8hf): Modify constriant Us to Ux, predicate to
mve_memory_operand and also modify the MVE instructions to emit.
(mve_vldrhq_): Modify constriant Us to Ux, predicate to
mve_memory_operand and also modify the MVE instructions to emit.
(mve_vldrhq_z_fv8hf): Likewise.
(mve_vldrhq_z_): Likewise.
(mve_vldrwq_fv4sf): Likewise.
(mve_vldrwq_v4si): Likewise.
(mve_vldrwq_z_fv4sf): Likewise.
(mve_vldrwq_z_v4si): Likewise.
(mve_vld1q_f): Modify constriant Us to Ux.
(mve_vld1q_): Likewise.
(mve_vstrhq_fv8hf): Modify constriant Us to Ux, predicate to
mve_memory_operand.
(mve_vstrhq_p_fv8hf): Modify constriant Us to Ux, predicate to
mve_memory_operand and also modify the MVE instructions to emit.
(mve_vstrhq_p_): Likewise.
(mve_vstrhq_): Modify constriant Us to Ux, predicate to
mve_memory_operand.
(mve_vstrwq_fv4sf): Modify constriant Us to Ux.
(mve_vstrwq_p_fv4sf): Modify constriant Us to Ux and also modify the MVE
instructions to emit.
(mve_vstrwq_p_v4si): Likewise.
(mve_vstrwq_v4si): Likewise.Modify constriant Us to Ux.
* config/arm/predicates.md (mve_memory_operand): Define.

gcc/testsuite/ChangeLog:

2020-06-09  Srinath Parvathaneni  

Backported from mainline
2020-05-20  Srinath Parvathaneni  

PR target/94959
* gcc.target/arm/mve/intrinsics/mve_vector_float2.c: Modify.
* gcc.target/arm/mve/intrinsics/mve_vldr.c: New test.
* gcc.target/arm/mve/intrinsics/mve_vldr_z.c: Likewise.
* gcc.target/arm/mve/intrinsics/mve_vstr.c: Likewise.
* gcc.target/arm/mve/intrinsics/mve_vstr_p.c: Likewise.
* gcc.target/arm/mve/intrinsics/vld1q_f16.c: Modify.
* gcc.target/arm/mve/intrinsics/vld1q_f32.c: Likewise.
* gcc.target/arm/mve/intrinsics/vld1q_s16.c: Likewise.
* gcc.target/arm/mve/intrinsics/vld1q_s32.c: Likewise.
* gcc.target/arm/mve/intrinsics/vld1q_s8.c: Likewise.
* gcc.target/arm/mve/intrinsics/vld1q_u16.c: Likewise.
* gcc.target/arm/mve/intrinsics/vld1q_u32.c: Likewise.
* gcc.target/arm/mve/intrinsics/vld1q_u8.c: Likewise.
* gcc.target/arm/mve/intrinsics/vld1q_z_f16.c: Likewise.
* gcc.target/arm/mve/intrinsics/vld1q_z_f32.c: Likewise.
* gcc.target/arm/mve/intrinsics/vld1q_z_s16.c: Likewise.
* gcc.target/arm/mve/intrinsics/vld1q_z_s32.c: Likewise.
* gcc.ta

[PATCH][GCC-10 Backport] arm: Fix the MVE ACLE vbicq intrinsics.

[Srinath Parvathaneni]

Hello,

Following MVE intrinsic testcases are failing in GCC testsuite.

Directory: gcc.target/arm/mve/intrinsics/
Testcases: vbicq_f16.c, vbicq_f32.c, vbicq_s16.c, vbicq_s32.c, vbicq_s8.c
,vbicq_u16.c, vbicq_u32.c and vbicq_u8.c.

This patch fixes the vbicq intrinsics by modifying the intrinsic parameters
and polymorphic variants in "arm_mve.h" header file.

Please refer to M-profile Vector Extension (MVE) intrinsics [1]for more details.
[1] 
https://developer.arm.com/architectures/instruction-sets/simd-isas/helium/mve-intrinsics

Regression tested on arm-none-eabi and found no regressions.

Ok for GCC-10 branch?

Thanks,
Srinath.

gcc/ChangeLog:

2020-05-20  Srinath Parvathaneni  

Backported from mainline
2020-06-04  Srinath Parvathaneni  

* config/arm/arm_mve.h (__arm_vbicq_n_u16): Correct the intrinsic
arguments.
(__arm_vbicq_n_s16): Likewise.
(__arm_vbicq_n_u32): Likewise.
(__arm_vbicq_n_s32): Likewise.
(__arm_vbicq): Modify polymorphic variant.

gcc/testsuite/ChangeLog:

2020-05-20  Srinath Parvathaneni  

Backported from mainline
2020-06-04  Srinath Parvathaneni  

* gcc.target/arm/mve/intrinsics/vbicq_f16.c: Modify.
* gcc.target/arm/mve/intrinsics/vbicq_f32.c: Likewise.
* gcc.target/arm/mve/intrinsics/vbicq_n_s16.c: Likewise.
* gcc.target/arm/mve/intrinsics/vbicq_n_s32.c: Likewise.
* gcc.target/arm/mve/intrinsics/vbicq_n_u16.c: Likewise.
* gcc.target/arm/mve/intrinsics/vbicq_n_u32.c: Likewise.
* gcc.target/arm/mve/intrinsics/vbicq_s16.c: Likewise.
* gcc.target/arm/mve/intrinsics/vbicq_s32.c: Likewise.
* gcc.target/arm/mve/intrinsics/vbicq_s8.c: Likewise.
* gcc.target/arm/mve/intrinsics/vbicq_u16.c: Likewise.
* gcc.target/arm/mve/intrinsics/vbicq_u32.c: Likewise.
* gcc.target/arm/mve/intrinsics/vbicq_u8.c: Likewise.


### Attachment also inlined for ease of reply###


diff --git a/gcc/config/arm/arm_mve.h b/gcc/config/arm/arm_mve.h
index 
1002512a98f9364403f66eba0e320fe5070bdc3a..9bc5c97db8fea15d8140d966bc501b8a457a1abf
 100644
--- a/gcc/config/arm/arm_mve.h
+++ b/gcc/config/arm/arm_mve.h
@@ -6361,7 +6361,7 @@ __arm_vorrq_n_u16 (uint16x8_t __a, const int __imm)
 
 __extension__ extern __inline uint16x8_t
 __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
-__arm_vbicq_n_u16 (uint16x8_t __a, const uint16_t __imm)
+__arm_vbicq_n_u16 (uint16x8_t __a, const int __imm)
 {
   return __builtin_mve_vbicq_n_uv8hi (__a, __imm);
 }
@@ -6473,7 +6473,7 @@ __arm_vorrq_n_s16 (int16x8_t __a, const int __imm)
 
 __extension__ extern __inline int16x8_t
 __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
-__arm_vbicq_n_s16 (int16x8_t __a, const int16_t __imm)
+__arm_vbicq_n_s16 (int16x8_t __a, const int __imm)
 {
   return __builtin_mve_vbicq_n_sv8hi (__a, __imm);
 }
@@ -6564,7 +6564,7 @@ __arm_vorrq_n_u32 (uint32x4_t __a, const int __imm)
 
 __extension__ extern __inline uint32x4_t
 __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
-__arm_vbicq_n_u32 (uint32x4_t __a, const uint32_t __imm)
+__arm_vbicq_n_u32 (uint32x4_t __a, const int __imm)
 {
   return __builtin_mve_vbicq_n_uv4si (__a, __imm);
 }
@@ -6676,7 +6676,7 @@ __arm_vorrq_n_s32 (int32x4_t __a, const int __imm)
 
 __extension__ extern __inline int32x4_t
 __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
-__arm_vbicq_n_s32 (int32x4_t __a, const int32_t __imm)
+__arm_vbicq_n_s32 (int32x4_t __a, const int __imm)
 {
   return __builtin_mve_vbicq_n_sv4si (__a, __imm);
 }
@@ -23182,7 +23182,7 @@ __arm_vorrq (uint16x8_t __a, const int __imm)
 
 __extension__ extern __inline uint16x8_t
 __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
-__arm_vbicq (uint16x8_t __a, const uint16_t __imm)
+__arm_vbicq (uint16x8_t __a, const int __imm)
 {
  return __arm_vbicq_n_u16 (__a, __imm);
 }
@@ -23294,7 +23294,7 @@ __arm_vorrq (int16x8_t __a, const int __imm)
 
 __extension__ extern __inline int16x8_t
 __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
-__arm_vbicq (int16x8_t __a, const int16_t __imm)
+__arm_vbicq (int16x8_t __a, const int __imm)
 {
  return __arm_vbicq_n_s16 (__a, __imm);
 }
@@ -23385,7 +23385,7 @@ __arm_vorrq (uint32x4_t __a, const int __imm)
 
 __extension__ extern __inline uint32x4_t
 __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
-__arm_vbicq (uint32x4_t __a, const uint32_t __imm)
+__arm_vbicq (uint32x4_t __a, const int __imm)
 {
  return __arm_vbicq_n_u32 (__a, __imm);
 }
@@ -23497,7 +23497,7 @@ __arm_vorrq (int32x4_t __a, const int __imm)
 
 __extension__ extern __inline int32x4_t
 __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
-__arm_vbicq (int32x4_t __a, const int32_t __imm)
+__arm_vbicq (int32x4_t __a, const int __imm)
 {
  return __arm_vbicq_n_s32 (__a, __imm);
 }
@@ -35963,10 +35963,10 @@ extern void 

[PATCH][GCC-10 Backport] arm: Correct the grouping of operands in MVE vector scatter store intrinsics (PR94735).

[Srinath Parvathaneni]

Hello,

The operands in RTL patterns of MVE vector scatter store intrinsics are wrongly 
grouped, because of which few
vector loads and stores instructions are wrongly getting optimized out with -O2.

A new predicate "mve_scatter_memory" is defined in this patch, this predicate 
returns TRUE on
matching: (mem(reg)) for MVE scatter store intrinsics.
This patch fixes the issue by adding define_expand pattern with 
"mve_scatter_memory" predicate and calls the
corresponding define_insn by passing register_operand as first argument. This 
register_operand is extracted
from the operand with "mve_scatter_memory" predicate in define_expand pattern.

Please refer to M-profile Vector Extension (MVE) intrinsics [1]  for more 
details.
[1] 
https://developer.arm.com/architectures/instruction-sets/simd-isas/helium/mve-intrinsics

Regression tested on arm-none-eabi and found no regressions.

Ok for GCC-10 branch?

Thanks,
Srinath.

gcc/ChangeLog:

2020-06-09  Srinath Parvathaneni  

Backported from mainline
2020-06-04  Srinath Parvathaneni  

PR target/94735
* config/arm//predicates.md (mve_scatter_memory): Define to
match (mem (reg)) for scatter store memory.
* config/arm/mve.md (mve_vstrbq_scatter_offset_): Modify
define_insn to define_expand.
(mve_vstrbq_scatter_offset_p_): Likewise.
(mve_vstrhq_scatter_offset_): Likewise.
(mve_vstrhq_scatter_shifted_offset_p_): Likewise.
(mve_vstrhq_scatter_shifted_offset_): Likewise.
(mve_vstrdq_scatter_offset_p_v2di): Likewise.
(mve_vstrdq_scatter_offset_v2di): Likewise.
(mve_vstrdq_scatter_shifted_offset_p_v2di): Likewise.
(mve_vstrdq_scatter_shifted_offset_v2di): Likewise.
(mve_vstrhq_scatter_offset_fv8hf): Likewise.
(mve_vstrhq_scatter_offset_p_fv8hf): Likewise.
(mve_vstrhq_scatter_shifted_offset_fv8hf): Likewise.
(mve_vstrhq_scatter_shifted_offset_p_fv8hf): Likewise.
(mve_vstrwq_scatter_offset_fv4sf): Likewise.
(mve_vstrwq_scatter_offset_p_fv4sf): Likewise.
(mve_vstrwq_scatter_offset_p_v4si): Likewise.
(mve_vstrwq_scatter_offset_v4si): Likewise.
(mve_vstrwq_scatter_shifted_offset_fv4sf): Likewise.
(mve_vstrwq_scatter_shifted_offset_p_fv4sf): Likewise.
(mve_vstrwq_scatter_shifted_offset_p_v4si): Likewise.
(mve_vstrwq_scatter_shifted_offset_v4si): Likewise.
(mve_vstrbq_scatter_offset__insn): Define insn for scatter
stores.
(mve_vstrbq_scatter_offset_p__insn): Likewise.
(mve_vstrhq_scatter_offset__insn): Likewise.
(mve_vstrhq_scatter_shifted_offset_p__insn): Likewise.
(mve_vstrhq_scatter_shifted_offset__insn): Likewise.
(mve_vstrdq_scatter_offset_p_v2di_insn): Likewise.
(mve_vstrdq_scatter_offset_v2di_insn): Likewise.
(mve_vstrdq_scatter_shifted_offset_p_v2di_insn): Likewise.
(mve_vstrdq_scatter_shifted_offset_v2di_insn): Likewise.
(mve_vstrhq_scatter_offset_fv8hf_insn): Likewise.
(mve_vstrhq_scatter_offset_p_fv8hf_insn): Likewise.
(mve_vstrhq_scatter_shifted_offset_fv8hf_insn): Likewise.
(mve_vstrhq_scatter_shifted_offset_p_fv8hf_insn): Likewise.
(mve_vstrwq_scatter_offset_fv4sf_insn): Likewise.
(mve_vstrwq_scatter_offset_p_fv4sf_insn): Likewise.
(mve_vstrwq_scatter_offset_p_v4si_insn): Likewise.
(mve_vstrwq_scatter_offset_v4si_insn): Likewise.
(mve_vstrwq_scatter_shifted_offset_fv4sf_insn): Likewise.
(mve_vstrwq_scatter_shifted_offset_p_fv4sf_insn): Likewise.
(mve_vstrwq_scatter_shifted_offset_p_v4si_insn): Likewise.
(mve_vstrwq_scatter_shifted_offset_v4si_insn): Likewise.

gcc/testsuite/ChangeLog:

2020-06-09  Srinath Parvathaneni  

Backported from mainline
2020-06-04  Srinath Parvathaneni  

PR target/94735
* gcc.target/arm/mve/intrinsics/mve_vstore_scatter_base.c: New test.
* gcc.target/arm/mve/intrinsics/mve_vstore_scatter_base_p.c: Likewise.
* gcc.target/arm/mve/intrinsics/mve_vstore_scatter_offset.c: Likewise.
* gcc.target/arm/mve/intrinsics/mve_vstore_scatter_offset_p.c: Likewise.
* gcc.target/arm/mve/intrinsics/mve_vstore_scatter_shifted_offset.c:
Likewise.
* gcc.target/arm/mve/intrinsics/mve_vstore_scatter_shifted_offset_p.c:
Likewise.


### Attachment also inlined for ease of reply###


diff --git a/gcc/config/arm/mve.md b/gcc/config/arm/mve.md
index 
986fbfe2abae5f1e91e65f1ff5c84709c43c4617..3a57901bd5bcd770832d59dc77cd92b6d9b5ecb4
 100644
--- a/gcc/config/arm/mve.md
+++ b/gcc/config/arm/mve.md
@@ -8102,22 +8102,29 @@
 ;;
 ;; [vstrbq_scatter_offset_s vstrbq_scatter_offset_u]
 ;;
-(define_insn "mve_vstrbq_scatter_offset_"
-  [(set (match_operand: 0 "memory_operand" "=Us")
-   (unspec:
-   [(match_operand:MVE_2 1 "s_register_operand" "w")
-  

RE: [PATCH][GCC-10 Backport] arm: Fix the MVE ACLE vbicq intrinsics.

[Kyrylo Tkachov]

> -Original Message-
> From: Srinath Parvathaneni 
> Sent: 16 June 2020 11:53
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov 
> Subject: [PATCH][GCC-10 Backport] arm: Fix the MVE ACLE vbicq intrinsics.
> 
> Hello,
> 
> Following MVE intrinsic testcases are failing in GCC testsuite.
> 
> Directory: gcc.target/arm/mve/intrinsics/
> Testcases: vbicq_f16.c, vbicq_f32.c, vbicq_s16.c, vbicq_s32.c, vbicq_s8.c
> ,vbicq_u16.c, vbicq_u32.c and vbicq_u8.c.
> 
> This patch fixes the vbicq intrinsics by modifying the intrinsic parameters
> and polymorphic variants in "arm_mve.h" header file.
> 
> Please refer to M-profile Vector Extension (MVE) intrinsics [1]for more
> details.
> [1] https://developer.arm.com/architectures/instruction-sets/simd-
> isas/helium/mve-intrinsics
> 
> Regression tested on arm-none-eabi and found no regressions.
> 
> Ok for GCC-10 branch?

Ok.
Thanks,
Kyrill

> 
> Thanks,
> Srinath.
> 
> gcc/ChangeLog:
> 
> 2020-05-20  Srinath Parvathaneni  
> 
>   Backported from mainline
>   2020-06-04  Srinath Parvathaneni  
> 
>   * config/arm/arm_mve.h (__arm_vbicq_n_u16): Correct the intrinsic
>   arguments.
>   (__arm_vbicq_n_s16): Likewise.
>   (__arm_vbicq_n_u32): Likewise.
>   (__arm_vbicq_n_s32): Likewise.
>   (__arm_vbicq): Modify polymorphic variant.
> 
> gcc/testsuite/ChangeLog:
> 
> 2020-05-20  Srinath Parvathaneni  
> 
>   Backported from mainline
>   2020-06-04  Srinath Parvathaneni  
> 
>   * gcc.target/arm/mve/intrinsics/vbicq_f16.c: Modify.
>   * gcc.target/arm/mve/intrinsics/vbicq_f32.c: Likewise.
>   * gcc.target/arm/mve/intrinsics/vbicq_n_s16.c: Likewise.
>   * gcc.target/arm/mve/intrinsics/vbicq_n_s32.c: Likewise.
>   * gcc.target/arm/mve/intrinsics/vbicq_n_u16.c: Likewise.
>   * gcc.target/arm/mve/intrinsics/vbicq_n_u32.c: Likewise.
>   * gcc.target/arm/mve/intrinsics/vbicq_s16.c: Likewise.
>   * gcc.target/arm/mve/intrinsics/vbicq_s32.c: Likewise.
>   * gcc.target/arm/mve/intrinsics/vbicq_s8.c: Likewise.
>   * gcc.target/arm/mve/intrinsics/vbicq_u16.c: Likewise.
>   * gcc.target/arm/mve/intrinsics/vbicq_u32.c: Likewise.
>   * gcc.target/arm/mve/intrinsics/vbicq_u8.c: Likewise.
> 
> 
> ### Attachment also inlined for ease of reply
> ###
> 
> 
> diff --git a/gcc/config/arm/arm_mve.h b/gcc/config/arm/arm_mve.h
> index
> 1002512a98f9364403f66eba0e320fe5070bdc3a..9bc5c97db8fea15d8140d966
> bc501b8a457a1abf 100644
> --- a/gcc/config/arm/arm_mve.h
> +++ b/gcc/config/arm/arm_mve.h
> @@ -6361,7 +6361,7 @@ __arm_vorrq_n_u16 (uint16x8_t __a, const int
> __imm)
> 
>  __extension__ extern __inline uint16x8_t
>  __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
> -__arm_vbicq_n_u16 (uint16x8_t __a, const uint16_t __imm)
> +__arm_vbicq_n_u16 (uint16x8_t __a, const int __imm)
>  {
>return __builtin_mve_vbicq_n_uv8hi (__a, __imm);
>  }
> @@ -6473,7 +6473,7 @@ __arm_vorrq_n_s16 (int16x8_t __a, const int
> __imm)
> 
>  __extension__ extern __inline int16x8_t
>  __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
> -__arm_vbicq_n_s16 (int16x8_t __a, const int16_t __imm)
> +__arm_vbicq_n_s16 (int16x8_t __a, const int __imm)
>  {
>return __builtin_mve_vbicq_n_sv8hi (__a, __imm);
>  }
> @@ -6564,7 +6564,7 @@ __arm_vorrq_n_u32 (uint32x4_t __a, const int
> __imm)
> 
>  __extension__ extern __inline uint32x4_t
>  __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
> -__arm_vbicq_n_u32 (uint32x4_t __a, const uint32_t __imm)
> +__arm_vbicq_n_u32 (uint32x4_t __a, const int __imm)
>  {
>return __builtin_mve_vbicq_n_uv4si (__a, __imm);
>  }
> @@ -6676,7 +6676,7 @@ __arm_vorrq_n_s32 (int32x4_t __a, const int
> __imm)
> 
>  __extension__ extern __inline int32x4_t
>  __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
> -__arm_vbicq_n_s32 (int32x4_t __a, const int32_t __imm)
> +__arm_vbicq_n_s32 (int32x4_t __a, const int __imm)
>  {
>return __builtin_mve_vbicq_n_sv4si (__a, __imm);
>  }
> @@ -23182,7 +23182,7 @@ __arm_vorrq (uint16x8_t __a, const int __imm)
> 
>  __extension__ extern __inline uint16x8_t
>  __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
> -__arm_vbicq (uint16x8_t __a, const uint16_t __imm)
> +__arm_vbicq (uint16x8_t __a, const int __imm)
>  {
>   return __arm_vbicq_n_u16 (__a, __imm);
>  }
> @@ -23294,7 +23294,7 @@ __arm_vorrq (int16x8_t __a, const int __imm)
> 
>  __extension__ extern __inline int16x8_t
>  __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
> -__arm_vbicq (int16x8_t __a, const int16_t __imm)
> +__arm_vbicq (int16x8_t __a, const int __imm)
>  {
>   return __arm_vbicq_n_s16 (__a, __imm);
>  }
> @@ -23385,7 +23385,7 @@ __arm_vorrq (uint32x4_t __a, const int __imm)
> 
>  __extension__ extern __inline uint32x4_t
>  __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
> -__arm_vbicq (uint32x4_t __a, const uint32_t __imm)
> +__arm

RE: [PATCH][GCC-10 Backport] arm: Fix unintentional fall throughs in arm.c

[Kyrylo Tkachov]

> -Original Message-
> From: Srinath Parvathaneni 
> Sent: 16 June 2020 11:52
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov 
> Subject: [PATCH][GCC-10 Backport] arm: Fix unintentional fall throughs in
> arm.c
> 
> Hi all,
> 
> This small patch fix some unintentional fall-throughs in
> `mve_vector_mem_operand'.
> 
> Regtested and bootstraped on arm-linux-gnueabihf.
> 
> Okay for GCC-10 branch?

Ok.
Thanks,
Kyrill

> 
> Regards,
> Srinath
> 
> gcc/ChangeLog
> 
> 2020-06-09  Srinath Parvathaneni  
> 
>   Backported from mainline
>   2020-05-28  Andrea Corallo  
> 
>   * config/arm/arm.c (mve_vector_mem_operand): Fix unwanted
>   fall-throughs.
> 
> 
> ### Attachment also inlined for ease of reply
> ###
> 
> 
> diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
> index
> 01bc1b8ae9b72700ca5ae0840ee4496fd686b623..a7b7c55a763c66382bc140a
> 4c504840c509df84c 100644
> --- a/gcc/config/arm/arm.c
> +++ b/gcc/config/arm/arm.c
> @@ -13302,26 +13302,31 @@ mve_vector_mem_operand (machine_mode
> mode, rtx op, bool strict)
>   if (abs_hwi (val))
> return ((reg_no < LAST_ARM_REGNUM && reg_no != SP_REGNUM)
> || (!strict && reg_no >= FIRST_PSEUDO_REGISTER));
> + return FALSE;
> case E_V8HImode:
> case E_V8HFmode:
>   if (abs (val) <= 255)
> return ((reg_no < LAST_ARM_REGNUM && reg_no != SP_REGNUM)
> || (!strict && reg_no >= FIRST_PSEUDO_REGISTER));
> + return FALSE;
> case E_V8QImode:
> case E_V4QImode:
>   if (abs_hwi (val))
> return (reg_no <= LAST_LO_REGNUM
> || (!strict && reg_no >= FIRST_PSEUDO_REGISTER));
> + return FALSE;
> case E_V4HImode:
> case E_V4HFmode:
>   if (val % 2 == 0 && abs (val) <= 254)
> return (reg_no <= LAST_LO_REGNUM
> || (!strict && reg_no >= FIRST_PSEUDO_REGISTER));
> + return FALSE;
> case E_V4SImode:
> case E_V4SFmode:
>   if (val % 4 == 0 && abs (val) <= 508)
> return ((reg_no < LAST_ARM_REGNUM && reg_no != SP_REGNUM)
> || (!strict && reg_no >= FIRST_PSEUDO_REGISTER));
> + return FALSE;
> case E_V2DImode:
> case E_V2DFmode:
> case E_TImode:

Re: [PATCH] Defined libcall_arg_t

[Kamlesh Kumar via Gcc-patches]

thanks Richard,

addressed your concern.

diff --git a/gcc/rtl.h b/gcc/rtl.h
index 0872cc4..7206c8a 100644
--- a/gcc/rtl.h
+++ b/gcc/rtl.h
@@ -2238,6 +2238,16 @@ struct address_info {
   enum rtx_code base_outer_code;
 };

+/* This is used for passing args in emit_library_* functions */
+struct libcall_arg {
+  rtx value;
+  machine_mode mode;
+  bool unsigned_p;
+  constexpr
+  libcall_arg (rtx v, machine_mode m, bool u) : value(v), mode(m),
+    unsigned_p(u) {}
+};
+
 /* This is used to bundle an rtx and a mode together so that the pair
    can be used with the wi:: routines.  If we ever put modes into rtx
    integer constants, this should go away and then just pass an rtx 
in.  */


On 16/06/20 2:34 pm, Richard Sandiford wrote:

Thanks for doing this.

Kamlesh Kumar via Gcc-patches  writes:

diff --git a/gcc/rtl.h b/gcc/rtl.h
index 0872cc4..c023ff0 100644
--- a/gcc/rtl.h
+++ b/gcc/rtl.h
@@ -2238,6 +2238,18 @@ struct address_info {
enum rtx_code base_outer_code;
  };
  
+/* This is used for passing args in emit_library_* functions */

+typedef struct libcall_arg {

There's not really any need for a typedef here.  We should just
use “libcall_arg” directly.


+  rtx value;
+  machine_mode mode;
+  bool unsigned_p;
+  libcall_arg (rtx v, machine_mode m, bool u) {
+value = v;
+mode = m;
+unsigned_p = u;
+  }

Please use member initialisation for the fields instead.

Now that we're C++11, the constructor might as well be constexpr.

Thanks,
Richard


+} libcall_arg_t;
+
  /* This is used to bundle an rtx and a mode together so that the pair
 can be used with the wi:: routines.  If we ever put modes into rtx
 integer constants, this should go away and then just pass an rtx in.  */

[PATCH] libiberty, include: add bsearch_r

[Nick Alcock via Gcc-patches]

A resend of something I sent over, sheesh, six months ago.  Jeff Law acked it
but, well, it was six months ago.  I think getting a re-ack might be a good
idea.

(Also... could someone push it for me? I should have push privs, but only on
binutils and I have yet to test them. Starting my pushing career at sourceware
by fubaring gcc is not my idea of a good time.)

8<--->8
libctf wants a bsearch that takes a void * arg pointer to avoid a
nonportable use of __thread.

bsearch_r is required, not optional, at this point because as far as I
can see this obvious-sounding function is not implemented by anyone's
libc.  We can easily move it to AC_LIBOBJ later if it proves necessary
to do so.

include/
* libiberty.h (bsearch_r): New.
libiberty/
* bsearch_r.c: New file.
* Makefile.in (CFILES): Add bsearch_r.c.
(REQUIRED_OFILES): Add bsearch_r.o.
* functions.texi: Regenerate.
---
 include/libiberty.h   |  7 
 libiberty/Makefile.in | 12 +-
 libiberty/bsearch_r.c | 93 +++
 3 files changed, 111 insertions(+), 1 deletion(-)
 create mode 100644 libiberty/bsearch_r.c

diff --git a/include/libiberty.h b/include/libiberty.h
index 141cb886a8..0bb5b81d4a 100644
--- a/include/libiberty.h
+++ b/include/libiberty.h
@@ -641,6 +641,13 @@ extern int pexecute (const char *, char * const *, const 
char *,
 
 extern int pwait (int, int *, int);
 
+/* Like bsearch, but takes and passes on an argument like qsort_r.  */
+
+extern void *bsearch_r (register const void *, const void *,
+   size_t, register size_t,
+   register int (*)(const void *, const void *, void *),
+   void *);
+
 #if defined(HAVE_DECL_ASPRINTF) && !HAVE_DECL_ASPRINTF
 /* Like sprintf but provides a pointer to malloc'd storage, which must
be freed by the caller.  */
diff --git a/libiberty/Makefile.in b/libiberty/Makefile.in
index d6b302e02f..895f701bcd 100644
--- a/libiberty/Makefile.in
+++ b/libiberty/Makefile.in
@@ -124,7 +124,7 @@ COMPILE.c = $(CC) -c @DEFS@ $(CFLAGS) $(CPPFLAGS) -I. 
-I$(INCDIR) \
 # CONFIGURED_OFILES and funcs in configure.ac.  Also run "make maint-deps"
 # to build the new rules.
 CFILES = alloca.c argv.c asprintf.c atexit.c   \
-   basename.c bcmp.c bcopy.c bsearch.c bzero.c \
+   basename.c bcmp.c bcopy.c bsearch.c bsearch_r.c bzero.c \
calloc.c choose-temp.c clock.c concat.c cp-demangle.c   \
 cp-demint.c cplus-dem.c crc32.c\
d-demangle.c dwarfnames.c dyn-string.c  \
@@ -168,6 +168,7 @@ REQUIRED_OFILES =   
\
./regex.$(objext) ./cplus-dem.$(objext) ./cp-demangle.$(objext) \
./md5.$(objext) ./sha1.$(objext) ./alloca.$(objext) \
./argv.$(objext)\
+   ./bsearch_r.$(objext)   \
./choose-temp.$(objext) ./concat.$(objext)  \
./cp-demint.$(objext) ./crc32.$(objext) ./d-demangle.$(objext)  \
./dwarfnames.$(objext) ./dyn-string.$(objext)   \
@@ -601,6 +602,15 @@ $(CONFIGURED_OFILES): stamp-picdir stamp-noasandir
else true; fi
$(COMPILE.c) $(srcdir)/bsearch.c $(OUTPUT_OPTION)
 
+./bsearch_r.$(objext): $(srcdir)/bsearch_r.c config.h $(INCDIR)/ansidecl.h
+   if [ x"$(PICFLAG)" != x ]; then \
+ $(COMPILE.c) $(PICFLAG) $(srcdir)/bsearch_r.c -o pic/$@; \
+   else true; fi
+   if [ x"$(NOASANFLAG)" != x ]; then \
+ $(COMPILE.c) $(PICFLAG) $(NOASANFLAG) $(srcdir)/bsearch_r.c -o 
noasan/$@; \
+   else true; fi
+   $(COMPILE.c) $(srcdir)/bsearch_r.c $(OUTPUT_OPTION)
+
 ./bzero.$(objext): $(srcdir)/bzero.c
if [ x"$(PICFLAG)" != x ]; then \
  $(COMPILE.c) $(PICFLAG) $(srcdir)/bzero.c -o pic/$@; \
diff --git a/libiberty/bsearch_r.c b/libiberty/bsearch_r.c
new file mode 100644
index 00..79ebae9b0b
--- /dev/null
+++ b/libiberty/bsearch_r.c
@@ -0,0 +1,93 @@
+/*
+ * Copyright (c) 1990 Regents of the University of California.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. [rescinded 22 July 1999]
+ * 4. Neither the name of the University nor the names of its contributors
+ *may be used to endorse or promote pro

Re: gcc.dg testsuite glitches

[Thomas Schwinge]

Hi!

On 2020-04-28T11:12:56+0200, Manfred Schwarb  wrote:
> I guess this goes under the obvious and trivial rules.
>
> There are several malformed dejagnu directives in the gcc.dg testsuite.

Generally, ACK, and thanks for the cleanup.

> Below I fixed some of them following these criteria:
> - fix mis-typed directives
> - require that the outermost braces are space padded
> - fix imbalanced braces
>
> Several of these changes are no-ops, as nonsensical directives act as "dg-do 
> compile",
> but they should be fixed nevertheless, IMO.

> --- a/gcc/testsuite/gcc.dg/lto/pr52634_0.c
> +++ b/gcc/testsuite/gcc.dg/lto/pr52634_0.c
> @@ -1,7 +1,7 @@
>  /* { dg-require-weak "" } */
>  /* { dg-require-alias "" } */
>  /* { dg-lto-do link } */
> -/* { dg-lto-options {{-flto -r -flto-partition=1to1}} */
> +/* { dg-lto-options {-flto -r -flto-partition=1to1} } */
>  /* { dg-extra-ld-options "-flinker-output=nolto-rel" } */
>  extern int cfliteValueCallBacks;
>  void baz (int *);

That one's not correct: 'dg-lto-options' is "special".  I've pushed
commit b70eeb248efe2b3e9bdb5e26b490e3d8aa07022d "Further adjust
'dg-lto-options' in 'gcc.dg/lto/pr52634'", see attached.  (I'll claim you
ran into that because you said "obvious and trivial".)  ;-P


Grüße
 Thomas


-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter
>From b70eeb248efe2b3e9bdb5e26b490e3d8aa07022d Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Sat, 6 Jun 2020 13:50:24 +0200
Subject: [PATCH] Further adjust 'dg-lto-options' in 'gcc.dg/lto/pr52634'

The recent commit f8a4141bae53f9125d374e5873dcda3f75392f1f "Fix various dg
directives" corrected the imbalanced curly braces in 'dg-lto-options', which
changes the testing as follows:

-PASS: gcc.dg/lto/pr52634 c_lto_pr52634_0.o assemble, -O0 -flto -flto-partition=none -fuse-linker-plugin
-PASS: gcc.dg/lto/pr52634 c_lto_pr52634_1.o assemble, -O0 -flto -flto-partition=none -fuse-linker-plugin
-PASS: gcc.dg/lto/pr52634 c_lto_pr52634_0.o-c_lto_pr52634_1.o link, -O0 -flto -flto-partition=none -fuse-linker-plugin
-PASS: gcc.dg/lto/pr52634 c_lto_pr52634_0.o assemble, -O2 -flto -flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects
-PASS: gcc.dg/lto/pr52634 c_lto_pr52634_1.o assemble, -O2 -flto -flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects
-PASS: gcc.dg/lto/pr52634 c_lto_pr52634_0.o-c_lto_pr52634_1.o link, -O2 -flto -flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects
-PASS: gcc.dg/lto/pr52634 c_lto_pr52634_0.o assemble, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin
-PASS: gcc.dg/lto/pr52634 c_lto_pr52634_1.o assemble, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin
-PASS: gcc.dg/lto/pr52634 c_lto_pr52634_0.o-c_lto_pr52634_1.o link, -O0 -flto -flto-partition=1to1 -fno-use-linker-plugin
-PASS: gcc.dg/lto/pr52634 c_lto_pr52634_0.o assemble, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin
-PASS: gcc.dg/lto/pr52634 c_lto_pr52634_1.o assemble, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin
-PASS: gcc.dg/lto/pr52634 c_lto_pr52634_0.o-c_lto_pr52634_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin
-PASS: gcc.dg/lto/pr52634 c_lto_pr52634_0.o assemble, -O0 -flto -fuse-linker-plugin -fno-fat-lto-objects
-PASS: gcc.dg/lto/pr52634 c_lto_pr52634_1.o assemble, -O0 -flto -fuse-linker-plugin -fno-fat-lto-objects
-PASS: gcc.dg/lto/pr52634 c_lto_pr52634_0.o-c_lto_pr52634_1.o link, -O0 -flto -fuse-linker-plugin -fno-fat-lto-objects
-PASS: gcc.dg/lto/pr52634 c_lto_pr52634_0.o assemble, -O2 -flto -fuse-linker-plugin
-PASS: gcc.dg/lto/pr52634 c_lto_pr52634_1.o assemble, -O2 -flto -fuse-linker-plugin
-PASS: gcc.dg/lto/pr52634 c_lto_pr52634_0.o-c_lto_pr52634_1.o link, -O2 -flto -fuse-linker-plugin
+PASS: gcc.dg/lto/pr52634 c_lto_pr52634_0.o assemble, -flto
+PASS: gcc.dg/lto/pr52634 c_lto_pr52634_1.o assemble, -flto
+PASS: gcc.dg/lto/pr52634 c_lto_pr52634_0.o-c_lto_pr52634_1.o link, -flto
+PASS: gcc.dg/lto/pr52634 c_lto_pr52634_0.o assemble, -r
+PASS: gcc.dg/lto/pr52634 c_lto_pr52634_1.o assemble, -r
+PASS: gcc.dg/lto/pr52634 c_lto_pr52634_0.o-c_lto_pr52634_1.o link, -r
+PASS: gcc.dg/lto/pr52634 c_lto_pr52634_0.o assemble, -flto-partition=1to1
+PASS: gcc.dg/lto/pr52634 c_lto_pr52634_1.o assemble, -flto-partition=1to1
+PASS: gcc.dg/lto/pr52634 c_lto_pr52634_0.o-c_lto_pr52634_1.o link, -flto-partition=1to1

I however assume the original idea however has not been to run variants
'-flto', '-r', '-flto-partition=1to1' individually, but rather to run one
variant '-flto -r -flto-partition=1to1'.

	gcc/testsuite/
	* gcc.dg/lto/pr52634_0.c: Further adjust 'dg-lto-options'.
---
 gcc/testsuite/gcc.dg/lto/pr52634_0.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/lto/pr52634_0.c b/gcc/testsuite/gcc.dg/lto/p

[Patch] OpenMP/Fortran: Permit impure ELEMENTAL in omp directives

[Tobias Burnus]

Hi all,

when looking into a PURE/ELEMENTAL issue with OpenACC, Thomas and
I came across the analogous OpenMP code – and stumbled over
ELEMENTAL.

In Fortran, ELEMENTAL implies PURE but one can also have an IMPURE
ELEMENTAL procedure.

As PR 79154 quotes, OpenMP 4 had:
"OpenMP directives may not appear in PURE or ELEMENTAL procedures."

While OpenMP 4.5 (and later) have:
"OpenMP directives, except SIMD and declare target directives,
 may not appear in pure procedures."

ELEMENTAL is still mentioned – but only for:
"OpenMP runtime library routines may not be called
 from PURE or ELEMENTAL procedures."

OK for the trunk?

Tobias

-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter
OpenMP/Fortran: Permit impure ELEMENTAL in omp directives

OpenMP since 4.5 permits IMPURE ELEMENTAL in directives and
the code already only checked for PURE.

gcc/fortran/ChangeLog:

	* parse.c (decode_omp_directive): Remove "or ELEMENTAL"
	from "in PURE" error message.

gcc/testsuite/ChangeLog:

	* gfortran.dg/gomp/pr79154-1.f90: Update dg-*;
	add an impure elemental example.
	* gfortran.dg/gomp/pr79154-2.f90: Likewise.

 gcc/fortran/parse.c  |  4 ++--
 gcc/testsuite/gfortran.dg/gomp/pr79154-1.f90 | 15 +-
 gcc/testsuite/gfortran.dg/gomp/pr79154-2.f90 | 30 +++-
 3 files changed, 33 insertions(+), 16 deletions(-)

diff --git a/gcc/fortran/parse.c b/gcc/fortran/parse.c
index f71a95dd871..9d90e501bf6 100644
--- a/gcc/fortran/parse.c
+++ b/gcc/fortran/parse.c
@@ -849,7 +849,7 @@ decode_omp_directive (void)
   /* match is for directives that should be recognized only if
  -fopenmp, matchs for directives that should be recognized
  if either -fopenmp or -fopenmp-simd.
- Handle only the directives allowed in PURE/ELEMENTAL procedures
+ Handle only the directives allowed in PURE procedures
  first (those also shall not turn off implicit pure).  */
   switch (c)
 {
@@ -868,7 +868,7 @@ decode_omp_directive (void)
   if (flag_openmp && gfc_pure (NULL))
 {
   gfc_error_now ("OpenMP directives other than SIMD or DECLARE TARGET "
-		 "at %C may not appear in PURE or ELEMENTAL procedures");
+		 "at %C may not appear in PURE procedures");
   gfc_error_recovery ();
   return ST_NONE;
 }
diff --git a/gcc/testsuite/gfortran.dg/gomp/pr79154-1.f90 b/gcc/testsuite/gfortran.dg/gomp/pr79154-1.f90
index 69a0009e13c..ea147bfa78e 100644
--- a/gcc/testsuite/gfortran.dg/gomp/pr79154-1.f90
+++ b/gcc/testsuite/gfortran.dg/gomp/pr79154-1.f90
@@ -2,7 +2,7 @@
 ! { dg-do compile }
 
 pure real function foo (a, b)		! { dg-warning "GCC does not currently support mixed size types for 'simd' functions" "" { target aarch64*-*-* } }
-!$omp declare simd(foo)			! { dg-bogus "may not appear in PURE or ELEMENTAL" }
+!$omp declare simd(foo)			! { dg-bogus "may not appear in PURE" }
   real, intent(in) :: a, b
   foo = a + b
 end function foo
@@ -10,23 +10,28 @@ pure function bar (a, b)
   real, intent(in) :: a(8), b(8)
   real :: bar(8)
   integer :: i
-!$omp simd! { dg-bogus "may not appear in PURE or ELEMENTAL" }
+!$omp simd! { dg-bogus "may not appear in PURE" }
   do i = 1, 8
 bar(i) = a(i) + b(i)
   end do
 end function bar
 pure real function baz (a, b)
-!$omp declare target			! { dg-bogus "may not appear in PURE or ELEMENTAL" }
+!$omp declare target			! { dg-bogus "may not appear in PURE" }
   real, intent(in) :: a, b
   baz = a + b
 end function baz
 elemental real function fooe (a, b)	! { dg-warning "GCC does not currently support mixed size types for 'simd' functions" "" { target aarch64*-*-* } }
-!$omp declare simd(fooe)		! { dg-bogus "may not appear in PURE or ELEMENTAL" }
+!$omp declare simd(fooe)		! { dg-bogus "may not appear in PURE" }
   real, intent(in) :: a, b
   fooe = a + b
 end function fooe
 elemental real function baze (a, b)
-!$omp declare target			! { dg-bogus "may not appear in PURE or ELEMENTAL" }
+!$omp declare target			! { dg-bogus "may not appear in PURE" }
   real, intent(in) :: a, b
   baze = a + b
 end function baze
+elemental impure real function bazei (a, b)
+!$omp declare target			! { dg-bogus "may not appear in PURE" }
+  real, intent(in) :: a, b
+  baze = a + b
+end function bazei
diff --git a/gcc/testsuite/gfortran.dg/gomp/pr79154-2.f90 b/gcc/testsuite/gfortran.dg/gomp/pr79154-2.f90
index 67344f0c028..38d3fe5c384 100644
--- a/gcc/testsuite/gfortran.dg/gomp/pr79154-2.f90
+++ b/gcc/testsuite/gfortran.dg/gomp/pr79154-2.f90
@@ -3,14 +3,14 @@
 
 pure real function foo (a, b)
   real, intent(in) :: a, b
-!$omp taskwait! { dg-error "may not appear in PURE or ELEMENTAL" }
+!$omp taskwait! { dg-error "may not appear in PURE" }
   foo = a + b
 end function foo
 pure function bar (a, b)
   real, intent(in) :: a(8), b(8)
   real :: bar(8)
   integer :: i
-!$omp do simd! { dg-error "may 

Re: [PATCH][v2] tree-optimization/94988 - enhance SM some more

[Thomas Schwinge]

Hi!

On 2020-05-11T16:51:41+0200, Richard Biener  wrote:
> This enhances store-order preserving store motion to handle the case
> of non-invariant dependent stores in the sequence of unconditionally
> executed stores on exit by re-issueing them as part of the sequence
> of stores on the exit.  This fixes the observed regression of
> gcc.target/i386/pr64110.c which relies on store-motion of 'b'
> for a loop like
>
>   for (int i = 0; i < j; ++i)
> *b++ = x;
>
> where for correctness we now no longer apply store-motion.  With
> the patch we emit the correct
>
>   tem = b;
>   for (int i = 0; i < j; ++i)
> {
>   tem = tem + 1;
>   *tem = x;
> }
>   b = tem;
>   *tem = x;
>
> preserving the original order of stores.  A testcase reflecting
> the miscompilation done by earlier GCC is added as well.
>
> This also fixes the reported ICE in PR95025 and adds checking code
> to catch it earlier - the issue was not-supported refs propagation
> leaving stray refs in the sequence.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.

I noticed that since this commit b6ff3ddecfa93d53867afaaa078f85fc848abbbd
"tree-optimization/94988 - enhance SM some more", for
'gcc.dg/graphite/pr80906.c' XPASSes what you recently had XFAILed in
commit 283cb9ea6293e813e48a1b769e1e0779918ea20a "tree-optimization/57359
- rewrite SM code".  I've thus pushed commit
2210ef7d3d68a027ec16476825049567953c7fa4 "Un-XFAIL
'gcc.dg/graphite/pr80906.c'", see attached.  I assume but have not
verified that's the expected/correct thing vs. your commit introducing a
bug.  ;-)


Grüße
 Thomas


> 2020-05-11  Richard Biener  
>
>   PR tree-optimization/94988
>   PR tree-optimization/95025
>   * tree-ssa-loop-im.c (seq_entry): Make a struct, add from.
>   (sm_seq_push_down): Take extra parameter denoting where we
>   moved the ref to.
>   (execute_sm_exit): Re-issue sm_other stores in the correct
>   order.
>   (sm_seq_valid_bb): When always executed, allow sm_other to
>   prevail inbetween sm_ord and record their stored value.
>   (hoist_memory_references): Adjust refs_not_supported propagation
>   and prune sm_other from the end of the ordered sequences.
>
>   * gcc.dg/torture/pr94988.c: New testcase.
>   * gcc.dg/torture/pr95025.c: Likewise.
>   * gcc.dg/torture/pr95045.c: Likewise.
>   * g++.dg/asan/pr95025.C: New testcase.
> ---
>  gcc/testsuite/g++.dg/asan/pr95025.C|  28 
>  gcc/testsuite/gcc.dg/torture/pr94988.c |  20 +++
>  gcc/testsuite/gcc.dg/torture/pr95025.c |  13 ++
>  gcc/testsuite/gcc.dg/torture/pr95045.c |  29 
>  gcc/tree-ssa-loop-im.c | 177 ++---
>  5 files changed, 218 insertions(+), 49 deletions(-)
>  create mode 100644 gcc/testsuite/g++.dg/asan/pr95025.C
>  create mode 100644 gcc/testsuite/gcc.dg/torture/pr94988.c
>  create mode 100644 gcc/testsuite/gcc.dg/torture/pr95025.c
>  create mode 100644 gcc/testsuite/gcc.dg/torture/pr95045.c
>
> diff --git a/gcc/testsuite/g++.dg/asan/pr95025.C 
> b/gcc/testsuite/g++.dg/asan/pr95025.C
> new file mode 100644
> index 000..dabb7e92f82
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/asan/pr95025.C
> @@ -0,0 +1,28 @@
> +// { dg-do compile }
> +// { dg-options "-O2 -fsanitize=address" }
> +
> +struct a {
> +int b;
> +} * c;
> +struct d {
> +d *e;
> +};
> +struct f {
> +bool done;
> +d *g;
> +};
> +int h;
> +int i(f *j) {
> +if (j->g) {
> + j->g = j->g->e;
> + return h;
> +}
> +j->done = true;
> +return 0;
> +}
> +void k(bool j) { c->b = j; }
> +void l() {
> +f a;
> +for (; !(&a)->done; i(&a))
> +  k(true);
> +}
> diff --git a/gcc/testsuite/gcc.dg/torture/pr94988.c 
> b/gcc/testsuite/gcc.dg/torture/pr94988.c
> new file mode 100644
> index 000..1ee99fea5ce
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/torture/pr94988.c
> @@ -0,0 +1,20 @@
> +/* { dg-do run } */
> +
> +short *b;
> +
> +void __attribute__((noipa))
> +bar (short x, int j)
> +{
> +  for (int i = 0; i < j; ++i)
> +*b++ = x;
> +}
> +
> +int
> +main()
> +{
> +  b = (short *)&b;
> +  bar (0, 1);
> +  if ((short)(__UINTPTR_TYPE__)b != 0)
> +__builtin_abort ();
> +  return 0;
> +}
> diff --git a/gcc/testsuite/gcc.dg/torture/pr95025.c 
> b/gcc/testsuite/gcc.dg/torture/pr95025.c
> new file mode 100644
> index 000..5834dc04887
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/torture/pr95025.c
> @@ -0,0 +1,13 @@
> +/* { dg-do compile } */
> +
> +static int a;
> +short b;
> +int *c;
> +void d() {
> +for (;; a -= 1)
> +  for (; b; b += 1) {
> +   *c ^= 5;
> +   if (a)
> + return;
> +  }
> +}
> diff --git a/gcc/testsuite/gcc.dg/torture/pr95045.c 
> b/gcc/testsuite/gcc.dg/torture/pr95045.c
> new file mode 100644
> index 000..9f591beb6be
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/torture/pr95045.c
> @@ -0,0 +1,29 @@
> +/* { dg-do run } */
> +
> +int a, c, f;
> +long b;
> +char d;
> +int e[3];
> +int g[9][3][

Re: [Patch] OpenMP/Fortran: Permit impure ELEMENTAL in omp directives

[Jakub Jelinek via Gcc-patches]

On Tue, Jun 16, 2020 at 01:27:43PM +0200, Tobias Burnus wrote:
> when looking into a PURE/ELEMENTAL issue with OpenACC, Thomas and
> I came across the analogous OpenMP code – and stumbled over
> ELEMENTAL.
> 
> In Fortran, ELEMENTAL implies PURE but one can also have an IMPURE
> ELEMENTAL procedure.
> 
> As PR 79154 quotes, OpenMP 4 had:
> "OpenMP directives may not appear in PURE or ELEMENTAL procedures."
> 
> While OpenMP 4.5 (and later) have:
> "OpenMP directives, except SIMD and declare target directives,
>  may not appear in pure procedures."
> 
> ELEMENTAL is still mentioned – but only for:
> "OpenMP runtime library routines may not be called
>  from PURE or ELEMENTAL procedures."
> 
> OK for the trunk?

Ok.

Jakub

RE: [PATCH][GCC-10 Backport] arm: Fix the wrong code-gen generated by MVE vector load/store intrinsics (PR94959).

[Kyrylo Tkachov]

> -Original Message-
> From: Srinath Parvathaneni 
> Sent: 16 June 2020 11:50
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov 
> Subject: [PATCH][GCC-10 Backport] arm: Fix the wrong code-gen generated
> by MVE vector load/store intrinsics (PR94959).
> 
> Hello,
> 
> Few MVE intrinsics like vldrbq_s32, vldrhq_s32 etc., the assembler
> instructions
> generated by current compiler are wrong.
> eg: vldrbq_s32 generates an assembly instructions `vldrb.s32 q0,[ip]`.
> But as per Arm-arm second argument in above instructions must also be a
> low
> register (<= r7). This patch fixes this issue by creating a new predicate
> "mve_memory_operand" and constraint "Ux" which allows low registers as
> arguments
> to the generated instructions depending on the mode of the argument. A
> new constraint
> "Ul" is created to handle loading to PC-relative addressing modes for vector
> store/load intrinsiscs.
> All the corresponding MVE intrinsic generating wrong code-gen as vldrbq_s32
> are modified in this patch.
> 
> Please refer to M-profile Vector Extension (MVE) intrinsics [1] and Armv8-M
> Architecture Reference Manual [2] for more details.
> [1] https://developer.arm.com/architectures/instruction-sets/simd-
> isas/helium/mve-intrinsics
> [2] https://developer.arm.com/docs/ddi0553/latest
> 
> Regression tested on arm-none-eabi and found no regressions.
> 
> Ok for gcc-10 branch?

Ok.
Thanks,
Kyrill

> 
> Thanks,
> Srinath.
> 
> gcc/ChangeLog:
> 
> 2020-06-09  Srinath Parvathaneni  
> 
>   Backported from mainline
>   2020-05-20  Srinath Parvathaneni  
>   Andre Vieira  
> 
>   PR target/94959
>   * config/arm/arm-protos.h (arm_mode_base_reg_class): Function
>   declaration.
>   (mve_vector_mem_operand): Likewise.
>   * config/arm/arm.c (thumb2_legitimate_address_p): For MVE target
> check
>   the load from memory to a core register is legitimate for give mode.
>   (mve_vector_mem_operand): Define function.
>   (arm_print_operand): Modify comment.
>   (arm_mode_base_reg_class): Define.
>   * config/arm/arm.h (MODE_BASE_REG_CLASS): Modify to add check
> for
>   TARGET_HAVE_MVE and expand to arm_mode_base_reg_class on
> TRUE.
>   * config/arm/constraints.md (Ux): Likewise.
>   (Ul): Likewise.
>   * config/arm/mve.md (mve_mov): Replace constraint Us with Ux and
> also
>   add support for missing Vector Store Register and Vector Load
> Register.
>   Add a new alternative to support load from memory to PC (or label)
> in
>   vector store/load.
>   (mve_vstrbq_): Modify constraint Us to Ux.
>   (mve_vldrbq_): Modify constriant Us to Ux, predicate
> to
>   mve_memory_operand and also modify the MVE instructions to emit.
>   (mve_vldrbq_z_): Modify constraint Us to Ux.
>   (mve_vldrhq_fv8hf): Modify constriant Us to Ux, predicate to
>   mve_memory_operand and also modify the MVE instructions to emit.
>   (mve_vldrhq_): Modify constriant Us to Ux, predicate
> to
>   mve_memory_operand and also modify the MVE instructions to emit.
>   (mve_vldrhq_z_fv8hf): Likewise.
>   (mve_vldrhq_z_): Likewise.
>   (mve_vldrwq_fv4sf): Likewise.
>   (mve_vldrwq_v4si): Likewise.
>   (mve_vldrwq_z_fv4sf): Likewise.
>   (mve_vldrwq_z_v4si): Likewise.
>   (mve_vld1q_f): Modify constriant Us to Ux.
>   (mve_vld1q_): Likewise.
>   (mve_vstrhq_fv8hf): Modify constriant Us to Ux, predicate to
>   mve_memory_operand.
>   (mve_vstrhq_p_fv8hf): Modify constriant Us to Ux, predicate to
>   mve_memory_operand and also modify the MVE instructions to emit.
>   (mve_vstrhq_p_): Likewise.
>   (mve_vstrhq_): Modify constriant Us to Ux, predicate
> to
>   mve_memory_operand.
>   (mve_vstrwq_fv4sf): Modify constriant Us to Ux.
>   (mve_vstrwq_p_fv4sf): Modify constriant Us to Ux and also modify
> the MVE
>   instructions to emit.
>   (mve_vstrwq_p_v4si): Likewise.
>   (mve_vstrwq_v4si): Likewise.Modify constriant Us to Ux.
>   * config/arm/predicates.md (mve_memory_operand): Define.
> 
> gcc/testsuite/ChangeLog:
> 
> 2020-06-09  Srinath Parvathaneni  
> 
> Backported from mainline
> 2020-05-20  Srinath Parvathaneni  
> 
>   PR target/94959
>   * gcc.target/arm/mve/intrinsics/mve_vector_float2.c: Modify.
>   * gcc.target/arm/mve/intrinsics/mve_vldr.c: New test.
>   * gcc.target/arm/mve/intrinsics/mve_vldr_z.c: Likewise.
>   * gcc.target/arm/mve/intrinsics/mve_vstr.c: Likewise.
>   * gcc.target/arm/mve/intrinsics/mve_vstr_p.c: Likewise.
>   * gcc.target/arm/mve/intrinsics/vld1q_f16.c: Modify.
>   * gcc.target/arm/mve/intrinsics/vld1q_f32.c: Likewise.
>   * gcc.target/arm/mve/intrinsics/vld1q_s16.c: Likewise.
>   * gcc.target/arm/mve/intrinsics/vld1q_s32.c: Likewise.
>   * gcc.target/arm/mve/intrinsics/vld1q_s8.c: Likewise.
>   * gcc.target/arm/mve/intrinsics/vld1q_u16.c: Likewise.
>  

RE: [PATCH][GCC-10 Backport] arm: Correct the grouping of operands in MVE vector scatter store intrinsics (PR94735).

[Kyrylo Tkachov]

> -Original Message-
> From: Srinath Parvathaneni 
> Sent: 16 June 2020 11:53
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov 
> Subject: [PATCH][GCC-10 Backport] arm: Correct the grouping of operands in
> MVE vector scatter store intrinsics (PR94735).
> 
> Hello,
> 
> The operands in RTL patterns of MVE vector scatter store intrinsics are
> wrongly grouped, because of which few
> vector loads and stores instructions are wrongly getting optimized out with -
> O2.
> 
> A new predicate "mve_scatter_memory" is defined in this patch, this
> predicate returns TRUE on
> matching: (mem(reg)) for MVE scatter store intrinsics.
> This patch fixes the issue by adding define_expand pattern with
> "mve_scatter_memory" predicate and calls the
> corresponding define_insn by passing register_operand as first argument.
> This register_operand is extracted
> from the operand with "mve_scatter_memory" predicate in define_expand
> pattern.
> 
> Please refer to M-profile Vector Extension (MVE) intrinsics [1]  for more
> details.
> [1] https://developer.arm.com/architectures/instruction-sets/simd-
> isas/helium/mve-intrinsics
> 
> Regression tested on arm-none-eabi and found no regressions.
> 
> Ok for GCC-10 branch?
> 

Ok.
Thanks,
Kyrill

> Thanks,
> Srinath.
> 
> gcc/ChangeLog:
> 
> 2020-06-09  Srinath Parvathaneni  
> 
>   Backported from mainline
>   2020-06-04  Srinath Parvathaneni  
> 
>   PR target/94735
>   * config/arm//predicates.md (mve_scatter_memory): Define to
>   match (mem (reg)) for scatter store memory.
>   * config/arm/mve.md (mve_vstrbq_scatter_offset_):
> Modify
>   define_insn to define_expand.
>   (mve_vstrbq_scatter_offset_p_): Likewise.
>   (mve_vstrhq_scatter_offset_): Likewise.
>   (mve_vstrhq_scatter_shifted_offset_p_): Likewise.
>   (mve_vstrhq_scatter_shifted_offset_): Likewise.
>   (mve_vstrdq_scatter_offset_p_v2di): Likewise.
>   (mve_vstrdq_scatter_offset_v2di): Likewise.
>   (mve_vstrdq_scatter_shifted_offset_p_v2di): Likewise.
>   (mve_vstrdq_scatter_shifted_offset_v2di): Likewise.
>   (mve_vstrhq_scatter_offset_fv8hf): Likewise.
>   (mve_vstrhq_scatter_offset_p_fv8hf): Likewise.
>   (mve_vstrhq_scatter_shifted_offset_fv8hf): Likewise.
>   (mve_vstrhq_scatter_shifted_offset_p_fv8hf): Likewise.
>   (mve_vstrwq_scatter_offset_fv4sf): Likewise.
>   (mve_vstrwq_scatter_offset_p_fv4sf): Likewise.
>   (mve_vstrwq_scatter_offset_p_v4si): Likewise.
>   (mve_vstrwq_scatter_offset_v4si): Likewise.
>   (mve_vstrwq_scatter_shifted_offset_fv4sf): Likewise.
>   (mve_vstrwq_scatter_shifted_offset_p_fv4sf): Likewise.
>   (mve_vstrwq_scatter_shifted_offset_p_v4si): Likewise.
>   (mve_vstrwq_scatter_shifted_offset_v4si): Likewise.
>   (mve_vstrbq_scatter_offset__insn): Define insn for
> scatter
>   stores.
>   (mve_vstrbq_scatter_offset_p__insn): Likewise.
>   (mve_vstrhq_scatter_offset__insn): Likewise.
>   (mve_vstrhq_scatter_shifted_offset_p__insn):
> Likewise.
>   (mve_vstrhq_scatter_shifted_offset__insn): Likewise.
>   (mve_vstrdq_scatter_offset_p_v2di_insn): Likewise.
>   (mve_vstrdq_scatter_offset_v2di_insn): Likewise.
>   (mve_vstrdq_scatter_shifted_offset_p_v2di_insn): Likewise.
>   (mve_vstrdq_scatter_shifted_offset_v2di_insn): Likewise.
>   (mve_vstrhq_scatter_offset_fv8hf_insn): Likewise.
>   (mve_vstrhq_scatter_offset_p_fv8hf_insn): Likewise.
>   (mve_vstrhq_scatter_shifted_offset_fv8hf_insn): Likewise.
>   (mve_vstrhq_scatter_shifted_offset_p_fv8hf_insn): Likewise.
>   (mve_vstrwq_scatter_offset_fv4sf_insn): Likewise.
>   (mve_vstrwq_scatter_offset_p_fv4sf_insn): Likewise.
>   (mve_vstrwq_scatter_offset_p_v4si_insn): Likewise.
>   (mve_vstrwq_scatter_offset_v4si_insn): Likewise.
>   (mve_vstrwq_scatter_shifted_offset_fv4sf_insn): Likewise.
>   (mve_vstrwq_scatter_shifted_offset_p_fv4sf_insn): Likewise.
>   (mve_vstrwq_scatter_shifted_offset_p_v4si_insn): Likewise.
>   (mve_vstrwq_scatter_shifted_offset_v4si_insn): Likewise.
> 
> gcc/testsuite/ChangeLog:
> 
> 2020-06-09  Srinath Parvathaneni  
> 
>   Backported from mainline
>   2020-06-04  Srinath Parvathaneni  
> 
>   PR target/94735
>   * gcc.target/arm/mve/intrinsics/mve_vstore_scatter_base.c: New
> test.
>   * gcc.target/arm/mve/intrinsics/mve_vstore_scatter_base_p.c:
> Likewise.
>   * gcc.target/arm/mve/intrinsics/mve_vstore_scatter_offset.c:
> Likewise.
>   * gcc.target/arm/mve/intrinsics/mve_vstore_scatter_offset_p.c:
> Likewise.
>   * gcc.target/arm/mve/intrinsics/mve_vstore_scatter_shifted_offset.c:
>   Likewise.
>   *
> gcc.target/arm/mve/intrinsics/mve_vstore_scatter_shifted_offset_p.c:
>   Likewise.
> 
> 
> ### Attachment also inlined for ease of reply
> ###
> 
> 
> diff --git a/gcc/config/arm/mve.md b/gcc/config/arm/mve.md
> index
> 986fbfe2abae5f1e91e65f1f

RE: [PATCH][GCC] arm: Fix MVE scalar shift intrinsics code-gen.

[Kyrylo Tkachov]

> -Original Message-
> From: Srinath Parvathaneni 
> Sent: 15 June 2020 09:46
> To: gcc Patches 
> Cc: Kyrylo Tkachov ; Richard Earnshaw
> 
> Subject: [PATCH][GCC] arm: Fix MVE scalar shift intrinsics code-gen.
> 
> Hello,
> 
> This patch modifies the MVE scalar shift RTL patterns. The current patterns
> have wrong constraints and predicates due to which the values returned
> from
> MVE scalar shift instructions are overwritten in the code-gen.
> 
> example:
> $ cat x.c
> #include "arm_mve.h"
> int32_t  foo(int64_t acc, int shift)
> {
>   return sqrshrl_sat48 (acc, shift);
> }
> 
> Code-gen before applying this patch:
> $ arm-none-eabi-gcc -march=armv8.1-m.main+mve -mfloat-abi=hard -O2 -S
> $  cat x.s
> foo:
>push{r4, r5}
>sqrshrl r0, r1, #48, r2   > (a)
>mov r0, r4  > (b)
>pop {r4, r5}
>bx  lr
> 
> Code-gen after applying this patch:
> foo:
>sqrshrl r0, r1, #48, r2
>bx  lr
> 
> In the current compiler the return value (r0) from sqrshrl (a) is getting
> overwritten by the mov statement (b).
> This patch fixes above issue.
> 
> Please refer to M-profile Vector Extension (MVE) intrinsics [1]for more
> details.
> [1] https://developer.arm.com/architectures/instruction-sets/simd-
> isas/helium/mve-intrinsics
> 
> Regression tested on arm-none-eabi and found no regressions.
> 
> Ok for master and gcc-10 branch?
> 

Ok.
Thanks,
Kyrill

> Thanks,
> Srinath.
> 
> gcc/ChangeLog:
> 
> 2020-06-12  Srinath Parvathaneni  
> 
> * config/arm/mve.md (mve_uqrshll_sat_di): Correct the predicate
> and constraint of all the operands.
> (mve_sqrshrl_sat_di): Likewise.
> (mve_uqrshl_si): Likewise.
> (mve_sqrshr_si): Likewise.
> (mve_uqshll_di): Likewise.
> (mve_urshrl_di): Likewise.
> (mve_uqshl_si): Likewise.
> (mve_urshr_si): Likewise.
> (mve_sqshl_si): Likewise.
> (mve_srshr_si): Likewise.
> (mve_srshrl_di): Likewise.
> (mve_sqshll_di): Likewise.
> * config/arm/predicates.md (arm_low_register_operand): Define.
> 
> gcc/testsuite/ChangeLog:
> 
> 2020-06-12  Srinath Parvathaneni  
> 
> * gcc.target/arm/mve/intrinsics/mve_scalar_shifts1.c: New test.
> * gcc.target/arm/mve/intrinsics/mve_scalar_shifts2.c: Likewise.
> * gcc.target/arm/mve/intrinsics/mve_scalar_shifts3.c: Likewise.
> * gcc.target/arm/mve/intrinsics/mve_scalar_shifts4.c: Likewise.

RE: [PATCH][GCC] arm: Fix the MVE ACLE vaddq_m polymorphic variants.

[Kyrylo Tkachov]

> -Original Message-
> From: Srinath Parvathaneni 
> Sent: 04 June 2020 17:57
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov 
> Subject: [PATCH][GCC] arm: Fix the MVE ACLE vaddq_m polymorphic variants.
> 
> Hello,
> 
> This patch fixes the MVE ACLE vaddq_m polymorphic variants by modifying
> the corresponding
> intrinsic parameters and vaddq_m polymorphic variant's _Generic case
> entries in "arm_mve.h"
> header file.
> 
> Please refer to M-profile Vector Extension (MVE) intrinsics [1] for more
> details.
> [1] https://developer.arm.com/architectures/instruction-sets/simd-
> isas/helium/mve-intrinsics
> 
> Regression tested on arm-none-eabi and found no regressions.
> 
> Ok for master and gcc-10 branch?
> 

Ok.
Thanks,
Kyrill

> Thanks,
> Srinath.
> 
> gcc/ChangeLog:
> 
> 2020-06-04  Srinath Parvathaneni  
> 
>   * config/arm/arm_mve.h (__arm_vaddq_m_n_s8): Correct the
> intrinsic
>   arguments.
>   (__arm_vaddq_m_n_s32): Likewise.
>   (__arm_vaddq_m_n_s16): Likewise.
>   (__arm_vaddq_m_n_u8): Likewise.
>   (__arm_vaddq_m_n_u32): Likewise.
>   (__arm_vaddq_m_n_u16): Likewise.
>   (__arm_vaddq_m): Modify polymorphic variant.
> 
> gcc/testsuite/ChangeLog:
> 
> 2020-06-04  Srinath Parvathaneni  
> 
>   * gcc.target/arm/mve/intrinsics/mve_vaddq_m.c: New test.
> 
> 
> 
> ### Attachment also inlined for ease of reply
> ###
> 
> 
> diff --git a/gcc/config/arm/arm_mve.h b/gcc/config/arm/arm_mve.h
> index
> 1002512a98f9364403f66eba0e320fe5070bdc3a..9ea146189883c09c71842f10
> d25dc9924b5ae7e3 100644
> --- a/gcc/config/arm/arm_mve.h
> +++ b/gcc/config/arm/arm_mve.h
> @@ -9713,42 +9713,42 @@ __arm_vabdq_m_u16 (uint16x8_t __inactive,
> uint16x8_t __a, uint16x8_t __b, mve_pr
> 
>  __extension__ extern __inline int8x16_t
>  __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
> -__arm_vaddq_m_n_s8 (int8x16_t __inactive, int8x16_t __a, int8_t __b,
> mve_pred16_t __p)
> +__arm_vaddq_m_n_s8 (int8x16_t __inactive, int8x16_t __a, int __b,
> mve_pred16_t __p)
>  {
>return __builtin_mve_vaddq_m_n_sv16qi (__inactive, __a, __b, __p);
>  }
> 
>  __extension__ extern __inline int32x4_t
>  __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
> -__arm_vaddq_m_n_s32 (int32x4_t __inactive, int32x4_t __a, int32_t __b,
> mve_pred16_t __p)
> +__arm_vaddq_m_n_s32 (int32x4_t __inactive, int32x4_t __a, int __b,
> mve_pred16_t __p)
>  {
>return __builtin_mve_vaddq_m_n_sv4si (__inactive, __a, __b, __p);
>  }
> 
>  __extension__ extern __inline int16x8_t
>  __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
> -__arm_vaddq_m_n_s16 (int16x8_t __inactive, int16x8_t __a, int16_t __b,
> mve_pred16_t __p)
> +__arm_vaddq_m_n_s16 (int16x8_t __inactive, int16x8_t __a, int __b,
> mve_pred16_t __p)
>  {
>return __builtin_mve_vaddq_m_n_sv8hi (__inactive, __a, __b, __p);
>  }
> 
>  __extension__ extern __inline uint8x16_t
>  __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
> -__arm_vaddq_m_n_u8 (uint8x16_t __inactive, uint8x16_t __a, uint8_t __b,
> mve_pred16_t __p)
> +__arm_vaddq_m_n_u8 (uint8x16_t __inactive, uint8x16_t __a, int __b,
> mve_pred16_t __p)
>  {
>return __builtin_mve_vaddq_m_n_uv16qi (__inactive, __a, __b, __p);
>  }
> 
>  __extension__ extern __inline uint32x4_t
>  __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
> -__arm_vaddq_m_n_u32 (uint32x4_t __inactive, uint32x4_t __a, uint32_t
> __b, mve_pred16_t __p)
> +__arm_vaddq_m_n_u32 (uint32x4_t __inactive, uint32x4_t __a, int __b,
> mve_pred16_t __p)
>  {
>return __builtin_mve_vaddq_m_n_uv4si (__inactive, __a, __b, __p);
>  }
> 
>  __extension__ extern __inline uint16x8_t
>  __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
> -__arm_vaddq_m_n_u16 (uint16x8_t __inactive, uint16x8_t __a, uint16_t
> __b, mve_pred16_t __p)
> +__arm_vaddq_m_n_u16 (uint16x8_t __inactive, uint16x8_t __a, int __b,
> mve_pred16_t __p)
>  {
>return __builtin_mve_vaddq_m_n_uv8hi (__inactive, __a, __b, __p);
>  }
> @@ -26493,42 +26493,42 @@ __arm_vabdq_m (uint16x8_t __inactive,
> uint16x8_t __a, uint16x8_t __b, mve_pred16
> 
>  __extension__ extern __inline int8x16_t
>  __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
> -__arm_vaddq_m (int8x16_t __inactive, int8x16_t __a, int8_t __b,
> mve_pred16_t __p)
> +__arm_vaddq_m (int8x16_t __inactive, int8x16_t __a, int __b,
> mve_pred16_t __p)
>  {
>   return __arm_vaddq_m_n_s8 (__inactive, __a, __b, __p);
>  }
> 
>  __extension__ extern __inline int32x4_t
>  __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
> -__arm_vaddq_m (int32x4_t __inactive, int32x4_t __a, int32_t __b,
> mve_pred16_t __p)
> +__arm_vaddq_m (int32x4_t __inactive, int32x4_t __a, int __b,
> mve_pred16_t __p)
>  {
>   return __arm_vaddq_m_n_s32 (__inactive, __a, __b, __p);
>  }
> 
>  __extension__ extern __inline int16x8_t
>  __attribute__ ((__always_inline__, __gnu_inline_

RE: [PATCH][GCC][Aarch64]: Fix for PR94880: Failure to recognize andn pattern

[Przemyslaw Wirkus]

On 12 June 2020 20:55 Andrew Pinski wrote:
> Subject: Re: [PATCH][GCC][Aarch64]: Fix for PR94880: Failure to recognize
> andn pattern
> 
> On Fri, Jun 12, 2020 at 7:50 AM Przemyslaw Wirkus
>  wrote:
> >
> > Hi all,
> >
> > Pattern "(x | y) - y" can be optimized to simple "(x & ~y)" andn pattern.
> 
> Isn't it better to do this transformation on the gimple level and not in a
> target specific form?  Or at least do it in the RTL level in a generic form 
> rather
> than adding target specific patterns.

Yes, I will rework this and add simplification pattern on the gimple level.

Cheers,
Przemyslaw Wirkus

> Thanks,
> Andrew Pinski
> 
> 
> >
> > So, for the example code:
> >
> > $ cat main.c
> > int
> > f_i(int x, int y)
> > {
> > return (x | y) - y;
> > }
> >
> > long long
> > f_l(long long x, long long y)
> > {
> > return (x | y) - y;
> > }
> >
> > typedef int v4si __attribute__ ((vector_size (16))); typedef long long
> > v2di __attribute__ ((vector_size (16)));
> >
> > v4si
> > f_v4si(v4si a, v4si b) {
> > return (a | b) - b;
> > }
> >
> > v2di
> > f_v2di(v2di a, v2di b) {
> > return (a | b) - b;
> > }
> >
> > void
> > f(v4si *d, v4si *a, v4si *b) {
> > for (int i=0; i > d[i] = (a[i] | b[i]) - b[i]; }
> >
> > Before this patch:
> > $ ./aarch64-none-linux-gnu-gcc -S -O2 main.c -dp
> >
> > f_i:
> > orr w0, w0, w1// 8[c=4 l=4]  iorsi3/0
> > sub w0, w0, w1// 14   [c=4 l=4]  subsi3
> > ret   // 24   [c=0 l=4]  *do_return
> > f_l:
> > orr x0, x0, x1// 8[c=4 l=4]  iordi3/0
> > sub x0, x0, x1// 14   [c=4 l=4]  subdi3/0
> > ret   // 24   [c=0 l=4]  *do_return
> > f_v4si:
> > orr v0.16b, v0.16b, v1.16b// 8[c=8 l=4]  
> > iorv4si3/0
> > sub v0.4s, v0.4s, v1.4s   // 14 [c=8 l=4]  subv4si3
> > ret   // 24   [c=0 l=4]  *do_return
> > f_v2di:
> > orr v0.16b, v0.16b, v1.16b// 8[c=8 l=4]  
> > iorv2di3/0
> > sub v0.2d, v0.2d, v1.2d   // 14 [c=8 l=4]  subv2di3
> > ret   // 24   [c=0 l=4]  *do_return
> >
> > After this patch:
> > $ ./aarch64-none-linux-gnu-gcc -S -O2 main.c -dp
> >
> > f_i:
> > bic w0, w0, w1  // 13   [c=8 l=4]  *bic_and_not_si3
> > ret // 23   [c=0 l=4]  *do_return
> > f_l:
> > bic x0, x0, x1  // 13   [c=8 l=4]  *bic_and_not_di3
> > ret // 23   [c=0 l=4]  *do_return
> > f_v4si:
> > bic v0.16b, v0.16b, v1.16b  // 13   [c=16 l=4]
> *bic_and_not_simd_v4si3
> > ret // 23   [c=0 l=4]  *do_return
> > f_v2di:
> > bic v0.16b, v0.16b, v1.16b  // 13   [c=16 l=4]
> *bic_and_not_simd_v2di3
> > ret // 23   [c=0 l=4]  *do_return
> >
> > Bootstrapped and tested on aarch64-none-linux-gnu.
> >
> > OK for master ?
> >
> > Cheers,
> > Przemyslaw
> >
> > gcc/ChangeLog:
> >
> > PR tree-optimization/94880
> > * config/aarch64/aarch64.md (bic_and_not_3): New
> define_insn.
> > * config/aarch64/aarch64-simd.md (bic_and_not_simd_3):
> New
> > define_insn.
> >
> > gcc/testsuite/ChangeLog:
> >
> > PR tree-optimization/94880
> > * gcc.target/aarch64/bic_and_not_di3.c: New test.
> > * gcc.target/aarch64/bic_and_not_si3.c: New test.
> > * gcc.target/aarch64/bic_and_not_v2di3.c: New test.
> > * gcc.target/aarch64/bic_and_not_v4si3.c: New test.

Re: [PATCH][v2] tree-optimization/94988 - enhance SM some more

[Richard Biener]

On Tue, 16 Jun 2020, Thomas Schwinge wrote:

> Hi!
> 
> On 2020-05-11T16:51:41+0200, Richard Biener  wrote:
> > This enhances store-order preserving store motion to handle the case
> > of non-invariant dependent stores in the sequence of unconditionally
> > executed stores on exit by re-issueing them as part of the sequence
> > of stores on the exit.  This fixes the observed regression of
> > gcc.target/i386/pr64110.c which relies on store-motion of 'b'
> > for a loop like
> >
> >   for (int i = 0; i < j; ++i)
> > *b++ = x;
> >
> > where for correctness we now no longer apply store-motion.  With
> > the patch we emit the correct
> >
> >   tem = b;
> >   for (int i = 0; i < j; ++i)
> > {
> >   tem = tem + 1;
> >   *tem = x;
> > }
> >   b = tem;
> >   *tem = x;
> >
> > preserving the original order of stores.  A testcase reflecting
> > the miscompilation done by earlier GCC is added as well.
> >
> > This also fixes the reported ICE in PR95025 and adds checking code
> > to catch it earlier - the issue was not-supported refs propagation
> > leaving stray refs in the sequence.
> >
> > Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
> 
> I noticed that since this commit b6ff3ddecfa93d53867afaaa078f85fc848abbbd
> "tree-optimization/94988 - enhance SM some more", for
> 'gcc.dg/graphite/pr80906.c' XPASSes what you recently had XFAILed in
> commit 283cb9ea6293e813e48a1b769e1e0779918ea20a "tree-optimization/57359
> - rewrite SM code".  I've thus pushed commit
> 2210ef7d3d68a027ec16476825049567953c7fa4 "Un-XFAIL
> 'gcc.dg/graphite/pr80906.c'", see attached.  I assume but have not
> verified that's the expected/correct thing vs. your commit introducing a
> bug.  ;-)

Ah, sorry - I also noticed this and wanted to update the test but
keep forgetting.  So thanks for doing it.  We're indeed again
doing the expected store motion thanks to the folloup enhancements.

Richard

> 
> Grüße
>  Thomas
> 
> 
> > 2020-05-11  Richard Biener  
> >
> >   PR tree-optimization/94988
> >   PR tree-optimization/95025
> >   * tree-ssa-loop-im.c (seq_entry): Make a struct, add from.
> >   (sm_seq_push_down): Take extra parameter denoting where we
> >   moved the ref to.
> >   (execute_sm_exit): Re-issue sm_other stores in the correct
> >   order.
> >   (sm_seq_valid_bb): When always executed, allow sm_other to
> >   prevail inbetween sm_ord and record their stored value.
> >   (hoist_memory_references): Adjust refs_not_supported propagation
> >   and prune sm_other from the end of the ordered sequences.
> >
> >   * gcc.dg/torture/pr94988.c: New testcase.
> >   * gcc.dg/torture/pr95025.c: Likewise.
> >   * gcc.dg/torture/pr95045.c: Likewise.
> >   * g++.dg/asan/pr95025.C: New testcase.
> > ---
> >  gcc/testsuite/g++.dg/asan/pr95025.C|  28 
> >  gcc/testsuite/gcc.dg/torture/pr94988.c |  20 +++
> >  gcc/testsuite/gcc.dg/torture/pr95025.c |  13 ++
> >  gcc/testsuite/gcc.dg/torture/pr95045.c |  29 
> >  gcc/tree-ssa-loop-im.c | 177 ++---
> >  5 files changed, 218 insertions(+), 49 deletions(-)
> >  create mode 100644 gcc/testsuite/g++.dg/asan/pr95025.C
> >  create mode 100644 gcc/testsuite/gcc.dg/torture/pr94988.c
> >  create mode 100644 gcc/testsuite/gcc.dg/torture/pr95025.c
> >  create mode 100644 gcc/testsuite/gcc.dg/torture/pr95045.c
> >
> > diff --git a/gcc/testsuite/g++.dg/asan/pr95025.C 
> > b/gcc/testsuite/g++.dg/asan/pr95025.C
> > new file mode 100644
> > index 000..dabb7e92f82
> > --- /dev/null
> > +++ b/gcc/testsuite/g++.dg/asan/pr95025.C
> > @@ -0,0 +1,28 @@
> > +// { dg-do compile }
> > +// { dg-options "-O2 -fsanitize=address" }
> > +
> > +struct a {
> > +int b;
> > +} * c;
> > +struct d {
> > +d *e;
> > +};
> > +struct f {
> > +bool done;
> > +d *g;
> > +};
> > +int h;
> > +int i(f *j) {
> > +if (j->g) {
> > + j->g = j->g->e;
> > + return h;
> > +}
> > +j->done = true;
> > +return 0;
> > +}
> > +void k(bool j) { c->b = j; }
> > +void l() {
> > +f a;
> > +for (; !(&a)->done; i(&a))
> > +  k(true);
> > +}
> > diff --git a/gcc/testsuite/gcc.dg/torture/pr94988.c 
> > b/gcc/testsuite/gcc.dg/torture/pr94988.c
> > new file mode 100644
> > index 000..1ee99fea5ce
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.dg/torture/pr94988.c
> > @@ -0,0 +1,20 @@
> > +/* { dg-do run } */
> > +
> > +short *b;
> > +
> > +void __attribute__((noipa))
> > +bar (short x, int j)
> > +{
> > +  for (int i = 0; i < j; ++i)
> > +*b++ = x;
> > +}
> > +
> > +int
> > +main()
> > +{
> > +  b = (short *)&b;
> > +  bar (0, 1);
> > +  if ((short)(__UINTPTR_TYPE__)b != 0)
> > +__builtin_abort ();
> > +  return 0;
> > +}
> > diff --git a/gcc/testsuite/gcc.dg/torture/pr95025.c 
> > b/gcc/testsuite/gcc.dg/torture/pr95025.c
> > new file mode 100644
> > index 000..5834dc04887
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.dg/torture/pr95025.c
> > @@ -0,0 +1

Re: [PATCH] middle-end/95690 - avoid MEM_EXPRs for constants

[Richard Biener]

On Tue, 16 Jun 2020, Richard Biener wrote:

> 
> [the following fixes fallout of the last change which introduced
> an assert - after this change we can likely trim down the set
> of tree codes we "ignore"]
> 
> The following avoids calling set_mem_attributes on the
> DECL_INITIAL of a CONST_DECL which seems pointless since there
> cannot be a sensible MEM_EXPR derived from that.  We're overwriting
> both other possibly useful info, alias-set and alignment immediately
> so the following patch simply removes the call instead of making
> the function deal with even more (unexpected) trees that are not
> memory accesses.
> 
> Bootstrap and regtest ongoing on x86_64-unknown-linux-gnu.

All went well and I pushed this to master.

Richard.

> Richard.
> 
> 2020-06-16  Richard Biener  
> 
>   PR middle-end/95690
>   * varasm.c (build_constant_desc): Remove set_mem_attributes call.
> 
>   * gfortran.dg/pr95690.f90: New testcase.
> ---
>  gcc/testsuite/gfortran.dg/pr95690.f90 | 9 +
>  gcc/varasm.c  | 1 -
>  2 files changed, 9 insertions(+), 1 deletion(-)
>  create mode 100644 gcc/testsuite/gfortran.dg/pr95690.f90
> 
> diff --git a/gcc/testsuite/gfortran.dg/pr95690.f90 
> b/gcc/testsuite/gfortran.dg/pr95690.f90
> new file mode 100644
> index 000..2da08912a4d
> --- /dev/null
> +++ b/gcc/testsuite/gfortran.dg/pr95690.f90
> @@ -0,0 +1,9 @@
> +! { dg-do compile }
> +module m
> +contains
> +   subroutine s
> +  print *, (erfc) ! { dg-error "not a floating constant" }
> +   end
> +   function erfc()
> +   end
> +end
> diff --git a/gcc/varasm.c b/gcc/varasm.c
> index f062e48071f..4070f9c17e8 100644
> --- a/gcc/varasm.c
> +++ b/gcc/varasm.c
> @@ -3399,7 +3399,6 @@ build_constant_desc (tree exp)
>TREE_CONSTANT_POOL_ADDRESS_P (symbol) = 1;
>  
>rtl = gen_const_mem (TYPE_MODE (TREE_TYPE (exp)), symbol);
> -  set_mem_attributes (rtl, exp, 1);
>set_mem_alias_set (rtl, 0);
>  
>/* Putting EXP into the literal pool might have imposed a different
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)

Re: [PATCH] ipa: special pass-through op for Fortran strides

[Martin Jambor]

Hi,

On Mon, Jun 15 2020, Jan Hubicka wrote:
>> On Fri, Jun 12, 2020 at 11:28 PM Martin Jambor  wrote:
>> >
>> > Hi,
>> >
>> > when Fortran functions pass array descriptors they receive as a
>> > parameter to another function, they actually rebuild it.  Thanks to
>> > work done mainly by Feng, IPA-CP can already handle the cases when
>> > they pass directly the values loaded from the original descriptor.
>> > Unfortunately, perhaps the most important one, stride, is first
>> > checked against zero and is replaced with one in that case:
>> >
>> >   _12 = *a_11(D).dim[0].stride;
>> >   if (_12 != 0)
>> > goto ; [50.00%]
>> >   else
>> > goto ; [50.00%]
>> >
>> >   
>> > // empty BB
>> >   
>> >   # iftmp.22_9 = PHI <_12(2), 1(3)>
>> >...
>> >parm.6.dim[0].stride = iftmp.22_9;
>> >...
>> >__x_MOD_foo (&parm.6, b_31(D));
>> >
>> > in the most important and hopefully common cases, the incoming value
>> > is already 1 and we fail to propagate it.
>> >
>> > I would therefore like to propose the following way of encoding this
>> > situation in pass-through jump functions using using ASSERTT_EXPR
>> > operation code meaning that if the incoming value is the same as the
>> > "operand" in the jump function, it is passed on, otherwise the result
>> > is unknown.  This of course captures only the single (but most
>> > important) case but is an improvement and does not need enlarging the
>> > jump function structure and is simple to pattern match.  Encoding that
>> > zero needs to be changed to one would need another field and matching
>> > it would be slightly more complicated too.
>> >
>> > Bootstrapped and tested on x86_64-linux, LTO bootstrap is underway.  OK
>> > if it passes?
>> 
>> Looks reasonable - I wonder if we somehow track enough info to
>> infer the _12 != 0 check in IPA propagation?  So whether there's the
>> possibility to not use "conditional 1" as I understand you do but
>> "conditional *a_11(D).dim[0].stride"?  Because AFAICS you
>> compare _12 against 1 in IPA propagation to enable the propagation,
>> why not compare it against 0?  Or even allow all cases to be resolved
>> if _12 is a constant?  That is, propagate a "_12 != 0 ? 12 : 1" jump
>> function which you should be able to resolve in the exact same
>> way via values_equal_for_ipa_cp_p?

It can of course be pattern matched.  Then I can invent another special
meaning for another _EXPR operation or perhaps start encoding these
special operations a bit more sanely.

>
> I was wondering, since we can now represent more complex arithmetic
> operations, if we can express param0 + (param0 != 0) using the jump
> function w/o use of assert exprs?

...I don't quite understand what you think has changed recently, we
still can only represent one arithmetic operation in pass-through jump
functions.  They still have one tree_code for the operation and one tree
for the second operand of the operation, but into that one tree I can
put something like

  (cond-expr (error_node != 0 ) error-node 1)

or anything arbitrarily complex, and when evaluating it, make a copy,
replace all error_nodes with the constant and attempt to fold it.  But
probably you meant something else?

>
> In general assert exprs seems like good concept to represent conditional
> jumps though.

OK then, I'll try to extend the matcher to also take the condition into
account (for simple situation like these) and use the assert expr only
when it fails.

Thanks,

Martin

>> >
>> >
>> > 2020-06-12  Martin Jambor  
>> >
>> > * ipa-prop.h (ipa_pass_through_data): Expand comment describing
>> > operation.
>> > * ipa-prop.c (analyze_agg_content_value): Detect new special case 
>> > and
>> > encode it as ASSERT_EXPR.
>> > * ipa-cp.c (values_equal_for_ipcp_p): Move before
>> > ipa_get_jf_arith_result.
>> > (ipa_get_jf_arith_result): Special case ASSERT_EXPR.
>> >
>> > testsuite/
>> > * gfortran.dg/ipcp-array-2.f90: New test.

Re: [PATCH] Defined libcall_arg_t

[Richard Sandiford]

Kamlesh Kumar  writes:
> thanks Richard,
>
> addressed your concern.
>
> diff --git a/gcc/rtl.h b/gcc/rtl.h
> index 0872cc4..7206c8a 100644
> --- a/gcc/rtl.h
> +++ b/gcc/rtl.h
> @@ -2238,6 +2238,16 @@ struct address_info {
>     enum rtx_code base_outer_code;
>   };
>
> +/* This is used for passing args in emit_library_* functions */
> +struct libcall_arg {
> +  rtx value;
> +  machine_mode mode;
> +  bool unsigned_p;
> +  constexpr
> +  libcall_arg (rtx v, machine_mode m, bool u) : value(v), mode(m),
> +    unsigned_p(u) {}

Think this should be formatted with the ":" on the next line.
There should also be spaces before each "(":

  constexpr libcall_arg (rtx v, machine_mode m, bool u)
: value (v), mode (m), unsigned_p (u) {}

Looks good otherwise, thanks, but please only apply at the same
time as the patch that needs it.

Richard

Re: [stage1][PATCH] Change semantics of -frecord-gcc-switches and add -frecord-gcc-switches-format.

[Martin Liška]

PING^3

On 6/2/20 11:16 AM, Martin Liška wrote:

PING^2

On 5/15/20 11:58 AM, Martin Liška wrote:

We're in stage1: PING^1

On 4/3/20 8:15 PM, Egeyar Bagcioglu wrote:



On 3/18/20 10:05 AM, Martin Liška wrote:

On 3/17/20 7:43 PM, Egeyar Bagcioglu wrote:

Hi Martin,

I like the patch. It definitely serves our purposes at Oracle and provides 
another way to do what my previous patches did as well.

1) It keeps the backwards compatibility regarding -frecord-gcc-switches; 
therefore, removes my related doubts about your previous patch.

2) It still makes use of -frecord-gcc-switches. The new option is only to 
control the format. This addresses some previous objections to having a new 
option doing something similar. Now the new option controls the behaviour of 
the existing one and that behaviour can be further extended.

3) It uses an environment variable as Jakub suggested.

The patch looks good and I confirm that it works for our purposes.


Hello.

Thank you for the support.



Having said that, I have to ask for recognition in this patch for my and my 
company's contributions. Can you please keep my name and my work email in the 
changelog and in the commit message?


Sure, sorry I forgot.


Hi Martin,

I noticed that some comments in the patch were still referring to 
--record-gcc-command-line, the option I suggested earlier. I updated those 
comments to mention -frecord-gcc-switches-format instead and also added my name 
to the patch as you agreed above. I attached the updated patch. We are starting 
to use this patch in the specific domain where we need its functionality.

Regards
Egeyar




Martin



Thanks
Egeyar



On 3/17/20 2:53 PM, Martin Liška wrote:

Hi.

I'm sending enhanced patch that makes the following changes:
- a new option -frecord-gcc-switches-format is added; the option
  selects format (processed, driver) for all options that record
  GCC command line
- Dwarf gen_produce_string is now used in -fverbose-asm
- The .s file is affected in the following way:

BEFORE:

# GNU C17 (SUSE Linux) version 9.2.1 20200128 [revision 
83f65674e78d97d27537361de1a9d74067ff228d] (x86_64-suse-linux)
#    compiled by GNU C version 9.2.1 20200128 [revision 
83f65674e78d97d27537361de1a9d74067ff228d], GMP version 6.2.0, MPFR version 
4.0.2, MPC version 1.1.0, isl version isl-0.22.1-GMP

# GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
# options passed:  -fpreprocessed test.i -march=znver1 -mmmx -mno-3dnow
# -msse -msse2 -msse3 -mssse3 -msse4a -mcx16 -msahf -mmovbe -maes -msha
# -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mno-sgx
# -mbmi2 -mno-pconfig -mno-wbnoinvd -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1
# -mlzcnt -mno-rtm -mno-hle -mrdrnd -mf16c -mfsgsbase -mrdseed -mprfchw
# -madx -mfxsr -mxsave -mxsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd
# -mno-avx512pf -mno-prefetchwt1 -mclflushopt -mxsavec -mxsaves
# -mno-avx512dq -mno-avx512bw -mno-avx512vl -mno-avx512ifma -mno-avx512vbmi
# -mno-avx5124fmaps -mno-avx5124vnniw -mno-clwb -mmwaitx -mclzero -mno-pku
# -mno-rdpid -mno-gfni -mno-shstk -mno-avx512vbmi2 -mno-avx512vnni
# -mno-vaes -mno-vpclmulqdq -mno-avx512bitalg -mno-movdiri -mno-movdir64b
# -mno-waitpkg -mno-cldemote -mno-ptwrite --param l1-cache-size=32
# --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=znver1
# -grecord-gcc-switches -g -fverbose-asm -frecord-gcc-switches
# options enabled:  -faggressive-loop-optimizations -fassume-phsa
# -fasynchronous-unwind-tables -fauto-inc-dec -fcommon
# -fdelete-null-pointer-checks -fdwarf2-cfi-asm -fearly-inlining
# -feliminate-unused-debug-types -ffp-int-builtin-inexact -ffunction-cse
# -fgcse-lm -fgnu-runtime -fgnu-unique -fident -finline-atomics
# -fipa-stack-alignment -fira-hoist-pressure -fira-share-save-slots
# -fira-share-spill-slots -fivopts -fkeep-static-consts
# -fleading-underscore -flifetime-dse -flto-odr-type-merging -fmath-errno
# -fmerge-debug-strings -fpeephole -fplt -fprefetch-loop-arrays
# -frecord-gcc-switches -freg-struct-return -fsched-critical-path-heuristic
# -fsched-dep-count-heuristic -fsched-group-heuristic -fsched-interblock
# -fsched-last-insn-heuristic -fsched-rank-heuristic -fsched-spec
# -fsched-spec-insn-heuristic -fsched-stalled-insns-dep -fschedule-fusion
# -fsemantic-interposition -fshow-column -fshrink-wrap-separate
# -fsigned-zeros -fsplit-ivs-in-unroller -fssa-backprop -fstdarg-opt
# -fstrict-volatile-bitfields -fsync-libcalls -ftrapping-math -ftree-cselim
# -ftree-forwprop -ftree-loop-if-convert -ftree-loop-im -ftree-loop-ivcanon
# -ftree-loop-optimize -ftree-parallelize-loops= -ftree-phiprop
# -ftree-reassoc -ftree-scev-cprop -funit-at-a-time -funwind-tables
# -fverbose-asm -fzero-initialized-in-bss -m128bit-long-double -m64 -m80387
# -mabm -madx -maes -malign-stringops -mavx -mavx2
# -mavx256-split-unaligned-store -mbmi -mbmi2 -mclflushopt -mclzero -mcx16
# -mf16c -mfancy-math-387 -mfma -mfp-ret-in-387 -mfsgsbase -mfxsr -mglibc
# -mieee-fp -mlong-double

[PATCH] gcov: fix gcov-tool merge for TOPN counters

[Martin Liška]

Hello.

The patch is about corrupted gcov-tool merge command for a TOPN counter.
What was missing is transition of a on-disk representation to a memory
representation expected by __gcov_merge_topn function.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
I'm going to install it if there are no objections.

Martin

libgcc/ChangeLog:

* libgcov-util.c (read_gcda_finalize): Remove const operator.
(merge_wrapper): Add both counts and use them properly.
(topn_to_memory_representation): New function.
(gcov_merge): Covert on disk representation to in memory
representation.
* libgcov.h: Remove const operator.
---
 libgcc/libgcov-util.c | 70 ---
 libgcc/libgcov.h  |  2 +-
 2 files changed, 61 insertions(+), 11 deletions(-)

diff --git a/libgcc/libgcov-util.c b/libgcc/libgcov-util.c
index fff54c6a3f6..224c190ee63 100644
--- a/libgcc/libgcov-util.c
+++ b/libgcc/libgcov-util.c
@@ -243,7 +243,7 @@ read_gcda_finalize (struct gcov_info *obj_info)
   /* We set the following fields: merge, n_functions, functions
  and summary.  */
   obj_info->n_functions = num_fn_info;
-  obj_info->functions = (const struct gcov_fn_info**) obstack_finish 
(&fn_info);
+  obj_info->functions = (struct gcov_fn_info**) obstack_finish (&fn_info);
 
   /* wrap all the counter array.  */

   for (i=0; i< GCOV_COUNTERS; i++)
@@ -506,14 +506,58 @@ gcov_get_merge_weight (void)
value buffer and weights and then calls the merge function.  */
 
 static void

-merge_wrapper (gcov_merge_fn f, gcov_type *v1, gcov_unsigned_t n,
-   gcov_type *v2, unsigned w)
+merge_wrapper (gcov_merge_fn f, gcov_type *v1, gcov_unsigned_t n1,
+  gcov_type *v2, gcov_unsigned_t n2, unsigned w)
 {
   gcov_value_buf = v2;
   gcov_value_buf_pos = 0;
-  gcov_value_buf_size = n;
+  gcov_value_buf_size = n2;
   gcov_merge_weight = w;
-  (*f) (v1, n);
+  (*f) (v1, n1);
+}
+
+/* Convert on disk representation of a TOPN counter to in memory representation
+   that is expected from __gcov_merge_topn function.  */
+
+static void
+topn_to_memory_representation (struct gcov_ctr_info *info)
+{
+  auto_vec output;
+  gcov_type *values = info->values;
+  int count = info->num;
+
+  while (count > 0)
+{
+  output.safe_push (values[0]);
+  gcov_type n = values[1];
+  output.safe_push (n);
+  if (n > 0)
+   {
+ struct gcov_kvp *tuples
+   = (struct gcov_kvp *)xcalloc (sizeof (struct gcov_kvp), n);
+ for (unsigned i = 0; i < n - 1; i++)
+   tuples[i].next = &tuples[i + 1];
+ for (unsigned i = 0; i < n; i++)
+   {
+ tuples[i].value = values[2 + 2 * i];
+ tuples[i].count = values[2 + 2 * i + 1];
+   }
+ output.safe_push ((intptr_t)&tuples[0]);
+   }
+  else
+   output.safe_push (0);
+
+  unsigned len = 2 * n + 2;
+  values += len;
+  count -= len;
+}
+  gcc_assert (count == 0);
+
+  /* Allocate new buffer and copy it there.  */
+  info->num = output.length ();
+  info->values = (gcov_type *)xmalloc (sizeof (gcov_type) * info->num);
+  for (unsigned i = 0; i < info->num; i++)
+info->values[i] = output[i];
 }
 
 /* Offline tool to manipulate profile data.

@@ -543,9 +587,9 @@ gcov_merge (struct gcov_info *info1, struct gcov_info 
*info2, int w)
   for (f_ix = 0; f_ix < n_functions; f_ix++)
 {
   unsigned t_ix;
-  const struct gcov_fn_info *gfi_ptr1 = info1->functions[f_ix];
-  const struct gcov_fn_info *gfi_ptr2 = info2->functions[f_ix];
-  const struct gcov_ctr_info *ci_ptr1, *ci_ptr2;
+  struct gcov_fn_info *gfi_ptr1 = info1->functions[f_ix];
+  struct gcov_fn_info *gfi_ptr2 = info2->functions[f_ix];
+  struct gcov_ctr_info *ci_ptr1, *ci_ptr2;
 
   if (!gfi_ptr1 || gfi_ptr1->key != info1)

 continue;
@@ -569,8 +613,14 @@ gcov_merge (struct gcov_info *info1, struct gcov_info 
*info2, int w)
   gcc_assert (merge1 == merge2);
   if (!merge1)
 continue;
-  gcc_assert (ci_ptr1->num == ci_ptr2->num);
-  merge_wrapper (merge1, ci_ptr1->values, ci_ptr1->num, 
ci_ptr2->values, w);
+
+ if (merge1 == __gcov_merge_topn)
+   topn_to_memory_representation (ci_ptr1);
+ else
+   gcc_assert (ci_ptr1->num == ci_ptr2->num);
+
+ merge_wrapper (merge1, ci_ptr1->values, ci_ptr1->num,
+ci_ptr2->values, ci_ptr2->num, w);
   ci_ptr1++;
   ci_ptr2++;
 }
diff --git a/libgcc/libgcov.h b/libgcc/libgcov.h
index 5d237a4c730..ffa9a690af4 100644
--- a/libgcc/libgcov.h
+++ b/libgcc/libgcov.h
@@ -216,7 +216,7 @@ struct gcov_info
   const struct gcov_fn_info *const *functions; /* pointer to pointers
   to function information  */
 #else
-  const struct gcov_fn_info **functions;
+  struct gcov_fn_info **functions;
 #endif /* 

RE: [PATCH PR95199 v2] vect: CSE for bump and offset in strided load/store operations

[zhoukaipeng (A)]

Bootstrapped and tested on aarch64-linux-gnu & x86_64-linux-gnu.  Could you 
please help install this patch?

Kaipeng Zhou

> -Original Message-
> From: Richard Biener [mailto:rguent...@suse.de]
> Sent: Tuesday, June 16, 2020 5:49 PM
> To: zhoukaipeng (A) 
> Cc: Richard Sandiford ; gcc-
> patc...@gcc.gnu.org; am...@gcc.gnu.org; rgue...@gcc.gnu.org
> Subject: Re: [PATCH PR95199 v2] vect: CSE for bump and offset in strided
> load/store operations
> 
> On Tue, 16 Jun 2020, zhoukaipeng (A) wrote:
> 
> > Hi,
> >
> > I try to eliminate the common stmts for *vec_offset also.  But I am
> > not sure it is a good way.
> >
> > New patch attached.  Bootstraped and testsuites are being tested.
> 
> Looks good to me and certainly worth if it makes a difference for IV
> calculation (that was the main motivation of the machinery).
> 
> Richard.
> 
> > Kaipeng Zhou
> >
> > > -Original Message-
> > > From: Richard Biener [mailto:rguent...@suse.de]
> > > Sent: Monday, June 15, 2020 2:21 PM
> > > To: zhoukaipeng (A) 
> > > Cc: Richard Sandiford ; gcc-
> > > patc...@gcc.gnu.org; am...@gcc.gnu.org; rgue...@gcc.gnu.org
> > > Subject: RE: [PATCH PR95199] vect: Remove extra variable created for
> > > memory reference
> > >
> > > On Sun, 14 Jun 2020, zhoukaipeng (A) wrote:
> > >
> > > > Hi,
> > > >
> > > > I modified the issue you mentioned.  Bootstrap and tested on
> > > > aarch64
> > > Linux platform again.  No new regression witnessed.
> > > >
> > > > For "*vec_offset", it is indeed a point optimizable.  However, it
> > > > is not able to eliminate it by the same way as "*dataref_bump".
> > > > The cse_and_gimplify_to_preheader will return the cached operand
> > > > if operand_compare::operand_equal_p for the cached one and the
> new
> > > > one returns true.  But it did not work well for "*vec_offset".
> > >
> > > You have to see what is actually in *vec_offset, if there's partly
> > > gimplified but not CSEd stmts in there then that's the issue.
> > >
> > > Richard.
> > >
> > > > Do you have any suggestions for the problem?
> > > >
> > > > Thanks,
> > > > Kaipeng Zhou
> > > >
> > > > > -Original Message-
> > > > > From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> > > > > Sent: Friday, June 12, 2020 3:48 PM
> > > > > To: zhoukaipeng (A) 
> > > > > Cc: gcc-patches@gcc.gnu.org; rguent...@suse.de;
> > > > > am...@gcc.gnu.org; rgue...@gcc.gnu.org
> > > > > Subject: Re: [PATCH PR95199] vect: Remove extra variable created
> > > > > for memory reference
> > > > >
> > > > > "zhoukaipeng (A)"  writes:
> > > > > > Hi,
> > > > > >
> > > > > > This is a fix for pr95199.
> > > > > > In vectorization, vinfo->ivexpr_map is supposed to catch those
> > > > > > "IV base
> > > > > and/or step expressions".  Just call
> > > > > cse_and_gimplify_to_preheader to handle gathering/scattering to
> avoid the extra variable.
> > > > > >
> > > > > > Bootstrap and tested on aarch64/x86_64 Linux platform. No new
> > > > > regression witnessed.
> > > > > >
> > > > > > Is it ok?
> > > > > >
> > > > > > Thanks,
> > > > > > Kaipeng Zhou
> > > > > >
> > > > > > From 12cf9b362576735e4c584c48cd6db3d2b0f2e14b Mon Sep 17
> > > 00:00:00
> > > > > 2001
> > > > > > From: Kaipeng Zhou 
> > > > > > Date: Fri, 12 Jun 2020 00:54:15 +0800
> > > > > > Subject: [PATCH] vect: Remove extra variable created for
> > > > > > memory reference in  loop vectorization.
> > > > > >
> > > > > > Vectorization create two copies of the same IV and IVOPTs does
> > > > > > not perform CSE.  But vinfo->ivexpr_map is supposed to catch
> > > > > > those "IV base and/or step expressions".  Just call
> > > > > > cse_and_gimplify_to_preheader to handle gathering/scattering
> > > > > > to avoid
> > > > > the extra variable.
> > > > > >
> > > > > > 2020-06-12  Bin Cheng 
> > > > > > Kaipeng Zhou  
> > > > > >
> > > > > > PR tree-optimization/95199
> > > > > > * tree-vect-stmts.c: Use CSE map to catch the IV step and
> eliminate
> > > > > > extra variable.
> > > > > >
> > > > > > 2020-06-12  Bin Cheng 
> > > > > > Kaipeng Zhou  
> > > > > >
> > > > > > PR tree-optimization/95199
> > > > > > * gcc.dg/vect/pr95199.c: New test.
> > > > > > ---
> > > > > >  gcc/ChangeLog   |  7 +++
> > > > > >  gcc/testsuite/ChangeLog |  6 ++
> > > > > >  gcc/testsuite/gcc.dg/vect/pr95199.c | 17 +
> > > > > >  gcc/tree-vect-stmts.c   |  1 +
> > > > > >  4 files changed, 31 insertions(+)  create mode 100644
> > > > > > gcc/testsuite/gcc.dg/vect/pr95199.c
> > > > > >
> > > > > > diff --git a/gcc/ChangeLog b/gcc/ChangeLog index
> > > > > > c92582df7fe..753d70fc94b 100644
> > > > > > --- a/gcc/ChangeLog
> > > > > > +++ b/gcc/ChangeLog
> > > > > > @@ -1,3 +1,10 @@
> > > > > > +2020-06-12  Bin Cheng 
> > > > > > +   Kaipeng Zhou  
> > > > > > +
> > > > > > +   PR tree-optimization/95199
> > > > > > +   * tree-vect-stmts.c: Use CSE map to catch the IV step and
> eliminate
> > > > > > +  

Re: [PATCH] c++: zero_init_expr_p of dependent expression

[Patrick Palka via Gcc-patches]

On Thu, Apr 23, 2020 at 5:17 PM Jason Merrill  wrote:
>
> On 4/23/20 4:09 PM, Patrick Palka wrote:
> > This fixes a ICE coming from mangle.c:write_expression when compiling the
> > ranges-v3 testsuite; the added testcase is a reduced reproducer of the ICE.
> >
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, and also tested on the
> > cmcstl2, fmt and range-v3 libraries.  Does this look OK to commit?
>
> OK.

Is it OK to backport the same patch to the 9 branch in order to resolve PR95678?

>
> > gcc/cp/ChangeLog:> >
> >   * tree.c (zero_init_expr_p): Use uses_template_parms instead of
> >   dependent_type_p.
> >
> > gcc/testsuite/ChangeLog:
> >
> >   * g++.dg/cpp0x/dependent3.C: New test.
> > ---
> >   gcc/cp/tree.c   |  2 +-
> >   gcc/testsuite/g++.dg/cpp0x/dependent3.C | 28 +
> >   2 files changed, 29 insertions(+), 1 deletion(-)
> >   create mode 100644 gcc/testsuite/g++.dg/cpp0x/dependent3.C
> >
> > diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
> > index 090c565c093..8840932dba2 100644
> > --- a/gcc/cp/tree.c
> > +++ b/gcc/cp/tree.c
> > @@ -4486,7 +4486,7 @@ bool
> >   zero_init_expr_p (tree t)
> >   {
> > tree type = TREE_TYPE (t);
> > -  if (!type || dependent_type_p (type))
> > +  if (!type || uses_template_parms (type))
> >   return false;
> > if (zero_init_p (type))
> >   return initializer_zerop (t);
> > diff --git a/gcc/testsuite/g++.dg/cpp0x/dependent3.C 
> > b/gcc/testsuite/g++.dg/cpp0x/dependent3.C
> > new file mode 100644
> > index 000..caf7e1cd4a4
> > --- /dev/null
> > +++ b/gcc/testsuite/g++.dg/cpp0x/dependent3.C
> > @@ -0,0 +1,28 @@
> > +// { dg-do compile { target c++11 } }
> > +
> > +template
> > +struct d
> > +{
> > +  using e = c;
> > +};
> > +
> > +template
> > +struct g
> > +{
> > +  using h = typename d::e;
> > +
> > +  template
> > +  auto operator()(i, j k) -> decltype(h{k});
> > +};
> > +
> > +template
> > +void m()
> > +{
> > +  int a[1];
> > +  l{}(a, a);
> > +}
> > +
> > +int main()
> > +{
> > +  m>();
> > +}
> >
>

[Ada] Fix small fallout of freezing change for expression functions

[Pierre-Marie de Rodat]

The previous change implemented the rule in Freeze_Expression that
expression functions that are not completions are not freeze points.
However, for code generation purposes, the artificial entities that
are created during the expansion of the expressions must still be
frozen inside the body created for the functions.  Now the existing
mechanism aimed at ensuring this had a loophole for entities created
in nested blocks, which is plugged by the change.

The change also removes some unreachable code in In_Expanded_Body.

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

2020-06-16  Eric Botcazou  

gcc/ada/

* freeze.adb (In_Expanded_Body): Remove unreachable code.
(Freeze_Expression): Rename a couple of local variables.
In the case of an expanded body, also freeze locally the
entities declared in a nested block.--- gcc/ada/freeze.adb
+++ gcc/ada/freeze.adb
@@ -7114,22 +7114,15 @@ package body Freeze is
   --
 
   function In_Expanded_Body (N : Node_Id) return Boolean is
- P  : Node_Id;
+ P  : constant Node_Id := Parent (N);
  Id : Entity_Id;
 
   begin
- if Nkind (N) = N_Subprogram_Body then
-P := N;
- else
-P := Parent (N);
- end if;
-
  if Nkind (P) /= N_Subprogram_Body then
 return False;
 
- --  AI12-0152 : an expression function that is a completion
- --  is a freeze point. If the body is the result of expansion
- --  it is not.
+ --  AI12-0157: An expression function that is a completion is a freeze
+ --  point. If the body is the result of expansion, it is not.
 
  elsif Was_Expression_Function (P) then
 return not Comes_From_Source (P);
@@ -7146,9 +7139,8 @@ package body Freeze is
  or else Is_TSS (Id, TSS_Stream_Output)
  or else Is_TSS (Id, TSS_Stream_Read)
  or else Is_TSS (Id, TSS_Stream_Write)
- or else Nkind_In (Original_Node (P),
-   N_Subprogram_Renaming_Declaration,
-   N_Expression_Function))
+ or else Nkind (Original_Node (P)) =
+ N_Subprogram_Renaming_Declaration)
 then
return True;
 else
@@ -7518,45 +7510,61 @@ package body Freeze is
 
   if In_Expanded_Body (Parent_P) then
  declare
-Subp : constant Node_Id := Parent (Parent_P);
-Spec : Entity_Id;
+Subp_Body : constant Node_Id := Parent (Parent_P);
+Spec_Id   : Entity_Id;
 
  begin
 --  Freeze the entity only when it is declared inside
---  the body of the expander generated procedure.
---  This case is recognized by the scope of the entity
---  or its type, which is either the spec for some
---  enclosing body, or (in the case of init_procs,
---  for which there are no separate specs) the current
---  scope.
-
-if Nkind (Subp) = N_Subprogram_Body then
-   Spec := Corresponding_Spec (Subp);
-
-   if (Present (Typ) and then Scope (Typ) = Spec)
-or else
-  (Present (Nam) and then Scope (Nam) = Spec)
-   then
-  exit;
+--  the body of the expander generated procedure. This
+--  case is recognized by the subprogram scope of the
+--  entity or its type, which is either the spec of an
+--  enclosing body, or (in the case of init_procs for
+--  which there is no separate spec) the current scope.
+
+if Nkind (Subp_Body) = N_Subprogram_Body then
+   declare
+  S : Entity_Id;
+
+   begin
+  Spec_Id := Corresponding_Spec (Subp_Body);
+
+  if Present (Typ) then
+ S := Scope (Typ);
+  elsif Present (Nam) then
+ S := Scope (Nam);
+  else
+ S := Standard_Standard;
+  end if;
 
-   elsif Present (Typ)
- and then Scope (Typ) = Current_Scope
- and then Defining_Entity (Subp) = Current_Scope
-   then
- 

[Ada] Fix spurious error on implicit dereference for private type

[Pierre-Marie de Rodat]

This is a fallout of the earlier work on the handling of Ada 95
implicit dereferences.  The dereferences are now made explicit
only at the final stage of type resolution and this slightly
changes the way they are analyzed during semantic analysis.

In particular, in the case of an implicit dereference of a component
inherited in a tagged extension from a private parent and used as
actual type in an instance, Analyze_Selected_Component has specific
code to recognize this situation after the interpretation as prefixed
call has failed.

This tentative interpretation is done by Try_Object_Operation and
it turns out that the procedure may be partially destructive for the
parent of the analyzed node in the case where it is a subprogram call
or an indexed component.

This change makes sure that the partial damage is undone on failure.

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

2020-06-16  Eric Botcazou  

gcc/ada/

* sem_ch4.adb (Transform_Object_Operation): Document that it
may be partially destructive for the parent of the node.
(Try_Object_Operation): Undo the changes made above on failure.--- gcc/ada/sem_ch4.adb
+++ gcc/ada/sem_ch4.adb
@@ -8460,7 +8460,9 @@ package body Sem_Ch4 is
   --  Transform Obj.Operation (X, Y, ...) into Operation (Obj, X, Y ...).
   --  Call_Node is the resulting subprogram call, Node_To_Replace is
   --  either N or the parent of N, and Subprog is a reference to the
-  --  subprogram we are trying to match.
+  --  subprogram we are trying to match. Note that the transformation
+  --  may be partially destructive for the parent of N, so it needs to
+  --  be undone in the case where Try_Object_Operation returns false.
 
   function Try_Class_Wide_Operation
 (Call_Node   : Node_Id;
@@ -8731,7 +8733,7 @@ package body Sem_Ch4 is
 --  example:
 --Some_Subprogram (..., Obj.Operation, ...)
 
-and then Name (Parent_Node) = N
+and then N = Name (Parent_Node)
  then
 Node_To_Replace := Parent_Node;
 
@@ -9769,8 +9771,20 @@ package body Sem_Ch4 is
  return True;
 
   else
- --  There was no candidate operation, so report it as an error
- --  in the caller: Analyze_Selected_Component.
+ --  There was no candidate operation, but Analyze_Selected_Component
+ --  may continue the analysis so we need to undo the change possibly
+ --  made to the Parent of N earlier by Transform_Object_Operation.
+
+ declare
+Parent_Node : constant Node_Id := Parent (N);
+
+ begin
+if Node_To_Replace = Parent_Node then
+   Remove (First (Parameter_Associations (New_Call_Node)));
+   Set_Parent
+ (Parameter_Associations (New_Call_Node), Parent_Node);
+end if;
+ end;
 
  return False;
   end if;

[Ada] Spurious undefined symbol with nested call to expression function

[Pierre-Marie de Rodat]

The compiler creates a link failure involving an expression function
that is not a completion when the expression of the expression function
includes a call to a function F declared in on outer scope of the same
package declaration, becausw the compiler places the freeze node for F
in the generated body of the expression function.

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

2020-06-16  Ed Schonberg  

gcc/ada/

* freeze.adb: (Freeze_Expression, In_Expanded_Body): Treat the
generated body of an expression function like other bodies
generated during expansion (e.g. stream subprograms) so that
those bodies are not treated as freezing points. Handle properly
other global references in such completions.--- gcc/ada/freeze.adb
+++ gcc/ada/freeze.adb
@@ -7071,8 +7071,9 @@ package body Freeze is
   function In_Expanded_Body (N : Node_Id) return Boolean;
   --  Given an N_Handled_Sequence_Of_Statements node N, determines whether
   --  it is the handled statement sequence of an expander-generated
-  --  subprogram (init proc, stream subprogram, or renaming as body).
-  --  If so, this is not a freezing context.
+  --  subprogram: init proc, stream subprogram, renaming as body, or body
+  --  created for an expression function. If so, this is not a freezing
+  --  context and the entity will be frozen at a later point.
 
   -
   -- Find_Aggregate_Component_Desig_Type --
@@ -7126,6 +7127,13 @@ package body Freeze is
  if Nkind (P) /= N_Subprogram_Body then
 return False;
 
+ --  AI12-0152 : an expression function that is a completion
+ --  is a freeze point. If the body is the result of expansion
+ --  it is not.
+
+ elsif Was_Expression_Function (P) then
+return not Comes_From_Source (P);
+
  else
 Id := Defining_Unit_Name (Specification (P));
 
@@ -7539,28 +7547,16 @@ package body Freeze is
end if;
 end if;
 
---  An expression function may act as a completion of
---  a function declaration. As such, it can reference
---  entities declared between the two views:
-
--- Hidden []; -- 1
--- function F return ...;
--- private
---function Hidden return ...;
---function F return ... is (Hidden);  -- 2
-
---  Refering to the example above, freezing the
---  expression of F (2) would place Hidden's freeze
---  node (1) in the wrong place. Avoid explicit
---  freezing and let the usual scenarios do the job
---  (for example, reaching the end of the private
---  declarations, or a call to F.)
+--  If the entity is not frozen by an expression
+--  function that is a completion, continue climing
+--  the tree.
 
-if Nkind (Original_Node (Subp)) = N_Expression_Function
+if Nkind (Subp) = N_Subprogram_Body
+  and then Was_Expression_Function (Subp)
 then
null;
 
---  Freeze outside the body
+   --  Freeze outside the body
 
 else
Parent_P := Parent (Parent_P);

[Ada] Check if attribute Passed_By_Reference is called on incomplete types

[Pierre-Marie de Rodat]

Problem: When Passed_By_Reference is used on an incomplete type (e.g.
`type T; B : Boolean := T'Passed_By_Reference;`) GNAT crashes in Gigi
because it doesn't know the size of T.  Solution: Reject programs that
use Passed_By_Reference on incomplete types, just like what is currently
done for the Alignment attribute.

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

2020-06-16  Ghjuvan Lacambre  

gcc/ada/

* sem_attr.adb (Analyze_Attribute): Add
Check_Not_Incomplete_Type call.--- gcc/ada/sem_attr.adb
+++ gcc/ada/sem_attr.adb
@@ -5202,6 +5202,7 @@ package body Sem_Attr is
   when Attribute_Passed_By_Reference =>
  Check_E0;
  Check_Type;
+ Check_Not_Incomplete_Type;
  Set_Etype (N, Standard_Boolean);
 
   --

[Ada] Implement AI12-0351 Matching for actuals for formal derived types

[Pierre-Marie de Rodat]

This implements the AI in all versions of the language, since it is a
binding interpretation.  The AI extends the 12.5.1(8) subclause: "For
a generic formal derived type with no discriminant_part, the actual
subtype shall be statically compatible with the ancestor subtype"
from constained types to unconstrained types.

It turns out that this extension was already implemented in GNAT and
constrained and unconstrained types were already treated alike here.
So the change only tweaks the error message to mention the ancestor.

However, in Ada 2012 the "statically compatible" property comprises
a condition on the predicates present on the subtypes which was not
implemented yet so this change implements it, with a limitation for
static subtypes that are not discrete.

A duplicate error handling pattern is also factored out in Sem_Ch3.

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

2020-06-16  Eric Botcazou  

gcc/ada/

* sem_ch12.adb (Validate_Derived_Type_Instance): Reword error
message for 12.5.1(8) subclause and add secondary message if
the incompatibility comes from the predicates.
* sem_ch3.adb (Check_Constraining_Discriminant): New procedure
to give the error required by the 3.7(15) subclause.  Mention
"statically" in the error message and add secondary message
if the incompatibility comes from the predicates.
(Build_Derived_Concurrent_Type): Call it when a new discriminant
constrains an old one.
(Build_Derived_Record_Type): Likewise.
* sem_eval.ads (Predicates_Compatible): Declare.
* sem_eval.adb (Predicates_Compatible): New function to implement
the compatibility of predicates specified by the 4.9.1 clause.
(Subtypes_Statically_Compatible): Call it.--- gcc/ada/sem_ch12.adb
+++ gcc/ada/sem_ch12.adb
@@ -13321,8 +13321,16 @@ package body Sem_Ch12 is
 if not Subtypes_Statically_Compatible
  (Act_T, Ancestor, Formal_Derived_Matching => True)
 then
-   Error_Msg_N
- ("constraint on actual is incompatible with formal", Actual);
+   Error_Msg_NE
+ ("actual for & must be statically compatible with ancestor",
+  Actual, Gen_T);
+
+   if not Predicates_Compatible (Act_T, Ancestor) then
+  Error_Msg_N
+("\predicate on actual is not compatible with ancestor",
+ Actual);
+   end if;
+
Abandon_Instantiation (Actual);
 end if;
  end if;

--- gcc/ada/sem_ch3.adb
+++ gcc/ada/sem_ch3.adb
@@ -254,6 +254,11 @@ package body Sem_Ch3 is
--  circularity issues in Gigi. We create an incomplete type for the record
--  declaration, which is the designated type of the anonymous access.
 
+   procedure Check_Constraining_Discriminant (New_Disc, Old_Disc : Entity_Id);
+   --  Check that, if a new discriminant is used in a constraint defining the
+   --  parent subtype of a derivation, its subtype is statically compatible
+   --  with the subtype of the corresponding parent discriminant (RM 3.7(15)).
+
procedure Check_Delta_Expression (E : Node_Id);
--  Check that the expression represented by E is suitable for use as a
--  delta expression, i.e. it is of real type and is static.
@@ -6906,14 +6911,13 @@ package body Sem_Ch3 is
   Error_Msg_NE
 ("new discriminant& must constrain old one", N, New_Disc);
 
-   elsif not
- Subtypes_Statically_Compatible
-   (Etype (New_Disc),
-Etype (Corresponding_Discriminant (New_Disc)))
-   then
-  Error_Msg_NE
-("& not statically compatible with parent discriminant",
-  N, New_Disc);
+   --  If a new discriminant is used in the constraint, then its
+   --  subtype must be statically compatible with the subtype of
+   --  the parent discriminant (RM 3.7(15)).
+
+   else
+  Check_Constraining_Discriminant
+(New_Disc, Corresponding_Discriminant (New_Disc));
end if;
 
Next_Discriminant (New_Disc);
@@ -9087,41 +9091,13 @@ package body Sem_Ch3 is
end if;
 
--  If a new discriminant is used in the constraint, then its
-   --  subtype must be statically compatible with the parent
-   --  discriminant's subtype (3.7(15)).
-
-   --  However, if the record contains an array constrained by
-   --  the discriminant but with some different bound, the compiler
-   --  tries to create a smaller range for the discriminant type.
-   --  (See exp_ch3.Adjust_Discriminants). In this case, where
-   --  the discriminant type is a scalar type, the check must use
-   

[Ada] Accept renamings of folded string aggregates

[Pierre-Marie de Rodat]

Routine Is_Object_Reference, which implements Ada RM 3.3(2) that says
"All of the following are objects: ..." was slightly diverging from the
exact wording of that rule and from the exact wording of AI05-0003,
which allows qualified expressions to be used as objects (provided that
their expression itself is an object).

This patch fixes this routine to precisely follow both the wording of
Ada RM 3.3(2), i.e. it recognizes aggregates as objects (as introduced
in Ada 95) and it literally implements the rule about qualified
expression (as introduced in Ada 2012).

Finally, it recognizes string literals that come from folded aggregates
as objects.

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

2020-06-16  Piotr Trojanek  

gcc/ada/

* sem_ch8.adb (Analyze_Object_Renaming): Remove trivially
useless initialization of Is_Object_Reference.
* sem_util.adb (Is_Object_Reference): Simplify detection of
binary and unary operators; literally implement rules about
aggregates and qualified expressions; recognize string literals
as object references.--- gcc/ada/sem_ch8.adb
+++ gcc/ada/sem_ch8.adb
@@ -754,7 +754,7 @@ package body Sem_Ch8 is
   Id: constant Entity_Id  := Defining_Identifier (N);
   Loc   : constant Source_Ptr := Sloc (N);
   Nam   : constant Node_Id:= Name (N);
-  Is_Object_Ref : Boolean := False;
+  Is_Object_Ref : Boolean;
   Dec   : Node_Id;
   T : Entity_Id;
   T2: Entity_Id;
@@ -1366,7 +1366,7 @@ package body Sem_Ch8 is
   if T = Any_Type or else Etype (Nam) = Any_Type then
  return;
 
-  --  Verify that the renamed entity is an object or function call.
+  --  Verify that the renamed entity is an object or function call
 
   elsif Is_Object_Ref then
  if Comes_From_Source (N) then

--- gcc/ada/sem_util.adb
+++ gcc/ada/sem_util.adb
@@ -16978,9 +16978,8 @@ package body Sem_Util is
 --  Note that predefined operators are functions as well, and so
 --  are attributes that are (can be renamed as) functions.
 
-when N_Binary_Op
-   | N_Function_Call
-   | N_Unary_Op
+when N_Function_Call
+   | N_Op
 =>
return Etype (N) /= Standard_Void_Type;
 
@@ -17040,12 +17039,21 @@ package body Sem_Util is
 --  of aggregates in more contexts.
 
 when N_Qualified_Expression =>
-   if Ada_Version <  Ada_2012 then
-  return False;
-   else
-  return Is_Object_Reference (Expression (N))
-or else Nkind (Expression (N)) = N_Aggregate;
-   end if;
+   return Ada_Version >= Ada_2012
+ and then Is_Object_Reference (Expression (N));
+
+--  In Ada 95 an aggreate is an object reference
+
+when N_Aggregate =>
+   return Ada_Version >= Ada_95;
+
+--  A string literal is not an object reference, but it might come
+--  from rewriting of an object reference, e.g. from folding of an
+--  aggregate.
+
+when N_String_Literal =>
+   return Is_Rewrite_Substitution (N)
+ and then Is_Object_Reference (Original_Node (N));
 
 when others =>
return False;

[Ada] Force evaluation of qualified aggregates

[Pierre-Marie de Rodat]

This patch fixes regressions in GNATprove, after a previous patch
changed routine Is_Object_Reference to literally implement the Ada RM
and recognize aggregates as objects.

Now routine Evaluate_Name also literally implements the Ada RM rules
about name evaluation; in particular, it restores forced evaluation of
aggregates (which are now recognized as objects).

There appears to be no impact on compilation.

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

2020-06-16  Piotr Trojanek  

gcc/ada/

* exp_util.adb (Evaluate_Name): Force evaluation of aggregates;
recursively evaluate expression of a qualified expression; fix
location of the comment for an attribute referenced and an
indexed component.--- gcc/ada/exp_util.adb
+++ gcc/ada/exp_util.adb
@@ -4918,11 +4918,16 @@ package body Exp_Util is
 
procedure Evaluate_Name (Nam : Node_Id) is
begin
-  --  For an attribute reference or an indexed component, evaluate the
-  --  prefix, which is itself a name, recursively, and then force the
-  --  evaluation of all the subscripts (or attribute expressions).
-
   case Nkind (Nam) is
+ --  For an aggregate, force its evaluation
+
+ when N_Aggregate =>
+Force_Evaluation (Nam);
+
+ --  For an attribute reference or an indexed component, evaluate the
+ --  prefix, which is itself a name, recursively, and then force the
+ --  evaluation of all the subscripts (or attribute expressions).
+
  when N_Attribute_Reference
 | N_Indexed_Component
  =>
@@ -4960,16 +4965,10 @@ package body Exp_Util is
  =>
 Force_Evaluation (Nam);
 
- --  For a qualified expression, we evaluate the underlying object
- --  name if any, otherwise we force the evaluation of the underlying
- --  expression.
+ --  For a qualified expression, we evaluate the expression
 
  when N_Qualified_Expression =>
-if Is_Object_Reference (Expression (Nam)) then
-   Evaluate_Name (Expression (Nam));
-else
-   Force_Evaluation (Expression (Nam));
-end if;
+Evaluate_Name (Expression (Nam));
 
  --  For a selected component, we simply evaluate the prefix
 

[Ada] ACATS 4.1K - B452001 - No errors detected

[Pierre-Marie de Rodat]

This is a test against RM 4.5.2(4.1/4), the rule that ensures that
equality is visible for a membership involving objects. GNAT wasn't
handling this case properly because during the rewrite of membership
tests, the legality rules were bypassed as the rewrite was no longer
treated as if it came from the source code.

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

2020-06-16  Arnaud Charlet  

gcc/ada/

* sem_ch4.adb (Analyze_Membership_Op): Reset entity of equality
nodes for membership tests with singletons.
(Analyze_User_Defined_Binary_Op): Always perform the analysis
since nodes coming from the expander also may refer to non
standard operators as part of membership expansion.
* exp_ch4.adb (Expand_Set_Membership.Make_Cond): Reset entity of
equality node.
* sem_type.ads: Fix typo in comment.--- gcc/ada/exp_ch4.adb
+++ gcc/ada/exp_ch4.adb
@@ -12716,6 +12716,11 @@ package body Exp_Ch4 is
   Make_Op_Eq (Sloc (Alt),
 Left_Opnd  => L,
 Right_Opnd => R);
+
+--  We reset the Entity since we do not want to bypass the operator
+--  resolution.
+
+Set_Entity (Cond, Empty);
  end if;
 
  return Cond;

--- gcc/ada/sem_ch4.adb
+++ gcc/ada/sem_ch4.adb
@@ -2965,6 +2965,8 @@ package body Sem_Ch4 is
  end if;
   end Analyze_Set_Membership;
 
+  Op : Node_Id;
+
--  Start of processing for Analyze_Membership_Op
 
begin
@@ -3011,17 +3013,16 @@ package body Sem_Ch4 is
and then Has_Compatible_Type (R, Etype (L))
  then
 if Nkind (N) = N_In then
-   Rewrite (N,
- Make_Op_Eq (Loc,
-   Left_Opnd  => L,
-   Right_Opnd => R));
+   Op := Make_Op_Eq (Loc, Left_Opnd  => L, Right_Opnd => R);
 else
-   Rewrite (N,
- Make_Op_Ne (Loc,
-   Left_Opnd  => L,
-   Right_Opnd => R));
+   Op := Make_Op_Ne (Loc, Left_Opnd  => L, Right_Opnd => R);
 end if;
 
+--  We reset the Entity since we do not want to bypass the operator
+--  resolution.
+
+Set_Entity (Op, Empty);
+Rewrite (N, Op);
 Analyze (N);
 return;
 
@@ -5595,54 +5596,47 @@ package body Sem_Ch4 is
 
procedure Analyze_User_Defined_Binary_Op
  (N : Node_Id;
-  Op_Id : Entity_Id)
-   is
+  Op_Id : Entity_Id) is
begin
-  --  Only do analysis if the operator Comes_From_Source, since otherwise
-  --  the operator was generated by the expander, and all such operators
-  --  always refer to the operators in package Standard.
-
-  if Comes_From_Source (N) then
- declare
-F1 : constant Entity_Id := First_Formal (Op_Id);
-F2 : constant Entity_Id := Next_Formal (F1);
-
- begin
---  Verify that Op_Id is a visible binary function. Note that since
---  we know Op_Id is overloaded, potentially use visible means use
---  visible for sure (RM 9.4(11)).
+  declare
+ F1 : constant Entity_Id := First_Formal (Op_Id);
+ F2 : constant Entity_Id := Next_Formal (F1);
 
-if Ekind (Op_Id) = E_Function
-  and then Present (F2)
-  and then (Is_Immediately_Visible (Op_Id)
- or else Is_Potentially_Use_Visible (Op_Id))
-  and then Has_Compatible_Type (Left_Opnd (N), Etype (F1))
-  and then Has_Compatible_Type (Right_Opnd (N), Etype (F2))
-then
-   Add_One_Interp (N, Op_Id, Etype (Op_Id));
+  begin
+ --  Verify that Op_Id is a visible binary function. Note that since
+ --  we know Op_Id is overloaded, potentially use visible means use
+ --  visible for sure (RM 9.4(11)).
+
+ if Ekind (Op_Id) = E_Function
+   and then Present (F2)
+   and then (Is_Immediately_Visible (Op_Id)
+  or else Is_Potentially_Use_Visible (Op_Id))
+   and then Has_Compatible_Type (Left_Opnd (N), Etype (F1))
+   and then Has_Compatible_Type (Right_Opnd (N), Etype (F2))
+ then
+Add_One_Interp (N, Op_Id, Etype (Op_Id));
 
-   --  If the left operand is overloaded, indicate that the current
-   --  type is a viable candidate. This is redundant in most cases,
-   --  but for equality and comparison operators where the context
-   --  does not impose a type on the operands, setting the proper
-   --  type is necessary to avoid subsequent ambiguities during
-   --  resolution, when both user-defined and predefined operators
-   --  may be candidates.
+--  If the left operand is overloaded, indicate that the current
+--  type is a viable candidate. This 

[Ada] ACATS 4.1P - C432003 - Errors missed on extension aggregates

[Pierre-Marie de Rodat]

This ACATS test show that GNAT was not implementing AI05-0115 properly,
now fixed by checking the relevant parent type.

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

2020-06-16  Arnaud Charlet  

gcc/ada/

* sem_aggr.adb (Resolve_Extension_Aggregate): Fix implementation
of AI05-0115 by checking the correct type.--- gcc/ada/sem_aggr.adb
+++ gcc/ada/sem_aggr.adb
@@ -3084,14 +3084,12 @@ package body Sem_Aggr is
   Analyze (A);
   Check_Parameterless_Call (A);
 
-  --  In SPARK, the ancestor part cannot be a type mark
-
   if Is_Entity_Name (A) and then Is_Type (Entity (A)) then
 
  --  AI05-0115: if the ancestor part is a subtype mark, the ancestor
  --  must not have unknown discriminants.
 
- if Has_Unknown_Discriminants (Root_Type (Typ)) then
+ if Has_Unknown_Discriminants (Entity (A)) then
 Error_Msg_NE
   ("aggregate not available for type& whose ancestor "
  & "has unknown discriminants", N, Typ);
@@ -4291,6 +4289,10 @@ package body Sem_Aggr is
 
  --  AI05-0115: if the ancestor part is a subtype mark, the ancestor
  --  must not have unknown discriminants.
+ --  ??? We are not checking any subtype mark here and this code is not
+ --  exercised by any test, so it's likely wrong (in particular
+ --  we should not use Root_Type here but the subtype mark, if any),
+ --  and possibly not needed.
 
  if Is_Derived_Type (Typ)
and then Has_Unknown_Discriminants (Root_Type (Typ))

[Ada] Force evaluation of operator calls in renamings

[Pierre-Marie de Rodat]

When renaming a qualified expression with an operator, e.g.:

   Y : Boolean renames Boolean'(not X);

routine Evaluate_Name should handle operators just like it handles
function calls. This doesn't appear to matter for GNAT (where this
routine is called in very few cases, as described in the comment for
Evaluation_Required), but is critical for GNATprove (where the lack of a
forced evaluation triggers might cause a soundness bug).

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

2020-06-16  Piotr Trojanek  

gcc/ada/

* exp_util.adb (Evaluate_Name): Force evaluation of operators.--- gcc/ada/exp_util.adb
+++ gcc/ada/exp_util.adb
@@ -4953,9 +4953,11 @@ package body Exp_Util is
  when N_Explicit_Dereference =>
 Force_Evaluation (Prefix (Nam));
 
- --  For a function call, we evaluate the call
+ --  For a function call, we evaluate the call; same for an operator
 
- when N_Function_Call =>
+ when N_Function_Call
+| N_Op
+ =>
 Force_Evaluation (Nam);
 
  --  For a qualified expression, we evaluate the underlying object
@@ -4989,9 +4991,11 @@ package body Exp_Util is
  when N_Type_Conversion =>
 Evaluate_Name (Expression (Nam));
 
- --  The remaining cases are direct name, operator symbol and character
- --  literal. In all these cases, we do nothing, since we want to
- --  reevaluate each time the renamed object is used.
+ --  The remaining cases are direct name and character literal. In all
+ --  these cases, we do nothing, since we want to reevaluate each time
+ --  the renamed object is used. ??? There are more remaining cases, at
+ --  least in the GNATprove_Mode, where this routine is called in more
+ --  contexts than in GNAT.
 
  when others =>
 null;

[Ada] Fix assertion failure on qualified type names in predicates

[Pierre-Marie de Rodat]

An assertion is code for static membership tests was failing on this
code:

   subtype A is Integer with
 predicate => A > 0;

   subtype B is Integer with
 predicate => B in P.A;

where a qualified type name "P.A" appears in the predicate of type B.
The fix is trivial and the problem didn't affect production builds.

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

2020-06-16  Piotr Trojanek  

gcc/ada/

* sem_ch13.adb (Membership_Entry): Relax assertion to also
recognize qualified identifiers.--- gcc/ada/sem_ch13.adb
+++ gcc/ada/sem_ch13.adb
@@ -8566,7 +8566,7 @@ package body Sem_Ch13 is
 
  --  Identifier (other than static expression) case
 
- else pragma Assert (Nkind (N) = N_Identifier);
+ else pragma Assert (Nkind_In (N, N_Expanded_Name, N_Identifier));
 
 --  Type case
 

[Ada] ACATS 4.1P - BC55001 - Error missed

[Pierre-Marie de Rodat]

This ACATS test shows that we are not checking legality of functions
returning interfaces that need to be abstract.

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

2020-06-16  Arnaud Charlet  

gcc/ada/

* sem_ch6.adb (Analyze_Subprogram_Specification): Generate error
message for functions returning interfaces.--- gcc/ada/sem_ch6.adb
+++ gcc/ada/sem_ch6.adb
@@ -5464,9 +5464,7 @@ package body Sem_Ch6 is
   N_Formal_Abstract_Subprogram_Declaration,
   N_Subprogram_Renaming_Declaration)
  then
-if Is_Abstract_Type (Etype (Designator))
-  and then not Is_Interface (Etype (Designator))
-then
+if Is_Abstract_Type (Etype (Designator)) then
Error_Msg_N
  ("function that returns abstract type must be abstract", N);
 

[Ada] ACATS C452005/C452006 memberships use wrong equality operation

[Pierre-Marie de Rodat]

ACATS tests C452005 and C452006 show that GNAT is using the wrong
equality operation for non record/non limited types as defined in RM
4.5.2 (28.1/4).

This is actually a follow up/complement of the previous change for
ACATS B452001 against RM 4.5.2(4.1/4).

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

2020-06-16  Arnaud Charlet  

gcc/ada/

* sem_aux.ads, sem_aux.adb (Is_Record_Or_Limited_Type): New
function.
* exp_ch4.adb, sem_ch4.adb (Analyze_Membership_Op,
Expand_Set_Membership.Make_Cond): Choose between primitive and
predefined equality for membership tests.--- gcc/ada/exp_ch4.adb
+++ gcc/ada/exp_ch4.adb
@@ -12717,10 +12717,13 @@ package body Exp_Ch4 is
 Left_Opnd  => L,
 Right_Opnd => R);
 
---  We reset the Entity since we do not want to bypass the operator
---  resolution.
+if Is_Record_Or_Limited_Type (Etype (Alt)) then
 
-Set_Entity (Cond, Empty);
+   --  We reset the Entity in order to use the primitive equality
+   --  of the type, as per RM 4.5.2 (28.1/4).
+
+   Set_Entity (Cond, Empty);
+end if;
  end if;
 
  return Cond;

--- gcc/ada/sem_aux.adb
+++ gcc/ada/sem_aux.adb
@@ -1330,6 +1330,15 @@ package body Sem_Aux is
N_Protected_Definition);
end Is_Protected_Operation;
 
+   ---
+   -- Is_Record_Or_Limited_Type --
+   ---
+
+   function Is_Record_Or_Limited_Type (Typ : Entity_Id) return Boolean is
+   begin
+  return Is_Record_Type (Typ) or else Is_Limited_Type (Typ);
+   end Is_Record_Or_Limited_Type;
+
--
-- Nearest_Ancestor --
--

--- gcc/ada/sem_aux.ads
+++ gcc/ada/sem_aux.ads
@@ -362,6 +362,9 @@ package Sem_Aux is
--  Given a subprogram or entry, determines whether E is a protected entry
--  or subprogram.
 
+   function Is_Record_Or_Limited_Type (Typ : Entity_Id) return Boolean;
+   --  Return True if Typ requires is a record or limited type.
+
function Nearest_Ancestor (Typ : Entity_Id) return Entity_Id;
--  Given a subtype Typ, this function finds out the nearest ancestor from
--  which constraints and predicates are inherited. There is no simple link

--- gcc/ada/sem_ch4.adb
+++ gcc/ada/sem_ch4.adb
@@ -3018,10 +3018,14 @@ package body Sem_Ch4 is
Op := Make_Op_Ne (Loc, Left_Opnd  => L, Right_Opnd => R);
 end if;
 
---  We reset the Entity since we do not want to bypass the operator
---  resolution.
+if Is_Record_Or_Limited_Type (Etype (L)) then
+
+   --  We reset the Entity in order to use the primitive equality
+   --  of the type, as per RM 4.5.2 (28.1/4).
+
+   Set_Entity (Op, Empty);
+end if;
 
-Set_Entity (Op, Empty);
 Rewrite (N, Op);
 Analyze (N);
 return;

[Ada] Fix premature freezing of artificial array subtype

[Pierre-Marie de Rodat]

This prevents the compiler from placing the freeze node of an array
subtype, generated for the expression of an if-expression whose type
is an array type declared with a predicate, ahead of this expression
and, in particular, before its declaration.

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

2020-06-16  Eric Botcazou  

gcc/ada/

* freeze.adb (Freeze_Expression): Stop climbing the parent chain
at a N_{Case,If}_Expression node for a type or an entity that
does not come from source.--- gcc/ada/freeze.adb
+++ gcc/ada/freeze.adb
@@ -7630,15 +7630,18 @@ package body Freeze is
  exit;
   end if;
 
-   --  Note: N_Loop_Statement is a special case. A type that
-   --  appears in the source can never be frozen in a loop (this
-   --  occurs only because of a loop expanded by the expander), so
-   --  we keep on going. Otherwise we terminate the search. Same
-   --  is true of any entity which comes from source. (if they
-   --  have predefined type, that type does not appear to come
-   --  from source, but the entity should not be frozen here).
-
-   when N_Loop_Statement =>
+   --  N_Loop_Statement is a special case: a type that appears in
+   --  the source can never be frozen in a loop (this occurs only
+   --  because of a loop expanded by the expander), so we keep on
+   --  going. Otherwise we terminate the search. Same is true of
+   --  any entity which comes from source (if it has a predefined
+   --  type, this type does not appear to come from source, but the
+   --  entity should not be frozen here). The reasoning can also be
+   --  applied to if-expressions and case-expressions.
+
+   when N_Loop_Statement
+  | N_If_Expression
+  | N_Case_Expression =>
   exit when not Comes_From_Source (Etype (N))
 and then (No (Nam) or else not Comes_From_Source (Nam));
 

[Ada] Enable literal aspect specifications in Big_Numbers specs

[Pierre-Marie de Rodat]

Specify the Integer_Literal aspect for the type
Ada.Numerics.Big_Numbers.Big_Integers.Big_Integer.  Specify the
Real_Literal aspect for the type
Ada.Numerics.Big_Numbers.Big_Reals.Big_Real.

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

2020-06-16  Steve Baird  

gcc/ada/

* libgnat/a-nbnbin.ads, libgnat/a-nbnbre.ads: Uncomment the
commented-out Integer_Literal aspect specification for type
Big_Integer.--- gcc/ada/libgnat/a-nbnbin.ads
+++ gcc/ada/libgnat/a-nbnbin.ads
@@ -27,8 +27,8 @@ package Ada.Numerics.Big_Numbers.Big_Integers
   with Preelaborate
 is
type Big_Integer is private with
-   --  Integer_Literal => From_String,
- Put_Image => Put_Image;
+ Integer_Literal => From_String,
+ Put_Image   => Put_Image;
 
function Is_Valid (Arg : Big_Integer) return Boolean
  with Convention => Intrinsic;

--- gcc/ada/libgnat/a-nbnbre.ads
+++ gcc/ada/libgnat/a-nbnbre.ads
@@ -26,7 +26,7 @@ package Ada.Numerics.Big_Numbers.Big_Reals
   with Preelaborate
 is
type Big_Real is private with
---Real_Literal => From_String,
+ Real_Literal => From_String,
  Put_Image=> Put_Image;
 
function Is_Valid (Arg : Big_Real) return Boolean

[Ada] Implement AI12-0216 on restricting overlap errors in calls

[Pierre-Marie de Rodat]

This patch implements A12-0216, which clarifies RM 6.4.1 (6.16-17/3)
concerning illegal overlappings between actuals in a call. The previous
illegality rule applied to a call in which two writable actuals, one
of them having an elementary type, are known to overlap. The new rule
states that illegality only occurs when both actuals are elementary
types (i.e. are identical) because of the non-deterministic order in
which the actuals are rewritten upon return. Other overlaps are not
illegal, but GNAT does emit a warning on them if proper warnings
are enabled.

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

2020-06-16  Ed Schonberg  

gcc/ada/

* sem_warn.adb (Warn_On_Overlapping_Actuals): Simplify code and
implement AI12-0216 which clarifies the conditions under which
overlapping actuals in a call are illegal. If proper warnings
are enabled, GNAT also emits warnings in legal cases of
overlopping actuals.--- gcc/ada/sem_warn.adb
+++ gcc/ada/sem_warn.adb
@@ -3674,9 +3674,6 @@ package body Sem_Warn is
   Act2  : Node_Id;
   Form1 : Entity_Id;
   Form2 : Entity_Id;
-  Warn_Only : Boolean;
-  --  GNAT warns on overlapping in-out parameters of any type, not just for
-  --  elementary in-out parameters (as specified in RM 6.4.1 (15/3-17/3)).
 
--  Start of processing for Warn_On_Overlapping_Actuals
 
@@ -3686,29 +3683,6 @@ package body Sem_Warn is
  return;
   end if;
 
-  --  The call is illegal only if there are at least two in-out parameters
-  --  of the same elementary type.
-
-  Warn_Only := True;
-  Form1 := First_Formal (Subp);
-  Set_Warn_Only : while Present (Form1) loop
- Form2 := Next_Formal (Form1);
- while Present (Form2) loop
-if Is_Elementary_Type (Etype (Form1))
-  and then Is_Elementary_Type (Etype (Form2))
-  and then Ekind (Form1) /= E_In_Parameter
-  and then Ekind (Form2) /= E_In_Parameter
-then
-   Warn_Only := False;
-   exit Set_Warn_Only;
-end if;
-
-Next_Formal (Form2);
- end loop;
-
- Next_Formal (Form1);
-  end loop Set_Warn_Only;
-
   --  Exclude calls rewritten as enumeration literals
 
   if Nkind (N) not in N_Subprogram_Call
@@ -3722,9 +3696,16 @@ package body Sem_Warn is
   --  N that is passed as a parameter of mode in out or out to the call C,
   --  there is no other name among the other parameters of mode in out or
   --  out to C that is known to denote the same object (RM 6.4.1(6.15/3))
+  --  This has been clarified in AI12-0216 to indicate that the illegality
+  --  only occurs if both formals are of an elementary type, bevause of the
+  --  non-determinism on the write-back of the corresponding actuals.
+  --  Earlier versions of the language made it illegal if only one of the
+  --  actuals was an elementary parameter that overlapped a composite
+  --  actual, and both were writable.
 
   --  If appropriate warning switch is set, we also report warnings on
-  --  overlapping parameters that are record types or array types.
+  --  overlapping parameters that are composite types. Users find these
+  --  warnings useful, and they used in style guides.
 
   --  It is also worthwhile to warn on overlaps of composite objects when
   --  only one of the formals is (in)-out. Note that the RM rule above is
@@ -3836,14 +3817,16 @@ package body Sem_Warn is
   --  Overlap is only illegal in Ada 2012 in the case
   --  of elementary types (passed by copy). For other
   --  types we always have a warning in all versions.
+  --  This is clarified by AI12-0216.
 
-  or else not Is_Elementary_Type (Etype (Form1))
+  or else not
+   (Is_Elementary_Type (Etype (Form1))
+and then Is_Elementary_Type (Etype (Form2)))
 
   --  debug flag -gnatd.E changes the error to a
   --  warning even in Ada 2012 mode.
 
-  or else Error_To_Warning
-  or else Warn_Only;
+  or else Error_To_Warning;
 
 if Is_Elementary_Type (Etype (Act1))
   and then Ekind (Form2) = E_In_Parameter

[Ada] Crash in tagged type constructor with task components

[Pierre-Marie de Rodat]

This patch fixes the regressions introduced in CodePeer (caused by
missing support for thunks) and enforces checks on BIP formals in the
frontend to avoid mismatch when their values are passed as actuals of
BIP calls.

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

2020-06-16  Javier Miranda  

gcc/ada/

* exp_ch6.adb (BIP_Suffix_Kind, Check_BIP_Actuals,
Is_Build_In_Place_Entity): New subprograms.
(Make_Build_In_Place_Call_In_Allocator,
Make_Build_In_Place_Call_In_Anonymous_Context,
Make_Build_In_Place_Call_In_Assignment,
Make_Build_In_Place_Call_In_Object_Declaration): Add assertions.
(Needs_BIP_Task_Actuals): Add missing support for thunks.
(Expand_Actuals): Ensure that the BIP call has available an
activation chain and the _master variable.
* exp_ch9.adb (Find_Enclosing_Context): Initialize the list of
declarations of empty blocks when the _master variable must be
declared and the list was not available.--- gcc/ada/exp_ch6.adb
+++ gcc/ada/exp_ch6.adb
@@ -78,6 +78,15 @@ with Validsw;   use Validsw;
 
 package body Exp_Ch6 is
 
+   --  Suffix for BIP formals
+
+   BIP_Alloc_Suffix   : constant String := "BIPalloc";
+   BIP_Storage_Pool_Suffix: constant String := "BIPstoragepool";
+   BIP_Finalization_Master_Suffix : constant String := "BIPfinalizationmaster";
+   BIP_Task_Master_Suffix : constant String := "BIPtaskmaster";
+   BIP_Activation_Chain_Suffix: constant String := "BIPactivationchain";
+   BIP_Object_Access_Suffix   : constant String := "BIPaccess";
+
---
-- Local Subprograms --
---
@@ -147,6 +156,9 @@ package body Exp_Ch6 is
--  level is known not to be statically deeper than the result type of the
--  function.
 
+   function BIP_Suffix_Kind (E : Entity_Id) return BIP_Formal_Kind;
+   --  Ada 2005 (AI-318-02): Returns the kind of the given extra formal.
+
function Caller_Known_Size
  (Func_Call   : Node_Id;
   Result_Subt : Entity_Id) return Boolean;
@@ -156,6 +168,12 @@ package body Exp_Ch6 is
--  access discriminants do not require secondary stack use. Note we must
--  always use the secondary stack for dispatching-on-result calls.
 
+   function Check_BIP_Actuals
+ (Subp_Call : Node_Id;
+  Subp_Id   : Entity_Id) return Boolean;
+   --  Given a subprogram call to the given subprogram return True if the
+   --  names of BIP extra actual and formal parameters match.
+
function Check_Number_Of_Actuals
  (Subp_Call : Node_Id;
   Subp_Id   : Entity_Id) return Boolean;
@@ -258,6 +276,9 @@ package body Exp_Ch6 is
--  Insert the Post_Call list previously produced by routine Expand_Actuals
--  or Expand_Call_Helper into the tree.
 
+   function Is_Build_In_Place_Entity (E : Entity_Id) return Boolean;
+   --  Ada 2005 (AI-318-02): Returns True if E is a BIP entity.
+
procedure Replace_Renaming_Declaration_Id
   (New_Decl  : Node_Id;
Orig_Decl : Node_Id);
@@ -737,25 +758,68 @@ package body Exp_Ch6 is
begin
   case Kind is
  when BIP_Alloc_Form =>
-return "BIPalloc";
+return BIP_Alloc_Suffix;
 
  when BIP_Storage_Pool =>
-return "BIPstoragepool";
+return BIP_Storage_Pool_Suffix;
 
  when BIP_Finalization_Master =>
-return "BIPfinalizationmaster";
+return BIP_Finalization_Master_Suffix;
 
  when BIP_Task_Master =>
-return "BIPtaskmaster";
+return BIP_Task_Master_Suffix;
 
  when BIP_Activation_Chain =>
-return "BIPactivationchain";
+return BIP_Activation_Chain_Suffix;
 
  when BIP_Object_Access =>
-return "BIPaccess";
+return BIP_Object_Access_Suffix;
   end case;
end BIP_Formal_Suffix;
 
+   -
+   -- BIP_Suffix_Kind --
+   -
+
+   function BIP_Suffix_Kind (E : Entity_Id) return BIP_Formal_Kind is
+  Nam : constant String := Get_Name_String (Chars (E));
+
+  function Has_Suffix (Suffix : String) return Boolean;
+  --  Return True if Nam has suffix Suffix
+
+  function Has_Suffix (Suffix : String) return Boolean is
+ Len : constant Natural := Suffix'Length;
+  begin
+ return Nam'Length > Len
+   and then Nam (Nam'Last - Len + 1 .. Nam'Last) = Suffix;
+  end Has_Suffix;
+
+   --  Start of processing for BIP_Suffix_Kind
+
+   begin
+  if Has_Suffix (BIP_Alloc_Suffix) then
+ return BIP_Alloc_Form;
+
+  elsif Has_Suffix (BIP_Storage_Pool_Suffix) then
+ return BIP_Storage_Pool;
+
+  elsif Has_Suffix (BIP_Finalization_Master_Suffix) then
+ return BIP_Finalization_Master;
+
+  elsif Has_Suffix (BIP_Task_Master_Suffix) then
+ return BIP_Task_Master;
+
+  elsif Has_Suffix (BIP_Activation_Chain_Suffix) then
+ r

[Ada] Crash in tagged type constructor with task components

[Pierre-Marie de Rodat]

This patch removes part of the patch added to process the run-time
package system.ads; it is not needed because we now rely on
Targparm.Restrictions_On_Target.

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

2020-06-16  Javier Miranda  

gcc/ada/

* sem_prag.adb (Process_Restrictions_Or_Restriction_Warnings):
Code cleanup.--- gcc/ada/sem_prag.adb
+++ gcc/ada/sem_prag.adb
@@ -10694,54 +10694,11 @@ package body Sem_Prag is
  Add_To_Config_Boolean_Restrictions (No_Elaboration_Code);
   end if;
 
-   --  Special processing for No_Tasking restriction
+   --  Special processing for No_Tasking restriction placed in
+   --  a configuration pragmas file.
 
-   elsif R_Id = No_Tasking then
-
-  --  Handle global configuration pragmas
-
-  if No (Cunit (Main_Unit)) then
- Set_Global_No_Tasking;
-
-  --  Handle package System, which may be loaded by rtsfind as
-  --  a consequence of loading some other run-time unit.
-
-  else
- declare
-C_Node : constant Entity_Id :=
-   Cunit (Current_Sem_Unit);
-C_Ent  : constant Entity_Id :=
-   Cunit_Entity (Current_Sem_Unit);
-Loc_Str : constant String :=
-Build_Location_String (Sloc (C_Ent));
-Ref_Str : constant String := "system.ads";
-Ref_Len : constant Positive := Ref_Str'Length;
-
- begin
-pragma Assert (Loc_Str'First = 1);
-pragma Assert (Loc_Str'First = Ref_Str'First);
-
-if Nkind (Unit (C_Node)) = N_Package_Declaration
-  and then Chars (C_Ent) = Name_System
-
-   --  Handle child packages named foo-system.ads
-
-  and then Loc_Str'Length > Ref_Str'Length
-  and then Loc_Str (Loc_Str'First .. Ref_Len)
- = Ref_Str (Ref_Str'First .. Ref_Len)
-
-   --  ... and ensure that package System has not
-   --  been previously loaded. Done to ensure that
-   --  the above checks do not have any corner case
-   --  (since they are performed without semantic
-   --  information).
-
-  and then not RTU_Loaded (Rtsfind.System)
-then
-   Set_Global_No_Tasking;
-end if;
- end;
-  end if;
+   elsif R_Id = No_Tasking and then No (Cunit (Main_Unit)) then
+  Set_Global_No_Tasking;
end if;
 
--  If this is a warning, then set the warning unless we already

[Ada] Implement AI12-0249, AI12-0295 (user-defined numeric & string literals)

[Pierre-Marie de Rodat]

Implement Ada 202x's Integer_Literal, Real_Literal, and String_Literal
aspects. This is just a preliminary implementation; interactions with
controlled types, build-in-place functions, abstract types, interface
types, aspects specifying an operator (e.g, "+"), mandatory aspect
overriding, and many other features have not been implemented.

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

2020-06-16  Steve Baird  

gcc/ada/

* snames.ads-tmpl: Define names of the three new aspects.
* aspects.ads: Define the three new aspects.
* sem_util.ads, sem_util.adb, sem_dim.adb: Move the function
String_From_Numeric_Literal from being declared in the body of
package Sem_Dim to being declared in the visible part of package
Sem_Util.
* sem_ch13.ads, sem_ch13.adb: Declare new visible procedure
Validate_Literal_Aspect. This is where most of the legality
checking occurs for an aspect specification for one of the three
new aspects, as well as resolution of the subprogram named in
the aspect specification. Follow example of other aspects (e.g.,
Validate_Literal_Aspect is called in much the same way as
Validate_Iterable_Aspect in Analyze_Aspects_At_Freeze_Point; a
small amount of legality checking is performed in
Analyze_One_Aspect in much the same way as for Default_Value or
Default_Component_Value aspects). Most of the work is done in
Validate_Literal_Aspect.
* contracts.adb (Add_Contract_Item): Call
Validate_Literal_Aspect in much the same way that
Validate_Iterable_Aspect was already being called.
* sem_res.adb (Resolve): Rewrite a literal as a call if it is a
user-defined literal.  This is where the dynamic semantics of
the 3 new aspects are implemented.
* sem_ch6.adb (Fully_Conformant_Expressions): Two numeric
literals that have different text but the same value (e.g.,
12345 and 12_345) do not conform if they are user-defined
literals. Introduce a new function
User_Defined_Numeric_Literal_Mismatch to avoid duplication in
making this check.
* sem_type.adb (Has_Compatible_Type): A numeric literal can be
compatible with a non-numeric type (and a string literal can be
compatible with a non-string type) if it can be interpreted as a
user-defined literal.

patch.diff.gz
Description: application/gzip

[Ada] Minor casing of " The " after a comma in docs and comments

[Pierre-Marie de Rodat]

Fix wrong casing in phrases like "something, The"; also, fix other small
typos in comments.

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

2020-06-16  Piotr Trojanek  

gcc/ada/

* checks.adb, doc/gnat_ugn/the_gnat_compilation_model.rst,
einfo.ads, exp_ch5.adb, exp_ch7.adb, lib-xref.ads,
libgnat/g-spitbo.ads, make.adb, sem_aux.adb, sem_ch3.adb,
sem_ch4.adb, sem_ch5.adb, urealp.adb: Fix wrong casing.
* gnat_ugn.texi: Regenerate.--- gcc/ada/checks.adb
+++ gcc/ada/checks.adb
@@ -1960,7 +1960,7 @@ package body Checks is
--  (1)  The bounds may not be known at compile time
--  (2)  The check must take into account rounding or truncation.
--  (3)  The range of type I may not be exactly representable in F.
-   --  (4)  For the rounding case, The end-points I'First - 0.5 and
+   --  (4)  For the rounding case, the end-points I'First - 0.5 and
--   I'Last + 0.5 may or may not be in range, depending on the
--   sign of  I'First and I'Last.
--  (5)  X may be a NaN, which will fail any comparison

--- gcc/ada/doc/gnat_ugn/the_gnat_compilation_model.rst
+++ gcc/ada/doc/gnat_ugn/the_gnat_compilation_model.rst
@@ -3950,7 +3950,7 @@ The following example, provided as part of the GNAT examples, shows how
 to achieve procedural interfacing between Ada and C++ in both
 directions. The C++ class A has two methods. The first method is exported
 to Ada by the means of an extern C wrapper function. The second method
-calls an Ada subprogram. On the Ada side, The C++ calls are modelled by
+calls an Ada subprogram. On the Ada side, the C++ calls are modelled by
 a limited record with a layout comparable to the C++ class. The Ada
 subprogram, in turn, calls the C++ method. So, starting from the C++
 main program, the process passes back and forth between the two

--- gcc/ada/einfo.ads
+++ gcc/ada/einfo.ads
@@ -538,7 +538,7 @@ package Einfo is
 --Block_Node (Node11)
 --   Defined in block entities. Points to the identifier in the
 --   Block_Statement itself. Used when retrieving the block construct
---   for finalization purposes, The block entity has an implicit label
+--   for finalization purposes, the block entity has an implicit label
 --   declaration in the enclosing declarative part, and has otherwise
 --   no direct connection in the tree with the block statement. The
 --   link is to the identifier (which is an occurrence of the entity)

--- gcc/ada/exp_ch5.adb
+++ gcc/ada/exp_ch5.adb
@@ -3892,8 +3892,6 @@ package body Exp_Ch5 is
   Ind_Comp   : Node_Id;
   Iterator   : Entity_Id;
 
-   --  Start of processing for Expand_Iterator_Loop_Over_Array
-
begin
   --  for Element of Array loop
 

--- gcc/ada/exp_ch7.adb
+++ gcc/ada/exp_ch7.adb
@@ -368,7 +368,7 @@ package body Exp_Ch7 is
--  Mode such subprograms must be handled as nested inside the (implicit)
--  elaboration procedure that executes that statement part. To handle
--  properly uplevel references we construct that subprogram explicitly,
-   --  to contain blocks and inner subprograms, The statement part becomes
+   --  to contain blocks and inner subprograms, the statement part becomes
--  a call to this subprogram. This is only done if blocks are present
--  in the statement list of the body. (It would be nice to unify this
--  procedure with Check_Unnesting_In_Decls_Or_Stmts, if possible, since

--- gcc/ada/gnat_ugn.texi
+++ gcc/ada/gnat_ugn.texi
@@ -6034,7 +6034,7 @@ The following example, provided as part of the GNAT examples, shows how
 to achieve procedural interfacing between Ada and C++ in both
 directions. The C++ class A has two methods. The first method is exported
 to Ada by the means of an extern C wrapper function. The second method
-calls an Ada subprogram. On the Ada side, The C++ calls are modelled by
+calls an Ada subprogram. On the Ada side, the C++ calls are modelled by
 a limited record with a layout comparable to the C++ class. The Ada
 subprogram, in turn, calls the C++ method. So, starting from the C++
 main program, the process passes back and forth between the two

--- gcc/ada/lib-xref.ads
+++ gcc/ada/lib-xref.ads
@@ -592,7 +592,7 @@ package Lib.Xref is
 
--  What we do in such cases is to gather nodes, where we would have liked
--  to call Generate_Reference but we couldn't because we didn't know enough
-   --  into this table, Then we deal with generating references later on when
+   --  into this table, then we deal with generating references later on when
--  we have sufficient information to do it right.
 
type Deferred_Reference_Entry is record

--- gcc/ada/libgnat/g-spitbo.ads
+++ gcc/ada/libgnat/g-spitbo.ads
@@ -126,7 +126,7 @@ package GNAT.Spitbol is
   Len : Natural;
   Pad : Character := ' ') return VString;
--  If the length of Str is greater than or equal to Len, then Str is
-   --  returned unchanged. Otherwise, The value

[Ada] Expand 'Pos and 'Val for enumeration types with standard representation

[Pierre-Marie de Rodat]

This changes the front-end to expand the 'Pos and 'Val attributes for
enumeration types with standard representation.  It turns out that this
was the only remaining case where it does not expand them, as it does
so for enumeration types with non-standard representation as well as
for integer types.

Besides fixing the irregularity, this makes it possible to narrow the
computations in which these attributes are involved, since they either
return or take a value of Universal_Integer type nominally.

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

2020-06-16  Eric Botcazou  

gcc/ada/

* sinfo.ads (Conversion_OK): Document use for 'Pos and 'Val.
* exp_attr.adb (Get_Integer_Type): New function returning a
small integer type appropriate for an enumeration type.
(Expand_N_Attribute_Reference) : Call it.
: For an enumeration type with a standard
representation, expand to a conversion with Conversion_OK.
: Likewise.
* exp_ch4.adb (Expand_N_Type_Conversion): Do not expand when
the target is an enumeration type and Conversion_OK is set.--- gcc/ada/exp_attr.adb
+++ gcc/ada/exp_attr.adb
@@ -1737,11 +1737,41 @@ package body Exp_Attr is
   Pref  : constant Node_Id  := Prefix (N);
   Exprs : constant List_Id  := Expressions (N);
 
+  function Get_Integer_Type (Typ : Entity_Id) return Entity_Id;
+  --  Return a small integer type appropriate for the enumeration type
+
   procedure Rewrite_Attribute_Proc_Call (Pname : Entity_Id);
   --  Rewrites an attribute for Read, Write, Output, or Put_Image with a
   --  call to the appropriate TSS procedure. Pname is the entity for the
   --  procedure to call.
 
+  --
+  -- Get_Integer_Type --
+  --
+
+  function Get_Integer_Type (Typ : Entity_Id) return Entity_Id is
+ Siz : constant Uint := RM_Size (Base_Type (Typ));
+ Int_Typ : Entity_Id;
+
+  begin
+ --  We need to accommodate unsigned values
+
+ if Siz < 8 then
+Int_Typ := Standard_Integer_8;
+
+ elsif Siz < 16 then
+Int_Typ := Standard_Integer_16;
+
+ elsif Siz < 32 then
+Int_Typ := Standard_Integer_32;
+
+ else
+Int_Typ := Standard_Integer_64;
+ end if;
+
+ return Int_Typ;
+  end Get_Integer_Type;
+
   -
   -- Rewrite_Attribute_Proc_Call --
   -
@@ -3146,8 +3176,6 @@ package body Exp_Attr is
 
   when Attribute_Enum_Rep => Enum_Rep : declare
  Expr : Node_Id;
- Ityp : Entity_Id;
- Psiz : Uint;
 
   begin
  --  Get the expression, which is X for Enum_Type'Enum_Rep (X) or
@@ -3177,22 +3205,7 @@ package body Exp_Attr is
  --  the size information.
 
  if Is_Enumeration_Type (Ptyp) then
-Psiz := RM_Size (Base_Type (Ptyp));
-
-if Psiz < 8 then
-   Ityp := Standard_Integer_8;
-
-elsif Psiz < 16 then
-   Ityp := Standard_Integer_16;
-
-elsif Psiz < 32 then
-   Ityp := Standard_Integer_32;
-
-else
-   Ityp := Standard_Integer_64;
-end if;
-
-Rewrite (N, OK_Convert_To (Ityp, Expr));
+Rewrite (N, OK_Convert_To (Get_Integer_Type (Ptyp), Expr));
 Convert_To_And_Rewrite (Typ, N);
 
  else
@@ -5159,9 +5172,6 @@ package body Exp_Attr is
   -- Pos --
   -
 
-  --  For enumeration types with a standard representation, Pos is handled
-  --  by the back end.
-
   --  For enumeration types, with a non-standard representation we generate
   --  a call to the _Rep_To_Pos function created when the type was frozen.
   --  The call has the form:
@@ -5172,17 +5182,21 @@ package body Exp_Attr is
   --  Program_Error to be raised if the expression has an invalid
   --  representation, and False if range checks are suppressed.
 
+  --  For enumeration types with a standard representation, Pos can be
+  --  rewritten as a simple conversion with Conversion_OK set.
+
   --  For integer types, Pos is equivalent to a simple integer conversion
   --  and we rewrite it as such.
 
   when Attribute_Pos => Pos : declare
+ Expr : constant Node_Id := First (Exprs);
  Etyp : Entity_Id := Base_Type (Ptyp);
 
   begin
  --  Deal with zero/non-zero boolean values
 
  if Is_Boolean_Type (Etyp) then
-Adjust_Condition (First (Exprs));
+Adjust_Condition (Expr);
 Etyp := Standard_Boolean;
 Set_Prefix (N, New_Occurrence_Of (Standard_Boolean, Loc));
  end if;
@@ -5202,21 +5216,32 @@ package body Exp_Attr is
New_Occurrence_Of (TSS (Etyp, TSS_Rep_To_Pos), Loc),
  Parameter_Associations => Exprs)

[Ada] Fix spurious error on derived private type with predicate

[Pierre-Marie de Rodat]

As explained in the head comment of Compatible_Types_In_Predicate,
anomalies involving private and full views can occur when a call
to a predicate or invariant function is generated by the compiler.

The function uses the child function Common_Type to reconcile the
various views of a private type, but this latter function does not
consider the Underlying_Full_View of private types, so it can miss
some cases like this one.

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

2020-06-16  Eric Botcazou  

gcc/ada/

* sem_ch4.adb (Common_Type): Go to Underlying_Full_View, if any.--- gcc/ada/sem_ch4.adb
+++ gcc/ada/sem_ch4.adb
@@ -3291,20 +3291,30 @@ package body Sem_Ch4 is
  T2 : Entity_Id) return Boolean
   is
  function Common_Type (T : Entity_Id) return Entity_Id;
- --  Find non-private full view if any, without going to ancestor type
- --  (as opposed to Underlying_Type).
+ --  Find non-private underlying full view if any, without going to
+ --  ancestor type (as opposed to Underlying_Type).
 
  -
  -- Common_Type --
  -
 
  function Common_Type (T : Entity_Id) return Entity_Id is
+CT : Entity_Id;
+
  begin
-if Is_Private_Type (T) and then Present (Full_View (T)) then
-   return Base_Type (Full_View (T));
-else
-   return Base_Type (T);
+CT := T;
+
+if Is_Private_Type (CT) and then Present (Full_View (CT)) then
+   CT := Full_View (CT);
 end if;
+
+if Is_Private_Type (CT)
+  and then Present (Underlying_Full_View (CT))
+then
+   CT := Underlying_Full_View (CT);
+end if;
+
+return Base_Type (CT);
  end Common_Type;
 
   --  Start of processing for Compatible_Types_In_Predicate

[Ada] Declare expressions

[Pierre-Marie de Rodat]

This patch implements AI12-0236-1, declare expressions. They are
implemented in terms of N_Expression_With_Actions, which has the same
semantics. A superset of the semantics, actually.

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

2020-06-16  Bob Duff  

gcc/ada/

* par-ch4.adb (P_Case_Expression): Move to be local.
(P_Declare_Expression): New parsing routine.
(P_Unparen_Cond_Expr_Etc): New name for
P_Unparen_Cond_Case_Quant_Expression which was missing one case
in its name (iterated component association), and we're adding a
new case (declare expression), so lets use "Etc" instead of
trying to pack all those things into the name.  Add call to
P_Declare_Expression, and check for missing parens.
(P_Expression_If_OK, P_Expression_Or_Range_Attribute_If_OK): Add
Tok_Declare.
* par.adb (P_Basic_Declarative_Items): Add parameter
Declare_Expression so we can tailor the error message about
incorrect bodies.
(P_Case_Expression): Move to body.
* par-ch3.adb (P_Basic_Declarative_Items): Tailor the error
message about incorrect bodies.
* par-ch7.adb (P_Package): Pass Declare_Expression => False to
P_Basic_Declarative_Items.
* sem.ads (In_Declare_Expr): Counter used to determine whether
we are analyzing a declare_expression. Needed to give errors
about things that are not allowed in declare_expression, such as
the 'Access attribute.
* sem.adb (Do_Analyze): Save/restore In_Declare_Expr.
* sem_ch4.adb (Analyze_Expression_With_Actions): Give this node
its own scope.  That seems better in general, but it is
necessary for declare_expressions.  For example, an identifier
declared in a declare_expression should not clash with the same
identifier in an outer scope.  If this is a declare_expression,
indicated by Comes_From_Source, then check legality rules, and
incr/decr In_Declare_Expr.
* sem_aggr.adb (Resolve_Aggregate): Allow an applicable index
constraint for a declare_expression, so if its expression is an
array aggregate, it can have "others => ...".
* sem_attr.adb (Analyze_Access_Attribute): Disallow these
attributes in declare_expressions. Add comment to make it clear
that Unrestricted_Access is included.
* sinfo.ads, sinfo.adb, atree.ads, atree.adb: Remove the
now-incorrect comment in sinfo.ads that says
N_Expression_With_Actions has no proper scope.  Add 17-parameter
versions of Nkind_In.  Remove the 16-parameter versions of
Nkind_In.--- gcc/ada/atree.adb
+++ gcc/ada/atree.adb
@@ -1940,11 +1940,12 @@ package body Atree is
   V13 : Node_Kind;
   V14 : Node_Kind;
   V15 : Node_Kind;
-  V16 : Node_Kind) return Boolean
+  V16 : Node_Kind;
+  V17 : Node_Kind) return Boolean
is
begin
   return Nkind_In (Nkind (N), V1, V2, V3, V4, V5, V6, V7, V8, V9, V10,
-  V11, V12, V13, V14, V15, V16);
+  V11, V12, V13, V14, V15, V16, V17);
end Nkind_In;
 


--- gcc/ada/atree.ads
+++ gcc/ada/atree.ads
@@ -772,7 +772,7 @@ package Atree is
   V10 : Node_Kind;
   V11 : Node_Kind) return Boolean;
 
-   --  12..15-parameter versions are not yet needed
+   --  12..16-parameter versions are not yet needed
 
function Nkind_In
  (N   : Node_Id;
@@ -791,7 +791,8 @@ package Atree is
   V13 : Node_Kind;
   V14 : Node_Kind;
   V15 : Node_Kind;
-  V16 : Node_Kind) return Boolean;
+  V16 : Node_Kind;
+  V17 : Node_Kind) return Boolean;
 
pragma Inline (Nkind_In);
--  Inline all above functions

--- gcc/ada/par-ch3.adb
+++ gcc/ada/par-ch3.adb
@@ -4702,7 +4702,9 @@ package body Ch3 is
--  the scan pointer is repositioned past the next semicolon, and the scan
--  for declarative items continues.
 
-   function P_Basic_Declarative_Items return List_Id is
+   function P_Basic_Declarative_Items
+ (Declare_Expression : Boolean) return List_Id
+   is
   Decl  : Node_Id;
   Decls : List_Id;
   Kind  : Node_Kind;
@@ -4750,7 +4752,15 @@ package body Ch3 is
 Kind = N_Task_Body   or else
 Kind = N_Protected_Body
  then
-Error_Msg ("proper body not allowed in package spec", Sloc (Decl));
+if Declare_Expression then
+   Error_Msg
+ ("proper body not allowed in declare_expression",
+  Sloc (Decl));
+else
+   Error_Msg
+ ("proper body not allowed in package spec",
+  Sloc (Decl));
+end if;
 
 --  Complete declaration of mangled subprogram body, for better
 --  recovery if analysis is attempted.

--- gcc/ada/par-ch4.adb
+++ gcc/ada/par-ch4.adb
@@ -72,23 +72,24 @@ pac

[Ada] Improve bug box customer language

[Pierre-Marie de Rodat]

The language used in the bugbox for a customer to report an error
message is missing an upper-case for the start of a sentence and also
could be worded a bit clearer.

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

2020-06-16  Richard Kenner  

gcc/ada/

* comperr.adb (Compiler_Abort): Clarify message displayed to
customers.--- gcc/ada/comperr.adb
+++ gcc/ada/comperr.adb
@@ -330,12 +330,12 @@ package body Comperr is
   End_Line;
 
   Write_Str
-("| alternatively submit a bug report by email " &
- "to rep...@adacore.com,");
+("| Or submit a bug report by email " &
+ "to rep...@adacore.com");
   End_Line;
 
   Write_Str
-("| including your customer number #nnn " &
+("| and include your customer number #nnn " &
  "in the subject line.");
   End_Line;
end if;

[Ada] Reuse Is_Object where possible

[Pierre-Marie de Rodat]

Reuse a high-level Is_Object, which is meant to be more readable than a
low-level membership test with Ekind. Semantics is unaffected.

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

2020-06-16  Piotr Trojanek  

gcc/ada/

* einfo.adb, exp_spark.adb, exp_util.adb, sem_eval.adb: Replace
"Ekind ... in Object_Kind" with "Is_Object (...)".--- gcc/ada/einfo.adb
+++ gcc/ada/einfo.adb
@@ -997,7 +997,7 @@ package body Einfo is
 
function Current_Value (Id : E) return N is
begin
-  pragma Assert (Ekind (Id) in Object_Kind);
+  pragma Assert (Is_Object (Id));
   return Node9 (Id);
end Current_Value;
 

--- gcc/ada/exp_spark.adb
+++ gcc/ada/exp_spark.adb
@@ -434,7 +434,7 @@ package body Exp_SPARK is
begin
   --  Replace a reference to a renaming with the actual renamed object
 
-  if Ekind (Obj_Id) in Object_Kind then
+  if Is_Object (Obj_Id) then
  Ren := Renamed_Object (Obj_Id);
 
  if Present (Ren) then

--- gcc/ada/exp_util.adb
+++ gcc/ada/exp_util.adb
@@ -6396,7 +6396,7 @@ package body Exp_Util is
 
   --  Immediate return, nothing doing, if this is not an object
 
-  if Ekind (Ent) not in Object_Kind then
+  if not Is_Object (Ent) then
  return;
   end if;
 

--- gcc/ada/sem_eval.adb
+++ gcc/ada/sem_eval.adb
@@ -1001,7 +1001,7 @@ package body Sem_Eval is
 (Is_Known_Valid (Entity (Opnd))
   or else Ekind (Entity (Opnd)) = E_In_Parameter
   or else
-(Ekind (Entity (Opnd)) in Object_Kind
+(Is_Object (Entity (Opnd))
   and then Present (Current_Value (Entity (Opnd))
or else Is_OK_Static_Expression (Opnd);
   end Is_Known_Valid_Operand;

[Ada] Change how we detect internal protected subprograms

[Pierre-Marie de Rodat]

We don't always have Convention_Protected, so test for presence of
Protected_Body_Subprogram.

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

2020-06-16  Richard Kenner  

gcc/ada/

* exp_unst.adb (Subp_Index): Change way we detect internal
protected subprograms.--- gcc/ada/exp_unst.adb
+++ gcc/ada/exp_unst.adb
@@ -282,7 +282,7 @@ package body Exp_Unst is
  --  has been scanned at this point, and thus has an entry in the
  --  subprogram table.
 
- if E = Sub and then Convention (E) = Convention_Protected then
+ if E = Sub and then Present (Protected_Body_Subprogram (E)) then
 E := Protected_Body_Subprogram (E);
  end if;
 

Re: [PATCH] vectorizer: add _bb_vec_info::const_iterator

[Martin Liška]

On 6/16/20 10:50 AM, Richard Sandiford wrote:

Martin Liška  writes:

Also, one minor formatting nit, sorry: the other functions instead
indent the “{” block by the same amount as the function prototype,
which seems more consistent with the usual out-of-class formatting.


Hope I fixed that.


Sorry, I meant the other functions were IMO formatted correctly, with the
“{” directly under the function name.  It looks like the new patch instead
indents all “{” by two spaces relative to the function name or “struct”
keyword.  I.e. IMO:

   struct const_iterator
   {
   };

seems better than:
   
   struct const_iterator

 {
 };

and:

   const const_iterator &
   operator++ ()
   {
   }

seems better than:

   const const_iterator &
   operator++ ()
 {
 }

This makes the formatting consistent with definitions in column 0.


About rbiener's comment, I wrapper the iterators with bb_vinfo::region_stmts..


Sorry for dragging this on longer, but…


@@ -5120,20 +5120,14 @@ vect_determine_precisions (vec_info *vinfo)
else
  {
bb_vec_info bb_vinfo = as_a  (vinfo);
-  gimple_stmt_iterator si = bb_vinfo->region_end;
-  gimple *stmt;
-  do
+  for ( _bb_vec_info::reverse_iterator it = bb_vinfo->region_stmts.rbegin 
();
+  it != bb_vinfo->region_stmts.rend (); ++it)
{
- if (!gsi_stmt (si))
-   si = gsi_last_bb (bb_vinfo->bb);
- else
-   gsi_prev (&si);
- stmt = gsi_stmt (si);
+ gimple *stmt = *it;
  stmt_vec_info stmt_info = vinfo->lookup_stmt (stmt);
  if (stmt_info && STMT_VINFO_VECTORIZABLE (stmt_info))
vect_determine_stmt_precisions (vinfo, stmt_info);
}
-  while (stmt != gsi_stmt (bb_vinfo->region_begin));
  }
  }


I think this should be a similar style, i.e.

  for (gimple *stmt : bb_vinfo->reverse_region_stmts ())

rather than using iterators directly.


@@ -5492,10 +5486,8 @@ vect_pattern_recog (vec_info *vinfo)
else
  {
bb_vec_info bb_vinfo = as_a  (vinfo);
-  for (si = bb_vinfo->region_begin;
-  gsi_stmt (si) != gsi_stmt (bb_vinfo->region_end); gsi_next (&si))
+  for (gimple *stmt : bb_vinfo->region_stmts)
{
- gimple *stmt = gsi_stmt (si);
  stmt_vec_info stmt_info = bb_vinfo->lookup_stmt (stmt);
  if (!stmt_info || !STMT_VINFO_VECTORIZABLE (stmt_info))
continue;
diff --git a/gcc/tree-vect-slp.c b/gcc/tree-vect-slp.c
index 303410c2fc4..f4809c2207d 100644
--- a/gcc/tree-vect-slp.c
+++ b/gcc/tree-vect-slp.c
@@ -2546,20 +2546,15 @@ vect_detect_hybrid_slp (loop_vec_info loop_vinfo)
  /* Initialize a bb_vec_info struct for the statements between
 REGION_BEGIN_IN (inclusive) and REGION_END_IN (exclusive).  */
  
-_bb_vec_info::_bb_vec_info (gimple_stmt_iterator region_begin_in,

-   gimple_stmt_iterator region_end_in,
+_bb_vec_info::_bb_vec_info (gimple_stmt_iterator region_begin,
+   gimple_stmt_iterator region_end,
vec_info_shared *shared)
: vec_info (vec_info::bb, init_cost (NULL), shared),
-bb (gsi_bb (region_begin_in)),
-region_begin (region_begin_in),
-region_end (region_end_in)
+bb (gsi_bb (region_begin)),
+region_stmts (region_begin, region_end)
  {
-  gimple_stmt_iterator gsi;
-
-  for (gsi = region_begin; gsi_stmt (gsi) != gsi_stmt (region_end);
-   gsi_next (&gsi))
+  for (gimple *stmt : this->region_stmts)
  {
-  gimple *stmt = gsi_stmt (gsi);
gimple_set_uid (stmt, 0);
if (is_gimple_debug (stmt))
continue;
@@ -2575,10 +2570,9 @@ _bb_vec_info::_bb_vec_info (gimple_stmt_iterator 
region_begin_in,
  
  _bb_vec_info::~_bb_vec_info ()

  {
-  for (gimple_stmt_iterator si = region_begin;
-   gsi_stmt (si) != gsi_stmt (region_end); gsi_next (&si))
+  for (gimple *stmt : this->region_stmts)
  /* Reset region marker.  */
-gimple_set_uid (gsi_stmt (si), -1);
+gimple_set_uid (stmt, -1);
  
bb->aux = NULL;

  }
@@ -3012,16 +3006,13 @@ vect_bb_vectorization_profitable_p (bb_vec_info 
bb_vinfo)
  static void
  vect_slp_check_for_constructors (bb_vec_info bb_vinfo)
  {
-  gimple_stmt_iterator gsi;
-
-  for (gsi = bb_vinfo->region_begin;
-   gsi_stmt (gsi) != gsi_stmt (bb_vinfo->region_end); gsi_next (&gsi))
+  for (gimple *stmt : bb_vinfo->region_stmts)
  {
-  gassign *stmt = dyn_cast  (gsi_stmt (gsi));
-  if (!stmt || gimple_assign_rhs_code (stmt) != CONSTRUCTOR)
+  gassign *assign = dyn_cast  (stmt);
+  if (!assign || gimple_assign_rhs_code (assign) != CONSTRUCTOR)
continue;
  
-  tree rhs = gimple_assign_rhs1 (stmt);

+  tree rhs = gimple_assign_rhs1 (assign);
if (!VECTOR_TYPE_P (TREE_TYPE (rhs))
  || maybe_ne (TYPE_VECTOR_SUBPARTS (TREE_TYPE (rhs)),
   CONSTRUCTOR_NELTS (rhs))
@@ -3029,7 +3020,7 @@ vect_slp_check_for_constructors (bb_vec_info bb_vinfo)
 

Re: [PATCH] recog: Use parameter packs for operator()

[Jonathan Wakely via Gcc-patches]

On 16/06/20 11:42 +0100, Richard Sandiford wrote:

Jonathan Wakely  writes:

+  template
+  rtx_insn *operator() (Ts... args...) const

Why is this declared as a variadic template **and** a varargs function?

I think the second ellipsis is wrong, it should be just:

+  template
+  rtx_insn *operator() (Ts... args) const


Oops, yes.


And this seems like a more direct way to say "a list of N rtx types"
where N is sizeof...(args):

diff --git a/gcc/recog.h b/gcc/recog.h
index 0a71a02c4a9..fd22c58c92a 100644
--- a/gcc/recog.h
+++ b/gcc/recog.h
@@ -294,10 +294,13 @@ struct insn_gen_fn
 {
   typedef void (*stored_funcptr) (void);

+  template using rtx_t = rtx;
+
   template
-  rtx_insn *operator() (Ts... args...) const
+  rtx_insn *operator() (Ts... args) const
   {
-return ((rtx_insn *(*) (decltype(args, NULL_RTX)...)) func) (args...);
+using funcptr = rtx_insn * (*) (rtx_t...);
+return ((funcptr) func) (args...);
   }

   // This is for compatibility of code that invokes functions like

The rtx_t alias is the type 'rtx' for any T. The pack expansion
rtx_t... is a list of rtx the same length as the pack Ts.


Yeah.  As mentioned on IRC, I'd originally done it like this, but didn't
like the ad-hoc type alias.  I can't remember what name I'd used, but the
problem in both cases is/was that the ad-hoc name looks odd when you're
used to seeing plain “rtx”.  It also felt weird to expose this kind of
internal, function-specific implementation detail at insn_gen_fn scope.

Using decltype also gave nicer error messages, e.g.:

   invalid conversion from ‘int’ to ‘rtx {aka rtx_def*}’

instead of:

   invalid conversion from ‘int’ to ‘insn_gen_fn::rtx_t {aka rtx_def*}’

I think the latter is likely to confuse people when they see it
for the first time.

So in some ways I'd prefer to keep the decltype and just add a void cast
to suppress the warning.  (Seems odd to warn about expressions having no
effect in an unevaluated context.)


Yes, arguably a G++ bug.


But how about the below instead?  Hopefully the alias name is mnemonic
enough.


Works for me, thanks.

OpenACC/Fortran: permit 'routine' inside PURE

[Tobias Burnus]

While OpenACC 2.0 had
"OpenACC directives may not appear in Fortran PURE
 or ELEMENTAL procedures"

OpenACC 2.5 relaxed this. This patch permits 'acc routine'
(with explicit or implicit 'seq' clause) inside PURE
procedures.

The 'match' → 'matcha' change permits that the gfc_errors
inside the 'routine' actually show up. The 'goto' instead
of 'gfc_error_recovery' is just for consistency.

Thomas reviewed this patch off list.
Unless there are further comments, I will later
apply it to mainline (and OG10).

Tobias

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

libgomp/ChangeLog:

	* testsuite/libgomp.oacc-fortran/routine-10.f90: New test.

gcc/testsuite/ChangeLog:
2020-06-15 Thomas Schwinge 
	   Tobias Burnus  

	* gfortran.dg/goacc/pure-elemental-procedures-2.f90: New test.

Reviewed-by: Thomas Schwinge 

 gcc/fortran/openmp.c   |  8 
 gcc/fortran/parse.c| 28 ++--
 .../goacc/pure-elemental-procedures-2.f90  | 27 +++
 .../testsuite/libgomp.oacc-fortran/routine-10.f90  | 52 ++
 4 files changed, 102 insertions(+), 13 deletions(-)

diff --git a/gcc/fortran/openmp.c b/gcc/fortran/openmp.c
index b24630827c9..94522d16e6d 100644
--- a/gcc/fortran/openmp.c
+++ b/gcc/fortran/openmp.c
@@ -2525,6 +2525,14 @@ gfc_match_oacc_routine (void)
 /* Something has gone wrong, possibly a syntax error.  */
 goto cleanup;
 
+  if (gfc_pure (NULL) && c && (c->gang || c->worker || c->vector))
+{
+  gfc_error ("!$ACC ROUTINE with GANG, WORKER, or VECTOR clause is not "
+		 "permitted in PURE procedure at %C");
+  goto cleanup;
+}
+
+
   if (n)
 n->clauses = c;
   else if (gfc_current_ns->oacc_routine)
diff --git a/gcc/fortran/parse.c b/gcc/fortran/parse.c
index 9d90e501bf6..ffaef63a50d 100644
--- a/gcc/fortran/parse.c
+++ b/gcc/fortran/parse.c
@@ -639,20 +639,10 @@ decode_oacc_directive (void)
 
   gfc_matching_function = false;
 
-  if (gfc_pure (NULL))
-{
-  gfc_error_now ("OpenACC directives at %C may not appear in PURE "
-		 "procedures");
-  gfc_error_recovery ();
-  return ST_NONE;
-}
-
   if (gfc_current_state () == COMP_FUNCTION
   && gfc_current_block ()->result->ts.kind == -1)
 spec_only = true;
 
-  gfc_unset_implicit_pure (NULL);
-
   old_locus = gfc_current_locus;
 
   /* General OpenACC directive matching: Instead of testing every possible
@@ -661,6 +651,21 @@ decode_oacc_directive (void)
 
   c = gfc_peek_ascii_char ();
 
+  switch (c)
+{
+case 'r':
+  matcha ("routine", gfc_match_oacc_routine, ST_OACC_ROUTINE);
+  break;
+}
+
+  gfc_unset_implicit_pure (NULL);
+  if (gfc_pure (NULL))
+{
+  gfc_error_now ("OpenACC directives other than ROUTINE may not appear in PURE "
+		 "procedures at %C");
+  goto error_handling;
+}
+
   switch (c)
 {
 case 'a':
@@ -705,9 +710,6 @@ decode_oacc_directive (void)
 case 'l':
   matcha ("loop", gfc_match_oacc_loop, ST_OACC_LOOP);
   break;
-case 'r':
-  match ("routine", gfc_match_oacc_routine, ST_OACC_ROUTINE);
-  break;
 case 's':
   matcha ("serial loop", gfc_match_oacc_serial_loop, ST_OACC_SERIAL_LOOP);
   matcha ("serial", gfc_match_oacc_serial, ST_OACC_SERIAL);
diff --git a/gcc/testsuite/gfortran.dg/goacc/pure-elemental-procedures-2.f90 b/gcc/testsuite/gfortran.dg/goacc/pure-elemental-procedures-2.f90
new file mode 100644
index 000..97d92c3becc
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/goacc/pure-elemental-procedures-2.f90
@@ -0,0 +1,27 @@
+pure elemental subroutine foo()
+!$acc routine vector  ! { dg-error "ROUTINE with GANG, WORKER, or VECTOR clause is not permitted in PURE procedure" }
+end
+
+elemental subroutine foo2()
+!$acc routine (myfoo2) gang  ! { dg-error "Invalid NAME 'myfoo2' in" }
+end
+
+elemental subroutine foo2a()
+!$acc routine gang  ! { dg-error "ROUTINE with GANG, WORKER, or VECTOR clause is not permitted in PURE procedure" }
+end
+
+pure subroutine foo3()
+!$acc routine vector ! { dg-error "ROUTINE with GANG, WORKER, or VECTOR clause is not permitted in PURE procedure" }
+end
+
+elemental impure subroutine foo4()
+!$acc routine vector ! OK: impure
+end
+
+pure subroutine foo5()
+!$acc routine seq ! OK: seq
+end
+
+pure subroutine foo6()
+!$acc routine ! OK (implied 'seq')
+end
diff --git a/libgomp/testsuite/libgomp.oacc-fortran/routine-10.f90 b/libgomp/testsuite/libgomp.oacc-fortran/routine-10.f90
new file mode 100644
index 000..90cca7c1024
--- /dev/null
+++ b/libgomp/testsuite/libgomp.oacc-fortran/routine-10.f90
@@ -0,0 +1,52 @@
+! { dg-do run }
+!
+module m
+  implicit none
+contains
+  pure subroutine add_ps_routine(a, b, c)
+implicit none
+!$acc routine seq
+integer, intent(in)  :: a, b
+intege

Re: [PATCH] vectorizer: add _bb_vec_info::const_iterator

[Richard Sandiford]

Martin Liška  writes:
> On 6/16/20 10:50 AM, Richard Sandiford wrote:
>> Martin Liška  writes:
 Also, one minor formatting nit, sorry: the other functions instead
 indent the “{” block by the same amount as the function prototype,
 which seems more consistent with the usual out-of-class formatting.
>>>
>>> Hope I fixed that.
>> 
>> Sorry, I meant the other functions were IMO formatted correctly, with the
>> “{” directly under the function name.  It looks like the new patch instead
>> indents all “{” by two spaces relative to the function name or “struct”
>> keyword.  I.e. IMO:
>> 
>>struct const_iterator
>>{
>>};
>> 
>> seems better than:
>>
>>struct const_iterator
>>  {
>>  };
>> 
>> and:
>> 
>>const const_iterator &
>>operator++ ()
>>{
>>}
>> 
>> seems better than:
>> 
>>const const_iterator &
>>operator++ ()
>>  {
>>  }
>> 
>> This makes the formatting consistent with definitions in column 0.
>> 
>>> About rbiener's comment, I wrapper the iterators with 
>>> bb_vinfo::region_stmts..
>> 
>> Sorry for dragging this on longer, but…
>> 
>>> @@ -5120,20 +5120,14 @@ vect_determine_precisions (vec_info *vinfo)
>>> else
>>>   {
>>> bb_vec_info bb_vinfo = as_a  (vinfo);
>>> -  gimple_stmt_iterator si = bb_vinfo->region_end;
>>> -  gimple *stmt;
>>> -  do
>>> +  for ( _bb_vec_info::reverse_iterator it = 
>>> bb_vinfo->region_stmts.rbegin ();
>>> +  it != bb_vinfo->region_stmts.rend (); ++it)
>>> {
>>> - if (!gsi_stmt (si))
>>> -   si = gsi_last_bb (bb_vinfo->bb);
>>> - else
>>> -   gsi_prev (&si);
>>> - stmt = gsi_stmt (si);
>>> + gimple *stmt = *it;
>>>   stmt_vec_info stmt_info = vinfo->lookup_stmt (stmt);
>>>   if (stmt_info && STMT_VINFO_VECTORIZABLE (stmt_info))
>>> vect_determine_stmt_precisions (vinfo, stmt_info);
>>> }
>>> -  while (stmt != gsi_stmt (bb_vinfo->region_begin));
>>>   }
>>>   }
>> 
>> I think this should be a similar style, i.e.
>> 
>>   for (gimple *stmt : bb_vinfo->reverse_region_stmts ())
>> 
>> rather than using iterators directly.
>> 
>>> @@ -5492,10 +5486,8 @@ vect_pattern_recog (vec_info *vinfo)
>>> else
>>>   {
>>> bb_vec_info bb_vinfo = as_a  (vinfo);
>>> -  for (si = bb_vinfo->region_begin;
>>> -  gsi_stmt (si) != gsi_stmt (bb_vinfo->region_end); gsi_next (&si))
>>> +  for (gimple *stmt : bb_vinfo->region_stmts)
>>> {
>>> - gimple *stmt = gsi_stmt (si);
>>>   stmt_vec_info stmt_info = bb_vinfo->lookup_stmt (stmt);
>>>   if (!stmt_info || !STMT_VINFO_VECTORIZABLE (stmt_info))
>>> continue;
>>> diff --git a/gcc/tree-vect-slp.c b/gcc/tree-vect-slp.c
>>> index 303410c2fc4..f4809c2207d 100644
>>> --- a/gcc/tree-vect-slp.c
>>> +++ b/gcc/tree-vect-slp.c
>>> @@ -2546,20 +2546,15 @@ vect_detect_hybrid_slp (loop_vec_info loop_vinfo)
>>>   /* Initialize a bb_vec_info struct for the statements between
>>>  REGION_BEGIN_IN (inclusive) and REGION_END_IN (exclusive).  */
>>>   
>>> -_bb_vec_info::_bb_vec_info (gimple_stmt_iterator region_begin_in,
>>> -   gimple_stmt_iterator region_end_in,
>>> +_bb_vec_info::_bb_vec_info (gimple_stmt_iterator region_begin,
>>> +   gimple_stmt_iterator region_end,
>>> vec_info_shared *shared)
>>> : vec_info (vec_info::bb, init_cost (NULL), shared),
>>> -bb (gsi_bb (region_begin_in)),
>>> -region_begin (region_begin_in),
>>> -region_end (region_end_in)
>>> +bb (gsi_bb (region_begin)),
>>> +region_stmts (region_begin, region_end)
>>>   {
>>> -  gimple_stmt_iterator gsi;
>>> -
>>> -  for (gsi = region_begin; gsi_stmt (gsi) != gsi_stmt (region_end);
>>> -   gsi_next (&gsi))
>>> +  for (gimple *stmt : this->region_stmts)
>>>   {
>>> -  gimple *stmt = gsi_stmt (gsi);
>>> gimple_set_uid (stmt, 0);
>>> if (is_gimple_debug (stmt))
>>> continue;
>>> @@ -2575,10 +2570,9 @@ _bb_vec_info::_bb_vec_info (gimple_stmt_iterator 
>>> region_begin_in,
>>>   
>>>   _bb_vec_info::~_bb_vec_info ()
>>>   {
>>> -  for (gimple_stmt_iterator si = region_begin;
>>> -   gsi_stmt (si) != gsi_stmt (region_end); gsi_next (&si))
>>> +  for (gimple *stmt : this->region_stmts)
>>>   /* Reset region marker.  */
>>> -gimple_set_uid (gsi_stmt (si), -1);
>>> +gimple_set_uid (stmt, -1);
>>>   
>>> bb->aux = NULL;
>>>   }
>>> @@ -3012,16 +3006,13 @@ vect_bb_vectorization_profitable_p (bb_vec_info 
>>> bb_vinfo)
>>>   static void
>>>   vect_slp_check_for_constructors (bb_vec_info bb_vinfo)
>>>   {
>>> -  gimple_stmt_iterator gsi;
>>> -
>>> -  for (gsi = bb_vinfo->region_begin;
>>> -   gsi_stmt (gsi) != gsi_stmt (bb_vinfo->region_end); gsi_next (&gsi))
>>> +  for (gimple *stmt : bb_vinfo->region_stmts)
>>>   {
>>> -  gassign *stmt = dyn_cast  (gsi_stmt (gsi));
>>> -  if (!stmt || gimple_assign_rhs_code (stmt) != CONSTRUCTOR)
>>> +  

Re: PING^2: [PATCH] x86: Add UNSPECV_PATCHABLE_AREA

[Jakub Jelinek via Gcc-patches]

On Tue, Jun 09, 2020 at 09:34:01AM -0700, H.J. Lu via Gcc-patches wrote:
> > > * gcc.target/i386/pr93492-3.c: Likewise.
> > > * gcc.target/i386/pr93492-5.c: Likewise.

These tests FAIL on i686-linux.
E.g. in the first one I see
.file   "pr93492-3.c"
.text
.globl  f10_endbr
.type   f10_endbr, @function
f10_endbr:
.LFB0:
.cfi_startproc
endbr32
.section__patchable_function_entries,"aw",@progbits
.align 4
.long   .LPFE1
.text
.LPFE1:
nop
1:  call__fentry__
pushl   %ebp
.cfi_def_cfa_offset 8
.cfi_offset 5, -8
movl%esp, %ebp
.cfi_def_cfa_register 5
popl%ebp
.cfi_restore 5
.cfi_def_cfa 4, 4
ret
.cfi_endproc
.LFE0:
.size   f10_endbr, .-f10_endbr
so it doesn't match the scan regexp, because
call__fentry__
is not immediately followed by
ret
As -pg is incompatible with -fomit-frame-pointer, I don't see anything wrong
on that.

Another thing in the test is that I don't think you can rely on
.cfi_startproc actually being printed, you should add an effective target
that will either check __GCC_HAVE_DWARF2_CFI_ASM macro definition, or check
for presence of .cfi_startproc on some trivial function compiled with
-fasynchronous-unwind-tables.

Jakub

Re: PING^2: [PATCH] x86: Add UNSPECV_PATCHABLE_AREA

[H.J. Lu via Gcc-patches]

On Tue, Jun 16, 2020 at 7:17 AM Jakub Jelinek  wrote:
>
> On Tue, Jun 09, 2020 at 09:34:01AM -0700, H.J. Lu via Gcc-patches wrote:
> > > > * gcc.target/i386/pr93492-3.c: Likewise.
> > > > * gcc.target/i386/pr93492-5.c: Likewise.
>
> These tests FAIL on i686-linux.
> E.g. in the first one I see
> .file   "pr93492-3.c"
> .text
> .globl  f10_endbr
> .type   f10_endbr, @function
> f10_endbr:
> .LFB0:
> .cfi_startproc
> endbr32
> .section__patchable_function_entries,"aw",@progbits
> .align 4
> .long   .LPFE1
> .text
> .LPFE1:
> nop
> 1:  call__fentry__
> pushl   %ebp
> .cfi_def_cfa_offset 8
> .cfi_offset 5, -8
> movl%esp, %ebp
> .cfi_def_cfa_register 5
> popl%ebp
> .cfi_restore 5
> .cfi_def_cfa 4, 4
> ret
> .cfi_endproc
> .LFE0:
> .size   f10_endbr, .-f10_endbr
> so it doesn't match the scan regexp, because
> call__fentry__
> is not immediately followed by
> ret
> As -pg is incompatible with -fomit-frame-pointer, I don't see anything wrong
> on that.

Can you take a look at

https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547992.html

It should fix it.

> Another thing in the test is that I don't think you can rely on
> .cfi_startproc actually being printed, you should add an effective target
> that will either check __GCC_HAVE_DWARF2_CFI_ASM macro definition, or check
> for presence of .cfi_startproc on some trivial function compiled with
> -fasynchronous-unwind-tables.
>

-mfentry and -fpatchable-function-entry= don't work on all targets.
Should I limit these tests to Linux?

-- 
H.J.

[committed] openmp: Diagnose invalid OpenMP schedule(simd, static)

[Jakub Jelinek via Gcc-patches]

Hi!

I've noticed we weren't diagnosing this, fixed thusly,
bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.

2020-06-16  Jakub Jelinek  

gcc/c/
* c-parser.c (c_parser_omp_clause_schedule): Reject modifier separated
from kind by comma rather than colon.
gcc/cp/
* parser.c (cp_parser_omp_clause_schedule): Reject modifier separated
from kind by comma rather than colon.
gcc/testsuite/
* c-c++-common/gomp/schedule-modifiers-2.c: New test.

--- gcc/c/c-parser.c.jj 2020-06-16 12:10:03.613011138 +0200
+++ gcc/c/c-parser.c2020-06-16 12:23:41.208216697 +0200
@@ -14782,6 +14782,7 @@ c_parser_omp_clause_schedule (c_parser *
 
   c = build_omp_clause (loc, OMP_CLAUSE_SCHEDULE);
 
+  location_t comma = UNKNOWN_LOCATION;
   while (c_parser_next_token_is (parser, CPP_NAME))
 {
   tree kind = c_parser_peek_token (parser)->value;
@@ -14794,16 +14795,22 @@ c_parser_omp_clause_schedule (c_parser *
modifiers |= OMP_CLAUSE_SCHEDULE_NONMONOTONIC;
   else
break;
+  comma = UNKNOWN_LOCATION;
   c_parser_consume_token (parser);
   if (nmodifiers++ == 0
  && c_parser_next_token_is (parser, CPP_COMMA))
-   c_parser_consume_token (parser);
+   {
+ comma = c_parser_peek_token (parser)->location;
+ c_parser_consume_token (parser);
+   }
   else
{
  c_parser_require (parser, CPP_COLON, "expected %<:%>");
  break;
}
 }
+  if (comma != UNKNOWN_LOCATION)
+error_at (comma, "expected %<:%>");
 
   if ((modifiers & (OMP_CLAUSE_SCHEDULE_MONOTONIC
| OMP_CLAUSE_SCHEDULE_NONMONOTONIC))
--- gcc/cp/parser.c.jj  2020-06-16 11:37:11.533023319 +0200
+++ gcc/cp/parser.c 2020-06-16 12:27:20.047032749 +0200
@@ -35868,6 +35868,7 @@ cp_parser_omp_clause_schedule (cp_parser
 
   c = build_omp_clause (location, OMP_CLAUSE_SCHEDULE);
 
+  location_t comma = UNKNOWN_LOCATION;
   while (cp_lexer_next_token_is (parser->lexer, CPP_NAME))
 {
   tree id = cp_lexer_peek_token (parser->lexer)->u.value;
@@ -35880,16 +35881,22 @@ cp_parser_omp_clause_schedule (cp_parser
modifiers |= OMP_CLAUSE_SCHEDULE_NONMONOTONIC;
   else
break;
+  comma = UNKNOWN_LOCATION;
   cp_lexer_consume_token (parser->lexer);
   if (nmodifiers++ == 0
  && cp_lexer_next_token_is (parser->lexer, CPP_COMMA))
-   cp_lexer_consume_token (parser->lexer);
+   {
+ comma = cp_lexer_peek_token (parser->lexer)->location;
+ cp_lexer_consume_token (parser->lexer);
+   }
   else
{
  cp_parser_require (parser, CPP_COLON, RT_COLON);
  break;
}
 }
+  if (comma != UNKNOWN_LOCATION)
+error_at (comma, "expected %<:%>");
 
   if (cp_lexer_next_token_is (parser->lexer, CPP_NAME))
 {
--- gcc/testsuite/c-c++-common/gomp/schedule-modifiers-2.c.jj   2020-06-16 
12:30:11.602534085 +0200
+++ gcc/testsuite/c-c++-common/gomp/schedule-modifiers-2.c  2020-06-16 
12:29:28.035168632 +0200
@@ -0,0 +1,14 @@
+void
+foo (void)
+{
+  int i = 0;
+  #pragma omp for simd schedule(simd, static)  /* { dg-error "expected ':'" } 
*/
+  for (i = 0; i < 16; i++)
+;
+  #pragma omp for simd schedule(monotonic, dynamic)/* { dg-error "expected 
':'" } */
+  for (i = 0; i < 16; i++)
+;
+  #pragma omp for simd schedule(nonmonotonic, guided, 1)   /* { dg-error 
"expected ':'" } */
+  for (i = 0; i < 16; i++)
+;
+}

Jakub

Re: [Patch] OpenMP/Fortran: Permit impure ELEMENTAL in omp directives

[Thomas Schwinge]

Hi!

On 2020-06-16T13:27:43+0200, Tobias Burnus  wrote:
> when looking into a PURE/ELEMENTAL issue with OpenACC, Thomas and
> I came across the analogous OpenMP code – and stumbled over
> ELEMENTAL.
>
> In Fortran, ELEMENTAL implies PURE but one can also have an IMPURE
> ELEMENTAL procedure.
>
> As PR 79154 quotes, OpenMP 4 had:
> "OpenMP directives may not appear in PURE or ELEMENTAL procedures."
>
> While OpenMP 4.5 (and later) have:
> "OpenMP directives, except SIMD and declare target directives,
>   may not appear in pure procedures."
>
> ELEMENTAL is still mentioned – but only for:
> "OpenMP runtime library routines may not be called
>   from PURE or ELEMENTAL procedures."

... but that's mentioned not only diagnoesd here:

> --- a/gcc/fortran/parse.c
> +++ b/gcc/fortran/parse.c
> @@ -849,7 +849,7 @@ decode_omp_directive (void)
>/* match is for directives that should be recognized only if
>   -fopenmp, matchs for directives that should be recognized
>   if either -fopenmp or -fopenmp-simd.
> - Handle only the directives allowed in PURE/ELEMENTAL procedures
> + Handle only the directives allowed in PURE procedures
>   first (those also shall not turn off implicit pure).  */
>switch (c)
>  {
> @@ -868,7 +868,7 @@ decode_omp_directive (void)
>if (flag_openmp && gfc_pure (NULL))
>  {
>gfc_error_now ("OpenMP directives other than SIMD or DECLARE TARGET "
> -  "at %C may not appear in PURE or ELEMENTAL procedures");
> +  "at %C may not appear in PURE procedures");
>gfc_error_recovery ();
>return ST_NONE;
>  }

..., but also further down, in the 'finish' label:

 finish:
  if (!pure_ok)
{
  gfc_unset_implicit_pure (NULL);

  if (!flag_openmp && gfc_pure (NULL))
{
  gfc_error_now ("OpenMP directives other than SIMD or DECLARE 
TARGET "
 "at %C may not appear in PURE or ELEMENTAL "
 "procedures");
  reject_statement ();
  gfc_error_recovery ();
  return ST_NONE;
}
}
  return ret;

..., so I suppose this needs to be changed, too -- and maybe is missing
testsuite coverage?

> --- a/gcc/testsuite/gfortran.dg/gomp/pr79154-1.f90
> +++ b/gcc/testsuite/gfortran.dg/gomp/pr79154-1.f90
> @@ -2,7 +2,7 @@
>  ! { dg-do compile }
>
>  pure real function foo (a, b)! { dg-warning "GCC does not 
> currently support mixed size types for 'simd' functions" "" { target 
> aarch64*-*-* } }
> -!$omp declare simd(foo)  ! { dg-bogus "may not appear in 
> PURE or ELEMENTAL" }
> +!$omp declare simd(foo)  ! { dg-bogus "may not appear in 
> PURE" }
>real, intent(in) :: a, b
>foo = a + b
>  end function foo
> @@ -10,23 +10,28 @@ pure function bar (a, b)
>real, intent(in) :: a(8), b(8)
>real :: bar(8)
>integer :: i
> -!$omp simd   ! { dg-bogus "may not appear in PURE or 
> ELEMENTAL" }
> +!$omp simd   ! { dg-bogus "may not appear in PURE" }
>do i = 1, 8
>  bar(i) = a(i) + b(i)
>end do
>  end function bar
>  pure real function baz (a, b)
> -!$omp declare target ! { dg-bogus "may not appear in PURE or 
> ELEMENTAL" }
> +!$omp declare target ! { dg-bogus "may not appear in PURE" }
>real, intent(in) :: a, b
>baz = a + b
>  end function baz
>  elemental real function fooe (a, b)  ! { dg-warning "GCC does not currently 
> support mixed size types for 'simd' functions" "" { target aarch64*-*-* } }
> -!$omp declare simd(fooe) ! { dg-bogus "may not appear in PURE or 
> ELEMENTAL" }
> +!$omp declare simd(fooe) ! { dg-bogus "may not appear in PURE" }
>real, intent(in) :: a, b
>fooe = a + b
>  end function fooe
>  elemental real function baze (a, b)
> -!$omp declare target ! { dg-bogus "may not appear in PURE or 
> ELEMENTAL" }
> +!$omp declare target ! { dg-bogus "may not appear in PURE" }
>real, intent(in) :: a, b
>baze = a + b
>  end function baze
> +elemental impure real function bazei (a, b)
> +!$omp declare target ! { dg-bogus "may not appear in PURE" }
> +  real, intent(in) :: a, b
> +  baze = a + b

Shouldn't this assign to 'bazei' instead of 'baze'?

> +end function bazei

> --- a/gcc/testsuite/gfortran.dg/gomp/pr79154-2.f90
> +++ b/gcc/testsuite/gfortran.dg/gomp/pr79154-2.f90
> @@ -3,14 +3,14 @@
>
>  pure real function foo (a, b)
>real, intent(in) :: a, b
> -!$omp taskwait   ! { dg-error "may not appear in 
> PURE or ELEMENTAL" }
> +!$omp taskwait   ! { dg-error "may not appear in 
> PURE" }
>foo = a + b
>  end function foo
>  pure function bar (a, b)
>real, intent(in) :: a(8), b(8)
>real :: bar(8)
>integer :: i
> -!$omp do simd  

[committed] openmp: Initial part of OpenMP 5.0 non-rectangular loop support

[Jakub Jelinek via Gcc-patches]

Hi!

OpenMP 5.0 adds support for non-rectangular loop collapses, e.g.
triangular and more complex.

This patch deals just with the diagnostics so that they aren't rejected
immediately as before.  As the spec generally requires as before that the
iteration variable initializer and bound in the comparison as invariant
vs. the outermost loop, and just add some exceptional forms that can violate
that, we need to avoid folding the expressions until we can detect them and
in order to avoid folding it later on, I chose to use a TREE_VEC in those
expressions to hold the var_outer * expr1 + expr2 triplet, the patch adds
pretty-printing of that, gimplification etc. and just sorry_at during
omp expansion for now.

The next step will be to implement the different cases of that one by one.

Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.

2020-06-16  Jakub Jelinek  

gcc/
* tree.h (OMP_FOR_NON_RECTANGULAR): Define.
* gimplify.c (gimplify_omp_for): Diagnose schedule, ordered
or dist_schedule clause on non-rectangular loops.  Handle
gimplification of non-rectangular lb/b expressions.  When changing
iteration variable, adjust also non-rectangular lb/b expressions
referencing that.
* omp-general.h (struct omp_for_data_loop): Add m1, m2 and outer
members.
(struct omp_for_data): Add non_rect member.
* omp-general.c (omp_extract_for_data): Handle non-rectangular
loops.  Fill in non_rect, m1, m2 and outer.
* omp-low.c (lower_omp_for): Handle non-rectangular lb/b expressions.
* omp-expand.c (expand_omp_for): Emit sorry_at for unsupported
non-rectangular loop cases and assert for cases that can't be
non-rectangular.
* tree-pretty-print.c (dump_mem_ref): Formatting fix.
(dump_omp_loop_non_rect_expr): New function.
(dump_generic_node): Handle non-rectangular OpenMP loops.
* tree-pretty-print.h (dump_omp_loop_non_rect_expr): Declare.
* gimple-pretty-print.c (dump_gimple_omp_for): Handle non-rectangular
OpenMP loops.
gcc/c-family/
* c-common.h (c_omp_check_loop_iv_exprs): Add an int argument.
* c-omp.c (struct c_omp_check_loop_iv_data): Add maybe_nonrect and
idx members.
(c_omp_is_loop_iterator): New function.
(c_omp_check_loop_iv_r): Use it.  Add support for silent scanning
if outer loop iterator is present.  Perform duplicate checking through
hash_set in the function rather than expecting caller to do that.
Pass NULL instead of d->ppset to walk_tree_1.
(c_omp_check_nonrect_loop_iv): New function.
(c_omp_check_loop_iv): Use it.  Fill in new members, allow
non-rectangular loop forms, diagnose multiple associated loops with
the same iterator.  Pass NULL instead of &pset to walk_tree_1.
(c_omp_check_loop_iv_exprs): Likewise.
gcc/c/
* c-parser.c (c_parser_expr_no_commas): Save, clear and restore
c_in_omp_for.
(c_parser_omp_for_loop): Set c_in_omp_for around some calls to avoid
premature c_fully_fold.  Defer explicit c_fully_fold calls to after
c_finish_omp_for.
* c-tree.h (c_in_omp_for): Declare.
* c-typeck.c (c_in_omp_for): Define.
(build_modify_expr): Avoid c_fully_fold if c_in_omp_for.
(digest_init): Likewise.
(build_binary_op): Likewise.
gcc/cp/
* semantics.c (handle_omp_for_class_iterator): Adjust
c_omp_check_loop_iv_exprs caller.
(finish_omp_for): Likewise.  Don't call fold_build_cleanup_point_expr
before calling c_finish_omp_for and c_omp_check_loop_iv, move it
after those calls.
* pt.c (tsubst_omp_for_iterator): Handle non-rectangular loops.
gcc/testsuite/
* c-c++-common/gomp/loop-6.c: New test.
* gcc.dg/gomp/loop-1.c: Don't expect diagnostics on valid
non-rectangular loops.
* gcc.dg/gomp/loop-2.c: New test.
* g++.dg/gomp/loop-1.C: Don't expect diagnostics on valid
non-rectangular loops.
* g++.dg/gomp/loop-2.C: Likewise.
* g++.dg/gomp/loop-5.C: New test.
* g++.dg/gomp/loop-6.C: New test.

--- gcc/tree.h.jj   2020-06-16 12:10:03.628010921 +0200
+++ gcc/tree.h  2020-06-16 12:35:02.440298110 +0200
@@ -1465,6 +1465,11 @@ class auto_suppress_location_wrappers
   != UNKNOWN_LOCATION)
 #define OMP_CLAUSE_LOCATION(NODE)  (OMP_CLAUSE_CHECK (NODE))->omp_clause.locus
 
+/* True on OMP_FOR and other OpenMP/OpenACC looping constructs if the loop nest
+   is non-rectangular.  */
+#define OMP_FOR_NON_RECTANGULAR(NODE) \
+  (OMP_LOOPING_CHECK (NODE)->base.private_flag)
+
 /* True on an OMP_SECTION statement that was the last lexical member.
This status is meaningful in the implementation of lastprivate.  */
 #define OMP_SECTION_LAST(NODE) \
--- gcc/gimplify.c.jj   2020-06-16 12:10:03.622011008 +0200
+++ gcc/gimplify.c  2020-06-16 12:35:02.446

Re: [PATCH] S/390: Emit vector alignment hints for z13 if AS accepts them

[Andreas Krebbel via Gcc-patches]

On 16.06.20 10:26, Stefan Schulze Frielinghaus wrote:
> Since 87cb9423add vector alignment hints are emitted for target z13,
> too.  This patch changes this behaviour in the sense that alignment
> hints are only emitted for target z13 if the assembler accepts them.
> 
> Bootstrapped and regtested on S/390. Ok for master?
> 
> gcc/ChangeLog:
> 
>   * config.in: Regenerate.
>   * config/s390/s390.c (print_operand): Emit vector alignment hints
>   for target z13, if AS accepts them.  For other targets the logic
>   stays the same.
>   * config/s390/s390.h (TARGET_VECTOR_LOADSTORE_ALIGNMENT_HINTS): Define
>   macro.
>   * configure: Regenerate.
>   * configure.ac: Check HAVE_AS_VECTOR_LOADSTORE_ALIGNMENT_HINTS_ON_Z13.

Ok. Thanks!

Andreas

> ---
>  gcc/config.in  |  7 +++
>  gcc/config/s390/s390.c |  4 +---
>  gcc/config/s390/s390.h |  7 +++
>  gcc/configure  | 31 +++
>  gcc/configure.ac   |  5 +
>  5 files changed, 51 insertions(+), 3 deletions(-)
> 
> diff --git a/gcc/config.in b/gcc/config.in
> index 809e7b26823..364eba47737 100644
> --- a/gcc/config.in
> +++ b/gcc/config.in
> @@ -706,6 +706,13 @@
>  #endif
>  
>  
> +/* Define if your assembler supports vl/vst/vlm/vstm with an optional
> +   alignment hint argument on z13. */
> +#ifndef USED_FOR_TARGET
> +#undef HAVE_AS_VECTOR_LOADSTORE_ALIGNMENT_HINTS_ON_Z13
> +#endif
> +
> +
>  /* Define if your assembler supports VSX instructions. */
>  #ifndef USED_FOR_TARGET
>  #undef HAVE_AS_VSX
> diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c
> index 56e3e87425a..758315c0c72 100644
> --- a/gcc/config/s390/s390.c
> +++ b/gcc/config/s390/s390.c
> @@ -7853,15 +7853,13 @@ print_operand (FILE *file, rtx x, int code)
>switch (code)
>  {
>  case 'A':
> -#ifdef HAVE_AS_VECTOR_LOADSTORE_ALIGNMENT_HINTS
> -  if (TARGET_Z13 && MEM_P (x))
> +  if (TARGET_VECTOR_LOADSTORE_ALIGNMENT_HINTS && MEM_P (x))
>   {
> if (MEM_ALIGN (x) >= 128)
>   fprintf (file, ",4");
> else if (MEM_ALIGN (x) == 64)
>   fprintf (file, ",3");
>   }
> -#endif
>return;
>  case 'C':
>fprintf (file, s390_branch_condition_mnemonic (x, FALSE));
> diff --git a/gcc/config/s390/s390.h b/gcc/config/s390/s390.h
> index 2e29dbe97e8..e4ef63e4080 100644
> --- a/gcc/config/s390/s390.h
> +++ b/gcc/config/s390/s390.h
> @@ -167,6 +167,13 @@ enum processor_flags
>   (TARGET_VX && TARGET_CPU_VXE2)
>  #define TARGET_VXE2_P(opts)  \
>   (TARGET_VX_P (opts) && TARGET_CPU_VXE2_P (opts))
> +#if defined(HAVE_AS_VECTOR_LOADSTORE_ALIGNMENT_HINTS_ON_Z13)
> +#define TARGET_VECTOR_LOADSTORE_ALIGNMENT_HINTS TARGET_Z13
> +#elif defined(HAVE_AS_VECTOR_LOADSTORE_ALIGNMENT_HINTS)
> +#define TARGET_VECTOR_LOADSTORE_ALIGNMENT_HINTS TARGET_Z14
> +#else
> +#define TARGET_VECTOR_LOADSTORE_ALIGNMENT_HINTS 0
> +#endif
>  
>  #ifdef HAVE_AS_MACHINE_MACHINEMODE
>  #define S390_USE_TARGET_ATTRIBUTE 1
> diff --git a/gcc/configure b/gcc/configure
> index def9d9a48be..f224679ed3e 100755
> --- a/gcc/configure
> +++ b/gcc/configure
> @@ -28241,6 +28241,37 @@ if test 
> $gcc_cv_as_s390_vector_loadstore_alignment_hints = yes; then
>  
>  $as_echo "#define HAVE_AS_VECTOR_LOADSTORE_ALIGNMENT_HINTS 1" >>confdefs.h
>  
> +fi
> +
> +{ $as_echo "$as_me:${as_lineno-$LINENO}: checking assembler for vector 
> load/store alignment hints on z13" >&5
> +$as_echo_n "checking assembler for vector load/store alignment hints on 
> z13... " >&6; }
> +if ${gcc_cv_as_s390_vector_loadstore_alignment_hints_on_z13+:} false; then :
> +  $as_echo_n "(cached) " >&6
> +else
> +  gcc_cv_as_s390_vector_loadstore_alignment_hints_on_z13=no
> +  if test x$gcc_cv_as != x; then
> +$as_echo '   vl %v24,0(%r15),3 ' > conftest.s
> +if { ac_try='$gcc_cv_as $gcc_cv_as_flags -mzarch -march=z13 -o 
> conftest.o conftest.s >&5'
> +  { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
> +  (eval $ac_try) 2>&5
> +  ac_status=$?
> +  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
> +  test $ac_status = 0; }; }
> +then
> + gcc_cv_as_s390_vector_loadstore_alignment_hints_on_z13=yes
> +else
> +  echo "configure: failed program was" >&5
> +  cat conftest.s >&5
> +fi
> +rm -f conftest.o conftest.s
> +  fi
> +fi
> +{ $as_echo "$as_me:${as_lineno-$LINENO}: result: 
> $gcc_cv_as_s390_vector_loadstore_alignment_hints_on_z13" >&5
> +$as_echo "$gcc_cv_as_s390_vector_loadstore_alignment_hints_on_z13" >&6; }
> +if test $gcc_cv_as_s390_vector_loadstore_alignment_hints_on_z13 = yes; then
> +
> +$as_echo "#define HAVE_AS_VECTOR_LOADSTORE_ALIGNMENT_HINTS_ON_Z13 1" 
> >>confdefs.h
> +
>  fi
>  
>  
> diff --git a/gcc/configure.ac b/gcc/configure.ac
> index e769c9c87d4..e83f0833ef3 100644
> --- a/gcc/configure.ac
> +++ b/gcc/configure.ac
> @@ -5106,6 +5106,11 @@ configured with --enable-newlib-nano-formatted-io.])

Re: [Patch] OpenMP/Fortran: Permit impure ELEMENTAL in omp directives

[Tobias Burnus]

Ups. Good catch. – I think the follow-up patch is obvious.
Unless there are comments, I will commit it as such.

Tobias

On 6/16/20 4:41 PM, Thomas Schwinge wrote:


Hi!

On 2020-06-16T13:27:43+0200, Tobias Burnus  wrote:

when looking into a PURE/ELEMENTAL issue with OpenACC, Thomas and
I came across the analogous OpenMP code – and stumbled over
ELEMENTAL.

In Fortran, ELEMENTAL implies PURE but one can also have an IMPURE
ELEMENTAL procedure.

As PR 79154 quotes, OpenMP 4 had:
"OpenMP directives may not appear in PURE or ELEMENTAL procedures."

While OpenMP 4.5 (and later) have:
"OpenMP directives, except SIMD and declare target directives,
   may not appear in pure procedures."

ELEMENTAL is still mentioned – but only for:
"OpenMP runtime library routines may not be called
   from PURE or ELEMENTAL procedures."

... but that's mentioned not only diagnoesd here:


--- a/gcc/fortran/parse.c
+++ b/gcc/fortran/parse.c
@@ -849,7 +849,7 @@ decode_omp_directive (void)
/* match is for directives that should be recognized only if
   -fopenmp, matchs for directives that should be recognized
   if either -fopenmp or -fopenmp-simd.
- Handle only the directives allowed in PURE/ELEMENTAL procedures
+ Handle only the directives allowed in PURE procedures
   first (those also shall not turn off implicit pure).  */
switch (c)
  {
@@ -868,7 +868,7 @@ decode_omp_directive (void)
if (flag_openmp && gfc_pure (NULL))
  {
gfc_error_now ("OpenMP directives other than SIMD or DECLARE TARGET "
-  "at %C may not appear in PURE or ELEMENTAL procedures");
+  "at %C may not appear in PURE procedures");
gfc_error_recovery ();
return ST_NONE;
  }

..., but also further down, in the 'finish' label:

  finish:
   if (!pure_ok)
 {
   gfc_unset_implicit_pure (NULL);

   if (!flag_openmp && gfc_pure (NULL))
 {
   gfc_error_now ("OpenMP directives other than SIMD or DECLARE TARGET 
"
  "at %C may not appear in PURE or ELEMENTAL "
  "procedures");
   reject_statement ();
   gfc_error_recovery ();
   return ST_NONE;
 }
 }
   return ret;

..., so I suppose this needs to be changed, too -- and maybe is missing
testsuite coverage?


--- a/gcc/testsuite/gfortran.dg/gomp/pr79154-1.f90
+++ b/gcc/testsuite/gfortran.dg/gomp/pr79154-1.f90
@@ -2,7 +2,7 @@
  ! { dg-do compile }

  pure real function foo (a, b)! { dg-warning "GCC does not currently support 
mixed size types for 'simd' functions" "" { target aarch64*-*-* } }
-!$omp declare simd(foo)  ! { dg-bogus "may not appear in PURE 
or ELEMENTAL" }
+!$omp declare simd(foo)  ! { dg-bogus "may not appear in 
PURE" }
real, intent(in) :: a, b
foo = a + b
  end function foo
@@ -10,23 +10,28 @@ pure function bar (a, b)
real, intent(in) :: a(8), b(8)
real :: bar(8)
integer :: i
-!$omp simd   ! { dg-bogus "may not appear in PURE or 
ELEMENTAL" }
+!$omp simd   ! { dg-bogus "may not appear in PURE" }
do i = 1, 8
  bar(i) = a(i) + b(i)
end do
  end function bar
  pure real function baz (a, b)
-!$omp declare target ! { dg-bogus "may not appear in PURE or 
ELEMENTAL" }
+!$omp declare target ! { dg-bogus "may not appear in PURE" }
real, intent(in) :: a, b
baz = a + b
  end function baz
  elemental real function fooe (a, b)  ! { dg-warning "GCC does not currently support mixed 
size types for 'simd' functions" "" { target aarch64*-*-* } }
-!$omp declare simd(fooe) ! { dg-bogus "may not appear in PURE or 
ELEMENTAL" }
+!$omp declare simd(fooe) ! { dg-bogus "may not appear in PURE" }
real, intent(in) :: a, b
fooe = a + b
  end function fooe
  elemental real function baze (a, b)
-!$omp declare target ! { dg-bogus "may not appear in PURE or 
ELEMENTAL" }
+!$omp declare target ! { dg-bogus "may not appear in PURE" }
real, intent(in) :: a, b
baze = a + b
  end function baze
+elemental impure real function bazei (a, b)
+!$omp declare target ! { dg-bogus "may not appear in PURE" }
+  real, intent(in) :: a, b
+  baze = a + b

Shouldn't this assign to 'bazei' instead of 'baze'?


+end function bazei
--- a/gcc/testsuite/gfortran.dg/gomp/pr79154-2.f90
+++ b/gcc/testsuite/gfortran.dg/gomp/pr79154-2.f90
@@ -3,14 +3,14 @@

  pure real function foo (a, b)
real, intent(in) :: a, b
-!$omp taskwait   ! { dg-error "may not appear in PURE 
or ELEMENTAL" }
+!$omp taskwait   ! { dg-error "may not appear in 
PURE" }
foo = a + b
  end function foo
  pure function bar (a, b)
real, intent(in) :: a(8), b(8)
real :: bar(8)
integer :: i
-!$omp

[PATCH v2, RS6000 PR target/94954] Fix wrong codegen for vec_pack_to_short_fp32() builtin

[will schmidt via Gcc-patches]

[PATCH v2, PR target/94954] Fix wrong codegen for vec_pack_to_short_fp32() 
builtin

Hi,
  Fix codegen for builtin vec_pack_to_short_fp32.  This includes adding
  a define_insn for xvcvsphp, and adding a new define_expand for
  convert_4f32_8f16.
[v2]
  Comment on altivec.md "convert_4f32_8f16" enhanced.
  Testsuite builtins-1-p9-runnable.c updated with additional description
  of the built-in and to improve the target statements.

  OK for trunk and backports?

  Thanks
  -Will

[gcc]
  target pr/94954

* config/rs6000/altivec.h (vec_pack_to_short_fp32) Update.
* config/rs6000/altivec.md (UNSPEC_CONVERT_4F32_8F16): New unspec.
(convert_4f32_8f16): New define_expand
* config/rs6000/rs6000-builtin.def (convert_4f32_8f16): New builtin define
and overload.
* config/rs6000/rs6000-call.c  (P9V_BUILTIN_VEC_CONVERT_4F32_8F16): New
overloaded builtin entry.
* config/rs6000/vsx.md (UNSPEC_VSX_XVCVSPHP): New unspec.
(vsx_xvcvsphp): New define_insn.

[testsuite]
* testsuite/gcc.target/powerpc/builtins-1-p9-runnable.c: Update.

diff --git a/gcc/config/rs6000/altivec.h b/gcc/config/rs6000/altivec.h
index 0a7e8ab..ab10025 100644
--- a/gcc/config/rs6000/altivec.h
+++ b/gcc/config/rs6000/altivec.h
@@ -431,11 +431,11 @@
 /* Vector additions added in ISA 3.0.  */
 #define vec_first_match_index __builtin_vec_first_match_index
 #define vec_first_match_or_eos_index __builtin_vec_first_match_or_eos_index
 #define vec_first_mismatch_index __builtin_vec_first_mismatch_index
 #define vec_first_mismatch_or_eos_index 
__builtin_vec_first_mismatch_or_eos_index
-#define vec_pack_to_short_fp32 __builtin_vec_convert_4f32_8i16
+#define vec_pack_to_short_fp32 __builtin_vec_convert_4f32_8f16
 #define vec_parity_lsbb __builtin_vec_vparity_lsbb
 #define vec_vctz __builtin_vec_vctz
 #define vec_cnttz __builtin_vec_vctz
 #define vec_vctzb __builtin_vec_vctzb
 #define vec_vctzd __builtin_vec_vctzd
diff --git a/gcc/config/rs6000/altivec.md b/gcc/config/rs6000/altivec.md
index 159f24e..5ce54c8 100644
--- a/gcc/config/rs6000/altivec.md
+++ b/gcc/config/rs6000/altivec.md
@@ -78,10 +78,11 @@
UNSPEC_VUNPACK_HI_SIGN_DIRECT
UNSPEC_VUNPACK_LO_SIGN_DIRECT
UNSPEC_VUPKHPX
UNSPEC_VUPKLPX
UNSPEC_CONVERT_4F32_8I16
+   UNSPEC_CONVERT_4F32_8F16
UNSPEC_DST
UNSPEC_DSTT
UNSPEC_DSTST
UNSPEC_DSTSTT
UNSPEC_LVSL
@@ -3215,10 +3216,43 @@
   emit_insn (gen_altivec_vctuxs (rtx_tmp_lo, operands[2], const0_rtx));
   emit_insn (gen_altivec_vpkswss (operands[0], rtx_tmp_hi, rtx_tmp_lo));
   DONE;
 })
 
+
+;; Convert two vector F32 to packed vector F16.
+;; This builtin packs 32-bit floating-point values into a packed
+;; 16-bit floating point values (stored in 16bit integer type).
+;; (vector unsigned short r = vec_pack_to_short_fp32 (a, b);
+;; The expected codegen for this builtin is
+;;xvcvsphp t, a
+;;xvcvsphp u, b
+;;if (little endian)
+;;  vpkuwum r, t, u
+;;else
+;;  vpkuwum r, u, t
+
+(define_expand "convert_4f32_8f16"
+  [(set (match_operand:V8HI 0 "register_operand" "=v")
+   (unspec:V8HI [(match_operand:V4SF 1 "register_operand" "v")
+ (match_operand:V4SF 2 "register_operand" "v")]
+UNSPEC_CONVERT_4F32_8F16))]
+  "TARGET_P9_VECTOR"
+{
+  rtx rtx_tmp_hi = gen_reg_rtx (V4SImode);
+  rtx rtx_tmp_lo = gen_reg_rtx (V4SImode);
+
+  emit_insn (gen_vsx_xvcvsphp (rtx_tmp_hi, operands[1]));
+  emit_insn (gen_vsx_xvcvsphp (rtx_tmp_lo, operands[2]));
+  if (!BYTES_BIG_ENDIAN)
+emit_insn (gen_altivec_vpkuwum (operands[0], rtx_tmp_hi, rtx_tmp_lo));
+  else
+emit_insn (gen_altivec_vpkuwum (operands[0], rtx_tmp_lo, rtx_tmp_hi));
+  DONE;
+})
+
+
 ;; Generate
 ;;xxlxor/vxor SCRATCH0,SCRATCH0,SCRATCH0
 ;;vsubu?m SCRATCH2,SCRATCH1,%1
 ;;vmaxs? %0,%1,SCRATCH2"
 (define_expand "abs2"
diff --git a/gcc/config/rs6000/rs6000-builtin.def 
b/gcc/config/rs6000/rs6000-builtin.def
index 8b1ddb0..47e9137 100644
--- a/gcc/config/rs6000/rs6000-builtin.def
+++ b/gcc/config/rs6000/rs6000-builtin.def
@@ -2208,10 +2208,11 @@ BU_P8V_OVERLOAD_3 (VPERMXOR,   "vpermxor")
 
 /* ISA 3.0 vector overloaded 2-argument functions. */
 BU_P9V_AV_2 (VSLV, "vslv", CONST, vslv)
 BU_P9V_AV_2 (VSRV, "vsrv", CONST, vsrv)
 BU_P9V_AV_2 (CONVERT_4F32_8I16, "convert_4f32_8i16", CONST, convert_4f32_8i16)
+BU_P9V_AV_2 (CONVERT_4F32_8F16, "convert_4f32_8f16", CONST, convert_4f32_8f16)
 
 BU_P9V_AV_2 (VFIRSTMATCHINDEX_V16QI, "first_match_index_v16qi",
 CONST, first_match_index_v16qi)
 BU_P9V_AV_2 (VFIRSTMATCHINDEX_V8HI, "first_match_index_v8hi",
 CONST, first_match_index_v8hi)
@@ -2238,10 +2239,11 @@ BU_P9V_AV_2 (VFIRSTMISMATCHOREOSINDEX_V4SI, 
"first_mismatch_or_eos_index_v4si",
 
 /* ISA 3.0 vector overloaded 2-argument functions. */
 BU_P9V_OVERLOAD_2 (VSLV,   "vslv")
 BU_P9V_OVERLOAD_2 (VSRV,   "vsrv")
 BU_P9V_OVERLOAD_2 (CONVERT_4F32_8I16, "convert_4f32_8i16")
+BU_P9

Re: [PATCH v2] c++: Don't allow designated initializers with non-aggregates [PR95369]

[Jason Merrill via Gcc-patches]

On 6/15/20 4:56 PM, Marek Polacek wrote:

On Thu, Jun 11, 2020 at 06:15:26PM -0400, Jason Merrill via Gcc-patches wrote:

On 6/11/20 5:28 PM, Marek Polacek wrote:

On Thu, Jun 11, 2020 at 03:51:29PM -0400, Jason Merrill wrote:

On 6/9/20 2:17 PM, Marek Polacek wrote:

Another part of 95369 is that we accept designated initializers with
non-aggregate types.  That seems to be wrong since they're part of
aggregate initialization.  clang/icc also reject it.

(Un)fortunately there are multiple contexts where we can use designated
initializers: function-like casts, member list initializers, NTTP, etc.
So I've adjusted multiple places in the compiler in order to to detect
this case and to provide a nice diagnostic, instead of an ugly raft of
errors.


Would it work to handle this only in add_list_candidates?


'fraid not -- we don't call add_list_candidates at all when compiling
desig16.C.


Hmm, why not?  What is turning the CONSTRUCTOR into an argument vec?


Nevermind, I must've glossed over a local patch.  This better patch
implements your suggestion.  I still changed implicit_conversion_error
to give a better diagnostic but that should be fine.  Thanks,

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


OK, thanks.


-- >8 --
Another part of 95369 is that we accept designated initializers with
non-aggregate types.  That seems to be wrong since they're part of
aggregate initialization.  clang/icc also reject it.

There are multiple contexts where we can use designated initializers:
function-like casts, member list initializers, NTTP, etc.  I've adjusted
add_list_candidates and implicit_conversion_error in order to to detect
this case.

gcc/cp/ChangeLog:

PR c++/95369
* call.c (add_list_candidates): Return if a designated initializer
is used with a non-aggregate.
(implicit_conversion_error): Give an error for the case above.

gcc/testsuite/ChangeLog:

PR c++/95369
* g++.dg/cpp2a/desig11.C: Adjust dg-error.
* g++.dg/cpp2a/desig16.C: New test.
---
  gcc/cp/call.c| 13 +
  gcc/testsuite/g++.dg/cpp2a/desig11.C |  2 +-
  gcc/testsuite/g++.dg/cpp2a/desig16.C | 28 
  3 files changed, 42 insertions(+), 1 deletion(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/desig16.C

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index b99959f76f9..1a54e9f4440 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -3952,6 +3952,14 @@ add_list_candidates (tree fns, tree first_arg,
if (any_strictly_viable (*candidates))
return;
  }
+  else if (CONSTRUCTOR_IS_DESIGNATED_INIT (init_list)
+  && !CP_AGGREGATE_TYPE_P (totype))
+{
+  if (complain & tf_error)
+   error ("designated initializers cannot be used with a "
+  "non-aggregate type %qT", totype);
+  return;
+}
  
/* Expand the CONSTRUCTOR into a new argument vec.  */

vec *new_args;
@@ -4301,6 +4309,11 @@ implicit_conversion_error (location_t loc, tree type, 
tree expr)
  instantiate_type (type, expr, complain);
else if (invalid_nonstatic_memfn_p (loc, expr, complain))
  /* We gave an error.  */;
+  else if (BRACE_ENCLOSED_INITIALIZER_P (expr)
+  && CONSTRUCTOR_IS_DESIGNATED_INIT (expr)
+  && !CP_AGGREGATE_TYPE_P (type))
+error_at (loc, "designated initializers cannot be used with a "
+ "non-aggregate type %qT", type);
else
  {
range_label_for_type_mismatch label (TREE_TYPE (expr), type);
diff --git a/gcc/testsuite/g++.dg/cpp2a/desig11.C 
b/gcc/testsuite/g++.dg/cpp2a/desig11.C
index d6895a7be56..a189fff2059 100644
--- a/gcc/testsuite/g++.dg/cpp2a/desig11.C
+++ b/gcc/testsuite/g++.dg/cpp2a/desig11.C
@@ -11,4 +11,4 @@ int bar (_Complex int);   // { dg-message 
"initializing argument 1 of" }
  int y = bar ({.real = 0, .imag = 1}); // { dg-error "cannot convert" }
  
  int baz (std::initializer_list);

-int z = baz ({.one = 1, .two = 2, .three = 3});// { dg-error "could not 
convert" }
+int z = baz ({.one = 1, .two = 2, .three = 3});// { dg-error "designated 
initializers" }
diff --git a/gcc/testsuite/g++.dg/cpp2a/desig16.C 
b/gcc/testsuite/g++.dg/cpp2a/desig16.C
new file mode 100644
index 000..3edb68d24a4
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/desig16.C
@@ -0,0 +1,28 @@
+// PR c++/95369
+// { dg-do compile { target c++20 } }
+
+struct S {
+  unsigned a;
+  unsigned b;
+  constexpr S(unsigned _a, unsigned _b) noexcept: a{_a}, b{_b} { }
+};
+
+template struct X { };
+void g(S);
+
+struct Z {
+  S s;
+  Z() : s{.a = 1, .b = 2} { } // { dg-error "designated initializers|no matching 
function" }
+};
+
+S
+f()
+{
+  X<{.a = 1, .b = 2}> x; // { dg-error "designated initializers" }
+  S s{ .a = 1, .b = 2 }; // { dg-error "designated initializers|no matching 
function" }
+  S s2 = { .a = 1, .b = 2 }; // { dg-error "designated initializers" }
+  S s3 = S{ .a = 1, .b = 2 }; // { dg-error "desi

Re: [PATCH] c++: zero_init_expr_p of dependent expression

[Jason Merrill via Gcc-patches]

On 6/16/20 9:06 AM, Patrick Palka wrote:

On Thu, Apr 23, 2020 at 5:17 PM Jason Merrill  wrote:


On 4/23/20 4:09 PM, Patrick Palka wrote:

This fixes a ICE coming from mangle.c:write_expression when compiling the
ranges-v3 testsuite; the added testcase is a reduced reproducer of the ICE.

Bootstrapped and regtested on x86_64-pc-linux-gnu, and also tested on the
cmcstl2, fmt and range-v3 libraries.  Does this look OK to commit?


OK.


Is it OK to backport the same patch to the 9 branch in order to resolve PR95678?


OK.




gcc/cp/ChangeLog:> >
   * tree.c (zero_init_expr_p): Use uses_template_parms instead of
   dependent_type_p.

gcc/testsuite/ChangeLog:

   * g++.dg/cpp0x/dependent3.C: New test.
---
   gcc/cp/tree.c   |  2 +-
   gcc/testsuite/g++.dg/cpp0x/dependent3.C | 28 +
   2 files changed, 29 insertions(+), 1 deletion(-)
   create mode 100644 gcc/testsuite/g++.dg/cpp0x/dependent3.C

diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index 090c565c093..8840932dba2 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -4486,7 +4486,7 @@ bool
   zero_init_expr_p (tree t)
   {
 tree type = TREE_TYPE (t);
-  if (!type || dependent_type_p (type))
+  if (!type || uses_template_parms (type))
   return false;
 if (zero_init_p (type))
   return initializer_zerop (t);
diff --git a/gcc/testsuite/g++.dg/cpp0x/dependent3.C 
b/gcc/testsuite/g++.dg/cpp0x/dependent3.C
new file mode 100644
index 000..caf7e1cd4a4
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/dependent3.C
@@ -0,0 +1,28 @@
+// { dg-do compile { target c++11 } }
+
+template
+struct d
+{
+  using e = c;
+};
+
+template
+struct g
+{
+  using h = typename d::e;
+
+  template
+  auto operator()(i, j k) -> decltype(h{k});
+};
+
+template
+void m()
+{
+  int a[1];
+  l{}(a, a);
+}
+
+int main()
+{
+  m>();
+}

Re: [PATCH] c++: Fix ICE in check_local_shadow with enum [PR95560]

[Jason Merrill via Gcc-patches]

On 6/15/20 9:20 PM, Marek Polacek wrote:

On Thu, Jun 11, 2020 at 03:32:14PM -0400, Jason Merrill wrote:

On 6/10/20 5:11 PM, Marek Polacek wrote:

Another indication that perhaps this warning is emitted too early.  We
crash because same_type_p gets a null type: we have an enumerator
without a fixed underlying type and finish_enum_value_list hasn't yet
run.  So check if the type is null before calling same_type_p.


Hmm, I wonder why we use NULL_TREE for the type of uninitialized enumerators
in a template; why not give them integer_type_node temporarily?


That breaks enum22.C:

   template 
   struct A {
 enum e_ : unsigned char { Z_, E_=sizeof(Z_) };
   };

   static_assert ( A::E_ == 1, "E_ should be 1");

If we give 'Z_' a type, it's no longer instantiation-dependent, so sizeof(Z_)
immediately evaluates to 4.  Whereas if it doesn't have a type, in the template
we create a SIZEOF_EXPR and only evaluate when instantiating (to 1).

This sounded like a problem big enough for me not to pursue this any further.
Do you want me to try anything else or is the original patch ok?


The original patch is OK, thanks.

Jason

Re: [PATCH] avoid false positives due to compute_objsize (PR 95353)

[Jeff Law via Gcc-patches]

On Mon, 2020-06-15 at 11:10 -0600, Martin Sebor wrote:
> 
> That's fine.  Since they are treated as equivalent it shouldn't
> matter which of the equivalent alternatives is chosen (there
> may be many).  It's the particular choice of the smaller member
> that makes it a problem: both in the terms of triggering a false
> positive and in terms of the note referencing a member the source
> code doesn't use.
> 
> If PRE instead picked the bigger member it wouldn't necessarily
> trigger the warning.  But if that member was also too small,
> the note might still reference the wrong member.
> 
> But if PRE picked another equivalent representation not involving
> any member at all but rather an offset from the base object (i.e.,
> just a MEM_REF) there would be no problem either way: no false
> positive, and if it overflowed, the warning wouldn't reference
> any member but just the base object.
I'm not sure if this is actually viable from an implementation standpoint.  I'd
have to dig deeply into PRE's implementation to know.  But I suspect anything 
you
suggest in this space that continues relying on the type information in MEM_REFs
is going to be rejected as building on top of a fundamentally flawed foundation.


> 
> > > Instead of substituting one member for another in the COMPONENT_REF
> > > when both happen to be accessed at the same offset, using a MEM_REF
> > > alone into the enclosing struct or union plus the offset of
> > > the members would avoid the problem.  Something like this:
> > Ultimately that's just a bandaid over a flawed implementation.  
> > Fundamentally the
> > problem is the diagnostics should not be depending on the type of those MEM
> > expressions.  As long as we continue to do that we're going to run into 
> > problems.
> > Hence my suggestion we look at attaching suitable type information to the 
> > calls
> > early in the pipeline, possibly at AST generation time.
> 
> It's not the MEM_REF type that's a problem here.  The general
> issue with the reliability of late warnings like this one also
> isn't isolated to just function calls.  Any checked statement
> is susceptible to them.
> 
> In this case, the problem is that the COMPONENT_REF member is
> not the one referenced in the source code.  So more reliable
> type information for MEM_REFs wouldn't solve it: we would also
> need more reliable COMPONENT_REFs.
I'm not suggesting we have more accurate type information on either of those
*_REF nodes.  Instead I'm suggesting type information get attached to the
statement which uses them.  ie, the call.  If that turns out to work well, we
could look to expand it to other cases.

It's not a new IL.  Not even close.  It's just attaching the original type of
arguments to the call before the optimizers muck it up.

Jeff

Re: [PATCH] sanitizer: do not inline no-sanitize into sanitizer fn

[Jakub Jelinek via Gcc-patches]

Hi!

On Tue, Jun 09, 2020 at 09:58:11PM +0200, Martin Liška wrote:
> On 6/9/20 9:42 PM, Rainer Orth wrote:
> > Excess errors:
> > cc1: error: '-fsanitize=address' is incompatible with 
> > '-fsanitize=kernel-address'
> 
> Sorry for that, I'm going to install the following patch.

These tests are UNRESOLVED because -fdump-tree-optimized can't be scanned
with slim LTO.  Other *san/ tests deal with this by adding -ffat-lto-objects.

Tested on x86_64-linux, committed to trunk as obvious.

2020-06-16  Jakub Jelinek  

* c-c++-common/asan/inline.c: Add -ffat-lto-objects to dg-options.
* c-c++-common/asan/inline-kernel.c: Likewise.
* c-c++-common/ubsan/inline.c: Likewise.

--- gcc/testsuite/c-c++-common/asan/inline.c.jj 2020-06-10 14:58:17.539494212 
+0200
+++ gcc/testsuite/c-c++-common/asan/inline.c2020-06-16 18:17:36.011197816 
+0200
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-fsanitize=address -c -O3 -fdump-tree-optimized" } */
+/* { dg-options "-fsanitize=address -c -O3 -fdump-tree-optimized 
-ffat-lto-objects" } */
 
 int x;
 
--- gcc/testsuite/c-c++-common/asan/inline-kernel.c.jj  2020-06-10 
14:58:17.539494212 +0200
+++ gcc/testsuite/c-c++-common/asan/inline-kernel.c 2020-06-16 
18:17:51.096981545 +0200
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-fno-sanitize=address -fsanitize=kernel-address -c -O3 
-fdump-tree-optimized" } */
+/* { dg-options "-fno-sanitize=address -fsanitize=kernel-address -c -O3 
-fdump-tree-optimized -ffat-lto-objects" } */
 
 int x;
 
--- gcc/testsuite/c-c++-common/ubsan/inline.c.jj2020-06-10 
14:58:17.539494212 +0200
+++ gcc/testsuite/c-c++-common/ubsan/inline.c   2020-06-16 18:18:08.037738683 
+0200
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-fsanitize=vla-bound -c -O3 -fdump-tree-optimized" } */
+/* { dg-options "-fsanitize=vla-bound -c -O3 -fdump-tree-optimized 
-ffat-lto-objects" } */
 
 int x;
 


Jakub

[PATCH] middle-end: Add another testcase for PR 95493

[Jonathan Wakely via Gcc-patches]

This was reported on the gcc-help mailing list. The regression started
with r10-589 and was fixed by r11-963.

gcc/testsuite/ChangeLog:

* g++.dg/torture/pr95493-1.C: New test.

Tested x86_64-linux. OK for master?


commit 03f6e6bea110994d4e1d49a2469f808082d5bded
Author: Jonathan Wakely 
Date:   Tue Jun 16 17:57:23 2020 +0100

middle-end: Add another testcase for PR 95493

This was reported on the gcc-help mailing list. The regression started
with r10-589 and was fixed by r11-963.

gcc/testsuite/ChangeLog:

* g++.dg/torture/pr95493-1.C: New test.

diff --git a/gcc/testsuite/g++.dg/torture/pr95493-1.C 
b/gcc/testsuite/g++.dg/torture/pr95493-1.C
new file mode 100644
index 000..907d191ebfe
--- /dev/null
+++ b/gcc/testsuite/g++.dg/torture/pr95493-1.C
@@ -0,0 +1,95 @@
+// { dg-do run { target c++11 } }
+// PR rtl-optimization/95493 comment 8
+
+#include 
+#include 
+
+struct Point
+{
+std::array array;
+
+Point(int x, int y, int z) : array{x, y, z} {}
+
+Point(const Point & other) : array{other.array} {} // OK if commented
+//Point(const Point &) = default; // OK
+
+//Point(Point && other) = default; // OK
+
+int  operator[] (std::size_t i) const { return array[i]; }
+int& operator[] (std::size_t i)   { return array[i]; }
+};
+
+//using Point = std::array; // OK
+
+struct Cell
+{
+Point point;
+Cell(Point const& pt) : point(pt) {}
+int   operator[] (std::size_t i) const { return point[i]; }
+int&  operator[] (std::size_t i)   { return point[i]; }
+};
+
+//using Cell = Point; // OK
+
+std::ostream & operator<< (std::ostream & out, Cell const& object)
+//std::ostream & operator<< (std::ostream & out, Cell object) // Fails with f2 
too
+{
+for ( std::size_t i = 0; i < 3; ++i )
+out << object[ i ] << " ";
+return out;
+}
+
+
+struct DirIterator
+{
+std::size_t dir;
+Cell cell;
+
+DirIterator(Cell c)
+: dir(0), cell(c)
+{
+find(); // OK if commented
+}
+
+void find()
+{
+//while (dir < 3) // Fails with f2 too
+while (dir < 3 && (cell[dir] % 2) == 0)
+++dir;
+}
+};
+
+Cell uIncident(Cell c, std::size_t k)
+//Cell uIncident(Cell& c, std::size_t k) // OK
+{
+--c[k];
+return c;
+}
+
+Cell uSpel(Point p)
+{
+for (std::size_t i = 0; i < 3; ++i)
+p[i] += p[i] + 1;
+return Cell(p);
+}
+
+
+int main ()
+{
+Cell c = uSpel(Point{0, 0, 0}); // Fails
+//Cell c( Point(1, 1, 1) ); // OK
+
+auto q = DirIterator( c );
+
+Cell f1 = uIncident( c, q.dir ); // Fails
+//Cell f1 = uIncident( c, 0 ); // OK
+
+Cell f2 = f1; // f2 is the right cell that f1 should be
+
+std::cout << "q.dir = " << q.dir << " ; f1 = " << f1 << " ; f2 = " << f2 
<< std::endl;
+//std::cout << "q.dir = " << q.dir << " ; f1 = " << f1[0] << " " << f1[1] 
<< " " << f1[2] << " ; f2 = " << f2[0] << " " << f2[1] << " " << f2[2] << 
std::endl; // OK
+
+for (int i = 0; i < 3; ++i)
+  if (f1[i] != f2[i])
+__builtin_abort();
+}

PING^2: V5 [PATCH] x86: Move cpuinfo.h from libgcc to common/config/i386

[H.J. Lu via Gcc-patches]

On Tue, Jun 9, 2020 at 9:35 AM H.J. Lu  wrote:
>
> On Tue, May 26, 2020 at 6:27 AM Martin Liška  wrote:
> >
> > On 5/26/20 1:59 PM, H.J. Lu wrote:
> > > On Tue, May 26, 2020 at 2:30 AM Martin Liška  wrote:
> > >>
> > >> On 5/25/20 7:42 PM, H.J. Lu wrote:
> > >>> Here is the updated patch.  OK for master?
> > >>
> > >> Thank you for the updated patch.
> > >>
> > >> I have still few nits:
> > >>
> > >> 1) I would make all the:
> > >>
> > >>> +  has_sse3 = has_feature (FEATURE_SSE3);
> > >>
> > >> a macro. The local variable seems to superfluous.
> > >
> > > Done.
> >
> > Thanks!
> >
> > >
> > >> 2) can we automatically deduce option name:
> > >>
> > >>> +  ISA_NAMES_TABLE_ENTRY("rdpid", FEATURE_RDPID, P_ZERO, "-mrdpid")
> > >>> +  ISA_NAMES_TABLE_ENTRY("rdrnd", FEATURE_RDRND, P_ZERO, "-mrdrnd")
> > >>
> > >> I mean "-m" + "rdrnd" == "-mrdrnd" ?
> > >
> > > The new option field serves 2 purposes:
> > >
> > > 1. Not all features have a corresponding command-line option
> > >
> > > ISA_NAMES_TABLE_ENTRY("cmov", FEATURE_CMOV, P_ZERO, NULL)
> > >
> > >   for (i = 0; i < ARRAY_SIZE (isa_names_table); i++)
> > >  if (isa_names_table[i].option)
> > >
> > > 2. Some feature has a different name in the command-line option.
> > >
> > >ISA_NAMES_TABLE_ENTRY("fxsave", FEATURE_FXSAVE, P_ZERO, "-mfxsr")
> >
> > I noticed that, one can theoretically use "" for an option that does not
> > have a flag. And NULL for these which have option equal to "-m" + name.
> > Anyway, that's a nit.
> >
> > I support the patch!
> > Martin
> >
> > >
> > > Here is the updated patch.   OK for master?
> > >
> > > Thanks.
> > >
> >
>
> PING:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546522.html
>

PING.

-- 
H.J.

Re: [PATCH] avoid false positives due to compute_objsize (PR 95353)

[Martin Sebor via Gcc-patches]

On 6/16/20 10:13 AM, Jeff Law wrote:

On Mon, 2020-06-15 at 11:10 -0600, Martin Sebor wrote:


That's fine.  Since they are treated as equivalent it shouldn't
matter which of the equivalent alternatives is chosen (there
may be many).  It's the particular choice of the smaller member
that makes it a problem: both in the terms of triggering a false
positive and in terms of the note referencing a member the source
code doesn't use.

If PRE instead picked the bigger member it wouldn't necessarily
trigger the warning.  But if that member was also too small,
the note might still reference the wrong member.

But if PRE picked another equivalent representation not involving
any member at all but rather an offset from the base object (i.e.,
just a MEM_REF) there would be no problem either way: no false
positive, and if it overflowed, the warning wouldn't reference
any member but just the base object.

I'm not sure if this is actually viable from an implementation standpoint.  I'd
have to dig deeply into PRE's implementation to know.  But I suspect anything 
you
suggest in this space that continues relying on the type information in MEM_REFs
is going to be rejected as building on top of a fundamentally flawed foundation.


I'm not sure I understand why you continue to mention type
information or MEM_REF in this context when the problem we're
dealing with is the member in the outer COMPONENT_REF.

I'm also not sure what you mean by fundamentally flawed.  If
we want to continue to consider the member substitution a valid
transformation, then presumably you mean the assumption that
the member in a COMPONENT_REF in GIMPLE refers to the same member
in the source code.  All the late warnings that check accesses
(including -Warray-bounds, -Wstringop-overflow, -Wformat-overflow,
and -Wrestrict) make this basic assumption.

I can also imagine other transformations in the same vein that
could also be considered valid and that would cause false
positives in these contexts.  For instance, given

  struct S { char a[X], b[Y], c[Z]; };

transforming

  p->b[K] and p->c[L]

into

  p->a[X + K] and p->a[X + Y + L].

I'm not sure it was ARRAY_REF or also MEM_REF but I am pretty
sure I've seen something like this happen (was it store merging?)
Either way, if all of these transformations are valid then all
these late warnings are built on the same flawed foundation.


Instead of substituting one member for another in the COMPONENT_REF
when both happen to be accessed at the same offset, using a MEM_REF
alone into the enclosing struct or union plus the offset of
the members would avoid the problem.  Something like this:

Ultimately that's just a bandaid over a flawed implementation.  Fundamentally 
the
problem is the diagnostics should not be depending on the type of those MEM
expressions.  As long as we continue to do that we're going to run into 
problems.
Hence my suggestion we look at attaching suitable type information to the calls
early in the pipeline, possibly at AST generation time.


It's not the MEM_REF type that's a problem here.  The general
issue with the reliability of late warnings like this one also
isn't isolated to just function calls.  Any checked statement
is susceptible to them.

In this case, the problem is that the COMPONENT_REF member is
not the one referenced in the source code.  So more reliable
type information for MEM_REFs wouldn't solve it: we would also
need more reliable COMPONENT_REFs.

I'm not suggesting we have more accurate type information on either of those
*_REF nodes.  Instead I'm suggesting type information get attached to the
statement which uses them.  ie, the call.  If that turns out to work well, we
could look to expand it to other cases.

It's not a new IL.  Not even close.  It's just attaching the original type of
arguments to the call before the optimizers muck it up.


Not type in this case.  The COMPONENT_REF is what would need to
be attached to the statement, referencing the original member.
Or, for things like ARRAY_REF (MEM_REF (...)), the ARRAY_REF.

So every statement would need to maintain two sets of operands:
the original set before the PRE/FRE substitution (and all others
like it), and another after it.  For function calls, that would
mean two sets of arguments.  I imagine both sets of operands
would need to be updated by optimizations to stay in sync (or
be folded).  Yes?

If so, it sounds very involved to me, almost on par with
maintaining a separate IL.  Maybe it's not quite as bad as
that, but it does feel like a whole lot of work to implement
and maintain.  If it isn't, let me know what I'm missing.

Martin

Re: [PATCH 1/6 ver 2] rs6000, Update support for vec_extract

[will schmidt via Gcc-patches]

On Mon, 2020-06-15 at 16:37 -0700, Carl Love via Gcc-patches wrote:
> v2 changes
> 
> config/rs6000/altivec.md log entry for move from changed as
> suggested.
> 
> config/rs6000/vsx.md log entro for moved to here changed as
> suggested.
> 
> define_mode_iterator VI2 also moved, included in both change log
> entries
> 
> 
> GCC maintainers:
> 
> Move the existing vector extract support in altivec.md to vsx.md
> so all of the vector insert and extract support is in the same file.
> 
> The patch also updates the name of the builtins and descriptions for
> the
> builtins in the documentation file so they match the approved builtin
> names and descriptions.
> 
> The patch does not make any functional changes.
> 
> Please let me know if the changes are acceptable.  Thanks.
> 
>   Carl Love
> 
> --
> 
> gcc/ChangeLog
> 
> 2020-06-15  Carl Love  
> 
> * config/rs6000/altivec.md: (UNSPEC_EXTRACTL,
> UNSPEC_EXTRACTR)
>   (vextractl, vextractr)
> (vextractl_internal, vextractr_internal)
>   (VI2): Move to gcc/config/rs6000/vsx.md.
>   * config/rs6000/vsx.md: (UNSPEC_EXTRACTL, UNSPEC_EXTRACTR)
> (vextractl, vextractr)
> (vextractl_internal, vextractr_internal)
>   (VI2): Code was moved from config/rs6000/altivec.md.

Compare the syntax with other patches that move code.  This should be
simplifiable as

* config/rs6000/altivec.md: (UNSPEC_EXTRACTL,
UNSPEC_EXTRACTR)
(vextractl, vextractr)
(vextractl_internal, vextractr_internal)
(VI2): Move to ..
* config/rs6000/vsx.md: (UNSPEC_EXTRACTL, UNSPEC_EXTRACTR)
(vextractl, vextractr)
(vextractl_internal, vextractr_internal)
(VI2): .. here.




>   * gcc/doc/extend.texi: Update documentation for vec_extractl.
>   Replace builtin name vec_extractr with vec_extracth.  Update description
>   of vec_extracth.
> ---
>  gcc/config/rs6000/altivec.md | 64 ---
>  gcc/config/rs6000/vsx.md | 66 
>  gcc/doc/extend.texi  | 73 +---
>  3 files changed, 101 insertions(+), 102 deletions(-)
> 
> diff --git a/gcc/config/rs6000/altivec.md b/gcc/config/rs6000/altivec.md
> index 159f24ebc10..0b0b49ee056 100644
> --- a/gcc/config/rs6000/altivec.md
> +++ b/gcc/config/rs6000/altivec.md
> @@ -171,8 +171,6 @@
> UNSPEC_XXEVAL
> UNSPEC_VSTRIR
> UNSPEC_VSTRIL
> -   UNSPEC_EXTRACTL
> -   UNSPEC_EXTRACTR
>  ])
> 
>  (define_c_enum "unspecv"
> @@ -183,8 +181,6 @@
> UNSPECV_DSS
>])
> 
> -;; Like VI, defined in vector.md, but add ISA 2.07 integer vector ops
> -(define_mode_iterator VI2 [V4SI V8HI V16QI V2DI])
>  ;; Short vec int modes
>  (define_mode_iterator VIshort [V8HI V16QI])
>  ;; Longer vec int modes for rotate/mask ops
> @@ -785,66 +781,6 @@
>DONE;
>  })
> 
> -(define_expand "vextractl"
> -  [(set (match_operand:V2DI 0 "altivec_register_operand")
> - (unspec:V2DI [(match_operand:VI2 1 "altivec_register_operand")
> -   (match_operand:VI2 2 "altivec_register_operand")
> -   (match_operand:SI 3 "register_operand")]
> -  UNSPEC_EXTRACTL))]
> -  "TARGET_FUTURE"
> -{
> -  if (BYTES_BIG_ENDIAN)
> -{
> -  emit_insn (gen_vextractl_internal (operands[0], operands[1],
> -operands[2], operands[3]));
> -  emit_insn (gen_xxswapd_v2di (operands[0], operands[0]));
> -}
> -  else
> -emit_insn (gen_vextractr_internal (operands[0], operands[2],
> -  operands[1], operands[3]));
> -  DONE;
> -})
> -
> -(define_insn "vextractl_internal"
> -  [(set (match_operand:V2DI 0 "altivec_register_operand" "=v")
> - (unspec:V2DI [(match_operand:VEC_I 1 "altivec_register_operand" "v")
> -   (match_operand:VEC_I 2 "altivec_register_operand" "v")
> -   (match_operand:SI 3 "register_operand" "r")]
> -  UNSPEC_EXTRACTL))]
> -  "TARGET_FUTURE"
> -  "vextvlx %0,%1,%2,%3"
> -  [(set_attr "type" "vecsimple")])
> -
> -(define_expand "vextractr"
> -  [(set (match_operand:V2DI 0 "altivec_register_operand")
> - (unspec:V2DI [(match_operand:VI2 1 "altivec_register_operand")
> -   (match_operand:VI2 2 "altivec_register_operand")
> -   (match_operand:SI 3 "register_operand")]
> -  UNSPEC_EXTRACTR))]
> -  "TARGET_FUTURE"
> -{
> -  if (BYTES_BIG_ENDIAN)
> -{
> -  emit_insn (gen_vextractr_internal (operands[0], operands[1],
> -operands[2], operands[3]));
> -  emit_insn (gen_xxswapd_v2di (operands[0], operands[0]));
> -}
> -  else
> -emit_insn (gen_vextractl_internal (operands[0], operands[2],
> -  operands[1], operands[3]));
> -  DONE;
> -})

Re: [PATCH 3/6 ver 2] rs6000, Add vector replace builtin support

[will schmidt via Gcc-patches]

On Mon, 2020-06-15 at 16:37 -0700, Carl Love via Gcc-patches wrote:
> v2 fixes:
> 
> change log entries config/rs6000/vsx.md, config/rs6000/rs6000-builtin.def,
> config/rs6000/rs6000-call.c.
> 
> gcc/config/rs6000/rs6000-call.c: fixed if check for 3rd arg between 0 and 3
>  fixed if check for 3rd arg between 0 and 12
> 
> gcc/config/rs6000/vsx.md: removed REPLACE_ELT_atr definition and used
>   VS_scalar instead.
>   removed REPLACE_ELT_inst definition and used  
> i\
> nstead

bad word break.


>   fixed spelling mistake on Endianness.
>   fixed indenting for vreplace_elt_
> 
> ---
> 
> GCC maintainers:
> 
> The following patch adds support for builtins vec_replace_elt and
> vec_replace_unaligned.
> 
> The patch has been compiled and tested on
> 
>   powerpc64le-unknown-linux-gnu (Power 9 LE)
> 
> and mambo with no regression errors.
> 
> Please let me know if this patch is acceptable for the pu
> branch.  Thanks.

What branch?



> 
>  Carl Love
> 
> ---
> 
> gcc/ChangeLog
> 
> 2020-06-15 Carl Love  
> 
> * config/rs6000/altivec.h: Add define for vec_replace_elt and
> vec_replace_unaligned.
> * config/rs6000/vsx.md (UNSPEC_REPLACE_ELT, UNSPEC_REPLACE_UN): New.
> (REPLACE_ELT): New mode iterator.
> (REPLACE_ELT_atr, REPLACE_ELT_inst, REPLACE_ELT_char,
> REPLACE_ELT_sh, REPLACE_ELT_max): New mode attributes.
> (vreplace_un_, vreplace_elt__inst): New.
> * config/rs6000/rs6000-builtin.def (VREPLACE_ELT_V4SI, 
> VREPLACE_ELT_UV4\
> SI,
> VREPLACE_ELT_V4SF, VREPLACE_ELT_UV2DI, VREPLACE_ELT_V2DF,
> VREPLACE_UN_V4SI, VREPLACE_UN_UV4SI, VREPLACE_UN_V4SF,
> VREPLACE_UN_V2DI, VREPLACE_UN_UV2DI, VREPLACE_UN_V2DF): New.
> (REPLACE_ELT, REPLACE_UN): New.
> * config/rs6000/rs6000-call.c (FUTURE_BUILTIN_VEC_REPLACE_ELT,
> FUTURE_BUILTIN_VEC_REPLACE_UN): New.
> (rs6000_expand_ternop_builtin): Add 3rd argument checks for
> CODE_FOR_vreplace_elt_v4si, CODE_FOR_vreplace_elt_v4sf,
> CODE_FOR_vreplace_un_v4si, CODE_FOR_vreplace_un_v4sf.
> (builtin_function_type) [FUTURE_BUILTIN_VREPLACE_ELT_UV4SI, 
> FUTURE_BUIL\
> TIN_VREPLACE_ELT_UV2DI,
> FUTURE_BUILTIN_VREPLACE_UN_UV4SI, FUTURE_BUILTIN_VREPLACE_UN_UV2DI]: 
> Ne\
> w cases.


Multiple bad wordbreaks.


> * doc/extend.texi: Add description for vec_replace_elt and
> vec_replace_unaligned builtins.
> 
> 
> gcc/testsuite/ChangeLog
> 
> 2020-06-15 Carl Love  
> * gcc.target/powerpc/vec-replace-word.c: Add new test.
> ---
>  gcc/config/rs6000/altivec.h   |   2 +
>  gcc/config/rs6000/rs6000-builtin.def  |  16 +
>  gcc/config/rs6000/rs6000-call.c   |  61 
>  gcc/config/rs6000/vsx.md  |  60 
>  gcc/doc/extend.texi   |  50 +++
>  .../powerpc/vec-replace-word-runnable.c   | 289 ++
>  6 files changed, 478 insertions(+)
>  create mode 100644 
> gcc/testsuite/gcc.target/powerpc/vec-replace-word-runnable.c
> 
> diff --git a/gcc/config/rs6000/altivec.h b/gcc/config/rs6000/altivec.h
> index 936aeb1ee09..435ffb8158f 100644
> --- a/gcc/config/rs6000/altivec.h
> +++ b/gcc/config/rs6000/altivec.h
> @@ -701,6 +701,8 @@ __altivec_scalar_pred(vec_any_nle,
>  #define vec_extracth(a, b, c)__builtin_vec_extracth (a, b, c)
>  #define vec_insertl(a, b, c)   __builtin_vec_insertl (a, b, c)
>  #define vec_inserth(a, b, c)   __builtin_vec_inserth (a, b, c)
> +#define vec_replace_elt(a, b, c)   __builtin_vec_replace_elt (a, b, c)
> +#define vec_replace_unaligned(a, b, c) __builtin_vec_replace_un (a, b, c)
> 

I don't think the parms are necessary unless there is remapping going
on.  But existing nearby content has them, so match the existing style,
i guess.  :-)


>  #define vec_gnb(a, b)__builtin_vec_gnb (a, b)
>  #define vec_clrl(a, b)   __builtin_vec_clrl (a, b)
> diff --git a/gcc/config/rs6000/rs6000-builtin.def 
> b/gcc/config/rs6000/rs6000-builtin.def
> index c5bd4f86555..91821f29a6f 100644
> --- a/gcc/config/rs6000/rs6000-builtin.def
> +++ b/gcc/config/rs6000/rs6000-builtin.def
> @@ -2643,6 +2643,20 @@ BU_FUTURE_V_3 (VINSERTVPRBR, "vinsvubvrx", CONST, 
> vinsertvr_v16qi)
>  BU_FUTURE_V_3 (VINSERTVPRHR, "vinsvuhvrx", CONST, vinsertvr_v8hi)
>  BU_FUTURE_V_3 (VINSERTVPRWR, "vinsvuwvrx", CONST, vinsertvr_v4si)
> 
> +BU_FUTURE_V_3 (VREPLACE_ELT_V4SI, "vreplace_v4si", CONST, vreplace_elt_v4si)
> +BU_FUTURE_V_3 (VREPLACE_ELT_UV4SI, "vreplace_uv4si", CONST, 
> vreplace_elt_v4si)
> +BU_FUTURE_V_3 (VREPLACE_ELT_V4SF, "vreplace_v4sf", CONST, vreplace_elt_v4sf)
> +BU_FUTURE_V_3 (VREPLACE_ELT_V2DI, "vreplace_v2di", CONST, vreplace_elt_v2di)
> +BU_FUTURE_V_3 (VREPLACE_ELT_UV2DI, 

[pushed] PR tree-optimization/95649: Fix pasto in the substitute_and_fold_engine merge with evrp.

[Aldy Hernandez via Gcc-patches]

The original code only propagated into PHI arguments if the value was a 
constant.  This behavior was lost in the conversion, allowing any value 
(SSAs for instance) to be propagated into PHIs.


Pre-approved by Jeff in the PR.

Aldy
commit 8fb4d1d58362b77da78c09740c6b5562124a369e
Author: Aldy Hernandez 
Date:   Tue Jun 16 13:43:57 2020 +0200

Fix pasto in the substitute_and_fold_engine merge with evrp.

The original code only propagated into PHI arguments if the value was
a constant.  This behavior was lost in the conversion, allowing
any value (SSAs for instance) to be propagated into PHIs.

gcc/ChangeLog:

PR tree-optimization/95649
* tree-ssa-propagate.c (propagate_into_phi_args): Do not propagate unless
value is a constant.

gcc/testsuite/ChangeLog:

* g++.dg/tree-ssa/pr95649.C: New test.
* gcc.dg/tree-ssa/pr95649.c: New test.

diff --git a/gcc/testsuite/g++.dg/tree-ssa/pr95649.C b/gcc/testsuite/g++.dg/tree-ssa/pr95649.C
new file mode 100644
index 000..139f699ee2e
--- /dev/null
+++ b/gcc/testsuite/g++.dg/tree-ssa/pr95649.C
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+extern unsigned short var_5;
+extern int var_8, var_9;
+extern short arr_7[];
+void test() {
+  for (; 0 < (char)var_5;)
+for (int a(var_9 ? var_5 : 0); a < 3002972621U + 1291994699;
+ a += 19499 - 19497)
+  for (long b(var_8); b; b += 4)
+arr_7[a * b] = 0;
+}
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr95649.c b/gcc/testsuite/gcc.dg/tree-ssa/pr95649.c
new file mode 100644
index 000..cc9b7640c19
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr95649.c
@@ -0,0 +1,21 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fno-tree-scev-cprop" } */
+
+char b (void);
+char *d;
+int e;
+int f;
+void
+g (char *h)
+{
+  while (d)
+{
+  long i = b ();
+  if (h + i > d)
+	break;
+  if (f > 0 || e)
+	do
+	  *h++ = *h;
+	while (--i);
+}
+}
diff --git a/gcc/tree-ssa-propagate.c b/gcc/tree-ssa-propagate.c
index 4fda296ef9e..01ee7fd33eb 100644
--- a/gcc/tree-ssa-propagate.c
+++ b/gcc/tree-ssa-propagate.c
@@ -1035,7 +1035,8 @@ substitute_and_fold_engine::propagate_into_phi_args (basic_block bb)
 	  || virtual_operand_p (arg))
 	continue;
 	  tree val = get_value (arg, phi);
-	  if (val && may_propagate_copy (arg, val))
+	  if (val && is_gimple_min_invariant (val)
+	  && may_propagate_copy (arg, val))
 	propagate_value (use_p, val);
 	}
 }

Re: [PATCH 1/3] rs6000: Add base support and types for defining MMA built-ins.

[Peter Bergner via Gcc-patches]

On 6/15/20 5:43 PM, will schmidt wrote:
> On Mon, 2020-06-15 at 14:56 -0500, Peter Bergner via Gcc-patches wrote:
>>  * config/rs6000/rs6000-cpus.def (OTHER_FUTURE_MASKS): Add
>>  OPTION_MASK_MMA.
>>  (POWERPC_MASKS): Likewise.
> 
> Don't see POWERPC_MASKS in the patch here.

It's this hunk:

 /* Support for a future processor's features.  */
@@ -132,6 +133,7 @@
 | OPTION_MASK_HTM  \
 | OPTION_MASK_ISEL \
 | OPTION_MASK_MFCRF\
+| OPTION_MASK_MMA  \
 | OPTION_MASK_MODULO   \
 | OPTION_MASK_MULHW\
 | OPTION_MASK_NO_UPDATE\




>> +;; Vector load/store pair operations
> 
> Probably clear later on.  First blush and first pass a blurb here to
> clarify MMA, and what the modes are may be useful.
> 
> The subsection paragraph from the extend.texi may be a good fit).
[snip]
>> +;; We need to define an OImode move pattern, even though we don't
>> enable it,
>> +;; because the machine independent parts of the compiler at times
>> uses the
>> +;; large integer modes.
>> +;;
>> +;; If we enable movoi, the compiler will try and use
>> it.  Unfortunately, if it
>> +;; is enabled, it will cause problems on little endian systems with
>> code that
>> +;; uses the vector_size attribute, due to endian issues.
> 
> So, maybe rearrange as two lines?
> 
> Define a (disabled) OImode move pattern so the machine independent
> parts of the compare can use the large integer modes.
> FIXME: If the OImove pattern is enabled, LE systems will have problems
> with the vector_size attribute.

Ok, I'll take a stab at rewording this.


>> +(define_expand "movoi"
>> +  [(set (match_operand:OI 0 "nonimmediate_operand")
>> +(match_operand:OI 1 "input_operand"))]
>> +  "0"
>> +{
>> +  gcc_unreachable ();
>> +})
> 
> Is it the "0" or the _unreachable() that 'disables' this? 

It's the "0" condition flag that disables it.  The gcc_unreachable() call
is just used to verify we never do.


Peter

Re: [PATCH 2/3] rs6000: Add MMA built-in function definitions

[Peter Bergner via Gcc-patches]

On 6/15/20 5:43 PM, will schmidt wrote:
> checked noses, all have been found below. 

Thanks for verifying!


>>  * config/rs6000/rs6000.md ('type' attribute): Add mma type.
> 
> (mma) : New 'type' attribute.

I just copied what someone else did, but agree this is more readable.
Will change.



> I've read through the rest of this patch.  nothing else jumps out at me. 
Thanks

Peter

Re: [PATCH] avoid false positives due to compute_objsize (PR 95353)

[Martin Sebor via Gcc-patches]

On 6/16/20 3:33 AM, Richard Biener wrote:

On Mon, Jun 15, 2020 at 7:11 PM Martin Sebor via Gcc-patches
 wrote:


On 6/14/20 12:37 PM, Jeff Law wrote:

On Sat, 2020-06-13 at 17:49 -0600, Martin Sebor wrote:

On 6/13/20 3:50 PM, Sandra Loosemore wrote:

On 6/2/20 6:12 PM, Martin Sebor via Gcc-patches wrote:

The compute_objsize() function started out as a thin wrapper around
compute_builtin_object_size(), but over time developed its own
features to compensate for the other function's limitations (such
as its inability to work with ranges).  The interaction of these
features and the limitations has started to become increasingly
problematic as the former function is used in more contexts.

A complete "fix" for all the problems (as well as some other
limitations) that I'm working on will be more extensive and won't
be appropriate for backports.  Until then, the attached patch
cleans up the extensions compute_objsize() has accumulated over
the years to avoid a class of false positives.

To make the warnings issued based on the results of the function
easier to understand and fix, the patch also adds an informative
message to many instances of -Wstringop-overflow to point to
the object to which the warning refers.  This is especially
helpful when the object is referenced by a series of pointer
operations.

Tested by boostrapping on x86_64-linux and building Binutils/GDB,
Glibc, and the Linux kernel with no new warnings.

Besides applying it to trunk I'm looking to backport the fix to
GCC 10.


This patch (commit a2c2cee92e5defff9bf23d3b1184ee96e57e5fdd) has broken
glibc builds on nios2-linux-gnu, when building sysdeps/posix/getaddrinfo.c:

../sysdeps/posix/getaddrinfo.c: In function 'gaih_inet.constprop':
../sysdeps/posix/getaddrinfo.c:1081:3: error: 'memcpy' writing 16 bytes
into a region of size 8 overflows the destination
[-Werror=stringop-overflow=]
1081 |   memcpy (&sin6p->sin6_addr,
 |   ^~
1082 |at2->addr, sizeof (struct in6_addr));
 |
In file included from ../include/netinet/in.h:3,
from ../resolv/bits/types/res_state.h:5,
from ../include/bits/types/res_state.h:1,
from ../nptl/descr.h:35,
from ../sysdeps/nios2/nptl/tls.h:45,
from ../sysdeps/generic/libc-tsd.h:44,
from ../include/../locale/localeinfo.h:224,
from ../include/ctype.h:26,
from ../sysdeps/posix/getaddrinfo.c:57:
../inet/netinet/in.h:249:19: note: destination object 'sin_zero'
 249 | unsigned char sin_zero[sizeof (struct sockaddr)
 |   ^~~~


I have to say that I don't understand the "note" diagnostic here at all.
:-(  Why does it think the destination object is a field of struct
sockaddr_in, while this memcpy is filling in a field of struct
sockaddr_in6?  (And, the sin6_addr field is indeed of type struct
in6_addr, matching the sizeof expression.)


Most likely because some earlier pass (from my exchange with Jeff
about this instance of the warning I suspect it's PRE) substitutes
one member for the other in the IL when offsets into them happen
to evaluate to the same offset from the start of the enclosing
object.  The Glibc code does this:

Yes, this is the same issue we were discussing privately.



  struct sockaddr_in6 *sin6p =
(struct sockaddr_in6 *) ai->ai_addr;

  sin6p->sin6_port = st2->port;
  sin6p->sin6_flowinfo = 0;
  memcpy (&sin6p->sin6_addr,
  at2->addr, sizeof (struct in6_addr));

and the warning doesn't see sin6p->sin6_addr as the destination
but something like

 &MEM  [(void *)ai_10 + 4B].sin_zero;

The details in this and all other middle end warnings are only as
reliable as the IL they work with.  If the IL that doesn't correspond
to the original source code they're going to be confusing (and may
trigger false positives).

True, but the transformation done by PRE is valid.  PRE is concerned only with
value equivalences and the two addresses are the same and PRE can and will
replace one with the other.


That's fine.  Since they are treated as equivalent it shouldn't
matter which of the equivalent alternatives is chosen (there
may be many).  It's the particular choice of the smaller member
that makes it a problem: both in the terms of triggering a false
positive and in terms of the note referencing a member the source
code doesn't use.

If PRE instead picked the bigger member it wouldn't necessarily
trigger the warning.  But if that member was also too small,
the note might still reference the wrong member.

But if PRE picked another equivalent representation not involving
any member at all but rather an offset from the base object (i.e.,
just a MEM_REF) there would be no problem either way: no false
positive, and if it overflowed, the warning wouldn'

Re: [PATCH 2/6 ver 2] rs6000 Add vector insert builtin support

[will schmidt via Gcc-patches]

On Mon, 2020-06-15 at 16:37 -0700, Carl Love via Gcc-patches wrote:
> v2 changes
> 
> Fix change log entry for config/rs6000/altivec.h
> 
> Fix change log entry for config/rs6000/rs6000-builtin.def
> 
> Fix change log entry for config/rs6000/rs6000-call.c
> 
> vsx.md: Fixed if (BYTES_BIG_ENDIAN) else statements.
> Porting error from pu branch.
> 
> ---
> GCC maintainers:
> 
> This patch adds support for vec_insertl and vec_inserth builtins.
> 
> The patch has been compiled and tested on
> 
>   powerpc64le-unknown-linux-gnu (Power 9 LE)
> 
> and mambo with no regression errors.
> 
> Please let me know if this patch is acceptable for the mainline branch.
> 
> Thanks.
> 
>  Carl Love
> 
> --
> gcc/ChangeLog
> 
> 2020-06-15  Carl Love  
> 
> * config/rs6000/altivec.h (vec_insertl, vec_inserth): New defines.

tabs/spaces.

>   * config/rs6000/rs6000-builtin.def (VINSERTGPRBL, VINSERTGPRHL,
>   VINSERTGPRWL, VINSERTGPRDL, VINSERTVPRBL, VINSERTVPRHL, VINSERTVPRWL,
>   VINSERTGPRBR, VINSERTGPRHR, VINSERTGPRWR, VINSERTGPRDR, VINSERTVPRBR,
>   VINSERTVPRHR, VINSERTVPRWR): New builtins.
>   (INSERTL, INSERTH): New builtins.
>   * config/rs6000/rs6000-call.c (FUTURE_BUILTIN_VEC_INSERTL,
>   FUTURE_BUILTIN_VEC_INSERTH):  New Overloaded definitions.
>   (FUTURE_BUILTIN_VINSERTGPRBL, FUTURE_BUILTIN_VINSERTGPRHL,
>   FUTURE_BUILTIN_VINSERTGPRWL, FUTURE_BUILTIN_VINSERTGPRDL,
>   FUTURE_BUILTIN_VINSERTVPRBL, FUTURE_BUILTIN_VINSERTVPRHL,
>   FUTURE_BUILTIN_VINSERTVPRWL): Add case entries.
>   * config/rs6000/vsx.md (define_c_enum): Add UNSPEC_INSERTL,
>   UNSPEC_INSERTR.
>   (define_expand): Add vinsertvl_, vinsertvr_,
>   vinsertgl_, vinsertgr_, mode is VI2.
>   (define_ins): vinsertvl_internal_, vinsertvr_internal_,
>   vinsertgl_internal_, vinsertgr_internal_, mode VEC_I.
>   * doc/extend.texi: Add documentation for vec_insertl, vec_inserth.
> 
> gcc/testsuite/ChangeLog
> 
> 2020-06-15  Carl Love  
> 
>   * gcc.target/powerpc/vec-insert-word-runnable.c: New
>   test case.
> ---
>  gcc/config/rs6000/altivec.h   |   2 +
>  gcc/config/rs6000/rs6000-builtin.def  |  18 +
>  gcc/config/rs6000/rs6000-call.c   |  51 +++
>  gcc/config/rs6000/vsx.md  | 110 ++
>  gcc/doc/extend.texi   |  73 
>  .../powerpc/vec-insert-word-runnable.c| 345 ++
>  6 files changed, 599 insertions(+)
>  create mode 100644 
> gcc/testsuite/gcc.target/powerpc/vec-insert-word-runnable.c
> 
> diff --git a/gcc/config/rs6000/altivec.h b/gcc/config/rs6000/altivec.h
> index 0a7e8ab3647..936aeb1ee09 100644
> --- a/gcc/config/rs6000/altivec.h
> +++ b/gcc/config/rs6000/altivec.h
> @@ -699,6 +699,8 @@ __altivec_scalar_pred(vec_any_nle,
>  /* Overloaded built-in functions for future architecture.  */
>  #define vec_extractl(a, b, c)__builtin_vec_extractl (a, b, c)
>  #define vec_extracth(a, b, c)__builtin_vec_extracth (a, b, c)
> +#define vec_insertl(a, b, c)   __builtin_vec_insertl (a, b, c)
> +#define vec_inserth(a, b, c)   __builtin_vec_inserth (a, b, c)
> 
>  #define vec_gnb(a, b)__builtin_vec_gnb (a, b)
>  #define vec_clrl(a, b)   __builtin_vec_clrl (a, b)
> diff --git a/gcc/config/rs6000/rs6000-builtin.def 
> b/gcc/config/rs6000/rs6000-builtin.def
> index 8b1ddb00045..c5bd4f86555 100644
> --- a/gcc/config/rs6000/rs6000-builtin.def
> +++ b/gcc/config/rs6000/rs6000-builtin.def
> @@ -2627,6 +2627,22 @@ BU_FUTURE_V_3 (VEXTRACTHR, "vextduhvhx", CONST, 
> vextractrv8hi)
>  BU_FUTURE_V_3 (VEXTRACTWR, "vextduwvhx", CONST, vextractrv4si)
>  BU_FUTURE_V_3 (VEXTRACTDR, "vextddvhx", CONST, vextractrv2di)
> 
> +BU_FUTURE_V_3 (VINSERTGPRBL, "vinsgubvlx", CONST, vinsertgl_v16qi)
> +BU_FUTURE_V_3 (VINSERTGPRHL, "vinsguhvlx", CONST, vinsertgl_v8hi)
> +BU_FUTURE_V_3 (VINSERTGPRWL, "vinsguwvlx", CONST, vinsertgl_v4si)
> +BU_FUTURE_V_3 (VINSERTGPRDL, "vinsgudvlx", CONST, vinsertgl_v2di)
> +BU_FUTURE_V_3 (VINSERTVPRBL, "vinsvubvlx", CONST, vinsertvl_v16qi)
> +BU_FUTURE_V_3 (VINSERTVPRHL, "vinsvuhvlx", CONST, vinsertvl_v8hi)
> +BU_FUTURE_V_3 (VINSERTVPRWL, "vinsvuwvlx", CONST, vinsertvl_v4si)
> +
> +BU_FUTURE_V_3 (VINSERTGPRBR, "vinsgubvrx", CONST, vinsertgr_v16qi)
> +BU_FUTURE_V_3 (VINSERTGPRHR, "vinsguhvrx", CONST, vinsertgr_v8hi)
> +BU_FUTURE_V_3 (VINSERTGPRWR, "vinsguwvrx", CONST, vinsertgr_v4si)
> +BU_FUTURE_V_3 (VINSERTGPRDR, "vinsgudvrx", CONST, vinsertgr_v2di)
> +BU_FUTURE_V_3 (VINSERTVPRBR, "vinsvubvrx", CONST, vinsertvr_v16qi)
> +BU_FUTURE_V_3 (VINSERTVPRHR, "vinsvuhvrx", CONST, vinsertvr_v8hi)
> +BU_FUTURE_V_3 (VINSERTVPRWR, "vinsvuwvrx", CONST, vinsertvr_v4si)
> +
>  BU_FUTURE_V_1 (VSTRIBR, "vstribr", CONST, vstrir_v16qi)
>  BU_FUTURE_V_1 (VSTRIHR, "vstrihr", CONST, vstrir_v8hi)
>  BU_FUTURE_V_1 (VSTRIBL, "

[PATCH] PR fortran/95688 - ICE in gfc_get_string, at fortran/iresolve.c:70

[Harald Anlauf]

Here's an almost obvious one on a testcase by Gerhard, which triggered
an internal error since the buffer size was checked.  By looking at the
format string and arguments used in name mangling, I decided to stick
with the simple approach of using a fixed size buffer, but larger.

Regtested on x86_64-pc-linux-gnu, along with the fixes for similar bugs
(PRs 95687, 95689).

OK for trunk?  Backport if suitable?

Thanks,
Harald


PR fortran/95688 - ICE in gfc_get_string, at fortran/iresolve.c:70

With submodules, name mangling of character pointer declarations produces long
internal symbols that overflowed a static internal buffer.  Adjust the buffer
size.

gcc/fortran/
PR fortran/95688
* iresolve.c (gfc_get_string): Enlarge static buffer size.
diff --git a/gcc/fortran/iresolve.c b/gcc/fortran/iresolve.c
index df4f2265c58..aa9bb328a0f 100644
--- a/gcc/fortran/iresolve.c
+++ b/gcc/fortran/iresolve.c
@@ -47,8 +47,8 @@ along with GCC; see the file COPYING3.  If not see
 const char *
 gfc_get_string (const char *format, ...)
 {
-  /* Provide sufficient space to hold "_F.caf_token__symbol_MOD_symbol".  */
-  char temp_name[14 + GFC_MAX_SYMBOL_LEN + 5 + GFC_MAX_SYMBOL_LEN + 1];
+  /* Provide sufficient space to hold "_F.symbol.symbol_MOD_symbol".  */
+  char temp_name[4 + 2*GFC_MAX_SYMBOL_LEN + 5 + GFC_MAX_SYMBOL_LEN + 1];
   const char *str;
   va_list ap;
   tree ident;
diff --git a/gcc/testsuite/gfortran.dg/pr95688.f90 b/gcc/testsuite/gfortran.dg/pr95688.f90
new file mode 100644
index 000..ce8fd3e9890
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr95688.f90
@@ -0,0 +1,15 @@
+! { dg-do compile }
+! { dg-options "-fsecond-underscore" }
+! PR fortran/95688 - ICE in gfc_get_string, at fortran/iresolve.c:70
+
+module m2345678901234567890123456789012345678901234567890123456789_123
+  interface
+ module subroutine s2345678901234567890123456789012345678901234567890123456789_123
+ end
+  end interface
+end
+submodule(m2345678901234567890123456789012345678901234567890123456789_123) &
+  n2345678901234567890123456789012345678901234567890123456789_123
+  character(:), pointer :: &
+  x2345678901234567890123456789012345678901234567890123456789_123 => null()
+end

Re: [PATCH 4/6 ver 2] rs6000, Add vector shift double builtin support

[will schmidt via Gcc-patches]

On Mon, 2020-06-15 at 16:38 -0700, Carl Love via Gcc-patches wrote:
> v2 fixes:
> 
>  change logs redone
> 
>   gcc/config/rs6000/rs6000-call.c - added spaces before parenthesis around 
> args.
> 
> -
> GCC maintainers:
> 
> The following patch adds support for the vector shift double builtins
> for RFC2609.

The RFC # reference is likely meaningless outside of the blue walls.  


> 
> The patch has been compiled and tested on
> 
>   powerpc64le-unknown-linux-gnu (Power 9 LE)
> 
> and Mambo with no regression errors.
> 
> Please let me know if this patch is acceptable for the pu
> branch.  Thanks.

There is no pu branch?

> 
>  Carl Love
> 
> ---
> 
> gcc/ChangeLog
> 
> 2020-06-15  Carl Love  
> 
> * config/rs6000/altivec.h (vec_sldb and vec_srdb): New defines.

s/and/,/

> * config/rs6000/altivec.md (UNSPEC_SLDB, UNSPEC_SRDB): New.
> (SLDB_LR attribute): New.
 (SLDB_LR): New attribute.

> (VSHIFT_DBL_LR iterator): New.

(VSHIFT_DBL_LR): New iterator.

> (vsdb_): New define_insn.

> * config/rs6000/rs6000-builtin.def (VSLDB_V16QI, VSLDB_V8HI,
>   VSLDB_V4SI, VSLDB_V2DI, VSRDB_V16QI, VSRDB_V8HI, VSRDB_V4SI,
>   VSRDB_V2DI): New BU_FUTURE_V_3 definitions.
> (SLDB, SRDB): New BU_FUTURE_OVERLOAD_3 definitions.
> * config/rs6000/rs6000-call.c (FUTURE_BUILTIN_VEC_SLDB,
>   FUTURE_BUILTIN_VEC_SRDB): New definitions.
> (rs6000_expand_ternop_builtin) [CODE_FOR_vsldb_v16qi,
>   CODE_FOR_vsldb_v8hi, CODE_FOR_vsldb_v4si, CODE_FOR_vsldb_v2di,
>   CODE_FOR_vsrdb_v16qi, CODE_FOR_vsrdb_v8hi, CODE_FOR_vsrdb_v4si,
>   CODE_FOR_vsrdb_v2di}: Add else if clauses.

s/else if//

> * doc/extend.texi: Add description for vec_sldb and vec_srdb.

spaces/tabs throughout changelog.

> 
> gcc/testsuite/ChangeLog
> 
> 2020-06-15  Carl Love  
>   * gcc.target/powerpc/vec-shift-double-runnable.c:  New test file.
> ---
>  gcc/config/rs6000/altivec.h   |   2 +
>  gcc/config/rs6000/altivec.md  |  18 +
>  gcc/config/rs6000/rs6000-builtin.def  |  11 +
>  gcc/config/rs6000/rs6000-call.c   |  70 
>  gcc/doc/extend.texi   |  53 +++
>  .../powerpc/vec-shift-double-runnable.c   | 384 ++
>  6 files changed, 538 insertions(+)
>  create mode 100644 
> gcc/testsuite/gcc.target/powerpc/vec-shift-double-runnable.c
> 
> diff --git a/gcc/config/rs6000/altivec.h b/gcc/config/rs6000/altivec.h
> index 435ffb8158f..0be68892aad 100644
> --- a/gcc/config/rs6000/altivec.h
> +++ b/gcc/config/rs6000/altivec.h
> @@ -703,6 +703,8 @@ __altivec_scalar_pred(vec_any_nle,
>  #define vec_inserth(a, b, c)   __builtin_vec_inserth (a, b, c)
>  #define vec_replace_elt(a, b, c)   __builtin_vec_replace_elt (a, b, c)
>  #define vec_replace_unaligned(a, b, c) __builtin_vec_replace_un (a, b, c)
> +#define vec_sldb(a, b, c)  __builtin_vec_sldb (a, b, c)
> +#define vec_srdb(a, b, c)  __builtin_vec_srdb (a, b, c)
> 
>  #define vec_gnb(a, b)__builtin_vec_gnb (a, b)
>  #define vec_clrl(a, b)   __builtin_vec_clrl (a, b)

ok.  

> diff --git a/gcc/config/rs6000/altivec.md b/gcc/config/rs6000/altivec.md
> index 0b0b49ee056..832a35cdaa9 100644
> --- a/gcc/config/rs6000/altivec.md
> +++ b/gcc/config/rs6000/altivec.md
> @@ -171,6 +171,8 @@
> UNSPEC_XXEVAL
> UNSPEC_VSTRIR
> UNSPEC_VSTRIL
> +   UNSPEC_SLDB
> +   UNSPEC_SRDB
>  ])
> 
>  (define_c_enum "unspecv"
> @@ -781,6 +783,22 @@
>DONE;
>  })
> 
> +;; Map UNSPEC_SLDB to "l" and  UNSPEC_SRDB to "r".
> +(define_int_attr SLDB_LR [(UNSPEC_SLDB "l")
> +   (UNSPEC_SRDB "r")])
> +
> +(define_int_iterator VSHIFT_DBL_LR [UNSPEC_SLDB UNSPEC_SRDB])
> +
> +(define_insn "vsdb_"
> + [(set (match_operand:VI2 0 "register_operand" "=v")
> +  (unspec:VI2 [(match_operand:VI2 1 "register_operand" "v")
> +(match_operand:VI2 2 "register_operand" "v")
> +(match_operand:QI 3 "const_0_to_12_operand" "n")]
> +   VSHIFT_DBL_LR))]
> +  "TARGET_FUTURE"
> +  "vsdbi %0,%1,%2,%3"
> +  [(set_attr "type" "vecsimple")])
> +
>  (define_expand "vstrir_"
>[(set (match_operand:VIshort 0 "altivec_register_operand")
>   (unspec:VIshort [(match_operand:VIshort 1 "altivec_register_operand")]

ok

> diff --git a/gcc/config/rs6000/rs6000-builtin.def 
> b/gcc/config/rs6000/rs6000-builtin.def
> index 91821f29a6f..2b198177ef0 100644
> --- a/gcc/config/rs6000/rs6000-builtin.def
> +++ b/gcc/config/rs6000/rs6000-builtin.def
> @@ -2657,6 +2657,15 @@ BU_FUTURE_V_3 (VREPLACE_UN_V2DI, "vreplace_un_v2di", 
> CONST, vreplace_un_v2di)
>  BU_FUTURE_V_3 (VREPLACE_UN_UV2DI, "vreplace_un_uv2di", CONST, 
> vreplace_un_v2di)
>  BU_FUTURE_V_3 (VREPLACE_UN_V2DF, "vreplace_un_v2df", CONST, vreplace_un_v2df)
> 
> +BU_FUTURE_V_3 (VSLDB_V16QI, "vsldb_v16qi", CONST, vsldb

Re: [PATCH 5/6 ver 2] rs6000, Add vector splat builtin support

[will schmidt via Gcc-patches]

On Mon, 2020-06-15 at 16:38 -0700, Carl Love via Gcc-patches wrote:
> v2 changes:  
> 
> change log fixes
> 
> gcc/config/rs6000/altivec changed name of define_insn and define_expand
> for vxxspltiw... to xxspltiw...   Fixed spaces in 
> gen_xxsplti32dx_v4sf_inst (operands[0], GEN_INT
> 
> gcc/rs6000-builtin.def propagated name changes above where they are used.
> 
> Updated definition for S32bit_cint_operand, c32bit_cint_operand,
> f32bit_const_operand predicate definitions.
> 
> Changed name of rs6000_constF32toI32 to rs6000_const_f32_to_i32, 
> propagated
> name change as needed.  Replaced if test with gcc_assert().
> 
> Fixed description of vec_splatid() in documentation.

Probably easier to read if you place the 'changes from previous patch' 
below the patch introduction.


> ---
> 
> GCC maintainers:
> 
> The following patch adds support for the vec_splati, vec_splatid and
> vec_splati_ins builtins.
> 
> Note, this patch adds support for instructions that take a 32-bit immediate
> value that represents a floating point value.  This support adds new
> predicates and a support function to properly handle the immediate value.

s/Note//.

> 
> The patch has been compiled and tested on
> 
>   powerpc64le-unknown-linux-gnu (Power 9 LE)
> 
> with no regression errors.
> 
> The test case was compiled on a Power 9 system and then tested on
> Mambo.
> 
> Please let me know if this patch is acceptable for the pu
> branch.  Thanks.

Which branch?



> 
>  Carl Love
> 
> gcc/ChangeLog
> 
> 2020-06-15  Carl Love  
> 
> * config/rs6000/altivec.h (vec_splati, vec_splatid, vec_splati_ins):
>   Add defines.
> * config/rs6000/altivec.md (UNSPEC_XXSPLTIW, UNSPEC_XXSPLTID,
>   UNSPEC_XXSPLTI32DX): New.
> (vxxspltiw_v4si, vxxspltiw_v4sf_inst, vxxspltidp_v2df_inst,
>   vxxsplti32dx_v4si_inst, vxxsplti32dx_v4sf_inst): New define_insn.
> (vxxspltiw_v4sf, vxxspltidp_v2df, vxxsplti32dx_v4si,
>   vxxsplti32dx_v4sf.): New define_expands.
> * config/rs6000/predicates (u1bit_cint_operand,
> s32bit_cint_operand, c32bit_cint_operand,
>   f32bit_const_operand): New predicates.
> * config/rs6000/rs6000-builtin.def (VXXSPLTIW_V4SI, VXXSPLTIW_V4SF,
>VXXSPLTID): NewBU_FUTURE_V_1 definitions.

NewBU_FUTURE_V_1 ? 


> (VXXSPLTI32DX_V4SI, VXXSPLTI32DX_V4SF): New BU_FUTURE_V_3
>   definitions.
> (XXSPLTIW, XXSPLTID): New BU_FUTURE_OVERLOAD_1 definitions.

seems to be a typo

> (XXSPLTI32DX): Add BU_FUTURE_OVERLOAD_3 definition.

> * config/rs6000/rs6000-call.c (FUTURE_BUILTIN_VEC_XXSPLTIW,
>   FUTURE_BUILTIN_VEC_XXSPLTID, FUTURE_BUILTIN_VEC_XXSPLTI32DX):
>   New definitions.
> * config/rs6000/rs6000-protos.h (rs6000_constF32toI32): New extern
>   declaration.
> * config/rs6000/rs6000.c (rs6000_constF32toI32): New function.
> * config/doc/extend.texi: Add documentation for vec_splati,
>   vec_splatid, and vec_splati_ins.

tabs/spaces.



THanks,
-WIll


> gcc/testsuite/ChangeLog
> 
> 2020-06-15  Carl Love  
> 
> * testsuite/gcc.target/powerpc/vec-splati-runnable: New test.
> ---
>  gcc/config/rs6000/altivec.h   |   3 +
>  gcc/config/rs6000/altivec.md  | 109 +
>  gcc/config/rs6000/predicates.md   |  33 
>  gcc/config/rs6000/rs6000-builtin.def  |  13 ++
>  gcc/config/rs6000/rs6000-call.c   |  19 +++
>  gcc/config/rs6000/rs6000-protos.h |   1 +
>  gcc/config/rs6000/rs6000.c|  11 ++
>  gcc/doc/extend.texi   |  35 +
>  .../gcc.target/powerpc/vec-splati-runnable.c  | 145 ++
>  9 files changed, 369 insertions(+)
>  create mode 100644 gcc/testsuite/gcc.target/powerpc/vec-splati-runnable.c
> 
> diff --git a/gcc/config/rs6000/altivec.h b/gcc/config/rs6000/altivec.h
> index 0be68892aad..9ed41b1cbf1 100644
> --- a/gcc/config/rs6000/altivec.h
> +++ b/gcc/config/rs6000/altivec.h
> @@ -705,6 +705,9 @@ __altivec_scalar_pred(vec_any_nle,
>  #define vec_replace_unaligned(a, b, c) __builtin_vec_replace_un (a, b, c)
>  #define vec_sldb(a, b, c)  __builtin_vec_sldb (a, b, c)
>  #define vec_srdb(a, b, c)  __builtin_vec_srdb (a, b, c)
> +#define vec_splati(a)  __builtin_vec_xxspltiw (a)
> +#define vec_splatid(a) __builtin_vec_xxspltid (a)
> +#define vec_splati_ins(a, b, c)__builtin_vec_xxsplti32dx (a, b, c)
> 
>  #define vec_gnb(a, b)__builtin_vec_gnb (a, b)
>  #define vec_clrl(a, b)   __builtin_vec_clrl (a, b)
> diff --git a/gcc/config/rs6000/altivec.md b/gcc/config/rs6000/altivec.md
> index 832a35cdaa9..25f6b9b2f07 100644
> --- a/gcc/config/rs6000/altivec.md
> +++ b/gcc/config/rs6000/altivec.md
> @@ -173,6 +173,9 @@
> UNSPEC_VSTRIL
> UNSPEC_SLDB
> UNSPEC_SRDB
> +   UNSPEC_

Re: [PATCH 2/3] rs6000: Add MMA built-in function definitions

[Segher Boessenkool]

Hi!

On Tue, Jun 16, 2020 at 02:02:36PM -0500, Peter Bergner wrote:
> On 6/15/20 5:43 PM, will schmidt wrote:
> >>* config/rs6000/rs6000.md ('type' attribute): Add mma type.
> > 
> > (mma) : New 'type' attribute.
> 
> I just copied what someone else did, but agree this is more readable.
> Will change.

We have had before

* config/rs6000/rs6000.md (define_attr "type"): New type popcnt.

and

* config/rs6000/rs6000.md ('type' attribute): Add
veclogical,veccmpfx,vecexts,vecmove insn types.

(Both are fine, double quotes is a teeny bit better).  The thing that
is changed is not named "mma", it is named "type".

"New value "mma"." or similar, maybe.  The important thing is that what
is in () is the thing that is modified, and that you mention the exact
name of the value added (spelled in full).

(Not that it matters much in this case anyway: no one will search the
changelog for "type" or even "\" or "\.*):", although,
hrm I did search for that in "git log config/rs6000", but most commits
do not have changelog entries in the commit message yet).


Segher

Re: [PATCH 6/6 ver 2] rs6000 Add vector blend, permute builtin support

[will schmidt via Gcc-patches]

On Mon, 2020-06-15 at 16:38 -0700, Carl Love via Gcc-patches wrote:
> v2 changes:
> 
>Updated ChangeLog per comments.
> 
>define_expand "xxpermx",  Updated implementation to use XOR

Unclear..  Updated implementation of the xxpermx ? 

>(icode == CODE_FOR_xxpermx, fix comments and check for 3-bit immediate
>field.

Unclear.

> 
>gcc/doc/extend.texi:
>   comment "Maybe it should say it is related to vsel/xxsel, but per
>   bigger element?", added comment.  I took the description directly
>   from spec.  Don't really don't want to mess with the approved
>   description.
> 
>fixed typo for Vector Permute Extendedextracth
> 
> --
> 
> GCC maintainers:
> 
> The following patch adds support for the vec_blendv and vec_permx
> builtins.
> 
> The patch has been compiled and tested on
> 
>   powerpc64le-unknown-linux-gnu (Power 9 LE)
> 
> with no regression errors.
> 
> The test cases were compiled on a Power 9 system and then tested on
> Mambo.
> 
>  Carl Love
> 
> ---
> rs6000 RFC2609 vector blend, permute instructions
> 
> gcc/ChangeLog
> 
> 2020-06-15  Carl Love  
> 
> * config/rs6000/altivec.h (vec_blendv, vec_permx): Add define.
> * config/rs6000/altivec.md (UNSPEC_XXBLEND, UNSPEC_XXPERMX.): New
>   unspecs.
> (VM3): New define_mode.
> (VM3_char): New define_attr.
> (xxblend_ mode VM3): New define_insn.
> (xxpermx): New define_expand.
> (xxpermx_inst): New define_insn.
> * config/rs6000/rs6000-builtin.def (VXXBLEND_V16QI, VXXBLEND_V8HI,
>   VXXBLEND_V4SI, VXXBLEND_V2DI, VXXBLEND_V4SF, VXXBLEND_V2DF): New
>   BU_FUTURE_V_3 definitions.
> (XXBLENDBU_FUTURE_OVERLOAD_3): New BU_FUTURE_OVERLOAD_3 definition.
> (XXPERMX): New BU_FUTURE_OVERLOAD_4 definition.
> * config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin):
> (FUTURE_BUILTIN_VXXPERMX): Add if case support.
> * config/rs6000/rs6000-call.c (FUTURE_BUILTIN_VXXBLEND_V16QI,
>   FUTURE_BUILTIN_VXXBLEND_V8HI, FUTURE_BUILTIN_VXXBLEND_V4SI,
>   FUTURE_BUILTIN_VXXBLEND_V2DI, FUTURE_BUILTIN_VXXBLEND_V4SF,
>   FUTURE_BUILTIN_VXXBLEND_V2DF, FUTURE_BUILTIN_VXXPERMX): Define
>   overloaded arguments.
> (rs6000_expand_quaternop_builtin): Add if case for CODE_FOR_xxpermx.
> (builtin_quaternary_function_type): Add v16uqi_type and xxpermx_type
> variables, add case statement for FUTURE_BUILTIN_VXXPERMX.
> (builtin_function_type)[FUTURE_BUILTIN_VXXBLEND_V16QI,
> FUTURE_BUILTIN_VXXBLEND_V8HI, FUTURE_BUILTIN_VXXBLEND_V4SI,
> FUTURE_BUILTIN_VXXBLEND_V2DI]: Add case statements.
> * doc/extend.texi: Add documentation for vec_blendv and vec_permx.
> 

tabs/spaces


> gcc/testsuite/ChangeLog
> 
> 2020-06-15  Carl Love  
> gcc.target/powerpc/vec-blend-runnable.c: New test.
> gcc.target/powerpc/vec-permute-ext-runnable.c: New test.
> ---
>  gcc/config/rs6000/altivec.h   |   2 +
>  gcc/config/rs6000/altivec.md  |  71 +
>  gcc/config/rs6000/rs6000-builtin.def  |  13 +
>  gcc/config/rs6000/rs6000-c.c  |  25 +-
>  gcc/config/rs6000/rs6000-call.c   |  94 ++
>  gcc/doc/extend.texi   |  63 
>  .../gcc.target/powerpc/vec-blend-runnable.c   | 276 
>  .../powerpc/vec-permute-ext-runnable.c| 294 ++
>  8 files changed, 833 insertions(+), 5 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/powerpc/vec-blend-runnable.c
>  create mode 100644 
> gcc/testsuite/gcc.target/powerpc/vec-permute-ext-runnable.c
> 
> diff --git a/gcc/config/rs6000/altivec.h b/gcc/config/rs6000/altivec.h
> index 9ed41b1cbf1..1b532effebe 100644
> --- a/gcc/config/rs6000/altivec.h
> +++ b/gcc/config/rs6000/altivec.h
> @@ -708,6 +708,8 @@ __altivec_scalar_pred(vec_any_nle,
>  #define vec_splati(a)  __builtin_vec_xxspltiw (a)
>  #define vec_splatid(a) __builtin_vec_xxspltid (a)
>  #define vec_splati_ins(a, b, c)__builtin_vec_xxsplti32dx (a, b, c)
> +#define vec_blendv(a, b, c)__builtin_vec_xxblend (a, b, c)
> +#define vec_permx(a, b, c, d)  __builtin_vec_xxpermx (a, b, c, d)
> 
>  #define vec_gnb(a, b)__builtin_vec_gnb (a, b)
>  #define vec_clrl(a, b)   __builtin_vec_clrl (a, b)


ok

> diff --git a/gcc/config/rs6000/altivec.md b/gcc/config/rs6000/altivec.md
> index 25f6b9b2f07..fd221bb21f6 100644
> --- a/gcc/config/rs6000/altivec.md
> +++ b/gcc/config/rs6000/altivec.md
> @@ -176,6 +176,8 @@
> UNSPEC_XXSPLTIW
> UNSPEC_XXSPLTID
> UNSPEC_XXSPLTI32DX
> +   UNSPEC_XXBLEND
> +   UNSPEC_XXPERMX
>  ])
> 
>  (define_c_enum "unspecv"
> @@ -218,6 +220,21 @@
>  (KF "FLOAT128_VECTOR_P (KFmode)")
>  (TF "FLOAT128_VECTOR_P (TFmode)")])
> 
> +;; Like VM2, just do cha