Re: [Patch, Fortran] Minor coarray fix: Constraint check, wrong "restrict"

2011-05-26 Thread Daniel Kraft
On 05/27/11 08:10, Tobias Burnus wrote:
> Attached is a small coarray fix, solving two issues:
> 
> - For -fcoarray=single, nonallocatable coarrays are nonpointer - but
> currently they get set the "restrict" qualifier. (With -fcoarray=lib,
> nonallocatble coarrays are always pointers.)
>  Fixed by not setting "restricted" in this case.
> 
> - The pointer association status may not be checked/modified on remote
> images. And remote (de)allocate is also invalid. However, some of those
> constraint checks were missing
> 
> OK for the trunk?

Ok.   Thanks for the patch!

Daniel

-- 
http://www.pro-vegan.info/
--
Done:  Arc-Bar-Cav-Kni-Ran-Rog-Sam-Tou-Val-Wiz
To go: Hea-Mon-Pri


[Patch, Fortran] Minor coarray fix: Constraint check, wrong "restrict"

2011-05-26 Thread Tobias Burnus

Attached is a small coarray fix, solving two issues:

- For -fcoarray=single, nonallocatable coarrays are nonpointer - but 
currently they get set the "restrict" qualifier. (With -fcoarray=lib, 
nonallocatble coarrays are always pointers.)

 Fixed by not setting "restricted" in this case.

- The pointer association status may not be checked/modified on remote 
images. And remote (de)allocate is also invalid. However, some of those 
constraint checks were missing


OK for the trunk?

Tobias
2011-05-27  Tobias Burnus  

	PR fortran/18918
	* check.c (gfc_check_associated, gfc_check_null): Add coindexed check.
	* match.c (gfc_match_nullify): Ditto.
	* resolve.c (resolve_deallocate_expr): Ditto.
	* trans-types.c (gfc_get_nodesc_array_type): Don't set restricted
	for nonpointers.

2011-05-27  Tobias Burnus  

	PR fortran/18918
	* gfortran.dg/coarray_22.f90: New.

diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index 8641142..544253c 100644
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -875,6 +875,15 @@ gfc_check_associated (gfc_expr *pointer, gfc_expr *target)
   return FAILURE;
 }
 
+  /* F2008, C1242.  */
+  if (attr1.pointer && gfc_is_coindexed (pointer))
+{
+  gfc_error ("'%s' argument of '%s' intrinsic at %L shall not be "
+		 "conindexed", gfc_current_intrinsic_arg[0]->name,
+		 gfc_current_intrinsic, &pointer->where);
+  return FAILURE;
+}
+
   /* Target argument is optional.  */
   if (target == NULL)
 return SUCCESS;
@@ -902,6 +911,15 @@ gfc_check_associated (gfc_expr *pointer, gfc_expr *target)
   return FAILURE;
 }
 
+  /* F2008, C1242.  */
+  if (attr1.pointer && gfc_is_coindexed (target))
+{
+  gfc_error ("'%s' argument of '%s' intrinsic at %L shall not be "
+		 "conindexed", gfc_current_intrinsic_arg[1]->name,
+		 gfc_current_intrinsic, &target->where);
+  return FAILURE;
+}
+
   t = SUCCESS;
   if (same_type_check (pointer, 0, target, 1) == FAILURE)
 t = FAILURE;
@@ -2651,6 +2669,15 @@ gfc_check_null (gfc_expr *mold)
   return FAILURE;
 }
 
+  /* F2008, C1242.  */
+  if (gfc_is_coindexed (mold))
+{
+  gfc_error ("'%s' argument of '%s' intrinsic at %L shall not be "
+		 "conindexed", gfc_current_intrinsic_arg[0]->name,
+		 gfc_current_intrinsic, &mold->where);
+  return FAILURE;
+}
+
   return SUCCESS;
 }
 
diff --git a/gcc/fortran/trans-types.c b/gcc/fortran/trans-types.c
index 9c4f5f6..94b9a59 100644
--- a/gcc/fortran/trans-types.c
+++ b/gcc/fortran/trans-types.c
@@ -1543,13 +1543,12 @@ gfc_get_nodesc_array_type (tree etype, gfc_array_spec * as, gfc_packed packed,
   if (as->rank == 0)
 {
   if (packed != PACKED_STATIC  || gfc_option.coarray == GFC_FCOARRAY_LIB)
-	type = build_pointer_type (type);
+	{
+	  type = build_pointer_type (type);
 
-  if (restricted)
-type = build_qualified_type (type, TYPE_QUAL_RESTRICT);	
+	  if (restricted)
+	type = build_qualified_type (type, TYPE_QUAL_RESTRICT);	
 
-  if (packed != PACKED_STATIC  || gfc_option.coarray == GFC_FCOARRAY_LIB)
-	{
 	  GFC_ARRAY_TYPE_P (type) = 1;
 	  TYPE_LANG_SPECIFIC (type) = TYPE_LANG_SPECIFIC (TREE_TYPE (type)); 
 	}
diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
index 75f2a7f..f275239 100644
--- a/gcc/fortran/match.c
+++ b/gcc/fortran/match.c
@@ -3194,6 +3194,13 @@ gfc_match_nullify (void)
   if (gfc_check_do_variable (p->symtree))
 	goto cleanup;
 
+  /* F2008, C1242.  */
+  if (gfc_is_coindexed (p))
+	{
+	  gfc_error ("Pointer object at %C shall not be conindexed");
+	  goto cleanup;
+	}
+
   /* build ' => NULL() '.  */
   e = gfc_get_null_expr (&gfc_current_locus);
 
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 3483bc7..4b18529 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -6494,6 +6494,13 @@ resolve_deallocate_expr (gfc_expr *e)
   return FAILURE;
 }
 
+  /* F2008, C644.  */
+  if (gfc_is_coindexed (e))
+{
+  gfc_error ("Coindexed allocatable object at %L", &e->where);
+  return FAILURE;
+}
+
   if (pointer
   && gfc_check_vardef_context (e, true, _("DEALLOCATE object")) == FAILURE)
 return FAILURE;

--- /dev/null	2011-05-27 07:14:06.059892443 +0200
+++ gcc/gcc/testsuite/gfortran.dg/coarray_22.f90	2011-05-27 08:03:48.0 +0200
@@ -0,0 +1,33 @@
+! { dg-do compile }
+! { dg-options "-fcoarray=single" }
+!
+! Constraint checks for invalid access of remote pointers
+! (Accessing the value is ok, checking/changing association
+!  status is invalid)
+!
+! PR fortran/18918
+!
+type t
+  integer, pointer :: ptr => null()
+end type t
+type(t) :: x[*], y[*]
+
+if (associated(x%ptr)) stop 0
+if (associated(x%ptr,y%ptr)) stop 0
+
+if (associated(x[1]%ptr)) stop 0  ! { dg-error "shall not be conindexed" }
+if (associated(x%ptr,y[1]%ptr)) stop 0  ! { dg-error "shall not be conindexed" }
+
+nullify (x%ptr)
+nullify (x[1]%ptr)  ! { dg-error "shall not be conindexed" }
+
+x%ptr => null(x%ptr)
+x%ptr => null(x[1]%ptr)  

Re: [RFC] Context sensitive inline analysis

2011-05-26 Thread H.J. Lu
On Thu, May 26, 2011 at 9:53 PM, H.J. Lu  wrote:
> On Fri, Apr 22, 2011 at 5:35 AM, Jan Hubicka  wrote:
>> Hi,
>> this patch implements infrastructure to summarize function body size&time in 
>> a
>> way that is sensitive on function context.  At the moment context means
>>
>>  1) if function is inline or offline
>>  2) if some of parameters are known compile time constants.
>>
>> but we should handle more later.
>>
>> The analysis is implemented by introducing notion of predicates, that are
>> simple logical formulas in conjunctive-disjunctive form on conditions.
>> Conditions are simple tests like "function is not inlined" "op0 is not
>> constant" "op0 > 6". That is one can express things like "this statement will
>> execute if op1 >6 or op0 is not constant".
>>
>> The patch implements simple infrastructure to represent the predicates.  
>> There
>> are hard limits on everything - i.e. there are no more than 32 different
>> conditions and no more than 8 clauses.  This makes it possible to test 
>> clauses
>> by simple logicaloperations on integers and represent predicates at array of 
>> 8
>> integers thatis very cheap.  The implementation details are quite contained 
>> so
>> we might relax the limits, but I don't really see a need for that.
>>
>> The main point of designing this was to allow effective way of evaulating 
>> those
>> predicates for given context, since this happens many times during inlining,
>> and to not make WPA memory usage grow too much.  At the same time I wanted 
>> the
>> infrastructure to be flexible enough to allow adding more tricks in future.
>> Like we might consider extra inlining points if callee uses the argument to
>> drive number of iterations of loop or when caller pass a pointer to a static
>> variable that might be SRAed after inlining etc. etc.
>>
>> At the moment only consumer of predicates is size/time vector that is vector
>> of simple entries consiting of size, time and predicate.  Function size/time 
>> is then
>> computed as sum of all entries whose predicate might be true in given 
>> context +
>> size/time of all call edges (this is because call edges can disappear at 
>> different
>> conditions or be turned into constant).
>>
>> I plan to add more uses of predicates in near future - i.e. attaching
>> predicates to edges so we know what calls will be optimized out at WPA time.
>> Also I plan to use the analysis to drive function clonning (i.e. partial
>> specialization): when function is called from several places with the same
>> context and the context makes a difference at expected runtime, clone the
>> function.
>>
>> The analysis part deciding on predicates is currently very simple, kind of 
>> proof
>> of concept:
>>
>>  1) Every BB gets assigned predicate when it is reachable. At the moment it 
>> happens
>>    only if the all predecestors of BB are conditionals that tests function
>>    parameter.  Obviously we will need to propagate this info for sane 
>> results.
>>
>>  2) Every statement gets assigned predicate when it will become constant. 
>> Again
>>    it is very simple, only statements using only function arguments are 
>> considered.
>>    Simple propagation across SSA graph will do better.
>>
>>  3) Finally the statement is accounted at a predicate that is conjunction of 
>> both
>>    above.
>>  All call statements are accounted unconditoinally because we don't 
>> predicate edges, yet.
>>
>> While computing function sizes is fast, it is not as speedy as original
>> "time-benefit".  Small function inliner is quite insane about querying the
>> sizes/times again and again while it keeps up to date its queue. For this
>> purpose I added cache same way as we already cache function growths.  Not 
>> that
>> I would not plan to make inliner&badness more sensible here soon.
>> So far I did not want to touch the actual heuristics part of inliner and 
>> hope to do
>> it after getting the infrastructure to the point I want it to be for 4.7.
>>
>> The patch bootstraps®tests.  I tested that compile time implication on
>> tramp3d is positive (because of caching, without it inliner grows from 1.1% 
>> to
>> 4% of compile time) I also tested SPECs and there are not great changes, that
>> is not bad result given stupidity of the analysis ;).
>>
>> I will look into Mozilla even though I plan to look into solving scability
>> problems of the inliner as followup instead of snowballing this.
>>
>> I plan to work on the patch little further during weekend, in particular make
>> dumps more readable since they got bit convoluted by random formatting. But i
>> am sending the patch for comments and I plan to get it finished till next 
>> week.
>>
>> Honza
>>
>>        * gengtype.c (open_base_files): Add ipa-inline.h include.
>>        * ipa-cp.c (ipcp_get_lattice, ipcp_lattice_from_jfunc): Move to 
>> ipa-prop.c
>>        update all uses.
>>        * ipa-prop.c: (ipa_get_lattice, ipa_lattice_from_jfunc): ... here.
>>        * ipa-inline-transform.c (inline_call):

Re: [RFC] Context sensitive inline analysis

2011-05-26 Thread H.J. Lu
On Fri, Apr 22, 2011 at 5:35 AM, Jan Hubicka  wrote:
> Hi,
> this patch implements infrastructure to summarize function body size&time in a
> way that is sensitive on function context.  At the moment context means
>
>  1) if function is inline or offline
>  2) if some of parameters are known compile time constants.
>
> but we should handle more later.
>
> The analysis is implemented by introducing notion of predicates, that are
> simple logical formulas in conjunctive-disjunctive form on conditions.
> Conditions are simple tests like "function is not inlined" "op0 is not
> constant" "op0 > 6". That is one can express things like "this statement will
> execute if op1 >6 or op0 is not constant".
>
> The patch implements simple infrastructure to represent the predicates.  There
> are hard limits on everything - i.e. there are no more than 32 different
> conditions and no more than 8 clauses.  This makes it possible to test clauses
> by simple logicaloperations on integers and represent predicates at array of 8
> integers thatis very cheap.  The implementation details are quite contained so
> we might relax the limits, but I don't really see a need for that.
>
> The main point of designing this was to allow effective way of evaulating 
> those
> predicates for given context, since this happens many times during inlining,
> and to not make WPA memory usage grow too much.  At the same time I wanted the
> infrastructure to be flexible enough to allow adding more tricks in future.
> Like we might consider extra inlining points if callee uses the argument to
> drive number of iterations of loop or when caller pass a pointer to a static
> variable that might be SRAed after inlining etc. etc.
>
> At the moment only consumer of predicates is size/time vector that is vector
> of simple entries consiting of size, time and predicate.  Function size/time 
> is then
> computed as sum of all entries whose predicate might be true in given context 
> +
> size/time of all call edges (this is because call edges can disappear at 
> different
> conditions or be turned into constant).
>
> I plan to add more uses of predicates in near future - i.e. attaching
> predicates to edges so we know what calls will be optimized out at WPA time.
> Also I plan to use the analysis to drive function clonning (i.e. partial
> specialization): when function is called from several places with the same
> context and the context makes a difference at expected runtime, clone the
> function.
>
> The analysis part deciding on predicates is currently very simple, kind of 
> proof
> of concept:
>
>  1) Every BB gets assigned predicate when it is reachable. At the moment it 
> happens
>    only if the all predecestors of BB are conditionals that tests function
>    parameter.  Obviously we will need to propagate this info for sane results.
>
>  2) Every statement gets assigned predicate when it will become constant. 
> Again
>    it is very simple, only statements using only function arguments are 
> considered.
>    Simple propagation across SSA graph will do better.
>
>  3) Finally the statement is accounted at a predicate that is conjunction of 
> both
>    above.
>  All call statements are accounted unconditoinally because we don't predicate 
> edges, yet.
>
> While computing function sizes is fast, it is not as speedy as original
> "time-benefit".  Small function inliner is quite insane about querying the
> sizes/times again and again while it keeps up to date its queue. For this
> purpose I added cache same way as we already cache function growths.  Not that
> I would not plan to make inliner&badness more sensible here soon.
> So far I did not want to touch the actual heuristics part of inliner and hope 
> to do
> it after getting the infrastructure to the point I want it to be for 4.7.
>
> The patch bootstraps®tests.  I tested that compile time implication on
> tramp3d is positive (because of caching, without it inliner grows from 1.1% to
> 4% of compile time) I also tested SPECs and there are not great changes, that
> is not bad result given stupidity of the analysis ;).
>
> I will look into Mozilla even though I plan to look into solving scability
> problems of the inliner as followup instead of snowballing this.
>
> I plan to work on the patch little further during weekend, in particular make
> dumps more readable since they got bit convoluted by random formatting. But i
> am sending the patch for comments and I plan to get it finished till next 
> week.
>
> Honza
>
>        * gengtype.c (open_base_files): Add ipa-inline.h include.
>        * ipa-cp.c (ipcp_get_lattice, ipcp_lattice_from_jfunc): Move to 
> ipa-prop.c
>        update all uses.
>        * ipa-prop.c: (ipa_get_lattice, ipa_lattice_from_jfunc): ... here.
>        * ipa-inline-transform.c (inline_call): Use inline_merge_summary to 
> merge
>        summary of inlined function into former caller.
>        * ipa-inline.c (max_benefit): Remove.
>        (edge_badness): Compensate for rem

Re: [PATCH] PR debug/49047 (linkage name missing for cdtors)

2011-05-26 Thread Jason Merrill

On 05/26/2011 04:03 PM, Dodji Seketeli wrote:

That is what I first did and it worked for this case.  But then I wasn't
sure if there could be cases where a function DIE would have the
DW_AT_abstract_origin set, but won't have any actual code? For instance
if the function has DECL_EXTERNAL set.  That's why I wanted to call
add_linkage_name only if the function has DW_AT_{low,high}_pc so that I
am sure it contains actual code.


I think that we only generate debug info for a function if we emit it, 
so it should always have pc attributes.  But you could try adding an 
assert to see if I'm right.



+  if (TREE_PUBLIC (origin))
+   /*  So this is where the actual code for a publicly accessible
+   cloned function is.  Let's emit linkage name attribute for
+   it.  This helps debuggers to e.g, set breakpoints into
+   constructors/destructors when the user asks "break
+   K::K".  */
+   add_linkage_name (subr_die, decl);


add_name_and_src_coords_attributes doesn't check TREE_PUBLIC, so I don't 
think we should here, either; we want the debugger to be able to find 
cloned constructors in anonymous namespaces, too.


Jason


Re: [PATCH PING] unreviewed tree-slimming patches

2011-05-26 Thread Jason Merrill

On 05/26/2011 08:50 PM, Nathan Froyd wrote:

Sigh, I am an idiot.  It appears that we always have something pushed by
the time add_stmt is called.  (I ran into problems implementing the
above approach, as I wound up with [ NULL_TREE,  ] and that gave
pop_stmt heartburn.)  I can't recall why I added the check in the first
place; it might have been because I ran into problems in the C FE and
blindly assumed I needed the same fix in the C++ FE.


A reasonable assumption; I wonder why C is doing things differently.

The patch is OK, but could you look into that inconsistency?

Jason


C++ PATCH for c++/47956 (missing diagnostic for non-const static)

2011-05-26 Thread Jason Merrill

struct A { static auto i = 42; };

is ill-formed because i is non-const, but we weren't noticing that 
because we were checking it before replacing the auto.  Fixed by moving 
the check into cp_finish_decl.


It also seems we were incorrectly setting DECL_INITIALIZED_IN_CLASS for 
some template static data members; I had to fix that to avoid testsuite 
regressions.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit 5719ff482f5048956429380ed6938e88c56d0962
Author: Jason Merrill 
Date:   Thu May 26 14:44:27 2011 -0400

	PR c++/47956
	* decl.c (check_static_variable_definition): Now static.
	(cp_finish_decl): Call it here.
	(grokdeclarator): Not here.
	* pt.c (instantiate_class_template_1): Or here.
	* cp-tree.h: Don't declare it.

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index ada01fb..a01253e 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -4895,7 +4895,6 @@ extern void finish_stmt(void);
 extern tree static_fn_type			(tree);
 extern void revert_static_member_fn		(tree);
 extern void fixup_anonymous_aggr		(tree);
-extern int check_static_variable_definition	(tree, tree);
 extern tree compute_array_index_type		(tree, tree, tsubst_flags_t);
 extern tree check_default_argument		(tree, tree);
 typedef int (*walk_namespaces_fn)		(tree, void *);
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index a956dbb..a524880 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -74,6 +74,7 @@ static void push_local_name (tree);
 static tree grok_reference_init (tree, tree, tree, tree *);
 static tree grokvardecl (tree, tree, const cp_decl_specifier_seq *,
 			 int, int, tree);
+static int check_static_variable_definition (tree, tree);
 static void record_unknown_type (tree, const char *);
 static tree builtin_function_1 (tree, tree, bool);
 static tree build_library_fn_1 (tree, enum tree_code, tree);
@@ -5909,6 +5910,7 @@ cp_finish_decl (tree decl, tree init, bool init_const_expr_p,
   if (current_class_type
   && CP_DECL_CONTEXT (decl) == current_class_type
   && TYPE_BEING_DEFINED (current_class_type)
+  && !CLASSTYPE_TEMPLATE_INSTANTIATION (current_class_type)
   && (DECL_INITIAL (decl) || init))
 DECL_INITIALIZED_IN_CLASS_P (decl) = 1;
 
@@ -5939,6 +5941,11 @@ cp_finish_decl (tree decl, tree init, bool init_const_expr_p,
   if (!ensure_literal_type_for_constexpr_object (decl))
 DECL_DECLARED_CONSTEXPR_P (decl) = 0;
 
+  if (TREE_CODE (decl) == VAR_DECL
+  && DECL_CLASS_SCOPE_P (decl)
+  && DECL_INITIALIZED_IN_CLASS_P (decl))
+check_static_variable_definition (decl, type);
+
   if (init && TREE_CODE (decl) == FUNCTION_DECL)
 {
   tree clone;
@@ -7640,9 +7647,12 @@ build_ptrmem_type (tree class_type, tree member_type)
messages.  Return 1 if the definition is particularly bad, or 0
otherwise.  */
 
-int
+static int
 check_static_variable_definition (tree decl, tree type)
 {
+  /* Can't check yet if we don't know the type.  */
+  if (dependent_type_p (type))
+return 0;
   /* If DECL is declared constexpr, we'll do the appropriate checks
  in check_initializer.  */
   if (DECL_P (decl) && DECL_DECLARED_CONSTEXPR_P (decl))
@@ -10025,21 +10035,6 @@ grokdeclarator (const cp_declarator *declarator,
 			staticp = 1;
 		  }
 		  }
-
-		if (uses_template_parms (type))
-		  /* We'll check at instantiation time.  */
-		  ;
-		else if (constexpr_p)
-		  /* constexpr has the same requirements.  */
-		  ;
-		else if (check_static_variable_definition (unqualified_id,
-			   type))
-		  /* If we just return the declaration, crashes
-		 will sometimes occur.  We therefore return
-		 void_type_node, as if this was a friend
-		 declaration, to cause callers to completely
-		 ignore this declaration.  */
-		  return error_mark_node;
 	  }
 
 	if (staticp)
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index ab48c8f..3b26700 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -8414,8 +8414,6 @@ instantiate_class_template_1 (tree type)
 			 /*init_const_expr_p=*/false,
 			 /*asmspec_tree=*/NULL_TREE,
 			 /*flags=*/0);
-		  if (DECL_INITIALIZED_IN_CLASS_P (r))
-			check_static_variable_definition (r, TREE_TYPE (r));
 		}
 		  else if (TREE_CODE (r) == FIELD_DECL)
 		{
diff --git a/gcc/testsuite/g++.dg/cpp0x/auto7.C b/gcc/testsuite/g++.dg/cpp0x/auto7.C
index 9ef5a80..e7ab723 100644
--- a/gcc/testsuite/g++.dg/cpp0x/auto7.C
+++ b/gcc/testsuite/g++.dg/cpp0x/auto7.C
@@ -7,7 +7,7 @@ auto j;			// { dg-error "has no initializer" }
 
 template struct A
 {
-  static auto k = 7;
+  static auto k = 7;	// { dg-error "non-const" }
   static auto l;	// { dg-error "has no initializer" }
   auto m;		// { dg-error "has no initializer" }
 };
diff --git a/gcc/testsuite/g++.dg/template/crash50.C b/gcc/testsuite/g++.dg/template/crash50.C
index 0060561..286685a 100644
--- a/gcc/testsuite/g++.dg/template/crash50.C
+++ b/gcc/testsuite/g++.dg/template/crash50.C
@@ -3,5 +3,5 @@
 
 struct A
 {
-  template void* foo(; // { dg-error "primary-e

Re: C++ PATCH for c++/47721 (N1791, friend T)

2011-05-26 Thread Jason Merrill
And as a prerequisite for that testcase, I needed to implement DR 1004, 
dropping the pedwarn about using an injected class name as a template 
template parameter.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit 0407c6ff58d0e7033de64040ce66d60a85b709e5
Author: Jason Merrill 
Date:   Thu May 26 15:00:08 2011 -0400

	DR 1004
	* pt.c (convert_template_argument): Don't complain about using
	injected-class-name as template template argument.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 3b26700..28c82b8 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -5962,7 +5962,9 @@ convert_template_argument (tree parm,
   tree t = maybe_get_template_decl_from_type_decl (TYPE_NAME (arg));
   if (TREE_CODE (t) == TEMPLATE_DECL)
 	{
-	  if (complain & tf_warning_or_error)
+	  if (cxx_dialect >= cxx0x)
+	/* OK under DR 1004.  */;
+	  else if (complain & tf_warning_or_error)
 	pedwarn (input_location, OPT_pedantic, "injected-class-name %qD"
 		 " used as template template argument", TYPE_NAME (arg));
 	  else if (flag_pedantic_errors)


C++ PATCH for c++/47721 (N1791, friend T)

2011-05-26 Thread Jason Merrill
The C++0x draft has allowed "friend T;" to make a template type 
parameter a friend since 2005; we've been getting a few bug reports 
about not having implemented it yet, so here it is.


I notice that friend template template parameters also seem to work now, 
with the syntax


  template  friend class W;

though it's not clear that's valid syntax.

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

commit 89758cb5378bbf92d1f9f72ed5161fd3f89118a8
Author: Jason Merrill 
Date:   Thu May 26 16:31:45 2011 -0400

	PR c++/47721
	* parser.c (cp_parser_member_declaration): Allow friend T.
	* friend.c (make_friend_class): Ignore non-classes.
	* pt.c (instantiate_class_template_1): Handle TEMPLATE_TYPE_PARM.

diff --git a/gcc/cp/friend.c b/gcc/cp/friend.c
index b61611a..36fcca4 100644
--- a/gcc/cp/friend.c
+++ b/gcc/cp/friend.c
@@ -226,7 +226,14 @@ make_friend_class (tree type, tree friend_type, bool complain)
 
   if (! MAYBE_CLASS_TYPE_P (friend_type))
 {
-  error ("invalid type %qT declared %", friend_type);
+  /* N1791: If the type specifier in a friend declaration designates a
+	 (possibly cv-qualified) class type, that class is declared as a
+	 friend; otherwise, the friend declaration is ignored.
+
+ So don't complain in C++0x mode.  */
+  if (cxx_dialect < cxx0x)
+	pedwarn (input_location, complain ? 0 : OPT_pedantic,
+		 "invalid type %qT declared %", friend_type);
   return;
 }
 
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 004ff05..135ab14 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -17758,9 +17758,10 @@ cp_parser_member_declaration (cp_parser* parser)
 	{
 	  /* If the `friend' keyword was present, the friend must
 		 be introduced with a class-key.  */
-	   if (!declares_class_or_enum)
-		 error_at (decl_spec_token_start->location,
-			   "a class-key must be used when declaring a friend");
+	   if (!declares_class_or_enum && cxx_dialect < cxx0x)
+		 pedwarn (decl_spec_token_start->location, OPT_pedantic,
+			  "in C++03 a class-key must be used "
+			  "when declaring a friend");
 	   /* In this case:
 
 		template  struct A {
@@ -17769,10 +17770,12 @@ cp_parser_member_declaration (cp_parser* parser)
 
 		  A::B will be represented by a TYPENAME_TYPE, and
 		  therefore not recognized by check_tag_decl.  */
-	   if (!type
-		   && decl_specifiers.type
-		   && TYPE_P (decl_specifiers.type))
-		 type = decl_specifiers.type;
+	   if (!type)
+		 {
+		   type = decl_specifiers.type;
+		   if (type && TREE_CODE (type) == TYPE_DECL)
+		 type = TREE_TYPE (type);
+		 }
 	   if (!type || !TYPE_P (type))
 		 error_at (decl_spec_token_start->location,
 			   "friend declaration does not name a class or "
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 28c82b8..767c4f6 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -8472,7 +8472,8 @@ instantiate_class_template_1 (tree type)
 		friend_type = TREE_TYPE (friend_type);
 		  adjust_processing_template_decl = true;
 		}
-	  else if (TREE_CODE (friend_type) == TYPENAME_TYPE)
+	  else if (TREE_CODE (friend_type) == TYPENAME_TYPE
+		   || TREE_CODE (friend_type) == TEMPLATE_TYPE_PARM)
 		{
 		  /* This could be either
 
diff --git a/gcc/testsuite/g++.dg/cpp0x/friend1.C b/gcc/testsuite/g++.dg/cpp0x/friend1.C
new file mode 100644
index 000..2cf4c3c
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/friend1.C
@@ -0,0 +1,22 @@
+// From N1791
+// { dg-options -std=c++0x }
+
+class C;
+typedef C Ct;
+class X1 {
+  friend C;		// OK: class C is a friend
+};
+
+class X2
+{
+  friend Ct;		// OK: class C is a friend
+  friend D;		// { dg-error "" } no type-name D in scope
+  friend class D;	// OK: elaborated-type-specifier declares new class
+};
+
+template  class R {
+  friend T;
+};
+
+R rc;		// class C is a friend of R
+R Ri;		// OK: "friend int;" is ignored
diff --git a/gcc/testsuite/g++.dg/cpp0x/friend2.C b/gcc/testsuite/g++.dg/cpp0x/friend2.C
new file mode 100644
index 000..39276a0
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/friend2.C
@@ -0,0 +1,40 @@
+// PR c++/47721
+// { dg-options -std=c++0x }
+
+// template type parameter friend:
+
+template
+class Q
+{
+  static const int I = 2;
+public:
+  friend W;
+};
+
+struct B
+{
+  int ar[Q::I];
+};
+
+// bonus template template parameter friend:
+
+template  struct A;
+
+template class W>
+class P
+{
+  static const int I = 2;
+public:
+  // I'm not sure this is well-formed, but I can't find anything
+  // that says otherwise.
+  template  friend class W;
+};
+
+template 
+struct A
+{
+  int ar[P::I];
+};
+
+A a;
+


Re: [C++ Patch] PR 42056

2011-05-26 Thread Jason Merrill

On 05/26/2011 02:30 PM, Paolo Carlini wrote:

We want to do that only when processing a template, because otherwise we
get a duplicate diagnostic, see, eg, auto9.C


Hmm, where's the error coming from in the non-template case?  From 
cp_build_c_cast?  In that case always giving the error in 
build_functional_cast and then returning error_mark_node should avoid 
duplication.



error_mark_node unconditionally, means a better diagnostic, without
redundant "array bound is not an integer constant before...".


I'd rather deal with that by suppressing that error if we already have 
error_mark_node.


Jason


Re: Prefixes for libgcc symbols (C6X 9.5/11)

2011-05-26 Thread Jack Howarth
On Thu, May 26, 2011 at 12:04:43PM +, Bernd Schmidt wrote:
> It occurred to me to do another test, building libgcc with and without
> the patch and comparing the binaries. That showed a problem - if there
> are multiple version files, their order matters. In all cases where
> $$(libgcc_objdir)/libgcc-std.ver occurs, it occurs first, so I've
> changed the order in srcdirify to match. I also need to properly svn rm
> the old libgcc-std.ver file.
> 
> Will check this in today after a bootstrap unless there are objections.
> 

This patch breaks the bootstrap on all darwin targets...

http://gcc.gnu.org/regtest/HEAD/native-lastbuild.txt.gzip

make[3]: *** No rule to make target 
`/Users/regress/tbox/svn-gcc/libgcc/../gcc/libgcc-std.ver', needed by 
`libgcc.map'.  Stop.
make[3]: *** Waiting for unfinished jobs

> 
> Bernd

> Index: gcc/ChangeLog
> ===
> --- gcc/ChangeLog (revision 174276)
> +++ gcc/ChangeLog (working copy)
> @@ -1,3 +1,9 @@
> +2011-05-26  Bernd Schmidt  
> +
> + * Makefile.in (srcdirify): Change order so that libgcc_objdir is
> + substituted first.
> + * libgcc-std.ver: Delete file.
> +
>  2011-05-26  Jakub Jelinek  
>  
>   PR c++/49165
> Index: gcc/Makefile.in
> ===
> --- gcc/Makefile.in   (revision 174276)
> +++ gcc/Makefile.in   (working copy)
> @@ -1894,13 +1894,15 @@ cc1$(exeext): $(C_OBJS) cc1-checksum.o $
>  LIB2ADD = $(LIB2FUNCS_EXTRA)
>  LIB2ADD_ST = $(LIB2FUNCS_STATIC_EXTRA)
>  
> -# All source files for libgcc are either in the source directory (in
> -# which case they will start with $(srcdir)), or generated into the build
> -# directory (in which case they will be relative paths).
> -srcdirify = $(patsubst $(srcdir)%,$$(gcc_srcdir)%,$(filter $(srcdir)%,$(1))) 
> \
> -$(patsubst $$(libgcc_objdir)/%,%, \
> +# All source files for libgcc are either generated in the libgcc build
> +# directory which will be substituted for $$(libgcc_objdir), in the
> +# source directory (in which case they will start with $(srcdir)), or
> +# generated into the build directory (in which case they will be
> +# relative paths).
> +srcdirify = $(patsubst $$(libgcc_objdir)/%,%, \
>   $(filter $$(libgcc_objdir)%,$(1))) \
> -$(patsubst %,$$(gcc_objdir)/%, \
> + $(patsubst $(srcdir)%,$$(gcc_srcdir)%,$(filter $(srcdir)%,$(1))) \
> + $(patsubst %,$$(gcc_objdir)/%, \
>   $(filter-out $(srcdir)% $$(libgcc_objdir)%,$(1)))
>  
>  # The distinction between these two variables is no longer relevant,



Re: [pph] More C++ Tree Nodes (issue4526083)

2011-05-26 Thread Nathan Froyd
On 05/26/2011 10:24 PM, Lawrence Crowl wrote:
> Index: gcc/cp/cp-objcp-common.c
> ===
> --- gcc/cp/cp-objcp-common.c  (revision 174301)
> +++ gcc/cp/cp-objcp-common.c  (working copy)
> @@ -99,6 +99,8 @@ cp_tree_size (enum tree_code code)
>  
>  case TEMPLATE_INFO: return sizeof (struct tree_template_info);
>  
> +case TREE_BINFO:return sizeof (struct tree_binfo);
> +
>  default:
>gcc_unreachable ();
>  }

This does not look right; TREE_BINFO is a variable-sized structure (and is not
C++-specific in any event).  Maybe you should be using tree_size instead of
tree_code_size someplace?

-Nathan


[pph] More C++ Tree Nodes (issue4526083)

2011-05-26 Thread Lawrence Crowl
Oranize the PPH tree switch into tcc_* chunks, in each of four sections:
needs more work, already handled, unimplemented, and unrecognized.

Implement several C++ tree nodes.  These nodes do not get any more tests
to pass, but they do move the failures deeper into the compilation.

Index: gcc/cp/ChangeLog.pph

2011-05-26  Lawrence Crowl  

* cp-objcp-common.c (cp_tree_size): Add case TREE_BINFO.
* pph.c (pph_read_file): Also log closing of PPH files.
* pph-streamer-in.c (pph_stream_read_tree):
Organize the switch into tcc_* chunks.
Move tcc_statement case STATEMENT_LIST down.
Implement tcc_type cases for BOUND_TEMPLATE_TEMPLATE_PARM,
DECLTYPE_TYPE, TEMPLATE_TEMPLATE_PARM, TEMPLATE_TYPE_PARM,
TYPENAME_TYPE, and TYPEOF_TYPE.
Implement tcc_exceptional case TEMPLATE_PARM_INDEX.
Add tcc_declaration case TRANSLATION_UNIT_DECL to already handled list.
Create a section for unimplemented cases as opposed to unrecognized
cases.
* pph-streamer-out.c (pph_stream_write_tree):
Organize the switch into tcc_* chunks.
Move tcc_statement case STATEMENT_LIST down.
Implement tcc_type cases for BOUND_TEMPLATE_TEMPLATE_PARM,
DECLTYPE_TYPE, TEMPLATE_TEMPLATE_PARM, TEMPLATE_TYPE_PARM,
TYPENAME_TYPE, and TYPEOF_TYPE.
Move tcc_statement case STATEMENT_LIST down.
Implement tcc_exceptional case TEMPLATE_PARM_INDEX.
Add tcc_declaration case TRANSLATION_UNIT_DECL to already handled list.
Create a section for unimplemented cases as opposed to unrecognized
cases.


Index: gcc/cp/pph.c
===
--- gcc/cp/pph.c(revision 174301)
+++ gcc/cp/pph.c(working copy)
@@ -2072,6 +2072,9 @@ pph_read_file (const char *filename)
 {
   pph_read_file_contents (stream);
   pph_stream_close (stream);
+
+  if (flag_pph_debug >= 1)
+fprintf (pph_logfile, "PPH: Closing %s\n", filename);
 }
   else
 error ("Cannot open PPH file for reading: %s: %m", filename);
Index: gcc/cp/pph-streamer-in.c
===
--- gcc/cp/pph-streamer-in.c(revision 174304)
+++ gcc/cp/pph-streamer-in.c(working copy)
@@ -807,6 +807,10 @@ pph_stream_read_tree (struct lto_input_b
 
   switch (TREE_CODE (expr))
 {
+/* TREES NEEDING EXTRA WORK */
+
+/* tcc_declaration */
+
 case DEBUG_EXPR_DECL:
 case IMPORTED_DECL:
 case LABEL_DECL:
@@ -845,16 +849,7 @@ pph_stream_read_tree (struct lto_input_b
   DECL_CONTEXT (expr) = pph_input_tree (stream);
   break;
 
-case STATEMENT_LIST:
-  {
-HOST_WIDE_INT i, num_trees = pph_input_uint (stream);
-for (i = 0; i < num_trees; i++)
- {
-   tree stmt = pph_input_tree (stream);
-   append_to_statement_list (stmt, &expr);
- }
-  }
-  break;
+/* tcc_type */
 
 case ARRAY_TYPE:
 case BOOLEAN_TYPE:
@@ -882,6 +877,43 @@ pph_stream_read_tree (struct lto_input_b
   TYPE_BINFO (expr) = pph_input_tree (stream);
   break;
 
+case BOUND_TEMPLATE_TEMPLATE_PARM:
+case DECLTYPE_TYPE:
+case TEMPLATE_TEMPLATE_PARM:
+case TEMPLATE_TYPE_PARM:
+case TYPENAME_TYPE:
+case TYPEOF_TYPE:
+  pph_stream_read_lang_type (stream, expr);
+  TYPE_CACHED_VALUES (expr) = pph_input_tree (stream);
+  /* Note that we are using TYPED_CACHED_VALUES for it access to 
+ the generic .values field of types. */
+  break;
+
+/* tcc_statement */
+
+case STATEMENT_LIST:
+  {
+HOST_WIDE_INT i, num_trees = pph_input_uint (stream);
+for (i = 0; i < num_trees; i++)
+ {
+   tree stmt = pph_input_tree (stream);
+   append_to_statement_list (stmt, &expr);
+ }
+  }
+  break;
+
+/* tcc_expression */
+
+/* tcc_unary */
+
+/* tcc_vl_exp */
+
+/* tcc_reference */
+
+/* tcc_constant */
+
+/* tcc_exceptional */
+
 case OVERLOAD:
   OVL_FUNCTION (expr) = pph_input_tree (stream);
   break;
@@ -907,11 +939,127 @@ pph_stream_read_tree (struct lto_input_b
   = pph_stream_read_qual_use_vec (stream);
   break;
 
-case TREE_LIST:
+case TEMPLATE_PARM_INDEX:
+  {
+template_parm_index *p = TEMPLATE_PARM_INDEX_CAST (expr);
+p->index = pph_input_uint (stream);
+p->level = pph_input_uint (stream);
+p->orig_level = pph_input_uint (stream);
+p->num_siblings = pph_input_uint (stream);
+p->decl = pph_input_tree (stream);
+/* FIXME pph: Is TEMPLATE_PARM_PARAMETER_PACK using TREE_LANG_FLAG_0
+   already handled?  */
+  }
+  break;
+
+/* TREES ALREADY HANDLED */
+
+/* tcc_declaration */
+
+case TRANSLATION_UNIT_DECL:
+
+/* tcc_exceptional */
+
 case TREE_BINFO:
-  /* These trees are already fully handled. 

Re: [PATCH PING] unreviewed tree-slimming patches

2011-05-26 Thread Nathan Froyd
On Thu, May 26, 2011 at 09:39:30AM -0400, Jason Merrill wrote:
> On 05/25/2011 10:21 PM, Nathan Froyd wrote:
> >An alternative solution would be to initialize cur_stmt_list somewhere with 
> >an
> >actual 1-element VEC;
> 
> Or just push NULL onto the stack and let append_to_statement_list_1
> allocate the VEC?
> 
> >the check in add_stmt would then be unnecessary, as we'd
> >always be assured of having someplace in the stack to store it.  I don't 
> >trust
> >myself to write a patch like that tonight; I'll twiddle with that tomorrow.
> 
> Right, that's what I was thinking about.  I think we should only
> need to do this once per function.

Sigh, I am an idiot.  It appears that we always have something pushed by
the time add_stmt is called.  (I ran into problems implementing the
above approach, as I wound up with [ NULL_TREE,  ] and that gave
pop_stmt heartburn.)  I can't recall why I added the check in the first
place; it might have been because I ran into problems in the C FE and
blindly assumed I needed the same fix in the C++ FE.

Below is a revised patch with the dubious code taken out of add_stmt and
an assert added.  Bootstrap/testing in progress on
x86_64-unknown-linux-gnu, but we've built libstdc++ a couple of times,
so I don't anticipate any surprises.  OK to commit?

-Nathan

gcc/
* c-decl.c (c_push_function_context): Copy the current statement
list stack.
(add_stmt): Check building_stmt_list_p and push_stmt if necessary.
(finish_struct): Call building_stmt_list_p instead of checking
cur_stmt_list.
* c-parser.c (c_parser_postfix_expression): Likewise.
* c-typeck.c (c_end_compound_stmt): Likewise.
* print-tree.c (print_node) [STATEMENT_LIST]: Don't print TREE_CHAIN.
* tree-iterator.c (stmt_list_cache): Change to a VEC.
(alloc_stmt_list): Adjust for stmt_list_cache's new type.
(free_stmt_list): Likewise.
* tree.h (struct tree_statement_list): Include typed_tree instead
of tree_common.
* tree.c (initialize_tree_contains_struct): Mark TS_STATEMENT_LIST
as TS_TYPED instead of TS_COMMON.

gcc/c-family/
* c-common.h (struct stmt_tree_s) [x_cur_stmt_list]: Change to a VEC.
(stmt_list_stack): Define.
(cur_stmt_list): Adjust for new type of x_cur_stmt_list.
* c-semantics.c (push_stmt_list, pop_stmt_list): Likewise.

gcc/cp/
* cp-tree.h (building_stmt_tree): Delete.
* decl.c (save_function_data): Tweak initializer for x_cur_stmt_list.
(build_aggr_init_full_exprs): Call building_stmt_list_p
instead of building_stmt_tree.
(initialize_local_var): Likewise.
(finish_function): Likewise.
* decl2.c (finish_anon_union): Likewise.
* init.c (begin_init_stmts): Likewise.
(finish_init_stmts): Likewise.
(expand_aggr_init_1): Likewise.
* name-lookup.c (do_local_using_decl): Likewise.
(do_namespace_alias): Likewise.
(do_using_directive): Likewise.
(cp_emit_debug_info_for_using): Likewise.
* semantics.c (add_stmt): Assert that stmt_list_stack is non-empty.

diff --git a/gcc/c-decl.c b/gcc/c-decl.c
index a7cc965..1d43126 100644
--- a/gcc/c-decl.c
+++ b/gcc/c-decl.c
@@ -552,6 +552,8 @@ add_stmt (tree t)
 
   /* Add T to the statement-tree.  Non-side-effect statements need to be
  recorded during statement expressions.  */
+  if (!building_stmt_list_p ())
+push_stmt_list ();
   append_to_statement_list_force (t, &cur_stmt_list);
 
   return t;
@@ -7188,7 +7190,7 @@ finish_struct (location_t loc, tree t, tree fieldlist, 
tree attributes,
   /* If we're inside a function proper, i.e. not file-scope and not still
  parsing parameters, then arrange for the size of a variable sized type
  to be bound now.  */
-  if (cur_stmt_list && variably_modified_type_p (t, NULL_TREE))
+  if (building_stmt_list_p () && variably_modified_type_p (t, NULL_TREE))
 add_stmt (build_stmt (loc,
  DECL_EXPR, build_decl (loc, TYPE_DECL, NULL, t)));
 
@@ -8424,6 +8426,8 @@ c_push_function_context (void)
   cfun->language = p;
 
   p->base.x_stmt_tree = c_stmt_tree;
+  c_stmt_tree.x_cur_stmt_list
+= VEC_copy (tree, gc, c_stmt_tree.x_cur_stmt_list);
   p->x_break_label = c_break_label;
   p->x_cont_label = c_cont_label;
   p->x_switch_stack = c_switch_stack;
diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
index 65f8ad1..1b658b1 100644
--- a/gcc/c-family/c-common.h
+++ b/gcc/c-family/c-common.h
@@ -452,8 +452,8 @@ typedef enum ref_operator {
 /* Information about a statement tree.  */
 
 struct GTY(()) stmt_tree_s {
-  /* The current statement list being collected.  */
-  tree x_cur_stmt_list;
+  /* A stack of statement lists being collected.  */
+  VEC(tree,gc) *x_cur_stmt_list;
 
   /* In C++, Nonzero if we should treat statements as full
  expressions.  In particular, this variable is no-zero if at the
@@ -483,11 +483,17

Re: [ARM] TLS Descriptor support

2011-05-26 Thread Ramana Radhakrishnan

Thanks for this and sorry about the length of time in reviewing this .

On 10/05/11 07:49, Nathan Sidwell wrote:

This patch implements TLS descriptor support in GCC. TLS descriptors are
described at
http://www.codesourcery.com/publications/RFC-TLSDESC-ARM.txt and blessed
by ARM, who have reserved the relocation numbers.

Binutils and GLIBC patches are already committed (there is an orthogonal
glibc patch to do with make dependencies that I need to post though).

This patch adds a --with-tls={arm|gnu} configuration option, to specify
the default scheme. It can be overridden with a -mtls-dialect={arm|gnu}
option (this is the name used by the x86 backend, which also has
tlsdescriptor support). I have not added --with-tls support to the x86
bits of config.gcc etc, but it would be simple to do so.


Could you consider adding a check in the configury to test if a binutils 
version of recent vintage is being used when --with-tls=gnu is in ?


Could you also use R0_REGNUM, R1_REGNUM instead of 0 and 1 in the 
"tlscall" pattern ?





This patch has been tested for both default arm and default gnu tls
schemes using the gcc and glibc testsuites for an arm-linux-gnueabi target.


Presumably for v7-a and v5te and with this as default ? On hardware ?


cheers
Ramana




Re: [google] Disable getpagesize() for Android toolchain (issue4515131)

2011-05-26 Thread Andrew Pinski
On Thu, May 26, 2011 at 4:47 PM, Jing Yu  wrote:
> I have tested the following patch to skip building target libiberty
> for arm*-*-linux-androideabi. It works as intended when building
> Android arm-linux-androideabi toolchain.
>
> Doug, do we want to skip building libiberty for non arm android
> toolchain, say *-linux-android*?
>
> Joseph, do you think if similar patch is possible for trunk? I will
> send a separate email for review if this approach is the right way to
> go.

What Joseph recommended was ripping out all support for building
libiberty for the target side as it is not needed.  Your patch just
skips it for those targets.

-- Pinski


Re: [google] Disable getpagesize() for Android toolchain (issue4515131)

2011-05-26 Thread Jing Yu
I have tested the following patch to skip building target libiberty
for arm*-*-linux-androideabi. It works as intended when building
Android arm-linux-androideabi toolchain.

Doug, do we want to skip building libiberty for non arm android
toolchain, say *-linux-android*?

Joseph, do you think if similar patch is possible for trunk? I will
send a separate email for review if this approach is the right way to
go.

Thanks,
Jing

Index: configure.ac
===
--- configure.ac(revision 174299)
+++ configure.ac(working copy)
@@ -515,7 +515,7 @@
   sh*-*-pe|mips*-*-pe|*arm-wince-pe)
 noconfigdirs="$noconfigdirs target-libiberty"
 ;;
-  arm*-*-symbianelf*)
+  arm*-*-symbianelf*|arm*-*-linux-androideabi)
 noconfigdirs="$noconfigdirs target-libiberty"
 ;;
   avr-*-*)
Index: configure
===
--- configure   (revision 174299)
+++ configure   (working copy)
@@ -3069,7 +3069,7 @@
   sh*-*-pe|mips*-*-pe|*arm-wince-pe)
 noconfigdirs="$noconfigdirs target-libiberty"
 ;;
-  arm*-*-symbianelf*)
+  arm*-*-symbianelf*|arm*-*-linux-androideabi)
 noconfigdirs="$noconfigdirs target-libiberty"
 ;;
   avr-*-*)




On Thu, May 26, 2011 at 5:00 AM, Joseph S. Myers
 wrote:
> On Wed, 25 May 2011, Jing Yu wrote:
>
>> I am wondering how to disable build of libiberty for target? I
>
> Tear out all the target-libiberty code unconditionally?  See
>  and references
> therein; building target libiberty at all is a bug in my view.
>
>> In some environment we still need to build libstdc++ libraries, where
>> libiberty has to be built for target. Can we use #ifndef __ANDROID__
>> to wrap around the getpagesize() definition? It is working for us.
>
> See what I said in
> .  libstdc++-v3
> does not use target libiberty; it uses one source file from the libiberty
> directory.
>
> --
> Joseph S. Myers
> jos...@codesourcery.com
>


Re: RFA: another patch to solve PR49154

2011-05-26 Thread Hans-Peter Nilsson
On Thu, 26 May 2011, Vladimir Makarov wrote:
> On 05/26/2011 04:47 AM, Hans-Peter Nilsson wrote:
> > On Wed, 25 May 2011, Vladimir Makarov wrote:
> > It sounds like you're saying that "the narrowest register
> > classes must be formed of registers for which there are trivial
> > instructions to move between registers inside the class"?
> >
> No it is wrong.  For example, SPARC FPCC (floating point control code
> registers) should form a uniform class but there are no trvial insns to move
> between registers inside the class.

I see.

> I'll think how to formulate the requirement but it will be really not easy.

I'd be very thankful but moreover we don't have to inspect the
source and guess and maybe ultimately ask you why the abort
triggered "every time" there's a new port or someone changes the
register classes in their port. :)

> > I think that'd be reasonable and if you agree I'll do the
> > update.
> >
> > In either case, your patch wouldn't be complete as more changes
> > are needed, for example for secondary reloads the new SRP_REGS
> > has to be considered.
> I've checked CC0 and it is not fixed.  If I make it fixed, I have pressure
> classes SPECIAL_REGS and GENERAL_REGS and the assertion is ok.  But you need
> another patch for PR49154, the one I sent to fix SPARC.

Oops, it should be, at least until the CRIS port is de-CC0:ed.
I'll fix that.  Still, I think I'll have a look why SRP was
"forgotten".

Good, a way forward (well, for me) even though the cure is
suspiciously incidental.  Thanks for your patience.

brgds, H-P


Re: [testsuite] remove XFAIL for all but ia64 for g++.dg/tree-ssa/pr43411.C

2011-05-26 Thread Janis Johnson
On 05/25/2011 05:15 AM, Jan Hubicka wrote:
> Am Wed 25 May 2011 11:04:06 AM CEST schrieb Richard Guenther  
> :
> 
>> On Wed, May 25, 2011 at 10:38 AM, Rainer Orth
>>  wrote:
>>> Janis Johnson  writes:
>>>
 Archived test results for 4.7.0 for most processors with C++ results have:

 XPASS: g++.dg/tree-ssa/pr43411.C scan-tree-dump-not optimized   
 "OBJ_TYPE_REF"

 The only failures I could find were for ia64-linux and ia64-hpux.  This
 patch changes the xfail so it only applies to ia64-*-*.  OK for trunk?
>>>
>>> Richard rejected a similar patch:
>>>
>>>http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00054.html
>>>
>>> Perhaps Jan can suggest the correct approach?
>>
>> We should verify that the call to val is inlined in all functions.
>> Maybe rename it to something larger and scan the optimized
>> dump so that name doesn't appear.
> Indeed, this seems to be safest approach I can think of.
> If function is supposed to be optimized out completely by early  
> passes, we should just search release_ssa.  It is not the case here  
> and dumping IPA info for inlining all instance would be bit tricky.

This patch renames val to function_to_inline and searches for its
name in the release-ssa dump.  That scan-dump has an xfail. The
original scan-dump of 'optimized' is removed.

Richard and Jan, is this OK?

2011-05-26  Janis Johnson  

* g++.dg/tree-ssa-pr43411.C: Rename function to be inlined and
replace dump search.

Index: g++.dg/tree-ssa/pr43411.C
===
--- g++.dg/tree-ssa/pr43411.C   (revision 174217)
+++ g++.dg/tree-ssa/pr43411.C   (working copy)
@@ -1,6 +1,6 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -fdump-tree-optimized" } */
-class P { public: virtual int val() { return 123; } };
+/* { dg-options "-O2 -fdump-tree-release_ssa" } */
+class P { public: virtual int function_to_inline() { return 123; } };
 class Psub : public P { };
 
 extern int sink1, sink2;
@@ -8,12 +8,12 @@
 void test() {
 Psub p;
 P &pRef = p;
-sink1 = p.val();
-sink2 = pRef.val();
+sink1 = p.function_to_inline();
+sink2 = pRef.function_to_inline();
 }
 
 
-inline int v(P &p) { return p.val(); }
+inline int v(P &p) { return p.function_to_inline(); }
 
 void testInlineP() {
 P p;
@@ -25,5 +25,5 @@
 sink1 = v(p);
 }
 
-// { dg-final { scan-tree-dump-not "OBJ_TYPE_REF" "optimized" { xfail *-*-* } 
} }
-// { dg-final { cleanup-tree-dump "optimized" } }
+// { dg-final { scan-tree-dump-not "function_to_inline" "release_ssa" { xfail 
*-*-* } } }
+// { dg-final { cleanup-tree-dump "release_ssa" } }


Re: [testsuite] remove XFAIL for all but ia64 for g++.dg/tree-ssa/pr43411.C

2011-05-26 Thread Mike Stump
On May 26, 2011, at 8:55 AM, Richard Guenther wrote:
> The red on the transition should cause the human that did that transition to 
> do that inspection.

[ thinking about this some more ]  Agreed.  So, that means I should not just 
approve the XPASS -> PASS changes and that people that cause them should chime 
in instead.  Harder to always know just when they were put in and by who.  
Thanks.


Re: New options to disable/enable any pass for any functions (issue4550056)

2011-05-26 Thread Xinliang David Li
The latest version that only exports 2 functions from passes.c.

David

On Thu, May 26, 2011 at 2:04 PM, Xinliang David Li  wrote:
> On Thu, May 26, 2011 at 2:04 AM, Richard Guenther
>  wrote:
>> On Wed, May 25, 2011 at 6:53 PM, Joseph S. Myers
>>  wrote:
>>> On Wed, 25 May 2011, Xinliang David Li wrote:
>>>
 Ping. The link to the message:

 http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01303.html
>>>
>>> I don't consider this an option handling patch.  Patches adding whole new
>>> features involving new options should be reviewed by maintainers for the
>>> part of the compiler relevant to those features (since there isn't a pass
>>> manager maintainer, I guess that means middle-end).
>>
>> Hmm, I suppose then you reviewed the option handling parts and they
>> are ok?  Those globbing options always cause headache to me.
>>
>> +-fenable-ipa-@var{pass} @gol
>> +-fenable-rtl-@var{pass} @gol
>> +-fenable-rtl-@var{pass}=@var{range-list} @gol
>> +-fenable-tree-@var{pass} @gol
>>
>> so, no -fenable-tree-@var{pass}=@var{range-list}?
>>
>
> Missed. Will add.
>
>
>> Does the pass name match 1:1 with the dump file name?  In which
>> case
>
> Yes.
>
>>
>> +Disable ipa pass @var{pass}. @var{pass} is the pass name. If the same
>> pass is statically invoked in the compiler multiple times, the pass
>> name should be appended with a sequential number starting from 1.
>>
>> isn't true as passes that are invoked only a single time lack the number
>> suffix (yes, I'd really like that to be changed ...)
>
> Yes, pass with single static instance does not need number suffix.
>
>>
>> Please break likes also in .texi files and stick to 80 columns.
>
> Done.
>
>>  Please
>> document that these options are debugging options and regular
>> options for enabling/disabling passes should be used.  I would suggest
>> to group documentation differently and document -fenable-* and
>> -fdisable-*, thus,
>>
>> + -fdisable-@var{kind}-@var{pass}
>> + -fenable-@var{kind}-@var{pass}
>>
>> Even in .texi files please two spaces after a full-stop.
>
> Done
>
>>
>> +extern void enable_disable_pass (const char *, bool);
>>
>> I'd rather have both enable_pass and disable_pass ;)
>
> Ok.
>
>>
>> +struct function;
>> +extern void pass_dump_function_header (FILE *, tree, struct function *);
>>
>> that's odd and probably should be split out, the function should
>> maybe reside in tree-pretty-print.c.
>
> Ok.
>
>>
>> Index: tree-ssa-loop-ivopts.c
>> ===
>> --- tree-ssa-loop-ivopts.c      (revision 173837)
>> +++ tree-ssa-loop-ivopts.c      (working copy)
>> @@ -3968,7 +3968,7 @@ get_computation_cost_at (struct ivopts_d
>>
>> well - doesn't belong here ;)
>
> Sorry -- many things in the same client -- not needed with your latest
> change anyway.
>
>>
>> +static hashval_t
>> +passr_hash (const void *p)
>> +{
>> +  const struct pass_registry *const s = (const struct pass_registry *const) 
>> p;
>> +  return htab_hash_string (s->unique_name);
>> +}
>> +
>> +/* Hash equal function  */
>> +
>> +static int
>> +passr_eq (const void *p1, const void *p2)
>> +{
>> +  const struct pass_registry *const s1 = (const struct pass_registry
>> *const) p1;
>> +  const struct pass_registry *const s2 = (const struct pass_registry
>> *const) p2;
>> +
>> +  return !strcmp (s1->unique_name, s2->unique_name);
>> +}
>>
>> you can use htab_hash_string and strcmp directly, no need for these
>> wrappers.
>
> The hashtable entry is not string in this case. It is pass_registry,
> thus the wrapper.
>
>>
>> +void
>> +register_pass_name (struct opt_pass *pass, const char *name)
>>
>> doesn't seem to need exporting, so don't and make it static.
>
> Done.
>
>>
>> +  if (!pass_name_tab)
>> +    pass_name_tab = htab_create (10, passr_hash, passr_eq, NULL);
>>
>> see above, the initial size should be larger - we have 223 passes at the
>> moment, so use 256.
>
> Done.
>
>>
>> +  else
>> +    return; /* Ignore plugin passes.  */
>>
>> ?  You mean they might clash?
>
> Yes, name clash.
>
>>
>> +struct opt_pass *
>> +get_pass_by_name (const char *name)
>>
>> doesn't need exporting either.
>
> Done.
>
>>
>> +      if (is_enable)
>> +        error ("unrecognized option -fenable");
>> +      else
>> +        error ("unrecognized option -fdisable");
>>
>> I think that should be fatal_error - Joseph?
>>
>> +      if (is_enable)
>> +        error ("unknown pass %s specified in -fenable", phase_name);
>> +      else
>> +        error ("unknown pass %s specified in -fdisble", phase_name);
>>
>> likewise.
>>
>> +      if (!enabled_pass_uid_range_tab)
>> +       enabled_pass_uid_range_tab = htab_create (10, pass_hash, pass_eq, 
>> NULL);
>>
>> instead of using a hashtable here please use a VEC indexed by
>> the static_pass_number which shoud speed up
>
> Ok.  The reason I did not use it is because in most of the cases, the
> htab will be very small -- it is determined by the number of passes
> specified in the command line, while the VE

Re: [testsuite] gcc.dg/march.c: expect extra message for ARM

2011-05-26 Thread Janis Johnson
On 05/26/2011 02:54 PM, Joseph S. Myers wrote:
> On Thu, 26 May 2011, Janis Johnson wrote:
> 
>> On 05/26/2011 01:23 PM, Bernd Schmidt wrote:
>>> On 05/26/2011 08:20 PM, Janis Johnson wrote:
 Changes went into ARM support recently to add an informative note after an 
 error about an invalid argument to -march=.  This patch looks for that 
 message on ARM targets and allows the test to once again pass.

 OK for trunk?
>>>
>>> mtune.c does the following:
>>>
>>> /* { dg-prune-output "note: valid arguments.*" } */
>>>
>>> which is probably better as it's target independent? OK to make that change.
>>
>> I would prefer to look for the note in both tests, currently for arm
>> and perhaps later for additional targets that use it.  Let's see what
>> others have to say.
> 
> It should end up being every target; if you want to list targets 
> explicitly you should use a blacklist of targets that haven't been 
> converted to use Enum for -march= yet.  Except that targets may not have 
> -march= at all, so that doesn't work without whitelisting the targets with 
> no -march= option.  I think pruning for all targets is the right approach.
> 

OK, you guys convinced me, pruning it is.  I'll commit a patch to do that.

Janis


[PATCH] Fix PR 48981 aliasing bug inside GCC

2011-05-26 Thread Andrew Pinski
The problem here is that vec.c accesses VEC__base via a
vec_prefix but VEC__base's first field is not a vec_prefix.
This patch fixes the problem by changing how VEC_*_base is done by
using vec_prefix as the real base.

OK? Bootstrapped and tested on x86_64 without any regressions.

Thanks,
Andrew Pinski

ChangeLog:
* gengtype.c (vec_prefix_type): New function.
(note_def_vec): Use vec_prefix_type and change the length
attribute to be based on the prefix.
* vec.c: Include coretypes.h before vec.h.
(struct vec_prefix): Remove.
(vec_gc_p_reserve): Change the offsetof to sizeof.
(vec_gc_p_reserve_exact): Likewise.
(vec_heap_p_reserve): Likewise.
(vec_heap_p_reserve_exact): Likewise.
(vec_stack_o_reserve_1): Copy from +1 instead of from vec.
(vec_stack_p_reserve): Change the offsetof to sizeof.
(vec_stack_p_reserve_exact): Likewise.
* vec.h (struct vec_prefix): New struct definition.
(VEC_T(T,B)): Use vec_prefix instead of having num/alloc fields.
(VEC_T_GTY(T,B)): Likewise.
(DEF_VEC_FUNC_P(T)): Use prefix field.
(DEF_VEC_NONALLOC_FUNCS_O(T,A)): Likewise.
(DEF_VEC_NONALLOC_FUNCS_I(T,A)): Likewise.
Index: gengtype.c
===
--- gengtype.c  (revision 174305)
+++ gengtype.c  (working copy)
@@ -4130,14 +4130,36 @@ write_roots (pair_p variables, bool emit
   finish_root_table (flp, "pch_rs", "LAST_GGC_ROOT_TAB", "ggc_root_tab",
 "gt_pch_scalar_rtab");
 }
+/* Record the definition of the vec_prefix structure, as defined in vec.h:
+
+   struct vec_prefix GTY(()) {
+   unsigned num;
+   unsigned alloc;
+   };  */
+static type_p
+vec_prefix_type (void)
+{
+  static type_p prefix_type = NULL;
+  if (prefix_type == NULL)
+{
+  pair_p fields;
+  static struct fileloc pos = { NULL, 0 };
+  type_p len_ty = create_scalar_type ("unsigned");
+  pos.file = input_file_by_name (__FILE__); pos.line = __LINE__;
+  fields = create_field_at (0, len_ty, "alloc", 0, &pos);
+  fields = create_field_at (fields, len_ty, "num", 0, &pos);
+  prefix_type = new_structure ("vec_prefix", 0, &pos, fields, 0);
+  prefix_type->u.s.bitmap = -1;
+}
+  return prefix_type;
+}
 
 /* Record the definition of a generic VEC structure, as if we had expanded
the macros in vec.h:
 
typedef struct VEC__base GTY(()) {
-   unsigned num;
-   unsigned alloc;
-GTY((length ("%h.num"))) vec[1];
+   struct vec_prefix prefix;
+GTY((length ("%h.prefix.num"))) vec[1];
} VEC__base
 
where the GTY(()) tags are only present if is_scalar is _false_.  */
@@ -4148,7 +4170,6 @@ note_def_vec (const char *type_name, boo
   pair_p fields;
   type_p t;
   options_p o;
-  type_p len_ty = create_scalar_type ("unsigned");
   const char *name = concat ("VEC_", type_name, "_base", (char *) 0);
 
   if (is_scalar)
@@ -4159,12 +4180,11 @@ note_def_vec (const char *type_name, boo
   else
 {
   t = resolve_typedef (type_name, pos);
-  o = create_string_option (0, "length", "%h.num");
+  o = create_string_option (0, "length", "%h.prefix.num");
 }
   /* We assemble the field list in reverse order.  */
   fields = create_field_at (0, create_array (t, "1"), "vec", o, pos);
-  fields = create_field_at (fields, len_ty, "alloc", 0, pos);
-  fields = create_field_at (fields, len_ty, "num", 0, pos);
+  fields = create_field_at (fields, vec_prefix_type (), "prefix", 0, pos);
 
   do_typedef (name, new_structure (name, 0, pos, fields, 0), pos);
 }
Index: vec.c
===
--- vec.c   (revision 174305)
+++ vec.c   (working copy)
@@ -28,20 +28,12 @@ along with GCC; see the file COPYING3.
 #endif
 
 #include "system.h"
+#include "coretypes.h"
 #include "ggc.h"
 #include "vec.h"
-#include "coretypes.h"
 #include "diagnostic-core.h"
 #include "hashtab.h"
 
-struct vec_prefix
-{
-  unsigned num;
-  unsigned alloc;
-  void *vec[1];
-};
-
-
 #ifdef GATHER_STATISTICS
 
 /* Store information about each particular vector.  */
@@ -254,7 +246,7 @@ void *
 vec_gc_p_reserve (void *vec, int reserve MEM_STAT_DECL)
 {
   return vec_gc_o_reserve_1 (vec, reserve,
-offsetof (struct vec_prefix, vec),
+sizeof (struct vec_prefix),
 sizeof (void *), false
 PASS_MEM_STAT);
 }
@@ -268,7 +260,7 @@ void *
 vec_gc_p_reserve_exact (void *vec, int reserve MEM_STAT_DECL)
 {
   return vec_gc_o_reserve_1 (vec, reserve,
-offsetof (struct vec_prefix, vec),
+sizeof (struct vec_prefix),
 sizeof (void *), true
 PASS_MEM_STAT);
 }
@@ -337,7 +329,7 @@ void *
 vec_heap_p_reserve (void *vec, int reserve MEM_STAT_DECL)
 {
   return vec_heap_o_reserve_1 (vec, reserve,
-  offsetof (struct vec_prefix, vec),
+  sizeof (struct vec_prefix),
 

Re: [testsuite] gcc.dg/march.c: expect extra message for ARM

2011-05-26 Thread Joseph S. Myers
On Thu, 26 May 2011, Janis Johnson wrote:

> On 05/26/2011 01:23 PM, Bernd Schmidt wrote:
> > On 05/26/2011 08:20 PM, Janis Johnson wrote:
> >> Changes went into ARM support recently to add an informative note after an 
> >> error about an invalid argument to -march=.  This patch looks for that 
> >> message on ARM targets and allows the test to once again pass.
> >>
> >> OK for trunk?
> > 
> > mtune.c does the following:
> > 
> > /* { dg-prune-output "note: valid arguments.*" } */
> > 
> > which is probably better as it's target independent? OK to make that change.
> 
> I would prefer to look for the note in both tests, currently for arm
> and perhaps later for additional targets that use it.  Let's see what
> others have to say.

It should end up being every target; if you want to list targets 
explicitly you should use a blacklist of targets that haven't been 
converted to use Enum for -march= yet.  Except that targets may not have 
-march= at all, so that doesn't work without whitelisting the targets with 
no -march= option.  I think pruning for all targets is the right approach.

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


Re: [build] Fix Solaris 2/x86 GD/LD TLS code sequences with Sun ld

2011-05-26 Thread Uros Bizjak
On Thu, May 26, 2011 at 12:47 PM, Rainer Orth
 wrote:

>>> We could certainly duplicate (some of) the logic that %P already uses,
>>> but I though it easier to just introduce a straightforward variant (%p)
>>> instead.  It's not pretty, but it worked.
>>
>> OK then... can you propose a new patch, please, changing as little of
>> generic code as possible?
>
> I'll try, but somewhat fear that I will arive again at what I had
> initially.  Will probably have to wait for the weekend.

Please find attached the patch that introduces %p to output only the
raw symbol name. @plt is added "manually", since it doesn't really
follow -fpic flag.

Uros.
Index: gcc/config/i386/i386.md
===
--- gcc/config/i386/i386.md (revision 174306)
+++ gcc/config/i386/i386.md (working copy)
@@ -12367,6 +12367,12 @@
 {
   output_asm_insn
 ("lea{l}\t{%a2@tlsgd(,%1,1), %0|%0, %a2@tlsgd[%1*1]}", operands);
+  if (TARGET_SUN_TLS)
+#ifdef HAVE_AS_IX86_TLSGDPLT
+return "call\t%a2@tlsgdplt";
+#else
+return "call\t%p3@plt";
+#endif
   return "call\t%P3";
 }
   [(set_attr "type" "multi")
@@ -12397,6 +12403,8 @@
 ("lea{q}\t{%a1@tlsgd(%%rip), %%rdi|rdi, %a1@tlsgd[rip]}", operands);
   fputs (ASM_SHORT "0x\n", asm_out_file);
   fputs ("\trex64\n", asm_out_file);
+  if (TARGET_SUN_TLS)
+return "call\t%p2@plt";
   return "call\t%P2";
 }
   [(set_attr "type" "multi")
@@ -12424,6 +12432,12 @@
 {
   output_asm_insn
 ("lea{l}\t{%&@tlsldm(%1), %0|%0, %&@tlsldm[%1]}", operands);
+  if (!TARGET_SUN_TLS)
+#ifdef HAVE_AS_IX86_TLSLDMPLT
+return "call\t%&@tlsldmplt";
+#else
+return "call\t%p2@plt";
+#endif
   return "call\t%P2";
 }
   [(set_attr "type" "multi")
@@ -12450,6 +12464,8 @@
 {
   output_asm_insn
 ("lea{q}\t{%&@tlsld(%%rip), %%rdi|rdi, %&@tlsld[rip]}", operands);
+  if (TARGET_SUN_TLS)
+return "call\t%p1@plt";
   return "call\t%P1";
 }
   [(set_attr "type" "multi")
Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c  (revision 174306)
+++ gcc/config/i386/i386.c  (working copy)
@@ -13918,6 +13918,7 @@ get_some_local_dynamic_name (void)
d -- print duplicated register operand for AVX instruction.
D -- print condition for SSE cmp instruction.
P -- if PIC, print an @PLT suffix.
+   p -- print raw symbol name.
X -- don't print any sort of PIC '@' suffix for a symbol.
& -- print some in-use local-dynamic symbol name.
H -- print a memory address offset by 8; used for sse high-parts
@@ -14123,6 +14124,7 @@ ix86_print_operand (FILE *file, rtx x, i
case 'x':
case 'X':
case 'P':
+   case 'p':
  break;
 
case 's':
@@ -14522,7 +14524,7 @@ ix86_print_operand (FILE *file, rtx x, i
  x = const0_rtx;
}
 
-  if (code != 'P')
+  if (code != 'P' && code != 'p')
{
  if (CONST_INT_P (x) || GET_CODE (x) == CONST_DOUBLE)
{


Re: RFC: explicitely mark out-of-scope deaths

2011-05-26 Thread Martin Jambor
Hi,

On Thu, May 26, 2011 at 03:43:45PM +0200, Michael Matz wrote:
> Index: tree-sra.c
> ===
> --- tree-sra.c.orig   2011-05-26 14:15:01.0 +0200
> +++ tree-sra.c2011-05-26 14:15:41.0 +0200
> @@ -1041,6 +1041,11 @@ build_accesses_from_assign (gimple stmt)
>if (disqualify_ops_if_throwing_stmt (stmt, lhs, rhs))
>  return false;
>  
> +  /* Scope clobbers don't influence scalarization.  */
> +  if (TREE_CODE (rhs) == CONSTRUCTOR
> +  && TREE_THIS_VOLATILE (rhs))
> +return false;
> +
>racc = build_access_from_expr_1 (rhs, stmt, false);
>lacc = build_access_from_expr_1 (lhs, stmt, true);

I assume DSE does not remove the stores as that would defeat the
purpose of the patch.  If after optimizations such as SRA, these
special stores are the only statements accessing the variable, will
the variable still remain in the function potentially causing an
unnecessary stack frame setup?

If so, then SRA would have to delete these statements in its
modification phase if it has removed all other accesses to the
aggregate.  This is something I can do as a followup, of course.

Thanks,

Martin

>  
> Index: tree-ssa-dce.c
> ===
> --- tree-ssa-dce.c.orig   2011-05-26 14:15:01.0 +0200
> +++ tree-ssa-dce.c2011-05-26 14:15:41.0 +0200
> @@ -846,19 +846,17 @@ propagate_necessity (struct edge_list *e
> else if (gimple_assign_single_p (stmt))
>   {
> tree rhs;
> -   bool rhs_aliased = false;
> /* If this is a load mark things necessary.  */
> rhs = gimple_assign_rhs1 (stmt);
> if (TREE_CODE (rhs) != SSA_NAME
> -   && !is_gimple_min_invariant (rhs))
> +   && !is_gimple_min_invariant (rhs)
> +   && TREE_CODE (rhs) != CONSTRUCTOR)
>   {
> if (!ref_may_be_aliased (rhs))
>   mark_aliased_reaching_defs_necessary (stmt, rhs);
> else
> - rhs_aliased = true;
> + mark_all_reaching_defs_necessary (stmt);
>   }
> -   if (rhs_aliased)
> - mark_all_reaching_defs_necessary (stmt);
>   }
> else if (gimple_code (stmt) == GIMPLE_RETURN)
>   {
> @@ -866,7 +864,8 @@ propagate_necessity (struct edge_list *e
> /* A return statement may perform a load.  */
> if (rhs
> && TREE_CODE (rhs) != SSA_NAME
> -   && !is_gimple_min_invariant (rhs))
> +   && !is_gimple_min_invariant (rhs)
> +   && TREE_CODE (rhs) != CONSTRUCTOR)
>   {
> if (!ref_may_be_aliased (rhs))
>   mark_aliased_reaching_defs_necessary (stmt, rhs);
> @@ -884,6 +883,7 @@ propagate_necessity (struct edge_list *e
> tree op = TREE_VALUE (gimple_asm_input_op (stmt, i));
> if (TREE_CODE (op) != SSA_NAME
> && !is_gimple_min_invariant (op)
> +   && TREE_CODE (op) != CONSTRUCTOR
> && !ref_may_be_aliased (op))
>   mark_aliased_reaching_defs_necessary (stmt, op);
>   }
> Index: gimple.c
> ===
> --- gimple.c.orig 2011-05-26 14:15:01.0 +0200
> +++ gimple.c  2011-05-26 14:15:41.0 +0200
> @@ -1425,7 +1425,9 @@ walk_gimple_op (gimple stmt, walk_tree_f
>   {
>/* If the RHS has more than 1 operand, it is not appropriate
>   for the memory.  */
> -   wi->val_only = !is_gimple_mem_rhs (gimple_assign_rhs1 (stmt))
> +   wi->val_only = !(is_gimple_mem_rhs (gimple_assign_rhs1 (stmt))
> +|| TREE_CODE (gimple_assign_rhs1 (stmt))
> +   == CONSTRUCTOR)
>   || !gimple_assign_single_p (stmt);
> wi->is_lhs = true;
>   }
> Index: tree-ssa-structalias.c
> ===
> --- tree-ssa-structalias.c.orig   2011-05-26 14:15:01.0 +0200
> +++ tree-ssa-structalias.c2011-05-26 14:15:41.0 +0200
> @@ -4355,7 +4355,12 @@ find_func_aliases (gimple origt)
>tree lhsop = gimple_assign_lhs (t);
>tree rhsop = (gimple_num_ops (t) == 2) ? gimple_assign_rhs1 (t) : NULL;
>  
> -  if (rhsop && AGGREGATE_TYPE_P (TREE_TYPE (lhsop)))
> +  if (rhsop && TREE_CODE (rhsop) == CONSTRUCTOR
> +   && TREE_THIS_VOLATILE (rhsop))
> + /* Ignore clobbers, they don't actually store anything into
> +the LHS.  */
> + ;
> +  else if (rhsop && AGGREGATE_TYPE_P (TREE_TYPE (lhsop)))
>   do_structure_copy (lhsop, rhsop);
>else
>   {
> Index: tree-ssa-operands.c
> ===
> --- tree-ssa-operands

Re: New options to disable/enable any pass for any functions (issue4550056)

2011-05-26 Thread Xinliang David Li
On Thu, May 26, 2011 at 2:04 AM, Richard Guenther
 wrote:
> On Wed, May 25, 2011 at 6:53 PM, Joseph S. Myers
>  wrote:
>> On Wed, 25 May 2011, Xinliang David Li wrote:
>>
>>> Ping. The link to the message:
>>>
>>> http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01303.html
>>
>> I don't consider this an option handling patch.  Patches adding whole new
>> features involving new options should be reviewed by maintainers for the
>> part of the compiler relevant to those features (since there isn't a pass
>> manager maintainer, I guess that means middle-end).
>
> Hmm, I suppose then you reviewed the option handling parts and they
> are ok?  Those globbing options always cause headache to me.
>
> +-fenable-ipa-@var{pass} @gol
> +-fenable-rtl-@var{pass} @gol
> +-fenable-rtl-@var{pass}=@var{range-list} @gol
> +-fenable-tree-@var{pass} @gol
>
> so, no -fenable-tree-@var{pass}=@var{range-list}?
>

Missed. Will add.


> Does the pass name match 1:1 with the dump file name?  In which
> case

Yes.

>
> +Disable ipa pass @var{pass}. @var{pass} is the pass name. If the same
> pass is statically invoked in the compiler multiple times, the pass
> name should be appended with a sequential number starting from 1.
>
> isn't true as passes that are invoked only a single time lack the number
> suffix (yes, I'd really like that to be changed ...)

Yes, pass with single static instance does not need number suffix.

>
> Please break likes also in .texi files and stick to 80 columns.

Done.

>  Please
> document that these options are debugging options and regular
> options for enabling/disabling passes should be used.  I would suggest
> to group documentation differently and document -fenable-* and
> -fdisable-*, thus,
>
> + -fdisable-@var{kind}-@var{pass}
> + -fenable-@var{kind}-@var{pass}
>
> Even in .texi files please two spaces after a full-stop.

Done

>
> +extern void enable_disable_pass (const char *, bool);
>
> I'd rather have both enable_pass and disable_pass ;)

Ok.

>
> +struct function;
> +extern void pass_dump_function_header (FILE *, tree, struct function *);
>
> that's odd and probably should be split out, the function should
> maybe reside in tree-pretty-print.c.

Ok.

>
> Index: tree-ssa-loop-ivopts.c
> ===
> --- tree-ssa-loop-ivopts.c      (revision 173837)
> +++ tree-ssa-loop-ivopts.c      (working copy)
> @@ -3968,7 +3968,7 @@ get_computation_cost_at (struct ivopts_d
>
> well - doesn't belong here ;)

Sorry -- many things in the same client -- not needed with your latest
change anyway.

>
> +static hashval_t
> +passr_hash (const void *p)
> +{
> +  const struct pass_registry *const s = (const struct pass_registry *const) 
> p;
> +  return htab_hash_string (s->unique_name);
> +}
> +
> +/* Hash equal function  */
> +
> +static int
> +passr_eq (const void *p1, const void *p2)
> +{
> +  const struct pass_registry *const s1 = (const struct pass_registry
> *const) p1;
> +  const struct pass_registry *const s2 = (const struct pass_registry
> *const) p2;
> +
> +  return !strcmp (s1->unique_name, s2->unique_name);
> +}
>
> you can use htab_hash_string and strcmp directly, no need for these
> wrappers.

The hashtable entry is not string in this case. It is pass_registry,
thus the wrapper.

>
> +void
> +register_pass_name (struct opt_pass *pass, const char *name)
>
> doesn't seem to need exporting, so don't and make it static.

Done.

>
> +  if (!pass_name_tab)
> +    pass_name_tab = htab_create (10, passr_hash, passr_eq, NULL);
>
> see above, the initial size should be larger - we have 223 passes at the
> moment, so use 256.

Done.

>
> +  else
> +    return; /* Ignore plugin passes.  */
>
> ?  You mean they might clash?

Yes, name clash.

>
> +struct opt_pass *
> +get_pass_by_name (const char *name)
>
> doesn't need exporting either.

Done.

>
> +      if (is_enable)
> +        error ("unrecognized option -fenable");
> +      else
> +        error ("unrecognized option -fdisable");
>
> I think that should be fatal_error - Joseph?
>
> +      if (is_enable)
> +        error ("unknown pass %s specified in -fenable", phase_name);
> +      else
> +        error ("unknown pass %s specified in -fdisble", phase_name);
>
> likewise.
>
> +      if (!enabled_pass_uid_range_tab)
> +       enabled_pass_uid_range_tab = htab_create (10, pass_hash, pass_eq, 
> NULL);
>
> instead of using a hashtable here please use a VEC indexed by
> the static_pass_number which shoud speed up

Ok.  The reason I did not use it is because in most of the cases, the
htab will be very small -- it is determined by the number of passes
specified in the command line, while the VEC requires allocating const
size array. Not an issue as long as by default the array is not
allocated.

>
> +static bool
> +is_pass_explicitly_enabled_or_disabled (struct opt_pass *pass,
> +                                       tree func, htab_t tab)
> +{
> +  struct uid_range **slot, *range, key;
> +  int cgraph_uid;
> +
> 

Re: RFA: another patch to solve PR49154

2011-05-26 Thread Vladimir Makarov

On 05/26/2011 04:47 AM, Hans-Peter Nilsson wrote:

On Wed, 25 May 2011, Vladimir Makarov wrote:

On 11-05-25 6:58 PM, Hans-Peter Nilsson wrote:

On Wed, 25 May 2011, Vladimir Makarov wrote:


This patch solves http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49154 for
CRIS.
The problem was in that the pressure classes did not contain SRP register
and
the assert failed.

I'm not sure I understand the basic requirement.


It is ambiguous area.  Register pressure classes are used for register
pressure evaluation in several parts of the compiler:

register pressure sensitive loop invariant motion
register pressure sensitive insn scheduling
and in IRA to form regions for allocation

In some way register pressure classes are what cover classes were when they
were defined.

Just a note here; for cover classes, SPECIAL_REGS was sufficient.


  But right definition of register pressure classes are not so
critical as the right definition of cover classes were earlier because
register pressure calculation is in some way approximation (even if we know
what exact classes will be used for each pseudo during the allocation, but we
don't know it yet exactly when the register pressure is calculated) because
classes used for allocation (allocno classes) are calculated dynamicly and
they can be different from register pressure classes and the old cover classes
and, the most important thing, the allocno classes can be intersected in any
way which makes the register pressure caclulation is inaccurate.  Still the
register pressure calculation is useful.

I added an assertion which checks that the calculated register pressure
classes contains all allocatable hard registers.  When the assertion fails we
have this problem.  But the compiler will work well even if the assertion
fails.  Generally speaking, we could remove the assertion without harm.  The
assertion is just a check for *the most* targets that the pressure classes
calculation is not broken because for the most targets the register pressure
classes should contain all available hard registers.

The assertion failed for CRIS because we had pressure classes only CC0_REGS
and GENERAL_REGS which do not includes SRP register.

It sounds like a bug that CC0_REGS was considered at all, as the
only register is not allocatable.  SPECIAL_REGS should be
chosen; the only allocatable register would be SRP_REGS
(additionally, MOF_REGS for the v10 multilib).

I'll have a look.


Can you please suggest an update to the target macro
documentation to reflect the requirement it's currently failing?
To feel ok with this change I need to understand why it's not ok
as is: I can't see the error, just a random change narrowing a
register class that at a glance *should* not be needed.  To wit,
I need to understand why the bug is here and that it's not the
failing assert in IRA that's wrong.


I don't think it is necessary because as I know only CRIS requires register
classes modification.

On the contrary.  I think at least a "should" needs to change to
"must" regarding register classes, or we can't say what to
change.  The documentation is not "what works for most targets"!

It sounds like you're saying that "the narrowest register
classes must be formed of registers for which there are trivial
instructions to move between registers inside the class"?

No it is wrong.  For example, SPARC FPCC (floating point control code 
registers) should form a uniform class but there are no trvial insns to 
move between registers inside the class.


I'll think how to formulate the requirement but it will be really not easy.

I think that'd be reasonable and if you agree I'll do the
update.

In either case, your patch wouldn't be complete as more changes
are needed, for example for secondary reloads the new SRP_REGS
has to be considered.
I've checked CC0 and it is not fixed.  If I make it fixed, I have 
pressure classes SPECIAL_REGS and GENERAL_REGS and the assertion is ok.  
But you need another patch for PR49154, the one I sent to fix SPARC.




Re: [testsuite] gcc.dg/march.c: expect extra message for ARM

2011-05-26 Thread Janis Johnson
On 05/26/2011 01:23 PM, Bernd Schmidt wrote:
> On 05/26/2011 08:20 PM, Janis Johnson wrote:
>> Changes went into ARM support recently to add an informative note after an 
>> error about an invalid argument to -march=.  This patch looks for that 
>> message on ARM targets and allows the test to once again pass.
>>
>> OK for trunk?
> 
> mtune.c does the following:
> 
> /* { dg-prune-output "note: valid arguments.*" } */
> 
> which is probably better as it's target independent? OK to make that change.

I would prefer to look for the note in both tests, currently for arm
and perhaps later for additional targets that use it.  Let's see what
others have to say.

Janis



Re: [testsuite] gcc.dg/march.c: expect extra message for ARM

2011-05-26 Thread Bernd Schmidt
On 05/26/2011 08:20 PM, Janis Johnson wrote:
> Changes went into ARM support recently to add an informative note after an 
> error about an invalid argument to -march=.  This patch looks for that 
> message on ARM targets and allows the test to once again pass.
> 
> OK for trunk?

mtune.c does the following:

/* { dg-prune-output "note: valid arguments.*" } */

which is probably better as it's target independent? OK to make that change.


Bernd


[testsuite] gcc.dg/march.c: expect extra message for ARM

2011-05-26 Thread Janis Johnson
Changes went into ARM support recently to add an informative note after an 
error about an invalid argument to -march=.  This patch looks for that message 
on ARM targets and allows the test to once again pass.

OK for trunk?
Index: gcc.dg/march.c
===
--- gcc.dg/march.c  (revision 163294)
+++ gcc.dg/march.c  (working copy)
@@ -2,5 +2,6 @@
 /* { dg-skip-if "" { *-*-* } { "-march=*" } { "" } } */
 /* { dg-options "-march=foo" } */
 /* { dg-error "march" "" { target *-*-* } 0 } */
+/* { dg-message "note: valid arguments" "note" { target arm*-*-* } 0 } */
 /* { dg-bogus "mtune" "" { target *-*-* } 0 } */
 int i;


Re: [PATCH] PR debug/49047 (linkage name missing for cdtors)

2011-05-26 Thread Dodji Seketeli
Jason Merrill  a écrit:

> Why not just call add_linkage_name after add_abstract_origin_attribute?

That is what I first did and it worked for this case.  But then I wasn't
sure if there could be cases where a function DIE would have the
DW_AT_abstract_origin set, but won't have any actual code? For instance
if the function has DECL_EXTERNAL set.  That's why I wanted to call
add_linkage_name only if the function has DW_AT_{low,high}_pc so that I
am sure it contains actual code.

If my concern is not justified then I guess the patch below should be
enough then.

gcc/

* dwarf2out.c (gen_subprogram_die): Emit linkage name attribute
for functions containing actual code for public cloned abstract
functions.

gcc/testsuite/

* g++.dg/debug/dwarf2/cdtor-1.C: New test.
---
 gcc/dwarf2out.c |7 +++
 gcc/testsuite/g++.dg/debug/dwarf2/cdtor-1.C |   17 +
 2 files changed, 24 insertions(+), 0 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/debug/dwarf2/cdtor-1.C

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 55453a3..0cf782f 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -19636,6 +19636,13 @@ gen_subprogram_die (tree decl, dw_die_ref context_die)
 
   subr_die = new_die (DW_TAG_subprogram, context_die, decl);
   add_abstract_origin_attribute (subr_die, origin);
+  if (TREE_PUBLIC (origin))
+   /*  So this is where the actual code for a publicly accessible
+   cloned function is.  Let's emit linkage name attribute for
+   it.  This helps debuggers to e.g, set breakpoints into
+   constructors/destructors when the user asks "break
+   K::K".  */
+   add_linkage_name (subr_die, decl);
 }
   else if (old_die)
 {
diff --git a/gcc/testsuite/g++.dg/debug/dwarf2/cdtor-1.C 
b/gcc/testsuite/g++.dg/debug/dwarf2/cdtor-1.C
new file mode 100644
index 000..6d39e54
--- /dev/null
+++ b/gcc/testsuite/g++.dg/debug/dwarf2/cdtor-1.C
@@ -0,0 +1,17 @@
+// origin PR debug/49047
+// { dg-options "-g -dA" }
+// { dg-do compile }
+
+struct K
+{
+  K () { }
+  ~K () { }
+};
+
+int
+main()
+{
+K k;
+}
+
+// { dg-final {scan-assembler-times "\[^\n\r\]*DW_AT_MIPS_linkage_name:" 2 } }
-- 
1.7.3.4


-- 
Dodji


Re: PATCH: Add pause intrinsic

2011-05-26 Thread Basile Starynkevitch
On Thu, 26 May 2011 13:48:13 -0400
Paul Koning  wrote:

> Relax?  Weird.  "Pause" is just as weird.  It might be an ia32 instruction, 
> so as an ia32 builtin it is a reasonable name  But if you want a generic 
> builtin, you need a name that actually has some plausible connection with 
> what it does, and neither "pause" nor "relax" do that.

I still think that having a builtin which do a "compiler flush" that is
which spill all registers to memory is useful, eg a
builtin_compiler_flush()

And I even think there is another reason to use it. If you are
debugging a program compiled with -O2 -g, and if you know where there
could be a bug or a fault, temporarily adding a call to that
builtin_compiler_flush () would probably help the gdb debugger a lot.

Regards.

-- 
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***


Re: Reintroduce -mflat option on SPARC

2011-05-26 Thread Eric Botcazou
> In fact, I haven't tried to make big changes in how mflat option was
> implemented. From my point of view, the goal was to facilitate mflat
> option reintroduction first, and then improve it after. I hope you
> understand. I know there's some place to improve, maybe you have start
> to do it ?

Yes, I have changed a few things, patch attached.  The basic stuff works, but 
not yet the fancy features (non-local gotos, setjmp/longjmp and exceptions).  
I'm also working on the GDB side.

> So why mflat is like that we should ask the questions to 'wilson' who
> did it in 92 (see revision 1275) !

Indeed, thanks for doing the archaeology. :-)


* doc/invoke.texi (SPARC options): Add -mflat.
* config/sparc/sparc.opt: Likewise.
* config/sparc/sparc-protos.h (sparc_flat_expand_prologue): Declare.
(sparc_flat_expand_epilogue): Likewise.
(load_got_register): Likewise.
* config/sparc/sparc.h (CPP_CPU_SPEC): Define _FLAT in flat mode.
(SPARC_INCOMING_INT_ARG_FIRST): Add TARGET_FLAT handling.
(INCOMING_REGNO): Likewise.
(OUTGOING_REGNO): Likewise.
(LOCAL_REGNO): Likewise.
(FIXED_REGISTERS): Set 0 for %fp.
(CALL_USED_REGISTERS): Likewise.
(RETURN_ADDR_REGNUM): Define.
(RETURN_ADDR_RTX): Use it.
(EH_RETURN_HANDLER_RTX): Use it.
(INCOMING_RETURN_ADDR_REGNUM): Define.
(INCOMING_RETURN_ADDR_RTX): Use it.
(DWARF_FRAME_RETURN_COLUMN): Likewise.
(EH_RETURN_REGNUM): Define.
(EH_RETURN_STACKADJ_RTX): Use it.
(EPILOGUE_USES): Use them and add TARGET_FLAT handling.
* config/sparc/sparc.c (struct machine_function): Add frame_size,
apparent_frame_size, frame_base_reg, frame_base_offset, n_regs
and save_local_in_regs_p fields.
(sparc_frame_size, sparc_apparent_frame_size, sparc_frame_base_reg,
sparc_frame_base_offset, sparc_n_regs, sparc_save_local_in_regs_p):
New macros.
(sparc_option_override): Error out if -fcall-saved-REG is specified
for Out registers.
(eligible_for_restore_insn): Fix formatting.
(eligible_for_return_delay): Likewise.  Add TARGET_FLAT handling.
(load_got_register): Make global.
(save_global_or_fp_reg_p): New predicate.
(incoming_return_addr_reg_clobbered_p): Likewise.
(save_local_or_in_reg_p): Likewise.
(sparc_compute_frame_size): Use them.  Add TARGET_FLAT handling.
(SORR_SAVE, SORR_RESTORE): Delete.
(sorr_pred_t): New typedef.
(sorr_act_t): New enum.
(save_or_restore_regs): Rename to...
(emit_save_or_restore): ...this.  Changed type of LOW/HIGH parameters
remove ACTION parameter, add LEAF_FUNCTION_P, SAVE_P, ACTION_TRUE and
ACTION_FALSE parameters.  Implement more general mechanism.  Add CFI
information for double-word saves in 32-bit mode.
(emit_adjust_base_to_offset): New function extracted from...
(emit_save_or_restore_regs): ...this.  Rename the rest to...
(emit_save_or_restore_regs_global_fp_regs): ...this.
(emit_save_or_restore_regs_local_in_regs): New function.
(gen_create_flat_frame_[123]): New functions.
(sparc_expand_prologue): Use SIZE local variable.  Adjust.
(sparc_flat_expand_prologue): New function.
(sparc_asm_function_prologue): Add TARGET_FLAT handling.
(sparc_expand_epilogue): Use SIZE local variable.  Adjust.
(sparc_flat_expand_epilogue): New function.
(sparc_can_use_return_insn_p):  Add TARGET_FLAT handling.
(output_return): Likewise.
(sparc_function_ok_for_sibcall): Likewise.
(sparc_frame_pointer_required): Likewise.
(sparc_can_eliminate): Call sparc_frame_pointer_required directly.
(sparc_conditional_register_usage): If TARGET_FLAT, disable leaf
function optimization.
* config/sparc/sparc.md (flat): New attribute.
(prologue): Add TARGET_FLAT handling.
(epilogue): Likewise.
(sibcall_epilogue): Likewise.
(save_register_window): Disable if TARGET_FLAT.
(create_flat_frame_[123]): New patterns.
(return_internal): Add TARGET_FLAT handling.
(flush_register_windows): Likewise.
(goto_handler_and_restore): Likewise.
(exception_receiver): New pattern.
(builtin_setjmp_receiver): Likewise.


-- 
Eric Botcazou


gcc-4.7-mflat-2.diff.gz
Description: GNU Zip compressed data


[trans-mem] Add documentation

2011-05-26 Thread Torvald Riegel
Patch adds libitm.texi with some documentation, including differences
between our currently targeted ABI and Intel's current ABI
specification.

OK for branch?

Torvald
commit ce12f0535a9eebe02a08b6cb5ef9814132f962f8
Author: Torvald Riegel 
Date:   Thu May 26 21:04:29 2011 +0200

Add documentation.

* libitm.texi: New file.
* Makefile.am: Add libitm.texi.
* Makefile.in: Rebuild.

diff --git a/libitm/Makefile.am b/libitm/Makefile.am
index bf0180d..09c21ff 100644
--- a/libitm/Makefile.am
+++ b/libitm/Makefile.am
@@ -50,3 +50,46 @@ libitm_la_SOURCES += x86_sse.cc x86_avx.cc
 x86_sse.lo : XCFLAGS += -msse
 x86_avx.lo : XCFLAGS += -mavx
 endif
+
+
+# Automake Documentation:
+# If your package has Texinfo files in many directories, you can use the
+# variable TEXINFO_TEX to tell Automake where to find the canonical
+# `texinfo.tex' for your package. The value of this variable should be
+# the relative path from the current `Makefile.am' to `texinfo.tex'.
+TEXINFO_TEX   = ../gcc/doc/include/texinfo.tex
+
+# Defines info, dvi, pdf and html targets
+MAKEINFOFLAGS = -I $(srcdir)/../gcc/doc/include
+info_TEXINFOS = libitm.texi
+
+# AM_CONDITIONAL on configure option --generated-files-in-srcdir
+if GENINSRC
+STAMP_GENINSRC = stamp-geninsrc
+else
+STAMP_GENINSRC =
+endif
+
+# AM_CONDITIONAL on configure check ACX_CHECK_PROG_VER([MAKEINFO])
+if BUILD_INFO
+STAMP_BUILD_INFO = stamp-build-info
+else
+STAMP_BUILD_INFO =
+endif
+
+
+all-local: $(STAMP_GENINSRC)
+
+stamp-geninsrc: libitm.info
+   cp -p $(top_builddir)/libitm.info $(srcdir)/libitm.info
+   @touch $@
+
+libitm.info: $(STAMP_BUILD_INFO)
+
+stamp-build-info: libitm.texi
+   $(MAKEINFO) $(AM_MAKEINFOFLAGS) $(MAKEINFOFLAGS) -I $(srcdir) -o 
libitm.info $(srcdir)/libitm.texi
+   @touch $@
+
+
+CLEANFILES = $(STAMP_GENINSRC) $(STAMP_BUILD_INFO) libitm.info
+MAINTAINERCLEANFILES = $(srcdir)/libitm.info
diff --git a/libitm/Makefile.in b/libitm/Makefile.in
index 8fc3106..57f76f6 100644
--- a/libitm/Makefile.in
+++ b/libitm/Makefile.in
@@ -87,21 +87,20 @@ am__nobase_list = $(am__nobase_strip_setup); \
 am__base_list = \
   sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
   sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
-am__installdirs = "$(DESTDIR)$(toolexeclibdir)" \
+am__installdirs = "$(DESTDIR)$(toolexeclibdir)" "$(DESTDIR)$(infodir)" \
"$(DESTDIR)$(toolexeclibdir)"
 LTLIBRARIES = $(toolexeclib_LTLIBRARIES)
 libitm_la_LIBADD =
 am__libitm_la_SOURCES_DIST = aatree.cc alloc.cc alloc_c.cc \
alloc_cpp.cc barrier.cc beginend.cc clone.cc cacheline.cc \
-   cachepage.cc eh_cpp.cc local.cc query.cc \
-   retry.cc rwlock.cc useraction.cc util.cc sjlj.S tls.cc \
-   method-serial.cc x86_sse.cc 86_avx.cc
+   cachepage.cc eh_cpp.cc local.cc query.cc retry.cc rwlock.cc \
+   useraction.cc util.cc sjlj.S tls.cc method-serial.cc \
+   x86_sse.cc x86_avx.cc
 @ARCH_X86_TRUE@am__objects_1 = x86_sse.lo x86_avx.lo
 am_libitm_la_OBJECTS = aatree.lo alloc.lo alloc_c.lo alloc_cpp.lo \
barrier.lo beginend.lo clone.lo cacheline.lo cachepage.lo \
-   eh_cpp.lo local.lo query.lo retry.lo \
-   rwlock.lo useraction.lo util.lo sjlj.lo tls.lo \
-   method-serial.lo $(am__objects_1)
+   eh_cpp.lo local.lo query.lo retry.lo rwlock.lo useraction.lo \
+   util.lo sjlj.lo tls.lo method-serial.lo $(am__objects_1)
 libitm_la_OBJECTS = $(am_libitm_la_OBJECTS)
 DEFAULT_INCLUDES = -I.@am__isrc@
 depcomp = $(SHELL) $(top_srcdir)/../depcomp
@@ -138,6 +137,18 @@ MULTIDIRS =
 MULTISUBDIR = 
 MULTIDO = true
 MULTICLEAN = true
+INFO_DEPS = libitm.info
+am__TEXINFO_TEX_DIR = $(srcdir)/../gcc/doc/include
+DVIS = libitm.dvi
+PDFS = libitm.pdf
+PSS = libitm.ps
+HTMLS = libitm.html
+TEXINFOS = libitm.texi
+TEXI2DVI = texi2dvi
+TEXI2PDF = $(TEXI2DVI) --pdf --batch
+MAKEINFOHTML = $(MAKEINFO) --html
+AM_MAKEINFOHTMLFLAGS = $(AM_MAKEINFOFLAGS)
+DVIPS = dvips
 RECURSIVE_TARGETS = all-recursive check-recursive dvi-recursive \
html-recursive info-recursive install-data-recursive \
install-dvi-recursive install-exec-recursive \
@@ -357,14 +368,34 @@ libitm_la_LDFLAGS = $(libitm_version_info) 
$(libitm_version_script) \
 
 libitm_la_SOURCES = aatree.cc alloc.cc alloc_c.cc alloc_cpp.cc \
barrier.cc beginend.cc clone.cc cacheline.cc cachepage.cc \
-   eh_cpp.cc local.cc query.cc retry.cc \
-   rwlock.cc useraction.cc util.cc sjlj.S tls.cc method-serial.cc \
-   $(am__append_1)
+   eh_cpp.cc local.cc query.cc retry.cc rwlock.cc useraction.cc \
+   util.cc sjlj.S tls.cc method-serial.cc $(am__append_1)
+
+# Automake Documentation:
+# If your package has Texinfo files in many directories, you can use the
+# variable TEXINFO_TEX to tell Automake where to find the canonical
+# `texinfo.tex' for your package. The value of this variable should be
+# the relative path from the current `Makefile.am' to `texinfo.tex'.
+TEXINFO_TEX = ../gcc/doc/include/texinfo.tex
+
+# Defines info, d

Re: PING: PATCH: PR rtl-optimization/48575: RTL vector patterns are limited to 26 elements

2011-05-26 Thread Richard Sandiford
Bernd Schmidt  writes:
> On 05/25/2011 08:33 PM, Richard Sandiford wrote:
>> +subpos2_ptr = &pos->xvecexp0s;
>>  for (j = 0; j < XVECLEN (pattern, i); j++)
>>{
>> +subpos2 = next_position (subpos2_ptr, pos, POS_XVECEXP0, j);
>>  sub = add_to_sequence (XVECEXP (pattern, i, j),
>> -   &sub->success, subpos, insn_type, 0);
>> +   &sub->success, subpos2, insn_type, 0);
>> +subpos2_ptr = &subpos2->next;
>
> Let me see if I understand this correctly. If *subpos2_ptr is NULL,
> we'll create a new structure, otherwise we'll return the one that's
> already there. Hence, we can go through this loop multiple times and
> never create new position structures that aren't unique.

Right.

> If that's how it's supposed to work, it's quite clever but also a bit
> nonobvious. I think the patch is OK with one or two more comments.

OK, thanks, here's what I installed.  I added a bit more commentary
to the list head fields and to the next_position function.

Richard


gcc/
PR rtl-optimization/48575
* genrecog.c (position_type): New enum.
(position): New structure.
(decision): Use position structure instead of a string.
(root_pos, peep2_insn_pos_list): New variables.
(next_position, compare_positions): New functions.
(new_decision): Use position structures instead of strings.
(maybe_both_true): Likewise.
(change_state): Likewise.
(write_tree): Likewise.
(make_insn_sequence): Likewise.

Index: gcc/genrecog.c
===
--- gcc/genrecog.c  2011-05-25 19:41:57.0 +0100
+++ gcc/genrecog.c  2011-05-26 20:10:19.0 +0100
@@ -62,6 +62,49 @@
 #define OUTPUT_LABEL(INDENT_STRING, LABEL_NUMBER) \
   printf("%sL%d: ATTRIBUTE_UNUSED_LABEL\n", (INDENT_STRING), (LABEL_NUMBER))
 
+/* Ways of obtaining an rtx to be tested.  */
+enum position_type {
+  /* PATTERN (peep2_next_insn (ARG)).  */
+  POS_PEEP2_INSN,
+
+  /* XEXP (BASE, ARG).  */
+  POS_XEXP,
+
+  /* XVECEXP (BASE, 0, ARG).  */
+  POS_XVECEXP0
+};
+
+/* The position of an rtx relative to X0.  Each useful position is
+   represented by exactly one instance of this structure.  */
+struct position
+{
+  /* The parent rtx.  This is the root position for POS_PEEP2_INSNs.  */
+  struct position *base;
+
+  /* A position with the same BASE and TYPE, but with the next value
+ of ARG.  */
+  struct position *next;
+
+  /* A list of all POS_XEXP positions that use this one as their base,
+ chained by NEXT fields.  The first entry represents XEXP (this, 0),
+ the second represents XEXP (this, 1), and so on.  */
+  struct position *xexps;
+
+  /* A list of POS_XVECEXP0 positions that use this one as their base,
+ chained by NEXT fields.  The first entry represents XVECEXP (this, 0, 0),
+ the second represents XVECEXP (this, 0, 1), and so on.  */
+  struct position *xvecexp0s;
+
+  /* The type of position.  */
+  enum position_type type;
+
+  /* The argument to TYPE (shown as ARG in the position_type comments).  */
+  int arg;
+
+  /* The depth of this position, with 0 as the root.  */
+  int depth;
+};
+
 /* A listhead of decision trees.  The alternatives to a node are kept
in a doubly-linked list so we can easily add nodes to the proper
place when merging.  */
@@ -132,7 +175,7 @@ struct decision
   struct decision *afterward;  /* Node to test on success,
   but failure of successor nodes.  */
 
-  const char *position;/* String denoting position in pattern. 
 */
+  struct position *position;   /* Position in pattern.  */
 
   struct decision_test *tests; /* The tests for this node.  */
 
@@ -170,9 +213,16 @@ #define IS_SPLIT(X) ((X) != RECOG)
 
 /* The line number of the start of the pattern currently being processed.  */
 static int pattern_lineno;
+
+/* The root position (x0).  */
+static struct position root_pos;
+
+/* A list of all POS_PEEP2_INSNs.  The entry for insn 0 is the root position,
+   since we are given that instruction's pattern as x0.  */
+static struct position *peep2_insn_pos_list = &root_pos;
 
 static struct decision *new_decision
-  (const char *, struct decision_head *);
+  (struct position *, struct decision_head *);
 static struct decision_test *new_decision_test
   (enum decision_type, struct decision_test ***);
 static rtx find_operand
@@ -182,7 +232,7 @@ #define IS_SPLIT(X) ((X) != RECOG)
 static void validate_pattern
   (rtx, rtx, rtx, int);
 static struct decision *add_to_sequence
-  (rtx, struct decision_head *, const char *, enum routine_type, int);
+  (rtx, struct decision_head *, struct position *, enum routine_type, int);
 
 static int maybe_both_true_2
   (struct decision_test *, struct decision_test *);
@@ -210,7 +260,7 @@ #define IS_SPLIT(X) ((X) != RECOG)
   (struct decision_head *, struct dec

Re: [PATCH] Remove bogus fold code

2011-05-26 Thread H.J. Lu
On Thu, May 26, 2011 at 6:50 AM, Richard Guenther  wrote:
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
>
> Richard.
>
> 2011-05-26  Richard Guenther  
>
>        * fold-const.c (fold_unary_loc): Remove bogus code.
>

This caused:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49177

-- 
H.J.


Re: Reintroduce -mflat option on SPARC

2011-05-26 Thread Laurent Rougé
Dear Eric,

In fact, I haven't tried to make big changes in how mflat option was
implemented. From my point of view, the goal was to facilitate mflat
option reintroduction first, and then improve it after. I hope you
understand. I know there's some place to improve, maybe you have start
to do it ?

So why mflat is like that we should ask the questions to 'wilson' who
did it in 92 (see revision 1275) !

Regards,
Laurent.

Le 18/05/2011 12:31, Eric Botcazou a écrit :
>> Another question: why does the model hijack %i7 to use it as frame pointer,
>> instead of just using %fp?  AFAICS both are kept as fixed registers by the
>> code so the model seems to be wasting 1 register (2 without frame pointer).
> Related question: why saving the Local and In registers in the frame instead 
> of 
> at their standard location, right above the stack pointer?  It would seem to 
> me that the layout of the frame can be identical to the standard one.



Re: [C++ Patch] PR 42056

2011-05-26 Thread Paolo Carlini

On 05/26/2011 08:30 PM, Paolo Carlini wrote:
...also, not returning error_mark_node unconditionally, means a better 
diagnostic, without redundant "array bound is not an integer constant 
before...".
Just noticed that outside a template, we do indeed emit the additional 
"array bound is not an integer constant before..." message. If we want 
it, I have just to return error_mark_node unconditionally. Just let me know.


Paolo.


Re: [C++0x] contiguous bitfields race implementation

2011-05-26 Thread Aldy Hernandez



What padding? bitregion_end-bitregion_start+1 will be 32, but in


Poop, I misread your example.


get_best_mode I see


+ maxbits = bitregion_end - bitpos + 1;


which is 28. No?


Yes, but if you look at the next few lines you'll see:

  /* Find the narrowest integer mode that contains the bit field.  */
  for (mode = GET_CLASS_NARROWEST_MODE (MODE_INT); mode != VOIDmode;
   mode = GET_MODE_WIDER_MODE (mode))
{
  unit = GET_MODE_BITSIZE (mode);
  if ((bitpos % unit) + bitsize <= unit)
break;
}

The narrowest integer mode containing the bit field is still 32, so we 
access the bitfield with an SI instruction as expected.



Incidentally, I would expect _end to be one past the end rather than the
index of the last element, but perhaps I just expect that because C++
iterators work that way.


I can fix that.

Aldy


[pph] Move code (issue4517108)

2011-05-26 Thread Lawrence Crowl
Move TEMPLATE_DECL case next to other DECLs in pph_stream_read_tree
and pph_stream_write_tree.  Move pph_output_chain_filtered to just
before its use.


Index: gcc/cp/ChangeLog.pph

2011-05-26  Lawrence Crowl  

* pph-streamer-in.c (pph_stream_read_tree): Move TEMPLATE_DECL case
next to other DECLs.
* pph-streamer-out.c (pph_stream_write_tree): Move TEMPLATE_DECL case
next to other DECLs.
(pph_output_chain_filtered):  Move to just before its use.


Index: gcc/cp/pph-streamer-in.c
===
--- gcc/cp/pph-streamer-in.c(revision 174301)
+++ gcc/cp/pph-streamer-in.c(working copy)
@@ -837,6 +837,14 @@ pph_stream_read_tree (struct lto_input_b
   DECL_ORIGINAL_TYPE (expr) = pph_input_tree (stream);
   break;
 
+case TEMPLATE_DECL:
+  DECL_INITIAL (expr) = pph_input_tree (stream);
+  pph_stream_read_lang_specific (stream, expr);
+  DECL_TEMPLATE_RESULT (expr) = pph_input_tree (stream);
+  DECL_TEMPLATE_PARMS (expr) = pph_input_tree (stream);
+  DECL_CONTEXT (expr) = pph_input_tree (stream);
+  break;
+
 case STATEMENT_LIST:
   {
 HOST_WIDE_INT i, num_trees = pph_input_uint (stream);
@@ -894,14 +902,6 @@ pph_stream_read_tree (struct lto_input_b
   BASELINK_ACCESS_BINFO (expr) = pph_input_tree (stream);
   break;
 
-case TEMPLATE_DECL:
-  DECL_INITIAL (expr) = pph_input_tree (stream);
-  pph_stream_read_lang_specific (stream, expr);
-  DECL_TEMPLATE_RESULT (expr) = pph_input_tree (stream);
-  DECL_TEMPLATE_PARMS (expr) = pph_input_tree (stream);
-  DECL_CONTEXT (expr) = pph_input_tree (stream);
-  break;
-
 case TEMPLATE_INFO:
   TI_TYPEDEFS_NEEDING_ACCESS_CHECKING (expr)
   = pph_stream_read_qual_use_vec (stream);
Index: gcc/cp/pph-streamer-out.c
===
--- gcc/cp/pph-streamer-out.c   (revision 174301)
+++ gcc/cp/pph-streamer-out.c   (working copy)
@@ -378,6 +378,55 @@ pph_stream_write_label_binding (pph_stre
 }
 
 
+/* Output a chain of nodes to STREAM starting with FIRST.  Skip any
+   nodes that do not match FILTER.  REF_P is true if nodes in the chain
+   should be emitted as references.  */
+
+void
+pph_output_chain_filtered (pph_stream *stream, tree first, bool ref_p,
+  enum chain_filter filter)
+{
+  unsigned count;
+  tree t;
+
+  /* Special case.  If the caller wants no filtering, it is much
+ faster to just call pph_output_chain directly.  */
+  if (filter == NONE)
+{
+  pph_output_chain (stream, first, ref_p);
+  return;
+}
+
+  /* Count all the nodes that match the filter.  */
+  for (t = first, count = 0; t; t = TREE_CHAIN (t))
+{
+  if (filter == NO_BUILTINS && DECL_P (t) && DECL_IS_BUILTIN (t))
+   continue;
+  count++;
+}
+  pph_output_uint (stream, count);
+
+  /* Output all the nodes that match the filter.  */
+  for (t = first; t; t = TREE_CHAIN (t))
+{
+  tree saved_chain;
+
+  /* Apply filters to T.  */
+  if (filter == NO_BUILTINS && DECL_P (t) && DECL_IS_BUILTIN (t))
+   continue;
+
+  /* Clear TREE_CHAIN to avoid blindly recursing into the rest
+of the list.  */
+  saved_chain = TREE_CHAIN (t);
+  TREE_CHAIN (t) = NULL_TREE;
+
+  pph_output_tree_or_ref_1 (stream, t, ref_p, 2);
+
+  TREE_CHAIN (t) = saved_chain;
+}
+}
+
+
 /* Write all the fields of cp_binding_level instance BL to STREAM.  If
REF_P is true, tree fields will be written as references.  */
 
@@ -838,6 +887,14 @@ pph_stream_write_tree (struct output_blo
   pph_output_tree_or_ref_1 (stream, DECL_ORIGINAL_TYPE (expr), ref_p, 3);
   break;
 
+case TEMPLATE_DECL:
+  pph_output_tree_or_ref_1 (stream, DECL_INITIAL (expr), ref_p, 3);
+  pph_stream_write_lang_specific (stream, expr, ref_p);
+  pph_output_tree_or_ref_1 (stream, DECL_TEMPLATE_RESULT (expr), ref_p, 3);
+  pph_output_tree_or_ref_1 (stream, DECL_TEMPLATE_PARMS (expr), ref_p, 3);
+  pph_output_tree_or_ref_1 (stream, DECL_CONTEXT (expr), ref_p, 3);
+  break;
+
 case STATEMENT_LIST:
   {
 tree_stmt_iterator i;
@@ -901,14 +958,6 @@ pph_stream_write_tree (struct output_blo
   pph_output_tree_or_ref_1 (stream, BASELINK_ACCESS_BINFO (expr), ref_p, 
3);
   break;
 
-case TEMPLATE_DECL:
-  pph_output_tree_or_ref_1 (stream, DECL_INITIAL (expr), ref_p, 3);
-  pph_stream_write_lang_specific (stream, expr, ref_p);
-  pph_output_tree_or_ref_1 (stream, DECL_TEMPLATE_RESULT (expr), ref_p, 3);
-  pph_output_tree_or_ref_1 (stream, DECL_TEMPLATE_PARMS (expr), ref_p, 3);
-  pph_output_tree_or_ref_1 (stream, DECL_CONTEXT (expr), ref_p, 3);
-  break;
-
 case TEMPLATE_INFO:
   pph_stream_write_qual_use_vec (stream,
   TI_TYPEDEFS_NEEDING_ACCESS_CHECKING (expr), ref_p);
@@ -925,52 +974,3 @@ pph_stream_write_tree

[C++ Patch] PR 42056

2011-05-26 Thread Paolo Carlini

Hi,

I have just regtested on x86_64-linux the below patchlet for a simple 
accepts-invalid, exploiting type_uses_auto, as suggested by Jason.


We want to do that only when processing a template, because otherwise we 
get a duplicate diagnostic, see, eg, auto9.C; also, not returning 
error_mark_node unconditionally, means a better diagnostic, without 
redundant "array bound is not an integer constant before...". As for the 
error message itself, I'm just emitting what we otherwise emit outside 
templates...


Ok?

Thanks,
Paolo.

///
/cp
2011-05-26  Paolo Carlini  

PR c++/42056
* typeck2.c (build_functional_cast): When processing_template_decl,
check for invalid uses of 'auto'.

/testsuite
2011-05-26  Paolo Carlini  

PR c++/42056
* testsuite/g++.dg/cpp0x/auto25.C: New.
* testsuite/g++.dg/cpp0x/auto26.C: Likewise.
Index: testsuite/g++.dg/cpp0x/auto25.C
===
--- testsuite/g++.dg/cpp0x/auto25.C (revision 0)
+++ testsuite/g++.dg/cpp0x/auto25.C (revision 0)
@@ -0,0 +1,7 @@
+// PR c++/42056
+// { dg-options -std=c++0x }
+
+template struct A
+{
+  int a[auto(1)]; // { dg-error "invalid use of" }
+};
Index: testsuite/g++.dg/cpp0x/auto26.C
===
--- testsuite/g++.dg/cpp0x/auto26.C (revision 0)
+++ testsuite/g++.dg/cpp0x/auto26.C (revision 0)
@@ -0,0 +1,7 @@
+// PR c++/42056
+// { dg-options -std=c++0x }
+
+template void foo()
+{
+  int a[auto(1)]; // { dg-error "invalid use of" }
+}
Index: cp/typeck2.c
===
--- cp/typeck2.c(revision 174301)
+++ cp/typeck2.c(working copy)
@@ -1603,6 +1603,14 @@ build_functional_cast (tree exp, tree parms, tsubs
 {
   tree t;
 
+  if (type_uses_auto (type))
+   {
+ if (complain & tf_error)
+   error ("invalid use of %");
+ else
+   return error_mark_node;
+   }
+
   /* Diagnose this even in a template.  We could also try harder
 to give all the usual errors when the type and args are
 non-dependent...  */


C++ PATCH for c++/48211 (ICE in gc code)

2011-05-26 Thread Jason Merrill
The problem in this PR was that we had a cxx_binding embedded in another 
object and then put a pointer to the cxx_binding in another gc-able 
object.  So when GC ran we tried to mark the cxx_binding and crash, 
because it wasn't allocated separately.


Conveniently, the fix to allocate it separately makes the code simpler.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit 47d35e93b23a66a5bb43614875c7ad772e2eb4c5
Author: Jason Merrill 
Date:   Thu May 26 12:59:47 2011 -0400

	PR c++/48211
	* name-lookup.h (cp_class_binding): Make base a pointer.
	* name-lookup.c (new_class_binding): Adjust.
	(poplevel_class): Adjust.

diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
index bb6d4b9..935dd2a 100644
--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -319,33 +319,11 @@ new_class_binding (tree name, tree value, tree type, cxx_scope *scope)
   cp_class_binding *cb;
   cxx_binding *binding;
 
-  if (VEC_length (cp_class_binding, scope->class_shadowed))
-{
-  cp_class_binding *old_base;
-  old_base = VEC_index (cp_class_binding, scope->class_shadowed, 0);
-  if (VEC_reserve (cp_class_binding, gc, scope->class_shadowed, 1))
-	{
-	  /* Fixup the current bindings, as they might have moved.  */
-	  size_t i;
-
-	  FOR_EACH_VEC_ELT (cp_class_binding, scope->class_shadowed, i, cb)
-	{
-	  cxx_binding **b;
-	  b = &IDENTIFIER_BINDING (cb->identifier);
-	  while (*b != &old_base[i].base)
-		b = &((*b)->previous);
-	  *b = &cb->base;
-	}
-	}
-  cb = VEC_quick_push (cp_class_binding, scope->class_shadowed, NULL);
-}
-  else
 cb = VEC_safe_push (cp_class_binding, gc, scope->class_shadowed, NULL);
 
   cb->identifier = name;
-  binding = &cb->base;
+  cb->base = binding = cxx_binding_make (value, type);
   binding->scope = scope;
-  cxx_binding_init (binding, value, type);
   return binding;
 }
 
@@ -2725,7 +2703,10 @@ poplevel_class (void)
   if (level->class_shadowed)
 {
   FOR_EACH_VEC_ELT (cp_class_binding, level->class_shadowed, i, cb)
-	IDENTIFIER_BINDING (cb->identifier) = cb->base.previous;
+	{
+	  IDENTIFIER_BINDING (cb->identifier) = cb->base->previous;
+	  cxx_binding_free (cb->base);
+	}
   ggc_free (level->class_shadowed);
   level->class_shadowed = NULL;
 }
diff --git a/gcc/cp/name-lookup.h b/gcc/cp/name-lookup.h
index 4bf253f..3309f0a 100644
--- a/gcc/cp/name-lookup.h
+++ b/gcc/cp/name-lookup.h
@@ -140,7 +140,7 @@ typedef enum tag_scope {
 } tag_scope;
 
 typedef struct GTY(()) cp_class_binding {
-  cxx_binding base;
+  cxx_binding *base;
   /* The bound name.  */
   tree identifier;
 } cp_class_binding;


Re: [Patch, Fortran] -fcoarray=lib - add registering calls for nonallocatable coarrays

2011-05-26 Thread Paul Richard Thomas
> However, I forgot the [*]  (or [3,*] or ...). Fortunately, you
> have spotted the sematically relevant typo!
>

;-)

Paul


Re: [PATCH][4.6] detect C++ errors to fix 2288 and 18770

2011-05-26 Thread Jason Merrill

OK for 4.7.

Jason


Re: [C++0x] contiguous bitfields race implementation

2011-05-26 Thread Jason Merrill

On 05/26/2011 01:39 PM, Aldy Hernandez wrote:

On 05/26/11 12:24, Jason Merrill wrote:

struct A
{
  int i: 4;
  int j: 28;
};

we won't use SImode to access A::j because we're setting maxbits to 28.


No, maxbits is actually 32, because we include padding. So it's correct
in this case.


What padding?  bitregion_end-bitregion_start+1 will be 32, but in 
get_best_mode I see



+maxbits = bitregion_end - bitpos + 1;


which is 28.  No?

Incidentally, I would expect _end to be one past the end rather than the 
index of the last element, but perhaps I just expect that because C++ 
iterators work that way.


Jason


Re: PATCH: Add pause intrinsic

2011-05-26 Thread Andi Kleen
> Relax?  Weird.  "Pause" is just as weird.  It might be an ia32 instruction, 
> so as an ia32 builtin it is a reasonable name  But if you want a generic 
> builtin, you need a name that actually has some plausible connection with 
> what it does, and neither "pause" nor "relax" do that.

It's a short pause for the CPU. Both names fit quite well.

-Andi


Re: [PATCH] More pow(x,c) expansions in cse_sincos pass (PR46728, patch 3)

2011-05-26 Thread Joseph S. Myers
On Thu, 26 May 2011, William J. Schmidt wrote:

> +  /* Optimize pow(x,1./3.) = cbrt(x).  This is always safe.  */

No, it's not always safe.  1./3. isn't exactly representable; if x is 
negative (and finite), the correct value of the LHS is a NaN (with the 
"invalid" exception raised) because the value of 1./3. actually has an 
even denominator, whereas the correct value of the RHS is a negative real 
value.

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


Re: [PATCH] More pow(x,c) expansions in cse_sincos pass (PR46728, patch 3)

2011-05-26 Thread William J. Schmidt

On Thu, 2011-05-26 at 11:22 +0200, Richard Guenther wrote:




> There are several extra pre-conditions in the original code in
> builtins.c as well as commens for reasonings (yes, there seem
> to be duplicates of several of the transforms there ...).  Please
> try to preserve them.  I noticed especially
> 
>   /* Optimize pow (x, 0.25) into sqrt (sqrt (x)).  Assume on most
>  machines that a builtin sqrt instruction is smaller than a
>  call to pow with 0.25, so do this optimization even if
>  -Os.  */
> 
> and
> 
>   /* Check whether we can do cbrt insstead of pow (x, 1./3.) and
>  cbrt/sqrts instead of pow (x, 1./6.).  */
>   if (cbrtfn && ! op
>   && (tree_expr_nonnegative_p (arg0) || !HONOR_NANS (mode)))
> 
> where you omit the non-negative check and the check for NANs.
> Note that -funsafe-math-optimizations does not mean you can
> ignore nans or signed zero issues.  pow(x,1/3) -> cbrt(x) does not
> need a -funsafe-math-optimization check either.

OK.  Good catch on the non-negative/NaN check -- that just slipped
through the cracks.  I've fixed this and beefed up the comments as you
suggest.

> 
> It would be nice if you could re-arrange this function so that before
> each individual replacement all preconditions are checked (even if
> that means duplicating some checks and code) - that way
> reviewing and later maintainance should be much easier.
> 

Done -- you're right, the result is much cleaner.  Hopefully this
version is easier to follow.

Thanks, 
Bill


2011-05-25  Bill Schmidt  

PR tree-optimization/46728
* tree-ssa-math-opts.c (powi_as_mults_1): Add gimple_set_location.
(powi_as_mults): Add gimple_set_location.
(build_and_insert_call): New.
(gimple_expand_builtin_pow): Add handling for pow(x,y) when y is
0.5, 0.25, 0.75, 1./3., or 1./6.


Index: gcc/tree-ssa-math-opts.c
===
--- gcc/tree-ssa-math-opts.c(revision 174199)
+++ gcc/tree-ssa-math-opts.c(working copy)
@@ -965,6 +965,7 @@ powi_as_mults_1 (gimple_stmt_iterator *gsi, locati
 }
 
   mult_stmt = gimple_build_assign_with_ops (MULT_EXPR, ssa_target, op0, op1);
+  gimple_set_location (mult_stmt, loc);
   gsi_insert_before (gsi, mult_stmt, GSI_SAME_STMT);
 
   return ssa_target;
@@ -999,6 +1000,7 @@ powi_as_mults (gimple_stmt_iterator *gsi, location
   div_stmt = gimple_build_assign_with_ops (RDIV_EXPR, target, 
   build_real (type, dconst1),
   result);
+  gimple_set_location (div_stmt, loc);
   gsi_insert_before (gsi, div_stmt, GSI_SAME_STMT);
 
   return target;
@@ -1024,6 +1026,34 @@ gimple_expand_builtin_powi (gimple_stmt_iterator *
   return NULL_TREE;
 }
 
+/* Build a gimple call statement that calls FN with argument ARG.
+   Set the lhs of the call statement to a fresh SSA name for
+   variable VAR.  If VAR is NULL, first allocate it.  Insert the
+   statement prior to GSI's current position, and return the fresh
+   SSA name.  */
+
+static tree
+build_and_insert_call (gimple_stmt_iterator *gsi, tree fn, tree arg,
+  tree *var, location_t loc)
+{
+  gimple call_stmt;
+  tree ssa_target;
+
+  if (!*var)
+{
+  *var = create_tmp_var (TREE_TYPE (arg), "powroot");
+  add_referenced_var (*var);
+}
+
+  call_stmt = gimple_build_call (fn, 1, arg);
+  ssa_target = make_ssa_name (*var, NULL);
+  gimple_set_lhs (call_stmt, ssa_target);
+  gimple_set_location (call_stmt, loc);
+  gsi_insert_before (gsi, call_stmt, GSI_SAME_STMT);
+
+  return ssa_target;
+}
+
 /* ARG0 and ARG1 are the two arguments to a pow builtin call in GSI
with location info LOC.  If possible, create an equivalent and
less expensive sequence of statements prior to GSI, and return an
@@ -1033,16 +1063,21 @@ static tree
 gimple_expand_builtin_pow (gimple_stmt_iterator *gsi, location_t loc, 
   tree arg0, tree arg1)
 {
-  REAL_VALUE_TYPE c, cint;
+  REAL_VALUE_TYPE c, cint, dconst1_4, dconst3_4, dconst1_3, dconst1_6;
   HOST_WIDE_INT n;
+  tree type, sqrtfn, cbrtfn, sqrt_arg0, sqrt_sqrt, ssa_target;
+  tree target = NULL_TREE;
+  enum machine_mode mode;
+  bool hw_sqrt_exists;
+  gimple mult_stmt;
 
   /* If the exponent isn't a constant, there's nothing of interest
  to be done.  */
   if (TREE_CODE (arg1) != REAL_CST)
 return NULL_TREE;
 
-  /* If the exponent is equivalent to an integer, expand it into
- multiplies when profitable.  */
+  /* If the exponent is equivalent to an integer, expand to an optimal
+ multiplication sequence when profitable.  */
   c = TREE_REAL_CST (arg1);
   n = real_to_integer (&c);
   real_from_integer (&cint, VOIDmode, n, n < 0 ? -1 : 0, 0);
@@ -1054,6 +1089,97 @@ gimple_expand_builtin_pow (gimple_stmt_iterator *g
  && powi_cost (n) <= POWI_MAX_MULTS)))
 

Re: PATCH: Add pause intrinsic

2011-05-26 Thread Paul Koning

On May 26, 2011, at 1:37 PM, Andi Kleen wrote:

> On Thu, May 26, 2011 at 06:46:39PM +0200, Jakub Jelinek wrote:
>> On Thu, May 26, 2011 at 09:10:32AM -0700, Andi Kleen wrote:
>>> Richard Guenther  writes:
>>> As for why having a builtin: one reason would be portability.
>> 
>> You mean portability to other compilers (I think reasonable amount
>> of them support gcc-ish inline asm), or to other architectures?
> 
> Both.
> 
>> __builtin_ia32_pause () doesn't look like a builtin you would
>> want to use on PPC.
> 
> That's true, it should probably have a different name.
> 
> __builtin_pause()? 
> 
> The Linux kernel calls it cpu_relax() on all architectures.
> The following architectures implement it: ia64, powerpc, x86
> On others it just acts like a barrier.

Relax?  Weird.  "Pause" is just as weird.  It might be an ia32 instruction, so 
as an ia32 builtin it is a reasonable name  But if you want a generic builtin, 
you need a name that actually has some plausible connection with what it does, 
and neither "pause" nor "relax" do that.

paul




Re: Faster streaming of enums

2011-05-26 Thread Tom Tromey
> "Jan" == Jan Hubicka  writes:

Some typos...

Jan> + /* Pack VAL into BP, be more effetive when VAL is small.
Jan> +Implementation is sily, we may want to do better later.  */

"effective" and "silly".

Jan> + /* Pack VAL into BP, be more effetive when VAL is small.
Jan> +Implementation is sily, we may want to do better later.  */

Ditto.

Jan> + /* Pack VAL into BP, be more effetive when VAL is small.  */

"effective"

Jan> + /* Pack VAL into BP, be more effetive when VAL is small.  */

Ditto.

Tom


Re: [PATCH 18/18] make TS_BLOCK a substructure of TS_BASE

2011-05-26 Thread Nathan Froyd
On Thu, Mar 10, 2011 at 11:23:26PM -0500, Nathan Froyd wrote:
> Now that we've  encapsulated all uses of BLOCK_CHAINON properly, we can
> make BLOCKs inherit from tree_base and redirect BLOCK_CHAINON to use a
> tree_block-private field instead of tree_common's chain.  Doing so saves
> the never-used TREE_TYPE field.

This patch was approved:

http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00564.html
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01844.html

However, during retesting, I hit problems in find_decls_types_r; the
following bit of code doesn't work if your trees don't have TREE_TYPE:

  if (TREE_CODE (t) != IDENTIFIER_NODE)
fld_worklist_push (TREE_TYPE (t), fld);

This didn't show up when I was developing the patch, since the
adjustments to IDENTIFIER_NODE:

http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00561.html

had done:

@@ -4795,7 +4791,8 @@ find_decls_types_r (tree *tp, int *ws, void *data)
   fld_worklist_push (BLOCK_ABSTRACT_ORIGIN (t), fld);
 }
 
-  fld_worklist_push (TREE_TYPE (t), fld);
+  if (CODE_CONTAINS_STRUCT (TREE_CODE (t), TS_TYPED))
+fld_worklist_push (TREE_TYPE (t), fld);
 
   return NULL_TREE;
 }

And the later BLOCK-adjusting made use of that bit.  Given that removing
TREE_TYPE from IDENTIFIER_NODE required more invasive surgery than I'm
qualified to do at this point, that bit (and several others) got
dropped, leading to our present situation.

Since Richi approved the IDENTIFIER_NODE changes, I feel justified in
committing the slightly tweaked patch below.  The relevant bit that
wasn't in the initial mail is:

@@ -4892,7 +4892,8 @@ find_decls_types_r (tree *tp, int *ws, void *data)
   fld_worklist_push (BLOCK_ABSTRACT_ORIGIN (t), fld);
 }
 
-  if (TREE_CODE (t) != IDENTIFIER_NODE)
+  if (TREE_CODE (t) != IDENTIFIER_NODE
+  && CODE_CONTAINS_STRUCT (TREE_CODE (t), TS_TYPED))
 fld_worklist_push (TREE_TYPE (t), fld);
 
   return NULL_TREE;

If people feel that checking TREE_CODE for BLOCK or just 'return'ing
from the BLOCK block just above would be more appropriate, I can commit
that as a followup patch.

Tested on x86_64-unknown-linux-gnu.  Committed as r174300.

-Nathan

gcc/
* tree.c (initialize_tree_contains_struct): Mark TS_BLOCK as
TS_BASE instead of TS_COMMON.
* tree.h (struct tree_block): Inherit from tree_base, not tree_common.
Add chain field.
(BLOCK_CHAIN): Use new chain field.

gcc/c-family/
* c-common.c (warning_candidate_p): Check for BLOCKs.

gcc/java/
* decl.c (poplevel): Don't access TREE_TYPE of BLOCKs.
* expr.c (build_jni_stub): Likewise.

diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 2d4e492..fa7ebc5 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -2367,6 +2367,9 @@ warning_candidate_p (tree x)
   if (DECL_P (x) && DECL_ARTIFICIAL (x))
 return 0;
 
+  if (TREE_CODE (x) == BLOCK)
+return 0;
+
   /* VOID_TYPE_P (TREE_TYPE (x)) is workaround for cp/tree.c
  (lvalue_p) crash on TRY/CATCH. */
   if (TREE_TYPE (x) == NULL_TREE || VOID_TYPE_P (TREE_TYPE (x)))
diff --git a/gcc/java/decl.c b/gcc/java/decl.c
index 47b4ebe..e958136 100644
--- a/gcc/java/decl.c
+++ b/gcc/java/decl.c
@@ -1425,10 +1425,7 @@ poplevel (int keep, int reverse, int functionbody)
 
   block = 0;
   if (keep || functionbody)
-{
-  block = make_node (BLOCK);
-  TREE_TYPE (block) = void_type_node;
-}
+block = make_node (BLOCK);
 
   if (current_binding_level->exception_range)
 expand_end_java_handler (current_binding_level->exception_range);
@@ -1456,7 +1453,7 @@ poplevel (int keep, int reverse, int functionbody)
}
  *var = NULL;

- bind = build3 (BIND_EXPR, TREE_TYPE (block), BLOCK_VARS (block), 
+ bind = build3 (BIND_EXPR, void_type_node, BLOCK_VARS (block), 
 BLOCK_EXPR_BODY (block), block);
  BIND_EXPR_BODY (bind) = current_binding_level->stmts;
  
diff --git a/gcc/java/expr.c b/gcc/java/expr.c
index 3be1cff..b9293e0 100644
--- a/gcc/java/expr.c
+++ b/gcc/java/expr.c
@@ -2649,7 +2649,6 @@ build_jni_stub (tree method)
   method_args = DECL_ARGUMENTS (method);
   block = build_block (env_var, NULL_TREE, method_args, NULL_TREE);
   TREE_SIDE_EFFECTS (block) = 1;
-  TREE_TYPE (block) = TREE_TYPE (TREE_TYPE (method));
 
   /* Compute the local `env' by calling _Jv_GetJNIEnvNewFrame.  */
   body = build2 (MODIFY_EXPR, ptr_type_node, env_var,
diff --git a/gcc/tree.c b/gcc/tree.c
index 1dfad04..d5b5dac 100644
--- a/gcc/tree.c
+++ b/gcc/tree.c
@@ -368,6 +368,7 @@ initialize_tree_contains_struct (void)
   switch (ts_code)
{
case TS_TYPED:
+   case TS_BLOCK:
  MARK_TS_BASE (code);
  break;
 
@@ -389,7 +390,6 @@ initialize_tree_contains_struct (void)
case TS_TYPE_COMMON:
case TS_LIST:
case TS_VEC:
-   case TS_BLOCK:
case TS_BINFO:
case TS_STATEMENT_LIST:
cas

Re: [C++0x] contiguous bitfields race implementation

2011-05-26 Thread Aldy Hernandez

On 05/26/11 12:24, Jason Merrill wrote:

I'm afraid I think this is still wrong; the computation of maxbits in
various places assumes that the bitfield is at the start of the unit
we're going to access, so given

struct A
{
int i: 4;
int j: 28;
};

we won't use SImode to access A::j because we're setting maxbits to 28.


No, maxbits is actually 32, because we include padding.  So it's correct 
in this case.


Re: [PATCH][4.6] detect C++ errors to fix 2288 and 18770

2011-05-26 Thread Peter Bergner
On Wed, 2011-05-25 at 21:24 -0400, Nathan Froyd wrote:
> On Wed, May 25, 2011 at 03:22:07PM -0400, Nathan Froyd wrote:
> > The patch just requires some shuffling of logic to catch issues now;
> > below is a version that works for me on the trunk.
> > 
> > This new checking does require modifying g++.dg/cpp0x/range-for5.C.
> > 
> > Tested with g++ testsuite on x86_64-unknown-linux-gnu; tests in progress
> > for libstdc++.  OK to commit?
> 
> Below is a slightly revised patch that actually adds all the necessary
> dg-error directives to range-for5.C.  Tested the same way; Peter Bergner
> was kind enough to bootstrap and test the previous patch on
> powerpc64-linux-gnu with (almost) clean results as well.

FYI, the revised patch passes bootstrap and regtesting (-m32 and -m64) with
no regressions on powerpc64-linux.

Peter





Re: PATCH: Add pause intrinsic

2011-05-26 Thread Andi Kleen
On Thu, May 26, 2011 at 06:46:39PM +0200, Jakub Jelinek wrote:
> On Thu, May 26, 2011 at 09:10:32AM -0700, Andi Kleen wrote:
> > Richard Guenther  writes:
> > As for why having a builtin: one reason would be portability.
> 
> You mean portability to other compilers (I think reasonable amount
> of them support gcc-ish inline asm), or to other architectures?

Both.

> __builtin_ia32_pause () doesn't look like a builtin you would
> want to use on PPC.

That's true, it should probably have a different name.

__builtin_pause()? 

The Linux kernel calls it cpu_relax() on all architectures.
The following architectures implement it: ia64, powerpc, x86
On others it just acts like a barrier.

I suppose most CPUs that implement SMT will have some equivalent.

-Andi
-- 
a...@linux.intel.com -- Speaking for myself only.


PATCH: PR target/49168: [4.7 Regression] Aligned store used with unaligned address

2011-05-26 Thread H.J. Lu
Hi,

Since we don't have movmisaligntf pattern, we need to handle misaligned
load/store in *movtf_internal, similar to *movti_internal_*.  OK for
trunk?

Thanks.


H.J.
---
gcc/

2011-05-26  H.J. Lu  

PR target/49168
* config/i386/i386.md (*movtf_internal): Handle misaligned
load/store.

gcc/testsuite/

2011-05-26  H.J. Lu  

PR target/49168
 * gcc.target/i386/pr49168-1.c: New.

diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 13a1cde..034cda8 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -2805,10 +2805,23 @@
 {
 case 0:
 case 1:
-  if (get_attr_mode (insn) == MODE_V4SF)
-   return "%vmovaps\t{%1, %0|%0, %1}";
+  /* Handle misaligned load/store since we don't have movmisaligntf
+pattern. */
+  if (misaligned_operand (operands[0], TFmode)
+ || misaligned_operand (operands[1], TFmode))
+   {
+ if (get_attr_mode (insn) == MODE_V4SF)
+   return "%vmovups\t{%1, %0|%0, %1}";
+ else
+   return "%vmovdqu\t{%1, %0|%0, %1}";
+   }
   else
-   return "%vmovdqa\t{%1, %0|%0, %1}";
+   {
+ if (get_attr_mode (insn) == MODE_V4SF)
+   return "%vmovaps\t{%1, %0|%0, %1}";
+ else
+   return "%vmovdqa\t{%1, %0|%0, %1}";
+   }
 
 case 2:
   return standard_sse_constant_opcode (insn, operands[1]);
diff --git a/gcc/testsuite/gcc.target/i386/pr49168-1.c 
b/gcc/testsuite/gcc.target/i386/pr49168-1.c
new file mode 100644
index 000..9676dc8
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr49168-1.c
@@ -0,0 +1,11 @@
+/* PR target/49168  */
+/* { dg-do compile } */
+/* { dg-options "-O2 -msse2 -mtune=generic" } */
+/* { dg-final { scan-assembler-not "movdqa\[\t \]*%xmm\[0-9\]\+,\[^,\]*" } } */
+/* { dg-final { scan-assembler "movdqu\[\t \]*%xmm\[0-9\]\+,\[^,\]*" } } */
+
+void
+flt128_va (void *mem, __float128 d)
+{ 
+  __builtin_memcpy (mem, &d, sizeof (d));
+}


Re: [C++0x] contiguous bitfields race implementation

2011-05-26 Thread Jason Merrill
I'm afraid I think this is still wrong; the computation of maxbits in 
various places assumes that the bitfield is at the start of the unit 
we're going to access, so given


struct A
{
  int i: 4;
  int j: 28;
};

we won't use SImode to access A::j because we're setting maxbits to 28.

Jason


Re: RFA: a patch for PR49154

2011-05-26 Thread Jeff Law
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/25/11 15:27, Vladimir Makarov wrote:
> The following patch solves problem
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49154 for SPARC.  SPARC FPCC
> registers were excluded from pressure classes because the movement
> between them is costly.  Therefore the assert was triggered again. 
> Common logic says that it should be a pressure class because the
> registers are common and that is attributed that the class has no
> subclasses.
> 
> The patch was bootstrapped on x86-64 and teststed on the same targets
> (about 10 of them) + regular SPARC (without soft floating point).
> 
> 
> Ok to commit?
> 
> 2011-05-25  Vladimir Makarov 
> 
> PR rtl-optimization/49154
> * ira.c (setup_pressure_classes): Process class without sublcasses
> as a candidate for pressure classes.
OK
Jeff

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJN3oKyAAoJEBRtltQi2kC767sH/2V5jrDzAt4zDLpS1go78QBq
l03YV1rfy/MG19HBcFcS0rNcGXHUobo0dQxS8woqY75GOmU29HpLuyh5ps6l18gK
YX4gWvbJADnOK9eyFQ0TjdGLAZCx6w4SMcIpUpurYh8e6iFqBUbHEf+KvO5bIhiE
EkXhMcMy3fX/EWmvK7kJWkKGAxYDI3mvyz6RUB0oMlgK1PcW5eW7IQWPXnerHRTi
dNdaVZ6VUiJVPyehKKxfIAsmZM6K0R6q6jYsAGx+ewOtjRq5Vz6gQkAhJKgZ7uGM
747LXBlLRmyS9giGehviqPsep5m5/u2eb/uiVu4ypAGUj7iFeePJY6B1tbiPETA=
=5Ps1
-END PGP SIGNATURE-


[PATCH] ARM fixed-point support [5.5/6]: argument & return padding for libcalls

2011-05-26 Thread Julian Brown
This patch allows padding to be specified per-target for libcalls. This
hasn't been traditionally important, because libcalls haven't accepted
quantities which might need padding, but that's no longer true with the
new(-ish) fixed-point support helper functions.

Tested (alongside other fixed-point support patches) with cross to ARM
EABI in both big & little-endian mode (the target-specific part is to
avoid a behaviour change for half-float types on ARM). OK to apply?

Thanks,

Julian

ChangeLog

gcc/
* calls.c (emit_library_call_value_1): Support padding for libcall
arguments and return values.
* config/arm/arm.c (arm_pad_arg_upward): Pad half-float values
downwards in big-endian mode.commit e3b8b63431fc1d701ac5d3cafd19c24e6d3b5c6e
Author: Julian Brown 
Date:   Thu May 26 09:06:44 2011 -0700

Support target-specific padding for libcalls.

diff --git a/gcc/calls.c b/gcc/calls.c
index 44a16ff..9d5d294 100644
--- a/gcc/calls.c
+++ b/gcc/calls.c
@@ -3794,13 +3794,41 @@ emit_library_call_value_1 (int retval, rtx orgfun, rtx value,
   rtx val = argvec[argnum].value;
   rtx reg = argvec[argnum].reg;
   int partial = argvec[argnum].partial;
-
+  int size = 0;
+  
   /* Handle calls that pass values in multiple non-contiguous
 	 locations.  The PA64 has examples of this for library calls.  */
   if (reg != 0 && GET_CODE (reg) == PARALLEL)
 	emit_group_load (reg, val, NULL_TREE, GET_MODE_SIZE (mode));
   else if (reg != 0 && partial == 0)
-	emit_move_insn (reg, val);
+{
+	  emit_move_insn (reg, val);
+#ifdef BLOCK_REG_PADDING
+	  size = GET_MODE_SIZE (argvec[argnum].mode);
+
+	  /* Copied from load_register_parameters.  */
+
+	  /* Handle case where we have a value that needs shifting
+	 up to the msb.  eg. a QImode value and we're padding
+	 upward on a BYTES_BIG_ENDIAN machine.  */
+	  if (size < UNITS_PER_WORD
+	  && (argvec[argnum].locate.where_pad
+		  == (BYTES_BIG_ENDIAN ? upward : downward)))
+	{
+	  rtx x;
+	  int shift = (UNITS_PER_WORD - size) * BITS_PER_UNIT;
+
+	  /* Assigning REG here rather than a temp makes CALL_FUSAGE
+		 report the whole reg as used.  Strictly speaking, the
+		 call only uses SIZE bytes at the msb end, but it doesn't
+		 seem worth generating rtl to say that.  */
+	  reg = gen_rtx_REG (word_mode, REGNO (reg));
+	  x = expand_shift (LSHIFT_EXPR, word_mode, reg, shift, reg, 1);
+	  if (x != reg)
+		emit_move_insn (reg, x);
+	}
+#endif
+	}
 
   NO_DEFER_POP;
 }
@@ -3866,6 +3894,15 @@ emit_library_call_value_1 (int retval, rtx orgfun, rtx value,
 	   valreg,
 	   old_inhibit_defer_pop + 1, call_fusage, flags, & args_so_far);
 
+  /* Right-shift returned value if necessary.  */
+  if (!pcc_struct_value
+  && TYPE_MODE (tfom) != BLKmode
+  && targetm.calls.return_in_msb (tfom))
+{
+  shift_return_value (TYPE_MODE (tfom), false, valreg);
+  valreg = gen_rtx_REG (TYPE_MODE (tfom), REGNO (valreg));
+}
+
   /* For calls to `setjmp', etc., inform function.c:setjmp_warnings
  that it should complain if nonvolatile values are live.  For
  functions that cannot return, inform flow that control does not
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 7d52b0e..cd32fe3 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -11375,6 +11375,15 @@ arm_pad_arg_upward (enum machine_mode mode, const_tree type)
   if (type && BYTES_BIG_ENDIAN && INTEGRAL_TYPE_P (type))
 return false;
 
+  /* Half-float values are only passed to libcalls, not regular functions.
+ They should be passed and returned as "short"s (see RTABI).  To achieve
+ that effect in big-endian mode, pad downwards so the value is passed in
+ the least-significant end of the register.  ??? This needs to be here
+ rather than in arm_pad_reg_upward due to peculiarity in the handling of
+ libcall arguments.  */
+  if (BYTES_BIG_ENDIAN && mode == HFmode)
+return false;
+
   return true;
 }
 


Re: PATCH: Add pause intrinsic

2011-05-26 Thread Basile Starynkevitch
On Thu, 26 May 2011 09:12:06 -0700
Andi Kleen  wrote:

> Basile Starynkevitch  writes:
> >
> > Perhaps the doc might explain why is it necessary to have a builtin for
> > two independent roles: first, the full compiler memory barrier (which
> > probably means to spill all the registers on the stack - definitely a
> > task for a compiler); second, to "pause" the processor (which might
> > also mean to flush or invalidate some data caches). In particular, I
> > would naively imagine that we might have a more generic builtin for the
> > compiler memory barrier (which probably could be independent of the
> > particular ia32 target), and in that case which can't we just implement
> > the pause ia32 builtin as builtin_compiler_barrier(); asm ("pause")?
> 
> Because a pause() which can be freely moved around is pretty much
> useless. Think about it. And a memory barrier is the standard
> way to prevent moving around in relation to other code.

I thought that there is a syntax, perhaps volatile asm("pause"), which
forbids the compiler to move an asm statement? Or is the "memory" thing? 
(I am not very used to GCC asm).

Still, is there a way to ask GCC to spill all data from registers to
memory, and to require GCC to consider all registers crappy and to
reload them when needed? I would imagine that such a feature is useful,
and most importantly, that it should not be specific to ia32!

Regards.
-- 
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***


Re: [PATCH] ARM fixed-point support [5/6]: make long-long support optional for fixed-point tests

2011-05-26 Thread Julian Brown
On Fri, 13 May 2011 14:58:08 +0100
Julian Brown  wrote:

> This makes makes the requirement for "long long" fixed-point types
> optional in the testsuite (fixed-point.exp tests), since they are
> unsupported by the ARM backend.
> 
> Tested alongside other patches in the series. OK to apply?

This patch is no longer needed with the updated version of:

http://gcc.gnu.org/ml/gcc-patches/2011-05/msg02060.html

Please consider it withdrawn.

Thanks,

Julian


Re: PATCH: Add pause intrinsic

2011-05-26 Thread Jakub Jelinek
On Thu, May 26, 2011 at 09:10:32AM -0700, Andi Kleen wrote:
> Richard Guenther  writes:
> As for why having a builtin: one reason would be portability.

You mean portability to other compilers (I think reasonable amount
of them support gcc-ish inline asm), or to other architectures?
__builtin_ia32_pause () doesn't look like a builtin you would
want to use on PPC.

> Then it also seems cleaner to me to cover the instruction
> set with builtins like the others.

No idea why in this case.  Builtins have the advantage that they
can be better scheduled, but in this case you don't want to move
it around.

Jakub


Re: [PATCH] ARM fixed-point support [6/6]: target-specific parts

2011-05-26 Thread Julian Brown
On Fri, 13 May 2011 17:31:18 +0100
Julian Brown  wrote:

> On Fri, 13 May 2011 14:54:47 + (UTC)
> "Joseph S. Myers"  wrote:
> 
> > On Fri, 13 May 2011, Julian Brown wrote:
> > 
> > > although Joseph's comments have (hopefully) all been addressed.
> > > One must now configure with "--enable-fixed-point" to enable the
> > > fixed-point support.
> > 
> > No, that's not how this configure logic works; it enables fixed
> > point by default for the given targets.  The bit that enables it by
> > default for MIPS (and that you're changing to cover ARM as well) is
> > the code that is called if the user *doesn't* pass
> > --enable-fixed-point or --disable-fixed-point.
> 
> Yes, you're quite right: I had forgotten to run autoconf after
> changing configure.ac whilst testing. Sorry for the misinformation!

This is a new version of the patch, which fixes a couple of issues
discovered on our internal branch since the last version was posted.
This version handles "long long" fixed point types in the same way as
32-bit MIPS: basically the sizes of those types are clamped to 64 bits.

This means the testsuite changes in:

http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00969.html

are no longer required.

Another couple of problems have also been fixed, relating to big-endian
mode. One was the use of simplify_gen_subreg with a hard-wired offset in
a several of the insn expanders, where I should have just used
gen_highpart -- which works in either endianness, and makes the intent
clearer anyway.

The other issue is ABI-related. My previous assertion that fixed-point
types (smaller than word size) should be passed to and returned from
functions "like integers" doesn't really work out very well after all
in big-endian mode, so needs re-thinking. The problem is basically that
such fixed-point types are incorrectly padded in big-endian mode, so
the data ends up in a different part of the passed word than expected.

The way chars and shorts is handled is as follows: when those types are
passed to a function, they are promoted to word-size ints, which is a
nop-op: the values can simply be reinterpreted as ints, and that works
fine in either endianness. We might hope to be able to do the same thing
for smaller-than-word-size fixed-point types, but unfortunately we
can't: e.g. a "short fract" or "fract" can't just be reinterpreted as a
"long fract" (the 32-bit fractional type), because the fixed-point is
in a different place for the wider type (and performing conversions
would itself require libcalls at present). It also doesn't work to
promote small fixed-point types to SImode: as well as being
conceptually messy, we hit ICEs very quickly attempting that.

So instead, I think that small fixed-point types should be handled the
same way as small aggregates or small complex-valued types. This means
effectively no change in little-endian mode, but in big-endian mode:

* for register arguments, fixed-point types are passed in the
  most-significant end of the register.

* for stack arguments, fixed-point types are passed in lower memory
  addresses.

* for return values, fixed-point types are again in the
  most-significant end of the return register (r0).

This is quite easy to set up in the backend code, but unfortunately I
hit a snag in libcall expansion in calls.c: padding of arguments and
return values is not properly supported, as it is for regular function
calls. I've implemented that, and will post it as a separate patch.

OK to apply? Tested alongside the rest of the patch series, in both big
& little-endian mode.

Julian

ChangeLog

gcc/
* configure.ac (fixed-point): Add ARM support.
* configure: Regenerate.
* config/arm/arm.c (arm_fixed_mode_set): New struct.
(arm_set_fixed_optab_libfunc): New.
(arm_set_fixed_conv_libfunc): New.
(arm_init_libfuncs): Initialise fixed-point helper libfuncs with
ARM-specific names.
(aapcs_libcall_value): Return sub-word-size fixed-point libcall
return values in SImode.
(arm_return_in_msb): Return fixed-point types in the msb.
(arm_pad_reg_upwards, arm_pad_arg_upwards): Pad fixed-point types
upwards.
(arm_scalar_mode_supported_p): Support fixed-point modes.
(arm_vector_mode_supported_p): Support vector fixed-point modes.
* config/arm/arm.h (SHORT_FRACT_TYPE_SIZE, FRACT_TYPE_SIZE)
(LONG_FRACT_TYPE_SIZE, LONG_LONG_FRACT_TYPE_SIZE)
(SHORT_ACCUM_TYPE_SIZE, ACCUM_TYPE_SIZE, LONG_ACCUM_TYPE_SIZE)
(LONG_LONG_ACCUM_TYPE_SIZE, MAX_FIXED_MODE_SIZE): Define.
* config/arm/arm-modes.def (FRACT, UFRACT, ACCUM, UACCUM): Declare
vector modes.
* config/arm/predicates.md (sat_shift_operator): New predicate.
* config/arm/arm-fixed.md: New.
* config/arm/arm.md: Include arm-fixed.md.
* config/arm/t-arm (MD_INCLUDES): Add arm-fixed.md.
* config/arm/fixed-bit-machine.h: New.
 
libgcc/
* config.host (arm*-*-linux*, arm*-*-uclinux*, arm*-*-eabi*)
(arm*-*-symbianelf*): Add arm/t-fixed-point makefile fragm

Re: RFC: explicitely mark out-of-scope deaths

2011-05-26 Thread Steven Bosscher
On Thu, May 26, 2011 at 3:43 PM, Michael Matz  wrote:

> on IRC we discussed about this, here's the RFC patch.  It bootstraps and
> causes some minor regressions most probably due to some missing sprinkled
> checks for the special clobber insns and sometimes due to having to adjust
> some regexps.

 Just for reference... I am guessing this also supposed to help fix PR39604?

Ciao!
Steven


Re: PATCH: Add pause intrinsic

2011-05-26 Thread Andi Kleen
Basile Starynkevitch  writes:
>
> Perhaps the doc might explain why is it necessary to have a builtin for
> two independent roles: first, the full compiler memory barrier (which
> probably means to spill all the registers on the stack - definitely a
> task for a compiler); second, to "pause" the processor (which might
> also mean to flush or invalidate some data caches). In particular, I
> would naively imagine that we might have a more generic builtin for the
> compiler memory barrier (which probably could be independent of the
> particular ia32 target), and in that case which can't we just implement
> the pause ia32 builtin as builtin_compiler_barrier(); asm ("pause")?

Because a pause() which can be freely moved around is pretty much
useless. Think about it. And a memory barrier is the standard
way to prevent moving around in relation to other code.

You would always need to combine those too.

-Andi

-- 
a...@linux.intel.com -- Speaking for myself only


Re: PATCH: Add pause intrinsic

2011-05-26 Thread Andi Kleen
Richard Guenther  writes:
>
> To make it a compiler memory barrier you have to "expand" the
> builtin already in the frontend and present the middle-end with
> __asm__ ("" : : : "memory").  That will serve as a compiler

Those are the intended semantics (at least those I asked
for :-). For all practical purposes the same as
asm volatile("pause" ::: "memory")

HJ? Can it be expanded earlier?

As for why having a builtin: one reason would be portability.
Various other architectures have a similar instruction
(e.g. PPC). They could be added later to this as a next 
step.

Then it also seems cleaner to me to cover the instruction
set with builtins like the others.

-Andi
-- 
a...@linux.intel.com -- Speaking for myself only


Re: [testsuite] remove XFAIL for all but ia64 for g++.dg/tree-ssa/pr43411.C

2011-05-26 Thread Richard Guenther
On Thu, May 26, 2011 at 5:16 PM, Mike Stump  wrote:
> On May 26, 2011, at 2:25 AM, Richard Guenther wrote:
>> The XPASS is suprious - that's the whole point of XPASSes.  It should
>> FAIL (well, XFAIL).  A patch making it PASS is bogus.
>
> There are deeper reasons for my position.  Take a look at:
>
>  http://google1.osuosl.org:8011/waterfall
>
> the idea is to use the expected state of the testcases to determine if the 
> color should be green or not.  The best use of a system like this is when the 
> usual state is green, and any time a red appears, it is turned back to green, 
> in time measures in minutes or hours, not days or years.  Now, do you think 
> there is any value add to having a testing system that displays testing 
> results across many platforms on a regular basis like this?  If so, how do 
> you propose to decide on wether the color should be green or red?

It's always red on a transition.  Whether an XPASS or XFAIL is red on
its own needs human interaction (understanding of the testcase and
why it now XPASSes or XFAILs).  The red on the transition should
cause the human that did that transition to do that inspection.

Richard.


Re: [PATCH, ARM] Unaligned accesses for packed structures [1/2]

2011-05-26 Thread Julian Brown
On Mon, 9 May 2011 18:01:12 +0100
Julian Brown  wrote:

> How does this look now? (Re-testing in progress.)

The previously-posted version contained a bug in the "extv" expander,
which became apparent only when testing together with my fixed-point
support patch. This is a corrected version.

Re-tested (together with the followup unaligned-memcpy patch and
fixed-point patch series), with no regressions in both big &
little-endian mode, cross to ARM EABI.

OK to apply this version?

Thanks,

Julian

ChangeLog

gcc/
* config/arm/arm.c (arm_override_options): Add unaligned_access
support.
(arm_file_start): Emit attribute for unaligned access as
appropriate.
* config/arm/arm.md (UNSPEC_UNALIGNED_LOAD)
(UNSPEC_UNALIGNED_STORE): Add constants for unspecs.
(insv, extzv): Add unaligned-access support.
(extv): Change to expander. Likewise.
(unaligned_loadsi, unaligned_loadhis, unaligned_loadhiu)
(unaligned_storesi, unaligned_storehi): New.
(*extv_reg): New (previous extv implementation).
* config/arm/arm.opt (munaligned_access): Add option.
* config/arm/constraints.md (Uw): New constraint.
* expmed.c (store_bit_field_1): Don't tweak bitfield numbering for
memory locations if BITS_BIG_ENDIAN != BYTES_BIG_ENDIAN.
(extract_bit_field_1): Likewise.
commit d66c777aa23e6df0d68265767d4ae9f370ffb761
Author: Julian Brown 
Date:   Tue May 24 10:01:48 2011 -0700

Unaligned support for packed structs

diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 47c7a3a..177c9bc 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -1674,6 +1674,28 @@ arm_option_override (void)
 	fix_cm3_ldrd = 0;
 }
 
+  /* Enable -munaligned-access by default for
+ - all ARMv6 architecture-based processors
+ - ARMv7-A, ARMv7-R, and ARMv7-M architecture-based processors.
+
+ Disable -munaligned-access by default for
+ - all pre-ARMv6 architecture-based processors
+ - ARMv6-M architecture-based processors.  */
+
+  if (unaligned_access == 2)
+{
+  if (arm_arch6 && (arm_arch_notm || arm_arch7))
+	unaligned_access = 1;
+  else
+	unaligned_access = 0;
+}
+  else if (unaligned_access == 1
+	   && !(arm_arch6 && (arm_arch_notm || arm_arch7)))
+{
+  warning (0, "target CPU does not support unaligned accesses");
+  unaligned_access = 0;
+}
+
   if (TARGET_THUMB1 && flag_schedule_insns)
 {
   /* Don't warn since it's on by default in -O2.  */
@@ -21555,6 +21577,10 @@ arm_file_start (void)
 	val = 6;
   asm_fprintf (asm_out_file, "\t.eabi_attribute 30, %d\n", val);
 
+  /* Tag_CPU_unaligned_access.  */
+  asm_fprintf (asm_out_file, "\t.eabi_attribute 34, %d\n",
+		   unaligned_access);
+
   /* Tag_ABI_FP_16bit_format.  */
   if (arm_fp16_format)
 	asm_fprintf (asm_out_file, "\t.eabi_attribute 38, %d\n",
diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index fad82f0..12fd7ca 100644
--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -104,6 +104,10 @@
   UNSPEC_SYMBOL_OFFSET  ; The offset of the start of the symbol from
 ; another symbolic address.
   UNSPEC_MEMORY_BARRIER ; Represent a memory barrier.
+  UNSPEC_UNALIGNED_LOAD	; Used to represent ldr/ldrh instructions that access
+			; unaligned locations, on architectures which support
+			; that.
+  UNSPEC_UNALIGNED_STORE ; Same for str/strh.
 ])
 
 ;; UNSPEC_VOLATILE Usage:
@@ -2393,7 +2397,7 @@
 ;;; this insv pattern, so this pattern needs to be reevalutated.
 
 (define_expand "insv"
-  [(set (zero_extract:SI (match_operand:SI 0 "s_register_operand" "")
+  [(set (zero_extract:SI (match_operand:SI 0 "nonimmediate_operand" "")
  (match_operand:SI 1 "general_operand" "")
  (match_operand:SI 2 "general_operand" ""))
 (match_operand:SI 3 "reg_or_int_operand" ""))]
@@ -2407,35 +2411,66 @@
 
 if (arm_arch_thumb2)
   {
-	bool use_bfi = TRUE;
-
-	if (GET_CODE (operands[3]) == CONST_INT)
+if (unaligned_access && MEM_P (operands[0])
+	&& s_register_operand (operands[3], GET_MODE (operands[3]))
+	&& (width == 16 || width == 32) && (start_bit % BITS_PER_UNIT) == 0)
 	  {
-	HOST_WIDE_INT val = INTVAL (operands[3]) & mask;
-
-	if (val == 0)
+	rtx base_addr;
+	
+	if (width == 32)
 	  {
-		emit_insn (gen_insv_zero (operands[0], operands[1],
-	  operands[2]));
-		DONE;
+	base_addr = adjust_address (operands[0], SImode,
+	start_bit / BITS_PER_UNIT);
+		emit_insn (gen_unaligned_storesi (base_addr, operands[3]));
 	  }
+	else
+	  {
+	rtx tmp = gen_reg_rtx (HImode);
 
-	/* See if the set can be done with a single orr instruction.  */
-	if (val == mask && const_ok_for_arm (val << start_bit))
-	  use_bfi = FALSE;
+	base_addr = adjust_address (operands[0], HImode,
+	start_bit / BITS_PER_UNIT);
+		emit_move_insn (tmp, gen_lowpart (HImode, operands[3]));
+

Re: Faster streaming of enums

2011-05-26 Thread Jan Hubicka
Hi,
this is updated patch.  For whatever reason we now end up with longer .o file
for tramp3d than with my prevoius attempt (by 9KB). We need at average 15 bytes
for location, well, the encoding of small ints might be better with uleb style,
perhaps with smaller chunk (like 4 bits per chunk as opposed to 8).
But that is easy followup.

Bootstrapping/regtesting x86_64-linux, OK if it passes?

* lto-streamer-out.c (lto_string_index): break out from...; offset by 1
so 0 means NULL string.
(lto_output_string_with_length): ... here.
(lto_output_string, output_string_cst, output_identifier): Update 
handling
of NULL strings.
(lto_output_location_bitpack): New function.
(lto_output_location): Use it.
(lto_output_tree_ref): Use output_record_start.
* lto-streamer-in.c (string_for_index): Break out from ...; offset 
values by 1.
(input_string_internal): ... here; 
(input_string_cst, input_identifier, lto_input_string): Update handling 
of NULL strings.
(lto_input_location_bitpack): New function
(lto_input_location): Use it.
* lto-streamer.h (bp_pack_small_unsigned, bp_pack_small_int, 
bp_unpack_small_unsigned,
bp_unpack_small_int): New functions.
Index: lto-streamer-out.c
===
*** lto-streamer-out.c  (revision 174268)
--- lto-streamer-out.c  (working copy)
*** destroy_output_block (struct output_bloc
*** 143,158 
free (ob);
  }
  
! 
! /* Output STRING of LEN characters to the string
!table in OB. The string might or might not include a trailing '\0'.
 Then put the index onto the INDEX_STREAM.  */
  
! void
! lto_output_string_with_length (struct output_block *ob,
!  struct lto_output_stream *index_stream,
!  const char *s,
!  unsigned int len)
  {
struct string_slot **slot;
struct string_slot s_slot;
--- 143,156 
free (ob);
  }
  
! /* Return index used to reference STRING of LEN characters in the string table
!in OB.  The string might or might not include a trailing '\0'.
 Then put the index onto the INDEX_STREAM.  */
  
! static unsigned
! lto_string_index (struct output_block *ob,
! const char *s,
! unsigned int len)
  {
struct string_slot **slot;
struct string_slot s_slot;
*** lto_output_string_with_length (struct ou
*** 164,172 
s_slot.len = len;
s_slot.slot_num = 0;
  
-   /* Indicate that this is not a NULL string.  */
-   lto_output_uleb128_stream (index_stream, 0);
- 
slot = (struct string_slot **) htab_find_slot (ob->string_hash_table,
 &s_slot, INSERT);
if (*slot == NULL)
--- 162,167 
*** lto_output_string_with_length (struct ou
*** 180,197 
new_slot->len = len;
new_slot->slot_num = start;
*slot = new_slot;
-   lto_output_uleb128_stream (index_stream, start);
lto_output_uleb128_stream (string_stream, len);
lto_output_data_stream (string_stream, string, len);
  }
else
  {
struct string_slot *old_slot = *slot;
-   lto_output_uleb128_stream (index_stream, old_slot->slot_num);
free (string);
  }
  }
  
  /* Output the '\0' terminated STRING to the string
 table in OB.  Then put the index onto the INDEX_STREAM.  */
  
--- 175,207 
new_slot->len = len;
new_slot->slot_num = start;
*slot = new_slot;
lto_output_uleb128_stream (string_stream, len);
lto_output_data_stream (string_stream, string, len);
+   return start + 1;
  }
else
  {
struct string_slot *old_slot = *slot;
free (string);
+   return old_slot->slot_num + 1;
  }
  }
  
+ 
+ /* Output STRING of LEN characters to the string
+table in OB. The string might or might not include a trailing '\0'.
+Then put the index onto the INDEX_STREAM.  */
+ 
+ void
+ lto_output_string_with_length (struct output_block *ob,
+  struct lto_output_stream *index_stream,
+  const char *s,
+  unsigned int len)
+ {
+   lto_output_uleb128_stream (index_stream,
+lto_string_index (ob, s, len));
+ }
+ 
  /* Output the '\0' terminated STRING to the string
 table in OB.  Then put the index onto the INDEX_STREAM.  */
  
*** lto_output_string (struct output_block *
*** 204,210 
  lto_output_string_with_length (ob, index_stream, string,
   strlen (string) + 1);
else
! lto_output_uleb128_stream (index_stream, 1);
  }
  
  
--- 214,220 
  lto_output_string_with_length (ob, index_stream, string,
   strlen (string) + 1);
else
! lto_output_1_stream (

Re: [PATCH,c++] describe reasons for function template overload resolution failure

2011-05-26 Thread Jason Merrill

On 05/25/2011 02:15 PM, Nathan Froyd wrote:

The patch below implements just such an idea.  The only twist is that
the `explain' parameter is actually a `location_t *' so that when we
provide explanations that aren't produced via tf_warning_or_error
blocks, the explanations are attached to the template itself rather than
the call, as would be done with input_location.  Requests for
non-explanation are accomplished with a NULL argument.

I'm not totally attached to this; it's almost too cute, and since
tf_warning_or_error messsages tend to be attached to the call anyway,
it's arguably inconsistent.


Yes, I think let's drop this bit and just use the call location. 
Ideally, for unification failures we'd give the source location of the 
problematic argument (which we don't always have because it might be a 
plain DECL) and for substitution failures we'd give the source location 
of the expression that substitution failed on (for which we could adjust 
input_location in tsubst_*).



I didn't see what you intended by "reconstructing" the arguments, so I
implemented the more straightforward saving.


I was thinking that we could try to add the candidate again, but this is 
fine.


Jason


Re: Better location streaming

2011-05-26 Thread Michael Matz
Hi,

On Thu, 26 May 2011, Richard Guenther wrote:

> > Hmm, I plan to optimize string streaming (since we always stream one 
> > uleb to set it is non-NULL that can be easilly handled by assigining 
> > NULL string index 0).  How precisely you however suggest to bitpack 
> > line/column and string offset together?
> 
> Similar to how you suggested, stream bits for a changed flag but instead 
> of finishing the bitpack simply stream HOST_BITS_PER_INT bits for line 

OMG, no.  Just write uleb outputters for bitpacks and use those.  In fact 
all outputs should just go through through bitpacks and properly align to 
byte border if necessary.


Ciao,
Michael.

Re: Libiberty: POSIXify psignal definition

2011-05-26 Thread DJ Delorie

> Yes please.  I've been arguing for that for some time.

Since you feel so strongly about it and nobody objects, go ahead.

> http://gcc.gnu.org/ml/gcc/2009-04/msg00410.html
> http://gcc.gnu.org/ml/gcc/2010-03/msg2.html
> http://gcc.gnu.org/ml/gcc/2010-03/msg00012.html
> http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01231.html
> http://gcc.gnu.org/ml/gcc-bugs/2011-03/msg00206.html
> http://gcc.gnu.org/ml/gcc/2011-03/msg00465.html
> http://gcc.gnu.org/ml/gcc-patches/2011-03/msg02304.html


Re: [PATCH] PR debug/49047 (linkage name missing for cdtors)

2011-05-26 Thread Jason Merrill

Why not just call add_linkage_name after add_abstract_origin_attribute?

Jason


Re: [testsuite] remove XFAIL for all but ia64 for g++.dg/tree-ssa/pr43411.C

2011-05-26 Thread Mike Stump
On May 26, 2011, at 2:25 AM, Richard Guenther wrote:
> The XPASS is suprious - that's the whole point of XPASSes.  It should
> FAIL (well, XFAIL).  A patch making it PASS is bogus.

There are deeper reasons for my position.  Take a look at:

  http://google1.osuosl.org:8011/waterfall

the idea is to use the expected state of the testcases to determine if the 
color should be green or not.  The best use of a system like this is when the 
usual state is green, and any time a red appears, it is turned back to green, 
in time measures in minutes or hours, not days or years.  Now, do you think 
there is any value add to having a testing system that displays testing results 
across many platforms on a regular basis like this?  If so, how do you propose 
to decide on wether the color should be green or red?


Re: ICE with -fgraphite-opencl-ignore-dep

2011-05-26 Thread Sebastian Pop
On Thu, May 26, 2011 at 03:11, Alexey Kravets  wrote:
> Here is the patch for this issue.
> It is caused by the bug in opencl_get_perfect_nested_loop_depth.
> This functions ignores  -fgraphite-opencl-ignore-dep flag while
> opencl_transform_stmt_list considers this flag.
>
> This patch adds a new function, which should be used to check for
> dependencies in graphite-opencl. I tested it on PolyKernels and on the
> block-0.c test from graphite testsuite.
>
> Is this patch OK for graphite branch? If it is, could you commit it?

The patch looks good.  Committed to the graphite branch after
make -k check RUNTESTFLAGS=graphite.exp
Thanks for fixing this.

>
> gcc:
> 2011-05-26  Alexey Kravets  
>
>        RP middle-end/49147
>        * graphite-opencl-codegen.c (opencl_get_perfect_nested_loop_depth):
>         Use enabled_dependency_in_clast_loop_p instead of
>         dependency_in_clast_loop_p.
>         graphite-opencl.c (opencl_transform_stmt_list): Ditto.
>         (enabled_dependency_in_clast_loop_p): New.
>         graphite-opencl.h (enabled_dependency_in_clast_loop_p): Export.
>
> testsuite:
> 2011-05-26  Alexey Kravets  
>
>        RP middle-end/49147
>        * gcc.dg/graphite/pr49147.c: New test.

To increase the number of tests we perform on the graphite-opencl code
gen, I was thinking to add the existing block-*.c files from the
testsuite to be compiled with the graphite-opencl flags as part of the
make check.

Sebastian


[PATCH] Fix bug in uniquify_nodes reorg

2011-05-26 Thread Richard Guenther

I merged one if too eagerly, resulting in not fixing up the
cache for merged types.  Oops.

LTO bootstrapped on x86_64-unknown-linux-gnu, testing and SPEC2k6
build in progress.

Richard.

2011-05-26  Richard Guenther  

lto/
* lto.c (uniquify_nodes): Fix bug in one of the previous changes.

Index: gcc/lto/lto.c
===
--- gcc/lto/lto.c   (revision 174269)
+++ gcc/lto/lto.c   (working copy)
@@ -610,33 +610,36 @@ uniquify_nodes (struct data_in *data_in,
}
}
 
-  else if (RECORD_OR_UNION_TYPE_P (t))
+  else
{
- tree f1, f2;
- if (TYPE_FIELDS (t) != TYPE_FIELDS (oldt))
-   for (f1 = TYPE_FIELDS (t), f2 = TYPE_FIELDS (oldt);
-f1 && f2; f1 = TREE_CHAIN (f1), f2 = TREE_CHAIN (f2))
- {
-   unsigned ix;
-   gcc_assert (f1 != f2 && DECL_NAME (f1) == DECL_NAME (f2));
-   if (!lto_streamer_cache_lookup (cache, f2, &ix))
- gcc_unreachable ();
-   /* If we're going to replace an element which we'd
-  still visit in the next iterations, we wouldn't
-  handle it, so do it here.  We do have to handle it
-  even though the field_decl itself will be removed,
-  as it could refer to e.g. integer_cst which we
-  wouldn't reach via any other way, hence they
-  (and their type) would stay uncollected.  */
-   /* ???  We should rather make sure to replace all
-  references to f2 with f1.  That means handling
-  COMPONENT_REFs and CONSTRUCTOR elements in
-  lto_fixup_types and special-case the field-decl
-  operand handling.  */
-   if (ix < i)
- lto_fixup_types (f2);
-   lto_streamer_cache_insert_at (cache, f1, ix);
- }
+ if (RECORD_OR_UNION_TYPE_P (t))
+   {
+ tree f1, f2;
+ if (TYPE_FIELDS (t) != TYPE_FIELDS (oldt))
+   for (f1 = TYPE_FIELDS (t), f2 = TYPE_FIELDS (oldt);
+f1 && f2; f1 = TREE_CHAIN (f1), f2 = TREE_CHAIN (f2))
+ {
+   unsigned ix;
+   gcc_assert (f1 != f2 && DECL_NAME (f1) == DECL_NAME (f2));
+   if (!lto_streamer_cache_lookup (cache, f2, &ix))
+ gcc_unreachable ();
+   /* If we're going to replace an element which we'd
+  still visit in the next iterations, we wouldn't
+  handle it, so do it here.  We do have to handle it
+  even though the field_decl itself will be removed,
+  as it could refer to e.g. integer_cst which we
+  wouldn't reach via any other way, hence they
+  (and their type) would stay uncollected.  */
+   /* ???  We should rather make sure to replace all
+  references to f2 with f1.  That means handling
+  COMPONENT_REFs and CONSTRUCTOR elements in
+  lto_fixup_types and special-case the field-decl
+  operand handling.  */
+   if (ix < i)
+ lto_fixup_types (f2);
+   lto_streamer_cache_insert_at (cache, f1, ix);
+ }
+   }
 
  /* If we found a tree that is equal to oldt replace it in the
 cache, so that further users (in the various LTO sections)


Re: PATCH: Add pause intrinsic

2011-05-26 Thread Michael Matz
Hi,

On Thu, 26 May 2011, Andrew Haley wrote:

> >>> +Generates the @code{pause} machine instruction.
> >>
> >> But that's missing the fact that it generates a compiler memory 
> >> barrier, which is important.  And if you think it's not a compiler 
> >> memory barrier, please explain
> >>
> >> a.  Why it's not a compiler memory barrier,
> > 
> > It is not a compiler memory barrier because it is a builtin function call
> > which is never assumed to be a barrier for local automatic storage
> > that does not have its address taken.
> 
> OK.  How would you tell the difference between the kind of barrier
> that it is and a real compiler memory barrier?

First we have to determine if this builtin really does what its users 
intend to use it for.  I believe they _do_ want to use it also with 
regards to auto variables (it includes also address-takens whose address 
doesn't escape).  A normal builtin call is not a barrier for operations on 
such entities, hence it might very well be that the implementation of HJ 
actually doesn't what he wanted.

I don't have a good word for what functions calls are in their barrierness 
part of pre/post conditions.  "global memory movement barrier" perhaps, 
with an appropriate definition of global memory (which funnily include 
address-taken escaped local storage, ugh).

> > To make it a compiler memory barrier you have to "expand" the
> > builtin already in the frontend and present the middle-end with
> > __asm__ ("" : : : "memory").  That will serve as a compiler
> > memory barrier also covering local non-address taken storage
> > (global and practically most of address-taken local storage
> > is covered by a builtin function call already).
> 
> Well, the fact that it's also a memory clobber has to be documented
> somehow.  If the present documentation is to be changed, it should
> not be changed by deleting a vital piece of information.

It's not only about the docu.  As implemented right now it's neither an 
optimization barrier nor a memory clobber.


Ciao,
Michael.


[PATCH] PR debug/49047 (linkage name missing for cdtors)

2011-05-26 Thread Dodji Seketeli
Hello,

The constructors (resp. destructors) of a given class K are cloned.
For each constructor (resp. destructor) There is thus an abstract
version of the function and (at least) a concrete version that
actually contains the code of the abstract version.

The debug info generated for a constructor (resp. destructor) lacks
linkage name (DWARF attribute DW_AT_MIPS_linkage_name), making the job
of GDB slow and difficult when it tries to get the actual concrete
function that contains the constructor's code to, e.g, set a
breakpoint.

The patch below emits that linkage name for those concrete versions of
cloned public functions.

Tested on x86-64-unknown-linux-gnu against trunk.

gcc/

* dwarf2out.c (gen_subprogram_die): Emit linkage name attribute
for functions containing actual code for public cloned abstract
functions.

gcc/testsuite/

* g++.dg/debug/dwarf2/cdtor-1.C: New test.
---
 gcc/dwarf2out.c |   11 +++
 gcc/testsuite/g++.dg/debug/dwarf2/cdtor-1.C |   17 +
 2 files changed, 28 insertions(+), 0 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/debug/dwarf2/cdtor-1.C

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 55453a3..85c01b1 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -19601,6 +19601,7 @@ gen_subprogram_die (tree decl, dw_die_ref context_die)
   dw_die_ref old_die = lookup_decl_die (decl);
   int declaration = (current_function_decl != decl
 || class_or_namespace_scope_p (context_die));
+  bool fn_has_code_addr_p = false;
 
   premark_used_types ();
 
@@ -19769,6 +19770,7 @@ gen_subprogram_die (tree decl, dw_die_ref context_die)
  /* We have already generated the labels.  */
  add_AT_lbl_id (subr_die, DW_AT_low_pc, fde->dw_fde_begin);
  add_AT_lbl_id (subr_die, DW_AT_high_pc, fde->dw_fde_end);
+ fn_has_code_addr_p = true;
}
  else
{
@@ -19780,6 +19782,7 @@ gen_subprogram_die (tree decl, dw_die_ref context_die)
  ASM_GENERATE_INTERNAL_LABEL (label_id, FUNC_END_LABEL,
   current_function_funcdef_no);
  add_AT_lbl_id (subr_die, DW_AT_high_pc, label_id);
+ fn_has_code_addr_p = true;
}
 
 #if VMS_DEBUGGING_INFO
@@ -19929,6 +19932,14 @@ gen_subprogram_die (tree decl, dw_die_ref context_die)
   if (cfun->static_chain_decl)
add_AT_location_description (subr_die, DW_AT_static_link,
 loc_list_from_tree (cfun->static_chain_decl, 2));
+
+  if (fn_has_code_addr_p && origin && TREE_PUBLIC (origin))
+   /*  So this is where the actual code for a publicly accessible
+   cloned function is.  Let's emit linkage name attribute for
+   it.  This helps debuggers to e.g, set breakpoints into
+   constructors/destructors when the user asks "break
+   K::K".  */
+   add_linkage_name (subr_die, decl);
 }
 
   /* Generate child dies for template paramaters.  */
diff --git a/gcc/testsuite/g++.dg/debug/dwarf2/cdtor-1.C 
b/gcc/testsuite/g++.dg/debug/dwarf2/cdtor-1.C
new file mode 100644
index 000..6d39e54
--- /dev/null
+++ b/gcc/testsuite/g++.dg/debug/dwarf2/cdtor-1.C
@@ -0,0 +1,17 @@
+// origin PR debug/49047
+// { dg-options "-g -dA" }
+// { dg-do compile }
+
+struct K
+{
+  K () { }
+  ~K () { }
+};
+
+int
+main()
+{
+K k;
+}
+
+// { dg-final {scan-assembler-times "\[^\n\r\]*DW_AT_MIPS_linkage_name:" 2 } }
-- 
1.7.3.4


-- 
Dodji


Re: PATCH: Add pause intrinsic

2011-05-26 Thread Andrew Haley
On 05/26/2011 03:29 PM, Richard Guenther wrote:
> On Thu, May 26, 2011 at 3:53 PM, Andrew Haley  wrote:
>> On 05/26/2011 02:51 PM, Richard Guenther wrote:
>>> On Thu, May 26, 2011 at 3:30 PM, Andrew Haley  wrote:
 On 05/26/2011 10:34 AM, Richard Guenther wrote:

>> Index: doc/extend.texi
>> ===
>> --- doc/extend.texi (revision 174216)
>> +++ doc/extend.texi (working copy)
>> @@ -8699,7 +8699,8 @@ The following built-in function is alway
>>
>>  @table @code
>>  @item void __builtin_ia32_pause (void)
>> -Generates the @code{pause} machine instruction with full memory barrier.
>> +Generates the @code{pause} machine instruction with a compiler memory
>> +barrier.
>>  @end table
>
> This isn't true.  It is _not_ a compiler memory barrier.

 Please elucidate.  Please suggest alternative wording.
>>>
>>> +Generates the @code{pause} machine instruction.
>>
>> But that's missing the fact that it generates a compiler memory barrier,
>> which is important.  And if you think it's not a compiler memory barrier,
>> please explain
>>
>> a.  Why it's not a compiler memory barrier,
> 
> It is not a compiler memory barrier because it is a builtin function call
> which is never assumed to be a barrier for local automatic storage
> that does not have its address taken.

OK.  How would you tell the difference between the kind of barrier
that it is and a real compiler memory barrier?  If an auto does not
have its address taken, it isn't visible anyway.

>> b.  What you'd call it.
> 
> Not a compiler memory barrier ;)

I don't want to know what not to call it, though.

> To make it a compiler memory barrier you have to "expand" the
> builtin already in the frontend and present the middle-end with
> __asm__ ("" : : : "memory").  That will serve as a compiler
> memory barrier also covering local non-address taken storage
> (global and practically most of address-taken local storage
> is covered by a builtin function call already).

Well, the fact that it's also a memory clobber has to be documented
somehow.  If the present documentation is to be changed, it should
not be changed by deleting a vital piece of information.

Andrew.


Re: PATCH: Add pause intrinsic

2011-05-26 Thread Richard Guenther
On Thu, May 26, 2011 at 4:34 PM, Jakub Jelinek  wrote:
> On Thu, May 26, 2011 at 04:29:50PM +0200, Richard Guenther wrote:
>> To make it a compiler memory barrier you have to "expand" the
>> builtin already in the frontend and present the middle-end with
>> __asm__ ("" : : : "memory").  That will serve as a compiler
>> memory barrier also covering local non-address taken storage
>> (global and practically most of address-taken local storage
>> is covered by a builtin function call already).
>
> But then, what is the point of the builtin when
> __asm__ __volatile__ ("rep; nop" : : : "memory");
> does all of that already and has been supported for years...

Good question ;)

Richard.


Re: PATCH: Add pause intrinsic

2011-05-26 Thread Jakub Jelinek
On Thu, May 26, 2011 at 04:29:50PM +0200, Richard Guenther wrote:
> To make it a compiler memory barrier you have to "expand" the
> builtin already in the frontend and present the middle-end with
> __asm__ ("" : : : "memory").  That will serve as a compiler
> memory barrier also covering local non-address taken storage
> (global and practically most of address-taken local storage
> is covered by a builtin function call already).

But then, what is the point of the builtin when
__asm__ __volatile__ ("rep; nop" : : : "memory");
does all of that already and has been supported for years...

Jakub


[PATCH][JAVA] Sanitize Java frontend global tree building

2011-05-26 Thread Richard Guenther

In preparation to move all frontends common tree node building to
the middle-end this makes the Java frontend actually use the
standard routines.  It's still severely broken in overriding
things with stuff that does not match the targets C ABI, but well,
Java ...

Bootstrapped and tested on x86_64-unknown-linux-gnu, ok for trunk?

Thanks,
Richard.

2011-05-26  Richard Guenther  

java/
* decl.c (java_init_decl_processing): Call build_common_nodes,
set_sizetype and build_common_nodes_2 at the beginning.  Remove
then duplicate initializations.

Index: gcc/java/decl.c
===
--- gcc/java/decl.c (revision 174281)
+++ gcc/java/decl.c (working copy)
@@ -566,13 +566,22 @@ java_init_decl_processing (void)
   pushlevel (0);   /* make the binding_level structure for global names */
   global_binding_level = current_binding_level;
 
-  /* The code here must be similar to build_common_tree_nodes{,_2} in
- tree.c, especially as to the order of initializing common nodes.  */
-  error_mark_node = make_node (ERROR_MARK);
-  TREE_TYPE (error_mark_node) = error_mark_node;
+  /* Build common tree nodes, Java has an unsigned char.  */
+  build_common_tree_nodes (false);
 
-  /* Create sizetype first - needed for other types. */
-  initialize_sizetypes ();
+  /* This is not a java type, however tree-dfa requires a definition for
+ size_type_node.  */
+  size_type_node = make_unsigned_type (POINTER_SIZE);
+  set_sizetype (size_type_node);
+
+  /* Build the rest of the common tree nodes.  */
+  build_common_tree_nodes_2 (0);
+
+  /* ???  Now we continue and override some of the built types again
+ with Java specific types.  As the above generated types are
+ supposed to match the targets C ABI this isn't really the way
+ to go and any Java specifics should _not_ use those global types
+ if the Java ABI does not match the C one.  */
 
   byte_type_node = make_signed_type (8);
   pushdecl (build_decl (BUILTINS_LOCATION,
@@ -604,11 +613,6 @@ java_init_decl_processing (void)
TYPE_DECL, get_identifier ("unsigned long"),
unsigned_long_type_node));
 
-  /* This is not a java type, however tree-dfa requires a definition for
- size_type_node.  */
-  size_type_node = make_unsigned_type (POINTER_SIZE);
-  set_sizetype (size_type_node);
-
   /* Define these next since types below may used them.  */
   integer_type_node = java_type_for_size (INT_TYPE_SIZE, 0);
   integer_zero_node = build_int_cst (NULL_TREE, 0);
@@ -624,39 +628,22 @@ java_init_decl_processing (void)
 = double_int_to_tree (unsigned_long_type_node,
  double_int_setbit (double_int_zero, 64));
 
-  size_zero_node = size_int (0);
-  size_one_node = size_int (1);
-  bitsize_zero_node = bitsize_int (0);
-  bitsize_one_node = bitsize_int (1);
-  bitsize_unit_node = bitsize_int (BITS_PER_UNIT);
-
   long_zero_node = build_int_cst (long_type_node, 0);
 
-  void_type_node = make_node (VOID_TYPE);
   pushdecl (build_decl (BUILTINS_LOCATION,
TYPE_DECL, get_identifier ("void"), void_type_node));
-  layout_type (void_type_node);/* Uses size_zero_node */
-
-  ptr_type_node = build_pointer_type (void_type_node);
-  const_ptr_type_node
-= build_pointer_type (build_type_variant (void_type_node, 1, 0));
 
   t = make_node (VOID_TYPE);
   layout_type (t); /* Uses size_zero_node */
   return_address_type_node = build_pointer_type (t);
 
-  null_pointer_node = build_int_cst (ptr_type_node, 0);
-
-  char_type_node = make_node (INTEGER_TYPE);
+  char_type_node = make_unsigned_type (16);
   TYPE_STRING_FLAG (char_type_node) = 1;
-  TYPE_PRECISION (char_type_node) = 16;
-  fixup_unsigned_type (char_type_node);
   pushdecl (build_decl (BUILTINS_LOCATION,
TYPE_DECL, get_identifier ("char"), char_type_node));
 
-  boolean_type_node = make_node (BOOLEAN_TYPE);
-  TYPE_PRECISION (boolean_type_node) = 1;
-  fixup_unsigned_type (boolean_type_node);
+  boolean_type_node = make_unsigned_type (1);
+  TREE_SET_CODE (boolean_type_node, BOOLEAN_TYPE);
   pushdecl (build_decl (BUILTINS_LOCATION,
TYPE_DECL, get_identifier ("boolean"),
boolean_type_node));


Re: PATCH: Add pause intrinsic

2011-05-26 Thread Richard Guenther
On Thu, May 26, 2011 at 3:53 PM, Andrew Haley  wrote:
> On 05/26/2011 02:51 PM, Richard Guenther wrote:
>> On Thu, May 26, 2011 at 3:30 PM, Andrew Haley  wrote:
>>> On 05/26/2011 10:34 AM, Richard Guenther wrote:
>>>
> Index: doc/extend.texi
> ===
> --- doc/extend.texi     (revision 174216)
> +++ doc/extend.texi     (working copy)
> @@ -8699,7 +8699,8 @@ The following built-in function is alway
>
>  @table @code
>  @item void __builtin_ia32_pause (void)
> -Generates the @code{pause} machine instruction with full memory barrier.
> +Generates the @code{pause} machine instruction with a compiler memory
> +barrier.
>  @end table

 This isn't true.  It is _not_ a compiler memory barrier.
>>>
>>> Please elucidate.  Please suggest alternative wording.
>>
>> +Generates the @code{pause} machine instruction.
>
> But that's missing the fact that it generates a compiler memory barrier,
> which is important.  And if you think it's not a compiler memory barrier,
> please explain
>
> a.  Why it's not a compiler memory barrier,

It is not a compiler memory barrier because it is a builtin function call
which is never assumed to be a barrier for local automatic storage
that does not have its address taken.

> b.  What you'd call it.

Not a compiler memory barrier ;)

To make it a compiler memory barrier you have to "expand" the
builtin already in the frontend and present the middle-end with
__asm__ ("" : : : "memory").  That will serve as a compiler
memory barrier also covering local non-address taken storage
(global and practically most of address-taken local storage
is covered by a builtin function call already).

Richard.

>
> Andrew.
>


Re: RFC: explicitely mark out-of-scope deaths

2011-05-26 Thread Richard Guenther
On Thu, May 26, 2011 at 4:00 PM, Jakub Jelinek  wrote:
> On Thu, May 26, 2011 at 03:43:45PM +0200, Michael Matz wrote:
>> --- tree-stdarg.c.orig        2011-05-26 14:15:01.0 +0200
>> +++ tree-stdarg.c     2011-05-26 14:15:41.0 +0200
>> @@ -872,8 +872,12 @@ execute_optimize_stdarg (void)
>>                 if (get_gimple_rhs_class (gimple_assign_rhs_code (stmt))
>>                     == GIMPLE_SINGLE_RHS)
>>                   {
>> +                   /* Check for ap ={v} {}.  */
>> +                   if (TREE_CODE (rhs) == CONSTRUCTOR
>> +                            && TREE_THIS_VOLATILE (rhs))
>> +                     continue;
>>                     /* Check for ap[0].field = temp.  */
>> -                   if (va_list_counter_struct_op (&si, lhs, rhs, true))
>> +                   else if (va_list_counter_struct_op (&si, lhs, rhs, true))
>>                       continue;
>
> Perhaps optimize_stdarg_builtin could fold __builtin_va_end into
> this ap ={v} {} for non-pointer va_list to make it clear the variable
> is undefined afterwards, currently it just optimizes it away completely.

Btw, I suggested to use {  } for the "undefinedness".

Repeated code asks for something like gimple_clobber_p () and
gimple_clobber_rhs_p ().

Richard.


Re: [Patch, Fortran] -fcoarray=lib - add registering calls for nonallocatable coarrays

2011-05-26 Thread Tobias Burnus
Dear Paul,

thanks for the review. Regarding:

Paul Thomas wrote:
> Maybe I am being stupid but what is the call, in the
> testcase, to subroutine test for?


Well, it is supposed to test coarray decls in functions,
contained functions, and in not-referenced functions.

However, I forgot the [*]  (or [3,*] or ...). Fortunately, you
have spotted the sematically relevant typo!

Tobias


Re: RFC: explicitely mark out-of-scope deaths

2011-05-26 Thread Jakub Jelinek
On Thu, May 26, 2011 at 03:43:45PM +0200, Michael Matz wrote:
> --- tree-stdarg.c.orig2011-05-26 14:15:01.0 +0200
> +++ tree-stdarg.c 2011-05-26 14:15:41.0 +0200
> @@ -872,8 +872,12 @@ execute_optimize_stdarg (void)
> if (get_gimple_rhs_class (gimple_assign_rhs_code (stmt))
> == GIMPLE_SINGLE_RHS)
>   {
> +   /* Check for ap ={v} {}.  */
> +   if (TREE_CODE (rhs) == CONSTRUCTOR
> +&& TREE_THIS_VOLATILE (rhs))
> + continue;
> /* Check for ap[0].field = temp.  */
> -   if (va_list_counter_struct_op (&si, lhs, rhs, true))
> +   else if (va_list_counter_struct_op (&si, lhs, rhs, true))
>   continue;

Perhaps optimize_stdarg_builtin could fold __builtin_va_end into
this ap ={v} {} for non-pointer va_list to make it clear the variable
is undefined afterwards, currently it just optimizes it away completely.

Jakub


Re: [patch][simplify-rtx] Fix 16-bit -> 64-bit multiply and accumulate

2011-05-26 Thread Joseph S. Myers
On Thu, 26 May 2011, Andrew Stubbs wrote:

> On 25/05/11 14:47, Joseph S. Myers wrote:
> > The shift must be by a positive constant amount, strictly less than the
> > precision (GET_MODE_PRECISION) of the mode (of the value being shifted).
> > If that applies, the relevant number of bits is the precision of the mode
> > minus the number of bits of the shift.  For an extension, just take the
> > number of bits in the inner mode.  Add the two numbers of bits; if the
> > result does not exceed the number of bits in the mode (of the operands and
> > the multiplication) then the multiplication won't overflow.
> 
> I believe the attached should implement what you describe.
> 
> Is the patch OK now?

It appears to implement the logic I described, so I have no further 
comments on it (but can't review it).

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


Re: PATCH: Add pause intrinsic

2011-05-26 Thread Andrew Haley
On 05/26/2011 02:51 PM, Richard Guenther wrote:
> On Thu, May 26, 2011 at 3:30 PM, Andrew Haley  wrote:
>> On 05/26/2011 10:34 AM, Richard Guenther wrote:
>>
 Index: doc/extend.texi
 ===
 --- doc/extend.texi (revision 174216)
 +++ doc/extend.texi (working copy)
 @@ -8699,7 +8699,8 @@ The following built-in function is alway

  @table @code
  @item void __builtin_ia32_pause (void)
 -Generates the @code{pause} machine instruction with full memory barrier.
 +Generates the @code{pause} machine instruction with a compiler memory
 +barrier.
  @end table
>>>
>>> This isn't true.  It is _not_ a compiler memory barrier.
>>
>> Please elucidate.  Please suggest alternative wording.
> 
> +Generates the @code{pause} machine instruction.

But that's missing the fact that it generates a compiler memory barrier,
which is important.  And if you think it's not a compiler memory barrier,
please explain

a.  Why it's not a compiler memory barrier,
b.  What you'd call it.

Andrew.


Re: PATCH: Add pause intrinsic

2011-05-26 Thread Richard Guenther
On Thu, May 26, 2011 at 3:30 PM, Andrew Haley  wrote:
> On 05/26/2011 10:34 AM, Richard Guenther wrote:
>
>>> Index: doc/extend.texi
>>> ===
>>> --- doc/extend.texi     (revision 174216)
>>> +++ doc/extend.texi     (working copy)
>>> @@ -8699,7 +8699,8 @@ The following built-in function is alway
>>>
>>>  @table @code
>>>  @item void __builtin_ia32_pause (void)
>>> -Generates the @code{pause} machine instruction with full memory barrier.
>>> +Generates the @code{pause} machine instruction with a compiler memory
>>> +barrier.
>>>  @end table
>>
>> This isn't true.  It is _not_ a compiler memory barrier.
>
> Please elucidate.  Please suggest alternative wording.

+Generates the @code{pause} machine instruction.

Richard.

> Andrew.
>


Re: [PATCH PING] unreviewed tree-slimming patches

2011-05-26 Thread Jason Merrill

On 05/26/2011 09:46 AM, Nathan Froyd wrote:

On 05/26/2011 09:39 AM, Jason Merrill wrote:

On 05/25/2011 10:21 PM, Nathan Froyd wrote:

An alternative solution would be to initialize cur_stmt_list somewhere with an
actual 1-element VEC;


Or just push NULL onto the stack and let append_to_statement_list_1 allocate
the VEC?


Did you misspeak here?  append_to_statement_1 shouldn't be caring about VECs.


Yes, I was confused.  I meant push NULL onto the VEC, which seems like 
what you meant too.


Jason


[PATCH] Remove bogus fold code

2011-05-26 Thread Richard Guenther

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

Richard.

2011-05-26  Richard Guenther  

* fold-const.c (fold_unary_loc): Remove bogus code.

Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 174269)
+++ gcc/fold-const.c(working copy)
@@ -7639,21 +7639,6 @@ fold_unary_loc (location_t loc, enum tre
0)));
  return tem;
}
-  else if (COMPARISON_CLASS_P (arg0))
-   {
- if (TREE_CODE (type) == BOOLEAN_TYPE)
-   {
- arg0 = copy_node (arg0);
- TREE_TYPE (arg0) = type;
- return arg0;
-   }
- else if (TREE_CODE (type) != INTEGER_TYPE)
-   return fold_build3_loc (loc, COND_EXPR, type, arg0,
-   fold_build1_loc (loc, code, type,
-integer_one_node),
-   fold_build1_loc (loc, code, type,
-integer_zero_node));
-   }
}
 
   switch (code)


Re: [PATCH PING] unreviewed tree-slimming patches

2011-05-26 Thread Nathan Froyd
On 05/26/2011 09:39 AM, Jason Merrill wrote:
> On 05/25/2011 10:21 PM, Nathan Froyd wrote:
>> An alternative solution would be to initialize cur_stmt_list somewhere with 
>> an
>> actual 1-element VEC;
> 
> Or just push NULL onto the stack and let append_to_statement_list_1 allocate
> the VEC?

Did you misspeak here?  append_to_statement_1 shouldn't be caring about VECs.
 Or do you mean pushing NULL_TREE someplace else, as in:

>> the check in add_stmt would then be unnecessary, as we'd
>> always be assured of having someplace in the stack to store it.  I don't 
>> trust
>> myself to write a patch like that tonight; I'll twiddle with that tomorrow.
> 
> Right, that's what I was thinking about.  I think we should only need to do
> this once per function.

...here?

-Nathan



RFC: explicitely mark out-of-scope deaths

2011-05-26 Thread Michael Matz
Hi,

on IRC we discussed about this, here's the RFC patch.  It bootstraps and 
causes some minor regressions most probably due to some missing sprinkled 
checks for the special clobber insns and sometimes due to having to adjust 
some regexps.

Anyway, stack slot sharing is currently using the heuristic that if 
variables were declared in non-intersecting scopes they can share they 
space.  Code movement transformations make this heuristic invalid, and 
we're lucky that we're hit with problems only very seldomly.  The solution 
is to make the border of liveness for local variables (at least those not 
gimple_reg, as the latter are moved to outer scope anyway, and hence all 
conflict) explicit in the intermediate representation, either preventing 
invalid code movements, or updating the IR to reflect such movement.

The idea is to explicitely mark the death for all such variables by some 
special instruction whose interpretation would mean "clobber all space 
associated with this entity".  We nearly have such instructions, namely 
simple stores with an empty ctor on the rhs.  We just have to mark them in 
a way to differ them from such normal stores (which are interpreted as 
filling the LHS with zero bytes).  I chose to use volatility as such 
marker (which normally doesn't make sense on a CONSTRUCTOR node).

Stores are better than builtin functions here, so as to not artificially 
take addresses of the decls in question.  They are also better than a 
completely new type of instruction as stores are handled already by 
passes, and the semantics match quite well if you consider the RHS to be 
undefined.

This store will act as a movement barrier, or alternatively can be moved 
with other instructions.  They can also be duplicated, and generally 
naturally transform with any other transformation we want to do.

The live area of a local decl then will be defined as the area between the 
first mention of the decls name, and those clobber instructions.  This is 
conservative in that we overestimate the start of live (it's starting not 
at the first mention of the name which could be an address taking, but at 
the first store to it, or at the start of its scope, which we could 
identify be a similar new instruction).

A simple bit algorithm can be used to calculate this area, and then the 
conflicts for stack slot sharing.

The nice thing about explicitel death markers is that we could use them 
also to implement some warning where addresses to out-of-scope variables 
definitely or possibly escape after their point of death.

For a full solution these death points need to be reflected in RTL too so 
as to also deactivate the scheduler messing with instruction sequence.  
Alternatively we can create a conflict between all alias sets in one stack 
slot (and then have to disable object based disambiguation).  I haven't 
yet investigated if we could perhaps just use the CLOBBER rtx for that.

The patch also doesn't remove (but disables) the current code for 
generating conflicts.

So, I'm asking for some comments.  Also about my choice of using an empty 
volatile CONSTRUCTOR as marker, perhaps someone has a nicer idea.  (Note 
the above remarks though, and also that these clobbers must not be removed 
for uselessness, otherwise we'll get less sharing, thankfully not wrong 
code at least).


Ciao,
Michael.
Index: gengtype.c
===
--- gengtype.c.orig 2011-05-26 14:15:01.0 +0200
+++ gengtype.c  2011-05-26 14:15:41.0 +0200
@@ -3613,14 +3613,13 @@ write_field_root (outf_p f, pair_p v, ty
  int has_length, struct fileloc *line, const char *if_marked,
  bool emit_pch, type_p field_type, const char *field_name)
 {
+  struct pair newv;
   /* If the field reference is relative to V, rather than to some
  subcomponent of V, we can mark any subarrays with a single stride.
  We're effectively treating the field as a global variable in its
  own right.  */
   if (v && type == v->type)
 {
-  struct pair newv;
-
   newv = *v;
   newv.type = field_type;
   newv.name = ACONCAT ((v->name, ".", field_name, NULL));
Index: tree-stdarg.c
===
--- tree-stdarg.c.orig  2011-05-26 14:15:01.0 +0200
+++ tree-stdarg.c   2011-05-26 14:15:41.0 +0200
@@ -872,8 +872,12 @@ execute_optimize_stdarg (void)
  if (get_gimple_rhs_class (gimple_assign_rhs_code (stmt))
  == GIMPLE_SINGLE_RHS)
{
+ /* Check for ap ={v} {}.  */
+ if (TREE_CODE (rhs) == CONSTRUCTOR
+  && TREE_THIS_VOLATILE (rhs))
+   continue;
  /* Check for ap[0].field = temp.  */
- if (va_list_counter_struct_op (&si, lhs, rhs, true))
+ else if (va_list_counter_struct_o

Re: [PATCH] Handle C++ x ? y : throw 1 COND_EXPRs in shortcut_cond_r (PR c++/49165)

2011-05-26 Thread Jason Merrill

On 05/26/2011 09:41 AM, Jakub Jelinek wrote:

That is how it ends up being optimized later on, I just think
given how long the bug has been in this is so rare that
we don't need to try to optimize it already at the gimplifier level.


Makes sense.

Jason


Re: [PATCH] Handle C++ x ? y : throw 1 COND_EXPRs in shortcut_cond_r (PR c++/49165)

2011-05-26 Thread Jakub Jelinek
On Thu, May 26, 2011 at 09:26:58AM -0400, Jason Merrill wrote:
> On 05/26/2011 06:32 AM, Jakub Jelinek wrote:
> >gimplify_cond_expr knows how to gimplify this, but shortcut_cond_r
> >tried to optimize
> >if (a ? b : throw 1) goto yes; else goto no;
> >into
> >if (a)
> >   if (b) goto yes; else goto no;
> >else
> >   if (throw 1) goto yes; else goto no;
> >which ICEs or errors out.  Fixed by not trying to optimize
> >such COND_EXPRs.
> 
> Why not optimize them to
> 
> if (!a)
>   throw 1;
> if (b) goto yes; else goto no;
> 
> ?

That is how it ends up being optimized later on, I just think
given how long the bug has been in this is so rare that
we don't need to try to optimize it already at the gimplifier level.

Jakub


Re: [PATCH PING] unreviewed tree-slimming patches

2011-05-26 Thread Jason Merrill

On 05/25/2011 10:21 PM, Nathan Froyd wrote:

An alternative solution would be to initialize cur_stmt_list somewhere with an
actual 1-element VEC;


Or just push NULL onto the stack and let append_to_statement_list_1 
allocate the VEC?



the check in add_stmt would then be unnecessary, as we'd
always be assured of having someplace in the stack to store it.  I don't trust
myself to write a patch like that tonight; I'll twiddle with that tomorrow.


Right, that's what I was thinking about.  I think we should only need to 
do this once per function.



behavior; I don't think it's worthwhile to change all the callers to ensure
the pointer-to-statement_list points to a non-NULL thing.


Agreed.

Jason


Re: [patch][simplify-rtx] Fix 16-bit -> 64-bit multiply and accumulate

2011-05-26 Thread Andrew Stubbs

On 25/05/11 14:47, Joseph S. Myers wrote:

The shift must be by a positive constant amount, strictly less than the
precision (GET_MODE_PRECISION) of the mode (of the value being shifted).
If that applies, the relevant number of bits is the precision of the mode
minus the number of bits of the shift.  For an extension, just take the
number of bits in the inner mode.  Add the two numbers of bits; if the
result does not exceed the number of bits in the mode (of the operands and
the multiplication) then the multiplication won't overflow.


I believe the attached should implement what you describe.

Is the patch OK now?

Andrew
2011-05-26  Bernd Schmidt  
	Andrew Stubbs  

	gcc/
	* simplify-rtx.c (simplify_unary_operation_1): Canonicalize widening
	multiplies.
	* doc/md.texi (Canonicalization of Instructions): Document widening
	multiply canonicalization.

	gcc/testsuite/
	* gcc.target/arm/mla-2.c: New test.

--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -5840,6 +5840,23 @@ Equality comparisons of a group of bits (usually a single bit) with zero
 will be written using @code{zero_extract} rather than the equivalent
 @code{and} or @code{sign_extract} operations.
 
+@cindex @code{mult}, canonicalization of
+@item
+@code{(sign_extend:@var{m1} (mult:@var{m2} (sign_extend:@var{m2} @var{x})
+(sign_extend:@var{m2} @var{y})))} is converted to @code{(mult:@var{m1}
+(sign_extend:@var{m1} @var{x}) (sign_extend:@var{m1} @var{y}))}, and likewise
+for @code{zero_extend}.
+
+@item
+@code{(sign_extend:@var{m1} (mult:@var{m2} (ashiftrt:@var{m2}
+@var{x} @var{s}) (sign_extend:@var{m2} @var{y})))} is converted
+to @code{(mult:@var{m1} (sign_extend:@var{m1} (ashiftrt:@var{m2}
+@var{x} @var{s})) (sign_extend:@var{m1} @var{y}))}, and likewise for
+patterns using @code{zero_extend} and @code{lshiftrt}.  If the second
+operand of @code{mult} is also a shift, then that is extended also.
+This transformation is only applied when it can be proven that the
+original operation had sufficient precision to prevent overflow.
+
 @end itemize
 
 Further canonicalization rules are defined in the function
--- a/gcc/simplify-rtx.c
+++ b/gcc/simplify-rtx.c
@@ -1000,6 +1000,48 @@ simplify_unary_operation_1 (enum rtx_code code, enum machine_mode mode, rtx op)
 	  && GET_CODE (XEXP (XEXP (op, 0), 1)) == LABEL_REF)
 	return XEXP (op, 0);
 
+  /* Extending a widening multiplication should be canonicalized to
+	 a wider widening multiplication.  */
+  if (GET_CODE (op) == MULT)
+	{
+	  rtx lhs = XEXP (op, 0);
+	  rtx rhs = XEXP (op, 1);
+	  enum rtx_code lcode = GET_CODE (lhs);
+	  enum rtx_code rcode = GET_CODE (rhs);
+
+	  /* Widening multiplies usually extend both operands, but sometimes
+	 they use a shift to extract a portion of a register.  */
+	  if ((lcode == SIGN_EXTEND
+	   || (lcode == ASHIFTRT && CONST_INT_P (XEXP (lhs, 1
+	  && (rcode == SIGN_EXTEND
+		  || (rcode == ASHIFTRT && CONST_INT_P (XEXP (rhs, 1)
+	{
+	  enum machine_mode lmode = GET_MODE (lhs);
+	  enum machine_mode rmode = GET_MODE (rhs);
+	  int bits;
+
+	  if (lcode == ASHIFTRT)
+		/* Number of bits not shifted off the end.  */
+		bits = GET_MODE_PRECISION (lmode) - INTVAL (XEXP (lhs, 1));
+	  else /* lcode == SIGN_EXTEND */
+		/* Size of inner mode.  */
+		bits = GET_MODE_PRECISION (GET_MODE (XEXP (lhs, 0)));
+
+	  if (rcode == ASHIFTRT)
+		bits += GET_MODE_PRECISION (rmode) - INTVAL (XEXP (rhs, 1));
+	  else /* rcode == SIGN_EXTEND */
+		bits += GET_MODE_PRECISION (GET_MODE (XEXP (rhs, 0)));
+
+	  /* We can only widen multiplies if the result is mathematiclly
+		 equivalent.  I.e. if overflow was impossible.  */
+	  if (bits <= GET_MODE_PRECISION (GET_MODE (op)))
+		return simplify_gen_binary
+			 (MULT, mode,
+			  simplify_gen_unary (SIGN_EXTEND, mode, lhs, lmode),
+			  simplify_gen_unary (SIGN_EXTEND, mode, rhs, rmode));
+	}
+	}
+
   /* Check for a sign extension of a subreg of a promoted
 	 variable, where the promotion is sign-extended, and the
 	 target mode is the same as the variable's promotion.  */
@@ -1071,6 +1113,48 @@ simplify_unary_operation_1 (enum rtx_code code, enum machine_mode mode, rtx op)
 	  && GET_MODE_SIZE (mode) <= GET_MODE_SIZE (GET_MODE (XEXP (op, 0
 	return rtl_hooks.gen_lowpart_no_emit (mode, op);
 
+  /* Extending a widening multiplication should be canonicalized to
+	 a wider widening multiplication.  */
+  if (GET_CODE (op) == MULT)
+	{
+	  rtx lhs = XEXP (op, 0);
+	  rtx rhs = XEXP (op, 1);
+	  enum rtx_code lcode = GET_CODE (lhs);
+	  enum rtx_code rcode = GET_CODE (rhs);
+
+	  /* Widening multiplies usually extend both operands, but sometimes
+	 they use a shift to extract a portion of a register.  */
+	  if ((lcode == ZERO_EXTEND
+	   || (lcode == LSHIFTRT && CONST_INT_P (XEXP (lhs, 1
+	  && (rcode == ZERO_EXTEND
+		  || (rcode == LSHIFTRT && CONST_INT_P (XEXP (rhs, 1)
+	{
+	  enum machine_mode lmode = GET_MODE (lhs);
+	 

Re: Fix PR 49014

2011-05-26 Thread Andrey Belevantsev

On 25.05.2011 19:31, Bernd Schmidt wrote:

On 05/25/2011 03:29 PM, Andrey Belevantsev wrote:

I think the hook is a better idea than the attribute because nobody will
care to mark all offending insns with an attribute.


I don't know. IIRC when I looked at sh or whatever the broken port was,
it was only two insns - there would still be some value in being able to
assert that all other insns have a reservation.

OK, I will take a look on x86-64 and will get back with more information.

Andrey




Bernd




Re: C6X port 9/11: Allow defining attributes in terms of another

2011-05-26 Thread Bernd Schmidt
On 05/25/2011 01:45 PM, Hans-Peter Nilsson wrote:
> On Wed, 25 May 2011, Bernd Schmidt wrote:
> 
>> I'm not sure where you're looking for added documentation for this
>> patch.
> 
> I guess no surprise that'd be md.texi node Defining Attributes,

That covers define_attr, not set_attr, so it seems inappropriate.

> or an updated example in node Attr Example since the
> documentation for "default" basically just refers to it.  Or
> perhaps better node Expressions where (attr x) is documented,
> since it says it's mostly useful for numeric attributes and not
> so for non-numeric attributes.  Perhaps add after that sentence
> "It can also be used to yield the value of another attribute,
> useful to e.g. set the value of the current attribute if they
> share a domain".  You can probably find a better wording. :)

To be honest I can't think of anything reasonable to add there. The
documentation already says you can use (attr "...") to return the value
of another attribute... all my patch did was make that actually work in
some situations.


Bernd


Re: PATCH: Add pause intrinsic

2011-05-26 Thread Andrew Haley
On 05/26/2011 10:34 AM, Richard Guenther wrote:

>> Index: doc/extend.texi
>> ===
>> --- doc/extend.texi (revision 174216)
>> +++ doc/extend.texi (working copy)
>> @@ -8699,7 +8699,8 @@ The following built-in function is alway
>>
>>  @table @code
>>  @item void __builtin_ia32_pause (void)
>> -Generates the @code{pause} machine instruction with full memory barrier.
>> +Generates the @code{pause} machine instruction with a compiler memory
>> +barrier.
>>  @end table
> 
> This isn't true.  It is _not_ a compiler memory barrier.

Please elucidate.  Please suggest alternative wording.

Andrew.


  1   2   >