Re: [PATCH] alias: Fix offset checks involving section anchors [PR92294]

[Richard Biener]

On Wed, Feb 19, 2020 at 4:12 PM Richard Sandiford
 wrote:
>
> Richard Biener  writes:
> > On Wed, Feb 19, 2020 at 1:19 PM Richard Sandiford
> >  wrote:
> >>
> >> What should we do about this?  The PR is a wrong-code regression from
> >> GCC 9 and it doesn't look like we can remove the second offset_overlap_p
> >> check, given how many cases currently rely on it.
> >
> > Did you check whether we eventually disambiguate those via 
> > rtx_refs_may_alias_p
> > (so using MEM_EXPR)?  I would guess all but those that have no MEM_EXPR?
>
> Good point, I should have checked that.
>
> Here are the numbers after excluding cases that
> mems_in_disjoint_alias_sets_p, nonoverlapping_memrefs_p and
> rtx_refs_may_alias_p would disambiguate later.  This time I didn't
> divide based on false/true, just based on the path taken:
>
>   cmp == 1, overlap:: 66.72%
>   cmp == 1, no overlap  :  6.51%
>   cmp == -1, overlap:  0.06%
>   cmp == -1. no overlap : 26.71% <--- the number that matters
>
> The number of cases being disambiguated only by this function seems
> surprisingly high.  Maybe that's a sign that we're losing too much
> information somewhere?  Or maybe it's rtl constants vs. other stuff.

No idea - you could print the rtxen involved to a temporary file and
look at them...
when I did that other statistic most cases were from postreload DSE
(which does O(n^2)
disambiguations...) against stack slots.

>From what I've seen we're definitely eager to drop MEM_EXPR and lack
handling of late allocated stack space there.

> > Ideally we'd rely more on MEM_EXPR for alias disambiguation than the ad-hoc
> > ways of recovering "details" from the actual MEM.
>
> Yeah, agreed.
>
> Thanks,
> Richard

Re: [PATCH 1/2] libstdc++: Forward second argument of views::iota using the correct type

[Jonathan Wakely]

On 19/02/20 23:53 -0500, Patrick Palka wrote:

We are forwarding the second argument of views::iota using the wrong type,
causing compiling errors when calling it with a value and bound of different
types, like in the test case below.


Good catch, OK for master.

Re: [PATCH 2/2] libstdc++: P1739R4 Avoid template bloat for safe_ranges in combination with ...

[Jonathan Wakely]

On 19/02/20 23:53 -0500, Patrick Palka wrote:

... 'subrange-y' view adaptors

This implements an interpretation of P1739R4.  It's only an "interpretation"
becuase AFAICT there is an issue with the paper's wording as-is.  So this patch
deviates from paper when it comes to the problematic wording.

The issue is that the paper's wording for views::take requires that the
views::take of a specialization of subrange is not just another subrange, but
specifically is the same specialization as the input subrange.
But if, say, the input subrange does not model common_range, then the expression
in section 6.1

   T{begin(E), begin(E) + min(size(E), F)}

is ill-formed because T -- a specialization of subrange which does not model
common_range -- must be constructed with an iterator-sentinel pair and not an
iterator-iterator pair.  A similar issue arises with the views::take of an
iota_view whose value type differs from the type of its bound.

So in light of this issue, this patch deviates from the paper's wording here by
allowing the views::take of a subrange/iota_view input to be a different
specialization than that of the input.

Moreover, I found myself needing to define an extra constrained constructor
iota_view(iterator_, iterator_) alongside the newly added
iota_view(iterator_, sentinel_) constructor, so that the expression
in views::take

   iota_view{begin(E), begin(E) + min(size(E), F)}

is well-formed in general.  Despite these deviations, the intended end result
remains the same AFAICT.


Please be sure to report these to the LWG chair address so issues can
be opened.


@@ -1965,10 +1993,70 @@ namespace views

  namespace views
  {
+namespace __detail
+{
+  template
+   inline constexpr bool __is_empty_view = false;
+
+  template
+   inline constexpr bool __is_empty_view> = true;
+
+  template
+   inline constexpr bool __is_dynamic_span = false;
+
+  template
+   inline constexpr bool __is_dynamic_span>
+ = true;
+
+  template
+   inline constexpr bool __is_basic_string_view = false;
+
+  template
+   inline constexpr bool
+ __is_basic_string_view> = true;


I think it should be possible to define these without including 
and . Either by adding forward declarations of span and
basic_string_view, which is sufficient to define the variable template
specializations, or by defining something here and specializing it in
 and  e.g. in :

  template
inline constexpr bool __is_viewish = false;

And then in  add:

  template
extern inline const bool __is_viewish;
  template
inline constexpr bool __is_viewish> = true;

The first declaration is needed so that  works without including
, and vice versa.

And in :

#if __cplusplus > 201703L
  template
extern inline const bool __is_viewish;
  template
inline constexpr bool __is_viewish>
  = true;
#endif

That way we don't need to declare span and string_view in  at
all. We also don't need two separate variables, one will do. And
finally, doing it this way allows us to enable this feature for
experimental::basic_string_view too:

And in :

#if __cplusplus > 201703L
  template
extern inline const bool __is_viewish;
  template
inline constexpr bool
  __is_viewish> = true;
#endif

This last specialization *must* be defined in
 not in , because we don't want to
"leak" the non-reserved "experimental" name into  when the
user hasn't explicitly included a TS header.

A better name than "viewish" would be nice, but it does look like we
can use the same one for span and string_view, since you always treat
them the same.



+
+  template
+   inline constexpr bool __is_iota_view = false;
+
+  template
+   inline constexpr bool __is_iota_view> = true;
+
+  template
+   inline constexpr bool __is_subrange = false;
+
+  template
+   inline constexpr bool
+ __is_subrange> = true;
+}
+
inline constexpr __adaptor::_RangeAdaptor take
-  = []  (_Range&& __r, _Tp&& __n)
+  = []  (_Range&& __r, range_difference_t<_Range> 
__n)
  {
-   return take_view{std::forward<_Range>(__r), std::forward<_Tp>(__n)};
+   using _Tp = remove_cvref_t<_Range>;
+   if constexpr (__detail::__is_empty_view<_Tp>)
+ return std::forward<_Range>(__r);
+   else if constexpr (random_access_range<_Tp> && sized_range<_Tp>)
+ {
+   // XXX: we diverge from P1739R4 here in the way we fold iota_view
+   // and subrange.
+   auto __begin = ranges::begin(__r);
+   auto __size = std::min(ranges::size(__r), __n);
+   if constexpr (__detail::__is_dynamic_span<_Tp>
+ || __detail::__is_basic_string_view<_Tp>)
+ return _Tp{__begin, __begin + __size};
+   else if constexpr (__detail::__is_iota_view<_Tp>)
+ {
+   using _ValueType = range_value_t<_Tp>;
+   return iota_view<_ValueType, _ValueType>{__begin,
+  

[PATCH] Fix error message for Darwin.

[Martin Liška]

Hi.

It's one obvious documentation fix that I'm going to install.

Martin

gcc/ChangeLog:

2020-02-20  Martin Liska  

PR translation/93831
* config/darwin.c (darwin_override_options): Change 64b to 64-bit mode.
---
 gcc/config/darwin.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)


diff --git a/gcc/config/darwin.c b/gcc/config/darwin.c
index e7892617d9d..8131361715b 100644
--- a/gcc/config/darwin.c
+++ b/gcc/config/darwin.c
@@ -3302,7 +3302,8 @@ darwin_override_options (void)
   else if (DARWIN_X86 && darwin_symbol_stubs && TARGET_64BIT)
 {
   inform (input_location,
-	  "%<-mpic-symbol-stubs%> is not required for 64b code (ignored)");
+	  "%<-mpic-symbol-stubs%> is not required for 64-bit code "
+	  "(ignored)");
   darwin_symbol_stubs = false;
 }
 

[PATCH] Remove trailing | in help message.

[Martin Liška]

Hi.

It's one obvious documentation fix that I'm going to install.

Martin

gcc/ChangeLog:

2020-02-20  Martin Liska  

PR translation/93830
* common/config/avr/avr-common.c: Remote trailing "|".
---
 gcc/common/config/avr/avr-common.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)


diff --git a/gcc/common/config/avr/avr-common.c b/gcc/common/config/avr/avr-common.c
index 233468be421..712b8cf5626 100644
--- a/gcc/common/config/avr/avr-common.c
+++ b/gcc/common/config/avr/avr-common.c
@@ -96,7 +96,7 @@ avr_handle_option (struct gcc_options *opts, struct gcc_options*,
 {
 #if !defined (HAVE_DOUBLE32)
   error_at (loc, "option %<-mdouble=32%> is only available if "
-"configured %<--with-double={|32|32,64|64,32}%>");
+"configured %<--with-double={32|32,64|64,32}%>");
 #endif
 }
   else
@@ -121,9 +121,9 @@ avr_handle_option (struct gcc_options *opts, struct gcc_options*,
 {
 #if !defined (HAVE_LONG_DOUBLE32)
   error_at (loc, "option %<-mlong-double=32%> is only available if "
-"configured %<--with-long-double={|32|32,64|64,32}%>, "
+"configured %<--with-long-double={32|32,64|64,32}%>, "
 "or %<--with-long-double=double%> together with "
-"%<--with-double={|32|32,64|64,32}%>");
+"%<--with-double={32|32,64|64,32}%>");
 #endif
   opts->x_avr_double = 32;
 }

[PATCH] Remove triling space for a warning.

[Martin Liška]

Hi.

It's one obvious warning message fix that I'm going to install.

Martin

gcc/cp/ChangeLog:

2020-02-20  Martin Liska  

PR translation/93838
* parser.c (cp_parser_decl_specifier_seq): Remove trailing space.
---
 gcc/cp/parser.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index e8a536ae22f..46841344831 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -14164,7 +14164,7 @@ cp_parser_decl_specifier_seq (cp_parser* parser,
 			 "allowed in a C++20 concept definition");
 	  else
 		pedwarn (token->location, 0, "C++20 concept definition syntax "
-			 "is % = %> ");
+			 "is % = %>");
 }
 
 	  /* In C++20 a concept definition is just 'concept name = expr;'

[PATCH] Remove superfluous word in documentation.

[Martin Liška]

Hi.

It's one obvious documentation fix that I'm going to install.

Martin

gcc/cp/ChangeLog:

2020-02-20  Martin Liska  

PR translation/93841
* config/or1k/or1k.opt: Remove superfluous word.
* doc/invoke.texi: Likewise.
---
 gcc/config/or1k/or1k.opt | 2 +-
 gcc/doc/invoke.texi  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)


diff --git a/gcc/config/or1k/or1k.opt b/gcc/config/or1k/or1k.opt
index 2da978b84e9..03c9b8d0bba 100644
--- a/gcc/config/or1k/or1k.opt
+++ b/gcc/config/or1k/or1k.opt
@@ -66,7 +66,7 @@ are used to perform unordered floating point compare and set flag operations.
 mcmov
 Target RejectNegative Mask(CMOV)
 Enable generation of conditional move (l.cmov) instructions.  By default the
-equivalent will be generated using using set and branch.
+equivalent will be generated using set and branch.
 
 mror
 Target RejectNegative Mask(ROR)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index ba2b7e42520..54017dfce8f 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -24907,7 +24907,7 @@ compare and set flag operations.
 @item -mcmov
 @opindex mcmov
 Enable generation of conditional move (@code{l.cmov}) instructions.  By
-default the equivalent will be generated using using set and branch.
+default the equivalent will be generated using set and branch.
 
 @item -mror
 @opindex mror

[PATCH] libstdc++: Add <=> to thread::id

[Jonathan Wakely]

* include/std/thread (thread::id::operator<=>): Define for C++20.
* testsuite/30_threads/thread/id/70294.cc: Do not take addresses of
functions in namespace std.
* testsuite/30_threads/thread/id/operators_c++20.cc: New test.

This is a small part of P1614R2. Tested powerpc64le-linux, committed
to master.

commit c7b591f3868f778ce89b14cbfb81d8e96d0daad2
Author: Jonathan Wakely 
Date:   Fri Feb 7 20:28:06 2020 +

libstdc++: Add <=> to thread::id

* include/std/thread (thread::id::operator<=>): Define for C++20.
* testsuite/30_threads/thread/id/70294.cc: Do not take addresses of
functions in namespace std.
* testsuite/30_threads/thread/id/operators_c++20.cc: New test.

diff --git a/libstdc++-v3/include/std/thread b/libstdc++-v3/include/std/thread
index b533bca578f..1f9c13ff7d1 100644
--- a/libstdc++-v3/include/std/thread
+++ b/libstdc++-v3/include/std/thread
@@ -45,7 +45,8 @@
 #include   // std::tuple
 
 #if __cplusplus > 201703L
-# include  // std::stop_source, std::stop_token, std::nostopstate
+# include // std::strong_ordering
+# include  // std::stop_source, std::stop_token, std::nostopstate
 #endif
 
 #ifdef _GLIBCXX_USE_NANOSLEEP
@@ -96,17 +97,22 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
 private:
   friend class thread;
-  friend class hash;
+  friend class hash;
 
   friend bool
-  operator==(thread::id __x, thread::id __y) noexcept;
+  operator==(id __x, id __y) noexcept;
 
+#if __cpp_lib_three_way_comparison
+  friend strong_ordering
+  operator<=>(id __x, id __y) noexcept;
+#else
   friend bool
-  operator<(thread::id __x, thread::id __y) noexcept;
+  operator<(id __x, id __y) noexcept;
+#endif
 
   template
friend basic_ostream<_CharT, _Traits>&
-   operator<<(basic_ostream<_CharT, _Traits>& __out, thread::id __id);
+   operator<<(basic_ostream<_CharT, _Traits>& __out, id __id);
 };
 
   private:
@@ -180,7 +186,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 void
 detach();
 
-thread::id
+id
 get_id() const noexcept
 { return _M_id; }
 
@@ -296,6 +302,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 return __x._M_thread == __y._M_thread;
   }
 
+#if __cpp_lib_three_way_comparison
+  inline strong_ordering
+  operator<=>(thread::id __x, thread::id __y) noexcept
+  { return __x._M_thread <=> __y._M_thread; }
+#else
   inline bool
   operator!=(thread::id __x, thread::id __y) noexcept
   { return !(__x == __y); }
@@ -319,6 +330,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   inline bool
   operator>=(thread::id __x, thread::id __y) noexcept
   { return !(__x < __y); }
+#endif // __cpp_lib_three_way_comparison
 
   // DR 889.
   /// std::hash specialization for thread::id.
@@ -424,8 +436,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   class jthread
   {
   public:
-using id = std::thread::id;
-using native_handle_type = std::thread::native_handle_type;
+using id = thread::id;
+using native_handle_type = thread::native_handle_type;
 
 jthread() noexcept
 : _M_stop_source{nostopstate}
@@ -498,7 +510,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 [[nodiscard]] static unsigned
 hardware_concurrency() noexcept
 {
-  return std::thread::hardware_concurrency();
+  return thread::hardware_concurrency();
 }
 
 [[nodiscard]] stop_source
@@ -544,7 +556,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   }
 
 stop_source _M_stop_source;
-std::thread _M_thread;
+thread _M_thread;
   };
 #endif // __cpp_lib_jthread
 _GLIBCXX_END_NAMESPACE_VERSION
diff --git a/libstdc++-v3/testsuite/30_threads/thread/id/70294.cc 
b/libstdc++-v3/testsuite/30_threads/thread/id/70294.cc
index ac3b58afa75..d9c61f74351 100644
--- a/libstdc++-v3/testsuite/30_threads/thread/id/70294.cc
+++ b/libstdc++-v3/testsuite/30_threads/thread/id/70294.cc
@@ -19,5 +19,14 @@
 
 #include 
 
-bool (*lt)(std::thread::id, std::thread::id) = &std::operator<;
-bool (*eq)(std::thread::id, std::thread::id) = &std::operator==;
+struct T
+{
+  operator std::thread::id() const;
+} const t;
+
+using namespace std;
+
+// std::thread::id comparison operators are not hidden friends,
+// so should be candidates for these expressions:
+bool lt = t < t;
+bool eq = t == t;
diff --git a/libstdc++-v3/testsuite/30_threads/thread/id/operators.cc 
b/libstdc++-v3/testsuite/30_threads/thread/id/operators.cc
index fb6440bfc3d..3d84afafd15 100644
--- a/libstdc++-v3/testsuite/30_threads/thread/id/operators.cc
+++ b/libstdc++-v3/testsuite/30_threads/thread/id/operators.cc
@@ -20,16 +20,26 @@
 
 #include 
 
+template
+  struct check_type
+  : std::false_type
+  { };
+
+template
+  struct check_type
+  : std::true_type
+  { };
+
 void test01()
 {
   // thread::id operators
   std::thread::id id1;
   std::thread::id id2;
 
-  id1 == id2;
-  id1 != id2;
-  id1 < id2;
-  id1 > id2;
-  id1 >= id2;
-  id1 <= id2;
+  static_assert( check_type{} );
+  static_assert( check_type{} );
+  

[committed] Remove std::type_info::operator!= for C++20

[Jonathan Wakely]

This is an even smaller part of P1614R2.

Tested powerpc64le-linux, committed to master.


commit 20fa41e61fd2d2839ca47e0dfac6976c552ab648
Author: Jonathan Wakely 
Date:   Fri Feb 7 20:50:00 2020 +

libstdc++: Remove std::type_info::operator!= for C++20

This function can be synthesized by the compiler now.

* libsupc++/typeinfo (type_info::operator!=): Remove for C++20.

diff --git a/libstdc++-v3/libsupc++/typeinfo b/libstdc++-v3/libsupc++/typeinfo
index 0f523d75b55..5a64e9ff092 100644
--- a/libstdc++-v3/libsupc++/typeinfo
+++ b/libstdc++-v3/libsupc++/typeinfo
@@ -133,8 +133,11 @@ namespace std
 { return __name == __arg.__name; }
   #endif
 #endif
+
+#if __cpp_impl_three_way_comparison < 201907L
 bool operator!=(const type_info& __arg) const _GLIBCXX_NOEXCEPT
 { return !operator==(__arg); }
+#endif
 
 #if __cplusplus >= 201103L
 size_t hash_code() const noexcept

RE: [PATCH] Fix bug in recursiveness check for function to be cloned (ipa/pr93707)

[Tamar Christina]

Hi Martin,

> Honza, is it OK for trunk?  Tamar, can you please double check it fixes
> your problem with perlbench?
>

Thanks for working on this! Yes it does seem to fix the regression as well.

Cheers,
Tamar

> Thanks,
>
> Martin
>
>
> ipa-cp: Avoid wrongly gathering self-recursive edges  (PR 93707)
>
> 2020-02-18  Martin Jambor  
>Feng Xue  
>
>PR ipa/93707
>* ipa-cp.c (same_node_or_its_all_contexts_clone_p): Replaced with
>new function calls_same_node_or_its_all_contexts_clone_p.
>(cgraph_edge_brings_value_p): Use it.  Fix comment.
>(cgraph_edge_brings_value_p): Likewise.
>
>testsuite/
>* gcc.dg/ipa/pr93707.c: New test.
> ---
>  gcc/ChangeLog  |  9 +
>  gcc/ipa-cp.c   | 29 ++---
>  gcc/testsuite/ChangeLog|  6 ++
>  gcc/testsuite/gcc.dg/ipa/pr93707.c | 29
> +
>  4 files changed, 58 insertions(+), 15 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.dg/ipa/pr93707.c
>
> diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
> index 4f5b72e6994..4609375bf8d 100644
> --- a/gcc/ipa-cp.c
> +++ b/gcc/ipa-cp.c
> @@ -4033,15 +4033,23 @@ edge_clone_summary_t::duplicate
> (cgraph_edge *src_edge, cgraph_edge *dst_edge,
>src_data->next_clone = dst_edge;
>  }
>
> -/* Return true is NODE is DEST or its clone for all contexts.  */
> +/* Return true is CS calls DEST or its clone for all contexts, except for
> +   self-recursive nodes in which it has to be DEST itself.  */
>
>  static bool
> -same_node_or_its_all_contexts_clone_p (cgraph_node *node,
> cgraph_node *dest)
> +calls_same_node_or_its_all_contexts_clone_p (cgraph_edge *cs,
> cgraph_node *dest)
>  {
> -  if (node == dest)
> +  enum availability availability;
> +  cgraph_node *callee = cs->callee->function_symbol (&availability);
> +
> +  if (availability <= AVAIL_INTERPOSABLE)
> +return false;
> +  if (callee == dest)
>  return true;
> +  if (cs->caller == callee)
> +return false;
>
> -  class ipa_node_params *info = IPA_NODE_REF (node);
> +  class ipa_node_params *info = IPA_NODE_REF (callee);
>return info->is_all_contexts_clone && info->ipcp_orig_node == dest;
>  }
>
> @@ -4053,11 +4061,8 @@ cgraph_edge_brings_value_p (cgraph_edge *cs,
> ipcp_value_source *src,
>cgraph_node *dest, ipcp_value *dest_val)
>  {
>class ipa_node_params *caller_info = IPA_NODE_REF (cs->caller);
> -  enum availability availability;
> -  cgraph_node *real_dest = cs->callee->function_symbol (&availability);
>
> -  if (availability <= AVAIL_INTERPOSABLE
> -  || !same_node_or_its_all_contexts_clone_p (real_dest, dest)
> +  if (!calls_same_node_or_its_all_contexts_clone_p (cs, dest)
>|| caller_info->node_dead)
>  return false;
>
> @@ -4076,9 +4081,6 @@ cgraph_edge_brings_value_p (cgraph_edge *cs,
> ipcp_value_source *src,
>  }
>else
>  {
> -  /* At the moment we do not propagate over arithmetic jump functions in
> -  SCCs, so it is safe to detect self-feeding recursive calls in this
> -  way.  */
>if (src->val == dest_val)
>return true;
>
> @@ -4113,11 +4115,8 @@ cgraph_edge_brings_value_p (cgraph_edge *cs,
>ipcp_value *)
>  {
>class ipa_node_params *caller_info = IPA_NODE_REF (cs->caller);
> -  enum availability avail;
> -  cgraph_node *real_dest = cs->callee->function_symbol (&avail);
>
> -  if (avail <= AVAIL_INTERPOSABLE
> -  || !same_node_or_its_all_contexts_clone_p (real_dest, dest)
> +  if (!calls_same_node_or_its_all_contexts_clone_p (cs, dest)
>|| caller_info->node_dead)
>  return false;
>if (!src->val)
> diff --git a/gcc/testsuite/gcc.dg/ipa/pr93707.c
> b/gcc/testsuite/gcc.dg/ipa/pr93707.c
> new file mode 100644
> index 000..e200a3a432b
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/ipa/pr93707.c
> @@ -0,0 +1,29 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O3 --param ipa-cp-eval-threshold=1" } */
> +
> +int foo();
> +int data[100];
> +
> +__attribute__((noinline)) static int recur_fn (int i, int j, int depth)
> +{
> +   if (depth > 10)
> + return 1;
> +
> +   data[i + j]++;
> +
> +   if (depth & 3)
> + recur_fn (i, 1, depth + 1);
> +   else
> + recur_fn (i, j & 1, depth + 1);
> +
> +   foo();
> +
> +   return i + j;
> +}
> +
> +int caller (int v, int depth)
> +{
> +  recur_fn (1, v, depth);
> +
> +  return 0;
> +}
> --
> 2.25.0

[committed] libstdc++: Define operator<=> for types

[Jonathan Wakely]

Another piece of P1614R2 for C++20.

This also adds tests for operator< in C++11, which was present but
untested.

* include/std/system_error (error_category::operator<=>)
(operator<=>(const error_code&, const error_code&))
(operator<=>(const error_condition&, const error_condition&)): Define
for C++20.
* testsuite/19_diagnostics/error_category/operators/less.cc: New test.
* testsuite/19_diagnostics/error_category/operators/three_way.cc: New
test.
* testsuite/19_diagnostics/error_code/operators/equal.cc: Remove
incorrect comment.
* testsuite/19_diagnostics/error_code/operators/less.cc: New test.
* testsuite/19_diagnostics/error_code/operators/not_equal.cc: Remove
incorrect comment.
* testsuite/19_diagnostics/error_code/operators/three_way.cc: New test.
* testsuite/19_diagnostics/error_condition/operators/equal.cc: Remove
incorrect comment.
* testsuite/19_diagnostics/error_condition/operators/less.cc: New test.
* testsuite/19_diagnostics/error_condition/operators/not_equal.cc:
Remove incorrect comment.
* testsuite/19_diagnostics/error_condition/operators/three_way.cc: New
test.


Tested powerpc64le-linux, committed to master.



commit 4be779f59b04947324889b7e1488fb9a68c81d53
Author: Jonathan Wakely 
Date:   Fri Feb 7 20:50:00 2020 +

libstdc++: Define operator<=> for  types

Another piece of P1614R2 for C++20.

This also adds tests for operator< in C++11, which was present but
untested.

* include/std/system_error (error_category::operator<=>)
(operator<=>(const error_code&, const error_code&))
(operator<=>(const error_condition&, const error_condition&)): Define
for C++20.
* testsuite/19_diagnostics/error_category/operators/less.cc: New test.
* testsuite/19_diagnostics/error_category/operators/three_way.cc: New
test.
* testsuite/19_diagnostics/error_code/operators/equal.cc: Remove
incorrect comment.
* testsuite/19_diagnostics/error_code/operators/less.cc: New test.
* testsuite/19_diagnostics/error_code/operators/not_equal.cc: Remove
incorrect comment.
* testsuite/19_diagnostics/error_code/operators/three_way.cc: New test.
* testsuite/19_diagnostics/error_condition/operators/equal.cc: Remove
incorrect comment.
* testsuite/19_diagnostics/error_condition/operators/less.cc: New test.
* testsuite/19_diagnostics/error_condition/operators/not_equal.cc:
Remove incorrect comment.
* testsuite/19_diagnostics/error_condition/operators/three_way.cc: New
test.

diff --git a/libstdc++-v3/include/std/system_error b/libstdc++-v3/include/std/system_error
index f1aebd59d02..f92b4345895 100644
--- a/libstdc++-v3/include/std/system_error
+++ b/libstdc++-v3/include/std/system_error
@@ -39,6 +39,9 @@
 #include 
 #include 
 #include 
+#if __cplusplus > 201703L
+# include 
+#endif
 
 namespace std _GLIBCXX_VISIBILITY(default)
 {
@@ -129,17 +132,23 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 virtual bool
 equivalent(const error_code& __code, int __i) const noexcept;
 
-bool
-operator<(const error_category& __other) const noexcept
-{ return less()(this, &__other); }
-
 bool
 operator==(const error_category& __other) const noexcept
 { return this == &__other; }
 
+#if __cpp_lib_three_way_comparison
+strong_ordering
+operator<=>(const error_category& __rhs) const noexcept
+{ return std::compare_three_way()(this, &__rhs); }
+#else
 bool
 operator!=(const error_category& __other) const noexcept
 { return this != &__other; }
+
+bool
+operator<(const error_category& __other) const noexcept
+{ return less()(this, &__other); }
+#endif
   };
 
   // DR 890.
@@ -230,6 +239,15 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   make_error_code(errc __e) noexcept
   { return error_code(static_cast(__e), generic_category()); }
 
+#if __cpp_lib_three_way_comparison
+  inline strong_ordering
+  operator<=>(const error_code& __lhs, const error_code& __rhs) noexcept
+  {
+if (auto __c = __lhs.category() <=> __rhs.category(); __c != 0)
+  return __c;
+return __lhs.value() <=> __rhs.value();
+  }
+#else
   inline bool
   operator<(const error_code& __lhs, const error_code& __rhs) noexcept
   {
@@ -237,6 +255,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 	|| (__lhs.category() == __rhs.category()
 		&& __lhs.value() < __rhs.value()));
   }
+#endif
 
   template
 basic_ostream<_CharT, _Traits>&
@@ -316,17 +335,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   make_error_condition(errc __e) noexcept
   { return error_condition(static_cast(__e), generic_category()); }
 
-  /// Define an ordering for error_condition objects.
-  /// @relates error_condition
-  inline bool
-  operat

[PATCH] Fix -save-temp leaking lto files in /tmp

[Bernd Edlinger]

Hi,

this is the remaining issue that happens when -flto and -save-temps
is used together, it leaks several files in /tmp.

I try to give more background to how these temp files are
created, and in all likelihood the leaking of these
files is wanted, and certainly very helpful for debugging
lto issues, that's for sure.  It is just not helpful
that they need to be looked up in the /tmp folder, even
if you want to debug something with lto.

The short story is...

They are created here:

  if (parallel)
{
  makefile = make_temp_file (".mk");
  mstream = fopen (makefile, "w");

and here:

  /* Note: we assume argv contains at least one element; this is
 checked above.  */

  response_file = make_temp_file ("");

  f = fopen (response_file, "w");

And in a few other places as well, it depends a bit
if -o is used or not (i.e. linker_output != NULL or not).

and not removed here:


  if (response_file && !save_temps)
{
  unlink (response_file);
  response_file = NULL;
}

and here:

  do_wait (new_argv[0], pex);
  maybe_unlink (makefile);
  makefile = NULL;


the code with the response_file is executed both in
lto-wrapper and collect2, but in collect2 only when
if is invoked from lto-wrapper, triggered by the @file
argument list.

Therefore I figured that the best possible
solution is just let lto-wrapper create a temp-file
for those problem cases, and use TMPDIR to have
all make_temp_file that follow use that to folder to
place the those response files and other stuff in
there.


So that is what I split out from the previous patch,
which focused on collect2.


Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?


Thanks
Bernd.

From d6dc826c63dc881fe41dbf0c3a461008afdef8b3 Mon Sep 17 00:00:00 2001
From: Bernd Edlinger 
Date: Mon, 17 Feb 2020 17:40:07 +0100
Subject: [PATCH] Fix -save-temp leaking lto files in /tmp

When linking with -flto and -save-temps, various
temporary files are created in /tmp.  They would normally
be deleted without -save-temps, but are retained
for debugging purposes, which is good.  So this just
creates a folder named as output-file.lto_tmpdir,
which makes this feature even more useful, as the
temporary files do not linger in the /tmp directoy
but instead are more easy to locate this way.

2020-02-20  Bernd Edlinger  

	* lto-wrapper.c (run_gcc): Create an lto tmpdir
	and use it when -save-temps is used.
---
 gcc/lto-wrapper.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/gcc/lto-wrapper.c b/gcc/lto-wrapper.c
index fe8f292..fdc9565 100644
--- a/gcc/lto-wrapper.c
+++ b/gcc/lto-wrapper.c
@@ -1423,6 +1423,17 @@ run_gcc (unsigned argc, char *argv[])
   fputc ('\n', stderr);
 }
 
+  if (save_temps)
+{
+  char *tmpdir = concat (linker_output ? linker_output : "a.out",
+			 ".lto_tmpdir", NULL);
+  /* Make directory if necessary, but expect no race here.  */
+  if (access (tmpdir, F_OK) == 0
+	  || mkdir (tmpdir, S_IRWXU | S_IRWXG | S_IRWXO) == 0)
+	setenv ("TMPDIR", tmpdir, 1);
+  free (tmpdir);
+}
+
   if (linker_output_rel)
 no_partition = true;
 
-- 
1.9.1

Re: [PATCH] Avoid collect2 calling signal unsafe functions and/or unlink, with uninitialized memory (for gcc-8 branch)

[Richard Biener]

On Wed, 19 Feb 2020, Bernd Edlinger wrote:

> Hi,
> 
> this fixes the signal handler calling signal unsafe vfprintf and/or passing
> uninitialized memory to unlink in signal handler.
> 
> This is the patch for the gcc-8 branch.
> 
> 
> Bootstrapped and reg-tested with x86_64-pc-linux-gnu.
> Is it OK for the gcc-8 branch?

OK.

Richard.

> 
> Thanks
> Bernd.
> 

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

Re: [PATCH] Fix -save-temp leaking lto files in /tmp

[Richard Biener]

On Thu, 20 Feb 2020, Bernd Edlinger wrote:

> Hi,
> 
> this is the remaining issue that happens when -flto and -save-temps
> is used together, it leaks several files in /tmp.
> 
> I try to give more background to how these temp files are
> created, and in all likelihood the leaking of these
> files is wanted, and certainly very helpful for debugging
> lto issues, that's for sure.  It is just not helpful
> that they need to be looked up in the /tmp folder, even
> if you want to debug something with lto.
> 
> The short story is...
> 
> They are created here:
> 
>   if (parallel)
> {
>   makefile = make_temp_file (".mk");
>   mstream = fopen (makefile, "w");
> 
> and here:
> 
>   /* Note: we assume argv contains at least one element; this is
>  checked above.  */
> 
>   response_file = make_temp_file ("");
> 
>   f = fopen (response_file, "w");
> 
> And in a few other places as well, it depends a bit
> if -o is used or not (i.e. linker_output != NULL or not).
> 
> and not removed here:
> 
> 
>   if (response_file && !save_temps)
> {
>   unlink (response_file);
>   response_file = NULL;
> }
> 
> and here:
> 
>   do_wait (new_argv[0], pex);
>   maybe_unlink (makefile);
>   makefile = NULL;
> 
> 
> the code with the response_file is executed both in
> lto-wrapper and collect2, but in collect2 only when
> if is invoked from lto-wrapper, triggered by the @file
> argument list.
> 
> Therefore I figured that the best possible
> solution is just let lto-wrapper create a temp-file
> for those problem cases, and use TMPDIR to have
> all make_temp_file that follow use that to folder to
> place the those response files and other stuff in
> there.
> 
> 
> So that is what I split out from the previous patch,
> which focused on collect2.
> 
> 
> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
> Is it OK for trunk?

I don't think this is an improvement.  The files still
will be (correctly) retained and now in addition to that
there's temporary directories piling up?

A better improvement would be to selectively decide
which files might not be needed to be preserved and/or
give them names in the build directory in more cases.

Richard.

> 
> Thanks
> Bernd.
> 
> 

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

[committed] libstdc++: Issues with range access CPOs (P2091R0)

[Jonathan Wakely]

This changes how arrays of unknown bound and/or incomplete element type
are handled.

* include/bits/range_access.h (ranges::begin): Reject array of
incomplete type.
(ranges::end, ranges::size): Require arrays to be bounded.
(ranges::data): Require lvalue or borrowed_range.
(ranges::iterator_t): Remove constraint.
* testsuite/std/ranges/access/begin.cc: Do not check array of
incomplete type.
* testsuite/std/ranges/access/begin_neg.cc: New test.
* testsuite/std/ranges/access/end_neg.cc: Adjust expected error.
* testsuite/std/ranges/access/size_neg.cc: Adjust expected error.
* testsuite/std/ranges/access/ssize.cc: Do not check array of
incomplete type.

Tested powerpc64le-linux, committed to master.


commit e817c23f6806a6b9201a0a1f77b51cb863af51e9
Author: Jonathan Wakely 
Date:   Thu Feb 20 13:20:44 2020 +

libstdc++: Issues with range access CPOs (P2091R0)

This changes how arrays of unknown bound and/or incomplete element type
are handled.

* include/bits/range_access.h (ranges::begin): Reject array of
incomplete type.
(ranges::end, ranges::size): Require arrays to be bounded.
(ranges::data): Require lvalue or borrowed_range.
(ranges::iterator_t): Remove constraint.
* testsuite/std/ranges/access/begin.cc: Do not check array of
incomplete type.
* testsuite/std/ranges/access/begin_neg.cc: New test.
* testsuite/std/ranges/access/end_neg.cc: Adjust expected error.
* testsuite/std/ranges/access/size_neg.cc: Adjust expected error.
* testsuite/std/ranges/access/ssize.cc: Do not check array of
incomplete type.

diff --git a/libstdc++-v3/include/bits/range_access.h 
b/libstdc++-v3/include/bits/range_access.h
index e7a19305d23..eb91ade35ff 100644
--- a/libstdc++-v3/include/bits/range_access.h
+++ b/libstdc++-v3/include/bits/range_access.h
@@ -382,8 +382,8 @@ namespace ranges
  { __decay_copy(__t.begin()) } -> input_or_output_iterator;
};
 
-template void begin(_Tp&&) = delete;
-template void begin(initializer_list<_Tp>&&) = delete;
+void begin(auto&) = delete;
+void begin(const auto&) = delete;
 
 template
   concept __adl_begin = __class_or_enum>
@@ -417,7 +417,9 @@ namespace ranges
  if constexpr (is_array_v>)
{
  static_assert(is_lvalue_reference_v<_Tp>);
- return __t;
+ using _Up = remove_all_extents_t>;
+ static_assert(sizeof(_Up) != 0, "not array of incomplete type");
+ return __t + 0;
}
  else if constexpr (__member_begin<_Tp>)
return __t.begin();
@@ -433,8 +435,8 @@ namespace ranges
-> sentinel_for(__t)))>;
};
 
-template void end(_Tp&&) = delete;
-template void end(initializer_list<_Tp>&&) = delete;
+void end(auto&) = delete;
+void end(const auto&) = delete;
 
 template
   concept __adl_end = __class_or_enum>
@@ -451,7 +453,7 @@ namespace ranges
static constexpr bool
_S_noexcept()
{
- if constexpr (is_array_v>)
+ if constexpr (is_bounded_array_v>)
return true;
  else if constexpr (__member_end<_Tp>)
return noexcept(__decay_copy(std::declval<_Tp&>().end()));
@@ -461,15 +463,14 @@ namespace ranges
 
 public:
   template<__maybe_borrowed_range _Tp>
-   requires is_array_v> || __member_end<_Tp>
+   requires is_bounded_array_v> || 
__member_end<_Tp>
|| __adl_end<_Tp>
constexpr auto
operator()(_Tp&& __t) const noexcept(_S_noexcept<_Tp>())
{
- if constexpr (is_array_v>)
+ if constexpr (is_bounded_array_v>)
{
  static_assert(is_lvalue_reference_v<_Tp>);
- static_assert(is_bounded_array_v>);
  return __t + extent_v>;
}
  else if constexpr (__member_end<_Tp>)
@@ -519,7 +520,8 @@ namespace ranges
  { __decay_copy(__t.rbegin()) } -> input_or_output_iterator;
};
 
-template void rbegin(_Tp&&) = delete;
+void rbegin(auto&) = delete;
+void rbegin(const auto&) = delete;
 
 template
   concept __adl_rbegin = __class_or_enum>
@@ -582,7 +584,8 @@ namespace ranges
-> sentinel_for;
};
 
-template void rend(_Tp&&) = delete;
+void rend(auto&) = delete;
+void rend(const auto&) = delete;
 
 template
   concept __adl_rend = __class_or_enum>
@@ -664,7 +667,8 @@ namespace ranges
-> __detail::__is_integer_like;
};
 
-template void size(_Tp&&) = delete;
+void size(auto&) = delete;
+void size(const auto&) = delete;
 
 template
   concept __adl_size = __class_or_enum>
@@ -691,7 +695,7 @@ namespace ranges
static constexpr bool
_S_noexcept()
{
-  

Re: [PATCH] Fix -save-temp leaking lto files in /tmp

[Bernd Edlinger]

On 2/20/20 2:34 PM, Richard Biener wrote:
> On Thu, 20 Feb 2020, Bernd Edlinger wrote:
> 
>> Hi,
>>
>> this is the remaining issue that happens when -flto and -save-temps
>> is used together, it leaks several files in /tmp.
>>
>> I try to give more background to how these temp files are
>> created, and in all likelihood the leaking of these
>> files is wanted, and certainly very helpful for debugging
>> lto issues, that's for sure.  It is just not helpful
>> that they need to be looked up in the /tmp folder, even
>> if you want to debug something with lto.
>>
>> The short story is...
>>
>> They are created here:
>>
>>   if (parallel)
>> {
>>   makefile = make_temp_file (".mk");
>>   mstream = fopen (makefile, "w");
>>
>> and here:
>>
>>   /* Note: we assume argv contains at least one element; this is
>>  checked above.  */
>>
>>   response_file = make_temp_file ("");
>>
>>   f = fopen (response_file, "w");
>>
>> And in a few other places as well, it depends a bit
>> if -o is used or not (i.e. linker_output != NULL or not).
>>
>> and not removed here:
>>
>>
>>   if (response_file && !save_temps)
>> {
>>   unlink (response_file);
>>   response_file = NULL;
>> }
>>
>> and here:
>>
>>   do_wait (new_argv[0], pex);
>>   maybe_unlink (makefile);
>>   makefile = NULL;
>>
>>
>> the code with the response_file is executed both in
>> lto-wrapper and collect2, but in collect2 only when
>> if is invoked from lto-wrapper, triggered by the @file
>> argument list.
>>
>> Therefore I figured that the best possible
>> solution is just let lto-wrapper create a temp-file
>> for those problem cases, and use TMPDIR to have
>> all make_temp_file that follow use that to folder to
>> place the those response files and other stuff in
>> there.
>>
>>
>> So that is what I split out from the previous patch,
>> which focused on collect2.
>>
>>
>> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
>> Is it OK for trunk?
> 
> I don't think this is an improvement.  The files still
> will be (correctly) retained and now in addition to that
> there's temporary directories piling up?
> 

Well, the temp. directory has a known name,
in case the command line is

gcc -save-temps -lto -o test test.c

there are those 4 in a *known* place, test.lto_tmpdir:

test.lto_tmpdir:
insgesamt 24
drwxrwxr-x 2 ed ed 4096 Feb 20 16:14 .
drwxrwxr-x 3 ed ed 4096 Feb 20 16:14 ..
-rw--- 1 ed ed   15 Feb 20 16:14 cc8FwPQ1
-rw--- 1 ed ed  237 Feb 20 16:14 cchROrdh
-rw--- 1 ed ed  197 Feb 20 16:14 cclbBAUp
-rw--- 1 ed ed7 Feb 20 16:14 ccMlfh1g

plus
-rw-rw-r-- 1 ed ed   164 Feb 20 16:14 test.i
-rw-rw-r-- 1 ed ed50 Feb 20 16:14 test.lto_wrapper_args
-rw-rw-r-- 1 ed ed17 Feb 20 16:14 test.ltrans.out
-rw-rw-r-- 1 ed ed  1232 Feb 20 16:14 test.ltrans0.ltrans.o
-rw-rw-r-- 1 ed ed  2539 Feb 20 16:14 test.ltrans0.o
-rw-rw-r-- 1 ed ed   374 Feb 20 16:14 test.ltrans0.s
-rw-rw-r-- 1 ed ed52 Feb 20 16:14 test.res
-rw-rw-r-- 1 ed ed  4267 Feb 20 16:14 test.s

if the command line is
gcc -save-temps -lto test.c

there are a few more but also in a *known* place, a.out.lto_tmpdir:

a.out.lto_tmpdir/
total 36
drwxrwxr-x 2 ed ed 4096 Feb 20 16:18 .
drwxrwxr-x 3 ed ed 4096 Feb 20 16:18 ..
-rw--- 1 ed ed7 Feb 20 16:18 cc2hY8SH
-rw--- 1 ed ed  227 Feb 20 16:18 ccDafyit
-rw--- 1 ed ed  262 Feb 20 16:18 ccglzNAe
-rw--- 1 ed ed   36 Feb 20 16:18 ccnAU7NG
-rw--- 1 ed ed   38 Feb 20 16:18 ccoLFY2H.ltrans.out
-rw-rw-r-- 1 ed ed 1232 Feb 20 16:18 ccoLFY2H.ltrans0.ltrans.o
-rw-rw-r-- 1 ed ed 2560 Feb 20 16:18 ccoLFY2H.ltrans0.o

plus
-rw-rw-r--   1 ed ed50 Feb 20 16:18 a.out.lto_wrapper_args
-rw-rw-r--   1 ed ed   160 Feb 20 16:18 test.i
-rw-rw-r--   1 ed ed  3104 Feb 20 16:18 test.o
-rw-rw-r--   1 ed ed52 Feb 20 16:18 test.res
-rw-rw-r--   1 ed ed  4267 Feb 20 16:18 test.s


> A better improvement would be to selectively decide
> which files might not be needed to be preserved and/or
> give them names in the build directory in more cases.
> 

Ah, well, it just felt like that will probably need a
rather complicated patch which is probably not
worth it, since the are a lot of different
code pathes involved, (with -g or not, with -flto=jobserver
or not, flto_partition=none, or with offload or not, with -o
or not etc.) in two or more independent forked processes,
which will need to coordinate somehow, not to clobber each
other's tempfiles.


Bernd.


> Richard.
> 
>>
>> Thanks
>> Bernd.
>>
>>
> 

Re: [PATCH] tree-optimization/93586 - bogus path-based disambiguation

[Jan Hubicka]

> This fixes bogus path-based disambiguation of mismatched array shape
> accesses.
> 
> Bootstrap & regtest running on x86_64-unknown-linux-gnu.
> 
> Honza, is this the correct place to detect this or were we not
> supposed to arrive there?
> 
> Thanks,
> Richard.
> 
> 2020-02-17  Richard Biener  
> 
>   PR tree-optimization/93586
>   * tree-ssa-alias.c (nonoverlapping_array_refs_p): Fail when
>   we're obviously not looking at same-shaped array accesses.
> 
>   * gcc.dg/torture/pr93586.c: New testcase.
> ---
>  gcc/testsuite/gcc.dg/torture/pr93586.c | 21 +
>  gcc/tree-ssa-alias.c   |  5 +
>  2 files changed, 26 insertions(+)
>  create mode 100644 gcc/testsuite/gcc.dg/torture/pr93586.c
> 
> diff --git a/gcc/tree-ssa-alias.c b/gcc/tree-ssa-alias.c
> index b8df66ac1f2..e7caf9bee77 100644
> --- a/gcc/tree-ssa-alias.c
> +++ b/gcc/tree-ssa-alias.c
> @@ -1291,6 +1291,11 @@ nonoverlapping_array_refs_p (tree ref1, tree ref2)
>  
>tree elmt_type1 = TREE_TYPE (TREE_TYPE (TREE_OPERAND (ref1, 0)));
>tree elmt_type2 = TREE_TYPE (TREE_TYPE (TREE_OPERAND (ref2, 0)));
> +  /* If one element is an array but not the other there's an obvious
> + mismatch in dimensionality.  */
> +  if ((TREE_CODE (elmt_type1) == ARRAY_TYPE)
> +  != (TREE_CODE (elmt_type2) == ARRAY_TYPE))
> +return -1;

The problem happens earlier.  The function is not supposed to give
meaningful results when bases of ref1 and ref2 are not same or
completely disjoint and here it is called on c[0][j_2][0] and c[0][1] so
bases in sence of this functions are "c[0][j_2]" and "c[0]" which do
partially overlap.

The problem is in nonoverlapping_array_refs that walks
pair of array references and in this case it misses to note the fact
that if it walked across first mismatched pair it is no longer safe to
compare rest.

The reason why it continues matching is because it hopes it will
eventually get pair of COMPONENT_REFs from types of same size and use
TBAA to conclude that their addresses must be either same or completely
disjoint.

This patch makes the loop to terminate early but popping all the
remaining pairs so walking can continue.  We could re-synchronize on
arrays of same size with TBAA but this is bit fishy (because we try to
support some sort of partial array overlaps) and hard to implement
(because of zero sized arrays and VLAs) so I think it is not worth the
effort.

In addition I notied that the function is not !flag_strict_aliasing safe
and added early exits on places we set seen_unmatched_ref_p since later
we do not check that in:

   /* If we skipped array refs on type of different sizes, we can
 no longer be sure that there are not partial overlaps.  */
   if (seen_unmatched_ref_p
  && !operand_equal_p (TYPE_SIZE (type1), TYPE_SIZE (type2), 0))
{
  ++alias_stats
.nonoverlapping_refs_since_match_p_may_alias;
}

Bootstrapped/regtested ppc64-linux, OK?

* tree-ssa-alias.c (nonoverlapping_array_refs_p): Finish array walk
after mismatched array refs; do not sure type size information to
recover from unmatched referneces with !flag_strict_aliasing_p.
* gcc.dg/torture/pr93586.c: New testcase.
diff --git a/gcc/tree-ssa-alias.c b/gcc/tree-ssa-alias.c
index fd78105..8509f75 100644
--- a/gcc/tree-ssa-alias.c
+++ b/gcc/tree-ssa-alias.c
@@ -1486,9 +1489,27 @@ nonoverlapping_refs_since_match_p (tree match1, tree 
ref1,
.nonoverlapping_refs_since_match_p_no_alias;
  return 1;
}
- partial_overlap = false;
  if (cmp == -1)
-   seen_unmatched_ref_p = true;
+   {
+ seen_unmatched_ref_p = true;
+ /* We can not maintain the invariant that bases are either
+same or completely disjoint.  However we can still recover
+from type based alias analysis if we reach referneces to
+same sizes.  We do not attempt to match array sizes, so
+just finish array walking and look for component refs.  */
+ if (!flag_strict_aliasing)
+   {
+ ++alias_stats.nonoverlapping_refs_since_match_p_may_alias;
+ return -1;
+   }
+ for (i++; i < narray_refs1; i++)
+   {
+ component_refs1.pop ();
+ component_refs2.pop ();
+   }
+ break;
+   }
+ partial_overlap = false;
}
}
 
@@ -1503,7 +1524,14 @@ nonoverlapping_refs_since_match_p (tree match1, tree 
ref1,
}
  ref1 = component_refs1.pop ();
  if (TREE_CODE (ref1) != COMPONENT_REF)
-   seen_unmatched_ref_p = true;
+   {
+ seen_unmatched_ref_p = true;
+ if (!flag_strict_aliasing)
+   

Re: [PATCH] Fix -save-temp leaking lto files in /tmp

[Tobias Burnus]

Hi Bernd, hi all,

note that you can get even more files: If you do offloading,
LTO is additionally run for each offloading target (there
can be more than one), cf. https://gcc.gnu.org/wiki/Offloading

Some of those files are probably also from mkoffload etc.
See below.

On 2/20/20 4:33 PM, Bernd Edlinger wrote:


On 2/20/20 2:34 PM, Richard Biener wrote:

I don't think this is an improvement.  The files still
will be (correctly) retained and now in addition to that
there's temporary directories piling up?

Well, the temp. directory has a known name,
in case the command line is

gcc -save-temps -lto -o test test.c

there are those 4 in a *known* place, test.lto_tmpdir:


Here, with offloading (compiler only supports one
offloading target), I get for
   gfortran -fopenacc -save-temps -o test kernels-map-2.F90

(1) in the current directory:
kernels-map-2.f90
kernels-map-2.o
test.lto_wrapper_args
kernels-map-2.res
kernels-map-2.s
ccv97orQ.i
ccv97orQ.s

(2) in /tmp:
ccXtFBKP.ofldlist
cckm9TaT
cc1aPJVX
ccwnCSfQ
ccEwCVRX
ccv97orQ.c
ccgtnzbU.mkoffload
ccsZzs01
ccouoZqP.target.o
cc6o87mX.crtoffloadtable.o
test

And with "-flto" in addition:

(1) Current directory:
kernels-map-2.f90
kernels-map-2.o
test.lto_wrapper_args
kernels-map-2.res
kernels-map-2.s
ccdBFFxF.i
ccdBFFxF.s
test.ltrans0.o
test.ltrans.out
test.ltrans0.s
test.ltrans0.ltrans.o
test

(2) in /tmp:
ccX5EDTE.ofldlist
ccpAKbE7
ccxnuNsz
ccq5sdmF
ccWUsloz
ccZ5rev7.mkoffload
ccdBFFxF.c
cc3PGOK1
ccW4hTGF.target.o
ccWH1ft2
ccsKJG3z.crtoffloadtable.o
ccmE0bPK
ccB54fLv
cckO6O6c

Cheers,

Tobias

[GCC][PATCH][ARM] Add multilib mapping for Armv8.1-M+MVE with -mfloat-abi=hard

[Mihail Ionescu]

Hi,

This patch adds a new multilib for armv8.1-m.main+mve with hard float abi. For
armv8.1-m.main+mve soft and softfp, the v8-M multilibs will be reused.
The following mappings are also updated:
"-mfloat-abi=hard -march=armv8.1-m.main+mve.fp -> armv8-m.main+fp/hard"
"-mfloat-abi=softfp -march=armv8.1-m.main+mve.fp -> armv8-m.main+fp/softfp"
"-mfloat-abi=soft -march=armv8.1-m.main+mve.fp -> armv8-m.main/nofp"

The patch also includes a libgcc change to prevent cmse_nonsecure_call.S from 
being
compiled for v8.1-M. v8.1-M doesn't need it since the same behaviour is 
achieved during
code generation by using the new instructions[1].

[1] https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01654.html

Tested on arm-none-eabi.


gcc/ChangeLog:

2020-02-20  Mihail Ionescu  

* config/arm/t-rmprofile: create new multilib for
armv8.1-m.main+mve hard float and reuse v8-m.main ones for
v8.1-m.main+mve .

gcc/testsuite/ChangeLog:

2020-02-20  Mihail Ionescu  

* testsuite/gcc.target/arm/multilib.exp: Add new v8.1-M entry.

2020-02-20  Mihail Ionescu  

libgcc/ChangLog:

* config/arm/t-arm: Do not compile cmse_nonsecure_call.S for v8.1-m.

Ok for trunk?


Regards,
Mihail


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


diff --git a/gcc/config/arm/t-rmprofile b/gcc/config/arm/t-rmprofile
index 
0fb3084c8b20f16ccadba632fc55162b196651d5..16e368f25cc2e3ad341adc2752120ad0defdf2a4
 100644
--- a/gcc/config/arm/t-rmprofile
+++ b/gcc/config/arm/t-rmprofile
@@ -27,8 +27,8 @@
 
 # Arch and FPU variants to build libraries with
 
-MULTI_ARCH_OPTS_RM = 
march=armv6s-m/march=armv7-m/march=armv7e-m/march=armv7e-m+fp/march=armv7e-m+fp.dp/march=armv8-m.base/march=armv8-m.main/march=armv8-m.main+fp/march=armv8-m.main+fp.dp
-MULTI_ARCH_DIRS_RM = v6-m v7-m v7e-m v7e-m+fp v7e-m+dp v8-m.base v8-m.main 
v8-m.main+fp v8-m.main+dp
+MULTI_ARCH_OPTS_RM = 
march=armv6s-m/march=armv7-m/march=armv7e-m/march=armv7e-m+fp/march=armv7e-m+fp.dp/march=armv8-m.base/march=armv8-m.main/march=armv8-m.main+fp/march=armv8-m.main+fp.dp/march=armv8.1-m.main+mve
+MULTI_ARCH_DIRS_RM = v6-m v7-m v7e-m v7e-m+fp v7e-m+dp v8-m.base v8-m.main 
v8-m.main+fp v8-m.main+dp v8.1-m.main+mve
 
 # Base M-profile (no fp)
 MULTILIB_REQUIRED  += mthumb/march=armv6s-m/mfloat-abi=soft
@@ -48,8 +48,7 @@ MULTILIB_REQUIRED += 
mthumb/march=armv8-m.main+fp/mfloat-abi=hard
 MULTILIB_REQUIRED  += mthumb/march=armv8-m.main+fp/mfloat-abi=softfp
 MULTILIB_REQUIRED  += mthumb/march=armv8-m.main+fp.dp/mfloat-abi=hard
 MULTILIB_REQUIRED  += mthumb/march=armv8-m.main+fp.dp/mfloat-abi=softfp
-
-
+MULTILIB_REQUIRED  += mthumb/march=armv8.1-m.main+mve/mfloat-abi=hard
 
 # Arch Matches
 MULTILIB_MATCHES   += march?armv6s-m=march?armv6-m
@@ -66,12 +65,14 @@ MULTILIB_MATCHES+= march?armv7e-m+fp=march?armv7e-m+fpv5
 MULTILIB_REUSE += $(foreach ARCH, armv6s-m armv7-m armv7e-m 
armv8-m\.base armv8-m\.main, \
 
mthumb/march.$(ARCH)/mfloat-abi.soft=mthumb/march.$(ARCH)/mfloat-abi.softfp)
 
+
 # Map v8.1-M to v8-M.
 MULTILIB_MATCHES   += march?armv8-m.main=march?armv8.1-m.main
 MULTILIB_MATCHES   += march?armv8-m.main=march?armv8.1-m.main+dsp
-MULTILIB_MATCHES   += march?armv8-m.main=march?armv8.1-m.main+mve
+MULTILIB_REUSE += 
mthumb/march.armv8-m\.main/mfloat-abi.soft=mthumb/march.armv8\.1-m\.main+mve/mfloat-abi.soft
+MULTILIB_REUSE += 
mthumb/march.armv8-m\.main/mfloat-abi.soft=mthumb/march.armv8\.1-m\.main+mve/mfloat-abi.softfp
 
-v8_1m_sp_variants = +fp +dsp+fp +mve.fp
+v8_1m_sp_variants = +fp +dsp+fp +mve.fp +fp+mve
 v8_1m_dp_variants = +fp.dp +dsp+fp.dp +fp.dp+mve +fp.dp+mve.fp
 
 # Map all v8.1-m.main FP sp variants down to v8-m.
diff --git a/gcc/testsuite/gcc.target/arm/multilib.exp 
b/gcc/testsuite/gcc.target/arm/multilib.exp
index 
67d00266f6b5e69aa2a7831cfb9a4353ac4f4340..42aaebfabdf76c45a1909b2aaa1651d3c42ee4b7
 100644
--- a/gcc/testsuite/gcc.target/arm/multilib.exp
+++ b/gcc/testsuite/gcc.target/arm/multilib.exp
@@ -813,6 +813,9 @@ if {[multilib_config "rmprofile"] } {
{-march=armv8.1-m.main+mve.fp -mfpu=auto -mfloat-abi=soft} 
"thumb/v8-m.main/nofp"
{-march=armv8.1-m.main+mve -mfpu=auto -mfloat-abi=softfp} 
"thumb/v8-m.main/nofp"
{-march=armv8.1-m.main+mve.fp -mfpu=auto -mfloat-abi=softfp} 
"thumb/v8-m.main+fp/softfp"
+   {-march=armv8.1-m.main+mve -mfpu=auto -mfloat-abi=hard} 
"thumb/v8.1-m.main+mve/hard"
+   {-march=armv8.1-m.main+mve+fp -mfpu=auto -mfloat-abi=hard} 
"thumb/v8-m.main+fp/hard"
+   {-march=armv8.1-m.main+mve+fp -mfpu=auto -mfloat-abi=softfp} 
"thumb/v8-m.main+fp/softfp"
{-march=armv8.1-m.main+mve.fp -mfpu=auto -mfloat-abi=hard} 
"thumb/v8-m.main+fp/hard"
{-march=armv8.1-m.main+mve+fp.dp -mfpu=auto -mfloat-abi=soft} 
"thumb/v8-m.main/nofp"
{-march=armv8.1-m.main+mve.fp+fp.dp -mfpu=auto -mfloat-abi=soft} 
"thumb/v8-m.main/nofp"
diff --git 

Re: [PATCH v3] c++: Fix value-init crash in template [PR93676]

[Marek Polacek]

On Thu, Feb 20, 2020 at 12:13:07AM +, Jason Merrill wrote:
> On 2/19/20 10:15 PM, Marek Polacek wrote:
> > On Fri, Feb 14, 2020 at 12:24:30AM +0100, Jason Merrill wrote:
> > > On 2/11/20 8:54 PM, Marek Polacek wrote:
> > > > Since  we
> > > > attempt to value-initialize in build_vec_init even when there's no
> > > > initializer but the type has a constexpr default constructor.  But
> > > > build_value_init doesn't work in templates, so I think let's avoid
> > > > this scenario; we'll go to the normal build_aggr_init path then.
> > > > 
> > > > Bootstrapped/regtested on x86_64-linux, ok for trunk and branches?
> > > > 
> > > > PR c++/93676 - value-init crash in template.
> > > > * init.c (build_vec_init): Don't perform value-init in a 
> > > > template.
> > > 
> > > Hmm, we really shouldn't even be calling build_vec_init in a template, 
> > > that
> > > builds up a lot of garbage that we'll throw away at the end of build_new.
> > 
> > Ah, it's true that build_new will just creates a NEW_EXPR in a template and
> > doesn't use the result of build_new_1.  Unfortunately I can't just call
> > build_special_member_call like we do in build_new_1 since that crashes for
> > array types.
> 
> We should call it for strip_array_types (type).

Since build_special_member_call takes an expression we'd have to modify
its type which I think is not pretty, but it works.  Is this along the
lines you had in mind?

I think I still like the v1 patch best but if you're fine with the
following, then am I.

-- >8 --
Since  we
attempt to value-initialize in build_vec_init even when there's no
initializer but the type has a constexpr default constructor.  But
build_value_init doesn't work in templates, and build_vec_init
creates a lot of garbage that would not be used anyway, so don't
call it in a template.

PR c++/93676 - value-init crash in template.
* init.c (build_new_1): Don't call build_vec_init in a template.

* g++.dg/cpp0x/nsdmi-template19.C: New test.
---
 gcc/cp/init.c |  6 +-
 gcc/testsuite/g++.dg/cpp0x/nsdmi-template19.C | 13 +
 2 files changed, 18 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/nsdmi-template19.C

diff --git a/gcc/cp/init.c b/gcc/cp/init.c
index d480660445e..c60f332313a 100644
--- a/gcc/cp/init.c
+++ b/gcc/cp/init.c
@@ -3511,13 +3511,17 @@ build_new_1 (vec **placement, tree type, 
tree nelts,
  explicit_value_init_p = true;
}
 
-  if (processing_template_decl && explicit_value_init_p)
+  if (processing_template_decl)
{
  /* build_value_init doesn't work in templates, and we don't need
 the initializer anyway since we're going to throw it away and
 rebuild it at instantiation time, so just build up a single
 constructor call to get any appropriate diagnostics.  */
  init_expr = cp_build_fold_indirect_ref (data_addr);
+ /* Avoid an ICE when converting to a base in build_simple_base_path.
+We'll throw this all away anyway, and build_new will create
+a NEW_EXPR.  */
+ TREE_TYPE (init_expr) = strip_array_types (TREE_TYPE (init_expr));
  if (type_build_ctor_call (elt_type))
init_expr = build_special_member_call (init_expr,
   complete_ctor_identifier,
diff --git a/gcc/testsuite/g++.dg/cpp0x/nsdmi-template19.C 
b/gcc/testsuite/g++.dg/cpp0x/nsdmi-template19.C
new file mode 100644
index 000..f3e2cb87fd6
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/nsdmi-template19.C
@@ -0,0 +1,13 @@
+// PR c++/93676 - value-init crash in template.
+// { dg-do compile { target c++11 } }
+
+struct P {
+  int x = 0;
+};
+
+template
+struct S {
+  S() { new P[2][2]; }
+};
+
+S s;

base-commit: 4be779f59b04947324889b7e1488fb9a68c81d53
-- 
Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA

Re: [RFC PATCH v0] PPC64: Implement POWER Architecure Vector Function ABI.

[GT]

‐‐‐ Original Message ‐‐‐
On Wednesday, February 19, 2020 5:52 PM, Joseph Myers  
wrote:

> On Wed, 19 Feb 2020, GT wrote:
>
> > 1.  In the Vector Function ABI document, under section "Vector Function
> > Name Mangling", state that all  vector variants will be created by
> > the compiler. And that it will be up to the caller of vectorized
> > functions to select the preferred version ('b' or 'c' are the only
> > choices presently).
> >
>
> A reminder, "all" needs to be a particular fixed set that will not be
> expanded in future versions of the ABI, so that a glibc installed now
> continues to work with future compilers (rather than a future compiler
> wrongly taking a pragma / attribute in existing glibc headers as meaning
> some future vector ISA variant, unknown when that glibc header was
> written, is available).

What more needs to be done other than documenting the GLIBC and GCC versions for
which 'b' and 'c' vector versions are available? It is how x86_64 explained
the differences between Examples 1 and 2 at 
https://sourceware.org/glibc/wiki/libmvec

Bert.

Re: [RFC PATCH v0] PPC64: Implement POWER Architecure Vector Function ABI.

[Joseph Myers]

On Thu, 20 Feb 2020, GT wrote:

> What more needs to be done other than documenting the GLIBC and GCC 
> versions for which 'b' and 'c' vector versions are available? It is how 
> x86_64 explained the differences between Examples 1 and 2 at 
> https://sourceware.org/glibc/wiki/libmvec

This is about ISA variants in the ABI.  

 
says "Compiler implementations must not generate calls to version of other 
ISAs unless some non-standard pragma or clause is used to declare those 
other versions are available.".  The same needs to apply to the POWER ABI 
- any pragma or attribute declaring vector functions to be available must 
have a fixed set of ISA variants the ABI says it declares to be available, 
with any ISA variants added in future needing a new pragma or attribute to 
declare them to be available, to avoid GCC 20 misinterpreting glibc 2.32 
headers as implying function variants are available for ISAs that didn't 
exist when those glibc 2.32 headers were written.

-- 
Joseph S. Myers
jos...@codesourcery.com

[PATCH] libstdc++: Fix capturing of lvalue references in_RangeAdaptor::operator()

[Patrick Palka]

This fixes a dangling-reference issue with views::split and other multi-argument
adaptors that may take its extra arguments by reference.

When creating the _RangeAdaptorClosure in _RangeAdaptor::operator(), we
currently capture all provided arguments by value.  When we later use the
_RangeAdaptorClosure and call it with a range, as in e.g.

v = views::split(p)(range),

we forward the range and the captures to the underlying adaptor routine.  But
then when the temporary _RangeAdaptorClosure goes out of scope, the by-value
captures get destroyed and the references to these capture in the resulting view
become dangling.

This patch fixes this problem by capturing lvalue references by reference in
_RangeAdaptorClosure::operator(), and then forwarding the captures appropriately
to the underlying range adaptor.

libstdc++-v3/ChangeLog:

* include/std/ranges (views::__adaptor::__maybe_refwrap): New utility
function.
(views::__adaptor::_RangeAdaptor::operator()): Add comments.  Use
__maybe_refwrap to capture lvalue references by reference, and then use
unwrap_reference_t to forward the by-reference captures as references.
* testsuite/std/ranges/adaptors/split.cc: Augment test.
* testsuite/std/ranges/adaptors/split_neg.cc: New test.
---
 libstdc++-v3/include/std/ranges   | 50 --
 .../testsuite/std/ranges/adaptors/split.cc| 18 +++
 .../std/ranges/adaptors/split_neg.cc  | 51 +++
 3 files changed, 116 insertions(+), 3 deletions(-)
 create mode 100644 libstdc++-v3/testsuite/std/ranges/adaptors/split_neg.cc

diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index a2c1be50594..34de6965dcd 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -1072,6 +1072,21 @@ namespace views
 {
   namespace __adaptor
   {
+template
+  inline constexpr auto
+  __maybe_refwrap(_Tp& __arg)
+  { return reference_wrapper<_Tp>{__arg}; }
+
+template
+  inline constexpr auto
+  __maybe_refwrap(const _Tp& __arg)
+  { return reference_wrapper{__arg}; }
+
+template
+  inline constexpr decltype(auto)
+  __maybe_refwrap(_Tp&& __arg)
+  { return std::forward<_Tp>(__arg); }
+
 template
   struct _RangeAdaptorClosure;
 
@@ -1100,18 +1115,47 @@ namespace views
  constexpr auto
  operator()(_Args&&... __args) const
  {
+   // [range.adaptor.object]: If a range adaptor object accepts more
+   // than one argument, then the following expressions are equivalent:
+   //
+   //   (1) adaptor(range, args...)
+   //   (2) adaptor(args...)(range)
+   //   (3) range | adaptor(args...)
+   //
+   // In this case, adaptor(args...) is a range adaptor closure object.
+   //
+   // We handle (1) and (2) here, and (3) is just a special case of a
+   // more general case already handled by _RangeAdaptorClosure.
if constexpr (is_invocable_v<_Callable, _Args...>)
  {
static_assert(sizeof...(_Args) != 1,
  "a _RangeAdaptor that accepts only one argument "
  "should be defined as a _RangeAdaptorClosure");
+   // Here we handle adaptor(range, args...) -- just forward all
+   // arguments to the underlying adaptor routine.
return _Callable{}(std::forward<_Args>(__args)...);
  }
else
  {
-   auto __closure = [__args...]  (_Range&& __r) {
- return _Callable{}(std::forward<_Range>(__r), __args...);
-   };
+   // Here we handle adaptor(args...)(range).
+   // Given args..., we return a _RangeAdaptorClosure that takes a
+   // range argument, such that (2) is equivalent to (1).
+   //
+   // We need to be careful about how we capture args... in this
+   // closure.  By using __maybe_refwrap, we capture lvalue
+   // references by reference (through a reference_wrapper) and
+   // otherwise capture by value.
+   auto __closure
+ = [...__args(__maybe_refwrap(std::forward<_Args>(__args)))]
+(_Range&& __r) {
+ // This static_cast has two purposes: it forwards a
+ // reference_wrapper capture as a T&, and otherwise
+ // forwards the captured argument as an rvalue.
+ return _Callable{}(std::forward<_Range>(__r),
+  (static_cast>>
+   (__args))...);
+   };
using _ClosureType = decltype(__closure);
return _RangeAdaptorClosure<_ClosureType>(std::move(__closure));
  }
diff --git a/libstdc++-v3/testsuite/s

[patch,committed] OpenACC's tile clause fix for implicit typing (PR93825)

[Tobias Burnus]

I committed it as simple and obvious patch, but
of course I am happy for comment :-)

OpenACC loop directives can have both 'collapse' and 'tile'
clauses. They are resolved as follows:
* gfc_resolve_oacc_blocks is called, which in turn calls
  resolve_oacc_loop_blocks followed by gfc_resolve_blocks,
* Then gfc_resolve_oacc_directive is called, which calls
  resolve_oacc_loop

It turned out that one needs to handle first the checks
in resolve_oacc_loop_blocks for the clauses itself – if one
moved this call after the gfc_resolve_blocks in the
callee gfc_resolve_oacc_blocks it won't work.

On the other hand, if one directly calls resolve_oacc_nested_loops
within resolve_oacc_loop_blocks, the loop data (code->ext.iterator)
is not yet resolved. – That's visible in the included test case as
the variables are still BT_UNKNOWN instead of implicitly being typed
to integer.

Hence, the solution is to keep the clause checks in
resolve_oacc_loop_blocks but move the checking of the loop data
(via resolve_oacc_nested_loops) to resolve_oacc_loop — next to
the handling for collapsed, which also makes sense code-organization
wise.

NOTE: In line with the tree-conversion code, which does ignore "collapse",
this check ignores "collapse" in terms of checking. That only matters if
"n" in collapse(n) is greater than the "n" in "tile" as otherwise all the
check are already done for "tile".

Installed as Rev. r10-6761-g2c52b2884ba10b1c5050fe066bae651680c8ebae

Cheers,

Tobias

commit 2c52b2884ba10b1c5050fe066bae651680c8ebae
Author: Tobias Burnus 
Date:   Thu Feb 20 18:11:32 2020 +0100

OpenACC's tile clause fix for implicit typing (PR93825)

2020-02-20  Tobias Burnus  

PR fortran/93825
* openmp.c (resolve_oacc_loop_blocks): Move call to
resolve_oacc_nested_loops from here ...
(resolve_oacc_loop): ... to here.

PR fortran/93825
* gfortran.dg/goacc/tile-3.f90: New.
---
 gcc/fortran/ChangeLog  | 25 -
 gcc/fortran/openmp.c   | 15 ---
 gcc/testsuite/ChangeLog|  5 +
 gcc/testsuite/gfortran.dg/goacc/tile-3.f90 | 13 +
 4 files changed, 46 insertions(+), 12 deletions(-)

diff --git a/gcc/fortran/ChangeLog b/gcc/fortran/ChangeLog
index 7547dccd79a..6795b82b74c 100644
--- a/gcc/fortran/ChangeLog
+++ b/gcc/fortran/ChangeLog
@@ -1,3 +1,10 @@
+2020-02-20  Tobias Burnus  
+
+	PR fortran/93825
+	* openmp.c (resolve_oacc_loop_blocks): Move call to
+	resolve_oacc_nested_loops from here ...
+	(resolve_oacc_loop): ... to here.
+
 2020-02-18  Mark Eggleston  
 
 	PR fortran/93714
@@ -29,15 +36,15 @@
 
 2020-02-10  Andrew Benson  
 
-PR fortran/83113
-* array.c: Do not attempt to set the array spec for a submodule
-function symbol (as it has already been set in the corresponding
-module procedure interface).
-* symbol.c: Do not reject duplicate POINTER, ALLOCATABLE, or
-DIMENSION attributes in declarations of a submodule function.
-* gfortran.h: Add a macro that tests for a module procedure in a
-submodule.
-* gfortran.dg/pr83113.f90: New test.
+	PR fortran/83113
+	* array.c: Do not attempt to set the array spec for a submodule
+	function symbol (as it has already been set in the corresponding
+	module procedure interface).
+	* symbol.c: Do not reject duplicate POINTER, ALLOCATABLE, or
+	DIMENSION attributes in declarations of a submodule function.
+	* gfortran.h: Add a macro that tests for a module procedure in a
+	submodule.
+	* gfortran.dg/pr83113.f90: New test.
 
 2020-02-03  Julian Brown  
 	Tobias Burnus  
diff --git a/gcc/fortran/openmp.c b/gcc/fortran/openmp.c
index b885e86c658..35f6b2f4938 100644
--- a/gcc/fortran/openmp.c
+++ b/gcc/fortran/openmp.c
@@ -6192,10 +6192,8 @@ resolve_oacc_loop_blocks (gfc_code *code)
   if (code->ext.omp_clauses->tile_list)
 {
   gfc_expr_list *el;
-  int num = 0;
   for (el = code->ext.omp_clauses->tile_list; el; el = el->next)
 	{
-	  num++;
 	  if (el->expr == NULL)
 	{
 	  /* NULL expressions are used to represent '*' arguments.
@@ -6213,7 +6211,6 @@ resolve_oacc_loop_blocks (gfc_code *code)
 			   &code->loc);
 	}
 	}
-  resolve_oacc_nested_loops (code, code->block->next, num, "tiled");
 }
 }
 
@@ -6266,6 +6263,18 @@ resolve_oacc_loop (gfc_code *code)
   do_code = code->block->next;
   collapse = code->ext.omp_clauses->collapse;
 
+  /* Both collapsed and tiled loops are lowered the same way, but are not
+ compatible.  In gfc_trans_omp_do, the tile is prioritized.  */
+  if (code->ext.omp_clauses->tile_list)
+{
+  int num = 0;
+  gfc_expr_list *el;
+  for (el = code->ext.omp_clauses->tile_list; el; el = el->next)
+	++num;
+  resolve_oacc_nested_loops (code, code->block->next, num, "tiled");
+  return;
+}
+
   if (collapse <= 0)
 collapse = 1;
   resolve_oacc_ne

Re: [PATCH] rs6000: Fix infinite loop building ghostscript and icu [PR93658]

[Peter Bergner]

On 2/20/20 1:47 AM, Segher Boessenkool wrote:
> On Wed, Feb 19, 2020 at 09:17:26PM -0600, Peter Bergner wrote:
>> This passed bootstrap and regtesting on powerpc64le-linux and powerpc64-linux
>> (in both 32-bit and 64-bit modes) with no regressions.  Ok for trunk?
>> The same bug exists in FSF 9 anf FSF 8 branches.  Ok for those too after
>> some burn in on trunk and clean regtests on the backports?
> 
> Okay for all.  You may want to check it into 9 a bit faster than usual,
> to meet the release schedule.  It should be perfectly safe enough for
> that.  Do run the regstraps, of course ;-)

Ok, I pushed the trunk fix now.  I'll kick off the release branch
backports now.

Jakub, I know you're getting the GCC 8.4 release ready.  Is this fix ok
for FSF 8 now or do you want me to wait until after 8.4 is out?


Peter

Re: [PATCH 2/2] libstdc++: P1739R4 Avoid template bloat for safe_ranges in combination with ...

[Patrick Palka]

On Thu, 20 Feb 2020, Jonathan Wakely wrote:

> On 19/02/20 23:53 -0500, Patrick Palka wrote:
> > ... 'subrange-y' view adaptors
> > 
> > This implements an interpretation of P1739R4.  It's only an "interpretation"
> > becuase AFAICT there is an issue with the paper's wording as-is.  So this
> > patch
> > deviates from paper when it comes to the problematic wording.
> > 
> > The issue is that the paper's wording for views::take requires that the
> > views::take of a specialization of subrange is not just another subrange,
> > but
> > specifically is the same specialization as the input subrange.
> > But if, say, the input subrange does not model common_range, then the
> > expression
> > in section 6.1
> > 
> >T{begin(E), begin(E) + min(size(E), F)}
> > 
> > is ill-formed because T -- a specialization of subrange which does not model
> > common_range -- must be constructed with an iterator-sentinel pair and not
> > an
> > iterator-iterator pair.  A similar issue arises with the views::take of an
> > iota_view whose value type differs from the type of its bound.
> > 
> > So in light of this issue, this patch deviates from the paper's wording here
> > by
> > allowing the views::take of a subrange/iota_view input to be a different
> > specialization than that of the input.
> > 
> > Moreover, I found myself needing to define an extra constrained constructor
> > iota_view(iterator_, iterator_) alongside the newly added
> > iota_view(iterator_, sentinel_) constructor, so that the expression
> > in views::take
> > 
> >iota_view{begin(E), begin(E) + min(size(E), F)}
> > 
> > is well-formed in general.  Despite these deviations, the intended end
> > result
> > remains the same AFAICT.
> 
> Please be sure to report these to the LWG chair address so issues can
> be opened.

Sounds good, I will report them issues probably today or tomorrow.

> 
> > @@ -1965,10 +1993,70 @@ namespace views
> > 
> >   namespace views
> >   {
> > +namespace __detail
> > +{
> > +  template
> > +   inline constexpr bool __is_empty_view = false;
> > +
> > +  template
> > +   inline constexpr bool __is_empty_view> = true;
> > +
> > +  template
> > +   inline constexpr bool __is_dynamic_span = false;
> > +
> > +  template
> > +   inline constexpr bool __is_dynamic_span>
> > + = true;
> > +
> > +  template
> > +   inline constexpr bool __is_basic_string_view = false;
> > +
> > +  template
> > +   inline constexpr bool
> > + __is_basic_string_view> = true;
> 
> I think it should be possible to define these without including 
> and . Either by adding forward declarations of span and
> basic_string_view, which is sufficient to define the variable template
> specializations, or by defining something here and specializing it in
>  and  e.g. in :
> 
>   template
> inline constexpr bool __is_viewish = false;
> 
> And then in  add:
> 
>   template
> extern inline const bool __is_viewish;
>   template
> inline constexpr bool __is_viewish> = true;
> 
> The first declaration is needed so that  works without including
> , and vice versa.
> 
> And in :
> 
> #if __cplusplus > 201703L
>   template
> extern inline const bool __is_viewish;
>   template
> inline constexpr bool __is_viewish>
>   = true;
> #endif
> 
> That way we don't need to declare span and string_view in  at
> all. We also don't need two separate variables, one will do. And
> finally, doing it this way allows us to enable this feature for
> experimental::basic_string_view too:
> 
> And in :
> 
> #if __cplusplus > 201703L
>   template
> extern inline const bool __is_viewish;
>   template
> inline constexpr bool
>   __is_viewish> = true;
> #endif
> 
> This last specialization *must* be defined in
>  not in , because we don't want to
> "leak" the non-reserved "experimental" name into  when the
> user hasn't explicitly included a TS header.
> 
> A better name than "viewish" would be nice, but it does look like we
> can use the same one for span and string_view, since you always treat
> them the same.

Thanks for the detailed explanation.  I'll update the patch to use this
design.

Re: [PATCH 1/2] libstdc++: Forward second argument of views::iota using the correct type

[Patrick Palka]

On Thu, 20 Feb 2020, Jonathan Wakely wrote:

> On 19/02/20 23:53 -0500, Patrick Palka wrote:
> > We are forwarding the second argument of views::iota using the wrong type,
> > causing compiling errors when calling it with a value and bound of different
> > types, like in the test case below.
> 
> Good catch, OK for master.

Oops, the second patch in this series includes a friendship change that
should instead be a part of this patch: iota_view::_Iterator must
befriend iota_view::_Sentinel, so that iota_view::_Sentinel::operator==
can access its private members.  This is needed for the new test in
iota_view.cc to compile.

Tested on x86_64-pc-linux-gnu, does this look OK to commit?

-- >8 --

Subject: [PATCH] libstdc++: Forward second argument of views::iota using the
 correct type

We are forwarding the second argument of views::iota using the wrong type,
causing compile errors when calling views::iota with a value and bound of
different types, like in the test case below.

libstdc++-v3/ChangeLog:

* include/std/ranges (iota_view): Forward declare _Sentinel.
(iota_view::_Iterator): Befriend _Sentinel.
(iota_view::_Sentinel::_M_equal): New member function.
(iota_view::_Sentinel::operator==): Use it.
(views::_Iota::operator()): Forward __f using the correct type.
* testsuite/std/ranges/access/ssize.cc (test06): Don't call views::iota
with integers of different signedness, to appease iota_view's deduction
guide.
* testsuite/std/ranges/iota/iota_view.cc: Augment test.
---
 libstdc++-v3/ChangeLog  |  9 +
 libstdc++-v3/include/std/ranges | 12 ++--
 .../testsuite/std/ranges/access/ssize.cc|  2 +-
 .../testsuite/std/ranges/iota/iota_view.cc  | 17 +
 4 files changed, 37 insertions(+), 3 deletions(-)

diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog
index 30cf706cdae..90098fa9aa5 100644
--- a/libstdc++-v3/ChangeLog
+++ b/libstdc++-v3/ChangeLog
@@ -1,3 +1,12 @@
+2020-02-20  Patrick Palka  
+
+   * include/std/ranges (views::_Iota::operator()): Forward __f using the
+   correct type.
+   * testsuite/std/ranges/access/ssize.cc (test06): Don't call views::iota
+   with integers of different signedness, to appease iota_view's deduction
+   guide.
+   * testsuite/std/ranges/iota/iota_view.cc: Augment test.
+
 2020-02-20  Jonathan Wakely  
 
* include/bits/range_access.h (ranges::begin): Reject array of
diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index 7a66491f2e4..6358ce86f79 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -635,6 +635,8 @@ namespace ranges
 class iota_view : public view_interface>
 {
 private:
+  struct _Sentinel;
+
   struct _Iterator
   {
   private:
@@ -811,11 +813,17 @@ namespace ranges
 
   private:
_Winc _M_value = _Winc();
+
+friend _Sentinel;
   };
 
   struct _Sentinel
   {
   private:
+   constexpr bool
+   _M_equal(const _Iterator& __x) const
+   { return __x._M_value == _M_bound; }
+
_Bound _M_bound = _Bound();
 
   public:
@@ -827,7 +835,7 @@ namespace ranges
 
friend constexpr bool
operator==(const _Iterator& __x, const _Sentinel& __y)
-   { return __x._M_value == __y._M_bound; }
+   { return __y._M_equal(__x); }
 
friend constexpr iter_difference_t<_Winc>
operator-(const _Iterator& __x, const _Sentinel& __y)
@@ -933,7 +941,7 @@ namespace views
 template
   constexpr auto
   operator()(_Tp&& __e, _Up&& __f) const
-  { return iota_view{std::forward<_Tp>(__e), std::forward<_Tp>(__f)}; }
+  { return iota_view{std::forward<_Tp>(__e), std::forward<_Up>(__f)}; }
   };
 
   inline constexpr _Iota iota{};
diff --git a/libstdc++-v3/testsuite/std/ranges/access/ssize.cc 
b/libstdc++-v3/testsuite/std/ranges/access/ssize.cc
index 6f5478e2bb1..8423654c5f7 100644
--- a/libstdc++-v3/testsuite/std/ranges/access/ssize.cc
+++ b/libstdc++-v3/testsuite/std/ranges/access/ssize.cc
@@ -75,7 +75,7 @@ test05()
 void
 test06()
 {
-  auto i = std::views::iota(1ull, 5);
+  auto i = std::views::iota(1ull, 5u);
   auto s = std::ranges::ssize(i);
   using R = std::ranges::range_difference_t;
   static_assert( std::same_as );
diff --git a/libstdc++-v3/testsuite/std/ranges/iota/iota_view.cc 
b/libstdc++-v3/testsuite/std/ranges/iota/iota_view.cc
index 798e745d3f0..65d166fbd3b 100644
--- a/libstdc++-v3/testsuite/std/ranges/iota/iota_view.cc
+++ b/libstdc++-v3/testsuite/std/ranges/iota/iota_view.cc
@@ -61,10 +61,27 @@ test03()
   VERIFY( it == v.end() );
 }
 
+void
+test04()
+{
+  int x[] = {1,2,3};
+  auto v = std::ranges::views::iota(std::counted_iterator(x, 3),
+   std::default_sentinel);
+  auto it = v.begin();
+  VERIFY( (*it).base() == x );
+  ++it;
+  VERIFY( (*it).base() == x

Re: [PATCH] libstdc++: Fix capturing of lvalue references in_RangeAdaptor::operator()

[Jonathan Wakely]

On 20/02/20 12:19 -0500, Patrick Palka wrote:

This fixes a dangling-reference issue with views::split and other multi-argument
adaptors that may take its extra arguments by reference.

When creating the _RangeAdaptorClosure in _RangeAdaptor::operator(), we
currently capture all provided arguments by value.  When we later use the
_RangeAdaptorClosure and call it with a range, as in e.g.

   v = views::split(p)(range),

we forward the range and the captures to the underlying adaptor routine.  But
then when the temporary _RangeAdaptorClosure goes out of scope, the by-value
captures get destroyed and the references to these capture in the resulting view
become dangling.

This patch fixes this problem by capturing lvalue references by reference in
_RangeAdaptorClosure::operator(), and then forwarding the captures appropriately
to the underlying range adaptor.


OK for master. Thanks for figuring this one out.

Re: [PATCH 1/2] libstdc++: Forward second argument of views::iota using the correct type

[Jonathan Wakely]

On 20/02/20 12:52 -0500, Patrick Palka wrote:

On Thu, 20 Feb 2020, Jonathan Wakely wrote:


On 19/02/20 23:53 -0500, Patrick Palka wrote:
> We are forwarding the second argument of views::iota using the wrong type,
> causing compiling errors when calling it with a value and bound of different
> types, like in the test case below.

Good catch, OK for master.


Oops, the second patch in this series includes a friendship change that
should instead be a part of this patch: iota_view::_Iterator must
befriend iota_view::_Sentinel, so that iota_view::_Sentinel::operator==
can access its private members.  This is needed for the new test in
iota_view.cc to compile.

Tested on x86_64-pc-linux-gnu, does this look OK to commit?


Yes, OK for master.

Re: [RFC PATCH v0] PPC64: Implement POWER Architecure Vector Function ABI.

[GT]

‐‐‐ Original Message ‐‐‐
On Wednesday, February 19, 2020 12:33 PM, Bill Schmidt  
wrote:

> > The reason 'c' was added to the ABI is this mailing list discussion:
> > https://sourceware.org/ml/libc-alpha/2019-11/msg00765.html
> > As long as 'b' specifies that the VSX functionality is that specified in 
> > ISA v2.07,
> > I suggest that we delete the reference to 'c' in the ABI. Bill, Tulio?
>
> No, I don't think that's the right call.  We want to leverage ISA 3.0
> instructionsin vector implementations when they are available, so we
> need the 'c' ABI for that purpose.  In future we are likely to add a
> 'd' ABI for a future processor if it adds more vector capability.  So
> emitting both and letting the vectorized callers choose, as Jakub
> suggests, seems like the right way to go.  This is true even if the
> current implementations are identical (i.e., don't exploit any ISA
> 3.0 instructions).
>

Because of the issue at 
https://gcc.gnu.org/ml/gcc-patches/2020-02/msg01171.html, I
am coming back to whether or not to include VSX extensions for ISA 3.0 in the 
Vector
Function ABI Specification.

If we retain 'c' in the ABI Spec., then GCC will expect libmvec functions such 
as
_ZGVcN2v_sin. The changes made to GLIBC for POWER libmvec don't have these 
functions
with  == 'c'. Only those with  == 'b' have been implemented. So we 
have to
do either of:

1. Create all those 'c' variants in GLIBC libmvec, even though they will be 
identical
to the existing 'b' versions.
2. Remove all references to 'c' in the ABI Specification, and leave GCC 
expecting to
find only 'b' variants in libmvec.

If/when it becomes necessary to have 'c' variants of functions, then a new 
version of
the Vector Function ABI document will be created. And GLIBC and GCC 
modifications to
comply with that new ABI will be made then.

Bert.

Re: [PATCH] Fix -save-temp leaking lto files in /tmp

[Bernd Edlinger]

Hi Tobias,

On 2/20/20 5:09 PM, Tobias Burnus wrote:
> Hi Bernd, hi all,
> 
> note that you can get even more files: If you do offloading,
> LTO is additionally run for each offloading target (there
> can be more than one), cf. https://gcc.gnu.org/wiki/Offloading
> 
> Some of those files are probably also from mkoffload etc.
> See below.
> 
> On 2/20/20 4:33 PM, Bernd Edlinger wrote:
> 
>> On 2/20/20 2:34 PM, Richard Biener wrote:
>>> I don't think this is an improvement.  The files still
>>> will be (correctly) retained and now in addition to that
>>> there's temporary directories piling up?
>> Well, the temp. directory has a known name,
>> in case the command line is
>>
>> gcc -save-temps -lto -o test test.c
>>
>> there are those 4 in a *known* place, test.lto_tmpdir:
> 
> Here, with offloading (compiler only supports one
> offloading target), I get for
>    gfortran -fopenacc -save-temps -o test kernels-map-2.F90
> 
> (1) in the current directory:
> kernels-map-2.f90
> kernels-map-2.o
> test.lto_wrapper_args
> kernels-map-2.res
> kernels-map-2.s
> ccv97orQ.i
> ccv97orQ.s
> 
> (2) in /tmp:
> ccXtFBKP.ofldlist
> cckm9TaT
> cc1aPJVX
> ccwnCSfQ
> ccEwCVRX
> ccv97orQ.c
> ccgtnzbU.mkoffload
> ccsZzs01
> ccouoZqP.target.o
> cc6o87mX.crtoffloadtable.o
> test
> 
> And with "-flto" in addition:
> 
> (1) Current directory:
> kernels-map-2.f90
> kernels-map-2.o
> test.lto_wrapper_args
> kernels-map-2.res
> kernels-map-2.s
> ccdBFFxF.i
> ccdBFFxF.s
> test.ltrans0.o
> test.ltrans.out
> test.ltrans0.s
> test.ltrans0.ltrans.o
> test
> 
> (2) in /tmp:
> ccX5EDTE.ofldlist
> ccpAKbE7
> ccxnuNsz
> ccq5sdmF
> ccWUsloz
> ccZ5rev7.mkoffload
> ccdBFFxF.c
> cc3PGOK1
> ccW4hTGF.target.o
> ccWH1ft2
> ccsKJG3z.crtoffloadtable.o
> ccmE0bPK
> ccB54fLv
> cckO6O6c
> 

I cannot test anything with offload, because that setup is out of my reach.
I believe this patch will improve the situation significantly, but I would
be curious to know if the temp files move away from /tmp if you
might give this patch a try.  It will not prevent the ccX.i/s
in the $PWD, unfortunately.


Thanks
Bernd.

[committed] i386: Fix *vec_extractv2sf_1 and *vec_extractv2sf_1 shufps alternative [PR93828]

[Uros Bizjak]

shufps moves two of the four packed single-precision floating-point values
from *destination* operand (first operand) into the low quadword of the
destination operand.  Match source operand to the destination.

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

Committed to mainline.

The testcase is relevant only for MMX_WITH_SSE, the fix will be
committed to release branches without testcase.

2020-02-20  Uroš Bizjak  

PR target/93828
* config/i386/mmx.md (*vec_extractv2sf_1): Match source operand
to destination operand for shufps alternative.
(*vec_extractv2si_1): Ditto.

testsuite/ChangeLog:

2020-02-20  Uroš Bizjak  

PR target/93828
* g++.target/i386/pr93828.C: New test.

Uros.
diff --git a/gcc/config/i386/mmx.md b/gcc/config/i386/mmx.md
index f695831b5b9..e1c8b0af4c7 100644
--- a/gcc/config/i386/mmx.md
+++ b/gcc/config/i386/mmx.md
@@ -645,14 +645,14 @@
 (define_insn "*vec_extractv2sf_1"
   [(set (match_operand:SF 0 "nonimmediate_operand" "=y,x,x,y,x,f,r")
(vec_select:SF
- (match_operand:V2SF 1 "nonimmediate_operand" " 0,x,x,o,o,o,o")
+ (match_operand:V2SF 1 "nonimmediate_operand" " 0,x,0,o,o,o,o")
  (parallel [(const_int 1)])))]
   "(TARGET_MMX || TARGET_MMX_WITH_SSE)
&& !(MEM_P (operands[0]) && MEM_P (operands[1]))"
   "@
punpckhdq\t%0, %0
%vmovshdup\t{%1, %0|%0, %1}
-   shufps\t{$0xe5, %1, %0|%0, %1, 0xe5}
+   shufps\t{$0xe5, %0, %0|%0, %0, 0xe5}
#
#
#
@@ -1794,7 +1794,7 @@
 (define_insn "*vec_extractv2si_1"
   [(set (match_operand:SI 0 "nonimmediate_operand" "=y,rm,x,x,y,x,r")
(vec_select:SI
- (match_operand:V2SI 1 "nonimmediate_operand" " 0,x ,x,x,o,o,o")
+ (match_operand:V2SI 1 "nonimmediate_operand" " 0,x ,x,0,o,o,o")
  (parallel [(const_int 1)])))]
   "(TARGET_MMX || TARGET_MMX_WITH_SSE)
&& !(MEM_P (operands[0]) && MEM_P (operands[1]))"
@@ -1802,7 +1802,7 @@
punpckhdq\t%0, %0
%vpextrd\t{$1, %1, %0|%0, %1, 1}
%vpshufd\t{$0xe5, %1, %0|%0, %1, 0xe5}
-   shufps\t{$0xe5, %1, %0|%0, %1, 0xe5}
+   shufps\t{$0xe5, %0, %0|%0, %0, 0xe5}
#
#
#"
diff --git a/gcc/testsuite/g++.target/i386/pr93828.C 
b/gcc/testsuite/g++.target/i386/pr93828.C
new file mode 100644
index 000..e0c19751599
--- /dev/null
+++ b/gcc/testsuite/g++.target/i386/pr93828.C
@@ -0,0 +1,17 @@
+// { dg-do run }
+// { dg-require-effective-target c++11 }
+// { dg-options "-O2 -march=k8" }
+
+using float2[[gnu::vector_size (8)]] = float;
+using int2[[gnu::vector_size (8)]] = int;
+float2 y = { 2, 2 };
+
+int
+main ()
+{
+  const auto k = y == float2 { 2, 2 };
+  if (k[1] == 0)
+__builtin_abort ();
+  const auto a = k & int2 { 2, 2 };
+  return a[0] - 2;
+}

[PING^2][PATCH] Fix documentation of -mpoke-function-name ARM option

[Jérémy Lefaure]

Hello,

Ping for https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01081.html.

Thank you,
Jérémy

On Sun, Dec 15, 2019 at 07:20:26PM +0100, Jérémy Lefaure wrote:
> Hi!
> 
> Since in ARM state the value of PC is the address of the current
> instruction plus 8 bytes, the code inspecting the value of PC stored at
> FP + 0 should look at location PC - 16 : PC - 8 points to the stmfd
> instruction, PC - 16 points two words before, where the top 8 bits are
> set.
> 
> gcc/
> 2019-12-14  Jérémy Lefaure 
> 
>   * config/arm/arm.c (-mpoke-function-name): Fix documentation in comment.
>   * doc/invoke.texi (-mpoke-function-name): Fix documentation.
> 

Re: [PATCH] avoid issuing -Wredundant-tags in shared C/C++ code in headers (PR 93804)

[Martin Sebor]

On 2/19/20 5:09 PM, Jason Merrill wrote:

On 2/19/20 1:02 AM, Martin Sebor wrote:

PR 93804 points out that issuing -Wredundant-tags for declarations
in C headers included in C++ isn't helpful because the tags cannot
be removed without breaking C programs that depend on the headers.

Attached is a patch that avoids the warning in these cases tested
on x86_64-linux.  While strictly not a regression (and even though
I initially considered it a GCC 11 enhancement), since most C++
code includes some C headers, without the patch the warning would
likely cause too much noise to be widely useful.



+  const line_map_ordinary *map = NULL;
+  linemap_resolve_location (line_table, key_loc,
+    LRK_MACRO_DEFINITION_LOCATION,
+    &map);
+  if (!MAIN_FILE_P (map))
+    key_redundant = false;


Checking which file it came from seems like unnecessary complication; is 
it important to still warn in extern "C" blocks in the main source file?


It's only important if someone is relying on it to avoid the redundant
tags in all their C++ code, e.g., as part of cleaning up -Wmismatched-
tags.  The latter will complain about mismatches in extern "C" blocks
and suggest either dropping the tag or replacing it, whichever is
appropriate.  I'd view it as a bug if -Wredundant-tags didn't do
the same since that's its one and only job.

I attach a slightly revised patch that also handles enums (as pointed
out by Stephan), and with beefed up tests.  Retested on x86_64-linux.

If you find the linemap code distracting, or even the warning code,
I can factor it out and into a helper function.

Martin
PR c++/93804 - exempt extern C headers from -Wredundant-tags

gcc/cp/ChangeLog:

	PR c++/93804
	* parser.c (cp_parser_check_class_key): Avoid issuing -Wredundant-tags
	in shared C/C++ code in headers.

gcc/testsuite/ChangeLog:

	PR c++/93804
	* g++.dg/warn/Wredundant-tags-4.C: New test.
	* g++.dg/warn/Wredundant-tags-5.C: New test.
	* g++.dg/warn/Wredundant-tags-5.h: New test.

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index ee534b5db21..21ce05ea05a 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -30826,15 +30826,31 @@ cp_parser_maybe_warn_enum_key (cp_parser *parser, location_t key_loc,
   /* The enum-key is redundant for uses of the TYPE that are not
  declarations and for which name lookup returns just the type
  itself.  */
-  if (decl == type_decl)
-{
-  gcc_rich_location richloc (key_loc);
-  richloc.add_fixit_remove (key_loc);
-  warning_at (&richloc, OPT_Wredundant_tags,
-		  "redundant enum-key % in reference to %q#T",
-		  (scoped_key == RID_CLASS ? " class"
-		   : scoped_key == RID_STRUCT ? " struct" : ""), type);
+  if (decl != type_decl)
+return;
+
+  if (scoped_key != RID_CLASS
+  && scoped_key != RID_STRUCT
+  && current_lang_name != lang_name_cplusplus
+  && current_namespace == global_namespace)
+{
+  /* Avoid issuing the diagnostic for apparently redundant (unscoped)
+	 enum tag in shared C/C++ code in files (such as headers) included
+	 in the main source file.  */
+  const line_map_ordinary *map = NULL;
+  linemap_resolve_location (line_table, key_loc,
+LRK_MACRO_DEFINITION_LOCATION,
+&map);
+  if (!MAIN_FILE_P (map))
+	return;
 }
+
+  gcc_rich_location richloc (key_loc);
+  richloc.add_fixit_remove (key_loc);
+  warning_at (&richloc, OPT_Wredundant_tags,
+	  "redundant enum-key % in reference to %q#T",
+	  (scoped_key == RID_CLASS ? " class"
+	   : scoped_key == RID_STRUCT ? " struct" : ""), type);
 }
 
 /* Describes the set of declarations of a struct, class, or class template
@@ -30995,6 +31011,13 @@ cp_parser_check_class_key (cp_parser *parser, location_t key_loc,
   tree decl = cp_parser_lookup_name_simple (parser, name, input_location);
   pop_deferring_access_checks ();
 
+  /* Only consider the true class-keys below and ignore typename_type,
+ etc. that are not C++ class-keys.  */
+  if (class_key != class_type
+  && class_key != record_type
+  && class_key != union_type)
+return;
+
   /* Only consider the true class-keys below and ignore typename_type,
  etc. that are not C++ class-keys.  */
   if (class_key != class_type
@@ -31006,15 +31029,32 @@ cp_parser_check_class_key (cp_parser *parser, location_t key_loc,
  neither definitions of it nor declarations, and for which name
  lookup returns just the type itself.  */
   bool key_redundant = !def_p && !decl_p && decl == type_decl;
+
+  if (key_redundant
+  && class_key != class_type
+  && current_lang_name != lang_name_cplusplus
+  && current_namespace == global_namespace)
+{
+  /* Avoid issuing the diagnostic for apparently redundant struct
+	 and union class-keys in shared C/C++ code in files (such as
+	 headers) included in the main source file.  */
+  const line_map_ordinary *map = NULL;
+  linemap_resolve_location (line_table, key_loc,
+LRK_MACRO_DEFINITION_LOCATION,

[PATCH] c++: Some improvements to concept diagnostics

[Patrick Palka]

This patch improves our concept diagnostics in two ways.  First, it sets a more
precise location for the constraint expressions built in
finish_constraint_binary_op.  As a result, when a disjunction is unsatisfied we
now print e.g.

.../include/bits/range_access.h:467:2: note: neither operand of the disjunction 
is satisfied
  466 |  requires is_bounded_array_v> || 
__member_end<_Tp>
  |   

  467 |  || __adl_end<_Tp>
  |  ^

instead of

.../include/bits/range_access.h:467:2: note: neither operand of the disjunction 
is satisfied
  467 |  || __adl_end<_Tp>
  |  ^~

Second, this patch changes diagnose_atomic_constraint to pretty-print
unsatisfied atomic constraint expressions with their template arguments
substituted in (if doing so does not result in a trivial expression).  So for
example we now emit

cpp2a/concepts-pr67719.C:9:8: note: the expression ‘((C() && C()) && C())’ evaluated to ‘false’

instead of

cpp2a/concepts-pr67719.C:9:8: note: the expression ‘(... &&(C)())’ 
evaluated to ‘false’

Tested on x86_64-pc-linux-gnu, and verified that all the diagnostics emitted in
our concept tests are no worse with this patch.  Does this look OK to commit?

gcc/cp/ChangeLog:

* constraint.cc (finish_constraint_binary_op): Set expr's location range
to the range of its operands.
(diagnose_atomic_constraint): Prefer to pretty-print the atomic
constraint with template arguments substituted in.

gcc/testsuite/ChangeLog:

* g++.dg/concepts/diagnostic2.C: New test.
* g++.dg/concepts/diagnostic3.C: New test.
---
 gcc/cp/constraint.cc| 15 +++
 gcc/testsuite/g++.dg/concepts/diagnostic2.C | 30 +
 gcc/testsuite/g++.dg/concepts/diagnostic3.C | 19 +
 3 files changed, 59 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/concepts/diagnostic2.C
 create mode 100644 gcc/testsuite/g++.dg/concepts/diagnostic3.C

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index 58044cd0f9d..4f6bc11e7e8 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -155,14 +155,14 @@ finish_constraint_binary_op (location_t loc,
   if (!check_constraint_operands (loc, lhs, rhs))
 return error_mark_node;
   tree overload;
-  tree expr = build_x_binary_op (loc, code,
-lhs, TREE_CODE (lhs),
-rhs, TREE_CODE (rhs),
-&overload, tf_none);
+  cp_expr expr = build_x_binary_op (loc, code,
+   lhs, TREE_CODE (lhs),
+   rhs, TREE_CODE (rhs),
+   &overload, tf_none);
   /* When either operand is dependent, the overload set may be non-empty.  */
   if (expr == error_mark_node)
 return error_mark_node;
-  SET_EXPR_LOCATION (expr, loc);
+  expr.set_range (lhs.get_start (), rhs.get_finish ());
   return expr;
 }
 
@@ -3330,6 +3330,11 @@ diagnose_atomic_constraint (tree t, tree args, 
subst_info info)
   inform (loc, "%qE is never satisfied", expr);
   break;
 default:
+  tree orig_expr = expr;
+  expr = tsubst_expr (expr, args, tf_none, NULL_TREE, false);
+  if (CONSTANT_CLASS_P (expr))
+   /* We are better off printing the original expression.  */
+   expr = orig_expr;
   inform (loc, "the expression %qE evaluated to %", expr);
 }
 }
diff --git a/gcc/testsuite/g++.dg/concepts/diagnostic2.C 
b/gcc/testsuite/g++.dg/concepts/diagnostic2.C
new file mode 100644
index 000..ce51b71fa8b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/concepts/diagnostic2.C
@@ -0,0 +1,30 @@
+// { dg-do compile { target c++2a } }
+// { dg-options "-fdiagnostics-show-caret" }
+
+template
+  inline constexpr bool foo_v = false;
+
+template
+  concept foo = foo_v || foo_v; // { dg-message "neither operand" }
+/* { dg-begin-multiline-output "" }
+   concept foo = foo_v || foo_v;
+ ~^~~~
+   { dg-end-multiline-output "" } */
+
+template
+  requires foo
+  void bar();
+/* { dg-begin-multiline-output "" }
+   void bar();
+   { dg-end-multiline-output "" } */
+/* { dg-prune-output "~" } */
+
+void
+baz()
+{
+  bar(); // { dg-error "unsatisfied constraints" }
+/* { dg-begin-multiline-output "" }
+   bar();
+^
+   { dg-end-multiline-output "" } */
+}
diff --git a/gcc/testsuite/g++.dg/concepts/diagnostic3.C 
b/gcc/testsuite/g++.dg/concepts/diagnostic3.C
new file mode 100644
index 000..e0649dac51a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/concepts/diagnostic3.C
@@ -0,0 +1,19 @@
+// { dg-do compile { target c++2a } }
+
+template
+  inline constexpr bool foo_v = false;
+
+template
+  concept foo = (bool)(foo_v | foo_v); // { dg-message 
"foo_v.*foo_v" }
+
+template
+requires foo
+void
+bar()
+{ }
+
+void
+baz()
+{
+  bar(); // { dg-error "unsatisfied constraints" }
+}
-- 
2.25.

[fixinc] Allow CONFIG_SHELL to override build-time shell in mkheaders

[Alexandre Oliva]

mkheaders.in uses substitutions of @SHELL@ to run fixinc.sh and
mkinstalldirs.  Problem is, SHELL comes from CONFIG_SHELL for the
build system, and it needs not match whatever is available at an
unrelated host system after installation, when mkheaders is supposed
to be run.

I considered ditching the hardcoding altogether, but decided to retain
it, but allowing CONFIG_SHELL and SHELL to override it, if any of them
can successfully run mkinstalldirs, and if those and the substituted
@SHELL@ fail, fallback to /bin/sh and to plain execution of the
script, which appears to enable at least one shell on a system that
doesn't typicall have a shell to recognize a script by #!/bin/sh and
reinvoke itself to run it.

If all of these fail, we fail, but only after telling the user to
retry after setting CONFIG_SHELL, that fixincl itself also uses.

Tested with a x86_64-linux-gnu native, and on various combinations of
build, host and targets, including cross and canadian crosses involving
host systems that don't have a built-in Bourne Shell.  I'm going ahead
and checking it in as part of the build machinery, though I acknowledge
this might be stretching configury a bit.  Please let me know if you
have any objections to this stretching, or to the change itself.


for  fixincludes/ChangeLog

* mkheaders.in: Don't require build-time shell on host.
---
 fixincludes/mkheaders.in |   22 --
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/fixincludes/mkheaders.in b/fixincludes/mkheaders.in
index a293a57..4109dc6 100644
--- a/fixincludes/mkheaders.in
+++ b/fixincludes/mkheaders.in
@@ -77,11 +77,29 @@ 
libexecsubdir=${libexecdir}/gcc/${target_noncanonical}/${version}
 itoolsdir=${libexecsubdir}/install-tools
 itoolsdatadir=${libsubdir}/install-tools
 incdir=${libsubdir}/include-fixed
-mkinstalldirs="@SHELL@ ${itoolsdir}/mkinstalldirs"
+mkinstalldirs="${itoolsdir}/mkinstalldirs"
 
 cd ${itoolsdir}
 rm -rf ${incdir}/*
 
+for shell in $CONFIG_SHELL $SHELL @SHELL@ /bin/sh ""; do
+  if { test -x $shell || test -x $shell.exe; } \
+  && $shell $mkinstalldirs > /dev/null 2>&1; then
+mkinstalldirs="$shell $mkinstalldirs"
+break
+  elif test x$shell = x; then
+if $mkinstalldirs > /dev/null 2>&1; then
+  break
+elif test ! -f $mkinstalldirs; then
+  echo mkheaders: could not find $mkinstalldirs >&2
+  exit 1
+else
+  echo mkheaders: please rerun with CONFIG_SHELL set to a working Bourne 
shell >&2
+  exit 1
+fi
+  fi
+done
+
 for ml in `cat ${itoolsdatadir}/fixinc_list`; do
   sysroot_headers_suffix=`echo ${ml} | sed -e 's/;.*$//'`
   multi_dir=`echo ${ml} | sed -e 's/^[^;]*;//'`
@@ -91,7 +109,7 @@ for ml in `cat ${itoolsdatadir}/fixinc_list`; do
   if [ x${STMP_FIXINC} != x ] ; then
TARGET_MACHINE="${target}" target_canonical="${target}" \
MACRO_LIST="${itoolsdatadir}/macro_list" \
-   @SHELL@ ./fixinc.sh ${subincdir} \
+   $shell ./fixinc.sh ${subincdir} \
${isysroot}${SYSTEM_HEADER_DIR} ${OTHER_FIXINCLUDES_DIRS}
rm -f ${subincdir}/syslimits.h
if [ -f ${subincdir}/limits.h ]; then

-- 
Alexandre Oliva, freedom fighterhe/himhttps://FSFLA.org/blogs/lxo/
Free Software Evangelist  Stallman was right, but he's left :(
GNU Toolchain Engineer   The darkest places in hell are reserved for those
who maintain their neutrality in times of moral crisis. -- Dante Alighieri

Re: [PATCH] MAINTAINERS: Change to my personal email address

[Palmer Dabbelt]

On Tue, 29 Oct 2019 21:40:09 PDT (-0700), Palmer Dabbelt wrote:

I'm leaving SiFive in a bit less than two weeks, which means I'll be
losing my @sifive email address.  I don't have my new email address yet,
so I'm switching over to my personal address instead.

2019-10-29  Palmer Dabbelt  

* MAINTAINERS: Change pal...@sifive.com to pal...@dabbelt.com.

Signed-off-by: Palmer Dabbelt 
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 78f17c35e9e1..2de8455767fa 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -97,7 +97,7 @@ or1k port Stafford Horne  

 pdp11 port Paul Koning 
 powerpcspe portAndrew Jenner   

 riscv port Kito Cheng  
-riscv port Palmer Dabbelt  
+riscv port Palmer Dabbelt  
 riscv port Andrew Waterman 
 riscv port Jim Wilson  
 rs6000/powerpc portDavid Edelsohn  


Committed (or maybe I say pushed now?) with a more up-to-date message.

Re: [PATCH] Fix -save-temp leaking lto files in /tmp

[Richard Biener]

On Thu, 20 Feb 2020, Bernd Edlinger wrote:

> On 2/20/20 2:34 PM, Richard Biener wrote:
> > On Thu, 20 Feb 2020, Bernd Edlinger wrote:
> > 
> >> Hi,
> >>
> >> this is the remaining issue that happens when -flto and -save-temps
> >> is used together, it leaks several files in /tmp.
> >>
> >> I try to give more background to how these temp files are
> >> created, and in all likelihood the leaking of these
> >> files is wanted, and certainly very helpful for debugging
> >> lto issues, that's for sure.  It is just not helpful
> >> that they need to be looked up in the /tmp folder, even
> >> if you want to debug something with lto.
> >>
> >> The short story is...
> >>
> >> They are created here:
> >>
> >>   if (parallel)
> >> {
> >>   makefile = make_temp_file (".mk");
> >>   mstream = fopen (makefile, "w");
> >>
> >> and here:
> >>
> >>   /* Note: we assume argv contains at least one element; this is
> >>  checked above.  */
> >>
> >>   response_file = make_temp_file ("");
> >>
> >>   f = fopen (response_file, "w");
> >>
> >> And in a few other places as well, it depends a bit
> >> if -o is used or not (i.e. linker_output != NULL or not).
> >>
> >> and not removed here:
> >>
> >>
> >>   if (response_file && !save_temps)
> >> {
> >>   unlink (response_file);
> >>   response_file = NULL;
> >> }
> >>
> >> and here:
> >>
> >>   do_wait (new_argv[0], pex);
> >>   maybe_unlink (makefile);
> >>   makefile = NULL;
> >>
> >>
> >> the code with the response_file is executed both in
> >> lto-wrapper and collect2, but in collect2 only when
> >> if is invoked from lto-wrapper, triggered by the @file
> >> argument list.
> >>
> >> Therefore I figured that the best possible
> >> solution is just let lto-wrapper create a temp-file
> >> for those problem cases, and use TMPDIR to have
> >> all make_temp_file that follow use that to folder to
> >> place the those response files and other stuff in
> >> there.
> >>
> >>
> >> So that is what I split out from the previous patch,
> >> which focused on collect2.
> >>
> >>
> >> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
> >> Is it OK for trunk?
> > 
> > I don't think this is an improvement.  The files still
> > will be (correctly) retained and now in addition to that
> > there's temporary directories piling up?
> > 
> 
> Well, the temp. directory has a known name,
> in case the command line is
> 
> gcc -save-temps -lto -o test test.c
> 
> there are those 4 in a *known* place, test.lto_tmpdir:
> 
> test.lto_tmpdir:
> insgesamt 24
> drwxrwxr-x 2 ed ed 4096 Feb 20 16:14 .
> drwxrwxr-x 3 ed ed 4096 Feb 20 16:14 ..
> -rw--- 1 ed ed   15 Feb 20 16:14 cc8FwPQ1
> -rw--- 1 ed ed  237 Feb 20 16:14 cchROrdh
> -rw--- 1 ed ed  197 Feb 20 16:14 cclbBAUp
> -rw--- 1 ed ed7 Feb 20 16:14 ccMlfh1g
> 
> plus
> -rw-rw-r-- 1 ed ed   164 Feb 20 16:14 test.i
> -rw-rw-r-- 1 ed ed50 Feb 20 16:14 test.lto_wrapper_args
> -rw-rw-r-- 1 ed ed17 Feb 20 16:14 test.ltrans.out
> -rw-rw-r-- 1 ed ed  1232 Feb 20 16:14 test.ltrans0.ltrans.o
> -rw-rw-r-- 1 ed ed  2539 Feb 20 16:14 test.ltrans0.o
> -rw-rw-r-- 1 ed ed   374 Feb 20 16:14 test.ltrans0.s
> -rw-rw-r-- 1 ed ed52 Feb 20 16:14 test.res
> -rw-rw-r-- 1 ed ed  4267 Feb 20 16:14 test.s
> 
> if the command line is
> gcc -save-temps -lto test.c
> 
> there are a few more but also in a *known* place, a.out.lto_tmpdir:
> 
> a.out.lto_tmpdir/
> total 36
> drwxrwxr-x 2 ed ed 4096 Feb 20 16:18 .
> drwxrwxr-x 3 ed ed 4096 Feb 20 16:18 ..
> -rw--- 1 ed ed7 Feb 20 16:18 cc2hY8SH
> -rw--- 1 ed ed  227 Feb 20 16:18 ccDafyit
> -rw--- 1 ed ed  262 Feb 20 16:18 ccglzNAe
> -rw--- 1 ed ed   36 Feb 20 16:18 ccnAU7NG
> -rw--- 1 ed ed   38 Feb 20 16:18 ccoLFY2H.ltrans.out
> -rw-rw-r-- 1 ed ed 1232 Feb 20 16:18 ccoLFY2H.ltrans0.ltrans.o
> -rw-rw-r-- 1 ed ed 2560 Feb 20 16:18 ccoLFY2H.ltrans0.o
> 
> plus
> -rw-rw-r--   1 ed ed50 Feb 20 16:18 a.out.lto_wrapper_args
> -rw-rw-r--   1 ed ed   160 Feb 20 16:18 test.i
> -rw-rw-r--   1 ed ed  3104 Feb 20 16:18 test.o
> -rw-rw-r--   1 ed ed52 Feb 20 16:18 test.res
> -rw-rw-r--   1 ed ed  4267 Feb 20 16:18 test.s
> 
> 
> > A better improvement would be to selectively decide
> > which files might not be needed to be preserved and/or
> > give them names in the build directory in more cases.
> > 
> 
> Ah, well, it just felt like that will probably need a
> rather complicated patch which is probably not
> worth it, since the are a lot of different
> code pathes involved, (with -g or not, with -flto=jobserver
> or not, flto_partition=none, or with offload or not, with -o
> or not etc.) in two or more independent forked processes,
> which will need to coordinate somehow, not to clobber each
> other's tempfiles.

IIRC this definitely clashes with Alex work to overhaul
-auxdir/-dumpdir queued for GCC 11 where some of the above
is improved.

So whatever we do we should do it for GCC 11 after Alex patche