Re: [PATCH] i386: Optimize vpsubusw compared to 0 into vpcmpleuw or vpcmpnltuw[PR96906]

[Hongtao Liu via Gcc-patches]

On Thu, Dec 3, 2020 at 2:22 AM Jakub Jelinek  wrote:
>
> On Tue, Dec 01, 2020 at 12:49:03PM +0800, Hongtao Liu via Gcc-patches wrote:
> > +bool neq_p = INTVAL (operands[4]) >> 2;
> > +/* LE: 2, NLT: 5, NLE: 6, LT: 1  */
> > +rtx cmp_predicate = neq_p ? GEN_INT (6) : GEN_INT (2);
> > +if (MEM_P (operands[1]))
> > +  {
> > + std::swap (operands[1], operands[2]);
> > + cmp_predicate = neq_p ? GEN_INT (1) : GEN_INT (5);
> > +  }
> > +emit_insn (gen__ucmp3 (operands[0], operands[1],
> > + operands[2], cmp_predicate));
>
> I'd suggest instead:
> +/* LE: 2, NLT: 5, NLE: 6, LT: 1  */
> +int cmp_predicate = 2; /* LE  */
> +if (MEM_P (operands[1]))
> +  {
> +   std::swap (operands[1], operands[2]);
> +   cmp_predicate = 5; /* NLT (GE)  */
> +  }
> +if ((INTVAL (operands[4]) & 4) != 0)
> +  cmp_predictate ^= 4; /* Invert the comparison to NLE (GT) or LT.  */
> +emit_insn (gen__ucmp3 (operands[0], operands[1], 
> operands[2],
> +GEN_INT (cmp_predicate)));
> so that you don't create the rtx CONST_INTs in 4 places and don't do that
> unnecessarily when you will need another constant.
Thanks for the review,committed.
>
> Otherwise LGTM, thanks.
>
> Jakub
>


-- 
BR,
Hongtao

Re: [PATCH][PR target/97642] Fix incorrect replacement of vmovdqu32 with vpblendd.

[Hongtao Liu via Gcc-patches]

On Thu, Dec 3, 2020 at 3:11 AM Jeff Law  wrote:
>
>
>
> On 11/25/20 9:47 PM, Hongtao Liu wrote:
> > On Wed, Nov 25, 2020 at 7:37 PM Jakub Jelinek  wrote:
> >> On Wed, Nov 25, 2020 at 07:32:44PM +0800, Hongtao Liu wrote:
> >>> Update patch:
> >>>   1. ix86_expand_special_args_builtin is used for expanding mask load
> >>> intrinsics, this function will always convert the constant mask
> >>> operands into reg. So for the situation of all-ones mask, keep this
> >>> constant, and also change the mask operand predicate(of corresponding
> >>> expander) to register_or_constm1_operand.
> >>>   2. Delete last_arg_constant which is not used in
> >>> ix86_expand_special_args_builtin(maybe should be in a separate patch?)
> >> Yes, please make it a separate patch, it should go in first and
> >> should just drop last_arg_constant from that function plus the
> >> reindentation.
> >>
> >> Then post the PR97642 incremental to that.
> >>
> > Updated.
> >
> >> Thanks.
> >>
> >> Jakub
> >>
> >
> > 0002-Fix-incorrect-replacement-of-vmovdqu32-with-vpblendd.patch
> >
> > From b1256b6ef8f877244f4955b9205d53797424fc27 Mon Sep 17 00:00:00 2001
> > From: liuhongt 
> > Date: Tue, 3 Nov 2020 17:26:43 +0800
> > Subject: [PATCH 2/2] Fix incorrect replacement of vmovdqu32 with vpblendd
> >  which can cause fault.
> >
> > gcc/ChangeLog:
> >
> >   PR target/97642
> >   * config/i386/i386-expand.c
> >   (ix86_expand_special_args_builtin): Don't move all-ones mask
> >   operands into register.
> >   * config/i386/sse.md (UNSPEC_MASKLOAD): New unspec.
> >   (*_load_mask): New define_insns for masked load
> >   instructions.
> >   (_load_mask): Changed to define_expands which
> >   specifically handle memory or all-ones mask operands.
> >   (_blendm): Changed to define_insns which are same
> >   as original _load_mask with adjustment of
> >   operands order.
> >   (*_load): New define_insn_and_split which is
> >   used to optimize for masked load with all one mask.
> >
> > gcc/testsuite/ChangeLog:
> >
> >   * gcc.target/i386/avx512bw-vmovdqu16-1.c: Adjust testcase to
> >   make sure only masked load instruction is generated.
> >   * gcc.target/i386/avx512bw-vmovdqu8-1.c: Ditto.
> >   * gcc.target/i386/avx512f-vmovapd-1.c: Ditto.
> >   * gcc.target/i386/avx512f-vmovaps-1.c: Ditto.
> >   * gcc.target/i386/avx512f-vmovdqa32-1.c: Ditto.
> >   * gcc.target/i386/avx512f-vmovdqa64-1.c: Ditto.
> >   * gcc.target/i386/avx512vl-vmovapd-1.c: Ditto.
> >   * gcc.target/i386/avx512vl-vmovaps-1.c: Ditto.
> >   * gcc.target/i386/avx512vl-vmovdqa32-1.c: Ditto.
> >   * gcc.target/i386/avx512vl-vmovdqa64-1.c: Ditto.
> >   * gcc.target/i386/pr97642-1.c: New test.
> >   * gcc.target/i386/pr97642-2.c: New test.
> > ---
> > [ ... ]
>
> > diff --git a/gcc/testsuite/gcc.target/i386/pr97642-2.c 
> > b/gcc/testsuite/gcc.target/i386/pr97642-2.c
> > new file mode 100644
> > index 000..eb06a2739b4
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/i386/pr97642-2.c
> > @@ -0,0 +1,77 @@
> > +/* PR target/97642 */
> > +/* { dg-do run } */
> > +/* { dg-options "-O2 -mavx512dq -mavx512vl -mavx512bw" } */
> > +/* { dg-require-effective-target avx512vl } */
> > +/* { dg-require-effective-target avx512dq } */
> > +/* { dg-require-effective-target avx512bw } */
> Given the uses of mprotect in this test, don't we need the test to be
> limited to systems where that's supported.   Even just limiting to linux
> targets is probably sufficient.
>
> With that change, I think this is OK for the trunk.
Thanks for the review,committed.
>
> jeff
>


-- 
BR,
Hongtao

[PATCH v2 08/31] jump: Also handle jumps wrapped in UNSPEC or UNSPEC_VOLATILE

[Maciej W. Rozycki]

VAX has interlocked branch instructions used for atomic operations and
we want to have them wrapped in UNSPEC_VOLATILE so as not to have code
carried across.  This however breaks with jump optimization and leads
to an ICE in the build of libbacktrace like:

.../libbacktrace/mmap.c:190:1: internal compiler error: in fixup_reorder_chain, 
at cfgrtl.c:3934
  190 | }
  | ^
0x1087d46b fixup_reorder_chain
.../gcc/cfgrtl.c:3934
0x1087f29f cfg_layout_finalize()
.../gcc/cfgrtl.c:4447
0x1087c74f execute
.../gcc/cfgrtl.c:3662

on RTL like:

(jump_insn 18 17 150 4 (unspec_volatile [
(set (pc)
(if_then_else (eq (zero_extract:SI (mem/v:SI (reg/f:SI 23 [ _2 
]) [-1  S4 A32])
(const_int 1 [0x1])
(const_int 0 [0]))
(const_int 1 [0x1]))
(label_ref 20)
(pc)))
(set (zero_extract:SI (mem/v:SI (reg/f:SI 23 [ _2 ]) [-1  S4 A32])
(const_int 1 [0x1])
(const_int 0 [0]))
(const_int 1 [0x1]))
] 101) ".../libbacktrace/mmap.c":135:14 158 {jbbssisi}
 (nil)
 -> 20)

when those branches are enabled with a follow-up change.  Also showing
with:

FAIL: gcc.dg/pr61756.c (internal compiler error)

Handle branches wrapped in UNSPEC_VOLATILE then and, for consistency,
also in UNSPEC.  The presence of UNSPEC_VOLATILE will prevent such
branches from being removed as they won't be accepted by `onlyjump_p',
we just need to let them through.

gcc/
* jump.c (pc_set): Also accept a jump wrapped in UNSPEC or
UNSPEC_VOLATILE.
(any_uncondjump_p, any_condjump_p): Update comment accordingly.
---
On Fri, 20 Nov 2020, Jeff Law wrote:

> > Handle branches wrapped in UNSPEC_VOLATILE then and, for consistency,
> > also in UNSPEC.  The presence of UNSPEC_VOLATILE will prevent such
> > branches from being removed as they won't be accepted by `onlyjump_p',
> > we just need to let them through.
> >
> > gcc/
> > * jump.c (pc_set): Also accept a jump wrapped in UNSPEC or
> > UNSPEC_VOLATILE.
> > (any_uncondjump_p, any_condjump_p): Update comment accordingly.
> I've got some concerns that there may be users of pc_set where handling
> UNSPECs would be undesirable.  For example the uses in cfgcleanup.

 I've gone through the use of `pc_set' and `any_condjump_p' in detail 
then.  Mind that I wouldn't claim expertise with this stuff, just common 
sense backed with documentation and source code available.

 It appears safe to me though, as the really dangerous cases where a jump 
is to be removed, in `thread_jump' and `outgoing_edges_match', are guarded 
with calls to `onlyjump_p' (the reference to which from the description of 
`any_condjump_p' making a promise it will guard the relevant cases is what 
made me pretty confident with my change being technically correct), which 
will reject any jumps wrapped into UNSPEC_VOLATILE or even UNSPEC (though 
arguably the latter case might be an overkill, and we could loosen that 
restriction) on the premise of failing `single_set', which only accepts a 
SET, possibly wrapped into a PARALLEL.

 Similarly with branch deletion in `cfg_layout_redirect_edge_and_branch' 
and attempted transformations using `cond_exec_get_condition'.

 Those `pc_set' calls that you mention are then only used once the 
containing code has been qualified with `onlyjump_p', so they won't be 
ever called with branches wrapped into UNSPEC_VOLATILE.  Likewise the 
`pc_set' calls in `cprop_jump' and `bypass_block'.

 The calls in `try_optimize_cfg' trying to convert a conditional branch 
into a corresponding conditional return (necessary to analyse of course 
though not relevant for the VAX; oh, how I long for the Z80) both rely on 
`redirect_jump' and possibly `invert_jump', and they're supposed to fail 
if a suitably modified original rtx cannot be matched with any RTL pattern 
(though AFAICS `redirect_exp_1' will just fail due to the lack of explicit 
UNSPEC_VOLATILE/UNSPEC support and so will `invert_jump' as it relies on 
it too).

 Except for one case the use in icvt appear safe to me: all legs except 
for ones calling into `dead_or_predicable' refer to `onlyjump_p'.  Then in 
`dead_or_predicable' we have two cases, NCE and CE.  The NCE one there is 
safe due to `can_move_insns_across' rejecting the move in the case of any 
UNSPEC_VOLATILE insn in either block.  The CE one isn't because ultimately 
it will delete the jump without validating it with `onlyjump_p' AFAICT.

 This will not affect VAX as it doesn't have conditional execution, and is 
not a fault in my change.  I think it needs fixing though, and I will post 
a patch separately, along with a minor clean-up in this area.

 In `force_nonfallthru_and_redirect' we have `gcc_assert (redirected)' and 
this may well trigger sometime.  Perhaps we need to make `redirect_jump' 
understand UNSPEC_VOLATILE/UNS

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

[Jason Merrill via Gcc-patches]

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.

gcc/testsuite/ChangeLog:

* g++.dg/parse/defarg17.C: New test.
---
 gcc/cp/parser.c   | 32 ++-
 gcc/testsuite/g++.dg/parse/defarg17.C | 11 +
 2 files changed, 37 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/parse/defarg17.C

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index a8e86cf250d..ef4d73d6161 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -5814,8 +5814,11 @@ cp_parser_primary_expression (cp_parser *parser,
if ((parser->local_variables_forbidden_p & LOCAL_VARS_FORBIDDEN)
&& local_variable_p (decl))
  {
-   error_at (id_expression.get_location (),
- "local variable %qD may not appear in this context",
+   const char *msg
+ = (TREE_CODE (decl) == PARM_DECL
+? _("parameter %qD may not appear in this context")
+: _("local variable %qD may not appear in this context"));
+   error_at (id_expression.get_location (), msg,
  decl.get_value ());
return error_mark_node;
  }
@@ -30551,7 +30554,6 @@ static void
 cp_parser_late_parsing_default_args (cp_parser *parser, tree fn)
 {
   unsigned char saved_local_variables_forbidden_p;
-  tree parm, parmdecl;
 
   /* While we're parsing the default args, we might (due to the
  statement expression extension) encounter more classes.  We want
@@ -30568,11 +30570,18 @@ cp_parser_late_parsing_default_args (cp_parser 
*parser, tree fn)
 
   begin_scope (sk_function_parms, fn);
 
-  for (parm = TYPE_ARG_TYPES (TREE_TYPE (fn)),
-parmdecl = DECL_ARGUMENTS (fn);
+  /* Gather the PARM_DECLs into a vec so we can keep track of them when
+ pushdecl clears DECL_CHAIN.  */
+  releasing_vec parms;
+  for (tree parmdecl = DECL_ARGUMENTS (fn); parmdecl;
+   parmdecl = DECL_CHAIN (parmdecl))
+vec_safe_push (parms, parmdecl);
+
+  tree parm = TYPE_ARG_TYPES (TREE_TYPE (fn));
+  for (int i = 0;
parm && parm != void_list_node;
parm = TREE_CHAIN (parm),
-parmdecl = DECL_CHAIN (parmdecl))
+++i)
 {
   tree default_arg = TREE_PURPOSE (parm);
   tree parsed_arg;
@@ -30580,6 +30589,9 @@ cp_parser_late_parsing_default_args (cp_parser *parser, 
tree fn)
   tree copy;
   unsigned ix;
 
+  tree parmdecl = parms[i];
+  pushdecl (parmdecl);
+
   if (!default_arg)
continue;
 
@@ -30602,6 +30614,14 @@ cp_parser_late_parsing_default_args (cp_parser 
*parser, tree fn)
 
   pop_bindings_and_leave_scope ();
 
+  /* Restore DECL_CHAINs after clobbering by pushdecl.  */
+  parm = NULL_TREE;
+  for (int i = parms->length () - 1; i >= 0; --i)
+{
+  DECL_CHAIN (parms[i]) = parm;
+  parm = parms[i];
+}
+
   pop_defarg_context ();
 
   /* Make sure no default arg is missing.  */
diff --git a/gcc/testsuite/g++.dg/parse/defarg17.C 
b/gcc/testsuite/g++.dg/parse/defarg17.C
new file mode 100644
index 000..c39a819c723
--- /dev/null
+++ b/gcc/testsuite/g++.dg/parse/defarg17.C
@@ -0,0 +1,11 @@
+typedef int I;
+
+int f(float I = 0.0, int b = I(2)); // { dg-error "parameter" }
+int g(int b = I(2), float I = 0.0);
+
+struct A
+{
+  int f(float I = 0.0, int b = I(2)); // { dg-error "parameter" }
+  int g(int b = I(2), float I = 0.0);
+};
+

base-commit: 54f97a226a0d8b315aa1a0129df957a8bb3fdf65
-- 
2.27.0

[pushed] c++: Fix late-parsed default arg context

[Jason Merrill via Gcc-patches]

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.

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

gcc/cp/ChangeLog:

* name-lookup.c (begin_scope): Set immediate_fn_ctx_p.
* parser.c (cp_parser_late_parsing_default_args): Push
sk_function_parms scope.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/consteval-defarg1.C: New test.
---
 gcc/cp/name-lookup.c   |  7 ++-
 gcc/cp/parser.c|  4 
 gcc/testsuite/g++.dg/cpp2a/consteval-defarg1.C | 11 +++
 3 files changed, 21 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/consteval-defarg1.C

diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
index 837c0ea89af..c87d151b441 100644
--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -3291,12 +3291,17 @@ begin_scope (scope_kind kind, tree entity)
 case sk_cond:
 case sk_class:
 case sk_scoped_enum:
-case sk_function_parms:
 case sk_transaction:
 case sk_omp:
   scope->keep = keep_next_level_flag;
   break;
 
+case sk_function_parms:
+  scope->keep = keep_next_level_flag;
+  if (entity)
+   scope->immediate_fn_ctx_p = DECL_IMMEDIATE_FUNCTION_P (entity);
+  break;
+
 case sk_namespace:
   NAMESPACE_LEVEL (entity) = scope;
   break;
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 52743b03be2..a8e86cf250d 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -30566,6 +30566,8 @@ cp_parser_late_parsing_default_args (cp_parser *parser, 
tree fn)
 
   push_defarg_context (fn);
 
+  begin_scope (sk_function_parms, fn);
+
   for (parm = TYPE_ARG_TYPES (TREE_TYPE (fn)),
 parmdecl = DECL_ARGUMENTS (fn);
parm && parm != void_list_node;
@@ -30598,6 +30600,8 @@ cp_parser_late_parsing_default_args (cp_parser *parser, 
tree fn)
TREE_PURPOSE (copy) = parsed_arg;
 }
 
+  pop_bindings_and_leave_scope ();
+
   pop_defarg_context ();
 
   /* Make sure no default arg is missing.  */
diff --git a/gcc/testsuite/g++.dg/cpp2a/consteval-defarg1.C 
b/gcc/testsuite/g++.dg/cpp2a/consteval-defarg1.C
new file mode 100644
index 000..826ee254c20
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/consteval-defarg1.C
@@ -0,0 +1,11 @@
+// Test that late-parsed default args have the same consteval semantics.
+// { dg-do compile { target c++20 } }
+
+consteval bool foo (bool x) { if (x) throw 1; return false; }
+consteval bool bar (bool x = foo (true)) { return true; }
+struct S
+{
+  consteval static bool baz (bool x = foo (true)) { return true; }
+};
+constexpr bool a = bar (true);
+constexpr bool b = S::baz (true);

base-commit: 2847d7d28ea79e2f93049fad16f931b6705c9fff
-- 
2.27.0

Re: [PATCH] c++: ICE with switch and scoped enum bit-fields [PR98043]

[Jason Merrill via Gcc-patches]

On 12/2/20 6:18 PM, Marek Polacek wrote:

In this testcase we are crashing trying to gimplify a switch, because
the types of the switch condition and case constants have different
TYPE_PRECISIONs.

This started with my r5-3726 fix: SWITCH_STMT_TYPE is supposed to be the
original type of the switch condition before any conversions, so in the
C++ FE we need to use unlowered_expr_type to get the unlowered type of
enum bit-fields.

Normally, the switch type is subject to integral promotions, but here
we have a scoped enum type and those don't promote:

   enum class B { A };
   struct C { B c : 8; };

   switch (x.c) // type B
 case B::A: // type int, will be converted to B

Here TREE_TYPE is "signed char" but SWITCH_STMT_TYPE is "B".  When
gimplifying this in gimplify_switch_expr, the index type is "B" and
we convert all the case values to "B" in preprocess_case_label_vec,
but SWITCH_COND is of type "signed char": gimple_switch_index should
be the (possibly promoted) type, not the original type, so we gimplify
the "x.c" SWITCH_COND to a SSA_NAME of type "signed char".  And then
we crash because the precision of the index type doesn't match the
precision of the case value type.

I think it makes sense to do the following; at the end of pop_switch
we've already issued the switch warnings, and since scoped enums don't
promote, it should be okay to use the type of SWITCH_STMT_COND.  The
r5-3726 change was about giving warnings for enum bit-fields anyway.

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/10?

gcc/cp/ChangeLog:

PR c++/98043
* decl.c (pop_switch): If SWITCH_STMT_TYPE is a scoped enum type,
set it to the type of SWITCH_STMT_COND.


It might make sense to do this in cp_genericize_r instead, but here is fine.


gcc/testsuite/ChangeLog:

PR c++/98043
* g++.dg/cpp0x/enum41.C: New test.
---
  gcc/cp/decl.c   | 11 ++
  gcc/testsuite/g++.dg/cpp0x/enum41.C | 32 +
  2 files changed, 43 insertions(+)
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/enum41.C

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index df76155a243..9c7d01a8c6d 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -3711,6 +3711,17 @@ pop_switch (void)
  SWITCH_STMT_ALL_CASES_P (cs->switch_stmt) = 1;
if (!cs->break_stmt_seen_p)
  SWITCH_STMT_NO_BREAK_P (cs->switch_stmt) = 1;
+  /* Now that we're done with the switch warnings, set the switch type
+ to the type of the condition if the index type was of scoped enum type.
+ (Such types don't participate in the integer promotions.)  We do this
+ because of bit-fields whose declared type is a scoped enum type:
+ gimplification will use the lowered index type, but convert the
+ case values to SWITCH_STMT_TYPE, which would have been the declared type
+ and verify_gimple_switch doesn't accept that.  */
+  if (SWITCH_STMT_TYPE (cs->switch_stmt)
+  && SCOPED_ENUM_P (SWITCH_STMT_TYPE (cs->switch_stmt)))
+SWITCH_STMT_TYPE (cs->switch_stmt)
+  = TREE_TYPE (SWITCH_STMT_COND (cs->switch_stmt));


What would be the impact of doing this for all 
is_bitfield_expr_with_lowered_type conditions, rather than all scoped 
enum conditions?



gcc_assert (!cs->in_loop_body_p);
splay_tree_delete (cs->cases);
switch_stack = switch_stack->next;
diff --git a/gcc/testsuite/g++.dg/cpp0x/enum41.C 
b/gcc/testsuite/g++.dg/cpp0x/enum41.C
new file mode 100644
index 000..5f6ef13289b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/enum41.C
@@ -0,0 +1,32 @@
+// PR c++/98043
+// { dg-do compile { target c++11 } }
+
+enum class B { A };
+struct C { B c : 8; };
+
+bool
+foo (C x)
+{
+  switch (x.c)
+{
+case B::A:
+  return false;
+default:
+  return true;
+}
+}
+
+enum E { X };
+struct D { E c : 7; };
+
+bool
+bar (D x)
+{
+  switch (x.c)
+{
+case E::X:
+  return false;
+default:
+  return true;
+}
+}

base-commit: 4ed34c60a818cc513239844f336fc781a8b47a24

Re: [PATCH] Fix division by 0 in printf_strlen_execute when dumping

[Martin Sebor via Gcc-patches]

On 12/2/20 6:06 PM, Ilya Leoshkevich via Gcc-patches wrote:

Bootstrap ang regtest running on x86_64-redhat-linux.  Ok for master?


I'd consider the fix obviously correct.

Thank you!
Martin



gcc/ChangeLog:

2020-12-03  Ilya Leoshkevich  

* tree-ssa-strlen.c (printf_strlen_execute): Avoid division by
0.
---
  gcc/tree-ssa-strlen.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/tree-ssa-strlen.c b/gcc/tree-ssa-strlen.c
index 741b47bca4a..522b2d45b3a 100644
--- a/gcc/tree-ssa-strlen.c
+++ b/gcc/tree-ssa-strlen.c
@@ -5684,7 +5684,7 @@ printf_strlen_execute (function *fun, bool warn_only)
   "  failures:  %u\n"
   "  max_depth: %u\n",
   nidxs,
-  (nused * 100) / nidxs,
+  nidxs == 0 ? 0 : (nused * 100) / nidxs,
   walker.ptr_qry.var_cache->access_refs.length (),
   walker.ptr_qry.hits, walker.ptr_qry.misses,
   walker.ptr_qry.failures, walker.ptr_qry.max_depth);

Re: [PATCH] c++: ICE with -fsanitize=vptr and constexpr dynamic_cast [PR98103]

[Jason Merrill via Gcc-patches]

On 12/2/20 6:18 PM, Marek Polacek wrote:

-fsanitize=vptr initializes all vtable pointers to null so that it can
catch invalid calls; see cp_ubsan_maybe_initialize_vtbl_ptrs.  That
means that evaluating a vtable reference can produce a null pointer
in this mode, so cxx_eval_dynamic_cast_fn should check that.


Yes, but we shouldn't accept it silently; sanitize is supposed to flag 
undefined behavior, not allow it.  If we see a null vptr, we should 
complain and set *non_constant_p.



Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?

gcc/cp/ChangeLog:

PR c++/98103
* constexpr.c (cxx_eval_dynamic_cast_fn): If the evaluating of vtable
yields a null pointer, return.

gcc/testsuite/ChangeLog:

PR c++/98103
* g++.dg/ubsan/vptr-18.C: New test.
---
  gcc/cp/constexpr.c   |  4 +++-
  gcc/testsuite/g++.dg/ubsan/vptr-18.C | 27 +++
  2 files changed, 30 insertions(+), 1 deletion(-)
  create mode 100644 gcc/testsuite/g++.dg/ubsan/vptr-18.C

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 9a1a1db1267..8c6a9cf2b40 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -1996,7 +1996,9 @@ cxx_eval_dynamic_cast_fn (const constexpr_ctx *ctx, tree 
call,
tree vtable = build_vfield_ref (obj, TREE_TYPE (obj));
vtable = cxx_eval_constant_expression (ctx, vtable, /*lval*/false,
 non_constant_p, overflow_p);
-  if (*non_constant_p)
+  /* With -fsanitize=vptr, we initialize all vtable pointers to null,
+ so it's possible that we got a null pointer now.  */
+  if (*non_constant_p || integer_zerop (vtable))
  return call;
/* VTABLE will be &_ZTV1A + 16 or similar, get _ZTV1A.  */
vtable = extract_obj_from_addr_offset (vtable);
diff --git a/gcc/testsuite/g++.dg/ubsan/vptr-18.C 
b/gcc/testsuite/g++.dg/ubsan/vptr-18.C
new file mode 100644
index 000..9f421c269bc
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ubsan/vptr-18.C
@@ -0,0 +1,27 @@
+// PR c++/98103
+// { dg-do compile { target c++20 } }
+// { dg-additional-options "-fsanitize=vptr" }
+// Modified constexpr-dynamic17.C.  -fsanitize=vptr initializes all vtable
+// pointers to null, so we don't get the "accessing uninitialized member"
+// error.
+
+struct V {
+  virtual void f();
+};
+
+struct A : V { };
+
+struct B : V {
+  constexpr B(V*, A*);
+};
+
+struct D : B, A {
+  constexpr D() : B((A*)this, this) { }
+};
+
+constexpr B::B(V* v, A* a)
+{
+  dynamic_cast(a);
+}
+
+constexpr D d;

base-commit: dc2b372ed1b1e9af6db45051cff95478c7616807

[PATCH] IBM Z: Build autovec-*-signaling-eq.c tests with exceptions

[Ilya Leoshkevich via Gcc-patches]

According to
https://gcc.gnu.org/pipermail/gcc/2020-November/234344.html, GCC is
allowed to perform optimizations that remove floating point traps,
since they do not affect the modeled control flow.  This interferes with
two signaling comparison tests, where (a <= b && a >= b) is turned into
(a <= b && a == b) by test_for_singularity, into ((a <= b) & (a == b))
by vectorizer and then into (a == b) eliminate_redundant_comparison.

Fix by making traps affect the control flow by turning them into
exceptions.

gcc/testsuite/ChangeLog:

2020-12-03  Ilya Leoshkevich  

* gcc.target/s390/zvector/autovec-double-signaling-eq.c: Build
with exceptions.
* gcc.target/s390/zvector/autovec-float-signaling-eq.c:
Likewise.
---
 .../gcc.target/s390/zvector/autovec-double-signaling-eq.c   | 2 +-
 .../gcc.target/s390/zvector/autovec-float-signaling-eq.c| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git 
a/gcc/testsuite/gcc.target/s390/zvector/autovec-double-signaling-eq.c 
b/gcc/testsuite/gcc.target/s390/zvector/autovec-double-signaling-eq.c
index a8402b9f705..3645d3cc393 100644
--- a/gcc/testsuite/gcc.target/s390/zvector/autovec-double-signaling-eq.c
+++ b/gcc/testsuite/gcc.target/s390/zvector/autovec-double-signaling-eq.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O3 -march=z14 -mzvector -mzarch" } */
+/* { dg-options "-O3 -march=z14 -mzvector -mzarch -fexceptions 
-fnon-call-exceptions" } */
 
 #include "autovec.h"
 
diff --git a/gcc/testsuite/gcc.target/s390/zvector/autovec-float-signaling-eq.c 
b/gcc/testsuite/gcc.target/s390/zvector/autovec-float-signaling-eq.c
index 7dd91a5e6f3..d98aa0c494e 100644
--- a/gcc/testsuite/gcc.target/s390/zvector/autovec-float-signaling-eq.c
+++ b/gcc/testsuite/gcc.target/s390/zvector/autovec-float-signaling-eq.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O3 -march=z14 -mzvector -mzarch" } */
+/* { dg-options "-O3 -march=z14 -mzvector -mzarch -fexceptions 
-fnon-call-exceptions" } */
 
 #include "autovec.h"
 
-- 
2.25.4

Re: [committed] Fix mcore multilib specification

[Jim Wilson]

On Tue, Dec 1, 2020 at 3:24 PM Jeff Law via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:

>
> Kito's recent change to multilib handling seems to have exposed a latent
> mcore bug.
>
> The mcore 210 does not support little endian.  Yet we try to build a
> mcore-210 little-endian multilibs.
>
> I don't know why this wasn't failing before, but clearly it's not
> supposed to work.  This patch adjusts the multilib set to not generate
> that particular library configuration.  The net result is mcore's libgcc
> builds again, as does newlib.
>

You have two default args in MULTILIB_DEFAULTS and that was never supported
by the print_multilib_info function.  It only handled one default arg
correctly.  It must have been working by accident before Kito fixed it.
But since we know what the underlying problem is, we can check for targets
with more than one option in MULTILIB_DEFAULTS.  Looks like targets that
might be affected are csky, m32r, mcore, mips, nds32, riscv, rs6000/sysv*,
and sh.  We know that riscv works correctly as we checked that.  And you
just fixed mcore.  We should probably check the others.  They may or may
not be OK with Kito's patch.

Jim

[PATCH] Fix division by 0 in printf_strlen_execute when dumping

[Ilya Leoshkevich via Gcc-patches]

Bootstrap ang regtest running on x86_64-redhat-linux.  Ok for master?

gcc/ChangeLog:

2020-12-03  Ilya Leoshkevich  

* tree-ssa-strlen.c (printf_strlen_execute): Avoid division by
0.
---
 gcc/tree-ssa-strlen.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/tree-ssa-strlen.c b/gcc/tree-ssa-strlen.c
index 741b47bca4a..522b2d45b3a 100644
--- a/gcc/tree-ssa-strlen.c
+++ b/gcc/tree-ssa-strlen.c
@@ -5684,7 +5684,7 @@ printf_strlen_execute (function *fun, bool warn_only)
   "  failures:  %u\n"
   "  max_depth: %u\n",
   nidxs,
-  (nused * 100) / nidxs,
+  nidxs == 0 ? 0 : (nused * 100) / nidxs,
   walker.ptr_qry.var_cache->access_refs.length (),
   walker.ptr_qry.hits, walker.ptr_qry.misses,
   walker.ptr_qry.failures, walker.ptr_qry.max_depth);
-- 
2.25.4

Re: [PATCH] RISC-V: Canonicalize --with-arch

[Jim Wilson]

On Tue, Dec 1, 2020 at 12:13 AM Kito Cheng  wrote:

>  - We would like to canonicalize the arch string for --with-arch for
>easier handling multilib, so split canonicalization part to a stand
>along script to shared the logic.
>
> gcc/ChangeLog:
>
> * config/riscv/multilib-generator (arch_canonicalize): Move
> code to arch-canonicalize, and call that script to canonicalize
> arch
> string.
> (canonical_order): Move code to arch-canonicalize.
> (LONG_EXT_PREFIXES): Ditto.
> (IMPLIED_EXT): Ditto.
> * config/riscv/arch-canonicalize: New.
> * config.gcc (riscv*-*-*): Canonicalize --with-arch.
>

Looks OK to me.

Jim

Re: [committed] adjust expected warnings to reflect max-object-size

[Martin Sebor via Gcc-patches]

On 12/2/20 1:31 PM, Jeff Law wrote:



On 12/2/20 11:43 AM, Martin Sebor wrote:

The r11-5622 change to -Wformat-overflow switched the warning
to using the maximm object size limit used by the other overflow
and out of bounds access warnings like -Wstringop-overflow.
That in turn exposed a subtle off-by-one mistake in the former
that was also reflected in a few tests, seen in ILP32 but not
in LP64.  I just committed the attached patch adjusts the tests
to correctly reflect the limit.  These mistakes would be easier
to avoid if if were possible to lower the max object size limit
from PTRDIFF_MAX - 1 to a value that's independent of the target
as in the following patch:

https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559450.html

Martin

gcc-sprintf-max-objsize.diff

commit 0a7dc4b6440faa8cd57c630f1e394a719469c399
Author: Martin Sebor 
Date:   Wed Dec 2 11:29:11 2020 -0700

 Adjust test to avoid ILP32 failures after r11-5622 (PR middle-end/97373)
 
 gcc/testsuite/ChangeLog:

 * gcc.dg/tree-ssa/builtin-sprintf-warn-1.c: Adjust expected 
warnings
 to correctly reflect the maximum object size.
 * gcc.dg/tree-ssa/builtin-sprintf-warn-11.c: Same.
 * gcc.dg/tree-ssa/builtin-sprintf-warn-18.c: Same.

Still seeing regressions.  mcore-elf for example:


I didn't fully revert the max-object-size patch from my tree when
I tested the changes so the fixes I made to the tests were based
on the fixes for the one-off bugs the parameter exposed in
the warning code.  I've tweaked the tests to undo the changes with
the dependencies on the fixes.  I tested them on x86_64 with both
-m32 and -m64, as well as with mcore-elf and or1k-elf crosses.
builtin-sprintf-warn-18.c is unsupported because it needs iconv
but the other two pass so hopefully this is the last iteration.

Martin



Tests that now fail, but worked before (4 tests):

moxie-sim: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for excess errors)
moxie-sim: gcc.dg/tree-ssa/builtin-sprintf-warn-11.c (test for excess
errors)

And in the log file:
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for excess errors)
Excess errors:
/home/jenkins/gcc/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c:119:3:
warning: '__builtin_sprintf' writing a terminating nul past the end of
the destination [-Wformat-overflow=]
/home/jenkins/gcc/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c:121:3:
warning: '__builtin_sprintf' writing a terminating nul past the end of
the destination [-Wformat-overflow=]
/home/jenkins/gcc/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c:122:3:
warning: '%*c' directive writing 2147483647 bytes into a region of size
2147483646 [-Wformat-overflow=]
/home/jenkins/gcc/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c:125:3:
warning: '%*c' directive writing 2147483646 bytes into a region of size
1 [-Wformat-overflow=]
/home/jenkins/gcc/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c:130:3:
warning: '__builtin_sprintf' writing a terminating nul past the end of
the destination [-Wformat-overflow=]
/home/jenkins/gcc/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c:131:3:
warning: 'X' directive writing 1 byte into a region of size 0
[-Wformat-overflow=]
/home/jenkins/gcc/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c:299:3:
warning: '__builtin_sprintf' writing a terminating nul past the end of
the destination [-Wformat-overflow=]
/home/jenkins/gcc/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c:300:3:
warning: '%*s' directive writing 2147483647 bytes into a region of size
2147483646 [-Wformat-overflow=]

And:
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-11.c (test for excess errors)
Excess errors:
/home/jenkins/gcc/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-11.c:207:3:
warning: '__builtin_sprintf' writing a terminating nul past the end of
the destination [-Wformat-overflow=]
/home/jenkins/gcc/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-11.c:215:3:
warning: '%*.*s' directive writing between 5 and 6 bytes into a region
of size between 2 and 4 [-Wformat-overflow=]



Again, I think you can look at these with a simple cross compiler.  I
don't think you need cross-binutils, newlib, etc.

jeff

Re: [PATCH] c++: Treat OPAQUE_TYPE types as an aggregate type [PR97947]

[Peter Bergner via Gcc-patches]

On 12/2/20 2:37 PM, Jason Merrill wrote:
> But this patch is OK.

Ok, pushed to trunk.  Thanks!

Peter

Re: [PATCH] c++: Treat OPAQUE_TYPE types as an aggregate type [PR97947]

[Peter Bergner via Gcc-patches]

On 12/2/20 2:36 PM, Jakub Jelinek wrote:
> Just a random question, do you have some testsuite coverage for constant
> expression evaluation (primarily C++) with the opaque types, do you verify
> any object with that type is treated as something that may not appear in
> constant expression and does constexpr.c properly punt on it rather than
> ICE?

We don't, since we don't support that with these specific types, but yeah,
an ICE isn't as good as an error message.  We'll look into adding some.  
Thanks.

Peter

[PATCH] c++: ICE with -fsanitize=vptr and constexpr dynamic_cast [PR98103]

[Marek Polacek via Gcc-patches]

-fsanitize=vptr initializes all vtable pointers to null so that it can
catch invalid calls; see cp_ubsan_maybe_initialize_vtbl_ptrs.  That
means that evaluating a vtable reference can produce a null pointer
in this mode, so cxx_eval_dynamic_cast_fn should check that.

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?

gcc/cp/ChangeLog:

PR c++/98103
* constexpr.c (cxx_eval_dynamic_cast_fn): If the evaluating of vtable
yields a null pointer, return.

gcc/testsuite/ChangeLog:

PR c++/98103
* g++.dg/ubsan/vptr-18.C: New test.
---
 gcc/cp/constexpr.c   |  4 +++-
 gcc/testsuite/g++.dg/ubsan/vptr-18.C | 27 +++
 2 files changed, 30 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/ubsan/vptr-18.C

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 9a1a1db1267..8c6a9cf2b40 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -1996,7 +1996,9 @@ cxx_eval_dynamic_cast_fn (const constexpr_ctx *ctx, tree 
call,
   tree vtable = build_vfield_ref (obj, TREE_TYPE (obj));
   vtable = cxx_eval_constant_expression (ctx, vtable, /*lval*/false,
 non_constant_p, overflow_p);
-  if (*non_constant_p)
+  /* With -fsanitize=vptr, we initialize all vtable pointers to null,
+ so it's possible that we got a null pointer now.  */
+  if (*non_constant_p || integer_zerop (vtable))
 return call;
   /* VTABLE will be &_ZTV1A + 16 or similar, get _ZTV1A.  */
   vtable = extract_obj_from_addr_offset (vtable);
diff --git a/gcc/testsuite/g++.dg/ubsan/vptr-18.C 
b/gcc/testsuite/g++.dg/ubsan/vptr-18.C
new file mode 100644
index 000..9f421c269bc
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ubsan/vptr-18.C
@@ -0,0 +1,27 @@
+// PR c++/98103
+// { dg-do compile { target c++20 } }
+// { dg-additional-options "-fsanitize=vptr" }
+// Modified constexpr-dynamic17.C.  -fsanitize=vptr initializes all vtable
+// pointers to null, so we don't get the "accessing uninitialized member"
+// error.
+
+struct V {
+  virtual void f();
+};
+
+struct A : V { };
+
+struct B : V {
+  constexpr B(V*, A*);
+};
+
+struct D : B, A {
+  constexpr D() : B((A*)this, this) { }
+};
+
+constexpr B::B(V* v, A* a)
+{
+  dynamic_cast(a);
+}
+
+constexpr D d;

base-commit: dc2b372ed1b1e9af6db45051cff95478c7616807
-- 
2.28.0

[PATCH] c++: ICE with switch and scoped enum bit-fields [PR98043]

[Marek Polacek via Gcc-patches]

In this testcase we are crashing trying to gimplify a switch, because
the types of the switch condition and case constants have different
TYPE_PRECISIONs.

This started with my r5-3726 fix: SWITCH_STMT_TYPE is supposed to be the
original type of the switch condition before any conversions, so in the
C++ FE we need to use unlowered_expr_type to get the unlowered type of
enum bit-fields.

Normally, the switch type is subject to integral promotions, but here
we have a scoped enum type and those don't promote:

  enum class B { A };
  struct C { B c : 8; };

  switch (x.c) // type B
case B::A: // type int, will be converted to B

Here TREE_TYPE is "signed char" but SWITCH_STMT_TYPE is "B".  When
gimplifying this in gimplify_switch_expr, the index type is "B" and
we convert all the case values to "B" in preprocess_case_label_vec,
but SWITCH_COND is of type "signed char": gimple_switch_index should
be the (possibly promoted) type, not the original type, so we gimplify
the "x.c" SWITCH_COND to a SSA_NAME of type "signed char".  And then
we crash because the precision of the index type doesn't match the
precision of the case value type.

I think it makes sense to do the following; at the end of pop_switch
we've already issued the switch warnings, and since scoped enums don't
promote, it should be okay to use the type of SWITCH_STMT_COND.  The
r5-3726 change was about giving warnings for enum bit-fields anyway.

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/10?

gcc/cp/ChangeLog:

PR c++/98043
* decl.c (pop_switch): If SWITCH_STMT_TYPE is a scoped enum type,
set it to the type of SWITCH_STMT_COND.

gcc/testsuite/ChangeLog:

PR c++/98043
* g++.dg/cpp0x/enum41.C: New test.
---
 gcc/cp/decl.c   | 11 ++
 gcc/testsuite/g++.dg/cpp0x/enum41.C | 32 +
 2 files changed, 43 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/enum41.C

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index df76155a243..9c7d01a8c6d 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -3711,6 +3711,17 @@ pop_switch (void)
 SWITCH_STMT_ALL_CASES_P (cs->switch_stmt) = 1;
   if (!cs->break_stmt_seen_p)
 SWITCH_STMT_NO_BREAK_P (cs->switch_stmt) = 1;
+  /* Now that we're done with the switch warnings, set the switch type
+ to the type of the condition if the index type was of scoped enum type.
+ (Such types don't participate in the integer promotions.)  We do this
+ because of bit-fields whose declared type is a scoped enum type:
+ gimplification will use the lowered index type, but convert the
+ case values to SWITCH_STMT_TYPE, which would have been the declared type
+ and verify_gimple_switch doesn't accept that.  */
+  if (SWITCH_STMT_TYPE (cs->switch_stmt)
+  && SCOPED_ENUM_P (SWITCH_STMT_TYPE (cs->switch_stmt)))
+SWITCH_STMT_TYPE (cs->switch_stmt)
+  = TREE_TYPE (SWITCH_STMT_COND (cs->switch_stmt));
   gcc_assert (!cs->in_loop_body_p);
   splay_tree_delete (cs->cases);
   switch_stack = switch_stack->next;
diff --git a/gcc/testsuite/g++.dg/cpp0x/enum41.C 
b/gcc/testsuite/g++.dg/cpp0x/enum41.C
new file mode 100644
index 000..5f6ef13289b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/enum41.C
@@ -0,0 +1,32 @@
+// PR c++/98043
+// { dg-do compile { target c++11 } }
+
+enum class B { A };
+struct C { B c : 8; };
+
+bool
+foo (C x)
+{
+  switch (x.c)
+{
+case B::A:
+  return false;
+default:
+  return true;
+}
+}
+
+enum E { X };
+struct D { E c : 7; };
+
+bool
+bar (D x)
+{
+  switch (x.c)
+{
+case E::X:
+  return false;
+default:
+  return true;
+}
+}

base-commit: 4ed34c60a818cc513239844f336fc781a8b47a24
-- 
2.28.0

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.

In all the excitement, i've lost track of some of the details throughout the 
thread.  :-) 


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

This is at least now V3.


Given the number of changes, May be worth re-posting as a a clean [v3] version, 
etc..

> 
> 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.


Would be useful to include the patch descriptionm as a standalone paragraph 
here.  

I believe the first email in the thread contained this:

> GCC maintainers:
> 
> The following patch adds new builtins for the vector integer multiply,
> divide and modulo operations.  The builtins are:  
> vec_mulh(), vec_div(), vec_dive(), vec_mod() for signed and unsigned
> integers and long long integers.  Support for signed and unsigned long
> long integers the exiting vec_mul() is added.  Note that the existing
> support for the vec_div()and vec_mul() builtins emulate the vector
> operations with multiple scalar instructions.  This patch adds support
> for these builtins to use the new vector instructions.
> 

I don't see an updated in-between version. 
Nit: ".. exiting vec_mul() is added" doesn't read quite right.
First and last sentences there can probably be combined.





> 
> 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 
> 
> ---
> 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):
>   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.
>   (UNSPEC_VDIVES, UNSPEC_VDIVEU): Add enum for UNSPECs.
>   (vsx_mul_v2di, vsx_udiv_v2di): Add if TARGET_POWER10 statement.
>   (dives_, dive

[r11-5674 Regression] FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c lp32 (test for warnings, line 122) on Linux/x86_64

[sunil.k.pandey via Gcc-patches]

On Linux/x86_64,

0a7dc4b6440faa8cd57c630f1e394a719469c399 is the first bad commit
commit 0a7dc4b6440faa8cd57c630f1e394a719469c399
Author: Martin Sebor 
Date:   Wed Dec 2 11:29:11 2020 -0700

Adjust test to avoid ILP32 failures after r11-5622 (PR middle-end/97373)

caused

FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-11.c ilp32 (test for warnings, line 
207)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-11.c ilp32 (test for warnings, line 
215)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-11.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c il32 (test for warnings, line 
119)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c ilp32 (test for warnings, line 
118)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c ilp32 (test for warnings, line 
121)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c ilp32 (test for warnings, line 
125)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c ilp32 (test for warnings, line 
129)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c ilp32 (test for warnings, line 
130)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c ilp32 (test for warnings, line 
131)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c ilp32 (test for warnings, line 
298)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c ilp32 (test for warnings, line 
299)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c ilp32 (test for warnings, line 
300)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c lp32 (test for warnings, line 
122)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for excess errors)

with GCC configured with

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

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="tree-ssa.exp=gcc.dg/tree-ssa/builtin-sprintf-warn-11.c 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="tree-ssa.exp=gcc.dg/tree-ssa/builtin-sprintf-warn-11.c 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="tree-ssa.exp=gcc.dg/tree-ssa/builtin-sprintf-warn-1.c 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="tree-ssa.exp=gcc.dg/tree-ssa/builtin-sprintf-warn-1.c 
--target_board='unix{-m32\ -march=cascadelake}'"

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

Re: [PATCH] rs6000: Use subreg for QI/HI vector init

[will schmidt via Gcc-patches]

On Wed, 2020-12-02 at 17:44 +0800, Kewen.Lin via Gcc-patches wrote:
> Hi,
> 
> This patch is to use paradoxical subreg instead of
> zero_extend for promoting QI/HI to SI/DI when we
> want to construct one vector with these modes.
> Since we do the gpr->vsx movement and vector merge
> or pack later, the high part is useless and safe to
> use paradoxical subreg.  It can avoid useless rlwinms
> generated for signed cases.
> 
> Bootstrapped/regtested on powerpc64le-linux-gnu P9.
> 
> Is it ok for trunk?

Mostly cosmetic review.  comments sprinkled below.
thanks
-Will

> 
> BR,
> Kewen
> --
> gcc/ChangeLog:
> 
>   * config/rs6000/rs6000.c (rs6000_expand_vector_init): Use
>   paradoxical subreg instead of zero_extend for QI/HI promotion
>   when doing QI/HI vector init.

A bit long, but OK with me. :-)

> 
> gcc/testsuite/ChangeLog:
> 
>   * gcc.target/powerpc/pr96933-1.c: Adjusted to check no rlwinm.
>   * gcc.target/powerpc/pr96933-2.c: Likewise.

Ok.  (I'd hope a few more extend instructions would be eliminated, but
this only covers the tests that explicitly looked/didn't look for them, so OK).



> diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
> index f33fca3982a..9c084b055b8 100644
> --- a/gcc/config/rs6000/rs6000.c
> +++ b/gcc/config/rs6000/rs6000.c
> @@ -6793,17 +6793,8 @@ rs6000_expand_vector_init (rtx target, rtx vals)

I note that the code changes that follow here are within the code block 

  if (TARGET_DIRECT_MOVE && (mode == V16QImode || mode == V8HImode))
{

This is implied per the patch description, but not obvious from the context of 
the changes here.   (OK).


>/* Force the values into word_mode registers.  */
>for (i = 0; i < n_elts; i++)
> {
> - rtx tmp = force_reg (GET_MODE_INNER (mode), XVECEXP (vals, 0, i));
> - if (TARGET_POWERPC64)
> -   {
> - op[i] = gen_reg_rtx (DImode);
> - emit_insn (gen_zero_extendqidi2 (op[i], tmp));
> -   }
> - else
> -   {
> - op[i] = gen_reg_rtx (SImode);
> - emit_insn (gen_zero_extendqisi2 (op[i], tmp));
> -   }
> + rtx tmp = force_reg (inner_mode, XVECEXP (vals, 0, i));
> + op[i] = simplify_gen_subreg (Pmode, tmp, inner_mode, 0);
> }
> 
>/* Take unsigned char big endianness on 64bit as example for below
> diff --git a/gcc/testsuite/gcc.target/powerpc/pr96933-1.c 
> b/gcc/testsuite/gcc.target/powerpc/pr96933-1.c
> index 3b63865b3b8..71d72084413 100644
> --- a/gcc/testsuite/gcc.target/powerpc/pr96933-1.c
> +++ b/gcc/testsuite/gcc.target/powerpc/pr96933-1.c
> @@ -13,3 +13,4 @@
>  /* { dg-final { scan-assembler-times {\mvpkudum\M} 12 } } */
>  /* { dg-final { scan-assembler-not {\mstb\M} } } */
>  /* { dg-final { scan-assembler-not {\msth\M} } } */
> +/* { dg-final { scan-assembler-not {\mrlwinm\M} } } */
> diff --git a/gcc/testsuite/gcc.target/powerpc/pr96933-2.c 
> b/gcc/testsuite/gcc.target/powerpc/pr96933-2.c
> index cef8fbd4f35..9fa15125d8d 100644
> --- a/gcc/testsuite/gcc.target/powerpc/pr96933-2.c
> +++ b/gcc/testsuite/gcc.target/powerpc/pr96933-2.c
> @@ -13,3 +13,4 @@
>  /* { dg-final { scan-assembler-times {\mxxpermdi\M} 4 } } */
>  /* { dg-final { scan-assembler-not {\mstb\M} } } */
>  /* { dg-final { scan-assembler-not {\msth\M} } } */
> +/* { dg-final { scan-assembler-not {\mrlwinm\M} } } */

Ok.
Thanks
-Will

Re: V3 [PATCH] Use SHF_GNU_RETAIN to preserve symbol definitions

[Joseph Myers]

On Wed, 2 Dec 2020, H.J. Lu via Gcc-patches wrote:

> > Not sure if this is a GCC bug or indicates that glibc's libc_freeres_fn or
> > related macros need to change to work with both old and new GCC.
> 
> We may need to update glibc for GCC 11.  Can you open a glibc bug and
> CC me?

https://sourceware.org/bugzilla/show_bug.cgi?id=27002

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

Re: V3 [PATCH] Use SHF_GNU_RETAIN to preserve symbol definitions

[H.J. Lu via Gcc-patches]

On Wed, Dec 2, 2020 at 1:31 PM Joseph Myers  wrote:
>
> This patch (GCC commit 6fbec038f7a7ddf29f074943611b53210d17c40c) has
> broken the glibc build (at least with current binutils master).  The
> errors are of the form:
>
> In file included from :
> gconv_dl.c: In function 'free_mem':
> gconv_dl.c:202:18: error: 'free_mem' causes a section type conflict with 
> 'do_release_all'
>   202 | libc_freeres_fn (free_mem)
>   |  ^~~~
> ./../include/libc-symbols.h:316:15: note: in definition of macro 
> 'libc_freeres_fn'
>   316 |   static void name (void)
>   |   ^~~~
> gconv_dl.c:191:1: note: 'do_release_all' was declared here
>   191 | do_release_all (void *nodep)
>   | ^~
>
> Not sure if this is a GCC bug or indicates that glibc's libc_freeres_fn or
> related macros need to change to work with both old and new GCC.

We may need to update glibc for GCC 11.  Can you open a glibc bug and
CC me?

Thanks.

-- 
H.J.

Re: [PATCH] c++: Change __builtin_source_location to use __PRETTY_FUNCTION__ instead of __FUNCTION__ [PR80780]

[Jonathan Wakely via Gcc-patches]

On 02/12/20 15:18 -0500, Jason Merrill wrote:

On 12/2/20 7:30 AM, Jakub Jelinek wrote:

Hi!

On Tue, Dec 01, 2020 at 01:03:52PM +, Jonathan Wakely via Gcc-patches wrote:

I mentioned in PR 80780 that a __builtin__PRETTY_FUNCTION would have
been nice, because __FUNCTION__ isn't very useful for C++, because of
overloading and namespace/class scopes. There are an unlimited number
of functions that have __FUNCTION__ == "s", e.g. "ns::s(int)" and
"ns::s()" and "another_scope::s::s(T...)" etc.

Since __builtin_source_location() can do whatever it wants (without
needing to add __builtin__PRETTY_FUNCTION) it might be nice to use the
__PRETTY_FUNCTION__ string. JeanHeyd's tests would still need changes,
because the name would be "s::s(void*)" not "s::s" but that still
seems better for users.


When I've added template tests for the previous patch, I have noticed that
the current __builtin_source_location behavior is not really __FUNCTION__,
just close, because e.g. in function template __FUNCTION__ is still
"bar" but __builtin_source_location gave "bar<0>".

Anyway, this patch implements above request to follow __PRETTY_FUNCTION__
(on top of the earlier posted patch).

Tested on x86_64-linux, ok for trunk if it passes full bootstrap/regtest on
x86_64-linux?


OK on Friday unless Jonathan objects.


I'll try to test it tomorrow, but I'm definitely in favour of the
change to PRETTY_FUNCTION.

[committed] libstdc++: Fix std::any pretty printer [PR 68735]

[Jonathan Wakely via Gcc-patches]

This fixes errors seen on powerpc64 (big endian only) due to the
printers for std::any and std::experimental::any being unable to find
the manager function.

libstdc++-v3/ChangeLog:

PR libstdc++/65480
PR libstdc++/68735
* python/libstdcxx/v6/printers.py (function_pointer_to_name):
New helper function to get the name of a function from its
address.
(StdExpAnyPrinter.__init__): Use it.

Tested powerpc64-linux, powerpc64le-linux and x86_64-linux.

Committed to trunk.

commit dc2b372ed1b1e9af6db45051cff95478c7616807
Author: Jonathan Wakely 
Date:   Wed Dec 2 21:39:08 2020

libstdc++: Fix std::any pretty printer [PR 68735]

This fixes errors seen on powerpc64 (big endian only) due to the
printers for std::any and std::experimental::any being unable to find
the manager function.

libstdc++-v3/ChangeLog:

PR libstdc++/65480
PR libstdc++/68735
* python/libstdcxx/v6/printers.py (function_pointer_to_name):
New helper function to get the name of a function from its
address.
(StdExpAnyPrinter.__init__): Use it.

diff --git a/libstdc++-v3/python/libstdcxx/v6/printers.py 
b/libstdc++-v3/python/libstdcxx/v6/printers.py
index 4176f739004..9c6393712a0 100644
--- a/libstdc++-v3/python/libstdcxx/v6/printers.py
+++ b/libstdc++-v3/python/libstdcxx/v6/printers.py
@@ -1126,6 +1126,29 @@ class SingleObjContainerPrinter(object):
 return self.visualizer.display_hint ()
 return self.hint
 
+def function_pointer_to_name(f):
+"Find the name of the function referred to by the gdb.Value f, "
+" which should contain a function pointer from the program."
+
+# Turn the function pointer into an actual address.
+# This is needed to unpack ppc64 function descriptors.
+f = f.dereference().address
+
+if sys.version_info[0] == 2:
+# Older versions of GDB need to use long for Python 2,
+# because int(f) on 64-bit big-endian values raises a
+# gdb.error saying "Cannot convert value to int."
+f = long(f)
+else:
+f = int(f)
+
+try:
+# If the function can't be found older versions of GDB raise a
+# RuntimeError saying "Cannot locate object file for block."
+return gdb.block_for_pc(f).function.name
+except:
+return None
+
 class StdExpAnyPrinter(SingleObjContainerPrinter):
 "Print a std::any or std::experimental::any"
 
@@ -1138,11 +1161,11 @@ class StdExpAnyPrinter(SingleObjContainerPrinter):
 visualizer = None
 mgr = self.val['_M_manager']
 if mgr != 0:
-func = gdb.block_for_pc(int(mgr.cast(gdb.lookup_type('intptr_t'
+func = function_pointer_to_name(mgr)
 if not func:
-raise ValueError("Invalid function pointer in %s" % 
self.typename)
+raise ValueError("Invalid function pointer in %s" % 
(self.typename))
 rx = r"""({0}::_Manager_\w+<.*>)::_S_manage\((enum )?{0}::_Op, 
(const {0}|{0} const) ?\*, (union )?{0}::_Arg ?\*\)""".format(typename)
-m = re.match(rx, func.function.name)
+m = re.match(rx, func)
 if not m:
 raise ValueError("Unknown manager function in %s" % 
self.typename)
 

Re: V3 [PATCH] Use SHF_GNU_RETAIN to preserve symbol definitions

[Joseph Myers]

This patch (GCC commit 6fbec038f7a7ddf29f074943611b53210d17c40c) has 
broken the glibc build (at least with current binutils master).  The 
errors are of the form:

In file included from :
gconv_dl.c: In function 'free_mem':
gconv_dl.c:202:18: error: 'free_mem' causes a section type conflict with 
'do_release_all'
  202 | libc_freeres_fn (free_mem)
  |  ^~~~
./../include/libc-symbols.h:316:15: note: in definition of macro 
'libc_freeres_fn'
  316 |   static void name (void)
  |   ^~~~
gconv_dl.c:191:1: note: 'do_release_all' was declared here
  191 | do_release_all (void *nodep)
  | ^~

Not sure if this is a GCC bug or indicates that glibc's libc_freeres_fn or 
related macros need to change to work with both old and new GCC.

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

Re: [PATCH] Remove misleading debug line entries

[Bernd Edlinger]

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?


Thanks
Bernd.

> Thanks,
> Richard.
> 
>>
>> Thanks
>> Bernd.
>>
> 
From 1f97917fcbb15f7277dc9d6030dca05beab825c7 Mon Sep 17 00:00:00 2001
From: Bernd Edlinger 
Date: Wed, 2 Dec 2020 12:32:02 +0100
Subject: [PATCH] Remove misleading debug line entries

This removes gimple_debug_begin_stmts without block info which remain
after a gimple block originating from an inline function is unused.

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-12-02  Bernd Edlinger  

	* cfgexpand.c (expand_gimple_basic_block): Remove special handling
	of debug_inline_entries without block info.
	* tree-inline.c (remap_gimple_stmt): Drop debug_nonbind_markers when
	the call statement has no block info.
	* tree-ssa-live.c (clear_unused_block_pointer): Remove
	debug_nonbind_markers originating from inlined functions.
---
 gcc/cfgexpand.c |  9 +
 gcc/tree-inline.c   |  3 ++-
 gcc/tree-ssa-live.c | 16 ++--
 3 files changed, 17 insertions(+), 11 deletions(-)

diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c
index 1df6f4b..2ef8298 100644
--- a/gcc/cfgexpand.c
+++ b/gcc/cfgexpand.c
@@ -5831,14 +5831,7 @@ expand_gimple_basic_block (basic_block bb, bool disable_tail_calls)
 	  else if (gimple_debug_begin_stmt_p (stmt))
 		val = GEN_RTX_DEBUG_MARKER_BEGIN_STMT_PAT ();
 	  else if (gimple_debug_inline_entry_p (stmt))
-		{
-		  tree block = gimple_block (stmt);
-
-		  if (block)
-		val = GEN_RTX_DEBUG_MARKER_INLINE_ENTRY_PAT ();
-		  else
-		goto delink_debug_stmt;
-		}
+		val = GEN_RTX_DEBUG_MARKER_INLINE_ENTRY_PAT ();
 	  else
 		gcc_unreachable ();
 
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;
 
 	  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))
+	  {
+		gsi_remove (&gsi, true);
+		if (gsi_end_p (gsi))
+		  break;
+		goto next;
+	  }
+	gimple_set_block (stmt, NULL);
+	  }
 	for (i = 0; i < gimple_num_ops (stmt); i++)
 	  walk

[r11-5663 Regression] FAIL: g++.dg/template/canon-type-4.C -std=c++17 (test for excess errors) on Linux/x86_64

[sunil.k.pandey via Gcc-patches]

On Linux/x86_64,

329ae1d7751346ba166d34e77a43e8cc33daa1c9 is the first bad commit
commit 329ae1d7751346ba166d34e77a43e8cc33daa1c9
Author: Nathan Sidwell 
Date:   Wed Dec 2 07:35:23 2020 -0800

c++: Extend build_array_type API

caused

FAIL: g++.dg/template/canon-type-4.C  -std=c++17 (internal compiler error)
FAIL: g++.dg/template/canon-type-4.C  -std=c++17 (test for excess errors)

with GCC configured with

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

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="dg.exp=g++.dg/template/canon-type-4.C --target_board='unix{-m64\ 
-march=cascadelake}'"

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

[pushed] c++: Give better placeholder diagnostic

[Jason Merrill via Gcc-patches]

We were saying 'auto parameter not permitted' in a place where 'auto' is in
fact permitted in C++20, but a class template placeholder is not.

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

gcc/cp/ChangeLog:

* decl.c (grokdeclarator): Improve diagnostic for
disallowed CTAD placeholder.

gcc/testsuite/ChangeLog:

* g++.dg/other/pr88187.C: Adjust expected error.
* g++.dg/cpp2a/class-deduction-abbrev1.C: New test.
---
 gcc/cp/decl.c   | 10 ++
 .../g++.dg/cpp2a/class-deduction-abbrev1.C  | 13 +
 gcc/testsuite/g++.dg/other/pr88187.C|  2 +-
 3 files changed, 24 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/class-deduction-abbrev1.C

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 1e2bae4afba..0cf84a0750c 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -13145,6 +13145,16 @@ grokdeclarator (const cp_declarator *declarator,
  if (decl_context == PARM && AUTO_IS_DECLTYPE (auto_node))
error_at (typespec_loc,
  "cannot declare a parameter with %");
+ else if (tree c = CLASS_PLACEHOLDER_TEMPLATE (auto_node))
+   {
+ auto_diagnostic_group g;
+ error_at (typespec_loc,
+   "class template placeholder %qE not permitted "
+   "in this context", c);
+ if (decl_context == PARM && cxx_dialect >= cxx20)
+   inform (typespec_loc, "use % for an "
+   "abbreviated function template");
+   }
  else
error_at (typespec_loc,
  "% parameter not permitted in this context");
diff --git a/gcc/testsuite/g++.dg/cpp2a/class-deduction-abbrev1.C 
b/gcc/testsuite/g++.dg/cpp2a/class-deduction-abbrev1.C
new file mode 100644
index 000..f9310090b5b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/class-deduction-abbrev1.C
@@ -0,0 +1,13 @@
+ // { dg-do compile { target c++20 } }
+
+template  struct A { };
+template  concept is_A = requires { A(T()); };
+
+void f(auto);  // OK
+void f(is_A auto); // OK
+void f(A);// { dg-error "placeholder" }
+
+int main()
+{
+  f(A());
+}
diff --git a/gcc/testsuite/g++.dg/other/pr88187.C 
b/gcc/testsuite/g++.dg/other/pr88187.C
index ebdafddc634..13466d3ce57 100644
--- a/gcc/testsuite/g++.dg/other/pr88187.C
+++ b/gcc/testsuite/g++.dg/other/pr88187.C
@@ -4,4 +4,4 @@
 template  struct A;
 void f (A ()); // { dg-error "6:variable or field 'f' declared void" "" { 
target c++14_down } }
// { dg-error "missing template arguments before '\\(' token" 
"" { target c++14_down } .-1 }
-   // { dg-error "'auto' parameter not permitted in this context" 
"" { target c++17 } .-2 }
+   // { dg-error "placeholder .A. not permitted in this context" 
"" { target c++17 } .-2 }

base-commit: d9288bd28e24c755a7216311ee5247e7c88270a6
-- 
2.27.0

[pushed] c++: Improve init handling

[Jason Merrill via Gcc-patches]

While looking at another issue I noticed that in a template we were failing
to find the INIT_EXPR we were looking for, and so ended up doing redundant
processing.  No testcase, as the redundant processing ended up getting the
right result.

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

gcc/cp/ChangeLog:

* decl.c (check_initializer): Also look through STMT_EXPR
and BIND_EXPR.
---
 gcc/cp/decl.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index df76155a243..1e2bae4afba 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -6892,9 +6892,17 @@ check_initializer (tree decl, tree init, int flags, 
vec **cleanups)
 have returned an INIT_EXPR rather than a CALL_EXPR.  In that
 case, pull the initializer back out and pass it down into
 store_init_value.  */
- while (TREE_CODE (init_code) == EXPR_STMT
-|| TREE_CODE (init_code) == CONVERT_EXPR)
-   init_code = TREE_OPERAND (init_code, 0);
+ while (true)
+   {
+ if (TREE_CODE (init_code) == EXPR_STMT
+ || TREE_CODE (init_code) == STMT_EXPR
+ || TREE_CODE (init_code) == CONVERT_EXPR)
+   init_code = TREE_OPERAND (init_code, 0);
+ else if (TREE_CODE (init_code) == BIND_EXPR)
+   init_code = BIND_EXPR_BODY (init_code);
+ else
+   break;
+   }
  if (TREE_CODE (init_code) == INIT_EXPR)
{
  /* In C++20, the call to build_aggr_init could have created

base-commit: 4ed34c60a818cc513239844f336fc781a8b47a24
-- 
2.27.0

c++: typename_type structural comparison

[Nathan Sidwell]

For modules we need to compare structurally all the way down.  This
means inhibiting typename_type resolution, independent of comparing
specializations.

gcc/cp/
* cp-tree.h (comparing_typenames): Declare.
* pt.c (comparing_typenames): Define.
(spec_hasher::equal): Increment it around comparisons.
* typeck.c (structural_comptypes): Adjust TYPENAME resolution
check.

pushing to trunk

nathan
--
Nathan Sidwell
diff --git i/gcc/cp/cp-tree.h w/gcc/cp/cp-tree.h
index 3b67e7ae76a..f7a737910b6 100644
--- i/gcc/cp/cp-tree.h
+++ w/gcc/cp/cp-tree.h
@@ -5399,6 +5399,10 @@ extern int function_depth;
in structrual_comptypes.  */
 extern int comparing_specializations;
 
+/* Nonzero if we are inside eq_specializations, which affects
+   resolving of typenames in structural_comptypes.  */
+extern int comparing_typenames;
+
 /* In parser.c.  */
 
 /* Nonzero if we are parsing an unevaluated operand: an operand to
diff --git i/gcc/cp/pt.c w/gcc/cp/pt.c
index 4fb0bc82c31..19a2ea0acd4 100644
--- i/gcc/cp/pt.c
+++ w/gcc/cp/pt.c
@@ -1702,9 +1702,11 @@ register_specialization (tree spec, tree tmpl, tree args, bool is_friend,
   return spec;
 }
 
-/* Returns true iff two spec_entry nodes are equivalent.  */
-
+/* Restricts tree and type comparisons.  */
 int comparing_specializations;
+int comparing_typenames;
+
+/* Returns true iff two spec_entry nodes are equivalent.  */
 
 bool
 spec_hasher::equal (spec_entry *e1, spec_entry *e2)
@@ -1712,6 +1714,7 @@ spec_hasher::equal (spec_entry *e1, spec_entry *e2)
   int equal;
 
   ++comparing_specializations;
+  ++comparing_typenames;
   equal = (e1->tmpl == e2->tmpl
 	   && comp_template_args (e1->args, e2->args));
   if (equal && flag_concepts
@@ -1727,6 +1730,7 @@ spec_hasher::equal (spec_entry *e1, spec_entry *e2)
   equal = equivalent_constraints (c1, c2);
 }
   --comparing_specializations;
+  --comparing_typenames;
 
   return equal;
 }
diff --git i/gcc/cp/typeck.c w/gcc/cp/typeck.c
index 267b284ea40..6294a787b5a 100644
--- i/gcc/cp/typeck.c
+++ w/gcc/cp/typeck.c
@@ -1256,16 +1256,15 @@ structural_comptypes (tree t1, tree t2, int strict)
 
   gcc_assert (TYPE_P (t1) && TYPE_P (t2));
 
-  if (!comparing_specializations)
-{
-  /* TYPENAME_TYPEs should be resolved if the qualifying scope is the
-	 current instantiation.  */
-  if (TREE_CODE (t1) == TYPENAME_TYPE)
-	t1 = resolve_typename_type (t1, /*only_current_p=*/true);
-
-  if (TREE_CODE (t2) == TYPENAME_TYPE)
-	t2 = resolve_typename_type (t2, /*only_current_p=*/true);
-}
+  /* TYPENAME_TYPEs should be resolved if the qualifying scope is the
+ current instantiation, and we don't care about typename
+ structural equality.  The comparing_typenames check is after the
+ code check, in order to early-out the common case.  */
+  if (TREE_CODE (t1) == TYPENAME_TYPE && !comparing_typenames)
+t1 = resolve_typename_type (t1, /*only_current_p=*/true);
+
+  if (TREE_CODE (t2) == TYPENAME_TYPE && !comparing_typenames)
+t2 = resolve_typename_type (t2, /*only_current_p=*/true);
 
   if (TYPE_PTRMEMFUNC_P (t1))
 t1 = TYPE_PTRMEMFUNC_FN_TYPE (t1);

Re: [PATCH] c++: Treat OPAQUE_TYPE types as an aggregate type [PR97947]

[Nathan Sidwell]

On 12/2/20 3:37 PM, Jason Merrill wrote:

On 12/2/20 3:36 PM, Jakub Jelinek wrote:
On Wed, Dec 02, 2020 at 02:20:17PM -0600, Peter Bergner via 
Gcc-patches wrote:

My apologies for sending this a second time. I forgot to add the
mailing list to the CC list. :-(


c++: Treat OPAQUE_TYPE types as an aggregate type

MODE_OPAQUE and the associated OPAQUE_TYPE were added to stop the 
optimizers
from knowing how the bits in a variable with an opaque type are laid 
out.
This makes them a kind of pseudo aggregate type and we need to treat 
them

as such when we process the INIT initializer for variables with an
opaque type.


Just a random question, do you have some testsuite coverage for constant
expression evaluation (primarily C++) with the opaque types, do you 
verify

any object with that type is treated as something that may not appear in
constant expression and does constexpr.c properly punt on it rather than
ICE?


Yes, I'm sure many more changes are necessary for significant C++ 
support.  But this patch is OK.


Well, they ain't gonna serialize though modules :)

nathan


--
Nathan Sidwell

Re: [PATCH] c++: Treat OPAQUE_TYPE types as an aggregate type [PR97947]

[Jason Merrill via Gcc-patches]

On 12/2/20 3:36 PM, Jakub Jelinek wrote:

On Wed, Dec 02, 2020 at 02:20:17PM -0600, Peter Bergner via Gcc-patches wrote:

My apologies for sending this a second time. I forgot to add the
mailing list to the CC list. :-(


c++: Treat OPAQUE_TYPE types as an aggregate type

MODE_OPAQUE and the associated OPAQUE_TYPE were added to stop the optimizers
from knowing how the bits in a variable with an opaque type are laid out.
This makes them a kind of pseudo aggregate type and we need to treat them
as such when we process the INIT initializer for variables with an
opaque type.


Just a random question, do you have some testsuite coverage for constant
expression evaluation (primarily C++) with the opaque types, do you verify
any object with that type is treated as something that may not appear in
constant expression and does constexpr.c properly punt on it rather than
ICE?


Yes, I'm sure many more changes are necessary for significant C++ 
support.  But this patch is OK.


Jason

Re: [08/23] Add an alternative splay tree implementation

[Jeff Law via Gcc-patches]

On 11/13/20 1:15 AM, Richard Sandiford via Gcc-patches wrote:
> We already have two splay tree implementations: the old C one in
> libiberty and a templated reimplementation of it in typed-splay-tree.h.
> However, they have some drawbacks:
>
> - They hard-code the assumption that nodes should have both a key and
>   a value, which isn't always true.
>
> - They use the two-phase method of lookup, and so nodes need to store
>   a temporary back pointer.  We can avoid that overhead by using the
>   top-down method (as e.g. the bitmap tree code already does).
>
> - The tree node has to own the key and the value.  For some use cases
>   it's more convenient to embed the tree links in the value instead.
>
> Also, a later patch wants to use splay trees to represent an
> adaptive total order: the splay tree itself records whether node N1
> is less than node N2, and (in the worst case) comparing nodes is
> a splay operation.
>
> This patch therefore adds an alternative implementation.  The main
> features are:
>
> - Nodes can optionally point back to their parents.
>
> - An Accessors class abstracts accessing child nodes and (where
>   applicable) parent nodes, so that the information can be embedded
>   in larger data structures.
>
> - There is no fixed comparison function at the class level.  Instead,
>   individual functions that do comparisons take a comparison function
>   argument.
>
> - There are two styles of comparison function, optimised for different
>   use cases.  (See the comments in the patch for details.)
>
> - It's possible to do some operations directly on a given node,
>   without knowing whether it's the root.  This includes the comparison
>   use case described above.
>
> This of course has its own set of drawbacks.  It's really providing
> splay utility functions rather than a true ADT, and so is more low-level
> than the existing routines.  It's mostly geared for cases in which the
> client code wants to participate in the splay operations to some extent.
>
> gcc/
>   * Makefile.in (OBJS): Add splay-tree-utils.o.
>   * system.h: Include  when INCLUDE_ARRAY is defined.
>   * selftest.h (splay_tree_cc_tests): Declare.
>   * selftest-run-tests.c (selftest::run_tests): Run splay_tree_cc_tests.
>   * splay-tree-utils.h: New file.
>   * splay-tree-utils.tcc: Likewise.
>   * splay-tree-utils.cc: Likewise.
I must admit, I'm not a fan of adding another splay tree.  Though I
suspect the one in libiberty will be there forever since there could
well be clients outside our source base.

The typed_splay_tree implementation however is internal to GCC and only
has a couple users (the JIT and fixit hints).  Is there any chance we
could convert those two users to the new one?  Your cover hints that's
not the case, but I'm going to explicitly ask :-)

As for the implementation, I've got no real concerns there.  If there's
issues, I'm sure you'll deal with them.

Jeff

Re: [PATCH] c++: Treat OPAQUE_TYPE types as an aggregate type [PR97947]

[Jakub Jelinek via Gcc-patches]

On Wed, Dec 02, 2020 at 02:20:17PM -0600, Peter Bergner via Gcc-patches wrote:
> My apologies for sending this a second time. I forgot to add the
> mailing list to the CC list. :-(
> 
> 
> c++: Treat OPAQUE_TYPE types as an aggregate type
> 
> MODE_OPAQUE and the associated OPAQUE_TYPE were added to stop the optimizers
> from knowing how the bits in a variable with an opaque type are laid out.
> This makes them a kind of pseudo aggregate type and we need to treat them
> as such when we process the INIT initializer for variables with an
> opaque type.

Just a random question, do you have some testsuite coverage for constant
expression evaluation (primarily C++) with the opaque types, do you verify
any object with that type is treated as something that may not appear in
constant expression and does constexpr.c properly punt on it rather than
ICE?

Jakub

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

[Jason Merrill via Gcc-patches]

On 7/10/20 1:53 PM, Jeff Chapman wrote:

Hello again :)

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.




Please let me know if there's a better way to share revisions.


+  /* Check that assertions are null statements.  */
+  if (attribute_contract_assert_p (contract_attrs))
+if (token->type != CPP_SEMICOLON)
+  error_at (token->location, "assertions must be followed by
%<;%>");


Better I think to handle this further down where [[fallthrough]] has the
same requirement.



I'm wondering if it would be better to move [[fallthrough]] up, since
the later check is not always executed and in the case of [[assert]] we
actually need to error.

   [[fallthrough]] int x;

for instance just gets a generic 'attribute ignored' warning. I'm not
entirely happy with how we prevent assert/pre/post from appearing in
invalid locations in general which I'll try to improve. If you have
concrete suggestions please let me know.


Improvements have been made to handling contract attributes appearing in
places they don't belong. Any feedback about moving the logic dealing
with [[fallthrough]]?



Why not leave the function the user declared as the unchecked function
(just changing some linkage properties) and create a new function for
the checked wrapper?



This revision of the patch does not include changes to the
checked/unchecked function split. We're exploring an alternative rewrite
that leaves the original function declaration alone and should address
or sidestep a number of these comments.

Specifically, we're exploring generating pre and post functions with
calls to them in the correct places (upon entering a guarded function,
wrapping the return value):

   int f(int n) [[ pre: n > 0 ]] [[ post r: r < 0 ]] { return -n; }

turns into

   void __pre_f(int n) { [[ assert: n > 0 ]]; }
   int __post_f(int r) { [[ assert: r < 0 ]]; return r; }
   int f(int n) {
 __pre_f(n);
 return __post_f(-n);
   }

with whatever hints we can give to optimize this as much as possible.


This is the main change since the last submission. We now leave the
original decl intact and instead generate a pre and post function.
Naming and mangling of these pre/post functions needs addressed.

Beyond that, more cleanup has been done. There's still outstanding
cleanup work, mostly around investigating and improving performance.
Feedback on the main direction of the patch would be appreciated, and
any specific commentary or directions of investigation would be helpful.



+/* Return the source text between two locations.  */
+
+static char *
+get_source (location_t start, location_t end)


This seems like it belongs in libcpp.  It also needs to



This has been moved to input since it uses input functions, but needs
more work. Was there another comment you had that cutoff?

...snip...


+  /* We never want to accidentally instantiate templates.  */
+  if (code == TEMPLATE_DECL)
+return *tp; /* FIXME? */


This seems unlikely to have the desired effect; we should see template
instantiations as FUNCTION_DECL or VAR_DECL.  I'm also not sure what the
cp_tree_defined_p check is trying to do; surely using defined functions
and variables can also lead to runtime code?



This is an result of the transform we do for axioms when they're enabled
that you may know of a better way to do. Essentially we turn this:

   [[ assert axiom: f() > 0 ]];

into this:

   if (!(f() > 0))
 __builtin_unreachable ();

but we potentially run into issues later if f isn't (yet) defined or is
defined in a different translation unit, such as constexpr time. We're
avoiding those errors by generating a nop if there's any chance can't be
evaluated. We'd prefer something like

   __builtin_assume (f() > 0);

where the condition is simply ignored if enough information isn't
present to affect codegen. Is there a better way to handle this?

I should mention that there are likely significant further changes
around axiom coming down the pike that may tie into or replace the
"is defined" check. Specifically for expressions that _cannot_ be
defined rather than ones that are simply not yet defined.



Not much has changed yet regarding axiom, but if you have any
suggestions for handling any of the above then I'm all ears.

Re: [committed] adjust expected warnings to reflect max-object-size

[Jeff Law via Gcc-patches]

On 12/2/20 11:43 AM, Martin Sebor wrote:
> The r11-5622 change to -Wformat-overflow switched the warning
> to using the maximm object size limit used by the other overflow
> and out of bounds access warnings like -Wstringop-overflow.
> That in turn exposed a subtle off-by-one mistake in the former
> that was also reflected in a few tests, seen in ILP32 but not
> in LP64.  I just committed the attached patch adjusts the tests
> to correctly reflect the limit.  These mistakes would be easier
> to avoid if if were possible to lower the max object size limit
> from PTRDIFF_MAX - 1 to a value that's independent of the target
> as in the following patch:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559450.html
>
> Martin
>
> gcc-sprintf-max-objsize.diff
>
> commit 0a7dc4b6440faa8cd57c630f1e394a719469c399
> Author: Martin Sebor 
> Date:   Wed Dec 2 11:29:11 2020 -0700
>
> Adjust test to avoid ILP32 failures after r11-5622 (PR middle-end/97373)
> 
> gcc/testsuite/ChangeLog:
> * gcc.dg/tree-ssa/builtin-sprintf-warn-1.c: Adjust expected 
> warnings
> to correctly reflect the maximum object size.
> * gcc.dg/tree-ssa/builtin-sprintf-warn-11.c: Same.
> * gcc.dg/tree-ssa/builtin-sprintf-warn-18.c: Same.
Still seeing regressions.  mcore-elf for example:

Tests that now fail, but worked before (4 tests):

moxie-sim: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for excess errors)
moxie-sim: gcc.dg/tree-ssa/builtin-sprintf-warn-11.c (test for excess
errors)

And in the log file:
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for excess errors)
Excess errors:
/home/jenkins/gcc/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c:119:3:
warning: '__builtin_sprintf' writing a terminating nul past the end of
the destination [-Wformat-overflow=]
/home/jenkins/gcc/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c:121:3:
warning: '__builtin_sprintf' writing a terminating nul past the end of
the destination [-Wformat-overflow=]
/home/jenkins/gcc/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c:122:3:
warning: '%*c' directive writing 2147483647 bytes into a region of size
2147483646 [-Wformat-overflow=]
/home/jenkins/gcc/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c:125:3:
warning: '%*c' directive writing 2147483646 bytes into a region of size
1 [-Wformat-overflow=]
/home/jenkins/gcc/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c:130:3:
warning: '__builtin_sprintf' writing a terminating nul past the end of
the destination [-Wformat-overflow=]
/home/jenkins/gcc/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c:131:3:
warning: 'X' directive writing 1 byte into a region of size 0
[-Wformat-overflow=]
/home/jenkins/gcc/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c:299:3:
warning: '__builtin_sprintf' writing a terminating nul past the end of
the destination [-Wformat-overflow=]
/home/jenkins/gcc/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c:300:3:
warning: '%*s' directive writing 2147483647 bytes into a region of size
2147483646 [-Wformat-overflow=]

And:
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-11.c (test for excess errors)
Excess errors:
/home/jenkins/gcc/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-11.c:207:3:
warning: '__builtin_sprintf' writing a terminating nul past the end of
the destination [-Wformat-overflow=]
/home/jenkins/gcc/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-11.c:215:3:
warning: '%*.*s' directive writing between 5 and 6 bytes into a region
of size between 2 and 4 [-Wformat-overflow=]



Again, I think you can look at these with a simple cross compiler.  I
don't think you need cross-binutils, newlib, etc.

jeff

[PATCH] c++: Treat OPAQUE_TYPE types as an aggregate type [PR97947]

[Peter Bergner via Gcc-patches]

My apologies for sending this a second time. I forgot to add the
mailing list to the CC list. :-(


c++: Treat OPAQUE_TYPE types as an aggregate type

MODE_OPAQUE and the associated OPAQUE_TYPE were added to stop the optimizers
from knowing how the bits in a variable with an opaque type are laid out.
This makes them a kind of pseudo aggregate type and we need to treat them
as such when we process the INIT initializer for variables with an
opaque type.

This passed bootstrap and regtesting on powerpc64le-linux with no regressions.
Ok for trunk?

Peter


gcc/cp/
PR c++/97947
* typeck2.c (digest_init_r): Handle OPAQUE_TYPE as an aggregate type.

gcc/testsuite/
PR c++/97947
* g++.target/powerpc/pr97947.C: New test.

diff --git a/gcc/cp/typeck2.c b/gcc/cp/typeck2.c
index 721987e8502..97bb41b7d2e 100644
--- a/gcc/cp/typeck2.c
+++ b/gcc/cp/typeck2.c
@@ -1147,6 +1147,7 @@ digest_init_r (tree type, tree init, int nested, int 
flags,
  || VECTOR_TYPE_P (type)
  || code == RECORD_TYPE
  || code == UNION_TYPE
+ || code == OPAQUE_TYPE
  || code == COMPLEX_TYPE);
 
   /* "If T is a class type and the initializer list has a single
diff --git a/gcc/testsuite/g++.target/powerpc/pr97947.C 
b/gcc/testsuite/g++.target/powerpc/pr97947.C
new file mode 100644
index 000..05ddbef2d17
--- /dev/null
+++ b/gcc/testsuite/g++.target/powerpc/pr97947.C
@@ -0,0 +1,12 @@
+/* PR c++/97947 */
+/* { dg-do compile } */
+/* { dg-require-effective-target power10_ok } */
+/* { dg-options "-O2 -mdejagnu-cpu=power10" } */
+
+/* Verify we do not ICE on the test below.  */
+
+void
+bug (__vector_pair *src)
+{
+  volatile __vector_pair dd = *src;
+}

Re: [PATCH] c++: Change __builtin_source_location to use __PRETTY_FUNCTION__ instead of __FUNCTION__ [PR80780]

[Jason Merrill via Gcc-patches]

On 12/2/20 7:30 AM, Jakub Jelinek wrote:

Hi!

On Tue, Dec 01, 2020 at 01:03:52PM +, Jonathan Wakely via Gcc-patches wrote:

I mentioned in PR 80780 that a __builtin__PRETTY_FUNCTION would have
been nice, because __FUNCTION__ isn't very useful for C++, because of
overloading and namespace/class scopes. There are an unlimited number
of functions that have __FUNCTION__ == "s", e.g. "ns::s(int)" and
"ns::s()" and "another_scope::s::s(T...)" etc.

Since __builtin_source_location() can do whatever it wants (without
needing to add __builtin__PRETTY_FUNCTION) it might be nice to use the
__PRETTY_FUNCTION__ string. JeanHeyd's tests would still need changes,
because the name would be "s::s(void*)" not "s::s" but that still
seems better for users.


When I've added template tests for the previous patch, I have noticed that
the current __builtin_source_location behavior is not really __FUNCTION__,
just close, because e.g. in function template __FUNCTION__ is still
"bar" but __builtin_source_location gave "bar<0>".

Anyway, this patch implements above request to follow __PRETTY_FUNCTION__
(on top of the earlier posted patch).

Tested on x86_64-linux, ok for trunk if it passes full bootstrap/regtest on
x86_64-linux?


OK on Friday unless Jonathan objects.


2020-12-02  Jakub Jelinek  

PR c++/80780
* cp-gimplify.c (fold_builtin_source_location): Use 2 instead of 0
as last argument to cxx_printable_name.

* g++.dg/cpp2a/srcloc1.C (quux): Use __PRETTY_FUNCTION__ instead of
function.
* g++.dg/cpp2a/srcloc2.C (quux): Likewise.
* g++.dg/cpp2a/srcloc15.C (S::S): Likewise.
(bar): Likewise.  Adjust expected column.
* g++.dg/cpp2a/srcloc17.C (S::S): Likewise.
(bar): Likewise.  Adjust expected column.

--- gcc/cp/cp-gimplify.c.jj 2020-12-02 12:26:21.596922205 +0100
+++ gcc/cp/cp-gimplify.c2020-12-02 13:16:48.599284262 +0100
@@ -3001,7 +3001,7 @@ fold_builtin_source_location (location_t
  const char *name = "";
  
  	  if (current_function_decl)

-   name = cxx_printable_name (current_function_decl, 0);
+   name = cxx_printable_name (current_function_decl, 2);
  
  	  val = build_string_literal (strlen (name) + 1, name);

}
--- gcc/testsuite/g++.dg/cpp2a/srcloc1.C.jj 2020-07-28 15:39:10.012756173 
+0200
+++ gcc/testsuite/g++.dg/cpp2a/srcloc1.C2020-12-02 13:17:39.010708329 
+0100
@@ -88,7 +88,7 @@ quux ()
const char *file1 = source_location::current ().file_name ();
const char *file2 = __FILE__;
const char *function1 = source_location::current ().function_name ();
-  const char *function2 = __FUNCTION__;
+  const char *function2 = __PRETTY_FUNCTION__;
int line1 = source_location::current ().line ();
int line2 = __LINE__ - 1;
int column
--- gcc/testsuite/g++.dg/cpp2a/srcloc2.C.jj 2020-07-28 15:39:10.012756173 
+0200
+++ gcc/testsuite/g++.dg/cpp2a/srcloc2.C2020-12-02 13:17:51.851562576 
+0100
@@ -92,7 +92,7 @@ quux ()
const char *file1 = source_location::current ().file_name ();
const char *file2 = __FILE__;
const char *function1 = source_location::current ().function_name ();
-  const char *function2 = __FUNCTION__;
+  const char *function2 = __PRETTY_FUNCTION__;
int line1 = source_location::current ().line ();
int line2 = __LINE__ - 1;
int column
--- gcc/testsuite/g++.dg/cpp2a/srcloc15.C.jj2020-12-02 12:48:20.592828477 
+0100
+++ gcc/testsuite/g++.dg/cpp2a/srcloc15.C   2020-12-02 13:20:46.768577089 
+0100
@@ -44,12 +44,12 @@ struct S {
source_location loc = source_location::current ();
  
constexpr S (int l, source_location loc = source_location::current ())

-  : func(__FUNCTION__), line(l), loc(loc)
+  : func(__PRETTY_FUNCTION__), line(l), loc(loc)
{}
  
constexpr S (double)

-  : func(__FUNCTION__), line(__LINE__)
-  // ^ column 38
+  : func(__PRETTY_FUNCTION__), line(__LINE__)
+  //^ column 45
{}
  };
  
@@ -73,7 +73,7 @@ bar ()

//^ column 49
const source_location *d[3] = { &a, &b, &c };
const char *file1 = __FILE__;
-  const char *function1 = __FUNCTION__;
+  const char *function1 = __PRETTY_FUNCTION__;
for (int j = 0; j < 3; j++)
  {
int i= 0;
@@ -104,7 +104,7 @@ bar ()
  return false;
if (e.loc.column () != 9)
  return false;
-  if (f.loc.column () != 38)
+  if (f.loc.column () != 45)
  return false;
return true;
  }
--- gcc/testsuite/g++.dg/cpp2a/srcloc17.C.jj2020-12-02 12:58:26.113904280 
+0100
+++ gcc/testsuite/g++.dg/cpp2a/srcloc17.C   2020-12-02 13:21:11.943291326 
+0100
@@ -46,12 +46,12 @@ struct S {
source_location loc = source_location::current ();
  
constexpr S (int l, source_location loc = source_location::current ())

-  : func(__FUNCTION__), line(l), loc(loc)
+  : func(__PRETTY_FUNCTIO

[pushed] git: Tell git send-email where to send patches.

[Jason Merrill via Gcc-patches]

I've been using

  git send-email --annotate --suppress-from --to=gcc-patches@gcc.gnu.org \
  ${@:-HEAD^} ':!*/ChangeLog' ':!*configure'

for sending most patches, but it occurs to me that it would be useful to put
the To: address in the configury.

If someone were feeling ambitious, they could write a script to analyze a
patch and add the relevant maintainers to To: or CC:.

Pushed as obvious.

contrib/ChangeLog:

* gcc-git-customization.sh: Configure sendemail.to.
---
 contrib/gcc-git-customization.sh | 4 
 1 file changed, 4 insertions(+)

diff --git a/contrib/gcc-git-customization.sh b/contrib/gcc-git-customization.sh
index 200b81eec31..e7e66623786 100755
--- a/contrib/gcc-git-customization.sh
+++ b/contrib/gcc-git-customization.sh
@@ -35,6 +35,10 @@ git config alias.gcc-commit-mklog '!f() { GCC_FORCE_MKLOG=1 
git commit "$@"; };
 # *.mddiff=md
 git config diff.md.xfuncname '^\(define.*$'
 
+# Tell git send-email where patches go.
+# ??? Maybe also set sendemail.tocmd to guess from MAINTAINERS?
+git config sendemail.to 'gcc-patches@gcc.gnu.org'
+
 set_user=$(git config --get "user.name")
 set_email=$(git config --get "user.email")
 

base-commit: e34153b0e230bc0a8b9a3f5db1d46a67cbb51788
-- 
2.27.0

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

[Richard Sandiford via Gcc-patches]

Richard Sandiford via Gcc-patches  writes:
> Przemyslaw Wirkus  writes:
>> New +flagm (Condition flag manipulation from Armv8.4-A) feature option for
>> -march command line option.
>>
>> Please note that FLAGM stays an Armv8.4-A feature but now can be
>> assigned to other architectures or CPUs.
>>
>> OK for master?
>>
>> 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.

Thanks,
Richard

C++: Module-specific tree flags

[Nathan Sidwell]

This is an updated patch for the new tree flags needed for modules. 
Inspired by Richard's desire for documenting the flags, I realized that 
three of them could already be merged.  So that's done here.


Nothing uses these flags yet.

gcc/cp/
* cp-tree.h (DECL_MODULE_PURVIEW_P, DECL_MODULE_IMPORT_P)
(DECL_MODULE_ENTITY_P): New.
(DECL_MODULE_PENDING_SPECIALIZATIONS_P): New.
(DECL_MODULE_PENDING_MEMBERS_P): New.
(DECL_MODULE_ATTACHMENTS_P): New.
(DECL_MODULE_EXPORT_P): New.
(struct lang_decl_base): Shrink sel field.  Add new
module-specific fields.

pushing to trunk

--
Nathan Sidwell
diff --git i/gcc/cp/cp-tree.h w/gcc/cp/cp-tree.h
index d69110f7ab6..3b67e7ae76a 100644
--- i/gcc/cp/cp-tree.h
+++ w/gcc/cp/cp-tree.h
@@ -488,6 +488,7 @@ extern GTY(()) tree cp_global_trees[CPTI_MAX];
   CALL_EXPR_ORDERED_ARGS (in CALL_EXPR, AGGR_INIT_EXPR)
   DECLTYPE_FOR_REF_CAPTURE (in DECLTYPE_TYPE)
   CONSTRUCTOR_C99_COMPOUND_LITERAL (in CONSTRUCTOR)
+  DECL_MODULE_EXPORT_P (in _DECL)
   OVL_NESTED_P (in OVERLOAD)
   LAMBDA_EXPR_INSTANTIATED (in LAMBDA_EXPR)
   Reserved for DECL_MODULE_EXPORT (in DECL_)
@@ -1644,6 +1645,46 @@ check_constraint_info (tree t)
 #define CONSTRAINED_PARM_PROTOTYPE(NODE) \
   DECL_INITIAL (TYPE_DECL_CHECK (NODE))
 
+/* Module defines.  */
+// Too many _DECLS: FUNCTION,VAR,TYPE,TEMPLATE,CONCEPT or NAMESPACE
+#define DECL_MODULE_CHECK(NODE) (NODE)
+
+/* In the purview of a module (including header unit).  */
+#define DECL_MODULE_PURVIEW_P(N) \
+  (DECL_LANG_SPECIFIC (DECL_MODULE_CHECK (N))->u.base.module_purview_p)
+
+/* True if the live version of the decl was imported.  */
+#define DECL_MODULE_IMPORT_P(NODE) \
+  (DECL_LANG_SPECIFIC (DECL_MODULE_CHECK (NODE))->u.base.module_import_p)
+
+/* True if this decl is in the entity hash & array.  This means that
+   some variant was imported, even if DECL_MODULE_IMPORT_P is false.  */
+#define DECL_MODULE_ENTITY_P(NODE) \
+  (DECL_LANG_SPECIFIC (DECL_MODULE_CHECK (NODE))->u.base.module_entity_p)
+
+/* True if there are unloaded specializations keyed to this template.  */
+#define DECL_MODULE_PENDING_SPECIALIZATIONS_P(NODE)	\
+  (DECL_LANG_SPECIFIC (TEMPLATE_DECL_CHECK (NODE))	\
+   ->u.base.module_pending_p)
+
+/* True if this class has unloaded members.  These should be loaded
+   before we do member lookups.   */
+#define DECL_MODULE_PENDING_MEMBERS_P(NODE)		\
+  (DECL_LANG_SPECIFIC (TYPE_DECL_CHECK (NODE))		\
+   ->u.base.module_pending_p)
+
+/* DECL that has attached decls for ODR-relatedness.  */
+#define DECL_MODULE_ATTACHMENTS_P(NODE)			\
+  (DECL_LANG_SPECIFIC (TREE_CHECK2(NODE,FUNCTION_DECL,VAR_DECL))\
+   ->u.base.module_pending_p)
+
+/* Whether this is an exported DECL.  Held on any decl that can appear
+   at namespace scope (function, var, type, template, const or
+   namespace).  templates copy from their template_result, consts have
+   it for unscoped enums.  */
+#define DECL_MODULE_EXPORT_P(NODE) TREE_LANG_FLAG_3 (NODE)
+
+
 /* The list of local parameters introduced by this requires-expression,
in the form of a chain of PARM_DECLs.  */
 #define REQUIRES_EXPR_PARMS(NODE) \
@@ -2655,15 +2696,15 @@ enum lang_decl_selector
 /* Flags shared by all forms of DECL_LANG_SPECIFIC.
 
Some of the flags live here only to make lang_decl_min/fn smaller.  Do
-   not make this struct larger than 32 bits; instead, make sel smaller.  */
+   not make this struct larger than 32 bits.  */
 
 struct GTY(()) lang_decl_base {
-  /* Larger than necessary for faster access.  */
-  ENUM_BITFIELD(lang_decl_selector) selector : 16;
+  ENUM_BITFIELD(lang_decl_selector) selector : 3;
   ENUM_BITFIELD(languages) language : 1;
   unsigned use_template : 2;
   unsigned not_really_extern : 1;	   /* var or fn */
   unsigned initialized_in_class : 1;	   /* var or fn */
+
   unsigned threadprivate_or_deleted_p : 1; /* var or fn */
   /* anticipated_p is no longer used for anticipated_decls (fn, type
  or template).  It is used as DECL_OMP_PRIVATIZED_MEMBER in
@@ -2672,11 +2713,22 @@ struct GTY(()) lang_decl_base {
   unsigned friend_or_tls : 1;		   /* var, fn, type or template */
   unsigned unknown_bound_p : 1;		   /* var */
   unsigned odr_used : 1;		   /* var or fn */
-  unsigned spare : 1;
   unsigned concept_p : 1;  /* applies to vars and functions */
   unsigned var_declared_inline_p : 1;	   /* var */
   unsigned dependent_init_p : 1;	   /* var */
-  /* 2 spare bits */
+
+  /* The following apply to VAR, FUNCTION, TYPE, CONCEPT, TEMPLATE,
+ NAMESPACE decls.  */
+  unsigned module_purview_p : 1;	   /* in module purview (not GMF) */
+  unsigned module_import_p : 1; 	   /* from an import */
+  unsigned module_entity_p : 1;		   /* is in the entitity ary &
+	  hash.  */
+  /* TEMPLATE_DECL has specializations or,
+ TYPE_DECL has class members yet to load, or
+ VAR_DECL or FUNCTION_DECL has attached decls. */
+  unsigned

Re: [PATCH] c++: Fix ICE with inline variable in template [PR97975]

[Jason Merrill via Gcc-patches]

On 12/1/20 12:38 PM, Marek Polacek wrote:

In this test, we have

   static inline const int c = b;

in a class template, and we call store_init_value as usual.  There, the
value is

   IMPLICIT_CONV_EXPR(b)

which is is_nondependent_static_init_expression but isn't
is_nondependent_constant_expression (they only differ in STRICT).
We call fold_non_dependent_expr, but that just returns the expression
because it only instantiates is_nondependent_constant_expression
expressions.  Since we're not checking the initializer of a constexpr
variable, we go on to call maybe_constant_init, whereupon we crash
because it tries to evaluate all is_nondependent_static_init_expression
expressions, which our value is, but it still contains a template code.

I think the fix is to call fold_non_dependent_init instead of
maybe_constant_init, and only call fold_non_dependent_expr on the
"this is a constexpr variable" path so as to avoid instantiating twice
in a row.  Outside a template this should also avoid evaluating the
value twice.

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/10?


OK.


gcc/cp/ChangeLog:

PR c++/97975
* constexpr.c (fold_non_dependent_init): Add a tree parameter.
Use it.
* cp-tree.h (fold_non_dependent_init): Add a tree parameter with
a default value.
* typeck2.c (store_init_value): Call fold_non_dependent_expr
only when checking the initializer for constexpr variables.
Call fold_non_dependent_init instead of maybe_constant_init.

gcc/testsuite/ChangeLog:

PR c++/97975
* g++.dg/cpp1z/inline-var8.C: New test.
---
  gcc/cp/constexpr.c   |  7 ---
  gcc/cp/cp-tree.h |  2 +-
  gcc/cp/typeck2.c |  7 +--
  gcc/testsuite/g++.dg/cpp1z/inline-var8.C | 17 +
  4 files changed, 27 insertions(+), 6 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp1z/inline-var8.C

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 054ee524c7a..9a1a1db1267 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -7271,7 +7271,8 @@ maybe_fold_non_dependent_expr (tree expr,
  tree
  fold_non_dependent_init (tree t,
 tsubst_flags_t complain /*=tf_warning_or_error*/,
-bool manifestly_const_eval /*=false*/)
+bool manifestly_const_eval /*=false*/,
+tree object /* = NULL_TREE */)
  {
if (t == NULL_TREE)
  return NULL_TREE;
@@ -7279,7 +7280,7 @@ fold_non_dependent_init (tree t,
if (processing_template_decl)
  {
t = fold_non_dependent_expr_template (t, complain,
-   manifestly_const_eval, NULL_TREE);
+   manifestly_const_eval, object);
/* maybe_constant_init does this stripping, so do it here too.  */
if (TREE_CODE (t) == TARGET_EXPR)
{
@@ -7290,7 +7291,7 @@ fold_non_dependent_init (tree t,
return t;
  }
  
-  return maybe_constant_init (t, NULL_TREE, manifestly_const_eval);

+  return maybe_constant_init (t, object, manifestly_const_eval);
  }
  
  /* Like maybe_constant_value, but returns a CONSTRUCTOR directly, rather

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 021de76e142..41516deeafa 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -7953,7 +7953,7 @@ extern tree maybe_fold_non_dependent_expr (tree,
 tsubst_flags_t = 
tf_warning_or_error);
  extern tree fold_non_dependent_init   (tree,
 tsubst_flags_t = 
tf_warning_or_error,
-bool = false);
+bool = false, tree = 
NULL_TREE);
  extern tree fold_simple   (tree);
  extern bool reduced_constant_expression_p   (tree);
  extern bool is_instantiation_of_constexpr   (tree);
diff --git a/gcc/cp/typeck2.c b/gcc/cp/typeck2.c
index 721987e8502..575c609a365 100644
--- a/gcc/cp/typeck2.c
+++ b/gcc/cp/typeck2.c
@@ -744,11 +744,13 @@ store_init_value (tree decl, tree init, vec** cleanups, int flags)
  {
bool const_init;
tree oldval = value;
-  value = fold_non_dependent_expr (value, tf_warning_or_error, true, decl);
if (DECL_DECLARED_CONSTEXPR_P (decl)
  || (DECL_IN_AGGR_P (decl)
  && DECL_INITIALIZED_IN_CLASS_P (decl)))
{
+ value = fold_non_dependent_expr (value, tf_warning_or_error,
+  /*manifestly_const_eval=*/true,
+  decl);
  /* Diagnose a non-constant initializer for constexpr variable or
 non-inline in-class-initialized static data member.  */
  if (!require_constant_expression (value))
@@ -762,7 +764,8 @@ store_init_value (tree decl, tree in

Re: [patch][rtl-optimization][i386][pr97777] Fix a reg-stack df maintenance bug triggered by zero-call-used-regs pass.

[Qing Zhao via Gcc-patches]

Thanks a lot for your review.

I will commit the patch soon.

Qing

> On Dec 2, 2020, at 12:27 PM, Jeff Law  wrote:
> 
> 
> 
> On 12/2/20 9:32 AM, Qing Zhao wrote:
>> 
>>> So we are clearing the x87 registers with that option.  Hence the change
>>> in reg-stack behavior.  I'm a bit surprised by this as I don't see
>>> clearing the x87 registers as particularly helpful from a security
>>> standpoint.  But I haven't followed that discussion closely.
>> Even with the option -fzero-call-used-regs=used-gpr (without clearing any 
>> x87 registers), 
>> We have the same compiler time error. 
>> 
>> The first thing that the new pass “zero_call_used_regs” does is:
>> 
>> df_analyze();
> OK.  So that's the key issue, until now nothing has really cared about
> the DF state after reg-stack, but the pass to zero registers does.  I
> had the order backwards in my head with register clearing happening
> before regstack.  Hence my significant confusion about why things were
> suddenly going wrong.
> 
> The patch is OK.  Thanks for patiently walking me through this.
> 
> jeff
> 

Re: [PATCH][PR target/97642] Fix incorrect replacement of vmovdqu32 with vpblendd.

[Jeff Law via Gcc-patches]

On 11/25/20 9:47 PM, Hongtao Liu wrote:
> On Wed, Nov 25, 2020 at 7:37 PM Jakub Jelinek  wrote:
>> On Wed, Nov 25, 2020 at 07:32:44PM +0800, Hongtao Liu wrote:
>>> Update patch:
>>>   1. ix86_expand_special_args_builtin is used for expanding mask load
>>> intrinsics, this function will always convert the constant mask
>>> operands into reg. So for the situation of all-ones mask, keep this
>>> constant, and also change the mask operand predicate(of corresponding
>>> expander) to register_or_constm1_operand.
>>>   2. Delete last_arg_constant which is not used in
>>> ix86_expand_special_args_builtin(maybe should be in a separate patch?)
>> Yes, please make it a separate patch, it should go in first and
>> should just drop last_arg_constant from that function plus the
>> reindentation.
>>
>> Then post the PR97642 incremental to that.
>>
> Updated.
>
>> Thanks.
>>
>> Jakub
>>
>
> 0002-Fix-incorrect-replacement-of-vmovdqu32-with-vpblendd.patch
>
> From b1256b6ef8f877244f4955b9205d53797424fc27 Mon Sep 17 00:00:00 2001
> From: liuhongt 
> Date: Tue, 3 Nov 2020 17:26:43 +0800
> Subject: [PATCH 2/2] Fix incorrect replacement of vmovdqu32 with vpblendd
>  which can cause fault.
>
> gcc/ChangeLog:
>
>   PR target/97642
>   * config/i386/i386-expand.c
>   (ix86_expand_special_args_builtin): Don't move all-ones mask
>   operands into register.
>   * config/i386/sse.md (UNSPEC_MASKLOAD): New unspec.
>   (*_load_mask): New define_insns for masked load
>   instructions.
>   (_load_mask): Changed to define_expands which
>   specifically handle memory or all-ones mask operands.
>   (_blendm): Changed to define_insns which are same
>   as original _load_mask with adjustment of
>   operands order.
>   (*_load): New define_insn_and_split which is
>   used to optimize for masked load with all one mask.
>
> gcc/testsuite/ChangeLog:
>
>   * gcc.target/i386/avx512bw-vmovdqu16-1.c: Adjust testcase to
>   make sure only masked load instruction is generated.
>   * gcc.target/i386/avx512bw-vmovdqu8-1.c: Ditto.
>   * gcc.target/i386/avx512f-vmovapd-1.c: Ditto.
>   * gcc.target/i386/avx512f-vmovaps-1.c: Ditto.
>   * gcc.target/i386/avx512f-vmovdqa32-1.c: Ditto.
>   * gcc.target/i386/avx512f-vmovdqa64-1.c: Ditto.
>   * gcc.target/i386/avx512vl-vmovapd-1.c: Ditto.
>   * gcc.target/i386/avx512vl-vmovaps-1.c: Ditto.
>   * gcc.target/i386/avx512vl-vmovdqa32-1.c: Ditto.
>   * gcc.target/i386/avx512vl-vmovdqa64-1.c: Ditto.
>   * gcc.target/i386/pr97642-1.c: New test.
>   * gcc.target/i386/pr97642-2.c: New test.
> ---
> [ ... ]

> diff --git a/gcc/testsuite/gcc.target/i386/pr97642-2.c 
> b/gcc/testsuite/gcc.target/i386/pr97642-2.c
> new file mode 100644
> index 000..eb06a2739b4
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/pr97642-2.c
> @@ -0,0 +1,77 @@
> +/* PR target/97642 */
> +/* { dg-do run } */
> +/* { dg-options "-O2 -mavx512dq -mavx512vl -mavx512bw" } */
> +/* { dg-require-effective-target avx512vl } */
> +/* { dg-require-effective-target avx512dq } */
> +/* { dg-require-effective-target avx512bw } */
Given the uses of mprotect in this test, don't we need the test to be
limited to systems where that's supported.   Even just limiting to linux
targets is probably sufficient.

With that change, I think this is OK for the trunk.

jeff

libbacktrace patch committed: permit values at end of buffer

[Ian Lance Taylor via Gcc-patches]

A couple of buffer overflow checks in libbacktrace incorrectly used >=
when comparing the end of the value with the end of the buffer.  It is
of course OK if the value ends at the very end of the buffer.  This
patch corrects those cases to use > instead.  Bootstrapped and ran
libbacktrace and Go tests on x86_64-pc-linux-gnu.  Committed to
mainline.

Ian

* dwarf.c (resolve_string): Use > rather than >= to check whether
string index extends past buffer.
(resolve_addr_index): Similarly for address index.
2e7ce16d5156bab9c217d21e7ff17a6a6eaf6fd3
diff --git a/libbacktrace/dwarf.c b/libbacktrace/dwarf.c
index 582f34bc816..0c913c95983 100644
--- a/libbacktrace/dwarf.c
+++ b/libbacktrace/dwarf.c
@@ -1053,7 +1053,7 @@ resolve_string (const struct dwarf_sections 
*dwarf_sections, int is_dwarf64,
 
offset = val->u.uint * (is_dwarf64 ? 8 : 4) + str_offsets_base;
if (offset + (is_dwarf64 ? 8 : 4)
-   >= dwarf_sections->size[DEBUG_STR_OFFSETS])
+   > dwarf_sections->size[DEBUG_STR_OFFSETS])
  {
error_callback (data, "DW_FORM_strx value out of range", 0);
return 0;
@@ -1097,7 +1097,7 @@ resolve_addr_index (const struct dwarf_sections 
*dwarf_sections,
   struct dwarf_buf addr_buf;
 
   offset = addr_index * addrsize + addr_base;
-  if (offset + addrsize >= dwarf_sections->size[DEBUG_ADDR])
+  if (offset + addrsize > dwarf_sections->size[DEBUG_ADDR])
 {
   error_callback (data, "DW_FORM_addrx value out of range", 0);
   return 0;

Re: [PATCH] c++: Fix tsubst ICE with invalid code [PR97993, PR97187]

[Jason Merrill via Gcc-patches]

On 12/1/20 12:38 PM, Marek Polacek wrote:

I had a strong sense of deja vu when looking into this, and no wonder,
since this is almost identical to c++/95728.

Since r11-423 tsubst_copy_and_build/TREE_LIST uses tsubst_tree_list
instead of open coding it.  While the latter could return an error
node wrapped in a TREE_LIST, the former can return a naked error node.

That broke in tsubst_copy_and_build/NEW_EXPR, because we were accessing
TREE_VALUE of an error node.

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?


OK.


gcc/cp/ChangeLog:

PR c++/97187
PR c++/97993
* pt.c (tsubst_copy_and_build) : Return error_mark_node
if init is erroneous.

gcc/testsuite/ChangeLog:

PR c++/97187
PR c++/97993
* g++.dg/eh/crash2.C: New test.
* g++.dg/template/crash132.C: New test.
---
  gcc/cp/pt.c  |  2 ++
  gcc/testsuite/g++.dg/eh/crash2.C | 20 
  gcc/testsuite/g++.dg/template/crash132.C |  6 ++
  3 files changed, 28 insertions(+)
  create mode 100644 gcc/testsuite/g++.dg/eh/crash2.C
  create mode 100644 gcc/testsuite/g++.dg/template/crash132.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 4fb0bc82c31..72d6cc3ad98 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -19829,6 +19829,8 @@ tsubst_copy_and_build (tree t,
   parameter packs are of length zero.  */
if (init == NULL_TREE && TREE_OPERAND (t, 3) == NULL_TREE)
  init_vec = NULL;
+   else if (init == error_mark_node)
+ RETURN (error_mark_node);
else
  {
init_vec = make_tree_vector ();
diff --git a/gcc/testsuite/g++.dg/eh/crash2.C b/gcc/testsuite/g++.dg/eh/crash2.C
new file mode 100644
index 000..fff8e142fd6
--- /dev/null
+++ b/gcc/testsuite/g++.dg/eh/crash2.C
@@ -0,0 +1,20 @@
+// PR c++/97187
+// { dg-do compile { target c++14 } }
+// { dg-options "-fno-exceptions" }
+
+auto yp = [] { return 0; };
+
+template 
+DI
+zl ()
+{
+  auto au = [] () -> DI { return *new auto (true ? yp : throw); }; // { dg-error 
"exception handling disabled" }
+
+  return au ();
+}
+
+auto
+vd ()
+{
+  return zl  ();
+}
diff --git a/gcc/testsuite/g++.dg/template/crash132.C 
b/gcc/testsuite/g++.dg/template/crash132.C
new file mode 100644
index 000..f6f4863e937
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/crash132.C
@@ -0,0 +1,6 @@
+// PR c++/97993
+// { dg-do compile { target c++14 } }
+
+template  T a;
+template  auto foo ();
+struct S decltype (foo ); // { dg-error "" }

base-commit: b46314c78061a5156bac44a317c87d32b00d4295

Re: [PATCH] c++, v3: Implement LWG3396 Clarify point of reference for source_location::current() [PR80780, PR93093]

[Jason Merrill via Gcc-patches]

On 12/2/20 12:35 PM, Jakub Jelinek wrote:

On Wed, Dec 02, 2020 at 10:42:51AM -0500, Jason Merrill via Gcc-patches wrote:

On 12/2/20 7:13 AM, Jakub Jelinek wrote:

On Tue, Dec 01, 2020 at 04:05:22PM -0500, Jason Merrill via Gcc-patches wrote:

Or simpler might be to always defer immediate evaluation of
source_location::current() until genericize time.


That works.
I had to change constexpr.c too so that it temporarily adjusts
current_function_decl from the constexpr evaluation context, but we do the
same already from __builtin_FUNCTION ().

Tested on x86_64-linux and i686-linux, ok for trunk if it passes full
bootstrap/regtest?

For the non-std::source_location::current() immediate evaluation, I'll just
file a PR and put there all details.


Looks like you missed my minor comments within the earlier patch; I should
have mentioned that there were some.  Repeating them below:


Oops, I'm terribly sorry, didn't scroll down beyond the Please.
Implemented now yours and Marek's suggestions.


+
+  tree decl
+= lookup_qualified_name (std_node,
+DECL_NAME (TYPE_NAME (source_location)),
+LOOK_want::TYPE, tf_none);
+  return TYPE_NAME (source_location) == decl;


Why not TYPE_CONTEXT (source_location) == std_node?  I don't think we need
to do name lookup here.


The point was possible inline namespaces between std and source_location.
But Marek's suggestion to use decl_in_std_namespace_p for that looks
right.

Tested on x86_64-linux, ok for trunk if it passes full
bootstrap/regtest on x86_64-linux and i686-linux?


OK.


2020-12-02  Jakub Jelinek  

LWG3396 Clarify point of reference for source_location::current()
PR c++/80780
PR c++/93093
* cp-tree.h (source_location_current_p): Declare.
* tree.c (source_location_current_p): New function.
* call.c (immediate_invocation_p): New function.
(build_over_call): Use it.
* constexpr.c (cxx_eval_builtin_function_call): Temporarily set
current_function_decl from ctx->call->fundef->decl if any.
* cp-gimplify.c (cp_genericize_r) : Fold calls
to immediate function std::source_location::current ().

* g++.dg/cpp2a/srcloc15.C: New test.
* g++.dg/cpp2a/srcloc16.C: New test.
* g++.dg/cpp2a/srcloc17.C: New test.
* g++.dg/cpp2a/srcloc18.C: New test.

--- gcc/cp/cp-tree.h.jj 2020-12-02 18:05:46.497197545 +0100
+++ gcc/cp/cp-tree.h2020-12-02 18:07:49.395815083 +0100
@@ -7422,6 +7422,7 @@ extern tree bind_template_template_parm
  extern tree array_type_nelts_total(tree);
  extern tree array_type_nelts_top  (tree);
  extern bool array_of_unknown_bound_p  (const_tree);
+extern bool source_location_current_p  (tree);
  extern tree break_out_target_exprs(tree, bool = false);
  extern tree build_ctor_subob_ref  (tree, tree, tree);
  extern tree replace_placeholders  (tree, tree, bool * = NULL);
--- gcc/cp/tree.c.jj2020-12-02 18:05:46.498197533 +0100
+++ gcc/cp/tree.c   2020-12-02 18:27:55.711332497 +0100
@@ -2993,6 +2993,32 @@ array_type_nelts_total (tree type)
return sz;
  }
  
+/* Return true if FNDECL is std::source_location::current () method.  */

+
+bool
+source_location_current_p (tree fndecl)
+{
+  gcc_checking_assert (TREE_CODE (fndecl) == FUNCTION_DECL
+  && DECL_IMMEDIATE_FUNCTION_P (fndecl));
+  if (DECL_NAME (fndecl) == NULL_TREE
+  || TREE_CODE (TREE_TYPE (fndecl)) != FUNCTION_TYPE
+  || TREE_CODE (TREE_TYPE (TREE_TYPE (fndecl))) != RECORD_TYPE
+  || DECL_CONTEXT (fndecl) != TREE_TYPE (TREE_TYPE (fndecl))
+  || !id_equal (DECL_NAME (fndecl), "current"))
+return false;
+
+  tree source_location = DECL_CONTEXT (fndecl);
+  if (TYPE_NAME (source_location) == NULL_TREE
+  || TREE_CODE (TYPE_NAME (source_location)) != TYPE_DECL
+  || TYPE_IDENTIFIER (source_location) == NULL_TREE
+  || !id_equal (TYPE_IDENTIFIER (source_location),
+   "source_location")
+  || !decl_in_std_namespace_p (TYPE_NAME (source_location)))
+return false;
+
+  return true;
+}
+
  struct bot_data
  {
splay_tree target_remap;
--- gcc/cp/call.c.jj2020-12-02 14:42:46.533121244 +0100
+++ gcc/cp/call.c   2020-12-02 18:27:18.607747289 +0100
@@ -8540,6 +8540,25 @@ build_trivial_dtor_call (tree instance,
 instance, clobber);
  }
  
+/* Return true if a call to FN with number of arguments NARGS

+   is an immediate invocation.  */
+
+static bool
+immediate_invocation_p (tree fn, int nargs)
+{
+  return (TREE_CODE (fn) == FUNCTION_DECL
+ && DECL_IMMEDIATE_FUNCTION_P (fn)
+ && cp_unevaluated_operand == 0
+ && (current_function_decl == NULL_TREE
+ || !DECL_IMMEDIATE_FUNCTION_P (current_function_decl))
+ && (current_binding_level->kind != sk_function_parms
+ || !current_binding_level->immediate_f

Re: [PATCH] Avoid atomic for guard acquire when that is expensive

[Jason Merrill via Gcc-patches]

On 12/1/20 1:28 PM, Bernd Edlinger wrote:

On 11/24/20 11:10 PM, Jason Merrill wrote:

On 11/22/20 3:05 AM, Bernd Edlinger wrote:

Hi,

this avoids the need to use -fno-threadsafe-statics on
arm-none-eabi or working around that problem by supplying
a dummy __sync_synchronize function which might
just lead to silent code failure of the worst kind
(non-reproducable, racy) at runtime, as was pointed out
on previous discussions here.

When the atomic access involves a call to __sync_synchronize
it is better to call __cxa_guard_acquire unconditionally,
since it handles the atomics too, or is a non-threaded
implementation when there is no gthread support for this target.

This fixes also a bug for the ARM EABI big-endian target,
that is, previously the wrong bit was checked.


Instead of a new target macro, can't you follow 
fold_builtin_atomic_always_lock_free/can_atomic_load_p?


Yes, thanks, that should work too.
Would you like this better?



+is_atomic_expensive_p (machine_mode mode)
+{
+  if (!flag_inline_atomics)
+return false;


Why not true?


+  if (!can_compare_and_swap_p (mode, false) || !can_atomic_load_p (mode))
+return false;


This also seems backwards; I'd think we want to return false if either 
of those tests are true.  Or maybe just can_atomic_load_p, and not 
bother about compare-and-swap.



+  tree type = targetm.cxx.guard_mask_bit ()
+ ? TREE_TYPE (guard) : char_type_node;
+
+  if (is_atomic_expensive_p (TYPE_MODE (type)))
+   guard = integer_zero_node;
+  else
+   guard = build_atomic_load_type (guard, MEMMODEL_ACQUIRE, type);


It should still work to load a single byte, it just needs to be the 
least-significant byte.  And this isn't an EABI issue; it looks like the 
non-EABI code is also broken for big-endian targets, both the atomic 
load and the normal load in get_guard_bits.


Jason

Re: [committed] adjust expected warnings to reflect max-object-size

[Jeff Law via Gcc-patches]

On 12/2/20 11:43 AM, Martin Sebor wrote:
> The r11-5622 change to -Wformat-overflow switched the warning
> to using the maximm object size limit used by the other overflow
> and out of bounds access warnings like -Wstringop-overflow.
> That in turn exposed a subtle off-by-one mistake in the former
> that was also reflected in a few tests, seen in ILP32 but not
> in LP64.  I just committed the attached patch adjusts the tests
> to correctly reflect the limit.  These mistakes would be easier
> to avoid if if were possible to lower the max object size limit
> from PTRDIFF_MAX - 1 to a value that's independent of the target
> as in the following patch:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559450.html
>
> Martin
>
> gcc-sprintf-max-objsize.diff
>
> commit 0a7dc4b6440faa8cd57c630f1e394a719469c399
> Author: Martin Sebor 
> Date:   Wed Dec 2 11:29:11 2020 -0700
>
> Adjust test to avoid ILP32 failures after r11-5622 (PR middle-end/97373)
> 
> gcc/testsuite/ChangeLog:
> * gcc.dg/tree-ssa/builtin-sprintf-warn-1.c: Adjust expected 
> warnings
> to correctly reflect the maximum object size.
> * gcc.dg/tree-ssa/builtin-sprintf-warn-11.c: Same.
> * gcc.dg/tree-ssa/builtin-sprintf-warn-18.c: Same.
Thanks!  I'll turn the tester back on  :-)  If you don't hear from me
over the next few hours, then assume all is well again.


jeff

Re: [PATCH] dwarf2out: Fix up add_scalar_info not to create invalid DWARF

[Jeff Law via Gcc-patches]

On 12/2/20 9:48 AM, Jakub Jelinek via Gcc-patches wrote:
> Hi!
>
> As discussed in https://sourceware.org/bugzilla/show_bug.cgi?id=26987 ,
> for very large bounds (which don't fit into HOST_WIDE_INT) GCC emits invalid
> DWARF.
> In DWARF2, DW_AT_{lower,upper}_bound were constant reference class.
> In DWARF3 they are block constant reference and the
> Static and Dynamic Properties of Types
> chapter says:
> "For a block, the value is interpreted as a DWARF expression; evaluation of 
> the expression
> yields the value of the attribute."
> In DWARF4/5 they are constant exprloc reference class.
> Now, for add_AT_wide we use DW_FORM_data16 (valid in constant class)
> when -gdwarf-5, but otherwise just use DW_FORM_block1, which is not constant
> class, but block.
> For DWARF3 this means emitting clearly invalid DWARF, because the
> DW_FORM_block1 should contain a DWARF expression, not random bytes
> containing the constant directly.
> For DWARF2/DWARF4/5 it could be considered a GNU extension, but a very badly
> designed one when it means something different in DWARF3.
>
> The following patch uses add_AT_wide only if we know we'll be using
> DW_FORM_data16, and otherwise wastes 2 extra bytes and emits in there
> DW_OP_implicit_value  before the constant.
>
> Ok for trunk if it passes bootstrap/regtest?
>
> 2020-12-02  Jakub Jelinek  
>
>   * dwarf2out.c (add_scalar_info): Only use add_AT_wide for 128-bit
>   constants and only in dwarf-5 or later, where DW_FORM_data16 is
>   available.  Otherwise use DW_FORM_block*/DW_FORM_exprloc with
>   DW_OP_implicit_value to describe the constant.
OK.
jeff

[committed] adjust expected warnings to reflect max-object-size

[Martin Sebor via Gcc-patches]

The r11-5622 change to -Wformat-overflow switched the warning
to using the maximm object size limit used by the other overflow
and out of bounds access warnings like -Wstringop-overflow.
That in turn exposed a subtle off-by-one mistake in the former
that was also reflected in a few tests, seen in ILP32 but not
in LP64.  I just committed the attached patch adjusts the tests
to correctly reflect the limit.  These mistakes would be easier
to avoid if if were possible to lower the max object size limit
from PTRDIFF_MAX - 1 to a value that's independent of the target
as in the following patch:

https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559450.html

Martin
commit 0a7dc4b6440faa8cd57c630f1e394a719469c399
Author: Martin Sebor 
Date:   Wed Dec 2 11:29:11 2020 -0700

Adjust test to avoid ILP32 failures after r11-5622 (PR middle-end/97373)

gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/builtin-sprintf-warn-1.c: Adjust expected warnings
to correctly reflect the maximum object size.
* gcc.dg/tree-ssa/builtin-sprintf-warn-11.c: Same.
* gcc.dg/tree-ssa/builtin-sprintf-warn-18.c: Same.

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c b/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c
index a94d123b34c..3d238c4c3ed 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c
@@ -112,17 +112,24 @@ void test_sprintf_c_const (void)
   T ( 3, "%1$c%2$c", '1', '2');
 
   /* Verify that a warning is issued for exceeding INT_MAX bytes and
- not otherwise.  */
-  T (-1, "%*c",  INT_MAX - 1, '1');
-  T (-1, "%*c",  INT_MAX, '1');
-  T (-1, "X%*c", INT_MAX - 1, '1');
-  T (-1, "X%*c", INT_MAX, '1'); /* { dg-warning "directive output of \[0-9\]+ bytes causes result to exceed .INT_MAX." } */
-
-  T (-1, "%*c%*c", INT_MAX - 1, '1', INT_MAX - 1, '2'); /* { dg-warning "directive output of \[0-9\]+ bytes causes result to exceed .INT_MAX." } */
-
-  T (-1, "%*cX", INT_MAX - 2, '1');
-  T (-1, "%*cX", INT_MAX - 1, '1');
-  T (-1, "%*cX", INT_MAX, '1'); /* { dg-warning "output of \[0-9\]+ bytes causes result to exceed .INT_MAX." } */
+ not otherwise.  In ILP32 where the maximum object size is INT_MAX - 1
+ bytes, the calls are diagnosed due to the overflow.  */
+  T (-1, "%*c",  INT_MAX - 2, '1');
+  T (-1, "%*c",  INT_MAX - 1, '1'); /* { dg-warning "writing a terminating nul past the end" "ilp32" { target ilp32 } } */
+  T (-1, "%*c",  INT_MAX, '1'); /* { dg-warning "writing 2147483647 bytes into a region of size 2147483646" "il32" { target ilp32 } } */
+  T (-1, "X%*c", INT_MAX - 3, '1');
+  T (-1, "X%*c", INT_MAX - 1, '1'); /* { dg-warning "writing 2147483646 bytes into a region of size 2147483645" "ilp32" { target ilp32 } } */
+  T (-1, "X%*c", INT_MAX, '1'); /* { dg-warning "directive output of \[0-9\]+ bytes causes result to exceed .INT_MAX." "lp64" { target lp64 } } */
+/* { dg-warning "directive writing 2147483647 bytes into a region of size 2147483645." "lp32" { target ilp32 } .-1 } */
+
+  T (-1, "%*c%*c", INT_MAX - 1, '1', INT_MAX - 1, '2'); /* { dg-warning "directive output of \[0-9\]+ bytes causes result to exceed .INT_MAX." "lp64" { target lp64 } } */
+  /* { dg-warning "directive writing 2147483646 bytes into a region of size 0" "ilp32" { target ilp32 } .-1 } */
+
+  T (-1, "%*cX", INT_MAX - 3, '1');
+  T (-1, "%*cX", INT_MAX - 2, '1'); /* { dg-warning "writing a terminating nul past the end of the destination" "ilp32" { target ilp32} } */
+  T (-1, "%*cX", INT_MAX - 1, '1'); /* { dg-warning "'X' directive writing 1 byte into a region of size 0" "ilp32" { target ilp32 } } */
+  T (-1, "%*cX", INT_MAX, '1'); /* { dg-warning "output of \[0-9\]+ bytes causes result to exceed .INT_MAX." "lp64" { target lp64 } } */
+  /* { dg-warning "directive writing 2147483647 bytes into a region of size 2147483646" "ilp32" { target ilp32 } .-1 } */
 }
 
 /* Verify that no warning is issued for calls that write into a flexible
@@ -287,9 +294,11 @@ void test_sprintf_chk_s_const (void)
 
   /* Verify that output in excess of INT_MAX bytes is diagnosed even
  when the size of the destination object is unknown.  */
-  T (-1, "%*s",  INT_MAX - 1, "");
-  T (-1, "%*s",  INT_MAX, "");
-  T (-1, "X%*s", INT_MAX, ""); /* { dg-warning "directive output of \[0-9\]+ bytes causes result to exceed .INT_MAX." } */
+  T (-1, "%*s",  INT_MAX - 2, "");
+  T (-1, "%*s",  INT_MAX - 1, ""); /* { dg-warning "writing a terminating nul past the end of the destination" "ilp32" { target ilp32 } } */
+  T (-1, "%*s",  INT_MAX, ""); /* { dg-warning "directive writing 2147483647 bytes into a region of size 2147483646" "ilp32" { target ilp32 } } */
+  T (-1, "X%*s", INT_MAX, ""); /* { dg-warning "directive output of \[0-9\]+ bytes causes result to exceed .INT_MAX." "lp64" { target lp64 } } */
+  /* { dg-warning "directive

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

[Jeff Law via Gcc-patches]

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.

jeff

Re: options.exp: unsupport tests that depend on missing language

[Jeff Law via Gcc-patches]

On 12/1/20 11:15 PM, Alexandre Oliva wrote:
> There's a help.exp test that checks that the help message for
> -Wabsolute-value mentions it's available in C and ObjC, when compiling
> a C++ program.
>
> However, if GCC is built with the C++ language disabled, the
> .cc file is compiled as C, and the message [available in C...] becomes
> [disabled] instead, because that's the default for the flag in C.
>
> I suppose it might also be possible to disable the C language, and
> then the multitude of help.exp tests that name c as the source
> language will fail.
>
> This patch avoids these fails: it detects the message "compiler not
> installed" in the compiler output, and bails out as "unsupported".
>
> Regstrapped on x86_64-linux-gnu; also tested with a cross compiler to
> arm-eabi with C++ disabled.  Ok to install?
>
>
> for  gcc/testsuite/ChangeLog
>
>   * lib/options.exp (check_for_options_with_filter): Detect
>   unavailable compiler for the selected language, and bail out
>   as unsupported.
OK
jeff

Re: [GCC 10 PATCH] value-range: Give up on POLY_INT_CST ranges [PR97457]

[Jeff Law via Gcc-patches]

On 12/2/20 9:27 AM, Richard Sandiford via Gcc-patches wrote:
> This is a gcc-10 version of:
>
> Richard Sandiford  writes:
>> This PR shows another problem with calculating value ranges for
>> POLY_INT_CSTs.  We have:
>>
>>   ivtmp_76 = ASSERT_EXPR  POLY_INT_CST [9, 4294967294]>
>>
>> where the VQ coefficient is unsigned but is effectively acting
>> as a negative number.  We wrongly give the POLY_INT_CST the range:
>>
>>   [9, INT_MAX]
>>
>> and things go downhill from there: later iterations of the unrolled
>> epilogue are wrongly removed as dead.
>>
>> I guess this is the final nail in the coffin for doing VRP on
>> POLY_INT_CSTs.  For other similarly exotic testcases we could have
>> overflow for any coefficient, not just those that could be treated
>> as contextually negative.
>>
>> Testing TYPE_OVERFLOW_UNDEFINED doesn't seem like an option because we
>> couldn't handle warn_strict_overflow properly.  At this stage we're
>> just recording a range that might or might not lead to strict-overflow
>> assumptions later.
>>
>> It still feels like we should be able to do something here, but for
>> now removing the code seems safest.  It's also telling that there
>> are no testsuite failures on SVE from doing this.
>>
>> Tested on aarch64-linux-gnu (with and without SVE) and
>> x86_64-linux-gnu.  OK for trunk and backports?
>>
>> Richard
> The backport ended up looking a bit different.  Rather than fall through
> to the later VR_VARYING code (which asserts for certain min and max values),
> this code just moves directly to varying.
Yea, lots has changed in this area over the last year.


>
> Tested on aarch64-linux-gnu, aarch64_be-elf, arm-linux-gnueabihf,
> armeb-elf and x86_64-linux-gnu.  OK for GCC 10?
>
> Richard
>
>
> gcc/
>   PR tree-optimization/97457
>   * value-range.cc (irange::set): Don't decay POLY_INT_CST ranges
>   to integer ranges.
>
> gcc/testsuite/
>   PR tree-optimization/97457
>   * gcc.dg/vect/pr97457.c: New test.
Backport is fine.

jeff

Re: [patch][rtl-optimization][i386][pr97777] Fix a reg-stack df maintenance bug triggered by zero-call-used-regs pass.

[Jeff Law via Gcc-patches]

On 12/2/20 9:32 AM, Qing Zhao wrote:
>
>> So we are clearing the x87 registers with that option.  Hence the change
>> in reg-stack behavior.  I'm a bit surprised by this as I don't see
>> clearing the x87 registers as particularly helpful from a security
>> standpoint.  But I haven't followed that discussion closely.
> Even with the option -fzero-call-used-regs=used-gpr (without clearing any x87 
> registers), 
> We have the same compiler time error. 
>
> The first thing that the new pass “zero_call_used_regs” does is:
>
> df_analyze();
OK.  So that's the key issue, until now nothing has really cared about
the DF state after reg-stack, but the pass to zero registers does.  I
had the order backwards in my head with register clearing happening
before regstack.  Hence my significant confusion about why things were
suddenly going wrong.

The patch is OK.  Thanks for patiently walking me through this.

jeff

Re: introduce overridable clear_cache emitter

[Jeff Law via Gcc-patches]

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.
>   * config/vxcache.c: Remove.
OK
jeff

Re: [PATCH] i386: Optimize vpsubusw compared to 0 into vpcmpleuw or vpcmpnltuw[PR96906]

[Jakub Jelinek via Gcc-patches]

On Tue, Dec 01, 2020 at 12:49:03PM +0800, Hongtao Liu via Gcc-patches wrote:
> +bool neq_p = INTVAL (operands[4]) >> 2;
> +/* LE: 2, NLT: 5, NLE: 6, LT: 1  */
> +rtx cmp_predicate = neq_p ? GEN_INT (6) : GEN_INT (2);
> +if (MEM_P (operands[1]))
> +  {
> + std::swap (operands[1], operands[2]);
> + cmp_predicate = neq_p ? GEN_INT (1) : GEN_INT (5);
> +  }
> +emit_insn (gen__ucmp3 (operands[0], operands[1],
> + operands[2], cmp_predicate));

I'd suggest instead:
+/* LE: 2, NLT: 5, NLE: 6, LT: 1  */
+int cmp_predicate = 2; /* LE  */
+if (MEM_P (operands[1]))
+  {
+   std::swap (operands[1], operands[2]);
+   cmp_predicate = 5; /* NLT (GE)  */
+  }
+if ((INTVAL (operands[4]) & 4) != 0)
+  cmp_predictate ^= 4; /* Invert the comparison to NLE (GT) or LT.  */
+emit_insn (gen__ucmp3 (operands[0], operands[1], operands[2],
+GEN_INT (cmp_predicate)));
so that you don't create the rtx CONST_INTs in 4 places and don't do that
unnecessarily when you will need another constant.

Otherwise LGTM, thanks.

Jakub

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

[Richard Sandiford via Gcc-patches]

Przemyslaw Wirkus  writes:
> New +flagm (Condition flag manipulation from Armv8.4-A) feature option for
> -march command line option.
>
> Please note that FLAGM stays an Armv8.4-A feature but now can be
> assigned to other architectures or CPUs.
>
> OK for master?
>
> 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.

Richard

Re: [PATCH] Sync .gitignore with binutils-gdb

[Jeff Law via Gcc-patches]

On 12/2/20 7:44 AM, Simon Marchi via Gcc-patches wrote:
> Bring in a few lines that are in binutils-gdb's .gitignore but not
> gcc's.
>
> Note that I don't have push access to gcc, so I would appreciate
> if somebody could push it for me.
>
> ChangeLog:
>
>   * .gitignore: Sync with binutils-gdb.
Pushed to the trunk.

THanks,
jeff

Re: Go patch committed: Don't advance past unexpected semicolon

[Ian Lance Taylor via Gcc-patches]

On Wed, Dec 2, 2020 at 7:47 AM Ian Lance Taylor  wrote:
>
> This Go frontend patch changes the parser to not advance past an
> unexpected semicolon, after it gives an error.  We've already read the
> unexpected semicolon, so advancing again causes us to skip the next
> token, causing future errors to be out of sync.  Bootstrapped and ran
> Go testsuite on x86_64-pc-linux-gnu.  Committed to mainline.

This requires updating a test, which I forgot to do.  Committed this
patch to mainline.

Ian
55ba4ab02661bf4710bd7e58ed0f1b99922cabe9
diff --git a/gcc/testsuite/go.test/test/syntax/semi6.go 
b/gcc/testsuite/go.test/test/syntax/semi6.go
index c1e1cc363a2..9bc730d43d6 100644
--- a/gcc/testsuite/go.test/test/syntax/semi6.go
+++ b/gcc/testsuite/go.test/test/syntax/semi6.go
@@ -1,13 +1,11 @@
 // errorcheck
 
-// 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.
 
 package main
 
-type T // ERROR "unexpected semicolon or newline in type declaration"
-{
-
-
+type T1// ERROR "newline in type declaration"
 
+type T2 /* // ERROR "(semicolon.*|EOF) in type declaration" */
\ No newline at end of file

[PATCH] c++, v3: Implement LWG3396 Clarify point of reference for source_location::current() [PR80780, PR93093]

[Jakub Jelinek via Gcc-patches]

On Wed, Dec 02, 2020 at 10:42:51AM -0500, Jason Merrill via Gcc-patches wrote:
> On 12/2/20 7:13 AM, Jakub Jelinek wrote:
> > On Tue, Dec 01, 2020 at 04:05:22PM -0500, Jason Merrill via Gcc-patches 
> > wrote:
> > > Or simpler might be to always defer immediate evaluation of
> > > source_location::current() until genericize time.
> > 
> > That works.
> > I had to change constexpr.c too so that it temporarily adjusts
> > current_function_decl from the constexpr evaluation context, but we do the
> > same already from __builtin_FUNCTION ().
> > 
> > Tested on x86_64-linux and i686-linux, ok for trunk if it passes full
> > bootstrap/regtest?
> > 
> > For the non-std::source_location::current() immediate evaluation, I'll just
> > file a PR and put there all details.
> 
> Looks like you missed my minor comments within the earlier patch; I should
> have mentioned that there were some.  Repeating them below:

Oops, I'm terribly sorry, didn't scroll down beyond the Please.
Implemented now yours and Marek's suggestions.

> > +
> > +  tree decl
> > += lookup_qualified_name (std_node,
> > +DECL_NAME (TYPE_NAME (source_location)),
> > +LOOK_want::TYPE, tf_none);
> > +  return TYPE_NAME (source_location) == decl;
> 
> Why not TYPE_CONTEXT (source_location) == std_node?  I don't think we need
> to do name lookup here.

The point was possible inline namespaces between std and source_location.
But Marek's suggestion to use decl_in_std_namespace_p for that looks
right.

Tested on x86_64-linux, ok for trunk if it passes full
bootstrap/regtest on x86_64-linux and i686-linux?

2020-12-02  Jakub Jelinek  

LWG3396 Clarify point of reference for source_location::current()
PR c++/80780
PR c++/93093
* cp-tree.h (source_location_current_p): Declare.
* tree.c (source_location_current_p): New function.
* call.c (immediate_invocation_p): New function.
(build_over_call): Use it.
* constexpr.c (cxx_eval_builtin_function_call): Temporarily set
current_function_decl from ctx->call->fundef->decl if any.
* cp-gimplify.c (cp_genericize_r) : Fold calls
to immediate function std::source_location::current ().

* g++.dg/cpp2a/srcloc15.C: New test.
* g++.dg/cpp2a/srcloc16.C: New test.
* g++.dg/cpp2a/srcloc17.C: New test.
* g++.dg/cpp2a/srcloc18.C: New test.

--- gcc/cp/cp-tree.h.jj 2020-12-02 18:05:46.497197545 +0100
+++ gcc/cp/cp-tree.h2020-12-02 18:07:49.395815083 +0100
@@ -7422,6 +7422,7 @@ extern tree bind_template_template_parm
 extern tree array_type_nelts_total (tree);
 extern tree array_type_nelts_top   (tree);
 extern bool array_of_unknown_bound_p   (const_tree);
+extern bool source_location_current_p  (tree);
 extern tree break_out_target_exprs (tree, bool = false);
 extern tree build_ctor_subob_ref   (tree, tree, tree);
 extern tree replace_placeholders   (tree, tree, bool * = NULL);
--- gcc/cp/tree.c.jj2020-12-02 18:05:46.498197533 +0100
+++ gcc/cp/tree.c   2020-12-02 18:27:55.711332497 +0100
@@ -2993,6 +2993,32 @@ array_type_nelts_total (tree type)
   return sz;
 }
 
+/* Return true if FNDECL is std::source_location::current () method.  */
+
+bool
+source_location_current_p (tree fndecl)
+{
+  gcc_checking_assert (TREE_CODE (fndecl) == FUNCTION_DECL
+  && DECL_IMMEDIATE_FUNCTION_P (fndecl));
+  if (DECL_NAME (fndecl) == NULL_TREE
+  || TREE_CODE (TREE_TYPE (fndecl)) != FUNCTION_TYPE
+  || TREE_CODE (TREE_TYPE (TREE_TYPE (fndecl))) != RECORD_TYPE
+  || DECL_CONTEXT (fndecl) != TREE_TYPE (TREE_TYPE (fndecl))
+  || !id_equal (DECL_NAME (fndecl), "current"))
+return false;
+
+  tree source_location = DECL_CONTEXT (fndecl);
+  if (TYPE_NAME (source_location) == NULL_TREE
+  || TREE_CODE (TYPE_NAME (source_location)) != TYPE_DECL
+  || TYPE_IDENTIFIER (source_location) == NULL_TREE
+  || !id_equal (TYPE_IDENTIFIER (source_location),
+   "source_location")
+  || !decl_in_std_namespace_p (TYPE_NAME (source_location)))
+return false;
+
+  return true;
+}
+
 struct bot_data
 {
   splay_tree target_remap;
--- gcc/cp/call.c.jj2020-12-02 14:42:46.533121244 +0100
+++ gcc/cp/call.c   2020-12-02 18:27:18.607747289 +0100
@@ -8540,6 +8540,25 @@ build_trivial_dtor_call (tree instance,
 instance, clobber);
 }
 
+/* Return true if a call to FN with number of arguments NARGS
+   is an immediate invocation.  */
+
+static bool
+immediate_invocation_p (tree fn, int nargs)
+{
+  return (TREE_CODE (fn) == FUNCTION_DECL
+ && DECL_IMMEDIATE_FUNCTION_P (fn)
+ && cp_unevaluated_operand == 0
+ && (current_function_decl == NULL_TREE
+ || !DECL_IMMEDIATE_FUNCTION_P (current_function_decl))
+ && (current_binding_level->kind != sk_function_parms
+ || !current_b

[PATCH] dwarf2out: Fix up add_scalar_info not to create invalid DWARF

[Jakub Jelinek via Gcc-patches]

Hi!

As discussed in https://sourceware.org/bugzilla/show_bug.cgi?id=26987 ,
for very large bounds (which don't fit into HOST_WIDE_INT) GCC emits invalid
DWARF.
In DWARF2, DW_AT_{lower,upper}_bound were constant reference class.
In DWARF3 they are block constant reference and the
Static and Dynamic Properties of Types
chapter says:
"For a block, the value is interpreted as a DWARF expression; evaluation of the 
expression
yields the value of the attribute."
In DWARF4/5 they are constant exprloc reference class.
Now, for add_AT_wide we use DW_FORM_data16 (valid in constant class)
when -gdwarf-5, but otherwise just use DW_FORM_block1, which is not constant
class, but block.
For DWARF3 this means emitting clearly invalid DWARF, because the
DW_FORM_block1 should contain a DWARF expression, not random bytes
containing the constant directly.
For DWARF2/DWARF4/5 it could be considered a GNU extension, but a very badly
designed one when it means something different in DWARF3.

The following patch uses add_AT_wide only if we know we'll be using
DW_FORM_data16, and otherwise wastes 2 extra bytes and emits in there
DW_OP_implicit_value  before the constant.

Ok for trunk if it passes bootstrap/regtest?

2020-12-02  Jakub Jelinek  

* dwarf2out.c (add_scalar_info): Only use add_AT_wide for 128-bit
constants and only in dwarf-5 or later, where DW_FORM_data16 is
available.  Otherwise use DW_FORM_block*/DW_FORM_exprloc with
DW_OP_implicit_value to describe the constant.

--- gcc/dwarf2out.c.jj  2020-12-01 19:51:25.033066458 +0100
+++ gcc/dwarf2out.c 2020-12-02 17:29:45.042576547 +0100
@@ -20775,12 +20775,23 @@ add_scalar_info (dw_die_ref die, enum dw
  else
add_AT_int (die, attr, TREE_INT_CST_LOW (value));
}
-  else
+  else if (dwarf_version >= 5
+  && TREE_INT_CST_LOW (TYPE_SIZE (TREE_TYPE (value))) == 128)
/* Otherwise represent the bound as an unsigned value with
   the precision of its type.  The precision and signedness
   of the type will be necessary to re-interpret it
   unambiguously.  */
add_AT_wide (die, attr, wi::to_wide (value));
+  else
+   {
+ rtx v = immed_wide_int_const (wi::to_wide (value),
+   TYPE_MODE (TREE_TYPE (value)));
+ dw_loc_descr_ref loc
+   = loc_descriptor (v, TYPE_MODE (TREE_TYPE (value)),
+ VAR_INIT_STATUS_INITIALIZED);
+ if (loc)
+   add_AT_loc (die, attr, loc);
+   }
   return;
 }
 

Jakub

[committed] libstdc++: Use libatomic for tests on all 32-bit powerpc targets

[Jonathan Wakely via Gcc-patches]

In addition to the existing powerpc targets, powerpc64 needs libatomic
for 64-bit atomics when testing the 32-bit multilib with -m32. Adjust
the existing target checks to match all 32-bit powerpc targets, but not
64-bit ones.

libstdc++-v3/ChangeLog:

* testsuite/lib/dg-options.exp (add_options_for_libatomic):
Replace powerpc-ibm-aix* and powerpc*-*-darwin* with check for
powerpc && ilp32.

Tested powerpc64-linux (with both -m32 and -m64) and
powerpc-ibm-aix7.2.0.0 (with both -maix32 and -maix64)
and powerpc64le-linux (-m64 only).

Committed to trunk.

commit dd053eea0be4f3ec8b76fb2e103a13a3977bcf9f
Author: Jonathan Wakely 
Date:   Wed Dec 2 16:37:56 2020

libstdc++: Use libatomic for tests on all 32-bit powerpc targets

In addition to the existing powerpc targets, powerpc64 needs libatomic
for 64-bit atomics when testing the 32-bit multilib with -m32. Adjust
the existing target checks to match all 32-bit powerpc targets, but not
64-bit ones.

libstdc++-v3/ChangeLog:

* testsuite/lib/dg-options.exp (add_options_for_libatomic):
Replace powerpc-ibm-aix* and powerpc*-*-darwin* with check for
powerpc && ilp32.

diff --git a/libstdc++-v3/testsuite/lib/dg-options.exp 
b/libstdc++-v3/testsuite/lib/dg-options.exp
index d3f61cb5267..0102acf65a2 100644
--- a/libstdc++-v3/testsuite/lib/dg-options.exp
+++ b/libstdc++-v3/testsuite/lib/dg-options.exp
@@ -257,13 +257,14 @@ proc add_options_for_net_ts { flags } {
 return $flags
 }
 
-# Add to FLAGS all the target-specific flags to link to libatomic, if required.
+# Add to FLAGS all the target-specific flags to link to libatomic,
+# if required for atomics on pointers and 64-bit types.
 
 proc add_options_for_libatomic { flags } {
 if { [istarget hppa*-*-hpux*]
-|| [istarget powerpc-ibm-aix*]
-|| [istarget powerpc*-*-darwin*]
-|| [istarget riscv*-*-*] } {
+|| ([istarget powerpc*-*-*] && [check_effective_target_ilp32])
+|| [istarget riscv*-*-*]
+   } {
return "$flags -L../../libatomic/.libs -latomic"
 }
 return $flags

Re: [PATCH][GCC10] arm: Fix unwanted fall-through in arm.c

[Andrea Corallo via Gcc-patches]

Andrea Corallo via Gcc-patches  writes:

> Hi all,
>
> this is to fix in GCC 10 the incomplete backport done by 1aabb312f of
> what at the time I fixed on master with dd019ef07.
>
> Regtested and bootstraped on arm-linux-gnueabihf.
>
> I guess should be under the obvious rule but prefer to ask, okay for
> gcc-10?
>
> Thanks
>
>   Andrea

Adding references to the two mentioned patches for clarity.

Original patch (1aabb312f)



Backport (dd019ef07)



  Andrea

Re: [patch][rtl-optimization][i386][pr97777] Fix a reg-stack df maintenance bug triggered by zero-call-used-regs pass.

[Qing Zhao via Gcc-patches]

> On Dec 1, 2020, at 6:16 PM, Jeff Law  wrote:
 From c2573c6c8552b7b4c2eedb0684ce48b5c11436ec Mon Sep 17 00:00:00 2001
 From: qing zhao 
 Date: Thu, 19 Nov 2020 16:46:50 +0100
 Subject: [PATCH] rtl-optimization: Fix data flow maintenance bug in
 reg-stack.c [pr9]
 
 reg-stack pass does not maintain the data flow information correctly.
 call df_insn_rescan_all after the transformation is done.
 
gcc/
 PR rtl-optimization/9
 * reg-stack.c (rest_of_handle_stack_regs): call
 df_insn_rescan_all if reg_to_stack return true.
 
 gcc/testsuite/
 PR rtl-optimization/9
 * gcc.target/i386/pr9.c: New test.
>>> I'd like to see more analysis here.
>>> 
>>> ie, precisely what data is out of date and why?
>> 
>> For the simple testing case, what happened is, for the insn #6:
>> 
>> (gdb) call debug_rtx(insn)
>> (insn 6 26 7 2 (set (reg:XF 8 st [84])
>> (reg:XF 9 st(1) [85])) "t.c":4:10 134 {*movxf_internal}
>>  (expr_list:REG_EQUAL (const_double:XF 0.0 [0x0.0p+0])
>> (nil)))
>> 
>> After the following statement in reg-stack.c:
>>3080   control_flow_insn_deleted |= subst_stack_regs (insn,
>> ®stack);
>> 
>> This insn # 6 becomes:
>> (gdb) call debug_rtx(insn)
>> (insn 6 26 7 2 (set (reg:XF 8 st)
>> (reg:XF 8 st)) "t.c":4:10 134 {*movxf_internal}
>>  (expr_list:REG_EQUAL (const_double:XF 0.0 [0x0.0p+0])
>> (nil)))
>> 
>> However, there is no any df maintenance routine (for example,
>> df_insn_rescan, etc) is called for this changed insn.
> So we are clearing the x87 registers with that option.  Hence the change
> in reg-stack behavior.  I'm a bit surprised by this as I don't see
> clearing the x87 registers as particularly helpful from a security
> standpoint.  But I haven't followed that discussion closely.

Even with the option -fzero-call-used-regs=used-gpr (without clearing any x87 
registers), 
We have the same compiler time error. 

The first thing that the new pass “zero_call_used_regs” does is:

df_analyze();

And the compiler error happens inside this call. 

From the following passes list:

  NEXT_PASS (pass_stack_regs);
  PUSH_INSERT_PASSES_WITHIN (pass_stack_regs)
  NEXT_PASS (pass_split_before_regstack);
  NEXT_PASS (pass_stack_regs_run);
  POP_INSERT_PASSES ()
  POP_INSERT_PASSES ()
  NEXT_PASS (pass_late_compilation);
  PUSH_INSERT_PASSES_WITHIN (pass_late_compilation)
  NEXT_PASS (pass_zero_call_used_regs);
  NEXT_PASS (pass_compute_alignments);
  NEXT_PASS (pass_variable_tracking);
  NEXT_PASS (pass_free_cfg);
  NEXT_PASS (pass_machine_reorg);
  NEXT_PASS (pass_cleanup_barriers);
  NEXT_PASS (pass_delay_slots);
  NEXT_PASS (pass_split_for_shorten_branches);
  NEXT_PASS (pass_convert_to_eh_region_ranges);
  NEXT_PASS (pass_shorten_branches);
  NEXT_PASS (pass_set_nothrow_function_flags);
  NEXT_PASS (pass_dwarf2_frame);
  NEXT_PASS (pass_final);

We can see that the new pass “zero_call_used_regs” immediately follows pass 
“stack_regs”.

And all other passes that follows “stack_regs” do not call “df_analyze()”.


> 
>> 
>> As I checked, the transformation for this pass “stack” is quite
>> complicated. In addition to the above register replacement,
>> New insns might be inserted, and control flow might be changed, but
>> for most of the transformations applied in this pass,
>> There is no corresponding df maintenance routine is added for deferred
>> df rescanning.
> But this has been the case essentially for ever with reg-stack.  So
> what's unclear to me is why it's suddenly a problem now.

Previously, without the new pass “zero_call_used_regs”, all the passes 
following “stack_regs”
do not call df_analyze, therefore never expose this bug. 

The new pass “zero_call_used_regs” is the first pass that follows “stack_regs” 
and call “df_analyze”, 
Therefore triggered this old bug.

Instead of adding -fzero-call-used-regs option, if I change final.c as 
following to add “df_analyze” at
The beginning of the pass “pass_compute_alignments”:

qinzhao@gcc10:~/Work/write_gcc/gcc$ git diff final.c
diff --git a/gcc/final.c b/gcc/final.c
index fc9a05e335f..4955fc3fdcb 100644
--- a/gcc/final.c
+++ b/gcc/final.c
@@ -639,6 +639,7 @@ compute_alignments (void)
   basic_block bb;
   align_flags max_alignment;
 
+  df_analyze();
   label_align.truncate (0);
 
   max_labelno = max_label_num ();


We will have the exactly same bug as adding -fzero-call-used-regs:
qinzhao@gcc10:~/Bugs/b_9$ sh t
/home/qinzhao/Install/latest_write/bin/gcc -O -ffinite-math-only -S t.c
during RTL pass: alignments
t.c: In function ‘foo’:
t.c:5:1: internal compiler error: in df_refs_verify, at df-scan.c:3991
5 | }
  | ^
0xc3f98a df_refs_verify
../../write_gcc/gcc/df-scan.c:3991
0xc3fbfb df_insn_refs_verify
../../write_gcc/g

Go patch committed: Reword "declared and not used" error message

[Ian Lance Taylor via Gcc-patches]

This patch to the Go frontend rewords the "declared and not used"
error message.  This is a copy of https://golang.org/cl/203282 in the
gc compiler.

>From the CL 203282 description:

"declared and not used" is technically correct, but might confuse
the user. Switching "and" to "but" will hopefully create the
contrast for the users: they did one thing (declaration), but
not the other --- actually using the variable.

This requires updating a couple of tests in the testsuite to the
versions in the source repo.

Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
to mainline.

Ian
5bd5d85117ce968e68d41a746f917a63ed8e6ae6
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index d6ee8573e92..183e5cae9c9 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-720b8fed93143f284ca04358e1b13c8a3487281e
+6b01f8cdc11d86bd98165c91d6ae101bcf6b9e1a
 
 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/gogo.cc b/gcc/go/gofrontend/gogo.cc
index 93a4a5773a2..a5e4521469b 100644
--- a/gcc/go/gofrontend/gogo.cc
+++ b/gcc/go/gofrontend/gogo.cc
@@ -3744,7 +3744,7 @@ Check_types_traverse::variable(Named_object* named_object)
   && !var->type()->is_error()
   && (init == NULL || !init->is_error_expression())
   && !Lex::is_invalid_identifier(named_object->name()))
-   go_error_at(var->location(), "%qs declared and not used",
+   go_error_at(var->location(), "%qs declared but not used",
named_object->message_name().c_str());
 }
   return TRAVERSE_CONTINUE;
diff --git a/gcc/go/gofrontend/parse.cc b/gcc/go/gofrontend/parse.cc
index 00ac2f8f48c..b1925ed8ccc 100644
--- a/gcc/go/gofrontend/parse.cc
+++ b/gcc/go/gofrontend/parse.cc
@@ -4817,7 +4817,7 @@ Parse::type_switch_body(Label* label, const Type_switch& 
type_switch,
}
}
   if (!used)
-   go_error_at(type_switch.location, "%qs declared and not used",
+   go_error_at(type_switch.location, "%qs declared but not used",
Gogo::message_name(var_name).c_str());
 }
   return statement;
diff --git a/gcc/testsuite/go.test/test/fixedbugs/bug373.go 
b/gcc/testsuite/go.test/test/fixedbugs/bug373.go
index e91f26d6ed0..6b7a312097a 100644
--- a/gcc/testsuite/go.test/test/fixedbugs/bug373.go
+++ b/gcc/testsuite/go.test/test/fixedbugs/bug373.go
@@ -1,6 +1,6 @@
 // errorcheck
 
-// Copyright 2011 The Go Authors.  All rights reserved.
+// Copyright 2011 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.
 
@@ -9,7 +9,7 @@
 package foo
 
 func f(x interface{}) {
-   switch t := x.(type) {  // ERROR "declared and not used"
+   switch t := x.(type) {  // ERROR "declared but not used"
case int:
}
 }
diff --git a/gcc/testsuite/go.test/test/typeswitch2.go 
b/gcc/testsuite/go.test/test/typeswitch2.go
index 6c703076a6f..62c96c8330f 100644
--- a/gcc/testsuite/go.test/test/typeswitch2.go
+++ b/gcc/testsuite/go.test/test/typeswitch2.go
@@ -4,7 +4,7 @@
 // Use of this source code is governed by a BSD-style
 // license that can be found in the LICENSE file.
 
-// Verify that various erroneous type switches are caught be the compiler.
+// Verify that various erroneous type switches are caught by the compiler.
 // Does not compile.
 
 package main
@@ -26,22 +26,12 @@ func whatis(x interface{}) string {
w()
}:
return "rw"
-   case interface {// GCCGO_ERROR "duplicate"
+   case interface {// ERROR "duplicate"
w()
r()
-   }: // GC_ERROR "duplicate"
+   }:
return "wr"
 
}
return ""
 }
-
-func notused(x interface{}) {
-   // The first t is in a different scope than the 2nd t; it cannot
-   // be accessed (=> declared and not used error); but it is legal
-   // to declare it.
-   switch t := 0; t := x.(type) { // ERROR "declared and not used"
-   case int:
-   _ = t // this is using the t of "t := x.(type)"
-   }
-}

c++: RTTI accessors for modules

[Nathan Sidwell]

The module machinery needs to serialize tinfo types and vars by
meaning, not literally.  This adds the necessary pieces to rtti.

gcc/cp/
* cp-tree.h (DECL_TINFO_P): Also for TYPE_DECLs.
(get_tinfo_decl_direct): Declare.
(get_pseudo_tinfo_index, get_pseudo_tinfo_type): Declare.
* rtti.c (get_tinfo_decl_direct): Externalize.
(get_tinfo_desc): Set DECL_TINFO_P on the typedef.
(get_pseudo_tinfo_index, get_pseudo_tinfo_type): New.

pushing to trunk

--
Nathan Sidwell
diff --git i/gcc/cp/cp-tree.h w/gcc/cp/cp-tree.h
index 4eaa10bc7fd..d69110f7ab6 100644
--- i/gcc/cp/cp-tree.h
+++ w/gcc/cp/cp-tree.h
@@ -494,7 +494,7 @@ extern GTY(()) tree cp_global_trees[CPTI_MAX];
4: IDENTIFIER_MARKED (IDENTIFIER_NODEs)
   TREE_HAS_CONSTRUCTOR (in INDIRECT_REF, SAVE_EXPR, CONSTRUCTOR,
 	  CALL_EXPR, or FIELD_DECL).
-  DECL_TINFO_P (in VAR_DECL)
+  DECL_TINFO_P (in VAR_DECL, TYPE_DECL)
   FUNCTION_REF_QUALIFIED (in FUNCTION_TYPE, METHOD_TYPE)
   OVL_LOOKUP_P (in OVERLOAD)
   LOOKUP_FOUND_P (in RECORD_TYPE, UNION_TYPE, ENUMERAL_TYPE, NAMESPACE_DECL)
@@ -3350,7 +3350,8 @@ struct GTY(()) lang_decl {
 
 /* 1 iff VAR_DECL node NODE is a type-info decl.  This flag is set for
both the primary typeinfo object and the associated NTBS name.  */
-#define DECL_TINFO_P(NODE) TREE_LANG_FLAG_4 (VAR_DECL_CHECK (NODE))
+#define DECL_TINFO_P(NODE)			\
+  TREE_LANG_FLAG_4 (TREE_CHECK2 (NODE,VAR_DECL,TYPE_DECL))
 
 /* 1 iff VAR_DECL node NODE is virtual table or VTT.  We forward to
DECL_VIRTUAL_P from the common code, as that has the semantics we
@@ -7025,6 +7026,7 @@ extern GTY(()) vec *unemitted_tinfo_decls;
 
 extern void init_rtti_processing		(void);
 extern tree build_typeid			(tree, tsubst_flags_t);
+extern tree get_tinfo_decl_direct	(tree, tree, int);
 extern tree get_tinfo_decl			(tree);
 extern tree get_typeid(tree, tsubst_flags_t);
 extern tree build_headof			(tree);
@@ -7032,6 +7034,8 @@ extern tree build_dynamic_cast			(location_t, tree, tree,
 		 tsubst_flags_t);
 extern void emit_support_tinfos			(void);
 extern bool emit_tinfo_decl			(tree);
+extern unsigned get_pseudo_tinfo_index		(tree);
+extern tree get_pseudo_tinfo_type		(unsigned);
 
 /* in search.c */
 extern bool accessible_base_p			(tree, tree, bool);
diff --git i/gcc/cp/rtti.c w/gcc/cp/rtti.c
index 887aae31bf6..d6288622246 100644
--- i/gcc/cp/rtti.c
+++ w/gcc/cp/rtti.c
@@ -123,7 +123,6 @@ static GTY (()) vec *tinfo_descs;
 
 static tree ifnonnull (tree, tree, tsubst_flags_t);
 static tree tinfo_name (tree, bool);
-static tree get_tinfo_decl_direct (tree type, tree name, int pseudo_ix);
 static tree build_dynamic_cast_1 (location_t, tree, tree, tsubst_flags_t);
 static tree throw_bad_cast (void);
 static tree throw_bad_typeid (void);
@@ -431,7 +430,7 @@ get_tinfo_decl (tree type)
 /* Get or create a tinfo VAR_DECL directly from the provided information.
The caller must have already checked it is valid to do so.  */
 
-static tree
+tree
 get_tinfo_decl_direct (tree type, tree name, int pseudo_ix)
 {
   /* For a class type, the variable is cached in the type node
@@ -1479,6 +1478,7 @@ get_tinfo_desc (unsigned ix)
   finish_builtin_struct (pseudo_type, pseudo_name, fields, NULL_TREE);
   CLASSTYPE_AS_BASE (pseudo_type) = pseudo_type;
   DECL_CONTEXT (TYPE_NAME (pseudo_type)) = FROB_CONTEXT (global_namespace);
+  DECL_TINFO_P (TYPE_NAME (pseudo_type)) = true;
   xref_basetypes (pseudo_type, /*bases=*/NULL_TREE);
 
   res->type = cp_build_qualified_type (pseudo_type, TYPE_QUAL_CONST);
@@ -1491,6 +1491,36 @@ get_tinfo_desc (unsigned ix)
   return res;
 }
 
+/* Return an identifying index for the pseudo type_info TYPE.
+   We wrote the index at the end of the name, so just scan it from
+   there.  This isn't critical, as it's only on the first use of this
+   type during module stream out.  */
+
+unsigned
+get_pseudo_tinfo_index (tree type)
+{
+  tree name = DECL_NAME (TYPE_NAME (type));
+  unsigned ix = 0, scale = 1;
+  size_t len = IDENTIFIER_LENGTH (name);
+  const char *ptr = IDENTIFIER_POINTER (name) + len;
+
+  for (; *--ptr != '_'; scale *= 10)
+{
+  len--;
+  gcc_checking_assert (len && ISDIGIT (*ptr));
+  ix += (*ptr - '0') * scale;
+}
+
+  gcc_assert (len != IDENTIFIER_LENGTH (name));
+  return ix;
+}
+
+tree
+get_pseudo_tinfo_type (unsigned ix)
+{
+  return get_tinfo_desc (ix)->type;
+}
+
 /* We lazily create the type info types.  */
 
 static void

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

[Richard Sandiford via Gcc-patches]

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?

(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 long long) (x >> 64) != 1)
+__builtin_abort ();
+  return 0;
+}

Go patch committed: Better mixed named/unnamed parameter error

[Ian Lance Taylor via Gcc-patches]

This patch to the Go frontend improves the error message reported for
mixed named and unnamed parameters.  This requires updating a test in
the testsuite to the current version in the source repo.  Bootstrapped
and ran Go testsuite on x86_64-pc-linux-gnu.  Committed to mainline.

Ian
ed281e4a944a8b62e66d160b0910bd2be9ef9330
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index 8cba9aa5a3d..d6ee8573e92 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-81d3afed2b7f7eba4eed4599dfdd10081f67391e
+720b8fed93143f284ca04358e1b13c8a3487281e
 
 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/parse.cc b/gcc/go/gofrontend/parse.cc
index b062a471008..00ac2f8f48c 100644
--- a/gcc/go/gofrontend/parse.cc
+++ b/gcc/go/gofrontend/parse.cc
@@ -995,7 +995,7 @@ Parse::parameter_list(bool* is_varargs)
 }
   if (mix_error)
 {
-  go_error_at(location, "invalid named/anonymous mix");
+  go_error_at(location, "mixed named and unnamed function parameters");
   saw_error = true;
 }
   if (saw_error)
diff --git a/gcc/testsuite/go.test/test/fixedbugs/bug388.go 
b/gcc/testsuite/go.test/test/fixedbugs/bug388.go
index d41f9ea543c..2d508501e07 100644
--- a/gcc/testsuite/go.test/test/fixedbugs/bug388.go
+++ b/gcc/testsuite/go.test/test/fixedbugs/bug388.go
@@ -1,6 +1,6 @@
 // errorcheck
 
-// Copyright 2011 The Go Authors.  All rights reserved.
+// Copyright 2011 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.
 
@@ -9,12 +9,12 @@
 package main
 import "runtime"
 
-func foo(runtime.UintType, i int) {  // ERROR "cannot declare name 
runtime.UintType|named/anonymous mix|undefined identifier"
+func foo(runtime.UintType, i int) {  // ERROR "cannot declare name 
runtime.UintType|mixed named and unnamed|undefined identifier"
println(i, runtime.UintType) // GCCGO_ERROR "undefined identifier"
 }
 
 func bar(i int) {
-   runtime.UintType := i   // ERROR "cannot declare name 
runtime.UintType|non-name on left side|undefined identifier"
+   runtime.UintType := i   // ERROR "non-name 
runtime.UintType|non-name on left side|undefined identifier"
println(runtime.UintType)   // GCCGO_ERROR "invalid use of 
type|undefined identifier"
 }
 

Re: [PATCH v2] IBM Z: Use llihf and oilf to load large immediates into GPRs

[Andreas Krebbel via Gcc-patches]

On 12/2/20 4:08 PM, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux.  Ok for master?
> 
> v1: https://gcc.gnu.org/pipermail/gcc-patches/2020-December/560822.html
> 
> v1 -> v2:
> - Use SYMBOL_REF_P.
> - Fix usage of gcc_assert.
> - Use GEN_INT.
> 
> 
> 
> Currently GCC loads large immediates into GPRs from the literal pool,
> which is not as efficient as loading two halves with llihf and oilf.
> 
> gcc/ChangeLog:
> 
> 2020-11-30  Ilya Leoshkevich  
> 
>   * config/s390/s390-protos.h (s390_const_int_pool_entry_p): New
>   function.
>   * config/s390/s390.c (s390_const_int_pool_entry_p): New
>   function.
>   * config/s390/s390.md: Add define_peephole2 that produces llihf
>   and oilf.
> 
> gcc/testsuite/ChangeLog:
> 
> 2020-11-30  Ilya Leoshkevich  
> 
>   * gcc.target/s390/load-imm64-1.c: New test.
>   * gcc.target/s390/load-imm64-2.c: New test.

Ok. Thanks!

Andreas

[GCC 10 PATCH] value-range: Give up on POLY_INT_CST ranges [PR97457]

[Richard Sandiford via Gcc-patches]

This is a gcc-10 version of:

Richard Sandiford  writes:
> This PR shows another problem with calculating value ranges for
> POLY_INT_CSTs.  We have:
>
>   ivtmp_76 = ASSERT_EXPR  POLY_INT_CST [9, 4294967294]>
>
> where the VQ coefficient is unsigned but is effectively acting
> as a negative number.  We wrongly give the POLY_INT_CST the range:
>
>   [9, INT_MAX]
>
> and things go downhill from there: later iterations of the unrolled
> epilogue are wrongly removed as dead.
>
> I guess this is the final nail in the coffin for doing VRP on
> POLY_INT_CSTs.  For other similarly exotic testcases we could have
> overflow for any coefficient, not just those that could be treated
> as contextually negative.
>
> Testing TYPE_OVERFLOW_UNDEFINED doesn't seem like an option because we
> couldn't handle warn_strict_overflow properly.  At this stage we're
> just recording a range that might or might not lead to strict-overflow
> assumptions later.
>
> It still feels like we should be able to do something here, but for
> now removing the code seems safest.  It's also telling that there
> are no testsuite failures on SVE from doing this.
>
> Tested on aarch64-linux-gnu (with and without SVE) and
> x86_64-linux-gnu.  OK for trunk and backports?
>
> Richard

The backport ended up looking a bit different.  Rather than fall through
to the later VR_VARYING code (which asserts for certain min and max values),
this code just moves directly to varying.

Tested on aarch64-linux-gnu, aarch64_be-elf, arm-linux-gnueabihf,
armeb-elf and x86_64-linux-gnu.  OK for GCC 10?

Richard


gcc/
PR tree-optimization/97457
* value-range.cc (irange::set): Don't decay POLY_INT_CST ranges
to integer ranges.

gcc/testsuite/
PR tree-optimization/97457
* gcc.dg/vect/pr97457.c: New test.

(cherry picked from commit 54ef7701a9dec8c923a12d1983f8a051ba88a7b9)
---
 gcc/testsuite/gcc.dg/vect/pr97457.c | 15 +++
 gcc/value-range.cc  | 29 ++---
 2 files changed, 21 insertions(+), 23 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/vect/pr97457.c

diff --git a/gcc/testsuite/gcc.dg/vect/pr97457.c 
b/gcc/testsuite/gcc.dg/vect/pr97457.c
new file mode 100644
index 000..506ba249b00
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/pr97457.c
@@ -0,0 +1,15 @@
+/* { dg-additional-options "-O3" } */
+
+int a;
+long c;
+signed char d(char e, char f) { return e + f; }
+int main(void) {
+  for (; a <= 1; a++) {
+c = -8;
+for (; c != 3; c = d(c, 1))
+  ;
+  }
+  char b = c;
+  if (b != 3)
+__builtin_abort();
+}
diff --git a/gcc/value-range.cc b/gcc/value-range.cc
index bc4b061da57..04820846fe0 100644
--- a/gcc/value-range.cc
+++ b/gcc/value-range.cc
@@ -87,30 +87,13 @@ value_range::set (tree min, tree max, value_range_kind kind)
   return;
 }
 
-  if (kind == VR_RANGE)
+  if (kind != VR_VARYING
+  && (POLY_INT_CST_P (min) || POLY_INT_CST_P (max)))
 {
-  /* Convert POLY_INT_CST bounds into worst-case INTEGER_CST bounds.  */
-  if (POLY_INT_CST_P (min))
-   {
- tree type_min = vrp_val_min (TREE_TYPE (min));
- widest_int lb
-   = constant_lower_bound_with_limit (wi::to_poly_widest (min),
-  wi::to_widest (type_min));
- min = wide_int_to_tree (TREE_TYPE (min), lb);
-   }
-  if (POLY_INT_CST_P (max))
-   {
- tree type_max = vrp_val_max (TREE_TYPE (max));
- widest_int ub
-   = constant_upper_bound_with_limit (wi::to_poly_widest (max),
-  wi::to_widest (type_max));
- max = wide_int_to_tree (TREE_TYPE (max), ub);
-   }
-}
-  else if (kind != VR_VARYING)
-{
-  if (POLY_INT_CST_P (min) || POLY_INT_CST_P (max))
-   kind = VR_VARYING;
+  tree typ = TREE_TYPE (min);
+  gcc_checking_assert (useless_type_conversion_p (typ, TREE_TYPE (max)));
+  set_varying (typ);
+  return;
 }
 
   if (kind == VR_VARYING)

Re: [PATCH] gcc: handle double quotes in symbol name during stabstrings generation

[CHIGOT, CLEMENT via Gcc-patches]

Hi Ian,

Here is the test case.
If you're compiling with -gstabs you should have a line looking like:
.stabs  "type..struct{Type go.bug1.ObjectIdentifier;Value 
[][]go.bug1.Extension{asn1:"set"}}:G(0,7)=xsStructType:",32,0,0,0

As you can see the " around for "set" aren't escaped.
I didn't try to reproduce it on linux/amd64, but I did on linux/ppc64le and I 
don't think it's a ppc-only bug.

Clément

From: Ian Lance Taylor 
Sent: Wednesday, December 2, 2020 4:55 PM
To: CHIGOT, CLEMENT 
Cc: gcc-patches@gcc.gnu.org ; David Edelsohn 

Subject: Re: [PATCH] gcc: handle double quotes in symbol name during 
stabstrings generation

Caution! External email. Do not open attachments or click links, unless this 
email comes from a known sender and you know the content is safe.

On Wed, Dec 2, 2020 at 4:24 AM CHIGOT, CLEMENT  wrote:
>
> Since the new gccgo mangling scheme, libgo compilation is broken on AIX (or 
> in Linux with -gstabs) because of a type symbol having a " in its name. I've 
> made a patch (see attachment) in order to fix stabstring generation, because, 
> IMO, it should be handled anyway.
> However, it happens only once in the whole libgo so I don't know if this " is 
> intended or not. The problematic type is there: 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgolang%2Fgo%2Fblob%2Fmaster%2Fsrc%2Fcrypto%2Fx509%2Fx509.go%23L2674&data=04%7C01%7Cclement.chigot%40atos.net%7Ce85b8b57669c47db583508d896db2fc2%7C33440fc6b7c7412cbb730e70b0198d5a%7C0%7C0%7C637425215428486700%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=aB6diiR9Tgo3FTKOm0vmqVVJ%2B5JlCwd9oM5WeUaTaF4%3D&reserved=0.
>  Other similar types don't trigger the bug though.
>
> I've a minimal test which might can be added if you wish, in Golang tests or 
> in Gcc Go tests or in both ?
>
> If the patch is okay, could you please apply it for me ?

Could you show me the small test case?  I don't think I understand the
problem.  In DWARF I don't see any symbol names with quotation marks.
I'm not yet sure that your patch is the right fix.  Thanks.

Ian


bug_stabs.go
Description: bug_stabs.go

Re: [PATCH 1, 2] Darwin : Update libtool and dependencies for Darwin20 [PR97865]

[Iain Sandoe]

given that this is a blocker for Darwin20 and is Darwin-local I plan to
apply it (with the spello fixes) if there are no more comments in the next
24h.

thanks
Iain

Jonathan Wakely  wrote:


On 23/11/20 20:01 +, Iain Sandoe wrote:

Hi

This fixes a blocker for x86_64 darwin20 (a.k.a macOS 11)
It is needed on all open branches too.

(probably this comes under my Dariwn hat - but since it involves
regenerating all the configure scripts… I’d welcome another pair
of eyes)

tested on:
darwin8-darwin20, powerpc, i686, x86_64, arm64(aarch64).
aix (cfarm gcc119), aarch64 (cfarm gcc115), powerpc64 (BE) - (cfarm  
gcc110)

powerpc64 (LE) - (cfarm gcc135), sparc solaris 2.11 (gcc211)
x86_64-linux-gnu (cfarm gcc123)

OK for master?

OK for backports?

thanks
iain

N.B. I am attaching the second patch which is the uninteresting  
regenerated files.


=

The change in major version (and the increment from Darwin19 to 20)
caused libtool tests to fail which resulted in incorrect build settings
for shared libraries.

We take this opportunity to sort out the shared undefined symbols state
rather than propagating the current unsound behaviour into a new rev.

This change means that we default to the case that missing symbols are
considered an error, and if one wants to allow this intentionally, the
confiuration for that case should be set appropriately.

We use intentional missing symbols to emulate the ELF behaviour when
we have a weak undefined extern.

So, three existing cases need undefined dynamic lookup:
libitm, where there is already a configuration mechanism to add the
   flags.
libsanitizer, likewise
libcc1, where we add simple configuration to add the flags for Darwin.

libcc1/ChangeLog:

PR target/97865
* Makefile.am: Add dynamic_lookup to LD flags for Darwin.
* configure.ac: Test for Darwin host and set a flag.

libitm/ChangeLog:

PR target/97865
* configure.tgt: Add dynamic_lookup to XLDFLAGS for Darwin.

libsanitizer/ChangeLog:

PR target/97865
* configure.tgt: Add dynamic_lookup to EXTRA_CXXFLAGS for
Darwin.

ChangeLog:

PR target/97865
* libtool.m4: Update handling of Darwin platform link flags
for Darwin20.


---
libcc1/Makefile.am |  3 +++
libcc1/configure.ac|  6 ++
libitm/configure.tgt   |  9 -
libsanitizer/configure.tgt |  1 +
libtool.m4 | 32 +---
5 files changed, 35 insertions(+), 16 deletions(-)

diff --git a/libcc1/Makefile.am b/libcc1/Makefile.am
index ab6f839ecae..173b84f9cdb 100644
--- a/libcc1/Makefile.am
+++ b/libcc1/Makefile.am
@@ -25,6 +25,9 @@ CPPFLAGS_FOR_C_FAMILY = -I $(srcdir)/../gcc/c-family \
CPPFLAGS_FOR_C = $(CPPFLAGS_FOR_C_FAMILY) -I $(srcdir)/../gcc/c
CPPFLAGS_FOR_CXX = $(CPPFLAGS_FOR_C_FAMILY) -I $(srcdir)/../gcc/cp
AM_CXXFLAGS = $(WARN_FLAGS) $(WERROR) $(visibility) $(CET_HOST_FLAGS)
+if DARWIN_DYNAMIC_LOOKUP
+AM_CXXFLAGS += -Wl,-undefined,dynamic_lookup
+endif
override CXXFLAGS := $(filter-out -fsanitize=address,$(CXXFLAGS))
override LDFLAGS := $(filter-out -fsanitize=address,$(LDFLAGS))
# Can be simplified when libiberty becomes a normal convenience library.
diff --git a/libcc1/configure.ac b/libcc1/configure.ac
index 8d3b8d14748..262e0a61e6f 100644
--- a/libcc1/configure.ac
+++ b/libcc1/configure.ac
@@ -104,6 +104,12 @@ AC_CACHE_CHECK([for socket libraries],  
libcc1_cv_lib_sockets,

])
LIBS="$LIBS $libcc1_cv_lib_sockets"

+case "$host" in
+  *-*-darwin*) darwin_dynamic_lookup=yes ;;
+  *) darwin_dynamic_lookup= ;;
+esac
+AM_CONDITIONAL(DARWIN_DYNAMIC_LOOKUP, test $darwin_dynamic_lookup = yes)
+
# If any of these functions are missing, simply don't bother building
# this plugin.
GCC_ENABLE_PLUGINS
diff --git a/libitm/configure.tgt b/libitm/configure.tgt
index 04109160e91..d1beb5c9ec8 100644
--- a/libitm/configure.tgt
+++ b/libitm/configure.tgt
@@ -43,6 +43,7 @@ if test "$gcc_cv_have_tls" = yes ; then
   *-*-linux*)
XCFLAGS="${XCFLAGS} -ftls-model=initial-exec"
;;
+
 esac
fi

@@ -144,10 +145,16 @@ case "${target}" in
 *-*-gnu* | *-*-k*bsd*-gnu \
 | *-*-netbsd* | *-*-freebsd* | *-*-openbsd* \
 | *-*-solaris2* | *-*-sysv4* | *-*-hpux11* \
-  | *-*-darwin* | *-*-aix* | *-*-dragonfly*)
+  | *-*-aix* | *-*-dragonfly*)
# POSIX system.  The OS is supported.
;;

+  *-*-darwin*)
+   # The OS is supported, but we need dynamic lookup to support undefined
+   # weak symbols at link-time.
+   XLDFLAGS="${XLDFLAGS} -Wl,-undefined,dynamic_lookup"
+   ;;
+
 *) # Non-POSIX, or embedded system
UNSUPPORTED=1
;;
diff --git a/libsanitizer/configure.tgt b/libsanitizer/configure.tgt
index ef9150209c4..f73d410dedf 100644
--- a/libsanitizer/configure.tgt
+++ b/libsanitizer/configure.tgt
@@ -64,6 +64,7 @@ case "${target}" in
;;
 x86_64-*-darwin2* | x86_64-*-darwin1[2-9]* | i?86-*-darwin1[2-9]*)
TSAN_SUPPORTED=no
+   EXTRA_CXXFLAGS+="-Wl,-undefine

[PATCH][GCC10] arm: Fix unwanted fall-through in arm.c

[Andrea Corallo via Gcc-patches]

Hi all,

this is to fix in GCC 10 the incomplete backport done by 1aabb312f of
what at the time I fixed on master with dd019ef07.

Regtested and bootstraped on arm-linux-gnueabihf.

I guess should be under the obvious rule but prefer to ask, okay for
gcc-10?

Thanks

  Andrea

>From a795f7aaf87fa3610bd690fcfb567e7150fe7570 Mon Sep 17 00:00:00 2001
From: Andrea Corallo 
Date: Wed, 27 May 2020 17:43:48 +0100
Subject: [PATCH] arm: Fix unwanted fall-through in arm.c

Backporting from mainline.

gcc/ChangeLog

2020-05-28  Andrea Corallo  

* config/arm/arm.c (mve_vector_mem_operand): Fix unwanted
fall-through.
---
 gcc/config/arm/arm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 97f5e12ad68..35e6aa27c11 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -13375,6 +13375,7 @@ mve_vector_mem_operand (machine_mode mode, rtx op, bool 
strict)
if (val % 4 == 0 && val >= 0 && val <= 1020)
  return ((reg_no < LAST_ARM_REGNUM && reg_no != SP_REGNUM)
  || (!strict && reg_no >= FIRST_PSEUDO_REGISTER));
+   return FALSE;
  default:
return FALSE;
}
-- 
2.20.1

Re: [PATCH] gcc: handle double quotes in symbol name during stabstrings generation

[Ian Lance Taylor via Gcc-patches]

On Wed, Dec 2, 2020 at 4:24 AM CHIGOT, CLEMENT  wrote:
>
> Since the new gccgo mangling scheme, libgo compilation is broken on AIX (or 
> in Linux with -gstabs) because of a type symbol having a " in its name. I've 
> made a patch (see attachment) in order to fix stabstring generation, because, 
> IMO, it should be handled anyway.
> However, it happens only once in the whole libgo so I don't know if this " is 
> intended or not. The problematic type is there: 
> https://github.com/golang/go/blob/master/src/crypto/x509/x509.go#L2674. Other 
> similar types don't trigger the bug though.
>
> I've a minimal test which might can be added if you wish, in Golang tests or 
> in Gcc Go tests or in both ?
>
> If the patch is okay, could you please apply it for me ?

Could you show me the small test case?  I don't think I understand the
problem.  In DWARF I don't see any symbol names with quotation marks.
I'm not yet sure that your patch is the right fix.  Thanks.

Ian

Go patch committed: Don't advance past unexpected semicolon

[Ian Lance Taylor via Gcc-patches]

This Go frontend patch changes the parser to not advance past an
unexpected semicolon, after it gives an error.  We've already read the
unexpected semicolon, so advancing again causes us to skip the next
token, causing future errors to be out of sync.  Bootstrapped and ran
Go testsuite on x86_64-pc-linux-gnu.  Committed to mainline.

Ian
91bbf4342966cee0f8557068a116c4f2622a3539
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index 45f62b3bec5..8cba9aa5a3d 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-2cc5c746ddfbaeb731f10f2232b9a488df12b71e
+81d3afed2b7f7eba4eed4599dfdd10081f67391e
 
 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/parse.cc b/gcc/go/gofrontend/parse.cc
index c9a5485049f..b062a471008 100644
--- a/gcc/go/gofrontend/parse.cc
+++ b/gcc/go/gofrontend/parse.cc
@@ -1567,7 +1567,6 @@ Parse::type_spec(void*, unsigned int pragmas)
   go_error_at(this->location(),
  "unexpected semicolon or newline in type declaration");
   type = Type::make_error_type();
-  this->advance_token();
 }
 
   if (type->is_error_type())

[Ada] Upgrade ACATS testsuite to latest ACATS 2.6

[Eric Botcazou]

This upgrades the ACATS tesuite present in ada/acats from 2.5 to latest 2.6, 
removing 3 tests and adding 11 tests, some of them written very recently.

Tested on x86-64/Linux, SPARC64/Linux, PowerPC64/Linux and SPARC/Solaris, 
applied on the mainline.


2020-12-02  Eric Botcazou  

Upgrade to latest ACATS 2.6
* ada/acats/support/acats25.lst: Delete.
* ada/acats/support/acats26.lst: New file.
* ada/acats/support/fcndecl.ada: Minor tweak.
* ada/acats/support/impdef.a: Add commentary.
* ada/acats/support/impdefg.a (Negative_Zero return): Simplify.
* ada/acats/support/macro.dfs (TASK_STORAGE_SIZE): Bump.
* ada/acats/support/repbody.ada: Upgrade to ACATS 2.6.
* ada/acats/support/tctouch.ada: Likewise.
* ada/acats/tests/c3/c352001.a: New file.
* ada/acats/tests/c4/c433001.a: Correct error messages.
* ada/acats/tests/c4/c453001.a: New file.
* ada/acats/tests/c4/c45622a.ada: Delete.
* ada/acats/tests/c4/c45624a.ada: Likewise.
* ada/acats/tests/c4/c45624b.ada: Likewise.
* ada/acats/tests/c4/c460013.a: New file.
* ada/acats/tests/c4/c460014.a: Likewise.
* ada/acats/tests/c6/c620001.a: Likewise.
* ada/acats/tests/c6/c620002.a: Likewise.
* ada/acats/tests/c7/c761006.a: Redo Unchecked_Deallocation case.
* ada/acats/tests/c9/c96004a.ada: Adjust for Ada 2005.
* ada/acats/tests/c9/c96007a.ada: Likewise.
* ada/acats/tests/cb/cb41004.a: Adjust for AI95-0044.
* ada/acats/tests/cc/cc3016f.ada: Minor tweak.
* ada/acats/tests/cd/cd30011.a: New file.
* ada/acats/tests/cd/cd30012.a: Likewise.
* ada/acats/tests/cd/cd90001.a: Fix comparison.
* ada/acats/tests/cxa/cxa3004.a: New file.
* ada/acats/tests/cxa/cxa5013.a: Likewise.
* ada/acats/tests/cxa/cxac005.a: Adjust for return-by-reference.
* ada/acats/tests/cxb/cxb30061.am: New file.
* ada/acats/tests/cxf/cxf2001.a: Fix failure message.

-- 
Eric Botcazou

acats26.diff.gz
Description: application/gzip

Re: [PATCH] c++, v2: Implement LWG3396 Clarify point of reference for source_location::current() [PR80780, PR93093]

[Jason Merrill via Gcc-patches]

On 12/2/20 7:13 AM, Jakub Jelinek wrote:

On Tue, Dec 01, 2020 at 04:05:22PM -0500, Jason Merrill via Gcc-patches wrote:

Or simpler might be to always defer immediate evaluation of
source_location::current() until genericize time.


That works.
I had to change constexpr.c too so that it temporarily adjusts
current_function_decl from the constexpr evaluation context, but we do the
same already from __builtin_FUNCTION ().

Tested on x86_64-linux and i686-linux, ok for trunk if it passes full
bootstrap/regtest?

For the non-std::source_location::current() immediate evaluation, I'll just
file a PR and put there all details.


Looks like you missed my minor comments within the earlier patch; I 
should have mentioned that there were some.  Repeating them below:



2020-12-02  Jakub Jelinek  

LWG3396 Clarify point of reference for source_location::current()
PR c++/80780
PR c++/93093
* cp-tree.h (source_location_current_p): Declare.
* tree.c (source_location_current_p): New function.
* call.c (build_over_call): Don't evaluate calls to immediate
function std::source_location::current ().
* constexpr.c (cxx_eval_builtin_function_call): Temporarily set
current_function_decl from ctx->call->fundef->decl if any.
* cp-gimplify.c (cp_genericize_r) : Fold calls
to immediate function std::source_location::current ().

* g++.dg/cpp2a/srcloc15.C: New test.
* g++.dg/cpp2a/srcloc16.C: New test.
* g++.dg/cpp2a/srcloc17.C: New test.
* g++.dg/cpp2a/srcloc18.C: New test.

--- gcc/cp/cp-tree.h.jj 2020-12-01 16:13:01.716818440 +0100
+++ gcc/cp/cp-tree.h2020-12-02 11:49:25.984376796 +0100
@@ -7413,6 +7413,7 @@ extern tree bind_template_template_parm
  extern tree array_type_nelts_total(tree);
  extern tree array_type_nelts_top  (tree);
  extern bool array_of_unknown_bound_p  (const_tree);
+extern bool source_location_current_p  (tree);
  extern tree break_out_target_exprs(tree, bool = false);
  extern tree build_ctor_subob_ref  (tree, tree, tree);
  extern tree replace_placeholders  (tree, tree, bool * = NULL);
--- gcc/cp/tree.c.jj2020-12-01 16:13:01.717818429 +0100
+++ gcc/cp/tree.c   2020-12-02 11:53:19.032696933 +0100
@@ -2968,6 +2968,37 @@ array_type_nelts_total (tree type)
return sz;
  }
  
+/* Return true if FNDECL is std::source_location::current () method.  */

+
+bool
+source_location_current_p (tree fndecl)
+{
+  gcc_checking_assert (TREE_CODE (fndecl) == FUNCTION_DECL
+  && DECL_IMMEDIATE_FUNCTION_P (fndecl));
+  if (DECL_NAME (fndecl) == NULL_TREE
+  || TREE_CODE (TREE_TYPE (fndecl)) != FUNCTION_TYPE
+  || TREE_CODE (TREE_TYPE (TREE_TYPE (fndecl))) != RECORD_TYPE
+  || DECL_CONTEXT (fndecl) != TREE_TYPE (TREE_TYPE (fndecl)))
+return false;
+
+  if (strcmp (IDENTIFIER_POINTER (DECL_NAME (fndecl)), "current") != 0)


You can use id_equal for comparing identifiers to strings.


+return false;
+
+  tree source_location = DECL_CONTEXT (fndecl);
+  if (TYPE_NAME (source_location) == NULL_TREE
+  || TREE_CODE (TYPE_NAME (source_location)) != TYPE_DECL
+  || DECL_NAME (TYPE_NAME (source_location)) == NULL_TREE
+  || strcmp (IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME (source_location))),
+"source_location") != 0)
+return false;


TYPE_IDENTIFIER would also make this shorter.


+
+  tree decl
+= lookup_qualified_name (std_node,
+DECL_NAME (TYPE_NAME (source_location)),
+LOOK_want::TYPE, tf_none);
+  return TYPE_NAME (source_location) == decl;


Why not TYPE_CONTEXT (source_location) == std_node?  I don't think we 
need to do name lookup here.



+}
+
  struct bot_data
  {
splay_tree target_remap;
--- gcc/cp/call.c.jj2020-12-01 16:13:01.714818462 +0100
+++ gcc/cp/call.c   2020-12-02 12:25:25.379566607 +0100
@@ -8613,7 +8613,8 @@ build_over_call (struct z_candidate *can
  && (current_function_decl == NULL_TREE
  || !DECL_IMMEDIATE_FUNCTION_P (current_function_decl))
  && (current_binding_level->kind != sk_function_parms
- || !current_binding_level->immediate_fn_ctx_p))
+ || !current_binding_level->immediate_fn_ctx_p)
+ && (nargs > 1 || !source_location_current_p (fn)))
{
  tree obj_arg = NULL_TREE, exprimm = expr;
  if (DECL_CONSTRUCTOR_P (fn))
@@ -9257,7 +9258,8 @@ build_over_call (struct z_candidate *can
  && (current_function_decl == NULL_TREE
  || !DECL_IMMEDIATE_FUNCTION_P (current_function_decl))
  && (current_binding_level->kind != sk_function_parms
- || !current_binding_level->immediate_fn_ctx_p))
+ || !current_binding_level->immediate_fn_ctx_p)
+ && (nargs > 1 || !source_location_current_p (fndecl)))


Please factor this condition ou

c++: Add lang_decl, type_decl API

[Nathan Sidwell]

We need to call the lang_decl and type_decl creators from the module
loading machinery.  This makes them reachable.

gcc/cp/
* cp-tree.h (maybe_add_lang_decl_raw, maybe_add_lang_type_raw):
Declare.
* lex.c (maybe_add_lang_decl_raw, maybe_add_lang_type_raw):
Externalize, reformat.

pushing to trunk

--
Nathan Sidwell
diff --git i/gcc/cp/cp-tree.h w/gcc/cp/cp-tree.h
index ae1147d4589..4eaa10bc7fd 100644
--- i/gcc/cp/cp-tree.h
+++ w/gcc/cp/cp-tree.h
@@ -6759,6 +6759,8 @@ extern tree unqualified_fn_lookup_error		(cp_expr);
 extern tree make_conv_op_name			(tree);
 extern tree build_lang_decl			(enum tree_code, tree, tree);
 extern tree build_lang_decl_loc			(location_t, enum tree_code, tree, tree);
+extern bool maybe_add_lang_decl_raw		(tree, bool decomp_p);
+extern bool maybe_add_lang_type_raw		(tree);
 extern void retrofit_lang_decl			(tree);
 extern void fit_decomposition_lang_decl		(tree, tree);
 extern tree copy_decl(tree CXX_MEM_STAT_INFO);
diff --git i/gcc/cp/lex.c w/gcc/cp/lex.c
index 21e33d69c08..795f5718198 100644
--- i/gcc/cp/lex.c
+++ w/gcc/cp/lex.c
@@ -680,7 +680,7 @@ build_lang_decl_loc (location_t loc, enum tree_code code, tree name, tree type)
 /* Maybe add a raw lang_decl to T, a decl.  Return true if it needed
one.  */
 
-static bool
+bool
 maybe_add_lang_decl_raw (tree t, bool decomp_p)
 {
   size_t size;
@@ -833,8 +833,7 @@ copy_lang_type (tree node)
   if (! TYPE_LANG_SPECIFIC (node))
 return;
 
-  struct lang_type *lt
-= (struct lang_type *) ggc_internal_alloc (sizeof (struct lang_type));
+  auto *lt = (struct lang_type *) ggc_internal_alloc (sizeof (struct lang_type));
 
   memcpy (lt, TYPE_LANG_SPECIFIC (node), (sizeof (struct lang_type)));
   TYPE_LANG_SPECIFIC (node) = lt;
@@ -860,15 +859,15 @@ copy_type (tree type MEM_STAT_DECL)
 
 /* Add a raw lang_type to T, a type, should it need one.  */
 
-static bool
+bool
 maybe_add_lang_type_raw (tree t)
 {
   if (!RECORD_OR_UNION_CODE_P (TREE_CODE (t)))
 return false;
   
-  TYPE_LANG_SPECIFIC (t)
-= (struct lang_type *) (ggc_internal_cleared_alloc
-			(sizeof (struct lang_type)));
+  auto *lt = (struct lang_type *) (ggc_internal_cleared_alloc
+   (sizeof (struct lang_type)));
+  TYPE_LANG_SPECIFIC (t) = lt;
 
   if (GATHER_STATISTICS)
 {

c++: Extend build_array_type API

[Nathan Sidwell]

The modules machinery needs to construct array types, and that wanted
to determine type dependency.  That doesn't work during loading, but
the module loader can stream that fact too and tell the array builder.
Thus this extends the API to allow a caller to specify the dependency
explicitly.  The call in cp_build_qualified_type_real is unreachable
during the loading, so that one's ok as is.

gcc/cp/
* cp-tree.h (build_cplus_array_type): Add defaulted DEP parm.
* tree.c (set_array_type_common): Add DEP parm.
(build_cplus_array_type): Add DEP parm, determine dependency if
needed.
(cp_build_qualified_type_real): Adjust array-building call.
(strip_typedefs): Likewise.

pushing to trunk
--
Nathan Sidwell
diff --git i/gcc/cp/cp-tree.h w/gcc/cp/cp-tree.h
index b5d4fc0aba1..ae1147d4589 100644
--- i/gcc/cp/cp-tree.h
+++ w/gcc/cp/cp-tree.h
@@ -7377,7 +7377,7 @@ extern bool is_local_temp			(tree);
 extern tree build_aggr_init_expr		(tree, tree);
 extern tree get_target_expr			(tree);
 extern tree get_target_expr_sfinae		(tree, tsubst_flags_t);
-extern tree build_cplus_array_type		(tree, tree);
+extern tree build_cplus_array_type		(tree, tree, int is_dep = -1);
 extern tree build_array_of_n_type		(tree, int);
 extern bool array_of_runtime_bound_p		(tree);
 extern bool vla_type_p(tree);
diff --git i/gcc/cp/tree.c w/gcc/cp/tree.c
index 4113a34b0c1..5932777be04 100644
--- i/gcc/cp/tree.c
+++ w/gcc/cp/tree.c
@@ -998,7 +998,7 @@ build_min_array_type (tree elt_type, tree index_type)
build_cplus_array_type.  */
 
 static void
-set_array_type_canon (tree t, tree elt_type, tree index_type)
+set_array_type_canon (tree t, tree elt_type, tree index_type, bool dep)
 {
   /* Set the canonical type for this new node.  */
   if (TYPE_STRUCTURAL_EQUALITY_P (elt_type)
@@ -1009,30 +1009,33 @@ set_array_type_canon (tree t, tree elt_type, tree index_type)
 TYPE_CANONICAL (t)
   = build_cplus_array_type (TYPE_CANONICAL (elt_type),
 index_type
-? TYPE_CANONICAL (index_type) : index_type);
+? TYPE_CANONICAL (index_type) : index_type,
+dep);
   else
 TYPE_CANONICAL (t) = t;
 }
 
 /* Like build_array_type, but handle special C++ semantics: an array of a
variant element type is a variant of the array of the main variant of
-   the element type.  */
+   the element type.  IS_DEPENDENT is -ve if we should determine the
+   dependency.  Otherwise its bool value indicates dependency.  */
 
 tree
-build_cplus_array_type (tree elt_type, tree index_type)
+build_cplus_array_type (tree elt_type, tree index_type, int dependent)
 {
   tree t;
 
   if (elt_type == error_mark_node || index_type == error_mark_node)
 return error_mark_node;
 
-  bool dependent = (uses_template_parms (elt_type)
-		|| (index_type && uses_template_parms (index_type)));
+  if (dependent < 0)
+dependent = (uses_template_parms (elt_type)
+		 || (index_type && uses_template_parms (index_type)));
 
   if (elt_type != TYPE_MAIN_VARIANT (elt_type))
 /* Start with an array of the TYPE_MAIN_VARIANT.  */
 t = build_cplus_array_type (TYPE_MAIN_VARIANT (elt_type),
-index_type);
+index_type, dependent);
   else if (dependent)
 {
   /* Since type_hash_canon calls layout_type, we need to use our own
@@ -1062,7 +1065,11 @@ build_cplus_array_type (tree elt_type, tree index_type)
 	  *e = t;
 
 	  /* Set the canonical type for this new node.  */
-	  set_array_type_canon (t, elt_type, index_type);
+	  set_array_type_canon (t, elt_type, index_type, dependent);
+
+	  /* Mark it as dependent now, this saves time later.  */
+	  TYPE_DEPENDENT_P_VALID (t) = true;
+	  TYPE_DEPENDENT_P (t) = true;
 	}
 }
   else
@@ -1083,7 +1090,7 @@ build_cplus_array_type (tree elt_type, tree index_type)
   if (!t)
 	{
 	  t = build_min_array_type (elt_type, index_type);
-	  set_array_type_canon (t, elt_type, index_type);
+	  set_array_type_canon (t, elt_type, index_type, dependent);
 	  if (!dependent)
 	{
 	  layout_type (t);
@@ -1319,7 +1326,8 @@ cp_build_qualified_type_real (tree type,
 
   if (!t)
 	{
-	  t = build_cplus_array_type (element_type, TYPE_DOMAIN (type));
+	  t = build_cplus_array_type (element_type, TYPE_DOMAIN (type),
+  TYPE_DEPENDENT_P (type));
 
 	  /* Keep the typedef name.  */
 	  if (TYPE_NAME (t) != TYPE_NAME (type))
@@ -1555,7 +1563,7 @@ 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);
-  result = build_cplus_array_type (type, t0);
+  result = build_cplus_array_type (type, t0, TYPE_DEPENDENT_P (t));
   break;
 case FUNCTION_TYPE:
 case METHOD_TYPE:

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

[Qing Zhao via Gcc-patches]

> 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.

> 
> 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 general situation, and people see it as a debugging tool,
not a "improve code quality and improve the life of kernel developers"
tool.

So having a flag similar to -ftrivial-auto-var-init=zero in GCC will be
appreciated by the Linux kernel community.

currently, kernel is using a gcc plugin to support stack variables
auto-initialization:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/g

c++: Fix bootstrap

[Nathan Sidwell]

I'm not sure why this didn't pop up on the earlier bootstrap.  Anyway, 
fixed thusly.


I made the prefix for dumping a binding-vector slightly too small.
Fixed thusly.

gcc/cp/
* ptree.c (cxx_print_xnode): Increase binding-vector prefix size.

--
Nathan Sidwell
diff --git i/gcc/cp/ptree.c w/gcc/cp/ptree.c
index 1ee107f23cc..f8d22082ba7 100644
--- i/gcc/cp/ptree.c
+++ w/gcc/cp/ptree.c
@@ -259,15 +259,15 @@ cxx_print_xnode (FILE *file, tree node, int indent)
 	for (unsigned ix = 0; ix != len; ix++)
 	  {
 	binding_cluster *cluster = &BINDING_VECTOR_CLUSTER (node, ix);
-	char pfx[20];
+	char pfx[24];
 	for (unsigned jx = 0; jx != BINDING_VECTOR_SLOTS_PER_CLUSTER; jx++)
 	  if (cluster->indices[jx].span)
 		{
 		  int len = sprintf (pfx, "module:%u",
  cluster->indices[jx].base);
 		  if (cluster->indices[jx].span > 1)
-		len
-		  += sprintf (&pfx[len], "(+%u)", cluster->indices[jx].span);
+		len += sprintf (&pfx[len], "(+%u)",
+cluster->indices[jx].span);
 		  len += sprintf (&pfx[len], " cluster:%u/%u", ix, jx);
 		  binding_slot &slot = cluster->slots[jx];
 		  if (slot.is_lazy ())

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

[Martin Jambor]

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.  So it is not known
that the information is useless until the WPA stage.

Or do I misunderstand the issue?

Thanks,

Martin

Re: [PATCH] c++, v2: Implement LWG3396 Clarify point of reference for source_location::current() [PR80780, PR93093]

[Marek Polacek via Gcc-patches]

On Wed, Dec 02, 2020 at 01:13:26PM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Tue, Dec 01, 2020 at 04:05:22PM -0500, Jason Merrill via Gcc-patches wrote:
> > Or simpler might be to always defer immediate evaluation of
> > source_location::current() until genericize time.
> 
> That works.
> I had to change constexpr.c too so that it temporarily adjusts
> current_function_decl from the constexpr evaluation context, but we do the
> same already from __builtin_FUNCTION ().
> 
> Tested on x86_64-linux and i686-linux, ok for trunk if it passes full
> bootstrap/regtest?

I have a few comments, but only minor things; please feel free to ignore
them.

> --- gcc/cp/tree.c.jj  2020-12-01 16:13:01.717818429 +0100
> +++ gcc/cp/tree.c 2020-12-02 11:53:19.032696933 +0100
> @@ -2968,6 +2968,37 @@ array_type_nelts_total (tree type)
>return sz;
>  }
>  
> +/* Return true if FNDECL is std::source_location::current () method.  */
> +
> +bool
> +source_location_current_p (tree fndecl)
> +{
> +  gcc_checking_assert (TREE_CODE (fndecl) == FUNCTION_DECL
> +&& DECL_IMMEDIATE_FUNCTION_P (fndecl));
> +  if (DECL_NAME (fndecl) == NULL_TREE
> +  || TREE_CODE (TREE_TYPE (fndecl)) != FUNCTION_TYPE
> +  || TREE_CODE (TREE_TYPE (TREE_TYPE (fndecl))) != RECORD_TYPE
> +  || DECL_CONTEXT (fndecl) != TREE_TYPE (TREE_TYPE (fndecl)))
> +return false;
> +
> +  if (strcmp (IDENTIFIER_POINTER (DECL_NAME (fndecl)), "current") != 0)
> +return false;

You could use id_equal.

> +  tree source_location = DECL_CONTEXT (fndecl);
> +  if (TYPE_NAME (source_location) == NULL_TREE
> +  || TREE_CODE (TYPE_NAME (source_location)) != TYPE_DECL
> +  || DECL_NAME (TYPE_NAME (source_location)) == NULL_TREE
> +  || strcmp (IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME 
> (source_location))),
> +  "source_location") != 0)
> +return false;

And here too.

> +  tree decl
> += lookup_qualified_name (std_node,
> +  DECL_NAME (TYPE_NAME (source_location)),
> +  LOOK_want::TYPE, tf_none);
> +  return TYPE_NAME (source_location) == decl;

Can this be decl_in_std_namespace_p?

> --- gcc/cp/constexpr.c.jj 2020-11-26 16:22:24.250407040 +0100
> +++ gcc/cp/constexpr.c2020-12-02 12:35:11.458852298 +0100
> @@ -1332,7 +1332,14 @@ cxx_eval_builtin_function_call (const co
>  }
>  
>if (fndecl_built_in_p (fun, CP_BUILT_IN_SOURCE_LOCATION, 
> BUILT_IN_FRONTEND))
> -return fold_builtin_source_location (EXPR_LOCATION (t));
> +{
> +  tree save_cur_fn = current_function_decl;

You could use 

temp_override ovr (current_function_decl);

to avoid having to restore c_f_d manually.

> +  if (ctx->call && ctx->call->fundef)
> + current_function_decl = ctx->call->fundef->decl;
> +  t = fold_builtin_source_location (EXPR_LOCATION (t));
> +  current_function_decl = save_cur_fn;
> +  return t;
> +}
>  
>int strops = 0;
>int strret = 0;
> --- gcc/cp/cp-gimplify.c.jj   2020-11-26 16:22:24.250407040 +0100
> +++ gcc/cp/cp-gimplify.c  2020-12-02 12:26:21.596922205 +0100
> @@ -1374,6 +1374,15 @@ cp_genericize_r (tree *stmt_p, int *walk
> break;
>   }
>  
> +  if (call_expr_nargs (stmt) == 0)
> + if (tree fndecl = cp_get_callee_fndecl (stmt))
> +   if (DECL_IMMEDIATE_FUNCTION_P (fndecl)
> +   && source_location_current_p (fndecl))
> + {
> +   *stmt_p = cxx_constant_value (stmt, NULL_TREE);

You can drop the ", NULL_TREE".

Thanks,
Marek

Re: [PATCH] libstdc++: Add C++ runtime support for new 128-bit long double format

[Michael Meissner via Gcc-patches]

On Tue, Dec 01, 2020 at 10:36:10PM +, Jonathan Wakely wrote:
> I've attached a complete patch including those generated files, and
> I've also pushed the branch to refs/users/redi/heads/ieee128-squash in
> the gcc.gnu.org Git repo. That branch includes your patch for PR
> libgcc/97543 which is required for some of the libstdc++ changes to
> work properly.

This patch along with my posted patches allows me to build the Spec 2017
parest_r benchmark with a PowerPC compiler configured for IEEE 128-bit long
doubles (that previously failed).  Thanks for the hard work!

In addition, I built a compiler where long double defaulted to 64-bit, and I
could build all of the Spec 2017 rate benchmarks.

I ran the two benchmarks that generate IEEE 128-bit instructions when long
double is IEEE 128-bit (perlbench_r and parest_r) on a little endian power9
running Linux with all different long double formats.  There was no difference
in runtime between the benchmark compiled for the different long double
formats.  I have to imagine that while the code is built using long double, the
actual benchmark does not use those functions in a significant way.

I did bootstrap builds for three different compilers configured to use each of
the long double formats.  There were no differences in the C++ tests between
the three compilers.

In the C tests, the two tests that test the nanq and nansq built-in functions
fail with IEEE 128-bit long double because I did not incorprate the patch for
that in this run.  There are 9 tests that fail with long double configured for
64-bits that I will look at adjusting in the future.

In the Fortran tests, there were three benchmarks that fail with IBM 128-bit
long double that now pass with IEEE 128-bit long double.  There is one test
that fails when long double is 64-bits.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH v2] IBM Z: Use llihf and oilf to load large immediates into GPRs

[Ilya Leoshkevich via Gcc-patches]

Bootstrapped and regtested on s390x-redhat-linux.  Ok for master?

v1: https://gcc.gnu.org/pipermail/gcc-patches/2020-December/560822.html

v1 -> v2:
- Use SYMBOL_REF_P.
- Fix usage of gcc_assert.
- Use GEN_INT.



Currently GCC loads large immediates into GPRs from the literal pool,
which is not as efficient as loading two halves with llihf and oilf.

gcc/ChangeLog:

2020-11-30  Ilya Leoshkevich  

* config/s390/s390-protos.h (s390_const_int_pool_entry_p): New
function.
* config/s390/s390.c (s390_const_int_pool_entry_p): New
function.
* config/s390/s390.md: Add define_peephole2 that produces llihf
and oilf.

gcc/testsuite/ChangeLog:

2020-11-30  Ilya Leoshkevich  

* gcc.target/s390/load-imm64-1.c: New test.
* gcc.target/s390/load-imm64-2.c: New test.
---
 gcc/config/s390/s390-protos.h|  1 +
 gcc/config/s390/s390.c   | 31 
 gcc/config/s390/s390.md  | 23 +++
 gcc/testsuite/gcc.target/s390/load-imm64-1.c | 14 +
 gcc/testsuite/gcc.target/s390/load-imm64-2.c | 14 +
 5 files changed, 83 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/s390/load-imm64-1.c
 create mode 100644 gcc/testsuite/gcc.target/s390/load-imm64-2.c

diff --git a/gcc/config/s390/s390-protos.h b/gcc/config/s390/s390-protos.h
index ad2f7f77c18..eb10c3f4bbb 100644
--- a/gcc/config/s390/s390-protos.h
+++ b/gcc/config/s390/s390-protos.h
@@ -135,6 +135,7 @@ extern void s390_split_access_reg (rtx, rtx *, rtx *);
 extern void print_operand_address (FILE *, rtx);
 extern void print_operand (FILE *, rtx, int);
 extern void s390_output_pool_entry (rtx, machine_mode, unsigned int);
+extern bool s390_const_int_pool_entry_p (rtx, HOST_WIDE_INT *);
 extern int s390_label_align (rtx_insn *);
 extern int s390_agen_dep_p (rtx_insn *, rtx_insn *);
 extern rtx_insn *s390_load_got (void);
diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c
index 02f18366aa1..fb48102559d 100644
--- a/gcc/config/s390/s390.c
+++ b/gcc/config/s390/s390.c
@@ -9400,6 +9400,37 @@ s390_output_pool_entry (rtx exp, machine_mode mode, 
unsigned int align)
 }
 }
 
+/* Return true if MEM refers to an integer constant in the literal pool.  If
+   VAL is not nullptr, then also fill it with the constant's value.  */
+
+bool
+s390_const_int_pool_entry_p (rtx mem, HOST_WIDE_INT *val)
+{
+  /* Try to match the following:
+ - (mem (unspec [(symbol_ref) (reg)] UNSPEC_LTREF)).
+ - (mem (symbol_ref)).  */
+
+  if (!MEM_P (mem))
+return false;
+
+  rtx addr = XEXP (mem, 0);
+  rtx sym;
+  if (GET_CODE (addr) == UNSPEC && XINT (addr, 1) == UNSPEC_LTREF)
+sym = XVECEXP (addr, 0, 0);
+  else
+sym = addr;
+
+  if (!SYMBOL_REF_P (sym) || !CONSTANT_POOL_ADDRESS_P (sym))
+return false;
+
+  rtx val_rtx = get_pool_constant (sym);
+  if (!CONST_INT_P (val_rtx))
+return false;
+
+  if (val != nullptr)
+*val = INTVAL (val_rtx);
+  return true;
+}
 
 /* Return an RTL expression representing the value of the return address
for the frame COUNT steps up from the current frame.  FRAME is the
diff --git a/gcc/config/s390/s390.md b/gcc/config/s390/s390.md
index 910415a5974..d4cfbdf6732 100644
--- a/gcc/config/s390/s390.md
+++ b/gcc/config/s390/s390.md
@@ -2116,6 +2116,29 @@ (define_peephole2
   [(set (match_dup 0) (plus:DI (match_dup 1) (match_dup 2)))]
   "")
 
+; Split loading of 64-bit constants into GPRs into llihf + oilf -
+; counterintuitively, using oilf is faster than iilf.  oilf clobbers
+; cc, so cc must be dead.
+(define_peephole2
+  [(set (match_operand:DI 0 "register_operand" "")
+   (match_operand:DI 1 "memory_operand" ""))]
+  "TARGET_64BIT
+   && TARGET_EXTIMM
+   && GENERAL_REG_P (operands[0])
+   && s390_const_int_pool_entry_p (operands[1], nullptr)
+   && peep2_reg_dead_p (1, gen_rtx_REG (CCmode, CC_REGNUM))"
+  [(set (match_dup 0) (match_dup 2))
+   (parallel
+[(set (match_dup 0) (ior:DI (match_dup 0) (match_dup 3)))
+ (clobber (reg:CC CC_REGNUM))])]
+{
+  HOST_WIDE_INT val;
+  bool ok = s390_const_int_pool_entry_p (operands[1], &val);
+  gcc_assert (ok);
+  operands[2] = GEN_INT (val & 0xULL);
+  operands[3] = GEN_INT (val & 0xULL);
+})
+
 ;
 ; movsi instruction pattern(s).
 ;
diff --git a/gcc/testsuite/gcc.target/s390/load-imm64-1.c 
b/gcc/testsuite/gcc.target/s390/load-imm64-1.c
new file mode 100644
index 000..03d17f59096
--- /dev/null
+++ b/gcc/testsuite/gcc.target/s390/load-imm64-1.c
@@ -0,0 +1,14 @@
+/* Test that large 64-bit constants are loaded with llihf + oilf when lgrl is
+   not available.  */
+
+/* { dg-do compile } */
+/* { dg-options "-O3 -march=z9-109" } */
+
+unsigned long
+magic (void)
+{
+  return 0x3f08c5392f756cd;
+}
+
+/* { dg-final { scan-assembler-times {\n\tllihf\t} 1 { target lp64 } } } */
+/* { dg-final { scan-assembler-times {\n\toilf\t} 1 { target lp64 } } } */
diff --git a/gcc/testsuite/gcc.target

[PATCH] Sync .gitignore with binutils-gdb

[Simon Marchi via Gcc-patches]

Bring in a few lines that are in binutils-gdb's .gitignore but not
gcc's.

Note that I don't have push access to gcc, so I would appreciate
if somebody could push it for me.

ChangeLog:

* .gitignore: Sync with binutils-gdb.
---
 .gitignore | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/.gitignore b/.gitignore
index 1a29029895aa..382e2def731e 100644
--- a/.gitignore
+++ b/.gitignore
@@ -15,6 +15,7 @@
 *.o
 *.pyc
 *.tmp
+*.a
 
 .deps
 .libs
@@ -44,6 +45,9 @@ compile_commands.json
 .gdbinit
 .gdb_history
 
+perf.data
+perf.data.old
+
 # ignore core files, but not java/net/protocol/core/
 core
 !core/
@@ -54,6 +58,9 @@ lost+found
 LAST_UPDATED
 REVISION
 
+stamp-*
+*.stamp
+
 # ignore in-tree prerequisites
 /mpfr*
 /mpc*
-- 
2.29.2

Re: [PATCH] vec.h: Fix GCC build with -std=gnu++20 [PR98059]

[Richard Biener via Gcc-patches]

On Wed, Dec 2, 2020 at 3:08 PM Jakub Jelinek via Gcc-patches
 wrote:
>
> Hi!
>
> Apparently vec.h doesn't build with -std=c++20/gnu++20, since the
> DR2237 r11-532 change.
> template 
> class auto_delete_vec
> {
> private:
>   auto_vec_delete (const auto_delete_vec &) = delete;
> };
> which vec.h uses is invalid C++20, one needs to use
>   auto_vec_delete (const auto_delete_vec &) = delete;
> instead which is valid all the way back to C++11 (and without = delete
> to C++98).
>
> Tested on x86_64-linux, ok for trunk?

OK.

> 2020-12-02  Scott Snyder  
>
> PR plugins/98059
> * vec.h (auto_delete_vec): Use
> DISABLE_COPY_AND_ASSIGN(auto_delete_vec) instead of
> DISABLE_COPY_AND_ASSIGN(auto_delete_vec) to make it valid C++20
> after DR2237.
>
> --- gcc/vec.h.jj2020-10-30 08:59:57.081496258 +0100
> +++ gcc/vec.h   2020-12-02 14:56:01.098938644 +0100
> @@ -1602,7 +1602,7 @@ class auto_delete_vec : public auto_vec
>~auto_delete_vec ();
>
>  private:
> -  DISABLE_COPY_AND_ASSIGN(auto_delete_vec);
> +  DISABLE_COPY_AND_ASSIGN(auto_delete_vec);
>  };
>
>  /* Conditionally allocate heap memory for VEC and its internal vector.  */
>
> Jakub
>

C++ Module Binding Vector

[Nathan Sidwell]

This is modified from the original patch.  firstly it contains a few 
more necessary bits.  But mainly I renamed the entities from 
'MODULE_foo' to 'BINDING_foo', as it's a vector of bindings used by 
modules (not a vector of modules).  It also belongs in name-lookup.h.


Pushing to trunk

This adds the vector necessary to hold different module's namespace
bindings.  We add a new tree-node 'tree_binding_vec', which contains a
sparse array, indexed by module number.  To avoid space wasting, this
is allocated in clusters using 'unsigned short' as the index value (so
that's one of the upper bounds on module importing).  If there are
only bindings from the current TU, there is no vector, so we have the
same representation as a non-module compilation.

To support lazy loading, a binding slot can contain either a tree (the
binding), or a cookie that the module machinery uses to load the
required binding on demand.

The first 2 or 3 slots end up being reserved for fixed meanings.
There are a couple of flags we have to record on a binding, to know
whether the same declaration could appear in two different slots.

gcc/cp/
* cp-tree.def (BINDING_VECTOR): New.
* name-lookup.h (struct binding_slot): New.
(BINDING_VECTOR_SLOTS_PER_CLUSTER): New.
(struct binding_index, struct binding_cluster): New.
(BINDING_VECTOR_ALLOC_CLUSTERS, BINDING_VECTOR_CLUSTER_BASE)
(BINDING_VECTOR_CLUSTER): New.
(struct tree_binding_vec): New.
(BINDING_VECTOR_NAME, BINDING_VECTOR_GLOBAL_DUPS_P)
(BINDING_VECTOR_PARTITION_DUPS_P): New.
(BINDING_BINDING_GLOBAL_P, BINDING_BINDING_PARTITION_P): New.
(BINDING_VECTOR_PENDING_SPECIALIZATIONS)
(BINDING_VECTOR_PENDING_IS_HEADER_P)
(BINDING_VECTOR_PENDING_IS_PARTITION_P): New.
* cp-tree.h (enum cp_tree_node_structure_enum): Add
TS_CP_BINDING_VECTOR.
(union lang_tree_node): Add binding_vec field.
(make_binding_vec): Declare.
(named_decl_hash::hash, named_decl_hash::equal): Check for binding
vector.
* decl.c (cp_tree_node_structure): Add BINDING_VECTOR case.
* ptree.c (cxx_print_xnode): Add BINDING_VECTOR case.
* tree.c (make_binding_vec): New.
--
Nathan Sidwell
diff --git i/gcc/cp/cp-tree.def w/gcc/cp/cp-tree.def
index a188576013b..4e73e46b4a0 100644
--- i/gcc/cp/cp-tree.def
+++ w/gcc/cp/cp-tree.def
@@ -233,6 +233,9 @@ DEFTREECODE (TEMPLATE_ID_EXPR, "template_id_expr", tcc_expression, 2)
 /* One of a set of overloaded functions.  */
 DEFTREECODE (OVERLOAD, "overload", tcc_exceptional, 0)
 
+/* A vector of binding slots.  */
+DEFTREECODE (BINDING_VECTOR, "binding_vector", tcc_exceptional, 0)
+
 /* A pseudo-destructor, of the form "OBJECT.~DESTRUCTOR" or
"OBJECT.SCOPE::~DESTRUCTOR.  The first operand is the OBJECT.  The
second operand (if non-NULL) is the SCOPE.  The third operand is
diff --git i/gcc/cp/cp-tree.h w/gcc/cp/cp-tree.h
index 021de76e142..b5d4fc0aba1 100644
--- i/gcc/cp/cp-tree.h
+++ w/gcc/cp/cp-tree.h
@@ -1665,6 +1665,7 @@ enum cp_tree_node_structure_enum {
   TS_CP_TPI,
   TS_CP_PTRMEM,
   TS_CP_OVERLOAD,
+  TS_CP_BINDING_VECTOR,
   TS_CP_BASELINK,
   TS_CP_TEMPLATE_DECL,
   TS_CP_DEFERRED_PARSE,
@@ -1686,6 +1687,7 @@ union GTY((desc ("cp_tree_node_structure (&%h)"),
   struct template_parm_index GTY ((tag ("TS_CP_TPI"))) tpi;
   struct ptrmem_cst GTY ((tag ("TS_CP_PTRMEM"))) ptrmem;
   struct tree_overload GTY ((tag ("TS_CP_OVERLOAD"))) overload;
+  struct tree_binding_vec GTY ((tag ("TS_CP_BINDING_VECTOR"))) binding_vec;
   struct tree_baselink GTY ((tag ("TS_CP_BASELINK"))) baselink;
   struct tree_template_decl GTY ((tag ("TS_CP_TEMPLATE_DECL"))) template_decl;
   struct tree_deferred_parse GTY ((tag ("TS_CP_DEFERRED_PARSE"))) deferred_parse;
@@ -7386,6 +7388,7 @@ extern tree hash_tree_cons			(tree, tree, tree);
 extern tree hash_tree_chain			(tree, tree);
 extern tree build_qualified_name		(tree, tree, tree, bool);
 extern tree build_ref_qualified_type		(tree, cp_ref_qualifier);
+extern tree make_binding_vec			(tree, unsigned clusters);
 inline tree ovl_first(tree) ATTRIBUTE_PURE;
 extern tree ovl_make(tree fn,
 		 tree next = NULL_TREE);
@@ -8020,14 +8023,16 @@ type_unknown_p (const_tree expr)
 inline hashval_t
 named_decl_hash::hash (const value_type decl)
 {
-  tree name = OVL_NAME (decl);
+  tree name = (TREE_CODE (decl) == BINDING_VECTOR
+	   ? BINDING_VECTOR_NAME (decl) : OVL_NAME (decl));
   return name ? IDENTIFIER_HASH_VALUE (name) : 0;
 }
 
 inline bool
 named_decl_hash::equal (const value_type existing, compare_type candidate)
 {
-  tree name = OVL_NAME (existing);
+  tree name = (TREE_CODE (existing) == BINDING_VECTOR
+	   ? BINDING_VECTOR_NAME (existing) : OVL_NAME (existing));
   return candidate == name;
 }
 
diff --git i/gcc/cp/decl.c w/gcc/cp/decl.c
index 3dd4b076582..df76155a243 100644
--- i/gcc/cp/decl.c
+++ w/gcc/cp/decl.c
@@ -17594,6 +17594,7 @@ cp_tree_node_s

[PATCH] vec.h: Fix GCC build with -std=gnu++20 [PR98059]

[Jakub Jelinek via Gcc-patches]

Hi!

Apparently vec.h doesn't build with -std=c++20/gnu++20, since the
DR2237 r11-532 change.
template 
class auto_delete_vec
{
private:
  auto_vec_delete (const auto_delete_vec &) = delete;
};
which vec.h uses is invalid C++20, one needs to use
  auto_vec_delete (const auto_delete_vec &) = delete;
instead which is valid all the way back to C++11 (and without = delete
to C++98).

Tested on x86_64-linux, ok for trunk?

2020-12-02  Scott Snyder  

PR plugins/98059
* vec.h (auto_delete_vec): Use
DISABLE_COPY_AND_ASSIGN(auto_delete_vec) instead of
DISABLE_COPY_AND_ASSIGN(auto_delete_vec) to make it valid C++20
after DR2237.

--- gcc/vec.h.jj2020-10-30 08:59:57.081496258 +0100
+++ gcc/vec.h   2020-12-02 14:56:01.098938644 +0100
@@ -1602,7 +1602,7 @@ class auto_delete_vec : public auto_vec
   ~auto_delete_vec ();
 
 private:
-  DISABLE_COPY_AND_ASSIGN(auto_delete_vec);
+  DISABLE_COPY_AND_ASSIGN(auto_delete_vec);
 };
 
 /* Conditionally allocate heap memory for VEC and its internal vector.  */

Jakub

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

[Jan Hubicka]

> Hello.
> 
> 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.
> 
> gcc/testsuite/ChangeLog:
> 
>   PR ipa/98075
>   * g++.dg/ipa/pr98075.C: New test.
> ---
>  gcc/cgraph.c   |  2 ++
>  gcc/ipa-pure-const.c   |  3 ++-
>  gcc/testsuite/g++.dg/ipa/pr98075.C | 30 ++
>  3 files changed, 34 insertions(+), 1 deletion(-)
>  create mode 100644 gcc/testsuite/g++.dg/ipa/pr98075.C
> 
> diff --git a/gcc/cgraph.c b/gcc/cgraph.c
> index dbde8aaaba1..cb59a5a71fc 100644
> --- a/gcc/cgraph.c
> +++ b/gcc/cgraph.c
> @@ -2190,6 +2190,8 @@ cgraph_node::dump (FILE *f)
>  fprintf (f, " optimize_size");
>if (parallelized_function)
>  fprintf (f, " parallelized_function");
> +  if (DECL_IS_MALLOC (decl))
> +fprintf (f, " decl_is_malloc");
>if (DECL_IS_OPERATOR_NEW_P (decl))
>  fprintf (f, " %soperator_new",
>DECL_IS_REPLACEABLE_OPERATOR (decl) ? "replaceable_" : "");
> diff --git a/gcc/ipa-pure-const.c b/gcc/ipa-pure-const.c
> index 054f35981a5..4c47eec8509 100644
> --- a/gcc/ipa-pure-const.c
> +++ b/gcc/ipa-pure-const.c
> @@ -1973,7 +1973,8 @@ propagate_malloc (void)
>   funct_state l = funct_state_summaries->get (node);
>   if (!node->alias
>   && l->malloc_state == STATE_MALLOC
> - && !node->inlined_to)
> + && !node->inlined_to
> + && !VOID_TYPE_P (TREE_TYPE (TREE_TYPE (node->decl
> {
>   if (dump_file && (dump_flags & TDF_DETAILS))
> fprintf (dump_file, "Function %s found to be malloc\n",
> diff --git a/gcc/testsuite/g++.dg/ipa/pr98075.C 
> b/gcc/testsuite/g++.dg/ipa/pr98075.C
> new file mode 100644
> index 000..0c4219d1ff3
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/ipa/pr98075.C
> @@ -0,0 +1,30 @@
> +/* PR ipa/98075 */
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fno-inline" } */
> +
> +template 
> +class xg {
> +public:
> +  BS *
> +  fw ()
> +  {
> +return static_cast (operator new (sizeof (BS)));
> +  }
> +};
> +
> +class zp : xg {
> +public:
> +  __attribute__ ((always_inline)) zp ()
> +  {
> +hy = xg::fw ();
> +  }
> +
> +private:
> +  int *hy;
> +};
> +
> +void
> +e5 ()
> +{
> +  zp ix;
> +}
> -- 
> 2.29.2
> 

[PATCH] tree-optimization/97630 - fix SLP cycle memory leak

[Richard Biener]

This fixes SLP cycles leaking memory by maintaining a double-linked
list of allocatd SLP nodes we can zap when we free the alloc pool.

Bootstrap & regtest running on x86_64-unknown-linux-gnu.

2020-12-02  Richard Biener  

PR tree-optimization/97630
* tree-vectorizer.h (_slp_tree::next_node,
_slp_tree::prev_node): New.
(vect_slp_init): Declare.
(vect_slp_fini): Likewise.
* tree-vectorizer.c (vectorize_loops): Call vect_slp_init/fini.
(pass_slp_vectorize::execute): Likewise.
* tree-vect-slp.c (vect_slp_init): New.
(vect_slp_fini): Likewise.
(slp_first_node): New global.
(_slp_tree::_slp_tree): Link node into the SLP tree list.
(_slp_tree::~_slp_tree): Delink node from the SLP tree list.
---
 gcc/tree-vect-slp.c   | 31 ++-
 gcc/tree-vectorizer.c | 10 --
 gcc/tree-vectorizer.h |  9 ++---
 3 files changed, 40 insertions(+), 10 deletions(-)

diff --git a/gcc/tree-vect-slp.c b/gcc/tree-vect-slp.c
index 55e0a23253d..be87475092d 100644
--- a/gcc/tree-vect-slp.c
+++ b/gcc/tree-vect-slp.c
@@ -48,12 +48,30 @@ along with GCC; see the file COPYING3.  If not see
 #include "cfganal.h"
 #include "tree-eh.h"
 #include "tree-cfg.h"
+#include "alloc-pool.h"
 
 static bool vectorizable_slp_permutation (vec_info *, gimple_stmt_iterator *,
  slp_tree, stmt_vector_for_cost *);
 static void vect_print_slp_tree (dump_flags_t, dump_location_t, slp_tree);
+static void vect_free_slp_tree (slp_tree);
 
-object_allocator<_slp_tree> *slp_tree_pool;
+static object_allocator<_slp_tree> *slp_tree_pool;
+static slp_tree slp_first_node;
+
+void
+vect_slp_init (void)
+{
+  slp_tree_pool = new object_allocator<_slp_tree> ("SLP nodes");
+}
+
+void
+vect_slp_fini (void)
+{
+  while (slp_first_node)
+delete slp_first_node;
+  delete slp_tree_pool;
+  slp_tree_pool = NULL;
+}
 
 void *
 _slp_tree::operator new (size_t n)
@@ -74,6 +92,11 @@ _slp_tree::operator delete (void *node, size_t n)
 
 _slp_tree::_slp_tree ()
 {
+  this->prev_node = NULL;
+  if (slp_first_node)
+slp_first_node->prev_node = this;
+  this->next_node = slp_first_node;
+  slp_first_node = this;
   SLP_TREE_SCALAR_STMTS (this) = vNULL;
   SLP_TREE_SCALAR_OPS (this) = vNULL;
   SLP_TREE_VEC_STMTS (this) = vNULL;
@@ -96,6 +119,12 @@ _slp_tree::_slp_tree ()
 
 _slp_tree::~_slp_tree ()
 {
+  if (this->prev_node)
+this->prev_node->next_node = this->next_node;
+  else
+slp_first_node = this->next_node;
+  if (this->next_node)
+this->next_node->prev_node = this->prev_node;
   SLP_TREE_CHILDREN (this).release ();
   SLP_TREE_SCALAR_STMTS (this).release ();
   SLP_TREE_SCALAR_OPS (this).release ();
diff --git a/gcc/tree-vectorizer.c b/gcc/tree-vectorizer.c
index b63dda31a08..f9e26422018 100644
--- a/gcc/tree-vectorizer.c
+++ b/gcc/tree-vectorizer.c
@@ -1171,7 +1171,7 @@ vectorize_loops (void)
   if (vect_loops_num <= 1)
 return 0;
 
-  slp_tree_pool = new object_allocator<_slp_tree> ("SLP nodes for vect");
+  vect_slp_init ();
 
   if (cfun->has_simduid_loops)
 note_simd_array_uses (&simd_array_to_simduid_htab);
@@ -1295,8 +1295,7 @@ vectorize_loops (void)
 shrink_simd_arrays (simd_array_to_simduid_htab, simduid_to_vf_htab);
   delete simduid_to_vf_htab;
   cfun->has_simduid_loops = false;
-  delete slp_tree_pool;
-  slp_tree_pool = NULL;
+  vect_slp_fini ();
 
   if (num_vectorized_loops > 0)
 {
@@ -1432,12 +1431,11 @@ pass_slp_vectorize::execute (function *fun)
}
 }
 
-  slp_tree_pool = new object_allocator<_slp_tree> ("SLP nodes for slp");
+  vect_slp_init ();
 
   vect_slp_function (fun);
 
-  delete slp_tree_pool;
-  slp_tree_pool = NULL;
+  vect_slp_fini ();
 
   if (!in_loop_pipeline)
 {
diff --git a/gcc/tree-vectorizer.h b/gcc/tree-vectorizer.h
index c9f95bc6ffe..661444e3dac 100644
--- a/gcc/tree-vectorizer.h
+++ b/gcc/tree-vectorizer.h
@@ -26,7 +26,6 @@ typedef class _stmt_vec_info *stmt_vec_info;
 #include "tree-data-ref.h"
 #include "tree-hash-traits.h"
 #include "target.h"
-#include "alloc-pool.h"
 
 
 /* Used for naming of new temporaries.  */
@@ -116,8 +115,6 @@ typedef hash_map *slp_tree_pool;
-
 /* A computation tree of an SLP instance.  Each node corresponds to a group of
stmts to be packed in a SIMD stmt.  */
 struct _slp_tree {
@@ -177,6 +174,10 @@ struct _slp_tree {
 
   /* Return memory to slp_tree_pool.  */
   static void operator delete (void *, size_t);
+
+  /* Linked list of nodes to release when we free the slp_tree_pool.  */
+  slp_tree next_node;
+  slp_tree prev_node;
 };
 
 /* The enum describes the type of operations that an SLP instance
@@ -1968,6 +1969,8 @@ extern int vect_get_known_peeling_cost (loop_vec_info, 
int, int *,
 extern tree cse_and_gimplify_to_preheader (loop_vec_info, tree);
 
 /* In tree-vect-slp.c.  */
+extern void vect_slp_init (void);
+extern void vect_slp_fini (void);
 extern void vect_free_slp_instance (slp_

[PATCH] x86: Add the missing '.' for -mneeded

[H.J. Lu via Gcc-patches]

On Tue, Dec 1, 2020 at 6:28 PM H. J. Lu  wrote:
>
> New failures:
> FAIL: compiler driver --help=target option(s): "^ +-.*[^:.]$" absent from 
> output: "  -mneededEmit GNU_PROPERTY_X86_ISA_1_NEEDED GNU 
> property"
> FAIL: compiler driver --help=target option(s): "^ +-.*[^:.]$" absent from 
> output: "  -mneededEmit GNU_PROPERTY_X86_ISA_1_NEEDED GNU 
> property"
> FAIL: compiler driver --help=target option(s): "^ +-.*[^:.]$" absent from 
> output: "  -mneededEmit GNU_PROPERTY_X86_ISA_1_NEEDED GNU 
> property"
> FAIL: gcc.dg/lto/save-temps c_lto_save-temps_0.o-c_lto_save-temps_0.o link,  
> -O -flto -save-temps
>

I am checking this as an obvious fix.

-- 
H.J.
From c3dff3d73da87f20effae8defaf926e8ba5204db Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Wed, 2 Dec 2020 05:16:12 -0800
Subject: [PATCH] x86: Add the missing '.' for -mneeded

	* config/i386/i386.opt: Add the missing '.' for -mneeded.
---
 gcc/config/i386/i386.opt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/i386/i386.opt b/gcc/config/i386/i386.opt
index d7e4f443883..87e6021408d 100644
--- a/gcc/config/i386/i386.opt
+++ b/gcc/config/i386/i386.opt
@@ -1151,4 +1151,4 @@ AVXVNNI built-in functions and code generation.
 
 mneeded
 Target Report Var(ix86_needed) Save
-Emit GNU_PROPERTY_X86_ISA_1_NEEDED GNU property
+Emit GNU_PROPERTY_X86_ISA_1_NEEDED GNU property.
-- 
2.28.0

V2 [PATCH] Use the section flag 'o' for __patchable_function_entries

[H.J. Lu via Gcc-patches]

On Tue, Dec 1, 2020 at 9:23 PM Jeff Law  wrote:
>
>
>
> On 11/18/20 7:00 AM, H.J. Lu wrote:
> > On Sat, Nov 7, 2020 at 7:47 AM H.J. Lu  wrote:
> >> On Sat, Oct 31, 2020 at 5:01 AM H.J. Lu  wrote:
> >>> On Fri, Oct 23, 2020 at 5:41 AM H.J. Lu  wrote:
>  On Fri, Oct 2, 2020 at 6:00 AM H.J. Lu  wrote:
> > On Thu, Feb 6, 2020 at 6:57 PM H.J. Lu  wrote:
> >> This commit in GNU binutils 2.35:
> >>
> >> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=b7d072167715829eed0622616f6ae0182900de3e
> >>
> >> added the section flag 'o' to .section directive:
> >>
> >> .section __patchable_function_entries,"awo",@progbits,foo
> >>
> >> which specifies the symbol name which the section references.  
> >> Assembler
> >> creates a unique __patchable_function_entries section with the section,
> >> where foo is defined, as its linked-to section.  Linker keeps a section
> >> if its linked-to section is kept during garbage collection.
> >>
> >> This patch checks assembler support for the section flag 'o' and uses
> >> it to implement __patchable_function_entries section.  Since Solaris 
> >> may
> >> use GNU assembler with Solairs ld.  Even if GNU assembler supports the
> >> section flag 'o', it doesn't mean that Solairs ld supports it.  This
> >> feature is disabled for Solairs targets.
> >>
> >> gcc/
> >>
> >> PR middle-end/93195
> >> PR middle-end/93197
> >> * configure.ac (HAVE_GAS_SECTION_LINK_ORDER): New.  Define if
> >> the assembler supports the section flag 'o' for specifying
> >> section with link-order.
> >> * dwarf2out.c (output_comdat_type_unit): Pass 0 as flags2
> >> to targetm.asm_out.named_section.
> >> * config/sol2.c (solaris_elf_asm_comdat_section): Likewise.
> >> * output.h (SECTION2_LINK_ORDER): New.
> >> (switch_to_section): Add an unsigned int argument.
> >> (default_no_named_section): Likewise.
> >> (default_elf_asm_named_section): Likewise.
> >> * target.def (asm_out.named_section): Likewise.
> >> * targhooks.c (default_print_patchable_function_entry): Pass
> >> current_function_decl to get_section and SECTION2_LINK_ORDER
> >> to switch_to_section.
> >> * varasm.c (default_no_named_section): Add an unsigned int
> >> argument.
> >> (default_elf_asm_named_section): Add an unsigned int argument,
> >> flags2.  Use 'o' flag for SECTION2_LINK_ORDER if assembler
> >> supports it.
> >> (switch_to_section): Add an unsigned int argument and pass it
> >> to targetm.asm_out.named_section.
> >> (handle_vtv_comdat_section): Pass 0 to
> >> targetm.asm_out.named_section.
> >> * config.in: Regenerated.
> >> * configure: Likewise.
> >> * doc/tm.texi: Likewise.
> >>
> >> gcc/testsuite/
> >>
> >> PR middle-end/93195
> >> * g++.dg/pr93195a.C: New test.
> >> * g++.dg/pr93195b.C: Likewise.
> >> * lib/target-supports.exp
> >> (check_effective_target_o_flag_in_section): New proc.
> > PING
> >
> > https://gcc.gnu.org/pipermail/gcc-patches/2020-February/539963.html
>  PING.
> 
> >>> PING.
> >>>
> >> PING.
> > Here is a simpler patch.  OK for master?
> >
> > This commit in GNU binutils 2.35:
> >
> > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=b7d072167715
> > 829eed0622616f6ae0182900de3e
> >
> > added the section flag 'o' to .section directive:
> >
> > .section __patchable_function_entries,"awo",@progbits,foo
> >
> > which specifies the symbol name which the section references.  Assembler
> > creates a unique __patchable_function_entries section with the section,
> > where foo is defined, as its linked-to section.  Linker keeps a section
> > if its linked-to section is kept during garbage collection.
> >
> > This patch checks assembler support for the section flag 'o' and uses
> > it to implement __patchable_function_entries section.  Since Solaris may
> > use GNU assembler with Solairs ld.  Even if GNU assembler supports the
> > section flag 'o', it doesn't mean that Solairs ld supports it.  This
> > feature is disabled for Solairs targets.
> >
> > gcc/
> >
> > PR middle-end/93195
> > PR middle-end/93197
> > * configure.ac (HAVE_GAS_SECTION_LINK_ORDER): New.  Define 1 if
> > the assembler supports the section flag 'o' for specifying
> > section with link-order.
> > * output.h (SECTION_LINK_ORDER): New.  Defined to 0x400.
> > (SECTION_MACH_DEP): Changed from 0x400 to 0x800.
> > * targhooks.c (default_print_patchable_function_entry): Pass
> > SECTION_LINK_ORDER to switch_to_section if the section flag 'o'
> > works.  Pass current_function_decl to switch_to_sect

Re: [PATCH] dwarf: Add -gdwarf{32,64} options

[Jakub Jelinek via Gcc-patches]

On Tue, Dec 01, 2020 at 01:48:31PM +0100, Jakub Jelinek via Gcc-patches wrote:
> I guess it depends on whether for 32-bit target and -gdwarf64, when
> calling dw2_assemble_integer with non-CONST_INT argument we only
> need positive values or might need negative ones too.
> Because positive ones can be easily emulated through that
> .long expression, 0
> or
> .long 0, expression
> depending on endianity, but I'm afraid there is no way to emit
> 0 or -1 depending on the sign of expression, when it needs relocations.
> Looking through dw2_asm_output_delta calls, at least the vast majority
> of the calls seem to guarantee being positive, not 100% sure about
> one case in .debug_line views, but I'd hope it is ok too.
> In most cases, the deltas are between two labels where the first one
> in the arguments is later in the same section than the other one,
> or where the second argument is the start of a section or another section
> base.

I went through dwarf2out.c dw2_asm_output_delta calls and I'm fairly
confident all of them are ok, represent sizes of .debug* sections or their
portions, or differences between symbols in the same section where the x
in x - y is later than y in the section (what I was worried about, something
like:
.text
.L1:
...
.L2:
...
.quad .L1 - .L2
doesn't appear to happen.
Additionally, seems the x32 ABI I've been worried about uses ELF32 rather
than ELF64, so it must suffer from the same limitation, if address size is
32-bit, one can't apply 64-bit relocations.

Patch has been bootstrapped/regtested on x86_64-linux and i686-linux.
Ok for trunk together with the -gdwarf{32,64} patch?

> 2020-12-01  Jakub Jelinek  
> 
>   * dwarf2asm.c (dw2_assemble_integer): Handle size twice as large
>   as DWARF2_ADDR_SIZE if x is not a scalar int by emitting it as
>   two halves, one with x and the other with const0_rtx, ordered
>   depending on endianity.

Jakub

[PATCH] ipa: do not DECL_IS_MALLOC for void fns

[Martin Liška]

Hello.

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.

gcc/testsuite/ChangeLog:

PR ipa/98075
* g++.dg/ipa/pr98075.C: New test.
---
 gcc/cgraph.c   |  2 ++
 gcc/ipa-pure-const.c   |  3 ++-
 gcc/testsuite/g++.dg/ipa/pr98075.C | 30 ++
 3 files changed, 34 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/ipa/pr98075.C

diff --git a/gcc/cgraph.c b/gcc/cgraph.c
index dbde8aaaba1..cb59a5a71fc 100644
--- a/gcc/cgraph.c
+++ b/gcc/cgraph.c
@@ -2190,6 +2190,8 @@ cgraph_node::dump (FILE *f)
 fprintf (f, " optimize_size");
   if (parallelized_function)
 fprintf (f, " parallelized_function");
+  if (DECL_IS_MALLOC (decl))
+fprintf (f, " decl_is_malloc");
   if (DECL_IS_OPERATOR_NEW_P (decl))
 fprintf (f, " %soperator_new",
 DECL_IS_REPLACEABLE_OPERATOR (decl) ? "replaceable_" : "");
diff --git a/gcc/ipa-pure-const.c b/gcc/ipa-pure-const.c
index 054f35981a5..4c47eec8509 100644
--- a/gcc/ipa-pure-const.c
+++ b/gcc/ipa-pure-const.c
@@ -1973,7 +1973,8 @@ propagate_malloc (void)
funct_state l = funct_state_summaries->get (node);
if (!node->alias
&& l->malloc_state == STATE_MALLOC
-   && !node->inlined_to)
+   && !node->inlined_to
+   && !VOID_TYPE_P (TREE_TYPE (TREE_TYPE (node->decl
  {
if (dump_file && (dump_flags & TDF_DETAILS))
  fprintf (dump_file, "Function %s found to be malloc\n",
diff --git a/gcc/testsuite/g++.dg/ipa/pr98075.C 
b/gcc/testsuite/g++.dg/ipa/pr98075.C
new file mode 100644
index 000..0c4219d1ff3
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ipa/pr98075.C
@@ -0,0 +1,30 @@
+/* PR ipa/98075 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fno-inline" } */
+
+template 
+class xg {
+public:
+  BS *
+  fw ()
+  {
+return static_cast (operator new (sizeof (BS)));
+  }
+};
+
+class zp : xg {
+public:
+  __attribute__ ((always_inline)) zp ()
+  {
+hy = xg::fw ();
+  }
+
+private:
+  int *hy;
+};
+
+void
+e5 ()
+{
+  zp ix;
+}
--
2.29.2

Re: [RFC] Decrease default timeout for libstdc++ tests to 6 minutes

[Jonathan Wakely via Gcc-patches]

On 01/12/20 10:52 +, Jonathan Wakely wrote:

On 01/12/20 10:45 +0100, Christophe Lyon wrote:

On Mon, 30 Nov 2020 at 15:58, Jonathan Wakely  wrote:


On 27/11/20 21:17 +0100, Christophe Lyon via Libstdc++ wrote:

On Fri, 27 Nov 2020 at 17:13, Jonathan Wakely via Gcc-patches
 wrote:


The default for the GCC testsuite is 300, i.e. 5 minutes, which is the
same as the DejaGnu default.

Libstdc++ overrides this to 600, i.e. 10 minutes.

This seems ridiculously long. If any test takes that long on modern
hardware, something is wrong. We've seen this a lot recently with
buggy tests, and waiting for them to FAIL is tedious.

I've already made libstdc++.exp respect the user's setting in
~/.dejagnurc or the global site.exp file. This means anybody testing
on slow simulators or old hardware can choose their own timeout.

I've added dg-timeout-factor to the slowest std::regex tests and have
a patch to do it for the PSTL tests, which both take far too long to
compile. That means you can choose a sensible timeout appropriate for
most tests (e.g. 60 seconds) and not get spurious failures from the
few dozen tests which are just very slow.

I'd like to change the default to 6 minutes. If that goes well, I'd
like to lower it even further.

The main benefit of this will be that buggy tests which hang will get
killed sooner, so we waste less time waiting for the inevitable
timeout.



I think that's a good idea, I did have problems sometimes when
many tests timed out, causing the whole 'make check' to be
killed before completion by our compute farm management system.


Thanks for the feedback. I've pushed this patch now.

It's been tested on powercp64le-linux, x86_64-linux, aarch64-linux,
sparc-solaris and powerpc-aix. They were all fine with much lower
defaults (e.g. 120 seconds). Let's see how this goes for people
testing on older or less powerful hardware.



FTR, I've seen two occurrences of a random timeout:
WARNING: program timed out.
27_io/basic_istream/get/wchar_t/lwg3464.cc execution test (reason: NONE)
FAIL: 27_io/basic_istream/get/wchar_t/lwg3464.cc execution test

when testing for aarch64-none-elf with -mabi=ilp32 using Arm's
Foundation Model as simulator (an old release).


Yes, that test only runs for target { ! lp64 } and does quite a lot of
work. It should compile quite quickly, but takes a long time to run
compared to most tests.

I've add dg-timeout-factor to it and its narrow char counterpart.


Similarly for a couple more tests which do extra work on 32-bit
targets.

Tested x86_64-linux, pushed to trunk.

commit 8b2c3b5af3da8d06a59276721263c7f326ed64fd
Author: Jonathan Wakely 
Date:   Wed Dec 2 12:34:20 2020

libstdc++: Use longer timeout for istream::gcount() overflow tests

On targets with 32-bit poitners these tests do extra work, so give them
longer to run.

libstdc++-v3/ChangeLog:

* testsuite/27_io/basic_istream/ignore/char/94749.cc: Add
dg-timeout-factor for ilp32 targets.
* testsuite/27_io/basic_istream/ignore/wchar_t/94749.cc:
Likewise.

diff --git a/libstdc++-v3/testsuite/27_io/basic_istream/ignore/char/94749.cc b/libstdc++-v3/testsuite/27_io/basic_istream/ignore/char/94749.cc
index 21097c2bff1..63b652dc77b 100644
--- a/libstdc++-v3/testsuite/27_io/basic_istream/ignore/char/94749.cc
+++ b/libstdc++-v3/testsuite/27_io/basic_istream/ignore/char/94749.cc
@@ -17,6 +17,7 @@
 
 // { dg-do run }
 // { dg-options "-DSIMULATOR_TEST" { target simulator } }
+// { dg-timeout-factor 2 { target ilp32 } }
 
 // PR libstdc++/94749
 // basic_istream::ignore(n, c) discards n+1 if next character is equal to c.
diff --git a/libstdc++-v3/testsuite/27_io/basic_istream/ignore/wchar_t/94749.cc b/libstdc++-v3/testsuite/27_io/basic_istream/ignore/wchar_t/94749.cc
index 2473588d307..dcf0fee4906 100644
--- a/libstdc++-v3/testsuite/27_io/basic_istream/ignore/wchar_t/94749.cc
+++ b/libstdc++-v3/testsuite/27_io/basic_istream/ignore/wchar_t/94749.cc
@@ -17,6 +17,7 @@
 
 // { dg-do run }
 // { dg-options "-DSIMULATOR_TEST" { target simulator } }
+// { dg-timeout-factor 2 { target ilp32 } }
 
 // PR libstdc++/94749
 // basic_istream::ignore(n, c) discards n+1 if next character is equal to c.

[PATCH] c++: Change __builtin_source_location to use __PRETTY_FUNCTION__ instead of __FUNCTION__ [PR80780]

[Jakub Jelinek via Gcc-patches]

Hi!

On Tue, Dec 01, 2020 at 01:03:52PM +, Jonathan Wakely via Gcc-patches wrote:
> I mentioned in PR 80780 that a __builtin__PRETTY_FUNCTION would have
> been nice, because __FUNCTION__ isn't very useful for C++, because of
> overloading and namespace/class scopes. There are an unlimited number
> of functions that have __FUNCTION__ == "s", e.g. "ns::s(int)" and
> "ns::s()" and "another_scope::s::s(T...)" etc.
> 
> Since __builtin_source_location() can do whatever it wants (without
> needing to add __builtin__PRETTY_FUNCTION) it might be nice to use the
> __PRETTY_FUNCTION__ string. JeanHeyd's tests would still need changes,
> because the name would be "s::s(void*)" not "s::s" but that still
> seems better for users.

When I've added template tests for the previous patch, I have noticed that
the current __builtin_source_location behavior is not really __FUNCTION__,
just close, because e.g. in function template __FUNCTION__ is still
"bar" but __builtin_source_location gave "bar<0>".

Anyway, this patch implements above request to follow __PRETTY_FUNCTION__
(on top of the earlier posted patch).

Tested on x86_64-linux, ok for trunk if it passes full bootstrap/regtest on
x86_64-linux?

2020-12-02  Jakub Jelinek  

PR c++/80780
* cp-gimplify.c (fold_builtin_source_location): Use 2 instead of 0
as last argument to cxx_printable_name.

* g++.dg/cpp2a/srcloc1.C (quux): Use __PRETTY_FUNCTION__ instead of
function.
* g++.dg/cpp2a/srcloc2.C (quux): Likewise.
* g++.dg/cpp2a/srcloc15.C (S::S): Likewise.
(bar): Likewise.  Adjust expected column.
* g++.dg/cpp2a/srcloc17.C (S::S): Likewise.
(bar): Likewise.  Adjust expected column.

--- gcc/cp/cp-gimplify.c.jj 2020-12-02 12:26:21.596922205 +0100
+++ gcc/cp/cp-gimplify.c2020-12-02 13:16:48.599284262 +0100
@@ -3001,7 +3001,7 @@ fold_builtin_source_location (location_t
  const char *name = "";
 
  if (current_function_decl)
-   name = cxx_printable_name (current_function_decl, 0);
+   name = cxx_printable_name (current_function_decl, 2);
 
  val = build_string_literal (strlen (name) + 1, name);
}
--- gcc/testsuite/g++.dg/cpp2a/srcloc1.C.jj 2020-07-28 15:39:10.012756173 
+0200
+++ gcc/testsuite/g++.dg/cpp2a/srcloc1.C2020-12-02 13:17:39.010708329 
+0100
@@ -88,7 +88,7 @@ quux ()
   const char *file1 = source_location::current ().file_name ();
   const char *file2 = __FILE__;
   const char *function1 = source_location::current ().function_name ();
-  const char *function2 = __FUNCTION__;
+  const char *function2 = __PRETTY_FUNCTION__;
   int line1 = source_location::current ().line ();
   int line2 = __LINE__ - 1;
   int column
--- gcc/testsuite/g++.dg/cpp2a/srcloc2.C.jj 2020-07-28 15:39:10.012756173 
+0200
+++ gcc/testsuite/g++.dg/cpp2a/srcloc2.C2020-12-02 13:17:51.851562576 
+0100
@@ -92,7 +92,7 @@ quux ()
   const char *file1 = source_location::current ().file_name ();
   const char *file2 = __FILE__;
   const char *function1 = source_location::current ().function_name ();
-  const char *function2 = __FUNCTION__;
+  const char *function2 = __PRETTY_FUNCTION__;
   int line1 = source_location::current ().line ();
   int line2 = __LINE__ - 1;
   int column
--- gcc/testsuite/g++.dg/cpp2a/srcloc15.C.jj2020-12-02 12:48:20.592828477 
+0100
+++ gcc/testsuite/g++.dg/cpp2a/srcloc15.C   2020-12-02 13:20:46.768577089 
+0100
@@ -44,12 +44,12 @@ struct S {
   source_location loc = source_location::current ();
 
   constexpr S (int l, source_location loc = source_location::current ())
-  : func(__FUNCTION__), line(l), loc(loc)
+  : func(__PRETTY_FUNCTION__), line(l), loc(loc)
   {}
 
   constexpr S (double)
-  : func(__FUNCTION__), line(__LINE__)
-  // ^ column 38
+  : func(__PRETTY_FUNCTION__), line(__LINE__)
+  //^ column 45
   {}
 };
 
@@ -73,7 +73,7 @@ bar ()
   //^ column 49
   const source_location *d[3] = { &a, &b, &c };
   const char *file1 = __FILE__;
-  const char *function1 = __FUNCTION__;
+  const char *function1 = __PRETTY_FUNCTION__;
   for (int j = 0; j < 3; j++)
 {
   int i= 0;
@@ -104,7 +104,7 @@ bar ()
 return false;
   if (e.loc.column () != 9)
 return false;
-  if (f.loc.column () != 38)
+  if (f.loc.column () != 45)
 return false;
   return true;
 }
--- gcc/testsuite/g++.dg/cpp2a/srcloc17.C.jj2020-12-02 12:58:26.113904280 
+0100
+++ gcc/testsuite/g++.dg/cpp2a/srcloc17.C   2020-12-02 13:21:11.943291326 
+0100
@@ -46,12 +46,12 @@ struct S {
   source_location loc = source_location::current ();
 
   constexpr S (int l, source_location loc = source_location::current ())
-  : func(__FUNCTION__), line(l), loc(loc)
+  : func(__PRETTY_FUNCTION__), line(l), loc(loc)
   {}
 
   constexpr S (double)
-  : func(__FUNCTION__), line(__LINE__)
- 

[committed] libstdc++: Fix null pointer dereferences in __gnu_cxx::rope

[Jonathan Wakely via Gcc-patches]

This fixes UBsan errors like:

/usr/include/c++/10/ext/ropeimpl.h:593:9: runtime error: member access within 
null pointer of type 'struct _RopeRep'
/usr/include/c++/10/ext/ropeimpl.h:593:9: runtime error: member call on null 
pointer of type 'struct _Rope_rep_base'
/usr/include/c++/10/ext/rope:556:17: runtime error: reference binding to null 
pointer of type 'struct allocator_type'
/usr/include/c++/10/ext/ropeimpl.h:593:9: runtime error: reference binding to 
null pointer of type 'struct allocator_type'
/usr/include/c++/10/ext/rope:1700:30: runtime error: member call on null 
pointer of type 'struct new_allocator'
/usr/include/c++/10/ext/new_allocator.h:105:29: runtime error: member call on 
null pointer of type 'struct new_allocator'
/usr/include/c++/10/ext/rope:1702:26: runtime error: reference binding to null 
pointer of type 'const struct allocator'
/usr/include/c++/10/bits/allocator.h:148:34: runtime error: reference binding 
to null pointer of type 'const struct new_allocator'
/usr/include/c++/10/ext/rope:1664:39: runtime error: reference binding to null 
pointer of type 'const struct allocator'
/usr/include/c++/10/ext/rope:1665:9: runtime error: reference binding to null 
pointer of type 'const struct allocator_type'
/usr/include/c++/10/ext/rope:725:36: runtime error: reference binding to null 
pointer of type 'const struct allocator_type'
/usr/include/c++/10/ext/rope:614:64: runtime error: reference binding to null 
pointer of type 'const struct allocator_type'

The problem is calling r->_M_get_allocator() when r is null.

Tested powerpc64le-linux. Committed to trunk.

commit 74270a546cf75aad5e2db642b4715728d4da7904
Author: Jonathan Wakely 
Date:   Wed Dec 2 12:29:00 2020

libstdc++: Fix null pointer dereferences in __gnu_cxx::rope

This fixes UBsan errors like:

/usr/include/c++/10/ext/ropeimpl.h:593:9: runtime error: member access 
within null pointer of type 'struct _RopeRep'
/usr/include/c++/10/ext/ropeimpl.h:593:9: runtime error: member call on 
null pointer of type 'struct _Rope_rep_base'
/usr/include/c++/10/ext/rope:556:17: runtime error: reference binding to 
null pointer of type 'struct allocator_type'
/usr/include/c++/10/ext/ropeimpl.h:593:9: runtime error: reference binding 
to null pointer of type 'struct allocator_type'
/usr/include/c++/10/ext/rope:1700:30: runtime error: member call on null 
pointer of type 'struct new_allocator'
/usr/include/c++/10/ext/new_allocator.h:105:29: runtime error: member call 
on null pointer of type 'struct new_allocator'
/usr/include/c++/10/ext/rope:1702:26: runtime error: reference binding to 
null pointer of type 'const struct allocator'
/usr/include/c++/10/bits/allocator.h:148:34: runtime error: reference 
binding to null pointer of type 'const struct new_allocator'
/usr/include/c++/10/ext/rope:1664:39: runtime error: reference binding to 
null pointer of type 'const struct allocator'
/usr/include/c++/10/ext/rope:1665:9: runtime error: reference binding to 
null pointer of type 'const struct allocator_type'
/usr/include/c++/10/ext/rope:725:36: runtime error: reference binding to 
null pointer of type 'const struct allocator_type'
/usr/include/c++/10/ext/rope:614:64: runtime error: reference binding to 
null pointer of type 'const struct allocator_type'

The problem is calling r->_M_get_allocator() when r is null.

libstdc++-v3/ChangeLog:

* include/ext/rope (rope::_S_concat_char_iter)
(rope::_S_destr_concat_char_iter): Add allocator parameter.
(rope::push_back, rope::append, rope::insert, operator+):
Pass allocator.
* include/ext/ropeimpl.h (rope::_S_concat_char_iter)
(rope::_S_destr_concat_char_iter): Add allocator parameter
and use it.
(_Rope_char_ref_proxy::operator=(_CharT)): Pass allocator.

diff --git a/libstdc++-v3/include/ext/rope b/libstdc++-v3/include/ext/rope
index 8479acd8f74..de6ecdd524f 100644
--- a/libstdc++-v3/include/ext/rope
+++ b/libstdc++-v3/include/ext/rope
@@ -1612,19 +1612,21 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   static _RopeRep* _S_concat_char_iter(_RopeRep* __r,
   const _CharT* __iter,
-  size_type __slen);
-  // Concatenate rope and char ptr, copying __s.
+  size_type __slen,
+  allocator_type& __a);
+  // Concatenate rope and char ptr, copying __iter.
   // Should really take an arbitrary iterator.
   // Result is counted in refcount.
   static _RopeRep* _S_destr_concat_char_iter(_RopeRep* __r,
 const _CharT* __iter,
-size_type __slen)
+size_type __slen,
+allocator_type& __a)

[committed] libstdc++: Fix indentation in rope

[Jonathan Wakely via Gcc-patches]

libstdc++-v3/ChangeLog:

* include/ext/rope: Fix indentation of access specifiers.

Tested powerpc64le-linux. Committed to trunk.

commit d38fbb5a863dfc00631c74a525a908cef620e149
Author: Jonathan Wakely 
Date:   Wed Dec 2 11:25:42 2020

libstdc++: Fix indentation in rope

libstdc++-v3/ChangeLog:

* include/ext/rope: Fix indentation of access specifiers.

diff --git a/libstdc++-v3/include/ext/rope b/libstdc++-v3/include/ext/rope
index 08e510bb0dc..8479acd8f74 100644
--- a/libstdc++-v3/include/ext/rope
+++ b/libstdc++-v3/include/ext/rope
@@ -675,7 +675,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   static void _S_ref(_Rope_RopeRep*) { }
   static void _S_free_if_unref(_Rope_RopeRep*) { }
 #   endif
-protected:
+protected:
   _Rope_RopeRep&
   operator=(const _Rope_RopeRep&);
 
@@ -742,7 +742,7 @@ protected:
this->__STL_FREE_STRING(_M_data, this->_M_size, 
this->_M_get_allocator());
   }
 #endif
-protected:
+protected:
   _Rope_RopeLeaf&
   operator=(const _Rope_RopeLeaf&);
 
@@ -778,7 +778,7 @@ protected:
_M_right->_M_unref_nonnil();
   }
 #endif
-protected:
+protected:
   _Rope_RopeConcatenation&
   operator=(const _Rope_RopeConcatenation&);
   
@@ -1508,7 +1508,7 @@ protected:
   __ROPE_DEFINE_ALLOCS(_Alloc)
 #undef __ROPE_DEFINE_ALLOC
 
-   protected:
+protected:
   _Rope_base&
   operator=(const _Rope_base&);