[PATCH ARM] backport r174803 from trunk to 4.6 branch

[Bin Cheng]

Hi,
Julian Brown once posted a patch fixing ARM EABI violation, which I think
also essential to 4.6 branch.
I created a patch against 4.6 branch as attached. Is it ok to back port?

You can refer following link for original patch.
http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00260.html

Thanks

gcc/ChangeLog:
2012-02-08  Bin Cheng  

Backport from mainline
2011-06-08  Julian Brown  

* config/arm/arm.c (arm_libcall_uses_aapcs_base): Use correct ABI
for double-precision helper functions in hard-float mode if only
single-precision arithmetic is supported in hardware.

Re: [PATCH][4.8] C++ memory model bitfield handling rewrite

[Jason Merrill]

On 02/07/2012 04:47 AM, Joseph S. Myers wrote:

For C++ the width may depend on a template parameter so the integer value
can't be determined immediately at parse time.


Right.  But we don't do any layout in templates, so it should be ok to 
do different things for template and non-template cases.


Jason

Re: [PATCH][4.8] C++ memory model bitfield handling rewrite

[Jason Merrill]

On 02/07/2012 02:23 AM, Richard Guenther wrote:

There are still corner-cases I also pointed out in the existing
get_bit_range code, namely if you consider tail-padding re-use
with C++ inheritance (I didn't try hard to construct a testcase yet).
The C++ memory model folks have not yet expressed their opinion as
to how this case is supposed to be handled - a testcase would look
like

struct Base {
   int i : 1;
};
struct Deriv : Base {
   char c;
};

where Deriv::c would be at byte offset 1 (the current code will
allow SImode accesses to Base:i).  Note that in the above case
tail-padding is _not_ reused (for some reason).


We don't re-use the tail padding of Base because it is a POD-struct. 
Adding a user-defined constructor, copy assignment operator or 
destructor should make it non-POD and therefore enable tail padding reuse.


i and c are separate memory locations.

Jason

Re: [PATCH][4.8] C++ memory model bitfield handling rewrite

[Richard Guenther]

On Tue, 7 Feb 2012, Jakub Jelinek wrote:

> On Tue, Feb 07, 2012 at 04:01:31PM +, Jonathan Wakely wrote:
> > > What would it have said for -fabi-version=1 where for
> > > we place s.i and s.d into the same byte?
> > 
> > I think it says they shouldn't be in the same byte :-)
> 
> They don't, except for compatibility with the old ABI.
> I think easiest would be either to error out on -fabi-version=1
> mixed with an explicit option to request C++11 memory model,
> or just ignore it (perhaps with a warning), people who care about the strict
> memory model requirements just shouldn't use -fabi-version=1.
> Using atomic modifications of the byte that has parts of the tail
> padding bits used by another class would be IMHO an overkill.

I agree.  The question is of course whether the C++ memory model
folks thought about this issue in case there is an ABI that requires
this tail-padding reuse (they could have, for example, declared
that s.i and s.d are in the same bitfield - that would have made
things easy).

Richard.

Re: [PATCH][4.8] C++ memory model bitfield handling rewrite

[Richard Guenther]

On Tue, 7 Feb 2012, Hans-Peter Nilsson wrote:

> On Tue, 7 Feb 2012, Richard Guenther wrote:
> > The following patch rewrites the bitfield handling of the C++ memory
> > model and enables it unconditionally to fix PR52080.  As I suggested
> > earlier at some point this moves computation of what the memory model
> > considers the underlying object we may access to the point where we
> > lay out a structure type.  This allows other passes like for example
> > SRA or a new bitfield lowering pass to use a canonical (and correct)
> > addressable object to access bitfields.  The underlying object is
> > represented as a FIELD_DECL that would be a suitable replacement
> > for all bitfield FIELD_DECLs if you wrap it inside a BIT_FIELD_REF
> > (see the gimplify.c hunk).  But the main purpose (for now) is to
> > make use of it in get_bit_range which no longer needs to walk
> > all fields of a record nor build new trees or use get_inner_reference.
> 
> Please excuse an ignorant question: is there somewhere in that
> new code where you should consider target bitfield layout macros
> like EMPTY_FIELD_BOUNDARY and PCC_BITFIELD_TYPE_MATTERS?
> (Just guessing: alignment.)  Or maybe that's a later stage?

No, bitfield layout is unchanged - the only thing that I added
is computing a FIELD_DECL that covers the underlying storage
of a series of adjacent bitfields (as required for example by
the C++ memory model).  This computation simply uses the offsets
of the FIELD_DECLs of the bitfield fields as layed out previously.

Richard.

C++ PATCH for c++/51675 (more constexpr unions)

[Jason Merrill]

More traffic on PR 51675 demonstrates that my earlier patch didn't fix 
the whole problem.  This patch improves handling of user-defined 
constructors.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit 2ebb9d76963c08ebb009a1b6eb8f576eb9e671c0
Author: Jason Merrill 
Date:   Mon Feb 6 14:47:50 2012 -1000

	PR c++/51675
	* semantics.c (cx_check_missing_mem_inits): Handle unions.
	Fix constexpr default constructor logic.

diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 9019962..5646fa7 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -6025,13 +6025,28 @@ cx_check_missing_mem_inits (tree fun, tree body, bool complain)
   bool bad;
   tree field;
   unsigned i, nelts;
+  tree ctype;
 
   if (TREE_CODE (body) != CONSTRUCTOR)
 return false;
 
-  bad = false;
   nelts = CONSTRUCTOR_NELTS (body);
-  field = TYPE_FIELDS (DECL_CONTEXT (fun));
+  ctype = DECL_CONTEXT (fun);
+  field = TYPE_FIELDS (ctype);
+
+  if (TREE_CODE (ctype) == UNION_TYPE)
+{
+  if (nelts == 0 && next_initializable_field (field))
+	{
+	  if (complain)
+	error ("% constructor for union %qT must "
+		   "initialize exactly one non-static data member", ctype);
+	  return true;
+	}
+  return false;
+}
+
+  bad = false;
   for (i = 0; i <= nelts; ++i)
 {
   tree index;
@@ -6050,8 +6065,6 @@ cx_check_missing_mem_inits (tree fun, tree body, bool complain)
 	  if (TREE_CODE (field) != FIELD_DECL
 	  || (DECL_C_BIT_FIELD (field) && !DECL_NAME (field)))
 	continue;
-	  if (!complain)
-	return true;
 	  ftype = strip_array_types (TREE_TYPE (field));
 	  if (type_has_constexpr_default_constructor (ftype))
 	{
@@ -6062,6 +6075,8 @@ cx_check_missing_mem_inits (tree fun, tree body, bool complain)
    || errorcount != 0);
 	  continue;
 	}
+	  if (!complain)
+	return true;
 	  error ("uninitialized member %qD in % constructor",
 		 field);
 	  bad = true;
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-union3.C b/gcc/testsuite/g++.dg/cpp0x/constexpr-union3.C
new file mode 100644
index 000..bac9cab
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-union3.C
@@ -0,0 +1,12 @@
+// PR c++/51675
+// { dg-options -std=c++11 }
+
+union foo
+{
+  int x;
+  short y;
+
+  constexpr foo(): x(0) { }
+};
+
+constexpr foo f;

C++ PATCH for c++/52035 (LTO ICE with typedef in class template)

[Jason Merrill]

The issue here is that when we go to instantiate QVector::insert, 
we use the out-of-class definition which uses the typedef rather than 
the in-class declaration which uses plain int.  But we haven't 
instantiated the typedef yet, so when we look for the instantiation we 
get nothing and end up just returning the template version of the 
typedef.  So we end up referring to uninstantiated trees, which leads to 
an abort in the LTO streamer.


Fixed by stripping the typedef if we don't find an instantiation.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit d8cfecd974c2515465f9be396d52a128db88f9e9
Author: Jason Merrill 
Date:   Mon Feb 6 11:29:37 2012 -1000

	PR c++/52035
	* pt.c (tsubst): Strip uninstantiated typedef.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 4c93b31..a0b2a0b 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -11178,7 +11178,9 @@ tsubst (tree t, tree args, tsubst_flags_t complain, tree in_decl)
 	 complain | tf_ignore_bad_quals);
 	  return r;
 	}
-  /* Else we must be instantiating the typedef, so fall through.  */
+  else
+	/* We don't have an instantiation yet, so drop the typedef.  */
+	t = DECL_ORIGINAL_TYPE (decl);
 }
 
   if (type
diff --git a/gcc/testsuite/g++.dg/lto/README b/gcc/testsuite/g++.dg/lto/README
index 5fa3123..1a13dd9 100644
--- a/gcc/testsuite/g++.dg/lto/README
+++ b/gcc/testsuite/g++.dg/lto/README
@@ -24,9 +24,9 @@ $ g++ -o  a_0.o a_1.o a_2.o
 Tests that do not need more than one file are a special case
 where there is a single file named 'foo_0.C'.
 
-The only supported dg-lto-do option are 'compile', 'run' and 'link'.
+The only supported dg-lto-do option are 'assemble', 'run' and 'link'.
 Additionally, these can only be used in the main file.  If
-'compile' is used, only the individual object files are
+'assemble' is used, only the individual object files are
 generated.  If 'link' is used, the final executable is generated
 but not executed (in this case, function main() needs to exist
 but it does not need to do anything).  If 'run' is used, the
diff --git a/gcc/testsuite/g++.dg/lto/pr52035_0.C b/gcc/testsuite/g++.dg/lto/pr52035_0.C
new file mode 100644
index 000..3de4ea5
--- /dev/null
+++ b/gcc/testsuite/g++.dg/lto/pr52035_0.C
@@ -0,0 +1,14 @@
+// PR c++/52035
+// { dg-lto-do assemble }
+
+template  struct QVector {
+typedef T* iterator;
+static void insert(int n);
+typedef int size_type;
+};
+template  void QVector::insert(size_type n) {}
+void error()
+{
+int n;
+QVector::insert(n);
+}

[Ada] Implementation of simple storage pools for dynamic allocation

[Arnaud Charlet]

The pragma Simple_Storage_Pool is provided for designating a library-level
limited private or limited record type as a simple storage pool type.
This provides an alternative to Ada's standard Storage_Pools, where
the pool type is not required to be tagged or have associated finalization
actions, eliminating the need for run-time support. A simple storage pool type
is defined with an Allocate operation, and optionally can have Deallocate
and Storage_Size operations (as well as other user-defined operations).
An access type can be associated with a pool object by setting the
attribute (or aspect) Simple_Storage_Pool. Allocators for the type will
invoke the pool's Allocate procedure, and unchecked deallocation invokes
the Deallocate operation (if defined).

Tested on x86_64-pc-linux-gnu, committed on trunk

2012-02-08  Gary Dismukes  

* aspects.ads (type Aspect_Id): Add Aspect_Simple_Storage_Pool.
(Impl_Defined_Aspects): Add entry for Aspect_Simple_Storage_Pool.
(Aspect_Argument): Add Name entry for Aspect_Simple_Storage_Pool.
(Aspect_Names): Add entry for Aspect_Simple_Storage_Pool.
* aspects.adb (Canonical_Aspect): Add entry for
Aspect_Simple_Storage_Pool.
* exp_attr.adb (Expand_N_Attribute_Reference): Handle case of
Attribute_Simple_Storage_Pool in the same way as Storage_Pool
(add conversion, analyze/resolve). For the Storage_Size attribute,
for the simple pool case, locate and use the simple pool type's
Storage_Size function (if any), otherwise evaluate to zero.
* exp_ch4.adb (Expand_N_Allocator): In the case of an allocator
for an access type with an associated simple storage pool,
locate and use the pool type's Allocate.
* exp_intr.adb (Expand_Unc_Deallocation): In the case where the
access type has a simple storage pool, locate the pool type's
Deallocate procedure (if present) and use it as the procedure
to call on the Free operation.
* freeze.adb (Freeze_Entity): In the case of a full type for
a private type defined with pragma Simple_Storage_Pool, check
that the full type is also appropriate for the pragma. For
a simple storage pool type, validate that the operations
Allocate, Deallocate (if present), and Storage_Size
(if present) are defined with appropriate expected profiles.
(Validate_Simple_Pool_Op_Formal): New procedure
(Validate_Simple_Pool_Operation): New procedure Add with and
use of Rtsfind.
* par-prag.adb: Add Pragma_Simple_Storage_Pool to case statement
(no action required).
* sem_attr.adb (Analyze_Attribute): For the case of the
Storage_Pool attribute, give a warning if the prefix type has an
associated simple storage pool, and rewrite the attribute as a
raise of Program_Error. In the case of the Simple_Storage_Pool
attribute, check that the prefix type has an associated simple
storage pool, and set the attribute type to the pool's type.
* sem_ch13.adb (Analyze_Aspect_Specifications): Add
Aspect_Simple_Storage_Pool case choice.
(Analyze_Attribute_Definition_Clause): Add
Aspect_Simple_Storage_Pool to case for Ignore_Rep_Clauses
(no action). Add handling for Simple_Storage_Pool attribute
definition, requiring the name to denote a simple storage pool
object.
(Check_Aspect_At_Freeze_Point): For a simple storage pool
aspect, set the type to that of the name specified for the aspect.
* sem_prag.adb (Analyze_Pragma): Add handling for pragma
Simple_Storage_Pool, requiring that it applies to a library-level
type declared in a package declaration that is a limited private
or limited record type.
* sem_res.adb (Resolve_Allocator): Flag an attempt to call a
build-in-place function in an allocator for an access type with
a simple storage pool as unsupported.
* snames.ads-tmpl: Add Name_Simple_Storage_Pool.
(type Attribute_Id): Add Attribute_Simple_Storage_Pool.
(type Pragma_Id): Add Pragma_Simple_Storage_Pool.
* snames.adb-tmpl (Get_Pragma_Id): Handle case of
Name_Simple_Storage_Pool.
(Is_Pragma_Name): Return True for Name_Simple_Storage_Pool.

Index: exp_attr.adb
===
--- exp_attr.adb(revision 183996)
+++ exp_attr.adb(working copy)
@@ -6,7 +6,7 @@
 --  --
 -- B o d y  --
 --  --
---  Copyright (C) 1992-2011, Free Software Foundation, Inc. --
+--  Copyright (C) 1992-2012, Free Software Foundation, Inc. --
 --   

Re: [PATCH] Fix cfg_layout_merge_blocks (PR rtl-optimization/52139)

[Richard Guenther]

On Tue, 7 Feb 2012, Jakub Jelinek wrote:

> Hi!
> 
> On the following testcase we hit two bugs during cfglayout merge_blocks.
> 
> One is that b->il.rtl->header has some jumptable in it, followed by
> barrier.  We call emit_insn_after_noloc to insert the whole b's header
> after BB_END (a) and then delete_insn_chain it, with the intention that only
> non-deletable insns like deleted label notes are kept around.  Unfortunately
> delete_insn/remove_insn it uses isn't prepared to handle BARRIERs as part of
> a bb (i.e. if BB_END is equal to some barrier because of the
> emit_insn_after_noloc call, delete_insn_chain won't update BB_END properly).
> As barriers aren't part of a BB, instead of adjusting remove_insn this patch
> adjusts BB_END not to point to a barrier before calling delete_insn_chain.
> 
> The second bug is that remove_insn ICEs if deleting an insn with NEXT_INSN
> NULL, unless that insn is part of a current sequence (or some sequence in
> the sequence stack).  In the first version of the patch I've tried to
> avoid calling delete_insn on insns that have NEXT_INSN NULL, but given that
> having NULL NEXT_INSN is a pretty common situation when in cfglayout mode
> if the insn is at BB_END, I think it is better to allow that in remove_insn.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> 2012-02-07  Jakub Jelinek  
> 
>   PR rtl-optimization/52139
>   * emit-rtl.c (remove_insn): Allow removing insns
>   with NEXT_INSN NULL, if they are at BB_END.
>   * cfgrtl.c (cfg_layout_merge_blocks): If BB_END
>   is a BARRIER after emit_insn_after_noloc, move BB_END
>   to the last non-BARRIER insn before it.  Cleanup.
> 
>   * gcc.dg/pr52139.c: New test.
> 
> --- gcc/emit-rtl.c.jj 2012-02-07 16:05:47.913534092 +0100
> +++ gcc/emit-rtl.c2012-02-07 16:14:32.529734964 +0100
> @@ -1,7 +1,7 @@
>  /* Emit RTL for the GCC expander.
> Copyright (C) 1987, 1988, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
> 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009,
> -   2010, 2011
> +   2010, 2011, 2012
> Free Software Foundation, Inc.
>  
>  This file is part of GCC.
> @@ -3957,7 +3957,19 @@ remove_insn (rtx insn)
>   break;
> }
>  
> -  gcc_assert (stack);
> +  if (stack == NULL)
> + {
> +   /* In cfglayout mode allow remove_insn of
> +  insns at the end of bb.  */
> +   if (BARRIER_P (insn))
> + {
> +   gcc_assert (prev);
> +   bb = BLOCK_FOR_INSN (prev);
> + }
> +   else
> + bb = BLOCK_FOR_INSN (insn);
> +   gcc_assert (bb && BB_END (bb) == insn);
> + }

Isn't it cheaper to do that before we scan all the sequences?  Thus,
I'd expect BLOCK_FOR_INSN to be NULL if the insn is in a sequence?
Like simply

Index: emit-rtl.c
===
--- emit-rtl.c  (revision 183971)
+++ emit-rtl.c  (working copy)
@@ -3946,7 +3946,7 @@ remove_insn (rtx insn)
 }
   else if (get_last_insn () == insn)
 set_last_insn (prev);
-  else
+  else if (!BLOCK_FOR_INSN (insn))
 {
   struct sequence_stack *stack = seq_stack;
   /* Scan all pending sequences too.  */
@@ -3957,7 +3957,7 @@ remove_insn (rtx insn)
break;
  }
 
-  gcc_assert (stack);
+  gcc_assert (BARRIER_P (insn) || stack);
 }
   if (!BARRIER_P (insn)
   && (bb = BLOCK_FOR_INSN (insn)))

?  I realize that doesn't do the extra assertions, but this is a
pretty core routine and checking of invariants would more belong
to RTL checking.

Richard.


>  }
>if (!BARRIER_P (insn)
>&& (bb = BLOCK_FOR_INSN (insn)))
> --- gcc/cfgrtl.c.jj   2012-02-07 16:05:47.977533716 +0100
> +++ gcc/cfgrtl.c  2012-02-07 17:03:52.925956927 +0100
> @@ -2818,6 +2818,7 @@ static void
>  cfg_layout_merge_blocks (basic_block a, basic_block b)
>  {
>bool forwarder_p = (b->flags & BB_FORWARDER_BLOCK) != 0;
> +  rtx insn;
>  
>gcc_checking_assert (cfg_layout_can_merge_blocks_p (a, b));
>  
> @@ -2871,6 +2872,11 @@ cfg_layout_merge_blocks (basic_block a,
>rtx first = BB_END (a), last;
>  
>last = emit_insn_after_noloc (b->il.rtl->header, BB_END (a), a);
> +  /* The above might add a BARRIER as BB_END, but as barriers
> +  aren't valid parts of a bb, remove_insn doesn't update
> +  BB_END if it is a barrier.  So adjust BB_END here.  */
> +  while (BB_END (a) != first && BARRIER_P (BB_END (a)))
> + BB_END (a) = PREV_INSN (BB_END (a));
>delete_insn_chain (NEXT_INSN (first), last, false);
>b->il.rtl->header = NULL;
>  }
> @@ -2878,40 +2884,28 @@ cfg_layout_merge_blocks (basic_block a,
>/* In the case basic blocks are not adjacent, move them around.  */
>if (NEXT_INSN (BB_END (a)) != BB_HEAD (b))
>  {
> -  rtx first = unlink_insn_chain (BB_HEAD (b), BB_END (b));
> +  insn = unlink_insn_chain (BB_HEAD (b), BB_END (b));
>  
> -  emit_insn_a

[Ada] New procedure to get a context while parsing a project tree

[Arnaud Charlet]

No test as no change in behavior. This is for gprbuild.

Tested on x86_64-pc-linux-gnu, committed on trunk

2012-02-08  Pascal Obry  

* prj.ads, prj.adb (For_Project_And_Aggregated_Context): New
generic routine with a context parameter.

Index: prj.adb
===
--- prj.adb (revision 183996)
+++ prj.adb (working copy)
@@ -1863,6 +1863,56 @@
   end if;
end For_Project_And_Aggregated;
 
+   
+   -- For_Project_And_Aggregated_Context --
+   
+
+   procedure For_Project_And_Aggregated_Context
+ (Root_Project : Project_Id;
+  Root_Tree: Project_Tree_Ref)
+   is
+
+  procedure Recursive_Process
+(Project : Project_Id;
+ Tree: Project_Tree_Ref;
+ Context : Project_Context);
+  --  Process Project and all aggregated projects recursively
+
+  ---
+  -- Recursive_Process --
+  ---
+
+  procedure Recursive_Process
+(Project : Project_Id;
+ Tree: Project_Tree_Ref;
+ Context : Project_Context)
+  is
+ Agg : Aggregated_Project_List;
+ Ctx : Project_Context;
+  begin
+ Action (Project, Tree, Context);
+
+ if Project.Qualifier in Aggregate_Project then
+Ctx :=
+  (In_Aggregate_Lib  => True,
+   From_Encapsulated_Lib =>
+ Context.From_Encapsulated_Lib
+   or else
+ Project.Standalone_Library = Encapsulated);
+
+Agg := Project.Aggregated_Projects;
+while Agg /= null loop
+   Recursive_Process (Agg.Project, Agg.Tree, Ctx);
+   Agg := Agg.Next;
+end loop;
+ end if;
+  end Recursive_Process;
+
+   begin
+  Recursive_Process
+(Root_Project, Root_Tree, Project_Context'(False, False));
+   end For_Project_And_Aggregated_Context;
+
 --  Package initialization for Prj
 
 begin
Index: prj.ads
===
--- prj.ads (revision 183996)
+++ prj.ads (working copy)
@@ -1621,7 +1621,18 @@
   With_State : in out State;
   Include_Aggregated : Boolean := True;
   Imported_First : Boolean := False);
+   --  As above but with an associated context
 
+   generic
+  with procedure Action
+(Project : Project_Id;
+ Tree: Project_Tree_Ref;
+ Context : Project_Context);
+   procedure For_Project_And_Aggregated_Context
+ (Root_Project : Project_Id;
+  Root_Tree: Project_Tree_Ref);
+   --  As above but with an associated context
+
function Extend_Name
  (File: File_Name_Type;
   With_Suffix : String) return File_Name_Type;

[Ada] Set proper context for encapsulated aggregate libraries

[Arnaud Charlet]

No change in behavior. This is for gprbuild.

Tested on x86_64-pc-linux-gnu, committed on trunk

2012-02-08  Pascal Obry  

* prj.adb (Compute_All_Imported_Projects): Use new
For_Project_And_Aggregated_Context to ensure proper context is
used for encapsulated aggregate libraries.
* prj-proc.adb (Recursive_Process): Call
Process_Aggregated_Projects earlier to ensure that all dependent
projects are set with the proper encapsulated status.

Index: prj.adb
===
--- prj.adb (revision 183998)
+++ prj.adb (working copy)
@@ -1476,7 +1476,8 @@
is
   procedure Analyze_Tree
 (Local_Root : Project_Id;
- Local_Tree : Project_Tree_Ref);
+ Local_Tree : Project_Tree_Ref;
+ Context: Project_Context);
   --  Process Project and all its aggregated project to analyze their own
   --  imported projects.
 
@@ -1486,7 +1487,8 @@
 
   procedure Analyze_Tree
 (Local_Root : Project_Id;
- Local_Tree : Project_Tree_Ref)
+ Local_Tree : Project_Tree_Ref;
+ Context: Project_Context)
   is
  pragma Unreferenced (Local_Root);
 
@@ -1540,7 +1542,9 @@
Project.All_Imported_Projects :=
  new Project_List_Element'
(Project   => Prj2,
-From_Encapsulated_Lib => Context.From_Encapsulated_Lib,
+From_Encapsulated_Lib =>
+  Context.From_Encapsulated_Lib
+or else Analyze_Tree.Context.From_Encapsulated_Lib,
 Next  => Project.All_Imported_Projects);
 end if;
  end Recursive_Add;
@@ -1564,7 +1568,7 @@
   end Analyze_Tree;
 
   procedure For_Aggregates is
-new For_Project_And_Aggregated (Analyze_Tree);
+new For_Project_And_Aggregated_Context (Analyze_Tree);
 
--  Start of processing for Compute_All_Imported_Projects
 
Index: prj-proc.adb
===
--- prj-proc.adb(revision 183996)
+++ prj-proc.adb(working copy)
@@ -2908,6 +2908,10 @@
 
 Process_Imported_Projects (Imported, Limited_With => True);
 
+if Err_Vars.Total_Errors_Detected = 0 then
+   Process_Aggregated_Projects;
+end if;
+
 --  At this point (after Process_Declarative_Items) we have the
 --  attribute values set, we can backtrace In_Tree.Project and
 --  set the From_Encapsulated_Library status.
@@ -2935,7 +2939,6 @@
end if;
 
if Err_Vars.Total_Errors_Detected = 0 then
-  Process_Aggregated_Projects;
 
   --  For an aggregate library we add the aggregated projects
   --  as imported ones. This is necessary to give visibility

Re: [PATCH] fix PR51910, take 2

[Jason Merrill]

On 02/02/2012 11:27 PM, Jakub Jelinek wrote:

Anyway, here is the tweaking all the symbols that demangle the same
equally patch (untested so far) as an alternative.  On the example it
unfortunately causes also the D2 dtor into the link which wasn't there
otherwise (and with -Wl,--no-demangle).  While D2 dtors are generally small,
perhaps it will sometimes force into the link also ctor or dtor variants
that couldn't be aliased together.


Hmm, I wrote up something quite similar on the plane.  One difference is 
that mine synchronizes .rpo files that start with some variants chosen 
and others not.  Does this make sense to you?



I wonder if it wouldn't be better to just use a linker plugin for -frepo
if the linker supports plugins.


Probably.  But I don't feel motivated to write it.

Jason
commit 1f4b0d273cfd81948762d3922cdafac40a06a2cf
Author: Jason Merrill 
Date:   Thu Feb 2 00:07:44 2012 -0500

	PR c++/51910
	* tlink.c (demangled_hash_entry): Change mangled to a VEC.
	(demangle_new_symbols): Fill it.
	(scan_linker_output): Walk it.
	(start_tweaking): Split out from scan_linker_output.
	(maybe_tweak): Update sym->chosen.
	* Makefile.in (COLLECT2_OBJS): Add vec.o and gcc-none.o

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index c9ecc4b..486538d 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1946,7 +1946,7 @@ gcc-ranlib.c: gcc-ar.c
 gcc-nm.c: gcc-ar.c
 	cp $^ $@
 
-COLLECT2_OBJS = collect2.o collect2-aix.o tlink.o
+COLLECT2_OBJS = collect2.o collect2-aix.o tlink.o vec.o ggc-none.o
 COLLECT2_LIBS = @COLLECT2_LIBS@
 collect2$(exeext): $(COLLECT2_OBJS) $(LIBDEPS)
 # Don't try modifying collect2 (aka ld) in place--it might be linking this.
diff --git a/gcc/testsuite/g++.dg/template/repo10.C b/gcc/testsuite/g++.dg/template/repo10.C
new file mode 100644
index 000..c92f7a5
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/repo10.C
@@ -0,0 +1,16 @@
+// PR c++/51910
+// { dg-options -frepo }
+// { dg-require-host-local "" }
+// { dg-skip-if "dkms are not final links" { vxworks_kernel } }
+// { dg-final cleanup-repo-files }
+
+template
+struct Foo
+{
+  virtual ~Foo() { }
+};
+
+int main( int, char*[] )
+{
+  Foo test;
+}
diff --git a/gcc/tlink.c b/gcc/tlink.c
index f054047..67c7086 100644
--- a/gcc/tlink.c
+++ b/gcc/tlink.c
@@ -32,6 +32,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "collect2.h"
 #include "filenames.h"
 #include "diagnostic-core.h"
+#include "vec.h"
 
 /* TARGET_64BIT may be defined to use driver specific functionality. */
 #undef TARGET_64BIT
@@ -67,10 +68,14 @@ typedef struct file_hash_entry
   int tweaking;
 } file;
 
+typedef const char *str;
+DEF_VEC_P(str);
+DEF_VEC_ALLOC_P(str,heap);
+
 typedef struct demangled_hash_entry
 {
   const char *key;
-  const char *mangled;
+  VEC(str,heap) *mangled;
 } demangled;
 
 /* Hash and comparison functions for these hash tables.  */
@@ -435,9 +440,15 @@ maybe_tweak (char *line, file *f)
   sym->tweaked = 1;
 
   if (line[0] == 'O')
-	line[0] = 'C';
+	{
+	  line[0] = 'C';
+	  sym->chosen = 1;
+	}
   else
-	line[0] = 'O';
+	{
+	  line[0] = 'O';
+	  sym->chosen = 0;
+	}
 }
 }
 
@@ -598,10 +609,34 @@ demangle_new_symbols (void)
 	continue;
 
   dem = demangled_hash_lookup (p, true);
-  dem->mangled = sym->key;
+  VEC_safe_push (str, heap, dem->mangled, sym->key);
 }
 }
 
+/* We want to tweak symbol SYM.  Return true if all is well, false on
+   error.  */
+
+static bool
+start_tweaking (symbol *sym)
+{
+  if (sym && sym->tweaked)
+{
+  error ("'%s' was assigned to '%s', but was not defined "
+	 "during recompilation, or vice versa",
+	 sym->key, sym->file->key);
+  return 0;
+}
+  if (sym && !sym->tweaking)
+{
+  if (tlink_verbose >= 2)
+	fprintf (stderr, _("collect: tweaking %s in %s\n"),
+		 sym->key, sym->file->key);
+  sym->tweaking = 1;
+  file_push (sym->file);
+}
+  return true;
+}
+
 /* Step through the output of the linker, in the file named FNAME, and
adjust the settings for each symbol encountered.  */
 
@@ -616,8 +651,11 @@ scan_linker_output (const char *fname)
 {
   char *p = line, *q;
   symbol *sym;
+  demangled *dem = 0;
   int end;
   int ok = 0;
+  unsigned ix;
+  str s;
 
   /* On darwin9, we might have to skip " in " lines as well.  */
   if (skip_next_in_line
@@ -662,7 +700,6 @@ scan_linker_output (const char *fname)
 	/* Try a mangled name in quotes.  */
 	{
 	  char *oldq = q + 1;
-	  demangled *dem = 0;
 	  q = 0;
 
 	  /* On darwin9, we look for "foo" referenced from:\n\(.* in .*\n\)*  */
@@ -718,9 +755,7 @@ scan_linker_output (const char *fname)
 	{
 	  *q = 0;
 	  dem = demangled_hash_lookup (p, false);
-	  if (dem)
-		sym = symbol_hash_lookup (dem->mangled, false);
-	  else
+	  if (!dem)
 		{
 		  if (!strncmp (p, USER_LABEL_PREFIX,
 strlen (USER_LABEL_PREFIX)))
@@ -730,24 +765,43 @@ scan_linker_output (const char *fname)

Re: [Ada] Do not pass -Werror during linking

[Richard Guenther]

On Tue, Feb 7, 2012 at 10:11 PM, Eric Botcazou  wrote:
> This breaks LTO bootstrap because of warnings for apparently incompatible 
> types
> at the interface between C and Ada.  Given that it's very likely not possible
> to fix them all, let's keep accepting them.
>
> Tested on i586-suse-linux, applied on the mainline.

Can you try to extract a testcase (assuming it's just a single case?).
 We shouldn't
warn for layout-compatible types (but we may do so if for example struct
nesting differs).

Thanks,
Richard.

>
> 2012-02-07  Eric Botcazou  
>
>        * gcc-interface/Make-lang.in (GCC_LINKERFLAGS): New variable.
>        (GCC_LINK): Use it.
>
>
> --
> Eric Botcazou

[Ada] -gnatwA should suppress mod warning

[Arnaud Charlet]

This patch causes -gnatwA to suppress the warning was intended.

Tested on x86_64-pc-linux-gnu, committed on trunk

2012-02-08  Bob Duff  

* warnsw.adb (Set_Warning_Switch): Set Warn_On_Suspicious_Modulus_Value
False for '-gnatwA', to suppress these warnings.

Index: warnsw.adb
===
--- warnsw.adb  (revision 183996)
+++ warnsw.adb  (working copy)
@@ -6,7 +6,7 @@
 --  --
 -- B o d y  --
 --  --
---  Copyright (C) 1999-2011, Free Software Foundation, Inc. --
+--  Copyright (C) 1999-2012, Free Software Foundation, Inc. --
 --  --
 -- GNAT is free software;  you can  redistribute it  and/or modify it under --
 -- terms of the  GNU General Public License as published  by the Free Soft- --
@@ -308,6 +308,7 @@
 Warn_On_Redundant_Constructs:= False;
 Warn_On_Reverse_Bit_Order   := False;
 Warn_On_Suspicious_Contract := False;
+Warn_On_Suspicious_Modulus_Value:= False;
 Warn_On_Unchecked_Conversion:= False;
 Warn_On_Unordered_Enumeration_Type  := False;
 Warn_On_Unrecognized_Pragma := False;

[Ada] Mark Exceptional_Complete_Rendezvous No_Return

[Arnaud Charlet]

This change marks Exceptional_Complete_Rendezvous No_Return, which can
be useful for code generation purposes, and can also help static analyzers.

Tested on x86_64-pc-linux-gnu, committed on trunk

2012-02-08  Arnaud Charlet  

* s-tasren.adb, s-tasren.ads (Internal_Complete_Rendezvous): New
function.
(Complete_Rendezvous): Now call Internal_Complete_Rendezvous.
(Exceptional_Complete_Rendezvous): Mark No_Return.

Index: s-tasren.adb
===
--- s-tasren.adb(revision 183996)
+++ s-tasren.adb(working copy)
@@ -6,7 +6,7 @@
 --  --
 -- B o d y  --
 --  --
--- Copyright (C) 1992-2011, Free Software Foundation, Inc.  --
+-- Copyright (C) 1992-2012, Free Software Foundation, Inc.  --
 --  --
 -- GNARL is free software; you can  redistribute it  and/or modify it under --
 -- terms of the  GNU General Public License as published  by the Free Soft- --
@@ -107,6 +107,12 @@
--  debugging it may be wise to modify the above renamings to the
--  non-nestable forms.
 
+   procedure Local_Complete_Rendezvous (Ex : Ada.Exceptions.Exception_Id);
+   --  Internal version of Complete_Rendezvous, used to implement
+   --  Complete_Rendezvous and Exceptional_Complete_Rendezvous.
+   --  Should be called holding no locks, generally with abort not yet
+   --  deferred.
+
procedure Boost_Priority (Call : Entry_Call_Link; Acceptor : Task_Id);
pragma Inline (Boost_Priority);
--  Call this only with abort deferred and holding lock of Acceptor
@@ -498,7 +504,7 @@
 
procedure Complete_Rendezvous is
begin
-  Exceptional_Complete_Rendezvous (Ada.Exceptions.Null_Id);
+  Local_Complete_Rendezvous (Ada.Exceptions.Null_Id);
end Complete_Rendezvous;
 
-
@@ -508,19 +514,33 @@
procedure Exceptional_Complete_Rendezvous
  (Ex : Ada.Exceptions.Exception_Id)
is
+  procedure Internal_Reraise;
+  pragma No_Return (Internal_Reraise);
+  pragma Import (C, Internal_Reraise, "__gnat_reraise");
+
+   begin
+  Local_Complete_Rendezvous (Ex);
+  Internal_Reraise;
+
+  --  ??? Do we need to give precedence to Program_Error that might be
+  --  raised due to failure of finalization, over Tasking_Error from
+  --  failure of requeue?
+   end Exceptional_Complete_Rendezvous;
+
+   ---
+   -- Local_Complete_Rendezvous --
+   ---
+
+   procedure Local_Complete_Rendezvous (Ex : Ada.Exceptions.Exception_Id) is
   Self_Id: constant Task_Id := STPO.Self;
   Entry_Call : Entry_Call_Link := Self_Id.Common.Call;
   Caller : Task_Id;
   Called_PO  : STPE.Protection_Entries_Access;
   Acceptor_Prev_Priority : Integer;
 
-  Exception_To_Raise : Ada.Exceptions.Exception_Id := Ex;
   Ceiling_Violation  : Boolean;
 
   use type Ada.Exceptions.Exception_Id;
-  procedure Internal_Reraise;
-  pragma Import (C, Internal_Reraise, "__gnat_reraise");
-
   procedure Transfer_Occurrence
 (Target : Ada.Exceptions.Exception_Occurrence_Access;
  Source : Ada.Exceptions.Exception_Occurrence);
@@ -529,18 +549,12 @@
   use type STPE.Protection_Entries_Access;
 
begin
-  --  Consider phasing out Complete_Rendezvous in favor of direct call to
-  --  this with Ada.Exceptions.Null_ID. See code expansion examples for
-  --  Accept_Call and Selective_Wait. Also consider putting an explicit
-  --  re-raise after this call, in the generated code. That way we could
-  --  eliminate the code here that reraises the exception.
-
   --  The deferral level is critical here, since we want to raise an
   --  exception or allow abort to take place, if there is an exception or
   --  abort pending.
 
   pragma Debug
-   (Debug.Trace (Self_Id, "Exceptional_Complete_Rendezvous", 'R'));
+(Debug.Trace (Self_Id, "Local_Complete_Rendezvous", 'R'));
 
   if Ex = Ada.Exceptions.Null_Id then
 
@@ -632,10 +646,8 @@
 
if Ceiling_Violation then
   pragma Assert (Ex = Ada.Exceptions.Null_Id);
+  Entry_Call.Exception_To_Raise := Program_Error'Identity;
 
-  Exception_To_Raise := Program_Error'Identity;
-  Entry_Call.Exception_To_Raise := Exception_To_Raise;
-
   if Single_Lock then
  Lock_RTS;
   end if;
@@ -692,17 +704,8 @@
   end if;
 
   Initialization.Undefer_Abort (Self_Id);
+   end Local_Complete_Rendezvous;
 
-  

[Ada] Fix internal error on constant with nested variant part

[Arnaud Charlet]

This fixes an internal error in the gimplifier when it is trying to generate
code for a CONSTRUCTOR of a record type with a component whose type contains
a variant part.

The handling of this kind of CONSTRUCTORs is delicate and the front-end has a
special circuitry to pre-decompose them (or rather aggregates, as they are
called in Ada) into assignments.  This circuitry was recently adjusted to be
less conservative, so as to let the back-end build fully static objects in
more cases.

However, when they cannot be built statically because they contain non-static
parts, aggregates of this sort need always be pre-decomposed.  The change
makes sure this is the case.  But, in order not to go back too far on the
conservative side, it also enhances the circuitry that computes whether an
aggregate can be built statically or not.

The following code must compile quietly:

with Aggr4_Pkg; use Aggr4_Pkg;

package Aggr4 is

   C : constant Rec3 := (Data => (D => One, Value => Zero));

end Aggr4;

package Aggr4_Pkg is

   function F return Integer;

   type Rec1 is tagged record
  I : Integer;
   end record;

   Zero : constant Rec1 := (I => F);

   type Enum is (One, Two);

   type Rec2 (D : Enum := One) is record
  case D is
 when One => Value : Rec1;
 when others => null;
  end case;
   end record;

   type Rec3 is record
  Data : Rec2;
   end record;

end Aggr4_Pkg;  

Tested on x86_64-pc-linux-gnu, committed on trunk

2012-02-08  Eric Botcazou  

* exp_aggr.adb (Compile_Time_Known_Composite_Value):
New predicate to compute whether a composite value can be
evaluated at compile time.
(Component_Not_OK_For_Backend): Use Compile_Time_Known_Value for all
expressions of elementary type and Compile_Time_Known_Composite_Value
for all other expressions.
(Expand_Record_Aggregate): Convert to assignments in the case
of a type with mutable components if the aggregate cannot be
built statically.

Index: exp_aggr.adb
===
--- exp_aggr.adb(revision 183996)
+++ exp_aggr.adb(working copy)
@@ -5115,6 +5115,14 @@
   --  and the aggregate can be constructed statically and handled by
   --  the back-end.
 
+  function Compile_Time_Known_Composite_Value (N : Node_Id) return Boolean;
+  --  Returns true if N is an expression of composite type which can be
+  --  fully evaluated at compile time without raising constraint error.
+  --  Such expressions can be passed as is to Gigi without any expansion.
+  --
+  --  This returns true for N_Aggregate with Compile_Time_Known_Aggregate
+  --  set and constants whose expression is such an aggregate, recursively.
+
   function Component_Not_OK_For_Backend return Boolean;
   --  Check for presence of component which makes it impossible for the
   --  backend to process the aggregate, thus requiring the use of a series
@@ -5145,6 +5153,46 @@
   --  For nested aggregates return the ultimate enclosing aggregate; for
   --  non-nested aggregates return N.
 
+  
+  -- Compile_Time_Known_Composite_Value --
+  
+
+  function Compile_Time_Known_Composite_Value (N : Node_Id) return Boolean
+  is
+
+  begin
+ --  If we have an entity name, then see if it is the name of a
+ --  constant and if so, test the corresponding constant value.
+
+ if Is_Entity_Name (N) then
+declare
+   E : constant Entity_Id := Entity (N);
+   V : Node_Id;
+
+begin
+   if Ekind (E) /= E_Constant then
+  return False;
+   end if;
+
+   V := Constant_Value (E);
+   return Present (V)
+ and then Compile_Time_Known_Composite_Value (V);
+end;
+
+ --  We have a value, see if it is compile time known
+
+ else
+if Nkind (N) = N_Aggregate then
+   return Compile_Time_Known_Aggregate (N);
+end if;
+
+--  All other types of values are not known at compile time
+
+return False;
+ end if;
+
+  end Compile_Time_Known_Composite_Value;
+
   --
   -- Component_Not_OK_For_Backend --
   --
@@ -5201,14 +5249,12 @@
return True;
 end if;
 
-if Is_Scalar_Type (Etype (Expr_Q)) then
+if Is_Elementary_Type (Etype (Expr_Q)) then
if not Compile_Time_Known_Value (Expr_Q) then
   Static_Components := False;
end if;
 
-elsif Nkind (Expr_Q) /= N_Aggregate
-  or else not Compile_Time_Known_Aggregate (Expr_Q)
-then
+elsif not Compile_Time_Known_Composit

[Ada] Remove code duplication in Scn and Sinput.P

[Arnaud Charlet]

No functionality modified.

Tested on x86_64-pc-linux-gnu, committed on trunk

2012-02-08  Vincent Celier  

* gcc-interface/Make-lang.in: Add g-byorma.o to gnatbind objects
(g-buorma is now imported by sinput).
Update dependencies.
* scn.adb (Initialize_Scanner): Call Check_For_BOM
* sinput-p.adb (Source_File_Is_Subunit): Call Check_For_BOM
* sinput.adb: New procedure Check_For_BOM
* sinput.ads: New procedure Check_For_BOM

Index: sinput.adb
===
--- sinput.adb  (revision 183996)
+++ sinput.adb  (working copy)
@@ -6,7 +6,7 @@
 --  --
 -- B o d y  --
 --  --
---  Copyright (C) 1992-2011, Free Software Foundation, Inc. --
+--  Copyright (C) 1992-2012, Free Software Foundation, Inc. --
 --  --
 -- GNAT is free software;  you can  redistribute it  and/or modify it under --
 -- terms of the  GNU General Public License as published  by the Free Soft- --
@@ -36,11 +36,15 @@
 with Debug;use Debug;
 with Opt;  use Opt;
 with Output;   use Output;
+with Scans;use Scans;
 with Tree_IO;  use Tree_IO;
-with System;   use System;
 with Widechar; use Widechar;
 
+with GNAT.Byte_Order_Mark; use GNAT.Byte_Order_Mark;
+
+with System; use System;
 with System.Memory;
+with System.WCh_Con; use System.WCh_Con;
 
 with Unchecked_Conversion;
 with Unchecked_Deallocation;
@@ -246,6 +250,44 @@
   return Name_Buffer (1 .. Name_Len);
end Build_Location_String;
 
+   procedure Check_For_BOM is
+  BOM : BOM_Kind;
+  Len : Natural;
+  Tst : String (1 .. 5);
+
+   begin
+  for J in 1 .. 5 loop
+ Tst (J) := Source (Scan_Ptr + Source_Ptr (J) - 1);
+  end loop;
+
+  Read_BOM (Tst, Len, BOM, False);
+
+  case BOM is
+ when UTF8_All =>
+Scan_Ptr := Scan_Ptr + Source_Ptr (Len);
+Wide_Character_Encoding_Method := WCEM_UTF8;
+Upper_Half_Encoding := True;
+
+ when UTF16_LE | UTF16_BE =>
+Set_Standard_Error;
+Write_Line ("UTF-16 encoding format not recognized");
+Set_Standard_Output;
+raise Unrecoverable_Error;
+
+ when UTF32_LE | UTF32_BE =>
+Set_Standard_Error;
+Write_Line ("UTF-32 encoding format not recognized");
+Set_Standard_Output;
+raise Unrecoverable_Error;
+
+ when Unknown =>
+null;
+
+ when others =>
+raise Program_Error;
+  end case;
+   end Check_For_BOM;
+
---
-- Get_Column_Number --
---
Index: sinput.ads
===
--- sinput.ads  (revision 183996)
+++ sinput.ads  (working copy)
@@ -6,7 +6,7 @@
 --  --
 -- S p e c  --
 --  --
---  Copyright (C) 1992-2011, Free Software Foundation, Inc. --
+--  Copyright (C) 1992-2012, Free Software Foundation, Inc. --
 --  --
 -- GNAT is free software;  you can  redistribute it  and/or modify it under --
 -- terms of the  GNU General Public License as published  by the Free Soft- --
@@ -712,6 +712,16 @@
--  Writes out internal tables to current tree file using the relevant
--  Table.Tree_Write routines.
 
+   procedure Check_For_BOM;
+   --  Check if the current source starts with a BOM. Scan_Ptr needs to be at
+   --  the start of the current source.
+   --  If the current source starts with a recognized BOM, then some flags
+   --  such as Wide_Character_Encoding_Method are set accordingly.
+   --  An exception is raised if a BOM is found that indicates an unrecognized
+   --  format.
+   --  This procedure has no effect if there is no BOM at the beginning of the
+   --  current source.
+
 private
pragma Inline (File_Name);
pragma Inline (First_Mapped_Line);
Index: sinput-p.adb
===
--- sinput-p.adb(revision 184003)
+++ sinput-p.adb(working copy)
@@ -26,15 +26,10 @@
 with Ada.Unchecked_Conversion;
 with Ada.Unchecked_Deallocation;
 
-with GNAT.Byte_Order_Mark; use GNAT.Byte_Order_Mark;
-
-with Opt; use Opt;
-with Output;  use Output;
 with Prj.Err;
 with Sinput.C;
 
 with System;
-with System.WCh_Con; use System.WCh_Con;
 
 package body Sinput.P is
 
@@ -169,46 +164,8 @@
   Prj.Err.Scanner.Set_Specia

[Ada] Documentation for GNAT dimensionality checking system

[Arnaud Charlet]

Tested on x86_64-pc-linux-gnu, committed on trunk

2012-02-08  Vincent Pucci  

* impunit.adb: Dimension package names updated
* Makefile.rtl: s-dim added
* sem_dim.adb (Is_Procedure_Put_Call): minor changes
(Is_Dim_IO_Package_Instantiation): minor changes
* sem_dim.ads: minor changes in comments
* snames.ads-tmpl: Name_Dim added Name_Dim_Float_IO and
Name_Dim_Integer_IO removed
* s-dim.ads: New package. Define the dimension terminology.
* s-diflio.adb, s-diinio.adb, s-dimkio.ads, s-dimmks.ads,
* s-dmotpr.ads: Package names updated.
* s-diflio.ads, s-diinio.ads: Documentation added and package
names updated.

Index: impunit.adb
===
--- impunit.adb (revision 183996)
+++ impunit.adb (working copy)
@@ -6,7 +6,7 @@
 --  --
 -- B o d y  --
 --  --
---   Copyright (C) 2000-2011, Free Software Foundation, Inc.--
+--   Copyright (C) 2000-2012, Free Software Foundation, Inc.--
 --  --
 -- GNAT is free software;  you can  redistribute it  and/or modify it under --
 -- terms of the  GNU General Public License as published  by the Free Soft- --
@@ -366,11 +366,11 @@
 
 ("s-addima", F),  -- System.Address_Image
 ("s-assert", F),  -- System.Assertions
-("s-diflio", F),  -- System.Dim_Float_IO
-("s-diinio", F),  -- System.Dim_Integer_IO
-("s-dimkio", F),  -- System.Dim_Mks_IO
-("s-dimmks", F),  -- System.Dim_Mks
-("s-dmotpr", F),  -- System.Dim_Mks.Other_Prefixes
+("s-diflio", F),  -- System.Dim.Float_IO
+("s-diinio", F),  -- System.Dim.Integer_IO
+("s-dimkio", F),  -- System.Dim.Mks_IO
+("s-dimmks", F),  -- System.Dim.Mks
+("s-dmotpr", F),  -- System.Dim.Mks.Other_Prefixes
 ("s-memory", F),  -- System.Memory
 ("s-parint", F),  -- System.Partition_Interface
 ("s-pooglo", F),  -- System.Pool_Global
Index: s-diinio.adb
===
--- s-diinio.adb(revision 183996)
+++ s-diinio.adb(working copy)
@@ -2,7 +2,7 @@
 --  --
 -- GNAT RUN-TIME COMPONENTS --
 --  --
---  S Y S T E M . D I M _ I N T E G E R _ I O   --
+--  S Y S T E M . D I M . I N T E G E R _ I O   --
 --  --
 -- B o d y  --
 --  --
@@ -29,7 +29,7 @@
 --  --
 --
 
-package body System.Dim_Integer_IO is
+package body System.Dim.Integer_IO is
 
package Num_Dim_Integer_IO is new Ada.Text_IO.Integer_IO (Num_Dim_Integer);
 
@@ -74,4 +74,4 @@
   To := To & Symbols;
end Put;
 
-end System.Dim_Integer_IO;
+end System.Dim.Integer_IO;
Index: s-diinio.ads
===
--- s-diinio.ads(revision 183996)
+++ s-diinio.ads(working copy)
@@ -2,7 +2,7 @@
 --  --
 -- GNAT RUN-TIME COMPONENTS --
 --  --
---  S Y S T E M . D I M _ I N T E G E R _ I O   --
+--  S Y S T E M . D I M . I N T E G E R _ I O   --
 --  --
 -- S p e c  --
 --  --
@@ -29,19 +29,81 @@
 --  --
 --
 
---  This package is a generic package that provides IO facilities for integer
---  dimensioned types.
+--  This package provides output routines for integer dimensioned types. All
+--  Put routines are modelled after those in package Ada.Text_IO.Integer_IO
+--  with the addition of an extra default parameter.
 
---  Note that there is a default string parameter in every Put routine
---  rewritten at compile time to output the corresponding dimensions as a
--- 

Re: [PATCH] Fix cfg_layout_merge_blocks (PR rtl-optimization/52139)

[Jakub Jelinek]

On Wed, Feb 08, 2012 at 10:27:42AM +0100, Richard Guenther wrote:
> Isn't it cheaper to do that before we scan all the sequences?  Thus,
> I'd expect BLOCK_FOR_INSN to be NULL if the insn is in a sequence?
> Like simply

Actually, on a third look, the emit-rtl.c changes aren't needed,
apparently NEXT_INSN even in cfglayout mode is NULL for the in bb
insns only if it is equal to get_last_insn (), unless in the header/footer
sequences, but for those one shouldn't call remove_insn.

To fix this bug the
+  /* The above might add a BARRIER as BB_END, but as barriers
+aren't valid parts of a bb, remove_insn doesn't update
+BB_END if it is a barrier.  So adjust BB_END here.  */
+  while (BB_END (a) != first && BARRIER_P (BB_END (a)))
+   BB_END (a) = PREV_INSN (BB_END (a));
hunk is all that is needed (and the remaining cfgrtl.c hunks
just a nice to have cleanup, could be postponed for 4.8).
Without this BB_END (a) is a barrier, but deleted one, so get_last_insn ()
was actually moved to some insn before it and therefore when we
emit_insn_after_noloc the b bb unchained sequence, it doesn't match
get_last_insn () when it should.

I'll bootstrap/regtest now just that single hunk, is that ok for
trunk/4.6/4.5?

Jakub

Re: Memory corruption due to word sharing

[Jason Merrill]

On 02/07/2012 05:32 AM, Aldy Hernandez wrote:

struct A {
  virtual void f();
  int f1 : 1;<--- bit 64
};

struct B : public A {
  int f2 : 1; // { dg-warning "ABI" }<--- bit 65
  int : 0;
  int f3 : 4;
  int f4 : 3;
};


It is my understanding that f1 and f2 must be in distinct memory
regions. So writing to f1 cannot clobber f2.


That's my understanding as well.

Jason

Re: [PATCH] Fix cfg_layout_merge_blocks (PR rtl-optimization/52139)

[Richard Guenther]

On Wed, 8 Feb 2012, Jakub Jelinek wrote:

> On Wed, Feb 08, 2012 at 10:27:42AM +0100, Richard Guenther wrote:
> > Isn't it cheaper to do that before we scan all the sequences?  Thus,
> > I'd expect BLOCK_FOR_INSN to be NULL if the insn is in a sequence?
> > Like simply
> 
> Actually, on a third look, the emit-rtl.c changes aren't needed,
> apparently NEXT_INSN even in cfglayout mode is NULL for the in bb
> insns only if it is equal to get_last_insn (), unless in the header/footer
> sequences, but for those one shouldn't call remove_insn.
> 
> To fix this bug the
> +  /* The above might add a BARRIER as BB_END, but as barriers
> +aren't valid parts of a bb, remove_insn doesn't update
> +BB_END if it is a barrier.  So adjust BB_END here.  */
> +  while (BB_END (a) != first && BARRIER_P (BB_END (a)))
> +   BB_END (a) = PREV_INSN (BB_END (a));
> hunk is all that is needed (and the remaining cfgrtl.c hunks
> just a nice to have cleanup, could be postponed for 4.8).
> Without this BB_END (a) is a barrier, but deleted one, so get_last_insn ()
> was actually moved to some insn before it and therefore when we
> emit_insn_after_noloc the b bb unchained sequence, it doesn't match
> get_last_insn () when it should.
> 
> I'll bootstrap/regtest now just that single hunk, is that ok for
> trunk/4.6/4.5?

Yes.

Thanks,
Richard.

Re: [PATCH][ARM] Improve 64-bit shifts (non-NEON)

[Andrew Stubbs]

On 07/02/12 22:19, Ramana Radhakrishnan wrote:

I find it interesting that cond_exec's in this form survive all the
way till reload and "work".  AFAIK we could never have cond_exec's
before reload . The documentation doesn't appear to mention this,
therefore I would like to see if  the cond_exec's can be recast as
if_then_else forms from expand rather than these forms. Has this
survived bootstrap and testing ?


I've tried to do this, but it can't be done by a straight translation 
because we don't have the insns available to do it. As I understand it, 
all "predicable" instructions automatically get a cond_exec variant, but 
the only if_then_else I could find (it's hard to grep because 
if_then_else occurs many times in attributes) is in the conditional move 
instruction. Have I missed something?


Anyway, I've tried to redo it using conditional move, and that works, 
but it's not as efficient.


Hopefully Steven Bosscher is correct, and there's no problem with 
cond_exec on ARM.



+  /* If we're optimizing for size, we prefer the libgcc calls.  */
+  if (optimize_size)
+   FAIL;


In addition you want to replace optimize_size with
optimize_function_for_size_p in these cases.


Ok, I've fixed this. I'll post an update soon.

Unfortunately, my testing has found a problem in the native bootstrap, 
so I'm going to need to track that down first.


Andrew

Re: [trans-mem,darwin] PR/52042 find tm_clone_table with PIE

[Iain Sandoe]

Hi Patrick,

thanks for looking at this ..

On 8 Feb 2012, at 03:36, Patrick Marlier wrote:

The problem in this PR is that with PIE, getsectdata does not return  
the position of tm_clone_table after the relocation.
While _dyld_get_image_vmaddr_slide(0) is enough for PIE, this is not  
enough for dylib.
I did not find an easy API function to get position of the  
tm_clone_table for a shared library (dylib). So the only way I found  
is to get the mach_header address of the current dylib (via  
_dyld_get_image_header_containing_address), iterate over loaded  
binaries to find the current shared library and use  
_dyld_get_image_vmaddr_slide to find the position.

Any other proposal (my knowledge of darwin is really limited)?

Can someone do a bootstrap and test libitm on darwin (I have a  
limited access to a darwin machine, at least libitm tests pass)?  
Thanks!


If tests passed, ok for 4.7?
--
Patrick Marlier.
libgcc:

PR libitm/52042
   * config/darwin-crt-tm.c: Changes for PIE and shared library.




looks good to me .. and DTRT on Darwin 9 too .. (but I can't approve).

one nit (also mea culpa in the original...)

 /* not listed in mach-o/dyld.h for some reason.  */
-extern char * getsectdata (const char*,const char*,unsigned long*);
+extern char *getsectdatafromheader (struct mach_header*, const char*,
+   const char*, unsigned long*);
+extern char *getsectdatafromheader_64 (struct mach_header_64*, const  
char*,

+  const char*, unsigned long*);

these are in 

(dyld documentation glitch ...)

===

Sometime: I wonder if we should move the definition of the section  
name to a common place so that we don't need to worry about keeping it  
in step.  Or even better have some compiler-wide mechanism for dealing  
with the fact that named sections might have different literals/ 
semantics per target.


Iain

Re: [PATCH][ARM] Improve 64-bit shifts (non-NEON)

[Bernd Schmidt]

On 02/07/2012 11:33 PM, Steven Bosscher wrote:
> On Tue, Feb 7, 2012 at 11:19 PM, Ramana Radhakrishnan
>  wrote:
>> Hi Andrew
>>
>> I find it interesting that cond_exec's in this form survive all the
>> way till reload and "work".  AFAIK we could never have cond_exec's
>> before reload .
> 
> There is nothing wrong per-se with cond_execs before reload, as long
> as you don't have to reload a predicate pseudo-reg.

I thought the problem was that we'd have to emit conditional reload
insns and inheritance wouldn't work.


Bernd

Re: [PATCH][ARM] Improve 64-bit shifts (non-NEON)

[Richard Guenther]

On Wed, Feb 8, 2012 at 1:02 PM, Bernd Schmidt  wrote:
> On 02/07/2012 11:33 PM, Steven Bosscher wrote:
>> On Tue, Feb 7, 2012 at 11:19 PM, Ramana Radhakrishnan
>>  wrote:
>>> Hi Andrew
>>>
>>> I find it interesting that cond_exec's in this form survive all the
>>> way till reload and "work".  AFAIK we could never have cond_exec's
>>> before reload .
>>
>> There is nothing wrong per-se with cond_execs before reload, as long
>> as you don't have to reload a predicate pseudo-reg.
>
> I thought the problem was that we'd have to emit conditional reload
> insns and inheritance wouldn't work.

It probably depends on how DF sees conditional uses / defs.  If they
look like regular uses / defs then I suppose un-conditional spills/reloads
are fine - otherwise of course you'd corrupt one of the two register set
states.  But that also means it's probably safe if the sequence of conditional
insns is of length 1.

Not sure we want to open that possible can of worms though ;)

Richard.

>
> Bernd

Re: [PATCH] Fix cfg_layout_merge_blocks (PR rtl-optimization/52139)

[Jakub Jelinek]

On Wed, Feb 08, 2012 at 11:55:52AM +0100, Richard Guenther wrote:
> > I'll bootstrap/regtest now just that single hunk, is that ok for
> > trunk/4.6/4.5?
> 
> Yes.

Thanks, this is what I've committed after bootstrap/regtest on x86_64-linux
and i686-linux:

2012-02-08  Jakub Jelinek  

PR rtl-optimization/52139
* cfgrtl.c (cfg_layout_merge_blocks): If BB_END
is a BARRIER after emit_insn_after_noloc, move BB_END
to the last non-BARRIER insn before it.

* gcc.dg/pr52139.c: New test.

--- gcc/cfgrtl.c.jj 2012-02-07 16:05:47.977533716 +0100
+++ gcc/cfgrtl.c2012-02-07 17:03:52.925956927 +0100
@@ -2871,6 +2871,11 @@ cfg_layout_merge_blocks (basic_block a,
   rtx first = BB_END (a), last;
 
   last = emit_insn_after_noloc (b->il.rtl->header, BB_END (a), a);
+  /* The above might add a BARRIER as BB_END, but as barriers
+aren't valid parts of a bb, remove_insn doesn't update
+BB_END if it is a barrier.  So adjust BB_END here.  */
+  while (BB_END (a) != first && BARRIER_P (BB_END (a)))
+   BB_END (a) = PREV_INSN (BB_END (a));
   delete_insn_chain (NEXT_INSN (first), last, false);
   b->il.rtl->header = NULL;
 }
--- gcc/testsuite/gcc.dg/pr52139.c.jj   2012-02-07 16:14:32.537734917 +0100
+++ gcc/testsuite/gcc.dg/pr52139.c  2012-02-07 16:14:32.537734917 +0100
@@ -0,0 +1,49 @@
+/* PR rtl-optimization/52139 */
+/* { dg-do compile } */
+/* { dg-options "-O -fno-tree-dominator-opts -fno-tree-fre" } */
+/* { dg-additional-options "-fpic" { target fpic } } */
+
+void *p;
+
+void
+foo (int a)
+{
+  switch (a)
+{
+case 0:
+a0:
+case 1:
+a1:
+  p = &&a1;
+case 2:
+a2:
+  p = &&a2;
+case 3:
+a3:
+  p = &&a3;
+case 4:
+a4:
+  p = &&a4;
+case 5:
+a5:
+  p = &&a5;
+case 6:
+a6:
+  p = &&a6;
+case 7:
+a7:
+  p = &&a7;
+case 8:
+a8:
+  p = &&a8;
+case 9:
+a9:
+  p = &&a9;
+case 10:
+a10:
+  p = &&a10;
+default:
+  p = &&a0;
+}
+  goto *p;
+}


Jakub

[PATCH] Fix -fprofile-generate __gcov* var naming (PR gcov-profile/52150)

[Jakub Jelinek]

Hi!

build_var in coverage.c doesn't strip_name_encoding, therefore happily
puts in characters like leading * into the __gcov* variable names.
Fixed thusly, additionally I'm changing the last _ to . or $ when possible
to avoid failures if user code e.g. contains variables like __gcov__foo
(yeah, I know, it is implementation reserved namespace, still it doesn't
hurt to avoid it if possible).

Bootstrapped/regtested on x86_64-linux and i686-linux, tested with Firefox
PGO build by the reporter.  Ok for trunk?

2012-02-08  Jakub Jelinek  

PR gcov-profile/52150
* coverage.c: Include target.h.
(build_var): Call targetm.strip_name_encoding on the assembler name.
Change one _ into . or $ if the target allows it.
* Makefile.in (coverage.o): Depend on $(TARGET_H).

* gcc.dg/tree-prof/pr52150.c: New test.

--- gcc/coverage.c.jj   2012-01-01 19:54:46.0 +0100
+++ gcc/coverage.c  2012-02-08 09:24:49.345911957 +0100
@@ -50,6 +50,7 @@ along with GCC; see the file COPYING3.
 #include "diagnostic-core.h"
 #include "intl.h"
 #include "filenames.h"
+#include "target.h"
 
 #include "gcov-io.h"
 #include "gcov-io.c"
@@ -656,13 +657,25 @@ static tree
 build_var (tree fn_decl, tree type, int counter)
 {
   tree var = build_decl (BUILTINS_LOCATION, VAR_DECL, NULL_TREE, type);
-  tree fn_name = DECL_ASSEMBLER_NAME (fn_decl);
-  char *buf = (char *)alloca (IDENTIFIER_LENGTH (fn_name) + 10);
+  const char *fn_name = IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (fn_decl));
+  char *buf;
+  size_t fn_name_len, len;
+
+  fn_name = targetm.strip_name_encoding (fn_name);
+  fn_name_len = strlen (fn_name);
+  buf = XALLOCAVEC (char, fn_name_len + 8 + sizeof (int) * 3);
 
   if (counter < 0)
-sprintf (buf, "__gcov__%s", IDENTIFIER_POINTER (fn_name));
+strcpy (buf, "__gcov__");
   else
-sprintf (buf, "__gcov%u_%s", counter, IDENTIFIER_POINTER (fn_name));
+sprintf (buf, "__gcov%u_", counter);
+  len = strlen (buf);
+#ifndef NO_DOT_IN_LABEL
+  buf[len - 1] = '.';
+#elif !defined NO_DOLLAR_IN_LABEL
+  buf[len - 1] = '$';
+#endif
+  memcpy (buf + len, fn_name, fn_name_len + 1);
   DECL_NAME (var) = get_identifier (buf);
   TREE_STATIC (var) = 1;
   TREE_ADDRESSABLE (var) = 1;
--- gcc/Makefile.in.jj  2012-01-30 00:10:01.0 +0100
+++ gcc/Makefile.in 2012-02-08 09:20:24.616554891 +0100
@@ -3002,7 +3002,7 @@ coverage.o : coverage.c $(GCOV_IO_H) $(C
$(TM_H) $(RTL_H) $(TREE_H) $(FLAGS_H) output.h $(REGS_H) $(EXPR_H) \
$(FUNCTION_H) $(BASIC_BLOCK_H) toplev.h $(DIAGNOSTIC_CORE_H) $(GGC_H) 
langhooks.h $(COVERAGE_H) \
$(HASHTAB_H) tree-iterator.h $(CGRAPH_H) $(TREE_PASS_H) gcov-io.c $(TM_P_H) 
\
-   $(DIAGNOSTIC_CORE_H) intl.h gt-coverage.h
+   $(DIAGNOSTIC_CORE_H) intl.h gt-coverage.h $(TARGET_H)
 cselib.o : cselib.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(RTL_H) \
$(REGS_H) hard-reg-set.h $(FLAGS_H) insn-config.h $(RECOG_H) \
$(EMIT_RTL_H) $(DIAGNOSTIC_CORE_H) output.h $(FUNCTION_H) $(TREE_PASS_H) \
--- gcc/testsuite/gcc.dg/tree-prof/pr52150.c.jj 2012-02-08 09:29:41.334297278 
+0100
+++ gcc/testsuite/gcc.dg/tree-prof/pr52150.c2012-02-08 09:30:22.580068958 
+0100
@@ -0,0 +1,16 @@
+/* PR gcov-profile/52150 */
+/* { dg-options "-O0" } */
+
+void foo () __asm__ ("bar");
+
+void
+foo ()
+{
+}
+
+int
+main ()
+{
+  foo ();
+  return 0;
+}

Jakub

Re: [PATCH][ARM] Improve 64-bit shifts (non-NEON)

[Bernd Schmidt]

On 02/08/2012 01:12 PM, Richard Guenther wrote:
> On Wed, Feb 8, 2012 at 1:02 PM, Bernd Schmidt  wrote:
>> On 02/07/2012 11:33 PM, Steven Bosscher wrote:
>>> On Tue, Feb 7, 2012 at 11:19 PM, Ramana Radhakrishnan
>>>  wrote:
 Hi Andrew

 I find it interesting that cond_exec's in this form survive all the
 way till reload and "work".  AFAIK we could never have cond_exec's
 before reload .
>>>
>>> There is nothing wrong per-se with cond_execs before reload, as long
>>> as you don't have to reload a predicate pseudo-reg.
>>
>> I thought the problem was that we'd have to emit conditional reload
>> insns and inheritance wouldn't work.
> 
> It probably depends on how DF sees conditional uses / defs.  If they
> look like regular uses / defs then I suppose un-conditional spills/reloads
> are fine - otherwise of course you'd corrupt one of the two register set
> states.

I'm pretty sure conditional defs are always RMW, but I'd have to go
look. Can't imagine it working otherwise though.


Bernd

Re: [PATCH] fix PR51910, take 2

[Jakub Jelinek]

On Tue, Feb 07, 2012 at 11:41:03PM -1000, Jason Merrill wrote:
> Hmm, I wrote up something quite similar on the plane.  One
> difference is that mine synchronizes .rpo files that start with some
> variants chosen and others not.  Does this make sense to you?

You mean the maybe_tweak change?  Not sure I understand it.

Anyway, using VEC is probably cleaner than my patch, on the other
side might be more expensive for the common case where most
symbols don't demangle the same like any other symbol,
because then you allocate a VEC (I think 4 pointers) for each of the
hash table entries, i.e. one extra allocation for each.
> 
> >I wonder if it wouldn't be better to just use a linker plugin for -frepo
> >if the linker supports plugins.
> 
> Probably.  But I don't feel motivated to write it.

Me neither ;).
Anyway, the question is if the increases in object sizes with -frepo
(due to bringing in unused ctor or dtor variants from time to time)
will be acceptable to -frepo users (if there are any).

Jakub

Re: [PATCH] increase timeout in simulate-thread gdb test

[Andrew MacLeod]

On 02/07/2012 07:55 PM, Mike Stump wrote:

On Dec 7, 2011, at 10:43 AM, Jack Howarth wrote:

Currently we are failing...

FAIL: gcc.dg/simulate-thread/atomic-load-int128.c  -O1 -g  thread simulation 
test
FAIL: gcc.dg/simulate-thread/atomic-load-int128.c  -O2 -g  thread simulation 
test
FAIL: gcc.dg/simulate-thread/atomic-load-int128.c  -O3 -g  thread simulation 
test
FAIL: gcc.dg/simulate-thread/atomic-load-int128.c  -Os -g  thread simulation 
test

on x86_64-apple-darwin11 due to the 10 second timeout in simulate-thread of
gcc/testsuite/lib/gcc-simulate-thread.exp. Increasing this timeout to 20 seconds
eliminates the failures (as these test take ~16 seconds on 
x86_64-apple-darwin11).
Okay for gcc trunk?

Ok.  Ok for 4.7.
And I just recently noticed armv7 was failing *all* the simulate-thread 
tests for the same reason.  20 seconds appears to make it pass all tests 
there as well.


On a different note, shouldn't these time out's be reported as 
UNRESOLVED rather than fails?  Seems like the framework isn't reporting 
properly.


Andrew

[PATCH] Fix PR52170

[Richard Guenther]

We can enter simplify_plus_minus with integer vector mode operands
and thus we shouldn't use constm1_rtx when canonicalizing ~a but
CONSTM1_RTX (mode).

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

Richard.

2012-02-08  Richard Guenther  

PR rtl-optimization/52170
* simplify-rtx.c (simplify_plus_minus): Use CONSTM1_RTX to
properly handle integer vector modes.

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

Index: gcc/simplify-rtx.c
===
*** gcc/simplify-rtx.c  (revision 183997)
--- gcc/simplify-rtx.c  (working copy)
*** simplify_plus_minus (enum rtx_code code,
*** 3947,3953 
  /* ~a -> (-a - 1) */
  if (n_ops != 7)
{
! ops[n_ops].op = constm1_rtx;
  ops[n_ops++].neg = this_neg;
  ops[i].op = XEXP (this_op, 0);
  ops[i].neg = !this_neg;
--- 3947,3953 
  /* ~a -> (-a - 1) */
  if (n_ops != 7)
{
! ops[n_ops].op = CONSTM1_RTX (mode);
  ops[n_ops++].neg = this_neg;
  ops[i].op = XEXP (this_op, 0);
  ops[i].neg = !this_neg;
Index: gcc/testsuite/gcc.dg/torture/pr52170.c
===
*** gcc/testsuite/gcc.dg/torture/pr52170.c  (revision 0)
--- gcc/testsuite/gcc.dg/torture/pr52170.c  (revision 0)
***
*** 0 
--- 1,17 
+ /* { dg-do compile } */
+ 
+ typedef unsigned char uint8_t ;
+ typedef unsigned long uint32_t;
+ void f0a(uint32_t * result, uint32_t * arg1)
+ {
+   int idx;
+   for (idx=0;idx<96;idx += 1)
+ {
+   uint8_t temp_5;
+   uint8_t temp_6;
+ 
+   temp_5 = ~(*arg1);
+   temp_6 = (*arg1) + 1 - temp_5;
+   result[idx] = temp_6;
+ }
+ }

Re: [PATCH] Fix -fprofile-generate __gcov* var naming (PR gcov-profile/52150)

[Richard Guenther]

On Wed, Feb 8, 2012 at 1:37 PM, Jakub Jelinek  wrote:
> Hi!
>
> build_var in coverage.c doesn't strip_name_encoding, therefore happily
> puts in characters like leading * into the __gcov* variable names.
> Fixed thusly, additionally I'm changing the last _ to . or $ when possible
> to avoid failures if user code e.g. contains variables like __gcov__foo
> (yeah, I know, it is implementation reserved namespace, still it doesn't
> hurt to avoid it if possible).
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, tested with Firefox
> PGO build by the reporter.  Ok for trunk?

Ok.

Thanks,
Richard.

> 2012-02-08  Jakub Jelinek  
>
>        PR gcov-profile/52150
>        * coverage.c: Include target.h.
>        (build_var): Call targetm.strip_name_encoding on the assembler name.
>        Change one _ into . or $ if the target allows it.
>        * Makefile.in (coverage.o): Depend on $(TARGET_H).
>
>        * gcc.dg/tree-prof/pr52150.c: New test.
>
> --- gcc/coverage.c.jj   2012-01-01 19:54:46.0 +0100
> +++ gcc/coverage.c      2012-02-08 09:24:49.345911957 +0100
> @@ -50,6 +50,7 @@ along with GCC; see the file COPYING3.
>  #include "diagnostic-core.h"
>  #include "intl.h"
>  #include "filenames.h"
> +#include "target.h"
>
>  #include "gcov-io.h"
>  #include "gcov-io.c"
> @@ -656,13 +657,25 @@ static tree
>  build_var (tree fn_decl, tree type, int counter)
>  {
>   tree var = build_decl (BUILTINS_LOCATION, VAR_DECL, NULL_TREE, type);
> -  tree fn_name = DECL_ASSEMBLER_NAME (fn_decl);
> -  char *buf = (char *)alloca (IDENTIFIER_LENGTH (fn_name) + 10);
> +  const char *fn_name = IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (fn_decl));
> +  char *buf;
> +  size_t fn_name_len, len;
> +
> +  fn_name = targetm.strip_name_encoding (fn_name);
> +  fn_name_len = strlen (fn_name);
> +  buf = XALLOCAVEC (char, fn_name_len + 8 + sizeof (int) * 3);
>
>   if (counter < 0)
> -    sprintf (buf, "__gcov__%s", IDENTIFIER_POINTER (fn_name));
> +    strcpy (buf, "__gcov__");
>   else
> -    sprintf (buf, "__gcov%u_%s", counter, IDENTIFIER_POINTER (fn_name));
> +    sprintf (buf, "__gcov%u_", counter);
> +  len = strlen (buf);
> +#ifndef NO_DOT_IN_LABEL
> +  buf[len - 1] = '.';
> +#elif !defined NO_DOLLAR_IN_LABEL
> +  buf[len - 1] = '$';
> +#endif
> +  memcpy (buf + len, fn_name, fn_name_len + 1);
>   DECL_NAME (var) = get_identifier (buf);
>   TREE_STATIC (var) = 1;
>   TREE_ADDRESSABLE (var) = 1;
> --- gcc/Makefile.in.jj  2012-01-30 00:10:01.0 +0100
> +++ gcc/Makefile.in     2012-02-08 09:20:24.616554891 +0100
> @@ -3002,7 +3002,7 @@ coverage.o : coverage.c $(GCOV_IO_H) $(C
>    $(TM_H) $(RTL_H) $(TREE_H) $(FLAGS_H) output.h $(REGS_H) $(EXPR_H) \
>    $(FUNCTION_H) $(BASIC_BLOCK_H) toplev.h $(DIAGNOSTIC_CORE_H) $(GGC_H) 
> langhooks.h $(COVERAGE_H) \
>    $(HASHTAB_H) tree-iterator.h $(CGRAPH_H) $(TREE_PASS_H) gcov-io.c 
> $(TM_P_H) \
> -   $(DIAGNOSTIC_CORE_H) intl.h gt-coverage.h
> +   $(DIAGNOSTIC_CORE_H) intl.h gt-coverage.h $(TARGET_H)
>  cselib.o : cselib.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(RTL_H) \
>    $(REGS_H) hard-reg-set.h $(FLAGS_H) insn-config.h $(RECOG_H) \
>    $(EMIT_RTL_H) $(DIAGNOSTIC_CORE_H) output.h $(FUNCTION_H) $(TREE_PASS_H) \
> --- gcc/testsuite/gcc.dg/tree-prof/pr52150.c.jj 2012-02-08 09:29:41.334297278 
> +0100
> +++ gcc/testsuite/gcc.dg/tree-prof/pr52150.c    2012-02-08 09:30:22.580068958 
> +0100
> @@ -0,0 +1,16 @@
> +/* PR gcov-profile/52150 */
> +/* { dg-options "-O0" } */
> +
> +void foo () __asm__ ("bar");
> +
> +void
> +foo ()
> +{
> +}
> +
> +int
> +main ()
> +{
> +  foo ();
> +  return 0;
> +}
>
>        Jakub

Re: [PATCH][ARM] Improve 64-bit shifts (non-NEON)

[Richard Guenther]

On Wed, Feb 8, 2012 at 1:41 PM, Bernd Schmidt  wrote:
> On 02/08/2012 01:12 PM, Richard Guenther wrote:
>> On Wed, Feb 8, 2012 at 1:02 PM, Bernd Schmidt  
>> wrote:
>>> On 02/07/2012 11:33 PM, Steven Bosscher wrote:
 On Tue, Feb 7, 2012 at 11:19 PM, Ramana Radhakrishnan
  wrote:
> Hi Andrew
>
> I find it interesting that cond_exec's in this form survive all the
> way till reload and "work".  AFAIK we could never have cond_exec's
> before reload .

 There is nothing wrong per-se with cond_execs before reload, as long
 as you don't have to reload a predicate pseudo-reg.
>>>
>>> I thought the problem was that we'd have to emit conditional reload
>>> insns and inheritance wouldn't work.
>>
>> It probably depends on how DF sees conditional uses / defs.  If they
>> look like regular uses / defs then I suppose un-conditional spills/reloads
>> are fine - otherwise of course you'd corrupt one of the two register set
>> states.
>
> I'm pretty sure conditional defs are always RMW, but I'd have to go
> look. Can't imagine it working otherwise though.

I was thinking about

  (cond_exec 1 (set (reg:SI 30) (...)))
  (cond_exec 0 (set (reg:SI 30) (...)))
  (cond_exec 1 (use (reg:SI 30) (...)))

where if we spill/reload 30 with non-cond_exec stmts then we might
clobber the shared register set of the conditional execution paths.
Similar of course shared stack space if we happen to spill/reload in
both paths.  If of course defs/uses of both paths conflict and get different
hard registers assigned the register issue doesn't exist, still the
shared spill stack space issue may.

Richard.

Re: [PATCH] increase timeout in simulate-thread gdb test

[Richard Guenther]

On Wed, Feb 8, 2012 at 2:11 PM, Andrew MacLeod  wrote:
> On 02/07/2012 07:55 PM, Mike Stump wrote:
>>
>> On Dec 7, 2011, at 10:43 AM, Jack Howarth wrote:
>>>
>>> Currently we are failing...
>>>
>>> FAIL: gcc.dg/simulate-thread/atomic-load-int128.c  -O1 -g  thread
>>> simulation test
>>> FAIL: gcc.dg/simulate-thread/atomic-load-int128.c  -O2 -g  thread
>>> simulation test
>>> FAIL: gcc.dg/simulate-thread/atomic-load-int128.c  -O3 -g  thread
>>> simulation test
>>> FAIL: gcc.dg/simulate-thread/atomic-load-int128.c  -Os -g  thread
>>> simulation test
>>>
>>> on x86_64-apple-darwin11 due to the 10 second timeout in simulate-thread
>>> of
>>> gcc/testsuite/lib/gcc-simulate-thread.exp. Increasing this timeout to 20
>>> seconds
>>> eliminates the failures (as these test take ~16 seconds on
>>> x86_64-apple-darwin11).
>>> Okay for gcc trunk?
>>
>> Ok.  Ok for 4.7.
>
> And I just recently noticed armv7 was failing *all* the simulate-thread
> tests for the same reason.  20 seconds appears to make it pass all tests
> there as well.
>
> On a different note, shouldn't these time out's be reported as UNRESOLVED
> rather than fails?  Seems like the framework isn't reporting properly.

Well - it depends.  You don't know whether the test will eventually terminate,
but yes, you could interpret "UNRESOLVED" as exactly what that is.  A
definite finishes-never would be a FAIL of course.  The question is on which
side to err.

Richard.

Re: [PATCH] increase timeout in simulate-thread gdb test

[Iain Sandoe]

On 8 Feb 2012, at 13:33, Richard Guenther wrote:

On Wed, Feb 8, 2012 at 2:11 PM, Andrew MacLeod   
wrote:

On 02/07/2012 07:55 PM, Mike Stump wrote:


On Dec 7, 2011, at 10:43 AM, Jack Howarth wrote:


Currently we are failing...

FAIL: gcc.dg/simulate-thread/atomic-load-int128.c  -O1 -g  thread
simulation test
FAIL: gcc.dg/simulate-thread/atomic-load-int128.c  -O2 -g  thread
simulation test
FAIL: gcc.dg/simulate-thread/atomic-load-int128.c  -O3 -g  thread
simulation test
FAIL: gcc.dg/simulate-thread/atomic-load-int128.c  -Os -g  thread
simulation test

on x86_64-apple-darwin11 due to the 10 second timeout in simulate- 
thread

of
gcc/testsuite/lib/gcc-simulate-thread.exp. Increasing this  
timeout to 20

seconds
eliminates the failures (as these test take ~16 seconds on
x86_64-apple-darwin11).
Okay for gcc trunk?


Ok.  Ok for 4.7.


And I just recently noticed armv7 was failing *all* the simulate- 
thread
tests for the same reason.  20 seconds appears to make it pass all  
tests

there as well.

On a different note, shouldn't these time out's be reported as  
UNRESOLVED
rather than fails?  Seems like the framework isn't reporting  
properly.


Well - it depends.  You don't know whether the test will eventually  
terminate,

but yes, you could interpret "UNRESOLVED" as exactly what that is.  A
definite finishes-never would be a FAIL of course.  The question is  
on which

side to err.


There was also some discussion about reducing the amount of log-file  
output (which might help too).
Did that ever get anywhere/who would be willing to decide what could  
be dropped from the output?

Iain

Re: [PATCH] increase timeout in simulate-thread gdb test

[Andrew MacLeod]

On 02/08/2012 08:37 AM, Iain Sandoe wrote:


Well - it depends.  You don't know whether the test will eventually 
terminate,

but yes, you could interpret "UNRESOLVED" as exactly what that is.  A
definite finishes-never would be a FAIL of course.  The question is 
on which

side to err.



There was also some discussion about reducing the amount of log-file 
output (which might help too).
Did that ever get anywhere/who would be willing to decide what could 
be dropped from the output?

Iain



For a start we could comment out the
   disp/i $pc
command in the simulate-thread.gdb script file.   I'd leave it there as 
a comment to make it easy to turn back on when needed.


You can still see the source line being executed, and you generally need 
to take the test case and hand run it to see whats going on anyway.   
That cuts the log file in about half.


Andrew

Re: [PATCH] increase timeout in simulate-thread gdb test

[Jack Howarth]

On Wed, Feb 08, 2012 at 09:00:00AM -0500, Andrew MacLeod wrote:
> On 02/08/2012 08:37 AM, Iain Sandoe wrote:
>>
>>> Well - it depends.  You don't know whether the test will eventually  
>>> terminate,
>>> but yes, you could interpret "UNRESOLVED" as exactly what that is.  A
>>> definite finishes-never would be a FAIL of course.  The question is  
>>> on which
>>> side to err.
>>
>>
>> There was also some discussion about reducing the amount of log-file  
>> output (which might help too).
>> Did that ever get anywhere/who would be willing to decide what could  
>> be dropped from the output?
>> Iain
>>
>
> For a start we could comment out the
>disp/i $pc
> command in the simulate-thread.gdb script file.   I'd leave it there as  
> a comment to make it easy to turn back on when needed.

Andrew,
   Eliminating the "disp/i $pc" in the simulate-thread.gdb script file
is insufficient to reduce the execution time below 10 seconds. What is 
the next thing we can prune?
   Jack

>
> You can still see the source line being executed, and you generally need  
> to take the test case and hand run it to see whats going on anyway.
> That cuts the log file in about half.
>
> Andrew
>

[PATCH] Fix PR50031

[William J. Schmidt]

This is a vectorizer patch I inherited from Ira.  As with the fix for
PR50969, it handles problems with excessive permutes by adjusting the
cost model.  In this case the permutes comes from type
promotion/demotion, which is now modeled with a new vec_cvt cost.

This restores the lost performance for sphinx3, and gives wupwise an
additional boost.  This is a performance workaround for 4.7; for 4.8 we
want to try to do a better job of modeling the real issue, which is that
VSX permutes are constrained to a single processor pipe.  Thus isolated
permutes are less expensive per instruction than denser collections of
permutes.

There also remains an opportunity for versioning loops for alignment.

Bootstrapped and tested on powerpc64-linux with no regressions.  OK for
trunk?

Thanks,
Bill


2012-02-08  Bill Schmidt  
Ira Rosen  

PR tree-optimization/50031
* targhooks.c (default_builtin_vectorization_cost): Handle vec_cvt.
* target.h (enum vect_cost_for_stmt): Add vec_cvt.
* tree-vect-loop.c (vect_get_single_scalar_iteraion_cost): Handle
all types of reduction and pattern statements.
(vect_estimate_min_profitable_iters): Likewise.
* tree-vect-stmts.c (vect_model_simple_cost): Use vec_cvt cost for
type promotions and demotions.
(vect_model_conversion_cost): New function.
(vect_get_load_cost): Use vec_perm for permutations; add dump logic
for explicit realigns.
(vectorizable_conversion): Call vect_model_conversion_cost.
* config/spu/spu.c (spu_builtin_vectorization_cost): Handle vec_cvt.
* config/i386/i386.c (ix86_builtin_vectorization_cost): Likewise.
* config/rs6000/rs6000.c (rs6000_builtin_vectorization_cost): Update
vec_perm for VSX and handle vec_cvt.


Index: gcc/targhooks.c
===
--- gcc/targhooks.c (revision 183944)
+++ gcc/targhooks.c (working copy)
@@ -514,6 +514,7 @@ default_builtin_vectorization_cost (enum vect_cost
   case scalar_to_vec:
   case cond_branch_not_taken:
   case vec_perm:
+  case vec_cvt:
 return 1;
 
   case unaligned_load:
Index: gcc/target.h
===
--- gcc/target.h(revision 183944)
+++ gcc/target.h(working copy)
@@ -145,7 +145,8 @@ enum vect_cost_for_stmt
   scalar_to_vec,
   cond_branch_not_taken,
   cond_branch_taken,
-  vec_perm
+  vec_perm,
+  vec_cvt
 };
 
 /* The target structure.  This holds all the backend hooks.  */
Index: gcc/tree-vect-loop.c
===
--- gcc/tree-vect-loop.c(revision 183944)
+++ gcc/tree-vect-loop.c(working copy)
@@ -2417,7 +2417,8 @@ vect_get_single_scalar_iteraion_cost (loop_vec_inf
   if (stmt_info
   && !STMT_VINFO_RELEVANT_P (stmt_info)
   && (!STMT_VINFO_LIVE_P (stmt_info)
-  || STMT_VINFO_DEF_TYPE (stmt_info) != vect_reduction_def))
+  || !VECTORIZABLE_CYCLE_DEF (STMT_VINFO_DEF_TYPE (stmt_info)))
+ && !STMT_VINFO_IN_PATTERN_P (stmt_info))
 continue;
 
   if (STMT_VINFO_DATA_REF (vinfo_for_stmt (stmt)))
@@ -2562,17 +2563,51 @@ vect_estimate_min_profitable_iters (loop_vec_info
 
   for (si = gsi_start_bb (bb); !gsi_end_p (si); gsi_next (&si))
{
- gimple stmt = gsi_stmt (si);
+ gimple stmt = gsi_stmt (si), pattern_stmt;
  stmt_vec_info stmt_info = vinfo_for_stmt (stmt);
  /* Skip stmts that are not vectorized inside the loop.  */
  if (!STMT_VINFO_RELEVANT_P (stmt_info)
  && (!STMT_VINFO_LIVE_P (stmt_info)
- || STMT_VINFO_DEF_TYPE (stmt_info) != vect_reduction_def))
-   continue;
+ || !VECTORIZABLE_CYCLE_DEF (STMT_VINFO_DEF_TYPE (stmt_info
+   {
+ if (STMT_VINFO_IN_PATTERN_P (stmt_info)
+ && (pattern_stmt = STMT_VINFO_RELATED_STMT (stmt_info))
+ && (STMT_VINFO_RELEVANT_P (vinfo_for_stmt (pattern_stmt))
+ || STMT_VINFO_LIVE_P (vinfo_for_stmt (pattern_stmt
+{
+  stmt = pattern_stmt;
+  stmt_info = vinfo_for_stmt (stmt);
+   }
+ else
+   continue;
+   }
  vec_inside_cost += STMT_VINFO_INSIDE_OF_LOOP_COST (stmt_info) * 
factor;
  /* FIXME: for stmts in the inner-loop in outer-loop vectorization,
 some of the "outside" costs are generated inside the outer-loop.  
*/
  vec_outside_cost += STMT_VINFO_OUTSIDE_OF_LOOP_COST (stmt_info);
+  if (is_pattern_stmt_p (stmt_info)
+ && STMT_VINFO_PATTERN_DEF_SEQ (stmt_info))
+{
+ gimple_stmt_iterator gsi;
+ 
+ for (gsi = gsi_start (STMT_VINFO_PATTERN_DEF_SEQ (stmt_info));

Re: [PATCH] increase timeout in simulate-thread gdb test

[Andrew MacLeod]

On 02/08/2012 09:27 AM, Jack Howarth wrote:

On Wed, Feb 08, 2012 at 09:00:00AM -0500, Andrew MacLeod wrote:

On 02/08/2012 08:37 AM, Iain Sandoe wrote:

Well - it depends.  You don't know whether the test will eventually
terminate,
but yes, you could interpret "UNRESOLVED" as exactly what that is.  A
definite finishes-never would be a FAIL of course.  The question is
on which
side to err.


There was also some discussion about reducing the amount of log-file
output (which might help too).
Did that ever get anywhere/who would be willing to decide what could
be dropped from the output?
Iain


For a start we could comment out the
disp/i $pc
command in the simulate-thread.gdb script file.   I'd leave it there as
a comment to make it easy to turn back on when needed.

Andrew,
Eliminating the "disp/i $pc" in the simulate-thread.gdb script file
is insufficient to reduce the execution time below 10 seconds. What is
the next thing we can prune?
Jack

no, it wont change the time, just reduce the size of the log file.

The only way to reduce the time below 10 seconds would be to change the 
test case to run less time, but I'd rather leave them as they are. They 
did catch one very tricky case for me.


I propose increasing the time to 20 seconds and reduce the log file.  I 
believe the timeout as made really short because of the size of the log 
file when the timeout was needed. I htink it was an arbitrary number.   
Doubling the execution time and halving the size of the log file should 
put us about where we were.


Im even fine abandoning most of the log file if need be as well... Its 
really pass or fail that I care about and a fail usually requires hand 
investigation anyway


The other thing we can do is to only run the test with -O0 and -O3.   
right now they run with -O0, -O1, -O2, -O3, -Os.  I don't think the 
other options really add much.


Andrew

haifa-sched: Fix problems with cc0 in prune_ready_list

[Bernd Schmidt]

We found a scheduler problem while testing Coldfire targets. The
prune_ready_list function I introduced doesn't take SCHED_GROUPs into
account, which can lead to a random insn being scheduled between a cc0
setter and user. The patch below fixes it, OK? (Bootstrapped & tested
i686-linux).


Bernd
* haifa-sched.c (prune_ready_list): Ensure that if there is a
sched-group insn, it either remains alone or the entire list is
pruned.

Index: gcc/haifa-sched.c
===
--- gcc/haifa-sched.c   (revision 357962)
+++ gcc/haifa-sched.c   (working copy)
@@ -3959,6 +3959,7 @@ prune_ready_list (state_t temp_state, bo
  bool shadows_only_p, bool modulo_epilogue_p)
 {
   int i;
+  bool sched_group_found = false;
 
  restart:
   for (i = 0; i < ready.n_ready; i++)
@@ -3967,13 +3968,27 @@ prune_ready_list (state_t temp_state, bo
   int cost = 0;
   const char *reason = "resource conflict";
 
-  if (modulo_epilogue_p && !DEBUG_INSN_P (insn)
- && INSN_EXACT_TICK (insn) == INVALID_TICK)
+  if (DEBUG_INSN_P (insn))
+   continue;
+
+  if (SCHED_GROUP_P (insn) && !sched_group_found)
+   {
+ sched_group_found = true;
+ if (i > 0)
+   goto restart;
+   }
+
+  if (sched_group_found && !SCHED_GROUP_P (insn))
+   {
+ cost = 1;
+ reason = "not in sched group";
+   }
+  else if (modulo_epilogue_p && INSN_EXACT_TICK (insn) == INVALID_TICK)
{
  cost = max_insn_queue_index;
  reason = "not an epilogue insn";
}
-  if (shadows_only_p && !DEBUG_INSN_P (insn) && !SHADOW_P (insn))
+  else if (shadows_only_p && !SHADOW_P (insn))
{
  cost = 1;
  reason = "not a shadow";

[PATCH] Fix atomic load for unsupported data sizes

[Andrew MacLeod]

When investigating an issue on arm, I discovered a bug that needs fixing.

If there is no atomic_load pattern  for data which is larger than the 
native word size, we try to issue a compare_and_swap loop.  Problem is 
there is no check to see if it succeeded or failed.  If the compare-swap 
loop isn't emitted, we need to leave the __atomic_load_N call rather 
than silently generate incorrect code.


Attached patch bootstraps on   x86_64-unknown-linux-gnu and fixes the 
problem on an arm cross compiler.


No new regressions in the testsuite, and is a harmless change for 
working code.


OK to check in?  GCC 4.7 is still mainline isn't it?

Andrew


* optabs.c (expand_atomic_load): Do not assume compare_and_swap will
succeed for larger than word integers.

Index: optabs.c
===
*** optabs.c(revision 183969)
--- optabs.c(working copy)
*** expand_atomic_load (rtx target, rtx mem,
*** 7665,7673 
/* Issue val = compare_and_swap (mem, 0, 0).
 This may cause the occasional harmless store of 0 when the value is
 already 0, but it seems to be OK according to the standards guys.  */
!   expand_atomic_compare_and_swap (NULL, &target, mem, const0_rtx,
! const0_rtx, false, model, model);
!   return target;
  }
  
/* Otherwise assume loads are atomic, and emit the proper barriers.  */
--- 7665,7676 
/* Issue val = compare_and_swap (mem, 0, 0).
 This may cause the occasional harmless store of 0 when the value is
 already 0, but it seems to be OK according to the standards guys.  */
!   if (expand_atomic_compare_and_swap (NULL, &target, mem, const0_rtx,
! const0_rtx, false, model, model))
!   return target;
!   else
!   /* Otherwise there is no atomic load, leave the library call.  */
! return NULL_RTX;
  }
  
/* Otherwise assume loads are atomic, and emit the proper barriers.  */

Re: [PATCH] Fix PR50031

[Richard Guenther]

On Wed, Feb 8, 2012 at 3:39 PM, William J. Schmidt
 wrote:
> This is a vectorizer patch I inherited from Ira.  As with the fix for
> PR50969, it handles problems with excessive permutes by adjusting the
> cost model.  In this case the permutes comes from type
> promotion/demotion, which is now modeled with a new vec_cvt cost.
>
> This restores the lost performance for sphinx3, and gives wupwise an
> additional boost.  This is a performance workaround for 4.7; for 4.8 we
> want to try to do a better job of modeling the real issue, which is that
> VSX permutes are constrained to a single processor pipe.  Thus isolated
> permutes are less expensive per instruction than denser collections of
> permutes.
>
> There also remains an opportunity for versioning loops for alignment.
>
> Bootstrapped and tested on powerpc64-linux with no regressions.  OK for
> trunk?
>
> Thanks,
> Bill
>
>
> 2012-02-08  Bill Schmidt  
>            Ira Rosen  
>
>        PR tree-optimization/50031
>        * targhooks.c (default_builtin_vectorization_cost): Handle vec_cvt.
>        * target.h (enum vect_cost_for_stmt): Add vec_cvt.
>        * tree-vect-loop.c (vect_get_single_scalar_iteraion_cost): Handle
>        all types of reduction and pattern statements.
>        (vect_estimate_min_profitable_iters): Likewise.
>        * tree-vect-stmts.c (vect_model_simple_cost): Use vec_cvt cost for
>        type promotions and demotions.
>        (vect_model_conversion_cost): New function.
>        (vect_get_load_cost): Use vec_perm for permutations; add dump logic
>        for explicit realigns.
>        (vectorizable_conversion): Call vect_model_conversion_cost.
>        * config/spu/spu.c (spu_builtin_vectorization_cost): Handle vec_cvt.
>        * config/i386/i386.c (ix86_builtin_vectorization_cost): Likewise.
>        * config/rs6000/rs6000.c (rs6000_builtin_vectorization_cost): Update
>        vec_perm for VSX and handle vec_cvt.
>
>
> Index: gcc/targhooks.c
> ===
> --- gcc/targhooks.c     (revision 183944)
> +++ gcc/targhooks.c     (working copy)
> @@ -514,6 +514,7 @@ default_builtin_vectorization_cost (enum vect_cost
>       case scalar_to_vec:
>       case cond_branch_not_taken:
>       case vec_perm:
> +      case vec_cvt:
>         return 1;
>
>       case unaligned_load:
> Index: gcc/target.h
> ===
> --- gcc/target.h        (revision 183944)
> +++ gcc/target.h        (working copy)
> @@ -145,7 +145,8 @@ enum vect_cost_for_stmt
>   scalar_to_vec,
>   cond_branch_not_taken,
>   cond_branch_taken,
> -  vec_perm
> +  vec_perm,
> +  vec_cvt
>  };

Somewhere we should document what these mean.  vec_cvt certainly
is non-obvious, especially as it does not apply to int <-> float converts.
Maybe vec_promote_demote would be a better name.

>  /* The target structure.  This holds all the backend hooks.  */
> Index: gcc/tree-vect-loop.c
> ===
> --- gcc/tree-vect-loop.c        (revision 183944)
> +++ gcc/tree-vect-loop.c        (working copy)
> @@ -2417,7 +2417,8 @@ vect_get_single_scalar_iteraion_cost (loop_vec_inf
>           if (stmt_info
>               && !STMT_VINFO_RELEVANT_P (stmt_info)
>               && (!STMT_VINFO_LIVE_P (stmt_info)
> -                  || STMT_VINFO_DEF_TYPE (stmt_info) != vect_reduction_def))
> +                  || !VECTORIZABLE_CYCLE_DEF (STMT_VINFO_DEF_TYPE 
> (stmt_info)))
> +             && !STMT_VINFO_IN_PATTERN_P (stmt_info))
>             continue;
>
>           if (STMT_VINFO_DATA_REF (vinfo_for_stmt (stmt)))
> @@ -2562,17 +2563,51 @@ vect_estimate_min_profitable_iters (loop_vec_info
>
>       for (si = gsi_start_bb (bb); !gsi_end_p (si); gsi_next (&si))
>        {
> -         gimple stmt = gsi_stmt (si);
> +         gimple stmt = gsi_stmt (si), pattern_stmt;
>          stmt_vec_info stmt_info = vinfo_for_stmt (stmt);
>          /* Skip stmts that are not vectorized inside the loop.  */
>          if (!STMT_VINFO_RELEVANT_P (stmt_info)
>              && (!STMT_VINFO_LIVE_P (stmt_info)
> -                 || STMT_VINFO_DEF_TYPE (stmt_info) != vect_reduction_def))
> -           continue;
> +                 || !VECTORIZABLE_CYCLE_DEF (STMT_VINFO_DEF_TYPE 
> (stmt_info
> +           {
> +             if (STMT_VINFO_IN_PATTERN_P (stmt_info)
> +                 && (pattern_stmt = STMT_VINFO_RELATED_STMT (stmt_info))
> +                 && (STMT_VINFO_RELEVANT_P (vinfo_for_stmt (pattern_stmt))
> +                     || STMT_VINFO_LIVE_P (vinfo_for_stmt (pattern_stmt
> +                {
> +                  stmt = pattern_stmt;
> +                  stmt_info = vinfo_for_stmt (stmt);
> +               }
> +             else
> +               continue;
> +           }

It looks super-ugly that way.  I think we should _always_ use the main pattern
stmt - do we at this point already have generated the vectorized loop?

Re: [PATCH] Fix atomic load for unsupported data sizes

[Richard Guenther]

On Wed, Feb 8, 2012 at 4:16 PM, Andrew MacLeod  wrote:
> When investigating an issue on arm, I discovered a bug that needs fixing.
>
> If there is no atomic_load pattern  for data which is larger than the native
> word size, we try to issue a compare_and_swap loop.  Problem is there is no
> check to see if it succeeded or failed.  If the compare-swap loop isn't
> emitted, we need to leave the __atomic_load_N call rather than silently
> generate incorrect code.
>
> Attached patch bootstraps on   x86_64-unknown-linux-gnu and fixes the
> problem on an arm cross compiler.
>
> No new regressions in the testsuite, and is a harmless change for working
> code.
>
> OK to check in?  GCC 4.7 is still mainline isn't it?

Ok and yes.

Thanks,
Richard.

> Andrew
>
>

[PATCH] Fix PR46886

[Richard Guenther]

transform_to_exit_first_loop of the parloops pass can appearantly
not handle (certain?) loops that were not header-copied.  Thus, better
assert we face a do-while-style loop before parallelizing it.

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

Richard.

2012-03-08  Richard Guenther  

PR tree-optimization/46886
* tree-flow.h (do_while_loop_p): Declare.
* tree-ssa-loop-ch.c (do_while_loop_p): Export.
* tree-parloops.c (parallelize_loops): Only parallelize do-while
loops.

* testsuite/libgomp.c/pr46886.c: New testcase.

Index: gcc/tree-flow.h
===
*** gcc/tree-flow.h (revision 184007)
--- gcc/tree-flow.h (working copy)
*** extern bool may_propagate_copy (tree, tr
*** 619,624 
--- 619,627 
  extern bool may_propagate_copy_into_stmt (gimple, tree);
  extern bool may_propagate_copy_into_asm (tree);
  
+ /* In tree-ssa-loop-ch.c  */
+ bool do_while_loop_p (struct loop *);
+ 
  /* Affine iv.  */
  
  typedef struct
Index: gcc/tree-ssa-loop-ch.c
===
*** gcc/tree-ssa-loop-ch.c  (revision 184007)
--- gcc/tree-ssa-loop-ch.c  (working copy)
*** should_duplicate_loop_header_p (basic_bl
*** 104,110 
  
  /* Checks whether LOOP is a do-while style loop.  */
  
! static bool
  do_while_loop_p (struct loop *loop)
  {
gimple stmt = last_stmt (loop->latch);
--- 104,110 
  
  /* Checks whether LOOP is a do-while style loop.  */
  
! bool
  do_while_loop_p (struct loop *loop)
  {
gimple stmt = last_stmt (loop->latch);
Index: gcc/tree-parloops.c
===
*** gcc/tree-parloops.c (revision 184007)
--- gcc/tree-parloops.c (working copy)
*** parallelize_loops (void)
*** 2183,2189 
  || loop_has_blocks_with_irreducible_flag (loop)
  || (loop_preheader_edge (loop)->src->flags & BB_IRREDUCIBLE_LOOP)
  /* FIXME: the check for vector phi nodes could be removed.  */
! || loop_has_vector_phi_nodes (loop))
continue;
estimated = max_stmt_executions_int (loop, false);
/* FIXME: Bypass this check as graphite doesn't update the
--- 2183,2192 
  || loop_has_blocks_with_irreducible_flag (loop)
  || (loop_preheader_edge (loop)->src->flags & BB_IRREDUCIBLE_LOOP)
  /* FIXME: the check for vector phi nodes could be removed.  */
! || loop_has_vector_phi_nodes (loop)
! /* FIXME: transform_to_exit_first_loop does not handle not
!header-copied loops correctly - see PR46886.  */
! || !do_while_loop_p (loop))
continue;
estimated = max_stmt_executions_int (loop, false);
/* FIXME: Bypass this check as graphite doesn't update the
Index: libgomp/testsuite/libgomp.c/pr46886.c
===
*** libgomp/testsuite/libgomp.c/pr46886.c   (revision 0)
--- libgomp/testsuite/libgomp.c/pr46886.c   (revision 0)
***
*** 0 
--- 1,28 
+ /* { dg-do run } */
+ /* { dg-options "-O -ftree-parallelize-loops=4 -fno-tree-ch 
-fno-tree-dominator-opts" } */
+ 
+ void abort(void);
+ 
+ int d[1024], e[1024];
+ 
+ int foo (void)
+ {
+   int s = 0;
+   int i;
+   for (i = 0; i < 1024; i++)
+ s += d[i] - e[i];
+   return s;
+ }
+ 
+ int main ()
+ {
+   int i;
+   for (i = 0; i < 1024; i++)
+ {
+   d[i] = i * 2;
+   e[i] = i;
+ }
+   if (foo () != 1023 * 1024 / 2)
+ abort ();
+   return 0;
+ }

Re: [PING2] New port resubmission for TILEPro and TILE-Gx

[Walter Lee]

Still looking for review.  It's been about a month and a half.

Thanks,

Walter

On 1/27/2012 12:47 PM, Walter Lee wrote:

Ping? It's been a month. Seeing more feedback or status update.

Thanks,

Walter Lee

On 12/30/2011 7:30 PM, Walter Lee wrote:

I'm resubmitting the gcc ports to TILE-Gx and TILEPro as replies to
this email. The resubmission addresses the feedback made by Richard
Henderson in:

http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01232.html, and
http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01247.html

Feedback by Joseph Myers made in:

http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01385.html
http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01387.html

was addressed in a previous submission.

Here is a summary of the issues addressed:

Changes made to both ports:

- added vector patterns for suitable vector ops.

- cleaned up various move pattens, deleting dead alternatives,
deleting redundant immediate insn_and_split patterns, and delete
unnecessary movdi multi-word move pattern (tilepro only).

- added extra insv patterns.

- combined all the conditional moves into one pattern.

- combined "*lh" and "*extendhisi2" pattern, and "*lb" and
"*extendqihi2".

- partially remove the divsi stubs that were there to work around an
old gcc bug that has been partially fixed. Previously gcc would not
turn divide by constant into multiply by constant unless there is a
pattern for the divide of the given mode. It now seems to do
better, but we still need the stub on tilegx, else it turns 32-bit
divide by constant into 64-bit multiply by constant.

- wrap the GOT and TLS unspec addresses in const, and handle them with
a single pattern.

- add support for post_{inc,dec,modify} addressing modes.

- fixed invalid rtl sharing in alloca handling routines.

- use REG_CFA_* notes in prologue and epilogue.

- Use post-inc load in TARGET_ASM_TRAMPOLINE_TEMPLATE.

- converted the following to target hooks: LIBCALL_VALUE,
FUNCTION_VALUE_REGNO_P, GO_IF_LEGITIMATE_ADDRESS. Delete
GO_IF_MODE_DEPENDENT_ADDRESS and use the default.

- use the new atomics_ names and patterns.

Changes made to tilegx port:

- merged the AND patterns.

- add patterns that sign extends an SI result to DI for all the 32-bit
insns.

Here are replies to a few feedback items:


optabs.c will do exactly this if the pattern is not present. Similarly
for the DImode logicals (popcount, parity, etc).


I tried taking out the patterns for ctzdi2, clzdi2, ffsdi2, paritydi2,
and popcountdi2, and I found that the compiler generates libgcc
function calls for all of them except clzdi2. For clzdi2 the tilepro
pattern is better than the default because it uses mvnz to get rid of
a branch.

This is all true for gcc 4.4.6... gcc 4.7 does not use my patterns at
all, which seems like a bug.

I need the paritysi2 as well; without it the compiler does not
generate code for paritydi2 properly.


Post merge, consider changing this to simple_return to enable shrink
wrapping. This may also involve epilogue unwind fixups though.


I have not enabled the "simple_return" pattern. On the tile ports,
the prologue defines a register not accounted for in the shrink
wrapping code (the PIC_TEXT_LABEL_REGNUM register). Is there a plan
to provide a target hook to support this? I did verify that shrink
wrapping work properly when I account for this register.


I also don't see support for AND addresses, as for lw_na. And yet you
seem to be using those addressing modes in
tilepro_expand_unaligned_load.
I can only assume these are failing validate_mem, and forcing the
address into a register first?


Yeah there is no AND addressing mode; the addresses are being put into
registers.


Why not use gp-relative references? A small matter of extending the
assembler with new relocations, perhaps.


We don't have that support in the tool chain currently. I can look
into it, but I haven't done it.


/* We represent all SI values as sign-extended DI values in
registers. */
#define TRULY_NOOP_TRUNCATION(OUTPREC, INPREC) \
((INPREC)<= 32 || (OUTPREC)> 32)


I think you should be *very* careful before you insist on this. Do
you not have a memory mode that ignores the high bits for 32-bit
pointers? From the description of "memoryReadWord", it does seem like
you've got modes that pre-process input addresses.


Unfortunately all the address bits are read; we do not ignore the high
bits of 32-bit pointers.


MIPS uses this because, technically, the 32-bit operation insns
produce undefined results when given inputs that are not
sign-extended. I see no such restriction in the TileGx manual.


I think the issue is that we do not have 32-bit compares; we just
reuse the 64-bit ones. This requires that the inputs be sign
extended.


At least in 64-bit pointer mode, I think you should drop this and make
sure that you've got appropriate sign_extend patterns for all of the
"x" insns. Similar to how x86_64 does for the zero_extend patterns.


I've added the sign_extend patterns for the 32-bit insns.

Please let me 

Re: [PATCH] increase timeout in simulate-thread gdb test

[Andrew MacLeod]

On 02/08/2012 09:47 AM, Andrew MacLeod wrote:


I propose increasing the time to 20 seconds and reduce the log file.  
I believe the timeout as made really short because of the size of the 
log file when the timeout was needed. I htink it was an arbitrary 
number.   Doubling the execution time and halving the size of the log 
file should put us about where we were.


Im even fine abandoning most of the log file if need be as well... Its 
really pass or fail that I care about and a fail usually requires hand 
investigation anyway


The other thing we can do is to only run the test with -O0 and -O3.   
right now they run with -O0, -O1, -O2, -O3, -Os.  I don't think the 
other options really add much.



So something like the following changes:


I'm running a testsuite run on x86-64 right now, I'll try arm as well 
shortly. Presuming that it runs properly, is this OK for mainline?


Andrew

2012-02-08  Jack Howarth 

* lib/gcc-simulate-thread.exp (simulate-thread): Increase timeout
  to 20 seconds.

2012-02-08  Andrew MacLeod  

* gcc.dg/simulate-thread/simulate-thread.exp: Use only -O0 and -O3.
* gcc.dg/simulate-thread/simulate-thread.gdb: Don't display every 
machine instuction in the log.

Index: lib/gcc-simulate-thread.exp
===
*** lib/gcc-simulate-thread.exp (revision 183969)
--- lib/gcc-simulate-thread.exp (working copy)
*** proc simulate-thread { args } {
*** 56,63 
  
  set gdb_worked 0
  
! # Set timeout to 10 seconds due to huge amount of generated log.
! remote_expect target 10 {
# Too old GDB
-re "Unhandled dwarf expression|Error in sourced command file" {
unsupported "$testcase $message"
--- 56,63 
  
  set gdb_worked 0
  
! # Set timeout to 20 seconds due to huge amount of generated log.
! remote_expect target 20 {
# Too old GDB
-re "Unhandled dwarf expression|Error in sourced command file" {
unsupported "$testcase $message"
Index: gcc.dg/simulate-thread/simulate-thread.exp
===
*** gcc.dg/simulate-thread/simulate-thread.exp  (revision 183969)
--- gcc.dg/simulate-thread/simulate-thread.exp  (working copy)
*** dg-init
*** 24,33 
  torture-init
  set-torture-options [list \
{ -O0 -g } \
!   { -O1 -g } \
!   { -O2 -g } \
!   { -O3 -g } \
!   { -Os -g } ]
  
  if [gdb-exists] {
gcc-dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/*.c]] ""
--- 24,30 
  torture-init
  set-torture-options [list \
{ -O0 -g } \
!   { -O3 -g } ]
  
  if [gdb-exists] {
gcc-dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/*.c]] ""
Index: gcc.dg/simulate-thread/simulate-thread.gdb
===
*** gcc.dg/simulate-thread/simulate-thread.gdb  (revision 183969)
--- gcc.dg/simulate-thread/simulate-thread.gdb  (working copy)
***
*** 1,6 
  set height 0
  break simulate_thread_main
! disp/i $pc
  run
  
  set $ret = 0
--- 1,6 
  set height 0
  break simulate_thread_main
! # disp/i $pc
  run
  
  set $ret = 0

Re: [PATCH][ARM] Improve 64-bit shifts (non-NEON)

[Andrew Stubbs]

On 08/02/12 11:18, Andrew Stubbs wrote:

I've tried to do this, but it can't be done by a straight translation
because we don't have the insns available to do it. As I understand it,
all "predicable" instructions automatically get a cond_exec variant, but
the only if_then_else I could find (it's hard to grep because
if_then_else occurs many times in attributes) is in the conditional move
instruction. Have I missed something?


Ok, I missed the various patterns like if_arith_move.

Unfortunately, these don't work in Thumb mode (no IT block), and I'd 
have to add arith-shift variants, I think, for ARM mode to work.


H ... I'll try again.

Andrew

Re: [PATCH] increase timeout in simulate-thread gdb test

[Jack Howarth]

On Wed, Feb 08, 2012 at 11:02:02AM -0500, Andrew MacLeod wrote:
> On 02/08/2012 09:47 AM, Andrew MacLeod wrote:
>>
>> I propose increasing the time to 20 seconds and reduce the log file.   
>> I believe the timeout as made really short because of the size of the  
>> log file when the timeout was needed. I htink it was an arbitrary  
>> number.   Doubling the execution time and halving the size of the log  
>> file should put us about where we were.
>>
>> Im even fine abandoning most of the log file if need be as well... Its  
>> really pass or fail that I care about and a fail usually requires hand  
>> investigation anyway
>>
>> The other thing we can do is to only run the test with -O0 and -O3.
>> right now they run with -O0, -O1, -O2, -O3, -Os.  I don't think the  
>> other options really add much.
>>
> So something like the following changes:
>
>
> I'm running a testsuite run on x86-64 right now, I'll try arm as well  
> shortly. Presuming that it runs properly, is this OK for mainline?

Andrew,
   I can confirm that this eliminates the unexpected failures in
simulate-thread.exp on x86_64-apple-darwin11...

Native configuration is x86_64-apple-darwin11.3.0

=== gcc tests ===


Running target unix/-m32

=== gcc Summary for unix/-m32 ===

# of expected passes49
# of unsupported tests  7

Running target unix/-m64

=== gcc Summary for unix/-m64 ===

# of expected passes57
# of unsupported tests  3

=== gcc Summary ===

# of expected passes    106
# of unsupported tests  10
/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/xgcc  version 4.7.0 20120208 
(experimental) (GCC) 

Compiler version: 4.7.0 20120208 (experimental) (GCC) 
Platform: x86_64-apple-darwin11.3.0
configure flags: --prefix=/sw --prefix=/sw/lib/gcc4.7 --mandir=/sw/share/man 
--infodir=/sw/lib/gcc4.7/info --with-build-config=bootstrap-lto 
--enable-stage1-languages=c,lto 
--enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw 
--with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw 
--with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib 
--program-suffix=-fsf-4.7 --enable-checking=release --enable-cloog-backend=isl

Thanks for the fix.
  Jack
>
> Andrew
>

> 2012-02-08  Jack Howarth 
> 
>   * lib/gcc-simulate-thread.exp (simulate-thread): Increase timeout
> to 20 seconds.
> 
> 2012-02-08  Andrew MacLeod  
> 
>   * gcc.dg/simulate-thread/simulate-thread.exp: Use only -O0 and -O3.
>   * gcc.dg/simulate-thread/simulate-thread.gdb: Don't display every 
>   machine instuction in the log.
> 
> Index: lib/gcc-simulate-thread.exp
> ===
> *** lib/gcc-simulate-thread.exp   (revision 183969)
> --- lib/gcc-simulate-thread.exp   (working copy)
> *** proc simulate-thread { args } {
> *** 56,63 
>   
>   set gdb_worked 0
>   
> ! # Set timeout to 10 seconds due to huge amount of generated log.
> ! remote_expect target 10 {
>   # Too old GDB
>   -re "Unhandled dwarf expression|Error in sourced command file" {
>   unsupported "$testcase $message"
> --- 56,63 
>   
>   set gdb_worked 0
>   
> ! # Set timeout to 20 seconds due to huge amount of generated log.
> ! remote_expect target 20 {
>   # Too old GDB
>   -re "Unhandled dwarf expression|Error in sourced command file" {
>   unsupported "$testcase $message"
> Index: gcc.dg/simulate-thread/simulate-thread.exp
> ===
> *** gcc.dg/simulate-thread/simulate-thread.exp(revision 183969)
> --- gcc.dg/simulate-thread/simulate-thread.exp(working copy)
> *** dg-init
> *** 24,33 
>   torture-init
>   set-torture-options [list \
>   { -O0 -g } \
> ! { -O1 -g } \
> ! { -O2 -g } \
> ! { -O3 -g } \
> ! { -Os -g } ]
>   
>   if [gdb-exists] {
> gcc-dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/*.c]] ""
> --- 24,30 
>   torture-init
>   set-torture-options [list \
>   { -O0 -g } \
> ! { -O3 -g } ]
>   
>   if [gdb-exists] {
> gcc-dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/*.c]] ""
> Index: gcc.dg/simulate-thread/simulate-thread.gdb
> ===
> *** gcc.dg/simulate-thread/simulate-thread.gdb(revision 183969)
> --- gcc.dg/simulate-thread/simulate-thread.gdb(working copy)
> ***
> *** 1,6 
>   set height 0
>   break simulate_thread_main
> ! disp/i $pc
>   run
>   
>   set $ret = 0
> --- 1,6 
>   set height 0
>   break simulate_thread_main
> ! # disp/i $pc
>   run
>   
>   set $ret = 0

Re: [PATCH] Fix PR50031

[William J. Schmidt]

On Wed, 2012-02-08 at 16:18 +0100, Richard Guenther wrote:
> On Wed, Feb 8, 2012 at 3:39 PM, William J. Schmidt
>  wrote:
> > This is a vectorizer patch I inherited from Ira.  As with the fix for
> > PR50969, it handles problems with excessive permutes by adjusting the
> > cost model.  In this case the permutes comes from type
> > promotion/demotion, which is now modeled with a new vec_cvt cost.
> >
> > This restores the lost performance for sphinx3, and gives wupwise an
> > additional boost.  This is a performance workaround for 4.7; for 4.8 we
> > want to try to do a better job of modeling the real issue, which is that
> > VSX permutes are constrained to a single processor pipe.  Thus isolated
> > permutes are less expensive per instruction than denser collections of
> > permutes.
> >
> > There also remains an opportunity for versioning loops for alignment.
> >
> > Bootstrapped and tested on powerpc64-linux with no regressions.  OK for
> > trunk?
> >
> > Thanks,
> > Bill
> >
> >
> > 2012-02-08  Bill Schmidt  
> >Ira Rosen  
> >
> >PR tree-optimization/50031
> >* targhooks.c (default_builtin_vectorization_cost): Handle vec_cvt.
> >* target.h (enum vect_cost_for_stmt): Add vec_cvt.
> >* tree-vect-loop.c (vect_get_single_scalar_iteraion_cost): Handle
> >all types of reduction and pattern statements.
> >(vect_estimate_min_profitable_iters): Likewise.
> >* tree-vect-stmts.c (vect_model_simple_cost): Use vec_cvt cost for
> >type promotions and demotions.
> >(vect_model_conversion_cost): New function.
> >(vect_get_load_cost): Use vec_perm for permutations; add dump logic
> >for explicit realigns.
> >(vectorizable_conversion): Call vect_model_conversion_cost.
> >* config/spu/spu.c (spu_builtin_vectorization_cost): Handle vec_cvt.
> >* config/i386/i386.c (ix86_builtin_vectorization_cost): Likewise.
> >* config/rs6000/rs6000.c (rs6000_builtin_vectorization_cost): Update
> >vec_perm for VSX and handle vec_cvt.
> >
> >
> > Index: gcc/targhooks.c
> > ===
> > --- gcc/targhooks.c (revision 183944)
> > +++ gcc/targhooks.c (working copy)
> > @@ -514,6 +514,7 @@ default_builtin_vectorization_cost (enum vect_cost
> >   case scalar_to_vec:
> >   case cond_branch_not_taken:
> >   case vec_perm:
> > +  case vec_cvt:
> > return 1;
> >
> >   case unaligned_load:
> > Index: gcc/target.h
> > ===
> > --- gcc/target.h(revision 183944)
> > +++ gcc/target.h(working copy)
> > @@ -145,7 +145,8 @@ enum vect_cost_for_stmt
> >   scalar_to_vec,
> >   cond_branch_not_taken,
> >   cond_branch_taken,
> > -  vec_perm
> > +  vec_perm,
> > +  vec_cvt
> >  };
> 
> Somewhere we should document what these mean.  vec_cvt certainly
> is non-obvious, especially as it does not apply to int <-> float converts.
> Maybe vec_promote_demote would be a better name.

Fully agree.  I'll change to that name.

> 
> >  /* The target structure.  This holds all the backend hooks.  */
> > Index: gcc/tree-vect-loop.c
> > ===
> > --- gcc/tree-vect-loop.c(revision 183944)
> > +++ gcc/tree-vect-loop.c(working copy)
> > @@ -2417,7 +2417,8 @@ vect_get_single_scalar_iteraion_cost (loop_vec_inf
> >   if (stmt_info
> >   && !STMT_VINFO_RELEVANT_P (stmt_info)
> >   && (!STMT_VINFO_LIVE_P (stmt_info)
> > -  || STMT_VINFO_DEF_TYPE (stmt_info) != 
> > vect_reduction_def))
> > +  || !VECTORIZABLE_CYCLE_DEF (STMT_VINFO_DEF_TYPE 
> > (stmt_info)))
> > + && !STMT_VINFO_IN_PATTERN_P (stmt_info))
> > continue;
> >
> >   if (STMT_VINFO_DATA_REF (vinfo_for_stmt (stmt)))
> > @@ -2562,17 +2563,51 @@ vect_estimate_min_profitable_iters (loop_vec_info
> >
> >   for (si = gsi_start_bb (bb); !gsi_end_p (si); gsi_next (&si))
> >{
> > - gimple stmt = gsi_stmt (si);
> > + gimple stmt = gsi_stmt (si), pattern_stmt;
> >  stmt_vec_info stmt_info = vinfo_for_stmt (stmt);
> >  /* Skip stmts that are not vectorized inside the loop.  */
> >  if (!STMT_VINFO_RELEVANT_P (stmt_info)
> >  && (!STMT_VINFO_LIVE_P (stmt_info)
> > - || STMT_VINFO_DEF_TYPE (stmt_info) != vect_reduction_def))
> > -   continue;
> > + || !VECTORIZABLE_CYCLE_DEF (STMT_VINFO_DEF_TYPE 
> > (stmt_info
> > +   {
> > + if (STMT_VINFO_IN_PATTERN_P (stmt_info)
> > + && (pattern_stmt = STMT_VINFO_RELATED_STMT (stmt_info))
> > + && (STMT_VINFO_RELEVANT_P (vinfo_for_stmt (pattern_stmt))
> > + || STMT_VINFO_LIVE_P (vinfo_for_stmt (pattern_stmt
> > +{
> > + 

Re: [PATCH] increase timeout in simulate-thread gdb test

[Andrew MacLeod]

On 02/08/2012 11:43 AM, Jack Howarth wrote:


So something like the following changes:


I'm running a testsuite run on x86-64 right now, I'll try arm as well
shortly. Presuming that it runs properly, is this OK for mainline?

Andrew,
I can confirm that this eliminates the unexpected failures in
simulate-thread.exp on x86_64-apple-darwin11...


This also resolved my arm tests, as well as works fine on x86-64.OK 
for mainline?


Andrew

[PATCH} backport r175475 to gcc-4_6-branch

[Jack Howarth]

   Currently PR49536 still exists in gcc-4_6-branch. The following
patch backports r175475 for the gcc 4.6.3 release. This will be helpful
to dragonegg users (http://llvm.org/bugs/show_bug.cgi?id=10042) as
dragonegg currently doesn't build against FSF gcc trunk yet. Regression
tested on x86_64-apple-darwin11...

http://gcc.gnu.org/ml/gcc-testresults/2012-02/msg00599.html

Okay for gcc-4_6-branch and thus gcc 4.6.3?
Jack

2012-02-08  Jack Howarth  

Backport from mainline
2011-06-27  Richard Guenther  

PR tree-optimization/49536
* tree-vect-stmts.c (get_vectype_for_scalar_type_and_size):
For non-scalar inner types use a scalar type according to
the scalar inner mode.

Index: gcc/tree-vect-stmts.c
===
--- gcc/tree-vect-stmts.c   (revision 183938)
+++ gcc/tree-vect-stmts.c   (working copy)
@@ -5117,6 +5117,15 @@ get_vectype_for_scalar_type_and_size (tr
   && GET_MODE_CLASS (inner_mode) != MODE_FLOAT)
 return NULL_TREE;
 
+  /* We shouldn't end up building VECTOR_TYPEs of non-scalar components.
+ When the component mode passes the above test simply use a type
+ corresponding to that mode.  The theory is that any use that
+ would cause problems with this will disable vectorization anyway.  */
+  if (!SCALAR_FLOAT_TYPE_P (scalar_type)
+  && !INTEGRAL_TYPE_P (scalar_type)
+  && !POINTER_TYPE_P (scalar_type))
+scalar_type = lang_hooks.types.type_for_mode (inner_mode, 1);
+
   /* If no size was supplied use the mode the target prefers.   Otherwise
  lookup a vector mode of the specified size.  */
   if (size == 0)

[Patch, Fortran] PR 52151: reallocation w/ RESHAPE: also set stride

[Tobias Burnus]

Hi all,

this patch is a follow up to the recent patch on RESHAPE with an 
allocatable LHS. It turned out that if the LHS is not allocated or has 
the wrong shape, the bounds are not correctly set. Or to be precise: The 
just internally used* "stride" is not set correctly.


Result: Either the wrong elements were accessed or - in particular for 
unallocated arrays with "garbage" or malloc_perturb_ initialization - a 
segfault occurred. Especially the case of having the wrong values is nasty!


The bug was found by Dominique, who found it when looking at the 
chapter08/puppeteer_f2003 example in Damian (et al.)'s book. Thanks 
Dominique!


While that's not a regression, I think the bug is seriously enough and 
the fix simple enough that it should also be applied to 4.6.


Thus: OK for the trunk and 4.6? (The patch has been build and regtested 
on x86-64-linux.)


Tobias
2012-02-08  Tobias Burnus  

	PR fortran/52151
	* trans-expr.c (fcncall_realloc_result): Set also the stride.

2012-02-08  Tobias Burnus  

	PR fortran/52151
	* gfortran.dg/realloc_on_assign_12.f90: New.

Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c	(revision 184010)
+++ gcc/fortran/trans-expr.c	(working copy)
@@ -6370,16 +6370,15 @@ fcncall_realloc_result (gfc_se *se, int rank)
   gfc_conv_descriptor_ubound_set (&se->post, desc,
   gfc_rank_cst[n], tmp);
 
-  /* Accumulate the offset.  */
-  tmp = gfc_conv_descriptor_stride_get (desc, gfc_rank_cst[n]);
+  /* Set stride and accumulate the offset.  */
+  tmp = gfc_conv_descriptor_stride_get (res_desc, gfc_rank_cst[n]);
+  gfc_conv_descriptor_stride_set (&se->post, desc,
+  gfc_rank_cst[n], tmp);
   tmp = fold_build2_loc (input_location, MULT_EXPR,
-gfc_array_index_type,
-lbound, tmp);
+			 gfc_array_index_type, lbound, tmp);
   offset = fold_build2_loc (input_location, MINUS_EXPR,
-gfc_array_index_type,
-offset, tmp);
+gfc_array_index_type, offset, tmp);
   offset = gfc_evaluate_now (offset, &se->post);
-
 }
 
   gfc_conv_descriptor_offset_set (&se->post, desc, offset);
Index: gcc/testsuite/gfortran.dg/realloc_on_assign_12.f90
===
--- gcc/testsuite/gfortran.dg/realloc_on_assign_12.f90	(revision 0)
+++ gcc/testsuite/gfortran.dg/realloc_on_assign_12.f90	(working copy)
@@ -0,0 +1,96 @@
+! { dg-do run }
+!
+! PR fortran/52151
+!
+! Check that the bounds/shape/strides are correctly set
+! for (re)alloc on assignment, if the LHS is either not
+! allocated or has the wrong shape. This test is for
+! code which is only invoked for libgfortran intrinsic
+! such as RESHAPE.
+!
+! Based on the example of PR 52117 by Steven Hirshman
+!
+PROGRAM RESHAPEIT
+  call unalloc ()
+  call wrong_shape ()
+contains
+subroutine unalloc ()
+  INTEGER, PARAMETER :: n1=2, n2=2, n3=2
+  INTEGER:: m1, m2, m3, lc
+  REAL, ALLOCATABLE  :: A(:,:), B(:,:,:)
+  REAL   :: val
+
+  ALLOCATE (A(n1,n2*n3))
+! << B is not allocated
+
+  val = 0
+  lc = 0
+  DO m3=1,n3
+ DO m2=1,n2
+lc = lc+1
+DO m1=1,n1
+   val = val+1
+   A(m1, lc) = val
+END DO
+ END DO
+  END DO
+
+  B = RESHAPE(A, [n1,n2,n3])
+
+  if (any (shape (B)  /= [n1,n2,n3])) call abort ()
+  if (any (ubound (B) /= [n1,n2,n3])) call abort ()
+  if (any (lbound (B) /= [1,1,1])) call abort ()
+
+  lc = 0
+  DO m3=1,n3
+ DO m2=1,n2
+lc = lc+1
+DO m1=1,n1
+!   PRINT *,'A(',m1,',',lc,') = ',A(m1,lc),' B = ',B(m1,m2,m3)
+   if (A(m1,lc) /= B(m1,m2,m3)) call abort ()
+END DO
+ END DO
+  END DO
+  DEALLOCATE(A, B)
+end subroutine unalloc
+
+subroutine wrong_shape ()
+  INTEGER, PARAMETER :: n1=2, n2=2, n3=2
+  INTEGER:: m1, m2, m3, lc
+  REAL, ALLOCATABLE  :: A(:,:), B(:,:,:)
+  REAL   :: val
+
+  ALLOCATE (A(n1,n2*n3))
+  ALLOCATE (B(1,1,1)) ! << shape differs from RHS
+
+  val = 0
+  lc = 0
+  DO m3=1,n3
+ DO m2=1,n2
+lc = lc+1
+DO m1=1,n1
+   val = val+1
+   A(m1, lc) = val
+END DO
+ END DO
+  END DO
+
+  B = RESHAPE(A, [n1,n2,n3])
+
+  if (any (shape (B)  /= [n1,n2,n3])) call abort ()
+  if (any (ubound (B) /= [n1,n2,n3])) call abort ()
+  if (any (lbound (B) /= [1,1,1])) call abort ()
+
+  lc = 0
+  DO m3=1,n3
+ DO m2=1,n2
+lc = lc+1
+DO m1=1,n1
+!   PRINT *,'A(',m1,',',lc,') = ',A(m1,lc),' B = ',B(m1,m2,m3)
+   if (A(m1,lc) /= B(m1,m2,m3)) call abort ()
+END DO
+ END DO
+  END DO
+  DEALLOCATE(A, B)
+end subroutine wrong_shape
+

Re: [Patch, Fortran] PR 52151: reallocation w/ RESHAPE: also set stride

[Steve Kargl]

On Wed, Feb 08, 2012 at 06:46:03PM +0100, Tobias Burnus wrote:
> 
> this patch is a follow up to the recent patch on RESHAPE with an 
> allocatable LHS. It turned out that if the LHS is not allocated or has 
> the wrong shape, the bounds are not correctly set. Or to be precise: The 
> just internally used* "stride" is not set correctly.
> 
> Result: Either the wrong elements were accessed or - in particular for 
> unallocated arrays with "garbage" or malloc_perturb_ initialization - a 
> segfault occurred. Especially the case of having the wrong values is nasty!
> 
> The bug was found by Dominique, who found it when looking at the 
> chapter08/puppeteer_f2003 example in Damian (et al.)'s book. Thanks 
> Dominique!
> 
> While that's not a regression, I think the bug is seriously enough and 
> the fix simple enough that it should also be applied to 4.6.
> 
> Thus: OK for the trunk and 4.6? (The patch has been build and regtested 
> on x86-64-linux.)
> 

OK for both trunk and 4.6. Thanks for tracking down the problem.

-- 
Steve

[PATCH] Fix var-tracking /c vs. non-/c note emitting (PR debug/52165)

[Jakub Jelinek]

Hi!

emit_note_insn_var_location already had code to ensure that
non-NOTE_DURING_CALL_P notes emitted EMIT_NOTE_BEFORE_INSN
with NEXT_INSN (call_insn) are put after all the NOTE_DURING_CALL_P
notes after the call, but if there is NOTE_INSN_CALL_ARG_LOCATION
note there too, this code doesn't trigger and we would emit
a non-NOTE_DURING_CALL_P note before NOTE_INSN_CALL_ARG_LOCATION
note possibly followed by NOTE_DURING_CALL_P notes.  That then may
trigger ICEs in dwarf2out, which assumes that the LVL labels change
monotonically, and that for calls first come all .LVLXXX-1 labels (if any)
and then .LVLXXX (if any).

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux and
with go cross to s390x-linux.  Ok for trunk?

2012-02-08  Jakub Jelinek  

PR debug/52165
* var-tracking.c (emit_note_insn_var_location): If
EMIT_NOTE_BEFORE_INSN and insn is NOTE_INSN_CALL_ARG_LOCATION,
emit it before next non-NOTE_INSN_CALL_ARG_LOCATION
non-NOTE_DURING_CALL_P insn.

--- gcc/var-tracking.c.jj   2012-01-30 00:10:01.0 +0100
+++ gcc/var-tracking.c  2012-02-08 16:20:54.808523330 +0100
@@ -8225,9 +8225,14 @@ emit_note_insn_var_location (void **varp
   /* Make sure that the call related notes come first.  */
   while (NEXT_INSN (insn)
 && NOTE_P (insn)
-&& NOTE_DURING_CALL_P (insn))
+&& ((NOTE_KIND (insn) == NOTE_INSN_VAR_LOCATION
+ && NOTE_DURING_CALL_P (insn))
+|| NOTE_KIND (insn) == NOTE_INSN_CALL_ARG_LOCATION))
insn = NEXT_INSN (insn);
-  if (NOTE_P (insn) && NOTE_DURING_CALL_P (insn))
+  if (NOTE_P (insn)
+ && ((NOTE_KIND (insn) == NOTE_INSN_VAR_LOCATION
+  && NOTE_DURING_CALL_P (insn))
+ || NOTE_KIND (insn) == NOTE_INSN_CALL_ARG_LOCATION))
note = emit_note_after (NOTE_INSN_VAR_LOCATION, insn);
   else
note = emit_note_before (NOTE_INSN_VAR_LOCATION, insn);

Jakub

Go patch committed: Build math library with -funsafe-math-optimizations

[Ian Lance Taylor]

The master Go math library uses assembler code on 386 processors to take
advantage of 387 instructions.  This patch lets gccgo do the same thing,
by compiling the math library with -funsafe-math-optimizations.  I also
pass -mfancy-math-387, although that is the default.  It would not be
appropriate to compile all Go code with -funsafe-math-optimizations, of
course, but the math library is designed to handle it.

The compiler currently rewrites calls to, e.g., acos to call acosl
instead when using excess precision.  This also enables the use of
assembler routines on 387.  I tweaked the compiler to only do this when
optimizing, which is probably how it should have been done anyhow.  (At
some point this code will move into the gcc interface out of the
frontend proper.)

With this change the math library no longer refers to functions like
acosl on 386 systems--the operations are done inline using 387
instructions--which should address some portability problems.

Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu (32-bit
and 64-bit mode).  Committed to mainline.

Ian

diff -r 69a7e6220af1 go/expressions.cc
--- a/go/expressions.cc	Tue Feb 07 22:16:02 2012 -0800
+++ b/go/expressions.cc	Wed Feb 08 11:29:04 2012 -0800
@@ -10027,7 +10027,8 @@
 
   // This is to support builtin math functions when using 80387 math.
   tree excess_type = NULL_TREE;
-  if (TREE_CODE(fndecl) == FUNCTION_DECL
+  if (optimize
+  && TREE_CODE(fndecl) == FUNCTION_DECL
   && DECL_IS_BUILTIN(fndecl)
   && DECL_BUILT_IN_CLASS(fndecl) == BUILT_IN_NORMAL
   && nargs > 0
diff -r 69a7e6220af1 libgo/Makefile.am
--- a/libgo/Makefile.am	Tue Feb 07 22:16:02 2012 -0800
+++ b/libgo/Makefile.am	Wed Feb 08 11:29:04 2012 -0800
@@ -1959,7 +1959,9 @@
 math/math.lo.dep: $(go_math_files)
 	$(BUILDDEPS)
 math/math.lo: $(go_math_files)
-	$(BUILDPACKAGE)
+	$(MKDIR_P) $(@D)
+	files=`echo $^ | sed -e 's/[^ ]*\.gox//g'`; \
+	$(LTGOCOMPILE) $(MATH_FLAG) -I . -c -fgo-prefix="libgo_$(@D)" -o $@ $$files
 math/check: $(CHECK_DEPS)
 	@$(CHECK)
 .PHONY: math/check
diff -r 69a7e6220af1 libgo/configure.ac
--- a/libgo/configure.ac	Tue Feb 07 22:16:02 2012 -0800
+++ b/libgo/configure.ac	Wed Feb 08 11:29:04 2012 -0800
@@ -522,6 +522,23 @@
 fi
 AC_SUBST(STRINGOPS_FLAG)
 
+dnl For x86 we want to compile the math library with -mfancy-math-387
+dnl -funsafe-math-optimizations so that we can use the builtin
+dnl instructions directly.
+AC_CACHE_CHECK([whether compiler supports -mfancy-math-387],
+[libgo_cv_c_fancymath],
+[CFLAGS_hold=$CFLAGS
+CFLAGS="$CFLAGS -mfancy-math-387"
+AC_COMPILE_IFELSE([int i;],
+[libgo_cv_c_fancymath=yes],
+[libgo_cv_c_fancymath=no])
+CFLAGS=$CFLAGS_hold])
+MATH_FLAG=
+if test "$libgo_cv_c_fancymath" = yes; then
+  MATH_FLAG="-mfancy-math-387 -funsafe-math-optimizations"
+fi
+AC_SUBST(MATH_FLAG)
+
 CFLAGS_hold=$CFLAGS
 CFLAGS="$CFLAGS -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE"
 AC_CHECK_TYPES([off64_t])

[patch, testsuite, committed] Test case for vectorization PR 32380

[Thomas Koenig]

Hello world,

I committed the attached test case after verifying that it passes and
that only real(4) variables occur (so the requiredment on vect_float
should be correct.)

Thomas

2012-02-08  Thomas Koenig  

PR fortran/32380
* gfortran.dg/vect/pr32380.f90:  New test.
! { dg-do compile }
! { dg-require-effective-target vect_float }
! { dg-options "-O3 -fcray-pointer -ftree-vectorize -fdump-tree-vect-stats" }
! PR 32380 - loops were not vectorized due to unaligned store.
  subroutine trnfbt(e,f,qs,mte,gm,ihgenf,hgener,lft,llt,sthick,
 .  fibl,istupd,ies,hoff)
  parameter (nlq=96)
  integer nnlq
  common/newnlq/nnlq
c   ... implicit common ...
  integer imauto,iteopt,lauto,mthsol,ilimit,maxref,icnvrg,
 & igdiv,nwebuf,neql,neqt,imterm,imphas,nbfgs,
 & numupd,istif,itrlas,imerr,imdof,neqtgl,lsmtd,lsdir
  common/bki01i/imauto,iteopt,lauto,mthsol,ilimit,maxref,icnvrg,
 & igdiv,nwebuf,neql,neqt,imterm,imphas,nbfgs,
 & numupd,istif,itrlas,imerr,imdof,neqtgl,lsmtd,lsdir
  REAL dtimp,dtimp0,timeim,dtmnim,dtmxim,cvtl,ectl,rctl,
 & tolls,dnorm2,dtprnt,dtplot,dtiter,dtrefm
  common/bki01r/dtimp,dtimp0,timeim,dtmnim,dtmxim,cvtl,ectl,rctl,
 & tolls,dnorm2,dtprnt(2),dtplot(2),dtiter(2),dtrefm(2)
  REAL ascntl
  common/bki02r/ascntl(150)
  logical lsensw
  common/bki01l/lsensw(20)
  integer imip,isolvr,icwrb
  common/bki02i/imip(100),isolvr(200),icwrb(50)
c   ... implicit common ...
c
c
c
  integer lnodim,ndofpn,nnpke,melemt,imlft,imllt,is17loc
  common/bki03iloc/lnodim(nlq,16),ndofpn,nnpke,melemt,imlft,imllt,
 & is17loc
  real*4 ske
  common/bki03rloc/ske(nlq,1176)
  integer lmke
  common/bki04iloc/lmke(nlq,48)
c**
c|  livermore software technology corporation  (lstc) |
c|    |
c|  copyright 1987,1988,1989 john o. hallquist, lstc  |
c|  all rights reserved   |
c**
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
c
  common/bk12loc/b12,b2,qhg,qhgm,qhgb,qhgw
  common/aux00loc/
 & sig1m(nlq),sig2m(nlq),sig4m(nlq),sig1n(nlq),sig2n(nlq),
 & sig4n(nlq),sig5n(nlq),sig6n(nlq),sig5l(nlq),sig6l(nlq),
 & str33(nlq),enginc(nlq)
  common/aux01loc/
 &ft11(nlq),ft12(nlq),ft13(nlq),ft21(nlq),ft22(nlq),ft23(nlq),
 &fm11(nlq),fm12(nlq),fm21(nlq),fm22(nlq),
 &fm31(nlq),fm32(nlq),fm41(nlq),fm42(nlq),
 &fmr11(nlq),fmr12(nlq),fmr21(nlq),fmr22(nlq),fmr31(nlq),
 &fmr32(nlq),fmr41(nlq),fmr42(nlq),sg5(nlq),sg6(nlq)
  common/aux7loc/
 1 vx1(nlq),vx2(nlq),vx3(nlq),vx4(nlq),
 2 vx5(nlq),vx6(nlq),vx7(nlq),vx8(nlq),
 3 vy1(nlq),vy2(nlq),vy3(nlq),vy4(nlq),
 4 vy5(nlq),vy6(nlq),vy7(nlq),vy8(nlq),
 5 vz1(nlq),vz2(nlq),vz3(nlq),vz4(nlq),
 6 vz5(nlq),vz6(nlq),vz7(nlq),vz8(nlq)
  common/aux10loc/area(nlq),
 1 px1(nlq),px2(nlq),px3(nlq),px4(nlq),
 & px5(nlq),px6(nlq),px7(nlq),px8(nlq),
 2 py1(nlq),py2(nlq),py3(nlq),py4(nlq),
 & py5(nlq),py6(nlq),py7(nlq),py8(nlq),
 3 pz1(nlq),pz2(nlq),pz3(nlq),pz4(nlq),
 & pz5(nlq),pz6(nlq),pz7(nlq),pz8(nlq),
 4 dx1(nlq),dx2(nlq),dx3(nlq),dx4(nlq),
 5 dx5(nlq),dx6(nlq),dx7(nlq),dx8(nlq),
 6 dy1(nlq),dy2(nlq),dy3(nlq),dy4(nlq),
 7 dy5(nlq),dy6(nlq),dy7(nlq),dy8(nlq),
 8 dz1(nlq),dz2(nlq),dz3(nlq),dz4(nlq),
 9 dz5(nlq),dz6(nlq),dz7(nlq),dz8(nlq)
  common/aux11loc/
 &ft31(nlq),ft32(nlq),ft33(nlq),ft41(nlq),ft42(nlq),ft43(nlq),
 &htx(nlq),hty(nlq),gm1(nlq),gm2(nlq),gm3(nlq),gm4(nlq),
 &bsum(nlq),qhx(nlq),qhy(nlq),qwz(nlq),qtx(nlq),qty(nlq)
  real*4 mx1,my1,mz1,mx2,my2,mz2,mx3,my3,mz3,mx4,my4,mz4
  common/aux13loc/
 &zeta(nlq),thick(nlq),fga(nlq),fgb(nlq),fgc(nlq),
 &gl11(nlq),gl12(nlq),gl13(nlq),gl21(nlq),gl22(nlq),gl23(nlq),
 &gl31(nlq),gl32(nlq),gl33(nlq),
 &x1(nlq),y1(nlq),z1(nlq),x2(nlq),y2(nlq),z2(nlq),
 &x3(nlq),y3(nlq),z3(nlq),x4(nlq),y4(nlq),z4(nlq),
 &fx1(nlq),fy1(nlq),fz1(nlq),fx2(nlq),fy2(nlq),fz2(nlq),
 &fx3(nlq),fy3(nlq),fz3(nlq),fx4(nlq),fy4(nlq),fz4(nlq),
 &mx1(nlq),my1(nlq),mz1(nlq),mx2(nlq),my2(nlq),mz2(nlq),
 &mx3(nlq),my3(nlq),mz3(nlq),mx4(nlq),my4(nlq),mz4(nlq)
  common/aux33loc/
 1 ix1(nlq),ix2(nlq),ix3(nlq),ix4(nlq),ixs(nlq,4),mxt(nlq)
  common/aux35loc/rhoa(nlq),cxx(nlq),fcl(nlq),fcq(nlq)
  common/hourgloc/ymod(nlq),gmod(nlq),ifsv(nlq)
  common/soundloc/sndspd(nlq),sndsp(nlq),diagm(nlq),sarea(nlq),
 . dxl(nlq)
  common/bel6loc/bm(nlq,3,8),bb(nlq,3,8),bs(nlq,2,12),bhg(nlq,4),
 1 ex(nlq,3,8),dp0(nlq,3,3),dp1(nlq,3,3),dp2(nlq,3,3),
 2 ds(nlq),dhg(nlq,5)
c
  common/shlioc/ioshl(60)
  common/failuloc/sieu(nlq),fail(nlq),ifaili(nlq)
  logical output,slnew
  common/csforc/ncs1,ncs2,nc

[PATCH] Re: New atomics not mentioned in /gcc-4.7/changes.html

[Andrew MacLeod]

On 02/08/2012 04:59 AM, Jonathan Wakely wrote:

Should they be?
How's this look for a news item and the changes file?  Formatting seems 
fine.


Is there no changelog for docs?

Andrew


Index: index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.830
diff -c -p -r1.830 index.html
*** index.html  27 Jan 2012 10:54:58 -  1.830
--- index.html  8 Feb 2012 19:58:12 -
*** mission statement.
*** 53,58 
--- 53,68 
  
  
  
+ Atomic memory model support
+ [2011-11-06]
+ C+11/C11 memory model support has been added through a new set of built-in
+ __atomic functions.  These new functions allow a memory model to be specified
+ for an operation and some targets may produce more efficient barriers and 
+ synchronization code.  Generic atomic support has also been added to allow 
+ arbitrary sized data to be treated as atomic, and in turn the C++ atomic
+ class has been updated to allow atomic classes to be any size.
+ 
+ 
  Transactional memory support
  [2011-11-15]
  An implementation of the
Index: gcc-4.7/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v
retrieving revision 1.76
diff -c -p -r1.76 changes.html
*** gcc-4.7/changes.html8 Feb 2012 00:43:12 -   1.76
--- gcc-4.7/changes.html8 Feb 2012 19:58:12 -
*** void foo (char *a, const char *b, const 
*** 223,228 
--- 223,249 
see http://gcc.gnu.org/wiki/TransactionalMemory";>here.
  

+ 
+   
+ 
+   Support for atomic operations specifying the C++11/C11 memory model 
have 
+   been added.  These new __atomic routines replace the existing __sync
+   built-in routines.
+ 
+ 
+   Atomic support is also available for memory blocks.  Lock free
+   instructions will be used if a memory block is the same size and 
+   alignment as a supported integer type.  Atomic operations which do not
+   have lock free support are left as function calls.  A set of library 
+   functions are available on the GCC atomic wiki in the "External 
+   Atomics Library" section.
+ 
+ 
+   For more details on the memory models and features, see the atomic wiki
+   http://gcc.gnu.org/wiki/Atomic/GCCMM";>here.
+ 
+   
+ 
When a binary operation performed on vector types and one of the 
operands
is a uniform vector it is possible to replace the vector with the
generating element. For example:
*** struct A {
*** 330,335 
--- 351,366 
A(): A(42) { } // delegate to the A(int) constructor
  };
  
+   G++ now fully implements C++11 atomic classes rather than just integer 
+ derived classes.
+ 
+ class POD {
+   int a;
+   int b;
+ };
+ std::atomic my_atomic_POD;
+ 
+ 
G++ now sets the predefined macro __cplusplus to the
  correct value, 199711L for C++98/03,
  and 201103L for C++11.

Re: [trans-mem,darwin] PR/52042 find tm_clone_table with PIE

[Mike Stump]

On Feb 7, 2012, at 7:36 PM, Patrick Marlier wrote:
> The problem in this PR is that with PIE, getsectdata does not return the 
> position of tm_clone_table after the relocation.


> If tests passed, ok for 4.7?

Ok.  Thanks for all your hard work.  If you want to change it to include the 
header and delete the declarations in the source, that is pre-approved as well.

>   PR libitm/52042
>* config/darwin-crt-tm.c: Changes for PIE and shared library.

Re: [PATCH] increase timeout in simulate-thread gdb test

[Mike Stump]

On Feb 8, 2012, at 5:11 AM, Andrew MacLeod wrote:
> On 02/07/2012 07:55 PM, Mike Stump wrote:
>> On Dec 7, 2011, at 10:43 AM, Jack Howarth wrote:
>>> Currently we are failing...
>>> 
>>> FAIL: gcc.dg/simulate-thread/atomic-load-int128.c  -O1 -g  thread 
>>> simulation test
>>> FAIL: gcc.dg/simulate-thread/atomic-load-int128.c  -O2 -g  thread 
>>> simulation test
>>> FAIL: gcc.dg/simulate-thread/atomic-load-int128.c  -O3 -g  thread 
>>> simulation test
>>> FAIL: gcc.dg/simulate-thread/atomic-load-int128.c  -Os -g  thread 
>>> simulation test
>>> 
>>> on x86_64-apple-darwin11 due to the 10 second timeout in simulate-thread of
>>> gcc/testsuite/lib/gcc-simulate-thread.exp. Increasing this timeout to 20 
>>> seconds
>>> eliminates the failures (as these test take ~16 seconds on 
>>> x86_64-apple-darwin11).
>>> Okay for gcc trunk?
>> Ok.  Ok for 4.7.
> And I just recently noticed armv7 was failing *all* the simulate-thread tests 
> for the same reason.  20 seconds appears to make it pass all tests there as 
> well.

In the context of recent, reasonably fast machine, no timeout should be within 
10x of failing because of the timeout.  Having a 20 second timeout, when 18 are 
required, means failures, if you merely have 2 test suites running at the same 
time.  If it takes 18 seconds, the timeout should be 180 seconds, minimum.  :-( 
 I'd welcome a simulate threads person re-engineering what the numbers should 
be.

> On a different note, shouldn't these time out's be reported as UNRESOLVED 
> rather than fails?  Seems like the framework isn't reporting properly.

No.  An infinite loop is failure.  The timeouts are not supported to be close.

Re: [PATCH] increase timeout in simulate-thread gdb test

[Mike Stump]

On Feb 8, 2012, at 8:02 AM, Andrew MacLeod wrote:
> Presuming that it runs properly, is this OK for mainline?

Ok.

Re: Ping: Re: [patch middle-end]: Fix PR/48814 - [4.4/4.5/4.6/4.7 Regression] Incorrect scalar increment result

[Kai Tietz]

2012/1/11 Richard Guenther :
>
> count despite being declared volatile and only loaded once in the source
> is loaded twice in gimple.  If it were a HW register which destroys the
> device after the 2nd load without an intervening store you'd wrecked
> the device ;)
>
> Richard.

Thanks for explaination.  I tried to flip order for lhs/rhs in
gimplify_modify_expr & co.  Issue here is that for some cases we are
relying here on lhs for gimplifying rhs (is_gimple_reg_rhs_or_call vs
is_gimple_mem_rhs_or_call) and this doesn't work for cases in C++
like:

typedef const unsigned char _Jv_Utf8Const;
typedef __SIZE_TYPE__ uaddr;

void maybe_adjust_signature (_Jv_Utf8Const *&s, uaddr &special)
{
  union {
_Jv_Utf8Const *signature;
uaddr signature_bits;
  };
  signature = s;
  special = signature_bits & 1;
  signature_bits -= special;
  s = signature;
}

So I modified gimplify_self_mod_expr for post-inc/dec so that we use
following sequence
and add it to pre_p for it:

tmp = lhs;
lvalue = tmp (+/-) rhs
*expr_p = tmp;

ChangeLog

2012-02-08  Kai Tietz  

PR middle-end/48814
* gimplify.c (gimplify_self_mod_expr): Move for
postfix-inc/dec the modification in pre and return
temporary with origin value.

2012-02-08  Kai Tietz  

* gcc.c-torture/execute/pr48814-1.c: New test.
* gcc.c-torture/execute/pr48814-2.c: New test.
* gcc.dg/tree-ssa/assign-1.c: New test.
* gcc.dg/tree-ssa/assign-2.c: New test.

I did boostrap for all languages (including Ada and Obj-C++) and
regression tests on host x86_64-unknown-linux-gnu.  Ok for apply?

Regards,
Kai

Index: gcc/gcc/gimplify.c
===
--- gcc.orig/gcc/gimplify.c
+++ gcc/gcc/gimplify.c
@@ -2197,7 +2197,7 @@ gimplify_self_mod_expr (tree *expr_p, gi
bool want_value)
 {
   enum tree_code code;
-  tree lhs, lvalue, rhs, t1;
+  tree lhs, lvalue, rhs, t1, t2;
   gimple_seq post = NULL, *orig_post_p = post_p;
   bool postfix;
   enum tree_code arith_code;
@@ -2264,20 +2264,23 @@ gimplify_self_mod_expr (tree *expr_p, gi
   arith_code = POINTER_PLUS_EXPR;
 }

-  t1 = build2 (arith_code, TREE_TYPE (*expr_p), lhs, rhs);
-
-  if (postfix)
-{
-  gimplify_assign (lvalue, t1, orig_post_p);
-  gimplify_seq_add_seq (orig_post_p, post);
-  *expr_p = lhs;
-  return GS_ALL_DONE;
-}
-  else
+  if (!postfix)
 {
+  t1 = build2 (arith_code, TREE_TYPE (*expr_p), lhs, rhs);
   *expr_p = build2 (MODIFY_EXPR, TREE_TYPE (lvalue), lvalue, t1);
   return GS_OK;
 }
+
+  /* Assign lhs to temporary variable.  */
+  t2 = create_tmp_var (TREE_TYPE (lhs), NULL);
+  gimplify_assign (t2, lhs, pre_p);
+  /* Do increment and assign it to lvalue.  */
+  t1 = build2 (arith_code, TREE_TYPE (*expr_p), t2, rhs);
+  gimplify_assign (lvalue, t1, pre_p);
+
+  gimplify_seq_add_seq (orig_post_p, post);
+  *expr_p = t2;
+  return GS_ALL_DONE;
 }

 /* If *EXPR_P has a variable sized type, wrap it in a WITH_SIZE_EXPR.  */
Index: gcc/gcc/testsuite/gcc.c-torture/execute/pr48814-1.c
===
--- /dev/null
+++ gcc/gcc/testsuite/gcc.c-torture/execute/pr48814-1.c
@@ -0,0 +1,18 @@
+extern void abort (void);
+
+int arr[] = {1,2,3,4};
+int count = 0;
+
+int __attribute__((noinline))
+incr (void)
+{
+  return ++count;
+}
+
+int main()
+{
+  arr[count++] = incr ();
+  if (count != 2 || arr[count] != 3)
+abort ();
+  return 0;
+}
Index: gcc/gcc/testsuite/gcc.c-torture/execute/pr48814-2.c
===
--- /dev/null
+++ gcc/gcc/testsuite/gcc.c-torture/execute/pr48814-2.c
@@ -0,0 +1,18 @@
+extern void abort (void);
+
+int arr[] = {1,2,3,4};
+int count = 0;
+
+int
+incr (void)
+{
+  return ++count;
+}
+
+int main()
+{
+  arr[count++] = incr ();
+  if (count != 2 || arr[count] != 3)
+abort ();
+  return 0;
+}
Index: gcc/gcc/testsuite/gcc.dg/tree-ssa/assign-1.c
===
--- /dev/null
+++ gcc/gcc/testsuite/gcc.dg/tree-ssa/assign-1.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+
+volatile int count;
+void bar(int);
+void foo()
+{
+ bar(count++);
+}
+
+/* { dg-final { scan-tree-dump-times "count =" 1 "optimized"} } */
+/* { dg-final { cleanup-tree-dump "optimized" } } */
Index: gcc/gcc/testsuite/gcc.dg/tree-ssa/assign-2.c
===
--- /dev/null
+++ gcc/gcc/testsuite/gcc.dg/tree-ssa/assign-2.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+
+volatile int count;
+int arr[4];
+void foo()
+{
+ arr[count++] = 0;
+}
+
+/* { dg-final { scan-tree-dump-times "count =" 1 "optimized"} } */
+/* { dg-final { cleanup-tree-dump "optimized" } } */
+

Re: [PATCH] Re: New atomics not mentioned in /gcc-4.7/changes.html

[Jonathan Wakely]

On 08/02/2012, Andrew MacLeod wrote:
> On 02/08/2012 04:59 AM, Jonathan Wakely wrote:
>> Should they be?
> How's this look for a news item and the changes file?  Formatting seems
> fine.

 The news item is missing a + in C++

It's not critical for the changes.html page since it's not likely to
be printed, but it's better hyperlink style to say "see the [atomic
wiki]" rather than "see the atomic wiki [here]"


> Is there no changelog for docs?

Not for wwwdocs, no.

Re: [PATCH] increase timeout in simulate-thread gdb test

[Andrew MacLeod]

On 02/08/2012 04:22 PM, Mike Stump wrote:

On Feb 8, 2012, at 5:11 AM, Andrew MacLeod wrote:

On 02/07/2012 07:55 PM, Mike Stump wrote:

On Dec 7, 2011, at 10:43 AM, Jack Howarth wrote:

Currently we are failing...

FAIL: gcc.dg/simulate-thread/atomic-load-int128.c  -O1 -g  thread simulation 
test
FAIL: gcc.dg/simulate-thread/atomic-load-int128.c  -O2 -g  thread simulation 
test
FAIL: gcc.dg/simulate-thread/atomic-load-int128.c  -O3 -g  thread simulation 
test
FAIL: gcc.dg/simulate-thread/atomic-load-int128.c  -Os -g  thread simulation 
test

on x86_64-apple-darwin11 due to the 10 second timeout in simulate-thread of
gcc/testsuite/lib/gcc-simulate-thread.exp. Increasing this timeout to 20 seconds
eliminates the failures (as these test take ~16 seconds on 
x86_64-apple-darwin11).
Okay for gcc trunk?

Ok.  Ok for 4.7.

And I just recently noticed armv7 was failing *all* the simulate-thread tests 
for the same reason.  20 seconds appears to make it pass all tests there as 
well.

In the context of recent, reasonably fast machine, no timeout should be within 
10x of failing because of the timeout.  Having a 20 second timeout, when 18 are 
required, means failures, if you merely have 2 test suites running at the same 
time.  If it takes 18 seconds, the timeout should be 180 seconds, minimum.  :-( 
 I'd welcome a simulate threads person re-engineering what the numbers should 
be.
well, originally there wasn't a special number.  Someone added the 10 
seconds because most of the testcases are short, and they generated  a 
*lot* of log. If an infinite loop did happen (which it did), the 300 
second timeout could generate a huge log file that fills the 
filesystem.  I think there was a defect for that...  Anyway, I think 10 
seconds just came out of someones imagination, but I'm not sure.  Was 
that you Aldy?


Given thats the case, I'd be more tempted long term to simply disable 
the line by line output into the log file...  I assume thats possible. 
then we dont need any special time outs.  If a failure needs 
investigation, you look at it by hand.


Andrew

Re: [PATCH] PR48524 spec language does not cover switches with separated form

[Joseph S. Myers]

On Tue, 20 Dec 2011, Magnus Granberg wrote:

> Hi
> 
> This patch make -D and -U work in the spec language, bug pr48524.
> Tested on x86_64-unknown-linux-gnu snapshot 4.7-20111217

Thanks.  I've fixed up the whitespace and the ChangeLog entry formatting 
and applied this patch now the copyright assignment is in.

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

Re: [patch boehm-gc]: Fix PR/48514

[Kai Tietz]

Ping

2012/2/2 Kai Tietz :
> Hello,
>
> this patch fixes an issue about current used boehm-gc tree in gcc.
> The issue is that _DLL macro is used for Windows-targets wrong.  It is
> assumed that it would mean to build a shared object (DLL), but it just
> indicates that built DLL/Exectuable is using shared msvcrt.dll
> runtime.  (see here msdn about meaning for _DLL macro).
>
> ChangeLog
>
>        * include/gc_config_macros.h (GC_DLL): Define it for
> mingw-targets only, if
>        we are actual in boehm-gc's build and DLL_EXPORT macro is defined.
>
> Tested for i686-w64-mingw32, i686-pc-mingw32, and x86_64-w64-mingw32
> (including building of libjava with test).  Ok for apply?
>
> Regards,
> Kai
>
> Index: include/gc_config_macros.h
> ===
> --- include/gc_config_macros.h  (revision 183833)
> +++ include/gc_config_macros.h  (working copy)
> @@ -81,7 +81,9 @@
>     typedef long ptrdiff_t;    /* ptrdiff_t is not defined */
>  # endif
>
> -#if defined(_DLL) && !defined(GC_NOT_DLL) && !defined(GC_DLL)
> +#if ((defined(_DLL) && !defined (__MINGW32__)) \
> +     || (defined (DLL_EXPORT) && defined (GC_BUILD))) \
> +    && !defined(GC_DLL)
>  # define GC_DLL
>  #endif



-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

Re: [PATCH] Re: New atomics not mentioned in /gcc-4.7/changes.html

[Andrew MacLeod]

On 02/08/2012 04:30 PM, Jonathan Wakely wrote:

On 08/02/2012, Andrew MacLeod wrote:

On 02/08/2012 04:59 AM, Jonathan Wakely wrote:

Should they be?

How's this look for a news item and the changes file?  Formatting seems
fine.

  The news item is missing a + in C++

It's not critical for the changes.html page since it's not likely to
be printed, but it's better hyperlink style to say "see the [atomic
wiki]" rather than "see the atomic wiki [here]"

That's what I get for following the same pattern as those TM jokers.

OK, hows this look?  I added a link in the news as well.

Andrew
? K
? gcc-4.7/K
Index: index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.830
diff -c -p -r1.830 index.html
*** index.html  27 Jan 2012 10:54:58 -  1.830
--- index.html  8 Feb 2012 21:48:05 -
*** mission statement.
*** 53,58 
--- 53,69 
  
  
  
+ Atomic memory model support
+ [2011-11-06]
+ C++11/C11 http://gcc.gnu.org/wiki/Atomic/GCCMM";>memory model
+ support has been added through a new set of built-in __atomic functions.
+ These new functions allow a memory model to be specified for an 
+ operation and some targets may produce more efficient barriers and 
+ synchronization code.  Generic atomic support has also been added to allow 
+ arbitrary sized data to be treated as atomic, and in turn the C++ atomic
+ class has been updated to allow atomic classes to be any size.
+ 
+ 
  Transactional memory support
  [2011-11-15]
  An implementation of the
Index: gcc-4.7/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v
retrieving revision 1.76
diff -c -p -r1.76 changes.html
*** gcc-4.7/changes.html8 Feb 2012 00:43:12 -   1.76
--- gcc-4.7/changes.html8 Feb 2012 21:48:05 -
*** void foo (char *a, const char *b, const 
*** 223,228 
--- 223,249 
see http://gcc.gnu.org/wiki/TransactionalMemory";>here.
  

+ 
+   
+ 
+   Support for atomic operations specifying the C++11/C11 memory model 
have 
+   been added.  These new __atomic routines replace the existing __sync
+   built-in routines.
+ 
+ 
+   Atomic support is also available for memory blocks.  Lock free
+   instructions will be used if a memory block is the same size and 
+   alignment as a supported integer type.  Atomic operations which do not
+   have lock free support are left as function calls.  A set of library 
+   functions are available on the GCC atomic wiki in the "External 
+   Atomics Library" section.
+ 
+ 
+   For more details on the memory models and features, see the 
+   http://gcc.gnu.org/wiki/Atomic/GCCMM";>atomic wiki.
+ 
+   
+ 
When a binary operation performed on vector types and one of the 
operands
is a uniform vector it is possible to replace the vector with the
generating element. For example:
*** struct A {
*** 330,335 
--- 351,366 
A(): A(42) { } // delegate to the A(int) constructor
  };
  
+   G++ now fully implements C++11 atomic classes rather than just integer 
+ derived classes.
+ 
+ class POD {
+   int a;
+   int b;
+ };
+ std::atomic my_atomic_POD;
+ 
+ 
G++ now sets the predefined macro __cplusplus to the
  correct value, 199711L for C++98/03,
  and 201103L for C++11.

[patch libffi]: Enable build for DLL version for x64 windows targets

[Kai Tietz]

Hi,

the following patch enables DLL build for x64 windows target.

ChangeLog

2012-02-08  Kai Tietz  

  * configure.ac (AM_LTLDFLAGS): Add -no-undefine for x64
windows target.
  * configure: Regenerated

Tested for x86_64-w64-mingw32.  Ok for apply?

Regards,
Kai

Index: configure.ac
===
--- configure.ac(revision 184020)
+++ configure.ac(working copy)
@@ -166,6 +166,15 @@

   x86_64-*-cygwin* | x86_64-*-mingw*)
TARGET=X86_WIN64; TARGETDIR=x86
+   # All mingw/cygwin/win32 builds require -no-undefined for sharedlib.
+   # We must also check with_cross_host to decide if this is a native
+   # or cross-build and select where to install dlls appropriately.
+   if test -n "$with_cross_host" &&
+  test x"$with_cross_host" != x"no"; then
+ AM_LTLDFLAGS='-no-undefined -bindir "$(toolexeclibdir)"';
+   else
+ AM_LTLDFLAGS='-no-undefined -bindir "$(bindir)"';
+   fi
;;

   x86_64-*-*)

libgo patch committed: Fix typo in //extern comment

[Ian Lance Taylor]

This patch fixes a typo in an //extern comment.  Bootstrapped and ran Go
testsuite on x86_64-unknown-linux-gnu.  Committed to mainline.

Ian

diff -r 419efb0adfa7 libgo/go/os/dir_regfile.go
--- a/libgo/go/os/dir_regfile.go	Wed Feb 08 11:30:14 2012 -0800
+++ b/libgo/go/os/dir_regfile.go	Wed Feb 08 14:19:55 2012 -0800
@@ -9,5 +9,5 @@
 
 import "syscall"
 
-// extern readdir_r
+//extern readdir_r
 func libc_readdir_r(*syscall.DIR, *syscall.Dirent, **syscall.Dirent) syscall.Errno

Go patch committed: Provide matherr function

[Ian Lance Taylor]

On SVID-based systems, when certain math functions encounter an
exceptional condition they call a magic function named matherr.  That
function is permitted to change the result which the math functions will
return.  a program is permitted to provide its own version of matherr.

Solaris works this way and at least the Solaris version of matherr does
not act as Go, or an ordinary interpretation of the function, would
expect.  E.g., calling acos on an out-of-range value will return 0
rather than NaN.

This patch defines a version of matherr in the Go library to ensure that
the Go math routines behaves as one would normally expect.  This could
potentially be a problem in a mixed C/Go program for which the C part
needs to use its own definition of matherr.  Ordinarily I would expect
the C version to take precedence, in which case the Go functions may
misbehave slightly in exceptional conditions.  I don't consider this to
be a likely scenario.

Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu and
i386-pc-solaris2.11.  Committed to mainline.

Ian

diff -r 596217515a77 libgo/Makefile.am
--- a/libgo/Makefile.am	Wed Feb 08 14:20:19 2012 -0800
+++ b/libgo/Makefile.am	Wed Feb 08 14:22:22 2012 -0800
@@ -422,6 +422,7 @@
 	runtime/go-map-index.c \
 	runtime/go-map-len.c \
 	runtime/go-map-range.c \
+	runtime/go-matherr.c \
 	runtime/go-nanotime.c \
 	runtime/go-now.c \
 	runtime/go-new-map.c \
diff -r 596217515a77 libgo/configure.ac
--- a/libgo/configure.ac	Wed Feb 08 14:20:19 2012 -0800
+++ b/libgo/configure.ac	Wed Feb 08 14:22:22 2012 -0800
@@ -478,6 +478,11 @@
 CFLAGS="$CFLAGS_hold"
 LIBS="$LIBS_hold"
 
+LIBS_hold="$LIBS"
+LIBS="$LIBS $MATH_LIBS"
+AC_CHECK_FUNCS(matherr)
+LIBS="$LIBS_hold"
+
 AC_CACHE_CHECK([for __sync_bool_compare_and_swap_4],
 [libgo_cv_func___sync_bool_compare_and_swap_4],
 [AC_LINK_IFELSE([
@@ -566,6 +571,16 @@
 STRUCT_EPOLL_EVENT_FD_OFFSET=${libgo_cv_c_epoll_event_fd_offset}
 AC_SUBST(STRUCT_EPOLL_EVENT_FD_OFFSET)
 
+dnl See if struct exception is defined in .
+AC_CHECK_TYPE([struct exception],
+[libgo_has_struct_exception=yes],
+[libgo_has_struct_exception=no],
+[#include ])
+if test "$libgo_has_struct_exception" = "yes"; then
+  AC_DEFINE(HAVE_STRUCT_EXCEPTION, 1,
+[Define to 1 if  defines struct exception])
+fi
+
 dnl See whether setcontext changes the value of TLS variables.
 AC_CACHE_CHECK([whether setcontext clobbers TLS variables],
 [libgo_cv_lib_setcontext_clobbers_tls],
diff -r 596217515a77 libgo/runtime/go-matherr.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +
+++ b/libgo/runtime/go-matherr.c	Wed Feb 08 14:22:22 2012 -0800
@@ -0,0 +1,88 @@
+/* go-matherr.c -- a Go version of the matherr function.
+
+   Copyright 2012 The Go Authors. All rights reserved.
+   Use of this source code is governed by a BSD-style
+   license that can be found in the LICENSE file.  */
+
+/* The gccgo version of the math library calls libc functions.  On
+   some systems, such as Solaris, those functions will call matherr on
+   exceptional conditions.  This is a version of matherr appropriate
+   for Go, one which returns the values that the Go math library
+   expects.  This is fine for pure Go programs.  For mixed Go and C
+   programs this will be problematic if the C programs themselves use
+   matherr.  Normally the C version of matherr will override this, and
+   the Go code will just have to cope.  If this turns out to be too
+   problematic we can change to run pure Go code in the math library
+   on systems that use matherr.  */
+
+#include 
+#include 
+
+#include "config.h"
+
+#if defined(HAVE_MATHERR) && defined(HAVE_STRUCT_EXCEPTION)
+
+#define PI 3.14159265358979323846264338327950288419716939937510582097494459
+
+int
+matherr (struct exception* e)
+{
+  const char *n;
+
+  if (e->type != DOMAIN)
+return 0;
+
+  n = e->name;
+  if (__builtin_strcmp (n, "acos") == 0
+  || __builtin_strcmp (n, "asin") == 0)
+e->retval = NAN;
+  else if (__builtin_strcmp (n, "atan2") == 0)
+{
+  if (e->arg1 == 0 && e->arg2 == 0)
+	{
+	  double nz;
+
+	  nz = -0.0;
+	  if (__builtin_memcmp (&e->arg2, &nz, sizeof (double)) != 0)
+	e->retval = e->arg1;
+	  else
+	e->retval = copysign (PI, e->arg1);
+	}
+  else
+	return 0;
+}
+  else if (__builtin_strcmp (n, "log") == 0
+	   || __builtin_strcmp (n, "log10") == 0)
+e->retval = NAN;
+  else if (__builtin_strcmp (n, "pow") == 0)
+{
+  if (e->arg1 < 0)
+	e->retval = NAN;
+  else if (e->arg1 == 0 && e->arg2 == 0)
+	e->retval = 1.0;
+  else if (e->arg1 == 0 && e->arg2 < 0)
+	{
+	  double i;
+
+	  if (modf (e->arg2, &i) == 0 && ((int64_t) i & 1) == 1)
+	e->retval = copysign (INFINITY, e->arg1);
+	  else
+	e->retval = INFINITY;
+	}
+  else
+	return 0;
+}
+  else if (__builtin_strcmp (n, "sqrt") == 0)
+{
+  if (e->arg1 < 0)
+	e->retval = NAN;
+  else
+	return 0;
+}
+  else
+return 0;
+
+  return 1;
+}
+
+#endif

Re: [PATCH] Re: New atomics not mentioned in /gcc-4.7/changes.html

[Jonathan Wakely]

On 8 February 2012 21:49, Andrew MacLeod wrote:
> That's what I get for following the same pattern as those TM jokers.

Heh :)

> OK, hows this look?  I added a link in the news as well.

Looks great to me.

New German PO file for 'gcc' (version 4.7-b20120128)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the German team of translators.  The file is available at:

http://translationproject.org/latest/gcc/de.po

(This file, 'gcc-4.7-b20120128.de.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

http://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: [PATCH] Use relayout_decl instead of layout_decl when completing vars with incomplete types (PR c/51339)

[Ulrich Weigand]

Joseph S. Myers wrote:
> On Mon, 5 Dec 2011, Jakub Jelinek wrote:
> 
> > 2011-12-05  Jakub Jelinek  
> > 
> > PR c/51339
> > * c-decl.c (c_finish_incomplete_decl, finish_decl): Call
> > relayout_decl instead of layout_decl.
> > 
> > * gcc.dg/gomp/pr51339.c: New test.
> 
> OK.

The finish_decl change appears to have introduced a regression
in attribute ((aligned)) handling.  With the following code:

extern const int foo[];
const int __attribute__((aligned(16))) foo[] = { 0 };

the attribute now seems to be ignored; reverting the change
above causes the attribute to be honored again.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  ulrich.weig...@de.ibm.com

Re: [PATCH] Re: New atomics not mentioned in /gcc-4.7/changes.html

[Gerald Pfeifer]

Hi Andrew,

On Wed, 8 Feb 2012, Andrew MacLeod wrote:

OK, hows this look?  I added a link in the news as well.


Index: index.html
===
+ Atomic memory model support
+ [2011-11-06]
+ C++11/C11 http://gcc.gnu.org/wiki/Atomic/GCCMM";>memory model
+ support has been added through a new set of built-in __atomic functions.
+ These new functions allow a memory model to be specified for an 
+ operation and some targets may produce more efficient barriers and 
+ synchronization code.  Generic atomic support has also been added to allow 
+ arbitrary sized data to be treated as atomic, and in turn the C++ atomic

+ class has been updated to allow atomic classes to be any size.
+ 

This news item on the main page is quite long if you compare it with the 
others and probably fills most of that column on page 1; could you cut 
this signficantly and instead link to the gcc-4.7/changes.html and have

some of the good general background there?

Also, wouldn't you want to name who has contributed that?  (See some
old items for a couple of examples.)  That is purely optional, I think
it's kinda nice, though, and your employer might appreciate it, too. :-)

Index: gcc-4.7/changes.html
===
+   Support for atomic operations specifying the C++11/C11 memory model have 
+   been added.  These new __atomic routines replace the existing __sync

+   built-in routines.

Would that be __atomic and __sync 



Nice stuff!

Gerald

Re: [PATCH] Re: New atomics not mentioned in /gcc-4.7/changes.html

[Andrew MacLeod]

On 02/08/2012 06:19 PM, Gerald Pfeifer wrote:


This news item on the main page is quite long if you compare it with 
the others and probably fills most of that column on page 1; could you 
cut this signficantly and instead link to the gcc-4.7/changes.html and 
have

some of the good general background there?


Checked in the shortened version and  changes.  How thats?  seems 
better :-)


Andrew

[v3] Update C++11 status table.

[Jonathan Wakely]

* doc/xml/manual/status_cxx2011.xml: Update C++11 status table.

Committed to trunk.
commit 4e7bd98694de0aa098bd68ca0122bad65ca7d7a8
Author: Jonathan Wakely 
Date:   Wed Feb 8 23:46:22 2012 +

* doc/xml/manual/status_cxx2011.xml: Update C++11 status table.

diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2011.xml 
b/libstdc++-v3/doc/xml/manual/status_cxx2011.xml
index 1f39ce5..0ed63ea 100644
--- a/libstdc++-v3/doc/xml/manual/status_cxx2011.xml
+++ b/libstdc++-v3/doc/xml/manual/status_cxx2011.xml
@@ -384,12 +384,10 @@ particular release.
   
 
 
-  
   20.3.2
   Class template pair
-  Partial
-  Piecewise construction requires an accessible copy/move
- constructor.
+  Y
+  
 
 
   20.3.3
@@ -530,11 +528,10 @@ particular release.
   
 
 
-  
   20.6.3
   Pointer traits
-  Partial
-  Missing rebind
+  Y
+  
 
 
   
@@ -563,11 +560,10 @@ particular release.
   
 
 
-  
   20.6.8
   Allocator traits
-  Partial
-  Missing rebind_alloc and rebind_traits
+  Y
+  
 
 
   20.6.9
@@ -992,11 +988,10 @@ particular release.
   
 
 
-  
   20.11.7.2
   Class steady_clock
-  N
-  Support old monotonic_clock spec instead
+  Y
+  
 
 
   20.11.7.3
@@ -1125,11 +1120,10 @@ particular release.
   
 
 
-  
   21.4
   Class template basic_string
-  Partial
-  Missing pop_back
+  Y
+  
 
 
   21.5
@@ -2287,28 +2281,23 @@ particular release.
   
 
 
-  
+  
   29.3
   Order and consistency
-  N
+  Partial
   
 
 
-  
   29.4
   Lock-free property
-  Partial
-  Missing ATOMIC_BOOL_LOCK_FREE and
-ATOMIC_POINTER_LOCK_FREE.
-Based on _GLIBCXX_ATOMIC_PROPERTY
-  
+  Y
+  
 
 
-  
   29.5
   Atomic types
-  Partial
-  Missing constexpr
+  Y
+  
 
 
   29.6
@@ -2526,14 +2515,14 @@ particular release.
   30.6.6
   Class template future
   Partial
-  Timed waiting functions do not return future_status
+  Timed waiting functions do not return 
future_status::deferred
 
 
   
   30.6.7
   Class template shared_future
   Partial
-  Timed waiting functions do not return future_status
+  Timed waiting functions do not return 
future_status::deferred
 
 
   30.6.8

Re: [v3] Update C++11 status table.

[Jonathan Wakely]

* doc/xml/manual/documentation_hacking.xml: Fix invalid attribute.

Also committed to trunk. Tested with 'make doc-xml-validate-docbook doc-html'
commit 3947c1646119ea4319a57cd401f1736ff5cd76f2
Author: Jonathan Wakely 
Date:   Wed Feb 8 23:57:04 2012 +

* doc/xml/manual/documentation_hacking.xml: Fix invalid attribute.

diff --git a/libstdc++-v3/doc/xml/manual/documentation_hacking.xml 
b/libstdc++-v3/doc/xml/manual/documentation_hacking.xml
index b9830a0..e74f2b7 100644
--- a/libstdc++-v3/doc/xml/manual/documentation_hacking.xml
+++ b/libstdc++-v3/doc/xml/manual/documentation_hacking.xml
@@ -693,7 +693,7 @@
   
 
   
-   For epub output, the http://www.w3.org/1999/xlink"; 
xmlns:href="http://sourceforge.net/projects/docbook/files/epub3/";>stylesheets
 for EPUB3 are required. These stylesheets are still in development. To 
validate the created file, http://www.w3.org/1999/xlink"; 
xmlns:href="https://code.google.com/p/epubcheck/";>epubcheck is necessary.
+   For epub output, the http://www.w3.org/1999/xlink"; 
xlink:href="http://sourceforge.net/projects/docbook/files/epub3/";>stylesheets
 for EPUB3 are required. These stylesheets are still in development. To 
validate the created file, http://www.w3.org/1999/xlink"; 
xlink:href="https://code.google.com/p/epubcheck/";>epubcheck is necessary.
   
 
 

Re: [trans-mem,darwin] PR/52042 find tm_clone_table with PIE

[Patrick Marlier]

On 02/08/2012 04:14 PM, Mike Stump wrote:

On Feb 7, 2012, at 7:36 PM, Patrick Marlier wrote:

The problem in this PR is that with PIE, getsectdata does not return the 
position of tm_clone_table after the relocation.




If tests passed, ok for 4.7?


Ok.  Thanks for all your hard work.  If you want to change it to include the 
header and delete the declarations in the source, that is pre-approved as well.


Ok. done.
Minor modifications:
* New function to avoid duplicated code
* Add gcc_assert if _dyld_get_image_header_containing_address function fails
* Leave early if no tm_clone_table or no clone.

How does it look like now?

Patrick.

PS: May I ask someone to commit on my behalf? I have filled the FSF 
paperwork but I did not have an account yet. Thanks in advance!




PR libitm/52042
* config/darwin-crt-tm.c: Changes for PIE and shared library.


Index: config/darwin-crt-tm.c
===
--- config/darwin-crt-tm.c	(revision 183968)
+++ config/darwin-crt-tm.c	(working copy)
@@ -23,33 +23,62 @@ a copy of the GCC Runtime Library Exception along
 see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 .  */
 
+#include "tsystem.h"
 #include 
+#include 
 
-/* not listed in mach-o/dyld.h for some reason.  */
-extern char * getsectdata (const char*,const char*,unsigned long*); 
+#ifdef __LP64__
+#define GET_DATA_TMCT(mh,size) \
+  getsectdatafromheader_64 ((struct mach_header_64*) mh, \
+			"__DATA", "__tm_clone_table", (uint64_t *)size)
+#else
+#define GET_DATA_TMCT(mh,size) \
+  getsectdatafromheader (mh, "__DATA", "__tm_clone_table", (uint32_t *)size)
+#endif
 
 #define WEAK __attribute__((weak))
 
 extern void _ITM_registerTMCloneTable (void *, size_t) WEAK;
 extern void _ITM_deregisterTMCloneTable (void *) WEAK;
 
+#if defined(START) || defined(END)
+static inline void *getTMCloneTable (const void *f, size_t *tmct_siz)
+{
+  char *tmct_fixed, *tmct = NULL;
+  unsigned int i, img_count; 
+  struct mach_header *mh;
+  
+  mh = _dyld_get_image_header_containing_address (f);
+  gcc_assert (mh);
+  tmct_fixed = GET_DATA_TMCT (mh, tmct_siz);
+  *tmct_siz /= (sizeof (size_t) * 2);
+  /* No tm_clone_table or no clones. */
+  if (tmct_fixed == NULL || *tmct_siz == 0)
+return NULL; 
+
+  img_count = _dyld_image_count();
+  for (i = 0; i < img_count && tmct == NULL; i++)
+{
+  if (mh == _dyld_get_image_header(i))
+	tmct = tmct_fixed + (unsigned long)_dyld_get_image_vmaddr_slide(i); 
+}
+
+  return tmct;
+}
+#endif
+
 #ifdef START
 
 void __doTMRegistrations (void) __attribute__ ((constructor));
 
 void __doTMRegistrations (void)
 {
-  char * tm_clone_table_sect_data;
-  unsigned long tmct_siz;
-  
-  tm_clone_table_sect_data = getsectdata ("__DATA",
-	  "__tm_clone_table",
-	  &tmct_siz);
-  tmct_siz /= (sizeof (size_t) * 2);
-  if (_ITM_registerTMCloneTable != NULL
-  && tm_clone_table_sect_data != NULL
-  && tmct_siz > 0)
-_ITM_registerTMCloneTable (tm_clone_table_sect_data, (size_t)tmct_siz);
+  size_t tmct_siz;
+  void *tmct;
+
+  tmct = getTMCloneTable ((const void *)&__doTMRegistrations, &tmct_siz);
+  if (_ITM_registerTMCloneTable != NULL && tmct != NULL)
+_ITM_registerTMCloneTable (tmct, (size_t)tmct_siz);
 }
 
 #endif
@@ -60,18 +89,12 @@ void __doTMdeRegistrations (void) __attribute__ ((
 
 void __doTMdeRegistrations (void)
 {
-  char * tm_clone_table_sect_data;
-  unsigned long tmct_siz;
-  
-  tm_clone_table_sect_data = getsectdata ("__DATA",
-	  "__tm_clone_table",
-	  &tmct_siz);
-  
-  if (_ITM_deregisterTMCloneTable != NULL
-  && tm_clone_table_sect_data != NULL
-  && tmct_siz > 0)
-_ITM_deregisterTMCloneTable (tm_clone_table_sect_data);
+  size_t tmct_siz;
+  void *tmct;
 
+  tmct = getTMCloneTable ((const void *)&__doTMdeRegistrations, &tmct_siz);
+  if (_ITM_deregisterTMCloneTable != NULL && tmct != NULL)
+_ITM_deregisterTMCloneTable (tmct);
 }
 
 #endif

[PATCH] Fix PR middle-end/52140, ICE on valid code

[Peter Bergner]

The following patch fixes an ICE when we try and generate a compare of
decimal float variables when we are not compiling for a cpu with dfp
hardware support.  This is a regression from gcc 4.4.  The patch below
bootstrapped and regression tested with no regressions on trunk, 4.6
and 4.5.  Is this ok everywhere?

I'll note that there seem to be a few other places that need this change,
but they aren't needed to fix this ICE, so I left them for a 4.8. cleanup.

Peter


gcc/
PR middle-end/52140
* dojump.c (do_compare_rtx_and_jump): Use SCALAR_FLOAT_MODE_P.

gcc/testsuite/
PR middle-end/52140
* gcc.dg/dfp/pr52140.c: New test.

Index: gcc/dojump.c
===
--- gcc/dojump.c(revision 184032)
+++ gcc/dojump.c(working copy)
@@ -1049,7 +1049,7 @@ do_compare_rtx_and_jump (rtx op0, rtx op
 }
   else
 {
-  if (GET_MODE_CLASS (mode) == MODE_FLOAT
+  if (SCALAR_FLOAT_MODE_P (mode)
  && ! can_compare_p (code, mode, ccp_jump)
  && can_compare_p (swap_condition (code), mode, ccp_jump))
{
@@ -1060,7 +1060,7 @@ do_compare_rtx_and_jump (rtx op0, rtx op
  op1 = tmp;
}
 
-  else if (GET_MODE_CLASS (mode) == MODE_FLOAT
+  else if (SCALAR_FLOAT_MODE_P (mode)
   && ! can_compare_p (code, mode, ccp_jump)
 
   /* Never split ORDERED and UNORDERED.  These must be 
implemented.  */
Index: gcc/testsuite/gcc.dg/dfp/pr52140.c
===
--- gcc/testsuite/gcc.dg/dfp/pr52140.c  (revision 0)
+++ gcc/testsuite/gcc.dg/dfp/pr52140.c  (revision 0)
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-options "-O1" } */
+
+/* This used to result in an ICE.  */
+
+int
+foo (_Decimal64 x, _Decimal64 y)
+{
+  return (x < y) || (x > y);
+}

Re: [PATCH] Fix PR middle-end/52140, ICE on valid code

[Peter Bergner]

On Wed, 2012-02-08 at 20:34 -0600, Peter Bergner wrote:
> The following patch fixes an ICE when we try and generate a compare of
> decimal float variables when we are not compiling for a cpu with dfp
> hardware support.  This is a regression from gcc 4.4.  The patch below
> bootstrapped and regression tested with no regressions on trunk, 4.6
> and 4.5.  Is this ok everywhere?

Sorry for replying to my own message, but I meant to say this was
bootstrapped and regression tested on powerpc64-linux and running
the test suite in both 32-bit and 64-bit modes.

Peter

Re: [trans-mem,darwin] PR/52042 find tm_clone_table with PIE

[Patrick Marlier]

On 02/08/2012 12:12 AM, Jack Howarth wrote:

I believe the remaining libitm.c++/eh-1.C execution test failures are due to
the weakref linker bug currently in Xcode 4.x (radr://10466868) which I hae been
told will be fixed in the next Xcode release after Xcode 4.3.
 Jack


Humm... In fact, not completely. Of course, if the linker was working, 
the HAVE_ELF_STYLE_WEAKREF will be defined and no problem.


Otherwise in the eh-1.c, we can see that _ITM_cxa_allocation_exception 
is using the dummy function __cxa_allocation_exception defined into 
eh_cpp.cc but not the one from libstdc++. There is no dynamic symbol 
resolution since the function is defined in the file.


I do not really know why those functions are defined here, I think it 
may causes more problems than it solves for darwin.


When Rainer introduced this, he mentioned "on Tru64 UNIX. Of course it 
cannot work to provide only a single dummy function, but all weak 
definitions must be backed by dummy definitions on that platform."

http://patchwork.ozlabs.org/patch/126007/

Iain mentioned this when he introduced the dummy def for darwin:
*** FWIW, weakref actually work (at runtime) for earlier Darwin
- it's just that refs either need to be satisfied by dummies at link time -
- or the library namespace has to be flattened (which is generally 
undesirable).


I think refs (from libstdc++) should be satisfied at link time with 
-lstdc++ but probably I am missing something?


Note that removing definitions in eh_cpp.cc make the test passes.

Thanks guys!
--
Patrick.

Re: Too much memory in chan/select2.go used

[Ian Lance Taylor]

Uros Bizjak  writes:

> Some more debugging reveal the difference between alpha and x86_64.
> Alpha does not implement split stacks, so soon after
> "runtime.MemStats.Alloc = 0" line, we allocate exactly 2MB fake stack
> via:

Thanks for tracking this down.

> So, short of XFAILing the test on non-split stack targets, I have no
> other idea how to handle this testcase failure.

I thought about it for a while, and I can't think of any better approach
than to skip this test case.  A simple xfail doesn't work because it
xfails the compilation of the test case rather than the execution,
leading to an XPASS and a FAIL.

I have committed this patch.

Ian


2012-02-08  Ian Lance Taylor  

* go.test/go-test.exp (go-gc-tests): Don't run chan/select2.go on
systems which don't support -fsplit-stack.


Index: gcc/testsuite/go.test/go-test.exp
===
--- gcc/testsuite/go.test/go-test.exp	(revision 184032)
+++ gcc/testsuite/go.test/go-test.exp	(working copy)
@@ -33,6 +33,7 @@
 
 load_lib go-dg.exp
 load_lib go-torture.exp
+load_lib target-supports.exp
 
 # Compare two files
 proc filecmp { file1 file2 testname } {
@@ -329,6 +330,15 @@ proc go-gc-tests { } {
 	continue
 	}
 
+	if { [file tail $test] == "select2.go" && \
+		 ! [check_effective_target_split_stack] } {
+	# chan/select2.go fails on targets without split stack,
+	# because they allocate a large stack segment that blows
+	# out the memory calculations.
+	untested $name
+	continue
+	}
+
 	set fd [open $test r]
 
 	set lines_ok 1