Re: [PATCH][RFC] Introduce BIT_FIELD_INSERT

[Richard Biener]

On Mon, 16 Dec 2019, Andrew Pinski wrote:

> On Thu, Nov 15, 2018 at 12:31 AM Richard Biener  wrote:
> >
> > On Thu, 15 Nov 2018, Richard Biener wrote:
> >
> > > On Wed, 14 Nov 2018, Andrew Pinski wrote:
> > >
> > > > On Fri, May 13, 2016 at 3:51 AM Richard Biener  
> > > > wrote:
> > > > >
> > > > >
> > > > > The following patch adds BIT_FIELD_INSERT, an operation to
> > > > > facilitate doing bitfield inserts on registers (as opposed
> > > > > to currently where we'd have a BIT_FIELD_REF store).
> > > > >
> > > > > Originally this was developed as part of bitfield lowering
> > > > > where bitfield stores were lowered into read-modify-write
> > > > > cycles and the modify part, instead of doing shifting and masking,
> > > > > be kept in a more high-level form to ease combining them.
> > > > >
> > > > > A second use case (the above is still valid) is vector element
> > > > > inserts which we currently can only do via memory or
> > > > > by extracting all components and re-building the vector using
> > > > > a CONSTRUCTOR.  For this second use case I added code
> > > > > re-writing the BIT_FIELD_REF stores the C family FEs produce
> > > > > into BIT_FIELD_INSERT when update-address-taken can otherwise
> > > > > re-write a decl into SSA form (the testcase shows we miss
> > > > > a similar opportunity with the MEM_REF form of a vector insert,
> > > > > I plan to fix that for the final submission).
> > > > >
> > > > > One speciality of BIT_FIELD_INSERT as opposed to BIT_FIELD_REF
> > > > > is that the size of the insertion is given implicitely via the
> > > > > type size/precision of the value to insert.  That avoids
> > > > > introducing ways to have quaternary ops in folding and GIMPLE stmts.
> > > > >
> > > > > Bootstrapped and tested on x86_64-unknown-linux-gnu.
> > > > >
> > > > > Richard.
> > > > >
> > > > > 2011-06-16  Richard Guenther  
> > > > >
> > > > > PR tree-optimization/29756
> > > > > * tree.def (BIT_FIELD_INSERT): New tcc_expression tree code.
> > > > > * expr.c (expand_expr_real_2): Handle BIT_FIELD_INSERT.
> > > > > * fold-const.c (operand_equal_p): Likewise.
> > > > > (fold_ternary_loc): Add constant folding of BIT_FIELD_INSERT.
> > > > > * gimplify.c (gimplify_expr): Handle BIT_FIELD_INSERT.
> > > > > * tree-inline.c (estimate_operator_cost): Likewise.
> > > > > * tree-pretty-print.c (dump_generic_node): Likewise.
> > > > > * tree-ssa-operands.c (get_expr_operands): Likewise.
> > > > > * cfgexpand.c (expand_debug_expr): Likewise.
> > > > > * gimple-pretty-print.c (dump_ternary_rhs): Likewise.
> > > > > * gimple.c (get_gimple_rhs_num_ops): Handle BIT_FIELD_INSERT.
> > > > > * tree-cfg.c (verify_gimple_assign_ternary): Verify 
> > > > > BIT_FIELD_INSERT.
> > > > >
> > > > > * tree-ssa.c (non_rewritable_lvalue_p): We can rewrite
> > > > > vector inserts using BIT_FIELD_REF on the lhs.
> > > > > (execute_update_addresses_taken): Do it.
> > > > >
> > > > > * gcc.dg/tree-ssa/vector-6.c: New testcase.
> > > > >
> > > > > Index: trunk/gcc/expr.c
> > > > > ===
> > > > > *** trunk.orig/gcc/expr.c   2016-05-12 13:40:30.704262951 +0200
> > > > > --- trunk/gcc/expr.c2016-05-12 15:40:32.481225744 +0200
> > > > > *** expand_expr_real_2 (sepops ops, rtx targ
> > > > > *** 9358,9363 
> > > > > --- 9358,9380 
> > > > > target = expand_vec_cond_expr (type, treeop0, treeop1, 
> > > > > treeop2, target);
> > > > > return target;
> > > > >
> > > > > + case BIT_FIELD_INSERT:
> > > > > +   {
> > > > > +   unsigned bitpos = tree_to_uhwi (treeop2);
> > > > > +   unsigned bitsize;
> > > > > +   if (INTEGRAL_TYPE_P (TREE_TYPE (treeop1)))
> > > > > + bitsize = TYPE_PRECISION (TREE_TYPE (treeop1));
> > > > > +   else
> > > > > + bitsize = tree_to_uhwi (TYPE_SIZE (TREE_TYPE (treeop1)));
> > > > > +   rtx op0 = expand_normal (treeop0);
> > > > > +   rtx op1 = expand_normal (treeop1);
> > > > > +   rtx dst = gen_reg_rtx (mode);
> > > > > +   emit_move_insn (dst, op0);
> > > > > +   store_bit_field (dst, bitsize, bitpos, 0, 0,
> > > > > +TYPE_MODE (TREE_TYPE (treeop1)), op1, false);
> > > > > +   return dst;
> > > > > +   }
> > > > > +
> > > > >   default:
> > > > > gcc_unreachable ();
> > > > >   }
> > > > > Index: trunk/gcc/fold-const.c
> > > > > ===
> > > > > *** trunk.orig/gcc/fold-const.c 2016-05-12 13:40:30.704262951 +0200
> > > > > --- trunk/gcc/fold-const.c  2016-05-13 09:41:13.509812127 +0200
> > > > > *** operand_equal_p (const_tree arg0, const_
> > > > > *** 3163,3168 
> > > > > --- 3163,3169 
> > > > >
> > > > > case VEC_COND_EXPR:
> > > > > case DOT_PROD_EXPR:
> 

Re: [testsuite][arm] Remove xfail for vect-epilogues test

[Richard Biener]

On Fri, 13 Dec 2019, Andre Vieira (lists) wrote:

> Consequently whilst looking at the list I noticed these two were missing.
> 
> This OK for trunk?

Yes.

Thanks,
Richard.

> gcc/ChangeLog:
> 2019-12-13  Andre Vieira  
> 
> * doc/sourcebuild.texi (arm_little_endian, arm_nothumb):
> Documented existing target checks.
> 
> On 13/12/2019 13:05, Andre Vieira (lists) wrote:
> > Thanks for pointing it out Rainer. Thanks to that reminder I noticed there
> > is a different way to achieve this without adding that extra target check.
> > 
> > This OK?
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > 2019-12-12  Andre Vieira  
> > 
> >      * gcc.dg/vect/vect-epilogues.c: XFAIL for arm big endian.
> > 
> > On 12/12/2019 17:41, Rainer Orth wrote:
> >> Hi Andre,
> >>
> >>> gcc/testsuite/ChangeLog:
> >>>
> >>> 2019-12-12  Andre Vieira  
> >>>
> >>>  * gcc.dg/vect/vect-epilogues.c: XFAIL for arm big endian.
> >>>  * lib/target-supports.exp
> >>> (check_effective_target_arm_big_endian):
> >>>  New target selector.
> >>
> >> as always, this needs documenting in sourcebuild.texi.
> >>
> >> Rainer
> >>
> 

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

[PATCH] Small ccp optimization for x * x (PR tree-optimization/93156)

[Jakub Jelinek]

Hi!

In x * x = ((x & -2) + (x & 1))^2 = ((x^2) & -4) + 2 * (x & -2) * (x & 1) + (x 
& 1)^2
the first two terms are divisible by 4 and the last one is 0 or 1, so
(x * x) % 4U <= 1
and thus bit ccp can assume he second least significant bit of any power of two 
is
0.

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

2020-01-07  Jakub Jelinek  

PR tree-optimization/93156
* tree-ssa-ccp.c (bit_value_binop): For x * x note that the second
least significant bit is always clear.

* gcc.dg/tree-ssa/pr93156.c: New test.

--- gcc/tree-ssa-ccp.c.jj   2020-01-01 12:15:48.026609558 +0100
+++ gcc/tree-ssa-ccp.c  2020-01-06 15:39:16.807109578 +0100
@@ -1650,6 +1650,17 @@ bit_value_binop (enum tree_code code, tr
   TYPE_SIGN (TREE_TYPE (rhs2)), TYPE_PRECISION (TREE_TYPE 
(rhs2)),
   value_to_wide_int (r2val), r2val.mask);
 
+  /* (x * x) & 2 == 0.  */
+  if (code == MULT_EXPR && rhs1 == rhs2 && TYPE_PRECISION (type) > 1)
+{
+  widest_int m = 2;
+  if (wi::sext (mask, TYPE_PRECISION (type)) != -1)
+   value = wi::bit_and_not (value, m);
+  else
+   value = 0;
+  mask = wi::bit_and_not (mask, m);
+}
+
   if (wi::sext (mask, TYPE_PRECISION (type)) != -1)
 {
   val.lattice_val = CONSTANT;
--- gcc/testsuite/gcc.dg/tree-ssa/pr93156.c.jj  2020-01-06 15:26:57.750286597 
+0100
+++ gcc/testsuite/gcc.dg/tree-ssa/pr93156.c 2020-01-06 15:40:32.987957791 
+0100
@@ -0,0 +1,23 @@
+/* PR tree-optimization/93156 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+/* { dg-final { scan-tree-dump-times "return 0;" 3 "optimized" } } */
+
+int
+foo (int x)
+{
+  return (x * x) & 2;
+}
+
+unsigned long long
+bar (unsigned long long x)
+{
+  return (x * x) & 2;
+}
+
+int
+baz (int x)
+{
+  x &= -2;
+  return (x * x) & 3;
+}

Jakub

[committed] Fix UB in gfc_trans_omp_clauses (PR fortran/93162)

[Jakub Jelinek]

Hi!

When I wrote the code, for map clause the arguments couldn't contain any
REF_COMPONENT (nor REF_UNQUIRY nor REF_SUBSTRING) and therefore it was
ok (although unclean) to just look at u.ar.type, but now that REF_COMPONENT
can appear there (so far for OpenACC only, although OpenMP 5.0 also allows
it), that is no longer the case.  Not really sure if the code doesn't need
further changes (how will e.g. var%comp(:) be handled in the mapping
clauses?), but this conditional is clearly wrong.

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

2020-01-07  Jakub Jelinek  

PR fortran/93162
* trans-openmp.c (gfc_trans_omp_clauses): Check for REF_ARRAY type
before testing u.ar.type == AR_FULL.

--- gcc/fortran/trans-openmp.c.jj   2020-01-04 00:14:28.511400132 +0100
+++ gcc/fortran/trans-openmp.c  2020-01-06 17:01:10.538816323 +0100
@@ -2495,7 +2495,9 @@ gfc_trans_omp_clauses (stmtblock_t *bloc
  tree decl = gfc_trans_omp_variable (n->sym, false);
  if (DECL_P (decl))
TREE_ADDRESSABLE (decl) = 1;
- if (n->expr == NULL || n->expr->ref->u.ar.type == AR_FULL)
+ if (n->expr == NULL
+ || (n->expr->ref->type == REF_ARRAY
+ && n->expr->ref->u.ar.type == AR_FULL))
{
  tree present = gfc_omp_check_optional_argument (decl, true);
  if (n->sym->ts.type == BT_CLASS)

Jakub

Re: [PATCH] ipa-inline: Adjust condition for caller_growth_limits

[luoxhu]

On 2020/1/7 02:01, Jeff Law wrote:

On Mon, 2020-01-06 at 01:03 -0600, Xiong Hu Luo wrote:

Inline should return failure either (newsize > param_large_function_insns)
OR (newsize > limit).  Sometimes newsize is larger than
param_large_function_insns, but smaller than limit, inline doesn't return
failure even if the new function is a large function.
Therefore, param_large_function_insns and param_large_function_growth should be
OR instead of AND, otherwise --param large-function-growth won't
work correctly with --param large-function-insns.

gcc/ChangeLog:

2020-01-06  Luo Xiong Hu  

ipa-inline-analysis.c (estimate_growth): Fix typo.
ipa-inline.c (caller_growth_limits): Use OR instead of AND.

OK
jeff


Thanks, committed in r279942.

XiongHu

Re: [PATCH, committed] V11 patch #5 of 15, Optimize vec_extract of a vector in memory with a PC-relative address

[Michael Meissner]

On Tue, Dec 24, 2019 at 10:24:55AM -0600, Segher Boessenkool wrote:
> Hi!
> 
> On Fri, Dec 20, 2019 at 06:55:53PM -0500, Michael Meissner wrote:
> > * config/rs6000/rs6000.c (rs6000_reg_to_addr_mask): New helper
> > function to identify the address mask of a hard register.
> 
> Do this as a separate patch please.  That refactoring is pre-approved.
> Please explain in the function comment what an "address mask" is.  Or
> better yet, don't call it a "mask", it isn't a mask?

I committed this patch for the refactoring (subversion id 279941).  I will
submit the other pieces later.

2020-01-06  Michael Meissner  

* config/rs6000/rs6000.c (hard_reg_and_mode_to_addr_mask): New
helper function to return the valid addressing formats for a given
hard register and mode.
(rs6000_adjust_vec_address): Call hard_reg_and_mode_to_addr_mask.

Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 279912)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -6729,6 +6729,30 @@ rs6000_expand_vector_extract (rtx target
 }
 }
 
+/* Helper function to return an address mask based on a physical register.  */
+
+static addr_mask_type
+hard_reg_and_mode_to_addr_mask (rtx reg, machine_mode mode)
+{
+  unsigned int r = reg_or_subregno (reg);
+  addr_mask_type addr_mask;
+
+  gcc_assert (HARD_REGISTER_NUM_P (r));
+  if (INT_REGNO_P (r))
+addr_mask = reg_addr[mode].addr_mask[RELOAD_REG_GPR];
+
+  else if (FP_REGNO_P (r))
+addr_mask = reg_addr[mode].addr_mask[RELOAD_REG_FPR];
+
+  else if (ALTIVEC_REGNO_P (r))
+addr_mask = reg_addr[mode].addr_mask[RELOAD_REG_VMX];
+
+  else
+gcc_unreachable ();
+
+  return addr_mask;
+}
+
 /* Adjust a memory address (MEM) of a vector type to point to a scalar field
within the vector (ELEMENT) with a mode (SCALAR_MODE).  Use a base register
temporary (BASE_TMP) to fixup the address.  Return the new memory address
@@ -6865,21 +6889,8 @@ rs6000_adjust_vec_address (rtx scalar_re
   if (GET_CODE (new_addr) == PLUS)
 {
   rtx op1 = XEXP (new_addr, 1);
-  addr_mask_type addr_mask;
-  unsigned int scalar_regno = reg_or_subregno (scalar_reg);
-
-  gcc_assert (HARD_REGISTER_NUM_P (scalar_regno));
-  if (INT_REGNO_P (scalar_regno))
-   addr_mask = reg_addr[scalar_mode].addr_mask[RELOAD_REG_GPR];
-
-  else if (FP_REGNO_P (scalar_regno))
-   addr_mask = reg_addr[scalar_mode].addr_mask[RELOAD_REG_FPR];
-
-  else if (ALTIVEC_REGNO_P (scalar_regno))
-   addr_mask = reg_addr[scalar_mode].addr_mask[RELOAD_REG_VMX];
-
-  else
-   gcc_unreachable ();
+  addr_mask_type addr_mask
+   = hard_reg_and_mode_to_addr_mask (scalar_reg, scalar_mode);
 
   if (REG_P (op1) || SUBREG_P (op1))
valid_addr_p = (addr_mask & RELOAD_REG_INDEXED) != 0;

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

Re: [PATCH, committed] V11 patch #4 of 15, Update 'Q' constraint documentation.

[Michael Meissner]

On Sun, Dec 22, 2019 at 11:49:19AM -0600, Segher Boessenkool wrote:
> On Fri, Dec 20, 2019 at 06:49:30PM -0500, Michael Meissner wrote:
> > In doing V11 patch #3, I noticed that the documentation for the 'Q' was
> > misleading.
> 
> It originally was used just for lswi/stswi, which can access up to the
> first 32 bytes of storage pointed to by the register.  But yes, the
> current comment is confusing.
> 
> > * config/rs6000/constraints.md (Q constraint): Update
> > documentation.
> > * doc/md.tet (PowerPC constraints): Update 'Q' constraint
> > documentation.
> 
> "md.tet"?  That's an interesting typo :-)
> 
> >  (define_memory_constraint "Q"
> > -  "Memory operand that is an offset from a register (it is usually better
> > -to use @samp{m} or @samp{es} in @code{asm} statements)"
> > +  "A memory operand whose address which uses a single register with no 
> > offset."
> 
> Arm has
> 
> (define_memory_constraint "Q"
>  "@internal
>   An address that is a single base register."
>  (and (match_code "mem")
>   (match_test "REG_P (XEXP (op, 0))")))
> 
> which is more correct for us (the register cannot be r0!)
> 
> But it is not an address.
> 
> Maybe "A memory operand addressed by just a base register." ?
> 
> Okay for trunk like that.  Thanks!

This is the patch I committed (subversion ids 279939 and 279940).

2020-01-06  Michael Meissner  

* config/rs6000/constraints.md (Q constraint): Update
documentation.
* doc/md.texi (RS/6000 constraints): Update 'Q' cosntraint
documentation.

Index: gcc/config/rs6000/constraints.md
===
--- gcc/config/rs6000/constraints.md(revision 279910)
+++ gcc/config/rs6000/constraints.md(working copy)
@@ -211,8 +211,7 @@ several times, or that might not access
(match_test "GET_RTX_CLASS (GET_CODE (XEXP (op, 0))) != RTX_AUTOINC")))
 
 (define_memory_constraint "Q"
-  "Memory operand that is an offset from a register (it is usually better
-to use @samp{m} or @samp{es} in @code{asm} statements)"
+  "A memory operand addressed by just a base register."
   (and (match_code "mem")
(match_test "REG_P (XEXP (op, 0))")))
 
Index: gcc/doc/md.texi
===
--- gcc/doc/md.texi (revision 279910)
+++ gcc/doc/md.texi (working copy)
@@ -3381,8 +3381,7 @@ allowed when @samp{<} or @samp{>} is use
 as @samp{m} without @samp{<} and @samp{>}.
 
 @item Q
-Memory operand that is an offset from a register (it is usually better
-to use @samp{m} or @samp{es} in @code{asm} statements)
+A memory operand addressed by just a base register.
 
 @item Z
 Memory operand that is an indexed or indirect from a register (it is

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

Re: [PATCH, committed] V11 patch #3 of 15, Use 'Q' constraint for variable vector extract from memory

[Michael Meissner]

On Sun, Dec 22, 2019 at 11:24:51AM -0600, Segher Boessenkool wrote:
> Hi!
> 
> On Fri, Dec 20, 2019 at 06:47:28PM -0500, Michael Meissner wrote:
> > Then I realized that eventaully we will want to generate an X-FORM 
> > (register +
> > register) address, and it was just simpler to use the 'Q' constraint, and 
> > have
> > the register allocator put the address into a register.
> 
> Yep, good call.
> 
> > * config/rs6000/vsx.md (vsx_extract__var, VSX_D iterator):
> > Use 'Q' for memory constraints because we need to do an X-FORM
> > load with the variable index.
> > (vsx_extract_v4sf_var): Use 'Q' for memory constraints because we
> > need to do an X-FORM load with the variable index.
> 
> This comment is a headscratcher -- but you shouldn't say "why" in
> changelogs at all, so that is an easy fix ;-)
> 
> > (vsx_extract__var, VSX_EXTRACT_I iterator):Use 'Q' for
> 
> (missing space)
> 
> > memory constraints because we need to do an X-FORM load with the
> > variable index.
> > (vsx_extract__mode_var): Use 'Q' for memory
> > constraints because we need to do an X-FORM load with the variable
> > index.
> 
> (and more)
> 
> > -;; Variable V2DI/V2DF extract
> > +;; Variable V2DI/V2DF extract.  Use 'Q' for the memory because we will
> > +;; ultimately have to convert the address into base + index.
> 
> Maybe just don't write anything at all, since it is hard to explain in a
> few words?  It is clear that "Q" is not a usual constraint, anyway :-)
> 
> Okay for trunk like that.  Thanks!

This is the patch I committed (subversion id 279938):

2020-01-06  Michael Meissner  

* config/rs6000/vsx.md (vsx_extract__var, VSX_D iterator):
Use 'Q' for doing vector extract from memory.
(vsx_extract_v4sf_var): Use 'Q' for doing vector extract from
memory.
(vsx_extract__var, VSX_EXTRACT_I iterator): Use 'Q' for
doing vector extract from memory.
(vsx_extract__mode_var): Use 'Q' for doing vector
extract from memory.

Index: gcc/config/rs6000/vsx.md
===
--- gcc/config/rs6000/vsx.md(revision 279910)
+++ gcc/config/rs6000/vsx.md(working copy)
@@ -3248,7 +3248,7 @@ (define_insn "vsx_vslo_"
 ;; Variable V2DI/V2DF extract
 (define_insn_and_split "vsx_extract__var"
   [(set (match_operand: 0 "gpc_reg_operand" "=v,wa,r")
-   (unspec: [(match_operand:VSX_D 1 "input_operand" "v,m,m")
+   (unspec: [(match_operand:VSX_D 1 "input_operand" "v,Q,Q")
 (match_operand:DI 2 "gpc_reg_operand" "r,r,r")]
UNSPEC_VSX_EXTRACT))
(clobber (match_scratch:DI 3 "=r,,"))
@@ -3318,7 +3318,7 @@ (define_insn_and_split "*vsx_extract_v4s
 ;; Variable V4SF extract
 (define_insn_and_split "vsx_extract_v4sf_var"
   [(set (match_operand:SF 0 "gpc_reg_operand" "=wa,wa,?r")
-   (unspec:SF [(match_operand:V4SF 1 "input_operand" "v,m,m")
+   (unspec:SF [(match_operand:V4SF 1 "input_operand" "v,Q,Q")
(match_operand:DI 2 "gpc_reg_operand" "r,r,r")]
   UNSPEC_VSX_EXTRACT))
(clobber (match_scratch:DI 3 "=r,,"))
@@ -3681,7 +3681,7 @@ (define_insn_and_split "*vsx_extract__var"
   [(set (match_operand: 0 "gpc_reg_operand" "=r,r,r")
(unspec:
-[(match_operand:VSX_EXTRACT_I 1 "input_operand" "v,v,m")
+[(match_operand:VSX_EXTRACT_I 1 "input_operand" "v,v,Q")
  (match_operand:DI 2 "gpc_reg_operand" "r,r,r")]
 UNSPEC_VSX_EXTRACT))
(clobber (match_scratch:DI 3 "=r,r,"))
@@ -3701,7 +3701,7 @@ (define_insn_and_split "*vsx_extract_ 0 "gpc_reg_operand" "=r,r,r")
(zero_extend:
 (unspec:
- [(match_operand:VSX_EXTRACT_I 1 "input_operand" "v,v,m")
+ [(match_operand:VSX_EXTRACT_I 1 "input_operand" "v,v,Q")
   (match_operand:DI 2 "gpc_reg_operand" "r,r,r")]
  UNSPEC_VSX_EXTRACT)))
(clobber (match_scratch:DI 3 "=r,r,"))

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

Re: [PATCH, committed] V11 patch #2 of 15, Use prefixed load for vector extract with large offset

[Michael Meissner]

On Sun, Dec 22, 2019 at 11:10:09AM -0600, Segher Boessenkool wrote:
> The patch is okay for trunk (with the comment moved, and the rtx_equal_p
> fixed).  Thanks!

Here is the patch I committed (subversion id 279937):

2020-01-06  Michael Meissner  

* config/rs6000/rs6000.c (rs6000_adjust_vec_address): Add support
for the offset being 34-bits when -mcpu=future is used.

Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 279910)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -6797,11 +6797,19 @@ rs6000_adjust_vec_address (rtx scalar_re
  HOST_WIDE_INT offset = INTVAL (op1) + INTVAL (element_offset);
  rtx offset_rtx = GEN_INT (offset);
 
- if (IN_RANGE (offset, -32768, 32767)
+ /* 16-bit offset.  */
+ if (SIGNED_INTEGER_16BIT_P (offset)
  && (scalar_size < 8 || (offset & 0x3) == 0))
new_addr = gen_rtx_PLUS (Pmode, op0, offset_rtx);
+
+ /* 34-bit offset if we have prefixed addresses.  */
+ else if (TARGET_PREFIXED_ADDR && SIGNED_INTEGER_34BIT_P (offset))
+   new_addr = gen_rtx_PLUS (Pmode, op0, offset_rtx);
+
  else
{
+ /* Offset overflowed, move offset to the temporary (which will
+likely be split), and do X-FORM addressing.  */
  emit_move_insn (base_tmp, offset_rtx);
  new_addr = gen_rtx_PLUS (Pmode, op0, base_tmp);
}
@@ -6830,6 +6838,12 @@ rs6000_adjust_vec_address (rtx scalar_re
  emit_insn (insn);
}
 
+ /* Make sure we don't overwrite the temporary if the element being
+extracted is variable, and we've put the offset into base_tmp
+previously.  */
+ else if (reg_mentioned_p (base_tmp, element_offset))
+   emit_insn (gen_add2_insn (base_tmp, op1));
+
  else
{
  emit_move_insn (base_tmp, op1);

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

Re: [PATCH] PR C++/92739

[Jason Merrill]

On 12/16/19 6:12 PM, Jason Merrill wrote:

On 12/2/19 9:30 AM, Andrew Sutton wrote:

Find attached.

    gcc/cp/
 * parser.c (cp_parser_constraint_requires_parens): Exclude
attributes
 as postfix expressions.

 gcc/testsuite/
 * g++.dg/concepts-pr92739.C: New test.


The testcase didn't come through in this patch.


I ended up grabbing a testcase from the PR and checking in the patch.

Jason

[C++ PATCH] PR c++/92552 - ICE with inherited constrained default ctor.

[Jason Merrill]

We set TYPE_HAS_USER_CONSTRUCTOR on the template type in lookup_using_decl,
but we didn't copy it to the instantiation.  Setting it in
one_inherited_ctor is too late, as that gets called after we decide whether
to set CLASSTYPE_LAZY_DEFAULT_CTOR.  This change affects other testcases as
well; the changes are fixes for the other inherited constructor tests as
well.

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

* pt.c (instantiate_class_template_1): Copy
TYPE_HAS_USER_CONSTRUCTOR.
* class.c (one_inherited_ctor): Don't set it here.
---
 gcc/cp/class.c |  1 -
 gcc/cp/pt.c|  1 +
 gcc/testsuite/g++.dg/concepts/inherit-ctor3.C  |  4 ++--
 .../g++.dg/cpp2a/concepts-inherit-ctor2.C  |  4 ++--
 .../g++.dg/cpp2a/concepts-inherit-ctor7.C  | 14 ++
 gcc/testsuite/g++.dg/template/crash7.C |  4 +---
 gcc/testsuite/g++.old-deja/g++.pt/error2.C |  2 +-
 7 files changed, 21 insertions(+), 9 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-inherit-ctor7.C

diff --git a/gcc/cp/class.c b/gcc/cp/class.c
index 4da08812702..07abe5298d1 100644
--- a/gcc/cp/class.c
+++ b/gcc/cp/class.c
@@ -3141,7 +3141,6 @@ one_inherited_ctor (tree ctor, tree t, tree using_decl)
   ctor = implicitly_declare_fn (sfk_inheriting_constructor,
t, /*const*/false, ctor, parms);
   add_method (t, ctor, using_decl != NULL_TREE);
-  TYPE_HAS_USER_CONSTRUCTOR (t) = true;
   return;
 }
 
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index bc23e9e0354..cd48f533d5d 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -11544,6 +11544,7 @@ instantiate_class_template_1 (tree type)
   SET_TYPE_ALIGN (type, TYPE_ALIGN (pattern));
   TYPE_USER_ALIGN (type) = TYPE_USER_ALIGN (pattern);
   CLASSTYPE_NON_AGGREGATE (type) = CLASSTYPE_NON_AGGREGATE (pattern);
+  TYPE_HAS_USER_CONSTRUCTOR (type) = TYPE_HAS_USER_CONSTRUCTOR (pattern);
   if (ANON_AGGR_TYPE_P (pattern))
 SET_ANON_AGGR_TYPE_P (type);
   if (CLASSTYPE_VISIBILITY_SPECIFIED (pattern))
diff --git a/gcc/testsuite/g++.dg/concepts/inherit-ctor3.C 
b/gcc/testsuite/g++.dg/concepts/inherit-ctor3.C
index abfe96e8240..dda202f4c24 100644
--- a/gcc/testsuite/g++.dg/concepts/inherit-ctor3.C
+++ b/gcc/testsuite/g++.dg/concepts/inherit-ctor3.C
@@ -11,7 +11,7 @@ template
   };
 
 template
-  struct S2 : S1 { // { dg-error "no matching function" }
+  struct S2 : S1 {
 using S1::S1; // { dg-error "no matching function" }
   };
 
@@ -19,5 +19,5 @@ struct X { } x;
 
 int main() {
   S2 s1(0); // { dg-error "use of deleted function" }
-  S2 s2; // { dg-error "use of deleted function" }
+  S2 s2; // { dg-error "no matching function" }
 }
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-inherit-ctor2.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts-inherit-ctor2.C
index aa244bc04c1..82d14746df2 100644
--- a/gcc/testsuite/g++.dg/cpp2a/concepts-inherit-ctor2.C
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-inherit-ctor2.C
@@ -9,10 +9,10 @@ template
   };
 
 template
-  struct S2 : S1 { // { dg-error "matching" }
+  struct S2 : S1 {
 using S1::S1;
   };
 
 int main() {
-  S2 s; // { dg-error "deleted function" }
+  S2 s; // { dg-error "no matching function" }
 }
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-inherit-ctor7.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts-inherit-ctor7.C
new file mode 100644
index 000..2592b529356
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-inherit-ctor7.C
@@ -0,0 +1,14 @@
+// PR c++/92552
+// { dg-do compile { target concepts } }
+
+template  struct basic_mixin {
+  basic_mixin() requires true;
+};
+template 
+struct mixin : basic_mixin {
+  using basic_mixin::basic_mixin;
+};
+int main() {
+  (void)__is_constructible(mixin);
+  // noexcept(mixin()); also triggers ICE
+}
diff --git a/gcc/testsuite/g++.dg/template/crash7.C 
b/gcc/testsuite/g++.dg/template/crash7.C
index 691628e7878..00d387c1197 100644
--- a/gcc/testsuite/g++.dg/template/crash7.C
+++ b/gcc/testsuite/g++.dg/template/crash7.C
@@ -10,6 +10,4 @@ template  struct A
 template  A(typename A::X) {} // { dg-error "incomplete" }
 };
 
-// We currently don't give the "no match" error because we don't add the
-// invalid constructor template to TYPE_METHODS.
-A a; // { dg-message "required" }
+A a; // { dg-message "no match" }
diff --git a/gcc/testsuite/g++.old-deja/g++.pt/error2.C 
b/gcc/testsuite/g++.old-deja/g++.pt/error2.C
index 2e65718b679..666aea0a1ef 100644
--- a/gcc/testsuite/g++.old-deja/g++.pt/error2.C
+++ b/gcc/testsuite/g++.old-deja/g++.pt/error2.C
@@ -9,7 +9,7 @@ public:
 
 void f ()
 {
-  Test c; // { dg-message "required" }
+  Test c; // { dg-error "no match" }
 }
 
 

base-commit: b0f2d29e5944b0f3f09f217edd4375201ba6a164
-- 
2.18.1

Re: [PATCH] libstdcxx: Update ctype_base.h from NetBSD upstream

[Kamil Rytarowski]

On 07.01.2020 01:28, Jonathan Wakely wrote:
> On 07/01/20 00:18 +0100, Kamil Rytarowski wrote:
>> On 06.01.2020 16:34, Jonathan Wakely wrote:
>>> On 22/12/19 09:36 +1000, Gerald Pfeifer wrote:
 Hi Matthew,

 On Mon, 4 Feb 2019, Matthew Bauer wrote:
> The ctype_base.h file in libstdc++-v3 is out of date for NetBSD. They
> have changed their ctype.h definition. It was updated in their intree
> libstdc++-v3 but not in the GCC one. My understanding is this is a
> straightforward rewrite. I've attached my own patch, but the file can
> be obtained directly here:
>
> http://cvsweb.netbsd.org/bsdweb.cgi/src/external/gpl3/gcc/dist/libstdc%2b%2b-v3/config/os/bsd/netbsd/ctype_base.h
>
>
>
> With the attached patch, libstdc++-v3 can succesfully be built with
> NetBSD headers (along with --disable-libcilkrts).

 I noticed this has not been applied yet, nor seen a follow-up?, and
 also
 noticed it went to the gcc-patches list, but not libstd...@gcc.gnu.org.

 Let me re-address this to libstd...@gcc.gnu.org in the hope the
 maintainers there will have a look.

 Gerald
>>>
 diff --git a/libstdc++-v3/config/os/bsd/netbsd/ctype_base.h
 b/libstdc++-v3/config/os/bsd/netbsd/ctype_base.h
 index ff3ec893974..21eccf9fde1 100644
 --- a/libstdc++-v3/config/os/bsd/netbsd/ctype_base.h
 +++ b/libstdc++-v3/config/os/bsd/netbsd/ctype_base.h
 @@ -38,40 +38,46 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   /// @brief  Base class for ctype.
   struct ctype_base
   {
 -    // Non-standard typedefs.
 -    typedef const unsigned char*    __to_type;

     // NB: Offsets into ctype::_M_table force a particular size
     // on the mask type. Because of this, we don't use an enum.
 -    typedef unsigned char  mask;

 #ifndef _CTYPE_U
 -    static const mask upper    = _U;
 -    static const mask lower = _L;
 -    static const mask alpha = _U | _L;
 -    static const mask digit = _N;
 -    static const mask xdigit = _N | _X;
 -    static const mask space = _S;
 -    static const mask print = _P | _U | _L | _N | _B;
 -    static const mask graph = _P | _U | _L | _N;
 -    static const mask cntrl = _C;
 -    static const mask punct = _P;
 -    static const mask alnum = _U | _L | _N;
 +    // Non-standard typedefs.
 +    typedef const unsigned char*    __to_type;
 +
 +    typedef unsigned char    mask;
 +
 +    static const mask upper    = _U;
 +    static const mask lower    = _L;
 +    static const mask alpha    = _U | _L;
 +    static const mask digit    = _N;
 +    static const mask xdigit    = _N | _X;
 +    static const mask space    = _S;
 +    static const mask print    = _P | _U | _L | _N | _B;
 +    static const mask graph    = _P | _U | _L | _N;
 +    static const mask cntrl    = _C;
 +    static const mask punct    = _P;
 +    static const mask alnum    = _U | _L | _N;
 #else
 -    static const mask upper    = _CTYPE_U;
 -    static const mask lower = _CTYPE_L;
 -    static const mask alpha = _CTYPE_U | _CTYPE_L;
 -    static const mask digit = _CTYPE_N;
 -    static const mask xdigit = _CTYPE_N | _CTYPE_X;
 -    static const mask space = _CTYPE_S;
 -    static const mask print = _CTYPE_P | _CTYPE_U | _CTYPE_L |
 _CTYPE_N | _CTYPE_B;
 -    static const mask graph = _CTYPE_P | _CTYPE_U | _CTYPE_L |
 _CTYPE_N;
 -    static const mask cntrl = _CTYPE_C;
 -    static const mask punct = _CTYPE_P;
 -    static const mask alnum = _CTYPE_U | _CTYPE_L | _CTYPE_N;
 +    typedef const unsigned short*    __to_type;
 +
 +    typedef unsigned short    mask;
 +
 +    static const mask upper    = _CTYPE_U;
 +    static const mask lower    = _CTYPE_L;
 +    static const mask alpha    = _CTYPE_A;
 +    static const mask digit    = _CTYPE_D;
 +    static const mask xdigit    = _CTYPE_X;
 +    static const mask space    = _CTYPE_S;
 +    static const mask print    = _CTYPE_R;
 +    static const mask graph    = _CTYPE_G;
 +    static const mask cntrl    = _CTYPE_C;
 +    static const mask punct    = _CTYPE_P;
 +    static const mask alnum    = _CTYPE_A | _CTYPE_D;
 #endif
 #if __cplusplus >= 201103L
 -    static const mask blank = space;
 +    static const mask blank    = space;
 #endif
   };

 diff --git a/libstdc++-v3/config/os/bsd/netbsd/ctype_configure_char.cc
 b/libstdc++-v3/config/os/bsd/netbsd/ctype_configure_char.cc
 index ed3b7cd0d6a..33358e8f5d8 100644
 --- a/libstdc++-v3/config/os/bsd/netbsd/ctype_configure_char.cc
 +++ b/libstdc++-v3/config/os/bsd/netbsd/ctype_configure_char.cc
 @@ -38,11 +38,9 @@ 

Re: [PATCH] libstdcxx: Update ctype_base.h from NetBSD upstream

[Kamil Rytarowski]

On 07.01.2020 01:26, Jonathan Wakely wrote:
> On 06/01/20 23:20 +0100, Kamil Rytarowski wrote:
>> On 06.01.2020 16:24, Jonathan Wakely wrote:
>>> On 22/12/19 09:36 +1000, Gerald Pfeifer wrote:
 Hi Matthew,

 On Mon, 4 Feb 2019, Matthew Bauer wrote:
> The ctype_base.h file in libstdc++-v3 is out of date for NetBSD. They
> have changed their ctype.h definition. It was updated in their intree
> libstdc++-v3 but not in the GCC one. My understanding is this is a
> straightforward rewrite. I've attached my own patch, but the file can
> be obtained directly here:
>
> http://cvsweb.netbsd.org/bsdweb.cgi/src/external/gpl3/gcc/dist/libstdc%2b%2b-v3/config/os/bsd/netbsd/ctype_base.h
>
>
>
> With the attached patch, libstdc++-v3 can succesfully be built with
> NetBSD headers (along with --disable-libcilkrts).

 I noticed this has not been applied yet, nor seen a follow-up?, and
 also
 noticed it went to the gcc-patches list, but not libstd...@gcc.gnu.org.

 Let me re-address this to libstd...@gcc.gnu.org in the hope the
 maintainers there will have a look.

 Gerald
>>>
 diff --git a/libstdc++-v3/config/os/bsd/netbsd/ctype_base.h
 b/libstdc++-v3/config/os/bsd/netbsd/ctype_base.h
 index ff3ec893974..21eccf9fde1 100644
 --- a/libstdc++-v3/config/os/bsd/netbsd/ctype_base.h
 +++ b/libstdc++-v3/config/os/bsd/netbsd/ctype_base.h
 @@ -38,40 +38,46 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   /// @brief  Base class for ctype.
   struct ctype_base
   {
 -    // Non-standard typedefs.
 -    typedef const unsigned char*    __to_type;

     // NB: Offsets into ctype::_M_table force a particular size
     // on the mask type. Because of this, we don't use an enum.
 -    typedef unsigned char  mask;

 #ifndef _CTYPE_U
 -    static const mask upper    = _U;
 -    static const mask lower = _L;
 -    static const mask alpha = _U | _L;
 -    static const mask digit = _N;
 -    static const mask xdigit = _N | _X;
 -    static const mask space = _S;
 -    static const mask print = _P | _U | _L | _N | _B;
 -    static const mask graph = _P | _U | _L | _N;
 -    static const mask cntrl = _C;
 -    static const mask punct = _P;
 -    static const mask alnum = _U | _L | _N;
 +    // Non-standard typedefs.
 +    typedef const unsigned char*    __to_type;
 +
 +    typedef unsigned char    mask;
 +
 +    static const mask upper    = _U;
 +    static const mask lower    = _L;
 +    static const mask alpha    = _U | _L;
 +    static const mask digit    = _N;
 +    static const mask xdigit    = _N | _X;
 +    static const mask space    = _S;
 +    static const mask print    = _P | _U | _L | _N | _B;
 +    static const mask graph    = _P | _U | _L | _N;
 +    static const mask cntrl    = _C;
 +    static const mask punct    = _P;
 +    static const mask alnum    = _U | _L | _N;
 #else
 -    static const mask upper    = _CTYPE_U;
 -    static const mask lower = _CTYPE_L;
 -    static const mask alpha = _CTYPE_U | _CTYPE_L;
 -    static const mask digit = _CTYPE_N;
 -    static const mask xdigit = _CTYPE_N | _CTYPE_X;
 -    static const mask space = _CTYPE_S;
 -    static const mask print = _CTYPE_P | _CTYPE_U | _CTYPE_L |
 _CTYPE_N | _CTYPE_B;
 -    static const mask graph = _CTYPE_P | _CTYPE_U | _CTYPE_L |
 _CTYPE_N;
 -    static const mask cntrl = _CTYPE_C;
 -    static const mask punct = _CTYPE_P;
 -    static const mask alnum = _CTYPE_U | _CTYPE_L | _CTYPE_N;
 +    typedef const unsigned short*    __to_type;
 +
 +    typedef unsigned short    mask;
>>>
>>> I seem to recall looking at this previously and noting that the change
>>> to ctype_base::mask is an ABI break. It means that code compiled with
>>> old versions of GCC or on old versions of NetBSD will not be ABI
>>> compatible with code compiled by a new GCC on a new version of NetBSD.
>>>
>>> If the NetBSD maintainers are OK with that, then we can go ahead and
>>> change it.
>>>
>>>
>>
>> We are fine with ABI breaks as we bump libstdc++ major on each upgrade
>> in base.
> 
> That affects the libstdc++ built from NetBSD ports collection, but if
> somebody builds GCC themselves using the upstream sources (which is
> what these patches are trying to change) then they don't get that
> bumped major version.
> 
> So if somebody builds GCC 9 themselves, and then builds GCC 10
> themselves on the same machine, they'll get two versions of
> libstdc++.so that are not ABI compatible.
> 
> 

I know, but we don't support this in NetBSD. We ship with our own major
numbers for GCC. If someone wants to maintain out of base or out of
pkgsrc it will have likely more problems than ABI 

Re: [PATCH] libstdcxx: Update ctype_base.h from NetBSD upstream

[Jonathan Wakely]

On 07/01/20 00:18 +0100, Kamil Rytarowski wrote:

On 06.01.2020 16:34, Jonathan Wakely wrote:

On 22/12/19 09:36 +1000, Gerald Pfeifer wrote:

Hi Matthew,

On Mon, 4 Feb 2019, Matthew Bauer wrote:

The ctype_base.h file in libstdc++-v3 is out of date for NetBSD. They
have changed their ctype.h definition. It was updated in their intree
libstdc++-v3 but not in the GCC one. My understanding is this is a
straightforward rewrite. I've attached my own patch, but the file can
be obtained directly here:

http://cvsweb.netbsd.org/bsdweb.cgi/src/external/gpl3/gcc/dist/libstdc%2b%2b-v3/config/os/bsd/netbsd/ctype_base.h


With the attached patch, libstdc++-v3 can succesfully be built with
NetBSD headers (along with --disable-libcilkrts).


I noticed this has not been applied yet, nor seen a follow-up?, and also
noticed it went to the gcc-patches list, but not libstd...@gcc.gnu.org.

Let me re-address this to libstd...@gcc.gnu.org in the hope the
maintainers there will have a look.

Gerald



diff --git a/libstdc++-v3/config/os/bsd/netbsd/ctype_base.h
b/libstdc++-v3/config/os/bsd/netbsd/ctype_base.h
index ff3ec893974..21eccf9fde1 100644
--- a/libstdc++-v3/config/os/bsd/netbsd/ctype_base.h
+++ b/libstdc++-v3/config/os/bsd/netbsd/ctype_base.h
@@ -38,40 +38,46 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  /// @brief  Base class for ctype.
  struct ctype_base
  {
-    // Non-standard typedefs.
-    typedef const unsigned char*    __to_type;

    // NB: Offsets into ctype::_M_table force a particular size
    // on the mask type. Because of this, we don't use an enum.
-    typedef unsigned char  mask;

#ifndef _CTYPE_U
-    static const mask upper    = _U;
-    static const mask lower = _L;
-    static const mask alpha = _U | _L;
-    static const mask digit = _N;
-    static const mask xdigit = _N | _X;
-    static const mask space = _S;
-    static const mask print = _P | _U | _L | _N | _B;
-    static const mask graph = _P | _U | _L | _N;
-    static const mask cntrl = _C;
-    static const mask punct = _P;
-    static const mask alnum = _U | _L | _N;
+    // Non-standard typedefs.
+    typedef const unsigned char*    __to_type;
+
+    typedef unsigned char    mask;
+
+    static const mask upper    = _U;
+    static const mask lower    = _L;
+    static const mask alpha    = _U | _L;
+    static const mask digit    = _N;
+    static const mask xdigit    = _N | _X;
+    static const mask space    = _S;
+    static const mask print    = _P | _U | _L | _N | _B;
+    static const mask graph    = _P | _U | _L | _N;
+    static const mask cntrl    = _C;
+    static const mask punct    = _P;
+    static const mask alnum    = _U | _L | _N;
#else
-    static const mask upper    = _CTYPE_U;
-    static const mask lower = _CTYPE_L;
-    static const mask alpha = _CTYPE_U | _CTYPE_L;
-    static const mask digit = _CTYPE_N;
-    static const mask xdigit = _CTYPE_N | _CTYPE_X;
-    static const mask space = _CTYPE_S;
-    static const mask print = _CTYPE_P | _CTYPE_U | _CTYPE_L |
_CTYPE_N | _CTYPE_B;
-    static const mask graph = _CTYPE_P | _CTYPE_U | _CTYPE_L |
_CTYPE_N;
-    static const mask cntrl = _CTYPE_C;
-    static const mask punct = _CTYPE_P;
-    static const mask alnum = _CTYPE_U | _CTYPE_L | _CTYPE_N;
+    typedef const unsigned short*    __to_type;
+
+    typedef unsigned short    mask;
+
+    static const mask upper    = _CTYPE_U;
+    static const mask lower    = _CTYPE_L;
+    static const mask alpha    = _CTYPE_A;
+    static const mask digit    = _CTYPE_D;
+    static const mask xdigit    = _CTYPE_X;
+    static const mask space    = _CTYPE_S;
+    static const mask print    = _CTYPE_R;
+    static const mask graph    = _CTYPE_G;
+    static const mask cntrl    = _CTYPE_C;
+    static const mask punct    = _CTYPE_P;
+    static const mask alnum    = _CTYPE_A | _CTYPE_D;
#endif
#if __cplusplus >= 201103L
-    static const mask blank = space;
+    static const mask blank    = space;
#endif
  };

diff --git a/libstdc++-v3/config/os/bsd/netbsd/ctype_configure_char.cc
b/libstdc++-v3/config/os/bsd/netbsd/ctype_configure_char.cc
index ed3b7cd0d6a..33358e8f5d8 100644
--- a/libstdc++-v3/config/os/bsd/netbsd/ctype_configure_char.cc
+++ b/libstdc++-v3/config/os/bsd/netbsd/ctype_configure_char.cc
@@ -38,11 +38,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION

// Information as gleaned from /usr/include/ctype.h

-  extern "C" const u_int8_t _C_ctype_[];
-
  const ctype_base::mask*
  ctype::classic_table() throw()
-  { return _C_ctype_ + 1; }
+  { return _C_ctype_tab_ + 1; }


The first patch attached to PR 64271 (i.e.
https://gcc.gnu.org/bugzilla/attachment.cgi?id=34254 ) does that
differently. Is it safe to make this change unconditionally?



This file is NetBSD only (at least in theory) and we likely can do the
right think without conditional build here.


Yes, it's NetBSD-specific, but it's used for multiple versions of
NetBSD.

The patch 

Re: [PATCH] libstdcxx: Update ctype_base.h from NetBSD upstream

[Jonathan Wakely]

On 06/01/20 23:20 +0100, Kamil Rytarowski wrote:

On 06.01.2020 16:24, Jonathan Wakely wrote:

On 22/12/19 09:36 +1000, Gerald Pfeifer wrote:

Hi Matthew,

On Mon, 4 Feb 2019, Matthew Bauer wrote:

The ctype_base.h file in libstdc++-v3 is out of date for NetBSD. They
have changed their ctype.h definition. It was updated in their intree
libstdc++-v3 but not in the GCC one. My understanding is this is a
straightforward rewrite. I've attached my own patch, but the file can
be obtained directly here:

http://cvsweb.netbsd.org/bsdweb.cgi/src/external/gpl3/gcc/dist/libstdc%2b%2b-v3/config/os/bsd/netbsd/ctype_base.h


With the attached patch, libstdc++-v3 can succesfully be built with
NetBSD headers (along with --disable-libcilkrts).


I noticed this has not been applied yet, nor seen a follow-up?, and also
noticed it went to the gcc-patches list, but not libstd...@gcc.gnu.org.

Let me re-address this to libstd...@gcc.gnu.org in the hope the
maintainers there will have a look.

Gerald



diff --git a/libstdc++-v3/config/os/bsd/netbsd/ctype_base.h
b/libstdc++-v3/config/os/bsd/netbsd/ctype_base.h
index ff3ec893974..21eccf9fde1 100644
--- a/libstdc++-v3/config/os/bsd/netbsd/ctype_base.h
+++ b/libstdc++-v3/config/os/bsd/netbsd/ctype_base.h
@@ -38,40 +38,46 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  /// @brief  Base class for ctype.
  struct ctype_base
  {
-    // Non-standard typedefs.
-    typedef const unsigned char*    __to_type;

    // NB: Offsets into ctype::_M_table force a particular size
    // on the mask type. Because of this, we don't use an enum.
-    typedef unsigned char  mask;

#ifndef _CTYPE_U
-    static const mask upper    = _U;
-    static const mask lower = _L;
-    static const mask alpha = _U | _L;
-    static const mask digit = _N;
-    static const mask xdigit = _N | _X;
-    static const mask space = _S;
-    static const mask print = _P | _U | _L | _N | _B;
-    static const mask graph = _P | _U | _L | _N;
-    static const mask cntrl = _C;
-    static const mask punct = _P;
-    static const mask alnum = _U | _L | _N;
+    // Non-standard typedefs.
+    typedef const unsigned char*    __to_type;
+
+    typedef unsigned char    mask;
+
+    static const mask upper    = _U;
+    static const mask lower    = _L;
+    static const mask alpha    = _U | _L;
+    static const mask digit    = _N;
+    static const mask xdigit    = _N | _X;
+    static const mask space    = _S;
+    static const mask print    = _P | _U | _L | _N | _B;
+    static const mask graph    = _P | _U | _L | _N;
+    static const mask cntrl    = _C;
+    static const mask punct    = _P;
+    static const mask alnum    = _U | _L | _N;
#else
-    static const mask upper    = _CTYPE_U;
-    static const mask lower = _CTYPE_L;
-    static const mask alpha = _CTYPE_U | _CTYPE_L;
-    static const mask digit = _CTYPE_N;
-    static const mask xdigit = _CTYPE_N | _CTYPE_X;
-    static const mask space = _CTYPE_S;
-    static const mask print = _CTYPE_P | _CTYPE_U | _CTYPE_L |
_CTYPE_N | _CTYPE_B;
-    static const mask graph = _CTYPE_P | _CTYPE_U | _CTYPE_L |
_CTYPE_N;
-    static const mask cntrl = _CTYPE_C;
-    static const mask punct = _CTYPE_P;
-    static const mask alnum = _CTYPE_U | _CTYPE_L | _CTYPE_N;
+    typedef const unsigned short*    __to_type;
+
+    typedef unsigned short    mask;


I seem to recall looking at this previously and noting that the change
to ctype_base::mask is an ABI break. It means that code compiled with
old versions of GCC or on old versions of NetBSD will not be ABI
compatible with code compiled by a new GCC on a new version of NetBSD.

If the NetBSD maintainers are OK with that, then we can go ahead and
change it.




We are fine with ABI breaks as we bump libstdc++ major on each upgrade
in base.


That affects the libstdc++ built from NetBSD ports collection, but if
somebody builds GCC themselves using the upstream sources (which is
what these patches are trying to change) then they don't get that
bumped major version.

So if somebody builds GCC 9 themselves, and then builds GCC 10
themselves on the same machine, they'll get two versions of
libstdc++.so that are not ABI compatible.

Re: [committed] Fix comparison operator used for B and S integer comparisons on hppa

[John David Anglin]

On 2020-01-01 4:11 p.m., John David Anglin wrote:
> This fixes PR target/93111.  The ICE
> 
> The comparison_operator predicate is too broad and includes a couple of 
> comparisons
> that aren't valid for integer comparisons on hppa.  We need to use the 
> ordered_comparison_operator
> predicate.
> 
> Similarly, the cmpib_comparison_operator predicate misses a couple of 
> comparisons that are valid
> for the cmpib patterns.  Again we can use the ordered_comparison_operator 
> predicate.
> 
> Tested on hppa-unknown-linux-gnu.  Committed to active branches.
Unfortunately, the cmpib_comparison_operator changes broke 64-bit gcc and linux 
builds.  I missed
that the patterns using the cmpib_comparison_operator only apply to double word 
comparisons.

The following change reverts this portion of the previous change.  Tested on 
hppa64-hp-hpux11.11
and linux-unknown-linux-gnu.  Committed to active branches.

Dave

2020-01-06  John David Anglin  

* config/pa/pa.md: Revert change to use ordered_comparison_operator
instead of cmpib_comparison_operator in cmpib patterns.
* config/pa/predicates.md (cmpib_comparison_operator): Revert removal
of cmpib_comparison_operator.  Revise comment.

Index: config/pa/pa.md
===
--- config/pa/pa.md (revision 279888)
+++ config/pa/pa.md (working copy)
@@ -1524,7 +1524,7 @@
 (define_insn ""
   [(set (pc)
(if_then_else
-(match_operator 3 "ordered_comparison_operator"
+(match_operator 3 "cmpib_comparison_operator"
 [(match_operand:DI 1 "reg_or_0_operand" "rM")
  (match_operand:DI 2 "arith5_operand" "rL")])
 (label_ref (match_operand 0 "" ""))
@@ -1553,7 +1553,7 @@
 (define_insn ""
   [(set (pc)
(if_then_else
-(match_operator 3 "ordered_comparison_operator"
+(match_operator 3 "cmpib_comparison_operator"
 [(match_operand:DI 1 "reg_or_0_operand" "rM")
  (match_operand:DI 2 "arith5_operand" "rL")])
 (pc)
Index: config/pa/predicates.md
===
--- config/pa/predicates.md (revision 279888)
+++ config/pa/predicates.md (working copy)
@@ -662,6 +662,12 @@
   (and (match_code "symbol_ref")
(match_test "SYMBOL_REF_TLS_MODEL (op) == TLS_MODEL_LOCAL_EXEC")))

+;; True iff OP is an operator suitable for use in a double-word cmpib
+;; instruction.
+
+(define_predicate "cmpib_comparison_operator"
+  (match_code "eq,ne,lt,le,leu,gt,gtu,ge"))
+
 ;; True iff OP is an operator suitable for use in a movb instruction.

 (define_predicate "movb_comparison_operator"

Re: [PATCH] libstdcxx: Update ctype_base.h from NetBSD upstream

[Kamil Rytarowski]

On 06.01.2020 16:34, Jonathan Wakely wrote:
> On 22/12/19 09:36 +1000, Gerald Pfeifer wrote:
>> Hi Matthew,
>>
>> On Mon, 4 Feb 2019, Matthew Bauer wrote:
>>> The ctype_base.h file in libstdc++-v3 is out of date for NetBSD. They
>>> have changed their ctype.h definition. It was updated in their intree
>>> libstdc++-v3 but not in the GCC one. My understanding is this is a
>>> straightforward rewrite. I've attached my own patch, but the file can
>>> be obtained directly here:
>>>
>>> http://cvsweb.netbsd.org/bsdweb.cgi/src/external/gpl3/gcc/dist/libstdc%2b%2b-v3/config/os/bsd/netbsd/ctype_base.h
>>>
>>>
>>> With the attached patch, libstdc++-v3 can succesfully be built with
>>> NetBSD headers (along with --disable-libcilkrts).
>>
>> I noticed this has not been applied yet, nor seen a follow-up?, and also
>> noticed it went to the gcc-patches list, but not libstd...@gcc.gnu.org.
>>
>> Let me re-address this to libstd...@gcc.gnu.org in the hope the
>> maintainers there will have a look.
>>
>> Gerald
> 
>> diff --git a/libstdc++-v3/config/os/bsd/netbsd/ctype_base.h
>> b/libstdc++-v3/config/os/bsd/netbsd/ctype_base.h
>> index ff3ec893974..21eccf9fde1 100644
>> --- a/libstdc++-v3/config/os/bsd/netbsd/ctype_base.h
>> +++ b/libstdc++-v3/config/os/bsd/netbsd/ctype_base.h
>> @@ -38,40 +38,46 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>>   /// @brief  Base class for ctype.
>>   struct ctype_base
>>   {
>> -    // Non-standard typedefs.
>> -    typedef const unsigned char*    __to_type;
>>
>>     // NB: Offsets into ctype::_M_table force a particular size
>>     // on the mask type. Because of this, we don't use an enum.
>> -    typedef unsigned char  mask;
>>
>> #ifndef _CTYPE_U
>> -    static const mask upper    = _U;
>> -    static const mask lower = _L;
>> -    static const mask alpha = _U | _L;
>> -    static const mask digit = _N;
>> -    static const mask xdigit = _N | _X;
>> -    static const mask space = _S;
>> -    static const mask print = _P | _U | _L | _N | _B;
>> -    static const mask graph = _P | _U | _L | _N;
>> -    static const mask cntrl = _C;
>> -    static const mask punct = _P;
>> -    static const mask alnum = _U | _L | _N;
>> +    // Non-standard typedefs.
>> +    typedef const unsigned char*    __to_type;
>> +
>> +    typedef unsigned char    mask;
>> +
>> +    static const mask upper    = _U;
>> +    static const mask lower    = _L;
>> +    static const mask alpha    = _U | _L;
>> +    static const mask digit    = _N;
>> +    static const mask xdigit    = _N | _X;
>> +    static const mask space    = _S;
>> +    static const mask print    = _P | _U | _L | _N | _B;
>> +    static const mask graph    = _P | _U | _L | _N;
>> +    static const mask cntrl    = _C;
>> +    static const mask punct    = _P;
>> +    static const mask alnum    = _U | _L | _N;
>> #else
>> -    static const mask upper    = _CTYPE_U;
>> -    static const mask lower = _CTYPE_L;
>> -    static const mask alpha = _CTYPE_U | _CTYPE_L;
>> -    static const mask digit = _CTYPE_N;
>> -    static const mask xdigit = _CTYPE_N | _CTYPE_X;
>> -    static const mask space = _CTYPE_S;
>> -    static const mask print = _CTYPE_P | _CTYPE_U | _CTYPE_L |
>> _CTYPE_N | _CTYPE_B;
>> -    static const mask graph = _CTYPE_P | _CTYPE_U | _CTYPE_L |
>> _CTYPE_N;
>> -    static const mask cntrl = _CTYPE_C;
>> -    static const mask punct = _CTYPE_P;
>> -    static const mask alnum = _CTYPE_U | _CTYPE_L | _CTYPE_N;
>> +    typedef const unsigned short*    __to_type;
>> +
>> +    typedef unsigned short    mask;
>> +
>> +    static const mask upper    = _CTYPE_U;
>> +    static const mask lower    = _CTYPE_L;
>> +    static const mask alpha    = _CTYPE_A;
>> +    static const mask digit    = _CTYPE_D;
>> +    static const mask xdigit    = _CTYPE_X;
>> +    static const mask space    = _CTYPE_S;
>> +    static const mask print    = _CTYPE_R;
>> +    static const mask graph    = _CTYPE_G;
>> +    static const mask cntrl    = _CTYPE_C;
>> +    static const mask punct    = _CTYPE_P;
>> +    static const mask alnum    = _CTYPE_A | _CTYPE_D;
>> #endif
>> #if __cplusplus >= 201103L
>> -    static const mask blank = space;
>> +    static const mask blank    = space;
>> #endif
>>   };
>>
>> diff --git a/libstdc++-v3/config/os/bsd/netbsd/ctype_configure_char.cc
>> b/libstdc++-v3/config/os/bsd/netbsd/ctype_configure_char.cc
>> index ed3b7cd0d6a..33358e8f5d8 100644
>> --- a/libstdc++-v3/config/os/bsd/netbsd/ctype_configure_char.cc
>> +++ b/libstdc++-v3/config/os/bsd/netbsd/ctype_configure_char.cc
>> @@ -38,11 +38,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>>
>> // Information as gleaned from /usr/include/ctype.h
>>
>> -  extern "C" const u_int8_t _C_ctype_[];
>> -
>>   const ctype_base::mask*
>>   ctype::classic_table() throw()
>> -  { return _C_ctype_ + 1; }
>> +  { return _C_ctype_tab_ + 1; }
> 
> The first patch attached to PR 64271 (i.e.
> 

Re: [C++ PATCH] Avoid caching constexpr calls that allocate something that they don't deallocate or vice versa (PR c++/91369)

[Jason Merrill]

On 1/5/20 8:04 AM, Jakub Jelinek wrote:

Hi!

The caching of constexpr calls breaks the following testcase.
The problem is that constexpr calls that allocate from heap something
that they don't deallocate or calls that deallocate something they haven't
allocated aren't stateless for the constexpr context and in each outermost
constexpr evaluation the allocations will produce different artificial heap
VAR_DECLs.  In the testcase a function allocates something that the caller
is supposed to deallocate, so when we call it second time (e.g. from
different function) with the same constant arguments, we get the cached
result that contains address of the heap VAR_DECL from the earlier
evaluation and error trying to free something we haven't allocated (in the
same outermost constexpr evaluation).  Similarly, a constexpr call could
deallocate something the caller is supposed to allocate, if we cache such
call, we wouldn't actually deallocate it and complain the allocation has not
been deallocated.

Fixed by making sure we only cache calls that either don't perform any
allocations/deallocations, or perform exactly as many allocations and
deallocations and all those new allocations (new additions to heap_vars,
to which we only add, never remove) have been deallocated (checking just
numbers is not good enough, we might perform 3 allocations and 3
deallocations, e.g. deallocate 2 of those allocations and one passed to the
call from the caller and pass the still allocated address to the caller.

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


OK.


2020-01-05  Jakub Jelinek  

PR c++/91369
* constexpr.c (struct constexpr_global_ctx): Add heap_alloc_count
member, initialize it to zero in ctor.
(cxx_eval_call_expression): Bump heap_dealloc_count when deleting
a heap object.  Don't cache calls to functions which allocate some
heap objects and don't deallocate them or deallocate some heap
objects they didn't allocate.

Re: [patch] relax aarch64 stack-clash tests depedence on alloca.h

[Andrew Pinski]

On Mon, Jan 6, 2020 at 2:18 PM Olivier Hainque  wrote:
>
> Hello,
>
> The aarch64 testsuite features a few tests for
> the stack-clash-protection facility, all using "alloca"
> after an #include .
>
> The use of alloca.h causes the tests to fail on
> target systems not providing that header, such as some
> variants of VxWorks.
>
> My understanding is that the tests really depend on
> the alloca functionality, not on alloca.h in particular.
>
> This patch is a proposal to modify the tests to
> use __builtin_alloca instead, as done in some other
> places in the testsuite.
>
> This cures the failures on VxWorks and bootstrap+regtest
> fine on aarch64 linux.
>
> Ok to commit ?

Just one small suggestion:
Instead of:
-  char* pStr = alloca(SIZE);
+  char* pStr = __builtin_alloca(SIZE);

Why not just do:
-#include 
+#define alloca __builtin_alloca

Thanks,
Andrew Pinski


>
> Thanks in advance!
>
> Best Regards,
>
> Olivier
>
>
> 2020-01-06  Olivier Hainque  
> Alexandre Oliva  
>
> * gcc.target/aarch64/stack-check-alloca.h: Remove
> #include alloca.h.
> (f_caller): Use __builtin_alloca instead of alloca.
> * gcc.target/aarch64/stack-check-alloca-1.c: Add
> { dg-require-effective-target alloca }.
> * gcc.target/aarch64/stack-check-alloca-2.c: Likewise.
> * gcc.target/aarch64/stack-check-alloca-3.c: Likewise.
> * gcc.target/aarch64/stack-check-alloca-4.c: Likewise.
> * gcc.target/aarch64/stack-check-alloca-5.c: Likewise.
> * gcc.target/aarch64/stack-check-alloca-6.c: Likewise.
> * gcc.target/aarch64/stack-check-alloca-7.c: Likewise.
> * gcc.target/aarch64/stack-check-alloca-8.c: Likewise.
> * gcc.target/aarch64/stack-check-alloca-9.c: Likewise.
> * gcc.target/aarch64/stack-check-alloca-10.c: Likewise.
>

Re: [PATCH] libstdcxx: Update ctype_base.h from NetBSD upstream

[Kamil Rytarowski]

On 06.01.2020 16:24, Jonathan Wakely wrote:
> On 22/12/19 09:36 +1000, Gerald Pfeifer wrote:
>> Hi Matthew,
>>
>> On Mon, 4 Feb 2019, Matthew Bauer wrote:
>>> The ctype_base.h file in libstdc++-v3 is out of date for NetBSD. They
>>> have changed their ctype.h definition. It was updated in their intree
>>> libstdc++-v3 but not in the GCC one. My understanding is this is a
>>> straightforward rewrite. I've attached my own patch, but the file can
>>> be obtained directly here:
>>>
>>> http://cvsweb.netbsd.org/bsdweb.cgi/src/external/gpl3/gcc/dist/libstdc%2b%2b-v3/config/os/bsd/netbsd/ctype_base.h
>>>
>>>
>>> With the attached patch, libstdc++-v3 can succesfully be built with
>>> NetBSD headers (along with --disable-libcilkrts).
>>
>> I noticed this has not been applied yet, nor seen a follow-up?, and also
>> noticed it went to the gcc-patches list, but not libstd...@gcc.gnu.org.
>>
>> Let me re-address this to libstd...@gcc.gnu.org in the hope the
>> maintainers there will have a look.
>>
>> Gerald
> 
>> diff --git a/libstdc++-v3/config/os/bsd/netbsd/ctype_base.h
>> b/libstdc++-v3/config/os/bsd/netbsd/ctype_base.h
>> index ff3ec893974..21eccf9fde1 100644
>> --- a/libstdc++-v3/config/os/bsd/netbsd/ctype_base.h
>> +++ b/libstdc++-v3/config/os/bsd/netbsd/ctype_base.h
>> @@ -38,40 +38,46 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>>   /// @brief  Base class for ctype.
>>   struct ctype_base
>>   {
>> -    // Non-standard typedefs.
>> -    typedef const unsigned char*    __to_type;
>>
>>     // NB: Offsets into ctype::_M_table force a particular size
>>     // on the mask type. Because of this, we don't use an enum.
>> -    typedef unsigned char  mask;
>>
>> #ifndef _CTYPE_U
>> -    static const mask upper    = _U;
>> -    static const mask lower = _L;
>> -    static const mask alpha = _U | _L;
>> -    static const mask digit = _N;
>> -    static const mask xdigit = _N | _X;
>> -    static const mask space = _S;
>> -    static const mask print = _P | _U | _L | _N | _B;
>> -    static const mask graph = _P | _U | _L | _N;
>> -    static const mask cntrl = _C;
>> -    static const mask punct = _P;
>> -    static const mask alnum = _U | _L | _N;
>> +    // Non-standard typedefs.
>> +    typedef const unsigned char*    __to_type;
>> +
>> +    typedef unsigned char    mask;
>> +
>> +    static const mask upper    = _U;
>> +    static const mask lower    = _L;
>> +    static const mask alpha    = _U | _L;
>> +    static const mask digit    = _N;
>> +    static const mask xdigit    = _N | _X;
>> +    static const mask space    = _S;
>> +    static const mask print    = _P | _U | _L | _N | _B;
>> +    static const mask graph    = _P | _U | _L | _N;
>> +    static const mask cntrl    = _C;
>> +    static const mask punct    = _P;
>> +    static const mask alnum    = _U | _L | _N;
>> #else
>> -    static const mask upper    = _CTYPE_U;
>> -    static const mask lower = _CTYPE_L;
>> -    static const mask alpha = _CTYPE_U | _CTYPE_L;
>> -    static const mask digit = _CTYPE_N;
>> -    static const mask xdigit = _CTYPE_N | _CTYPE_X;
>> -    static const mask space = _CTYPE_S;
>> -    static const mask print = _CTYPE_P | _CTYPE_U | _CTYPE_L |
>> _CTYPE_N | _CTYPE_B;
>> -    static const mask graph = _CTYPE_P | _CTYPE_U | _CTYPE_L |
>> _CTYPE_N;
>> -    static const mask cntrl = _CTYPE_C;
>> -    static const mask punct = _CTYPE_P;
>> -    static const mask alnum = _CTYPE_U | _CTYPE_L | _CTYPE_N;
>> +    typedef const unsigned short*    __to_type;
>> +
>> +    typedef unsigned short    mask;
> 
> I seem to recall looking at this previously and noting that the change
> to ctype_base::mask is an ABI break. It means that code compiled with
> old versions of GCC or on old versions of NetBSD will not be ABI
> compatible with code compiled by a new GCC on a new version of NetBSD.
> 
> If the NetBSD maintainers are OK with that, then we can go ahead and
> change it.
> 
> 

We are fine with ABI breaks as we bump libstdc++ major on each upgrade
in base.



signature.asc
Description: OpenPGP digital signature

[patch] relax aarch64 stack-clash tests depedence on alloca.h

[Olivier Hainque]

Hello,

The aarch64 testsuite features a few tests for
the stack-clash-protection facility, all using "alloca"
after an #include .

The use of alloca.h causes the tests to fail on
target systems not providing that header, such as some
variants of VxWorks.

My understanding is that the tests really depend on
the alloca functionality, not on alloca.h in particular.

This patch is a proposal to modify the tests to
use __builtin_alloca instead, as done in some other
places in the testsuite.

This cures the failures on VxWorks and bootstrap+regtest
fine on aarch64 linux.

Ok to commit ?

Thanks in advance!

Best Regards,

Olivier


2020-01-06  Olivier Hainque  
Alexandre Oliva  

* gcc.target/aarch64/stack-check-alloca.h: Remove
#include alloca.h.
(f_caller): Use __builtin_alloca instead of alloca.
* gcc.target/aarch64/stack-check-alloca-1.c: Add
{ dg-require-effective-target alloca }.
* gcc.target/aarch64/stack-check-alloca-2.c: Likewise.
* gcc.target/aarch64/stack-check-alloca-3.c: Likewise.
* gcc.target/aarch64/stack-check-alloca-4.c: Likewise.
* gcc.target/aarch64/stack-check-alloca-5.c: Likewise.
* gcc.target/aarch64/stack-check-alloca-6.c: Likewise.
* gcc.target/aarch64/stack-check-alloca-7.c: Likewise.
* gcc.target/aarch64/stack-check-alloca-8.c: Likewise.
* gcc.target/aarch64/stack-check-alloca-9.c: Likewise.
* gcc.target/aarch64/stack-check-alloca-10.c: Likewise.

diff --git a/gcc/testsuite/gcc.target/aarch64/stack-check-alloca-1.c 
b/gcc/testsuite/gcc.target/aarch64/stack-check-alloca-1.c
index 7fc189f6210..e963ee66d36 100644
--- a/gcc/testsuite/gcc.target/aarch64/stack-check-alloca-1.c
+++ b/gcc/testsuite/gcc.target/aarch64/stack-check-alloca-1.c
@@ -1,6 +1,7 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -fstack-clash-protection --param 
stack-clash-protection-guard-size=16" } */
 /* { dg-require-effective-target supports_stack_clash_protection } */
+/* { dg-require-effective-target alloca } */
 
 #define SIZE y
 #include "stack-check-alloca.h"
diff --git a/gcc/testsuite/gcc.target/aarch64/stack-check-alloca-10.c 
b/gcc/testsuite/gcc.target/aarch64/stack-check-alloca-10.c
index 7c42206d315..eb85843565d 100644
--- a/gcc/testsuite/gcc.target/aarch64/stack-check-alloca-10.c
+++ b/gcc/testsuite/gcc.target/aarch64/stack-check-alloca-10.c
@@ -1,6 +1,7 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -fstack-clash-protection --param 
stack-clash-protection-guard-size=16" } */
 /* { dg-require-effective-target supports_stack_clash_protection } */
+/* { dg-require-effective-target alloca } */
 
 #define SIZE 127.5 * 64 * 1024
 #include "stack-check-alloca.h"
diff --git a/gcc/testsuite/gcc.target/aarch64/stack-check-alloca-2.c 
b/gcc/testsuite/gcc.target/aarch64/stack-check-alloca-2.c
index 69fdd16e35a..cc8216d2312 100644
--- a/gcc/testsuite/gcc.target/aarch64/stack-check-alloca-2.c
+++ b/gcc/testsuite/gcc.target/aarch64/stack-check-alloca-2.c
@@ -1,6 +1,7 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -fstack-clash-protection --param 
stack-clash-protection-guard-size=16" } */
 /* { dg-require-effective-target supports_stack_clash_protection } */
+/* { dg-require-effective-target alloca } */
 
 #define SIZE 0
 #include "stack-check-alloca.h"
diff --git a/gcc/testsuite/gcc.target/aarch64/stack-check-alloca-3.c 
b/gcc/testsuite/gcc.target/aarch64/stack-check-alloca-3.c
index fba3a7a25b7..f5e51fa4dc8 100644
--- a/gcc/testsuite/gcc.target/aarch64/stack-check-alloca-3.c
+++ b/gcc/testsuite/gcc.target/aarch64/stack-check-alloca-3.c
@@ -1,6 +1,7 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -fstack-clash-protection --param 
stack-clash-protection-guard-size=16" } */
 /* { dg-require-effective-target supports_stack_clash_protection } */
+/* { dg-require-effective-target alloca } */
 
 #define SIZE 100
 #include "stack-check-alloca.h"
diff --git a/gcc/testsuite/gcc.target/aarch64/stack-check-alloca-4.c 
b/gcc/testsuite/gcc.target/aarch64/stack-check-alloca-4.c
index d53f30a4133..c903f4d9998 100644
--- a/gcc/testsuite/gcc.target/aarch64/stack-check-alloca-4.c
+++ b/gcc/testsuite/gcc.target/aarch64/stack-check-alloca-4.c
@@ -1,6 +1,7 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -fstack-clash-protection --param 
stack-clash-protection-guard-size=16" } */
 /* { dg-require-effective-target supports_stack_clash_protection } */
+/* { dg-require-effective-target alloca } */
 
 #define SIZE 2 * 1024
 #include "stack-check-alloca.h"
diff --git a/gcc/testsuite/gcc.target/aarch64/stack-check-alloca-5.c 
b/gcc/testsuite/gcc.target/aarch64/stack-check-alloca-5.c
index e0ff99ffbe1..691ec23f89f 100644
--- a/gcc/testsuite/gcc.target/aarch64/stack-check-alloca-5.c
+++ b/gcc/testsuite/gcc.target/aarch64/stack-check-alloca-5.c
@@ -1,6 +1,7 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -fstack-clash-protection --param 
stack-clash-protection-guard-size=16" } */
 /* { dg-require-effective-target 

Re: [PATCH] V11 patch #5 of 15, Optimize vec_extract of a vector in memory with a PC-relative address

[Michael Meissner]

On Tue, Dec 24, 2019 at 10:24:55AM -0600, Segher Boessenkool wrote:
> Hi!
> 
> On Fri, Dec 20, 2019 at 06:55:53PM -0500, Michael Meissner wrote:
> > * config/rs6000/rs6000.c (rs6000_reg_to_addr_mask): New helper
> > function to identify the address mask of a hard register.
> 
> Do this as a separate patch please.  That refactoring is pre-approved.
> Please explain in the function comment what an "address mask" is.  Or
> better yet, don't call it a "mask", it isn't a mask?
> 
> Also various of the names here still have "reload" in it, which doesn't
> really make much sense.
> 
> rs6000_mode_to_addressing_flags?  And a reg_to for this new one?
> Something like that.

Note, rs6000_mode_to_addressing_flags also does not fit the usage.  The key is
to return the address mask of the valid addressing options that needs both a
hard register and a mode.  Mode by itself is not useful, since loading up
SImode to vector registers requires X_FORM, while then same mode in GPR
registers can of course do D_FORM and X_FORM addressing.

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

Re: [PATCH] V11 patch #5 of 15, Optimize vec_extract of a vector in memory with a PC-relative address

[Michael Meissner]

On Tue, Dec 24, 2019 at 10:24:55AM -0600, Segher Boessenkool wrote:
> Hi!
> 
> On Fri, Dec 20, 2019 at 06:55:53PM -0500, Michael Meissner wrote:
> > * config/rs6000/rs6000.c (rs6000_reg_to_addr_mask): New helper
> > function to identify the address mask of a hard register.
> 
> Do this as a separate patch please.  That refactoring is pre-approved.
> Please explain in the function comment what an "address mask" is.  Or
> better yet, don't call it a "mask", it isn't a mask?

It is called mask because everywhere else in rs6000.c uses 'addr_mask' or just
mask.  It is a mask of valid bits.

> Also various of the names here still have "reload" in it, which doesn't
> really make much sense.

When these functions were written, it was in the context of supporting the
secondary reload functions, and so reload was in the name.

I will make a refactoring patch that uses the current names.  If we want to
change all of the uses we can in a future patch.

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

Re: [C++ Patch] Improve build_new locations

[Jason Merrill]

On 1/2/20 4:23 AM, Paolo Carlini wrote:

@@ -19320,8 +19320,8 @@ tsubst_copy_and_build (tree t,
  
  	tree op1 = tsubst (TREE_OPERAND (t, 1), args, complain, in_decl);

tree op2 = RECUR (TREE_OPERAND (t, 2));
-   ret = build_new (_vec, op1, op2, _vec,
-NEW_EXPR_USE_GLOBAL (t),
+   ret = build_new (input_location, _vec, op1, op2,


Hmm, using input_location bothers me even though it does have the right 
value in this function.  Let's use a local variable instead; maybe 
change the existing loc variable to save_loc and use the name loc for 
the location we want to use.


Jason

Re: [PATCH] Fix PowerPC -fstack-clash-protection -mprefixed-addr ICE (PR target/93122)

[Segher Boessenkool]

On Mon, Jan 06, 2020 at 11:03:02AM -0700, Jeff Law wrote:
> On Mon, 2020-01-06 at 09:24 +0100, Jakub Jelinek wrote:
> > Hi!
> > 
> > As mentioned in the PR, the following testcase ICEs because rs, while valid
> > add_operand is not valid add_cint_operand and so gen_add3_insn fails,
> > because it doesn't meet the expander predicates.
> > 
> > Fixed thusly, bootstrapped/regtested on powerpc64{,le}-linux, ok for trunk?
> > 
> > Another option would be to:
> > 1) always use gen_add3_insn, but if it returns NULL use the extra
> > emit_move_insn (end_addr, GEN_INT (-rounded_size));
> > and retry with end_addr instead of rs
> > 2) if the first gen_add3_insn returned NULL or if it created more than one
> > instruction, add the REG_FRAME_RELATED_EXPR note on the last insn
> > 
> > Is that what you want to do instead?
> > 
> > 2020-01-06  Jakub Jelinek  
> > 
> > PR target/93122
> > * config/rs6000/rs6000-logue.c
> > (rs6000_emit_probe_stack_range_stack_clash): Only use gen_addr3_insn
> > if add_cint_operand predicate matches.  Use rs instead of doing
> > GEN_INT again.
> > 
> > * gcc.target/powerpc/pr93122.c: New test.
> I think this is fine, but give the PPC maintainers a few days to chime
> in.

It's not okay, whether I'll need a few days or more to reply.  But I will
reply soon :-)


Segher

Re: [PATCH] Document cloning for the target_clone attribute.

[Jeff Law]

On Mon, 2020-01-06 at 11:05 +0100, Martin Liška wrote:
> Hi.
> 
> The patch is about explanation what happens when
> a target_clone function calls a function without
> the attribute.
> 
> Ready for trunk?
> Thanks,
> Martin
> 
> gcc/ChangeLog:
> 
> 2020-01-06  Martin Liska  
> 
>   PR ipa/83411
>   * doc/extend.texi: Explain cloning for target_clone
>   attribute.
Shouldn't the docs use "flatten" rather than "flatter"?  OK with that
change.

Jeff
> 

Re: [PATCH] Relax invalidation of TOP N counters in PGO.

[Jan Hubicka]

> > > OK
> > Actually I am not so sure about this patch - how do we ensure
> > reproducibility in this case?
> ISTM that anyone trying to have reproducible builds shouldn't be using
> PGO based optimizations.

OpenSUSE does that. Builds are supposed to be reproducible + PGO is used
for number of core packages (like GCC itself).  This was motivation of
original Martin's change to drop TOPN values from profile more
agressively.

Honza
> 
> jeff
> 

Re: [PATCH] Relax invalidation of TOP N counters in PGO.

[Jeff Law]

On Mon, 2020-01-06 at 19:23 +0100, Jan Hubicka wrote:
> > On Mon, 2020-01-06 at 15:08 +0100, Martin Liška wrote:
> > > Hi.
> > > 
> > > As Honza noticed in the PR, we are quite strict about TOP N
> > > counter invalidation due to multiple values that can't
> > > fit in a counter. We due it in order to have a reproducible
> > > builds. I guess we should do a compromise in between reproducibility
> > > and possible speed up. That's why I'm suggesting to invalidate
> > > a TOP N counter only if param_profile_topn_invalid_threshold percent
> > > of profile are missing.
> > > 
> > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> > > 
> > > Ready to be installed?
> > > Thanks,
> > > Martin
> > > 
> > > gcc/ChangeLog:
> > > 
> > > 2020-01-06  Martin Liska  
> > > 
> > >   PR tree-optimization/92924
> > >   * params.opt (param_profile_topn_invalid_threshold):
> > >   New parameter.
> > >   * profile.c (sort_hist_values): Mark TOP N counter
> > >   invalid only if significant amount of samples
> > >   is missing.
> > > 
> > > gcc/testsuite/ChangeLog:
> > > 
> > > 2020-01-06  Martin Liska  
> > > 
> > >   PR tree-optimization/92924
> > >   * gcc.dg/tree-prof/pr92924-2.c: New test.
> > >   * gcc.dg/tree-prof/pr92924.c: New test.
> > > 
> > > libgcc/ChangeLog:
> > > 
> > > 2020-01-06  Martin Liska  
> > > 
> > >   PR tree-optimization/92924
> > >   * libgcov-merge.c (merge_topn_values_set): Replace
> > >   value with lowest count.
> > OK
> Actually I am not so sure about this patch - how do we ensure
> reproducibility in this case?
ISTM that anyone trying to have reproducible builds shouldn't be using
PGO based optimizations.

jeff

Re: [PATCH] Relax invalidation of TOP N counters in PGO.

[Jan Hubicka]

> On Mon, 2020-01-06 at 15:08 +0100, Martin Liška wrote:
> > Hi.
> > 
> > As Honza noticed in the PR, we are quite strict about TOP N
> > counter invalidation due to multiple values that can't
> > fit in a counter. We due it in order to have a reproducible
> > builds. I guess we should do a compromise in between reproducibility
> > and possible speed up. That's why I'm suggesting to invalidate
> > a TOP N counter only if param_profile_topn_invalid_threshold percent
> > of profile are missing.
> > 
> > Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> > 
> > Ready to be installed?
> > Thanks,
> > Martin
> > 
> > gcc/ChangeLog:
> > 
> > 2020-01-06  Martin Liska  
> > 
> > PR tree-optimization/92924
> > * params.opt (param_profile_topn_invalid_threshold):
> > New parameter.
> > * profile.c (sort_hist_values): Mark TOP N counter
> > invalid only if significant amount of samples
> > is missing.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > 2020-01-06  Martin Liska  
> > 
> > PR tree-optimization/92924
> > * gcc.dg/tree-prof/pr92924-2.c: New test.
> > * gcc.dg/tree-prof/pr92924.c: New test.
> > 
> > libgcc/ChangeLog:
> > 
> > 2020-01-06  Martin Liska  
> > 
> > PR tree-optimization/92924
> > * libgcov-merge.c (merge_topn_values_set): Replace
> > value with lowest count.
> OK
Actually I am not so sure about this patch - how do we ensure
reproducibility in this case?

Honza

Re: [PATCH] Relax invalidation of TOP N counters in PGO.

[Jeff Law]

On Mon, 2020-01-06 at 15:08 +0100, Martin Liška wrote:
> Hi.
> 
> As Honza noticed in the PR, we are quite strict about TOP N
> counter invalidation due to multiple values that can't
> fit in a counter. We due it in order to have a reproducible
> builds. I guess we should do a compromise in between reproducibility
> and possible speed up. That's why I'm suggesting to invalidate
> a TOP N counter only if param_profile_topn_invalid_threshold percent
> of profile are missing.
> 
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> 
> Ready to be installed?
> Thanks,
> Martin
> 
> gcc/ChangeLog:
> 
> 2020-01-06  Martin Liska  
> 
>   PR tree-optimization/92924
>   * params.opt (param_profile_topn_invalid_threshold):
>   New parameter.
>   * profile.c (sort_hist_values): Mark TOP N counter
>   invalid only if significant amount of samples
>   is missing.
> 
> gcc/testsuite/ChangeLog:
> 
> 2020-01-06  Martin Liska  
> 
>   PR tree-optimization/92924
>   * gcc.dg/tree-prof/pr92924-2.c: New test.
>   * gcc.dg/tree-prof/pr92924.c: New test.
> 
> libgcc/ChangeLog:
> 
> 2020-01-06  Martin Liska  
> 
>   PR tree-optimization/92924
>   * libgcov-merge.c (merge_topn_values_set): Replace
>   value with lowest count.
OK
jeff

Re: [PATCH] Fix PowerPC -fstack-clash-protection -mprefixed-addr ICE (PR target/93122)

[Jeff Law]

On Mon, 2020-01-06 at 09:24 +0100, Jakub Jelinek wrote:
> Hi!
> 
> As mentioned in the PR, the following testcase ICEs because rs, while valid
> add_operand is not valid add_cint_operand and so gen_add3_insn fails,
> because it doesn't meet the expander predicates.
> 
> Fixed thusly, bootstrapped/regtested on powerpc64{,le}-linux, ok for trunk?
> 
> Another option would be to:
> 1) always use gen_add3_insn, but if it returns NULL use the extra
> emit_move_insn (end_addr, GEN_INT (-rounded_size));
> and retry with end_addr instead of rs
> 2) if the first gen_add3_insn returned NULL or if it created more than one
> instruction, add the REG_FRAME_RELATED_EXPR note on the last insn
> 
> Is that what you want to do instead?
> 
> 2020-01-06  Jakub Jelinek  
> 
>   PR target/93122
>   * config/rs6000/rs6000-logue.c
>   (rs6000_emit_probe_stack_range_stack_clash): Only use gen_addr3_insn
>   if add_cint_operand predicate matches.  Use rs instead of doing
>   GEN_INT again.
> 
>   * gcc.target/powerpc/pr93122.c: New test.
I think this is fine, but give the PPC maintainers a few days to chime
in.

jeff
> 

Re: [PATCH] ipa-inline: Adjust condition for caller_growth_limits

[Jeff Law]

On Mon, 2020-01-06 at 01:03 -0600, Xiong Hu Luo wrote:
> Inline should return failure either (newsize > param_large_function_insns)
> OR (newsize > limit).  Sometimes newsize is larger than
> param_large_function_insns, but smaller than limit, inline doesn't return
> failure even if the new function is a large function.
> Therefore, param_large_function_insns and param_large_function_growth should 
> be
> OR instead of AND, otherwise --param large-function-growth won't
> work correctly with --param large-function-insns.
> 
> gcc/ChangeLog:
> 
>   2020-01-06  Luo Xiong Hu  
> 
>   ipa-inline-analysis.c (estimate_growth): Fix typo.
>   ipa-inline.c (caller_growth_limits): Use OR instead of AND.
OK
jeff

Re: [patch][avr] PR92606: Disable -fipa-icf-variables because it generates wrong code.

[Georg-Johann Lay]

Jeff Law schrieb:

On Wed, 2019-12-18 at 16:30 +0100, Georg-Johann Lay wrote:
Hi, this patch turns off -fipa-icf-variables because it generates wrong 
code like for PR92606.  As there is no target hook that could decide 
whether such optimizations are obsolete, disable such optimizations 
alltogether until PR92932 (target hook to disable such optimizations 
depending on object attributes and address-spcace) is available.


Ok to apply?

Johann


Work around PR ipa/92932 by disabling -fipa-icf-variables until
PR92932 will have been solved.

PR ipa/92932
PR target/92606
* common/config/avr/avr-common.c (avr_option_optimization_table)
<-fipa-icf-variables>: Disable.

This seems backwards to me.  Instead of disabling the optimization in
the target files we should prevent the optimization from firing in
cases where it can't reasonably work.

Jeff


The chances that this will be fixed are... tiny.  As Andrew notes in a 
comment to PR92932, there are at least 2 other PRs that report 
wrong-code due to similar data optimization.  He mentions different 
passes however.


Whatever passes perform such wrong-code transforms, apart from more 
conservative approach they will need a new target hook to properly fix 
PR92606 because target attributes / address spaces are involved.


I'd highly appreciate correct code, even if it's at the expense of (yah, 
yet another) hack in the avr backend.  In particular, because such 
optimizations will improve code only a tiny little bit -- if at all. 
Hence kicking out the culprit does not reduce code quality, also because 
 IF such merging is legitimate, some cases can be catched by the linker 
with, say -fmerge-all-constants.


If PR92932, PR92294, PR954666 will ever be fixed, I'd gladly remove the 
proposed 1-line disable-culprit-hack and implement the new target hook 
that PR92932 is supposed to bring.


Johann

Re: [PATCH] Improve (x >> c) << c match.pd optimization (PR tree-optimization/93118)

[Jeff Law]

On Fri, 2020-01-03 at 09:16 +0100, Jakub Jelinek wrote:
> Hi!
> 
> As can be seen in the testcase, for the (x >> c) << c optimization into
> x & (-1< as the affected bits are shifted away.
> Furthermore, while match.pd can handle
> ((unsigned long long)(unsigned)(x >> 32))<<32
> for unsigned long long x - we figure out that after the logical right shift
> the upper 32 bits are already zero and optimize away those two casts -
> we don't handle that for arithmetic shift or e.g. for
> ((unsigned long long)(int)(x >> 32))<<32
> Still, the upper 32 bits don't really matter on the result and can be
> anything.
> 
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
> trunk?
> 
> 2019-01-03  Jakub Jelinek  
> 
>   PR tree-optimization/93118
>   * match.pd ((x >> c) << c -> x & (-1<   simplifier with two intermediate conversions.
> 
>   * gcc.dg/tree-ssa/pr93118.c: New test.
OK
jeff
> 

Re: Add a generic lhd_simulate_enum_decl

[Jeff Law]

On Thu, 2019-12-19 at 16:59 +, Richard Sandiford wrote:
> Normally we only create SVE ACLE functions when arm_sve.h is included.
> But for LTO we need to do it at start-up, so that the functions are
> already defined when streaming in the LTO objects.
> 
> One hitch with doing that is that LTO doesn't yet implement the
> simulate_enum_decl langhook.  This patch adds a simple default
> implementation that it can use.
> 
> Tested on aarch64-linux-gnu and x86_64-linux-gnu.  OK for the
> generic bits?
> 
> Richard
> 
> 
> 2019-12-19  Richard Sandiford  
> 
> gcc/
>   * langhooks-def.h (lhd_simulate_enum_decl): Declare.
>   (LANG_HOOKS_SIMULATE_ENUM_DECL): Use it.
>   * langhooks.c: Include stor-layout.h.
>   (lhd_simulate_enum_decl): New function.
>   * config/aarch64/aarch64-sve-builtins.cc (init_builtins): Call
>   handle_arm_sve_h for the LTO frontend.
>   (register_vector_type): Cope with null returns from pushdecl.
> 
> gcc/testsuite/
>   * gcc.target/aarch64/sve/pcs/asm_4.c: New test.
OK
jeff
> 

Re: [patch][avr] New option -nodevicespecs to omit -specs=... in self specs.

[Jeff Law]

On Wed, 2019-12-18 at 16:36 +0100, Georg-Johann Lay wrote:
> Hi, currently device support in avr-gcc is accomplished by injecting a 
> specs file my means of -specs=... in dirver self specs.
> 
> This patch adds a new avr driver option to omit the addition of 
> respective -specs option so give the user more freedom.
> 
> Ok to apply?
> 
> Johann
> 
>   * config/avr/avr.opt (-nodevicespecs): New driver option.
>   * config/avr/driver-avr.c (avr_devicespecs_file): Only issue
>   "-specs=device-specs/..." if that option is not set.
>   * doc/invoke.texi (AVR Options) <-nodevicespecs>: Document.
OK
jeff

Re: Move -Wmaybe-uninitialized to -Wextra

[Jeff Law]

On Mon, 2019-12-16 at 15:45 +0100, Martin Jambor wrote:
> Hi Jeff,
> 
> On Sat, Dec 07 2019, Jeff Law wrote:
> > [...]
> > The whole point behind the uninitialized warning is to capture cases
> > where objects may not be properly initialized.  For modern code the
> > simple cases typically "just work".  What is by far the most
> > interesting cases are those with complex flow control, often
> > interacting with inline functions, address-of stripping, etc.  These
> > are precisely the cases that humans aren't particularly good at
> > catching and having the compiler analyze those paths and issue warnings
> > that humans fix ultimately results in better quality code.
> 
> Or "fixes" like:
> 
> https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/expmed.c?r1=277864=277863=277864
:(


> 
> if even we cannot deal with the false positive in our own compiler, how
> can we expect our users to do so?
Fair point.  And I've certainly seen painful-to-fix fallout in my
Fedora builds -- by far the most painful cases have been addressables
where we're able to strip the address-of due to inlining.


> 
> > Experience has shown that if you put something in -Wall, people will
> > pay attention to it, and that is good for the long term quality of code
> > bases.  If the diagnostic is outside of -Wall, it's largely ignored.  I
> > think the pain of dealing with the Wuninitialized warts is smaller than
> > the pain of allowing these errors to persist.
> 
> I'm afraid I that -Wmaybe-uninitialized is getting out of hand.  I bet
> that some users regularly get these warnings coming from c++ header
> "libraries" (like they sometimes come out our vec.h which recently
> "broke" bootstrap) which they sometimes even cannot change and they then
> conclude that our -Wall is "unusable" and stop paying attention to all
> warnings.
If it's coming from our headers, then we make a huge effort to fix the
issues :-)

jeff

[committed, amdgcn] Fix issue with '0' constraints

[Andrew Stubbs]

This patch fixes a wrong-code bug that can occur with subv64di3.

The pattern uses '0' constraints to override the early-clobber modifier, 
meaning that the output can be in the same register as one of the 
inputs, whilst still disallowing overlapping pairs of registers (which 
are the real problem).


The problem was that, in GCC 9, it used to be possible to have a '0' in 
all the operands and have it match just one of them, but now it ends up 
forcing *all* the inputs to match, resulting in wrong code. (It's 
possible that this never gave the benefits intended, but just didn't 
produce bad code?)


Adding an alternatives for each permutation fixes the problem. This has 
already been done for many other patterns.


Andrew
Fix amdgcn issue with '0' constraints

2020-01-06  Andrew Stubbs  

	gcc/
	* config/gcn/gcn-valu.md (subv64di3): Use separate alternatives for
	'0' matching inputs.
	(subv64di3_exec): Likewise.

diff --git a/gcc/config/gcn/gcn-valu.md b/gcc/config/gcn/gcn-valu.md
index 9baef24b1c8..e301a4356ec 100644
--- a/gcc/config/gcn/gcn-valu.md
+++ b/gcc/config/gcn/gcn-valu.md
@@ -1292,10 +1292,10 @@
(set_attr "length" "8")])
 
 (define_insn_and_split "subv64di3"
-  [(set (match_operand:V64DI 0 "register_operand"  "=  ,   ")
-	(minus:V64DI
-	  (match_operand:V64DI 1 "gcn_alu_operand" "vSvB0,   v0")
-	  (match_operand:V64DI 2 "gcn_alu_operand" "   v0,vSvB0")))
+  [(set (match_operand:V64DI 0 "register_operand"  "= ,   ,   ,  ")
+	(minus:V64DI 
+	  (match_operand:V64DI 1 "gcn_alu_operand" "vSvB,vSvB0,v,  v0")
+	  (match_operand:V64DI 2 "gcn_alu_operand" "  v0,v,vSvB0,vSvB")))
(clobber (reg:DI VCC_REG))]
   ""
   "#"
@@ -1318,17 +1318,17 @@
 DONE;
   }
   [(set_attr "type" "vmult")
-   (set_attr "length" "8,8")])
+   (set_attr "length" "8")])
 
 (define_insn_and_split "subv64di3_exec"
-  [(set (match_operand:V64DI 0 "register_operand"	   "=  ,   ")
-	(vec_merge:V64DI
-	  (minus:V64DI
-	(match_operand:V64DI 1 "gcn_alu_operand"	   "vSvB0,   v0")
-	(match_operand:V64DI 2 "gcn_alu_operand"	   "   v0,vSvB0"))
+  [(set (match_operand:V64DI 0 "register_operand""= ,   ,   ,  ")
+	(vec_merge:V64DI 
+	  (minus:V64DI   
+	(match_operand:V64DI 1 "gcn_alu_operand" "vSvB,vSvB0,v,  v0")
+	(match_operand:V64DI 2 "gcn_alu_operand" "  v0,v,vSvB0,vSvB"))
 	  (match_operand:V64DI 3 "gcn_register_or_unspec_operand"
-			   "   U0,   U0")
-	  (match_operand:DI 4 "gcn_exec_reg_operand"	   "e,e")))
+		 "  U0,   U0,   U0,  U0")
+	  (match_operand:DI 4 "gcn_exec_reg_operand" "   e,e,e,   e")))
(clobber (reg:DI VCC_REG))]
   "register_operand (operands[1], VOIDmode)
|| register_operand (operands[2], VOIDmode)"
@@ -1357,7 +1357,7 @@
 DONE;
   }
   [(set_attr "type" "vmult")
-   (set_attr "length" "8,8")])
+   (set_attr "length" "8")])
 
 (define_insn_and_split "addv64di3_dup"
   [(set (match_operand:V64DI 0 "register_operand"   "= ")

Re: [patch,avr, 1/3] Support 64-bit (long) double: The gcc part.

[Jeff Law]

On Mon, 2020-01-06 at 18:12 +0100, Georg-Johann Lay wrote:
> Jeff Law schrieb:
> > On Mon, 2019-12-16 at 17:43 +0100, Georg-Johann Lay wrote:
> > > Am 16.12.19 um 17:40 schrieb Georg-Johann Lay:
> > > Patch 1/3 is the GCC changes: Documentation and new avr-specific
> > > configure options:
> > > 
> > > --with-libf7 selects to which level double support from libf7 is added
> > > to libgcc.
> > > 
> > > --with-double-comparison select what FLOAT_LIB_COMPARE_RETURNS_BOOL
> > > returns.
> > > 
> > > Johann
> > > 
> > > gcc/
> > >   * config.gcc (tm_defines) [target=avr]: Support --with-libf7,
> > >   --with-double-comparison.
> > >   * doc/install.texi: Document them.
> > >   * config/avr/avr-c.c (avr_cpu_cpp_builtins)
> > >   
> > >   : New built-in defines.
> > >   * doc/invoke.texi (AVR Built-in Macros): Document them.
> > >   * config/avr/avr-protos.h (avr_float_lib_compare_returns_bool): New.
> > >   * config/avr/avr.c (avr_float_lib_compare_returns_bool): New function.
> > >   * config/avr/avr.h (FLOAT_LIB_COMPARE_RETURNS_BOOL): New macro.
> > I'd suggest "--with-libf77" rather than "--with-libf7".  
> > 
> > jeff
> 
> Why that second 7?
Because I incorrectly thought you were referring to the Fortran
library.  Jakub corrected me on an internal IRC.  Ignore my comments
about changing the name.  


> p.s. You know anything about Denis Chertykov? He used to reply to avr 
> patches within hours, but my latest patches (after a long period where I 
> didn't propose any patches) where all approved by you; not a single mail 
> from Denis.  So I am concerned if he's well.  Maybe he left you or some 
> other global maintainer a note? He's still listed as maintainer though.
I haven't heard much from him for a while.  I'm trying to leave enough
space that he can step in on this stuff, but I'm also hesitant to let
patches linger for too long.

jeff
> 

Re: [PATCH 1/1] Work around array out of bounds warning in mkdeps

[Jeff Law]

On Tue, 2019-12-17 at 10:14 +0100, Andreas Krebbel wrote:
> This suppresses an array out of bounds warning in mkdeps.c as proposed
> by Martin Sebor in the bugzilla.
> 
> array subscript 2 is outside array bounds of ‘const char [2]’
> 
> Since this warning does occur during bootstrap it currently breaks
> werror builds on IBM Z.
> 
> The problem can be reproduced also on x86_64 by changing the inlining
> threshold using: --param max-inline-insns-auto=80
> 
> Bootstrapped and regression tested on x86_64 and IBM Z.
> 
> Ok for mainline?
> 
> libcpp/ChangeLog:
> 
> 2019-12-17  Andreas Krebbel  
> 
>   PR tree-optimization/92176
>   * mkdeps.c (deps_add_default_target):
> ---
>  libcpp/mkdeps.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
OK with a fixed ChangeLog entry.

jeff

Re: [patch,avr, 1/3] Support 64-bit (long) double: The gcc part.

[Georg-Johann Lay]

Jeff Law schrieb:

On Mon, 2019-12-16 at 17:43 +0100, Georg-Johann Lay wrote:

Am 16.12.19 um 17:40 schrieb Georg-Johann Lay:
Patch 1/3 is the GCC changes: Documentation and new avr-specific
configure options:

--with-libf7 selects to which level double support from libf7 is added
to libgcc.

--with-double-comparison select what FLOAT_LIB_COMPARE_RETURNS_BOOL
returns.

Johann

gcc/
* config.gcc (tm_defines) [target=avr]: Support --with-libf7,
--with-double-comparison.
* doc/install.texi: Document them.
* config/avr/avr-c.c (avr_cpu_cpp_builtins)

: New built-in defines.
* doc/invoke.texi (AVR Built-in Macros): Document them.
* config/avr/avr-protos.h (avr_float_lib_compare_returns_bool): New.
* config/avr/avr.c (avr_float_lib_compare_returns_bool): New function.
* config/avr/avr.h (FLOAT_LIB_COMPARE_RETURNS_BOOL): New macro.
I'd suggest "--with-libf77" rather than "--with-libf7".  


jeff



Why that second 7?

I called it "libf7" because the internal _f_loat representation has a 
mantissa of 7 bytes.  So libf56 would also be indicative.


Actually the name does not matter very much... It just needs to have 
/some/ name.  "f77" however puts it close to Fortran, but that code has 
absolutely nothing to do with Fortran whatsoever.


Johann

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

Re: Fix tree-nrv.c ICE for direct internal functions

[Jeff Law]

On Thu, 2019-12-12 at 15:13 +, Richard Sandiford wrote:
> pass_return_slot::execute has:
> 
> /* Ignore internal functions without direct optabs,
>those are expanded specially and aggregate_value_p
>on their result might result in undesirable warnings
>with some backends.  */
> && (!gimple_call_internal_p (stmt)
> || direct_internal_fn_p (gimple_call_internal_fn (stmt)))
> && aggregate_value_p (TREE_TYPE (gimple_call_lhs (stmt)),
>   gimple_call_fndecl (stmt)))
> 
> But what the comment says applies to directly-mapped internal functions
> too, since they're only used if the target supports them without a
> libcall.
> 
> This was triggering an ICE on the attached testcase.  The svld3 call
> is folded to an IFN_LOAD_LANES, which returns an array of vectors with
> VNx48QImode.  Since no such return type can exist in C, the target hook
> was complaining about an unexpected use of SVE modes.  (And we want to
> keep asserting for that, so that we don't accidentally define an ABI for
> an unexpected corner case.)
> 
> Tested on aarch64-linux-gnu and x86_64-linux-gnu.  OK to install?
> 
> Richard
> 
> 
> 2019-12-12  Richard Sandiford  
> 
> gcc/
>   * tree-nrv.c (pass_return_slot::execute): Handle all internal
>   functions the same way, rather than singling out those that
>   aren't mapped directly to optabs.
> 
> gcc/testsuite/
>   * gcc.target/aarch64/sve/acle/general/nrv_1.c: New test.
OK
jeff

Re: Fix libdecnumber handling of non-canonical BID significands (PR middle-end/91226)

[Jeff Law]

On Fri, 2019-11-29 at 20:53 +, Joseph Myers wrote:
> As reported in bug 91226, the libdecnumber code used on the host to
> interpret DFP values in the BID encoding fails, for _Decimal64 and
> _Decimal128, to check for the case where a significand is too large
> and so specified in IEEE 754 to be a non-canonical encoding of the
> zero significand.  This patch adds the required handling of that case,
> together with tests both using -O2 (testing this host code) and -O0
> (testing libgcc code, which already worked before the patch); the
> tests also cover _Decimal32, which already had the required check.
> 
> In the _Decimal128 case, where the code previously completely ignored
> the case where the first four bits of the combination field are 1100,
> 1101 or 1110, the logic for determining the correct quantum exponent
> in that case is also newly added by this patch, so tests are added for
> that as well (again, libgcc already handled it correctly when the
> conversion was done at runtime rather than at compile time).
> 
> Bootstrapped with no regressions for x86_64-pc-linux-gnu.  OK to
> commit (to trunk)?  (Note 1: we don't have a maintainer for
> libdecnumber.  Note 2: as a wrong-code fix, this could be considered
> later for backporting to release branches if no problems appear with
> it on trunk.  Note 3: presumably binutils-gdb will pick this up at
> some point through a merge of libdecnumber from the GCC repository.)
> 
> libdecnumber:
> 2019-11-29  Joseph Myers  
> 
>   PR middle-end/91226
>   * bid/bid2dpd_dpd2bid.c (_bid_to_dpd64): Handle non-canonical
>   significands.
>   (_bid_to_dpd128): Likewise.  Check for case where combination
>   field starts 1100, 1101 or 1110.
> 
> gcc/testsuite:
> 2019-11-29  Joseph Myers  
> 
>   PR middle-end/91226
>   * gcc.dg/dfp/bid-non-canonical-d128-1.c,
>   gcc.dg/dfp/bid-non-canonical-d128-2.c,
>   gcc.dg/dfp/bid-non-canonical-d128-3.c,
>   gcc.dg/dfp/bid-non-canonical-d128-4.c,
>   gcc.dg/dfp/bid-non-canonical-d32-1.c,
>   gcc.dg/dfp/bid-non-canonical-d32-2.c,
>   gcc.dg/dfp/bid-non-canonical-d64-1.c,
>   gcc.dg/dfp/bid-non-canonical-d64-2.c: New tests.
OK.  Your call on whether or not to backport.  Yes, binutils-gdb will
pick this up on whatever schedule works best for them.

Jeff
> 

Re: [PATCH] Add Optimization keyword for TREE/RTL optimization passes.

[Jeff Law]

On Fri, 2020-01-03 at 16:18 +0100, Martin Liška wrote:
> Hello.
> 
> The patch introduces Optimization keyword for various
> parameters that influence an optimization that operates
> on function level (TREE/RTL). I manually grepped for
> each occurrence and verified that it's really used
> within a function context.
> 
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> 
> Ready to be installed?
> Thanks,
> Martin
> 
> gcc/ChangeLog:
> 
> 2020-01-03  Martin Liska  
> 
>   * params.opt: Add Optimization for various parameters.
> ---
>   gcc/params.opt | 336 -
>   1 file changed, 168 insertions(+), 168 deletions(-)
> 
> 
OK
jeff

Re: [PATCH] Mark param_max_fields_for_field_sensitive with Optimization keyword.

[Jeff Law]

On Fri, 2020-01-03 at 13:26 +0100, Martin Liška wrote:
> Hi.
> 
> One another fix where -Ox sets a parameter that
> is not marked with Optimize keyword. Fixed by
> adding the keyword.
> 
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> 
> Ready to be installed?
> Thanks,
> Martin
> 
> gcc/ChangeLog:
> 
> 2020-01-03  Martin Liska  
> 
>   PR tree-optimization/92860
>   * params.opt: (param_max_fields_for_field_sensitive):
>   Mark with Optimization keyword.
>   * tree-ssa-structalias.c (use_field_sensitive): Make
>   it a function.
>   (get_constraint_for_ptr_offset): Call it.
>   (create_variable_info_for_1): Likewise.
>   (init_alias_vars): Do not initialize use_field_sensitive.
> ---
>   gcc/params.opt |  2 +-
>   gcc/tree-ssa-structalias.c | 15 ++-
>   2 files changed, 11 insertions(+), 6 deletions(-)
> 
> 
OK
jeff

Re: [PATCH] Make warn_inline Optimization option.

[Jeff Law]

On Thu, 2020-01-02 at 10:04 +0100, Martin Liška wrote:
> Hi.
> 
> The patch is about using Optimization for warn_inline as
> it's affected by -O0.
> 
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> 
> Ready to be installed?
> Thanks,
> Martin
> 
> gcc/ChangeLog:
> 
> 2019-12-11  Martin Liska  
> 
>   PR tree-optimization/92860
>   * common.opt: Make in Optimization option
>   as it is affected by -O0, which is an Optimization
>   option.
>   * tree-inline.c (tree_inlinable_function_p):
>   Use opt_for_fn for warn_inline.
>   (expand_call_inline): Likewise.
> 
> gcc/testsuite/ChangeLog:
> 
> 2019-12-11  Martin Liska  
> 
>   PR tree-optimization/92860
>   * gcc.dg/pr92860.c: New test.
OK
jeff

Re: Check mask argument's type when vectorising conditional functions

[Jeff Law]

On Mon, 2019-12-23 at 14:44 +, Richard Sandiford wrote:
> We can't yet vectorise conditional internal functions whose boolean
> condition is fed by a data access (or more generally, by a tree of logic
> ops in which all the leaves are data accesses).  Although we should add
> that eventually, we'd need further work to generate good-quality code.
> 
> Unlike vectorizable_load and vectorizalbe_streo, vectorizable_call
> wasn't checking whether the mask had a suitable type, leading to an
> ICE on the testcases.
> 
> Tested on aarch64-linux-gnu and x86_64-linux-gnu.  OK to install?
> 
> Richard
> 
> 
> 2019-12-23  Richard Sandiford  
> 
> gcc/
>   * tree-vect-stmts.c (vect_check_load_store_mask): Rename to...
>   (vect_check_scalar_mask): ...this.
>   (vectorizable_store, vectorizable_load): Update call accordingly.
>   (vectorizable_call): Use vect_check_scalar_mask to check the mask
>   argument in calls to conditional internal functions.
> 
> gcc/testsuite/
>   * gcc.dg/vect/vect-cond-arith-8.c: New test.
>   * gcc.target/aarch64/sve/cond_fmul_5.c: Likewise.
OK
jeff
> 

Re: Require equal shift amounts for IFN_DIV_POW2

[Jeff Law]

On Thu, 2019-12-19 at 15:22 +, Richard Sandiford wrote:
> IFN_DIV_POW2 currently requires all elements to be shifted by the
> same amount, in a similar way as for WIDEN_LSHIFT_EXPR.  This patch
> enforces that when building the SLP tree.
> 
> If in future targets want to support IFN_DIV_POW2 without this
> restriction, we'll probably need the kind of vector-vector/
> vector-scalar split that we already have for normal shifts.
> 
> Tested on aarch64-linux-gnu and x86_64-linux-gnu.  OK to install?
> 
> Richard
> 
> 
> 2019-12-19  Richard Sandiford  
> 
> gcc/
>   * tree-vect-slp.c (vect_build_slp_tree_1): Require all shifts
>   in an IFN_DIV_POW2 node to be equal.
> 
> gcc/testsuite/
>   * gcc.target/aarch64/sve/asrdiv_1.c: Remove trailing %s.
>   * gcc.target/aarch64/sve/asrdiv_2.c: New test.
>   * gcc.target/aarch64/sve/asrdiv_3.c: Likewise.
OK
jeff
> 

Re: [patch][avr] PR92606: Disable -fipa-icf-variables because it generates wrong code.

[Jeff Law]

On Wed, 2019-12-18 at 16:30 +0100, Georg-Johann Lay wrote:
> Hi, this patch turns off -fipa-icf-variables because it generates wrong 
> code like for PR92606.  As there is no target hook that could decide 
> whether such optimizations are obsolete, disable such optimizations 
> alltogether until PR92932 (target hook to disable such optimizations 
> depending on object attributes and address-spcace) is available.
> 
> Ok to apply?
> 
> Johann
> 
> 
>   Work around PR ipa/92932 by disabling -fipa-icf-variables until
>   PR92932 will have been solved.
> 
>   PR ipa/92932
>   PR target/92606
>   * common/config/avr/avr-common.c (avr_option_optimization_table)
>   <-fipa-icf-variables>: Disable.
This seems backwards to me.  Instead of disabling the optimization in
the target files we should prevent the optimization from firing in
cases where it can't reasonably work.

Jeff

Re: [patch,avr, 3/3] Support 64-bit (long) double: libf7.

[Jeff Law]

On Mon, 2019-12-16 at 17:49 +0100, Georg-Johann Lay wrote:
> Am 16.12.19 um 17:40 schrieb Georg-Johann Lay:
> Patch 3/3 is the actual libf7 implementation.  A great deal of which is
> assembly, together with C + inline assembly for higher routines.
> 
> Johann
> 
> libgcc/config/avr/libf7/
>   * t-libf7: New file.
>   * t-libf7-math: New file.
>   * t-libf7-math-symbols: New file.
>   * libf7-common.mk: New file.
>   * libf7-asm-object.mk: New file.
>   * libf7-c-object.mk: New file.
>   * asm-defs.h: New file.
>   * libf7.h: New file.
>   * libf7.c: New file.
>   * libf7-asm.sx: New file.
>   * libf7-array.def: New file.
>   * libf7-const.def: New file.
>   * libf7-constdef.h: New file.
>   * f7renames.sh: New script.
>   * f7wraps.sh: New script.
>   * f7-renames.h: New generated file.
>   * f7-wraps.h: New generated file.
Same with this one was well.  libf7->libf77.

jeff

Re: [patch,avr, 2/3] Support 64-bit (long) double: The libgcc changes.

[Jeff Law]

On Mon, 2019-12-16 at 17:46 +0100, Georg-Johann Lay wrote:
> Am 16.12.19 um 17:40 schrieb Georg-Johann Lay:
> 
> Patch 2/3 is the libgcc additions:
> 
> --with-libf7 selects which makefile-snips from libf7 to use.
> 
> libgcc/
>   * config.host (tmake_file) [target=avr]: Add t-libf7,
>   t-libf7-math, t-libf7-math-symbols as specified by --with-libf7=.
>   * config/avr/t-avrlibc: Don't copy libgcc.a if there are modules
>   depending on sizeof (double) or sizeof (long double).
>   * config/avr/libf7: New folder.
Same as #1/3, libf7->libf77.  Otherwise this looks reasonable.

jeff

Re: [wwwdocs] Document -fcommon default change

[Sandra Loosemore]

On 1/6/20 7:10 AM, Jonathan Wakely wrote:


How about:

GCC now defaults to -fno-common.  As a result, global
variable accesses are more efficient on various targets.  In C, global
variables with multiple tentative definitions will result in linker
errors.


This is better.  I'd also s/will/now/, since we're talking about the 
present behavior of GCC 10, not some future behavior.


-Sandra

Re: [patch,avr, 1/3] Support 64-bit (long) double: The gcc part.

[Jeff Law]

On Mon, 2019-12-16 at 17:43 +0100, Georg-Johann Lay wrote:
> Am 16.12.19 um 17:40 schrieb Georg-Johann Lay:
> Patch 1/3 is the GCC changes: Documentation and new avr-specific
> configure options:
> 
> --with-libf7 selects to which level double support from libf7 is added
> to libgcc.
> 
> --with-double-comparison select what FLOAT_LIB_COMPARE_RETURNS_BOOL
> returns.
> 
> Johann
> 
> gcc/
>   * config.gcc (tm_defines) [target=avr]: Support --with-libf7,
>   --with-double-comparison.
>   * doc/install.texi: Document them.
>   * config/avr/avr-c.c (avr_cpu_cpp_builtins)
>   
>   : New built-in defines.
>   * doc/invoke.texi (AVR Built-in Macros): Document them.
>   * config/avr/avr-protos.h (avr_float_lib_compare_returns_bool): New.
>   * config/avr/avr.c (avr_float_lib_compare_returns_bool): New function.
>   * config/avr/avr.h (FLOAT_LIB_COMPARE_RETURNS_BOOL): New macro.
I'd suggest "--with-libf77" rather than "--with-libf7".  

jeff

Re: [PATCH] Mark param_max_combine_insns with Optimization keyword.

[Jeff Law]

On Thu, 2020-01-02 at 12:07 +0100, Martin Liška wrote:
> Hi.
> 
> The param is changed here:
> 
>/* Restrict the amount of work combine does at -Og while retaining
>   most of its useful transforms.  */
>if (opts->x_optimize_debug)
>  SET_OPTION_IF_UNSET (opts, opts_set, param_max_combine_insns, 2);
> 
> and so that it should be per-function. The only usage is in combine RTL
> pass, which is per-function optimization.
> 
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> 
> Ready to be installed?
> Thanks,
> Martin
> 
> gcc/ChangeLog:
> 
> 2020-01-02  Martin Liska  
> 
>   PR tree-optimization/92860
>   * params.opt: Mart param_max_combine_insns with Optimization
>   keyword.
OK
jeff

Re: [PATCH] Mark param_min_crossjump_insns with Optimization keyword.

[Jeff Law]

On Thu, 2020-01-02 at 12:06 +0100, Martin Liška wrote:
> Hi.
> 
> Again, the param is set based on optimize_size:
> 
>if (opts->x_optimize_size)
>  /* We want to crossjump as much as possible.  */
>  SET_OPTION_IF_UNSET (opts, opts_set, param_min_crossjump_insns, 1);
> 
> So that, the param should be per-function. The only usage is in cfgcleanup
> that is done per-function.
> 
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> 
> Ready to be installed?
> Thanks,
> Martin
> 
> gcc/ChangeLog:
> 
> 2020-01-02  Martin Liska  
> 
>   PR optimization/92860
>   * params.opt: Mark param_min_crossjump_insns with Optimization
>   keyword.
OK
jeff

Re: [PATCH] Mark -free as Optimization option.

[Jeff Law]

On Thu, 2020-01-02 at 12:04 +0100, Martin Liška wrote:
> Hi.
> 
> The flag is set based on optimization option:
> gcc/common/config/i386/i386-common.c:{ OPT_LEVELS_2_PLUS, OPT_free, NULL, 
> 1 },
> 
> and so that it should be also per-function. The only usage of the flag is
> in gate of a RTL pass, so that it will use on function selection.
> 
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> 
> Ready to be installed?
> Thanks,
> Martin
> 
> gcc/ChangeLog:
> 
> 2020-01-02  Martin Liska  
> 
>   PR tree-optimization/92860
>   * common.opt: Make flag_ree as optimization
>   attribute.
> 
> gcc/testsuite/ChangeLog:
> 
> 2020-01-02  Martin Liska  
> 
>   PR tree-optimization/92860
>   * gcc.dg/pr92860.c: New test.
OK
jeff

Re: typo in 'patern'

[Jeff Law]

On Thu, 2019-12-19 at 13:21 -0800, Bryan Stenson wrote:
> x-post from here: https://marc.info/?t=15767864485=1=2
> 
> diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
> index 6341216d1bc..e6d690b75c0 100644
> --- a/gcc/config/mips/mips.c
> diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
> index 6341216d1bc..e6d690b75c0 100644
> --- a/gcc/config/mips/mips.c
> +++ b/gcc/config/mips/mips.c
> @@ -18627,7 +18627,7 @@ vr4130_align_insns (void)
>if (length > 0)
> {
>   /* If the instruction is an asm statement or multi-instruction
> -mips.md patern, the length is only an estimate.  Insert an
> +mips.md pattern, the length is only an estimate.  Insert an
>  8 byte alignment after it so that the following instructions
>  can be handled correctly.  */
>   if (NONJUMP_INSN_P (SEQ_BEGIN (insn))
> diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
> index 0ad4a00739f..049ff93e0d5 100644
> --- a/gcc/doc/md.texi
> +++ b/gcc/doc/md.texi
> @@ -6287,7 +6287,7 @@ destination and source strings are operands 1
> and 2, and both are
>  the expansion of this pattern should store in operand 0 the address in
>  which the @code{NUL} terminator was stored in the destination string.
> 
> -This patern has also several optional operands that are same as in
> +This pattern has also several optional operands that are same as in
>  @code{setmem}.
> 
>  @cindex @code{setmem@var{m}} instruction pattern
THanks.  I've installed these typo fixes on the trunk.

jeff
> 

[PING^3][PATCH v3] Add `--with-toolexeclibdir=' configuration option

[Maciej W. Rozycki]

On Mon, 2 Dec 2019, Maciej W. Rozycki wrote:

> Provide means, in the form of a `--with-toolexeclibdir=' configuration 
> option, to override the default installation directory for target 
> libraries, otherwise known as $toolexeclibdir.  This is so that it is 
> possible to get newly-built libraries, particularly the shared ones, 
> installed in a common place, so that they can be readily used by the 
> target system as their host libraries, possibly over NFS, without a need 
> to manually copy them over from the currently hardcoded location they 
> would otherwise be installed in.

 Ping for:



  Maciej

[committed, amdgcn] Fix early-clobber in vec_extract

[Andrew Stubbs]

This patch fixes an execution test failure in gcc.dg/vect/vect-live-2.c.

The problem was that the input and output registers were the same, which 
isn't safe for this pattern. It could be fixed by reversing the 
instructions, but then that would still be broken for overlapping input 
and output register pairs. Other patterns use '0' to allow exact 
matches, but the input and outputs here are different size, and I'm not 
sure what happens there. Anyway, this is safe.


Andrew
Fix early-clobber in amdgcn vec_extract

2020-01-06  Andrew Stubbs  

	gcc/
	* config/gcn/gcn-valu.md (vec_extract): Add early
	clobber.

diff --git a/gcc/config/gcn/gcn-valu.md b/gcc/config/gcn/gcn-valu.md
index 457a66c1505..9baef24b1c8 100644
--- a/gcc/config/gcn/gcn-valu.md
+++ b/gcc/config/gcn/gcn-valu.md
@@ -580,10 +580,10 @@
(set_attr "laneselect" "yes")])
 
 (define_insn "vec_extract"
-  [(set (match_operand: 0 "register_operand"   "=Sg")
+  [(set (match_operand: 0 "register_operand"   "=")
 	(vec_select:
-	  (match_operand:VEC_2REG_MODE 1 "register_operand" "  v")
-	  (parallel [(match_operand:SI 2 "gcn_alu_operand"  "SvB")])))]
+	  (match_operand:VEC_2REG_MODE 1 "register_operand" "   v")
+	  (parallel [(match_operand:SI 2 "gcn_alu_operand"  " SvB")])))]
   ""
   "v_readlane_b32 %L0, %L1, %2\;v_readlane_b32 %H0, %H1, %2"
   [(set_attr "type" "vmult")

[PING^5][PATCH 0/4] Fix library testsuite compilation for build sysroot

[Maciej W. Rozycki]

On Fri, 20 Dec 2019, Mike Stump wrote:

> >> This patch series addresses a problem with the testsuite compiler being 
> >> set up across libatomic, libffi, libgo, libgomp with no correlation 
> >> whatsoever to the target compiler being used in GCC compilation.  
> >> Consequently there in no arrangement made to set up the compilation 
> >> sysroot according to the build sysroot specified for GCC compilation, 
> >> causing a catastrophic failure across the testsuites affected from the 
> >> inability to link executables.
> > 
> > Ping for:
> > 
> > 
> > 
> > 
> 
> Hum...  I'm wondering who should review this...  Feels like I should, 
> the problem is it intertwines with the build system as well.  So, let me 
> approve the testsuite parts so that can clear the way for someone else 
> to approve the remaining bits (if not obvious).

 Ping for the build system parts of:




  Maciej

Re: [PATCH] libstdcxx: Update ctype_base.h from NetBSD upstream

[Jonathan Wakely]

On 22/12/19 09:36 +1000, Gerald Pfeifer wrote:

Hi Matthew,

On Mon, 4 Feb 2019, Matthew Bauer wrote:

The ctype_base.h file in libstdc++-v3 is out of date for NetBSD. They
have changed their ctype.h definition. It was updated in their intree
libstdc++-v3 but not in the GCC one. My understanding is this is a
straightforward rewrite. I've attached my own patch, but the file can
be obtained directly here:

http://cvsweb.netbsd.org/bsdweb.cgi/src/external/gpl3/gcc/dist/libstdc%2b%2b-v3/config/os/bsd/netbsd/ctype_base.h

With the attached patch, libstdc++-v3 can succesfully be built with
NetBSD headers (along with --disable-libcilkrts).


I noticed this has not been applied yet, nor seen a follow-up?, and also
noticed it went to the gcc-patches list, but not libstd...@gcc.gnu.org.

Let me re-address this to libstd...@gcc.gnu.org in the hope the
maintainers there will have a look.

Gerald



diff --git a/libstdc++-v3/config/os/bsd/netbsd/ctype_base.h 
b/libstdc++-v3/config/os/bsd/netbsd/ctype_base.h
index ff3ec893974..21eccf9fde1 100644
--- a/libstdc++-v3/config/os/bsd/netbsd/ctype_base.h
+++ b/libstdc++-v3/config/os/bsd/netbsd/ctype_base.h
@@ -38,40 +38,46 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  /// @brief  Base class for ctype.
  struct ctype_base
  {
-// Non-standard typedefs.
-typedef const unsigned char*   __to_type;

// NB: Offsets into ctype::_M_table force a particular size
// on the mask type. Because of this, we don't use an enum.
-typedef unsigned char  mask;

#ifndef _CTYPE_U
-static const mask upper= _U;
-static const mask lower= _L;
-static const mask alpha= _U | _L;
-static const mask digit= _N;
-static const mask xdigit   = _N | _X;
-static const mask space= _S;
-static const mask print= _P | _U | _L | _N | _B;
-static const mask graph= _P | _U | _L | _N;
-static const mask cntrl= _C;
-static const mask punct= _P;
-static const mask alnum= _U | _L | _N;
+// Non-standard typedefs.
+typedef const unsigned char*   __to_type;
+
+typedef unsigned char  mask;
+
+static const mask upper= _U;
+static const mask lower= _L;
+static const mask alpha= _U | _L;
+static const mask digit= _N;
+static const mask xdigit   = _N | _X;
+static const mask space= _S;
+static const mask print= _P | _U | _L | _N | _B;
+static const mask graph= _P | _U | _L | _N;
+static const mask cntrl= _C;
+static const mask punct= _P;
+static const mask alnum= _U | _L | _N;
#else
-static const mask upper= _CTYPE_U;
-static const mask lower= _CTYPE_L;
-static const mask alpha= _CTYPE_U | _CTYPE_L;
-static const mask digit= _CTYPE_N;
-static const mask xdigit   = _CTYPE_N | _CTYPE_X;
-static const mask space= _CTYPE_S;
-static const mask print= _CTYPE_P | _CTYPE_U | _CTYPE_L | _CTYPE_N | 
_CTYPE_B;
-static const mask graph= _CTYPE_P | _CTYPE_U | _CTYPE_L | _CTYPE_N;
-static const mask cntrl= _CTYPE_C;
-static const mask punct= _CTYPE_P;
-static const mask alnum= _CTYPE_U | _CTYPE_L | _CTYPE_N;
+typedef const unsigned short*  __to_type;
+
+typedef unsigned short mask;
+
+static const mask upper= _CTYPE_U;
+static const mask lower= _CTYPE_L;
+static const mask alpha= _CTYPE_A;
+static const mask digit= _CTYPE_D;
+static const mask xdigit   = _CTYPE_X;
+static const mask space= _CTYPE_S;
+static const mask print= _CTYPE_R;
+static const mask graph= _CTYPE_G;
+static const mask cntrl= _CTYPE_C;
+static const mask punct= _CTYPE_P;
+static const mask alnum= _CTYPE_A | _CTYPE_D;
#endif
#if __cplusplus >= 201103L
-static const mask blank= space;
+static const mask blank= space;
#endif
  };

diff --git a/libstdc++-v3/config/os/bsd/netbsd/ctype_configure_char.cc 
b/libstdc++-v3/config/os/bsd/netbsd/ctype_configure_char.cc
index ed3b7cd0d6a..33358e8f5d8 100644
--- a/libstdc++-v3/config/os/bsd/netbsd/ctype_configure_char.cc
+++ b/libstdc++-v3/config/os/bsd/netbsd/ctype_configure_char.cc
@@ -38,11 +38,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION

// Information as gleaned from /usr/include/ctype.h

-  extern "C" const u_int8_t _C_ctype_[];
-
  const ctype_base::mask*
  ctype::classic_table() throw()
-  { return _C_ctype_ + 1; }
+  { return _C_ctype_tab_ + 1; }


The first patch attached to PR 64271 (i.e.
https://gcc.gnu.org/bugzilla/attachment.cgi?id=34254 ) does that
differently. Is it safe to make this change unconditionally?

Who authored these patches? We don't seem to have a changelog, not
even an author's name and email address, as required for any patch.

Here was my previous review, where I mentioned the ABI break:
https://gcc.gnu.org/ml/libstdc++/2014-12/msg00069.html
I didn't get a reply.

Re: [C++ PATCH] fix testcase

[Rainer Orth]

Hi Nathan,

> Jason's recent patch
> 2019-12-17  Jason Merrill  
>
>   PR c++/79592 - missing explanation of invalid constexpr.
>
> Caused ubsan/vptr-4.C to emit an additional, correct,
> diagnostic. Committing this to update the testcase.

this is PR testsuite/92991.

Rainer

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

[PING] Re: [Patch 0/X] HWASAN v3

[Matthew Malcomson]

Ping


On 17/12/2019 14:11, Matthew Malcomson wrote:
> I've noticed a few minor problems with this patch series after I sent it
> out (mostly testcase stuff, one documentation tidy-up, but also that one
> patch didn't bootstrap due to something fixed in a later patch).
> 
> I also rely on a documentation change that isn't part of the series.
> 
> I figure I should make this easy on anyone that wants to try the patch
> series out, so I'm attaching a compressed tarfile containing the entire
> patch series plus the additional documentation patch so it can all be
> applied at once with `git apply *`.
> 
> It's attached.
> 
> Matthew.
> 
> 
> 
> On 12/12/2019 15:18, Matthew Malcomson wrote:
>> Hello,
>>
>> I've gone through the suggestions Martin made and implemented  the ones I 
>> think
>> I can implement for GCC10.
>>
>> The two functionality changes in this version are:
>> Added the --param's hwasan-instrument-reads, hwasan-instrument-writes,
>> hwasan-instrument-allocas, hwasan-memintrin, options.  I.e. Those that asan 
>> has
>> and that make sense for hwasan.
>>
>> Avoided HWASAN_STACK_BACKGROUND in hwasan_increment_tag when using a
>> deterministic tagging approach.
>>
>>
>> There are a lot of extra comments and tests.
>>
>>
>> Bootstrapped and regtested on x86_64 and AArch64.
>> Bootstrapped with `--with-build-config=bootstrap-hwasan` on AArch64 and 
>> hwasan
>> features tested there.
>> Built the linux kernel using this feature and ran the test_kasan.ko testing 
>> to
>> check the this works for the kernel.
>> (NOTE: I actually did all the above testing before a search and replace of
>> `memory_tagging_p` for `hwasan_sanitize_p` and fixing a typo in the
>> `hwasan-instrument-allocas` parameter name, I will run all the tests again
>> before committing but figure I'll send this out now since I fully expect the
>> tests to still pass).
>>
>>
>> I noticed one extra testsuite failure from those mentioned in the previous
>> version emails: g++.dg/cpp2a/ucn2.C.
>> I believe this is HWASAN correctly catching a problem in the compiler.
>> I've logged the issue here 
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92919 .
>>
>>
>> I haven't gotten ASAN_MARK to print as HWASAN_MARK when using memory tagging,
>> since I'm not sure the way I found to implement this would be acceptable.  
>> The
>> inlined patch below works but it requires a special declaration instead of 
>> just
>> an ~#include~.
>>
>>
>> diff --git a/gcc/internal-fn.h b/gcc/internal-fn.h
>> index a1bc081..d81eb12 100644
>> --- a/gcc/internal-fn.h
>> +++ b/gcc/internal-fn.h
>> @@ -101,10 +101,16 @@ extern void init_internal_fns ();
>>
>>extern const char *const internal_fn_name_array[];
>>
>> +
>> +extern bool hwasan_sanitize_p (void);
>>static inline const char *
>>internal_fn_name (enum internal_fn fn)
>>{
>> -  return internal_fn_name_array[(int) fn];
>> +  const char *ret = internal_fn_name_array[(int) fn];
>> +  if (! strcmp (ret, "ASAN_MARK")
>> +  && hwasan_sanitize_p ())
>> +return "HWASAN_MARK";
>> +  return ret;
>>}
>>
>>extern internal_fn lookup_internal_fn (const char *);
>>
>>
>> Entire patch series attached to cover letter.
>>

Re: [PING^4][PATCH 0/4] Fix library testsuite compilation for build sysroot

[Maciej W. Rozycki]

Hi Julian,

> FYI: This patch seems to be causing problems for our (internal -- as
> you know!) test harness. I'm not sure if it's a local issue (or at least
> something we can work around here), or a problem with the patch itself
> though.

 I'm sorry to break your setup.  I'm currently a little bit busy before a 
conference next week I speak at, however I'll try to address your problem 
the best I can regardless.

> I'm currently working on offloading-enabled compilers. I see the same
> failure mode for both AMD GCN and NVPTX.
> 
> Without the patch, the compiler is found (with [find_gcc] I suppose) and
> invoked as x86_64-none-linux-gnu-gcc. That works fine for us, but we do
> (I think) "installed testing", which IIUC is atypical.

 I'm not sure if the libgomp-test-support.exp file produced by the build 
is supposed to be used in standalone testing rather than one that has been 
separately prepared for the standalone environment in question.

 However before I make any definite conclusion I would like to understand 
how things are supposed to work with an offload-enabled compiler.

> With the patch, the compiler is invoked as (at the risk of excessive
> detail) e.g.:
> 
> /scratch/jbrown/nvptx-mainline/obj/gcc-2018.11-99-x86_64-none-linux-gnu-x86_64-linux-gnu/./gcc/xgcc
>  
> -B/scratch/jbrown/nvptx-mainline/obj/gcc-2018.11-99-x86_64-none-linux-gnu-x86_64-linux-gnu/./gcc/
>  
> -B/scratch/jbrown/nvptx-mainline/install/opt/codesourcery/x86_64-none-linux-gnu/bin/
>  
> -B/scratch/jbrown/nvptx-mainline/install/opt/codesourcery/x86_64-none-linux-gnu/lib/
>  -isystem 
> /scratch/jbrown/nvptx-mainline/install/opt/codesourcery/x86_64-none-linux-gnu/include
>  -isystem 
> /scratch/jbrown/nvptx-mainline/install/opt/codesourcery/x86_64-none-linux-gnu/sys-include
>  
> --sysroot=/scratch/jbrown/nvptx-mainline/install/opt/codesourcery/x86_64-none-linux-gnu/libc
>  [...]
> 
> ...and then it fails to find libgomp.spec:
> 
> xgcc: fatal error: cannot read spec file 'libgomp.spec': No such file or 
> directory
> 
> Can your approach be made to work with an offload-enabled compiler? How
> should that spec file (and/or the target compiler) be located?

 As I recall there is a separate compiler invoked for the offload target.  
I don't have a suitable setup available to hand nor an easy way to make 
one.  Can you therefore please figure out and tell me how this is 
arranged?  Also where does the libgomp.spec file come from?

 Overall if libgomp-test-support.exp is considered appropriate for 
standalone testing, then I think two solutions are possible here:

1. An option is added to libgomp's $CC such that the compiler is able to 
   make builds involving the offload compiler where requested, and this 
   then propagates to GCC_UNDER_TEST as it stands.

2. The definition of GCC_UNDER_TEST in libgomp-test-support.exp is only 
   made if inexistent, and then you can predefine the variable in site.exp 
   however you find appropriate.

  Maciej

Re: [PATCH] libstdcxx: Update ctype_base.h from NetBSD upstream

[Jonathan Wakely]

On 22/12/19 09:36 +1000, Gerald Pfeifer wrote:

Hi Matthew,

On Mon, 4 Feb 2019, Matthew Bauer wrote:

The ctype_base.h file in libstdc++-v3 is out of date for NetBSD. They
have changed their ctype.h definition. It was updated in their intree
libstdc++-v3 but not in the GCC one. My understanding is this is a
straightforward rewrite. I've attached my own patch, but the file can
be obtained directly here:

http://cvsweb.netbsd.org/bsdweb.cgi/src/external/gpl3/gcc/dist/libstdc%2b%2b-v3/config/os/bsd/netbsd/ctype_base.h

With the attached patch, libstdc++-v3 can succesfully be built with
NetBSD headers (along with --disable-libcilkrts).


I noticed this has not been applied yet, nor seen a follow-up?, and also
noticed it went to the gcc-patches list, but not libstd...@gcc.gnu.org.

Let me re-address this to libstd...@gcc.gnu.org in the hope the
maintainers there will have a look.

Gerald



diff --git a/libstdc++-v3/config/os/bsd/netbsd/ctype_base.h 
b/libstdc++-v3/config/os/bsd/netbsd/ctype_base.h
index ff3ec893974..21eccf9fde1 100644
--- a/libstdc++-v3/config/os/bsd/netbsd/ctype_base.h
+++ b/libstdc++-v3/config/os/bsd/netbsd/ctype_base.h
@@ -38,40 +38,46 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  /// @brief  Base class for ctype.
  struct ctype_base
  {
-// Non-standard typedefs.
-typedef const unsigned char*   __to_type;

// NB: Offsets into ctype::_M_table force a particular size
// on the mask type. Because of this, we don't use an enum.
-typedef unsigned char  mask;

#ifndef _CTYPE_U
-static const mask upper= _U;
-static const mask lower= _L;
-static const mask alpha= _U | _L;
-static const mask digit= _N;
-static const mask xdigit   = _N | _X;
-static const mask space= _S;
-static const mask print= _P | _U | _L | _N | _B;
-static const mask graph= _P | _U | _L | _N;
-static const mask cntrl= _C;
-static const mask punct= _P;
-static const mask alnum= _U | _L | _N;
+// Non-standard typedefs.
+typedef const unsigned char*   __to_type;
+
+typedef unsigned char  mask;
+
+static const mask upper= _U;
+static const mask lower= _L;
+static const mask alpha= _U | _L;
+static const mask digit= _N;
+static const mask xdigit   = _N | _X;
+static const mask space= _S;
+static const mask print= _P | _U | _L | _N | _B;
+static const mask graph= _P | _U | _L | _N;
+static const mask cntrl= _C;
+static const mask punct= _P;
+static const mask alnum= _U | _L | _N;
#else
-static const mask upper= _CTYPE_U;
-static const mask lower= _CTYPE_L;
-static const mask alpha= _CTYPE_U | _CTYPE_L;
-static const mask digit= _CTYPE_N;
-static const mask xdigit   = _CTYPE_N | _CTYPE_X;
-static const mask space= _CTYPE_S;
-static const mask print= _CTYPE_P | _CTYPE_U | _CTYPE_L | _CTYPE_N | 
_CTYPE_B;
-static const mask graph= _CTYPE_P | _CTYPE_U | _CTYPE_L | _CTYPE_N;
-static const mask cntrl= _CTYPE_C;
-static const mask punct= _CTYPE_P;
-static const mask alnum= _CTYPE_U | _CTYPE_L | _CTYPE_N;
+typedef const unsigned short*  __to_type;
+
+typedef unsigned short mask;


I seem to recall looking at this previously and noting that the change
to ctype_base::mask is an ABI break. It means that code compiled with
old versions of GCC or on old versions of NetBSD will not be ABI
compatible with code compiled by a new GCC on a new version of NetBSD.

If the NetBSD maintainers are OK with that, then we can go ahead and
change it.

Re: [patch] Let libstdc++ know that VxWorks has_nanosleep

[Jonathan Wakely]

On 22/12/19 23:20 +0100, Olivier Hainque wrote:

Hi Jonathan,


On 19 Dec 2019, at 12:13, Jonathan Wakely  wrote:


Is there a way to detect that more reliably? Should we replicate the
test used later in the file, to detect whether the timers are really
enabled for VxWorks?

 AC_MSG_CHECKING([for nanosleep])

...

You're the port maintainer though, so if you think that's not needed
then the patch is OK for trunk.


Thanks for your feedback Jonathan,

Unfortunately, the AC kind of check is actually less reliable
on VxWorks, in particular for the so called "kernel" mode where
linking a "module" actually performs only a partial link to be
downloaded on a target where the run-time loader takes care of
the rest.

The current assumption on the environment configuration is on
a component included by default and required for a number
of very common time related operations anyway, so always there
in practice in our experience.

The rare/unlikely users that would not have the library
configured in on the VxWorks end would just not access to the
c++ time related facilities, which is not a problem.

Overall, this really seems like a good setting for
--enable-libstdcxx-time auto.


OK, that makes sense. Thanks!

[C++ PATCH] fix testcase

[Nathan Sidwell]

Jason's recent patch
2019-12-17  Jason Merrill  

PR c++/79592 - missing explanation of invalid constexpr.

Caused ubsan/vptr-4.C to emit an additional, correct, diagnostic. 
Committing this to update the testcase.


nathan
--
Nathan Sidwell
2020-01-06  Nathan Sidwell  

	PR c++/79592
	* g++.dg/ubsan/vptr-4.C: Add expected error.

Index: gcc/testsuite/g++.dg/ubsan/vptr-4.C
===
--- gcc/testsuite/g++.dg/ubsan/vptr-4.C	(revision 279901)
+++ gcc/testsuite/g++.dg/ubsan/vptr-4.C	(working copy)
@@ -36,5 +36,5 @@ struct W : V {
   int g() { return 0; }
   virtual int v() { return 1; }
-  constexpr const W *foo() { return (const W *) reinterpret_cast *> (this); }
+  constexpr const W *foo() { return (const W *) reinterpret_cast *> (this); } // { dg-error "is not a constant expression" }
 };
 

Re: [PATCH] libstdc++/92124 for associative containers

[Jonathan Wakely]

On 03/01/20 22:04 +0100, François Dumont wrote:

This is the patch to extend PR 92124 to the associative containers.

As it is pretty simple I thought it could maybe go in now.

I also think that the existing 92124 tests are not really testing what 
they should with the move assignment operators noexcept qualified, no 
?


    PR libstdc++/92124
    * include/bits/stl_tree.h
    (_Rb_tree<>::_M_move_assign(_Rb_tree&, false_type)): Replace
    std::move_if_noexcept by std::move.
    * testsuite/23_containers/deque/92124.cc
    (X::operator==(X&&)): Qualify noexcept(false).
    * testsuite/23_containers/forward_list/92124.cc: Likewise.
    * testsuite/23_containers/list/92124.cc: Likewise.
    * testsuite/23_containers/vector/92124.cc: Likewise.
    * testsuite/23_containers/map/92124.cc: New.
    * testsuite/23_containers/set/92124.cc: New.

Tested under linux x86_64.

François




diff --git a/libstdc++-v3/include/bits/stl_tree.h 
b/libstdc++-v3/include/bits/stl_tree.h
index 12ba3181dd9..9339011e872 100644
--- a/libstdc++-v3/include/bits/stl_tree.h
+++ b/libstdc++-v3/include/bits/stl_tree.h
@@ -1695,7 +1695,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
[&__roan](const value_type& __cval)
{
  auto& __val = const_cast(__cval);
- return __roan(std::move_if_noexcept(__val));
+ return __roan(std::move(__val));


This part is OK and so is the new test.


};
  _M_root() = _M_copy(__x, __lbd);
  __x.clear();
diff --git a/libstdc++-v3/testsuite/23_containers/deque/92124.cc 
b/libstdc++-v3/testsuite/23_containers/deque/92124.cc
index 0bdfcb70dcf..ea16d415a49 100644
--- a/libstdc++-v3/testsuite/23_containers/deque/92124.cc
+++ b/libstdc++-v3/testsuite/23_containers/deque/92124.cc
@@ -30,7 +30,7 @@ struct X {
// Tracking calls to assignment functions
X& operator=(const X&) { throw 1; }

-X& operator=(X&&) noexcept(true) { return *this; }
+X& operator=(X&&) noexcept(false) { return *this; }


These changes don't seem to be needed. Is there a reason to change it?

Re: [PATCH] PR libstdc++/92124 on hashtable

[Jonathan Wakely]

On 07/11/19 20:28 +0100, François Dumont wrote:
From what I understood from recent fix the unordered containers need 
to be updated the same way.


I hope you'll appreciate the usage of rvalue forwarding. Containers 
node values are moved as soon as _M_assign is called with a rvalue 
reference to the source container.


Additionnaly this patch removes usages of lambdas in _Hashtable.

If you confirm it I'll check for the same on _Rb_tree.

    * include/bits/hashtable.h (_Hashtable<>::__alloc_node_gen_t): New
    template alias.
    (_Hashtable<>::__mv_if_value_type_mv_noexcept): New.
    (_Hashtable<>::__fwd_value): New.
    (_Hashtable<>::_M_assign_elements<>): Remove _NodeGenerator template
    parameter.
    (_Hashtable<>::_M_assign<>): Add _Ht template parameter.
    (_Hashtable<>::operator=(const _Hashtable<>&)): Adapt.
    (_Hashtable<>::_M_move_assign): Adapt.
    (_Hashtable<>::_Hashtable(const _Hashtable&)): Adapt.
    (_Hashtable<>::_Hashtable(const _Hashtable&, const allocator_type&)):
    Adapt.
    (_Hashtable<>::_Hashtable(_Hashtable&&, const allocator_type&)):
    Adapt.
    * testsuite/23_containers/unordered_set/92124.cc: New.

Tested under Linux x86_64.

Ok to commit ?

François




diff --git a/libstdc++-v3/include/bits/hashtable.h 
b/libstdc++-v3/include/bits/hashtable.h
index ab579a7059e..c2b2219d471 100644
--- a/libstdc++-v3/include/bits/hashtable.h
+++ b/libstdc++-v3/include/bits/hashtable.h
@@ -255,6 +255,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION

  using __reuse_or_alloc_node_gen_t =
__detail::_ReuseOrAllocNode<__node_alloc_type>;
+  using __alloc_node_gen_t =
+   __detail::_AllocNode<__node_alloc_type>;

  // Simple RAII type for managing a node containing an element
  struct _Scoped_node
@@ -280,6 +282,20 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
__node_type* _M_node;
  };

+  template
+   static constexpr
+   typename conditional<__move_if_noexcept_cond::value,
+const _Tp&, _Tp&&>::type
+   __mv_if_value_type_mv_noexcept(_Tp& __x) noexcept
+   { return std::move(__x); }
+
+  template
+   static constexpr
+   typename conditional::value,
+value_type&&, const value_type&>::type
+   __fwd_value(_Ht&&, value_type& __val) noexcept
+   { return std::move(__val); }
+
  // Metaprogramming for picking apart hash caching.
  template
using __if_hash_cached = __or_<__not_<__hash_cached>, _Cond>;
@@ -406,13 +422,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION

  // Assign *this using another _Hashtable instance. Either elements
  // are copy or move depends on the _NodeGenerator.


N.B. I know this comment was already there, but could you please
change the second sentence to say:

"Whether elements are copied or moved ..."


-  template
+  template
void
-   _M_assign_elements(_Ht&&, const _NodeGenerator&);
+   _M_assign_elements(_Ht&&);

-  template
+  template
void
-   _M_assign(const _Hashtable&, const _NodeGenerator&);
+   _M_assign(_Ht&&, const _NodeGenerator&);

  void
  _M_move_assign(_Hashtable&&, true_type);

Re: [PATCH] PR libstdc++/92124 on hashtable

[Jonathan Wakely]

On 07/11/19 20:28 +0100, François Dumont wrote:
From what I understood from recent fix the unordered containers need 
to be updated the same way.


I hope you'll appreciate the usage of rvalue forwarding. Containers 


Yes, I think it makes sense.

node values are moved as soon as _M_assign is called with a rvalue 
reference to the source container.


Additionnaly this patch removes usages of lambdas in _Hashtable.

If you confirm it I'll check for the same on _Rb_tree.

    * include/bits/hashtable.h (_Hashtable<>::__alloc_node_gen_t): New
    template alias.
    (_Hashtable<>::__mv_if_value_type_mv_noexcept): New.
    (_Hashtable<>::__fwd_value): New.
    (_Hashtable<>::_M_assign_elements<>): Remove _NodeGenerator template
    parameter.
    (_Hashtable<>::_M_assign<>): Add _Ht template parameter.
    (_Hashtable<>::operator=(const _Hashtable<>&)): Adapt.
    (_Hashtable<>::_M_move_assign): Adapt.
    (_Hashtable<>::_Hashtable(const _Hashtable&)): Adapt.
    (_Hashtable<>::_Hashtable(const _Hashtable&, const allocator_type&)):
    Adapt.
    (_Hashtable<>::_Hashtable(_Hashtable&&, const allocator_type&)):
    Adapt.
    * testsuite/23_containers/unordered_set/92124.cc: New.

Tested under Linux x86_64.

Ok to commit ?

François




diff --git a/libstdc++-v3/include/bits/hashtable.h 
b/libstdc++-v3/include/bits/hashtable.h
index ab579a7059e..c2b2219d471 100644
--- a/libstdc++-v3/include/bits/hashtable.h
+++ b/libstdc++-v3/include/bits/hashtable.h
@@ -255,6 +255,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION

  using __reuse_or_alloc_node_gen_t =
__detail::_ReuseOrAllocNode<__node_alloc_type>;
+  using __alloc_node_gen_t =
+   __detail::_AllocNode<__node_alloc_type>;

  // Simple RAII type for managing a node containing an element
  struct _Scoped_node
@@ -280,6 +282,20 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
__node_type* _M_node;
  };

+  template
+   static constexpr
+   typename conditional<__move_if_noexcept_cond::value,
+const _Tp&, _Tp&&>::type
+   __mv_if_value_type_mv_noexcept(_Tp& __x) noexcept
+   { return std::move(__x); }


This is only used in one place. Adding a function doesn't seem
worthwhile, you can just do this where you use it:

  using _Fwd_Ht = typename
conditional<__move_if_noexcept_cond::value,
const _Ht&, _Ht>::type;
  _M_assign(std::forward<_Fwd_Ht>(__ht), __alloc_gen);



+  template
+   static constexpr
+   typename conditional::value,
+value_type&&, const value_type&>::type


I think I'd prefer to reverse the condition, i.e.

  typename conditional::value,
   const value_type&, value_type&&>::type


+   __fwd_value(_Ht&&, value_type& __val) noexcept
+   { return std::move(__val); }


Since this doesn't use the first parameter, it can just be removed:

  template
static constexpr
typename conditional::value,
 const value_type&, value_type&&>::type
__fwd_value(value_type& __val) noexcept
{ return std::move(__val); }

That simplifies the usage from:

  __fwd_value(std::forward<_Ht>(__ht), __ht_n->_M_v()))

so it becomes:

  __fwd_value<_Ht>(__ht_n->_M_v()))


Maybe __fwd_value<_Ht> should be __fwd_value_for<_Ht> so it's clear
how it depends on _Ht (because otherwise it looks like it is
forwarding as _Ht&& like std::forward<_Ht> would).

What do you think?

Re: [wwwdocs] Document -fcommon default change

[Jonathan Wakely]

On 05/12/19 13:14 +, Wilco Dijkstra wrote:

Hi,

Add entries for the default change in changes.html and porting_to.html.
Passes the W3 validator.

Cheers,
Wilco

---

diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index 
e02966460450b7aad884b2d45190b9ecd8c7a5d8..304e1e8ccd38795104156e86b92062696fa5aa8b
 100644
--- a/htdocs/gcc-10/changes.html
+++ b/htdocs/gcc-10/changes.html
@@ -102,6 +102,11 @@ a work-in-progress.
In C2X mode, -fno-fp-int-builtin-inexact is
enabled by default.
  
+
+  GCC now defaults to -fno-common.  In C, global variables 
with
+  multiple tentative definitions will result in linker errors.
+  Global variable accesses are also more efficient on various targets.


The "also" here is a bit unclear what it refers to. It seems to follow
on from the previous sentence, which suggests that the efficiencies
are somehow related to the cases that get linker errors.

How about:

GCC now defaults to -fno-common.  As a result, global
variable accesses are more efficient on various targets.  In C, global
variables with multiple tentative definitions will result in linker
errors.



+  


C++
diff --git a/htdocs/gcc-10/porting_to.html b/htdocs/gcc-10/porting_to.html
index 
3256e8a35d00ce1352c169a1c6df6d8f120889ee..e2c7e226a83b7720fe6ed40061cdddbc27659664
 100644
--- a/htdocs/gcc-10/porting_to.html
+++ b/htdocs/gcc-10/porting_to.html
@@ -29,9 +29,25 @@ and provide solutions. Let us know if you have suggestions 
for improvements!
Preprocessor issues
-->

-
+
+Default to -fno-common


What does "complit" mean? Would a more memorable anchor such as
"common" or "no-common" be better?

[PATCH] Relax invalidation of TOP N counters in PGO.

[Martin Liška]

Hi.

As Honza noticed in the PR, we are quite strict about TOP N
counter invalidation due to multiple values that can't
fit in a counter. We due it in order to have a reproducible
builds. I guess we should do a compromise in between reproducibility
and possible speed up. That's why I'm suggesting to invalidate
a TOP N counter only if param_profile_topn_invalid_threshold percent
of profile are missing.

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

Ready to be installed?
Thanks,
Martin

gcc/ChangeLog:

2020-01-06  Martin Liska  

PR tree-optimization/92924
* params.opt (param_profile_topn_invalid_threshold):
New parameter.
* profile.c (sort_hist_values): Mark TOP N counter
invalid only if significant amount of samples
is missing.

gcc/testsuite/ChangeLog:

2020-01-06  Martin Liska  

PR tree-optimization/92924
* gcc.dg/tree-prof/pr92924-2.c: New test.
* gcc.dg/tree-prof/pr92924.c: New test.

libgcc/ChangeLog:

2020-01-06  Martin Liska  

PR tree-optimization/92924
* libgcov-merge.c (merge_topn_values_set): Replace
value with lowest count.
---
 gcc/params.opt |  4 +++
 gcc/profile.c  | 17 +--
 gcc/testsuite/gcc.dg/tree-prof/pr92924-2.c | 34 ++
 gcc/testsuite/gcc.dg/tree-prof/pr92924.c   | 34 ++
 libgcc/libgcov-merge.c | 12 ++--
 5 files changed, 95 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/tree-prof/pr92924-2.c
 create mode 100644 gcc/testsuite/gcc.dg/tree-prof/pr92924.c


diff --git a/gcc/params.opt b/gcc/params.opt
index 6f05b29a929..dd4e1546d93 100644
--- a/gcc/params.opt
+++ b/gcc/params.opt
@@ -756,6 +756,10 @@ The minimum constant stride beyond which we should use prefetch hints for.
 Common Joined UInteger Var(param_profile_func_internal_id) IntegerRange(0, 1) Param
 Use internal function id in profile lookup.
 
+-param=profile-topn-invalid-threshold=
+Common Joined UInteger Var(param_profile_topn_invalid_threshold) IntegerRange(0, 100) Init(10) Param Optimization
+Threshold of missing samples (in percent) that lead to an invalid (and ignored) TOP N counter.
+
 -param=rpo-vn-max-loop-depth=
 Common Joined UInteger Var(param_rpo_vn_max_loop_depth) Init(7) IntegerRange(2, 65536) Param
 Maximum depth of a loop nest to fully value-number optimistically.
diff --git a/gcc/profile.c b/gcc/profile.c
index e124dc6173a..d3479f0e998 100644
--- a/gcc/profile.c
+++ b/gcc/profile.c
@@ -765,9 +765,20 @@ compute_branch_probabilities (unsigned cfg_checksum, unsigned lineno_checksum)
 static void
 sort_hist_values (histogram_value hist)
 {
-  /* counters[2] equal to -1 means that all counters are invalidated.  */
-  if (hist->hvalue.counters[2] == -1)
-return;
+  /* Calculate what number of samples didn't fit into counters.  */
+  gcov_type sample_total = 0;
+  for (unsigned i = 0; i < GCOV_TOPN_VALUES; i++)
+sample_total += hist->hvalue.counters[2 * i + 2];
+
+  /* Mark the counter invalid if we miss X% of samples or more.  */
+  gcc_assert (hist->hvalue.counters[2] != -1);
+  gcov_type threshold
+= (100 - param_profile_topn_invalid_threshold) * hist->hvalue.counters[0];
+  if (100 * sample_total <= threshold)
+{
+  hist->hvalue.counters[2] = -1;
+  return;
+}
 
   gcc_assert (hist->type == HIST_TYPE_TOPN_VALUES
 	  || hist->type == HIST_TYPE_INDIR_CALL);
diff --git a/gcc/testsuite/gcc.dg/tree-prof/pr92924-2.c b/gcc/testsuite/gcc.dg/tree-prof/pr92924-2.c
new file mode 100644
index 000..d78d73df04c
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-prof/pr92924-2.c
@@ -0,0 +1,34 @@
+/* { dg-options "-O2 -fdump-tree-optimized -fdump-ipa-profile-optimized --param=profile-topn-invalid-threshold=1" } */
+unsigned int a[1000];
+unsigned int b = 99;
+unsigned int c = 10022;
+unsigned int d = 10033;
+unsigned int e = 100444;
+unsigned int f = 100;
+int
+main ()
+{
+  int i;
+  unsigned int n;
+  for (i = 0; i < 1000; i++)
+{
+	a[i]=1000+i;
+}
+  for (i = 0; i < 1000; i++)
+{
+  if (i % 100 == 1)
+	n = b;
+  else if (i % 100 == 2)
+	n = c;
+  else if (i % 100 == 3)
+	n = d;
+  else if (i % 100 == 4)
+	n = e;
+  else
+	n = f;
+  a[i] /= n;
+}
+  return 0;
+}
+/* autofdo does not do value profiling so far */
+/* { dg-final-use-not-autofdo { scan-ipa-dump-not "Transformation done: div.mod by constant 100" "profile"} } */
diff --git a/gcc/testsuite/gcc.dg/tree-prof/pr92924.c b/gcc/testsuite/gcc.dg/tree-prof/pr92924.c
new file mode 100644
index 000..8cee33f3a43
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-prof/pr92924.c
@@ -0,0 +1,34 @@
+/* { dg-options "-O2 -fdump-tree-optimized -fdump-ipa-profile-optimized" } */
+unsigned int a[1000];
+unsigned int b = 99;
+unsigned int c = 10022;
+unsigned int d = 10033;
+unsigned int e = 100444;
+unsigned int f = 100;

Re: [PATCH] Document cloning for the target_clone attribute.

[Martin Sebor]

On 1/6/20 3:05 AM, Martin Liška wrote:

Hi.

The patch is about explanation what happens when
a target_clone function calls a function without
the attribute.

Ready for trunk?
Thanks,
Martin

gcc/ChangeLog:

2020-01-06  Martin Liska  

 PR ipa/83411
 * doc/extend.texi: Explain cloning for target_clone
 attribute.
---
  gcc/doc/extend.texi | 6 ++
  1 file changed, 6 insertions(+)


diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 05ec62c552b..184146abd10 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -3768,6 +3768,12 @@ the @code{ifunc} attribute above) that 
dynamically selects a clone

 suitable for current architecture.  The resolver is created only if there
 is a usage of a function with @code{target_clones} attribute.

+Note that any subsequent call of a function without @code{target_clone}
+from a @code{target_clone} caller will not lead to copying
+(target clone) of the called function.
+If you want to enforce such behaviour,
+we recommend to use @code{flatter} attribute for the caller function.
+

Should that be "the @code{flatten} attribute?"  (Article and
an 'n' rather than an 'r' in "flatten".)

Also, (assuming I'm reading it correctly) would the rest of
the sentence be clearer if it instead read:

  we recommend declaring the calling function with the @code{flatten}
  attribute?

Martin

[Ping^2][patch,avr, 2/3] Support 64-bit (long) double: The libgcc changes.

[Georg-Johann Lay]

Ping #2

Georg-Johann Lay schrieb:

Am 16.12.19 um 17:40 schrieb Georg-Johann Lay:

Patch 2/3 is the libgcc additions:

--with-libf7 selects which makefile-snips from libf7 to use.

libgcc/
* config.host (tmake_file) [target=avr]: Add t-libf7,
t-libf7-math, t-libf7-math-symbols as specified by --with-libf7=.
* config/avr/t-avrlibc: Don't copy libgcc.a if there are modules
depending on sizeof (double) or sizeof (long double).
* config/avr/libf7: New folder.



Index: libgcc/config.host
===
--- libgcc/config.host  (revision 278552)
+++ libgcc/config.host  (working copy)
@@ -514,6 +514,29 @@ arm*-*-eabi* | arm*-*-symbianelf* | arm*
 avr-*-*)
# Make HImode functions for AVR
tmake_file="${cpu_type}/t-avr t-fpbit"
+   # Make some DFmode functions from libf7, part of avr-libgcc.
+   # This must be prior to adding t-avrlibc.
+   case "y${with_libf7}" in
+   yno)
+   # No libf7 support.
+   ;;
+   ylibgcc)
+   tmake_file="$tmake_file ${cpu_type}/libf7/t-libf7"
+   ;;
+   ymath)
+   tmake_file="$tmake_file ${cpu_type}/libf7/t-libf7-math"
+   tmake_file="$tmake_file ${cpu_type}/libf7/t-libf7"
+   ;;
+   ymath-symbols | yyes | y)
+   tmake_file="$tmake_file ${cpu_type}/libf7/t-libf7-math-symbols"
+   tmake_file="$tmake_file ${cpu_type}/libf7/t-libf7-math"
+   tmake_file="$tmake_file ${cpu_type}/libf7/t-libf7"
+   ;;
+   *)
+   echo "Error: --with-libf7=${with_libf7} but can only be used 
with: 'libgcc', 'math', 'math-symbols', 'yes', 'no'" 1>&2
+   exit 1
+   ;;
+   esac
if test x${with_avrlibc} != xno; then
tmake_file="$tmake_file ${cpu_type}/t-avrlibc"
fi
Index: libgcc/config/avr/t-avrlibc
===
--- libgcc/config/avr/t-avrlibc (revision 278992)
+++ libgcc/config/avr/t-avrlibc (working copy)
@@ -65,6 +65,12 @@ LIB2FUNCS_EXCLUDE += \
_fixunssfdi \
_floatdisf _floatundisf
 
+ifeq (,$(WITH_LIBF7_MATH_SYMBOLS))
+
+# No modules depend on __SIZEOF_LONG_DOUBLE__ or __SIZEOF_DOUBLE__
+# which means we might have an opportunity to copy libgcc.a.
+# WITH_LIBF7_MATH_SYMBOLS is set by libf7/t-libf7-math-symbols.
+
 ifneq (,$(findstring avr,$(MULTISUBDIR)))
 
 # We are not in the avr2 (default) subdir, hence copying will work.
@@ -95,3 +101,4 @@ Makefile: t-copy-libgcc.dep
 
 endif
 endif
+endif

[Ping^2][patch,avr, 0/3] Support 64-bit (long) double.

[Georg-Johann Lay]

Ping #2

Georg-Johann Lay schrieb:
Now that the avr backend can support 64-bit floats by means of 
configure-options --with-double= and --with-long-double=, this patch 
series adds some routines to support it.


It's an ad-hoc, avr-specific implementation in assembly and GNU-C which 
is added as a new subfolder in libgcc/config/avr/libf7.


Patch 1/3 is the GCC changes: Documentation and new avr-specific 
configure options:


--with-libf7 selects to which level double support from libf7 is added 
to libgcc.


--with-double-comparison select what FLOAT_LIB_COMPARE_RETURNS_BOOL 
returns.


I wrote the libf7 code from scratch and put it under GPL v3 + library 
exception, so it should be no problem to have it as part of libgcc.


Patch 2/3 is the libgcc additions:

--with-libf7 selects which makefile-snips from libf7 to use.

Patch 3/3 is the actual libf7 implementation.  A great deal of which is 
assembly, together with C + inline assembly for higher routines.


Ok for trunk?

Johann

[Ping^2][patch,avr, 1/3] Support 64-bit (long) double: The gcc part.

[Georg-Johann Lay]

Ping #2

Georg-Johann Lay schrieb:

Am 16.12.19 um 17:40 schrieb Georg-Johann Lay:
Patch 1/3 is the GCC changes: Documentation and new avr-specific
configure options:

--with-libf7 selects to which level double support from libf7 is added
to libgcc.

--with-double-comparison select what FLOAT_LIB_COMPARE_RETURNS_BOOL
returns.

Johann

gcc/
* config.gcc (tm_defines) [target=avr]: Support --with-libf7,
--with-double-comparison.
* doc/install.texi: Document them.
* config/avr/avr-c.c (avr_cpu_cpp_builtins)

: New built-in defines.
* doc/invoke.texi (AVR Built-in Macros): Document them.
* config/avr/avr-protos.h (avr_float_lib_compare_returns_bool): New.
* config/avr/avr.c (avr_float_lib_compare_returns_bool): New function.
* config/avr/avr.h (FLOAT_LIB_COMPARE_RETURNS_BOOL): New macro.



Index: gcc/config/avr/avr-c.c
===
--- gcc/config/avr/avr-c.c  (revision 278667)
+++ gcc/config/avr/avr-c.c  (working copy)
@@ -390,6 +390,20 @@ start address.  This macro shall be used
   cpp_define (pfile, "__WITH_AVRLIBC__");
 #endif /* WITH_AVRLIBC */
 
+  // From configure --with-libf7={|libgcc|math|math-symbols|yes|no}
+
+#ifdef WITH_LIBF7_LIBGCC
+  cpp_define (pfile, "__WITH_LIBF7_LIBGCC__");
+#endif /* WITH_LIBF7_LIBGCC */
+
+#ifdef WITH_LIBF7_MATH
+  cpp_define (pfile, "__WITH_LIBF7_MATH__");
+#endif /* WITH_LIBF7_MATH */
+
+#ifdef WITH_LIBF7_MATH_SYMBOLS
+  cpp_define (pfile, "__WITH_LIBF7_MATH_SYMBOLS__");
+#endif /* WITH_LIBF7_MATH_SYMBOLS */
+
   // From configure --with-double={|32|32,64|64,32|64}
 
 #ifdef HAVE_DOUBLE_MULTILIB
@@ -438,7 +452,23 @@ start address.  This macro shall be used
 #error "align this with config.gcc"
 #endif
 
-  
+  // From configure --with-double-comparison={2|3} --with-libf7.
+
+#if defined (WITH_DOUBLE_COMPARISON)
+#if WITH_DOUBLE_COMPARISON == 2 || WITH_DOUBLE_COMPARISON == 3
+  /* The number of states a DFmode comparison libcall might take and
+ reflects what avr.c:FLOAT_LIB_COMPARE_RETURNS_BOOL returns for
+ DFmode.  GCC's default is 3-state, but some libraries like libf7
+ implement true / false (2-state).  */
+  cpp_define_formatted (pfile, "__WITH_DOUBLE_COMPARISON__=%d",
+   WITH_DOUBLE_COMPARISON);
+#else
+#error "align this with config.gcc"
+#endif
+#else
+#error "align this with config.gcc"
+#endif
+
   /* Define builtin macros so that the user can easily query whether
  non-generic address spaces (and which) are supported or not.
  This is only supported for C.  For C++, a language extension is needed
Index: gcc/config/avr/avr-protos.h
===
--- gcc/config/avr/avr-protos.h (revision 278667)
+++ gcc/config/avr/avr-protos.h (working copy)
@@ -128,6 +128,8 @@ extern bool avr_xload_libgcc_p (machine_
 extern rtx avr_eval_addr_attrib (rtx x);
 extern bool avr_casei_sequence_check_operands (rtx *xop);
 
+extern bool avr_float_lib_compare_returns_bool (machine_mode, enum rtx_code);
+
 static inline unsigned
 regmask (machine_mode mode, unsigned regno)
 {
Index: gcc/config/avr/avr.c
===
--- gcc/config/avr/avr.c(revision 278667)
+++ gcc/config/avr/avr.c(working copy)
@@ -14575,6 +14575,23 @@ avr_fold_builtin (tree fndecl, int n_arg
   return NULL_TREE;
 }
 
+
+/* Worker function for `FLOAT_LIB_COMPARE_RETURNS_BOOL'.  */
+
+bool
+avr_float_lib_compare_returns_bool (machine_mode mode, enum rtx_code)
+{
+  if (mode == DFmode)
+{
+#if WITH_DOUBLE_COMPARISON == 2
+  return true;
+#endif
+}
+
+  // This is the GCC default and also what AVR-LibC implements.
+  return false;
+}
+
 
 
 /* Initialize the GCC target structure.  */
Index: gcc/config/avr/avr.h
===
--- gcc/config/avr/avr.h(revision 278667)
+++ gcc/config/avr/avr.h(working copy)
@@ -107,6 +107,9 @@ These two properties are reflected by bu
 #define BYTES_BIG_ENDIAN 0
 #define WORDS_BIG_ENDIAN 0
 
+#define FLOAT_LIB_COMPARE_RETURNS_BOOL(mode, comparison) \
+  avr_float_lib_compare_returns_bool (mode, comparison)
+
 #ifdef IN_LIBGCC2
 /* This is to get correct SI and DI modes in libgcc2.c (32 and 64 bits).  */
 #define UNITS_PER_WORD 4
Index: gcc/config.gcc
===
--- gcc/config.gcc  (revision 278552)
+++ gcc/config.gcc  (working copy)
@@ -1303,6 +1303,46 @@ avr-*-*)
tm_file="${tm_file} ${cpu_type}/avrlibc.h"
tm_defines="${tm_defines} WITH_AVRLIBC"
fi
+   # Work out avr_double_comparison which is 2 or 3 and is used in
+   # target hook FLOAT_LIB_COMPARE_RETURNS_BOOL to determine whether
+   # DFmode comparisons return 3-state or 2-state results.
+   case y${with_double_comparison} in
+   y | ytristate)
+   

[committed][AArch64] Use move-if-change for aarch64-tune.md

[Richard Sandiford]

If aarch64-tune.md was older than gentune.sh or aarch64-cores.def,
we'd try to overwrite it even if the current contents were correct.
This could cause problems with read-only source directories and
could cause spurious copying for rsync --archive.

Tested on aarch64-linux-gnu.  Also tested by changing aarch64-cores.def
and making sure that the file was updated appropriately.

Richard


2020-01-06  Richard Sandiford  

gcc/
* config/aarch64/t-aarch64 ($(srcdir)/config/aarch64/aarch64-tune.md):
Depend on...
(s-aarch64-tune-md): ...this new stamp file.  Pipe the new contents
to a temporary file and use move-if-change to update the real
file where necessary.

Index: gcc/config/aarch64/t-aarch64
===
--- gcc/config/aarch64/t-aarch642020-01-06 12:58:16.453794569 +
+++ gcc/config/aarch64/t-aarch642020-01-06 13:01:23.332565292 +
@@ -24,11 +24,15 @@ OPTIONS_H_EXTRA += $(srcdir)/config/aarc
   $(srcdir)/config/aarch64/aarch64-fusion-pairs.def \
   $(srcdir)/config/aarch64/aarch64-tuning-flags.def
 
-$(srcdir)/config/aarch64/aarch64-tune.md: $(srcdir)/config/aarch64/gentune.sh \
+$(srcdir)/config/aarch64/aarch64-tune.md: s-aarch64-tune-md; @true
+s-aarch64-tune-md: $(srcdir)/config/aarch64/gentune.sh \
$(srcdir)/config/aarch64/aarch64-cores.def
$(SHELL) $(srcdir)/config/aarch64/gentune.sh \
$(srcdir)/config/aarch64/aarch64-cores.def > \
+   tmp-aarch64-tune.md
+   $(SHELL) $(srcdir)/../move-if-change tmp-aarch64-tune.md \
$(srcdir)/config/aarch64/aarch64-tune.md
+   $(STAMP) s-aarch64-tune-md
 
 aarch64-builtins.o: $(srcdir)/config/aarch64/aarch64-builtins.c $(CONFIG_H) \
   $(SYSTEM_H) coretypes.h $(TM_H) \

[AArch64] Fix constraints for CPY /M

[Richard Sandiford]

The constraints for CPY /M allowed p0-p15 instead of the intended p0-p7.
This looks like a pasto from the preceding constant pattern, where p0-p15
is allowed.

Tested on aarch64-linux-gnu and applied as 279899.

Richard


2020-01-06  Richard Sandiford  

gcc/
* config/aarch64/aarch64-sve.md (@aarch64_sel_dup): Use Upl
rather than Upa for CPY /M.

gcc/testsuite/
* gcc.target/aarch64/sve/acle/general/cpy_1.c: New test.

Index: gcc/config/aarch64/aarch64-sve.md
===
--- gcc/config/aarch64/aarch64-sve.md   2020-01-06 12:58:16.453794569 +
+++ gcc/config/aarch64/aarch64-sve.md   2020-01-06 12:59:18.173388581 +
@@ -6523,7 +6523,7 @@ (define_insn "*vcond_mask_"
 (define_insn "@aarch64_sel_dup"
   [(set (match_operand:SVE_FULL 0 "register_operand" "=?w, w, ??w, ?, ??, 
?")
(unspec:SVE_FULL
- [(match_operand: 3 "register_operand" "Upa, Upa, Upl, Upl, 
Upl, Upl")
+ [(match_operand: 3 "register_operand" "Upl, Upl, Upl, Upl, 
Upl, Upl")
   (vec_duplicate:SVE_FULL
 (match_operand: 1 "register_operand" "r, w, r, w, r, w"))
   (match_operand:SVE_FULL 2 "aarch64_simd_reg_or_zero" "0, 0, Dz, Dz, 
w, w")]
Index: gcc/testsuite/gcc.target/aarch64/sve/acle/general/cpy_1.c
===
--- /dev/null   2019-09-17 11:41:18.176664108 +0100
+++ gcc/testsuite/gcc.target/aarch64/sve/acle/general/cpy_1.c   2020-01-06 
12:59:18.173388581 +
@@ -0,0 +1,42 @@
+/* { dg-do compile } */
+/* { dg-options "-O" } */
+/* { dg-final { check-function-bodies "**" "" } } */
+
+#include 
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/*
+** dup_x0_m:
+** add (x[0-9]+), x0, #?1
+** mov (p[0-7])\.b, p15\.b
+** mov z0\.d, \2/m, \1
+** ret
+*/
+svuint64_t
+dup_x0_m (svuint64_t z0, uint64_t x0)
+{
+  register svbool_t pg asm ("p15");
+  asm volatile ("" : "=Upa" (pg));
+  return svdup_u64_m (z0, pg, x0 + 1);
+}
+
+/*
+** dup_d1_z:
+** mov (p[0-7])\.b, p15\.b
+** mov z0\.d, \1/m, d1
+** ret
+*/
+svfloat64_t
+dup_d1_z (svfloat64_t z0, float64_t d1)
+{
+  register svbool_t pg asm ("p15");
+  asm volatile ("" : "=Upa" (pg));
+  return svdup_f64_m (z0, pg, d1);
+}
+
+#ifdef __cplusplus
+}
+#endif

[PING^2][patch][avr] PR92606: Disable -fipa-icf-variables because it generates wrong code.

[Georg-Johann Lay]

Ping #2.

Hi, this patch turns off -fipa-icf-variables because it generates wrong 
code like for PR92606.  As there is no target hook that could decide 
whether such optimizations are obsolete, disable such optimizations 
alltogether until PR92932 (target hook to disable such optimizations 
depending on object attributes and address-spcace) is available.


Ok to apply?

Johann


Work around PR ipa/92932 by disabling -fipa-icf-variables until
PR92932 will have been solved.

PR ipa/92932
PR target/92606
* common/config/avr/avr-common.c (avr_option_optimization_table)
<-fipa-icf-variables>: Disable.

[PING^2][patch][avr] New option -nodevicespecs to omit -specs=... in self specs.

[Georg-Johann Lay]

Ping #2

Hi, currently device support in avr-gcc is accomplished by injecting a 
specs file my means of -specs=... in dirver self specs.


This patch adds a new avr driver option to omit the addition of 
respective -specs option so give the user more freedom.


Ok to apply?

Johann

* config/avr/avr.opt (-nodevicespecs): New driver option.
* config/avr/driver-avr.c (avr_devicespecs_file): Only issue
"-specs=device-specs/..." if that option is not set.
* doc/invoke.texi (AVR Options) <-nodevicespecs>: Document.

[committed, amdgcn] Fix inline immediate range

[Andrew Stubbs]

Inline immediates for AMD GCN instructions are supposed to be in the 
range -16..64 inclusive, but the implementation had the upper bound 
exclusive.


This patch fixes the error.

Andrew
Fix amdgcn inline immediate range

2020-01-06  Andrew Stubbs  

	gcc/
	* config/gcn/gcn.c (gcn_inline_constant_p): Allow 64 as an inline
	immediate.

diff --git a/gcc/config/gcn/gcn.c b/gcc/config/gcn/gcn.c
index 94f1e45bb3d..b361cffbb84 100644
--- a/gcc/config/gcn/gcn.c
+++ b/gcc/config/gcn/gcn.c
@@ -842,7 +842,7 @@ bool
 gcn_inline_constant_p (rtx x)
 {
   if (GET_CODE (x) == CONST_INT)
-return INTVAL (x) >= -16 && INTVAL (x) < 64;
+return INTVAL (x) >= -16 && INTVAL (x) <= 64;
   if (GET_CODE (x) == CONST_DOUBLE)
 return gcn_inline_fp_constant_p (x, false);
   if (GET_CODE (x) == CONST_VECTOR)

[PATCH] libstdc++: Remove redundant inequality operators in

[Jonathan Wakely]

* include/std/stop_token (stop_token): Remove operator!= (LWG 3254).
(stop_source): Likewise (LWG 3362).
* testsuite/30_threads/stop_token/stop_source.cc: Test equality
comparisons.

Tested powerpc64le-linux, committed to trunk.


commit 55ac97433857c19cd9ecf3fbf6e35583d72da86d
Author: Jonathan Wakely 
Date:   Mon Jan 6 11:26:16 2020 +

libstdc++: Remove redundant inequality operators in 

* include/std/stop_token (stop_token): Remove operator!= (LWG 3254).
(stop_source): Likewise (LWG 3362).
* testsuite/30_threads/stop_token/stop_source.cc: Test equality
comparisons.

diff --git a/libstdc++-v3/include/std/stop_token 
b/libstdc++-v3/include/std/stop_token
index 58f72792b9e..e23d139e66c 100644
--- a/libstdc++-v3/include/std/stop_token
+++ b/libstdc++-v3/include/std/stop_token
@@ -87,16 +87,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 [[nodiscard]]
 friend bool
 operator==(const stop_token& __a, const stop_token& __b)
-{
-  return __a._M_state == __b._M_state;
-}
-
-[[nodiscard]]
-friend bool
-operator!=(const stop_token& __a, const stop_token& __b)
-{
-  return __a._M_state != __b._M_state;
-}
+{ return __a._M_state == __b._M_state; }
 
 friend void
 swap(stop_token& __lhs, stop_token& __rhs) noexcept
@@ -301,13 +292,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   return __a._M_state == __b._M_state;
 }
 
-[[nodiscard]]
-friend bool
-operator!=(const stop_source& __a, const stop_source& __b) noexcept
-{
-  return __a._M_state != __b._M_state;
-}
-
 friend void
 swap(stop_source& __lhs, stop_source& __rhs) noexcept
 {
diff --git a/libstdc++-v3/testsuite/30_threads/stop_token/stop_source.cc 
b/libstdc++-v3/testsuite/30_threads/stop_token/stop_source.cc
index 707c421ce32..9d15f0781ea 100644
--- a/libstdc++-v3/testsuite/30_threads/stop_token/stop_source.cc
+++ b/libstdc++-v3/testsuite/30_threads/stop_token/stop_source.cc
@@ -27,12 +27,18 @@ test01()
   std::stop_source ssrc;
   VERIFY( ssrc.stop_possible() );
   VERIFY( !ssrc.stop_requested() );
+  VERIFY( ssrc == ssrc );
+  VERIFY( !(ssrc != ssrc) );
 
   std::stop_source copy(ssrc);
   VERIFY( copy.stop_possible() );
   VERIFY( !copy.stop_requested() );
   VERIFY( ssrc.stop_possible() );
   VERIFY( !ssrc.stop_requested() );
+  VERIFY( copy == ssrc );
+  VERIFY( !(copy != ssrc) );
+  VERIFY( ssrc == ssrc );
+  VERIFY( !(ssrc != ssrc) );
 
   std::stop_source move(std::move(ssrc));
   VERIFY( move.stop_possible() );
@@ -41,6 +47,14 @@ test01()
   VERIFY( !copy.stop_requested() );
   VERIFY( !ssrc.stop_possible() );
   VERIFY( !ssrc.stop_requested() );
+  VERIFY( !(move == ssrc) );
+  VERIFY( move != ssrc );
+  VERIFY( ssrc == ssrc );
+  VERIFY( !(ssrc != ssrc) );
+  VERIFY( move == copy );
+  VERIFY( !(move != copy) );
+  VERIFY( !(copy == ssrc) );
+  VERIFY( copy != ssrc );
 }
 
 void
@@ -52,12 +66,18 @@ test02()
   std::stop_source ssrc(std::nostopstate);
   VERIFY( !ssrc.stop_possible() );
   VERIFY( !ssrc.stop_requested() );
+  VERIFY( ssrc == ssrc );
+  VERIFY( !(ssrc != ssrc) );
 
   std::stop_source copy(ssrc);
   VERIFY( !copy.stop_possible() );
   VERIFY( !copy.stop_requested() );
   VERIFY( !ssrc.stop_possible() );
   VERIFY( !ssrc.stop_requested() );
+  VERIFY( copy == ssrc );
+  VERIFY( !(copy != ssrc) );
+  VERIFY( ssrc == ssrc );
+  VERIFY( !(ssrc != ssrc) );
 
   std::stop_source move(std::move(ssrc));
   VERIFY( !move.stop_possible() );
@@ -66,24 +86,39 @@ test02()
   VERIFY( !copy.stop_requested() );
   VERIFY( !ssrc.stop_possible() );
   VERIFY( !ssrc.stop_requested() );
+  VERIFY( move == ssrc );
+  VERIFY( !(move != ssrc) );
+  VERIFY( ssrc == ssrc );
+  VERIFY( !(ssrc != ssrc) );
+  VERIFY( move == copy );
+  VERIFY( !(move != copy) );
+  VERIFY( copy == ssrc );
+  VERIFY( !(copy != ssrc) );
 }
 
 void
 test03()
 {
   std::stop_source s1;
+  std::stop_source copy(s1);
   s1.request_stop();
   std::stop_source s2(std::nostopstate);
+  VERIFY( s1 != s2 );
+
   s1.swap(s2);
   VERIFY( !s1.stop_possible() );
   VERIFY( !s1.stop_requested() );
   VERIFY( s2.stop_possible() );
   VERIFY( s2.stop_requested() );
+  VERIFY( s1 != s2 );
+  VERIFY( s2 == copy );
+
   swap(s1, s2);
   VERIFY( s1.stop_possible() );
   VERIFY( s1.stop_requested() );
   VERIFY( !s2.stop_possible() );
   VERIFY( !s2.stop_requested() );
+  VERIFY( s1 == copy );
 }
 
 int main()

Re: [PATCH] libstdc++: Define std::lexicographical_compare_three_way for C++20

[Jonathan Wakely]

On 03/01/20 15:03 +, Jonathan Wakely wrote:

On 03/01/20 14:54 +, Jonathan Wakely wrote:

On 29/12/19 12:07 +0100, Stephan Bergmann wrote:
FYI, the above fails with -std=c++2a and recent Clang trunk after  
"Mark the major papers for C++20 consistent comparisons as 'done', 
and start publishing the corresponding feature-test macro":  Clang 
now defines __cpp_impl_three_way_comparison (so 
libstdc++-v3/include/std/version defines 
__cpp_lib_three_way_comparison) but still doesn't define 
__cpp_lib_concepts, so libstdc++-v3/libsupc++/compare doesn't 
define compare_three_way.


I locally managed that for now with extending the surrounding

#if __cpp_lib_three_way_comparison

with

&& __cpp_lib_concepts


+}
+#endif // three_way_comparison


Should be fixed at r279861 on trunk (also attached). This leaves the
five-argument overload defined for Clang, just not the four-argument
one that uses std::compare_three_way.

We could define that overload unconditionally and do something like
this, but I prefer to just omit it rather than define it badly:

return std::lexicographical_compare_three_way(__first1, __last1,
__first2, __last2,
#if __cpp_lib_concepts
compare_three_way{}
#else
[](auto&& __l, auto&& __r)
{ return __l <=> __r; }
#endif // concepts
);


After writing that, I realised that a better approach might be:

--- a/libstdc++-v3/libsupc++/compare
+++ b/libstdc++-v3/libsupc++/compare
@@ -40,7 +40,9 @@

namespace std
{
-#define __cpp_lib_three_way_comparison 201711L
+#if __cpp_lib_concepts
+# define __cpp_lib_three_way_comparison 201711L
+#endif

  // [cmp.categories], comparison category types


i.e. don't pretend the library supports three-way comparison if that
support is incomplete. That will still fix the Clang problem because
if that macro isn't defined then we don't define either overload of
std::lexicographical_compare_three_way.

That seems cleaner to me. Anybody disagree?



I'm committing this patch to do that.

Tested powerpc64le-linux, committed to trunk.


commit 6eb2a600ef9623cf6fbf2584df44fc5d71fd16f5
Author: Jonathan Wakely 
Date:   Mon Jan 6 10:35:48 2020 +

libstdc++: Define __cpp_lib_three_way_comparison conditionally

The contents of the  header are not complete unless concepts
are supported, so the feature test macro should depend on the macro for
concepts.

As a result, the std::lexicographical_compare_three_way function will
not be defined unless concepts are supported, so there is no need to
check __cpp_lib_concepts before using concepts in those functions.

* include/bits/stl_algobase.h (__is_byte_iter, __min_cmp)
(lexicographical_compare_three_way): Do not depend on
__cpp_lib_concepts.
* include/std/version (__cpp_lib_three_way_comparison): Only define
when __cpp_lib_concepts is defined.
* libsupc++/compare (__cpp_lib_three_way_comparison): Likewise.

diff --git a/libstdc++-v3/include/bits/stl_algobase.h b/libstdc++-v3/include/bits/stl_algobase.h
index 76c323ab21b..dc922a0f3d2 100644
--- a/libstdc++-v3/include/bits/stl_algobase.h
+++ b/libstdc++-v3/include/bits/stl_algobase.h
@@ -1667,7 +1667,6 @@ _GLIBCXX_BEGIN_NAMESPACE_ALGO
 }
 
 #if __cpp_lib_three_way_comparison
-#if __cpp_lib_concepts
   // Iter points to a contiguous range of unsigned narrow character type
   // or std::byte, suitable for comparison by memcmp.
   template
@@ -1690,7 +1689,6 @@ _GLIBCXX_BEGIN_NAMESPACE_ALGO
 	return _Res{__y, __c};
   return _Res{__x, __c};
 }
-#endif
 
   /**
*  @brief Performs dictionary comparison on ranges.
@@ -1718,7 +1716,7 @@ _GLIBCXX_BEGIN_NAMESPACE_ALGO
   __glibcxx_requires_valid_range(__first1, __last1);
   __glibcxx_requires_valid_range(__first2, __last2);
 
-#if __cpp_lib_concepts && __cpp_lib_is_constant_evaluated
+#if __cpp_lib_is_constant_evaluated
   using _Cat = decltype(__comp(*__first1, *__first2));
   static_assert(same_as, _Cat>);
 
@@ -1739,7 +1737,7 @@ _GLIBCXX_BEGIN_NAMESPACE_ALGO
 		  }
 		return __lencmp;
 	  }
-#endif // concepts && is_constant_evaluated
+#endif // is_constant_evaluated
   while (__first1 != __last1 && __first2 != __last2)
 	{
 	  if (auto __cmp = __comp(*__first1, *__first2); __cmp != 0)
@@ -1751,7 +1749,6 @@ _GLIBCXX_BEGIN_NAMESPACE_ALGO
 	: __first2 != __last2 ? strong_ordering::less : strong_ordering::equal;
 }
 
-#if __cpp_lib_concepts
   template
 constexpr auto
 lexicographical_compare_three_way(_InputIter1 __first1,
@@ -1763,7 +1760,6 @@ _GLIBCXX_BEGIN_NAMESPACE_ALGO
 		__first2, __last2,
 		

Re: [PATCH] Make cgraph_edge::resolve_speculation static

[Jan Hubicka]

> Hi,
> 
> throughout this year a few of us got burnt by the fact that
> cgraph_edge::resolve_speculation method sometimes removed and
> deallocated its this pointer, sometimes making the this pointer of a few
> other methods of the class also suddenly invalid.
> 
> We postponed dealing with the issue because simply making these methods
> static would be a bit ugly and hoped that someone would come with
> something better.  Well, that did not happen and so the semi-mechanical
> patch below does exactly that and fixing a few (potential) problems I
> encountered: I made the iteration over edges in
> function_and_variable_visibility cope with such edge removal and fixed
> local variable hiding in cgraph_node::set_call_stmt_including_clones and
> cgraph_node::create_edge_including_clones.  I did not unify calls to
> resolve_speculation and make_direct in redirect_to_unreachable in this
> patch but I believe that is a logical follow-up.
> 
> The patch has passed bootstrap and LTO bootstrap and testing on an
> x86_64-linux.  What do you think?
It looks reasonable to me, but if we do not want member function to
deallocate THIS, then we probably want to make remove()
methods also static?

Honza

Re: [PATCH] Make cgraph_edge::resolve_speculation static

[Martin Liška]

On 1/4/20 7:23 PM, Martin Jambor wrote:

Hi,

throughout this year a few of us got burnt by the fact that
cgraph_edge::resolve_speculation method sometimes removed and
deallocated its this pointer, sometimes making the this pointer of a few
other methods of the class also suddenly invalid.


Hello.

Yes, I can confirm that I was victim at least once :)



We postponed dealing with the issue because simply making these methods
static would be a bit ugly and hoped that someone would come with
something better.  Well, that did not happen and so the semi-mechanical
patch below does exactly that and fixing a few (potential) problems I
encountered: I made the iteration over edges in
function_and_variable_visibility cope with such edge removal and fixed
local variable hiding in cgraph_node::set_call_stmt_including_clones and
cgraph_node::create_edge_including_clones.  I did not unify calls to
resolve_speculation and make_direct in redirect_to_unreachable in this
patch but I believe that is a logical follow-up.

The patch has passed bootstrap and LTO bootstrap and testing on an
x86_64-linux.  What do you think?


I've just read the patch and I see it as an improvement.

Thanks for it.
Martin



Thanks,

Martin

[PATCH] Document cloning for the target_clone attribute.

[Martin Liška]

Hi.

The patch is about explanation what happens when
a target_clone function calls a function without
the attribute.

Ready for trunk?
Thanks,
Martin

gcc/ChangeLog:

2020-01-06  Martin Liska  

PR ipa/83411
* doc/extend.texi: Explain cloning for target_clone
attribute.
---
 gcc/doc/extend.texi | 6 ++
 1 file changed, 6 insertions(+)


diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 05ec62c552b..184146abd10 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -3768,6 +3768,12 @@ the @code{ifunc} attribute above) that dynamically selects a clone
 suitable for current architecture.  The resolver is created only if there
 is a usage of a function with @code{target_clones} attribute.
 
+Note that any subsequent call of a function without @code{target_clone}
+from a @code{target_clone} caller will not lead to copying
+(target clone) of the called function.
+If you want to enforce such behaviour,
+we recommend to use @code{flatter} attribute for the caller function.
+
 @item unused
 @cindex @code{unused} function attribute
 This attribute, attached to a function, means that the function is meant

Re: [PATCH] Add changes that I made in GCC 10 development cycle.

[Martin Liška]

On 11/29/19 3:34 PM, Martin Liška wrote:

Hello.

I'm sending entries for changes.html file for GCC 10.

Martin

---
  htdocs/gcc-10/changes.html | 38 ++
  1 file changed, 38 insertions(+)




I've just installed the changes update.
Feel free to provide language corrections.

Martin

Re: [PATCH] Mark param_max_combine_insns with Optimization keyword.

[Martin Liška]

On 1/3/20 5:12 PM, Segher Boessenkool wrote:

Hi!

On Thu, Jan 02, 2020 at 12:07:27PM +0100, Martin Liška wrote:

The param is changed here:

   /* Restrict the amount of work combine does at -Og while retaining
  most of its useful transforms.  */
   if (opts->x_optimize_debug)
 SET_OPTION_IF_UNSET (opts, opts_set, param_max_combine_insns, 2);

and so that it should be per-function. The only usage is in combine RTL
pass, which is per-function optimization.

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

Ready to be installed?


Sure.  Okay for trunk.  Thanks!


Thank you.




2020-01-02  Martin Liska  

PR tree-optimization/92860
* params.opt: Mart param_max_combine_insns with Optimization
keyword.


s/mart/mark/


Will fix the typo.



(Btw, does this help -Og at all?  If so, shouldn't it be -O1 as well?)


I would say yes. The param default for -Og was added by Richi in 2014.
I'm adding him to CC.

Martin




Segher

[RFC/PATCH] IVOPTs select cand with preferred D-form access

[Kewen.Lin]

Hi all,

Recently I'm investigating on an issue related to use D-form/X-form vector
memory access, it's the same as what the patch
https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01879.html 
was intended to deal with.  Power9 introduces DQ-form instructions for vector
memory access, we perfer to use DQ-form when unrolling loop.  As the example
in the above link, it can save number of ADDI and GPR for indexing.

Or for below example:

extern void dummy (double, unsigned n);

void
func (double *x, double *y, unsigned m, unsigned n)
{
  double sacc;
  for (unsigned j = 1; j < m; j++)
  {
sacc = 0.0;
for (unsigned i = 1; i < n; i++)
  sacc = sacc + x[i] * y[i];
dummy (sacc, n);
  }
}

Core loop with X-form (lxvx):
/*
mtctr   r10
lxvxvs12,r31,r9
lxvxvs0,r30,r9
addir10,r9,16
addir9,r9,32
xvmaddadp vs32,vs12,vs0
lxvxvs12,r31,r10
lxvxvs0,r30,r10
xvmaddadp vs11,vs12,vs0
lxvxvs12,r31,r9
lxvxvs0,r30,r9
addir9,r10,32
xvmaddadp vs32,vs12,vs0
lxvxvs12,r31,r9
lxvxvs0,r30,r9
addir9,r10,48
xvmaddadp vs11,vs12,vs0
lxvxvs12,r31,r9
lxvxvs0,r30,r9
addir9,r10,64
xvmaddadp vs32,vs12,vs0
lxvxvs12,r31,r9
lxvxvs0,r30,r9
addir9,r10,80
xvmaddadp vs11,vs12,vs0
lxvxvs12,r31,r9
lxvxvs0,r30,r9
addir9,r10,96
xvmaddadp vs32,vs12,vs0
lxvxvs12,r31,r9
lxvxvs0,r30,r9
addir9,r10,112
xvmaddadp vs11,vs12,vs0
bdnz190 
*/

vs.
/*
Core loop with D-form (lxv)
mtctr   r8
lxv vs12,0(r9)
lxv vs0,0(r10)
addir7,r9,16  // r7, r8 can be eliminated further with r9, r10
addir8,r10,16 // 2 or 4 addi vs. 8 addi above
addir9,r9,128
addir10,r10,128  
xvmaddadp vs32,vs12,vs0
lxv vs12,-112(r9)
lxv vs0,-112(r10)
xvmaddadp vs11,vs12,vs0
lxv vs12,16(r7)
lxv vs0,16(r8)
xvmaddadp vs32,vs12,vs0
lxv vs12,32(r7)
lxv vs0,32(r8)
xvmaddadp vs11,vs12,vs0
lxv vs12,48(r7)
lxv vs0,48(r8)
xvmaddadp vs32,vs12,vs0
lxv vs12,64(r7)
lxv vs0,64(r8)
xvmaddadp vs11,vs12,vs0
lxv vs12,80(r7)
lxv vs0,80(r8)
xvmaddadp vs32,vs12,vs0
lxv vs12,96(r7)
lxv vs0,96(r8)
xvmaddadp vs11,vs12,vs0
bdnz1b0 
*/

We are thinking whether it can be handled in IVOPTs instead of one RTL pass.

During IVOPTs selecting IV cands, it doesn't know the loop will be unrolled so
it doesn't count the possible step cost in with X-form.  If we can teach it to
consider the case, the IV cands which plays with D-form can be preferred.
Currently unrolling (incomplete) happens in RTL, it looks we have to predict
the loop whether unroll in IVOPTs.  Since there is some parameter checks on RTL
insn counts and target hooks, it seems not easy to get that.  Besides, we need
to check the step is valid to put into D-form field (eg: DQ-form requires divide
16 exactly), to ensure no extra ADDIs needed.

I'm not sure whether it's a good idea to implement in IVOPTs, but I did some
changes in IVOPTs to prove it's doable to get expected codes, the patch is 
attached.

Any comments/suggestions are highly appreiciated!

BR,
Kewen
diff --git a/gcc/common.opt b/gcc/common.opt
index 404b6aa..0d3f8f8 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -1465,6 +1465,10 @@ ffinite-loops
 Common Report Var(flag_finite_loops) Optimization
 Assume that loops with an exit will terminate and not loop indefinitely.
 
+fivopts-dform
+Common Report Var(flag_ivopts_dform) Init(1) Optimization
+Assume D-form is preferred in IVOPTS like unrolling.
+
 ffixed-
 Common Joined RejectNegative Var(common_deferred_options) Defer
 -ffixed- Mark  as being unavailable to the compiler.
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 2995348..588feac 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -1654,6 +1654,9 @@ static const struct attribute_spec 
rs6000_attribute_table[] =
 #undef TARGET_PREDICT_DOLOOP_P
 #define TARGET_PREDICT_DOLOOP_P rs6000_predict_doloop_p
 
+#undef TARGET_D_FORM_SUITABLE_P
+#define TARGET_D_FORM_SUITABLE_P rs6000_d_form_suitable_p
+
 #undef TARGET_HAVE_COUNT_REG_DECR_P
 #define TARGET_HAVE_COUNT_REG_DECR_P true
 
@@ -26258,6 +26261,28 @@ rs6000_predict_doloop_p (struct loop *loop)
   return true;
 }
 
+static bool
+rs6000_d_form_suitable_p (machine_mode mode, signed HOST_WIDE_INT val,
+ bool is_sig, bool is_store)
+{
+  /* Only Power9 and above supports DQ 

[PATCH] Fix PowerPC -fstack-clash-protection -mprefixed-addr ICE (PR target/93122)

[Jakub Jelinek]

Hi!

As mentioned in the PR, the following testcase ICEs because rs, while valid
add_operand is not valid add_cint_operand and so gen_add3_insn fails,
because it doesn't meet the expander predicates.

Fixed thusly, bootstrapped/regtested on powerpc64{,le}-linux, ok for trunk?

Another option would be to:
1) always use gen_add3_insn, but if it returns NULL use the extra
emit_move_insn (end_addr, GEN_INT (-rounded_size));
and retry with end_addr instead of rs
2) if the first gen_add3_insn returned NULL or if it created more than one
instruction, add the REG_FRAME_RELATED_EXPR note on the last insn

Is that what you want to do instead?

2020-01-06  Jakub Jelinek  

PR target/93122
* config/rs6000/rs6000-logue.c
(rs6000_emit_probe_stack_range_stack_clash): Only use gen_addr3_insn
if add_cint_operand predicate matches.  Use rs instead of doing
GEN_INT again.

* gcc.target/powerpc/pr93122.c: New test.

--- gcc/config/rs6000/rs6000-logue.c.jj 2020-01-01 12:22:32.945491552 +0100
+++ gcc/config/rs6000/rs6000-logue.c2020-01-02 12:59:09.612734662 +0100
@@ -1605,11 +1605,11 @@ rs6000_emit_probe_stack_range_stack_clas
= copy_reg ? gen_rtx_REG (Pmode, 0) : gen_rtx_REG (Pmode, 12);
   rtx rs = GEN_INT (-rounded_size);
   rtx_insn *insn;
-  if (add_operand (rs, Pmode))
+  if (add_cint_operand (rs, Pmode) && add_operand (rs, Pmode))
insn = emit_insn (gen_add3_insn (end_addr, stack_pointer_rtx, rs));
   else
{
- emit_move_insn (end_addr, GEN_INT (-rounded_size));
+ emit_move_insn (end_addr, rs);
  insn = emit_insn (gen_add3_insn (end_addr, end_addr,
   stack_pointer_rtx));
  /* Describe the effect of INSN to the CFI engine.  */
--- gcc/testsuite/gcc.target/powerpc/pr93122.c.jj   2020-01-02 
13:07:07.022459554 +0100
+++ gcc/testsuite/gcc.target/powerpc/pr93122.c  2020-01-06 07:05:31.397917021 
+0100
@@ -0,0 +1,12 @@
+/* PR target/93122 */
+/* { dg-do compile { target lp64 } } */
+/* { dg-options "-fstack-clash-protection -mprefixed-addr -mfuture" } */
+
+void bar (char *);
+
+void
+foo (void)
+{
+  char s[4294967296];
+  bar (s);
+}

Jakub