Re: [PATCH] Remove misleading debug line entries

[Richard Biener]

On Wed, 2 Dec 2020, Bernd Edlinger wrote:

> On 12/2/20 8:50 AM, Richard Biener wrote:
> > On Tue, 1 Dec 2020, Bernd Edlinger wrote:
> > 
> >> Hi!
> >>
> >>
> >> This removes gimple_debug stmts without block info after a
> >> NULL INLINE_ENTRY.
> >>
> >> The line numbers from these stmts are from the inline function,
> >> but since the inline function is completely optimized away,
> >> there will be no DW_TAG_inlined_subroutine so the debugger has
> >> no callstack available at this point, and therefore those
> >> line table entries are not helpful to the user.
> >>
> >> 2020-11-20  Bernd Edlinger  
> >>
> >>* cfgexpand.c (expand_gimple_basic_block): Remove debug_begin_stmts
> >>following a removed debug_inline_entry.
> >>
> >>
> >> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
> >> Is it OK for trunk?
> > 
> > So are those visited by clear_unused_block_pointer?  If so wouldn't
> > it be more appropriate to remove those there, when we elide the
> > inlined block scope?
> > 
> 
> That's what I thought initially, but that is only true for 99% of the 
> inline statements.  However 1% of the inline_entries without block info,
> and debug_begin_stmts without block info, that have line numbers from
> an inline header, do actually originate here:
> 
> copy_debug_stmt (gdebug *stmt, copy_body_data *id)
> {
>   tree t, *n;
>   struct walk_stmt_info wi;
> 
>   if (tree block = gimple_block (stmt))
> {
>   n = id->decl_map->get (block);
>   gimple_set_block (stmt, n ? *n : id->block);
> }
> 
> because id->block is NULL, and decl_map does not have
> an entry.
> 
> So I tracked it down why that happens.
> 
> I think remap_gimple_stmt should just drop those nonbind markers
> on the floor when the call statement has no block information.
> 
> Once that is fixed, the special handling of inline entries without
> block info can as well be moved from remap_gimple_stmt to
> clear_unused_block_pointer.
> 
> What do you think of this (not yet fully tested) patch?
> 
> Is it OK when bootstrap and reg-testing passes?

diff --git a/gcc/tree-inline.c b/gcc/tree-inline.c
index d9814bd..e87c653 100644
--- a/gcc/tree-inline.c
+++ b/gcc/tree-inline.c
@@ -1819,7 +1819,8 @@ remap_gimple_stmt (gimple *stmt, copy_body_data *id)
  /* If the inlined function has too many debug markers,
 don't copy them.  */
  if (id->src_cfun->debug_marker_count
- > param_max_debug_marker_count)
+ > param_max_debug_marker_count
+ || !id->block)
return stmts;

Isn't this overly pessimistic in throwing away all debug markers
of an inline rather than just those which are associated with
the outermost scope (that's mapped to NULL if !id->block)?  Can
we instead remap the block here (move it from copy_debug_stmt)
and elide the copy only when it maps to NULL?


  gdebug *copy = as_a  (gimple_copy (stmt));
diff --git a/gcc/tree-ssa-live.c b/gcc/tree-ssa-live.c
index 21a9ee4..ca119c6 100644
--- a/gcc/tree-ssa-live.c
+++ b/gcc/tree-ssa-live.c
@@ -623,13 +623,25 @@ clear_unused_block_pointer (void)
   {
unsigned i;
tree b;
-   gimple *stmt = gsi_stmt (gsi);
+   gimple *stmt;
 
+  next:
+   stmt = gsi_stmt (gsi);
if (!is_gimple_debug (stmt) && !gimple_clobber_p (stmt))
  continue;
b = gimple_block (stmt);
if (b && !TREE_USED (b))
- gimple_set_block (stmt, NULL);
+ {
+   if (gimple_debug_nonbind_marker_p (stmt)
+   && BLOCK_ABSTRACT_ORIGIN (b))

why only for inlined BLOCKs?  Did you want to restrict it further
to inlined_function_outer_scope_p?

I guess I don't understand the debug situation fully - I guess it is
about jumping to locations in inlines where the call stack does
not show we are in the actual inlined function?  But IIRC at least
unused BLOCK removal never elides the actual 
inlined_function_outer_scope_p which would leave the inlining case
you spotted.  But there we should zap all markers that belong to
the inlined function but not those which belong to another inline
instance?  So we want to walk BLOCK_SUPERCONTEXT until we hit
an inlined_function_outer_scope_p where we don't want to zap
or the inlined functions outermost scope where we do want to zap
(if the call stmt has a NULL block)?

+ {
+   gsi_remove (&gsi, true);
+   if (gsi_end_p (gsi))
+ break;



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

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

Re: How to traverse all the local variables that declared in the current routine?

[Richard Biener via Gcc-patches]

On Wed, Dec 2, 2020 at 4:36 PM Qing Zhao  wrote:
>
>
>
> On Dec 2, 2020, at 2:45 AM, Richard Biener  wrote:
>
> On Tue, Dec 1, 2020 at 8:49 PM Qing Zhao  wrote:
>
>
> Hi, Richard,
>
> Could you please comment on the following approach:
>
> Instead of adding the zero-initializer quite late at the pass “pass_expand”, 
> we can add it as early as during gimplification.
> However, we will mark these new added zero-initializers as “artificial”. And 
> passing this “artificial” information to
> “pass_early_warn_uninitialized” and “pass_late_warn_uninitialized”, in these 
> two uninitialized variable analysis passes,
> (i.e., in tree-sea-uninit.c) We will update the checking on 
> “ssa_undefined_value_p”  to consider “artificial” zero-initializers.
> (i.e, if the def_stmt is marked with “artificial”, then it’s a undefined 
> value).
>
> With such approach, we should be able to address all those conflicts.
>
> Do you see any obvious issue with this approach?
>
>
> Yes, DSE will happily elide an explicit zero-init following the
> artificial one leading to false uninit diagnostics.
>
>
> Indeed.  This is a big issue. And other optimizations might also be impacted 
> by the new zero-init, resulting changed behavior
> of uninitialized analysis in the later stage.

I don't see how the issue can be resolved, you can't get both, uninit
warnings and no uninitialized memory.
People can compile twice, once without -fzero-init to get uninit
warnings and once with -fzero-init to get
the extra "security".

Richard.

>
> What's the intended purpose of the zero-init?
>
>
>
> The purpose of this new option is: (from the original LLVM patch submission):
>
> "Add an option to initialize automatic variables with either a pattern or with
> zeroes. The default is still that automatic variables are uninitialized. Also
> add attributes to request uninitialized on a per-variable basis, mainly to 
> disable
> initialization of large stack arrays when deemed too expensive.
>
> This isn't meant to change the semantics of C and C++. Rather, it's meant to 
> be
> a last-resort when programmers inadvertently have some undefined behavior in
> their code. This patch aims to make undefined behavior hurt less, which
> security-minded people will be very happy about. Notably, this means that
> there's no inadvertent information leak when:
>
> • The compiler re-uses stack slots, and a value is used uninitialized.
> • The compiler re-uses a register, and a value is used uninitialized.
> • Stack structs / arrays / unions with padding are copied.
> This patch only addresses stack and register information leaks. There's many
> more infoleaks that we could address, and much more undefined behavior that
> could be tamed. Let's keep this patch focused, and I'm happy to address 
> related
> issues elsewhere."
>
> For more details, please refer to the LLVM code review discussion on this 
> patch:
> https://reviews.llvm.org/D54604
>
>
> I also wrote a simple writeup for this task based on my study and discussion 
> with
> Kees Cook (cc’ing him) as following:
>
>
> thanks.
>
> Qing
>
> Support stack variables auto-initialization in GCC
>
> 11/19/2020
>
> Qing Zhao
>
> ===
>
>
> ** Background of the task:
>
> The correponding GCC bugzilla RFE was created on 9/3/2018:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87210
>
> A similar option for LLVM (around Nov, 2018)
> https://lists.llvm.org/pipermail/cfe-dev/2018-November/060172.html
> had invoked a lot of discussion before committed.
>
> (The following are quoted from the comments of Alexander Potapenko in
> GCC bug 87210):
>
> Finally, on Oct, 2019, upstream Clang supports force initialization
> of stack variables under the -ftrivial-auto-var-init flag.
>
> -ftrivial-auto-var-init=pattern initializes local variables with a 0xAA 
> pattern
> (actually it's more complicated, see https://reviews.llvm.org/D54604)
>
> -ftrivial-auto-var-init=zero provides zero-initialization of locals.
> This mode isn't officially supported yet and is hidden behind an additional
> -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang flag.
> This is done to avoid creating a C++ dialect where all variables are
> zero-initialized.
>
> Starting v5.2, Linux kernel has a CONFIG_INIT_STACK_ALL config that performs
> the build  with -ftrivial-auto-var-init=pattern. This one isn't widely adopted
> yet, partially because initializing locals with 0xAA isn't fast enough.
>
> Linus Torvalds is quite positive about zero-initializing the locals though,
> see https://lkml.org/lkml/2019/7/30/1303:
>
> "when a compiler has an option to initialize stack variables, it
> would probably _also_ be a very good idea for that compiler to then
> support a variable attribute that says "don't initialize _this_
> variable, I will do that manually".
> I also think that the "initialize with poison" is
> pointless and wrong. Yes, it can find bugs, but it doesn't really help
> improve the gen

Re: [GCC 10 PATCH] expr: Fix REDUCE_BIT_FIELD for constants [PR95694]

[Richard Biener via Gcc-patches]

On Wed, Dec 2, 2020 at 5:31 PM Richard Sandiford via Gcc-patches
 wrote:
>
> This is a gcc-10 version of:
>
> Richard Sandiford  writes:
> > [Sorry, been sitting on this patch for a while and just realised
> >  I never sent it.]
> >
> > This is yet another PR caused by constant integer rtxes not storing
> > a mode.  We were calling REDUCE_BIT_FIELD on a constant integer that
> > didn't fit in poly_int64, and then tripped the as_a
> > assert on VOIDmode.
> >
> > AFAICT REDUCE_BIT_FIELD is always passed rtxes that have TYPE_MODE
> > (rather than some other mode) and it just fills in the redundant
> > sign bits of that TYPE_MODE value.  So it should be safe to get
> > the mode from the type instead of the rtx.  The patch does that
> > and asserts that the modes agree, where information is available.
> >
> > That on its own is enough to fix the bug, but we might as well
> > extend the folding case to all constant integers, not just those
> > that fit poly_int64.
> >
> > Tested on aarch64-linux-gnu and x86_64-linux-gnu.  OK to trunk
> > and release branches?
>
> The mainline patch ended up causing PR96151, so this patch folds
> in the fix for that.  It also avoids some C++11-isms.
>
> Tested on aarch64-linux-gnu, aarch64_be-elf, arm-linux-gnueabihf,
> armeb-elf and x86_64-linux-gnu.  OK for GCC 10?

OK.

> (I didn't include PR96151 in the changelog since it's no longer
> a live bug.)
>
> Richard
>
>
> gcc/
> PR middle-end/95694
> * expr.c (expand_expr_real_2): Get the mode from the type rather
> than the rtx, and assert that it is consistent with the mode of
> the rtx (where known).  Optimize all constant integers, not just
> those that can be represented in poly_int64.
>
> gcc/testsuite/
> PR middle-end/95694
> * gcc.dg/pr95694.c: New test.
>
> (cherry picked from commit 760df6d296b8fc59796f42dca5eb14012fbfa28b)
> ---
>  gcc/expr.c | 19 ++-
>  gcc/testsuite/gcc.dg/pr95694.c | 23 +++
>  2 files changed, 33 insertions(+), 9 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.dg/pr95694.c
>
> diff --git a/gcc/expr.c b/gcc/expr.c
> index 6dfee6627a3..991b26f3341 100644
> --- a/gcc/expr.c
> +++ b/gcc/expr.c
> @@ -8560,7 +8560,9 @@ expand_expr_real_2 (sepops ops, rtx target, 
> machine_mode tmode,
>reduce_bit_field = (INTEGRAL_TYPE_P (type)
>   && !type_has_mode_precision_p (type));
>
> -  if (reduce_bit_field && modifier == EXPAND_STACK_PARM)
> +  if (reduce_bit_field
> +  && (modifier == EXPAND_STACK_PARM
> + || (target && GET_MODE (target) != mode)))
>  target = 0;
>
>/* Use subtarget as the target for operand 0 of a binary operation.  */
> @@ -11434,26 +11436,25 @@ expand_expr_real_1 (tree exp, rtx target, 
> machine_mode tmode,
>  static rtx
>  reduce_to_bit_field_precision (rtx exp, rtx target, tree type)
>  {
> +  scalar_int_mode mode = SCALAR_INT_TYPE_MODE (type);
>HOST_WIDE_INT prec = TYPE_PRECISION (type);
> -  if (target && GET_MODE (target) != GET_MODE (exp))
> -target = 0;
> -  /* For constant values, reduce using build_int_cst_type. */
> -  poly_int64 const_exp;
> -  if (poly_int_rtx_p (exp, &const_exp))
> +  gcc_assert ((GET_MODE (exp) == VOIDmode || GET_MODE (exp) == mode)
> + && (!target || GET_MODE (target) == mode));
> +
> +  /* For constant values, reduce using wide_int_to_tree. */
> +  if (poly_int_rtx_p (exp))
>  {
> -  tree t = build_int_cst_type (type, const_exp);
> +  tree t = wide_int_to_tree (type, wi::to_poly_wide (exp, mode));
>return expand_expr (t, target, VOIDmode, EXPAND_NORMAL);
>  }
>else if (TYPE_UNSIGNED (type))
>  {
> -  scalar_int_mode mode = as_a  (GET_MODE (exp));
>rtx mask = immed_wide_int_const
> (wi::mask (prec, false, GET_MODE_PRECISION (mode)), mode);
>return expand_and (mode, exp, mask, target);
>  }
>else
>  {
> -  scalar_int_mode mode = as_a  (GET_MODE (exp));
>int count = GET_MODE_PRECISION (mode) - prec;
>exp = expand_shift (LSHIFT_EXPR, mode, exp, count, target, 0);
>return expand_shift (RSHIFT_EXPR, mode, exp, count, target, 0);
> diff --git a/gcc/testsuite/gcc.dg/pr95694.c b/gcc/testsuite/gcc.dg/pr95694.c
> new file mode 100644
> index 000..6f5e1900a02
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/pr95694.c
> @@ -0,0 +1,23 @@
> +/* PR tree-optimization/68835 */
> +/* { dg-do run { target int128 } } */
> +/* { dg-options "-fno-tree-forwprop -fno-tree-ccp -O1 
> -fno-tree-dominator-opts -fno-tree-fre" } */
> +
> +__attribute__((noinline, noclone)) unsigned __int128
> +foo (void)
> +{
> +  unsigned __int128 x = (unsigned __int128) 0xULL;
> +  struct { unsigned __int128 a : 65; } w;
> +  w.a = x;
> +  w.a += x;
> +  return w.a;
> +}
> +
> +int
> +main ()
> +{
> +  unsigned __int128 x = foo ();
> +  if ((unsigned long long) x != 0xfffeULL
> +  || (unsigned l

[PATCH] i386: Fix up ix86_md_asm_adjust for TImode [PR98086]

[Jakub Jelinek via Gcc-patches]

Hi!

ix86_md_asm_adjust right above this code uses:
  machine_mode dest_mode = GET_MODE (dest);
  if (!SCALAR_INT_MODE_P (dest_mode))
{
  error ("invalid type for % flag output");
  continue;
}
but then assumes that dest_mode can be only [QHSD]Imode and nothing else.

The following patch handles TImode and hypothetically even wider modes
by handling it like DImode for 32-bit.

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

2020-12-03  Jakub Jelinek  

PR target/98086
* config/i386/i386.c (ix86_md_asm_adjust): Use dest_mode DImode
or SImode for modes wider than DImode.  If dest_mode isn't SImode
or GET_MODE (dest) isn't DImode, use convert_to_mode.

* gcc.target/i386/pr98086.c: New test.

--- gcc/config/i386/i386.c.jj   2020-11-18 09:40:09.498664422 +0100
+++ gcc/config/i386/i386.c  2020-12-02 15:33:26.224184113 +0100
@@ -21508,6 +21508,8 @@ ix86_md_asm_adjust (vec &outputs, v
  continue;
}
 
+  if (GET_MODE_BITSIZE (dest_mode) > GET_MODE_BITSIZE (DImode))
+   dest_mode = DImode;
   if (dest_mode == DImode && !TARGET_64BIT)
dest_mode = SImode;
 
@@ -21534,10 +21536,16 @@ ix86_md_asm_adjust (vec &outputs, v
 
   if (dest_mode != GET_MODE (dest))
{
- rtx tmp = gen_reg_rtx (SImode);
+ rtx tmp = gen_reg_rtx (dest_mode);
 
  emit_insn (gen_rtx_SET (tmp, x));
- emit_insn (gen_zero_extendsidi2 (dest, tmp));
+ if (dest_mode == SImode && GET_MODE (dest) == DImode)
+   emit_insn (gen_zero_extendsidi2 (dest, tmp));
+ else
+   {
+ tmp = convert_to_mode (GET_MODE (dest), tmp, 1);
+ emit_insn (gen_rtx_SET (dest, tmp));
+   }
}
   else
emit_insn (gen_rtx_SET (dest, x));
--- gcc/testsuite/gcc.target/i386/pr98086.c.jj  2020-12-02 15:36:40.858951118 
+0100
+++ gcc/testsuite/gcc.target/i386/pr98086.c 2020-12-02 15:37:27.305406401 
+0100
@@ -0,0 +1,10 @@
+/* PR target/98086 */
+/* { dg-do compile { target int128 } } */
+
+__int128_t x;
+
+void
+foo (void)
+{
+  __asm ("" : "=@ccc" (x));
+}

Jakub

[committed] testsuite: Add testcase for already fixed PR [PR98104]

[Jakub Jelinek via Gcc-patches]

Hi!

This testcase got broken with r11-3826 and got fixed with r11-5628.

Tested on x86_64-linux -m32/-m64 with current trunk as well as 4 days old
compiler, committed to trunk as obvious.

2020-12-03  Jakub Jelinek  

PR c++/98104
* g++.dg/warn/pr98104.C: New test.

--- gcc/testsuite/g++.dg/warn/pr98104.C
+++ gcc/testsuite/g++.dg/warn/pr98104.C
@@ -0,0 +1,20 @@
+// PR c++/98104
+
+#include 
+
+struct B
+{
+  B ();
+  int *a;
+  char b;
+};
+
+struct D : public B {};
+void bar (B *);
+
+void
+foo ()
+{
+  D d;
+  bar (::new (static_cast(&d)) B); // { dg-bogus "placement new 
constructing an object of type 'B' and size '\[0-9]*' in a region of type 'B' 
and size '\[0-9]*'" }
+}

Jakub

RE: [PATCH][GCC] aarch64: Add +flagm to -march

[Przemyslaw Wirkus via Gcc-patches]

> >> gcc/ChangeLog:
> >>
> >> * config/aarch64/aarch64-option-extensions.def
> >> (AARCH64_OPT_EXTENSION): New +flagm option in -march for AArch64.
> >> * config/aarch64/aarch64.h (AARCH64_FL_FLAGM): Add new flagm
> >> extension bit mask.
> >> (AARCH64_FL_FOR_ARCH8_4): Add flagm to Armv8.4-A.
> >
> > OK, thanks, and sorry for the slow review.
> 
> Just remembered that we also need documentation for the new feature flag in
> doc/invoke.texi.

Done. Thank you for the reminder.

commit 48ff86adfd96a0f5132273719932b48a14941881

> Thanks,
> Richard

[PATCH] c++: consteval-defarg1.C test variant for templates

[Jakub Jelinek via Gcc-patches]

On Wed, Dec 02, 2020 at 10:15:25PM -0500, Jason Merrill wrote:
> Jakub noticed that we weren't recognizing a default argument for a consteval
> member function as being in immediate function context because there was no
> function parameter scope to look at.
> 
> Note that this patch doesn't actually push the parameters into the scope,
> that happens in a separate commit.

Shouldn't we also be testing how it behaves in templates?

The following testcase is an attempt to test both non-dependent and
dependent consteval calls in both function and class templates, and with
your committed patch it now passes.

Ok for trunk?

2020-12-03  Jakub Jelinek  

* g++.dg/cpp2a/consteval-defarg2.C: New test.

--- gcc/testsuite/g++.dg/cpp2a/consteval-defarg2.C.jj   2020-12-03 
10:26:16.340256056 +0100
+++ gcc/testsuite/g++.dg/cpp2a/consteval-defarg2.C  2020-12-03 
10:19:33.215853790 +0100
@@ -0,0 +1,29 @@
+// Test that late-parsed default args have the same consteval semantics.
+// { dg-do compile { target c++20 } }
+
+template 
+consteval bool foo (bool x) { if (x) throw N; return false; }
+consteval bool qux (bool x) { if (x) throw 1; return false; }
+template 
+consteval bool bar (bool x = foo (true)) { return true; }
+template 
+consteval bool corge (bool x = qux (true)) { return true; }
+template 
+struct S
+{
+  consteval static bool baz (bool x = foo (true)) { return true; }
+  consteval static bool garply (bool x = qux (true)) { return true; }
+};
+struct T
+{
+  template 
+  consteval static bool baz (bool x = foo (true)) { return true; }
+  template 
+  consteval static bool garply (bool x = qux (true)) { return true; }
+};
+constexpr bool a = bar<0> (true);
+constexpr bool b = corge<0> (true);
+constexpr bool c = S<0>::baz (true);
+constexpr bool d = S<0>::garply (true);
+constexpr bool e = T::baz<0> (true);
+constexpr bool f = T::garply<0> (true);


Jakub

Re: [PATCH RESEND] tree-ssa-threadbackward.c (profitable_jump_thread_path): Do not allow __builtin_constant_p.

[Ilya Leoshkevich via Gcc-patches]

On Wed, 2020-12-02 at 11:42 -0700, Jeff Law wrote:
> 
> On 12/1/20 7:09 PM, Ilya Leoshkevich wrote:
> > On Tue, 2020-12-01 at 15:34 -0700, Jeff Law wrote:
> > > No strong opinions.  I think whichever is less invasive in terms
> > > of
> > > code
> > > quality is probably the way to go.  What we want to avoid is
> > > suppressing
> > > threading unnecessarily as that often leads to false positives
> > > from
> > > middle-end based warnings.  Suppressing threading can also lead
> > > to
> > > build
> > > failures in the kernel due to the way they use b_c_p.
> > I think v1 is better then.  Would you mind approving the following?
> > That's the same code as in v1, but with the improved commit message
> > and
> > comments.
> > 
> > 
> > 
> > Linux Kernel (specifically, drivers/leds/trigger/ledtrig-cpu.c)
> > build
> > with GCC 10 fails on s390 with "impossible constraint".
> > 
> > Explanation by Jeff Law:
> > 
> > ```
> > So what we have is a b_c_p at the start of an if-else
> > chain.  Subsequent
> > tests on the "true" arm of the the b_c_p test may throw us off the
> > constant path (because the constants are out of range).  Once all
> > the
> > tests are passed (it's constant and the constant is in range) the
> > true
> > arm's terminal block has a special asm that requires a constant
> > argument.   In the case where we get to the terminal block on the
> > true
> > arm, the argument to the b_c_p is used as the constant argument to
> > the
> > special asm.
> > 
> > At first glace jump threading seems to be doing the right
> > thing.  Except
> > that we end up with two paths to that terminal block with the
> > special
> > asm, one for each of the two constant arguments to the b_c_p call.
> > Naturally since that same value is used in the asm, we have to
> > introduce
> > a PHI to select between them at the head of the terminal
> > block.   Now
> > the argument in the asm is no longer constant and boom we fail.
> > ```
> > 
> > Fix by disallowing __builtin_constant_p on threading paths.
> > 
> > gcc/ChangeLog:
> > 
> > 2020-06-03  Ilya Leoshkevich  
> > 
> > * tree-ssa-threadbackward.c
> > (thread_jumps::profitable_jump_thread_path):
> > Do not allow __builtin_constant_p on a threading path.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > 2020-06-03  Ilya Leoshkevich  
> > 
> > * gcc.target/s390/builtin-constant-p-threading.c: New test.
> OK.  I think the old forward threader has the same problem.  Which I
> think can be fixed by returning NULL from
> record_temporary_equivalences_from_stmts_at_dest when we see the
> B_C_P
> call.  Fixing that in the obvious way is pre-approved once it's gone
> through the usual testing.

Thanks!

I've committed both:

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=70a62009181f66d1d1c90d3c74de38e153c96eb0
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=614aff0adf8fba5d843ec894603160151c20f0aa

Best regards,
Ilya

Re: [PATCH] ipa: do not DECL_IS_MALLOC for void fns

[Martin Liška]

On 12/2/20 4:25 PM, Martin Jambor wrote:

Hi,

On Wed, Dec 02 2020, Jan Hubicka wrote:

We create an IPA SRA (which has DECL_IS_MALLOC set to false), but later
IPA pure const propagates malloc attributes. I think we should not set
it for a void returning functions.

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

Ready to be installed?
Thanks,
Martin

gcc/ChangeLog:

PR ipa/98075
* cgraph.c (cgraph_node::dump): Dump decl_is_malloc flag.
* ipa-pure-const.c (propagate_malloc): Do not set malloc
attribute for void functions.


This is OK, extra credit would be for not collecting state here.  I plan
to avoid stremaing useless pure-const summaries (to fight memory
fragmentation at WPA time) so it would be nice to have an easy way to say that
summary is not interesting.


If I understood Martin's description well, it is an IPA-SRA created
clone that is a void function, not the original.


Yes.


So it is not known
that the information is useless until the WPA stage.


Well, we have a code in ipa_param_adjustments::adjust_decl (tree orig_decl)
where we properly not set DECL_IS_MALLOC.
But later than the info is propagated in IPA pure const. That's why the patch
was needed.



Or do I misunderstand the issue?


Is it explained now?

Thanks,
Martin



Thanks,

Martin

Re: [PATCH][GCC] aarch64: Add +flagm to -march

[Richard Sandiford via Gcc-patches]

Przemyslaw Wirkus  writes:
>> >> gcc/ChangeLog:
>> >>
>> >> * config/aarch64/aarch64-option-extensions.def
>> >> (AARCH64_OPT_EXTENSION): New +flagm option in -march for AArch64.
>> >> * config/aarch64/aarch64.h (AARCH64_FL_FLAGM): Add new flagm
>> >> extension bit mask.
>> >> (AARCH64_FL_FOR_ARCH8_4): Add flagm to Armv8.4-A.
>> >
>> > OK, thanks, and sorry for the slow review.
>> 
>> Just remembered that we also need documentation for the new feature flag in
>> doc/invoke.texi.
>
> Done. Thank you for the reminder.
>
> commit 48ff86adfd96a0f5132273719932b48a14941881

I think you also need to add flagm to:

---
The table below summarizes the permissible values for @var{arch}
and the features that they enable by default:

@multitable @columnfractions 0.20 0.20 0.60
@headitem @var{arch} value @tab Architecture @tab Includes by default
…
@item @samp{armv8.4-a} @tab Armv8.4-A @tab @samp{armv8.3-a}, @samp{+fp16fml}, 
@samp{+dotprod}
---

Thanks,
Richard

RE: [PATCH][GCC] aarch64: Add +flagm to -march

[Przemyslaw Wirkus via Gcc-patches]

> >> >> gcc/ChangeLog:
> >> >>
> >> >> * config/aarch64/aarch64-option-extensions.def
> >> >> (AARCH64_OPT_EXTENSION): New +flagm option in -march for AArch64.
> >> >> * config/aarch64/aarch64.h (AARCH64_FL_FLAGM): Add new flagm
> >> >> extension bit mask.
> >> >> (AARCH64_FL_FOR_ARCH8_4): Add flagm to Armv8.4-A.
> >> >
> >> > OK, thanks, and sorry for the slow review.
> >>
> >> Just remembered that we also need documentation for the new feature
> >> flag in doc/invoke.texi.
> >
> > Done. Thank you for the reminder.
> >
> > commit 48ff86adfd96a0f5132273719932b48a14941881
> 
> I think you also need to add flagm to:
> 
> ---
> The table below summarizes the permissible values for @var{arch} and the
> features that they enable by default:
> 
> @multitable @columnfractions 0.20 0.20 0.60 @headitem @var{arch} value
> @tab Architecture @tab Includes by default … @item @samp{armv8.4-a}
> @tab Armv8.4-A @tab @samp{armv8.3-a}, @samp{+fp16fml},
> @samp{+dotprod}
> ---

Yes, I've just noticed that :/
I will update this with my next patch which adds yet another -march flag if 
that's OK with you?

> Thanks,
> Richard

Re: [PATCH][GCC] aarch64: Add +flagm to -march

[Richard Sandiford via Gcc-patches]

Przemyslaw Wirkus  writes:
>> >> >> gcc/ChangeLog:
>> >> >>
>> >> >> * config/aarch64/aarch64-option-extensions.def
>> >> >> (AARCH64_OPT_EXTENSION): New +flagm option in -march for AArch64.
>> >> >> * config/aarch64/aarch64.h (AARCH64_FL_FLAGM): Add new flagm
>> >> >> extension bit mask.
>> >> >> (AARCH64_FL_FOR_ARCH8_4): Add flagm to Armv8.4-A.
>> >> >
>> >> > OK, thanks, and sorry for the slow review.
>> >>
>> >> Just remembered that we also need documentation for the new feature
>> >> flag in doc/invoke.texi.
>> >
>> > Done. Thank you for the reminder.
>> >
>> > commit 48ff86adfd96a0f5132273719932b48a14941881
>> 
>> I think you also need to add flagm to:
>> 
>> ---
>> The table below summarizes the permissible values for @var{arch} and the
>> features that they enable by default:
>> 
>> @multitable @columnfractions 0.20 0.20 0.60 @headitem @var{arch} value
>> @tab Architecture @tab Includes by default … @item @samp{armv8.4-a}
>> @tab Armv8.4-A @tab @samp{armv8.3-a}, @samp{+fp16fml},
>> @samp{+dotprod}
>> ---
>
> Yes, I've just noticed that :/
> I will update this with my next patch which adds yet another -march flag if 
> that's OK with you?

Yeah, that'd be fine.

Richard

Re: [PR66791][ARM] Replace calls to __builtin_neon_vmvn* by ~ for vmvn intrinsics

[Prathamesh Kulkarni via Gcc-patches]

On Wed, 25 Nov 2020 at 22:01, Prathamesh Kulkarni
 wrote:
>
> Hi,
> This patch replaces calls to __builtin_neon_vmvnv* builtins with ~
> operator in arm_neon.h.
> Cross-tested on arm*-*-*.
> OK to commit ?
ping https://gcc.gnu.org/pipermail/gcc-patches/2020-November/560223.html

Thanks,
Prathamesh
>
> Thanks,
> Prathamesh

RE: [PR66791][ARM] Replace calls to __builtin_neon_vmvn* by ~ for vmvn intrinsics

[Kyrylo Tkachov via Gcc-patches]

> -Original Message-
> From: Gcc-patches  On Behalf Of
> Prathamesh Kulkarni via Gcc-patches
> Sent: 03 December 2020 10:30
> To: gcc Patches ; Kyrill Tkachov
> 
> Subject: Re: [PR66791][ARM] Replace calls to __builtin_neon_vmvn* by ~ for
> vmvn intrinsics
> 
> On Wed, 25 Nov 2020 at 22:01, Prathamesh Kulkarni
>  wrote:
> >
> > Hi,
> > This patch replaces calls to __builtin_neon_vmvnv* builtins with ~
> > operator in arm_neon.h.
> > Cross-tested on arm*-*-*.
> > OK to commit ?

Ok.
Sorry for missing this.
Thanks,
Kyrill

P.S. please use my @arm.com address when CC'ing me, I don't have access to the 
foss.arm.com one currently...

> ping https://gcc.gnu.org/pipermail/gcc-patches/2020-
> November/560223.html
> 
> Thanks,
> Prathamesh
> >
> > Thanks,
> > Prathamesh

Re: introduce overridable clear_cache emitter

[Christophe Lyon via Gcc-patches]

Hi Alexandre,

On Wed, 2 Dec 2020 at 19:23, Jeff Law via Gcc-patches
 wrote:
>
>
>
> On 11/10/20 7:35 PM, Alexandre Oliva wrote:
> > This patch introduces maybe_emit_call_builtin___clear_cache for the
> > builtin expander machinery and the trampoline initializers to use to
> > clear the instruction cache, removing a source of inconsistencies and
> > subtle errors in low-level machinery.
> >
> > I've adjusted all trampoline_init implementations that used to issue
> > explicit calls to __clear_cache or similar to use this new primitive.
> >
> >
> > Specifically on vxworks targets, we needed to drop the __clear_cache
> > symbol in libgcc, for reasons related with linking that I didn't need
> > to understand, and we wanted to call cacheTextUpdate directly, despite
> > the different calling conventions: the second argument is a length
> > rather than the end address.
> >
> > So I introduced a target hook to enable target OS-level overriding of
> > builtin __clear_cache call emission, retaining nearly (*) the same
> > logic to govern the decision on whether to emit a call (or nothing, or
> > a machine-dependent insn) but enabling a call to a target
> > system-defined function with different calling conventions to be
> > issued, without having to modify .md files of the various
> > architectures supported by the target system to introduce or modify
> > clear_cache insns.
> >
> > (*) I write "nearly" mainly because, when not optimizing, we'd issue a
> > call regardless, but since the call may now be overridden, I added it
> > to the set of builtins that are not directly turned into calls when
> > not optimizing, following the normal expansion path instead.  It
> > wouldn't be hard to skip the emission of cache-clearing insns when not
> > optimizing, but it didn't seem very important, especially for the new
> > uses from trampoline init.
> >
> > Another difference that might be relevant is that now we expand
> > the begin and end arguments unconditionally.  This might make a
> > difference if they have side effects.  That's prettty much impossible
> > at expand time, but I thought I'd mention it.
> >
> >
> > I have NOT modified targets that did not issue cache-clearing calls in
> > trampoline init to use the new clear_cache-calling infrastructure even
> > if it would expand to nothing.  I have considered doing so, to have
> > __builtin___clear_cache and trampoline init call cacheTextUpdate on
> > all vxworks targets, but decided not to, since on targets that don't
> > do any cache clearing, cacheTextUpdate ought to be a no-op, even
> > though rs6000 seems to use icbi and dcbf instructions in the function
> > called to initialize a trampoline, but AFAICT not in the __clear_cache
> > builtin.  Hopefully target maintainers will have a look and take
> > advantage of this new piece of infrastructure to remove such
> > (apparent?) inconsistencies.  Not rs6000 and other that call asm-coded
> > trampoline setup instructions, for sure, but they might wish to
> > introduce a CLEAR_INSN_CACHE macro or a clear_cache expander if they
> > don't have one.
> >
> >
> > This was regstrapped on x86_64-linux-gnu, and a trivial backport was
> > tested on multiple vxworks targets.  Ok to install?
> >
> >
> > for  gcc/ChangeLog
> >
> >   * builtins.c (default_emit_call_builtin___clear_cache): New.
> >   (maybe_emit_call_builtin___clear_cache): New.
> >   (expand_builtin___clear_cache): Split into the above.
> >   (expand_builtin): Do not issue clear_cache call any more.
> >   * builtins.h (maybe_emit_call_builtin___clear_cache): Declare.
> >   * config/aarch64/aarch64.c (aarch64_trampoline_init): Use
> >   maybe_emit_call_builtin___clear_cache.
> >   * config/arc/arc.c (arc_trampoline_init): Likewise.
> >   * config/arm/arm.c (arm_trampoline_init): Likewise.
> >   * config/c6x/c6x.c (c6x_initialize_trampoline): Likewise.
> >   * config/csky/csky.c (csky_trampoline_init): Likewise.
> >   * config/m68k/linux.h (FInALIZE_TRAMPOLINE): Likewise.
> >   * config/tilegx/tilegx.c (tilegx_trampoline_init): Likewise.
> >   * config/tilepro/tilepro.c (tilepro_trampoline_init): Ditto.
> >   * config/vxworks.c: Include rtl.h, memmodel.h, and optabs.h.
> >   (vxworks_emit_call_builtin___clear_cache): New.
> >   * config/vxworks.h (CLEAR_INSN_CACHE): Drop.
> >   (TARGET_EMIT_CALL_BUILTIN___CLEAR_CACHE): Define.
> >   * target.def (trampoline_init): In the documentation, refer to
> >   maybe_emit_call_builtin___clear_cache.
> >   (emit_call_builtin___clear_cache): New.
> >   * doc/tm.texi.in: Add new hook point.
> >   (CLEAR_CACHE_INSN): Remove duplicate 'both'.
> >   * doc/tm.texi: Rebuilt.
> >   * targhooks.h (default_meit_call_builtin___clear_cache):
> >   Declare.
> >   * tree.h (BUILTIN_ASM_NAME_PTR): New.
> >
> > for  libgcc/ChangeLog
> >
> >   * config/t-vxworks (LIB2ADD): Drop.
> >   * config/t-vxworks7 (LIB2ADD): Likewise.
> > 

Re: [PATCH] i386: Fix up ix86_md_asm_adjust for TImode [PR98086]

[Uros Bizjak via Gcc-patches]

On Thu, Dec 3, 2020 at 9:50 AM Jakub Jelinek  wrote:
>
> Hi!
>
> ix86_md_asm_adjust right above this code uses:
>   machine_mode dest_mode = GET_MODE (dest);
>   if (!SCALAR_INT_MODE_P (dest_mode))
> {
>   error ("invalid type for % flag output");
>   continue;
> }
> but then assumes that dest_mode can be only [QHSD]Imode and nothing else.
>
> The following patch handles TImode and hypothetically even wider modes
> by handling it like DImode for 32-bit.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2020-12-03  Jakub Jelinek  
>
> PR target/98086
> * config/i386/i386.c (ix86_md_asm_adjust): Use dest_mode DImode
> or SImode for modes wider than DImode.  If dest_mode isn't SImode
> or GET_MODE (dest) isn't DImode, use convert_to_mode.

The whole part should be simply rewritten to:

--cut here--
  if (dest_mode == QImode)
emit_insn (gen_rtx_SET (dest, x));
  else
{
  rtx reg = gen_reg_rtx (QImode);
  emit_insn (gen_rtx_SET (reg, x));

  reg = convert_to_mode (GET_MODE (dest), reg, 1);
  emit_move_insn (dest, reg);
}
--cut here--

Uros.

[patch] Fix PR middle-end/98099

[Eric Botcazou]

Hi,

this replaces the ICE by a sorry message for the use of reverse scalar storage 
order with a 128-bit decimal floating-point type on 32-bit platforms.

Tested on x86-64/Linux, OK for the mainline?


2020-12-03  Eric Botcazou  

* expmed.c (flip_storage_order): In the case of a non-integer mode,
sorry out if the integer mode to be used instead is not supported.


2020-12-03  Eric Botcazou  

* gcc.dg/pr98099.c: New test.

-- 
Eric Botcazou/* PR middle-end/98099 */
/* Reported by G. Steinmetz  */

/* { dg-do compile } */
/* { dg-options "-fsso-struct=big-endian" } */

struct S { _Decimal128 a; };

_Decimal128 f (struct S x)
{
  return x.a; /* { dg-message "sorry, unimplemented: reverse storage order" "" { target { ! int128 } } } */
}
diff --git a/gcc/expmed.c b/gcc/expmed.c
index ce88f322961..0d600bd7b54 100644
--- a/gcc/expmed.c
+++ b/gcc/expmed.c
@@ -412,7 +412,8 @@ flip_storage_order (machine_mode mode, rtx x)
 	  && __builtin_expect (reverse_float_storage_order_supported < 0, 0))
 	check_reverse_float_storage_order_support ();
 
-  if (!int_mode_for_size (GET_MODE_PRECISION (mode), 0).exists (&int_mode))
+  if (!int_mode_for_size (GET_MODE_PRECISION (mode), 0).exists (&int_mode)
+	  || !targetm.scalar_mode_supported_p (int_mode))
 	{
 	  sorry ("reverse storage order for %smode", GET_MODE_NAME (mode));
 	  return x;

[patch] Fix PR middle-end/98082

[Eric Botcazou]

Hi,

this fixes an ICE introduced on the mainline by my fix for PR middle-end/97078 
where I changed use_register_for_decl to return true at -O0 for a parameter of 
a thunk.  It turns out that we need to do the same for a result in this case.

Tested on x86-64/Linux, OK for the mainline?


2020-12-03  Eric Botcazou  

PR middle-end/98082
* function.c (use_register_for_decl): Also return true for a result
if cfun->tail_call_marked is true.


2020-12-03  Eric Botcazou  

* g++.dg/cpp2a/pr98082.C: New test.

-- 
Eric Botcazoudiff --git a/gcc/function.c b/gcc/function.c
index 59fd72b0e82..af9618e18df 100644
--- a/gcc/function.c
+++ b/gcc/function.c
@@ -2206,13 +2206,15 @@ use_register_for_decl (const_tree decl)
   /* Otherwise, if RESULT_DECL is DECL_BY_REFERENCE, it will take
 	 the function_result_decl's assignment.  Since it's a pointer,
 	 we can short-circuit a number of the tests below, and we must
-	 duplicat e them because we don't have the
-	 function_result_decl to test.  */
+	 duplicate them because we don't have the function_result_decl
+	 to test.  */
   if (!targetm.calls.allocate_stack_slots_for_args ())
 	return true;
   /* We don't set DECL_IGNORED_P for the function_result_decl.  */
   if (optimize)
 	return true;
+  if (cfun->tail_call_marked)
+	return true;
   /* We don't set DECL_REGISTER for the function_result_decl.  */
   return false;
 }
/* PR middle-end/98082 */
/* Reported by Martin Liska  */

/* { dg-do compile { target c++20 } } */
/* { dg-options "-fipa-icf" } */

class GoodIter {
public:
  GoodIter();
  GoodIter(GoodIter &);
};

GoodIter operator-(int, GoodIter) { return GoodIter(); }
GoodIter operator+(int, GoodIter) { return GoodIter(); }

[PR66791][ARM] Replace __builtin_neon_vcreate* for vcreate intrinsics

[Prathamesh Kulkarni via Gcc-patches]

Hi,
This patch replaces calls to __builtin_neon_vcreate* builtins for
vcreate intrinsics in arm_neon.h.
Cross-tested on arm*-*-*.
OK to commit ?

Thanks,
Prathamesh


vcreate-1.diff
Description: Binary data

[PR66791][ARM] Replace __builtin_neon_vneg* by - for vneg intrinsics

[Prathamesh Kulkarni via Gcc-patches]

Hi,
This patch replaces calls to __builtin_neon_vneg* builtins by -
operator, for vneg intrinsics in arm_neon.h.
Cross-tested on arm*-*-*.
OK to commit ?

Thanks,
Prathamesh


vneg-1.diff
Description: Binary data

Re: introduce overridable clear_cache emitter

[Alexandre Oliva]

On Dec  3, 2020, Christophe Lyon  wrote:

> This patches causes a lot of regressions in fortran on arm and aarch64,

Thanks, on it.

-- 
Alexandre Oliva, happy hacker  https://FSFLA.org/blogs/lxo/
   Free Software Activist GNU Toolchain Engineer
Vim, Vi, Voltei pro Emacs -- GNUlius Caesar

Re: [PATCH] ipa: do not DECL_IS_MALLOC for void fns

[Jan Hubicka]

> On 12/2/20 4:25 PM, Martin Jambor wrote:
> > Hi,
> > 
> > On Wed, Dec 02 2020, Jan Hubicka wrote:
> > > > We create an IPA SRA (which has DECL_IS_MALLOC set to false), but later
> > > > IPA pure const propagates malloc attributes. I think we should not set
> > > > it for a void returning functions.
> > > > 
> > > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> > > > 
> > > > Ready to be installed?
> > > > Thanks,
> > > > Martin
> > > > 
> > > > gcc/ChangeLog:
> > > > 
> > > > PR ipa/98075
> > > > * cgraph.c (cgraph_node::dump): Dump decl_is_malloc flag.
> > > > * ipa-pure-const.c (propagate_malloc): Do not set malloc
> > > > attribute for void functions.
> > > 
> > > This is OK, extra credit would be for not collecting state here.  I plan
> > > to avoid stremaing useless pure-const summaries (to fight memory
> > > fragmentation at WPA time) so it would be nice to have an easy way to say 
> > > that
> > > summary is not interesting.
> > 
> > If I understood Martin's description well, it is an IPA-SRA created
> > clone that is a void function, not the original.
> 
> Yes.
> 
> > So it is not known
> > that the information is useless until the WPA stage.
> 
> Well, we have a code in ipa_param_adjustments::adjust_decl (tree orig_decl)
> where we properly not set DECL_IS_MALLOC.
> But later than the info is propagated in IPA pure const. That's why the patch
> was needed.
> 
> > 
> > Or do I misunderstand the issue?
> 
> Is it explained now?
Yep, it looks fine.
We have number of other attriutes that are about return values. It is
bit inconsistent that we treat DECL_IS_MALLOC but do not seem to remove
others, but I guess it is all harmless - there is no need to query those
attr on void functions.

Honza
> 
> Thanks,
> Martin
> 
> > 
> > Thanks,
> > 
> > Martin
> > 
> 

Re: [gcc r11-4816] Fix Ada build failure for the SuSE PowerPC64/Linux compiler

[Andreas Schwab]

On Nov 07 2020, Eric Botcazou via Gcc-cvs wrote:

> https://gcc.gnu.org/g:df784801daf0185a1e22ebf03d48363530717882
>
> commit r11-4816-gdf784801daf0185a1e22ebf03d48363530717882
> Author: Eric Botcazou 
> Date:   Sat Nov 7 11:07:11 2020 +0100
>
> Fix Ada build failure for the SuSE PowerPC64/Linux compiler
> 
> gcc/ada/ChangeLog:
> * gcc-interface/Makefile.in: Force target_cpu to powerpc if the
> nominal target is powerpc64-suse-linux.

This breaks build of libada, it is missing all of $(GNATRTL_128BIT_OBJS).

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

RE: [PR66791][ARM] Replace __builtin_neon_vcreate* for vcreate intrinsics

[Kyrylo Tkachov via Gcc-patches]

Hi Prathamesh,

> -Original Message-
> From: Prathamesh Kulkarni 
> Sent: 03 December 2020 10:50
> To: gcc Patches ; Kyrylo Tkachov
> 
> Subject: [PR66791][ARM] Replace __builtin_neon_vcreate* for vcreate
> intrinsics
> 
> Hi,
> This patch replaces calls to __builtin_neon_vcreate* builtins for
> vcreate intrinsics in arm_neon.h.
> Cross-tested on arm*-*-*.
> OK to commit ?

Just remembered for this and the previous patch...
Do we need to remove the builtins from being created in the backend if they are 
now unused?

Thanks,
Kyrill

> 
> Thanks,
> Prathamesh

Re: [gcc r11-4816] Fix Ada build failure for the SuSE PowerPC64/Linux compiler

[Eric Botcazou]

> This breaks build of libada, it is missing all of $(GNATRTL_128BIT_OBJS).

In the default multilib?  Yes, that's the point, since it's 32-bit apparently.

-- 
Eric Botcazou

[PATCH 0/6] Add missing calls to `onlyjump_p'

[Maciej W. Rozycki]

Hi,

 As discussed here: 



here is a small patch series adding missing calls to `onlyjump_p' around 
`any_condjump_p' and `any_uncondjump_p' use where the jump in question is 
about to be removed.

 Note that I have included unrelated though contextually connected 6/6 as 
an RFC to verify whether this potential anomaly I have spotted has been 
intentional.  I'll be happy to drop it if that is the case.  The remaining 
changes are I believe actual bug fixes.

 These changes have been successfully bootstrapped and regression-tested 
with the `powerpc64le-linux-gnu' and `x86_64-linux-gnu' native systems; 
verification with the `vax-netbsdelf' target using `powerpc64le-linux-gnu' 
host has been underway.

 I meant to do size checks across the test suites with the native builds, 
but I forgot that the test framework deletes built test cases after use by 
default.  I have restarted verification now with a modified configuration 
and will have results sometime tomorrow.

  Maciej

[PATCH 1/6] ifcvt: Add missing call to `onlyjump_p'

[Maciej W. Rozycki]

Do not convert a conditional jump into conditional execution (and remove 
the jump as a consequence) if the jump has side effects.

gcc/
* ifcvt.c (dead_or_predicable) [!IFCVT_MODIFY_TESTS]: Bail out 
if `!onlyjump_p'.
---
 gcc/ifcvt.c |6 ++
 1 file changed, 6 insertions(+)

gcc-ifcvt-dead-or-predicable-ce-only-jump.diff
Index: gcc/gcc/ifcvt.c
===
--- gcc.orig/gcc/ifcvt.c
+++ gcc/gcc/ifcvt.c
@@ -5127,6 +5127,11 @@ dead_or_predicable (basic_block test_bb,
 
   rtx cond;
 
+  /* If the conditional jump is more than just a conditional jump,
+then we cannot do conditional execution conversion on this block.  */
+  if (!onlyjump_p (jump))
+   goto nce;
+
   cond = cond_exec_get_condition (jump);
   if (! cond)
return FALSE;
@@ -5154,6 +5159,7 @@ dead_or_predicable (basic_block test_bb,
 
   earliest = jump;
 }
+ nce:
 #endif
 
   /* If we allocated new pseudos (e.g. in the conditional move

[PATCH 2/6] loop-iv: Add missing calls to `onlyjump_p'

[Maciej W. Rozycki]

Ignore jumps that have side effects in loop processing as pasting the 
body of a loop multiple times within is semantically equivalent to jump 
deletion (between the iterations unrolled) even if we do not physically 
delete the jump RTL insn.

gcc/
* loop-iv.c (simplify_using_initial_values): Only process jumps 
that match `onlyjump_p'.
(check_simple_exit): Likewise.
---
 gcc/loop-iv.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

gcc-loop-iv-only-jump.diff
Index: gcc/gcc/loop-iv.c
===
--- gcc.orig/gcc/loop-iv.c
+++ gcc/gcc/loop-iv.c
@@ -1936,7 +1936,7 @@ simplify_using_initial_values (class loo
   while (1)
 {
   insn = BB_END (e->src);
-  if (any_condjump_p (insn))
+  if (any_condjump_p (insn) && onlyjump_p (insn))
{
  rtx cond = get_condition (BB_END (e->src), NULL, false, true);
 
@@ -2887,7 +2887,7 @@ check_simple_exit (class loop *loop, edg
 return;
 
   /* It must end in a simple conditional jump.  */
-  if (!any_condjump_p (BB_END (exit_bb)))
+  if (!any_condjump_p (BB_END (exit_bb)) || !onlyjump_p (BB_END (exit_bb)))
 return;
 
   ein = EDGE_SUCC (exit_bb, 0);

[PATCH 3/6] sel-sched-ir: Add missing call to `onlyjump_p'

[Maciej W. Rozycki]

Do not try to remove a conditional jump if it has side effects.

gcc/
* sel-sched-ir.c (maybe_tidy_empty_bb): Only try to remove a 
conditional jump if `onlyjump_p'.
---
 gcc/sel-sched-ir.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

gcc-sel-sched-ir-empty-bb-only-jump.diff
Index: gcc/gcc/sel-sched-ir.c
===
--- gcc.orig/gcc/sel-sched-ir.c
+++ gcc/gcc/sel-sched-ir.c
@@ -3793,7 +3793,8 @@ maybe_tidy_empty_bb (basic_block bb)
  else if (single_succ_p (pred_bb) && any_condjump_p (BB_END (pred_bb)))
{
  /* If possible, try to remove the unneeded conditional jump.  */
- if (INSN_SCHED_TIMES (BB_END (pred_bb)) == 0
+ if (onlyjump_p (BB_END (pred_bb))
+ && INSN_SCHED_TIMES (BB_END (pred_bb)) == 0
  && !IN_CURRENT_FENCE_P (BB_END (pred_bb)))
{
  if (!sel_remove_insn (BB_END (pred_bb), false, false))

[PATCH 4/6] cfgrtl: Add missing call to `onlyjump_p'

[Maciej W. Rozycki]

If any unconditional jumps within a block have side effects then the 
block cannot be considered empty.

gcc/
* cfgrtl.c (rtl_block_empty_p): Return false if `!onlyjump_p' 
too.
---
 gcc/cfgrtl.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

gcc-cfgrtl-block-empty-only-jump.diff
Index: gcc/gcc/cfgrtl.c
===
--- gcc.orig/gcc/cfgrtl.c
+++ gcc/gcc/cfgrtl.c
@@ -4860,7 +4860,8 @@ rtl_block_empty_p (basic_block bb)
 return true;
 
   FOR_BB_INSNS (bb, insn)
-if (NONDEBUG_INSN_P (insn) && !any_uncondjump_p (insn))
+if (NONDEBUG_INSN_P (insn)
+   && (!any_uncondjump_p (insn) || !onlyjump_p (insn)))
   return false;
 
   return true;

[PATCH 5/6] loop-doloop: Add missing call to `onlyjump_p'

[Maciej W. Rozycki]

Keep any jump that has side effects as those must not be removed.

gcc/
* loop-doloop.c (add_test): Only remove the jump if `onlyjump_p'.
---
 gcc/loop-doloop.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

gcc-loop-doloop-add-test-only-jump.diff
Index: gcc/gcc/loop-doloop.c
===
--- gcc.orig/gcc/loop-doloop.c
+++ gcc/gcc/loop-doloop.c
@@ -378,7 +378,7 @@ add_test (rtx cond, edge *e, basic_block
   bb = split_edge_and_insert (*e, seq);
   *e = single_succ_edge (bb);
 
-  if (any_uncondjump_p (jump))
+  if (any_uncondjump_p (jump) && onlyjump_p (jump))
 {
   /* The condition is always true.  */
   delete_insn (jump);

[RFC 6/6] ifcvt: Fall through to NCE if getting the CE condition failed

[Maciej W. Rozycki]

If getting the condition for conditional execution has failed then fall 
through and try the non-conditional execution approach instead rather 
than giving up with dead code elimination altogether, for a better code 
structure if nothing else.

The case may well now be that whenever `cond_exec_get_condition' fails 
`noce_get_condition' will as well, however in that case no change in 
semantics will result.  If they ever diverge, then someone will have to 
chase this place.

gcc/
* ifcvt.c (dead_or_predicable) [!IFCVT_MODIFY_TESTS]: Fall 
through to the non-conditional execution case if getting the 
condition for conditional execution has failed.
---
 gcc/ifcvt.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: gcc/gcc/ifcvt.c
===
--- gcc.orig/gcc/ifcvt.c
+++ gcc/gcc/ifcvt.c
@@ -5134,7 +5134,7 @@ dead_or_predicable (basic_block test_bb,
 
   cond = cond_exec_get_condition (jump);
   if (! cond)
-   return FALSE;
+   goto nce;
 
   rtx note = find_reg_note (jump, REG_BR_PROB, NULL_RTX);
   profile_probability prob_val

Re: [Ada] Build support units for 128-bit integer types on 64-bit platforms

[Andreas Schwab]

On Nov 20 2020, Maciej W. Rozycki wrote:

>  For the record: in a native `powerpc64le-linux-gnu' build despite the 
> issue a functional compiler used to be built, except for the acats test 
> suite reporting a catastrophic failure:
>
>   === acats support ===
> Generating support files... Failed to compile impbit
> make: [.../gcc/ada/gcc-interface/Make-lang.in:958: check-acats] Error 1 
> (ignored)
>
> and then acats.log reporting:
>
> .../gcc/gnatbind -x impbit.ali
> error: "s-imgllli.ali" not found, "s-imgllli.ads" must be compiled
> gnatmake: *** bind failed.
>  Failed to compile impbit

This means GNATRTL_128BIT_OBJS is missing from
EXTRA_GNATRTL_NONTASKING_OBJS.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: [PATCH] i386: Fix up ix86_md_asm_adjust for TImode [PR98086]

[Uros Bizjak via Gcc-patches]

On Thu, Dec 3, 2020 at 11:39 AM Uros Bizjak  wrote:
>
> > ix86_md_asm_adjust right above this code uses:
> >   machine_mode dest_mode = GET_MODE (dest);
> >   if (!SCALAR_INT_MODE_P (dest_mode))
> > {
> >   error ("invalid type for % flag output");
> >   continue;
> > }
> > but then assumes that dest_mode can be only [QHSD]Imode and nothing else.
> >
> > The following patch handles TImode and hypothetically even wider modes
> > by handling it like DImode for 32-bit.
> >
> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> >
> > 2020-12-03  Jakub Jelinek  
> >
> > PR target/98086
> > * config/i386/i386.c (ix86_md_asm_adjust): Use dest_mode DImode
> > or SImode for modes wider than DImode.  If dest_mode isn't SImode
> > or GET_MODE (dest) isn't DImode, use convert_to_mode.
>
> The whole part should be simply rewritten to:
>
> --cut here--
>   if (dest_mode == QImode)
> emit_insn (gen_rtx_SET (dest, x));
>   else
> {
>   rtx reg = gen_reg_rtx (QImode);
>   emit_insn (gen_rtx_SET (reg, x));
>
>   reg = convert_to_mode (GET_MODE (dest), reg, 1);
>   emit_move_insn (dest, reg);
> }
> --cut here--

Please let me fix this PR.

Uros.

Re: [PATCH] i386: Fix up ix86_md_asm_adjust for TImode [PR98086]

[Jakub Jelinek via Gcc-patches]

On Thu, Dec 03, 2020 at 12:49:49PM +0100, Uros Bizjak wrote:
> On Thu, Dec 3, 2020 at 11:39 AM Uros Bizjak  wrote:
> >
> > > ix86_md_asm_adjust right above this code uses:
> > >   machine_mode dest_mode = GET_MODE (dest);
> > >   if (!SCALAR_INT_MODE_P (dest_mode))
> > > {
> > >   error ("invalid type for % flag output");
> > >   continue;
> > > }
> > > but then assumes that dest_mode can be only [QHSD]Imode and nothing else.
> > >
> > > The following patch handles TImode and hypothetically even wider modes
> > > by handling it like DImode for 32-bit.
> > >
> > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> > >
> > > 2020-12-03  Jakub Jelinek  
> > >
> > > PR target/98086
> > > * config/i386/i386.c (ix86_md_asm_adjust): Use dest_mode DImode
> > > or SImode for modes wider than DImode.  If dest_mode isn't SImode
> > > or GET_MODE (dest) isn't DImode, use convert_to_mode.
> >
> > The whole part should be simply rewritten to:
> >
> > --cut here--
> >   if (dest_mode == QImode)
> > emit_insn (gen_rtx_SET (dest, x));
> >   else
> > {
> >   rtx reg = gen_reg_rtx (QImode);
> >   emit_insn (gen_rtx_SET (reg, x));
> >
> >   reg = convert_to_mode (GET_MODE (dest), reg, 1);
> >   emit_move_insn (dest, reg);
> > }
> > --cut here--
> 
> Please let me fix this PR.

Sorry, I've been looking at the glibc miscompilation in the meantime.
But if you want to take this over, please go ahead, it is all yours,
there are hundreds of other PRs for me to choose from ;)

Jakub

[BUG/PATCH] ppc64 g5 and cell optimizations result in .machine power7

[René Rebe]

Hi,

Since reworking the rs6000 .machine output selection in commit 
e154242724b084380e3221df7c08fcdbd8460674 22 May 2019, compiling glibc with 
either G5 or cell results in power7 assembly optimizations to be chosen, which 
obviously crash with illegal instructions. This is because gcc's .machine 
output was accidentally changed due to OPTION_MASK_ALTIVEC only otherwise 
present in IBM CPUs since power7.

Bug & patch already at:

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

Best regards,
René Rebe

-- 
 ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin, https://exactcode.com
 https://exactscan.com | https://ocrkit.com | https://t2sde.org | 
https://rene.rebe.de

Re: introduce overridable clear_cache emitter

[Andreas Schwab]

../../../../libffi/src/aarch64/ffi.c: In function 'ffi_prep_closure_loc':
../../../../libffi/src/aarch64/ffi.c:67:3: error: both arguments to 
'__builtin___clear_cache' must be pointers
   67 |   __builtin___clear_cache (start, end);
  |   ^~~~

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: [patch] Fix PR middle-end/98099

[Richard Biener via Gcc-patches]

On Thu, Dec 3, 2020 at 11:49 AM Eric Botcazou  wrote:
>
> Hi,
>
> this replaces the ICE by a sorry message for the use of reverse scalar storage
> order with a 128-bit decimal floating-point type on 32-bit platforms.
>
> Tested on x86-64/Linux, OK for the mainline?

OK.

Richard.

>
> 2020-12-03  Eric Botcazou  
>
> * expmed.c (flip_storage_order): In the case of a non-integer mode,
> sorry out if the integer mode to be used instead is not supported.
>
>
> 2020-12-03  Eric Botcazou  
>
> * gcc.dg/pr98099.c: New test.
>
> --
> Eric Botcazou

Re: [patch] Fix PR middle-end/98082

[Richard Biener via Gcc-patches]

On Thu, Dec 3, 2020 at 11:49 AM Eric Botcazou  wrote:
>
> Hi,
>
> this fixes an ICE introduced on the mainline by my fix for PR middle-end/97078
> where I changed use_register_for_decl to return true at -O0 for a parameter of
> a thunk.  It turns out that we need to do the same for a result in this case.
>
> Tested on x86-64/Linux, OK for the mainline?

OK.

Richard.

>
> 2020-12-03  Eric Botcazou  
>
> PR middle-end/98082
> * function.c (use_register_for_decl): Also return true for a result
> if cfun->tail_call_marked is true.
>
>
> 2020-12-03  Eric Botcazou  
>
> * g++.dg/cpp2a/pr98082.C: New test.
>
> --
> Eric Botcazou

Re: [gcc r11-4816] Fix Ada build failure for the SuSE PowerPC64/Linux compiler

[Andreas Schwab]

On Dez 03 2020, Eric Botcazou wrote:

>> This breaks build of libada, it is missing all of $(GNATRTL_128BIT_OBJS).
>
> In the default multilib?  Yes, that's the point, since it's 32-bit apparently.

Nope.  The default is 64-bit.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: introduce overridable clear_cache emitter

[Andreas Schwab]

On Dez 03 2020, Andreas Schwab wrote:

> ../../../../libffi/src/aarch64/ffi.c: In function 'ffi_prep_closure_loc':
> ../../../../libffi/src/aarch64/ffi.c:67:3: error: both arguments to 
> '__builtin___clear_cache' must be pointers
>67 |   __builtin___clear_cache (start, end);
>   |   ^~~~

This happens when compiling with -mabi=ilp32.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: [stage1][PATCH] Change semantics of -frecord-gcc-switches and add -frecord-gcc-switches-format.

[Richard Biener via Gcc-patches]

On Thu, Nov 26, 2020 at 2:55 PM Martin Liška  wrote:
>
> On 11/25/20 2:48 PM, Richard Biener wrote:
> > On Mon, Nov 23, 2020 at 2:02 PM Martin Liška  wrote:
> >>
> >> On 11/23/20 12:00 PM, Richard Biener wrote:
> >>> Can you split out the unifying of -[gf]record-gcc-switches processing
> >>> and the target hook adjustment from the change introducing
> >>> -frecord-gcc-switches-format?
> >>
> >> Sure.
> >>
> >>>
> >>> dwarf2out.c seems to retain its gen_producer_string () even though
> >>> you duplicate it elsewhere and it is now unused?  Please retain
> >>> the gen_producer_string name since the function does actual
> >>> processing and not just fetch a precomputed string from somewhere.
> >>
> >> Yep, please take a look at the attached patch.
> >>
> >>>
> >>> I'd like somebody else chime in on the -frecord-gcc-switches-format
> >>> driver handling but will happily work with getting the unification part 
> >>> merged.
> >>
> >> May I apply the patch after it finishes regression tests and bootstrap?
> >
> > @@ -1523,8 +1378,9 @@ process_options (void)
> > if (version_flag)
> >   {
> > print_version (stderr, "", true);
> > -  if (! quiet_flag)
> > -   print_switch_values (print_to_stderr);
> > +  if (!quiet_flag)
> > +   fputs (gen_producer_string (lang_hooks.name, save_decoded_options,
> > +   save_decoded_options_count), stderr);
> >   }
> >
> >
> > so I wonder whether this regresses (no newlines anymore, no separate
> > printing of options passed/enabled).  Previously with -Q -v you'll get sth
> > like
> >
> > options passed:  -v
> >   -iprefix 
> > /home/rguenther/obj-gcc2-g/gcc/../lib64/gcc/x86_64-pc-linux-gnu/11.0.0/
> >   -isystem ./include -isystem ./include-fixed t.c -mtune=generic
> >   -march=x86-64 -O2
> > options enabled:  -faggressive-loop-optimizations -falign-functions
> >   -falign-jumps -falign-labels -falign-loops -fallocation-dce
> >   -fasynchronous-unwind-tables -fauto-inc-dec -fbranch-count-reg
> >   -fcaller-saves -fcode-hoisting -fcombine-stack-adjustments -fcompare-elim
> >   -fcprop-registers -fcrossjumping -fcse-follow-jumps -fdefer-pop
> >   -fdelete-null-pointer-checks -fdevirtualize -fdevirtualize-speculatively
> >   -fdwarf2-cfi-asm -fearly-inlining -feliminate-unused-debug-symbols
> > ...
>
> Oh, you are right that there's a significant change (I fixed the newline):
>
> BEFORE:
> GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
> options passed:  -v a.c -mtune=generic -march=x86-64
> options enabled:  -faggressive-loop-optimizations -fallocation-dce
>   -fasynchronous-unwind-tables -fauto-inc-dec -fdelete-null-pointer-checks
>   -fdwarf2-cfi-asm -fearly-inlining -feliminate-unused-debug-symbols
>   -feliminate-unused-debug-types -ffp-int-builtin-inexact -ffunction-cse
>   -fgcse-lm -fgnu-unique -fident -finline-atomics -fipa-stack-alignment
>   -fira-hoist-pressure -fira-share-save-slots -fira-share-spill-slots
>   -fivopts -fkeep-static-consts -fleading-underscore -flifetime-dse
>   -fmath-errno -fmerge-debug-strings -fpeephole -fplt -fprefetch-loop-arrays
>   -freg-struct-return -fsched-critical-path-heuristic
>   -fsched-dep-count-heuristic -fsched-group-heuristic -fsched-interblock
>   -fsched-last-insn-heuristic -fsched-rank-heuristic -fsched-spec
>   -fsched-spec-insn-heuristic -fsched-stalled-insns-dep -fschedule-fusion
>   -fsemantic-interposition -fshow-column -fshrink-wrap-separate
>   -fsigned-zeros -fsplit-ivs-in-unroller -fssa-backprop -fstdarg-opt
>   -fstrict-volatile-bitfields -fsync-libcalls -ftrapping-math -ftree-cselim
>   -ftree-forwprop -ftree-loop-if-convert -ftree-loop-im -ftree-loop-ivcanon
>   -ftree-loop-optimize -ftree-parallelize-loops= -ftree-phiprop
>   -ftree-reassoc -ftree-scev-cprop -funit-at-a-time -funwind-tables
>   -fvar-tracking -fvar-tracking-assignments -fzero-initialized-in-bss
>   -m128bit-long-double -m64 -m80387 -malign-stringops
>   -mavx256-split-unaligned-load -mavx256-split-unaligned-store
>   -mfancy-math-387 -mfp-ret-in-387 -mfxsr -mglibc -mieee-fp -mlong-double-80
>   -mmmx -mno-sse4 -mpush-args -mred-zone -msse -msse2 -mstv
>   -mtls-direct-seg-refs -mvzeroupper
> Compiler executable checksum: 
>
> AFTER:
> GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
> GNU C17 11.0.0 20201123 (experimental) -dumpbase-ext .c -mtune=generic 
> -march=x86-64
> Compiler executable checksum: 36558a9ca3607b6821d78562377c56da
>
> For -fverbose-asm we get something similar:
>
> BEFORE:
> # GNU C17 (SUSE Linux) version 10.2.1 20201117 [revision 
> 98ba03ffe0b9f37b4916ce6238fad754e00d720b] (x86_64-suse-linux)
> #   compiled by GNU C version 10.2.1 20201117 [revision 
> 98ba03ffe0b9f37b4916ce6238fad754e00d720b], GMP version 6.2.0, MPFR version 
> 4.1.0, MPC version 1.2.1, isl version isl-0.22.1-GMP
>
> # GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
> # options passed:

[PATCH] tree-optimization/98113 - vectorize a sequence of BIT_INSERT_EXPRs

[Richard Biener]

This adds the capability to handle a sequence of vector BIT_INSERT_EXPRs
to be vectorized similar as to how we vectorize vector constructors.

Bootstrapped and tested on x86_64-unknown-linux-gnu, OK at this stage
or do we want to defer to stage1 and regress for the PRs testcase?

The testcase can see amending for other targets that support
vectorized popcount, I've refrained from second-guessing needed
options and targest.

Thanks,
Richard.

2020-12-03  Richard Biener  

PR tree-optimization/98113
* tree-vectorizer.h (struct slp_root): New.
(_bb_vec_info::roots): New member.
* tree-vect-slp.c (vect_analyze_slp): Also walk BB info
roots.
(_bb_vec_info::_bb_vec_info): Adjust.
(_bb_vec_info::~_bb_vec_info): Likewise.
(vld_cmp): New.
(vect_slp_is_lane_insert): Likewise.
(vect_slp_check_for_constructors): Match a series of
BIT_INSERT_EXPRs as vector constructor.
(vect_slp_analyze_bb_1): Continue if BB info roots is
not empty.
(vect_slp_analyze_bb_1): Mark the whole BIT_INSERT_EXPR root
sequence as pure_slp.

* gcc.dg/vect/bb-slp-70.c: New testcase.
---
 gcc/testsuite/gcc.dg/vect/bb-slp-70.c |  17 +++
 gcc/tree-vect-slp.c   | 192 +++---
 gcc/tree-vectorizer.h |  12 ++
 3 files changed, 200 insertions(+), 21 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/vect/bb-slp-70.c

diff --git a/gcc/testsuite/gcc.dg/vect/bb-slp-70.c 
b/gcc/testsuite/gcc.dg/vect/bb-slp-70.c
new file mode 100644
index 000..0eb70112bde
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/bb-slp-70.c
@@ -0,0 +1,17 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-mavx512vl -mavx512vpopcntdq" { target 
avx512vpopcntdq } } */
+
+typedef unsigned uv4si __attribute__((vector_size(16)));
+
+uv4si __attribute__((noinline))
+vpopctf (uv4si a)
+{
+  uv4si r;
+  r[2] = __builtin_popcount (a[2]);
+  r[1] = __builtin_popcount (a[1]);
+  r[0] = __builtin_popcount (a[0]);
+  r[3] = __builtin_popcount (a[3]);
+  return r;
+}
+
+/* { dg-final { scan-tree-dump "optimized: basic block" "slp2" { target 
avx512vpopcntdq } } } */
diff --git a/gcc/tree-vect-slp.c b/gcc/tree-vect-slp.c
index be87475092d..8f709aa0271 100644
--- a/gcc/tree-vect-slp.c
+++ b/gcc/tree-vect-slp.c
@@ -3039,6 +3039,19 @@ vect_analyze_slp (vec_info *vinfo, unsigned 
max_tree_size)
   ? slp_inst_kind_store : slp_inst_kind_ctor,
   max_tree_size);
 
+  if (bb_vec_info bb_vinfo = dyn_cast  (vinfo))
+{
+  for (unsigned i = 0; i < bb_vinfo->roots.length (); ++i)
+   {
+ vect_location = bb_vinfo->roots[i].root->stmt;
+ if (vect_build_slp_instance (bb_vinfo, bb_vinfo->roots[i].kind,
+  bb_vinfo->roots[i].stmts,
+  bb_vinfo->roots[i].root,
+  max_tree_size, bst_map, NULL))
+   bb_vinfo->roots[i].stmts = vNULL;
+   }
+}
+
   if (loop_vec_info loop_vinfo = dyn_cast  (vinfo))
 {
   /* Find SLP sequences starting from reduction chains.  */
@@ -3797,7 +3810,7 @@ vect_detect_hybrid_slp (loop_vec_info loop_vinfo)
 /* Initialize a bb_vec_info struct for the statements in BBS basic blocks.  */
 
 _bb_vec_info::_bb_vec_info (vec _bbs, vec_info_shared *shared)
-  : vec_info (vec_info::bb, init_cost (NULL), shared), bbs (_bbs)
+  : vec_info (vec_info::bb, init_cost (NULL), shared), bbs (_bbs), roots 
(vNULL)
 {
   for (unsigned i = 0; i < bbs.length (); ++i)
 {
@@ -3844,6 +3857,10 @@ _bb_vec_info::~_bb_vec_info ()
  gimple_set_uid (stmt, -1);
}
 }
+
+  for (unsigned i = 0; i < roots.length (); ++i)
+roots[i].stmts.release ();
+  roots.release ();
 }
 
 /* Subroutine of vect_slp_analyze_node_operations.  Handle the root of NODE,
@@ -4556,6 +4573,38 @@ vect_bb_vectorization_profitable_p (bb_vec_info bb_vinfo,
   return true;
 }
 
+/* qsort comparator for lane defs.  */
+
+static int
+vld_cmp (const void *a_, const void *b_)
+{
+  auto *a = (const std::pair *)a_;
+  auto *b = (const std::pair *)b_;
+  return a->first - b->first;
+}
+
+/* Return true if USE_STMT is a vector lane insert into VEC and set
+   *THIS_LANE to the lane number that is set.  */
+
+static bool
+vect_slp_is_lane_insert (gimple *use_stmt, tree vec, unsigned *this_lane)
+{
+  gassign *use_ass = dyn_cast  (use_stmt);
+  if (!use_ass
+  || gimple_assign_rhs_code (use_ass) != BIT_INSERT_EXPR
+  || (vec
+ ? gimple_assign_rhs1 (use_ass) != vec
+ : ((vec = gimple_assign_rhs1 (use_ass)), false))
+  || !useless_type_conversion_p (TREE_TYPE (TREE_TYPE (vec)),
+TREE_TYPE (gimple_assign_rhs2 (use_ass)))
+  || !constant_multiple_p
+   (tree_to_poly_uint64 (gimple_assign_rhs3 (use_ass)),
+tree_to_poly_uint64 (TYPE_SIZE (TREE_TYPE (TREE_TYP

C++ patch ping

[Jakub Jelinek via Gcc-patches]

Hi!

I'd like to ping
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/560372.html
- v3 of the __builtin_bit_cast (with (hopefully) all earlier feedback
incorporated).

Thanks

Jakub

Re: [PATCH] c++: consteval-defarg1.C test variant for templates

[Jason Merrill via Gcc-patches]

On 12/3/20 4:29 AM, Jakub Jelinek wrote:

On Wed, Dec 02, 2020 at 10:15:25PM -0500, Jason Merrill wrote:

Jakub noticed that we weren't recognizing a default argument for a consteval
member function as being in immediate function context because there was no
function parameter scope to look at.

Note that this patch doesn't actually push the parameters into the scope,
that happens in a separate commit.


Shouldn't we also be testing how it behaves in templates?

The following testcase is an attempt to test both non-dependent and
dependent consteval calls in both function and class templates, and with
your committed patch it now passes.

Ok for trunk?


OK, thanks.


2020-12-03  Jakub Jelinek  

* g++.dg/cpp2a/consteval-defarg2.C: New test.

--- gcc/testsuite/g++.dg/cpp2a/consteval-defarg2.C.jj   2020-12-03 
10:26:16.340256056 +0100
+++ gcc/testsuite/g++.dg/cpp2a/consteval-defarg2.C  2020-12-03 
10:19:33.215853790 +0100
@@ -0,0 +1,29 @@
+// Test that late-parsed default args have the same consteval semantics.
+// { dg-do compile { target c++20 } }
+
+template 
+consteval bool foo (bool x) { if (x) throw N; return false; }
+consteval bool qux (bool x) { if (x) throw 1; return false; }
+template 
+consteval bool bar (bool x = foo (true)) { return true; }
+template 
+consteval bool corge (bool x = qux (true)) { return true; }
+template 
+struct S
+{
+  consteval static bool baz (bool x = foo (true)) { return true; }
+  consteval static bool garply (bool x = qux (true)) { return true; }
+};
+struct T
+{
+  template 
+  consteval static bool baz (bool x = foo (true)) { return true; }
+  template 
+  consteval static bool garply (bool x = qux (true)) { return true; }
+};
+constexpr bool a = bar<0> (true);
+constexpr bool b = corge<0> (true);
+constexpr bool c = S<0>::baz (true);
+constexpr bool d = S<0>::garply (true);
+constexpr bool e = T::baz<0> (true);
+constexpr bool f = T::garply<0> (true);


Jakub

Re: introduce overridable clear_cache emitter

[Alexandre Oliva]

On Dec  3, 2020, Christophe Lyon  wrote:

> This patches causes a lot of regressions in fortran on arm and aarch64,

On Dec  3, 2020, Andreas Schwab  wrote:

> On Dez 03 2020, Andreas Schwab wrote:

>> ../../../../libffi/src/aarch64/ffi.c: In function 'ffi_prep_closure_loc':
>> ../../../../libffi/src/aarch64/ffi.c:67:3: error: both arguments to 
>> '__builtin___clear_cache' must be pointers
>> 67 |   __builtin___clear_cache (start, end);
>> |   ^~~~

> This happens when compiling with -mabi=ilp32.

Thank you both.  Here's the patch I'm testing to fix both issues.
Ok to install?


fix __builtin___clear_cache overrider fallout

From: Alexandre Oliva 

Machines that had CLEAR_CACHE_INSN and that would thus issue calls to
__clear_cache with the default call expander, would fail on languages
that did not set up the __clear_cache builtin.  This patch arranges
for all languages to set up this builtin.

Machines or multilibs that had ptr_mode != Pmode, such as aarch64 with
-mabi=ilp32, would fail the RTL mode test of the arguments passed to
__clear_cache, because we'd insist on ptr_mode.  This patch arranges for
Pmode to be accepted as well.


for  gcc/ChangeLog

* tree.c (build_common_builtin_nodes): Declare
__builtin___clear_cache for all languages.
* builtins.c (maybe_emit_call_builtin___clear_cache): Accept
Pmode arguments.
---
 gcc/builtins.c |3 ++-
 gcc/tree.c |6 ++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/gcc/builtins.c b/gcc/builtins.c
index ecc12e69c1466..cd30de8bfb035 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -7793,7 +7793,8 @@ default_emit_call_builtin___clear_cache (rtx begin, rtx 
end)
 void
 maybe_emit_call_builtin___clear_cache (rtx begin, rtx end)
 {
-  if (GET_MODE (begin) != ptr_mode || GET_MODE (end) != ptr_mode)
+  if ((GET_MODE (begin) != ptr_mode && GET_MODE (begin) != Pmode)
+  || (GET_MODE (end) != ptr_mode && GET_MODE (end) != Pmode))
 {
   error ("both arguments to %<__builtin___clear_cache%> must be pointers");
   return;
diff --git a/gcc/tree.c b/gcc/tree.c
index 52a145dd01819..72311005f57b2 100644
--- a/gcc/tree.c
+++ b/gcc/tree.c
@@ -10733,6 +10733,12 @@ build_common_builtin_nodes (void)
 
   ftype = build_function_type_list (void_type_node,
ptr_type_node, ptr_type_node, NULL_TREE);
+  if (!builtin_decl_explicit_p (BUILT_IN_CLEAR_CACHE))
+local_define_builtin ("__builtin___clear_cache", ftype,
+ BUILT_IN_CLEAR_CACHE,
+ "__builtin___clear_cache",
+ ECF_NOTHROW);
+
   local_define_builtin ("__builtin_nonlocal_goto", ftype,
BUILT_IN_NONLOCAL_GOTO,
"__builtin_nonlocal_goto",


-- 
Alexandre Oliva, happy hacker  https://FSFLA.org/blogs/lxo/
   Free Software Activist GNU Toolchain Engineer
Vim, Vi, Voltei pro Emacs -- GNUlius Caesar

Re: [PATCH 3/4] rs6000: Enable vec_insert for P8 with rs6000_expand_vector_set_var_p8

[Xionghu Luo via Gcc-patches]

Ping. Thanks.


On 2020/11/27 09:04, Xionghu Luo via Gcc-patches wrote:

Hi Segher,
Thanks for the approval of [PATCH 1/4] and [PATCH 2/4], what's your
opinion of this [PATCH 3/4] for P8, please?  xxinsertw only exists since
v3.0, so we had to implement by another way.


Xionghu


On 2020/10/10 16:08, Xionghu Luo wrote:

gcc/ChangeLog:

2020-10-10  Xionghu Luo  

* config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin):
Generate ARRAY_REF(VIEW_CONVERT_EXPR) for P8 and later
platforms.
* config/rs6000/rs6000.c (rs6000_expand_vector_set_var): Update
to call different path for P8 and P9.
(rs6000_expand_vector_set_var_p9): New function.
(rs6000_expand_vector_set_var_p8): New function.

gcc/testsuite/ChangeLog:

2020-10-10  Xionghu Luo  

* gcc.target/powerpc/pr79251.p8.c: New test.
---
   gcc/config/rs6000/rs6000-c.c  |  27 +++-
   gcc/config/rs6000/rs6000.c| 117 +-
   gcc/testsuite/gcc.target/powerpc/pr79251.p8.c |  17 +++
   3 files changed, 155 insertions(+), 6 deletions(-)
   create mode 100644 gcc/testsuite/gcc.target/powerpc/pr79251.p8.c

diff --git a/gcc/config/rs6000/rs6000-c.c b/gcc/config/rs6000/rs6000-c.c
index 5551a21d738..4bea8001ec6 100644
--- a/gcc/config/rs6000/rs6000-c.c
+++ b/gcc/config/rs6000/rs6000-c.c
@@ -1599,10 +1599,29 @@ altivec_resolve_overloaded_builtin (location_t loc, 
tree fndecl,
  SET_EXPR_LOCATION (stmt, loc);
  stmt = build1 (COMPOUND_LITERAL_EXPR, arg1_type, stmt);
}
-  stmt = build_array_ref (loc, stmt, arg2);
-  stmt = fold_build2 (MODIFY_EXPR, TREE_TYPE (arg0), stmt,
- convert (TREE_TYPE (stmt), arg0));
-  stmt = build2 (COMPOUND_EXPR, arg1_type, stmt, decl);
+
+  if (TARGET_P8_VECTOR)
+   {
+ stmt = build_array_ref (loc, stmt, arg2);
+ stmt = fold_build2 (MODIFY_EXPR, TREE_TYPE (arg0), stmt,
+ convert (TREE_TYPE (stmt), arg0));
+ stmt = build2 (COMPOUND_EXPR, arg1_type, stmt, decl);
+   }
+  else
+   {
+ tree arg1_inner_type;
+ tree innerptrtype;
+ arg1_inner_type = TREE_TYPE (arg1_type);
+ innerptrtype = build_pointer_type (arg1_inner_type);
+
+ stmt = build_unary_op (loc, ADDR_EXPR, stmt, 0);
+ stmt = convert (innerptrtype, stmt);
+ stmt = build_binary_op (loc, PLUS_EXPR, stmt, arg2, 1);
+ stmt = build_indirect_ref (loc, stmt, RO_NULL);
+ stmt = build2 (MODIFY_EXPR, TREE_TYPE (stmt), stmt,
+convert (TREE_TYPE (stmt), arg0));
+ stmt = build2 (COMPOUND_EXPR, arg1_type, stmt, decl);
+   }
 return stmt;
   }
   
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c

index 96f76c7a74c..33ca839cb28 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -6806,10 +6806,10 @@ rs6000_expand_vector_set (rtx target, rtx val, rtx 
elt_rtx)
   }
   
   /* Insert VAL into IDX of TARGET, VAL size is same of the vector element, IDX

-   is variable and also counts by vector element size.  */
+   is variable and also counts by vector element size for p9 and above.  */
   
   void

-rs6000_expand_vector_set_var (rtx target, rtx val, rtx idx)
+rs6000_expand_vector_set_var_p9 (rtx target, rtx val, rtx idx)
   {
 machine_mode mode = GET_MODE (target);
   
@@ -6852,6 +6852,119 @@ rs6000_expand_vector_set_var (rtx target, rtx val, rtx idx)

 emit_insn (perml);
   }
   
+/* Insert VAL into IDX of TARGET, VAL size is same of the vector element, IDX

+   is variable and also counts by vector element size for p8.  */
+
+void
+rs6000_expand_vector_set_var_p8 (rtx target, rtx val, rtx idx)
+{
+  machine_mode mode = GET_MODE (target);
+
+  gcc_assert (VECTOR_MEM_VSX_P (mode) && !CONST_INT_P (idx));
+
+  gcc_assert (GET_MODE (idx) == E_SImode);
+
+  machine_mode inner_mode = GET_MODE (val);
+  HOST_WIDE_INT mode_mask = GET_MODE_MASK (inner_mode);
+
+  rtx tmp = gen_reg_rtx (GET_MODE (idx));
+  int width = GET_MODE_SIZE (inner_mode);
+
+  gcc_assert (width >= 1 && width <= 4);
+
+  if (!BYTES_BIG_ENDIAN)
+{
+  /*  idx = idx * width.  */
+  emit_insn (gen_mulsi3 (tmp, idx, GEN_INT (width)));
+  /*  idx = idx + 8.  */
+  emit_insn (gen_addsi3 (tmp, tmp, GEN_INT (8)));
+}
+  else
+{
+  emit_insn (gen_mulsi3 (tmp, idx, GEN_INT (width)));
+  emit_insn (gen_subsi3 (tmp, GEN_INT (24 - width), tmp));
+}
+
+  /*  lxv vs33, mask.
+  DImode: 0x
+  SImode: 0x
+  HImode: 0x.
+  QImode: 0x00ff.  */
+  rtx mask = gen_reg_rtx (V16QImode);
+  rtx mask_v2di = gen_reg_rtx (V2DImode);
+  rtvec v = rtvec_alloc (2);
+  if (!BYTES_BIG_ENDIAN)
+{
+  RTVEC_ELT (v, 0) = gen_rtx_CONST_INT (DImode, 0);
+  RTVEC_ELT (v, 1) = gen_r

[PATCH] c++: Distinguish unsatisfaction vs errors during satisfaction [PR97093]

[Patrick Palka via Gcc-patches]

During satisfaction, the flag info.noisy() controls three things:
whether to diagnose fatal errors (such as the satisfaction value of an
atom being non-bool); whether to diagnose unsatisfaction; and whether to
bypass the satisfaction cache.

This flag turns out to be too coarse however, for sometimes we need to
diagnose fatal errors but not unsatisfaction, in particular when replaying
an erroneous satisfaction result from constraint_satisfaction_value,
evaluate_concept_check and tsubst_nested_requirement.

And we sometimes need to bypass the satisfaction cache but not diagnose
unsatisfaction, in particular when evaluating the branches of a
disjunction when info.noisy() is true.  Currently, satisfy_disjunction
first quietly evaluates each branch, but doing so causes satisfy_atom
to insert re-normalized atoms into the satisfaction cache when
diagnosing unsatisfaction of the overall constraint.  This is ultimately
the source of PR97093.

To that end, this patch adds the info.diagnose_unsatisfaction_p() flag
which refines the info.noisy() flag.  During satisfaction info.noisy()
now controls whether to diagnose fatal errors, and
info.diagnose_unsatisfaction_p() controls whether to additionally
diagnose unsatisfaction.  This enables us to address the above two
issues straightforwardly.

This flag refinement also allows us to fold the diagnose_foo_requirement
routines into the corresponding tsubst_foo_requirement ones.  Here, the
flags take on slightly different meanings: info.noisy() controls whether
to diagnose invalid types and expressions inside the requires-expression,
and info.diagnose_unsatisfaction_p() controls whether to diagnose the
overall unsatisfaction of the requires-expression.

Bootstrapped and regtested on x86_64-pc-linux-gnu, and also tested on
cmcstl2 and range-v3.  Does this look OK for trunk?

gcc/cp/ChangeLog:

PR c++/97093
* constraint.cc (struct sat_info): Define.
(tsubst_valid_expression_requirement): Take a sat_info instead
of subst_info.  Perform the substitution quietly first.  Fold in
error-replaying code from diagnose_valid_expression.
(tsubst_simple_requirement): Take a sat_info instead of
subst_info.
(tsubst_type_requirement_1): New.  Fold in error-replaying code
from diagnose_valid_type.
(tsubst_type_requirement): Use it. Take a sat_info instead of
subst_info.
(tsubst_compound_requirement): Likewise.  Fold in
error-replaying code from diagnose_compound_requirement.
(tsubst_nested_requirement): Take a sat_info instead of
subst_info.  Perform the substitution quietly first.  Fold in
error-replaying code from diagnose_nested_requirement.
(tsubst_requirement): Take a sat_info instead of subst_info.
(tsubst_requirement_body): Likewise.
(tsubst_requires_expr): Split into two versions, one that takes
a sat_info argument and another that takes a complain and
in_decl argument.  Remove outdated documentation.  Document he
effects of the sat_info argument.
(tsubst_parameter_mapping): Take a sat_info instead of a
subst_info.
(satisfy_conjunction): Likewise.
(satisfy_disjunction): Likewise.  Evaluate each branch with
unsatisfaction diagnostics disabled rather than completely
quietly, and short circuit when an erroneous branch is
encountered.
(satisfy_atom):  Take a sat_info instead of a subst_info.  Fix a
comment.  Use diagnose_unsatisfaction_p() instead of noisy() to
guard replaying of satisfaction failure.  Always check
constantness quietly first and consistently return
error_mark_node when the value is non-constant.
(satisfy_constraint_r): Document the effects of the sat_info
argument.  Take a sat_info instead of a subst_info.
(satisfy_constraint): Take a sat_info instead of a subst_info.
(satisfy_associated_constraints): Likewise.
(satisfy_constraint_expression): Likewise.
(satisfy_declaration_constraints): Likewise.
(constraint_satisfaction_value): Likewise.  Adjust.  XXX
(constraints_satisfied_p): Adjust.
(evaluate_concept_check): Adjust.
(diagnose_trait_expr): Make static.  Take a template args vector
instead of a parameter mapping.
(diagnose_atomic_constraint): Take a sat_info instead of a
subst_info.  Adjust call to diagnose_trait_expr.  Call
tsubst_requires_expr instead of diagnose_requires_expr.
(diagnose_constraints): Adjust calls to
constraint_satisfaction_value.
(diagnose_valid_expression): Remove.
(diagnose_valid_type): Likewise.
(diagnose_simple_requirement): Likewise.
(diagnose_compound_requirement): Likewise.
(diagnose_type_requirement): Likewise.
(diagnose_nested_requirement): Likewise.
(diagnose_requirement): Likewise.
   

Re: [PATCH] c++: v3: Add __builtin_bit_cast to implement std::bit_cast [PR93121]

[Jason Merrill via Gcc-patches]

On 11/26/20 10:09 AM, Jakub Jelinek wrote:

Sorry, thought I had replied to this before.


The following patch removes the mask from the new native_interpret_aggregate
moved to fold-const.c altogether.  Instead, the code uses the
__builtin_clear_padding infrastructure (new entrypoint in there).
If native_interpret_aggregate succeeds (returns non-NULL), then
what we have in mask from the earlier native_encode_initializer call is
0 bits if they are well defined in argument and 1 bits for indeterminate
bits.  The new clear_type_padding_in_mask function then clears all bits
which are padding in the given type (the destination type), so if any bits
remain in the mask, it means we are using indeterminate bits and C++ FE
can diagnose it.  The bit-cast* tests didn't change at all.


Great, thanks.


+  if (can_native_interpret_type_p (TREE_TYPE (t)))
+if (tree r = native_interpret_expr (TREE_TYPE (t), ptr, len))
+  {
+   for (int i = 0; i < len; i++)
+ if (mask[i])
+   {
+ if (!ctx->quiet)
+   error_at (loc, "%qs accessing uninitialized byte at offset %d",
+ "__builtin_bit_cast", i);
+ *non_constant_p = true;
+ r = t;
+ break;
+   }
+   if (ptr != buf)
+ XDELETE (ptr);
+   return r;
+  }
+
+  if (TREE_CODE (TREE_TYPE (t)) == RECORD_TYPE)
+{
+  tree r = native_interpret_aggregate (TREE_TYPE (t), ptr, 0, len);
+  if (r != NULL_TREE)
+   {
+ clear_type_padding_in_mask (TREE_TYPE (t), mask);
+ for (int i = 0; i < len; i++)
+   if (mask[i])
+ {
+   if (!ctx->quiet)
+ error_at (loc, "%qs accessing uninitialized byte at offset "
+"%d", "__builtin_bit_cast", i);
+   *non_constant_p = true;
+   r = t;
+   break;
+ }
+ if (ptr != buf)
+   XDELETE (ptr);
+ return r;
+   }
+}


There's a lot of code that can be shared between these two cases now. 
The C++ bits are OK with that change.


Jason

[PATCH] [X86_64]: Enable support for next generation AMD Zen3 CPU

[Kumar, Venkataramanan via Gcc-patches]

[AMD Official Use Only - Internal Distribution Only]

Hi Maintainers,

PFA, the patch that enables support for the next generation AMD Zen3 CPU via 
-march=znver3.
This is a very basic enablement patch. As of now the cost, tuning and scheduler 
changes are kept same as znver2.
Further changes to the cost and tunings will be done later.

Ok for trunk ?

Regards,
Venkat.


X86_64-Enable-support-for-next-generation-AMD-Znver3.patch
Description: X86_64-Enable-support-for-next-generation-AMD-Znver3.patch

Re: [PATCH] [X86_64]: Enable support for next generation AMD Zen3 CPU

[Uros Bizjak via Gcc-patches]

The message says that it is for internal distribution. Please repost.

Thanks,
Uros.

On Thu, Dec 3, 2020 at 4:11 PM Kumar, Venkataramanan
 wrote:
>
> [AMD Official Use Only - Internal Distribution Only]
>
>
> Hi Maintainers,
>
>
>
> PFA, the patch that enables support for the next generation AMD Zen3 CPU via 
> -march=znver3.
>
> This is a very basic enablement patch. As of now the cost, tuning and 
> scheduler changes are kept same as znver2.
>
> Further changes to the cost and tunings will be done later.
>
>
>
> Ok for trunk ?
>
>
>
> Regards,
>
> Venkat.

RE: [PATCH] [X86_64]: Enable support for next generation AMD Zen3 CPU

[Kumar, Venkataramanan via Gcc-patches]

[AMD Public Use]

Thanks Uros, I forgot to change.

Please ignore this thread . I will send fresh  one.

Regards,
Venkat.

-Original Message-
From: Uros Bizjak  
Sent: Thursday, December 3, 2020 8:44 PM
To: Kumar, Venkataramanan 
Cc: gcc-patches@gcc.gnu.org; Jan Hubicka 
Subject: Re: [PATCH] [X86_64]: Enable support for next generation AMD Zen3 CPU

[CAUTION: External Email]

The message says that it is for internal distribution. Please repost.

Thanks,
Uros.

On Thu, Dec 3, 2020 at 4:11 PM Kumar, Venkataramanan 
 wrote:
>
> [AMD Official Use Only - Internal Distribution Only]
>
>
> Hi Maintainers,
>
>
>
> PFA, the patch that enables support for the next generation AMD Zen3 CPU via 
> -march=znver3.
>
> This is a very basic enablement patch. As of now the cost, tuning and 
> scheduler changes are kept same as znver2.
>
> Further changes to the cost and tunings will be done later.
>
>
>
> Ok for trunk ?
>
>
>
> Regards,
>
> Venkat.

[PATCH] [X86_64]: Enable support for next generation AMD Zen3 CPU

[Kumar, Venkataramanan via Gcc-patches]

[AMD Public Use]


Hi Maintainers,

PFA, the patch that enables support for the next generation AMD Zen3 CPU via 
-march=znver3.
This is a very basic enablement patch. As of now the cost, tuning and scheduler 
changes are kept same as znver2.
Further changes to the cost and tunings will be done later.

Ok for trunk ?

Regards,
Venkat.



X86_64-Enable-support-for-next-generation-AMD-Znver3.patch
Description: X86_64-Enable-support-for-next-generation-AMD-Znver3.patch

[committed] aarch64: Don't fold svundef* at the gimple level

[Richard Sandiford via Gcc-patches]

As the testcase shows, folding svundef*() at the gimple level
has the unfortunate side-effect of introducing -Wuninitialized
or -Wmaybe-uninitialized warnings.  We don't have a testcase
that relies on the fold, so the easiest fix seems to be to
remove it.

Tested on aarch64-linux-gnu and aarch64_be-elf, pushed.

Thanks,
Richard


gcc/
* config/aarch64/aarch64-sve-builtins-base.cc (svundef_impl::fold):
Delete.

gcc/testsuite/
* gcc.target/aarch64/sve/acle/general/undef_1.c: New test.
---
 gcc/config/aarch64/aarch64-sve-builtins-base.cc  | 11 ---
 .../gcc.target/aarch64/sve/acle/general/undef_1.c| 12 
 2 files changed, 12 insertions(+), 11 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/aarch64/sve/acle/general/undef_1.c

diff --git a/gcc/config/aarch64/aarch64-sve-builtins-base.cc 
b/gcc/config/aarch64/aarch64-sve-builtins-base.cc
index 9b63ea76ecd..4223125cd5e 100644
--- a/gcc/config/aarch64/aarch64-sve-builtins-base.cc
+++ b/gcc/config/aarch64/aarch64-sve-builtins-base.cc
@@ -2295,17 +2295,6 @@ public:
   CONSTEXPR svundef_impl (unsigned int vectors_per_tuple)
 : quiet (vectors_per_tuple) {}
 
-  gimple *
-  fold (gimple_folder &f) const OVERRIDE
-  {
-/* Don't fold svundef at the gimple level.  There's no exact
-   correspondence for SSA_NAMEs, and we explicitly don't want
-   to generate a specific value (like an all-zeros vector).  */
-if (vectors_per_tuple () == 1)
-  return NULL;
-return gimple_build_assign (f.lhs, build_clobber (TREE_TYPE (f.lhs)));
-  }
-
   rtx
   expand (function_expander &e) const OVERRIDE
   {
diff --git a/gcc/testsuite/gcc.target/aarch64/sve/acle/general/undef_1.c 
b/gcc/testsuite/gcc.target/aarch64/sve/acle/general/undef_1.c
new file mode 100644
index 000..793593b662c
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/sve/acle/general/undef_1.c
@@ -0,0 +1,12 @@
+/* { dg-options "-O2 -W -Wall -Werror" } */
+
+#include 
+
+svfloat32x2_t
+foo (svfloat32_t x, svfloat32_t y)
+{
+  svfloat32x2_t res = svundef2_f32 ();
+  res = svset2 (res, 0, x);
+  res = svset2 (res, 1, y);
+  return res;
+}

Re: OpenMP patch ping ** 2

[Tobias Burnus]

Hi,

I would like to ping the following OpenMP-related patches:

On 27.11.20 17:09, Tobias Burnus wrote:


OpenMP-related patch pings:

Kwok's:
* Re: [PATCH] openmp: Implicit 'declare target' for C++ static
initializers
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559624.html

* openmp: Add OpenMP 5.0 task detach clause support
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558752.html

* RFC:
  Nested declare target support
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559758.html

Chung-Lin's:
* [PATCH v2, OpenMP 5, C++] Implement implicit mapping of this[:1]
(PR92120)
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558975.html

My:
* [Patch] OpenMP: C/C++ parse 'omp allocate'
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559930.html

Julian's
* Re: [PATCH] nvptx: Cache stacks block for OpenMP kernel launch
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559044.html



Tobias

-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter

c++: Fix array type dependency [PR 98107]

[Nathan Sidwell]

I'd missed somepaths through build_cplus_array_type, plus, some
arrays come via the C-type builder.  This propagates dependencyin
more places and asserts that in the cases where TYPE_DEPENDENT_P_VALID
is unset, the type is non-dependent.

PR c++/98107
gcc/cp/
* tree.c (build_cplus_array_type): Mark dependency of new variant.
(cp_build_qualified_type_real, strip_typedefs): Assert
TYPE_DEPENDENT_P_VALID, or not a dependent type.

--
Nathan Sidwell
diff --git c/gcc/cp/tree.c w/gcc/cp/tree.c
index 5932777be04..4f28e6d49fd 100644
--- c/gcc/cp/tree.c
+++ w/gcc/cp/tree.c
@@ -1076,6 +1076,9 @@ build_cplus_array_type (tree elt_type, tree index_type, int dependent)
 {
   bool typeless_storage = is_byte_access_type (elt_type);
   t = build_array_type (elt_type, index_type, typeless_storage);
+
+  /* Mark as non-dependenty now, this will save time later.  */
+  TYPE_DEPENDENT_P_VALID (t) = true;
 }
 
   /* Now check whether we already have this array variant.  */
@@ -1090,6 +1093,9 @@ build_cplus_array_type (tree elt_type, tree index_type, int dependent)
   if (!t)
 	{
 	  t = build_min_array_type (elt_type, index_type);
+	  /* Mark dependency now, this saves time later.  */
+	  TYPE_DEPENDENT_P_VALID (t) = true;
+	  TYPE_DEPENDENT_P (t) = dependent;
 	  set_array_type_canon (t, elt_type, index_type, dependent);
 	  if (!dependent)
 	{
@@ -1326,6 +1332,8 @@ cp_build_qualified_type_real (tree type,
 
   if (!t)
 	{
+	  gcc_checking_assert (TYPE_DEPENDENT_P_VALID (type)
+			   || !dependent_type_p (type));
 	  t = build_cplus_array_type (element_type, TYPE_DOMAIN (type),
   TYPE_DEPENDENT_P (type));
 
@@ -1563,6 +1571,8 @@ strip_typedefs (tree t, bool *remove_attributes, unsigned int flags)
 case ARRAY_TYPE:
   type = strip_typedefs (TREE_TYPE (t), remove_attributes, flags);
   t0  = strip_typedefs (TYPE_DOMAIN (t), remove_attributes, flags);
+  gcc_checking_assert (TYPE_DEPENDENT_P_VALID (t)
+			   || !dependent_type_p (t));
   result = build_cplus_array_type (type, t0, TYPE_DEPENDENT_P (t));
   break;
 case FUNCTION_TYPE:

[Committed] IBM Z: Fix mode in probe_stack pattern

[Andreas Krebbel via Gcc-patches]

The probe pattern uses Pmode but the middle-end wants to emit a
word_mode probe check.  This - as usual - breaks on Z with -m31 -mzarch
were word_mode doesn't match Pmode.

Bootstrapped and regression-tested on s390x.

gcc/ChangeLog:

* config/s390/s390.md ("@probe_stack2"): Change mode
iterator to W.

gcc/testsuite/ChangeLog:

* gcc.target/s390/stack-clash-4.c: New test.
---
 gcc/config/s390/s390.md   |  6 +++---
 gcc/testsuite/gcc.target/s390/stack-clash-4.c | 10 ++
 2 files changed, 13 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/s390/stack-clash-4.c

diff --git a/gcc/config/s390/s390.md b/gcc/config/s390/s390.md
index d4cfbdf6732..d6d8965a740 100644
--- a/gcc/config/s390/s390.md
+++ b/gcc/config/s390/s390.md
@@ -6,8 +6,8 @@ (define_expand "allocate_stack"
 
 (define_expand "@probe_stack2"
   [(set (reg:CCZ CC_REGNUM)
-   (compare:CCZ (reg:P 0)
-(match_operand 0 "memory_operand")))
+   (compare:CCZ (reg:W 0)
+(match_operand:W 0 "memory_operand")))
(unspec_volatile [(const_int 0)] UNSPECV_BLOCKAGE)]
   "")
 
@@ -11125,7 +11125,7 @@ (define_expand "probe_stack"
   [(match_operand 0 "memory_operand")]
   ""
 {
-  emit_insn (gen_probe_stack2 (Pmode, operands[0]));
+  emit_insn (gen_probe_stack2 (word_mode, operands[0]));
   DONE;
 })
 
diff --git a/gcc/testsuite/gcc.target/s390/stack-clash-4.c 
b/gcc/testsuite/gcc.target/s390/stack-clash-4.c
new file mode 100644
index 000..619d99ddf69
--- /dev/null
+++ b/gcc/testsuite/gcc.target/s390/stack-clash-4.c
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-options "-O1 -m31 -mzarch -fstack-clash-protection" } */
+
+extern void c(char*);
+
+void
+a() {
+  char *b = __builtin_alloca(3);
+  c(b);
+}
-- 
2.28.0

Re: How to traverse all the local variables that declared in the current routine?

[Qing Zhao via Gcc-patches]

> On Dec 3, 2020, at 2:45 AM, Richard Biener  wrote:
> 
> On Wed, Dec 2, 2020 at 4:36 PM Qing Zhao  > wrote:
>> 
>> 
>> 
>> On Dec 2, 2020, at 2:45 AM, Richard Biener  
>> wrote:
>> 
>> On Tue, Dec 1, 2020 at 8:49 PM Qing Zhao  wrote:
>> 
>> 
>> Hi, Richard,
>> 
>> Could you please comment on the following approach:
>> 
>> Instead of adding the zero-initializer quite late at the pass “pass_expand”, 
>> we can add it as early as during gimplification.
>> However, we will mark these new added zero-initializers as “artificial”. And 
>> passing this “artificial” information to
>> “pass_early_warn_uninitialized” and “pass_late_warn_uninitialized”, in these 
>> two uninitialized variable analysis passes,
>> (i.e., in tree-sea-uninit.c) We will update the checking on 
>> “ssa_undefined_value_p”  to consider “artificial” zero-initializers.
>> (i.e, if the def_stmt is marked with “artificial”, then it’s a undefined 
>> value).
>> 
>> With such approach, we should be able to address all those conflicts.
>> 
>> Do you see any obvious issue with this approach?
>> 
>> 
>> Yes, DSE will happily elide an explicit zero-init following the
>> artificial one leading to false uninit diagnostics.
>> 
>> 
>> Indeed.  This is a big issue. And other optimizations might also be impacted 
>> by the new zero-init, resulting changed behavior
>> of uninitialized analysis in the later stage.
> 
> I don't see how the issue can be resolved, you can't get both, uninit
> warnings and no uninitialized memory.
> People can compile twice, once without -fzero-init to get uninit
> warnings and once with -fzero-init to get
> the extra "security".

So, for GCC, you think that it’s okay to get rid of the following requirement:

C. The implementation needs to keep the current static warning on uninitialized
variables untouched in order to avoid "forking the language”.

Then, we can add explanation in the user documentation of the new -fzero-init 
and also 
that of the -Wuninitialized to inform users that -fzero-init will change the 
behavior of -Wuninitialized.
In order to get the warnings, -fzero-init should not be added at the same time?

With this requirement being eliminated, implementation will be much easier. 

We can add the new initialization during simplification phase. Then this new 
option will work
for all languages.  Is this reasonable?

thanks.

Qing



> 
> Richard.
> 
>> 
>> What's the intended purpose of the zero-init?
>> 
>> 
>> 
>> The purpose of this new option is: (from the original LLVM patch submission):
>> 
>> "Add an option to initialize automatic variables with either a pattern or 
>> with
>> zeroes. The default is still that automatic variables are uninitialized. Also
>> add attributes to request uninitialized on a per-variable basis, mainly to 
>> disable
>> initialization of large stack arrays when deemed too expensive.
>> 
>> This isn't meant to change the semantics of C and C++. Rather, it's meant to 
>> be
>> a last-resort when programmers inadvertently have some undefined behavior in
>> their code. This patch aims to make undefined behavior hurt less, which
>> security-minded people will be very happy about. Notably, this means that
>> there's no inadvertent information leak when:
>> 
>> • The compiler re-uses stack slots, and a value is used uninitialized.
>> • The compiler re-uses a register, and a value is used uninitialized.
>> • Stack structs / arrays / unions with padding are copied.
>> This patch only addresses stack and register information leaks. There's many
>> more infoleaks that we could address, and much more undefined behavior that
>> could be tamed. Let's keep this patch focused, and I'm happy to address 
>> related
>> issues elsewhere."
>> 
>> For more details, please refer to the LLVM code review discussion on this 
>> patch:
>> https://reviews.llvm.org/D54604
>> 
>> 
>> I also wrote a simple writeup for this task based on my study and discussion 
>> with
>> Kees Cook (cc’ing him) as following:
>> 
>> 
>> thanks.
>> 
>> Qing
>> 
>> Support stack variables auto-initialization in GCC
>> 
>> 11/19/2020
>> 
>> Qing Zhao
>> 
>> ===
>> 
>> 
>> ** Background of the task:
>> 
>> The correponding GCC bugzilla RFE was created on 9/3/2018:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87210
>> 
>> A similar option for LLVM (around Nov, 2018)
>> https://lists.llvm.org/pipermail/cfe-dev/2018-November/060172.html
>> had invoked a lot of discussion before committed.
>> 
>> (The following are quoted from the comments of Alexander Potapenko in
>> GCC bug 87210):
>> 
>> Finally, on Oct, 2019, upstream Clang supports force initialization
>> of stack variables under the -ftrivial-auto-var-init flag.
>> 
>> -ftrivial-auto-var-init=pattern initializes local variables with a 0xAA 
>> pattern
>> (actually it's more complicated, see https://reviews.llvm.org/D54604)
>> 
>> -ftrivial-auto-var-init=zero provides zero-initialization of locals.

Go patch committed: Defer to middle-end for complex division

[Ian Lance Taylor via Gcc-patches]

This patch to the Go frontend and libgo defers to the middle-end for
complex division.  Go used to use slightly different semantics than
C99 for complex division, so we used runtime routines to handle the
difference.  The gc compiler has changed its behavior to match C99, so
change ours as well.  This is for https://golang.org/issue/14644.
This requires updating a test as well; the patch attached here does
not include the changes to the generated file
gcc/testsuite/go.test/test/cmplxdivide1.go, as they are large.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
to mainline.

Ian
e9a4798d3c615d1aa576ff76af429a188c6cd90f
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index 183e5cae9c9..f55daf7562c 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-6b01f8cdc11d86bd98165c91d6ae101bcf6b9e1a
+5364d15082de77d2759a01f254208d4cb4f579e3
 
 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/expressions.cc b/gcc/go/gofrontend/expressions.cc
index 23caf61db93..50574c2bc58 100644
--- a/gcc/go/gofrontend/expressions.cc
+++ b/gcc/go/gofrontend/expressions.cc
@@ -6979,27 +6979,6 @@ Binary_expression::do_get_backend(Translate_context* 
context)
   // been converted to a String_concat_expression in do_lower.
   go_assert(!left_type->is_string_type());
 
-  // For complex division Go might want slightly different results than the
-  // backend implementation provides, so we have our own runtime routine.
-  if (this->op_ == OPERATOR_DIV && this->left_->type()->complex_type() != NULL)
-{
-  Runtime::Function complex_code;
-  switch (this->left_->type()->complex_type()->bits())
-   {
-   case 64:
-  complex_code = Runtime::COMPLEX64_DIV;
- break;
-   case 128:
-  complex_code = Runtime::COMPLEX128_DIV;
- break;
-   default:
- go_unreachable();
-   }
-  Expression* complex_div =
-  Runtime::make_call(complex_code, loc, 2, this->left_, this->right_);
-  return complex_div->get_backend(context);
-}
-
   Bexpression* left = this->left_->get_backend(context);
   Bexpression* right = this->right_->get_backend(context);
 
diff --git a/gcc/go/gofrontend/runtime.def b/gcc/go/gofrontend/runtime.def
index 9a3c6809130..4b606a6c00c 100644
--- a/gcc/go/gofrontend/runtime.def
+++ b/gcc/go/gofrontend/runtime.def
@@ -62,12 +62,6 @@ DEF_GO_RUNTIME(STRINGTOSLICERUNE, 
"runtime.stringtoslicerune",
   P2(POINTER, STRING), R1(SLICE))
 
 
-// Complex division.
-DEF_GO_RUNTIME(COMPLEX64_DIV, "__go_complex64_div",
-  P2(COMPLEX64, COMPLEX64), R1(COMPLEX64))
-DEF_GO_RUNTIME(COMPLEX128_DIV, "__go_complex128_div",
-  P2(COMPLEX128, COMPLEX128), R1(COMPLEX128))
-
 // Make a slice.
 DEF_GO_RUNTIME(MAKESLICE, "runtime.makeslice", P3(TYPE, INT, INT),
   R1(POINTER))
diff --git a/gcc/testsuite/go.test/test/cmplxdivide.c 
b/gcc/testsuite/go.test/test/cmplxdivide.c
index 12dc4f1c0c9..89a2868b75b 100644
--- a/gcc/testsuite/go.test/test/cmplxdivide.c
+++ b/gcc/testsuite/go.test/test/cmplxdivide.c
@@ -1,8 +1,19 @@
-// Copyright 2010 The Go Authors.  All rights reserved.
+// Copyright 2010 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.
 
-// gcc '-std=c99' cmplxdivide.c && a.out >cmplxdivide1.go
+// This C program generates the file cmplxdivide1.go. It uses the
+// output of the operations by C99 as the reference to check
+// the implementation of complex numbers in Go.
+// The generated file, cmplxdivide1.go, is compiled along
+// with the driver cmplxdivide.go (the names are confusing
+// and unimaginative) to run the actual test. This is done by
+// the usual test runner.
+//
+// The file cmplxdivide1.go is checked in to the repository, but
+// if it needs to be regenerated, compile and run this C program
+// like this:
+// gcc '-std=c99' cmplxdivide.c && a.out >cmplxdivide1.go
 
 #include 
 #include 
@@ -12,50 +23,63 @@
 #define nelem(x) (sizeof(x)/sizeof((x)[0]))
 
 double f[] = {
-   0,
-   1,
-   -1,
-   2,
+   0.0,
+   -0.0,
+   1.0,
+   -1.0,
+   2.0,
NAN,
INFINITY,
-INFINITY,
 };
 
-char*
-fmt(double g)
-{
+char* fmt(double g) {
static char buf[10][30];
static int n;
char *p;
-   
+
p = buf[n++];
-   if(n == 10)
+   if(n == 10) {
n = 0;
+   }
+
sprintf(p, "%g", g);
-   if(strcmp(p, "-0") == 0)
-   strcpy(p, "negzero");
-   return p;
-}
 
-int
-iscnan(double complex d)
-{
-   return !isinf(creal(d)) && !isinf(cimag(d)) && (isnan(creal(d)) || 
isnan(cimag(d)));
-}
+   if(strcmp(p, "0") == 0) {
+   strcpy(p, "zero");
+   return p;
+   }
+
+   if(strcmp(p, "-0") == 0) {
+  

Go patch committed: Convert comparison function result to expected bool type

[Ian Lance Taylor via Gcc-patches]

This patch to the Go frontend converts the result type of calling a
comparison function to the expected bool type.  Otherwise cases like
type mybool bool
var b mybool = [10]string{} == [10]string{}
get an incorrect type checking error.  Bootstrapped and ran Go
testsuite on x86_64-pc-linux-gnu.  Committed to mainline.

Ian
17c9cf3c17651950bd4bfefcbe15440fa2155810
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index f55daf7562c..cd1a3961a06 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-5364d15082de77d2759a01f254208d4cb4f579e3
+b3a0b068f7fa2d65ba781271b2c0479d103b7d7b
 
 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/expressions.cc b/gcc/go/gofrontend/expressions.cc
index 50574c2bc58..ebe1b36eb53 100644
--- a/gcc/go/gofrontend/expressions.cc
+++ b/gcc/go/gofrontend/expressions.cc
@@ -6287,8 +6287,21 @@ Binary_expression::lower_array_comparison(Gogo* gogo,
   args->push_back(this->operand_address(inserter, this->left_));
   args->push_back(this->operand_address(inserter, this->right_));
 
-  Expression* ret = Expression::make_call(func, args, false, loc);
-
+  Call_expression* ce = Expression::make_call(func, args, false, loc);
+
+  // Record that this is a call to a generated equality function.  We
+  // need to do this because a comparison returns an abstract boolean
+  // type, but the function necessarily returns "bool".  The
+  // difference shows up in code like
+  // type mybool bool
+  // var b mybool = [10]string{} == [10]string{}
+  // The comparison function returns "bool", but since a comparison
+  // has an abstract boolean type we need an implicit conversion to
+  // "mybool".  The implicit conversion is inserted in
+  // Call_expression::do_flatten.
+  ce->set_is_equal_function();
+
+  Expression* ret = ce;
   if (this->op_ == OPERATOR_NOTEQ)
 ret = Expression::make_unary(OPERATOR_NOT, ret, loc);
 
@@ -11163,6 +11176,13 @@ Call_expression::do_flatten(Gogo* gogo, Named_object*,
 return ret;
 }
 
+  // Add an implicit conversion to a boolean type, if needed.  See the
+  // comment in Binary_expression::lower_array_comparison.
+  if (this->is_equal_function_
+  && this->type_ != NULL
+  && this->type_ != Type::lookup_bool_type())
+return Expression::make_cast(this->type_, this, this->location());
+
   return this;
 }
 
@@ -11938,7 +11958,7 @@ Call_expression::do_type()
 // parameter types to set the types of the arguments.
 
 void
-Call_expression::do_determine_type(const Type_context*)
+Call_expression::do_determine_type(const Type_context* context)
 {
   if (!this->determining_types())
 return;
@@ -11985,6 +12005,22 @@ Call_expression::do_determine_type(const Type_context*)
(*pa)->determine_type_no_context();
}
 }
+
+  // If this is a call to a generated equality function, we determine
+  // the type based on the context.  See the comment in
+  // Binary_expression::lower_array_comparison.
+  if (this->is_equal_function_
+  && !context->may_be_abstract
+  && context->type != NULL
+  && context->type->is_boolean_type()
+  && context->type != Type::lookup_bool_type())
+{
+  go_assert(this->type_ == NULL
+   || this->type_ == Type::lookup_bool_type()
+   || this->type_ == context->type
+   || this->type_->is_error());
+  this->type_ = context->type;
+}
 }
 
 // Called when determining types for a Call_expression.  Return true
diff --git a/gcc/go/gofrontend/expressions.h b/gcc/go/gofrontend/expressions.h
index d2975238572..259eeb6027e 100644
--- a/gcc/go/gofrontend/expressions.h
+++ b/gcc/go/gofrontend/expressions.h
@@ -2326,8 +2326,8 @@ class Call_expression : public Expression
   fn_(fn), args_(args), type_(NULL), call_(NULL), call_temp_(NULL)
 , expected_result_count_(0), is_varargs_(is_varargs),
   varargs_are_lowered_(false), types_are_determined_(false),
-  is_deferred_(false), is_concurrent_(false), issued_error_(false),
-  is_multi_value_arg_(false), is_flattened_(false)
+  is_deferred_(false), is_concurrent_(false), is_equal_function_(false),
+  issued_error_(false), is_multi_value_arg_(false), is_flattened_(false)
   { }
 
   // The function to call.
@@ -2408,6 +2408,11 @@ class Call_expression : public Expression
   set_is_concurrent()
   { this->is_concurrent_ = true; }
 
+  // Note that this is a call to a generated equality function.
+  void
+  set_is_equal_function()
+  { this->is_equal_function_ = true; }
+
   // We have found an error with this call expression; return true if
   // we should report it.
   bool
@@ -2545,6 +2550,8 @@ class Call_expression : public Expression
   bool is_deferred_;
   // True if the call is an argument to a go statement.
   bool is_concurrent_;
+  // True if this is a call to a generated equality function.
+  bool is_equal_function_;
   // 

Re: How to traverse all the local variables that declared in the current routine?

[Richard Biener via Gcc-patches]

On December 3, 2020 5:07:28 PM GMT+01:00, Qing Zhao  
wrote:
>
>
>> On Dec 3, 2020, at 2:45 AM, Richard Biener
> wrote:
>> 
>> On Wed, Dec 2, 2020 at 4:36 PM Qing Zhao > wrote:
>>> 
>>> 
>>> 
>>> On Dec 2, 2020, at 2:45 AM, Richard Biener
> wrote:
>>> 
>>> On Tue, Dec 1, 2020 at 8:49 PM Qing Zhao 
>wrote:
>>> 
>>> 
>>> Hi, Richard,
>>> 
>>> Could you please comment on the following approach:
>>> 
>>> Instead of adding the zero-initializer quite late at the pass
>“pass_expand”, we can add it as early as during gimplification.
>>> However, we will mark these new added zero-initializers as
>“artificial”. And passing this “artificial” information to
>>> “pass_early_warn_uninitialized” and “pass_late_warn_uninitialized”,
>in these two uninitialized variable analysis passes,
>>> (i.e., in tree-sea-uninit.c) We will update the checking on
>“ssa_undefined_value_p”  to consider “artificial” zero-initializers.
>>> (i.e, if the def_stmt is marked with “artificial”, then it’s a
>undefined value).
>>> 
>>> With such approach, we should be able to address all those
>conflicts.
>>> 
>>> Do you see any obvious issue with this approach?
>>> 
>>> 
>>> Yes, DSE will happily elide an explicit zero-init following the
>>> artificial one leading to false uninit diagnostics.
>>> 
>>> 
>>> Indeed.  This is a big issue. And other optimizations might also be
>impacted by the new zero-init, resulting changed behavior
>>> of uninitialized analysis in the later stage.
>> 
>> I don't see how the issue can be resolved, you can't get both, uninit
>> warnings and no uninitialized memory.
>> People can compile twice, once without -fzero-init to get uninit
>> warnings and once with -fzero-init to get
>> the extra "security".
>
>So, for GCC, you think that it’s okay to get rid of the following
>requirement:
>
>C. The implementation needs to keep the current static warning on
>uninitialized
>variables untouched in order to avoid "forking the language”.
>
>Then, we can add explanation in the user documentation of the new
>-fzero-init and also 
>that of the -Wuninitialized to inform users that -fzero-init will
>change the behavior of -Wuninitialized.
>In order to get the warnings, -fzero-init should not be added at the
>same time?
>
>With this requirement being eliminated, implementation will be much
>easier. 
>
>We can add the new initialization during simplification phase. Then
>this new option will work
>for all languages.  Is this reasonable?

I think that's reasonable indeed. Eventually doing the init after the early 
uninit pass is possible as well.

Richard. 

>thanks.
>
>Qing
>
>
>
>> 
>> Richard.
>> 
>>> 
>>> What's the intended purpose of the zero-init?
>>> 
>>> 
>>> 
>>> The purpose of this new option is: (from the original LLVM patch
>submission):
>>> 
>>> "Add an option to initialize automatic variables with either a
>pattern or with
>>> zeroes. The default is still that automatic variables are
>uninitialized. Also
>>> add attributes to request uninitialized on a per-variable basis,
>mainly to disable
>>> initialization of large stack arrays when deemed too expensive.
>>> 
>>> This isn't meant to change the semantics of C and C++. Rather, it's
>meant to be
>>> a last-resort when programmers inadvertently have some undefined
>behavior in
>>> their code. This patch aims to make undefined behavior hurt less,
>which
>>> security-minded people will be very happy about. Notably, this means
>that
>>> there's no inadvertent information leak when:
>>> 
>>> • The compiler re-uses stack slots, and a value is used
>uninitialized.
>>> • The compiler re-uses a register, and a value is used
>uninitialized.
>>> • Stack structs / arrays / unions with padding are copied.
>>> This patch only addresses stack and register information leaks.
>There's many
>>> more infoleaks that we could address, and much more undefined
>behavior that
>>> could be tamed. Let's keep this patch focused, and I'm happy to
>address related
>>> issues elsewhere."
>>> 
>>> For more details, please refer to the LLVM code review discussion on
>this patch:
>>> https://reviews.llvm.org/D54604
>>> 
>>> 
>>> I also wrote a simple writeup for this task based on my study and
>discussion with
>>> Kees Cook (cc’ing him) as following:
>>> 
>>> 
>>> thanks.
>>> 
>>> Qing
>>> 
>>> Support stack variables auto-initialization in GCC
>>> 
>>> 11/19/2020
>>> 
>>> Qing Zhao
>>> 
>>> ===
>>> 
>>> 
>>> ** Background of the task:
>>> 
>>> The correponding GCC bugzilla RFE was created on 9/3/2018:
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87210
>>> 
>>> A similar option for LLVM (around Nov, 2018)
>>> https://lists.llvm.org/pipermail/cfe-dev/2018-November/060172.html
>>> had invoked a lot of discussion before committed.
>>> 
>>> (The following are quoted from the comments of Alexander Potapenko
>in
>>> GCC bug 87210):
>>> 
>>> Finally, on Oct, 2019, upstream Clang supports force initialization
>>> of stack variab

Re: How to traverse all the local variables that declared in the current routine?

[Qing Zhao via Gcc-patches]

> On Dec 3, 2020, at 10:36 AM, Richard Biener  
> wrote:
> 
> On December 3, 2020 5:07:28 PM GMT+01:00, Qing Zhao  > wrote:
>> 
>> 
 of uninitialized analysis in the later stage.
>>> 
>>> I don't see how the issue can be resolved, you can't get both, uninit
>>> warnings and no uninitialized memory.
>>> People can compile twice, once without -fzero-init to get uninit
>>> warnings and once with -fzero-init to get
>>> the extra "security".
>> 
>> So, for GCC, you think that it’s okay to get rid of the following
>> requirement:
>> 
>> C. The implementation needs to keep the current static warning on
>> uninitialized
>> variables untouched in order to avoid "forking the language”.
>> 
>> Then, we can add explanation in the user documentation of the new
>> -fzero-init and also 
>> that of the -Wuninitialized to inform users that -fzero-init will
>> change the behavior of -Wuninitialized.
>> In order to get the warnings, -fzero-init should not be added at the
>> same time?
>> 
>> With this requirement being eliminated, implementation will be much
>> easier. 
>> 
>> We can add the new initialization during simplification phase. Then
>> this new option will work
>> for all languages.  Is this reasonable?
> 
> I think that's reasonable indeed. Eventually doing the init after the early 
> uninit pass is possible as well.

You suggested to put the new pass after the early uninit pass? Why?

Qing
> 
> Richard. 
> 
>> thanks.
>> 
>> Qing
>> 
>> 
>> 
>>> 
>>> 

Re: c++: Fix array type dependency [PR 98107]

[Nathan Sidwell]

These two testcases provide coverage for 98115,	which doesn't trigger on 
all hosts.


PR c++/98115
PR c++/98116
gcc/testsuite/
* g++.dg/template/pr98115.C: New.
* g++.dg/template/pr98116.C: New.


nathan

--
Nathan Sidwell
diff --git c/gcc/testsuite/g++.dg/template/pr98115.C w/gcc/testsuite/g++.dg/template/pr98115.C
new file mode 100644
index 000..0bfc57ab88e
--- /dev/null
+++ w/gcc/testsuite/g++.dg/template/pr98115.C
@@ -0,0 +1,4 @@
+// PR 98115, dependent array types lead to specialization issues
+
+template  class Stringify;
+template  class Stringify;
diff --git c/gcc/testsuite/g++.dg/template/pr98116.C w/gcc/testsuite/g++.dg/template/pr98116.C
new file mode 100644
index 000..d3398d2238c
--- /dev/null
+++ w/gcc/testsuite/g++.dg/template/pr98116.C
@@ -0,0 +1,29 @@
+// PR 98116, ICE with stripping typedef array type
+// { dg-do compile { target c++11 } }
+namespace std {
+struct is_convertible;
+template  using remove_pointer_t = typename _Tp ::type;
+template  struct enable_if;
+template  void declval();
+template  using enable_if_t = typename enable_if<_Cond>::type;
+template  class Trans_NS___cxx11_basic_string {
+  long _M_string_length;
+};
+} // namespace std
+struct string16_char_traits;
+template class std::Trans_NS___cxx11_basic_string;
+template  using IsLegalDataConversion = std::is_convertible;
+template 
+using ContainerHasConvertibleData = IsLegalDataConversion<
+std::remove_pointer_t)>, T>;
+template 
+using EnableIfSpanCompatibleArray =
+std::enable_if_t::value>;
+template  class span {
+  template [N],
+std::Trans_NS___cxx11_basic_string, Extent>>
+  span();
+};

Re: introduce overridable clear_cache emitter

[Jeff Law via Gcc-patches]

On 12/3/20 7:08 AM, Alexandre Oliva wrote:
> On Dec  3, 2020, Christophe Lyon  wrote:
>
>> This patches causes a lot of regressions in fortran on arm and aarch64,
> On Dec  3, 2020, Andreas Schwab  wrote:
>
>> On Dez 03 2020, Andreas Schwab wrote:
>>> ../../../../libffi/src/aarch64/ffi.c: In function 'ffi_prep_closure_loc':
>>> ../../../../libffi/src/aarch64/ffi.c:67:3: error: both arguments to 
>>> '__builtin___clear_cache' must be pointers
>>> 67 |   __builtin___clear_cache (start, end);
>>> |   ^~~~
>> This happens when compiling with -mabi=ilp32.
> Thank you both.  Here's the patch I'm testing to fix both issues.
> Ok to install?
>
>
> fix __builtin___clear_cache overrider fallout
>
> From: Alexandre Oliva 
>
> Machines that had CLEAR_CACHE_INSN and that would thus issue calls to
> __clear_cache with the default call expander, would fail on languages
> that did not set up the __clear_cache builtin.  This patch arranges
> for all languages to set up this builtin.
>
> Machines or multilibs that had ptr_mode != Pmode, such as aarch64 with
> -mabi=ilp32, would fail the RTL mode test of the arguments passed to
> __clear_cache, because we'd insist on ptr_mode.  This patch arranges for
> Pmode to be accepted as well.
>
>
> for  gcc/ChangeLog
>
>   * tree.c (build_common_builtin_nodes): Declare
>   __builtin___clear_cache for all languages.
>   * builtins.c (maybe_emit_call_builtin___clear_cache): Accept
>   Pmode arguments.
OK
jeff

Re: How to traverse all the local variables that declared in the current routine?

[Richard Sandiford via Gcc-patches]

Richard Biener via Gcc-patches  writes:
> On December 3, 2020 5:07:28 PM GMT+01:00, Qing Zhao  
> wrote:
>>
>>
>>> On Dec 3, 2020, at 2:45 AM, Richard Biener
>> wrote:
>>> 
>>> On Wed, Dec 2, 2020 at 4:36 PM Qing Zhao >> wrote:
 
 
 
 On Dec 2, 2020, at 2:45 AM, Richard Biener
>> wrote:
 
 On Tue, Dec 1, 2020 at 8:49 PM Qing Zhao 
>>wrote:
 
 
 Hi, Richard,
 
 Could you please comment on the following approach:
 
 Instead of adding the zero-initializer quite late at the pass
>>“pass_expand”, we can add it as early as during gimplification.
 However, we will mark these new added zero-initializers as
>>“artificial”. And passing this “artificial” information to
 “pass_early_warn_uninitialized” and “pass_late_warn_uninitialized”,
>>in these two uninitialized variable analysis passes,
 (i.e., in tree-sea-uninit.c) We will update the checking on
>>“ssa_undefined_value_p”  to consider “artificial” zero-initializers.
 (i.e, if the def_stmt is marked with “artificial”, then it’s a
>>undefined value).
 
 With such approach, we should be able to address all those
>>conflicts.
 
 Do you see any obvious issue with this approach?
 
 
 Yes, DSE will happily elide an explicit zero-init following the
 artificial one leading to false uninit diagnostics.
 
 
 Indeed.  This is a big issue. And other optimizations might also be
>>impacted by the new zero-init, resulting changed behavior
 of uninitialized analysis in the later stage.
>>> 
>>> I don't see how the issue can be resolved, you can't get both, uninit
>>> warnings and no uninitialized memory.
>>> People can compile twice, once without -fzero-init to get uninit
>>> warnings and once with -fzero-init to get
>>> the extra "security".
>>
>>So, for GCC, you think that it’s okay to get rid of the following
>>requirement:
>>
>>C. The implementation needs to keep the current static warning on
>>uninitialized
>>variables untouched in order to avoid "forking the language”.
>>
>>Then, we can add explanation in the user documentation of the new
>>-fzero-init and also 
>>that of the -Wuninitialized to inform users that -fzero-init will
>>change the behavior of -Wuninitialized.
>>In order to get the warnings, -fzero-init should not be added at the
>>same time?
>>
>>With this requirement being eliminated, implementation will be much
>>easier. 
>>
>>We can add the new initialization during simplification phase. Then
>>this new option will work
>>for all languages.  Is this reasonable?
>
> I think that's reasonable indeed. Eventually doing the init after the early 
> uninit pass is possible as well.

Sorry to be awkward, but I kind-of disagree.  IIRC, clang was able to
give uninit warnings while implementing the initialisation as expected,
so I think this is a GCC restriction rather than a fundamental
incompatibility.

I don't think it's reasonable to expect people to read the documentation
of -ffoo for Clang and separately read the documentation of -ffoo for
GCC.  They'll at best read the documentation for one and (rightly)
expect the other compiler to behave in a compatible way.  I'm also not
sure people would build twice in practice.

I remember the issue of forking the language was discussed at length on
the Clang dev list at the time (but I haven't gone back and re-read the
thread, so I'm relying on memory here).  Not forking the language was an
important goal/requirement of the option and I don't think we should
drop it when implementing the option in GCC.

IMO, if we want to define a dialect of C/C++ in which uninitialised uses
are always well defined rather than UB, we should do that as a separate
option.  If we're implementing the Clang options, we should continue
to treat uninitialised uses as UB that triggers the same warnings as
if the option wasn't passed.

So TBH I'd rather not add the option until it can be implemented in a
way that is compatible with Clang.

Thanks,
Richard

c++: templatey type creation

[Nathan Sidwell]

This patch makes a couple of type-creation routines available to
modules.  That needs to create unbound template parms, and canonical
template parms.

gcc/cp/
* cp-tree.h (make_unbound_class_template_raw): Declare.
(canonical_type_parameter): Declare.
* decl.c (make_unbound_class_template_raw): Break out of ...
(make_unboud_class_template): ... here.  Call it.
* pt.c (canonical_type_parameter): Externalize.  Refactor & set
structural_equality for type parms.

pushing to trunk

--
Nathan Sidwell
diff --git i/gcc/cp/cp-tree.h w/gcc/cp/cp-tree.h
index de905dcf37c..69f8ed56e62 100644
--- i/gcc/cp/cp-tree.h
+++ w/gcc/cp/cp-tree.h
@@ -6542,6 +6542,7 @@ extern bool check_omp_return			(void);
 extern tree make_typename_type			(tree, tree, enum tag_types, tsubst_flags_t);
 extern tree build_typename_type			(tree, tree, tree, tag_types);
 extern tree make_unbound_class_template		(tree, tree, tree, tsubst_flags_t);
+extern tree make_unbound_class_template_raw	(tree, tree, tree);
 extern tree build_library_fn_ptr		(const char *, tree, int);
 extern tree build_cp_library_fn_ptr		(const char *, tree, int);
 extern tree push_library_fn			(tree, tree, tree, int);
@@ -6880,6 +6881,7 @@ extern void maybe_show_extern_c_location (void);
 extern bool literal_integer_zerop (const_tree);
 
 /* in pt.c */
+extern tree canonical_type_parameter		(tree);
 extern void push_access_scope			(tree);
 extern void pop_access_scope			(tree);
 extern bool check_template_shadow		(tree);
diff --git i/gcc/cp/decl.c w/gcc/cp/decl.c
index 0cf84a0750c..a28e7924869 100644
--- i/gcc/cp/decl.c
+++ w/gcc/cp/decl.c
@@ -4132,6 +4132,14 @@ make_unbound_class_template (tree context, tree name, tree parm_list,
   return tmpl;
 }
 
+  return make_unbound_class_template_raw (context, name, parm_list);
+}
+
+/* Build an UNBOUND_CLASS_TEMPLATE.  */
+
+tree
+make_unbound_class_template_raw (tree context, tree name, tree parm_list)
+{
   /* Build the UNBOUND_CLASS_TEMPLATE.  */
   tree t = cxx_make_type (UNBOUND_CLASS_TEMPLATE);
   TYPE_CONTEXT (t) = FROB_CONTEXT (context);
diff --git i/gcc/cp/pt.c w/gcc/cp/pt.c
index 66ac6473983..3ca28133d94 100644
--- i/gcc/cp/pt.c
+++ w/gcc/cp/pt.c
@@ -4432,7 +4432,7 @@ build_template_parm_index (int index,
parameter.  Returns the canonical type parameter, which may be TYPE
if no such parameter existed.  */
 
-static tree
+tree
 canonical_type_parameter (tree type)
 {
   int idx = TEMPLATE_TYPE_IDX (type);
@@ -13212,19 +13212,24 @@ tsubst_argument_pack (tree orig_arg, tree args, tsubst_flags_t complain,
 		  tree in_decl)
 {
   /* Substitute into each of the arguments.  */
-  tree new_arg = TYPE_P (orig_arg)
-? cxx_make_type (TREE_CODE (orig_arg))
-: make_node (TREE_CODE (orig_arg));
-
   tree pack_args = tsubst_template_args (ARGUMENT_PACK_ARGS (orig_arg),
 	 args, complain, in_decl);
-  if (pack_args == error_mark_node)
-new_arg = error_mark_node;
-  else
-SET_ARGUMENT_PACK_ARGS (new_arg, pack_args);
+  tree new_arg = error_mark_node;
+  if (pack_args != error_mark_node)
+{
+  if (TYPE_P (orig_arg))
+	{
+	  new_arg = cxx_make_type (TREE_CODE (orig_arg));
+	  SET_TYPE_STRUCTURAL_EQUALITY (new_arg);
+	}
+  else
+	{
+	  new_arg = make_node (TREE_CODE (orig_arg));
+	  TREE_CONSTANT (new_arg) = TREE_CONSTANT (orig_arg);
+	}
 
-  if (TREE_CODE (new_arg) == NONTYPE_ARGUMENT_PACK)
-TREE_CONSTANT (new_arg) = TREE_CONSTANT (orig_arg);
+  SET_ARGUMENT_PACK_ARGS (new_arg, pack_args);
+}
 
   return new_arg;
 }

[PATCH v2]: i386: Fix up ix86_md_asm_adjust for TImode [PR98086]

[Uros Bizjak via Gcc-patches]

ix86_md_asm_adjust assumes that dest_mode can be only [QHSD]Imode
and nothing else.  The patch rewrites zero-extension part to use
convert_to_mode to handle TImode and hypothetically even wider modes.

2020-12-03  Uroš Bizjak  
Jakub Jelinek  

gcc/
PR target/98086
* config/i386/i386.c (ix86_md_asm_adjustmd): Rewrite
zero-extension part to use convert_to_mode.

gcc/testsuite/
PR target/98086
* gcc.target/i386/pr98086.c: New test.

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

Pushed to master, will be backported to gcc-10 and gcc-9.

Uros.
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index c5db8c9712e..63216782430 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -21508,40 +21508,18 @@ ix86_md_asm_adjust (vec &outputs, vec 
&/*inputs*/,
  continue;
}
 
-  if (dest_mode == DImode && !TARGET_64BIT)
-   dest_mode = SImode;
-
-  if (dest_mode != QImode)
-   {
- rtx destqi = gen_reg_rtx (QImode);
- emit_insn (gen_rtx_SET (destqi, x));
-
- if (TARGET_ZERO_EXTEND_WITH_AND
- && optimize_function_for_speed_p (cfun))
-   {
- x = force_reg (dest_mode, const0_rtx);
-
- emit_insn (gen_movstrictqi (gen_lowpart (QImode, x), destqi));
-   }
- else
-   {
- x = gen_rtx_ZERO_EXTEND (dest_mode, destqi);
- if (dest_mode == GET_MODE (dest)
- && !register_operand (dest, GET_MODE (dest)))
-   x = force_reg (dest_mode, x);
-   }
-   }
-
-  if (dest_mode != GET_MODE (dest))
+  if (dest_mode == QImode)
+   emit_insn (gen_rtx_SET (dest, x));
+  else
{
- rtx tmp = gen_reg_rtx (SImode);
+ rtx reg = gen_reg_rtx (QImode);
+ emit_insn (gen_rtx_SET (reg, x));
 
- emit_insn (gen_rtx_SET (tmp, x));
- emit_insn (gen_zero_extendsidi2 (dest, tmp));
+ reg = convert_to_mode (dest_mode, reg, 1);
+ emit_move_insn (dest, reg);
}
-  else
-   emit_insn (gen_rtx_SET (dest, x));
 }
+
   rtx_insn *seq = get_insns ();
   end_sequence ();
 
diff --git a/gcc/testsuite/gcc.target/i386/pr98086.c 
b/gcc/testsuite/gcc.target/i386/pr98086.c
new file mode 100644
index 000..254a3b9bef6
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr98086.c
@@ -0,0 +1,17 @@
+/* PR target/98086 */
+/* { dg-do compile } */
+/* { dg-options "" } */
+
+#ifdef __x86_64__
+typedef __int128 T;
+#else
+typedef long long T;
+#endif
+
+T x;
+
+void
+foo (void)
+{
+  __asm ("" : "=@ccc" (x));
+}

Re: [PATCH] implement pre-c++20 contracts

[Andrew Sutton via Gcc-patches]

>
>
> > Attached is a new squashed revision of the patch sans ChangeLogs. The
> > current work is now being done on github:
> > https://github.com/lock3/gcc/tree/contracts-jac-alt
>
> I'm starting to review this now, sorry for the delay. Is this still the
> branch you want me to consider for GCC 11?  I notice that the -constexpr
> and -mangled-config branches are newer.


I think so. Jeff can answer more authoritatively. I know we had one set of
changes to the design (how contracts) work aimed at improving the debugging
experience for violated contracts. I'm not sure if that's in the jac-alt
branch though.

The -constexpr branch checks for trivially satisfied contracts (e.g.,
[[assert: true]]) and issues warnings. It also preemptively checks
preconditions against constant function arguments. It's probably worth
reviewing that separately.

I'm not sure the -manged-config branch is worth considering for merging at
this point. It's trying to solve a problem that might not be worth solving.

Out of curiosity, are you concerned that future versions of contracts might
have considerably different syntax or configurability? I'd hope it
wouldn't, but who knows where SG21 is going :)

Andrew

[PATCH][GCC10][1/6] arm: Add vld1_lane_bf16 + vldq_lane_bf16 intrinsics

[Andrea Corallo via Gcc-patches]

Hi all,

first patch of the series to backport a number of bfloat16 intrinsics from
trunk to gcc-10.

These patch are including the fixes to the tests that we have applied
into master.

Please see refer to:
ACLE 
ISA  

The serie has been bootstrapped on arm-linux-gnueabihf and regtested.

Okay for gcc-10?

Thanks

  Andrea
>From 7b2080b71405918769811174082646219d23163c Mon Sep 17 00:00:00 2001
From: Andrea Corallo 
Date: Wed, 21 Oct 2020 11:16:01 +0200
Subject: [PATCH 1/6] arm: Add vld1_lane_bf16 + vldq_lane_bf16 intrinsics

gcc/ChangeLog

2020-10-21  Andrea Corallo  

* config/arm/arm_neon_builtins.def: Add to LOAD1LANE v4bf, v8bf.
* config/arm/arm_neon.h (vld1_lane_bf16, vld1q_lane_bf16): Add
intrinsics.

gcc/testsuite/ChangeLog

2020-10-21  Andrea Corallo  

* gcc.target/arm/simd/vld1_lane_bf16_1.c: New testcase.
* gcc.target/arm/simd/vld1_lane_bf16_indices_1.c: Likewise.
* gcc.target/arm/simd/vld1q_lane_bf16_indices_1.c: Likewise.
---
 gcc/config/arm/arm_neon.h | 14 
 gcc/config/arm/arm_neon_builtins.def  |  4 ++--
 .../gcc.target/arm/simd/vld1_lane_bf16_1.c| 22 +++
 .../arm/simd/vld1_lane_bf16_indices_1.c   | 19 
 .../arm/simd/vld1q_lane_bf16_indices_1.c  | 19 
 5 files changed, 76 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/arm/simd/vld1_lane_bf16_1.c
 create mode 100644 gcc/testsuite/gcc.target/arm/simd/vld1_lane_bf16_indices_1.c
 create mode 100644 
gcc/testsuite/gcc.target/arm/simd/vld1q_lane_bf16_indices_1.c

diff --git a/gcc/config/arm/arm_neon.h b/gcc/config/arm/arm_neon.h
index aa21730dea0..fcd8020425e 100644
--- a/gcc/config/arm/arm_neon.h
+++ b/gcc/config/arm/arm_neon.h
@@ -19665,6 +19665,20 @@ vld4q_dup_bf16 (const bfloat16_t * __ptr)
   return __rv.__i;
 }
 
+__extension__ extern __inline bfloat16x4_t
+__attribute__  ((__always_inline__, __gnu_inline__, __artificial__))
+vld1_lane_bf16 (const bfloat16_t * __a, bfloat16x4_t __b, const int __c)
+{
+  return __builtin_neon_vld1_lanev4bf (__a, __b, __c);
+}
+
+__extension__ extern __inline bfloat16x8_t
+__attribute__  ((__always_inline__, __gnu_inline__, __artificial__))
+vld1q_lane_bf16 (const bfloat16_t * __a, bfloat16x8_t __b, const int __c)
+{
+  return __builtin_neon_vld1_lanev8bf (__a, __b, __c);
+}
+
 #pragma GCC pop_options
 
 #ifdef __cplusplus
diff --git a/gcc/config/arm/arm_neon_builtins.def 
b/gcc/config/arm/arm_neon_builtins.def
index 34c1945c0a1..d0617a4695d 100644
--- a/gcc/config/arm/arm_neon_builtins.def
+++ b/gcc/config/arm/arm_neon_builtins.def
@@ -312,8 +312,8 @@ VAR1 (TERNOP, vtbx3, v8qi)
 VAR1 (TERNOP, vtbx4, v8qi)
 VAR12 (LOAD1, vld1,
 v8qi, v4hi, v4hf, v2si, v2sf, di, v16qi, v8hi, v8hf, v4si, v4sf, v2di)
-VAR10 (LOAD1LANE, vld1_lane,
-   v8qi, v4hi, v2si, v2sf, di, v16qi, v8hi, v4si, v4sf, v2di)
+VAR12 (LOAD1LANE, vld1_lane,
+   v8qi, v4hi, v2si, v2sf, di, v16qi, v8hi, v4si, v4sf, v2di, v4bf, v8bf)
 VAR10 (LOAD1, vld1_dup,
v8qi, v4hi, v2si, v2sf, di, v16qi, v8hi, v4si, v4sf, v2di)
 VAR12 (STORE1, vst1,
diff --git a/gcc/testsuite/gcc.target/arm/simd/vld1_lane_bf16_1.c 
b/gcc/testsuite/gcc.target/arm/simd/vld1_lane_bf16_1.c
new file mode 100644
index 000..94fb38f32b8
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/simd/vld1_lane_bf16_1.c
@@ -0,0 +1,22 @@
+/* { dg-do assemble } */
+/* { dg-require-effective-target arm_v8_2a_bf16_neon_ok } */
+/* { dg-require-effective-target arm_hard_ok } */
+/* { dg-add-options arm_v8_2a_bf16_neon } */
+/* { dg-additional-options "-O3 --save-temps -mfloat-abi=hard" } */
+
+#include "arm_neon.h"
+
+bfloat16x4_t
+test_vld1_lane_bf16 (bfloat16_t *a, bfloat16x4_t b)
+{
+  return vld1_lane_bf16 (a, b, 1);
+}
+
+bfloat16x8_t
+test_vld1q_lane_bf16 (bfloat16_t *a, bfloat16x8_t b)
+{
+  return vld1q_lane_bf16 (a, b, 2);
+}
+
+/* { dg-final { scan-assembler "vld1.16\t{d0\\\[1\\\]}, \\\[r0\\\]" } } */
+/* { dg-final { scan-assembler "vld1.16\t{d0\\\[2\\\]}, \\\[r0\\\]" } } */
diff --git a/gcc/testsuite/gcc.target/arm/simd/vld1_lane_bf16_indices_1.c 
b/gcc/testsuite/gcc.target/arm/simd/vld1_lane_bf16_indices_1.c
new file mode 100644
index 000..d9af512cf92
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/simd/vld1_lane_bf16_indices_1.c
@@ -0,0 +1,19 @@
+/* { dg-do assemble } */
+/* { dg-require-effective-target arm_v8_2a_bf16_neon_ok } */
+/* { dg-require-effective-target arm_hard_ok } */
+/* { dg-add-options arm_v8_2a_bf16_neon } */
+/* { dg-additional-options "-mfloat-abi=hard" } */
+
+#include "arm_neon.h"
+
+bfloat16x4_t
+test_vld1_lane_bf16 (bfloat16_t *a, bfloat16x4_t b)
+{
+  bfloat16x4_t res;
+  res = vld1_lane_bf16 (a, b, -1);
+  res = vld1_lane_bf16 (a, b, 4);
+  return res;
+}
+
+/* { dg-error "lane -1 out of range 0 - 3" "" { target *-*-* } 0 } */
+/* { dg-error "lane 4 out of rang

[PATCH][GCC10][2/6] arm: Add vst1_lane_bf16 + vstq_lane_bf16 intrinsics

[Andrea Corallo via Gcc-patches]

Hi all,

second patch of the series to backport a number of bfloat16 intrinsics from
trunk to gcc-10.

These patch are including the fixes to the tests that we have applied
into master.

Please see refer to:
ACLE 
ISA  

The series has been bootstrapped on arm-linux-gnueabihf and regtested.

Okay for gcc-10?

Thanks

  Andrea
>From f138006c8e8bcc35f0bfea816dbc34d6256b0912 Mon Sep 17 00:00:00 2001
From: Andrea Corallo 
Date: Fri, 23 Oct 2020 14:21:56 +0200
Subject: [PATCH 2/6] arm: Add vst1_lane_bf16 + vstq_lane_bf16 intrinsics

gcc/ChangeLog

2020-10-23  Andrea Corallo  

* config/arm/arm-builtins.c (VAR14): Define macro.
* config/arm/arm_neon.h (vst1_lane_bf16, vst1q_lane_bf16): Add
intrinsics.
* config/arm/arm_neon_builtins.def (STORE1LANE): Add v4bf, v8bf.

gcc/testsuite/ChangeLog

2020-10-23  Andrea Corallo  

* gcc.target/arm/simd/vst1_lane_bf16_1.c: New testcase.
* gcc.target/arm/simd/vstq1_lane_bf16_indices_1.c: Likewise.
* gcc.target/arm/simd/vst1_lane_bf16_indices_1.c: Likewise.
---
 gcc/config/arm/arm_neon.h | 14 
 gcc/config/arm/arm_neon_builtins.def  |  4 ++--
 .../gcc.target/arm/simd/vst1_lane_bf16_1.c| 22 +++
 .../arm/simd/vst1_lane_bf16_indices_1.c   | 17 ++
 .../arm/simd/vstq1_lane_bf16_indices_1.c  | 17 ++
 5 files changed, 72 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/arm/simd/vst1_lane_bf16_1.c
 create mode 100644 gcc/testsuite/gcc.target/arm/simd/vst1_lane_bf16_indices_1.c
 create mode 100644 
gcc/testsuite/gcc.target/arm/simd/vstq1_lane_bf16_indices_1.c

diff --git a/gcc/config/arm/arm_neon.h b/gcc/config/arm/arm_neon.h
index fcd8020425e..432d77fb272 100644
--- a/gcc/config/arm/arm_neon.h
+++ b/gcc/config/arm/arm_neon.h
@@ -19679,6 +19679,20 @@ vld1q_lane_bf16 (const bfloat16_t * __a, bfloat16x8_t 
__b, const int __c)
   return __builtin_neon_vld1_lanev8bf (__a, __b, __c);
 }
 
+__extension__ extern __inline void
+__attribute__  ((__always_inline__, __gnu_inline__, __artificial__))
+vst1_lane_bf16 (bfloat16_t * __a, bfloat16x4_t __b, const int __c)
+{
+  __builtin_neon_vst1_lanev4bf (__a, __b, __c);
+}
+
+__extension__ extern __inline void
+__attribute__  ((__always_inline__, __gnu_inline__, __artificial__))
+vst1q_lane_bf16 (bfloat16_t * __a, bfloat16x8_t __b, const int __c)
+{
+  __builtin_neon_vst1_lanev8bf (__a, __b, __c);
+}
+
 #pragma GCC pop_options
 
 #ifdef __cplusplus
diff --git a/gcc/config/arm/arm_neon_builtins.def 
b/gcc/config/arm/arm_neon_builtins.def
index d0617a4695d..7a5dae0c4c0 100644
--- a/gcc/config/arm/arm_neon_builtins.def
+++ b/gcc/config/arm/arm_neon_builtins.def
@@ -318,8 +318,8 @@ VAR10 (LOAD1, vld1_dup,
v8qi, v4hi, v2si, v2sf, di, v16qi, v8hi, v4si, v4sf, v2di)
 VAR12 (STORE1, vst1,
v8qi, v4hi, v4hf, v2si, v2sf, di, v16qi, v8hi, v8hf, v4si, v4sf, v2di)
-VAR12 (STORE1LANE, vst1_lane,
-   v8qi, v4hi, v4hf, v2si, v2sf, di, v16qi, v8hi, v8hf, v4si, v4sf, v2di)
+VAR14 (STORE1LANE, vst1_lane,
+   v8qi, v4hi, v4hf, v2si, v2sf, di, v16qi, v8hi, v8hf, v4si, v4sf, v2di, 
v4bf, v8bf)
 VAR13 (LOAD1, vld2,
v8qi, v4hi, v4hf, v2si, v2sf, di, v16qi, v8hi, v8hf, v4si, v4sf, v4bf, 
v8bf)
 VAR9 (LOAD1LANE, vld2_lane,
diff --git a/gcc/testsuite/gcc.target/arm/simd/vst1_lane_bf16_1.c 
b/gcc/testsuite/gcc.target/arm/simd/vst1_lane_bf16_1.c
new file mode 100644
index 000..8564b8fa062
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/simd/vst1_lane_bf16_1.c
@@ -0,0 +1,22 @@
+/* { dg-do assemble } */
+/* { dg-require-effective-target arm_v8_2a_bf16_neon_ok } */
+/* { dg-require-effective-target arm_hard_ok } */
+/* { dg-add-options arm_v8_2a_bf16_neon } */
+/* { dg-additional-options "-O3 --save-temps -mfloat-abi=hard" } */
+
+#include "arm_neon.h"
+
+void
+test_vst1_lane_bf16 (bfloat16_t *a, bfloat16x4_t b)
+{
+  vst1_lane_bf16 (a, b, 1);
+}
+
+void
+test_vst1q_lane_bf16 (bfloat16_t *a, bfloat16x8_t b)
+{
+  vst1q_lane_bf16 (a, b, 2);
+}
+
+/* { dg-final { scan-assembler "vst1.16\t{d0\\\[1\\\]}, \\\[r0\\\]" } } */
+/* { dg-final { scan-assembler "vst1.16\t{d0\\\[2\\\]}, \\\[r0\\\]" } } */
diff --git a/gcc/testsuite/gcc.target/arm/simd/vst1_lane_bf16_indices_1.c 
b/gcc/testsuite/gcc.target/arm/simd/vst1_lane_bf16_indices_1.c
new file mode 100644
index 000..1bd68718d10
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/simd/vst1_lane_bf16_indices_1.c
@@ -0,0 +1,17 @@
+/* { dg-do assemble } */
+/* { dg-require-effective-target arm_v8_2a_bf16_neon_ok } */
+/* { dg-require-effective-target arm_hard_ok } */
+/* { dg-add-options arm_v8_2a_bf16_neon } */
+/* { dg-additional-options "-mfloat-abi=hard" } */
+
+#include "arm_neon.h"
+
+void
+test_vst1_lane_bf16 (bfloat16_t *a, bfloat16x4_t b)
+{
+  vst1_lane_bf16 (a, b, -1);
+  vst1_lane_bf16 (a, b, 4);
+}
+
+/* { dg-error "lane -

Re: [PATCH] 2/2 Remove debug/array

[Jonathan Wakely via Gcc-patches]

On 09/11/20 13:07 +, Jonathan Wakely wrote:

On 08/11/20 15:27 +0100, François Dumont via Libstdc++ wrote:
Following a recent fix on std::array this test started to fail in 
_GLIBCXX_DEBUG mode.


FAIL: 23_containers/array/comparison_operators/96851.cc (test for 
excess errors)


Rather than fixing it and now that __glibcxx_assert is constexpr 
compatible I would like to propose to simply remove 
__gnu_debug::array.


The only code we are losing with this change are the 
_Array_check_nonempty/_Array_check_subscript types. I am not sure 
about the purpose of this code as I saw no impact on tests. Maybe it 
was to avoid assertion in constexpr where the value of the 
expression is not use but there is a test doing that and it does 
produce an assertion.


Note that I am also moving std::array in versioned namespace. It is 
just for consistency so no problem to remove it.


I also manually edited include/Makefile.in cause I do not have the 
proper autoreconf version. Can you regenerate it on your side once 
patch is in ?


    libstdc++: Remove 

    Add _GLIBCXX_ASSERTIONS assert in normal std::array and remove 
__gnu_debug::array

    implementation.

    libstdc++-v3/ChangeLog:

            * include/debug/array: Remove.
            * include/Makefile.am: Remove .
            * include/Makefile.in: Regenerate.
            * include/experimental/functional: Adapt.
            * include/std/array: Move to _GLIBCXX_INLINE_VERSION 
namespace.
            * include/std/functional: Adapt.
            * include/std/span: Adapt.
            * testsuite/23_containers/array/debug/back1_neg.cc:
            Remove dg-require-debug-mode. Add -D_GLIBCXX_ASSERTIONS 
option.
            * testsuite/23_containers/array/debug/back2_neg.cc: 
Likewise.
            * testsuite/23_containers/array/debug/front1_neg.cc: 
Likewise.
            * testsuite/23_containers/array/debug/front2_neg.cc: 
Likewise.
            * 
testsuite/23_containers/array/debug/square_brackets_operator1_neg.cc:

            Likewise.
            * 
testsuite/23_containers/array/debug/square_brackets_operator2_neg.cc:

            Likewise.
            * testsuite/23_containers/array/element_access/60497.cc
            * 
testsuite/23_containers/array/tuple_interface/get_debug_neg.cc:

            Remove.
            * 
testsuite/23_containers/array/tuple_interface/get_neg.cc
            * 
testsuite/23_containers/array/tuple_interface/tuple_element_debug_neg.cc
            * 
testsuite/23_containers/array/tuple_interface/tuple_element_neg.cc


Tested under Linux x86_64 normal and debug modes.

Ok to commit ?


Yes, this is a nice simplification, thanks.


This broke the C++11 constexpr support in std::array. Fixed with this
patch. Tested x86_64-linux, committed to trunk.


commit 91cfacc4b5d317b12a3bdcd798273a581568f645
Author: Jonathan Wakely 
Date:   Thu Dec 3 17:08:01 2020

libstdc++: Disable std::array assertions for C++11 constexpr

The recent changes to add assertions to std::array broke the functions
that need to be constexpr in C++11, because of the restrictive rules for
constexpr functions in C++11.

This simply disables the assertions for C++11 mode, so the functions can
be constexpr again.

libstdc++-v3/ChangeLog:

* include/std/array (array::operator[](size_t) const, array::front() const)
(array::back() const) [__cplusplus == 201103]: Disable
assertions.
* testsuite/23_containers/array/element_access/constexpr_element_access.cc:
Check for correct values.
* testsuite/23_containers/array/tuple_interface/get_neg.cc:
Adjust dg-error line numbers.
* testsuite/23_containers/array/debug/constexpr_c++11.cc: New test.

diff --git a/libstdc++-v3/include/std/array b/libstdc++-v3/include/std/array
index 3c4c88a536e..80750994058 100644
--- a/libstdc++-v3/include/std/array
+++ b/libstdc++-v3/include/std/array
@@ -192,7 +192,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   constexpr const_reference
   operator[](size_type __n) const noexcept
   {
+#if __cplusplus >= 201402L
 	__glibcxx_requires_subscript(__n);
+#endif
 	return _AT_Type::_S_ref(_M_elems, __n);
   }
 
@@ -228,7 +230,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   constexpr const_reference
   front() const noexcept
   {
+#if __cplusplus >= 201402L
 	__glibcxx_requires_nonempty();
+#endif
 	return _AT_Type::_S_ref(_M_elems, 0);
   }
 
@@ -242,7 +246,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   constexpr const_reference
   back() const noexcept
   {
+#if __cplusplus >= 201402L
 	__glibcxx_requires_nonempty();
+#endif
 	return _Nm ? _AT_Type::_S_ref(_M_elems, _Nm - 1)
  	   

[PATCH][GCC10][3/6] arm: Add vld1_bf16 + vld1q_bf16 intrinsics

[Andrea Corallo via Gcc-patches]

Hi all,

third patch of the series to backport a number of bfloat16 intrinsics from
trunk to gcc-10.

These patch are including the fixes to the tests that we have applied
into master.

Please see refer to:
ACLE 
ISA  

The series has been bootstrapped on arm-linux-gnueabihf and regtested.

Okay for gcc-10?

Thanks

  Andrea

>From 995779bf10731d00acf6701b57251aeb5d4e46b6 Mon Sep 17 00:00:00 2001
From: Andrea Corallo 
Date: Thu, 29 Oct 2020 13:56:17 +0100
Subject: [PATCH 3/6] arm: Add vld1_bf16 + vld1q_bf16 intrinsics

gcc/ChangeLog

2020-10-29  Andrea Corallo  

* config/arm/arm-builtins.c (VAR14): Define macro.
* config/arm/arm_neon_builtins.def: Touch for:
__builtin_neon_vld1v4bf, __builtin_neon_vld1v8bf.
* config/arm/arm_neon.h (vld1_bf16, vld1q_bf16): Add intrinsics.

gcc/testsuite/ChangeLog

2020-10-29  Andrea Corallo  

* gcc.target/arm/simd/vld1_bf16_1.c: New test.
---
 gcc/config/arm/arm-builtins.c |  3 ++
 gcc/config/arm/arm_neon.h | 14 +
 gcc/config/arm/arm_neon_builtins.def  |  5 ++--
 .../gcc.target/arm/simd/vld1_bf16_1.c | 29 +++
 4 files changed, 49 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/arm/simd/vld1_bf16_1.c

diff --git a/gcc/config/arm/arm-builtins.c b/gcc/config/arm/arm-builtins.c
index 4716771d7e4..73650637e5e 100644
--- a/gcc/config/arm/arm-builtins.c
+++ b/gcc/config/arm/arm-builtins.c
@@ -946,6 +946,9 @@ typedef struct {
 #define VAR13(T, N, A, B, C, D, E, F, G, H, I, J, K, L, M) \
   VAR12 (T, N, A, B, C, D, E, F, G, H, I, J, K, L) \
   VAR1 (T, N, M)
+#define VAR14(T, N, A, B, C, D, E, F, G, H, I, J, K, L, M, O) \
+  VAR13 (T, N, A, B, C, D, E, F, G, H, I, J, K, L, M) \
+  VAR1 (T, N, O)
 
 /* The builtin data can be found in arm_neon_builtins.def, arm_vfp_builtins.def
and arm_acle_builtins.def.  The entries in arm_neon_builtins.def require
diff --git a/gcc/config/arm/arm_neon.h b/gcc/config/arm/arm_neon.h
index 432d77fb272..b77175eaa3e 100644
--- a/gcc/config/arm/arm_neon.h
+++ b/gcc/config/arm/arm_neon.h
@@ -19557,6 +19557,20 @@ vst4q_bf16 (bfloat16_t * __ptr, bfloat16x8x4_t __val)
   return __builtin_neon_vst4v8bf (__ptr, __bu.__o);
 }
 
+__extension__ extern __inline bfloat16x4_t
+__attribute__  ((__always_inline__, __gnu_inline__, __artificial__))
+vld1_bf16 (bfloat16_t const * __ptr)
+{
+  return __builtin_neon_vld1v4bf (__ptr);
+}
+
+__extension__ extern __inline bfloat16x8_t
+__attribute__  ((__always_inline__, __gnu_inline__, __artificial__))
+vld1q_bf16 (const bfloat16_t * __ptr)
+{
+  return __builtin_neon_vld1v8bf (__ptr);
+}
+
 __extension__ extern __inline bfloat16x4x2_t
 __attribute__  ((__always_inline__, __gnu_inline__, __artificial__))
 vld2_bf16 (bfloat16_t const * __ptr)
diff --git a/gcc/config/arm/arm_neon_builtins.def 
b/gcc/config/arm/arm_neon_builtins.def
index 7a5dae0c4c0..07eda44cc58 100644
--- a/gcc/config/arm/arm_neon_builtins.def
+++ b/gcc/config/arm/arm_neon_builtins.def
@@ -310,8 +310,9 @@ VAR1 (TERNOP, vtbx1, v8qi)
 VAR1 (TERNOP, vtbx2, v8qi)
 VAR1 (TERNOP, vtbx3, v8qi)
 VAR1 (TERNOP, vtbx4, v8qi)
-VAR12 (LOAD1, vld1,
-v8qi, v4hi, v4hf, v2si, v2sf, di, v16qi, v8hi, v8hf, v4si, v4sf, v2di)
+VAR14 (LOAD1, vld1,
+v8qi, v4hi, v4hf, v2si, v2sf, di, v16qi, v8hi, v8hf, v4si, v4sf, v2di,
+v4bf, v8bf)
 VAR12 (LOAD1LANE, vld1_lane,
v8qi, v4hi, v2si, v2sf, di, v16qi, v8hi, v4si, v4sf, v2di, v4bf, v8bf)
 VAR10 (LOAD1, vld1_dup,
diff --git a/gcc/testsuite/gcc.target/arm/simd/vld1_bf16_1.c 
b/gcc/testsuite/gcc.target/arm/simd/vld1_bf16_1.c
new file mode 100644
index 000..b6b00dc03c2
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/simd/vld1_bf16_1.c
@@ -0,0 +1,29 @@
+/* { dg-do assemble } */
+/* { dg-require-effective-target arm_v8_2a_bf16_neon_ok } */
+/* { dg-add-options arm_v8_2a_bf16_neon } */
+/* { dg-additional-options "-save-temps -O2 -mfloat-abi=hard" }  */
+/* { dg-final { check-function-bodies "**" "" } } */
+
+#include "arm_neon.h"
+
+/*
+**test_vld1_bf16:
+** vld1.16 {d0}, \[r0\]
+** bx  lr
+*/
+bfloat16x4_t
+test_vld1_bf16 (bfloat16_t const *p)
+{
+  return vld1_bf16 (p);
+}
+
+/*
+**test_vld1q_bf16:
+** vld1.16 {d0-d1}, \[r0\]
+** bx  lr
+*/
+bfloat16x8_t
+test_vld1q_bf16 (bfloat16_t const *p)
+{
+  return vld1q_bf16 (p);
+}
-- 
2.20.1

[PATCH][GCC10][4/6] arm: Add vst1_bf16 + vst1q_bf16 intrinsics

[Andrea Corallo via Gcc-patches]

Hi all,

forth patch of the series to backport a number of bfloat16 intrinsics from
trunk to gcc-10.

These patch are including the fixes to the tests that we have applied
into master.

Please see refer to:
ACLE 
ISA  

The series has been bootstrapped on arm-linux-gnueabihf and regtested.

Okay for gcc-10?

Thanks

  Andrea

>From c2b787d773ff51485d0fdc594596b0873beb59c5 Mon Sep 17 00:00:00 2001
From: Andrea Corallo 
Date: Thu, 29 Oct 2020 15:11:37 +0100
Subject: [PATCH 4/6] arm: Add vst1_bf16 + vst1q_bf16 intrinsics

gcc/ChangeLog

2020-10-29  Andrea Corallo  

* config/arm/arm_neon.h (vst1_bf16, vst1q_bf16): Add intrinsics.
* config/arm/arm_neon_builtins.def : Touch for:
__builtin_neon_vst1v4bf, __builtin_neon_vst1v8bf.

gcc/testsuite/ChangeLog

2020-10-29  Andrea Corallo  

* gcc.target/arm/simd/vst1_bf16_1.c: New test.
---
 gcc/config/arm/arm_neon.h | 14 +
 gcc/config/arm/arm_neon_builtins.def  |  5 ++--
 .../gcc.target/arm/simd/vst1_bf16_1.c | 29 +++
 3 files changed, 46 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/arm/simd/vst1_bf16_1.c

diff --git a/gcc/config/arm/arm_neon.h b/gcc/config/arm/arm_neon.h
index b77175eaa3e..24aad3370f6 100644
--- a/gcc/config/arm/arm_neon.h
+++ b/gcc/config/arm/arm_neon.h
@@ -19509,6 +19509,20 @@ vbfmlaltq_laneq_f32 (float32x4_t __r, bfloat16x8_t 
__a, bfloat16x8_t __b,
   return __builtin_neon_vfmat_laneqv8bf (__r, __a, __b, __index);
 }
 
+__extension__ extern __inline void
+__attribute__  ((__always_inline__, __gnu_inline__, __artificial__))
+vst1_bf16 (bfloat16_t * __a, bfloat16x4_t __b)
+{
+  __builtin_neon_vst1v4bf (__a, __b);
+}
+
+__extension__ extern __inline void
+__attribute__  ((__always_inline__, __gnu_inline__, __artificial__))
+vst1q_bf16 (bfloat16_t * __a, bfloat16x8_t __b)
+{
+  __builtin_neon_vst1v8bf (__a, __b);
+}
+
 __extension__ extern __inline void
 __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
 vst2_bf16 (bfloat16_t * __ptr, bfloat16x4x2_t __val)
diff --git a/gcc/config/arm/arm_neon_builtins.def 
b/gcc/config/arm/arm_neon_builtins.def
index 07eda44cc58..e3ab6281497 100644
--- a/gcc/config/arm/arm_neon_builtins.def
+++ b/gcc/config/arm/arm_neon_builtins.def
@@ -317,8 +317,9 @@ VAR12 (LOAD1LANE, vld1_lane,
v8qi, v4hi, v2si, v2sf, di, v16qi, v8hi, v4si, v4sf, v2di, v4bf, v8bf)
 VAR10 (LOAD1, vld1_dup,
v8qi, v4hi, v2si, v2sf, di, v16qi, v8hi, v4si, v4sf, v2di)
-VAR12 (STORE1, vst1,
-   v8qi, v4hi, v4hf, v2si, v2sf, di, v16qi, v8hi, v8hf, v4si, v4sf, v2di)
+VAR14 (STORE1, vst1,
+v8qi, v4hi, v4hf, v2si, v2sf, di, v16qi, v8hi, v8hf, v4si, v4sf, v2di,
+v4bf, v8bf)
 VAR14 (STORE1LANE, vst1_lane,
v8qi, v4hi, v4hf, v2si, v2sf, di, v16qi, v8hi, v8hf, v4si, v4sf, v2di, 
v4bf, v8bf)
 VAR13 (LOAD1, vld2,
diff --git a/gcc/testsuite/gcc.target/arm/simd/vst1_bf16_1.c 
b/gcc/testsuite/gcc.target/arm/simd/vst1_bf16_1.c
new file mode 100644
index 000..06fb58ecd79
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/simd/vst1_bf16_1.c
@@ -0,0 +1,29 @@
+/* { dg-do assemble } */
+/* { dg-require-effective-target arm_v8_2a_bf16_neon_ok } */
+/* { dg-add-options arm_v8_2a_bf16_neon } */
+/* { dg-additional-options "-save-temps -O2 -mfloat-abi=hard" }  */
+/* { dg-final { check-function-bodies "**" "" } } */
+
+#include "arm_neon.h"
+
+/*
+**test_vst1_bf16:
+** vst1.16 {d0}, \[r0\]
+** bx  lr
+*/
+void
+test_vst1_bf16 (bfloat16_t *a, bfloat16x4_t b)
+{
+  vst1_bf16 (a, b);
+}
+
+/*
+**test_vst1q_bf16:
+** vst1.16 {d0-d1}, \[r0\]
+** bx  lr
+*/
+void
+test_vst1q_bf16 (bfloat16_t *a, bfloat16x8_t b)
+{
+  vst1q_bf16 (a, b);
+}
-- 
2.20.1

[PATCH][GCC10][5/6] arm: Add vldN_lane_bf16 + vldNq_lane_bf16 intrisics

[Andrea Corallo via Gcc-patches]

Hi all,

fifth patch of the series to backport a number of bfloat16 intrinsics from
trunk to gcc-10.

These patch are including the fixes to the tests that we have applied
into master.

Please see refer to:
ACLE 
ISA  

The series has been bootstrapped on arm-linux-gnueabihf and regtested.

Okay for gcc-10?

Thanks

  Andrea

>From d3d58cbc90bc9bd4ac890f7871558bf52b5b6b37 Mon Sep 17 00:00:00 2001
From: Andrea Corallo 
Date: Mon, 26 Oct 2020 18:31:19 +0100
Subject: [PATCH 5/6] arm: Add vldN_lane_bf16 + vldNq_lane_bf16 intrisics

gcc/ChangeLog

2020-10-29  Andrea Corallo  

* config/arm/arm_neon.h (vld2_lane_bf16, vld2q_lane_bf16)
(vld3_lane_bf16, vld3q_lane_bf16, vld4_lane_bf16)
(vld4q_lane_bf16): Add intrinsics.
* config/arm/arm_neon_builtins.def: Touch for:
__builtin_neon_vld2_lanev4bf, __builtin_neon_vld2_lanev8bf,
__builtin_neon_vld3_lanev4bf, __builtin_neon_vld3_lanev8bf,
__builtin_neon_vld4_lanev4bf, __builtin_neon_vld4_lanev8bf.
* config/arm/iterators.md (VQ_HS): Add V8BF to the iterator.

gcc/testsuite/ChangeLog

2020-10-29  Andrea Corallo  

* gcc.target/aarch64/advsimd-intrinsics/vld2_lane_bf16_indices_1.c:
Run it also for the arm backend.
* gcc.target/aarch64/advsimd-intrinsics/vld2q_lane_bf16_indices_1.c:
Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vld3_lane_bf16_indices_1.c:
Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vld3q_lane_bf16_indices_1.c:
Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vld4q_lane_bf16_indices_1.c:
Likewise.
* gcc.target/arm/simd/vldn_lane_bf16_1.c: New test.
---
 gcc/config/arm/arm_neon.h | 62 +++
 gcc/config/arm/arm_neon_builtins.def  | 12 +--
 gcc/config/arm/iterators.md   |  2 +-
 .../vld2_lane_bf16_indices_1.c|  2 +-
 .../vld2q_lane_bf16_indices_1.c   |  2 +-
 .../vld3_lane_bf16_indices_1.c|  2 +-
 .../vld3q_lane_bf16_indices_1.c   |  2 +-
 .../vld4_lane_bf16_indices_1.c|  2 +-
 .../vld4q_lane_bf16_indices_1.c   |  2 +-
 .../gcc.target/arm/simd/vldn_lane_bf16_1.c| 79 +++
 10 files changed, 154 insertions(+), 13 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/arm/simd/vldn_lane_bf16_1.c

diff --git a/gcc/config/arm/arm_neon.h b/gcc/config/arm/arm_neon.h
index 24aad3370f6..4fee128ce8d 100644
--- a/gcc/config/arm/arm_neon.h
+++ b/gcc/config/arm/arm_neon.h
@@ -19721,6 +19721,68 @@ vst1q_lane_bf16 (bfloat16_t * __a, bfloat16x8_t __b, 
const int __c)
   __builtin_neon_vst1_lanev8bf (__a, __b, __c);
 }
 
+__extension__ extern __inline bfloat16x4x2_t
+__attribute__  ((__always_inline__, __gnu_inline__, __artificial__))
+vld2_lane_bf16 (const bfloat16_t * __a, bfloat16x4x2_t __b, const int __c)
+{
+  union { bfloat16x4x2_t __i; __builtin_neon_ti __o; } __bu = { __b };
+  union { bfloat16x4x2_t __i; __builtin_neon_ti __o; } __rv;
+  __rv.__o = __builtin_neon_vld2_lanev4bf ( __a, __bu.__o, __c);
+  return __rv.__i;
+}
+
+__extension__ extern __inline bfloat16x8x2_t
+__attribute__  ((__always_inline__, __gnu_inline__, __artificial__))
+vld2q_lane_bf16 (const bfloat16_t * __a, bfloat16x8x2_t __b, const int __c)
+{
+  union { bfloat16x8x2_t __i; __builtin_neon_oi __o; } __bu = { __b };
+  union { bfloat16x8x2_t __i; __builtin_neon_oi __o; } __rv;
+  __rv.__o = __builtin_neon_vld2_lanev8bf (__a, __bu.__o, __c);
+  return __rv.__i;
+}
+
+__extension__ extern __inline bfloat16x4x3_t
+__attribute__  ((__always_inline__, __gnu_inline__, __artificial__))
+vld3_lane_bf16 (const bfloat16_t * __a, bfloat16x4x3_t __b, const int __c)
+{
+  union { bfloat16x4x3_t __i; __builtin_neon_ei __o; } __bu = { __b };
+  union { bfloat16x4x3_t __i; __builtin_neon_ei __o; } __rv;
+  __rv.__o = __builtin_neon_vld3_lanev4bf (__a, __bu.__o, __c);
+  return __rv.__i;
+}
+
+__extension__ extern __inline bfloat16x8x3_t
+__attribute__  ((__always_inline__, __gnu_inline__, __artificial__))
+vld3q_lane_bf16 (const bfloat16_t * __a, bfloat16x8x3_t __b, const int __c)
+{
+  union { bfloat16x8x3_t __i; __builtin_neon_ci __o; } __bu = { __b };
+  union { bfloat16x8x3_t __i; __builtin_neon_ci __o; } __rv;
+  __rv.__o = __builtin_neon_vld3_lanev8bf (__a, __bu.__o, __c);
+  return __rv.__i;
+}
+
+__extension__ extern __inline bfloat16x4x4_t
+__attribute__  ((__always_inline__, __gnu_inline__, __artificial__))
+vld4_lane_bf16 (const bfloat16_t * __a, bfloat16x4x4_t __b, const int __c)
+{
+  union { bfloat16x4x4_t __i; __builtin_neon_oi __o; } __bu = { __b };
+  union { bfloat16x4x4_t __i; __builtin_neon_oi __o; } __rv;
+  __rv.__o = __builtin_neon_vld4_lanev4bf (__a,
+  __bu.__o, __c);
+  return __rv.__i;
+}
+
+__extension__ extern __inline bfloat16x8x4_t
+__

Re: [PATCH] 2/2 Remove debug/array

[Daniel Krügler via Gcc-patches]

Am Do., 3. Dez. 2020 um 18:10 Uhr schrieb Jonathan Wakely via
Libstdc++ :
>
[..]
> >>Ok to commit ?
> >
> >Yes, this is a nice simplification, thanks.
>
> This broke the C++11 constexpr support in std::array. Fixed with this
> patch. Tested x86_64-linux, committed to trunk.

Wouldn't a transformation into a comma expression, such as

return __glibcxx_requires_subscript(__n), _AT_Type::_S_ref(_M_elems, __n);

realize the same thing but would still keep the assertion-like thing?
(Untested, just out of my head)

- Daniel

[PATCH][GCC10][6/6] arm: Add vstN_lane_bf16 + vstNq_lane_bf16 intrisics

[Andrea Corallo via Gcc-patches]

Hi all,

last patch of the series to backport a number of bfloat16 intrinsics from
trunk to gcc-10.

These patch are including the fixes to the tests that we have applied
into master.

Please see refer to:
ACLE 
ISA  

The series has been bootstrapped on arm-linux-gnueabihf and regtested.

Okay for gcc-10?

Thanks

  Andrea

>From 614211164b83a1cd426c10c8894cf0aa2837e070 Mon Sep 17 00:00:00 2001
From: Andrea Corallo 
Date: Thu, 29 Oct 2020 11:20:23 +0100
Subject: [PATCH 6/6] arm: Add vstN_lane_bf16 + vstNq_lane_bf16 intrisics

gcc/ChangeLog

2020-10-29  Andrea Corallo  

* config/arm/arm_neon.h (vst2_lane_bf16, vst2q_lane_bf16)
(vst3_lane_bf16, vst3q_lane_bf16, vst4_lane_bf16)
(vst4q_lane_bf16): New intrinsics.
* config/arm/arm_neon_builtins.def: Touch it for:
__builtin_neon_vst2_lanev4bf, __builtin_neon_vst2_lanev8bf,
__builtin_neon_vst3_lanev4bf, __builtin_neon_vst3_lanev8bf,
__builtin_neon_vst4_lanev4bf,__builtin_neon_vst4_lanev8bf.

gcc/testsuite/ChangeLog

2020-10-29  Andrea Corallo  

* gcc.target/aarch64/advsimd-intrinsics/vst2_lane_bf16_indices_1.c:
Run it also for arm-*-*.
* gcc.target/aarch64/advsimd-intrinsics/vst2q_lane_bf16_indices_1.c:
Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vst3_lane_bf16_indices_1.c:
Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vst3q_lane_bf16_indices_1.c:
Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vst4_lane_bf16_indices_1.c:
Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vst4q_lane_bf16_indices_1.c:
Likewise.
* gcc.target/arm/simd/vstn_lane_bf16_1.c: New test.
---
 gcc/config/arm/arm_neon.h | 48 
 gcc/config/arm/arm_neon_builtins.def  | 12 +--
 .../vst2_lane_bf16_indices_1.c|  2 +-
 .../vst2q_lane_bf16_indices_1.c   |  2 +-
 .../vst3_lane_bf16_indices_1.c|  2 +-
 .../vst3q_lane_bf16_indices_1.c   |  2 +-
 .../vst4_lane_bf16_indices_1.c|  2 +-
 .../vst4q_lane_bf16_indices_1.c   |  2 +-
 .../gcc.target/arm/simd/vstn_lane_bf16_1.c| 73 +++
 9 files changed, 133 insertions(+), 12 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/arm/simd/vstn_lane_bf16_1.c

diff --git a/gcc/config/arm/arm_neon.h b/gcc/config/arm/arm_neon.h
index 4fee128ce8d..9569e1a4c9c 100644
--- a/gcc/config/arm/arm_neon.h
+++ b/gcc/config/arm/arm_neon.h
@@ -19783,6 +19783,54 @@ vld4q_lane_bf16 (const bfloat16_t * __a, 
bfloat16x8x4_t __b, const int __c)
   return __rv.__i;
 }
 
+__extension__ extern __inline void
+__attribute__  ((__always_inline__, __gnu_inline__, __artificial__))
+vst2_lane_bf16 (bfloat16_t * __a, bfloat16x4x2_t __b, const int __c)
+{
+  union { bfloat16x4x2_t __i; __builtin_neon_ti __o; } __bu = { __b };
+  __builtin_neon_vst2_lanev4bf (__a, __bu.__o, __c);
+}
+
+__extension__ extern __inline void
+__attribute__  ((__always_inline__, __gnu_inline__, __artificial__))
+vst2q_lane_bf16 (bfloat16_t * __a, bfloat16x8x2_t __b, const int __c)
+{
+  union { bfloat16x8x2_t __i; __builtin_neon_oi __o; } __bu = { __b };
+  __builtin_neon_vst2_lanev8bf (__a, __bu.__o, __c);
+}
+
+__extension__ extern __inline void
+__attribute__  ((__always_inline__, __gnu_inline__, __artificial__))
+vst3_lane_bf16 (bfloat16_t * __a, bfloat16x4x3_t __b, const int __c)
+{
+  union { bfloat16x4x3_t __i; __builtin_neon_ei __o; } __bu = { __b };
+  __builtin_neon_vst3_lanev4bf (__a, __bu.__o, __c);
+}
+
+__extension__ extern __inline void
+__attribute__  ((__always_inline__, __gnu_inline__, __artificial__))
+vst3q_lane_bf16 (bfloat16_t * __a, bfloat16x8x3_t __b, const int __c)
+{
+  union { bfloat16x8x3_t __i; __builtin_neon_ci __o; } __bu = { __b };
+  __builtin_neon_vst3_lanev8bf (__a, __bu.__o, __c);
+}
+
+__extension__ extern __inline void
+__attribute__  ((__always_inline__, __gnu_inline__, __artificial__))
+vst4_lane_bf16 (bfloat16_t * __a, bfloat16x4x4_t __b, const int __c)
+{
+  union { bfloat16x4x4_t __i; __builtin_neon_oi __o; } __bu = { __b };
+  __builtin_neon_vst4_lanev4bf (__a, __bu.__o, __c);
+}
+
+__extension__ extern __inline void
+__attribute__  ((__always_inline__, __gnu_inline__, __artificial__))
+vst4q_lane_bf16 (bfloat16_t * __a, bfloat16x8x4_t __b, const int __c)
+{
+  union { bfloat16x8x4_t __i; __builtin_neon_xi __o; } __bu = { __b };
+  __builtin_neon_vst4_lanev8bf (__a, __bu.__o, __c);
+}
+
 #pragma GCC pop_options
 
 #ifdef __cplusplus
diff --git a/gcc/config/arm/arm_neon_builtins.def 
b/gcc/config/arm/arm_neon_builtins.def
index 1cb8c8c23b4..0ff0494b5da 100644
--- a/gcc/config/arm/arm_neon_builtins.def
+++ b/gcc/config/arm/arm_neon_builtins.def
@@ -329,8 +329,8 @@ VAR11 (LOAD1LANE, vld2_lane,
 VAR8 (LOAD1, vld2_dup, v8qi, v4hi, v4hf, v2si, v2sf, di, v4bf, v8bf)
 VAR13 (S

[committed] libstdc++: Update powerpc-linux baselines for GCC 10.1

[Jonathan Wakely via Gcc-patches]

This should have been done before the GCC 10.1 release.

libstdc++-v3/ChangeLog:

* config/abi/post/powerpc-linux-gnu/baseline_symbols.txt:
Update.
* config/abi/post/powerpc64-linux-gnu/32/baseline_symbols.txt:
Update.

Tested powerpc64-linux. Committed to trunk. Backport to gcc-10 to
follow.

commit 3843fa2d75a76ca64d3366950f0ac3d7d4729c4c
Author: Jonathan Wakely 
Date:   Thu Dec 3 17:18:28 2020

libstdc++: Update powerpc-linux baselines for GCC 10.1

This should have been done before the GCC 10.1 release.

libstdc++-v3/ChangeLog:

* config/abi/post/powerpc-linux-gnu/baseline_symbols.txt:
Update.
* config/abi/post/powerpc64-linux-gnu/32/baseline_symbols.txt:
Update.

diff --git 
a/libstdc++-v3/config/abi/post/powerpc-linux-gnu/baseline_symbols.txt 
b/libstdc++-v3/config/abi/post/powerpc-linux-gnu/baseline_symbols.txt
index 5cb72bbfcb4..63a58b03596 100644
--- a/libstdc++-v3/config/abi/post/powerpc-linux-gnu/baseline_symbols.txt
+++ b/libstdc++-v3/config/abi/post/powerpc-linux-gnu/baseline_symbols.txt
@@ -2208,16 +2208,20 @@ FUNC:_ZNSt12__basic_fileIcED1Ev@@GLIBCXX_3.4
 FUNC:_ZNSt12__basic_fileIcED2Ev@@GLIBCXX_3.4
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1EOS5_@@GLIBCXX_3.4.26
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1Ev@@GLIBCXX_3.4.26
+FUNC:_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC2EOS5_@@GLIBCXX_3.4.28
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC2Ev@@GLIBCXX_3.4.27
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC1EOS4_@@GLIBCXX_3.4.26
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC1Ev@@GLIBCXX_3.4.26
+FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC2EOS4_@@GLIBCXX_3.4.28
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC2Ev@@GLIBCXX_3.4.27
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEaSEOS4_@@GLIBCXX_3.4.26
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1EOS6_@@GLIBCXX_3.4.26
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1Ev@@GLIBCXX_3.4.26
+FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC2EOS6_@@GLIBCXX_3.4.28
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC2Ev@@GLIBCXX_3.4.27
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC1EOS5_@@GLIBCXX_3.4.26
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC1Ev@@GLIBCXX_3.4.26
+FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC2EOS5_@@GLIBCXX_3.4.28
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC2Ev@@GLIBCXX_3.4.27
 
FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEaSEOS5_@@GLIBCXX_3.4.26
 FUNC:_ZNSt12bad_weak_ptrD0Ev@@GLIBCXX_3.4.15
@@ -3191,12 +3195,18 @@ FUNC:_ZNSt3_V214error_categoryD1Ev@@GLIBCXX_3.4.21
 FUNC:_ZNSt3_V214error_categoryD2Ev@@GLIBCXX_3.4.21
 FUNC:_ZNSt3_V215system_categoryEv@@GLIBCXX_3.4.21
 FUNC:_ZNSt3_V216generic_categoryEv@@GLIBCXX_3.4.21
+FUNC:_ZNSt3pmr15memory_resourceD0Ev@@GLIBCXX_3.4.28
+FUNC:_ZNSt3pmr15memory_resourceD1Ev@@GLIBCXX_3.4.28
+FUNC:_ZNSt3pmr15memory_resourceD2Ev@@GLIBCXX_3.4.28
 FUNC:_ZNSt3pmr19new_delete_resourceEv@@GLIBCXX_3.4.26
 FUNC:_ZNSt3pmr20get_default_resourceEv@@GLIBCXX_3.4.26
 FUNC:_ZNSt3pmr20null_memory_resourceEv@@GLIBCXX_3.4.26
 FUNC:_ZNSt3pmr20set_default_resourceEPNS_15memory_resourceE@@GLIBCXX_3.4.26
 FUNC:_ZNSt3pmr25monotonic_buffer_resource13_M_new_bufferEjj@@GLIBCXX_3.4.26
 FUNC:_ZNSt3pmr25monotonic_buffer_resource18_M_release_buffersEv@@GLIBCXX_3.4.26
+FUNC:_ZNSt3pmr25monotonic_buffer_resourceD0Ev@@GLIBCXX_3.4.28
+FUNC:_ZNSt3pmr25monotonic_buffer_resourceD1Ev@@GLIBCXX_3.4.28
+FUNC:_ZNSt3pmr25monotonic_buffer_resourceD2Ev@@GLIBCXX_3.4.28
 FUNC:_ZNSt3pmr26synchronized_pool_resource11do_allocateEjj@@GLIBCXX_3.4.26
 FUNC:_ZNSt3pmr26synchronized_pool_resource13do_deallocateEPvjj@@GLIBCXX_3.4.26
 FUNC:_ZNSt3pmr26synchronized_pool_resource7releaseEv@@GLIBCXX_3.4.26
@@ -4642,6 +4652,7 @@ OBJECT:0:GLIBCXX_3.4.24
 OBJECT:0:GLIBCXX_3.4.25
 OBJECT:0:GLIBCXX_3.4.26
 OBJECT:0:GLIBCXX_3.4.27
+OBJECT:0:GLIBCXX_3.4.28
 OBJECT:0:GLIBCXX_3.4.3
 OBJECT:0:GLIBCXX_3.4.4
 OBJECT:0:GLIBCXX_3.4.5
@@ -4680,6 +4691,7 @@ 
OBJECT:12:_ZTINSt17__gnu_cxx_ldbl1289money_getIcSt19istreambuf_iteratorIcSt11cha
 
OBJECT:12:_Z

Re: [PATCH] 2/2 Remove debug/array

[Jonathan Wakely via Gcc-patches]

On 03/12/20 18:14 +0100, Daniel Krügler via Libstdc++ wrote:

Am Do., 3. Dez. 2020 um 18:10 Uhr schrieb Jonathan Wakely via
Libstdc++ :



[..]

>>Ok to commit ?
>
>Yes, this is a nice simplification, thanks.

This broke the C++11 constexpr support in std::array. Fixed with this
patch. Tested x86_64-linux, committed to trunk.


Wouldn't a transformation into a comma expression, such as

return __glibcxx_requires_subscript(__n), _AT_Type::_S_ref(_M_elems, __n);

realize the same thing but would still keep the assertion-like thing?


No, because the assertion is defined as  do { ... } while(false) so
can't be used in C++11 constexpr functions.

We could change that, or introduce new assertion macros just for this
case, but I don't care about C++11 enough to do it.

Re: [pushed] c++: Push parms when late parsing default args

[Rainer Orth]

Hi Jason,

> In this testcase we weren't catching the error in A::f because the parameter
> 'I' wasn't in scope, so the default argument for 'b' found the global
> typedef I.  Fixed by pushing the parms before parsing.  This is a bit
> complicated because pushdecl clears DECL_CHAIN; do_push_parm_decls deals
> with this by nreversing first, but that doesn't work here because we only
> want to push them one at a time; if we pushed all of them before parsing,
> we'd wrongly reject A::g.
>
> Tested x86_64-pc-linux-gnu, applying to trunk.
>
> gcc/cp/ChangeLog:
>
>   * parser.c (cp_parser_primary_expression): Distinguish
>   parms from vars in error.
>   (cp_parser_late_parsing_default_args): Pushdecl parms
>   as we go.

this patch broke i386-pc-solaris2.11 and sparc-sun-solaris2.11 bootstrap
with gcc 8.1.0 in stage 1:

/vol/gcc/src/hg/master/local/gcc/cp/parser.c: In function 'void 
cp_parser_late_parsing_default_args(cp_parser*, tree)':
/vol/gcc/src/hg/master/local/gcc/cp/parser.c:30618:28: error: ambiguous 
overload for 'operator[]' (operand types are 'releasing_vec' and 'int')
   tree parmdecl = parms[i];
^
/vol/gcc/src/hg/master/local/gcc/cp/parser.c:30618:28: note: candidate: 
'operator[](releasing_vec::vec_t* {aka vec*}, int)' 

In file included from /vol/gcc/src/hg/master/local/gcc/cp/parser.c:25:
/vol/gcc/src/hg/master/local/gcc/cp/cp-tree.h:965:9: note: candidate: 
'tree_node*& releasing_vec::operator[](unsigned int) const'
   tree& operator[] (unsigned i) const { return (*v)[i]; }
 ^~~~
In file included from /vol/gcc/src/hg/master/local/gcc/c-family/c-common.h:26,
 from /vol/gcc/src/hg/master/local/gcc/cp/cp-tree.h:40,
 from /vol/gcc/src/hg/master/local/gcc/cp/parser.c:25:
/vol/gcc/src/hg/master/local/gcc/cp/parser.c:30647:24: error: ambiguous 
overload for 'operator[]' (operand types are 'releasing_vec' and 'int')
   DECL_CHAIN (parms[i]) = parm;
^
/vol/gcc/src/hg/master/local/gcc/tree.h:286:26: note: in definition of macro 
'CONTAINS_STRUCT_CHECK'
 (contains_struct_check ((T), (STRUCT), __FILE__, __LINE__, __FUNCTION__))
  ^
/vol/gcc/src/hg/master/local/gcc/tree.h:2424:27: note: in expansion of macro 
'TREE_CHAIN'
 #define DECL_CHAIN(NODE) (TREE_CHAIN (DECL_MINIMAL_CHECK (NODE)))
[...]

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: How to traverse all the local variables that declared in the current routine?

[Richard Sandiford via Gcc-patches]

Richard Biener via Gcc-patches  writes:
> On Tue, Nov 24, 2020 at 4:47 PM Qing Zhao  wrote:
>> Another issue is, in order to check whether an auto-variable has 
>> initializer, I plan to add a new bit in “decl_common” as:
>>   /* In a VAR_DECL, this is DECL_IS_INITIALIZED.  */
>>   unsigned decl_is_initialized :1;
>>
>> /* IN VAR_DECL, set when the decl is initialized at the declaration.  */
>> #define DECL_IS_INITIALIZED(NODE) \
>>   (DECL_COMMON_CHECK (NODE)->decl_common.decl_is_initialized)
>>
>> set this bit when setting DECL_INITIAL for the variables in FE. then keep it
>> even though DECL_INITIAL might be NULLed.
>
> For locals it would be more reliable to set this flag during gimplification.
>
>> Do you have any comment and suggestions?
>
> As said above - do you want to cover registers as well as locals?  I'd do
> the actual zeroing during RTL expansion instead since otherwise you
> have to figure youself whether a local is actually used (see 
> expand_stack_vars)
>
> Note that optimization will already made have use of "uninitialized" state
> of locals so depending on what the actual goal is here "late" may be too late.

Haven't thought about this much, so it might be a daft idea, but would a
compromise be to use a const internal function:

  X1 = .DEFERRED_INIT (X0, INIT)

where the X0 argument is an uninitialised value and the INIT argument
describes the initialisation pattern?  So for a decl we'd have:

  X = .DEFERRED_INIT (X, INIT)

and for an SSA name we'd have:

  X_2 = .DEFERRED_INIT (X_1(D), INIT)

with all other uses of X_1(D) being replaced by X_2.  The idea is that:

* Having the X0 argument would keep the uninitialised use of the
  variable around for the later warning passes.

* Using a const function should still allow the UB to be deleted as dead
  if X1 isn't needed.

* Having a function in the way should stop passes from taking advantage
  of direct uninitialised uses for optimisation.

This means we won't be able to optimise based on the actual init
value at the gimple level, but that seems like a fair trade-off.
AIUI this is really a security feature or anti-UB hardening feature
(in the sense that users are more likely to see predictable behaviour
“in the field” even if the program has UB).

Thanks,
Richard

Re: [PATCH] implement pre-c++20 contracts

[Jason Merrill via Gcc-patches]

On 12/3/20 12:07 PM, Andrew Sutton wrote:


 > Attached is a new squashed revision of the patch sans ChangeLogs. The
 > current work is now being done on github:
 > https://github.com/lock3/gcc/tree/contracts-jac-alt


I'm starting to review this now, sorry for the delay. Is this still the
branch you want me to consider for GCC 11?  I notice that the
-constexpr
and -mangled-config branches are newer.


I think so. Jeff can answer more authoritatively. I know we had one set 
of changes to the design (how contracts) work aimed at improving the 
debugging experience for violated contracts. I'm not sure if that's in 
the jac-alt branch though.


The -constexpr branch checks for trivially satisfied contracts (e.g., 
[[assert: true]]) and issues warnings. It also preemptively checks 
preconditions against constant function arguments. It's probably worth 
reviewing that separately.


I'm not sure the -manged-config branch is worth considering for merging 
at this point. It's trying to solve a problem that might not be worth 
solving.


OK, I'll start with -alt then, thanks.

Out of curiosity, are you concerned that future versions of contracts 
might have considerably different syntax or configurability? I'd hope it 
wouldn't, but who knows where SG21 is going :)


Not particularly; I figure that most of the implementation would be 
unaffected.


Jason

[PATCH RFA] vec: Simplify use with C++11 range-based 'for'.

[Jason Merrill via Gcc-patches]

It looks cleaner if we can use a vec* directly as a range for the C++11
range-based 'for' loop, without needing to indirect from it, and also works
with null pointers.

The change in cp_parser_late_parsing_default_args is an example of how this
can be used to simplify many loops over vec*.

I deliberately didn't format the new overloads for etags since they are
trivial, but am open to changing that.

Tested x86_64-pc-linux-gnu.  Is this OK for trunk now, or should I hold it for
stage 1?

gcc/ChangeLog:

* vec.h (begin, end): Add overloads for vec*.
* tree.c (build_constructor_from_vec): Remove *.

gcc/cp/ChangeLog:

* decl2.c (clear_consteval_vfns): Remove *.
* pt.c (do_auto_deduction): Remove *.
* parser.c (cp_parser_late_parsing_default_args): Change loop
to use range 'for'.
---
 gcc/vec.h   | 10 ++
 gcc/cp/decl2.c  |  2 +-
 gcc/cp/parser.c |  6 +-
 gcc/cp/pt.c |  2 +-
 gcc/tree.c  |  2 +-
 5 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/gcc/vec.h b/gcc/vec.h
index 90904515ea0..09166f1bce6 100644
--- a/gcc/vec.h
+++ b/gcc/vec.h
@@ -419,6 +419,16 @@ struct GTY((user)) vec
 {
 };
 
+/* Allow C++11 range-based 'for' to work directly on vec*.  */
+template
+T* begin (vec *v) { return v ? v->begin () : nullptr; }
+template
+T* end (vec *v) { return v ? v->end () : nullptr; }
+template
+const T* begin (const vec *v) { return v ? v->begin () : nullptr; }
+template
+const T* end (const vec *v) { return v ? v->end () : nullptr; }
+
 /* Generic vec<> debug helpers.
 
These need to be instantiated for each vec used throughout
diff --git a/gcc/cp/decl2.c b/gcc/cp/decl2.c
index 1bc7b7e0197..46069cb66a6 100644
--- a/gcc/cp/decl2.c
+++ b/gcc/cp/decl2.c
@@ -1928,7 +1928,7 @@ static void
 clear_consteval_vfns (vec &consteval_vtables)
 {
   for (tree vtable : consteval_vtables)
-for (constructor_elt &elt : *CONSTRUCTOR_ELTS (DECL_INITIAL (vtable)))
+for (constructor_elt &elt : CONSTRUCTOR_ELTS (DECL_INITIAL (vtable)))
   {
tree fn = cp_get_fndecl_from_callee (elt.value, /*fold*/false);
if (fn && DECL_IMMEDIATE_FUNCTION_P (fn))
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 103567cd004..cc3da155032 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -30611,9 +30611,6 @@ cp_parser_late_parsing_default_args (cp_parser *parser, 
tree fn)
 {
   tree default_arg = TREE_PURPOSE (parm);
   tree parsed_arg;
-  vec *insts;
-  tree copy;
-  unsigned ix;
 
   tree parmdecl = parms[i];
   pushdecl (parmdecl);
@@ -30633,8 +30630,7 @@ cp_parser_late_parsing_default_args (cp_parser *parser, 
tree fn)
   TREE_PURPOSE (parm) = parsed_arg;
 
   /* Update any instantiations we've already created.  */
-  for (insts = DEFPARSE_INSTANTIATIONS (default_arg), ix = 0;
-  vec_safe_iterate (insts, ix, ©); ix++)
+  for (tree copy : DEFPARSE_INSTANTIATIONS (default_arg))
TREE_PURPOSE (copy) = parsed_arg;
 }
 
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 3ca28133d94..ac987682a58 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -29273,7 +29273,7 @@ do_auto_deduction (tree type, tree init, tree auto_node,
   /* We don't recurse here because we can't deduce from a nested
 initializer_list.  */
   if (CONSTRUCTOR_ELTS (init))
-   for (constructor_elt &elt : *CONSTRUCTOR_ELTS (init))
+   for (constructor_elt &elt : CONSTRUCTOR_ELTS (init))
  elt.value = resolve_nondeduced_context (elt.value, complain);
 }
   else
diff --git a/gcc/tree.c b/gcc/tree.c
index 52a145dd018..431bbc22e52 100644
--- a/gcc/tree.c
+++ b/gcc/tree.c
@@ -2185,7 +2185,7 @@ build_constructor_from_vec (tree type, const vec *vals)
 {
   vec *v = NULL;
 
-  for (tree t : *vals)
+  for (tree t : vals)
 CONSTRUCTOR_APPEND_ELT (v, NULL_TREE, t);
 
   return build_constructor (type, v);

base-commit: 3843fa2d75a76ca64d3366950f0ac3d7d4729c4c
-- 
2.27.0

Re: [PATCH RFA] vec: Simplify use with C++11 range-based 'for'.

[Marek Polacek via Gcc-patches]

On Thu, Dec 03, 2020 at 12:53:22PM -0500, Jason Merrill via Gcc-patches wrote:
> It looks cleaner if we can use a vec* directly as a range for the C++11
> range-based 'for' loop, without needing to indirect from it, and also works
> with null pointers.

Nice.

> The change in cp_parser_late_parsing_default_args is an example of how this
> can be used to simplify many loops over vec*.
> 
> I deliberately didn't format the new overloads for etags since they are
> trivial, but am open to changing that.
> 
> Tested x86_64-pc-linux-gnu.  Is this OK for trunk now, or should I hold it for
> stage 1?

I'd vote for pushing this now as it's simple enough.

> --- a/gcc/cp/pt.c
> +++ b/gcc/cp/pt.c
> @@ -29273,7 +29273,7 @@ do_auto_deduction (tree type, tree init, tree 
> auto_node,
>/* We don't recurse here because we can't deduce from a nested
>initializer_list.  */
>if (CONSTRUCTOR_ELTS (init))

Can this check go now or do we still need it?

> - for (constructor_elt &elt : *CONSTRUCTOR_ELTS (init))
> + for (constructor_elt &elt : CONSTRUCTOR_ELTS (init))
> elt.value = resolve_nondeduced_context (elt.value, complain);

Marek

Go testsuite: update existing tests to source repo

[Ian Lance Taylor via Gcc-patches]

I've committed a patch to update the existing Go tests, the ones under
go.test, to the versions in the source repo at
https://go.googlesource.com/.  This does not include any of the new
tests, just updates the ones we already have and removes the ones that
no longer exist in the source.  The attached patch omits some of the
removed files, as they are large.  Bootstrapped and ran Go testsuite
on x86_64-pc-linux-gnu.  Committed to mainline.

Ian


patch.txt.bz2
Description: application/bzip

Re: [gcc r11-4816] Fix Ada build failure for the SuSE PowerPC64/Linux compiler

[Eric Botcazou]

> Nope.  The default is 64-bit.

That's not what Richard said under PR ada/97504 though:

"Yes, we're building a 64bit compiler defaulting to -m32.  Our
"ppc" target was never a true 32bit system but a 64bit system with a
32bit "default" runtime and 64bit multilibs, so most binaries in the
system were 32bit binaries but select ones could be 64bit.

Note the GCC binaries themselves become 32bit binaries as well (the way
we use it the host compiler is the very same, powerpc64-linux compiler
defaulting to 32bit code generation)."

I'm afraid we cannot support both given the current setup, so you'll have to 
make a choice for the powerpc64-suse-linux compiler.

-- 
Eric Botcazou

Re: [gcc r11-4816] Fix Ada build failure for the SuSE PowerPC64/Linux compiler

[Andreas Schwab]

On Dez 03 2020, Eric Botcazou wrote:

> I'm afraid we cannot support both given the current setup, so you'll have to 
> make a choice for the powerpc64-suse-linux compiler.

I'm using the same configuration as the system compiler.  There is no
choice to make.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Go testsuite patch committed: Add -I. when compiling in directory

[Ian Lance Taylor via Gcc-patches]

This Go testsuite patch adds a -I. argument when compiling sources in
a directory.  This tells the compiler to import packages in the
current directory first, which is what we want in the testsuite.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
to mainline.

Ian

* go.test/go-test.exp (go-gc-tests): Add -I. when building all
sources in a directory (errorcheckdir, compiledir, rundir,
rundircmpout).
5c642e8b52c0508730a6273f0828e8c10b1be057
diff --git a/gcc/testsuite/go.test/go-test.exp 
b/gcc/testsuite/go.test/go-test.exp
index 067f309a296..8f17cb3db71 100644
--- a/gcc/testsuite/go.test/go-test.exp
+++ b/gcc/testsuite/go.test/go-test.exp
@@ -648,7 +648,7 @@ proc go-gc-tests { } {
set last [lindex $packages end]
set packages [lreplace $packages end end]
foreach p $packages {
-   dg-test -keep-output [lrange $p 1 end] "-O" "-w 
$DEFAULT_GOCFLAGS"
+   dg-test -keep-output [lrange $p 1 end] "-O -I." "-w 
$DEFAULT_GOCFLAGS"
lappend del "[file rootname [file tail [lindex $p 1]]].o"
}
errchk [lindex $last 1] "[lrange $last 2 end]"
@@ -692,7 +692,7 @@ proc go-gc-tests { } {
if { [llength $packages] > 0 } {
set del [list]
foreach p $packages {
-   dg-test -keep-output [lindex $p 1] "[lrange $p 2 end] -O" 
"-w $DEFAULT_GOCFLAGS"
+   dg-test -keep-output [lindex $p 1] "[lrange $p 2 end] -O 
-I." "-w $DEFAULT_GOCFLAGS"
lappend del "[file rootname [file tail [lindex $p 1]]].o"
}
foreach f $del {
@@ -712,7 +712,7 @@ proc go-gc-tests { } {
set last [lindex $packages end]
set packages [lreplace $packages end end]
foreach p $packages {
-   dg-test -keep-output [lrange $p 1 end] "-O" "-w 
$DEFAULT_GOCFLAGS"
+   dg-test -keep-output [lrange $p 1 end] "-O -I." "-w 
$DEFAULT_GOCFLAGS"
lappend del "[file rootname [file tail [lindex $p 1]]].o"
}
set dg-do-what-default "link"
@@ -737,11 +737,11 @@ proc go-gc-tests { } {
set last [lindex $packages end]
set packages [lreplace $packages end end]
foreach p $packages {
-   dg-test -keep-output [lrange $p 1 end] "-O" "-w 
$DEFAULT_GOCFLAGS"
+   dg-test -keep-output [lrange $p 1 end] "-O -I." "-w 
$DEFAULT_GOCFLAGS"
lappend del "[file rootname [file tail [lindex $p 1]]].o"
}
set dg-do-what-default "link"
-   dg-test -keep-output [lrange $last 1 end] "$del -O" "-w 
$DEFAULT_GOCFLAGS"
+   dg-test -keep-output [lrange $last 1 end] "$del -O -I." "-w 
$DEFAULT_GOCFLAGS"
set base "[file rootname [file tail [lindex $last 1]]]"
set output_file "./$base.exe"
lappend del $output_file

[patch] Fix checking failure in IPA-SRA

[Eric Botcazou]

Hi,

this is a regression present on the mainline and 10 branch: on the one hand, 
IPA-SRA does *not* disqualify accesses with zero size but, on the other hand, 
it checks that accesses present in the tree have a (strictly) positive size,
thus trivially yielding an ICE, for example on the attached Ada testcase.

The attached fix relaxes the check, OK for mainline and 10 branch?


2020-12-03  Eric Botcazou  

* ipa-sra.c (verify_access_tree_1): Relax assertion on the size.


2020-12-03  Eric Botcazou  

* gnat.dg/opt91.ad[sb]: New test.
* gnat.dg/opt91_pkg.ad[sb]: New helper.

-- 
Eric Botcazoudiff --git a/gcc/ipa-sra.c b/gcc/ipa-sra.c
index 82acc6a21cb..7adc4b688f3 100644
--- a/gcc/ipa-sra.c
+++ b/gcc/ipa-sra.c
@@ -1480,7 +1480,7 @@ verify_access_tree_1 (gensum_param_access *access, HOST_WIDE_INT parent_offset,
 {
   while (access)
 {
-  gcc_assert (access->offset >= 0 && access->size > 0);
+  gcc_assert (access->offset >= 0 && access->size >= 0);
 
   if (parent_size != 0)
 	{
package body Opt91_Pkg is

   package body Pure_Relation is

  overriding function Custom_Image (Self : Rel) return String is
  begin
 return Custom_Image (Self.Rel);
  end Custom_Image;

   end Pure_Relation;

end Opt91_Pkg;
package Opt91_Pkg is

   type Base_Relation is abstract tagged null record;

   function Custom_Image (Self : Base_Relation) return String is abstract;

   generic
  type Ty is private;
  with function Custom_Image (Self : Ty) return String is <>;
   package Pure_Relation is

  type Rel is new Base_Relation with record
 Rel : Ty;
  end record;

  overriding function Custom_Image (Self : Rel) return String;
   end Pure_Relation;

end Opt91_Pkg;
-- { dg-do compile }
-- { dg-options "-O2 -fchecking=1" }

package body Opt91 is

   function Custom_Image (Self : True_Relation_Rec) return String is
   begin
  return "";
   end;

end Opt91;
with Opt91_Pkg; use Opt91_Pkg;

package Opt91 is

   type True_Relation_Rec is null record;
   function Custom_Image (Self : True_Relation_Rec) return String;

   package True_Relation is new Pure_Relation (Ty => True_Relation_Rec);

end Opt91;

[PATCH] v2: doc/implement-c.texi: About same-as-scalar-type volatile aggregate accesses, PR94600

[Hans-Peter Nilsson via Gcc-patches]

Belatedly, here's an updated version, using Martin Sebor's
suggested wording from
"https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549580.html";.
I added two commas, hopefully helpfully.  Albeit ok'd by Richard
Biener in
"https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549922.html";,
better have this reviewed properly, including markup (none added).

Ok for trunk (gcc-11) and gcc-10?


---
We say very little about reads and writes to aggregate /
compound objects, just scalar objects (i.e. assignments don't
cause reads).  Let's lets say something safe about aggregate
objects, but only for those that are the same size as a scalar
type.

There's an equal-sounding section (Volatiles) in extend.texi,
but this seems a more appropriate place, as specifying the
behavior of a standard qualifier.

gcc:

2020-12-02  Hans-Peter Nilsson  
Martin Sebor  

PR middle-end/94600
* doc/implement-c.texi (Qualifiers implementation): Add blurb
about access to the whole of a volatile aggregate object, only for
same-size as a scalar object.
---
 gcc/doc/implement-c.texi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/gcc/doc/implement-c.texi b/gcc/doc/implement-c.texi
index 692297b69c4..2e9158a2a45 100644
--- a/gcc/doc/implement-c.texi
+++ b/gcc/doc/implement-c.texi
@@ -576,6 +576,11 @@ are of scalar types, the expression is interpreted by GCC 
as a read of
 the volatile object; in the other cases, the expression is only evaluated
 for its side effects.
 
+When an object of an aggregate type, with the same size and alignment as a
+scalar type S, is the subject of a volatile access by an assignment
+expression or an atomic function, the access to it is performed as if the
+object's declared type were volatile S.
+
 @end itemize
 
 @node Declarators implementation
-- 
2.11.0

Go testsuite patch committed: Add a bunch of new tests

[Ian Lance Taylor via Gcc-patches]

This patch to the Go testsuite adds a bunch of new tests from the
source repo.  These are mostly tests that were added specifically to
test gccgo.  There are still other tests in the source repo that are
not reflected in the gccgo copy.  Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu.  Committed to mainline.

Ian


patch.txt.bz2
Description: application/bzip

c++: uninstantiated template friends

[Nathan Sidwell]

template friends need to be recognized by module streaming and
associated with the befriending class.  but their context is that of
the friend (a namespace or other class).  This adds a flag to mark
such templates, and uses their DECL_CHAIN to point at the befriender.

gcc/cp
* cp-tree.h (DECL_UNINSTANTIATED_TEMPLATE_FRIEND): New.
* pt.c (push_template_decl): Set it.
(tsubst_friend_function): Clear it.

pushing to trunk

--
Nathan Sidwell
diff --git i/gcc/cp/cp-tree.h w/gcc/cp/cp-tree.h
index 69f8ed56e62..4db50128443 100644
--- i/gcc/cp/cp-tree.h
+++ w/gcc/cp/cp-tree.h
@@ -545,6 +545,7 @@ extern GTY(()) tree cp_global_trees[CPTI_MAX];
   DECL_ANON_UNION_VAR_P (in a VAR_DECL)
   DECL_SELF_REFERENCE_P (in a TYPE_DECL)
   DECL_INVALID_OVERRIDER_P (in a FUNCTION_DECL)
+  DECL_UNINSTANIATED_TEMPLATE_FRIEND_P (in TEMPLATE_DECL)
5: DECL_INTERFACE_KNOWN.
6: DECL_THIS_STATIC (in VAR_DECL, FUNCTION_DECL or PARM_DECL)
   DECL_FIELD_IS_BASE (in FIELD_DECL)
@@ -3161,6 +3162,13 @@ struct GTY(()) lang_decl {
   (DECL_LANG_SPECIFIC (FUNCTION_DECL_CHECK (NODE)) \
->u.base.friend_or_tls)
 
+/* True of a TEMPLATE_DECL that is a template class friend.  Such
+   decls are not pushed until instantiated (as they may depend on
+   parameters of the befriending class).  DECL_CHAIN is the
+   befriending class.  */
+#define DECL_UNINSTANTIATED_TEMPLATE_FRIEND_P(NODE) \
+  (DECL_LANG_FLAG_4 (TEMPLATE_DECL_CHECK (NODE)))
+
 /* Nonzero if the thread-local variable was declared with __thread as
opposed to thread_local.  */
 #define DECL_GNU_TLS_P(NODE)\
diff --git i/gcc/cp/pt.c w/gcc/cp/pt.c
index 3ca28133d94..08931823d57 100644
--- i/gcc/cp/pt.c
+++ w/gcc/cp/pt.c
@@ -22,7 +22,9 @@ along with GCC; see the file COPYING3.  If not see
 /* Known bugs or deficiencies include:
 
  all methods must be provided in header files; can't use a source
- file that contains only the method templates and "just win".  */
+ file that contains only the method templates and "just win".
+
+ Fixed by: C++20 modules.  */
 
 #include "config.h"
 #include "system.h"
@@ -6044,6 +6046,14 @@ push_template_decl (tree decl, bool is_friend)
 	  tmpl = NULL_TREE;
 	}
 	}
+  else if (is_friend)
+	{
+	  /* Record this decl as belonging to the current class.  It's
+	 not chained onto anything else.  */
+	  DECL_UNINSTANTIATED_TEMPLATE_FRIEND_P (tmpl) = true;
+	  gcc_checking_assert (!DECL_CHAIN (tmpl));
+	  DECL_CHAIN (tmpl) = current_scope ();
+	}
 }
   else if (tmpl)
 /* The type may have been completed, or (erroneously) changed.  */
@@ -11053,6 +11063,7 @@ tsubst_friend_function (tree decl, tree args)
   DECL_USE_TEMPLATE (new_friend) = 0;
   if (TREE_CODE (new_friend) == TEMPLATE_DECL)
 {
+  DECL_UNINSTANTIATED_TEMPLATE_FRIEND_P (new_friend) = false;
   DECL_USE_TEMPLATE (DECL_TEMPLATE_RESULT (new_friend)) = 0;
   DECL_SAVED_TREE (DECL_TEMPLATE_RESULT (new_friend))
 	= DECL_SAVED_TREE (DECL_TEMPLATE_RESULT (decl));

[committed] libstdc++: Add std::bit_cast for C++20 [PR 93121]

[Jonathan Wakely via Gcc-patches]

Thanks to Jakub's addition of the built-in, we can add this to the
library now. The compiler tests for the built-in are quite extensive,
including verifying the constraints, so this only adds minimal tests to
the library testsuite.

This doesn't add a new _GLIBCXX_HAVE_BUILTIN_BIT_CAST because using
__has_builtin(__builtin_bit_cast) works for GCC and versions of Clang
that provide the built-in.

libstdc++-v3/ChangeLog:

PR libstdc++/93121
* include/std/bit (__cpp_lib_bit_cast, bit_cast): Define.
* include/std/version (__cpp_lib_bit_cast): Define.
* testsuite/26_numerics/bit/bit.cast/bit_cast.cc: New test.
* testsuite/26_numerics/bit/bit.cast/version.cc: New test.

Tested powerpc64le-linux. Committed to trunk.

commit 9e433b3461ab64b38350817392a77efb67bb78b4
Author: Jonathan Wakely 
Date:   Thu Dec 3 19:17:13 2020

libstdc++: Add std::bit_cast for C++20 [PR 93121]

Thanks to Jakub's addition of the built-in, we can add this to the
library now. The compiler tests for the built-in are quite extensive,
including verifying the constraints, so this only adds minimal tests to
the library testsuite.

This doesn't add a new _GLIBCXX_HAVE_BUILTIN_BIT_CAST because using
__has_builtin(__builtin_bit_cast) works for GCC and versions of Clang
that provide the built-in.

libstdc++-v3/ChangeLog:

PR libstdc++/93121
* include/std/bit (__cpp_lib_bit_cast, bit_cast): Define.
* include/std/version (__cpp_lib_bit_cast): Define.
* testsuite/26_numerics/bit/bit.cast/bit_cast.cc: New test.
* testsuite/26_numerics/bit/bit.cast/version.cc: New test.

diff --git a/libstdc++-v3/include/std/bit b/libstdc++-v3/include/std/bit
index 16f7eba46d7..1d99c807c4a 100644
--- a/libstdc++-v3/include/std/bit
+++ b/libstdc++-v3/include/std/bit
@@ -49,6 +49,18 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
* @{
*/
 
+#if __cplusplus > 201703l && __has_builtin(__builtin_bit_cast)
+#define __cpp_lib_bit_cast 201806L
+
+  /// Create a value of type `To` from the bits of `from`.
+  template
+constexpr _To
+bit_cast(const _From& __from) noexcept
+{
+  return __builtin_bit_cast(_To, __from);
+}
+#endif
+
   /// @cond undoc
 
   template
diff --git a/libstdc++-v3/include/std/version b/libstdc++-v3/include/std/version
index 25f628f399d..6e4bd99b361 100644
--- a/libstdc++-v3/include/std/version
+++ b/libstdc++-v3/include/std/version
@@ -201,6 +201,9 @@
 # define __cpp_lib_atomic_wait 201907L
 #endif
 #define __cpp_lib_bind_front 201907L
+#if __has_builtin(__builtin_bit_cast)
+# define __cpp_lib_bit_cast 201806L
+#endif
 // FIXME: #define __cpp_lib_execution 201902L
 #define __cpp_lib_integer_comparison_functions 202002L
 #define __cpp_lib_constexpr_algorithms 201806L
diff --git a/libstdc++-v3/testsuite/26_numerics/bit/bit.cast/bit_cast.cc 
b/libstdc++-v3/testsuite/26_numerics/bit/bit.cast/bit_cast.cc
new file mode 100644
index 000..b451f152b47
--- /dev/null
+++ b/libstdc++-v3/testsuite/26_numerics/bit/bit.cast/bit_cast.cc
@@ -0,0 +1,81 @@
+// 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 } }
+
+#include 
+
+#ifndef __cpp_lib_bit_cast
+# error "Feature-test macro for bit_cast wait missing in "
+#elif __cpp_lib_bit_cast != 201806L
+# error "Feature-test macro for bit_cast wait has wrong value in "
+#endif
+
+#include 
+#include 
+#include 
+
+template
+constexpr bool
+check(const From& from)
+{
+  return std::bit_cast(std::bit_cast(from)) == from;
+}
+
+void
+test01()
+{
+  static_assert( std::bit_cast(123) == 123 );
+  static_assert( std::bit_cast(123u) == 123 );
+  static_assert( std::bit_cast(~0u) == ~0 );
+
+  if constexpr (sizeof(int) == sizeof(float))
+static_assert( check(12.34f) );
+  if constexpr (sizeof(unsigned long long) == sizeof(double))
+static_assert( check(123.456) );
+  if constexpr (sizeof(std::intptr_t) == sizeof(void(*)()))
+VERIFY( check(&test01) );
+}
+
+void
+test02()
+{
+  struct S
+  {
+int i;
+
+bool operator==(const char* s) const
+{ return std::memcmp(&i, s, sizeof(i)) == 0; }
+  };
+
+  char arr[sizeof(int)];
+  char arr2[sizeof(int)];
+  for (int i = 0;

[committed] libstdc++: Update C++20 library implementation status

[Jonathan Wakely via Gcc-patches]

libstdc++-v3/ChangeLog:

* doc/xml/manual/status_cxx2020.xml: Update C++20 status.
* doc/html/*: Regenerate.

Tested powerpc64le-linux. Committed to trunk.

commit 44ac1ea0e2244343b798ff1ccc7048029cb9fa02
Author: Jonathan Wakely 
Date:   Thu Dec 3 19:17:13 2020

libstdc++: Update C++20 library implementation status

libstdc++-v3/ChangeLog:

* doc/xml/manual/status_cxx2020.xml: Update C++20 status.
* doc/html/*: Regenerate.

diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2020.xml 
b/libstdc++-v3/doc/xml/manual/status_cxx2020.xml
index e633365ab40..b62a432eed1 100644
--- a/libstdc++-v3/doc/xml/manual/status_cxx2020.xml
+++ b/libstdc++-v3/doc/xml/manual/status_cxx2020.xml
@@ -357,24 +357,22 @@ or any notes about the implementation.
 
 
 
-  
 C++ Synchronized Buffered Ostream 
   
 http://www.w3.org/1999/xlink"; 
xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0053r7.pdf";>
 P0053R7 
   
-   
+   11 
__cpp_lib_syncbuf >= 201711L 
 
 
 
-  
 Manipulators for C++ Synchronized Buffered Ostream 
   
 http://www.w3.org/1999/xlink"; 
xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0753r2.pdf";>
 P0753R2 
   
-   
+   11 
__cpp_lib_syncbuf >= 201803L 
 
 
@@ -1024,13 +1022,12 @@ or any notes about the implementation.
 
 
 
-  
 Bit-casting object representations 
   
 http://www.w3.org/1999/xlink"; 
xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0476r2.html";>
 P0476R2 
   
-   
+   11 
__cpp_lib_bit_cast >= 201806L 
 
 
@@ -1411,26 +1408,24 @@ or any notes about the implementation.
 
 
 
-  
std::source_location 
   
 http://www.w3.org/1999/xlink"; 
xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1208r6.pdf";>
 P1208R6 
   
-   
+   11 
   
 __cpp_lib_source_location >= 201907L
   
 
 
 
-  
Efficient access to std::basic_stringbuf's Buffer 
   
 http://www.w3.org/1999/xlink"; 
xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0408r7.pdf";>
 P0408R7 
   
-   
+   11 
   
 
 

Re: [ PATCH ] [ C++ ] [ libstdc++ ] P1208r6 Merge source_location

[Jonathan Wakely via Gcc-patches]

On 02/01/20 17:20 -0500, JeanHeyd Meneide wrote:

On Thu, Jan 2, 2020 at 5:07 PM Jakub Jelinek  wrote:


On Thu, Jan 02, 2020 at 04:57:01PM -0500, JeanHeyd Meneide wrote:
> +#if defined(_GLIBCXX_HAVE_BUILTIN_SOURCE_LOCATION)
> +# define __cpp_lib_source_location 201907L
> +#elif defined(_GLIBCXX_HAVE_BUILTIN_LINE) && 
defined(_GLIBCXX_HAVE_BUILTIN_COLUMN)
> +# define __cpp_lib_is_constant_evaluated 201907L

How is __cpp_lib_is_constant_evaluated related to presence of __builtin_LINE
and __builtin_COLUMN?


Oops. Sorry; fat-fingered the diff a little!


I've committed a slightly reworked version of JeanHeyd's
 patch (see attached). Jakub has improved the
built-in so all the commented out tests work now. There's one more
compiler patch coming to use __PRETTY_FUNCTION__ for the function
name, so I'll tweak the new tests after than has gone in.

Tested powerpc64le-linux, committed to trunk.

Thanks, JeanHeyd!


commit 57d76ee9cf6265e012fad6286adfaeaba9414c11
Author: JeanHeyd Meneide 
Date:   Thu Dec 3 19:17:13 2020

libtdc++: Define std::source_location for C++20

This doesn't define a new _GLIBCXX_HAVE_BUILTIN_SOURCE_LOCATION macro.
because using __has_builtin(__builtin_source_location) is sufficient.
Currently only GCC supports it, but if/when Clang and Intel add it the
__has_builtin check should for them too.

Co-authored-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:

* doc/doxygen/user.cfg.in (INPUT): Add .
* include/Makefile.am: Add .
* include/Makefile.in: Regenerate.
* include/std/version (__cpp_lib_source_location): Define.
* include/std/source_location: New file.
* testsuite/18_support/source_location/1.cc: New test.
* testsuite/18_support/source_location/consteval.cc: New test.
* testsuite/18_support/source_location/srcloc.h: New test.
* testsuite/18_support/source_location/version.cc: New test.

diff --git a/libstdc++-v3/doc/doxygen/user.cfg.in b/libstdc++-v3/doc/doxygen/user.cfg.in
index 1966055e675..2261d572efb 100644
--- a/libstdc++-v3/doc/doxygen/user.cfg.in
+++ b/libstdc++-v3/doc/doxygen/user.cfg.in
@@ -891,6 +891,7 @@ INPUT  = @srcdir@/doc/doxygen/doxygroups.cc \
  include/semaphore \
  include/set \
  include/shared_mutex \
+ include/source_location \
  include/span \
  include/sstream \
  include/stack \
diff --git a/libstdc++-v3/include/Makefile.am b/libstdc++-v3/include/Makefile.am
index ca413b8fdfe..9dbc7dcb32d 100644
--- a/libstdc++-v3/include/Makefile.am
+++ b/libstdc++-v3/include/Makefile.am
@@ -73,6 +73,7 @@ std_headers = \
 	${std_srcdir}/semaphore \
 	${std_srcdir}/set \
 	${std_srcdir}/shared_mutex \
+	${std_srcdir}/source_location \
 	${std_srcdir}/span \
 	${std_srcdir}/sstream \
 	${std_srcdir}/syncstream \
diff --git a/libstdc++-v3/include/std/source_location b/libstdc++-v3/include/std/source_location
new file mode 100644
index 000..13d4bd48857
--- /dev/null
+++ b/libstdc++-v3/include/std/source_location
@@ -0,0 +1,92 @@
+//  -*- C++ -*-
+
+// 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.
+
+// Under Section 7 of GPL version 3, you are granted additional
+// permissions described in the GCC Runtime Library Exception, version
+// 3.1, as published by the Free Software Foundation.
+
+// You should have received a copy of the GNU General Public License and
+// a copy of the GCC Runtime Library Exception along with this program;
+// see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+// .
+
+/** @file include/source_location
+ *  This is a Standard C++ Library header.
+ */
+
+#ifndef _GLIBCXX_SRCLOC
+#define _GLIBCXX_SRCLOC 1
+
+#if __cplusplus > 201703L && __has_builtin(__builtin_source_location)
+#include 
+
+namespace std
+{
+_GLIBCXX_BEGIN_NAMESPACE_VERSION
+
+#define __cpp_lib_source_location 201907L
+
+  /// A class that describes a location in source code.
+  struct source_location
+  {
+  private:
+using uint_least32_t = __UINT_LEAST32_TYPE__;
+
+  public:
+
+// [support.srcloc.cons], creation
+static consteval source_location
+current(const void* __p = __builtin_source_location()) noexcept
+{
+  source_location __ret;
+  

Re: [committed] libstdc++: Add std::bit_cast for C++20 [PR 93121]

[Jonathan Wakely via Gcc-patches]

On 03/12/20 19:25 +, Jonathan Wakely wrote:

Thanks to Jakub's addition of the built-in, we can add this to the
library now. The compiler tests for the built-in are quite extensive,
including verifying the constraints, so this only adds minimal tests to
the library testsuite.

This doesn't add a new _GLIBCXX_HAVE_BUILTIN_BIT_CAST because using
__has_builtin(__builtin_bit_cast) works for GCC and versions of Clang
that provide the built-in.

libstdc++-v3/ChangeLog:

PR libstdc++/93121
* include/std/bit (__cpp_lib_bit_cast, bit_cast): Define.
* include/std/version (__cpp_lib_bit_cast): Define.
* testsuite/26_numerics/bit/bit.cast/bit_cast.cc: New test.
* testsuite/26_numerics/bit/bit.cast/version.cc: New test.


This fixes some typos in the new tests.

Tested x86_64-linux. Committed to trunk.


commit 656131e06aa76ba3cb50305c07cf5c8ee79fce44
Author: Jonathan Wakely 
Date:   Thu Dec 3 19:30:02 2020

libstdc++: Fix typos in #error strings

libstdc++-v3/ChangeLog:

* testsuite/26_numerics/bit/bit.cast/bit_cast.cc: Remove stray
word from copy&paste.
* testsuite/26_numerics/bit/bit.cast/version.cc: Likewise.

diff --git a/libstdc++-v3/testsuite/26_numerics/bit/bit.cast/bit_cast.cc b/libstdc++-v3/testsuite/26_numerics/bit/bit.cast/bit_cast.cc
index b451f152b47..138ceb1c4d6 100644
--- a/libstdc++-v3/testsuite/26_numerics/bit/bit.cast/bit_cast.cc
+++ b/libstdc++-v3/testsuite/26_numerics/bit/bit.cast/bit_cast.cc
@@ -21,9 +21,9 @@
 #include 
 
 #ifndef __cpp_lib_bit_cast
-# error "Feature-test macro for bit_cast wait missing in "
+# error "Feature-test macro for bit_cast missing in "
 #elif __cpp_lib_bit_cast != 201806L
-# error "Feature-test macro for bit_cast wait has wrong value in "
+# error "Feature-test macro for bit_cast has wrong value in "
 #endif
 
 #include 
diff --git a/libstdc++-v3/testsuite/26_numerics/bit/bit.cast/version.cc b/libstdc++-v3/testsuite/26_numerics/bit/bit.cast/version.cc
index 688d44bbb89..82e97543481 100644
--- a/libstdc++-v3/testsuite/26_numerics/bit/bit.cast/version.cc
+++ b/libstdc++-v3/testsuite/26_numerics/bit/bit.cast/version.cc
@@ -21,7 +21,7 @@
 #include 
 
 #ifndef __cpp_lib_bit_cast
-# error "Feature-test macro for bit_cast wait missing in "
+# error "Feature-test macro for bit_cast missing in "
 #elif __cpp_lib_bit_cast != 201806L
-# error "Feature-test macro for bit_cast wait has wrong value in "
+# error "Feature-test macro for bit_cast has wrong value in "
 #endif

Re: [PATCH v2] rs6000, vector integer multiply/divide/modulo instructions

[will schmidt via Gcc-patches]

On Tue, 2020-12-01 at 15:48 -0800, Carl Love via Gcc-patches wrote:
> Segher, Pat:
> 
> I have updated the patch to address the comments below.
> 
> On Wed, 2020-11-25 at 20:30 -0600, Segher Boessenkool wrote:
> > On Tue, Nov 24, 2020 at 08:34:51PM -0600, Pat Haugen wrote:
> > > On 11/24/20 8:17 PM, Pat Haugen via Gcc-patches wrote:
> > > > On 11/24/20 12:59 PM, Carl Love via Gcc-patches wrote:
> > > > > +(define_insn "modu_"
> > > > > +  [(set (match_operand:VIlong 0 "vsx_register_operand" "=v")
> > > > > + (umod:VIlong (match_operand:VIlong 1
> > > > > "vsx_register_operand" "v")
> > > > > +  (match_operand:VIlong 2
> > > > > "vsx_register_operand" "v")))]
> > > > > +  "TARGET_POWER10"
> > > > > +  "vmodu %0,%1,%2"
> > > > > +  [(set_attr "type" "vecdiv")
> > > > > +   (set_attr "size" "128")])
> > > > 
> > > > We should only be setting "size" "128" for instructions that
> > > > operate on scalar 128-bit data items (i.e. 'vdivesq' etc).
> > > > Since
> > > > the above insns are either V2DI/V4SI (ala VIlong
> > > > mode_iterator),
> > > > they shouldn't be marked as size 128. If you want to set the
> > > > size
> > > > based on mode, (set_attr "size" "") should do the trick I
> > > > believe.
> > > 
> > > Well, after you update "(define_mode_attr bits" in rs6000.md for
> > > V2DI/V4SI.
> > 
> > So far,  was only used for scalars.  I agree that for vectors
> > it
> > makes most sense to do the element size (because the vector size
> > always
> > is 128 bits, and for scheduling the element size can matter).  But,
> > the
> > definitions of  and  now say
> > 
> > ;; What data size does this instruction work on?
> > ;; This is used for insert, mul and others as necessary.
> > (define_attr "size" "8,16,32,64,128" (const_string "32"))
> > 
> > and
> > 
> > ;; How many bits in this mode?
> > (define_mode_attr bits [(QI "8") (HI "16") (SI "32") (DI "64")
> >(SF "32") (DF "64")])
> > so those need a bit of update as well then :-)
> 
> I set the size based on the vector element size, extendeing the
> define_mode_attr bits definition.  Please take a look at the updated
> patch.  Hopefully I have this all correct.  Thanks.
> 
> Note, I retested the updated patch on 
> 
>   powerpc64le-unknown-linux-gnu (Power 9 LE)
>   powerpc64le-unknown-linux-gnu (Power 10 LE)
> 
> Thanks for the help.
> 
>  Carl 
> 

Continued from yesterday..  
Thanks
-Will

> ---
> 
> rs6000, vector integer multiply/divide/modulo instructions
> 
> 2020-12-01  Carl Love  
> 
> gcc/
>   * config/rs6000/altivec.h (vec_mulh, vec_div, vec_dive,
> vec_mod): New
>   defines.
>   * config/rs6000/altivec.md (VIlong): Move define to file
> vsx.md.
>   * config/rs6000/rs6000-builtin.def (DIVES_V4SI, DIVES_V2DI,
>   DIVEU_V4SI, DIVEU_V2DI, DIVS_V4SI, DIVS_V2DI, DIVU_V4SI,
>   DIVU_V2DI, MODS_V2DI, MODS_V4SI, MODU_V2DI, MODU_V4SI,
>   MULHS_V2DI, MULHS_V4SI, MULHU_V2DI, MULHU_V4SI, MULLD_V2DI):
>   Add builtin define.
>   (MULH, DIVE, MOD):  Add new BU_P10_OVERLOAD_2 definitions.
>   * config/rs6000/rs6000-call.c (VSX_BUILTIN_VEC_DIV,
>   P10_BUILTIN_VEC_VDIVE, P10_BUILTIN_VEC_VMOD, 
> P10_BUILTIN_VEC_VMULH):
No mentions of these three P10_BUILTIN_VEC_* in patch below.


>   New overloaded definitions.
>   (builtin_function_type) [P10V_BUILTIN_DIVEU_V4SI,
>   P10V_BUILTIN_DIVEU_V2DI, P10V_BUILTIN_DIVU_V4SI,
>   P10V_BUILTIN_DIVU_V2DI, P10V_BUILTIN_MODU_V2DI,
>   P10V_BUILTIN_MODU_V4SI, P10V_BUILTIN_MULHU_V2DI,
>   P10V_BUILTIN_MULHU_V4SI, P10V_BUILTIN_MULLD_V2DI]: Add case
>   statement for builtins.
>   * config/rs6000/vsx.md (VIlong_char): Add define_mod_attribute.

just VIlong 
Maybe s/define_mod_attribute/define_mod_attr /  ? 

>   (UNSPEC_VDIVES, UNSPEC_VDIVEU): Add enum for UNSPECs.



>   (vsx_mul_v2di, vsx_udiv_v2di): Add if TARGET_POWER10 statement.

I don't see vsx_mul_v2di or vsx_udiv_v2di in the patch contexts, Looks
OK per a look at trunks vsx.md. 

>   (dives_, diveu_, div3, uvdiv3,
>   mods_, modu_, mulhs_, mulhu_,
> mulv2di3):
>   Add define_insn, mode is VIlong.
>   * doc/extend.texi (vec_mulh, vec_mul, vec_div, vec_dive,
> vec_mod): Add
>   builtin descriptions.
> 
> gcc/testsuite/
>   * gcc.target/powerpc/builtins-1-p10-runnable.c: New test file.
> ---
>  gcc/config/rs6000/altivec.h   |   5 +
>  gcc/config/rs6000/altivec.md  |   2 -
>  gcc/config/rs6000/rs6000-builtin.def  |  22 +
>  gcc/config/rs6000/rs6000-call.c   |  49 +++
>  gcc/config/rs6000/rs6000.md   |   3 +-
>  gcc/config/rs6000/vsx.md  | 213 +++---
>  gcc/doc/extend.texi   | 120 ++
>  .../powerpc/builtins-1-p10-runnable.c | 398
> ++
>  8 files changed, 759 insertions(+), 53 deletion

Re: Go testsuite patch committed: Add a bunch of new tests

[Ian Lance Taylor via Gcc-patches]

On Thu, Dec 3, 2020 at 11:15 AM Ian Lance Taylor  wrote:
>
> This patch to the Go testsuite adds a bunch of new tests from the
> source repo.  These are mostly tests that were added specifically to
> test gccgo.  There are still other tests in the source repo that are
> not reflected in the gccgo copy.  Bootstrapped and ran Go testsuite on
> x86_64-pc-linux-gnu.  Committed to mainline.

Unfortunately I was working from an older copy of the tests, and
forgot to sync them up from the source repo.  This updates the new
tests to the current versions in the source repo.  Bootstrapped and
ran Go testsuite on x86_64-pc-linux-gnu.  Committed to mainline.

Ian

c++: Exported using decls

[Nathan Sidwell]

With modules we need to record whethe a (namespace-scope) using decl
is exporting the named entities.  Record this on the OVERLOAD marking
the used decl.

gcc/cp/
* cp-tree.h (OVL_EXPORT): New.
(class ovl_iterator): Add get_using, exporting_p.
* tree.c (ovl_insert): Extend using_or_hidden meaning to include
an exported using.

pushed to trunk
--
Nathan Sidwell
diff --git i/gcc/cp/cp-tree.h w/gcc/cp/cp-tree.h
index 4db50128443..4720af2175a 100644
--- i/gcc/cp/cp-tree.h
+++ w/gcc/cp/cp-tree.h
@@ -503,6 +503,7 @@ extern GTY(()) tree cp_global_trees[CPTI_MAX];
   FUNCTION_RVALUE_QUALIFIED (in FUNCTION_TYPE, METHOD_TYPE)
   CALL_EXPR_REVERSE_ARGS (in CALL_EXPR, AGGR_INIT_EXPR)
   CONSTRUCTOR_PLACEHOLDER_BOUNDARY (in CONSTRUCTOR)
+  OVL_EXPORT_P (in OVERLOAD)
6: TYPE_MARKED_P (in _TYPE)
   DECL_NONTRIVIALLY_INITIALIZED_P (in VAR_DECL)
   RANGE_FOR_IVDEP (in RANGE_FOR_STMT)
@@ -780,6 +781,8 @@ typedef struct ptrmem_cst * ptrmem_cst_t;
 #define OVL_NESTED_P(NODE)	TREE_LANG_FLAG_3 (OVERLOAD_CHECK (NODE))
 /* If set, this overload was constructed during lookup.  */
 #define OVL_LOOKUP_P(NODE)	TREE_LANG_FLAG_4 (OVERLOAD_CHECK (NODE))
+/* If set, this OVL_USING_P overload is exported.  */
+#define OVL_EXPORT_P(NODE)	TREE_LANG_FLAG_5 (OVERLOAD_CHECK (NODE))
 
 /* The first decl of an overload.  */
 #define OVL_FIRST(NODE)	ovl_first (NODE)
@@ -839,6 +842,11 @@ class ovl_iterator {
 
 return fn;
   }
+  tree get_using () const
+  {
+gcc_checking_assert (using_p ());
+return ovl;
+  }
 
  public:
   /* Whether this overload was introduced by a using decl.  */
@@ -847,6 +855,12 @@ class ovl_iterator {
 return (TREE_CODE (ovl) == USING_DECL
 	|| (TREE_CODE (ovl) == OVERLOAD && OVL_USING_P (ovl)));
   }
+  /* Whether this using is being exported.  */
+  bool exporting_p () const
+  {
+return OVL_EXPORT_P (get_using ());
+  }
+  
   bool hidden_p () const
   {
 return TREE_CODE (ovl) == OVERLOAD && OVL_HIDDEN_P (ovl);
diff --git i/gcc/cp/tree.c w/gcc/cp/tree.c
index 8d7df60f963..d9fa505041f 100644
--- i/gcc/cp/tree.c
+++ w/gcc/cp/tree.c
@@ -2272,10 +2272,11 @@ ovl_make (tree fn, tree next)
   return result;
 }
 
-/* Add FN to the (potentially NULL) overload set OVL.  USING_OR_HIDDEN
-   is > 0, if FN is via a using declaration.  USING_OR_HIDDEN is < 0,
-   if FN is hidden.  (A decl cannot be both using and hidden.)  We
-   keep the hidden decls first, but remaining ones are unordered.  */
+/* Add FN to the (potentially NULL) overload set OVL.  USING_OR_HIDDEN is >
+   zero if this is a using-decl.  It is > 1 if we're exporting the
+   using decl.  USING_OR_HIDDEN is < 0, if FN is hidden.  (A decl
+   cannot be both using and hidden.)  We keep the hidden decls first,
+   but remaining ones are unordered.  */
 
 tree
 ovl_insert (tree fn, tree maybe_ovl, int using_or_hidden)
@@ -2299,7 +2300,11 @@ ovl_insert (tree fn, tree maybe_ovl, int using_or_hidden)
   if (using_or_hidden < 0)
 	OVL_HIDDEN_P (maybe_ovl) = true;
   if (using_or_hidden > 0)
-	OVL_DEDUP_P (maybe_ovl) = OVL_USING_P (maybe_ovl) = true;
+	{
+	  OVL_DEDUP_P (maybe_ovl) = OVL_USING_P (maybe_ovl) = true;
+	  if (using_or_hidden > 1)
+	OVL_EXPORT_P (maybe_ovl) = true;
+	}
 }
   else
 maybe_ovl = fn;

Re: [PATCH RFA] vec: Simplify use with C++11 range-based 'for'.

[Jeff Law via Gcc-patches]

On 12/3/20 10:53 AM, Jason Merrill via Gcc-patches wrote:
> It looks cleaner if we can use a vec* directly as a range for the C++11
> range-based 'for' loop, without needing to indirect from it, and also works
> with null pointers.
>
> The change in cp_parser_late_parsing_default_args is an example of how this
> can be used to simplify many loops over vec*.
>
> I deliberately didn't format the new overloads for etags since they are
> trivial, but am open to changing that.
>
> Tested x86_64-pc-linux-gnu.  Is this OK for trunk now, or should I hold it for
> stage 1?
>
> gcc/ChangeLog:
>
>   * vec.h (begin, end): Add overloads for vec*.
>   * tree.c (build_constructor_from_vec): Remove *.
>
> gcc/cp/ChangeLog:
>
>   * decl2.c (clear_consteval_vfns): Remove *.
>   * pt.c (do_auto_deduction): Remove *.
>   * parser.c (cp_parser_late_parsing_default_args): Change loop
>   to use range 'for'.
I'd go forward with it now, it's simple enough and simplifies the code
we end up writing...


jeff

Re: [PATCH 1/6] ifcvt: Add missing call to `onlyjump_p'

[Jeff Law via Gcc-patches]

On 12/3/20 4:34 AM, Maciej W. Rozycki wrote:
> Do not convert a conditional jump into conditional execution (and remove 
> the jump as a consequence) if the jump has side effects.
>
>   gcc/
>   * ifcvt.c (dead_or_predicable) [!IFCVT_MODIFY_TESTS]: Bail out 
>   if `!onlyjump_p'.
OK
jeff
> ---
>  gcc/ifcvt.c |6 ++
>  1 file changed, 6 insertions(+)
>
> gcc-ifcvt-dead-or-predicable-ce-only-jump.diff
> Index: gcc/gcc/ifcvt.c
> ===
> --- gcc.orig/gcc/ifcvt.c
> +++ gcc/gcc/ifcvt.c
> @@ -5127,6 +5127,11 @@ dead_or_predicable (basic_block test_bb,
>  
>rtx cond;
>  
> +  /* If the conditional jump is more than just a conditional jump,
> +  then we cannot do conditional execution conversion on this block.  */
> +  if (!onlyjump_p (jump))
> + goto nce;
> +
>cond = cond_exec_get_condition (jump);
>if (! cond)
>   return FALSE;
> @@ -5154,6 +5159,7 @@ dead_or_predicable (basic_block test_bb,
>  
>earliest = jump;
>  }
> + nce:
>  #endif
>  
>/* If we allocated new pseudos (e.g. in the conditional move
>