Re: *PING* [PATCH] PR fortran/100274 - [9/10/11/12 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.c:6131

[Jerry DeLisle]

LGTM, OK for trunk and back ports.

On 5/4/21 11:34 AM, Harald Anlauf via Fortran wrote:

PING!

---

Dear Fortranners,

Gerhard found a case where the mismatch of actual and formal argument lead
to an ICE instead of the relevant warning.  Furthermore, the special case
of character argument avoided the check that the actual argument must be
definable if the formal one is INTENT-OUT or -INOUT.  The check was already
there, it just did not get triggered here.

The patch is close to obvious, trivial and self-explaining.  I chose to
continue doing the argument checking after emitting the warning.

Regtested on x86_64-pc-linux-gnu.

OK for mainline?  OK for backports to the affected branches?

Thanks,
Harald


PR fortran/100274 - ICE in gfc_conv_procedure_call, at fortran/trans-expr.c:6131

When the check for the length of formal and actual character arguments
found a mismatch and emitted a warning, it would skip further checks
like that could lead to errors.  Fix that by continuing the checking.
Also catch a NULL pointer dereference.

gcc/fortran/ChangeLog:

PR fortran/100274
* interface.c (gfc_compare_actual_formal): Continue checks after
emitting warning for argument length mismatch.
* trans-expr.c (gfc_conv_procedure_call): Check for NULL pointer
dereference.

gcc/testsuite/ChangeLog:

PR fortran/100274
* gfortran.dg/argument_checking_25.f90: New test.

[PATCH] libstdc++: Don't constrain some enable_borrowed_range specializations

[Patrick Palka via Gcc-patches]

These constraints are already present on the template we're partially
specilalizing for.

[ This was recently fixed editorially in
https://github.com/cplusplus/draft/pull/4519 ]

Tested on x86_64-pc-linux-gnu, does this look OK for trunk?

libstdc++-v3/ChangeLog:

* include/bits/ranges_util.h (enable_borrowed_range):
Remove constraints on this partial specialization.
* include/std/ranges (enable_borrowed_range):
Likewise.
---
 libstdc++-v3/include/bits/ranges_util.h | 3 +--
 libstdc++-v3/include/std/ranges | 2 +-
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/libstdc++-v3/include/bits/ranges_util.h 
b/libstdc++-v3/include/bits/ranges_util.h
index 589886eb157..b73fc121e0f 100644
--- a/libstdc++-v3/include/bits/ranges_util.h
+++ b/libstdc++-v3/include/bits/ranges_util.h
@@ -381,8 +381,7 @@ namespace ranges
return __r.end();
 }
 
-  template _Sent,
-  subrange_kind _Kind>
+  template
 inline constexpr bool
   enable_borrowed_range> = true;
 
diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index f21e08a36e3..2305bd200a5 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -586,7 +586,7 @@ namespace ranges
== __detail::__is_signed_integer_like<_Bound>))
 iota_view(_Winc, _Bound) -> iota_view<_Winc, _Bound>;
 
-  template
+  template
 inline constexpr bool
   enable_borrowed_range> = true;
 
-- 
2.31.1.442.g7e39198978

[PATCH] libstdc++: Implement LWG 3517 and 3520 for transform_view/join_view

[Patrick Palka via Gcc-patches]

Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
10/11?

libstdc++-v3/ChangeLog:

* include/std/ranges (transform_view::_Iterator::iter_swap):
Remove as per LWG 3520.
(join_view::_Iterator::iter_swap): Add indirectly_swappable
constraint as per LWG 3517.
---
 libstdc++-v3/include/std/ranges | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index 4a7ca49b45d..f21e08a36e3 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -1581,12 +1581,6 @@ namespace views::__adaptor
  return *__i;
  }
 
- friend constexpr void
- iter_swap(const _Iterator& __x, const _Iterator& __y)
-   noexcept(noexcept(ranges::iter_swap(__x._M_current, 
__y._M_current)))
-   requires indirectly_swappable<_Base_iter>
- { return ranges::iter_swap(__x._M_current, __y._M_current); }
-
  friend _Iterator;
  template friend struct _Sentinel;
};
@@ -2520,6 +2514,7 @@ namespace views::__adaptor
  friend constexpr void
  iter_swap(const _Iterator& __x, const _Iterator& __y)
noexcept(noexcept(ranges::iter_swap(__x._M_inner, __y._M_inner)))
+   requires indirectly_swappable<_Inner_iter>
  { return ranges::iter_swap(__x._M_inner, __y._M_inner); }
 
  friend _Iterator;
-- 
2.31.1.442.g7e39198978

[PATCH] libstdc++: Reduce ranges::minmax/minmax_element comparison complexity

[Patrick Palka via Gcc-patches]

This rewrites ranges::minmax and ranges::minmax_element so that it
performs at most 3*N/2 many comparisons, as required by the standard.
In passing, this also fixes PR100387 by avoiding a premature std::move
in ranges::minmax and in std::shift_right.

Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
10/11?

libstdc++-v3/ChangeLog:

PR libstdc++/100387
* include/bits/ranges_algo.h (__minmax_fn::operator()): Rewrite
to limit comparison complexity to 3*N/2.  Avoid premature std::move.
(__minmax_element_fn::operator()): Likewise.
(shift_right): Avoid premature std::move of __result.
* testsuite/25_algorithms/minmax/constrained.cc (test04, test05):
New tests.
* testsuite/25_algorithms/minmax_element/constrained.cc (test02):
Likewise.
---
 libstdc++-v3/include/bits/ranges_algo.h   | 87 ++-
 .../25_algorithms/minmax/constrained.cc   | 31 +++
 .../minmax_element/constrained.cc | 19 
 3 files changed, 113 insertions(+), 24 deletions(-)

diff --git a/libstdc++-v3/include/bits/ranges_algo.h 
b/libstdc++-v3/include/bits/ranges_algo.h
index cda3042c11f..bbd29127e89 100644
--- a/libstdc++-v3/include/bits/ranges_algo.h
+++ b/libstdc++-v3/include/bits/ranges_algo.h
@@ -3291,18 +3291,39 @@ namespace ranges
auto __first = ranges::begin(__r);
auto __last = ranges::end(__r);
__glibcxx_assert(__first != __last);
+   auto __comp_proj = __detail::__make_comp_proj(__comp, __proj);
minmax_result> __result = {*__first, *__first};
while (++__first != __last)
  {
-   auto __tmp = *__first;
-   if (std::__invoke(__comp,
- std::__invoke(__proj, __tmp),
- std::__invoke(__proj, __result.min)))
- __result.min = std::move(__tmp);
-   if (!(bool)std::__invoke(__comp,
-std::__invoke(__proj, __tmp),
-std::__invoke(__proj, __result.max)))
- __result.max = std::move(__tmp);
+   // Process two elements at a time so that we perform at most
+   // 3*N/2 many comparisons in total (each of the N/2 iterations
+   // of this loop performs three comparisions).
+   auto __val1 = *__first;
+   if (++__first == __last)
+ {
+   // N is odd; in this final iteration, we perform a just one
+   // comparison, for a total of 3*(N-1)/2 + 1 < 3*N/2 comparisons.
+   if (__comp_proj(__val1, __result.min))
+ __result.min = std::move(__val1);
+   else if (!__comp_proj(__val1, __result.max))
+ __result.max = std::move(__val1);
+   break;
+ }
+   auto __val2 = *__first;
+   if (!__comp_proj(__val2, __val1))
+ {
+   if (__comp_proj(__val1, __result.min))
+ __result.min = std::move(__val1);
+   if (!__comp_proj(__val2, __result.max))
+ __result.max = std::move(__val2);
+ }
+   else
+ {
+   if (__comp_proj(__val2, __result.min))
+ __result.min = std::move(__val2);
+   if (!__comp_proj(__val1, __result.max))
+ __result.max = std::move(__val1);
+ }
  }
return __result;
   }
@@ -3408,21 +3429,40 @@ namespace ranges
   operator()(_Iter __first, _Sent __last,
 _Comp __comp = {}, _Proj __proj = {}) const
   {
-   if (__first == __last)
- return {__first, __first};
-
+   auto __comp_proj = __detail::__make_comp_proj(__comp, __proj);
minmax_element_result<_Iter> __result = {__first, __first};
-   auto __i = __first;
-   while (++__i != __last)
+   if (__first == __last)
+ return __result;
+   while (++__first != __last)
  {
-   if (std::__invoke(__comp,
- std::__invoke(__proj, *__i),
- std::__invoke(__proj, *__result.min)))
- __result.min = __i;
-   if (!(bool)std::__invoke(__comp,
-std::__invoke(__proj, *__i),
-std::__invoke(__proj, *__result.max)))
- __result.max = __i;
+   // Process two elements at a time so that we perform at most
+   // 3*N/2 many comparisons in total (each of the N/2 iterations
+   // of this loop performs three comparisions).
+   auto __prev = __first;
+   if (++__first == __last)
+ {
+   // N is odd; in this final iteration, we perform a just one
+   // comparison, for a total of 3*(N-1)/2 + 1 < 3*N/2 comparisons.
+   if (__comp_proj(*__prev, *__result.min))
+ __result.min = __prev;
+ 

[PATCH] -Walloca-larger-than with constant sizes at -O0 (PR 100425)

[Martin Sebor via Gcc-patches]

Even when explicitly enabled, -Walloca-larger-than doesn't run
unless optimization is enabled as well.  This prevents diagnosing
alloca calls with constant arguments in excess of the limit that
could otherwise be flagged even at -O0, making the warning less
consistent and less useful than is possible.

The attached patch enables -Walloca-larger-than for calls with
constant arguments in excess of the limit even at -O0 (variable
arguments are only handled with optimization, when VRP runs).

Martin
PR middle-end/100425 - missing -Walloca-larger-than with -O0

gcc/ChangeLog:

	PR middle-end/100425
	* gimple-ssa-warn-alloca.c (pass_walloca::firast_time_p): Rename...
	(pass_walloca::xlimit_certain_p): ...to this.
	(pass_walloca::gate): Execute for any kind of handled warning.
	(pass_walloca::execute): Avoid issuing "maybe" and "unbounded"
	warnings when xlimit_certain_p is set.

gcc/testsuite/ChangeLog:

	PR middle-end/100425
	* gcc.dg/Walloca-larger-than-4.c: New test.

diff --git a/gcc/gimple-ssa-warn-alloca.c b/gcc/gimple-ssa-warn-alloca.c
index 42c0ba1d87b..e9a24d4d1d0 100644
--- a/gcc/gimple-ssa-warn-alloca.c
+++ b/gcc/gimple-ssa-warn-alloca.c
@@ -56,31 +56,30 @@ class pass_walloca : public gimple_opt_pass
 {
 public:
   pass_walloca (gcc::context *ctxt)
-: gimple_opt_pass(pass_data_walloca, ctxt), first_time_p (false)
+: gimple_opt_pass(pass_data_walloca, ctxt), xlimit_certain_p (false)
   {}
   opt_pass *clone () { return new pass_walloca (m_ctxt); }
   void set_pass_param (unsigned int n, bool param)
 {
   gcc_assert (n == 0);
-  first_time_p = param;
+  // Set to true to enable only warnings for alloca calls that
+  // are certainly in excess of the limit.  This includes calls
+  // with constant arguments but excludes those in ranges (that
+  // can only be determined by range analysis) as well as
+  // the "may be too large" kind.
+  xlimit_certain_p = param;
 }
   virtual bool gate (function *);
   virtual unsigned int execute (function *);
 
  private:
   // Set to TRUE the first time we run this pass on a function.
-  bool first_time_p;
+  bool xlimit_certain_p;
 };
 
 bool
 pass_walloca::gate (function *fun ATTRIBUTE_UNUSED)
 {
-  // The first time this pass is called, it is called before
-  // optimizations have been run and range information is unavailable,
-  // so we can only perform strict alloca checking.
-  if (first_time_p)
-return warn_alloca != 0;
-
   // Warning is disabled when its size limit is greater than PTRDIFF_MAX
   // for the target maximum, which makes the limit negative since when
   // represented in signed HOST_WIDE_INT.
@@ -317,6 +316,9 @@ pass_walloca::execute (function *fun)
 	  break;
 	case ALLOCA_BOUND_MAYBE_LARGE:
 	  {
+		if (xlimit_certain_p)
+		  break;
+
 		auto_diagnostic_group d;
 		if (warning_at (loc, wcode,
 (is_vla
@@ -354,6 +356,9 @@ pass_walloca::execute (function *fun)
 	  }
 	  break;
 	case ALLOCA_UNBOUNDED:
+	  if (xlimit_certain_p)
+		break;
+
 	  warning_at (loc, wcode,
 			  (is_vla
 			   ? G_("%Gunbounded use of variable-length array")
diff --git a/gcc/testsuite/gcc.dg/Walloca-larger-than-4.c b/gcc/testsuite/gcc.dg/Walloca-larger-than-4.c
new file mode 100644
index 000..f2ccc93d92b
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/Walloca-larger-than-4.c
@@ -0,0 +1,18 @@
+/* PR middle-end/100425 - missing -Walloca-larger-than with -O0
+   { dg-do compile }
+   { dg-options "-O0 -Wall -Walloca-larger-than=128" } */
+
+typedef __SIZE_TYPE__ size_t;
+
+void* alloca (size_t);
+
+void sink (void*);
+
+void warn_alloca_too_large (void)
+{
+  sink (alloca (1));
+  sink (alloca (128));
+  sink (alloca (129));// { dg-warning "\\\[-Walloca-larger-than" }
+  sink (alloca (128 + 2));// { dg-warning "\\\[-Walloca-larger-than" }
+  sink (alloca (1024));   // { dg-warning "\\\[-Walloca-larger-than" }
+}

Re: ctype support for libstdc++ on VxWorks

[Alexandre Oliva]

On May  4, 2021, Jonathan Wakely  wrote:

> s/explicitely/explicitly/

Thanks.  I also adjusted the attribution in that file.  Here's what I'm
checking in.


ctype support for libstdc++ on VxWorks

From: Corentin Gay 

for  libstdc++-v3/ChangeLog

* acinclude.m4: Add VxWorks-specific case for the
configuration of ctypes.
* configure: Regenerate.
* config/locale/vxworks/ctype_members.cc: Add VxWorks-specific
version.
* config/os/vxworks/ctype_base.h: Adjust for VxWorks7+.
* config/os/vxworks/ctype_configure_char.cc: Likewise.
* config/os/vxworks/ctype_inline.h: Likewise.
* testsuite/28_regex/traits/char/isctype.cc: Defines
NEWLINE_IN_CLASS_BLANK if the target is VxWorks.
* testsuite/28_regex/traits/wchar_t/isctype.cc: Likewise.
---
 libstdc++-v3/acinclude.m4  |   18 +
 .../config/locale/vxworks/ctype_members.cc |  292 
 libstdc++-v3/config/os/vxworks/ctype_base.h|   27 ++
 .../config/os/vxworks/ctype_configure_char.cc  |   10 +
 libstdc++-v3/config/os/vxworks/ctype_inline.h  |   39 +++
 libstdc++-v3/configure |   19 +
 .../testsuite/28_regex/traits/char/isctype.cc  |1 
 .../testsuite/28_regex/traits/wchar_t/isctype.cc   |1 
 8 files changed, 406 insertions(+), 1 deletion(-)
 create mode 100644 libstdc++-v3/config/locale/vxworks/ctype_members.cc

diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index 94897a654c950..90ecc4a87a253 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -2391,6 +2391,9 @@ AC_DEFUN([GLIBCXX_ENABLE_CLOCALE], [
   darwin*)
enable_clocale_flag=darwin
;;
+  vxworks*)
+   enable_clocale_flag=vxworks
+   ;;
   dragonfly* | freebsd*)
enable_clocale_flag=dragonfly
;;
@@ -2485,7 +2488,22 @@ AC_DEFUN([GLIBCXX_ENABLE_CLOCALE], [
   CTIME_CC=config/locale/generic/time_members.cc
   CLOCALE_INTERNAL_H=config/locale/generic/c++locale_internal.h
   ;;
+vxworks)
+  AC_MSG_RESULT(vxworks)
 
+  CLOCALE_H=config/locale/generic/c_locale.h
+  CLOCALE_CC=config/locale/generic/c_locale.cc
+  CCODECVT_CC=config/locale/generic/codecvt_members.cc
+  CCOLLATE_CC=config/locale/generic/collate_members.cc
+  CCTYPE_CC=config/locale/vxworks/ctype_members.cc
+  CMESSAGES_H=config/locale/generic/messages_members.h
+  CMESSAGES_CC=config/locale/generic/messages_members.cc
+  CMONEY_CC=config/locale/generic/monetary_members.cc
+  CNUMERIC_CC=config/locale/generic/numeric_members.cc
+  CTIME_H=config/locale/generic/time_members.h
+  CTIME_CC=config/locale/generic/time_members.cc
+  CLOCALE_INTERNAL_H=config/locale/generic/c++locale_internal.h
+  ;;
 dragonfly)
   AC_MSG_RESULT(dragonfly or freebsd)
 
diff --git a/libstdc++-v3/config/locale/vxworks/ctype_members.cc 
b/libstdc++-v3/config/locale/vxworks/ctype_members.cc
new file mode 100644
index 0..f9dd64c73ff78
--- /dev/null
+++ b/libstdc++-v3/config/locale/vxworks/ctype_members.cc
@@ -0,0 +1,292 @@
+// std::ctype implementation details, vxworks specific version -*- C++ -*-
+
+// Copyright (C) 2001-2021 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.
+
+// Under Section 7 of GPL version 3, you are granted additional
+// permissions described in the GCC Runtime Library Exception, version
+// 3.1, as published by the Free Software Foundation.
+
+// You should have received a copy of the GNU General Public License and
+// a copy of the GCC Runtime Library Exception along with this program;
+// see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+// .
+
+//
+// ISO C++ 14882: 22.2.1.1.2  ctype virtual functions.
+//
+
+// Originally written by Benjamin Kosnik .
+// Ported to vxworks by Corentin Gay .
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+namespace std _GLIBCXX_VISIBILITY(default)
+{
+_GLIBCXX_BEGIN_NAMESPACE_VERSION
+
+  // NB: The other ctype specializations are in src/locale.cc and
+  // various /config/os/* files.
+  ctype_byname::ctype_byname(const char* __s, size_t __refs)
+  : ctype(0, false, __refs)
+  {
+if (std::strcmp(__s, "C") != 0 && std::strcmp(__s, "POSIX") != 0)
+  {
+   this->_S_destroy_c_locale(this->_M_c_locale_ctype);
+   

Re: RFC: Changing AC_PROG_CC to AC_PROG_CC_C99 in top level configure

[Alan Modra via Gcc-patches]

On 2021-05-04 8:42 a.m., Nick Clifton wrote:
> Hi Guys,
> 
> On 4/30/21 7:36 PM, Simon Marchi wrote:
>> I think this fix is obvious enough, I encourage you to push it,
> 
> OK - I have pushed the patch to the mainline branches of both
> the gcc and binutils-gdb repositories.

Thanks Nick!  Incidentally, I checked the AC_PROG_CC_C99 change on
both binutils and gcc mainline using gcc-4.9.

To build gcc on x86_64 I found the following patch necessary to avoid
lots of
error: uninitialized const member ‘stringop_algs::stringop_strategy::max’
error: uninitialized const member ‘stringop_algs::stringop_strategy::alg’
when compiling config/i386/i386-options.c.  These can't be cured by
configuring with --disable-stage1-checking.

diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
index 97d6f3863cb..cc3b1b6d666 100644
--- a/gcc/config/i386/i386.h
+++ b/gcc/config/i386/i386.h
@@ -73,8 +73,8 @@ struct stringop_algs
 {
   const enum stringop_alg unknown_size;
   const struct stringop_strategy {
-const int max;
-const enum stringop_alg alg;
+int max;
+enum stringop_alg alg;
 int noalign;
   } size [MAX_STRINGOP_ALGS];
 };


-- 
Alan Modra
Australia Development Lab, IBM

[committed 4/4] libstdc++: Fix null dereferences in std::promise

[Jonathan Wakely via Gcc-patches]

This fixes some ubsan errors in std::promise:

future:1153:34: runtime error: member call on null pointer of type 'struct 
element_type'
future:1153:34: runtime error: member access within null pointer of type 
'struct element_type'

The problem is that the check for a null pointer is done inside the
_State::__Setter function, which is only evaluated after evaluating the
_M_future->_M_set_result postfix-expression.

This change adds a new promise::_M_state() helper for accessing
_M_future, and moves the check for no shared state into there, instead
of inside the __setter functions. The __setter functions are made
always_inline, to avoid the situation where the linker selects the old
version of set_value (without the _S_check call) and the new version of
__setter (without the _S_check call) and so there is no check. With the
always_inline attribute the old version of set_value will either inline
the old __setter or call an extern definition of it, and the new
set_value will do the check itself, so both versions do the check.

libstdc++-v3/ChangeLog:

* include/std/future (promise::set_value): Check for existence
of shared state before dereferncing it.
(promise::set_exception, promise::set_value_at_thread_exit)
(promise::set_exception_at_thread_exit): Likewise.
(promise::set_value, promise::set_exception)
(promise::set_value_at_thread_exit)
(promise::set_exception_at_thread_exit): Likewise.
(promise::set_value, promise::set_exception)
(promise::set_value_at_thread_exit)
(promise::set_exception_at_thread_exit): Likewise.
* testsuite/30_threads/promise/members/at_thread_exit2.cc:
Remove unused variable.


Tested x86_64-linux. Committed to trunk.


commit 058d6acefe8bac4a66c8e7fb4951276db188e2d8
Author: Jonathan Wakely 
Date:   Tue May 4 16:28:57 2021

libstdc++: Fix null dereferences in std::promise

This fixes some ubsan errors in std::promise:

future:1153:34: runtime error: member call on null pointer of type 'struct element_type'
future:1153:34: runtime error: member access within null pointer of type 'struct element_type'

The problem is that the check for a null pointer is done inside the
_State::__Setter function, which is only evaluated after evaluating the
_M_future->_M_set_result postfix-expression.

This change adds a new promise::_M_state() helper for accessing
_M_future, and moves the check for no shared state into there, instead
of inside the __setter functions. The __setter functions are made
always_inline, to avoid the situation where the linker selects the old
version of set_value (without the _S_check call) and the new version of
__setter (without the _S_check call) and so there is no check. With the
always_inline attribute the old version of set_value will either inline
the old __setter or call an extern definition of it, and the new
set_value will do the check itself, so both versions do the check.

libstdc++-v3/ChangeLog:

* include/std/future (promise::set_value): Check for existence
of shared state before dereferncing it.
(promise::set_exception, promise::set_value_at_thread_exit)
(promise::set_exception_at_thread_exit): Likewise.
(promise::set_value, promise::set_exception)
(promise::set_value_at_thread_exit)
(promise::set_exception_at_thread_exit): Likewise.
(promise::set_value, promise::set_exception)
(promise::set_value_at_thread_exit)
(promise::set_exception_at_thread_exit): Likewise.
* testsuite/30_threads/promise/members/at_thread_exit2.cc:
Remove unused variable.

diff --git a/libstdc++-v3/include/std/future b/libstdc++-v3/include/std/future
index ef15fefa53c..09e54c3703b 100644
--- a/libstdc++-v3/include/std/future
+++ b/libstdc++-v3/include/std/future
@@ -532,26 +532,26 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 };
 
   template
+	__attribute__((__always_inline__))
 static _Setter<_Res, _Arg&&>
-__setter(promise<_Res>* __prom, _Arg&& __arg)
+__setter(promise<_Res>* __prom, _Arg&& __arg) noexcept
 {
-	  _S_check(__prom->_M_future);
   return _Setter<_Res, _Arg&&>{ __prom, std::__addressof(__arg) };
 }
 
   template
+	__attribute__((__always_inline__))
 static _Setter<_Res, __exception_ptr_tag>
-__setter(exception_ptr& __ex, promise<_Res>* __prom)
+__setter(exception_ptr& __ex, promise<_Res>* __prom) noexcept
 {
-	  _S_check(__prom->_M_future);
   return _Setter<_Res, __exception_ptr_tag>{ __prom, &__ex };
 }
 
   template
+	__attribute__((__always_inline__))
 	static _Setter<_Res, void>
-	__setter(promise<_Res>* __prom)
+	__setter(promise<_Res>* __prom) noexcept
 	{
-	  _S_check(__prom->_M_future);
 	  return _Setter<_Res, void>{ __prom };
 	}

[committed 3/4] libstdc++: Fix undefined behaviour in std::string

[Jonathan Wakely via Gcc-patches]

This fixes a ubsan error when constructing a string with a null pointer:

bits/basic_string.h:534:21: runtime error: applying non-zero offset 
18446744073709551615 to null pointer

The _M_construct function only cares whether the second pointer is
non-null, so create a non-null value without undefined arithmetic.

We can also pass the random_access_iterator_tag directly to the
_M_construct function, to avoid going via the tag dispatching
_M_construct_aux, because we know we have pointers not integers here.

libstdc++-v3/ChangeLog:

* include/bits/basic_string.h (basic_string(const CharT*, const A&)):
Do not do arithmetic on null pointer.

Tested x86_64-linux. Committed to trunk.



commit 789c57bc5fe023fc6dc72ade4afcb0916ff788d3
Author: Jonathan Wakely 
Date:   Tue May 4 15:49:38 2021

libstdc++: Fix undefined behaviour in std::string

This fixes a ubsan error when constructing a string with a null pointer:

bits/basic_string.h:534:21: runtime error: applying non-zero offset 18446744073709551615 to null pointer

The _M_construct function only cares whether the second pointer is
non-null, so create a non-null value without undefined arithmetic.

We can also pass the random_access_iterator_tag directly to the
_M_construct function, to avoid going via the tag dispatching
_M_construct_aux, because we know we have pointers not integers here.

libstdc++-v3/ChangeLog:

* include/bits/basic_string.h (basic_string(const CharT*, const A&)):
Do not do arithmetic on null pointer.

diff --git a/libstdc++-v3/include/bits/basic_string.h b/libstdc++-v3/include/bits/basic_string.h
index fba7c6f3354..84356adc7ae 100644
--- a/libstdc++-v3/include/bits/basic_string.h
+++ b/libstdc++-v3/include/bits/basic_string.h
@@ -531,7 +531,12 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
 #endif
   basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())
   : _M_dataplus(_M_local_data(), __a)
-  { _M_construct(__s, __s ? __s + traits_type::length(__s) : __s+npos); }
+  {
+	const _CharT* __end = __s ? __s + traits_type::length(__s)
+	  // We just need a non-null pointer here to get an exception:
+	  : reinterpret_cast(__alignof__(_CharT));
+	_M_construct(__s, __end, random_access_iterator_tag());
+  }
 
   /**
*  @brief  Construct string as multiple characters.

[committed 2/4] libstdc++: Fix null dereference in pb_ds containers

[Jonathan Wakely via Gcc-patches]

This fixes ubsan errors:

ext/pb_ds/detail/cc_hash_table_map_/cc_ht_map_.hpp:533:15: runtime error: 
member access within null pointer of type 'struct entry'

libstdc++-v3/ChangeLog:

* include/ext/pb_ds/detail/cc_hash_table_map_/cc_ht_map_.hpp
(find_key_pointer(key_const_reference, false_type))
(find_key_pointer(key_const_reference, true_type)): Do not
dereference null pointer.

Tested x86_64-linux. Committed to trunk.


commit ca871701c2822c3c4537745d4aa44a7b8f408337
Author: Jonathan Wakely 
Date:   Tue May 4 15:46:28 2021

libstdc++: Fix null dereference in pb_ds containers

This fixes ubsan errors:

ext/pb_ds/detail/cc_hash_table_map_/cc_ht_map_.hpp:533:15: runtime error: member access within null pointer of type 'struct entry'

libstdc++-v3/ChangeLog:

* include/ext/pb_ds/detail/cc_hash_table_map_/cc_ht_map_.hpp
(find_key_pointer(key_const_reference, false_type))
(find_key_pointer(key_const_reference, true_type)): Do not
dereference null pointer.

diff --git a/libstdc++-v3/include/ext/pb_ds/detail/cc_hash_table_map_/cc_ht_map_.hpp b/libstdc++-v3/include/ext/pb_ds/detail/cc_hash_table_map_/cc_ht_map_.hpp
index aa5c94b9aed..c81bf3abfef 100644
--- a/libstdc++-v3/include/ext/pb_ds/detail/cc_hash_table_map_/cc_ht_map_.hpp
+++ b/libstdc++-v3/include/ext/pb_ds/detail/cc_hash_table_map_/cc_ht_map_.hpp
@@ -524,13 +524,16 @@ namespace __gnu_pbds
 
 	resize_base::notify_find_search_end();
 
-#ifdef _GLIBCXX_DEBUG
 	if (p_e == 0)
-	  PB_DS_CHECK_KEY_DOES_NOT_EXIST(r_key)
+	  {
+	PB_DS_CHECK_KEY_DOES_NOT_EXIST(r_key)
+	return 0;
+	  }
 	else
-	  PB_DS_CHECK_KEY_EXISTS(r_key)
-#endif
-	return _e->m_value;
+	  {
+	PB_DS_CHECK_KEY_EXISTS(r_key)
+	return _e->m_value;
+	  }
   }
 
   inline pointer
@@ -550,13 +553,16 @@ namespace __gnu_pbds
 
 	resize_base::notify_find_search_end();
 
-#ifdef _GLIBCXX_DEBUG
 	if (p_e == 0)
-	  PB_DS_CHECK_KEY_DOES_NOT_EXIST(r_key)
+	  {
+	PB_DS_CHECK_KEY_DOES_NOT_EXIST(r_key)
+	return 0;
+	  }
 	else
-	  PB_DS_CHECK_KEY_EXISTS(r_key)
-#endif
-	return _e->m_value;
+	  {
+	PB_DS_CHECK_KEY_EXISTS(r_key)
+	return _e->m_value;
+	  }
   }
 
   inline bool

[committed 1/4] libstdc++ Fix undefined behaviour in testsuite

[Jonathan Wakely via Gcc-patches]

Fix some test bugs found by ubsan.

libstdc++-v3/ChangeLog:

* testsuite/20_util/from_chars/3.cc: Use unsigned type to avoid
overflow.
* testsuite/24_iterators/reverse_iterator/2.cc: Do not add
non-zero value to null pointer.
* testsuite/25_algorithms/copy_backward/move_iterators/69478.cc:
Use past-the-end iterator for result.
* testsuite/25_algorithms/move_backward/69478.cc: Likewise.
* testsuite/25_algorithms/move_backward/93872.cc: Likewise.

Tested x86_64-linux. Committed to trunk.

commit 6fb8b67089119b737ccb38f75f403b8d279e2229
Author: Jonathan Wakely 
Date:   Tue May 4 15:28:39 2021

libstdc++ Fix undefined behaviour in testsuite

Fix some test bugs found by ubsan.

libstdc++-v3/ChangeLog:

* testsuite/20_util/from_chars/3.cc: Use unsigned type to avoid
overflow.
* testsuite/24_iterators/reverse_iterator/2.cc: Do not add
non-zero value to null pointer.
* testsuite/25_algorithms/copy_backward/move_iterators/69478.cc:
Use past-the-end iterator for result.
* testsuite/25_algorithms/move_backward/69478.cc: Likewise.
* testsuite/25_algorithms/move_backward/93872.cc: Likewise.

diff --git a/libstdc++-v3/testsuite/20_util/from_chars/3.cc 
b/libstdc++-v3/testsuite/20_util/from_chars/3.cc
index c99353a7284..d3d70394ed9 100644
--- a/libstdc++-v3/testsuite/20_util/from_chars/3.cc
+++ b/libstdc++-v3/testsuite/20_util/from_chars/3.cc
@@ -29,7 +29,7 @@ long long
 read(const char* first, const char* last, int base)
 {
   long long val = 0;
-  long long place = 1;
+  unsigned long long place = 1;
   while (last > first)
   {
 val += (*--last - '0') * place;
diff --git a/libstdc++-v3/testsuite/24_iterators/reverse_iterator/2.cc 
b/libstdc++-v3/testsuite/24_iterators/reverse_iterator/2.cc
index a6d7d6b0191..633c1426b96 100644
--- a/libstdc++-v3/testsuite/24_iterators/reverse_iterator/2.cc
+++ b/libstdc++-v3/testsuite/24_iterators/reverse_iterator/2.cc
@@ -27,7 +27,7 @@ void test02()
   iterator_type it01;
   iterator_type it02;
 
-  // Sanity check non-member operators and functions can be instantiated. 
+  // Sanity check non-member operators and functions can be instantiated.
   it01 == it02;
   it01 != it02;
   it01 < it02;
@@ -35,11 +35,11 @@ void test02()
   it01 > it02;
   it01 >= it02;
   it01 - it02;
-  5 + it02;
+  0 + it02;
 }
 
-int main() 
-{ 
+int main()
+{
   test02();
   return 0;
 }
diff --git 
a/libstdc++-v3/testsuite/25_algorithms/copy_backward/move_iterators/69478.cc 
b/libstdc++-v3/testsuite/25_algorithms/copy_backward/move_iterators/69478.cc
index 88a01b84a8e..9c84cfb176c 100644
--- a/libstdc++-v3/testsuite/25_algorithms/copy_backward/move_iterators/69478.cc
+++ b/libstdc++-v3/testsuite/25_algorithms/copy_backward/move_iterators/69478.cc
@@ -35,6 +35,6 @@ test01()
   static_assert(std::is_trivial::value, "");
 
   trivial_rvalstruct a[1], b[1];
-  copy_backward(std::make_move_iterator(a), std::make_move_iterator(a+1), b);
+  copy_backward(std::make_move_iterator(a), std::make_move_iterator(a+1), b+1);
 }
 // { dg-prune-output "use of deleted" }
diff --git a/libstdc++-v3/testsuite/25_algorithms/move_backward/69478.cc 
b/libstdc++-v3/testsuite/25_algorithms/move_backward/69478.cc
index 25bfe29fc14..10e31be1e08 100644
--- a/libstdc++-v3/testsuite/25_algorithms/move_backward/69478.cc
+++ b/libstdc++-v3/testsuite/25_algorithms/move_backward/69478.cc
@@ -35,6 +35,6 @@ test01()
   static_assert(std::is_trivial::value, "");
 
   trivial_rvalstruct a[1], b[1];
-  std::move_backward(a, a + 1, b);
+  std::move_backward(a, a + 1, b + 1);
 }
 // { dg-prune-output "use of deleted" }
diff --git a/libstdc++-v3/testsuite/25_algorithms/move_backward/93872.cc 
b/libstdc++-v3/testsuite/25_algorithms/move_backward/93872.cc
index df96c94b394..a9fd2697f5b 100644
--- a/libstdc++-v3/testsuite/25_algorithms/move_backward/93872.cc
+++ b/libstdc++-v3/testsuite/25_algorithms/move_backward/93872.cc
@@ -35,5 +35,5 @@ void
 test01()
 {
   X a[2], b[2];
-  std::move_backward(std::begin(a), std::end(a), std::begin(b));
+  std::move_backward(std::begin(a), std::end(a), std::end(b));
 }

Re: ctype support for libstdc++ on VxWorks

[Jonathan Wakely via Gcc-patches]

On 04/05/21 21:53 +0200, François Dumont via Libstdc++ wrote:

On 04/05/21 4:52 am, Alexandre Oliva wrote:

This patch adds ctype and locale support to libstdc++ on vxworks7.
We've been using this for a while internally.  It was tested with
various vx7r2 targets.  Ok to install?


From: Corentin Gay 

+
+// Copyright (C) 2001-2021 Free Software Foundation, Inc.
+//


Just a detail but for a new file this Copyright specification looks wrong


It's derived from an existing file, with a few modifications relevant
to vxworks. As a derived work, I think it should retain the copyright
of the original file.

[PATCH] run early sprintf warning after SSA (PR 100325)

[Martin Sebor via Gcc-patches]

With no optimization, -Wformat-overflow and -Wformat-truncation
runs early to detect a subset of simple bugs.  But as it turns out,
the pass runs just a tad too early, before SSA.  That causes it to
miss a class of problems that can easily be detected once code is
in SSA form, and I would expect might also cause false positives.

The attached change moves the sprintf pass just after pass_build_ssa,
similar to other early flow-sensitive warnings (-Wnonnull-compare and
-Wuninitialized).

Martin
PR middle-end/100325 - missing warning with -O0 on sprintf overflow with pointer plus offset

gcc/ChangeLog:

	* passes.def (pass_warn_printf): Run after SSA.

gcc/testsuite/ChangeLog:

	* gcc.dg/tree-ssa/builtin-sprintf-warn-26.c: New test.

diff --git a/gcc/passes.def b/gcc/passes.def
index 55e8164d56b..de39fa48b3d 100644
--- a/gcc/passes.def
+++ b/gcc/passes.def
@@ -45,7 +45,6 @@ along with GCC; see the file COPYING3.  If not see
   NEXT_PASS (pass_warn_function_return);
   NEXT_PASS (pass_coroutine_early_expand_ifns);
   NEXT_PASS (pass_expand_omp);
-  NEXT_PASS (pass_warn_printf);
   NEXT_PASS (pass_walloca, /*strict_mode_p=*/true);
   NEXT_PASS (pass_build_cgraph_edges);
   TERMINATE_PASS_LIST (all_lowering_passes)
@@ -58,6 +57,7 @@ along with GCC; see the file COPYING3.  If not see
   PUSH_INSERT_PASSES_WITHIN (pass_build_ssa_passes)
   NEXT_PASS (pass_fixup_cfg);
   NEXT_PASS (pass_build_ssa);
+  NEXT_PASS (pass_warn_printf);
   NEXT_PASS (pass_warn_nonnull_compare);
   NEXT_PASS (pass_early_warn_uninitialized);
   NEXT_PASS (pass_ubsan);
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-26.c b/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-26.c
index 16a551d9c8d..677b6345c5c 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-26.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-26.c
@@ -22,17 +22,17 @@ void nowarn_4m3 ()
 void warn_2m1 ()
 {
   char *p = a + 2;
-  sprintf (p - 1, "%i", 123);   // { dg-warning "-Wformat-overflow" "pr100325" { xfail *-*-* } }
+  sprintf (p - 1, "%i", 123);   // { dg-warning "-Wformat-overflow" "pr100325" }
 }
 
 void warn_3m1 ()
 {
   char *p = a + 3;
-  sprintf (p - 1, "%i", 12);// { dg-warning "-Wformat-overflow" "pr100325" { xfail *-*-* } }
+  sprintf (p - 1, "%i", 12);// { dg-warning "-Wformat-overflow" "pr100325" }
 }
 
 void warn_4m1 ()
 {
   char *p = a + 4;
-  sprintf (p - 1, "%i", 1); // { dg-warning "-Wformat-overflow" "pr100325" { xfail *-*-* } }
+  sprintf (p - 1, "%i", 1); // { dg-warning "-Wformat-overflow" "pr100325" }
 }

Re: [PATCH v2 19/21] libcc1: use variadic templates for callbacks

[Tom Tromey]

Jeff> OK

Jeff> I think that's the whole set.  If not, let me know.

It is.  Thank you for the reviews.
I am checking it in now.

Tom

Re: [RFC v2] bpf.2: Use standard types and attributes

[Alexei Starovoitov via Gcc-patches]

On Tue, May 4, 2021 at 1:33 PM Zack Weinberg  wrote:
> the information that should
> appear in the manpages is the information that is most relevant to
> user space programmers.

The bpf programs are compiled for the kernel and run in the kernel.
Hence bpf man pages must reflect the kernel.
Also there is BTF where type names are part of the verification process.
if a user decides to rename a type it will be rejected by the kernel verifier.

testsuite: gcc.c-torture/execute/ieee/cdivchkld.c needs fmaxl

[Christophe Lyon via Gcc-patches]

The new test gcc.c-torture/execute/ieee/cdivchkld.c needs fmaxl(),
which may not be available, for instance on aarch64-elf with newlib.
As discussed in the PR, requiring c99_runtime enables to skip the test
in this case.

2021-05-04  Christophe Lyon  

PR testsuite/100355
gcc/testsuite/
* gcc.c-torture/execute/ieee/cdivchkld.x: New.

diff --git a/gcc/testsuite/gcc.c-torture/execute/ieee/cdivchkld.x
b/gcc/testsuite/gcc.c-torture/execute/ieee/cdivchkld.x
new file mode 100644
index 000..f798152
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/execute/ieee/cdivchkld.x
@@ -0,0 +1,4 @@
+if { [check_effective_target_c99_runtime] } {
+return 0
+}
+return 1
testsuite: gcc.c-torture/execute/ieee/cdivchkld.c needs fmaxl

The new test gcc.c-torture/execute/ieee/cdivchkld.c needs fmaxl(),
which may not be available, for instance on aarch64-elf with newlib.
As discussed in the PR, requiring c99_runtime enables to skip the test
in this case.

2021-05-04  Christophe Lyon  

	PR testsuite/100355
	gcc/testsuite/
	* gcc.c-torture/execute/ieee/cdivchkld.x: New.

diff --git a/gcc/testsuite/gcc.c-torture/execute/ieee/cdivchkld.x b/gcc/testsuite/gcc.c-torture/execute/ieee/cdivchkld.x
new file mode 100644
index 000..f798152
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/execute/ieee/cdivchkld.x
@@ -0,0 +1,4 @@
+if { [check_effective_target_c99_runtime] } {
+return 0
+}
+return 1

Re: [RFC v2] bpf.2: Use standard types and attributes

[Zack Weinberg]

On Tue, May 4, 2021 at 4:06 PM Daniel Borkmann  wrote:
> > I'm trying to clarify the manual pages as much as possible, by using 
> > standard conventions and similar structure all around the pages.  Not 
> > everyone understands kernel conventions.  Basically, Zack said very much 
> > what I had in mind with this patch.
>
> But then are you also converting, for example, __{le,be}{16,32,64} to plain
> uint{16,32,64}_t in the man pages and thus removing contextual information
> (or inventing new equivalent types)?
>
> What about other types exposed to user space like __sum16, __wsum, or __poll_t
> when they are part of a man page, etc?

Fields that are specifically in some endianness that isn't
(necessarily) the CPU's _should_ be documented as such in the manpage,
but I dunno if __{le,be}{16,32,64} as a type name is the ideal way to
do it.  There is no off-the-shelf notation for this as far as I know.

I do not know what __sum16, __wsum, and __poll_t are used for, but I
want to remind everyone again that the kernel's concerns are not
necessarily user space's concerns and the information that should
appear in the manpages is the information that is most relevant to
user space programmers.

zw

Re: [RFC v2] bpf.2: Use standard types and attributes

[Alejandro Colomar (man-pages) via Gcc-patches]

Hi Daniel,

On 5/4/21 10:06 PM, Daniel Borkmann wrote:


On 5/4/21 6:08 PM, Daniel Borkmann wrote:
 >
 > But what /problem/ is this really solving? Why bother to change 
this /now/
 > after so many years?! I think this is causing more confusion than 
solving

 > anything, really. Moreover, what are you doing with all the
 > __{le,be}{16,32,64}
 > types in uapi? Anyway, NAK for bpf.2 specifically, and the idea 
generally..


I'm trying to clarify the manual pages as much as possible, by using 
standard conventions and similar structure all around the pages.  Not 
everyone understands kernel conventions.  Basically, Zack said very 
much what I had in mind with this patch.


But then are you also converting, for example, __{le,be}{16,32,64} to plain
uint{16,32,64}_t in the man pages and thus removing contextual information
(or inventing new equivalent types)?

What about other types exposed to user space like __sum16, __wsum, or 
__poll_t

when they are part of a man page, etc?


Sorry, I forgot to address that part in my answer.  If there's no 
standard way of naming a type without losing information, we can use the 
kernel naming.  I have no objection to that.


These are the only pages that seem to be using those:

$ grep -Enr '\b__[a-z][a-z]+[0-9]+' man?
man2/clone.2:44:clone, __clone2, clone3 \- create a child process
man2/clone.2:1694:.BI "int __clone2(int (*" "fn" ")(void *),"
man2/clone.2:1717:.BR __clone2 ()
man7/sock_diag.7:362:__be16  idiag_sport;
man7/sock_diag.7:363:__be16  idiag_dport;
man7/sock_diag.7:364:__be32  idiag_src[4];
man7/sock_diag.7:365:__be32  idiag_dst[4];
man7/bpf-helpers.7:514:.B \fBlong bpf_skb_vlan_push(struct sk_buff 
*\fP\fIskb\fP\fB, __be16\fP \fIvlan_proto\fP\fB, u16\fP 
\fIvlan_tci\fP\fB)\fP
man7/bpf-helpers.7:878:.B \fBs64 bpf_csum_diff(__be32 *\fP\fIfrom\fP\fB, 
u32\fP \fIfrom_size\fP\fB, __be32 *\fP\fIto\fP\fB, u32\fP 
\fIto_size\fP\fB, __wsum\fP \fIseed\fP\fB)\fP
man7/bpf-helpers.7:949:.B \fBlong bpf_skb_change_proto(struct sk_buff 
*\fP\fIskb\fP\fB, __be16\fP \fIproto\fP\fB, u64\fP \fIflags\fP\fB)\fP

man7/system_data_types.7:473:.I __int128
man7/system_data_types.7:475:.I __int128
man7/system_data_types.7:1584:.I unsigned __int128
man7/system_data_types.7:1586:.I unsigned __int128
$

So sock_diag.7 and bpf-helpers.7 and only a handful of cases. Not much 
of a problem.  I'd keep those untouched.


Regards,

Alex



--
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/

Re: [RFC v2] bpf.2: Use standard types and attributes

[Daniel Borkmann]

On 5/4/21 8:54 PM, Alejandro Colomar (man-pages) wrote:

On 5/4/21 6:06 PM, Greg KH wrote:
 > There's a very old post from Linus where he describes the difference
 > between things like __u32 and uint32_t.  They are not the same, they
 > live in different namespaces, and worlds, and can not always be swapped
 > out for each other on all arches.>
 > Dig it up if you are curious, but for user/kernel apis you HAVE to use
 > the __uNN and can not use uintNN_t variants, so don't try to mix/match
 > them, it's good to just follow the kernel standard please.
I found these:

* [RFC] Splitting kernel headers and deprecating __KERNEL__ 


* coding style 


* [patch] Small input fixes for 2.5.29 


I already knew the first one, and now found the other two.  If there's any 
other thread that is relevant, I couldn't find it.

The thing is, in all of those threads, the only reasons to avoid  
types in the kernel (at least, the only explicitly mentioned ones) are (a bit 
simplified, but this is the general idea of those threads):

* Possibly breaking something in such a big automated change.
* Namespace collision with userspace (the C standard allows defining uint32_t for 
nefarious purposes as long as you don't include .  POSIX prohibits 
that, though)
* Uglier

But

* The manual pages only document the variable size and signedness by using either 
'__u32' or 'uint32_t'.  We state that the variable is an unsigned integer of exactly 
32 bits; nothing more and nothing less.  It doesn't specify that those types are 
defined in  (or whatever header a specific manual page uses).  In 
fact, in uint32_t(3) we clearly state the headers that shall provide the type.  In 
the end, the kernel will receive a 32 bit number.  I'm not exactly sure about what is 
wrong with this.  Is there any magic in the kernel/user interface beyond what the 
standard and the compiler define that I ignore?

* At that time (~2004), the C99 and POSIX.1-2001 standards were quite young, and it was 
likely to find code that defined uint32_t.  Currently, it is hard to find something that 
compiles without C99, and even if C99 allows you to define uint32_t as long as you don't 
include , it would be really stupid to do so.  And POSIX, which completely 
prohibits defining uint32_t, is also very present in Linux and other UNIX systems.  So we 
can probably guarantee that using  in the kernel wouldn't break anything.  
But yet this isn't trying to do so. This is only about the manual pages.

I haven't read it in any of those threads, but suspect that the static analyzer 
used for the kernel might use extra information from the different 
'u32'/'__u32' type names to do some extra checks.  Does it?

 > and can not always be swapped out for each other on all arches.

Really?  'uint32_t' is defined as "an unsigned integer type of a fixed width of 
exactly 32 bits".  How is that different from '[__]u32'? Aren't the kernel types 
guaranteed to be unsigned integers of exactly 32 bits?  AFAICT, they are 100% binary 
compatible; and if not, it's probably a kernel bug.

Yes there are archs that don't provide 64 bit integers (I ignore if any of the 
archs supported by Linux does though), but if an arch doesn't provide 
'uint64_t', it will neither be possible to have '__u64'.

[
    uintN_t
   Include: .  Alternatively, .

   uint8_t, uint16_t, uint32_t, uint64_t

   An unsigned integer type of a fixed width  of  ex‐
   actly  N  bits, N being the value specified in its
   type name.  According to the C language  standard,
   they  shall  be  capable  of storing values in the
   range [0, UINTN_MAX], substituting N by the appro‐
   priate number.

   According   to   POSIX,   uint8_t,  uint16_t,  and
   uint32_t are required; uint64_t is  only  required
   in implementations that provide integer types with
   width 64; and all other types of this form are op‐
   tional.

] -- uint32_t(3)


 >
 > So consider this my:
 >
 > Nacked-by: Greg Kroah-Hartman 
 >
 > as well.
Okay.

On 5/4/21 6:08 PM, Daniel Borkmann wrote:
 >
 > But what /problem/ is this really solving? Why bother to change this /now/
 > after so many years?! I think this is causing more confusion than solving
 > anything, really. Moreover, what are you doing with all the
 > __{le,be}{16,32,64}
 > types in uapi? Anyway, NAK for bpf.2 specifically, and the idea generally..

I'm trying to clarify the manual pages as much as possible, by using standard 
conventions and similar structure all around the pages.  Not everyone 
understands kernel conventions.  Basically, Zack said very much what 

Re: [RFC v2] bpf.2: Use standard types and attributes

[Alejandro Colomar (man-pages) via Gcc-patches]

Hi Florian,

On 5/4/21 9:45 PM, Florian Weimer wrote:

* Alejandro Colomar:


The thing is, in all of those threads, the only reasons to avoid
 types in the kernel (at least, the only explicitly
mentioned ones) are (a bit simplified, but this is the general idea of
those threads):

* Possibly breaking something in such a big automated change.
* Namespace collision with userspace (the C standard allows defining
   uint32_t for nefarious purposes as long as you don't include
  .   POSIX prohibits that, though)
* Uglier


__u64 can't be formatted with %llu on all architectures.  That's not
true for uint64_t, where you have to use %lu on some architectures to
avoid compiler warnings (and technically undefined behavior).  There are
preprocessor macros to get the expected format specifiers, but they are
clunky.  I don't know if the problem applies to uint32_t.  It does
happen with size_t and ptrdiff_t on 32-bit targets (both vary between
int and long).



Hmmm, that's interesting.  It looks like Linux always uses long long for 
64 bit types, while glibc uses 'long' as long as it's possible, and only 
uses 'long long' when necessary.  Assignment is still 100% valid both 
ways and binary compatibility also 100% (AFAIK), given they're the same 
length and signedness, but pointers are incompatible.  That's something 
to note, even though in this case there are no pointers involved, so no 
incompatibilities.  Maybe the kernel and glibc could use the same rules 
to improve compatibility, but that's out of the scope of this.


Thanks,

Alex


--
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/

Re: ctype support for libstdc++ on VxWorks

[François Dumont via Gcc-patches]

On 04/05/21 4:52 am, Alexandre Oliva wrote:

This patch adds ctype and locale support to libstdc++ on vxworks7.
We've been using this for a while internally.  It was tested with
various vx7r2 targets.  Ok to install?


From: Corentin Gay 

+
+// Copyright (C) 2001-2021 Free Software Foundation, Inc.
+//


Just a detail but for a new file this Copyright specification looks wrong

Re: [RFC v2] bpf.2: Use standard types and attributes

[Florian Weimer via Gcc-patches]

* Alejandro Colomar:

> The thing is, in all of those threads, the only reasons to avoid
>  types in the kernel (at least, the only explicitly
> mentioned ones) are (a bit simplified, but this is the general idea of
> those threads):
>
> * Possibly breaking something in such a big automated change.
> * Namespace collision with userspace (the C standard allows defining
>   uint32_t for nefarious purposes as long as you don't include
>  .   POSIX prohibits that, though)
> * Uglier

__u64 can't be formatted with %llu on all architectures.  That's not
true for uint64_t, where you have to use %lu on some architectures to
avoid compiler warnings (and technically undefined behavior).  There are
preprocessor macros to get the expected format specifiers, but they are
clunky.  I don't know if the problem applies to uint32_t.  It does
happen with size_t and ptrdiff_t on 32-bit targets (both vary between
int and long).

Thanks,
Florian

Re: [PATCH] Add gnu::diagnose_as attribute

[Matthias Kretz]

> On Tuesday, 4 May 2021 15:34:13 CEST David Malcolm wrote:
> > Does the patch interact correctly with the %H and %I codes that try to
> > show the differences between two template types?

While looking into this, I noticed that given

namespace std {
  struct A {};
  typedef A B;
}

const std::B would print as "'const B' {aka 'const std::A'}", i.e. without 
printing the scope of the typedef. I traced it to cp/error.c (dump_type). In 
the `if (TYPE_P (t) && typedef_variant_p (t))` branch, in the final else 
branch only cv-qualifiers and identifier are printed:

  pp_cxx_cv_qualifier_seq (pp, t);
  pp_cxx_tree_identifier (pp, TYPE_IDENTIFIER (t));

I believe the following should go in between, correct?

  pp_cxx_cv_qualifier_seq (pp, t);
  if (! (flags & TFF_UNQUALIFIED_NAME))
dump_scope (pp, CP_DECL_CONTEXT (TYPE_NAME (t)), flags);
  pp_cxx_tree_identifier (pp, TYPE_IDENTIFIER (t));

This is important for my diagnose_as patch because otherwise the output is:

  'const string' {aka 'const std::string'}

which is confusing and unnecessarily verbose. Patch below.


From: Matthias Kretz 

dump_type on 'const std::string' should not print 'const string' unless
TFF_UNQUALIFIED_NAME is requested.

gcc/cp/ChangeLog:
* error.c: Call dump_scope when printing a typedef.
---
 gcc/cp/error.c | 2 ++
 1 file changed, 2 insertions(+)


-- 
──
 Dr. Matthias Kretz   https://mattkretz.github.io
 GSI Helmholtz Centre for Heavy Ion Research   https://gsi.de
 std::experimental::simd  https://github.com/VcDevel/std-simd
──
diff --git a/gcc/cp/error.c b/gcc/cp/error.c
index 10b547afaa7..edeaad44bcd 100644
--- a/gcc/cp/error.c
+++ b/gcc/cp/error.c
@@ -511,6 +511,8 @@ dump_type (cxx_pretty_printer *pp, tree t, int flags)
   else
 	{
 	  pp_cxx_cv_qualifier_seq (pp, t);
+	  if (! (flags & TFF_UNQUALIFIED_NAME))
+	dump_scope (pp, CP_DECL_CONTEXT (TYPE_NAME (t)), flags);
 	  pp_cxx_tree_identifier (pp, TYPE_IDENTIFIER (t));
 	  return;
 	}

Re: [PATCH] Add gnu::diagnose_as attribute

[David Malcolm via Gcc-patches]

On Tue, 2021-05-04 at 16:23 +0200, Matthias Kretz wrote:
> On Tuesday, 4 May 2021 15:34:13 CEST David Malcolm wrote:
> > On Tue, 2021-05-04 at 13:13 +0200, Matthias Kretz wrote:
> > > This attribute overrides the diagnostics output string for the
> > > entity
> > > it
> > > appertains to. The motivation is to improve QoI for library TS
> > > implementations, where diagnostics have a very bad signal-to-
> > > noise
> > > ratio
> > > due to the long namespaces involved.
> > > [...]
> > 
> > Thanks for the patch, it looks very promising.
> 
> Thanks. I'm new to modifying the compiler like this, so please be
> extra 
> careful with my patch. I believe I understand most of what I did, but
> I might 
> have misunderstood. :)

That's tends to be how I feel when working on the C++ FE :)

> 
> > The patch has no testcases; it should probably add test coverage
> > for:
> > - the various places and ways in which diagnose_as can affect the
> > output,
> > - disabling it with the option
> > - the various ways in which the user can get diagnose_as wrong
> > - etc
> 
> Right. If you know of an existing similar testcase, that'd help me a
> lot to 
> get started.

FWIW I implemented the %H and %I codes in
f012c8ef4b35dcee9b5a3807868d050812d5b3b9 and that commit adds various
DejaGnu testcases that exercise C++ diagnostics with and without
various options, verifying the precise wording of errors.  So that
might be a good place to look.


> 
> > Does the patch affect the output of labels when underlining ranges of
> > source code in diagnostics?
> 
> AFAIU (and tested), it doesn't affect source code output. So, no?

Sorry, I was unclear.  I was referring to this kind of thing:

$ cat t.C
#include 

std::string test (std::string s)
{
return 
}

$ g++ t.C
t.C: In function ‘std::string test(std::string)’:
t.C:5:12: error: could not convert ‘& s’ from ‘std::string*’ {aka
‘std::__cxx11::basic_string*’} to ‘std::string’ {aka
‘std::__cxx11::basic_string’}
5 | return 
  |^~
  ||
  |std::string* {aka std::__cxx11::basic_string*}

i.e. the final line in the output above, where the underlined range of
source code in line 5 is labelled, showing the type of the expression.

Hopefully it ought to automatically just drop out of the work you've
already done.

FWIW an example of implementation this can be seen in
a14feb3c783fba6af8d66b8138214a3a313be5c5 (which added labels for type
errors in C++ binary operators).


> Does the patch interact correctly with the %H and %I codes that try to
> show the differences between two template types?

I don't know. I'll try to find out. If you have a good idea (or
pointer) for a 
testcase, let me know.

See above.


Dave

Re: [RFC v2] bpf.2: Use standard types and attributes

[Alejandro Colomar (man-pages) via Gcc-patches]

Hi Greg, Daniel,

On 5/4/21 6:06 PM, Greg KH wrote:
> There's a very old post from Linus where he describes the difference
> between things like __u32 and uint32_t.  They are not the same, they
> live in different namespaces, and worlds, and can not always be swapped
> out for each other on all arches.>
> Dig it up if you are curious, but for user/kernel apis you HAVE to use
> the __uNN and can not use uintNN_t variants, so don't try to mix/match
> them, it's good to just follow the kernel standard please.
I found these:

* [RFC] Splitting kernel headers and deprecating __KERNEL__ 



* coding style 



* [patch] Small input fixes for 2.5.29 



I already knew the first one, and now found the other two.  If there's 
any other thread that is relevant, I couldn't find it.


The thing is, in all of those threads, the only reasons to avoid 
 types in the kernel (at least, the only explicitly mentioned 
ones) are (a bit simplified, but this is the general idea of those threads):


* Possibly breaking something in such a big automated change.
* Namespace collision with userspace (the C standard allows defining 
uint32_t for nefarious purposes as long as you don't include . 
 POSIX prohibits that, though)

* Uglier

But

* The manual pages only document the variable size and signedness by 
using either '__u32' or 'uint32_t'.  We state that the variable is an 
unsigned integer of exactly 32 bits; nothing more and nothing less.  It 
doesn't specify that those types are defined in  (or 
whatever header a specific manual page uses).  In fact, in uint32_t(3) 
we clearly state the headers that shall provide the type.  In the end, 
the kernel will receive a 32 bit number.  I'm not exactly sure about 
what is wrong with this.  Is there any magic in the kernel/user 
interface beyond what the standard and the compiler define that I ignore?


* At that time (~2004), the C99 and POSIX.1-2001 standards were quite 
young, and it was likely to find code that defined uint32_t.  Currently, 
it is hard to find something that compiles without C99, and even if C99 
allows you to define uint32_t as long as you don't include , 
it would be really stupid to do so.  And POSIX, which completely 
prohibits defining uint32_t, is also very present in Linux and other 
UNIX systems.  So we can probably guarantee that using  in the 
kernel wouldn't break anything.  But yet this isn't trying to do so. 
This is only about the manual pages.


I haven't read it in any of those threads, but suspect that the static 
analyzer used for the kernel might use extra information from the 
different 'u32'/'__u32' type names to do some extra checks.  Does it?


> and can not always be swapped out for each other on all arches.

Really?  'uint32_t' is defined as "an unsigned integer type of a fixed 
width of exactly 32 bits".  How is that different from '[__]u32'? 
Aren't the kernel types guaranteed to be unsigned integers of exactly 32 
bits?  AFAICT, they are 100% binary compatible; and if not, it's 
probably a kernel bug.


Yes there are archs that don't provide 64 bit integers (I ignore if any 
of the archs supported by Linux does though), but if an arch doesn't 
provide 'uint64_t', it will neither be possible to have '__u64'.


[
   uintN_t
  Include: .  Alternatively, .

  uint8_t, uint16_t, uint32_t, uint64_t

  An unsigned integer type of a fixed width  of  ex‐
  actly  N  bits, N being the value specified in its
  type name.  According to the C language  standard,
  they  shall  be  capable  of storing values in the
  range [0, UINTN_MAX], substituting N by the appro‐
  priate number.

  According   to   POSIX,   uint8_t,  uint16_t,  and
  uint32_t are required; uint64_t is  only  required
  in implementations that provide integer types with
  width 64; and all other types of this form are op‐
  tional.

] -- uint32_t(3)


>
> So consider this my:
>
> Nacked-by: Greg Kroah-Hartman 
>
> as well.
Okay.

On 5/4/21 6:08 PM, Daniel Borkmann wrote:
>
> But what /problem/ is this really solving? Why bother to change this 
/now/

> after so many years?! I think this is causing more confusion than solving
> anything, really. Moreover, what are you doing with all the
> __{le,be}{16,32,64}
> types in uapi? Anyway, NAK for bpf.2 specifically, and the idea 
generally..

>

I'm trying to clarify the manual pages as much as possible, by using 
standard conventions and similar structure all around the pages.  Not 
everyone understands kernel conventions.  Basically, Zack said very much 
what I had in mind with this patch.



Thanks for your 

Re: [RFC v2] bpf.2: Use standard types and attributes

[Zack Weinberg]

On Tue, May 4, 2021 at 12:06 PM Greg KH  wrote:
> On Tue, May 04, 2021 at 05:53:29PM +0200, Alejandro Colomar (man-pages) wrote:
> > On 5/4/21 4:24 PM, Greg KH wrote:
> > > I agree, the two are not the same type at all, this change should not be
> > > accepted.
> >
> > I get that in the kernel you don't use the standard fixed-width types (with
> > some exceptions), probably not to mess with code that relies on 
> > not being included (I hope there's not much code that relies on this in
> > 2021, but who knows).
> >
> > But, there is zero difference between these types, from the point of view of
> > the compiler.  There's 100% compatibility between those types, and you're
> > able to mix'n'match them.  See some example below.
...
> There's a very old post from Linus where he describes the difference
> between things like __u32 and uint32_t.  They are not the same, they
> live in different namespaces, and worlds, and can not always be swapped
> out for each other on all arches.
>
> Dig it up if you are curious, but for user/kernel apis you HAVE to use
> the __uNN and can not use uintNN_t variants, so don't try to mix/match
> them, it's good to just follow the kernel standard please.
...
> Nacked-by: Greg Kroah-Hartman 

Speaking from the C library's perspective, I'm going to push back
pretty hard on this NAK, for several reasons.

First, this is a proposed change to the manpages, not the headers
themselves.  Manpage documentation of C structs is *not* expected to
match the actual declaration in the headers.  The documented field
type is usually assignment-compatible with the actual type, but not
always.  There's no guarantee whatsoever that the fields are in the
same order as the header, or that the listed set of fields is
complete.

I would say that as long as any value of type __u32 can be stored in a
variable of type uint32_t without data loss, and vice versa, there is
no reason why manpages should *have to* use __u32 in preference to
uint32_t, and that in the absence of such a reason, the standard type
should be used.

Second, it's true that __u32 and uint32_t are in different namespaces,
and it may well be necessary for uapi  headers to use the
__uNN names in order to preserve the C standard's distinction between
the program and the implementation, but that's *not* a reason for
documentation aimed at writers of user-space programs to use the
__uNN names.  In fact, it is exactly the opposite!  User space program
authors should, all else equal, be *discouraged* from using the __uNN
names, and avoiding their use in manpages is one way to do that.

Third, if there does in fact exist a situation where __uNN and
uintNN_t are *not* assignment compatible, THAT IS A BUG IN THE KERNEL.
Frankly, it would be such a catastrophic bug that I think Linus has to
have been *wrong*.  We would have noticed the problems long ago if he
were right.

I'm going to have to ask you to produce hard evidence for your claim
that __uNN and uintNN_t are not (always) assignment compatible, and
hard evidence why that can't be fixed within the kernel, or else
withdraw your objection.

zw

*PING* [PATCH] PR fortran/100274 - [9/10/11/12 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.c:6131

[Harald Anlauf via Gcc-patches]

PING!

---

Dear Fortranners,

Gerhard found a case where the mismatch of actual and formal argument lead
to an ICE instead of the relevant warning.  Furthermore, the special case
of character argument avoided the check that the actual argument must be
definable if the formal one is INTENT-OUT or -INOUT.  The check was already
there, it just did not get triggered here.

The patch is close to obvious, trivial and self-explaining.  I chose to
continue doing the argument checking after emitting the warning.

Regtested on x86_64-pc-linux-gnu.

OK for mainline?  OK for backports to the affected branches?

Thanks,
Harald


PR fortran/100274 - ICE in gfc_conv_procedure_call, at fortran/trans-expr.c:6131

When the check for the length of formal and actual character arguments
found a mismatch and emitted a warning, it would skip further checks
like that could lead to errors.  Fix that by continuing the checking.
Also catch a NULL pointer dereference.

gcc/fortran/ChangeLog:

PR fortran/100274
* interface.c (gfc_compare_actual_formal): Continue checks after
emitting warning for argument length mismatch.
* trans-expr.c (gfc_conv_procedure_call): Check for NULL pointer
dereference.

gcc/testsuite/ChangeLog:

PR fortran/100274
* gfortran.dg/argument_checking_25.f90: New test.

diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index 60736123550..9e3e8aa9da9 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -3255,10 +3255,13 @@ gfc_compare_actual_formal (gfc_actual_arglist **ap, gfc_formal_arglist *formal,
 	  && f->sym->attr.flavor != FL_PROCEDURE)
 	{
 	  if (a->expr->ts.type == BT_CHARACTER && !f->sym->as && where)
-	gfc_warning (0, "Character length of actual argument shorter "
-			 "than of dummy argument %qs (%lu/%lu) at %L",
-			 f->sym->name, actual_size, formal_size,
-			 >expr->where);
+	{
+	  gfc_warning (0, "Character length of actual argument shorter "
+			   "than of dummy argument %qs (%lu/%lu) at %L",
+			   f->sym->name, actual_size, formal_size,
+			   >expr->where);
+	  goto skip_size_check;
+	}
   else if (where)
 	{
 	  /* Emit a warning for -std=legacy and an error otherwise. */
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 213f32b0a67..a10170c7dff 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -6128,6 +6128,7 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
 		  bool add_clobber;
 		  add_clobber = fsym && fsym->attr.intent == INTENT_OUT
 			&& !fsym->attr.allocatable && !fsym->attr.pointer
+			&& e->symtree && e->symtree->n.sym
 			&& !e->symtree->n.sym->attr.dimension
 			&& !e->symtree->n.sym->attr.pointer
 			&& !e->symtree->n.sym->attr.allocatable
diff --git a/gcc/testsuite/gfortran.dg/argument_checking_25.f90 b/gcc/testsuite/gfortran.dg/argument_checking_25.f90
new file mode 100644
index 000..e699160fee1
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/argument_checking_25.f90
@@ -0,0 +1,12 @@
+! { dg-do compile }
+! PR fortran/100274 - ICE in gfc_conv_procedure_call, at fortran/trans-expr.c:6131
+
+program p
+  call s('y')   ! { dg-warning "Character length of actual argument" }
+contains
+  subroutine s(x)
+character(8), intent(out) :: x
+  end
+end
+
+! { dg-error "in variable definition context"  " " { target *-*-* } 5 }

[PATCH] AIX Encode function section and rs6000 MI Thunk

[David Edelsohn via Gcc-patches]

AIX XCOFF symbols can be labels or qualnames (names with an appended
mapping class).  CSECTs must be declared with a mapping class.
Within an assembler file, the symbol names with and without the mapping
class are unique.  An object file symbol table only presents the symbol
name without the mapping class, but the section of the symbol depends on
the mapping class.

The AIX XCOFF assembly language does not support first class aliases.
GCC implements symbol aliases by emitting additional labels for the function
or object.  When GCC encodes sections for a DECL, it must distinguish
between the primary definition and the aliases, which don't have a
mapping class encoding.

.globl foo[DS]
.globl .foo
.globl foo1
.globl .foo1
.csect foo[DS]
foo:
foo1:
.long .foo, TOC[tc0] 0
.csect .foo[PR]
.foo:
.foo1:

The CSECT foo[DS] and label foo are distinct.  foo1 is another label (alias)
for foo, and .foo1 is another label (alias) for .foo.  foo is the function
descriptor and .foo is the code.

This patch adds the [DS] mapping class to the encoding of FUNCTION_DECL
but ensures that mapping class is not added to function aliases.

rs6000_output_mi_thunk is updated to emit the function name that matches
the behavior of GCC final.c for normal functions: get_fnname_from_decl based
on the RTL name, not the DECL name.

Bootstrapped on powerpc-ibm-aix7.2.3.0 and powerpc64le-linux.

* config/rs6000/rs6000-call.c (rs6000_output_mi_thunk): Use
get_fnname_from_decl for name of thunk.
* config/rs6000/rs6000.c (rs6000_declare_alias): Use assemble_name
and ASM_OUTPUT_LABEL.
(rs6000_xcoff_declare_function_name): Use assemble_name and
ASM_OUTPUT_LABEL.
(rs6000_xcoff_declare_object_name): Use ASM_OUTPUT_LABEL.
(rs6000_xcoff_encode_section_info): Don't add mapping class
for aliases.  Always add [DS] mapping class to primary
FUNCTION_DECL.
(rs6000_asm_weaken_decl): Don't explicitly add [DS].

diff --git a/gcc/config/rs6000/rs6000-call.c b/gcc/config/rs6000/rs6000-call.c
index 6f6dc47f0ae..c4332a61862 100644
--- a/gcc/config/rs6000/rs6000-call.c
+++ b/gcc/config/rs6000/rs6000-call.c
@@ -15077,7 +15077,7 @@ rs6000_output_mi_thunk (FILE *file, tree
thunk_fndecl ATTRIBUTE_UNUSED,
HOST_WIDE_INT delta, HOST_WIDE_INT vcall_offset,
tree function)
 {
-  const char *fnname = IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (thunk_fndecl));
+  const char *fnname = get_fnname_from_decl (thunk_fndecl);
   rtx this_rtx, funexp;
   rtx_insn *insn;

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 0e9cf178245..ee15af9efa4 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -21468,7 +21468,7 @@ rs6000_declare_alias (struct symtab_node *n, void *d)
  putc ('\n', data->file);
}
  fputs ("\t.globl ", data->file);
- RS6000_OUTPUT_BASENAME (data->file, buffer);
+ assemble_name (data->file, buffer);
  putc ('\n', data->file);
}
 #ifdef ASM_WEAKEN_DECL
@@ -21491,13 +21491,12 @@ rs6000_declare_alias (struct symtab_node *n, void *d)
  putc ('\n', data->file);
}
   fputs ("\t.lglobl ", data->file);
-  RS6000_OUTPUT_BASENAME (data->file, buffer);
+  assemble_name (data->file, buffer);
   putc ('\n', data->file);
 }
   if (data->function_descriptor)
-fputs (".", data->file);
-  RS6000_OUTPUT_BASENAME (data->file, buffer);
-  fputs (":\n", data->file);
+putc ('.', data->file);
+  ASM_OUTPUT_LABEL (data->file, buffer);
   return false;
 }

 @@ -21574,21 +21573,24 @@ rs6000_xcoff_declare_function_name (FILE
*file, const char *name, tree decl)
   RS6000_OUTPUT_BASENAME (file, buffer);
   putc ('\n', file);
 }
+
   fputs ("\t.csect ", file);
-  RS6000_OUTPUT_BASENAME (file, buffer);
-  fputs (TARGET_32BIT ? "[DS]\n" : "[DS],3\n", file);
-  RS6000_OUTPUT_BASENAME (file, buffer);
-  fputs (":\n", file);
+  assemble_name (file, buffer);
+  fputs (TARGET_32BIT ? "\n" : ",3\n", file);
+
+  ASM_OUTPUT_LABEL (file, buffer);
+
   symtab_node::get (decl)->call_for_symbol_and_aliases (rs6000_declare_alias,
, true);
   fputs (TARGET_32BIT ? "\t.long ." : "\t.llong .", file);
   RS6000_OUTPUT_BASENAME (file, buffer);
   fputs (", TOC[tc0], 0\n", file);
+
   in_section = NULL;
   switch_to_section (function_section (decl));
   putc ('.', file);
-  RS6000_OUTPUT_BASENAME (file, buffer);
-  fputs (":\n", file);
+  ASM_OUTPUT_LABEL (file, buffer);
+
   data.function_descriptor = true;
   symtab_node::get (decl)->call_for_symbol_and_aliases (rs6000_declare_alias,
, true);
@@ -21683,8 

Re: [RFC] ldist: Recognize rawmemchr loop patterns

[Stefan Schulze Frielinghaus via Gcc-patches]

ping

On Thu, Apr 08, 2021 at 10:23:31AM +0200, Stefan Schulze Frielinghaus wrote:
> ping
> 
> On Tue, Mar 16, 2021 at 06:13:21PM +0100, Stefan Schulze Frielinghaus wrote:
> > [snip]
> > 
> > Please find attached a new version of the patch.  A major change compared to
> > the previous patch is that I created a separate pass which hopefully makes
> > reviewing also easier since it is almost self-contained.  After realizing 
> > that
> > detecting loops which mimic the behavior of rawmemchr/strlen functions does 
> > not
> > really fit into the topic of loop distribution, I created a separate pass.  
> > Due
> > to this I was also able to play around a bit and schedule the pass at 
> > different
> > times.  Currently it is scheduled right before loop distribution where loop
> > header copying already took place which leads to the following effect.  
> > Running
> > this setup over
> > 
> > char *t (char *p)
> > {
> >   for (; *p; ++p);
> >   return p;
> > }
> > 
> > the new pass transforms
> > 
> > char * t (char * p)
> > {
> >   char _1;
> >   char _7;
> > 
> >[local count: 118111600]:
> >   _7 = *p_3(D);
> >   if (_7 != 0)
> > goto ; [89.00%]
> >   else
> > goto ; [11.00%]
> > 
> >[local count: 105119324]:
> > 
> >[local count: 955630225]:
> >   # p_8 = PHI 
> >   p_6 = p_8 + 1;
> >   _1 = *p_6;
> >   if (_1 != 0)
> > goto ; [89.00%]
> >   else
> > goto ; [11.00%]
> > 
> >[local count: 105119324]:
> >   # p_2 = PHI 
> >   goto ; [100.00%]
> > 
> >[local count: 850510901]:
> >   goto ; [100.00%]
> > 
> >[local count: 12992276]:
> > 
> >[local count: 118111600]:
> >   # p_9 = PHI 
> >   return p_9;
> > 
> > }
> > 
> > into
> > 
> > char * t (char * p)
> > {
> >   char * _5;
> >   char _7;
> > 
> >[local count: 118111600]:
> >   _7 = *p_3(D);
> >   if (_7 != 0)
> > goto ; [89.00%]
> >   else
> > goto ; [11.00%]
> > 
> >[local count: 105119324]:
> >   _5 = p_3(D) + 1;
> >   p_10 = .RAWMEMCHR (_5, 0);
> > 
> >[local count: 118111600]:
> >   # p_9 = PHI 
> >   return p_9;
> > 
> > }
> > 
> > which is fine so far.  However, I haven't made up my mind so far whether it 
> > is
> > worthwhile to spend more time in order to also eliminate the "first 
> > unrolling"
> > of the loop.  I gave it a shot by scheduling the pass prior pass copy header
> > and ended up with:
> > 
> > char * t (char * p)
> > {
> >[local count: 118111600]:
> >   p_5 = .RAWMEMCHR (p_3(D), 0);
> >   return p_5;
> > 
> > }
> > 
> > which seems optimal to me.  The downside of this is that I have to 
> > initialize
> > scalar evolution analysis which might be undesired that early.
> > 
> > All this brings me to the question where do you see this peace of code 
> > running?
> > If in a separate pass when would you schedule it?  If in an existing pass,
> > which one would you choose?
> > 
> > Another topic which came up is whether there exists a more elegant solution 
> > to
> > my current implementation in order to deal with stores (I'm speaking of the 
> > `if
> > (store_dr)` statement inside of function transform_loop_1).  For example,
> > 
> > extern char *p;
> > char *t ()
> > {
> >   for (; *p; ++p);
> >   return p;
> > }
> > 
> > ends up as
> > 
> > char * t ()
> > {
> >   char * _1;
> >   char * _2;
> >   char _3;
> >   char * p.1_8;
> >   char _9;
> >   char * p.1_10;
> >   char * p.1_11;
> > 
> >[local count: 118111600]:
> >   p.1_8 = p;
> >   _9 = *p.1_8;
> >   if (_9 != 0)
> > goto ; [89.00%]
> >   else
> > goto ; [11.00%]
> > 
> >[local count: 105119324]:
> > 
> >[local count: 955630225]:
> >   # p.1_10 = PHI <_1(6), p.1_8(5)>
> >   _1 = p.1_10 + 1;
> >   p = _1;
> >   _3 = *_1;
> >   if (_3 != 0)
> > goto ; [89.00%]
> >   else
> > goto ; [11.00%]
> > 
> >[local count: 105119324]:
> >   # _2 = PHI <_1(3)>
> >   goto ; [100.00%]
> > 
> >[local count: 850510901]:
> >   goto ; [100.00%]
> > 
> >[local count: 12992276]:
> > 
> >[local count: 118111600]:
> >   # p.1_11 = PHI <_2(8), p.1_8(7)>
> >   return p.1_11;
> > 
> > }
> > 
> > where inside the loop a load and store occurs.  For a rawmemchr like loop I
> > have to show that we never load from a memory location to which we write.
> > Currently I solve this by hard coding those facts which are not generic at 
> > all.
> > I gave compute_data_dependences_for_loop a try which failed to determine the
> > fact that stores only happen to p[0] and loads from p[i] where i>0.  Maybe
> > there are more generic solutions to express this in contrast to my current 
> > one?
> > 
> > Thanks again for your input so far.  Really appreciated.
> > 
> > Cheers,
> > Stefan
> 
> > diff --git a/gcc/Makefile.in b/gcc/Makefile.in
> > index 8a5fb3fd99c..7b2d7405277 100644
> > --- a/gcc/Makefile.in
> > +++ b/gcc/Makefile.in
> > @@ -1608,6 +1608,7 @@ OBJS = \
> > tree-into-ssa.o \
> > tree-iterator.o \
> > tree-loop-distribution.o \
> > +   tree-loop-pattern.o \
> > tree-nested.o \
> >

Re: [PATCH 7/9] arm: Auto-vectorization for MVE: add __fp16 support to VCMP

[Christophe Lyon via Gcc-patches]

On Tue, 4 May 2021 at 15:43, Christophe Lyon  wrote:
>
> On Tue, 4 May 2021 at 13:48, Andre Vieira (lists)
>  wrote:
> >
> > It would be good to also add tests for NEON as you also enable auto-vec
> > for it. I checked and I do think the necessary 'neon_vc' patterns exist
> > for 'VH', so we should be OK there.
> >
>
> Actually since I posted the patch series, I've noticed a regression in
> armv8_2-fp16-arith-1.c, because we now vectorize all the float16x[48]_t loops,
> but we lose the fact that some FP comparisons can throw exceptions.
>
> I'll have to revisit this patch.

Actually it looks like my patch does the right thing: we now vectorize
appropriately, given that the testcase is compiled with -ffast-math.
I need to update the testcase, though.

>
> Thanks,
>
> Christophe
>
> > On 30/04/2021 15:09, Christophe Lyon via Gcc-patches wrote:
> > > This patch adds __fp16 support to the previous patch that added vcmp
> > > support with MVE. For this we update existing expanders to use VDQWH
> > > iterator, and add a new expander vcond.  In the
> > > process we need to create suitable iterators, and update v_cmp_result
> > > as needed.
> > >
> > > 2021-04-26  Christophe Lyon  
> > >
> > >   gcc/
> > >   * config/arm/iterators.md (V16): New iterator.
> > >   (VH_cvtto): New iterator.
> > >   (v_cmp_result): Added V4HF and V8HF support.
> > >   * config/arm/vec-common.md (vec_cmp): Use VDQWH.
> > >   (vcond): Likewise.
> > >   (vcond_mask_): Likewise.
> > >   (vcond): New expander.
> > >
> > >   gcc/testsuite/
> > >   * gcc.target/arm/simd/mve-compare-3.c: New test with GCC vectors.
> > >   * gcc.target/arm/simd/mve-vcmp-f16.c: New test for
> > >   auto-vectorization.
> > > ---
> > >   gcc/config/arm/iterators.md   |  6 
> > >   gcc/config/arm/vec-common.md  | 40 
> > > ---
> > >   gcc/testsuite/gcc.target/arm/simd/mve-compare-3.c | 38 
> > > +
> > >   gcc/testsuite/gcc.target/arm/simd/mve-vcmp-f16.c  | 30 +
> > >   4 files changed, 102 insertions(+), 12 deletions(-)
> > >   create mode 100644 gcc/testsuite/gcc.target/arm/simd/mve-compare-3.c
> > >   create mode 100644 gcc/testsuite/gcc.target/arm/simd/mve-vcmp-f16.c
> > >
> > > diff --git a/gcc/config/arm/iterators.md b/gcc/config/arm/iterators.md
> > > index a128465..3042baf 100644
> > > --- a/gcc/config/arm/iterators.md
> > > +++ b/gcc/config/arm/iterators.md
> > > @@ -231,6 +231,9 @@ (define_mode_iterator VU [V16QI V8HI V4SI])
> > >   ;; Vector modes for 16-bit floating-point support.
> > >   (define_mode_iterator VH [V8HF V4HF])
> > >
> > > +;; Modes with 16-bit elements only.
> > > +(define_mode_iterator V16 [V4HI V4HF V8HI V8HF])
> > > +
> > >   ;; 16-bit floating-point vector modes suitable for moving (includes 
> > > BFmode).
> > >   (define_mode_iterator VHFBF [V8HF V4HF V4BF V8BF])
> > >
> > > @@ -571,6 +574,8 @@ (define_mode_attr V_cvtto [(V2SI "v2sf") (V2SF "v2si")
> > >   ;; (Opposite) mode to convert to/from for vector-half mode conversions.
> > >   (define_mode_attr VH_CVTTO [(V4HI "V4HF") (V4HF "V4HI")
> > >   (V8HI "V8HF") (V8HF "V8HI")])
> > > +(define_mode_attr VH_cvtto [(V4HI "v4hf") (V4HF "v4hi")
> > > + (V8HI "v8hf") (V8HF "v8hi")])
> > >
> > >   ;; Define element mode for each vector mode.
> > >   (define_mode_attr V_elem [(V8QI "QI") (V16QI "QI")
> > > @@ -720,6 +725,7 @@ (define_mode_attr V_cmp_result [(V8QI "V8QI") (V16QI 
> > > "V16QI")
> > >   (define_mode_attr v_cmp_result [(V8QI "v8qi") (V16QI "v16qi")
> > >   (V4HI "v4hi") (V8HI  "v8hi")
> > >   (V2SI "v2si") (V4SI  "v4si")
> > > + (V4HF "v4hi") (V8HF  "v8hi")
> > >   (DI   "di")   (V2DI  "v2di")
> > >   (V2SF "v2si") (V4SF  "v4si")])
> > >
> > > diff --git a/gcc/config/arm/vec-common.md b/gcc/config/arm/vec-common.md
> > > index 034b48b..3fd341c 100644
> > > --- a/gcc/config/arm/vec-common.md
> > > +++ b/gcc/config/arm/vec-common.md
> > > @@ -366,8 +366,8 @@ (define_expand "vlshr3"
> > >   (define_expand "vec_cmp"
> > > [(set (match_operand: 0 "s_register_operand")
> > >   (match_operator: 1 "comparison_operator"
> > > -   [(match_operand:VDQW 2 "s_register_operand")
> > > -(match_operand:VDQW 3 "reg_or_zero_operand")]))]
> > > +   [(match_operand:VDQWH 2 "s_register_operand")
> > > +(match_operand:VDQWH 3 "reg_or_zero_operand")]))]
> > > "ARM_HAVE__ARITH
> > >  && !TARGET_REALLY_IWMMXT
> > >  && (! || flag_unsafe_math_optimizations)"
> > > @@ -399,13 +399,13 @@ (define_expand "vec_cmpu"
> > >   ;; element-wise.
> > >
> > >   (define_expand "vcond"
> > > -  [(set (match_operand:VDQW 0 "s_register_operand")
> > > - (if_then_else:VDQW
> > > +  [(set (match_operand:VDQWH 0 "s_register_operand")
> > > +   

Re: [PATCH 13/20] aarch64: Use RTL builtins for FP ml[as][q]_laneq intrinsics

[Richard Sandiford via Gcc-patches]

Jonathan Wright via Gcc-patches  writes:
> Hi Richard,
>
> I think you may be referencing an older checkout as we refactored this
> pattern in a previous change to:
>
> (define_insn "mul_lane3"
>  [(set (match_operand:VMUL 0 "register_operand" "=w")
>(mult:VMUL
>(vec_duplicate:VMUL
>  (vec_select:
>(match_operand:VMUL 2 "register_operand" "")
>(parallel [(match_operand:SI 3 "immediate_operand" "i")])))
>(match_operand:VMUL 1 "register_operand" "w")))]
>   "TARGET_SIMD"
>   {
> operands[3] = aarch64_endian_lane_rtx (mode, INTVAL (operands[3]));
> return "mul\\t%0., %1., %2.[%3]";
>   }
>   [(set_attr "type" "neon_mul__scalar")]
> )
>
> which doesn't help us with the 'laneq' intrinsics as the machine mode for
> operands 0 and 1 (of the laneq intrinsics) is narrower than the machine
> mode for operand 2.

Gah, I copied the wrong one, sorry.  The one I meant was:

(define_insn "*aarch64_mul3_elt_"
  [(set (match_operand:VMUL_CHANGE_NLANES 0 "register_operand" "=w")
 (mult:VMUL_CHANGE_NLANES
   (vec_duplicate:VMUL_CHANGE_NLANES
  (vec_select:
(match_operand: 1 "register_operand" "")
(parallel [(match_operand:SI 2 "immediate_operand")])))
  (match_operand:VMUL_CHANGE_NLANES 3 "register_operand" "w")))]
  "TARGET_SIMD"
  {
operands[2] = aarch64_endian_lane_rtx (mode, INTVAL 
(operands[2]));
return "mul\\t%0., %3., %1.[%2]";
  }
  [(set_attr "type" "neon_mul__scalar")]
)

This already provides patterns in which the indexed operand is
wider than the other operands.

Thanks,
Richard

Re: [wwwdocs] Remove CC0 from backends.html

[Eric Botcazou]

> Pushed.  What is next?  :-)

You can finally remove powerpcspe. :-)

-- 
Eric Botcazou

Re: [PATCH] Remove CC0

[Richard Earnshaw via Gcc-patches]

On 04/05/2021 17:22, Eric Botcazou wrote:

A quick look through the code suggests it's being used for thumb1 code
gen to try to reproduce the traditional CC0 type behaviour of
eliminating redundant compare operations when you have sequences such as

cmp a, b
b d1
cmp a, b
b d2

The second compare operation can be eliminated.

It might be possible to eliminate this another way by reworking the
thumb1 codegen to expose the condition codes after register allocation
has completed (much like x86 does these days), but that would be quite a
lot of work right now.  I don't know if such splitting would directly
lead to the ability to remove the redundant compares - it might need a
new pass to spot them.


Do you mean in addition to the existing pass_compare_elim_after_reload?



No, sounds like that would do the job.  :)

R.

Re: [PATCH] Remove CC0

[Eric Botcazou]

> A quick look through the code suggests it's being used for thumb1 code
> gen to try to reproduce the traditional CC0 type behaviour of
> eliminating redundant compare operations when you have sequences such as
> 
> cmp a, b
> b d1
> cmp a, b
> b d2
> 
> The second compare operation can be eliminated.
> 
> It might be possible to eliminate this another way by reworking the
> thumb1 codegen to expose the condition codes after register allocation
> has completed (much like x86 does these days), but that would be quite a
> lot of work right now.  I don't know if such splitting would directly
> lead to the ability to remove the redundant compares - it might need a
> new pass to spot them.

Do you mean in addition to the existing pass_compare_elim_after_reload?

-- 
Eric Botcazou

Re: [RFC v2] bpf.2: Use standard types and attributes

[Daniel Borkmann]

On 5/4/21 5:53 PM, Alejandro Colomar (man-pages) wrote:

Hi Greg and Alexei,


On Tue, May 04, 2021 at 07:12:01AM -0700, Alexei Starovoitov wrote:

For the same reasons as explained earlier:
Nacked-by: Alexei Starovoitov 


Okay, I'll add that.

On 5/4/21 4:24 PM, Greg KH wrote:> I agree, the two are not the same type at 
all, this change should not be

accepted.


I get that in the kernel you don't use the standard fixed-width types (with some 
exceptions), probably not to mess with code that relies on  not being 
included (I hope there's not much code that relies on this in 2021, but who knows).

But, there is zero difference between these types, from the point of view of 
the compiler.  There's 100% compatibility between those types, and you're able 
to mix'n'match them.  See some example below.

Could you please explain why the documentation, which supposedly only documents 
the API and not the internal implementation, should not use standard naming 
conventions?  The standard is much easier to read for userspace programmers, 
which might ignore why the kernel does some things in some specific ways.

BTW, just to clarify, bpf.2 is just a small sample to get reviews; the original 
intention was to replace __uNN by uintNN_t in all of the manual pages.


But what /problem/ is this really solving? Why bother to change this /now/
after so many years?! I think this is causing more confusion than solving
anything, really. Moreover, what are you doing with all the __{le,be}{16,32,64}
types in uapi? Anyway, NAK for bpf.2 specifically, and the idea generally..

Best,
Daniel

Re: [RFC v2] bpf.2: Use standard types and attributes

[Greg KH via Gcc-patches]

On Tue, May 04, 2021 at 05:53:29PM +0200, Alejandro Colomar (man-pages) wrote:
> Hi Greg and Alexei,
> 
> > On Tue, May 04, 2021 at 07:12:01AM -0700, Alexei Starovoitov wrote:
> > > For the same reasons as explained earlier:
> > > Nacked-by: Alexei Starovoitov 
> 
> Okay, I'll add that.
> 
> 
> On 5/4/21 4:24 PM, Greg KH wrote:> I agree, the two are not the same type at
> all, this change should not be
> > accepted.
> 
> I get that in the kernel you don't use the standard fixed-width types (with
> some exceptions), probably not to mess with code that relies on 
> not being included (I hope there's not much code that relies on this in
> 2021, but who knows).
> 
> But, there is zero difference between these types, from the point of view of
> the compiler.  There's 100% compatibility between those types, and you're
> able to mix'n'match them.  See some example below.
> 
> Could you please explain why the documentation, which supposedly only
> documents the API and not the internal implementation, should not use
> standard naming conventions?  The standard is much easier to read for
> userspace programmers, which might ignore why the kernel does some things in
> some specific ways.
> 
> BTW, just to clarify, bpf.2 is just a small sample to get reviews; the
> original intention was to replace __uNN by uintNN_t in all of the manual
> pages.

There's a very old post from Linus where he describes the difference
between things like __u32 and uint32_t.  They are not the same, they
live in different namespaces, and worlds, and can not always be swapped
out for each other on all arches.

Dig it up if you are curious, but for user/kernel apis you HAVE to use
the __uNN and can not use uintNN_t variants, so don't try to mix/match
them, it's good to just follow the kernel standard please.

So consider this my:

Nacked-by: Greg Kroah-Hartman 

as well.

thanks,

greg k-h

Re: [RFC v2] bpf.2: Use standard types and attributes

[Alejandro Colomar (man-pages) via Gcc-patches]

Hi Greg and Alexei,


On Tue, May 04, 2021 at 07:12:01AM -0700, Alexei Starovoitov wrote:

For the same reasons as explained earlier:
Nacked-by: Alexei Starovoitov 


Okay, I'll add that.


On 5/4/21 4:24 PM, Greg KH wrote:> I agree, the two are not the same 
type at all, this change should not be

accepted.


I get that in the kernel you don't use the standard fixed-width types 
(with some exceptions), probably not to mess with code that relies on 
 not being included (I hope there's not much code that relies 
on this in 2021, but who knows).


But, there is zero difference between these types, from the point of 
view of the compiler.  There's 100% compatibility between those types, 
and you're able to mix'n'match them.  See some example below.


Could you please explain why the documentation, which supposedly only 
documents the API and not the internal implementation, should not use 
standard naming conventions?  The standard is much easier to read for 
userspace programmers, which might ignore why the kernel does some 
things in some specific ways.


BTW, just to clarify, bpf.2 is just a small sample to get reviews; the 
original intention was to replace __uNN by uintNN_t in all of the manual 
pages.


Thanks,

Alex

...

Example:

$ cat test.c
#include 

typedef int __s32;

int32_t foo(void);

int main(void)
{
return 1 - foo();
}


__s32 foo(void)
{
return 1;
}
$ cc -Wall -Wextra -Werror -S -Og test.c -o test.s
$ cat test.s
.file   "test.c"
.text
.globl  foo
.type   foo, @function
foo:
.LFB1:
.cfi_startproc
movl$1, %eax
ret
.cfi_endproc
.LFE1:
.size   foo, .-foo
.globl  main
.type   main, @function
main:
.LFB0:
.cfi_startproc
callfoo
movl%eax, %edx
movl$1, %eax
subl%edx, %eax
ret
.cfi_endproc
.LFE0:
.size   main, .-main
.ident  "GCC: (Debian 10.2.1-6) 10.2.1 20210110"
.section.note.GNU-stack,"",@progbits
$


--
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/

Re: RFC: Changing AC_PROG_CC to AC_PROG_CC_C99 in top level configure

[Simon Marchi via Gcc-patches]

On 2021-05-04 8:42 a.m., Nick Clifton wrote:
> Hi Guys,
> 
> On 4/30/21 7:36 PM, Simon Marchi wrote:
>> I think this fix is obvious enough, I encourage you to push it,
> 
> OK - I have pushed the patch to the mainline branches of both
> the gcc and binutils-gfdb repositories.
> 
> Cheers
>   Nick
> 

Thanks Nick!

Simon

[PATCH] testsuite/s390: Fix risbg-ll-3.c f2_cconly test.

[Robin Dapp via Gcc-patches]

Hi,

instead of selecting bits 62 to (wraparound) 59 from r2 and inserting 
them into r3, we select bits 60 to 62 from r3 and insert them into r2 
nowadays.  Adjust the test accordingly.


Is this OK?

Regards
 Robin

gcc/testsuite/ChangeLog:

* gcc.target/s390/risbg-ll-3.c: Change match pattern.
>From ca1a204ff1753f4902bb58668d0ceafcc17d1232 Mon Sep 17 00:00:00 2001
From: Robin Dapp 
Date: Tue, 27 Apr 2021 16:17:35 +0200
Subject: [PATCH] testsuite/s390: Fix risbg-ll-3.c f2_cconly test.

Instead of selecting bits 62 to (wraparound) 59 from r2 and inserting them
into r3, we select bits 60 to 62 from r3 and insert them into r2
nowadays.  Adjust the test accordingly.
---
 gcc/testsuite/gcc.target/s390/risbg-ll-3.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/s390/risbg-ll-3.c b/gcc/testsuite/gcc.target/s390/risbg-ll-3.c
index 90d37f2c1ce..864b0d6c417 100644
--- a/gcc/testsuite/gcc.target/s390/risbg-ll-3.c
+++ b/gcc/testsuite/gcc.target/s390/risbg-ll-3.c
@@ -37,7 +37,7 @@ i64 f2 (i64 v_a, i64 v_b)
 void f2_bar ();
 void f2_cconly (i64 v_a, i64 v_b)
 {
-/* { dg-final { scan-assembler "f2_cconly:\n\trisbg\t%r3,%r2,63,59,0\n\tber\t%r14\n\tjg\tf2_bar\n" { target { lp64 } } } } */
+/* { dg-final { scan-assembler "f2_cconly:\n\trisbg\t%r2,%r3,60,62,0\n\tber\t%r14\n\tjg\tf2_bar\n" { target { lp64 } } } } */
 /* { dg-final { scan-assembler "f2_cconly:\n\trisbgn\t%r3,%r2,0,0\\\+32-1,64-0-32\n\trisbg\t%r3,%r5,60,62,0\n\tber\t%r14\n\tjg\tf2_bar\n" { target { ! lp64 } } } } */
   if ((v_a & -15) | (v_b & 14))
 f2_bar();
-- 
2.23.0

[committed] Trivial bfin-elf fix

[Jeff Law via Gcc-patches]

Whee, no more cc0!  This fixes trivial fallout.  Installed on the trunk.


Jeff

commit b50ccaf6dd743c373af95e90935b9a2b72157f3a
Author: Jeff Law 
Date:   Tue May 4 08:56:28 2021 -0600

Make bfin-elf build again

gcc/
* config/bfin/bfin.h (NOTICE_UPDATE_CC): Remove.

diff --git a/gcc/config/bfin/bfin.h b/gcc/config/bfin/bfin.h
index f282d05d43d..823ca2d7124 100644
--- a/gcc/config/bfin/bfin.h
+++ b/gcc/config/bfin/bfin.h
@@ -786,8 +786,6 @@ typedef struct {
  || GET_CODE (X) == LABEL_REF  \
  || (GET_CODE (X) == CONST && symbolic_reference_mentioned_p (X)))
 
-#define NOTICE_UPDATE_CC(EXPR, INSN) 0
-
 /* Max number of bytes we can move from memory to memory
in one reasonably fast instruction.  */
 #define MOVE_MAX UNITS_PER_WORD

Re: [PATCH 9/9] arm: Auto-vectorization for MVE: vld4/vst4

[Christophe Lyon via Gcc-patches]

On Tue, 4 May 2021 at 14:03, Andre Vieira (lists)
 wrote:
>
> Hi Christophe,
>
> The series LGTM but you'll need the approval of an arm port maintainer
> before committing. I only did code-review, did not try to build/run tests.
>

Hi Andre,

Thanks for the comments!

> Kind regards,
> Andre
>
> On 30/04/2021 15:09, Christophe Lyon via Gcc-patches wrote:
> > This patch enables MVE vld4/vst4 instructions for auto-vectorization.
> > We move the existing expanders from neon.md and enable them for MVE,
> > calling the respective emitter.
> >
> > 2021-03-12  Christophe Lyon  
> >
> >   gcc/
> >   * config/arm/neon.md (vec_load_lanesxi)
> >   (vec_store_lanexoi): Move ...
> >   * config/arm/vec-common.md: here.
> >
> >   gcc/testsuite/
> >   * gcc.target/arm/simd/mve-vld4.c: New test, derived from
> >   slp-perm-3.c
> > ---
> >   gcc/config/arm/neon.md   |  20 
> >   gcc/config/arm/vec-common.md |  26 +
> >   gcc/testsuite/gcc.target/arm/simd/mve-vld4.c | 140 
> > +++
> >   3 files changed, 166 insertions(+), 20 deletions(-)
> >   create mode 100644 gcc/testsuite/gcc.target/arm/simd/mve-vld4.c
> >
> > diff --git a/gcc/config/arm/neon.md b/gcc/config/arm/neon.md
> > index bc8775c..fb58baf 100644
> > --- a/gcc/config/arm/neon.md
> > +++ b/gcc/config/arm/neon.md
> > @@ -5617,16 +5617,6 @@ (define_insn "neon_vld4"
> >   (const_string "neon_load4_4reg")))]
> >   )
> >
> > -(define_expand "vec_load_lanesxi"
> > -  [(match_operand:XI 0 "s_register_operand")
> > -   (match_operand:XI 1 "neon_struct_operand")
> > -   (unspec:VQ2 [(const_int 0)] UNSPEC_VSTRUCTDUMMY)]
> > -  "TARGET_NEON"
> > -{
> > -  emit_insn (gen_neon_vld4 (operands[0], operands[1]));
> > -  DONE;
> > -})
> > -
> >   (define_expand "neon_vld4"
> > [(match_operand:XI 0 "s_register_operand")
> >  (match_operand:XI 1 "neon_struct_operand")
> > @@ -5818,16 +5808,6 @@ (define_insn "neon_vst4"
> >   (const_string "neon_store4_4reg")))]
> >   )
> >
> > -(define_expand "vec_store_lanesxi"
> > -  [(match_operand:XI 0 "neon_struct_operand")
> > -   (match_operand:XI 1 "s_register_operand")
> > -   (unspec:VQ2 [(const_int 0)] UNSPEC_VSTRUCTDUMMY)]
> > -  "TARGET_NEON"
> > -{
> > -  emit_insn (gen_neon_vst4 (operands[0], operands[1]));
> > -  DONE;
> > -})
> > -
> >   (define_expand "neon_vst4"
> > [(match_operand:XI 0 "neon_struct_operand")
> >  (match_operand:XI 1 "s_register_operand")
> > diff --git a/gcc/config/arm/vec-common.md b/gcc/config/arm/vec-common.md
> > index 7abefea..d46b78d 100644
> > --- a/gcc/config/arm/vec-common.md
> > +++ b/gcc/config/arm/vec-common.md
> > @@ -512,3 +512,29 @@ (define_expand "vec_store_lanesoi"
> >   emit_insn (gen_mve_vst2q (operands[0], operands[1]));
> > DONE;
> >   })
> > +
> > +(define_expand "vec_load_lanesxi"
> > +  [(match_operand:XI 0 "s_register_operand")
> > +   (match_operand:XI 1 "neon_struct_operand")
> > +   (unspec:VQ2 [(const_int 0)] UNSPEC_VSTRUCTDUMMY)]
> > +  "TARGET_NEON || TARGET_HAVE_MVE"
> > +{
> > +  if (TARGET_NEON)
> > +emit_insn (gen_neon_vld4 (operands[0], operands[1]));
> > +  else
> > +emit_insn (gen_mve_vld4q (operands[0], operands[1]));
> > +  DONE;
> > +})
> > +
> > +(define_expand "vec_store_lanesxi"
> > +  [(match_operand:XI 0 "neon_struct_operand")
> > +   (match_operand:XI 1 "s_register_operand")
> > +   (unspec:VQ2 [(const_int 0)] UNSPEC_VSTRUCTDUMMY)]
> > +  "TARGET_NEON || TARGET_HAVE_MVE"
> > +{
> > +  if (TARGET_NEON)
> > +emit_insn (gen_neon_vst4 (operands[0], operands[1]));
> > +  else
> > +emit_insn (gen_mve_vst4q (operands[0], operands[1]));
> > +  DONE;
> > +})
> > diff --git a/gcc/testsuite/gcc.target/arm/simd/mve-vld4.c 
> > b/gcc/testsuite/gcc.target/arm/simd/mve-vld4.c
> > new file mode 100644
> > index 000..ce3e755
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/arm/simd/mve-vld4.c
> > @@ -0,0 +1,140 @@
> > +/* { dg-do assemble } */
> > +/* { dg-require-effective-target arm_v8_1m_mve_fp_ok } */
> > +/* { dg-add-options arm_v8_1m_mve_fp } */
> > +/* { dg-additional-options "-O3" } */
> > +
> > +#include 
> > +
> > +#define M00 100
> > +#define M10 216
> > +#define M20 23
> > +#define M30 237
> > +#define M01 1322
> > +#define M11 13
> > +#define M21 27271
> > +#define M31 2280
> > +#define M02 74
> > +#define M12 191
> > +#define M22 500
> > +#define M32 111
> > +#define M03 134
> > +#define M13 117
> > +#define M23 11
> > +#define M33 771
> > +
> > +#define N 128
> > +
> > +/* Integer tests.  */
> > +#define FUNC(SIGN, TYPE, BITS) 
> >   \
> > +  void foo_##SIGN##BITS##x (TYPE##BITS##_t *__restrict__ pInput, \
> > + TYPE##BITS##_t *__restrict__ pOutput)   \
> > +  {  \
> > +unsigned int i;  \
> > +

[PATCH] testsuite: Add s390 to gcc.dg/vect/slp-21.c

[Robin Dapp via Gcc-patches]

Hi,

on s390 we vectorize 4 statements using SLP.  Add s390*-*-* to the
appropriate dg-finals.

Is that OK?

Regards
 Robin

gcc/testsuite/ChangeLog:

* gcc.dg/vect/slp-21.c: Add s390.
>From 5f31f411ee36be8c8f3000cfc07b2609796142b7 Mon Sep 17 00:00:00 2001
From: Robin Dapp 
Date: Tue, 27 Apr 2021 17:11:54 +0200
Subject: [PATCH] testsuite: Add s390 to gcc.dg/vect/slp-21.c

On s390 we vectorize 4 statements using SLP.  Add s390*-*-* to the
appropriate dg-finals.

gcc/testsuite/ChangeLog:

	* gcc.dg/vect/slp-21.c: Add s390.
---
 gcc/testsuite/gcc.dg/vect/slp-21.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/vect/slp-21.c b/gcc/testsuite/gcc.dg/vect/slp-21.c
index 85393975b45..77152d7252a 100644
--- a/gcc/testsuite/gcc.dg/vect/slp-21.c
+++ b/gcc/testsuite/gcc.dg/vect/slp-21.c
@@ -210,7 +210,7 @@ int main (void)
 
Not all vect_perm targets support that, and it's a bit too specific to have
its own effective-target selector, so we just test targets directly.  */
-/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 4 "vect" { target powerpc64*-*-* } } } */
-/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 2 "vect" { target { vect_strided4 && { ! powerpc64*-*-* } } } } } */
+/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 4 "vect" { target powerpc64*-*-* s390*-*-* } } } */
+/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 2 "vect" { target { vect_strided4 && { ! powerpc64*-*-* s390*-*-* } } } } } */
 /* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 0 "vect"  { target { ! { vect_strided4 } } } } } */
   
-- 
2.23.0

Re: Minor testsuite fix for cr16 and xstormy16 targets

[Jeff Law via Gcc-patches]

On 5/4/2021 2:33 AM, Richard Biener wrote:

On Mon, May 3, 2021 at 6:08 PM Jeff Law via Gcc-patches
 wrote:


Richi's recent work twiddles dse1's actions for these targets. This
patch just updates the expected output.  I'll keep an eye on other
targets as their results trickle in.


Committed to the trunk,

Thanks - the same case apparently also happens for
x86_64 with -m32, I'll adjust for that.


Thanks.  I've got some more on the embedded side to commit/push.


Jeff

Re: [PATCH] Add gnu::diagnose_as attribute

[Matthias Kretz]

On Tuesday, 4 May 2021 16:23:23 CEST Matthias Kretz wrote:
> On Tuesday, 4 May 2021 15:34:13 CEST David Malcolm wrote:
> > Does the patch interact correctly with the %H and %I codes that try to
> > show the differences between two template types?
> 
> I don't know. I'll try to find out. If you have a good idea (or pointer) for
> a testcase, let me know.

I see it now. It currently does not interact with %H and %I (at least in my 
tests). I'll investigate what it should do.

-- 
──
 Dr. Matthias Kretz   https://mattkretz.github.io
 GSI Helmholtz Centre for Heavy Ion Research   https://gsi.de
 std::experimental::simd  https://github.com/VcDevel/std-simd
──

Re: [RFC v2] bpf.2: Use standard types and attributes

[Greg KH via Gcc-patches]

On Tue, May 04, 2021 at 07:12:01AM -0700, Alexei Starovoitov wrote:
> On Tue, May 4, 2021 at 4:05 AM Alejandro Colomar  
> wrote:
> >
> > Some manual pages are already using C99 syntax for integral
> > types 'uint32_t', but some aren't.  There are some using kernel
> > syntax '__u32'.  Fix those.
> >
> > Some pages also document attributes, using GNU syntax
> > '__attribute__((xxx))'.  Update those to use the shorter and more
> > portable C11 keywords such as 'alignas()' when possible, and C2x
> > syntax '[[gnu::xxx]]' elsewhere, which hasn't been standardized
> > yet, but is already implemented in GCC, and available through
> > either --std=c2x or any of the --std=gnu... options.
> >
> > The standard isn't very clear on how to use alignas() or
> > [[]]-style attributes, so the following link is useful in the case
> > of 'alignas()' and '[[gnu::aligned()]]':
> > 
> >
> > Signed-off-by: Alejandro Colomar 
> > Cc: LKML 
> > Cc: glibc 
> > Cc: GCC 
> > Cc: Alexei Starovoitov 
> > Cc: bpf 
> > Cc: David Laight 
> > Cc: Zack Weinberg 
> > Cc: Joseph Myers 
> > ---
> >  man2/bpf.2 | 49 -
> >  1 file changed, 24 insertions(+), 25 deletions(-)
> >
> > diff --git a/man2/bpf.2 b/man2/bpf.2
> > index 6e1ffa198..04b8fbcef 100644
> > --- a/man2/bpf.2
> > +++ b/man2/bpf.2
> > @@ -186,41 +186,40 @@ commands:
> >  .PP
> >  .in +4n
> >  .EX
> > -union bpf_attr {
> > +union [[gnu::aligned(8)]] bpf_attr {
> >  struct {/* Used by BPF_MAP_CREATE */
> > -__u32 map_type;
> > -__u32 key_size;/* size of key in bytes */
> > -__u32 value_size;  /* size of value in bytes */
> > -__u32 max_entries; /* maximum number of entries
> > -  in a map */
> > +uint32_tmap_type;
> > +uint32_tkey_size;/* size of key in bytes */
> > +uint32_tvalue_size;  /* size of value in bytes */
> > +uint32_tmax_entries; /* maximum number of entries
> > +in a map */
> 
> For the same reasons as explained earlier:
> Nacked-by: Alexei Starovoitov 

I agree, the two are not the same type at all, this change should not be
accepted.

thanks,

greg k-h

Re: [PATCH] Add gnu::diagnose_as attribute

[Matthias Kretz]

On Tuesday, 4 May 2021 15:34:13 CEST David Malcolm wrote:
> On Tue, 2021-05-04 at 13:13 +0200, Matthias Kretz wrote:
> > This attribute overrides the diagnostics output string for the entity
> > it
> > appertains to. The motivation is to improve QoI for library TS
> > implementations, where diagnostics have a very bad signal-to-noise
> > ratio
> > due to the long namespaces involved.
> > [...]
> 
> Thanks for the patch, it looks very promising.

Thanks. I'm new to modifying the compiler like this, so please be extra 
careful with my patch. I believe I understand most of what I did, but I might 
have misunderstood. :)

> The patch has no testcases; it should probably add test coverage for:
> - the various places and ways in which diagnose_as can affect the
> output,
> - disabling it with the option
> - the various ways in which the user can get diagnose_as wrong
> - etc

Right. If you know of an existing similar testcase, that'd help me a lot to 
get started.

> Does the patch affect the output of labels when underlining ranges of
> source code in diagnostics?

AFAIU (and tested), it doesn't affect source code output. So, no?

> Does the patch interact correctly with the %H and %I codes that try to
> show the differences between two template types?

I don't know. I'll try to find out. If you have a good idea (or pointer) for a 
testcase, let me know.

> I have some minor nits from a diagnostics point of view:
> [...]
> Please add an auto_diagnostic_group here so that the "inform" is
> associated with the "error".
> [...]
> diagnose_as should be in quotes here (%< and %>).
> [...]
> Please quote extern "C":

Thanks. All done in my tree. I'll work on testcases before sending an updated 
patch.

> Thanks again for the patch; hope this is constructive




-- 
──
 Dr. Matthias Kretz   https://mattkretz.github.io
 GSI Helmholtz Centre for Heavy Ion Research   https://gsi.de
 std::experimental::simd  https://github.com/VcDevel/std-simd
──

Re: [PATCH] s390/testsuite: Fix oscbreak-1.c.

[Robin Dapp via Gcc-patches]

Hi,


Yeah, that's because of the very limited analysis we do in the backend to 
detect such cases. In fact
we probably would want to have an OSC break in many of them as well.

For me the testcase appears to work with -O2 on all the -march levels. I think 
-O2 would be
preferred because that's what is most frequently used.



Is it OK?


Yes, either with -O2 or the options you have proposed if -O2 doesn't work out 
for you.


-O2 did not work reliably for me with different --with_arch settings. 
I'm going to commit the -O1 -fschedule-insns version then.


Regards
 Robin

Re: [RFC v2] bpf.2: Use standard types and attributes

[Alexei Starovoitov via Gcc-patches]

On Tue, May 4, 2021 at 4:05 AM Alejandro Colomar  wrote:
>
> Some manual pages are already using C99 syntax for integral
> types 'uint32_t', but some aren't.  There are some using kernel
> syntax '__u32'.  Fix those.
>
> Some pages also document attributes, using GNU syntax
> '__attribute__((xxx))'.  Update those to use the shorter and more
> portable C11 keywords such as 'alignas()' when possible, and C2x
> syntax '[[gnu::xxx]]' elsewhere, which hasn't been standardized
> yet, but is already implemented in GCC, and available through
> either --std=c2x or any of the --std=gnu... options.
>
> The standard isn't very clear on how to use alignas() or
> [[]]-style attributes, so the following link is useful in the case
> of 'alignas()' and '[[gnu::aligned()]]':
> 
>
> Signed-off-by: Alejandro Colomar 
> Cc: LKML 
> Cc: glibc 
> Cc: GCC 
> Cc: Alexei Starovoitov 
> Cc: bpf 
> Cc: David Laight 
> Cc: Zack Weinberg 
> Cc: Joseph Myers 
> ---
>  man2/bpf.2 | 49 -
>  1 file changed, 24 insertions(+), 25 deletions(-)
>
> diff --git a/man2/bpf.2 b/man2/bpf.2
> index 6e1ffa198..04b8fbcef 100644
> --- a/man2/bpf.2
> +++ b/man2/bpf.2
> @@ -186,41 +186,40 @@ commands:
>  .PP
>  .in +4n
>  .EX
> -union bpf_attr {
> +union [[gnu::aligned(8)]] bpf_attr {
>  struct {/* Used by BPF_MAP_CREATE */
> -__u32 map_type;
> -__u32 key_size;/* size of key in bytes */
> -__u32 value_size;  /* size of value in bytes */
> -__u32 max_entries; /* maximum number of entries
> -  in a map */
> +uint32_tmap_type;
> +uint32_tkey_size;/* size of key in bytes */
> +uint32_tvalue_size;  /* size of value in bytes */
> +uint32_tmax_entries; /* maximum number of entries
> +in a map */

For the same reasons as explained earlier:
Nacked-by: Alexei Starovoitov 

[wwwdocs] Remove CC0 from backends.html

[Segher Boessenkool]

Pushed.  What is next?  :-)


Segher


---
 htdocs/backends.html | 105 +--
 1 file changed, 52 insertions(+), 53 deletions(-)

diff --git a/htdocs/backends.html b/htdocs/backends.html
index 8d95e915709c..8034a5776360 100644
--- a/htdocs/backends.html
+++ b/htdocs/backends.html
@@ -49,7 +49,6 @@ l   Port cannot use ILP32 mode integer arithmetic.
 q   Port can use LP64 mode integer arithmetic.
 r   Port can switch between ILP32 and LP64 at runtime.
 (Not necessarily supported by all subtargets.)
-c   Port uses cc0.
 p   Port uses define_peephole (as opposed to define_peephole2).
 b   Port uses '"* ..."' notation for output template code.
 f   Port does not define prologue and/or epilogue RTL expanders.
@@ -67,58 +66,58 @@ s   arch-elf is the correct target to use with 
the simulator
 
 
|  Characteristics
-Target | HMSLQNFICBD lqrcpbfmgiates
+---
-aarch64| Qq   b  gia  s
-alpha  |  ?  Q   Cq mgi  e
-arc|  B   b  gia
-arm|  b   ia  s
-avr|L  FIl  cp   g
-bfin   |   F gi
-c6x|   S CB  gi
-cr16   |L  F C  cgs
-cris   |   F  B  gi   s
-csky   |  b   ia
-epiphany   | C   gi   s
-fr30   | ??FI B  pb mgs
-frv| ??   B   b   i   s
-gcn|   S C D  qa e
-h8300  |   FI B  gs
-i386   | Qq   b   ia
-ia64   |   ? Q   Cqr  b m i
-iq2000 | ???   FICB   b  g  t
-lm32   |   F g
-m32c   |L  FIlb  gs
-m32r   |   FI b   s
-m68k   | pb   i
-mcore  |  ?FIpb mgs
-mep|   F Cb  g  t s
-microblaze | CB   i   s
-mips   | Q   CB   qr  ia  s
-mmix   | HM  Q   Cq   i  e
-mn10300| ??  gi   s
-moxie  |   F g  t s
-msp430 |L  FIlb  gs
-nds32  |   F Cia  s
-nios2  | Cia
-nvptx  |   S Q   Cq mg   e
-pa | Q   CBD  qr  b   i  e
-pdp11  |L   ICqr  b  e
-powerpcspe | Q   Cqr pb   ia
-pru|L  F   a  s
-riscv  | Q   Cqr gia
-rl78   |L  F l   gs
-rs6000 | Q   Cqr pb   ia
-rx |  s
-s390   | Qqr gia e
-sh | Q   CB   qr pi
-sparc  | Q   CB   qr  b   ia
-stormy16   | ???L  FIC D lb   i
-tilegx | Q   Cq  gi  e
-tilepro|   S   F C   gi  e
-v850   | g a  s
-vax|  M I b   i  e
-visium |  B  g  t s
+Target | HMSLQNFICBD lqrpbfmgiates
+---+--
+aarch64| Qq  b  gia  s
+alpha  |  ?  Q   Cqmgi  e
+arc|  B  b  gia
+arm| b   ia  s
+avr|L  FIl  p   g
+bfin   |   Fgi
+c6x|   S CB gi
+cr16   |L  F C  gs
+cris   |   F  B gi   s
+csky   | b   ia
+epiphany   | C  gi   s
+fr30   | ??FI B pb mgs
+frv| ??   B  b   i   s
+gcn|   S C D  q   a e
+h8300  |   FI B gs
+i386   | Qq  b   ia
+ia64   |   ? Q   Cqr b m i
+iq2000 | ???   FICB  b  g  t
+lm32   |   Fg
+m32c   |L  FIl   b  gs
+m32r   |   FIb   s
+m68k   |pb   i
+mcore  |  ?FI   pb mgs
+mep|   F C   b  g  t s
+microblaze | CB  i   s
+mips   | Q   CB   qr ia  s
+mmix   | HM  Q   Cq  i  e
+mn10300| ?? gi   s
+moxie  |   Fg  t s
+msp430 |L  FIl   b  gs
+nds32  |   F C   ia  s
+nios2  | C   ia
+nvptx  |   S Q   Cqmg   e
+pa | Q   CBD  qr b   i  e
+pdp11  |L   ICqr b  e
+powerpcspe | Q   Cqrpb   ia
+pru|L  F  a  s
+riscv  | Q   Cqrgia
+rl78   |L  F l  gs
+rs6000 | Q   Cqrpb   ia
+rx | s
+s390   | Qqrgia e
+sh | Q   CB   qrpi
+sparc  | Q   CB   qr b   ia
+stormy16   | ???L  FIC D l   b   i
+tilegx | Q   Cq gi  e
+tilepro|   S   F C  gi  e
+v850   |g a  s
+vax|  M Ib   i  e
+visium |  B g  t s
 xtensa 

Re: [libstdc++] Inconsistent detection of __int128

[David Edelsohn via Gcc-patches]

On Tue, May 4, 2021 at 7:12 AM Jonathan Wakely  wrote:
>
> On 30/04/21 16:24 -0400, David Edelsohn via Libstdc++ wrote:
> >On Fri, Jan 8, 2021 at 11:10 AM Jonathan Wakely  wrote:
> >>
> >> On 03/01/21 22:26 -0500, David Edelsohn via Libstdc++ wrote:
> >> >On Sun, Jan 3, 2021 at 9:45 PM Jonathan Wakely  
> >> >wrote:
> >> >>
> >> >> On Mon, 4 Jan 2021, 00:44 David Edelsohn via Libstdc++, 
> >> >>  wrote:
> >> >>>
> >> >>> Or is there some other reason that _GLIBCXX_USE_INT128 and
> >> >>> __SIZEOF_INT128__ are used in different contexts?
> >> >>
> >> >> Yes.
> >> >>
> >> >> I'll reply when I'm back from taking some time off. Probably Wednesday.
> >> >
> >> >If the uses of _GLIBCXX_USE_INT128 in libstdc++ headers specifically
> >> >are checking if __int128 type is different than "long" and "long
> >> >long", as opposed to the availability of the __int128, can c++config.h
> >>
> >> Yes, the test is not just "is __int128 a valid type?" but "should we
> >> use __int128 as a larger integer type?"
> >>
> >> We used to use it more widely, but many places that use __int128
> >> conditionally now check __GLIBCXX_INT_N_0 instead, because that is
> >> defined when __int128 is available and we're not compiling in a
> >> "strict ansi" dialect.
> >>
> >> Of the two remaining uses of _GLIBCXX_USE_INT128 I think one is wrong
> >> and should test __SIZEOF__INT128__ directly. We specifically do want
> >> to use unsigned __int128 in __to_chars_unsigned_type even if it's the
> >> same as a standard type.
> >>
> >> So that leaves one remaining use, and I think that should do as you
> >> suggest here ...
> >>
> >> >define _GLIBCXX_USE_INT128 by comparing __SIZEOF_INT128__ to
> >> >__SIZEOF_LONG_LONG__ and __SIZEOF_LONG__ instead of the libstdc++
> >> >configure template typename test?
> >>
> >> Yes, that seems fine. But since we only need it in one place, let's
> >> just do that test in that one place. It makes the purpose of the test
> >> more explicit, and so you don't need to look up what
> >> _GLIBCXX_USE_INT128 means and when it's true.
> >>
> >> Does the attached patch work for you?
> >
> >Hi, Jonathan
> >
> >Thanks for pushing the INT64_T patch.
> >
> >I tested your revised patch in January and it works perfectly.
> >
> >Could you push your INT128 patch to trunk when you have a moment?
> >
> >Thanks, David
>
> I've pushed the attached to trunk after testing on powerpc-aix and
> x86_64-linux.
>
> Contrary to what I said in January, I think both sues of
> _GLIBCXX_USE_INT128 do want to only use __int128 if it's larger than
> long long. For __to_chars_unsigned_type there's no point trying to use
> unsigned __int128 if it's the same size as unsigned long long, because
> we'd already have chosen unsigned long long.

Hi, Jonathan

Excellent.  Thank you very much for addressing this issue and removing
the multilib size dependencies in libstdc++ headers.

Thanks, David

[PATCH] tree-optimization/100414 - compute dominance info in phiopt

[Richard Biener]

phiopt now has dominator queries but fails to compute dominance
info.

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

2021-05-04  Richard Biener  

PR tree-optimization/100414
* tree-ssa-phiopt.c (get_non_trapping): Do not compute dominance
info here.
(tree_ssa_phiopt_worker): But unconditionally here.

* gcc.dg/pr100414.c: New testcase.
---
 gcc/testsuite/gcc.dg/pr100414.c | 9 +
 gcc/tree-ssa-phiopt.c   | 5 ++---
 2 files changed, 11 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/pr100414.c

diff --git a/gcc/testsuite/gcc.dg/pr100414.c b/gcc/testsuite/gcc.dg/pr100414.c
new file mode 100644
index 000..7876f6b56e9
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr100414.c
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-options "-O -fno-tree-dce -fno-tree-dse -fchecking" } */
+
+int i;
+void
+foo (void)
+{
+  i &= i && __builtin_bswap16 (i);
+}
diff --git a/gcc/tree-ssa-phiopt.c b/gcc/tree-ssa-phiopt.c
index 35ce51e5977..5c18ea16600 100644
--- a/gcc/tree-ssa-phiopt.c
+++ b/gcc/tree-ssa-phiopt.c
@@ -174,6 +174,8 @@ tree_ssa_phiopt_worker (bool do_store_elim, bool 
do_hoist_loads, bool early_p)
   bool cfgchanged = false;
   hash_set *nontrap = 0;
 
+  calculate_dominance_info (CDI_DOMINATORS);
+
   if (do_store_elim)
 /* Calculate the set of non-trapping memory accesses.  */
 nontrap = get_non_trapping ();
@@ -2438,9 +2440,6 @@ get_non_trapping (void)
 {
   nt_call_phase = 0;
   hash_set *nontrap = new hash_set;
-  /* We're going to do a dominator walk, so ensure that we have
- dominance information.  */
-  calculate_dominance_info (CDI_DOMINATORS);
 
   nontrapping_dom_walker (CDI_DOMINATORS, nontrap)
 .walk (cfun->cfg->x_entry_block_ptr);
-- 
2.26.2

Re: [PATCH] Remove CC0

[Segher Boessenkool]

On Tue, May 04, 2021 at 10:44:38AM +0200, Richard Biener wrote:
> On Tue, May 4, 2021 at 1:40 AM Segher Boessenkool
>  wrote:
> >
> > This removes CC0 and all directly related infrastructure.
> >
> > CC_STATUS, CC_STATUS_MDEP, CC_STATUS_MDEP_INIT, and NOTICE_UPDATE_CC
> > are deleted and poisoned.  CC0 is only deleted (some targets use that
> > name for something else).  HAVE_cc0 is automatically generated, and we
> > no longer will do that after this patch.
> >
> > CC_STATUS_INIT is suggested in final.c to also be useful for ports that
> > are not CC0, and at least arm seems to use it for something.  So I am
> > leaving that alone, but most targets that have it could remove it.
> >
> > Is this okay for trunk?
> 
> OK.  Can you adjust the target table in our html pages, removing the cc0 
> column?

Thanks.  Yeah I will :-)


Segher

Re: [PATCH 7/9] arm: Auto-vectorization for MVE: add __fp16 support to VCMP

[Christophe Lyon via Gcc-patches]

On Tue, 4 May 2021 at 13:48, Andre Vieira (lists)
 wrote:
>
> It would be good to also add tests for NEON as you also enable auto-vec
> for it. I checked and I do think the necessary 'neon_vc' patterns exist
> for 'VH', so we should be OK there.
>

Actually since I posted the patch series, I've noticed a regression in
armv8_2-fp16-arith-1.c, because we now vectorize all the float16x[48]_t loops,
but we lose the fact that some FP comparisons can throw exceptions.

I'll have to revisit this patch.

Thanks,

Christophe

> On 30/04/2021 15:09, Christophe Lyon via Gcc-patches wrote:
> > This patch adds __fp16 support to the previous patch that added vcmp
> > support with MVE. For this we update existing expanders to use VDQWH
> > iterator, and add a new expander vcond.  In the
> > process we need to create suitable iterators, and update v_cmp_result
> > as needed.
> >
> > 2021-04-26  Christophe Lyon  
> >
> >   gcc/
> >   * config/arm/iterators.md (V16): New iterator.
> >   (VH_cvtto): New iterator.
> >   (v_cmp_result): Added V4HF and V8HF support.
> >   * config/arm/vec-common.md (vec_cmp): Use VDQWH.
> >   (vcond): Likewise.
> >   (vcond_mask_): Likewise.
> >   (vcond): New expander.
> >
> >   gcc/testsuite/
> >   * gcc.target/arm/simd/mve-compare-3.c: New test with GCC vectors.
> >   * gcc.target/arm/simd/mve-vcmp-f16.c: New test for
> >   auto-vectorization.
> > ---
> >   gcc/config/arm/iterators.md   |  6 
> >   gcc/config/arm/vec-common.md  | 40 
> > ---
> >   gcc/testsuite/gcc.target/arm/simd/mve-compare-3.c | 38 
> > +
> >   gcc/testsuite/gcc.target/arm/simd/mve-vcmp-f16.c  | 30 +
> >   4 files changed, 102 insertions(+), 12 deletions(-)
> >   create mode 100644 gcc/testsuite/gcc.target/arm/simd/mve-compare-3.c
> >   create mode 100644 gcc/testsuite/gcc.target/arm/simd/mve-vcmp-f16.c
> >
> > diff --git a/gcc/config/arm/iterators.md b/gcc/config/arm/iterators.md
> > index a128465..3042baf 100644
> > --- a/gcc/config/arm/iterators.md
> > +++ b/gcc/config/arm/iterators.md
> > @@ -231,6 +231,9 @@ (define_mode_iterator VU [V16QI V8HI V4SI])
> >   ;; Vector modes for 16-bit floating-point support.
> >   (define_mode_iterator VH [V8HF V4HF])
> >
> > +;; Modes with 16-bit elements only.
> > +(define_mode_iterator V16 [V4HI V4HF V8HI V8HF])
> > +
> >   ;; 16-bit floating-point vector modes suitable for moving (includes 
> > BFmode).
> >   (define_mode_iterator VHFBF [V8HF V4HF V4BF V8BF])
> >
> > @@ -571,6 +574,8 @@ (define_mode_attr V_cvtto [(V2SI "v2sf") (V2SF "v2si")
> >   ;; (Opposite) mode to convert to/from for vector-half mode conversions.
> >   (define_mode_attr VH_CVTTO [(V4HI "V4HF") (V4HF "V4HI")
> >   (V8HI "V8HF") (V8HF "V8HI")])
> > +(define_mode_attr VH_cvtto [(V4HI "v4hf") (V4HF "v4hi")
> > + (V8HI "v8hf") (V8HF "v8hi")])
> >
> >   ;; Define element mode for each vector mode.
> >   (define_mode_attr V_elem [(V8QI "QI") (V16QI "QI")
> > @@ -720,6 +725,7 @@ (define_mode_attr V_cmp_result [(V8QI "V8QI") (V16QI 
> > "V16QI")
> >   (define_mode_attr v_cmp_result [(V8QI "v8qi") (V16QI "v16qi")
> >   (V4HI "v4hi") (V8HI  "v8hi")
> >   (V2SI "v2si") (V4SI  "v4si")
> > + (V4HF "v4hi") (V8HF  "v8hi")
> >   (DI   "di")   (V2DI  "v2di")
> >   (V2SF "v2si") (V4SF  "v4si")])
> >
> > diff --git a/gcc/config/arm/vec-common.md b/gcc/config/arm/vec-common.md
> > index 034b48b..3fd341c 100644
> > --- a/gcc/config/arm/vec-common.md
> > +++ b/gcc/config/arm/vec-common.md
> > @@ -366,8 +366,8 @@ (define_expand "vlshr3"
> >   (define_expand "vec_cmp"
> > [(set (match_operand: 0 "s_register_operand")
> >   (match_operator: 1 "comparison_operator"
> > -   [(match_operand:VDQW 2 "s_register_operand")
> > -(match_operand:VDQW 3 "reg_or_zero_operand")]))]
> > +   [(match_operand:VDQWH 2 "s_register_operand")
> > +(match_operand:VDQWH 3 "reg_or_zero_operand")]))]
> > "ARM_HAVE__ARITH
> >  && !TARGET_REALLY_IWMMXT
> >  && (! || flag_unsafe_math_optimizations)"
> > @@ -399,13 +399,13 @@ (define_expand "vec_cmpu"
> >   ;; element-wise.
> >
> >   (define_expand "vcond"
> > -  [(set (match_operand:VDQW 0 "s_register_operand")
> > - (if_then_else:VDQW
> > +  [(set (match_operand:VDQWH 0 "s_register_operand")
> > + (if_then_else:VDQWH
> > (match_operator 3 "comparison_operator"
> > - [(match_operand:VDQW 4 "s_register_operand")
> > -  (match_operand:VDQW 5 "reg_or_zero_operand")])
> > -   (match_operand:VDQW 1 "s_register_operand")
> > -   (match_operand:VDQW 2 "s_register_operand")))]
> > + [(match_operand:VDQWH 4 "s_register_operand")
> > +  (match_operand:VDQWH 5 "reg_or_zero_operand")])
> > +   

Re: [PATCH 6/9] arm: Auto-vectorization for MVE: vcmp

[Christophe Lyon via Gcc-patches]

On Tue, 4 May 2021 at 13:29, Andre Vieira (lists)
 wrote:
>
> Hi Christophe,
>
> On 30/04/2021 15:09, Christophe Lyon via Gcc-patches wrote:
> > Since MVE has a different set of vector comparison operators from
> > Neon, we have to update the expansion to take into account the new
> > ones, for instance 'NE' for which MVE does not require to use 'EQ'
> > with the inverted condition.
> >
> > Conversely, Neon supports comparisons with #0, MVE does not.
> >
> > For:
> > typedef long int vs32 __attribute__((vector_size(16)));
> > vs32 cmp_eq_vs32_reg (vs32 a, vs32 b) { return a == b; }
> >
> > we now generate:
> > cmp_eq_vs32_reg:
> >   vldr.64 d4, .L123   @ 8 [c=8 l=4]  *mve_movv4si/8
> >   vldr.64 d5, .L123+8
> >   vldr.64 d6, .L123+16@ 9 [c=8 l=4]  *mve_movv4si/8
> >   vldr.64 d7, .L123+24
> >   vcmp.i32  eq, q0, q1@ 7 [c=16 l=4]  mve_vcmpeqq_v4si
> >   vpsel q0, q3, q2@ 15[c=8 l=4]  mve_vpselq_sv4si
> >   bx  lr  @ 26[c=8 l=4]  *thumb2_return
> > .L124:
> >   .align  3
> > .L123:
> >   .word   0
> >   .word   0
> >   .word   0
> >   .word   0
> >   .word   1
> >   .word   1
> >   .word   1
> >   .word   1
> >
> > For some reason emit_move_insn (zero, CONST0_RTX (cmp_mode)) produces
> > a pair of vldr instead of vmov.i32, qX, #0
> I think ideally we would even want:
> vpte  eq, q0, q1
> vmovt.i32 q0, #0
> vmove.i32 q0, #1
>
> But we don't have a way to generate VPT blocks with multiple
> instructions yet unfortunately so I guess VPSEL will have to do for now.

TBH,  I looked at what LLVM generates currently ;-)

>
> >
> > 2021-03-01  Christophe Lyon  
> >
> >   gcc/
> >   * config/arm/arm-protos.h (arm_expand_vector_compare): Update
> >   prototype.
> >   * config/arm/arm.c (arm_expand_vector_compare): Add support for
> >   MVE.
> >   (arm_expand_vcond): Likewise.
> >   * config/arm/iterators.md (supf): Remove VCMPNEQ_S, VCMPEQQ_S,
> >   VCMPEQQ_N_S, VCMPNEQ_N_S.
> >   (VCMPNEQ, VCMPEQQ, VCMPEQQ_N, VCMPNEQ_N): Remove.
> >   * config/arm/mve.md (@mve_vcmpq_): Add '@' prefix.
> >   (@mve_vcmpq_f): Likewise.
> >   (@mve_vcmpq_n_f): Likewise.
> >   (@mve_vpselq_): Likewise.
> >   (@mve_vpselq_f"): Likewise.
> >   * config/arm/neon.md (vec_cmp >   and move to vec-common.md.
> >   (vec_cmpu): Likewise.
> >   (vcond): Likewise.
> >   (vcond): Likewise.
> >   (vcondu): Likewise.
> >   (vcond_mask_): Likewise.
> >   * config/arm/unspecs.md (VCMPNEQ_U, VCMPNEQ_S, VCMPEQQ_S)
> >   (VCMPEQQ_N_S, VCMPNEQ_N_S, VCMPEQQ_U, CMPEQQ_N_U, VCMPNEQ_N_U)
> >   (VCMPGEQ_N_S, VCMPGEQ_S, VCMPGTQ_N_S, VCMPGTQ_S, VCMPLEQ_N_S)
> >   (VCMPLEQ_S, VCMPLTQ_N_S, VCMPLTQ_S, VCMPCSQ_N_U, VCMPCSQ_U)
> >   (VCMPHIQ_N_U, VCMPHIQ_U): Remove.
> >   * config/arm/vec-common.md (vec_cmp >   from neon.md.
> >   (vec_cmpu): Likewise.
> >   (vcond): Likewise.
> >   (vcond): Likewise.
> >   (vcondu): Likewise.
> >   (vcond_mask_): Likewise.
> >
> >   gcc/testsuite
> >   * gcc.target/arm/simd/mve-compare-1.c: New test with GCC vectors.
> >   * gcc.target/arm/simd/mve-compare-2.c: New test with GCC vectors.
> >   * gcc.target/arm/simd/mve-compare-scalar-1.c: New test with GCC
> >   vectors.
> >   * gcc.target/arm/simd/mve-vcmp-f32.c: New test for
> >   auto-vectorization.
> >   * gcc.target/arm/simd/mve-vcmp.c: New test for auto-vectorization.
> >
> > add gcc/testsuite/gcc.target/arm/simd/mve-compare-scalar-1.c
> > ---
> >   gcc/config/arm/arm-protos.h|   2 +-
> >   gcc/config/arm/arm.c   | 211 
> > -
> >   gcc/config/arm/iterators.md|   9 +-
> >   gcc/config/arm/mve.md  |  10 +-
> >   gcc/config/arm/neon.md |  87 -
> >   gcc/config/arm/unspecs.md  |  20 --
> >   gcc/config/arm/vec-common.md   | 107 +++
> >   gcc/testsuite/gcc.target/arm/simd/mve-compare-1.c  |  80 
> >   gcc/testsuite/gcc.target/arm/simd/mve-compare-2.c  |  38 
> >   .../gcc.target/arm/simd/mve-compare-scalar-1.c |  69 +++
> >   gcc/testsuite/gcc.target/arm/simd/mve-vcmp-f32.c   |  30 +++
> >   gcc/testsuite/gcc.target/arm/simd/mve-vcmp.c   |  50 +
> >   12 files changed, 547 insertions(+), 166 deletions(-)
> >   create mode 100644 gcc/testsuite/gcc.target/arm/simd/mve-compare-1.c
> >   create mode 100644 gcc/testsuite/gcc.target/arm/simd/mve-compare-2.c
> >   create mode 100644 
> > gcc/testsuite/gcc.target/arm/simd/mve-compare-scalar-1.c
> >   create mode 100644 gcc/testsuite/gcc.target/arm/simd/mve-vcmp-f32.c
> >   create mode 100644 gcc/testsuite/gcc.target/arm/simd/mve-vcmp.c
> >
> > diff --git a/gcc/config/arm/arm-protos.h b/gcc/config/arm/arm-protos.h
> > index 

Re: [PATCH] Add gnu::diagnose_as attribute

[David Malcolm via Gcc-patches]

On Tue, 2021-05-04 at 13:13 +0200, Matthias Kretz wrote:
> From: Matthias Kretz 
> 
> This attribute overrides the diagnostics output string for the entity
> it
> appertains to. The motivation is to improve QoI for library TS
> implementations, where diagnostics have a very bad signal-to-noise
> ratio
> due to the long namespaces involved.
> 
> On Tuesday, 27 April 2021 11:46:48 CEST Jonathan Wakely wrote:
> > I think it's a great idea and would like to use it for all the TS
> > implementations where there is some inline namespace that the user
> > doesn't care about. std::experimental::fundamentals_v1:: would be
> > much
> > better as just std::experimental::, or something like std::[LFTS]::.
> 
> With the attribute, it is possible to solve PR89370 and make
> std::__cxx11::basic_string<_CharT, _Traits, _Alloc> appear as
> std::string in diagnostic output without extra hacks to recognize the
> type.

Thanks for the patch, it looks very promising.

The C++ frontend maintainers will need to review the C++ frontend parts
in detail, so I'll defer to them for the bulk of the review.

Various thoughts:

The patch has no testcases; it should probably add test coverage for:
- the various places and ways in which diagnose_as can affect the
output,
- disabling it with the option
- the various ways in which the user can get diagnose_as wrong
- etc

Does the patch affect the output of labels when underlining ranges of
source code in diagnostics?

Does the patch interact correctly with the %H and %I codes that try to
show the differences between two template types?

I have some minor nits from a diagnostics point of view:

[...snip...]

> diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
> index 4e84e2f9987..80637503310 100644
> --- a/gcc/cp/name-lookup.c
> +++ b/gcc/cp/name-lookup.c

[...]

> +   tree existing
> + = lookup_attribute ("diagnose_as", DECL_ATTRIBUTES (ns));
> +   if (existing
> + && !cp_tree_equal(TREE_VALUE (args),
> +   TREE_VALUE (TREE_VALUE (existing
> + {

Please add an auto_diagnostic_group here so that the "inform" is
associated with the "error".

> +   error ("the namespace %qE already uses a different diagnose_as "
> +  "attribute value", ns);

diagnose_as should be in quotes here (%< and %>).


> +   inform (DECL_SOURCE_LOCATION (ns), "previous declaration here");
> +   continue;
> + }
> +   DECL_ATTRIBUTES (ns) = tree_cons (name, args,
> + DECL_ATTRIBUTES (ns));
> + }
>else
>   {
> warning (OPT_Wattributes, "%qD attribute directive ignored",
> diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
> index a8bfd5fc053..f7b93dc89d7 100644
> --- a/gcc/cp/tree.c
> +++ b/gcc/cp/tree.c

[...snip...]

> +  else if (DECL_LANGUAGE (*node) == lang_c)
> + {
> +   error ("%qE attribute applied to extern \"C\" declaration %qD",

Please quote extern "C":
   %

> +  name, *node);

[...snip...]

Thanks again for the patch; hope this is constructive
Dave

Re: [patch] Generate debug info for local dynamic record types

[Richard Biener via Gcc-patches]

On Sat, May 1, 2021 at 9:04 PM Eric Botcazou  wrote:
>
> Hi,
>
> in Ada you can embed VLAs in local record types and thus end up with dynamic
> offsets in record types, which are currently not well described in DWARF
> because 1) the temporaries generated for them by the gimplifier are naturally
> DECL_IGNORED_P and 2) when the types are referenced in nested subprograms,
> the DWARF back-end does not correctly handle the rewritten references.
>
> The attached patch fixes 1) by reusing the trick already used for VLAs and
> 2) by deferring the resolution of these references to the late DWARF pass.
>
> Tested on x86-64/Linux, both GCC and GDB, OK for the mainline?

OK.  I suppose there's no easy way to build a gnat.dg "guality"
testcase for this?

Thanks,
Richard.

>
> 2021-05-01  Eric Botcazou  
>
> * dwarf2out.c (loc_list_from_tree_1) : During early DWARF, do 
> not
> expand the VALUE_EXPR of variables put in the non-local frame.
> * gimplify.c (gimplify_type_sizes) : If the type is not 
> to
> be ignored for debug info, ensure its variable offsets are not either.
>
> --
> Eric Botcazou

Re: RFC: Changing AC_PROG_CC to AC_PROG_CC_C99 in top level configure

[Nick Clifton via Gcc-patches]

Hi Guys,

On 4/30/21 7:36 PM, Simon Marchi wrote:

I think this fix is obvious enough, I encourage you to push it,


OK - I have pushed the patch to the mainline branches of both
the gcc and binutils-gfdb repositories.

Cheers
  Nick

Re: [PATCH 13/20] aarch64: Use RTL builtins for FP ml[as][q]_laneq intrinsics

[Jonathan Wright via Gcc-patches]

Hi Richard,

I think you may be referencing an older checkout as we refactored this
pattern in a previous change to:

(define_insn "mul_lane3"
 [(set (match_operand:VMUL 0 "register_operand" "=w")
   (mult:VMUL
   (vec_duplicate:VMUL
 (vec_select:
   (match_operand:VMUL 2 "register_operand" "")
   (parallel [(match_operand:SI 3 "immediate_operand" "i")])))
   (match_operand:VMUL 1 "register_operand" "w")))]
  "TARGET_SIMD"
  {
operands[3] = aarch64_endian_lane_rtx (mode, INTVAL (operands[3]));
return "mul\\t%0., %1., %2.[%3]";
  }
  [(set_attr "type" "neon_mul__scalar")]
)

which doesn't help us with the 'laneq' intrinsics as the machine mode for
operands 0 and 1 (of the laneq intrinsics) is narrower than the machine
mode for operand 2.

Thanks,
Jonathan
​

From: Richard Sandiford 
Sent: 30 April 2021 19:18
To: Jonathan Wright 
Cc: gcc-patches@gcc.gnu.org 
Subject: Re: [PATCH 13/20] aarch64: Use RTL builtins for FP ml[as][q]_laneq 
intrinsics

Richard Sandiford via Gcc-patches  writes:
> Jonathan Wright  writes:
>> diff --git a/gcc/config/aarch64/aarch64-simd.md 
>> b/gcc/config/aarch64/aarch64-simd.md
>> index 
>> bdee49f74f4725409d33af733bb55be290b3f0e7..234762960bd6df057394f753072ef65a6628a43d
>>  100644
>> --- a/gcc/config/aarch64/aarch64-simd.md
>> +++ b/gcc/config/aarch64/aarch64-simd.md
>> @@ -734,6 +734,22 @@
>>[(set_attr "type" "neon_mul__scalar")]
>>  )
>>
>> +(define_insn "mul_laneq3"
>> +  [(set (match_operand:VDQSF 0 "register_operand" "=w")
>> +(mult:VDQSF
>> +  (vec_duplicate:VDQSF
>> +(vec_select:
>> +  (match_operand:V4SF 2 "register_operand" "w")
>> +  (parallel [(match_operand:SI 3 "immediate_operand" "i")])))
>> +  (match_operand:VDQSF 1 "register_operand" "w")))]
>> +  "TARGET_SIMD"
>> +  {
>> +operands[3] = aarch64_endian_lane_rtx (V4SFmode, INTVAL (operands[3]));
>> +return "fmul\\t%0., %1., %2.[%3]";
>> +  }
>> +  [(set_attr "type" "neon_fp_mul_s_scalar")]
>> +)
>> +

Oops, sorry, I just realised that this pattern does already exist as:

(define_insn "*aarch64_mul3_elt"
 [(set (match_operand:VMUL 0 "register_operand" "=w")
(mult:VMUL
  (vec_duplicate:VMUL
  (vec_select:
(match_operand:VMUL 1 "register_operand" "")
(parallel [(match_operand:SI 2 "immediate_operand")])))
  (match_operand:VMUL 3 "register_operand" "w")))]
  "TARGET_SIMD"
  {
operands[2] = aarch64_endian_lane_rtx (mode, INTVAL (operands[2]));
return "mul\\t%0., %3., %1.[%2]";
  }
  [(set_attr "type" "neon_mul__scalar")]
)

Thanks,
Richard

Re: [PATCH 9/9] arm: Auto-vectorization for MVE: vld4/vst4

[Andre Vieira (lists) via Gcc-patches]

Hi Christophe,

The series LGTM but you'll need the approval of an arm port maintainer 
before committing. I only did code-review, did not try to build/run tests.


Kind regards,
Andre

On 30/04/2021 15:09, Christophe Lyon via Gcc-patches wrote:

This patch enables MVE vld4/vst4 instructions for auto-vectorization.
We move the existing expanders from neon.md and enable them for MVE,
calling the respective emitter.

2021-03-12  Christophe Lyon  

gcc/
* config/arm/neon.md (vec_load_lanesxi)
(vec_store_lanexoi): Move ...
* config/arm/vec-common.md: here.

gcc/testsuite/
* gcc.target/arm/simd/mve-vld4.c: New test, derived from
slp-perm-3.c
---
  gcc/config/arm/neon.md   |  20 
  gcc/config/arm/vec-common.md |  26 +
  gcc/testsuite/gcc.target/arm/simd/mve-vld4.c | 140 +++
  3 files changed, 166 insertions(+), 20 deletions(-)
  create mode 100644 gcc/testsuite/gcc.target/arm/simd/mve-vld4.c

diff --git a/gcc/config/arm/neon.md b/gcc/config/arm/neon.md
index bc8775c..fb58baf 100644
--- a/gcc/config/arm/neon.md
+++ b/gcc/config/arm/neon.md
@@ -5617,16 +5617,6 @@ (define_insn "neon_vld4"
  (const_string "neon_load4_4reg")))]
  )
  
-(define_expand "vec_load_lanesxi"

-  [(match_operand:XI 0 "s_register_operand")
-   (match_operand:XI 1 "neon_struct_operand")
-   (unspec:VQ2 [(const_int 0)] UNSPEC_VSTRUCTDUMMY)]
-  "TARGET_NEON"
-{
-  emit_insn (gen_neon_vld4 (operands[0], operands[1]));
-  DONE;
-})
-
  (define_expand "neon_vld4"
[(match_operand:XI 0 "s_register_operand")
 (match_operand:XI 1 "neon_struct_operand")
@@ -5818,16 +5808,6 @@ (define_insn "neon_vst4"
  (const_string "neon_store4_4reg")))]
  )
  
-(define_expand "vec_store_lanesxi"

-  [(match_operand:XI 0 "neon_struct_operand")
-   (match_operand:XI 1 "s_register_operand")
-   (unspec:VQ2 [(const_int 0)] UNSPEC_VSTRUCTDUMMY)]
-  "TARGET_NEON"
-{
-  emit_insn (gen_neon_vst4 (operands[0], operands[1]));
-  DONE;
-})
-
  (define_expand "neon_vst4"
[(match_operand:XI 0 "neon_struct_operand")
 (match_operand:XI 1 "s_register_operand")
diff --git a/gcc/config/arm/vec-common.md b/gcc/config/arm/vec-common.md
index 7abefea..d46b78d 100644
--- a/gcc/config/arm/vec-common.md
+++ b/gcc/config/arm/vec-common.md
@@ -512,3 +512,29 @@ (define_expand "vec_store_lanesoi"
  emit_insn (gen_mve_vst2q (operands[0], operands[1]));
DONE;
  })
+
+(define_expand "vec_load_lanesxi"
+  [(match_operand:XI 0 "s_register_operand")
+   (match_operand:XI 1 "neon_struct_operand")
+   (unspec:VQ2 [(const_int 0)] UNSPEC_VSTRUCTDUMMY)]
+  "TARGET_NEON || TARGET_HAVE_MVE"
+{
+  if (TARGET_NEON)
+emit_insn (gen_neon_vld4 (operands[0], operands[1]));
+  else
+emit_insn (gen_mve_vld4q (operands[0], operands[1]));
+  DONE;
+})
+
+(define_expand "vec_store_lanesxi"
+  [(match_operand:XI 0 "neon_struct_operand")
+   (match_operand:XI 1 "s_register_operand")
+   (unspec:VQ2 [(const_int 0)] UNSPEC_VSTRUCTDUMMY)]
+  "TARGET_NEON || TARGET_HAVE_MVE"
+{
+  if (TARGET_NEON)
+emit_insn (gen_neon_vst4 (operands[0], operands[1]));
+  else
+emit_insn (gen_mve_vst4q (operands[0], operands[1]));
+  DONE;
+})
diff --git a/gcc/testsuite/gcc.target/arm/simd/mve-vld4.c 
b/gcc/testsuite/gcc.target/arm/simd/mve-vld4.c
new file mode 100644
index 000..ce3e755
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/simd/mve-vld4.c
@@ -0,0 +1,140 @@
+/* { dg-do assemble } */
+/* { dg-require-effective-target arm_v8_1m_mve_fp_ok } */
+/* { dg-add-options arm_v8_1m_mve_fp } */
+/* { dg-additional-options "-O3" } */
+
+#include 
+
+#define M00 100
+#define M10 216
+#define M20 23
+#define M30 237
+#define M01 1322
+#define M11 13
+#define M21 27271
+#define M31 2280
+#define M02 74
+#define M12 191
+#define M22 500
+#define M32 111
+#define M03 134
+#define M13 117
+#define M23 11
+#define M33 771
+
+#define N 128
+
+/* Integer tests.  */
+#define FUNC(SIGN, TYPE, BITS) \
+  void foo_##SIGN##BITS##x (TYPE##BITS##_t *__restrict__ pInput,   \
+   TYPE##BITS##_t *__restrict__ pOutput)   \
+  {\
+unsigned int i;\
+TYPE##BITS##_t  a, b, c, d;
\
+   \
+for (i = 0; i < N / BITS; i++)  \
+  {
\
+   a = *pInput++;  \
+   b = *pInput++;  \
+   c = *pInput++;  \
+   d = *pInput++;  \
+   

Re: [PATCH 7/9] arm: Auto-vectorization for MVE: add __fp16 support to VCMP

[Andre Vieira (lists) via Gcc-patches]

It would be good to also add tests for NEON as you also enable auto-vec 
for it. I checked and I do think the necessary 'neon_vc' patterns exist 
for 'VH', so we should be OK there.


On 30/04/2021 15:09, Christophe Lyon via Gcc-patches wrote:

This patch adds __fp16 support to the previous patch that added vcmp
support with MVE. For this we update existing expanders to use VDQWH
iterator, and add a new expander vcond.  In the
process we need to create suitable iterators, and update v_cmp_result
as needed.

2021-04-26  Christophe Lyon  

gcc/
* config/arm/iterators.md (V16): New iterator.
(VH_cvtto): New iterator.
(v_cmp_result): Added V4HF and V8HF support.
* config/arm/vec-common.md (vec_cmp): Use VDQWH.
(vcond): Likewise.
(vcond_mask_): Likewise.
(vcond): New expander.

gcc/testsuite/
* gcc.target/arm/simd/mve-compare-3.c: New test with GCC vectors.
* gcc.target/arm/simd/mve-vcmp-f16.c: New test for
auto-vectorization.
---
  gcc/config/arm/iterators.md   |  6 
  gcc/config/arm/vec-common.md  | 40 ---
  gcc/testsuite/gcc.target/arm/simd/mve-compare-3.c | 38 +
  gcc/testsuite/gcc.target/arm/simd/mve-vcmp-f16.c  | 30 +
  4 files changed, 102 insertions(+), 12 deletions(-)
  create mode 100644 gcc/testsuite/gcc.target/arm/simd/mve-compare-3.c
  create mode 100644 gcc/testsuite/gcc.target/arm/simd/mve-vcmp-f16.c

diff --git a/gcc/config/arm/iterators.md b/gcc/config/arm/iterators.md
index a128465..3042baf 100644
--- a/gcc/config/arm/iterators.md
+++ b/gcc/config/arm/iterators.md
@@ -231,6 +231,9 @@ (define_mode_iterator VU [V16QI V8HI V4SI])
  ;; Vector modes for 16-bit floating-point support.
  (define_mode_iterator VH [V8HF V4HF])
  
+;; Modes with 16-bit elements only.

+(define_mode_iterator V16 [V4HI V4HF V8HI V8HF])
+
  ;; 16-bit floating-point vector modes suitable for moving (includes BFmode).
  (define_mode_iterator VHFBF [V8HF V4HF V4BF V8BF])
  
@@ -571,6 +574,8 @@ (define_mode_attr V_cvtto [(V2SI "v2sf") (V2SF "v2si")

  ;; (Opposite) mode to convert to/from for vector-half mode conversions.
  (define_mode_attr VH_CVTTO [(V4HI "V4HF") (V4HF "V4HI")
(V8HI "V8HF") (V8HF "V8HI")])
+(define_mode_attr VH_cvtto [(V4HI "v4hf") (V4HF "v4hi")
+   (V8HI "v8hf") (V8HF "v8hi")])
  
  ;; Define element mode for each vector mode.

  (define_mode_attr V_elem [(V8QI "QI") (V16QI "QI")
@@ -720,6 +725,7 @@ (define_mode_attr V_cmp_result [(V8QI "V8QI") (V16QI 
"V16QI")
  (define_mode_attr v_cmp_result [(V8QI "v8qi") (V16QI "v16qi")
(V4HI "v4hi") (V8HI  "v8hi")
(V2SI "v2si") (V4SI  "v4si")
+   (V4HF "v4hi") (V8HF  "v8hi")
(DI   "di")   (V2DI  "v2di")
(V2SF "v2si") (V4SF  "v4si")])
  
diff --git a/gcc/config/arm/vec-common.md b/gcc/config/arm/vec-common.md

index 034b48b..3fd341c 100644
--- a/gcc/config/arm/vec-common.md
+++ b/gcc/config/arm/vec-common.md
@@ -366,8 +366,8 @@ (define_expand "vlshr3"
  (define_expand "vec_cmp"
[(set (match_operand: 0 "s_register_operand")
(match_operator: 1 "comparison_operator"
- [(match_operand:VDQW 2 "s_register_operand")
-  (match_operand:VDQW 3 "reg_or_zero_operand")]))]
+ [(match_operand:VDQWH 2 "s_register_operand")
+  (match_operand:VDQWH 3 "reg_or_zero_operand")]))]
"ARM_HAVE__ARITH
 && !TARGET_REALLY_IWMMXT
 && (! || flag_unsafe_math_optimizations)"
@@ -399,13 +399,13 @@ (define_expand "vec_cmpu"
  ;; element-wise.
  
  (define_expand "vcond"

-  [(set (match_operand:VDQW 0 "s_register_operand")
-   (if_then_else:VDQW
+  [(set (match_operand:VDQWH 0 "s_register_operand")
+   (if_then_else:VDQWH
  (match_operator 3 "comparison_operator"
-   [(match_operand:VDQW 4 "s_register_operand")
-(match_operand:VDQW 5 "reg_or_zero_operand")])
- (match_operand:VDQW 1 "s_register_operand")
- (match_operand:VDQW 2 "s_register_operand")))]
+   [(match_operand:VDQWH 4 "s_register_operand")
+(match_operand:VDQWH 5 "reg_or_zero_operand")])
+ (match_operand:VDQWH 1 "s_register_operand")
+ (match_operand:VDQWH 2 "s_register_operand")))]
"ARM_HAVE__ARITH
 && !TARGET_REALLY_IWMMXT
 && (! || flag_unsafe_math_optimizations)"
@@ -430,6 +430,22 @@ (define_expand "vcond"
DONE;
  })
  
+(define_expand "vcond"

+  [(set (match_operand: 0 "s_register_operand")
+   (if_then_else:
+ (match_operator 3 "comparison_operator"
+   [(match_operand:V16 4 "s_register_operand")
+(match_operand:V16 5 "reg_or_zero_operand")])
+ (match_operand: 1 "s_register_operand")
+ (match_operand: 2 "s_register_operand")))]
+  

Re: [PATCH 6/9] arm: Auto-vectorization for MVE: vcmp

[Andre Vieira (lists) via Gcc-patches]

Hi Christophe,

On 30/04/2021 15:09, Christophe Lyon via Gcc-patches wrote:

Since MVE has a different set of vector comparison operators from
Neon, we have to update the expansion to take into account the new
ones, for instance 'NE' for which MVE does not require to use 'EQ'
with the inverted condition.

Conversely, Neon supports comparisons with #0, MVE does not.

For:
typedef long int vs32 __attribute__((vector_size(16)));
vs32 cmp_eq_vs32_reg (vs32 a, vs32 b) { return a == b; }

we now generate:
cmp_eq_vs32_reg:
vldr.64 d4, .L123   @ 8 [c=8 l=4]  *mve_movv4si/8
vldr.64 d5, .L123+8
vldr.64 d6, .L123+16@ 9 [c=8 l=4]  *mve_movv4si/8
vldr.64 d7, .L123+24
vcmp.i32  eq, q0, q1@ 7 [c=16 l=4]  mve_vcmpeqq_v4si
vpsel q0, q3, q2@ 15[c=8 l=4]  mve_vpselq_sv4si
bx  lr  @ 26[c=8 l=4]  *thumb2_return
.L124:
.align  3
.L123:
.word   0
.word   0
.word   0
.word   0
.word   1
.word   1
.word   1
.word   1

For some reason emit_move_insn (zero, CONST0_RTX (cmp_mode)) produces
a pair of vldr instead of vmov.i32, qX, #0

I think ideally we would even want:
vpte  eq, q0, q1
vmovt.i32 q0, #0
vmove.i32 q0, #1

But we don't have a way to generate VPT blocks with multiple 
instructions yet unfortunately so I guess VPSEL will have to do for now.




2021-03-01  Christophe Lyon  

gcc/
* config/arm/arm-protos.h (arm_expand_vector_compare): Update
prototype.
* config/arm/arm.c (arm_expand_vector_compare): Add support for
MVE.
(arm_expand_vcond): Likewise.
* config/arm/iterators.md (supf): Remove VCMPNEQ_S, VCMPEQQ_S,
VCMPEQQ_N_S, VCMPNEQ_N_S.
(VCMPNEQ, VCMPEQQ, VCMPEQQ_N, VCMPNEQ_N): Remove.
* config/arm/mve.md (@mve_vcmpq_): Add '@' prefix.
(@mve_vcmpq_f): Likewise.
(@mve_vcmpq_n_f): Likewise.
(@mve_vpselq_): Likewise.
(@mve_vpselq_f"): Likewise.
* config/arm/neon.md (vec_cmp): Likewise.
(vcond): Likewise.
(vcond): Likewise.
(vcondu): Likewise.
(vcond_mask_): Likewise.
* config/arm/unspecs.md (VCMPNEQ_U, VCMPNEQ_S, VCMPEQQ_S)
(VCMPEQQ_N_S, VCMPNEQ_N_S, VCMPEQQ_U, CMPEQQ_N_U, VCMPNEQ_N_U)
(VCMPGEQ_N_S, VCMPGEQ_S, VCMPGTQ_N_S, VCMPGTQ_S, VCMPLEQ_N_S)
(VCMPLEQ_S, VCMPLTQ_N_S, VCMPLTQ_S, VCMPCSQ_N_U, VCMPCSQ_U)
(VCMPHIQ_N_U, VCMPHIQ_U): Remove.
* config/arm/vec-common.md (vec_cmp): Likewise.
(vcond): Likewise.
(vcond): Likewise.
(vcondu): Likewise.
(vcond_mask_): Likewise.

gcc/testsuite
* gcc.target/arm/simd/mve-compare-1.c: New test with GCC vectors.
* gcc.target/arm/simd/mve-compare-2.c: New test with GCC vectors.
* gcc.target/arm/simd/mve-compare-scalar-1.c: New test with GCC
vectors.
* gcc.target/arm/simd/mve-vcmp-f32.c: New test for
auto-vectorization.
* gcc.target/arm/simd/mve-vcmp.c: New test for auto-vectorization.

add gcc/testsuite/gcc.target/arm/simd/mve-compare-scalar-1.c
---
  gcc/config/arm/arm-protos.h|   2 +-
  gcc/config/arm/arm.c   | 211 -
  gcc/config/arm/iterators.md|   9 +-
  gcc/config/arm/mve.md  |  10 +-
  gcc/config/arm/neon.md |  87 -
  gcc/config/arm/unspecs.md  |  20 --
  gcc/config/arm/vec-common.md   | 107 +++
  gcc/testsuite/gcc.target/arm/simd/mve-compare-1.c  |  80 
  gcc/testsuite/gcc.target/arm/simd/mve-compare-2.c  |  38 
  .../gcc.target/arm/simd/mve-compare-scalar-1.c |  69 +++
  gcc/testsuite/gcc.target/arm/simd/mve-vcmp-f32.c   |  30 +++
  gcc/testsuite/gcc.target/arm/simd/mve-vcmp.c   |  50 +
  12 files changed, 547 insertions(+), 166 deletions(-)
  create mode 100644 gcc/testsuite/gcc.target/arm/simd/mve-compare-1.c
  create mode 100644 gcc/testsuite/gcc.target/arm/simd/mve-compare-2.c
  create mode 100644 gcc/testsuite/gcc.target/arm/simd/mve-compare-scalar-1.c
  create mode 100644 gcc/testsuite/gcc.target/arm/simd/mve-vcmp-f32.c
  create mode 100644 gcc/testsuite/gcc.target/arm/simd/mve-vcmp.c

diff --git a/gcc/config/arm/arm-protos.h b/gcc/config/arm/arm-protos.h
index 2521541..ffccaa7 100644
--- a/gcc/config/arm/arm-protos.h
+++ b/gcc/config/arm/arm-protos.h
@@ -373,7 +373,7 @@ extern void arm_emit_coreregs_64bit_shift (enum rtx_code, 
rtx, rtx, rtx, rtx,
  extern bool arm_fusion_enabled_p (tune_params::fuse_ops);
  extern bool arm_valid_symbolic_address_p (rtx);
  extern bool arm_validize_comparison (rtx *, rtx *, rtx *);
-extern bool arm_expand_vector_compare (rtx, rtx_code, rtx, rtx, bool);
+extern bool arm_expand_vector_compare (rtx, rtx_code, rtx, rtx, bool, bool);
  #endif /* 

[committed] libstdc++: Do not use deduced return type for std::visit [PR 100384]

[Jonathan Wakely via Gcc-patches]

This avoids errors outside the immediate context when std::visit is an
overload candidate because of ADL, but not actually viable.

The solution is to give std::visit a non-deduced return type. New
helpers are introduced for that, and existing ones refactored slightly.

libstdc++-v3/ChangeLog:

PR libstdc++/100384
* include/std/variant (__get_t): New alias template yielding the
return type of std::get on a variant.
(__visit_result_t): New alias template yielding the result of
std::visit.
(__same_types): Move into namespace __detail::__variant.
(__check_visitor_results): Likewise. Use __invoke_result_t and
__get_t.
(__check_visitor_result): Remove.
(visit): Use __visit_result_t for return type.
* testsuite/20_util/variant/100384.cc: New test.

Tested powerpc64le-linux. Committed to trunk.

This should be backported too, as the std::visit on the branches has
this bug.

commit af5b2b911dd80ae9cc87404b7e7ab807cf6655d4
Author: Jonathan Wakely 
Date:   Tue May 4 12:16:46 2021

libstdc++: Do not use deduced return type for std::visit [PR 100384]

This avoids errors outside the immediate context when std::visit is an
overload candidate because of ADL, but not actually viable.

The solution is to give std::visit a non-deduced return type. New
helpers are introduced for that, and existing ones refactored slightly.

libstdc++-v3/ChangeLog:

PR libstdc++/100384
* include/std/variant (__get_t): New alias template yielding the
return type of std::get on a variant.
(__visit_result_t): New alias template yielding the result of
std::visit.
(__same_types): Move into namespace __detail::__variant.
(__check_visitor_results): Likewise. Use __invoke_result_t and
__get_t.
(__check_visitor_result): Remove.
(visit): Use __visit_result_t for return type.
* testsuite/20_util/variant/100384.cc: New test.

diff --git a/libstdc++-v3/include/std/variant b/libstdc++-v3/include/std/variant
index 1ef9b9725e2..9b2bc440841 100644
--- a/libstdc++-v3/include/std/variant
+++ b/libstdc++-v3/include/std/variant
@@ -1063,6 +1063,25 @@ namespace __variant
  std::index_sequence<__indices...>>
 : _Base_dedup<__indices, __poison_hash>>... { };
 
+  template
+using __get_t = decltype(std::get<_Np>(std::declval<_Variant>()));
+
+  // Return type of std::visit.
+  template
+using __visit_result_t
+  = invoke_result_t<_Visitor, __get_t<0, _Variants>...>;
+
+  template
+constexpr inline bool __same_types = (is_same_v<_Tp, _Types> && ...);
+
+  template 
+constexpr bool __check_visitor_results(std::index_sequence<_Idxs...>)
+{
+  return __same_types<
+   invoke_result_t<_Visitor, __get_t<_Idxs, _Variant>>...
+   >;
+}
+
 } // namespace __variant
 } // namespace __detail
 
@@ -1248,7 +1267,8 @@ namespace __variant
 #endif
 
   template
-constexpr decltype(auto) visit(_Visitor&&, _Variants&&...);
+constexpr __detail::__variant::__visit_result_t<_Visitor, _Variants...>
+visit(_Visitor&&, _Variants&&...);
 
   template
 inline enable_if_t<(is_move_constructible_v<_Types> && ...)
@@ -1715,41 +1735,21 @@ namespace __variant
   std::forward<_Variants>(__variants)...);
 }
 
-  template
- constexpr inline bool __same_types = (is_same_v<_Tp, _Types> && ...);
-
-  template 
-decltype(auto)
-__check_visitor_result(_Visitor&& __vis, _Variant&& __variant)
-{
-  return std::__invoke(std::forward<_Visitor>(__vis),
-  std::get<_Idx>(std::forward<_Variant>(__variant)));
-}
-
-  template 
-constexpr bool __check_visitor_results(std::index_sequence<_Idxs...>)
-{
-  return __same_types(
-   std::declval<_Visitor>(),
-   std::declval<_Variant>()))...>;
-}
-
-
   template
-constexpr decltype(auto)
+constexpr __detail::__variant::__visit_result_t<_Visitor, _Variants...>
 visit(_Visitor&& __visitor, _Variants&&... __variants)
 {
   if ((__variants.valueless_by_exception() || ...))
__throw_bad_variant_access("std::visit: variant is valueless");
 
-  using _Result_type = std::invoke_result_t<_Visitor,
-   decltype(std::get<0>(std::declval<_Variants>()))...>;
+  using _Result_type
+   = __detail::__variant::__visit_result_t<_Visitor, _Variants...>;
 
   using _Tag = __detail::__variant::__deduce_visit_result<_Result_type>;
 
   if constexpr (sizeof...(_Variants) == 1)
{
- constexpr bool __visit_rettypes_match =
+ constexpr bool __visit_rettypes_match = __detail::__variant::
__check_visitor_results<_Visitor, _Variants...>(
  std::make_index_sequence<
std::variant_size...>::value>());
diff --git 

[PATCH] Add gnu::diagnose_as attribute

[Matthias Kretz]

From: Matthias Kretz 

This attribute overrides the diagnostics output string for the entity it
appertains to. The motivation is to improve QoI for library TS
implementations, where diagnostics have a very bad signal-to-noise ratio
due to the long namespaces involved.

On Tuesday, 27 April 2021 11:46:48 CEST Jonathan Wakely wrote:
> I think it's a great idea and would like to use it for all the TS
> implementations where there is some inline namespace that the user
> doesn't care about. std::experimental::fundamentals_v1:: would be much
> better as just std::experimental::, or something like std::[LFTS]::.

With the attribute, it is possible to solve PR89370 and make
std::__cxx11::basic_string<_CharT, _Traits, _Alloc> appear as
std::string in diagnostic output without extra hacks to recognize the
type.

gcc/ChangeLog:

PR c++/89370
* doc/extend.texi: Document the diagnose_as attribute.
* doc/invoke.texi: Document -fno-diagnostics-use-aliases.

gcc/c-family/ChangeLog:

PR c++/89370
* c.opt (fdiagnostics-use-aliases): New diagnostics flag.

gcc/cp/ChangeLog:

PR c++/89370
* error.c (dump_scope): When printing the name of a namespace,
look for the diagnose_as attribute. If found, print the
associated string instead of calling dump_decl.
(dump_decl_name_or_diagnose_as): New function to replace
dump_decl (pp, DECL_NAME(t), flags) and inspect the tree for the
diagnose_as attribute before printing the DECL_NAME.
(dump_aggr_type): If the type has a diagnose_as attribute, print
the associated string instead of printing the original type
name.
(dump_simple_decl): Call dump_decl_name_or_diagnose_as instead
of dump_decl.
(dump_decl): Ditto.
(lang_decl_name): Ditto.
(dump_function_decl): Ensure complete replacement of the class
template diagnostics if a diagnose_as attribute is present.
(dump_function_name): Replace the function diagnostic output if
the diagnose_as attribute is set.
* name-lookup.c (handle_namespace_attrs): Handle the diagnose_as
attribute. Ensure exactly one string argument. Ensure previous
diagnose_as attributes used the same name.
* tree.c (cxx_attribute_table): Add diagnose_as attribute to the
table.
(check_diagnose_as_redeclaration): New function; copied and
adjusted from check_abi_tag_redeclaration.
(handle_diagnose_as_attribute): New function; copied and
adjusted from handle_abi_tag_attribute. If the given *node is a
TYPE_DECL and the TREE_TYPE is an implicit class template
instantiation, call decl_attributes to add the diagnose_as
attribute to the TREE_TYPE.
---
 gcc/c-family/c.opt   |   4 ++
 gcc/cp/error.c   |  85 ---
 gcc/cp/name-lookup.c |  27 ++
 gcc/cp/tree.c| 117 +++
 gcc/doc/extend.texi  |  37 ++
 gcc/doc/invoke.texi  |   9 +++-
 6 files changed, 270 insertions(+), 9 deletions(-)


--
──
 Dr. Matthias Kretz   https://mattkretz.github.io
 GSI Helmholtz Centre for Heavy Ion Research   https://gsi.de
 std::experimental::simd  https://github.com/VcDevel/std-simd
──diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 3f8b72cdc00..0cf01c6dba4 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -1582,6 +1582,10 @@ fdiagnostics-show-template-tree
 C++ ObjC++ Var(flag_diagnostics_show_template_tree) Init(0)
 Print hierarchical comparisons when template types are mismatched.
 
+fdiagnostics-use-aliases
+C++ Var(flag_diagnostics_use_aliases) Init(1)
+Replace identifiers or scope names in diagnostics as defined by the diagnose_as attribute.
+
 fdirectives-only
 C ObjC C++ ObjC++
 Preprocess directives only.
diff --git a/gcc/cp/error.c b/gcc/cp/error.c
index c88d1749a0f..10b547afaa7 100644
--- a/gcc/cp/error.c
+++ b/gcc/cp/error.c
@@ -35,6 +35,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "internal-fn.h"
 #include "gcc-rich-location.h"
 #include "cp-name-hint.h"
+#include "attribs.h"
 
 #define pp_separate_with_comma(PP) pp_cxx_separate_with (PP, ',')
 #define pp_separate_with_semicolon(PP) pp_cxx_separate_with (PP, ';')
@@ -66,6 +67,7 @@ static void dump_alias_template_specialization (cxx_pretty_printer *, tree, int)
 static void dump_type (cxx_pretty_printer *, tree, int);
 static void dump_typename (cxx_pretty_printer *, tree, int);
 static void dump_simple_decl (cxx_pretty_printer *, tree, tree, int);
+static void dump_decl_name_or_diagnose_as (cxx_pretty_printer *, tree, int);
 static void dump_decl (cxx_pretty_printer *, tree, int);
 static void dump_template_decl (cxx_pretty_printer *, tree, int);

Re: [libstdc++] Inconsistent detection of __int128

[Jonathan Wakely via Gcc-patches]

On 30/04/21 16:24 -0400, David Edelsohn via Libstdc++ wrote:

On Fri, Jan 8, 2021 at 11:10 AM Jonathan Wakely  wrote:


On 03/01/21 22:26 -0500, David Edelsohn via Libstdc++ wrote:
>On Sun, Jan 3, 2021 at 9:45 PM Jonathan Wakely  wrote:
>>
>> On Mon, 4 Jan 2021, 00:44 David Edelsohn via Libstdc++, 
 wrote:
>>>
>>> Or is there some other reason that _GLIBCXX_USE_INT128 and
>>> __SIZEOF_INT128__ are used in different contexts?
>>
>> Yes.
>>
>> I'll reply when I'm back from taking some time off. Probably Wednesday.
>
>If the uses of _GLIBCXX_USE_INT128 in libstdc++ headers specifically
>are checking if __int128 type is different than "long" and "long
>long", as opposed to the availability of the __int128, can c++config.h

Yes, the test is not just "is __int128 a valid type?" but "should we
use __int128 as a larger integer type?"

We used to use it more widely, but many places that use __int128
conditionally now check __GLIBCXX_INT_N_0 instead, because that is
defined when __int128 is available and we're not compiling in a
"strict ansi" dialect.

Of the two remaining uses of _GLIBCXX_USE_INT128 I think one is wrong
and should test __SIZEOF__INT128__ directly. We specifically do want
to use unsigned __int128 in __to_chars_unsigned_type even if it's the
same as a standard type.

So that leaves one remaining use, and I think that should do as you
suggest here ...

>define _GLIBCXX_USE_INT128 by comparing __SIZEOF_INT128__ to
>__SIZEOF_LONG_LONG__ and __SIZEOF_LONG__ instead of the libstdc++
>configure template typename test?

Yes, that seems fine. But since we only need it in one place, let's
just do that test in that one place. It makes the purpose of the test
more explicit, and so you don't need to look up what
_GLIBCXX_USE_INT128 means and when it's true.

Does the attached patch work for you?


Hi, Jonathan

Thanks for pushing the INT64_T patch.

I tested your revised patch in January and it works perfectly.

Could you push your INT128 patch to trunk when you have a moment?

Thanks, David


I've pushed the attached to trunk after testing on powerpc-aix and
x86_64-linux.

Contrary to what I said in January, I think both sues of
_GLIBCXX_USE_INT128 do want to only use __int128 if it's larger than
long long. For __to_chars_unsigned_type there's no point trying to use
unsigned __int128 if it's the same size as unsigned long long, because
we'd already have chosen unsigned long long.



commit ad0a3be4df5eecc79075d899fd79179d0f61270e
Author: Jonathan Wakely 
Date:   Tue May 4 12:07:09 2021

libstdc++: Remove _GLIBCXX_USE_INT128 autoconf macro

We don't need to decide whether to use __int128 when running configure,
we can do so at compilation time by seeing if __SIZEOF_INT128__ is
defined and if it's greater than __SIZEOF_LONG_LONG__.

This removes another unnecessary architecture-specific config macro in
, so the same header can work for 32-bit or 64-bit
compilation on AIX.

libstdc++-v3/ChangeLog:

* acinclude.m4 (GLIBCXX_ENABLE_INT128_FLOAT128): Remove
checks for __int128 and rename to GLIBCXX_ENABLE_FLOAT128.
* config.h.in: Regenerate.
* configure: Regenerate.
* configure.ac: Adjust to use GLIBCXX_ENABLE_FLOAT128.
* include/bits/random.h (_Select_uint_least_t):
Use __SIZEOF_INT128__ to decide whether to use __int128.
* include/std/charconv (__to_chars_unsigned_type): Likewise.

diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index 7b78e148fbd..94897a654c9 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -3049,15 +3049,14 @@ EOF
 ])
 
 dnl
-dnl Check for GNU 128-bit integer and floating point types.
+dnl Check for GNU 128-bit floating point type.
 dnl
-dnl Note: also checks that the types aren't standard types.
+dnl Note: also checks that the type isn't a standard types.
 dnl
 dnl Defines:
-dnl  _GLIBCXX_USE_INT128
 dnl  ENABLE_FLOAT128
 dnl
-AC_DEFUN([GLIBCXX_ENABLE_INT128_FLOAT128], [
+AC_DEFUN([GLIBCXX_ENABLE_FLOAT128], [
 
   AC_LANG_SAVE
   AC_LANG_CPLUSPLUS
@@ -3065,34 +3064,7 @@ AC_DEFUN([GLIBCXX_ENABLE_INT128_FLOAT128], [
   # Fake what AC_TRY_COMPILE does, without linking as this is
   # unnecessary for this test.
 
-cat > conftest.$ac_ext << EOF
-[#]line __oline__ "configure"
-template
-  struct same
-  { typedef T2 type; };
-
-template
-  struct same;
-
-int main()
-{
-  typename same::typei1;
-  typename same::type   i2;
-}
-EOF
-
-AC_MSG_CHECKING([for __int128])
-if AC_TRY_EVAL(ac_compile); then
-  AC_DEFINE(_GLIBCXX_USE_INT128, 1,
-  [Define if __int128 is supported on this host.])
-  enable_int128=yes
-else
-  enable_int128=no
-fi
-AC_MSG_RESULT($enable_int128)
-rm -f conftest*
-
-cat > conftest.$ac_ext << EOF
+  cat > conftest.$ac_ext << EOF
 [#]line __oline__ "configure"
 template
   struct same
diff --git a/libstdc++-v3/configure.ac 

[RFC v2] bpf.2: Use standard types and attributes

[Alejandro Colomar via Gcc-patches]

Some manual pages are already using C99 syntax for integral
types 'uint32_t', but some aren't.  There are some using kernel
syntax '__u32'.  Fix those.

Some pages also document attributes, using GNU syntax
'__attribute__((xxx))'.  Update those to use the shorter and more
portable C11 keywords such as 'alignas()' when possible, and C2x
syntax '[[gnu::xxx]]' elsewhere, which hasn't been standardized
yet, but is already implemented in GCC, and available through
either --std=c2x or any of the --std=gnu... options.

The standard isn't very clear on how to use alignas() or
[[]]-style attributes, so the following link is useful in the case
of 'alignas()' and '[[gnu::aligned()]]':


Signed-off-by: Alejandro Colomar 
Cc: LKML 
Cc: glibc 
Cc: GCC 
Cc: Alexei Starovoitov 
Cc: bpf 
Cc: David Laight 
Cc: Zack Weinberg 
Cc: Joseph Myers 
---
 man2/bpf.2 | 49 -
 1 file changed, 24 insertions(+), 25 deletions(-)

diff --git a/man2/bpf.2 b/man2/bpf.2
index 6e1ffa198..04b8fbcef 100644
--- a/man2/bpf.2
+++ b/man2/bpf.2
@@ -186,41 +186,40 @@ commands:
 .PP
 .in +4n
 .EX
-union bpf_attr {
+union [[gnu::aligned(8)]] bpf_attr {
 struct {/* Used by BPF_MAP_CREATE */
-__u32 map_type;
-__u32 key_size;/* size of key in bytes */
-__u32 value_size;  /* size of value in bytes */
-__u32 max_entries; /* maximum number of entries
-  in a map */
+uint32_tmap_type;
+uint32_tkey_size;/* size of key in bytes */
+uint32_tvalue_size;  /* size of value in bytes */
+uint32_tmax_entries; /* maximum number of entries
+in a map */
 };
 
-struct {/* Used by BPF_MAP_*_ELEM and BPF_MAP_GET_NEXT_KEY
-   commands */
-__u32 map_fd;
-__aligned_u64 key;
+struct {/* Used by BPF_MAP_*_ELEM and BPF_MAP_GET_NEXT_KEY commands */
+uint32_tmap_fd;
+uint64_t alignas(8) key;
 union {
-__aligned_u64 value;
-__aligned_u64 next_key;
+uint64_t alignas(8) value;
+uint64_t alignas(8) next_key;
 };
-__u64 flags;
+uint64_tflags;
 };
 
 struct {/* Used by BPF_PROG_LOAD */
-__u32 prog_type;
-__u32 insn_cnt;
-__aligned_u64 insns;  /* \(aqconst struct bpf_insn *\(aq */
-__aligned_u64 license;/* \(aqconst char *\(aq */
-__u32 log_level;  /* verbosity level of verifier */
-__u32 log_size;   /* size of user buffer */
-__aligned_u64 log_buf;/* user supplied \(aqchar *\(aq
- buffer */
-__u32 kern_version;
-  /* checked when prog_type=kprobe
- (since Linux 4.1) */
+uint32_tprog_type;
+uint32_tinsn_cnt;
+uint64_t alignas(8) insns; /* \(aqconst struct bpf_insn *\(aq */
+uint64_t alignas(8) license;   /* \(aqconst char *\(aq */
+uint32_tlog_level; /* verbosity level of verifier */
+uint32_tlog_size;  /* size of user buffer */
+uint64_t alignas(8) log_buf;   /* user supplied \(aqchar *\(aq
+  buffer */
+uint32_tkern_version;
+   /* checked when prog_type=kprobe
+  (since Linux 4.1) */
 .\" commit 2541517c32be2531e0da59dfd7efc1ce844644f5
 };
-} __attribute__((aligned(8)));
+};
 .EE
 .in
 .\"
-- 
2.31.1

Re: [PATCH] Avoid DSE/DCE of pure call that throws

[Richard Biener]

On Tue, 4 May 2021, Eric Botcazou wrote:

> > Do you have extra fixes in your tree or does -fnon-call-exceptions
> > somehow magically paper over the issue?
> 
> This optimization is valid in Ada for pure functions.  RM 10.2.1(18/3) says:
> "If a library unit is declared pure, then the implementation is permitted to 
> omit a call on a library-level subprogram of the library unit if the results 
> are not needed after the call.(...)[This permission applies even if the 
> subprogram produces other side effects when called.]".
> 
> > I suppose if the C or C++ frontends like to have pure/const attributed
> > functions not throw they could mark functions accordingly themselves.
> > 
> > Which also means, the Ada functions are DECL_PURE_P but not 'pure'
> > according to the extend.texi documentation of the user-visible
> > attribute?  That said, I think if my C++ testcase is valid then we
> > should amend this documentation (or if not then as well, to not
> > re-iterate this every N years).  Do you agree?
> 
> Yes, the documentation was written without considering other languages with 
> exception handling, but it's originally an extension of the C language and 
> documented in the manual of the C compiler, so that's not very surprising.
> 
> Pure Ada functions are "const" in the GNU C sense if all their parameters are 
> passed by copy and "pure" in the GNU  C sense if their parameters not passed 
> by value (i.e. by reference) are In parameters; in all the other cases, pure 
> Ada functions are neither "const" nor "pure" in the GNU C sense.
> 
> I think that we need to add an explicit sentence about exception handling to 
> the declaration of DECL_PURE_P:
> 
> /* Nonzero in a FUNCTION_DECL means this function should be treated
>as "pure" function (like const function, but may read global memory).  */
> #define DECL_PURE_P(NODE) (FUNCTION_DECL_CHECK (NODE)>function_decl.pure_flag)
> 
> Maybe: "Note that being pure or const for a function is orthogonal to being 
> no-throw, i.e. it is valid to have DECL_PURE_P set and TREE_NOTHROW cleared".

Good idea.

So the reason it doesn't "break" with Ada is because with Ada we are
allowed to elide the EH.

I'm testing the revised patch below which also prepares for a
PR100409 fix in the C++ FE (the DCE hunk).  I hope any Ada fallout
is catched by the testsuite.

Better ideas for the expand_call / expand_call_stmt kludges appreciated.

Richard.


middle-end/100394 - avoid DSE/DCE of pure call that throws

There is -fdelete-dead-exceptions now and we're tracking
nothrow and const/pure bits separately and I do remember that
const or pure does _not_ imply nothrow.

Now, in the light of the PR100382 fix which added a
stmt_unremovable_because_of_non_call_eh_p guard to DSEs "DCE"
I wondered how -fdelete-dead-exceptions applies to calls and
whether stmt_unremovable_because_of_non_call_eh_p doing

  return (fun->can_throw_non_call_exceptions
  && !fun->can_delete_dead_exceptions
  && stmt_could_throw_p (fun, stmt));

really should conditionalize itself on
fun->can_throw_non_call_exceptions.  In fact DCE happily elides
pure function calls that throw without a LHS (probably a
consistency bug).  The following testcase shows this:

int x, y;
int __attribute__((pure,noinline)) foo () { if (x) throw 1; return y; }

int main()
{
  int a[2];
  x = 1;
  try {
int res = foo ();
a[0] = res;
  } catch (...) {
  return 0;
  }
  return 1;
}

note that if you wrap foo () into another noinline
wrap_foo () { foo (); return 1; } function then we need to make
sure to not DCE this call either even though it only throws
externally.

2021-05-03  Richard Biener  

PR middle-end/100394
* calls.c (expand_call): Preserve possibly throwing calls.
* cfgexpand.c (expand_call_stmt): When a call can throw signal
RTL expansion there are side-effects.
* tree-ssa-dce.c (mark_stmt_if_obviously_necessary): Simplify,
mark all possibly throwing stmts necessary unless we can elide
dead EH.
* tree-ssa-dse.c (pass_dse::execute): Preserve exceptions unless
-fdelete-dead-exceptions.
* tree.h (DECL_PURE_P): Add note about exceptions.

* g++.dg/torture/pr100382.C: New testcase.
---
 gcc/calls.c |  1 +
 gcc/cfgexpand.c |  5 -
 gcc/testsuite/g++.dg/torture/pr100382.C | 24 
 gcc/tree-ssa-dce.c  | 29 +++--
 gcc/tree-ssa-dse.c  |  3 ++-
 gcc/tree.h  |  5 -
 6 files changed, 43 insertions(+), 24 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/torture/pr100382.C

diff --git a/gcc/calls.c b/gcc/calls.c
index 883d08ba5f2..f3da1839dc5 100644
--- a/gcc/calls.c
+++ b/gcc/calls.c
@@ -3808,6 +3808,7 @@ expand_call (tree exp, rtx target, int ignore)
  side-effects.  */
   if ((flags & (ECF_CONST | ECF_PURE))
   && (!(flags & 

[PATCH] tree-optimization/100398 - avoid DSE of control flow stmt

[Richard Biener]

The following makes sure to preserve control altering stmts
when removing trivially dead stmts in DSE.

Boostrapped and tested on x86_64-unknown-linux-gnu, pushed.

2021-05-04  Richard Biener  

PR tree-optimization/100398
* tree-ssa-dse.c (pass_dse::execute): Preserve control
altering stmts.

* gcc.dg/torture/pr100398.c: New testcase.
---
 gcc/testsuite/gcc.dg/torture/pr100398.c | 13 +
 gcc/tree-ssa-dse.c  |  1 +
 2 files changed, 14 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/torture/pr100398.c

diff --git a/gcc/testsuite/gcc.dg/torture/pr100398.c 
b/gcc/testsuite/gcc.dg/torture/pr100398.c
new file mode 100644
index 000..41eaddee27e
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/torture/pr100398.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+
+int
+test5_limit (void)
+{
+  int addr;
+
+  asm goto ("" : "+r" (addr) : : : t_err);
+  return 0;
+
+ t_err:
+  return 1;
+}
diff --git a/gcc/tree-ssa-dse.c b/gcc/tree-ssa-dse.c
index dfa6d314727..d7cf7477028 100644
--- a/gcc/tree-ssa-dse.c
+++ b/gcc/tree-ssa-dse.c
@@ -1219,6 +1219,7 @@ pass_dse::execute (function *fun)
 dead SSA defs.  */
  if (has_zero_uses (DEF_FROM_PTR (def_p))
  && !gimple_has_side_effects (stmt)
+ && !is_ctrl_altering_stmt (stmt)
  && !stmt_unremovable_because_of_non_call_eh_p (cfun, stmt))
{
  if (dump_file && (dump_flags & TDF_DETAILS))
-- 
2.26.2

[PATCH] tree-optimization/100329 - avoid reassociating asm goto defs

[Richard Biener]

This avoids reassociating asm goto defs because we have no idea
on which outgoing edge to insert defs.

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

2021-05-04  Richard Biener  

PR tree-optimization/100329
* tree-ssa-reassoc.c (can_reassociate_p): Do not reassociate
asm goto defs.
(insert_stmt_after): Assert we're not running into asm goto.

* gcc.dg/torture/pr100329.c: New testcase.
---
 gcc/testsuite/gcc.dg/torture/pr100329.c | 16 
 gcc/tree-ssa-reassoc.c  | 10 ++
 2 files changed, 26 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/torture/pr100329.c

diff --git a/gcc/testsuite/gcc.dg/torture/pr100329.c 
b/gcc/testsuite/gcc.dg/torture/pr100329.c
new file mode 100644
index 000..b90700dd5f0
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/torture/pr100329.c
@@ -0,0 +1,16 @@
+/* { dg-do compile } */
+/* { dg-additional-options "--param tree-reassoc-width=2" } */
+
+unsigned int a0;
+
+unsigned int
+foo (unsigned int a1, unsigned int a2)
+{
+  unsigned int x;
+
+  asm goto ("" : "=r" (x) : : : lab);
+  a0 = x;
+
+ lab:
+  return x + a1 + a2 + 1;
+}
diff --git a/gcc/tree-ssa-reassoc.c b/gcc/tree-ssa-reassoc.c
index 8e2a4896d14..359367c9382 100644
--- a/gcc/tree-ssa-reassoc.c
+++ b/gcc/tree-ssa-reassoc.c
@@ -1446,6 +1446,10 @@ insert_stmt_after (gimple *stmt, gimple *insert_point)
   gsi_insert_after (, stmt, GSI_NEW_STMT);
   return;
 }
+  else if (gimple_code (insert_point) == GIMPLE_ASM)
+/* We have no idea where to insert - it depends on where the
+   uses will be placed.  */
+gcc_unreachable ();
   else
 /* We assume INSERT_POINT is a SSA_NAME_DEF_STMT of some SSA_NAME,
thus if it must end a basic block, it should be a call that can
@@ -5893,6 +5897,12 @@ can_reassociate_p (tree op)
   tree type = TREE_TYPE (op);
   if (TREE_CODE (op) == SSA_NAME && SSA_NAME_OCCURS_IN_ABNORMAL_PHI (op))
 return false;
+  /* Make sure asm goto outputs do not participate in reassociation since
+ we have no way to find an insertion place after asm goto.  */
+  if (TREE_CODE (op) == SSA_NAME
+  && gimple_code (SSA_NAME_DEF_STMT (op)) == GIMPLE_ASM
+  && gimple_asm_nlabels (as_a  (SSA_NAME_DEF_STMT (op))) != 0)
+return false;
   if ((ANY_INTEGRAL_TYPE_P (type) && TYPE_OVERFLOW_WRAPS (type))
   || NON_SAT_FIXED_POINT_TYPE_P (type)
   || (flag_associative_math && FLOAT_TYPE_P (type)))
-- 
2.26.2

Re: [Patch] OpenMP: Support complex/float in && and || reduction

[Jakub Jelinek via Gcc-patches]

On Tue, May 04, 2021 at 12:16:50PM +0200, Tobias Burnus wrote:
> Unless there are further comments, I intent to commit it after the lunch
> break.

Just further nits, sorry (but no need to retest):

> --- a/gcc/omp-low.c
> +++ b/gcc/omp-low.c
> @@ -6389,6 +6389,11 @@ lower_rec_input_clauses (tree clauses, gimple_seq 
> *ilist, gimple_seq *dlist,
> if (code == MINUS_EXPR)
>   code = PLUS_EXPR;
>  
> +   /* C/C++ permits FP/complex with || and &&.  */
> +   bool is_fp_and_or
> + = (((code == TRUTH_ANDIF_EXPR) || (code == TRUTH_ORIF_EXPR))

The ()s around code == TRUTH_*_EXPR are unnecessary.

> +&& (FLOAT_TYPE_P (TREE_TYPE (new_var))
> +|| (TREE_CODE (TREE_TYPE (new_var)) == 
> COMPLEX_TYPE)));

And if I count well, this is too long, so should have == on the next line
below TREE_CODE.  If it would fit, the ()s around the == would be
unnecessary too, the whole point of them is to make emacs happy (not an
emacs user myself though), which would otherwise misalign it.
Only needed if it needs a line split.
Without ()s, I think emacs likes to indent
foo ()
|| bar (..)
   == ...
as
foo ()
|| bar (..)
== ...
and the cure is
foo ()
|| (bar (..)
== ...)


> @@ -7397,13 +7429,32 @@ lower_reduction_clauses (tree clauses, gimple_seq 
> *stmt_seqp,
>if (code == MINUS_EXPR)
>  code = PLUS_EXPR;
>  
> +  /* C/C++ permits FP/complex with || and &&.  */
> +  bool is_fp_and_or = (((code == TRUTH_ANDIF_EXPR)
> + || (code == TRUTH_ORIF_EXPR))

See above.

Otherwise ok.

Jakub

Re: [Patch] OpenMP: Support complex/float in && and || reduction

[Tobias Burnus]

On 03.05.21 19:38, Jakub Jelinek wrote:

All the above ChangeLog lines are too long.

Fixed.

The above line is too long too, ...


I counted 80 characters  - but the line break is now required for: used
'(...)' around '... == ...').


+  if (is_fp_and_or)
+new_var2 = fold_build2_loc (
+ clause_loc, NE_EXPR,
+ integer_type_node, new_var,
+ build_zero_cst (TREE_TYPE (new_var)));

Formatting, would be nice to avoid the ( at the end of line, e.g.
  {
tree zero = build_zero_cst (TREE_TYPE (new_var));

I added now the zero plus

Please wrap the == into ()s.

Done.

Though ref should have the same type new_var (or at least a compatible type),
so I don't see the point of the && ... in there and of using two separate
if (is_fp_and_or) blocks.


I have now merged the two parts into a single block - with a single zero
as proposed.


For the testcases, would be nice to have one with _Complex int, though
perhaps separately from the ones you've included because while float
or _Complex double are standard, _Complex int is a GNU extension.


Done (reduction-4.c).

Unless there are further comments, I intent to commit it after the lunch
break.

Tobias

-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München 
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank 
Thürauf
OpenMP: Support complex/float in && and || reduction

C/C++ permit logical AND and logical OR also with floating-point or complex
arguments by doing an unequal zero comparison; the result is an 'int' with
value one or zero.  Hence, those are also permitted as reduction variable,
even though it is not the most sensible thing to do.

gcc/c/ChangeLog:

	* c-typeck.c (c_finish_omp_clauses): Accept float + complex
	for || and && reductions.

gcc/cp/ChangeLog:

	* semantics.c (finish_omp_reduction_clause): Accept float + complex
	for || and && reductions.

gcc/ChangeLog:

	* omp-low.c (lower_rec_input_clauses, lower_reduction_clauses): Handle
	&& and || with floating-point and complex arguments.

gcc/testsuite/ChangeLog:

* gcc.dg/gomp/clause-1.c: Use 'reduction(&:' instead of '...(&&:'.

libgomp/ChangeLog:

	* testsuite/libgomp.c-c++-common/reduction-1.c: New test.
	* testsuite/libgomp.c-c++-common/reduction-2.c: New test.
	* testsuite/libgomp.c-c++-common/reduction-3.c: New test.

 gcc/c/c-typeck.c   |  10 +-
 gcc/cp/semantics.c |   8 +-
 gcc/omp-low.c  |  87 -
 gcc/testsuite/gcc.dg/gomp/clause-1.c   |   2 +-
 .../testsuite/libgomp.c-c++-common/reduction-1.c   | 192 
 .../testsuite/libgomp.c-c++-common/reduction-2.c   | 192 
 .../testsuite/libgomp.c-c++-common/reduction-3.c   | 192 
 .../testsuite/libgomp.c-c++-common/reduction-4.c   | 194 +
 8 files changed, 856 insertions(+), 21 deletions(-)

diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
index 3b45cfda0ff..fdc7bb6125c 100644
--- a/gcc/c/c-typeck.c
+++ b/gcc/c/c-typeck.c
@@ -14097,6 +14097,8 @@ c_finish_omp_clauses (tree clauses, enum c_omp_region_type ort)
 		case PLUS_EXPR:
 		case MULT_EXPR:
 		case MINUS_EXPR:
+		case TRUTH_ANDIF_EXPR:
+		case TRUTH_ORIF_EXPR:
 		  break;
 		case MIN_EXPR:
 		  if (TREE_CODE (type) == COMPLEX_TYPE)
@@ -14115,14 +14117,6 @@ c_finish_omp_clauses (tree clauses, enum c_omp_region_type ort)
 		case BIT_IOR_EXPR:
 		  r_name = "|";
 		  break;
-		case TRUTH_ANDIF_EXPR:
-		  if (FLOAT_TYPE_P (type))
-		r_name = "&&";
-		  break;
-		case TRUTH_ORIF_EXPR:
-		  if (FLOAT_TYPE_P (type))
-		r_name = "||";
-		  break;
 		default:
 		  gcc_unreachable ();
 		}
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 6224f49f189..0d590c318fb 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -6032,6 +6032,8 @@ finish_omp_reduction_clause (tree c, bool *need_default_ctor, bool *need_dtor)
   case PLUS_EXPR:
   case MULT_EXPR:
   case MINUS_EXPR:
+  case TRUTH_ANDIF_EXPR:
+  case TRUTH_ORIF_EXPR:
 	predefined = true;
 	break;
   case MIN_EXPR:
@@ -6047,12 +6049,6 @@ finish_omp_reduction_clause (tree c, bool *need_default_ctor, bool *need_dtor)
 	  break;
 	predefined = true;
 	break;
-  case TRUTH_ANDIF_EXPR:
-  case TRUTH_ORIF_EXPR:
-	if (FLOAT_TYPE_P (type))
-	  break;
-	predefined = true;
-	break;
   default:
 	break;
   }
diff --git a/gcc/omp-low.c b/gcc/omp-low.c
index 1f14c4b1d69..1e31d8e72c4 100644
--- a/gcc/omp-low.c
+++ b/gcc/omp-low.c
@@ -6389,6 +6389,11 @@ lower_rec_input_clauses (tree clauses, gimple_seq *ilist, gimple_seq *dlist,
 		  if (code == MINUS_EXPR)
 		code = PLUS_EXPR;
 
+		  /* C/C++ permits FP/complex with || and &&.  */
+		  bool 

Re: ctype support for libstdc++ on VxWorks

[Jonathan Wakely via Gcc-patches]

On 03/05/21 23:52 -0300, Alexandre Oliva wrote:


This patch adds ctype and locale support to libstdc++ on vxworks7.
We've been using this for a while internally.  It was tested with
various vx7r2 targets.  Ok to install?





+// VxWorks does not consider spaces to be blank, however, the testsuite
+// and more generally the libstdc++ rely on it, we explicitely handle


s/explicitely/explicitly/


OK with that tweak.

Re: [PATCH] phiopt: Optimize (x <=> y) cmp z [PR94589]

[Jakub Jelinek via Gcc-patches]

On Tue, May 04, 2021 at 10:42:12AM +0100, Jonathan Wakely wrote:
> > There are two things I'd like to address in a follow-up:
> > 1) if (HONOR_NANS (TREE_TYPE (lhs1)) || HONOR_SIGNED_ZEROS (TREE_TYPE 
> > (lhs1)))
> > is what I've copied from elsewhere in phiopt, but thinking about it,
> > alll we care is probably only HONOR_NANS, the matched pattern starts with
> > == or != comparison and branches to the PHI bb with -1/0/1/2 result if it is
> > equal, which should be the case for signed zero differences.
> > 2) the pr94589-2.C testcase should be matching just 12 times each, but runs
> > into operator>=(strong_ordering, unspecified) being defined as
> 
> Should this say s/strong/partial/  ?

Yeah, sorry.

Jakub

Re: [RFC] Using main loop's updated IV as base_address for epilogue vectorization

[Richard Biener]

On Fri, 30 Apr 2021, Andre Vieira (lists) wrote:

> Hi,
> 
> The aim of this RFC is to explore a way of cleaning up the codegen around
> data_references.  To be specific, I'd like to reuse the main-loop's updated
> data_reference as the base_address for the epilogue's corresponding
> data_reference, rather than use the niters.  We have found this leads to
> better codegen in the vectorized epilogue loops.
> 
> The approach in this RFC creates a map if iv_updates which always contain an
> updated pointer that is caputed in vectorizable_{load,store}, an iv_update may
> also contain a skip_edge in case we decide the vectorization can be skipped in
> 'vect_do_peeling'. During the epilogue update this map of iv_updates is then
> checked to see if it contains an entry for a data_reference and it is used
> accordingly and if not it reverts back to the old behavior of using the niters
> to advance the data_reference.
> 
> The motivation for this work is to improve codegen for the option `--param
> vect-partial-vector-usage=1` for SVE. We found that one of the main problems
> for the codegen here was coming from unnecessary conversions caused by the way
> we update the data_references in the epilogue.
> 
> This patch passes regression tests in aarch64-linux-gnu, but the codegen is
> still not optimal in some cases. Specifically those where we have a scalar
> epilogue, as this does not use the data_reference's and will rely on the
> gimple scalar code, thus constructing again a memory access using the niters. 
> This is a limitation for which I haven't quite worked out a solution yet and
> does cause some minor regressions due to unfortunate spills.
> 
> Let me know what you think and if you have ideas of how we can better achieve
> this.

Hmm, so the patch adds a kludge to improve the kludge we have in place ;)

I think it might be interesting to create a C testcase mimicing the
update problem without involving the vectorizer.  That way we can
see how the various components involved behave (FRE + ivopts most
specifically).

That said, a cleaner approach to dealing with this would be to
explicitely track the IVs we generate for vectorized DRs, eventually
factoring that out from vectorizable_{store,load} so we can simply
carry over the actual pointer IV final value to the epilogue as
initial value.  For each DR group we'd create a single IV (we can
even do better in case we have load + store of the "same" group).

We already kind-of track things via the ivexpr_map, but I'm not sure
if this lazly populated map can be reliably re-used to "re-populate"
the epilogue one (walk the map, create epilogue IVs with the appropriate
initial value & adjustd upate).

Richard.

> Kind regards,
> Andre Vieira
> 
> 
> 

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

[Ada] Remove arbitrary and redundant qualification with Sinfo

[Pierre-Marie de Rodat]

Code cleanup; semantics is unaffected. Perhaps the extra qualification
used to be necessary to avoid ambiguities, but it is no longer needed.

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

gcc/ada/

* pprint.adb: Remove qualification of arbitrary calls to
Sinfo.Expressions and Sinfo.Parameter_Associations.diff --git a/gcc/ada/pprint.adb b/gcc/ada/pprint.adb
--- a/gcc/ada/pprint.adb
+++ b/gcc/ada/pprint.adb
@@ -238,10 +238,10 @@ package body Pprint is
return "new " & Expr_Name (Expression (Expr));
 
 when N_Aggregate =>
-   if Present (Sinfo.Expressions (Expr)) then
+   if Present (Expressions (Expr)) then
   return
 List_Name
-  (List  => First (Sinfo.Expressions (Expr)),
+  (List  => First (Expressions (Expr)),
Add_Space => False);
 
--  Do not return empty string for (others => <>) aggregate
@@ -265,7 +265,7 @@ package body Pprint is
 when N_Extension_Aggregate =>
return "(" & Expr_Name (Ancestor_Part (Expr)) & " with "
  & List_Name
- (List  => First (Sinfo.Expressions (Expr)),
+ (List  => First (Expressions (Expr)),
   Add_Space => False,
   Add_Paren => False) & ")";
 
@@ -356,9 +356,8 @@ package body Pprint is
   and then Nkind (Decl) = N_Object_Declaration
   and then not Comes_From_Source (Decl)
   and then Constant_Present (Decl)
-  and then Present (Sinfo.Expression (Decl))
-  and then Nkind (Sinfo.Expression (Decl)) =
- N_Reference
+  and then Present (Expression (Decl))
+  and then Nkind (Expression (Decl)) = N_Reference
 then
return "";
 end if;
@@ -411,7 +410,7 @@ package body Pprint is
 
 when N_If_Expression =>
declare
-  N : constant Node_Id := First (Sinfo.Expressions (Expr));
+  N : constant Node_Id := First (Expressions (Expr));
begin
   return
 "if " & Expr_Name (N) & " then "
@@ -622,9 +621,9 @@ package body Pprint is
if Take_Prefix then
   return
 Expr_Name (Prefix (Expr))
-  & List_Name (First (Sinfo.Expressions (Expr)));
+  & List_Name (First (Expressions (Expr)));
else
-  return List_Name (First (Sinfo.Expressions (Expr)));
+  return List_Name (First (Expressions (Expr)));
end if;
 
 when N_Function_Call =>
@@ -636,13 +635,12 @@ package body Pprint is
if Default = "" then
   return '('
 & Expr_Name (Name (Expr))
-& List_Name (First (Sinfo.Parameter_Associations (Expr)))
+& List_Name (First (Parameter_Associations (Expr)))
 & ')';
else
   return
 Expr_Name (Name (Expr))
-  & List_Name
-  (First (Sinfo.Parameter_Associations (Expr)));
+  & List_Name (First (Parameter_Associations (Expr)));
end if;
 
 when N_Null =>
@@ -768,11 +766,11 @@ package body Pprint is
end if;
 
 when N_Indexed_Component =>
-   Right := Original_Node (Last (Sinfo.Expressions (Right)));
+   Right := Original_Node (Last (Expressions (Right)));
Append_Paren := Append_Paren + 1;
 
 when N_Function_Call =>
-   if Present (Sinfo.Parameter_Associations (Right)) then
+   if Present (Parameter_Associations (Right)) then
   declare
  Rover : Node_Id;
  Found : Boolean;
@@ -781,7 +779,7 @@ package body Pprint is
  --  Avoid source position confusion associated with
  --  parameters for which Comes_From_Source is False.
 
- Rover := First (Sinfo.Parameter_Associations (Right));
+ Rover := First (Parameter_Associations (Right));
  Found := False;
  while Present (Rover) loop
 if Comes_From_Source (Original_Node (Rover)) then

[Ada] Use function and not procedure UI_Image in pretty-printing

[Pierre-Marie de Rodat]

Code cleanup; semantics is unaffected. The code for pretty-printing
integer, real and string literals now looks the same.

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

gcc/ada/

* pprint.adb (Expr_Name): Simplify with functional variant of
UI_Image.diff --git a/gcc/ada/pprint.adb b/gcc/ada/pprint.adb
--- a/gcc/ada/pprint.adb
+++ b/gcc/ada/pprint.adb
@@ -226,8 +226,7 @@ package body Pprint is
end;
 
 when N_Integer_Literal =>
-   UI_Image (Intval (Expr));
-   return UI_Image_Buffer (1 .. UI_Image_Length);
+   return UI_Image (Intval (Expr));
 
 when N_Real_Literal =>
return Real_Image (Realval (Expr));

[Ada] Reuse existing To_Mixed routine in pretty-printer

[Pierre-Marie de Rodat]

Unit Pprint, which implements pretty-printing of the AST, defined
routine To_Mixed_Case, which was identical to System.Case_Util.To_Mixed.

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

gcc/ada/

* pprint.adb (To_Mixed): Removed.diff --git a/gcc/ada/pprint.adb b/gcc/ada/pprint.adb
--- a/gcc/ada/pprint.adb
+++ b/gcc/ada/pprint.adb
@@ -24,7 +24,6 @@
 --
 
 with Atree;   use Atree;
-with Csets;   use Csets;
 with Einfo;   use Einfo;
 with Namet;   use Namet;
 with Nlists;  use Nlists;
@@ -34,6 +33,8 @@ with Sinput;  use Sinput;
 with Snames;  use Snames;
 with Uintp;   use Uintp;
 
+with System.Case_Util;
+
 package body Pprint is
 
List_Name_Count : Natural := 0;
@@ -272,32 +273,6 @@ package body Pprint is
 when N_Attribute_Reference =>
if Take_Prefix then
   declare
- function To_Mixed_Case (S : String) return String;
- --  Transform given string into the corresponding one in
- --  mixed case form.
-
- ---
- -- To_Mixed_Case --
- ---
-
- function To_Mixed_Case (S : String) return String is
-Result : String (S'Range);
-Ucase  : Boolean := True;
-
- begin
-for J in S'Range loop
-   if Ucase then
-  Result (J) := Fold_Upper (S (J));
-   else
-  Result (J) := Fold_Lower (S (J));
-   end if;
-
-   Ucase := (S (J) = '_');
-end loop;
-
-return Result;
- end To_Mixed_Case;
-
  Id : constant Attribute_Id :=
 Get_Attribute_Id (Attribute_Name (Expr));
 
@@ -306,7 +281,7 @@ package body Pprint is
  Str : constant String :=
  Expr_Name (Prefix (Expr))
& "'"
-   & To_Mixed_Case
+   & System.Case_Util.To_Mixed
(Get_Name_String (Attribute_Name (Expr)));
 
  N  : Node_Id;

[Ada] Minor tweak in pretty-printing of expressions

[Pierre-Marie de Rodat]

Printing of expressions is used in GNATprove to display parts of an
assertion which are not proved, Here the printing is improved slightly
for an expression-with-actions, so that the underlying expression is
printed, instead of the corresponding AST form of the expression with
Expr_Name.

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

gcc/ada/

* pprint.adb (Expression_Image): Special case for
expression-with-actions.diff --git a/gcc/ada/pprint.adb b/gcc/ada/pprint.adb
--- a/gcc/ada/pprint.adb
+++ b/gcc/ada/pprint.adb
@@ -682,7 +682,7 @@ package body Pprint is
  end case;
   end Expr_Name;
 
-   --  Start of processing for Expression_Name
+   --  Start of processing for Expression_Image
 
begin
   if not From_Source then
@@ -697,6 +697,12 @@ package body Pprint is
  end;
   end if;
 
+  --  Reach to the underlying expression for an expression-with-actions
+
+  if Nkind (Expr) = N_Expression_With_Actions then
+ return Expression_Image (Expression (Expr), Default);
+  end if;
+
   --  Compute left (start) and right (end) slocs for the expression
   --  Consider using Sinput.Sloc_Range instead, except that it does not
   --  work properly currently???

[Ada] Do not "optimize" by converting Positive to Unsigned

[Pierre-Marie de Rodat]

Back out the previous change that tried to "optimize" in
Expand_Concatenate. It turns out that this is actually a pessimization,
and it causes codepeer to trip over a bunch of extra checks.

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

gcc/ada/

* exp_ch4.adb (Expand_Concatenate): Remove the non-optimization.diff --git a/gcc/ada/exp_ch4.adb b/gcc/ada/exp_ch4.adb
--- a/gcc/ada/exp_ch4.adb
+++ b/gcc/ada/exp_ch4.adb
@@ -3025,14 +3025,6 @@ package body Exp_Ch4 is
   if Is_Enumeration_Type (Ityp) then
  Artyp := Standard_Integer;
 
-  --  If index type is Positive, we use the standard unsigned type, to give
-  --  more room on the top of the range, obviating the need for an overflow
-  --  check when creating the upper bound. This is needed to avoid junk
-  --  overflow checks in the common case of String types.
-
-  elsif Istyp = Standard_Positive then
- Artyp := Standard_Unsigned;
-
   --  For modular types, we use a 32-bit modular type for types whose size
   --  is in the range 1-31 bits. For 32-bit unsigned types, we use the
   --  identity type, and for larger unsigned types we use a 64-bit type.

[Ada] Refine type of a counter variable from Integer to Natural

[Pierre-Marie de Rodat]

A List_Name_Count variable is initialized with zero, then incremented
and decremented in a stack-like manner, so it should never become
negative.

This gives us extra confidence, but otherwise the behaviour is not
affected.

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

gcc/ada/

* pprint.adb (List_Name_Count): Change type from Integer to
Natural.diff --git a/gcc/ada/pprint.adb b/gcc/ada/pprint.adb
--- a/gcc/ada/pprint.adb
+++ b/gcc/ada/pprint.adb
@@ -36,7 +36,7 @@ with Uintp;   use Uintp;
 
 package body Pprint is
 
-   List_Name_Count : Integer := 0;
+   List_Name_Count : Natural := 0;
--  Counter used to prevent infinite recursion while computing name of
--  complex expressions.
 

[Ada] Assert_Failure vs Assertion_Error

[Pierre-Marie de Rodat]

When Ada introduced Ada.Assertions.Assertion_Error, we made it a
renaming of the existing System.Assertions.Assert_Failure as provisioned
by the ARM, but we should have done it the other way around, so that the
reference/first class exception is the one from the ARM in e.g.
exception messages.

This is now done by swapping the renaming.

Note that this provides a simple version under gcc-interface for
bootstrap with old GNAT compilers, which are not able to compile
libgnat/a-assert.adb. We will be able to remove this simple version when
we bump by one year the minimal version requirement.

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

gcc/ada/

* libgnat/s-assert.ads (Assert_Failure): Now a renaming of
Assertion_Error.
* libgnat/a-assert.ads (Assertion_Error): Now a first class
citizen.  Remove dependency on System.Assertions.
* gcc-interface/a-assert.ads, gcc-interface/a-assert.adb: New.
* gcc-interface/Make-lang.in (GNAT_ADA_OBJS, GNATBIND_OBJS): Add
a-assert.o from gcc-interface.diff --git a/gcc/ada/gcc-interface/Make-lang.in b/gcc/ada/gcc-interface/Make-lang.in
--- a/gcc/ada/gcc-interface/Make-lang.in
+++ b/gcc/ada/gcc-interface/Make-lang.in
@@ -471,6 +471,7 @@ GNAT_ADA_OBJS =	\
  ada/stylesw.o	\
  ada/switch-c.o	\
  ada/switch.o	\
+ ada/gcc-interface/a-assert.o	\
  ada/gcc-interface/system.o	\
  ada/table.o	\
  ada/targparm.o	\
@@ -629,6 +630,7 @@ GNATBIND_OBJS = \
  ada/stylesw.o\
  ada/switch-b.o   \
  ada/switch.o \
+ ada/gcc-interface/a-assert.o	\
  ada/gcc-interface/system.o \
  ada/table.o  \
  ada/targext.o\


diff --git /dev/null b/gcc/ada/gcc-interface/a-assert.adb
new file mode 100644
--- /dev/null
+++ b/gcc/ada/gcc-interface/a-assert.adb
@@ -0,0 +1,52 @@
+--
+--  --
+-- GNAT RUN-TIME COMPONENTS --
+--  --
+--   A D A . A S S E R T--
+--  --
+-- B o d y  --
+--  --
+-- Copyright (C) 2007-2021, Free Software Foundation, Inc.  --
+--  --
+-- GNAT is free software;  you can  redistribute it  and/or modify it under --
+-- terms of the  GNU General Public License as published  by the Free Soft- --
+-- ware  Foundation;  either version 3,  or (at your option) any later ver- --
+-- sion.  GNAT is distributed in the hope that it will be useful, but WITH- --
+-- OUT ANY WARRANTY;  without even the  implied warranty of MERCHANTABILITY --
+-- or FITNESS FOR A PARTICULAR PURPOSE. --
+--  --
+-- As a special exception under Section 7 of GPL version 3, you are granted --
+-- additional permissions described in the GCC Runtime Library Exception,   --
+-- version 3.1, as published by the Free Software Foundation.   --
+--  --
+-- You should have received a copy of the GNU General Public License and--
+-- a copy of the GCC Runtime Library Exception along with this program; --
+-- see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see--
+-- .  --
+--  --
+-- GNAT was originally developed  by the GNAT team at  New York University. --
+-- Extensive contributions were provided by Ada Core Technologies Inc.  --
+--  --
+--
+
+package body Ada.Assertions is
+
+   
+   -- Assert --
+   
+
+   procedure Assert (Check : Boolean) is
+   begin
+  if Check = False then
+ raise Ada.Assertions.Assertion_Error;
+  end if;
+   end Assert;
+
+   procedure Assert (Check : Boolean; Message : String) is
+   begin
+  if Check = False then
+ raise Ada.Assertions.Assertion_Error with Message;
+  end if;
+   end Assert;
+
+end Ada.Assertions;


diff --git /dev/null b/gcc/ada/gcc-interface/a-assert.ads
new file mode 100644
--- /dev/null
+++ b/gcc/ada/gcc-interface/a-assert.ads
@@ -0,0 +1,50 @@
+--
+--  --
+-- GNAT 

[Ada] Fix handling of access-to-variable objects in Global and Depends

[Pierre-Marie de Rodat]

Objects that typically would be constant, but can actually be written
because they are of access-to-variable type, can appear as outputs in
the Global and Depends contracts of non-functions (i.e. functions,
procedures, generic functions, generic procedures, protected entries,
task types and single task objects).

Those objects are constants, generic parameters of mode IN, and actual
non-function parameters of mode IN (i.e. parameters of procedures,
generic procedures and protected entries).

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

gcc/ada/

* sem_prag.ads (Collect_Subprogram_Inputs_Outputs): Update
comment; this routine is no longer used by GNATprove.
* sem_prag.adb (Find_Role): The IN parameter is on output only
when it belongs to non-function; also, the otherwise constant
object can only be written by a non-function.
(Collect_Global_Item): The IN parameter can only be written when
it belongs to non-function; also, unnest this check to make it
easier to read.diff --git a/gcc/ada/sem_prag.adb b/gcc/ada/sem_prag.adb
--- a/gcc/ada/sem_prag.adb
+++ b/gcc/ada/sem_prag.adb
@@ -1281,17 +1281,22 @@ package body Sem_Prag is
(Item_Is_Input  : out Boolean;
 Item_Is_Output : out Boolean)
  is
---  A constant or IN parameter of access-to-variable type should be
+--  A constant or an IN parameter of a procedure or a protected
+--  entry, if it is of an access-to-variable type, should be
 --  handled like a variable, as the underlying memory pointed-to
 --  can be modified. Use Adjusted_Kind to do this adjustment.
 
 Adjusted_Kind : Entity_Kind := Ekind (Item_Id);
 
  begin
-if Ekind (Item_Id) in E_Constant
-| E_Generic_In_Parameter
-| E_In_Parameter
+if (Ekind (Item_Id) in E_Constant | E_Generic_In_Parameter
+  or else
+  (Ekind (Item_Id) = E_In_Parameter
+ and then Ekind (Scope (Item_Id))
+not in E_Function | E_Generic_Function))
   and then Is_Access_Variable (Etype (Item_Id))
+  and then Ekind (Spec_Id) not in E_Function
+| E_Generic_Function
 then
Adjusted_Kind := E_Variable;
 end if;
@@ -30244,16 +30249,6 @@ package body Sem_Prag is
  Formal := First_Entity (Spec_Id);
  while Present (Formal) loop
 if Ekind (Formal) in E_In_Out_Parameter | E_In_Parameter then
-
-   --  IN parameters can act as output when the related type is
-   --  access-to-variable.
-
-   if Ekind (Formal) = E_In_Parameter
- and then Is_Access_Variable (Etype (Formal))
-   then
-  Append_New_Elmt (Formal, Subp_Outputs);
-   end if;
-
Append_New_Elmt (Formal, Subp_Inputs);
 end if;
 
@@ -30271,6 +30266,17 @@ package body Sem_Prag is
end if;
 end if;
 
+--  IN parameters of procedures and protected entries can act as
+--  outputs when the related type is access-to-variable.
+
+if Ekind (Formal) = E_In_Parameter
+  and then Ekind (Spec_Id) not in E_Function
+| E_Generic_Function
+  and then Is_Access_Variable (Etype (Formal))
+then
+   Append_New_Elmt (Formal, Subp_Outputs);
+end if;
+
 Next_Entity (Formal);
  end loop;
 


diff --git a/gcc/ada/sem_prag.ads b/gcc/ada/sem_prag.ads
--- a/gcc/ada/sem_prag.ads
+++ b/gcc/ada/sem_prag.ads
@@ -360,9 +360,9 @@ package Sem_Prag is
   Subp_Outputs : in out Elist_Id;
   Global_Seen  : out Boolean);
--  Subsidiary to the analysis of pragmas Depends, Global, Refined_Depends
-   --  and Refined_Global. The routine is also used by GNATprove. Collect all
-   --  inputs and outputs of subprogram Subp_Id in lists Subp_Inputs (inputs)
-   --  and Subp_Outputs (outputs). The inputs and outputs are gathered from:
+   --  and Refined_Global. Collect all inputs and outputs of subprogram Subp_Id
+   --  in lists Subp_Inputs (inputs) and Subp_Outputs (outputs). The inputs and
+   --  outputs are gathered from:
--1) The formal parameters of the subprogram
--2) The generic formal parameters of the generic subprogram
--3) The current instance of a concurrent type

[Ada] Reuse First_Formal for generic subprograms

[Pierre-Marie de Rodat]

Routine First_Formal works both for non-generic and generic subprograms,
so patch removes a dubious special-casing for the latter.

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

gcc/ada/

* lib-xref.adb (Generate_Reference_To_Formals): Remove dedicated
branch for generic subprograms (they are now handled together
with non-generic subprograms in the ELSE branch); replace a
low-level Ekind membership test with a high-level call to
Is_Access_Subprogram_Type.diff --git a/gcc/ada/lib-xref.adb b/gcc/ada/lib-xref.adb
--- a/gcc/ada/lib-xref.adb
+++ b/gcc/ada/lib-xref.adb
@@ -1277,18 +1277,8 @@ package body Lib.Xref is
   Formal : Entity_Id;
 
begin
-  if Is_Generic_Subprogram (E) then
- Formal := First_Entity (E);
-
- while Present (Formal)
-   and then not Is_Formal (Formal)
- loop
-Next_Entity (Formal);
- end loop;
-
-  elsif Ekind (E) in Access_Subprogram_Kind then
+  if Is_Access_Subprogram_Type (E) then
  Formal := First_Formal (Designated_Type (E));
-
   else
  Formal := First_Formal (E);
   end if;

[Ada] Fix inconsistent iteration with First_Formal and Next_Entity

[Pierre-Marie de Rodat]

Iteration routines should come in pairs, i.e. First_Formal with
Next_Formal and First_Entity with Next_Entity. This patch fixes two
occurrences where First_Formal was used with Next_Entity. Cleanup only;
semantics is unaffected.

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

gcc/ada/

* sem_ch12.adb (Check_Abstract_Primitives): Match First_Formal
with Next_Formal.
* sem_ch6.adb (Is_Non_Overriding_Operation): Likewise.diff --git a/gcc/ada/sem_ch12.adb b/gcc/ada/sem_ch12.adb
--- a/gcc/ada/sem_ch12.adb
+++ b/gcc/ada/sem_ch12.adb
@@ -13682,8 +13682,8 @@ package body Sem_Ch12 is
 exit;
  end if;
 
- Next_Entity (Anc_Formal);
- Next_Entity (Act_Formal);
+ Next_Formal (Anc_Formal);
+ Next_Formal (Act_Formal);
   end loop;
 
   --  If we traversed through all of the formals


diff --git a/gcc/ada/sem_ch6.adb b/gcc/ada/sem_ch6.adb
--- a/gcc/ada/sem_ch6.adb
+++ b/gcc/ada/sem_ch6.adb
@@ -10713,8 +10713,8 @@ package body Sem_Ch6 is
exit;
 end if;
 
-Next_Entity (P_Formal);
-Next_Entity (N_Formal);
+Next_Formal (P_Formal);
+Next_Formal (N_Formal);
  end loop;
 
  --  Found a matching primitive operation belonging to the

[Ada] Simplify iteration over formal parameters for Global/Depends check

[Pierre-Marie de Rodat]

Replace low-level First_Entity/Next_Entity with a high-level
First_Formal/Next_Formal. The new code is easier to debug, because we
don't even see local subprograms, objects, etc.

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

gcc/ada/

* sem_prag.adb (Collect_Global_Item): Iterate directly over
formals.diff --git a/gcc/ada/sem_prag.adb b/gcc/ada/sem_prag.adb
--- a/gcc/ada/sem_prag.adb
+++ b/gcc/ada/sem_prag.adb
@@ -30246,7 +30246,7 @@ package body Sem_Prag is
 
  --  Process all formal parameters
 
- Formal := First_Entity (Spec_Id);
+ Formal := First_Formal (Spec_Id);
  while Present (Formal) loop
 if Ekind (Formal) in E_In_Out_Parameter | E_In_Parameter then
Append_New_Elmt (Formal, Subp_Inputs);
@@ -30277,7 +30277,7 @@ package body Sem_Prag is
Append_New_Elmt (Formal, Subp_Outputs);
 end if;
 
-Next_Entity (Formal);
+Next_Formal (Formal);
  end loop;
 
   --  Otherwise the input denotes a task type, a task body, or the

[Ada] Ongoing work for AI12-0212: container aggregates

[Pierre-Marie de Rodat]

This patch refines the handling of container aggregates with non-static
sizes given with iterated component associations and iterated element
associations. When necessary we construct an expression to be evaluated
dynamically to guide the allocation of the container, prior to inserting
elements.

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

gcc/ada/

* exp_aggr.adb (Build_Siz_Exp): new function, subsidiary of
Expand_Container_Aggregate, to create an expression to be used
in the dynamic allocation of a container with a single container
element association.
(Add_Range): Handle static bounds of ranges over enumerations.
(Expand_Container_Aggregate): Add declaration for size
expression when needed, and use it in container object
declaration for container.diff --git a/gcc/ada/exp_aggr.adb b/gcc/ada/exp_aggr.adb
--- a/gcc/ada/exp_aggr.adb
+++ b/gcc/ada/exp_aggr.adb
@@ -6982,11 +6982,24 @@ package body Exp_Aggr is
   Init_Stat : Node_Id;
   Siz   : Int;
 
+  --  The following are used when the size of the aggregate is not
+  --  static and requires a dynamic evaluation.
+  Siz_Decl   : Node_Id;
+  Siz_Exp: Node_Id := Empty;
+  Count_Type : Entity_Id;
+
   function Aggregate_Size return Int;
   --  Compute number of entries in aggregate, including choices
-  --  that cover a range, as well as iterated constructs.
+  --  that cover a range or subtype, as well as iterated constructs.
   --  Return -1 if the size is not known statically, in which case
-  --  we allocate a default size for the aggregate.
+  --  allocate a default size for the aggregate, or build an expression
+  --  to estimate the size dynamically.
+
+  function Build_Siz_Exp (Comp : Node_Id) return Int;
+  --  When the aggregate contains a single Iterated_Component_Association
+  --  or Element_Association with non-static bounds, build an expression
+  --  to be used as the allocated size of the container. This may be an
+  --  overestimate if a filter is present, but is a safe approximation.
 
   procedure Expand_Iterated_Component (Comp : Node_Id);
   --  Handle iterated_component_association and iterated_Element
@@ -7005,34 +7018,54 @@ package body Exp_Aggr is
  Siz : Int := 0;
 
  procedure Add_Range_Size;
- --  Compute size of component association given by
- --  range or subtype name.
+ --  Compute number of components specified by a component association
+ --  given by a range or subtype name.
+
+ 
+ -- Add_Range_Size --
+ 
 
  procedure Add_Range_Size is
  begin
+--  The bounds of the discrete range are integers or enumeration
+--  literals
+
 if Nkind (Lo) = N_Integer_Literal then
Siz := Siz + UI_To_Int (Intval (Hi))
- - UI_To_Int (Intval (Lo)) + 1;
+  - UI_To_Int (Intval (Lo)) + 1;
+else
+   Siz := Siz + UI_To_Int (Enumeration_Pos (Hi))
+  - UI_To_Int (Enumeration_Pos (Lo)) + 1;
 end if;
  end Add_Range_Size;
 
   begin
+ --  Aggregate is either all positional or all named.
+
  if Present (Expressions (N)) then
 Siz := List_Length (Expressions (N));
  end if;
 
  if Present (Component_Associations (N)) then
 Comp := First (Component_Associations (N));
-
---  If the component is an Iterated_Element_Association
---  it includes an iterator or a loop parameter, possibly
---  with a filter, so we do not attempt to compute its
---  size. Room for future optimization ???
-
-if Nkind (Comp) = N_Iterated_Element_Association then
-   return -1;
+--  If there is a single component association it can be
+--  an iterated component with dynamic bounds or an element
+--  iterator over an iterable object. If it is an array
+--  we can use the attribute Length to get its size;
+--  for a predefined container the function Length plays
+--  the same role. There is no available mechanism for
+--  user-defined containers. For now we treat all of these
+--  as dynamic.
+
+if List_Length (Component_Associations (N)) = 1
+  and then Nkind (Comp) in N_Iterated_Component_Association |
+   N_Iterated_Element_Association
+then
+   return Build_Siz_Exp (Comp);
 end if;
 
+--  Otherwise all associations must specify static sizes.
+
 while Present (Comp) loop
Choice := First (Choice_List (Comp));
 
@@ -7042,26 +7075,14 @@ package body Exp_Aggr is

[Ada] Move match function for pragma Warnings to public spec

[Pierre-Marie de Rodat]

In order to use the same matching function in GNATprove for justifying
messages through pragma Annotate as the matching function used for
pragma Warnings, make that function publicly visible in Erroutc.

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

gcc/ada/

* erroutc.adb (Matches): Move spec...
* erroutc.ads (Matches): ...here.diff --git a/gcc/ada/erroutc.adb b/gcc/ada/erroutc.adb
--- a/gcc/ada/erroutc.adb
+++ b/gcc/ada/erroutc.adb
@@ -51,11 +51,6 @@ package body Erroutc is
-- Local Subprograms --
---
 
-   function Matches (S : String; P : String) return Boolean;
-   --  Returns true if the String S matches the pattern P, which can contain
-   --  wildcard chars (*). The entire pattern must match the entire string.
-   --  Case is ignored in the comparison (so X matches x).
-
function Sloc_In_Range (Loc, Start, Stop : Source_Ptr) return Boolean;
--  Return whether Loc is in the range Start .. Stop, taking instantiation
--  locations of Loc into account. This is useful for suppressing warnings


diff --git a/gcc/ada/erroutc.ads b/gcc/ada/erroutc.ads
--- a/gcc/ada/erroutc.ads
+++ b/gcc/ada/erroutc.ads
@@ -496,6 +496,11 @@ package Erroutc is
--  Given an error message ID, return tag showing warning message class, or
--  the null string if this option is not enabled or this is not a warning.
 
+   function Matches (S : String; P : String) return Boolean;
+   --  Returns true if the String S matches the pattern P, which can contain
+   --  wildcard chars (*). The entire pattern must match the entire string.
+   --  Case is ignored in the comparison (so X matches x).
+
procedure Output_Error_Msgs (E : in out Error_Msg_Id);
--  Output source line, error flag, and text of stored error message and all
--  subsequent messages for the same line and unit. On return E is set to be

[Ada] Simplify use of a global name buffer for Global/Depends errors

[Pierre-Marie de Rodat]

Error messages about the Global/Depends contracts are constructed in the
Global_Name_Buffer, but there is no need to store those messages as the
Name_Id objects.

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

gcc/ada/

* sem_prag.adb (Role_Error, Usage_Error): Replace calls to
Name_Find and Get_Name_String with a call to To_String.diff --git a/gcc/ada/sem_prag.adb b/gcc/ada/sem_prag.adb
--- a/gcc/ada/sem_prag.adb
+++ b/gcc/ada/sem_prag.adb
@@ -1477,8 +1477,6 @@ package body Sem_Prag is
(Item_Is_Input  : Boolean;
 Item_Is_Output : Boolean)
  is
-Error_Msg : Name_Id;
-
  begin
 Name_Len := 0;
 
@@ -1491,8 +1489,7 @@ package body Sem_Prag is
Add_Str_To_Name_Buffer
  (" & cannot appear in dependence relation");
 
-   Error_Msg := Name_Find;
-   SPARK_Msg_NE (Get_Name_String (Error_Msg), Item, Item_Id);
+   SPARK_Msg_NE (To_String (Global_Name_Buffer), Item, Item_Id);
 
Error_Msg_Name_1 := Chars (Spec_Id);
SPARK_Msg_NE
@@ -1521,8 +1518,8 @@ package body Sem_Prag is
end if;
 
Add_Str_To_Name_Buffer (" in dependence relation");
-   Error_Msg := Name_Find;
-   SPARK_Msg_NE (Get_Name_String (Error_Msg), Item, Item_Id);
+
+   SPARK_Msg_NE (To_String (Global_Name_Buffer), Item, Item_Id);
 end if;
  end Role_Error;
 
@@ -1574,8 +1571,6 @@ package body Sem_Prag is
  -
 
  procedure Usage_Error (Item_Id : Entity_Id) is
-Error_Msg : Name_Id;
-
  begin
 --  Input case
 
@@ -1593,8 +1588,7 @@ package body Sem_Prag is
   Add_Str_To_Name_Buffer
 (" & is missing from input dependence list");
 
-  Error_Msg := Name_Find;
-  SPARK_Msg_NE (Get_Name_String (Error_Msg), N, Item_Id);
+  SPARK_Msg_NE (To_String (Global_Name_Buffer), N, Item_Id);
   SPARK_Msg_NE
 ("\add `null ='> &` dependency to ignore this input",
  N, Item_Id);
@@ -1609,8 +1603,7 @@ package body Sem_Prag is
Add_Str_To_Name_Buffer
  (" & is missing from output dependence list");
 
-   Error_Msg := Name_Find;
-   SPARK_Msg_NE (Get_Name_String (Error_Msg), N, Item_Id);
+   SPARK_Msg_NE (To_String (Global_Name_Buffer), N, Item_Id);
 end if;
  end Usage_Error;
 

[Ada] Use error marker for messages in GNATprove mode

[Pierre-Marie de Rodat]

Force the use of the "error:" marker for error messages in GNATprove.
This helps distinguishing these messages from others like warnings,
check messages and info messages, in particular when colored output is
used.

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

gcc/ada/

* gnat1drv.adb (Adjust_Global_Switches): Force error marker in
GNATprove mode.diff --git a/gcc/ada/gnat1drv.adb b/gcc/ada/gnat1drv.adb
--- a/gcc/ada/gnat1drv.adb
+++ b/gcc/ada/gnat1drv.adb
@@ -565,6 +565,10 @@ procedure Gnat1drv is
 
  Tagged_Type_Expansion := False;
 
+ --  Force the use of "error:" prefix for error messages
+
+ Unique_Error_Tag := True;
+
  --  Detect that the runtime library support for floating-point numbers
  --  may not be compatible with SPARK analysis of IEEE-754 floats.
 

[Ada] Missing finalization on generic instantiation

[Pierre-Marie de Rodat]

If some objects are declared in the body of a generic package, these
objects are not finalized when the package is instantiated at the
library level.

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

gcc/ada/

* exp_ch7.adb (Build_Finalizer_Helper.New_Finalizer_Name):
Unnest so that it can be reused.
(Build_Finalizer_Helper.Process_Declarations): Call the
xxx__finalize_body procedure of a package instantiation in case
it contains finalization statements.  Code clean ups.
(Build_Finalizer_Helper.Create_Finalizer): Export and set an
Interface_Name for library level finalizers since these may be
imported now.
(Build_Finalizer_Helper): Need to process library level package
body instantiations which may contain objects requiring
finalization.
* libgnat/s-finmas.ads: Fix typo.diff --git a/gcc/ada/exp_ch7.adb b/gcc/ada/exp_ch7.adb
--- a/gcc/ada/exp_ch7.adb
+++ b/gcc/ada/exp_ch7.adb
@@ -1547,6 +1547,11 @@ package body Exp_Ch7 is
   --  Create the spec and body of the finalizer and insert them in the
   --  proper place in the tree depending on the context.
 
+  function New_Finalizer_Name
+(Spec_Id : Node_Id; For_Spec : Boolean) return Name_Id;
+  --  Create a fully qualified name of a package spec or body finalizer.
+  --  The generated name is of the form: xx__yy__finalize_[spec|body].
+
   procedure Process_Declarations
 (Decls  : List_Id;
  Preprocess : Boolean := False;
@@ -1554,7 +1559,8 @@ package body Exp_Ch7 is
   --  Inspect a list of declarations or statements which may contain
   --  objects that need finalization. When flag Preprocess is set, the
   --  routine will simply count the total number of controlled objects in
-  --  Decls. Flag Top_Level denotes whether the processing is done for
+  --  Decls and set Counter_Val accordingly. Top_Level is only relevant
+  --  when Preprocess is set and if True, the processing is performed for
   --  objects in nested package declarations or instances.
 
   procedure Process_Object_Declaration
@@ -1689,58 +1695,6 @@ package body Exp_Ch7 is
   --
 
   procedure Create_Finalizer is
- function New_Finalizer_Name return Name_Id;
- --  Create a fully qualified name of a package spec or body finalizer.
- --  The generated name is of the form: xx__yy__finalize_[spec|body].
-
- 
- -- New_Finalizer_Name --
- 
-
- function New_Finalizer_Name return Name_Id is
-procedure New_Finalizer_Name (Id : Entity_Id);
---  Place "__" in the name buffer. If the identifier
---  has a non-standard scope, process the scope first.
-
-
--- New_Finalizer_Name --
-
-
-procedure New_Finalizer_Name (Id : Entity_Id) is
-begin
-   if Scope (Id) = Standard_Standard then
-  Get_Name_String (Chars (Id));
-
-   else
-  New_Finalizer_Name (Scope (Id));
-  Add_Str_To_Name_Buffer ("__");
-  Add_Str_To_Name_Buffer (Get_Name_String (Chars (Id)));
-   end if;
-end New_Finalizer_Name;
-
- --  Start of processing for New_Finalizer_Name
-
- begin
---  Create the fully qualified name of the enclosing scope
-
-New_Finalizer_Name (Spec_Id);
-
---  Generate:
---__finalize_[spec|body]
-
-Add_Str_To_Name_Buffer ("__finalize_");
-
-if For_Package_Spec then
-   Add_Str_To_Name_Buffer ("spec");
-else
-   Add_Str_To_Name_Buffer ("body");
-end if;
-
-return Name_Find;
- end New_Finalizer_Name;
-
- --  Local variables
-
  Body_Id: Entity_Id;
  Fin_Body   : Node_Id;
  Fin_Spec   : Node_Id;
@@ -1748,8 +1702,6 @@ package body Exp_Ch7 is
  Label  : Node_Id;
  Label_Id   : Entity_Id;
 
-  --  Start of processing for Create_Finalizer
-
   begin
  --  Step 1: Creation of the finalizer name
 
@@ -1760,7 +1712,8 @@ package body Exp_Ch7 is
  --xx__yy__finalize_[spec|body]
 
  if For_Package then
-Fin_Id := Make_Defining_Identifier (Loc, New_Finalizer_Name);
+Fin_Id := Make_Defining_Identifier
+(Loc, New_Finalizer_Name (Spec_Id, For_Package_Spec));
 Set_Has_Qualified_Name   (Fin_Id);
 Set_Has_Fully_Qualified_Name (Fin_Id);
 
@@ -1836,10 +1789,22 @@ package body Exp_Ch7 is
Make_Procedure_Specification (Loc,
  Defining_Unit_Name => Fin_Id));
 
+ if For_Package then
+Set_Is_Exported (Fin_Id);
+ 

[Ada] Reject formals of mode IN appearing as global outputs

[Pierre-Marie de Rodat]

Fix implementation of SPARK RM 6.1.4(13), which says:

  "... if the global_specification of the outer subprogram has an entity
   denoted by a global_item with a mode_specification of Input or the
   entity is a formal parameter with a mode of in"

but the rule was only enforced for outer subprograms with explicit
Global contracts. Now it is enforced for subprograms with implicit
Global contracts as well, i.e. both implicit Global => null, implicit
Global implied by Depends, and with Global generated by the flow
analysis of GNATprove.

In particular, this is useful for detecting formals of mode IN appearing
in as global outputs of nested subprograms.

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

gcc/ada/

* sem_prag.adb (Check_Mode_Restriction_In_Enclosing_Context):
Apply the rule even with no explicit Global contract (and remove
a dead condition for Refined_Global).diff --git a/gcc/ada/sem_prag.adb b/gcc/ada/sem_prag.adb
--- a/gcc/ada/sem_prag.adb
+++ b/gcc/ada/sem_prag.adb
@@ -2634,13 +2634,9 @@ package body Sem_Prag is
   Context := Anonymous_Object (Context);
end if;
 
-   if (Is_Subprogram_Or_Entry (Context)
- or else Ekind (Context) = E_Task_Type
- or else Is_Single_Task_Object (Context))
- and then
-  (Present (Get_Pragma (Context, Pragma_Global))
- or else
-   Present (Get_Pragma (Context, Pragma_Refined_Global)))
+   if Is_Subprogram_Or_Entry (Context)
+ or else Ekind (Context) = E_Task_Type
+ or else Is_Single_Task_Object (Context)
then
   Collect_Subprogram_Inputs_Outputs
 (Subp_Id  => Context,
@@ -2649,8 +2645,8 @@ package body Sem_Prag is
  Global_Seen  => Dummy);
 
   --  The item is classified as In_Out or Output but appears as
-  --  an Input in an enclosing subprogram or task unit (SPARK
-  --  RM 6.1.4(13)).
+  --  an Input or a formal parameter of mode IN in an enclosing
+  --  subprogram or task unit (SPARK RM 6.1.4(13)).
 
   if Appears_In (Inputs, Item_Id)
 and then not Appears_In (Outputs, Item_Id)

[Ada] Reject constants of access-to-variable type as function globals

[Pierre-Marie de Rodat]

Constants of an access-to-variable type can only appear as global
outputs in procedures, tasks and protected entries, not in functions.

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

gcc/ada/

* sem_prag.adb (Analyze_Global_Item): Take subprogram kind into
account when accepting or rejecting a constant of an
access-to-variable type as a global Output/In_Out; do this check
inside an ELSIF branch to avoid unnecessary evaluation of the
subsequent condition.diff --git a/gcc/ada/sem_prag.adb b/gcc/ada/sem_prag.adb
--- a/gcc/ada/sem_prag.adb
+++ b/gcc/ada/sem_prag.adb
@@ -2450,17 +2450,31 @@ package body Sem_Prag is
 
--  Constant related checks
 
-   elsif Ekind (Item_Id) = E_Constant
- and then not Is_Access_Type (Etype (Item_Id))
-   then
+   elsif Ekind (Item_Id) = E_Constant then
 
-  --  Unless it is of an access type, a constant is a read-only
-  --  item, therefore it cannot act as an output.
+  --  Constant is a read-only item, therefore it cannot act as
+  --  an output.
 
   if Global_Mode in Name_In_Out | Name_Output then
- SPARK_Msg_NE
-   ("constant & cannot act as output", Item, Item_Id);
- return;
+
+ --  Constant of a access-to-variable type is a read-write
+ --  item in procedures, generic procedures, protected
+ --  entries and tasks.
+
+ if Is_Access_Variable (Etype (Item_Id))
+   and then (Ekind (Spec_Id) in E_Entry
+  | E_Entry_Family
+  | E_Procedure
+  | E_Generic_Procedure
+  | E_Task_Type
+ or else Is_Single_Task_Object (Spec_Id))
+ then
+null;
+ else
+SPARK_Msg_NE
+  ("constant & cannot act as output", Item, Item_Id);
+return;
+ end if;
   end if;
 
--  Loop parameter related checks

[Ada] Check entries for formals of mode IN appearing as global outputs

[Pierre-Marie de Rodat]

Rule SPARK RM 6.1.4(13) only mentions "subprograms", but it is equally
applicable to protected entries whose global inputs cannot appear as
global outputs in nested subprograms.

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

gcc/ada/

* sem_prag.adb (Check_Mode_Restriction_In_Enclosing_Context):
Extend check to protected entries.diff --git a/gcc/ada/sem_prag.adb b/gcc/ada/sem_prag.adb
--- a/gcc/ada/sem_prag.adb
+++ b/gcc/ada/sem_prag.adb
@@ -2634,7 +2634,7 @@ package body Sem_Prag is
   Context := Anonymous_Object (Context);
end if;
 
-   if (Is_Subprogram (Context)
+   if (Is_Subprogram_Or_Entry (Context)
  or else Ekind (Context) = E_Task_Type
  or else Is_Single_Task_Object (Context))
  and then
@@ -2659,7 +2659,7 @@ package body Sem_Prag is
("global item & cannot have mode In_Out or Output",
 Item, Item_Id);
 
- if Is_Subprogram (Context) then
+ if Is_Subprogram_Or_Entry (Context) then
 SPARK_Msg_NE
   (Fix_Msg (Subp_Id, "\item already appears as input "
& "of subprogram &"), Item, Context);

[Ada] Fix inconsistent handling of character set control switches

[Pierre-Marie de Rodat]

Switch -gnatic, where "c" denotes a character set, is described in the
GNAT User's Guide sections 4.3.11 Character Set Control and 4.3.1
Alphabetical List of All Switches, but the latter section didn't mention
'5' as an allowed value for "c".

This is implemented in csets.adb, switch-c.adb (for the frontend) and
switch-b.adb (for the binder), but the binder didn't support '9' as the
value for "c".

Now both documentation and code deals with all allowed character sets.

Found while refactoring repeated expressions in OR ELSE operands.

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

gcc/ada/

* csets.adb (Initialize): Refactor into CASE statement; raise
exception on unsupported code of character set (it will be
gently rejected earlier when scanning command line switches).
* switch-b.adb (Scan_Binder_Switches): Refactor into a
membership expression; add missing '9' choice; reorder as
described by GNAT UG, section 4.3.11.
* switch-c.adb (Scan_Front_End_Switches): Refactor into a
membership expression and reorder as above.
* doc/gnat_ugn/building_executable_programs_with_gnat.rst
(gnatic): Mention '5' as an allowed value for "c".
* gnat_ugn.texi: Regenerate.diff --git a/gcc/ada/csets.adb b/gcc/ada/csets.adb
--- a/gcc/ada/csets.adb
+++ b/gcc/ada/csets.adb
@@ -1091,38 +1091,40 @@ package body Csets is
begin
   --  Set Fold_Upper table from source code indication
 
-  if Identifier_Character_Set = '1'
-or else Identifier_Character_Set = 'w'
-  then
- Fold_Upper := Fold_Latin_1;
+  case Identifier_Character_Set is
+ when '1' | 'w' =>
+Fold_Upper := Fold_Latin_1;
 
-  elsif Identifier_Character_Set = '2' then
- Fold_Upper := Fold_Latin_2;
+ when '2' =>
+Fold_Upper := Fold_Latin_2;
 
-  elsif Identifier_Character_Set = '3' then
- Fold_Upper := Fold_Latin_3;
+ when '3' =>
+Fold_Upper := Fold_Latin_3;
 
-  elsif Identifier_Character_Set = '4' then
- Fold_Upper := Fold_Latin_4;
+ when '4' =>
+Fold_Upper := Fold_Latin_4;
 
-  elsif Identifier_Character_Set = '5' then
- Fold_Upper := Fold_Cyrillic;
+ when '5' =>
+Fold_Upper := Fold_Cyrillic;
 
-  elsif Identifier_Character_Set = 'p' then
- Fold_Upper := Fold_IBM_PC_437;
+ when '9' =>
+Fold_Upper := Fold_Latin_9;
 
-  elsif Identifier_Character_Set = '8' then
- Fold_Upper := Fold_IBM_PC_850;
+ when 'p' =>
+Fold_Upper := Fold_IBM_PC_437;
 
-  elsif Identifier_Character_Set = '9' then
- Fold_Upper := Fold_Latin_9;
+ when '8' =>
+Fold_Upper := Fold_IBM_PC_850;
 
-  elsif Identifier_Character_Set = 'f' then
- Fold_Upper := Fold_Full_Upper_Half;
+ when 'f' =>
+Fold_Upper := Fold_Full_Upper_Half;
 
-  else -- Identifier_Character_Set = 'n'
- Fold_Upper := Fold_No_Upper_Half;
-  end if;
+ when 'n' =>
+Fold_Upper := Fold_No_Upper_Half;
+
+ when others =>
+raise Program_Error;
+  end case;
 
   --  Use Fold_Upper table to compute Fold_Lower table
 


diff --git a/gcc/ada/doc/gnat_ugn/building_executable_programs_with_gnat.rst b/gcc/ada/doc/gnat_ugn/building_executable_programs_with_gnat.rst
--- a/gcc/ada/doc/gnat_ugn/building_executable_programs_with_gnat.rst
+++ b/gcc/ada/doc/gnat_ugn/building_executable_programs_with_gnat.rst
@@ -1896,7 +1896,7 @@ Alphabetical List of All Switches
 .. index:: -gnati  (gcc)
 
 :switch:`-gnati{c}`
-  Identifier character set (``c`` = 1/2/3/4/8/9/p/f/n/w).
+  Identifier character set (``c`` = 1/2/3/4/5/9/p/8/f/n/w).
   For details of the possible selections for ``c``,
   see :ref:`Character_Set_Control`.
 


diff --git a/gcc/ada/gnat_ugn.texi b/gcc/ada/gnat_ugn.texi
--- a/gcc/ada/gnat_ugn.texi
+++ b/gcc/ada/gnat_ugn.texi
@@ -21,7 +21,7 @@
 
 @copying
 @quotation
-GNAT User's Guide for Native Platforms , Dec 11, 2020
+GNAT User's Guide for Native Platforms , Apr 12, 2021
 
 AdaCore
 
@@ -9462,7 +9462,7 @@ For further details see @ref{f,,Elaboration Order Handling in GNAT}.
 
 @item @code{-gnati@emph{c}}
 
-Identifier character set (@code{c} = 1/2/3/4/8/9/p/f/n/w).
+Identifier character set (@code{c} = 1/2/3/4/5/9/p/8/f/n/w).
 For details of the possible selections for @code{c},
 see @ref{31,,Character Set Control}.
 @end table


diff --git a/gcc/ada/switch-b.adb b/gcc/ada/switch-b.adb
--- a/gcc/ada/switch-b.adb
+++ b/gcc/ada/switch-b.adb
@@ -369,13 +369,7 @@ package body Switch.B is
 Ptr := Ptr + 1;
 C := Switch_Chars (Ptr);
 
-if C in '1' .. '5'
-  or else C = '8'
-  or else C = 'p'
-  or else C = 'f'
-  or else C = 'n'
-  or else C = 'w'
-then
+if C in '1' .. '5' | '9' | 

[Ada] Preliminary cleanup in floating-point output implementation

[Pierre-Marie de Rodat]

This moves the low-level processing on characters to the package
Img_Util, factors out common processing with fixed point, and overhauls
the handling of negative zeros and rounding.  This also removes the
Is_Negative intrinsic function, which was only accessible from
predefined units and is now unused.

No functional changes.

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

gcc/ada/

* exp_intr.adb: Remove with/use clauses for Urealp.
(Expand_Is_Negative): Delete.
(Expand_Intrinsic_Call): Do not call it.
* rtsfind.ads (RE_Id): Remove RE_Float_Unsigned.
(RE_Unit_Table): Remove entry for RE_Float_Unsigned.
* snames.ads-tmpl (Name_Is_Negative): Delete.
* libgnat/s-imgrea.ads (Set_Image_Real): Fix mode of S parameter.
* libgnat/s-imgrea.adb: Add with/use clauses for System.Img_Util.
(LLU): New subtype.
(Maxdigs): Use it.
(Is_Negative): Reimplement.
(Image_Floating_Point): Simplify.
(Set_Image_Real): Fix mode of S parameter.  Remove the low-level
processing on characters.  Flip the sign of the Scale variable.
Compute the maximum number of digits for the straight notation.
Call Set_Decimal_Digits at the end to do the final formatting.
* libgnat/s-imguti.ads (Floating_Invalid_Value): New type.
(Set_Floating_Invalid_Value): New procedure.
* libgnat/s-imguti.adb (Set_Floating_Invalid_Value): Implement it
based on existing code from Set_Image_Real.
* libgnat/s-unstyp.ads (Float_Unsigned): Delete.

patch.diff.gz
Description: application/gzip

[Ada] Wrong membership test computation for interface type

[Pierre-Marie de Rodat]

When the left expression of a membership test is an object implementing
an interface type, and the right operand of such membership test is a
non-class wide interface type, the compiler generates code that, instead
of comparing the actual tag of the left expression to the tag of the
right operand, erroneously generates a runtime call to the function
IW_Membership test.

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

gcc/ada/

* exp_ch4.adb (Tagged_Membership): Remove wrong condition that
is not consistent with the documentation of this subprogram.diff --git a/gcc/ada/exp_ch4.adb b/gcc/ada/exp_ch4.adb
--- a/gcc/ada/exp_ch4.adb
+++ b/gcc/ada/exp_ch4.adb
@@ -15284,7 +15284,7 @@ package body Exp_Ch4 is
   Selector_Name =>
 New_Occurrence_Of (First_Tag_Component (Left_Type), Loc));
 
-  if Is_Class_Wide_Type (Right_Type) or else Is_Interface (Left_Type) then
+  if Is_Class_Wide_Type (Right_Type) then
 
  --  No need to issue a run-time check if we statically know that the
  --  result of this membership test is always true. For example,

[Ada] Guard against leading and trailing spaces reappearing in errors

[Pierre-Marie de Rodat]

The leading and trailing spaces in error message strings have been
recently removed. This patch adds an assertion to prevent those spaces
from appearing again.

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

gcc/ada/

* errout.adb (Error_Msg_Internal): Add assertion to prevent
style mistakes reappearing in the future.diff --git a/gcc/ada/errout.adb b/gcc/ada/errout.adb
--- a/gcc/ada/errout.adb
+++ b/gcc/ada/errout.adb
@@ -952,6 +952,11 @@ package body Errout is
--  Start of processing for Error_Msg_Internal
 
begin
+  --  Detect common mistake of prefixing or suffing the message with a
+  --  space character.
+
+  pragma Assert (Msg (Msg'First) /= ' ' and then Msg (Msg'Last) /= ' ');
+
   if Raise_Exception_On_Error /= 0 then
  raise Error_Msg_Exception;
   end if;

[Ada] Fix reference to SPARK RM rule in comment

[Pierre-Marie de Rodat]

Adding rule about a user-defined equality operation as SPARK RM
6.1.4(11) is changing the numeration of previous rules (11,12).

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

gcc/ada/

* sem_prag.adb (Check_Mode_Restriction_In_Enclosing_Context):
Fix reference to SPARK RM rule number.diff --git a/gcc/ada/sem_prag.adb b/gcc/ada/sem_prag.adb
--- a/gcc/ada/sem_prag.adb
+++ b/gcc/ada/sem_prag.adb
@@ -2650,7 +2650,7 @@ package body Sem_Prag is
 
   --  The item is classified as In_Out or Output but appears as
   --  an Input in an enclosing subprogram or task unit (SPARK
-  --  RM 6.1.4(12)).
+  --  RM 6.1.4(13)).
 
   if Appears_In (Inputs, Item_Id)
 and then not Appears_In (Outputs, Item_Id)

Re: [PATCH] Avoid DSE/DCE of pure call that throws

[Eric Botcazou]

> Do you have extra fixes in your tree or does -fnon-call-exceptions
> somehow magically paper over the issue?

This optimization is valid in Ada for pure functions.  RM 10.2.1(18/3) says:
"If a library unit is declared pure, then the implementation is permitted to 
omit a call on a library-level subprogram of the library unit if the results 
are not needed after the call.(...)[This permission applies even if the 
subprogram produces other side effects when called.]".

> I suppose if the C or C++ frontends like to have pure/const attributed
> functions not throw they could mark functions accordingly themselves.
> 
> Which also means, the Ada functions are DECL_PURE_P but not 'pure'
> according to the extend.texi documentation of the user-visible
> attribute?  That said, I think if my C++ testcase is valid then we
> should amend this documentation (or if not then as well, to not
> re-iterate this every N years).  Do you agree?

Yes, the documentation was written without considering other languages with 
exception handling, but it's originally an extension of the C language and 
documented in the manual of the C compiler, so that's not very surprising.

Pure Ada functions are "const" in the GNU C sense if all their parameters are 
passed by copy and "pure" in the GNU  C sense if their parameters not passed 
by value (i.e. by reference) are In parameters; in all the other cases, pure 
Ada functions are neither "const" nor "pure" in the GNU C sense.

I think that we need to add an explicit sentence about exception handling to 
the declaration of DECL_PURE_P:

/* Nonzero in a FUNCTION_DECL means this function should be treated
   as "pure" function (like const function, but may read global memory).  */
#define DECL_PURE_P(NODE) (FUNCTION_DECL_CHECK (NODE)>function_decl.pure_flag)

Maybe: "Note that being pure or const for a function is orthogonal to being 
no-throw, i.e. it is valid to have DECL_PURE_P set and TREE_NOTHROW cleared".

-- 
Eric Botcazou

Re: [PATCH] phiopt: Optimize (x <=> y) cmp z [PR94589]

[Jonathan Wakely via Gcc-patches]

On 04/05/21 09:44 +0200, Jakub Jelinek wrote:

Hi!

genericize_spaceship genericizes i <=> j to approximately
({ int c; if (i == j) c = 0; else if (i < j) c = -1; else c = 1; c; })
for strong ordering and
({ int c; if (i == j) c = 0; else if (i < j) c = -1; else if (i > j) c = 1; 
else c = 2; c; })
for partial ordering.
The C++ standard supports then == or != comparisons of that against
strong/partial ordering enums, or />= comparisons of <=> result
against literal 0.

In some cases we already optimize that but in many cases we keep performing
all the 2 or 3 comparisons, compute the spaceship value and then compare
that.

The following patch recognizes those patterns if the <=> operands are
integral types or floating point (the latter only for -ffast-math) and
optimizes it to the single comparison that is needed (plus adds debug stmts
if needed for the spaceship result).

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

There are two things I'd like to address in a follow-up:
1) if (HONOR_NANS (TREE_TYPE (lhs1)) || HONOR_SIGNED_ZEROS (TREE_TYPE (lhs1)))
is what I've copied from elsewhere in phiopt, but thinking about it,
alll we care is probably only HONOR_NANS, the matched pattern starts with
== or != comparison and branches to the PHI bb with -1/0/1/2 result if it is
equal, which should be the case for signed zero differences.
2) the pr94589-2.C testcase should be matching just 12 times each, but runs
into operator>=(strong_ordering, unspecified) being defined as


Should this say s/strong/partial/  ?

[PATCH] Restrict gcc.dg/tree-ssa/ssa-dse-26.c

[Richard Biener]

This restricts the testcase to the target where it exposes the
situation fixed with g:e9d297a15d68121ba5bdd5a76ea71c1916180622
which targets BIT_FIELD_REFs created by fold_truth_andor.

This avoids strange dejagnu limits with overly long target lists
and simplifies the tests.

Tested on x86_64-unknown-linux-gnu where it failed with -m32
and is now skipped there.

Will push soon.

2021-05-04  Richard Biener  

* gcc.dg/tree-ssa/ssa-dse-26.c: Skip on !lp64 targets,
simplify dump scanning down to one case.
---
 gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-26.c | 19 +++
 1 file changed, 3 insertions(+), 16 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-26.c 
b/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-26.c
index 4011daf5a59..5eabfb464d3 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-26.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-26.c
@@ -1,6 +1,6 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -fdump-tree-dse1-details -fno-short-enums -fno-tree-fre" 
} */
-/* { dg-skip-if "temporary variable for constraint_expr is never used" { 
msp430-*-* } } */
+/* { dg-skip-if "we want a BIT_FIELD_REF from fold_truth_andor" { ! lp64 } } */
 
 enum constraint_expr_type
 {
@@ -30,18 +30,5 @@ constraint_equal (struct constraint a, struct constraint b)
 && constraint_expr_equal (a.rhs, b.rhs);
 }
 
-/* Most targets should be using this test.  */
-/* { dg-final { scan-tree-dump-times "Deleted dead store: x = " 1 "dse1" { 
target { ! { tic6x-*-* mmix-knuth-mmixware cr16*-*-* xstormy16*-*-* or1k*-*-* 
lm32*-*-* bfin*-*-* m32r*-*-* nds32le-elf rx*-*-* } } } } } */
-/* { dg-final { scan-tree-dump-times "Deleted dead store: y = " 1 "dse1" { 
target { ! { tic6x-*-* mmix-knuth-mmixware cr16*-*-* xstormy16*-*-* or1k*-*-* 
bfin*-*-* lm32*-*-* m32r*-*-* nds32le-elf rx*-*-* } } } } } */
-
-/* The c6x port generates significantly different gimple which
-   changes the SRA and DSE decisions.   Verify we remove all
-   dead stores.  Similarly for mmix.  */
-/* { dg-final { scan-tree-dump-times "Deleted dead store: \[ax\].. = " 2 
"dse1" { target tic6x-*-* } } } */
-/* { dg-final { scan-tree-dump-times "Deleted dead store: \[by\].. = " 2 
"dse1" { target tic6x-*-* } } } */
-/* { dg-final { scan-tree-dump-times "Deleted dead store: x::. = " 1 "dse1" { 
target mmix-knuth-mmixware } } } */
-/* { dg-final { scan-tree-dump-times "Deleted dead store: y::. = " 1 "dse1" { 
target mmix-knuth-mmixware } } } */
-
-/* And more special cases
-/* { dg-final { scan-tree-dump-times "Deleted dead store: x = " 2 "dse1" { 
target cr16*-*-* xstormy16*-*-* or1k*-*-* bfin*-*-* lm32*-*-* m32r*-*-* 
nds32le-elf rx*-*-* } } } */
-/* { dg-final { scan-tree-dump-times "Deleted dead store: y = " 2 "dse1" { 
target cr16*-*-* xstormy16*-*-* or1k*-*-* bfin*-*-* lm32*-*-* m32r*-*-* 
nds32le-elf rx*-*-* } } } */
+/* { dg-final { scan-tree-dump-times "Deleted dead store: x = " 1 "dse1" } } */
+/* { dg-final { scan-tree-dump-times "Deleted dead store: y = " 1 "dse1" } } */
-- 
2.26.2