Re: [PATCH] tree-optimization/108522 Use COMPONENT_REF offset when available

[Richard Biener via Gcc-patches]

On Tue, Jan 24, 2023 at 10:54 PM Siddhesh Poyarekar  wrote:
>
> Use the offset in TREE_OPERAND(component_ref, 2) when available instead
> of DECL_FIELD_OFFSET when trying to compute offset for a COMPONENT_REF.
>
> OK for gcc 13 and gcc 12?
>
> Co-authored-by: Jakub Jelinek 
>
> gcc/ChangeLog:
>
> PR tree-optimization/108522
> * tree-object-size.cc (compute_object_offset): Use
> TREE_OPERAND(ref, 2) for COMPONENT_REF when available.
>
> gcc/testsuite/ChangeLog:
>
> PR tree-optimization/108522
> * builtin-dynamic-object-size-0.c (test_dynarray_struct_member):
> new test.
> (main): Call it.
>
> Signed-off-by: Siddhesh Poyarekar 
> ---
> Testing:
>
> - Bootstrapped on x86_64, I'm checking to confirm if a couple of
>   seemingly unrelated failures are in fact unrelated.
> - ubsan config bootstrap and i686 tests in progress
>
>  .../gcc.dg/builtin-dynamic-object-size-0.c   | 16 
>  gcc/tree-object-size.cc  |  4 +++-
>  2 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/testsuite/gcc.dg/builtin-dynamic-object-size-0.c 
> b/gcc/testsuite/gcc.dg/builtin-dynamic-object-size-0.c
> index f9047a037d9..569c0a87722 100644
> --- a/gcc/testsuite/gcc.dg/builtin-dynamic-object-size-0.c
> +++ b/gcc/testsuite/gcc.dg/builtin-dynamic-object-size-0.c
> @@ -314,6 +314,20 @@ test_dynarray_struct_subobj2 (size_t sz, size_t off, 
> size_t *objsz)
>return __builtin_dynamic_object_size (&bin.c[off], 1);
>  }
>
> +/* See pr #108522.  */
> +size_t
> +__attribute__ ((noinline))
> +test_dynarray_struct_member (size_t sz)
> +{
> +  struct
> +{
> +  char a[sz];
> +  char b;
> +} s;
> +
> +  return __builtin_dynamic_object_size (&s.b, 0);
> +}
> +
>  size_t
>  __attribute__ ((noinline))
>  test_substring (size_t sz, size_t off)
> @@ -619,6 +633,8 @@ main (int argc, char **argv)
>if (test_dynarray_struct_subobj2 (42, 4, &objsz)
>  != objsz - 4 - sizeof (long) - sizeof (int))
>  FAIL ();
> +  if (test_dynarray_struct_member (42) != sizeof (char))
> +FAIL ();
>if (test_substring_ptrplus (128, 4) != (128 - 4) * sizeof (int))
>  FAIL ();
>if (test_substring_ptrplus (128, 142) != 0)
> diff --git a/gcc/tree-object-size.cc b/gcc/tree-object-size.cc
> index 356591c22cc..de93ffad9c9 100644
> --- a/gcc/tree-object-size.cc
> +++ b/gcc/tree-object-size.cc
> @@ -412,7 +412,9 @@ compute_object_offset (const_tree expr, const_tree var)
> return base;
>
>t = TREE_OPERAND (expr, 1);
> -  off = size_binop (PLUS_EXPR, DECL_FIELD_OFFSET (t),
> +  off = size_binop (PLUS_EXPR,
> +   (TREE_OPERAND (expr, 2) ? TREE_OPERAND (expr, 2)
> +: DECL_FIELD_OFFSET (t)),

That isn't correct - operand 2 is the field offset in units of
DECL_OFFSET_ALIGN (t) / BITS_PER_UNIT.
See component_ref_filed_offset (), maybe you should be using that
function instead?

> size_int (tree_to_uhwi (DECL_FIELD_BIT_OFFSET (t))
>   / BITS_PER_UNIT));
>break;
> --
> 2.38.1
>

Re: [PATCH v4] xtensa: Eliminate unnecessary general-purpose reg-reg moves

[Max Filippov via Gcc-patches]

Hi Suwa-san,

On Mon, Jan 23, 2023 at 7:43 PM Takayuki 'January June' Suwa
 wrote:
>
> Register-register move instructions that can be easily seen as
> unnecessary by the human eye may remain in the compiled result.
> For example:
>
> /* example */
> double test(double a, double b) {
>   return __builtin_copysign(a, b);
> }
>
> test:
> add.n   a3, a3, a3
> extui   a5, a5, 31, 1
> ssai1
> ;; be in the same BB
> src a7, a5, a3  ;; No '0' in the source constraints
> ;; The destination replaced is
> ;;   irrelevant to the sources if the
> ;;   destination constraint has '&'
> ;; No CALL insns in this span
> ;; Both A3 and A7 are irrelevant to
> ;;   insns in this span
> mov.n   a3, a7  ;; An unnecessary reg-reg move
> ;; A7 is not used after this
> ret.n
>
> The last two instructions above, excluding the return instruction,
> could be done like this:
>
> src a3, a5, a3
>
> This symptom often occurs when handling DI/DFmode values with SImode
> instructions.  This patch solves the above problem using peephole2
> pattern.
>
> gcc/ChangeLog:
>
> * config/xtensa/xtensa.md: New peephole2 pattern that eliminates
> the occurrence of general-purpose register used only once and for
> transferring intermediate value.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/xtensa/elim_GP_regmove.c: New.
> ---
>  gcc/config/xtensa/xtensa.md   | 49 +++
>  .../gcc.target/xtensa/elim_GP_regmove.c   | 23 +
>  2 files changed, 72 insertions(+)
>  create mode 100644 gcc/testsuite/gcc.target/xtensa/elim_GP_regmove.c

This change breaks windowed builds by the following ICEs:

libgcc/libgcov-interface.c: In function ‘__gcov_execlp’:
libgcc/libgcov-interface.c:263:1: error: insn does not satisfy its constraints:
 263 | }
 | ^
(insn 96 95 98 11 (set (reg/f:SI 1 sp)
   (minus:SI (reg/f:SI 1 sp)
   (reg:SI 8 a8 [85]))) "libgcc/libgcov-interface.c":253:20 4 {subsi3}
(expr_list:REG_DEAD (reg:SI 8 a8 [85])
   (nil)))
during RTL pass: cprop_hardreg
libgcc/libgcov-interface.c:263:1: internal compiler error: in
extract_constrain_insn, at recog.cc:2692

It also introduces at least one regression in executable tests
in call0 build, I haven't tracked it down yet.

-- 
Thanks.
-- Max

[committed] libstdc++: Use /etc/sysconfig/clock for std::chrono::current_zone() [PR108530]

[Jonathan Wakely via Gcc-patches]

Tested x86_64-linux. Pushed to trunk.

-- >8 --

On some systems /etc/localtime is a tzfile, not a symlink to one. We
cannot use it to determine the current time zone in that case. See if
/etc/sysconfig/clock sets the variable DEFAULT_TIMEZONE instead.

libstdc++-v3/ChangeLog:

PR libstdc++/108530
* src/c++20/tzdb.cc (current_zone): Look for DEFAULT_TIMEZONE in
/etc/sysconfig/clock.
---
 libstdc++-v3/src/c++20/tzdb.cc | 24 ++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/libstdc++-v3/src/c++20/tzdb.cc b/libstdc++-v3/src/c++20/tzdb.cc
index 20399b91e47..eb68111e444 100644
--- a/libstdc++-v3/src/c++20/tzdb.cc
+++ b/libstdc++-v3/src/c++20/tzdb.cc
@@ -62,8 +62,8 @@
 #if ! __cpp_constinit
 # if __has_cpp_attribute(clang::require_constant_initialization)
 #  define constinit [[clang::require_constant_initialization]]
-#else // YOLO
-# define constinit
+# else // YOLO
+#  define constinit
 # endif
 #endif
 
@@ -1663,6 +1663,26 @@ namespace std::chrono
  if (auto tz = do_locate_zone(this->zones, this->links, name))
return tz;
   }
+
+if (ifstream tzf{"/etc/sysconfig/clock"})
+  {
+   string line;
+   string_view key = "DEFAULT_TIMEZONE=";
+   while (std::getline(tzf, line))
+ if (line.starts_with(key))
+   {
+ string_view name = line;
+ name.remove_prefix(key.size());
+ if (name.size() != 0 && name.front() == '"')
+   {
+ name.remove_prefix(1);
+ if (auto pos = name.find('"'); pos != name.npos)
+   name = name.substr(0, pos);
+   }
+ if (auto tz = do_locate_zone(this->zones, this->links, name))
+   return tz;
+   }
+  }
 #else
 // AIX stores current zone in $TZ in /etc/environment but the value
 // is typically a POSIX time zone name, not IANA zone.
-- 
2.39.1

[committed] libstdc++: Include std::ranges::subrange definition in [PR102301]

[Jonathan Wakely via Gcc-patches]

Tested x86_64-linux. Pushed to trunk.

-- >8 --

In order for std::make_from_tuple to work with tuple-like types, the
overloads of std::get for those types must have been declared before the
definition of std::make_from_tuple. That means we need to include the
definition of std::ranges::subrange in .

The definitions of std::pair and its overloads of std::get are already
included in . We provide forward declarations of std::array and
its std::get overloads in . We could just declare subrange
without defining it, and give ranges::get a non-deduced return type,
like so:

  namespace ranges
  {
enum class subrange_kind : bool { unsized, sized};

template S,
 subrange_kind K>
  requires (K == subrange_kind::sized || !sized_sentinel_for)
  class subrange;

template
  requires (_Num < 2)
  constexpr __conditional_t<_Num == 0, _It, _Sent>
  get(const subrange<_It, _Sent, _Kind>& __r);

template
  requires (_Num < 2)
  constexpr __conditional_t<_Num == 0, _It, _Sent>
  get(subrange<_It, _Sent, _Kind>&& __r)
  }
  using ranges::get;

It is a bit late in the GCC 13 dev cycle to do this, so just include the
right headers for now.

Also add the dangling check to std::make_from_tuple added by P2255.

libstdc++-v3/ChangeLog:

PR libstdc++/102301
* include/bits/ranges_base.h: Include  for
std::make_reverse_iterator.
* include/std/tuple: Include  for subrange.
(make_from_tuple): Add static assertion from P2255 to diagnose
dangling references.
* testsuite/20_util/tuple/make_from_tuple/dangling_ref.cc: New test.
* testsuite/20_util/tuple/make_from_tuple/tuple_like.cc: New test.
---
 libstdc++-v3/include/bits/ranges_base.h   |  2 +-
 libstdc++-v3/include/std/tuple| 16 +--
 .../tuple/make_from_tuple/dangling_ref.cc |  5 +++
 .../tuple/make_from_tuple/tuple_like.cc   | 43 +++
 4 files changed, 61 insertions(+), 5 deletions(-)
 create mode 100644 
libstdc++-v3/testsuite/20_util/tuple/make_from_tuple/dangling_ref.cc
 create mode 100644 
libstdc++-v3/testsuite/20_util/tuple/make_from_tuple/tuple_like.cc

diff --git a/libstdc++-v3/include/bits/ranges_base.h 
b/libstdc++-v3/include/bits/ranges_base.h
index 26b3a983f72..86952b34096 100644
--- a/libstdc++-v3/include/bits/ranges_base.h
+++ b/libstdc++-v3/include/bits/ranges_base.h
@@ -34,7 +34,7 @@
 
 #if __cplusplus > 201703L
 #include 
-#include 
+#include 
 #include 
 #include 
 
diff --git a/libstdc++-v3/include/std/tuple b/libstdc++-v3/include/std/tuple
index 3d82ed1c370..c773b3a348b 100644
--- a/libstdc++-v3/include/std/tuple
+++ b/libstdc++-v3/include/std/tuple
@@ -37,10 +37,11 @@
 
 #include  // for std::pair
 #include// for std::allocator_arg_t
-#include   // for std::get, std::tuple_size etc.
+#include   // for std::tuple_size etc.
 #include// for std::__invoke
 #if __cplusplus > 201703L
 # include 
+# include  // for std::ranges::subrange
 # define __cpp_lib_constexpr_tuple 201811L
 #endif
 
@@ -2312,9 +2313,16 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 make_from_tuple(_Tuple&& __t)
 noexcept(__unpack_std_tuple)
 {
-  return __make_from_tuple_impl<_Tp>(
-std::forward<_Tuple>(__t),
-   make_index_sequence>>{});
+  constexpr size_t __n = tuple_size_v>;
+#if __has_builtin(__reference_constructs_from_temporary)
+  if constexpr (__n == 1)
+   {
+ using _Elt = decltype(std::get<0>(std::declval<_Tuple>()));
+ static_assert(!__reference_constructs_from_temporary(_Tp, _Elt));
+   }
+#endif
+  return __make_from_tuple_impl<_Tp>(std::forward<_Tuple>(__t),
+make_index_sequence<__n>{});
 }
 #endif // C++17
 
diff --git 
a/libstdc++-v3/testsuite/20_util/tuple/make_from_tuple/dangling_ref.cc 
b/libstdc++-v3/testsuite/20_util/tuple/make_from_tuple/dangling_ref.cc
new file mode 100644
index 000..7958ec888a3
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/tuple/make_from_tuple/dangling_ref.cc
@@ -0,0 +1,5 @@
+// { dg-do compile { target c++17 } }
+#include 
+std::tuple f();
+auto t = std::make_from_tuple(f()); // { dg-error "here" }
+// { dg-error "static assertion failed" "" { target *-*-* } 0 }
diff --git a/libstdc++-v3/testsuite/20_util/tuple/make_from_tuple/tuple_like.cc 
b/libstdc++-v3/testsuite/20_util/tuple/make_from_tuple/tuple_like.cc
new file mode 100644
index 000..de694554d86
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/tuple/make_from_tuple/tuple_like.cc
@@ -0,0 +1,43 @@
+// { dg-do compile { target c++17 } }
+
+#include 
+#include 
+
+struct Two
+{
+  Two(const char*, int);
+};
+
+void
+test_pair()
+{
+  auto two = std::make_from_tuple(std::pair("one", 2));
+  static_assert(std::is_same_v, "make from pair");
+}
+
+#include 
+
+struct Three
+{
+  Three(int, int, int);
+};
+
+void
+test_array()
+{
+  Three three = std::m

[PATCH] c++: Fix up mangling of static lambdas [PR108525]

[Jakub Jelinek via Gcc-patches]

Hi!

Before the P1169R4 changes, operator () of a lambda was
always a method, so it was fine to pass method_p = 1 unconditionally,
but it isn't always the case, so this patch adds a check for whether
it is a method or nor.

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

2023-01-25  Jakub Jelinek  

PR c++/108525
* mangle.cc (write_closure_type_name): Don't assume all
lambda operator() fns are methods.

* g++.dg/cpp23/static-operator-call5.C: New test.

--- gcc/cp/mangle.cc.jj 2023-01-16 11:52:16.0 +0100
+++ gcc/cp/mangle.cc2023-01-24 18:59:09.335156301 +0100
@@ -1816,7 +1816,7 @@ write_closure_type_name (const tree type
   if (abi_warn_or_compat_version_crosses (18))
G.need_abi_warning = true;
 
-  write_method_parms (parms, /*method_p=*/1, fn);
+  write_method_parms (parms, TREE_CODE (TREE_TYPE (fn)) == METHOD_TYPE, fn);
   write_char ('E');
   if ((LAMBDA_EXPR_SCOPE_SIG_DISCRIMINATOR (lambda)
!= LAMBDA_EXPR_SCOPE_ONLY_DISCRIMINATOR (lambda))
--- gcc/testsuite/g++.dg/cpp23/static-operator-call5.C.jj   2023-01-24 
19:03:21.770469929 +0100
+++ gcc/testsuite/g++.dg/cpp23/static-operator-call5.C  2023-01-24 
19:02:45.224003615 +0100
@@ -0,0 +1,5 @@
+// PR c++/108525
+// { dg-do compile { target c++23 } }
+
+auto b = [](...) static { return 1; };
+auto foo () { return b (); }

Jakub

[committed] testsuite: Fix up new51.C test on various targets [PR108533]

[Jakub Jelinek via Gcc-patches]

On Mon, Jan 23, 2023 at 10:26:14PM -0500, Jason Merrill via Gcc-patches wrote:
>   * g++.dg/init/new51.C: New test.

The test fails on targets where size_t is not unsigned long
due to extra diagnostics.

As the testcase is tested in C++98 too, I'm not using decltype (sizeof 0)
but __SIZE_TYPE__.

Tested on x86_64-linux and i686-linux (plus verified with older snapshots
that it ICEs even with the change with both -m32/-m64), committed to
trunk as obvious.

2023-01-25  Jakub Jelinek  

PR c++/107329
PR testsuite/108533
* g++.dg/init/new51.C (size_t): New typedef.
(RexxClass::operator new, RexxClass::operator delete): Use size_t
instead of unsigned long.

--- gcc/testsuite/g++.dg/init/new51.C.jj2023-01-24 11:10:13.0 
+0100
+++ gcc/testsuite/g++.dg/init/new51.C   2023-01-25 00:05:10.767472447 +0100
@@ -1,9 +1,10 @@
 // PR c++/107329
 
+typedef __SIZE_TYPE__ size_t;
 struct RexxClass {
-  void *operator new(unsigned long, unsigned long, const char *, RexxClass *,
+  void *operator new(size_t, size_t, const char *, RexxClass *,
  RexxClass *);
-  void operator delete(void *, unsigned long, const char *, RexxClass *,
+  void operator delete(void *, size_t, const char *, RexxClass *,
RexxClass *);
   RexxClass();
 };

Jakub

Re: [PATCH v4] c++: Reject UDLs in certain contexts [PR105300]

[Marek Polacek via Gcc-patches]

Ping.

On Fri, Jan 13, 2023 at 06:22:38PM -0500, Marek Polacek wrote:
> On Sat, Dec 03, 2022 at 02:58:16PM -0500, Jason Merrill wrote:
> > On 12/2/22 18:58, Marek Polacek wrote:
> > > On Fri, Nov 18, 2022 at 08:39:10PM -0500, Jason Merrill wrote:
> > > > On 11/18/22 18:52, Marek Polacek wrote:
> > > > > +/* Parse a string literal or user defined string literal.
> > > > > +
> > > > > +   user-defined-string-literal :
> > > > > + string-literal ud-suffix
> > > > > +
> > > > > +   Parameters as for cp_parser_string_literal.  If LOOKUP_UDLIT, 
> > > > > perform
> > > > > +   a lookup for a suitable template function.  */
> > > > > +
> > > > > +static inline cp_expr
> > > > > +cp_parser_userdef_string_literal (cp_parser *parser, bool translate,
> > > > > +   bool wide_ok, bool lookup_udlit = 
> > > > > true)
> > > > 
> > > > I think this function doesn't need the translate and wide_ok parms, 
> > > > they can
> > > > always be true.
> > > 
> > > I've dropped the wide_ok one, but not the other, because...
> > > > > +{
> > > > > +  return cp_parser_string_literal_common (parser, translate, wide_ok,
> > > > > +   /*udl_ok=*/true, 
> > > > > lookup_udlit);
> > > > > +}
> > > > > +
> > > > >/* Look up a literal operator with the name and the exact 
> > > > > arguments.  */
> > > > >static tree
> > > > > @@ -4913,7 +4955,7 @@ cp_parser_userdef_numeric_literal (cp_parser 
> > > > > *parser)
> > > > >   as arguments.  */
> > > > >static tree
> > > > > -cp_parser_userdef_string_literal (tree literal)
> > > > > +finish_userdef_string_literal (tree literal)
> > > > >{
> > > > >  tree suffix_id = USERDEF_LITERAL_SUFFIX_ID (literal);
> > > > >  tree name = cp_literal_operator_id (IDENTIFIER_POINTER 
> > > > > (suffix_id));
> > > > > @@ -5652,10 +5694,10 @@ cp_parser_primary_expression (cp_parser 
> > > > > *parser,
> > > > >case CPP_UTF8STRING_USERDEF:
> > > > >  /* ??? Should wide strings be allowed when 
> > > > > parser->translate_strings_p
> > > > >is false (i.e. in attributes)?  If not, we can kill the third
> > > > > -  argument to cp_parser_string_literal.  */
> > > > 
> > > > I think the answer to this old question is no: if we have an
> > > > encoding-prefix, we should be translating.
> > > 
> > > ...I don't actually know how to resolve this.  wide_ok is always true 
> > > here.
> > > Should that change?  Or rather, should translate be false for CPP_STRING 
> > > only?
> 
> Sorry it's taken so long to get back to this.
>  
> > The one current exception to my assertion above is static_assert, for which
> > we currently allow encoding-prefixes but don't translate.  I think this is
> > wrong, that we should translate the string.  But I'm not confident of that.
> > 
> > But to your question, yes: when translate is false, I think we also don't
> > want to allow UDLs.  So _userdef can always pass true for translate.  And as
> > below we should call it only when translate would be true.
> 
> Done: _userdef no longer has the translate paramater and it's only called
> when parser->translate_strings_p.
>  
> > Incidentally, it seems that we set translate off for all attributes, even
> > ones that would take a normal expression argument where presumably we do
> > want translation (and UDLs).  The whole business of different parsing for
> > different attributes is a headache.  You don't need to deal with this now.
> > 
> > > > > -  return (cp_parser_string_literal (parser,
> > > > > - parser->translate_strings_p,
> > > > > - true)
> > > > > +  argument to cp_parser_{,userdef}string_literal.  */
> > > > > +  return (cp_parser_userdef_string_literal (parser,
> > > > > + 
> > > > > parser->translate_strings_p,
> > > > > + /*wide_ok=*/true)
> > > > 
> > > > For CPP_*STRING* without _USERDEF, we should still call
> > > > cp_parser_string_literal.
> > > 
> > > It looks like we always have to call cp_parser_userdef_string_literal
> > > otherwise this would be reejcted:
> > > 
> > >std::string concat01 = "Hello, " "World!"_www;
> > > 
> > > Because first we see a CPP_STRING but the subsequent UDL shouldn't
> > > be rejected.
> > 
> > Ah, I didn't notice the function was handling a sequence of string-literals.
> > So maybe we want to call _userdef here when translate_strings_p, and not
> > when it's false.
> 
> Resolved by the change above.  Thanks,
> 
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> 
> -- >8 --
> In this PR, we are crashing because we've encountered a UDL where a
> string-literal is expected.  This patch makes the parser reject string
> and character UDLs in all places where the grammar requires a
> string-literal and not a user-defined-string-literal.
> 
> I've introduced two new wrappers; the existing cp_p

Re: [PATCH v3] c++: -Wdangling-reference with reference wrapper [PR107532]

[Marek Polacek via Gcc-patches]

On Fri, Jan 20, 2023 at 03:19:54PM -0500, Jason Merrill wrote:
> On 1/19/23 21:03, Marek Polacek wrote:
> > On Thu, Jan 19, 2023 at 01:02:02PM -0500, Jason Merrill wrote:
> > > On 1/18/23 20:13, Marek Polacek wrote:
> > > > On Wed, Jan 18, 2023 at 04:07:59PM -0500, Jason Merrill wrote:
> > > > > On 1/18/23 12:52, Marek Polacek wrote:
> > > > > > Here, -Wdangling-reference triggers where it probably shouldn't, 
> > > > > > causing
> > > > > > some grief.  The code in question uses a reference wrapper with a 
> > > > > > member
> > > > > > function returning a reference to a subobject of a non-temporary 
> > > > > > object:
> > > > > > 
> > > > > >  const Plane & meta = fm.planes().inner();
> > > > > > 
> > > > > > I've tried a few approaches, e.g., checking that the member 
> > > > > > function's
> > > > > > return type is the same as the type of the enclosing class (which is
> > > > > > the case for member functions returning *this), but that then breaks
> > > > > > Wdangling-reference4.C with std::optional.
> > > > > > 
> > > > > > So I figured that perhaps we want to look at the object we're 
> > > > > > invoking
> > > > > > the member function(s) on and see if that is a temporary, as in, 
> > > > > > don't
> > > > > > warn about
> > > > > > 
> > > > > >  const Plane & meta = fm.planes().inner();
> > > > > > 
> > > > > > but do warn about
> > > > > > 
> > > > > >  const Plane & meta = FrameMetadata().planes().inner();
> > > > > > 
> > > > > > It's ugly, but better than asking users to add #pragmas into their 
> > > > > > code.
> > > > > 
> > > > > Hmm, that doesn't seem right; the former is only OK because Ref is in 
> > > > > fact a
> > > > > reference-like type.  If planes() returned a class that held data, we 
> > > > > would
> > > > > want to warn.
> > > > 
> > > > Sure, it's always some kind of tradeoff with warnings :/.
> > > > > In this case, we might recognize the reference-like class because it 
> > > > > has a
> > > > > reference member and a constructor taking the same reference type.
> > > > 
> > > > That occurred to me too, but then I found out that 
> > > > std::reference_wrapper
> > > > actually uses T*, not T&, as you say.  But here's a patch to do that
> > > > (I hope).
> > > > > That wouldn't help with std::reference_wrapper or std::ref_view 
> > > > > because they
> > > > > have pointer members instead of references, but perhaps loosening the 
> > > > > check
> > > > > to include that case would make sense?
> > > > 
> > > > Sorry, I don't understand what you mean by loosening the check.  I could
> > > > hardcode std::reference_wrapper and std::ref_view but I don't think 
> > > > that's
> > > > what you meant.
> > > 
> > > Indeed that's not what I meant, but as I was saying in our meeting I think
> > > it's worth doing; the compiler has various tweaks to handle specific
> > > standard-library classes better.
> > Okay, done in the patch below.  Except that I'm not including a test for
> > std::ranges::ref_view because I don't really know how that works.
> > 
> > > > Surely I cannot _not_ warn for any class that contains a T*.
> > > 
> > > I was thinking if a constructor takes a T& and the class has a T* that 
> > > would
> > > be close enough, though this also wouldn't handle the standard library
> > > classes so the benefit is questionable.
> > > 
> > > > Here's the patch so that we have some actual code to discuss...  Thanks.
> > > > 
> > > > -- >8 --
> > > > Here, -Wdangling-reference triggers where it probably shouldn't, causing
> > > > some grief.  The code in question uses a reference wrapper with a member
> > > > function returning a reference to a subobject of a non-temporary object:
> > > > 
> > > > const Plane & meta = fm.planes().inner();
> > > > 
> > > > I've tried a few approaches, e.g., checking that the member function's
> > > > return type is the same as the type of the enclosing class (which is
> > > > the case for member functions returning *this), but that then breaks
> > > > Wdangling-reference4.C with std::optional.
> > > > 
> > > > Perhaps we want to look at the member function's enclosing class
> > > > to see if it's a reference wrapper class (meaning, has a reference
> > > > member and a constructor taking the same reference type) and don't
> > > > warn if so, supposing that the member function returns a reference
> > > > to a non-temporary object.
> > > > 
> > > > It's ugly, but better than asking users to add #pragmas into their code.
> > > > 
> > > > PR c++/107532
> > > > 
> > > > gcc/cp/ChangeLog:
> > > > 
> > > > * call.cc (do_warn_dangling_reference): Don't warn when the
> > > > member function comes from a reference wrapper class.
> > > 
> > > Let's factor the new code out into e.g. reference_like_class_p
> > 
> > Done.  Thanks,
> > 
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > 
> > -- >8 --
> > Here, -Wdangling-reference triggers where it probably shouldn't, causing
> > some grief.  The code i

Re: [PATCH v5] xtensa: Eliminate the use of callee-saved register that saves and restores only once

[Max Filippov via Gcc-patches]

Hi Suwa-san,

On Mon, Jan 23, 2023 at 7:43 PM Takayuki 'January June' Suwa
 wrote:
>
> In the case of the CALL0 ABI, values that must be retained before and
> after function calls are placed in the callee-saved registers (A12
> through A15) and referenced later.  However, it is often the case that
> the save and the reference are each only once and a simple register-
> register move (with two exceptions; i. the register saved to/restored
> from is the stack pointer, ii. the function needs an additional stack
> pointer adjustment to grow the stack).
>
> e.g. in the following example, if there are no other occurrences of
> register A14:
>
> ;; before
> ; prologue {
>   ...
> s32i.n  a14, sp, 16
>   ...   ;; no frame pointer needed
> ;; no additional stack growth
> ; } prologue
>   ...
> mov.n   a14, a6 ;; A6 is not SP
>   ...
> call0   foo
>   ...
> mov.n   a8, a14 ;; A8 is not SP
>   ...
> ; epilogue {
>   ...
> l32i.n  a14, sp, 16
>   ...
> ; } epilogue
>
> It can be possible like this:
>
> ;; after
> ; prologue {
>   ...
> (no save needed)
>   ...
> ; } prologue
>   ...
> s32i.n  a6, sp, 16  ;; replaced with A14's slot
>   ...
> call0   foo
>   ...
> l32i.n  a8, sp, 16  ;; through SP
>   ...
> ; epilogue {
>   ...
> (no restoration needed)
>   ...
> ; } epilogue
>
> This patch adds the abovementioned logic to the function prologue/epilogue
> RTL expander code.
>
> gcc/ChangeLog:
>
> * config/xtensa/xtensa.cc (machine_function): Add new member
> 'eliminated_callee_saved_bmp'.
> (xtensa_can_eliminate_callee_saved_reg_p): New function to
> determine whether the register can be eliminated or not.
> (xtensa_expand_prologue): Add invoking the above function and
> elimination the use of callee-saved register by using its stack
> slot through the stack pointer (or the frame pointer if needed)
> directly.
> (xtensa_expand_prologue): Modify to not emit register restoration
> insn from its stack slot if the register is already eliminated.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/xtensa/elim_callee_saved.c: New.
> ---
>  gcc/config/xtensa/xtensa.cc   | 130 ++
>  .../gcc.target/xtensa/elim_callee_saved.c |  32 +
>  2 files changed, 137 insertions(+), 25 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/xtensa/elim_callee_saved.c

This version results in multiple ICEs with the following stack traces:

gcc/testsuite/gcc.c-torture/compile/2127-1.c:7:1: error: could not
split insn
(insn 7 6 8 2 (set (mem/c:SI (plus:SI (reg/f:SI 15 a15)
   (const_int 24 [0x18])) [3  S4 A32])
   (reg:DF 2 a2))
"gcc/testsuite/gcc.c-torture/compile/2127-1.c":4:10 61
{movdf_internal}
(nil))
during RTL pass: final
gcc/testsuite/gcc.c-torture/compile/2127-1.c:7:1: internal
compiler error: in final_scan_insn_1, at final.cc:2808
0x6cb090 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
   gcc/rtl-error.cc:108
0x639b17 final_scan_insn_1
   gcc/final.cc:2808
0xb1817b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
   gcc/final.cc:2887
0xb18266 final_1
   gcc/final.cc:1979
0xb18f94 rest_of_handle_final
   gcc/final.cc:4240
0xb18f94 execute
   gcc/final.cc:4318



gcc/testsuite/gcc.c-torture/compile/950729-1.c:39:1: error: could not split insn
(insn 91 93 228 13 (set (reg:DI 4 a4)
   (mem/c:SI (plus:SI (reg/f:SI 15 a15)
   (const_int 72 [0x48])) [5  S4 A32]))
"gcc/testsuite/gcc.c-torture/compile/950729-1.c":28:55 52
{movdi_internal}
(nil))
during RTL pass: final
gcc/testsuite/gcc.c-torture/compile/950729-1.c:39:1: internal compiler
error: in final_scan_insn_1, at final.cc:2808
0x6cb090 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
   gcc/rtl-error.cc:108
0x639b17 final_scan_insn_1
   gcc/final.cc:2808
0xb1817b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
   gcc/final.cc:2887
0xb18266 final_1
   gcc/final.cc:1979
0xb18f94 rest_of_handle_final
   gcc/final.cc:4240
0xb18f94 execute
   gcc/final.cc:4318

-- 
Thanks.
-- Max

[pushed] c++: "" #pragma at BOF [PR108504]

[Jason Merrill via Gcc-patches]

Tested x86_64-pc-linux-gnu, applying to trunk.

-- 8< --

Since r11-2095 we pass flags to cp_lexer_get_preprocessor_token, and
cp_lexer_new_main passes C_LEX_STRING_NO_JOIN when lexing most of the
translation unit, but doesn't do that for the very first token; as a
result, if the first token is a string literal, we try to join strings and
get confused if that encounters a pragma.

PR c++/108504

gcc/cp/ChangeLog:

* parser.cc (cp_lexer_new_main): Pass C_LEX_STRING_NO_JOIN for first
token, too.

gcc/testsuite/ChangeLog:

* g++.dg/ext/pragma1.C: New test.
---
 gcc/cp/parser.cc   | 2 +-
 gcc/testsuite/g++.dg/ext/pragma1.C | 4 
 2 files changed, 5 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/ext/pragma1.C

diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index b38c22e9a3d..07ec0e14491 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -705,7 +705,7 @@ cp_lexer_new_main (void)
   /* It's possible that parsing the first pragma will load a PCH file,
  which is a GC collection point.  So we have to do that before
  allocating any memory.  */
-  cp_lexer_get_preprocessor_token (0, &token);
+  cp_lexer_get_preprocessor_token (C_LEX_STRING_NO_JOIN, &token);
   cp_parser_initial_pragma (&token);
   c_common_no_more_pch ();
 
diff --git a/gcc/testsuite/g++.dg/ext/pragma1.C 
b/gcc/testsuite/g++.dg/ext/pragma1.C
new file mode 100644
index 000..bb258dac9a7
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/pragma1.C
@@ -0,0 +1,4 @@
+// PR c++/108504
+
+"1"// { dg-error "" }
+#pragma GCC diagnostic push

base-commit: 049a52909075117f5112971cc83952af2a818bc1
-- 
2.31.1

[pushed] c++: static lambda in template [PR108526]

[Jason Merrill via Gcc-patches]

Tested x86_64-pc-linux-gnu, applying to trunk.

-- 8< --

tsubst_lambda_expr uses build_memfn_type to build a METHOD_TYPE for the new
lamba op().  This is not what we want for a C++23 static op(), but since we
also use that METHOD_TYPE to communicate the closure type down to
tsubst_function_decl, let's wait and turn it back at that point.

PR c++/108526

gcc/cp/ChangeLog:

* pt.cc (tsubst_function_decl): Handle static lambda.

gcc/testsuite/ChangeLog:

* g++.dg/cpp23/static-operator-call5.C: New test.
---
 gcc/cp/pt.cc   | 5 +
 gcc/testsuite/g++.dg/cpp23/static-operator-call5.C | 8 
 2 files changed, 13 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp23/static-operator-call5.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 2a4d03c5e47..51fc246ed71 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -14306,6 +14306,11 @@ tsubst_function_decl (tree t, tree args, 
tsubst_flags_t complain,
   tree ctx = closure ? closure : DECL_CONTEXT (t);
   bool member = ctx && TYPE_P (ctx);
 
+  /* If this is a static lambda, remove the 'this' pointer added in
+ tsubst_lambda_expr now that we know the closure type.  */
+  if (lambda_fntype && DECL_STATIC_FUNCTION_P (t))
+lambda_fntype = static_fn_type (lambda_fntype);
+
   if (member && !closure)
 ctx = tsubst_aggr_type (ctx, args,
complain, t, /*entering_scope=*/1);
diff --git a/gcc/testsuite/g++.dg/cpp23/static-operator-call5.C 
b/gcc/testsuite/g++.dg/cpp23/static-operator-call5.C
new file mode 100644
index 000..ae022d0b971
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp23/static-operator-call5.C
@@ -0,0 +1,8 @@
+// PR c++/108526
+// { dg-do compile { target c++23 } }
+
+template void f()
+{
+  auto a = [] (auto x) static { return x; };
+}
+template void f();

base-commit: 049a52909075117f5112971cc83952af2a818bc1
-- 
2.31.1

Re: [PATCH] tree-optimization/108522 Use COMPONENT_REF offset when available

[Jakub Jelinek via Gcc-patches]

On Tue, Jan 24, 2023 at 04:54:00PM -0500, Siddhesh Poyarekar wrote:
> Use the offset in TREE_OPERAND(component_ref, 2) when available instead
> of DECL_FIELD_OFFSET when trying to compute offset for a COMPONENT_REF.
> 
> OK for gcc 13 and gcc 12?

Ok for trunk, I'd wait a week or two with the backport.

Thanks.

> Co-authored-by: Jakub Jelinek 
> 
> gcc/ChangeLog:
> 
>   PR tree-optimization/108522
>   * tree-object-size.cc (compute_object_offset): Use
>   TREE_OPERAND(ref, 2) for COMPONENT_REF when available.
> 
> gcc/testsuite/ChangeLog:
> 
>   PR tree-optimization/108522
>   * builtin-dynamic-object-size-0.c (test_dynarray_struct_member):
>   new test.
>   (main): Call it.
> 
> Signed-off-by: Siddhesh Poyarekar 

Jakub

[PATCH] tree-optimization/108522 Use COMPONENT_REF offset when available

[Siddhesh Poyarekar]

Use the offset in TREE_OPERAND(component_ref, 2) when available instead
of DECL_FIELD_OFFSET when trying to compute offset for a COMPONENT_REF.

OK for gcc 13 and gcc 12?

Co-authored-by: Jakub Jelinek 

gcc/ChangeLog:

PR tree-optimization/108522
* tree-object-size.cc (compute_object_offset): Use
TREE_OPERAND(ref, 2) for COMPONENT_REF when available.

gcc/testsuite/ChangeLog:

PR tree-optimization/108522
* builtin-dynamic-object-size-0.c (test_dynarray_struct_member):
new test.
(main): Call it.

Signed-off-by: Siddhesh Poyarekar 
---
Testing:

- Bootstrapped on x86_64, I'm checking to confirm if a couple of
  seemingly unrelated failures are in fact unrelated.
- ubsan config bootstrap and i686 tests in progress

 .../gcc.dg/builtin-dynamic-object-size-0.c   | 16 
 gcc/tree-object-size.cc  |  4 +++-
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/builtin-dynamic-object-size-0.c 
b/gcc/testsuite/gcc.dg/builtin-dynamic-object-size-0.c
index f9047a037d9..569c0a87722 100644
--- a/gcc/testsuite/gcc.dg/builtin-dynamic-object-size-0.c
+++ b/gcc/testsuite/gcc.dg/builtin-dynamic-object-size-0.c
@@ -314,6 +314,20 @@ test_dynarray_struct_subobj2 (size_t sz, size_t off, 
size_t *objsz)
   return __builtin_dynamic_object_size (&bin.c[off], 1);
 }
 
+/* See pr #108522.  */
+size_t
+__attribute__ ((noinline))
+test_dynarray_struct_member (size_t sz)
+{
+  struct
+{
+  char a[sz];
+  char b;
+} s;
+
+  return __builtin_dynamic_object_size (&s.b, 0);
+}
+
 size_t
 __attribute__ ((noinline))
 test_substring (size_t sz, size_t off)
@@ -619,6 +633,8 @@ main (int argc, char **argv)
   if (test_dynarray_struct_subobj2 (42, 4, &objsz)
 != objsz - 4 - sizeof (long) - sizeof (int))
 FAIL ();
+  if (test_dynarray_struct_member (42) != sizeof (char))
+FAIL ();
   if (test_substring_ptrplus (128, 4) != (128 - 4) * sizeof (int))
 FAIL ();
   if (test_substring_ptrplus (128, 142) != 0)
diff --git a/gcc/tree-object-size.cc b/gcc/tree-object-size.cc
index 356591c22cc..de93ffad9c9 100644
--- a/gcc/tree-object-size.cc
+++ b/gcc/tree-object-size.cc
@@ -412,7 +412,9 @@ compute_object_offset (const_tree expr, const_tree var)
return base;
 
   t = TREE_OPERAND (expr, 1);
-  off = size_binop (PLUS_EXPR, DECL_FIELD_OFFSET (t),
+  off = size_binop (PLUS_EXPR,
+   (TREE_OPERAND (expr, 2) ? TREE_OPERAND (expr, 2)
+: DECL_FIELD_OFFSET (t)),
size_int (tree_to_uhwi (DECL_FIELD_BIT_OFFSET (t))
  / BITS_PER_UNIT));
   break;
-- 
2.38.1

[PATCH] Fortran: fix ICE in compare_bound_int [PR108527]

[Harald Anlauf via Gcc-patches]

Dear all,

when checking expressions for array sections, we need to ensure
that these use only type INTEGER.  However, it does not make sense
to generate an internal error when encountering wrong types,
but rather take the ordinary route of error recovery.

The initial fix was provided by Steve.

While working on the same PR, I found that the comments related
to the logic needed a minor adjustment, and the logic could be
cleaned up to actually match the intended comment.

Regtested on x86_64-pc-linux-gnu.  OK for mainline?

Thanks,
Harald

From bd9afd0835bfe956400978503041323aea894ef5 Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Tue, 24 Jan 2023 22:36:25 +0100
Subject: [PATCH] Fortran: fix ICE in compare_bound_int [PR108527]

gcc/fortran/ChangeLog:

	PR fortran/108527
	* resolve.cc (compare_bound_int): Expression to compare must be of
	type INTEGER.
	(compare_bound_mpz_t): Likewise.
	(check_dimension): Fix comment on checks applied to array section
	and clean up associated logic.

gcc/testsuite/ChangeLog:

	PR fortran/108527
	* gfortran.dg/pr108527.f90: New test.

Co-authored-by: Steven G. Kargl 
---
 gcc/fortran/resolve.cc | 29 +-
 gcc/testsuite/gfortran.dg/pr108527.f90 | 10 +
 2 files changed, 24 insertions(+), 15 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/pr108527.f90

diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 94213cd3cd4..0538029da26 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -4575,12 +4575,11 @@ compare_bound_int (gfc_expr *a, int b)
 {
   int i;

-  if (a == NULL || a->expr_type != EXPR_CONSTANT)
+  if (a == NULL
+  || a->expr_type != EXPR_CONSTANT
+  || a->ts.type != BT_INTEGER)
 return CMP_UNKNOWN;

-  if (a->ts.type != BT_INTEGER)
-gfc_internal_error ("compare_bound_int(): Bad expression");
-
   i = mpz_cmp_si (a->value.integer, b);

   if (i < 0)
@@ -4598,12 +4597,11 @@ compare_bound_mpz_t (gfc_expr *a, mpz_t b)
 {
   int i;

-  if (a == NULL || a->expr_type != EXPR_CONSTANT)
+  if (a == NULL
+  || a->expr_type != EXPR_CONSTANT
+  || a->ts.type != BT_INTEGER)
 return CMP_UNKNOWN;

-  if (a->ts.type != BT_INTEGER)
-gfc_internal_error ("compare_bound_int(): Bad expression");
-
   i = mpz_cmp (a->value.integer, b);

   if (i < 0)
@@ -4733,23 +4731,24 @@ check_dimension (int i, gfc_array_ref *ar, gfc_array_spec *as)
 #define AR_END (ar->end[i] ? ar->end[i] : as->upper[i])

 	compare_result comp_start_end = compare_bound (AR_START, AR_END);
+	compare_result comp_stride_zero = compare_bound_int (ar->stride[i], 0);

 	/* Check for zero stride, which is not allowed.  */
-	if (compare_bound_int (ar->stride[i], 0) == CMP_EQ)
+	if (comp_stride_zero == CMP_EQ)
 	  {
 	gfc_error ("Illegal stride of zero at %L", &ar->c_where[i]);
 	return false;
 	  }

-	/* if start == len || (stride > 0 && start < len)
-			   || (stride < 0 && start > len),
+	/* if start == end || (stride > 0 && start < end)
+			   || (stride < 0 && start > end),
 	   then the array section contains at least one element.  In this
 	   case, there is an out-of-bounds access if
 	   (start < lower || start > upper).  */
-	if (compare_bound (AR_START, AR_END) == CMP_EQ
-	|| ((compare_bound_int (ar->stride[i], 0) == CMP_GT
-		 || ar->stride[i] == NULL) && comp_start_end == CMP_LT)
-	|| (compare_bound_int (ar->stride[i], 0) == CMP_LT
+	if (comp_start_end == CMP_EQ
+	|| ((comp_stride_zero == CMP_GT || ar->stride[i] == NULL)
+		&& comp_start_end == CMP_LT)
+	|| (comp_stride_zero == CMP_LT
 	&& comp_start_end == CMP_GT))
 	  {
 	if (compare_bound (AR_START, as->lower[i]) == CMP_LT)
diff --git a/gcc/testsuite/gfortran.dg/pr108527.f90 b/gcc/testsuite/gfortran.dg/pr108527.f90
new file mode 100644
index 000..c97ba3111cb
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr108527.f90
@@ -0,0 +1,10 @@
+! { dg-do compile }
+! PR fortran/108527 - ICE in compare_bound_int
+! Contributed by G.Steinmetz
+
+program p
+  integer, parameter :: a((2.)) = [4,8] ! { dg-error "must be of INTEGER type" }
+  integer(a(1:1)) :: b  ! { dg-error "out of bounds" }
+end
+
+! { dg-prune-output "Parameter array" }
--
2.35.3

Re: [PATCH] xtensa: Revise 89afb2e86fcb29c559b2957fdcbea0d01740c49b

[Max Filippov via Gcc-patches]

On Thu, Jan 19, 2023 at 7:33 PM Takayuki 'January June' Suwa
 wrote:
>
> In the previously posted patch
> "xtensa: Make complex hard register clobber elimination more robust and 
> accurate",
> the check code for insns that refer to the [DS]Cmode hard register before
> it is overwritten after it is clobbered is incomplete.  Fortunately such
> insns are seldom emitted, so it didn't matter.
>
> This patch fixes that for the sake of completeness.
>
> gcc/ChangeLog:
>
> * config/xtensa/xtensa.md:
> Fix exit from loops detecting references before overwriting in the
> split pattern.
> ---
>  gcc/config/xtensa/xtensa.md | 72 +++--
>  1 file changed, 37 insertions(+), 35 deletions(-)

Regtested for target=xtensa-linux-uclibc, no new regressions.
Committed to master with more human readable subject line.

-- 
Thanks.
-- Max

[committed] [PR108388] LRA: Always do elimination and only for hard register to check insn constraints

[Vladimir Makarov via Gcc-patches]

The following patch solves

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

The patch was successfully bootstrapped and tested on x86-64, aarch64, 
and ppc64le.
commit 265a749f290f7c6adc9a3aaa9c585b498a8a38ea
Author: Vladimir N. Makarov 
Date:   Tue Jan 24 16:10:59 2023 -0500

LRA: Always do elimination and only for hard register to check insn constraints

LRA does elimination but not always checks insn constraints in this case.
This results in LRA failure for PDP11 target whose addition is only 2-op insn.
The same might happen for other analogous targets.  The patch fixes this problem.

PR rtl-optimization/108388

gcc/ChangeLog:

* lra-constraints.cc (get_hard_regno): Remove final_p arg.  Always
do elimination but only for hard register.
(operands_match_p, uses_hard_regs_p, process_alt_operands): Adjust
calls of get_hard_regno.

gcc/testsuite/ChangeLog:

* gcc.target/pdp11/pdp11.exp: New.
* gcc.target/pdp11/pr108388.c: New.

diff --git a/gcc/lra-constraints.cc b/gcc/lra-constraints.cc
index b0b3c5b01dc..7bffbc07ee2 100644
--- a/gcc/lra-constraints.cc
+++ b/gcc/lra-constraints.cc
@@ -184,12 +184,12 @@ get_try_hard_regno (int regno)
   return ira_class_hard_regs[rclass][0];
 }
 
-/* Return the hard regno of X after removing its subreg.  If X is not
-   a register or a subreg of a register, return -1.  If X is a pseudo,
-   use its assignment.  If FINAL_P return the final hard regno which will
-   be after elimination.  */
+/* Return the hard regno of X after removing its subreg.  If X is not a
+   register or a subreg of a register, return -1.  If X is a pseudo, use its
+   assignment.  If X is a hard regno, return the final hard regno which will be
+   after elimination.  */
 static int
-get_hard_regno (rtx x, bool final_p)
+get_hard_regno (rtx x)
 {
   rtx reg;
   int hard_regno;
@@ -203,7 +203,7 @@ get_hard_regno (rtx x, bool final_p)
 hard_regno = lra_get_regno_hard_regno (hard_regno);
   if (hard_regno < 0)
 return -1;
-  if (final_p)
+  if (HARD_REGISTER_NUM_P (REGNO (reg)))
 hard_regno = lra_get_elimination_hard_regno (hard_regno);
   if (SUBREG_P (x))
 hard_regno += subreg_regno_offset (hard_regno, GET_MODE (reg),
@@ -782,7 +782,7 @@ operands_match_p (rtx x, rtx y, int y_hard_regno)
 {
   int j;
 
-  i = get_hard_regno (x, false);
+  i = get_hard_regno (x);
   if (i < 0)
 	goto slow;
 
@@ -1920,7 +1920,7 @@ uses_hard_regs_p (rtx x, HARD_REG_SET set)
 
   if (REG_P (x) || SUBREG_P (x))
 {
-  x_hard_regno = get_hard_regno (x, true);
+  x_hard_regno = get_hard_regno (x);
   return (x_hard_regno >= 0
 	  && overlaps_hard_reg_set_p (set, mode, x_hard_regno));
 }
@@ -2078,7 +2078,7 @@ process_alt_operands (int only_alternative)
 
   op = no_subreg_reg_operand[nop] = *curr_id->operand_loc[nop];
   /* The real hard regno of the operand after the allocation.  */
-  hard_regno[nop] = get_hard_regno (op, true);
+  hard_regno[nop] = get_hard_regno (op);
 
   operand_reg[nop] = reg = op;
   biggest_mode[nop] = GET_MODE (op);
@@ -2258,7 +2258,7 @@ process_alt_operands (int only_alternative)
 			&& curr_operand_mode[m] != curr_operand_mode[nop])
 		  break;
 		
-		m_hregno = get_hard_regno (*curr_id->operand_loc[m], false);
+		m_hregno = get_hard_regno (*curr_id->operand_loc[m]);
 		/* We are supposed to match a previous operand.
 		   If we do, we win if that one did.  If we do
 		   not, count both of the operands as losers.
diff --git a/gcc/testsuite/gcc.target/pdp11/pdp11.exp b/gcc/testsuite/gcc.target/pdp11/pdp11.exp
new file mode 100644
index 000..89b1f257329
--- /dev/null
+++ b/gcc/testsuite/gcc.target/pdp11/pdp11.exp
@@ -0,0 +1,41 @@
+# Copyright (C) 2023 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+# 
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+# 
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3.  If not see
+# .
+
+# GCC testsuite that uses the `dg.exp' driver.
+
+# Exit immediately if this isn't an pdp11 target.
+if ![istarget pdp11*-*-*] then {
+  return
+}
+
+# Load support procs.
+load_lib gcc-dg.exp
+
+# If a testcase doesn't have special options, use these.
+global DEFAULT_CFLAGS
+if ![info exists DEFAULT_CFLAGS] then {
+set DEFAULT_CFLAGS " -ansi -pedantic-errors"
+}
+
+# Initialize `dg'.
+dg-init
+
+# Main loop.

Re: [PATCH 2/4] libbacktrace: detect executable path on windows

[Björn Schäpers]

Am 24.01.2023 um 17:52 schrieb Eli Zaretskii:

From: Ian Lance Taylor 
Date: Tue, 24 Jan 2023 06:35:21 -0800
Cc: g...@hazardy.de, gcc-patches@gcc.gnu.org, g...@gcc.gnu.org


On Windows it seems that MAX_PATH is not
a true limit, as an extended length path may be up to 32767 bytes.


The limit of 32767 characters (not bytes, AFAIK) is only applicable
when using the Unicode (a.k.a. "wide") versions of the Windows Win32
APIs, see

   
https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation

Since the above code uses GetModuleFileNameA, which is an "ANSI"
single-byte API, it is still subject to the MAX_PATH limitation, and
MAX_PATH is defined as 260 on Windows headers.


Thanks.  Should this code be using GetModuleFileNameW?  Or would that
mean that the later call to open will fail?


We'd need to use _wopen or somesuch, and the file name will have to be
a wchar_t array, not a char array, yes.  So this is not very practical
when file names need to be passed between functions, unless they are
converted to UTF-8 (and back again before using them in Windows APIs).

And note that even then, the 260-byte limit could be lifted only if
the user has a new enough Windows version _and_ has opted in to the
long-name feature by turning it on in the Registry.  Otherwise, file
names used in "wide" APIs can only break the 260-byte limit if they
use the special format "\\?\D:\foo\bar", which means file names
specified by user outside of the program or file names that come from
other programs will need to be reformatted to this special format.


260 bytes does not seem like very much for a path name these days.


That's true.  But complications with using longer file names are still
a PITA on Windows, even though they are a step closer to practically
possible.


That was basically also my reasoning for choosing the A variant instead of W.

[PATCH, committed] Fortran: ICE in transformational_result [PR108529]

[Harald Anlauf via Gcc-patches]

Dear all,

we ICE'd in the simplification of the transformational intrinsic
ANY when the passed ARRAY argument had an invalid declaration.
The reason was a reference to array->shape which was NULL.

Obvious solution: then just don't attempt to simplify.

Regtested on x86_64-pc-linux-gnu and pushed to mainline as

https://gcc.gnu.org/g:6c96382eed96a9285611f2e3e2e59557094172b8

The PR is marked as a 10/11/12/13 regression, thus I plan to
backport.

Thanks,
Harald

From 6c96382eed96a9285611f2e3e2e59557094172b8 Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Tue, 24 Jan 2023 21:39:43 +0100
Subject: [PATCH] Fortran: ICE in transformational_result [PR108529]

gcc/fortran/ChangeLog:

	PR fortran/108529
	* simplify.cc (simplify_transformation): Do not try to simplify
	transformational intrinsic when the ARRAY argument has a NULL shape.

gcc/testsuite/ChangeLog:

	PR fortran/108529
	* gfortran.dg/pr108529.f90: New test.
---
 gcc/fortran/simplify.cc| 1 +
 gcc/testsuite/gfortran.dg/pr108529.f90 | 9 +
 2 files changed, 10 insertions(+)
 create mode 100644 gcc/testsuite/gfortran.dg/pr108529.f90

diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc
index f413f132b3f..20ea38e0007 100644
--- a/gcc/fortran/simplify.cc
+++ b/gcc/fortran/simplify.cc
@@ -720,6 +720,7 @@ simplify_transformation (gfc_expr *array, gfc_expr *dim, gfc_expr *mask,
   size_zero = gfc_is_size_zero_array (array);

   if (!(is_constant_array_expr (array) || size_zero)
+  || array->shape == NULL
   || !gfc_is_constant_expr (dim))
 return NULL;

diff --git a/gcc/testsuite/gfortran.dg/pr108529.f90 b/gcc/testsuite/gfortran.dg/pr108529.f90
new file mode 100644
index 000..34c9691fae1
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr108529.f90
@@ -0,0 +1,9 @@
+! { dg-do compile }
+! PR fortran/108529 - ICE in transformational_result
+! Contributed by G.Steinmetz
+
+program p
+  integer, parameter :: a(*,*) = reshape([1, 2, 3, 4], [2, 2])
+  logical, parameter :: b(2,*) = a > 2 ! { dg-error "Assumed size" }
+  logical, parameter :: c(*)   = all(b, 1) ! { dg-error "Bad shape" }
+end
--
2.35.3

Re: [PATCH 2/4] libbacktrace: detect executable path on windows

[Ian Lance Taylor via Gcc-patches]

On Tue, Jan 24, 2023 at 10:12 AM Eli Zaretskii via Gcc-patches
 wrote:
>
> > From: Ian Lance Taylor 
> > Date: Tue, 24 Jan 2023 09:58:10 -0800
> > Cc: g...@hazardy.de, gcc-patches@gcc.gnu.org, g...@gcc.gnu.org
> >
> > I'd rather that the patch look like the appended.  Can someone with a
> > Windows system test to see what that builds and passes the tests?
>
> ENOPATCH

Gah.

Ian
diff --git a/libbacktrace/config.h.in b/libbacktrace/config.h.in
index 94621c2e385..29d1ad3911a 100644
--- a/libbacktrace/config.h.in
+++ b/libbacktrace/config.h.in
@@ -100,6 +100,9 @@
 /* Define to 1 if you have the  header file. */
 #undef HAVE_UNISTD_H
 
+/* Define to 1 if you have the  header file. */
+#undef HAVE_WINDOWS_H
+
 /* Define if -lz is available. */
 #undef HAVE_ZLIB
 
diff --git a/libbacktrace/configure b/libbacktrace/configure
index 6af2c04c81a..0a27cfb7799 100755
--- a/libbacktrace/configure
+++ b/libbacktrace/configure
@@ -13409,6 +13409,19 @@ $as_echo "#define HAVE_LOADQUERY 1" >>confdefs.h
 
 fi
 
+for ac_header in windows.h
+do :
+  ac_fn_c_check_header_mongrel "$LINENO" "windows.h" "ac_cv_header_windows_h" 
"$ac_includes_default"
+if test "x$ac_cv_header_windows_h" = xyes; then :
+  cat >>confdefs.h <<_ACEOF
+#define HAVE_WINDOWS_H 1
+_ACEOF
+
+fi
+
+done
+
+
 # Check for the fcntl function.
 if test -n "${with_target_subdir}"; then
case "${host}" in
diff --git a/libbacktrace/configure.ac b/libbacktrace/configure.ac
index 39e6bf41e35..e3e10abd7b5 100644
--- a/libbacktrace/configure.ac
+++ b/libbacktrace/configure.ac
@@ -377,6 +377,8 @@ if test "$have_loadquery" = "yes"; then
   AC_DEFINE(HAVE_LOADQUERY, 1, [Define if AIX loadquery is available.])
 fi
 
+AC_CHECK_HEADERS(windows.h)
+
 # Check for the fcntl function.
 if test -n "${with_target_subdir}"; then
case "${host}" in
diff --git a/libbacktrace/fileline.c b/libbacktrace/fileline.c
index 674bf33cdcf..e110b54ee24 100644
--- a/libbacktrace/fileline.c
+++ b/libbacktrace/fileline.c
@@ -47,6 +47,18 @@ POSSIBILITY OF SUCH DAMAGE.  */
 #include 
 #endif
 
+#ifdef HAVE_WINDOWS_H
+#ifndef WIN32_MEAN_AND_LEAN
+#define WIN32_MEAN_AND_LEAN
+#endif
+
+#ifndef NOMINMAX
+#define NOMINMAX
+#endif
+
+#include 
+#endif
+
 #include "backtrace.h"
 #include "internal.h"
 
@@ -155,6 +167,27 @@ macho_get_executable_path (struct backtrace_state *state,
 
 #endif /* !defined (HAVE_MACH_O_DYLD_H) */
 
+#ifdef HAVE_WINDOWS_H
+
+static char *
+windows_get_executable_path (char *buf, backtrace_error_callback 
error_callback,
+void *data)
+{
+  size_t got;
+
+  got = GetModuleFileNameA (NULL, buf, MAX_PATH - 1);
+  if (got == 0
+  || (got == MAX_PATH - 1 && GetLastError () == ERROR_INSUFFICIENT_BUFFER))
+return NULL;
+  return buf;
+}
+
+#else /* !defined (HAVE_WINDOWS_H) */
+
+#define windows_get_executable_path(buf, error_callback, data) NULL
+
+#endif /* !defined (HAVE_WINDOWS_H) */
+
 /* Initialize the fileline information from the executable.  Returns 1
on success, 0 on failure.  */
 
@@ -168,7 +201,11 @@ fileline_initialize (struct backtrace_state *state,
   int called_error_callback;
   int descriptor;
   const char *filename;
+#ifdef HAVE_WINDOWS_H
+  char buf[MAX_PATH];
+#else
   char buf[64];
+#endif
 
   if (!state->threaded)
 failed = state->fileline_initialization_failed;
@@ -192,7 +229,7 @@ fileline_initialize (struct backtrace_state *state,
 
   descriptor = -1;
   called_error_callback = 0;
-  for (pass = 0; pass < 8; ++pass)
+  for (pass = 0; pass < 9; ++pass)
 {
   int does_not_exist;
 
@@ -224,6 +261,9 @@ fileline_initialize (struct backtrace_state *state,
case 7:
  filename = macho_get_executable_path (state, error_callback, data);
  break;
+   case 8:
+ filename = windows_get_executable_path (buf, error_callback, data);
+ break;
default:
  abort ();
}

Re: [PATCH 2/4] libbacktrace: detect executable path on windows

[Eli Zaretskii via Gcc-patches]

> From: Ian Lance Taylor 
> Date: Tue, 24 Jan 2023 09:58:10 -0800
> Cc: g...@hazardy.de, gcc-patches@gcc.gnu.org, g...@gcc.gnu.org
> 
> I'd rather that the patch look like the appended.  Can someone with a
> Windows system test to see what that builds and passes the tests?

ENOPATCH

Re: [PATCH 2/4] libbacktrace: detect executable path on windows

[Ian Lance Taylor via Gcc-patches]

On Tue, Jan 24, 2023 at 8:53 AM Eli Zaretskii via Gcc-patches
 wrote:
>
> > From: Ian Lance Taylor 
> > Date: Tue, 24 Jan 2023 06:35:21 -0800
> > Cc: g...@hazardy.de, gcc-patches@gcc.gnu.org, g...@gcc.gnu.org
> >
> > > > On Windows it seems that MAX_PATH is not
> > > > a true limit, as an extended length path may be up to 32767 bytes.
> > >
> > > The limit of 32767 characters (not bytes, AFAIK) is only applicable
> > > when using the Unicode (a.k.a. "wide") versions of the Windows Win32
> > > APIs, see
> > >
> > >   
> > > https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation
> > >
> > > Since the above code uses GetModuleFileNameA, which is an "ANSI"
> > > single-byte API, it is still subject to the MAX_PATH limitation, and
> > > MAX_PATH is defined as 260 on Windows headers.
> >
> > Thanks.  Should this code be using GetModuleFileNameW?  Or would that
> > mean that the later call to open will fail?
>
> We'd need to use _wopen or somesuch, and the file name will have to be
> a wchar_t array, not a char array, yes.  So this is not very practical
> when file names need to be passed between functions, unless they are
> converted to UTF-8 (and back again before using them in Windows APIs).
>
> And note that even then, the 260-byte limit could be lifted only if
> the user has a new enough Windows version _and_ has opted in to the
> long-name feature by turning it on in the Registry.  Otherwise, file
> names used in "wide" APIs can only break the 260-byte limit if they
> use the special format "\\?\D:\foo\bar", which means file names
> specified by user outside of the program or file names that come from
> other programs will need to be reformatted to this special format.
>
> > 260 bytes does not seem like very much for a path name these days.
>
> That's true.  But complications with using longer file names are still
> a PITA on Windows, even though they are a step closer to practically
> possible.


OK, thanks.

I'd rather that the patch look like the appended.  Can someone with a
Windows system test to see what that builds and passes the tests?
Thanks.

Ian

Re: [PATCH] aarch64: Add aarch64*-*-* to the list of vect_long_long targets

[Richard Sandiford via Gcc-patches]

"Andre Vieira (lists)"  writes:
> Hi,
>
> This patch adds aarch64 to the list of vect_long_long targets. 
> Regression tested on aarch64-none-linux-gnu.
>
> OK for trunk?
>
> gcc/testsuite/ChangeLog:
>
>   * lib/target-supports.exp (check_effective_target_vect_long_long): Add
>   aarch64 to list of targets supporting long long vectorization.

OK, thanks.

Richard

> diff --git a/gcc/testsuite/lib/target-supports.exp 
> b/gcc/testsuite/lib/target-supports.exp
> index 
> c0694af233818b5923919b33c5ae6f9d1955d118..227e3004077a374317ae20c323c03a9b2ce15292
>  100644
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -7125,7 +7125,8 @@ proc check_effective_target_vect_long_long { } {
>&& [check_effective_target_s390_vx])
>|| ([istarget powerpc*-*-*]
>&& ![istarget powerpc-*-linux*paired*]
> -  && [check_effective_target_has_arch_pwr8]) }}]
> +  && [check_effective_target_has_arch_pwr8])
> +  || [istarget aarch64*-*-*] }}]
>  }
>  
>  

Re: [PATCH 2/4] libbacktrace: detect executable path on windows

[Eli Zaretskii via Gcc-patches]

> From: Ian Lance Taylor 
> Date: Tue, 24 Jan 2023 06:35:21 -0800
> Cc: g...@hazardy.de, gcc-patches@gcc.gnu.org, g...@gcc.gnu.org
> 
> > > On Windows it seems that MAX_PATH is not
> > > a true limit, as an extended length path may be up to 32767 bytes.
> >
> > The limit of 32767 characters (not bytes, AFAIK) is only applicable
> > when using the Unicode (a.k.a. "wide") versions of the Windows Win32
> > APIs, see
> >
> >   
> > https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation
> >
> > Since the above code uses GetModuleFileNameA, which is an "ANSI"
> > single-byte API, it is still subject to the MAX_PATH limitation, and
> > MAX_PATH is defined as 260 on Windows headers.
> 
> Thanks.  Should this code be using GetModuleFileNameW?  Or would that
> mean that the later call to open will fail?

We'd need to use _wopen or somesuch, and the file name will have to be
a wchar_t array, not a char array, yes.  So this is not very practical
when file names need to be passed between functions, unless they are
converted to UTF-8 (and back again before using them in Windows APIs).

And note that even then, the 260-byte limit could be lifted only if
the user has a new enough Windows version _and_ has opted in to the
long-name feature by turning it on in the Registry.  Otherwise, file
names used in "wide" APIs can only break the 260-byte limit if they
use the special format "\\?\D:\foo\bar", which means file names
specified by user outside of the program or file names that come from
other programs will need to be reformatted to this special format.

> 260 bytes does not seem like very much for a path name these days.

That's true.  But complications with using longer file names are still
a PITA on Windows, even though they are a step closer to practically
possible.

[PATCH] aarch64: Add aarch64*-*-* to the list of vect_long_long targets

[Andre Vieira (lists) via Gcc-patches]

Hi,

This patch adds aarch64 to the list of vect_long_long targets. 
Regression tested on aarch64-none-linux-gnu.


OK for trunk?

gcc/testsuite/ChangeLog:

* lib/target-supports.exp (check_effective_target_vect_long_long): Add
aarch64 to list of targets supporting long long vectorization.diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index 
c0694af233818b5923919b33c5ae6f9d1955d118..227e3004077a374317ae20c323c03a9b2ce15292
 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -7125,7 +7125,8 @@ proc check_effective_target_vect_long_long { } {
 && [check_effective_target_s390_vx])
 || ([istarget powerpc*-*-*]
 && ![istarget powerpc-*-linux*paired*]
-&& [check_effective_target_has_arch_pwr8]) }}]
+&& [check_effective_target_has_arch_pwr8])
+|| [istarget aarch64*-*-*] }}]
 }
 
 

[COMMITTED] C-SKY: Fix wrong sysroot suffix when disable multilib.

[Xianmiao Qu via Gcc-patches]

The SYSROOT_SUFFIX_SPEC works even when multilib is disabled.
So when build no-multilib glibc toolchain and the options are
not same as MULTILIB_DEFAULTS, the sysroot will specify wrong
because the libc will not be installed as such.
This bug causes glibc regression test error:
  https://sourceware.org/pipermail/libc-testresults/2023q1/010706.html
The error is:
  
/scratch/jmyers/glibc-bot/install/compilers/csky-linux-gnuabiv2/csky-glibc-linux-gnuabiv2/bin/ld:
 cannot find -lc: No such file or directory

gcc/
* config.gcc(csky-*-linux*): Define CSKY_ENABLE_MULTILIB
and only include 'csky/t-csky-linux' when enable multilib.
* config/csky/csky-linux-elf.h(SYSROOT_SUFFIX_SPEC): Don't
define it when disable multilib.
---
 gcc/config.gcc   | 7 ++-
 gcc/config/csky/csky-linux-elf.h | 3 +++
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/gcc/config.gcc b/gcc/config.gcc
index d828223c16d..89f56047cfe 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1642,7 +1642,12 @@ csky-*-*)
;;
csky-*-linux*)
tm_file="elfos.h gnu-user.h linux.h glibc-stdint.h ${tm_file} 
csky/csky-linux-elf.h"
-   tmake_file="${tmake_file} csky/t-csky csky/t-csky-linux"
+   tmake_file="${tmake_file} csky/t-csky"
+
+   if test "x${enable_multilib}" = xyes ; then
+   tm_defines="$tm_defines CSKY_ENABLE_MULTILIB"
+   tmake_file="${tmake_file} csky/t-csky-linux"
+   fi
 
case ${target} in
csky-*-linux-gnu*)
diff --git a/gcc/config/csky/csky-linux-elf.h b/gcc/config/csky/csky-linux-elf.h
index 3f67af64c15..117c2a12c74 100644
--- a/gcc/config/csky/csky-linux-elf.h
+++ b/gcc/config/csky/csky-linux-elf.h
@@ -65,6 +65,8 @@
 
 #define GLIBC_DYNAMIC_LINKER 
"/lib/ld-linux-cskyv2%{mfloat-abi=hard:-hf}%{mbig-endian:-be}.so.1"
 
+#ifdef CSKY_ENABLE_MULTILIB
+#undef SYSROOT_SUFFIX_SPEC
 #define SYSROOT_SUFFIX_SPEC\
   "%{mbig-endian:/big}"\
   "%{mcpu=ck807*:/ck807}"  \
@@ -72,6 +74,7 @@
   "%{mcpu=ck800*:/ck800}"  \
   "%{mfloat-abi=softfp:/soft-fp}"  \
   "%{mfloat-abi=hard:/hard-fp}"
+#endif
 
 #define LINUX_TARGET_LINK_SPEC "%{h*} %{version:-v}\
%{b}\
-- 
2.32.1 (Apple Git-133)

Re: [PATCH v2] IBM zSystems: Fix TARGET_D_CPU_VERSIONS

[Andreas Krebbel via Gcc-patches]

On 1/24/23 09:47, Stefan Schulze Frielinghaus wrote:
> In the context of D the interpretation of S390, S390X, and SystemZ is a
> bit fuzzy.  The wording S390X was wrongly deprecated in favour of
> SystemZ by commit
> https://github.com/dlang/dlang.org/commit/3b50a4c3faf01c32234d0ef8be5f82915a61c23f
> Thus, SystemZ is used for 64-bit targets, now, and S390 for 31-bit
> targets.  However, in TARGET_D_CPU_VERSIONS depending on TARGET_ZARCH we
> set the CPU version to SystemZ.  This is also the case if compiled for
> 31-bit targets leading to the following error:
> 
> libphobos/libdruntime/core/sys/posix/sys/stat.d:967:13: error: static assert: 
>  '96u == 144u' is false
>   967 | static assert(stat_t.sizeof == 144);
>   | ^
> 
> Thus in order to keep this patch simple I went for keeping SystemZ for
> 64-bit targets and S390, as usual, for 31-bit targets and dropped the
> distinction between ESA and z/Architecture.
> 
> Bootstrapped and regtested on IBM zSystems.  Ok for mainline?
> 
> gcc/ChangeLog:
> 
>   * config/s390/s390-d.cc (s390_d_target_versions): Fix detection
>   of CPU version.

Ok, thanks!

Andreas

Re: [PATCH 2/2] Add VREL_OTHER for FP unsupported relations.

[Andrew MacLeod via Gcc-patches]

On 1/24/23 05:05, Jakub Jelinek wrote:

On Mon, Jan 23, 2023 at 12:44:48PM -0500, Andrew MacLeod wrote:

@@ -784,17 +794,28 @@ value_relation::negate ()
  bool
  value_relation::intersect (const value_relation &p)
  {
-  // Save previous value
-  relation_kind old = related;
+  relation_kind k;
  
if (p.op1 () == op1 () && p.op2 () == op2 ())

-related = relation_intersect (kind (), p.kind ());
+k = relation_intersect (kind (), p.kind ());
else if (p.op2 () == op1 () && p.op1 () == op2 ())
-related = relation_intersect (kind (), relation_swap (p.kind ()));
+k = relation_intersect (kind (), relation_swap (p.kind ()));
else
  return false;
  
-  return old != related;

+  if (related == k)
+return false;
+
+  bool float_p = name1 && FLOAT_TYPE_P (TREE_TYPE (name1));
+  if (float_p && p.kind () != k && k == VREL_UNDEFINED)
+{
+  if (relation_lt_le_gt_ge_p (kind ())
+ || relation_lt_le_gt_ge_p (p.kind ()))
+   k = VREL_OTHER;
+}

I don't understand this.

When at least one of the relations is VREL_{L,G}{T,E} and intersection
is VREL_UNDEFINED, it means other relation is VREL_UNDEFINED (but then
VREL_UNDEFINED is the right range to return), or one is VREL_{L,G}T
and the other is VREL_EQ (x > y && x == y, again, VREL_UNDEFINED is
the right answer, no ordered pair of x and y is greater (or less) and
equal at the same time and for unordered (at least one NaN) both
relations are false), or it is VREL_LT vs. VREL_G{T,E} or vice versa
or VREL_GT vs. VREL_L{T,E} or vice versa
(x < y && x >= y again, for ordered pairs of x and y it is never
true, if any is NaN, neither comparison is true).

I don't think you need to do anything floating point related in intersect.
It might seem to be inconsistent with union, but that is just because
VREL_OTHER is the union of VREL_LTGT, VREL_ORDERED, VREL_UNORDERED,
VREL_UNLT, VREL_UNGT, VREL_UNGT, VREL_UNGE and VREL_UNEQ, if we had
those 8 in addition to the current 8 non-PE ones you'd see that for
intersections one only gets the new codes when fp with possible
NANs and at least one of the intersection operand is one of the new
codes.  In the VREL_OTHER world, simply VREL_OTHER intersected with
anything but VREL_UNDEFINED is VREL_OTHER.


That is the way VREL_OTHER is implemented in the table.

So the problem is not on the true side of the IF condition as in your 
example, its on the false side. We see this commonly in code like this



if (x <= y) // FALSE side registers x > y
  blah()
else if (x >= y)  // FALSE side registers x < y
  blah()
else
  // Here we get VREL_UNDEFINED.

But for floating point, that is not true, this would be a known NAN 
based on my understanding of this.  If I understand correctly, the 
condition on the true side is explicitly true, but the false side is 
the  "false condition Union NAN".. which we cant represent.   but I 
don't think we want to always make that VREL_OTHER either.


So it seems we have to do one of two things...   either never produce 
UNDEFINED for floating point (unless one operand is explicitly UNDEFINED 
already), or on the false side of a condition, always produce a 
VREL_OTHER since its a relation and a NAN possible.   Of course, if the 
floating point code for the range-op relation operator knows the false 
side has no NAN, it could produce the appropriate relation then.


It seems to me the "easiest" to get right is to stop producing 
VREL_UNDEFINED for intersection?


Or am I reading something wrong?




+  // (x < y) || (x > y) produces x != y, but this is not true with floats.
+  // (x <= y) || (x >= y) produces VARYING, which is also not true for floats.

This misses a couple of needed cases both in this comment and
in the actual implementation.  In particular, the first comment
line is right, x < y || x > y is the only one where we get
VREL_NE and want VREL_OTHER (VREL_LTGT maybe later).
x <= y || x >= y is just one of the cases which produce VREL_VARYING
and we want VREL_OTHER (VREL_ORDERED maybe later) though,
x < y || x >= y
x <= y || x > y
are the others where from the current tables you also get
VREL_VARYING but want VREL_OTHER (VREL_ORDERED eventually).


+  // As they cannot be properly represented, use VREL_OTHER.
+  bool float_p = name1 && FLOAT_TYPE_P (TREE_TYPE (name1));

This should be
   bool float_p = name1 && HONOR_NANS (TREE_TYPE (name1));
If it is not floating point mode, it will be false, if it is
floating point mode which doesn't have NANs in hw, it also behaves
the same relation-wise, and lastly if hw supports NANs but user
uses -ffast-math or -ffinite-math-only, the user guaranteed that
the operands will never be NAN (nor +-INF), which means that
again relation behave like the integral/pointer ones, there is
no 4th possible outcome of a comparison.


+  if (float_p && p.kind () != k)
+{
+  if (kind () == VREL_LT && p.kind () == VREL_GT)
+   k = VREL_OTHER;
+  else if (kind () == VREL_GT && p.kind () == VREL_LT)
+   k = VR

[Patch] OpenMP/Fortran: Fix loop-iter var privatization with !$OMP LOOP [PR108512]

[Tobias Burnus]

I stumbled over a new FAIL (regression) in sollve_vv today, which was due to an
odd corner case (see commit log for a description).

The mentioned in-scan error is tested for in gomp/loop-2.f90 ("'inscan' 
REDUCTION
clause on construct other than DO, SIMD, DO SIMD, PARALLEL DO, PARALLEL DO 
SIMD").

I hope that this patch covers all cases and no other surprises exist...

OK for mainline?

 * * *

The ICE is new in GCC 13 due to the duplicate diagnostic (cf. PR); the original 
issue
existed before but seemingly did not affect the code, at least the sollve_vv 
testcase
passed before.

Still, it could be backported to GCC 12. (Fortran '!$omp loop' support was 
added with r12-1206.)
Thoughts?

Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
OpenMP/Fortran: Fix loop-iter var privatization with !$OMP LOOP [PR108512]

For 'parallel', loop-iteration variables are marked are marked as 'private',
unless they either appear in an omp do/simd loop or an data-sharing clause
already exists for those on 'parallel'. 'omp loop' wasn't handled, leading
to (potentially) multiple data-sharing clauses in gfc_resolve_do_iterator
as omp_current_ctx pointed to the 'parallel' directive, ignoring the
in-betwen 'loop' directive.

The latter lead to a bogus diagnostic - or rather an ICE as the source
location var contained only '\0'.

gcc/fortran/ChangeLog:

	PR fortran/108512
	* openmp.cc (gfc_resolve_omp_do_blocks): Don't check 'inscan'
	restrictions for loop as rejected elsewhere.
	(gfc_resolve_do_iterator): Set a source location for added
	'private'-clause arguments.
	* resolve.cc (gfc_resolve_code): Call gfc_resolve_omp_do_blocks
	also for EXEC_OMP_LOOP.

gcc/testsuite/ChangeLog:

	PR fortran/108512
	* gfortran.dg/gomp/loop-5.f90: New test.

 gcc/fortran/openmp.cc |  5 +-
 gcc/fortran/resolve.cc|  1 +
 gcc/testsuite/gfortran.dg/gomp/loop-5.f90 | 84 +++
 3 files changed, 89 insertions(+), 1 deletion(-)

diff --git a/gcc/fortran/openmp.cc b/gcc/fortran/openmp.cc
index cc1eab90b8c..7673a52249f 100644
--- a/gcc/fortran/openmp.cc
+++ b/gcc/fortran/openmp.cc
@@ -9056,7 +9056,9 @@ gfc_resolve_omp_do_blocks (gfc_code *code, gfc_namespace *ns)
 	}
   if (i < omp_current_do_collapse || omp_current_do_collapse <= 0)
 	omp_current_do_collapse = 1;
-  if (code->ext.omp_clauses->lists[OMP_LIST_REDUCTION_INSCAN])
+  if (code->op == EXEC_OMP_LOOP)
+	;  /* Already rejected in resolve_omp_clauses.  */
+  else if (code->ext.omp_clauses->lists[OMP_LIST_REDUCTION_INSCAN])
 	{
 	  locus *loc
 	= &code->ext.omp_clauses->lists[OMP_LIST_REDUCTION_INSCAN]->where;
@@ -9224,6 +9226,7 @@ gfc_resolve_do_iterator (gfc_code *code, gfc_symbol *sym, bool add_clause)
 
   p = gfc_get_omp_namelist ();
   p->sym = sym;
+  p->where = omp_current_ctx->code->loc;
   p->next = omp_clauses->lists[OMP_LIST_PRIVATE];
   omp_clauses->lists[OMP_LIST_PRIVATE] = p;
 }
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 94213cd3cd4..bd2a749776d 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -11950,6 +11950,7 @@ gfc_resolve_code (gfc_code *code, gfc_namespace *ns)
 	case EXEC_OMP_DISTRIBUTE_SIMD:
 	case EXEC_OMP_DO:
 	case EXEC_OMP_DO_SIMD:
+	case EXEC_OMP_LOOP:
 	case EXEC_OMP_SIMD:
 	case EXEC_OMP_TARGET_SIMD:
 	  gfc_resolve_omp_do_blocks (code, ns);
diff --git a/gcc/testsuite/gfortran.dg/gomp/loop-5.f90 b/gcc/testsuite/gfortran.dg/gomp/loop-5.f90
new file mode 100644
index 000..1948e782653
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/gomp/loop-5.f90
@@ -0,0 +1,84 @@
+! { dg-additional-options "-fdump-tree-original" }
+!
+! PR fortran/108512
+
+! The problem was that the context wasn't reset for the 'LOOP'
+! such that the clauses of the loops weren't seen when adding
+! PRIVATE clauses.
+!
+! In the following, only the loop variable of the non-OpenMP loop
+! in 'subroutine four' should get a front-end addded PRIVATE clause
+
+implicit none
+integer :: x, a(10), b(10), n
+n = 10
+a = -42
+b = [(2*x, x=1,10)]
+
+! { dg-final { scan-tree-dump-times "#pragma omp target map\\(tofrom:a\\) map\\(tofrom:b\\) map\\(tofrom:x\\)\[\r\n\]" 1 "original" } }
+! { dg-final { scan-tree-dump-times "#pragma omp parallel\[\r\n\]" 2 "original" } }
+!  ^- shows up twice; checked only here.
+! { dg-final { scan-tree-dump-times "#pragma omp loop lastprivate\\(x\\)\[\r\n\]" 1 "original" } }
+
+!$omp target parallel map(tofrom: a, b, x)
+!$omp loop lastprivate(x)
+DO x = 1, n
+  a(x) = a(x) + b(x)
+END DO
+!$omp end loop
+!$omp end target parallel
+if (x /= 11) error stop
+if (any (a /= [(2*x - 42, x=1,10)])) error stop
+call two()
+call three()

[PATCH] ipa: check if cache_token != NULL before hash_set::add call

[Martin Liška]

We should not insert an empty value to the container.

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

Ready to be installed?
Thanks,
Martin

PR ipa/108509

gcc/ChangeLog:

* cgraphunit.cc (walk_polymorphic_call_targets): Insert
ony non-null values.
* ipa.cc (walk_polymorphic_call_targets): Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/ipa/pr108509.C: New test.
---
 gcc/cgraphunit.cc   |  2 +-
 gcc/ipa.cc  |  2 +-
 gcc/testsuite/g++.dg/ipa/pr108509.C | 22 ++
 3 files changed, 24 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/ipa/pr108509.C

diff --git a/gcc/cgraphunit.cc b/gcc/cgraphunit.cc
index 832818d651f..a972900900b 100644
--- a/gcc/cgraphunit.cc
+++ b/gcc/cgraphunit.cc
@@ -1000,7 +1000,7 @@ walk_polymorphic_call_targets (hash_set 
*reachable_call_targets,
 = possible_polymorphic_call_targets
(edge, &final, &cache_token);
 
-  if (!reachable_call_targets->add (cache_token))
+  if (cache_token != NULL && !reachable_call_targets->add (cache_token))
 {
   if (symtab->dump_file)
dump_possible_polymorphic_call_targets 
diff --git a/gcc/ipa.cc b/gcc/ipa.cc
index 4de605000b6..5c15b60a603 100644
--- a/gcc/ipa.cc
+++ b/gcc/ipa.cc
@@ -182,7 +182,7 @@ walk_polymorphic_call_targets (hash_set 
*reachable_call_targets,
 = possible_polymorphic_call_targets
(edge, &final, &cache_token);
 
-  if (!reachable_call_targets->add (cache_token))
+  if (cache_token != NULL && !reachable_call_targets->add (cache_token))
 {
   for (i = 0; i < targets.length (); i++)
{
diff --git a/gcc/testsuite/g++.dg/ipa/pr108509.C 
b/gcc/testsuite/g++.dg/ipa/pr108509.C
new file mode 100644
index 000..2844189bbb4
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ipa/pr108509.C
@@ -0,0 +1,22 @@
+// PR ipa/108509
+// { dg-do compile }
+// { dg-options "-O1 -fdevirtualize -fno-tree-fre" }
+
+struct B {
+  virtual void deref ();
+};
+
+struct RefPtr {
+  B *p;
+
+  RefPtr ()
+  {
+p->deref ();
+  }
+};
+
+void
+f ()
+{
+  RefPtr b;
+}
-- 
2.39.0

RE: [PATCH] arm: Make MVE masked stores read memory operand [PR 108177]

[Kyrylo Tkachov via Gcc-patches]

> -Original Message-
> From: Andre Vieira (lists) 
> Sent: Tuesday, January 24, 2023 2:40 PM
> To: 'gcc-patches@gcc.gnu.org' 
> Cc: Richard Earnshaw ; Kyrylo Tkachov
> 
> Subject: Re: [PATCH] arm: Make MVE masked stores read memory operand
> [PR 108177]
> 
> ping. (reattaching patch in the hopes patchwork picks it up).
> 
> On 13/01/2023 16:05, Andre Simoes Dias Vieira via Gcc-patches wrote:
> > Hi,
> >
> > This patch adds the memory operand of MVE masked stores as input
> operands to
> > mimic the 'partial' writes, to prevent erroneous write-after-write
> > optimizations as described in the PR.
> >
> > Regression tested on arm-none-eabi for armv8.1-m.main+mve.fp.
> >
> > OK for trunk?

Ok.
Thanks,
Kyrill

> >
> > gcc/ChangeLog:
> >
> > PR target/108177
> > * config/arm/mve.md (mve_vstrbq_p_,
> mve_vstrhq_p_fv8hf,
> > mve_vstrhq_p_, mve_vstrwq_p_v4si): Add
> memory operand
> > as input operand.
> >
> >  gcc/testsuite/ChangeLog:
> >
> >  *   gcc.target/arm/mve/pr108177-1-run.c: New test.
> >  *   gcc.target/arm/mve/pr108177-1.c: New test.
> >  *   gcc.target/arm/mve/pr108177-10-run.c: New test.
> >  *   gcc.target/arm/mve/pr108177-10.c: New test.
> >  *   gcc.target/arm/mve/pr108177-11-run.c: New test.
> >  *   gcc.target/arm/mve/pr108177-11.c: New test.
> >  *   gcc.target/arm/mve/pr108177-12-run.c: New test.
> >  *   gcc.target/arm/mve/pr108177-12.c: New test.
> >  *   gcc.target/arm/mve/pr108177-13-run.c: New test.
> >  *   gcc.target/arm/mve/pr108177-13.c: New test.
> >  *   gcc.target/arm/mve/pr108177-14-run.c: New test.
> >  *   gcc.target/arm/mve/pr108177-14.c: New test.
> >  *   gcc.target/arm/mve/pr108177-2-run.c: New test.
> >  *   gcc.target/arm/mve/pr108177-2.c: New test.
> >  *   gcc.target/arm/mve/pr108177-3-run.c: New test.
> >  *   gcc.target/arm/mve/pr108177-3.c: New test.
> >  *   gcc.target/arm/mve/pr108177-4-run.c: New test.
> >  *   gcc.target/arm/mve/pr108177-4.c: New test.
> >  *   gcc.target/arm/mve/pr108177-5-run.c: New test.
> >  *   gcc.target/arm/mve/pr108177-5.c: New test.
> >  *   gcc.target/arm/mve/pr108177-6-run.c: New test.
> >  *   gcc.target/arm/mve/pr108177-6.c: New test.
> >  *   gcc.target/arm/mve/pr108177-7-run.c: New test.
> >  *   gcc.target/arm/mve/pr108177-7.c: New test.
> >  *   gcc.target/arm/mve/pr108177-8-run.c: New test.
> >  *   gcc.target/arm/mve/pr108177-8.c: New test.
> >  *   gcc.target/arm/mve/pr108177-9-run.c: New test.
> >  *   gcc.target/arm/mve/pr108177-9.c: New test.
> >  *   gcc.target/arm/mve/pr108177-main.x: New test include.
> >  *   gcc.target/arm/mve/pr108177.x: New test include.

Re: [PATCH] arm: Make MVE masked stores read memory operand [PR 108177]

[Andre Vieira (lists) via Gcc-patches]

ping. (reattaching patch in the hopes patchwork picks it up).

On 13/01/2023 16:05, Andre Simoes Dias Vieira via Gcc-patches wrote:

Hi,

This patch adds the memory operand of MVE masked stores as input operands to
mimic the 'partial' writes, to prevent erroneous write-after-write
optimizations as described in the PR.

Regression tested on arm-none-eabi for armv8.1-m.main+mve.fp.

OK for trunk?

gcc/ChangeLog:

PR target/108177
* config/arm/mve.md (mve_vstrbq_p_, mve_vstrhq_p_fv8hf,
mve_vstrhq_p_, mve_vstrwq_p_v4si): Add memory operand
as input operand.

 gcc/testsuite/ChangeLog:

 *   gcc.target/arm/mve/pr108177-1-run.c: New test.
 *   gcc.target/arm/mve/pr108177-1.c: New test.
 *   gcc.target/arm/mve/pr108177-10-run.c: New test.
 *   gcc.target/arm/mve/pr108177-10.c: New test.
 *   gcc.target/arm/mve/pr108177-11-run.c: New test.
 *   gcc.target/arm/mve/pr108177-11.c: New test.
 *   gcc.target/arm/mve/pr108177-12-run.c: New test.
 *   gcc.target/arm/mve/pr108177-12.c: New test.
 *   gcc.target/arm/mve/pr108177-13-run.c: New test.
 *   gcc.target/arm/mve/pr108177-13.c: New test.
 *   gcc.target/arm/mve/pr108177-14-run.c: New test.
 *   gcc.target/arm/mve/pr108177-14.c: New test.
 *   gcc.target/arm/mve/pr108177-2-run.c: New test.
 *   gcc.target/arm/mve/pr108177-2.c: New test.
 *   gcc.target/arm/mve/pr108177-3-run.c: New test.
 *   gcc.target/arm/mve/pr108177-3.c: New test.
 *   gcc.target/arm/mve/pr108177-4-run.c: New test.
 *   gcc.target/arm/mve/pr108177-4.c: New test.
 *   gcc.target/arm/mve/pr108177-5-run.c: New test.
 *   gcc.target/arm/mve/pr108177-5.c: New test.
 *   gcc.target/arm/mve/pr108177-6-run.c: New test.
 *   gcc.target/arm/mve/pr108177-6.c: New test.
 *   gcc.target/arm/mve/pr108177-7-run.c: New test.
 *   gcc.target/arm/mve/pr108177-7.c: New test.
 *   gcc.target/arm/mve/pr108177-8-run.c: New test.
 *   gcc.target/arm/mve/pr108177-8.c: New test.
 *   gcc.target/arm/mve/pr108177-9-run.c: New test.
 *   gcc.target/arm/mve/pr108177-9.c: New test.
 *   gcc.target/arm/mve/pr108177-main.x: New test include.
 *   gcc.target/arm/mve/pr108177.x: New test include.diff --git a/gcc/config/arm/mve.md b/gcc/config/arm/mve.md
index 
f123edc449b8b20bfb4a15c1fb0eccdbfff1339c..2e58ad188c4b13b27f7d35ddde0f04f98b1334c6
 100644
--- a/gcc/config/arm/mve.md
+++ b/gcc/config/arm/mve.md
@@ -7272,15 +7272,13 @@ (define_insn "mve_vstrwq_scatter_base_p_v4si"
 }
   [(set_attr "length" "8")])
 
-;;
-;; [vstrbq_p_s vstrbq_p_u]
-;;
 (define_insn "mve_vstrbq_p_"
   [(set (match_operand: 0 "mve_memory_operand" "=Ux")
-   (unspec: [(match_operand:MVE_2 1 "s_register_operand" "w")
- (match_operand: 2 
"vpr_register_operand" "Up")]
-VSTRBQ))
-  ]
+   (unspec:
+[(match_operand:MVE_2 1 "s_register_operand" "w")
+ (match_operand: 2 "vpr_register_operand" "Up")
+ (match_dup 0)]
+VSTRBQ))]
   "TARGET_HAVE_MVE"
 {
rtx ops[2];
@@ -8079,10 +8077,11 @@ (define_insn "mve_vstrhq_fv8hf"
 ;;
 (define_insn "mve_vstrhq_p_fv8hf"
   [(set (match_operand:V8HI 0 "mve_memory_operand" "=Ux")
-   (unspec:V8HI [(match_operand:V8HF 1 "s_register_operand" "w")
- (match_operand:V8BI 2 "vpr_register_operand" "Up")]
-VSTRHQ_F))
-  ]
+   (unspec:V8HI
+[(match_operand:V8HF 1 "s_register_operand" "w")
+ (match_operand:V8BI 2 "vpr_register_operand" "Up")
+ (match_dup 0)]
+VSTRHQ_F))]
   "TARGET_HAVE_MVE && TARGET_HAVE_MVE_FLOAT"
 {
rtx ops[2];
@@ -8099,8 +8098,10 @@ (define_insn "mve_vstrhq_p_fv8hf"
 ;;
 (define_insn "mve_vstrhq_p_"
   [(set (match_operand: 0 "mve_memory_operand" "=Ux")
-   (unspec: [(match_operand:MVE_6 1 "s_register_operand" "w")
- (match_operand: 2 
"vpr_register_operand" "Up")]
+   (unspec:
+[(match_operand:MVE_6 1 "s_register_operand" "w")
+ (match_operand: 2 "vpr_register_operand" "Up")
+ (match_dup 0)]
 VSTRHQ))
   ]
   "TARGET_HAVE_MVE"
@@ -8278,10 +8279,11 @@ (define_insn "mve_vstrwq_fv4sf"
 ;;
 (define_insn "mve_vstrwq_p_fv4sf"
   [(set (match_operand:V4SI 0 "mve_memory_operand" "=Ux")
-   (unspec:V4SI [(match_operand:V4SF 1 "s_register_operand" "w")
- (match_operand: 2 "vpr_register_operand" "Up")]
-VSTRWQ_F))
-  ]
+   (unspec:V4SI
+[(match_operand:V4SF 1 "s_register_operand" "w")
+ (match_operand: 2 "vpr_register_operand" "Up")
+ (match_dup 0)]
+VSTRWQ_F))]
   "TARGET_HAVE_MVE && TARGET_HAVE_MVE_FLOAT"
 {
rtx ops[2];
@@ -8298,10 +8300,11 @@ (define_insn "mve_vstrwq_p_fv4sf"
 ;;
 (define_insn "mve_vstrwq_p_v4si"
   [(set (match_operand:V4SI 0 "mve_memory_operand" "=Ux"

Re: [PATCH 2/4] libbacktrace: detect executable path on windows

[Ian Lance Taylor via Gcc-patches]

On Tue, Jan 24, 2023 at 5:11 AM Eli Zaretskii via Gcc-patches
 wrote:
>
> > Date: Mon, 23 Jan 2023 15:00:56 -0800
> > Cc: gcc-patches@gcc.gnu.org, g...@gcc.gnu.org
> > From: Ian Lance Taylor via Gcc 
> >
> > > +#ifdef HAVE_WINDOWS_H
> > > +
> > > +static char *
> > > +windows_get_executable_path (char *buf, backtrace_error_callback 
> > > error_callback,
> > > +void *data)
> > > +{
> > > +  if (GetModuleFileNameA (NULL, buf, MAX_PATH - 1) == 0)
> > > +{
> > > +  error_callback (data,
> > > + "could not get the filename of the current 
> > > executable",
> > > + (int) GetLastError ());
> > > +  return NULL;
> > > +}
> > > +  return buf;
> > > +}
> >
> > Thanks, but this seems incomplete.  The docs for GetModuleFileNameA
> > say that if the pathname is too long to fit into the buffer it returns
> > the size of the buffer and sets the error to
> > ERROR_INSUFFICIENT_BUFFER.  It seems to me that in that case we should
> > allocate a larger buffer and try again.
>
> This is correct in general, but not in this particular case.
>
> > On Windows it seems that MAX_PATH is not
> > a true limit, as an extended length path may be up to 32767 bytes.
>
> The limit of 32767 characters (not bytes, AFAIK) is only applicable
> when using the Unicode (a.k.a. "wide") versions of the Windows Win32
> APIs, see
>
>   
> https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation
>
> Since the above code uses GetModuleFileNameA, which is an "ANSI"
> single-byte API, it is still subject to the MAX_PATH limitation, and
> MAX_PATH is defined as 260 on Windows headers.

Thanks.  Should this code be using GetModuleFileNameW?  Or would that
mean that the later call to open will fail?

260 bytes does not seem like very much for a path name these days.

Ian

[PATCH 3/3] arm: Fix MVE predicates synthesis [PR 108443]

[Andre Vieira (lists) via Gcc-patches]

Hi,

This patch fixes the way we synthesize MVE predicate immediates and 
fixes some other inconsistencies around predicates. For instance this 
patch fixes the modes used in the vctp intrinsics, to couple them with 
predicate modes with the appropriate lane numbers. For this V2QI is 
added to represent a predicate created by vctp64q. The reason we use 
V2QI and not for instance a V2BI with 8-bit boolean modes is because we 
are trying to avoid having two 'INT' modes of the same size. We make 
sure we use the V2QI mode instead of HI for any instruction working on 
two lanes of 64-bits consuming a predicate.


Bootstrapped on aarch64-none-linux-gnu and regression tested on 
arm-none-eabi and armeb-none-eabi for armv8.1-m.main+mve.fp.


OK for trunk?

gcc/ChangeLog:

PR target/108443
* config/arm/arm.h (VALID_MVE_PRED_MODE): Add V2QI.
* config/arm/arm.cc (thumb2_legitimate_address_p): Use HImode for
addressing MVE predicate modes.
(mve_bool_vec_to_const): Change to represent correct MVE predicate
format.
	(arm_hard_regno_mode_ok): Use VALID_MVE_PRED_MODE instead of checking 
modes.

(arm_vector_mode_supported_p): Likewise.
(arm_mode_to_pred_mode): Add V2QI.
* config/arm/arm-builtins.cc (UNOP_PRED_UNONE_QUALIFIERS): New 
qualifier.
(UNOP_PRED_PRED_QUALIFIERS): New qualifier
(BINOP_PRED_UNONE_PRED_QUALIFIERS): New qualifier.
(v2qi_UP): New macro.
(v4bi_UP): New macro.
(v8bi_UP): New macro.
(v16bi_UP): New macro.
(arm_expand_builtin_args): Make it able to expand the new predicate
modes.
* config/arm/arm-modes.def (V2QI): New mode.
* config/arm/arm-simd-builtin-types.def (Pred1x16_t, Pred2x8_t
Pred4x4_t): Remove unused predicate builtin types.
* config/arm/arm_mve.h (__arm_vctp16q, __arm_vctp32q, __arm_vctp64q,
__arm_vctp8q, __arm_vpnot, __arm_vctp8q_m, __arm_vctp64q_m,
__arm_vctp32q_m, __arm_vctp16q_m): Use predicate modes.
* config/arm/arm_mve_builtins.def (vctp16q, vctp32q, vctp64q, vctp8q,
vpnot, vctp8q_m, vctp16q_m, vctp32q_m, vctp64q_m): Likewise.
* config/arm/constraints.md (DB): Check for VALID_MVE_PRED_MODE instead
of MODE_VECTOR_BOOL.
* config/arm/iterators.md (MVE_7, MVE_7_HI): Add V2QI
(MVE_VPRED): Likewise.
(MVE_vpred): Add V2QI and map upper case predicate modes to 
lower case.

(MVE_vctp): New mode attribute.
(mode1): Remove.
(VCTPQ): Remove.
(VCTPQ_M): Remove.
* config/arm/mve.md (mve_vctpqhi): Rename this...
(mve_vctpq): ... to this. And use new mode
attributes.
(mve_vpnothi): Rename this...
(mve_vpnotv16bi): ... to this.
(mve_vctpq_mhi): Rename this...
(mve_vctpq_m):... to this.
(mve_vldrdq_gather_base_z_v2di,
mve_vldrdq_gather_offset_z_v2di,
mve_vldrdq_gather_shifted_offset_z_v2di,
mve_vstrdq_scatter_base_p_v2di,
mve_vstrdq_scatter_offset_p_v2di,
mve_vstrdq_scatter_offset_p_v2di_insn,
mve_vstrdq_scatter_shifted_offset_p_v2di,
mve_vstrdq_scatter_shifted_offset_p_v2di_insn,
mve_vstrdq_scatter_base_wb_p_v2di,
mve_vldrdq_gather_base_wb_z_v2di,
mve_vldrdq_gather_base_nowb_z_v2di,
	mve_vldrdq_gather_base_wb_z_v2di_insn):  Use V2QI insead of HI 
for predicates.

* config/arm/unspecs.md (VCTP8Q, VCTP16Q, VCTP32Q, VCTP64Q): Replace
these...
(VCTP): ... with this.
(VCTP8Q_M, VCTP16Q_M, VCTP32Q_M, VCTP64Q_M): Replace these...
(VCTP_M): ... with this.
	* config/arm/vfp.md (*thumb2_movhi_vfp, *thumb2_movhi_fp16): Use 
VALID_MVE_PRED_MODE

instead of checking for MODE_VECTOR_BOOL class.


gcc/testsuite/ChangeLog:

* gcc.dg/rtl/arm/mve-vxbi.c: Use new predicate modes.
* gcc.target/arm/mve/pr108443-run.c: New test.
* gcc.target/arm/mve/pr108443.c: New test.diff --git a/gcc/config/arm/arm-builtins.cc b/gcc/config/arm/arm-builtins.cc
index 
6c67cec93ff76a4b42f3a0b305f697142e88fcd9..22fc7f10e92b33a861a321e43becee4647738b61
 100644
--- a/gcc/config/arm/arm-builtins.cc
+++ b/gcc/config/arm/arm-builtins.cc
@@ -384,6 +384,19 @@ arm_unop_unone_imm_qualifiers[SIMD_MAX_BUILTIN_ARGS]
 #define UNOP_UNONE_IMM_QUALIFIERS \
   (arm_unop_unone_imm_qualifiers)
 
+static enum arm_type_qualifiers
+arm_unop_pred_unone_qualifiers[SIMD_MAX_BUILTIN_ARGS]
+  = { qualifier_predicate, qualifier_unsigned };
+#define UNOP_PRED_UNONE_QUALIFIERS \
+  (arm_unop_pred_unone_qualifiers)
+
+static enum arm_type_qualifiers
+arm_unop_pred_pred_qualifiers[SIMD_MAX_BUILTIN_ARGS]
+  = { qualifier_predicate, qualifier_predicate };
+#define UNOP_PRED_PRED_QUALIFIERS \
+  (arm_unop_pred_pred_qualifiers)
+
+
 static enum arm_type_qualifiers
 arm_binop_none_none_none_qualifiers[SIMD_MAX_BUILTIN_ARGS]
   = { qualifier_none, qualifier_none, qualifier_none };
@@ -426,6 +439,12 @@ 
arm

[PATCH 2/3] arm: Remove unnecessary zero-extending of MVE predicates before use [PR 107674]

[Andre Vieira (lists) via Gcc-patches]

Hi,

This patch teaches GCC that zero-extending a MVE predicate from 16-bits 
to 32-bits and then only using 16-bits is a no-op.

It does so in two steps:
- it lets gcc know that it can access any MVE predicate mode using any 
other MVE predicate mode without needing to copy it, using the 
TARGET_MODES_TIEABLE_P hook,
- it teaches simplify_subreg to optimize a subreg with a vector 
outermode, by replacing this outermode with a same-sized integer mode 
and trying the avalailable optimizations, then if successful it 
surrounds the result with a subreg casting it back to the original 
vector outermode.


This removes the unnecessary zero-extending shown on PR 107674 (though 
it's a sign-extend there), that was introduced in gcc 11.


Bootstrapped on aarch64-none-linux-gnu and regression tested on 
arm-none-eabi and armeb-none-eabi for armv8.1-m.main+mve.fp.


OK for trunk?

gcc/ChangeLog:

PR target/107674
* conig/arm/arm.cc (arm_hard_regno_mode_ok): Use new MACRO.
(arm_modes_tieable_p): Make MVE predicate modes tieable.
* config/arm/arm.h (VALID_MVE_PRED_MODE):  New define.
* simplify-rtx.cc (simplify_context::simplify_subreg): Teach
simplify_subreg to simplify subregs where the outermode is not scalar.

gcc/testsuite/ChangeLog:

* gcc.target/arm/mve/mve_vpt.c: Change to remove unecessary
zero-extend.diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
index 
6f7ecf9128047647fc41677e634cd9612a13242b..4352c830cb6d2e632a225edea861b5ceb35dd035
 100644
--- a/gcc/config/arm/arm.h
+++ b/gcc/config/arm/arm.h
@@ -1091,6 +1091,10 @@ extern const int arm_arch_cde_coproc_bits[];
|| (MODE) == V16QImode || (MODE) == V8HFmode || (MODE) == V4SFmode \
|| (MODE) == V2DFmode)
 
+#define VALID_MVE_PRED_MODE(MODE) \
+  ((MODE) == HImode\
+   || (MODE) == V16BImode || (MODE) == V8BImode || (MODE) == V4BImode)
+
 #define VALID_MVE_SI_MODE(MODE) \
   ((MODE) == V2DImode ||(MODE) == V4SImode || (MODE) == V8HImode \
|| (MODE) == V16QImode)
diff --git a/gcc/config/arm/arm.cc b/gcc/config/arm/arm.cc
index 
3f171188de513e258369397e4726afe27bd9fdbf..18460ef5280be8c1df85eff424a1bf66d6019c0a
 100644
--- a/gcc/config/arm/arm.cc
+++ b/gcc/config/arm/arm.cc
@@ -25564,10 +25564,7 @@ arm_hard_regno_mode_ok (unsigned int regno, 
machine_mode mode)
 return false;
 
   if (IS_VPR_REGNUM (regno))
-return mode == HImode
-  || mode == V16BImode
-  || mode == V8BImode
-  || mode == V4BImode;
+return VALID_MVE_PRED_MODE (mode);
 
   if (TARGET_THUMB1)
 /* For the Thumb we only allow values bigger than SImode in
@@ -25646,6 +25643,10 @@ arm_modes_tieable_p (machine_mode mode1, machine_mode 
mode2)
   if (GET_MODE_CLASS (mode1) == GET_MODE_CLASS (mode2))
 return true;
 
+  if (TARGET_HAVE_MVE
+  && (VALID_MVE_PRED_MODE (mode1) && VALID_MVE_PRED_MODE (mode2)))
+return true;
+
   /* We specifically want to allow elements of "structure" modes to
  be tieable to the structure.  This more general condition allows
  other rarer situations too.  */
diff --git a/gcc/simplify-rtx.cc b/gcc/simplify-rtx.cc
index 
7fb1e97fbea4e7b8b091f5724ebe0cb61eee7ec3..a951272186585c0a5cc3e0155285e7a635865f42
 100644
--- a/gcc/simplify-rtx.cc
+++ b/gcc/simplify-rtx.cc
@@ -7652,6 +7652,22 @@ simplify_context::simplify_subreg (machine_mode 
outermode, rtx op,
}
 }
 
+  /* Try simplifying a SUBREG expression of a non-integer OUTERMODE by using a
+ NEW_OUTERMODE of the same size instead, other simplifications rely on
+ integer to integer subregs and we'd potentially miss out on optimizations
+ otherwise.  */
+  if (known_gt (GET_MODE_SIZE (innermode),
+   GET_MODE_SIZE (outermode))
+  && SCALAR_INT_MODE_P (innermode)
+  && !SCALAR_INT_MODE_P (outermode)
+  && int_mode_for_size (GET_MODE_BITSIZE (outermode),
+   0).exists (&int_outermode))
+{
+  rtx tem = simplify_subreg (int_outermode, op, innermode, byte);
+  if (tem)
+   return simplify_gen_subreg (outermode, tem, GET_MODE (tem), byte);
+}
+
   /* If OP is a vector comparison and the subreg is not changing the
  number of elements or the size of the elements, change the result
  of the comparison to the new mode.  */
diff --git a/gcc/testsuite/gcc.target/arm/mve/mve_vpt.c 
b/gcc/testsuite/gcc.target/arm/mve/mve_vpt.c
index 
26a565b79dd1348e361b3aa23a1d6e6d13bffce8..8e562a9f065eff157f63ebd5acf9af0a2155b5c5
 100644
--- a/gcc/testsuite/gcc.target/arm/mve/mve_vpt.c
+++ b/gcc/testsuite/gcc.target/arm/mve/mve_vpt.c
@@ -16,9 +16,6 @@ void test0 (uint8_t *a, uint8_t *b, uint8_t *c)
 ** vldrb.8 q2, \[r0\]
 ** vldrb.8 q1, \[r1\]
 ** vcmp.i8 eq, q2, q1
-** vmrsr3, p0  @ movhi
-** uxthr3, r3
-** vmsrp0, r3  @ movhi
 ** vpst
 ** vaddt.i8q3, q2, q1
 ** vpst

Re: [PATCH 1/3] arm: Fix sign of MVE predicate mve_pred16_t [PR 107674]

[Andre Vieira (lists) via Gcc-patches]

I meant bootstrapped on aarch64-none-linux-gnu and not none-eabi.

On 24/01/2023 13:40, Andre Vieira (lists) via Gcc-patches wrote:

Hi,

The ACLE defines mve_pred16_t as an unsigned short.  This patch makes 
sure GCC treats the predicate as an unsigned type, rather than signed.


Bootstrapped on aarch64-none-eabi and regression tested on arm-none-eabi 
and armeb-none-eabi for armv8.1-m.main+mve.fp.


OK for trunk?

gcc/ChangeLog:

 PR target/107674
 * config/arm/arm-builtins.cc (arm_simd_builtin_type): Rewrite to use
 new qualifiers parameter and use unsigned short type for MVE 
predicate.

 (arm_init_builtin): Call arm_simd_builtin_type with qualifiers
 parameter.
 (arm_init_crypto_builtins): Likewise.

gcc/testsuite/ChangeLog:

 PR target/107674
 * gcc.target/arm/mve/mve_vpt.c: New test.

[PATCH 1/3] arm: Fix sign of MVE predicate mve_pred16_t [PR 107674]

[Andre Vieira (lists) via Gcc-patches]

Hi,

The ACLE defines mve_pred16_t as an unsigned short.  This patch makes 
sure GCC treats the predicate as an unsigned type, rather than signed.


Bootstrapped on aarch64-none-eabi and regression tested on arm-none-eabi 
and armeb-none-eabi for armv8.1-m.main+mve.fp.


OK for trunk?

gcc/ChangeLog:

PR target/107674
* config/arm/arm-builtins.cc (arm_simd_builtin_type): Rewrite to use
new qualifiers parameter and use unsigned short type for MVE predicate.
(arm_init_builtin): Call arm_simd_builtin_type with qualifiers
parameter.
(arm_init_crypto_builtins): Likewise.

gcc/testsuite/ChangeLog:

PR target/107674
* gcc.target/arm/mve/mve_vpt.c: New test.diff --git a/gcc/config/arm/arm-builtins.cc b/gcc/config/arm/arm-builtins.cc
index 
11d7478d9df69139802a9d42c09dd0de7480b60e..6c67cec93ff76a4b42f3a0b305f697142e88fcd9
 100644
--- a/gcc/config/arm/arm-builtins.cc
+++ b/gcc/config/arm/arm-builtins.cc
@@ -1489,12 +1489,14 @@ arm_lookup_simd_builtin_type (machine_mode mode,
 }
 
 static tree
-arm_simd_builtin_type (machine_mode mode, bool unsigned_p, bool poly_p)
+arm_simd_builtin_type (machine_mode mode, enum arm_type_qualifiers qualifiers)
 {
-  if (poly_p)
+  if ((qualifiers & qualifier_poly) != 0)
 return arm_lookup_simd_builtin_type (mode, qualifier_poly);
-  else if (unsigned_p)
+  else if ((qualifiers & qualifier_unsigned) != 0)
 return arm_lookup_simd_builtin_type (mode, qualifier_unsigned);
+  else if ((qualifiers & qualifier_predicate) != 0)
+return unsigned_intHI_type_node;
   else
 return arm_lookup_simd_builtin_type (mode, qualifier_none);
 }
@@ -1755,9 +1757,7 @@ arm_init_builtin (unsigned int fcode, arm_builtin_datum 
*d,
   else
{
  eltype
-   = arm_simd_builtin_type (op_mode,
-(qualifiers & qualifier_unsigned) != 0,
-(qualifiers & qualifier_poly) != 0);
+   = arm_simd_builtin_type (op_mode, qualifiers);
  gcc_assert (eltype != NULL);
 
  /* Add qualifiers.  */
@@ -1929,10 +1929,10 @@ static void
 arm_init_crypto_builtins (void)
 {
   tree V16UQI_type_node
-= arm_simd_builtin_type (V16QImode, true, false);
+= arm_simd_builtin_type (V16QImode, qualifier_unsigned);
 
   tree V4USI_type_node
-= arm_simd_builtin_type (V4SImode, true, false);
+= arm_simd_builtin_type (V4SImode, qualifier_unsigned);
 
   tree v16uqi_ftype_v16uqi
 = build_function_type_list (V16UQI_type_node, V16UQI_type_node,
diff --git a/gcc/testsuite/gcc.target/arm/mve/mve_vpt.c 
b/gcc/testsuite/gcc.target/arm/mve/mve_vpt.c
new file mode 100644
index 
..26a565b79dd1348e361b3aa23a1d6e6d13bffce8
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/mve/mve_vpt.c
@@ -0,0 +1,27 @@
+/* { dg-options "-O2" } */
+/* { dg-require-effective-target arm_v8_1m_mve_ok } */
+/* { dg-add-options arm_v8_1m_mve } */
+/* { dg-final { check-function-bodies "**" "" } } */
+#include 
+void test0 (uint8_t *a, uint8_t *b, uint8_t *c)
+{
+uint8x16_t va = vldrbq_u8 (a);
+uint8x16_t vb = vldrbq_u8 (b);
+mve_pred16_t p = vcmpeqq_u8 (va, vb);
+uint8x16_t vc = vaddq_x_u8 (va, vb, p);
+vstrbq_p_u8 (c, vc, p);
+}
+/*
+** test0:
+** vldrb.8 q2, \[r0\]
+** vldrb.8 q1, \[r1\]
+** vcmp.i8 eq, q2, q1
+** vmrsr3, p0  @ movhi
+** uxthr3, r3
+** vmsrp0, r3  @ movhi
+** vpst
+** vaddt.i8q3, q2, q1
+** vpst
+** vstrbt.8q3, \[r2\]
+** bx  lr
+*/

Re: [PATCH] ipa: silent -Wodr notes with -w

[Martin Liška]

PING^4

On 1/13/23 10:09, Martin Liška wrote:
> PING^3
> 
> On 12/22/22 13:15, Martin Liška wrote:
>> PING^2
>>
>> On 12/9/22 09:27, Martin Liška wrote:
>>> PING^1
>>>
>>> On 12/2/22 12:27, Martin Liška wrote:
 If -w is used, warn_odr properly sets *warned = false and
 so it should be preserved when calling warn_types_mismatch.

 Noticed that during a LTO reduction where I used -w.

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

 Ready to be installed?
 Thanks,
 Martin

 gcc/ChangeLog:

 * ipa-devirt.cc (odr_types_equivalent_p): Respect *warned
 value if set.
 ---
   gcc/ipa-devirt.cc | 12 ++--
   1 file changed, 6 insertions(+), 6 deletions(-)

 diff --git a/gcc/ipa-devirt.cc b/gcc/ipa-devirt.cc
 index 265d07bb354..bcdc50c5bd7 100644
 --- a/gcc/ipa-devirt.cc
 +++ b/gcc/ipa-devirt.cc
 @@ -1300,7 +1300,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, 
 bool *warned,
     warn_odr (t1, t2, NULL, NULL, warn, warned,
   G_("it is defined as a pointer to different type "
  "in another translation unit"));
 -  if (warn && warned)
 +  if (warn && (warned == NULL || *warned))
   warn_types_mismatch (TREE_TYPE (t1), TREE_TYPE (t2),
    loc1, loc2);
     return false;
 @@ -1315,7 +1315,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, 
 bool *warned,
     warn_odr (t1, t2, NULL, NULL, warn, warned,
   G_("a different type is defined "
  "in another translation unit"));
 -  if (warn && warned)
 +  if (warn && (warned == NULL || *warned))
   warn_types_mismatch (TREE_TYPE (t1), TREE_TYPE (t2), loc1, loc2);
     return false;
   }
 @@ -1333,7 +1333,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, 
 bool *warned,
   warn_odr (t1, t2, NULL, NULL, warn, warned,
     G_("a different type is defined in another "
    "translation unit"));
 -    if (warn && warned)
 +    if (warn && (warned == NULL || *warned))
     warn_types_mismatch (TREE_TYPE (t1), TREE_TYPE (t2), loc1, 
 loc2);
     }
   gcc_assert (TYPE_STRING_FLAG (t1) == TYPE_STRING_FLAG (t2));
 @@ -1375,7 +1375,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, 
 bool *warned,
     warn_odr (t1, t2, NULL, NULL, warn, warned,
   G_("has different return value "
  "in another translation unit"));
 -  if (warn && warned)
 +  if (warn && (warned == NULL || *warned))
   warn_types_mismatch (TREE_TYPE (t1), TREE_TYPE (t2), loc1, loc2);
     return false;
   }
 @@ -1398,7 +1398,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, 
 bool *warned,
     warn_odr (t1, t2, NULL, NULL, warn, warned,
   G_("has different parameters in another "
  "translation unit"));
 -  if (warn && warned)
 +  if (warn && (warned == NULL || *warned))
   warn_types_mismatch (TREE_VALUE (parms1),
    TREE_VALUE (parms2), loc1, loc2);
     return false;
 @@ -1484,7 +1484,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, 
 bool *warned,
   warn_odr (t1, t2, f1, f2, warn, warned,
     G_("a field of same name but different type "
    "is defined in another translation unit"));
 -    if (warn && warned)
 +    if (warn && (warned == NULL || *warned))
     warn_types_mismatch (TREE_TYPE (f1), TREE_TYPE (f2), loc1, 
 loc2);
   return false;
     }
>>>
>>
> 

Re: [PATCH] diagnostics: fix crash with -fdiagnostics-format=json-file

[Martin Liška]

PING^1

On 1/10/23 16:10, Martin Liška wrote:
> On 1/6/23 14:21, David Malcolm wrote:
>> On Fri, 2023-01-06 at 12:33 +0100, Martin Liška wrote:
>>> Patch can bootstrap on x86_64-linux-gnu and survives regression
>>> tests.
>>
>> Thanks for the patch.
>>
>> I noticed that you marked PR 108307 as a dup of this, which covers
>> -fdiagnostics-format=sarif-file (and a .S file as input).
>>
>> The patch doesn't add any test coverage (for either of the diagnostic
>> formats).
>>
>> If we try to emit a diagnostic and base_file_name is NULL, and the user
>> requested one of -fdiagnostics-format={json,sarif}-file, where do the
>> diagnostics go?  Where should they go?
> 
> Hey.
> 
> I've done a new version of the patch where I utilize x_main_input_basename.
> 
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> 
> Ready to be installed?
> Thanks,
> Martin

[PATCH 0/3] arm: Fix regressions around MVE predicate codegen

[Andre Vieira (lists) via Gcc-patches]

Hi all,

This patch series aims to fix two or three (depends on how you look at 
it) regressions that came about in gcc 11. The first and third patch 
address wrong-codegen regressions and the second a performance 
regression. Patch two makes a change to the mid-end so I can understand 
if there are reservations about making these changes this late in the 
development stage, unfortunately I didn't get around to fixing them earlier.


Andre Vieira (3):
arm: Fix sign of MVE predicate mve_pred16_t [PR 107674]
arm: Remove unnecessary zero-extending of MVE predicates before use [PR 
107674]

arm: Fix MVE predicates synthesis [PR 108443]

Re: [PATCH 2/4] libbacktrace: detect executable path on windows

[Eli Zaretskii via Gcc-patches]

> Date: Mon, 23 Jan 2023 15:00:56 -0800
> Cc: gcc-patches@gcc.gnu.org, g...@gcc.gnu.org
> From: Ian Lance Taylor via Gcc 
> 
> > +#ifdef HAVE_WINDOWS_H
> > +
> > +static char *
> > +windows_get_executable_path (char *buf, backtrace_error_callback 
> > error_callback,
> > +void *data)
> > +{
> > +  if (GetModuleFileNameA (NULL, buf, MAX_PATH - 1) == 0)
> > +{
> > +  error_callback (data,
> > + "could not get the filename of the current 
> > executable",
> > + (int) GetLastError ());
> > +  return NULL;
> > +}
> > +  return buf;
> > +}
> 
> Thanks, but this seems incomplete.  The docs for GetModuleFileNameA
> say that if the pathname is too long to fit into the buffer it returns
> the size of the buffer and sets the error to
> ERROR_INSUFFICIENT_BUFFER.  It seems to me that in that case we should
> allocate a larger buffer and try again.

This is correct in general, but not in this particular case.

> On Windows it seems that MAX_PATH is not
> a true limit, as an extended length path may be up to 32767 bytes.

The limit of 32767 characters (not bytes, AFAIK) is only applicable
when using the Unicode (a.k.a. "wide") versions of the Windows Win32
APIs, see

  
https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation

Since the above code uses GetModuleFileNameA, which is an "ANSI"
single-byte API, it is still subject to the MAX_PATH limitation, and
MAX_PATH is defined as 260 on Windows headers.

Re: [PATCH] tree-optimization/108500 - avoid useless fast-query compute in CFG cleanup

[Jakub Jelinek via Gcc-patches]

On Tue, Jan 24, 2023 at 01:37:07PM +0100, Richard Biener wrote:
> CFG cleanup computes dominators before the loop over blocks looking
> for merging opportunities.  That computes also the fast-query DFS
> numbers but that's a bit pointless since any CFG cleanup will invalidate
> them immediately (they are re-computed before fixing up loops).
> The following avoids this and fixes the SIGSEGV due to the deep
> recursion in assign_dfs_numbers after inlining very many small
> functions.
> 
> Bootstrapped and tested on x86_64-unknown-linux-gnu, it's a border-line
> regression and the following doesn't really avoid the deep recursion
> but instead cleans up the CFG before eventually doing it.

Not very happy with adding extra argument to 110 callers of this function,
but guess we can live with it.

Ok.

>   PR tree-optimization/108500
>   * dominance.h (calculate_dominance_info): Add parameter
>   to indicate fast-query compute, defaulted to true.
>   * dominance.cc (calculate_dominance_info): Honor
>   fast-query compute parameter.
>   * tree-cfgcleanup.cc (cleanup_tree_cfg_noloop): Do
>   not compute the dominator fast-query DFS numbers.

Jakub

[PATCH] tree-optimization/108500 - avoid useless fast-query compute in CFG cleanup

[Richard Biener via Gcc-patches]

CFG cleanup computes dominators before the loop over blocks looking
for merging opportunities.  That computes also the fast-query DFS
numbers but that's a bit pointless since any CFG cleanup will invalidate
them immediately (they are re-computed before fixing up loops).
The following avoids this and fixes the SIGSEGV due to the deep
recursion in assign_dfs_numbers after inlining very many small
functions.

Bootstrapped and tested on x86_64-unknown-linux-gnu, it's a border-line
regression and the following doesn't really avoid the deep recursion
but instead cleans up the CFG before eventually doing it.

OK for trunk?

Thanks,
Richard.

PR tree-optimization/108500
* dominance.h (calculate_dominance_info): Add parameter
to indicate fast-query compute, defaulted to true.
* dominance.cc (calculate_dominance_info): Honor
fast-query compute parameter.
* tree-cfgcleanup.cc (cleanup_tree_cfg_noloop): Do
not compute the dominator fast-query DFS numbers.
---
 gcc/dominance.cc   | 9 ++---
 gcc/dominance.h| 2 +-
 gcc/tree-cfgcleanup.cc | 6 --
 3 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/gcc/dominance.cc b/gcc/dominance.cc
index 13d5498443b..099b8fd3f24 100644
--- a/gcc/dominance.cc
+++ b/gcc/dominance.cc
@@ -705,10 +705,12 @@ compute_dom_fast_query_in_region (enum cdi_direction dir,
 }
 
 /* The main entry point into this module.  DIR is set depending on whether
-   we want to compute dominators or postdominators.  */
+   we want to compute dominators or postdominators.  If COMPUTE_FAST_QUERY
+   is false then the DFS numbers allowing for a O(1) dominance query
+   are not computed.  */
 
 void
-calculate_dominance_info (cdi_direction dir)
+calculate_dominance_info (cdi_direction dir, bool compute_fast_query)
 {
   unsigned int dir_index = dom_convert_dir_to_idx (dir);
 
@@ -745,7 +747,8 @@ calculate_dominance_info (cdi_direction dir)
   else
 checking_verify_dominators (dir);
 
-  compute_dom_fast_query (dir);
+  if (compute_fast_query)
+compute_dom_fast_query (dir);
 
   timevar_pop (TV_DOMINANCE);
 }
diff --git a/gcc/dominance.h b/gcc/dominance.h
index abdcf76e6f2..3c5a345f478 100644
--- a/gcc/dominance.h
+++ b/gcc/dominance.h
@@ -35,7 +35,7 @@ enum dom_state
   DOM_OK   /* Everything is ok.  */
 };
 
-extern void calculate_dominance_info (enum cdi_direction);
+extern void calculate_dominance_info (enum cdi_direction, bool = true);
 extern void calculate_dominance_info_for_region (enum cdi_direction,
 vec);
 extern void free_dominance_info (function *, enum cdi_direction);
diff --git a/gcc/tree-cfgcleanup.cc b/gcc/tree-cfgcleanup.cc
index ca0cb633f2c..64ff16fc45b 100644
--- a/gcc/tree-cfgcleanup.cc
+++ b/gcc/tree-cfgcleanup.cc
@@ -1106,9 +1106,11 @@ cleanup_tree_cfg_noloop (unsigned ssa_update_flags)
   timevar_push (TV_TREE_CLEANUP_CFG);
 }
 
-  /* Compute dominator info which we need for the iterative process below.  */
+  /* Compute dominator info which we need for the iterative process below.
+ Avoid computing the fast query DFS numbers since any block merging
+ done will invalidate them anyway.  */
   if (!dom_info_available_p (CDI_DOMINATORS))
-calculate_dominance_info (CDI_DOMINATORS);
+calculate_dominance_info (CDI_DOMINATORS, false);
   else
 checking_verify_dominators (CDI_DOMINATORS);
 
-- 
2.35.3

Re: [PATCH 2/2] Corrected pr25521.c target matching.

[Cupertino Miranda via Gcc-patches]

Thank you for the comments and suggestions.
I have changed the patch.

Unfortunately in case of rx target I could not make
scan-assembler-symbol-section to match. I believe it is because the
.section and .global entries order is reversed in this target.

Patch in inlined below. looking forward to your comments.

Cupertino

diff --git a/gcc/testsuite/gcc.dg/pr25521.c b/gcc/testsuite/gcc.dg/pr25521.c
index 63363a03b9f..82b4cd88ec0 100644
--- a/gcc/testsuite/gcc.dg/pr25521.c
+++ b/gcc/testsuite/gcc.dg/pr25521.c
@@ -2,9 +2,10 @@
sections.
 
{ dg-require-effective-target elf }
-   { dg-do compile } */
+   { dg-do compile }
+   { dg-skip-if "" { ! const_volatile_readonly_section } } */
 
 const volatile int foo = 30;
 
-
-/* { dg-final { scan-assembler "\\.s\?rodata" } } */
+/* { dg-final { scan-assembler {.section C,} { target { rx-*-* } } } } */
+/* { dg-final { scan-assembler-symbol-section {^_?foo$} {^\.(const|s?rodata)} { target { ! "rx-*-*" } } } } */
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index c0694af2338..91aafd89909 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -12295,3 +12295,13 @@ proc check_is_prog_name_available { prog } {
 
 return 1
 }
+
+# returns 1 if target does selects a readonly section for const volatile variables.
+proc check_effective_target_const_volatile_readonly_section { } {
+
+if { [istarget powerpc-*-*]
+	  || [check-flags { "" { powerpc64-*-* } { -m32 } }] } {
+	return 0
+}
+  return 1
+}


Jeff Law writes:

> On 12/7/22 08:45, Cupertino Miranda wrote:
>>
>>> On 12/2/22 10:52, Cupertino Miranda via Gcc-patches wrote:
 This commit is a follow up of bugzilla #107181.
 The commit /a0aafbc/ changed the default implementation of the
 SELECT_SECTION hook in order to match clang/llvm behaviour w.r.t the
 placement of `const volatile' objects.
 However, the following targets use target-specific selection functions
 and they choke on the testcase pr25521.c:
*rx - target sets its const variables as '.section C,"a",@progbits'.
>>> That's presumably a constant section.  We should instead twiddle the test to
>>> recognize that section.
>> Although @progbits is indeed a constant section, I believe it is
>> more interesting to detect if the `rx' starts selecting more
>> standard sections instead of the current @progbits.
>> That was the reason why I opted to XFAIL instead of PASSing it.
>> Can I keep it as such ?
> I'm not aware of any ongoing development for that port, so I would not let
> concerns about the rx port changing behavior dominate how we approach this
> problem.
>
> The rx port is using a different name for the section.  That's  valid thing to
> do and to the extent we can, we should support that in the test rather than
> (incorrectly IMHO) xfailing the test just becuase the name isn't what we
> expected.
>
> To avoid over-eagerly matching, I would probably search for "C,"  I wouldn't 
> do
> that for the const or rodata sections as they often have a suffix like 1, 2, 
> 4,
> 8 for different sized rodata sections.
>
> PPC32 is explicitly doing something different and placing those objects into 
> an
> RW section.  So for PPC32 it makes more sense to skip the test rather than 
> xfail
> it.
>
> Jeff

Re: [PATCH v2] IBM zSystems: Fix TARGET_D_CPU_VERSIONS

[Iain Buclaw via Gcc-patches]

Excerpts from Stefan Schulze Frielinghaus's message of Januar 24, 2023 9:47 am:
> In the context of D the interpretation of S390, S390X, and SystemZ is a
> bit fuzzy.  The wording S390X was wrongly deprecated in favour of
> SystemZ by commit
> https://github.com/dlang/dlang.org/commit/3b50a4c3faf01c32234d0ef8be5f82915a61c23f
> Thus, SystemZ is used for 64-bit targets, now, and S390 for 31-bit
> targets.  However, in TARGET_D_CPU_VERSIONS depending on TARGET_ZARCH we
> set the CPU version to SystemZ.  This is also the case if compiled for
> 31-bit targets leading to the following error:
> 
> libphobos/libdruntime/core/sys/posix/sys/stat.d:967:13: error: static assert: 
>  '96u == 144u' is false
>   967 | static assert(stat_t.sizeof == 144);
>   | ^
> 
> Thus in order to keep this patch simple I went for keeping SystemZ for
> 64-bit targets and S390, as usual, for 31-bit targets and dropped the
> distinction between ESA and z/Architecture.
> 
> Bootstrapped and regtested on IBM zSystems.  Ok for mainline?
> 

OK.

Re: [PATCH] options: fix cl_target_option_print_diff() with strings

[Jakub Jelinek via Gcc-patches]

On Tue, Jan 24, 2023 at 10:37:43AM +, Jonathan Wakely wrote:
> Changing CC to gcc-patches instead of gcc-bugs ...

The fix is obvious, so I've committed it.  Thanks.

> On 24/01/23 04:14 +, Eric Biggers wrote:
> > Fix an obvious copy-and-paste error where ptr1 was used instead of ptr2.
> > This bug caused the dump file produced by -fdump-ipa-inline-details to
> > not correctly show the difference in target options when a function
> > could not be inlined due to a target option mismatch.

Though, if you have a small reproducer, it would be nice to include it
in GCC testsuite.

> > 
> > gcc/ChangeLog:
> > 
> > * optc-save-gen.awk: Fix copy-and-paste error.
> > 
> > Fixes: b54ecc769f59 ("re PR bootstrap/90543 (Build failure on MINGW for 
> > gcc-9.1.0)")

The above line doesn't belong here, instead PR bootstrap/90543 should be
above the * optc-save-gen.awk ... line.

> > Signed-off-by: Eric Biggers 
> > ---
> > gcc/optc-save-gen.awk | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/gcc/optc-save-gen.awk b/gcc/optc-save-gen.awk
> > index e91adf7f132..d2cb53c477f 100644
> > --- a/gcc/optc-save-gen.awk
> > +++ b/gcc/optc-save-gen.awk
> > @@ -1013,7 +1013,7 @@ for (i = 0; i < n_target_string; i++) {
> > print " indent, \"\",";
> > print " \"" name "\",";
> > print " ptr1->x_" name " ? ptr1->x_" name " : \"(null)\",";
> > -   print " ptr2->x_" name " ? ptr1->x_" name " : \"(null)\");";
> > +   print " ptr2->x_" name " ? ptr2->x_" name " : \"(null)\");";
> > print "";
> > }
> > 
> > -- 
> > 2.39.1.405.gd4c25cc71f-goog
> > 

Jakub

Re: [PATCH][GCC] arm: Fix inclusion of arm-mlib.h header more than once (pr108505).

[Richard Earnshaw via Gcc-patches]

On 24/01/2023 09:55, Srinath Parvathaneni via Gcc-patches wrote:

Hello,

The patch fixes the build issue for arm-none-eabi target configured with
--with-multilib-list=aprofile,rmprofile, in which case the header file
arm/arm-mlib.h is being included more than once and the toolchain build
is failing (PR108505).

Regression tested on arm-none-eabi target and found no regressions.

Ok for master?

Regards,
Srinath.

gcc/ChangeLog:

2023-01-24  Srinath Parvathaneni  

 PR target/108505
 * config.gcc (tm_file): Move the variable out of loop.


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




A more robust fix would be:



diff --git a/gcc/config.gcc b/gcc/config.gcc
index 
771bd35e803b47e79c0a62eab8f4845e9bbf96ef..d828223c16d3076da0ab6582dfaf59ad657ea438
 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -4350,7 +4350,6 @@ case "${target}" in
case ${arm_multilib} in
aprofile|rmprofile)

tmake_profile_file="arm/t-multilib"
-   tm_file="$tm_file 
arm/arm-mlib.h"

tm_mlib_file="arm/arm-mlib.h"

;;
@*)
ml=`echo "X$arm_multilib" | sed 
'1s,^X@,,'`
@@ -4389,6 +4388,7 @@ case "${target}" in
# through to the multilib selector
with_float="soft"
tmake_file="${tmake_file} ${tmake_profile_file}"
+   tm_file="$tm_file arm/arm-mlib.h"

tm_file="$tm_file $tm_mlib_file"


TM_MULTILIB_CONFIG="$with_multilib_list"
fi
fi





Then if we ever need to add additional alternative multilib variants we 
can control the selection separately.


R.

Re: [PATCH] options: fix cl_target_option_print_diff() with strings

[Jonathan Wakely via Gcc-patches]

Changing CC to gcc-patches instead of gcc-bugs ...

On 24/01/23 04:14 +, Eric Biggers wrote:

Fix an obvious copy-and-paste error where ptr1 was used instead of ptr2.
This bug caused the dump file produced by -fdump-ipa-inline-details to
not correctly show the difference in target options when a function
could not be inlined due to a target option mismatch.

gcc/ChangeLog:

* optc-save-gen.awk: Fix copy-and-paste error.

Fixes: b54ecc769f59 ("re PR bootstrap/90543 (Build failure on MINGW for 
gcc-9.1.0)")
Signed-off-by: Eric Biggers 
---
gcc/optc-save-gen.awk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/optc-save-gen.awk b/gcc/optc-save-gen.awk
index e91adf7f132..d2cb53c477f 100644
--- a/gcc/optc-save-gen.awk
+++ b/gcc/optc-save-gen.awk
@@ -1013,7 +1013,7 @@ for (i = 0; i < n_target_string; i++) {
print " indent, \"\",";
print " \"" name "\",";
print " ptr1->x_" name " ? ptr1->x_" name " : \"(null)\",";
-   print " ptr2->x_" name " ? ptr1->x_" name " : \"(null)\");";
+   print " ptr2->x_" name " ? ptr2->x_" name " : \"(null)\");";
print "";
}

--
2.39.1.405.gd4c25cc71f-goog

Re: [PATCH 2/2] Add VREL_OTHER for FP unsupported relations.

[Jakub Jelinek via Gcc-patches]

On Mon, Jan 23, 2023 at 12:44:48PM -0500, Andrew MacLeod wrote:
> @@ -784,17 +794,28 @@ value_relation::negate ()
>  bool
>  value_relation::intersect (const value_relation &p)
>  {
> -  // Save previous value
> -  relation_kind old = related;
> +  relation_kind k;
>  
>if (p.op1 () == op1 () && p.op2 () == op2 ())
> -related = relation_intersect (kind (), p.kind ());
> +k = relation_intersect (kind (), p.kind ());
>else if (p.op2 () == op1 () && p.op1 () == op2 ())
> -related = relation_intersect (kind (), relation_swap (p.kind ()));
> +k = relation_intersect (kind (), relation_swap (p.kind ()));
>else
>  return false;
>  
> -  return old != related;
> +  if (related == k)
> +return false;
> +
> +  bool float_p = name1 && FLOAT_TYPE_P (TREE_TYPE (name1));
> +  if (float_p && p.kind () != k && k == VREL_UNDEFINED)
> +{
> +  if (relation_lt_le_gt_ge_p (kind ())
> +   || relation_lt_le_gt_ge_p (p.kind ()))
> + k = VREL_OTHER;
> +}

I don't understand this.

When at least one of the relations is VREL_{L,G}{T,E} and intersection
is VREL_UNDEFINED, it means other relation is VREL_UNDEFINED (but then
VREL_UNDEFINED is the right range to return), or one is VREL_{L,G}T
and the other is VREL_EQ (x > y && x == y, again, VREL_UNDEFINED is
the right answer, no ordered pair of x and y is greater (or less) and
equal at the same time and for unordered (at least one NaN) both
relations are false), or it is VREL_LT vs. VREL_G{T,E} or vice versa
or VREL_GT vs. VREL_L{T,E} or vice versa
(x < y && x >= y again, for ordered pairs of x and y it is never
true, if any is NaN, neither comparison is true).

I don't think you need to do anything floating point related in intersect.
It might seem to be inconsistent with union, but that is just because
VREL_OTHER is the union of VREL_LTGT, VREL_ORDERED, VREL_UNORDERED,
VREL_UNLT, VREL_UNGT, VREL_UNGT, VREL_UNGE and VREL_UNEQ, if we had
those 8 in addition to the current 8 non-PE ones you'd see that for
intersections one only gets the new codes when fp with possible
NANs and at least one of the intersection operand is one of the new
codes.  In the VREL_OTHER world, simply VREL_OTHER intersected with
anything but VREL_UNDEFINED is VREL_OTHER.

> +  // (x < y) || (x > y) produces x != y, but this is not true with floats.
> +  // (x <= y) || (x >= y) produces VARYING, which is also not true for 
> floats.

This misses a couple of needed cases both in this comment and
in the actual implementation.  In particular, the first comment
line is right, x < y || x > y is the only one where we get
VREL_NE and want VREL_OTHER (VREL_LTGT maybe later).
x <= y || x >= y is just one of the cases which produce VREL_VARYING
and we want VREL_OTHER (VREL_ORDERED maybe later) though,
x < y || x >= y
x <= y || x > y
are the others where from the current tables you also get
VREL_VARYING but want VREL_OTHER (VREL_ORDERED eventually).

> +  // As they cannot be properly represented, use VREL_OTHER.
> +  bool float_p = name1 && FLOAT_TYPE_P (TREE_TYPE (name1));

This should be
  bool float_p = name1 && HONOR_NANS (TREE_TYPE (name1));
If it is not floating point mode, it will be false, if it is
floating point mode which doesn't have NANs in hw, it also behaves
the same relation-wise, and lastly if hw supports NANs but user
uses -ffast-math or -ffinite-math-only, the user guaranteed that
the operands will never be NAN (nor +-INF), which means that
again relation behave like the integral/pointer ones, there is
no 4th possible outcome of a comparison.

> +  if (float_p && p.kind () != k)
> +{
> +  if (kind () == VREL_LT && p.kind () == VREL_GT)
> + k = VREL_OTHER;
> +  else if (kind () == VREL_GT && p.kind () == VREL_LT)
> + k = VREL_OTHER;
> +  else if (kind () == VREL_LE && p.kind () == VREL_GE)
> + k = VREL_OTHER;
> +  else if (kind () == VREL_GE && p.kind () == VREL_LE)
> + k = VREL_OTHER;

And as written above, this misses the VREL_LT vs. VREL_GE or
VREL_GE vs. VREL_LT or VREL_GT vs. VREL_LE or VREL_LE vs. VREL_GT
cases.
I think it is easier written as
  if (k == VREL_VARYING
  && relation_lt_le_gt_ge_p (kind ())
  && relation_lt_le_gt_ge_p (p.kind ()))
k = VREL_OTHER;
Only when/if we'll want to differentiate between VREL_LTGT for
VREL_LT vs. VREL_GT or VREL_GT vs. VREL_LT and VREL_ORDERED
for the others we will need something different.

> --- a/gcc/value-relation.h
> +++ b/gcc/value-relation.h
> @@ -70,6 +70,7 @@ typedef enum relation_kind_t
>VREL_GE,   // r1 >= r2
>VREL_EQ,   // r1 == r2
>VREL_NE,   // r1 != r2
> +  VREL_OTHER,// unrepresentatble floating point relation.

s/unrepresentatble/unrepresentable/

>VREL_PE8,  // 8 bit partial equivalency
>VREL_PE16, // 16 bit partial equivalency
>VREL_PE32, // 32 bit partial equivalency

Otherwise LGTM (i.e. I agree with VREL_OTHER introduction for now)
and the intersect/union

RE: [PATCH][GCC] arm: Fix inclusion of arm-mlib.h header more than once (pr108505).

[Kyrylo Tkachov via Gcc-patches]

> -Original Message-
> From: Srinath Parvathaneni 
> Sent: Tuesday, January 24, 2023 9:55 AM
> To: gcc-patches@gcc.gnu.org
> Cc: nd ; Richard Earnshaw ;
> Kyrylo Tkachov 
> Subject: [PATCH][GCC] arm: Fix inclusion of arm-mlib.h header more than
> once (pr108505).
> 
> Hello,
> 
> The patch fixes the build issue for arm-none-eabi target configured with
> --with-multilib-list=aprofile,rmprofile, in which case the header file
> arm/arm-mlib.h is being included more than once and the toolchain build
> is failing (PR108505).
> 
> Regression tested on arm-none-eabi target and found no regressions.
> 
> Ok for master?
> 

Ok.
Thanks,
Kyrill

> Regards,
> Srinath.
> 
> gcc/ChangeLog:
> 
> 2023-01-24  Srinath Parvathaneni  
> 
> PR target/108505
> * config.gcc (tm_file): Move the variable out of loop.
> 
> 
> ### Attachment also inlined for ease of reply
> ###
> 
> 
> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index
> 771bd35e803b47e79c0a62eab8f4845e9bbf96ef..d828223c16d3076da0ab658
> 2dfaf59ad657ea438 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -4350,7 +4350,6 @@ case "${target}" in
>   case ${arm_multilib} in
>   aprofile|rmprofile)
>   tmake_profile_file="arm/t-
> multilib"
> - tm_file="$tm_file arm/arm-
> mlib.h"
>   ;;
>   @*)
>   ml=`echo "X$arm_multilib" |
> sed '1s,^X@,,'`
> @@ -4389,6 +4388,7 @@ case "${target}" in
>   # through to the multilib selector
>   with_float="soft"
>   tmake_file="${tmake_file}
> ${tmake_profile_file}"
> + tm_file="$tm_file arm/arm-mlib.h"
>   TM_MULTILIB_CONFIG="$with_multilib_list"
>   fi
>   fi
> 
> 

[PATCH][GCC] arm: Fix inclusion of arm-mlib.h header more than once (pr108505).

[Srinath Parvathaneni via Gcc-patches]

Hello,

The patch fixes the build issue for arm-none-eabi target configured with
--with-multilib-list=aprofile,rmprofile, in which case the header file
arm/arm-mlib.h is being included more than once and the toolchain build
is failing (PR108505).

Regression tested on arm-none-eabi target and found no regressions.

Ok for master?

Regards,
Srinath.

gcc/ChangeLog:

2023-01-24  Srinath Parvathaneni  

PR target/108505
* config.gcc (tm_file): Move the variable out of loop.


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


diff --git a/gcc/config.gcc b/gcc/config.gcc
index 
771bd35e803b47e79c0a62eab8f4845e9bbf96ef..d828223c16d3076da0ab6582dfaf59ad657ea438
 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -4350,7 +4350,6 @@ case "${target}" in
case ${arm_multilib} in
aprofile|rmprofile)

tmake_profile_file="arm/t-multilib"
-   tm_file="$tm_file 
arm/arm-mlib.h"
;;
@*)
ml=`echo "X$arm_multilib" | sed 
'1s,^X@,,'`
@@ -4389,6 +4388,7 @@ case "${target}" in
# through to the multilib selector
with_float="soft"
tmake_file="${tmake_file} ${tmake_profile_file}"
+   tm_file="$tm_file arm/arm-mlib.h"
TM_MULTILIB_CONFIG="$with_multilib_list"
fi
fi



diff --git a/gcc/config.gcc b/gcc/config.gcc
index 
771bd35e803b47e79c0a62eab8f4845e9bbf96ef..d828223c16d3076da0ab6582dfaf59ad657ea438
 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -4350,7 +4350,6 @@ case "${target}" in
case ${arm_multilib} in
aprofile|rmprofile)

tmake_profile_file="arm/t-multilib"
-   tm_file="$tm_file 
arm/arm-mlib.h"
;;
@*)
ml=`echo "X$arm_multilib" | sed 
'1s,^X@,,'`
@@ -4389,6 +4388,7 @@ case "${target}" in
# through to the multilib selector
with_float="soft"
tmake_file="${tmake_file} ${tmake_profile_file}"
+   tm_file="$tm_file arm/arm-mlib.h"
TM_MULTILIB_CONFIG="$with_multilib_list"
fi
fi

Update 'libgomp/libgomp.texi' for 'nvptx, libgfortran: Switch out of "minimal" mode' (was: nvptx, libgfortran: Switch out of "minimal" mode)

[Thomas Schwinge]

Hi!

On 2023-01-20T22:16:00+0100, I wrote:
> On 2023-01-20T22:04:02+0100, I wrote:
>> We've been (t)asked to enable (portions of) GCC/Fortran I/O for nvptx
>> offloading, which means building a normal (non-'LIBGFOR_MINIMAL')
>> configuration of libgfortran.
>
> This is achieved by 'nvptx, libgfortran: Switch out of "minimal" mode',
> see attached, again based on WIP work by Andrew Stubbs.  This I've just
> pushed to devel/omp/gcc-12 branch in
> commit c7734c6fbb5513b4da6306de7bc85de9b8547988, and would like to push
> to master branch once other pending GCC patches have been accepted.
>
>
> The OpenACC XFAILs: "[...] overflows the stack for nvptx offloading"
> are unresolved at this point; see the discussion around
> "Handling of large stack objects in GPU code generation -- maybe transform 
> into heap allocation?",
> and my "nvptx: '-mframe-malloc-threshold', '-Wframe-malloc-threshold'"
> experimenting.  (The latter works to some extent, but also has other
> issues that I shall detail at some later point in time.)

I had a note from Tobias to "update the the last but one bullet point at
https://gcc.gnu.org/onlinedocs/libgomp/nvptx.html";.  Thus pushed to
devel/omp/gcc-12 branch commit 8c29332e98ca4669a059ebc0d90903b409ae049f
"Update 'libgomp/libgomp.texi' for 'nvptx, libgfortran: Switch out of "minimal" 
mode'",
see attached.  Please consider that one 'fixup'ed into the GCC master
branch submission.


Grüße
 Thomas


> From c7734c6fbb5513b4da6306de7bc85de9b8547988 Mon Sep 17 00:00:00 2001
> From: Thomas Schwinge 
> Date: Wed, 21 Sep 2022 18:58:34 +0200
> Subject: [PATCH] nvptx, libgfortran: Switch out of "minimal" mode
>
> ..., in order to enable (portions of) Fortran I/O, for example.
>
> libgfortran/ChangeLog:
>
>   * configure: Regenerate.
>   * configure.ac: No longer set LIBGFOR_MINIMAL for nvptx.
>
> libgomp/ChangeLog:
>
>   * testsuite/libgomp.fortran/target-print-1.f90: Adjust.
>   * testsuite/libgomp.fortran/target-print-1-nvptx.f90: Remove.
>   * testsuite/libgomp.oacc-fortran/print-1.f90: Adjust.
>   * testsuite/libgomp.oacc-fortran/print-1-nvptx.f90: Remove.
>   * testsuite/libgomp.oacc-fortran/error_stop-2.f: Adjust.
>   * testsuite/libgomp.oacc-fortran/stop-2.f: Likewise.
>
> Co-authored-by: Andrew Stubbs 
> ---
>  libgfortran/ChangeLog.omp   |  6 ++
>  libgfortran/configure   | 17 ++---
>  libgfortran/configure.ac| 17 ++---
>  libgomp/ChangeLog.omp   |  7 +++
>  .../libgomp.fortran/target-print-1-nvptx.f90| 11 ---
>  .../libgomp.fortran/target-print-1.f90  |  3 ---
>  .../libgomp.oacc-fortran/error_stop-2.f |  4 +++-
>  .../libgomp.oacc-fortran/print-1-nvptx.f90  | 11 ---
>  .../testsuite/libgomp.oacc-fortran/print-1.f90  |  5 ++---
>  libgomp/testsuite/libgomp.oacc-fortran/stop-2.f |  4 +++-
>  10 files changed, 33 insertions(+), 52 deletions(-)
>  delete mode 100644 libgomp/testsuite/libgomp.fortran/target-print-1-nvptx.f90
>  delete mode 100644 libgomp/testsuite/libgomp.oacc-fortran/print-1-nvptx.f90
>
> diff --git a/libgfortran/ChangeLog.omp b/libgfortran/ChangeLog.omp
> index b08c264daf9..925575e65fa 100644
> --- a/libgfortran/ChangeLog.omp
> +++ b/libgfortran/ChangeLog.omp
> @@ -1,3 +1,9 @@
> +2023-01-20  Thomas Schwinge  
> + Andrew Stubbs  
> +
> + * configure: Regenerate.
> + * configure.ac: No longer set LIBGFOR_MINIMAL for nvptx.
> +
>  2023-01-20  Thomas Schwinge  
>
>   PR target/85463
> diff --git a/libgfortran/configure b/libgfortran/configure
> index ae64dca3114..3e5c931d4ad 100755
> --- a/libgfortran/configure
> +++ b/libgfortran/configure
> @@ -6230,17 +6230,12 @@ else
>  fi
>
>
> -# For GPU offloading, not everything in libfortran can be supported.
> -# Currently, the only target that has this problem is nvptx.  The
> -# following is a (partial) list of features that are unsupportable on
> -# this particular target:
> -# * Constructors
> -# * alloca
> -# * C library support for I/O, with printf as the one notable exception
> -# * C library support for other features such as signal, environment
> -#   variables, time functions
> -
> - if test "x${target_cpu}" = xnvptx; then
> +# "Minimal" mode is for targets that cannot (yet) support all features of
> +# libgfortran.  It avoids the need for working constructors, alloca, and C
> +# library support for I/O, signals, environment variables, time functions, 
> etc.
> +# At present there are no targets that require this mode.
> +
> + if false; then
>LIBGFOR_MINIMAL_TRUE=
>LIBGFOR_MINIMAL_FALSE='#'
>  else
> diff --git a/libgfortran/configure.ac b/libgfortran/configure.ac
> index 97cc490cb5e..e5552949cc6 100644
> --- a/libgfortran/configure.ac
> +++ b/libgfortran/configure.ac
> @@ -222,17 +222,12 @@ AM_CONDITIONAL(LIBGFOR_USE_SYMVER, [test 
> "x$gfortran_use_symver" != xno])
>  AM_CONDITIONAL(LIBGFOR_USE_SYMVE

Re: [PATCH 1/2] Use value_relation class instead of direct calls to intersect/union.

[Jakub Jelinek via Gcc-patches]

On Mon, Jan 23, 2023 at 12:44:42PM -0500, Andrew MacLeod wrote:
> In order to fix 108447, this patch changes the calls to relation_union and
> relation_intersection to instead utilize the value_relation class, and make
> the calls through that instead.
> 
> value_relation manages the operands of a relation, and thus understands
> whether this is a floating point relation and can make any adjustments
> required to get the proper results.  THis patch doesn't do anything
> additional, just that isolation so we can track if it introduces anything
> speerate from the next change which adds another relation.
> 
> Bootstraps on x86_64-pc-linux-gnu with no regressions.  OK?

LGTM.

Jakub

Re: [committed] pru: Fix CLZ expansion for QI and HI modes

[Richard Sandiford via Gcc-patches]

Dimitar Dimitrov  writes:
> The recent gcc.dg/tree-ssa/clz-char.c test case failed for PRU target,
> exposing a wrong code generation bug in the PRU backend.  The "clz"
> pattern did not produce correct output for QI and HI input operand
> modes.  SI mode is ok.
>
> The "clz" pattern is expanded to an LMBD instruction to get the
> left-most bit position having value "1".  In turn, to get the correct
> "clz" value, that bit position must be subtracted from the MSB bit
> position of the input operand.  The old behaviour of hard-coding 31
> for MSB bit position is wrong.
>
> The LMBD instruction returns 32 if input operand is zero, irrespective
> of its register mode.  This maps nicely for SI mode, where the "clz"
> pattern outputs -1.  It also leads to peculiar (but valid!) output
> values from the "clz" pattern for QI and HI zero-valued inputs.
>
> Pushed to trunk. This patch is confined to the PRU backend only,
> and is fixing a wrong code generation.  Hence I deem it suitable
> for stage 4.
>
> Is it ok to push a backport to gcc-11 and gcc-12 branches?

Since it's a backend-specific patch, I think that's your call.

Thanks,
Richard

> gcc/ChangeLog:
>
>   * config/pru/pru.h (CLZ_DEFINED_VALUE_AT_ZERO): Fix value for QI
>   and HI input modes.
>   * config/pru/pru.md (clz): Fix generated code for QI and HI
>   input modes.
>
> gcc/testsuite/ChangeLog:
>
>   * gcc.target/pru/clz-hi-2.c: New test.
>   * gcc.target/pru/clz-hi.c: New test.
>
> Signed-off-by: Dimitar Dimitrov 
> ---
>  gcc/config/pru/pru.h|  5 ++--
>  gcc/config/pru/pru.md   | 15 ---
>  gcc/testsuite/gcc.target/pru/clz-hi-2.c | 24 +
>  gcc/testsuite/gcc.target/pru/clz-hi.c   | 35 +
>  4 files changed, 74 insertions(+), 5 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/pru/clz-hi-2.c
>  create mode 100644 gcc/testsuite/gcc.target/pru/clz-hi.c
>
> diff --git a/gcc/config/pru/pru.h b/gcc/config/pru/pru.h
> index 3658036cccb..1b5e874bc06 100644
> --- a/gcc/config/pru/pru.h
> +++ b/gcc/config/pru/pru.h
> @@ -566,8 +566,9 @@ do {  
> \
>  
>  #define CASE_VECTOR_MODE Pmode
>  
> -/* See definition of clz pattern for rationale of value -1.  */
> -#define CLZ_DEFINED_VALUE_AT_ZERO(MODE, VALUE) ((VALUE) = -1, 2)
> +/* See definition of clz pattern for rationale of the value.  */
> +#define CLZ_DEFINED_VALUE_AT_ZERO(MODE, VALUE)   \
> + ((VALUE) = GET_MODE_BITSIZE (MODE) - 1 - 32, 2)
>  
>  /* Jumps are cheap on PRU.  */
>  #define LOGICAL_OP_NON_SHORT_CIRCUIT 0
> diff --git a/gcc/config/pru/pru.md b/gcc/config/pru/pru.md
> index dfe08071e04..aa8e42a3587 100644
> --- a/gcc/config/pru/pru.md
> +++ b/gcc/config/pru/pru.md
> @@ -1723,8 +1723,16 @@ (define_insn "pru_halt"
>[(set_attr "type" "control")])
>  
>  ;; Count Leading Zeros implemented using LMBD.
> -;; LMBD returns 32 if bit value is not present, and we subtract 31 to get 
> CLZ.
> -;; Hence we get a defined value -1 for CLZ_DEFINED_VALUE_AT_ZERO.
> +;;
> +;; LMBD returns 32 if bit value is not present, for any kind of input MODE.
> +;; The LMBD's search result for a "1" bit is subtracted from the
> +;; mode bit size minus one, in order to get CLZ.
> +;;
> +;; Hence for SImode we get a defined value -1 for CLZ_DEFINED_VALUE_AT_ZERO.
> +;;
> +;; The QImode and HImode defined values for zero inputs end up to be
> +;; non-standard (-25 and -17).  But this is considered acceptable in
> +;; order to keep the CLZ expansion to only two instructions.
>  (define_expand "clz2"
>[(set (match_operand:QISI 0 "register_operand")
>   (clz:QISI (match_operand:QISI 1 "register_operand")))]
> @@ -1735,7 +1743,8 @@ (define_expand "clz2"
>rtx tmpval = gen_reg_rtx (mode);
>  
>emit_insn (gen_pru_lmbd (mode, tmpval, src, const1_rtx));
> -  emit_insn (gen_sub3_insn (dst, GEN_INT (31), tmpval));
> +  int msb_bitn = GET_MODE_BITSIZE (mode) - 1;
> +  emit_insn (gen_sub3_insn (dst, GEN_INT (msb_bitn), tmpval));
>DONE;
>  })
>  
> diff --git a/gcc/testsuite/gcc.target/pru/clz-hi-2.c 
> b/gcc/testsuite/gcc.target/pru/clz-hi-2.c
> new file mode 100644
> index 000..af877c7021e
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/pru/clz-hi-2.c
> @@ -0,0 +1,24 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fno-tree-ch" } */
> +
> +/* This test case is based on gcc.dg/tree-ssa/clz-char.c. */
> +
> +#define PREC (sizeof(short) * 8)
> +
> +int
> +__attribute__ ((noinline, noclone))
> +foo (unsigned short b) {
> +int c = 0;
> +
> +if (b == 0)
> +  return PREC;
> +
> +while (!(b & (1 << (PREC - 1 {
> + b <<= 1;
> + c++;
> +}
> +
> +return c;
> +}
> +
> +/* { dg-final { scan-assembler "lmbd\\tr\[012\]\[0-9\]?.w\[0-2\], 
> r\[012\]\[0-9\]?.w\[0-2\], 1" } } */
> diff --git a/gcc/testsuite/gcc.target/pru/clz-hi.c 
> b/gcc/testsuite/gcc.target/pru/clz-hi.c
> new file m

Make 'libgcc/config/nvptx/crt0.c' build '--without-headers' (was: [PING] nvptx: Support global constructors/destructors via 'collect2')

[Thomas Schwinge]

Hi!

On 2022-12-20T09:03:51+0100, I wrote:
> Minor change in the attached
> "nvptx: Support global constructors/destructors via 'collect2'": for
> 'atexit', add '#include ' to 'libgcc/config/nvptx/crt0.c'.

Turns out, it's not that easy.  ;-) Pushed to devel/omp/gcc-12 branch
commit d90a8a5685c8bd3657892feac01739fe87a457a5
"Make 'libgcc/config/nvptx/crt0.c' build '--without-headers'", see
attached.  Please consider that one 'fixup'ed into the GCC master branch
submission.


Grüße
 Thomas


> --- a/libgcc/config/nvptx/crt0.c
> +++ b/libgcc/config/nvptx/crt0.c
> @@ -19,6 +19,9 @@
> see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
> .  */
>
> +#include 
> +#include "gbl-ctors.h"
> +
>  int *__exitval_ptr;
>
>  extern void __attribute__((noreturn)) exit (int status);
> @@ -47,5 +50,8 @@ __main (int *rval_ptr, int argc, void **argv)
>__nvptx_stacks[0] = stack + sizeof stack;
>__nvptx_uni[0] = 0;
>
> +  __do_global_ctors ();
> +  atexit (__do_global_dtors);
> +
>exit (main (argc, argv));
>  }


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From d90a8a5685c8bd3657892feac01739fe87a457a5 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Tue, 24 Jan 2023 09:49:34 +0100
Subject: [PATCH] Make 'libgcc/config/nvptx/crt0.c' build '--without-headers'

..., where it currently fails:

[...]/libgcc/config/nvptx/crt0.c:22:10: fatal error: stdlib.h: No such file or directory
   22 | #include 
  |  ^~

Fix-up for "nvptx: Support global constructors/destructors via 'collect2'".

	libgcc/
	* config/nvptx/crt0.c [!HAVE_STDLIB_H]: Don't '#include '.
	(atexit): Prototype.
---
 libgcc/ChangeLog.omp   | 5 +
 libgcc/config/nvptx/crt0.c | 7 ++-
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/libgcc/ChangeLog.omp b/libgcc/ChangeLog.omp
index c46f49bf5b7..cf509a70d61 100644
--- a/libgcc/ChangeLog.omp
+++ b/libgcc/ChangeLog.omp
@@ -1,3 +1,8 @@
+2023-01-24  Thomas Schwinge  
+
+	* config/nvptx/crt0.c [!HAVE_STDLIB_H]: Don't '#include '.
+	(atexit): Prototype.
+
 2023-01-20  Thomas Schwinge  
 	Andrew Stubbs  
 
diff --git a/libgcc/config/nvptx/crt0.c b/libgcc/config/nvptx/crt0.c
index 860e2bfacad..02648bef84b 100644
--- a/libgcc/config/nvptx/crt0.c
+++ b/libgcc/config/nvptx/crt0.c
@@ -19,11 +19,16 @@
see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
.  */
 
-#include 
+#include "auto-target.h"
+
+#ifdef HAVE_STDLIB_H
+# include 
+#endif
 #include "gbl-ctors.h"
 
 int *__exitval_ptr;
 
+extern int atexit (void (*function) (void));
 extern void __attribute__((noreturn)) exit (int status);
 extern int main (int, void **);
 
-- 
2.25.1

Re: [PATCH] tree-optimization/108306 - Correctly detect shifts out of range

[Richard Biener via Gcc-patches]

On Tue, Jan 24, 2023 at 12:22 AM Andrew MacLeod via Gcc-patches
 wrote:
>
> get_shift_range was incorrectly communicating that it couldn't calculate
> a range when the shift value was out of range.
>
> Fix this and always return a range of [0, 0] instead of varying when the
> shift value is out of range.
>
> Bootstraps with no regressions on x86_64-pc-linux-gnu.  OK for trunk?

OK.

> Andrew

[PATCH v2] IBM zSystems: Fix TARGET_D_CPU_VERSIONS

[Stefan Schulze Frielinghaus via Gcc-patches]

In the context of D the interpretation of S390, S390X, and SystemZ is a
bit fuzzy.  The wording S390X was wrongly deprecated in favour of
SystemZ by commit
https://github.com/dlang/dlang.org/commit/3b50a4c3faf01c32234d0ef8be5f82915a61c23f
Thus, SystemZ is used for 64-bit targets, now, and S390 for 31-bit
targets.  However, in TARGET_D_CPU_VERSIONS depending on TARGET_ZARCH we
set the CPU version to SystemZ.  This is also the case if compiled for
31-bit targets leading to the following error:

libphobos/libdruntime/core/sys/posix/sys/stat.d:967:13: error: static assert:  
'96u == 144u' is false
  967 | static assert(stat_t.sizeof == 144);
  | ^

Thus in order to keep this patch simple I went for keeping SystemZ for
64-bit targets and S390, as usual, for 31-bit targets and dropped the
distinction between ESA and z/Architecture.

Bootstrapped and regtested on IBM zSystems.  Ok for mainline?

gcc/ChangeLog:

* config/s390/s390-d.cc (s390_d_target_versions): Fix detection
of CPU version.
---
 gcc/config/s390/s390-d.cc | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/gcc/config/s390/s390-d.cc b/gcc/config/s390/s390-d.cc
index d10b45f7de4..6e9c80f7283 100644
--- a/gcc/config/s390/s390-d.cc
+++ b/gcc/config/s390/s390-d.cc
@@ -30,10 +30,11 @@ along with GCC; see the file COPYING3.  If not see
 void
 s390_d_target_versions (void)
 {
-  if (TARGET_ZARCH)
-d_add_builtin_version ("SystemZ");
-  else if (TARGET_64BIT)
-d_add_builtin_version ("S390X");
+  if (TARGET_64BIT)
+{
+  d_add_builtin_version ("S390X");
+  d_add_builtin_version ("SystemZ");
+}
   else
 d_add_builtin_version ("S390");
 
-- 
2.39.0

Re: [PATCH 2/2] Add VREL_OTHER for FP unsupported relations.

[Richard Biener via Gcc-patches]

On Mon, Jan 23, 2023 at 6:44 PM Andrew MacLeod  wrote:
>
> This patch adds VREL_OTHER to represent another relation we do not
> understand.  It is used to represent the class fo relations arising from
> floating point that are currently not represented. IN GCC 14 we will
> determine exactly how to represent them, but for this release, this
> should prevent us from getting things wrong at least.
>
> if intersection produces UNDEFINED and either of the relations feeding
> it were <, <=, >, or >=   then it turns it to VR_OTHER.   the prevents
> false sides of branches from combining to produce  UNDEFINED when they
> end up being a known NAN.
>
> Union is adjusted such that < >, or <= >= also produce VREL_OTHER.   < >
> cannot be properly represented, and <= >= was producing VARYING, which
> is also not correct.
>
> Form the testcase:
>
>   :
>  cmp1_10 = x_8(D) <= y_9(D);
>  cmp2_11 = x_8(D) >= y_9(D);
>  _3 = cmp1_10 & cmp2_11;
>  if (_3 != 0)
>goto ; [INV]
>  else
>goto ; [INV]
>
> Relational : (x_8(D) == y_9(D))
>   :
>  // predicted unlikely by early return (on trees) predictor.
>  goto ; [INV]
>
>
>   :
>  _4 = ~cmp1_10;
>  _5 = ~cmp2_11;
>  _1 = cmp1_10 | cmp2_11;
>  _6 = ~_1;
>  if (_1 != 0)
>goto ; [INV]
>  else
>goto ; [INV]
>
> Relational : (x_8(D) unknown fp y_9(D))
>   :
>  // predicted unlikely by early return (on trees) predictor.
>
>
> The intersection "fix" is represented by the relation between x and y in
> BB5.  Without the patch, ti would be UNDEFINED and we do not want that.
>
> The union fix is what prevents us from folding the condition in bb_4.
> Without it, x<=y union x >=y comes out VARYING, when in fact I believe
> it represents everything except a NAN.
>
> So with this fix, all the unrepresentative relations get lumped into
> VREL_OTHER so we at least don't get it wrong.  For next release we can
> take the time to figure out exactly how we want to proceed.
>
> This is currently in testing on x86_64-pc-linux-gnu, and assuming it
> bootstraps with no regressions (a combined patch did before splitting it
> in 2), OK for trunk?   OR does it need more tweaking?

LGTM, I'd appreciate a 2nd eye though - you've gone through all the
pecularities of combining FP relations in the PRs audit trail.

Richard.

>
> Andrew

Re: [PATCH 1/2] Use value_relation class instead of direct calls to intersect/union.

[Richard Biener via Gcc-patches]

On Mon, Jan 23, 2023 at 6:44 PM Andrew MacLeod  wrote:
>
> In order to fix 108447, this patch changes the calls to relation_union
> and relation_intersection to instead utilize the value_relation class,
> and make the calls through that instead.
>
> value_relation manages the operands of a relation, and thus understands
> whether this is a floating point relation and can make any adjustments
> required to get the proper results.  THis patch doesn't do anything
> additional, just that isolation so we can track if it introduces
> anything speerate from the next change which adds another relation.
>
> Bootstraps on x86_64-pc-linux-gnu with no regressions.  OK?

LGTM

> Andrew