Re: [PATCH] avr: cc0 to mode_cc conversion

[Segher Boessenkool]

On Thu, Dec 17, 2020 at 10:07:22AM -0500, Paul Koning wrote:
> > On Dec 17, 2020, at 6:21 AM, Segher Boessenkool 
> >  wrote:
> > On Thu, Dec 17, 2020 at 02:15:51PM +0530, Senthil Kumar Selvaraj via 
> > Gcc-patches wrote:
> >> The work on my github branch was not complete - I'd blindly followed
> >> whatever the CC0 Transition wiki mentioned (the first three steps of
> >> case #2), and fixed any regression fallout (for ATmega128).
> >> 
> >> I intend to try out a define_subst/early clobber of reg_cc based
> >> approach (inspired by the cris port) and see if that can help avoid the
> >> proliferation of define_insn_and_splits. Will update how that works out.
> > 
> > Yeah, case #2 does not necessarily give the best result, but it usually
> > is the least work to do, so certainly a good choice under time pressure.
> 
> I was under the impression from what I read in the blog a year or two ago 
> (when I did the pdp11 ccmode work) that "case 2" is the better answer for 
> machines in which pretty much every operation touches the condition codes.  
> In other words, I understood that case 1 would for such machines not be the 
> right answer -- it wasn't just that "case 2 is easier".
> 
> Did I misunderstand?  Is there a reason for machines such as pdp11, in which 
> basically every operation that handles data, even a move instruction, touches 
> CC, to use approach 1?

No, you didn't misunderstand.  I said "not necessarily" for a reason :-)

If there are move insns that do *not* clobber CC, it can be different,
but if even move instructions do, a case #2 conversion is a good choice.

(This is all my opinion, but I think it is not controversial.)


Segher

Re: [patch] gcc.dg/analyzer tests: relax dependency on alloca.h

[Olivier Hainque]

Hello,

Ping for https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557548.html
(copied below for convenience), please ?

Thanks in advance!

With Kind Regards,

Olivier

> On 29 Oct 2020, at 21:45, Olivier Hainque  wrote:
> 
> Hello,
> 
> Some of the tests in gcc.dg/analyzer exercize alloca
> and #include .
> 
> Some systems, e.g. VxWorks, don't feature alloca.h and
> the aforementioned tests fail.
> 
> Other tests in the suite have been in this situation and
> the usual way around consists in resorting to __builtin_alloca
> directly.
> 
> This patch is a proposal in this direction for gcc.dg/analyzer.
> 
> It introduces a common "analyzer-alloca.h" where we can
> stick a common comment and a macro to redirect "alloca"
> directly to "__builtin_alloca".
> 
> The intermediate macro in a non system header unfortunately
> diverts some of the warning expectations, as the allocation
> point for "x = alloca(128);" is shown on the macro definition
> and not at the macro invocation point.
> 
> The patch circumvents this by calling __builtin_alloca
> directly from the points where the tests perform a warning
> check.
> 
> I have verified that all the tests adjusted by the change
> now pass in a run for a powerpc-vxworks configuration.
> 
> I'll gladly perform an extra regression test on a native
> system if the patch is considered ok.
> 
> Would this be ok to commit ?
> 
> Thanks in advance,
> 
> With Kind Regards,
> 
> Olivier
> 
> 2020-10-29  Olivier Hainque  
> 
> gcc/testsuite/
>* gcc.dg/analyzer/analyzer-alloca.h: New file.
>* gcc.dg/analyzer/alloca-leak.c: Use it.
>* gcc.dg/analyzer/data-model-1.c: Use it.
>* gcc.dg/analyzer/malloc-1.c: Use it and replace call to
>be tracked by a direct call to __builtin_alloca.
>* gcc.dg/analyzer/malloc-paths-8.c: Likewise.
> 
> <0001-Relax-dependency-on-alloca.h-in-gcc.dg-analyzer-tests.txt>
> 
> 

Re: [PATCH] libstdc++: Add support for C++20 barriers

[Jonathan Wakely via Gcc-patches]

On 17/12/20 15:37 -0800, Thomas Rodgers wrote:

From: Thomas Rodgers 

Cleans up a few things mentioned on IRC.

Adds 

libstdc++/ChangeLog:

* doc/doxygen/user.cfg.in: Add new header.
* include/Makefile.am (std_headers): likewise.
* include/Makefile.in: Regenerate.
   * include/precompiled/stdc++.h: Add new header.
* include/std/barrier: New file.
* include/std/version: Add __cpp_lib_barrier feature test macro.
* testsuite/30_thread/barrier/1.cc: New test.
* testsuite/30_thread/barrier/2.cc: Likewise.
* testsuite/30_thread/barrier/arrive_and_drop.cc: Likewise.
* testsuite/30_thread/barrier/arrive_and_wait.cc: Likewise.
* testsuite/30_thread/barrier/arrive.cc: Likewise.
* testsuite/30_thread/barrier/completion.cc: Likewise.
* testsuite/30_thread/barrier/max.cc: Likewise.




+#ifndef _GLIBCXX_BARRIER
+#define _GLIBCXX_BARRIER 1
+
+#pragma GCC system_header
+
+#if __cplusplus > 201703L
+#include 
+#if __cpp_lib_atomic_wait  && __cpp_aligned_new


There's an extra space here before the && operator.


+#endif // __cpp_lib_atomic_wait  && __cpp_aligned_new


And here.


+#endif // __cplusplus > 201703L
+#endif // _GLIBCXX_BARRIER
+
diff --git a/libstdc++-v3/include/std/version b/libstdc++-v3/include/std/version
index e4a8bed52ab..07d17433c5b 100644
--- a/libstdc++-v3/include/std/version
+++ b/libstdc++-v3/include/std/version
@@ -200,6 +200,9 @@
#if defined _GLIBCXX_HAS_GTHREADS || defined _GLIBCXX_HAVE_LINUX_FUTEX
# define __cpp_lib_atomic_wait 201907L
#endif
+#if __cpp_lib_atomic_wait


This needs to match the condition used in .


+#define __cpp_lib_barrier 201907L
+#endif


You could just put it inside the previous block where
__cpp_lib_atomic_wait is defined:

#if defined _GLIBCXX_HAS_GTHREADS || defined _GLIBCXX_HAVE_LINUX_FUTEX
# define __cpp_lib_atomic_wait 201907L
# if __cpp_aligned_new
#  define __cpp_lib_barrier 201907L
# endif
#endif


#define __cpp_lib_bind_front 201907L
#if __has_builtin(__builtin_bit_cast)
# define __cpp_lib_bit_cast 201806L
diff --git a/libstdc++-v3/testsuite/30_threads/barrier/1.cc 
b/libstdc++-v3/testsuite/30_threads/barrier/1.cc
new file mode 100644
index 000..0b38160a58b
--- /dev/null
+++ b/libstdc++-v3/testsuite/30_threads/barrier/1.cc
@@ -0,0 +1,27 @@
+// Copyright (C) 2020 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// { dg-options "-std=gnu++2a" }
+// { dg-do compile { target c++2a } }


This test will fail for non-gthreads targets, because they don't
define the macro. This needs the same condition as the similar
29_atomics/atomic/wait_notify/1.cc test:

// { dg-require-effective-target gthreads }

(which is the new way to say { dg-requires-gthread "" })


+#include 
+
+#ifndef __cpp_lib_barrier
+# error "Feature-test macro for barrier missing in "
+#elif __cpp_lib_barrier != 201907L
+# error "Feature-test macro for barrier has wrong value in "
+#endif
diff --git a/libstdc++-v3/testsuite/30_threads/barrier/2.cc 
b/libstdc++-v3/testsuite/30_threads/barrier/2.cc
new file mode 100644
index 000..1d8d83639e0
--- /dev/null
+++ b/libstdc++-v3/testsuite/30_threads/barrier/2.cc
@@ -0,0 +1,27 @@
+// Copyright (C) 2019-2020 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// { dg-options "-std=gnu++2a" }
+// { dg-do compile { target c++2a } }


Same here.


+#include 
+
+#ifndef __cpp_lib_barrier
+# error "Feature-test macro for barrier missing in "
+#elif __cpp_lib_barrier != 201907L
+# error "Feature-test macro for barrier has wrong value in "
+#endif
diff --git a/libstdc++-v3/

Re: Patch RFA: Support non-ASCII file names in git-changelog

[Martin Liška]

On 12/17/20 5:26 AM, Ian Lance Taylor via Gcc-patches wrote:

As discussed at
https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561995.html ,
the ChangeLog checker does not correctly handle files with non-ASCII
file names.

This patch fixes the problem.  I have little experience with Python,
so I may have made some foolish mistakes here.

OK to commit?

Thanks.

Ian

* gcc-changelog/git_repository.py: Ignore quotation marks added by git
for non-ASCII file names.



First, sorry for a slow response about the previous
thread (Change to gcc/testsuite/go.test/test rejected by ChangeLog checker).

Well, the suggested change will not help us because we will not be able
to find a file with a given path (\xxx\yyy...).

Proper solution is likely doing:
$ git config --global core.quotepath false

both on server side (and client side).

Having that, git properly displays non-ascii filenames:

commit 1814a090a816884892240752c927f7dbb50a10da
Author: Martin Liska 
Date:   Fri Dec 18 11:00:52 2020 +0100

Add new file.

ChangeLog:

* špatně.txt: New file.


diff --git a/špatně.txt b/špatně.txt
new file mode 100644
index 000..e69de29bb2d

Thoughts?
Martin

[PATCH] vect: Fix missing alias checks for 128-bit SVE [PR98371]

[Richard Sandiford via Gcc-patches]

On AArch64, the vectoriser tries various ways of vectorising with both
SVE and Advanced SIMD and picks the best one.  All other things being
equal, it prefers earlier attempts over later attempts.

The way this works currently is that, once it has a successful
vectorisation attempt A, it analyses all other attempts as epilogue
loops of A:

  /* When pick_lowest_cost_p is true, we should in principle iterate
 over all the loop_vec_infos that LOOP_VINFO could replace and
 try to vectorize LOOP_VINFO under the same conditions.
 E.g. when trying to replace an epilogue loop, we should vectorize
 LOOP_VINFO as an epilogue loop with the same VF limit.  When trying
 to replace the main loop, we should vectorize LOOP_VINFO as a main
 loop too.

 However, autovectorize_vector_modes is usually sorted as follows:

 - Modes that naturally produce lower VFs usually follow modes that
   naturally produce higher VFs.

 - When modes naturally produce the same VF, maskable modes
   usually follow unmaskable ones, so that the maskable mode
   can be used to vectorize the epilogue of the unmaskable mode.

 This order is preferred because it leads to the maximum
 epilogue vectorization opportunities.  Targets should only use
 a different order if they want to make wide modes available while
 disparaging them relative to earlier, smaller modes.  The assumption
 in that case is that the wider modes are more expensive in some
 way that isn't reflected directly in the costs.

 There should therefore be few interesting cases in which
 LOOP_VINFO fails when treated as an epilogue loop, succeeds when
 treated as a standalone loop, and ends up being genuinely cheaper
 than FIRST_LOOP_VINFO.  */

However, the vectoriser can normally elide alias checks for epilogue
loops, on the basis that the main loop should do them instead.
Converting an epilogue loop to a main loop can therefore cause the alias
checks to be skipped.  (It probably also unfairly penalises the original
loop in the cost comparison, given that one loop will have alias checks
and the other won't.)

As the comment says, we should in principle analyse each vector mode
twice: once as a main loop and once as an epilogue.  However, doing
that up-front would be quite expensive.  This patch instead goes for a
compromise: if an epilogue loop for mode M2 seems better than a main
loop for mode M1, re-analyse with M2 as the main loop.

The patch fixes dg.torture.exp=pr69719.c when testing with
-msve-vector-bits=128.

Tested on aarch64-linux-gnu and x86_64-linux-gnu.  OK to install?

Richard


gcc/
PR tree-optimization/98371
* tree-vect-loop.c (vect_reanalyze_as_main_loop): New function.
(vect_analyze_loop): If an epilogue loop appears to be cheaper
than the main loop, re-analyze it as a main loop before adopting
it as a main loop.
---
 gcc/tree-vect-loop.c | 61 +---
 1 file changed, 58 insertions(+), 3 deletions(-)

diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
index 688538a4521..221541f4a38 100644
--- a/gcc/tree-vect-loop.c
+++ b/gcc/tree-vect-loop.c
@@ -2850,6 +2850,45 @@ vect_joust_loop_vinfos (loop_vec_info new_loop_vinfo,
   return true;
 }
 
+/* If LOOP_VINFO is already a main loop, return it unmodified.  Otherwise
+   try to reanalyze it as a main loop.  Return the loop_vinfo on success
+   and null on failure.  */
+
+static loop_vec_info
+vect_reanalyze_as_main_loop (loop_vec_info loop_vinfo, unsigned int *n_stmts)
+{
+  if (!LOOP_VINFO_EPILOGUE_P (loop_vinfo))
+return loop_vinfo;
+
+  if (dump_enabled_p ())
+dump_printf_loc (MSG_NOTE, vect_location,
+"* Reanalyzing as a main loop with vector mode %s\n",
+GET_MODE_NAME (loop_vinfo->vector_mode));
+
+  struct loop *loop = LOOP_VINFO_LOOP (loop_vinfo);
+  vec_info_shared *shared = loop_vinfo->shared;
+  opt_loop_vec_info main_loop_vinfo = vect_analyze_loop_form (loop, shared);
+  gcc_assert (main_loop_vinfo);
+
+  main_loop_vinfo->vector_mode = loop_vinfo->vector_mode;
+
+  bool fatal = false;
+  bool res = vect_analyze_loop_2 (main_loop_vinfo, fatal, n_stmts);
+  loop->aux = NULL;
+  if (!res)
+{
+  if (dump_enabled_p ())
+   dump_printf_loc (MSG_NOTE, vect_location,
+"* Failed to analyze main loop with vector"
+" mode %s\n",
+GET_MODE_NAME (loop_vinfo->vector_mode));
+  delete main_loop_vinfo;
+  return NULL;
+}
+  LOOP_VINFO_VECTORIZABLE_P (main_loop_vinfo) = 1;
+  return main_loop_vinfo;
+}
+
 /* Function vect_analyze_loop.
 
Apply a set of analyses on LOOP, and create a loop_vec_info struct
@@ -2997,9 +3036,25 @@ vect_analyze_loop (class loop *loop, vec_info_shared 
*shared)
  if (vinfos.is_

[PATCH] Make switchconv smarter.

[Martin Liška]

The patch covers 2 cases mentioned in the PR.

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

Ready to be installed?
Thanks,
Martin

gcc/ChangeLog:

PR tree-optimization/94779
* tree-switch-conversion.c (switch_conversion::switch_conversion):
Initialize m_default_unreachable, m_missing_return_in_default
and m_inbound_check_needed.
(switch_conversion::collect): Start with first edge also
if m_default_unreachable or m_missing_return_in_default.
(switch_conversion::check_all_empty_except_final): Ignore
default edge for case where m_default_unreachable is true.
(switch_conversion::phi_leads_to_return): New.
(switch_conversion::build_one_array): Drop boundary
check for linear transformation where
m_missing_return_in_default is true
(switch_conversion::analyze_default_bb): New.
(switch_conversion::gen_inbound_check): Generate if TRUE when
m_default_unreachable or we don't need boundary check.
(switch_conversion::expand): Do transformation as we can't be
sure that the switch will be expanded with JT.
* tree-switch-conversion.h: Declare new functions and
variables.

gcc/testsuite/ChangeLog:

PR tree-optimization/94779
* gcc.dg/tree-ssa/cswtch-6.c: New test.
* gcc.dg/tree-ssa/cswtch-7.c: New test.
---
 gcc/testsuite/gcc.dg/tree-ssa/cswtch-6.c | 22 +++
 gcc/testsuite/gcc.dg/tree-ssa/cswtch-7.c | 19 ++
 gcc/tree-switch-conversion.c | 78 
 gcc/tree-switch-conversion.h | 14 +
 4 files changed, 122 insertions(+), 11 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/cswtch-6.c
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/cswtch-7.c

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/cswtch-6.c 
b/gcc/testsuite/gcc.dg/tree-ssa/cswtch-6.c
new file mode 100644
index 000..e5aa09fdbde
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/cswtch-6.c
@@ -0,0 +1,22 @@
+/* PR tree-optimization/94779 */
+/* { dg-options "-O2 -fdump-tree-switchconv" } */
+/* { dg-do compile { target nonpic } } */
+
+int global;
+
+int f1(unsigned x)
+{
+int v;
+switch (x)
+{
+case 0:
+return 1;
+case 1:
+return 2;
+case 2:
+return 3;
+}
+}
+
+/* { dg-final { scan-tree-dump-times "Linear transformation with A = 1 and B = 1" 1 
"switchconv" } } */
+/* { dg-final { scan-tree-dump-not "if " "switchconv" } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/cswtch-7.c 
b/gcc/testsuite/gcc.dg/tree-ssa/cswtch-7.c
new file mode 100644
index 000..15ca9849f9d
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/cswtch-7.c
@@ -0,0 +1,19 @@
+/* PR tree-optimization/94779 */
+/* { dg-options "-O2 -fdump-tree-switchconv" } */
+/* { dg-do compile { target nonpic } } */
+
+int global;
+
+int f1(unsigned x)
+{
+switch (x)
+{
+case 0:
+return 1;
+case 1:
+return 2;
+}
+}
+
+/* { dg-final { scan-tree-dump-times "Linear transformation with A = 1 and B = 1" 1 
"switchconv" } } */
+/* { dg-final { scan-tree-dump "Switch converted" "switchconv" } } */
diff --git a/gcc/tree-switch-conversion.c b/gcc/tree-switch-conversion.c
index 08dfd6f3580..dd64daf4b92 100644
--- a/gcc/tree-switch-conversion.c
+++ b/gcc/tree-switch-conversion.c
@@ -64,7 +64,9 @@ using namespace tree_switch_conversion;
 switch_conversion::switch_conversion (): m_final_bb (NULL),
   m_constructors (NULL), m_default_values (NULL),
   m_arr_ref_first (NULL), m_arr_ref_last (NULL),
-  m_reason (NULL), m_default_case_nonstandard (false), m_cfg_altered (false)
+  m_reason (NULL), m_default_unreachable (false),
+  m_missing_return_in_default (false), m_inbound_check_needed (true),
+  m_default_case_nonstandard (false), m_cfg_altered (false)
 {
 }
 
@@ -90,6 +92,8 @@ switch_conversion::collect (gswitch *swtch)

   m_default_bb = e_default->dest;
   m_default_prob = e_default->probability;
 
+  analyze_default_bb ();

+
   /* Get upper and lower bounds of case values, and the covered range.  */
   min_case = gimple_switch_label (swtch, 1);
   max_case = gimple_switch_label (swtch, branch_num - 1);
@@ -113,7 +117,9 @@ switch_conversion::collect (gswitch *swtch)
   last = CASE_HIGH (elt) ? CASE_HIGH (elt) : CASE_LOW (elt);
 }
 
-  if (m_contiguous_range)

+  if (m_contiguous_range
+  || m_default_unreachable
+  || m_missing_return_in_default)
 e_first = gimple_switch_edge (cfun, swtch, 1);
   else
 e_first = e_default;
@@ -142,7 +148,7 @@ switch_conversion::collect (gswitch *swtch)
&& single_succ (e->dest) == m_final_bb)
  continue;
 
-	if (e == e_default && m_contiguous_range)

+   if (e == e_default && (m_contiguous_range || m_default_unreachable))
  {
m_default_case_nonstandard = true;
continue;
@@ -211,6 +217,9 @@ switch_conversion::ch

Re: [PATCH 3/4] libstdc++: Add floating-point std::to_chars implementation

[Christophe Lyon via Gcc-patches]

Hi,


On Fri, 18 Dec 2020 at 05:13, Patrick Palka via Gcc-patches
 wrote:
>
> On Thu, Dec 17, 2020 at 9:32 AM Jonathan Wakely  wrote:
> >
> > On 19/08/20 17:57 -0400, Patrick Palka via Libstdc++ wrote:
> > >On Wed, 22 Jul 2020, Patrick Palka wrote:
> > >
> > >> On Mon, 20 Jul 2020, Patrick Palka wrote:
> > >>
> > >> > On Mon, 20 Jul 2020, Jonathan Wakely wrote:
> > >> >
> > >> > > On 20/07/20 08:53 -0400, Patrick Palka via Libstdc++ wrote:
> > >> > > > On Mon, 20 Jul 2020, Jonathan Wakely wrote:
> > >> > > >
> > >> > > > > On 19/07/20 23:37 -0400, Patrick Palka via Libstdc++ wrote:
> > >> > > > > > On Fri, 17 Jul 2020, Patrick Palka wrote:
> > >> > > > > >
> > >> > > > > > > On Fri, 17 Jul 2020, Patrick Palka wrote:
> > >> > > > > > >
> > >> > > > > > > > On Wed, 15 Jul 2020, Patrick Palka wrote:
> > >> > > > > > > >
> > >> > > > > > > > > On Tue, 14 Jul 2020, Patrick Palka wrote:
> > >> > > > > > > > >
> > >> > > > > > > > > > This implements the floating-point std::to_chars 
> > >> > > > > > > > > > overloads for
> > >> > > > > > > float,
> > >> > > > > > > > > > double and long double.  We use the Ryu library to 
> > >> > > > > > > > > > compute the
> > >> > > > > > > shortest
> > >> > > > > > > > > > round-trippable fixed and scientific forms of a number 
> > >> > > > > > > > > > for
> > >> > > > > float,
> > >> > > > > > > double
> > >> > > > > > > > > > and long double.  We also use Ryu for performing fixed 
> > >> > > > > > > > > > and
> > >> > > > > > > scientific
> > >> > > > > > > > > > formatting of float and double. For formatting long 
> > >> > > > > > > > > > double with
> > >> > > > > an
> > >> > > > > > > > > > explicit precision argument we use a printf fallback.
> > >> > > > > Hexadecimal
> > >> > > > > > > > > > formatting for float, double and long double is 
> > >> > > > > > > > > > implemented from
> > >> > > > > > > > > > scratch.
> > >> > > > > > > > > >
> > >> > > > > > > > > > The supported long double binary formats are float64 
> > >> > > > > > > > > > (same as
> > >> > > > > > > double),
> > >> > > > > > > > > > float80 (x86 extended precision), float128 and ibm128.
> > >> > > > > > > > > >
> > >> > > > > > > > > > Much of the complexity of the implementation is in 
> > >> > > > > > > > > > computing the
> > >> > > > > > > exact
> > >> > > > > > > > > > output length before handing it off to Ryu (which 
> > >> > > > > > > > > > doesn't do
> > >> > > > > bounds
> > >> > > > > > > > > > checking).  In some cases it's hard to compute the 
> > >> > > > > > > > > > output length
> > >> > > > > > > before
> > >> > > > > > > > > > the fact, so in these cases we instead compute an 
> > >> > > > > > > > > > upper bound on
> > >> > > > > the
> > >> > > > > > > > > > output length and use a sufficiently-sized 
> > >> > > > > > > > > > intermediate buffer
> > >> > > > > (if
> > >> > > > > > > the
> > >> > > > > > > > > > output range is smaller than the upper bound).
> > >> > > > > > > > > >
> > >> > > > > > > > > > Another source of complexity is in the 
> > >> > > > > > > > > > general-with-precision
> > >> > > > > > > formatting
> > >> > > > > > > > > > mode, where we need to do zero-trimming of the string 
> > >> > > > > > > > > > returned
> > >> > > > > by
> > >> > > > > > > Ryu, and
> > >> > > > > > > > > > where we also take care to avoid having to format the 
> > >> > > > > > > > > > string a
> > >> > > > > > > second
> > >> > > > > > > > > > time when the general formatting mode resolves to 
> > >> > > > > > > > > > fixed.
> > >> > > > > > > > > >
> > >> > > > > > > > > > Tested on x86_64-pc-linux-gnu, 
> > >> > > > > > > > > > aarch64-unknown-linux-gnu,
> > >> > > > > > > > > > s390x-ibm-linux-gnu, and powerpc64-unknown-linux-gnu.
> > >> > > > > > > > > >
> > >> > > > > > > > > > libstdc++-v3/ChangeLog:
> > >> > > > > > > > > >
> > >> > > > > > > > > >* acinclude.m4 (libtool_VERSION): Bump to 6:29:0.
> > >> > > > > > > > > >* config/abi/pre/gnu.ver: Add new exports.
> > >> > > > > > > > > >* configure: Regenerate.
> > >> > > > > > > > > >* include/std/charconv (to_chars): Declare the 
> > >> > > > > > > > > > floating-point
> > >> > > > > > > > > >overloads for float, double and long double.
> > >> > > > > > > > > >* src/c++17/Makefile.am (sources): Add 
> > >> > > > > > > > > > floating_to_chars.cc.
> > >> > > > > > > > > >* src/c++17/Makefile.in: Regenerate.
> > >> > > > > > > > > >* src/c++17/floating_to_chars.cc: New file.
> > >> > > > > > > > > >* testsuite/20_util/to_chars/long_double.cc: New 
> > >> > > > > > > > > > test.
> > >> > > > > > > > > >* testsuite/util/testsuite_abi.cc: Add new symbol 
> > >> > > > > > > > > > version.
> > >> > > > > > > > >
> > >> > > > > > > > > Here is v2 of this patch, which fixes a build failure on 
> > >> > > > > > > > > i386 due
> > >> > > > > to
> > >> > > > > > > > > __int128 being unavailable, by refactoring the long 
> > >> > > > > > > > > double binary
> > >> > > > > > > format
> > >> > > > > >

Re: [PATCH][AArch32] MVE: Split refactoring of remaining complex instrinsics

[Christophe Lyon via Gcc-patches]

On Wed, 16 Dec 2020 at 21:43, Tamar Christina via Gcc-patches
 wrote:
>
> Hi All,
>
> This refactors the complex numbers bits of MVE to go through the same unspecs
> as the NEON variant.
>
> This is pre-work to allow code to be shared between NEON and MVE for the 
> complex
> vectorization patches.
>
> Bootstrapped Regtested on arm-none-linux-gnueabihf and no issues.
> Codegen tested for -march=armv8.1-m.main+mve.fp -mfloat-abi=hard -mfpu=auto
> and no issues.
>

Hi Tamar,

This patch causes regressions for me:
gcc.target/arm/mve/intrinsics/vcmulq_f16.c (test for excess errors)
gcc.target/arm/mve/intrinsics/vcmulq_f32.c (test for excess errors)
gcc.target/arm/mve/intrinsics/vcmulq_rot180_f16.c (test for excess errors)
gcc.target/arm/mve/intrinsics/vcmulq_rot180_f32.c (test for excess errors)
gcc.target/arm/mve/intrinsics/vcmulq_rot270_f16.c (test for excess errors)
gcc.target/arm/mve/intrinsics/vcmulq_rot270_f32.c (test for excess errors)
gcc.target/arm/mve/intrinsics/vcmulq_rot90_f16.c (test for excess errors)
gcc.target/arm/mve/intrinsics/vcmulq_rot90_f32.c (test for excess errors)

I can see:
FAIL: gcc.target/arm/mve/intrinsics/vcmulq_f16.c (test for excess errors)
Excess errors:
vcmulq_f16.s:40: Warning: missing operand; zero assumed
vcmulq_f16.s:61: Warning: missing operand; zero assumed

I didn't check the code manually yet, and I am using binutils-2.34:
has something
related to this changed in more recent gas?

Thanks

Christophe

> This is just a splitting of a previously approved patch due to it having a
> dependency on the AArch64 bits which have been requested to be reworked.
>
> Will commit under the previous approval.
>
> Thanks,
> Tamar
>
> gcc/ChangeLog:
>
> * config/arm/arm_mve.h (__arm_vcmulq_rot90_f16):
> (__arm_vcmulq_rot270_f16, _arm_vcmulq_rot180_f16, __arm_vcmulq_f16,
> __arm_vcmulq_rot90_f32, __arm_vcmulq_rot270_f32,
> __arm_vcmulq_rot180_f32, __arm_vcmulq_f32, __arm_vcmlaq_f16,
> __arm_vcmlaq_rot180_f16, __arm_vcmlaq_rot270_f16,
> __arm_vcmlaq_rot90_f16, __arm_vcmlaq_f32, __arm_vcmlaq_rot180_f32,
> __arm_vcmlaq_rot270_f32, __arm_vcmlaq_rot90_f32): Update builtin 
> calls.
> * config/arm/arm_mve_builtins.def (vcmulq_f, vcmulq_rot90_f,
> vcmulq_rot180_f, vcmulq_rot270_f, vcmlaq_f, vcmlaq_rot90_f,
> vcmlaq_rot180_f, vcmlaq_rot270_f): Removed.
> (vcmulq, vcmulq_rot90, vcmulq_rot180, vcmulq_rot270, vcmlaq,
> vcmlaq_rot90, vcmlaq_rot180, vcmlaq_rot270): New.
> * config/arm/iterators.md (mve_rot): Add UNSPEC_VCMLA, UNSPEC_VCMLA90,
> UNSPEC_VCMLA180, UNSPEC_VCMLA270, UNSPEC_VCMUL, UNSPEC_VCMUL90,
> UNSPEC_VCMUL180, UNSPEC_VCMUL270.
> (VCMUL): New.
> * config/arm/mve.md (mve_vcmulq_f,
> mve_vcmulq_rot270_f, mve_vcmulq_rot90_f, 
> mve_vcmlaq_f,
> mve_vcmlaq_rot180_f, mve_vcmlaq_rot270_f,
> mve_vcmlaq_rot90_f): Removed.
> (mve_vcmlaq, mve_vcmulq,
> mve_vcaddq, cadd3, 
> mve_vcaddq):
> New.
> * config/arm/unspecs.md (UNSPEC_VCMUL90, UNSPEC_VCMUL270, 
> UNSPEC_VCMUL,
> UNSPEC_VCMUL180): New.
> (VCMULQ_F, VCMULQ_ROT180_F, VCMULQ_ROT270_F, VCMULQ_ROT90_F,
> VCMLAQ_F, VCMLAQ_ROT180_F, VCMLAQ_ROT90_F, VCMLAQ_ROT270_F): Removed.
>
> --- inline copy of patch --
> diff --git a/gcc/config/arm/arm_mve.h b/gcc/config/arm/arm_mve.h
> index 
> 987495dd234ad96ba1163a1f482fe183a46ff437..45014621f2533497e90ddf5257fb04e1fd9325b4
>  100644
> --- a/gcc/config/arm/arm_mve.h
> +++ b/gcc/config/arm/arm_mve.h
> @@ -17348,28 +17348,28 @@ __extension__ extern __inline float16x8_t
>  __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
>  __arm_vcmulq_rot90_f16 (float16x8_t __a, float16x8_t __b)
>  {
> -  return __builtin_mve_vcmulq_rot90_fv8hf (__a, __b);
> +  return __builtin_mve_vcmulq_rot90v8hf (__a, __b);
>  }
>
>  __extension__ extern __inline float16x8_t
>  __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
>  __arm_vcmulq_rot270_f16 (float16x8_t __a, float16x8_t __b)
>  {
> -  return __builtin_mve_vcmulq_rot270_fv8hf (__a, __b);
> +  return __builtin_mve_vcmulq_rot270v8hf (__a, __b);
>  }
>
>  __extension__ extern __inline float16x8_t
>  __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
>  __arm_vcmulq_rot180_f16 (float16x8_t __a, float16x8_t __b)
>  {
> -  return __builtin_mve_vcmulq_rot180_fv8hf (__a, __b);
> +  return __builtin_mve_vcmulq_rot180v8hf (__a, __b);
>  }
>
>  __extension__ extern __inline float16x8_t
>  __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
>  __arm_vcmulq_f16 (float16x8_t __a, float16x8_t __b)
>  {
> -  return __builtin_mve_vcmulq_fv8hf (__a, __b);
> +  return __builtin_mve_vcmulqv8hf (__a, __b);
>  }
>
>  __extension__ extern __inline float16x8_t
> @@ -17600,28 +17600,28 @@ __extension__ extern __inline float32x4_t
>  __attribute__ ((__always_inline__, __gnu_inline__, __art

RE: [PATCH][AArch32] MVE: Split refactoring of remaining complex instrinsics

[Tamar Christina via Gcc-patches]

Hi Christophe,

> -Original Message-
> From: Christophe Lyon 
> Sent: Friday, December 18, 2020 2:22 PM
> To: Tamar Christina 
> Cc: gcc Patches ; Richard Earnshaw
> ; nd ; Ramana Radhakrishnan
> 
> Subject: Re: [PATCH][AArch32] MVE: Split refactoring of remaining complex
> instrinsics
> 
> On Wed, 16 Dec 2020 at 21:43, Tamar Christina via Gcc-patches  patc...@gcc.gnu.org> wrote:
> >
> > Hi All,
> >
> > This refactors the complex numbers bits of MVE to go through the same
> > unspecs as the NEON variant.
> >
> > This is pre-work to allow code to be shared between NEON and MVE for
> > the complex vectorization patches.
> >
> > Bootstrapped Regtested on arm-none-linux-gnueabihf and no issues.
> > Codegen tested for -march=armv8.1-m.main+mve.fp -mfloat-abi=hard
> > -mfpu=auto and no issues.
> >
> 
> Hi Tamar,
> 
> This patch causes regressions for me:
> gcc.target/arm/mve/intrinsics/vcmulq_f16.c (test for excess errors)
> gcc.target/arm/mve/intrinsics/vcmulq_f32.c (test for excess errors)
> gcc.target/arm/mve/intrinsics/vcmulq_rot180_f16.c (test for excess errors)
> gcc.target/arm/mve/intrinsics/vcmulq_rot180_f32.c (test for excess errors)
> gcc.target/arm/mve/intrinsics/vcmulq_rot270_f16.c (test for excess errors)
> gcc.target/arm/mve/intrinsics/vcmulq_rot270_f32.c (test for excess errors)
> gcc.target/arm/mve/intrinsics/vcmulq_rot90_f16.c (test for excess errors)
> gcc.target/arm/mve/intrinsics/vcmulq_rot90_f32.c (test for excess errors)
> 
> I can see:
> FAIL: gcc.target/arm/mve/intrinsics/vcmulq_f16.c (test for excess errors)
> Excess errors:
> vcmulq_f16.s:40: Warning: missing operand; zero assumed
> vcmulq_f16.s:61: Warning: missing operand; zero assumed

That's quite odd.

I'll check it out thanks.

Regards,
Tamar

> 
> I didn't check the code manually yet, and I am using binutils-2.34:
> has something
> related to this changed in more recent gas?
> 
> Thanks
> 
> Christophe
> 
> > This is just a splitting of a previously approved patch due to it
> > having a dependency on the AArch64 bits which have been requested to
> be reworked.
> >
> > Will commit under the previous approval.
> >
> > Thanks,
> > Tamar
> >
> > gcc/ChangeLog:
> >
> > * config/arm/arm_mve.h (__arm_vcmulq_rot90_f16):
> > (__arm_vcmulq_rot270_f16, _arm_vcmulq_rot180_f16,
> __arm_vcmulq_f16,
> > __arm_vcmulq_rot90_f32, __arm_vcmulq_rot270_f32,
> > __arm_vcmulq_rot180_f32, __arm_vcmulq_f32, __arm_vcmlaq_f16,
> > __arm_vcmlaq_rot180_f16, __arm_vcmlaq_rot270_f16,
> > __arm_vcmlaq_rot90_f16, __arm_vcmlaq_f32,
> __arm_vcmlaq_rot180_f32,
> > __arm_vcmlaq_rot270_f32, __arm_vcmlaq_rot90_f32): Update builtin
> calls.
> > * config/arm/arm_mve_builtins.def (vcmulq_f, vcmulq_rot90_f,
> > vcmulq_rot180_f, vcmulq_rot270_f, vcmlaq_f, vcmlaq_rot90_f,
> > vcmlaq_rot180_f, vcmlaq_rot270_f): Removed.
> > (vcmulq, vcmulq_rot90, vcmulq_rot180, vcmulq_rot270, vcmlaq,
> > vcmlaq_rot90, vcmlaq_rot180, vcmlaq_rot270): New.
> > * config/arm/iterators.md (mve_rot): Add UNSPEC_VCMLA,
> UNSPEC_VCMLA90,
> > UNSPEC_VCMLA180, UNSPEC_VCMLA270, UNSPEC_VCMUL,
> UNSPEC_VCMUL90,
> > UNSPEC_VCMUL180, UNSPEC_VCMUL270.
> > (VCMUL): New.
> > * config/arm/mve.md (mve_vcmulq_f mve_vcmulq_rot180_f,
> > mve_vcmulq_rot270_f, mve_vcmulq_rot90_f,
> mve_vcmlaq_f,
> > mve_vcmlaq_rot180_f, mve_vcmlaq_rot270_f,
> > mve_vcmlaq_rot90_f): Removed.
> > (mve_vcmlaq, mve_vcmulq,
> > mve_vcaddq, cadd3,
> mve_vcaddq):
> > New.
> > * config/arm/unspecs.md (UNSPEC_VCMUL90, UNSPEC_VCMUL270,
> UNSPEC_VCMUL,
> > UNSPEC_VCMUL180): New.
> > (VCMULQ_F, VCMULQ_ROT180_F, VCMULQ_ROT270_F,
> VCMULQ_ROT90_F,
> > VCMLAQ_F, VCMLAQ_ROT180_F, VCMLAQ_ROT90_F,
> VCMLAQ_ROT270_F): Removed.
> >
> > --- inline copy of patch --
> > diff --git a/gcc/config/arm/arm_mve.h b/gcc/config/arm/arm_mve.h index
> >
> 987495dd234ad96ba1163a1f482fe183a46ff437..45014621f2533497e90ddf5257
> fb
> > 04e1fd9325b4 100644
> > --- a/gcc/config/arm/arm_mve.h
> > +++ b/gcc/config/arm/arm_mve.h
> > @@ -17348,28 +17348,28 @@ __extension__ extern __inline float16x8_t
> > __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
> >  __arm_vcmulq_rot90_f16 (float16x8_t __a, float16x8_t __b)  {
> > -  return __builtin_mve_vcmulq_rot90_fv8hf (__a, __b);
> > +  return __builtin_mve_vcmulq_rot90v8hf (__a, __b);
> >  }
> >
> >  __extension__ extern __inline float16x8_t  __attribute__
> > ((__always_inline__, __gnu_inline__, __artificial__))
> >  __arm_vcmulq_rot270_f16 (float16x8_t __a, float16x8_t __b)  {
> > -  return __builtin_mve_vcmulq_rot270_fv8hf (__a, __b);
> > +  return __builtin_mve_vcmulq_rot270v8hf (__a, __b);
> >  }
> >
> >  __extension__ extern __inline float16x8_t  __attribute__
> > ((__always_inline__, __gnu_inline__, __artificial__))
> >  __arm_vcmulq_rot180_f16 (float16

Re: [PATCH 3/4] libstdc++: Add floating-point std::to_chars implementation

[Jonathan Wakely via Gcc-patches]

I think we can test for it with #ifdef and just provide an incorrectly
rounded result for newlib.

Re: [PATCH 3/4] libstdc++: Add floating-point std::to_chars implementation

[Patrick Palka via Gcc-patches]

On Fri, 18 Dec 2020, Christophe Lyon wrote:

> Hi,
> 
> 
> On Fri, 18 Dec 2020 at 05:13, Patrick Palka via Gcc-patches
>  wrote:
> >
> > On Thu, Dec 17, 2020 at 9:32 AM Jonathan Wakely  wrote:
> > >
> > > On 19/08/20 17:57 -0400, Patrick Palka via Libstdc++ wrote:
> > > >On Wed, 22 Jul 2020, Patrick Palka wrote:
> > > >
> > > >> On Mon, 20 Jul 2020, Patrick Palka wrote:
> > > >>
> > > >> > On Mon, 20 Jul 2020, Jonathan Wakely wrote:
> > > >> >
> > > >> > > On 20/07/20 08:53 -0400, Patrick Palka via Libstdc++ wrote:
> > > >> > > > On Mon, 20 Jul 2020, Jonathan Wakely wrote:
> > > >> > > >
> > > >> > > > > On 19/07/20 23:37 -0400, Patrick Palka via Libstdc++ wrote:
> > > >> > > > > > On Fri, 17 Jul 2020, Patrick Palka wrote:
> > > >> > > > > >
> > > >> > > > > > > On Fri, 17 Jul 2020, Patrick Palka wrote:
> > > >> > > > > > >
> > > >> > > > > > > > On Wed, 15 Jul 2020, Patrick Palka wrote:
> > > >> > > > > > > >
> > > >> > > > > > > > > On Tue, 14 Jul 2020, Patrick Palka wrote:
> > > >> > > > > > > > >
> > > >> > > > > > > > > > This implements the floating-point std::to_chars 
> > > >> > > > > > > > > > overloads for
> > > >> > > > > > > float,
> > > >> > > > > > > > > > double and long double.  We use the Ryu library to 
> > > >> > > > > > > > > > compute the
> > > >> > > > > > > shortest
> > > >> > > > > > > > > > round-trippable fixed and scientific forms of a 
> > > >> > > > > > > > > > number for
> > > >> > > > > float,
> > > >> > > > > > > double
> > > >> > > > > > > > > > and long double.  We also use Ryu for performing 
> > > >> > > > > > > > > > fixed and
> > > >> > > > > > > scientific
> > > >> > > > > > > > > > formatting of float and double. For formatting long 
> > > >> > > > > > > > > > double with
> > > >> > > > > an
> > > >> > > > > > > > > > explicit precision argument we use a printf fallback.
> > > >> > > > > Hexadecimal
> > > >> > > > > > > > > > formatting for float, double and long double is 
> > > >> > > > > > > > > > implemented from
> > > >> > > > > > > > > > scratch.
> > > >> > > > > > > > > >
> > > >> > > > > > > > > > The supported long double binary formats are float64 
> > > >> > > > > > > > > > (same as
> > > >> > > > > > > double),
> > > >> > > > > > > > > > float80 (x86 extended precision), float128 and 
> > > >> > > > > > > > > > ibm128.
> > > >> > > > > > > > > >
> > > >> > > > > > > > > > Much of the complexity of the implementation is in 
> > > >> > > > > > > > > > computing the
> > > >> > > > > > > exact
> > > >> > > > > > > > > > output length before handing it off to Ryu (which 
> > > >> > > > > > > > > > doesn't do
> > > >> > > > > bounds
> > > >> > > > > > > > > > checking).  In some cases it's hard to compute the 
> > > >> > > > > > > > > > output length
> > > >> > > > > > > before
> > > >> > > > > > > > > > the fact, so in these cases we instead compute an 
> > > >> > > > > > > > > > upper bound on
> > > >> > > > > the
> > > >> > > > > > > > > > output length and use a sufficiently-sized 
> > > >> > > > > > > > > > intermediate buffer
> > > >> > > > > (if
> > > >> > > > > > > the
> > > >> > > > > > > > > > output range is smaller than the upper bound).
> > > >> > > > > > > > > >
> > > >> > > > > > > > > > Another source of complexity is in the 
> > > >> > > > > > > > > > general-with-precision
> > > >> > > > > > > formatting
> > > >> > > > > > > > > > mode, where we need to do zero-trimming of the 
> > > >> > > > > > > > > > string returned
> > > >> > > > > by
> > > >> > > > > > > Ryu, and
> > > >> > > > > > > > > > where we also take care to avoid having to format 
> > > >> > > > > > > > > > the string a
> > > >> > > > > > > second
> > > >> > > > > > > > > > time when the general formatting mode resolves to 
> > > >> > > > > > > > > > fixed.
> > > >> > > > > > > > > >
> > > >> > > > > > > > > > Tested on x86_64-pc-linux-gnu, 
> > > >> > > > > > > > > > aarch64-unknown-linux-gnu,
> > > >> > > > > > > > > > s390x-ibm-linux-gnu, and powerpc64-unknown-linux-gnu.
> > > >> > > > > > > > > >
> > > >> > > > > > > > > > libstdc++-v3/ChangeLog:
> > > >> > > > > > > > > >
> > > >> > > > > > > > > >* acinclude.m4 (libtool_VERSION): Bump to 6:29:0.
> > > >> > > > > > > > > >* config/abi/pre/gnu.ver: Add new exports.
> > > >> > > > > > > > > >* configure: Regenerate.
> > > >> > > > > > > > > >* include/std/charconv (to_chars): Declare the 
> > > >> > > > > > > > > > floating-point
> > > >> > > > > > > > > >overloads for float, double and long double.
> > > >> > > > > > > > > >* src/c++17/Makefile.am (sources): Add 
> > > >> > > > > > > > > > floating_to_chars.cc.
> > > >> > > > > > > > > >* src/c++17/Makefile.in: Regenerate.
> > > >> > > > > > > > > >* src/c++17/floating_to_chars.cc: New file.
> > > >> > > > > > > > > >* testsuite/20_util/to_chars/long_double.cc: New 
> > > >> > > > > > > > > > test.
> > > >> > > > > > > > > >* testsuite/util/testsuite_abi.cc: Add new symbol 
> > > >> > > > > > > > > > version.
> > > >> > > > > > > > >
>

Re: [PATCH] openmp: Implicit 'declare target' for C++ static initializers

[Kwok Cheung Yeung]

On 08/12/2020 4:24 pm, Jakub Jelinek wrote:

The GCC coding style (appart from libstdc++) is type * rather than type*,
occurs several times in the patch.


Fixed.


+{
+  tree node;
+
+  if (DECL_INITIAL (decl))
+return &DECL_INITIAL (decl);
+
+  for (node = dynamic_initializers; node; node = TREE_CHAIN (node))
+if (TREE_VALUE (node) == decl)
+  return &TREE_PURPOSE (node);


I'm worried with many dynamic initializers this will be worst case
quadratic.  Can't you use instead a hash map?  Note, as this is in the
FE, we might need to worry about PCH and GC.
Thus the hash map needs to be indexed by DECL_UIDs rather than pointers,
so perhaps use decl_tree_map?
Also, I'm worried that nothing releases dynamic_initializers (or the
decl_tree_map replacement).  We need it only during the discovery and not
afterwards, so it would be nice if the omp declare target discovery at the
end called another lang hook that would free the decl_tree_map, so that GC
can take it all.
If trees would remain there afterwards, we'd need to worry about destructive
gimplifier too and would need to unshare the dynamic initializers or
something.

I think it would be best to use omp_ in the hook name(s), and:


I have now changed dynamic_initializers to use a decl_tree_map instead. 
get_decl_init has been renamed to omp_get_decl_init, and I have added a hook 
omp_finish_decl_inits which is called at the end of 
omp_discover_implicit_declare_target to free the decl_tree_map for GC.



--- a/gcc/cp/decl2.c
+++ b/gcc/cp/decl2.c
@@ -4940,6 +4940,11 @@ c_parse_final_cleanups (void)
 loop.  */
vars = prune_vars_needing_no_initialization (&static_aggregates);
  
+  /* Copy the contents of VARS into DYNAMIC_INITIALIZERS.  */

+  for (t = vars; t; t = TREE_CHAIN (t))
+   dynamic_initializers = tree_cons (TREE_PURPOSE (t), TREE_VALUE (t),
+ dynamic_initializers);


Not to add there anything if (!flag_openmp).  We don't need to waste memory
when nobody is going to look at it.


Done.

I have retested all the gomp tests in the main testsuite, retested libgomp, and 
checked bootstrapping. Is this version okay for trunk now?


Thanks

Kwok
From ef4a42c5174372dd0d72dc0efe2c608e693c7877 Mon Sep 17 00:00:00 2001
From: Kwok Cheung Yeung 
Date: Thu, 17 Dec 2020 12:10:18 -0800
Subject: [PATCH] openmp: Implicitly add 'declare target' directives for
 dynamic initializers in C++

2020-12-17  Kwok Cheung Yeung  

gcc/
* langhooks-def.h (lhd_get_decl_init): New.
(lhd_finish_decl_inits): New.
(LANG_HOOKS_GET_DECL_INIT): New.
(LANG_HOOKS_OMP_FINISH_DECL_INITS): New.
(LANG_HOOKS_DECLS): Add LANG_HOOKS_GET_DECL_INIT and
LANG_HOOKS_OMP_FINISH_DECL_INITS.
* langhooks.c (lhd_omp_get_decl_init): New.
(lhd_omp_finish_decl_inits): New.
* langhooks.h (struct lang_hooks_for_decls): Add omp_get_decl_init
and omp_finish_decl_inits.
* omp-offload.c (omp_discover_declare_target_var_r): Use
get_decl_init langhook in place of DECL_INITIAL.  Call
omp_finish_decl_inits langhook at end of function.

gcc/cp/
* cp-lang.c (cxx_get_decl_init): New.
(cxx_omp_finish_decl_inits): New.
(LANG_HOOKS_GET_DECL_INIT): New.
(LANG_HOOKS_OMP_FINISH_DECL_INITS): New.
* cp-tree.h (dynamic_initializers): New.
* decl.c (dynamic_initializers): New.
* decl2.c (c_parse_final_cleanups): Add initializer entries
from vars to dynamic_initializers.

gcc/testsuite/
* g++.dg/gomp/declare-target-3.C: New.
---
 gcc/cp/cp-lang.c | 32 
 gcc/cp/cp-tree.h |  4 
 gcc/cp/decl.c|  4 
 gcc/cp/decl2.c   |  7 ++
 gcc/langhooks-def.h  |  8 ++-
 gcc/langhooks.c  | 16 ++
 gcc/langhooks.h  | 10 +
 gcc/omp-offload.c| 11 ++
 gcc/testsuite/g++.dg/gomp/declare-target-3.C | 31 +++
 9 files changed, 118 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/gomp/declare-target-3.C

diff --git a/gcc/cp/cp-lang.c b/gcc/cp/cp-lang.c
index 5d2aef4..bde11db 100644
--- a/gcc/cp/cp-lang.c
+++ b/gcc/cp/cp-lang.c
@@ -34,6 +34,8 @@ static tree cp_eh_personality (void);
 static tree get_template_innermost_arguments_folded (const_tree);
 static tree get_template_argument_pack_elems_folded (const_tree);
 static tree cxx_enum_underlying_base_type (const_tree);
+static tree * cxx_omp_get_decl_init (tree);
+static void cxx_omp_finish_decl_inits (void);
 
 /* Lang hooks common to C++ and ObjC++ are declared in cp/cp-objcp-common.h;
consequently, there should be very few hooks below.  */
@@ -92,6 +94,12 @@ static tree cxx_enum_underlying_base_

Re: [PATCH] Add simd testsuite

[Matthias Kretz]

On Donnerstag, 17. Dezember 2020 14:10:51 CET Jonathan Wakely wrote:
> On 16/12/20 12:58 +0100, Matthias Kretz wrote:
> >+  $srcdir/testsuite/experimental/simd/generate_makefile.sh \
> >+--destination="$testdir/$subdir" $CXX $INCLUDES $CXXFLAGS -static
> 
> Is the -static here to avoid needing LD_LIBRARY_PATH to find
> libstdc++.so?
> 
> If you don't have libc.a installed it won't work. How about
> using -static-libgcc -static-libstdc++ instead?

I need the -static for qemu and simple remote execution (copy binary via scp, 
execute via ssh). And yes, -static makes it much easier to avoid the 
LD_LIBRARY_PATH issue.

I'll make -static optional, and default to -static-libgcc -static-libstdc++. 
The latter should still work for most remote execution setups (works for me, 
at least).

> >--- /dev/null
> >+++ b/libstdc++-v3/testsuite/experimental/simd/tests/abs.cc
> >@@ -0,0 +1,24 @@
> >+#include "bits/verify.h"
> >+#include "bits/metahelpers.h"
> 
> We'd usually put these testsuite helper files in testsuite/util, maybe
> in a testsuite/util/simd sub-dir, but I suppose keeping them local to
> the tests is OK too.

At this point the simd testsuite is very close to being usable for other 
Parallelism TS 2 implementations. That's a feature I'd support if there's 
interest outside of libstdc++.

> >--- /dev/null
> >+++ b/libstdc++-v3/testsuite/experimental/simd/tests/bits/conversions.h
> >@@ -0,0 +1,167 @@
> >+#include 
> >+
> >+// is_conversion_undefined
> >+/* implementation-defined
> >+ * ==
> >+ * §4.7 p3 (integral conversions)
> 
> These section signs will cause errors if the testsuite is run with
> something like -finput-charset=ascii, but I suppose we can say "don't
> do that". We have tests that use that option and include all the
> libstdc++ headers, so there should be no need to run the entire
> testsuite with that option. So it's OK.

Ah, but good point. I have comments in simd_math.h (i.e. the other patch) 
like: "Fold @p x into [-¼π, ¼π] and [...]". These comments are not in the 
testsuite. I guess I need to replace all non-ASCII chars there?

Attached is the diff to the previous patch. In addition to the -static change 
I added license headers (as noted on IRC) and I improved the Makefile 
generator: Instead of only passing TESTFLAGS and GCC_TEST_SIMULATOR as 
environment variables, place the initial values into the generated Makefile. 
This makes it much easier to work on tests or fixes for failures.

I'll top-post the squashed simd patches. 

-- 
──
 Dr. Matthias Kretz   https://mattkretz.github.io
 GSI Helmholtz Centre for Heavy Ion Research   https://gsi.de
 std::experimental::simd  https://github.com/VcDevel/std-simd
──
diff --git a/libstdc++-v3/scripts/check_simd b/libstdc++-v3/scripts/check_simd
index 2b7a17a64c9..25acf64c841 100755
--- a/libstdc++-v3/scripts/check_simd
+++ b/libstdc++-v3/scripts/check_simd
@@ -26,7 +26,7 @@ sim=\\\"$sim\\\"\""
 
 if [ -f "$CHECK_SIMD_CONFIG" ]; then
   . "$CHECK_SIMD_CONFIG"
-elif [ -z "$CHECK_SIMD_CONFIG"]; then
+elif [ -z "$CHECK_SIMD_CONFIG" ]; then
   if [ -z "$target_list" ]; then
 target_list="unix"
 case "$target_triplet" in
@@ -69,8 +69,7 @@ while [ ${#list} -gt 0 ]; do
   subdir="simd/$(echo "$flags" | sed 's#[= /-]##g')"
   rm -f "${subdir}/Makefile"
   $srcdir/testsuite/experimental/simd/generate_makefile.sh \
---destination="$testdir/$subdir" $CXX $INCLUDES $CXXFLAGS -static
-  echo "$subdir
-$flags
-$sim"
+--destination="$testdir/$subdir" --sim="$sim" --testflags="$flags" \
+$CXX $INCLUDES $CXXFLAGS -static-libgcc -static-libstdc++
+  echo "$subdir"
 done
diff --git a/libstdc++-v3/testsuite/Makefile.am b/libstdc++-v3/testsuite/Makefile.am
index d2e282b62b9..fa9cc4753f3 100644
--- a/libstdc++-v3/testsuite/Makefile.am
+++ b/libstdc++-v3/testsuite/Makefile.am
@@ -192,9 +192,10 @@ check-simd: $(srcdir)/experimental/simd/generate_makefile.sh \
 	testsuite_files_simd \
 	${glibcxx_builddir}/scripts/testsuite_flags
 	${glibcxx_srcdir}/scripts/check_simd "${glibcxx_srcdir}" "${glibcxx_builddir}" "$(CXXFLAGS)" | \
-	  while read subdir && read flags && read sim; do \
-	$(MAKE) -C "$${subdir}" TESTFLAGS="$${flags}" GCC_TEST_SIMULATOR="$${sim}"; \
-	tail -n6 $${subdir}/simd_testsuite.sum >> .simd.summary; \
+	  while read subdir; do \
+	$(MAKE) -C "$${subdir}"; \
+	tail -n20 $${subdir}/simd_testsuite.sum | \
+	  grep -A20 -B1 'Summary ===' >> .simd.summary; \
 	  done; \
 	  cat .simd.summary && rm .simd.summary
 
diff --git a/libstdc++-v3/testsuite/Makefile.in b/libstdc++-v3/testsuite/Makefile.in
index 08b8fc05fa5..fadc93e027c 100644
--- a/libstdc++-v3/testsuite/Makefile.in
+++ b/libstdc++-v3/testsuite/Makefile.in
@@ -707,14 +707,16 @@ check-performance: testsuite_files_performance ${performance_s

c++: Fix windows binary files [PR 98362]

[Nathan Sidwell]

Windows has unique and special needs for open(2).

gcc/cp/
* module.cc (O_CLOEXEC, O_BINARY): Add window's support.
(elf_in::defrost, module_state::do_import)
(finish_module_processing): Use O_BINARY.

--
Nathan Sidwell
diff --git i/gcc/cp/module.cc w/gcc/cp/module.cc
index b2b81900fc3..fc918d296a2 100644
--- i/gcc/cp/module.cc
+++ w/gcc/cp/module.cc
@@ -252,9 +252,23 @@ Classes used:
 #endif
 #endif
 
-#if !HOST_HAS_O_CLOEXEC
+/* Some open(2) flag differences, what a colourful world it is!  */
+#if defined (O_CLOEXEC)
+// OK
+#elif defined (_O_NOINHERIT)
+/* Windows' _O_NOINHERIT matches O_CLOEXEC flag */
+#define O_CLOEXEC _O_NOINHERIT
+#else
 #define O_CLOEXEC 0
 #endif
+#if defined (O_BINARY)
+// Ok?
+#elif defined (_O_BINARY)
+/* Windows' open(2) call defaults to text!  */
+#define O_BINARY _O_BINARY
+#else
+#define O_BINARY 0
+#endif
 
 static inline cpp_hashnode *cpp_node (tree id)
 {
@@ -1596,7 +1610,7 @@ elf_in::defrost (const char *name)
   gcc_checking_assert (is_frozen ());
   struct stat stat;
 
-  fd = open (name, O_RDONLY | O_CLOEXEC);
+  fd = open (name, O_RDONLY | O_CLOEXEC | O_BINARY);
   if (fd < 0 || fstat (fd, &stat) < 0)
 set_error (errno);
   else
@@ -18568,7 +18582,7 @@ module_state::do_import (cpp_reader *reader, bool outermost)
 {
   const char *file = maybe_add_cmi_prefix (filename);
   dump () && dump ("CMI is %s", file);
-  fd = open (file, O_RDONLY | O_CLOEXEC);
+  fd = open (file, O_RDONLY | O_CLOEXEC | O_BINARY);
   e = errno;
 }
 
@@ -19704,7 +19718,8 @@ finish_module_processing (cpp_reader *reader)
 	  if (!errorcount)
 	for (unsigned again = 2; ; again--)
 	  {
-		fd = open (tmp_name, O_RDWR | O_CREAT | O_TRUNC | O_CLOEXEC,
+		fd = open (tmp_name,
+			   O_RDWR | O_CREAT | O_TRUNC | O_CLOEXEC | O_BINARY,
 			   S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH);
 		e = errno;
 		if (fd >= 0 || !again || e != ENOENT)

Re: [PATCH] openmp: Implicit 'declare target' for C++ static initializers

[Jakub Jelinek via Gcc-patches]

On Fri, Dec 18, 2020 at 03:10:52PM +, Kwok Cheung Yeung wrote:
> --- a/gcc/cp/cp-lang.c
> +++ b/gcc/cp/cp-lang.c
> @@ -34,6 +34,8 @@ static tree cp_eh_personality (void);
>  static tree get_template_innermost_arguments_folded (const_tree);
>  static tree get_template_argument_pack_elems_folded (const_tree);
>  static tree cxx_enum_underlying_base_type (const_tree);
> +static tree * cxx_omp_get_decl_init (tree);

No space between * and cxx_omp_get_decl_init here.

> +extern tree * lhd_omp_get_decl_init (tree);

Ditto.

> +  /* Return a pointer to the tree representing the initializer
> + expression for the non-local variable DECL.  Return NULL if
> + DECL is not initialized.  */
> +  tree * (*omp_get_decl_init) (tree decl);

Ditto.

Ok for trunk with those nits fixed.

Thanks!

Jakub

[PATCH] DWARF: fix debug info for offload kernels

[Andrew Stubbs]

This patch adjusts the DWARF emitted for OpenACC/OpenMP offload kernels 
such that the AMD rocgdb debugger can display the contents of variables 
within kernel code.


The problem was that GDB was discarding the kernel functions' debug info 
because it is represented as a nested function inside the host function, 
but in the offload binary the host function had only partial DWARF 
information.


By adding a code address to the parent function, in the offload binary, 
GDB works correctly. This patch simply duplicates the code range from 
the first kernel, to ensure that the addresses are valid, but the actual 
range doesn't matter because GDB will always choose the innermost 
function with that range.


This change should not affect the DWARF of the host binary at all (even 
though it has the same nested structure) because there the parent 
function has a full definition.


I'm not completely confident what the most correct pattern match should 
be for this issue, but the patch appear to DTRT in the cases I have 
observed.


OK to commit?

Andrew
Fix offload dwarf info

GCC represents offload kernels, in DWARF, as nested subprograms within a bare
representation of the host side function subprogram.  Unfortunately GDB then
disregards that, along with all the nested DIEs, because it has no address
range.

This function adds a notional address range to the parent subprogram, and
thus enables debug of offload kernels.

This change does not affect the DWARF for the host-program's representation of
the same function.

gcc/ChangeLog:

	* dwarf2out.c (gen_subprogram_die): Add PC address range for parents
	of offload kernels.

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 0baa056447c..bee40972950 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -23150,6 +23150,22 @@ gen_subprogram_die (tree decl, dw_die_ref context_die)
 	  /* We have already generated the labels.  */
  add_AT_low_high_pc (subr_die, fde->dw_fde_begin,
  fde->dw_fde_end, false);
+
+	 /* Offload kernel functions are nested within a parent function
+	that doesn't actually exist within the offload object.  GDB
+		will ignore the function and everything nested within unless
+		we give it a notional code range (the values aren't
+		important, as long as they are valid).
+		There's no specific marker for these(?), but they will be
+		artificial declarations with an abstract origin, and the
+		parent won't have many existing attributes.  */
+	 if (DECL_ARTIFICIAL (decl)
+		 && subr_die->die_parent
+		 && subr_die->die_parent->die_tag == DW_TAG_subprogram
+		 && get_AT_ref (subr_die->die_parent, DW_AT_abstract_origin)
+		 && !get_AT_low_pc (subr_die->die_parent))
+	   add_AT_low_high_pc (subr_die->die_parent, fde->dw_fde_begin,
+   fde->dw_fde_end, false);
 	}
 	  else
 	{

[PATCH] libstdc++: Fix build failure due to missing [PR98374]

[Patrick Palka via Gcc-patches]

This fixes a build failure on Windows which lacks .
(We can't use the more portable localeconv() from  to obtain
the radix character of the current locale here because it's not
thread-safe, unfortunately.)

This change means that on Windows and other such systems, we'll just
always assume the radix character used by printf is '.' when formatting
a long double through it.

libstdc++-v3/ChangeLog:

PR libstdc++/98374
* src/c++17/floating_to_chars.cc: Guard include of 
with __has_include.
(__floating_to_chars_precision) [!defined(RADIXCHAR)]: Don't
attempt to obtain the radix character of the current locale,
just assume it's '.'.
---
 libstdc++-v3/src/c++17/floating_to_chars.cc | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/libstdc++-v3/src/c++17/floating_to_chars.cc 
b/libstdc++-v3/src/c++17/floating_to_chars.cc
index 474e791e717..6470fbb0b95 100644
--- a/libstdc++-v3/src/c++17/floating_to_chars.cc
+++ b/libstdc++-v3/src/c++17/floating_to_chars.cc
@@ -33,7 +33,9 @@
 #include 
 #include 
 #include 
-#include 
+#if __has_include()
+# include  // for nl_langinfo
+#endif
 #include 
 #include 
 #include 
@@ -1113,6 +1115,7 @@ template
// to handle a radix point that's different from '.'.
char radix[6] = {'.', '\0', '\0', '\0', '\0', '\0'};
if (effective_precision > 0)
+#ifdef RADIXCHAR
  // ???: Can nl_langinfo() ever return null?
  if (const char* const radix_ptr = nl_langinfo(RADIXCHAR))
{
@@ -1121,6 +1124,7 @@ template
  // UTF-8 character) wide.
  __glibcxx_assert(radix[4] == '\0');
}
+#endif
 
// Compute straightforward upper bounds on the output length.
int output_length_upper_bound;
-- 
2.30.0.rc0

[PATCH]Arm MVE: Add missing complex mul iterators

[Tamar Christina via Gcc-patches]

Hi All,

Seems when I split the patch I forgot to include these into the rot iterator..
The uncommitted hunks were still in my local tree so didn't notice.

Tested for -march=armv8.1-m.main+mve.fp -mfloat-abi=hard -mfpu=auto
and no issues.

Ok for master?

Thanks,
Tamar

gcc/ChangeLog:

* config/arm/iterators.md (rot): Add UNSPEC_VCMUL, UNSPEC_VCMUL90,
UNSPEC_VCMUL180, UNSPEC_VCMUL270

--- inline copy of patch -- 
diff --git a/gcc/config/arm/iterators.md b/gcc/config/arm/iterators.md
index 
c6b1b28c896f9fb3081021ea4efcae8abaaceb55..ecbc6727312313c6c354b1a0b92c8369912354c6
 100644
--- a/gcc/config/arm/iterators.md
+++ b/gcc/config/arm/iterators.md
@@ -1177,6 +1177,10 @@ (define_int_attr crypto_mode [(UNSPEC_SHA1H "V4SI") 
(UNSPEC_AESMC "V16QI")
 
 (define_int_attr rot [(UNSPEC_VCADD90 "90")
  (UNSPEC_VCADD270 "270")
+ (UNSPEC_VCMUL "0")
+ (UNSPEC_VCMUL90 "90")
+ (UNSPEC_VCMUL180 "180")
+ (UNSPEC_VCMUL270 "270")
  (UNSPEC_VCMLA "0")
  (UNSPEC_VCMLA90 "90")
  (UNSPEC_VCMLA180 "180")


-- 
diff --git a/gcc/config/arm/iterators.md b/gcc/config/arm/iterators.md
index c6b1b28c896f9fb3081021ea4efcae8abaaceb55..ecbc6727312313c6c354b1a0b92c8369912354c6 100644
--- a/gcc/config/arm/iterators.md
+++ b/gcc/config/arm/iterators.md
@@ -1177,6 +1177,10 @@ (define_int_attr crypto_mode [(UNSPEC_SHA1H "V4SI") (UNSPEC_AESMC "V16QI")
 
 (define_int_attr rot [(UNSPEC_VCADD90 "90")
 		  (UNSPEC_VCADD270 "270")
+		  (UNSPEC_VCMUL "0")
+		  (UNSPEC_VCMUL90 "90")
+		  (UNSPEC_VCMUL180 "180")
+		  (UNSPEC_VCMUL270 "270")
 		  (UNSPEC_VCMLA "0")
 		  (UNSPEC_VCMLA90 "90")
 		  (UNSPEC_VCMLA180 "180")

RE: [PATCH]Arm MVE: Add missing complex mul iterators

[Kyrylo Tkachov via Gcc-patches]

> -Original Message-
> From: Tamar Christina 
> Sent: 18 December 2020 16:09
> To: gcc-patches@gcc.gnu.org
> Cc: nd ; Ramana Radhakrishnan
> ; Richard Earnshaw
> ; ni...@redhat.com; Kyrylo Tkachov
> 
> Subject: [PATCH]Arm MVE: Add missing complex mul iterators
> 
> Hi All,
> 
> Seems when I split the patch I forgot to include these into the rot iterator..
> The uncommitted hunks were still in my local tree so didn't notice.
> 
> Tested for -march=armv8.1-m.main+mve.fp -mfloat-abi=hard -mfpu=auto
> and no issues.
> 
> Ok for master?

Ok.
Thanks,
Kyrill

> 
> Thanks,
> Tamar
> 
> gcc/ChangeLog:
> 
>   * config/arm/iterators.md (rot): Add UNSPEC_VCMUL,
> UNSPEC_VCMUL90,
>   UNSPEC_VCMUL180, UNSPEC_VCMUL270
> 
> --- inline copy of patch --
> diff --git a/gcc/config/arm/iterators.md b/gcc/config/arm/iterators.md
> index
> c6b1b28c896f9fb3081021ea4efcae8abaaceb55..ecbc6727312313c6c354b1a
> 0b92c8369912354c6 100644
> --- a/gcc/config/arm/iterators.md
> +++ b/gcc/config/arm/iterators.md
> @@ -1177,6 +1177,10 @@ (define_int_attr crypto_mode [(UNSPEC_SHA1H
> "V4SI") (UNSPEC_AESMC "V16QI")
> 
>  (define_int_attr rot [(UNSPEC_VCADD90 "90")
> (UNSPEC_VCADD270 "270")
> +   (UNSPEC_VCMUL "0")
> +   (UNSPEC_VCMUL90 "90")
> +   (UNSPEC_VCMUL180 "180")
> +   (UNSPEC_VCMUL270 "270")
> (UNSPEC_VCMLA "0")
> (UNSPEC_VCMLA90 "90")
> (UNSPEC_VCMLA180 "180")
> 
> 
> --

RE: [PATCH][AArch32] MVE: Split refactoring of remaining complex instrinsics

[Tamar Christina via Gcc-patches]

Hi Christoph,

> -Original Message-
> From: Christophe Lyon 
> Sent: Friday, December 18, 2020 2:22 PM
> To: Tamar Christina 
> Cc: gcc Patches ; Richard Earnshaw
> ; nd ; Ramana Radhakrishnan
> 
> Subject: Re: [PATCH][AArch32] MVE: Split refactoring of remaining complex
> instrinsics
> 
> On Wed, 16 Dec 2020 at 21:43, Tamar Christina via Gcc-patches  patc...@gcc.gnu.org> wrote:
> >
> > Hi All,
> >
> > This refactors the complex numbers bits of MVE to go through the same
> > unspecs as the NEON variant.
> >
> > This is pre-work to allow code to be shared between NEON and MVE for
> > the complex vectorization patches.
> >
> > Bootstrapped Regtested on arm-none-linux-gnueabihf and no issues.
> > Codegen tested for -march=armv8.1-m.main+mve.fp -mfloat-abi=hard
> > -mfpu=auto and no issues.
> >
> 
> Hi Tamar,
> 
> This patch causes regressions for me:
> gcc.target/arm/mve/intrinsics/vcmulq_f16.c (test for excess errors)
> gcc.target/arm/mve/intrinsics/vcmulq_f32.c (test for excess errors)
> gcc.target/arm/mve/intrinsics/vcmulq_rot180_f16.c (test for excess errors)
> gcc.target/arm/mve/intrinsics/vcmulq_rot180_f32.c (test for excess errors)
> gcc.target/arm/mve/intrinsics/vcmulq_rot270_f16.c (test for excess errors)
> gcc.target/arm/mve/intrinsics/vcmulq_rot270_f32.c (test for excess errors)
> gcc.target/arm/mve/intrinsics/vcmulq_rot90_f16.c (test for excess errors)
> gcc.target/arm/mve/intrinsics/vcmulq_rot90_f32.c (test for excess errors)
> 
> I can see:
> FAIL: gcc.target/arm/mve/intrinsics/vcmulq_f16.c (test for excess errors)
> Excess errors:
> vcmulq_f16.s:40: Warning: missing operand; zero assumed
> vcmulq_f16.s:61: Warning: missing operand; zero assumed
> 
> I didn't check the code manually yet, and I am using binutils-2.34:
> has something
> related to this changed in more recent gas?

No, A hunk didn't get committed.  This should be fixed now.

Thanks,
Tamar

> 
> Thanks
> 
> Christophe
> 
> > This is just a splitting of a previously approved patch due to it
> > having a dependency on the AArch64 bits which have been requested to
> be reworked.
> >
> > Will commit under the previous approval.
> >
> > Thanks,
> > Tamar
> >
> > gcc/ChangeLog:
> >
> > * config/arm/arm_mve.h (__arm_vcmulq_rot90_f16):
> > (__arm_vcmulq_rot270_f16, _arm_vcmulq_rot180_f16,
> __arm_vcmulq_f16,
> > __arm_vcmulq_rot90_f32, __arm_vcmulq_rot270_f32,
> > __arm_vcmulq_rot180_f32, __arm_vcmulq_f32, __arm_vcmlaq_f16,
> > __arm_vcmlaq_rot180_f16, __arm_vcmlaq_rot270_f16,
> > __arm_vcmlaq_rot90_f16, __arm_vcmlaq_f32,
> __arm_vcmlaq_rot180_f32,
> > __arm_vcmlaq_rot270_f32, __arm_vcmlaq_rot90_f32): Update builtin
> calls.
> > * config/arm/arm_mve_builtins.def (vcmulq_f, vcmulq_rot90_f,
> > vcmulq_rot180_f, vcmulq_rot270_f, vcmlaq_f, vcmlaq_rot90_f,
> > vcmlaq_rot180_f, vcmlaq_rot270_f): Removed.
> > (vcmulq, vcmulq_rot90, vcmulq_rot180, vcmulq_rot270, vcmlaq,
> > vcmlaq_rot90, vcmlaq_rot180, vcmlaq_rot270): New.
> > * config/arm/iterators.md (mve_rot): Add UNSPEC_VCMLA,
> UNSPEC_VCMLA90,
> > UNSPEC_VCMLA180, UNSPEC_VCMLA270, UNSPEC_VCMUL,
> UNSPEC_VCMUL90,
> > UNSPEC_VCMUL180, UNSPEC_VCMUL270.
> > (VCMUL): New.
> > * config/arm/mve.md (mve_vcmulq_f mve_vcmulq_rot180_f,
> > mve_vcmulq_rot270_f, mve_vcmulq_rot90_f,
> mve_vcmlaq_f,
> > mve_vcmlaq_rot180_f, mve_vcmlaq_rot270_f,
> > mve_vcmlaq_rot90_f): Removed.
> > (mve_vcmlaq, mve_vcmulq,
> > mve_vcaddq, cadd3,
> mve_vcaddq):
> > New.
> > * config/arm/unspecs.md (UNSPEC_VCMUL90, UNSPEC_VCMUL270,
> UNSPEC_VCMUL,
> > UNSPEC_VCMUL180): New.
> > (VCMULQ_F, VCMULQ_ROT180_F, VCMULQ_ROT270_F,
> VCMULQ_ROT90_F,
> > VCMLAQ_F, VCMLAQ_ROT180_F, VCMLAQ_ROT90_F,
> VCMLAQ_ROT270_F): Removed.
> >
> > --- inline copy of patch --
> > diff --git a/gcc/config/arm/arm_mve.h b/gcc/config/arm/arm_mve.h index
> >
> 987495dd234ad96ba1163a1f482fe183a46ff437..45014621f2533497e90ddf5257
> fb
> > 04e1fd9325b4 100644
> > --- a/gcc/config/arm/arm_mve.h
> > +++ b/gcc/config/arm/arm_mve.h
> > @@ -17348,28 +17348,28 @@ __extension__ extern __inline float16x8_t
> > __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
> >  __arm_vcmulq_rot90_f16 (float16x8_t __a, float16x8_t __b)  {
> > -  return __builtin_mve_vcmulq_rot90_fv8hf (__a, __b);
> > +  return __builtin_mve_vcmulq_rot90v8hf (__a, __b);
> >  }
> >
> >  __extension__ extern __inline float16x8_t  __attribute__
> > ((__always_inline__, __gnu_inline__, __artificial__))
> >  __arm_vcmulq_rot270_f16 (float16x8_t __a, float16x8_t __b)  {
> > -  return __builtin_mve_vcmulq_rot270_fv8hf (__a, __b);
> > +  return __builtin_mve_vcmulq_rot270v8hf (__a, __b);
> >  }
> >
> >  __extension__ extern __inline float16x8_t  __attribute__
> > ((__always_inline__, __gnu_inline__, __artificial__))
> >  __arm_vcmulq_rot180

[PATCH] libstdc++: Fix build failure on AArch64 ILP32 [PR98370]

[Patrick Palka via Gcc-patches]

This should fix a build failure on AArch64 ILP32 due to int32_t mapping
to long int instead of int on this platform, which causes type deduction
to fail in the below call to std::max as reported in the PR.

libstdc++-v3/ChangeLog:

PR libstdc++/98370
* src/c++17/floating_to_chars.cc (__floating_to_chars_shortest):
Provide explicit template arguments to the call to std::max.
---
 libstdc++-v3/src/c++17/floating_to_chars.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libstdc++-v3/src/c++17/floating_to_chars.cc 
b/libstdc++-v3/src/c++17/floating_to_chars.cc
index 6470fbb0b95..3f46bce7a15 100644
--- a/libstdc++-v3/src/c++17/floating_to_chars.cc
+++ b/libstdc++-v3/src/c++17/floating_to_chars.cc
@@ -977,7 +977,7 @@ template
// fd.exponent contain all of the information needed to format the
// number in fixed notation "as if by std::printf" (with precision
// equal to -fd.exponent).
-   const int whole_digits = max(mantissa_length + fd.exponent, 1);
+   const int whole_digits = max(mantissa_length + fd.exponent, 1);
const int expected_output_length
  = fd.sign + whole_digits + strlen(".") + -fd.exponent;
if (last - first < expected_output_length)
-- 
2.30.0.rc0

Re: [PATCH][AArch32] MVE: Split refactoring of remaining complex instrinsics

[Christophe Lyon via Gcc-patches]

On Fri, 18 Dec 2020 at 17:20, Tamar Christina  wrote:
>
> Hi Christoph,
>
> > -Original Message-
> > From: Christophe Lyon 
> > Sent: Friday, December 18, 2020 2:22 PM
> > To: Tamar Christina 
> > Cc: gcc Patches ; Richard Earnshaw
> > ; nd ; Ramana Radhakrishnan
> > 
> > Subject: Re: [PATCH][AArch32] MVE: Split refactoring of remaining complex
> > instrinsics
> >
> > On Wed, 16 Dec 2020 at 21:43, Tamar Christina via Gcc-patches  > patc...@gcc.gnu.org> wrote:
> > >
> > > Hi All,
> > >
> > > This refactors the complex numbers bits of MVE to go through the same
> > > unspecs as the NEON variant.
> > >
> > > This is pre-work to allow code to be shared between NEON and MVE for
> > > the complex vectorization patches.
> > >
> > > Bootstrapped Regtested on arm-none-linux-gnueabihf and no issues.
> > > Codegen tested for -march=armv8.1-m.main+mve.fp -mfloat-abi=hard
> > > -mfpu=auto and no issues.
> > >
> >
> > Hi Tamar,
> >
> > This patch causes regressions for me:
> > gcc.target/arm/mve/intrinsics/vcmulq_f16.c (test for excess errors)
> > gcc.target/arm/mve/intrinsics/vcmulq_f32.c (test for excess errors)
> > gcc.target/arm/mve/intrinsics/vcmulq_rot180_f16.c (test for excess 
> > errors)
> > gcc.target/arm/mve/intrinsics/vcmulq_rot180_f32.c (test for excess 
> > errors)
> > gcc.target/arm/mve/intrinsics/vcmulq_rot270_f16.c (test for excess 
> > errors)
> > gcc.target/arm/mve/intrinsics/vcmulq_rot270_f32.c (test for excess 
> > errors)
> > gcc.target/arm/mve/intrinsics/vcmulq_rot90_f16.c (test for excess 
> > errors)
> > gcc.target/arm/mve/intrinsics/vcmulq_rot90_f32.c (test for excess 
> > errors)
> >
> > I can see:
> > FAIL: gcc.target/arm/mve/intrinsics/vcmulq_f16.c (test for excess errors)
> > Excess errors:
> > vcmulq_f16.s:40: Warning: missing operand; zero assumed
> > vcmulq_f16.s:61: Warning: missing operand; zero assumed
> >
> > I didn't check the code manually yet, and I am using binutils-2.34:
> > has something
> > related to this changed in more recent gas?
>
> No, A hunk didn't get committed.  This should be fixed now.
>

Yeah, I saw your other patch, cool this was an easy fix!

Thanks

> Thanks,
> Tamar
>
> >
> > Thanks
> >
> > Christophe
> >
> > > This is just a splitting of a previously approved patch due to it
> > > having a dependency on the AArch64 bits which have been requested to
> > be reworked.
> > >
> > > Will commit under the previous approval.
> > >
> > > Thanks,
> > > Tamar
> > >
> > > gcc/ChangeLog:
> > >
> > > * config/arm/arm_mve.h (__arm_vcmulq_rot90_f16):
> > > (__arm_vcmulq_rot270_f16, _arm_vcmulq_rot180_f16,
> > __arm_vcmulq_f16,
> > > __arm_vcmulq_rot90_f32, __arm_vcmulq_rot270_f32,
> > > __arm_vcmulq_rot180_f32, __arm_vcmulq_f32, __arm_vcmlaq_f16,
> > > __arm_vcmlaq_rot180_f16, __arm_vcmlaq_rot270_f16,
> > > __arm_vcmlaq_rot90_f16, __arm_vcmlaq_f32,
> > __arm_vcmlaq_rot180_f32,
> > > __arm_vcmlaq_rot270_f32, __arm_vcmlaq_rot90_f32): Update builtin
> > calls.
> > > * config/arm/arm_mve_builtins.def (vcmulq_f, vcmulq_rot90_f,
> > > vcmulq_rot180_f, vcmulq_rot270_f, vcmlaq_f, vcmlaq_rot90_f,
> > > vcmlaq_rot180_f, vcmlaq_rot270_f): Removed.
> > > (vcmulq, vcmulq_rot90, vcmulq_rot180, vcmulq_rot270, vcmlaq,
> > > vcmlaq_rot90, vcmlaq_rot180, vcmlaq_rot270): New.
> > > * config/arm/iterators.md (mve_rot): Add UNSPEC_VCMLA,
> > UNSPEC_VCMLA90,
> > > UNSPEC_VCMLA180, UNSPEC_VCMLA270, UNSPEC_VCMUL,
> > UNSPEC_VCMUL90,
> > > UNSPEC_VCMUL180, UNSPEC_VCMUL270.
> > > (VCMUL): New.
> > > * config/arm/mve.md (mve_vcmulq_f > mve_vcmulq_rot180_f,
> > > mve_vcmulq_rot270_f, mve_vcmulq_rot90_f,
> > mve_vcmlaq_f,
> > > mve_vcmlaq_rot180_f, mve_vcmlaq_rot270_f,
> > > mve_vcmlaq_rot90_f): Removed.
> > > (mve_vcmlaq, mve_vcmulq,
> > > mve_vcaddq, cadd3,
> > mve_vcaddq):
> > > New.
> > > * config/arm/unspecs.md (UNSPEC_VCMUL90, UNSPEC_VCMUL270,
> > UNSPEC_VCMUL,
> > > UNSPEC_VCMUL180): New.
> > > (VCMULQ_F, VCMULQ_ROT180_F, VCMULQ_ROT270_F,
> > VCMULQ_ROT90_F,
> > > VCMLAQ_F, VCMLAQ_ROT180_F, VCMLAQ_ROT90_F,
> > VCMLAQ_ROT270_F): Removed.
> > >
> > > --- inline copy of patch --
> > > diff --git a/gcc/config/arm/arm_mve.h b/gcc/config/arm/arm_mve.h index
> > >
> > 987495dd234ad96ba1163a1f482fe183a46ff437..45014621f2533497e90ddf5257
> > fb
> > > 04e1fd9325b4 100644
> > > --- a/gcc/config/arm/arm_mve.h
> > > +++ b/gcc/config/arm/arm_mve.h
> > > @@ -17348,28 +17348,28 @@ __extension__ extern __inline float16x8_t
> > > __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
> > >  __arm_vcmulq_rot90_f16 (float16x8_t __a, float16x8_t __b)  {
> > > -  return __builtin_mve_vcmulq_rot90_fv8hf (__a, __b);
> > > +  return __builtin_mve_vcmulq_rot90v8hf (__a, __b);
> > >  }
> > >
> > >  __extension__ extern __inline float16x8_t  __attribute__
> > >

[committed] aarch64: Extend aarch64-autovec-preference==2 to 128-bit SVE

[Richard Sandiford via Gcc-patches]

When compiling with -msve-vector-bits=128, aarch64_preferred_simd_mode
would pass the same vector width to aarch64_simd_container_mode for
both SVE and Advanced SIMD, and so Advanced SIMD would always “win”.
This patch instead makes it choose directly between SVE and Advanced
SIMD modes, so that aarch64-autovec-preference==2 and
aarch64-autovec-preference==4 work for this configuration.

(aarch64-autovec-preference shouldn't affect aarch64_simd_container_mode
because that would have an ABI impact for things like GNU vectors.)

Tested on aarch64-linux-gnu (with and without SVE), pushed to trunk.
As Kyrill suggested, I'll backport to GCC 10 too.

Richard


gcc/
* config/aarch64/aarch64.c (aarch64_preferred_simd_mode): Use
aarch64_full_sve_mode and aarch64_vq_mode directly, instead of
going via aarch64_simd_container_mode.
---
 gcc/config/aarch64/aarch64.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 67b4c91dbe4..70ddd70556f 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -17421,10 +17421,11 @@ aarch64_preferred_simd_mode (scalar_mode mode)
 {
   /* Take into account explicit auto-vectorization ISA preferences through
  aarch64_cmp_autovec_modes.  */
-  poly_int64 bits
-= (TARGET_SVE && aarch64_cmp_autovec_modes (VNx16QImode, V16QImode))
-   ? BITS_PER_SVE_VECTOR : 128;
-  return aarch64_simd_container_mode (mode, bits);
+  if (TARGET_SVE && aarch64_cmp_autovec_modes (VNx16QImode, V16QImode))
+return aarch64_full_sve_mode (mode).else_mode (word_mode);
+  if (TARGET_SIMD)
+return aarch64_vq_mode (mode).else_mode (word_mode);
+  return word_mode;
 }
 
 /* Return a list of possible vector sizes for the vectorizer

Re: [PATCH] [WIP] openmp: Add OpenMP 5.0 task detach clause support

[Jakub Jelinek via Gcc-patches]

On Thu, Dec 10, 2020 at 03:38:40PM +0100, Jakub Jelinek via Gcc-patches wrote:
One further thing, the detach clause effectively writes to the var, so
unless you mark the clause decl addressable as I've suggested, you should
if (omp_shared_to_firstprivate_optimizable_decl_p (decl))
  omp_mark_stores (gimplify_omp_ctxp->outer_context, decl);
e.g. in gimplify_adjust_omp_clauses OMP_CLAUSE_DETACH: handling, to make
sure that outer parallel/task etc. regions don't try to optimize the var
from shared to firstprivate through OMP_CLAUSE_SHARED_READONLY flag on
OMP_CLAUSE_SHARED.

Jakub

Re: [PATCH 3/4] libstdc++: Add floating-point std::to_chars implementation

[Christophe Lyon via Gcc-patches]

On Fri, 18 Dec 2020 at 16:00, Patrick Palka  wrote:
>
> On Fri, 18 Dec 2020, Christophe Lyon wrote:
>
> > Hi,
> >
> >
> > On Fri, 18 Dec 2020 at 05:13, Patrick Palka via Gcc-patches
> >  wrote:
> > >
> > > On Thu, Dec 17, 2020 at 9:32 AM Jonathan Wakely  
> > > wrote:
> > > >
> > > > On 19/08/20 17:57 -0400, Patrick Palka via Libstdc++ wrote:
> > > > >On Wed, 22 Jul 2020, Patrick Palka wrote:
> > > > >
> > > > >> On Mon, 20 Jul 2020, Patrick Palka wrote:
> > > > >>
> > > > >> > On Mon, 20 Jul 2020, Jonathan Wakely wrote:
> > > > >> >
> > > > >> > > On 20/07/20 08:53 -0400, Patrick Palka via Libstdc++ wrote:
> > > > >> > > > On Mon, 20 Jul 2020, Jonathan Wakely wrote:
> > > > >> > > >
> > > > >> > > > > On 19/07/20 23:37 -0400, Patrick Palka via Libstdc++ wrote:
> > > > >> > > > > > On Fri, 17 Jul 2020, Patrick Palka wrote:
> > > > >> > > > > >
> > > > >> > > > > > > On Fri, 17 Jul 2020, Patrick Palka wrote:
> > > > >> > > > > > >
> > > > >> > > > > > > > On Wed, 15 Jul 2020, Patrick Palka wrote:
> > > > >> > > > > > > >
> > > > >> > > > > > > > > On Tue, 14 Jul 2020, Patrick Palka wrote:
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > > This implements the floating-point std::to_chars 
> > > > >> > > > > > > > > > overloads for
> > > > >> > > > > > > float,
> > > > >> > > > > > > > > > double and long double.  We use the Ryu library to 
> > > > >> > > > > > > > > > compute the
> > > > >> > > > > > > shortest
> > > > >> > > > > > > > > > round-trippable fixed and scientific forms of a 
> > > > >> > > > > > > > > > number for
> > > > >> > > > > float,
> > > > >> > > > > > > double
> > > > >> > > > > > > > > > and long double.  We also use Ryu for performing 
> > > > >> > > > > > > > > > fixed and
> > > > >> > > > > > > scientific
> > > > >> > > > > > > > > > formatting of float and double. For formatting 
> > > > >> > > > > > > > > > long double with
> > > > >> > > > > an
> > > > >> > > > > > > > > > explicit precision argument we use a printf 
> > > > >> > > > > > > > > > fallback.
> > > > >> > > > > Hexadecimal
> > > > >> > > > > > > > > > formatting for float, double and long double is 
> > > > >> > > > > > > > > > implemented from
> > > > >> > > > > > > > > > scratch.
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > > The supported long double binary formats are 
> > > > >> > > > > > > > > > float64 (same as
> > > > >> > > > > > > double),
> > > > >> > > > > > > > > > float80 (x86 extended precision), float128 and 
> > > > >> > > > > > > > > > ibm128.
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > > Much of the complexity of the implementation is in 
> > > > >> > > > > > > > > > computing the
> > > > >> > > > > > > exact
> > > > >> > > > > > > > > > output length before handing it off to Ryu (which 
> > > > >> > > > > > > > > > doesn't do
> > > > >> > > > > bounds
> > > > >> > > > > > > > > > checking).  In some cases it's hard to compute the 
> > > > >> > > > > > > > > > output length
> > > > >> > > > > > > before
> > > > >> > > > > > > > > > the fact, so in these cases we instead compute an 
> > > > >> > > > > > > > > > upper bound on
> > > > >> > > > > the
> > > > >> > > > > > > > > > output length and use a sufficiently-sized 
> > > > >> > > > > > > > > > intermediate buffer
> > > > >> > > > > (if
> > > > >> > > > > > > the
> > > > >> > > > > > > > > > output range is smaller than the upper bound).
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > > Another source of complexity is in the 
> > > > >> > > > > > > > > > general-with-precision
> > > > >> > > > > > > formatting
> > > > >> > > > > > > > > > mode, where we need to do zero-trimming of the 
> > > > >> > > > > > > > > > string returned
> > > > >> > > > > by
> > > > >> > > > > > > Ryu, and
> > > > >> > > > > > > > > > where we also take care to avoid having to format 
> > > > >> > > > > > > > > > the string a
> > > > >> > > > > > > second
> > > > >> > > > > > > > > > time when the general formatting mode resolves to 
> > > > >> > > > > > > > > > fixed.
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > > Tested on x86_64-pc-linux-gnu, 
> > > > >> > > > > > > > > > aarch64-unknown-linux-gnu,
> > > > >> > > > > > > > > > s390x-ibm-linux-gnu, and 
> > > > >> > > > > > > > > > powerpc64-unknown-linux-gnu.
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > > libstdc++-v3/ChangeLog:
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > >* acinclude.m4 (libtool_VERSION): Bump to 
> > > > >> > > > > > > > > > 6:29:0.
> > > > >> > > > > > > > > >* config/abi/pre/gnu.ver: Add new exports.
> > > > >> > > > > > > > > >* configure: Regenerate.
> > > > >> > > > > > > > > >* include/std/charconv (to_chars): Declare the 
> > > > >> > > > > > > > > > floating-point
> > > > >> > > > > > > > > >overloads for float, double and long double.
> > > > >> > > > > > > > > >* src/c++17/Makefile.am (sources): Add 
> > > > >> > > > > > > > > > floating_to_chars.cc.
> > > > >> > > > > > > > > >* src/c++17/M

Re: AVR maintainership

[Georg-Johann Lay]

Segher Boessenkool schrieb:

On Tue, Dec 15, 2020 at 08:40:08AM +0100, Gerald Pfeifer wrote:

On Mon, 6 Jan 2020, Jeff Law wrote:
p.s. You know anything about Denis Chertykov? He used to reply to avr 
patches within hours, but my latest patches (after a long period where I 
didn't propose any patches) where all approved by you; not a single mail 
from Denis.  So I am concerned if he's well.  Maybe he left you or some 
other global maintainer a note? He's still listed as maintainer though.

I haven't heard much from him for a while.  I'm trying to leave enough
space that he can step in on this stuff, but I'm also hesitant to let
patches linger for too long.
I don't think I have seen mails from Denis since then (more than 
eleven months).


Do we need to get a new maintainer for AVR in place? Any nominations?


I nominate Georg-Johann Lay as the obvious choice, since he has authored
333 of the 511 patches that went into config/avr/ the last ten years.


Segher


Thanks, I feel honoured by this proposal.

However, I have to decline it and cannot set in as avr maintainer 
because I do not have respective resources right now.


Johann

Re: [PATCH 3/4] libstdc++: Add floating-point std::to_chars implementation

[Patrick Palka via Gcc-patches]

On Fri, 18 Dec 2020, Christophe Lyon wrote:

> On Fri, 18 Dec 2020 at 16:00, Patrick Palka  wrote:
> >
> > On Fri, 18 Dec 2020, Christophe Lyon wrote:
> >
> > > Hi,
> > >
> > >
> > > On Fri, 18 Dec 2020 at 05:13, Patrick Palka via Gcc-patches
> > >  wrote:
> > > >
> > > > On Thu, Dec 17, 2020 at 9:32 AM Jonathan Wakely  
> > > > wrote:
> > > > >
> > > > > On 19/08/20 17:57 -0400, Patrick Palka via Libstdc++ wrote:
> > > > > >On Wed, 22 Jul 2020, Patrick Palka wrote:
> > > > > >
> > > > > >> On Mon, 20 Jul 2020, Patrick Palka wrote:
> > > > > >>
> > > > > >> > On Mon, 20 Jul 2020, Jonathan Wakely wrote:
> > > > > >> >
> > > > > >> > > On 20/07/20 08:53 -0400, Patrick Palka via Libstdc++ wrote:
> > > > > >> > > > On Mon, 20 Jul 2020, Jonathan Wakely wrote:
> > > > > >> > > >
> > > > > >> > > > > On 19/07/20 23:37 -0400, Patrick Palka via Libstdc++ wrote:
> > > > > >> > > > > > On Fri, 17 Jul 2020, Patrick Palka wrote:
> > > > > >> > > > > >
> > > > > >> > > > > > > On Fri, 17 Jul 2020, Patrick Palka wrote:
> > > > > >> > > > > > >
> > > > > >> > > > > > > > On Wed, 15 Jul 2020, Patrick Palka wrote:
> > > > > >> > > > > > > >
> > > > > >> > > > > > > > > On Tue, 14 Jul 2020, Patrick Palka wrote:
> > > > > >> > > > > > > > >
> > > > > >> > > > > > > > > > This implements the floating-point std::to_chars 
> > > > > >> > > > > > > > > > overloads for
> > > > > >> > > > > > > float,
> > > > > >> > > > > > > > > > double and long double.  We use the Ryu library 
> > > > > >> > > > > > > > > > to compute the
> > > > > >> > > > > > > shortest
> > > > > >> > > > > > > > > > round-trippable fixed and scientific forms of a 
> > > > > >> > > > > > > > > > number for
> > > > > >> > > > > float,
> > > > > >> > > > > > > double
> > > > > >> > > > > > > > > > and long double.  We also use Ryu for performing 
> > > > > >> > > > > > > > > > fixed and
> > > > > >> > > > > > > scientific
> > > > > >> > > > > > > > > > formatting of float and double. For formatting 
> > > > > >> > > > > > > > > > long double with
> > > > > >> > > > > an
> > > > > >> > > > > > > > > > explicit precision argument we use a printf 
> > > > > >> > > > > > > > > > fallback.
> > > > > >> > > > > Hexadecimal
> > > > > >> > > > > > > > > > formatting for float, double and long double is 
> > > > > >> > > > > > > > > > implemented from
> > > > > >> > > > > > > > > > scratch.
> > > > > >> > > > > > > > > >
> > > > > >> > > > > > > > > > The supported long double binary formats are 
> > > > > >> > > > > > > > > > float64 (same as
> > > > > >> > > > > > > double),
> > > > > >> > > > > > > > > > float80 (x86 extended precision), float128 and 
> > > > > >> > > > > > > > > > ibm128.
> > > > > >> > > > > > > > > >
> > > > > >> > > > > > > > > > Much of the complexity of the implementation is 
> > > > > >> > > > > > > > > > in computing the
> > > > > >> > > > > > > exact
> > > > > >> > > > > > > > > > output length before handing it off to Ryu 
> > > > > >> > > > > > > > > > (which doesn't do
> > > > > >> > > > > bounds
> > > > > >> > > > > > > > > > checking).  In some cases it's hard to compute 
> > > > > >> > > > > > > > > > the output length
> > > > > >> > > > > > > before
> > > > > >> > > > > > > > > > the fact, so in these cases we instead compute 
> > > > > >> > > > > > > > > > an upper bound on
> > > > > >> > > > > the
> > > > > >> > > > > > > > > > output length and use a sufficiently-sized 
> > > > > >> > > > > > > > > > intermediate buffer
> > > > > >> > > > > (if
> > > > > >> > > > > > > the
> > > > > >> > > > > > > > > > output range is smaller than the upper bound).
> > > > > >> > > > > > > > > >
> > > > > >> > > > > > > > > > Another source of complexity is in the 
> > > > > >> > > > > > > > > > general-with-precision
> > > > > >> > > > > > > formatting
> > > > > >> > > > > > > > > > mode, where we need to do zero-trimming of the 
> > > > > >> > > > > > > > > > string returned
> > > > > >> > > > > by
> > > > > >> > > > > > > Ryu, and
> > > > > >> > > > > > > > > > where we also take care to avoid having to 
> > > > > >> > > > > > > > > > format the string a
> > > > > >> > > > > > > second
> > > > > >> > > > > > > > > > time when the general formatting mode resolves 
> > > > > >> > > > > > > > > > to fixed.
> > > > > >> > > > > > > > > >
> > > > > >> > > > > > > > > > Tested on x86_64-pc-linux-gnu, 
> > > > > >> > > > > > > > > > aarch64-unknown-linux-gnu,
> > > > > >> > > > > > > > > > s390x-ibm-linux-gnu, and 
> > > > > >> > > > > > > > > > powerpc64-unknown-linux-gnu.
> > > > > >> > > > > > > > > >
> > > > > >> > > > > > > > > > libstdc++-v3/ChangeLog:
> > > > > >> > > > > > > > > >
> > > > > >> > > > > > > > > >* acinclude.m4 (libtool_VERSION): Bump to 
> > > > > >> > > > > > > > > > 6:29:0.
> > > > > >> > > > > > > > > >* config/abi/pre/gnu.ver: Add new exports.
> > > > > >> > > > > > > > > >* configure: Regenerate.
> > > > > >> > > > > > > > > >* include/std/charconv (to_chars): Declare 
> > > > > >> > > > > > > > > > the float

Re: [PATCH] avr: cc0 to mode_cc conversion

[Georg-Johann Lay via Gcc-patches]

Segher Boessenkool schrieb:

On Thu, Dec 17, 2020 at 10:07:22AM -0500, Paul Koning wrote:

On Dec 17, 2020, at 6:21 AM, Segher Boessenkool  
wrote:
On Thu, Dec 17, 2020 at 02:15:51PM +0530, Senthil Kumar Selvaraj via 
Gcc-patches wrote:

The work on my github branch was not complete - I'd blindly followed
whatever the CC0 Transition wiki mentioned (the first three steps of
case #2), and fixed any regression fallout (for ATmega128).

I intend to try out a define_subst/early clobber of reg_cc based
approach (inspired by the cris port) and see if that can help avoid the
proliferation of define_insn_and_splits. Will update how that works out.

Yeah, case #2 does not necessarily give the best result, but it usually
is the least work to do, so certainly a good choice under time pressure.

I was under the impression from what I read in the blog a year or two ago (when I did the pdp11 
ccmode work) that "case 2" is the better answer for machines in which pretty much every 
operation touches the condition codes.  In other words, I understood that case 1 would for such 
machines not be the right answer -- it wasn't just that "case 2 is easier".

Did I misunderstand?  Is there a reason for machines such as pdp11, in which 
basically every operation that handles data, even a move instruction, touches 
CC, to use approach 1?


No, you didn't misunderstand.  I said "not necessarily" for a reason :-)

If there are move insns that do *not* clobber CC, it can be different,
but if even move instructions do, a case #2 conversion is a good choice.

(This is all my opinion, but I think it is not controversial.)


As far as I understand, targets that clobber condition code in mov
or add3 must use approach #2.  #1 is not a problem if the target
still uses IRA (like avr does), but LRA cannot handle clobbers of the
condition code (in terms or explicit clobbers).

Hence, targets that clobber cc in mov or add3 must
use #2 because IRA/reload will also be kicked out before very soon.

Or am I missing something?

Johann

Re: [PATCH] libstdc++: Fix build failure due to missing [PR98374]

[Patrick Palka via Gcc-patches]

On Fri, Dec 18, 2020 at 11:04 AM Patrick Palka  wrote:
>
> This fixes a build failure on Windows which lacks .
> (We can't use the more portable localeconv() from  to obtain
> the radix character of the current locale here because it's not
> thread-safe, unfortunately.)
>
> This change means that on Windows and other such systems, we'll just
> always assume the radix character used by printf is '.' when formatting
> a long double through it.
>
> libstdc++-v3/ChangeLog:
>
> PR libstdc++/98374
> * src/c++17/floating_to_chars.cc: Guard include of 
> with __has_include.
> (__floating_to_chars_precision) [!defined(RADIXCHAR)]: Don't
> attempt to obtain the radix character of the current locale,
> just assume it's '.'.

I went ahead and committed this patch under the "obvious" rule as r11-6259.

> ---
>  libstdc++-v3/src/c++17/floating_to_chars.cc | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/libstdc++-v3/src/c++17/floating_to_chars.cc 
> b/libstdc++-v3/src/c++17/floating_to_chars.cc
> index 474e791e717..6470fbb0b95 100644
> --- a/libstdc++-v3/src/c++17/floating_to_chars.cc
> +++ b/libstdc++-v3/src/c++17/floating_to_chars.cc
> @@ -33,7 +33,9 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#if __has_include()
> +# include  // for nl_langinfo
> +#endif
>  #include 
>  #include 
>  #include 
> @@ -1113,6 +1115,7 @@ template
> // to handle a radix point that's different from '.'.
> char radix[6] = {'.', '\0', '\0', '\0', '\0', '\0'};
> if (effective_precision > 0)
> +#ifdef RADIXCHAR
>   // ???: Can nl_langinfo() ever return null?
>   if (const char* const radix_ptr = nl_langinfo(RADIXCHAR))
> {
> @@ -1121,6 +1124,7 @@ template
>   // UTF-8 character) wide.
>   __glibcxx_assert(radix[4] == '\0');
> }
> +#endif
>
> // Compute straightforward upper bounds on the output length.
> int output_length_upper_bound;
> --
> 2.30.0.rc0
>

Re: [PATCH] libstdc++: Fix build failure on AArch64 ILP32 [PR98370]

[Patrick Palka via Gcc-patches]

On Fri, Dec 18, 2020 at 11:26 AM Patrick Palka  wrote:
>
> This should fix a build failure on AArch64 ILP32 due to int32_t mapping
> to long int instead of int on this platform, which causes type deduction
> to fail in the below call to std::max as reported in the PR.
>
> libstdc++-v3/ChangeLog:
>
> PR libstdc++/98370
> * src/c++17/floating_to_chars.cc (__floating_to_chars_shortest):
> Provide explicit template arguments to the call to std::max.

I went ahead and committed this patch under the "obvious" rule as r11-6260.

> ---
>  libstdc++-v3/src/c++17/floating_to_chars.cc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libstdc++-v3/src/c++17/floating_to_chars.cc 
> b/libstdc++-v3/src/c++17/floating_to_chars.cc
> index 6470fbb0b95..3f46bce7a15 100644
> --- a/libstdc++-v3/src/c++17/floating_to_chars.cc
> +++ b/libstdc++-v3/src/c++17/floating_to_chars.cc
> @@ -977,7 +977,7 @@ template
> // fd.exponent contain all of the information needed to format the
> // number in fixed notation "as if by std::printf" (with precision
> // equal to -fd.exponent).
> -   const int whole_digits = max(mantissa_length + fd.exponent, 1);
> +   const int whole_digits = max(mantissa_length + fd.exponent, 1);
> const int expected_output_length
>   = fd.sign + whole_digits + strlen(".") + -fd.exponent;
> if (last - first < expected_output_length)
> --
> 2.30.0.rc0
>

[committed] libstdc++: Fix mistake in PR98374 change [PR98377]

[Patrick Palka via Gcc-patches]

The #ifdef RADIXCHAR directive should be moved one line up so that it
also guards the outer if statement, or else when RADIXCHAR is not
defined the outer if statement will end up nonsensically guarding the
declaration of output_length_upper_bound a few lines below it.

libstdc++-v3/ChangeLog:

PR libstdc++/98377
* src/c++17/floating_to_chars.cc (__floating_to_chars_precision):
Fix mistake.
---
 libstdc++-v3/src/c++17/floating_to_chars.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libstdc++-v3/src/c++17/floating_to_chars.cc 
b/libstdc++-v3/src/c++17/floating_to_chars.cc
index 3f46bce7a15..b7c31c746cc 100644
--- a/libstdc++-v3/src/c++17/floating_to_chars.cc
+++ b/libstdc++-v3/src/c++17/floating_to_chars.cc
@@ -1114,8 +1114,8 @@ template
// Since the output of printf is locale-sensitive, we need to be able
// to handle a radix point that's different from '.'.
char radix[6] = {'.', '\0', '\0', '\0', '\0', '\0'};
-   if (effective_precision > 0)
 #ifdef RADIXCHAR
+   if (effective_precision > 0)
  // ???: Can nl_langinfo() ever return null?
  if (const char* const radix_ptr = nl_langinfo(RADIXCHAR))
{
-- 
2.30.0.rc0

[r11-6253 Regression] FAIL: gfortran.dg/unlimited_polymorphic_32.f03 -Os execution test on Linux/x86_64

[sunil.k.pandey via Gcc-patches]

On Linux/x86_64,

ce8dcc9105cbd4043d575d8b2c91309a423951a9 is the first bad commit
commit ce8dcc9105cbd4043d575d8b2c91309a423951a9
Author: Paul Thomas 
Date:   Fri Dec 18 14:00:11 2020 +

As well as the PR this patch fixes problems in handling class objects

caused

FAIL: gfortran.dg/unlimited_polymorphic_32.f03   -O0  execution test
FAIL: gfortran.dg/unlimited_polymorphic_32.f03   -O1  execution test
FAIL: gfortran.dg/unlimited_polymorphic_32.f03   -O2  execution test
FAIL: gfortran.dg/unlimited_polymorphic_32.f03   -O3 -fomit-frame-pointer 
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/unlimited_polymorphic_32.f03   -O3 -g  execution test
FAIL: gfortran.dg/unlimited_polymorphic_32.f03   -Os  execution test

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-6253/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="dg.exp=gfortran.dg/unlimited_polymorphic_32.f03 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="dg.exp=gfortran.dg/unlimited_polymorphic_32.f03 
--target_board='unix{-m32\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

RE: [PATCH][GCC][PR target/98177] aarch64: SVE: ICE in expand_direct_optab_fn

[Przemyslaw Wirkus via Gcc-patches]

> Przemyslaw Wirkus  writes:
> > > This is a bug in the vectoriser: the vectoriser shouldn't generate
> > > IFN_REDUC_MAX calls that the target doesn't support.
> > >
> > > I think the problem comes from using the wrong interface to get the
> > > index type for a COND_REDUCTION.  vectorizable_reduction has:
> > >
> > >   cr_index_vector_type = build_vector_type (cr_index_scalar_type,
> > > nunits_out);
> > >
> > > which means that for fixed-length SVE we get a V2SI (a 64-bit
> > > Advanced SIMD
> > > vector) instead of a VNx2SI (an SVE vector that stores SI elements
> > > in DI containers).  It should be using:
> > >
> > >   cr_index_vector_type = get_same_sized_vectype
> (cr_index_scalar_type,
> > >  vectype_out);
> > >
> > > instead.  Same idea for the build_vector_type call in
> > > vect_create_epilog_for_reduction.
> 
> Note that for this last bit I meant:
> 
>   tree vectype_unsigned = build_vector_type
>   (scalar_type_unsigned, TYPE_VECTOR_SUBPARTS (vectype));
> 
> which should become:
> 
>   tree vectype_unsigned = get_same_sized_vectype (scalar_type_unsigned,
> vectype);
> 
> This is the “transform” code that partners the “analysis” code that you're
> patching.  Changing one but not the other would cause problems if (say) the
> Advanced SIMD REDUC_MAX patterns were disabled.  We'd then correctly
> pick an SVE mode like VNx4SI when doing the analysis, but generate an
> unsupported V4SI REDUC_MAX in vect_create_epilog_for_reduction.
> That in turn would trip the kind of expand-time assert that was reported in
> the PR, just for a different case.
> 
> It's better for the modes to match up anyway: we should use a VNx4SI
> reduction when operating on SVE and a V4SI reducation when operating on
> Advanced SIMD.  This is particularly true for big endian, where mixing SVE
> and Advanced SIMD can involve a permute.
> 
> > diff --git a/gcc/testsuite/g++.target/aarch64/pr98177-1.C
> > b/gcc/testsuite/g++.target/aarch64/pr98177-1.C
> > new file mode 100644
> > index
> >
> ..a776b7352f966f6b1d870e
> d51a7c
> > 94647bc46d80
> > --- /dev/null
> > +++ b/gcc/testsuite/g++.target/aarch64/pr98177-1.C
> > @@ -0,0 +1,10 @@
> > +/* { dg-do compile } */
> > +/* { dg-options "-Ofast -march=armv8.2-a+sve -msve-vector-bits=128" }
> > +*/
> > +
> > +int a, b;
> > +short c;
> > +void d(long e) {
> > +  for (int f = 0; f < b; f += 1)
> > +for (short g = 0; g < c; g += 5)
> > +  a = (short)e;
> > +}
> 
> It'd be better to put these g++.target/aarch64/sve and drop the -march
> option.  That way we'll test with the user's specified -march or -mcpu if 
> that -
> march/-mcpu already supports SVE.
> 
> Same idea for the other tests (including the C ones).
> 
> OK for trunk with those changes, thanks.

commit d44d47b49267b4265cee16d25b3f89dbf967cc0c

> Richard


rb13905_v3.patch
Description: rb13905_v3.patch

Re: [PATCH 3/4] libstdc++: Add floating-point std::to_chars implementation

[Christophe Lyon via Gcc-patches]

Le ven. 18 déc. 2020 à 18:03, Patrick Palka  a écrit :

> On Fri, 18 Dec 2020, Christophe Lyon wrote:
>
> > On Fri, 18 Dec 2020 at 16:00, Patrick Palka  wrote:
> > >
> > > On Fri, 18 Dec 2020, Christophe Lyon wrote:
> > >
> > > > Hi,
> > > >
> > > >
> > > > On Fri, 18 Dec 2020 at 05:13, Patrick Palka via Gcc-patches
> > > >  wrote:
> > > > >
> > > > > On Thu, Dec 17, 2020 at 9:32 AM Jonathan Wakely <
> jwak...@redhat.com> wrote:
> > > > > >
> > > > > > On 19/08/20 17:57 -0400, Patrick Palka via Libstdc++ wrote:
> > > > > > >On Wed, 22 Jul 2020, Patrick Palka wrote:
> > > > > > >
> > > > > > >> On Mon, 20 Jul 2020, Patrick Palka wrote:
> > > > > > >>
> > > > > > >> > On Mon, 20 Jul 2020, Jonathan Wakely wrote:
> > > > > > >> >
> > > > > > >> > > On 20/07/20 08:53 -0400, Patrick Palka via Libstdc++
> wrote:
> > > > > > >> > > > On Mon, 20 Jul 2020, Jonathan Wakely wrote:
> > > > > > >> > > >
> > > > > > >> > > > > On 19/07/20 23:37 -0400, Patrick Palka via Libstdc++
> wrote:
> > > > > > >> > > > > > On Fri, 17 Jul 2020, Patrick Palka wrote:
> > > > > > >> > > > > >
> > > > > > >> > > > > > > On Fri, 17 Jul 2020, Patrick Palka wrote:
> > > > > > >> > > > > > >
> > > > > > >> > > > > > > > On Wed, 15 Jul 2020, Patrick Palka wrote:
> > > > > > >> > > > > > > >
> > > > > > >> > > > > > > > > On Tue, 14 Jul 2020, Patrick Palka wrote:
> > > > > > >> > > > > > > > >
> > > > > > >> > > > > > > > > > This implements the floating-point
> std::to_chars overloads for
> > > > > > >> > > > > > > float,
> > > > > > >> > > > > > > > > > double and long double.  We use the Ryu
> library to compute the
> > > > > > >> > > > > > > shortest
> > > > > > >> > > > > > > > > > round-trippable fixed and scientific forms
> of a number for
> > > > > > >> > > > > float,
> > > > > > >> > > > > > > double
> > > > > > >> > > > > > > > > > and long double.  We also use Ryu for
> performing fixed and
> > > > > > >> > > > > > > scientific
> > > > > > >> > > > > > > > > > formatting of float and double. For
> formatting long double with
> > > > > > >> > > > > an
> > > > > > >> > > > > > > > > > explicit precision argument we use a printf
> fallback.
> > > > > > >> > > > > Hexadecimal
> > > > > > >> > > > > > > > > > formatting for float, double and long
> double is implemented from
> > > > > > >> > > > > > > > > > scratch.
> > > > > > >> > > > > > > > > >
> > > > > > >> > > > > > > > > > The supported long double binary formats
> are float64 (same as
> > > > > > >> > > > > > > double),
> > > > > > >> > > > > > > > > > float80 (x86 extended precision), float128
> and ibm128.
> > > > > > >> > > > > > > > > >
> > > > > > >> > > > > > > > > > Much of the complexity of the
> implementation is in computing the
> > > > > > >> > > > > > > exact
> > > > > > >> > > > > > > > > > output length before handing it off to Ryu
> (which doesn't do
> > > > > > >> > > > > bounds
> > > > > > >> > > > > > > > > > checking).  In some cases it's hard to
> compute the output length
> > > > > > >> > > > > > > before
> > > > > > >> > > > > > > > > > the fact, so in these cases we instead
> compute an upper bound on
> > > > > > >> > > > > the
> > > > > > >> > > > > > > > > > output length and use a sufficiently-sized
> intermediate buffer
> > > > > > >> > > > > (if
> > > > > > >> > > > > > > the
> > > > > > >> > > > > > > > > > output range is smaller than the upper
> bound).
> > > > > > >> > > > > > > > > >
> > > > > > >> > > > > > > > > > Another source of complexity is in the
> general-with-precision
> > > > > > >> > > > > > > formatting
> > > > > > >> > > > > > > > > > mode, where we need to do zero-trimming of
> the string returned
> > > > > > >> > > > > by
> > > > > > >> > > > > > > Ryu, and
> > > > > > >> > > > > > > > > > where we also take care to avoid having to
> format the string a
> > > > > > >> > > > > > > second
> > > > > > >> > > > > > > > > > time when the general formatting mode
> resolves to fixed.
> > > > > > >> > > > > > > > > >
> > > > > > >> > > > > > > > > > Tested on x86_64-pc-linux-gnu,
> aarch64-unknown-linux-gnu,
> > > > > > >> > > > > > > > > > s390x-ibm-linux-gnu, and
> powerpc64-unknown-linux-gnu.
> > > > > > >> > > > > > > > > >
> > > > > > >> > > > > > > > > > libstdc++-v3/ChangeLog:
> > > > > > >> > > > > > > > > >
> > > > > > >> > > > > > > > > >* acinclude.m4 (libtool_VERSION): Bump
> to 6:29:0.
> > > > > > >> > > > > > > > > >* config/abi/pre/gnu.ver: Add new
> exports.
> > > > > > >> > > > > > > > > >* configure: Regenerate.
> > > > > > >> > > > > > > > > >* include/std/charconv (to_chars):
> Declare the floating-point
> > > > > > >> > > > > > > > > >overloads for float, double and long
> double.
> > > > > > >> > > > > > > > > >* src/c++17/Makefile.am (sources): Add
> floating_to_chars.cc.
> > > > > > >> > > > > > > > > >* src/c++17/Makefile.in: Regenerate.
> > > > > > >> > > > > > > > > >* src/c++17/floating_to_chars.cc: New
> file.
> > > > > > >> > > > > > > > > >*
> testsuite/20_util/to_chars/l

Re: [PATCH] avr: cc0 to mode_cc conversion

[Segher Boessenkool]

On Fri, Dec 18, 2020 at 06:13:22PM +0100, Georg-Johann Lay wrote:
> Segher Boessenkool schrieb:
> >On Thu, Dec 17, 2020 at 10:07:22AM -0500, Paul Koning wrote:
> >>>On Dec 17, 2020, at 6:21 AM, Segher Boessenkool 
> >>> wrote:
> >>>On Thu, Dec 17, 2020 at 02:15:51PM +0530, Senthil Kumar Selvaraj via 
> >>>Gcc-patches wrote:
> The work on my github branch was not complete - I'd blindly followed
> whatever the CC0 Transition wiki mentioned (the first three steps of
> case #2), and fixed any regression fallout (for ATmega128).
> 
> I intend to try out a define_subst/early clobber of reg_cc based
> approach (inspired by the cris port) and see if that can help avoid the
> proliferation of define_insn_and_splits. Will update how that works out.
> >>>Yeah, case #2 does not necessarily give the best result, but it usually
> >>>is the least work to do, so certainly a good choice under time pressure.
> >>I was under the impression from what I read in the blog a year or two ago 
> >>(when I did the pdp11 ccmode work) that "case 2" is the better answer for 
> >>machines in which pretty much every operation touches the condition 
> >>codes.  In other words, I understood that case 1 would for such machines 
> >>not be the right answer -- it wasn't just that "case 2 is easier".
> >>
> >>Did I misunderstand?  Is there a reason for machines such as pdp11, in 
> >>which basically every operation that handles data, even a move 
> >>instruction, touches CC, to use approach 1?
> >
> >No, you didn't misunderstand.  I said "not necessarily" for a reason :-)
> >
> >If there are move insns that do *not* clobber CC, it can be different,
> >but if even move instructions do, a case #2 conversion is a good choice.
> >
> >(This is all my opinion, but I think it is not controversial.)
> 
> As far as I understand, targets that clobber condition code in mov
> or add3 must use approach #2.

If there is no way to reload without clobbering CC, yeah.  Often you
*can* reload that way, at big cost (push the flags to the stack around
the move, for example), but if you need that for common insns, this is
no good.

> #1 is not a problem if the target
> still uses IRA (like avr does), but LRA cannot handle clobbers of the
> condition code (in terms or explicit clobbers).

(still uses reload)

I'm not sure what the LRA thing means?  The rs6000 port has many
patterns that clobber some specific CR reg.  If it is important here
that there is only one such reg, thyen we also clobber the CA reg in
many patterns (the carry bit, there is only one of those).

Or is this only wrt mov and add as well?

> Hence, targets that clobber cc in mov or add3 must
> use #2 because IRA/reload will also be kicked out before very soon.
> 
> Or am I missing something?

compare-elim.c claims this same thing:
  There is a set of targets whose general-purpose move or addition
  instructions clobber the flags.  These targets cannot split their
  CBRANCH/CSTORE etc patterns before reload is complete, lest reload
  itself insert these instructions in between the flags setter and user.
so you might well be right :-)

Thanks,


Segher

Re: Patch RFA: Support non-ASCII file names in git-changelog

[Ian Lance Taylor via Gcc-patches]

On Fri, Dec 18, 2020 at 2:28 AM Martin Liška  wrote:
>
> On 12/17/20 5:26 AM, Ian Lance Taylor via Gcc-patches wrote:
> > As discussed at
> > https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561995.html ,
> > the ChangeLog checker does not correctly handle files with non-ASCII
> > file names.
> >
> > This patch fixes the problem.  I have little experience with Python,
> > so I may have made some foolish mistakes here.
> >
> > OK to commit?
> >
> > Thanks.
> >
> > Ian
> >
> > * gcc-changelog/git_repository.py: Ignore quotation marks added by git
> > for non-ASCII file names.
> >
>
> First, sorry for a slow response about the previous
> thread (Change to gcc/testsuite/go.test/test rejected by ChangeLog checker).
>
> Well, the suggested change will not help us because we will not be able
> to find a file with a given path (\xxx\yyy...).
>
> Proper solution is likely doing:
> $ git config --global core.quotepath false
>
> both on server side (and client side).
>
> Having that, git properly displays non-ascii filenames:


> Thoughts?


I don't know the tradeoffs here.  This approach sounds fine to me.

Ian

[OG10][committed] Backport openmp: Implicit 'declare target' for C++ static initializers

[Kwok Cheung Yeung]

Hello

I have now backported the "openmp: Implicit 'declare target' for C++ static 
initializers" patch from mainline to the devel/omp/gcc-10 branch. The testcase 
required a small tweak as the gimple output has changed since OG10 was branched.


This has been committed as commit 83797c2d47aaa011b73512f6e86cf6a192cade56.

Kwok

[committed] libcc1: Fix up libcc1 configure [PR98330]

[Jakub Jelinek via Gcc-patches]

On Wed, Dec 02, 2020 at 04:11:24PM +, Iain Sandoe wrote:
> > > --- a/libcc1/configure.ac
> > > +++ b/libcc1/configure.ac
> > > @@ -104,6 +104,12 @@ AC_CACHE_CHECK([for socket libraries],
> > > libcc1_cv_lib_sockets,
> > > ])
> > > LIBS="$LIBS $libcc1_cv_lib_sockets"
> > > 
> > > +case "$host" in
> > > +  *-*-darwin*) darwin_dynamic_lookup=yes ;;
> > > +  *) darwin_dynamic_lookup= ;;
> > > +esac
> > > +AM_CONDITIONAL(DARWIN_DYNAMIC_LOOKUP, test $darwin_dynamic_lookup = yes)

Either we should write test x$darwin_dynamic_lookup = xyes
or we should make sure the variable is always defined to non-empty string.

The following patch does the latter, committed to trunk as obvious.

2020-12-18  Jakub Jelinek  

PR bootstrap/98380
* configure.ac: Set darwin_dynamic_lookup=no instead to empty
string.
* configure: Regenerated.

--- libcc1/configure.ac.jj  2020-12-06 10:51:32.77671 +0100
+++ libcc1/configure.ac 2020-12-18 20:18:22.615201701 +0100
@@ -106,7 +106,7 @@ LIBS="$LIBS $libcc1_cv_lib_sockets"
 
 case "$host" in
   *-*-darwin*) darwin_dynamic_lookup=yes ;;
-  *) darwin_dynamic_lookup= ;;
+  *) darwin_dynamic_lookup=no ;;
 esac
 AM_CONDITIONAL(DARWIN_DYNAMIC_LOOKUP, test $darwin_dynamic_lookup = yes)
 
--- libcc1/configure.jj 2020-12-06 10:51:32.77671 +0100
+++ libcc1/configure2020-12-18 20:18:30.373121348 +0100
@@ -14976,7 +14976,7 @@ LIBS="$LIBS $libcc1_cv_lib_sockets"
 
 case "$host" in
   *-*-darwin*) darwin_dynamic_lookup=yes ;;
-  *) darwin_dynamic_lookup= ;;
+  *) darwin_dynamic_lookup=no ;;
 esac
  if test $darwin_dynamic_lookup = yes; then
   DARWIN_DYNAMIC_LOOKUP_TRUE=

Jakub

Re: [PATCH] openmp: Implicit 'declare target' for C++ static initializers

[Jakub Jelinek via Gcc-patches]

On Fri, Dec 18, 2020 at 03:10:52PM +, Kwok Cheung Yeung wrote:
> 2020-12-17  Kwok Cheung Yeung  
> 
>   gcc/testsuite/
>   * g++.dg/gomp/declare-target-3.C: New.

Note the test fails on the trunk when one doesn't have offloading
configured.  IL scan tests are always problematic, different between
offloading and no offloading...

Jakub

Re: [PATCH] openmp: Implicit 'declare target' for C++ static initializers

[Kwok Cheung Yeung]

On 18/12/2020 7:31 pm, Jakub Jelinek wrote:

On Fri, Dec 18, 2020 at 03:10:52PM +, Kwok Cheung Yeung wrote:

2020-12-17  Kwok Cheung Yeung  

gcc/testsuite/
* g++.dg/gomp/declare-target-3.C: New.


Note the test fails on the trunk when one doesn't have offloading
configured.  IL scan tests are always problematic, different between
offloading and no offloading...


Oops. This patch disables the scan for .offload_var_table entries in the 
assembler if offloading is not enabled. The gimple tests appear to be okay though?


Okay for trunk?

Thanks

Kwok
commit f427d4eaddbd1ee4001e057b231c92fdd9fc66f5
Author: Kwok Cheung Yeung 
Date:   Fri Dec 18 12:05:20 2020 -0800

openmp: Fix g++.dg/gomp/declare-target-3.C testcase when offloading is 
disabled

2020-12-18  Kwok Cheung Yeung  

gcc/testsuite/
* g++.dg/gomp/declare-target-3.C: Only check .offload_var_table
entries if offloading is enabled.

diff --git a/gcc/testsuite/g++.dg/gomp/declare-target-3.C 
b/gcc/testsuite/g++.dg/gomp/declare-target-3.C
index d2dedaf..1e23c86 100644
--- a/gcc/testsuite/g++.dg/gomp/declare-target-3.C
+++ b/gcc/testsuite/g++.dg/gomp/declare-target-3.C
@@ -22,10 +22,10 @@ int *g = &f;// Explicitly marked
 // { dg-final { scan-tree-dump "__attribute__\\\(\\\(omp declare 
target\\\)\\\)\\\nint bar \\\(\\\)" "gimple" } }
 // { dg-final { scan-tree-dump "__attribute__\\\(\\\(omp declare 
target\\\)\\\)\\\nint baz \\\(\\\)" "gimple" } }
 // { dg-final { scan-tree-dump "__attribute__\\\(\\\(omp declare 
target\\\)\\\)\\\nint qux \\\(\\\)" "gimple" } }
-// { dg-final { scan-assembler-not "\\\.offload_var_table:\\n.+\\\.quad\\s+a" 
} }
-// { dg-final { scan-assembler "\\\.offload_var_table:\\n.+\\\.quad\\s+b" } }
-// { dg-final { scan-assembler "\\\.offload_var_table:\\n.+\\\.quad\\s+c" } }
-// { dg-final { scan-assembler "\\\.offload_var_table:\\n.+\\\.quad\\s+d" } }
-// { dg-final { scan-assembler "\\\.offload_var_table:\\n.+\\\.quad\\s+e" } }
-// { dg-final { scan-assembler "\\\.offload_var_table:\\n.+\\\.quad\\s+f" } }
-// { dg-final { scan-assembler "\\\.offload_var_table:\\n.+\\\.quad\\s+g" } }
+// { dg-final { scan-assembler-not "\\\.offload_var_table:\\n.+\\\.quad\\s+a" 
{ target { offloading_enabled } } } }
+// { dg-final { scan-assembler "\\\.offload_var_table:\\n.+\\\.quad\\s+b" { 
target { offloading_enabled } } } }
+// { dg-final { scan-assembler "\\\.offload_var_table:\\n.+\\\.quad\\s+c" { 
target { offloading_enabled } } } }
+// { dg-final { scan-assembler "\\\.offload_var_table:\\n.+\\\.quad\\s+d" { 
target { offloading_enabled } } } }
+// { dg-final { scan-assembler "\\\.offload_var_table:\\n.+\\\.quad\\s+e" { 
target { offloading_enabled } } } }
+// { dg-final { scan-assembler "\\\.offload_var_table:\\n.+\\\.quad\\s+f" { 
target { offloading_enabled } } } }
+// { dg-final { scan-assembler "\\\.offload_var_table:\\n.+\\\.quad\\s+g" { 
target { offloading_enabled } } } }

Re: [PATCH] openmp: Implicit 'declare target' for C++ static initializers

[Jakub Jelinek via Gcc-patches]

On Fri, Dec 18, 2020 at 08:15:56PM +, Kwok Cheung Yeung wrote:
> On 18/12/2020 7:31 pm, Jakub Jelinek wrote:
> > On Fri, Dec 18, 2020 at 03:10:52PM +, Kwok Cheung Yeung wrote:
> > > 2020-12-17  Kwok Cheung Yeung  
> > > 
> > >   gcc/testsuite/
> > >   * g++.dg/gomp/declare-target-3.C: New.
> > 
> > Note the test fails on the trunk when one doesn't have offloading
> > configured.  IL scan tests are always problematic, different between
> > offloading and no offloading...
> 
> Oops. This patch disables the scan for .offload_var_table entries in the
> assembler if offloading is not enabled. The gimple tests appear to be okay
> though?
> 
> Okay for trunk?

Ok, thanks.

> commit f427d4eaddbd1ee4001e057b231c92fdd9fc66f5
> Author: Kwok Cheung Yeung 
> Date:   Fri Dec 18 12:05:20 2020 -0800
> 
> openmp: Fix g++.dg/gomp/declare-target-3.C testcase when offloading is 
> disabled
> 
> 2020-12-18  Kwok Cheung Yeung  
> 
>   gcc/testsuite/
>   * g++.dg/gomp/declare-target-3.C: Only check .offload_var_table
>   entries if offloading is enabled.

Jakub

[PATCH] expr: Fix up constant_byte_string bitfield handling [PR98366]

[Jakub Jelinek via Gcc-patches]

Hi!

constant_byte_string now uses a convert_to_bytes function, which doesn't
handle bitfields at all (don't punt on them, just puts them into wrong bits
or bytes).  Furthermore, I don't see a reason why that function should exist
at all, it duplicates native_encode_initializer functionality.
Except that native_encode_initializer punted on flexible array members and 2
tests in the testsuite relied on constant_byte_string handling those.
So, this patch throws away convert_to_bytes, uses native_encode_initializer
instead, but teaches it to handle flexible array members (only in the
non-mask mode with off == -1 for now), furthermore, it adds various corner
case checks that the old implementation was missing (like that STRING_CSTs
use int as length and therefore we shouldn't try to build larger than that
strings, or that native_encode*/native_interpret* APIs require sane
host and target bytes (8-bit on both).

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

2020-12-18  Jakub Jelinek  

PR middle-end/98366
* fold-const.c (native_encode_initializer): Don't try to
memset more than total_bytes with off == -1 even if len is large.
Handle flexible array member initializers if off == -1 and mask is
NULL.
* expr.c (convert_to_bytes): Remove.
(constant_byte_string): Use native_encode_initializer instead of
convert_to_bytes.  Remove extraneous semicolon.  Punt on various
corner-cases the APIs don't handle, like sizes > INT_MAX,
BITS_PER_UNIT != 8, CHAR_BIT != 8.

* gcc.c-torture/execute/pr98366.c: New test.

--- gcc/fold-const.c.jj 2020-12-09 09:36:05.017217418 +0100
+++ gcc/fold-const.c2020-12-18 16:25:52.053997090 +0100
@@ -8197,7 +8197,7 @@ native_encode_initializer (tree init, un
 
  gcc_assert (TREE_CODE (type) == RECORD_TYPE || mask == NULL);
  if (ptr != NULL)
-   memset (ptr, '\0', MIN (total_bytes - off, len));
+   memset (ptr, '\0', MIN (total_bytes - o, len));
  for (cnt = 0; ; cnt++)
{
  tree val = NULL_TREE, field = NULL_TREE;
@@ -8266,11 +8266,33 @@ native_encode_initializer (tree init, un
  if (TREE_CODE (TREE_TYPE (field)) == ARRAY_TYPE
  && TYPE_DOMAIN (TREE_TYPE (field))
  && ! TYPE_MAX_VALUE (TYPE_DOMAIN (TREE_TYPE (field
-   return 0;
- if (DECL_SIZE_UNIT (field) == NULL_TREE
- || !tree_fits_shwi_p (DECL_SIZE_UNIT (field)))
-   return 0;
- fieldsize = tree_to_shwi (DECL_SIZE_UNIT (field));
+   {
+ if (mask || off != -1)
+   return 0;
+ if (val == NULL_TREE)
+   continue;
+ if (TREE_CODE (TREE_TYPE (val)) != ARRAY_TYPE)
+   return 0;
+ fieldsize = int_size_in_bytes (TREE_TYPE (val));
+ if (fieldsize < 0
+ || (int) fieldsize != fieldsize
+ || (pos + fieldsize) > INT_MAX)
+   return 0;
+ if (pos + fieldsize > total_bytes)
+   {
+ if (ptr != NULL && total_bytes - o < len)
+   memset (ptr + (total_bytes - o),
+   '\0', MIN (pos + fieldsize - o, len));
+ total_bytes = pos + fieldsize;
+   }
+   }
+ else
+   {
+ if (DECL_SIZE_UNIT (field) == NULL_TREE
+ || !tree_fits_shwi_p (DECL_SIZE_UNIT (field)))
+   return 0;
+ fieldsize = tree_to_shwi (DECL_SIZE_UNIT (field));
+   }
  if (fieldsize == 0)
continue;
 
@@ -8439,12 +8461,31 @@ native_encode_initializer (tree init, un
  || (pos >= off
  && (pos + fieldsize <= (HOST_WIDE_INT) off + len)))
{
- if (!native_encode_initializer (val, ptr ? ptr + pos - o
-  : NULL,
- fieldsize,
- off == -1 ? -1 : 0,
- mask ? mask + pos : NULL))
+ int fldsize = fieldsize;
+ if (off == -1)
+   {
+ tree fld = DECL_CHAIN (field);
+ while (fld)
+   {
+ if (TREE_CODE (fld) == FIELD_DECL)
+   break;
+ fld = DECL_CHAIN (fld);
+   }
+ if (fld == NULL_TREE)
+   fldsize = len - pos;
+   }
+ r = native_encode_initializer (val, ptr ? ptr + pos - o
+ : NULL,

[committed] openmp: Don't optimize shared to firstprivate on task with depend clause

[Jakub Jelinek via Gcc-patches]

Hi!

The attached testcase is miscompiled, because we optimize shared clauses
to firstprivate when task body can't modify the variable even when the
task has depend clause.  That is wrong, because firstprivate means the
variable will be copied immediately when the task is created, while with
depend clause some other task might change it later before the dependencies
are satisfied and the task should observe the value only after the change.

Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk
so far.

2020-12-18  Jakub Jelinek  

* gimplify.c (struct gimplify_omp_ctx): Add has_depend member.
(gimplify_scan_omp_clauses): Set it to true if OMP_CLAUSE_DEPEND
appears on OMP_TASK.
(gimplify_adjust_omp_clauses_1, gimplify_adjust_omp_clauses): Force
GOVD_WRITTEN on shared variables if task construct has depend clause.

* testsuite/libgomp.c/task-6.c: New test.

--- gcc/gimplify.c.jj   2020-11-26 01:14:47.537081889 +0100
+++ gcc/gimplify.c  2020-12-18 17:31:53.746888168 +0100
@@ -231,6 +231,7 @@ struct gimplify_omp_ctx
   bool target_firstprivatize_array_bases;
   bool add_safelen1;
   bool order_concurrent;
+  bool has_depend;
   int defaultmap[4];
 };
 
@@ -9497,6 +9498,8 @@ gimplify_scan_omp_clauses (tree *list_p,
  remove = true;
  break;
}
+ if (code == OMP_TASK)
+   ctx->has_depend = true;
  break;
 
case OMP_CLAUSE_TO:
@@ -10207,6 +10210,11 @@ gimplify_adjust_omp_clauses_1 (splay_tre
return 0;
}
   code = OMP_CLAUSE_SHARED;
+  /* Don't optimize shared into firstprivate for read-only vars
+on tasks with depend clause, we shouldn't try to copy them
+until the dependencies are satisfied.  */
+  if (gimplify_omp_ctxp->has_depend)
+   flags |= GOVD_WRITTEN;
 }
   else if (flags & GOVD_PRIVATE)
 code = OMP_CLAUSE_PRIVATE;
@@ -10494,6 +10502,10 @@ gimplify_adjust_omp_clauses (gimple_seq
  OMP_CLAUSE_SET_CODE (c, OMP_CLAUSE_PRIVATE);
  OMP_CLAUSE_PRIVATE_DEBUG (c) = 1;
}
+  if (OMP_CLAUSE_CODE (c) == OMP_CLAUSE_SHARED
+ && ctx->has_depend
+ && DECL_P (decl))
+   n->value |= GOVD_WRITTEN;
  if (OMP_CLAUSE_CODE (c) == OMP_CLAUSE_SHARED
  && (n->value & GOVD_WRITTEN) == 0
  && DECL_P (decl)
--- libgomp/testsuite/libgomp.c/task-6.c.jj 2020-12-18 16:55:34.422690908 
+0100
+++ libgomp/testsuite/libgomp.c/task-6.c2020-12-18 17:22:02.568615365 
+0100
@@ -0,0 +1,47 @@
+#include 
+#include 
+
+int
+main ()
+{
+  int x = 0, y = 0;
+  #pragma omp parallel shared(x, y)
+  #pragma omp master
+  {
+#pragma omp task depend(out:y) shared(x, y)
+{
+  sleep (1);
+  x = 1;
+  y = 1;
+}
+#pragma omp task depend(inout:y) shared(x, y)
+{
+  if (x != 1 || y != 1)
+   abort ();
+  y++;
+}
+  }
+  if (x != 1 || y != 2)
+abort ();
+  x = 0;
+  y = 0;
+  #pragma omp parallel
+  #pragma omp master
+  {
+#pragma omp task depend(out:y)
+{
+  sleep (1);
+  x = 1;
+  y = 1;
+}
+#pragma omp task depend(inout:y)
+{
+  if (x != 1 || y != 1)
+   abort ();
+  y++;
+}
+  }
+  if (x != 1 || y != 2)
+abort ();
+  return 0;
+}


Jakub

[patch] libstdc++/testsuite: Tweak dg-prune-output regex for out-of-tree contexts

[Olivier Hainque]

Hello,

This patch is a proposal to update the dg-prune-output
regex in 20_util/bind/ref_neg.cc to account for possible
extra subdirs of include/ before reaching "functional"
in out-of-build-tree test runs (c++/10.2.1 in our case).

I noticed only afterwards that many other tests seem to
have adopted a simpler
 
  // { dg-prune-output "include" }

Not entirely sure this would be appropriate here as well.

This variant cures the failures we saw when running tests
from our gcc-10 installed toolchain and I verified that the
test still passes from a build tree on mainline, x86_64-linux
host in both cases.

Is this ok to commit ?

Thanks in advance,

Olivier


2020-12-18  Olivier Hainque  

libstdc++-v3/

* testsuite/20_util/bind/ref_neg.cc: Account for
out-of-build-tree contexts in the dg-prune-output
regexp.

From 8ca4da2b492417752ab1fa7b86b75208ea17adc1 Mon Sep 17 00:00:00 2001
From: Olivier Hainque 
Date: Fri, 18 Dec 2020 18:09:21 +
Subject: [PATCH] Tweak dg-prune-output regex for out-of-tree contexts

libstdc++-v3/

* testsuite/20_util/bind/ref_neg.cc: Tweak
dg-prune-output regex for out-of-tree contexts.
---
 libstdc++-v3/testsuite/20_util/bind/ref_neg.cc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libstdc++-v3/testsuite/20_util/bind/ref_neg.cc 
b/libstdc++-v3/testsuite/20_util/bind/ref_neg.cc
index d77ad90cc253..bf9d3c0b3145 100644
--- a/libstdc++-v3/testsuite/20_util/bind/ref_neg.cc
+++ b/libstdc++-v3/testsuite/20_util/bind/ref_neg.cc
@@ -49,7 +49,8 @@ void test02()
 }
 
 // Ignore the reasons for deduction/substitution failure in the headers.
-// { dg-prune-output "/include/(functional|bits/invoke.h):" }
+// Account for possible extra subdirs in out-of-tree test runs.
+// { dg-prune-output "/include/(c../\[0-9.\]*/)?(functional|bits/invoke.h):" }
 
 int main()
 {
-- 
2.17.1

Re: [RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion)

[abebeos via Gcc-patches]

On Fri, 11 Dec 2020 at 23:20, abebeos 
wrote:

> Στις Παρ, 11 Δεκ 2020 στις 11:00 μ.μ., ο/η Segher Boessenkool <
> seg...@kernel.crashing.org> έγραψε:
>
[...]

> I'd ask the original author, but it seems he's busy with other work, so to
>> > avoid delays...
>>
>> Please try to ask him first?  That is always nice,
>
>
> contacted days ago both authors via email (naturally closing with "feel
> free to  ignore if you're busy"), pip replied, saa not. Though both are on
> the cc of the issue, too.
>
>
>> but you all also need to figure out what to do with the bounty.
>>
>
> Yes, the final "drama", but in the end, the bounty-backers decide about
> any claims.
>
> If they e.g. decide to hand out the bounty to the patch-producer... well.
>

clarification:

patch-producer = patch-author

Me currently anyways more in "want to get this done" (before my attention
> window closes).
>
> Segher
>>
>

Re: [PATCH] avr: cc0 to mode_cc conversion

[abebeos via Gcc-patches]

On Fri, 18 Dec 2020 at 20:31, Segher Boessenkool 
wrote:

> On Fri, Dec 18, 2020 at 06:13:22PM +0100, Georg-Johann Lay wrote:
> > Segher Boessenkool schrieb:
> > >On Thu, Dec 17, 2020 at 10:07:22AM -0500, Paul Koning wrote:
> > >>>On Dec 17, 2020, at 6:21 AM, Segher Boessenkool
> > >>> wrote:
> > >>>On Thu, Dec 17, 2020 at 02:15:51PM +0530, Senthil Kumar Selvaraj via
> > >>>Gcc-patches wrote:
> > The work on my github branch was not complete - I'd blindly followed
> > whatever the CC0 Transition wiki mentioned (the first three steps of
> > case #2), and fixed any regression fallout (for ATmega128).
>
[...]

@Senthil Kumar Selvaraj 

Remember that a full polish of the avr-backend is beyond the scope of the
task/bounty:

avr-cc0 ---[eliminate cc0]---> avr-non-cc0 with similar (or even worse)
quality.

Possibly this one is relevant as for "effort":

https://gcc.gnu.org/pipermail/gcc/2020-April/000455.html
as mentioned here:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c9

Re: [r11-6232 Regression] FAIL: gcc.dg/pr97750.c (test for warnings, line 17) on Linux/x86_64

[Andrew MacLeod via Gcc-patches]

On 12/17/20 1:37 PM, sunil.k.pandey wrote:

On Linux/x86_64,

c25b504636fec7bf8f181a84af83a52757ba7e89 is the first bad commit
commit c25b504636fec7bf8f181a84af83a52757ba7e89
Author: Andrew MacLeod 
Date:   Thu Dec 17 09:24:11 2020 -0500

 Fix trap in pointer conversion in op1_range.

caused

FAIL: gcc.dg/pr97750.c (test for excess errors)
FAIL: gcc.dg/pr97750.c  (test for warnings, line 17)

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-6232/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=gcc.dg/pr97750.c 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=gcc.dg/pr97750.c 
--target_board='unix{-m32\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)



For some reason this configuration produces the warning at a different 
line number.


Fixed by not checking for the warning.. we really just want to make sure 
this compiles to fix the PR.


Pushed.

Andrew

commit 0e9f2b2dc8df91be27acc383c63f0feae28fa229
Author: Andrew MacLeod 
Date:   Fri Dec 18 17:05:18 2020 -0500

Re: [r11-6232 Regression] FAIL: gcc.dg/pr97750.c

Adjust testcase to not actually check for an undefined warning since we
don't really care about it, or what line it is issued on.

gcc/testsuite/
* gcc.dg/pr97750.c: Remove check for warning.

diff --git a/gcc/testsuite/gcc.dg/pr97750.c b/gcc/testsuite/gcc.dg/pr97750.c
index 822b53abcff..90c3dc26852 100644
--- a/gcc/testsuite/gcc.dg/pr97750.c
+++ b/gcc/testsuite/gcc.dg/pr97750.c
@@ -14,8 +14,8 @@ void CopyFromUswc(long src_pitch) {
   for (; CopyFromUswc_height;) {
 unsigned unaligned = (long)CopyFromUswc_src;
 if (unaligned)
-  CopyPlane(&dst[unaligned]);  /* { dg-warning "may be used uninitialized" 
} */
+  CopyPlane(&dst[unaligned]);  
 CopyFromUswc_src += src_pitch;
   }
 }
-
+/* { dg-prune-output "-Wmaybe-uninitialized" } */

Re: [patch] libstdc++/testsuite: Tweak dg-prune-output regex for out-of-tree contexts

[Jonathan Wakely via Gcc-patches]

On 18/12/20 22:06 +0100, Olivier Hainque wrote:

Hello,

This patch is a proposal to update the dg-prune-output
regex in 20_util/bind/ref_neg.cc to account for possible
extra subdirs of include/ before reaching "functional"
in out-of-build-tree test runs (c++/10.2.1 in our case).

I noticed only afterwards that many other tests seem to
have adopted a simpler

 // { dg-prune-output "include" }

Not entirely sure this would be appropriate here as well.

This variant cures the failures we saw when running tests
from our gcc-10 installed toolchain and I verified that the
test still passes from a build tree on mainline, x86_64-linux
host in both cases.

Is this ok to commit ?


Yes, OK, although I wonder if this would be better:

{ dg-prune-output "/(functional|bits/invoke.h):" }

Re: [OG10][committed] Backport openmp: Implicit 'declare target' for C++ static initializers

[Kwok Cheung Yeung]

On 18/12/2020 7:27 pm, Kwok Cheung Yeung wrote:

Hello

I have now backported the "openmp: Implicit 'declare target' for C++ static 
initializers" patch from mainline to the devel/omp/gcc-10 branch. The testcase 
required a small tweak as the gimple output has changed since OG10 was branched.


This has been committed as commit 83797c2d47aaa011b73512f6e86cf6a192cade56.



I have now also backported and committed to OG10 the fix for the testcase (as 
commit a3108e0b52bae3783a705ce38d4a1f82ed3443a2), and a patch required for 
implicit 'declare target' for Fortran (OpenMP: Add implicit declare target for 
nested procedures, as commit c490d85b1722651f0a67b373e5e2a059c4a35abe).


Kwok

[PATCH] diagnostics: Support for -finput-charset [PR93067]

[Lewis Hyatt via Gcc-patches]

Hello-

The attached patch addresses PR93067:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93067#c0

This is similar to the patch I posted last year on the PR, with some tweaks
to make it a little simpler. Recapping some of the commentary on the PR:

When source lines are needed for diagnostics output, they are retrieved from
the source file by the fcache infrastructure in input.c, since libcpp has
generally already forgotten them (plus not all front ends are using
libcpp). This infrastructure does not read the files in the same way as
libcpp does; in particular, it does not translate the encoding as requested
by -finput-charset, and it does not strip a UTF-8 byte-order mark if
present. The patch adds this ability. My thinking in deciding how to do it
was the following:

- Use of -finput-charset is rare, and use of UTF-8 BOMs must be rarer still,
  so this patch should try hard not to introduce any worse performance
  unless these things are needed.

- It is desirable to reuse libcpp's encoding infrastructure from charset.c
  rather than repeat it in input.c. (Notably, libcpp uses iconv but it also
  has hand-coded routines for certain charsets to make sure they are
  available.)

- There is a performance degradation required in order to make use of libcpp
  directly, because the input.c infrastructure only reads as much of the
  source file as necessary, whereas libcpp interfaces as-is require to read
  the entire file into memory.

- It can't be quite as simple as just "only delegate to libcpp if
  -finput-charset was specified", because the stripping of the UTF-8 BOM has
  to happen with or without this option.

- So it seemed a reasonable compromise to me, if -finput-charset is
  specified, then use libcpp to convert the file, otherwise, strip the BOM
  in input.c and then process the file the same way it is done now. There's
  a little bit of leakage of charset logic from libcpp this way (for the
  BOM), but it seems worthwhile, since otherwise, diagnostics would always
  be reading the entire file into memory, which is not a cost paid
  currently.

Separate from the main patch are two testcases that both fail before this
patch and pass after. I attached them gzipped because they use non-standard
encodings that won't email well.

The main question I have about the patch is whether I chose a good way to
address the following complication. location_get_source_line() in input.c is
used to generate diagnostics for all front ends, whether they use libcpp to
read the files or not. So input.c needs some way to know whether libcpp is
in use or not. I ended up adding a new function input_initialize_cpp_context(),
which front ends have to call if they are using libcpp to read their
files. Currently that is c-family and fortran. I don't see a simpler way
to do it at least... Even if there were a better way for input.c to find out
the value passed to -finput-charset, it would still need to know whether
libcpp is being used or not.

Please let me know if it looks OK (either now or for stage 1, whatever makes
sense...) bootstrap + regtest all languages on x86-64 GNU/Linux, all tests the
same before & after plus 6 new PASS from the new tests. Thanks!

-Lewis
Adds the logic to handle -finput-charset in layout_get_source_line(), so that
source lines are converted from their input encodings prior to being output by
diagnostics machinery.

gcc/c-family/ChangeLog:

PR other/93067
* c-opts.c (c_common_post_options): Call new function
input_initialize_cpp_context().

gcc/fortran/ChangeLog:

PR other/93067
* cpp.c (gfc_cpp_post_options): Call new function
input_initialize_cpp_context().

gcc/ChangeLog:

PR other/93067
* input.c (input_initialize_cpp_context): New function.
(read_data): Add prototype.
(add_file_to_cache_tab): Use libcpp to convert input encoding when
needed.
(class fcache): Add new members to track input encoding conversion
via libcpp.
(fcache::fcache): Adapt for new members.
(fcache::~fcache): Likewise.
(maybe_grow): Likewise.
(needs_read): Adapt to be aware that fp member may be NULL now.
(get_next_line): Likewise.
* input.h (struct cpp_reader): Forward declare for use...
(input_initialize_cpp_context): ...here.  Declare new function.

libcpp/ChangeLog:

PR other/93067
* charset.c (init_iconv_desc): Adapt to permit PFILE argument to
be NULL.
(_cpp_convert_input): Likewise. Also move UTF-8 BOM logic to...
(cpp_check_utf8_bom): ...here.  New function.
(cpp_input_conversion_is_trivial): New function.
* files.c (read_file_guts): Allow PFILE argument to be NULL.  Add
INPUT_CHARSET argument as an alternate source of this information.
(cpp_get_converted_source): New function.
* include/cpplib.h (struct cpp_converted_source): Declare.
(cpp_get_converted_source): Declare.

Go patch committed: Check for floating-point exponent overflow

[Ian Lance Taylor via Gcc-patches]

This patch to the Go frontend checks for floating-point exponent
overflow.  Previously we just ignored the error and carried on.  This
forces us to ignore some floating point constants in the mksysinfo and
mkrsysinfo shell scripts, and forces us to update a couple of tests.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
to mainline.

Ian
91ea9a4f1e2a91f8e61a57399f08cf243eceea65
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index 6567db167a2..40242cc6a3f 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-526037336231593939a517b7c0b2892d413adb40
+1317de50147304a226b3ec5c4d81376470c358e5
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
diff --git a/gcc/go/gofrontend/lex.cc b/gcc/go/gofrontend/lex.cc
index e71b8cddf65..0baf4e4e24b 100644
--- a/gcc/go/gofrontend/lex.cc
+++ b/gcc/go/gofrontend/lex.cc
@@ -1316,9 +1316,13 @@ Lex::gather_number()
}
 }
 
+  mpfr_clear_overflow();
   mpfr_t val;
   int r = mpfr_init_set_str(val, num.c_str(), base, MPFR_RNDN);
   go_assert(r == 0);
+  if (mpfr_overflow_p())
+go_error_at(this->location(),
+   "floating-point exponent too large to represent");
 
   bool is_imaginary = *p == 'i';
   if (is_imaginary)
diff --git a/gcc/testsuite/go.test/test/fixedbugs/issue11326b.go 
b/gcc/testsuite/go.test/test/fixedbugs/issue11326b.go
index 8aba4d91215..b5f933bfea1 100644
--- a/gcc/testsuite/go.test/test/fixedbugs/issue11326b.go
+++ b/gcc/testsuite/go.test/test/fixedbugs/issue11326b.go
@@ -1,5 +1,9 @@
 // run
 
+// Does not work with gccgo, which uses a smaller (but still permitted)
+// exponent size.
+// +build !gccgo
+
 // Copyright 2015 The Go Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style
 // license that can be found in the LICENSE file.
diff --git a/gcc/testsuite/go.test/test/fixedbugs/issue13471.go 
b/gcc/testsuite/go.test/test/fixedbugs/issue13471.go
index 9bfc8c3d2cf..9069412ffa6 100644
--- a/gcc/testsuite/go.test/test/fixedbugs/issue13471.go
+++ b/gcc/testsuite/go.test/test/fixedbugs/issue13471.go
@@ -9,17 +9,17 @@
 package main
 
 func main() {
-   const _ int64 = 1e646456992 // ERROR "integer too large|floating-point 
constant truncated to integer"
-   const _ int32 = 1e64645699  // ERROR "integer too large|floating-point 
constant truncated to integer"
-   const _ int16 = 1e6464569   // ERROR "integer too large|floating-point 
constant truncated to integer"
-   const _ int8 = 1e646456 // ERROR "integer too large|floating-point 
constant truncated to integer"
-   const _ int = 1e64645   // ERROR "integer too large|floating-point 
constant truncated to integer"
+   const _ int64 = 1e646456992 // ERROR "integer too large|floating-point 
constant truncated to integer|exponent too large"
+   const _ int32 = 1e64645699  // ERROR "integer too large|floating-point 
constant truncated to integer|exponent too large"
+   const _ int16 = 1e6464569   // ERROR "integer too large|floating-point 
constant truncated to integer|exponent too large"
+   const _ int8 = 1e646456 // ERROR "integer too large|floating-point 
constant truncated to integer|exponent too large"
+   const _ int = 1e64645   // ERROR "integer too large|floating-point 
constant truncated to integer|exponent too large"
 
-   const _ uint64 = 1e646456992 // ERROR "integer too large|floating-point 
constant truncated to integer"
-   const _ uint32 = 1e64645699  // ERROR "integer too large|floating-point 
constant truncated to integer"
-   const _ uint16 = 1e6464569   // ERROR "integer too large|floating-point 
constant truncated to integer"
-   const _ uint8 = 1e646456 // ERROR "integer too large|floating-point 
constant truncated to integer"
-   const _ uint = 1e64645   // ERROR "integer too large|floating-point 
constant truncated to integer"
+   const _ uint64 = 1e646456992 // ERROR "integer too large|floating-point 
constant truncated to integer|exponent too large"
+   const _ uint32 = 1e64645699  // ERROR "integer too large|floating-point 
constant truncated to integer|exponent too large"
+   const _ uint16 = 1e6464569   // ERROR "integer too large|floating-point 
constant truncated to integer|exponent too large"
+   const _ uint8 = 1e646456 // ERROR "integer too large|floating-point 
constant truncated to integer|exponent too large"
+   const _ uint = 1e64645   // ERROR "integer too large|floating-point 
constant truncated to integer|exponent too large"
 
-   const _ rune = 1e64645 // ERROR "integer too large|floating-point 
constant truncated to integer"
+   const _ rune = 1e64645 // ERROR "integer too large|floating-point 
constant truncated to integer|exponent too large"
 }
diff --git a/libgo/mkrsysinfo.sh b/libgo/mkrsysinfo.sh
index c28f0e5f1f6..e016ca4dc59 100755
--- a/libgo/mkrsysinfo.sh
+++ b/l

[PATCH] store VLA bounds in attribute access as strings (PR 97172)

[Martin Sebor via Gcc-patches]

To keep tree expressions stored by the front end in attribute
access for nontrivial VLA bounds from getting corrupted during
Gimplification and to avoid breaking the preconditions verified
by the LTO streamer that no such trees exist in the IL,
the attached patch replaces those bounds with a string
representation of those expressions (as STRING_CST).  It also
tweaks the pretty-printer to improve the formatting of the VLA
bounds and avoid inserting spurious spaces in some cases.

The strings are only used by the front end to verify that
redeclarations of the same function match in the form and bounds
of their VLA arguments, and they're not needed in the middle end.
I considered removing them just before the front end finishes but
I couldn't find an efficient way to do that.  Is there some data
structure that stores all function declarations in a translation
unit?  If there is, then traversing it and removing the attribute
arguments might also be an option, either in addition to this
change or in lieu of it.

The patch was tested on x86_64-linux.

Martin
Store nontrivial VLA bounds as strings (PR c/97172).

gcc/ChangeLog

	PR c/97172
	* attribs.c (attr_access::array_as_string): Handle VLA bounds
	represented as strings.
	* pretty-print.c (pp_string): Add argument and use it.
	* pretty-print.h (pp_string): Add default argument.
	* tree-pretty-print.c (print_generic_expr_to_string_cst): Define.
	(dump_generic_node): Avoid printing spurious space; parenthesize
	operands to avoid three consecutive minus signs.
	(op_symbol_code):
	* tree-pretty-print.h (print_generic_expr_to_string_cst): New.
	* tree.c (array_bound_from_maxval): Define.
	* tree.h (array_bound_from_maxval): New.

gcc/c-family/ChangeLog:

	PR c/97172
	* c-attribs.c (handle_argspec_attribute): Handle VLA bounds
	represented as strings.
	(build_attr_access_from_parms): Adjust comment.
	* c-pretty-print.c (c_pretty_printer::direct_abstract_declarator):
	Call array_bound_from_maxval.
	* c-warn.c (warn_parm_array_mismatch): Handle VLA bounds represented
	as strings.

gcc/c/ChangeLog:

	PR c/97172
	* c-decl.c (get_parm_array_spec): Store nontrivial VLA bounds as
	strings.

gcc/testsuite/ChangeLog:

	PR c/97172
	* gcc.dg/Wvla-parameter-2.c: Adjust text of expected warning.
	* gcc.dg/Wvla-parameter-9.c: New test.

diff --git a/gcc/attribs.c b/gcc/attribs.c
index a6f6b70e39e..8803e0e7260 100644
--- a/gcc/attribs.c
+++ b/gcc/attribs.c
@@ -2257,6 +2257,9 @@ attr_access::array_as_string (tree type) const
   if (type == error_mark_node)
 return std::string ();
 
+  /* The most significant bound of a VLA as a PARM_DECL or VAR_DECL,
+ or STRING_CST for expressions, or null.  */
+  tree bound = NULL_TREE;
   if (this->str)
 {
   /* For array parameters (but not pointers) create a temporary array
@@ -2275,15 +2278,20 @@ attr_access::array_as_string (tree type) const
 	  const char *p = end;
 	  for ( ; p != str && *p-- != ']'; );
 	  if (*p == '$')
-	index_type = build_index_type (TREE_VALUE (size));
+	{
+	  bound = TREE_VALUE (size);
+	  if (DECL_P (bound))
+		index_type = build_index_type (bound);
+	}
 	}
   else if (minsize)
 	index_type = build_index_type (size_int (minsize - 1));
 
   tree arat = NULL_TREE;
-  if (static_p || vla_p)
+  if ((static_p || vla_p))
 	{
-	  tree flag = static_p ? integer_one_node : NULL_TREE;
+	  tree flag = (static_p && (!bound || DECL_P (bound))
+		   ? integer_one_node : NULL_TREE);
 	  /* Hack: there's no language-independent way to encode
 	 the "static" specifier or the "*" notation in an array type.
 	 Add a "fake" attribute to have the pretty-printer add "static"
@@ -2307,6 +2315,21 @@ attr_access::array_as_string (tree type) const
   typstr = pp_formatted_text (pp);
   delete pp;
 
+  if (bound && TREE_CODE (bound) == STRING_CST)
+{
+  /* For the most significant bound that's not a DECL and that's
+	 stored as a STRING_CST, replace the asterisk in the first [*]
+	 it was formatted as, or the first "static", with its human-
+	 readable representation.  */
+  size_t pos = typstr.find ("[*]", 0);
+  if (static_p)
+	{
+	  typstr.replace (pos + 1, 1, "static  ");
+	  pos += 7;
+	}
+  typstr.replace (pos + 1, 1, TREE_STRING_POINTER (bound));
+}
+
   return typstr;
 }
 
diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c
index 29e26728300..40d6389102f 100644
--- a/gcc/c-family/c-attribs.c
+++ b/gcc/c-family/c-attribs.c
@@ -3539,7 +3539,7 @@ handle_argspec_attribute (tree *, tree, tree args, int, bool *)
   for (tree next = TREE_CHAIN (args); next; next = TREE_CHAIN (next))
 {
   tree val = TREE_VALUE (next);
-  gcc_assert (DECL_P (val) || EXPR_P (val));
+  gcc_assert (DECL_P (val) || TREE_CODE (val) == STRING_CST);
 }
   return NULL_TREE;
 }
@@ -4910,7 +4910,7 @@ tree
 build_attr_access_from_parms (tree parms, bool skip_voidptr)
 {
   /* Maps each named integral argument DECL seen so far to its position
- i

[r11-6257 Regression] FAIL: g++.dg/gomp/declare-target-3.C -std=c++98 scan-assembler \\.offload_var_table:\\n.+\\.quad\\s+g on Linux/x86_64

[sunil.k.pandey via Gcc-patches]

On Linux/x86_64,

3af02d32cce2ff1ff11d078cf8094305f57ca179 is the first bad commit
commit 3af02d32cce2ff1ff11d078cf8094305f57ca179
Author: Kwok Cheung Yeung 
Date:   Fri Dec 18 08:26:34 2020 -0800

openmp: Implicitly add 'declare target' directives for dynamic initializers 
in C++

caused

FAIL: g++.dg/gomp/declare-target-3.C  -std=c++14  scan-assembler 
\\.offload_var_table:\\n.+\\.quad\\s+b
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++14  scan-assembler 
\\.offload_var_table:\\n.+\\.quad\\s+c
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++14  scan-assembler 
\\.offload_var_table:\\n.+\\.quad\\s+d
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++14  scan-assembler 
\\.offload_var_table:\\n.+\\.quad\\s+e
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++14  scan-assembler 
\\.offload_var_table:\\n.+\\.quad\\s+f
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++14  scan-assembler 
\\.offload_var_table:\\n.+\\.quad\\s+g
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++17  scan-assembler 
\\.offload_var_table:\\n.+\\.quad\\s+b
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++17  scan-assembler 
\\.offload_var_table:\\n.+\\.quad\\s+c
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++17  scan-assembler 
\\.offload_var_table:\\n.+\\.quad\\s+d
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++17  scan-assembler 
\\.offload_var_table:\\n.+\\.quad\\s+e
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++17  scan-assembler 
\\.offload_var_table:\\n.+\\.quad\\s+f
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++17  scan-assembler 
\\.offload_var_table:\\n.+\\.quad\\s+g
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++2a  scan-assembler 
\\.offload_var_table:\\n.+\\.quad\\s+b
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++2a  scan-assembler 
\\.offload_var_table:\\n.+\\.quad\\s+c
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++2a  scan-assembler 
\\.offload_var_table:\\n.+\\.quad\\s+d
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++2a  scan-assembler 
\\.offload_var_table:\\n.+\\.quad\\s+e
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++2a  scan-assembler 
\\.offload_var_table:\\n.+\\.quad\\s+f
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++2a  scan-assembler 
\\.offload_var_table:\\n.+\\.quad\\s+g
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++98  scan-assembler 
\\.offload_var_table:\\n.+\\.quad\\s+b
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++98  scan-assembler 
\\.offload_var_table:\\n.+\\.quad\\s+c
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++98  scan-assembler 
\\.offload_var_table:\\n.+\\.quad\\s+d
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++98  scan-assembler 
\\.offload_var_table:\\n.+\\.quad\\s+e
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++98  scan-assembler 
\\.offload_var_table:\\n.+\\.quad\\s+f
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++98  scan-assembler 
\\.offload_var_table:\\n.+\\.quad\\s+g

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-6257/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="gomp.exp=g++.dg/gomp/declare-target-3.C 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="gomp.exp=g++.dg/gomp/declare-target-3.C 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="gomp.exp=g++.dg/gomp/declare-target-3.C 
--target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="gomp.exp=g++.dg/gomp/declare-target-3.C 
--target_board='unix{-m64\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

Re: [PATCH] store VLA bounds in attribute access as strings (PR 97172)

[Richard Biener via Gcc-patches]

On December 19, 2020 1:55:02 AM GMT+01:00, Martin Sebor via Gcc-patches 
 wrote:
>To keep tree expressions stored by the front end in attribute
>access for nontrivial VLA bounds from getting corrupted during
>Gimplification and to avoid breaking the preconditions verified
>by the LTO streamer that no such trees exist in the IL,
>the attached patch replaces those bounds with a string
>representation of those expressions (as STRING_CST).  It also
>tweaks the pretty-printer to improve the formatting of the VLA
>bounds and avoid inserting spurious spaces in some cases.
>
>The strings are only used by the front end to verify that
>redeclarations of the same function match in the form and bounds
>of their VLA arguments, and they're not needed in the middle end.
>I considered removing them just before the front end finishes but
>I couldn't find an efficient way to do that.  Is there some data
>structure that stores all function declarations in a translation
>unit?  If there is, then traversing it and removing the attribute
>arguments might also be an option, either in addition to this
>change or in lieu of it.

There is the free lang data pass in tree.c which walks all reachable tree 
nodes. 

>The patch was tested on x86_64-linux.
>
>Martin