Re: C++ PATCH for c++/88294 - ICE with non-constant noexcept-specifier

[Jason Merrill]

On Fri, Feb 22, 2019 at 1:17 PM Marek Polacek  wrote:
> On Thu, Feb 21, 2019 at 02:57:28PM -1000, Jason Merrill wrote:
> > On 2/21/19 1:34 PM, Marek Polacek wrote:
> > > On Thu, Feb 21, 2019 at 11:22:41AM -1000, Jason Merrill wrote:
> > > > On 2/21/19 10:56 AM, Marek Polacek wrote:
> > > > > On Wed, Feb 20, 2019 at 01:53:18PM -1000, Jason Merrill wrote:
> > > > > > On 2/20/19 10:31 AM, Marek Polacek wrote:
> > > > > > > Here we ICE when substituting a deferred noexcept-specifier, 
> > > > > > > because it
> > > > > > > contains 'this', a PARM_DECL, in an evaluated context.  This is 
> > > > > > > different
> > > > > > > from "noexcept(noexcept(this))" where the noexcept operator's 
> > > > > > > operand is
> > > > > > > an unevaluated operand.  We crash within tsubst_copy's PARM_DECL 
> > > > > > > handling
> > > > > > > of a 'this' PARM_DECL:
> > > > > > > 15488   gcc_assert (cp_unevaluated_operand != 0)
> > > > > > > It'd be wrong to mess with cp_unevaluated_operand (or 
> > > > > > > current_class_*), and
> > > > > > > since we only check the expression's constness after substituting 
> > > > > > > in
> > > > > > > maybe_instantiate_noexcept, one fix would be the following.
> > > > > > >
> > > > > > > This is not just about 'this', as the 87844 test shows: here we 
> > > > > > > also have
> > > > > > > a parameter whose value we're trying to determine -- it's a 
> > > > > > > template arg
> > > > > > > of a late-specified return type.  Returning the original value in 
> > > > > > > tsubst_copy
> > > > > > > and leaving the later code to complain seems to work here as 
> > > > > > > well.  Just
> > > > > > > removing the assert should work as well.
> > > > > >
> > > > > > I'm reluctant to mess with this assert, as it catches a lot of 
> > > > > > lambda bugs.
> > > > >
> > > > > Makes sense -- I wasn't aware of that.
> > > > >
> > > > > > I think we want to register_parameter_specializations when 
> > > > > > instantiating
> > > > > > deferred noexcept, so that tsubst_copy can find the right decls.
> > > > >
> > > > > Thanks for the suggestion -- that works with one catch: we need to 
> > > > > replace the
> > > > > fake 'this' in the noexcept- specifier with a real 'this' (the 
> > > > > template one),
> > > > > one that has DECL_CONTEXT set.  The fake one comes from 
> > > > > inject_this_parameter,
> > > > > when we were parsing the noexcept-specifier.  The real one was set in 
> > > > > grokfndecl.
> > > >
> > > > If you set current_class_ptr appropriately tsubst_copy will use it, so 
> > > > you
> > > > shouldn't need to do a walk_tree.
> > >
> > > Unfortunately that broke a lot of libstdc++ tests.  I can poke at it more 
> > > if
> > > you feel stronly about it.
> >
> > Please do poke a bit more, that surprises me.
>
> Apparently *someone* needs to learn how to properly restore c_c_{ptr,ref}...
>
> noexcept35.C is a new test reduced from something from libstdc++.  Since it
> exercises codepaths that nothing in dg.exp does, I think it's worth adding.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2019-02-22  Marek Polacek  
>
> PR c++/88294 - ICE with non-constant noexcept-specifier.
> * pt.c (maybe_instantiate_noexcept): Set up the list of local
> specializations.  Set current_class_{ptr,ref}.

OK, thanks.

Jason

[PATCH, libgfortran] PR83387 Defined output does not work for a derived type that has no components

[Jerry DeLisle]

This patch is simple and obvious.

Regression tested on x86_64-pc-linux-gnu.

Test case attached. (Changelog for test case will be included)

I will commit tomorrow.

Regards,

Jerry

2019-02-23  Jerry DeLisle 

PR fortran/84387
* trans-io.c (transfer_expr): Do not return if there are no
components to the derived type or class.


diff --git a/gcc/fortran/trans-io.c b/gcc/fortran/trans-io.c
index 9a13af4a630..9e7071dc121 100644
--- a/gcc/fortran/trans-io.c
+++ b/gcc/fortran/trans-io.c
@@ -2407,8 +2407,6 @@ transfer_expr (gfc_se * se, gfc_typespec * ts, tree 
addr_expr,

 case_bt_struct:
 case BT_CLASS:
-  if (ts->u.derived->components == NULL)
-   return;
   if (gfc_bt_struct (ts->type) || ts->type == BT_CLASS)
{
  gfc_symbol *derived;
! { dg-do run }
! PR84387 Defined output does not work for a derived type that
! has no components 
module m
   type :: t
  private
  !integer :: m_i = 0  !<-- ***
   contains
  private
  procedure, pass(this) :: write_t
  generic, public :: write(formatted) => write_t
   end type
contains
   subroutine write_t(this, lun, iotype, vlist, istat, imsg)
  ! argument definitions
  class(t), intent(in):: this
  integer, intent(in) :: lun
  character(len=*), intent(in):: iotype
  integer, intent(in) :: vlist(:)
  integer, intent(out):: istat
  character(len=*), intent(inout) :: imsg
  write(lun, fmt=*, iostat=istat, iomsg=imsg) "Hello World!"
  return
   end subroutine write_t

end module

program p
   use m, only : t
   type(t) :: foo
   print "(dt)", foo ! { dg-output " Hello World!" }
end program

Re: [PATCH] PR libstdc++/89446 fix null pointer dereference in char_traits

[Jonathan Wakely]

On 23/02/19 01:26 +, Jonathan Wakely wrote:

On 23/02/19 02:06 +0100, Jakub Jelinek wrote:

On Sat, Feb 23, 2019 at 01:02:20AM +, Jonathan Wakely wrote:

PR libstdc++/89446
* include/bits/char_traits.h (__constant_char_array): Check index is
in range before dereferencing.
* testsuite/21_strings/basic_string_view/operators/char/89446.cc:
New test.

Tested x86_64-linux, committed to gcc-8-branch and gcc-7-branch.


And not trunk?  The bug is still there, even when it should be usually
ifdefed out because __builtin_is_constexpr_evaluated() should be supported.


Yes, that's a bigger patch (with some cleanup) which is coming
shortly.


Here's the patch for trunk. When the size is zero we can just return,
we don't need to do the __builtin_constant_p checks.

Tested powerpc64le-linux, committed to trunk.


commit c1f64344793df8b29ccb27d06572ba8d5b51957b
Author: Jonathan Wakely 
Date:   Sat Feb 23 01:33:02 2019 +

PR libstdc++/89446 fix null pointer dereference in char_traits

PR libstdc++/89446
* include/bits/char_traits.h (__constant_char_array): Check index is
in range before dereferencing.
(char_traits::compare, char_traits::find)
(char_traits::compare, char_traits::find): Return
immediately if n is zero.
(char_traits::compare, char_traits::find): Likewise.
Remove workarounds for PR 67026.
* testsuite/21_strings/basic_string_view/operators/char/89446.cc:
New test.
* testsuite/21_strings/basic_string_view/operators/wchar_t/89446.cc:
New test.

diff --git a/libstdc++-v3/include/bits/char_traits.h b/libstdc++-v3/include/bits/char_traits.h
index 21099c36c3b..fd9a3c73930 100644
--- a/libstdc++-v3/include/bits/char_traits.h
+++ b/libstdc++-v3/include/bits/char_traits.h
@@ -260,7 +260,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   return __builtin_is_constant_evaluated();
 #else
   size_t __i = 0;
-  while (__builtin_constant_p(__a[__i]) && __i < __n)
+  while (__i < __n && __builtin_constant_p(__a[__i]))
 	__i++;
   return __i == __n;
 #endif
@@ -314,14 +314,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   static _GLIBCXX17_CONSTEXPR int
   compare(const char_type* __s1, const char_type* __s2, size_t __n)
   {
+	if (__n == 0)
+	  return 0;
 #if __cplusplus >= 201703L
 	if (__builtin_constant_p(__n)
 	&& __constant_char_array_p(__s1, __n)
 	&& __constant_char_array_p(__s2, __n))
 	  return __gnu_cxx::char_traits::compare(__s1, __s2, __n);
 #endif
-	if (__n == 0)
-	  return 0;
 	return __builtin_memcmp(__s1, __s2, __n);
   }
 
@@ -338,14 +338,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   static _GLIBCXX17_CONSTEXPR const char_type*
   find(const char_type* __s, size_t __n, const char_type& __a)
   {
+	if (__n == 0)
+	  return 0;
 #if __cplusplus >= 201703L
 	if (__builtin_constant_p(__n)
 	&& __builtin_constant_p(__a)
 	&& __constant_char_array_p(__s, __n))
 	  return __gnu_cxx::char_traits::find(__s, __n, __a);
 #endif
-	if (__n == 0)
-	  return 0;
 	return static_cast(__builtin_memchr(__s, __a, __n));
   }
 
@@ -423,16 +423,15 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   static _GLIBCXX17_CONSTEXPR int
   compare(const char_type* __s1, const char_type* __s2, size_t __n)
   {
+	if (__n == 0)
+	  return 0;
 #if __cplusplus >= 201703L
 	if (__builtin_constant_p(__n)
 	&& __constant_char_array_p(__s1, __n)
 	&& __constant_char_array_p(__s2, __n))
 	  return __gnu_cxx::char_traits::compare(__s1, __s2, __n);
 #endif
-	if (__n == 0)
-	  return 0;
-	else
-	  return wmemcmp(__s1, __s2, __n);
+	return wmemcmp(__s1, __s2, __n);
   }
 
   static _GLIBCXX17_CONSTEXPR size_t
@@ -441,24 +440,22 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 #if __cplusplus >= 201703L
 	if (__constant_string_p(__s))
 	  return __gnu_cxx::char_traits::length(__s);
-	else
 #endif
-	  return wcslen(__s);
+	return wcslen(__s);
   }
 
   static _GLIBCXX17_CONSTEXPR const char_type*
   find(const char_type* __s, size_t __n, const char_type& __a)
   {
+	if (__n == 0)
+	  return 0;
 #if __cplusplus >= 201703L
 	if (__builtin_constant_p(__n)
 	&& __builtin_constant_p(__a)
 	&& __constant_char_array_p(__s, __n))
 	  return __gnu_cxx::char_traits::find(__s, __n, __a);
 #endif
-	if (__n == 0)
-	  return 0;
-	else
-	  return wmemchr(__s, __a, __n);
+	return wmemchr(__s, __a, __n);
   }
 
   static char_type*
@@ -532,14 +529,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   static _GLIBCXX17_CONSTEXPR int
   compare(const char_type* __s1, const char_type* __s2, size_t __n)
   {
+	if (__n == 0)
+	  return 0;
 #if __cplusplus > 201402
 	if (__builtin_constant_p(__n)
 	&& __constant_char_array_p(__s1, __n)
 	&& __constant_char_array_p(__s2, __n))
 	  return __gnu_cxx::char_traits::compare(__s1, __s2, __n);
 #endif
-	if (__n == 0)
-	  return 0;
 	return 

Re: PING^2: [PATCH] i386; Add -mmanual-endbr and cf_check function attribute

[H.J. Lu]

On Fri, Feb 22, 2019 at 11:18 AM H.J. Lu  wrote:
>
> On Fri, Dec 14, 2018 at 1:28 PM Jeff Law  wrote:
> >
> > On 12/11/18 9:03 AM, H.J. Lu wrote:
> > > On Mon, Dec 3, 2018 at 5:45 AM H.J. Lu  wrote:
> > >> On Mon, Jun 18, 2018 at 2:20 AM Richard Biener
> > >>  wrote:
> > >>> On Fri, Jun 15, 2018 at 2:59 PM H.J. Lu  wrote:
> >  Currently GCC inserts ENDBR instruction at entries of all non-static
> >  functions, unless LTO compilation is used.  Marking all functions,
> >  which are not called indirectly with nocf_check attribute, is not
> >  ideal since 99% of functions in a program may be of this kind.
> > 
> >  This patch adds -mmanual-endbr and cf_check function attribute.  They
> >  can be used together with -fcf-protection such that ENDBR instruction
> >  is inserted only at entries of functions with cf_check attribute.  It
> >  can limit number of ENDBR instructions to reduce program size.
> > 
> >  OK for trubk?
> > >>> I wonder if the linker could assist with ENDBR creation by
> > >>> redirecting all non-direct call relocs to a linker-generated
> > >>> stub with ENBR and a direct branch?
> > >>>
> > >> The goal of this patch is to add as few as ENDBR as possible
> > >> to reduce program size as much as possible.   Also there is no
> > >> relocation for indirect branch via register.
> > >>
> > > Hi Honza, Jakub, Jeff, Richard,
> > >
> > > Here is the rebased patch.  Can you guys take a look?
> > >
> > > Thanks.
> > >
> > >
> > > -- H.J.
> > >
> > >
> > > 0001-i386-Add-mmanual-endbr-and-cf_check-function-attribu.patch
> > >
> > > From 5934c6be6495b2d6f278646e25f9e684f6610e2b Mon Sep 17 00:00:00 2001
> > > From: "H.J. Lu" 
> > > Date: Thu, 14 Jun 2018 09:19:27 -0700
> > > Subject: [PATCH] i386; Add -mmanual-endbr and cf_check function attribute
> > >
> > > Currently GCC inserts ENDBR instruction at entries of all non-static
> > > functions, unless LTO compilation is used.  Marking all functions,
> > > which are not called indirectly with nocf_check attribute, is not
> > > ideal since 99% of functions in a program may be of this kind.
> > >
> > > This patch adds -mmanual-endbr and cf_check function attribute.  They
> > > can be used together with -fcf-protection such that ENDBR instruction
> > > is inserted only at entries of functions with cf_check attribute.  It
> > > can limit number of ENDBR instructions to reduce program size.
> > >
> > > gcc/
> > >
> > >   * config/i386/i386.c (rest_of_insert_endbranch): Insert ENDBR
> > >   at the function entry only when -mmanual-endbr isn't used or
> > >   there is cf_check function attribute.
> > >   (ix86_attribute_table): Add cf_check.
> > >   * config/i386/i386.opt: Add -mmanual-endbr.
> > >   * doc/extend.texi: Document cf_check attribute.
> > >   * doc/invoke.texi: Document -mmanual-endbr.
> > >
> > > gcc/testsuite/
> > >
> > >   * gcc.target/i386/cf_check-1.c: New test.
> > >   * gcc.target/i386/cf_check-2.c: Likewise.
> > >   * gcc.target/i386/cf_check-3.c: Likewise.
> > >   * gcc.target/i386/cf_check-4.c: Likewise.
> > >   * gcc.target/i386/cf_check-5.c: Likewise.
> > OK.
> >
> > Though I'm not sure how valuable this is in practice.  Yea, it saves
> > some space at the start of functions, but I find myself wondering more
> > and more if we should be pushing folks towards LTO for a variety of reasons.
> >
>
> Hi Jeff,
>
> Here is an update for this new option to move  -mmanual-endbr check to
> pass_insert_endbranch::gate.  I'd like to get it into GCC 9.
>
>

I withdraw this patch.  It is covered by

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


-- 
H.J.

[PATCH] make -Wformat-overflow consistent between data models

[Martin Sebor]

A few tests recently added for PR 88993 introduced an assumption
on the host compiler's data model that breaks between ILP32 and
LP64, causing failures test run failures
(see https://gcc.gnu.org/ml/gcc-patches/2019-02/msg01867.html).
Rather than avoiding the problem in the tests the attached patch
removes the data model assumption from the sprintf pass itself,
making the warnings emitted by the pass consistent regardless.

Bootstrapped and tested on x86_64-linux, and smoke-tested with
an i386-linux GCC.

Martin
gcc/ChangeLog:

	* gimple-ssa-sprintf.c (target_strtol): Rename...
	(target_strtohwi): ...to this.  Handle values up to HOST_WIDE_INT_MAX.
	(parse_directive): Adjust to name change.  Use HOST_WIDE_INT_MAX to
	check for range error.

Index: gcc/gimple-ssa-sprintf.c
===
--- gcc/gimple-ssa-sprintf.c	(revision 269136)
+++ gcc/gimple-ssa-sprintf.c	(working copy)
@@ -411,12 +411,12 @@ target_to_host (char *hostr, size_t hostsz, const
 }
 
 /* Convert the sequence of decimal digits in the execution character
-   starting at S to a long, just like strtol does.  Return the result
-   and set *END to one past the last converted character.  On range
-   error set ERANGE to the digit that caused it.  */
+   starting at *PS to a HOST_WIDE_INT, analogously to strtol.  Return
+   the result and set *PS to one past the last converted character.
+   On range error set ERANGE to the digit that caused it.  */
 
-static inline long
-target_strtol10 (const char **ps, const char **erange)
+static inline HOST_WIDE_INT
+target_strtowi (const char **ps, const char **erange)
 {
   unsigned HOST_WIDE_INT val = 0;
   for ( ; ; ++*ps)
@@ -427,9 +427,9 @@ target_to_host (char *hostr, size_t hostsz, const
 	  c -= '0';
 
 	  /* Check for overflow.  */
-	  if (val > (LONG_MAX - c) / 10LU)
+	  if (val > ((unsigned HOST_WIDE_INT) HOST_WIDE_INT_MAX - c) / 10LU)
 	{
-	  val = LONG_MAX;
+	  val = HOST_WIDE_INT_MAX;
 	  *erange = *ps;
 
 	  /* Skip the remaining digits.  */
@@ -3149,7 +3149,7 @@ parse_directive (sprintf_dom_walker::call_info 
 	 width and sort it out later after the next character has
 	 been seen.  */
   pwidth = pf;
-  width = target_strtol10 (, );
+  width = target_strtowi (, );
 }
   else if (target_to_host (*pf) == '*')
 {
@@ -3231,7 +3231,7 @@ parse_directive (sprintf_dom_walker::call_info 
 	{
 	  werange = 0;
 	  pwidth = pf;
-	  width = target_strtol10 (, );
+	  width = target_strtowi (, );
 	}
   else if (target_to_host (*pf) == '*')
 	{
@@ -3264,7 +3264,7 @@ parse_directive (sprintf_dom_walker::call_info 
   if (ISDIGIT (target_to_host (*pf)))
 	{
 	  pprec = pf;
-	  precision = target_strtol10 (, );
+	  precision = target_strtowi (, );
 	}
   else if (target_to_host (*pf) == '*')
 	{
@@ -3418,7 +3418,7 @@ parse_directive (sprintf_dom_walker::call_info 
 }
   else
 {
-  if (width == LONG_MAX && werange)
+  if (width == HOST_WIDE_INT_MAX && werange)
 	{
 	  size_t begin = dir.beg - info.fmtstr + (pwidth - pcnt);
 	  size_t caret = begin + (werange - pcnt);
@@ -3451,7 +3451,7 @@ parse_directive (sprintf_dom_walker::call_info 
 }
   else
 {
-  if (precision == LONG_MAX && perange)
+  if (precision == HOST_WIDE_INT_MAX && perange)
 	{
 	  size_t begin = dir.beg - info.fmtstr + (pprec - pcnt) - 1;
 	  size_t caret = dir.beg - info.fmtstr + (perange - pcnt) - 1;

[PATCH] improve performance of std::allocator::deallocate

[Pádraig Brady]

Attached is a simple patch which has been extensively tested within
Facebook,
and is enabled by default in our code base.

Passing the size to the allocator allows it to optimize deallocation,
and this was seen to significantly reduce the work required in jemalloc,
with about 40% reduction in CPU cycles in the free path.

Note jemalloc >= 5.1 is required to fix a bug with 0 sizes.

cheers,
Pádraig
From eb337e751bdeb5db7d41dd584c179c2cf19485a8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?= 
Date: Fri, 22 Feb 2019 17:21:57 -0800
Subject: [PATCH] std::allocator::deallocate support sized-deallocation

Pass the size to the allocator so that it may optimize deallocation.
This was seen to significantly reduce the work required in jemalloc,
with about 40% reduction in CPU cycles in the free path.
Note jemalloc >= 5.1 is required to fix a bug with 0 sizes.

* libstdc++-v3/include/ext/new_allocator.h (deallocate): Pass the size
to the deallocator with -fsized-deallocation.
---
 libstdc++-v3/include/ext/new_allocator.h | 17 +
 1 file changed, 17 insertions(+)

diff --git a/libstdc++-v3/include/ext/new_allocator.h b/libstdc++-v3/include/ext/new_allocator.h
index e245391..061d8ce 100644
--- a/libstdc++-v3/include/ext/new_allocator.h
+++ b/libstdc++-v3/include/ext/new_allocator.h
@@ -114,6 +114,22 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 	return static_cast<_Tp*>(::operator new(__n * sizeof(_Tp)));
   }
 
+#if __cpp_sized_deallocation
+  // __p is not permitted to be a null pointer.
+  void
+  deallocate(pointer __p, size_type __t)
+  {
+#if __cpp_aligned_new
+	if (alignof(_Tp) > __STDCPP_DEFAULT_NEW_ALIGNMENT__)
+	  {
+	::operator delete(__p, __t * sizeof(_Tp),
+			  std::align_val_t(alignof(_Tp)));
+	return;
+	  }
+#endif
+	::operator delete(__p, __t * sizeof(_Tp));
+  }
+#else
   // __p is not permitted to be a null pointer.
   void
   deallocate(pointer __p, size_type)
@@ -127,6 +143,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 #endif
 	::operator delete(__p);
   }
+#endif
 
   size_type
   max_size() const _GLIBCXX_USE_NOEXCEPT
-- 
2.5.5

Re: [PATCH] PR libstdc++/89446 fix null pointer dereference in char_traits

[Jonathan Wakely]

On 23/02/19 01:02 +, Jonathan Wakely wrote:

+// { dg-options "-std=gnu++17 -fexceptions -fnon-call-exceptions -O1" }
+// { dg-do run { target { powerpc*-*-linux* i?86-*-linux* x86_64-*-linux* } } }


I forgot to say that this is a conservative list of targets where
-fnon-call-exceptions is supported. Maybe it could run on other
targets, but this should be enough to ensure we don't get a regression
for this bug.

Re: [PATCH] PR libstdc++/89446 fix null pointer dereference in char_traits

[Jonathan Wakely]

On 23/02/19 02:06 +0100, Jakub Jelinek wrote:

On Sat, Feb 23, 2019 at 01:02:20AM +, Jonathan Wakely wrote:

PR libstdc++/89446
* include/bits/char_traits.h (__constant_char_array): Check index is
in range before dereferencing.
* testsuite/21_strings/basic_string_view/operators/char/89446.cc:
New test.

Tested x86_64-linux, committed to gcc-8-branch and gcc-7-branch.


And not trunk?  The bug is still there, even when it should be usually
ifdefed out because __builtin_is_constexpr_evaluated() should be supported.


Yes, that's a bigger patch (with some cleanup) which is coming
shortly.

[PATCH] libgomp: Add master thread to thread pool

[Kevin Buettner]

For debugging purposes, I need to be able to find the master thread
in the thread pool.

Without this patch, I see over 20 failures in the tests that I've
written for GDB.

I've also tested this in the gcc tree - no regressions.

libgomp/ChangeLog:

* team.c (gomp_team_start): Initialize pool->threads[0].
---
 libgomp/team.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/libgomp/team.c b/libgomp/team.c
index 2b2e9750da5..e331c9b72c0 100644
--- a/libgomp/team.c
+++ b/libgomp/team.c
@@ -477,11 +477,17 @@ gomp_team_start (void (*fn) (void *), void *data, 
unsigned nthreads,
 make no effort to expand gomp_threads_size geometrically.  */
   if (nthreads >= pool->threads_size)
{
+ bool need_init = (pool->threads == NULL);
  pool->threads_size = nthreads + 1;
  pool->threads
= gomp_realloc (pool->threads,
pool->threads_size
* sizeof (struct gomp_thread *));
+ if (need_init)
+   {
+ /* Add current (master) thread to threads[].  */
+ pool->threads[0] = thr;
+   }
}
 
   /* Release existing idle threads.  */

Re: [PATCH] PR libstdc++/89446 fix null pointer dereference in char_traits

[Jakub Jelinek]

On Sat, Feb 23, 2019 at 01:02:20AM +, Jonathan Wakely wrote:
>   PR libstdc++/89446
>   * include/bits/char_traits.h (__constant_char_array): Check index is
>   in range before dereferencing.
>   * testsuite/21_strings/basic_string_view/operators/char/89446.cc:
>   New test.
> 
> Tested x86_64-linux, committed to gcc-8-branch and gcc-7-branch.

And not trunk?  The bug is still there, even when it should be usually
ifdefed out because __builtin_is_constexpr_evaluated() should be supported.

> commit b639a9cac6e2532eb852b03df6ac40d34f1dd28c
> Author: Jonathan Wakely 
> Date:   Fri Feb 22 20:33:16 2019 +
> 
> PR libstdc++/89446 fix null pointer dereference in char_traits
> 
> PR libstdc++/89446
> * include/bits/char_traits.h (__constant_char_array): Check index 
> is
> in range before dereferencing.
> * testsuite/21_strings/basic_string_view/operators/char/89446.cc:
> New test.
> 
> diff --git a/libstdc++-v3/include/bits/char_traits.h 
> b/libstdc++-v3/include/bits/char_traits.h
> index 1945494d7e2..a2a883f3565 100644
> --- a/libstdc++-v3/include/bits/char_traits.h
> +++ b/libstdc++-v3/include/bits/char_traits.h
> @@ -248,7 +248,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>  __constant_char_array_p(const _CharT* __a, size_t __n)
>  {
>size_t __i = 0;
> -  while (__builtin_constant_p(__a[__i]) && __i < __n)
> +  while (__i < __n && __builtin_constant_p(__a[__i]))
>   __i++;
>return __i == __n;
>  }

Jakub

[PATCH] PR libstdc++/89446 fix null pointer dereference in char_traits

[Jonathan Wakely]

PR libstdc++/89446
* include/bits/char_traits.h (__constant_char_array): Check index is
in range before dereferencing.
* testsuite/21_strings/basic_string_view/operators/char/89446.cc:
New test.

Tested x86_64-linux, committed to gcc-8-branch and gcc-7-branch.


commit b639a9cac6e2532eb852b03df6ac40d34f1dd28c
Author: Jonathan Wakely 
Date:   Fri Feb 22 20:33:16 2019 +

PR libstdc++/89446 fix null pointer dereference in char_traits

PR libstdc++/89446
* include/bits/char_traits.h (__constant_char_array): Check index is
in range before dereferencing.
* testsuite/21_strings/basic_string_view/operators/char/89446.cc:
New test.

diff --git a/libstdc++-v3/include/bits/char_traits.h 
b/libstdc++-v3/include/bits/char_traits.h
index 1945494d7e2..a2a883f3565 100644
--- a/libstdc++-v3/include/bits/char_traits.h
+++ b/libstdc++-v3/include/bits/char_traits.h
@@ -248,7 +248,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 __constant_char_array_p(const _CharT* __a, size_t __n)
 {
   size_t __i = 0;
-  while (__builtin_constant_p(__a[__i]) && __i < __n)
+  while (__i < __n && __builtin_constant_p(__a[__i]))
__i++;
   return __i == __n;
 }
diff --git 
a/libstdc++-v3/testsuite/21_strings/basic_string_view/operators/char/89446.cc 
b/libstdc++-v3/testsuite/21_strings/basic_string_view/operators/char/89446.cc
new file mode 100644
index 000..768ba63ddfe
--- /dev/null
+++ 
b/libstdc++-v3/testsuite/21_strings/basic_string_view/operators/char/89446.cc
@@ -0,0 +1,28 @@
+// Copyright (C) 2019 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// { dg-options "-std=gnu++17 -fexceptions -fnon-call-exceptions -O1" }
+// { dg-do run { target { powerpc*-*-linux* i?86-*-linux* x86_64-*-linux* } } }
+// { dg-require-effective-target c++17 }
+
+#include 
+
+int main()
+{
+  std::string_view s1, s2;
+  return s1 != s2;
+}

Re: [PATCH] Minimum version of mpfr? (was Re: [PATCH] Fix up norm2 simplification (PR middle-end/88074)), take 2

[David Malcolm]

On Fri, 2019-02-22 at 14:19 +0100, Jakub Jelinek wrote:
> On Thu, Feb 21, 2019 at 04:50:27PM -0500, David Malcolm wrote:
> > gcc/fortran/ChangeLog:
> > PR middle-end/88074
> > * simplify.c (norm2_add_squared): Use mp_exp_t rather than
> > mpfr_exp_t.
> 
> I have discussed this with Richard on IRC earlier today, there is
> another
> issue that mpfr_regular_p is only 3.0 and later.  And he prefers that
> mp_exp_t over say
> #if MPFR_VERSION < MPFR_VERSION_NUM(3,0,0)
> typedef mp_exp_t mpfr_exp_t;
> #endif
> 
> So, here is the full patch I'll bootstrap/regtest soon:

FWIW, your patch fixed the bootstrap for me (and the regression tests
look sane:
  gfortran.sum : total: 49370 PASS: 49164 XFAIL: 126 UNSUPPORTED: 80
though sadly I've blown away my known-good baseline for comparison)

Dave

> 2019-02-22  David Malcolm  
>   Jakub Jelinek  
> 
>   PR middle-end/88074
>   * simplify.c (norm2_do_sqrt, gfc_simplify_norm2): Use
>   mpfr_number_p && !mpfr_zero_p instead of mpfr_regular_p.
>   (norm2_add_squared): Likewise.  Use mp_exp_t rather than
> mpfr_exp_t.
> 
> --- gcc/fortran/simplify.c.jj 2019-02-21 22:20:07.272388243
> +0100
> +++ gcc/fortran/simplify.c2019-02-22 11:07:36.093374586 +0100
> @@ -6061,8 +6061,8 @@ norm2_add_squared (gfc_expr *result, gfc
>  
>gfc_set_model_kind (result->ts.kind);
>int index = gfc_validate_kind (BT_REAL, result->ts.kind, false);
> -  mpfr_exp_t exp;
> -  if (mpfr_regular_p (result->value.real))
> +  mp_exp_t exp;
> +  if (mpfr_number_p (result->value.real) && !mpfr_zero_p (result-
> >value.real))
>  {
>exp = mpfr_get_exp (result->value.real);
>/* If result is getting close to overflowing, scale down.  */
> @@ -6076,7 +6076,7 @@ norm2_add_squared (gfc_expr *result, gfc
>  }
>  
>mpfr_init (tmp);
> -  if (mpfr_regular_p (e->value.real))
> +  if (mpfr_number_p (e->value.real) && !mpfr_zero_p (e->value.real))
>  {
>exp = mpfr_get_exp (e->value.real);
>/* If e**2 would overflow or close to overflowing, scale
> down.  */
> @@ -6117,7 +6117,9 @@ norm2_do_sqrt (gfc_expr *result, gfc_exp
>if (result != e)
>  mpfr_set (result->value.real, e->value.real, GFC_RND_MODE);
>mpfr_sqrt (result->value.real, result->value.real, GFC_RND_MODE);
> -  if (norm2_scale && mpfr_regular_p (result->value.real))
> +  if (norm2_scale
> +  && mpfr_number_p (result->value.real)
> +  && !mpfr_zero_p (result->value.real))
>  {
>mpfr_t tmp;
>mpfr_init (tmp);
> @@ -6156,7 +6158,9 @@ gfc_simplify_norm2 (gfc_expr *e, gfc_exp
>result = simplify_transformation_to_scalar (result, e, NULL,
> norm2_add_squared)
> ;
>mpfr_sqrt (result->value.real, result->value.real,
> GFC_RND_MODE);
> -  if (norm2_scale && mpfr_regular_p (result->value.real))
> +  if (norm2_scale
> +   && mpfr_number_p (result->value.real)
> +   && !mpfr_zero_p (result->value.real))
>   {
> mpfr_t tmp;
> mpfr_init (tmp);
> 
>   Jakub

[PATCH] Limit simplify_merge_mask optimization to cases where it can't trap (PR rtl-optimization/89445)

[Jakub Jelinek]

Hi!

The following testcase is miscompiled on x86_64.  The problem is that
simplify_merge_mask optimization throws away an inner VEC_MERGE when there
is an outer one with the same mask.  This can be done only if the change
doesn't have observable side-effects.  The code already uses side_effects_p
tests in various spots, that is needed, but as this testcase shows, not
sufficient.  Another issue is if there is a MEM load or store and not
MEM_NOTRAP_P, as the testcase shows.  And another problem can be vector
integer division by zero (I think only mips has such insn), or various
floating point operations if we care about floating point exceptions.

While fixing this, I've found that may_trap_p_1 doesn't really support
vector operations very much, vector floating point arithmetics can cause
exceptions like scalar floating point arithmetics; on the other side, the
4 VEC_* codes can't trap themselves, though their operands could.

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

2019-02-23  Jakub Jelinek  

PR rtl-optimization/89445
* simplify-rtx.c (simplify_ternary_operation): Don't use
simplify_merge_mask on operands that may trap.
* rtlanal.c (may_trap_p_1): Use FLOAT_MODE_P instead of
SCALAR_FLOAT_MODE_P checks.  For integral division by zero, if
second operand is CONST_VECTOR, check if any element could be zero.
Don't expect traps for VEC_{MERGE,SELECT,CONCAT,DUPLICATE} unless
their operands can trap.

* gcc.target/i386/avx512f-pr89445.c: New test.

--- gcc/simplify-rtx.c.jj   2019-01-10 11:43:14.390377646 +0100
+++ gcc/simplify-rtx.c  2019-02-22 19:01:08.977661098 +0100
@@ -6073,8 +6073,10 @@ simplify_ternary_operation (enum rtx_cod
 
   if (!side_effects_p (op2))
{
- rtx top0 = simplify_merge_mask (op0, op2, 0);
- rtx top1 = simplify_merge_mask (op1, op2, 1);
+ rtx top0
+   = may_trap_p (op0) ? NULL_RTX : simplify_merge_mask (op0, op2, 0);
+ rtx top1
+   = may_trap_p (op1) ? NULL_RTX : simplify_merge_mask (op1, op2, 1);
  if (top0 || top1)
return simplify_gen_ternary (code, mode, mode,
 top0 ? top0 : op0,
--- gcc/rtlanal.c.jj2019-02-20 10:00:49.279492877 +0100
+++ gcc/rtlanal.c   2019-02-22 19:03:02.478790634 +0100
@@ -2846,10 +2846,28 @@ may_trap_p_1 (const_rtx x, unsigned flag
 case UMOD:
   if (HONOR_SNANS (x))
return 1;
-  if (SCALAR_FLOAT_MODE_P (GET_MODE (x)))
+  if (FLOAT_MODE_P (GET_MODE (x)))
return flag_trapping_math;
   if (!CONSTANT_P (XEXP (x, 1)) || (XEXP (x, 1) == const0_rtx))
return 1;
+  if (GET_CODE (XEXP (x, 1)) == CONST_VECTOR)
+   {
+ /* For CONST_VECTOR, return 1 if any element is or might be zero.  */
+ unsigned int n_elts;
+ rtx op = XEXP (x, 1);
+ if (!GET_MODE_NUNITS (GET_MODE (op)).is_constant (_elts))
+   {
+ if (!CONST_VECTOR_DUPLICATE_P (op))
+   return 1;
+ for (unsigned i = 0; i < (unsigned int) XVECLEN (op, 0); i++)
+   if (CONST_VECTOR_ENCODED_ELT (op, i) == const0_rtx)
+ return 1;
+   }
+ else
+   for (unsigned i = 0; i < n_elts; i++)
+ if (CONST_VECTOR_ELT (op, i) == const0_rtx)
+   return 1;
+   }
   break;
 
 case EXPR_LIST:
@@ -2898,12 +2916,16 @@ may_trap_p_1 (const_rtx x, unsigned flag
 case NEG:
 case ABS:
 case SUBREG:
+case VEC_MERGE:
+case VEC_SELECT:
+case VEC_CONCAT:
+case VEC_DUPLICATE:
   /* These operations don't trap even with floating point.  */
   break;
 
 default:
   /* Any floating arithmetic may trap.  */
-  if (SCALAR_FLOAT_MODE_P (GET_MODE (x)) && flag_trapping_math)
+  if (FLOAT_MODE_P (GET_MODE (x)) && flag_trapping_math)
return 1;
 }
 
--- gcc/testsuite/gcc.target/i386/avx512f-pr89445.c.jj  2019-02-22 
19:19:17.709898754 +0100
+++ gcc/testsuite/gcc.target/i386/avx512f-pr89445.c 2019-02-22 
19:18:58.115216531 +0100
@@ -0,0 +1,54 @@
+/* PR rtl-optimization/89445 */
+/* { dg-do run { target { avx512f && mmap } } } */
+/* { dg-options "-O2 -mavx512f" } */
+
+#include "avx512f-check.h"
+
+#include 
+#ifndef MAP_ANONYMOUS
+#define MAP_ANONYMOUS MAP_ANON
+#endif
+#ifndef MAP_ANON
+#define MAP_ANON 0
+#endif
+#ifndef MAP_FAILED
+#define MAP_FAILED ((void *)-1)
+#endif
+
+__attribute__ ((noipa))
+void daxpy (unsigned long n, double a, double const *__restrict x,
+   double *__restrict y)
+{
+  const __m512d v_a = _mm512_broadcastsd_pd (_mm_set_sd (a));
+  const __mmask16 final = (1U << (n % 8u)) - 1;
+  __mmask16 mask = 65535u;
+  unsigned long i;
+  for (i = 0; i < n * sizeof (double); i += 8 * sizeof (double))
+{
+  if (i + 8 * sizeof (double) > n * sizeof (double))
+   mask = final;
+  __m512d v_x = _mm512_maskz_loadu_pd 

Re: PING [PATCH] avoid 4095/INT_MAX warning for fprintf (PR 88993)

[Martin Sebor]

On 2/22/19 4:33 PM, Jakub Jelinek wrote:

On Fri, Feb 22, 2019 at 04:17:14PM -0700, Martin Sebor wrote:

On 2/22/19 3:44 PM, Jakub Jelinek wrote:

On Tue, Feb 19, 2019 at 05:43:53PM -0700, Martin Sebor wrote:

PR tree-optimization/88993
PR tree-optimization/88835
* gcc.dg/tree-ssa/builtin-fprintf-warn-2.c: New test.
* gcc.dg/tree-ssa/builtin-printf-warn-2.c: New test.
* gcc.dg/tree-ssa/builtin-snprintf-warn-3.c: Adjust.
* gcc.dg/tree-ssa/builtin-sprintf-warn-18.c: Same.


Can you please, when testing a patch like this where you should expect
tbe wordsize will play an important role to test it with
make check-gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} 
tree-ssa.exp=builtin-*printf-warn*'
?
There are many failures on ilp32 targets.

+FAIL: gcc.dg/tree-ssa/builtin-fprintf-warn-2.c  (test for warnings, line 114)


I don't see these failures with -m32.  They must be specific to 32-bit
GCC itself.


My bootstrap was indeed i686-linux, not x86_64-linux compiler with -m32.
E.g. target_strtol10 for some strange reason returns long rather than
HOST_WIDE_INT and checks LONG_MAX rather than HOST_WIDE_INT_MAX, making
it host dependent rather than target dependent.  Either it should work with
HWI and its max always, or should cap at precision of some target type
(e.g. glibc I think uses int type for both width and precision, parsing
through read_int that is similar to target_strtol10, except that it returns
(target) int and if over INT_MAX uses -1).


target_strtol10 returns long because it's wide enough for what it's
used for (width and precision, both int) for all supported hosts
and targets.  What it's not good enough for (and what I forgot about)
is capturing the value of width and precision in excess of host
LONG_MAX in diagnostics.  For instance

  printf ("%2147483650i", 1);

in LP64 results in

   warning: ‘%2147483650i’ directive output of 2147483650 bytes exceeds 
‘INT_MAX’


but in ILP32 in:

  warning: ‘%2147483650i’ directive width out of range

But changing the function to work with HOST_WIDE_INT makes
the warnings consistent between the data models and will help
avoid these gotchas in the future so I've made the change.  I'll
post the patch once it passes bootstrap/regtest.

Martin

[PATCH] Improve arm and aarch64 casesi (PR target/70341)

[Jakub Jelinek]

Hi!

The testcase in the PR doesn't hoist any memory loads from the large switch
before the switch on aarch64 and arm (unlike e.g. x86), because the
arm/aarch64 casesi patterns don't properly annotate the memory load from the
jump table.  It is created by gen_* and in RTL directly one can't specify
the needed flags (MEM_READONLY_P and MEM_NOTRAP_P).

Fixed thusly, bootstrapped/regtested on armv7hl-linux-gnueabi and
aarch64-linux, ok for trunk?

2019-02-23  Jakub Jelinek  

PR target/70341
* config/arm/arm.md (arm_casesi_internal): New define_expand.  Rename
old define_insn to ...
(*arm_casesi_internal): ... this.  Add mode to LABEL_REFs.
* config/arm/thumb2.md (thumb2_casesi_internal): New define_expand.
Rename old define_insn to ...
(*thumb2_casesi_internal): ... this.  Add mode to LABEL_REFs.
(thumb2_casesi_internal_pic): New define_expand.  Rename old
define_insn to ...
(*thumb2_casesi_internal_pic): ... this.  Add mode to LABEL_REFs.
* config/aarch64/aarch64.md (casesi): Create the casesi_dispatch
MEM manually here, set MEM_READONLY_P and MEM_NOTRAP_P on it.

--- gcc/config/arm/arm.md.jj2019-02-18 20:48:32.643732307 +0100
+++ gcc/config/arm/arm.md   2019-02-21 14:40:50.603452028 +0100
@@ -8914,16 +8914,35 @@ (define_expand "casesi"
 
 ;; The USE in this pattern is needed to tell flow analysis that this is
 ;; a CASESI insn.  It has no other purpose.
-(define_insn "arm_casesi_internal"
+(define_expand "arm_casesi_internal"
+  [(parallel [(set (pc)
+  (if_then_else
+   (leu (match_operand:SI 0 "s_register_operand")
+(match_operand:SI 1 "arm_rhs_operand"))
+   (match_dup 4)
+   (label_ref:SI (match_operand 3 ""
+ (clobber (reg:CC CC_REGNUM))
+ (use (label_ref:SI (match_operand 2 "")))])]
+  "TARGET_ARM"
+{
+  operands[4] = gen_rtx_MULT (SImode, operands[0], GEN_INT (4));
+  operands[4] = gen_rtx_PLUS (SImode, operands[4],
+ gen_rtx_LABEL_REF (SImode, operands[2]));
+  operands[4] = gen_rtx_MEM (SImode, operands[4]);
+  MEM_READONLY_P (operands[4]) = 1;
+  MEM_NOTRAP_P (operands[4]) = 1;
+})
+
+(define_insn "*arm_casesi_internal"
   [(parallel [(set (pc)
   (if_then_else
(leu (match_operand:SI 0 "s_register_operand" "r")
 (match_operand:SI 1 "arm_rhs_operand" "rI"))
(mem:SI (plus:SI (mult:SI (match_dup 0) (const_int 4))
-(label_ref (match_operand 2 "" ""
-   (label_ref (match_operand 3 "" ""
+(label_ref:SI (match_operand 2 "" ""
+   (label_ref:SI (match_operand 3 "" ""
  (clobber (reg:CC CC_REGNUM))
- (use (label_ref (match_dup 2)))])]
+ (use (label_ref:SI (match_dup 2)))])]
   "TARGET_ARM"
   "*
 if (flag_pic)
--- gcc/config/arm/thumb2.md.jj 2019-01-01 12:37:28.280792453 +0100
+++ gcc/config/arm/thumb2.md2019-02-21 15:00:26.811137210 +0100
@@ -1079,17 +1079,37 @@ (define_insn "thumb2_zero_extendqisi2_v6
(set_attr "neg_pool_range" "*,250")]
 )
 
-(define_insn "thumb2_casesi_internal"
+(define_expand "thumb2_casesi_internal"
+  [(parallel [(set (pc)
+  (if_then_else
+   (leu (match_operand:SI 0 "s_register_operand")
+(match_operand:SI 1 "arm_rhs_operand"))
+   (match_dup 4)
+   (label_ref:SI (match_operand 3 ""
+ (clobber (reg:CC CC_REGNUM))
+ (clobber (match_scratch:SI 5))
+ (use (label_ref:SI (match_operand 2 "")))])]
+  "TARGET_THUMB2 && !flag_pic"
+{
+  operands[4] = gen_rtx_MULT (SImode, operands[0], GEN_INT (4));
+  operands[4] = gen_rtx_PLUS (SImode, operands[4],
+ gen_rtx_LABEL_REF (SImode, operands[2]));
+  operands[4] = gen_rtx_MEM (SImode, operands[4]);
+  MEM_READONLY_P (operands[4]) = 1;
+  MEM_NOTRAP_P (operands[4]) = 1;
+})
+
+(define_insn "*thumb2_casesi_internal"
   [(parallel [(set (pc)
   (if_then_else
(leu (match_operand:SI 0 "s_register_operand" "r")
 (match_operand:SI 1 "arm_rhs_operand" "rI"))
(mem:SI (plus:SI (mult:SI (match_dup 0) (const_int 4))
-(label_ref (match_operand 2 "" ""
-   (label_ref (match_operand 3 "" ""
+(label_ref:SI (match_operand 2 "" ""
+   (label_ref:SI (match_operand 3 "" ""
  (clobber (reg:CC CC_REGNUM))
  (clobber (match_scratch:SI 4 "="))
- (use (label_ref (match_dup 2)))])]
+ (use (label_ref:SI (match_dup 2)))])]
   "TARGET_THUMB2 && !flag_pic"
   "* return thumb2_output_casesi(operands);"
   [(set_attr "conds" "clob")
@@ -1097,18 +1117,39 @@ (define_insn 

Re: PING [PATCH] avoid 4095/INT_MAX warning for fprintf (PR 88993)

[Jakub Jelinek]

On Fri, Feb 22, 2019 at 04:17:14PM -0700, Martin Sebor wrote:
> On 2/22/19 3:44 PM, Jakub Jelinek wrote:
> > On Tue, Feb 19, 2019 at 05:43:53PM -0700, Martin Sebor wrote:
> > >   PR tree-optimization/88993
> > >   PR tree-optimization/88835
> > >   * gcc.dg/tree-ssa/builtin-fprintf-warn-2.c: New test.
> > >   * gcc.dg/tree-ssa/builtin-printf-warn-2.c: New test.
> > >   * gcc.dg/tree-ssa/builtin-snprintf-warn-3.c: Adjust.
> > >   * gcc.dg/tree-ssa/builtin-sprintf-warn-18.c: Same.
> > 
> > Can you please, when testing a patch like this where you should expect
> > tbe wordsize will play an important role to test it with
> > make check-gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} 
> > tree-ssa.exp=builtin-*printf-warn*'
> > ?
> > There are many failures on ilp32 targets.
> > 
> > +FAIL: gcc.dg/tree-ssa/builtin-fprintf-warn-2.c  (test for warnings, line 
> > 114)
> 
> I don't see these failures with -m32.  They must be specific to 32-bit
> GCC itself.

My bootstrap was indeed i686-linux, not x86_64-linux compiler with -m32.
E.g. target_strtol10 for some strange reason returns long rather than
HOST_WIDE_INT and checks LONG_MAX rather than HOST_WIDE_INT_MAX, making
it host dependent rather than target dependent.  Either it should work with
HWI and its max always, or should cap at precision of some target type
(e.g. glibc I think uses int type for both width and precision, parsing
through read_int that is similar to target_strtol10, except that it returns
(target) int and if over INT_MAX uses -1).

Jakub

Re: C++ PATCH for c++/88294 - ICE with non-constant noexcept-specifier

[Marek Polacek]

On Thu, Feb 21, 2019 at 02:57:28PM -1000, Jason Merrill wrote:
> On 2/21/19 1:34 PM, Marek Polacek wrote:
> > On Thu, Feb 21, 2019 at 11:22:41AM -1000, Jason Merrill wrote:
> > > On 2/21/19 10:56 AM, Marek Polacek wrote:
> > > > On Wed, Feb 20, 2019 at 01:53:18PM -1000, Jason Merrill wrote:
> > > > > On 2/20/19 10:31 AM, Marek Polacek wrote:
> > > > > > Here we ICE when substituting a deferred noexcept-specifier, 
> > > > > > because it
> > > > > > contains 'this', a PARM_DECL, in an evaluated context.  This is 
> > > > > > different
> > > > > > from "noexcept(noexcept(this))" where the noexcept operator's 
> > > > > > operand is
> > > > > > an unevaluated operand.  We crash within tsubst_copy's PARM_DECL 
> > > > > > handling
> > > > > > of a 'this' PARM_DECL:
> > > > > > 15488   gcc_assert (cp_unevaluated_operand != 0)
> > > > > > It'd be wrong to mess with cp_unevaluated_operand (or 
> > > > > > current_class_*), and
> > > > > > since we only check the expression's constness after substituting in
> > > > > > maybe_instantiate_noexcept, one fix would be the following.
> > > > > > 
> > > > > > This is not just about 'this', as the 87844 test shows: here we 
> > > > > > also have
> > > > > > a parameter whose value we're trying to determine -- it's a 
> > > > > > template arg
> > > > > > of a late-specified return type.  Returning the original value in 
> > > > > > tsubst_copy
> > > > > > and leaving the later code to complain seems to work here as well.  
> > > > > > Just
> > > > > > removing the assert should work as well.
> > > > > 
> > > > > I'm reluctant to mess with this assert, as it catches a lot of lambda 
> > > > > bugs.
> > > > 
> > > > Makes sense -- I wasn't aware of that.
> > > > 
> > > > > I think we want to register_parameter_specializations when 
> > > > > instantiating
> > > > > deferred noexcept, so that tsubst_copy can find the right decls.
> > > > 
> > > > Thanks for the suggestion -- that works with one catch: we need to 
> > > > replace the
> > > > fake 'this' in the noexcept- specifier with a real 'this' (the template 
> > > > one),
> > > > one that has DECL_CONTEXT set.  The fake one comes from 
> > > > inject_this_parameter,
> > > > when we were parsing the noexcept-specifier.  The real one was set in 
> > > > grokfndecl.
> > > 
> > > If you set current_class_ptr appropriately tsubst_copy will use it, so you
> > > shouldn't need to do a walk_tree.
> > 
> > Unfortunately that broke a lot of libstdc++ tests.  I can poke at it more if
> > you feel stronly about it.
> 
> Please do poke a bit more, that surprises me.

Apparently *someone* needs to learn how to properly restore c_c_{ptr,ref}...

noexcept35.C is a new test reduced from something from libstdc++.  Since it
exercises codepaths that nothing in dg.exp does, I think it's worth adding.

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

2019-02-22  Marek Polacek  

PR c++/88294 - ICE with non-constant noexcept-specifier.
* pt.c (maybe_instantiate_noexcept): Set up the list of local
specializations.  Set current_class_{ptr,ref}.

* g++.dg/cpp0x/noexcept34.C: New test.
* g++.dg/cpp0x/noexcept35.C: New test.

diff --git gcc/cp/pt.c gcc/cp/pt.c
index 42dd095a6b0..d678e278078 100644
--- gcc/cp/pt.c
+++ gcc/cp/pt.c
@@ -24203,12 +24203,39 @@ maybe_instantiate_noexcept (tree fn, tsubst_flags_t 
complain)
  push_access_scope (fn);
  push_deferring_access_checks (dk_no_deferred);
  input_location = DECL_SOURCE_LOCATION (fn);
- noex = tsubst_copy_and_build (DEFERRED_NOEXCEPT_PATTERN (noex),
-   DEFERRED_NOEXCEPT_ARGS (noex),
-   tf_warning_or_error, fn,
-   /*function_p=*/false,
-   
/*integral_constant_expression_p=*/true);
- spec = build_noexcept_spec (noex, tf_warning_or_error);
+
+ /* A new stack interferes with pop_access_scope.  */
+ {
+   /* Set up the list of local specializations.  */
+   local_specialization_stack lss (lss_copy);
+
+   tree save_ccp = current_class_ptr;
+   tree save_ccr = current_class_ref;
+   /* If needed, set current_class_ptr for the benefit of
+  tsubst_copy/PARM_DECL.  */
+   tree tdecl = DECL_TEMPLATE_RESULT (DECL_TI_TEMPLATE (fn));
+   if (DECL_NONSTATIC_MEMBER_FUNCTION_P (tdecl))
+ {
+   tree this_parm = DECL_ARGUMENTS (tdecl);
+   current_class_ptr = NULL_TREE;
+   current_class_ref = cp_build_fold_indirect_ref (this_parm);
+   current_class_ptr = this_parm;
+ }
+
+   /* Create substitution entries for the parameters.  */
+   register_parameter_specializations (tdecl, fn);
+
+   /* Do deferred instantiation of the noexcept-specifier.  */
+   noex = tsubst_copy_and_build 

Re: PING [PATCH] avoid 4095/INT_MAX warning for fprintf (PR 88993)

[Martin Sebor]

On 2/22/19 3:44 PM, Jakub Jelinek wrote:

On Tue, Feb 19, 2019 at 05:43:53PM -0700, Martin Sebor wrote:

PR tree-optimization/88993
PR tree-optimization/88835
* gcc.dg/tree-ssa/builtin-fprintf-warn-2.c: New test.
* gcc.dg/tree-ssa/builtin-printf-warn-2.c: New test.
* gcc.dg/tree-ssa/builtin-snprintf-warn-3.c: Adjust.
* gcc.dg/tree-ssa/builtin-sprintf-warn-18.c: Same.


Can you please, when testing a patch like this where you should expect
tbe wordsize will play an important role to test it with
make check-gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} 
tree-ssa.exp=builtin-*printf-warn*'
?
There are many failures on ilp32 targets.

+FAIL: gcc.dg/tree-ssa/builtin-fprintf-warn-2.c  (test for warnings, line 114)


I don't see these failures with -m32.  They must be specific to 32-bit
GCC itself.


+FAIL: gcc.dg/tree-ssa/l  (test for warnings, line 115)
+FAIL: gcc.dg/tree-ssa/builtin-fprintf-warn-2.c  (test for warnings, line 116)
+FAIL: gcc.dg/tree-ssa/builtin-fprintf-warn-2.c  (test for warnings, line 166)
+FAIL: gcc.dg/tree-ssa/builtin-fprintf-warn-2.c  (test for warnings, line 167)
+FAIL: gcc.dg/tree-ssa/builtin-fprintf-warn-2.c  (test for warnings, line 168)
+FAIL: gcc.dg/tree-ssa/builtin-fprintf-warn-2.c  (test for warnings, line 224)
+FAIL: gcc.dg/tree-ssa/builtin-fprintf-warn-2.c  (test for warnings, line 225)
+FAIL: gcc.dg/tree-ssa/builtin-fprintf-warn-2.c  (test for warnings, line 226)
+FAIL: gcc.dg/tree-ssa/builtin-fprintf-warn-2.c  (test for warnings, line 282)
+FAIL: gcc.dg/tree-ssa/builtin-fprintf-warn-2.c  (test for warnings, line 283)
+FAIL: gcc.dg/tree-ssa/builtin-fprintf-warn-2.c  (test for warnings, line 284)
+FAIL: gcc.dg/tree-ssa/builtin-fprintf-warn-2.c  (test for warnings, line 36)
+FAIL: gcc.dg/tree-ssa/builtin-fprintf-warn-2.c  (test for warnings, line 37)
+FAIL: gcc.dg/tree-ssa/builtin-fprintf-warn-2.c  (test for warnings, line 38)
+FAIL: gcc.dg/tree-ssa/builtin-fprintf-warn-2.c (test for excess errors)
+FAIL: gcc.dg/tree-ssa/builtin-printf-warn-2.c  (test for warnings, line 135)
+FAIL: gcc.dg/tree-ssa/builtin-printf-warn-2.c  (test for warnings, line 136)
+FAIL: gcc.dg/tree-ssa/builtin-printf-warn-2.c  (test for warnings, line 137)
+FAIL: gcc.dg/tree-ssa/builtin-printf-warn-2.c  (test for warnings, line 193)
+FAIL: gcc.dg/tree-ssa/builtin-printf-warn-2.c  (test for warnings, line 194)
+FAIL: gcc.dg/tree-ssa/builtin-printf-warn-2.c  (test for warnings, line 195)
+FAIL: gcc.dg/tree-ssa/builtin-printf-warn-2.c  (test for warnings, line 251)
+FAIL: gcc.dg/tree-ssa/builtin-printf-warn-2.c  (test for warnings, line 252)
+FAIL: gcc.dg/tree-ssa/builtin-printf-warn-2.c  (test for warnings, line 253)
+FAIL: gcc.dg/tree-ssa/builtin-printf-warn-2.c  (test for warnings, line 30)
+FAIL: gcc.dg/tree-ssa/builtin-printf-warn-2.c  (test for warnings, line 31)
+FAIL: gcc.dg/tree-ssa/builtin-printf-warn-2.c  (test for warnings, line 32)
+FAIL: gcc.dg/tree-ssa/builtin-printf-warn-2.c  (test for warnings, line 83)
+FAIL: gcc.dg/tree-ssa/builtin-printf-warn-2.c  (test for warnings, line 84)
+FAIL: gcc.dg/tree-ssa/builtin-printf-warn-2.c  (test for warnings, line 85)
+FAIL: gcc.dg/tree-ssa/builtin-printf-warn-2.c (test for excess errors)

and

FAIL: gcc.dg/tree-ssa/builtin-sprintf-10.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c second (test for warnings, line 
120)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c second (test for warnings, line 
122)

are not new today.


I silenced these warnings: they were due to bug 77970 where -Wformat
complains for

  printf ("%lc", L'x');

with -m32 but not with -m64.

Martin

Re: PING [PATCH] avoid 4095/INT_MAX warning for fprintf (PR 88993)

[Jakub Jelinek]

On Tue, Feb 19, 2019 at 05:43:53PM -0700, Martin Sebor wrote:
>   PR tree-optimization/88993
>   PR tree-optimization/88835
>   * gcc.dg/tree-ssa/builtin-fprintf-warn-2.c: New test.
>   * gcc.dg/tree-ssa/builtin-printf-warn-2.c: New test.
>   * gcc.dg/tree-ssa/builtin-snprintf-warn-3.c: Adjust.
>   * gcc.dg/tree-ssa/builtin-sprintf-warn-18.c: Same.

Can you please, when testing a patch like this where you should expect
tbe wordsize will play an important role to test it with
make check-gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} 
tree-ssa.exp=builtin-*printf-warn*'
?
There are many failures on ilp32 targets.

+FAIL: gcc.dg/tree-ssa/builtin-fprintf-warn-2.c  (test for warnings, line 114)
+FAIL: gcc.dg/tree-ssa/builtin-fprintf-warn-2.c  (test for warnings, line 115)
+FAIL: gcc.dg/tree-ssa/builtin-fprintf-warn-2.c  (test for warnings, line 116)
+FAIL: gcc.dg/tree-ssa/builtin-fprintf-warn-2.c  (test for warnings, line 166)
+FAIL: gcc.dg/tree-ssa/builtin-fprintf-warn-2.c  (test for warnings, line 167)
+FAIL: gcc.dg/tree-ssa/builtin-fprintf-warn-2.c  (test for warnings, line 168)
+FAIL: gcc.dg/tree-ssa/builtin-fprintf-warn-2.c  (test for warnings, line 224)
+FAIL: gcc.dg/tree-ssa/builtin-fprintf-warn-2.c  (test for warnings, line 225)
+FAIL: gcc.dg/tree-ssa/builtin-fprintf-warn-2.c  (test for warnings, line 226)
+FAIL: gcc.dg/tree-ssa/builtin-fprintf-warn-2.c  (test for warnings, line 282)
+FAIL: gcc.dg/tree-ssa/builtin-fprintf-warn-2.c  (test for warnings, line 283)
+FAIL: gcc.dg/tree-ssa/builtin-fprintf-warn-2.c  (test for warnings, line 284)
+FAIL: gcc.dg/tree-ssa/builtin-fprintf-warn-2.c  (test for warnings, line 36)
+FAIL: gcc.dg/tree-ssa/builtin-fprintf-warn-2.c  (test for warnings, line 37)
+FAIL: gcc.dg/tree-ssa/builtin-fprintf-warn-2.c  (test for warnings, line 38)
+FAIL: gcc.dg/tree-ssa/builtin-fprintf-warn-2.c (test for excess errors)
+FAIL: gcc.dg/tree-ssa/builtin-printf-warn-2.c  (test for warnings, line 135)
+FAIL: gcc.dg/tree-ssa/builtin-printf-warn-2.c  (test for warnings, line 136)
+FAIL: gcc.dg/tree-ssa/builtin-printf-warn-2.c  (test for warnings, line 137)
+FAIL: gcc.dg/tree-ssa/builtin-printf-warn-2.c  (test for warnings, line 193)
+FAIL: gcc.dg/tree-ssa/builtin-printf-warn-2.c  (test for warnings, line 194)
+FAIL: gcc.dg/tree-ssa/builtin-printf-warn-2.c  (test for warnings, line 195)
+FAIL: gcc.dg/tree-ssa/builtin-printf-warn-2.c  (test for warnings, line 251)
+FAIL: gcc.dg/tree-ssa/builtin-printf-warn-2.c  (test for warnings, line 252)
+FAIL: gcc.dg/tree-ssa/builtin-printf-warn-2.c  (test for warnings, line 253)
+FAIL: gcc.dg/tree-ssa/builtin-printf-warn-2.c  (test for warnings, line 30)
+FAIL: gcc.dg/tree-ssa/builtin-printf-warn-2.c  (test for warnings, line 31)
+FAIL: gcc.dg/tree-ssa/builtin-printf-warn-2.c  (test for warnings, line 32)
+FAIL: gcc.dg/tree-ssa/builtin-printf-warn-2.c  (test for warnings, line 83)
+FAIL: gcc.dg/tree-ssa/builtin-printf-warn-2.c  (test for warnings, line 84)
+FAIL: gcc.dg/tree-ssa/builtin-printf-warn-2.c  (test for warnings, line 85)
+FAIL: gcc.dg/tree-ssa/builtin-printf-warn-2.c (test for excess errors)

and

FAIL: gcc.dg/tree-ssa/builtin-sprintf-10.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c second (test for warnings, line 
120)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c second (test for warnings, line 
122)

are not new today.

Jakub

[PATCH] Fix var-tracking ICE on ARM due to backend bug (PR target/89438)

[Jakub Jelinek]

Hi!

The following testcase ICEs on arm, because the backend creates
non-canonical SImode constants (0x8000).  CONST_INTs always need to be
sign-extended from their corresponding mode to HOST_WIDE_INT.

Fixed thusly, bootstrapped/regtested on armv7hl-linux-gnueabi, ok for trunk?

2019-02-22  Jakub Jelinek  

PR target/89438
* config/arm.vfp.md (*negdf2_vfp): Use HOST_WIDE_INT_C (-0x8000)
instead of 0x8000.
* config/arm/neon.md (neon_copysignf): Likewise.

* gcc.dg/pr89438.c: New test.

--- gcc/config/arm/vfp.md.jj2019-02-18 20:48:32.642732323 +0100
+++ gcc/config/arm/vfp.md   2019-02-22 00:37:36.730795663 +0100
@@ -871,14 +871,15 @@ (define_insn_and_split "*negdf2_vfp"
   if (REGNO (operands[0]) == REGNO (operands[1]))
 {
   operands[0] = gen_highpart (SImode, operands[0]);
-  operands[1] = gen_rtx_XOR (SImode, operands[0], GEN_INT (0x8000));
+  operands[1] = gen_rtx_XOR (SImode, operands[0],
+GEN_INT (HOST_WIDE_INT_C (-0x8000)));
 }
   else
 {
   rtx in_hi, in_lo, out_hi, out_lo;
 
   in_hi = gen_rtx_XOR (SImode, gen_highpart (SImode, operands[1]),
-  GEN_INT (0x8000));
+  GEN_INT (HOST_WIDE_INT_C (-0x8000)));
   in_lo = gen_lowpart (SImode, operands[1]);
   out_hi = gen_highpart (SImode, operands[0]);
   out_lo = gen_lowpart (SImode, operands[0]);
--- gcc/config/arm/neon.md.jj   2019-02-07 17:33:38.840669157 +0100
+++ gcc/config/arm/neon.md  2019-02-22 00:40:15.243249783 +0100
@@ -3610,7 +3610,7 @@ (define_expand "neon_copysignf"
   "{
  rtx v_bitmask_cast;
  rtx v_bitmask = gen_reg_rtx (mode);
- rtx c = GEN_INT (0x8000);
+ rtx c = GEN_INT (HOST_WIDE_INT_C (-0x8000));
 
  emit_move_insn (v_bitmask,
 gen_const_vec_duplicate (mode, c));
--- gcc/testsuite/gcc.dg/pr89438.c.jj   2019-02-22 00:45:26.662292609 +0100
+++ gcc/testsuite/gcc.dg/pr89438.c  2019-02-22 00:45:02.130682728 +0100
@@ -0,0 +1,22 @@
+/* PR target/89438 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -g -w" } */
+
+struct S { double b, c; struct T { double d, e; } f[16]; } g;
+int h, i, j;
+double k;
+
+double
+foo (void)
+{
+  int m;
+  if (j)
+return k;
+  long a, p = a - 80;
+  double b, n;
+  n = b * h + g.f[p].e;
+  m = n;
+  double o = 1 ? m : 1.0;
+  k = i ? -o : o;
+  return k;
+}

Jakub

Re: [PATCH] luoxhu - backport from trunk r255555, r257253 and r258137

[Segher Boessenkool]

On Wed, Feb 20, 2019 at 09:40:25AM +0800, Xiong Hu Luo wrote:
> On 2019/2/20 AM6:24, Segher Boessenkool wrote:
> >On Tue, Feb 19, 2019 at 01:23:53AM -0600, luo...@linux.ibm.com wrote:
> >>This is a backport of r25, r257253 and r258137 of trunk to 
> >>gcc-7-branch.
> >>The patches were on trunk before GCC 8 forked already. Totally 5 files 
> >>need
> >>mannual resolve due to code changes for r25. r257253 and r258137 are
> >>dependent testcases require vsx support need merge to avoid regression.
> >
> >Could you show what changes you needed, please?  As patches for example.
> >It's not clear from the log :-(

So what is different?  Why did those patches not apply?  Your changelog
says you did have to change things.  So what are those?


Segher

Re: [patch] Add baseline for SPARC64/Linux

[Eric Botcazou]

> Sorry for the delay, I'm in a meeting all week with limited time for
> patch review.

No problem, thanks for reviewing!

> We don't usually include the __once_callable symbols in the baseline
> file, are you sure it's correct to do so for sparc64-linux-gnu?
> 
> +TLS:8:_ZSt11__once_call@@GLIBCXX_3.4.11
> +TLS:8:_ZSt15__once_callable@@GLIBCXX_3.4.11

Now removed for the sake of consistency with the SPARC/Linux twin port.

-- 
Eric Botcazou

Re: [patch] Add baseline for SPARC64/Linux

[Jonathan Wakely]

On 22/02/19 21:26 +0100, Jakub Jelinek wrote:

On Fri, Feb 22, 2019 at 08:24:09PM +, Jonathan Wakely wrote:

> > We don't usually include the __once_callable symbols in the baseline
> > file, are you sure it's correct to do so for sparc64-linux-gnu?
> >
> > +TLS:8:_ZSt11__once_call@@GLIBCXX_3.4.11
> > +TLS:8:_ZSt15__once_callable@@GLIBCXX_3.4.11
>
> It shouldn't be there on any target, as it will differ between configuring
> the library with and without TLS.

Right, that's my understanding. We get that wrong though:


Maybe it would be best to include them but if the compiler is configured
without native TLS ignore the TLS lines.


That should be a pretty easy change to the tests, I'll add it to my
TODO list.


config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt:TLS:4:_ZSt15__once_callable@@GLIBCXX_3.4.11
config/abi/post/i386-solaris2.11/amd64/baseline_symbols.txt:TLS:8:_ZSt15__once_callable@@GLIBCXX_3.4.11
config/abi/post/i386-solaris2.11/baseline_symbols.txt:TLS:4:_ZSt15__once_callable@@GLIBCXX_3.4.11
config/abi/post/mips64-linux-gnu/64/baseline_symbols.txt:TLS:8:_ZSt15__once_callable@@GLIBCXX_3.4.11
config/abi/post/mips64-linux-gnu/32/baseline_symbols.txt:TLS:4:_ZSt15__once_callable@@GLIBCXX_3.4.11
config/abi/post/i386-solaris2.10/amd64/baseline_symbols.txt:TLS:8:_ZSt15__once_callable@@GLIBCXX_3.4.11
config/abi/post/i386-solaris2.10/baseline_symbols.txt:TLS:4:_ZSt15__once_callable@@GLIBCXX_3.4.11
config/abi/post/sparc-solaris2.10/sparcv9/baseline_symbols.txt:TLS:8:_ZSt15__once_callable@@GLIBCXX_3.4.11
config/abi/post/sparc-solaris2.10/baseline_symbols.txt:TLS:4:_ZSt15__once_callable@@GLIBCXX_3.4.11
config/abi/post/sparc-solaris2.11/sparcv9/baseline_symbols.txt:TLS:8:_ZSt15__once_callable@@GLIBCXX_3.4.11
config/abi/post/sparc-solaris2.11/baseline_symbols.txt:TLS:4:_ZSt15__once_callable@@GLIBCXX_3.4.11


Jakub

Re: [PR fortran/83057, patch] - OPEN without a filename and without STATUS='SCRATCH' could produce a warning

[Harald Anlauf]

Committed to trunk as rev. 269134.

Thanks for the review!

Harald

On 02/22/19 06:28, Jerry DeLisle wrote:
> On 2/20/19 2:34 PM, Harald Anlauf wrote:
>> There was a rather obvious bug in the logic for checking the arguments
>> to the OPEN statement when NEWUNIT= was specified, which prohibited
>> the generation of the appropriate error message.
>>
>> Regtested successfully.
>>
>> OK for trunk?
> 
> Yes and thanks for patch.
> 
> Jerry
> 

[Committed] PR fortran/89431 -- correct documentation

[Steve Kargl]

Change and patch are self-explanatory.

2019-02-22  Steven G. Kargl  

PR fortran/89431
* gfortran.texi: Fix documentation to match the implementation.

Index: gfortran.texi
===
--- gfortran.texi   (revision 269131)
+++ gfortran.texi   (revision 269132)
@@ -425,9 +425,9 @@ compiler.  See @ref{Top,,Overview,cpp,The C Preprocess
 GNU Fortran supports a number of @code{INTEGER} and @code{REAL} kind types
 in additional to the kind types required by the Fortran standard.
 The availability of any given kind type is architecture dependent.  The
-following pre-defined preprocessor macros can be used to conditional
-include code for these additional kind types: @code{__GFC_INTEGER_1__},
-@code{__GFC_INTEGER_2__}, @code{__GFC_INTEGER_8__}, @code{__GFC_INTEGER_16__},
+following pre-defined preprocessor macros can be used to conditionally
+include code for these additional kind types: @code{__GFC_INT_1__},
+@code{__GFC_INT_2__}, @code{__GFC_INT_8__}, @code{__GFC_INT_16__},
 @code{__GFC_REAL_10__}, and @code{__GFC_REAL_16__}.
 
 While CPP is the de-facto standard for preprocessing Fortran code,
troutmask:sgk[206] 

-- 
Steve

Re: [patch] Add baseline for SPARC64/Linux

[Jakub Jelinek]

On Fri, Feb 22, 2019 at 08:24:09PM +, Jonathan Wakely wrote:
> > > We don't usually include the __once_callable symbols in the baseline
> > > file, are you sure it's correct to do so for sparc64-linux-gnu?
> > > 
> > > +TLS:8:_ZSt11__once_call@@GLIBCXX_3.4.11
> > > +TLS:8:_ZSt15__once_callable@@GLIBCXX_3.4.11
> > 
> > It shouldn't be there on any target, as it will differ between configuring
> > the library with and without TLS.
> 
> Right, that's my understanding. We get that wrong though:

Maybe it would be best to include them but if the compiler is configured
without native TLS ignore the TLS lines.

> config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt:TLS:4:_ZSt15__once_callable@@GLIBCXX_3.4.11
> config/abi/post/i386-solaris2.11/amd64/baseline_symbols.txt:TLS:8:_ZSt15__once_callable@@GLIBCXX_3.4.11
> config/abi/post/i386-solaris2.11/baseline_symbols.txt:TLS:4:_ZSt15__once_callable@@GLIBCXX_3.4.11
> config/abi/post/mips64-linux-gnu/64/baseline_symbols.txt:TLS:8:_ZSt15__once_callable@@GLIBCXX_3.4.11
> config/abi/post/mips64-linux-gnu/32/baseline_symbols.txt:TLS:4:_ZSt15__once_callable@@GLIBCXX_3.4.11
> config/abi/post/i386-solaris2.10/amd64/baseline_symbols.txt:TLS:8:_ZSt15__once_callable@@GLIBCXX_3.4.11
> config/abi/post/i386-solaris2.10/baseline_symbols.txt:TLS:4:_ZSt15__once_callable@@GLIBCXX_3.4.11
> config/abi/post/sparc-solaris2.10/sparcv9/baseline_symbols.txt:TLS:8:_ZSt15__once_callable@@GLIBCXX_3.4.11
> config/abi/post/sparc-solaris2.10/baseline_symbols.txt:TLS:4:_ZSt15__once_callable@@GLIBCXX_3.4.11
> config/abi/post/sparc-solaris2.11/sparcv9/baseline_symbols.txt:TLS:8:_ZSt15__once_callable@@GLIBCXX_3.4.11
> config/abi/post/sparc-solaris2.11/baseline_symbols.txt:TLS:4:_ZSt15__once_callable@@GLIBCXX_3.4.11

Jakub

Re: [patch] Add baseline for SPARC64/Linux

[Jonathan Wakely]

On 22/02/19 20:43 +0100, Jakub Jelinek wrote:

On Fri, Feb 22, 2019 at 07:24:57PM +, Jonathan Wakely wrote:

On 22/02/19 08:27 +0100, Eric Botcazou wrote:
> > 2019-02-20  Eric Botcazou  
> >
> > * configure.host (abi_baseline_pair): Adjust for SPARC64/Linux.
> > * config/abi/post/sparc64-linux-gnu: New directory.
> > * config/abi/post/sparc64-linux-gnu/baseline_symbols.txt: New file.
> > * config/abi/post/sparc64-linux-gnu/32: New directory.
> >   * config/abi/post/sparc64-linux-gnu/32/baseline_symbols.txt: New file.
>
> I can probably self-approve it as SPARC maintainer so now installed.

Sorry for the delay, I'm in a meeting all week with limited time for
patch review.

We don't usually include the __once_callable symbols in the baseline
file, are you sure it's correct to do so for sparc64-linux-gnu?

+TLS:8:_ZSt11__once_call@@GLIBCXX_3.4.11
+TLS:8:_ZSt15__once_callable@@GLIBCXX_3.4.11


It shouldn't be there on any target, as it will differ between configuring
the library with and without TLS.


Right, that's my understanding. We get that wrong though:

config/abi/post/x86_64-linux-gnu/x32/baseline_symbols.txt:TLS:4:_ZSt15__once_callable@@GLIBCXX_3.4.11
config/abi/post/i386-solaris2.11/amd64/baseline_symbols.txt:TLS:8:_ZSt15__once_callable@@GLIBCXX_3.4.11
config/abi/post/i386-solaris2.11/baseline_symbols.txt:TLS:4:_ZSt15__once_callable@@GLIBCXX_3.4.11
config/abi/post/mips64-linux-gnu/64/baseline_symbols.txt:TLS:8:_ZSt15__once_callable@@GLIBCXX_3.4.11
config/abi/post/mips64-linux-gnu/32/baseline_symbols.txt:TLS:4:_ZSt15__once_callable@@GLIBCXX_3.4.11
config/abi/post/i386-solaris2.10/amd64/baseline_symbols.txt:TLS:8:_ZSt15__once_callable@@GLIBCXX_3.4.11
config/abi/post/i386-solaris2.10/baseline_symbols.txt:TLS:4:_ZSt15__once_callable@@GLIBCXX_3.4.11
config/abi/post/sparc-solaris2.10/sparcv9/baseline_symbols.txt:TLS:8:_ZSt15__once_callable@@GLIBCXX_3.4.11
config/abi/post/sparc-solaris2.10/baseline_symbols.txt:TLS:4:_ZSt15__once_callable@@GLIBCXX_3.4.11
config/abi/post/sparc-solaris2.11/sparcv9/baseline_symbols.txt:TLS:8:_ZSt15__once_callable@@GLIBCXX_3.4.11
config/abi/post/sparc-solaris2.11/baseline_symbols.txt:TLS:4:_ZSt15__once_callable@@GLIBCXX_3.4.11

Re: [patch] Add baseline for SPARC64/Linux

[Jakub Jelinek]

On Fri, Feb 22, 2019 at 07:24:57PM +, Jonathan Wakely wrote:
> On 22/02/19 08:27 +0100, Eric Botcazou wrote:
> > > 2019-02-20  Eric Botcazou  
> > > 
> > > * configure.host (abi_baseline_pair): Adjust for SPARC64/Linux.
> > > * config/abi/post/sparc64-linux-gnu: New directory.
> > > * config/abi/post/sparc64-linux-gnu/baseline_symbols.txt: New 
> > > file.
> > > * config/abi/post/sparc64-linux-gnu/32: New directory.
> > >   * config/abi/post/sparc64-linux-gnu/32/baseline_symbols.txt: New 
> > > file.
> > 
> > I can probably self-approve it as SPARC maintainer so now installed.
> 
> Sorry for the delay, I'm in a meeting all week with limited time for
> patch review.
> 
> We don't usually include the __once_callable symbols in the baseline
> file, are you sure it's correct to do so for sparc64-linux-gnu?
> 
> +TLS:8:_ZSt11__once_call@@GLIBCXX_3.4.11
> +TLS:8:_ZSt15__once_callable@@GLIBCXX_3.4.11

It shouldn't be there on any target, as it will differ between configuring
the library with and without TLS.

Jakub

Re: [patch] Add baseline for SPARC64/Linux

[Jonathan Wakely]

On 22/02/19 08:27 +0100, Eric Botcazou wrote:

2019-02-20  Eric Botcazou  

* configure.host (abi_baseline_pair): Adjust for SPARC64/Linux.
* config/abi/post/sparc64-linux-gnu: New directory.
* config/abi/post/sparc64-linux-gnu/baseline_symbols.txt: New file.
* config/abi/post/sparc64-linux-gnu/32: New directory.
  * config/abi/post/sparc64-linux-gnu/32/baseline_symbols.txt: New file.


I can probably self-approve it as SPARC maintainer so now installed.


Sorry for the delay, I'm in a meeting all week with limited time for
patch review.

We don't usually include the __once_callable symbols in the baseline
file, are you sure it's correct to do so for sparc64-linux-gnu?

+TLS:8:_ZSt11__once_call@@GLIBCXX_3.4.11
+TLS:8:_ZSt15__once_callable@@GLIBCXX_3.4.11

Re: PING^2: [PATCH] i386; Add -mmanual-endbr and cf_check function attribute

[H.J. Lu]

On Fri, Dec 14, 2018 at 1:28 PM Jeff Law  wrote:
>
> On 12/11/18 9:03 AM, H.J. Lu wrote:
> > On Mon, Dec 3, 2018 at 5:45 AM H.J. Lu  wrote:
> >> On Mon, Jun 18, 2018 at 2:20 AM Richard Biener
> >>  wrote:
> >>> On Fri, Jun 15, 2018 at 2:59 PM H.J. Lu  wrote:
>  Currently GCC inserts ENDBR instruction at entries of all non-static
>  functions, unless LTO compilation is used.  Marking all functions,
>  which are not called indirectly with nocf_check attribute, is not
>  ideal since 99% of functions in a program may be of this kind.
> 
>  This patch adds -mmanual-endbr and cf_check function attribute.  They
>  can be used together with -fcf-protection such that ENDBR instruction
>  is inserted only at entries of functions with cf_check attribute.  It
>  can limit number of ENDBR instructions to reduce program size.
> 
>  OK for trubk?
> >>> I wonder if the linker could assist with ENDBR creation by
> >>> redirecting all non-direct call relocs to a linker-generated
> >>> stub with ENBR and a direct branch?
> >>>
> >> The goal of this patch is to add as few as ENDBR as possible
> >> to reduce program size as much as possible.   Also there is no
> >> relocation for indirect branch via register.
> >>
> > Hi Honza, Jakub, Jeff, Richard,
> >
> > Here is the rebased patch.  Can you guys take a look?
> >
> > Thanks.
> >
> >
> > -- H.J.
> >
> >
> > 0001-i386-Add-mmanual-endbr-and-cf_check-function-attribu.patch
> >
> > From 5934c6be6495b2d6f278646e25f9e684f6610e2b Mon Sep 17 00:00:00 2001
> > From: "H.J. Lu" 
> > Date: Thu, 14 Jun 2018 09:19:27 -0700
> > Subject: [PATCH] i386; Add -mmanual-endbr and cf_check function attribute
> >
> > Currently GCC inserts ENDBR instruction at entries of all non-static
> > functions, unless LTO compilation is used.  Marking all functions,
> > which are not called indirectly with nocf_check attribute, is not
> > ideal since 99% of functions in a program may be of this kind.
> >
> > This patch adds -mmanual-endbr and cf_check function attribute.  They
> > can be used together with -fcf-protection such that ENDBR instruction
> > is inserted only at entries of functions with cf_check attribute.  It
> > can limit number of ENDBR instructions to reduce program size.
> >
> > gcc/
> >
> >   * config/i386/i386.c (rest_of_insert_endbranch): Insert ENDBR
> >   at the function entry only when -mmanual-endbr isn't used or
> >   there is cf_check function attribute.
> >   (ix86_attribute_table): Add cf_check.
> >   * config/i386/i386.opt: Add -mmanual-endbr.
> >   * doc/extend.texi: Document cf_check attribute.
> >   * doc/invoke.texi: Document -mmanual-endbr.
> >
> > gcc/testsuite/
> >
> >   * gcc.target/i386/cf_check-1.c: New test.
> >   * gcc.target/i386/cf_check-2.c: Likewise.
> >   * gcc.target/i386/cf_check-3.c: Likewise.
> >   * gcc.target/i386/cf_check-4.c: Likewise.
> >   * gcc.target/i386/cf_check-5.c: Likewise.
> OK.
>
> Though I'm not sure how valuable this is in practice.  Yea, it saves
> some space at the start of functions, but I find myself wondering more
> and more if we should be pushing folks towards LTO for a variety of reasons.
>

Hi Jeff,

Here is an update for this new option to move  -mmanual-endbr check to
pass_insert_endbranch::gate.  I'd like to get it into GCC 9.


-- 
H.J.
From c1a25d170a942410eeb7803d61e6cac29678c9bd Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Thu, 14 Feb 2019 06:23:06 -0800
Subject: [PATCH] i386: Check -mmanual-endbr in pass_insert_endbranch::gate

When -mmanual-endbr is used with -fcf-protection, only functions marked
with cf_check attribute should be instrumented with ENDBR.  We should
skip rest_of_insert_endbranch on functions without cf_check attribute.

gcc/

	PR target/89353
	* config/i386/i386.c (rest_of_insert_endbranch): Move the
	-mmanual-endbr and cf_check attribute check to ..
	(pass_insert_endbranch::gate): Here.

gcc/testsuite/

	PR target/89353
	* gcc.target/i386/cf_check-6.c: New test.
---
 gcc/config/i386/i386.c | 10 +-
 gcc/testsuite/gcc.target/i386/cf_check-6.c | 23 ++
 2 files changed, 28 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/cf_check-6.c

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index fd05873ba39..a99ca23fffa 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -2640,9 +2640,6 @@ rest_of_insert_endbranch (void)
 
   if (!lookup_attribute ("nocf_check",
 			 TYPE_ATTRIBUTES (TREE_TYPE (cfun->decl)))
-  && (!flag_manual_endbr
-	  || lookup_attribute ("cf_check",
-			   DECL_ATTRIBUTES (cfun->decl)))
   && !cgraph_node::get (cfun->decl)->only_called_directly_p ())
 {
   /* Queue ENDBR insertion to x86_function_profiler.  */
@@ -2773,9 +2770,12 @@ public:
   {}
 
   /* opt_pass methods: */
-  virtual bool gate (function *)
+  virtual bool gate (function *fun)
 {
-  return 

Re: C++ PATCH for c++/89420 - ICE with CAST_EXPR in explicit-specifier

[Jason Merrill]

OK, thanks.

Jason

On Fri, Feb 22, 2019 at 6:11 AM Marek Polacek  wrote:
>
> On Thu, Feb 21, 2019 at 03:47:44PM -1000, Jason Merrill wrote:
> > On 2/21/19 1:35 PM, Marek Polacek wrote:
> > > We were ICEing because we called build_converted_constant_expr on an 
> > > expression
> > > that wasn't value-dependent, but it still contained template codes, and 
> > > that
> > > didn't work too well because check_narrowing calls maybe_constant_value.
> >
> > Hmm, I'm concerned about convert_like_real from
> > build_converted_constant_expr adding more template codes; you probably want
> > a processing_template_decl_sentinel after the
> > instantiate_non_dependent_expr.
>
> OK, that's a good trick.
>
> > Also, value_dependent_expression_p should probably be
> > instantiation_dependent_expression_p.
>
> I think I used value_* because that's what build_noexcept_spec had.  Also
> value_dependent_expression_p calls type_dependent_expression_p.  But I've
> changed it anyway.  Thanks,
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2019-02-22  Marek Polacek  
>
> PR c++/89420 - ICE with CAST_EXPR in explicit-specifier.
> * decl.c (build_explicit_specifier): Don't check
> processing_template_decl.  Call instantiation_dependent_expression_p
> instead of value_dependent_expression_p.  Call
> instantiate_non_dependent_expr_sfinae before
> build_converted_constant_expr instead of calling
> instantiate_non_dependent_expr after it.  Add
> processing_template_decl_sentinel.
>
> * g++.dg/cpp2a/explicit14.C: New test.
>
> diff --git gcc/cp/decl.c gcc/cp/decl.c
> index 612afbacd27..c5b5bd3ce08 100644
> --- gcc/cp/decl.c
> +++ gcc/cp/decl.c
> @@ -16687,12 +16687,14 @@ require_deduced_type (tree decl, tsubst_flags_t 
> complain)
>  tree
>  build_explicit_specifier (tree expr, tsubst_flags_t complain)
>  {
> -  if (processing_template_decl && value_dependent_expression_p (expr))
> +  if (instantiation_dependent_expression_p (expr))
>  /* Wait for instantiation, tsubst_function_decl will handle it.  */
>  return expr;
>
> +  expr = instantiate_non_dependent_expr_sfinae (expr, complain);
> +  /* Don't let convert_like_real create more template codes.  */
> +  processing_template_decl_sentinel s;
>expr = build_converted_constant_expr (boolean_type_node, expr, complain);
> -  expr = instantiate_non_dependent_expr (expr);
>expr = cxx_constant_value (expr);
>return expr;
>  }
> diff --git gcc/testsuite/g++.dg/cpp2a/explicit14.C 
> gcc/testsuite/g++.dg/cpp2a/explicit14.C
> new file mode 100644
> index 000..9c3acc32ac4
> --- /dev/null
> +++ gcc/testsuite/g++.dg/cpp2a/explicit14.C
> @@ -0,0 +1,11 @@
> +// PR c++/89420
> +// { dg-do compile { target c++2a } }
> +
> +template
> +struct S {
> +  explicit(int(1)) S(int);
> +  explicit(int{1}) S(int, int);
> +};
> +
> +S s(1);
> +S s2(1, 2);

Re: [PATCH] Fix -Wattributes warning in libstdc++ (PR libstdc++/89402)

[Jonathan Wakely]

On Fri, 22 Feb 2019 at 18:47, Jakub Jelinek wrote:
>
> On Fri, Feb 22, 2019 at 08:35:25AM -0700, Martin Sebor wrote:
> > > /home/jwakely/src/gcc/libstdc++-v3/src/c++98/compatibility-ldbl.cc:78:65:
> > > warning: ‘pure’ attribute on function returning ‘void’ [-Wattributes]
> > >78 |   _GLIBCXX_PURE __attribute__((alias ("_ZNKSt3tr14hashIeEclEe")));
> > >   | ^
> >
> > Are the attributes on this alias ever considered in calls to it?
> > If not (and assuming there's a way to tell, which I think there
> > should be but haven't verified it) the warning could be relaxed
>
> There is no point in relating this, this alias is just a hack in a hack
> to save a few bytes of code.
>
> I've now finally bootstrapped/regtested on {powerpc64le,s390x}-linux
> following patch, without it I indeed get those
> ../../../../libstdc++-v3/src/c++98/compatibility-ldbl.cc:78:65: warning: 
> 'pure' attribute on function returning 'void' [-Wattributes]
> warnings, with the patch I don't get any warnings on compatibility-ldbl.cc
> anymore.  Ok for trunk?

OK, thanks.

[PATCH] Fix -Wattributes warning in libstdc++ (PR libstdc++/89402)

[Jakub Jelinek]

On Fri, Feb 22, 2019 at 08:35:25AM -0700, Martin Sebor wrote:
> > /home/jwakely/src/gcc/libstdc++-v3/src/c++98/compatibility-ldbl.cc:78:65:
> > warning: ‘pure’ attribute on function returning ‘void’ [-Wattributes]
> >    78 |   _GLIBCXX_PURE __attribute__((alias ("_ZNKSt3tr14hashIeEclEe")));
> >   | ^
> 
> Are the attributes on this alias ever considered in calls to it?
> If not (and assuming there's a way to tell, which I think there
> should be but haven't verified it) the warning could be relaxed

There is no point in relating this, this alias is just a hack in a hack
to save a few bytes of code.

I've now finally bootstrapped/regtested on {powerpc64le,s390x}-linux
following patch, without it I indeed get those
../../../../libstdc++-v3/src/c++98/compatibility-ldbl.cc:78:65: warning: 'pure' 
attribute on function returning 'void' [-Wattributes]
warnings, with the patch I don't get any warnings on compatibility-ldbl.cc
anymore.  Ok for trunk?

2019-02-22  Jakub Jelinek  

PR libstdc++/89402
* src/c++98/compatibility-ldbl.cc (_ZNKSt4hashIeEclEe): Change return
type to std::size_t and argument to type to long double.

--- libstdc++-v3/src/c++98/compatibility-ldbl.cc.jj 2019-02-20 
08:57:18.161103140 +0100
+++ libstdc++-v3/src/c++98/compatibility-ldbl.cc2019-02-22 
09:17:54.619348391 +0100
@@ -74,7 +74,7 @@ namespace std _GLIBCXX_VISIBILITY(defaul
 // std::tr1::hash::operator()
 // and std::hash::operator()
 // are the same, no need to duplicate them.
-extern "C" void _ZNKSt4hashIeEclEe (void)
+extern "C" std::size_t _ZNKSt4hashIeEclEe (long double)
   _GLIBCXX_PURE __attribute__((alias ("_ZNKSt3tr14hashIeEclEe")));
 
 #endif


Jakub

Re: PING [PATCH] fix ICE in __builtin_has_attribute (PR 88383 and 89288)

[Martin Sebor]

I already explained the rationale behind the decision to have
the built-in accept expressions: to be able to easily query for
type attributes in expressions such as:

   typedef __attribute__ ((may_alias)) int* BadInt;

   void f (BadInt *p)
   {
 _Static_assert (__builtin_has_attribute (*p, may_alias));
   }

or

   struct S {
 int a[1] __attribute__ ((packed));
   };

   void f (struct S *p)
   {
 _Static_assert (__builtin_has_attribute (p->a, packed));
   }

or even

 _Static_assert (__builtin_has_attribute (p->a[0], packed));

If the built-in rejects expressions, I don't see how one would
query for these properties.


So how about __builtin_has_attribute (typeof (p->a), packed)?


typeof (p->a) is int, not 'packed int', so the built-in returns
false in this case, while true in the expression I wrote.  This
applies to any attribute that's attached to a member as opposed
to its type.  I know of no way to refer to a struct member in C
without using some non-trivial expression (in C++, S::a could
be used instead).


Trying to query/set attributes on things like "1 + 1" just doesn't make any
sense.  So why don't we handle TYPE_P/DECL_P and give an error for the rest?


Mainly because of the above.  But also because there is no harm
in accepting arbitrary expressions and querying their type, no
problem that I'm aware of that would justify giving an error.

This is analogous to __alignof__.  If __alignof__ (1 + 1) makes
enough sense to accept then I see no reason why
__builtin_has_attribute (1 + 1, aligned) should not be.

Martin

PS __alignof__ is documented to determine the alignment requirement
of a function, object, or a type, but it accepts expressions as well.
For lvalues, like p->a above, __alignof__ is further documented to
determine the alignment of the lvalue's type, but that's not what
it actually does, at least not in the sense of
__alignof__ (__typeof__ (p->a)), for over- or underaligned struct
members declared either with attribute aligned or packed.  What
it does is return the alignment of the member subobject, which is,
I'm sure, what most users expect.

Re: [PATCH] x86: (Reapply) Move AESNI generation to Skylake and Goldmont

[H.J. Lu]

On Thu, Feb 21, 2019 at 3:25 PM H.J. Lu  wrote:
>
> On Thu, Feb 21, 2019 at 3:10 PM Thiago Macieira
>  wrote:
> >
> > This is a repeat of commit r263989, which commit r264052 accidentally
> > reverted.
> >
> > Original commit message:
> >
> > The instruction set first appeared with Westmere, but not all processors
> > in that and the next few generations have the instructions. According to
> > Wikipedia[1], the first generation in which all SKUs have AES
> > instructions are Skylake and Goldmont. I can't find any Skylake,
> > Kabylake, Kabylake-R or Cannon Lake currently listed at
> > https://ark.intel.com that says "Intel® AES New Instructions" "No".
> >
> > [1] https://en.wikipedia.org/wiki/AES_instruction_set
> >
> > 2018-08-30  Thiago Macieira  
> >
> > * config/i386/i386.c (PTA_WESTMERE): Remove PTA_AES.
> > (PTA_SKYLAKE): Add PTA_AES.
> > (PTA_GOLDMONT): Likewise.
>
> I opened:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89444
>
> and I will check it in for Thiago tomorrow.
>

Now, r263989 has been re-applied.  I got

FAIL: g++.target/i386/mv16.C  -std=gnu++14 execution test
FAIL: g++.target/i386/mv16.C  -std=gnu++17 execution test
FAIL: g++.target/i386/mv16.C  -std=gnu++98 execution test

On Westmere.  Shouldn't this

   case PROCESSOR_NEHALEM:
  if (new_target->x_ix86_isa_flags & OPTION_MASK_ISA_AES)
{
  arg_str = "westmere";
  priority = P_AES;
}
  else

be removed?

-- 
H.J.

[PING**2] [PATCH] Fix not 8-byte aligned ldrd/strd on ARMv5

[Bernd Edlinger]

Ping...

On 2/12/19 1:32 PM, Bernd Edlinger wrote:
> Hi!
> 
> I'd like to ping for this patch:
> https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00248.html
> 
> Thanks
> Bernd.
> 
> 
> On 2/5/19 4:07 PM, Bernd Edlinger wrote:
>> Hi,
>>
>> due to the AAPCS parameter passing of 8-byte aligned structures, which 
>> happen to
>> be 8-byte aligned or only 4-byte aligned in the test case, ldrd instructions
>> are generated that may access 4-byte aligned stack slots, which will trap on 
>> ARMv5 and
>> ARMv6 according to the following document:
>>
>>
>> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0473m/dom1361290002364.html
>> says:
>>
>> "In ARMv5TE, or in ARMv6 when SCTLR.U is 0, LDRD and STRD doubleword data 
>> transfers must be
>> eight-byte aligned.  Use ALIGN 8 before memory allocation directives such as 
>> DCQ if the data
>> is to be accessed using LDRD or STRD.  This is not required in ARMv6 when 
>> SCTLR.U is 1, or in
>> ARMv7, because in these versions, doubleword data transfers can be 
>> word-aligned."
>>
>>
>> The reason why the ldrd instruction is generated seems to be a missing 
>> alignment check in the
>> function output_move_double.  But when that is fixed, it turns out that if 
>> the parameter happens
>> to be 8-byte aligned by chance, they still have MEM_ALIGN = 4, which 
>> prevents the ldrd completely.
>>
>> The reason for that is in function.c (assign_parm_find_stack_rtl), where 
>> values that happen to be
>> aligned to STACK_BOUNDARY, are only  aligned to PARM_BOUNDARY.
>>
>>
>> Bootstrapped and reg-tested on x86_64-pc-linux-gnu and arm-linux-gnueabihf 
>> with all languages.
>> Is it OK for trunk?
>>
>>
>> Thanks
>> Bernd.
>>

Re: PING [PATCH] fix ICE in __builtin_has_attribute (PR 88383 and 89288)

[Marek Polacek]

On Thu, Feb 21, 2019 at 03:39:21PM -0700, Martin Sebor wrote:
> On 2/21/19 1:27 PM, Jeff Law wrote:
> > On 2/21/19 1:12 PM, Martin Sebor wrote:
> > > On 2/21/19 12:08 PM, Jeff Law wrote:
> > > > On 2/18/19 7:53 PM, Martin Sebor wrote:
> > > > > Please let me know what it will take to get the fix for these two
> > > > > issues approved.  I've answered the questions so I don't know what
> > > > > else I'm expected to do here.
> > > > > 
> > > > >     https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00793.html
> > > > I think there is still a fundamental disagreement about whether or not
> > > > this should be handling expressions.  Without an agreement on that it's
> > > > hard to see how this could go forward.
> > > 
> > > I think it's wrong to hold up a fix for an ICE because you don't
> > > like the current design.  The built-in successfully handles common
> > > expressions (see c-c++-common/builtin-has-attribute-5.c).  It just
> > > fails for some of the less common ones.  Not fixing those will only
> > > penalize users who run into the ICE, and cast a bad light on
> > > the quality of the release.   Any design questions should be
> > > settled separately of these ICEs (should have been when
> > > the feature was being reviewed).
> > > 
> > > That said, I have explained the rationale for the current design.
> > > Neither you nor Jakub has explained what you find wrong with it or
> > > why either of your alternatives is preferable.  You said it should
> > > be an error to apply the built-in to expressions (why?).  Jakub
> > > thought there perhaps should be two built-ins, one for expressions
> > > and another for decls.  His rationale?  The current design is not
> > > good.  Clearly,  the two of you don't agree on what you'd like to
> > > see; the only thing you agree on is that you don't like what's
> > > there now.  What do you expect me to do with that, now at the end
> > > of stage 4?
> > Fix the ice in another way.  Handling expressions here seems
> > fundamentally wrong.  ISTM that making this query on an expression
> > should result in an immediate error.
> 
> Sorry but "it seems wrong" is not a compelling argument.  You need
> to explain what you think is wrong with it.

"Attributes apply to decls and types, not expressions" seems like an
argument strong enough.  (There are also special attributes for enums
 and ';' and labels.)

> The built-in is modeled on the sizeof, alignof, and typeof operators.
> The manual documents like this:
> 
>   bool __builtin_has_attribute (type-or-expression, attribute)
> 
>   ...The type-or-expression argument is subject to the same
>   restrictions as the argument to typeof (see Typeof).
> 
> It was reviewed and approved with no objections to the API.  So it
> seems that it's up to you to provide a convincing argument that this
> was the wrong choice.  What serious problems do you think it might
> cause that justify rejecting expressions, and how will users overcome
> this limitation?
> 
> I already explained the rationale behind the decision to have
> the built-in accept expressions: to be able to easily query for
> type attributes in expressions such as:
> 
>   typedef __attribute__ ((may_alias)) int* BadInt;
> 
>   void f (BadInt *p)
>   {
> _Static_assert (__builtin_has_attribute (*p, may_alias));
>   }
> 
> or
> 
>   struct S {
> int a[1] __attribute__ ((packed));
>   };
> 
>   void f (struct S *p)
>   {
> _Static_assert (__builtin_has_attribute (p->a, packed));
>   }
> 
> or even
> 
> _Static_assert (__builtin_has_attribute (p->a[0], packed));
> 
> If the built-in rejects expressions, I don't see how one would
> query for these properties.

So how about __builtin_has_attribute (typeof (p->a), packed)?

Trying to query/set attributes on things like "1 + 1" just doesn't make any
sense.  So why don't we handle TYPE_P/DECL_P and give an error for the rest?

Marek

[committed] [rtl-optimization/87761] Partial fix by improving ability to generate exts instructions

[Jeff Law]

This mips.md fixes part of 87761.  Specifically the failures for
octeon-exts-3.

There's roughly two ways to address the octeon-exts-3 issue.

One is to recognize that (set (dest) (ashiftrt (truncate (shift ...
is really just a bitfield extraction.  This is fairly easily done in
make_field_assignment.   The field starts at the outer shift constant
less the inner shift constant.  Its length is the size of the outer mode
less the outer shift constant.  The outer shift constant must be >= the
inner shift constant.

I originally preferred this approach as I expected it be a fairly
generic improvement.  As it turns out generation of the truncate in this
context is really only going to happen on targets that do not have noop
truncation -- mips, gcn, spe and one other minor target IIRC from my
investigations.  It's really a pretty narrow set of targets.

Additionally, even within that target set it's fairly difficult to
trigger outside the test -- even with a toolchain configured with all
the right defaults I only see a few generated in libgcc -- and it's
likely just one instance appearing across multilibs.

With such a narrow improvement profile I figured it was just safer to
attack in mips.md.  That way if by some chance I mucked it up it would
only affect mips.  So that's precisely what this patch does  with a new
mips.md pattern.

I've run the gcc.target/mips/mips.exp tests before/after, the only
changes are that octeon-exts-3.c now pass (using a compiler that
defaulted to abi=64).  I've also built mips64-linux-gnu (compiler,
glibc, kernel) and mips64el-linux-gnu (compiler, glibc, kernel) and
bootstrapped mips32r2-linux-gnu.  I doubt those builds actually test
this code though since I think they use the wrong ABI to trigger this
pattern.


I'm installing this on the trunk momentarily.

Jeff


diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 42ed0dca5b0..edaf84416c2 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,9 @@
+2019-02-22  Jeff Law  
+
+   PR rtl-optimization/87761
+   * config/mips/mips.md: Add new combiner pattern to recognize
+   a bitfield extraction using (ashiftrt (truncate (ashift (....
+
 2019-02-22  Martin Sebor  
 
PR c/89425
diff --git a/gcc/config/mips/mips.md b/gcc/config/mips/mips.md
index 25e0df218be..2ae1f7e0440 100644
--- a/gcc/config/mips/mips.md
+++ b/gcc/config/mips/mips.md
@@ -3502,6 +3502,47 @@
   "exts\t%0,%1,%2,31"
   [(set_attr "type" "arith")
(set_attr "mode" "")])
+
+;; This could likely be generalized for any SUBDI mode, and any right
+;; shift, but AFAICT this is used so rarely it is not worth the additional
+;; complexity.
+(define_insn ""
+  [(set (match_operand:SI 0 "register_operand" "=d")
+(ashiftrt:SI
+ (truncate:SI
+   (ashift:DI (match_operand:DI 1 "register_operand" "d")
+  (match_operand:DI 2 "const_arith_operand" "")))
+ (match_operand:DI 3 "const_arith_operand" "")))]
+  "(ISA_HAS_EXTS && TARGET_64BIT
+&& UINTVAL (operands[2]) < 32 && UINTVAL (operands[3]) < 32
+&& UINTVAL (operands[3]) >= UINTVAL (operands[2]))"
+  {
+rtx xoperands[4];
+xoperands[0] = operands[0];
+xoperands[1] = operands[1];
+
+/* The length of the field is the size of the outer mode less the outer
+   shift constant.  We fix the outer mode as SImode for simplicity.  */
+unsigned int right_shift = INTVAL (operands[3]);
+xoperands[3] = GEN_INT (32 - right_shift);
+
+/* The field starts at the outer shift constant less the inner shift
+   constant.  */
+unsigned int left_shift = INTVAL (operands[2]);
+xoperands[2] = GEN_INT (right_shift - left_shift);
+
+/* Sanity checks.  These constraints are taken from the MIPS ISA
+   manual.  */
+gcc_assert (INTVAL (xoperands[2]) >= 0 && INTVAL (xoperands[2]) < 32);
+gcc_assert (INTVAL (xoperands[3]) > 0 && INTVAL (xoperands[3]) <= 32);
+gcc_assert (INTVAL (xoperands[2]) + INTVAL (xoperands[3]) > 0
+   && INTVAL (xoperands[2]) + INTVAL (xoperands[3]) <= 32);
+
+output_asm_insn ("exts\t%0,%1,%2,%m3", xoperands);
+return "";
+  }
+  [(set_attr "type" "arith")
+   (set_attr "mode" "SI")])
 
 ;;
 ;;  

[PATCH] i386: Properly encode xmm16-xmm31/ymm16-ymm31 for vector move

[H.J. Lu]

Hi Jan, Uros,

This patch fixes the wrong code bug:

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

Tested on AVX2 and AVX512 with and without --with-arch=native.

OK for trunk?

Thanks.

H.J.
--
i386 backend has

INT_MODE (OI, 32);
INT_MODE (XI, 64);

So, XI_MODE represents 64 INTEGER bytes = 64 * 8 = 512 bit operation,
in case of const_1, all 512 bits set.

We can load zeros with narrower instruction, (e.g. 256 bit by inherent
zeroing of highpart in case of 128 bit xor), so TImode in this case.

Some targets prefer V4SF mode, so they will emit float xorps for zeroing.

sse.md has

(define_insn "mov_internal"
  [(set (match_operand:VMOVE 0 "nonimmediate_operand"
 "=v,v ,v ,m")
(match_operand:VMOVE 1 "nonimmediate_or_sse_const_operand"
 " C,BC,vm,v"))]

  /* There is no evex-encoded vmov* for sizes smaller than 64-bytes
 in avx512f, so we need to use workarounds, to access sse registers
 16-31, which are evex-only. In avx512vl we don't need workarounds.  */
  if (TARGET_AVX512F &&  < 64 && !TARGET_AVX512VL
  && (EXT_REX_SSE_REG_P (operands[0])
  || EXT_REX_SSE_REG_P (operands[1])))
{
  if (memory_operand (operands[0], mode))
{
  if ( == 32)
return "vextract64x4\t{$0x0, %g1, %0|%0, %g1, 
0x0}";
  else if ( == 16)
return "vextract32x4\t{$0x0, %g1, %0|%0, %g1, 
0x0}";
  else
gcc_unreachable ();
}
...

However, since ix86_hard_regno_mode_ok has

 /* TODO check for QI/HI scalars.  */
  /* AVX512VL allows sse regs16+ for 128/256 bit modes.  */
  if (TARGET_AVX512VL
  && (mode == OImode
  || mode == TImode
  || VALID_AVX256_REG_MODE (mode)
  || VALID_AVX512VL_128_REG_MODE (mode)))
return true;

  /* xmm16-xmm31 are only available for AVX-512.  */
  if (EXT_REX_SSE_REGNO_P (regno))
return false;

  if (TARGET_AVX512F &&  < 64 && !TARGET_AVX512VL
  && (EXT_REX_SSE_REG_P (operands[0])
  || EXT_REX_SSE_REG_P (operands[1])))

is a dead code.

Also for

long long *p;
volatile __m256i yy;

void
foo (void)
{
   _mm256_store_epi64 (p, yy);
}

with AVX512VL, we should generate

vmovdqa %ymm0, (%rax)

not

vmovdqa64   %ymm0, (%rax)

All TYPE_SSEMOV vector moves are consolidated to ix86_output_ssemov:

1. If xmm16-xmm31/ymm16-ymm31 registers aren't used, SSE/AVX vector
moves will be generated.
2. If xmm16-xmm31/ymm16-ymm31 registers are used:
   a. With AVX512VL, AVX512VL vector moves will be generated.
   b. Without AVX512VL, xmm16-xmm31/ymm16-ymm31 register to register
  move will be done with zmm register move.

ext_sse_reg_operand is removed since it is no longer needed.

Tested on AVX2 and AVX512 with and without --with-arch=native.

gcc/

PR target/89229
PR target/89346
* config/i386/i386-protos.h (ix86_output_ssemov): New prototype.
* config/i386/i386.c (ix86_get_ssemov): New function.
(ix86_output_ssemov): Likewise.
* config/i386/i386.md (*movxi_internal_avx512f): Call
ix86_output_ssemov for TYPE_SSEMOV.
(*movoi_internal_avx): Call ix86_output_ssemov for TYPE_SSEMOV.
Remove ext_sse_reg_operand and TARGET_AVX512VL check.
(*movti_internal): Likewise.
(*movdi_internal): Call ix86_output_ssemov for TYPE_SSEMOV.
Remove ext_sse_reg_operand check.
(*movsi_internal): Likewise.
(*movtf_internal): Call ix86_output_ssemov for TYPE_SSEMOV.
(*movdf_internal): Call ix86_output_ssemov for TYPE_SSEMOV.
Remove TARGET_AVX512F, TARGET_PREFER_AVX256, TARGET_AVX512VL
and ext_sse_reg_operand check.
(*movsf_internal_avx): Call ix86_output_ssemov for TYPE_SSEMOV.
Remove TARGET_PREFER_AVX256, TARGET_AVX512VL and
ext_sse_reg_operand check.
* config/i386/mmx.md (MMXMODE:*mov_internal): Call
ix86_output_ssemov for TYPE_SSEMOV.  Remove ext_sse_reg_operand
check.
* config/i386/sse.md (VMOVE:mov_internal): Call
ix86_output_ssemov for TYPE_SSEMOV.  Remove TARGET_AVX512VL
check.
* config/i386/predicates.md (ext_sse_reg_operand): Removed.

gcc/testsuite/

PR target/89229
PR target/89346
* gcc.target/i386/avx512vl-vmovdqa64-1.c: Updated.
* gcc.target/i386/pr89229-2a.c: New test.
* gcc.target/i386/pr89229-2b.c: Likewise.
* gcc.target/i386/pr89229-2c.c: Likewise.
* gcc.target/i386/pr89229-3a.c: Likewise.
* gcc.target/i386/pr89229-3b.c: Likewise.
* gcc.target/i386/pr89229-3c.c: Likewise.
* gcc.target/i386/pr89229-4a.c: Likewise.
* gcc.target/i386/pr89229-4b.c: Likewise.
* gcc.target/i386/pr89229-4c.c: Likewise.
* gcc.target/i386/pr89229-5a.c: Likewise.
* gcc.target/i386/pr89229-5b.c: Likewise.

Re: [Patch] [aarch64] PR target/89324 Handle stack pointer for SUBS/ADDS instructions

[James Greenhalgh]

On Fri, Feb 22, 2019 at 09:39:59AM -0600, Matthew Malcomson wrote:
> Hi James,
> 
> On 22/02/19 00:09, James Greenhalgh wrote:
> > On Mon, Feb 18, 2019 at 08:40:12AM -0600, Matthew Malcomson wrote:
> >>
> >> Additionally, this patch contains two tidy-ups (happy to remove them or 
> >> put in
> >> a separate patch if people want):
> > 
> > Generally, yes I prefer that.
> > 
> 
> I've removed the tidy ups and retested -- modified patch attached.
> 
> >>
> >> OK for trunk?
> > 
> > This patch is fine for GCC 10, so not on trunk yet please unless there is
> > a corectness reason for the change.
> > 
> 
> The patch is a correctness change to fix the P1 regression that occurs 
> when the stack pointer was passed to the define_insn from the 
> define_peephole2.
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89324
> 
> Ok for trunk?

Yes, please.

Thanks,
James

Re: C++ PATCH for c++/89420 - ICE with CAST_EXPR in explicit-specifier

[Marek Polacek]

On Thu, Feb 21, 2019 at 03:47:44PM -1000, Jason Merrill wrote:
> On 2/21/19 1:35 PM, Marek Polacek wrote:
> > We were ICEing because we called build_converted_constant_expr on an 
> > expression
> > that wasn't value-dependent, but it still contained template codes, and that
> > didn't work too well because check_narrowing calls maybe_constant_value.
> 
> Hmm, I'm concerned about convert_like_real from
> build_converted_constant_expr adding more template codes; you probably want
> a processing_template_decl_sentinel after the
> instantiate_non_dependent_expr.

OK, that's a good trick.

> Also, value_dependent_expression_p should probably be
> instantiation_dependent_expression_p.

I think I used value_* because that's what build_noexcept_spec had.  Also
value_dependent_expression_p calls type_dependent_expression_p.  But I've
changed it anyway.  Thanks,

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

2019-02-22  Marek Polacek  

PR c++/89420 - ICE with CAST_EXPR in explicit-specifier.
* decl.c (build_explicit_specifier): Don't check
processing_template_decl.  Call instantiation_dependent_expression_p
instead of value_dependent_expression_p.  Call
instantiate_non_dependent_expr_sfinae before
build_converted_constant_expr instead of calling
instantiate_non_dependent_expr after it.  Add
processing_template_decl_sentinel.

* g++.dg/cpp2a/explicit14.C: New test.

diff --git gcc/cp/decl.c gcc/cp/decl.c
index 612afbacd27..c5b5bd3ce08 100644
--- gcc/cp/decl.c
+++ gcc/cp/decl.c
@@ -16687,12 +16687,14 @@ require_deduced_type (tree decl, tsubst_flags_t 
complain)
 tree
 build_explicit_specifier (tree expr, tsubst_flags_t complain)
 {
-  if (processing_template_decl && value_dependent_expression_p (expr))
+  if (instantiation_dependent_expression_p (expr))
 /* Wait for instantiation, tsubst_function_decl will handle it.  */
 return expr;
 
+  expr = instantiate_non_dependent_expr_sfinae (expr, complain);
+  /* Don't let convert_like_real create more template codes.  */
+  processing_template_decl_sentinel s;
   expr = build_converted_constant_expr (boolean_type_node, expr, complain);
-  expr = instantiate_non_dependent_expr (expr);
   expr = cxx_constant_value (expr);
   return expr;
 }
diff --git gcc/testsuite/g++.dg/cpp2a/explicit14.C 
gcc/testsuite/g++.dg/cpp2a/explicit14.C
new file mode 100644
index 000..9c3acc32ac4
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp2a/explicit14.C
@@ -0,0 +1,11 @@
+// PR c++/89420
+// { dg-do compile { target c++2a } }
+
+template
+struct S {
+  explicit(int(1)) S(int);
+  explicit(int{1}) S(int, int);
+};
+
+S s(1);
+S s2(1, 2);

Re: [Patch] [aarch64] PR target/89324 Handle stack pointer for SUBS/ADDS instructions

[Matthew Malcomson]

Hi James,

On 22/02/19 00:09, James Greenhalgh wrote:
> On Mon, Feb 18, 2019 at 08:40:12AM -0600, Matthew Malcomson wrote:
>>
>> Additionally, this patch contains two tidy-ups (happy to remove them or put 
>> in
>> a separate patch if people want):
> 
> Generally, yes I prefer that.
> 

I've removed the tidy ups and retested -- modified patch attached.

>>
>> OK for trunk?
> 
> This patch is fine for GCC 10, so not on trunk yet please unless there is
> a corectness reason for the change.
> 

The patch is a correctness change to fix the P1 regression that occurs 
when the stack pointer was passed to the define_insn from the 
define_peephole2.

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

Ok for trunk?

Regards,
Matthew
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index b7f6fe0f1354f7aa19076a946ed2c633b9b9b8da..b7cd9fc787b8526cc7b11b9430fbfcd73103328a 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -1985,7 +1985,7 @@ (define_expand "uaddvti4"
 (define_insn "add3_compare0"
   [(set (reg:CC_NZ CC_REGNUM)
 	(compare:CC_NZ
-	 (plus:GPI (match_operand:GPI 1 "register_operand" "%r,r,r")
+	 (plus:GPI (match_operand:GPI 1 "register_operand" "%rk,rk,rk")
 		   (match_operand:GPI 2 "aarch64_plus_operand" "r,I,J"))
 	 (const_int 0)))
(set (match_operand:GPI 0 "register_operand" "=r,r,r")
@@ -2002,7 +2002,7 @@ (define_insn "add3_compare0"
 (define_insn "*addsi3_compare0_uxtw"
   [(set (reg:CC_NZ CC_REGNUM)
 	(compare:CC_NZ
-	 (plus:SI (match_operand:SI 1 "register_operand" "%r,r,r")
+	 (plus:SI (match_operand:SI 1 "register_operand" "%rk,rk,rk")
 		  (match_operand:SI 2 "aarch64_plus_operand" "r,I,J"))
 	 (const_int 0)))
(set (match_operand:DI 0 "register_operand" "=r,r,r")
@@ -2034,7 +2034,7 @@ (define_insn "add3_compareC"
   [(set (reg:CC_C CC_REGNUM)
 	(compare:CC_C
 	  (plus:GPI
-	(match_operand:GPI 1 "register_operand" "r,r,r")
+	(match_operand:GPI 1 "register_operand" "rk,rk,rk")
 	(match_operand:GPI 2 "aarch64_plus_operand" "r,I,J"))
 	  (match_dup 1)))
(set (match_operand:GPI 0 "register_operand" "=r,r,r")
@@ -2081,7 +2081,7 @@ (define_insn "add3_compareV_imm"
 	(compare:CC_V
 	  (plus:
 	(sign_extend:
-	  (match_operand:GPI 1 "register_operand" "r,r"))
+	  (match_operand:GPI 1 "register_operand" "rk,rk"))
 	(match_operand:GPI 2 "aarch64_plus_immediate" "I,J"))
 	  (sign_extend:
 	(plus:GPI (match_dup 1) (match_dup 2)
@@ -2098,7 +2098,7 @@ (define_insn "add3_compareV"
   [(set (reg:CC_V CC_REGNUM)
 	(compare:CC_V
 	  (plus:
-	(sign_extend: (match_operand:GPI 1 "register_operand" "r"))
+	(sign_extend: (match_operand:GPI 1 "register_operand" "rk"))
 	(sign_extend: (match_operand:GPI 2 "register_operand" "r")))
 	  (sign_extend: (plus:GPI (match_dup 1) (match_dup 2)
(set (match_operand:GPI 0 "register_operand" "=r")
@@ -2177,7 +2177,7 @@ (define_insn "*adds__"
 	(compare:CC_NZ
 	 (plus:GPI
 	  (ANY_EXTEND:GPI (match_operand:ALLX 1 "register_operand" "r"))
-	  (match_operand:GPI 2 "register_operand" "r"))
+	  (match_operand:GPI 2 "register_operand" "rk"))
 	(const_int 0)))
(set (match_operand:GPI 0 "register_operand" "=r")
 	(plus:GPI (ANY_EXTEND:GPI (match_dup 1)) (match_dup 2)))]
@@ -2189,7 +2189,7 @@ (define_insn "*adds__"
 (define_insn "*subs__"
   [(set (reg:CC_NZ CC_REGNUM)
 	(compare:CC_NZ
-	 (minus:GPI (match_operand:GPI 1 "register_operand" "r")
+	 (minus:GPI (match_operand:GPI 1 "register_operand" "rk")
 		(ANY_EXTEND:GPI
 		 (match_operand:ALLX 2 "register_operand" "r")))
 	(const_int 0)))
@@ -2207,7 +2207,7 @@ (define_insn "*adds__shift_"
 		(ANY_EXTEND:GPI 
 		 (match_operand:ALLX 1 "register_operand" "r"))
 		(match_operand 2 "aarch64_imm3" "Ui3"))
-		   (match_operand:GPI 3 "register_operand" "r"))
+		   (match_operand:GPI 3 "register_operand" "rk"))
 	 (const_int 0)))
(set (match_operand:GPI 0 "register_operand" "=rk")
 	(plus:GPI (ashift:GPI (ANY_EXTEND:GPI (match_dup 1))
@@ -2221,7 +2221,7 @@ (define_insn "*adds__shift_"
 (define_insn "*subs__shift_"
   [(set (reg:CC_NZ CC_REGNUM)
 	(compare:CC_NZ
-	 (minus:GPI (match_operand:GPI 1 "register_operand" "r")
+	 (minus:GPI (match_operand:GPI 1 "register_operand" "rk")
 		(ashift:GPI 
 		 (ANY_EXTEND:GPI
 		  (match_operand:ALLX 2 "register_operand" "r"))
@@ -2244,7 +2244,7 @@ (define_insn "*adds__multp2"
 			  (match_operand 2 "aarch64_pwr_imm3" "Up3"))
 		(match_operand 3 "const_int_operand" "n")
 		(const_int 0))
-		   (match_operand:GPI 4 "register_operand" "r"))
+		   (match_operand:GPI 4 "register_operand" "rk"))
 	(const_int 0)))
(set (match_operand:GPI 0 "register_operand" "=r")
 	(plus:GPI (ANY_EXTRACT:GPI (mult:GPI (match_dup 1) (match_dup 2))
@@ -2259,7 +2259,7 @@ (define_insn "*adds__multp2"
 (define_insn "*subs__multp2"
   [(set (reg:CC_NZ CC_REGNUM)
 	(compare:CC_NZ
-	 (minus:GPI (match_operand:GPI 4 "register_operand" "r")
+	 (minus:GPI 

Re: [committed] Fix -Wmissing-attributes warning in libstdc++ (PR libstdc++/89402)

[Martin Sebor]

On 2/21/19 6:10 PM, Jonathan Wakely wrote:

On 20/02/19 09:07 +0100, Jakub Jelinek wrote:

Hi!

The following patch fixes a warning when building on targets where long
double switched from being the same as double to something wider,
like e.g. powerpc*-linux, alpha*-linux, s390*-linux etc.

Fixed thusly, bootstrapped/regtested on {x86_64,i686,s390x}-linux and
bootstrapped on powerpc64le-linux, on both s390x and powerpc64le it 
removed

all
../../../../libstdc++-v3/src/c++98/compatibility-ldbl.cc:77:17: 
warning: 'void _ZNKSt4hashIeEclEe()' specifies less restrictive 
attribute than its target 'std::size_t 
std::tr1::hash<_Tp>::operator()(_Tp) const [with _Tp = long double]': 
'pure' [-Wmissing-attributes]
warnings from the build log.  Preapproved by Jonathan in the PR, 
committed

to trunk.


Now I see:

/home/jwakely/src/gcc/libstdc++-v3/src/c++98/compatibility-ldbl.cc:78:65: warning: 
‘pure’ attribute on function returning ‘void’ [-Wattributes]

   78 |   _GLIBCXX_PURE __attribute__((alias ("_ZNKSt3tr14hashIeEclEe")));
  | ^


Are the attributes on this alias ever considered in calls to it?
If not (and assuming there's a way to tell, which I think there
should be but haven't verified it) the warning could be relaxed
to only trigger for those that are.  I think those would be
either aliases declared in headers, or those with the TREE_USED
bit set.

Martin



We can disable that with a diagnostic pragma.




2019-02-20  Jakub Jelinek  

PR libstdc++/89402
* src/c++98/compatibility-ldbl.cc (_ZNKSt4hashIeEclEe): Add
_GLIBCXX_PURE to the alias declaration.

--- libstdc++-v3/src/c++98/compatibility-ldbl.cc.jj    2019-01-01 
12:39:41.530606161 +0100
+++ libstdc++-v3/src/c++98/compatibility-ldbl.cc    2019-02-19 
16:12:52.402123217 +0100

@@ -75,6 +75,6 @@ namespace std _GLIBCXX_VISIBILITY(defaul
// and std::hash::operator()
// are the same, no need to duplicate them.
extern "C" void _ZNKSt4hashIeEclEe (void)
-  __attribute__((alias ("_ZNKSt3tr14hashIeEclEe")));
+  _GLIBCXX_PURE __attribute__((alias ("_ZNKSt3tr14hashIeEclEe")));

#endif


Jakub

Re: [PATCH] Fix a test (PR testsuite/89441).

[John David Anglin]

Hi Martin,

On 2019-02-22 5:21 a.m., Martin Liška wrote:
> Hi.
> 
> This patch makes main not hidden (as reported in the PR).
> John: Can you verify it fixes your problem on hppa64-hp-hpux11.11 target?
Your patch fixed the problem on the hppa64-hp-hpux11.11 target but we also need 
to
require visibility support on 32-bit hppa-hpux.  See attached.

Dave
-- 
John David Anglin  dave.ang...@bell.net
Index: gcc/testsuite/g++.dg/ipa/pr89009.C
===
--- gcc/testsuite/g++.dg/ipa/pr89009.C  (revision 268997)
+++ gcc/testsuite/g++.dg/ipa/pr89009.C  (working copy)
@@ -1,11 +1,12 @@
 /* PR ipa/89009 */
 /* { dg-do run } */
-/* { dg-options "-fvisibility=hidden -fpic -O2 -fno-inline" } */
+/* { dg-options "-fpic -O2 -fno-inline" } */
+/* { dg-require-visibility "" } */
 
-#pragma GCC visibility push(default)
 void foo1() { __builtin_printf ("foo\n"); }
+#pragma GCC visibility push(hidden)
+void foo2() { __builtin_printf ("foo\n"); }
 #pragma GCC visibility pop
-void foo2() { __builtin_printf ("foo\n"); }
 
 int main() { foo2(); return 0; }
 

Re: [PR middle-end/85598] make -Wprintf* pass use loop info for PHI's

[Aldy Hernandez]

On 2/22/19 7:34 AM, Jakub Jelinek wrote:

On Fri, Feb 22, 2019 at 01:24:38PM +0100, Richard Biener wrote:

I believe the flag_printf_return_value change was the final agreed upon
solution.

Tested on x86-64 Linux.

OK for trunk?


OK.


Just a nit, could you please s/optimizing_late/use_scev/ or something
similar?  With the flag_printf_* in there, it isn't really about optimizing
late, but whether we do or don't want to use scev.


Done.  Committed.

Re: [PATCH] Minimum version of mpfr? (was Re: [PATCH] Fix up norm2 simplification (PR middle-end/88074)), take 2

[Richard Biener]

On Fri, 22 Feb 2019, Jakub Jelinek wrote:

> On Thu, Feb 21, 2019 at 04:50:27PM -0500, David Malcolm wrote:
> > gcc/fortran/ChangeLog:
> > PR middle-end/88074
> > * simplify.c (norm2_add_squared): Use mp_exp_t rather than
> > mpfr_exp_t.
> 
> I have discussed this with Richard on IRC earlier today, there is another
> issue that mpfr_regular_p is only 3.0 and later.  And he prefers that
> mp_exp_t over say
> #if MPFR_VERSION < MPFR_VERSION_NUM(3,0,0)
> typedef mp_exp_t mpfr_exp_t;
> #endif
> 
> So, here is the full patch I'll bootstrap/regtest soon:

OK if it passes.

Apart from autotesters where some of ours run very old outdated systems...
for SLES 12 which I think is the oldest relevant distro I'd like to
see newer GCCs to work on we have mpfr 3.1.2 and gmp 5.1.3 just in
case we might finally consider bumping the minimum required versions
at some point.  Though I didn't yet see any technical reason to do so,
we have more "issues" supporting old host GCC versions (SLE12 uses
GCC 4.8 so that would be a considerable bump already).

Richard.

> 2019-02-22  David Malcolm  
>   Jakub Jelinek  
> 
>   PR middle-end/88074
>   * simplify.c (norm2_do_sqrt, gfc_simplify_norm2): Use
>   mpfr_number_p && !mpfr_zero_p instead of mpfr_regular_p.
>   (norm2_add_squared): Likewise.  Use mp_exp_t rather than mpfr_exp_t.
> 
> --- gcc/fortran/simplify.c.jj 2019-02-21 22:20:07.272388243 +0100
> +++ gcc/fortran/simplify.c2019-02-22 11:07:36.093374586 +0100
> @@ -6061,8 +6061,8 @@ norm2_add_squared (gfc_expr *result, gfc
>  
>gfc_set_model_kind (result->ts.kind);
>int index = gfc_validate_kind (BT_REAL, result->ts.kind, false);
> -  mpfr_exp_t exp;
> -  if (mpfr_regular_p (result->value.real))
> +  mp_exp_t exp;
> +  if (mpfr_number_p (result->value.real) && !mpfr_zero_p 
> (result->value.real))
>  {
>exp = mpfr_get_exp (result->value.real);
>/* If result is getting close to overflowing, scale down.  */
> @@ -6076,7 +6076,7 @@ norm2_add_squared (gfc_expr *result, gfc
>  }
>  
>mpfr_init (tmp);
> -  if (mpfr_regular_p (e->value.real))
> +  if (mpfr_number_p (e->value.real) && !mpfr_zero_p (e->value.real))
>  {
>exp = mpfr_get_exp (e->value.real);
>/* If e**2 would overflow or close to overflowing, scale down.  */
> @@ -6117,7 +6117,9 @@ norm2_do_sqrt (gfc_expr *result, gfc_exp
>if (result != e)
>  mpfr_set (result->value.real, e->value.real, GFC_RND_MODE);
>mpfr_sqrt (result->value.real, result->value.real, GFC_RND_MODE);
> -  if (norm2_scale && mpfr_regular_p (result->value.real))
> +  if (norm2_scale
> +  && mpfr_number_p (result->value.real)
> +  && !mpfr_zero_p (result->value.real))
>  {
>mpfr_t tmp;
>mpfr_init (tmp);
> @@ -6156,7 +6158,9 @@ gfc_simplify_norm2 (gfc_expr *e, gfc_exp
>result = simplify_transformation_to_scalar (result, e, NULL,
> norm2_add_squared);
>mpfr_sqrt (result->value.real, result->value.real, GFC_RND_MODE);
> -  if (norm2_scale && mpfr_regular_p (result->value.real))
> +  if (norm2_scale
> +   && mpfr_number_p (result->value.real)
> +   && !mpfr_zero_p (result->value.real))
>   {
> mpfr_t tmp;
> mpfr_init (tmp);
> 
>   Jakub
> 
> 

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)

[PATCH] Minimum version of mpfr? (was Re: [PATCH] Fix up norm2 simplification (PR middle-end/88074)), take 2

[Jakub Jelinek]

On Thu, Feb 21, 2019 at 04:50:27PM -0500, David Malcolm wrote:
> gcc/fortran/ChangeLog:
>   PR middle-end/88074
>   * simplify.c (norm2_add_squared): Use mp_exp_t rather than
>   mpfr_exp_t.

I have discussed this with Richard on IRC earlier today, there is another
issue that mpfr_regular_p is only 3.0 and later.  And he prefers that
mp_exp_t over say
#if MPFR_VERSION < MPFR_VERSION_NUM(3,0,0)
typedef mp_exp_t mpfr_exp_t;
#endif

So, here is the full patch I'll bootstrap/regtest soon:

2019-02-22  David Malcolm  
Jakub Jelinek  

PR middle-end/88074
* simplify.c (norm2_do_sqrt, gfc_simplify_norm2): Use
mpfr_number_p && !mpfr_zero_p instead of mpfr_regular_p.
(norm2_add_squared): Likewise.  Use mp_exp_t rather than mpfr_exp_t.

--- gcc/fortran/simplify.c.jj   2019-02-21 22:20:07.272388243 +0100
+++ gcc/fortran/simplify.c  2019-02-22 11:07:36.093374586 +0100
@@ -6061,8 +6061,8 @@ norm2_add_squared (gfc_expr *result, gfc
 
   gfc_set_model_kind (result->ts.kind);
   int index = gfc_validate_kind (BT_REAL, result->ts.kind, false);
-  mpfr_exp_t exp;
-  if (mpfr_regular_p (result->value.real))
+  mp_exp_t exp;
+  if (mpfr_number_p (result->value.real) && !mpfr_zero_p (result->value.real))
 {
   exp = mpfr_get_exp (result->value.real);
   /* If result is getting close to overflowing, scale down.  */
@@ -6076,7 +6076,7 @@ norm2_add_squared (gfc_expr *result, gfc
 }
 
   mpfr_init (tmp);
-  if (mpfr_regular_p (e->value.real))
+  if (mpfr_number_p (e->value.real) && !mpfr_zero_p (e->value.real))
 {
   exp = mpfr_get_exp (e->value.real);
   /* If e**2 would overflow or close to overflowing, scale down.  */
@@ -6117,7 +6117,9 @@ norm2_do_sqrt (gfc_expr *result, gfc_exp
   if (result != e)
 mpfr_set (result->value.real, e->value.real, GFC_RND_MODE);
   mpfr_sqrt (result->value.real, result->value.real, GFC_RND_MODE);
-  if (norm2_scale && mpfr_regular_p (result->value.real))
+  if (norm2_scale
+  && mpfr_number_p (result->value.real)
+  && !mpfr_zero_p (result->value.real))
 {
   mpfr_t tmp;
   mpfr_init (tmp);
@@ -6156,7 +6158,9 @@ gfc_simplify_norm2 (gfc_expr *e, gfc_exp
   result = simplify_transformation_to_scalar (result, e, NULL,
  norm2_add_squared);
   mpfr_sqrt (result->value.real, result->value.real, GFC_RND_MODE);
-  if (norm2_scale && mpfr_regular_p (result->value.real))
+  if (norm2_scale
+ && mpfr_number_p (result->value.real)
+ && !mpfr_zero_p (result->value.real))
{
  mpfr_t tmp;
  mpfr_init (tmp);

Jakub

Re: [committed][nvptx, libgomp] Move rtl-dump test-cases to libgomp

[Tom de Vries]

On 22-02-19 12:09, Thomas Schwinge wrote:
> There is however still a problem here: if you have more than one offload
> compiler configured, 

Ah, right, that's a configuration I'm not testing, evidently.

> all of them will react to
> '-foffload=-fdump-rtl-mach', and will overwrite their dump files, or if
> different compiler passes configured, that may produce more than one
> "mach" dump file, all this resulting in "funny" testing FAILs/ERRORs.
> But: we can't just use '-foffload=[nvptx]=-fdump-rtl-mach', because
> '[nvptx]' can be 'nvptx', or 'nvptx-none', etc.
> 
> Similar problem for a lot of other test cases that you've recently added
> (... but thanks for all these, of course!).
> 
> And, "dg-require-effective-target offload_nvptx" is now obsolete, and
> should be removed.
> 
> All this I'm addressing in the commits I've just done, see attached:

Thanks for fixing that.

- Tom

Re: [PR middle-end/85598] make -Wprintf* pass use loop info for PHI's

[Jakub Jelinek]

On Fri, Feb 22, 2019 at 01:24:38PM +0100, Richard Biener wrote:
> > I believe the flag_printf_return_value change was the final agreed upon
> > solution.
> >
> > Tested on x86-64 Linux.
> >
> > OK for trunk?
> 
> OK.

Just a nit, could you please s/optimizing_late/use_scev/ or something
similar?  With the flag_printf_* in there, it isn't really about optimizing
late, but whether we do or don't want to use scev.

Jakub

Re: [PR middle-end/85598] make -Wprintf* pass use loop info for PHI's

[Richard Biener]

On Fri, Feb 22, 2019 at 10:57 AM Aldy Hernandez  wrote:
>
> On 1/31/19 9:56 AM, Richard Biener wrote:
> > On Thu, Jan 31, 2019 at 3:45 PM Jakub Jelinek  wrote:
> >>
> >> On Thu, Jan 31, 2019 at 09:30:13AM -0500, Aldy Hernandez wrote:
> > (LOOPS_HAVE_PREHEADERS).  This avoids unnecessary changes to the CFG.
> > But really, I'm just guessing here.  LOOPS_NORMAL would also work,
> > albeit creating forwarder blocks.
> >
> > Tested on x86-64 Linux.
> >
> > What do you think?
> 
>  As far as I understand fold_return_value is true/false independent
>  of -W* flags (but dependent on -fprintf-return-value or so).  This means
>  that your patch avoids the risk of CFG changes dependent on
>  -W* flags.  This means you could safely use LOOPS_NORMAL
> >>>
> >>> But isn't my code inside of ::execute, which is still gated by
> >>> fold_return_value AND all the -W* flags:?
> >>>
> >>> bool
> >>> pass_sprintf_length::gate (function *)
> >>> {
> >>>return ((warn_format_overflow > 0
> >>>   || warn_format_trunc > 0
> >>>   || flag_printf_return_value)
> >>>  && (optimize > 0) == fold_return_value);
> >>> }
> >>>
> >>> Thus, I think we need to move the loop initialization somewhere else ??.
> >>
> >> Then perhaps turn the gate into just return (optimize > 0) == 
> >> fold_return_value;
> >> and in execute do what you're adding and guard the rest with the above
> >> condition?  As -fprintf-return-value is on by default for C-family, it 
> >> shouldn't
> >> change much.
> >> + adjust comment on the gate of course.
> >
> > Don't you alreday have
> >
> > @@ -4200,10 +4202,34 @@ pass_sprintf_length::execute (function *fun)
> > init_target_to_host_charmap ();
> >
> > calculate_dominance_info (CDI_DOMINATORS);
> > +  bool optimizing_late = optimize > 0 && fold_return_value;
> > +  if (optimizing_late)
> > +{
> > +  /* ?? We should avoid changing the CFG as much as possible.
> > ...
> > +  loop_optimizer_init (LOOPS_HAVE_PREHEADERS);
> > +  scev_initialize ();
> > +}
> >
> > so loops are only initialized if fold_return_value is true?  Ah - but that's
> > the pass parameter from params.def rather than the flag to enable
> > the folding...  So indeed, change it to include && flag_printf_return_value
>
> I believe the flag_printf_return_value change was the final agreed upon
> solution.
>
> Tested on x86-64 Linux.
>
> OK for trunk?

OK.

Richard.

[PATCH][3/2] Fix PR87609

[Richard Biener]

And I forgot to update the copying to not copy non-inlined cliques...

Bootstrap / regtest running on x86_64-unknown-linux-gnu.

Richard.

2019-02-22  Richard Biener  

PR tree-optimization/87609
* tree-cfg.c (gimple_duplicate_bb): Only remap inlined cliques.

Index: gcc/tree-cfg.c
===
--- gcc/tree-cfg.c  (revision 269111)
+++ gcc/tree-cfg.c  (working copy)
@@ -6229,6 +6229,8 @@ gimple_duplicate_bb (basic_block bb, cop
DECL_NONSHAREABLE (base) = 1;
}
  
+  /* If requested remap dependence info of cliques brought in
+ via inlining.  */
   if (id)
for (unsigned i = 0; i < gimple_num_ops (copy); ++i)
  {
@@ -6242,7 +6244,7 @@ gimple_duplicate_bb (basic_block bb, cop
  op = TREE_OPERAND (op, 0);
if ((TREE_CODE (op) == MEM_REF
 || TREE_CODE (op) == TARGET_MEM_REF)
-   && MR_DEPENDENCE_CLIQUE (op) != 0)
+   && MR_DEPENDENCE_CLIQUE (op) > 1)
  {
if (!id->dependence_map)
  id->dependence_map = new hash_map

PR89433 "Repeated use of the OpenACC 'routine' directive"

[Thomas Schwinge]

Hi!

To resolve PR89433 "Repeated use of the OpenACC 'routine' directive" at
least for C/C++, I intend to push the attached patches in next GCC
development stage 1 (unless that should be addressed right now, and also
on other GCC release branches?).

The corresponding Fortran changes will require additional effort.


Grüße
 Thomas


>From 15a0bacff7c75891ceb11a81112b48114c7014a4 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Thu, 21 Feb 2019 15:52:20 +0100
Subject: [PATCH 1/3] Refer to OpenACC 'routine' clauses from "omp declare
 target" attribute

TODO
	gcc/c-family/
	* c-attribs.c (c_common_attribute_table): Set min_len to -1 for
	"omp declare target".
	gcc/c/
	* c-parser.c (c_finish_oacc_routine): Refer to OpenACC 'routine'
	clauses from "omp declare target" attribute.
	gcc/cp/
	* parser.c (cp_finalize_oacc_routine): Refer to OpenACC 'routine'
	clauses from "omp declare target" attribute.
	gcc/testsuite/
	* c-c++-common/goacc/classify-routine.c: Update.
---
 gcc/c-family/c-attribs.c   |  2 +-
 gcc/c/c-parser.c   |  2 +-
 gcc/cp/parser.c|  2 +-
 gcc/fortran/f95-lang.c |  2 +-
 gcc/fortran/trans-decl.c   | 18 +++---
 .../c-c++-common/goacc/classify-routine.c  |  4 ++--
 .../gfortran.dg/goacc/classify-routine.f95 |  4 ++--
 7 files changed, 19 insertions(+), 15 deletions(-)

diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c
index 20584593c6a..f108ce6ca6a 100644
--- a/gcc/c-family/c-attribs.c
+++ b/gcc/c-family/c-attribs.c
@@ -437,7 +437,7 @@ const struct attribute_spec c_common_attribute_table[] =
 			  handle_omp_declare_simd_attribute, NULL },
   { "simd",		  0, 1, true,  false, false, false,
 			  handle_simd_attribute, NULL },
-  { "omp declare target", 0, 0, true, false, false, false,
+  { "omp declare target", 0, -1, true, false, false, false,
 			  handle_omp_declare_target_attribute, NULL },
   { "omp declare target link", 0, 0, true, false, false, false,
 			  handle_omp_declare_target_attribute, NULL },
diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index 22c7416ac94..c8110faa948 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -15882,7 +15882,7 @@ c_finish_oacc_routine (struct oacc_routine_data *data, tree fndecl,
   /* Add an "omp declare target" attribute.  */
   DECL_ATTRIBUTES (fndecl)
 = tree_cons (get_identifier ("omp declare target"),
-		 NULL_TREE, DECL_ATTRIBUTES (fndecl));
+		 data->clauses, DECL_ATTRIBUTES (fndecl));
 
   /* Remember that we've used this "#pragma acc routine".  */
   data->fndecl_seen = true;
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 545047c91af..418cc507822 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -40181,7 +40181,7 @@ cp_finalize_oacc_routine (cp_parser *parser, tree fndecl, bool is_defn)
   /* Add an "omp declare target" attribute.  */
   DECL_ATTRIBUTES (fndecl)
 	= tree_cons (get_identifier ("omp declare target"),
-		 NULL_TREE, DECL_ATTRIBUTES (fndecl));
+		 parser->oacc_routine->clauses, DECL_ATTRIBUTES (fndecl));
 
   /* Don't unset parser->oacc_routine here: we may still need it to
 	 diagnose wrong usage.  But, remember that we've used this "#pragma acc
diff --git a/gcc/fortran/f95-lang.c b/gcc/fortran/f95-lang.c
index ad81f7d93a0..19739792c8f 100644
--- a/gcc/fortran/f95-lang.c
+++ b/gcc/fortran/f95-lang.c
@@ -91,7 +91,7 @@ static const struct attribute_spec gfc_attribute_table[] =
 {
   /* { name, min_len, max_len, decl_req, type_req, fn_type_req,
affects_type_identity, handler, exclude } */
-  { "omp declare target", 0, 0, true,  false, false, false,
+  { "omp declare target", 0, -1, true,  false, false, false,
 gfc_handle_omp_declare_target_attribute, NULL },
   { "omp declare target link", 0, 0, true,  false, false, false,
 gfc_handle_omp_declare_target_attribute, NULL },
diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index 20d453051a2..23b4f98845a 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -1400,12 +1400,7 @@ add_attributes_to_decl (symbol_attribute sym_attr, tree list)
 	list = chainon (list, attr);
   }
 
-  if (sym_attr.omp_declare_target_link)
-list = tree_cons (get_identifier ("omp declare target link"),
-		  NULL_TREE, list);
-  else if (sym_attr.omp_declare_target)
-list = tree_cons (get_identifier ("omp declare target"),
-		  NULL_TREE, list);
+  tree clauses = NULL_TREE;
 
   if (sym_attr.oacc_routine_lop != OACC_ROUTINE_LOP_NONE)
 {
@@ -1429,11 +1424,20 @@ add_attributes_to_decl (symbol_attribute sym_attr, tree list)
 	  gcc_unreachable ();
 	}
   tree c = build_omp_clause (UNKNOWN_LOCATION, code);
+  OMP_CLAUSE_CHAIN (c) = clauses;
+  clauses = c;
 
-  tree dims = oacc_build_routine_dims (c);
+  tree dims = oacc_build_routine_dims (clauses);
   list = oacc_replace_fn_attrib_attr (list, 

Re: [committed][nvptx, libgomp] Move rtl-dump test-cases to libgomp

[Thomas Schwinge]

Hi!

On Wed, 19 Dec 2018 15:28:41 +0100, Tom de Vries  wrote:
> The goacc.exp test-cases nvptx-merged-loop.c and nvptx-sese-1.c are failing
> during linking due to missing libgomp.spec.

Right; see also
,
from three years ago.  ;-)

> Move them to the libgomp testsuite.
> 
> Build and reg-tested on x86_64 with nvptx accelerator.
> 
> Committed to trunk.

ACK, thanks.

> diff --git a/gcc/testsuite/gcc.dg/goacc/nvptx-merged-loop.c 
> b/libgomp/testsuite/libgomp.oacc-c-c++-common/nvptx-merged-loop.c
> similarity index 59%
> rename from gcc/testsuite/gcc.dg/goacc/nvptx-merged-loop.c
> rename to libgomp/testsuite/libgomp.oacc-c-c++-common/nvptx-merged-loop.c
> index 3ff537c1d97..8a2117e1624 100644
> --- a/gcc/testsuite/gcc.dg/goacc/nvptx-merged-loop.c
> +++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/nvptx-merged-loop.c
> @@ -1,6 +1,6 @@
> -/* { dg-do link } */
> -/* { dg-require-effective-target offload_nvptx } */
> -/* { dg-options "-fopenacc -O2 -foffload=-fdump-rtl-mach\\ -dumpbase\\ 
> nvptx-merged-loop.c\\ -Wa,--no-verify" } */
> +/* { dg-do run { target openacc_nvidia_accel_selected } } */
> +/* { dg-options "-foffload=-fdump-rtl-mach" } */
> +/* { dg-skip-if "" { *-*-* } { "*" } { "-O2" } } */
> [...]
> -/* { dg-final { scan-rtl-dump "Merging loop .* into " "mach" } } */
> +/* { dg-final { scan-offload-rtl-dump "Merging loop .* into " "mach" } } */

There is however still a problem here: if you have more than one offload
compiler configured, all of them will react to
'-foffload=-fdump-rtl-mach', and will overwrite their dump files, or if
different compiler passes configured, that may produce more than one
"mach" dump file, all this resulting in "funny" testing FAILs/ERRORs.
But: we can't just use '-foffload=[nvptx]=-fdump-rtl-mach', because
'[nvptx]' can be 'nvptx', or 'nvptx-none', etc.

Similar problem for a lot of other test cases that you've recently added
(... but thanks for all these, of course!).

And, "dg-require-effective-target offload_nvptx" is now obsolete, and
should be removed.

All this I'm addressing in the commits I've just done, see attached:

  - r269106 "[libgomp] In OpenACC offloading testing, be more explicit in
what is supported, and what is not, or why not"
  - r269107 "[libgomp] Clarify difference between offload target, offload
plugin, and OpenACC device type"
  - r269108 "[libgomp] In OpenACC testing, cycle though all offload
targets"
  - r269109 "[libgomp] In OpenACC testing, by default only build for the
offload target that we're actually going to test"
  - r269110 "Remove unused check_effective_target_offload_nvptx"

These libgomp changes improves testing time, as discussed before, and
clean up the test log as follows:

UNSUPPORTED: 
libgomp.oacc-c/../libgomp.oacc-c-c++-common/nvptx-merged-loop.c 
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 {+-foffload=nvptx-none+}  -O0 
PASS: libgomp.oacc-c/../libgomp.oacc-c-c++-common/nvptx-merged-loop.c 
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 {+-foffload=nvptx-none+}  -O2  
(test for excess errors)
PASS: libgomp.oacc-c/../libgomp.oacc-c-c++-common/nvptx-merged-loop.c 
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 {+-foffload=nvptx-none+}  -O2  
execution test
[-ERROR:-]{+PASS:+} 
libgomp.oacc-c/../libgomp.oacc-c-c++-common/nvptx-merged-loop.c 
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 {+-foffload=nvptx-none+}  -O2   
[-: error executing dg-final: couldn't open "nvptx-merged-loop.o.304r.mach 
nvptx-merged-loop.o.307r.mach": no such file or 
directory-]{+scan-offload-rtl-dump mach "Merging loop .* into "+}

UNSUPPORTED: libgomp.oacc-c/../libgomp.oacc-c-c++-common/nvptx-sese-1.c 
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 {+-foffload=nvptx-none+}  -O0 
PASS: libgomp.oacc-c/../libgomp.oacc-c-c++-common/nvptx-sese-1.c 
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 {+-foffload=nvptx-none+}  -O2  
(test for excess errors)
PASS: libgomp.oacc-c/../libgomp.oacc-c-c++-common/nvptx-sese-1.c 
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 {+-foffload=nvptx-none+}  -O2  
execution test
[-ERROR:-]{+PASS:+} 
libgomp.oacc-c/../libgomp.oacc-c-c++-common/nvptx-sese-1.c 
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 {+-foffload=nvptx-none+}  -O2   
[-: error executing dg-final: couldn't open "nvptx-sese-1.o.307r.mach 
nvptx-sese-1.o.304r.mach": no such file or directory-]{+scan-offload-rtl-dump 
mach "SESE regions:.* [0-9]+{[0-9]+->[0-9]+(\\.[0-9]+)+}"+}

UNSUPPORTED: libgomp.oacc-c/../libgomp.oacc-c-c++-common/pr85381-2.c 
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 {+-foffload=nvptx-none+}  -O0 
PASS: libgomp.oacc-c/../libgomp.oacc-c-c++-common/pr85381-2.c 
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 {+-foffload=nvptx-none+}  -O2  
(test for excess errors)
PASS: libgomp.oacc-c/../libgomp.oacc-c-c++-common/pr85381-2.c 
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 {+-foffload=nvptx-none+}  -O2  
execution 

Re: [nvptx, committed] Unify C/Fortran routine handling in nvptx_goacc_validate_dims

[Thomas Schwinge]

Hi!

On Mon, 17 Dec 2018 22:46:50 +0100, Tom de Vries  wrote:
> [ was: Re: [nvptx] vector length patch series ]
> 
> On 14-12-18 20:58, Tom de Vries wrote:
> >> 0004-openacc-Make-GFC-default-to-1-for-OpenACC-routine-di.patch
> > If I remove this, I run into ICEs in the compiler, but I think that
> > means we need to understand and fix that ICE, instead of concluding that
> > we need this patch. It looks completely unrelated.
> 
> Indeed this
> (0004-openacc-Make-GFC-default-to-1-for-OpenACC-routine-di.patch) patch
> is unrelated to the vector length functionality.
> 
> However, it fixes a problem in the Fortran front-end which has as
> consequence that C and Fortran routines look the same in
> nvptx_goacc_validate_dims, which is a good thing to have.
> 
> However, the upstreaming of the patch seems to be stuck, so I've
> committed an nvptx workaround patch that has the same effect, allowing
> us to drop it
> (0004-openacc-Make-GFC-default-to-1-for-OpenACC-routine-di.patch) from
> the patch series.

ACK, thanks.

> [nvptx] Unify C/Fortran routine handling in nvptx_goacc_validate_dims
> 
> The Fortran front-end has a bug (PR72741) that means what when
> nvptx_goacc_validate_dims is called for a Fortran routine, the dims parameter
> is not the same as it would have been if the function would have been called 
> for
> an equivalent C routine.
> 
> Work around this bug by overriding the dims parameter for routines, allowing 
> the
> function to handle routines in Fortran and C the same.

I have now finally identified the relevant changes (scattered over
several commits on the OpenACC development branch, each of these trying
to do too many things at once, but also incompletely...), and then have
rewritten most of it anyway, into a more pleasant form, and now committed
to trunk in r269105 "[PR72741] Use 'oacc_build_routine_dims' for Fortran
OpenACC 'routine' directives, too", as attached.


Grüße
 Thomas


From 1d740b07b3ba5b15b7ece7fdb25236e32251131a Mon Sep 17 00:00:00 2001
From: tschwinge 
Date: Fri, 22 Feb 2019 10:50:35 +
Subject: [PATCH 4/9] [PR72741] Use 'oacc_build_routine_dims' for Fortran
 OpenACC 'routine' directives, too

... instead of having an incomplete local implementation.

With these changes in place, we can then also revert the work-around r267213
"[nvptx] Unify C/Fortran routine handling in nvptx_goacc_validate_dims".

	gcc/fortran/
	PR fortran/72741
	* gfortran.h (oacc_routine_lop): New enum.
	(symbol_attribute): Use it.
	* openmp.c (gfc_oacc_routine_dims): Replace with...
	(gfc_oacc_routine_lop): ... this new function.
	(gfc_match_oacc_routine): Adjust.
	* trans-decl.c (add_attributes_to_decl): Likewise.
	gcc/
	PR fortran/72741
	* omp-general.c (oacc_replace_fn_attrib): Mostly split out into...
	(oacc_replace_fn_attrib_attr): ... this new function.
	* omp-general.h (oacc_replace_fn_attrib_attr): New prototype.
	* config/nvptx/nvptx.c (nvptx_goacc_validate_dims_1): Revert workaround.
	gcc/testsuite/
	PR fortran/72741
	* gfortran.dg/goacc/classify-routine.f95: Adjust.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@269105 138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/ChangeLog |  8 
 gcc/config/nvptx/nvptx.c  | 35 
 gcc/fortran/ChangeLog | 11 +
 gcc/fortran/gfortran.h| 13 +-
 gcc/fortran/openmp.c  | 41 +++
 gcc/fortran/trans-decl.c  | 34 ++-
 gcc/omp-general.c | 18 ++--
 gcc/omp-general.h |  1 +
 gcc/testsuite/ChangeLog   |  3 ++
 .../gfortran.dg/goacc/classify-routine.f95|  4 +-
 10 files changed, 99 insertions(+), 69 deletions(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 4745a1999d9..f14cbbce477 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,11 @@
+2019-02-22  Thomas Schwinge  
+
+	PR fortran/72741
+	* omp-general.c (oacc_replace_fn_attrib): Mostly split out into...
+	(oacc_replace_fn_attrib_attr): ... this new function.
+	* omp-general.h (oacc_replace_fn_attrib_attr): New prototype.
+	* config/nvptx/nvptx.c (nvptx_goacc_validate_dims_1): Revert workaround.
+
 2019-02-22  Kyrylo Tkachov  
 
 	* config/arm/arm-cpus.in (ares): Rename to...
diff --git a/gcc/config/nvptx/nvptx.c b/gcc/config/nvptx/nvptx.c
index 23459e1c6f4..424b43ac8b4 100644
--- a/gcc/config/nvptx/nvptx.c
+++ b/gcc/config/nvptx/nvptx.c
@@ -5577,41 +5577,6 @@ nvptx_goacc_validate_dims_1 (tree decl, int dims[], int fn_level, unsigned used)
   else
 gcc_unreachable ();
 
-  if (routine_p)
-{
-  /* OpenACC routines in C arrive here with the following attributes
-	 (omitting the 'omp declare target'):
-	 seq   : __attribute__((oacc function (0 1, 0 1, 0 1)))
-	 vector: __attribute__((oacc function (0 1, 0 1, 1 0)))
-	 worker: __attribute__((oacc function (0 1, 1 0, 1 0)))
-	 gang  : __attribute__((oacc function (1 0, 

Re: [PATCH, GCC, AArch64] Fix a couple of bugs in BTI

[Sudakshina Das]

On 21/02/2019 22:52, James Greenhalgh wrote:
> On Thu, Feb 21, 2019 at 06:19:10AM -0600, Sudakshina Das wrote:
>> Hi
>>
>> While doing more testing I found a couple of issues with my BTI patches.
>> This patch fixes them:
>> 1) Remove a reference to return address key. The original patch was
>> written based on a different not yet committed patch ([PATCH
>> 3/3][GCC][AARCH64] Add support for pointer authentication B key) and I
>> missed out on cleaning this up. This is hidden behind the configuration
>> option and thus went unnoticed.
>> 2) Add a missed case for adding the BTI instruction in thunk functions.
>>
>> Bootstrapped on aarch64-none-linux-gnu and regression tested on
>> aarch64-none-elf with configuration turned on.
> 
> OK.
> 

Thanks committed as r269112.
Sudi

> Thanks,
> James
> 
>>
>> gcc/ChangeLog:
>>
>> 2019-xx-xx  Sudakshina Das  
>>
>>  * config/aarch64/aarch64.c (aarch64_output_mi_thunk): Add bti
>>  instruction if enabled.
>>  (aarch64_override_options): Remove reference to return address
>>  key.
>>
>>
>> Is this ok for trunk?
>> Sudi
> 

Re: [OpenACC] Update OpenACC data clause semantics to the 2.5 behavior

[Thomas Schwinge]

Hi!

On Fri, 14 Dec 2018 22:24:47 +0100, I wrote:
> On Fri, 25 May 2018 13:01:58 -0700, Cesar Philippidis 
>  wrote:
> > This patch updates GCC's to support OpenACC 2.5's data clause semantics. 
> > In OpenACC 2.5, copy, copyin and copyout all behave like their 
> > present_or_* counterparts in OpenACC 2.0. The patch also adds support 
> > for the new finalize and if_present data clauses introduced in OpenACC 
> > 2.5. The finalize clause introduced some new reference counting behavior 
> > in the runtime; whereas 'acc exit data copyout' decrements the reference 
> > count of a variable, 'acc exit data finalize' actually removes it from 
> > the accelerator regardless of there are any pending references to it.
> > 
> > Due to the size of this patch, I had to compress it.
> 
> Well, or just handled separately the pieces that already were nicely
> separated, instead of combining them into one big patch?
> 
> > However, despite 
> > the size of the patch, which is mainly due to the augmented test cases, 
> > it fairly noninvasive. I was originally going to include support for 
> > declare allocate and deallocate, but those require more extensive 
> > modifications to the fortran FE.
> 
> (Why the idea of including even more independent changes?)
> 
> 
> Anyway.  Committed to trunk in r267153 the following to add in the
> missing changes from [...].

..., and now further committed to trunk in r269104 "Revert earlier
OpenACC 'routine' changes", as attached.


Grüße
 Thomas


From 9b42375414c5d9220b627bea41df7d5fc712fd0c Mon Sep 17 00:00:00 2001
From: tschwinge 
Date: Fri, 22 Feb 2019 10:50:18 +
Subject: [PATCH 3/9] Revert earlier OpenACC 'routine' changes

..., which were committed as part of, but logically don't belong into r261813
"Update OpenACC data clause semantics to the 2.5 behavior", and which confuse
later changes.

	gcc/fortran/
	* openmp.c (gfc_match_oacc_declare): Revert earlier changes.
	gcc/testsuite/
	* c-c++-common/goacc/routine-5.c: Revert earlier changes.
	* g++.dg/goacc/template.C: Likewise.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@269104 138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/fortran/ChangeLog|   4 +
 gcc/fortran/openmp.c |   7 -
 gcc/testsuite/ChangeLog  |   3 +
 gcc/testsuite/c-c++-common/goacc/routine-5.c | 150 ---
 gcc/testsuite/g++.dg/goacc/template.C|   2 +-
 5 files changed, 104 insertions(+), 62 deletions(-)

diff --git a/gcc/fortran/ChangeLog b/gcc/fortran/ChangeLog
index c3bc30c42f6..74a6890ed70 100644
--- a/gcc/fortran/ChangeLog
+++ b/gcc/fortran/ChangeLog
@@ -1,3 +1,7 @@
+2019-02-22  Thomas Schwinge  
+
+	* openmp.c (gfc_match_oacc_declare): Revert earlier changes.
+
 2019-02-21  Thomas Koenig  
 
 	* dump-parse-tree.c (debug): Implement for gfc_expr *,
diff --git a/gcc/fortran/openmp.c b/gcc/fortran/openmp.c
index 11dd3ae0ada..8aa4a2f18c4 100644
--- a/gcc/fortran/openmp.c
+++ b/gcc/fortran/openmp.c
@@ -2075,13 +2075,6 @@ gfc_match_oacc_declare (void)
 	  module_var = true;
 	}
 
-  if (ns->proc_name->attr.oacc_function)
-	{
-	  gfc_error ("Invalid declare in routine with $!ACC DECLARE at %L",
-		 );
-	  return MATCH_ERROR;
-	}
-
   if (s->attr.use_assoc)
 	{
 	  gfc_error ("Variable is USE-associated with !$ACC DECLARE at %L",
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index b98cd355645..12901a9361a 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,5 +1,8 @@
 2019-02-22  Thomas Schwinge  
 
+	* c-c++-common/goacc/routine-5.c: Revert earlier changes.
+	* g++.dg/goacc/template.C: Likewise.
+
 	PR fortran/78027
 	* gfortran.dg/goacc/pr78027.f90: Add 'dg-additional-options "-Wno-hsa"'.
 
diff --git a/gcc/testsuite/c-c++-common/goacc/routine-5.c b/gcc/testsuite/c-c++-common/goacc/routine-5.c
index b759db3292d..b967a7447bd 100644
--- a/gcc/testsuite/c-c++-common/goacc/routine-5.c
+++ b/gcc/testsuite/c-c++-common/goacc/routine-5.c
@@ -4,11 +4,11 @@
 
 struct PC
 {
-#pragma acc routine seq /* { dg-error ".#pragma acc routine. must be at file scope" } */
+#pragma acc routine /* { dg-error ".#pragma acc routine. must be at file scope" } */
 };
 
 void PC1( /* { dg-bogus "variable or field .PC1. declared void" "TODO" { xfail c++ } } */
-#pragma acc routine seq
+#pragma acc routine
 	 /* { dg-error ".#pragma acc routine. must be at file scope" "" { target c } .-1 }
 	{ dg-error ".#pragma. is not allowed here" "" { target c++ } .-2 } */
 ) /* { dg-bogus "expected declaration specifiers or .\\.\\.\\.. before .\\). token" "TODO" { xfail c } } */
@@ -18,26 +18,26 @@ void PC1( /* { dg-bogus "variable or field .PC1. declared void" "TODO" { xfail c
 void PC2()
 {
   if (0)
-#pragma acc routine seq /* { dg-error ".#pragma acc routine. must be at file scope" } */
+#pragma acc routine /* { dg-error ".#pragma acc routine. must be at file scope" } */
 ;
 }
 
 void PC3()
 {
-#pragma acc routine seq /* { dg-error ".#pragma acc 

Re: [PATCH] Fix PR78027

[Thomas Schwinge]

Hi!

On Thu, 8 Dec 2016 15:05:10 -0800, Cesar Philippidis  
wrote:
> --- /dev/null
> +++ b/gcc/testsuite/gfortran.dg/goacc/pr78027.f90
> @@ -0,0 +1,20 @@
> +! { dg-additional-options "-fopenmp -O2 -fdump-ipa-icf" }
> +[...]

To address unrelated compiler diagnostics, I've just committed to trunk
in r269103 "Silence '-Whsa' diagnostic in
'gfortran.dg/goacc/pr78027.f90'", as attached.


Grüße
 Thomas


From eb1dc7b8b939858939783d0ce5ba6d5375784dd1 Mon Sep 17 00:00:00 2001
From: tschwinge 
Date: Fri, 22 Feb 2019 10:50:02 +
Subject: [PATCH 2/9] Silence '-Whsa' diagnostic in
 'gfortran.dg/goacc/pr78027.f90'

... which has been present (with HSA offloading configured) ever since this
test case got added.

	gcc/testsuite/
	PR fortran/78027
	* gfortran.dg/goacc/pr78027.f90: Add 'dg-additional-options "-Wno-hsa"'.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@269103 138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/testsuite/ChangeLog | 5 +
 gcc/testsuite/gfortran.dg/goacc/pr78027.f90 | 4 
 2 files changed, 9 insertions(+)

diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 7cb6b240d0c..b98cd355645 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2019-02-22  Thomas Schwinge  
+
+	PR fortran/78027
+	* gfortran.dg/goacc/pr78027.f90: Add 'dg-additional-options "-Wno-hsa"'.
+
 2019-02-22  Richard Biener  
 
 	PR middle-end/87609
diff --git a/gcc/testsuite/gfortran.dg/goacc/pr78027.f90 b/gcc/testsuite/gfortran.dg/goacc/pr78027.f90
index db65063bede..a1e51fa0f0d 100644
--- a/gcc/testsuite/gfortran.dg/goacc/pr78027.f90
+++ b/gcc/testsuite/gfortran.dg/goacc/pr78027.f90
@@ -1,5 +1,9 @@
 ! { dg-additional-options "-fopenmp -O2 -fdump-ipa-icf" }
 
+! f951: warning: could not emit HSAIL for the function [-Whsa]
+! f951: note: HSA does not support functions with variadic arguments (or unknown return type): 'GOACC_parallel_keyed'
+! { dg-additional-options "-Wno-hsa" }
+
 real function f()
!$omp declare target(f)
f = 1.
-- 
2.17.1



signature.asc
Description: PGP signature

[PATCH] Significantly speed up verifiers for a cgraph_node with many clones.

[Martin Liška]

Hi.

The patch makes a significant verifier speed up in a project that
has a dtor for which we create ~70.000 clones.

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

Ready to be installed?
Thanks,
Martin

gcc/ChangeLog:

2019-02-22  Martin Liska  

* cgraph.c (cgraph_node::verify_node): Verify with a neighbour
which is equivalent to searching for this in clones chain.
* symtab.c (symtab_node::verify_base): Similarly compare ASM
names with a neighbour and special case first node in a chain.
---
 gcc/cgraph.c | 14 +++---
 gcc/symtab.c | 39 +++
 2 files changed, 30 insertions(+), 23 deletions(-)


diff --git a/gcc/cgraph.c b/gcc/cgraph.c
index de82316d4b1..dfe1833ed1d 100644
--- a/gcc/cgraph.c
+++ b/gcc/cgraph.c
@@ -3240,14 +3240,14 @@ cgraph_node::verify_node (void)
 
   if (clone_of)
 {
-  cgraph_node *n;
-  for (n = clone_of->clones; n; n = n->next_sibling_clone)
-	if (n == this)
-	  break;
-  if (!n)
+  cgraph_node *first_clone = clone_of->clones;
+  if (first_clone != this)
 	{
-	  error ("cgraph_node has wrong clone_of");
-	  error_found = true;
+	  if (prev_sibling_clone->clone_of != clone_of)
+	{
+	  error ("cgraph_node has wrong clone_of");
+	  error_found = true;
+	}
 	}
 }
   if (clones)
diff --git a/gcc/symtab.c b/gcc/symtab.c
index c9fa16b353b..16a21359f8d 100644
--- a/gcc/symtab.c
+++ b/gcc/symtab.c
@@ -1040,23 +1040,30 @@ symtab_node::verify_base (void)
   if (symtab->assembler_name_hash)
 {
   hashed_node = symtab_node::get_for_asmname (DECL_ASSEMBLER_NAME (decl));
-  if (hashed_node && hashed_node->previous_sharing_asm_name)
+  if (hashed_node)
 	{
-  error ("assembler name hash list corrupted");
-  error_found = true;
-	}
-  while (hashed_node)
-	{
-	  if (hashed_node == this)
-	break;
-	  hashed_node = hashed_node->next_sharing_asm_name;
-	}
-  if (!hashed_node
-	  && !(is_a  (this)
-	   && DECL_HARD_REGISTER (decl)))
-	{
-  error ("node not found in symtab assembler name hash");
-  error_found = true;
+	  if (hashed_node->previous_sharing_asm_name)
+	{
+	  error ("assembler name hash list corrupted");
+	  error_found = true;
+	}
+	  else if (previous_sharing_asm_name == NULL)
+	{
+	  if (hashed_node != this)
+		{
+		  error ("assembler name hash list corrupted");
+		  error_found = true;
+		}
+	}
+	  else if (!(is_a  (this) && DECL_HARD_REGISTER (decl)))
+	{
+	  if (!asmname_hasher::equal (previous_sharing_asm_name,
+	  DECL_ASSEMBLER_NAME (decl)))
+		{
+		  error ("node not found in symtab assembler name hash");
+		  error_found = true;
+		}
+	}
 	}
 }
   if (previous_sharing_asm_name

Re: Use correct location information for OpenACC shape and simple clauses in C/C++

[Thomas Schwinge]

Hi!

On Thu, 4 Aug 2016 11:03:25 -0600, Jeff Law  wrote:
> On 07/27/2016 09:17 AM, Thomas Schwinge wrote:
> > I found that for a lot of OpenACC (and potentially also OpenMP) clauses
> > (in C/C++ front ends; didn't look at Fortran), we use wrong location
> > information.  The problem is that
> > c_parser_oacc_all_clauses/c_parser_omp_all_clauses calls
> > cp_parser_omp_clause_name to determine the pragma_omp_clause c_kind, and
> > that function (as documented) consumes the clause token before returning.
> > So, when we then do "c_parser_peek_token (parser)->location" or similar
> > in some clause parsing function, that will return the location
> > information of the token _after_ the clause token, which -- at least very
> > often -- is not desirable, in particular if that location information is
> > used then in a build_omp_clause call, which should point to the clause
> > token itself, and not whatever follows after that.
> >
> > Probably that all went unnoticed for so long, because the GCC testsuite
> > largely is running with -fno-diagnostics-show-caret, so we don't visually
> > see the wrong location information (and nobody pays attention to the
> > colum information as given, for example, as line 2, column 32 in
> > "[...]/c-c++-common/goacc/routine-2.c:2:32: error: [...]".
> >
> > There seems to be a lot of inconsistency in that in all the clause
> > parsing; here is just a first patch to fix the immediate problem I've
> > been observing.  OK for trunk already, or need to clean this all up in
> > one go?  Do we need this on release branches, as a "quality of
> > implementation" fix (wrong diagnostic locations)?

> > --- gcc/c/c-parser.c
> > +++ gcc/c/c-parser.c
> > @@ -11758,12 +11758,12 @@ c_parser_oacc_shape_clause (c_parser *parser, 
> > omp_clause_code kind,
> > seq */
> >
> >  static tree
> > -c_parser_oacc_simple_clause (c_parser *parser, enum omp_clause_code code,
> > -tree list)
> > +c_parser_oacc_simple_clause (c_parser * /* parser */, location_t loc,
> > +enum omp_clause_code code, tree list)

> Any reason not to just drop the parser argument entirely?  If we must 
> have it to match an API, but don't need it, then just drop the argument 
> name entirely rather than commenting it out.  This kind of comment, IMHO 
> serves no useful purpose.

OK.  I had only left it in, as all the parser functions passed it in, but
yeah, that's not actually necessary (and can easily be restored should it
ever be needed).

> With that change and some tests (presumably using David recipe) this is 
> will be fine.

With test cases still deferred for proper inspection of all such clauses,
I have now at least committed the agreed-on code changes to fix things
for the cases already identified: committed to trunk in r269102 "[C, C++]
Use correct location information for OpenACC shape and simple clauses",
as attached.


Grüße
 Thomas


From 51391c1d37a8111492a5c5ea2e17654c4fa29d03 Mon Sep 17 00:00:00 2001
From: tschwinge 
Date: Fri, 22 Feb 2019 10:49:43 +
Subject: [PATCH 1/9] [C, C++] Use correct location information for OpenACC
 shape and simple clauses

	gcc/c/
	* c-parser.c (c_parser_oacc_shape_clause): Add loc formal
	parameter.  Adjust all users.
	(c_parser_oacc_simple_clause): Replace parser with loc formal
	parameter.  Adjust all users.
	gcc/cp/
	* parser.c (cp_parser_oacc_simple_clause): Remove parser formal
	parameter, move loc formal parameter to the front.  Adjust all
	users.
	(cp_parser_oacc_shape_clause): Add loc formal parameter.  Adjust
	all users.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@269102 138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/c/ChangeLog  |  7 +++
 gcc/c/c-parser.c | 28 ++--
 gcc/cp/ChangeLog |  8 
 gcc/cp/parser.c  | 45 +++--
 4 files changed, 52 insertions(+), 36 deletions(-)

diff --git a/gcc/c/ChangeLog b/gcc/c/ChangeLog
index b76f5b1fae6..6b26ca0f9b3 100644
--- a/gcc/c/ChangeLog
+++ b/gcc/c/ChangeLog
@@ -1,3 +1,10 @@
+2019-02-22  Thomas Schwinge  
+
+	* c-parser.c (c_parser_oacc_shape_clause): Add loc formal
+	parameter.  Adjust all users.
+	(c_parser_oacc_simple_clause): Replace parser with loc formal
+	parameter.  Adjust all users.
+
 2019-02-19  Chung-Lin Tang 
 
 	PR c/87924
diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index 6c1f3076241..22c7416ac94 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -13159,12 +13159,12 @@ c_parser_oacc_single_int_clause (c_parser *parser, omp_clause_code code,
 */
 
 static tree
-c_parser_oacc_shape_clause (c_parser *parser, omp_clause_code kind,
+c_parser_oacc_shape_clause (c_parser *parser, location_t loc,
+			omp_clause_code kind,
 			const char *str, tree list)
 {
   const char *id = "num";
   tree ops[2] = { NULL_TREE, NULL_TREE }, c;
-  location_t loc = c_parser_peek_token (parser)->location;
 
   if (kind == OMP_CLAUSE_VECTOR)
 id = "length";
@@ -13296,12 +13296,12 @@ 

[PATCH] Fix PR89440

[Richard Biener]

The following removes an assert in the vectorizer since we can handle
this nested cycle just fine.

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

Richard.

2019-02-22  Richard Biener  

PR tree-optimization/89440
* tree-vect-loop.c (vect_create_epilog_for_reduction): Remove
not necessary assert.

* gcc.dg/vect/pr89440.c: New testcase.

Index: gcc/tree-vect-loop.c
===
--- gcc/tree-vect-loop.c(revision 269096)
+++ gcc/tree-vect-loop.c(working copy)
@@ -5494,13 +5494,6 @@ vect_finalize_reduction:
= loop_vinfo->lookup_stmt (exit_phi);
   gphi *vect_phi;
 
-  /* FORNOW. Currently not supporting the case that an inner-loop
- reduction is not used in the outer-loop (but only outside the
- outer-loop), unless it is double reduction.  */
-  gcc_assert ((STMT_VINFO_RELEVANT_P (exit_phi_vinfo)
-   && !STMT_VINFO_LIVE_P (exit_phi_vinfo))
-  || double_reduc);
-
  if (double_reduc)
STMT_VINFO_VEC_STMT (exit_phi_vinfo) = inner_phi;
  else
Index: gcc/testsuite/gcc.dg/vect/pr89440.c
===
--- gcc/testsuite/gcc.dg/vect/pr89440.c (nonexistent)
+++ gcc/testsuite/gcc.dg/vect/pr89440.c (working copy)
@@ -0,0 +1,32 @@
+/* { dg-do run } */
+/* { dg-additional-options "-ffast-math" } */
+
+#include "tree-vect.h"
+
+float __attribute__((noinline,noclone))
+f (float x)
+{
+  int i;
+  float j;
+  float a = 0;
+  for (i = 0; i < 4; ++i)
+{
+  for (j = 0; j < 4; ++j)
+   {
+ a += 1;
+ x += a;
+   }
+}
+  return x;
+}
+
+int
+main()
+{
+  check_vect ();
+  if (f (1.0f) != 137.0f)
+abort ();
+  return 0;
+}
+
+/* { dg-final { scan-tree-dump "OUTER LOOP VECTORIZED" "vect" { target 
vect_float } } } */

[PATCH, wwwdocs] Mention -march=armv8.5-a and other new command line options for AArch64 and Arm for GCC 9

[Sudakshina Das]

Hi

This patch documents the addition of the new Armv8.5-A and corresponding 
extensions in the gcc-9/changes.html.
As per https://gcc.gnu.org/about.html, I have used W3 Validator.
Is this ok for cvs?

Thanks
Sudi
Index: htdocs/gcc-9/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-9/changes.html,v
retrieving revision 1.43
diff -u -r1.43 changes.html
--- htdocs/gcc-9/changes.html	21 Feb 2019 10:32:55 -	1.43
+++ htdocs/gcc-9/changes.html	21 Feb 2019 18:25:09 -
@@ -283,6 +283,19 @@
 
 The intrinsics are defined by the ACLE specification.
   
+  
+The Armv8.5-A architecture is now supported. This can be used by specifying the
+   -march=armv8.5-a option.
+  
+   The Armv8.5-A architecture also adds some security features that are optional to all older
+architecture versions. These are also supported now and only effect the assembler.
+
+	 Speculation Barrier instruction using -march=armv8-a+sb.
+	 Execution and Data Prediction Restriction instructions using -march=armv8-a+predres.
+	 Speculative Store Bypass Safe instruction using -march=armv8-a+ssbs. This does not
+	 require a compiler option for Arm and thus -march=armv8-a+ssbs is a AArch64 specific option.
+
+  
 
 
 AArch64 specific
@@ -298,6 +311,22 @@
 The default value is 16 (64Kb) and can be changed at configure
 time using the flag --with-stack-clash-protection-guard-size=12|16.
   
+  
+The option -msign-return-address= has been deprecated. This has been replaced
+by the new -mbranch-protection= option. This new option can now be used to
+enable the return address signing as well as the new Branch Target Identification
+feature of Armv8.5-A architecture. For more information on the arguments accepted by
+this option, please refer to
+ https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html#AArch64-Options;>
+	AArch64-Options.
+  
+   The following optional extensions to Armv8.5-A architecture are also supported now and
+   only effect the assembler.
+
+	 Random Number Generation instructions using -march=armv8.5-a+rng.
+	 Memory Tagging Extension using -march=armv8.5-a+memtag.
+
+  
 
 
 Arm specific

[PATCH] Fix a test (PR testsuite/89441).

[Martin Liška]

Hi.

This patch makes main not hidden (as reported in the PR).
John: Can you verify it fixes your problem on hppa64-hp-hpux11.11 target?

Ready for trunk?

gcc/testsuite/ChangeLog:

2019-02-22  Martin Liska  

PR testsuite/89441
* g++.dg/ipa/pr89009.C (push): Don't make main hidden.
---
 gcc/testsuite/g++.dg/ipa/pr89009.C | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)


diff --git a/gcc/testsuite/g++.dg/ipa/pr89009.C b/gcc/testsuite/g++.dg/ipa/pr89009.C
index 6b4fc65a641..b303ef99142 100644
--- a/gcc/testsuite/g++.dg/ipa/pr89009.C
+++ b/gcc/testsuite/g++.dg/ipa/pr89009.C
@@ -1,11 +1,11 @@
 /* PR ipa/89009 */
 /* { dg-do run } */
-/* { dg-options "-fvisibility=hidden -fpic -O2 -fno-inline" } */
+/* { dg-options "-fpic -O2 -fno-inline" } */
 
-#pragma GCC visibility push(default)
 void foo1() { __builtin_printf ("foo\n"); }
-#pragma GCC visibility pop
+#pragma GCC visibility push(hidden)
 void foo2() { __builtin_printf ("foo\n"); }
+#pragma GCC visibility pop
 
 int main() { foo2(); return 0; }
 

[PATCH] Remove vestiges of cc1-dummy

[Richard Biener]

After

2010-10-07  Andi Kleen  

* Makefile.in (MOSTLYCLEANFILES): Remove cc1*dummy, add
checksum-options.
(checksum-options): Add.
(cc1-dummy): Remove.
(cc1-checksum): Change to run checksum over object files
and options only.
* dummy-checksum.c: Remove.
* genchecksum.c: Update copyright.
(usage): Allow multiple arguments.
(BLOCKSIZE): Add.
(dosum): Change for incremental checksum. Remove C output.
(main): Iterate over all argument files. Add C output.

there are no longer binaries with dummy-checksum.c we guard against
using.

Bootstrap running on x86_64-unknown-linux-gnu.

Richard.

2019-02-22  Richard Biener  

c-family/
* c-pch.c (no_checksum): Remove.
(pch_init): Remove assertion that executable_checksum is not
all zero.
(c_common_valid_pch): Likewise.

Index: gcc/c-family/c-pch.c
===
--- gcc/c-family/c-pch.c(revision 269098)
+++ gcc/c-family/c-pch.c(working copy)
@@ -45,10 +45,6 @@ enum {
   MATCH_SIZE = ARRAY_SIZE (pch_matching)
 };
 
-/* The value of the checksum in the dummy compiler that is actually
-   checksummed.  That compiler should never be run.  */
-static const char no_checksum[16] = { 0 };
-
 /* Information about flags and suchlike that affect PCH validity.
 
Before this structure is read, both an initial 8-character identification
@@ -111,8 +107,6 @@ pch_init (void)
 pch_file);
   pch_outfile = f;
 
-  gcc_assert (memcmp (executable_checksum, no_checksum, 16) != 0);
-
   memset (, '\0', sizeof (v));
   v.debug_info_type = write_symbols;
   {
@@ -212,8 +206,6 @@ c_common_valid_pch (cpp_reader *pfile, c
   /* Perform a quick test of whether this is a valid
  precompiled header for the current language.  */
 
-  gcc_assert (memcmp (executable_checksum, no_checksum, 16) != 0);
-
   sizeread = read (fd, ident, IDENT_LENGTH + 16);
   if (sizeread == -1)
 fatal_error (input_location, "can%'t read %s: %m", name);

Re: [PR middle-end/85598] make -Wprintf* pass use loop info for PHI's

[Aldy Hernandez]

On 1/31/19 9:56 AM, Richard Biener wrote:

On Thu, Jan 31, 2019 at 3:45 PM Jakub Jelinek  wrote:


On Thu, Jan 31, 2019 at 09:30:13AM -0500, Aldy Hernandez wrote:

(LOOPS_HAVE_PREHEADERS).  This avoids unnecessary changes to the CFG.
But really, I'm just guessing here.  LOOPS_NORMAL would also work,
albeit creating forwarder blocks.

Tested on x86-64 Linux.

What do you think?


As far as I understand fold_return_value is true/false independent
of -W* flags (but dependent on -fprintf-return-value or so).  This means
that your patch avoids the risk of CFG changes dependent on
-W* flags.  This means you could safely use LOOPS_NORMAL


But isn't my code inside of ::execute, which is still gated by
fold_return_value AND all the -W* flags:?

bool
pass_sprintf_length::gate (function *)
{
   return ((warn_format_overflow > 0
  || warn_format_trunc > 0
  || flag_printf_return_value)
 && (optimize > 0) == fold_return_value);
}

Thus, I think we need to move the loop initialization somewhere else ??.


Then perhaps turn the gate into just return (optimize > 0) == fold_return_value;
and in execute do what you're adding and guard the rest with the above
condition?  As -fprintf-return-value is on by default for C-family, it shouldn't
change much.
+ adjust comment on the gate of course.


Don't you alreday have

@@ -4200,10 +4202,34 @@ pass_sprintf_length::execute (function *fun)
init_target_to_host_charmap ();

calculate_dominance_info (CDI_DOMINATORS);
+  bool optimizing_late = optimize > 0 && fold_return_value;
+  if (optimizing_late)
+{
+  /* ?? We should avoid changing the CFG as much as possible.
...
+  loop_optimizer_init (LOOPS_HAVE_PREHEADERS);
+  scev_initialize ();
+}

so loops are only initialized if fold_return_value is true?  Ah - but that's
the pass parameter from params.def rather than the flag to enable
the folding...  So indeed, change it to include && flag_printf_return_value


I believe the flag_printf_return_value change was the final agreed upon 
solution.


Tested on x86-64 Linux.

OK for trunk?

gcc/

	PR middle-end/85598
	* gimple-ssa-sprintf.c (pass_sprintf_length::execute): Enable loop
	analysis for pass.

diff --git a/gcc/gimple-ssa-sprintf.c b/gcc/gimple-ssa-sprintf.c
index 8e6016fc42f..48580411eb9 100644
--- a/gcc/gimple-ssa-sprintf.c
+++ b/gcc/gimple-ssa-sprintf.c
@@ -65,6 +65,8 @@ along with GCC; see the file COPYING3.  If not see
 #include "tree-ssa-propagate.h"
 #include "calls.h"
 #include "cfgloop.h"
+#include "tree-scalar-evolution.h"
+#include "tree-ssa-loop.h"
 #include "intl.h"
 #include "langhooks.h"
 
@@ -4200,10 +4202,22 @@ pass_sprintf_length::execute (function *fun)
   init_target_to_host_charmap ();
 
   calculate_dominance_info (CDI_DOMINATORS);
+  bool optimizing_late = optimize > 0 && flag_printf_return_value;
+  if (optimizing_late)
+{
+  loop_optimizer_init (LOOPS_NORMAL);
+  scev_initialize ();
+}
 
   sprintf_dom_walker sprintf_dom_walker;
   sprintf_dom_walker.walk (ENTRY_BLOCK_PTR_FOR_FN (fun));
 
+  if (optimizing_late)
+{
+  scev_finalize ();
+  loop_optimizer_finalize ();
+}
+
   /* Clean up object size info.  */
   fini_object_sizes ();
   return 0;
diff --git a/gcc/testsuite/gcc.dg/pr85598.c b/gcc/testsuite/gcc.dg/pr85598.c
new file mode 100644
index 000..c84b63f8084
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr85598.c
@@ -0,0 +1,16 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -Wall" } */
+
+typedef __SIZE_TYPE__ size_t;
+extern void __chk_fail (void);
+extern int snprintf (char *, size_t, const char *, ...);
+
+int main()
+{
+char temp[100];
+unsigned int x;
+char *str = temp;
+for(x=0; x<256; ++x) {
+  snprintf(str, 4, "%%%02X", x);
+}
+}

[libgo, testsuite] Skip runtime.TestG0StackOverflow on Solaris

[Rainer Orth]

One of the relatively few remaining libgo failures on Solaris is

--- FAIL: TestG0StackOverflow (2.17s)
crash_test.go:754: === RUN   TestG0StackOverflow

(exit status signal: Segmentation Fault)
FAIL
FAIL: runtime

Given that Solaris is a pthread target just like a bunch of others, it
seems that the test should skipped there as well.  Done with the
following patch, tested on i386-pc-solaris2.11 and
sparc-sun-solaris2.11.

This leaves only (in runtime)

--- FAIL: TestSelectStackAdjust (0.16s)
chan_test.go:728: failed to trigger concurrent GC

(both sparc and x86)

and

--- FAIL: TestPanicInlined (0.00s)
[...]
crash_test.go:566: expecting stack trace to contain call to point.negate

(sparc only).  I haven't yet investigated those.

Rainer

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


2019-02-22  Rainer Orth  

* go/runtime/crash_test.go (TestG0StackOverflow): Skip on solaris.

# HG changeset patch
# Parent  b4d1b955d0574477e08883eb0143e36610f99f8f
Skip runtime.TestG0StackOverflow on Solaris

diff --git a/libgo/go/runtime/crash_test.go b/libgo/go/runtime/crash_test.go
--- a/libgo/go/runtime/crash_test.go
+++ b/libgo/go/runtime/crash_test.go
@@ -741,7 +741,7 @@ func TestG0StackOverflow(t *testing.T) {
 	testenv.MustHaveExec(t)
 
 	switch runtime.GOOS {
-	case "darwin", "dragonfly", "freebsd", "linux", "netbsd", "openbsd", "android":
+	case "darwin", "dragonfly", "freebsd", "linux", "netbsd", "openbsd", "android", "solaris":
 		t.Skipf("g0 stack is wrong on pthread platforms (see golang.org/issue/26061)")
 	}
 

Re: [PATCH] Fix PR89437

[Richard Biener]

On Thu, Feb 21, 2019 at 6:09 PM Wilco Dijkstra  wrote:
>
> Hi Richard,
>
> >>Fix an issue with sinl (atanl (sqrtl (LDBL_MAX)) returning 0.0
> >>instead of 1.0 by using x < sqrtl (LDBL_MAX) in match.pd.
> >
> > Wasn't that a intermediate problem with the mpfr exponent range limiting?
> > Please check whether that's still needed.
>
> I tested it with trunk about an hour ago, and it included Jacub's patch.
> Are there other fixes outstanding which haven't been committed yet?

Not that I know of.  Did we root-cause the bogus folding to 0.0?  Because
I don't really understand why using < can "fix" this...

> Latest trunk also still gives an assertion failure in mpc with the 
> gcc.dg/torture/builtin-math-5.c
> which started at the same time as the other mpc/mpfr releated issues:
>
> build/src/mpc/src/pow.c:631: MPC assertion failed: z_imag || mpfr_number_p 
> (MPC_RE(u))
> build/src/gcc/gcc/testsuite/gcc.dg/torture/builtin-math-5.c:95:3: internal 
> compiler error: Aborted
> 0x6725ab crash_signal
> build/src/gcc/gcc/toplev.c:326

Ick.  Is there a PR about this?

Richard.

> Wilco

[PATCH] [NDS32] Fix nds32_split_ashiftdi3 with large shift amount

[Kito Cheng]

From: Kito Cheng 

ChangeLog:
gcc/
* config/nds32/nds32-md-auxiliary.c (nds32_split_ashiftdi3):
Fix wrong code gen with large shift amount.
---
 gcc/config/nds32/nds32-md-auxiliary.c | 21 ++---
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/gcc/config/nds32/nds32-md-auxiliary.c 
b/gcc/config/nds32/nds32-md-auxiliary.c
index 33844be..71fa421 100644
--- a/gcc/config/nds32/nds32-md-auxiliary.c
+++ b/gcc/config/nds32/nds32-md-auxiliary.c
@@ -3304,15 +3304,22 @@ nds32_split_ashiftdi3 (rtx dst, rtx src, rtx 
shiftamount)
   ext_start = gen_reg_rtx (SImode);
 
   /*
-if (shiftamount < 32)
+# In fact, we want to check shift amonut is great than or equal 32,
+# but in some corner case, the shift amount might be very large value,
+# however we've defined SHIFT_COUNT_TRUNCATED, so GCC think we've
+# handle that correctly without any truncate.
+# so check the the condition of (shiftamount & 32) is most
+# safe way to do.
+if (shiftamount & 32)
+  dst_low_part = 0
+  dst_high_part = src_low_part << shiftamount & 0x1f
+else
   dst_low_part = src_low_part << shiftamout
   dst_high_part = wext (src, 32 - shiftamount)
   # wext can't handle wext (src, 32) since it's only take rb[0:4]
   # for extract.
   dst_high_part = shiftamount == 0 ? src_high_part : dst_high_part
-else
-  dst_low_part = 0
-  dst_high_part = src_low_part << shiftamount & 0x1f
+
   */
 
   emit_insn (gen_subsi3 (ext_start,
@@ -3331,11 +3338,11 @@ nds32_split_ashiftdi3 (rtx dst, rtx src, rtx 
shiftamount)
   emit_insn (gen_ashlsi3 (dst_high_part_g32, src_low_part,
 new_shift_amout));
 
-  emit_insn (gen_slt_compare (select_reg, shiftamount, GEN_INT (32)));
+  emit_insn (gen_andsi3 (select_reg, shiftamount, GEN_INT (32)));
 
-  emit_insn (gen_cmovnsi (dst_low_part, select_reg,
+  emit_insn (gen_cmovzsi (dst_low_part, select_reg,
  dst_low_part_l32, dst_low_part_g32));
-  emit_insn (gen_cmovnsi (dst_high_part, select_reg,
+  emit_insn (gen_cmovzsi (dst_high_part, select_reg,
  dst_high_part_l32, dst_high_part_g32));
 }
 }
-- 
1.8.3.1

[PATCH][2/2] Fix PR87609

[Richard Biener]

This is the original patch adjusted to not remap clique == 1.

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

Richard.

2019-02-22  Richard Biener  

PR middle-end/87609
* cfghooks.h (dependence_hash): New typedef.
(struct copy_bb_data): New type.
(cfg_hooks::duplicate_block): Adjust to take a copy_bb_data argument.
(duplicate_block): Likewise.
* cfghooks.c (duplicate_block): Pass down copy_bb_data.
(copy_bbs): Create and pass down copy_bb_data.
* cfgrtl.c (cfg_layout_duplicate_bb): Adjust.
(rtl_duplicate_bb): Likewise.
* tree-cfg.c (gimple_duplicate_bb): If the copy_bb_data arg is not NULL
remap dependence info.

* gcc.dg/torture/restrict-7.c: New testcase.

Index: gcc/cfghooks.c
===
--- gcc/cfghooks.c  (revision 269067)
+++ gcc/cfghooks.c  (working copy)
@@ -1066,7 +1066,7 @@ can_duplicate_block_p (const_basic_block
AFTER.  */
 
 basic_block
-duplicate_block (basic_block bb, edge e, basic_block after)
+duplicate_block (basic_block bb, edge e, basic_block after, copy_bb_data *id)
 {
   edge s, n;
   basic_block new_bb;
@@ -1082,7 +1082,7 @@ duplicate_block (basic_block bb, edge e,
 
   gcc_checking_assert (can_duplicate_block_p (bb));
 
-  new_bb = cfg_hooks->duplicate_block (bb);
+  new_bb = cfg_hooks->duplicate_block (bb, id);
   if (after)
 move_block_after (new_bb, after);
 
@@ -1337,6 +1337,7 @@ copy_bbs (basic_block *bbs, unsigned n,
   unsigned i, j;
   basic_block bb, new_bb, dom_bb;
   edge e;
+  copy_bb_data id;
 
   /* Mark the blocks to be copied.  This is used by edge creation hooks
  to decide whether to reallocate PHI nodes capacity to avoid reallocating
@@ -1349,7 +1350,7 @@ copy_bbs (basic_block *bbs, unsigned n,
 {
   /* Duplicate.  */
   bb = bbs[i];
-  new_bb = new_bbs[i] = duplicate_block (bb, NULL, after);
+  new_bb = new_bbs[i] = duplicate_block (bb, NULL, after, );
   after = new_bb;
   if (bb->loop_father)
{
Index: gcc/cfghooks.h
===
--- gcc/cfghooks.h  (revision 269067)
+++ gcc/cfghooks.h  (working copy)
@@ -54,6 +54,19 @@ struct profile_record
   bool run;
 };
 
+typedef int_hash  dependence_hash;
+
+/* Optional data for duplicate_block.   */
+
+struct copy_bb_data
+{
+  copy_bb_data() : dependence_map (NULL) {}
+  ~copy_bb_data () { delete dependence_map; }
+
+  /* A map from the copied BBs dependence info cliques to
+ equivalents in the BBs duplicated to.  */
+  hash_map *dependence_map;
+};
 
 struct cfg_hooks
 {
@@ -112,7 +125,7 @@ struct cfg_hooks
   bool (*can_duplicate_block_p) (const_basic_block a);
 
   /* Duplicate block A.  */
-  basic_block (*duplicate_block) (basic_block a);
+  basic_block (*duplicate_block) (basic_block a, copy_bb_data *);
 
   /* Higher level functions representable by primitive operations above if
  we didn't have some oddities in RTL and Tree representations.  */
@@ -227,7 +240,8 @@ extern void tidy_fallthru_edges (void);
 extern void predict_edge (edge e, enum br_predictor predictor, int 
probability);
 extern bool predicted_by_p (const_basic_block bb, enum br_predictor predictor);
 extern bool can_duplicate_block_p (const_basic_block);
-extern basic_block duplicate_block (basic_block, edge, basic_block);
+extern basic_block duplicate_block (basic_block, edge, basic_block,
+   copy_bb_data * = NULL);
 extern bool block_ends_with_call_p (basic_block bb);
 extern bool empty_block_p (basic_block);
 extern basic_block split_block_before_cond_jump (basic_block);
Index: gcc/cfgrtl.c
===
--- gcc/cfgrtl.c(revision 269067)
+++ gcc/cfgrtl.c(working copy)
@@ -4250,7 +4250,7 @@ duplicate_insn_chain (rtx_insn *from, rt
 /* Create a duplicate of the basic block BB.  */
 
 static basic_block
-cfg_layout_duplicate_bb (basic_block bb)
+cfg_layout_duplicate_bb (basic_block bb, copy_bb_data *)
 {
   rtx_insn *insn;
   basic_block new_bb;
@@ -5080,9 +5080,9 @@ rtl_can_remove_branch_p (const_edge e)
 }
 
 static basic_block
-rtl_duplicate_bb (basic_block bb)
+rtl_duplicate_bb (basic_block bb, copy_bb_data *id)
 {
-  bb = cfg_layout_duplicate_bb (bb);
+  bb = cfg_layout_duplicate_bb (bb, id);
   bb->aux = NULL;
   return bb;
 }
Index: gcc/testsuite/gcc.dg/torture/restrict-7.c
===
--- gcc/testsuite/gcc.dg/torture/restrict-7.c   (nonexistent)
+++ gcc/testsuite/gcc.dg/torture/restrict-7.c   (working copy)
@@ -0,0 +1,27 @@
+/* { dg-do run } */
+
+extern void abort (void);
+
+static inline __attribute__((always_inline)) void
+copy(int *restrict a, int *restrict b)
+{
+  *b = *a;
+  *a = 7;
+}
+
+void __attribute__((noinline))
+floppy(int mat[static 2], unsigned idxs[static 3])
+{

[PATCH][1/2] Fix PR87609

[Richard Biener]

This is a followup on the earlier RFC I sent in October.  It implements
a less restrictive variant by partitioning the clique set into problematic
(have to remap on BB copy) and non-problematic ones.  The single
non-problematic one is where the scope of the restrict affected refs
is the whole function (clique == 1) while all other cliques get
introduced via inlining and subsequent copying of inlined blocks.

The first patch performs this partitioning, the second one will add
the clique remapping on BB copying.

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

Richard.

2019-02-22  Richard Biener  

PR tree-optimization/87609
* tree-core.h (tree_base): Document special clique values.
* tree-inline.c (remap_dependence_clique): Do not use the
special clique value of one.
(maybe_set_dependence_info): Use clique one.
(clear_dependence_clique): New callback.
(compute_dependence_clique): Clear clique one from all refs
before assigning it (again).

Index: gcc/tree-core.h
===
--- gcc/tree-core.h (revision 269034)
+++ gcc/tree-core.h (working copy)
@@ -1032,7 +1032,9 @@ struct GTY(()) tree_base {
expression trees and specify known data non-dependences.  For
two memory references in a function they are known to not
alias if dependence_info.clique are equal and dependence_info.base
-   are distinct.  */
+   are distinct.  Clique number zero means there is no information,
+   clique number one is populated from function global information
+   and thus needs no remapping on transforms like loop unrolling.  */
 struct {
   unsigned short clique;
   unsigned short base;
Index: gcc/tree-inline.c
===
--- gcc/tree-inline.c   (revision 269034)
+++ gcc/tree-inline.c   (working copy)
@@ -911,7 +911,12 @@ remap_dependence_clique (copy_body_data
   bool existed;
   unsigned short  = id->dependence_map->get_or_insert (clique, );
   if (!existed)
-newc = ++cfun->last_clique;
+{
+  /* Clique 1 is reserved for local ones set by PTA.  */
+  if (cfun->last_clique == 0)
+   cfun->last_clique = 1;
+  newc = ++cfun->last_clique;
+}
   return newc;
 }
 
Index: gcc/tree-ssa-structalias.c
===
--- gcc/tree-ssa-structalias.c  (revision 269034)
+++ gcc/tree-ssa-structalias.c  (working copy)
@@ -7495,7 +7495,11 @@ maybe_set_dependence_info (gimple *, tre
   if (MR_DEPENDENCE_CLIQUE (base) == 0)
{
  if (clique == 0)
-   clique = ++cfun->last_clique;
+   {
+ if (cfun->last_clique == 0)
+   cfun->last_clique = 1;
+ clique = 1;
+   }
  if (restrict_var->ruid == 0)
restrict_var->ruid = ++last_ruid;
  MR_DEPENDENCE_CLIQUE (base) = clique;
@@ -7506,12 +7510,42 @@ maybe_set_dependence_info (gimple *, tre
   return false;
 }
 
+/* Clear dependence info for the clique DATA.  */
+
+static bool
+clear_dependence_clique (gimple *, tree base, tree, void *data)
+{
+  unsigned short clique = (uintptr_t)data;
+  if ((TREE_CODE (base) == MEM_REF
+   || TREE_CODE (base) == TARGET_MEM_REF)
+  && MR_DEPENDENCE_CLIQUE (base) == clique)
+{
+  MR_DEPENDENCE_CLIQUE (base) = 0;
+  MR_DEPENDENCE_BASE (base) = 0;
+}
+
+  return false;
+}
+
 /* Compute the set of independend memory references based on restrict
tags and their conservative propagation to the points-to sets.  */
 
 static void
 compute_dependence_clique (void)
 {
+  /* First clear the special "local" clique.  */
+  basic_block bb;
+  if (cfun->last_clique != 0)
+FOR_EACH_BB_FN (bb, cfun)
+  for (gimple_stmt_iterator gsi = gsi_start_bb (bb);
+  !gsi_end_p (gsi); gsi_next ())
+   {
+ gimple *stmt = gsi_stmt (gsi);
+ walk_stmt_load_store_ops (stmt, (void *)(uintptr_t) 1,
+   clear_dependence_clique,
+   clear_dependence_clique);
+   }
+
   unsigned short clique = 0;
   unsigned short last_ruid = 0;
   bitmap rvars = BITMAP_ALLOC (NULL);