[PATCH,Fortran] Allow pointer initialization in DATA

[Steve Kargl]

The attach patch allows for pointer initialization in
a DATA statement per F2018.  Yes, it's weird that a
data-constant-object is not a named parameter.  The
'data-constant-object' is required to have the SAVE and
TARGET attribute.

Built and regression tested on x86_64-*-freebsd.
OK to commit?

PS: I'm sure Gerhard can break this.

2018-05-24  Steven G. Kargl  

* decl.c (match_data_constant):  Fortran 2018 allows pointer
initialization in a data statement.

2018-05-24  Steven G. Kargl  

* gfortran.dg/data_stmt_pointer.f90: new test.

-- 
Steve
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c	(revision 260703)
+++ gcc/fortran/decl.c	(working copy)
@@ -387,7 +387,20 @@ match_data_constant (gfc_expr **result)
   return m;
 }
   else if (m == MATCH_YES)
-gfc_free_expr (*result);
+{
+  /* F2018:R845 data-stmt-constant is initial-data-target.
+	 A data-stmt-constant shall be ... initial-data-target if and
+	 only if the corresponding data-stmt-object has the POINTER
+	 attribute. ...  If data-stmt-constant is initial-data-target
+	 the corresponding data statement object shall be
+	 data-pointer-initialization compatible (7.5.4.6) with the initial
+	 data target; the data statement object is initially associated
+	 with the target.  */
+  if ((*result)->symtree->n.sym->attr.save
+	  && (*result)->symtree->n.sym->attr.target)
+	return m;
+  gfc_free_expr (*result);
+}
 
   gfc_current_locus = old_loc;
 
Index: gcc/testsuite/data_stmt_pointer.f90
===
--- gcc/testsuite/data_stmt_pointer.f90	(nonexistent)
+++ gcc/testsuite/data_stmt_pointer.f90	(working copy)
@@ -0,0 +1,19 @@
+! { dg-do run }
+program foo
+   real, pointer :: p
+   real, save, target :: x = 42
+   data p / x /
+   if (p /= 42) stop 1
+   call bar
+end program foo
+
+subroutine bar
+   type bah
+ integer, pointer :: p
+   end type bah
+   type(bah) a
+   integer, save, target :: i = 42
+   data a%p / i /
+   if (a%p /= 42) stop 2
+end subroutine
+

[Committed] PR fortran/85543 -- Avoid NULL pointer

[Steve Kargl]

Committed as obvious.

2018-05-24  Steven G. Kargl  

PR fortran/85543
* resolve.c (update_current_proc_array_outer_dependency): Avoid NULL
pointer dereference.

2018-05-24  Steven G. Kargl  

PR fortran/85543
* gfortran.dg/pr85543.f90: New test.

-- 
Steve
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c	(revision 260698)
+++ gcc/fortran/resolve.c	(working copy)
@@ -3055,8 +3055,8 @@ update_current_proc_array_outer_dependency (gfc_symbol
 
   /* If SYM has references to outer arrays, so has the procedure calling
  SYM.  If SYM is a procedure pointer, we can assume the worst.  */
-  if (sym->attr.array_outer_dependency
-  || sym->attr.proc_pointer)
+  if ((sym->attr.array_outer_dependency || sym->attr.proc_pointer)
+  && gfc_current_ns->proc_name)
 gfc_current_ns->proc_name->attr.array_outer_dependency = 1;
 }
 
Index: gcc/testsuite/gfortran.dg/pr85543.f90
===
--- gcc/testsuite/gfortran.dg/pr85543.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr85543.f90	(working copy)
@@ -0,0 +1,8 @@
+! { dg-do compile }
+! PR fortran/85543
+program p
+   procedure(), pointer :: z
+contains
+   real(z()) function f()  ! { dg-error "in initialization expression at" }
+   end
+end

[C++ PATCH] Do not warn about zero-as-null when NULL is used.

[Ville Voutilainen]

I smacked my head against conversion_null_warnings for a while,
and then I realized that we could just stop convert_like_real from
changing the node type for null_node.

Tested manually on Linux-x64, running full suite on Linux-PPC64,
ok for trunk?

2018-05-25  Ville Voutilainen  

gcc/cp/

Do not warn about zero-as-null when NULL is used.
* call.c (convert_like_real): Don't turn a null_node into integer_cst.
* cvt.c (cp_convert_to_pointer): Don't warn about null_nodes.

testsuite/

Do not warn about zero-as-null when NULL is used.
* g++.dg/warn/Wzero-as-null-pointer-constant-7.C: New.
diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 7aadd64..cb07bb7 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -6799,12 +6799,6 @@ convert_like_real (conversion *convs, tree expr, tree fn, int argnum,
 
   if (type_unknown_p (expr))
 	expr = instantiate_type (totype, expr, complain);
-  if (expr == null_node
-	  && INTEGRAL_OR_UNSCOPED_ENUMERATION_TYPE_P (totype))
-	/* If __null has been converted to an integer type, we do not want to
-	   continue to warn about uses of EXPR as an integer, rather than as a
-	   pointer.  */
-	expr = build_int_cst (totype, 0);
   return expr;
 case ck_ambig:
   /* We leave bad_p off ck_ambig because overload resolution considers
diff --git a/gcc/cp/cvt.c b/gcc/cp/cvt.c
index f29dacd..36529f9 100644
--- a/gcc/cp/cvt.c
+++ b/gcc/cp/cvt.c
@@ -208,8 +208,8 @@ cp_convert_to_pointer (tree type, tree expr, bool dofold,
 	return build_ptrmemfunc (TYPE_PTRMEMFUNC_FN_TYPE (type), expr, 0,
  /*c_cast_p=*/false, complain);
 
-  if (complain & tf_warning)
-	maybe_warn_zero_as_null_pointer_constant (expr, loc);
+  if (!null_node_p (expr) && (complain & tf_warning))
+   maybe_warn_zero_as_null_pointer_constant (expr, loc);
 
   /* A NULL pointer-to-data-member is represented by -1, not by
 	 zero.  */
diff --git a/gcc/testsuite/g++.dg/warn/Wzero-as-null-pointer-constant-7.C b/gcc/testsuite/g++.dg/warn/Wzero-as-null-pointer-constant-7.C
new file mode 100644
index 000..0d06dbf
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/Wzero-as-null-pointer-constant-7.C
@@ -0,0 +1,13 @@
+// { dg-options "-Wzero-as-null-pointer-constant" }
+// { dg-do compile { target c++11 } }
+
+#include 
+
+void test01()
+{
+  char* x(NULL);
+  char* x2{NULL};
+  char* x3 = NULL;
+  char* x4(0); // { dg-warning "zero as null pointer" }
+  char* x5 = 0; // { dg-warning "zero as null pointer" }
+}

Re: [PATCH] handle local aggregate initialization in strlen (PR 83821)

[Martin Sebor]

On 05/24/2018 03:40 PM, Marc Glisse wrote:

On Wed, 23 May 2018, Martin Sebor wrote:


On 05/23/2018 08:57 AM, Jeff Law wrote:

On 05/10/2018 04:05 PM, Marc Glisse wrote:

On Thu, 10 May 2018, Martin Sebor wrote:


Can you please comment/respond to Jeff's question below and
confirm whether my understanding of the restriction (below)
is correct?


I don't remember it at all, I really should have expanded that
comment...

The documentation of nonzero_chars seems to indicate that, unless
full_string_p, it is only a lower bound on the length of the string, so
not suitable for this kind of alias check. I don't know if we also have
easy access to some upper bound.

(I noticed while looking at this pass that it could probably use
POINTER_DIFF_EXPR more)

So ISTM that we'd need to guard the code that uses si->nonzero_chars in
maybe_invalidate to also check FULL_STRING_P since it appears we're
using si->nonzero_chars as a string length.


I'm not sure I see why.  Can you explain?

Here's my explanation of the current approach.  si->nonzero_chars
is the lower bound on si's length.  maybe_invalidate() invalidates
the string length which is only necessary when something overwrites
one of the first si->nonzero_chars of the array.  It doesn't matter
whether si is nul-terminated at that point.


When you say "invalidates the string length", does that mean it only
invalidates nonzero_chars (the lower bound), or does that also determine
if you can CSE a call to strlen before and after this instruction? Your
argument only applies in the first case.


"invalidates the string length" means that maybe_invalidate(STMT)
removes the length information record for a string whose length
might be modified by STMT.

If the exact string length is known (full_string_p is true) then
its length can only be modified by writing a nul into one of
the leading nonzero_chars.  If the exact string length is not
known (i.e., full_string_p is false), then nonzero_chars is not
constant and writes into the string are assumed to change its
length, and thus invalidate it.

But I'm not sure I understand from your brief description what
use case you have in mind.  If you have an example I'll test it.

Martin

[Committed] PR fortran/85780 -- Avoid NULL pointer dereference

[Steve Kargl]

Committed as obvious.

2018-05-24  Steven G. Kargl  

PR fortran/85780
* resolve.c (resolve_fl_procedure): Avoid NULL dereference.

2018-05-24  Steven G. Kargl  

PR fortran/85780
* gfortran.dg/pr85780.f90: New test.

-- 
Steve
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c	(revision 260696)
+++ gcc/fortran/resolve.c	(working copy)
@@ -12503,7 +12503,7 @@ resolve_fl_procedure (gfc_symbol *sym, int mp_flag)
   while (curr_arg != NULL)
 {
   /* Skip implicitly typed dummy args here.  */
-	  if (curr_arg->sym->attr.implicit_type == 0)
+	  if (curr_arg->sym && curr_arg->sym->attr.implicit_type == 0)
 	if (!gfc_verify_c_interop_param (curr_arg->sym))
 	  /* If something is found to fail, record the fact so we
 		 can mark the symbol for the procedure as not being
Index: gcc/testsuite/gfortran.dg/pr85780.f90
===
--- gcc/testsuite/gfortran.dg/pr85780.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr85780.f90	(working copy)
@@ -0,0 +1,5 @@
+! { dg-do compile }
+! { dg-options "-std=legacy" }
+! PR fortran/85780
+subroutine s(*) bind(c)
+end

Unreviewed patch

[Rainer Orth]

The following patch has remained unreviewed for two weeks:

[build] Support SHF_EXCLUDE on non-x86 and with Solaris as
https://gcc.gnu.org/ml/gcc-patches/2018-05/msg00465.html

Most of it falls under my Solaris maintainership, I believe, but running
the SHF_EXCLUDE configure test on all targets and the varasm.c change don't.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH GCC][1/6]Compute type mode and register class mapping

[Jeff Law]

On 05/18/2018 02:40 AM, Bin.Cheng wrote:
> On Fri, May 4, 2018 at 5:21 PM, Bin Cheng  wrote:
>> Hi,
>> This is the updated version patch set computing register pressure on TREE SSA
>> and use that information to direct other loop optimizers (predcom only for 
>> now).
>> This version of change is to follow Jeff's comment that we should reuse 
>> existing
>> tree-ssa-live.c infrastructure for live range computation, rather than 
>> inventing
>> another one.
>> Jeff had another concern about exposing ira.h and low-level register stuff in
>> GIMPLE world.  Unfortunately I haven't got a clear solution to it.  I found 
>> it's
>> a bit hard to relate type/type_mode with register class and with available 
>> regs
>> without exposing the information, especially there are multiple possible 
>> register
>> classes for vector types and it's not fixed.  I am open to any suggestions 
>> here.
>>
>> This is the first patch estimating the map from type mode to register class.
>> This one doesn't need update and it's the same as the original version patch
>> at https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01021.html
>>
>> Bootstrap and test on x86_64 and AArch64 ongoing.  Any comments?
> Hi,
> The original version of this patch was approved by Jeff
> @https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01808.html
> Jeff, some new comment now or the old approval is still valid?
> Guess your major concern is about exporting ira.h to gimple world?
Yea, that was by far my biggest concern -- IRA is very much in the RTL
world and exposing it into the gimple world seems like a major layering
violation.

So I have no inherent issues with this patch in isolation, but I may
have issues with subsequent patches if they introduce that kind of
layering violation.  So let's avoid installing until we have agreement
on the full set of patches.

jeff

Re: Try harder to preserve operand ties in maybe_legitimize_operands

[Jeff Law]

On 05/23/2018 12:47 AM, Richard Sandiford wrote:
> maybe_legitimize_operands normally goes through each operand in turn
> and legitimises it in isolation.  For example, if two operands to
> an instruction initially have constant value C, and the instruction
> requires both operands to be registers, the function ends up forcing
> C into a register twice and passing two different registers to the
> instruction.
> 
> I think we should try a bit harder to preserve the rtx_equal_p
> property, if it's easy to do.  Some targets can optimise that
> case better than they would the general case of all operands
> being different.  This is particularly true for SVE after the
> upcoming changes to the IFN_COND_* routines.
> 
> This is hard to test on its own, but is covered by the upcoming
> IFN_COND_* patches.
> 
> Tested on aarch64-linux-gnu (with and without SLP, and with and without
> the follow-on patch that needs it), aarch64_be-elf and x86_64-linux-gnu.
> OK to install?
> 
> Richard
> 
> 
> 2018-05-23  Richard Sandiford  
> 
> gcc/
>   * optabs.c (can_reuse_operands_p): New function.
>   (maybe_legitimize_operands): Try to reuse the results for
>   earlier operands.
OK.
jeff

Re: [PATCH, alpha] PR target/85095

[coypu]

On Thu, May 24, 2018 at 01:32:17PM -0600, Jeff Law wrote:
> On 05/24/2018 01:17 PM, co...@sdf.org wrote:
> > On Thu, May 24, 2018 at 12:48:22PM -0600, Jeff Law wrote:
> >> On 05/24/2018 07:54 AM, Maya Rashish wrote:
> >>> Move linux-specific specfile definitions to linux.h
> >>> gcc/config/alpha/linux.h (STARTFILE_SPEC, ENDFILE_SPEC) move from 
> >>> alpha/elf.h
> >>> ---
> >>>  gcc/config/alpha/elf.h   | 26 --
> >>>  gcc/config/alpha/linux.h | 26 ++
> >>>  2 files changed, 26 insertions(+), 26 deletions(-)
> >> So is there going to be some kind of follow-up to fix freebsd, netbsd
> >> and openbsd which currently get their STARTFILE/ENDFILE from elf.h?
> >>
> >> jeff
> > 
> > I can try to fix openbsd soon, but freebsd dropped alpha in 2009.
> > How does gcc feel about me picking up patches from openbsd ports, their
> > package manager, that weren't written by myself?
> So ISTM we should deprecate freebsd alpha.
> 
> WRT picking up bits from others.  It'd really depend on their size and
> complexity -- I'd have to see them to be able to judge.  I'll review if
> you extract the necessary bits and submit them.
> 
> Jeff

- With the original patch
- Attached patch to update the specfile for openbsd from openbsd ports
(It is here: 
https://github.com/openbsd/ports/blob/master/lang/gcc/6/patches/patch-gcc_config_alpha_openbsd_h
 )
- Attached patch to recognise cross compilation for openbsd (from me)
- A violent hack of "borrowing" stdatomic.h from a newer GCC
- Disabling libssp

I can build trunk for openbsd--alpha.
>From 1387836d5af4150ea08b888a202f72c08909a32f Mon Sep 17 00:00:00 2001
From: Maya Rashish 
Date: Fri, 25 May 2018 01:26:01 +0300
Subject: [PATCH 1/2] Recognise cross compilation for openbsd

---
 libstdc++-v3/configure  | 2 +-
 libstdc++-v3/crossconfig.m4 | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
index 79eb18727ea..cb51a01feeb 100755
--- a/libstdc++-v3/configure
+++ b/libstdc++-v3/configure
@@ -66148,7 +66148,7 @@ fi
 done
 
 ;;
-  *-netbsd*)
+  *-netbsd* | *-openbsd*)
 SECTION_FLAGS='-ffunction-sections -fdata-sections'
 
 
diff --git a/libstdc++-v3/crossconfig.m4 b/libstdc++-v3/crossconfig.m4
index 669d87f7602..0dbfe4057bd 100644
--- a/libstdc++-v3/crossconfig.m4
+++ b/libstdc++-v3/crossconfig.m4
@@ -201,7 +201,7 @@ case "${host}" in
 AC_CHECK_FUNCS(aligned_alloc posix_memalign memalign _aligned_malloc)
 AC_CHECK_FUNCS(_wfopen)
 ;;
-  *-netbsd*)
+  *-netbsd* | *-openbsd*)
 SECTION_FLAGS='-ffunction-sections -fdata-sections'
 AC_SUBST(SECTION_FLAGS) 
 GLIBCXX_CHECK_LINKER_FEATURES
-- 
2.17.0

>From 164a025328b007fb73ccd4491bc7d6fc70b88f0d Mon Sep 17 00:00:00 2001
From: Maya Rashish 
Date: Fri, 25 May 2018 01:26:16 +0300
Subject: [PATCH 2/2] Update openbsd/alpha specfile.

Taken from OpenBSD ports
---
 gcc/config/alpha/openbsd.h | 33 -
 1 file changed, 32 insertions(+), 1 deletion(-)

diff --git a/gcc/config/alpha/openbsd.h b/gcc/config/alpha/openbsd.h
index aa369d7630a..9f035150d8b 100644
--- a/gcc/config/alpha/openbsd.h
+++ b/gcc/config/alpha/openbsd.h
@@ -19,6 +19,28 @@ along with GCC; see the file COPYING3.  If not see
 
 /* Controlling the compilation driver.  */
 
+#undef TARGET_DEFAULT
+#define TARGET_DEFAULT \
+   (MASK_FPREGS | MASK_IEEE | MASK_IEEE_CONFORMANT)
+
+ #define LINK_SPEC \
+  "%{!shared:%{!nostdlib:%{!r*:%{!e*:-e __start \
+   %{shared:-shared} %{R*} \
+   %{static:-Bstatic} \
+   %{!static:-Bdynamic} \
+   %{rdynamic:-export-dynamic} \
+   %{assert*} \
+   %{!dynamic-linker:-dynamic-linker /usr/libexec/ld.so}"
+
+/* As an elf system, we need crtbegin/crtend stuff.  */
+#undef STARTFILE_SPEC
+#define STARTFILE_SPEC "\
+   %{!shared: %{pg:gcrt0%O%s} %{!pg:%{p:gcrt0%O%s} \
+   %{!p:%{!static:crt0%O%s} %{static:%{nopie:crt0%O%s} \
+   %{!nopie:rcrt0%O%s crtbegin%O%s} %{shared:crtbeginS%O%s}"
+#undef ENDFILE_SPEC
+#define ENDFILE_SPEC "%{!shared:crtend%O%s} %{shared:crtendS%O%s}"
+
 /* run-time target specifications */
 #define TARGET_OS_CPP_BUILTINS()   \
 do {   \
@@ -28,18 +50,27 @@ along with GCC; see the file COPYING3.  If not see
 
 /* Layout of source language data types.  */
 
-/* This must agree with  */
+/* This must agree with  */
 #undef SIZE_TYPE
 #define SIZE_TYPE "long unsigned int"
 
 #undef PTRDIFF_TYPE
 #define PTRDIFF_TYPE "long int"
 
+#undef INTMAX_TYPE
+#define INTMAX_TYPE "long long int"
+
+#undef UINTMAX_TYPE
+#define UINTMAX_TYPE "long long unsigned int"
+
 #undef WCHAR_TYPE
 #define WCHAR_TYPE "int"
 
 #undef WCHAR_TYPE_SIZE
 #define WCHAR_TYPE_SIZE 32
 
+#undef WINT_TYPE
+#define WINT_TYPE "int"
+
 
 #define LOCAL_LABEL_PREFIX "."
-- 
2.17.0

Re: [PATCH] gcc/configure.ac: add --disable-systemtap switch

[Jeff Law]

On 05/12/2018 08:00 AM, Sergei Trofimovich via gcc-patches wrote:
> From: Sergei Trofimovich 
> 
> Before the change systemtap probes were enabled
> if target headers had sys/sdt.h at ./configure time.
> 
> After the change explicitly ask to enable or disable
> for probe support and not rely on automagic dependency
> discovery.
I'm not terribly concerned about the uninstalling systemtap while
compiling gcc problem.   That seems like a package management problem on
the distro side.

61257 does raise the issue of header file usability which is a much
bigger concern.  c#1 indicates autoconf-2.70 introduces code which
instead of testing for header file existence instead checks for
usability.  So I'd rather see us moving towards making that happen
rather than explicit enable/disable of systemtap headers/probes.

jeff

Re: [PATCH] Define DW_FORM_strx* and DW_FORM_addrx*.

[Jeff Law]

On 05/09/2018 11:19 AM, Thomas Rix wrote:
> This patch defines the dwarf 5 forms.
> DW_FORM_strx1, DW_FORM_strx2, DW_FORM_strx3, DW_FORM_strx4
> And similar for addrx.
> 
> Tom
> 
> 
> 
> 
> 0001-Define-DW_FORM_strx-and-DW_FORM_addrx.patch
> 
> 
> From b995ecdf67d1cff0fcda622a5272a75e9fdde77c Mon Sep 17 00:00:00 2001
> From: Tom Rix 
> Date: Tue, 8 May 2018 08:30:13 -0700
> Subject: [PATCH] Define DW_FORM_strx* and DW_FORM_addrx*.
> 
> for  include/ChangeLog
> 
> * dwarf2.def (DW_FORM_strx*, DW_FORM_addrx*): New.
Thanks Tom.  Largely lost touch after you left Cygnus/Red Hat many years
ago.  I hope things are going well.

Installed on the trunk.

Jeff

Re: [PATCH] Optimize AVX512 vpcmpeq* against 0 into vptestm* (PR target/85832)

[Jeff Law]

On 05/23/2018 12:45 AM, Jakub Jelinek wrote:
> Hi!
> 
> As mentioned in the PR, vptestm* instructions with the same input operand used
> twice perform the same comparison as vpcmpeq* against zero vector, with the
> advantage that a register holding CONST0_RTX (mode) is not needed.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> 2018-05-23  Jakub Jelinek  
> 
>   PR target/85832
>   * config/i386/sse.md (_eq3_1):
>   Add (=Yk,v,C) variant using vptestm insn.  Use TARGET_AVX512BW
>   in test instead of TARGET_AVX512F for VI12_AVX512VL iterator.
> 
>   * gcc.target/i386/avx512f-pr85832.c: New test.
>   * gcc.target/i386/avx512vl-pr85832.c: New test.
>   * gcc.target/i386/avx512bw-pr85832.c: New test.
>   * gcc.target/i386/avx512vlbw-pr85832.c: New test.
OK.
jeff

Re: [PATCH] issue nonstring warning for strcpy even on s360 (PR 85369)

[Jeff Law]

On 04/12/2018 06:00 PM, Martin Sebor wrote:
> PR 85369 notes that the c-c++-common/attr-nonstring-3.c fails
> on IBM Z (and other similar targets) whose back-end provides
> the movstr expander.  The failure is cause by an expected
> warning failing to trigger because the strcpy call is expanded
> early and the checker never runs.
> 
> The attached patch adjusts the code to make sure the warning
> is not bypassed on these targets.
> 
> I've verified the patch with an s390-linux cross-compiler and
> with a full x86_64-linux native build and regression run.
> 
> Martin
> 
> gcc-85369.diff
> 
> 
> PR middle-end/85369 - no -Wstringop-overflow for a strcpy / stpcpy call with 
> a nonstring pointer when providing movstr pattern
> 
> gcc/ChangeLog:
> 
>   PR middle-end/85369
>   * builtins.c (expand_builtin_strcpy_1): New function.
Patch actually introduced expand_builtin_stpcpy_1, not
expand_builtin_strcpy_1.

>   (expand_builtin_stpcpy): Call it, and call maybe_warn_nonstring_arg
>   only if the former succeeds.
OK with ChangeLog nit fixed.

jeff

Re: [PATCH] handle local aggregate initialization in strlen (PR 83821)

[Marc Glisse]

On Wed, 23 May 2018, Martin Sebor wrote:


On 05/23/2018 08:57 AM, Jeff Law wrote:

On 05/10/2018 04:05 PM, Marc Glisse wrote:

On Thu, 10 May 2018, Martin Sebor wrote:


Can you please comment/respond to Jeff's question below and
confirm whether my understanding of the restriction (below)
is correct?


I don't remember it at all, I really should have expanded that comment...

The documentation of nonzero_chars seems to indicate that, unless
full_string_p, it is only a lower bound on the length of the string, so
not suitable for this kind of alias check. I don't know if we also have
easy access to some upper bound.

(I noticed while looking at this pass that it could probably use
POINTER_DIFF_EXPR more)

So ISTM that we'd need to guard the code that uses si->nonzero_chars in
maybe_invalidate to also check FULL_STRING_P since it appears we're
using si->nonzero_chars as a string length.


I'm not sure I see why.  Can you explain?

Here's my explanation of the current approach.  si->nonzero_chars
is the lower bound on si's length.  maybe_invalidate() invalidates
the string length which is only necessary when something overwrites
one of the first si->nonzero_chars of the array.  It doesn't matter
whether si is nul-terminated at that point.


When you say "invalidates the string length", does that mean it only 
invalidates nonzero_chars (the lower bound), or does that also determine 
if you can CSE a call to strlen before and after this instruction? Your 
argument only applies in the first case.


--
Marc Glisse

Re: Remove support for FreeBSD 4.x (and earlier)

[Jeff Law]

On 05/24/2018 03:36 PM, Gerald Pfeifer wrote:
> FreeBSD 5.0 was released in January of 2003, and FreeBSD 4.11, the last 
> on that branch in January of 2005, so it appears time to remove support 
> for anything older than FreeBSD 5.x, if for no other reason to simplify 
> things a bit.
> 
> This simplifies the spec file a fair bit, and I would not be surprised 
> for even FreeBSD 5.x not to really work any longer.
> 
> On the way, move a now no longer relevant comment where it is still 
> applicable.
> 
> What do you think?  (Let me know if you'd like me to keep the first 
> sentence of the original comment.)
> 
> Gerald
> 
> 2018-05-24  Gerald Pfeifer  
> 
>   * config/freebsd-spec.h (FBSD_LIB_SPEC): Only consider FreeBSD 5
>   and later.
Happy to trust you on what versions can be dropped and the resulting
simplifications.

Is it worth noting those old versions as deprecated/obsolete in config.gcc?

jeff

Remove support for FreeBSD 4.x (and earlier)

[Gerald Pfeifer]

FreeBSD 5.0 was released in January of 2003, and FreeBSD 4.11, the last 
on that branch in January of 2005, so it appears time to remove support 
for anything older than FreeBSD 5.x, if for no other reason to simplify 
things a bit.

This simplifies the spec file a fair bit, and I would not be surprised 
for even FreeBSD 5.x not to really work any longer.

On the way, move a now no longer relevant comment where it is still 
applicable.

What do you think?  (Let me know if you'd like me to keep the first 
sentence of the original comment.)

Gerald

2018-05-24  Gerald Pfeifer  

* config/freebsd-spec.h (FBSD_LIB_SPEC): Only consider FreeBSD 5
and later.

Index: gcc/config/freebsd-spec.h
===
--- gcc/config/freebsd-spec.h   (revision 260690)
+++ gcc/config/freebsd-spec.h   (working copy)
@@ -79,15 +79,9 @@
 #define FBSD_ENDFILE_SPEC \
   "%{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s"
 
-/* Provide a LIB_SPEC appropriate for FreeBSD as configured and as
-   required by the user-land thread model.  Before __FreeBSD_version
-   500016, select the appropriate libc, depending on whether we're
-   doing profiling or need threads support.  At __FreeBSD_version
-   500016 and later, when threads support is requested include both
-   -lc and the threading lib instead of only -lc_r.  To make matters
-   interesting, we can't actually use __FreeBSD_version provided by
-directly since it breaks cross-compiling.  As a final
-   twist, make it a hard error if -pthread is provided on the command
+/* When threads support is requested (assuming FreeBSD 5.x and later)
+   include both -lc and the threading lib.  
+   And make it a hard error if -pthread is provided on the command
line and gcc was configured with --disable-threads (this will help
avoid bug reports from users complaining about threading when they
misconfigured the gcc bootstrap but are later consulting FreeBSD
@@ -106,19 +100,8 @@
 %{pg:  -lc_p}  \
   }"
 #else
-#if FBSD_MAJOR < 5
 #define FBSD_LIB_SPEC "
\
   %{!shared:   \
-%{!pg: \
-  %{!pthread:-lc}  \
-  %{pthread:-lc_r}}
\
-%{pg:  \
-  %{!pthread:-lc_p}
\
-  %{pthread:-lc_r_p}}  \
-  }"
-#else
-#define FBSD_LIB_SPEC "
\
-  %{!shared:   \
 %{!pg: %{pthread:-lpthread} -lc}   \
 %{pg:  %{pthread:-lpthread_p} -lc_p}   \
   }\
@@ -126,8 +109,10 @@
 %{pthread:-lpthread} -lc   \
   }"
 #endif
-#endif
 
+/* To make matters interesting, we can't actually use __FreeBSD_version
+   provided by  directly since it breaks cross-compiling.  */
+
 #if FBSD_MAJOR < 6
 #define FBSD_DYNAMIC_LINKER "/usr/libexec/ld-elf.so.1"
 #else

Re: RFA (symtab): PATCH to symtab_node::nonzero_address DECL_COMDAT handling for c++/80485

[Jeff Law]

On 05/19/2018 07:07 AM, Jason Merrill wrote:
> A comment earlier in in nonzero_address says, "Important case of WEAK
> we want to do well are comdats. Those are handled by later check for
> definition."  But in this case we aren't handling this comdat function
> well, we return false because it is DECL_WEAK and DECL_EXTERNAL
> (because we aren't at EOF yet) and so we fail to fold the comparison.
> 
> This patch fixes the testcase by checking DECL_COMDAT directly.
> 
> Tested x86_64-pc-linux-gnu.  OK for trunk?
> 
> 
> 80485.diff
> 
> 
> commit a1a0c12db660aa94a625771a9f2fa9db30a552fe
> Author: Jason Merrill 
> Date:   Fri May 18 20:20:05 2018 -0400
> 
> PR c++/80485 - inline function non-zero address.
> 
> * symtab.c (nonzero_address): Check DECL_COMDAT.
OK
jeff

Re: [PATCH] consider MIN_EXPR in get_size_range() (PR 85888)

[Martin Sebor]

On 05/24/2018 11:15 AM, Richard Biener wrote:

On May 24, 2018 7:02:17 PM GMT+02:00, Martin Sebor  wrote:

On 05/24/2018 03:39 AM, Richard Biener wrote:

On Thu, May 24, 2018 at 12:50 AM Martin Sebor 

wrote:



The attached patch enhances the get_size_range() function to
extract more accurate ranges out of MIN_EXPR and MAX_EXPR nodes
with SSA_NAME operand(s).  This helps -Wstringop-overflow avoid
false positives on some targets in cases like some of those
reported in bug 85623 - strncmp() warns about attribute nonstring
incorrectly in -Wstringop-overflow



When first trying to expand calls to __builtin_strncmp, most back
ends succeed even when the expansion results in a call to the

library

function.  The powerpc64 back-end, however, fails and and allows
the generic expansion to take place.  There is a subtle difference
between the two cases that shows up when examining the bound of
the strncmp call expression (the third argument): in the original
call expression (in expand_builtin_strncmp) the bound is or can be
an SSA_NAME.  But when the early expansion fails,
expand_builtin_strncmp transforms the original call expression into
a new one, substituting MIN_EXPR (bound, CST) for the bound where
CST is the constant result of strlen (STR), with STR being either
the first or second strncmp argument.  When the bound is an SSA_NAME
the subsequent attempt to determine its range from the MIN_EXPR

fails.


Hmm, wouldn't sth extracted from the attached random patch I have

lying

around be more useful in general?  That is, refactor the GENERIC
expression walk in determine_value_range_1 to sth that can be used
in the current get_range_info () interface?  Or if we don't want to

change

that to accept non-SSA names add a corresponding get_expr_range_info

()

interface.


Thanks.  It is certainly more general.  I'm just not sure how much
use the generality can be put to because...


If you do that please cut out the dominator/loop condition handling

and

refrain from the idea of looking at SSA def stmts.


...I've done that but I'm having trouble exercising the code except
for this bug.  (I've run the C testsuite but the only tests that end
up in it call it with uninteresting arguments like VAR_DECL).  Do
you have any suggestions?


Well, what builds the MIN_EXPR for your testcase? I orinigally used it for 
niters analysis which deals with complex GENERIC expressions. If you just 
changed get_range_info then of course callers are guarded with SSA name checks.


In pr85888 it's built by expand_builtin_strncmp (so very late).
It doesn't seem like a good use case because of this code:

  /* Expand the library call ourselves using a stabilized argument
 list to avoid re-evaluating the function's arguments twice.  */
  tree fn = build_call_nofold_loc (loc, fndecl, 3, arg1, arg2, len);
  gcc_assert (TREE_CODE (fn) == CALL_EXPR);
  CALL_EXPR_TAILCALL (fn) = CALL_EXPR_TAILCALL (exp);
  return expand_call (fn, target, target == const0_rtx);

AFAICS, the new call expression is the same as the old one, the only
difference is the LEN argument which is the MIN_EXPR.

The code was added in r72380 where the stabilization referred to
calling save_expr() on the arguments.  That code has been gone
since r242556 so I think a better/more targeted solution to fix
pr85888 than either of our approaches might be to simply call
expand_call() on the original CALL_EXPR with the original
arguments, including ARG3.

I don't fully understand the point of the save_expr() calls there
(and they're still in builtin_expand_strcmp), so if they need to
be restored then they would presumably include ARG3.  I.e.,
expand_call() would be called using ARG3 in the original SSA_NAME
form rather than the MIN_EXPR wrapper created by the function.

Attached is a patch that implements the first approach above.

If the SAVE_EXPRs are needed for some reason, it would be good
to have a test case to verify it.  I haven't been able to come
up with one (or find an existing test that fails due to their
removal) but that could very well be because my limited
understanding of what they're for (and poor testsuite coverage).

I'm also up for taking your patch and trying to make use of it
for other trees where get_range_info() is currently being called
for SSA_NAMEs only.  But it feels like a separate project from
this bug fix.

Martin




Martin

PS I was able to create a test that at -O0 could call it with
a more interesting argument such as:

  const __SIZE_TYPE__ i = 3, j = 5;

  int f (void)
  {
return __builtin_strncmp ("1234", "123", i < j ? i : j);
  }

Here, the first call to gimple_fold_builtin_string_compare() that
I picked as a test case sees:

  j.0_1 = 5;
  i.1_2 = 3;
  _3 = MIN_EXPR ;
  D.1963 = __builtin_strncmp ("1234", "123", _3);

Above, _3's range info is not available yet at this point so
the expression could be evaluated but only by looking at def stmts.
Why is it not a good idea?


Because 

Re: [PATCH] handle local aggregate initialization in strlen (PR 83821)

[Jeff Law]

On 05/23/2018 01:28 PM, Martin Sebor wrote:
> On 05/23/2018 08:57 AM, Jeff Law wrote:
>> On 05/10/2018 04:05 PM, Marc Glisse wrote:
>>> On Thu, 10 May 2018, Martin Sebor wrote:
>>>
 Can you please comment/respond to Jeff's question below and
 confirm whether my understanding of the restriction (below)
 is correct?
>>>
>>> I don't remember it at all, I really should have expanded that
>>> comment...
>>>
>>> The documentation of nonzero_chars seems to indicate that, unless
>>> full_string_p, it is only a lower bound on the length of the string, so
>>> not suitable for this kind of alias check. I don't know if we also have
>>> easy access to some upper bound.
>>>
>>> (I noticed while looking at this pass that it could probably use
>>> POINTER_DIFF_EXPR more)
>> So ISTM that we'd need to guard the code that uses si->nonzero_chars in
>> maybe_invalidate to also check FULL_STRING_P since it appears we're
>> using si->nonzero_chars as a string length.
> 
> I'm not sure I see why.  Can you explain?
> 
> Here's my explanation of the current approach.  si->nonzero_chars
> is the lower bound on si's length.  maybe_invalidate() invalidates
> the string length which is only necessary when something overwrites
> one of the first si->nonzero_chars of the array.  It doesn't matter
> whether si is nul-terminated at that point.
> 
> The difference can be seen on the following test case which gets
> optimized as I would expect only if full_string_p is not considered,
> else the (minimum) string length is invalidated by the assignment
> to a.b because full_string_p is false.
My bad.  I was thinking in terms of maximum string length which
si->nonzero_chars does not represent unless it's also FULL_STRING_P.  A
a minimum string length it should be OK.

So OK with a quick comment clarifying that we're using it to compute a
minimum string length rather than a maximum string length.

Sorry for the goof on my part.

jeff

Re: [PATCH, AVX512]: Fix cvtusi264 insn mnemonic

[Jeff Law]

On 05/23/2018 04:08 AM, Uros Bizjak wrote:
> Hello!
> 
> With current insn mnemonic and ATT assembler dialect, there is no way
> for the assembler to distinguish between DImode and SImode instruction
> when memory input operand is used. The dump for 32bit memory reads as:
> 
>0:   62 f1 7e 08 7b 05 00vcvtusi2ss 0x0(%rip),%xmm0,%xmm0
>7:   00 00 00
>   10:   62 f1 7f 08 7b 05 00vcvtusi2sd 0x0(%rip),%xmm0,%xmm0
>   17:   00 00 00
> 
> And for 64bit access:
> 
>   20:   62 f1 fe 08 7b 05 00vcvtusi2ss 0x0(%rip),%xmm0,%xmm0
>   27:   00 00 00
>   30:   62 f1 ff 08 7b 05 00vcvtusi2sd 0x0(%rip),%xmm0,%xmm0
>   37:   00 00 00
> 
>  (Note the difference in the 3rd byte. On a related note, binutils
> should also be fixed to dump vcvtsi2sdq in the 64bit case to avoid
> ambiguity)
> 
> We should use "q" suffix with the ATT dialect in the Dimode insn mnemonic.
> 
> 2018-05-23  Uros Bizjak  
> 
> * config/i386/sse.md (cvtusi264):
> Add {q} suffix to insn mnemonic.
> 
> testsuite/Changelog:
> 
> 2018-05-23  Uros Bizjak  
> 
> * gcc.target/i386/avx512f-vcvtusi2sd64-1.c: Update scan string.
> * gcc.target/i386/avx512f-vcvtusi2ss64-1.c: Ditto.
> 
> Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
> 
> OK for mainline and backports?
OK.
jeff

Re: [PATCH] POPCOUNT folding optimizations

[Marc Glisse]

On Thu, 24 May 2018, Jeff Law wrote:


+    case LSHIFT_EXPR:
+  if (TREE_CODE (TREE_OPERAND (t, 1)) == INTEGER_CST)


Maybe check INTEGRAL_TYPE_P as well, like you did for PLUS_EXPR? Or was
that also unnecessary for PLUS_EXPR?

While there may be cases where allowing an INTEGRAL_TYPE_P SSA_NAME for
the shift count would be helpful, I think it'd be exceedingly rare.

For operands of a PLUS_EXPR I think we're a lot more likely to be able
to do something useful with an SSA_NAME argument.


This was a while ago, but it seems likely that I meant: check that the 
result (or lhs) has scalar integer type (in particular not a vector type). 
Or more precisely asking why such a check is done for PLUS_EXPR and not 
for LSHIFT_EXPR.


--
Marc Glisse

Re: [Patch, Fortran] PR 85849: [F2018] warn for obsolescent features

[Steve Kargl]

On Thu, May 24, 2018 at 09:57:16PM +0200, Janus Weil wrote:
> 
> just because 2018 seems like a good time to do that, I continue
> plucking some of the low-hanging Fortran 2018 fruit. The attached
> patch adds obsolescence warnings for all major F18 obsolescences
> (COMMON, BLOCK DATA, EQUIVALENCE, FORALL, labeled DO). Those warnings
> appear only with -std=f2018, but not with gfortran's default -std=gnu.
> They currently have zero impact on the gfortran test suite, so I'm
> adding a new test case to check for their existence.
> 
> Regtests cleanly on x86_64-linux-gnu. Ok for trunk?
> 

Ok.  Thanks for housekeeping type patches.

-- 
Steve

Re: [PATCH] MSP430: Don't warn if naked function does not return

[Jeff Law]

On 05/23/2018 04:44 PM, Jozef Lawrynowicz wrote:
> 2018-05-23  Jozef Lawrynowicz  
> 
>   gcc/config/msp430/msp430.c (msp430_warn_func_return): New.
> 
Thanks.  Installed on the trunk.

Jeff

Re: PING^2: [PATCH] Don't mark IFUNC resolver as only called directly

[H.J. Lu]

On Wed, May 23, 2018 at 8:35 AM, H.J. Lu  wrote:
> On Wed, May 23, 2018 at 8:11 AM, Jan Hubicka  wrote:
>>> On Wed, May 23, 2018 at 2:01 AM, Jan Hubicka  wrote:
>>> >> On Tue, May 22, 2018 at 9:21 AM, Jan Hubicka  wrote:
>>> >> >> > >  class ipa_opt_pass_d;
>>> >> >> > >  typedef ipa_opt_pass_d *ipa_opt_pass;
>>> >> >> > > @@ -2894,7 +2896,8 @@ 
>>> >> >> > > cgraph_node::only_called_directly_or_aliased_p (void)
>>> >> >> > >   && !DECL_STATIC_CONSTRUCTOR (decl)
>>> >> >> > >   && !DECL_STATIC_DESTRUCTOR (decl)
>>> >> >> > >   && !used_from_object_file_p ()
>>> >> >> > > - && !externally_visible);
>>> >> >> > > + && !externally_visible
>>> >> >> > > + && !lookup_attribute ("ifunc", DECL_ATTRIBUTES 
>>> >> >> > > (decl)));
>>> >> >> >
>>> >> >> > How's it handled for our own generated resolver functions?  
>>> >> >> > That is,
>>> >> >> > isn't there sth cheaper than doing a lookup_attribute here?  I 
>>> >> >> > see
>>> >> >> > that make_dispatcher_decl nor 
>>> >> >> > ix86_get_function_versions_dispatcher
>>> >> >> > adds the 'ifunc' attribute (though they are TREE_PUBLIC there).
>>> >> >> 
>>> >> >>  Is there any drawback of setting force_output flag?
>>> >> >>  Honza
>>> >> >> >>>
>>> >> >> >>> Setting force_output may prevent some optimizations.  Can we add 
>>> >> >> >>> a bit
>>> >> >> >>> for IFUNC resolver?
>>> >> >> >>>
>>> >> >> >>
>>> >> >> >> Here is the patch to add ifunc_resolver to cgraph_node. Tested on 
>>> >> >> >> x86-64
>>> >> >> >> and i686.  Any comments?
>>> >> >> >>
>>> >> >> >
>>> >> >> > PING:
>>> >> >> >
>>> >> >> > https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00647.html
>>> >> >> >
>>> >> >>
>>> >> >> PING.
>>> >> > OK, but please extend the verifier that ifunc_resolver flag is 
>>> >> > equivalent to
>>> >> > lookup_attribute ("ifunc", DECL_ATTRIBUTES (decl))
>>> >> > so we are sure things stays in sync.
>>> >> >
>>> >>
>>> >> Like this
>>> >>
>>> >> diff --git a/gcc/symtab.c b/gcc/symtab.c
>>> >> index 80f6f910c3b..954920b6dff 100644
>>> >> --- a/gcc/symtab.c
>>> >> +++ b/gcc/symtab.c
>>> >> @@ -998,6 +998,13 @@ symtab_node::verify_base (void)
>>> >>error ("function symbol is not function");
>>> >>error_found = true;
>>> >>}
>>> >> +  else if ((lookup_attribute ("ifunc", DECL_ATTRIBUTES (decl))
>>> >> + != NULL)
>>> >> + != dyn_cast  (this)->ifunc_resolver)
>>> >> +  {
>>> >> +  error ("inconsistent `ifunc' attribute");
>>> >> +  error_found = true;
>>> >> +  }
>>> >>  }
>>> >>else if (is_a  (this))
>>> >>  {
>>> >>
>>> >>
>>> >> Thanks.
>>> > Yes, thanks!
>>> > Honza
>>>
>>> I'd like to also fix it on GCC 8 branch for CET.  Should I backport my
>>> patch to GCC 8 after a few days or use the simple patch for GCC 8:
>>>
>>> https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00588.html
>>
>> I would backport this one so we don't unnecesarily diverge.
>> Thanks!
>> Honza
>
> This is the backport which I will check into GCC 8 branch next week.
>

This is the updated backport which I will check into GCC 8 branch next week.


-- 
H.J.
From 4516b6c76f4af7de2c09d34ab2ed1834c5ff31a0 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Wed, 11 Apr 2018 12:31:21 -0700
Subject: [PATCH] Don't mark IFUNC resolver as only called directly

Since IFUNC resolver is called indirectly, don't mark IFUNC resolver as
only called directly.  This patch adds ifunc_resolver to cgraph_node,
sets ifunc_resolver for ifunc attribute and checks ifunc_resolver
instead of looking up ifunc attribute.

gcc/

	Backport from mainline
	2018-05-24  H.J. Lu  

	PR target/85900
	PR target/85345
	* varasm.c (assemble_alias): Check ifunc_resolver only on
	FUNCTION_DECL.

	2018-05-22  H.J. Lu  

	PR target/85345
	* cgraph.h (cgraph_node::create): Set ifunc_resolver for ifunc
	attribute.
	(cgraph_node::create_alias): Likewise.
	(cgraph_node::get_availability): Check ifunc_resolver instead
	of looking up ifunc attribute.
	* cgraphunit.c (maybe_diag_incompatible_alias): Likewise.
	* varasm.c (do_assemble_alias): Likewise.
	(assemble_alias): Likewise.
	(default_binds_local_p_3): Likewise.
	* cgraph.h (cgraph_node): Add ifunc_resolver.
	(cgraph_node::only_called_directly_or_aliased_p): Return false
	for IFUNC resolver.
	* lto-cgraph.c (input_node): Set ifunc_resolver for ifunc
	attribute.
	* symtab.c (symtab_node::verify_base): Verify that ifunc_resolver
	is equivalent to lookup_attribute ("ifunc", DECL_ATTRIBUTES (decl)).
	(symtab_node::binds_to_current_def_p): Check ifunc_resolver
	instead of looking up ifunc attribute.

gcc/testsuite/

	Backport from mainline
	2018-05-24  Rainer Orth  

	* gcc.target/i386/pr85345.c: Require ifunc support.

	2018-05-22  H.J. Lu  

Re: [PATCH] POPCOUNT folding optimizations

[Jeff Law]

On 05/01/2018 02:42 AM, Marc Glisse wrote:
> (I am not a reviewer, just commenting)
But your comments are definitely appreciated!

> 
> On Fri, 9 Feb 2018, Roger Sayle wrote:
> 
>> The following patch implements a number of __builtin_popcount related
>> optimizations.
>> (i) popcount(x) == 0 can be simplified to x==0, and popcount(x) != 0 to
>> x!=0.
>> (ii) popcount(x&1) can be simplified to x&1, and for unsigned x,
>> popcount(x>>31) to x>>31.
>> (iii) popcount (x&6) + popcount(y&16) can be simplified to
>> popcount((x&6)|(y&16))
>>
>> These may seem obscure transformations, but performing these types of
>> POPCOUNT operations are often the performance critical steps in some
>> cheminformatics applications.
>>
>> To implement the above transformations I've introduced the
>> tree_nonzero_bits function, which is a tree-level version of rtlanal's
>> nonzero_bits used by the RTL optimizers.
> 
> I am wondering if this brings much, compared to just using
> get_nonzero_bits (works on INTEGER_CST / SSA_NAME, matched by
> with_possible_nonzero_bits). If we do decide to introduce this function,
> we probably want to use it in other places that currently use
> get_nonzero_bits as well...
> 
>> +    case NOP_EXPR:
>> +    case CONVERT_EXPR:
> 
> We have CASE_CONVERT: for this pair.
I've fixed this in Roger's patch.

> 
>> +    case LSHIFT_EXPR:
>> +  if (TREE_CODE (TREE_OPERAND (t, 1)) == INTEGER_CST)
> 
> Maybe check INTEGRAL_TYPE_P as well, like you did for PLUS_EXPR? Or was
> that also unnecessary for PLUS_EXPR?
While there may be cases where allowing an INTEGRAL_TYPE_P SSA_NAME for
the shift count would be helpful, I think it'd be exceedingly rare.

For operands of a PLUS_EXPR I think we're a lot more likely to be able
to do something useful with an SSA_NAME argument.


> 
>> +  return wi::neg_p (arg1)
>> + ? wi::rshift (nzbits, -arg1, TYPE_SIGN (type))
>> + : wi::lshift (nzbits, arg1);
> 
> I can see that fold-const.c already does something like that. I am
> surprised the sanitizer guys haven't asked that we just punt on negative
> values instead.
I'm leaving this as-is -- while I think negative shift counts are a bad
idea, handling them in any other way is likely going to result in a real
surprise in the result of the computation.


> 
>> +  /* popcount(X) + popcount(Y) is popcount(X|Y) when X must be
>> zero.  */
>> +  (simplify
>> +    (plus (popcount @0) (popcount @1))
> 
> We probably want :s on both popcount: if they are used in other places
> than just this addition, it is likely cheaper not to introduce a new
> call to popcount.
Yea.  I also verified the Roger's tests still work with the :s added.

> 
>> +  /* pocount(X) == 0 is X == 0, and related (in)equalities.  */
> 
> po+p+count
Fixed.

> 
>> +  (for cmp (le eq ne gt)
>> +   rep (eq eq ne ne)
>> +    (simplify
>> +  (cmp (popcount @0) zerop)
> 
> Might as well use integer_zerop when we know we are dealing with integers.
And fixed.


I've also re-bootstrapped Roger's patch and will be committing it shortly.

jeff

Re: [PATCH] PR fortan/85779 -- Fix NULL pointer dereference

[Janus Weil]

2018-05-24 2:24 GMT+02:00 Steve Kargl :
> Subject says it all.  OK to commit?

Ok with me.

Thanks,
Janus



> 2018-05-23  Steven G. Kargl  
>
> PR fortran/85779
> *decl.c (gfc_match_derived_decl): Fix NULL point dereference.
>
> 2018-05-23  Steven G. Kargl  
>
> PR fortran/85779
> * gfortran.dg/pr85779_1.f90: New test.
> * gfortran.dg/pr85779_2.f90: Ditto.
> * gfortran.dg/pr85779_3.f90: Ditto.
>
> --
> Steve

Re: [PATCH] PR fortran/85895 -- Check for valid errmsg entity

[Janus Weil]

2018-05-24 1:45 GMT+02:00 Steve Kargl :
> The attach patch fixes PR fortran/85895 and also addresses
> a nearby issue by resolving the expressions associated with
> the STAT= and ERRMSG= tags in SYNC statements.  OK to commit?

Looks good to me. Thanks for the patch!

Cheers,
Janus



> 2018-05-23  Steven G. Kargl  
>
> PR fortran/85895
> * resolve.c (resolve_sync): Resolve expression before checking for
> an error.
>
> 2018-05-23  Steven G. Kargl  
>
> PR fortran/85895
>
> * gfortran.dg/coarray_3.f90: Fix invalid testcase.
> * gfortran.dg/pr85895.f90: New test.
>
> --
> Steve

C++ PATCH for c++/85883, class tmpl args deduction fail with new

[Marek Polacek]

Here we were failing to deduce template arguments for a class, because the
code in build_new only handled the case when INIT had 1 element.  That works
for e.g. new auto (foo) or new Foo{1, 2}, but not new Foo(1, 2).  I noticed
that it works without "new" because we simply create a tree list of the
arguments and pass it down to do_auto_deduction (in build_functional_cast).
do_class_deduction is prepared to receive a tree list.

(Sorry if this is totally bogus.)

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

2018-05-24  Marek Polacek  

PR c++/85883
* init.c (build_new): Handle deducing a class with new
with more than one argument.

* g++.dg/cpp1z/class-deduction55.C: New test.
* g++.dg/cpp1z/class-deduction56.C: New test.
* g++.dg/cpp1z/class-deduction57.C: New test.

diff --git gcc/cp/init.c gcc/cp/init.c
index 3f1e49bae21..3b175f94ecb 100644
--- gcc/cp/init.c
+++ gcc/cp/init.c
@@ -3585,11 +3585,25 @@ build_new (vec **placement, tree type, 
tree nelts,
   if (auto_node)
{
  tree d_init = NULL_TREE;
- if (vec_safe_length (*init) == 1)
+ const size_t len = vec_safe_length (*init);
+ /* E.g. new auto(x) must have exactly one element, or
+a {} initializer will have one element.  */
+ if (len == 1)
{
  d_init = (**init)[0];
  d_init = resolve_nondeduced_context (d_init, complain);
}
+ /* For the rest, e.g. new A(1, 2, 3), create a list.  */
+ else if (len > 1)
+   {
+ unsigned int n;
+ tree t;
+ FOR_EACH_VEC_ELT (**init, n, t)
+   {
+ t = resolve_nondeduced_context (t, complain);
+ d_init = chainon (d_init, build_tree_list (NULL_TREE, t));
+   }
+   }
  type = do_auto_deduction (type, d_init, auto_node, complain);
}
 }
diff --git gcc/testsuite/g++.dg/cpp1z/class-deduction55.C 
gcc/testsuite/g++.dg/cpp1z/class-deduction55.C
index e69de29bb2d..a93d7203681 100644
--- gcc/testsuite/g++.dg/cpp1z/class-deduction55.C
+++ gcc/testsuite/g++.dg/cpp1z/class-deduction55.C
@@ -0,0 +1,15 @@
+// PR c++/85883
+// { dg-options -std=c++17 }
+
+template 
+struct Bar
+{
+  Bar(T) { }
+};
+
+int
+main ()
+{
+  auto x = Bar(1);
+  auto y = new Bar(3);
+}
diff --git gcc/testsuite/g++.dg/cpp1z/class-deduction56.C 
gcc/testsuite/g++.dg/cpp1z/class-deduction56.C
index e69de29bb2d..71dbfa1904d 100644
--- gcc/testsuite/g++.dg/cpp1z/class-deduction56.C
+++ gcc/testsuite/g++.dg/cpp1z/class-deduction56.C
@@ -0,0 +1,15 @@
+// PR c++/85883
+// { dg-options -std=c++17 }
+
+template 
+struct Bar
+{
+  Bar(T1, T2) { }
+};
+
+int
+main ()
+{
+  auto x = Bar(1, 2);
+  auto y = new Bar(3, 4);
+}
diff --git gcc/testsuite/g++.dg/cpp1z/class-deduction57.C 
gcc/testsuite/g++.dg/cpp1z/class-deduction57.C
index e69de29bb2d..200ba6c3536 100644
--- gcc/testsuite/g++.dg/cpp1z/class-deduction57.C
+++ gcc/testsuite/g++.dg/cpp1z/class-deduction57.C
@@ -0,0 +1,15 @@
+// PR c++/85883
+// { dg-options -std=c++17 }
+
+template 
+struct Bar
+{
+  Bar(T1, T2, T3) { }
+};
+
+int
+main ()
+{
+  auto x = Bar(1, 2, 3);
+  auto y = new Bar(3, 4, 5);
+}

Re: [PATCH][RFC] Radically simplify emission of balanced tree for switch statements.

[Martin Liška]

On 05/24/2018 02:28 PM, Rainer Orth wrote:

Hi Martin,


On 05/21/2018 01:18 PM, Rainer Orth wrote:

Hi Martin,


On 05/18/2018 03:55 PM, Rainer Orth wrote:

Hi Martin,


So the patch looks fine, only very very slightly binary is produced. I'm
going to install the patch so that
I can carry on more complex patches based on this one.


it seems you didn't properly test the testsuite part: I see

+UNRESOLVED: gcc.dg/tree-prof/update-loopch.c scan-tree-dump switchlower
"Removing basic block"
+UNRESOLVED: gcc.dg/tree-prof/update-loopch.c scan-tree-dump switchlower
"loop depth 1, count 3"
+UNRESOLVED: gcc.dg/tree-prof/update-loopch.c scan-tree-dump-not
switchlower "Invalid sum"
+UNRESOLVED: gcc.dg/tree-prof/update-loopch.c scan-tree-dump-not
switchlower "loop depth 1, count 2"

everywhere.  The log has

gcc.dg/tree-prof/update-loopch.c: dump file does not exist

Obviously you forgot the adapt the dg-final* files for the dumpfile
name.  If I do, three of the failures go away, but

FAIL: gcc.dg/tree-prof/update-loopch.c scan-tree-dump switchlower1
"Removing basic block"

remains (on 32 and 64-bit Linux/x86_64).

Please fix.

Rainer



Thanks for opened eyes, following patch will fix that.
It's quite obvious, I'll install it right after tests will finish.


unfortunately, it didn't fix either issue:

* The switchlower -> switchlower1 renames in the dg-final* lines
   (attached) are still necessary to avoid the UNRESOLVED errors.
   Although obvious, I haven't installed them since ...

* ... even so

FAIL: gcc.dg/tree-prof/update-loopch.c scan-tree-dump switchlower1 "Removing basic 
block"

   remains.

Rainer


Hi.

You are right, it's using -O2, thus your patch is right. Please install the
patch
after testing. It's obvious fix.


I've now installed the fix for the dumpfile renaming.  However, you've
still done nothing about the remaining failure.


Thanks. Is the last remaining one: gcc.dg/tree-prof/update-loopch.c?

Thanks,
Martin



Rainer

Re: [PATCH][RFC] Radically simplify emission of balanced tree for switch statements.

[Martin Liška]

On 05/21/2018 04:42 PM, Sudakshina Das wrote:

On 21/05/18 15:00, Rainer Orth wrote:

Hi Martin,


Thanks for opened eyes, following patch will fix that.
It's quite obvious, I'll install it right after tests will finish.


unfortunately, it didn't fix either issue:

* The switchlower -> switchlower1 renames in the dg-final* lines
   (attached) are still necessary to avoid the UNRESOLVED errors.
   Although obvious, I haven't installed them since ...

* ... even so

FAIL: gcc.dg/tree-prof/update-loopch.c scan-tree-dump switchlower1 "Removing basic 
block"

   remains.

[...]

You are right, it's using -O2, thus your patch is right. Please install the
patch
after testing. It's obvious fix.


But what about the remaining FAIL?



Sorry to add to this, but I have also observed the following failures on  
aarch64-none-elf, aarch64-none-linux-gnu and aarch64_be-none-elf targets 
bisected to this commit:

FAIL: gcc.dg/sancov/cmp0.c   -O0   scan-tree-dump-times optimized 
"__builtin___sanitizer_cov_trace_const_cmp" 7

FAIL: gcc.dg/sancov/cmp0.c   -O0   scan-tree-dump-times optimized 
"__builtin___sanitizer_cov_trace_switch \\(" 2

FAIL: gcc.dg/sancov/cmp0.c   -O0 -g   scan-tree-dump-times optimized 
"__builtin___sanitizer_cov_trace_const_cmp" 7

FAIL: gcc.dg/sancov/cmp0.c   -O0 -g   scan-tree-dump-times optimized 
"__builtin___sanitizer_cov_trace_switch \\(" 2

FAIL: gcc.dg/tree-ssa/pr77445-2.c scan-tree-dump-not thread3 "not considered"

FAIL: gcc.dg/tree-ssa/ssa-dom-thread-7.c scan-tree-dump-not vrp2 "Jumps 
threaded"

Sudi


Hi.

Sorry for the breakage, I'll fix it in couple of days.

Martin




Rainer

Re: [PATCH] libsanitizer: Use pre-computed size of struct ustat for Linux

[Jakub Jelinek]

On Thu, May 24, 2018 at 12:56:23PM -0700, H.J. Lu wrote:
> >> This patch uses pre-computed size of struct ustat for Linux.
> >>
> >>   PR sanitizer/85835
> >>   * sanitizer_common/sanitizer_platform_limits_posix.cc: Don't
> >>   include  for Linux.
> >>   (SIZEOF_STRUCT_USTAT): New.
> >>   (struct_ustat_sz): Use SIZEOF_STRUCT_USTAT for Linux.
> >
> > Ok, thanks.
> >
> 
> OK to backport to released branches?

Yes.

Jakub

C++ PATCH for c++/85842, -Wreturn-type, constexpr if, and generic lambda

[Jason Merrill]

In this testcase, the only returns are inside a constexpr if, and when
we're partially instantiating a generic lambda we don't mess with a
constexpr if with a dependent condition, so we don't see the returns.
Fixed by copying the relevant flags from the uninstantiated lambda.

Tested x86_64-pc-linux-gnu, applying to trunk and 8.
commit 788c94f8dc670e61c97654d3c42a0af4356ca88d
Author: Jason Merrill 
Date:   Thu May 24 10:50:08 2018 -0400

PR c++/85842 - -Wreturn-type, constexpr if and generic lambda.

* pt.c (tsubst_lambda_expr): Copy current_function_returns_* to
generic lambda.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index d1181055af4..01a3ad92439 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -17636,6 +17636,17 @@ tsubst_lambda_expr (tree t, tree args, tsubst_flags_t complain, tree in_decl)
 
   register_parameter_specializations (oldfn, fn);
 
+  if (oldtmpl)
+	{
+	  /* We might not partially instantiate some parts of the function, so
+	 copy these flags from the original template.  */
+	  language_function *ol = DECL_STRUCT_FUNCTION (oldfn)->language;
+	  current_function_returns_value = ol->returns_value;
+	  current_function_returns_null = ol->returns_null;
+	  current_function_returns_abnormally = ol->returns_abnormally;
+	  current_function_infinite_loop = ol->infinite_loop;
+	}
+
   tsubst_expr (DECL_SAVED_TREE (oldfn), args, complain, r,
 		   /*constexpr*/false);
 
diff --git a/gcc/testsuite/g++.dg/cpp1z/constexpr-if23.C b/gcc/testsuite/g++.dg/cpp1z/constexpr-if23.C
new file mode 100644
index 000..8e31db3e863
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/constexpr-if23.C
@@ -0,0 +1,13 @@
+// PR c++/85842
+// { dg-additional-options -std=c++17 }
+
+template
+auto f = [](auto&& arg) -> T* {
+if constexpr (sizeof(arg) == 1) {
+return nullptr;
+} else {
+return static_cast();
+}
+};
+
+auto p = f(0);

[Patch, Fortran] PR 85849: [F2018] warn for obsolescent features

[Janus Weil]

Hi all,

just because 2018 seems like a good time to do that, I continue
plucking some of the low-hanging Fortran 2018 fruit. The attached
patch adds obsolescence warnings for all major F18 obsolescences
(COMMON, BLOCK DATA, EQUIVALENCE, FORALL, labeled DO). Those warnings
appear only with -std=f2018, but not with gfortran's default -std=gnu.
They currently have zero impact on the gfortran test suite, so I'm
adding a new test case to check for their existence.

Regtests cleanly on x86_64-linux-gnu. Ok for trunk?

Cheers,
Janus


2018-05-24  Janus Weil  

PR fortran/85839
* match.c (gfc_match_block_data): Call gfc_notify_std to warn about
an obsolescent feature in Fortran 2018.
(gfc_match_equivalence): Ditto.
* resolve.c (resolve_common_blocks): Ditto.
(gfc_resolve_forall): Ditto.
* symbol.c (gfc_define_st_label): Ditto.


2018-05-24  Janus Weil  

PR fortran/85839
* gfortran.dg/f2018_obs.f90: New test case.
Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c	(revision 260623)
+++ gcc/fortran/match.c	(working copy)
@@ -5259,6 +5259,10 @@ gfc_match_block_data (void)
   gfc_symbol *sym;
   match m;
 
+  if (!gfc_notify_std (GFC_STD_F2018_OBS, "BLOCK DATA construct at %L",
+  _current_locus))
+return MATCH_ERROR;
+
   if (gfc_match_eos () == MATCH_YES)
 {
   gfc_new_block = NULL;
@@ -5575,6 +5579,9 @@ gfc_match_equivalence (void)
 	}
 }
 
+  if (!gfc_notify_std (GFC_STD_F2018_OBS, "EQUIVALENCE statement at %C"))
+return MATCH_ERROR;
+
   return MATCH_YES;
 
 syntax:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c	(revision 260623)
+++ gcc/fortran/resolve.c	(working copy)
@@ -997,6 +997,10 @@ resolve_common_blocks (gfc_symtree *common_root)
 
   resolve_common_vars (common_root->n.common, true);
 
+  if (!gfc_notify_std (GFC_STD_F2018_OBS, "COMMON block at %L",
+		   _root->n.common->where))
+return;
+
   /* The common name is a global name - in Fortran 2003 also if it has a
  C binding name, since Fortran 2008 only the C binding name is a global
  identifier.  */
@@ -9928,6 +9932,9 @@ gfc_resolve_forall (gfc_code *code, gfc_namespace
 
   old_nvar = nvar;
 
+  if (!gfc_notify_std (GFC_STD_F2018_OBS, "FORALL construct at %L", >loc))
+return;
+
   /* Start to resolve a FORALL construct   */
   if (forall_save == 0)
 {
Index: gcc/fortran/symbol.c
===
--- gcc/fortran/symbol.c	(revision 260623)
+++ gcc/fortran/symbol.c	(working copy)
@@ -2725,6 +2725,10 @@ gfc_define_st_label (gfc_st_label *lp, gfc_sl_type
   "DO termination statement which is not END DO"
   " or CONTINUE with label %d at %C", labelno))
 	return;
+	  if (type == ST_LABEL_DO_TARGET
+	  && !gfc_notify_std (GFC_STD_F2018_OBS, "Labeled DO statement "
+  "at %L", label_locus))
+	return;
 	  break;
 
 	default:
! { dg-do compile }
! { dg-do options "-std=f2018" }
!
! PR 85839: [F2018] warn for obsolescent features
!
! Contributed by Janus Weil 

block data   ! { dg-warning "obsolescent feature" }
  common /a/ y(3)! { dg-warning "obsolescent feature" }
  data y /3*1./
end

program f2018_obs

  implicit none
  integer :: a(10),b(10),j(8),i
  real :: x(3)
  common /c/ x   ! { dg-warning "obsolescent feature" }

  equivalence (a(10),b(1))   ! { dg-warning "obsolescent feature" }

  do 99 i=1,10
99 continue  ! { dg-warning "obsolescent feature" }

  j = (/ 0, 1, 2, 3, 4, 0, 6, 7  /)
  forall (i=1:8, j(i) /= 0)  ! { dg-warning "obsolescent feature" }
j(i) = 0
  end forall
end

Re: [PATCH] libsanitizer: Use pre-computed size of struct ustat for Linux

[H.J. Lu]

On Thu, May 24, 2018 at 11:32 AM, Jakub Jelinek  wrote:
> On Thu, May 24, 2018 at 11:20:02AM -0700, H.J. Lu wrote:
>> Here is the patch cherry-picked from compiler-rt revision 333213.
>> OK for trunk?
>>
>> Thanks.
>>
>>
>> --
>> H.J.
>
>> From 9569b61168b963a6cea7b782fd350dee489ad42c Mon Sep 17 00:00:00 2001
>> From: "H.J. Lu" 
>> Date: Mon, 21 May 2018 13:17:55 -0700
>> Subject: [PATCH] libsanitizer: Use pre-computed size of struct ustat for 
>> Linux
>>
>> Cherry-pick compiler-rt revision 333213:
>>
>>  has been removed from glibc 2.28 by:
>>
>> commit cf2478d53ad7071e84c724a986b56fe17f4f4ca7
>> Author: Adhemerval Zanella 
>> Date:   Sun Mar 18 11:28:59 2018 +0800
>>
>> Deprecate ustat syscall interface
>>
>> This patch uses pre-computed size of struct ustat for Linux.
>>
>>   PR sanitizer/85835
>>   * sanitizer_common/sanitizer_platform_limits_posix.cc: Don't
>>   include  for Linux.
>>   (SIZEOF_STRUCT_USTAT): New.
>>   (struct_ustat_sz): Use SIZEOF_STRUCT_USTAT for Linux.
>
> Ok, thanks.
>

OK to backport to released branches?


-- 
H.J.

Re: [PATCH, alpha] PR target/85095

[Jeff Law]

On 05/24/2018 01:17 PM, co...@sdf.org wrote:
> On Thu, May 24, 2018 at 12:48:22PM -0600, Jeff Law wrote:
>> On 05/24/2018 07:54 AM, Maya Rashish wrote:
>>> Move linux-specific specfile definitions to linux.h
>>> gcc/config/alpha/linux.h (STARTFILE_SPEC, ENDFILE_SPEC) move from 
>>> alpha/elf.h
>>> ---
>>>  gcc/config/alpha/elf.h   | 26 --
>>>  gcc/config/alpha/linux.h | 26 ++
>>>  2 files changed, 26 insertions(+), 26 deletions(-)
>> So is there going to be some kind of follow-up to fix freebsd, netbsd
>> and openbsd which currently get their STARTFILE/ENDFILE from elf.h?
>>
>> jeff
> 
> I can try to fix openbsd soon, but freebsd dropped alpha in 2009.
> How does gcc feel about me picking up patches from openbsd ports, their
> package manager, that weren't written by myself?
So ISTM we should deprecate freebsd alpha.

WRT picking up bits from others.  It'd really depend on their size and
complexity -- I'd have to see them to be able to judge.  I'll review if
you extract the necessary bits and submit them.

Jeff

Re: [PATCH, alpha] PR target/85095

[coypu]

On Thu, May 24, 2018 at 12:48:22PM -0600, Jeff Law wrote:
> On 05/24/2018 07:54 AM, Maya Rashish wrote:
> > Move linux-specific specfile definitions to linux.h
> > gcc/config/alpha/linux.h (STARTFILE_SPEC, ENDFILE_SPEC) move from 
> > alpha/elf.h
> > ---
> >  gcc/config/alpha/elf.h   | 26 --
> >  gcc/config/alpha/linux.h | 26 ++
> >  2 files changed, 26 insertions(+), 26 deletions(-)
> So is there going to be some kind of follow-up to fix freebsd, netbsd
> and openbsd which currently get their STARTFILE/ENDFILE from elf.h?
> 
> jeff

I can try to fix openbsd soon, but freebsd dropped alpha in 2009.
How does gcc feel about me picking up patches from openbsd ports, their
package manager, that weren't written by myself?

Re: [PATCH, alpha] PR target/85095

[Jeff Law]

On 05/24/2018 07:54 AM, Maya Rashish wrote:
> Move linux-specific specfile definitions to linux.h
> gcc/config/alpha/linux.h (STARTFILE_SPEC, ENDFILE_SPEC) move from alpha/elf.h
> ---
>  gcc/config/alpha/elf.h   | 26 --
>  gcc/config/alpha/linux.h | 26 ++
>  2 files changed, 26 insertions(+), 26 deletions(-)
So is there going to be some kind of follow-up to fix freebsd, netbsd
and openbsd which currently get their STARTFILE/ENDFILE from elf.h?

jeff

Re: [PATCH] PR target/85904: Fix configure when cross compiling for netbsd

[coypu]

On Thu, May 24, 2018 at 06:31:25PM +0100, Jonathan Wakely wrote:
> On 24/05/18 16:14 +0100, Jonathan Wakely wrote:
> > On 24/05/18 13:14 +, co...@sdf.org wrote:
> > > In the past I was asked to post bugzilla patches here. I am doing this.
> > > It fixes a build failure.
> > > 
> > > PR target/85904
> > > libstdc++-v3/crossconfig.m4: test for aligned_alloc on netbsd
> > > libstdc++-v3/configure: Regenerate
> > > 
> > > Attached is patch.
> > 
> > Thanks for the patch. We made a similar fix for FreeBSD recently, so
> > I'll commit this for you.
> 
> For consistency with freebsd and mingw what I committed to trunk has
> the AC_CHECK_FUNCS at the end of the netbsd section. Could you check
> it still works please? (I'm unable to build a netbsd cross-compiler
> for some reason).

It works, thank you!

Re: [PATCH] Check ifunc_resolver only on FUNCTION_DECL

[Jeff Law]

On 05/24/2018 05:43 AM, H.J. Lu wrote:
> Since ifunc_resolver is only valid on FUNCTION_DECL, check ifunc_resolver
> only on FUNCTION_DECL.
> 
> Please test it on Darwin.
> 
> 
> H.J.
> ---
>   PR target/85900
>   PR target/85345
>   * varasm.c (assemble_alias): Check ifunc_resolver only on
>   FUNCTION_DECL.
OK.
jeff

Re: [C++ PATCH] Pedwarn on a non-standard position of a C++ attribute.

[Jason Merrill]

OK.

On Thu, May 24, 2018 at 1:03 PM, Ville Voutilainen
 wrote:
> On 24 May 2018 at 19:57, Nathan Sidwell  wrote:
>> On 05/24/2018 10:48 AM, Ville Voutilainen wrote:
>>>
>>> Tested manually on Linux-x64, finishing testing with the full suite
>>> on Linux-PPC64. Ok for trunk?
>>>
>>> 2018-05-24  Ville Voutilainen  
>>>
>>>  gcc/cp/
>>>
>>>  Pedwarn on a non-standard position of a C++ attribute.
>>>  * parser.c (cp_parser_namespace_definition): Pedwarn about attributes
>>>  after the namespace name.
>>>
>>>  testsuite/
>>>
>>>  Pedwarn on a non-standard position of a C++ attribute.
>>>  * g++.dg/cpp1z/namespace-attribs2.C: New.
>>>
>>
>> ok, thanks
>
> The full suite run revealed a couple of adjustments:
>
> 2018-05-24  Ville Voutilainen  
>
> gcc/cp/
>
> Pedwarn on a non-standard position of a C++ attribute.
> * parser.c (cp_parser_namespace_definition): Pedwarn about attributes
> after the namespace name.
>
> testsuite/
>
> Pedwarn on a non-standard position of a C++ attribute.
> * g++.dg/cpp0x/gen-attrs-56.C: Adjust.
> * g++.dg/cpp0x/gen-attrs-64.C: Likewise.
> * g++.dg/cpp1z/namespace-attribs2.C: New.

Re: [PATCH] libsanitizer: Use pre-computed size of struct ustat for Linux

[Jakub Jelinek]

On Thu, May 24, 2018 at 11:20:02AM -0700, H.J. Lu wrote:
> Here is the patch cherry-picked from compiler-rt revision 333213.
> OK for trunk?
> 
> Thanks.
> 
> 
> -- 
> H.J.

> From 9569b61168b963a6cea7b782fd350dee489ad42c Mon Sep 17 00:00:00 2001
> From: "H.J. Lu" 
> Date: Mon, 21 May 2018 13:17:55 -0700
> Subject: [PATCH] libsanitizer: Use pre-computed size of struct ustat for Linux
> 
> Cherry-pick compiler-rt revision 333213:
> 
>  has been removed from glibc 2.28 by:
> 
> commit cf2478d53ad7071e84c724a986b56fe17f4f4ca7
> Author: Adhemerval Zanella 
> Date:   Sun Mar 18 11:28:59 2018 +0800
> 
> Deprecate ustat syscall interface
> 
> This patch uses pre-computed size of struct ustat for Linux.
> 
>   PR sanitizer/85835
>   * sanitizer_common/sanitizer_platform_limits_posix.cc: Don't
>   include  for Linux.
>   (SIZEOF_STRUCT_USTAT): New.
>   (struct_ustat_sz): Use SIZEOF_STRUCT_USTAT for Linux.

Ok, thanks.

Jakub

[PATCH] libsanitizer: Use pre-computed size of struct ustat for Linux

[H.J. Lu]

On Tue, May 22, 2018 at 6:00 AM, Jakub Jelinek  wrote:
> On Tue, May 22, 2018 at 05:37:03AM -0700, H.J. Lu wrote:
>>  has been removed from glibc 2.28 by:
>>
>> commit cf2478d53ad7071e84c724a986b56fe17f4f4ca7
>> Author: Adhemerval Zanella 
>> Date:   Sun Mar 18 11:28:59 2018 +0800
>>
>> Deprecate ustat syscall interface
>>
>> This patch removes its reference from libsanitizer for Linux.
>>
>> The LLVM patch is posted at
>>
>> https://reviews.llvm.org/D47165
>>
>> OK for trunk?
>
> Please wait on whatever upstream accepts, then it can be cherry-picked.
>

Here is the patch cherry-picked from compiler-rt revision 333213.
OK for trunk?

Thanks.


-- 
H.J.
From 9569b61168b963a6cea7b782fd350dee489ad42c Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Mon, 21 May 2018 13:17:55 -0700
Subject: [PATCH] libsanitizer: Use pre-computed size of struct ustat for Linux

Cherry-pick compiler-rt revision 333213:

 has been removed from glibc 2.28 by:

commit cf2478d53ad7071e84c724a986b56fe17f4f4ca7
Author: Adhemerval Zanella 
Date:   Sun Mar 18 11:28:59 2018 +0800

Deprecate ustat syscall interface

This patch uses pre-computed size of struct ustat for Linux.

	PR sanitizer/85835
	* sanitizer_common/sanitizer_platform_limits_posix.cc: Don't
	include  for Linux.
	(SIZEOF_STRUCT_USTAT): New.
	(struct_ustat_sz): Use SIZEOF_STRUCT_USTAT for Linux.
---
 .../sanitizer_platform_limits_posix.cc| 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc
index 858bb218450..de18e56d11c 100644
--- a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc
+++ b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc
@@ -157,7 +157,6 @@ typedef struct user_fpregs elf_fpregset_t;
 # include 
 #endif
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -250,7 +249,19 @@ namespace __sanitizer {
 #endif // SANITIZER_LINUX || SANITIZER_FREEBSD
 
 #if SANITIZER_LINUX && !SANITIZER_ANDROID
-  unsigned struct_ustat_sz = sizeof(struct ustat);
+  // Use pre-computed size of struct ustat to avoid  which
+  // has been removed from glibc 2.28.
+#if defined(__aarch64__) || defined(__s390x__) || defined (__mips64) \
+  || defined(__powerpc64__) || defined(__arch64__) || defined(__sparcv9) \
+  || defined(__x86_64__)
+#define SIZEOF_STRUCT_USTAT 32
+#elif defined(__arm__) || defined(__i386__) || defined(__mips__) \
+  || defined(__powerpc__) || defined(__s390__)
+#define SIZEOF_STRUCT_USTAT 20
+#else
+#error Unknown size of struct ustat
+#endif
+  unsigned struct_ustat_sz = SIZEOF_STRUCT_USTAT;
   unsigned struct_rlimit64_sz = sizeof(struct rlimit64);
   unsigned struct_statvfs64_sz = sizeof(struct statvfs64);
 #endif // SANITIZER_LINUX && !SANITIZER_ANDROID
-- 
2.17.0

[PATCH, i386]: FIx PR85903]: FAIL: gcc.target/i386/avx512dq-vcvtuqq2pd-2.c

[Uros Bizjak]

Hello!

my recent patch exposed a problem in movdi_to_sse pattern, where
post-reload splitter tries to generate a pseudo, which is in fact not
needed.

2018-05-24  Uros Bizjak  

PR target/85903
* config/i386/sse.md (movdi_to_sse): Do not generate pseudo
when memory input operand is handled.

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

Committed to mainline SVN, will be backported to release branches.

Uros.
diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 8a80fa35067..9750708a80f 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -1248,11 +1248,8 @@
 operands[2]));
}
  else if (memory_operand (operands[1], DImode))
-   {
- rtx tmp = gen_reg_rtx (V2DImode);
- emit_insn (gen_vec_concatv2di (tmp, operands[1], const0_rtx));
- emit_move_insn (operands[0], gen_lowpart (V4SImode, tmp));
-   }
+   emit_insn (gen_vec_concatv2di (gen_lowpart (V2DImode, operands[0]),
+ operands[1], const0_rtx));
  else
gcc_unreachable ();
  DONE;

Re: [PATCH] PR target/85904: Fix configure when cross compiling for netbsd

[Jonathan Wakely]

On 24/05/18 16:14 +0100, Jonathan Wakely wrote:

On 24/05/18 13:14 +, co...@sdf.org wrote:

In the past I was asked to post bugzilla patches here. I am doing this.
It fixes a build failure.

PR target/85904
libstdc++-v3/crossconfig.m4: test for aligned_alloc on netbsd
libstdc++-v3/configure: Regenerate

Attached is patch.


Thanks for the patch. We made a similar fix for FreeBSD recently, so
I'll commit this for you.


For consistency with freebsd and mingw what I committed to trunk has
the AC_CHECK_FUNCS at the end of the netbsd section. Could you check
it still works please? (I'm unable to build a netbsd cross-compiler
for some reason).


commit 56c5a530fd7b6813ccdb712c7d37d89fa59a80f7
Author: Jonathan Wakely 
Date:   Thu May 24 16:33:50 2018 +0100

PR target/85904 check for aligned_alloc on netbsd cross-compilation

2018-05-24  Maya Rashish  

PR target/85904
* crossconfig.m4: Test for aligned_alloc on netbsd.
* configure: Regenerate.

diff --git a/libstdc++-v3/crossconfig.m4 b/libstdc++-v3/crossconfig.m4
index f0a55c68404..669d87f7602 100644
--- a/libstdc++-v3/crossconfig.m4
+++ b/libstdc++-v3/crossconfig.m4
@@ -218,6 +218,7 @@ case "${host}" in
   AC_DEFINE(HAVE_ISINFL)
   AC_DEFINE(HAVE_ISNANL)
 fi
+AC_CHECK_FUNCS(aligned_alloc posix_memalign memalign _aligned_malloc)
 ;;
   *-qnx6.1* | *-qnx6.2*)
 SECTION_FLAGS='-ffunction-sections -fdata-sections'

Re: [PATCH] testsuite: Introduce be/le selectors

[Segher Boessenkool]

On Wed, May 23, 2018 at 10:07:18AM +0100, Richard Earnshaw (lists) wrote:
> On 22/05/18 22:21, Jeff Law wrote:
> > On 05/21/2018 03:46 PM, Segher Boessenkool wrote:
> >> This patch creates "be" and "le" selectors, which can be used by all
> >> architectures, similar to ilp32 and lp64.

> >> 2017-05-21  Segher Boessenkool  
> >>
> >> gcc/testsuite/
> >>* lib/target-supports.exp (check_effective_target_be): New.
> >>(check_effective_target_le): New.
> > I think this is fine.  "be" "le" are used all over the place in gcc and
> > the kernel to denote big/little endian.
> 
> except when el and eb are used for perversity... :-)

It should have been -BE and -EL, because that is what it means.  That
also avoids the -l/-L problem -le and -LE would have ;-)

(Confusing?  Yes, little-endian is confusing).


Segher

Re: [PATCH] consider MIN_EXPR in get_size_range() (PR 85888)

[Richard Biener]

On May 24, 2018 7:02:17 PM GMT+02:00, Martin Sebor  wrote:
>On 05/24/2018 03:39 AM, Richard Biener wrote:
>> On Thu, May 24, 2018 at 12:50 AM Martin Sebor 
>wrote:
>>
>>> The attached patch enhances the get_size_range() function to
>>> extract more accurate ranges out of MIN_EXPR and MAX_EXPR nodes
>>> with SSA_NAME operand(s).  This helps -Wstringop-overflow avoid
>>> false positives on some targets in cases like some of those
>>> reported in bug 85623 - strncmp() warns about attribute nonstring
>>> incorrectly in -Wstringop-overflow
>>
>>> When first trying to expand calls to __builtin_strncmp, most back
>>> ends succeed even when the expansion results in a call to the
>library
>>> function.  The powerpc64 back-end, however, fails and and allows
>>> the generic expansion to take place.  There is a subtle difference
>>> between the two cases that shows up when examining the bound of
>>> the strncmp call expression (the third argument): in the original
>>> call expression (in expand_builtin_strncmp) the bound is or can be
>>> an SSA_NAME.  But when the early expansion fails,
>>> expand_builtin_strncmp transforms the original call expression into
>>> a new one, substituting MIN_EXPR (bound, CST) for the bound where
>>> CST is the constant result of strlen (STR), with STR being either
>>> the first or second strncmp argument.  When the bound is an SSA_NAME
>>> the subsequent attempt to determine its range from the MIN_EXPR
>fails.
>>
>> Hmm, wouldn't sth extracted from the attached random patch I have
>lying
>> around be more useful in general?  That is, refactor the GENERIC
>> expression walk in determine_value_range_1 to sth that can be used
>> in the current get_range_info () interface?  Or if we don't want to
>change
>> that to accept non-SSA names add a corresponding get_expr_range_info
>()
>> interface.
>
>Thanks.  It is certainly more general.  I'm just not sure how much
>use the generality can be put to because...
>
>> If you do that please cut out the dominator/loop condition handling
>and
>> refrain from the idea of looking at SSA def stmts.
>
>...I've done that but I'm having trouble exercising the code except
>for this bug.  (I've run the C testsuite but the only tests that end
>up in it call it with uninteresting arguments like VAR_DECL).  Do
>you have any suggestions?

Well, what builds the MIN_EXPR for your testcase? I orinigally used it for 
niters analysis which deals with complex GENERIC expressions. If you just 
changed get_range_info then of course callers are guarded with SSA name checks. 

>Martin
>
>PS I was able to create a test that at -O0 could call it with
>a more interesting argument such as:
>
>   const __SIZE_TYPE__ i = 3, j = 5;
>
>   int f (void)
>   {
> return __builtin_strncmp ("1234", "123", i < j ? i : j);
>   }
>
>Here, the first call to gimple_fold_builtin_string_compare() that
>I picked as a test case sees:
>
>   j.0_1 = 5;
>   i.1_2 = 3;
>   _3 = MIN_EXPR ;
>   D.1963 = __builtin_strncmp ("1234", "123", _3);
>
>Above, _3's range info is not available yet at this point so
>the expression could be evaluated but only by looking at def stmts.
>Why is it not a good idea?

Because it raises complexity concerns unless you also populate intermediate SSA 
range Infos and stop at present ones. And you can't deal with conditional info 
as the patch tries to do (but I wouldn't keep that either initially). 

Richard. 

>
>Martin

Re: [C++ PATCH] Pedwarn on a non-standard position of a C++ attribute.

[Ville Voutilainen]

On 24 May 2018 at 19:57, Nathan Sidwell  wrote:
> On 05/24/2018 10:48 AM, Ville Voutilainen wrote:
>>
>> Tested manually on Linux-x64, finishing testing with the full suite
>> on Linux-PPC64. Ok for trunk?
>>
>> 2018-05-24  Ville Voutilainen  
>>
>>  gcc/cp/
>>
>>  Pedwarn on a non-standard position of a C++ attribute.
>>  * parser.c (cp_parser_namespace_definition): Pedwarn about attributes
>>  after the namespace name.
>>
>>  testsuite/
>>
>>  Pedwarn on a non-standard position of a C++ attribute.
>>  * g++.dg/cpp1z/namespace-attribs2.C: New.
>>
>
> ok, thanks

The full suite run revealed a couple of adjustments:

2018-05-24  Ville Voutilainen  

gcc/cp/

Pedwarn on a non-standard position of a C++ attribute.
* parser.c (cp_parser_namespace_definition): Pedwarn about attributes
after the namespace name.

testsuite/

Pedwarn on a non-standard position of a C++ attribute.
* g++.dg/cpp0x/gen-attrs-56.C: Adjust.
* g++.dg/cpp0x/gen-attrs-64.C: Likewise.
* g++.dg/cpp1z/namespace-attribs2.C: New.
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 6f51f03..ac68159 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -18588,6 +18588,11 @@ cp_parser_namespace_definition (cp_parser* parser)
 	{
 	  identifier = cp_parser_identifier (parser);
 
+	  if (cp_next_tokens_can_be_std_attribute_p (parser))
+	  pedwarn (input_location, OPT_Wpedantic,
+		   "standard attributes on namespaces must precede "
+		   "the namespace name");
+
 	  /* Parse any attributes specified after the identifier.  */
 	  attribs = attr_chainon (attribs, cp_parser_attributes_opt (parser));
 	}
diff --git a/gcc/testsuite/g++.dg/cpp0x/gen-attrs-56.C b/gcc/testsuite/g++.dg/cpp0x/gen-attrs-56.C
index f331ed3..f63fff4 100644
--- a/gcc/testsuite/g++.dg/cpp0x/gen-attrs-56.C
+++ b/gcc/testsuite/g++.dg/cpp0x/gen-attrs-56.C
@@ -2,4 +2,4 @@
 // { dg-do compile { target c++11 } }
 
 namespace foo __attribute__((visibility("default"))) {}
-namespace bar [[gnu::visibility("default")]] {}
+namespace [[gnu::visibility("default")]] bar {}
diff --git a/gcc/testsuite/g++.dg/cpp0x/gen-attrs-64.C b/gcc/testsuite/g++.dg/cpp0x/gen-attrs-64.C
index c0d48fc..4b335eb 100644
--- a/gcc/testsuite/g++.dg/cpp0x/gen-attrs-64.C
+++ b/gcc/testsuite/g++.dg/cpp0x/gen-attrs-64.C
@@ -1,4 +1,4 @@
 // PR c++/85140
 // { dg-do compile { target c++11 } }
 
-namespace N alignas() {}	// { dg-error "expected" }
+namespace alignas() N  {}	// { dg-error "expected" }
diff --git a/gcc/testsuite/g++.dg/cpp1z/namespace-attribs2.C b/gcc/testsuite/g++.dg/cpp1z/namespace-attribs2.C
new file mode 100644
index 000..2049da3
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/namespace-attribs2.C
@@ -0,0 +1,7 @@
+// { dg-options "-std=c++17" }
+// { dg-additional-options "-pedantic" }
+
+namespace B [[deprecated]] {} // { dg-warning "ignored|must precede" }
+
+namespace [[deprecated]] D {} // { dg-warning "ignored" }
+

Re: [PATCH] consider MIN_EXPR in get_size_range() (PR 85888)

[Martin Sebor]

On 05/24/2018 03:39 AM, Richard Biener wrote:

On Thu, May 24, 2018 at 12:50 AM Martin Sebor  wrote:


The attached patch enhances the get_size_range() function to
extract more accurate ranges out of MIN_EXPR and MAX_EXPR nodes
with SSA_NAME operand(s).  This helps -Wstringop-overflow avoid
false positives on some targets in cases like some of those
reported in bug 85623 - strncmp() warns about attribute nonstring
incorrectly in -Wstringop-overflow



When first trying to expand calls to __builtin_strncmp, most back
ends succeed even when the expansion results in a call to the library
function.  The powerpc64 back-end, however, fails and and allows
the generic expansion to take place.  There is a subtle difference
between the two cases that shows up when examining the bound of
the strncmp call expression (the third argument): in the original
call expression (in expand_builtin_strncmp) the bound is or can be
an SSA_NAME.  But when the early expansion fails,
expand_builtin_strncmp transforms the original call expression into
a new one, substituting MIN_EXPR (bound, CST) for the bound where
CST is the constant result of strlen (STR), with STR being either
the first or second strncmp argument.  When the bound is an SSA_NAME
the subsequent attempt to determine its range from the MIN_EXPR fails.


Hmm, wouldn't sth extracted from the attached random patch I have lying
around be more useful in general?  That is, refactor the GENERIC
expression walk in determine_value_range_1 to sth that can be used
in the current get_range_info () interface?  Or if we don't want to change
that to accept non-SSA names add a corresponding get_expr_range_info ()
interface.


Thanks.  It is certainly more general.  I'm just not sure how much
use the generality can be put to because...


If you do that please cut out the dominator/loop condition handling and
refrain from the idea of looking at SSA def stmts.


...I've done that but I'm having trouble exercising the code except
for this bug.  (I've run the C testsuite but the only tests that end
up in it call it with uninteresting arguments like VAR_DECL).  Do
you have any suggestions?

Martin

PS I was able to create a test that at -O0 could call it with
a more interesting argument such as:

  const __SIZE_TYPE__ i = 3, j = 5;

  int f (void)
  {
return __builtin_strncmp ("1234", "123", i < j ? i : j);
  }

Here, the first call to gimple_fold_builtin_string_compare() that
I picked as a test case sees:

  j.0_1 = 5;
  i.1_2 = 3;
  _3 = MIN_EXPR ;
  D.1963 = __builtin_strncmp ("1234", "123", _3);

Above, _3's range info is not available yet at this point so
the expression could be evaluated but only by looking at def stmts.
Why is it not a good idea?

Martin

Re: [C++ PATCH] Pedwarn on a non-standard position of a C++ attribute.

[Nathan Sidwell]

On 05/24/2018 10:48 AM, Ville Voutilainen wrote:

Tested manually on Linux-x64, finishing testing with the full suite
on Linux-PPC64. Ok for trunk?

2018-05-24  Ville Voutilainen  

 gcc/cp/

 Pedwarn on a non-standard position of a C++ attribute.
 * parser.c (cp_parser_namespace_definition): Pedwarn about attributes
 after the namespace name.

 testsuite/

 Pedwarn on a non-standard position of a C++ attribute.
 * g++.dg/cpp1z/namespace-attribs2.C: New.



ok, thanks

nathan
--
Nathan Sidwell

[PATCH] Implement P0558R2 changes to std::atomic

[Jonathan Wakely]

The restrictions forbidding arithmetic on atomic pointer types are only
enabled for C++17 and later, retaining the GNU extension for older
standards. The new nested typedefs and changes to prevent scalar
parameters participating in template argument deduction are enabled
unconditionally.

PR libstdc++/69769
PR libstdc++/85886
* include/bits/atomic_base.h (__atomic_base::value_type)
(__atomic_base::difference_type): Add new typedefs.
* include/std/atomic (atomic::value_type, atomic::value_type)
(atomic::value_type, atomic::difference_type): Likewise.
(atomic::operator++, atomic::operator--)
(atomic::operator+=, atomic::operator-=)
(atomic::fetch_add, atomic::fetch_sub): Add static assertion
to enforce C++17 requirement on pointer arithmetic.
(__atomic_val_t, __atomic_diff_t): New alias templates.
(atomic_init, atomic_store_explicit, atomic_exchange_explicit)
(atomic_compare_exchange_weak_explicit)
(atomic_compare_exchange_strong_explicit, atomic_store)
(atomic_exchange, atomic_compare_exchange_weak)
(atomic_compare_exchange_strong): Use __atomic_val_t to make
scalar parameters be non-deduced contexts.
(atomic_fetch_add_explicit, atomic_fetch_sub_explicit)
(atomic_fetch_add, atomic_fetch_sub): Change first parameter to be
atomic instead of __atomic_base, and use __atomic_diff_t for scalar
parameters.
(atomic_fetch_and_explicit, atomic_fetch_or_explicit)
(atomic_fetch_xor_explicit, atomic_fetch_and, atomic_fetch_or)
(atomic_fetch_xor): Use __atomic_val_t for scalar parameters.
(atomic_fetch_add_explicit, atomic_fetch_sub_explicit)
(atomic_fetch_add, atomic_fetch_sub): Remove overloads for atomic
address types.
* testsuite/29_atomics/atomic/60695.cc: Adjust dg-error lineno.
* testsuite/29_atomics/atomic/69769.cc: New test.
* testsuite/29_atomics/atomic/nonmembers.cc: New test.
* testsuite/29_atomics/atomic/operators/pointer_partial_void.cc:
Disable test for C++17 and later.
* testsuite/29_atomics/atomic/requirements/typedefs.cc: New test.
* testsuite/29_atomics/atomic_integral/nonmembers.cc: New test.
* testsuite/29_atomics/atomic_integral/requirements/typedefs.cc: New
test.

Tested powerpc64le-linux, committed to trunk.

commit cc606c3ce7a562750bbb1e7b1cca960a853f8daf
Author: Jonathan Wakely 
Date:   Thu May 24 15:48:10 2018 +0100

Implement P0558R2 changes to std::atomic

The restrictions forbidding arithmetic on atomic pointer types are only
enabled for C++17 and later, retaining the GNU extension for older
standards. The new nested typedefs and changes to prevent scalar
parameters participating in template argument deduction are enabled
unconditionally.

PR libstdc++/69769
PR libstdc++/85886
* include/bits/atomic_base.h (__atomic_base::value_type)
(__atomic_base::difference_type): Add new typedefs.
* include/std/atomic (atomic::value_type, 
atomic::value_type)
(atomic::value_type, atomic::difference_type): Likewise.
(atomic::operator++, atomic::operator--)
(atomic::operator+=, atomic::operator-=)
(atomic::fetch_add, atomic::fetch_sub): Add static assertion
to enforce C++17 requirement on pointer arithmetic.
(__atomic_val_t, __atomic_diff_t): New alias templates.
(atomic_init, atomic_store_explicit, atomic_exchange_explicit)
(atomic_compare_exchange_weak_explicit)
(atomic_compare_exchange_strong_explicit, atomic_store)
(atomic_exchange, atomic_compare_exchange_weak)
(atomic_compare_exchange_strong): Use __atomic_val_t to make
scalar parameters be non-deduced contexts.
(atomic_fetch_add_explicit, atomic_fetch_sub_explicit)
(atomic_fetch_add, atomic_fetch_sub): Change first parameter to be
atomic instead of __atomic_base, and use __atomic_diff_t for scalar
parameters.
(atomic_fetch_and_explicit, atomic_fetch_or_explicit)
(atomic_fetch_xor_explicit, atomic_fetch_and, atomic_fetch_or)
(atomic_fetch_xor): Use __atomic_val_t for scalar parameters.
(atomic_fetch_add_explicit, atomic_fetch_sub_explicit)
(atomic_fetch_add, atomic_fetch_sub): Remove overloads for atomic
address types.
* testsuite/29_atomics/atomic/60695.cc: Adjust dg-error lineno.
* testsuite/29_atomics/atomic/69769.cc: New test.
* testsuite/29_atomics/atomic/nonmembers.cc: New test.
* testsuite/29_atomics/atomic/operators/pointer_partial_void.cc:
Disable test for C++17 and 

Re: [PATCH] PR target/85904: Fix configure when cross compiling for netbsd

[Jonathan Wakely]

On 24/05/18 13:14 +, co...@sdf.org wrote:

In the past I was asked to post bugzilla patches here. I am doing this.
It fixes a build failure.

PR target/85904
libstdc++-v3/crossconfig.m4: test for aligned_alloc on netbsd
libstdc++-v3/configure: Regenerate

Attached is patch.


Thanks for the patch. We made a similar fix for FreeBSD recently, so
I'll commit this for you.

I think this should be backported to all branches that detect
aligned_alloc for native compilers, to allow cross-compiling too.




From ac7a1f364b0ca5e3a6a5a68a16266d1cb78ee5da Mon Sep 17 00:00:00 2001

From: Maya Rashish 
Date: Thu, 24 May 2018 16:05:27 +0300
Subject: [PATCH 1/1] check for aligned_alloc on netbsd crosscompilation.

Fixes build issue:
/home/fly/gcc/libstdc++-v3/libsupc++/new_opa.cc:62:1: error: 'void* 
aligned_alloc(std::size_t, std::size_t)' was declared 'extern' and later 
'static' [-fpermissive]
aligned_alloc (std::size_t al, std::size_t sz)
^
In file included from /tmp/build/alpha--netbsd/libstdc++-v3/include/cstdlib:75,
from /tmp/build/alpha--netbsd/libstdc++-v3/include/stdlib.h:36,
from /home/fly/gcc/libstdc++-v3/libsupc++/new_opa.cc:27:
/tmp/build/gcc/include-fixed/stdlib.h:254:7: note: previous declaration of 
'void* aligned_alloc(size_t, size_t)'
void *aligned_alloc(size_t, size_t);
  ^
---
libstdc++-v3/configure  | 13 +
libstdc++-v3/crossconfig.m4 |  1 +
2 files changed, 14 insertions(+)

diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
index f3522ee..9fd6197169a 100755
--- a/libstdc++-v3/configure
+++ b/libstdc++-v3/configure
@@ -66150,6 +66150,19 @@ done
;;
  *-netbsd*)
SECTION_FLAGS='-ffunction-sections -fdata-sections'
+for ac_func in aligned_alloc posix_memalign memalign _aligned_malloc
+do :
+  as_ac_var=`$as_echo "ac_cv_func_$ac_func" | $as_tr_sh`
+ac_fn_c_check_func "$LINENO" "$ac_func" "$as_ac_var"
+eval as_val=\$$as_ac_var
+   if test "x$as_val" = x""yes; then :
+  cat >>confdefs.h <<_ACEOF
+#define `$as_echo "HAVE_$ac_func" | $as_tr_cpp` 1
+_ACEOF
+
+fi
+done
+


  # If we're not using GNU ld, then there's no point in even trying these
diff --git a/libstdc++-v3/crossconfig.m4 b/libstdc++-v3/crossconfig.m4
index f0a55c68404..dcc807eb76a 100644
--- a/libstdc++-v3/crossconfig.m4
+++ b/libstdc++-v3/crossconfig.m4
@@ -203,6 +203,7 @@ case "${host}" in
;;
  *-netbsd*)
SECTION_FLAGS='-ffunction-sections -fdata-sections'
+AC_CHECK_FUNCS(aligned_alloc posix_memalign memalign _aligned_malloc)
AC_SUBST(SECTION_FLAGS)
GLIBCXX_CHECK_LINKER_FEATURES
AC_DEFINE(HAVE_FINITEF)
--
2.17.0

Re: [PATCH] [AArch64, Falkor] Falkor address costs tuning

[Luis Machado]

On 05/23/2018 12:17 PM, James Greenhalgh wrote:

On Tue, May 22, 2018 at 12:04:38PM -0500, Luis Machado wrote:

Switch from using generic address costs to using Falkor-specific ones, which
give Falkor better results overall.

OK for trunk?

Given this is a Falkor-specific adjustment, would this be an acceptable
backport for GCC 8 as well?


OK for trunk.

It doesn't fix a regression, so it wouldn't really fit the definition of
a backport patch. That said, if it is important to you to have it in GCC 8,
it is sufficiently low-risk for non-Falkor targets that we can take it. So,
it is your call if you want to backport it or not.

Thanks,
James


Thanks. For now i've pushed it to mainline as r260675.

[C++ PATCH] Pedwarn on a non-standard position of a C++ attribute.

[Ville Voutilainen]

Tested manually on Linux-x64, finishing testing with the full suite
on Linux-PPC64. Ok for trunk?

2018-05-24  Ville Voutilainen  

gcc/cp/

Pedwarn on a non-standard position of a C++ attribute.
* parser.c (cp_parser_namespace_definition): Pedwarn about attributes
after the namespace name.

testsuite/

Pedwarn on a non-standard position of a C++ attribute.
* g++.dg/cpp1z/namespace-attribs2.C: New.
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 6f51f03..ac68159 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -18588,6 +18588,11 @@ cp_parser_namespace_definition (cp_parser* parser)
 	{
 	  identifier = cp_parser_identifier (parser);
 
+	  if (cp_next_tokens_can_be_std_attribute_p (parser))
+	  pedwarn (input_location, OPT_Wpedantic,
+		   "standard attributes on namespaces must precede "
+		   "the namespace name");
+
 	  /* Parse any attributes specified after the identifier.  */
 	  attribs = attr_chainon (attribs, cp_parser_attributes_opt (parser));
 	}
diff --git a/gcc/testsuite/g++.dg/cpp1z/namespace-attribs2.C b/gcc/testsuite/g++.dg/cpp1z/namespace-attribs2.C
new file mode 100644
index 000..2049da3
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/namespace-attribs2.C
@@ -0,0 +1,7 @@
+// { dg-options "-std=c++17" }
+// { dg-additional-options "-pedantic" }
+
+namespace B [[deprecated]] {} // { dg-warning "ignored|must precede" }
+
+namespace [[deprecated]] D {} // { dg-warning "ignored" }
+

C++ PATCH for c++/85864, literal template and default template arg

[Jason Merrill]

Another adjustment needed for my having removed the type from
NONTYPE_ARGUMENT_PACK: instantiation_dependent_r needs to ignore that
like it does for TREE_LIST.

Tested x86_64-pc-linux-gnu, applying to trunk and 8.
commit 9ebcb2b5403980ec25429c3f43bf951fae5772f8
Author: Jason Merrill 
Date:   Wed May 23 15:29:18 2018 -0400

PR c++/85864 - literal template and default template arg.

* pt.c (instantiation_dependent_r): Handle NONTYPE_ARGUMENT_PACK.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 0b04770e123..d1181055af4 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -25212,6 +25212,7 @@ instantiation_dependent_r (tree *tp, int *walk_subtrees,
 	 TREE_TYPE.  */
 case TREE_LIST:
 case TREE_VEC:
+case NONTYPE_ARGUMENT_PACK:
   return NULL_TREE;
 
 case TEMPLATE_PARM_INDEX:
diff --git a/gcc/testsuite/g++.dg/cpp1y/udlit-char-template2.C b/gcc/testsuite/g++.dg/cpp1y/udlit-char-template2.C
new file mode 100644
index 000..06c13261156
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/udlit-char-template2.C
@@ -0,0 +1,23 @@
+// PR c++/85864
+// { dg-do compile { target c++14 } }
+
+template struct String_template {};
+
+template
+constexpr String_template operator""_template() {
+return String_template {};
+}
+
+template
+int hex(T v) { return 1; }
+
+template 
+void tt2() {
+  //auto h2 = hex(1);
+auto h = hex(2);
+}
+
+int main() {
+  //auto h = hex(2);
+  //return h;
+}

[PATCH, alpha] PR target/85095

[Maya Rashish]

Move linux-specific specfile definitions to linux.h
gcc/config/alpha/linux.h (STARTFILE_SPEC, ENDFILE_SPEC) move from alpha/elf.h
---
 gcc/config/alpha/elf.h   | 26 --
 gcc/config/alpha/linux.h | 26 ++
 2 files changed, 26 insertions(+), 26 deletions(-)

diff --git a/gcc/config/alpha/elf.h b/gcc/config/alpha/elf.h
index db766616156..2a767f193f2 100644
--- a/gcc/config/alpha/elf.h
+++ b/gcc/config/alpha/elf.h
@@ -100,32 +100,6 @@ do {   
\
 ASM_OUTPUT_DEF (FILE, alias, name);\
   } while (0)
 
-/* Provide a STARTFILE_SPEC appropriate for ELF.  Here we add the
-   (even more) magical crtbegin.o file which provides part of the
-   support for getting C++ file-scope static object constructed
-   before entering `main'.  */
-
-#undef STARTFILE_SPEC
-#ifdef HAVE_LD_PIE
-#define STARTFILE_SPEC \
-  "%{!shared: %{pg|p:gcrt1.o%s;pie:Scrt1.o%s;:crt1.o%s}}\
-   crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
-#else
-#define STARTFILE_SPEC \
-  "%{!shared: %{pg|p:gcrt1.o%s;:crt1.o%s}}\
-   crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
-#endif
-
-/* Provide a ENDFILE_SPEC appropriate for ELF.  Here we tack on the
-   magical crtend.o file which provides part of the support for
-   getting C++ file-scope static object constructed before entering
-   `main', followed by a normal ELF "finalizer" file, `crtn.o'.  */
-
-#undef ENDFILE_SPEC
-#define ENDFILE_SPEC \
-  "%{Ofast|ffast-math|funsafe-math-optimizations:crtfastmath.o%s} \
-   %{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s"
-
 /* This variable should be set to 'true' if the target ABI requires
unwinding tables even when exceptions are not used.  */
 #define TARGET_UNWIND_TABLES_DEFAULT true
diff --git a/gcc/config/alpha/linux.h b/gcc/config/alpha/linux.h
index 9ef320668c7..2bf52fe78ae 100644
--- a/gcc/config/alpha/linux.h
+++ b/gcc/config/alpha/linux.h
@@ -78,6 +78,32 @@ along with GCC; see the file COPYING3.  If not see
 
 #define TARGET_POSIX_IO
 
+/* Provide a STARTFILE_SPEC appropriate for ELF.  Here we add the
+   (even more) magical crtbegin.o file which provides part of the
+   support for getting C++ file-scope static object constructed
+   before entering `main'.  */
+
+#undef STARTFILE_SPEC
+#ifdef HAVE_LD_PIE
+#define STARTFILE_SPEC \
+  "%{!shared: %{pg|p:gcrt1.o%s;pie:Scrt1.o%s;:crt1.o%s}}\
+   crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
+#else
+#define STARTFILE_SPEC \
+  "%{!shared: %{pg|p:gcrt1.o%s;:crt1.o%s}}\
+   crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
+#endif
+
+/* Provide a ENDFILE_SPEC appropriate for ELF.  Here we tack on the
+   magical crtend.o file which provides part of the support for
+   getting C++ file-scope static object constructed before entering
+   `main', followed by a normal ELF "finalizer" file, `crtn.o'.  */
+
+#undef ENDFILE_SPEC
+#define ENDFILE_SPEC \
+  "%{Ofast|ffast-math|funsafe-math-optimizations:crtfastmath.o%s} \
+   %{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s"
+
 #define LINK_GCC_C_SEQUENCE_SPEC \
   "%{static|static-pie:--start-group} %G %L \
%{static|static-pie:--end-group}%{!static:%{!static-pie:%G}}"
-- 
2.17.0

Re: [C++ Patch] Add INDIRECT_TYPE_P

[Jason Merrill]

OK.

On Tue, May 22, 2018 at 7:42 AM, Paolo Carlini  wrote:
> Hi,
>
> so this is the patch only adding INDIRECT_TYPE_P to the C++ front-end and
> using it instead of the misleading POINTER_TYPE_P. It also replaces a couple
> of existing TYPE_PTR_P || TYPE_REF_P. Poisoning at the same time
> POINTER_TYPE_P in the front-end - via #pragma GCC poison - seems tricky,
> because we can't just do it in cp-tree.h: tree.c includes at the end the
> generated gt-cp-tree.h which in turn uses POINTER_TYPE_P. I don't know if we
> want to try really hard to do that at the same time...
>
> Tested x86_64-linux.
>
> Thanks, Paolo.
>
> /
>

Re: libcpp PATCH to avoid deprecated copy assignment

[Gerald Pfeifer]

On Wed, 23 May 2018, Jason Merrill wrote:
> Great, applied.

Thank you!

Gerald

Re: C++ PATCH for c++/85847, ICE with template_id_expr in new()

[Jason Merrill]

OK.

On Wed, May 23, 2018 at 4:27 PM, Marek Polacek  wrote:
> On Wed, May 23, 2018 at 03:24:20PM -0400, Jason Merrill wrote:
>> On Wed, May 23, 2018 at 2:50 PM, Marek Polacek  wrote:
>> > On Wed, May 23, 2018 at 12:45:11PM -0400, Jason Merrill wrote:
>> >> On Wed, May 23, 2018 at 9:46 AM, Marek Polacek  wrote:
>> >> > The diagnostic code in build_new{,_1} was using maybe_constant_value to 
>> >> > fold
>> >> > the array length, but that breaks while parsing a template, because we 
>> >> > might
>> >> > then leak template codes to the constexpr machinery.
>> >> >
>> >> > Bootstrapped/regtested on x86_64-linux, ok for trunk/8?
>> >> >
>> >> > 2018-05-23  Marek Polacek  
>> >> >
>> >> > PR c++/85847
>> >> > * init.c (build_new_1): Use fold_non_dependent_expr.
>> >> > (build_new): Likewise.
>> >> >
>> >> > * g++.dg/cpp0x/new3.C: New test.
>> >> >
>> >> > @@ -2860,7 +2860,7 @@ build_new_1 (vec **placement, tree 
>> >> > type, tree nelts,
>> >> >/* Lots of logic below. depends on whether we have a constant number 
>> >> > of
>> >> >   elements, so go ahead and fold it now.  */
>> >> >if (outer_nelts)
>> >> > -outer_nelts = maybe_constant_value (outer_nelts);
>> >> > +outer_nelts = fold_non_dependent_expr (outer_nelts);
>> >>
>> >> If outer_nelts is non-constant, this will mean that it ends up
>> >> instantiated but still non-constant, which can lead to problems when
>> >> the result is used in building up other expressions.
>> >>
>> >> I think we want to put the result of folding in a separate variable
>> >> for use with things that want to know about a constant size, and keep
>> >> the original outer_nelts for use in building outer_nelts_check.
>> >>
>> >> >/* Try to determine the constant value only for the purposes
>> >> >  of the diagnostic below but continue to use the original
>> >> >  value and handle const folding later.  */
>> >> > -  const_tree cst_nelts = maybe_constant_value (nelts);
>> >> > +  const_tree cst_nelts = fold_non_dependent_expr (nelts);
>> >>
>> >> ...like we do here.
>> >
>> > Like this?
>> >
>> > Bootstrapped/regtested on x86_64-linux, ok for trunk?
>> >
>> > 2018-05-23  Marek Polacek  
>> >
>> > PR c++/85847
>> > * init.c (build_new_1): Use fold_non_dependent_expr.  Use a 
>> > dedicated
>> > variable for its result.  Fix a condition.
>> > (build_new): Use fold_non_dependent_expr.  Tweak a condition.
>> >
>> > * g++.dg/cpp0x/new3.C: New test.
>> >
>> > diff --git gcc/cp/init.c gcc/cp/init.c
>> > index b558742abf6..cd0110a1e19 100644
>> > --- gcc/cp/init.c
>> > +++ gcc/cp/init.c
>> > @@ -2857,10 +2857,9 @@ build_new_1 (vec **placement, tree 
>> > type, tree nelts,
>> >outer_nelts_from_type = true;
>> >  }
>> >
>> > -  /* Lots of logic below. depends on whether we have a constant number of
>> > +  /* Lots of logic below depends on whether we have a constant number of
>> >   elements, so go ahead and fold it now.  */
>> > -  if (outer_nelts)
>> > -outer_nelts = maybe_constant_value (outer_nelts);
>> > +  const_tree cst_outer_nelts = fold_non_dependent_expr (outer_nelts);
>> >
>> >/* If our base type is an array, then make sure we know how many 
>> > elements
>> >   it has.  */
>> > @@ -2912,11 +2911,12 @@ build_new_1 (vec **placement, tree 
>> > type, tree nelts,
>> >/* Warn if we performed the (T[N]) to T[N] transformation and N is
>> >   variable.  */
>> >if (outer_nelts_from_type
>> > -  && !TREE_CONSTANT (outer_nelts))
>> > +  && cst_outer_nelts != NULL_TREE
>> > +  && !TREE_CONSTANT (cst_outer_nelts))
>>
>> Why add the comparisons with NULL_TREE?  fold_non_dependent_expr only
>> returns null if its argument is null.
>
> True, and it seemed to me that the argument can be null when NELTS is null,
> which, according to the comment for build_new_1 could happen.  So I was just
> being cautious.  But I dropped the checks and nothing in the testsuite broke.
>
>> > - pedwarn (EXPR_LOC_OR_LOC (outer_nelts, input_location), OPT_Wvla,
>> > + pedwarn (EXPR_LOC_OR_LOC (cst_outer_nelts, input_location), 
>> > OPT_Wvla,
>>
>> Let's drop this change, the original expression has the location we want.
>
> Okay.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk/8?
>
> 2018-05-23  Marek Polacek  
>
> PR c++/85847
> * init.c (build_new_1): Use fold_non_dependent_expr.  Use a dedicated
> variable for its result.  Fix a condition.
> (build_new): Use fold_non_dependent_expr.  Tweak a condition.
>
> * g++.dg/cpp0x/new3.C: New test.
>
> diff --git gcc/cp/init.c gcc/cp/init.c
> index b558742abf6..5bfd0848fc4 100644
> --- gcc/cp/init.c
> +++ gcc/cp/init.c
> @@ -2857,10 +2857,9 @@ build_new_1 (vec 

[PATCH] PR target/85904: Fix configure when cross compiling for netbsd

[coypu]

In the past I was asked to post bugzilla patches here. I am doing this.
It fixes a build failure.

PR target/85904
libstdc++-v3/crossconfig.m4: test for aligned_alloc on netbsd
libstdc++-v3/configure: Regenerate

Attached is patch.
>From ac7a1f364b0ca5e3a6a5a68a16266d1cb78ee5da Mon Sep 17 00:00:00 2001
From: Maya Rashish 
Date: Thu, 24 May 2018 16:05:27 +0300
Subject: [PATCH 1/1] check for aligned_alloc on netbsd crosscompilation.

Fixes build issue:
/home/fly/gcc/libstdc++-v3/libsupc++/new_opa.cc:62:1: error: 'void* 
aligned_alloc(std::size_t, std::size_t)' was declared 'extern' and later 
'static' [-fpermissive]
 aligned_alloc (std::size_t al, std::size_t sz)
 ^
In file included from /tmp/build/alpha--netbsd/libstdc++-v3/include/cstdlib:75,
 from /tmp/build/alpha--netbsd/libstdc++-v3/include/stdlib.h:36,
 from /home/fly/gcc/libstdc++-v3/libsupc++/new_opa.cc:27:
/tmp/build/gcc/include-fixed/stdlib.h:254:7: note: previous declaration of 
'void* aligned_alloc(size_t, size_t)'
 void *aligned_alloc(size_t, size_t);
   ^
---
 libstdc++-v3/configure  | 13 +
 libstdc++-v3/crossconfig.m4 |  1 +
 2 files changed, 14 insertions(+)

diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
index f3522ee..9fd6197169a 100755
--- a/libstdc++-v3/configure
+++ b/libstdc++-v3/configure
@@ -66150,6 +66150,19 @@ done
 ;;
   *-netbsd*)
 SECTION_FLAGS='-ffunction-sections -fdata-sections'
+for ac_func in aligned_alloc posix_memalign memalign _aligned_malloc
+do :
+  as_ac_var=`$as_echo "ac_cv_func_$ac_func" | $as_tr_sh`
+ac_fn_c_check_func "$LINENO" "$ac_func" "$as_ac_var"
+eval as_val=\$$as_ac_var
+   if test "x$as_val" = x""yes; then :
+  cat >>confdefs.h <<_ACEOF
+#define `$as_echo "HAVE_$ac_func" | $as_tr_cpp` 1
+_ACEOF
+
+fi
+done
+
 
 
   # If we're not using GNU ld, then there's no point in even trying these
diff --git a/libstdc++-v3/crossconfig.m4 b/libstdc++-v3/crossconfig.m4
index f0a55c68404..dcc807eb76a 100644
--- a/libstdc++-v3/crossconfig.m4
+++ b/libstdc++-v3/crossconfig.m4
@@ -203,6 +203,7 @@ case "${host}" in
 ;;
   *-netbsd*)
 SECTION_FLAGS='-ffunction-sections -fdata-sections'
+AC_CHECK_FUNCS(aligned_alloc posix_memalign memalign _aligned_malloc)
 AC_SUBST(SECTION_FLAGS) 
 GLIBCXX_CHECK_LINKER_FEATURES
 AC_DEFINE(HAVE_FINITEF)
-- 
2.17.0

[Ada] Fix irregular output with -gnatR3

[Pierre-Marie de Rodat]

This fixes a long-standing quirk present in the layout information for record
types displayed by the -gnatR3 switch: when a component has a variable
(starting) position, its corresponding line in the output has an irregular and
awkward format.  After this change, the format is the same as in all the other
cases.

For the following record:

type R (m : natural) is record
s : string (1 .. m);
r : natural;
b : boolean;
end record;
for R'alignment use 4;
pragma Pack (R);

the output of -gnatR3 used to be:

for R'Object_Size use 17179869248;
for R'Value_Size use ((#1 + 8) * 8);
for R'Alignment use 4;
for R use record
   m at  0 range  0 .. 30;
   s at  4 range  0 .. ((#1 * 8)) - 1;
   r at bit offset (((#1 + 4) * 8)) size in bits = 31
   b at bit offset #1 + 7) * 8) + 7)) size in bits = 1
end record;

and is changed into:

for R'Object_Size use 17179869248;
for R'Value_Size use ((#1 + 8) * 8);
for R'Alignment use 4;
for R use record
   m at  0 range  0 .. 30;
   s at  4 range  0 .. ((#1 * 8)) - 1;
   r at (#1 + 4) range  0 .. 30;
   b at (#1 + 7) range  7 ..  7;
end record;

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

2018-05-24  Eric Botcazou  

gcc/ada/

* fe.h (Set_Normalized_First_Bit): Declare.
(Set_Normalized_Position): Likewise.
* repinfo.adb (List_Record_Layout): Do not use irregular output for a
variable position.  Fix minor spacing issue.
* gcc-interface/decl.c (annotate_rep): If a field has a variable
offset, compute the normalized position and annotate it in addition to
the bit offset.--- gcc/ada/fe.h
+++ gcc/ada/fe.h
@@ -68,6 +68,8 @@ extern Boolean Debug_Flag_NN;
 #define Set_Component_Size		einfo__set_component_size
 #define Set_Esize			einfo__set_esize
 #define Set_Mechanism			einfo__set_mechanism
+#define Set_Normalized_First_Bit	einfo__set_normalized_first_bit
+#define Set_Normalized_Position		einfo__set_normalized_position
 #define Set_RM_Size			einfo__set_rm_size
 
 extern void Set_Alignment		(Entity_Id, Uint);
@@ -75,6 +77,8 @@ extern void Set_Component_Bit_Offset	(Entity_Id, Uint);
 extern void Set_Component_Size		(Entity_Id, Uint);
 extern void Set_Esize			(Entity_Id, Uint);
 extern void Set_Mechanism		(Entity_Id, Mechanism_Type);
+extern void Set_Normalized_First_Bit	(Entity_Id, Uint);
+extern void Set_Normalized_Position	(Entity_Id, Uint);
 extern void Set_RM_Size			(Entity_Id, Uint);
 
 #define Is_Entity_Name einfo__is_entity_name

--- gcc/ada/gcc-interface/decl.c
+++ gcc/ada/gcc-interface/decl.c
@@ -8291,7 +8291,8 @@ annotate_rep (Entity_Id gnat_entity, tree gnu_type)
    gnu_list);
 	if (t)
 	  {
-	tree parent_offset;
+	tree offset = TREE_VEC_ELT (TREE_VALUE (t), 0);
+	tree bit_offset = TREE_VEC_ELT (TREE_VALUE (t), 2);
 
 	/* If we are just annotating types and the type is tagged, the tag
 	   and the parent components are not generated by the front-end so
@@ -8301,31 +8302,46 @@ annotate_rep (Entity_Id gnat_entity, tree gnu_type)
 		&& Is_Tagged_Type (gnat_entity)
 		&& No (Component_Clause (gnat_field)))
 	  {
+		tree parent_bit_offset;
+
 		/* For a component appearing in the current extension, the
 		   offset is the size of the parent.  */
 		if (Is_Derived_Type (gnat_entity)
 		&& Original_Record_Component (gnat_field) == gnat_field)
-		  parent_offset
+		  parent_bit_offset
 		= UI_To_gnu (Esize (Etype (Base_Type (gnat_entity))),
  bitsizetype);
 		else
-		  parent_offset = bitsize_int (POINTER_SIZE);
+		  parent_bit_offset = bitsize_int (POINTER_SIZE);
 
 		if (TYPE_FIELDS (gnu_type))
-		  parent_offset
-		= round_up (parent_offset,
+		  parent_bit_offset
+		= round_up (parent_bit_offset,
 DECL_ALIGN (TYPE_FIELDS (gnu_type)));
+
+		offset
+		  = size_binop (PLUS_EXPR, offset,
+fold_convert (sizetype,
+	  size_binop (TRUNC_DIV_EXPR,
+			  parent_bit_offset,
+			  bitsize_unit_node)));
+	  }
+
+	/* If the field has a variable offset, also compute the normalized
+	   position since it's easier to do on trees here than to deduce
+	   it from the annotated expression of Component_Bit_Offset.  */
+	if (TREE_CODE (offset) != INTEGER_CST)
+	  {
+		normalize_offset (, _offset, BITS_PER_UNIT);
+		Set_Normalized_Position (gnat_field,
+	 annotate_value (offset));
+		Set_Normalized_First_Bit (gnat_field,
+	  annotate_value (bit_offset));
 	  }
-	else
-	  parent_offset = bitsize_zero_node;
 
 	Set_Component_Bit_Offset
 	  (gnat_field,
-	   annotate_value
-		 (size_binop (PLUS_EXPR,
-			  bit_from_pos (TREE_VEC_ELT (TREE_VALUE (t), 0),
-	TREE_VEC_ELT (TREE_VALUE (t), 2)),
-			  parent_offset)));
+	   annotate_value (bit_from_pos (offset, bit_offset)));
 
 	Set_Esize (gnat_field,
 		   annotate_value (DECL_SIZE (TREE_PURPOSE (t;
@@ -8334,19 +8350,27 @@ annotate_rep (Entity_Id gnat_entity, tree 

[Ada] Simplify routines with a local Result variable

[Pierre-Marie de Rodat]

Local variable Result that is modified inside IF statements makes a seemingly
trivial code slightly hard to understand. This patch rewrites such a pattern.

Semantics unaffected.

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

2018-05-24  Piotr Trojanek  

gcc/ada/

* sem_elab.adb (Non_Private_View): Simplify by removing a local Result
variable.
* sem_prag.adb (Get_Base_Subprogram): Same as above.--- gcc/ada/sem_elab.adb
+++ gcc/ada/sem_elab.adb
@@ -8077,16 +8077,12 @@ package body Sem_Elab is
--
 
function Non_Private_View (Typ : Entity_Id) return Entity_Id is
-  Result : Entity_Id;
-
begin
-  Result := Typ;
-
-  if Is_Private_Type (Result) and then Present (Full_View (Result)) then
- Result := Full_View (Result);
+  if Is_Private_Type (Typ) and then Present (Full_View (Typ)) then
+ return Full_View (Typ);
+  else
+ return Typ;
   end if;
-
-  return Result;
end Non_Private_View;
 
-

--- gcc/ada/sem_prag.adb
+++ gcc/ada/sem_prag.adb
@@ -29765,23 +29765,19 @@ package body Sem_Prag is
-
 
function Get_Base_Subprogram (Def_Id : Entity_Id) return Entity_Id is
-  Result : Entity_Id;
-
begin
   --  Follow subprogram renaming chain
 
-  Result := Def_Id;
-
-  if Is_Subprogram (Result)
+  if Is_Subprogram (Def_Id)
 and then
-  Nkind (Parent (Declaration_Node (Result))) =
+  Nkind (Parent (Declaration_Node (Def_Id))) =
  N_Subprogram_Renaming_Declaration
-and then Present (Alias (Result))
+and then Present (Alias (Def_Id))
   then
- Result := Alias (Result);
+ return Alias (Def_Id);
+  else
+ return Def_Id;
   end if;
-
-  return Result;
end Get_Base_Subprogram;
 
---

[Ada] Wrong renaming of variant record equality

[Pierre-Marie de Rodat]

For a renaming of the equality operator of a variant record the compiler
erroneously generates code that compares all the record component (thus
computing wrong results).

After this patch the following test provides the correct results.

package Types is
   type Data (Bool : Boolean := False) is record
  case Bool is
 when False =>
null;

 when True =>
Val1 : Integer range 0 .. 2 ** 23 - 1;
Val2 : Float;
  end case;
   end record;

   function IsEqual (Left, Right : Data) return Boolean renames "=";
end Types;

with Types;
with Ada.Text_IO;
procedure Main is
   A : Types.Data := Types.Data'(Bool => True,
 Val1 => 16#05A5A5#,
 Val2 => 9.0);

   B : Types.Data := Types.Data'(Bool => True,
 Val1 => 16#0A5A5A#,
 Val2 => 66.0);
   use type Types.Data;
begin
   A := (Bool => False); --  Test
   B := (Bool => False); --  Test

   if Types.IsEqual (A, B) then  --  Test
  Ada.Text_IO.Put_Line ("OK");
   else
  Ada.Text_IO.Put_Line ("ERROR");
   end if;
end Main;

Command: gnatmake main; ./main
 Output: OK

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

2018-05-24  Javier Miranda  

gcc/ada/

* exp_ch8.adb (Build_Body_For_Renaming): Adding support to build the
body of a variant record equality renaming.
(Expand_N_Subprogram_Renaming_Declaration): Adapt the code to the new
implementation of Build_Body_For_Renaming.
* exp_ch3.ads (Build_Variant_Record_Equality): New library level
function that factorizes the functionality needed by
Build_Body_For_Renaming and Expand_Freeze_Record_Type to build the body
of a variant record equality subprogram.
* exp_ch3.adb (Build_Variant_Record_Equality): New subprogram.
(Build_Variant_Record_Equality): New local procedure of
Expand_Freeze_Record_Type containing all the code specific for freezing
the record type that cannot be place in the new library level function.--- gcc/ada/exp_ch3.adb
+++ gcc/ada/exp_ch3.adb
@@ -131,10 +131,6 @@ package body Exp_Ch3 is
--  of a record type that has user-defined primitive equality operations.
--  The resulting operation is a TSS subprogram.
 
-   procedure Build_Variant_Record_Equality (Typ  : Entity_Id);
-   --  Create An Equality function for the untagged variant record Typ and
-   --  attach it to the TSS list
-
procedure Check_Stream_Attributes (Typ : Entity_Id);
--  Check that if a limited extension has a parent with user-defined stream
--  attributes, and does not itself have user-defined stream-attributes,
@@ -4235,7 +4231,14 @@ package body Exp_Ch3 is
 
--  Generates:
 
-   --function _Equality (X, Y : T) return Boolean is
+   --function <> (Left, Right : T) return Boolean is
+   --   [ X : T renames Left;  ]
+   --   [ Y : T renames Right; ]
+   --   --  The above renamings are generated only if the parameters of
+   --   --  this built function (which are passed by the caller) are not
+   --   --  named 'X' and 'Y'; these names are required to reuse several
+   --   --  expander routines when generating this body.
+
--begin
--   --  Compare discriminants
 
@@ -4266,71 +4269,45 @@ package body Exp_Ch3 is
--   return True;
--end _Equality;
 
-   procedure Build_Variant_Record_Equality (Typ : Entity_Id) is
-  Loc : constant Source_Ptr := Sloc (Typ);
-
-  F : constant Entity_Id :=
-Make_Defining_Identifier (Loc,
-  Chars => Make_TSS_Name (Typ, TSS_Composite_Equality));
-
-  X : constant Entity_Id := Make_Defining_Identifier (Loc, Name_X);
-  Y : constant Entity_Id := Make_Defining_Identifier (Loc, Name_Y);
-
-  Def: constant Node_Id := Parent (Typ);
-  Comps  : constant Node_Id := Component_List (Type_Definition (Def));
-  Stmts  : constant List_Id := New_List;
-  Pspecs : constant List_Id := New_List;
+   function Build_Variant_Record_Equality
+ (Typ : Entity_Id;
+  Body_Id : Entity_Id;
+  Param_Specs : List_Id) return Node_Id
+   is
+  Loc   : constant Source_Ptr := Sloc (Typ);
+  Def   : constant Node_Id := Parent (Typ);
+  Comps : constant Node_Id := Component_List (Type_Definition (Def));
+  Left  : constant Entity_Id := Defining_Identifier
+  (First (Param_Specs));
+  Right : constant Entity_Id := Defining_Identifier
+  (Next (First (Param_Specs)));
+  Decls : constant List_Id := New_List;
+  Stmts : constant List_Id := New_List;
+  Subp_Body : Node_Id;
 
begin
-  --  If we have a variant record with restriction No_Implicit_Conditionals
-  --  in effect, then we 

[Ada] Improve GNATprove messages on unproved checks

[Pierre-Marie de Rodat]

GNATprove messages may point out to part of an assertion as not being proved,
and in such a case it displays the sub-expression. This code relies on
Pprint.Expression_Image, which is improved here to display better some kinds of
expressions.

There is no impact on compilation.

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

2018-05-24  Yannick Moy  

gcc/ada/

* pprint.adb (Expression_Image): Improve the printing of expressions,
by taking more cases into account, in particular qualified expressions
and aggregates.  Also count more the number of parentheses to close
after the expression.--- gcc/ada/pprint.adb
+++ gcc/ada/pprint.adb
@@ -51,7 +51,7 @@ package body Pprint is
   From_Source  : constant Boolean :=
Comes_From_Source (Expr)
  and then not Opt.Debug_Generated_Code;
-  Append_Paren : Boolean := False;
+  Append_Paren : Natural := 0;
   Left : Node_Id := Original_Node (Expr);
   Right: Node_Id := Original_Node (Expr);
 
@@ -732,7 +732,9 @@ package body Pprint is
 when N_Range =>
Left := Original_Node (Low_Bound (Left));
 
-when N_Type_Conversion =>
+when N_Qualified_Expression
+   | N_Type_Conversion
+=>
Left := Original_Node (Subtype_Mark (Left));
 
 --  For any other item, quit loop
@@ -756,6 +758,20 @@ package body Pprint is
 =>
Right := Original_Node (Selector_Name (Right));
 
+when N_Qualified_Expression
+   | N_Type_Conversion
+=>
+   Right := Original_Node (Expression (Right));
+
+   --  If argument does not already account for a closing
+   --  parenthesis, count one here.
+
+   if not Nkind_In (Right, N_Quantified_Expression,
+   N_Aggregate)
+   then
+  Append_Paren := Append_Paren + 1;
+   end if;
+
 when N_Designator =>
Right := Original_Node (Identifier (Right));
 
@@ -768,9 +784,16 @@ package body Pprint is
 when N_Parameter_Association =>
Right := Original_Node (Explicit_Actual_Parameter (Right));
 
+when N_Component_Association =>
+   if Present (Expression (Right)) then
+  Right := Expression (Right);
+   else
+  Right := Last (Choices (Right));
+   end if;
+
 when N_Indexed_Component =>
Right := Original_Node (Last (Sinfo.Expressions (Right)));
-   Append_Paren := True;
+   Append_Paren := Append_Paren + 1;
 
 when N_Function_Call =>
if Present (Sinfo.Parameter_Associations (Right)) then
@@ -787,13 +810,16 @@ package body Pprint is
  while Present (Rover) loop
 if Comes_From_Source (Original_Node (Rover)) then
Right := Original_Node (Rover);
-   Append_Paren := True;
Found := True;
 end if;
 
 Next (Rover);
  end loop;
 
+ if Found then
+Append_Paren := Append_Paren + 1;
+ end if;
+
  --  Quit loop if no Comes_From_Source parameters
 
  exit when not Found;
@@ -807,6 +833,33 @@ package body Pprint is
 
 when N_Quantified_Expression =>
Right := Original_Node (Condition (Right));
+   Append_Paren := Append_Paren + 1;
+
+when N_Aggregate =>
+   declare
+  Aggr : constant Node_Id := Right;
+  Sub  : Node_Id;
+   begin
+  Sub := First (Expressions (Aggr));
+  while Present (Sub) loop
+ if Sloc (Sub) > Sloc (Right) then
+Right := Sub;
+ end if;
+ Next (Sub);
+  end loop;
+
+  Sub := First (Component_Associations (Aggr));
+  while Present (Sub) loop
+ if Sloc (Sub) > Sloc (Right) then
+Right := Sub;
+ end if;
+ Next (Sub);
+  end loop;
+
+  exit when Right = Aggr;
+
+  Append_Paren := Append_Paren + 1;
+   end;
 
 --  For all other items, quit the loop
 
@@ -886,11 +939,9 @@ package body Pprint is
   end if;
end;
 
-elsif Append_Paren then
-   return Buffer (1 .. Index) & Expr_Name (Right, False) & ')';
-
 else
-   return Buffer (1 .. Index) & Expr_Name (Right, 

[Ada] Quadratic compile time with tagged types

[Pierre-Marie de Rodat]

This patch is an incremental commit which focuses on the optimization of entity
chain navigation by adding an additional field (Prev_Entity) to all nodes in
order to greaty speed up compilation of sources making heavy use of tagged
derivations by effectly making the entity chain from a singly-linked list into
a doubly-linked one.

This is only a performance improvement: no compilation result change
expected.

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

2018-05-24  Justin Squirek  

gcc/ada/

* einfo.ads, einfo.adb (Append_Entity): Modified to use Link_Entities
and manage doubly-linked entity chain.
(Nested_Scenarios): Removed entity field used for optimization during
 elaboration to make room for the new field Prev_Entity.
(Link_Entities): Added to replace redundant calls to Set_Next_Entity
and Set_Prev_Entity as well as centralize changes to the entity chain.
(Predicated_Parent): Modified to use Node38.
(Prev_Entity): Added to fetch new node field Prev_Entity in all entity
types.
(Remove_Entity): Moved from sem_util.
(Set_Nested_Scenarios): Deleted.
(Set_Predicated_Parent): Modified to use Node38.
(Set_Prev_Entity): Added to set Prev_Entity field.
(Set_Validated_Object): Modified to use Node38.
(Unlink_Next_Entity): Added to process Prev_Entity when an unlinking
action is required.
(Validated_Object): Modified to use Node38.
(Write_Field36_Name): Remove Nested_Scenarios, Validated_Object, and
predicated parent cases.
(Write_Field38_Name): Add predicated parent and Validated_Object cases.
* sem_ch3.adb (Process_Subtype): Add guard to protect against
inappropriate marking of Predicated_Parent to non-itype subtypes.
(Make_Class_Wide_Type): Preserve Prev_Entity field and set in new type.
(Copy_And_Swap): Add setting of Prev_Entity.
(Build_derived_Record_Type): Replace Set_Next_Entity w/ Link_Entities.
* sem_ch6.adb (Analyze_Subprogram_Body_Helper): Replace Set_Next_Entity
w/ Link_Entities.
(New_Overloaded_Entity): Remove block created to search for previous
entities in the entity chain with relevant calls to Prev_Entity as well
as replace duplicated code from Remove_Entity_And_Homonym with a call
to that subprogram.
* sem_ch7.adb (Exchange_Declarations): Replace Set_Next_Entity w/
Link_Entities.
* sem_elab.adb (Find_And_Process_Nested_Scenarios): Remove global and
initial subprogram declarations related to Nested_Scenarios.
(Process_Nested_Scenarios): Deleted.
(Save_Scenario): Deleted.
(Traverse_Body): Remove optimization for Nested_Scenarios so as to free
node space in the entity tree.
* sem_util.adb, sem_util.ads (Remove_Entity): Moved to einfo.
(Remove_Entity_And_Homonym): Added to separate functionality of
Remove_Entity from the homonym chain directly.
* exp_attr.adb (Expand_N_Attribute_Reference): Replace Set_Next_Entity
w/ Link_Entities and Unlink_Next_Entity.
* exp_ch3.adb (Expand_N_Object_Declaration): Replace Set_Next_Entity w/
Link_Entities.
* exp_ch6.adb (Replace_Renaming_Declaration_Id): Replace
Set_Next_Entity w/ Link_Entities.
* exp_disp.adb (Expand_Dispatching_Call): Replace Set_Next_Entity w/
Link_Entities and Unlink_Next_Entity.
* exp_spark.adb (Expand_SPARK_N_Object_Renaming_Declaration): Replace
call to Remove_Entity with its new incarnation.
* exp_util.adb (New_Class_Wide_Subtype): Add setting of Prev_Entity.
* freeze.adb (Freeze_Record_Type): Replace Set_Next_Entity w/
Link_Entities.--- gcc/ada/einfo.adb
+++ gcc/ada/einfo.adb
@@ -70,6 +70,7 @@ package body Einfo is
--Homonym Node4
--First_Rep_Item  Node6
--Freeze_Node Node7
+   --Prev_Entity Node36
--Associated_Entity   Node37
 
--  The usage of other fields (and the entity kinds to which it applies)
@@ -274,10 +275,10 @@ package body Einfo is
--Entry_Max_Queue_Lengths_Array   Node35
--Import_Pragma   Node35
 
-   --Nested_ScenariosElist36
-   --Validated_ObjectNode36
-   --Predicated_Parent   Node36
+   --Prev_Entity Node36
 
+   --Validated_ObjectNode38
+   --Predicated_Parent   Node38
--Class_Wide_CloneNode38
 
--Protected_SubprogramNode39
@@ -2878,14 +2879,6 @@ package body Einfo is
   return Flag22 (Id);
end Needs_No_Actuals;
 
-   function Nested_Scenarios (Id : E) return L is
-   begin
-  pragma Assert (Ekind_In (Id, E_Function,
- 

[Ada] Infinite loop in the compiler when warning on redundant constructs

[Pierre-Marie de Rodat]

This patch fixes an infinite loop in the compiler when warnings on redundant
constructs are enabled (-gnatwr) and the constructs are use_type clauses
that appear (redundantly) in a parent unit and a child unit.

The following command:

   gcc -c -gnatwr root-child.ads

must yield:

   root-child.ads:2:01: warning: "Pack.Typ" is already use-visible through
   previous use_type_clause at root.ads:2

The following must compile quietly:

   gcc -c -gnatwr root-child-grand.ads


package Pack is
  type Typ is new Integer;
end Pack;

with Pack;
use type Pack.Typ;
package Root is
  Thing1 : Pack.Typ;
end Root;

with pack;
use type pack.typ;
package Root.Child is
  Thing2 : Pack.Typ := Root.Thing1 * 3;
end;

with Pack;
use type Pack.Typ;
package Root.Child.Grand is
  Thing3 : Pack.Typ := Thing1 + Thing2;
end;

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

2018-05-24  Ed Schonberg  

gcc/ada/

* sem_ch8.adb (Analyze_Use_Type): Do not assign the Prev_Use_Clause
link to a use_type clause if this would cause an infinite loop in the
machinery that detects redundant use clauses. This may happen when the
redundant clauses appear in the context of a child unit and the context
of its parent.--- gcc/ada/sem_ch8.adb
+++ gcc/ada/sem_ch8.adb
@@ -3916,10 +3916,14 @@ package body Sem_Ch8 is
   --  manipulation of the scope stack so we much guard against those cases
   --  here, otherwise, we must add the new use_type_clause to the previous
   --  use_type_clause chain in order to mark redundant use_type_clauses as
-  --  used.
+  --  used. When the redundant use-type clauses appear in a parent unit and
+  --  a child unit we must prevent a circularity in the chain that would
+  --  otherwise result from the separate steps of analysis and installation
+  --  of the parent context.
 
   if Present (Current_Use_Clause (E))
 and then Current_Use_Clause (E) /= N
+and then Prev_Use_Clause (Current_Use_Clause (E)) /= N
 and then No (Prev_Use_Clause (N))
   then
  Set_Prev_Use_Clause (N, Current_Use_Clause (E));

[Ada] Missing error on illegal access to discriminant

[Pierre-Marie de Rodat]

The compiler does not report an error on the illegal access to a renamed
discriminant when the actual object is a parameter of a subprogram.

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

2018-05-24  Javier Miranda  

gcc/ada/

* sem_ch3.adb (Is_Visible_Component): For untagged types add missing
check for renamed discriminants.
* sem_ch4.adb (Analyze_Overloaded_Selected_Component,
Analyze_Selected_Component, Check_Misspelled_Selector): For calls to
Is_Visible_Component pass the associated selector node to allow
checking renamed discriminants on untagged types.

gcc/testsuite/

* gnat.dg/discr52.adb: New testcase.--- gcc/ada/sem_ch3.adb
+++ gcc/ada/sem_ch3.adb
@@ -18797,7 +18797,18 @@ package body Sem_Ch3 is
   --  This test only concerns tagged types
 
   if not Is_Tagged_Type (Original_Type) then
- return True;
+
+ --  Check if this is a renamed discriminant (hidden either by the
+ --  derived type or by some ancestor), unless we are analyzing code
+ --  generated by the expander since it may reference such components
+ --  (for example see the expansion of Deep_Adjust).
+
+ if Ekind (C) = E_Discriminant and then Present (N) then
+return not Comes_From_Source (N)
+  or else not Is_Completely_Hidden (C);
+ else
+return True;
+ end if;
 
   --  If it is _Parent or _Tag, there is no visibility issue
 

--- gcc/ada/sem_ch4.adb
+++ gcc/ada/sem_ch4.adb
@@ -3905,7 +3905,7 @@ package body Sem_Ch4 is
 Comp := First_Entity (T);
 while Present (Comp) loop
if Chars (Comp) = Chars (Sel)
- and then Is_Visible_Component (Comp)
+ and then Is_Visible_Component (Comp, Sel)
then
 
   --  AI05-105:  if the context is an object renaming with
@@ -5324,7 +5324,7 @@ package body Sem_Ch4 is
Comp := First_Component (Base_Type (Prefix_Type));
while Present (Comp) loop
   if Chars (Comp) = Chars (Sel)
-and then Is_Visible_Component (Comp)
+and then Is_Visible_Component (Comp, Sel)
   then
  Set_Entity_With_Checks (Sel, Comp);
  Generate_Reference (Comp, Sel);
@@ -6031,7 +6031,7 @@ package body Sem_Ch4 is
 
   Comp  := First_Entity (Prefix);
   while Nr_Of_Suggestions <= Max_Suggestions and then Present (Comp) loop
- if Is_Visible_Component (Comp) then
+ if Is_Visible_Component (Comp, Sel) then
 if Is_Bad_Spelling_Of (Chars (Comp), Chars (Sel)) then
Nr_Of_Suggestions := Nr_Of_Suggestions + 1;
 

--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/discr52.adb
@@ -0,0 +1,20 @@
+--  { dg-do compile }
+
+procedure Discr52 is
+   type T_Root (Root_Disc : Natural) is record
+  Data : Natural := 0;
+   end record;
+
+   type T_Derived (deriv_disc : Natural) is
+ new T_Root (root_disc => deriv_disc);
+
+   Derived : T_Derived (Deriv_Disc => 3);
+   Value   : Natural;
+
+   procedure Do_Test (Obj : T_Derived) is
+   begin
+  Value := Obj.root_disc; --  { dg-error "no selector \"root_disc\" for type \"T_Derived\" defined at line \\d+" }
+   end;
+begin
+   Do_Test (Derived);
+end;

[Ada] Crash on return of raise expression

[Pierre-Marie de Rodat]

This patch fixes an issue whereby the compiler regarded assignments to limited
that consisted of raise expressions to be a compile-time error during
expansion.

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

2018-05-24  Justin Squirek  

gcc/ada/

* exp_ch3.adb (Expand_N_Object_Declaration): Ignore raising an error in
expansion for limited tagged types when the node to be expanded is a
raise expression due to it not representing a valid object.
* exp_ch5.adb (Expand_N_Assignment_Statement): Add exception to error
message regarding assignments to limited types to ignore genereated
code.

gcc/testsuite/

* gnat.dg/raise_expr.adb: New testcase.--- gcc/ada/exp_ch3.adb
+++ gcc/ada/exp_ch3.adb
@@ -6952,9 +6952,11 @@ package body Exp_Ch3 is
 
--  If we cannot convert the expression into a renaming we must
--  consider it an internal error because the backend does not
-   --  have support to handle it.
+   --  have support to handle it. Also, when a raise expression is
+   --  encountered we ignore it since it doesn't return a value and
+   --  thus cannot trigger a copy.
 
-   else
+   elsif Nkind (Original_Node (Expr_Q)) /= N_Raise_Expression then
   pragma Assert (False);
   raise Program_Error;
end if;

--- gcc/ada/exp_ch5.adb
+++ gcc/ada/exp_ch5.adb
@@ -2467,12 +2467,19 @@ package body Exp_Ch5 is
   --  extension of a limited interface, and the actual is
   --  limited. This is an error according to AI05-0087, but
   --  is not caught at the point of instantiation in earlier
-  --  versions.
+  --  versions. We also must verify that the limited type does
+  --  not come from source as corner cases may exist where
+  --  an assignment was not intended like the pathological case
+  --  of a raise expression within a return statement.
 
   --  This is wrong, error messages cannot be issued during
   --  expansion, since they would be missed in -gnatc mode ???
 
-  Error_Msg_N ("assignment not available on limited type", N);
+  if Comes_From_Source (N) then
+ Error_Msg_N
+   ("assignment not available on limited type", N);
+  end if;
+
   return;
end if;
 

--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/raise_expr.adb
@@ -0,0 +1,27 @@
+--  { dg-do compile }
+
+procedure Raise_Expr is
+
+   E : exception;
+
+   type T is tagged limited null record;
+   type TC is new T with null record;
+
+   function F0 return Boolean is
+   begin
+   return raise E;
+   end;
+
+   function F return T'Class is
+ TT : T;
+   begin
+  return raise E; -- Causes compile-time crash
+   end F;
+
+begin
+   declare
+  O : T'class  := F;
+   begin
+  null;
+   end;
+end Raise_Expr;

[Ada] Spurious error due to lingering limited view

[Pierre-Marie de Rodat]

This patch modifies the mechanism which manages [private] with clauses to
uninstall a limited with clause if a non-limited with clause is given for
the same package.

The management of with clauses already prevents the installation of a limited
with clause if the related package is already withed though a non-limited with
clause. The timing of parent unit with clause processing is such that the non-
limited clauses of the child unit are first installed, followed by the clauses
of the parent. This order prevents a limited with clause from "overriding" a
non-limited with clause.

Private with clauses however break this model because they are processed when
the private part of a package is entered. Since private with clauses are non-
limited with clauses, they must "override" the effects of any limited clauses
which import the same packages. This effect is now correctly achieved by
uninstalling the limited with clauses when private with clauses are activated.


-- Source --


--  server.ads

package Server is
   type Root is tagged private;
private
   type Root is tagged null record;
end Server;

--  parent.ads

limited with Server;

package Parent is end Parent;

--  parent-client.ads

private with Server;

package Parent.Client is
   type Deriv is tagged private;
private
   type Deriv is new Server.Root with null record;
end Parent.Client;

-
-- Compilation --
-

$ gcc -c parent-client.ads

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

2018-05-24  Hristian Kirtchev  

gcc/ada/

* sem_ch10.adb (Expand_Limited_With_Clause): Update the call to
Install_Limited_Withed_Unit.
(Expand_With_Clause): Update the call to Install_Withed_Unit.
(Implicit_With_On_Parent): Update the call to Install_Withed_Unit.
(Install_Context_Clauses): Update the call to Install_Withed_Unit.
(Install_Limited_Context_Clauses): Update the calls to
 Install_Limited_Withed_Unit.
(Install_Limited_Withed_Unit): Renamed to better illustrate its
purpose.
(Install_Private_With_Clauses): Update the calls to Install_Withed_Unit
and Install_Limited_Withed_Unit.
(Install_With_Clause): Uninstall a limited with clause if a [private]
with clause is given for the same package.
(Install_Withed_Unit): Renamed to better illustrate its purpose.
(Remove_Limited_With_Unit): New routine.--- gcc/ada/sem_ch10.adb
+++ gcc/ada/sem_ch10.adb
@@ -150,19 +150,10 @@ package body Sem_Ch10 is
--  Subsidiary to Install_Context. Process only limited with_clauses for
--  current unit. Implements Ada 2005 (AI-50217).
 
-   procedure Install_Limited_Withed_Unit (N : Node_Id);
+   procedure Install_Limited_With_Clause (N : Node_Id);
--  Place shadow entities for a limited_with package in the visibility
--  structures for the current compilation. Implements Ada 2005 (AI-50217).
 
-   procedure Install_Withed_Unit
- (With_Clause : Node_Id;
-  Private_With_OK : Boolean := False);
-   --  If the unit is not a child unit, make unit immediately visible. The
-   --  caller ensures that the unit is not already currently installed. The
-   --  flag Private_With_OK is set true in Install_Private_With_Clauses, which
-   --  is called when compiling the private part of a package, or installing
-   --  the private declarations of a parent unit.
-
procedure Install_Parents
  (Lib_Unit   : Node_Id;
   Is_Private : Boolean;
@@ -185,6 +176,15 @@ package body Sem_Ch10 is
--  an enclosing scope. Iterate over context to find child units of U_Name
--  or of some ancestor of it.
 
+   procedure Install_With_Clause
+ (With_Clause : Node_Id;
+  Private_With_OK : Boolean := False);
+   --  If the unit is not a child unit, make unit immediately visible. The
+   --  caller ensures that the unit is not already currently installed. The
+   --  flag Private_With_OK is set true in Install_Private_With_Clauses, which
+   --  is called when compiling the private part of a package, or installing
+   --  the private declarations of a parent unit.
+
function Is_Ancestor_Unit (U1 : Node_Id; U2 : Node_Id) return Boolean;
--  When compiling a unit Q descended from some parent unit P, a limited
--  with_clause in the context of P that names some other ancestor of Q
@@ -204,8 +204,15 @@ package body Sem_Ch10 is
--  Subsidiary of previous one. Remove use_ and with_clauses
 
procedure Remove_Limited_With_Clause (N : Node_Id);
-   --  Remove from visibility the shadow entities introduced for a package
-   --  mentioned in a limited_with clause. Implements Ada 2005 (AI-50217).
+   --  Remove the shadow entities from visibility introduced for a package
+   --  mentioned in limited with clause N. Implements Ada 2005 (AI-50217).
+
+   procedure Remove_Limited_With_Unit
+ (Pack_Decl  : Node_Id;
+  Lim_Clause : Node_Id := Empty);
+   --  

[Ada] Add warning on redundant others_clause in array aggregate

[Pierre-Marie de Rodat]

This patch adds a warning on a redundant others_clause in an array aggregate
when all index positions are already specified in previous positional or named
associations. The warning is emitted when Warn_On_Redundant_Constructs is
enabled.

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

2018-05-24  Ed Schonberg  

gcc/ada/

* exp_aggr.adb (Flatten): Add a warning on an others clause in an array
aggregate with static bounds when named associations cover all index
positions and the others clause is redundant.

gcc/testsuite/

* gnat.dg/others1.adb: New testcase.--- gcc/ada/exp_aggr.adb
+++ gcc/ada/exp_aggr.adb
@@ -4581,6 +4581,12 @@ package body Exp_Aggr is
 end if;
  end loop;
 
+ if Rep_Count = 0
+   and then Warn_On_Redundant_Constructs
+ then
+Error_Msg_N ("there are no others?r?", Elmt);
+ end if;
+
  exit Component_Loop;
 
   --  Case of a subtype mark, identifier or expanded name

--- /dev/null
new file mode 100644
+++ gcc/testsuite/gnat.dg/others1.adb
@@ -0,0 +1,13 @@
+--  { dg-do compile }
+--  { dg-options "-gnatwr" }
+
+procedure Others1 is
+   type Ar is Array (1..10) of Natural;
+   function five return integer is (5);
+   THing : Ar;
+begin
+   Thing := (1..5 => 22, 6 ..10 => 111, others => Five); --  { dg-warning "there are no others" }
+   if Thing (1) /= thing (5) then
+  raise Program_Error;
+   end if;
+end;

[Ada] Ineffective use warning is suppressed when performing verification

[Pierre-Marie de Rodat]

This patch fixes an issue whereby the compiler incorrectly marked use clauses
as effective due to code generated for verification referencing certain types
leading to missing use clause warnings.

No reasonably small testcase available.

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

2018-05-24  Justin Squirek  

gcc/ada/

* sem_res.adb (Resolve_Entity_Name): Add guard to protect against
marking use clauses as effective when the reference appears within
generated code.--- gcc/ada/sem_res.adb
+++ gcc/ada/sem_res.adb
@@ -7293,7 +7293,13 @@ package body Sem_Res is
  end if;
   end if;
 
-  Mark_Use_Clauses (E);
+  --  We may be resolving an entity within expanded code, so a reference
+  --  to an entity should be ignored when calculating effective use clauses
+  --  to avoid inappropriate marking.
+
+  if Comes_From_Source (N) then
+ Mark_Use_Clauses (E);
+  end if;
end Resolve_Entity_Name;
 
---

[Ada] Crash on function in Ghost subunit

[Pierre-Marie de Rodat]

This patch modifies the creation of class-wide subtypes to preserve vital
attributes related to Ghost code. The subtype is created by copying the
contents of a class-wide type into a newly created itype. When the itype
is created within a Ghost region, the act of copying destroys Ghost code
related attributes. As a result, if the now living class-wide subtype is
frozen within an ignored Ghost region, its freeze node is hoisted prior
to the start of the region, howeve the subtype is still eliminated from
the tree.


-- Source --


--  pack.ads

with Ada.Finalization; use Ada.Finalization;

package Pack is
   type Ctrl is new Controlled with null record;
   function Make_Ctrl return Ctrl;

   package Nested with Ghost is
  procedure Proc;
   end Nested;
end Pack;

--  pack.adb

package body Pack is
   function Make_Ctrl return Ctrl is
   begin
  return Result : Ctrl;
   end Make_Ctrl;

   package body Nested is separate;
end Pack;

--  pack-nested.adb

separate (Pack)

package body Nested is
   procedure Proc is
  Res : constant Ctrl'Class := Make_Ctrl;
   begin null; end Proc;
end Nested;

-
-- Compilation --
-

$ gcc -c pack.adb

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

2018-05-24  Hristian Kirtchev  

gcc/ada/

* exp_util.adb (New_Class_Wide_Subtype): Capture and restore relevant
Ghost-related attributes of the class-wide subtype because the copy
clobbers them.--- gcc/ada/exp_util.adb
+++ gcc/ada/exp_util.adb
@@ -10580,26 +10580,44 @@ package body Exp_Util is
  (CW_Typ : Entity_Id;
   N  : Node_Id) return Entity_Id
is
-  Res   : constant Entity_Id := Create_Itype (E_Void, N);
-  Res_Name  : constant Name_Id   := Chars (Res);
-  Res_Scope : constant Entity_Id := Scope (Res);
+  Res : constant Entity_Id := Create_Itype (E_Void, N);
+
+  --  Capture relevant attributes of the class-wide subtype which must be
+  --  restored after the copy.
+
+  Res_Chars  : constant Name_Id   := Chars (Res);
+  Res_Is_CGE : constant Boolean   := Is_Checked_Ghost_Entity (Res);
+  Res_Is_IGE : constant Boolean   := Is_Ignored_Ghost_Entity (Res);
+  Res_Is_IGN : constant Boolean   := Is_Ignored_Ghost_Node   (Res);
+  Res_Scope  : constant Entity_Id := Scope (Res);
 
begin
   Copy_Node (CW_Typ, Res);
-  Set_Comes_From_Source (Res, False);
-  Set_Sloc (Res, Sloc (N));
-  Set_Is_Itype (Res);
+
+  --  Restore the relevant attributes of the class-wide subtype
+
+  Set_Chars   (Res, Res_Chars);
+  Set_Is_Checked_Ghost_Entity (Res, Res_Is_CGE);
+  Set_Is_Ignored_Ghost_Entity (Res, Res_Is_IGE);
+  Set_Is_Ignored_Ghost_Node   (Res, Res_Is_IGN);
+  Set_Scope   (Res, Res_Scope);
+
+  --  Decorate the class-wide subtype
+
   Set_Associated_Node_For_Itype (Res, N);
-  Set_Is_Public (Res, False);   --  By default, may be changed below.
+  Set_Comes_From_Source (Res, False);
+  Set_Ekind (Res, E_Class_Wide_Subtype);
+  Set_Etype (Res, Base_Type (CW_Typ));
+  Set_Freeze_Node   (Res, Empty);
+  Set_Is_Frozen (Res, False);
+  Set_Is_Itype  (Res);
+  Set_Is_Public (Res, False);
+  Set_Next_Entity   (Res, Empty);
+  Set_Sloc  (Res, Sloc (N));
+
   Set_Public_Status (Res);
-  Set_Chars (Res, Res_Name);
-  Set_Scope (Res, Res_Scope);
-  Set_Ekind (Res, E_Class_Wide_Subtype);
-  Set_Next_Entity (Res, Empty);
-  Set_Etype (Res, Base_Type (CW_Typ));
-  Set_Is_Frozen (Res, False);
-  Set_Freeze_Node (Res, Empty);
-  return (Res);
+
+  return Res;
end New_Class_Wide_Subtype;
 

[Ada] Memory leak mixing limited and nonlimited functions

[Pierre-Marie de Rodat]

This patch fixes a memory leak. If a build-in-place function with a result
whose size is not known at the call site is called, and that function calls a
non-build-in-place function that allocates on the secondary stack, the
secondary stack was not necessarily cleaned up, which caused a memory leak.

The following program should print:
"Current allocated space :  0 bytes"
(among other things) in the loop.

./bip_leak-main > log
grep 'Current allocated' log
  Current allocated space :  0 bytes
  Current allocated space :  0 bytes
  Current allocated space :  0 bytes

with Ada.Finalization;
package BIP_Leak is
   subtype Limited_Controlled is Ada.Finalization.Limited_Controlled;

   type Nonlim_Controlled is new Ada.Finalization.Controlled with null record;
   type Needs_Fin is record
  X : Nonlim_Controlled;
   end record;

   type Lim_Controlled is new Limited_Controlled with null record;

   function Return_Lim_Controlled (Source : Boolean)
   return Lim_Controlled;

   procedure Dump_SS;

end BIP_Leak;

with Ada.Text_IO;
pragma Warnings (Off);
with System.Secondary_Stack;
pragma Warnings (On);
package body BIP_Leak is
   function Transform (X : Needs_Fin) return Lim_Controlled is
   begin
  return (Limited_Controlled with null record);
   end;

   function Return_Needs_Fin (I : Boolean) return Needs_Fin is
 THR : Needs_Fin;
   begin
  return THR;
   end;

   function Return_Lim_Controlled (Source : Boolean)
   return Lim_Controlled is
   begin
  return Transform (Return_Needs_Fin (Source));
   end Return_Lim_Controlled;

   procedure Dump_SS_Instance is
 new System.Secondary_Stack.SS_Info (Ada.Text_IO.Put_Line);
   procedure Dump_SS renames Dump_SS_Instance;

end BIP_Leak;

procedure BIP_Leak.Main is
begin
   for Count in 1 .. 350_000 loop
  declare
 Msg : constant Lim_Controlled := Return_Lim_Controlled (True);
  begin
 if Count mod 100_000 = 0 then
Dump_SS;
 end if;
  end;
   end loop;
end BIP_Leak.Main;

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

2018-05-24  Bob Duff  

gcc/ada/

* exp_ch7.adb (Expand_Cleanup_Actions): Create a mark unconditionally
for build-in-place functions with a caller-unknown-size result.
(Create_Finalizer): For build-in-place functions with a
caller-unknown-size result, check at run time whether we need to
release the secondary stack.--- gcc/ada/exp_ch7.adb
+++ gcc/ada/exp_ch7.adb
@@ -1777,10 +1777,49 @@ package body Exp_Ch7 is
 Set_At_End_Proc (HSS, Empty);
  end if;
 
- --  Release the secondary stack mark
+ --  Release the secondary stack
 
  if Present (Mark_Id) then
-Append_To (Finalizer_Stmts, Build_SS_Release_Call (Loc, Mark_Id));
+declare
+   Release : Node_Id :=
+ Build_SS_Release_Call (Loc, Mark_Id);
+begin
+   --  If this is a build-in-place function, then we need to
+   --  release the secondary stack, unless we are returning on the
+   --  secondary stack. We wrap the release call in:
+   --if BIP_Alloc_Form /= Secondary_Stack then ...
+   --  If we are returning on the secondary stack, then releasing
+   --  is the caller's responsibility (or caller's caller, or ...).
+
+   if Nkind (N) = N_Subprogram_Body then
+  declare
+ Spec_Id : constant Entity_Id :=
+ Unique_Defining_Entity (N);
+ BIP_SS  : constant Boolean :=
+ Is_Build_In_Place_Function (Spec_Id)
+   and then Needs_BIP_Alloc_Form (Spec_Id);
+  begin
+ if BIP_SS then
+Release :=
+  Make_If_Statement (Loc,
+Condition =>
+  Make_Op_Ne (Loc,
+Left_Opnd  =>
+  New_Occurrence_Of
+(Build_In_Place_Formal
+  (Spec_Id, BIP_Alloc_Form), Loc),
+Right_Opnd =>
+  Make_Integer_Literal (Loc,
+UI_From_Int (BIP_Allocation_Form'Pos
+   (Secondary_Stack,
+
+Then_Statements => New_List (Release));
+ end if;
+  end;
+   end if;
+
+   Append_To (Finalizer_Stmts, Release);
+end;
  end if;
 
  --  Protect the statements with abort defer/undefer. This is only when
@@ -4327,10 +4366,22 @@ package body Exp_Ch7 is
and then Is_Task_Allocation_Block 

[Ada] Fix crash on formal containers

[Pierre-Marie de Rodat]

This patch modifies several mechanisms in the compiler:

1) The handling of Ghost regions now records the start of the outermost ignored
   Ghost region which is currently in effect.

2) Generation of freeze actions for an arbitrary entity now inserts the actions
   prior to the start of the outermost ignored Ghost region when the freezing
   takes effect within an ignored Ghost region, but the entity being frozen is
   "living". This ensures that any freeze actions associated with the living
   entity will not be eliminated from the tree once ignored Ghost code is
   stripped away.

3) The Default_Initial_Condition and Invariant procedures are not treated as
   primitives even when they apply to tagged types. These procedures already
   employ class-wide precondition-like semantics to handle inheritance and
   overriding. In addition, the procedures cannot be invoked from source and
   should not be targets of dispatching calls.

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

2018-05-24  Hristian Kirtchev  

gcc/ada/

* expander.adb (Expand): Update the save and restore of the Ghost
region.
* exp_ch3.adb (Freeze_Type): Likewise.
* exp_disp.adb (Make_DT): Likewise.
* exp_util.adb (Build_DIC_Procedure_Body): Likewise.
(Build_DIC_Procedure_Declaration): Likewise.
(Build_Invariant_Procedure_Body): Likewise.
(Build_Invariant_Procedure_Declaration): Likewise.
(Make_Predicate_Call): Likewise.
* freeze.adb (Add_To_Result): Insert the freeze action of a living
entity prior to the start of the enclosing ignored Ghost region.
(Freeze_Entity): Update the save and restore of the Ghost region.
* ghost.adb (Install_Ghost_Mode): Reimplemented.
(Install_Ghost_Region): New routine.
(Mark_And_Set_Ghost_Assignment): Install a region rather than a mode.
(Mark_And_Set_Ghost_Body): Likewise.
(Mark_And_Set_Ghost_Completion): Likewise.
(Mark_And_Set_Ghost_Declaration): Likewise.
(Mark_And_Set_Ghost_Instantiation): Likewise.
(Mark_And_Set_Ghost_Procedure_Call): Likewise.
(Name_To_Ghost_Mode): New routine.
(Restore_Ghost_Region): New routine.
* ghost.ads (Install_Ghost_Region): New routine.
(Restore_Ghost_Region): New routine.
* opt.ads: Add new global variable Ignored_Ghost_Region.
* rtsfind.adb (Load_RTU): Update the save and restore of the Ghost
region. Install a clean region.
* sem.adb (Analyze): Likewise.
(Do_Analyze): Likewise.
* sem_ch3.adb (Analyze_Object_Declaration): Likewise
(Derive_Progenitor_Subprograms): Use local variable Iface_Alias to
capture the ultimate alias of the current primitive.
(Process_Full_View): Update the save and restore of the Ghost region.
Do not inherit DIC and invariant procedures.
* sem_ch5.adb (Analyze_Assignment): Update the save and restore of the
Ghost region.
* sem_ch6.adb (Analyze_Procedure_Call): Likewise.
(Analyze_Subprogram_Body_Helper): Likewise.
* sem_ch7.adb (Analyze_Package_Body_Helper): Likewise.
* sem_ch12.adb (Analyze_Package_Instantiation): Likewise.
(Analyze_Subprogram_Instantiation): Likewise.
(Instantiate_Package_Body): Likewise.
(Instantiate_Subprogram_Body): Likewise.
* sem_ch13.adb (Build_Predicate_Functions): Likewise.
(Build_Predicate_Function_Declaration): Likewise.
* sem_disp.adb
(Add_Dispatching_Operation): Do not consider DIC and invariant
procedures.
(Check_Dispatching_Operation): Use Add_Dispatching_Operation to collect
a dispatching subprogram.
(Check_Operation_From_Private_View): Likewise.
(Override_Dispatching_Operation): Likewise.
* sem_prag.adb (Analyze_Contract_Cases_In_Decl_Part): Update the save
and restore of the Ghost region.
(Analyze_Initial_Condition_In_Decl_Part): Likewise.
(Analyze_Pragma): Update the save and restore of the Ghost region.
(Analyze_Pre_Post_Condition_In_Decl_Part): Likewise.
* sem_util.adb (Is_Suitable_Primitive): New routine.
* sem_util.ads (Is_Suitable_Primitive): New routine.
* sinfo.ads: Update the section of Ghost regions.

gcc/testsuite/

* gnat.dg/formal_containers.adb: New testcase.--- gcc/ada/exp_ch3.adb
+++ gcc/ada/exp_ch3.adb
@@ -7554,8 +7554,9 @@ package body Exp_Ch3 is
 
   Def_Id : constant Entity_Id := Entity (N);
 
-  Saved_GM : constant Ghost_Mode_Type := Ghost_Mode;
-  --  Save the Ghost mode to restore on exit
+  Saved_GM  : constant Ghost_Mode_Type := Ghost_Mode;
+  Saved_IGR : constant Node_Id := Ignored_Ghost_Region;
+  --  Save the Ghost-related attributes to restore on exit
 
   Result : Boolean := False;
 
@@ -7920,13 +7921,13 @@ package body Exp_Ch3 is
  end if;
 

[Ada] Spurious error on pragma Independent_Components

[Pierre-Marie de Rodat]

This patch modifies the analysis of pragma Independent_Components to account
for a side effect from handling of self-referential records which render the
pragma illegal.


-- Source --


--  pack.ads

package Pack is
   type OK is record
  Comp_1 : Integer;
  Comp_2 : access OK;
   end record;
   pragma Independent_Components (OK);

   type Error;
   pragma Independent_Components (Error);
   type Error is record
  Comp : Integer;
   end record;
end Pack;


-- Compilation and output --


$ gcc -c pack.ads
pack.ads:9:04: representation item must be after full type declaration

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

2018-05-24  Hristian Kirtchev  

gcc/ada/

* sem_prag.adb (Analyze_Pragma): Use the full view of an internally
generated incomplete type.--- gcc/ada/sem_prag.adb
+++ gcc/ada/sem_prag.adb
@@ -16999,6 +16999,38 @@ package body Sem_Prag is
 
 E := Entity (E_Id);
 
+--  A record type with a self-referential component of anonymous
+--  access type is given an incomplete view in order to handle the
+--  self reference:
+--
+--type Rec is record
+--   Self : access Rec;
+--end record;
+--
+--  becomes
+--
+--type Rec;
+--type Ptr is access Rec;
+--type Rec is record
+--   Self : Ptr;
+--end record;
+--
+--  Since the incomplete view is now the initial view of the type,
+--  the argument of the pragma will reference the incomplete view,
+--  but this view is illegal according to the semantics of the
+--  pragma.
+--
+--  Obtain the full view of an internally-generated incomplete type
+--  only. This way an attempt to associate the pragma with a source
+--  incomplete type is still caught.
+
+if Ekind (E) = E_Incomplete_Type
+  and then not Comes_From_Source (E)
+  and then Present (Full_View (E))
+then
+   E := Full_View (E);
+end if;
+
 --  A pragma that applies to a Ghost entity becomes Ghost for the
 --  purposes of legality checks and removal of ignored Ghost code.
 

[Ada] Fix inconsistent documentation for the Contract_Cases pragma

[Pierre-Marie de Rodat]

This patch propagates the renaming from "condition" to "case guard" in the
contract grammar to the paragraphs that describe the pragma semantics.

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

2018-05-24  Piotr Trojanek  

gcc/ada/

* doc/gnat_rm/implementation_defined_pragmas.rst (Contract_Cases):
Change "condition" to "case guard" after renaming in the contract
grammar.
* gnat_rm.texi: Regenerate.--- gcc/ada/doc/gnat_rm/implementation_defined_pragmas.rst
+++ gcc/ada/doc/gnat_rm/implementation_defined_pragmas.rst
@@ -1173,9 +1173,9 @@ are equivalent to
   pragma Postcondition (if C2 then Pred2);
 
 
-The precondition ensures that one and only one of the conditions is
+The precondition ensures that one and only one of the case guards is
 satisfied on entry to the subprogram.
-The postcondition ensures that for the condition that was True on entry,
+The postcondition ensures that for the case guard that was True on entry,
 the corrresponding consequence is True on exit. Other consequence expressions
 are not evaluated.
 
@@ -1190,13 +1190,13 @@ expressed as contract cases:
 The placement and visibility rules for ``Contract_Cases`` pragmas are
 identical to those described for preconditions and postconditions.
 
-The compiler checks that boolean expressions given in conditions and
-consequences are valid, where the rules for conditions are the same as
+The compiler checks that boolean expressions given in case guards and
+consequences are valid, where the rules for case guards are the same as
 the rule for an expression in ``Precondition`` and the rules for
 consequences are the same as the rule for an expression in
 ``Postcondition``. In particular, attributes ``'Old`` and
 ``'Result`` can only be used within consequence expressions.
-The condition for the last contract case may be ``others``, to denote
+The case guard for the last contract case may be ``others``, to denote
 any case not captured by the previous cases. The
 following is an example of use within a package spec:
 
@@ -1214,7 +1214,7 @@ following is an example of use within a package spec:
 
 
 The meaning of contract cases is that only one case should apply at each
-call, as determined by the corresponding condition evaluating to True,
+call, as determined by the corresponding case guard evaluating to True,
 and that the consequence for this case should hold when the subprogram
 returns.
 

--- gcc/ada/gnat_rm.texi
+++ gcc/ada/gnat_rm.texi
@@ -21,7 +21,7 @@
 
 @copying
 @quotation
-GNAT Reference Manual , Apr 23, 2018
+GNAT Reference Manual , Apr 24, 2018
 
 AdaCore
 
@@ -2556,9 +2556,9 @@ pragma Postcondition (if C1 then Pred1);
 pragma Postcondition (if C2 then Pred2);
 @end example
 
-The precondition ensures that one and only one of the conditions is
+The precondition ensures that one and only one of the case guards is
 satisfied on entry to the subprogram.
-The postcondition ensures that for the condition that was True on entry,
+The postcondition ensures that for the case guard that was True on entry,
 the corrresponding consequence is True on exit. Other consequence expressions
 are not evaluated.
 
@@ -2572,13 +2572,13 @@ pragma Contract_Cases (P => Q);
 The placement and visibility rules for @code{Contract_Cases} pragmas are
 identical to those described for preconditions and postconditions.
 
-The compiler checks that boolean expressions given in conditions and
-consequences are valid, where the rules for conditions are the same as
+The compiler checks that boolean expressions given in case guards and
+consequences are valid, where the rules for case guards are the same as
 the rule for an expression in @code{Precondition} and the rules for
 consequences are the same as the rule for an expression in
 @code{Postcondition}. In particular, attributes @code{'Old} and
 @code{'Result} can only be used within consequence expressions.
-The condition for the last contract case may be @code{others}, to denote
+The case guard for the last contract case may be @code{others}, to denote
 any case not captured by the previous cases. The
 following is an example of use within a package spec:
 
@@ -2594,7 +2594,7 @@ end Math_Functions;
 @end example
 
 The meaning of contract cases is that only one case should apply at each
-call, as determined by the corresponding condition evaluating to True,
+call, as determined by the corresponding case guard evaluating to True,
 and that the consequence for this case should hold when the subprogram
 returns.
 

[Ada] Expansion of discrete choices

[Pierre-Marie de Rodat]

This patch does some minor bookkeeping to avoid a potential double expansion
of discrete choices where at least one of them is a subtype with predicates.
No change in behavior, no need for a test.

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

2018-05-24  Hristian Kirtchev  

gcc/ada/

* exp_util.adb (Expand_Static_Predicates_In_Choices): Indicate that the
construct with discrete choices no longer contains a subtype with
predicates since the expansion already handled this case.--- gcc/ada/exp_util.adb
+++ gcc/ada/exp_util.adb
@@ -4995,6 +4995,8 @@ package body Exp_Util is
 
  Choice := Next_C;
   end loop;
+
+  Set_Has_SP_Choice (N, False);
end Expand_Static_Predicates_In_Choices;
 
--

[Ada] Crash on compilation unit instance

[Pierre-Marie de Rodat]

Do not generate a variable marker for a reference which appears within the
formal part of an instantiation which acts as a compilation unit because
there is no suitable insertion context.


-- Source --


--  gnat.adc

pragma SPARK_Mode (On);

--  gen.ads

generic
   Val_1 : Integer;
   Val_2 : Integer;
package Gen is
end Gen;

--  pack.ads

package Pack is
   Val : Integer := 123;

   function Get_Val return Integer;
end Pack;

--  inst.ads

with Gen;
with Pack; use Pack;

package Inst is new Gen (Val, Get_Val);

--  proc.adb

with Pack; use Pack;

procedure Proc (Val_1 : Integer := Val; Val_2 : Integer := Get_Val) is
begin null; end Proc;

-
-- Compilation --
-

$ gcc -c inst.ads
$ gcc -c inst.ads -gnatd.F
$ gcc -c proc.adb
$ gcc -c proc.adb -gnatd.F

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

2018-05-24  Hristian Kirtchev  

gcc/ada/

* sem_elab.adb (Build_Variable_Reference_Marker): Do not create a
variable marker when the reference appears in the formal part of a
compilation unit instance because there is no place to insert it.
(In_Compilation_Instance_Formal_Part): New routine.--- gcc/ada/sem_elab.adb
+++ gcc/ada/sem_elab.adb
@@ -2274,9 +2274,44 @@ package body Sem_Elab is
   Read  : Boolean;
   Write : Boolean)
is
+  function In_Compilation_Instance_Formal_Part
+(Nod : Node_Id) return Boolean;
+  --  Determine whether arbitrary node Nod appears within the formal part
+  --  of an instantiation which acts as a compilation unit.
+
   function In_Pragma (Nod : Node_Id) return Boolean;
   --  Determine whether arbitrary node Nod appears within a pragma
 
+  -
+  -- In_Compilation_Instance_Formal_Part --
+  -
+
+  function In_Compilation_Instance_Formal_Part
+(Nod : Node_Id) return Boolean
+  is
+ Par : Node_Id;
+
+  begin
+ Par := Nod;
+ while Present (Par) loop
+if Nkind (Par) = N_Generic_Association
+  and then Nkind (Parent (Par)) in N_Generic_Instantiation
+  and then Nkind (Parent (Parent (Par))) = N_Compilation_Unit
+then
+   return True;
+
+--  Prevent the search from going too far
+
+elsif Is_Body_Or_Package_Declaration (Par) then
+   exit;
+end if;
+
+Par := Parent (Par);
+ end loop;
+
+ return False;
+  end In_Compilation_Instance_Formal_Part;
+
   ---
   -- In_Pragma --
   ---
@@ -2349,6 +2384,15 @@ package body Sem_Elab is
   and then Entity (N) /= Any_Id)
   then
  return;
+
+  --  Nothing to do when the reference appears within the formal part of
+  --  an instantiation which acts as compilation unit because there is no
+  --  proper context for the insertion of the marker.
+
+  --  Performance note: parent traversal
+
+  elsif In_Compilation_Instance_Formal_Part (N) then
+ return;
   end if;
 
   Extract_Variable_Reference_Attributes

[Ada] Fix references to Backend_Layout configuration parameter

[Pierre-Marie de Rodat]

Apparently the Backend_Layout target configuration parameter was renamed to
Frontend_Layout a long time ago (and their meanings are opposite). However,
some comments were still referencing the no longer existing Backend_Layout.
This patch fixes such references.

No test provided, because only comments has been modified.

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

2018-05-24  Piotr Trojanek  

gcc/ada/

* layout.ads, repinfo.ads: Fix references to renamed Backend_Layout
configuration parameter.--- gcc/ada/layout.ads
+++ gcc/ada/layout.ads
@@ -26,7 +26,7 @@
 --  This package does front-end layout of types and objects. The result is
 --  to annotate the tree with information on size and alignment of types
 --  and objects. How much layout is performed depends on the setting of the
---  target dependent parameter Backend_Layout.
+--  target dependent parameter Frontend_Layout.
 
 with Types; use Types;
 
@@ -40,9 +40,9 @@ package Layout is
procedure Layout_Type (E : Entity_Id);
--  This procedure may set or adjust the fields Esize, RM_Size and
--  Alignment in the non-generic type or subtype entity E. If the
-   --  Backend_Layout switch is False, then it is guaranteed that all
+   --  Frontend_Layout switch is True, then it is guaranteed that all
--  three fields will be properly set on return. Regardless of the
-   --  Backend_Layout value, it is guaranteed that all discrete types
+   --  Frontend_Layout value, it is guaranteed that all discrete types
--  will have both Esize and RM_Size fields set on return (since
--  these are static values). Note that Layout_Type is not called
--  for generic types, since these play no part in code generation,
@@ -53,7 +53,7 @@ package Layout is
--  a loop parameter (E_Loop_Parameter), or a formal parameter of
--  a non-generic subprogram (E_In_Parameter, E_In_Out_Parameter,
--  or E_Out_Parameter). This procedure may set or adjust the
-   --  Esize and Alignment fields of E. If Backend_Layout is False,
+   --  Esize and Alignment fields of E. If Frontend_Layout is True,
--  then it is guaranteed that both fields will be properly set
--  on return. If the Esize is still unknown in the latter case,
--  it means that the object must be allocated dynamically, since

--- gcc/ada/repinfo.ads
+++ gcc/ada/repinfo.ads
@@ -56,13 +56,13 @@ package Repinfo is
--   for example in the case where representation clauses or
--   pragmas specify the values.
 
-   --2. If Backend_Layout is True, then the backend is responsible
+   --2. If Frontend_Layout is False, then the backend is responsible
--   for layout of all types and objects not laid out by the
--   front end. This includes all dynamic values, and also
--   static values (e.g. record sizes) when not set by the
--   front end.
 
-   --3. If Backend_Layout is False, then the front end lays out
+   --3. If Frontend_Layout is True, then the front end lays out
--   all data, according to target dependent size and alignment
--   information, creating dynamic inlinable functions where
--   needed in the case of sizes not known till runtime.
@@ -71,7 +71,7 @@ package Repinfo is
-- Back-Annotation by Gigi --
-
 
-   --  The following interface is used by gigi if Backend_Layout is True
+   --  The following interface is used by gigi if Frontend_Layout is False
 
--  As part of the processing in gigi, the types are laid out and
--  appropriate values computed for the sizes and component positions
@@ -209,7 +209,7 @@ package Repinfo is
-- Front-End Interface for Dynamic Size/Offset Values --

 
-   --  If Backend_Layout is False, then the front-end deals with all
+   --  If Frontend_Layout is True, then the front-end deals with all
--  dynamic size and offset fields. There are two cases:
 
--1. The value can be computed at the time of type freezing, and

[Ada] Spurious error on private task derivation

[Pierre-Marie de Rodat]

The compiler reports a spurious error notifying a missing constraint in the
declaration of a private type with discriminants whose full view is a
derivation of a task type.

After this patch the following test compiles without errors.

package Types1 is
   type Parent (Discr1 : Boolean) is limited private;
private
   task type Parent (Discr1 : Boolean);
end Types1;

with Types1; use Types1;
package Types2 is
   type Child (Discr2 : Boolean) is limited private;
private
   type Child (Discr2 : Boolean) is   -- Test
 new Parent (Discr1 => Discr2);
end Types2;

Command: gcc -c types2.ads

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

2018-05-24  Javier Miranda  

gcc/ada/

* sem_util.adb (Abstract_Interface_List): Add missing support for
private types whose full view is a synchronized type.
* sem_ch3.adb (Build_Derived_Private_Type): Skip building the full
derivation of a private type parent type is a task type with
discriminants as gigi does not use such type directly.--- gcc/ada/sem_ch3.adb
+++ gcc/ada/sem_ch3.adb
@@ -7856,12 +7856,12 @@ package body Sem_Ch3 is
  --  Build the full derivation if this is not the anonymous derived
  --  base type created by Build_Derived_Record_Type in the constrained
  --  case (see point 5. of its head comment) since we build it for the
- --  derived subtype. And skip it for protected types altogether, as
+ --  derived subtype. And skip it for synchronized types altogether, as
  --  gigi does not use these types directly.
 
  if Present (Full_View (Parent_Type))
and then not Is_Itype (Derived_Type)
-   and then not (Ekind (Full_View (Parent_Type)) in Protected_Kind)
+   and then not (Is_Concurrent_Type (Full_View (Parent_Type)))
  then
 declare
Der_Base   : constant Entity_Id := Base_Type (Derived_Type);

--- gcc/ada/sem_util.adb
+++ gcc/ada/sem_util.adb
@@ -184,11 +184,11 @@ package body Sem_Util is
  --  If we are dealing with a synchronized subtype, go to the base
  --  type, whose declaration has the interface list.
 
- --  Shouldn't this be Declaration_Node???
+ Nod := Declaration_Node (Base_Type (Typ));
 
- Nod := Parent (Base_Type (Typ));
-
- if Nkind (Nod) = N_Full_Type_Declaration then
+ if Nkind_In (Nod, N_Full_Type_Declaration,
+   N_Private_Type_Declaration)
+ then
 return Empty_List;
  end if;
 

[Ada] Spurious error on imported subprogram with precondition

[Pierre-Marie de Rodat]

This patch modifies the generation of wrappers for imported subprograms which
are subject to contracts. In the case of an imported function, the original
function is relocated within the wrapper, and the wrapper simply invokes the
imported subprogram, returning its value. When the result type of the imported
subprogram is anonymous access, the relocation creates a new anonymous access
type, but with a different accessibility level. Since both return types are
essentially the same type, eliminate the accessibility level inconsistency by
unchecked converting the result of calling the imported function to the return
type.


-- Source --


--  pack.ads

package Pack is
   type Integer_Ptr is access all Integer;
   type Typ is null record;

   function Predicate (Val : Typ) return Boolean is (True);

   function Imported_1 (Val : Typ) return access Integer
 with Pre => Predicate (Val), Import;

   function Imported_2 (Val : Typ) return Integer_Ptr
 with Pre => Predicate (Val), Import;
end Pack;

-
-- Compilation --
-

$ gcc -c pack.ads

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

2018-05-24  Hristian Kirtchev  

gcc/ada/

* freeze.adb (Wrap_Imported_Subprogram): Generate an unchecked
conversion to the return type to avoid a side effect where an imported
relocated function generates a new anonymous access type, whose
accessibility level does not agree with with that of the wrapper.--- gcc/ada/freeze.adb
+++ gcc/ada/freeze.adb
@@ -5172,13 +5172,24 @@ package body Freeze is
 
 --  Build the call
 
+--  An imported function whose result type is anonymous access
+--  creates a new anonynous access type when it is relocated into
+--  the declarations of the body generated below. As a result, the
+--  accessibility level of these two anonymous access types may not
+--  be compatible even though they are essentially the same type.
+--  Use an unchecked type conversion to reconcile this case. Note
+--  that the conversion is safe because in the named access type
+--  case, both the body and imported function utilize the same
+--  type.
+
 if Ekind_In (E, E_Function, E_Generic_Function) then
Stmt :=
  Make_Simple_Return_Statement (Loc,
Expression =>
- Make_Function_Call (Loc,
-   Name   => Make_Identifier (Loc, CE),
-   Parameter_Associations => Parms));
+ Unchecked_Convert_To (Etype (E),
+   Make_Function_Call (Loc,
+ Name   => Make_Identifier (Loc, CE),
+ Parameter_Associations => Parms)));
 
 else
Stmt :=

Re: [PATCH v2] Don't mark IFUNC resolver as only called directly

[Rainer Orth]

Hi H.J.,

> This is the patch I am checking in.  Tested on x86-64.
>
> Thanks.
>
> -- 
> H.J.
>
> From 91d0b4bc0222ce85bd529a7b3ae9e11904802c26 Mon Sep 17 00:00:00 2001
> From: "H.J. Lu" 
> Date: Wed, 11 Apr 2018 12:31:21 -0700
> Subject: [PATCH] Don't mark IFUNC resolver as only called directly
>
> Since IFUNC resolver is called indirectly, don't mark IFUNC resolver as
> only called directly.  This patch adds ifunc_resolver to cgraph_node,
> sets ifunc_resolver for ifunc attribute and checks ifunc_resolver
> instead of looking up ifunc attribute.
[...]
> gcc/testsuite/
>
>   PR target/85345
>   * gcc.target/i386/pr85345.c: New test.

the new testcase FAILs on Solaris/x86:

+FAIL: gcc.target/i386/pr85345.c (test for excess errors)
+UNRESOLVED: gcc.target/i386/pr85345.c scan-assembler-times mendbr 4

Excess errors:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/i386/pr85345.c:22:6: 
error: ifunc is not supported on this target

Fixed as follows after i386-pc-solaris2.11 testing, installed on mainline.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


2018-05-24  Rainer Orth  

* gcc.target/i386/pr85345.c: Require ifunc support.

# HG changeset patch
# Parent  ea73d713036e6dea58ea15adc3a38e73a0ecf660
Require ifunc support in gcc.target/i386/pr85345.c

	gcc/testsuite:
	* gcc.target/i386/pr85345.c: Require ifunc support.

diff --git a/gcc/testsuite/gcc.target/i386/pr85345.c b/gcc/testsuite/gcc.target/i386/pr85345.c
--- a/gcc/testsuite/gcc.target/i386/pr85345.c
+++ b/gcc/testsuite/gcc.target/i386/pr85345.c
@@ -1,5 +1,6 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -fcf-protection" } */
+/* { dg-require-ifunc "" } */
 /* { dg-final { scan-assembler-times {\mendbr} 4 } } */
 
 int resolver_fn = 0;

Re: Prefer open-coding vector integer division

[Richard Sandiford]

Richard Biener  writes:
> On Thu, May 24, 2018 at 10:31 AM Jakub Jelinek  wrote:
>> On Thu, May 24, 2018 at 09:21:35AM +0100, Richard Sandiford wrote:
>> > vect_recog_divmod_pattern currently bails out if the target has
>> > native support for integer division, but I think in practice
>> > it's always going to be better to open-code it anyway, just as
>> > we usually open-code scalar divisions by constants.
>> >
>> > I think the only currently affected target is MIPS MSA, where for:
>
>> Isn't powerpcspe affected too?  It has a divv2si3 pattern.

Ah, yeah.  I forgot to update the description after you mentioned
that on IRC, sorry.

>> > --- gcc/tree-vect-patterns.c  2018-05-16 12:48:59.115202362 +0100
>> > +++ gcc/tree-vect-patterns.c  2018-05-24 09:18:10.445466941 +0100
>> > @@ -2639,7 +2639,6 @@ vect_recog_divmod_pattern (vec
>> >enum tree_code rhs_code;
>> >stmt_vec_info stmt_vinfo = vinfo_for_stmt (last_stmt);
>> >vec_info *vinfo = stmt_vinfo->vinfo;
>> > -  optab optab;
>> >tree q;
>> >int dummy_int, prec;
>> >stmt_vec_info def_stmt_vinfo;
>> > @@ -2674,17 +2673,6 @@ vect_recog_divmod_pattern (vec
>> >if (vectype == NULL_TREE)
>> >  return NULL;
>> >
>> > -  /* If the target can handle vectorized division or modulo natively,
>> > - don't attempt to optimize this.  */
>> > -  optab = optab_for_tree_code (rhs_code, vectype, optab_default);
>> > -  if (optab != unknown_optab)
>> > -{
>> > -  machine_mode vec_mode = TYPE_MODE (vectype);
>> > -  int icode = (int) optab_handler (optab, vec_mode);
>> > -  if (icode != CODE_FOR_nothing)
>> > - return NULL;
>> > -}
>> > -
>
>> Shouldn't we instead keep it, but only do it if
>> optimize_bb_for_size_p (gimple_bb (last_stmt)) ?
>> I mean, a hw division is very likely shorter than what we replace it
> with...
>
> Good idea.  While loops are checked for optimize_loop_nest_for_speed if
> not forced vect BB vectorization has no such predicate.

Like this, if it passes testing?

Thanks,
Richard


2018-05-24  Richard Sandiford  

gcc/
* tree-vect-patterns.c: Include predict.h.
(vect_recog_divmod_pattern): Restrict check for division support
to when optimizing for size.

gcc/testsuite/
* gcc.dg/vect/bb-slp-div-1.c: New XFAILed test.

Index: gcc/tree-vect-patterns.c
===
*** gcc/tree-vect-patterns.c2018-05-24 13:50:21.656138942 +0100
--- gcc/tree-vect-patterns.c2018-05-24 13:50:21.819134113 +0100
*** vect_recog_divmod_pattern (vec
*** 2674,2688 
if (vectype == NULL_TREE)
  return NULL;
  
!   /* If the target can handle vectorized division or modulo natively,
!  don't attempt to optimize this.  */
!   optab = optab_for_tree_code (rhs_code, vectype, optab_default);
!   if (optab != unknown_optab)
  {
!   machine_mode vec_mode = TYPE_MODE (vectype);
!   int icode = (int) optab_handler (optab, vec_mode);
!   if (icode != CODE_FOR_nothing)
!   return NULL;
  }
  
prec = TYPE_PRECISION (itype);
--- 2674,2692 
if (vectype == NULL_TREE)
  return NULL;
  
!   if (optimize_bb_for_size_p (gimple_bb (last_stmt)))
  {
!   /* If the target can handle vectorized division or modulo natively,
!don't attempt to optimize this, since native division is likely
!to give smaller code.  */
!   optab = optab_for_tree_code (rhs_code, vectype, optab_default);
!   if (optab != unknown_optab)
!   {
! machine_mode vec_mode = TYPE_MODE (vectype);
! int icode = (int) optab_handler (optab, vec_mode);
! if (icode != CODE_FOR_nothing)
!   return NULL;
!   }
  }
  
prec = TYPE_PRECISION (itype);
Index: gcc/testsuite/gcc.dg/vect/bb-slp-div-1.c
===
*** /dev/null   2018-04-20 16:19:46.369131350 +0100
--- gcc/testsuite/gcc.dg/vect/bb-slp-div-1.c2018-05-24 13:50:21.818134143 
+0100
***
*** 0 
--- 1,19 
+ /* { dg-do compile } */
+ /* { dg-additional-options "-msve-vector-bits=256" { target aarch64_sve } } */
+ 
+ int x[8];
+ 
+ void
+ f (void)
+ {
+   x[0] /= 2;
+   x[1] /= 3;
+   x[2] /= 4;
+   x[3] /= 5;
+   x[4] /= 6;
+   x[5] /= 7;
+   x[6] /= 8;
+   x[7] /= 9;
+ }
+ 
+ /* { dg-final { scan-tree-dump "basic block vectorized" "slp2" { xfail *-*-* 
} } } */

Re: [PATCH][RFC] Radically simplify emission of balanced tree for switch statements.

[Rainer Orth]

Hi Martin,

> On 05/21/2018 01:18 PM, Rainer Orth wrote:
>> Hi Martin,
>> 
>>> On 05/18/2018 03:55 PM, Rainer Orth wrote:
 Hi Martin,

> So the patch looks fine, only very very slightly binary is produced. I'm
> going to install the patch so that
> I can carry on more complex patches based on this one.

 it seems you didn't properly test the testsuite part: I see

 +UNRESOLVED: gcc.dg/tree-prof/update-loopch.c scan-tree-dump switchlower
 "Removing basic block"
 +UNRESOLVED: gcc.dg/tree-prof/update-loopch.c scan-tree-dump switchlower
 "loop depth 1, count 3"
 +UNRESOLVED: gcc.dg/tree-prof/update-loopch.c scan-tree-dump-not
 switchlower "Invalid sum"
 +UNRESOLVED: gcc.dg/tree-prof/update-loopch.c scan-tree-dump-not
 switchlower "loop depth 1, count 2"

 everywhere.  The log has

 gcc.dg/tree-prof/update-loopch.c: dump file does not exist

 Obviously you forgot the adapt the dg-final* files for the dumpfile
 name.  If I do, three of the failures go away, but

 FAIL: gcc.dg/tree-prof/update-loopch.c scan-tree-dump switchlower1
 "Removing basic block"

 remains (on 32 and 64-bit Linux/x86_64).

 Please fix.

Rainer

>>>
>>> Thanks for opened eyes, following patch will fix that.
>>> It's quite obvious, I'll install it right after tests will finish.
>> 
>> unfortunately, it didn't fix either issue:
>> 
>> * The switchlower -> switchlower1 renames in the dg-final* lines
>>   (attached) are still necessary to avoid the UNRESOLVED errors.
>>   Although obvious, I haven't installed them since ...
>> 
>> * ... even so
>> 
>> FAIL: gcc.dg/tree-prof/update-loopch.c scan-tree-dump switchlower1 "Removing 
>> basic block"
>> 
>>   remains.
>> 
>>  Rainer
>
> Hi.
>
> You are right, it's using -O2, thus your patch is right. Please install the
> patch
> after testing. It's obvious fix.

I've now installed the fix for the dumpfile renaming.  However, you've
still done nothing about the remaining failure.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Fold VEC_COND_EXPRs to IFN_COND_* where possible

[Richard Sandiford]

Richard Biener  writes:
>> 2018-05-24  Richard Sandiford  
>
>> gcc/
>>  * doc/sourcebuild.texi (vect_double_cond_arith: Document.
>>  * gimple-match.h (gimple_match_op::MAX_NUM_OPS): Bump to 4.
>>  (gimple_match_op::gimple_match_op): Add an overload for 4
> operands.
>>  (gimple_match_op::set_op): Likewise.
>>  (gimple_resimplify4): Declare.
>>  * genmatch.c (commutative_op): Handle CFN_COND_* functions.
>
> ^^^  you don't seem to use that and I don't see how those are commutative
> in operands 1 and 2 without inverting operand 0.  So w/o adjusting the
> parsing part I think that people can write (cond_foo:c ...) and likely
> be surprised that it isn't rejected.  It is of course required to make :C
> work.

Operands 1 and 2 are the operands of the binary operation, and now
that the else value is specified separately, the functions are
commutative in those operands if the binary operation is commutative.
Of course, CFN_COND_SUB shouldn't have been there, sigh...

> The patch is ok if you drop this hunk for now.  You can re-introduce it
> as followup if you make sure to make :c error on those IFNs.

OK, thanks.  I'm happy to drop it for now.

Richard

Re: [PATCH 1/2] Introduce prefetch-minimum stride option

[Luis Machado]

On 05/23/2018 10:57 PM, Jeff Law wrote:

On 05/23/2018 04:50 PM, Luis Machado wrote:

On 05/23/2018 07:42 PM, H.J. Lu wrote:

On Wed, May 23, 2018 at 3:41 PM, H.J. Lu  wrote:

On Wed, May 23, 2018 at 3:35 PM, H.J. Lu  wrote:



Sorry. Does the following fix it for i686?



Index: gcc/tree-ssa-loop-prefetch.c
===
--- gcc/tree-ssa-loop-prefetch.c (revision 260625)
+++ gcc/tree-ssa-loop-prefetch.c (working copy)
@@ -1014,7 +1014,8 @@
    fprintf (dump_file,
    "Step for reference %u:%u (%ld) is less than the mininum "
    ^^^ Please use
HOST_WIDE_INT_PRINT_DEC
    "required stride of %d\n",
- ref->group->uid, ref->uid, int_cst_value (ref->group->step),
+ ref->group->uid, ref->uid,
+ (HOST_WIDE_INT) int_cst_value (ref->group->step),
    PREFETCH_MINIMUM_STRIDE);




Something like this.

--
H.J.
---
diff --git a/gcc/tree-ssa-loop-prefetch.c b/gcc/tree-ssa-loop-prefetch.c
index c3e7fd1e529..949a67f360e 100644
--- a/gcc/tree-ssa-loop-prefetch.c
+++ b/gcc/tree-ssa-loop-prefetch.c
@@ -1012,8 +1012,8 @@ should_issue_prefetch_p (struct mem_ref *ref)
   {
     if (dump_file && (dump_flags & TDF_DETAILS))
     fprintf (dump_file,
-  "Step for reference %u:%u (%ld) is less than the mininum "
-  "required stride of %d\n",
+  "Step for reference %u:%u (" HOST_WIDE_INT_PRINT_C
+  ") is less than the mininum required stride of %d\n",
     ref->group->uid, ref->uid, int_cst_value (ref->group->step),
     PREFETCH_MINIMUM_STRIDE);
     return false;


I meant:

diff --git a/gcc/tree-ssa-loop-prefetch.c b/gcc/tree-ssa-loop-prefetch.c
index c3e7fd1e529..e34b78dc186 100644
--- a/gcc/tree-ssa-loop-prefetch.c
+++ b/gcc/tree-ssa-loop-prefetch.c
@@ -1012,8 +1012,8 @@ should_issue_prefetch_p (struct mem_ref *ref)
   {
     if (dump_file && (dump_flags & TDF_DETAILS))
     fprintf (dump_file,
-  "Step for reference %u:%u (%ld) is less than the mininum "
-  "required stride of %d\n",
+  "Step for reference %u:%u (" HOST_WIDE_INT_PRINT_DEC
+  ") is less than the mininum required stride of %d\n",
     ref->group->uid, ref->uid, int_cst_value (ref->group->step),
     PREFETCH_MINIMUM_STRIDE);
     return false;




Pushed now. Sorry for the breakage.

For future reference, is there an i686 system on the gcc farm that i can
use to validate this?

My tester uses gcc45.  In theory you could probably also do it in an
i686 chroot on an x86_64 system.  My tester does that for testing ppc32
on a ppc64 system.


Got it. Thanks for the info.

Re: Support fused multiply-adds in fully-masked reductions

[Richard Sandiford]

Richard Biener  writes:
> On Wed, May 16, 2018 at 11:26 AM Richard Sandiford <
> richard.sandif...@linaro.org> wrote:
>
>> This patch adds support for fusing a conditional add or subtract
>> with a multiplication, so that we can use fused multiply-add and
>> multiply-subtract operations for fully-masked reductions.  E.g.
>> for SVE we vectorise:
>
>>double res = 0.0;
>>for (int i = 0; i < n; ++i)
>>  res += x[i] * y[i];
>
>> using a fully-masked loop in which the loop body has the form:
>
>>res_1 = PHI<0(preheader), res_2(latch)>;
>>avec = IFN_MASK_LOAD (loop_mask, a)
>>bvec = IFN_MASK_LOAD (loop_mask, b)
>>prod = avec * bvec;
>>res_2 = IFN_COND_ADD (loop_mask, res_1, prod);
>
>> where the last statement does the equivalent of:
>
>>res_2 = loop_mask ? res_1 + prod : res_1;
>
>> (operating elementwise).  The point of the patch is to convert the last
>> two statements into a single internal function that is the equivalent of:
>
>>res_2 = loop_mask ? fma (avec, bvec, res_1) : res_1;
>
>> (again operating elementwise).
>
>> All current conditional X operations have the form "do X or don't do X
>> to the first operand" (add/don't add to first operand, etc.).  However,
>> the FMA optabs and functions are ordered so that the accumulator comes
>> last.  There were two obvious ways of resolving this: break the
>> convention for conditional operators and have "add/don't add to the
>> final operand" or break the convention for FMA and put the accumulator
>> first.  The patch goes for the latter, but adds _REV to make it obvious
>> that the operands are in a different order.
>
> Eh.  I guess you'll do the same to SAD/DOT_PROD/WIDEN_SUM?
>
> That said, I don't really see the "do or not do to the first operand", it's
> "do or not do the operation on operands 1 to 2 (or 3)".  None of the
> current ops modify operand 1, they all produce a new value, no?

Yeah, neither the current functions nor these ones actually changed
operand 1.  It was all about deciding what the "else" value should be.
The _REV thing was a "fix" for the fact that we wanted the else value
to be the final operand of fma.

Of course, the real fix was to make all the IFN_COND_* functions take an
explicit else value, as you suggested in the review of the other patch
in the series.  So all this _REV stuff is redundant now.

Here's an updated version based on top of the IFN_COND_FMA patch
that I just posted.  Tested in the same way.

Thanks,
Richard

2018-05-24  Richard Sandiford  
Alan Hayward  
David Sherwood  

gcc/
* internal-fn.h (can_interpret_as_conditional_op_p): Declare.
* internal-fn.c (can_interpret_as_conditional_op_p): New function.
* tree-ssa-math-opts.c (convert_mult_to_fma_1): Handle conditional
plus and minus and convert them into IFN_COND_FMA-based sequences.
(convert_mult_to_fma): Handle conditional plus and minus.

gcc/testsuite/
* gcc.dg/vect/vect-fma-2.c: New test.
* gcc.target/aarch64/sve/reduc_4.c: Likewise.
* gcc.target/aarch64/sve/reduc_6.c: Likewise.
* gcc.target/aarch64/sve/reduc_7.c: Likewise.

Index: gcc/internal-fn.h
===
--- gcc/internal-fn.h   2018-05-24 13:05:46.049605128 +0100
+++ gcc/internal-fn.h   2018-05-24 13:08:24.643987582 +0100
@@ -196,6 +196,9 @@ extern internal_fn get_conditional_inter
 extern internal_fn get_conditional_internal_fn (internal_fn);
 extern tree_code conditional_internal_fn_code (internal_fn);
 extern internal_fn get_unconditional_internal_fn (internal_fn);
+extern bool can_interpret_as_conditional_op_p (gimple *, tree *,
+  tree_code *, tree (&)[3],
+  tree *);
 
 extern bool internal_load_fn_p (internal_fn);
 extern bool internal_store_fn_p (internal_fn);
Index: gcc/internal-fn.c
===
--- gcc/internal-fn.c   2018-05-24 13:05:46.048606357 +0100
+++ gcc/internal-fn.c   2018-05-24 13:08:24.643987582 +0100
@@ -,6 +,62 @@ #define CASE(NAME) case IFN_COND_##NAME:
 }
 }
 
+/* Return true if STMT can be interpreted as a conditional tree code
+   operation of the form:
+
+ LHS = COND ? OP (RHS1, ...) : ELSE;
+
+   operating elementwise if the operands are vectors.  This includes
+   the case of an all-true COND, so that the operation always happens.
+
+   When returning true, set:
+
+   - *COND_OUT to the condition COND, or to NULL_TREE if the condition
+ is known to be all-true
+   - *CODE_OUT to the tree code
+   - OPS[I] to operand I of *CODE_OUT
+   - *ELSE_OUT to the fallback value ELSE, or to NULL_TREE if the
+ condition is known to be all true.  */
+
+bool
+can_interpret_as_conditional_op_p (gimple *stmt, tree *cond_out,
+   

Re: [RFT PATCH, AVX512]: Implement scalar unsigned int->float conversions with AVX512F

[H.J. Lu]

On Wed, May 23, 2018 at 8:15 AM, Uros Bizjak  wrote:
> On Wed, May 23, 2018 at 11:39 AM, Peryt, Sebastian
>  wrote:
>>> From: Uros Bizjak [mailto:ubiz...@gmail.com]
>>> Sent: Tuesday, May 22, 2018 8:43 PM
>>> To: gcc-patches@gcc.gnu.org
>>> Cc: Peryt, Sebastian ; Jakub Jelinek
>>> 
>>> Subject: [RFT PATCH, AVX512]: Implement scalar unsigned int->float 
>>> conversions
>>> with AVX512F
>>>
>>> Hello!
>>>
>>> Attached patch implements scalar unsigned int->float conversions with
>>> AVX512F.
>>>
>>> 2018-05-22  Uros Bizjak  
>>>
>>> * config/i386/i386.md (*floatuns2_avx512):
>>> New insn pattern.
>>> (floatunssi2): Also enable for AVX512F and TARGET_SSE_MATH.
>>> Rewrite expander pattern.  Emit gen_floatunssi2_i387_with_xmm
>>> for non-SSE modes.
>>> (floatunsdisf2): Rewrite expander pattern.  Hanlde TARGET_AVX512F.
>>> (floatunsdidf2): Ditto.
>>>
>>> testsuite/ChangeLog:
>>>
>>> 2018-05-22  Uros Bizjak  
>>>
>>> * gcc.target/i386/cvt-3.c: New test.
>>>
>>> Patch was bootstrapped and regression tested on x86_64-linux-gnu {,-m32}., 
>>> but
>>> not tested on AVX512 target.
>>
>> I have checked it on x86_64-linux-gnu {,-m32} on SKX and don't see any 
>> stability regressions.
>
> Thanks!
>
> Committed to mainline SVN.
>

This caused:

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


-- 
H.J.

Add IFN_COND_FMA functions

[Richard Sandiford]

This patch adds conditional equivalents of the IFN_FMA built-in functions.
Most of it is just a mechanical extension of the binary stuff.

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

Richard


2018-05-24  Richard Sandiford  

gcc/
* doc/md.texi (cond_fma, cond_fms, cond_fnma, cond_fnms): Document.
* optabs.def (cond_fma_optab, cond_fms_optab, cond_fnma_optab)
(cond_fnms_optab): New optabs.
* internal-fn.def (COND_FMA, COND_FMS, COND_FNMA, COND_FNMS): New
internal functions.
(FMA): Use DEF_INTERNAL_FLT_FN rather than DEF_INTERNAL_FLT_FLOATN_FN.
* internal-fn.h (get_conditional_internal_fn): Declare.
(get_unconditional_internal_fn): Likewise.
* internal-fn.c (cond_ternary_direct): New macro.
(expand_cond_ternary_optab_fn): Likewise.
(direct_cond_ternary_optab_supported_p): Likewise.
(FOR_EACH_COND_FN_PAIR): Likewise.
(get_conditional_internal_fn): New function.
(get_unconditional_internal_fn): Likewise.
* gimple-match.h (gimple_match_op::MAX_NUM_OPS): Bump to 5.
(gimple_match_op::gimple_match_op): Add a new overload for 5
operands.
(gimple_match_op::set_op): Likewise.
(gimple_resimplify5): Declare.
* genmatch.c (decision_tree::gen): Generate simplifications for
5 operands.
* gimple-match-head.c (gimple_simplify): Define an overload for
5 operands.  Handle calls with 5 arguments in the top-level overload.
(convert_conditional_op): Handle conversions from unconditional
internal functions to conditional ones.
(gimple_resimplify5): New function.
(build_call_internal): Pass a fifth operand.
(maybe_push_res_to_seq): Likewise.
(try_conditional_simplification): Try converting conditional
internal functions to unconditional internal functions.
Handle 3-operand unconditional forms.
* match.pd (UNCOND_TERNARY, COND_TERNARY): Operator lists.
Define ternary equivalents of the current rules for binary conditional
internal functions.
* config/aarch64/aarch64.c (aarch64_preferred_else_value): Handle
ternary operations.
* config/aarch64/aarch64-sve.md (cond_)
(*cond_, *cond__acc): New
SVE_COND_FP_TERNARY patterns.
* config/aarch64/iterators.md (UNSPEC_COND_FMLA, UNSPEC_COND_FMLS)
(UNSPEC_COND_FNMLA, UNSPEC_COND_FNMLS): New unspecs.
(optab): Handle them.
(SVE_COND_FP_TERNARY): New int iterator.
(sve_fmla_op, sve_fmad_op): New int attributes.

gcc/testsuite/
* gcc.dg/vect/vect-cond-arith-3.c: New test.
* gcc.target/aarch64/sve/vcond_13.c: Likewise.
* gcc.target/aarch64/sve/vcond_13_run.c: Likewise.
* gcc.target/aarch64/sve/vcond_14.c: Likewise.
* gcc.target/aarch64/sve/vcond_14_run.c: Likewise.
* gcc.target/aarch64/sve/vcond_15.c: Likewise.
* gcc.target/aarch64/sve/vcond_15_run.c: Likewise.
* gcc.target/aarch64/sve/vcond_16.c: Likewise.
* gcc.target/aarch64/sve/vcond_16_run.c: Likewise.

Index: gcc/doc/md.texi
===
--- gcc/doc/md.texi 2018-05-24 10:12:10.142352315 +0100
+++ gcc/doc/md.texi 2018-05-24 13:05:46.047607587 +0100
@@ -6386,6 +6386,23 @@ Operands 0, 2, 3 and 4 all have mode @va
 integer if @var{m} is scalar, otherwise it has the mode returned by
 @code{TARGET_VECTORIZE_GET_MASK_MODE}.
 
+@cindex @code{cond_fma@var{mode}} instruction pattern
+@cindex @code{cond_fms@var{mode}} instruction pattern
+@cindex @code{cond_fnma@var{mode}} instruction pattern
+@cindex @code{cond_fnms@var{mode}} instruction pattern
+@item @samp{cond_fma@var{mode}}
+@itemx @samp{cond_fms@var{mode}}
+@itemx @samp{cond_fnma@var{mode}}
+@itemx @samp{cond_fnms@var{mode}}
+Like @samp{cond_add@var{m}}, except that the conditional operation
+takes 3 operands rather than two.  For example, the vector form of
+@samp{cond_fma@var{mode}} is equivalent to:
+
+@smallexample
+for (i = 0; i < GET_MODE_NUNITS (@var{m}); i++)
+  op0[i] = op1[i] ? fma (op2[i], op3[i], op4[i]) : op5[i];
+@end smallexample
+
 @cindex @code{neg@var{mode}cc} instruction pattern
 @item @samp{neg@var{mode}cc}
 Similar to @samp{mov@var{mode}cc} but for conditional negation.  Conditionally
Index: gcc/optabs.def
===
--- gcc/optabs.def  2018-05-24 10:12:10.146352152 +0100
+++ gcc/optabs.def  2018-05-24 13:05:46.049605128 +0100
@@ -234,6 +234,10 @@ OPTAB_D (cond_smin_optab, "cond_smin$a")
 OPTAB_D (cond_smax_optab, "cond_smax$a")
 OPTAB_D (cond_umin_optab, "cond_umin$a")
 OPTAB_D (cond_umax_optab, "cond_umax$a")
+OPTAB_D (cond_fma_optab, "cond_fma$a")
+OPTAB_D (cond_fms_optab, "cond_fms$a")
+OPTAB_D (cond_fnma_optab, 

[PATCH] Check ifunc_resolver only on FUNCTION_DECL

[H.J. Lu]

Since ifunc_resolver is only valid on FUNCTION_DECL, check ifunc_resolver
only on FUNCTION_DECL.

Please test it on Darwin.


H.J.
---
PR target/85900
PR target/85345
* varasm.c (assemble_alias): Check ifunc_resolver only on
FUNCTION_DECL.
---
 gcc/varasm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/varasm.c b/gcc/varasm.c
index 3bd9cbb69f0..bff43450a91 100644
--- a/gcc/varasm.c
+++ b/gcc/varasm.c
@@ -5917,7 +5917,8 @@ assemble_alias (tree decl, tree target)
 # else
   if (!DECL_WEAK (decl))
{
- if (cgraph_node::get (decl)->ifunc_resolver)
+ if (TREE_CODE (decl) == FUNCTION_DECL
+ && cgraph_node::get (decl)->ifunc_resolver)
error_at (DECL_SOURCE_LOCATION (decl),
  "ifunc is not supported in this configuration");
  else
-- 
2.17.0

Re: Support fused multiply-adds in fully-masked reductions

[Richard Biener]

On Wed, May 16, 2018 at 11:26 AM Richard Sandiford <
richard.sandif...@linaro.org> wrote:

> This patch adds support for fusing a conditional add or subtract
> with a multiplication, so that we can use fused multiply-add and
> multiply-subtract operations for fully-masked reductions.  E.g.
> for SVE we vectorise:

>double res = 0.0;
>for (int i = 0; i < n; ++i)
>  res += x[i] * y[i];

> using a fully-masked loop in which the loop body has the form:

>res_1 = PHI<0(preheader), res_2(latch)>;
>avec = IFN_MASK_LOAD (loop_mask, a)
>bvec = IFN_MASK_LOAD (loop_mask, b)
>prod = avec * bvec;
>res_2 = IFN_COND_ADD (loop_mask, res_1, prod);

> where the last statement does the equivalent of:

>res_2 = loop_mask ? res_1 + prod : res_1;

> (operating elementwise).  The point of the patch is to convert the last
> two statements into a single internal function that is the equivalent of:

>res_2 = loop_mask ? fma (avec, bvec, res_1) : res_1;

> (again operating elementwise).

> All current conditional X operations have the form "do X or don't do X
> to the first operand" (add/don't add to first operand, etc.).  However,
> the FMA optabs and functions are ordered so that the accumulator comes
> last.  There were two obvious ways of resolving this: break the
> convention for conditional operators and have "add/don't add to the
> final operand" or break the convention for FMA and put the accumulator
> first.  The patch goes for the latter, but adds _REV to make it obvious
> that the operands are in a different order.

Eh.  I guess you'll do the same to SAD/DOT_PROD/WIDEN_SUM?

That said, I don't really see the "do or not do to the first operand", it's
"do or not do the operation on operands 1 to 2 (or 3)".  None of the
current ops modify operand 1, they all produce a new value, no?

> Tested on aarch64-linux-gnu (with and without SVE), aarch64_be-elf
> and x86_64-linux-gnu.  OK to install?

OK, but as said I don't see a reason for the operand order to differ
in the first place.

Richard.

> Richard


> 2018-05-16  Richard Sandiford  
>  Alan Hayward  
>  David Sherwood  

> gcc/
>  * doc/md.texi (cond_fma_rev, cond_fnma_rev): Document.
>  * optabs.def (cond_fma_rev, cond_fnma_rev): New optabs.
>  * internal-fn.def (COND_FMA_REV, COND_FNMA_REV): New internal
>  functions.
>  * internal-fn.h (can_interpret_as_conditional_op_p): Declare.
>  * internal-fn.c (cond_ternary_direct): New macro.
>  (expand_cond_ternary_optab_fn): Likewise.
>  (direct_cond_ternary_optab_supported_p): Likewise.
>  (FOR_EACH_CODE_MAPPING): Likewise.
>  (get_conditional_internal_fn): Use FOR_EACH_CODE_MAPPING.
>  (conditional_internal_fn_code): New function.
>  (can_interpret_as_conditional_op_p): Likewise.
>  * tree-ssa-math-opts.c (fused_cond_internal_fn): New function.
>  (convert_mult_to_fma_1): Transform calls to IFN_COND_ADD to
>  IFN_COND_FMA_REV and calls to IFN_COND_SUB to IFN_COND_FNMA_REV.
>  (convert_mult_to_fma): Handle calls to IFN_COND_ADD and
IFN_COND_SUB.
>  * genmatch.c (commutative_op): Handle CFN_COND_FMA_REV and
>  CFN_COND_FNMA_REV.
>  * config/aarch64/iterators.md (UNSPEC_COND_FMLA): New unspec.
>  (UNSPEC_COND_FMLS): Likewise.
>  (optab, sve_fp_op): Handle them.
>  (SVE_COND_INT_OP): Rename to...
>  (SVE_COND_INT2_OP): ...this.
>  (SVE_COND_FP_OP): Rename to...
>  (SVE_COND_FP2_OP): ...this.
>  (SVE_COND_FP3_OP): New iterator.
>  * config/aarch64/aarch64-sve.md (cond_): Update
>  for new iterator names.  Add a pattern for SVE_COND_FP3_OP.

> gcc/testsuite/
>  * gcc.target/aarch64/sve/reduc_4.c: New test.
>  * gcc.target/aarch64/sve/reduc_6.c: Likewise.
>  * gcc.target/aarch64/sve/reduc_7.c: Likewise.

> Index: gcc/doc/md.texi
> ===
> --- gcc/doc/md.texi 2018-05-16 10:23:03.590853492 +0100
> +++ gcc/doc/md.texi 2018-05-16 10:23:03.886838736 +0100
> @@ -6367,6 +6367,32 @@ be in a normal C @samp{?:} condition.
>   Operands 0, 2 and 3 all have mode @var{m}, while operand 1 has the mode
>   returned by @code{TARGET_VECTORIZE_GET_MASK_MODE}.

> +@cindex @code{cond_fma_rev@var{mode}} instruction pattern
> +@item @samp{cond_fma_rev@var{mode}}
> +Similar to @samp{cond_add@var{m}}, but compute:
> +@smallexample
> +op0 = op1 ? fma (op3, op4, op2) : op2;
> +@end smallexample
> +for scalars and:
> +@smallexample
> +op0[I] = op1[I] ? fma (op3[I], op4[I], op2[I]) : op2[I];
> +@end smallexample
> +for vectors.  The @samp{_rev} indicates that the addend (operand 2)
> +comes first.
> +
> +@cindex @code{cond_fnma_rev@var{mode}} instruction pattern
> +@item @samp{cond_fnma_rev@var{mode}}
> 

Re: Add IFN_COND_{MUL,DIV,MOD,RDIV}

[Richard Biener]

On Thu, May 24, 2018 at 11:34 AM Richard Sandiford <
richard.sandif...@linaro.org> wrote:

> This patch adds support for conditional multiplication and division.
> It's mostly mechanical, but a few notes:

> * The *_optab name and the .md names are the same as the unconditional
>forms, just with "cond_" added to the front.  This means we still
>have the awkward difference between sdiv and div, etc.

> * It was easier to retain the difference between integer and FP
>division in the function names, given that they map to different
>tree codes (TRUNC_DIV_EXPR and RDIV_EXPR).

> * SVE has no direct support for IFN_COND_MOD, but it seemed more
>consistent to add it anyway.

> * Adding IFN_COND_MUL enables an extra fully-masked reduction
>in gcc.dg/vect/pr53773.c.

> * In practice we don't actually use the integer division forms without
>if-conversion support (added by a later patch).

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

OK.

Richard.

> Richard


> 2018-05-24  Richard Sandiford  

> gcc/
>  * doc/sourcebuild.texi (vect_double_cond_arith): Include
>  multiplication and division.
>  * doc/md.texi (cond_mul@var{m}, cond_div@var{m}, cond_mod@var{m})
>  (cond_udiv@var{m}, cond_umod@var{m}): Document.
>  * optabs.def (cond_smul_optab, cond_sdiv_optab, cond_smod_optab)
>  (cond_udiv_optab, cond_umod_optab): New optabs.
>  * internal-fn.def (IFN_COND_MUL, IFN_COND_DIV, IFN_COND_MOD)
>  (IFN_COND_RDIV): New internal functions.
>  * internal-fn.c (get_conditional_internal_fn): Handle
TRUNC_DIV_EXPR,
>  TRUNC_MOD_EXPR and RDIV_EXPR.
>  * genmatch.c (commutative_op): Handle CFN_COND_MUL.
>  * match.pd (UNCOND_BINARY, COND_BINARY): Handle them.
>  * config/aarch64/iterators.md (UNSPEC_COND_MUL, UNSPEC_COND_DIV):
>  New unspecs.
>  (SVE_INT_BINARY): Include mult.
>  (SVE_COND_FP_BINARY): Include UNSPEC_MUL and UNSPEC_DIV.
>  (optab, sve_int_op): Handle mult.
>  (optab, sve_fp_op, commutative): Handle UNSPEC_COND_MUL and
>  UNSPEC_COND_DIV.
>  * config/aarch64/aarch64-sve.md (cond_): New pattern
>  for SVE_INT_BINARY_SD.

> gcc/testsuite/
>  * lib/target-supports.exp
>  (check_effective_target_vect_double_cond_arith): Include
>  multiplication and division.
>  * gcc.dg/vect/pr53773.c: Do not expect a scalar tail when using
>  fully-masked loops with a fixed vector length.
>  * gcc.dg/vect/vect-cond-arith-1.c: Add multiplication and division
>  tests.
>  * gcc.target/aarch64/sve/vcond_8.c: Likewise.
>  * gcc.target/aarch64/sve/vcond_9.c: Likewise.
>  * gcc.target/aarch64/sve/vcond_12.c: Add multiplication tests.

> Index: gcc/doc/sourcebuild.texi
> ===
> --- gcc/doc/sourcebuild.texi2018-05-24 09:54:37.508451387 +0100
> +++ gcc/doc/sourcebuild.texi2018-05-24 10:12:10.145352193 +0100
> @@ -1426,8 +1426,9 @@ have different type from the value opera
>   Target supports hardware vectors of @code{double}.

>   @item vect_double_cond_arith
> -Target supports conditional addition, subtraction, minimum and maximum
> -on vectors of @code{double}, via the @code{cond_} optabs.
> +Target supports conditional addition, subtraction, multiplication,
> +division, minimum and maximum on vectors of @code{double}, via the
> +@code{cond_} optabs.

>   @item vect_element_align_preferred
>   The target's preferred vector alignment is the same as the element
> Index: gcc/doc/md.texi
> ===
> --- gcc/doc/md.texi 2018-05-24 09:32:10.522816506 +0100
> +++ gcc/doc/md.texi 2018-05-24 10:12:10.142352315 +0100
> @@ -6333,6 +6333,11 @@ operand 0, otherwise (operand 2 + operan

>   @cindex @code{cond_add@var{mode}} instruction pattern
>   @cindex @code{cond_sub@var{mode}} instruction pattern
> +@cindex @code{cond_mul@var{mode}} instruction pattern
> +@cindex @code{cond_div@var{mode}} instruction pattern
> +@cindex @code{cond_udiv@var{mode}} instruction pattern
> +@cindex @code{cond_mod@var{mode}} instruction pattern
> +@cindex @code{cond_umod@var{mode}} instruction pattern
>   @cindex @code{cond_and@var{mode}} instruction pattern
>   @cindex @code{cond_ior@var{mode}} instruction pattern
>   @cindex @code{cond_xor@var{mode}} instruction pattern
> @@ -6342,6 +6347,11 @@ operand 0, otherwise (operand 2 + operan
>   @cindex @code{cond_umax@var{mode}} instruction pattern
>   @item @samp{cond_add@var{mode}}
>   @itemx @samp{cond_sub@var{mode}}
> +@itemx @samp{cond_mul@var{mode}}
> +@itemx @samp{cond_div@var{mode}}
> +@itemx @samp{cond_udiv@var{mode}}
> +@itemx @samp{cond_mod@var{mode}}
> +@itemx @samp{cond_umod@var{mode}}
>   @itemx 

Re: Fold VEC_COND_EXPRs to IFN_COND_* where possible

[Richard Biener]

On Thu, May 24, 2018 at 11:28 AM Richard Sandiford <
richard.sandif...@linaro.org> wrote:

> This patch adds the folds:

>(vec_cond COND (foo A B) C) -> (IFN_COND_FOO COND A B C)
>(vec_cond COND C (foo A B)) -> (IFN_COND_FOO (!COND) A B C)

> with the usual implicit restriction that the target must support
> the produced IFN_COND_FOO.

> The results of these folds don't have identical semantics, since
> the reverse transform would be invalid if (FOO A[i] B[i]) faults when
> COND[i] is false.  But this direction is OK since we're simply dropping
> faults for operations whose results aren't needed.

> The new gimple_resimplify4 doesn't try to do any constant folding
> on the IFN_COND_*s.  This is because a later patch will handle it
> by folding the associated unconditional operation.

> Doing this in gimple is better than doing it in .md patterns,
> since the second form (with the inverted condition) is much more
> common than the first, and it's better to fold away the inversion
> in gimple and optimise the result before entering expand.

> Tested on aarch64-linux-gnu (with and without SVE), aarch64_be-elf
> and x86_64-linux-gnu.  OK to install?

> Richard


> 2018-05-24  Richard Sandiford  

> gcc/
>  * doc/sourcebuild.texi (vect_double_cond_arith: Document.
>  * gimple-match.h (gimple_match_op::MAX_NUM_OPS): Bump to 4.
>  (gimple_match_op::gimple_match_op): Add an overload for 4
operands.
>  (gimple_match_op::set_op): Likewise.
>  (gimple_resimplify4): Declare.
>  * genmatch.c (commutative_op): Handle CFN_COND_* functions.

^^^  you don't seem to use that and I don't see how those are commutative
in operands 1 and 2 without inverting operand 0.  So w/o adjusting the
parsing part I think that people can write (cond_foo:c ...) and likely
be surprised that it isn't rejected.  It is of course required to make :C
work.

The patch is ok if you drop this hunk for now.  You can re-introduce it
as followup if you make sure to make :c error on those IFNs.

Thanks,
Richard.

>  (get_operand_type, expr::gen_transform): Likewise.
>  (decision_tree::gen): Generate a simplification routine for 4
operands.
>  * gimple-match-head.c (gimple_simplify): Add an overload for
>  4 operands.  In the top-level function, handle up to 4 call
>  arguments and call gimple_resimplify4.
>  (gimple_resimplify4): New function.
>  (build_call_internal): Pass a fourth operand.
>  (maybe_push_to_seq): Likewise.
>  * match.pd (UNCOND_BINARY, COND_BINARY): New operator lists.
>  Fold VEC_COND_EXPRs of an operation and a default value into
>  an IFN_COND_* function if possible.
>  * config/aarch64/iterators.md (UNSPEC_COND_MAX, UNSPEC_COND_MIN):
>  New unspecs.
>  (SVE_COND_FP_BINARY): Include them.
>  (optab, sve_fp_op): Handle them.
>  (SVE_INT_BINARY_REV): New code iterator.
>  (SVE_COND_FP_BINARY_REV): New int iterator.
>  (commutative): New int attribute.
>  * config/aarch64/aarch64-protos.h
(aarch64_sve_prepare_conditional_op):
>  Declare.
>  * config/aarch64/aarch64.c (aarch64_sve_prepare_conditional_op):
New
>  function.
>  * config/aarch64/aarch64-sve.md (cond_): Use it.
>  (*cond_): New patterns for reversed operands.

> gcc/testsuite/
>  * lib/target-supports.exp
>  (check_effective_target_vect_double_cond_arith): New proc.
>  * gcc.dg/vect/vect-cond-arith-1.c: New test.
>  * gcc.target/aarch64/sve/vcond_8.c: Likewise.
>  * gcc.target/aarch64/sve/vcond_8_run.c: Likewise.
>  * gcc.target/aarch64/sve/vcond_9.c: Likewise.
>  * gcc.target/aarch64/sve/vcond_9_run.c: Likewise.
>  * gcc.target/aarch64/sve/vcond_12.c: Likewise.
>  * gcc.target/aarch64/sve/vcond_12_run.c: Likewise.

> Index: gcc/doc/sourcebuild.texi
> ===
> --- gcc/doc/sourcebuild.texi2018-05-24 09:02:24.987538940 +0100
> +++ gcc/doc/sourcebuild.texi2018-05-24 09:54:37.508451387 +0100
> @@ -1425,6 +1425,10 @@ have different type from the value opera
>   @item vect_double
>   Target supports hardware vectors of @code{double}.

> +@item vect_double_cond_arith
> +Target supports conditional addition, subtraction, minimum and maximum
> +on vectors of @code{double}, via the @code{cond_} optabs.
> +
>   @item vect_element_align_preferred
>   The target's preferred vector alignment is the same as the element
>   alignment.
> Index: gcc/gimple-match.h
> ===
> --- gcc/gimple-match.h  2018-05-24 09:02:28.764328414 +0100
> +++ gcc/gimple-match.h  2018-05-24 09:54:37.509451356 +0100
> @@ -49,17 +49,19 @@ struct gimple_match_op
> gimple_match_op (code_helper, tree, tree);
> gimple_match_op 

Re: Add an "else" argument to IFN_COND_* functions

[Richard Biener]

On Thu, May 24, 2018 at 10:37 AM Richard Sandiford <
richard.sandif...@linaro.org> wrote:

> As suggested by Richard B, this patch changes the IFN_COND_*
> functions so that they take the else value of the ?: operation
> as a final argument, rather than always using argument 1.

> All current callers will still use the equivalent of argument 1,
> so this patch makes the SVE code assert that for now.  Later patches
> add the general case.

> This relies on the earlier "Try harder to preserve operand ties in
> maybe_legitimize_operands"
> https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01199.html

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

OK.

Thanks,
Richard.

> Thanks,
> Richard


> 2018-05-24  Richard Sandiford  

> gcc/
>  * doc/md.texi: Update the documentation of the cond_* optabs
>  to mention the new final operand.  Fix GET_MODE_NUNITS call.
>  Describe the scalar case too.
>  * internal-fn.def (IFN_EXTRACT_LAST): Change type to fold_left.
>  * internal-fn.c (expand_cond_unary_optab_fn): Expect 3 operands
>  instead of 2.
>  (expand_cond_binary_optab_fn): Expect 4 operands instead of 3.
>  (get_conditional_internal_fn): Update comment.
>  * tree-vect-loop.c (vectorizable_reduction): Pass the original
>  accumulator value as a final argument to conditional functions.
>  * config/aarch64/aarch64-sve.md (cond_): Turn into
>  a define_expand and add an "else" operand.  Assert for now that
>  the else operand is equal to operand 2.  Use SVE_INT_BINARY and
>  SVE_COND_FP_BINARY instead of SVE_COND_INT_OP and SVE_COND_FP_OP.
>  (*cond_): New patterns.
>  * config/aarch64/iterators.md (UNSPEC_COND_SMAX, UNSPEC_COND_UMAX)
>  (UNSPEC_COND_SMIN, UNSPEC_COND_UMIN, UNSPEC_COND_AND,
UNSPEC_COND_ORR)
>  (UNSPEC_COND_EOR): Delete.
>  (optab): Remove associated mappings.
>  (SVE_INT_BINARY): New code iterator.
>  (sve_int_op): Remove int attribute and add "minus" to the code
>  attribute.
>  (SVE_COND_INT_OP): Delete.
>  (SVE_COND_FP_OP): Rename to...
>  (SVE_COND_FP_BINARY): ...this.

> Index: gcc/doc/md.texi
> ===
> --- gcc/doc/md.texi 2018-05-24 09:31:46.687834412 +0100
> +++ gcc/doc/md.texi 2018-05-24 09:32:10.522816506 +0100
> @@ -6349,13 +6349,21 @@ operand 0, otherwise (operand 2 + operan
>   @itemx @samp{cond_smax@var{mode}}
>   @itemx @samp{cond_umin@var{mode}}
>   @itemx @samp{cond_umax@var{mode}}
> -Perform an elementwise operation on vector operands 2 and 3,
> -under the control of the vector mask in operand 1, and store the result
> -in operand 0.  This is equivalent to:
> +When operand 1 is true, perform an operation on operands 2 and 3 and
> +store the result in operand 0, otherwise store operand 4 in operand 0.
> +The operation works elementwise if the operands are vectors.
> +
> +The scalar case is equivalent to:
> +
> +@smallexample
> +op0 = op1 ? op2 @var{op} op3 : op4;
> +@end smallexample
> +
> +while the vector case is equivalent to:

>   @smallexample
> -for (i = 0; i < GET_MODE_NUNITS (@var{n}); i++)
> -  op0[i] = op1[i] ? op2[i] @var{op} op3[i] : op2[i];
> +for (i = 0; i < GET_MODE_NUNITS (@var{m}); i++)
> +  op0[i] = op1[i] ? op2[i] @var{op} op3[i] : op4[i];
>   @end smallexample

>   where, for example, @var{op} is @code{+} for @samp{cond_add@var{mode}}.
> @@ -6364,8 +6372,9 @@ When defined for floating-point modes, t
>   are not interpreted if @var{op1[i]} is false, just like they would not
>   be in a normal C @samp{?:} condition.

> -Operands 0, 2 and 3 all have mode @var{m}, while operand 1 has the mode
> -returned by @code{TARGET_VECTORIZE_GET_MASK_MODE}.
> +Operands 0, 2, 3 and 4 all have mode @var{m}.  Operand 1 is a scalar
> +integer if @var{m} is scalar, otherwise it has the mode returned by
> +@code{TARGET_VECTORIZE_GET_MASK_MODE}.

>   @cindex @code{neg@var{mode}cc} instruction pattern
>   @item @samp{neg@var{mode}cc}
> Index: gcc/internal-fn.def
> ===
> --- gcc/internal-fn.def 2018-05-24 09:31:46.687834412 +0100
> +++ gcc/internal-fn.def 2018-05-24 09:32:10.522816506 +0100
> @@ -173,7 +173,7 @@ DEF_INTERNAL_OPTAB_FN (REDUC_XOR, ECF_CO

>   /* Extract the last active element from a vector.  */
>   DEF_INTERNAL_OPTAB_FN (EXTRACT_LAST, ECF_CONST | ECF_NOTHROW,
> -  extract_last, cond_unary)
> +  extract_last, fold_left)

>   /* Same, but return the first argument if no elements are active.  */
>   DEF_INTERNAL_OPTAB_FN (FOLD_EXTRACT_LAST, ECF_CONST | ECF_NOTHROW,
> Index: gcc/internal-fn.c
> ===
> --- gcc/internal-fn.c   2018-05-24 

Re: Prefer open-coding vector integer division

[Richard Biener]

On Thu, May 24, 2018 at 10:31 AM Jakub Jelinek  wrote:

> On Thu, May 24, 2018 at 09:21:35AM +0100, Richard Sandiford wrote:
> > vect_recog_divmod_pattern currently bails out if the target has
> > native support for integer division, but I think in practice
> > it's always going to be better to open-code it anyway, just as
> > we usually open-code scalar divisions by constants.
> >
> > I think the only currently affected target is MIPS MSA, where for:

> Isn't powerpcspe affected too?  It has a divv2si3 pattern.

> > --- gcc/tree-vect-patterns.c  2018-05-16 12:48:59.115202362 +0100
> > +++ gcc/tree-vect-patterns.c  2018-05-24 09:18:10.445466941 +0100
> > @@ -2639,7 +2639,6 @@ vect_recog_divmod_pattern (vec
> >enum tree_code rhs_code;
> >stmt_vec_info stmt_vinfo = vinfo_for_stmt (last_stmt);
> >vec_info *vinfo = stmt_vinfo->vinfo;
> > -  optab optab;
> >tree q;
> >int dummy_int, prec;
> >stmt_vec_info def_stmt_vinfo;
> > @@ -2674,17 +2673,6 @@ vect_recog_divmod_pattern (vec
> >if (vectype == NULL_TREE)
> >  return NULL;
> >
> > -  /* If the target can handle vectorized division or modulo natively,
> > - don't attempt to optimize this.  */
> > -  optab = optab_for_tree_code (rhs_code, vectype, optab_default);
> > -  if (optab != unknown_optab)
> > -{
> > -  machine_mode vec_mode = TYPE_MODE (vectype);
> > -  int icode = (int) optab_handler (optab, vec_mode);
> > -  if (icode != CODE_FOR_nothing)
> > - return NULL;
> > -}
> > -

> Shouldn't we instead keep it, but only do it if
> optimize_bb_for_size_p (gimple_bb (last_stmt)) ?
> I mean, a hw division is very likely shorter than what we replace it
with...

Good idea.  While loops are checked for optimize_loop_nest_for_speed if
not forced vect BB vectorization has no such predicate.

Richard.

>  Jakub

Re: Use canonicalize_math_after_vectorization_p for FMA folds

[Richard Biener]

On Thu, May 24, 2018 at 10:07 AM Richard Sandiford <
richard.sandif...@linaro.org> wrote:

> The folds in r260348 kicked in before vectorisation, which hurts
> for two reasons:

> (1) the current suboptimal handling of nothrow meant that we could
>  drop the flag early and so prevent if-conversion

> (2) some architectures provide more scalar forms than vector forms
>  (true for Advanced SIMD)

> (1) is a bug in itself that needs to be fixed eventually, but delaying
> the folds is still needed for (2).

> Tested on aarch64-linux-gnu (with and without SVE), aarch64_be-elf
> and x86_64-linux-gnu.  OK to install?

OK.

Richard.

> (Patch is mostly just reindent.)

> Richard


> 2018-05-24  Richard Sandiford  

> gcc/
>  * match.pd: Delay FMA folds until after vectorization.

> gcc/testsuite/
>  * gcc.dg/vect/vect-fma-1.c: New test.

> Index: gcc/match.pd
> ===
> --- gcc/match.pd2018-05-18 09:26:37.735714314 +0100
> +++ gcc/match.pd2018-05-24 09:05:10.432158893 +0100
> @@ -4703,59 +4703,60 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
>wi::to_wide (@ipos) + isize))
>   (BIT_FIELD_REF @0 @rsize @rpos)

> -(for fmas (FMA)
> +(if (canonicalize_math_after_vectorization_p ())
> + (for fmas (FMA)
> +  (simplify
> +   (fmas:c (negate @0) @1 @2)
> +   (IFN_FNMA @0 @1 @2))
> +  (simplify
> +   (fmas @0 @1 (negate @2))
> +   (IFN_FMS @0 @1 @2))
> +  (simplify
> +   (fmas:c (negate @0) @1 (negate @2))
> +   (IFN_FNMS @0 @1 @2))
> +  (simplify
> +   (negate (fmas@3 @0 @1 @2))
> +   (if (single_use (@3))
> +(IFN_FNMS @0 @1 @2
> +
> + (simplify
> +  (IFN_FMS:c (negate @0) @1 @2)
> +  (IFN_FNMS @0 @1 @2))
>(simplify
> -  (fmas:c (negate @0) @1 @2)
> +  (IFN_FMS @0 @1 (negate @2))
> +  (IFN_FMA @0 @1 @2))
> + (simplify
> +  (IFN_FMS:c (negate @0) @1 (negate @2))
> (IFN_FNMA @0 @1 @2))
>(simplify
> -  (fmas @0 @1 (negate @2))
> -  (IFN_FMS @0 @1 @2))
> +  (negate (IFN_FMS@3 @0 @1 @2))
> +   (if (single_use (@3))
> +(IFN_FNMA @0 @1 @2)))
> +
> + (simplify
> +  (IFN_FNMA:c (negate @0) @1 @2)
> +  (IFN_FMA @0 @1 @2))
>(simplify
> -  (fmas:c (negate @0) @1 (negate @2))
> +  (IFN_FNMA @0 @1 (negate @2))
> (IFN_FNMS @0 @1 @2))
>(simplify
> -  (negate (fmas@3 @0 @1 @2))
> +  (IFN_FNMA:c (negate @0) @1 (negate @2))
> +  (IFN_FMS @0 @1 @2))
> + (simplify
> +  (negate (IFN_FNMA@3 @0 @1 @2))
> (if (single_use (@3))
> -   (IFN_FNMS @0 @1 @2
> +   (IFN_FMS @0 @1 @2)))

> -(simplify
> - (IFN_FMS:c (negate @0) @1 @2)
> - (IFN_FNMS @0 @1 @2))
> -(simplify
> - (IFN_FMS @0 @1 (negate @2))
> - (IFN_FMA @0 @1 @2))
> -(simplify
> - (IFN_FMS:c (negate @0) @1 (negate @2))
> - (IFN_FNMA @0 @1 @2))
> -(simplify
> - (negate (IFN_FMS@3 @0 @1 @2))
> + (simplify
> +  (IFN_FNMS:c (negate @0) @1 @2)
> +  (IFN_FMS @0 @1 @2))
> + (simplify
> +  (IFN_FNMS @0 @1 (negate @2))
> +  (IFN_FNMA @0 @1 @2))
> + (simplify
> +  (IFN_FNMS:c (negate @0) @1 (negate @2))
> +  (IFN_FMA @0 @1 @2))
> + (simplify
> +  (negate (IFN_FNMS@3 @0 @1 @2))
> (if (single_use (@3))
> -   (IFN_FNMA @0 @1 @2)))
> -
> -(simplify
> - (IFN_FNMA:c (negate @0) @1 @2)
> - (IFN_FMA @0 @1 @2))
> -(simplify
> - (IFN_FNMA @0 @1 (negate @2))
> - (IFN_FNMS @0 @1 @2))
> -(simplify
> - (IFN_FNMA:c (negate @0) @1 (negate @2))
> - (IFN_FMS @0 @1 @2))
> -(simplify
> - (negate (IFN_FNMA@3 @0 @1 @2))
> - (if (single_use (@3))
> -  (IFN_FMS @0 @1 @2)))
> -
> -(simplify
> - (IFN_FNMS:c (negate @0) @1 @2)
> - (IFN_FMS @0 @1 @2))
> -(simplify
> - (IFN_FNMS @0 @1 (negate @2))
> - (IFN_FNMA @0 @1 @2))
> -(simplify
> - (IFN_FNMS:c (negate @0) @1 (negate @2))
> - (IFN_FMA @0 @1 @2))
> -(simplify
> - (negate (IFN_FNMS@3 @0 @1 @2))
> - (if (single_use (@3))
> -  (IFN_FMA @0 @1 @2)))
> +   (IFN_FMA @0 @1 @2
> Index: gcc/testsuite/gcc.dg/vect/vect-fma-1.c
> ===
> --- /dev/null   2018-04-20 16:19:46.369131350 +0100
> +++ gcc/testsuite/gcc.dg/vect/vect-fma-1.c  2018-05-24
09:05:10.432158893 +0100
> @@ -0,0 +1,58 @@
> +/* { dg-require-effective-target scalar_all_fma } */
> +
> +#include "tree-vect.h"
> +
> +#define N (VECTOR_BITS * 11 / 64 + 3)
> +
> +#define DEF(INV)   \
> +  void __attribute__ ((noipa)) \
> +  f_##INV (double *restrict a, double *restrict b, \
> +  double *restrict c, double *restrict d)  \
> +  {\
> +for (int i = 0; i < N; ++i)\
> +  {\
> +   double mb = (INV & 1 ? -b[i] : b[i]);   \
> +   double mc = c[i];   \
> +   double md = (INV & 2 ? -d[i] : d[i]);   \
> +   double fma = __builtin_fma (mb, mc, md);\
> +   a[i] = (INV & 4 ? -fma : 

Re: [PATCH][arm][2/2] Remove support for -march=armv3 and older

[Richard Earnshaw (lists)]

On 23/05/18 16:26, Kyrill Tkachov wrote:
> 
> On 21/05/18 12:29, Kyrill Tkachov wrote:
>>
>> On 18/05/18 11:33, Richard Earnshaw (lists) wrote:
>>> On 17/05/18 11:26, Kyrill Tkachov wrote:
 Hi all,

 We deprecated architecture versions earlier than Armv4T in GCC 6 [1].
 This patch removes support for architectures lower than Armv4.
 That is the -march values armv2, armv2a, armv3, armv3m are removed
 with this patch.  I did not remove armv4 because it's a bit more
 involved code-wise and there has been some pushback on the implications
 for -mcpu=strongarm support.

 Removing armv3m and earlier though is pretty straightforward.
 This allows us to get rid of the armv3m and mode32 feature bits
 in arm-cpus.in as they can be assumed to be universally available.

 Consequently the mcpu values arm2, arm250, arm3, arm6, arm60, arm600,
 arm610, arm620, arm7, arm7d, arm7di, arm70, arm700, arm700i, arm710,
 arm720, arm710c, arm7100, arm7500, arm7500fe, arm7m, arm7dm, arm7dm are
 now also removed.

 Bootstrapped and tested on arm-none-linux-gnueabihf and on
 arm-none-eabi
 with an aprofile multilib configuration (which builds quite a lot of
 library
 configurations).

 Ramana, Richard, I'd appreciate an ok from either of you that you're
 happy for this to go ahead.
>>> OK.
>>
>> Thanks, I've committed the two patches.
>>
>>>
>>> It seems slightly strange that we remove the mode32 feature, but not the
>>> mode26 feature, though I can see how it occurs as a consequence of this
>>> cleanup.
>>>
>>> However, we're no longer interested in supporting ARMv4 running in
>>> mode26 (and I think in reality mode26 support was dropped several
>>> releases back), so we should just drop that feature bit as well.
>>> Perhaps you could do a follow-up to remove that too?
>>
>> Yeah, that can be cleaned up separately.
>>
> 
> And here is the patch doing that.
> Committed to trunk after a bootstrap and test on arm-none-linux-gnueabihf.

Thanks.  Another wart (the hunk in configure_build_target) cleaned up.

R.

> 
> Thanks,
> Kyrill
> 
> 2018-05-23  Kyrylo Tkachov  
> 
>     * config/arm/arm-cpus.in (mode26): Delete.
>     (armv4): Delete mode26 reference.
>     * config/arm/arm.c (arm_configure_build_target): Delete use of
>     isa_bit_mode26.
> 
>> Thanks,
>> Kyrill
>>
>>> Thanks,
>>>
>>> R.
>>>
 Thanks,
 Kyrill

 [1] https://gcc.gnu.org/gcc-6/changes.html#arm

 2018-05-17  Kyrylo Tkachov  

  * config/arm/arm-cpus.in (armv3m, mode32): Delete features.
  (ARMv4): Update.
  (ARMv2, ARMv3, ARMv3m): Delete fgroups.
  (ARMv6m): Update.
  (armv2, armv2a, armv3, armv3m): Delete architectures.
  (arm2, arm250, arm3, arm6, arm60, arm600, arm610, arm620,
  arm7, arm7d, arm7di, arm70, arm700, arm700i, arm710, arm720,
  arm710c, arm7100, arm7500, arm7500fe, arm7m, arm7dm, arm7dmi):
  Delete cpus.
  * config/arm/arm.md (maddsidi4): Remove check for arm_arch3m.
  (*mulsidi3adddi): Likewise.
  (mulsidi3): Likewise.
  (*mulsidi3_nov6): Likewise.
  (umulsidi3): Likewise.
  (umulsidi3_nov6): Likewise.
  (umaddsidi4): Likewise.
  (*umulsidi3adddi): Likewise.
  (smulsi3_highpart): Likewise.
  (*smulsi3_highpart_nov6): Likewise.
  (umulsi3_highpart): Likewise.
  (*umulsi3_highpart_nov6): Likewise.
  * config/arm/arm.h (arm_arch3m): Delete.
  * config/arm/arm.c (arm_arch3m): Delete.
  (arm_option_override_internal): Update armv3-related comment.
  (arm_configure_build_target): Delete use of isa_bit_mode32.
  (arm_option_reconfigure_globals): Delete set of arm_ach3m.
  (arm_rtx_costs_internal): Delete check of arm_arch3m.
  * config/arm/arm-fixed.md (mulsq3): Delete check for arm_arch3m.
  (mulsa3): Likewise.
  (mulusa3): Likewise.
  * config/arm/arm-protos.h (arm_arch3m): Delete.
  * config/arm/arm-tables.opt: Regenerate.
  * config/arm/arm-tune.md: Likewise.
  * config/arm/t-arm-elf (all_early_nofp): Delete mentions of
  deleted architectures.

 2018-05-17  Kyrylo Tkachov  

  * gcc.target/arm/pr62554.c: Delete.
  * gcc.target/arm/pr69610-1.c: Likewise.
  * gcc.target/arm/pr69610-2.c: Likewise.

 armv3.patch


 diff --git a/gcc/config/arm/arm-cpus.in b/gcc/config/arm/arm-cpus.in
 index
 0a318877f10394e2c045d2a03a8f0757557136cf..16a381c86b6a7947e424b29fe67812990519ada9
 100644
 --- a/gcc/config/arm/arm-cpus.in
 +++ b/gcc/config/arm/arm-cpus.in
 @@ -48,15 +48,9 @@
     # Features - general convention: all lower case.
   -# Extended multiply
 -define feature armv3m
 -
   # 26-bit 

Re: [PATCH] consider MIN_EXPR in get_size_range() (PR 85888)

[Richard Biener]

On Thu, May 24, 2018 at 12:50 AM Martin Sebor  wrote:

> The attached patch enhances the get_size_range() function to
> extract more accurate ranges out of MIN_EXPR and MAX_EXPR nodes
> with SSA_NAME operand(s).  This helps -Wstringop-overflow avoid
> false positives on some targets in cases like some of those
> reported in bug 85623 - strncmp() warns about attribute nonstring
> incorrectly in -Wstringop-overflow

> When first trying to expand calls to __builtin_strncmp, most back
> ends succeed even when the expansion results in a call to the library
> function.  The powerpc64 back-end, however, fails and and allows
> the generic expansion to take place.  There is a subtle difference
> between the two cases that shows up when examining the bound of
> the strncmp call expression (the third argument): in the original
> call expression (in expand_builtin_strncmp) the bound is or can be
> an SSA_NAME.  But when the early expansion fails,
> expand_builtin_strncmp transforms the original call expression into
> a new one, substituting MIN_EXPR (bound, CST) for the bound where
> CST is the constant result of strlen (STR), with STR being either
> the first or second strncmp argument.  When the bound is an SSA_NAME
> the subsequent attempt to determine its range from the MIN_EXPR fails.

Hmm, wouldn't sth extracted from the attached random patch I have lying
around be more useful in general?  That is, refactor the GENERIC
expression walk in determine_value_range_1 to sth that can be used
in the current get_range_info () interface?  Or if we don't want to change
that to accept non-SSA names add a corresponding get_expr_range_info ()
interface.

If you do that please cut out the dominator/loop condition handling and
refrain from the idea of looking at SSA def stmts.

I always wanted an excuse to actually push parts of the idea in this patch
to trunk.

Thanks,
Richard.

> Martin


fix-pr62630-3
Description: Binary data

Extend tree code folds to IFN_COND_*

[Richard Sandiford]

This patch adds match.pd support for applying normal folds to their
IFN_COND_* forms.  E.g. the rule:

  (plus @0 (negate @1)) -> (minus @0 @1)

also allows the fold:

  (IFN_COND_ADD @0 @1 (negate @2) @3) -> (IFN_COND_SUB @0 @1 @2 @3)

Actually doing this by direct matches in gimple-match.c would
probably lead to combinatorial explosion, so instead, the patch
makes gimple_match_op carry a condition under which the operation
happens ("cond"), and the value to use when the condition is false
("else_value").  Thus in the example above we'd do the following

(a) convert:

  cond:NULL_TREE (IFN_COND_ADD @0 @1 @4 @3) else_value:NULL_TREE

to:

  cond:@0 (plus @1 @4) else_value:@3

(b) apply gimple_resimplify to (plus @1 @4)

(c) reintroduce cond and else_value when constructing the result.

Nested operations inherit the condition of the outer operation
(so that we don't introduce extra faults) but have a null else_value.
If we try to build such an operation, the target gets to choose what
else_value it can handle efficiently: obvious choices include one of
the operands or a zero constant.  (The alternative would be to have some
representation for an undefined value, but that seems a bit invasive,
and isn't likely to be useful here.)

I've made the condition a mandatory part of the gimple_match_op
constructor so that it doesn't accidentally get dropped.

Tested on aarch64-linux-gnu (with and without SVE), aarch64_be-elf
and x86_64-linux-gnu.  OK to install?

Richard


2018-05-24  Richard Sandiford  

gcc/
* target.def (preferred_else_value): New target hook.
* doc/tm.texi.in (TARGET_PREFERRED_ELSE_VALUE): New hook.
* doc/tm.texi: Regenerate.
* targhooks.h (default_preferred_else_value): Declare.
* targhooks.c (default_preferred_else_value): New function.
* internal-fn.h (conditional_internal_fn_code): Declare.
* internal-fn.c (FOR_EACH_CODE_MAPPING): New macro.
(get_conditional_internal_fn): Use it.
(conditional_internal_fn_code): New function.
* gimple-match.h (gimple_match_cond): New struct.
(gimple_match_op): Add a cond member function.
(gimple_match_op::gimple_match_op): Update all forms to take a
gimple_match_cond.
* genmatch.c (expr::gen_transform): Use the same condition as res_op
for the suboperation, but don't specify a particular else_value.
* tree-ssa-sccvn.c (vn_nary_simplify, vn_reference_lookup_3)
(visit_nary_op, visit_reference_op_load): Pass
gimple_match_cond::UNCOND to the gimple_match_op constructor.
* gimple-match-head.c: Include tree-eh.h
(convert_conditional_op): New function.
(maybe_resimplify_conditional_op): Likewise.
(gimple_resimplify1): Call maybe_resimplify_conditional_op.
(gimple_resimplify2): Likewise.
(gimple_resimplify3): Likewise.
(gimple_resimplify4): Likewise.
(maybe_push_res_to_seq): Return null for conditional operations.
(try_conditional_simplification): New function.
(gimple_simplify): Call it.  Pass conditions to the gimple_match_op
constructor.
* match.pd: Fold VEC_COND_EXPRs of an IFN_COND_* call to a new
IFN_COND_* call.
* config/aarch64/aarch64.c (aarch64_preferred_else_value): New
function.
(TARGET_PREFERRED_ELSE_VALUE): Redefine.

gcc/testsuite/
* gcc.dg/vect/vect-cond-arith-2.c: New test.
* gcc.target/aarch64/sve/loop_add_6.c: Likewise.

Index: gcc/target.def
===
--- gcc/target.def  2018-05-01 19:30:30.159632586 +0100
+++ gcc/target.def  2018-05-24 10:33:30.871095132 +0100
@@ -2040,6 +2040,25 @@ HOOK_VECTOR_END (vectorize)
 #define HOOK_PREFIX "TARGET_"
 
 DEFHOOK
+(preferred_else_value,
+ "This hook returns the target's preferred final argument for a call\n\
+to conditional internal function @var{ifn} (really of type\n\
+@code{internal_fn}).  @var{type} specifies the return type of the\n\
+function and @var{ops} are the operands to the conditional operation,\n\
+of which there are @var{nops}.\n\
+\n\
+For example, if @var{ifn} is @code{IFN_COND_ADD}, the hook returns\n\
+a value of type @var{type} that should be used when @samp{@var{ops}[0]}\n\
+and @samp{@var{ops}[1]} are conditionally added together.\n\
+\n\
+This hook is only relevant if the target supports conditional patterns\n\
+like @code{cond_add@var{m}}.  The default implementation returns a zero\n\
+constant of type @var{type}.",
+ tree,
+ (unsigned ifn, tree type, unsigned nops, tree *ops),
+ default_preferred_else_value)
+
+DEFHOOK
 (record_offload_symbol,
  "Used when offloaded functions are seen in the compilation unit and no 
named\n\
 sections are available.  It is called once for each symbol that must be\n\
Index: gcc/doc/tm.texi.in
===
--- 

Add IFN_COND_{MUL,DIV,MOD,RDIV}

[Richard Sandiford]

This patch adds support for conditional multiplication and division.
It's mostly mechanical, but a few notes:

* The *_optab name and the .md names are the same as the unconditional
  forms, just with "cond_" added to the front.  This means we still
  have the awkward difference between sdiv and div, etc.

* It was easier to retain the difference between integer and FP
  division in the function names, given that they map to different
  tree codes (TRUNC_DIV_EXPR and RDIV_EXPR).

* SVE has no direct support for IFN_COND_MOD, but it seemed more
  consistent to add it anyway.

* Adding IFN_COND_MUL enables an extra fully-masked reduction
  in gcc.dg/vect/pr53773.c.

* In practice we don't actually use the integer division forms without
  if-conversion support (added by a later patch).

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

Richard


2018-05-24  Richard Sandiford  

gcc/
* doc/sourcebuild.texi (vect_double_cond_arith): Include
multiplication and division.
* doc/md.texi (cond_mul@var{m}, cond_div@var{m}, cond_mod@var{m})
(cond_udiv@var{m}, cond_umod@var{m}): Document.
* optabs.def (cond_smul_optab, cond_sdiv_optab, cond_smod_optab)
(cond_udiv_optab, cond_umod_optab): New optabs.
* internal-fn.def (IFN_COND_MUL, IFN_COND_DIV, IFN_COND_MOD)
(IFN_COND_RDIV): New internal functions.
* internal-fn.c (get_conditional_internal_fn): Handle TRUNC_DIV_EXPR,
TRUNC_MOD_EXPR and RDIV_EXPR.
* genmatch.c (commutative_op): Handle CFN_COND_MUL.
* match.pd (UNCOND_BINARY, COND_BINARY): Handle them.
* config/aarch64/iterators.md (UNSPEC_COND_MUL, UNSPEC_COND_DIV):
New unspecs.
(SVE_INT_BINARY): Include mult.
(SVE_COND_FP_BINARY): Include UNSPEC_MUL and UNSPEC_DIV.
(optab, sve_int_op): Handle mult.
(optab, sve_fp_op, commutative): Handle UNSPEC_COND_MUL and
UNSPEC_COND_DIV.
* config/aarch64/aarch64-sve.md (cond_): New pattern
for SVE_INT_BINARY_SD.

gcc/testsuite/
* lib/target-supports.exp
(check_effective_target_vect_double_cond_arith): Include
multiplication and division.
* gcc.dg/vect/pr53773.c: Do not expect a scalar tail when using
fully-masked loops with a fixed vector length.
* gcc.dg/vect/vect-cond-arith-1.c: Add multiplication and division
tests.
* gcc.target/aarch64/sve/vcond_8.c: Likewise.
* gcc.target/aarch64/sve/vcond_9.c: Likewise.
* gcc.target/aarch64/sve/vcond_12.c: Add multiplication tests.

Index: gcc/doc/sourcebuild.texi
===
--- gcc/doc/sourcebuild.texi2018-05-24 09:54:37.508451387 +0100
+++ gcc/doc/sourcebuild.texi2018-05-24 10:12:10.145352193 +0100
@@ -1426,8 +1426,9 @@ have different type from the value opera
 Target supports hardware vectors of @code{double}.
 
 @item vect_double_cond_arith
-Target supports conditional addition, subtraction, minimum and maximum
-on vectors of @code{double}, via the @code{cond_} optabs.
+Target supports conditional addition, subtraction, multiplication,
+division, minimum and maximum on vectors of @code{double}, via the
+@code{cond_} optabs.
 
 @item vect_element_align_preferred
 The target's preferred vector alignment is the same as the element
Index: gcc/doc/md.texi
===
--- gcc/doc/md.texi 2018-05-24 09:32:10.522816506 +0100
+++ gcc/doc/md.texi 2018-05-24 10:12:10.142352315 +0100
@@ -6333,6 +6333,11 @@ operand 0, otherwise (operand 2 + operan
 
 @cindex @code{cond_add@var{mode}} instruction pattern
 @cindex @code{cond_sub@var{mode}} instruction pattern
+@cindex @code{cond_mul@var{mode}} instruction pattern
+@cindex @code{cond_div@var{mode}} instruction pattern
+@cindex @code{cond_udiv@var{mode}} instruction pattern
+@cindex @code{cond_mod@var{mode}} instruction pattern
+@cindex @code{cond_umod@var{mode}} instruction pattern
 @cindex @code{cond_and@var{mode}} instruction pattern
 @cindex @code{cond_ior@var{mode}} instruction pattern
 @cindex @code{cond_xor@var{mode}} instruction pattern
@@ -6342,6 +6347,11 @@ operand 0, otherwise (operand 2 + operan
 @cindex @code{cond_umax@var{mode}} instruction pattern
 @item @samp{cond_add@var{mode}}
 @itemx @samp{cond_sub@var{mode}}
+@itemx @samp{cond_mul@var{mode}}
+@itemx @samp{cond_div@var{mode}}
+@itemx @samp{cond_udiv@var{mode}}
+@itemx @samp{cond_mod@var{mode}}
+@itemx @samp{cond_umod@var{mode}}
 @itemx @samp{cond_and@var{mode}}
 @itemx @samp{cond_ior@var{mode}}
 @itemx @samp{cond_xor@var{mode}}
Index: gcc/optabs.def
===
--- gcc/optabs.def  2018-05-16 12:48:59.194282896 +0100
+++ gcc/optabs.def  2018-05-24 10:12:10.146352152 +0100
@@ -222,6 +222,11 @@ OPTAB_D 

Fold VEC_COND_EXPRs to IFN_COND_* where possible

[Richard Sandiford]

This patch adds the folds:

  (vec_cond COND (foo A B) C) -> (IFN_COND_FOO COND A B C)
  (vec_cond COND C (foo A B)) -> (IFN_COND_FOO (!COND) A B C)

with the usual implicit restriction that the target must support
the produced IFN_COND_FOO.

The results of these folds don't have identical semantics, since
the reverse transform would be invalid if (FOO A[i] B[i]) faults when
COND[i] is false.  But this direction is OK since we're simply dropping
faults for operations whose results aren't needed.

The new gimple_resimplify4 doesn't try to do any constant folding
on the IFN_COND_*s.  This is because a later patch will handle it
by folding the associated unconditional operation.

Doing this in gimple is better than doing it in .md patterns,
since the second form (with the inverted condition) is much more
common than the first, and it's better to fold away the inversion
in gimple and optimise the result before entering expand.

Tested on aarch64-linux-gnu (with and without SVE), aarch64_be-elf
and x86_64-linux-gnu.  OK to install?

Richard


2018-05-24  Richard Sandiford  

gcc/
* doc/sourcebuild.texi (vect_double_cond_arith: Document.
* gimple-match.h (gimple_match_op::MAX_NUM_OPS): Bump to 4.
(gimple_match_op::gimple_match_op): Add an overload for 4 operands.
(gimple_match_op::set_op): Likewise.
(gimple_resimplify4): Declare.
* genmatch.c (commutative_op): Handle CFN_COND_* functions.
(get_operand_type, expr::gen_transform): Likewise.
(decision_tree::gen): Generate a simplification routine for 4 operands.
* gimple-match-head.c (gimple_simplify): Add an overload for
4 operands.  In the top-level function, handle up to 4 call
arguments and call gimple_resimplify4.
(gimple_resimplify4): New function.
(build_call_internal): Pass a fourth operand.
(maybe_push_to_seq): Likewise.
* match.pd (UNCOND_BINARY, COND_BINARY): New operator lists.
Fold VEC_COND_EXPRs of an operation and a default value into
an IFN_COND_* function if possible.
* config/aarch64/iterators.md (UNSPEC_COND_MAX, UNSPEC_COND_MIN):
New unspecs.
(SVE_COND_FP_BINARY): Include them.
(optab, sve_fp_op): Handle them.
(SVE_INT_BINARY_REV): New code iterator.
(SVE_COND_FP_BINARY_REV): New int iterator.
(commutative): New int attribute.
* config/aarch64/aarch64-protos.h (aarch64_sve_prepare_conditional_op):
Declare.
* config/aarch64/aarch64.c (aarch64_sve_prepare_conditional_op): New
function.
* config/aarch64/aarch64-sve.md (cond_): Use it.
(*cond_): New patterns for reversed operands.

gcc/testsuite/
* lib/target-supports.exp
(check_effective_target_vect_double_cond_arith): New proc.
* gcc.dg/vect/vect-cond-arith-1.c: New test.
* gcc.target/aarch64/sve/vcond_8.c: Likewise.
* gcc.target/aarch64/sve/vcond_8_run.c: Likewise.
* gcc.target/aarch64/sve/vcond_9.c: Likewise.
* gcc.target/aarch64/sve/vcond_9_run.c: Likewise.
* gcc.target/aarch64/sve/vcond_12.c: Likewise.
* gcc.target/aarch64/sve/vcond_12_run.c: Likewise.

Index: gcc/doc/sourcebuild.texi
===
--- gcc/doc/sourcebuild.texi2018-05-24 09:02:24.987538940 +0100
+++ gcc/doc/sourcebuild.texi2018-05-24 09:54:37.508451387 +0100
@@ -1425,6 +1425,10 @@ have different type from the value opera
 @item vect_double
 Target supports hardware vectors of @code{double}.
 
+@item vect_double_cond_arith
+Target supports conditional addition, subtraction, minimum and maximum
+on vectors of @code{double}, via the @code{cond_} optabs.
+
 @item vect_element_align_preferred
 The target's preferred vector alignment is the same as the element
 alignment.
Index: gcc/gimple-match.h
===
--- gcc/gimple-match.h  2018-05-24 09:02:28.764328414 +0100
+++ gcc/gimple-match.h  2018-05-24 09:54:37.509451356 +0100
@@ -49,17 +49,19 @@ struct gimple_match_op
   gimple_match_op (code_helper, tree, tree);
   gimple_match_op (code_helper, tree, tree, tree);
   gimple_match_op (code_helper, tree, tree, tree, tree);
+  gimple_match_op (code_helper, tree, tree, tree, tree, tree);
 
   void set_op (code_helper, tree, unsigned int);
   void set_op (code_helper, tree, tree);
   void set_op (code_helper, tree, tree, tree);
   void set_op (code_helper, tree, tree, tree, tree);
+  void set_op (code_helper, tree, tree, tree, tree, tree);
   void set_value (tree);
 
   tree op_or_null (unsigned int) const;
 
   /* The maximum value of NUM_OPS.  */
-  static const unsigned int MAX_NUM_OPS = 3;
+  static const unsigned int MAX_NUM_OPS = 4;
 
   /* The operation being performed.  */
   code_helper code;
@@ -113,6 +115,17 @@ gimple_match_op::gimple_match_op (code_h
   ops[2] = op2;
 }