[PATCH] Rope iterators: don't retain pointers when copied

[Jeremy Sawicki]

Rope iterators sometimes contain pointers to an internal buffer
inside the iterator itself.  When such an iterator is copied, the
copy incorrectly retains pointers to the original.

This patch takes the simple approach of not copying the cached
information when the internal buffer is being used, instead
requiring it to be recomputed when the copied iterator is
dereferenced.  An alternative would be to adjust the pointers so
they refer to the buffer in the copy.

I tested on Linux x64 with "/configure", "make bootstrap",
and "make -k check", three times: (1) with no changes (as a
baseline), (2) with only the new test (to make sure it fails), and
(3) with the new test and bug fix (to make sure the test passes and
nothing else changes).


* include/ext/rope (_Rope_iterator_base(const _Rope_iterator_base&))
(_Rope_const_iterator::operator=(const _Rope_const_iterator&))
(_Rope_iterator::operator=(const _Rope_iterator&)):
Copied/assigned rope iterators don't retain pointers to the
iterator they were copied/assigned from.
* testsuite/ext/rope/7.cc: New.

Index: libstdc++-v3/include/ext/rope
===
--- libstdc++-v3/include/ext/rope   (revision 260403)
+++ libstdc++-v3/include/ext/rope   (working copy)
@@ -1119,7 +1119,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   _Rope_iterator_base(const _Rope_iterator_base& __x)
   {
-if (0 != __x._M_buf_ptr)
+if (0 != __x._M_buf_ptr && __x._M_buf_start != __x._M_tmp_buf)
  *this = __x;
else
  {
@@ -1166,7 +1166,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   _Rope_const_iterator&
   operator=(const _Rope_const_iterator& __x)
   {
-if (0 != __x._M_buf_ptr)
+if (0 != __x._M_buf_ptr && __x._M_buf_start != __x._M_tmp_buf)
  *(static_cast<_Rope_iterator_base<_CharT, _Alloc>*>(this)) = __x;
else
  {
@@ -1345,7 +1345,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 _RopeRep* __old = this->_M_root;

 _RopeRep::_S_ref(__x._M_root);
-if (0 != __x._M_buf_ptr)
+if (0 != __x._M_buf_ptr && __x._M_buf_start != __x._M_tmp_buf)
  {
 _M_root_rope = __x._M_root_rope;
 *(static_cast<_Rope_iterator_base<_CharT, _Alloc>*>(this)) = __x;
Index: libstdc++-v3/testsuite/ext/rope/7.cc
===
--- libstdc++-v3/testsuite/ext/rope/7.cc(nonexistent)
+++ libstdc++-v3/testsuite/ext/rope/7.cc(working copy)
@@ -0,0 +1,95 @@
+// Copyright (C) 2018 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
+// .
+
+// rope (SGI extension)
+
+// { dg-do run }
+
+#include 
+#include 
+
+void
+test01()
+{
+  using __gnu_cxx::crope;
+
+  char str_a[] =
+""
+""
+""
+""
+"";
+  char str_b[] =
+""
+""
+""
+""
+"";
+
+  // Create ropes with leaf nodes longer than __lazy_threshold = 128
+  // so substring nodes will be created by the next step
+  crope leaf_rope_a(str_a);
+  crope leaf_rope_b(str_b);
+
+  // Create ropes with substring nodes referencing the leaf nodes
+  // of the prior ropes
+  crope substring_rope_a(leaf_rope_a.begin() + 1,
+ leaf_rope_a.begin() + 199);
+  crope substring_rope_b(leaf_rope_b.begin() + 1,
+ leaf_rope_b.begin() + 199);
+
+  // Create iterators to substring_rope_a
+  crope::const_iterator cit_orig = substring_rope_a.begin();
+  crope::iterator mit_orig = substring_rope_a.mutable_begin();
+
+  // Dereference the iterators so they cache a portion of the substring
+  // node in their internal buffers
+  *cit_orig;
+  *mit_orig;
+
+  // Copy the original iterators, via both copy constructors and
+  // assignment operators.  Prior to the bug fix, these iterators
+  // retained pointers to the internal 

[PATCH] Add a comma to comment in lower_eh_constructs_2

[Zhouyi Zhou]

Hi

I think the comment in lower_eh_constructs_2 need a comma.

And I don't have write permission to GCC.

Bootstraped on x86-64

Thanks,
Zhouyi

Signed-off-by: Zhouyi Zhou 

gcc/ChangeLog:

2018-05-21 Zhouyi Zhou 
* tree-eh.c (lower_eh_constructs_2): Add a comma to comment.

---
 gcc/tree-eh.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/tree-eh.c b/gcc/tree-eh.c
index 30c6d9e..06fe748 100644
--- a/gcc/tree-eh.c
+++ b/gcc/tree-eh.c
@@ -2028,7 +2028,7 @@ lower_eh_constructs_2 (struct leh_state *state, 
gimple_stmt_iterator *gsi)
   /* FALLTHRU */
 
 case GIMPLE_ASSIGN:
-  /* If the stmt can throw use a new temporary for the assignment
+  /* If the stmt can throw, use a new temporary for the assignment
  to a LHS.  This makes sure the old value of the LHS is
 available on the EH edge.  Only do so for statements that
 potentially fall through (no noreturn calls e.g.), otherwise
-- 
2.1.4

Re: [PATCH] PR libstdc++/85843 fix "should be explicitly initialized" warnings

[Jason Merrill]

On Sun, May 20, 2018 at 7:50 PM, Jonathan Wakely  wrote:
> PR libstdc++/85843
> * src/c++11/cow-stdexcept.cc (logic_error, runtime_error): Explicitly
> initialize base class to avoid warnings.

And this patch fixes the warning to treat defaulted constructors the
same as implicitly-declared constructors.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit b4bb335521d3993cc3fac3295d0461c376d52907
Author: Jason Merrill 
Date:   Sun May 20 22:26:04 2018 -0400

PR libstdc++/85843 - warning in logic_error copy constructor.

* class.c (type_has_user_nondefault_constructor): Check for a
user-provided ctor, not user-declared.

diff --git a/gcc/cp/class.c b/gcc/cp/class.c
index 4960b4b5593..a9a0fa92727 100644
--- a/gcc/cp/class.c
+++ b/gcc/cp/class.c
@@ -4884,7 +4884,7 @@ default_ctor_p (tree fn)
 	  && sufficient_parms_p (FUNCTION_FIRST_USER_PARMTYPE (fn)));
 }
 
-/* Returns true iff class T has a user-defined constructor that can be called
+/* Returns true iff class T has a user-provided constructor that can be called
with more than zero arguments.  */
 
 bool
@@ -4896,7 +4896,7 @@ type_has_user_nondefault_constructor (tree t)
   for (ovl_iterator iter (CLASSTYPE_CONSTRUCTORS (t)); iter; ++iter)
 {
   tree fn = *iter;
-  if (!DECL_ARTIFICIAL (fn)
+  if (user_provided_p (fn)
 	  && (TREE_CODE (fn) == TEMPLATE_DECL
 	  || (skip_artificial_parms_for (fn, DECL_ARGUMENTS (fn))
 		  != NULL_TREE)))
diff --git a/gcc/testsuite/g++.dg/warn/Wextra-4.C b/gcc/testsuite/g++.dg/warn/Wextra-4.C
new file mode 100644
index 000..5c33c271154
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/Wextra-4.C
@@ -0,0 +1,15 @@
+// PR libstdc++/85843
+// { dg-do compile { target c++11 } }
+// { dg-additional-options -Wextra }
+
+struct A
+{
+  A();
+  A(const A&) = default;
+};
+
+struct B : A
+{
+  B(): A() { }
+  B(const B&) { }
+};

Important, please!

[T. K Acharya]

Hello,

Did you receive my previous email? 

Pls inform. 

Best regards, 
T. K Acharya

[PATCH] PR libstdc++/85843 fix "should be explicitly initialized" warnings

[Jonathan Wakely]

PR libstdc++/85843
* src/c++11/cow-stdexcept.cc (logic_error, runtime_error): Explicitly
initialize base class to avoid warnings.

Tested powerpc64le-linux, committed to trunk.


commit e64c045676caee3153d62bdaaf207bb331f10d3d
Author: Jonathan Wakely 
Date:   Mon May 21 00:24:05 2018 +0100

PR libstdc++/85843 fix "should be explicitly initialized" warnings

PR libstdc++/85843
* src/c++11/cow-stdexcept.cc (logic_error, runtime_error): 
Explicitly
initialize base class to avoid warnings.

diff --git a/libstdc++-v3/src/c++11/cow-stdexcept.cc 
b/libstdc++-v3/src/c++11/cow-stdexcept.cc
index 7b42da1e133..5ad3d94ae31 100644
--- a/libstdc++-v3/src/c++11/cow-stdexcept.cc
+++ b/libstdc++-v3/src/c++11/cow-stdexcept.cc
@@ -56,13 +56,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   // Copy constructors and assignment operators defined using COW std::string
 
   logic_error::logic_error(const logic_error& e) noexcept
-  : _M_msg(e._M_msg) { }
+  : exception(e), _M_msg(e._M_msg) { }
 
   logic_error& logic_error::operator=(const logic_error& e) noexcept
   { _M_msg = e._M_msg; return *this; }
 
   runtime_error::runtime_error(const runtime_error& e) noexcept
-  : _M_msg(e._M_msg) { }
+  : exception(e), _M_msg(e._M_msg) { }
 
   runtime_error&
   runtime_error::operator=(const runtime_error& e) noexcept

Re: [Patch, Fortran] PR 85841: [F2018] reject deleted features

[Steve Kargl]

On Sun, May 20, 2018 at 09:44:47PM +0200, Janus Weil wrote:
> 
> >> The patch still regtests cleanly. Ok for trunk?
> >
> > Patch looks good to me.  The only thing that worries me is
> > whether the patch will cause the SPEC benchmark to throw
> > an error or warning that it did not before.  As I don't have
> > SPEC benchmark and it cost $$$, I'm not going to let it
> > bother too much.
> 
> Unfortunately I don't have access to SPEC either. Is anyone in a
> position to check this?

We'll find out evidently as one of the C/C++ developers run SPEC.

> If it is indeed a problem, I could remove the warning for the F2018
> deleted features with default flags (-std=gnu). However, I'd only like
> to do that if it's really necessary.

I would rather see the warnings to encourage users to fix
their codes.  If they don't want to see the warnings, they
can use -w.

> >> Btw, with the arrival of the F2018 standard, I wonder whether it
> >> actually makes sense to keep the option -std=f2008ts, or to remove it
> >> in favor of -std=f2018, since the two Technical Specifications covered
> >> by this flag are now part of F2018 (and pretty much the main part!).
> >> Any opinions on this?
> >
> > I think that f2008ts can go away.  We may need to do this
> > in two step as some users may have f2008ts hardcoded in
> > Makefiles.  Probably, issue warning for -std=2008ts and
> > map it to -std=2018 for a brief period (3 to 6 months?)
> > and then finally remove it.
> 
> Yes, I agree that it would be a good idea to keep -std=f2008ts as an
> alias for f2018 for a while (possibly until the next release, 9.0),
> and document is as deprecated. I can take care of removing the
> GFC_STD_F2008_TS macro in a follow-up patch.

Sounds good to me.

> Actually there is one other thing I do not like about my previous
> patch: The duplication of GFC_STD_* flags in gfc_match_stopcode. To
> get rid of this, I'm introducing additional macros in libgfortran.h,
> see new patch in the attachment. I hope you agree that this is an
> improvement. (Again: Regtests cleanly.)

Again, looks good.  Thanks for doing a boring janitor task of
cleaning up loose ends.  Welcome back to gfortran development.
Please stay away, we can use the help. :-)

-- 
steve

Re: [wwwdocs] Buildstat update for 5.5

[Gerald Pfeifer]

On Sat, 19 May 2018, Tom G. Christensen wrote:
> Here's an update covering gcc 5.5.0.

Thanks, applied.

Gerald

Re: Fix Bug 83566 - cyl_bessel_j returns wrong result for x>1000 for high orders

[Michele Pezzutti]

Hi.

This patch intends to fix Bug 83566 - cyl_bessel_j returns wrong result 
for x>1000 for high orders.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83566 for issue 
description.


    * libstdc++-v3/include/tr1/bessel_function.tcc
  Series expansion in __cyl_bessel_jn_asymp() shall not be 
truncated at the first terms.
  At least nu/2 terms shall be added, in order to have a guaranteed 
error bound.


    * 
libstdc++-v3/testsuite/tr1/5_numerical_facilities/special_functions/09_cyl_bessel_j/check_value.cc

  Testcase for x > 1000 added.

    * 
libstdc++-v3/testsuite/tr1/5_numerical_facilities/special_functions/11_cyl_neumann/check_value.cc

  Testcase for x > 1000 added.

    * 
libstdc++-v3/testsuite/special_functions/08_cyl_bessel_j/check_value.cc

  Testcase for x > 1000 added.


    * 
libstdc++-v3/testsuite/special_functions/10_cyl_neumann/check_value.cc

  Testcase for x > 1000 added.


diff --git a/libstdc++-v3/include/tr1/bessel_function.tcc 
b/libstdc++-v3/include/tr1/bessel_function.tcc

index 26c66cabe29..7b94b84a6ea 100644
--- a/libstdc++-v3/include/tr1/bessel_function.tcc
+++ b/libstdc++-v3/include/tr1/bessel_function.tcc
@@ -27,6 +27,10 @@
  *  Do not attempt to use it directly. @headername{tr1/cmath}
  */

+/* __cyl_bessel_jn_asymp adapted from GNU GSL version 2.4 
specfunc/bessel_j.c

+ * Copyright (C) 1996-2003 Gerard Jungman
+ */
+
 //
 // ISO C++ 14882 TR1: 5.2  Special functions
 //
@@ -358,24 +362,51 @@ namespace tr1
 void
 __cyl_bessel_jn_asymp(_Tp __nu, _Tp __x, _Tp & __Jnu, _Tp & __Nnu)
 {
-  const _Tp __mu   = _Tp(4) * __nu * __nu;
-  const _Tp __mum1 = __mu - _Tp(1);
-  const _Tp __mum9 = __mu - _Tp(9);
-  const _Tp __mum25 = __mu - _Tp(25);
-  const _Tp __mum49 = __mu - _Tp(49);
-  const _Tp __xx = _Tp(64) * __x * __x;
-  const _Tp __P = _Tp(1) - __mum1 * __mum9 / (_Tp(2) * __xx)
-    * (_Tp(1) - __mum25 * __mum49 / (_Tp(12) * __xx));
-  const _Tp __Q = __mum1 / (_Tp(8) * __x)
-    * (_Tp(1) - __mum9 * __mum25 / (_Tp(6) * __xx));
+  const _Tp __mu = _Tp(4) * __nu * __nu;
+  const _Tp __8x = _Tp(8) * __x;
+
+  _Tp __P = _Tp(0);
+  _Tp __Q = _Tp(0);
+
+  _Tp __k = _Tp(0);
+  _Tp __term = _Tp(1);
+
+  int __epsP = 0;
+  int __epsQ = 0;
+
+  _Tp __eps = std::numeric_limits<_Tp>::epsilon();
+
+  do
+    {
+  __term *= (__k == 0
+ ? _Tp(1)
+ : -(__mu - (2 * __k - 1) * (2 * __k - 1)) / (__k * 
__8x));

+
+  __epsP = std::abs(__term) < __eps * std::abs(__P);
+  __P += __term;
+
+  __k++;
+
+  __term *= (__mu - (2 * __k - 1) * (2 * __k - 1)) / (__k * __8x);
+  __epsQ = std::abs(__term) < __eps * std::abs(__Q);
+  __Q += __term;
+
+  if (__epsP && __epsQ && __k > (__nu / 2.))
+    break;
+
+  __k++;
+    }
+  while (__k < 1000);

   const _Tp __chi = __x - (__nu + _Tp(0.5L))
-    * __numeric_constants<_Tp>::__pi_2();
+ * __numeric_constants<_Tp>::__pi_2();
+
   const _Tp __c = std::cos(__chi);
   const _Tp __s = std::sin(__chi);

   const _Tp __coef = std::sqrt(_Tp(2)
  / (__numeric_constants<_Tp>::__pi() * __x));
+
   __Jnu = __coef * (__c * __P - __s * __Q);
   __Nnu = __coef * (__s * __P + __c * __Q);

diff --git 
a/libstdc++-v3/testsuite/special_functions/08_cyl_bessel_j/check_value.cc 
b/libstdc++-v3/testsuite/special_functions/08_cyl_bessel_j/check_value.cc

index 475c6dcaa4a..7900af3c959 100644
--- 
a/libstdc++-v3/testsuite/special_functions/08_cyl_bessel_j/check_value.cc
+++ 
b/libstdc++-v3/testsuite/special_functions/08_cyl_bessel_j/check_value.cc

@@ -698,6 +698,39 @@ data026[21] =
 };
 const double toler026 = 1.0006e-11;

+// Test data for nu=100.
+// max(|f - f_GSL|): 3.9438938226332709e-14 at index 19
+// max(|f - f_GSL| / |f_GSL|): 2.0193411077170867e-11
+// mean(f - f_GSL): 1.6682360684660055e-15
+// variance(f - f_GSL): 5.3274331668346898e-28
+// stddev(f - f_GSL): 2.3081232997469372e-14
+const testcase_cyl_bessel_j
+data027[21] =
+{
+  {  1.1676135007789573e-02, 100., 
1000., 0.0 },
+  { -1.1699854778025796e-02, 100., 
1100., 0.0 },
+  { -2.2801483405083697e-02, 100., 
1200., 0.0 },
+  { -1.6973500787373915e-02, 100., 
1300., 0.0 },
+  { -1.4154528803481308e-03, 100., 
1400., 0.0 },
+  {  1.726584495232e-02, 100., 
1500., 0.0 },
+  {  1.9802562020148559e-02, 100., 
1600., 0.0 },
+  {  1.6129771279838816e-02, 100., 
1700., 0.0 },
+  {  5.3753369281536031e-03, 100., 
1800., 0.0 },
+ 

Re: [wwwdocs] Buildstat update for 5.x

[Gerald Pfeifer]

On Sat, 19 May 2018, Tom G. Christensen wrote:
> Going through the archives I found two results missing from the
> buildstat page.

Thanks, Tom!  I applied this.

Gerald

[wwwdocs PATCH] for Re: Policy for reverting someone else commit?

[Gerald Pfeifer]

On Sun, 20 May 2018, Richard Biener wrote:
> IIRC there is a 24h rule that global maintainers can invoke. Not 
> sure if that is formally documented somewhere.

Yes, we have a reversion policy; it is documented at

  https://gcc.gnu.org/develop.html

And, after me just having applied the patch below, now 
directly reachable at

  https://gcc.gnu.org/develop.html#reversion 

Gerald

Index: develop.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/develop.html,v
retrieving revision 1.180
diff -u -r1.180 develop.html
--- develop.html25 Apr 2018 08:44:26 -  1.180
+++ develop.html20 May 2018 20:20:35 -
@@ -154,7 +154,7 @@
 so it is unlikely that many conflicts will occur.
 
 
-Patch Reversion
+Patch Reversion
 
 If a patch is committed which introduces a regression on any target
 which the Steering Committee considers to be important and if:

[og7] Re: Forwarding -foffload=[...] from the driver (compile-time) to libgomp (run-time)

[Thomas Schwinge]

Hi!

(This whole idea/patch still needs an overall re-work, as discussed, but
here is a small incremental improvement/bug fix.)

On Thu, 20 Aug 2015 22:52:58 +, Joseph Myers  
wrote:
> On Tue, 18 Aug 2015, Thomas Schwinge wrote:
> > [...] here is my current messy WIP patch [...]

> +/* List of offload targets, separated by colon.  Defaults to the list
> +   determined when configuring libgomp.  */
> +static const char *gomp_offload_targets = OFFLOAD_TARGETS;
> +static bool gomp_offload_targets_init = false;
> +
> +/* Override the list of offload targets.  This must be called early, and only
> +   once.  */
> +
> +void
> +GOMP_set_offload_targets (const char *offload_targets)
> +{
> +  gomp_debug (0, "%s (\"%s\")\n", __FUNCTION__, offload_targets);
> +
> +  /* Make sure this gets called early.  */
> +  assert (gomp_is_initialized == PTHREAD_ONCE_INIT);
> +  /* Make sure this only gets called once.  */
> +  assert (!gomp_offload_targets_init);
> +  gomp_offload_targets_init = true;
> +  gomp_offload_targets = offload_targets;
> +}

This will obviously fail as soon as there are shared libraries involved,
compiled for offloading, which contain additional
GOMP_set_offload_targets constructor calls.  Thus pushed to
openacc-gcc-7-branch:

commit 917e247055a37f912129ed545719182de0046adb
Author: Thomas Schwinge 
Date:   Sun May 20 21:31:01 2018 +0200

[PR81886] Avoid "GOMP_set_offload_targets: Assertion 
`!gomp_offload_targets_init' failed"

PR libgomp/81886
* openacc.h (enum acc_device_t): Add _acc_device_intel_mic,
_acc_device_hsa.
* oacc-init.c (get_openacc_name): Handle these.
(resolve_device): Debugging output.
* target.c (resolve_device, gomp_init_device)
(gomp_offload_target_available_p): Likewise.
(GOMP_set_offload_targets): Rewrite.
* testsuite/libgomp.oacc-c++/c++.exp: Provide offload target in
"-DACC_DEVICE_TYPE_host", and "-DACC_DEVICE_TYPE_nvidia".
* testsuite/libgomp.oacc-c/c.exp: Likewise.
* testsuite/libgomp.oacc-fortran/fortran.exp: Likewise.
* testsuite/libgomp.oacc-c/offload-targets-1.c: New file.
* testsuite/libgomp.oacc-c/offload-targets-2.c: Likewise.
* testsuite/libgomp.oacc-c/offload-targets-3.c: Likewise.
* testsuite/libgomp.oacc-c/offload-targets-4.c: Likewise.
* testsuite/libgomp.oacc-c/offload-targets-5.c: Likewise.
* testsuite/libgomp.oacc-c/offload-targets-6.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/acc-on-device-2.c: Adjust.
* testsuite/libgomp.oacc-c-c++-common/acc_on_device-1.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/pr85381-2.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/pr85381-3.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/pr85381-4.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/pr85381-5.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/pr85381.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/pr85486-2.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/pr85486-3.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/pr85486.c: Likewise.
* testsuite/libgomp.oacc-fortran/acc_on_device-1-1.f90: Likewise.
* testsuite/libgomp.oacc-fortran/acc_on_device-1-2.f: Likewise.
* testsuite/libgomp.oacc-fortran/acc_on_device-1-3.f: Likewise.
---
 libgomp/ChangeLog.openacc  |  34 
 libgomp/oacc-init.c|   7 +
 libgomp/openacc.h  |   2 +
 libgomp/target.c   | 178 +++--
 libgomp/testsuite/libgomp.oacc-c++/c++.exp |   4 +-
 .../libgomp.oacc-c-c++-common/acc-on-device-2.c|   2 +-
 .../libgomp.oacc-c-c++-common/acc_on_device-1.c|   4 +-
 .../libgomp.oacc-c-c++-common/pr85381-2.c  |   3 +-
 .../libgomp.oacc-c-c++-common/pr85381-3.c  |   3 +-
 .../libgomp.oacc-c-c++-common/pr85381-4.c  |   3 +-
 .../libgomp.oacc-c-c++-common/pr85381-5.c  |   3 +-
 .../testsuite/libgomp.oacc-c-c++-common/pr85381.c  |   3 +-
 .../libgomp.oacc-c-c++-common/pr85486-2.c  |   3 +-
 .../libgomp.oacc-c-c++-common/pr85486-3.c  |   3 +-
 .../testsuite/libgomp.oacc-c-c++-common/pr85486.c  |   3 +-
 libgomp/testsuite/libgomp.oacc-c/c.exp |   4 +-
 .../testsuite/libgomp.oacc-c/offload-targets-1.c   | 119 ++
 .../testsuite/libgomp.oacc-c/offload-targets-2.c   |   2 +
 .../testsuite/libgomp.oacc-c/offload-targets-3.c   |  10 ++
 .../testsuite/libgomp.oacc-c/offload-targets-4.c   |  11 ++
 .../testsuite/libgomp.oacc-c/offload-targets-5.c   |  10 ++
 .../testsuite/libgomp.oacc-c/offload-targets-6.c   |  11 ++
 

[PATCHv2] PR 85822 - Fix handling of negative constants

[Yuri Gribov]

On Sun, May 20, 2018 at 1:01 PM, Alexander Monakov  wrote:
> On Sun, 20 May 2018, Yuri Gribov wrote:
>
>> Hi all,
>>
>> This fixes PR 85822 by removing incorrect reversal of condition in VRP
>> assertion. Bootstrapped and regtested on x86_64.
>>
>> Ok for trunk?
>
> Please address the following issues:
>
> Use correct PR reference in Changelog.

Ah, right.

> Double-check the comment before the function, I think NE_EXPR and EQ_EXPR
> should be swapped there.

Thanks, fixed.

> Address Richard's request from the bug report:
>
>>> Ok, please make sure to say why not doing anything special for negative
>>> numbers is ok.

True, I didn't notice the "to say" part :/

Comparison
  (a & 11...100...0) == XX...X00..0  // RHS XX...X is covered by
11...100...0 mask i.e. (RHS & MASK) == RHS
means that 'a' can have values
  XX...X00...00
  XX...X00...01
  XX...X00...10
  ...
  XX...X11...11
Both for positive and negative, signed and unsigned RHSs the first
number is less than the last one so we can derive
  XX...X00...00 <= a
  a <= XX...X11...11
in all cases.

> Note there are at least three special cases that are handled incorrectly 
> either
> before or after the patch:
>
>  - not two's complement integers

Commented by Richard.

>  - mask being 0
>  - mask being ~0

Done (AND with 0 or -1 is removed during Gimple generation so I didn't
bother to optimize this special case, just bail out).

-Y


pr85822-2.patch
Description: Binary data

Re: [Patch, Fortran] PR 85841: [F2018] reject deleted features

[Janus Weil]

Hi Steve,

thanks for your comments!

>> The patch still regtests cleanly. Ok for trunk?
>
> Patch looks good to me.  The only thing that worries me is
> whether the patch will cause the SPEC benchmark to throw
> an error or warning that it did not before.  As I don't have
> SPEC benchmark and it cost $$$, I'm not going to let it
> bother too much.

Unfortunately I don't have access to SPEC either. Is anyone in a
position to check this?

If it is indeed a problem, I could remove the warning for the F2018
deleted features with default flags (-std=gnu). However, I'd only like
to do that if it's really necessary.


>> Btw, with the arrival of the F2018 standard, I wonder whether it
>> actually makes sense to keep the option -std=f2008ts, or to remove it
>> in favor of -std=f2018, since the two Technical Specifications covered
>> by this flag are now part of F2018 (and pretty much the main part!).
>> Any opinions on this?
>
> I think that f2008ts can go away.  We may need to do this
> in two step as some users may have f2008ts hardcoded in
> Makefiles.  Probably, issue warning for -std=2008ts and
> map it to -std=2018 for a brief period (3 to 6 months?)
> and then finally remove it.

Yes, I agree that it would be a good idea to keep -std=f2008ts as an
alias for f2018 for a while (possibly until the next release, 9.0),
and document is as deprecated. I can take care of removing the
GFC_STD_F2008_TS macro in a follow-up patch.


Actually there is one other thing I do not like about my previous
patch: The duplication of GFC_STD_* flags in gfc_match_stopcode. To
get rid of this, I'm introducing additional macros in libgfortran.h,
see new patch in the attachment. I hope you agree that this is an
improvement. (Again: Regtests cleanly.)

Cheers,
Janus
Index: gcc/fortran/error.c
===
--- gcc/fortran/error.c	(revision 260420)
+++ gcc/fortran/error.c	(working copy)
@@ -842,6 +842,40 @@ gfc_notification_std (int std)
 }
 
 
+/* Return a string describing the nature of a standard violation
+ * and/or the relevant version of the standard.  */
+
+char const*
+notify_std_msg(int std)
+{
+
+  if (std & GFC_STD_F2018_DEL)
+return _("Fortran 2018 deleted feature:");
+  else if (std & GFC_STD_F2018_OBS)
+return _("Fortran 2018 obsolescent feature:");
+  else if (std & GFC_STD_F2018)
+return _("Fortran 2018:");
+  else if (std & GFC_STD_F2008_TS)
+return "TS 29113/TS 18508:";
+  else if (std & GFC_STD_F2008_OBS)
+return _("Fortran 2008 obsolescent feature:");
+  else if (std & GFC_STD_F2008)
+return "Fortran 2008:";
+  else if (std & GFC_STD_F2003)
+return "Fortran 2003:";
+  else if (std & GFC_STD_GNU)
+return _("GNU Extension:");
+  else if (std & GFC_STD_LEGACY)
+return _("Legacy Extension:");
+  else if (std & GFC_STD_F95_OBS)
+return _("Obsolescent feature:");
+  else if (std & GFC_STD_F95_DEL)
+return _("Deleted feature:");
+  else
+gcc_unreachable ();
+}
+
+
 /* Possibly issue a warning/error about use of a nonstandard (or deleted)
feature.  An error/warning will be issued if the currently selected
standard does not contain the requested bits.  Return false if
@@ -851,55 +885,24 @@ bool
 gfc_notify_std (int std, const char *gmsgid, ...)
 {
   va_list argp;
-  bool warning;
   const char *msg, *msg2;
   char *buffer;
 
-  warning = ((gfc_option.warn_std & std) != 0) && !inhibit_warnings;
-  if ((gfc_option.allow_std & std) != 0 && !warning)
+  /* Determine whether an error or a warning is needed.  */
+  const int wstd = std & gfc_option.warn_std;/* Standard to warn about.  */
+  const int estd = std & ~gfc_option.allow_std;  /* Standard to error about.  */
+  const bool warning = (wstd != 0) && !inhibit_warnings;
+  const bool error = (estd != 0);
+
+  if (!error && !warning)
 return true;
-
   if (suppress_errors)
-return warning ? true : false;
+return !error;
 
-  switch (std)
-  {
-case GFC_STD_F2018_DEL:
-  msg = _("Fortran 2018 deleted feature:");
-  break;
-case GFC_STD_F2018_OBS:
-  msg = _("Fortran 2018 obsolescent feature:");
-  break;
-case GFC_STD_F2018:
-  msg = _("Fortran 2018:");
-  break;
-case GFC_STD_F2008_TS:
-  msg = "TS 29113/TS 18508:";
-  break;
-case GFC_STD_F2008_OBS:
-  msg = _("Fortran 2008 obsolescent feature:");
-  break;
-case GFC_STD_F2008:
-  msg = "Fortran 2008:";
-  break;
-case GFC_STD_F2003:
-  msg = "Fortran 2003:";
-  break;
-case GFC_STD_GNU:
-  msg = _("GNU Extension:");
-  break;
-case GFC_STD_LEGACY:
-  msg = _("Legacy Extension:");
-  break;
-case GFC_STD_F95_OBS:
-  msg = _("Obsolescent feature:");
-  break;
-case GFC_STD_F95_DEL:
-  msg = _("Deleted feature:");
-  break;
-default:
-  gcc_unreachable ();
-  }
+  if (error)
+msg = notify_std_msg (estd);
+  else
+msg = notify_std_msg (wstd);
 
   msg2 = 

Re: [PATCH GCC 8] x86: Re-enable partial_reg_dependency and movx for Haswell

[Jan Hubicka]

> r254152 disabled partial_reg_dependency and movx for Haswell and newer
> Intel processors.  r258972 restored them for skylake-avx512.  For Haswell,
> movx improves performance.  But partial_reg_stall may be better than
> partial_reg_dependency in theory.  We will investigate performance impact
> of partial_reg_stall vs partial_reg_dependency on Haswell for GCC 9.  In
> the meantime, this patch restores both partial_reg_dependency and mox for
> Haswell in GCC 8.
> 
> OK for GCC 8?

I would still like to know in what situations/bechnarks it improves the 
performance.
The change was benchmarked on spec2000/2006 plus some additional benchmarks 
and, so
it would be nice to know where it hurts.

Honza
> 
> H.J.
> ---
>   PR target/85829
>   * config/i386/x86-tune.def: Re-enable partial_reg_dependency
>   and movx for Haswell.
> ---
>  gcc/config/i386/x86-tune.def | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/gcc/config/i386/x86-tune.def b/gcc/config/i386/x86-tune.def
> index 5649fdcf416..60625668236 100644
> --- a/gcc/config/i386/x86-tune.def
> +++ b/gcc/config/i386/x86-tune.def
> @@ -48,7 +48,7 @@ DEF_TUNE (X86_TUNE_SCHEDULE, "schedule",
> over partial stores.  For example preffer MOVZBL or MOVQ to load 8bit
> value over movb.  */
>  DEF_TUNE (X86_TUNE_PARTIAL_REG_DEPENDENCY, "partial_reg_dependency",
> -  m_P4_NOCONA | m_CORE2 | m_NEHALEM  | m_SANDYBRIDGE
> +  m_P4_NOCONA | m_CORE2 | m_NEHALEM  | m_SANDYBRIDGE | m_HASWELL
> | m_BONNELL | m_SILVERMONT | m_INTEL
> | m_KNL | m_KNM | m_AMD_MULTIPLE | m_SKYLAKE_AVX512 | m_GENERIC)
>  
> @@ -84,7 +84,7 @@ DEF_TUNE (X86_TUNE_PARTIAL_FLAG_REG_STALL, 
> "partial_flag_reg_stall",
> partial dependencies.  */
>  DEF_TUNE (X86_TUNE_MOVX, "movx",
>m_PPRO | m_P4_NOCONA | m_CORE2 | m_NEHALEM  | m_SANDYBRIDGE
> -   | m_BONNELL | m_SILVERMONT | m_KNL | m_KNM | m_INTEL
> +   | m_BONNELL | m_SILVERMONT | m_KNL | m_KNM | m_INTEL | m_HASWELL
> | m_GEODE | m_AMD_MULTIPLE | m_SKYLAKE_AVX512 | m_GENERIC)
>  
>  /* X86_TUNE_MEMORY_MISMATCH_STALL: Avoid partial stores that are followed by
> -- 
> 2.17.0
> 

Re: [Patch, Fortran] PR 85841: [F2018] reject deleted features

[Steve Kargl]

On Sun, May 20, 2018 at 07:28:49PM +0200, Janus Weil wrote:
> 
> > the attached patch deals with the fact that the Fortran 2018 standard
> > marks two features as "deleted" (i.e. no longer supported), namely
> > arithmetic IFs and nonblock DO constructs. Both have been obsolescent
> > since the 90s (and have been warned about by gfortran with appropriate
> > flags).
> >
> > Here's what the patch does:
> > 1) It rejects those features with -std=f2018, giving a hard error.
> > 2) It gives a warning with default flags (previously this happened
> > only with -std=f2008 etc, but not with -std=gnu).
> 
> here is a slightly updated version of the patch. While the previous
> one had to duplicate every invocation of gfc_notify_std like this:
> 
> if (!gfc_notify_std (GFC_STD_F2018_DEL, ...)) ...
> if (!gfc_notify_std (GFC_STD_F95_OBS, ...)) ...
> 
> the new version extends gfc_notify_std, such that it works not only
> with a single GFC_STD_* flag, but can handle combinations of those.
> For such a situation, where a single feature can belong to several
> GFC_STD_* classes, one potentially needs to throw different error or
> warning messages, depending on the -std= option. The invocation of
> gfc_notify_std then simplifies to:
> 
> if (!gfc_notify_std (GFC_STD_F95_OBS | GFC_STD_F2018_DEL, ...)) ...
> 
> The patch still regtests cleanly. Ok for trunk?

Patch looks good to me.  The only thing that worries me is 
whether the patch will cause the SPEC benchmark to throw
an error or warning that it did not before.  As I don't have
SPEC benchmark and it cost $$$, I'm not going to let it 
bother too much.

> Btw, with the arrival of the F2018 standard, I wonder whether it
> actually makes sense to keep the option -std=f2008ts, or to remove it
> in favor of -std=f2018, since the two Technical Specifications covered
> by this flag are now part of F2018 (and pretty much the main part!).
> Any opinions on this?

I think that f2008ts can go away.  We may need to do this
in two step as some users may have f2008ts hardcoded in
Makefiles.  Probably, issue warning for -std=2008ts and
map it to -std=2018 for a brief period (3 to 6 months?)
and then finally remove it.

-- 
steve

Re: [Patch, Fortran] PR 85841: [F2018] reject deleted features

[Janus Weil]

Hi all,

> the attached patch deals with the fact that the Fortran 2018 standard
> marks two features as "deleted" (i.e. no longer supported), namely
> arithmetic IFs and nonblock DO constructs. Both have been obsolescent
> since the 90s (and have been warned about by gfortran with appropriate
> flags).
>
> Here's what the patch does:
> 1) It rejects those features with -std=f2018, giving a hard error.
> 2) It gives a warning with default flags (previously this happened
> only with -std=f2008 etc, but not with -std=gnu).

here is a slightly updated version of the patch. While the previous
one had to duplicate every invocation of gfc_notify_std like this:

if (!gfc_notify_std (GFC_STD_F2018_DEL, ...)) ...
if (!gfc_notify_std (GFC_STD_F95_OBS, ...)) ...

the new version extends gfc_notify_std, such that it works not only
with a single GFC_STD_* flag, but can handle combinations of those.
For such a situation, where a single feature can belong to several
GFC_STD_* classes, one potentially needs to throw different error or
warning messages, depending on the -std= option. The invocation of
gfc_notify_std then simplifies to:

if (!gfc_notify_std (GFC_STD_F95_OBS | GFC_STD_F2018_DEL, ...)) ...

The patch still regtests cleanly. Ok for trunk?

Btw, with the arrival of the F2018 standard, I wonder whether it
actually makes sense to keep the option -std=f2008ts, or to remove it
in favor of -std=f2018, since the two Technical Specifications covered
by this flag are now part of F2018 (and pretty much the main part!).
Any opinions on this?

Cheers,
Janus



2018-05-20  Janus Weil  

PR fortran/85841
* error.c (notify_std_msg): New function.
(gfc_notify_std): Adjust such that it can handle combinations of
GFC_STD_* flags in the 'std' argument, not just a single one.
* match.c (match_arithmetic_if, gfc_match_if): Reject arithmetic if
in Fortran 2018.
(gfc_match_stopcode): Adjust checks for standard version.
* options.c (set_default_std_flags): Warn for F2018 deleted features
by default.
(gfc_handle_option): F2018 deleted features are allowed in earlier
standards.
* symbol.c (gfc_define_st_label, gfc_reference_st_label): Reject
nonblock do constructs in Fortran 2018.


2018-05-20  Janus Weil  

PR fortran/85841
* gfortran.dg/g77/19990826-3.f: Add option "-std=legacy".
* gfortran.dg/g77/20020307-1.f: Ditto.
* gfortran.dg/g77/980310-3.f: Ditto.
* gfortran.dg/goacc/loop-1-2.f95: Ditto.
* gfortran.dg/goacc/loop-1.f95: Ditto.
* gfortran.dg/gomp/appendix-a/a.6.1.f90: Ditto.
* gfortran.dg/gomp/appendix-a/a.6.2.f90: Ditto.
* gfortran.dg/gomp/do-1.f90: Ditto.
* gfortran.dg/gomp/omp_do1.f90: Ditto.
* gfortran.dg/pr17229.f: Ditto.
* gfortran.dg/pr37243.f: Ditto.
* gfortran.dg/pr49721-1.f: Ditto.
* gfortran.dg/pr58484.f: Ditto.
* gfortran.dg/pr81175.f: Ditto.
* gfortran.dg/pr81723.f: Ditto.
* gfortran.dg/predcom-2.f: Ditto.
* gfortran.dg/vect/Ofast-pr50414.f90: Ditto.
* gfortran.dg/vect/cost-model-pr34445a.f: Ditto.
* gfortran.dg/vect/fast-math-mgrid-resid.f: Ditto.
* gfortran.dg/vect/pr52580.f: Ditto.
Index: gcc/fortran/error.c
===
--- gcc/fortran/error.c	(revision 260420)
+++ gcc/fortran/error.c	(working copy)
@@ -842,6 +842,40 @@ gfc_notification_std (int std)
 }
 
 
+/* Return a string describing the nature of a standard violation
+ * and/or the relevant version of the standard.  */
+
+char const*
+notify_std_msg(int std)
+{
+
+  if (std & GFC_STD_F2018_DEL)
+return _("Fortran 2018 deleted feature:");
+  else if (std & GFC_STD_F2018_OBS)
+return _("Fortran 2018 obsolescent feature:");
+  else if (std & GFC_STD_F2018)
+return _("Fortran 2018:");
+  else if (std & GFC_STD_F2008_TS)
+return "TS 29113/TS 18508:";
+  else if (std & GFC_STD_F2008_OBS)
+return _("Fortran 2008 obsolescent feature:");
+  else if (std & GFC_STD_F2008)
+return "Fortran 2008:";
+  else if (std & GFC_STD_F2003)
+return "Fortran 2003:";
+  else if (std & GFC_STD_GNU)
+return _("GNU Extension:");
+  else if (std & GFC_STD_LEGACY)
+return _("Legacy Extension:");
+  else if (std & GFC_STD_F95_OBS)
+return _("Obsolescent feature:");
+  else if (std & GFC_STD_F95_DEL)
+return _("Deleted feature:");
+  else
+gcc_unreachable ();
+}
+
+
 /* Possibly issue a warning/error about use of a nonstandard (or deleted)
feature.  An error/warning will be issued if the currently selected
standard does not contain the requested bits.  Return false if
@@ -851,55 +885,24 @@ bool
 gfc_notify_std (int std, const char *gmsgid, ...)
 {
   va_list argp;
-  bool warning;
   const char *msg, *msg2;
   char *buffer;
 
-  warning = ((gfc_option.warn_std & std) != 0) && !inhibit_warnings;
-  if ((gfc_option.allow_std & std) != 0 && !warning)
+  /* Determine whether an error or a warning is needed.  */

Re: [Patch] Request for comments: short int builtins

[Richard Biener]

On May 20, 2018 7:02:40 PM GMT+02:00, Allan Sandfeld Jensen 
 wrote:
>On Sonntag, 20. Mai 2018 15:07:59 CEST Richard Biener wrote:
>> On May 20, 2018 11:01:54 AM GMT+02:00, Allan Sandfeld Jensen 
> wrote:
>> >A little over a year back we had a regression in a point release of
>gcc
>> >
>> >because the builtin __builtin_clzs got removed from i386, in part
>> >because it
>> >is was wrongly named for a target specific builtin, but we were
>using
>> >it in Qt
>> >since it existed in multiple compilers. I got the patch removing it
>> >partially
>> >reverted and the problem solved, but in the meantime I had worked on
>a
>> >patch
>> >to make it a generic builtin instead. I have rebased it and added it
>> >below,
>> >should I clean it up futher, finish the other builtins add tests and
>> >propose
>> >it, or is this not something we want?
>> 
>> Can't users simply do clz((unsigned short) s) - 16? GCC should be
>able to
>> handle this for instruction selection With The addition of some
>folding
>> patterns using the corresponding internal function.
>> 
>Of course, but we already have the builtin for i386, and a version of
>the 
>builtin for all integer types except short for all platforms. Note the
>patch 
>also generally adds short versions for all the general integer
>builtins, not 
>just clzs and they are not all that trivial to synthesize (without
>knowing the 
>trick, which gcc does).

For other builtins using them with short types is even easier... 

Richard. 

>
>
>'Allan

Re: [Patch] Request for comments: short int builtins

[Allan Sandfeld Jensen]

On Sonntag, 20. Mai 2018 15:07:59 CEST Richard Biener wrote:
> On May 20, 2018 11:01:54 AM GMT+02:00, Allan Sandfeld Jensen 
 wrote:
> >A little over a year back we had a regression in a point release of gcc
> >
> >because the builtin __builtin_clzs got removed from i386, in part
> >because it
> >is was wrongly named for a target specific builtin, but we were using
> >it in Qt
> >since it existed in multiple compilers. I got the patch removing it
> >partially
> >reverted and the problem solved, but in the meantime I had worked on a
> >patch
> >to make it a generic builtin instead. I have rebased it and added it
> >below,
> >should I clean it up futher, finish the other builtins add tests and
> >propose
> >it, or is this not something we want?
> 
> Can't users simply do clz((unsigned short) s) - 16? GCC should be able to
> handle this for instruction selection With The addition of some folding
> patterns using the corresponding internal function.
> 
Of course, but we already have the builtin for i386, and a version of the 
builtin for all integer types except short for all platforms. Note the patch 
also generally adds short versions for all the general integer builtins, not 
just clzs and they are not all that trivial to synthesize (without knowing the 
trick, which gcc does).


'Allan

[PATCH GCC 8] x86: Re-enable partial_reg_dependency and movx for Haswell

[H.J. Lu]

r254152 disabled partial_reg_dependency and movx for Haswell and newer
Intel processors.  r258972 restored them for skylake-avx512.  For Haswell,
movx improves performance.  But partial_reg_stall may be better than
partial_reg_dependency in theory.  We will investigate performance impact
of partial_reg_stall vs partial_reg_dependency on Haswell for GCC 9.  In
the meantime, this patch restores both partial_reg_dependency and mox for
Haswell in GCC 8.

OK for GCC 8?

H.J.
---
PR target/85829
* config/i386/x86-tune.def: Re-enable partial_reg_dependency
and movx for Haswell.
---
 gcc/config/i386/x86-tune.def | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/config/i386/x86-tune.def b/gcc/config/i386/x86-tune.def
index 5649fdcf416..60625668236 100644
--- a/gcc/config/i386/x86-tune.def
+++ b/gcc/config/i386/x86-tune.def
@@ -48,7 +48,7 @@ DEF_TUNE (X86_TUNE_SCHEDULE, "schedule",
over partial stores.  For example preffer MOVZBL or MOVQ to load 8bit
value over movb.  */
 DEF_TUNE (X86_TUNE_PARTIAL_REG_DEPENDENCY, "partial_reg_dependency",
-  m_P4_NOCONA | m_CORE2 | m_NEHALEM  | m_SANDYBRIDGE
+  m_P4_NOCONA | m_CORE2 | m_NEHALEM  | m_SANDYBRIDGE | m_HASWELL
  | m_BONNELL | m_SILVERMONT | m_INTEL
  | m_KNL | m_KNM | m_AMD_MULTIPLE | m_SKYLAKE_AVX512 | m_GENERIC)
 
@@ -84,7 +84,7 @@ DEF_TUNE (X86_TUNE_PARTIAL_FLAG_REG_STALL, 
"partial_flag_reg_stall",
partial dependencies.  */
 DEF_TUNE (X86_TUNE_MOVX, "movx",
   m_PPRO | m_P4_NOCONA | m_CORE2 | m_NEHALEM  | m_SANDYBRIDGE
- | m_BONNELL | m_SILVERMONT | m_KNL | m_KNM | m_INTEL
+ | m_BONNELL | m_SILVERMONT | m_KNL | m_KNM | m_INTEL | m_HASWELL
  | m_GEODE | m_AMD_MULTIPLE | m_SKYLAKE_AVX512 | m_GENERIC)
 
 /* X86_TUNE_MEMORY_MISMATCH_STALL: Avoid partial stores that are followed by
-- 
2.17.0

Re: [C++ Patch] PR 84588 ("[8 Regression] internal compiler error: Segmentation fault (contains_struct_check())")​ (Take 2)

[Paolo Carlini]

Hi,

On 19/05/2018 15:30, Jason Merrill wrote:

I would expect it to cause different diagnostic issues, from
complaining about something not being a proper declaration when it's
really an expression.  I also wonder about warning problems (either
missed or bogus) due to trying these in a different order.
Yes. It seems kind of science-fiction project ;) I'll give it more 
thought, anyway...

How about doing cp_parser_commit_to_tentative_parse if we see
something that must be a declaration?  cp_parser_simple_declaration
has

   /* If we have seen at least one decl-specifier, and the next token
  is not a parenthesis, then we must be looking at a declaration.
  (After "int (" we might be looking at a functional cast.)  */
   if (decl_specifiers.any_specifiers_p
   && cp_lexer_next_token_is_not (parser->lexer, CPP_OPEN_PAREN)
   && cp_lexer_next_token_is_not (parser->lexer, CPP_OPEN_BRACE)
   && !cp_parser_error_occurred (parser))
 cp_parser_commit_to_tentative_parse (parser);

That seems useful here, as well.  Maybe factored into a separate function.
Hmm, I see, thanks for the tip. To other day, eventually I figured out 
the below and fully tested it, which seems quite good to me, frankly: it 
simply adds a check of parenthesized_p (per your highly welcome previous 
clarification) to the existing checks: having spent quite a bit of time 
on [dcl.ambig.res] I think it's Ok - if the declarator isn't 
parenthesized can't be in fact an expression - and alone that allows us 
to make very good progress - well beyond the requirements of c++/84588 - 
on a number of diagnostic-quality fronts, see the attached additional 
testcases too. I can still construct a nasty condition of the form, say, 
'a (a(int auto)JUNK' which we don't handle well in terms of error 
recovery, but if you agree that the below is correct, it's probably 
enough for the *regression* part...


Thanks!
Paolo.

/
Index: cp/parser.c
===
--- cp/parser.c (revision 260402)
+++ cp/parser.c (working copy)
@@ -11527,6 +11527,33 @@ cp_parser_selection_statement (cp_parser* parser,
 }
 }
 
+/* Helper function for cp_parser_condition.  Enforces [stmt.stmt]/2:
+   The declarator shall not specify a function or an array.  Returns
+   TRUE if the declarator is valid, FALSE otherwise.  */
+
+static bool
+cp_parser_check_condition_declarator (cp_parser* parser,
+ cp_declarator *declarator,
+ location_t loc)
+{
+  if (function_declarator_p (declarator)
+  || declarator->kind == cdk_array)
+{
+  if (declarator->kind == cdk_array)
+   error_at (loc, "condition declares an array");
+  else
+   error_at (loc, "condition declares a function");
+  if (parser->fully_implicit_function_template_p)
+   abort_fully_implicit_template (parser);
+  cp_parser_skip_to_closing_parenthesis (parser, /*recovering=*/true,
+/*or_comma=*/false,
+/*consume_paren=*/false);
+  return false;
+}
+  else
+return true;
+}
+
 /* Parse a condition.
 
condition:
@@ -11571,11 +11598,13 @@ cp_parser_condition (cp_parser* parser)
   tree attributes;
   cp_declarator *declarator;
   tree initializer = NULL_TREE;
+  bool parenthesized_p = false;
+  location_t loc = cp_lexer_peek_token (parser->lexer)->location;
 
   /* Parse the declarator.  */
   declarator = cp_parser_declarator (parser, CP_PARSER_DECLARATOR_NAMED,
 /*ctor_dtor_or_conv_p=*/NULL,
-/*parenthesized_p=*/NULL,
+_p,
 /*member_p=*/false,
 /*friend_p=*/false);
   /* Parse the attributes.  */
@@ -11582,8 +11611,9 @@ cp_parser_condition (cp_parser* parser)
   attributes = cp_parser_attributes_opt (parser);
   /* Parse the asm-specification.  */
   asm_specification = cp_parser_asm_specification_opt (parser);
-  /* If the next token is not an `=' or '{', then we might still be
-looking at an expression.  For example:
+  /* If the next token is not an `=' or '{' and the declarator is
+parenthesized, then we might still be looking at an expression.
+For example:
 
   if (A(a).x)
 
@@ -11590,11 +11620,12 @@ cp_parser_condition (cp_parser* parser)
 looks like a decl-specifier-seq and a declarator -- but then
 there is no `=', so this is an expression.  */
   if (cp_lexer_next_token_is_not (parser->lexer, CPP_EQ)
- && cp_lexer_next_token_is_not (parser->lexer, CPP_OPEN_BRACE))
+ && cp_lexer_next_token_is_not (parser->lexer, CPP_OPEN_BRACE)
+ && parenthesized_p)
cp_parser_simulate_error (parser);
  

Re: [PATCH] Improve memset handling in value-numbering

[Richard Biener]

On May 20, 2018 2:54:46 PM GMT+02:00, "H.J. Lu"  wrote:
>On Thu, May 17, 2018 at 5:05 AM, Richard Biener 
>wrote:
>>
>> Noticed in PR63185.
>>
>> Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
>>
>> Richard.
>>
>> 2018-05-17  Richard Biener  
>>
>> * tree-ssa-sccvn.c (vn_reference_lookup_3): Improve memset
>handling.
>>
>> * gcc.dg/tree-ssa/ssa-fre-63.c: New testcase.
>>
>
>This caused:
>
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85849

It'll take me until Tuesday to look at this due to public holidays. 

Sorry for the inconvenience,
Richard. 

Re: [Patch] Request for comments: short int builtins

[Richard Biener]

On May 20, 2018 11:01:54 AM GMT+02:00, Allan Sandfeld Jensen 
 wrote:
>A little over a year back we had a regression in a point release of gcc
>
>because the builtin __builtin_clzs got removed from i386, in part
>because it 
>is was wrongly named for a target specific builtin, but we were using
>it in Qt 
>since it existed in multiple compilers. I got the patch removing it
>partially 
>reverted and the problem solved, but in the meantime I had worked on a
>patch 
>to make it a generic builtin instead. I have rebased it and added it
>below, 
>should I clean it up futher, finish the other builtins add tests and
>propose 
>it, or is this not something we want?

Can't users simply do clz((unsigned short) s) - 16? GCC should be able to 
handle this for instruction selection
With The addition of some folding patterns using the corresponding internal 
function. 

Richard. 

>diff --git a/gcc/builtin-types.def b/gcc/builtin-types.def
>index 5365befd351..74a84e653e4 100644
>--- a/gcc/builtin-types.def
>+++ b/gcc/builtin-types.def
>@@ -232,6 +232,8 @@ DEF_FUNCTION_TYPE_1 (BT_FN_INT_LONG, BT_INT,
>BT_LONG)
> DEF_FUNCTION_TYPE_1 (BT_FN_INT_ULONG, BT_INT, BT_ULONG)
> DEF_FUNCTION_TYPE_1 (BT_FN_INT_LONGLONG, BT_INT, BT_LONGLONG)
> DEF_FUNCTION_TYPE_1 (BT_FN_INT_ULONGLONG, BT_INT, BT_ULONGLONG)
>+DEF_FUNCTION_TYPE_1 (BT_FN_INT_INT16, BT_INT, BT_INT16)
>+DEF_FUNCTION_TYPE_1 (BT_FN_INT_UINT16, BT_INT, BT_UINT16)
> DEF_FUNCTION_TYPE_1 (BT_FN_INT_INTMAX, BT_INT, BT_INTMAX)
> DEF_FUNCTION_TYPE_1 (BT_FN_INT_UINTMAX, BT_INT, BT_UINTMAX)
> DEF_FUNCTION_TYPE_1 (BT_FN_INT_PTR, BT_INT, BT_PTR)
>diff --git a/gcc/builtins.c b/gcc/builtins.c
>index 9a2bf8c7d38..a8ad00e8016 100644
>--- a/gcc/builtins.c
>+++ b/gcc/builtins.c
>@@ -10689,14 +10689,17 @@ is_inexpensive_builtin (tree decl)
>   case BUILT_IN_CLZIMAX:
>   case BUILT_IN_CLZL:
>   case BUILT_IN_CLZLL:
>+  case BUILT_IN_CLZS:
>   case BUILT_IN_CTZ:
>   case BUILT_IN_CTZIMAX:
>   case BUILT_IN_CTZL:
>   case BUILT_IN_CTZLL:
>+  case BUILT_IN_CTZS:
>   case BUILT_IN_FFS:
>   case BUILT_IN_FFSIMAX:
>   case BUILT_IN_FFSL:
>   case BUILT_IN_FFSLL:
>+  case BUILT_IN_FFSS:
>   case BUILT_IN_IMAXABS:
>   case BUILT_IN_FINITE:
>   case BUILT_IN_FINITEF:
>@@ -10734,10 +10737,12 @@ is_inexpensive_builtin (tree decl)
>   case BUILT_IN_POPCOUNTL:
>   case BUILT_IN_POPCOUNTLL:
>   case BUILT_IN_POPCOUNTIMAX:
>+  case BUILT_IN_POPCOUNTS:
>   case BUILT_IN_POPCOUNT:
>   case BUILT_IN_PARITYL:
>   case BUILT_IN_PARITYLL:
>   case BUILT_IN_PARITYIMAX:
>+  case BUILT_IN_PARITYS:
>   case BUILT_IN_PARITY:
>   case BUILT_IN_LABS:
>   case BUILT_IN_LLABS:
>diff --git a/gcc/builtins.def b/gcc/builtins.def
>index 449d08d682f..618ee798767 100644
>--- a/gcc/builtins.def
>+++ b/gcc/builtins.def
>@@ -848,15 +848,18 @@ DEF_GCC_BUILTIN(BUILT_IN_CLZ, "clz", 
>BT_FN_INT_UINT, ATTR_CONST_NOTHROW_
>DEF_GCC_BUILTIN(BUILT_IN_CLZIMAX, "clzimax", BT_FN_INT_UINTMAX,
>
>ATTR_CONST_NOTHROW_LEAF_LIST)
> DEF_GCC_BUILTIN(BUILT_IN_CLZL, "clzl", BT_FN_INT_ULONG, 
>ATTR_CONST_NOTHROW_LEAF_LIST)
> DEF_GCC_BUILTIN(BUILT_IN_CLZLL, "clzll", BT_FN_INT_ULONGLONG, 
>ATTR_CONST_NOTHROW_LEAF_LIST)
>+DEF_GCC_BUILTIN(BUILT_IN_CLZS, "clzs", BT_FN_INT_UINT16, 
>ATTR_CONST_NOTHROW_LEAF_LIST)
>DEF_GCC_BUILTIN(BUILT_IN_CONSTANT_P, "constant_p",
>BT_FN_INT_VAR, 
>ATTR_CONST_NOTHROW_LEAF_LIST)
> DEF_GCC_BUILTIN(BUILT_IN_CTZ, "ctz", BT_FN_INT_UINT, 
>ATTR_CONST_NOTHROW_LEAF_LIST)
>DEF_GCC_BUILTIN(BUILT_IN_CTZIMAX, "ctzimax", BT_FN_INT_UINTMAX,
>
>ATTR_CONST_NOTHROW_LEAF_LIST)
> DEF_GCC_BUILTIN(BUILT_IN_CTZL, "ctzl", BT_FN_INT_ULONG, 
>ATTR_CONST_NOTHROW_LEAF_LIST)
> DEF_GCC_BUILTIN(BUILT_IN_CTZLL, "ctzll", BT_FN_INT_ULONGLONG, 
>ATTR_CONST_NOTHROW_LEAF_LIST)
>+DEF_GCC_BUILTIN(BUILT_IN_CTZS, "ctzs", BT_FN_INT_UINT16, 
>ATTR_CONST_NOTHROW_LEAF_LIST)
> DEF_GCC_BUILTIN(BUILT_IN_CLRSB, "clrsb", BT_FN_INT_INT, 
>ATTR_CONST_NOTHROW_LEAF_LIST)
>DEF_GCC_BUILTIN(BUILT_IN_CLRSBIMAX, "clrsbimax",
>BT_FN_INT_INTMAX, 
>ATTR_CONST_NOTHROW_LEAF_LIST)
> DEF_GCC_BUILTIN(BUILT_IN_CLRSBL, "clrsbl", BT_FN_INT_LONG, 
>ATTR_CONST_NOTHROW_LEAF_LIST)
>DEF_GCC_BUILTIN(BUILT_IN_CLRSBLL, "clrsbll",
>BT_FN_INT_LONGLONG, 
>ATTR_CONST_NOTHROW_LEAF_LIST)
>+DEF_GCC_BUILTIN(BUILT_IN_CLRSBS, "clrsbs", BT_FN_INT_INT16, 
>ATTR_CONST_NOTHROW_LEAF_LIST)
> DEF_EXT_LIB_BUILTIN(BUILT_IN_DCGETTEXT, "dcgettext", 
>BT_FN_STRING_CONST_STRING_CONST_STRING_INT, ATTR_FORMAT_ARG_2)
> DEF_EXT_LIB_BUILTIN(BUILT_IN_DGETTEXT, "dgettext", 
>BT_FN_STRING_CONST_STRING_CONST_STRING, ATTR_FORMAT_ARG_2)
> DEF_GCC_BUILTIN(BUILT_IN_DWARF_CFA, "dwarf_cfa", BT_FN_PTR, 
>ATTR_NULL)
>@@ -878,6 +881,7 @@ DEF_EXT_LIB_BUILTIN(BUILT_IN_FFS, "ffs", 
>BT_FN_INT_INT, ATTR_CONST_NOTHROW_L
>DEF_EXT_LIB_BUILTIN(BUILT_IN_FFSIMAX, 

Re: O3 bootstraps fail on x86-64

[H.J. Lu]

On Sun, May 20, 2018 at 1:54 AM, graham stott via gcc-patches
 wrote:
> It's --disable-libsanitizer that works not --disable-asan I got that wrong
>
>  Original message 
> From: graham stott via gcc-patches 
> Date: 19/05/2018  10:30  (GMT+00:00)
> To: gcc-patches 
> Subject: O3 bootstraps fail on x86-64
>
> O3 bootstraps have started to fail to build since about Thursday.
> Due to an internal compiler error when building asan.c in function 
> asan_emit_stack_protectìon tree-ssa--sccan.c:3396
> Graham

This is

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

-- 
H.J.

Re: [PATCH] Improve memset handling in value-numbering

[H.J. Lu]

On Thu, May 17, 2018 at 5:05 AM, Richard Biener  wrote:
>
> Noticed in PR63185.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
>
> Richard.
>
> 2018-05-17  Richard Biener  
>
> * tree-ssa-sccvn.c (vn_reference_lookup_3): Improve memset handling.
>
> * gcc.dg/tree-ssa/ssa-fre-63.c: New testcase.
>

This caused:

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

-- 
H.J.

[Patch, Fortran] PR 85841: [F2018] reject deleted features

[Janus Weil]

Hi all,

the attached patch deals with the fact that the Fortran 2018 standard
marks two features as "deleted" (i.e. no longer supported), namely
arithmetic IFs and nonblock DO constructs. Both have been obsolescent
since the 90s (and have been warned about by gfortran with appropriate
flags).

Here's what the patch does:
1) It rejects those features with -std=f2018, giving a hard error.
2) It gives a warning with default flags (previously this happened
only with -std=f2008 etc, but not with -std=gnu).

Note that this does not mean that gfortran completely removes support
for these features, of course. They will continue to be supported with
flags like -std=legacy or -std=f95.

The effect on the gfortran.dg testsuite is moderate, but of course
there are a number of test cases which make use of those features. The
solutions is to compile them with -std=legacy.

The patch regtests cleanly on x86_64-linux-gnu. Ok for trunk?

Cheers,
Janus



2018-05-20  Janus Weil  

PR fortran/85841
* match.c (match_arithmetic_if, gfc_match_if): Reject arithmetic if
in Fortran 2018.
(gfc_match_stopcode): Adjust checks for standard version.
* options.c (set_default_std_flags): Warn for F2018 deleted features
by default.
(gfc_handle_option): F2018 deleted features are allowed in earlier
standards.
* symbol.c (gfc_define_st_label, gfc_reference_st_label): Reject
nonblock do constructs in Fortran 2018.


2018-05-20  Janus Weil  

PR fortran/85841
* gfortran.dg/goacc/loop-1-2.f95: Add option "-std=legacy".
* gfortran.dg/goacc/loop-1.f95: Ditto.
* gfortran.dg/gomp/appendix-a/a.6.1.f90: Ditto.
* gfortran.dg/gomp/appendix-a/a.6.2.f90: Ditto.
* gfortran.dg/gomp/do-1.f90: Ditto.
* gfortran.dg/gomp/omp_do1.f90: Ditto.
* gfortran.dg/pr37243.f: Ditto.
* gfortran.dg/pr49721-1.f: Ditto.
* gfortran.dg/pr58484.f: Ditto.
* gfortran.dg/pr81175.f: Ditto.
* gfortran.dg/pr81723.f: Ditto.
* gfortran.dg/predcom-2.f: Ditto.
* gfortran.dg/vect/Ofast-pr50414.f90: Ditto.
* gfortran.dg/vect/cost-model-pr34445a.f: Ditto.
* gfortran.dg/vect/fast-math-mgrid-resid.f: Ditto.
* gfortran.dg/vect/pr52580.f: Ditto.
Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c	(revision 260402)
+++ gcc/fortran/match.c	(working copy)
@@ -1442,6 +1442,8 @@ match_arithmetic_if (void)
   return MATCH_ERROR;
 }
 
+  if (!gfc_notify_std (GFC_STD_F2018_DEL, "Arithmetic IF statement at %C"))
+return MATCH_ERROR;
   if (!gfc_notify_std (GFC_STD_F95_OBS, "Arithmetic IF statement at %C"))
 return MATCH_ERROR;
 
@@ -1522,6 +1524,8 @@ gfc_match_if (gfc_statement *if_type)
 	  return MATCH_ERROR;
 	}
 
+  if (!gfc_notify_std (GFC_STD_F2018_DEL, "Arithmetic IF statement at %C"))
+	return MATCH_ERROR;
   if (!gfc_notify_std (GFC_STD_F95_OBS, "Arithmetic IF statement at %C"))
 	return MATCH_ERROR;
 
@@ -2939,11 +2943,12 @@ gfc_match_stopcode (gfc_statement st)
 
   /* Set f95 for -std=f95.  */
   f95 = gfc_option.allow_std == (GFC_STD_F95_OBS | GFC_STD_F95 | GFC_STD_F77
- | GFC_STD_F2008_OBS);
+ | GFC_STD_F2008_OBS | GFC_STD_F2018_DEL);
 
   /* Set f03 for -std=f2003.  */
   f03 = gfc_option.allow_std == (GFC_STD_F95_OBS | GFC_STD_F95 | GFC_STD_F77
- | GFC_STD_F2008_OBS | GFC_STD_F2003);
+ | GFC_STD_F2008_OBS | GFC_STD_F2003
+ | GFC_STD_F2018_DEL);
 
   /* Look for a blank between STOP and the stop-code for F2008 or later.  */
   if (gfc_current_form != FORM_FIXED && !(f95 || f03))
Index: gcc/fortran/options.c
===
--- gcc/fortran/options.c	(revision 260402)
+++ gcc/fortran/options.c	(working copy)
@@ -44,7 +44,7 @@ set_default_std_flags (void)
 | GFC_STD_F2003 | GFC_STD_F2008 | GFC_STD_F95 | GFC_STD_F77
 | GFC_STD_F2008_OBS | GFC_STD_F2008_TS | GFC_STD_GNU | GFC_STD_LEGACY
 | GFC_STD_F2018 | GFC_STD_F2018_DEL | GFC_STD_F2018_OBS;
-  gfc_option.warn_std = GFC_STD_F95_DEL | GFC_STD_LEGACY;
+  gfc_option.warn_std = GFC_STD_F2018_DEL | GFC_STD_F95_DEL | GFC_STD_LEGACY;
 }
 
 
@@ -706,7 +706,7 @@ gfc_handle_option (size_t scode, const char *arg,
 
 case OPT_std_f95:
   gfc_option.allow_std = GFC_STD_F95_OBS | GFC_STD_F95 | GFC_STD_F77
-			 | GFC_STD_F2008_OBS;
+			 | GFC_STD_F2008_OBS | GFC_STD_F2018_DEL;
   gfc_option.warn_std = GFC_STD_F95_OBS;
   gfc_option.max_continue_fixed = 19;
   gfc_option.max_continue_free = 39;
@@ -717,7 +717,7 @@ gfc_handle_option (size_t scode, const char *arg,
 
 case OPT_std_f2003:
   gfc_option.allow_std = GFC_STD_F95_OBS | GFC_STD_F77 
-	| GFC_STD_F2003 | GFC_STD_F95 | GFC_STD_F2008_OBS;
+	| GFC_STD_F2003 | GFC_STD_F95 | GFC_STD_F2008_OBS | GFC_STD_F2018_DEL;
   gfc_option.warn_std = GFC_STD_F95_OBS;
   gfc_option.max_identifier_length = 63;
   warn_ampersand = 1;
@@ -726,7 +726,8 @@ 

Re: [PATCH] PR 85822 - Fix handling of negative constants

[Richard Biener]

On May 20, 2018 2:01:24 PM GMT+02:00, Alexander Monakov  
wrote:
>On Sun, 20 May 2018, Yuri Gribov wrote:
>
>> Hi all,
>> 
>> This fixes PR 85822 by removing incorrect reversal of condition in
>VRP
>> assertion. Bootstrapped and regtested on x86_64.
>> 
>> Ok for trunk?
>
>Please address the following issues:
>
>Use correct PR reference in Changelog.
>
>Double-check the comment before the function, I think NE_EXPR and
>EQ_EXPR
>should be swapped there.
>
>Address Richard's request from the bug report:
>
>>> Ok, please make sure to say why not doing anything special for
>negative
>>> numbers is ok.
>
>Note there are at least three special cases that are handled
>incorrectly either
>before or after the patch:
>
> - not two's complement integers

GCC doesn't support these.

> - mask being 0
> - mask being ~0
>
>Alexander

Re: [PATCH] PR 85822 - Fix handling of negative constants

[Alexander Monakov]

On Sun, 20 May 2018, Yuri Gribov wrote:

> Hi all,
> 
> This fixes PR 85822 by removing incorrect reversal of condition in VRP
> assertion. Bootstrapped and regtested on x86_64.
> 
> Ok for trunk?

Please address the following issues:

Use correct PR reference in Changelog.

Double-check the comment before the function, I think NE_EXPR and EQ_EXPR
should be swapped there.

Address Richard's request from the bug report:

>> Ok, please make sure to say why not doing anything special for negative
>> numbers is ok.

Note there are at least three special cases that are handled incorrectly either
before or after the patch:

 - not two's complement integers
 - mask being 0
 - mask being ~0

Alexander

[PATCH] PR 85822 - Fix handling of negative constants

[Yuri Gribov]

Hi all,

This fixes PR 85822 by removing incorrect reversal of condition in VRP
assertion. Bootstrapped and regtested on x86_64.

Ok for trunk?

-Y


pr85822-1.patch
Description: Binary data

[Patch] Request for comments: short int builtins

[Allan Sandfeld Jensen]

A little over a year back we had a regression in a point release of gcc 
because the builtin __builtin_clzs got removed from i386, in part because it 
is was wrongly named for a target specific builtin, but we were using it in Qt 
since it existed in multiple compilers. I got the patch removing it partially 
reverted and the problem solved, but in the meantime I had worked on a patch 
to make it a generic builtin instead. I have rebased it and added it below, 
should I clean it up futher, finish the other builtins add tests and propose 
it, or is this not something we want?

diff --git a/gcc/builtin-types.def b/gcc/builtin-types.def
index 5365befd351..74a84e653e4 100644
--- a/gcc/builtin-types.def
+++ b/gcc/builtin-types.def
@@ -232,6 +232,8 @@ DEF_FUNCTION_TYPE_1 (BT_FN_INT_LONG, BT_INT, BT_LONG)
 DEF_FUNCTION_TYPE_1 (BT_FN_INT_ULONG, BT_INT, BT_ULONG)
 DEF_FUNCTION_TYPE_1 (BT_FN_INT_LONGLONG, BT_INT, BT_LONGLONG)
 DEF_FUNCTION_TYPE_1 (BT_FN_INT_ULONGLONG, BT_INT, BT_ULONGLONG)
+DEF_FUNCTION_TYPE_1 (BT_FN_INT_INT16, BT_INT, BT_INT16)
+DEF_FUNCTION_TYPE_1 (BT_FN_INT_UINT16, BT_INT, BT_UINT16)
 DEF_FUNCTION_TYPE_1 (BT_FN_INT_INTMAX, BT_INT, BT_INTMAX)
 DEF_FUNCTION_TYPE_1 (BT_FN_INT_UINTMAX, BT_INT, BT_UINTMAX)
 DEF_FUNCTION_TYPE_1 (BT_FN_INT_PTR, BT_INT, BT_PTR)
diff --git a/gcc/builtins.c b/gcc/builtins.c
index 9a2bf8c7d38..a8ad00e8016 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -10689,14 +10689,17 @@ is_inexpensive_builtin (tree decl)
   case BUILT_IN_CLZIMAX:
   case BUILT_IN_CLZL:
   case BUILT_IN_CLZLL:
+  case BUILT_IN_CLZS:
   case BUILT_IN_CTZ:
   case BUILT_IN_CTZIMAX:
   case BUILT_IN_CTZL:
   case BUILT_IN_CTZLL:
+  case BUILT_IN_CTZS:
   case BUILT_IN_FFS:
   case BUILT_IN_FFSIMAX:
   case BUILT_IN_FFSL:
   case BUILT_IN_FFSLL:
+  case BUILT_IN_FFSS:
   case BUILT_IN_IMAXABS:
   case BUILT_IN_FINITE:
   case BUILT_IN_FINITEF:
@@ -10734,10 +10737,12 @@ is_inexpensive_builtin (tree decl)
   case BUILT_IN_POPCOUNTL:
   case BUILT_IN_POPCOUNTLL:
   case BUILT_IN_POPCOUNTIMAX:
+  case BUILT_IN_POPCOUNTS:
   case BUILT_IN_POPCOUNT:
   case BUILT_IN_PARITYL:
   case BUILT_IN_PARITYLL:
   case BUILT_IN_PARITYIMAX:
+  case BUILT_IN_PARITYS:
   case BUILT_IN_PARITY:
   case BUILT_IN_LABS:
   case BUILT_IN_LLABS:
diff --git a/gcc/builtins.def b/gcc/builtins.def
index 449d08d682f..618ee798767 100644
--- a/gcc/builtins.def
+++ b/gcc/builtins.def
@@ -848,15 +848,18 @@ DEF_GCC_BUILTIN(BUILT_IN_CLZ, "clz", 
BT_FN_INT_UINT, ATTR_CONST_NOTHROW_
 DEF_GCC_BUILTIN(BUILT_IN_CLZIMAX, "clzimax", BT_FN_INT_UINTMAX, 
ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_GCC_BUILTIN(BUILT_IN_CLZL, "clzl", BT_FN_INT_ULONG, 
ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_GCC_BUILTIN(BUILT_IN_CLZLL, "clzll", BT_FN_INT_ULONGLONG, 
ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_GCC_BUILTIN(BUILT_IN_CLZS, "clzs", BT_FN_INT_UINT16, 
ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_GCC_BUILTIN(BUILT_IN_CONSTANT_P, "constant_p", BT_FN_INT_VAR, 
ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_GCC_BUILTIN(BUILT_IN_CTZ, "ctz", BT_FN_INT_UINT, 
ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_GCC_BUILTIN(BUILT_IN_CTZIMAX, "ctzimax", BT_FN_INT_UINTMAX, 
ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_GCC_BUILTIN(BUILT_IN_CTZL, "ctzl", BT_FN_INT_ULONG, 
ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_GCC_BUILTIN(BUILT_IN_CTZLL, "ctzll", BT_FN_INT_ULONGLONG, 
ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_GCC_BUILTIN(BUILT_IN_CTZS, "ctzs", BT_FN_INT_UINT16, 
ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_GCC_BUILTIN(BUILT_IN_CLRSB, "clrsb", BT_FN_INT_INT, 
ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_GCC_BUILTIN(BUILT_IN_CLRSBIMAX, "clrsbimax", BT_FN_INT_INTMAX, 
ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_GCC_BUILTIN(BUILT_IN_CLRSBL, "clrsbl", BT_FN_INT_LONG, 
ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_GCC_BUILTIN(BUILT_IN_CLRSBLL, "clrsbll", BT_FN_INT_LONGLONG, 
ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_GCC_BUILTIN(BUILT_IN_CLRSBS, "clrsbs", BT_FN_INT_INT16, 
ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_EXT_LIB_BUILTIN(BUILT_IN_DCGETTEXT, "dcgettext", 
BT_FN_STRING_CONST_STRING_CONST_STRING_INT, ATTR_FORMAT_ARG_2)
 DEF_EXT_LIB_BUILTIN(BUILT_IN_DGETTEXT, "dgettext", 
BT_FN_STRING_CONST_STRING_CONST_STRING, ATTR_FORMAT_ARG_2)
 DEF_GCC_BUILTIN(BUILT_IN_DWARF_CFA, "dwarf_cfa", BT_FN_PTR, 
ATTR_NULL)
@@ -878,6 +881,7 @@ DEF_EXT_LIB_BUILTIN(BUILT_IN_FFS, "ffs", 
BT_FN_INT_INT, ATTR_CONST_NOTHROW_L
 DEF_EXT_LIB_BUILTIN(BUILT_IN_FFSIMAX, "ffsimax", BT_FN_INT_INTMAX, 
ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_EXT_LIB_BUILTIN(BUILT_IN_FFSL, "ffsl", BT_FN_INT_LONG, 
ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_EXT_LIB_BUILTIN(BUILT_IN_FFSLL, "ffsll", BT_FN_INT_LONGLONG, 
ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_EXT_LIB_BUILTIN(BUILT_IN_FFSS, "ffss", BT_FN_INT_INT16, 
ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_EXT_LIB_BUILTIN(BUILT_IN_FORK, "fork", BT_FN_PID, 

Re: O3 bootstraps fail on x86-64

[graham stott via gcc-patches]

It's --disable-libsanitizer that works not --disable-asan I got that wrong

 Original message 
From: graham stott via gcc-patches  
Date: 19/05/2018  10:30  (GMT+00:00) 
To: gcc-patches  
Subject: O3 bootstraps fail on x86-64 

O3 bootstraps have started to fail to build since about Thursday. 
Due to an internal compiler error when building asan.c in function 
asan_emit_stack_protectìon tree-ssa--sccan.c:3396
Graham