Re: [PATCH, AArch64] Remove unused types and variables for abi types

[Marcus Shawcroft]

On 02/07/13 15:14, Yufeng Zhang wrote:


gcc/

* config/aarch64/aarch64.h (enum arm_abi_type): Remove.
(ARM_ABI_AAPCS64): Ditto.
(arm_abi): Ditto.
(ARM_DEFAULT_ABI): Ditto.



OK
/Marcus

Re: [patch] [python libstdc++ printers] Fix gdb/15195

[Phil Muldoon]

On 13/06/13 14:49, Tom Tromey wrote:
>> "Phil" == Phil Muldoon  writes:
> 
> Phil> Attached is an updated patch correcting the issues that you pointed
> Phil> out.
> 
> The patch itself looks fine to me, but I don't think I can approve it.
> 
> Tom

This new patch replaces and obsoletes the previous.  On further
inspection of some other pretty printer related bugs, it seems that
all of the printers need to fetch the referenced value where the value
type is a reference.  This patch applies that change, and adds a
number of reference based tests.

Cheers,

Phil

2013-07-03  Phil Muldoon  

PR gcc/53477
http://sourceware.org/bugzilla/show_bug.cgi?id=15195

* python/libstdcxx/v6/printers.py (Printer.__call__): If a value
is a reference, fetch referenced value.
(RxPrinter.invoke): Ditto.
* testsuite/libstdc++-prettyprinters/cxx11.cc (main): Add -O0
flag. Add referenced value tests.

--

Index: python/libstdcxx/v6/printers.py
===
--- python/libstdcxx/v6/printers.py (revision 199642)
+++ python/libstdcxx/v6/printers.py (working copy)
@@ -786,6 +786,10 @@
 def invoke(self, value):
 if not self.enabled:
 return None
+
+if value.type.code == gdb.TYPE_CODE_REF:
+value = value.referenced_value()
+
 return self.function(self.name, value)
 
 # A pretty-printer that conforms to the "PrettyPrinter" protocol from
@@ -841,6 +845,10 @@
 return None
 
 basename = match.group(1)
+
+if val.type.code == gdb.TYPE_CODE_REF:
+val = val.referenced_value()
+
 if basename in self.lookup:
 return self.lookup[basename].invoke(val)
 
Index: testsuite/libstdc++-prettyprinters/cxx11.cc
===
--- testsuite/libstdc++-prettyprinters/cxx11.cc (revision 199706)
+++ testsuite/libstdc++-prettyprinters/cxx11.cc (working copy)
@@ -1,5 +1,5 @@
 // { dg-do run }
-// { dg-options "-std=gnu++11 -g" }
+// { dg-options "-std=gnu++11 -g -O0" }
 
 // Copyright (C) 2011-2013 Free Software Foundation, Inc.
 //
@@ -25,6 +25,8 @@
 #include 
 #include 
 
+typedef std::tuple ExTuple;
+
 template
 void
 placeholder(const T &s)
@@ -63,43 +65,75 @@
   std::forward_list efl;
 // { dg-final { note-test efl "empty std::forward_list" } }
 
+  std::forward_list &refl = efl;
+// { dg-final { note-test refl "empty std::forward_list" } }
+
   std::forward_list fl;
   fl.push_front(2);
   fl.push_front(1);
 // { dg-final { note-test fl {std::forward_list = {[0] = 1, [1] = 2}} } }
 
+  std::forward_list &rfl = fl;
+// { dg-final { note-test rfl {std::forward_list = {[0] = 1, [1] = 2}} } }
+
   std::unordered_map eum;
 // { dg-final { note-test eum "std::unordered_map with 0 elements" } }
+  std::unordered_map &reum = eum;
+// { dg-final { note-test reum "std::unordered_map with 0 elements" } }
+
   std::unordered_multimap eumm;
 // { dg-final { note-test eumm "std::unordered_multimap with 0 elements" } }
+  std::unordered_multimap &reumm = eumm;
+// { dg-final { note-test reumm "std::unordered_multimap with 0 elements" } }
+
   std::unordered_set eus;
 // { dg-final { note-test eus "std::unordered_set with 0 elements" } }
+  std::unordered_set &reus = eus;
+// { dg-final { note-test reus "std::unordered_set with 0 elements" } }
+
   std::unordered_multiset eums;
 // { dg-final { note-test eums "std::unordered_multiset with 0 elements" } }
+  std::unordered_multiset &reums = eums;
+// { dg-final { note-test reums "std::unordered_multiset with 0 elements" } }
 
   std::unordered_map uom;
   uom[5] = "three";
   uom[3] = "seven";
 // { dg-final { note-test uom {std::unordered_map with 2 elements = {[3] = 
"seven", [5] = "three"}} } }
 
+  std::unordered_map &ruom = uom;
+// { dg-final { note-test ruom {std::unordered_map with 2 elements = {[3] = 
"seven", [5] = "three"}} } }
+
   std::unordered_multimap uomm;
   uomm.insert(std::pair (5, "three"));
   uomm.insert(std::pair (5, "seven"));
 // { dg-final { note-test uomm {std::unordered_multimap with 2 elements = {[5] 
= "seven", [5] = "three"}} } }
+  std::unordered_multimap &ruomm = uomm;
+// { dg-final { note-test ruomm {std::unordered_multimap with 2 elements = 
{[5] = "seven", [5] = "three"}} } }
 
   std::unordered_set uos;
   uos.insert(5);
 // { dg-final { note-test uos {std::unordered_set with 1 elements = {[0] = 5}} 
} }
+  std::unordered_set &ruos = uos;
+// { dg-final { note-test ruos {std::unordered_set with 1 elements = {[0] = 
5}} } }
 
   std::unordered_multiset uoms;
   uoms.insert(5);
 // { dg-final { note-test uoms {std::unordered_multiset with 1 elements = {[0] 
= 5}} } }
+  std::unordered_multiset &ruoms = uoms;
+// { dg-final { note-test ruoms {std::unordered_multiset with 1 elements = 
{[0] = 5}} } }
 
   std::unique_ptr uptr (new datum);
   uptr->s = "hi bob";
   uptr->i = 23;
 // { dg-final { regexp-test 

Re: [PATCH] Fix for PR c/57490

[Rainer Orth]

"Iyer, Balaji V"  writes:

>> -Original Message-
>> From: Jakub Jelinek [mailto:ja...@redhat.com]
>> Sent: Monday, July 01, 2013 1:09 PM
>> To: Iyer, Balaji V
>> Cc: gcc-patches@gcc.gnu.org; Rainer Orth
>> Subject: Re: [PATCH] Fix for PR c/57490
>> 
>> On Mon, Jul 01, 2013 at 05:02:57PM +, Iyer, Balaji V wrote:
>> > OK. The fixed patch is attached. Here are the ChangeLog entries:
>> >
>> > gcc/cp/ChangeLog
>> > 2013-07-01  Balaji V. Iyer  
>> >
>> 
>> Still
>>  PR c/57490
>> hasn't been added to cp/ChangeLog and c/ChangeLog entries.
>> > --- /dev/null
>> > +++ b/gcc/testsuite/c-c++-common/cilk-plus/AN/pr57490.c
>> > @@ -0,0 +1,25 @@
>> 
>
> Fixed as you suggested. Here is the fixed Changelogs and patch is attached.
>
> gcc/cp/ChangeLog
> 2013-07-01  Balaji V. Iyer  
>
> PR c/57490
> * cp-array-notation.c (cp_expand_cond_array_notations): Added a
> check for truth values.
> (expand_array_notation_exprs): Added truth values case.  Removed an
> unwanted else.  Added for-loop to walk through subtrees in default
> case.
>
> gcc/c/ChangeLog
> 2013-07-01  Balaji V. Iyer  
>
> PR c/57490
> * c-array-notation.c (fix_conditional_array_notations_1): Added a
> check for truth values.
> (expand_array_notation_exprs): Added truth values case.  Removed an
> unwanted else.  Added for-loop to walk through subtrees in default
> case.
>
>
> gcc/testsuite/ChangeLog
> 2013-07-01  Balaji V. Iyer  
>
> PR c/57490
> * c-c++-common/cilk-plus/AN/pr57490.c: New test.

I've just tested this patch on i386-pc-solaris2.10:

The c-c++-common/cilk-plus/AN/an-if.c test still FAILs for C++:

FAIL: c-c++-common/cilk-plus/AN/an-if.c  -fcilkplus (internal compiler error)
FAIL: c-c++-common/cilk-plus/AN/an-if.c  -fcilkplus (test for excess errors)
Excess errors:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/c-c++-common/cilk-plus/AN/an-if.c:13:5:
 error: mismatching comparison operand types
float
int
if (D.2198 == 24) goto ; else goto ;
/vol/gcc/src/hg/trunk/local/gcc/testsuite/c-c++-common/cilk-plus/AN/an-if.c:13:5:
 error: mismatching comparison operand types
float
int
if (D.2200 == D.2282) goto ; else goto ;
/vol/gcc/src/hg/trunk/local/gcc/testsuite/c-c++-common/cilk-plus/AN/an-if.c:13:5:
 error: mismatching comparison operand types
float
int
if (D.2202 == 0) goto ; else goto ;
/vol/gcc/src/hg/trunk/local/gcc/testsuite/c-c++-common/cilk-plus/AN/an-if.c:13:5:
 error: mismatching comparison operand types
float
int
if (D.2205 == 24) goto ; else goto ;
/vol/gcc/src/hg/trunk/local/gcc/testsuite/c-c++-common/cilk-plus/AN/an-if.c:13:5:
 error: mismatching comparison operand types
float
int
if (D.2207 == D.2338) goto ; else goto ;
/vol/gcc/src/hg/trunk/local/gcc/testsuite/c-c++-common/cilk-plus/AN/an-if.c:13:5:
 error: mismatching comparison operand types
float
int
if (D.2209 == iftmp.16) goto ; else goto ;
/vol/gcc/src/hg/trunk/local/gcc/testsuite/c-c++-common/cilk-plus/AN/an-if.c:13:5:
 internal compiler error: verify_gimple failed
0x87f1a27 verify_gimple_in_seq(gimple_statement_d*)
/vol/gcc/src/hg/trunk/local/gcc/tree-cfg.c:4474
0x863ce54 gimplify_body(tree_node*, bool)
/vol/gcc/src/hg/trunk/local/gcc/gimplify.c:8240
0x863d19a gimplify_function_tree(tree_node*)
/vol/gcc/src/hg/trunk/local/gcc/gimplify.c:8325
0x84a9437 analyze_function
/vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:631
0x84ac97a analyze_functions
/vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:914
0x84ae029 finalize_compilation_unit()
/vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2097
0x829255f cp_write_global_declarations()
/vol/gcc/src/hg/trunk/local/gcc/cp/decl2.c:4356

WARNING: c-c++-common/cilk-plus/AN/an-if.c  -fcilkplus compilation failed to 
produce executable

While the C an-if.c test now passes, the new pr57490.c test (which is
identical to an-if.c modulo the assert to __builtin_abort change) FAILs:

FAIL: c-c++-common/cilk-plus/AN/pr57490.c  -fcilkplus -std=c99 (internal 
compiler error)
FAIL: c-c++-common/cilk-plus/AN/pr57490.c  -fcilkplus -std=c99 (test for excess 
errors)
Excess errors:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/c-c++-common/cilk-plus/AN/pr57490.c:6:5:
 error: invalid types in conversion to floating point
long double
float
D.1656 = (long double) D.1604;
/vol/gcc/src/hg/trunk/local/gcc/testsuite/c-c++-common/cilk-plus/AN/pr57490.c:6:5:
 error: invalid types in conversion to floating point
long double
float
D.1671 = (long double) D.1609;
/vol/gcc/src/hg/trunk/local/gcc/testsuite/c-c++-common/cilk-plus/AN/pr57490.c:6:5:
 error: invalid types in conversion to floating point
long double
float
D.1731 = (long double) D.1619;
/vol/gcc/src/hg/trunk/local/gcc/testsuite/c-c++-common/cilk-plus/AN/pr57490.c:6:5:
 error: invalid types in conversion to floating point
long double
float
D.1746 = (long double) D.1624;
/vol/gcc/src/hg/trunk/local/gcc/testsuite/c-c++-common/cilk-plus/AN/pr57490.c:6:5

Re: [AArch64] Convert ld1, st1 arm_neon.h intrinsics to RTL builtins.

[Marcus Shawcroft]

On 02/07/13 10:01, James Greenhalgh wrote:


2013-07-02  James Greenhalgh  

* config/aarch64/aarch64-builtins.c
(aarch64_simd_expand_builtin): Handle AARCH64_SIMD_STORE1.
* config/aarch64/aarch64-simd-builtins.def (ld1): New.
(st1): Likewise.
* config/aarch64/aarch64-simd.md
(aarch64_ld1): New.
(aarch64_st1): Likewise.
* config/aarch64/arm_neon.h
(vld1_<8, 16, 32, 64>): Convert to RTL builtins.



OK
/MArcus

[gomp4] Compiler side of the cancellation support

[Jakub Jelinek]

Hi!

This is the compiler side of the #pragma omp cancel and #pragma omp
cancellation point support.  On the library side what is needed is:
1) GOMP_cancellation_point now returns a bool (whether the relevant
   cancellation was observed)
2) GOMP_cancel now has two arguments instead of just one, and returns
   bool like GOMP_cancellation_point.  If the second argument is false,
   it acts just like GOMP_cancellation_point, if it is true, it cancels
   the given construct.  For both these calls the first argument is
   1 for parallel cancellation, 2 for loop cancellation, 4 for sections and
   8 for taskgroup cancellation.
3) GOMP_barrier_cancel which is like GOMP_barrier, but should check
   for pending parallel cancellation and if parallel is cancelled, should
   return true
4) GOMP_sections_end_cancel and GOMP_loop_end_cancel variants to the
   non-cancel libcalls for the cancellation checking implicit barriers

The still unsolved problems are that for firstprivate/lastprivate
for, copyin_ref we add an implicit barrier that isn't really in the standard
and similarly for #pragma omp single copyprivate we don't use one barrier
mandated by the standard, but actually two barriers.  Not sure what exactly
we want as the behavior for these.  As some subset of threads can be
canceled before reaching the unofficial barrier (say one with #pragma omp
cancel parallel before reaching the omp for or omp single copyprivate)
and some others with #pragma omp cancellation point parallel, while some
threads hit the unofficial barrier before the cancellation (and optionally
some afterwards), do we want in the library to just arrange for all barriers
to be awaken and not block until the final barrier at the end of parallel is
hit, and for the unofficial barriers just not to return anything, while
for the official barriers (*_cancel suffixed) return true to signal jump to
end of region with running dtors?

Or perhaps keep track on how many threads in parallel have already observed
the cancellation and wait on non-*_cancel barriers only for the rest of the
threads that haven't observed it yet, and only on the *_cancel barriers
observe it for all threads.

Another issue is what if the dtors executed on the way contain barriers,
but that is probably ruled out by the restriction that 
"A construct that may be subject to cancellation must not encounter an orphaned
cancellation point."

Queuing this patch until we have a library implementation.

2013-07-03  Jakub Jelinek  

* gimple-pretty-print.c (dump_gimple_omp_return): Print
gimple_omp_return_lhs if non-NULL.
* tree-ssa-alias.c (ref_maybe_used_by_call_p_1,
call_may_clobber_ref_p_1): Handle BUILT_IN_GOMP_BARRIER_CANCEL,
BUILT_IN_GOMP_LOOP_END_CANCEL, BUILT_IN_GOMP_SECTIONS_END_CANCEL.
* gimple.h (gimple_omp_return_set_lhs, gimple_omp_return_lhs,
gimple_omp_return_lhs_ptr): New inlines.
* gimple.def (GIMPLE_OMP_RETURN): Use GSS_OMP_ATOMIC_STORE
instead of GSS_BASE.
* gimple.c (walk_gimple_op) : Walk lhs.
* builtin-types.def (BT_FN_BOOL_INT, BT_FN_BOOL_INT_BOOL): New.
* omp-builtins.def (BUILT_IN_GOMP_CANCELLATION_POINT): Use
ATTR_NOTHROW_LEAF_LIST instead of ATTR_NULL.  Return type is now
bool.
(BUILT_IN_GOMP_CANCEL): Likewise.  Add second argument with bool type.
(BUILT_IN_BARRIER_CANCEL, BUILT_IN_GOMP_LOOP_END_CANCEL,
BUILT_IN_GOMP_SECTIONS_END_CANCEL): New builtins.
* omp-low.c (struct omp_context): Add cancel_label and cancellable
fields.
(extract_omp_for_data): Set have_nowait even for simd implicitly.
(check_omp_nesting_restrictions): Verify nesting restrictions for
#pragma omp cancel and #pragma omp cancellation point.
Set ctx->cancellable for regions that can be cancelled or also
for any task region that contains #pragma omp cancellation point.
(scan_omp_1_stmt): Check nesting restrictions even if ctx == NULL.
(build_omp_barrier): Return gimple instead of tree, add lhs argument,
if non-NULL, build GOMP_barrier_cancel builtin instead and set its 
call lhs to lhs.
(lower_rec_input_clauses): Adjust build_omp_barrier caller.
(expand_omp_for_static_nochunk, expand_omp_for_static_chunk,
expand_omp_single): Likewise.  If OMP_RETURN has lhs, pass it to
build_omp_barrier.
(expand_omp_for_generic): If OMP_RETURN has lhs, use
GOMP_loop_end_cancel libcall instead of GOMP_loop_end and set its
lhs from OMP_RETURN's lhs.
(expand_omp_sections): If OMP_RETURN has lhs, use
GOMP_sections_end_cancel libcall instead of GOMP_sections_end and set
its lhs from OMP_RETURN's lhs.
(maybe_add_implicit_barrier_cancel): New function.
(lower_omp_sections): If ctx->cancellable, emit cancel_label before
OMP_RETURN.  Call maybe_add_implicit_barrier_cancel.
(lower_omp_for): Li

[linaro/gcc-4_8-branch] Backports from trunk

[Christophe Lyon]

Hi,

I have just committed backports of the following revisions from trunk
to linaro/gcc-4_8-branch:

r199640, 199705, 199733, 199734, 199739 grouped as r200640.

Thanks,

Christophe.

[Patch, Fortran] PR57785 - Fix folding of dot_product for complex vars

[Tobias Burnus]

Pending patches:http://gcc.gnu.org/ml/fortran/2013-07/msg2.html


Thanks goes to Dominique for debugging the issue!

Build and regtested on x86-64-gnu-linux.
OK for the trunk? I think one should also backport it to 4.7/4.8. 
(Folding - and hence the bug - exist since GCC 4.5.)


Tobias
2013-07-03  Tobias Burnus  

	PR fortran/57785
	* simplify.c (compute_dot_product): Complex conjugate for
	dot_product.
	(gfc_simplify_dot_product, gfc_simplify_matmul): Update call.

2013-07-03  Tobias Burnus  

	PR fortran/57785
	* gfortran.dg/dot_product_2.f90: New.

diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c
index 41e1dfb..32b8332 100644
--- a/gcc/fortran/simplify.c
+++ b/gcc/fortran/simplify.c
@@ -333,13 +333,15 @@ init_result_expr (gfc_expr *e, int init, gfc_expr *array)
 }
 
 
-/* Helper function for gfc_simplify_dot_product() and gfc_simplify_matmul.  */
+/* Helper function for gfc_simplify_dot_product() and gfc_simplify_matmul;
+   if conj_a is true, the matrix_a is complex conjugated.  */
 
 static gfc_expr *
 compute_dot_product (gfc_expr *matrix_a, int stride_a, int offset_a,
-		 gfc_expr *matrix_b, int stride_b, int offset_b)
+		 gfc_expr *matrix_b, int stride_b, int offset_b,
+		 bool conj_a)
 {
-  gfc_expr *result, *a, *b;
+  gfc_expr *result, *a, *b, *c;
 
   result = gfc_get_constant_expr (matrix_a->ts.type, matrix_a->ts.kind,
   &matrix_a->where);
@@ -362,9 +364,11 @@ compute_dot_product (gfc_expr *matrix_a, int stride_a, int offset_a,
 	  case BT_INTEGER:
 	  case BT_REAL:
 	  case BT_COMPLEX:
-	result = gfc_add (result,
-			  gfc_multiply (gfc_copy_expr (a),
-	gfc_copy_expr (b)));
+	if (conj_a && a->ts.type == BT_COMPLEX)
+	  c = gfc_simplify_conjg (a);
+	else
+	  c = gfc_copy_expr (a);
+	result = gfc_add (result, gfc_multiply (c, gfc_copy_expr (b)));
 	break;
 
 	  default:
@@ -1882,7 +1886,7 @@ gfc_simplify_dot_product (gfc_expr *vector_a, gfc_expr *vector_b)
   gcc_assert (vector_b->rank == 1);
   gcc_assert (gfc_compare_types (&vector_a->ts, &vector_b->ts));
 
-  return compute_dot_product (vector_a, 1, 0, vector_b, 1, 0);
+  return compute_dot_product (vector_a, 1, 0, vector_b, 1, 0, true);
 }
 
 
@@ -3910,7 +3914,7 @@ gfc_simplify_matmul (gfc_expr *matrix_a, gfc_expr *matrix_b)
   for (row = 0; row < result_rows; ++row)
 	{
 	  gfc_expr *e = compute_dot_product (matrix_a, stride_a, offset_a,
-	 matrix_b, 1, offset_b);
+	 matrix_b, 1, offset_b, false);
 	  gfc_constructor_append_expr (&result->value.constructor,
    e, NULL);
 
--- /dev/null	2013-07-03 08:52:40.042058079 +0200
+++ gcc/gcc/testsuite/gfortran.dg/dot_product_2.f90	2013-07-03 12:36:37.466598257 +0200
@@ -0,0 +1,15 @@
+! { dg-do compile }
+! { dg-options "-fdump-tree-original" }
+!
+! PR fortran/57785
+!
+! Contributed by Kontantinos Anagnostopoulos
+!
+! The implicit complex conjugate was missing
+
+complex :: z
+z = DOT_PRODUCT ((/ (1.0, 2.0), (2.0, 3.0) /), (/ (1.0, 1.0), (1.0, 4.0) /))
+end
+
+! { dg-final { scan-tree-dump "z = __complex__ \\(1.7e\\\+1, 4.0e\\\+0\\);" "original" } }
+! { dg-final { cleanup-tree-dump "original" } }

Re: [ping][PATCH][1 of 2] Add value range info to SSA_NAME for zero sign extension elimination in RTL

[Kugan]

On 17/06/13 18:33, Richard Biener wrote:

On Mon, 17 Jun 2013, Kugan wrote:
+/* Extract the value range of assigned exprassion for GIMPLE_ASSIGN stmt.
+   If the extracted value range is valid, return true else return
+   false.  */
+static bool
+extract_exp_value_range (gimple stmt, value_range_t *vr)
+{
+  gcc_assert (is_gimple_assign (stmt));
+  tree rhs1 = gimple_assign_rhs1 (stmt);
+  tree lhs = gimple_assign_lhs (stmt);
+  enum tree_code rhs_code = gimple_assign_rhs_code (stmt);
...
@@ -8960,6 +9016,23 @@ simplify_stmt_using_ranges (gimple_stmt_iterator
*gsi)
  {
enum tree_code rhs_code = gimple_assign_rhs_code (stmt);
tree rhs1 = gimple_assign_rhs1 (stmt);
+  tree lhs = gimple_assign_lhs (stmt);
+
+  /* Set value range information for ssa.  */
+  if (!POINTER_TYPE_P (TREE_TYPE (gimple_assign_lhs (stmt)))
+  && (TREE_CODE (gimple_assign_lhs (stmt)) == SSA_NAME)
+  && INTEGRAL_TYPE_P (TREE_TYPE (gimple_assign_lhs (stmt)))
+  && !SSA_NAME_RANGE_INFO (lhs))
+{
+  value_range_t vr = VR_INITIALIZER;
...
+  if (extract_exp_value_range (stmt, &vr))
+tree_ssa_set_value_range (lhs,
+  tree_to_double_int (vr.min),
+  tree_to_double_int (vr.max),
+  vr.type == VR_RANGE);
+}

This looks overly complicated to me.  In vrp_finalize you can simply do

   for (i = 0; i < num_vr_values; i++)
 if (vr_value[i])
   {
 tree name = ssa_name (i);
 if (POINTER_TYPE_P (name))
   continue;
 if (vr_value[i].type == VR_RANGE
 || vr_value[i].type == VR_ANTI_RANGE)
   tree_ssa_set_value_range (name, tree_to_double_int
(vr_value[i].min), tree_to_double_int (vr_value[i].max), vr_value[i].type
== VR_RANGE);
   }



Thanks Richard for taking time to review it.

I was doing something like what you are suggesting earlier but noticed 
some problems and that’s the reason why I changed.


For example, for the following testcase from the test suite,

unsigned long l = (unsigned long)-2;
unsigned short s;

int main () {
  long t = l + 1;
  s = l;
  if (s != (unsigned short) -2)
abort ();
  exit (0);
}

with the following gimple stmts

main ()
{
  short unsigned int s.1;
  long unsigned int l.0;

;;   basic block 2, loop depth 0
;;pred:   ENTRY
  l.0_2 = l;
  s.1_3 = (short unsigned int) l.0_2;
  s = s.1_3;
  if (s.1_3 != 65534)
goto ;
  else
goto ;
;;succ:   3
;;4

;;   basic block 3, loop depth 0
;;pred:   2
  abort ();
;;succ:

;;   basic block 4, loop depth 0
;;pred:   2
  exit (0);
;;succ:

}



has the following value range.

l.0_2: VARYING
s.1_3: [0, +INF]


From zero/sign extension point of view, the variable s.1_3 is expected 
to have a value that will overflow (or varying) as this is what is 
assigned to a smaller variable. extract_range_from_assignment initially 
calculates the value range as VARYING but later changed to [0, +INF] by 
extract_range_basic. What I need here is the value that will be assigned 
from the rhs expression and not the value that we will have with proper 
assignment.


I understand that the above code of mine needs to be changed but not 
convinced about the best way to do that.


I can possibly re-factor extract_range_from_assignment to give me this 
information with an additional argument. Could you kindly let me know 
your preference.





/* SSA name annotations.  */

+  union vrp_info_type {
+/* Pointer attributes used for alias analysis.  */
+struct GTY ((tag ("TREE_SSA_PTR_INFO"))) ptr_info_def *ptr_info;
+/* Value range attributes used for zero/sign extension elimination.
*/

/* Value range information.  */

+struct GTY ((tag ("TREE_SSA_RANGE_INFO"))) range_info_def
*range_info;
+  } GTY ((desc ("%1.def_stmt && !POINTER_TYPE_P (TREE_TYPE
((tree)&%1))"))) vrp;

why do you need to test %1.def_stmt here?



I have seen some tree_ssa_name with def_stmt NULL. Thats why I added 
this. Is that something that should never happen.



Thanks,
Kugan

Re: [Patch, Fortran] PR57785 - Fix folding of dot_product for complex vars

[Dominique Dhumieres]

Dear Tobias,

The patch is OK, but you may consider the following remarks:

(1) a comment before

+ c = gfc_simplify_conjg (a);

reminding the definition of the complex dot product.

(2) I don't like the scan-tree-dump: they are fragile and have a limited
coverage. I'ld prefer a test such as the following

! { dg-do run }
!
! PR fortran/57785
!
! Contributed by Kontantinos Anagnostopoulos
!
! The implicit complex conjugate was missing

if (DOT_PRODUCT ((/ (1.0, 2.0), (2.0, 3.0) /), (/ (1.0, 1.0), (1.0, 4.0) /))   &
   /= SUM (CONJG ((/ (1.0, 2.0), (2.0, 3.0) /))*(/ (1.0, 1.0), (1.0, 4.0) /))) &
   call abort ()
if (ANY (MATMUL ((/ (1.0, 2.0), (2.0, 3.0) /), &
 RESHAPE ((/ (1.0, 1.0), (1.0, 4.0) /),(/2, 1/))) /=   &
 SUM ((/ (1.0, 2.0), (2.0, 3.0) /)*(/ (1.0, 1.0), (1.0, 4.0) / &
call abort ()  
end

It checks that DOT_PRODUCT matches its definition (it will catch any attempt
to use CONJG on the second vector instead of the first). It also checks
that MATMUL works as expected.

Thanks for the patch,

Dominique

MIPS elimate trap-if-zero instruction if possible for divisions

[Graham Stott]

Hi Richard,
 
This patch attemps to elimate the TEQ instruction div DIV/MOD instructions
if possible (i.e the numerator is known to be non-zero)
 
I have introduced and seperated UNSPEC UNSPEC_SET_HILO_NOTRAP
which is generation by a peephole2 when the trap is known not to be required.
 
The peephole's work by checking for a REG_EQUAL or/REG_EQUIV on the
instruction which sets the numerator for the DIV/MOD this doesn't catch all
possible cases but does catch the common cases where ths numerator is
set set in a insn immediately preceeding the DIV/MOD.
 
ChangeLog
 
2013-07-03Graham Stottgrah...@btinternet.com
* config/mips/mips.c: (mips_output_division) : Make static
  add new traps enables/disables the geration if a trap
 insn is TRAPS for divison are enabled.
 (mips_output_division_with_trap): New enables geration of trap
 on division by zero instruction.
 (mips_output_division_without_trap) New disables generation of
 trap.on division by zero instruction.
* config/mips/mips-protos.h (mips_output_divison): Delete.
  (mips_output_division_with_trap):  Add outputs a division 
sequence
  with a trap-if-zero if required.
  (mips_output_division_without_trap):  Add outputs the division
 sequence without and trap-if-zero instruction.
 * config/mips/mips.md (UNSPEC_SET_HILO_NOTRAP): Add unspec
   and two peephole2 defines
   (divmod4_hilo_: Rename
   divmod4_hilo__with_trap.
(divmod4_hilo__without_trap): New
 * config/mips/predicates.md (binary_operator): Define.
 (unary_operator): Define.

mips.md.diff
Description: Binary data


mips-protoes.h.diff
Description: Binary data


mips.c.diff
Description: Binary data


predicates.md.diff
Description: Binary data

RFC DIVMOD expansion in expand_divmod:expmed.c

[Graham Stott]

All,
 
The DIV/MOD expansion performed in expmed is basically driven by RTX costs/-Os
that are provided by the backend.In a few instances these costs and or _os 
appear to be ignored.
 
One senerio  is divsion by a constant in a mode whose size <= 
HOST_BITS_PER_WIDE_INT
it will always expand the DIV/MOD using multiplation (Montgomery) when 
optimizing for size.
 
Shouldn't this expansion be be guarded by  !speed and the expansion skipped 
allowing
the backend open coding an DIV/MOD sequence or libcall.
 
Is guarding this with a !speed guard the best thing to do for most backends or 
should this be 
controlled with a new target hook with the default hook returning true for yes 
expand maintaining
the status quo giving the backends to override.
 
Another senerio is signed divison of a power-of-2  if the backend dosn't have 
optabs for sdiv
and sdivmod then  expand_sdiv_pow2 will be choosen even if otimizing for size 
and
sdiv_pow2_cheap() retuns true!
 
 if (sdiv_pow2_cheap (speed, compute_mode)
   && ((optab_handler (sdiv_optab, compute_mode)
    != CODE_FOR_nothing)
   || (optab_handler (sdivmod_optab, compute_mode)
!= CODE_FOR_nothing)))
    quotient = expand_divmod (0, TRUNC_DIV_EXPR,
  compute_mode, op0,
  gen_int_mode (abs_d,
 compute_mode),
  NULL_RTX, 0);
  else
    quotient = expand_sdiv_pow2 (compute_mode, op0, abs_d);
 
When optimizing for size (!speed) and sdiv_pow2_cheap() is true we ideally 
don't want to use 
expand_sdiv_pow2 but instead let the back end opend code the DIV.
 
Question how can one determine if a backend can open code a DIV/MOD
 
 Graham

MIPS don't gererate MUL when muliplying by constant of for 2^N +/- 1 optimizing for size

[Graham Stott]

Hi Richard,
 
When -Os is used  and the multiplier is of the for 2^N +- 1 we generate a MUL 
instruction
rather that a  shift-left   N and add-sub 1.
 
The problem is that rtx cost for the MUL is too cheap causing the shift-left 
and add-sub sequence
to be  more expensive.
 
This patch makes the MUL slightly more expension so the alternate sequence and 
better sequence
used. The shift + add/sub is faster and can probaly be scheduled better.
 
This change is code size neutral because the MUL requires a load-immediate.
 
ChangeLog:
* config/mips/mips.c: (mips_rtx_costs): Slightly increase cost of MUL 
when optimizing
   for size. This allows a better sequence to be choosen when multiply by a 
constant of the
form 2^N +- 1.
 
Graham

mips.c.diff
Description: Binary data

[C++ PATCH] Fix up static_cast/reinterpret_cast parsing in template argument (PR c++/57771)

[Jakub Jelinek]

Hi!

When parsing static_cast (expression) part inside of template argument,
greater_than_is_operator_p isn't temporarily set and thus the parser
considers >> in C++11 there as end of the the template argument, despite
this appearing before terminating ).

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk/4.8?

2013-07-01  Jakub Jelinek  

PR c++/57771
* parser.c (cp_parser_postfix_expression) 
Temporarily set parser->greater_than_is_operator_p for
cp_parser_expression and restore from saved value afterwards.

* g++.dg/template/arg9.C: New test.

--- gcc/cp/parser.c.jj  2013-07-01 22:43:42.0 +0200
+++ gcc/cp/parser.c 2013-07-01 22:47:14.220634900 +0200
@@ -5576,11 +5576,18 @@ cp_parser_postfix_expression (cp_parser
/* Restore the old message.  */
parser->type_definition_forbidden_message = saved_message;
 
+   bool saved_greater_than_is_operator_p
+ = parser->greater_than_is_operator_p;
+   parser->greater_than_is_operator_p = true;
+
/* And the expression which is being cast.  */
cp_parser_require (parser, CPP_OPEN_PAREN, RT_OPEN_PAREN);
expression = cp_parser_expression (parser, /*cast_p=*/true, & idk);
cp_parser_require (parser, CPP_CLOSE_PAREN, RT_CLOSE_PAREN);
 
+   parser->greater_than_is_operator_p
+ = saved_greater_than_is_operator_p;
+
/* Only type conversions to integral or enumeration types
   can be used in constant-expressions.  */
if (!cast_valid_in_integral_constant_expression_p (type)
--- gcc/testsuite/g++.dg/template/arg9.C.jj 2013-07-01 22:52:22.780699584 
+0200
+++ gcc/testsuite/g++.dg/template/arg9.C2013-07-01 22:51:22.0 
+0200
@@ -0,0 +1,8 @@
+// PR c++/57771
+// { dg-do compile }
+
+template 
+struct S {};
+
+S  (4>>2)> s1;
+S  (4>>2)> s2;

Jakub

[PATCH] Fix up gather addressing in -m64 -fpic code (PR target/57777)

[Jakub Jelinek]

Hi!

In 64-bit PIC mode, we allow SYMBOL_REF/LABEL_REF or that + constant offset
as disp, because we can use %rip addressing in that case, but as VSIB
addressing doesn't allow %rip addressing, we have to disallow even those.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk/4.8?

2013-07-02  Jakub Jelinek  

PR target/5
* config/i386/predicates.md (vsib_address_operand): Disallow
SYMBOL_REF or LABEL_REF in parts.disp if TARGET_64BIT && flag_pic.

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

--- gcc/config/i386/predicates.md.jj2013-04-29 09:38:16.0 +0200
+++ gcc/config/i386/predicates.md   2013-07-02 20:39:00.933572451 +0200
@@ -880,19 +880,28 @@ (define_predicate "vsib_address_operand"
 return false;
 
   /* VSIB addressing doesn't support (%rip).  */
-  if (parts.disp && GET_CODE (parts.disp) == CONST)
+  if (parts.disp)
 {
-  disp = XEXP (parts.disp, 0);
-  if (GET_CODE (disp) == PLUS)
-   disp = XEXP (disp, 0);
-  if (GET_CODE (disp) == UNSPEC)
-   switch (XINT (disp, 1))
- {
- case UNSPEC_GOTPCREL:
- case UNSPEC_PCREL:
- case UNSPEC_GOTNTPOFF:
-   return false;
- }
+  disp = parts.disp;
+  if (GET_CODE (disp) == CONST)
+   {
+ disp = XEXP (disp, 0);
+ if (GET_CODE (disp) == PLUS)
+   disp = XEXP (disp, 0);
+ if (GET_CODE (disp) == UNSPEC)
+   switch (XINT (disp, 1))
+ {
+ case UNSPEC_GOTPCREL:
+ case UNSPEC_PCREL:
+ case UNSPEC_GOTNTPOFF:
+   return false;
+ }
+   }
+  if (TARGET_64BIT
+ && flag_pic
+ && (GET_CODE (disp) == SYMBOL_REF
+ || GET_CODE (disp) == LABEL_REF))
+   return false;
 }
 
   return true;
--- gcc/testsuite/gcc.target/i386/pr5.c.jj  2013-07-02 20:45:33.789156903 
+0200
+++ gcc/testsuite/gcc.target/i386/pr5.c 2013-07-02 20:45:18.0 
+0200
@@ -0,0 +1,13 @@
+/* PR target/5 */
+/* { dg-do assemble { target avx2 } } */
+/* { dg-options "-O3 -mavx2" } */
+/* { dg-additional-options "-fpic" { target fpic } } */
+
+void
+foo (unsigned long *x, int *y)
+{
+  static unsigned long b[2] = { 0x0UL, 0x9908b0dfUL };
+  int c;
+  for (c = 0; c < 512; c++)
+x[c] = b[x[c] & 1UL];
+}

Jakub

Fix missing use of -Werror when compiling files in c-familty directory

[Graham Stott]

All,
 
 
Files in the c-family directory are being compiled during stage3 without 
-Werror and
other warningb flags that are part of WARN_STRICT flags.
 
Fixing this shows that array_notation_common.c  generates unused variable 
warnings
and will break the build after the apcth is applied.
 
 
ChangeLog
03-07-2013Graham Stott 
* gcc/Makegfvile.in: Define c-family-warn. to WARN_STRICT.

Makefile.in.diff
Description: Binary data

Committed: fix for frame-pointer-clobbering in builtins.c:expand_builtin_setjmp_receiver

[Hans-Peter Nilsson]

Eric Botcazou asked that I re-apply this previously reverted patch, so
here goes.  Bootstrapped+regression-test x86_64-unknown-linux-gnu at
r200585 with and without -m32.  The 32-bit i686-* aka. -m32 previously
exposed PR55030.  Though that PR was originally about the regression
causing the revert, it's also where the discussion about re-applying
the patch is, so I cross-referenced it.  (There are also notes that
this patch has also been checked on half a dozen other targets.)

While there were no regressions testing the patch, there *was* a
FAIL turned PASS: libgomp.c++/loop-3.C (libgomp.sum).  I'm guessing
that was somewhat spurious and caused by an unstable test-case which
could just as well have been the other way round (thankful it didn't)
but I'm a bit uncertain; maybe those gomp thingies make use of
__builtin_setjmp somehow.

See  for the
reason for the original commit.

PR middle-end/55030
* stmt.c (expand_nl_goto_receiver): Remove almost-copy of
expand_builtin_setjmp_receiver.
(expand_label): Adjust, call expand_builtin_setjmp_receiver
with NULL for the label parameter.
* builtins.c (expand_builtin_setjmp_receiver): Don't clobber
the frame-pointer.  Adjust comments.
[HAVE_builtin_setjmp_receiver]: Emit builtin_setjmp_receiver
only if LABEL is non-NULL.

Index: gcc/builtins.c
===
--- gcc/builtins.c  (revision 192675)
+++ gcc/builtins.c  (revision 192676)
@@ -885,14 +885,15 @@ expand_builtin_setjmp_setup (rtx buf_add
 }

 /* Construct the trailing part of a __builtin_setjmp call.  This is
-   also called directly by the SJLJ exception handling code.  */
+   also called directly by the SJLJ exception handling code.
+   If RECEIVER_LABEL is NULL, instead contruct a nonlocal goto handler.  */

 void
 expand_builtin_setjmp_receiver (rtx receiver_label ATTRIBUTE_UNUSED)
 {
   rtx chain;

-  /* Clobber the FP when we get here, so we have to make sure it's
+  /* Mark the FP as used when we get here, so we have to make sure it's
  marked as used by this function.  */
   emit_use (hard_frame_pointer_rtx);

@@ -907,17 +908,28 @@ expand_builtin_setjmp_receiver (rtx rece
 #ifdef HAVE_nonlocal_goto
   if (! HAVE_nonlocal_goto)
 #endif
-{
-  emit_move_insn (virtual_stack_vars_rtx, hard_frame_pointer_rtx);
-  /* This might change the hard frame pointer in ways that aren't
-apparent to early optimization passes, so force a clobber.  */
-  emit_clobber (hard_frame_pointer_rtx);
-}
+/* First adjust our frame pointer to its actual value.  It was
+   previously set to the start of the virtual area corresponding to
+   the stacked variables when we branched here and now needs to be
+   adjusted to the actual hardware fp value.
+
+   Assignments to virtual registers are converted by
+   instantiate_virtual_regs into the corresponding assignment
+   to the underlying register (fp in this case) that makes
+   the original assignment true.
+   So the following insn will actually be decrementing fp by
+   STARTING_FRAME_OFFSET.  */
+emit_move_insn (virtual_stack_vars_rtx, hard_frame_pointer_rtx);

 #if !HARD_FRAME_POINTER_IS_ARG_POINTER
   if (fixed_regs[ARG_POINTER_REGNUM])
 {
 #ifdef ELIMINABLE_REGS
+  /* If the argument pointer can be eliminated in favor of the
+frame pointer, we don't need to restore it.  We assume here
+that if such an elimination is present, it can always be used.
+This is the case on all known machines; if we don't make this
+assumption, we do unnecessary saving on many machines.  */
   size_t i;
   static const struct elims {const int from, to;} elim_regs[] = 
ELIMINABLE_REGS;

@@ -938,7 +950,7 @@ expand_builtin_setjmp_receiver (rtx rece
 #endif

 #ifdef HAVE_builtin_setjmp_receiver
-  if (HAVE_builtin_setjmp_receiver)
+  if (receiver_label != NULL && HAVE_builtin_setjmp_receiver)
 emit_insn (gen_builtin_setjmp_receiver (receiver_label));
   else
 #endif
Index: gcc/stmt.c
===
--- gcc/stmt.c  (revision 192675)
+++ gcc/stmt.c  (revision 192676)
@@ -106,7 +106,6 @@ extern basic_block label_to_block_fn (st

 static int n_occurrences (int, const char *);
 static bool tree_conflicts_with_clobbers_p (tree, HARD_REG_SET *);
-static void expand_nl_goto_receiver (void);
 static bool check_operand_nalternatives (tree, tree);
 static bool check_unique_operand_names (tree, tree, tree);
 static char *resolve_operand_name_1 (char *, tree, tree, tree);
@@ -200,7 +199,7 @@ expand_label (tree label)

   if (DECL_NONLOCAL (label))
 {
-  expand_nl_goto_receiver ();
+  expand_builtin_setjmp_receiver (NULL);
   nonlocal_goto_handler_labels
= gen_rtx_EXPR_LIST (VOIDmode, label_r,
 nonlo

Re: Fix missing use of -Werror when compiling files in c-familty directory

[Joseph S. Myers]

On Wed, 3 Jul 2013, Graham Stott wrote:

> Files in the c-family directory are being compiled during stage3 without 
> -Werror and other warningb flags that are part of WARN_STRICT flags.
> Fixing this shows that array_notation_common.c? generates unused 
> variable warnings and will break the build after the apcth is applied.
> ?
> ?
> ChangeLog
> 03-07-2013Graham Stott 
> * gcc/Makegfvile.in:?Define c-family-warn.?to WARN_STRICT.

OK with a properly formatted ChangeLog entry, once the warnings are fixed 
of course.

2013-07-03  Graham Stott  

* Makefile.in (c-family-warn): Define to $(WARN_STRICT).

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

[libobjc]: Allow SjLj for x64 windows target

[Kai Tietz]

Hi,

this patch fixes Obj-C's exception handling code for SEH x64.  For it
the guard for forcing SjLj was missing and therefore leads to issues,
if OP wants to force SjLj.

ChangeLog

2013-07-03  Kai Tietz  

* exception.c: Add check for SjLj to SEH blocks.

Tested for x86_64-w64-mingw32, and i686-pc-cygwin.  I will apply patch
tomorrow, if there are no objections.

Regards,
Kai

Index: exception.c
===
--- exception.c(Revision 200643)
+++ exception.c(Arbeitskopie)
@@ -202,7 +202,7 @@ get_ttype_entry (struct lsda_header_info *info, _U
 #ifdef SJLJ_EXCEPTIONS
 #define PERSONALITY_FUNCTION__gnu_objc_personality_sj0
 #define __builtin_eh_return_data_regno(x) x
-#elif defined(__SEH__)
+#elif defined(__SEH__) && !defined (__USING_SJLJ_EXCEPTIONS__)
 #define PERSONALITY_FUNCTION__gnu_objc_personality_imp
 #else
 #define PERSONALITY_FUNCTION__gnu_objc_personality_v0
@@ -227,7 +227,7 @@ PERSONALITY_FUNCTION (_Unwind_State state,

 #define CONTINUE_UNWINDING return _URC_CONTINUE_UNWIND

-#ifdef __SEH__
+#if defined (__SEH__) && !defined (__USING_SJLJ_EXCEPTIONS__)
 static
 #endif
 _Unwind_Reason_Code
@@ -524,7 +524,7 @@ objc_exception_throw (id exception)
   abort ();
 }

-#ifdef __SEH__
+#if defined (__SEH__) && !defined (__USING_SJLJ_EXCEPTIONS__)
 EXCEPTION_DISPOSITION
 __gnu_objc_personality_seh0 (PEXCEPTION_RECORD ms_exc, void *this_frame,
  PCONTEXT ms_orig_context,
@@ -533,4 +533,4 @@ __gnu_objc_personality_seh0 (PEXCEPTION_RECORD ms_
   return _GCC_specific_handler (ms_exc, this_frame, ms_orig_context,
 ms_disp, __gnu_objc_personality_imp);
 }
-#endif /* SEH */
+#endif

Fix ununsed variables before my patch adding missing -Werror

[Graham Stott]

 
This patch fixes the warnings from array-notation_common.c so that I can
then apply my Makefile missing -Werror patch.
 
Graham
 
ChangeLog
03-07-2013  graham.stott  graham.st...@btinternet.com
* c-familly/array_notation_comon.c (length_mismatch_expr_p): Delete 
unused
    varables l_length and l_node
 
Graham

array-notation-common.c.diff
Description: Binary data

Re: Fix missing use of -Werror when compiling files in c-familty directory

[Chung-Ju Wu]

Hi, Graham,

2013/7/3 Graham Stott :
> All,
>
> Files in the c-family directory are being compiled during stage3 without 
> -Werror and
> other warningb flags that are part of WARN_STRICT flags.
>
> Fixing this shows that array_notation_common.c  generates unused variable 
> warnings
> and will break the build after the apcth is applied.
>
>
> ChangeLog
> 03-07-2013Graham Stott 
> * gcc/Makegfvile.in: Define c-family-warn to WARN_STRICT.

A typo fix: STRICT_WARN.


Best regards,
jasonwucj

Re: Fix missing use of -Werror when compiling files in c-familty directory

[Chung-Ju Wu]

2013/7/3 Joseph S. Myers :
> On Wed, 3 Jul 2013, Graham Stott wrote:
>
>> Files in the c-family directory are being compiled during stage3 without
>> -Werror and other warningb flags that are part of WARN_STRICT flags.
>> Fixing this shows that array_notation_common.c  generates unused
>> variable warnings and will break the build after the apcth is applied.
>>
>>
>> ChangeLog
>> 03-07-2013Graham Stott 
>> * gcc/Makegfvile.in: Define c-family-warn. to WARN_STRICT.
>
> OK with a properly formatted ChangeLog entry, once the warnings are fixed
> of course.
>
> 2013-07-03  Graham Stott  
>
> * Makefile.in (c-family-warn): Define to $(WARN_STRICT).
>
> --
> Joseph S. Myers
> jos...@codesourcery.com

Hi, Balaji,

There is a warning in recent change of array_notation_common.c source.

In the revision r200405: http://gcc.gnu.org/r200405
you made some changes in length_mismatch_in_expr_p()
and use the variables l_length & l_node.

But in the revision r200554: http://gcc.gnu.org/r200554
you removed following two statements:
l_node = int_cst_value (list[ii][jj].length);
l_length = int_cst_value (length);
causing l_length & l_node to be unused variables.

I think it is safe to remove the declaration to avoid warning
after r200554.  What do you think? :-)


Best regards,
jasonwucj

Re: [PATCH, rs6000] PR target/57150, do not use VSX instructions for long double caller saves

[Joseph S. Myers]

On Fri, 3 May 2013, Michael Meissner wrote:

> 2013-05-03  Michael Meissner  
> 
>   PR target/57150
>   * config/rs6000/rs6000.h (HARD_REGNO_CALLER_SAVE_MODE): Use DFmode
>   to save TFmode registers and DImode to save TImode registers for
>   caller save operations.
>   (HARD_REGNO_CALL_PART_CLOBBERED): TFmode and TDmode do not need to
>   mark being partially clobbered since they only use the first
>   double word.
> 
>   * config/rs6000/rs6000.c (rs6000_init_hard_regno_mode_ok): TFmode
>   and TDmode only use the upper 64-bits of each VSX register.

That change has the effect that reload thinks TFmode (and no doubt
TDmode) only takes two registers even when in general registers,
causing a segfault in glibc's test-ldouble built for soft float.

I'm testing this patch (this diff is against 4.8 branch) to fix this;
at least, it fixes the glibc testing issue.  Since the original patch
went on 4.7 and 4.8 branches as well as trunk, I propose this patch
for the branches as well as trunk.  You may wish to test it in your
original VSX configuration.

2013-07-03  Joseph Myers  

* config/rs6000/rs6000.c (rs6000_init_hard_regno_mode_ok): Only
adjust register size for TDmode and TFmode for VSX registers.

Index: config/rs6000/rs6000.c
===
--- config/rs6000/rs6000.c  (revision 200641)
+++ config/rs6000/rs6000.c  (working copy)
@@ -2190,7 +2190,8 @@ rs6000_init_hard_regno_mode_ok (bool global_init_p
  int reg_size2 = reg_size;
 
  /* TFmode/TDmode always takes 2 registers, even in VSX.  */
- if (m == TDmode || m == TFmode)
+ if (TARGET_VSX && VSX_REG_CLASS_P (c)
+ && (m == TDmode || m == TFmode))
reg_size2 = UNITS_PER_FP_WORD;
 
  rs6000_class_max_nregs[m][c]

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

Re: Fix missing use of -Werror when compiling files in c-familty directory

[Chung-Ju Wu]

2013/7/4 Chung-Ju Wu :
>> On Wed, 3 Jul 2013, Graham Stott wrote:
>>
>>> Files in the c-family directory are being compiled during stage3 without
>>> -Werror and other warningb flags that are part of WARN_STRICT flags.
>>> Fixing this shows that array_notation_common.c  generates unused
>>> variable warnings and will break the build after the apcth is applied.
>>>
> But in the revision r200554: http://gcc.gnu.org/r200554
> you removed following two statements:
> l_node = int_cst_value (list[ii][jj].length);
> l_length = int_cst_value (length);
> causing l_length & l_node to be unused variables.
>
> I think it is safe to remove the declaration to avoid warning
> after r200554.  What do you think? :-)
>
>

A-ha~ great, I just noticed Graham has posted the patch:
http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00132.html


Best regards,
jasonwucj

Re: [c++-concepts] requires expression semantics

[Jason Merrill]

On 07/01/2013 01:27 PM, Andrew Sutton wrote:

Unfortunately, the behavior differs from the test suite for
std::is_convertible. In particular, this fails:

 static_assert(__is_convertible_to(int(int), int(&)(int)), "");

whereas this succeeds )

 static_assert(is_convertible::value, "");


Hmm, that probably has to do with reference decay; we don't handle 
conversion from reference type everywhere because there are no 
expressions of reference type.  So perhaps in the case of REFERENCE_TYPE 
can_convert should build a dummy expression and call 
convert_from_reference; did your CAST_EXPR work for this test?



In the formal model I'm designing, __is_valid_expr(e) evaluates to
true when e has a type. Although, if I'm instantiating a non-dependent
expression, I'll probably get an error_mark_node if the expression
can't be typed. Right?


Right.  Any expression either has a type, is type-dependent, or is 
erroneous; any erroneous expression will show up as error_mark_node.



+/* The REQ expressions are unary expressions that specify inididual


"individual"


+  // evaluatd.


"evaluated"

Jason

Re: [C++ PATCH] Fix up static_cast/reinterpret_cast parsing in template argument (PR c++/57771)

[Jason Merrill]

OK.

Jason

[gomp4] 3 minor OpenMP parsing tweaks

[Jakub Jelinek]

Hi!

I've noticed today or recently 3 separate issues that this patch attempts to
address.
1) the sections syntax is (and has been that way already back in OpenMP 2.5):
#pragma omp sections [clause[[,] clause] ...] new-line
{
  [#pragma omp section new-line]
  structured-block
  [#pragma omp section new-line
  structured-block ]
  ...
}
but we were happily allowing a sequence of statements before first
#pragma omp section, rather than a single statement or { sequence of
statements }.
2) on single construct, there is a restriction:
"The copyprivate clause must not be used with the nowait clause."
that we weren't actually enforcing - came over this by seeing that
we would just force a barrier when seeing a copyprivate, so essentially
silently ignoring the nowait clause.  Again, this is already in OpenMP 2.5.
3) the seq_cst in the syntax in OpenMP 4.0 has to come after atomic-clause
and no comma is allowed in between those two (both in atomic construct
description and in the appendix grammar).

Richard, does this look ok to you?

2013-07-03  Jakub Jelinek  

* omp-low.c (expand_omp_single): Don't force barrier for
copyprivate.
gcc/c/
* c-parser.c (c_parser_omp_atomic): Disallow seq_cst before
atomic-clause, disallow comma in between atomic-clause and
seq_cst.
(c_parser_omp_sections_scope): If section-sequence doesn't
start with #pragma omp section, require exactly one structured-block
instead of sequence of statements.
* c-typeck.c (c_finish_omp_clauses): Diagnose copyprivate clause
appearing together with nowait clause.
gcc/cp/
* parser.c (cp_parser_omp_atomic): Disallow seq_cst before
atomic-clause, disallow comma in between atomic-clause and
seq_cst.
(cp_parser_omp_sections_scope): If section-sequence doesn't
start with #pragma omp section, require exactly one structured-block
instead of sequence of statements.
* semantics.c (finish_omp_clauses): Diagnose copyprivate clause
appearing together with nowait clause.
gcc/testsuite/
* g++.dg/gomp/block-0.C: Adjust for stricter #pragma omp sections
parser.
* g++.dg/gomp/block-3.C: Likewise.
* gcc.dg/gomp/block-3.c: Likewise.
* gcc.dg/gomp/nesting-1.c: Likewise.  Add further #pragma omp sections
nesting tests.
* c-c++-common/gomp/sections1.c: New test.
* c-c++-common/gomp/single1.c: New test.
* c-c++-common/gomp/atomic-16.c: New test.
libgomp/
* testsuite/libgomp.c++/atomic-14.C: Adjust for stricter atomic
seq_cst parser.
* testsuite/libgomp.c++/atomic-15.C: Likewise.
* testsuite/libgomp.c/atomic-17.c: Likewise.

--- gcc/c/c-parser.c.jj 2013-06-26 12:13:50.0 +0200
+++ gcc/c/c-parser.c2013-07-03 17:17:40.614573329 +0200
@@ -10391,18 +10391,6 @@ c_parser_omp_atomic (location_t loc, c_p
   if (c_parser_next_token_is (parser, CPP_NAME))
 {
   const char *p = IDENTIFIER_POINTER (c_parser_peek_token (parser)->value);
-  if (!strcmp (p, "seq_cst"))
-   {
- seq_cst = true;
- c_parser_consume_token (parser);
- if (c_parser_next_token_is (parser, CPP_COMMA)
- && c_parser_peek_2nd_token (parser)->type == CPP_NAME)
-   c_parser_consume_token (parser);
-   }
-}
-  if (c_parser_next_token_is (parser, CPP_NAME))
-{
-  const char *p = IDENTIFIER_POINTER (c_parser_peek_token (parser)->value);
 
   if (!strcmp (p, "read"))
code = OMP_ATOMIC_READ;
@@ -10417,21 +10405,13 @@ c_parser_omp_atomic (location_t loc, c_p
   if (p)
c_parser_consume_token (parser);
 }
-  if (!seq_cst)
+  if (c_parser_next_token_is (parser, CPP_NAME))
 {
-  if (c_parser_next_token_is (parser, CPP_COMMA)
- && c_parser_peek_2nd_token (parser)->type == CPP_NAME)
-   c_parser_consume_token (parser);
-
-  if (c_parser_next_token_is (parser, CPP_NAME))
+  const char *p = IDENTIFIER_POINTER (c_parser_peek_token (parser)->value);
+  if (!strcmp (p, "seq_cst"))
{
- const char *p
-   = IDENTIFIER_POINTER (c_parser_peek_token (parser)->value);
- if (!strcmp (p, "seq_cst"))
-   {
- seq_cst = true;
- c_parser_consume_token (parser);
-   }
+ seq_cst = true;
+ c_parser_consume_token (parser);
}
 }
   c_parser_skip_to_pragma_eol (parser);
@@ -11231,21 +11211,7 @@ c_parser_omp_sections_scope (location_t
 
   if (c_parser_peek_token (parser)->pragma_kind != PRAGMA_OMP_SECTION)
 {
-  substmt = push_stmt_list ();
-
-  while (1)
-   {
-  c_parser_statement (parser);
-
- if (c_parser_peek_token (parser)->pragma_kind == PRAGMA_OMP_SECTION)
-   break;
- if (c_parser_next_token_is (parser, CPP_CLOSE_BRACE))
-   break;
- if (c_parser_next_token_is (parser, CPP_EOF))
-   break;
-

Re: MIPS don't gererate MUL when muliplying by constant of for 2^N +/- 1 optimizing for size

[Richard Sandiford]

Graham Stott  writes:
> When -Os is used and the multiplier is of the for 2^N +- 1 we generate
> a MUL instruction rather that a shift-left N and add-sub 1.
> 
> The problem is that rtx cost for the MUL is too cheap causing the
> shift-left and add-sub sequence to be more expensive.
> 
> This patch makes the MUL slightly more expension so the alternate
> sequence and better sequence used. The shift + add/sub is faster and
> can probaly be scheduled better.
> 
> This change is code size neutral because the MUL requires a load-immediate.

Hmm, but this code is giving the cost of the multiplication itself.
The cost of the immediate is added separately due to the "return false".
I'd have expected the cumulative cost of constant multiplications to be 2
for ISA_HAS_MULS and 3 for !ISA_HAS_MUL3, which sounds correct.

So is the problem that we have two sequences with identical cost and
GCC isn't sure which to pick?  If so:

  *total = COSTS_N_INSNS (ISA_HAS_MUL3 ? 1 : 2) + 1;

(i.e. a sub-insn bias) would be OK.  There should be a testcase though.

Thanks,
Richard

Re: [libobjc]: Allow SjLj for x64 windows target

[Andrew Pinski]

On Wed, Jul 3, 2013 at 8:11 AM, Kai Tietz  wrote:
> Hi,
>
> this patch fixes Obj-C's exception handling code for SEH x64.  For it
> the guard for forcing SjLj was missing and therefore leads to issues,
> if OP wants to force SjLj.
>
> ChangeLog
>
> 2013-07-03  Kai Tietz  
>
> * exception.c: Add check for SjLj to SEH blocks.
>
> Tested for x86_64-w64-mingw32, and i686-pc-cygwin.  I will apply patch
> tomorrow, if there are no objections.

This is ok.

Thanks,
Andrew

>
> Regards,
> Kai
>
> Index: exception.c
> ===
> --- exception.c(Revision 200643)
> +++ exception.c(Arbeitskopie)
> @@ -202,7 +202,7 @@ get_ttype_entry (struct lsda_header_info *info, _U
>  #ifdef SJLJ_EXCEPTIONS
>  #define PERSONALITY_FUNCTION__gnu_objc_personality_sj0
>  #define __builtin_eh_return_data_regno(x) x
> -#elif defined(__SEH__)
> +#elif defined(__SEH__) && !defined (__USING_SJLJ_EXCEPTIONS__)
>  #define PERSONALITY_FUNCTION__gnu_objc_personality_imp
>  #else
>  #define PERSONALITY_FUNCTION__gnu_objc_personality_v0
> @@ -227,7 +227,7 @@ PERSONALITY_FUNCTION (_Unwind_State state,
>
>  #define CONTINUE_UNWINDING return _URC_CONTINUE_UNWIND
>
> -#ifdef __SEH__
> +#if defined (__SEH__) && !defined (__USING_SJLJ_EXCEPTIONS__)
>  static
>  #endif
>  _Unwind_Reason_Code
> @@ -524,7 +524,7 @@ objc_exception_throw (id exception)
>abort ();
>  }
>
> -#ifdef __SEH__
> +#if defined (__SEH__) && !defined (__USING_SJLJ_EXCEPTIONS__)
>  EXCEPTION_DISPOSITION
>  __gnu_objc_personality_seh0 (PEXCEPTION_RECORD ms_exc, void *this_frame,
>   PCONTEXT ms_orig_context,
> @@ -533,4 +533,4 @@ __gnu_objc_personality_seh0 (PEXCEPTION_RECORD ms_
>return _GCC_specific_handler (ms_exc, this_frame, ms_orig_context,
>  ms_disp, __gnu_objc_personality_imp);
>  }
> -#endif /* SEH */
> +#endif

Re: MIPS elimate trap-if-zero instruction if possible for divisions

[Richard Sandiford]

Graham Stott  writes:
> Hi Richard,
>  
> This patch attemps to elimate the TEQ instruction div DIV/MOD instructions
> if possible (i.e the numerator is known to be non-zero)
>  
> I have introduced and seperated UNSPEC UNSPEC_SET_HILO_NOTRAP
> which is generation by a peephole2 when the trap is known not to be required.
>  
> The peephole's work by checking for a REG_EQUAL or/REG_EQUIV on the
> instruction which sets the numerator for the DIV/MOD this doesn't catch all
> possible cases but does catch the common cases where ths numerator is
> set set in a insn immediately preceeding the DIV/MOD.

Nice idea, but TBH, I think I'd prefer to expose the trap code at expand time
and let the rtl optimisers try to remove it.  I can't remember any correctness
reason why that wouldn't work.  I think the only reason we don't do it yet is
because (before gimple) there was a preference for keeping the division as
a unit during early rtl optimisations.

Thanks,
Richard

Re: MIPS elimate trap-if-zero instruction if possible for divisions

[Jeff Law]

On 07/03/13 11:42, Richard Sandiford wrote:

Graham Stott  writes:

Hi Richard,

This patch attemps to elimate the TEQ instruction div DIV/MOD instructions
if possible (i.e the numerator is known to be non-zero)

I have introduced and seperated UNSPEC UNSPEC_SET_HILO_NOTRAP
which is generation by a peephole2 when the trap is known not to be required.

The peephole's work by checking for a REG_EQUAL or/REG_EQUIV on the
instruction which sets the numerator for the DIV/MOD this doesn't catch all
possible cases but does catch the common cases where ths numerator is
set set in a insn immediately preceeding the DIV/MOD.


Nice idea, but TBH, I think I'd prefer to expose the trap code at expand time
and let the rtl optimisers try to remove it.  I can't remember any correctness
reason why that wouldn't work.  I think the only reason we don't do it yet is
because (before gimple) there was a preference for keeping the division as
a unit during early rtl optimisations.
Yea, we ought to be reasonably good at detecting non-zero ranges in VRP 
and eliminating the trap.  Doing it that way may also expose weaknesses 
in VRP which obviously we'd like to fix.


jeff

Re: [gomp4] 3 minor OpenMP parsing tweaks

[Richard Henderson]

On 07/03/2013 10:30 AM, Jakub Jelinek wrote:
> 2013-07-03  Jakub Jelinek  
> 
>   * omp-low.c (expand_omp_single): Don't force barrier for
>   copyprivate.
> gcc/c/
>   * c-parser.c (c_parser_omp_atomic): Disallow seq_cst before
>   atomic-clause, disallow comma in between atomic-clause and
>   seq_cst.
>   (c_parser_omp_sections_scope): If section-sequence doesn't
>   start with #pragma omp section, require exactly one structured-block
>   instead of sequence of statements.
>   * c-typeck.c (c_finish_omp_clauses): Diagnose copyprivate clause
>   appearing together with nowait clause.
> gcc/cp/
>   * parser.c (cp_parser_omp_atomic): Disallow seq_cst before
>   atomic-clause, disallow comma in between atomic-clause and
>   seq_cst.
>   (cp_parser_omp_sections_scope): If section-sequence doesn't
>   start with #pragma omp section, require exactly one structured-block
>   instead of sequence of statements.
>   * semantics.c (finish_omp_clauses): Diagnose copyprivate clause
>   appearing together with nowait clause.
> gcc/testsuite/
>   * g++.dg/gomp/block-0.C: Adjust for stricter #pragma omp sections
>   parser.
>   * g++.dg/gomp/block-3.C: Likewise.
>   * gcc.dg/gomp/block-3.c: Likewise.
>   * gcc.dg/gomp/nesting-1.c: Likewise.  Add further #pragma omp sections
>   nesting tests.
>   * c-c++-common/gomp/sections1.c: New test.
>   * c-c++-common/gomp/single1.c: New test.
>   * c-c++-common/gomp/atomic-16.c: New test.
> libgomp/
>   * testsuite/libgomp.c++/atomic-14.C: Adjust for stricter atomic
>   seq_cst parser.
>   * testsuite/libgomp.c++/atomic-15.C: Likewise.
>   * testsuite/libgomp.c/atomic-17.c: Likewise.

Ok.


r~

Re: [Google] Fix discriminator assignment for stmts

[Cary Coutant]

> -  locus = location_with_discriminator (
> -  locus, next_discriminator_for_locus (locus));
> +  discriminator = next_discriminator_for_locus (locus);
>
> -  if (block != NULL)
> -locus = COMBINE_LOCATION_DATA (line_table, locus, block);
> -
>for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (&gsi))
>  {
>gimple stmt = gsi_stmt (gsi);
> -  if (same_line_p (locus, gimple_location (stmt)))
> - gimple_set_location (stmt, locus);
> +  location_t stmt_locus = gimple_location (stmt);
> +  if (same_line_p (locus, stmt_locus))
> + gimple_set_location (
> +stmt, location_with_discriminator (stmt_locus, discriminator));
>  }
>  }

Sorry, this may be right, but I'm not yet convinced. Check my reasoning here:

So we're back to same_line_p returns true if the two loci have the
same spelling point, right? We're looping through the gimple stmts in
the bb, looking for stmts that have the same spelling point, then
assigning a new locus using that discriminator. Since the
discriminator is associated with the spelling point, this won't be
using one discriminator for different lines, but you may need to
create a new locus in case the spelling point is the same but the
expansion point is different. But location_with_discriminator is going
to allocate a new locus unconditionally, so this will create a new
locus for each stmt in the bb, even if they have the same locus to
begin with. On large programs, I be afraid that this may exhaust the
available supply of location_t values.

How about saving the original locus and checking for straightforward
equality first? If the stmt's locus is equal to the starting one, then
just set it to the new locus; otherwise, check for same_line_p and
create a new locus if that returns true. Something like this
(untested):

 assign_discriminator (location_t locus, basic_block bb)
 {
   gimple_stmt_iterator gsi;
   int discriminator;
   location_t new_locus;

   locus = map_discriminator_location (locus);

   if (locus == UNKNOWN_LOCATION)
 return;

   discriminator = next_discriminator_for_locus (locus);
   new_locus = location_with_discriminator (locus, discriminator)

   for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (&gsi))
 {
   gimple stmt = gsi_stmt (gsi);
   location_t stmt_locus = gimple_location (stmt);

   if (locus == stmt_locus)
 gimple_set_location (stmt, new_locus);
   else if (same_line_p (locus, stmt_locus))
 gimple_set_location (
 stmt, location_with_discriminator (stmt_locus, discriminator));
 }
 }

This could still allocate lots of unnecessary new location_t values,
though (and may never use new_locus). Maybe the right thing to do
would be to have location_with_discriminator implement a rudimentary
cache to avoid handing out a new location_t value when a
recently-allocated one matches. (I don't think you even need a cache
-- it can just look back at the last few elements in
discriminator_location_locations and
discriminator_location_discriminators.)

-cary

RE: [patch] ICE with combination of -openmp and -femit-struct-debug-reduced/baseonly

[Evgeny Gavrin]

> Do you have a copyright assignment on file with FSF? 
Signed form was already received by the copyright clerk. So I hope I'll be able 
to commit by myself soon.

/*
With optimism,
Evgeny Gavrin
email : evgeny.gav...@hotmail.com
*/

> Date: Tue, 2 Jul 2013 13:54:14 -0700
> Subject: Re: [patch] ICE with combination of -openmp and 
> -femit-struct-debug-reduced/baseonly
> From: ccout...@google.com
> To: evgeny.gav...@hotmail.com
> CC: gcc-patches@gcc.gnu.org; slava.garbu...@gmail.com
>
>> I've find out that compiler may crash with SEGFAULT on some openmp-enabled 
>> code (attached as debug-1.c) called with the following flags:
>> -g -fopenmp -gdwarf-2 -femit-struct-debug-reduced
>> Also, can be reproduced with -femit-struct-debug-baseonly
>>
>> The problem is in dwarf2out.c:350:should_emit_struct_debug() at this line:
>> 366 type_decl = TYPE_STUB_DECL (TYPE_MAIN_VARIANT (type));
>>
>> In some cases type_decl can be NULL and this causes ICE in the following 
>> code:
>> 368 if (criterion == DINFO_STRUCT_FILE_SYS && DECL_IN_SYSTEM_HEADER 
>> (type_decl))
>> 369 return DUMP_GSTRUCT (type, usage, criterion, generic, false, true);
>> 370
>> 371 if (matches_main_base (DECL_SOURCE_FILE (type_decl)))
>> 372 return DUMP_GSTRUCT (type, usage, criterion, generic, true, true);
>>
>> Can be fixed with checking for type_decl is not NULL.
>>
>> I've attached patch to fix this. Could you check, is it ok?
>
> The patch looks OK to me.
>
> Do you have a copyright assignment on file with FSF? For a patch this
> size, I don't think you need one, but I'd appreciate confirmation from
> the more legally-inclined (Danny, Ian?). Do you need someone to commit
> it for you?
>
>> This is very straightforward fix, can the problem be in incorrect debug info 
>> generation on early stages?
>
> Sorry, I'm not sure what you're asking here.
>
> -cary   

Re: [patch] ICE with combination of -openmp and -femit-struct-debug-reduced/baseonly

[Cary Coutant]

>> Do you have a copyright assignment on file with FSF?
> Signed form was already received by the copyright clerk. So I hope I'll be 
> able to commit by myself soon.

Great! Before you commit, please prepare a ChangeLog entry and post it
for review.

-cary

Re: [Google] Fix discriminator assignment for stmts

[Dehao Chen]

On Wed, Jul 3, 2013 at 11:25 AM, Cary Coutant  wrote:
>
> > -  locus = location_with_discriminator (
> > -  locus, next_discriminator_for_locus (locus));
> > +  discriminator = next_discriminator_for_locus (locus);
> >
> > -  if (block != NULL)
> > -locus = COMBINE_LOCATION_DATA (line_table, locus, block);
> > -
> >for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (&gsi))
> >  {
> >gimple stmt = gsi_stmt (gsi);
> > -  if (same_line_p (locus, gimple_location (stmt)))
> > - gimple_set_location (stmt, locus);
> > +  location_t stmt_locus = gimple_location (stmt);
> > +  if (same_line_p (locus, stmt_locus))
> > + gimple_set_location (
> > +stmt, location_with_discriminator (stmt_locus, discriminator));
> >  }
> >  }
>
> Sorry, this may be right, but I'm not yet convinced. Check my reasoning here:
>
> So we're back to same_line_p returns true if the two loci have the
> same spelling point, right? We're looping through the gimple stmts in

We actually change to expand_location instead, patch updated.

> the bb, looking for stmts that have the same spelling point, then
> assigning a new locus using that discriminator. Since the
> discriminator is associated with the spelling point, this won't be
> using one discriminator for different lines, but you may need to
> create a new locus in case the spelling point is the same but the
> expansion point is different. But location_with_discriminator is going
> to allocate a new locus unconditionally, so this will create a new
> locus for each stmt in the bb, even if they have the same locus to
> begin with. On large programs, I be afraid that this may exhaust the
> available supply of location_t values.
>
> How about saving the original locus and checking for straightforward
> equality first? If the stmt's locus is equal to the starting one, then
> just set it to the new locus; otherwise, check for same_line_p and
> create a new locus if that returns true. Something like this
> (untested):
>
>  assign_discriminator (location_t locus, basic_block bb)
>  {
>gimple_stmt_iterator gsi;
>int discriminator;
>location_t new_locus;
>
>locus = map_discriminator_location (locus);
>
>if (locus == UNKNOWN_LOCATION)
>  return;
>
>discriminator = next_discriminator_for_locus (locus);
>new_locus = location_with_discriminator (locus, discriminator)
>
>for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (&gsi))
>  {
>gimple stmt = gsi_stmt (gsi);
>location_t stmt_locus = gimple_location (stmt);
>
>if (locus == stmt_locus)
>  gimple_set_location (stmt, new_locus);
>else if (same_line_p (locus, stmt_locus))
>  gimple_set_location (
>  stmt, location_with_discriminator (stmt_locus, discriminator));
>  }
>  }
>
> This could still allocate lots of unnecessary new location_t values,
> though (and may never use new_locus). Maybe the right thing to do
> would be to have location_with_discriminator implement a rudimentary
> cache to avoid handing out a new location_t value when a
> recently-allocated one matches. (I don't think you even need a cache
> -- it can just look back at the last few elements in
> discriminator_location_locations and
> discriminator_location_discriminators.)

You are right. I've updated the patch to do this. Testing on-going.

Index: gcc/input.c
===
--- gcc/input.c (revision 200643)
+++ gcc/input.c (working copy)
@@ -308,7 +308,8 @@ location_with_discriminator (location_t locus, int
 {
   tree block = LOCATION_BLOCK (locus);
   location_t ret;
-  locus = LOCATION_LOCUS (locus);
+  int i;
+  locus = map_discriminator_location (locus);

   if (locus == UNKNOWN_LOCATION)
 return block ? COMBINE_LOCATION_DATA (line_table, locus, block)
@@ -320,14 +321,23 @@ location_with_discriminator (location_t locus, int
   next_discriminator_location = min_discriminator_location;
 }

+  /* Traverse the last few discriminator_locations to see if we can reuse
+ the entry.  */
+  for (i = next_discriminator_location - min_discriminator_location - 1;
+   i >= 0 && LOCATION_LINE (discriminator_location_locations[i]) ==
+ LOCATION_LINE (locus) &&
+   discriminator_location_discriminators[i] == discriminator; i--)
+if (discriminator_location_locations[i] == locus)
+  return block ? next_discriminator_location - i :
+  COMBINE_LOCATION_DATA (line_table, next_discriminator_location - i,
+ block);
+
   discriminator_location_locations.safe_push(locus);
   discriminator_location_discriminators.safe_push(discriminator);

-  if (block != NULL)
-ret = COMBINE_LOCATION_DATA (line_table, next_discriminator_location,
- block);
-  else
-ret = next_discriminator_location;
+  ret = block ? next_discriminator_location :
+ COMBINE_LOCATION_DATA (line_table, next_discriminator_location,
+   block);
   next_discriminator_location++;
   return ret;
 }

Re: [PATCH] Fix up gather addressing in -m64 -fpic code (PR target/57777)

[Richard Henderson]

On 07/03/2013 07:20 AM, Jakub Jelinek wrote:
> 2013-07-02  Jakub Jelinek  
> 
>   PR target/5
>   * config/i386/predicates.md (vsib_address_operand): Disallow
>   SYMBOL_REF or LABEL_REF in parts.disp if TARGET_64BIT && flag_pic.
> 
>   * gcc.target/i386/pr5.c: New test.

Ok.


r~

Re: [Google] Fix discriminator assignment for stmts

[Dehao Chen]

Please ignore the original patch, which is wrong. New patch updated,
passed regression test.

Dehao

On Wed, Jul 3, 2013 at 1:00 PM, Dehao Chen  wrote:
> On Wed, Jul 3, 2013 at 11:25 AM, Cary Coutant  wrote:
>>
>> > -  locus = location_with_discriminator (
>> > -  locus, next_discriminator_for_locus (locus));
>> > +  discriminator = next_discriminator_for_locus (locus);
>> >
>> > -  if (block != NULL)
>> > -locus = COMBINE_LOCATION_DATA (line_table, locus, block);
>> > -
>> >for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (&gsi))
>> >  {
>> >gimple stmt = gsi_stmt (gsi);
>> > -  if (same_line_p (locus, gimple_location (stmt)))
>> > - gimple_set_location (stmt, locus);
>> > +  location_t stmt_locus = gimple_location (stmt);
>> > +  if (same_line_p (locus, stmt_locus))
>> > + gimple_set_location (
>> > +stmt, location_with_discriminator (stmt_locus, discriminator));
>> >  }
>> >  }
>>
>> Sorry, this may be right, but I'm not yet convinced. Check my reasoning here:
>>
>> So we're back to same_line_p returns true if the two loci have the
>> same spelling point, right? We're looping through the gimple stmts in
>
> We actually change to expand_location instead, patch updated.
>
>> the bb, looking for stmts that have the same spelling point, then
>> assigning a new locus using that discriminator. Since the
>> discriminator is associated with the spelling point, this won't be
>> using one discriminator for different lines, but you may need to
>> create a new locus in case the spelling point is the same but the
>> expansion point is different. But location_with_discriminator is going
>> to allocate a new locus unconditionally, so this will create a new
>> locus for each stmt in the bb, even if they have the same locus to
>> begin with. On large programs, I be afraid that this may exhaust the
>> available supply of location_t values.
>>
>> How about saving the original locus and checking for straightforward
>> equality first? If the stmt's locus is equal to the starting one, then
>> just set it to the new locus; otherwise, check for same_line_p and
>> create a new locus if that returns true. Something like this
>> (untested):
>>
>>  assign_discriminator (location_t locus, basic_block bb)
>>  {
>>gimple_stmt_iterator gsi;
>>int discriminator;
>>location_t new_locus;
>>
>>locus = map_discriminator_location (locus);
>>
>>if (locus == UNKNOWN_LOCATION)
>>  return;
>>
>>discriminator = next_discriminator_for_locus (locus);
>>new_locus = location_with_discriminator (locus, discriminator)
>>
>>for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (&gsi))
>>  {
>>gimple stmt = gsi_stmt (gsi);
>>location_t stmt_locus = gimple_location (stmt);
>>
>>if (locus == stmt_locus)
>>  gimple_set_location (stmt, new_locus);
>>else if (same_line_p (locus, stmt_locus))
>>  gimple_set_location (
>>  stmt, location_with_discriminator (stmt_locus, discriminator));
>>  }
>>  }
>>
>> This could still allocate lots of unnecessary new location_t values,
>> though (and may never use new_locus). Maybe the right thing to do
>> would be to have location_with_discriminator implement a rudimentary
>> cache to avoid handing out a new location_t value when a
>> recently-allocated one matches. (I don't think you even need a cache
>> -- it can just look back at the last few elements in
>> discriminator_location_locations and
>> discriminator_location_discriminators.)
>
> You are right. I've updated the patch to do this. Testing on-going.
>
> Index: gcc/input.c
> ===
> --- gcc/input.c (revision 200643)
> +++ gcc/input.c (working copy)
> @@ -308,7 +308,8 @@ location_with_discriminator (location_t locus, int
>  {
>tree block = LOCATION_BLOCK (locus);
>location_t ret;
> -  locus = LOCATION_LOCUS (locus);
> +  int i;
> +  locus = map_discriminator_location (locus);
>
>if (locus == UNKNOWN_LOCATION)
>  return block ? COMBINE_LOCATION_DATA (line_table, locus, block)
> @@ -320,14 +321,23 @@ location_with_discriminator (location_t locus, int
>next_discriminator_location = min_discriminator_location;
>  }
>
> +  /* Traverse the last few discriminator_locations to see if we can reuse
> + the entry.  */
> +  for (i = next_discriminator_location - min_discriminator_location - 1;
> +   i >= 0 && LOCATION_LINE (discriminator_location_locations[i]) ==
> + LOCATION_LINE (locus) &&
> +   discriminator_location_discriminators[i] == discriminator; i--)
> +if (discriminator_location_locations[i] == locus)
> +  return block ? next_discriminator_location - i :
> +  COMBINE_LOCATION_DATA (line_table, next_discriminator_location - i,
> + block);
> +
>discriminator_location_locations.safe_push(locus);
>discriminator_location_discriminators.safe_push(discriminator);
>
> -  if (block != NULL)
> -ret = 

[PING] Re: C++ 2014 status page for libstdc++

[Ed Smith-Rowland]

On 06/27/2013 11:24 PM, Ed Smith-Rowland wrote:

On 06/27/2013 07:01 AM, Jonathan Wakely wrote:

On 26 June 2013 02:28, Ed Smith-Rowland wrote:

On 06/25/2013 11:59 AM, Jonathan Wakely wrote:

On 25 June 2013 16:45, <3dw...@verizon.net> wrote:

Here is a C++2014 status page for fun and profit.

Excellent, thanks!


Tested with xmllint.  Are there any other tests I should do?

The makefile target to check the docbook manual is:
make doc-xml-validate-docbook

Checked clean.


It should also be linked from doc/xml/manual/intro.xml so it appears
as part of the manual.

Done.


The first paragraph says the table is based on the table of contents
of the CD, but it isn't.  I agree with only showing the C++14 changes,
but the first paragraph should be changed (or removed.)


Just removed this paragraph.

Applied.
That patch is definitely OK, but please wait for approval before 
applying!

Will do.  Sorry.


Thanks again for doing this - I'll try to find time to finish the WIP
stuff I'm W'ing on :)


Cool!

I should have waited because I thought it would be better to have 
links for the papers.


Also, how does one regenerate html?  Do you do that?

Finally, should we put a line for thins in the 4.9 changes page?



PING!  Is adding links to the C++2014 library page OK?

Re: [Google] Fix discriminator assignment for stmts

[Cary Coutant]

> Please ignore the original patch, which is wrong. New patch updated,
> passed regression test.

+  for (i = next_discriminator_location - min_discriminator_location - 1;
+   i >= 0 && LOCATION_LINE (discriminator_location_locations[i]) ==
+ LOCATION_LINE (locus) &&
+   discriminator_location_discriminators[i] == discriminator; i--)
+if (discriminator_location_locations[i] == locus)
+  return block ? COMBINE_LOCATION_DATA (
+  line_table, min_discriminator_location + i, block)
+  : min_discriminator_location + i;

As per GCC coding conventions, the long expressions need to be
parenthesized and indented under the parens, with operators at the
beginning of the line, like this:

+  for (i = next_discriminator_location - min_discriminator_location - 1;
+   (i >= 0
+&& (LOCATION_LINE (discriminator_location_locations[i])
+== LOCATION_LINE (locus))
+&& discriminator_location_discriminators[i] == discriminator);
+   i--)
+if (discriminator_location_locations[i] == locus)
+  return (block
+  ? COMBINE_LOCATION_DATA (line_table,
+   min_discriminator_location + i,
+   block)
+  : min_discriminator_location + i);

Same here:

+  ret = block ? COMBINE_LOCATION_DATA (
+   line_table, next_discriminator_location, block)
+   : next_discriminator_location;

Should be something like this:

+  ret = (block
+ ? COMBINE_LOCATION_DATA (line_table, next_discriminator_location,
+  block)
+ : next_discriminator_location);

(Although this last statement would probably read better as a regular
if statement.)

And here:

+  if (same_line_p (locus, stmt_locus))
+gimple_set_location (
+   stmt, location_with_discriminator (stmt_locus, discriminator));

Should be something like this:

+  if (same_line_p (locus, stmt_locus))
+gimple_set_location (stmt,
+ location_with_discriminator (stmt_locus,
+  discriminator));

Looks good with those changes. Thanks!

-cary

[C++ Patch] PR 38634 (Take 2)

[Paolo Carlini]

Hi,

today I was going through some pending issues, and decided to rework my 
first try at fixing this very old ICE on invalid:


http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00480.html

In the first try, bailing out early in case of error without undoing the 
committed changes to decl1 made me a little nervous. The below variant 
works at first on newdecl and only if push_template_decl goes well, 
copies it back to decl1. Still passes testing on x86_64-linux.


Thanks,
Paolo.

//
/cp
2013-07-04  Paolo Carlini  

PR c++/38634
* decl.c (start_preparsed_function): Return a bool, false if
push_template_decl fails.
(start_function): Adjust.
* cp-tree.h: Update.

/testsuite
2013-07-04  Paolo Carlini  

PR c++/38634
* g++.dg/template/crash116.C: New.
Index: cp/cp-tree.h
===
--- cp/cp-tree.h(revision 200645)
+++ cp/cp-tree.h(working copy)
@@ -5206,8 +5206,9 @@ extern void finish_enum_value_list(tree);
 extern void finish_enum(tree);
 extern void build_enumerator   (tree, tree, tree, location_t);
 extern tree lookup_enumerator  (tree, tree);
-extern void start_preparsed_function   (tree, tree, int);
-extern int start_function  (cp_decl_specifier_seq *, const 
cp_declarator *, tree);
+extern bool start_preparsed_function   (tree, tree, int);
+extern bool start_function (cp_decl_specifier_seq *,
+const cp_declarator *, tree);
 extern tree begin_function_body(void);
 extern void finish_function_body   (tree);
 extern tree outer_curly_brace_block(tree);
Index: cp/decl.c
===
--- cp/decl.c   (revision 200645)
+++ cp/decl.c   (working copy)
@@ -12993,9 +12993,10 @@ check_function_type (tree decl, tree current_funct
error_mark_node if the function has never been defined, or
a BLOCK if the function has been defined somewhere.  */
 
-void
+bool
 start_preparsed_function (tree decl1, tree attrs, int flags)
 {
+  tree newdecl = decl1;
   tree ctype = NULL_TREE;
   tree fntype;
   tree restype;
@@ -13003,22 +13004,22 @@ start_preparsed_function (tree decl1, tree attrs,
   cp_binding_level *bl;
   tree current_function_parms;
   struct c_fileinfo *finfo
-= get_fileinfo (LOCATION_FILE (DECL_SOURCE_LOCATION (decl1)));
+= get_fileinfo (LOCATION_FILE (DECL_SOURCE_LOCATION (newdecl)));
   bool honor_interface;
 
   /* Sanity check.  */
   gcc_assert (VOID_TYPE_P (TREE_VALUE (void_list_node)));
   gcc_assert (TREE_CHAIN (void_list_node) == NULL_TREE);
 
-  fntype = TREE_TYPE (decl1);
+  fntype = TREE_TYPE (newdecl);
   if (TREE_CODE (fntype) == METHOD_TYPE)
 ctype = TYPE_METHOD_BASETYPE (fntype);
 
   /* ISO C++ 11.4/5.  A friend function defined in a class is in
  the (lexical) scope of the class in which it is defined.  */
-  if (!ctype && DECL_FRIEND_P (decl1))
+  if (!ctype && DECL_FRIEND_P (newdecl))
 {
-  ctype = DECL_FRIEND_CONTEXT (decl1);
+  ctype = DECL_FRIEND_CONTEXT (newdecl);
 
   /* CTYPE could be null here if we're dealing with a template;
 for example, `inline friend float foo()' inside a template
@@ -13029,60 +13030,61 @@ start_preparsed_function (tree decl1, tree attrs,
doing_friend = 1;
 }
 
-  if (DECL_DECLARED_INLINE_P (decl1)
+  if (DECL_DECLARED_INLINE_P (newdecl)
   && lookup_attribute ("noinline", attrs))
-warning (0, "inline function %q+D given attribute noinline", decl1);
+warning (0, "inline function %q+D given attribute noinline", newdecl);
 
   /* Handle gnu_inline attribute.  */
-  if (GNU_INLINE_P (decl1))
+  if (GNU_INLINE_P (newdecl))
 {
-  DECL_EXTERNAL (decl1) = 1;
-  DECL_NOT_REALLY_EXTERN (decl1) = 0;
-  DECL_INTERFACE_KNOWN (decl1) = 1;
-  DECL_DISREGARD_INLINE_LIMITS (decl1) = 1;
+  DECL_EXTERNAL (newdecl) = 1;
+  DECL_NOT_REALLY_EXTERN (newdecl) = 0;
+  DECL_INTERFACE_KNOWN (newdecl) = 1;
+  DECL_DISREGARD_INLINE_LIMITS (newdecl) = 1;
 }
 
-  if (DECL_MAYBE_IN_CHARGE_CONSTRUCTOR_P (decl1))
+  if (DECL_MAYBE_IN_CHARGE_CONSTRUCTOR_P (newdecl))
 /* This is a constructor, we must ensure that any default args
introduced by this definition are propagated to the clones
now. The clones are used directly in overload resolution.  */
-adjust_clone_args (decl1);
+adjust_clone_args (newdecl);
 
   /* Sometimes we don't notice that a function is a static member, and
  build a METHOD_TYPE for it.  Fix that up now.  */
-  gcc_assert (!(ctype != NULL_TREE && DECL_STATIC_FUNCTION_P (decl1)
-   && TREE_CODE (TREE_TYPE (decl1)) == METHOD_TYPE));
+  gcc_assert (!(ctype != NULL_TREE && DECL_STATIC_FUNCTION_P (newd