[patch] Fix wrong code on dynamic array slices

[Eric Botcazou]

Hi,

the attached Ada testcase fails on x86/Linux (32-bit only) because the FRE
pass wrongly deletes stores as redundant:

Deleted redundant store VIEW_CONVERT_EXPR(*a.18_41)[0]
{lb: 4294967292 sz: 4} = 100;
Deleted redundant store VIEW_CONVERT_EXPR(*a.18_41)[1]
{lb: 4294967292 sz: 4} = 1;
Deleted redundant store VIEW_CONVERT_EXPR(*a.18_41)[2]
{lb: 4294967292 sz: 4} = 2;
Deleted redundant store VIEW_CONVERT_EXPR(*a.18_41)[3]
{lb: 4294967292 sz: 4} = 3;
Deleted redundant store VIEW_CONVERT_EXPR(*a.18_41)[4]
{lb: 4294967292 sz: 4} = 4;

While the last 4 stores happen to be redundant (however the compiler cannot
really determine it), the first one isn't and deleting it yields wrong code.

These stores are part of a larger group of stores:

VIEW_CONVERT_EXPR(*a.18_41)[4294967292]{lb: 4294967292 
sz: 4} = -4;
VIEW_CONVERT_EXPR(*a.18_41)[4294967293]{lb: 4294967292 
sz: 4} = -3;
VIEW_CONVERT_EXPR(*a.18_41)[4294967294]{lb: 4294967292 
sz: 4} = -2;
VIEW_CONVERT_EXPR(*a.18_41)[4294967295]{lb: 4294967292 
sz: 4} = -1;
VIEW_CONVERT_EXPR(*a.18_41)[0]{lb: 4294967292 sz: 4} = 
100;
VIEW_CONVERT_EXPR(*a.18_41)[1]{lb: 4294967292 sz: 4} = 
1;
VIEW_CONVERT_EXPR(*a.18_41)[2]{lb: 4294967292 sz: 4} = 
2;
VIEW_CONVERT_EXPR(*a.18_41)[3]{lb: 4294967292 sz: 4} = 
3;
VIEW_CONVERT_EXPR(*a.18_41)[4]{lb: 4294967292 sz: 4} = 
4;

and the first 4 ones are correctly detected as *not* redundant.  What changes 
between the two groups of stores is the index or, more precisely, the sign of
the difference between the index and the low bound (4294967292 aka -4); it's
positive for the first group and negative for the second group.  The latter
case fools ao_ref_init_from_vn_reference because it doesn't properly truncate
it to the precision of the index, like for example get_ref_base_and_extent,
so as to make it positive again in this case, which in turn fools FRE.

So the attached patch offset_int'ifies ao_ref_init_from_vn_reference the same
way get_ref_base_and_extent was offset_int'ified (in fact double_int'ified at 
the time), adding the missing truncation in the process.

Bootstrapped/regtested on x86_64-suse-linux, OK for the mainline?


2015-09-16  Eric Botcazou  

* tree-ssa-sccvn.c (ao_ref_init_from_vn_reference): Use offset_int for
offset and size computations instead of HOST_WIDE_INT.


2015-09-16  Eric Botcazou  

* gnat.dg/opt49.adb: New test.

-- 
Eric BotcazouIndex: tree-ssa-sccvn.c
===
--- tree-ssa-sccvn.c	(revision 227805)
+++ tree-ssa-sccvn.c	(working copy)
@@ -953,9 +953,9 @@ ao_ref_init_from_vn_reference (ao_ref *r
   unsigned i;
   tree base = NULL_TREE;
   tree *op0_p = &base;
-  HOST_WIDE_INT offset = 0;
-  HOST_WIDE_INT max_size;
-  HOST_WIDE_INT size = -1;
+  offset_int offset = 0;
+  offset_int max_size;
+  offset_int size = -1;
   tree size_tree = NULL_TREE;
   alias_set_type base_alias_set = -1;
 
@@ -971,15 +971,11 @@ ao_ref_init_from_vn_reference (ao_ref *r
   if (mode == BLKmode)
 	size_tree = TYPE_SIZE (type);
   else
-size = GET_MODE_BITSIZE (mode);
-}
-  if (size_tree != NULL_TREE)
-{
-  if (!tree_fits_uhwi_p (size_tree))
-	size = -1;
-  else
-	size = tree_to_uhwi (size_tree);
+	size = int (GET_MODE_BITSIZE (mode));
 }
+  if (size_tree != NULL_TREE
+  && TREE_CODE (size_tree) == INTEGER_CST)
+size = wi::to_offset (size_tree);
 
   /* Initially, maxsize is the same as the accessed element size.
  In the following it will only grow (or become -1).  */
@@ -1034,7 +1030,7 @@ ao_ref_init_from_vn_reference (ao_ref *r
 
 	/* And now the usual component-reference style ops.  */
 	case BIT_FIELD_REF:
-	  offset += tree_to_shwi (op->op1);
+	  offset += wi::to_offset (op->op1);
 	  break;
 
 	case COMPONENT_REF:
@@ -1043,15 +1039,16 @@ ao_ref_init_from_vn_reference (ao_ref *r
 	/* We do not have a complete COMPONENT_REF tree here so we
 	   cannot use component_ref_field_offset.  Do the interesting
 	   parts manually.  */
+	tree this_offset = DECL_FIELD_OFFSET (field);
 
-	if (op->op1
-		|| !tree_fits_uhwi_p (DECL_FIELD_OFFSET (field)))
+	if (op->op1 || TREE_CODE (this_offset) != INTEGER_CST)
 	  max_size = -1;
 	else
 	  {
-		offset += (tree_to_uhwi (DECL_FIELD_OFFSET (field))
-			   * BITS_PER_UNIT);
-		offset += TREE_INT_CST_LOW (DECL_FIELD_BIT_OFFSET (field));
+		offset_int woffset = wi::lshift (wi::to_offset (this_offset),
+		 LOG2_BITS_PER_UNIT);
+		woffset += wi::to_offset (DECL_FIELD_BIT_OFFSET (field));
+		offset += woffset;
 	  }
 	break;
 	  }
@@ -1059,17 +1056,18 @@ ao_ref_init_from_vn_reference (ao_ref *r
 	case ARRAY_RANGE_REF:
 	case ARRAY_REF:
 	  /* We recorded the lower bound and the element size.  */
-	  if (!tree_fits_shwi_p (op->op0)
-	  || !tree_fits_shwi_p (op->op1)
-	  || !tree_fits_shwi_p (op->op2))
+	  if (TREE_CODE (op->op0) != INTEGER_CST
+	  || TREE_CODE (op->op1) != INTEGER_CST
+	  || TREE_CODE (op

[PATCH] Fix PR67442

[Richard Biener]

This fixes PR67442, wide_int_to_tree used for type extension from
a different signed value (which doesn't work).

Bootstrapped and tested on x86_64-unknown-linux-gnu, applied on trunk.

Richard.

2015-09-16  Richard Biener  

PR middle-end/67442
* fold-const.c (extract_muldiv_1): Properly extend multiplication
result before builting a tree via wide_int_to_tree.

* gcc.dg/torture/pr67442.c: New testcase.

Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 227779)
+++ gcc/fold-const.c(working copy)
@@ -6166,8 +6173,12 @@ extract_muldiv_1 (tree t, tree c, enum t
  && ((sign == UNSIGNED && tcode != MULT_EXPR) || sign == SIGNED))
overflow_p = true;
  if (!overflow_p)
-   return fold_build2 (tcode, ctype, fold_convert (ctype, op0),
-   wide_int_to_tree (ctype, mul));
+   {
+ mul = wide_int::from (mul, TYPE_PRECISION (ctype),
+   TYPE_SIGN (TREE_TYPE (op1)));
+ return fold_build2 (tcode, ctype, fold_convert (ctype, op0),
+ wide_int_to_tree (ctype, mul));
+   }
}
 
   /* If these operations "cancel" each other, we have the main
Index: gcc/testsuite/gcc.dg/torture/pr67442.c
===
--- gcc/testsuite/gcc.dg/torture/pr67442.c  (revision 0)
+++ gcc/testsuite/gcc.dg/torture/pr67442.c  (working copy)
@@ -0,0 +1,12 @@
+/* { dg-do run } */
+
+short foo[100];
+
+int main()
+{
+  short* bar = &foo[50];
+  short i = 1;
+  short j = 1;
+  short value = bar[8 - i * 2 * j];
+  return value;
+}

Re: dejagnu version update?

[Andreas Schwab]

Mike Stump  writes:

> The software presently works with 1.4.4 and there aren’t any changes
> that require anything newer.

SLES 12 has 1.4.4.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

[AArch64] Implement copysign[ds]f3

[James Greenhalgh]

Hi,

This patch adds expanders for copysigndf3 and copysignsf3 to the AArch64
backend. These use the BSL/BIT/BIF insn to save us from the default
expansion pattern.

Bootstrapped on aarch64-none-linux-gnu with no issues, and checked
the performance to show a slight improvement to FP routines using
copysign or SIGN from fortran.

OK?

Thanks,
James

---
gcc/

2015-09-16  James Greenhalgh  

* config/aarch64/aarch64.md (copysigndf3): New.
(copysignsf3): Likewise.

gcc/testsuite/

2015-09-16  James Greenhalgh  

* gcc.target/aarch64/copysign_1.c: New.
* gcc.target/aarch64/copysign_2.c: New.

diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 88ba72e..925c6b1 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -4412,6 +4412,52 @@
   [(set_attr "type" "f_minmax")]
 )
 
+;; For copysign (x, y), we want to generate:
+;;
+;;   LDR d2, #(1 << 63)
+;;   BSL v2.8b, [y], [x]
+;;
+;; or another, equivalent, sequence using one of BSL/BIT/BIF.
+;; aarch64_simd_bsldf will select the best suited of these instructions
+;; to generate based on register allocation, and knows how to partially
+;; constant fold based on the values of X and Y, so expand through that.
+
+(define_expand "copysigndf3"
+  [(match_operand:DF 0 "register_operand")
+   (match_operand:DF 1 "register_operand")
+   (match_operand:DF 2 "register_operand")]
+  "TARGET_FLOAT && TARGET_SIMD"
+{
+  rtx mask = gen_reg_rtx (DImode);
+  emit_move_insn (mask, GEN_INT (HOST_WIDE_INT_1U << 63));
+  emit_insn (gen_aarch64_simd_bsldf (operands[0], mask,
+ operands[2], operands[1]));
+  DONE;
+}
+)
+
+;; As above, but we must first get to a 64-bit value if we wish to use
+;; aarch64_simd_bslv2sf.
+
+(define_expand "copysignsf3"
+  [(match_operand:SF 0 "register_operand")
+   (match_operand:SF 1 "register_operand")
+   (match_operand:SF 2 "register_operand")]
+  "TARGET_FLOAT && TARGET_SIMD"
+{
+  rtx mask = gen_reg_rtx (DImode);
+
+  /* Juggle modes to get us in to a vector mode for BSL.  */
+  rtx op1 = lowpart_subreg (V2SFmode, operands[1], SFmode);
+  rtx op2 = lowpart_subreg (V2SFmode, operands[2], SFmode);
+  rtx tmp = gen_reg_rtx (V2SFmode);
+  emit_move_insn (mask, GEN_INT (HOST_WIDE_INT_1U << 31));
+  emit_insn (gen_aarch64_simd_bslv2sf (tmp, mask, op2, op1));
+  emit_move_insn (operands[0], lowpart_subreg (SFmode, tmp, V2SFmode));
+  DONE;
+}
+)
+
 ;; ---
 ;; Reload support
 ;; ---
diff --git a/gcc/testsuite/gcc.target/aarch64/copysign_1.c b/gcc/testsuite/gcc.target/aarch64/copysign_1.c
new file mode 100644
index 000..27fb9ca
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/copysign_1.c
@@ -0,0 +1,81 @@
+/* { dg-do run } */
+/* { dg-options "-O2 --save-temps" } */
+
+double fabs (double);
+
+double
+check (double x, double y)
+{
+  return __builtin_copysign (x, y);
+}
+
+double
+check1 (double x)
+{
+  return __builtin_copysign (x, 1.0);
+}
+
+double
+check2 (double x)
+{
+  return __builtin_copysign (1.0, x);
+}
+
+double
+check3 (double x)
+{
+  return -__builtin_copysign (x, 1.0);
+}
+
+double
+check4 (double x, double y)
+{
+  return x * __builtin_copysign (x, y);
+}
+
+double
+check5 (double x, double y)
+{
+  return __builtin_copysign (-x, -y);
+}
+
+int
+main (int argc, char** argv)
+{
+  double x = 2.0;
+  double y = -5.0;
+  double epsilon = 0.1;
+
+  double expected = -2.0;
+
+  if (fabs (check (x, y) - expected) >= epsilon)
+__builtin_abort ();
+
+  expected = 2.0;
+
+  if (fabs (check1 (x) - expected) >= epsilon)
+__builtin_abort ();
+
+  expected = 1.0;
+
+  if (fabs (check2 (x) - expected) >= epsilon)
+__builtin_abort ();
+
+  expected = -2.0;
+
+  if (fabs (check3 (x) - expected) >= epsilon)
+__builtin_abort ();
+
+  expected = -4.0;
+
+  if (fabs (check4 (x, y) - expected) >= epsilon)
+__builtin_abort ();
+
+  expected = 2.0;
+
+  if (fabs (check5 (x, y) - expected) >= epsilon)
+__builtin_abort ();
+}
+
+/* { dg-final { scan-assembler-not "copysign\tw" } } */
+
diff --git a/gcc/testsuite/gcc.target/aarch64/copysign_2.c b/gcc/testsuite/gcc.target/aarch64/copysign_2.c
new file mode 100644
index 000..6eaa704
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/copysign_2.c
@@ -0,0 +1,81 @@
+/* { dg-do run } */
+/* { dg-options "-O2 --save-temps" } */
+
+float fabsf (float);
+
+float
+check (float x, float y)
+{
+  return __builtin_copysignf (x, y);
+}
+
+float
+check1 (float x)
+{
+  return __builtin_copysignf (x, 1.0);
+}
+
+float
+check2 (float x)
+{
+  return __builtin_copysignf (1.0, x);
+}
+
+float
+check3 (float x)
+{
+  return -__builtin_copysignf (x, 1.0);
+}
+
+float
+check4 (float x, float y)
+{
+  return x * __builtin_copysignf (x, y);
+}
+
+float
+check5 (float x, float y)
+{
+  return __builtin_copysignf (-x, -y);
+}
+
+int
+main (int argc, char** argv)
+{
+  float x = 2

Re: [PATCH][C++] Avoid PCH dependent mangling

[Richard Biener]

On Tue, 15 Sep 2015, Richard Biener wrote:

> On September 15, 2015 4:25:37 PM GMT+02:00, Jason Merrill  
> wrote:
> >On 08/27/2015 09:36 AM, Richard Biener wrote:
> >>
> >> With the passes.c hunk in the patch below we FAIL assembly comparison
> >> of g++.dg/pch/system-[12].C because with PCH we have computed
> >> DECL_ASSEMBLER_NAME and thus appended DW_AT_linkage_name early during
> >> PCH generation while without PCH we compute it lazily and end up
> >> appending DW_AT_specification earlier.  Thus we have swapped dwarf
> >> attribute order and assembly comparison fails.
> >>
> >> Clearly this kind of "IL" changes dependent on whether we are writing
> >> a PCH file is going to cause differences down the food chain.
> >> (there is another case in instantiate_decl calling
> >add_pending_template
> >> dependent on pch_file)
> >>
> >> Now a simple solution is to simply not do that (mangle decls). 
> >Another
> >> would be to always mangle decls where we now do so conditional on
> >PCH.
> >> Another soulution is to declare we don't care about assembly
> >differences
> >> with/without using PCH and remove assembly comparison from the
> >> testsuite harness.
> >
> >Hmm, what if we walk through the symtab and mangle everything later, 
> >when we're about to write the PCH?  That should still get the benefit
> >of 
> >doing the mangling work only once, without changing the order of the 
> >attributes.
> 
> That might work if we can get at all relevant decls that way.  If not we 
> can populate a pointer-set from the function and walk that before 
> writing the PCH. I can do that if you prefer, I just didn't know if we 
> care about PCH performance enough to worry.

Ok, so the following fixes my pch.exp issues.  It drops note_decl_for_pch
in favor of mangling all globals before PCH write.

Bootstrap & regtest on x86_64-unknown-linux-gnu in progress, ok for trunk?

Thanks,
Richard.

2015-09-16  Richard Biener  

cp/
* cp-tree.h (note_decl_for_pch): Remove.
* class.c (build_clone): Do not call note_decl_for_pch.
* semantics.c (finish_member_declaration): Likewise.
(note_decl_for_pch): Remove.
* decl2.c (c_parse_final_cleanups): Mangle all globals before
writing the PCH.

Index: gcc/cp/class.c
===
*** gcc/cp/class.c  (revision 227779)
--- gcc/cp/class.c  (working copy)
*** build_clone (tree fn, tree name)
*** 4691,4699 
SET_DECL_RTL (clone, NULL);
rest_of_decl_compilation (clone, /*top_level=*/1, at_eof);
  
-   if (pch_file)
- note_decl_for_pch (clone);
- 
return clone;
  }
  
--- 4691,4696 
Index: gcc/cp/semantics.c
===
*** gcc/cp/semantics.c  (revision 227779)
--- gcc/cp/semantics.c  (working copy)
*** finish_member_declaration (tree decl)
*** 2951,2976 
maybe_add_class_template_decl_list (current_class_type, decl,
  /*friend_p=*/0);
  }
- 
-   if (pch_file)
- note_decl_for_pch (decl);
- }
- 
- /* DECL has been declared while we are building a PCH file.  Perform
-actions that we might normally undertake lazily, but which can be
-performed now so that they do not have to be performed in
-translation units which include the PCH file.  */
- 
- void
- note_decl_for_pch (tree decl)
- {
-   gcc_assert (pch_file);
- 
-   /* There's a good chance that we'll have to mangle names at some
-  point, even if only for emission in debugging information.  */
-   if (VAR_OR_FUNCTION_DECL_P (decl)
-   && !processing_template_decl)
- mangle_decl (decl);
  }
  
  /* Finish processing a complete template declaration.  The PARMS are
--- 2951,2956 
Index: gcc/cp/decl2.c
===
*** gcc/cp/decl2.c  (revision 227779)
--- gcc/cp/decl2.c  (working copy)
*** c_parse_final_cleanups (void)
*** 4511,4516 
--- 4511,4522 
   In that case we do not want to do anything else.  */
if (pch_file)
  {
+   /* Mangle all symbols at PCH creation time.  */
+   symtab_node *node;
+   FOR_EACH_SYMBOL (node)
+   if (! is_a  (node)
+   || ! DECL_HARD_REGISTER (node->decl))
+ DECL_ASSEMBLER_NAME (node->decl);
c_common_write_pch ();
dump_tu ();
return;
Index: gcc/cp/cp-tree.h
===
*** gcc/cp/cp-tree.h(revision 227779)
--- gcc/cp/cp-tree.h(working copy)
*** extern tree finish_qualified_id_expr(t
*** 6253,6259 
 bool, bool, tsubst_flags_t);
  extern void simplify_aggr_init_expr   (tree *);
  extern void finalize_nrv  (tree *, tree, tree);
- extern void note_decl_for_pch (tree);
  extern tree omp_reductio

[PATCH] Refactor dwarf2out_late_global_decl

[Richard Biener]

This makes dwarf2out_late_global_decl only do late work, namely add
location/value attributes.  For current LTO we need to make it do
early_global_decl as well (with LTO early debug this will be
conditionalized on !flag_lto_early_debug).

Bootstrapped and tested on x86_64-unknown-linux-gnu and verified
there are no regressions with the gdb testsuite.

This depends on the C++ PCH mangling patch.

If there are no further comments (and the mangling patch is approved) then
I plan to commit it.  I am working on a similar patch for
dwarf2out_function_decl right now.

(just noticed we have a 2nd dwarf maintainer, CCed now)

Richard.

2015-09-16  Richard Biener  

* passes.c (rest_of_decl_compilation): Always call early_global_decl
debug hook when we created a varpool node.
* dwarf2out.c (dwarf2out_late_global_decl): When in LTO call
dwarf2out_early_global_decl, when not just add location or
value attributes to existing DIEs.

Index: gcc/passes.c
===
--- gcc/passes.c(revision 227779)
+++ gcc/passes.c(working copy)
@@ -318,7 +318,17 @@ rest_of_decl_compilation (tree decl,
   && !decl_function_context (decl)
   && !current_function_decl
   && DECL_SOURCE_LOCATION (decl) != BUILTINS_LOCATION
-  && !decl_type_context (decl)
+  && (!decl_type_context (decl)
+ /* If we created a varpool node for the decl make sure to
+call early_global_decl.  Otherwise we miss changes
+introduced by member definitions like
+   struct A { static int staticdatamember; };
+   int A::staticdatamember;
+and thus have incomplete early debug and late debug
+called from varpool node removal fails to handle it
+properly.  */
+ || (TREE_CODE (decl) == VAR_DECL
+ && TREE_STATIC (decl) && !DECL_EXTERNAL (decl)))
   /* Avoid confusing the debug information machinery when there are
 errors.  */
   && !seen_error ())
Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 227779)
+++ gcc/dwarf2out.c (working copy)
@@ -21626,14 +21626,20 @@ dwarf2out_early_global_decl (tree decl)
 static void
 dwarf2out_late_global_decl (tree decl)
 {
-  /* Output any global decls we missed or fill-in any location
- information we were unable to determine on the first pass.
-
- Skip over functions because they were handled by the
- debug_hooks->function_decl() call in rest_of_handle_final.  */
-  if ((TREE_CODE (decl) != FUNCTION_DECL || !DECL_INITIAL (decl))
+  /* We have to generate early debug late for LTO.  */
+  if (in_lto_p)
+dwarf2out_early_global_decl (decl);
+
+/* Fill-in any location information we were unable to determine
+   on the first pass.  */
+  if (TREE_CODE (decl) == VAR_DECL
   && !POINTER_BOUNDS_P (decl))
-dwarf2out_decl (decl);
+{
+  dw_die_ref die = lookup_decl_die (decl);
+  if (die)
+   add_location_or_const_value_attribute (die, decl, false,
+  DW_AT_location);
+}
 }
 
 /* Output debug information for type decl DECL.  Called from toplev.c

Re: [PATCH] shrink-wrap: Fix up partitions (PR67587)

[Bernd Schmidt]

On 09/16/2015 02:17 AM, Segher Boessenkool wrote:

With the new shrink-wrap algorithm, blocks reachable both with and
without prologue are duplicated, and their incoming edges are then
distributed accordingly.  So we need to call fixup_partitions.

Is this okay for trunk?


I think so, given that pass_duplicate_computed_gotos uses the same method.


Bernd

Re: [patch match.pd c c++]: Ignore results of 'shorten_compare' and move missing patterns in match.pd

[Richard Biener]

On Tue, Sep 15, 2015 at 2:54 PM, Kai Tietz  wrote:
> Hi Richi,
>
> thanks for the review.
>
> 2015-09-15 12:06 GMT+02:00 Richard Biener :
>> On Tue, Sep 8, 2015 at 1:17 PM, Kai Tietz  wrote:
>>> Hi,
>>>
>>> This patch is the first part of obsoleting 'shorten_compare' function
>>> for folding.
>>> It adjusts the uses of 'shorten_compare' to ignore folding returned by
>>> it, and adds
>>> missing pattterns to match.pd to allow full bootstrap of C/C++ without
>>> regressions.
>>> Due we are using 'shorten_compare' for some diagnostic we can't simply
>>> remove it.  So if this patch gets approved, the next step will be to
>>> rename the function to something like 'check_compare', and adjust its
>>> arguments and inner logic to reflect that we don't modify
>>> arguments/expression anymore within that function.
>>>
>>> Bootstrap just show 2 regressions within gcc.dg testsuite due patterns
>>> matched are folded more early by forward-propagation.  I adjusted
>>> them, and added them to patch, too.
>>
>> Some comments on the patterns you added below
>>
>>> I did regression-testing for x86_64-unknown-linux-gnu.
>>>
>>> ChangeLog
>>>
>>> 2015-09-08  Kai Tietz  
>>>
>>> * match.pd: Add missing patterns from shorten_compare.
>>> * c/c-typeck.c (build_binary_op): Discard foldings of shorten_compare.
>>> * cp/typeck.c (cp_build_binary_op): Likewise.
>>>
>>> 2015-09-08  Kai Tietz  
>>>
>>> * gcc.dg/tree-ssa/vrp23.c: Adjust testcase to reflect that
>>> pattern is matching now already within forward-propagation pass.
>>> * gcc.dg/tree-ssa/vrp24.c: Likewise.
>>>
>>> Index: match.pd
>>> ===
>>> --- match.pd(Revision 227528)
>>> +++ match.pd(Arbeitskopie)
>>> @@ -1786,6 +1786,45 @@ along with GCC; see the file COPYING3.  If not see
>>>(op (abs @0) zerop@1)
>>>(op @0 @1)))
>>>
>>> +/* Simplify '((type) X) cmp ((type) Y' to shortest possible types, of X 
>>> and Y,
>>> +   if type's precision is wider then precision of X's and Y's type.
>>> +   Logic taken from shorten_compare function.  */
>>> +(for op (tcc_comparison)
>>> +  (simplify
>>> +(op (convert@0 @1) (convert@3 @2))
>>> +(if ((TREE_CODE (TREE_TYPE (@1)) == REAL_TYPE)
>>> + == (TREE_CODE (TREE_TYPE (@2)) == REAL_TYPE)
>>> + && (TREE_CODE (TREE_TYPE (@1)) == REAL_TYPE)
>>> +== (TREE_CODE (TREE_TYPE (@0)) == REAL_TYPE)
>>
>> I think these are always true, to/from REAL_TYPE is FIX_TRUNC /
>> FLOAT_EXPR.  What you
>> might get is conversion to/from decimal FP from/to non-decimal FP.
>
> Right, I just wanted to handle patterns of shorten_compare here.  I
> agree that - with small adjustments - we can use same logic for
> FIX_TRUNC and FLOAT_EXPR, too.

I was saying the test is useless, not that you should handle
FIX_TRUNC/FLOAT_EXPR.

>>> + && single_use (@1)
>>> + && single_use (@3)
>>
>> We have :s now, I'd like to see comments before any explicit
>> single_use () uses as to why
>> they were added.  Also why @1 and @3?  Either @0 and @3 or @1 and @2?
>
> Thanks for pointing me to :s.  I removedfrom updated patch the @3.
> Reason for introducing it was just for checking if expression has
> single-use, as otherwise we don't want to split expression by this
> transformation.
>
>>> + && TYPE_UNSIGNED (TREE_TYPE (@1)) == TYPE_UNSIGNED (TREE_TYPE 
>>> (@2))
>>> + && !((TREE_CODE (TREE_TYPE (@1)) == REAL_TYPE
>>> +   && DECIMAL_FLOAT_MODE_P (TYPE_MODE (TREE_TYPE (@1
>>> +  || (TREE_CODE (TREE_TYPE (@2)) == REAL_TYPE
>>> +  && DECIMAL_FLOAT_MODE_P (TYPE_MODE (TREE_TYPE (@2)
>>
>> We have DECIMAL_FLOAT_TYPE_P () for this.
>
> DECIMAL_FLOAT_TYPE seems to check for wide kind of patterns AFAICS.
> It uses internall SCALAR_FLOAT_TYPE_P,
> which also checks for COMPLEX_TYPE, not just for REAL_TYPE.  I  code
> in shorten_compare, which rejects DECIMAL_FLOAT_MODE_P just for
> REAL_TYPEs.
>
> But well, not sure if this is a latent bug in shorten_compare ...  so
> I replaced code using DECIMAL_FLOAT_TYPE instead.

I'd say it's a latent bug in shorten_compare.

>>> + && TYPE_PRECISION (TREE_TYPE (@1)) < TYPE_PRECISION (TREE_TYPE 
>>> (@0))
>>> + && TYPE_PRECISION (TREE_TYPE (@2)) < TYPE_PRECISION (TREE_TYPE 
>>> (@0))
>>
>> copy-paste error, @3 (ok, it shouldn't really matter as @0 and @3
>> should be the same types).
>
> Hmm, no pasto.  Initially (as told above) I didn't used @3 as it seems
> to be pretty superflous here.
> You are right that it doesn't matter as convert@0 and convert@3 should
> be always the same type.
>
>>> + )
>>
>> Closing parens always go to the previous line everywhere else.
>
> Ok. It just looks to me less good readable without skilled editor
>
>>> +   (with {
>>> + tree comtype = TYPE_PRECISION (TREE_TYPE (@1))
>>> + < TYPE_PRECISION (TREE_TYPE (@2)) ? TREE_TYPE (@2)
>>> +  

Re: [PATCH WIP] Use Levenshtein distance for various misspellings in C frontend v2

[Richard Biener]

On Tue, Sep 15, 2015 at 5:38 PM, David Malcolm  wrote:
> Updated patch attached, which is now independent of the rest of the
> patch kit; see below.  Various other comments inline.
>
> On Fri, 2015-09-11 at 17:30 +0200, Manuel López-Ibáñez wrote:
> On 10/09/15 22:28, David Malcolm wrote:
>> > There are a couple of FIXMEs here:
>> > * where to call levenshtein_distance_unit_tests
>>
>> Should this be part of make check? Perhaps a small program that is compiled 
>> and
>> linked with spellcheck.c? This would be possible if spellcheck.c did not 
>> depend
>> on tree.h or tm.h, which I doubt it needs to.
>
> Ideally I'd like to put them into a unittest plugin I've been working on:
>  https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00765.html
> In the meantime, they only get run in an ENABLE_CHECKING build.
>
>> > * should we attempt error-recovery in c-typeck.c:build_component_ref
>>
>> I would say yes, but why not leave this discussion to a later patch? The
>> current one seems useful enough.
>
> (nods)
>
>> > +
>> > +/* Look for the closest match for NAME within the currently valid
>> > +   scopes.
>> > +
>> > +   This finds the identifier with the lowest Levenshtein distance to
>> > +   NAME.  If there are multiple candidates with equal minimal distance,
>> > +   the first one found is returned.  Scopes are searched from innermost
>> > +   outwards, and within a scope in reverse order of declaration, thus
>> > +   benefiting candidates "near" to the current scope.  */
>> > +
>> > +tree
>> > +lookup_name_fuzzy (tree name)
>> > +{
>> > +  gcc_assert (TREE_CODE (name) == IDENTIFIER_NODE);
>> > +
>> > +  c_binding *best_binding = NULL;
>> > +  int best_distance = INT_MAX;
>> > +
>> > +  for (c_scope *scope = current_scope; scope; scope = scope->outer)
>> > +for (c_binding *binding = scope->bindings; binding; binding = 
>> > binding->prev)
>> > +  {
>> > +   if (!binding->id)
>> > + continue;
>> > +   int dist = levenshtein_distance (name, binding->id);
>> > +   if (dist < best_distance)

Btw, this looks quite expensive - I'm sure we want to limit the effort
here a bit.
Also not allowing arbitrary "best" distances and not do this for very simple
identifiers such as 'i'.  Say,

foo()
{
  int i;
  for (i =0; i<10; ++i)
   for (j = 0; j < 12; ++j)
;
}

I don't want us to suggest using 'i' instead of j (a good hint is that
I used 'j'
multiple times).

So while the idea might be an improvement to selected cases it can cause
confusion as well.  And if using the suggestion for further parsing it can
cause worse followup errors (unless we can limit such "fixup" use to the
cases where we can parse the result without errors).  Consider

foo()
{
  foz = 1;
}

if we suggest 'foo' instead of foz then we'll get a more confusing followup
error if we actually use it.

But maybe you already handle all these cases (didn't look at the patch,
just saw the above expensive loop plus dropped some obvious concerns).

Richard.

>> I guess 'dist' cannot be negative. Can it be zero? If not, wouldn't be
>> appropriate to exit as soon as it becomes 1?
>
> It can't be negative, so I've converted it to unsigned int, and introduced an
> "edit_distance_t" typedef for it.
>
> It would be appropriate to exit as soon as we reach 1 if we agree
> that lookup_name_fuzzy isn't intended to find exact matches (since
> otherwise we might fail to return an exact match if we see a
> distance 1 match first).
>
> I haven't implemented that early bailout in this iteration of the
> patch; should I?
>
>> Is this code discriminating between types and names? That is, what happens 
>> for:
>>
>> typedef int ins;
>>
>> int foo(void)
>> {
>> int inr;
>> inp x;
>> }
>
> Thanks.  I've fixed that.
>
>> > +/* Recursively append candidate IDENTIFIER_NODEs to CANDIDATES.  */
>> > +
>> > +static void
>> > +lookup_field_fuzzy_find_candidates (tree type, tree component,
>> > +   vec *candidates)
>> > +{
>> > +  tree field;
>> > +  for (field = TYPE_FIELDS (type); field; field = DECL_CHAIN (field))
>> > +{
>> > +  if (DECL_NAME (field) == NULL_TREE
>> > + && (TREE_CODE (TREE_TYPE (field)) == RECORD_TYPE
>> > + || TREE_CODE (TREE_TYPE (field)) == UNION_TYPE))
>> > +   {
>> > + lookup_field_fuzzy_find_candidates (TREE_TYPE (field),
>> > + component,
>> > + candidates);
>> > +   }
>> > +
>> > +  if (DECL_NAME (field))
>> > +   candidates->safe_push (field);
>> > +}
>> > +}
>>
>> This is appending inner-most, isn't it? Thus, given:
>
> Yes.
>
>> struct s{
>>  struct j { int aa; } kk;
>>  int aa;
>> };
>>
>> void foo(struct s x)
>> {
>>  x.ab;
>> }
>>
>> it will find s::j::aa before s::aa, no?
>
> AIUI, it doesn't look inside the "kk", only for anonymous structs.
>
> I added a test for this.
>
>> >   tree
>> > -build_component_ref (location_t loc, tree datum, tree component)
>> > +build_component_ref (location

Re: [PATCH, i386]: Fix PR 67484, asan detects heap-use-after-free with target options

[Richard Biener]

On Tue, Sep 15, 2015 at 8:13 PM, Uros Bizjak  wrote:
> Hello!
>
> As mentioned in the PR, ix86_valid_target_attribute_tree creates
> temporary copies of current options strings and saves *pointers* to
> these copies with build_target_option_node. A couple of lines below,
> these temporary copies are freed, leaving dangling pointers in the
> saved structure.
>
> Use xstrndup to create permanent copy of string on the heap. This will
> however create a small leak, as this copy is never deallocated.
>
> There is no test infrastructure to check for memory errors, so there
> is no testcase added.
>
> 2015-09-15  Uros Bizjak  
>
> PR target/67484
> * config/i386/i386.c (ix86_valid_target_attribute_tree):
> Use xstrdup to copy option_strings to opts->x_ix86_arch_string and
> opts->x_ix86_tune_string.
>
> Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
>
> I'll wait a couple of days for possible comments on the above solution.

I thought we have a custom destructor for target_option_node.  Ah, no,
that was for target_globals.  I suppose we could add one to cl_target_option
as well.  Note that currently the strings are not GTY((skip)) so it seems
we expect ggc allocated strings there?  Which means the xstrdup in
ix86_valid_target_attribute_inner_p should be ggc_strdup?

Richard.

> Uros.

Re: [PATCH][ARM] Fix arm bootstrap failure due to -Werror=shift-negative-value

[Richard Earnshaw]

On 15/09/15 15:59, Kyrill Tkachov wrote:
> Hi all,
> 
> After Marek's patch I see the bootstrap failure on arm:
> gcc/config/arm/arm.c:4601:46: error: left shift of negative value
> [-Werror=shift-negative-value]
>  && (val & (-1 << (32 - set_sign_bit_copies))) == val)
> 
> I believe this is the right fix. Change -1 to HOST_WIDE_INT_M1U and
> change the type of val from HOST_WIDE_INT to unsigned HOST_WIDE_INT.
> This restores the bootstrap for me.
> 
> Committing as obvious to restore bootstrap
> 
> 2015-09-15  Kyrylo Tkachov  
> 
> * config/arm/arm.c (arm_gen_constant): Use HOST_WIDE_INT_M1U instead
> of -1 when shifting.  Change type of val to unsigned HOST_WIDE_INT.
> Update prototype.
> 

And I guess the next problem we're going to see is a warning that
HOST_WIDE_INT has been silently coerced to unsigned by a prototype...
Perhaps we should audit for that as well.

OK.

R.


> arm-bootstrap-fix.patch
> 
> 
> diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
> index 5f3180d..efb3a8b 100644
> --- a/gcc/config/arm/arm.c
> +++ b/gcc/config/arm/arm.c
> @@ -95,7 +95,7 @@ static int arm_compute_static_chain_stack_bytes (void);
>  static arm_stack_offsets *arm_get_frame_offsets (void);
>  static void arm_add_gc_roots (void);
>  static int arm_gen_constant (enum rtx_code, machine_mode, rtx,
> -  HOST_WIDE_INT, rtx, rtx, int, int);
> +  unsigned HOST_WIDE_INT, rtx, rtx, int, int);
>  static unsigned bit_count (unsigned long);
>  static unsigned feature_count (const arm_feature_set*);
>  static int arm_address_register_rtx_p (rtx, int);
> @@ -4227,8 +4227,8 @@ emit_constant_insn (rtx cond, rtx pattern)
>  
>  static int
>  arm_gen_constant (enum rtx_code code, machine_mode mode, rtx cond,
> -   HOST_WIDE_INT val, rtx target, rtx source, int subtargets,
> -   int generate)
> +   unsigned HOST_WIDE_INT val, rtx target, rtx source,
> +   int subtargets, int generate)
>  {
>int can_invert = 0;
>int can_negate = 0;
> @@ -4598,7 +4598,7 @@ arm_gen_constant (enum rtx_code code, machine_mode 
> mode, rtx cond,
> mvn   r0, r0, asl #12
> mvn   r0, r0, lsr #12  */
>if (set_sign_bit_copies > 8
> -   && (val & (-1 << (32 - set_sign_bit_copies))) == val)
> +   && (val & (HOST_WIDE_INT_M1U << (32 - set_sign_bit_copies))) == val)
>   {
> if (generate)
>   {
> 

Re: [patch] Fix wrong code on dynamic array slices

[Richard Biener]

Ok.

Thanks,
Richard.

On Wed, Sep 16, 2015 at 9:07 AM, Eric Botcazou  wrote:
> Hi,
>
> the attached Ada testcase fails on x86/Linux (32-bit only) because the FRE
> pass wrongly deletes stores as redundant:
>
> Deleted redundant store VIEW_CONVERT_EXPR(*a.18_41)[0]
> {lb: 4294967292 sz: 4} = 100;
> Deleted redundant store VIEW_CONVERT_EXPR(*a.18_41)[1]
> {lb: 4294967292 sz: 4} = 1;
> Deleted redundant store VIEW_CONVERT_EXPR(*a.18_41)[2]
> {lb: 4294967292 sz: 4} = 2;
> Deleted redundant store VIEW_CONVERT_EXPR(*a.18_41)[3]
> {lb: 4294967292 sz: 4} = 3;
> Deleted redundant store VIEW_CONVERT_EXPR(*a.18_41)[4]
> {lb: 4294967292 sz: 4} = 4;
>
> While the last 4 stores happen to be redundant (however the compiler cannot
> really determine it), the first one isn't and deleting it yields wrong code.
>
> These stores are part of a larger group of stores:
>
> VIEW_CONVERT_EXPR(*a.18_41)[4294967292]{lb: 4294967292
> sz: 4} = -4;
> VIEW_CONVERT_EXPR(*a.18_41)[4294967293]{lb: 4294967292
> sz: 4} = -3;
> VIEW_CONVERT_EXPR(*a.18_41)[4294967294]{lb: 4294967292
> sz: 4} = -2;
> VIEW_CONVERT_EXPR(*a.18_41)[4294967295]{lb: 4294967292
> sz: 4} = -1;
> VIEW_CONVERT_EXPR(*a.18_41)[0]{lb: 4294967292 sz: 4} =
> 100;
> VIEW_CONVERT_EXPR(*a.18_41)[1]{lb: 4294967292 sz: 4} =
> 1;
> VIEW_CONVERT_EXPR(*a.18_41)[2]{lb: 4294967292 sz: 4} =
> 2;
> VIEW_CONVERT_EXPR(*a.18_41)[3]{lb: 4294967292 sz: 4} =
> 3;
> VIEW_CONVERT_EXPR(*a.18_41)[4]{lb: 4294967292 sz: 4} =
> 4;
>
> and the first 4 ones are correctly detected as *not* redundant.  What changes
> between the two groups of stores is the index or, more precisely, the sign of
> the difference between the index and the low bound (4294967292 aka -4); it's
> positive for the first group and negative for the second group.  The latter
> case fools ao_ref_init_from_vn_reference because it doesn't properly truncate
> it to the precision of the index, like for example get_ref_base_and_extent,
> so as to make it positive again in this case, which in turn fools FRE.
>
> So the attached patch offset_int'ifies ao_ref_init_from_vn_reference the same
> way get_ref_base_and_extent was offset_int'ified (in fact double_int'ified at
> the time), adding the missing truncation in the process.
>
> Bootstrapped/regtested on x86_64-suse-linux, OK for the mainline?
>
>
> 2015-09-16  Eric Botcazou  
>
> * tree-ssa-sccvn.c (ao_ref_init_from_vn_reference): Use offset_int for
> offset and size computations instead of HOST_WIDE_INT.
>
>
> 2015-09-16  Eric Botcazou  
>
> * gnat.dg/opt49.adb: New test.
>
> --
> Eric Botcazou

Re: [PATCH, i386]: Fix PR 67484, asan detects heap-use-after-free with target options

[Uros Bizjak]

On Wed, Sep 16, 2015 at 10:45 AM, Richard Biener
 wrote:

>> As mentioned in the PR, ix86_valid_target_attribute_tree creates
>> temporary copies of current options strings and saves *pointers* to
>> these copies with build_target_option_node. A couple of lines below,
>> these temporary copies are freed, leaving dangling pointers in the
>> saved structure.
>>
>> Use xstrndup to create permanent copy of string on the heap. This will
>> however create a small leak, as this copy is never deallocated.
>>
>> There is no test infrastructure to check for memory errors, so there
>> is no testcase added.
>>
>> 2015-09-15  Uros Bizjak  
>>
>> PR target/67484
>> * config/i386/i386.c (ix86_valid_target_attribute_tree):
>> Use xstrdup to copy option_strings to opts->x_ix86_arch_string and
>> opts->x_ix86_tune_string.
>>
>> Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
>>
>> I'll wait a couple of days for possible comments on the above solution.
>
> I thought we have a custom destructor for target_option_node.  Ah, no,
> that was for target_globals.  I suppose we could add one to cl_target_option
> as well.  Note that currently the strings are not GTY((skip)) so it seems
> we expect ggc allocated strings there?  Which means the xstrdup in
> ix86_valid_target_attribute_inner_p should be ggc_strdup?

This is a bit over my knowledge of option processing, but please note
that the only function that performs non-recursive call to
ix86_valid_target_attribute_inner_p also frees the strings, allocated
by mentioned function.

Uros.

Re: [PATCH, i386]: Fix PR 67484, asan detects heap-use-after-free with target options

[Richard Biener]

I see in gtype-desc.c:

void
gt_ggc_mx_cl_target_option (void *x_p)
{
  struct cl_target_option * const x = (struct cl_target_option *)x_p;
  if (ggc_test_and_set_mark (x))
{
  gt_ggc_m_S ((*x).x_ix86_arch_string);
  gt_ggc_m_S ((*x).x_ix86_recip_name);
  gt_ggc_m_S ((*x).x_ix86_tune_ctrl_string);
  gt_ggc_m_S ((*x).x_ix86_tune_memcpy_strategy);
  gt_ggc_m_S ((*x).x_ix86_tune_memset_strategy);
  gt_ggc_m_S ((*x).x_ix86_tune_string);
}

so it certainly does not expect heap allocated strings in
ix86_arch_string and friends.

Richard.

On Wed, Sep 16, 2015 at 10:59 AM, Uros Bizjak  wrote:
> On Wed, Sep 16, 2015 at 10:45 AM, Richard Biener
>  wrote:
>
>>> As mentioned in the PR, ix86_valid_target_attribute_tree creates
>>> temporary copies of current options strings and saves *pointers* to
>>> these copies with build_target_option_node. A couple of lines below,
>>> these temporary copies are freed, leaving dangling pointers in the
>>> saved structure.
>>>
>>> Use xstrndup to create permanent copy of string on the heap. This will
>>> however create a small leak, as this copy is never deallocated.
>>>
>>> There is no test infrastructure to check for memory errors, so there
>>> is no testcase added.
>>>
>>> 2015-09-15  Uros Bizjak  
>>>
>>> PR target/67484
>>> * config/i386/i386.c (ix86_valid_target_attribute_tree):
>>> Use xstrdup to copy option_strings to opts->x_ix86_arch_string and
>>> opts->x_ix86_tune_string.
>>>
>>> Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
>>>
>>> I'll wait a couple of days for possible comments on the above solution.
>>
>> I thought we have a custom destructor for target_option_node.  Ah, no,
>> that was for target_globals.  I suppose we could add one to cl_target_option
>> as well.  Note that currently the strings are not GTY((skip)) so it seems
>> we expect ggc allocated strings there?  Which means the xstrdup in
>> ix86_valid_target_attribute_inner_p should be ggc_strdup?
>
> This is a bit over my knowledge of option processing, but please note
> that the only function that performs non-recursive call to
> ix86_valid_target_attribute_inner_p also frees the strings, allocated
> by mentioned function.
>
> Uros.

Re: [PATCH, i386]: Fix PR 67484, asan detects heap-use-after-free with target options

[Richard Biener]

And it is initialized via

void
cl_target_option_save (struct cl_target_option *ptr, struct gcc_options *opts)
{
  if (targetm.target_option.save)
targetm.target_option.save (ptr, opts);

  ptr->x_recip_mask = opts->x_recip_mask;
  ptr->x_ix86_isa_flags = opts->x_ix86_isa_flags;
  ptr->x_ix86_fpmath = opts->x_ix86_fpmath;
  ptr->x_target_flags = opts->x_target_flags;
}

which uses a target hook to copy from gcc_options to cl_target_options...
(what a maze), and ix86_function_specific_save also plain copies the
pointers.

Richard.

On Wed, Sep 16, 2015 at 11:08 AM, Richard Biener
 wrote:
> I see in gtype-desc.c:
>
> void
> gt_ggc_mx_cl_target_option (void *x_p)
> {
>   struct cl_target_option * const x = (struct cl_target_option *)x_p;
>   if (ggc_test_and_set_mark (x))
> {
>   gt_ggc_m_S ((*x).x_ix86_arch_string);
>   gt_ggc_m_S ((*x).x_ix86_recip_name);
>   gt_ggc_m_S ((*x).x_ix86_tune_ctrl_string);
>   gt_ggc_m_S ((*x).x_ix86_tune_memcpy_strategy);
>   gt_ggc_m_S ((*x).x_ix86_tune_memset_strategy);
>   gt_ggc_m_S ((*x).x_ix86_tune_string);
> }
>
> so it certainly does not expect heap allocated strings in
> ix86_arch_string and friends.
>
> Richard.
>
> On Wed, Sep 16, 2015 at 10:59 AM, Uros Bizjak  wrote:
>> On Wed, Sep 16, 2015 at 10:45 AM, Richard Biener
>>  wrote:
>>
 As mentioned in the PR, ix86_valid_target_attribute_tree creates
 temporary copies of current options strings and saves *pointers* to
 these copies with build_target_option_node. A couple of lines below,
 these temporary copies are freed, leaving dangling pointers in the
 saved structure.

 Use xstrndup to create permanent copy of string on the heap. This will
 however create a small leak, as this copy is never deallocated.

 There is no test infrastructure to check for memory errors, so there
 is no testcase added.

 2015-09-15  Uros Bizjak  

 PR target/67484
 * config/i386/i386.c (ix86_valid_target_attribute_tree):
 Use xstrdup to copy option_strings to opts->x_ix86_arch_string and
 opts->x_ix86_tune_string.

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

 I'll wait a couple of days for possible comments on the above solution.
>>>
>>> I thought we have a custom destructor for target_option_node.  Ah, no,
>>> that was for target_globals.  I suppose we could add one to cl_target_option
>>> as well.  Note that currently the strings are not GTY((skip)) so it seems
>>> we expect ggc allocated strings there?  Which means the xstrdup in
>>> ix86_valid_target_attribute_inner_p should be ggc_strdup?
>>
>> This is a bit over my knowledge of option processing, but please note
>> that the only function that performs non-recursive call to
>> ix86_valid_target_attribute_inner_p also frees the strings, allocated
>> by mentioned function.
>>
>> Uros.

Re: [PATCH v5][aarch64] Implemented reciprocal square root (rsqrt) estimation in -ffast-math

[Benedikt Huber]

ping

patch is in: https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00417.html

Thank you

> On 07 Sep 2015, at 12:40, Benedikt Huber 
>  wrote:
> 
> This fifth revision of the patch:
> * Moves a function declaration to a header.
> * Adds comments to functions.
> 
> Ok for check in.
> 
> Benedikt Huber (1):
>  2015-09-03  Benedikt Huber  
>   Philipp Tomsich  
> 
> gcc/ChangeLog  |  21 
> gcc/config/aarch64/aarch64-builtins.c  | 107 +++
> gcc/config/aarch64/aarch64-opts.h  |   7 ++
> gcc/config/aarch64/aarch64-protos.h|   3 +
> gcc/config/aarch64/aarch64-simd.md |  27 +
> gcc/config/aarch64/aarch64-tuning-flags.def|   1 +
> gcc/config/aarch64/aarch64.c   | 113 -
> gcc/config/aarch64/aarch64.md  |   3 +
> gcc/config/aarch64/aarch64.opt |   8 ++
> gcc/doc/invoke.texi|  19 
> gcc/testsuite/gcc.target/aarch64/rsqrt-asm-check.c |  63 
> gcc/testsuite/gcc.target/aarch64/rsqrt.c   | 107 +++
> 12 files changed, 474 insertions(+), 5 deletions(-)
> create mode 100644 gcc/testsuite/gcc.target/aarch64/rsqrt-asm-check.c
> create mode 100644 gcc/testsuite/gcc.target/aarch64/rsqrt.c
> 
> --
> 1.9.1
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [C++ Patch] PR 53184 ("Unnecessary anonymous namespace warnings")

[Paolo Carlini]

Hi,

On 09/15/2015 03:11 AM, Jason Merrill wrote:

On 09/14/2015 06:17 PM, Paolo Carlini wrote:

Hi Florian,

On 09/14/2015 09:41 PM, Florian Weimer wrote:

  This warning is
+enabled by default.
Maybe add a sentence why this is bad?  I can only guess, but I suspect
the reason is this: Such types are necessarily specific to a single
translation unit because any definition in another translation unit
would be an ODR violation, so they can be put into the anonymous
namespace themselves.

As I probably mentioned somewhere, GCC is the only compiler I have at
hand implementing something similar: frankly, I'm not sure how exactly
we want to put it, concisely and neatly at the same time. If you are
willing to prepare something more concrete, I'm sure Jason would be
happy to review it!


Florian's summary is correct.

If a type A depends on a type B with no or internal linkage, defining 
it in multiple translation units would be an ODR violation because the 
meaning of B is different in each translation unit.  If A only appears 
in a single translation unit, the best way to silence the warning is 
to give it internal linkage by putting it in an anonymous namespace as 
well.  The compiler doesn't give this warning for types defined in the 
main .C file, as those are unlikely to have multiple definitions.
Thanks. Then I guess I'm going to simply add to invoke.texi the above 
as-is: if somebody thinks it's too long and sees a way to shorten it 
without loosing important details, please speak asap ;)


Paolo.

PR67588: module.c heap use after free and some submodule tidying up

[Paul Richard Thomas]

Dear All,

The attached patch fixes a memory leak, prevents writing of smod
files, when there are no submodules and adds a paragraph to the
gfortran documentation on submodules.

After this, PR66762, which is the -flto problem, is the last one to
sort out in order to complete the implementation of submodules.

Bootstraps and regtests on FC21/x86_64 - OK for trunk?

I will apply the patch tomorrow morning if there are no objections.

Cheers

Paul

2015-09-16  Paul Thomas  

PR fortran/52846
PR fortran/67588
* module.c : Add static no_module_procedures.
(gfc_match_submodule): Correct memory leakage caused during the
freeing of use_lists.
(mio_symbol_attribute): Reset above if module procedure is
encountered.
(gfc_dump_module): Set above and exit without writing smod file
if it reset.
* gfortran.texi : Add section on submodule support.

2015-09-16  Paul Thomas  

PR fortran/52846
* gfortran.dg/public_private_module_5.f90: Add module procedure
trigger_smod to ensure that the smod file is written.
Index: /home/pault/svn/trunk/gcc/fortran/module.c
===
*** /home/pault/svn/trunk/gcc/fortran/module.c  (revision 227818)
--- /home/pault/svn/trunk/gcc/fortran/module.c  (working copy)
*** static gzFile module_fp;
*** 193,198 
--- 193,203 
  static const char *module_name;
  /* The name of the .smod file that the submodule will write to.  */
  static const char *submodule_name;
+ 
+ /* Suppress the output of a .smod file by module, if no module
+procedures have been seen.  */
+ static bool no_module_procedures;
+ 
  static gfc_use_list *module_list;
  
  /* If we're reading an intrinsic module, this is its ID.  */
*** gfc_match_submodule (void)
*** 798,804 
/* Just retain the ultimate .(s)mod file for reading, since it
   contains all the information in its ancestors.  */
use_list = module_list;
!   for (; module_list->next; use_list = use_list->next)
  {
module_list = use_list->next;
free (use_list);
--- 803,809 
/* Just retain the ultimate .(s)mod file for reading, since it
   contains all the information in its ancestors.  */
use_list = module_list;
!   for (; module_list->next; use_list = module_list)
  {
module_list = use_list->next;
free (use_list);
*** mio_symbol_attribute (symbol_attribute *
*** ,2228 
--- 2227,2236 
if (attr->array_outer_dependency)
MIO_NAME (ab_attribute) (AB_ARRAY_OUTER_DEPENDENCY, attr_bits);
if (attr->module_procedure)
+   {
  MIO_NAME (ab_attribute) (AB_MODULE_PROCEDURE, attr_bits);
+ no_module_procedures = false;
+   }
  
mio_rparen ();
  
*** gfc_dump_module (const char *name, int d
*** 6081,6089 
else
  dump_smod =false;
  
dump_module (name, dump_flag);
  
!   if (dump_smod)
  return;
  
/* Write a submodule file from a module.  The 'dump_smod' flag switches
--- 6089,6098 
else
  dump_smod =false;
  
+   no_module_procedures = true;
dump_module (name, dump_flag);
  
!   if (no_module_procedures || dump_smod)
  return;
  
/* Write a submodule file from a module.  The 'dump_smod' flag switches
Index: /home/pault/svn/trunk/gcc/fortran/gfortran.texi
===
*** /home/pault/svn/trunk/gcc/fortran/gfortran.texi (revision 227818)
--- /home/pault/svn/trunk/gcc/fortran/gfortran.texi (working copy)
*** of @code{ISO_FORTRAN_ENV}.
*** 1047,1052 
--- 1047,1060 
  and experimental support for multiple images with the @option{-fcoarray=lib}
  flag.
  
+ @item Submodules are supported. It should noted that @code{MODULEs} do not
+ produce the smod file needed by the descendent @code{SUBMODULEs} unless they
+ contain at least one @code{MODULE PROCEDURE} interface. The reason for this is
+ that @code{SUBMODULEs} are useless without @code{MODULE PROCEDUREs}. See
+ http://j3-fortran.org/doc/meeting/207/15-209.txt for a discussion and a draft
+ interpretation. Adopting this interpretation has the advantage that code that
+ does not use submodules does not generate smod files.
+ 
  @item The @code{DO CONCURRENT} construct is supported.
  
  @item The @code{BLOCK} construct is supported.
Index: /home/pault/svn/trunk/gcc/testsuite/gfortran.dg/submodule_5.f08
===
*** /home/pault/svn/trunk/gcc/testsuite/gfortran.dg/submodule_5.f08 
(revision 227818)
--- /home/pault/svn/trunk/gcc/testsuite/gfortran.dg/submodule_5.f08 
(working copy)
*** module foo_interface
*** 10,15 
--- 10,23 
type foo
  character(len=16), private :: byebye = "adieu, world!   "
end type foo
+ 
+ ! This interface is required to trigger the output of an .smod file.
+ ! See http://j3-fortran.org/doc/mee

Re: [PATCH] New attribute to create target clones

[Evgeny Stupachenko]

PING 2.

On Tue, Sep 8, 2015 at 2:27 PM, Evgeny Stupachenko  wrote:
> Ping.
>
> On Thu, Aug 27, 2015 at 2:18 PM, Evgeny Stupachenko  
> wrote:
>> Hi All,
>>
>> Based on RFC:
>> https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01322.html
>>
>> The patch implement an extension to Function Multiversioning that
>> allows to clone a function for multiple targets.
>> __attribute__((target_clones("avx","arch=slm","default")))
>> int foo ()
>> ...
>>
>> Will create 3 clones of foo(). One optimized with -mavx, one optimized
>> with -march=slm, and one with default optimizations.
>> And will create ifunc resolver that calls appropriate clone (same as
>> in Function Multiversioning).
>>
>> Bootstrap and make check for x86 passed.
>>
>> Is it ok for trunk?
>>
>> 2015-08-27  Evgeny Stupachenko  
>>
>> gcc/
>> * Makefile.in (OBJS): Add multiple_target.o.
>> * multiple_target.c (make_attribute): New.
>> (create_dispatcher_calls): Ditto.
>> (expand_target_clones): Ditto.
>> (ipa_target_clone): Ditto.
>> * passes.def (pass_target_clone): New ipa pass.
>> * tree-pass.h (make_pass_target_clone): Ditto.
>>
>> gcc/c-family
>> * c-common.c (handle_target_clones_attribute): New.
>> * (c_common_attribute_table): Add handle_target_clones_attribute.
>> * (handle_always_inline_attribute): Add check on target_clones
>> attribute.
>> * (handle_target_attribute): Ditto.
>>
>> gcc/testsuite
>> * gcc.dg/mvc1.c: New test for multiple targets cloning.
>> * gcc.dg/mvc2.c: Ditto.
>> * gcc.dg/mvc3.c: Ditto.
>> * gcc.dg/mvc4.c: Ditto.
>> * gcc.dg/mvc5.c: Ditto.
>> * gcc.dg/mvc6.c: Ditto.
>> * gcc.dg/mvc7.c: Ditto.
>> * g++.dg/ext/mvc1.C: Ditto.
>> * g++.dg/ext/mvc2.C: Ditto.
>> * g++.dg/ext/mvc3.C: Ditto.
>>
>> gcc/doc
>> * doc/extend.texi (target_clones): New attribute description.

[PATCH] Fix Cygwin bootstrap failing to find win32 libraries

[JonY]

libgcc is failing to find kerne32 etc during the 2nd stage when
bootstraping, explicitly add w32api directory to search path.

Patch OK?

diff --git a/gcc/config/i386/cygwin.h b/gcc/config/i386/cygwin.h
index 2a2a0bf..fd3bc0a 100644
--- a/gcc/config/i386/cygwin.h
+++ b/gcc/config/i386/cygwin.h
@@ -39,6 +39,7 @@ along with GCC; see the file COPYING3.  If not see

 #undef STARTFILE_SPEC
 #define STARTFILE_SPEC "\
+  -L%R/usr/lib/w32api \
   %{!shared: %{!mdll: crt0%O%s \
   %{pg:gcrt0%O%s}}}\
   %{shared:crtbeginS.o%s;:crtbegin.o%s} \




signature.asc
Description: OpenPGP digital signature

Re: [PATCH PR66388]Add sizetype cand for BIV of smaller type if it's used as index of memory ref

[Richard Biener]

Ok.

Thanks,
Richard.

On Tue, Sep 15, 2015 at 7:56 AM, Bin.Cheng  wrote:
> Just realized that I missed the updated patch before.  Here it is...
>
> Thanks,
> bin
>
> On Tue, Sep 8, 2015 at 6:07 PM, Bin.Cheng  wrote:
>> On Tue, Sep 8, 2015 at 6:06 PM, Bin.Cheng  wrote:
>>> On Wed, Sep 2, 2015 at 10:12 PM, Richard Biener
>>>  wrote:
 On Wed, Sep 2, 2015 at 5:26 AM, Bin Cheng  wrote:
> Hi,
> This patch is a new approach to fix PR66388.  IVO today computes iv_use 
> with
> iv_cand which has at least same type precision as the use.  On 64bit
> platforms like AArch64, this results in different iv_cand created for each
> address type iv_use, and register pressure increased.  As a matter of 
> fact,
> the BIV should be used for all iv_uses in some of these cases.  It is a
> latent bug but recently getting worse because of overflow changes.
>
> The original approach at
> https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01484.html can fix the issue
> except it conflict with IV elimination.  Seems to me it is impossible to
> mitigate the contradiction.
>
> This new approach fixes the issue by adding sizetype iv_cand for BIVs
> directly.  In cases if the original BIV is preferred, the sizetype iv_cand
> will be chosen.  As for code generation, the sizetype iv_cand has the same
> effect as the original BIV.  Actually, it's better because BIV needs to be
> explicitly extended to sizetype to be used in address expression on most
> targets.
>
> One shortage of this approach is it may introduce more iv candidates.  To
> minimize the impact, this patch does sophisticated code analysis and adds
> sizetype candidate for BIV only if it is used as index.  Moreover, it 
> avoids
> to add candidate of the original type if the BIV is only used as index.
> Statistics for compiling spec2k6 shows increase of candidate number is
> modest and can be ignored.
>
> There are two more patches following to fix corner cases revealed by this
> one.  In together they bring obvious perf improvement for spec26k/int on
> aarch64.
> Spec2k6/int
> 400.perlbench   3.44%
> 445.gobmk   -0.86%
> 456.hmmer   14.83%
> 458.sjeng   2.49%
> 462.libquantum  -0.79%
> GEOMEAN 1.68%
>
> There is also about 0.36% improvement for spec2k6/fp, mostly because of 
> case
> 436.cactusADM.  I believe it can be further improved, but that should be
> another patch.
>
> I also collected benchmark data for x86_64.  Spec2k6/fp is not affected.  
> As
> for spec2k6/int, though the geomean is improved slightly, 400.perlbench is
> regressed by ~3%.  I can see BIVs are chosen for some loops instead of
> address candidates.  Generally, the loop header will be simplified because
> iv elimination with BIV is simpler; the number of instructions in loop 
> body
> isn't changed.  I suspect the regression comes from different addressing
> modes.  With BIV, complex addressing mode like [base + index << scale +
> disp] is used, rather than [base + disp].  I guess the former has more
> micro-ops, thus more expensive.  This guess can be confirmed by manually
> suppressing the complex addressing mode with higher address cost.
> Now the problem becomes why overall cost of BIV is computed lower while 
> the
> actual cost is higher.  I noticed for most affected loops, loop header is
> bloated because of iv elimination using the old address candidate.  The
> bloated loop header results in much higher cost than BIV.  As a result, 
> BIV
> is preferred.  I also noticed the bloated loop header generally can be
> simplified (I have a following patch for this).  After applying the local
> patch, the old address candidate is chosen, and most of regression is
> recovered.
> Conclusion is I think loop header bloated issue should be blamed for the
> regression, and it can be resolved.
>
> Bootstrap and test on x64_64 and aarch64.  It fixes failure of
> gcc.target/i386/pr49781-1.c, without new breakage.
>
> So what do you think?

 The data above looks ok to me.

 +static struct iv *
 +find_deriving_biv_for_iv (struct ivopts_data *data, struct iv *iv)
 +{
 +  aff_tree aff;
 +  struct expand_data exp_data;
 +
 +  if (!iv->ssa_name || TREE_CODE (iv->ssa_name) != SSA_NAME)
 +return iv;
 +
 +  /* Expand IV's ssa_name till the deriving biv is found.  */
 +  exp_data.data = data;
 +  exp_data.biv = NULL;
 +  tree_to_aff_combination_expand (iv->ssa_name, TREE_TYPE (iv->ssa_name),
 + &aff, &data->name_expansion_cache,
 + stop_expand, &exp_data);
 +  return exp_data.biv;

 that's actually "abusing" tree_to_aff_combination_expand for simply walking

[PATCH, RFC] Implement N4230, Nested namespace definition

[Ville Voutilainen]

This is the first stab, I haven't written the tests yet. Feedback would be
most welcome; should I put this code into a separate function? Is the minor
code duplication with the regular namespace definition ok?
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 3a68dd7..00f18fb 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -16750,7 +16750,7 @@ cp_parser_namespace_definition (cp_parser* parser)
   tree identifier, attribs;
   bool has_visibility;
   bool is_inline;
-
+  cp_token* token;
   cp_ensure_no_omp_declare_simd (parser);
   if (cp_lexer_next_token_is_keyword (parser->lexer, RID_INLINE))
 {
@@ -16762,7 +16762,7 @@ cp_parser_namespace_definition (cp_parser* parser)
 is_inline = false;
 
   /* Look for the `namespace' keyword.  */
-  cp_parser_require_keyword (parser, RID_NAMESPACE, RT_NAMESPACE);
+  token = cp_parser_require_keyword (parser, RID_NAMESPACE, RT_NAMESPACE);
 
   /* Get the name of the namespace.  We do not attempt to distinguish
  between an original-namespace-definition and an
@@ -16776,6 +16776,33 @@ cp_parser_namespace_definition (cp_parser* parser)
   /* Parse any specified attributes.  */
   attribs = cp_parser_attributes_opt (parser);
 
+  if (cp_lexer_next_token_is (parser->lexer, CPP_SCOPE))
+{
+  if (is_inline)
+error_at (token->location, "a nested % definition cannot 
be inline");
+  push_namespace (identifier);
+  int nest_count = 0;
+  while (cp_lexer_next_token_is (parser->lexer, CPP_SCOPE))
+{
+  cp_lexer_consume_token (parser->lexer);
+  if (cp_lexer_next_token_is (parser->lexer, CPP_NAME))
+identifier = cp_parser_identifier (parser);
+  else
+{
+  cp_parser_error (parser, "nested identifier required");
+  break;
+}
+  ++nest_count;
+  push_namespace (identifier);
+}
+  cp_parser_require (parser, CPP_OPEN_BRACE, RT_OPEN_BRACE);
+  cp_parser_namespace_body (parser);
+  while (nest_count--)
+pop_namespace ();
+  pop_namespace ();
+  cp_parser_require (parser, CPP_CLOSE_BRACE, RT_CLOSE_BRACE);
+  return;
+}
   /* Look for the `{' to start the namespace.  */
   cp_parser_require (parser, CPP_OPEN_BRACE, RT_OPEN_BRACE);
   /* Start the namespace.  */

[PATCH] Move language dependend DIE annotations early

[Richard Biener]

This moves gen_scheduled_generic_parms_dies and
gen_remaining_tmpl_value_param_die_attribute to early finish as we
are never populating them after that (the patch adds asserts to that 
fact).  I left handling "leftovers" of 
gen_remaining_tmpl_value_param_die_attribute in late finish as well
as we are special-casing generating references to symbols where we
only can decide late whether we may emit them or not.  The example
from the testsuite has a template parameter of function pointer type
with its value refering to a function we don't know whether we'll
end up outputting it.  (we need a good solution for this kind of
issue for early LTO debug as well - we only know at LTO link time
whether the symbol we want to refer to prevails.  If only we had
the ability to emit "weak" references to those ...)

Bootstrapped and tested on x86_64-unknown-linux-gnu and verified
gdb testsuite is fine.

I plan to commit this if there are no comments (and the previous
two patches have been approved or committed).

Richard.

2015-09-16  Richard Biener  

* dwarf2out.c (append_entry_to_tmpl_value_parm_die_table): Assert
we're in early phase.
(schedule_generic_params_dies_gen): Likewise.
(gen_remaining_tmpl_value_param_die_attribute): Do only as much
work as possible, retaining unhandled cases.
(gen_scheduled_generic_parms_dies): Set early-dwarf flag and
clear out generic_type_instances at the end.
(dwarf2out_finish): Move call to gen_scheduled_generic_parms_dies...
(dwarf2out_early_finish): ... here.  Do most of
gen_remaining_tmpl_value_param_die_attribute here.

Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 227779)
+++ gcc/dwarf2out.c (working copy)
@@ -22091,6 +22097,8 @@ append_entry_to_tmpl_value_parm_die_tabl
   if (!die || !arg)
 return;
 
+  gcc_assert (early_dwarf);
+
   if (!tmpl_value_parm_die_table)
 vec_alloc (tmpl_value_parm_die_table, 32);
 
@@ -22120,6 +22128,8 @@ schedule_generic_params_dies_gen (tree t
   if (!generic_type_p (t))
 return;
 
+  gcc_assert (early_dwarf);
+
   if (!generic_type_instances)
 vec_alloc (generic_type_instances, 256);
 
@@ -22135,11 +22145,21 @@ gen_remaining_tmpl_value_param_die_attri
 {
   if (tmpl_value_parm_die_table)
 {
-  unsigned i;
+  unsigned i, j;
   die_arg_entry *e;
 
+  /* We do this in two phases - first get the cases we can
+handle during early-finish, preserving those we cannot
+(containing symbolic constants where we don't yet know
+whether we are going to output the referenced symbols).
+For those we try again at late-finish.  */
+  j = 0;
   FOR_EACH_VEC_ELT (*tmpl_value_parm_die_table, i, e)
-   tree_add_const_value_attribute (e->die, e->arg);
+   {
+ if (!tree_add_const_value_attribute (e->die, e->arg))
+   (*tmpl_value_parm_die_table)[j++] = *e;
+   }
+  tmpl_value_parm_die_table->truncate (j);
 }
 }
 
@@ -22157,9 +22177,15 @@ gen_scheduled_generic_parms_dies (void)
   if (!generic_type_instances)
 return;
   
+  /* We end up "recursing" into schedule_generic_params_dies_gen, so
+ pretend this generation is part of "early dwarf" as well.  */
+  set_early_dwarf s;
+
   FOR_EACH_VEC_ELT (*generic_type_instances, i, t)
 if (COMPLETE_TYPE_P (t))
   gen_generic_params_dies (t);
+
+  generic_type_instances = NULL;
 }
 
 
@@ -25193,7 +25219,6 @@ dwarf2out_finish (const char *filename)
   producer->dw_attr_val.v.val_str->refcount--;
   producer->dw_attr_val.v.val_str = find_AT_string (producer_string);
 
-  gen_scheduled_generic_parms_dies ();
   gen_remaining_tmpl_value_param_die_attribute ();
 
   /* Add the name for the main input file now.  We delayed this from
@@ -25550,6 +25575,9 @@ dwarf2out_early_finish (void)
   /* The point here is to flush out the limbo list so that it is empty
  and we don't need to stream it for LTO.  */
   flush_limbo_die_list ();
+
+  gen_scheduled_generic_parms_dies ();
+  gen_remaining_tmpl_value_param_die_attribute ();
 }
 
 /* Reset all state within dwarf2out.c so that we can rerun the compiler

Re: [C++] Coding rule enforcement

[Nathan Sidwell]

On 09/15/15 09:33, Jason Merrill wrote:

On 09/15/2015 09:26 AM, Richard Biener wrote:

Wouldn't warning flags be better so you can decide whether it's an error
or a warning via -Werror=virtual-inheritance vs. -Wvirtual-inheritance?


Yep.  That also handles the system header exemption (unless -Wsystem-headers).


This  version implements Richard's suggestion of warning flags.

nathan

2015-09-16  Nathan Sidwell  

	c-family/
	* c.opt (Wmultiple-inheritance, Wvirtual-inheritance, Wtemplates,
	Wnamespaces): New C++ warnings.

	cp/
	* decl.c (xref_basetypes): Check virtual and/or multiple
	inheritance warning.
	* parser.c (cp_parser_namespace_definition): Check namespaces
	warning.
	* pt.c (push_template_decl_real): Check templates warning.

	* doc/invoke.texi  (-Wmultiple-inheritance, -Wvirtual-inheritance,
	-Wtemplates, -Wnamespaces): Document.

	testsuite/
	* g++.dg/diagostic/disable.C: New.

Index: gcc/c-family/c.opt
===
--- gcc/c-family/c.opt	(revision 227761)
+++ gcc/c-family/c.opt	(working copy)
@@ -573,6 +573,14 @@ Wmissing-field-initializers
 C ObjC C++ ObjC++ Var(warn_missing_field_initializers) Warning EnabledBy(Wextra)
 Warn about missing fields in struct initializers
 
+Wmultiple-inheritance
+C++ ObjC++ Var(warn_multiple_inheritance) Warninng
+Warn on direct multiple inheritance
+
+Wnamespaces
+C++ ObjC++ Var(warn_namespaces) Warning
+Warn on namespace definition
+
 Wsized-deallocation
 C++ ObjC++ Var(warn_sized_deallocation) Warning EnabledBy(Wextra)
 Warn about missing sized deallocation functions
@@ -610,6 +618,10 @@ Wswitch-bool
 C ObjC C++ ObjC++ Var(warn_switch_bool) Warning Init(1)
 Warn about switches with boolean controlling expression
 
+Wtemplates
+C++ ObjC++ Var(warn_templates) Warning
+Warn on primary template declaration
+
 Wmissing-format-attribute
 C ObjC C++ ObjC++ Alias(Wsuggest-attribute=format)
 ;
@@ -936,6 +948,10 @@ Wvolatile-register-var
 C ObjC C++ ObjC++ Var(warn_volatile_register_var) Warning LangEnabledBy(C ObjC C++ ObjC++,Wall)
 Warn when a register variable is declared volatile
 
+Wvirtual-inheritance
+C++ ObjC++ Var(warn_virtual_inheritance) Warning
+Warn on direct virtual inheritance
+
 Wvirtual-move-assign
 C++ ObjC++ Var(warn_virtual_move_assign) Warning Init(1)
 Warn if a virtual base has a non-trivial move assignment operator
Index: gcc/cp/decl.c
===
--- gcc/cp/decl.c	(revision 227761)
+++ gcc/cp/decl.c	(working copy)
@@ -12729,6 +12729,7 @@ xref_basetypes (tree ref, tree base_list
   tree binfo, base_binfo;
   unsigned max_vbases = 0; /* Maximum direct & indirect virtual bases.  */
   unsigned max_bases = 0;  /* Maximum direct bases.  */
+  unsigned max_dvbases = 0; /* Maximum direct virtual bases.  */
   int i;
   tree default_access;
   tree igo_prev; /* Track Inheritance Graph Order.  */
@@ -12766,12 +12767,13 @@ xref_basetypes (tree ref, tree base_list
 	{
 	  max_bases++;
 	  if (TREE_TYPE (*basep))
-	max_vbases++;
+	max_dvbases++;
 	  if (CLASS_TYPE_P (basetype))
 	max_vbases += vec_safe_length (CLASSTYPE_VBASECLASSES (basetype));
 	  basep = &TREE_CHAIN (*basep);
 	}
 }
+  max_vbases += max_dvbases;
 
   TYPE_MARKED_P (ref) = 1;
 
@@ -12814,6 +12816,9 @@ xref_basetypes (tree ref, tree base_list
 	  error ("Java class %qT cannot have multiple bases", ref);
   return false;
 }
+  else if (warn_multiple_inheritance)
+	warning (OPT_Wmultiple_inheritance,
+		 "%qT defined with multiple direct bases", ref);
 }
 
   if (max_vbases)
@@ -12825,6 +12830,9 @@ xref_basetypes (tree ref, tree base_list
 	  error ("Java class %qT cannot have virtual bases", ref);
   return false;
 }
+  else if (max_dvbases && warn_virtual_inheritance)
+	warning (OPT_Wvirtual_inheritance,
+		 "%qT defined with direct virtual base", ref);
 }
 
   for (igo_prev = binfo; base_list; base_list = TREE_CHAIN (base_list))
Index: gcc/cp/parser.c
===
--- gcc/cp/parser.c	(revision 227761)
+++ gcc/cp/parser.c	(working copy)
@@ -16798,6 +16798,9 @@ cp_parser_namespace_definition (cp_parse
 
   has_visibility = handle_namespace_attrs (current_namespace, attribs);
 
+  if (warn_namespaces)
+warning  (OPT_Wnamespaces, "namepace %qD entered", current_namespace);
+
   /* Parse the body of the namespace.  */
   cp_parser_namespace_body (parser);
 
Index: gcc/cp/pt.c
===
--- gcc/cp/pt.c	(revision 227761)
+++ gcc/cp/pt.c	(working copy)
@@ -5088,6 +5088,9 @@ push_template_decl_real (tree decl, bool
 
   if (is_primary)
 {
+  if (warn_templates)
+	warning (OPT_Wtemplates, "template %qD declared", decl);
+  
   if (DECL_CLASS_SCOPE_P (decl))
 	member_template_p = true;
   if (TREE_CODE (decl) == TYPE_DECL
Index: gcc/doc/invoke.texi
===

[gomp4] reduction cleanup

[Nathan Sidwell]

I noticed some unreachable code.  Committed this.
2015-09-16  Nathan Sidwell  

	* omp-low.c (lower_oacc_reductions): Remove dead initialization
	and unreachable code.

Index: gcc/omp-low.c
===
--- gcc/omp-low.c	(revision 227792)
+++ gcc/omp-low.c	(working copy)
@@ -4729,7 +4729,7 @@ static void
 lower_oacc_reductions (enum internal_fn ifn, int loop_dim, tree clauses,
 		   gimple_seq *ilist, omp_context *ctx, bool write_back)
 {
-  tree orig, res, var, ref_to_res, call, dim;
+  tree orig, var, ref_to_res, call, dim;
   tree c, tcode, gwv, rid, lid = build_int_cst (integer_type_node, oacc_lid);
   int oacc_rid, i;
   unsigned mask = extract_oacc_loop_mask (ctx);
@@ -4783,12 +4783,6 @@ lower_oacc_reductions (enum internal_fn
   if (var == NULL_TREE)
 	var = orig;
 
-  res = build_outer_var_ref (orig, ctx);
-
-  if (res == orig)
-	ref_to_res = NULL_TREE;
-
-  ref_to_res = integer_zero_node;
   if (is_oacc_parallel (ctx))
 	{
 	  ref_to_res = build_receiver_ref (orig, false, ctx);
@@ -4797,11 +4791,9 @@ lower_oacc_reductions (enum internal_fn
 	ref_to_res = build_simple_mem_ref (ref_to_res);
 	}
   else if (loop_dim == GOMP_DIM_GANG)
-	ref_to_res = build_fold_addr_expr (res);
-
-  /* Don't do anything for private gang reductions.  */
-  if (ref_to_res == NULL_TREE)
-	continue;
+	ref_to_res = build_fold_addr_expr (build_outer_var_ref (orig, ctx));
+  else
+	ref_to_res = integer_zero_node;
 
   rcode = OMP_CLAUSE_REDUCTION_CODE (c);
   if (rcode == MINUS_EXPR)

Re: [PATCH] Move language dependend DIE annotations early

[Richard Biener]

On Wed, 16 Sep 2015, Richard Biener wrote:

> 
> This moves gen_scheduled_generic_parms_dies and
> gen_remaining_tmpl_value_param_die_attribute to early finish as we
> are never populating them after that (the patch adds asserts to that 
> fact).  I left handling "leftovers" of 
> gen_remaining_tmpl_value_param_die_attribute in late finish as well
> as we are special-casing generating references to symbols where we
> only can decide late whether we may emit them or not.  The example
> from the testsuite has a template parameter of function pointer type
> with its value refering to a function we don't know whether we'll
> end up outputting it.  (we need a good solution for this kind of
> issue for early LTO debug as well - we only know at LTO link time
> whether the symbol we want to refer to prevails.  If only we had
> the ability to emit "weak" references to those ...)

Ok, maybe try to explain that a little bit more with an example.  If
we have a CU with just

int i;
static const int *p = &i;

then 'p' is unused but we still try to emit debug info for it
and its constant initializer.  This makes us refer to 'i'.  With
LTO 'i' may actually end up not being output (we localize it and
optimize it away if unused).  Unfortunately the reference to
'i' from the DWARF isn't symbolically but it is via a relocation
(a DW_OP_addr).  If it were possible to use a symbol name as
reference we'd be fine (and the debugger could print '&i' even
if i was optimized away).  If it were possible to allow the
linker to resolve that relocation to NULL it would solve the issue
as well (thus if 'i' were weak) - I'm quite sure using some tricks
like a local weak alias might work (on some platforms), but not
100% sure.

Anyway, that issue is orthogonal to the patch but the reason
why we need to defer some of gen_remaining_tmpl_value_param_die_attribute
to the late phase where we know TREE_ASM_WRITTEN bettter.
(we do have some code in resolve_addr pruning out these kind of references
if they are not valid anymore, not sure if this means we can remove
the TREE_ASM_WRITTEN check from reference_to_unused (or even
reference_to_unused completely).

Richard.

> Bootstrapped and tested on x86_64-unknown-linux-gnu and verified
> gdb testsuite is fine.
> 
> I plan to commit this if there are no comments (and the previous
> two patches have been approved or committed).
> 
> Richard.
> 
> 2015-09-16  Richard Biener  
> 
>   * dwarf2out.c (append_entry_to_tmpl_value_parm_die_table): Assert
>   we're in early phase.
>   (schedule_generic_params_dies_gen): Likewise.
>   (gen_remaining_tmpl_value_param_die_attribute): Do only as much
>   work as possible, retaining unhandled cases.
>   (gen_scheduled_generic_parms_dies): Set early-dwarf flag and
>   clear out generic_type_instances at the end.
>   (dwarf2out_finish): Move call to gen_scheduled_generic_parms_dies...
>   (dwarf2out_early_finish): ... here.  Do most of
>   gen_remaining_tmpl_value_param_die_attribute here.
> 
> Index: gcc/dwarf2out.c
> ===
> --- gcc/dwarf2out.c   (revision 227779)
> +++ gcc/dwarf2out.c   (working copy)
> @@ -22091,6 +22097,8 @@ append_entry_to_tmpl_value_parm_die_tabl
>if (!die || !arg)
>  return;
>  
> +  gcc_assert (early_dwarf);
> +
>if (!tmpl_value_parm_die_table)
>  vec_alloc (tmpl_value_parm_die_table, 32);
>  
> @@ -22120,6 +22128,8 @@ schedule_generic_params_dies_gen (tree t
>if (!generic_type_p (t))
>  return;
>  
> +  gcc_assert (early_dwarf);
> +
>if (!generic_type_instances)
>  vec_alloc (generic_type_instances, 256);
>  
> @@ -22135,11 +22145,21 @@ gen_remaining_tmpl_value_param_die_attri
>  {
>if (tmpl_value_parm_die_table)
>  {
> -  unsigned i;
> +  unsigned i, j;
>die_arg_entry *e;
>  
> +  /* We do this in two phases - first get the cases we can
> +  handle during early-finish, preserving those we cannot
> +  (containing symbolic constants where we don't yet know
> +  whether we are going to output the referenced symbols).
> +  For those we try again at late-finish.  */
> +  j = 0;
>FOR_EACH_VEC_ELT (*tmpl_value_parm_die_table, i, e)
> - tree_add_const_value_attribute (e->die, e->arg);
> + {
> +   if (!tree_add_const_value_attribute (e->die, e->arg))
> + (*tmpl_value_parm_die_table)[j++] = *e;
> + }
> +  tmpl_value_parm_die_table->truncate (j);
>  }
>  }
>  
> @@ -22157,9 +22177,15 @@ gen_scheduled_generic_parms_dies (void)
>if (!generic_type_instances)
>  return;
>
> +  /* We end up "recursing" into schedule_generic_params_dies_gen, so
> + pretend this generation is part of "early dwarf" as well.  */
> +  set_early_dwarf s;
> +
>FOR_EACH_VEC_ELT (*generic_type_instances, i, t)
>  if (COMPLETE_TYPE_P (t))
>gen_generic_params_dies (t);
> +
> +  generic_type_instances = NULL;
>  }
>  
>  
> @@ -25193,7

[gomp4] Break out dimension checking

[Nathan Sidwell]

I've applied this patch, which breaks out the offload function dimension 
checking to a separate function.  I'll be making use of that shortly, and 
execute_oacc_transform was getting unnecessarily large.


nathan
2015-09-16  Nathan Sidwell  

	* omp-low.c (oacc_validate_dims): New function, broken out of ...
	(execute_oacc_transform): ... here.  Call it.

Index: gcc/omp-low.c
===
--- gcc/omp-low.c	(revision 227792)
+++ gcc/omp-low.c	(working copy)
@@ -14789,6 +14985,64 @@ oacc_xform_dim (gimple stmt, const int d
   gsi_replace (&gsi, g, false);
 }
 
+/* Validate and update the dimensions for offloaded FN.  ATTRS is the
+   raw attribute.  DIMS is an array of dimensions, which is returned.
+   Returns the function level dimensionality --  the level at which an
+   offload routine wishes to partition a loop.  */
+
+static int
+oacc_validate_dims (tree fn, tree attrs, int *dims)
+{
+  tree purpose[GOMP_DIM_MAX];
+  unsigned ix;
+  tree pos = TREE_VALUE (attrs);
+  int fn_level = -1;
+
+  /* Make sure the attribute creator attached the dimension
+ information.  */
+  gcc_assert (pos);
+
+  for (ix = 0; ix != GOMP_DIM_MAX; ix++)
+{
+  purpose[ix] = TREE_PURPOSE (pos);
+
+  if (purpose[ix])
+	{
+	  if (integer_zerop (purpose[ix]))
+	fn_level = ix + 1;
+	  else if (fn_level < 0)
+	fn_level = ix;
+	}
+
+  tree val = TREE_VALUE (pos);
+  dims[ix] = val ? TREE_INT_CST_LOW (val) : -1;
+  pos = TREE_CHAIN (pos);
+}
+
+  bool changed = targetm.goacc.validate_dims (fn, dims, fn_level);
+
+  /* Default anything left to 1.  */
+  for (ix = 0; ix != GOMP_DIM_MAX; ix++)
+if (dims[ix] < 0)
+  {
+	dims[ix] = 1;
+	changed = true;
+  }
+
+  if (changed)
+{
+  /* Replace the attribute with new values.  */
+  pos = NULL_TREE;
+  for (ix = GOMP_DIM_MAX; ix--;)
+	pos = tree_cons (purpose[ix],
+			 build_int_cst (integer_type_node, dims[ix]),
+			 pos);
+  replace_oacc_fn_attrib (fn, pos);
+}
+
+  return fn_level;
+}
+
 /* Main entry point for oacc transformations which run on the device
compiler after LTO, so we know what the target device is at this
point (including the host fallback).  */
@@ -14799,67 +15053,18 @@ execute_oacc_transform ()
   basic_block bb;
   tree attrs = get_oacc_fn_attrib (current_function_decl);
   int dims[GOMP_DIM_MAX];
-  tree purpose[GOMP_DIM_MAX];
   bool needs_rescan;
   
   if (!attrs)
 /* Not an offloaded function.  */
 return 0;
 
+  oacc_validate_dims (current_function_decl, attrs, dims);
+  
   /* Offloaded targets may introduce new basic blocks, which require
  dominance information to update SSA.  */
   calculate_dominance_info (CDI_DOMINATORS);
 
-  {
-unsigned ix;
-tree pos = TREE_VALUE (attrs);
-int fn_level = -1;
-
-/* Make sure the attribute creator attached the dimension
-   information.  */
-gcc_assert (pos);
-
-for (ix = 0; ix != GOMP_DIM_MAX; ix++)
-  {
-	purpose[ix] = TREE_PURPOSE (pos);
-
-	if (purpose[ix])
-	  {
-	if (integer_zerop (purpose[ix]))
-	  fn_level = ix + 1;
-	else if (fn_level < 0)
-	  fn_level = ix;
-	  }
-	
-	tree val = TREE_VALUE (pos);
-
-	dims[ix] = val ? TREE_INT_CST_LOW (val) : -1;
-	pos = TREE_CHAIN (pos);
-  }
-
-bool changed = targetm.goacc.validate_dims (current_function_decl,
-		dims, fn_level);
-
-/* Default anything left to 1.  */
-for (ix = 0; ix != GOMP_DIM_MAX; ix++)
-  if (dims[ix] < 0)
-	{
-	  dims[ix] = 1;
-	  changed = true;
-	}
-
-if (changed)
-  {
-	/* Replace the attribute with new values.  */
-	pos = NULL_TREE;
-	for (ix = GOMP_DIM_MAX; ix--;)
-	  pos = tree_cons (purpose[ix],
-			   build_int_cst (integer_type_node, dims[ix]),
-			   pos);
-	replace_oacc_fn_attrib (current_function_decl, pos);
-  }
-  }
-
   do
 {
   needs_rescan = false;

Re: [RFC] Masking vectorized loops with bound not aligned to VF.

[Richard Biener]

On Mon, 14 Sep 2015, Kirill Yukhin wrote:

> Hello,
> I'd like to initiate discussion on vectorization of loops which 
> boundaries are not aligned to VF. Main target for this optimization 
> right now is x86's AVX-512, which features per-element embedded masking 
> for all instructions. The main goal for this mail is to agree on overall 
> design of the feature.
> 
> This approach was presented @ GNU Cauldron 2015 by Ilya Enkovich [1].
>  
> Here's a sketch of the algorithm:
>   1. Add check on basic stmts for masking: possibility to introduce index 
> vector and
>  corresponding mask
>   2. At the check if statements are vectorizable we additionally check if 
> stmts 
>  need and can be masked and compute masking cost. Result is stored in 
> `stmt_vinfo`.
>  We are going  to mask only mem. accesses, reductions and modify mask for 
> already 
>  masked stmts (mask load, mask store and vect. condition)

I think you also need to mask divisions (for integer divide by zero) and
want to mask FP ops which may result in NaNs or denormals (because that's 
generally to slow down execution a lot in my experience).

Why not simply mask all stmts?

>   3. Make a decision about masking: take computed costs and est. iterations 
> count
>  into consideration
>   4. Modify prologue/epilogue generation according decision made at analysis. 
> Three
>  options available:
> a. Use scalar remainder
> b. Use masked remainder. Won't be supported in first version
> c. Mask main loop
>   5.Support vectorized loop masking: 
> - Create stmts for mask generation
> - Support generation of masked vector code (create generic vector code 
> then
>   patch it w/ masks)
>   -  Mask loads/stores/vconds/reductions only
>
>  In first version (targeted v6) we're not going to support 4.b and loop 
> mask pack/unpack. No `pack/unpack` means that masking will be supported 
> only for types w/ the same size as index variable

This means that if ncopies for any stmt is > 1 masking won't be supported,
right?  (you'd need two or more different masks)

>  
> [1] - 
> https://gcc.gnu.org/wiki/cauldron2015?action=AttachFile&do=view&target=Vectorization+for+Intel+AVX-512.pdf
> 
> What do you think?

There was the idea some time ago to use single-iteration vector
variants for prologues/epilogues by simply overlapping them with
the vector loop (and either making sure to mask out the overlap
area or make sure the result stays the same).  This kind-of is
similar to 4b and thus IMHO it's better to get 4b implemented
rather than trying 4c.  So for example

 int a[];
 for (i=0; i < 13; ++i)
   a[i] = i;

would be vectorized (with v4si) as

 for (i=0; i < 13 / 4; ++i)
   ((v4si *)a)[i] = { ... };
 *(v4si *)(&a[9]) = { ... };

where the epilogue store of course would be unaligned.  The masked
variant can avoid the data pointer adjustment and instead use a masked
store.

OTOH it might be that the unaligned scheme is as efficient as the
masked version.  Only the masked version is more trivially correct,
data dependences can make the above idea not work without masking
out stores like for

 for (i=0; i < 13; ++i)
   a[i] = a[i+1];

obviously the overlapping iterations in the epilogue would
compute bogus values.  To avoid this we can merge the result
with the previously stored values (using properly computed masks)
before storing it.

Basically both 4b and the above idea need to peel a vector
iteration and "modify" it.  The same trick can be applied to
prologue loops of course.

Any chance you can try working on 4b instead?  It also feels
like it would need less hacks throughout the vectorizer
(basically post-processing the generated vector loop).

If 4b is implemented I don't think 4c is worth doing.

Thanks,
Richard.

Re: [PATCH GCC][rework]Improve loop bound info by simplifying conversions in iv base

[Richard Biener]

On Tue, Sep 15, 2015 at 7:57 AM, Bin.Cheng  wrote:
> Ping.

Ok.

Thanks,
Richard.

> On Thu, Aug 27, 2015 at 5:41 PM, Bin Cheng  wrote:
>> Hi,
>> This is a rework for
>> https://gcc.gnu.org/ml/gcc-patches/2015-07/msg02335.html, with review
>> comments addressed.  For now, SCEV may compute iv base in the form of
>> "(signed T)((unsigned T)base + step))".  This complicates other
>> optimizations/analysis depending on SCEV because it's hard to dive into type
>> conversions.  This kind of type conversions can be simplified with
>> additional range information implied by loop initial conditions.  This patch
>> does such simplification.
>> With simplified iv base, loop niter analysis can compute more accurate bound
>> information since sensible value range can be derived for "base+step".  For
>> example, accurate loop bound&may_be_zero information is computed for cases
>> added by this patch.
>>
>> The code is actually moved from loop_exits_before_overflow.  After this
>> patch, the corresponding code in loop_exits_before_overflow will be never
>> executed, so I removed that part code.  The patch also includes some code
>> format changes.
>>
>> Bootstrap and test on x86_64.  Is it OK?
>>
>> Thanks,
>> bin
>>
>> 2015-08-27  Bin Cheng  
>>
>> * tree-ssa-loop-niter.c (tree_simplify_using_condition_1): Support
>> new parameter.
>> (tree_simplify_using_condition): Ditto.
>> (simplify_using_initial_conditions): Ditto.
>> (loop_exits_before_overflow): Pass new argument to function
>> simplify_using_initial_conditions.  Remove case for type conversions
>> simplification.
>> * tree-ssa-loop-niter.h (simplify_using_initial_conditions): New
>> parameter.
>> * tree-scalar-evolution.c (simple_iv): Simplify type conversions
>> in iv base using loop initial conditions.
>>
>> gcc/testsuite/ChangeLog
>> 2015-08-27  Bin Cheng  
>>
>> * gcc.dg/tree-ssa/loop-bound-2.c: New test.
>> * gcc.dg/tree-ssa/loop-bound-4.c: New test.
>> * gcc.dg/tree-ssa/loop-bound-6.c: New test.

Re: Fix 61441

[Sujoy Saraswati]

Hi,

>> I'll leave the correctness part of the patch to Joseph who knows FP
>> arithmetic better than me,
>> implementation-wise this is ok if you fix the REAL_CST sharing issue.

Ok, will change this.

> Changing fold_abs_const is wrong - abs of sNaN is sNaN, no exceptions
> raised.  Changing real_arithmetic is wrong for the NEGATE_EXPR and
> ABS_EXPR cases, both of which should just affect the sign bit without
> quieting sNaNs.

Right, I had thought unary operators will be similar to binary
operators for this. Will fix this.

> All the comments in the patch should end with ".  " (full stop, two
> spaces).

Ok.

> If -fsignaling-nans, then folding of expressions involving sNaNs should be
> disabled, outside of static initializers - such expressions should not get
> folded to return an sNaN (it's incorrect to fold sNaN + 1 to sNaN, for
> example).  I think existing code may ensure that (the HONOR_SNANS check in
> const_binop, for example).

Yes, with -fsignaling-nans, the const_binop will not fold since the
HONOR_SNANS check is there. However, elsewhere, like const_unop, the
code doesn't do this check.

> Inside static initializers, expressions involving sNaNs still need to be
> folded (so sNaN + 1 becomes qNaN inside such an initializer, for example,
> with the translation-time exception being discarded).  Again, existing
> code should handle this: START_FOLD_INIT / END_FOLD_INIT already handle
> clearing and restoring flag_signaling_nans.

Yes.

> My understanding of the design of the existing code is that real.c will do
> the arithmetic regardless of whether it might raise an exception or have
> rounding-mode-dependent results, with fold-const.c being responsible for
> deciding whether the result can be used to fold the expression in
> question.  That is, you shouldn't need any flag_signaling_nans conditions
> in real.c; rather, if IEEE semantics mean an sNaN is quieted, real.c
> should do so unconditionally.  It should be the callers in fold-const.c
> that check HONOR_SNANS and disallow folding when it would lose exceptions.

I had added the flag_signaling_nans condition within real.c so that
the callers can do the folding, with the sNaN value converted to qNaN.
However, as you mention, the real.c design should do this irrespective
of the signaling flag and leave it for the callers to disallow the
folding.

I will make the modifications and post a patch.

Regards,
Sujoy

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

Re: dejagnu version update?

[Matthias Klose]

On 09/15/2015 09:23 PM, Bernhard Reutner-Fischer wrote:
> On September 15, 2015 7:39:39 PM GMT+02:00, Mike Stump 
>  wrote:
>> On Sep 14, 2015, at 3:37 PM, Jeff Law  wrote:
 Maybe GCC-6 can bump the required
 dejagnu version to allow for getting rid of all these superfluous
 load_gcc_lib? *blink* :)
>>> I'd support that as a direction.
>>>
>>> Certainly dropping the 2001 version from our website in favor of 1.5
>> (which is what I'm using anyway) would be a step forward.
>>
>> So, even ubuntu LTS is 1.5 now.  No harm in upgrading the website to
>> 1.5.  I don’t know of any reason to not update and just require 1.5 at
>> this point.  I’m not a fan of feature chasing dejagnu, but an update
>> every 2-4 years isn’t unreasonable.
>>
>> So, let’s do it this way…  Any serious and compelling reason to not
>> update to 1.5?  If none, let’s update to 1.5 in another week or two, if
>> no serious and compelling reasons not to.
>>
>> My general plan is, slow cycle updates on dejagnu, maybe every 2 years.
>> LTS style releases should have the version in it before the requirement
>> is updated.  I take this approach as I think this should be the maximal
>> change rate of things like make, gcc, g++, ld, if possible.
> 
> Yea, although this means that 1.5.3 (a Version with the libdirs tweak) being 
> just 5 months old will have to wait another bump, I fear. For my part going 
> to plain 1.5 is useless WRT the load_lib situation. I see no value in 
> conditionalizing simplified libdir handling on a lucky user with recentish 
> stuff so i'm just waiting another 2 or 4 years for this very minor cleanup.

is this libdirs tweak backportable to 1.5.1 (Debian stable), or 1.5 (Ubuntu 
LTS)?

Re: [PATCH WIP] Use Levenshtein distance for various misspellings in C frontend v2

[Michael Matz]

Hi,

On Wed, 16 Sep 2015, Richard Biener wrote:

> Btw, this looks quite expensive - I'm sure we want to limit the effort
> here a bit.

I'm not so sure.  It's only used for printing an error, so walking all 
available decls is expensive but IMHO not too much so.

> I don't want us to suggest using 'i' instead of j (a good hint is that I 
> used 'j' multiple times).

Well, there will always be cases where the suggestion is actually wrong.  
How do you propose to deal with this?  The above case could be solved by 
not giving hints when the levenshtein distance is as long as the string 
length (which makes sense, because then there's no relation at all between 
the string and the suggestion).

> So while the idea might be an improvement to selected cases it can cause 
> confusion as well.  And if using the suggestion for further parsing it 
> can cause worse followup errors (unless we can limit such "fixup" use to 
> the cases where we can parse the result without errors).  Consider
> 
> foo()
> {
>   foz = 1;
> }
> 
> if we suggest 'foo' instead of foz then we'll get a more confusing followup
> error if we actually use it.

This particular case could be solved by ruling out candidaten of the wrong 
kind (here, something that can be assigned to, vs. a function).  But it 
might actually be too early in parsing to say that there will be an 
assignment.  I don't think _this_ problem should block the patch.


Ciao,
Michael.

Re: [PATCH WIP] Use Levenshtein distance for various misspellings in C frontend v2

[Richard Biener]

On Wed, Sep 16, 2015 at 3:22 PM, Michael Matz  wrote:
> Hi,
>
> On Wed, 16 Sep 2015, Richard Biener wrote:
>
>> Btw, this looks quite expensive - I'm sure we want to limit the effort
>> here a bit.
>
> I'm not so sure.  It's only used for printing an error, so walking all
> available decls is expensive but IMHO not too much so.

Well, as we're not stopping at the very first error creating an
artificial testcase
that hits this quite badly should be possible.  Maybe only try this for
the first error and not for followups?

>> I don't want us to suggest using 'i' instead of j (a good hint is that I
>> used 'j' multiple times).
>
> Well, there will always be cases where the suggestion is actually wrong.
> How do you propose to deal with this?  The above case could be solved by
> not giving hints when the levenshtein distance is as long as the string
> length (which makes sense, because then there's no relation at all between
> the string and the suggestion).
>
>> So while the idea might be an improvement to selected cases it can cause
>> confusion as well.  And if using the suggestion for further parsing it
>> can cause worse followup errors (unless we can limit such "fixup" use to
>> the cases where we can parse the result without errors).  Consider
>>
>> foo()
>> {
>>   foz = 1;
>> }
>>
>> if we suggest 'foo' instead of foz then we'll get a more confusing followup
>> error if we actually use it.
>
> This particular case could be solved by ruling out candidaten of the wrong
> kind (here, something that can be assigned to, vs. a function).  But it
> might actually be too early in parsing to say that there will be an
> assignment.  I don't think _this_ problem should block the patch.

I wonder if we can tentatively parse with the choice at hand, only allowing
(and even suggesting?) it if that works out.

Richard.

>
> Ciao,
> Michael.

Re: (patch,rfc) s/gimple/gimple */

[Richard Biener]

On Wed, Sep 16, 2015 at 3:16 PM, Trevor Saunders  wrote:
> Hi,
>
> I gave changing from gimple to gimple * a shot last week.  It turned out
> to be not too hard.  As you might expect the patch is huge so its
> attached compressed.

A quick skim over it makes it look good.

> patch was bootstrapped + regtested on x86_64-linux-gnu, and run through
> config-list.mk.  However I needed to update it some for changes made
> while testing.  Do people want to make this change now?  If so I'll try
> and commit the patch over the weekend when less is changing.

I'm in favor of doing it now.

Thanks,
Richard.

> Trev
>
>

Re: [PATCH v2][GCC] Algorithmic optimization in match and simplify

[Andre Vieira]

On 03/09/15 12:11, Andre Vieira wrote:

On 01/09/15 15:01, Richard Biener wrote:

On Tue, Sep 1, 2015 at 3:40 PM, Andre Vieira
 wrote:

Hi Marc,

On 28/08/15 19:07, Marc Glisse wrote:


(not a review, I haven't even read the whole patch)

On Fri, 28 Aug 2015, Andre Vieira wrote:


2015-08-03  Andre Vieira  

* match.pd: Added new patterns:
  ((X {&,<<,>>} C0) {|,^} C1) {^,|} C2)
  (X {|,^,&} C0) {<<,>>} C1 -> (X {<<,>>} C1) {|,^,&} (C0 {<<,>>} C1)



+(for op0 (rshift rshift lshift lshift bit_and bit_and)
+ op1 (bit_ior bit_xor bit_ior bit_xor bit_ior bit_xor)
+ op2 (bit_xor bit_ior bit_xor bit_ior bit_xor bit_ior)

You can nest for-loops, it seems clearer as:
(for op0 (rshift lshift bit_and)
 (for op1 (bit_ior bit_xor)
  op2 (bit_xor bit_ior)



Will do, thank you for pointing it out.



+(simplify
+ (op2:c
+  (op1:c
+   (op0 @0 INTEGER_CST@1) INTEGER_CST@2) INTEGER_CST@3)

I suspect you will want more :s (single_use) and less :c (canonicalization
should put constants in second position).


I can't find the definition of :s (single_use).


Sorry for that - didn't get along updating it yet :/  It restricts matching to
sub-expressions that have a single-use.  So

+  a &= 0xd123;
+  unsigned short tem = a ^ 0x6040;
+  a = tem | 0xc031; /* Simplify _not_ to ((a & 0xd123) | 0xe071).  */
... use of tem ...

we shouldn't do the simplifcation here because the expression
(a & 0x123) ^ 0x6040 is kept live by 'tem'.


GCC internals do point out
that canonicalization does put constants in the second position, didnt see
that first. Thank you for pointing it out.


+   C1 = wi::bit_and_not (C1,C2);

Space after ','.


Will do.


Having wide_int_storage in many places is surprising, I can't find similar
code anywhere else in gcc.




I tried looking for examples of something similar, I think I ended up using
wide_int because I was able to convert easily to and from it and it has the
"mask" and "wide_int_to_tree" functions. I welcome any suggestions on what I
should be using here for integer constant transformations and comparisons.


Using wide-ints is fine, but you shouldn't need 'wide_int_storage'
constructors - those
are indeed odd.  Is it just for the initializers of wide-ints?

+wide_int zero_mask = wi::zero (prec);
+wide_int C0 = wide_int_storage (@1);
+wide_int C1 = wide_int_storage (@2);
+wide_int C2 = wide_int_storage (@3);
...
+   zero_mask = wide_int_storage (wi::mask (C0.to_uhwi (), false, prec));

tree_to_uhwi (@1) should do the trick as well

+   C1 = wi::bit_and_not (C1,C2);
+   cst_emit = wi::bit_or (C1, C2);

the ops should be replacable with @2 and @3, the store to C1 obviously not
(but you can use a tree temporary and use wide_int_to_tree here to avoid
the back-and-forth for the case where C1 is not assigned to).

Note that transforms only doing association are prone to endless recursion
in case some other pattern does the reverse op...

Richard.



BR,
Andre




Thank you for all the comments, see reworked version:

Two new algorithmic optimisations:
1.((X op0 C0) op1 C1) op2 C2)
  with op0 = {&, >>, <<}, op1 = {|,^}, op2 = {|,^} and op1 != op2
  zero_mask has 1's for all bits that are sure to be 0 in (X op0 C0)
  and 0's otherwise.
  if (op1 == '^') C1 &= ~C2 (Only changed if actually emitted)
  if ((C1 & ~zero_mask) == 0) then emit (X op0 C0) op2 (C1 op2 C2)
  if ((C2 & ~zero_mask) == 0) then emit (X op0 C0) op1 (C1 op2 C2)
2. (X {|,^,&} C0) {<<,>>} C1 -> (X {<<,>>} C1) {|,^,&} (C0 {<<,>>} C1)


This patch does two algorithmic optimisations that target patterns like:
(((x << 24) | 0x00FF) ^ 0xFF00) and ((x ^ 0x4002) >> 1) |
0x8000.

The transformation uses the knowledge of which bits are zero after
operations like (X {&,<<,(unsigned)>>}) to combine constants, reducing
run-time operations.
The two examples above would be transformed into (X << 24) ^ 0x
and (X >> 1) ^ 0xa001 respectively.

The second transformation enables more applications of the first. Also
some targets may benefit from delaying shift operations. I am aware that
such an optimization, in combination with one or more optimizations that
cause the reverse transformation, may lead to an infinite loop. Though
such behavior has not been detected during regression testing and
bootstrapping on aarch64.

gcc/ChangeLog:

2015-08-03  Andre Vieira  

* match.pd: Added new patterns:
  ((X {&,<<,>>} C0) {|,^} C1) {^,|} C2)
  (X {|,^,&} C0) {<<,>>} C1 -> (X {<<,>>} C1) {|,^,&} (C0 {<<,>>} C1)

gcc/testsuite/ChangeLog:

2015-08-03  Andre Vieira  
  Hale Wang  

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



Ping.

Re: [C++] Coding rule enforcement

[Jason Merrill]

On 09/16/2015 08:02 AM, Nathan Sidwell wrote:

+  else if (warn_multiple_inheritance)
+   warning (OPT_Wmultiple_inheritance,
+"%qT defined with multiple direct bases", ref);


You don't need to guard the warning with a check of the warning flag; 
warning will only give the warning if the option is enabled.


Jason

[PATCH] Fix PR67271

[Richard Biener]

Bootstrapped / tested on x86_64-unknown-linux-gnu, applied.

Richard.

2015-09-16  Richard Biener  

PR middle-end/67271
* fold-const.c (native_encode_expr): Bail out on bogus offsets.

* gcc.dg/pr67271.c: New testcase.

Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 227779)
+++ gcc/fold-const.c(working copy)
@@ -7106,6 +7127,10 @@ native_encode_string (const_tree expr, u
 int
 native_encode_expr (const_tree expr, unsigned char *ptr, int len, int off)
 {
+  /* We don't support starting at negative offset and -1 is special.  */
+  if (off < -1)
+return 0;
+
   switch (TREE_CODE (expr))
 {
 case INTEGER_CST:
Index: gcc/testsuite/gcc.dg/pr67271.c
===
--- gcc/testsuite/gcc.dg/pr67271.c  (revision 0)
+++ gcc/testsuite/gcc.dg/pr67271.c  (working copy)
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-O" } */
+
+extern long int labs (long int j);
+int
+main ()
+{
+  long *a = (long *)"empty";
+  int i = 1441516387;
+  a[i] = labs (a[i]);
+  return 0;
+}

[PATCH] Fix 67064 - Register asm variable broken

[Andres Tiraboschi]

Hi, this patch fix the following bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064 for gcc 5.2

It passes all the gcc tests except for this:
FAIL: g++.dg/cpp1y/auto-fn15.C  -std=gnu++14 (test for excess errors)

but this also happens without the patch.

This patch was implemented for gcc 5.2

changelog:


diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 949225b..62b8c2a 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -5131,8 +5131,6 @@ build_conditional_expr_1 (location_t loc, tree
arg1, tree arg2, tree arg3,
  lvalue, we must add a NON_LVALUE_EXPR.  */
   result = rvalue (result);
 }
-  else
-result = force_paren_expr (result);

   return result;
 }
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 4e525e0..1f802b0 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -5933,7 +5933,6 @@ extern tree finish_asm_stmt(int,
tree, tree, tree, tree,
 extern tree finish_label_stmt(tree);
 extern void finish_label_decl(tree);
 extern tree finish_parenthesized_expr(tree);
-extern tree force_paren_expr(tree);
 extern tree finish_non_static_data_member   (tree, tree, tree);
 extern tree begin_stmt_expr(void);
 extern tree finish_stmt_expr_expr(tree, tree);
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 82ef642..005262d 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -1642,26 +1642,9 @@ finish_mem_initializers (tree mem_inits)
 emit_mem_initializers (mem_inits);
 }

-/* Obfuscate EXPR if it looks like an id-expression or member access so
-   that the call to finish_decltype in do_auto_deduction will give the
-   right result.  */
-
-tree
-force_paren_expr (tree expr)
+static void
+check_paren_expr(tree expr)
 {
-  /* This is only needed for decltype(auto) in C++14.  */
-  if (cxx_dialect < cxx14)
-return expr;
-
-  /* If we're in unevaluated context, we can't be deducing a
- return/initializer type, so we don't need to mess with this.  */
-  if (cp_unevaluated_operand)
-return expr;
-
-  if (!DECL_P (expr) && TREE_CODE (expr) != COMPONENT_REF
-  && TREE_CODE (expr) != SCOPE_REF)
-return expr;
-
   if (TREE_CODE (expr) == COMPONENT_REF)
 REF_PARENTHESIZED_P (expr) = true;
   else if (type_dependent_expression_p (expr))
@@ -1672,7 +1655,7 @@ force_paren_expr (tree expr)
   if ((kind & ~clk_class) != clk_none)
 {
   tree type = unlowered_expr_type (expr);
-  bool rval = !!(kind & clk_rvalueref);
+  bool rval = (kind & clk_rvalueref);
   type = cp_build_reference_type (type, rval);
   /* This inhibits warnings in, eg, cxx_mark_addressable
  (c++/60955).  */
@@ -1682,10 +1665,7 @@ force_paren_expr (tree expr)
 REF_PARENTHESIZED_P (expr) = true;
 }
 }
-
-  return expr;
 }
-
 /* Finish a parenthesized expression EXPR.  */

 tree
@@ -1704,8 +1684,6 @@ finish_parenthesized_expr (tree expr)
   if (TREE_CODE (expr) == STRING_CST)
 PAREN_STRING_LITERAL_P (expr) = 1;

-  expr = force_paren_expr (expr);
-
   return expr;
 }

@@ -7369,7 +7347,10 @@ finish_decltype_type (tree expr, bool
id_expression_or_member_access_p,
 type = strip_typedefs (type);

   if (clk != clk_none && !(clk & clk_class))
+  {
+check_paren_expr(expr);
 type = cp_build_reference_type (type, (clk & clk_rvalueref));
+  }
 }
 }

[PATCH, rs6000] Add expansions for min/max vector reductions

[Bill Schmidt]

Hi,

A recent patch proposal from Alan Hayward
(https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00690.html) uncovered
that the PowerPC back end doesn't have expansions for
reduc_{smax,smin,umax,umin}_ and
reduc_{smax,smin,umax,umin}_scal_ for the integer modes.  This
prevents vectorization of reductions involving comparisons that can be
transformed into REDUC_{MAX,MIN}_EXPR expressions.  This patch adds
these expansions.

PowerPC does not have hardware reduction instructions for maximum and
minimum.  However, we can emulate this with varying degrees of
efficiency for different modes.  The size of the expansion is
logarithmic in the number of vector elements E.  The expansions for
reduc_{smax,smin,umax,umin}_ consist of log E stages, each
comprising a rotate operation and a maximum or minimum operation.  After
stage N, the maximum value in the vector will appear in at least 2^N
consecutive positions in the intermediate result.

The ...scal_ expansions just invoke the related non-scalar
expansions, and then extract an arbitrary element from the result
vector.

The expansions for V16QI, V8HI, and V4SI require TARGET_ALTIVEC.  The
expansions for V2DI make use of vector instructions added for ISA 2.07,
so they require TARGET_P8_VECTOR.

I was able to use iterators for the sub-doubleword ...scal_
expansions, but that's all.  I experimented with trying to use
code_iterators to generate the {smax,smin,umax,umin} expansions, but
couldn't find a way to make that work, as the substitution wasn't being
done into the UNSPEC constants.  If there is a way to do this, please
let me know and I'll try to reduce the code size.

There are already a number of common reduction execution tests that
exercise this logic.  I've also added PowerPC-specific code generation
tests to verify the patterns produce what's expected.  These are based
on the existing execution tests.

Some future work will be required:

(1) The vectorization cost model does not currently allow us to
distinguish between reductions of additions and reductions of max/min.
On PowerPC, these costs are very different, as the former is supported
by hardware and the latter is not.  After this patch is applied, we will
possibly vectorize some code when it's not profitable to do so.  I think
it's probably best to go ahead with this patch now, and deal with the
cost model as a separate issue after Alan's patch is complete and
upstream.

(2) The use of rs6000_expand_vector_extract to obtain a scalar from a
vector is not optimal for sub-doubleword modes using the latest
hardware.  Currently this generates a vector store followed by a scalar
load, which is Very Bad.  We should instead use a mfvsrd and sign- or
zero-extend the rightmost element in the result GPR.  To accomplish
this, we should update rs6000_expand_vector_extract to do the more
general thing:  mfvsrd, shift the selected element into the rightmost
position, and extend it.  At that time we should change the _scal_
expansions to select the element number that avoids the shift (that
number will differ for BE and LE).

Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
regressions.  Is this ok for trunk?

Thanks,
Bill


[gcc]

2015-09-16  Bill Schmidt  

* config/rs6000/altivec.md (UNSPEC_REDUC_SMAX, UNSPEC_REDUC_SMIN,
UNSPEC_REDUC_UMAX, UNSPEC_REDUC_UMIN, UNSPEC_REDUC_SMAX_SCAL,
UNSPEC_REDUC_SMIN_SCAL, UNSPEC_REDUC_UMAX_SCAL,
UNSPEC_REDUC_UMIN_SCAL): New enumerated constants.
(reduc_smax_v2di): New define_expand.
(reduc_smax_scal_v2di): Likewise.
(reduc_smin_v2di): Likewise.
(reduc_smin_scal_v2di): Likewise.
(reduc_umax_v2di): Likewise.
(reduc_umax_scal_v2di): Likewise.
(reduc_umin_v2di): Likewise.
(reduc_umin_scal_v2di): Likewise.
(reduc_smax_v4si): Likewise.
(reduc_smin_v4si): Likewise.
(reduc_umax_v4si): Likewise.
(reduc_umin_v4si): Likewise.
(reduc_smax_v8hi): Likewise.
(reduc_smin_v8hi): Likewise.
(reduc_umax_v8hi): Likewise.
(reduc_umin_v8hi): Likewise.
(reduc_smax_v16qi): Likewise.
(reduc_smin_v16qi): Likewise.
(reduc_umax_v16qi): Likewise.
(reduc_umin_v16qi): Likewise.
(reduc_smax_scal_): Likewise.
(reduc_smin_scal_): Likewise.
(reduc_umax_scal_): Likewise.
(reduc_umin_scal_): Likewise.

[gcc/testsuite]

2015-09-16  Bill Schmidt  

* gcc.target/powerpc/vect-reduc-minmax-char.c: New.
* gcc.target/powerpc/vect-reduc-minmax-short.c: New.
* gcc.target/powerpc/vect-reduc-minmax-int.c: New.
* gcc.target/powerpc/vect-reduc-minmax-long.c: New.


Index: gcc/config/rs6000/altivec.md
===
--- gcc/config/rs6000/altivec.md(revision 227817)
+++ gcc/config/rs6000/altivec.md(working copy)
@@ -87,6 +87,14 @@
UNSPEC_GET_VRSAVE
UNSPEC_LVX
UNSPEC_REDUC_PLUS
+   UNSPEC_RED

[PATCH] Fix PR67253

[Richard Biener]

Bootstrapped / tested on x86_64-unknown-linux-gnu, applied.

Richard.

2015-09-16  Richard Biener  

PR middle-end/67253
* cfgexpand.c (expand_gimple_stmt_1): Do not clobber
location of possibly shared trees.

* gcc.dg/torture/pr67253.c: New testcase.

Index: gcc/cfgexpand.c
===
--- gcc/cfgexpand.c (revision 227779)
+++ gcc/cfgexpand.c (working copy)
@@ -3587,7 +3587,9 @@ expand_gimple_stmt_1 (gimple stmt)
tree rhs = gimple_assign_rhs1 (assign_stmt);
gcc_assert (get_gimple_rhs_class (gimple_expr_code (stmt))
== GIMPLE_SINGLE_RHS);
-   if (gimple_has_location (stmt) && CAN_HAVE_LOCATION_P (rhs))
+   if (gimple_has_location (stmt) && CAN_HAVE_LOCATION_P (rhs)
+   /* Do not put locations on possibly shared trees.  */
+   && !is_gimple_min_invariant (rhs))
  SET_EXPR_LOCATION (rhs, gimple_location (stmt));
if (TREE_CLOBBER_P (rhs))
  /* This is a clobber to mark the going out of scope for
Index: gcc/testsuite/gcc.dg/torture/pr67253.c
===
--- gcc/testsuite/gcc.dg/torture/pr67253.c  (revision 0)
+++ gcc/testsuite/gcc.dg/torture/pr67253.c  (working copy)
@@ -0,0 +1,62 @@
+/* { dg-do run } */
+
+int *a, b, c, **d = &a, e, f, **h, i, j, k, l, m, *n, o, **q, r, s;
+
+void fn1 (int p) { }
+
+void
+fn3 ()
+{
+  for (; j; j++)
+for (; k; k++)
+  l++;
+  f++;
+}
+
+static int
+fn4 (char p1, int *p2)
+{
+  for (; m < 1;)
+{
+  fn1 (q == &p2);
+  for (; o; o++)
+   ;
+  n = p2;
+  return 0;
+}
+  for (;;)
+{
+  for (; s; s++)
+   b = r;
+  *d = 0;
+}
+}
+
+static int *fn2 (char, int, int *);
+
+static int
+fn5 ()
+{
+  int *g = &c;
+  fn3 ();
+  fn2 (0, 0, g);
+  return e;
+}
+
+static int *
+fn2 (char p1, int p2, int *p3)
+{
+  fn4 (0, p3);
+  fn1 (&p3 == h);
+  for (; i;)
+fn5 ();
+  fn4 (0, p3);
+  return *d;
+}
+
+int
+main ()
+{
+  fn5 ();
+  return 0;
+}

Re: [AArch64] Implement copysign[ds]f3

[Marcus Shawcroft]

On 16 September 2015 at 08:40, James Greenhalgh
 wrote:
>
> Hi,
>
> This patch adds expanders for copysigndf3 and copysignsf3 to the AArch64
> backend. These use the BSL/BIT/BIF insn to save us from the default
> expansion pattern.
>
> Bootstrapped on aarch64-none-linux-gnu with no issues, and checked
> the performance to show a slight improvement to FP routines using
> copysign or SIGN from fortran.
>
> OK?
>
> Thanks,
> James
>
> ---
> gcc/
>
> 2015-09-16  James Greenhalgh  
>
> * config/aarch64/aarch64.md (copysigndf3): New.
> (copysignsf3): Likewise.
>
> gcc/testsuite/
>
> 2015-09-16  James Greenhalgh  
>
> * gcc.target/aarch64/copysign_1.c: New.
> * gcc.target/aarch64/copysign_2.c: New.
>

OK /Marcus

Re: [PATCH, rs6000] Add expansions for min/max vector reductions

[David Edelsohn]

On Wed, Sep 16, 2015 at 10:28 AM, Bill Schmidt
 wrote:
> Hi,
>
> A recent patch proposal from Alan Hayward
> (https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00690.html) uncovered
> that the PowerPC back end doesn't have expansions for
> reduc_{smax,smin,umax,umin}_ and
> reduc_{smax,smin,umax,umin}_scal_ for the integer modes.  This
> prevents vectorization of reductions involving comparisons that can be
> transformed into REDUC_{MAX,MIN}_EXPR expressions.  This patch adds
> these expansions.
>
> PowerPC does not have hardware reduction instructions for maximum and
> minimum.  However, we can emulate this with varying degrees of
> efficiency for different modes.  The size of the expansion is
> logarithmic in the number of vector elements E.  The expansions for
> reduc_{smax,smin,umax,umin}_ consist of log E stages, each
> comprising a rotate operation and a maximum or minimum operation.  After
> stage N, the maximum value in the vector will appear in at least 2^N
> consecutive positions in the intermediate result.
>
> The ...scal_ expansions just invoke the related non-scalar
> expansions, and then extract an arbitrary element from the result
> vector.
>
> The expansions for V16QI, V8HI, and V4SI require TARGET_ALTIVEC.  The
> expansions for V2DI make use of vector instructions added for ISA 2.07,
> so they require TARGET_P8_VECTOR.
>
> I was able to use iterators for the sub-doubleword ...scal_
> expansions, but that's all.  I experimented with trying to use
> code_iterators to generate the {smax,smin,umax,umin} expansions, but
> couldn't find a way to make that work, as the substitution wasn't being
> done into the UNSPEC constants.  If there is a way to do this, please
> let me know and I'll try to reduce the code size.
>
> There are already a number of common reduction execution tests that
> exercise this logic.  I've also added PowerPC-specific code generation
> tests to verify the patterns produce what's expected.  These are based
> on the existing execution tests.
>
> Some future work will be required:
>
> (1) The vectorization cost model does not currently allow us to
> distinguish between reductions of additions and reductions of max/min.
> On PowerPC, these costs are very different, as the former is supported
> by hardware and the latter is not.  After this patch is applied, we will
> possibly vectorize some code when it's not profitable to do so.  I think
> it's probably best to go ahead with this patch now, and deal with the
> cost model as a separate issue after Alan's patch is complete and
> upstream.
>
> (2) The use of rs6000_expand_vector_extract to obtain a scalar from a
> vector is not optimal for sub-doubleword modes using the latest
> hardware.  Currently this generates a vector store followed by a scalar
> load, which is Very Bad.  We should instead use a mfvsrd and sign- or
> zero-extend the rightmost element in the result GPR.  To accomplish
> this, we should update rs6000_expand_vector_extract to do the more
> general thing:  mfvsrd, shift the selected element into the rightmost
> position, and extend it.  At that time we should change the _scal_
> expansions to select the element number that avoids the shift (that
> number will differ for BE and LE).
>
> Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
> regressions.  Is this ok for trunk?
>
> Thanks,
> Bill
>
>
> [gcc]
>
> 2015-09-16  Bill Schmidt  
>
> * config/rs6000/altivec.md (UNSPEC_REDUC_SMAX, UNSPEC_REDUC_SMIN,
> UNSPEC_REDUC_UMAX, UNSPEC_REDUC_UMIN, UNSPEC_REDUC_SMAX_SCAL,
> UNSPEC_REDUC_SMIN_SCAL, UNSPEC_REDUC_UMAX_SCAL,
> UNSPEC_REDUC_UMIN_SCAL): New enumerated constants.
> (reduc_smax_v2di): New define_expand.
> (reduc_smax_scal_v2di): Likewise.
> (reduc_smin_v2di): Likewise.
> (reduc_smin_scal_v2di): Likewise.
> (reduc_umax_v2di): Likewise.
> (reduc_umax_scal_v2di): Likewise.
> (reduc_umin_v2di): Likewise.
> (reduc_umin_scal_v2di): Likewise.
> (reduc_smax_v4si): Likewise.
> (reduc_smin_v4si): Likewise.
> (reduc_umax_v4si): Likewise.
> (reduc_umin_v4si): Likewise.
> (reduc_smax_v8hi): Likewise.
> (reduc_smin_v8hi): Likewise.
> (reduc_umax_v8hi): Likewise.
> (reduc_umin_v8hi): Likewise.
> (reduc_smax_v16qi): Likewise.
> (reduc_smin_v16qi): Likewise.
> (reduc_umax_v16qi): Likewise.
> (reduc_umin_v16qi): Likewise.
> (reduc_smax_scal_): Likewise.
> (reduc_smin_scal_): Likewise.
> (reduc_umax_scal_): Likewise.
> (reduc_umin_scal_): Likewise.
>
> [gcc/testsuite]
>
> 2015-09-16  Bill Schmidt  
>
> * gcc.target/powerpc/vect-reduc-minmax-char.c: New.
> * gcc.target/powerpc/vect-reduc-minmax-short.c: New.
> * gcc.target/powerpc/vect-reduc-minmax-int.c: New.
> * gcc.target/powerpc/vect-reduc-minmax-long.c: New.

This is okay.

I don't think that I have seen iterato

Re: [C++] Coding rule enforcement

[Nathan Sidwell]

On 09/16/15 10:23, Jason Merrill wrote:

On 09/16/2015 08:02 AM, Nathan Sidwell wrote:

+  else if (warn_multiple_inheritance)
+warning (OPT_Wmultiple_inheritance,
+ "%qT defined with multiple direct bases", ref);


You don't need to guard the warning with a check of the warning flag; warning
will only give the warning if the option is enabled.


hm, it didn't seem to be doing that.  Perhaps  I'd got something wrong 
...looking

Re: [PATCH, rs6000] Add expansions for min/max vector reductions

[Ramana Radhakrishnan]

On Wed, Sep 16, 2015 at 3:34 PM, David Edelsohn  wrote:
> On Wed, Sep 16, 2015 at 10:28 AM, Bill Schmidt

>
> This is okay.
>
> I don't think that I have seen iterators for UNSPECs, but maybe
> someone else is aware of the right idiom.

https://gcc.gnu.org/onlinedocs/gccint/Int-Iterators.html .
define_int_iterator was added precisely for this functionality in the
aarch64 backend.



regards
Ramana

>
> Thanks, David

Re: [patch] libstdc++/67173 Fix filesystem::canonical for Solaris 10.

[Jonathan Wakely]

On 12/09/15 12:07 -0600, Martin Sebor wrote:

On 09/12/2015 04:09 AM, Jonathan Wakely wrote:

On 11 September 2015 at 18:39, Martin Sebor wrote:

On 09/11/2015 08:21 AM, Jonathan Wakely wrote:


Solaris 10 doesn't follow POSIX in accepting a null pointer as the
second argument to realpath(), so allocate a buffer for it.



FWIW, the NULL requirement is new in Issue 7. In Issue 6, the behavior
is implementation-defined, and before then it was an error. Solaris 10
claims conformance to SUSv2 and its realpath fails with EINVAL.
Solaris 11 says it conforms to Issue 6 but according to the man page
its realpath already implements the Issue 7 requirement.


Thanks.


I suspect the same problem will come up on other systems so checking
the POSIX version might be better than testing for each OS.


The problem with doing that is that many BSD systems have supported
passing NULL as an extension long before issue 7, so if we just check
something like _POSIX_VERSION >= 200809L then we can only canonicalize
paths up to PATH_MAX on many systems where the extension is available
but _POSIX_VERSION implies conformance to an older standard.


You're right. I agree that just checking the POSIX version may not
lead to optimal results. Some implementations also support multiple
versions and the one in effect may not be the one most recent. To
get the most out of those, it's usually recommended to set
_POSIX_C_SOURCE to the latest version before including any headers,
then test the supported version, and when the supported version is
less than the one requested and involves implementation defined
behavior (as in Issue 6) or undefined behavior that's known to be
used to provide extensions (as in SUSv2), check the implementation
version just as the patch does.



So maybe we want an autoconf macro saying whether realpath() accepts
NULL, and just hardcode it for the targets known to support it, and
only check _POSIX_VERSION for the unknowns.


That will work for Issue 6 where the realpath behavior is
implementation-defined. The test wouldn't yield reliable results
for SUSv2 implementations where the behavior is undefined. There,
the result would have to be hardcoded based on what the manual says.
An autoconf test won't help with the ENAMETOOLONG problem since it
might depend on the filesystem. To overcome that, libstdc++ would
need to do the path traversal itself.


It turns out I was wrong about BSD traditionally supporting
realpath(path, NULL), it first appeared in these relatively recent
versions:

FreeBSD 9.0
OpenBSD 5.0
NetBSD 6.1

Like Solaris 11, some of them still define _POSIX_VERSION=200112L even
though they support passing NULL, so we could hardcode the targets
that are known to support it, but we'll still need a fallback for lots
of slightly older targets anyway.

So here's a new implementation of canonical() which only uses
realpath() when this autoconf compile-or-link test passes:

#if _XOPEN_VERSION < 500
#error
#elif _XOPEN_VERSION >= 700 || defined(PATH_MAX)
char *tmp = realpath((const char*)NULL, (char*)NULL);
#else
#error
#endif

i.e. I use realpath() for Issue 7, or for Issue 6 if PATH_MAX is
defined.

Then in filesystem::canonical() if _GLIBCXX_USE_REALPATH is set I use
it, passing NULL for Issue 7, or allocating a buffer of PATH_MAX
otherwise. If realpath isn't supported or fails with ENAMETOOLONG then
I do the path traversal by hand (which can be done entirely using the
std::experimental::filesystem operations).

Only passing NULL for Issue 7 is quite conservative. It means we don't
do it for targets that support it as an implementation-defined
extension to Issue 6, which includes Solaris 11, the BSDs and even
older GNU systems (including RHEL6). But that's OK, we have a fallback
now so it means no loss of functionality, just efficiency.  We can
tweak the config later for targets known to handle NULL.

The new testcase is not very thorough. I've run a few more involved
tests that aren't suitable to check in until I figure out a good way
of running filesystem tests that can create/remove arbitrary files and
symlinks.

What do you think?

Tested powerpc64le-linux and x86_64-dragonfly4.2.


commit e79ad2dbcb14d1e66f6edead4ff87b62e575a8e7
Author: Jonathan Wakely 
Date:   Wed Sep 16 14:07:54 2015 +0100

Implement filesystem::canonical() without realpath

	PR libstdc++/67173
	* acinclude.m4 (GLIBCXX_CHECK_FILESYSTEM_DEPS): Check _XOPEN_VERSION
	and PATH_MAX for _GLIBCXX_USE_REALPATH.
	* config.h.in: Regenerate.
	* configure: Regenerate.
	* src/filesystem/dir.cc: Define _XOPEN_VERSION.
	* src/filesystem/ops.cc: Likewise.
	(canonical) [!_GLIBCXX_USE_REALPATH]: Add alternative implementation.
	* testsuite/experimental/filesystem/operations/canonical.cc: New.

diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index 64c9b7e..364a7d2 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -3926,7 +3926,7 @@ dnl
   AC_LANG_SAVE
   AC_LANG_CPLU

Re: [PATCH, rs6000] Add expansions for min/max vector reductions

[Bill Schmidt]

On Wed, 2015-09-16 at 15:37 +0100, Ramana Radhakrishnan wrote:
> On Wed, Sep 16, 2015 at 3:34 PM, David Edelsohn  wrote:
> > On Wed, Sep 16, 2015 at 10:28 AM, Bill Schmidt
> 
> >
> > This is okay.
> >
> > I don't think that I have seen iterators for UNSPECs, but maybe
> > someone else is aware of the right idiom.
> 
> https://gcc.gnu.org/onlinedocs/gccint/Int-Iterators.html .
> define_int_iterator was added precisely for this functionality in the
> aarch64 backend.

Ah, thanks!  Much obliged, Ramana.

Bill

> 
> 
> 
> regards
> Ramana
> 
> >
> > Thanks, David
> 

Re: [PATCH, rs6000] Add expansions for min/max vector reductions

[Segher Boessenkool]

On Wed, Sep 16, 2015 at 09:28:09AM -0500, Bill Schmidt wrote:
> I was able to use iterators for the sub-doubleword ...scal_
> expansions, but that's all.  I experimented with trying to use
> code_iterators to generate the {smax,smin,umax,umin} expansions, but
> couldn't find a way to make that work, as the substitution wasn't being
> done into the UNSPEC constants.  If there is a way to do this, please
> let me know and I'll try to reduce the code size.

Do you need the unspecs at all?  They are only used in the pattern of
expanders, and all such expanders call DONE.  You can instead write
those patterns as just USEs of their operands?


Segher

Re: [PATCH, rs6000] Add expansions for min/max vector reductions

[Bill Schmidt]

On Wed, 2015-09-16 at 10:14 -0500, Segher Boessenkool wrote:
> On Wed, Sep 16, 2015 at 09:28:09AM -0500, Bill Schmidt wrote:
> > I was able to use iterators for the sub-doubleword ...scal_
> > expansions, but that's all.  I experimented with trying to use
> > code_iterators to generate the {smax,smin,umax,umin} expansions, but
> > couldn't find a way to make that work, as the substitution wasn't being
> > done into the UNSPEC constants.  If there is a way to do this, please
> > let me know and I'll try to reduce the code size.
> 
> Do you need the unspecs at all?  They are only used in the pattern of
> expanders, and all such expanders call DONE.  You can instead write
> those patterns as just USEs of their operands?

Hi Segher,

Yes, I had just independently come to the same conclusion -- since we
are always calling DONE, I don't need the UNSPECs at all.  I'm verifying
to be sure, but this should solve my problem.

Thanks!
Bill
> 
> 
> Segher
> 

Re: [PATCH, rs6000] Add expansions for min/max vector reductions

[Alan Lawrence]

On 16/09/15 15:28, Bill Schmidt wrote:

2015-09-16  Bill Schmidt  

 * config/rs6000/altivec.md (UNSPEC_REDUC_SMAX, UNSPEC_REDUC_SMIN,
 UNSPEC_REDUC_UMAX, UNSPEC_REDUC_UMIN, UNSPEC_REDUC_SMAX_SCAL,
 UNSPEC_REDUC_SMIN_SCAL, UNSPEC_REDUC_UMAX_SCAL,
 UNSPEC_REDUC_UMIN_SCAL): New enumerated constants.
 (reduc_smax_v2di): New define_expand.
 (reduc_smax_scal_v2di): Likewise.
 (reduc_smin_v2di): Likewise.
 (reduc_smin_scal_v2di): Likewise.
 (reduc_umax_v2di): Likewise.
 (reduc_umax_scal_v2di): Likewise.
 (reduc_umin_v2di): Likewise.
 (reduc_umin_scal_v2di): Likewise.
 (reduc_smax_v4si): Likewise.
 (reduc_smin_v4si): Likewise.
 (reduc_umax_v4si): Likewise.
 (reduc_umin_v4si): Likewise.
 (reduc_smax_v8hi): Likewise.
 (reduc_smin_v8hi): Likewise.
 (reduc_umax_v8hi): Likewise.
 (reduc_umin_v8hi): Likewise.
 (reduc_smax_v16qi): Likewise.
 (reduc_smin_v16qi): Likewise.
 (reduc_umax_v16qi): Likewise.
 (reduc_umin_v16qi): Likewise.
 (reduc_smax_scal_): Likewise.
 (reduc_smin_scal_): Likewise.
 (reduc_umax_scal_): Likewise.
 (reduc_umin_scal_): Likewise.


You shouldn't need the non-_scal reductions. Indeed, they shouldn't be used if 
the _scal are present. The non-_scal's were previously defined as producing a 
vector with one element holding the result and the other elements all zero, and 
this was only ever used with a vec_extract immediately after; the _scal pattern 
now includes the vec_extract as well. Hence the non-_scal patterns are 
deprecated / considered legacy, as per md.texi.


I proposed a patch to migrate PPC off the old patterns, but have forgotten to 
ping it recently - last at 
https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01024.html ... (ping?!)


--Alan

Re: dejagnu version update?

[Bernhard Reutner-Fischer]

On September 16, 2015 3:01:47 PM GMT+02:00, Matthias Klose  
wrote:
>On 09/15/2015 09:23 PM, Bernhard Reutner-Fischer wrote:
>> On September 15, 2015 7:39:39 PM GMT+02:00, Mike Stump
> wrote:
>>> On Sep 14, 2015, at 3:37 PM, Jeff Law  wrote:
> Maybe GCC-6 can bump the required
> dejagnu version to allow for getting rid of all these superfluous
> load_gcc_lib? *blink* :)
 I'd support that as a direction.

 Certainly dropping the 2001 version from our website in favor of
>1.5
>>> (which is what I'm using anyway) would be a step forward.
>>>
>>> So, even ubuntu LTS is 1.5 now.  No harm in upgrading the website to
>>> 1.5.  I don’t know of any reason to not update and just require 1.5
>at
>>> this point.  I’m not a fan of feature chasing dejagnu, but an update
>>> every 2-4 years isn’t unreasonable.
>>>
>>> So, let’s do it this way…  Any serious and compelling reason to not
>>> update to 1.5?  If none, let’s update to 1.5 in another week or two,
>if
>>> no serious and compelling reasons not to.
>>>
>>> My general plan is, slow cycle updates on dejagnu, maybe every 2
>years.
>>> LTS style releases should have the version in it before the
>requirement
>>> is updated.  I take this approach as I think this should be the
>maximal
>>> change rate of things like make, gcc, g++, ld, if possible.
>> 
>> Yea, although this means that 1.5.3 (a Version with the libdirs
>tweak) being just 5 months old will have to wait another bump, I fear.
>For my part going to plain 1.5 is useless WRT the load_lib situation. I
>see no value in conditionalizing simplified libdir handling on a lucky
>user with recentish stuff so i'm just waiting another 2 or 4 years for
>this very minor cleanup.
>
>is this libdirs tweak backportable to 1.5.1 (Debian stable), or 1.5
>(Ubuntu LTS)?

Should be trivial, yes:
http://git.savannah.gnu.org/cgit/dejagnu.git/commit/?id=5481f29161477520c691d525653323b82fa47ad7

Thanks,

Re: [PATCH WIP] Use Levenshtein distance for various misspellings in C frontend v2

[Manuel López-Ibáñez]

On 16 September 2015 at 15:33, Richard Biener
 wrote:
> On Wed, Sep 16, 2015 at 3:22 PM, Michael Matz  wrote:
>>> if we suggest 'foo' instead of foz then we'll get a more confusing followup
>>> error if we actually use it.
>>
>> This particular case could be solved by ruling out candidaten of the wrong
>> kind (here, something that can be assigned to, vs. a function).  But it
>> might actually be too early in parsing to say that there will be an
>> assignment.  I don't think _this_ problem should block the patch.

Indeed. The patch by David does not try to fix-up the code, it merely
suggests a possible candidate. The follow-up errors should be the same
before and after. Such suggestions will never be 100% right, even if
the suggestion makes the code compile and run, it may still be the
wrong one. A wrong suggestion is far less serious than a wrong
uninitialized or Warray-bounds warning and we can live with those. Why
this needs to be perfect from the very beginning?

BTW, there is a PR for this: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52277

> I wonder if we can tentatively parse with the choice at hand, only allowing
> (and even suggesting?) it if that works out.

This would require to queue the error, fix-up the wrong name and
continue parsing. If there is another error, ignore that one and emit
the original error without suggestion. The problem here is that we do
not know if the additional error is actually caused by the fix-up we
did or it is an already existing error. It would be equally terrible
to emit errors caused by the fix-up or emit just a single error for
the typo. We would need to roll-back the tentative parse and do a
definitive parse anyway. This does not seem possible at the moment
because the parsers maintain a lot of global state that is not easy to
roll-back. We cannot simply create a copy of the parser state and
throw it away later to continue as if the tentative parse has not
happened.

I'm not even sure if, in general, one can stop at the statement level
or we would need to parse the whole function (or translation unit) to
be able to tell if the suggestion is a valid candidate.

Cheers,

Manuel.

[PATCH] start of rewrite of unordered_{set,map}

[Geoff Pike]

This change is the start of a rewrite of unordered_set and
unordered_map.

(By the way, I am new to GCC and do not have SVN write access.)

SUMMARY OF MOTIVATION FOR THE CHANGE

1. Speed.  Linked lists are slow.  Without them, we save memory,
allowing us to default to a lower load factor; or, the savings could
be RAM, if desired.  Initial tests are showing a 20%ish improvement on
several basic benchmarks (with FDO, on x86-64).

2. Defense to hash flooding. This benefit is harder to analyze, but I
think I'm making a reasonable proposal.

PLAN

I plan to spread the changs out over multiple patches.  This first
patch has no effect USE_HYBRID_WILD_CUCKOO_FOR_UNORDERED_SET is
defined to 1 (or similar).  The patch isn't ready yet to turn that on
by default; I intend to suggest flipping the default after this and
other to-be-written patches are submitted.  That said, I would love to
get feedback, so I can understand any substantial flaws sooner rather
than later.

DETAILS

"Hash flooding" is an attempt by an adversary to flood a hash table
with keys that cause an unusual amount of time (or RAM or ...) to be
consumed.  For example, an adversary might present many keys with the
same hash code.

Here are several common ideas to combat hash flooding, and counter
arguments to each:

1. A traditional hash table with a "great" hash function.  Counter
argument: no matter what hash function is selected, there is still a
timing attack that can force O(n^1.5) computational steps by the
attackee via only n steps by the adversary.  Also, "great" hash
functions aren't cheap.

2. A hash table that uses linked lists in lightly-occupied buckets and
balanced binary trees in heavily-occupied buckets.  Counter argument:
Worst case O(n log n) time with perhaps a lot of wasted RAM as well.
Also, this introduces the need for an ordering on the elements.

3. De-amortized Cuckoo with "great" hash functions.  Counter argument:
when hash-flooded, the "queue" or "stash" in de-amortized Cuckoo can become
long enough that a lot of basic operations that much longer than normal.
Also, "great" hash functions aren't cheap.

On general principles, it would be nice to avoid a performance penalty
in the happy, common cases where no hash flooding is in progress.
Furthermore, if hash flooding is in progress, access to keys not
provided by the adversary should still be (mostly) fast.

My belief is we can overcome all these issues and still be backward
compatible with the requirements of C++'s unordered_set and unordered_map.
I haven't decided exactly how to tackle unordered_multi{map,set} yet, but
I don't forsee any huge problems there.

Another key feature of the scheme I've begun implementing is that,
while it's preferable to let it work with a family of hash functions
(like Cuckoo does), if only one is available, as will be the case in a
lot of existing code, then it still works.  When offered a single hash
function to use, the code creates a family of hash functions by using
a random post-processing step, i.e., the output of the given hash
function is rehashed by a randomly-selected hash-code-to-hash-code
function.  This isn't great for avoiding hash flooding, but I suspect
it's better than nothing.

Comments in the patch contain additional algorithmic details etc.

KNOWN ISSUES

o The C++ standard says very little about what local iterators are
supposed to do.  What it seems to require: begin(bucket_number) takes
O(1) time, and if two elements have the same hash code then a single
local iteration should contain both.  The current patch takes that at
face value, and simply makes begin(0) yield a local iterator that
contains everything (like begin()) and begin(n) == end(n) for n != 0.
Unfortunately, although the standard doesn't say one may assume it,
there may be existing code that assumes that begin(n) has something to
do with the elements whose hash code is n mod bucket_count(). If my
shortcut isn't acceptable then I'll have to switch to a more complex,
slower scheme.  That'll hurt a bit, but I don't think it'll destroy
the value of what I'm proposing.  Luckily, local iterators are an
obscure, seldom-used feature.

o Allocators need to be addressed (currently the prototype just uses
new and delete for everything).

o Other details need to be addressed, notably: swapping exactly what
should be swapped in the swap method, making begin() take O(1) time,
and properly handling exceptions thrown by the hasher and other code
that we call.

o Portability needs to be addressed.

o I'm still working on switching everything over to GCC coding style

o Some optimizations (notably caching hash codes) need to be investigated/added.

o Performance gains without FDO aren't nearly as impressive. I haven't
yet looked into this discrepancy.

Index: libstdc++-v3/include/Makefile.am
===
--- libstdc++-v3/include/Makefile.am (revision 227597)
+++ libstdc++-v3/include/Makefile.am (working copy)
@@ -96,6 +96

[C/C++ PATCH] RFC: Implement -Wduplicated-cond (PR c/64249)

[Marek Polacek]

This patch implements a new warning, -Wduplicated-cond.  It warns for
code such as

  if (x)
// ...
  else if (x)
// ...

This happened in the GCC codebase as well:
.

The approach I took for this was to create vectors of conditions in an
if-else-if chain.  I.e.,

  if (A1)
{
  if (B1) // ...
  else if (B2) // ...
  if (C1) // ...
}
  else if (A2)
// ...
  else
// ...

contains two chains: {A1, A2} and {B1, B2}.  We don't create a chain for
C1 because that if doesn't have else-if clause.  Now, every time we're
trying to add a new condition to the chain, we first check whether the
condition is already there using operand_equal_p.  If it is, we warn.

So that's the general overview.  Since I think this oughtn't to generate
many false positives and almost always will point to a real bug (famous
last words), I've made it a part of -Wall.

I couldn't bootstrap this yet because I'm tripping over

insn-dfatab.c: In function ‘int internal_dfa_insn_code_pentiumpro(rtx_insn*)’:
insn-dfatab.c:5392:12: error: duplicated ‘if’ condition 
[-Werror=duplicated-cond]
   else if ((cached_memory == MEMORY_NONE) && ((cached_mode == MODE_SF) && 
(cached_type == TYPE_SSEDIV)))
^
insn-dfatab.c:5388:47: note: previously used here
   else if ((cached_memory == MEMORY_NONE) && ((cached_mode == MODE_SF) && 
(cached_type == TYPE_SSEDIV)))
   ^
insn-latencytab.c: In function ‘int insn_default_latency_pentiumpro(rtx_insn*)’:
insn-latencytab.c:5164:12: error: duplicated ‘if’ condition 
[-Werror=duplicated-cond]
   else if ((cached_memory == MEMORY_NONE) && ((cached_mode == MODE_SF) && 
(cached_type == TYPE_SSEDIV)))
^
insn-latencytab.c:5160:47: note: previously used here
   else if ((cached_memory == MEMORY_NONE) && ((cached_mode == MODE_SF) && 
(cached_type == TYPE_SSEDIV)))

Unless I'm blind those conditions are indeed the same so the warning is
right and this might be a bug either in some .md file or in genattrtab,
but I don't know how to fix this.  There might be other bootstrap problems
as well.  But I thought I would post this for comments anyway.

Regtested on x86_64-linux.

2015-09-16  Marek Polacek  

PR c/64249
* c-common.c (warn_duplicated_cond_add_or_warn): New function.
* c-common.h (warn_duplicated_cond_add_or_warn): Declare.
* c.opt (Wduplicated-cond): New option.

* c-parser.c (c_parser_statement_after_labels): Add CHAIN parameter
and pass it down to c_parser_if_statement.
(c_parser_else_body): Add CHAIN parameter and pass it down to
c_parser_statement_after_labels.
(c_parser_if_statement): Add CHAIN parameter.  Add code to warn about
duplicated if-else-if conditions.

* parser.c (cp_parser_statement): Add CHAIN parameter and pass it
down to cp_parser_selection_statement.
(cp_parser_selection_statement): Add CHAIN parameter.  Add code to
warn about duplicated if-else-if conditions.
(cp_parser_implicitly_scoped_statement): Add CHAIN parameter and pass
it down to cp_parser_statement.

* doc/invoke.texi: Document -Wduplicated-cond.

* c-c++-common/Wduplicated-cond-1.c: New test.
* c-c++-common/Wduplicated-cond-2.c: New test.
* c-c++-common/Wduplicated-cond-3.c: New test.
* c-c++-common/Wmisleading-indentation.c (fn_37): Avoid
-Wduplicated-cond warning.

diff --git gcc/c-family/c-common.c gcc/c-family/c-common.c
index 4b922bf..ee15abc 100644
--- gcc/c-family/c-common.c
+++ gcc/c-family/c-common.c
@@ -12919,4 +12919,37 @@ reject_gcc_builtin (const_tree expr, location_t loc /* 
= UNKNOWN_LOCATION */)
   return false;
 }
 
+/* If we're creating an if-else-if condition chain, first see if we
+   already have this COND in the CHAIN.  If so, warn and don't add COND
+   into the vector, otherwise add the COND there.  LOC is the location
+   of COND.  */
+
+void
+warn_duplicated_cond_add_or_warn (location_t loc, tree cond, vec *chain)
+{
+  /* No chain has been created yet.  Do nothing.  */
+  if (chain == NULL)
+return;
+
+  unsigned int ix;
+  tree t;
+  bool found = false;
+  FOR_EACH_VEC_ELT (*chain, ix, t)
+if (operand_equal_p (cond, t, 0))
+  {
+   if (warning_at (loc, OPT_Wduplicated_cond,
+   "duplicated % condition"))
+ inform (EXPR_LOCATION (t), "previously used here");
+   found = true;
+   break;
+  }
+
+  if (!found
+  && !CONSTANT_CLASS_P (cond)
+  && !TREE_SIDE_EFFECTS (cond)
+  /* Don't infinitely grow the chain.  */
+  && chain->length () < 512)
+chain->safe_push (cond);
+}
+
 #include "gt-c-family-c-common.h"
diff --git gcc/c-family/c-common.h gcc/c-family/c-common.h
index 74d1bc1..6d91a4b 100644
--- gcc/c-family/c-common.h
+++ gcc/c-family/c-common.h
@@ -1441,5 +1441,6 @@ extern tree cilk_

Re: [patch] libstdc++/67173 Fix filesystem::canonical for Solaris 10.

[Jonathan Wakely]

On 16/09/15 15:42 +0100, Jonathan Wakely wrote:

@@ -22,6 +22,8 @@
// see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
// .

+#define _XOPEN_SOURCE 700
+
#include 
#include 
#include 


Unfortunately this completely breaks NetBSD, because defining
_XOPEN_SOURCE for this one file is inconsistent with how the autconf
test were run, so C99 functions that were implicitly available during
configure tests (because no _POSIX_C_SOURCE, _XOPEN_SOURCE etc. macro
was defined) are no longer available when compiling this translation
unit with _XOPEN_SOURCE defined.

Specifically,  in NetBSD 5.1 does:

#if !defined(_ANSI_SOURCE) && !defined(_POSIX_C_SOURCE) && \
   !defined(_XOPEN_SOURCE) && !defined(_NETBSD_SOURCE)
#define _NETBSD_SOURCE 1
#endif
...
#if defined(_ISOC99_SOURCE) || (__STDC_VERSION__ - 0) > 199901L || \
   defined(_NETBSD_SOURCE)
int vfwscanf(FILE * __restrict, const wchar_t * __restrict, _BSD_VA_LIST_);


So it's defined during configure and we define _GLIBCXX_HAVE_VFWSCANF
and our  does:

#if _GLIBCXX_HAVE_VFWSCANF
 using ::vfwscanf;
#endif

but the value of _GLIBCXX_HAVE_VFWSCANF determined during configure is
not valid in src/filesystem/ops.cc after defining _XOPEN_SOURCE.

I don't know how to use _XOPEN_VERSION or _POSIX_VERSION to check for
a suitable realpath without defining one of those feature-test macros,
which then breaks other things.

(This is fixed in NetBSD 7.x which knows about C++11 and so defines
vfwscanf more liberally, but that doesn't help NetBSD 5.1).

Maybe I should just give up on realpath() and use my new
implementation everywhere :-(

Re: [patch] libstdc++/67173 Fix filesystem::canonical for Solaris 10.

[Jonathan Wakely]

On 16/09/15 17:02 +0100, Jonathan Wakely wrote:

I don't know how to use _XOPEN_VERSION or _POSIX_VERSION to check for
a suitable realpath without defining one of those feature-test macros,
which then breaks other things.


I suppose we could also define _NETBSD_SOURCE manually, which is
basically what we do on GNU/Linux. G++ predefines _GNU_SOURCE so that
glibc gives us all declarations, but I want to move away from that and
stop polluting the global namespace with every GNU extension.

Maybe defining _NETBSD_SOURCE for versions older than 7.x is the right
solution though.

Re: [PATCH] Fix endianness assumption in LRA

[Vladimir Makarov]

On 09/15/2015 02:39 AM, David Miller wrote:

This was the most glaring case, and would result in LRA crashing
if this code snippet was actually hit on big-endian, since
simplify_gen_subreg() will return NULL in such a case and then
we try to blindly emit a move to 'subreg'.


Vlad, is this OK to commit?

Yes. Thanks, David.

We could use subreg_lowpart_offset for simplify_gen_subreg but for this 
case it would be just wasting computer cycles.

2015-09-14  David S. Miller  

* lra-constraints.c (simplify_operand_subreg): Do not assume that
lowpart of a SUBREG has offset zero.

diff --git a/gcc/lra-constraints.c b/gcc/lra-constraints.c
index cdb2695..fc8e43d 100644
--- a/gcc/lra-constraints.c
+++ b/gcc/lra-constraints.c
@@ -1545,7 +1545,7 @@ simplify_operand_subreg (int nop, machine_mode reg_mode)
  bool insert_before, insert_after;
  
  	  PUT_MODE (new_reg, mode);

-  subreg = simplify_gen_subreg (innermode, new_reg, mode, 0);
+  subreg = gen_lowpart_SUBREG (innermode, new_reg);
  bitmap_set_bit (&lra_subreg_reload_pseudos, REGNO (new_reg));
  
  	  insert_before = (type != OP_OUT);

Re: [PATCH, rs6000] Add expansions for min/max vector reductions

[Bill Schmidt]

On Wed, 2015-09-16 at 16:29 +0100, Alan Lawrence wrote:
> On 16/09/15 15:28, Bill Schmidt wrote:
> > 2015-09-16  Bill Schmidt  
> >
> >  * config/rs6000/altivec.md (UNSPEC_REDUC_SMAX, UNSPEC_REDUC_SMIN,
> >  UNSPEC_REDUC_UMAX, UNSPEC_REDUC_UMIN, UNSPEC_REDUC_SMAX_SCAL,
> >  UNSPEC_REDUC_SMIN_SCAL, UNSPEC_REDUC_UMAX_SCAL,
> >  UNSPEC_REDUC_UMIN_SCAL): New enumerated constants.
> >  (reduc_smax_v2di): New define_expand.
> >  (reduc_smax_scal_v2di): Likewise.
> >  (reduc_smin_v2di): Likewise.
> >  (reduc_smin_scal_v2di): Likewise.
> >  (reduc_umax_v2di): Likewise.
> >  (reduc_umax_scal_v2di): Likewise.
> >  (reduc_umin_v2di): Likewise.
> >  (reduc_umin_scal_v2di): Likewise.
> >  (reduc_smax_v4si): Likewise.
> >  (reduc_smin_v4si): Likewise.
> >  (reduc_umax_v4si): Likewise.
> >  (reduc_umin_v4si): Likewise.
> >  (reduc_smax_v8hi): Likewise.
> >  (reduc_smin_v8hi): Likewise.
> >  (reduc_umax_v8hi): Likewise.
> >  (reduc_umin_v8hi): Likewise.
> >  (reduc_smax_v16qi): Likewise.
> >  (reduc_smin_v16qi): Likewise.
> >  (reduc_umax_v16qi): Likewise.
> >  (reduc_umin_v16qi): Likewise.
> >  (reduc_smax_scal_): Likewise.
> >  (reduc_smin_scal_): Likewise.
> >  (reduc_umax_scal_): Likewise.
> >  (reduc_umin_scal_): Likewise.
> 
> You shouldn't need the non-_scal reductions. Indeed, they shouldn't be used 
> if 
> the _scal are present. The non-_scal's were previously defined as producing a 
> vector with one element holding the result and the other elements all zero, 
> and 
> this was only ever used with a vec_extract immediately after; the _scal 
> pattern 
> now includes the vec_extract as well. Hence the non-_scal patterns are 
> deprecated / considered legacy, as per md.texi.

Thanks -- I had misread the description of the non-scalar versions,
missing the part where the other elements are zero.  What I really
want/need is an optab defined as computing the maximum value in all
elements of the vector.  This seems like a strange thing to want, but
Alan Hayward's proposed patch will cause us to generate the scalar
version, followed by a broadcast of the vector.  Since our patterns
already generate the maximum value in all positions, this creates an
unnecessary extract followed by an unnecessary broadcast.

As discussed elsewhere, we *could* remove the unnecessary code by
recognizing this in simplify-rtx, etc., but the vectorization cost
modeling would be wrong.  It would have still told us to model this as a
vec_to_scalar for the reduc_max_scal, and a vec_stmt for the broadcast.
This would overcount the cost of the reduction compared to what we would
actually generate.

To get this right for all targets, one could envision having a new optab
for a reduction-to-vector, which most targets wouldn't implement, but
PowerPC and AArch32, at least, would.  If a target has a
reduction-to-vector, the vectorizer would have to generate a different
GIMPLE code that mapped to this; otherwise it would do the
REDUC_MAX_EXPR and the broadcast.  This obviously starts to get
complicated, since adding a GIMPLE code certainly has a nontrivial
cost. :/

Perhaps the practical thing is to have the vectorizer also do an
add_stmt_cost with some new token that indicates the cost model should
make an adjustment if the back end doesn't need the extract/broadcast.
Targets like PowerPC and AArch32 could then subtract the unnecessary
cost, and remove the unnecessary code in simplify-rtx.

Copying Richi and ARM folks for opinions on the best design.  I want to
be able to model this stuff as accurately as possible, but obviously we
need to avoid unnecessary effects on other architectures.

In any case, I will remove implementing the deprecated optabs, and I'll
also try to look at Alan L's patch shortly.

Thanks,
Bill


> 
> I proposed a patch to migrate PPC off the old patterns, but have forgotten to 
> ping it recently - last at 
> https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01024.html ... (ping?!)
> 
> --Alan
> 

Re: dejagnu version update?

[Mike Stump]

On Sep 16, 2015, at 12:29 AM, Andreas Schwab  wrote:
> Mike Stump  writes:
> 
>> The software presently works with 1.4.4 and there aren’t any changes
>> that require anything newer.
> 
> SLES 12 has 1.4.4.

Would be nice to cover them as well, but their update schedule, 3-4 years, 
means that their next update is 2018.  They didn’t update to a 3 year old 
stable release of dejagnu for their last OS, meaning they are on a > 7 year 
update cycle.  I love embedded and really long term support cycles (20 years), 
but, don’t think we should cater to the 20 year cycle just yet.  :-)  Since 7 
is substantially longer than 2, I don’t think we should worry about it.  If 
they had updated at the time, they would have had 3 years of engineering and 
testing before the release and _had_ 1.5.

Re: [PATCH, rs6000] Add expansions for min/max vector reductions

[Bill Schmidt]

On Wed, 2015-09-16 at 16:29 +0100, Alan Lawrence wrote:
> 
> I proposed a patch to migrate PPC off the old patterns, but have forgotten to 
> ping it recently - last at 
> https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01024.html ... (ping?!)
> 

Hi Alan,

Thanks for this patch.  I see that you tested it on gcc110, which is a
big-endian platform.  I think the pattern for V4SF might have an endian
problem on little-endian, but I'm not positive just eyeballing it.  (I
think that the select of element 3 will address the wrong end of the
vector for LE.)  Can you please try the patch on gcc112 as well to set
my mind at ease?

Thanks,
Bill

> --Alan
> 

Re: dejagnu version update?

[Ramana Radhakrishnan]

On 16/09/15 17:14, Mike Stump wrote:
> On Sep 16, 2015, at 12:29 AM, Andreas Schwab  wrote:
>> Mike Stump  writes:
>>
>>> The software presently works with 1.4.4 and there aren’t any changes
>>> that require anything newer.
>>
>> SLES 12 has 1.4.4.
> 
> Would be nice to cover them as well, but their update schedule, 3-4 years, 
> means that their next update is 2018.  They didn’t update to a 3 year old 
> stable release of dejagnu for their last OS, meaning they are on a > 7 year 
> update cycle.  I love embedded and really long term support cycles (20 
> years), but, don’t think we should cater to the 20 year cycle just yet.  :-)  
> Since 7 is substantially longer than 2, I don’t think we should worry about 
> it.  If they had updated at the time, they would have had 3 years of 
> engineering and testing before the release and _had_ 1.5.
> 

Sorry about the obvious (possibly dumb) question. 

Can't we just import a copy of dejagnu each year and install it as part of the 
source tree ? I can't imagine installing dejagnu is adding a huge amount of 
time to build and regression test time ? Advantage is that everyone is 
guaranteed to be on the same version. I fully expect resistance due to specific 
issues with specific versions of tcl and expect, but if folks aren't aware of 
this .

regards
Ramana

Re: [C++] Coding rule enforcement

[Manuel López-Ibáñez]

On 16/09/15 16:36, Nathan Sidwell wrote:

On 09/16/15 10:23, Jason Merrill wrote:

On 09/16/2015 08:02 AM, Nathan Sidwell wrote:

+  else if (warn_multiple_inheritance)
+warning (OPT_Wmultiple_inheritance,
+ "%qT defined with multiple direct bases", ref);


You don't need to guard the warning with a check of the warning flag; warning
will only give the warning if the option is enabled.


hm, it didn't seem to be doing that.  Perhaps  I'd got something wrong 
...looking


Perhaps because you misspelled Warning here?

+Wmultiple-inheritance
+C++ ObjC++ Var(warn_multiple_inheritance) Warninng
+Warn on direct multiple inheritance
+

The awk scripts that parse the .opt files are not as smart as they could be.

Cheers,

Manuel.

Re: dejagnu version update?

[Jeff Law]

On 09/16/2015 10:25 AM, Ramana Radhakrishnan wrote:



On 16/09/15 17:14, Mike Stump wrote:

On Sep 16, 2015, at 12:29 AM, Andreas Schwab 
wrote:

Mike Stump  writes:


The software presently works with 1.4.4 and there aren’t any
changes that require anything newer.


SLES 12 has 1.4.4.


Would be nice to cover them as well, but their update schedule, 3-4
years, means that their next update is 2018.  They didn’t update to
a 3 year old stable release of dejagnu for their last OS, meaning
they are on a > 7 year update cycle.  I love embedded and really
long term support cycles (20 years), but, don’t think we should
cater to the 20 year cycle just yet.  :-)  Since 7 is substantially
longer than 2, I don’t think we should worry about it.  If they had
updated at the time, they would have had 3 years of engineering and
testing before the release and _had_ 1.5.



Sorry about the obvious (possibly dumb) question.

Can't we just import a copy of dejagnu each year and install it as
part of the source tree ? I can't imagine installing dejagnu is
adding a huge amount of time to build and regression test time ?
Advantage is that everyone is guaranteed to be on the same version. I
fully expect resistance due to specific issues with specific versions
of tcl and expect, but if folks aren't aware of this .
That should work -- certainly that's the way we used to do things at 
Cygnus.  Some of that code may have bitrotted as single tree builds have 
fallen out-of-favor through the years.


As to whether or  not its a good idea.  I'm torn -- I don't like copying 
code from other repos because of the long term maintenance concerns.


I'd rather just move to 1.5 and get on with things.  If some systems 
don't have a new enough version, I'm comfortable telling developers on 
those platforms that they need to update.  It's not like every *user* 
needs dejagnu, it's just for the testing side of things.



jeff

Re: Fix 61441

[Joseph Myers]

On Wed, 16 Sep 2015, Sujoy Saraswati wrote:

> > If -fsignaling-nans, then folding of expressions involving sNaNs should be
> > disabled, outside of static initializers - such expressions should not get
> > folded to return an sNaN (it's incorrect to fold sNaN + 1 to sNaN, for
> > example).  I think existing code may ensure that (the HONOR_SNANS check in
> > const_binop, for example).
> 
> Yes, with -fsignaling-nans, the const_binop will not fold since the
> HONOR_SNANS check is there. However, elsewhere, like const_unop, the
> code doesn't do this check.

Which would be a bug in the const_unop code, or the functions it calls 
(for operations for which such a check is appropriate - as noted, abs and 
negation should be folded unconditionally).

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

Re: [PATCH, rs6000] Add expansions for min/max vector reductions

[Alan Lawrence]

On 16/09/15 17:10, Bill Schmidt wrote:


On Wed, 2015-09-16 at 16:29 +0100, Alan Lawrence wrote:

On 16/09/15 15:28, Bill Schmidt wrote:

2015-09-16  Bill Schmidt  

  * config/rs6000/altivec.md (UNSPEC_REDUC_SMAX, UNSPEC_REDUC_SMIN,
  UNSPEC_REDUC_UMAX, UNSPEC_REDUC_UMIN, UNSPEC_REDUC_SMAX_SCAL,
  UNSPEC_REDUC_SMIN_SCAL, UNSPEC_REDUC_UMAX_SCAL,
  UNSPEC_REDUC_UMIN_SCAL): New enumerated constants.
  (reduc_smax_v2di): New define_expand.
  (reduc_smax_scal_v2di): Likewise.
  (reduc_smin_v2di): Likewise.
  (reduc_smin_scal_v2di): Likewise.
  (reduc_umax_v2di): Likewise.
  (reduc_umax_scal_v2di): Likewise.
  (reduc_umin_v2di): Likewise.
  (reduc_umin_scal_v2di): Likewise.
  (reduc_smax_v4si): Likewise.
  (reduc_smin_v4si): Likewise.
  (reduc_umax_v4si): Likewise.
  (reduc_umin_v4si): Likewise.
  (reduc_smax_v8hi): Likewise.
  (reduc_smin_v8hi): Likewise.
  (reduc_umax_v8hi): Likewise.
  (reduc_umin_v8hi): Likewise.
  (reduc_smax_v16qi): Likewise.
  (reduc_smin_v16qi): Likewise.
  (reduc_umax_v16qi): Likewise.
  (reduc_umin_v16qi): Likewise.
  (reduc_smax_scal_): Likewise.
  (reduc_smin_scal_): Likewise.
  (reduc_umax_scal_): Likewise.
  (reduc_umin_scal_): Likewise.


You shouldn't need the non-_scal reductions. Indeed, they shouldn't be used if
the _scal are present. The non-_scal's were previously defined as producing a
vector with one element holding the result and the other elements all zero, and
this was only ever used with a vec_extract immediately after; the _scal pattern
now includes the vec_extract as well. Hence the non-_scal patterns are
deprecated / considered legacy, as per md.texi.


Thanks -- I had misread the description of the non-scalar versions,
missing the part where the other elements are zero.  What I really
want/need is an optab defined as computing the maximum value in all
elements of the vector.


Yes, indeed. It seems reasonable to me that this would coexist with an optab 
which computes only a single value (i.e. a scalar).


At that point it might be appropriate to change the cond-reduction code to 
generate the reduce-to-vector in all cases, and optabs.c expand it to 
reduce-to-scalar + broadcast if reduce-to-vector was not available. Along with 
the (parallel) changes to cost model already proposed, does that cover all the 
cases? It does add a new tree code, yes, but I'm feeling that could be justified 
if we go down this route.


However, another point that springs to mind: if you reduce a loop containing OR 
or MUL expressions, the vect_create_epilog_for_reduction reduces these using 
shifts, and I think will also use shifts for platforms not possessing a 
reduc_plus/min/max. If shifts could be changed for rotates, the code there would 
do your reduce-to-a-vector-of-identical-elements in the midend...can we 
(sensibly!) bring all of these together?



Perhaps the practical thing is to have the vectorizer also do an
add_stmt_cost with some new token that indicates the cost model should
make an adjustment if the back end doesn't need the extract/broadcast.
Targets like PowerPC and AArch32 could then subtract the unnecessary
cost, and remove the unnecessary code in simplify-rtx.


I think it'd be good if we could do it before simplify-rtx, really, although I'm 
not sure I have a strong argument as to why, as long as we can cost it 
appropriately.



In any case, I will remove implementing the deprecated optabs, and I'll
also try to look at Alan L's patch shortly.


That'd be great, thanks :)

Cheers, Alan

Re: [PATCH] start of rewrite of unordered_{set,map}

[Geoff Pike]

Silly me, pasting the patch at the bottom of my original message
didn't work. Patch is attached.

Also, to clarify, I am primarily seeking high-level comments; I am new
here and don't want to waste anybody's time.
Index: libstdc++-v3/include/Makefile.am
===
--- libstdc++-v3/include/Makefile.am(revision 227597)
+++ libstdc++-v3/include/Makefile.am(working copy)
@@ -96,6 +96,7 @@
${bits_srcdir}/codecvt.h \
${bits_srcdir}/concept_check.h \
${bits_srcdir}/cpp_type_traits.h \
+   ${bits_srcdir}/cuckoo.h \
${bits_srcdir}/deque.tcc \
${bits_srcdir}/enable_special_members.h \
${bits_srcdir}/forward_list.h \
Index: libstdc++-v3/include/Makefile.in
===
--- libstdc++-v3/include/Makefile.in(revision 227597)
+++ libstdc++-v3/include/Makefile.in(working copy)
@@ -386,6 +386,7 @@
${bits_srcdir}/codecvt.h \
${bits_srcdir}/concept_check.h \
${bits_srcdir}/cpp_type_traits.h \
+   ${bits_srcdir}/cuckoo.h \
${bits_srcdir}/deque.tcc \
${bits_srcdir}/enable_special_members.h \
${bits_srcdir}/forward_list.h \
Index: libstdc++-v3/include/bits/cuckoo.h
===
--- libstdc++-v3/include/bits/cuckoo.h  (revision 0)
+++ libstdc++-v3/include/bits/cuckoo.h  (working copy)
@@ -0,0 +1,3103 @@
+// hybrid wild cuckoo hashtable implementation -*- C++ -*-
+
+// Copyright (C) 2010-2015 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// Under Section 7 of GPL version 3, you are granted additional
+// permissions described in the GCC Runtime Library Exception, version
+// 3.1, as published by the Free Software Foundation.
+
+// You should have received a copy of the GNU General Public License and
+// a copy of the GCC Runtime Library Exception along with this program;
+// see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+// .
+
+/** @file bits/cuckoo.h
+ *  This is an internal header file, included by other library headers.
+ *  Do not attempt to use it directly. @headername{cuckoo}
+ * This file implements Hybrid Wild Cuckoo and Wild Cuckoo.  The latter is used
+ * as a building block for Hybrid Wild Cuckoo when all the bells and whistles
+ * are required (as they are for a C++ standards-compliant 
unordered_{set,map}).
+ * It may also be interesting on its own.
+ *
+ * For simplicity we use one table (as is also done in some variants of 
Cuckoo).
+ * We also force the table size to be a power of 2 in this implementation,
+ * though there is no theoretical reason to do so.  The number of elements in
+ * the table is _M_num_elements in the code, but called "n" here; the number of
+ * buckets is _M_num_buckets in the code, but called "b" here.
+ *
+ * As usual in such discussions, the big-O bounds stated below
+ * assume that hashing an element is O(1).  We also ignore the bitset
+ * size and z, parameters typically set to small integers, when
+ * discussing big-O bounds.  E.g., we never write O(z); we write O(1)
+ * for that.
+ *
+ * In Wild Cuckoo, the algorithm for inserting an item is similar to Cuckoo
+ * except that the set of possible "nests" for an item can grow dynamically.
+ * In particular, the algorithm for find-or-insert-if-not-present (often called
+ * "insert" among C++ programmers) is as follows:
+ *  1. Compute g1 = H1(key) and g2 = H2(key), where H1 and H2 are hash 
functions.
+ *  2. Let h1 = g1 % b and h2 = g2 % b
+ *  3. Look for the key in all its possible nests.  Typically these are just
+ *  h1, h1^1, h1^2, ..., h1^z, h2, h2^1, h2^2, ..., and h2^z.  (Say, for z = 
4.)
+ *  However, we also keep a map of  pairs to information on additional
+ *  possible nests, which can be anywhere in the table.  Pairs with additional
+ *  possible nests are called "extended."  More details on this
+ *  are below.  A key point is that, unlike in all previous
+ *  multiple-choice-hashing schemes, a key with any hash codes can appear
+ *  anywhere in the table...  Hence the "Wild" in Wild Cuckoo.
+ *  4. If the key is not found in any of its nests then it must be inserted,
+ *  into a empty nest if possible.  If no nest is free then we have two
+ *  choices:
+ *o If the size of all extensions to  is below the "extension cap,"
+ *  a constant, and either  is e

Re: dejagnu version update?

[Trevor Saunders]

On Wed, Sep 16, 2015 at 10:36:47AM -0600, Jeff Law wrote:
> On 09/16/2015 10:25 AM, Ramana Radhakrishnan wrote:
> >
> >
> >On 16/09/15 17:14, Mike Stump wrote:
> >>On Sep 16, 2015, at 12:29 AM, Andreas Schwab 
> >>wrote:
> >>>Mike Stump  writes:
> >>>
> The software presently works with 1.4.4 and there aren’t any
> changes that require anything newer.
> >>>
> >>>SLES 12 has 1.4.4.
> >>
> >>Would be nice to cover them as well, but their update schedule, 3-4
> >>years, means that their next update is 2018.  They didn’t update to
> >>a 3 year old stable release of dejagnu for their last OS, meaning
> >>they are on a > 7 year update cycle.  I love embedded and really
> >>long term support cycles (20 years), but, don’t think we should
> >>cater to the 20 year cycle just yet.  :-)  Since 7 is substantially
> >>longer than 2, I don’t think we should worry about it.  If they had
> >>updated at the time, they would have had 3 years of engineering and
> >>testing before the release and _had_ 1.5.
> >>
> >
> >Sorry about the obvious (possibly dumb) question.
> >
> >Can't we just import a copy of dejagnu each year and install it as
> >part of the source tree ? I can't imagine installing dejagnu is
> >adding a huge amount of time to build and regression test time ?
> >Advantage is that everyone is guaranteed to be on the same version. I
> >fully expect resistance due to specific issues with specific versions
> >of tcl and expect, but if folks aren't aware of this .
> That should work -- certainly that's the way we used to do things at Cygnus.
> Some of that code may have bitrotted as single tree builds have fallen
> out-of-favor through the years.
> 
> As to whether or  not its a good idea.  I'm torn -- I don't like copying
> code from other repos because of the long term maintenance concerns.

yeah, there's definitely history showing sharing code by coppying is not
a great idea e.g. top level files getting out of sync.  I'm hopefully
git submodules will make this better soon, but the UI isn't really great
yet.

> I'd rather just move to 1.5 and get on with things.  If some systems don't
> have a new enough version, I'm comfortable telling developers on those
> platforms that they need to update.  It's not like every *user* needs
> dejagnu, it's just for the testing side of things.

yeah, it seems like a poor idea to slow down progress we make for all
users to benefit a few people who want to develope on rather old
machines.

Trev

> 
> 
> jeff

[PATCH] Move code out of tree-ssa-dom into tree-ssa-scopedtables

[Jeff Law]

This moves most of the support for scoped hash tables out of DOM.  It's 
highly mechanical.  I did fix a few comments along the way and added 
some private members to the const_and_copies and avail_expr_stack 
classes to ensure we're following the rule-of-3 guidelines in those classes.


I can easily layer the changes to fix 47679 on top of this patch.  So 
we're getting close to the goal line here.


Bootstrapped and regression tested on x86_64-linux-gnu.  Applied to the 
trunk.




commit 0de8c264e5b6081105ccc31c67912fcd767b98ed
Author: Jeff Law 
Date:   Tue Sep 15 21:13:37 2015 -0600

[PATCH] Move code out of tree-ssa-dom into tree-ssa-scopedtables

PR tree-optimization/47679
* tree-ssa-dom.c (enum expr_kind): Moved from here to
tree-ssa-scopedtables.h.
(struct hashable_expr, class expr_hash_elt): Likewise.
(struct expr_elt_hasher, class avail_exprs_stack): Likewise.
Move associated methods into tree-ssa-scopedtables.c.
(avail_expr_hash, initialize_expr_from_cond): Similarly.
(hashable_expr_equal_p, add_expr_commutative): Likewise.
(add_hashable_expr): Likewise.
(record_cond): Delete element directly.
* tree-ssa-scopedtables.h (avail_expr_stack, const_and_copies): Add
private copy ctor and assignment operator methods.
(expr_elt_hasher): Inline trivial methods.
(initialize_expr_from_cond): Prototype.
* tree-ssa-scopedtables.c: Add necessary includes, functions and
methods that were previously in tree-ssa-dom.c.  Improve various
comments.

diff --git a/gcc/tree-ssa-dom.c b/gcc/tree-ssa-dom.c
index 9e38541..b97125a 100644
--- a/gcc/tree-ssa-dom.c
+++ b/gcc/tree-ssa-dom.c
@@ -55,33 +55,6 @@ along with GCC; see the file COPYING3.  If not see
 
 /* This file implements optimizations on the dominator tree.  */
 
-/* Representation of a "naked" right-hand-side expression, to be used
-   in recording available expressions in the expression hash table.  */
-
-enum expr_kind
-{
-  EXPR_SINGLE,
-  EXPR_UNARY,
-  EXPR_BINARY,
-  EXPR_TERNARY,
-  EXPR_CALL,
-  EXPR_PHI
-};
-
-struct hashable_expr
-{
-  tree type;
-  enum expr_kind kind;
-  union {
-struct { tree rhs; } single;
-struct { enum tree_code op;  tree opnd; } unary;
-struct { enum tree_code op;  tree opnd0, opnd1; } binary;
-struct { enum tree_code op;  tree opnd0, opnd1, opnd2; } ternary;
-struct { gcall *fn_from; bool pure; size_t nargs; tree *args; } call;
-struct { size_t nargs; tree *args; } phi;
-  } ops;
-};
-
 /* Structure for recording known values of a conditional expression
at the exits from its block.  */
 
@@ -91,7 +64,6 @@ struct cond_equivalence
   tree value;
 };
 
-
 /* Structure for recording edge equivalences.
 
Computing and storing the edge equivalences instead of creating
@@ -114,137 +86,6 @@ struct edge_info
   vec cond_equivalences;
 };
 
-/* Stack of available expressions in AVAIL_EXPRs.  Each block pushes any
-   expressions it enters into the hash table along with a marker entry
-   (null).  When we finish processing the block, we pop off entries and
-   remove the expressions from the global hash table until we hit the
-   marker.  */
-typedef struct expr_hash_elt * expr_hash_elt_t;
-
-
-/* Structure for entries in the expression hash table.  */
-
-class expr_hash_elt
-{
- public:
-  expr_hash_elt (gimple, tree);
-  expr_hash_elt (tree);
-  expr_hash_elt (struct hashable_expr *, tree);
-  expr_hash_elt (class expr_hash_elt &);
-  ~expr_hash_elt ();
-  void print (FILE *);
-  tree vop (void) { return m_vop; }
-  tree lhs (void) { return m_lhs; }
-  struct hashable_expr *expr (void) { return &m_expr; }
-  expr_hash_elt *stamp (void) { return m_stamp; }
-  hashval_t hash (void) { return m_hash; }
-
- private:
-  /* The expression (rhs) we want to record.  */
-  struct hashable_expr m_expr;
-
-  /* The value (lhs) of this expression.  */
-  tree m_lhs;
-
-  /* The virtual operand associated with the nearest dominating stmt
- loading from or storing to expr.  */
-  tree m_vop;
-
-  /* The hash value for RHS.  */
-  hashval_t m_hash;
-
-  /* A unique stamp, typically the address of the hash
- element itself, used in removing entries from the table.  */
-  struct expr_hash_elt *m_stamp;
-
-  /* We should never be making assignments between objects in this class.
- Though it might allow us to exploit C++11 move semantics if we
- defined the move constructor and move assignment operator.  */
-  expr_hash_elt& operator=(const expr_hash_elt&);
-};
-
-/* Hashtable helpers.  */
-
-static bool hashable_expr_equal_p (const struct hashable_expr *,
-  const struct hashable_expr *);
-static void free_expr_hash_elt (void *);
-
-struct expr_elt_hasher : pointer_hash 
-{
-  static inline hashval_t hash (const value_type &);
-  static inline bool equal (const value_type &, const compare_type &);
-  static inline void remove (valu

Go patch committed: Don't crash on malformed numeric constants

[Ian Lance Taylor]

This patch by Chris Manghane fixes the Go frontend to not crash on
malformed numeric constants.  This fixes
https://golang.org/issue/11548 .  Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu.  Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 227813)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-01a574c1b2bb244be764b6a18aab980ca0aef43c
+79f457a267ff2bf8e65db4bcec0cbc7add79227a
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: gcc/go/gofrontend/expressions.cc
===
--- gcc/go/gofrontend/expressions.cc(revision 227813)
+++ gcc/go/gofrontend/expressions.cc(working copy)
@@ -1904,6 +1904,13 @@ Integer_expression::do_check_types(Gogo*
 Bexpression*
 Integer_expression::do_get_backend(Translate_context* context)
 {
+  if (this->is_error_expression()
+  || (this->type_ != NULL && this->type_->is_error_type()))
+{
+  go_assert(saw_errors());
+  return context->gogo()->backend()->error_expression();
+}
+
   Type* resolved_type = NULL;
   if (this->type_ != NULL && !this->type_->is_abstract())
 resolved_type = this->type_;
@@ -2266,6 +2273,13 @@ Float_expression::do_check_types(Gogo*)
 Bexpression*
 Float_expression::do_get_backend(Translate_context* context)
 {
+  if (this->is_error_expression()
+  || (this->type_ != NULL && this->type_->is_error_type()))
+{
+  go_assert(saw_errors());
+  return context->gogo()->backend()->error_expression();
+}
+
   Type* resolved_type;
   if (this->type_ != NULL && !this->type_->is_abstract())
 resolved_type = this->type_;
@@ -2448,6 +2462,13 @@ Complex_expression::do_check_types(Gogo*
 Bexpression*
 Complex_expression::do_get_backend(Translate_context* context)
 {
+  if (this->is_error_expression()
+  || (this->type_ != NULL && this->type_->is_error_type()))
+{
+  go_assert(saw_errors());
+  return context->gogo()->backend()->error_expression();
+}
+
   Type* resolved_type;
   if (this->type_ != NULL && !this->type_->is_abstract())
 resolved_type = this->type_;
@@ -2826,8 +2847,12 @@ Const_expression::do_check_types(Gogo*)
 Bexpression*
 Const_expression::do_get_backend(Translate_context* context)
 {
-  if (this->type_ != NULL && this->type_->is_error())
-return context->backend()->error_expression();
+  if (this->is_error_expression()
+  || (this->type_ != NULL && this->type_->is_error()))
+{
+  go_assert(saw_errors());
+  return context->backend()->error_expression();
+}
 
   // If the type has been set for this expression, but the underlying
   // object is an abstract int or float, we try to get the abstract

[PATCH,committed] XFAIL read_dir.f90 on DragonflyBSD

[Steve Kargl]

I've committed the following patch.

Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog (revision 227831)
+++ gcc/testsuite/ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2015-09-16  John Marino  
+
+   * gfortran.dg/read_dir.f90: XFAIL this testcase on DragonFly.
+
 2015-09-16  Richard Biener  
 
PR middle-end/67253
Index: gcc/testsuite/gfortran.dg/read_dir.f90
===
--- gcc/testsuite/gfortran.dg/read_dir.f90  (revision 227831)
+++ gcc/testsuite/gfortran.dg/read_dir.f90  (working copy)
@@ -1,4 +1,4 @@
-! { dg-do run { xfail *-*-freebsd* } }
+! { dg-do run { xfail *-*-freebsd* *-*-dragonfly* } }
 ! PR67367
 program bug
implicit none

-- 
Steve

Re: [patch] libstdc++/67173 Fix filesystem::canonical for Solaris 10.

[Martin Sebor]

It turns out I was wrong about BSD traditionally supporting
realpath(path, NULL), it first appeared in these relatively recent
versions:

FreeBSD 9.0
OpenBSD 5.0
NetBSD 6.1

Like Solaris 11, some of them still define _POSIX_VERSION=200112L even
though they support passing NULL,  so we could hardcode the targets
that are known to support it, but we'll still need a fallback for lots
of slightly older targets anyway.

So here's a new implementation of canonical() which only uses
realpath() when this autoconf compile-or-link test passes:

#if _XOPEN_VERSION < 500
#error
#elif _XOPEN_VERSION >= 700 || defined(PATH_MAX)
char *tmp = realpath((const char*)NULL, (char*)NULL);
#else
#error
#endif

i.e. I use realpath() for Issue 7, or for Issue 6 if PATH_MAX is
defined.


I probably wouldn't code the PATH_MAX test quite the same way.
I would expect it to be mainly Issue 6 implementations that don't
define the macro to want to provide the null extension since there
would otherwise be no safe way to use the function.

I didn't test it at all but I'd be inclined to write the conditional
to look more along these lines:

  #if _XOPEN_VERSION >= 700
// Issue 7 and better -- null resolved_name means allocate
char *tmp = realpath (file_name, (char*)NULL);
  #elif _XOPEN_VERSION == 600
 // Issue 6 -- null resolved_name is implementation-defined
  #  if FreeBSD 9.0 or OpenBSD 5.0 or NetBSD 6.1
char *tmp = realpath (file_name, (char*)NULL);
  #  elif PATH_MAX
char *tmp = realpath (file_name, malloc (PATH_MAX));
  #  else
  #error No safe way to call realpath
  #  endif
  #elif _XOPEN_VERSION && PATH_MAX
// SUSv2 -- null resolved_name is an error
char *tmp = realpath (file_name, malloc (PATH_MAX));
  #else
  #  error realpath not supported or no safe way to call it
  #endif



Then in filesystem::canonical() if _GLIBCXX_USE_REALPATH is set I use
it, passing NULL for Issue 7, or allocating a buffer of PATH_MAX
otherwise. If realpath isn't supported or fails with ENAMETOOLONG then
I do the path traversal by hand (which can be done entirely using the
std::experimental::filesystem operations).


FWIW, to work across filesystems with different _PC_PATH_MAX, I
suspect the operations might need to use readlinkat. I.e., they
might need to descend into each individual subdirectory to avoid
forming a temporary pathname that's too long for the file system
being traversed, even though both the initial and the final
pathnames are under the limit. (I haven't actually tested this
but I don't see where GLIBC handles this case so it might not
do the right thing either.)



Only passing NULL for Issue 7 is quite conservative. It means we don't
do it for targets that support it as an implementation-defined
extension to Issue 6, which includes Solaris 11, the BSDs and even
older GNU systems (including RHEL6). But that's OK, we have a fallback
now so it means no loss of functionality, just efficiency.  We can
tweak the config later for targets known to handle NULL.


Does the config test actually run? If not, I don't see the point
(it doesn't tell us anything the POSIX feature tests macros don't).
If it did run, it would fail since the first argument is null.



The new testcase is not very thorough. I've run a few more involved
tests that aren't suitable to check in until I figure out a good way
of running filesystem tests that can create/remove arbitrary files and
symlinks.


Yeah, writing good tests is always the hard part. If you need help
I can try to put some together in my spare time.

Martin

Re: [Patch, libstdc++] Add specific error message into exceptions

[Jonathan Wakely]

On 12/09/15 01:57 +, Tim Shen wrote:

Ok then, let's not appending dynamic location string, but only throw a
string literal pointer.


This looks great, and a *huge* improvement on the current errors even
without more precise location info.

OK for trunk, thanks very much for doing this.





commit fc3343a2c719049620447f6dc20191e2af4895f6
Author: Tim Shen 
Date:   Thu Aug 27 21:42:40 2015 -0700

PR libstdc++/67361
* include/bits/regex_error.h: Add __throw_regex_error that
supports string.
* include/bits/regex_automaton.h: Add more specific exception
messages.
* include/bits/regex_automaton.tcc: Likewise.
* include/bits/regex_compiler.h: Likewise.
* include/bits/regex_compiler.tcc: Likewise.
* include/bits/regex_scanner.h: Likewise.
* include/bits/regex_scanner.tcc: Likewise.

Re: dejagnu version update?

[David Malcolm]

On Wed, 2015-09-16 at 10:36 -0600, Jeff Law wrote:
> On 09/16/2015 10:25 AM, Ramana Radhakrishnan wrote:
> >
> >
> > On 16/09/15 17:14, Mike Stump wrote:
> >> On Sep 16, 2015, at 12:29 AM, Andreas Schwab 
> >> wrote:
> >>> Mike Stump  writes:
> >>>
>  The software presently works with 1.4.4 and there aren’t any
>  changes that require anything newer.
> >>>
> >>> SLES 12 has 1.4.4.
> >>
> >> Would be nice to cover them as well, but their update schedule, 3-4
> >> years, means that their next update is 2018.  They didn’t update to
> >> a 3 year old stable release of dejagnu for their last OS, meaning
> >> they are on a > 7 year update cycle.  I love embedded and really
> >> long term support cycles (20 years), but, don’t think we should
> >> cater to the 20 year cycle just yet.  :-)  Since 7 is substantially
> >> longer than 2, I don’t think we should worry about it.  If they had
> >> updated at the time, they would have had 3 years of engineering and
> >> testing before the release and _had_ 1.5.
> >>
> >
> > Sorry about the obvious (possibly dumb) question.
> >
> > Can't we just import a copy of dejagnu each year and install it as
> > part of the source tree ? I can't imagine installing dejagnu is
> > adding a huge amount of time to build and regression test time ?
> > Advantage is that everyone is guaranteed to be on the same version. I
> > fully expect resistance due to specific issues with specific versions
> > of tcl and expect, but if folks aren't aware of this .
> That should work -- certainly that's the way we used to do things at 
> Cygnus.  Some of that code may have bitrotted as single tree builds have 
> fallen out-of-favor through the years.
> 
> As to whether or  not its a good idea.  I'm torn -- I don't like copying 
> code from other repos because of the long term maintenance concerns.
> 
> I'd rather just move to 1.5 and get on with things. 

AIUI, we specifically need >= 1.5.3 (or a version with a backport) to
get support for multiple load_lib paths mentioned by Bernhard, which is
what motivated this thread (on gcc-patches, before it spread to the gcc
list):
 https://gcc.gnu.org/ml/gcc-patches/2015-09/msg01196.html
 https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00983.html

> If some systems 
> don't have a new enough version, I'm comfortable telling developers on 
> those platforms that they need to update.  It's not like every *user* 
> needs dejagnu, it's just for the testing side of things.
> 
> 
> jeff

PR pretty-print/67567 do not pass NULL as a string

[Manuel López-Ibáñez]

Fortran passes NULL where a non-null string is expected by the pretty-printer,
which causes a sanitizer warning. This could have been found earlier by using
gcc_checking_assert. Even if the assertion is false, the result is just an
incomplete diagnostic, thus it seems more user-friendly to assert only when
checking. I do not have any idea how to properly fix the Fortran bug, thus this
patch simply works-around it.

Bootstrapped & regtested on x86_64-linux-gnu.

OK?

gcc/fortran/ChangeLog:

2015-09-15  Manuel López-Ibáñez  

PR pretty-print/67567
* resolve.c (resolve_fl_procedure): Work-around when iface->module
== NULL.

gcc/ChangeLog:

2015-09-15  Manuel López-Ibáñez  

PR pretty-print/67567
* pretty-print.c (pp_string): Add gcc_checking_assert.
* pretty-print.h (output_buffer_append_r): Likewise.
Index: gcc/pretty-print.c
===
--- gcc/pretty-print.c  (revision 227762)
+++ gcc/pretty-print.c  (working copy)
@@ -903,11 +903,12 @@ pp_character (pretty_printer *pp, int c)
 /* Append a STRING to the output area of PRETTY-PRINTER; the STRING may
be line-wrapped if in appropriate mode.  */
 void
 pp_string (pretty_printer *pp, const char *str)
 {
-  pp_maybe_wrap_text (pp, str, str + (str ? strlen (str) : 0));
+  gcc_checking_assert (str);
+  pp_maybe_wrap_text (pp, str, str + strlen (str));
 }
 
 /* Maybe print out a whitespace if needed.  */
 
 void
Index: gcc/pretty-print.h
===
--- gcc/pretty-print.h  (revision 227762)
+++ gcc/pretty-print.h  (working copy)
@@ -137,10 +137,11 @@ output_buffer_formatted_text (output_buf
 /* Append to the output buffer a string specified by its
STARTing character and LENGTH.  */
 static inline void
 output_buffer_append_r (output_buffer *buff, const char *start, int length)
 {
+  gcc_checking_assert (start);
   obstack_grow (buff->obstack, start, length);
   buff->line_length += length;
 }
 
 /*  Return a pointer to the last character emitted in the
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (revision 227762)
+++ gcc/fortran/resolve.c   (working copy)
@@ -11738,11 +11738,14 @@ resolve_fl_procedure (gfc_symbol *sym, i
   /* Check the procedure characteristics.  */
   if (sym->attr.pure != iface->attr.pure)
{
  gfc_error ("Mismatch in PURE attribute between MODULE "
 "PROCEDURE at %L and its interface in %s",
-&sym->declared_at, iface->module);
+&sym->declared_at, 
+/* FIXME: PR fortran/67567: iface->module should
+   not be NULL !  */
+iface->module ? iface->module : "");
  return false;
}
 
   if (sym->attr.elemental != iface->attr.elemental)
{
@@ -11754,20 +11757,26 @@ resolve_fl_procedure (gfc_symbol *sym, i
 
   if (sym->attr.recursive != iface->attr.recursive)
{
  gfc_error ("Mismatch in RECURSIVE attribute between MODULE "
 "PROCEDURE at %L and its interface in %s",
-&sym->declared_at, iface->module);
+&sym->declared_at, 
+/* FIXME: PR fortran/67567: iface->module should
+   not be NULL !  */
+iface->module ? iface->module : "");
  return false;
}
 
   /* Check the result characteristics.  */
   if (!gfc_check_result_characteristics (sym, iface, errmsg, 200))
{
  gfc_error ("%s between the MODULE PROCEDURE declaration "
 "in module %s and the declaration at %L in "
-"SUBMODULE %s", errmsg, iface->module,
+"SUBMODULE %s", errmsg, 
+/* FIXME: PR fortran/67567: iface->module should
+   not be NULL !  */
+iface->module ? iface->module : "",
 &sym->declared_at, sym->ns->proc_name->name);
  return false;
}
 
 check_formal:

[PATCH] Move check_global_declaration from toplev.c to cgraphunit.c

[Manuel López-Ibáñez]

Unfortunately, toplev.c is a kitchen sink of things that do not belong
anywhere in particular.
For example, check_global_declarations is only used in cgraphunit.c.
Moving it there allows us to make it static and remove one call to
symtab_node::get.

Bootstrapped & regtested on x86_64-linux-gnu.

OK?

gcc/ChangeLog:

2015-09-15  Manuel López-Ibáñez  

* toplev.h (check_global_declaration): Remove declaration.
* toplev.c (check_global_declaration): Move to ...
* cgraphunit.c: ... here. Make it static and pass a symtab_node *.
(analyze_functions): Update call.
Index: gcc/toplev.c
===
--- gcc/toplev.c(revision 227762)
+++ gcc/toplev.c(working copy)
@@ -467,73 +467,10 @@ wrapup_global_declarations (tree *vec, i
   while (reconsider);
 
   return output_something;
 }
 
-/* Issue appropriate warnings for the global declaration DECL.  */
-
-void
-check_global_declaration (tree decl)
-{
-  /* Warn about any function declared static but not defined.  We don't
- warn about variables, because many programs have static variables
- that exist only to get some text into the object file.  */
-  symtab_node *snode = symtab_node::get (decl);
-  if (TREE_CODE (decl) == FUNCTION_DECL
-  && DECL_INITIAL (decl) == 0
-  && DECL_EXTERNAL (decl)
-  && ! DECL_ARTIFICIAL (decl)
-  && ! TREE_NO_WARNING (decl)
-  && ! TREE_PUBLIC (decl)
-  && (warn_unused_function
- || snode->referred_to_p (/*include_self=*/false)))
-{
-  if (snode->referred_to_p (/*include_self=*/false))
-   pedwarn (input_location, 0, "%q+F used but never defined", decl);
-  else
-   warning (OPT_Wunused_function, "%q+F declared % but never 
defined", decl);
-  /* This symbol is effectively an "extern" declaration now.  */
-  TREE_PUBLIC (decl) = 1;
-}
-
-  /* Warn about static fns or vars defined but not used.  */
-  if (((warn_unused_function && TREE_CODE (decl) == FUNCTION_DECL)
-   || (((warn_unused_variable && ! TREE_READONLY (decl))
-   || (warn_unused_const_variable && TREE_READONLY (decl)))
-  && TREE_CODE (decl) == VAR_DECL))
-  && ! DECL_IN_SYSTEM_HEADER (decl)
-  && ! snode->referred_to_p (/*include_self=*/false)
-  /* This TREE_USED check is needed in addition to referred_to_p
-above, because the `__unused__' attribute is not being
-considered for referred_to_p.  */
-  && ! TREE_USED (decl)
-  /* The TREE_USED bit for file-scope decls is kept in the identifier,
-to handle multiple external decls in different scopes.  */
-  && ! (DECL_NAME (decl) && TREE_USED (DECL_NAME (decl)))
-  && ! DECL_EXTERNAL (decl)
-  && ! DECL_ARTIFICIAL (decl)
-  && ! DECL_ABSTRACT_ORIGIN (decl)
-  && ! TREE_PUBLIC (decl)
-  /* A volatile variable might be used in some non-obvious way.  */
-  && ! TREE_THIS_VOLATILE (decl)
-  /* Global register variables must be declared to reserve them.  */
-  && ! (TREE_CODE (decl) == VAR_DECL && DECL_REGISTER (decl))
-  /* Global ctors and dtors are called by the runtime.  */
-  && (TREE_CODE (decl) != FUNCTION_DECL
- || (!DECL_STATIC_CONSTRUCTOR (decl)
- && !DECL_STATIC_DESTRUCTOR (decl)))
-  /* Otherwise, ask the language.  */
-  && lang_hooks.decls.warn_unused_global (decl))
-warning_at (DECL_SOURCE_LOCATION (decl),
-   (TREE_CODE (decl) == FUNCTION_DECL)
-   ? OPT_Wunused_function
-   : (TREE_READONLY (decl)
-  ? OPT_Wunused_const_variable
-  : OPT_Wunused_variable),
-   "%qD defined but not used", decl);
-}
-
 /* Compile an entire translation unit.  Write a file of assembly
output and various debugging dumps.  */
 
 static void
 compile_file (void)
Index: gcc/toplev.h
===
--- gcc/toplev.h(revision 227762)
+++ gcc/toplev.h(working copy)
@@ -59,11 +59,10 @@ extern void init_eh (void);
 extern void announce_function (tree);
 
 extern void wrapup_global_declaration_1 (tree);
 extern bool wrapup_global_declaration_2 (tree);
 extern bool wrapup_global_declarations (tree *, int);
-extern void check_global_declaration (tree);
 
 extern void global_decl_processing (void);
 
 extern void dump_memory_report (bool);
 extern void dump_profile_report (void);
Index: gcc/cgraphunit.c
===
--- gcc/cgraphunit.c(revision 227762)
+++ gcc/cgraphunit.c(working copy)
@@ -921,10 +921,73 @@ walk_polymorphic_call_targets (hash_set<
}
}
 }
 }
 
+/* Issue appropriate warnings for the global declaration DECL.  */
+
+static void
+check_global_declaration (symtab_node *snode)
+{
+  tree decl = snode->decl;
+
+  /* Warn about any function declared static but not defined.  We don't
+ warn about variables, bec

Re: dejagnu version update?

[Mike Stump]

On Sep 16, 2015, at 9:25 AM, Ramana Radhakrishnan 
 wrote:
> 
> Sorry about the obvious (possibly dumb) question.

> Can't we just import a copy of dejagnu each year and install it as part of 
> the source tree?

TL;DR: No.

We could, and indeed, some people do engineering that way.  We instead depend 
upon package managers, software updates and backwards compatibility to manage 
the issue.  This is generally speaking, a better way to do software. In the 
olden days, back before shared libraries, X11 was the straw that broke the 
camels back.  Without shared libraries, everyone replicated large portions of 
the X11 system inside each binary causing a massive bloat just in terms of disk 
space.  This cost was also reflected in distribution size.  As multiple 
binaries were run, each program would replicate all the code and read only data 
of the X11 window system causing larger than optimal usage of ram.  The problem 
was so fundamental and so compelling to fix that dllhell[1] was born.  It was 
the price we paid, for the solution to the original problem.  Now, the good 
news is that dllhell is trivial to avoid and engineer around so that it doesn’t 
exist.  People that can program their way out of a paper bag can do it without 
even thinking about it.  So, where we are today, it is a non-issue as it is a 
solved problem.  Since it is solved, we don’t need to do things like unshare 
programs, libraries, kernels or executables anymore.  Indeed, it is so 
completely and fundamentally solved that we can now use the desire to unshare 
as an indicator that someone in the food chain doesn’t have a clue what they 
are doing.  Windows is notorious for instances where people have not yet 
attained the right skill set yet.  In our case, since we can contribute 
anything we want, to any package we want, because we are open source, we can 
avoid, fix and do the good engineering required to avoid dllhell.  This makes 
it so that fundamentally, we never have to unshare, by design.  This is but one 
benefit of open source.

One day, we will advance and configure && make will automatically fetch and 
install the required components that we need for a build, using the single 
command that on every system, resolves dependancies and installs dependent 
software.  We aren’t there yet, but, that is were we need to go.  Once we get 
that, we should depend on it and use it, and never look back, then discussions 
like this never ever take place again, because the first person that wanted 
1.5.3 would just put it in, update the 1.4.4 string to 1.5.3 and Bob’s your 
uncle.  No discussion, no asking, no worries.  That’s the path forward.

The current problem is that everyone wants to solve the dependency problem with 
their own tool and that tool is different on every system.  The entire software 
ecosystem would be better off if all these people contributed what they need to 
the design of a replacement and we all moved to one system.

1 - https://en.wikipedia.org/wiki/DLL_Hell

Go patch committed: Don't crash on erroneous channel reads

[Ian Lance Taylor]

This patch by Chris Manghane fixes the Go frontend to not crash on
erroneous channel reads.  This fixes https://golang.org/issue/12320 .
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 227830)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-79f457a267ff2bf8e65db4bcec0cbc7add79227a
+1cb26dc898bda1e85f4dd2ee204adbce792e4813
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: gcc/go/gofrontend/expressions.cc
===
--- gcc/go/gofrontend/expressions.cc(revision 227830)
+++ gcc/go/gofrontend/expressions.cc(working copy)
@@ -3472,6 +3472,15 @@ Unsafe_type_conversion_expression::do_ge
 
   Type* t = this->type_;
   Type* et = this->expr_->type();
+
+  if (t->is_error_type()
+  || this->expr_->is_error_expression()
+  || et->is_error_type())
+{
+  go_assert(saw_errors());
+  return context->backend()->error_expression();
+}
+
   if (t->array_type() != NULL)
 go_assert(et->array_type() != NULL
   && t->is_slice_type() == et->is_slice_type());

Re: [PATCH, rs6000] Add expansions for min/max vector reductions

[Alan Lawrence]

On 16/09/15 17:19, Bill Schmidt wrote:

On Wed, 2015-09-16 at 16:29 +0100, Alan Lawrence wrote:


I proposed a patch to migrate PPC off the old patterns, but have forgotten to
ping it recently - last at
https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01024.html ... (ping?!)



Hi Alan,

Thanks for this patch.  I see that you tested it on gcc110, which is a
big-endian platform.  I think the pattern for V4SF might have an endian
problem on little-endian, but I'm not positive just eyeballing it.  (I
think that the select of element 3 will address the wrong end of the
vector for LE.)  Can you please try the patch on gcc112 as well to set
my mind at ease?

Thanks,
Bill


--Alan






I think you are rightI'm just retesting without the patch to rule out other 
test setup problems etc., but I see more tests failing on gcc112 than I expect 
(comparing against e.g.

https://gcc.gnu.org/ml/gcc-testresults/2015-09/msg01479.html).

What's the best way to determine endianness - is it BYTES_BIG_ENDIAN, would that 
be true on gcc110 but false on gcc112?


Cheers, Alan

Re: [PATCH, rs6000] Add expansions for min/max vector reductions

[Bill Schmidt]

On Wed, 2015-09-16 at 19:16 +0100, Alan Lawrence wrote:
> On 16/09/15 17:19, Bill Schmidt wrote:
> > On Wed, 2015-09-16 at 16:29 +0100, Alan Lawrence wrote:
> >>
> >> I proposed a patch to migrate PPC off the old patterns, but have forgotten 
> >> to
> >> ping it recently - last at
> >> https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01024.html ... (ping?!)
> >>
> >
> > Hi Alan,
> >
> > Thanks for this patch.  I see that you tested it on gcc110, which is a
> > big-endian platform.  I think the pattern for V4SF might have an endian
> > problem on little-endian, but I'm not positive just eyeballing it.  (I
> > think that the select of element 3 will address the wrong end of the
> > vector for LE.)  Can you please try the patch on gcc112 as well to set
> > my mind at ease?
> >
> > Thanks,
> > Bill
> >
> >> --Alan
> >>
> >
> >
> 
> I think you are rightI'm just retesting without the patch to rule out 
> other 
> test setup problems etc., but I see more tests failing on gcc112 than I 
> expect 
> (comparing against e.g.
> https://gcc.gnu.org/ml/gcc-testresults/2015-09/msg01479.html).
> 
> What's the best way to determine endianness - is it BYTES_BIG_ENDIAN, would 
> that 
> be true on gcc110 but false on gcc112?

Yes, that's the correct test, thanks!

Bill

> 
> Cheers, Alan
> 

Re: [PATCH][C++] Avoid PCH dependent mangling

[Jason Merrill]

OK.

Jason

Re: dejagnu version update?

[Bernhard Reutner-Fischer]

On September 16, 2015 7:57:03 PM GMT+02:00, Mike Stump  
wrote:
>On Sep 16, 2015, at 9:25 AM, Ramana Radhakrishnan
> wrote:
>> 
>> Sorry about the obvious (possibly dumb) question.
>
>> Can't we just import a copy of dejagnu each year and install it as
>part of the source tree?
>
>TL;DR: No.
>
>We could, and indeed, some people do engineering that way.  We instead
>depend upon package managers, software updates and backwards
>compatibility to manage the issue.  This is generally speaking, a
>better way to do software. In the olden days, back before shared
>libraries, X11 was the straw that broke the camels back. 

[Well some thus later had KGI, GGI and fresco (the interviews thing), but 
that's another story for sure ;) ]

Either way. Importing doesn't make sense at all.

Establishing and maintaining duplicated gcc_load_lib cascades don't either IMO. 
If folks feel maintaining them is less hazzle than forcing a new dejagnu then 
fine with me (although we do require pretty recent libs anyway and developers 
will usually likewise use rather recent binutils et al for obvious reasons).

Re: [patch] libstdc++/67173 Fix filesystem::canonical for Solaris 10.

[Jonathan Wakely]

On 16/09/15 11:36 -0600, Martin Sebor wrote:

It turns out I was wrong about BSD traditionally supporting
realpath(path, NULL), it first appeared in these relatively recent
versions:

FreeBSD 9.0
OpenBSD 5.0
NetBSD 6.1

Like Solaris 11, some of them still define _POSIX_VERSION=200112L even
though they support passing NULL,  so we could hardcode the targets
that are known to support it, but we'll still need a fallback for lots
of slightly older targets anyway.

So here's a new implementation of canonical() which only uses
realpath() when this autoconf compile-or-link test passes:

#if _XOPEN_VERSION < 500
#error
#elif _XOPEN_VERSION >= 700 || defined(PATH_MAX)
char *tmp = realpath((const char*)NULL, (char*)NULL);
#else
#error
#endif

i.e. I use realpath() for Issue 7, or for Issue 6 if PATH_MAX is
defined.


I probably wouldn't code the PATH_MAX test quite the same way.
I would expect it to be mainly Issue 6 implementations that don't
define the macro to want to provide the null extension since there
would otherwise be no safe way to use the function.


OK.


I didn't test it at all but I'd be inclined to write the conditional
to look more along these lines:

 #if _XOPEN_VERSION >= 700
   // Issue 7 and better -- null resolved_name means allocate
   char *tmp = realpath (file_name, (char*)NULL);
 #elif _XOPEN_VERSION == 600
// Issue 6 -- null resolved_name is implementation-defined
 #  if FreeBSD 9.0 or OpenBSD 5.0 or NetBSD 6.1
   char *tmp = realpath (file_name, (char*)NULL);
 #  elif PATH_MAX
   char *tmp = realpath (file_name, malloc (PATH_MAX));
 #  else
 #error No safe way to call realpath
 #  endif
 #elif _XOPEN_VERSION && PATH_MAX
   // SUSv2 -- null resolved_name is an error
   char *tmp = realpath (file_name, malloc (PATH_MAX));
 #else
 #  error realpath not supported or no safe way to call it
 #endif


That would allow us to use realpath() on more targets, so would be a
good improvement, but I think it can wait for a later date. I think we
might also want two macros, USE_REALPATH and USE_REALPATH_NULL,
otherwise we just have to repeat the conditions in
src/filesystem/ops.cc to decide whether to use malloc() or not.

But I think the best solution for now is to not define any *_SOURCE
macros in the configure checks or in the source code (due to the
problem on NetBSD when _XOPEN_SOURCE is defined). If a new enough
_XOPEN_VERSION happens to be defined anyway (maybe due to an implicit
_GNU_SOURCE, or just a target where it's the default) then we'll use
realpath(), otherwise we use the fallback C++ implementation.

Here's a patch to do that, it's substantially the same as the last one
but doesn't define _XOPEN_SOURCE, and also tweaks some tests.

Tested powerpc64le-linux, x86_64-dragonfly4.1 and x86_64-netbsd5.1,
do you see any reason not to commit this for now?

Any improvements such as hardcoding checks for specific versions of
Solaris or the BSDs are QoI, and this is only an experimental TS, so I
don't want to spend the rest of stage 1 working on one function :-)



Then in filesystem::canonical() if _GLIBCXX_USE_REALPATH is set I use
it, passing NULL for Issue 7, or allocating a buffer of PATH_MAX
otherwise. If realpath isn't supported or fails with ENAMETOOLONG then
I do the path traversal by hand (which can be done entirely using the
std::experimental::filesystem operations).


FWIW, to work across filesystems with different _PC_PATH_MAX, I
suspect the operations might need to use readlinkat. I.e., they
might need to descend into each individual subdirectory to avoid
forming a temporary pathname that's too long for the file system
being traversed, even though both the initial and the final
pathnames are under the limit. (I haven't actually tested this
but I don't see where GLIBC handles this case so it might not
do the right thing either.)



Yes, I was planning to do it that way originally, then realised that
it can be done purely in C++ with the new filesystem API, which was
much easier!

It would be better to use openat() for each dir and use the *at()
functions, but I'd have to get my copy of Stevens out and read lots of
man pages, where as I already know the C++ API because I've recently
implemented the entire thing myself :-)

In an ideal world, with infinite time, it might be nice to create a
hybrid of the C++ Filesystem API and the *at() functions, even if only
for use internally in the library. It might reduce the number of
stat() calls, or at least the number of similar path traversals, if we
used openat(), fstatat() etc.

The Filesystem TS deals entirely in paths, because that's the only way
to be portable to both POSIX and Windows, but it would be really nice
to have a similar API based on file descriptors. It would certainly
make some things a lot more efficient.

A quick grep tells me that Boost.Filesystem doesn't use openat()
anywhere, and users have been happy with that implementation for many
years, so again I think improvements like this can wait (but feel free
to add s

Re: dejagnu version update?

[Bernhard Reutner-Fischer]

On September 16, 2015 7:39:42 PM GMT+02:00, David Malcolm  
wrote:
>On Wed, 2015-09-16 at 10:36 -0600, Jeff Law wrote:
>> On 09/16/2015 10:25 AM, Ramana Radhakrishnan wrote:
>> >
>> >
>> > On 16/09/15 17:14, Mike Stump wrote:
>> >> On Sep 16, 2015, at 12:29 AM, Andreas Schwab 
>> >> wrote:
>> >>> Mike Stump  writes:
>> >>>
>>  The software presently works with 1.4.4 and there aren’t any
>>  changes that require anything newer.
>> >>>
>> >>> SLES 12 has 1.4.4.
>> >>
>> >> Would be nice to cover them as well, but their update schedule,
>3-4
>> >> years, means that their next update is 2018.  They didn’t update
>to
>> >> a 3 year old stable release of dejagnu for their last OS, meaning
>> >> they are on a > 7 year update cycle.  I love embedded and really
>> >> long term support cycles (20 years), but, don’t think we should
>> >> cater to the 20 year cycle just yet.  :-)  Since 7 is
>substantially
>> >> longer than 2, I don’t think we should worry about it.  If they
>had
>> >> updated at the time, they would have had 3 years of engineering
>and
>> >> testing before the release and _had_ 1.5.
>> >>
>> >
>> > Sorry about the obvious (possibly dumb) question.
>> >
>> > Can't we just import a copy of dejagnu each year and install it as
>> > part of the source tree ? I can't imagine installing dejagnu is
>> > adding a huge amount of time to build and regression test time ?
>> > Advantage is that everyone is guaranteed to be on the same version.
>I
>> > fully expect resistance due to specific issues with specific
>versions
>> > of tcl and expect, but if folks aren't aware of this .
>> That should work -- certainly that's the way we used to do things at 
>> Cygnus.  Some of that code may have bitrotted as single tree builds
>have 
>> fallen out-of-favor through the years.
>> 
>> As to whether or  not its a good idea.  I'm torn -- I don't like
>copying 
>> code from other repos because of the long term maintenance concerns.
>> 
>> I'd rather just move to 1.5 and get on with things. 
>
>AIUI, we specifically need >= 1.5.3 (or a version with a backport) to
>get support for multiple load_lib paths mentioned by Bernhard, which is
>what motivated this thread (on gcc-patches, before it spread to the gcc
>list):
> https://gcc.gnu.org/ml/gcc-patches/2015-09/msg01196.html
> https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00983.html

And
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01395.html

Where Joseph said he'd wait some more.. I had thought I asked longer ago than 
that, time flies if one has fun.

I'd just require 1.5.3 just to avoid the time needed by folks to workaround 
those silly ordering gotchas and load cascades that propagate through the tree. 
Admittedly not my call but a pity IMHO.

Thanks,

Re: [PATCH] Move check_global_declaration from toplev.c to cgraphunit.c

[Jeff Law]

On 09/16/2015 11:54 AM, Manuel López-Ibáñez wrote:

Unfortunately, toplev.c is a kitchen sink of things that do not belong
anywhere in particular.
For example, check_global_declarations is only used in cgraphunit.c.
Moving it there allows us to make it static and remove one call to
symtab_node::get.

Bootstrapped & regtested on x86_64-linux-gnu.

OK?

gcc/ChangeLog:

2015-09-15  Manuel López-Ibáñez  

 * toplev.h (check_global_declaration): Remove declaration.
 * toplev.c (check_global_declaration): Move to ...
 * cgraphunit.c: ... here. Make it static and pass a symtab_node *.
 (analyze_functions): Update call.
I'm not really sure that passing in the symtab node is better than the 
underlying decl.  But I doubt it really matters in practice.


Ok for the trunk.
jeff

Re: [PATCH] Update ENABLE_CHECKING to make it usable in "if" conditions

[Jeff Law]

On 09/15/2015 04:11 AM, Richard Biener wrote:


I wouldn't expect to see any in the .c files.   There'll likely be
stragglers (like tree/rtl checking).  But even flushing all the stuff out of
the .c files is a major win.

Do you have a preference on whether or not to make flag_checking a pre, post
or integrated patch?  I can see arguments for any of those three choices.


I'd like to see it as part of the patch, even if the initial
implementation would be a

static const int flag_checking = CHECKING_P;

in flags.h so we can avoid chaging all uses twice.  It requires some
more careful
review of what uses are changed to flag_checking and which one to CHECKING_P
of course which means it would make sense to do it as a pre patch handling the
obvious cases first.  And then adding -fchecking "properly" wouldn't be too hard
anyway.

That works for me.  Mikhail, can you move things in that direction?

jeff

Re: (patch,rfc) s/gimple/gimple */

[David Malcolm]

On Wed, 2015-09-16 at 09:16 -0400, Trevor Saunders wrote:
> Hi,
> 
> I gave changing from gimple to gimple * a shot last week.  It turned out
> to be not too hard.  As you might expect the patch is huge so its
> attached compressed.
> 
> patch was bootstrapped + regtested on x86_64-linux-gnu, and run through
> config-list.mk.  However I needed to update it some for changes made
> while testing.  Do people want to make this change now?  If so I'll try
> and commit the patch over the weekend when less is changing.


FWIW there are some big changes in gcc/tree-vect-slp.c:vectorizable_load
that looks like unrelated whitespace changes, e.g. the following (and
there are some followup hunks).  Did something change underneath, or was
there a stray whitespace cleanup here?  (I skimmed through the patch,
and this was the only file I spotted where something looked wrong)


@@ -6755,473 +6754,473 @@ vectorizable_load (gimple stmt, gimple_stmt_iterator 
*gsi, gimple *vec_stmt,
   gcc_assert (alignment_support_scheme);
   /* Targets with load-lane instructions must not require explicit
  realignment.  */
-  gcc_assert (!load_lanes_p
- || alignment_support_scheme == dr_aligned
- || alignment_support_scheme == dr_unaligned_supported);
-
-  /* In case the vectorization factor (VF) is bigger than the number
- of elements that we can fit in a vectype (nunits), we have to generate
- more than one vector stmt - i.e - we need to "unroll" the
- vector stmt by a factor VF/nunits.  In doing so, we record a pointer
- from one copy of the vector stmt to the next, in the field
- STMT_VINFO_RELATED_STMT.  This is necessary in order to allow following
- stages to find the correct vector defs to be used when vectorizing
- stmts that use the defs of the current stmt.  The example below
- illustrates the vectorization process when VF=16 and nunits=4 (i.e., we
- need to create 4 vectorized stmts):
-
- before vectorization:
-RELATED_STMTVEC_STMT
-S1: x = memref  -   -
-S2: z = x + 1   -   -
-
- step 1: vectorize stmt S1:
-We first create the vector stmt VS1_0, and, as usual, record a
-pointer to it in the STMT_VINFO_VEC_STMT of the scalar stmt S1.
-Next, we create the vector stmt VS1_1, and record a pointer to
-it in the STMT_VINFO_RELATED_STMT of the vector stmt VS1_0.
-Similarly, for VS1_2 and VS1_3.  This is the resulting chain of
-stmts and pointers:
-RELATED_STMTVEC_STMT
-VS1_0:  vx0 = memref0   VS1_1   -
-VS1_1:  vx1 = memref1   VS1_2   -
-VS1_2:  vx2 = memref2   VS1_3   -
-VS1_3:  vx3 = memref3   -   -
-S1: x = load-   VS1_0
-S2: z = x + 1   -   -
-
- See in documentation in vect_get_vec_def_for_stmt_copy for how the
- information we recorded in RELATED_STMT field is used to vectorize
- stmt S2.  */
-
-  /* In case of interleaving (non-unit grouped access):
-
- S1:  x2 = &base + 2
- S2:  x0 = &base
- S3:  x1 = &base + 1
- S4:  x3 = &base + 3
-
- Vectorized loads are created in the order of memory accesses
- starting from the access of the first stmt of the chain:
-
- VS1: vx0 = &base
- VS2: vx1 = &base + vec_size*1
- VS3: vx3 = &base + vec_size*2
- VS4: vx4 = &base + vec_size*3
-
- Then permutation statements are generated:
-
- VS5: vx5 = VEC_PERM_EXPR < vx0, vx1, { 0, 2, ..., i*2 } >
- VS6: vx6 = VEC_PERM_EXPR < vx0, vx1, { 1, 3, ..., i*2+1 } >
-   ...
-
- And they are put in STMT_VINFO_VEC_STMT of the corresponding scalar stmts
- (the order of the data-refs in the output of vect_permute_load_chain
- corresponds to the order of scalar stmts in the interleaving chain - see
- the documentation of vect_permute_load_chain()).
- The generation of permutation stmts and recording them in
- STMT_VINFO_VEC_STMT is done in vect_transform_grouped_load().
-
- In case of both multiple types and interleaving, the vector loads and
- permutation stmts above are created for every copy.  The result vector
- stmts are put in STMT_VINFO_VEC_STMT for the first copy and in the
- corresponding STMT_VINFO_RELATED_STMT for the next copies.  */
-
-  /* If the data reference is aligned (dr_aligned) or potentially unaligned
- on a target that supports unaligned accesses (dr_unaligned_supported)
- we generate the following code:
- p = initial_addr;
- indx = 0;
- loop {
-  p = p + indx * vectype_size;
-   vec_dest = *(p);
-   indx = indx + 1;
- }
-
- Otherwise, the data reference is potentially unaligned on a target that
- does not support unaligned accesses (dr_explicit_realign_optimized) -
- then generate the f

Re: [C++] Coding rule enforcement

[Bernhard Reutner-Fischer]

On September 16, 2015 6:32:46 PM GMT+02:00, "Manuel López-Ibáñez" 
 wrote:
>On 16/09/15 16:36, Nathan Sidwell wrote:
>> On 09/16/15 10:23, Jason Merrill wrote:
>>> On 09/16/2015 08:02 AM, Nathan Sidwell wrote:
 +  else if (warn_multiple_inheritance)
 +warning (OPT_Wmultiple_inheritance,
 + "%qT defined with multiple direct bases", ref);
>>>
>>> You don't need to guard the warning with a check of the warning
>flag; warning
>>> will only give the warning if the option is enabled.
>>
>> hm, it didn't seem to be doing that.  Perhaps  I'd got something
>wrong ...looking
>
>Perhaps because you misspelled Warning here?
>
>+Wmultiple-inheritance
>+C++ ObjC++ Var(warn_multiple_inheritance) Warninng
>+Warn on direct multiple inheritance
>+
>
>The awk scripts that parse the .opt files are not as smart as they
>could be.

Ouch, unrecognised keywords there should barf really loud.
Great bug.

Re: [PATCH] Update ENABLE_CHECKING to make it usable in "if" conditions

[Mikhail Maltsev]

On 09/10/2015 12:07 AM, Jeff Law wrote:
>> On Mon, Aug 31, 2015 at 7:49 AM, Mikhail Maltsev 
>>> In lra.c we have:
>>>
>>> #ifdef ENABLE_CHECKING
>>>
>>>   /* Function checks RTL for correctness. If FINAL_P is true, it is
>>>  done at the end of LRA and the check is more rigorous.  */
>>>   static void
>>>   check_rtl (bool final_p)
>>> ...
>>> #ifdef ENABLED_CHECKING
>>>  extract_constrain_insn (insn);
>>> #endif
>>> ...
>>> #endif /* #ifdef ENABLE_CHECKING */
>>>
>>> The comment for extract_constrain_insn says:
>>> /* Do uncached extract_insn, constrain_operands and complain about
>>> failures.
>>> This should be used when extracting a pre-existing constrained
>>> instruction
>>> if the caller wants to know which alternative was chosen.  */
>>>
>>> So, as I understand, this additional check can be useful. This patch
>>> removes
>>> "#ifdef ENABLED_CHECKING" (without regressions).
> No strong opinions here.  There's other things that would catch this
> later.  The check merely catches it closer to the point where things go
> wrong.  So I'd tend to want it to be conditional.
> 
But please notice that the inner condition checks for
"ENABLE*D*_CHECKING", so the code guarded by it does not get executed
even in "checking" build. Such spelling is not used anywhere in the code
(except for this place in lra.c), so for me it looks like a typo (if it
is not, then it's really misleading, because it's very easy to confuse
ENABLE/ENABLED_CHECKING). Changing the condition to "ENABLE_CHECKING"
will make it useless because the code is already guarded by
ENABLE_CHECKING, that's why I proposed to remove the "#ifdef".

On 09/16/2015 10:10 PM, Jeff Law wrote:
>> I'd like to see it as part of the patch, even if the initial
>> implementation would be a
>>
>> static const int flag_checking = CHECKING_P;
>>
>> in flags.h so we can avoid chaging all uses twice.  It requires some
>> more careful
>> review of what uses are changed to flag_checking and which one to
>> CHECKING_P
>> of course which means it would make sense to do it as a pre patch
>> handling the
>> obvious cases first.  And then adding -fchecking "properly" wouldn't
>> be too hard
>> anyway.
> That works for me.  Mikhail, can you move things in that direction?

Yes, I hope to continue working on this patch (i.e. split it into
smaller pieces and convert it to use flags instead of macros) during
this weekend.

-- 
Regards,
Mikhail Maltsev

Re: dejagnu version update?

[Ramana Radhakrishnan]

On Wed, Sep 16, 2015 at 11:27 PM, Mike Stump  wrote:
> On Sep 16, 2015, at 9:25 AM, Ramana Radhakrishnan 
>  wrote:
>>
>> Sorry about the obvious (possibly dumb) question.
>
>> Can't we just import a copy of dejagnu each year and install it as part of 
>> the source tree?
>
> TL;DR: No.

[snip]

Thanks for the refresher on dll hell ;)  My original inspiration for
thinking about the import just as I was leaving for the day was the
whole raft of target libraries we now build with gcc that are imported
 (for convenience, coupling with compiler features etc. etc. ), why
not do the same with what is essentially required for any developer ?
I also see that the coupling for dejagnu is probably best left to
packaging systems - however we have a situations where developers face
version skew for dejagnu with the systems they are forced to develop
and test on. The question was really whether we as a community thought
that this cost with dejagnu was worth it and for someone to ask that
obvious question.

I am happy to settle for dealing with dejagnu the same way as other
prerequisites like gmp, mpfr / mpc i.e. put out a hard error when
testing if the right version of dejagnu is not found. For bonus points
update download_prerequisites to get the right version in the source
tree for people using older distributions and not being in a position
to upgrade their packages.

regards
Ramana

Re: vector lightweight debug mode

[François Dumont]

On 14/09/2015 21:50, Jonathan Wakely wrote:
> On 14/09/15 20:27 +0200, François Dumont wrote:
>> Hi
>>
>>Here is what I had in mind when talking about moving debug checks to
>> the lightweight debug checks.
>
> Ah yes, I hadn't thought about removing reundant checks from the
> __gnu_debug containers, but that makes sense.
>
>>Sometimes the checks have been simply moved resulting in a simpler
>> debug vector implementation (front, back...). Sometimes I copy the
>> checks in a simpler form and kept the debug one too to make sure
>> execution of the debug code is fine.
>>
>>I plan to do the same for other containers.
>>
>>I still need to run tests, ok if tests are fine ?
>>
>> François
>>
>
>> diff --git a/libstdc++-v3/include/bits/stl_vector.h
>> b/libstdc++-v3/include/bits/stl_vector.h
>> index 305d446..89a9aec 100644
>> --- a/libstdc++-v3/include/bits/stl_vector.h
>> +++ b/libstdc++-v3/include/bits/stl_vector.h
>> @@ -449,6 +449,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
>>   vector&
>>   operator=(vector&& __x) noexcept(_Alloc_traits::_S_nothrow_move())
>>   {
>> +__glibcxx_assert(this != &__x);
>
> Please don't do this, it fails in valid programs. The standard needs
> to be fixed in this regard.

The debug mode check should be removed too then.

>
>> constexpr bool __move_storage =
>>   _Alloc_traits::_S_propagate_on_move_assign()
>>   || _Alloc_traits::_S_always_equal();
>> @@ -778,7 +779,10 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
>>*/
>>   reference
>>   operator[](size_type __n) _GLIBCXX_NOEXCEPT
>> -  { return *(this->_M_impl._M_start + __n); }
>> +  {
>> +__glibcxx_assert(__n < size());
>> +return *(this->_M_impl._M_start + __n);
>> +  }
>
> This could use __glibcxx_requires_subscript(__n), see the attached
> patch.

I thought you didn't want to use anything from debug.h so I try to
do with only __glibcxx_assert coming from c++config. I think your patch
is missing include of debug.h.

But I was going to propose to use _Error_formatter also in this
mode, I do not see any reason to not do so. The attached patch does just
that.

>
>>
>>   /**
>>*  @brief  Subscript access to the data contained in the %vector.
>> @@ -793,7 +797,10 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
>>*/
>>   const_reference
>>   operator[](size_type __n) const _GLIBCXX_NOEXCEPT
>> -  { return *(this->_M_impl._M_start + __n); }
>> +  {
>> +__glibcxx_assert(__n < size());
>> +return *(this->_M_impl._M_start + __n);
>> +  }
>>
>> protected:
>>   /// Safety check used only from at().
>> @@ -850,7 +857,10 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
>>*/
>>   reference
>>   front() _GLIBCXX_NOEXCEPT
>> -  { return *begin(); }
>> +  {
>> +__glibcxx_assert(!empty());
>
> This is __glibcxx_requires_nonempty(), already defined for
> _GLIBCXX_ASSERTIONS.
>
>> @@ -1051,6 +1071,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
>>   iterator
>>   insert(const_iterator __position, size_type __n, const
>> value_type& __x)
>>   {
>> +__glibcxx_assert(__position >= cbegin() && __position <= cend());
>> difference_type __offset = __position - cbegin();
>> _M_fill_insert(begin() + __offset, __n, __x);
>> return begin() + __offset;
>
> This is undefined behaviour, so I'd rather not add this check (I know
> it's on the google branch, but it's still undefined behaviour).

Why ? Because of the >= operator usage ? Is the attached patch better ?
< and == operators are well defined for a random access iterator, no ?

>
> We could do it with std::less, I suppose.
>
> I've attached the simplest checks I thought we should add for vector
> and deque.
>
>

diff --git a/libstdc++-v3/include/bits/stl_vector.h b/libstdc++-v3/include/bits/stl_vector.h
index 305d446..b84e653 100644
--- a/libstdc++-v3/include/bits/stl_vector.h
+++ b/libstdc++-v3/include/bits/stl_vector.h
@@ -63,6 +63,8 @@
 #include 
 #endif
 
+#include 
+
 namespace std _GLIBCXX_VISIBILITY(default)
 {
 _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
@@ -778,7 +780,10 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
*/
   reference
   operator[](size_type __n) _GLIBCXX_NOEXCEPT
-  { return *(this->_M_impl._M_start + __n); }
+  {
+	__glibcxx_requires_subscript(__n);
+	return *(this->_M_impl._M_start + __n);
+  }
 
   /**
*  @brief  Subscript access to the data contained in the %vector.
@@ -793,7 +798,10 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
*/
   const_reference
   operator[](size_type __n) const _GLIBCXX_NOEXCEPT
-  { return *(this->_M_impl._M_start + __n); }
+  {
+	__glibcxx_requires_subscript(__n);
+	return *(this->_M_impl._M_start + __n);
+  }
 
 protected:
   /// Safety check used only from at().
@@ -850,7 +858,10 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
*/
   reference
   front() _GLIBCXX_NOEXCEPT
-  { return *begin(); }
+  {
+	__glibcxx_req

Re: dejagnu version update?

[Mike Stump]

On Sep 16, 2015, at 12:02 PM, Bernhard Reutner-Fischer  
wrote:
> Where Joseph said he'd wait some more.. I had thought I asked longer ago than 
> that, time flies if one has fun.
> 
> I'd just require 1.5.3 just to avoid the time needed by folks to workaround 
> those silly ordering gotchas and load cascades that propagate through the 
> tree. Admittedly not my call but a pity IMHO.

If maintanence is a burden for those that usually maintain these things, we can 
by fiat just bump up to 1.5.3. It isn’t the end of the world if we do.  It just 
seems the cost isn’t that high to me, however I’m happy to defer to the people 
in the trench.  Since 1.5 isn’t going to ease what appears to be the main 
issue, I think status quo or 1.5.3 make the most sense.  So, let’s phrase it 
this way, if you work in the trench and are impacted, do you want to see the 
bump to 1.5.3 now to ease the burden?

Re: [patch match.pd c c++]: Ignore results of 'shorten_compare' and move missing patterns in match.pd

[Jeff Law]

On 09/15/2015 03:42 AM, Kai Tietz wrote:

2015-09-08  Kai Tietz  

  * gcc.dg/tree-ssa/vrp23.c: Adjust testcase to reflect that
  pattern is matching now already within forward-propagation pass.
  * gcc.dg/tree-ssa/vrp24.c: Likewise.


So for the new patterns, I would have expected testcases to ensure they're
getting used.


We were talking about that.  My approach was to disable shortening
code and see what regressions we get.  For C++ our test-coverage isn't
that good, as we didn't had here any regressions, but for C testcases
we got some.  Eg the testcase vrp25.c is one of them
But as I noted, I think that simply looking at testsuite regressions 
after disabling shorten_compare is not sufficient as I don't think we 
have significant coverage of this code.




By disabling "shorten_compare" one of most simple testcases, which is
failing, is:

int foo (short s, short t)
{
   int a = (int) s;
   int b = (int) t;

   return a >= b;
}
And I would argue it's precisely this kind of stuff we should be 
building tests around and resolving prior to actually disabling 
shorten_compare.





Where we miss to do narrow down SSA-tree comparison to simply s >= t;
If we disable fre-pass ( -fno-tree-fre) for current trunk, we can see
that this pattern gets resolved in forward-propagation pass due
invocation of shorten_compare.

Another simple one (with disabled "shorten_compare") is:

The following testcase:

int foo (unsigned short a)
{
   unsigned int b = 0;
   return (unsigned int) a) < b;
}

Here we lacked the detection of ((unsigned int) a) < b being a < 0
(which is always false).
And again, this deserves a test and resolving prior to disabling 
shorten_compare.







In *theory* one ought to be able to look at the dumps or .s files before
after this patch for a blob of tests and see that nothing significant has
changed.  Unfortunately, so much changes that it's hard to evaluate if this
patch is a step forward or a step back.


Hmm, actually we deal here with obvious patterns from
"shorten_compare".  Of interest are here the narrowing-lines on top of
this function, which we need to reflect in match.pd too, before we can
deprecate it. I don't get that there are so much changes?  This are in
fact just 3 basic patterns '(convert) X  (convert) Y',
'((convert) X)  CST', and a more specialized variant for the last
pattern for '==/!=' case.


I wonder if we'd do better to first add new match.pd patterns, one at a
time, with tests, and evaluating them along the way by looking at the dumps
or .s files across many systems.  Then when we think we've got the right
set, then look at what happens to those dumps/.s files if we make the
changes so that shorten_compare really just emits warnings.


As the shorten_compare function covers those transformations, I don't
see that this is something leading to something useful.  As long as we
call shorten_compare on folding in FEs, we won't see those patterns in
ME that easy.  And even more important is, that patterns getting
resolved if function gets invoked.
It will tell you what will be missed from a code generation standpoint 
if you disable shorten_compare.  And that is the best proxy we have for 
performance regressions related to disabling shorten_compare.


ie, in a local tree, you disable shorten_compare.  Then compare the code 
we generate with and without shorten compare.  Reduce to a simple 
testcase.  Resolve the issue with a match.pd pattern (most likely) and 
repeat the process.  In theory at each step the  number of things to 
deeply investigate should be diminishing while at the same time you're 
building match.pd patterns and tests we can include in the testsuite. 
And each step is likely a new patch in the patch series -- the final 
patch of which disables shorten_compare.


It's a lot of work, but IMHO, it's necessary to help ensure we don't 
have code generation regressions.







So I would suggest here to disable shorten_compare invocation and
cleanup with fallout detectable in C-FE's testsuite.
But without deeper analysis at the start & patches+testcases for those 
issues, we have a real risk of regressing the code we generate.





My worry is that we get part way through the conversion and end up with the
match.pd patterns without actually getting shorten_compare cleaned up and
turned into just a warning generator.


This worry I share, therefore I see it as mandatory to remove with
initial patch the use of result of shorten_compare, and better cleanup
possible detected additional fallout for other targets.  I just did
regression-testing for Intel-architecture (32-bit and 64-bit).
I would disagree that removing shorten_compare should come first.  I 
think you have to address the code generation regressions.And I 
think that the patches to address the code generation regressions need 
to be a series of patches with testcases.


What I don't want is a mega-patch that adds a ton of new patterns to 
match.pd with minimal/no tests and disables shor

Re: [PATCH 07/22] Implement token range tracking within libcpp and C/C++ FEs

[David Malcolm]

On Tue, 2015-09-15 at 12:48 +0200, Jakub Jelinek wrote:
> On Tue, Sep 15, 2015 at 12:33:58PM +0200, Richard Biener wrote:
> > On Tue, Sep 15, 2015 at 12:20 PM, Jakub Jelinek  wrote:
> > > On Tue, Sep 15, 2015 at 12:14:22PM +0200, Richard Biener wrote:
> > >> > diff --git a/gcc/cp/parser.h b/gcc/cp/parser.h
> > >> > index 760467c..c7558a0 100644
> > >> > --- a/gcc/cp/parser.h
> > >> > +++ b/gcc/cp/parser.h
> > >> > @@ -61,6 +61,8 @@ struct GTY (()) cp_token {
> > >> >BOOL_BITFIELD purged_p : 1;
> > >> >/* The location at which this token was found.  */
> > >> >location_t location;
> > >> > +  /* The source range at which this token was found.  */
> > >> > +  source_range range;
> > >>
> > >> Is it just me or does location now feel somewhat redundant with range?  
> > >> Can't we
> > >> compress that somehow?
> > >
> > > For a token I'd expect it is redundant, I don't see how it would be useful
> > > for a single preprocessing token to have more than start and end 
> > > locations.
> > > But generally, for expressions, 3 locations make sense.
> > > If you have
> > > abc + def
> > > ^
> > > then having a range is useful.  In any case, I'm surprised that the 
> > > ranges aren't encoded in
> > > location_t (the data structures behind it, where we already stick also
> > > BLOCK pointer).
> > 
> > Probably lack of encoding space ... I suppose upping location_t to
> > 64bits coud solve
> > some of that (with its own drawback on increasing size of core structures).
> 
> What I had in mind was just add
>   source_location start, end;
> to location_adhoc_data struct and use !IS_ADHOC_LOC locations to represent
> just plain locations without block and without range (including the cases
> where the range has both start and end equal to the locus) and IS_ADHOC_LOC
> locations for the cases where either we have non-NULL block, or we have
> some other range, or both.  But I haven't spent any time on that, so just
> wondering if such an encoding has been considered.

I've been attempting to implement that.

Am I right in thinking that the ad-hoc locations never get purged? i.e.
that once we've registered an ad-hoc location, then is that slot within
location_adhoc_data_map is forever associated with that (locus, block)
pair?  [or in the proposed model, the (locus, src_range, block)
triple?].

If so, it may make more sense to put the ranges into ad-hoc locations,
but only *after tokenization*: in this approach, the src_range would be
a field within the tokens (like in patch 07/22), in the hope that the
tokens are short-lived  (which AIUI is the case for libcpp and C, though
not for C++), presumably also killing the "location" field within
tokens.  We then stuff the range into the location_t when building trees
(maybe putting a src_range into c_expr to further delay populating
location_adhoc_data_map).

That way we avoid bloating the location_adhoc_data_map during lexing,
whilst preserving the range information, and we can stuff the ranges
into the 32-bit location_t within tree/gimple etc (albeit paying a cost
within the location_adhoc_data_map).

Thoughts?  Hope this sounds sane.
Dave

Re: vector lightweight debug mode

[Jonathan Wakely]

On 16/09/15 21:37 +0200, François Dumont wrote:

On 14/09/2015 21:50, Jonathan Wakely wrote:

On 14/09/15 20:27 +0200, François Dumont wrote:

diff --git a/libstdc++-v3/include/bits/stl_vector.h
b/libstdc++-v3/include/bits/stl_vector.h
index 305d446..89a9aec 100644
--- a/libstdc++-v3/include/bits/stl_vector.h
+++ b/libstdc++-v3/include/bits/stl_vector.h
@@ -449,6 +449,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
  vector&
  operator=(vector&& __x) noexcept(_Alloc_traits::_S_nothrow_move())
  {
+__glibcxx_assert(this != &__x);


Please don't do this, it fails in valid programs. The standard needs
to be fixed in this regard.


The debug mode check should be removed too then.


Yes.





constexpr bool __move_storage =
  _Alloc_traits::_S_propagate_on_move_assign()
  || _Alloc_traits::_S_always_equal();
@@ -778,7 +779,10 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
   */
  reference
  operator[](size_type __n) _GLIBCXX_NOEXCEPT
-  { return *(this->_M_impl._M_start + __n); }
+  {
+__glibcxx_assert(__n < size());
+return *(this->_M_impl._M_start + __n);
+  }


This could use __glibcxx_requires_subscript(__n), see the attached
patch.


   I thought you didn't want to use anything from debug.h so I try to
do with only __glibcxx_assert coming from c++config. I think your patch
is missing include of debug.h.

   But I was going to propose to use _Error_formatter also in this
mode, I do not see any reason to not do so. The attached patch does just
that.


That pulls in extra dependencies on I/O and fprintf and things, which
can cause code size to increase. Is it really worth it?



@@ -1051,6 +1071,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
  iterator
  insert(const_iterator __position, size_type __n, const
value_type& __x)
  {
+__glibcxx_assert(__position >= cbegin() && __position <= cend());
difference_type __offset = __position - cbegin();
_M_fill_insert(begin() + __offset, __n, __x);
return begin() + __offset;


This is undefined behaviour, so I'd rather not add this check (I know
it's on the google branch, but it's still undefined behaviour).


Why ? Because of the >= operator usage ? Is the attached patch better ?
< and == operators are well defined for a random access iterator, no ?


No, because it is undefined to compare iterators that belong to
different containers, or to compare pointers that point to different
arrays.

Re: Openacc launch API

[Nathan Sidwell]

Ping?

On 09/11/15 11:50, Nathan Sidwell wrote:

Ping?

https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01498.html



On 09/07/15 08:48, Nathan Sidwell wrote:

On 08/25/15 09:29, Nathan Sidwell wrote:

Jakub,

This patch changes the launch API for openacc parallels.  The current scheme
passes the launch dimensions as 3 separate parameters to the GOACC_parallel
function.  This is problematic for a couple of reasons:

1) these must be validated in the host compiler

2) they provide no extension to support a variety of different offload devices
with different geometry requirements.

This patch changes things so that the function tables emitted by (ptx)
mkoffloads includes the geometry triplet for each function.  This allows them to
be validated and/or manipulated in the offload compiler.  However, this only
works for compile-time known dimensions -- which is a common case.  To deal with
runtime-computed dimensions we have to retain the host-side compiler's
calculation and pass that into the GOACC_parallel function.  We change
GOACC_parallel to take a variadic list of keyed operands ending with a sentinel
marker.  These keyed operands have a slot for expansion to support multiple
different offload devices.

We also extend the functionality of the 'oacc function' internal attribute.
Rather than being a simple marker, it now has a value, which is a TREE_LIST of
the geometry required.  The geometry is held as INTEGER_CSTs on the TREE_VALUE
slots.  Runtime-calculated values are represented by an INTEGER_CST of zero.
We'll also use this representation for  'routines', where the TREE_PURPOSE slot
will be used to indicate the levels at which a routine might spawn a partitioned
loop.  Again, to allow future expansion supporting a number of different offload
devices, this can become a list-of-lists, keyed by and offload device
identifier.  The offload  compiler can manipulate this data, and a later patch
will do this within a new oacc-xform pass.

I  did rename the GOACC_parallel entry point to GOACC_parallel_keyed and provide
a forwarding function. However, as the mkoffload data is incompatible, this is
probably overkill.  I've had to increment the (just committed) version number to
detect the change in data representation.  So any attempt to run an old binary
with a new libgomp will fail at the loading point.  We could simply keep the
same 'GOACC_parallel' name and not need any new symbols.  WDYT?


Ping?

https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01498.html

nathan

Re: [C/C++ PATCH] RFC: Implement -Wduplicated-cond (PR c/64249)

[Martin Sebor]

On 09/16/2015 09:59 AM, Marek Polacek wrote:

This patch implements a new warning, -Wduplicated-cond.  It warns for
code such as

   if (x)
 // ...
   else if (x)
 // ...


As usual, I like this improvement. I think it's worth extending
to conditional expressions (e.g., x ? f() : x ? g() : h() should
be diagnosed as well).

The patch currently issues a false positive for the test case
below. I suspect the chain might need to be cleared after each
condition that involves a side-effect.

  int foo (int a)
  {
if (a) return 1; else if (++a) return 2; else if (a) return 3;
return 0;
  }

The patch doesn't diagnose some more involved cases like the one
below:

  if (i < 0) return 1; else if (!(i > 0 || i == 0)) return 2;

even though it does diagnose some other such cases, including:

  if (i < 0) return 1; else if (!(i >= 0)) return 2;

and even:

  int foo (int a, int b, int c) {
if (a + c == b) return 1; else if (a + c - b == 0) return 2;
return 0;
  }

I'm guessing this is due to operand_equal_p returning true for
some pairs of equivalent expressions and false for others. Would
making this work be feasible?

You probably didn't intend to diagnose the final else clause in
the following case but I wonder if it should be (as an extension
of the original idea):

if (i) return 1; else if (!i) return 2; else return 0;

(In fact, I wonder if it might be worth diagnosing even the
'if (!i)' part since the condition is the inverse of the one
in the if and thus redundant).

Is diagnosing things like 'if (a) if (a);' or 'if (a); else {
if (a); }' not feasible or too involved, or did you choose not
to because you expect it might generate too many warnings? (If
the latter, perhaps it could be disabled by default and enabled
by -Wduplicated-cond=2).

Martin

Re: [PATCH, rs6000] Add expansions for min/max vector reductions

[Bill Schmidt]

On Wed, 2015-09-16 at 18:03 +0100, Alan Lawrence wrote:
> On 16/09/15 17:10, Bill Schmidt wrote:
> >
> > On Wed, 2015-09-16 at 16:29 +0100, Alan Lawrence wrote:
> >> On 16/09/15 15:28, Bill Schmidt wrote:
> >>> 2015-09-16  Bill Schmidt  
> >>>
> >>>   * config/rs6000/altivec.md (UNSPEC_REDUC_SMAX, 
> >>> UNSPEC_REDUC_SMIN,
> >>>   UNSPEC_REDUC_UMAX, UNSPEC_REDUC_UMIN, UNSPEC_REDUC_SMAX_SCAL,
> >>>   UNSPEC_REDUC_SMIN_SCAL, UNSPEC_REDUC_UMAX_SCAL,
> >>>   UNSPEC_REDUC_UMIN_SCAL): New enumerated constants.
> >>>   (reduc_smax_v2di): New define_expand.
> >>>   (reduc_smax_scal_v2di): Likewise.
> >>>   (reduc_smin_v2di): Likewise.
> >>>   (reduc_smin_scal_v2di): Likewise.
> >>>   (reduc_umax_v2di): Likewise.
> >>>   (reduc_umax_scal_v2di): Likewise.
> >>>   (reduc_umin_v2di): Likewise.
> >>>   (reduc_umin_scal_v2di): Likewise.
> >>>   (reduc_smax_v4si): Likewise.
> >>>   (reduc_smin_v4si): Likewise.
> >>>   (reduc_umax_v4si): Likewise.
> >>>   (reduc_umin_v4si): Likewise.
> >>>   (reduc_smax_v8hi): Likewise.
> >>>   (reduc_smin_v8hi): Likewise.
> >>>   (reduc_umax_v8hi): Likewise.
> >>>   (reduc_umin_v8hi): Likewise.
> >>>   (reduc_smax_v16qi): Likewise.
> >>>   (reduc_smin_v16qi): Likewise.
> >>>   (reduc_umax_v16qi): Likewise.
> >>>   (reduc_umin_v16qi): Likewise.
> >>>   (reduc_smax_scal_): Likewise.
> >>>   (reduc_smin_scal_): Likewise.
> >>>   (reduc_umax_scal_): Likewise.
> >>>   (reduc_umin_scal_): Likewise.
> >>
> >> You shouldn't need the non-_scal reductions. Indeed, they shouldn't be 
> >> used if
> >> the _scal are present. The non-_scal's were previously defined as 
> >> producing a
> >> vector with one element holding the result and the other elements all 
> >> zero, and
> >> this was only ever used with a vec_extract immediately after; the _scal 
> >> pattern
> >> now includes the vec_extract as well. Hence the non-_scal patterns are
> >> deprecated / considered legacy, as per md.texi.
> >
> > Thanks -- I had misread the description of the non-scalar versions,
> > missing the part where the other elements are zero.  What I really
> > want/need is an optab defined as computing the maximum value in all
> > elements of the vector.
> 
> Yes, indeed. It seems reasonable to me that this would coexist with an optab 
> which computes only a single value (i.e. a scalar).
> 
> At that point it might be appropriate to change the cond-reduction code to 
> generate the reduce-to-vector in all cases, and optabs.c expand it to 
> reduce-to-scalar + broadcast if reduce-to-vector was not available. Along 
> with 
> the (parallel) changes to cost model already proposed, does that cover all 
> the 
> cases? It does add a new tree code, yes, but I'm feeling that could be 
> justified 
> if we go down this route.

That's how I envisioned it as well, and it was my original preference,
provided the maintainers are ok with it.  However, your next suggestion
is intriguing...

> 
> However, another point that springs to mind: if you reduce a loop containing 
> OR 
> or MUL expressions, the vect_create_epilog_for_reduction reduces these using 
> shifts, and I think will also use shifts for platforms not possessing a 
> reduc_plus/min/max. If shifts could be changed for rotates, the code there 
> would 
> do your reduce-to-a-vector-of-identical-elements in the midend...can we 
> (sensibly!) bring all of these together?

Perhaps so.  I can have a look at that and see.  What I'm calling a
rotate is really a double-vector shift where both input vectors are the
same, so perhaps this is already pretty close to what we need.

Thanks!  I'll try to put together some sort of proposal over the next
week or so, workload permitting.

Bill

> 
> > Perhaps the practical thing is to have the vectorizer also do an
> > add_stmt_cost with some new token that indicates the cost model should
> > make an adjustment if the back end doesn't need the extract/broadcast.
> > Targets like PowerPC and AArch32 could then subtract the unnecessary
> > cost, and remove the unnecessary code in simplify-rtx.
> 
> I think it'd be good if we could do it before simplify-rtx, really, although 
> I'm 
> not sure I have a strong argument as to why, as long as we can cost it 
> appropriately.
> 
> > In any case, I will remove implementing the deprecated optabs, and I'll
> > also try to look at Alan L's patch shortly.
> 
> That'd be great, thanks :)
> 
> Cheers, Alan
> 

Re: [patch] libstdc++/67173 Fix filesystem::canonical for Solaris 10.

[Martin Sebor]

Tested powerpc64le-linux, x86_64-dragonfly4.1 and x86_64-netbsd5.1,
do you see any reason not to commit this for now?


I see only a couple of potential problems: a missing test for
PATH_MAX in the unlikely event it's not defined (or is obscenely
large), and a missing check to avoid infinite loops due to symlinks.



Any improvements such as hardcoding checks for specific versions of
Solaris or the BSDs are QoI, and this is only an experimental TS, so I
don't want to spend the rest of stage 1 working on one function :-)


Makes sense.


My main obstacle to writing good tests right now is having some way to
create and destroy files safely in the tests. It's hard to test
functions like is_symlink() without first creating a symlink in a
known location, and also removing it again cleanly so the next
testsuite run doesn't fail if the file is already present.

One option would be to have libstdc++-v3/testsuite/Makefile create a
new sub-directory as a sandbox for filesystem tests, removing it if it
already exists. Then the tests can put anything they like in that new
dir without fear of trashing the user's files elsewhere on the FS!


I don't know how you feel about Tcl but writing a filesystem.exp
and adding a new "dg-fs" API would let each test can set up the
directory structure it needs.

Martin

[PATCH], PowerPC IEEE 128-bit patch #7 (revised)

[Michael Meissner]

This is a revised patch that adds the parts to enable generation of IEEE
128-bit floating point support in the PowerPC backend.

The major user visible change of this patch is to change the switch from
-mfloat128-software and -mfloat128-none to just -mfloat128 and -mno-float128.
I also revised some of the support functions in rs6000.c to work better with
future patches.

In working on the future patches, I also noticed that I had allowed the
conversion routines to support target being a memory address (via the
nonimmediate_operand predicate), and I restricted it to register.

The next patch will be to libgcc to enable building the emulation routines, so
that you can use IEEE 128-bit floating point. It is expected that initially
these patches will be a temporary measure until the glibc team takes ownership
of the emulation functions (the soft-fp directory of libgcc comes from glibc).

Once the libgcc routines are in place, I will then submit a patch to flip the
default, so that enabling VSX options will enable -mfloat128 by default.

I expect there to be various additional patches as things come up as well.  Of
the top of my head, I will probably be adding built-in functions for sqrt and
abs.  I also want to tackle making _Complex __float128 work without having to
use attributes.

The patch has been bootstrapped on a Power7 big endian system and a Power8
little endian system with no regressions. I also built compilers with/without
the changes targetting power5 as a default and there were no regressions there
either.  Are these patches ok to install on the trunk?

[gcc]
2015-09-14  Michael Meissner  

* config/rs6000/rs6000-cpus.h (POWERPC_MASKS): Add -mfloat128.

* config/rs6000/rs6000-c.c (rs6000_cpu_cpp_builtins): Define new
macros to identify if __float128 is available, and whether long
double is IBM extended double or IEEE 128-bit floating point.

* config/rs6000/rs6000.opt (-mfloat128): Change IEEE 128-bit
switches from -mfloat128-none and -mfloat128-software to
-mfloat128 and -mno-float128.
(-mfloat128-): Delete.
(float128_type_t): Delete.

* config/rs6000/rs6000.c (rs6000_c_mode_for_suffix): Define 'q'
and 'Q' as the suffixes for __float128 constants.
(TARGET_C_MODE_FOR_SUFFIX): Likewise.
(rs6000_hard_regno_mode_ok): Remove tests disallowing IEEE 128-bit
floating point modes from GPRs if not -mfloat128.
(rs6000_debug_reg_global): Delete debug support for
-mfloat128-software and -mfloat128-none.
(rs6000_setup_reg_addr_masks): IEEE 128-bit in floating point is
not suitable for auto increment or decrement.
(rs6000_init_hard_regno_mode_ok): Enable VSX constraints and
addressing for IEEE 128-bit floating point in VSX registers.
(rs6000_option_override_internal): Update test for __float128
support.
(rs6000_gen_le_vsx_permute): Add support for -mfloat128.
(init_cumulative_args): Likewise.
(rs6000_function_arg): Likewise.
(rs6000_arg_partial_bytes): Likewise.
(rs6000_init_builtins): Rework __float128 support.
(init_float128_ibm): Add __float128 support. Split support into
separate functions for IEEE 128-bit floating point and IBM
extended double support.
(init_float128_ieee): Likewise.
(rs6000_init_libfuncs): Likewise.
(rs6000_expand_float128_convert): Use switch statements to handle
different types.
(rs6000_mangle_type): Add __float128 mangling support.
(rs6000_scalar_mode_supported_p): Rework __float128 support.
(rs6000_opt_masks): Add -mfloat128 support.
(chain_contains_only_swaps): Use ALTIVEC_OR_VSX_VECTOR_MODE
instead of VECTOR_MODE_P in order to treat IEEE1 28-bit floating
point in VSX registers like vector types, and treat it like a
128-bit integer.
(mark_swaps_for_removal): Likewise.
(rs6000_analyze_swaps): Likewise.

* config/rs6000/rs6000.h (ALTIVEC_VECTOR_MODE): Include __float128
modes as 'vector' modes.
(MODES_TIEABLE_P): Move checking for vector modes above scalar
floating point, so that __float128 types tie with vector types.
(struct rs6000_args): Add libcall field for __float128 support
functions.

* config/rs6000/rs6000.md (extend2):
Require target to be a register, not a memory operand.
(trunk2): Likewise.

* config/rs6000/rs6000-opts.h (enum float128_type_t): Delete,
switch to -mfloat128 and -mno-float128 from -mfloat128-software
and -mfloat128-none.

* doc/extend.texi (additional floating types): Document PowerPC
use of __float128 and __ibm128 types.

* doc/invoke.texi (RS/6000 and PowerPC Options): Document
-mfloat128 and -mno-float128.

[gcc/testsuite]
2015-09-14  Michael Meissner  

* gcc.target/powerpc/float128-c

Re: [patch] libstdc++/67173 Fix filesystem::canonical for Solaris 10.

[Jonathan Wakely]

On 16/09/15 16:04 -0600, Martin Sebor wrote:

Tested powerpc64le-linux, x86_64-dragonfly4.1 and x86_64-netbsd5.1,
do you see any reason not to commit this for now?


I see only a couple of potential problems: a missing test for
PATH_MAX in the unlikely event it's not defined (or is obscenely


In the current patch _GLIBCXX_USE_REALPATH won't be defined unless:

  #elif _XOPEN_VERSION >= 700 || defined(PATH_MAX)

so if it's defined and _XOPEN_VERSION < 700 then we know PATH_MAX must
be defined (otherwise _GLIBCXX_USE_REALPATH wouldn't be).


large), and a missing check to avoid infinite loops due to symlinks.


I thought about keeping track of where I'd been while expanding
symlinks, but then realised this will do it:

 if (!exists(pa, ec))
   {
 fail(ENOENT);
 return result;
   }
 // else we can assume no unresolvable symlink loops

If there's a symlink loop then exists(pa) will fail with ELOOP, and we
won't try to resolve it by hand.

And then after each step in the while(!cmpts.empty()) loop I also have
a check for !exists(result, ec), which should even handle the case
where the filesystem changes after the initial exists() call so that a
loop is introduced while we're canonicalising the path.



Any improvements such as hardcoding checks for specific versions of
Solaris or the BSDs are QoI, and this is only an experimental TS, so I
don't want to spend the rest of stage 1 working on one function :-)


Makes sense.


My main obstacle to writing good tests right now is having some way to
create and destroy files safely in the tests. It's hard to test
functions like is_symlink() without first creating a symlink in a
known location, and also removing it again cleanly so the next
testsuite run doesn't fail if the file is already present.

One option would be to have libstdc++-v3/testsuite/Makefile create a
new sub-directory as a sandbox for filesystem tests, removing it if it
already exists. Then the tests can put anything they like in that new
dir without fear of trashing the user's files elsewhere on the FS!


I don't know how you feel about Tcl but writing a filesystem.exp
and adding a new "dg-fs" API would let each test can set up the
directory structure it needs.


My Tcl is very weak, but if that's the right approach then I can try
that.

Thanks again!

Re: [patch] libstdc++/67173 Fix filesystem::canonical for Solaris 10.

[Jonathan Wakely]

On 16/09/15 19:58 +0100, Jonathan Wakely wrote:

commit ef25038796485298ff8f040bc79e0d9a371171fa
Author: Jonathan Wakely 
Date:   Wed Sep 16 18:07:32 2015 +0100

   Implement filesystem::canonical() without realpath
   
   	PR libstdc++/67173

* acinclude.m4 (GLIBCXX_CHECK_FILESYSTEM_DEPS): Check _XOPEN_VERSION
and PATH_MAX for _GLIBCXX_USE_REALPATH.
* config.h.in: Regenerate.
* configure: Regenerate.
* src/filesystem/ops.cc: (canonical) [!_GLIBCXX_USE_REALPATH]: Add
alternative implementation.
* testsuite/experimental/filesystem/operations/canonical.cc: New.
* testsuite/experimental/filesystem/operations/exists.cc: Add more
tests.
* testsuite/experimental/filesystem/operations/absolute.cc: Add test
variables.
* testsuite/experimental/filesystem/operations/copy.cc: Likewise.
* testsuite/experimental/filesystem/operations/current_path.cc:
Likewise.
* testsuite/experimental/filesystem/operations/file_size.cc: Likewise.
* testsuite/experimental/filesystem/operations/status.cc: Likewise.
* testsuite/experimental/filesystem/operations/temp_directory_path.cc:
Likewise.


Committed to trunk.