Re: [rs6000] Fix PR 50906, eh_frame and other woes

2011-11-18 Thread Olivier Hainque

On Nov 17, 2011, at 20:46 , David Edelsohn wrote:

> Coincidentally, IBM's XL compiler is encountering a similar issue and
> proposing a similar solution of having the stack pointer update
> conflict with all memory accesses.

 Interesting timing :-)

> I think all these corner cases
> confirm that it is impractical for the compiler to track all accesses
> against SP and the only expedient solution is a hammer like
> conflicting with all memory.

 OK, I'll come up with a patch. I'll compare the generated assembly for
 the Ada runtime lib with and without the change. That should be easy to
 do and will provide a datapoint.

 Thanks for your feedback.

 Olivier



Re: [PATCH, tree-opt]: Fix PR5118, ICE: tree check: expected tree that contains ‘typed’ structure, have ‘block’ in fold_checksum_tree

2011-11-18 Thread Richard Guenther
On Thu, Nov 17, 2011 at 8:47 PM, Uros Bizjak  wrote:
> Hello!
>
> Currently, bootstrap crashes with --enable-stage1-checking=all with:
>
> ../../../libgcc/libgcc2.c:553:3: internal compiler error: tree check: expected
> tree that contains ‘typed’ structure, have ‘block’ in fold_checksum_tree, at
> fold-const.c:14160
>
> The problem is in fold_checksum_tree function itself, when it recurses for 
> i.e.
>
> (gdb) p debug_tree (expr)
>      type         align 8 symtab 0 alias set -1 canonical type 0x719a5bd0
>        pointer_to_this >
> ---
>    body 
>        side-effects arg 0 
>        031.c:4:32>
>    block >
>    031.c:4:23>
>
> The function decomposes the tree expression with:
>
>    case tcc_expression:
> ...
>      len = TREE_OPERAND_LENGTH (expr);
>      for (i = 0; i < len; ++i)
>>>      fold_checksum_tree (TREE_OPERAND (expr, i), ctx, ht);
>      break;
>
> where we recurse with "block" expression, that has no type. This
> recursion crashes at
>
>  md5_process_bytes (expr, tree_size (expr), ctx);
>>>  fold_checksum_tree (TREE_TYPE (expr), ctx, ht);
>
> The fix is fairly trivial - check for typed structure before using
> TREE_TYPE accessor, as the error said.
>
> 2011-11-17  Uros Bizjak  
>
>        PR tree-optimization/51118
>        * fold-const.c (fold_checksum_tree): Check for TS_TYPED structure
>        before using TREE_TYPE accessor on expr.
>
> Patch was tested by bootstrapping --enable-stage1-checking=all
> configured bootstrap (which takes ages...) on x86_64-pc-linux-gnu.
>
> OK for mainline and release branches?

Ok for trunk.

Thanks,
Richard.

> Uros.
>


Re: [PATCH] Mark back edges in insert_backedge_copies

2011-11-18 Thread Richard Guenther
On Thu, Nov 17, 2011 at 10:55 PM, William J. Schmidt
 wrote:
> Greetings,
>
> While investigating http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976, I
> found that tree-outof-ssa.c:insert_backedge_copies tests whether edges
> are back edges, but the back edges haven't been marked to facilitate
> this.  (This was the reason the failures started happening in r149206,
> although fixing it doesn't take care of the problem in the current trunk
> revision because of the duplicate PHIs noted in the issue.)
>
> This simple patch updates the back edge information where it's needed.
> Bootstrapped and regression tested on powerpc64-linux.  OK for trunk?

Ok.

Thanks,
Richard.

> Thanks,
> Bill
>
>
> 2011-11-17  Bill Schmidt  
>
>        * tree-outof-ssa.c (insert_back_edge_copies):  Add call to
>        mark_dfs_back_edges.
>
>
>
> Index: gcc/tree-outof-ssa.c
> ===
> --- gcc/tree-outof-ssa.c        (revision 181442)
> +++ gcc/tree-outof-ssa.c        (working copy)
> @@ -1021,6 +1021,8 @@ insert_backedge_copies (void)
>   basic_block bb;
>   gimple_stmt_iterator gsi;
>
> +  mark_dfs_back_edges ();
> +
>   FOR_EACH_BB (bb)
>     {
>       /* Mark block as possibly needing calculation of UIDs.  */
>
>
>


[C++ Patch] PR c++/51188

2011-11-18 Thread Fabien Chêne
Hi,

As discussed in the audit trail, here is a patch that fixes this PR
and all its duplicates.
Tested x86_64-unknown-linux-gnu without regressions. OK to commit ?

gcc/testsuite/ChangeLog

2011-11-18  Fabien Chêne  

PR c++/51188
* g++.dg/lookup/using46.C: New.
* g++.dg/lookup/using47.C: New.
* g++.dg/lookup/using48.C: New.
* g++.dg/lookup/using49.C: New.
* g++.dg/lookup/using50.C: New.

gcc/cp/ChangeLog

2011-11-18  Fabien Chêne  

PR c++/51188
* search.c (lookup_field_1): Handle USING_DECLs for the storted
case.

-- 
Fabien
Index: gcc/testsuite/g++.dg/debug/using6.C
===
--- gcc/testsuite/g++.dg/debug/using6.C (revision 0)
+++ gcc/testsuite/g++.dg/debug/using6.C (revision 0)
@@ -0,0 +1,22 @@
+// PR c++/51189
+// { dg-do compile }
+
+struct A
+{
+  int i1, i2, i3, i4, i5, i6;
+};
+
+struct B : A
+{
+  using A::i1;
+  using A::i2;
+  using A::i3;
+  using A::i4;
+  using A::i5;
+  using A::i6;
+};
+
+struct C : B
+{
+  using B::i1;
+};
Index: gcc/testsuite/g++.dg/lookup/using49.C
===
--- gcc/testsuite/g++.dg/lookup/using49.C   (revision 0)
+++ gcc/testsuite/g++.dg/lookup/using49.C   (revision 0)
@@ -0,0 +1,20 @@
+// PR c++/51188
+// { dg-do compile }
+
+#include 
+class XBase {
+public:
+   virtual ~XBase() = 0;
+   enum ImpMode { Imp1, Imp2, Imp3 };
+};
+class X : public XBase {
+   class XBlock {};
+   using XBase::ImpMode;
+   using XBase::Imp3;
+   using XBase::Imp1;
+   using XBase::Imp2;
+   int _XBlocked;
+   std::pair getImp(void) const {
+  return (std::make_pair(0, static_cast(X::Imp1)));
+   }
+};
Index: gcc/testsuite/g++.dg/lookup/using46.C
===
--- gcc/testsuite/g++.dg/lookup/using46.C   (revision 0)
+++ gcc/testsuite/g++.dg/lookup/using46.C   (revision 0)
@@ -0,0 +1,65 @@
+// PR c++/51141
+// { dg-do compile }
+// { dg-options "-fpermissive -w -Werror" }
+
+typedef int size_t;
+template < size_t, size_t > struct AlignedBuffer;
+template < size_t size > struct AlignedBuffer 
+ < size, 8 > {
+};
+
+template < typename > class VectorBufferBase
+{
+public:
+allocateBuffer (size_t) {
+}
+buffer () {
+}
+*m_buffer;
+size_t m_capacity;
+};
+
+template < typename T, size_t > class VectorBuffer:VectorBufferBase < T >
+{
+typedef VectorBufferBase < T > Base;
+
+public:
+VectorBuffer () {
+}
+allocateBuffer (size_t) {
+m_capacity = 0;
+}
+Base::buffer;
+Base::m_buffer;
+Base::m_capacity;
+size_t m_inlineBufferSize;
+
+AlignedBuffer < 0, __alignof__ (T) > m_inlineBuffer;
+};
+
+template < typename T, size_t > class Vector
+{
+typedef VectorBuffer < T,
+0 > Buffer;
+public:
+void shrinkCapacity (size_t);
+
+clear () {
+shrinkCapacity (0);
+}
+Buffer m_buffer;
+};
+
+template < typename T, size_t inlineCapacity > void Vector < T,
+ inlineCapacity >::shrinkCapacity (size_t)
+{
+m_buffer.allocateBuffer (0);
+}
+
+struct PatternDisjunction;
+struct YarrPattern {
+reset () {
+m_disjunctions.clear ();
+}
+Vector < PatternDisjunction *, 0 > m_disjunctions;
+};
Index: gcc/testsuite/g++.dg/lookup/using47.C
===
--- gcc/testsuite/g++.dg/lookup/using47.C   (revision 0)
+++ gcc/testsuite/g++.dg/lookup/using47.C   (revision 0)
@@ -0,0 +1,29 @@
+// PR c++/51152
+// { dg-do compile }
+
+struct A
+{
+int a;
+};
+
+struct B
+{
+int b1;
+int b2;
+A b3;
+};
+
+struct C : B
+{
+typedef int R;
+typedef int S;
+typedef int T;
+using B::b1;
+using B::b2;
+using B::b3;
+void f()
+{
+b3.a;
+   b3.~A();
+}
+};
Index: gcc/testsuite/g++.dg/lookup/using48.C
===
--- gcc/testsuite/g++.dg/lookup/using48.C   (revision 0)
+++ gcc/testsuite/g++.dg/lookup/using48.C   (revision 0)
@@ -0,0 +1,23 @@
+// PR c++/51190
+// { dg-do compile }
+
+struct A
+{
+  int i;
+};
+
+template struct B
+{
+  A* p;
+};
+
+template struct C : B
+{
+  using B::p;
+
+  C() { p->i; }
+
+  int i1, i2, i3, i4, i5;
+};
+
+C c;
Index: gcc/cp/search.c
===
--- gcc/cp/search.c (revision 181386)
+++ gcc/cp/search.c (working copy)
@@ -436,6 +436,14 @@ lookup_field_1 (tree type, tree name, bo
field = fields[i++];
  while (i < hi && DECL_NAME (fields[i]) == name);
}
+
+ if (field)
+   {
+ field = strip_using_decl (field);
+ if (is_overloaded_fn (field))
+   field = NULL_TREE;
+   }
+
  return field;
}
}


Re: [patch tree-optimization]: Fix for PR/49806

2011-11-18 Thread Kai Tietz
PING

2011/8/9 Kai Tietz :
> Hello,
>
> actual the remaining issue about this PR is that vrp
> constructs by range analyzis for bitwise and/or expressions
> type-casted results, like ((type) A) op ((type) B), or ((type) A) op CST.
> So I've added to simplify_bit_ops_using_rnages the transformation of
>  ((type) A) op ((type) B) -> (type) (A op B)
>  ((type) A) op CST -> (type) (A op CST'), with CST'=(type-A)
>
>  This first transformation is valid if A has an integral type, TYPE
> is of integral kind,
>  and type of B has compatible type to type of A.
>  The second transformation is valid if A has integral type, TYPE is
> of integral kind,
>  and CST fits into type of A.
>
> 2011-08-09  Kai Tietz  
>
>        PR middle-end/49806
>        * tree-vrp.c (simplify_bit_ops_using_ranges): Add
>        code for type-cast sinking for bitwise-operations.
>
>        * gcc.dg/tree-ssa/vrp47.c: Remove dom-dump and adjusted
>        scan test for vrp result.
>
> Bootstrapped and regression tested for all languages (including Ada
> and Obj-C++) on host x86_64-pc-linux-gnu.  Ok for apply?
>
> Regards,
> Kai
>
> Index: gcc/gcc/testsuite/gcc.dg/tree-ssa/vrp47.c
> ===
> --- gcc.orig/gcc/testsuite/gcc.dg/tree-ssa/vrp47.c
> +++ gcc/gcc/testsuite/gcc.dg/tree-ssa/vrp47.c
> @@ -4,8 +4,8 @@
>    jumps when evaluating an && condition.  VRP is not able to optimize
>    this.  */
>  /* { dg-do compile { target { ! "mips*-*-* s390*-*-*  avr-*-*
> mn10300-*-*" } } } */
> -/* { dg-options "-O2 -fdump-tree-vrp1 -fdump-tree-dom1" } */
> -/* { dg-options "-O2 -fdump-tree-vrp1 -fdump-tree-dom1 -march=i586" {
> target { i?86-*-* && ilp32 } } } */
> +/* { dg-options "-O2 -fdump-tree-vrp1" } */
> +/* { dg-options "-O2 -fdump-tree-vrp1 -march=i586" { target {
> i?86-*-* && ilp32 } } } */
>
>  int h(int x, int y)
>  {
> @@ -37,12 +37,10 @@ int f(int x)
>  /* { dg-final { scan-tree-dump-times "\[xy\]\[^ \]* !=" 0 "vrp1" } } */
>
>  /* This one needs more copy propagation that only happens in dom1.  */
> -/* { dg-final { scan-tree-dump-times "x\[^ \]* & y" 1 "dom1" } } */
> -/* { dg-final { scan-tree-dump-times "x\[^ \]* & y" 1 "vrp1" { xfail
> *-*-* } } } */
> +/* { dg-final { scan-tree-dump-times "x\[^ \]* & y" 1 "vrp1" } } */
>
>  /* These two are fully simplified by VRP.  */
>  /* { dg-final { scan-tree-dump-times "x\[^ \]* \[|\] y" 1 "vrp1" } } */
>  /* { dg-final { scan-tree-dump-times "x\[^ \]* \\^ 1" 1 "vrp1" } } */
>
>  /* { dg-final { cleanup-tree-dump "vrp1" } } */
> -/* { dg-final { cleanup-tree-dump "dom1" } } */
> Index: gcc/gcc/tree-vrp.c
> ===
> --- gcc.orig/gcc/tree-vrp.c
> +++ gcc/gcc/tree-vrp.c
> @@ -6968,15 +6968,63 @@ simplify_abs_using_ranges (gimple stmt)
>  static bool
>  simplify_bit_ops_using_ranges (gimple_stmt_iterator *gsi, gimple stmt)
>  {
> +  gimple def0, def1;
>   tree op0 = gimple_assign_rhs1 (stmt);
>   tree op1 = gimple_assign_rhs2 (stmt);
> -  tree op = NULL_TREE;
> +  tree op = NULL_TREE, nop0 = NULL_TREE, nop1 = NULL_TREE;
>   value_range_t vr0 = { VR_UNDEFINED, NULL_TREE, NULL_TREE, NULL };
>   value_range_t vr1 = { VR_UNDEFINED, NULL_TREE, NULL_TREE, NULL };
>   double_int may_be_nonzero0, may_be_nonzero1;
>   double_int must_be_nonzero0, must_be_nonzero1;
>   double_int mask;
>
> +  def0 = TREE_CODE (op0) == SSA_NAME ? SSA_NAME_DEF_STMT (op0) : NULL;
> +  def1 = TREE_CODE (op1) == SSA_NAME ? SSA_NAME_DEF_STMT (op1) : NULL;
> +  if (def0 && is_gimple_assign (def0))
> +      nop0 = gimple_assign_rhs1 (def0);
> +  if (def1 && is_gimple_assign (def1))
> +      nop1 = gimple_assign_rhs1 (def1);
> +
> +  /* Simplify ((type) X) op ((type) Y) -> (type) (X op Y), if X and Y have
> +     compatible integral types.  */
> +  if (nop0 != NULL_TREE && nop1 != NULL_TREE
> +      && CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (def0))
> +      && CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (def1))
> +      && INTEGRAL_TYPE_P (TREE_TYPE (nop0))
> +      && types_compatible_p (TREE_TYPE (nop0), TREE_TYPE (nop1)))
> +    {
> +      gimple newop;
> +      tree tem = create_tmp_reg (TREE_TYPE (nop0), NULL);
> +      newop = gimple_build_assign_with_ops (gimple_assign_rhs_code (stmt),
> +                                           tem, nop0, nop1);
> +      tem = make_ssa_name (tem, newop);
> +      gimple_assign_set_lhs (newop, tem);
> +      gsi_insert_before (gsi, newop, GSI_SAME_STMT);
> +      update_stmt (newop);
> +      gimple_assign_set_rhs_with_ops (gsi, NOP_EXPR, tem, NULL_TREE);
> +      return true;
> +    }
> +  /* Simplify ((type) X) op CST -> (type) (X op (type-X) CST), if X has
> +     an integral types.  Additiona CST has to fit into type of X.  */
> +  else if (nop0 != NULL_TREE && TREE_CODE (op1) == INTEGER_CST
> +           && CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (def0))
> +           && INTEGRAL_TYPE_P (TREE_TYPE (nop0))
> +           && int_fits_type_p (op1, TREE_TYPE (nop

Re: [wwwdocs] Buildstat update for 4.6

2011-11-18 Thread Gerald Pfeifer
On Fri, 4 Nov 2011, Tom G. Christensen wrote:
> I missed them since my script that parses the archive did not expect
> the extra text after the 'testsuite' part of the subject.
> 
> Here's an updated patch.

Thanks, applied.

Gerald


Re: Memset/memcpy patch

2011-11-18 Thread Michael Zolotukhin
I found another bug in current implementation. A patch for it doesn't
cure i686-linux- bootstrap, but fixes fails on some tests (see
attached).

The problem was that we tried to add runtime tests for alignment even
if both SRC and DST had unknown alignment - in this case it could be
impossible to make them both aligned simultaneously, so I think it's
easier to even not try to use aligned SSE-moves at all. Generation of
prologues with runtime tests could be used only if at least one
alignment is known - otherwise it's incorrect. Probably, generation of
such prologues could be removed from MEMMOV at all for now.

Though, even with this fix i686-bootstrap still fails. Configure for
the bootstrap-fail reproducing:
CC="gcc -m32" CXX="g++ -m32" ../configure --with-arch=core2
--with-cpu=atom --prefix=`pwd` i686-linux --with-fpmath=sse
--enable-languages=c,c++,fortran

On 18 November 2011 06:23, Jan Hubicka  wrote:
>> > >
>> > > The current x86 memset/memcpy expansion is broken. It miscompiles
>> > > many programs, including GCC itself.  Should it be reverted for now?
>> >
>> > There was problem in the new code doing loopy epilogues.
>> > I am currently testing the following patch that shold fix the problem.
>> > We could either revert now and I will apply combined patch or I hope to 
>> > fix that
>> > tonight.
>>
>> To expand little bit. I was looking into the code for most of the day today 
>> and
>> the patch combines several fixes
>>    1) the new loopy epilogue code was quite broken. It did not work for 
>> memset at all because
>>       the promoted value was not always initialized that I fixed in the 
>> version of patch
>>       that is in mainline now. It however also miss bound check in some 
>> cases.  This is fixed
>>       by the expand_set_or_movmem_via_loop_with_iter change.
>>    2) I misupdated atom description so 32bit memset was not expanded inline, 
>> this is fixed
>>       by memset changes
>>    3) decide_alg was broken in two ways - first it gives complex algorithms 
>> for -O0
>>       and it chose wrong variant when sse_loop is used.
>>    4) the epilogue loop was output even in the case it is not needed - i.e. 
>> when unrolled
>>       loops handled 16 bytes at once, and block size is 39. This is the 
>> ix86_movmem
>>       and ix86_setmem change
>>    5) The implementation of ix86_movmem/ix86_setmem diverged for no reason 
>> so I got it back
>>       to sync. For some reason SSE code in movmem is not output for 64bit 
>> unaligned memcpy
>>       that is fixed too.
>>    6) it seems that both bdver and core is good enough on handling 
>> misaligned blocks that
>>       the alignmnet prologues can be ommited. This greatly improves and 
>> reduces size of the
>>       inline sequence. I will however break this out into independent patch.
>>
>> Life would be easier if the changes was made in multiple incremental steps, 
>> stringops expansion
>> is relatively tricky busyness and realively easy to get wrong in some cases 
>> since there are so
>> many of them depending on knowledge of size/alignmnet and target 
>> architecture.
>
> Hi,
> this is the patch I comitted after bootstrapping/regstesting x86_64-linux and
> --with-arch=core2 --with-cpu=atom 
> gfortran.fortran-torture/execute/arrayarg.f90
> failure stays. As I've explained in the PR log, I believe it is previously
> latent problem elsewhere that is now triggered by inline memset expansion that
> is later unrolled.  I would welcome help from someone who understand the
> testcase on whether it is aliasing safe or not.
>
> Honza
>
>        PR bootstrap/51134
>        * i386.c (atom_cost): Fix 32bit memset description.
>        (expand_set_or_movmem_via_loop_with_iter): Output proper bounds check 
> for epilogue loops.
>        (expand_movmem_epilogue): Handle epilogues up to size 15 w/o producing 
> byte loop.
>        (decide_alg): sse_loop is not useable wthen SSE2 is disabled; when not 
> optimizing always
>        use rep movsb or lincall; do not produce word sized loops when 
> optimizing memset for
>        size (to avoid need for large constants).
>        (ix86_expand_movmem): Get into sync with ix86_expand_setmem; choose 
> unroll factors
>        better; always do 128bit moves when producing SSE loops; do not 
> produce loopy epilogue
>        when size is too small.
>        (promote_duplicated_reg_to_size): Do not look into desired alignments 
> when
>        doing vector expansion.
>        (ix86_expand_setmem): Track better when promoted value is available; 
> choose unroll factors
>        more sanely.; output loopy epilogue only when needed.
> Index: config/i386/i386.c
> ===
> *** config/i386/i386.c  (revision 181407)
> --- config/i386/i386.c  (working copy)
> *** struct processor_costs atom_cost = {
> *** 1785,1791 
>       if that fails.  */
>    {{{libcall, {{4096, sse_loop}, {4096, unrolled_loop}, {-1, libcall}}}, /* 
> Known alignm

[v3] Declare std::hash specializations noexcept

2011-11-18 Thread Paolo Carlini

Hi,

this makes sure the various hash specializations are declared noexcept. 
Francois, please let me know if you are seeing something wrong / missing 
as part of your work...


Tested x86_64-linux, committed.

Thanks,
Paolo.

//
2011-11-18  Paolo Carlini  

* src/hash-long-double-aux.cc: Rename to...
* src/hash-long-double-tr1-aux.cc: ... this.
* src/compatibility-ldbl.cc: Adjust.
* src/hash_tr1.cc: Likewise.
* src/hash_c++0x.cc: Don't use src/hash-long-double-aux.cc.
* include/bits/functional_hash.h (hash<_Tp*>::operator(), specs
for integer types, hash::operator(), hash::operator(),
hash::operator()): Declare noexcept.
* include/debug/bitset (hash<__debug::bitset>::operator()): Likewise.
* include/debug/vector (hash<__debug::vector>::operator()): Likewise.
* include/std/system_error (hash::operator()): Likewise.
* include/std/thread (hash::operator()): Likewise.
* include/std/bitset (hash::operator()): Likewise.
* include/std/typeindex (hash::operator()): Likewise.
* include/profile/bitset (hash<__profile::vector>::operator()):
Likewise.
* include/profile/vector (hash<__profile::vector>::operator()):
Likewise.
* include/ext/vstring.h (hash<__vstring>::operator(),
hash<__wvstring>::operator(), hash<__u16vstring>::operator(),
hash<__u32vstring>::operator()): Likewise.
* include/bits/shared_ptr.h (hash::operator()): Likewise.
* include/bits/shared_ptr_base.h (hash<__shared_ptr>::operator()):
Likewise.
* include/bits/unique_ptr.h (hash::operator()): Likewise.
* include/bits/basic_string.h (hash::operator(),
hash::operator(), hash::operator(),
hash::operator()): Likewise.
* include/bits/vector.tcc (hash::operator()): Likewise.
* include/bits/stl_bvector.h (hash::operator()): Likewise.
* libsupc++/typeinfo (type_info::hash_code): Use noexcept instead of
throw().
Index: src/hash_c++0x.cc
===
--- src/hash_c++0x.cc   (revision 181470)
+++ src/hash_c++0x.cc   (working copy)
@@ -1,6 +1,6 @@
 // std::hash definitions -*- C++ -*-
 
-// Copyright (C) 2010 Free Software Foundation, Inc.
+// Copyright (C) 2010, 2011 Free Software Foundation, Inc.
 //
 // This file is part of the GNU ISO C++ Library.  This library is free
 // software; you can redistribute it and/or modify it under the
@@ -30,5 +30,27 @@
 
 namespace std _GLIBCXX_VISIBILITY(default)
 {
-#include "hash-long-double-aux.cc"
+  _GLIBCXX_PURE size_t
+  hash::operator()(long double __val) const noexcept
+  {
+// 0 and -0 both hash to zero.
+if (__val == 0.0L)
+  return 0;
+
+int __exponent;
+__val = __builtin_frexpl(__val, &__exponent);
+__val = __val < 0.0l ? -(__val + 0.5l) : __val;
+
+const long double __mult = __SIZE_MAX__ + 1.0l;
+__val *= __mult;
+
+// Try to use all the bits of the mantissa (really necessary only
+// on 32-bit targets, at least for 80-bit floating point formats).
+const size_t __hibits = (size_t)__val;
+__val = (__val - (long double)__hibits) * __mult;
+
+const size_t __coeff = __SIZE_MAX__ / __LDBL_MAX_EXP__;
+
+return __hibits + (size_t)__val + __coeff * __exponent;
+  }
 }
Index: src/compatibility-ldbl.cc
===
--- src/compatibility-ldbl.cc   (revision 181470)
+++ src/compatibility-ldbl.cc   (working copy)
@@ -1,6 +1,6 @@
 // Compatibility symbols for -mlong-double-64 compatibility -*- C++ -*-
 
-// Copyright (C) 2006, 2008, 2009, 2010
+// Copyright (C) 2006, 2008, 2009, 2010, 2011
 // Free Software Foundation, Inc.
 //
 // This file is part of the GNU ISO C++ Library.  This library is free
@@ -69,15 +69,8 @@
 
 // For std::tr1::hash::operator()
 #define _GLIBCXX_LONG_DOUBLE_COMPAT_IMPL
+#include "hash-long-double-tr1-aux.cc"
 
-namespace std _GLIBCXX_VISIBILITY(default)
-{
-  namespace tr1 
-  {
-#include "hash-long-double-aux.cc"
-  }
-}
-
 // std::tr1::hash::operator()
 // and std::hash::operator()
 // are the same, no need to duplicate them.
Index: src/hash_tr1.cc
===
--- src/hash_tr1.cc (revision 181470)
+++ src/hash_tr1.cc (working copy)
@@ -1,6 +1,6 @@
 // std::tr1::hash definitions -*- C++ -*-
 
-// Copyright (C) 2007, 2008, 2009, 2010 Free Software Foundation, Inc.
+// Copyright (C) 2007, 2008, 2009, 2010, 2011 Free Software Foundation, Inc.
 //
 // This file is part of the GNU ISO C++ Library.  This library is free
 // software; you can redistribute it and/or modify it under the
@@ -25,12 +25,12 @@
 #include 
 #include 
 
+#include "hash-long-double-tr1-aux.cc"
+
 namespace std _GLIBCXX_VISIBILITY(default)
 {
   namespace tr1 
   {
-#include "hash-long-double-aux.cc"
-
 #ifndef _GLIBCXX_LONG_DOUBLE_COM

Re: [C++ Patch] PR c++/51188

2011-11-18 Thread Jason Merrill

On 11/18/2011 05:18 AM, Fabien Chêne wrote:

+template<  size_t, size_t>  struct AlignedBuffer;
+template<  size_t size>  struct AlignedBuffer
+<  size, 8>  {
+};


This testcase will break on targets where alignof(void*) != 8; just 
define the base template and remove the partial specialization.


OK with that change.

Jason



Re: [PATCH] PR c++/51191 - ICE on alias of alias template instantiation

2011-11-18 Thread Jason Merrill

On 11/17/2011 06:32 PM, Dodji Seketeli wrote:

I am bootstrapping and testing the (IMHO better) patch below on
x86_64-unknown-linux-gnu against trunk.


OK.

Jason



[PATCH] Remove dead labels to increase superblock scope

2011-11-18 Thread Tom de Vries
Hi Eric,

this patch fixes an inefficiency problem I observed while working on PR50764.

For the test-case of PR50764, a dead label is introduced by fixup_reorder_chain
in cfg_layout_finalize, called from pass_reorder_blocks.
The dead label is removed by a cleanup_cfg in pass_duplicate_computed_gotos, but
is still present during pass_sched2.
When constructing ebbs in schedule_ebbs, the dead label ends an ebb. If we
remove the label before pass_sched2, the ebb is allowed to grow larger.

The patch tries to get rid of the dead label immediately after it's introduced,
in cfg_layout_finalized.

The new test gcc.dg/superblock.c uses -fno-asynchronous-unwind-tables to work
around PR50764.

bootstrapped and reg-tested on x86_64.

OK for next stage 1?

Thanks,
- Tom

2011-11-18  Tom de Vries  

* rtl.h (delete_dead_labels): Declare.
* cfgcleanup.c (delete_dead_labels): New function.
* cfglayout.c (cfg_layout_finalize): Use delete_dead_labels.

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


Re: [C++ Patch] PR 51150

2011-11-18 Thread Jason Merrill

On 11/17/2011 06:52 PM, Paolo Carlini wrote:

The problem is, in all these tests,
value is always a FIX_TRUNC_EXPR, which, AFAICS, is always left
untouched.


Aha, I guess tsubst_copy_and_build needs to handle FIX_TRUNC_EXPR better.

Jason



Re: [C++ Patch] PR 51150

2011-11-18 Thread Paolo Carlini

On 11/18/2011 02:16 PM, Jason Merrill wrote:

On 11/17/2011 06:52 PM, Paolo Carlini wrote:

The problem is, in all these tests,
value is always a FIX_TRUNC_EXPR, which, AFAICS, is always left
untouched.

Aha, I guess tsubst_copy_and_build needs to handle FIX_TRUNC_EXPR better.
I see. Maybe better if you handle this issue, I have very little clues 
about the right way to do that, see, in the whole cp/ I count only try 
occurrences of FIX_TRUNC_EXPR overall ;)


Paolo.


Re: [C++ Patch] PR 51150

2011-11-18 Thread Paolo Carlini

On 11/18/2011 02:27 PM, Paolo Carlini wrote:

On 11/18/2011 02:16 PM, Jason Merrill wrote:

On 11/17/2011 06:52 PM, Paolo Carlini wrote:

The problem is, in all these tests,
value is always a FIX_TRUNC_EXPR, which, AFAICS, is always left
untouched.
Aha, I guess tsubst_copy_and_build needs to handle FIX_TRUNC_EXPR 
better.
I see. Maybe better if you handle this issue, I have very little clues 
about the right way to do that, see, in the whole cp/ I count only try 
occurrences of FIX_TRUNC_EXPR overall ;)

I meant 4, including one in error.c. You see my point.

Paolo.


Re: [C++ Patch] PR 51150

2011-11-18 Thread Paolo Carlini

On 11/18/2011 02:29 PM, Paolo Carlini wrote:

On 11/18/2011 02:27 PM, Paolo Carlini wrote:

On 11/18/2011 02:16 PM, Jason Merrill wrote:

On 11/17/2011 06:52 PM, Paolo Carlini wrote:

The problem is, in all these tests,
value is always a FIX_TRUNC_EXPR, which, AFAICS, is always left
untouched.
Aha, I guess tsubst_copy_and_build needs to handle FIX_TRUNC_EXPR 
better.
I see. Maybe better if you handle this issue, I have very little 
clues about the right way to do that, see, in the whole cp/ I count 
only try occurrences of FIX_TRUNC_EXPR overall ;)

I meant 4, including one in error.c. You see my point.
Well, unless there are hopes that something as simple as the attached is 
all there is to it: works for the testcase, but I haven't run the 
testsuite...


Paolo.


Index: pt.c
===
--- pt.c(revision 181474)
+++ pt.c(working copy)
@@ -13384,6 +13384,7 @@ tsubst_copy_and_build (tree t,
 case UNARY_PLUS_EXPR:  /* Unary + */
 case REALPART_EXPR:
 case IMAGPART_EXPR:
+case FIX_TRUNC_EXPR:
   return build_x_unary_op (TREE_CODE (t), RECUR (TREE_OPERAND (t, 0)),
complain);
 
Index: call.c
===
--- call.c  (revision 181474)
+++ call.c  (working copy)
@@ -5227,6 +5227,7 @@ build_new_op_1 (enum tree_code code, int flags, tr
 case REALPART_EXPR:
 case IMAGPART_EXPR:
 case ABS_EXPR:
+case FIX_TRUNC_EXPR:
   return cp_build_unary_op (code, arg1, candidates != 0, complain);
 
 case ARRAY_REF:


[Patch RFA libitm] config-based assessment of weakref capability

2011-11-18 Thread Iain Sandoe

Hi,

one of the three remaining libitm issues for Darwin is to supply the  
dummy funcs fro the weakrefs (as Rainer has done for Tru64) for the  
versions of Darwin that need them.


Since we now have the situation where there are several targets which  
might need dummy functions for the weak declarations, it seemed worth  
trying to auto-foo this.


.. the attached works for me on Darwin9 (weakref doesn't work like  
elf***) and Darwin10+XCode3.2.5 (weakref works like elf)


I hope it also works for Rainer  and that I've got the right  
designator for the Tru64 cross-case.


comments/OK for trunk?
Iain

*** 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).


-

libitm:

* acinclude.m4 (LIBITM_CHECK_WORKING_WEAKREF): New.
* configure.ac: Use LIBITM_CHECK_WORKING_WEAKREF.
* alloc_cpp.cc: Generate dummy functions if we don't
HAVE_WORKING_WEAKREF.
* eh_cpp.cc: Likewise.
* configure: Regenerate.
* aclocal.m4:  Likewise.
* config.h.in: Likewise.

Index: libitm/acinclude.m4
===
--- libitm/acinclude.m4 (revision 181470)
+++ libitm/acinclude.m4 (working copy)
@@ -109,6 +109,29 @@ i[[34567]]86 | x86_64)
   ;;
 esac])
 
+dnl Check whether weak refs actually work.
+AC_DEFUN([LIBITM_CHECK_WORKING_WEAKREF], [
+  AC_CACHE_CHECK([whether weak refs actually work],
+  libitm_cv_have_working_weakref, [
+  AC_RUN_IFELSE([AC_LANG_SOURCE([[
+extern void fNotToBeFoundInAnyStandardLib(void) __attribute__((weak));
+int main () 
+{
+  if (fNotToBeFoundInAnyStandardLib)
+return 0;
+  else
+return 1;
+}
+}]])], libitm_cv_have_working_weakref=yes, libitm_cv_have_working_weakref=no, [
+case "${host}" in
+  alpha*-dec-osf*) libitm_cv_have_working_weakref=no ;;
+  *-apple-darwin[[89]]*) libitm_cv_have_working_weakref=no ;;
+  *) libitm_cv_have_working_weakref=yes;;
+esac])])
+if test x"$libitm_cv_have_working_weakref" = xyes; then
+  AC_DEFINE(HAVE_WORKING_WEAKREF, 1, [Define to 1 if target has a working 
weakref.])
+fi])
+
 sinclude(../libtool.m4)
 dnl The lines below arrange for aclocal not to bring an installed
 dnl libtool.m4 into aclocal.m4, while still arranging for automake to
Index: libitm/configure.ac
===
--- libitm/configure.ac (revision 181470)
+++ libitm/configure.ac (working copy)
@@ -238,6 +238,7 @@ CFLAGS="$save_CFLAGS $XCFLAGS"
 LIBITM_CHECK_SYNC_BUILTINS
 LIBITM_CHECK_64BIT_SYNC_BUILTINS
 LIBITM_CHECK_AS_AVX
+LIBITM_CHECK_WORKING_WEAKREF
 
 # Cleanup and exit.
 CFLAGS="$save_CFLAGS"
Index: libitm/alloc_cpp.cc
===
--- libitm/alloc_cpp.cc (revision 181470)
+++ libitm/alloc_cpp.cc (working copy)
@@ -60,7 +60,7 @@ extern void _ZdlPvRKSt9nothrow_t (void *, c_nothro
 extern void *_ZnaXRKSt9nothrow_t (size_t, c_nothrow_p) __attribute__((weak));
 extern void _ZdaPvRKSt9nothrow_t (void *, c_nothrow_p) __attribute__((weak));
 
-#ifdef __osf__ /* Really: !HAVE_WEAKDEF  */
+#if !defined (HAVE_WORKING_WEAKREF)
 void *_ZnwX (size_t) { return NULL; }
 void _ZdlPv (void *) { return; }
 void *_ZnaX (size_t) { return NULL; }
@@ -70,7 +70,7 @@ void *_ZnwXRKSt9nothrow_t (size_t, c_nothrow_p) {
 void _ZdlPvRKSt9nothrow_t (void *, c_nothrow_p) { return; }
 void *_ZnaXRKSt9nothrow_t (size_t, c_nothrow_p) { return NULL; }
 void _ZdaPvRKSt9nothrow_t (void *, c_nothrow_p) { return; }
-#endif /* __osf__ */
+#endif /* HAVE_WORKING_WEAKREF */
 
 /* Wrap the delete nothrow symbols for usage with a single argument.
Perhaps should have a configure type check for this, because the
Index: libitm/eh_cpp.cc
===
--- libitm/eh_cpp.cc(revision 181470)
+++ libitm/eh_cpp.cc(working copy)
@@ -39,13 +39,13 @@ extern void *__cxa_begin_catch (void *) WEAK;
 extern void *__cxa_end_catch (void) WEAK;
 extern void __cxa_tm_cleanup (void *, void *, unsigned int) WEAK;
 
-#ifdef __osf__ /* Really: !HAVE_WEAKDEF  */
+#if !defined (HAVE_WORKING_WEAKREF)
 void *__cxa_allocate_exception (size_t) { return NULL; }
 void __cxa_throw (void *, void *, void *) { return; }
 void *__cxa_begin_catch (void *) { return NULL; }
 void *__cxa_end_catch (void) { return NULL; }
 void __cxa_tm_cleanup (void *, void *, unsigned int) { return; }
-#endif
+#endif /* HAVE_WORKING_WEAKREF */
 
 }
 






Re: [C++ Patch] PR 51150

2011-11-18 Thread Jason Merrill
I think let's go straight to cp_build_unary_op from 
tsubst_copy_and_build in this case; it can't be overloaded, and we don't 
want to mess with build_non_dependent_expr.


Jason


Re: [C++ Patch] PR 51150

2011-11-18 Thread Paolo Carlini

On 11/18/2011 02:53 PM, Jason Merrill wrote:
I think let's go straight to cp_build_unary_op from 
tsubst_copy_and_build in this case; it can't be overloaded, and we 
don't want to mess with build_non_dependent_expr.
Ok. In the meanwhile I actually tested the attached, and it works. Is it 
what you have in mind?


Paolo.

///
/cp
2011-11-18  Paolo Carlini  

PR c++/51150
* pt.c (tsubst_copy_and_build): Handle FIX_TRUNC_EXPR.
* call.c (build_new_op_1): Likewise.

/testsuite
2011-11-18  Paolo Carlini  

PR c++/51150
* g++.dg/cpp0x/pr51150.C: New.
Index: testsuite/g++.dg/cpp0x/pr51150.C
===
--- testsuite/g++.dg/cpp0x/pr51150.C(revision 0)
+++ testsuite/g++.dg/cpp0x/pr51150.C(revision 0)
@@ -0,0 +1,20 @@
+// PR c++/51150
+// { dg-options "-std=c++0x" }
+
+struct Clock {
+  double Now();
+};
+template  void Foo(Clock* clock) {
+  const int now = clock->Now();
+}
+
+template void Foo(Clock*);
+
+template  void Boo(int val) {
+  const int now1 = (double)(val);
+  const int now2 = const_cast(val); // { dg-error "invalid" }
+  const int now3 = static_cast(val);
+  const int now4 = reinterpret_cast(val); // { dg-error "invalid" }
+}
+
+template void Boo(int);
Index: cp/pt.c
===
--- cp/pt.c (revision 181474)
+++ cp/pt.c (working copy)
@@ -13384,6 +13384,7 @@ tsubst_copy_and_build (tree t,
 case UNARY_PLUS_EXPR:  /* Unary + */
 case REALPART_EXPR:
 case IMAGPART_EXPR:
+case FIX_TRUNC_EXPR:
   return build_x_unary_op (TREE_CODE (t), RECUR (TREE_OPERAND (t, 0)),
complain);
 
Index: cp/call.c
===
--- cp/call.c   (revision 181474)
+++ cp/call.c   (working copy)
@@ -5227,6 +5227,7 @@ build_new_op_1 (enum tree_code code, int flags, tr
 case REALPART_EXPR:
 case IMAGPART_EXPR:
 case ABS_EXPR:
+case FIX_TRUNC_EXPR:
   return cp_build_unary_op (code, arg1, candidates != 0, complain);
 
 case ARRAY_REF:


[Patch RFA libitm] Deal with __USER_LABEL_PREFIX__ in the asm

2011-11-18 Thread Iain Sandoe

Darwin needs to account for __USER_LABEL_PREFIX__ in the asm.

I used some of the arm code in libgcc as an example ...

allows the lib to build OK on x86-darwin ... (with working hidden  
symbols etc.)


comments/OK for trunk (assuming a test on linux is successful, of  
course)?

Iain

libitm:

* config/x86/sjlj.S (CONCAT1, CONCAT2, SYM): Respond to
__USER_LABEL_PREFIX__ for targets that use it.
TYPE, SIZE, HIDDEN): New macros to assist on non-elf targets.
(_ITM_beginTransaction): Use SYM, TYPE, SIZE macros to assist
in portability to non-elf targets.
(GTM_longjmp): LIkewise.
* libitm_i.h (begin_transaction): Apply __USER_LABEL_PREFIX__
where required.


Index: libitm/config/x86/sjlj.S
===
--- libitm/config/x86/sjlj.S(revision 181470)
+++ libitm/config/x86/sjlj.S(working copy)
@@ -25,12 +25,35 @@
 
 #include "asmcfi.h"
 
+#define CONCAT1(a, b) CONCAT2(a, b)
+#define CONCAT2(a, b) a ## b
+
+#ifdef __USER_LABEL_PREFIX__
+#  define SYM(x) CONCAT1 (__USER_LABEL_PREFIX__, x)
+#else
+#  define SYM(x) (x)
+#endif
+
+#ifdef __ELF__
+#  define TYPE(x) .type SYM(x), @function
+#  define SIZE(x) .size SYM(x), . - SYM(x)
+#  define HIDDEN(x) .hidden SYM(x)
+#else
+#  define TYPE(x)
+#  define SIZE(x)
+#  ifdef __MACH__
+#define HIDDEN(x) .private_extern SYM(x)
+#  else
+#define HIDDEN(x)
+#  endif
+#endif
+
.text
 
.align 4
-   .globl  _ITM_beginTransaction
+   .globl  SYM(_ITM_beginTransaction)
 
-_ITM_beginTransaction:
+SYM(_ITM_beginTransaction):
cfi_startproc
 #ifdef __x86_64__
leaq8(%rsp), %rax
@@ -46,7 +69,7 @@
movq%r14, 48(%rsp)
movq%r15, 56(%rsp)
movq%rsp, %rsi
-   callGTM_begin_transaction
+   callSYM(GTM_begin_transaction)
addq$72, %rsp
cfi_def_cfa_offset(8)
ret
@@ -60,22 +83,20 @@
movl%edi, 20(%esp)
movl%ebp, 24(%esp)
leal8(%esp), %edx
-   callGTM_begin_transaction
+   callSYM(GTM_begin_transaction)
addl$28, %esp
cfi_def_cfa_offset(4)
ret
 #endif
cfi_endproc
 
-#ifdef __ELF__
-   .type   _ITM_beginTransaction, @function
-   .size   _ITM_beginTransaction, .-_ITM_beginTransaction
-#endif
+   TYPE(_ITM_beginTransaction)
+   SIZE(_ITM_beginTransaction)
 
.align 4
-   .globl  GTM_longjmp
+   .globl  SYM(GTM_longjmp)
 
-GTM_longjmp:
+SYM(GTM_longjmp):
cfi_startproc
 #ifdef __x86_64__
movq(%rdi), %rcx
@@ -106,11 +127,9 @@
 #endif
cfi_endproc
 
-#ifdef __ELF__
-   .type   GTM_longjmp, @function
-   .hidden GTM_longjmp
-   .size   GTM_longjmp, .-GTM_longjmp
-#endif
+   TYPE(GTM_longjmp)
+   HIDDEN(GTM_longjmp)
+   SIZE(GTM_longjmp)
 
 #ifdef __linux__
 .section .note.GNU-stack, "", @progbits
Index: libitm/libitm_i.h
===
--- libitm/libitm_i.h   (revision 181470)
+++ libitm/libitm_i.h   (working copy)
@@ -240,9 +240,15 @@ struct gtm_thread
 
   // Invoked from assembly language, thus the "asm" specifier on
   // the name, avoiding complex name mangling.
+#ifdef __USER_LABEL_PREFIX__
+#define UPFX1(t) UPFX(t)
+#define UPFX(t) #t
   static uint32_t begin_transaction(uint32_t, const gtm_jmpbuf *)
+   __asm__(UPFX1(__USER_LABEL_PREFIX__) "GTM_begin_transaction") 
ITM_REGPARM;
+#else
+  static uint32_t begin_transaction(uint32_t, const gtm_jmpbuf *)
__asm__("GTM_begin_transaction") ITM_REGPARM;
-
+#endif
   // In eh_cpp.cc
   void revert_cpp_exceptions (gtm_transaction_cp *cp = 0);
 






Re: [C++ Patch] PR 51150

2011-11-18 Thread Jason Merrill

On 11/18/2011 08:57 AM, Paolo Carlini wrote:

On 11/18/2011 02:53 PM, Jason Merrill wrote:

I think let's go straight to cp_build_unary_op from
tsubst_copy_and_build in this case; it can't be overloaded, and we
don't want to mess with build_non_dependent_expr.

Ok. In the meanwhile I actually tested the attached, and it works. Is it
what you have in mind?


That looks the same as the patch I was responding to; I mean to call 
cp_build_unary_op directly rather than build_x_unary_op from 
tsubst_copy_and_build in the FIX_TRUNC_EXPR case.


Jason



Re: Memset/memcpy patch

2011-11-18 Thread Jan Hubicka
> I found another bug in current implementation. A patch for it doesn't
> cure i686-linux- bootstrap, but fixes fails on some tests (see
> attached).
> 
> The problem was that we tried to add runtime tests for alignment even
> if both SRC and DST had unknown alignment - in this case it could be
> impossible to make them both aligned simultaneously, so I think it's
> easier to even not try to use aligned SSE-moves at all. Generation of
> prologues with runtime tests could be used only if at least one
> alignment is known - otherwise it's incorrect. Probably, generation of
> such prologues could be removed from MEMMOV at all for now.

The prologues always align the destination as it helps more than aligning
source on most chips.  I do not see problem with that.  But for SSE either we
should arrange unaligned load opcodes (that is what I see in generated code, 
but I
guess it depends on -march setting) or simply disqualify the sse_loop algorithm
in decide_alg when alignment is not know.
> 
> Though, even with this fix i686-bootstrap still fails. Configure for
> the bootstrap-fail reproducing:
> CC="gcc -m32" CXX="g++ -m32" ../configure --with-arch=core2
> --with-cpu=atom --prefix=`pwd` i686-linux --with-fpmath=sse
> --enable-languages=c,c++,fortran

Default i686-linux bootstrap was working for me. I will try your setting but
my time today evening and at weekend is limited.

Honza


Re: [C++ Patch] PR 51150

2011-11-18 Thread Paolo Carlini

On 11/18/2011 03:11 PM, Jason Merrill wrote:

On 11/18/2011 08:57 AM, Paolo Carlini wrote:

On 11/18/2011 02:53 PM, Jason Merrill wrote:

I think let's go straight to cp_build_unary_op from
tsubst_copy_and_build in this case; it can't be overloaded, and we
don't want to mess with build_non_dependent_expr.

Ok. In the meanwhile I actually tested the attached, and it works. Is it
what you have in mind?
That looks the same as the patch I was responding to; I mean to call 
cp_build_unary_op directly rather than build_x_unary_op from 
tsubst_copy_and_build in the FIX_TRUNC_EXPR case.
Ah ok, I didn't understand in the email client which (patch/message) you 
were responding too, sorry, and couldn't see any other direct call of 
cp_build_unary_op in the whole pt.c, but sure I'll test that.


Thanks,
Paolo.


[Patch libitm/testsuite] MAP_ANON

2011-11-18 Thread Iain Sandoe
For some reason, Darwin spells "MAP_ANONYMOUS" and "MAP_ANON" which  
causes the memcpy/set tests to fail.


fixed as below
OK for trunk?
Iain

libitm:

* testsuite/libitm.c/memcpy-1.c: Allow for MAP_ANON spelling.
* testsuite/libitm.c/memset-1.c: Likewise.

Index: libitm/testsuite/libitm.c/memcpy-1.c
===
--- libitm/testsuite/libitm.c/memcpy-1.c(revision 181470)
+++ libitm/testsuite/libitm.c/memcpy-1.c(working copy)
@@ -84,6 +84,12 @@ do_test (size_t align1, size_t align2, size_t len)
   }
 }
 
+#ifndef MAP_ANONYMOUS
+#  ifdef MAP_ANON
+#define MAP_ANONYMOUS MAP_ANON
+#  endif
+#endif
+
 int main()
 {
   size_t i, j;
Index: libitm/testsuite/libitm.c/memset-1.c
===
--- libitm/testsuite/libitm.c/memset-1.c(revision 181470)
+++ libitm/testsuite/libitm.c/memset-1.c(working copy)
@@ -33,6 +33,12 @@ static unsigned char *buf;
 static size_t bufsize, page_size;
 static int fail;
 
+#ifndef MAP_ANONYMOUS
+#  ifdef MAP_ANON
+#define MAP_ANONYMOUS MAP_ANON
+#  endif
+#endif
+
 static void
 do_test (size_t align, size_t len)
 {






Re: [wwwdocs] add news items for TM work

2011-11-18 Thread Gerald Pfeifer
Hej Aldy,

thanks for doing this.  It is mostly okay, I just have a minor
suggestion or two.

On Tue, 15 Nov 2011, Aldy Hernandez wrote:
> + The project was partially funded by
> + the http://www.velox-project.eu/";>Velox project.  This
> + feature is experimental and is available for C and C++ on selected
> + platforms.

Reading this I was wondering which platforms.  On the other page it
says x86 and alpha; should we just use this here, or were you thinking
to keep this more marketing speak? ;-)

> Index: gcc-4.7/changes.html
> ===
> +   Experimental support for transactional memory has been added.
> +   It includes support for the compiler, as well as a supporting
> +   runtime library called libitm.  To compile code
> +   with transactional memory constructs, use
> +   the -fgnu-tm option.

Put this under ... as well, I think.

> + Support is currently available for the x86 and Alpha platforms.

32-bit, 64-bit x86, or both?

> +   
> + This work was contributed by Red Hat and was partly funded by
> + the http://www.velox-project.eu/";>Velox project.
> +   

In the release notes we generally don't have those acknowledgements,
only in the News section.

Gerald


Re: [PATCH] Incorrect volatile bitfield load-extend

2011-11-18 Thread Richard Earnshaw
On 10/11/11 03:57, Joey Ye wrote:
> Trunk gcc mis-handles following volatile bitfield case on ARM target:
> 
> $ cat a.c
> extern void check(int);
> typedef struct {
>   volatile unsigned short a:8, b:8;
> } BitStruct;
> BitStruct bits = {1, 2};
> int main ()
> {
>   check(bits.a);
>   return 0;
> }
> $ arm-none-eabi-gcc -v 2>&1 |grep "gcc version"
> gcc version 4.7.0 20111024 (experimental) [trunk revision 180388] (GCC) 
> $ arm-none-eabi-gcc -S a.c -mthumb -mcpu=cortex-m3
> $ grep -v "^\s*\." a.s
> bits:
> main:
>   @ args = 0, pretend = 0, frame = 0
>   @ frame_needed = 1, uses_anonymous_args = 0
>   push{r7, lr}
>   add r7, sp, #0
>   movwr3, #:lower16:bits
>   movtr3, #:upper16:bits
>   ldrhr3, [r3, #0]@ movhi
>   uxthr3, r3  // Should be uxtb here. As a result,
> // the output becomes 2056, instead of 8 as expected
>   mov r0, r3
>   bl  check
>   mov r3, #0
>   mov r0, r3
>   pop {r7, pc}
> 
> Root cause is that when restrict-volatile-bitfields is enabled, which is ARM
> default. Volatile bitfields isn't loaded as bitfield even if bitfield size
> is less than load size.
> 
> It is actually a regression introduced by:
> http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01477.html
> 
> 
> Patch to fix this:
> 2011-11-10  Joey Ye  
> 
> Fix volatile bitfield load
> * gcc/expr.c (expand_expr_real_1): Check bitfield size
>   smaller than mode size.

Normally it would be best to write

* expr.c (expand_expr_real_1): Correctly handle strict volatile
bitfield loads smaller than mode size.


> 
> Testcase:
> 2011-11-10  Joey Ye  
> 
> * gcc.dg/volatile-bitfields-1.c: New.
> 

OK.

R.



Re: [Patch RFA libitm] config-based assessment of weakref capability

2011-11-18 Thread Jack Howarth
On Fri, Nov 18, 2011 at 01:44:40PM +, Iain Sandoe wrote:
> Hi,
>
> one of the three remaining libitm issues for Darwin is to supply the  
> dummy funcs fro the weakrefs (as Rainer has done for Tru64) for the  
> versions of Darwin that need them.
>
> Since we now have the situation where there are several targets which  
> might need dummy functions for the weak declarations, it seemed worth  
> trying to auto-foo this.
>
> .. the attached works for me on Darwin9 (weakref doesn't work like  
> elf***) and Darwin10+XCode3.2.5 (weakref works like elf)
>
> I hope it also works for Rainer  and that I've got the right  
> designator for the Tru64 cross-case.

Iain,
What steps are you taking to regenerate configure inside of libitm?
I am trying...

automake-1.11
autoconf -I. -I./config

but this fails with...

configure.ac:166: error: possibly undefined macro: GCC_AC_FUNC_MMAP_BLACKLIST
  If this token and others are legitimate, please use m4_pattern_allow.
  See the Autoconf documentation.

when using automake 1.11.1 and autoconf 2.64. Are you able to manually
regenerate configure or are you depending on --enable-maintainer-mode?
   Jack
>
> comments/OK for trunk?
> Iain
>
> *** 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).
>
> -
>
> libitm:
>
>   * acinclude.m4 (LIBITM_CHECK_WORKING_WEAKREF): New.
>   * configure.ac: Use LIBITM_CHECK_WORKING_WEAKREF.
>   * alloc_cpp.cc: Generate dummy functions if we don't
>   HAVE_WORKING_WEAKREF.
>   * eh_cpp.cc: Likewise.
>   * configure: Regenerate.
>   * aclocal.m4:  Likewise.
>   * config.h.in: Likewise.
>

> Index: libitm/acinclude.m4
> ===
> --- libitm/acinclude.m4   (revision 181470)
> +++ libitm/acinclude.m4   (working copy)
> @@ -109,6 +109,29 @@ i[[34567]]86 | x86_64)
>;;
>  esac])
>  
> +dnl Check whether weak refs actually work.
> +AC_DEFUN([LIBITM_CHECK_WORKING_WEAKREF], [
> +  AC_CACHE_CHECK([whether weak refs actually work],
> +  libitm_cv_have_working_weakref, [
> +  AC_RUN_IFELSE([AC_LANG_SOURCE([[
> +extern void fNotToBeFoundInAnyStandardLib(void) __attribute__((weak));
> +int main () 
> +{
> +  if (fNotToBeFoundInAnyStandardLib)
> +return 0;
> +  else
> +return 1;
> +}
> +}]])], libitm_cv_have_working_weakref=yes, 
> libitm_cv_have_working_weakref=no, [
> +case "${host}" in
> +  alpha*-dec-osf*) libitm_cv_have_working_weakref=no ;;
> +  *-apple-darwin[[89]]*) libitm_cv_have_working_weakref=no ;;
> +  *) libitm_cv_have_working_weakref=yes;;
> +esac])])
> +if test x"$libitm_cv_have_working_weakref" = xyes; then
> +  AC_DEFINE(HAVE_WORKING_WEAKREF, 1, [Define to 1 if target has a working 
> weakref.])
> +fi])
> +
>  sinclude(../libtool.m4)
>  dnl The lines below arrange for aclocal not to bring an installed
>  dnl libtool.m4 into aclocal.m4, while still arranging for automake to
> Index: libitm/configure.ac
> ===
> --- libitm/configure.ac   (revision 181470)
> +++ libitm/configure.ac   (working copy)
> @@ -238,6 +238,7 @@ CFLAGS="$save_CFLAGS $XCFLAGS"
>  LIBITM_CHECK_SYNC_BUILTINS
>  LIBITM_CHECK_64BIT_SYNC_BUILTINS
>  LIBITM_CHECK_AS_AVX
> +LIBITM_CHECK_WORKING_WEAKREF
>  
>  # Cleanup and exit.
>  CFLAGS="$save_CFLAGS"
> Index: libitm/alloc_cpp.cc
> ===
> --- libitm/alloc_cpp.cc   (revision 181470)
> +++ libitm/alloc_cpp.cc   (working copy)
> @@ -60,7 +60,7 @@ extern void _ZdlPvRKSt9nothrow_t (void *, c_nothro
>  extern void *_ZnaXRKSt9nothrow_t (size_t, c_nothrow_p) __attribute__((weak));
>  extern void _ZdaPvRKSt9nothrow_t (void *, c_nothrow_p) __attribute__((weak));
>  
> -#ifdef __osf__ /* Really: !HAVE_WEAKDEF  */
> +#if !defined (HAVE_WORKING_WEAKREF)
>  void *_ZnwX (size_t) { return NULL; }
>  void _ZdlPv (void *) { return; }
>  void *_ZnaX (size_t) { return NULL; }
> @@ -70,7 +70,7 @@ void *_ZnwXRKSt9nothrow_t (size_t, c_nothrow_p) {
>  void _ZdlPvRKSt9nothrow_t (void *, c_nothrow_p) { return; }
>  void *_ZnaXRKSt9nothrow_t (size_t, c_nothrow_p) { return NULL; }
>  void _ZdaPvRKSt9nothrow_t (void *, c_nothrow_p) { return; }
> -#endif /* __osf__ */
> +#endif /* HAVE_WORKING_WEAKREF */
>  
>  /* Wrap the delete nothrow symbols for usage with a single argument.
> Perhaps should have a configure type check for this, because the
> Index: libitm/eh_cpp.cc
> ===
> --- libitm/eh_cpp.cc  (revision 181470)
> +++ libitm/eh_cpp.cc  (working copy)
> @@ -39,13 +39,13 @@ extern void *__cxa_begin_catch (void *) WEAK;
>  extern void *__cxa_end_catch (void) WEAK;
>  extern void __cxa_tm_cleanup (void *, void *, un

Re: [Patch RFA libitm] config-based assessment of weakref capability

2011-11-18 Thread Iain Sandoe


On 18 Nov 2011, at 14:40, Jack Howarth wrote:


On Fri, Nov 18, 2011 at 01:44:40PM +, Iain Sandoe wrote:

Hi,

one of the three remaining libitm issues for Darwin is to supply the
dummy funcs fro the weakrefs (as Rainer has done for Tru64) for the
versions of Darwin that need them.

Since we now have the situation where there are several targets which
might need dummy functions for the weak declarations, it seemed worth
trying to auto-foo this.

.. the attached works for me on Darwin9 (weakref doesn't work like
elf***) and Darwin10+XCode3.2.5 (weakref works like elf)

I hope it also works for Rainer  and that I've got the right
designator for the Tru64 cross-case.


Iain,
   What steps are you taking to regenerate configure inside of libitm?


aclocal -I. -I.. -I..config
autoheader
automake
autoconf -I. -I.. -I..config

... you should be able to do this and then:
 delete your existing libitm build.
 make configure-target-libitm

... and then I would hope (from our other discussions) you should see  
that it says

checking if weakref actually works ... no
... for D11/XC4.2


I am trying...

automake-1.11
autoconf -I. -I./config

but this fails with...

configure.ac:166: error: possibly undefined macro:  
GCC_AC_FUNC_MMAP_BLACKLIST
 If this token and others are legitimate, please use  
m4_pattern_allow.

 See the Autoconf documentation.

when using automake 1.11.1 and autoconf 2.64. Are you able to manually
regenerate configure or are you depending on --enable-maintainer-mode?
  Jack


comments/OK for trunk?
Iain

*** 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).

-

libitm:

* acinclude.m4 (LIBITM_CHECK_WORKING_WEAKREF): New.
* configure.ac: Use LIBITM_CHECK_WORKING_WEAKREF.
* alloc_cpp.cc: Generate dummy functions if we don't
HAVE_WORKING_WEAKREF.
* eh_cpp.cc: Likewise.
* configure: Regenerate.
* aclocal.m4:  Likewise.
* config.h.in: Likewise.




Index: libitm/acinclude.m4
===
--- libitm/acinclude.m4 (revision 181470)
+++ libitm/acinclude.m4 (working copy)
@@ -109,6 +109,29 @@ i[[34567]]86 | x86_64)
  ;;
esac])

+dnl Check whether weak refs actually work.
+AC_DEFUN([LIBITM_CHECK_WORKING_WEAKREF], [
+  AC_CACHE_CHECK([whether weak refs actually work],
+  libitm_cv_have_working_weakref, [
+  AC_RUN_IFELSE([AC_LANG_SOURCE([[
+extern void fNotToBeFoundInAnyStandardLib(void)  
__attribute__((weak));

+int main ()
+{
+  if (fNotToBeFoundInAnyStandardLib)
+return 0;
+  else
+return 1;
+}
+}]])], libitm_cv_have_working_weakref=yes,  
libitm_cv_have_working_weakref=no, [

+case "${host}" in
+  alpha*-dec-osf*) libitm_cv_have_working_weakref=no ;;
+  *-apple-darwin[[89]]*) libitm_cv_have_working_weakref=no ;;
+  *) libitm_cv_have_working_weakref=yes;;
+esac])])
+if test x"$libitm_cv_have_working_weakref" = xyes; then
+  AC_DEFINE(HAVE_WORKING_WEAKREF, 1, [Define to 1 if target has a  
working weakref.])

+fi])
+
sinclude(../libtool.m4)
dnl The lines below arrange for aclocal not to bring an installed
dnl libtool.m4 into aclocal.m4, while still arranging for automake to
Index: libitm/configure.ac
===
--- libitm/configure.ac (revision 181470)
+++ libitm/configure.ac (working copy)
@@ -238,6 +238,7 @@ CFLAGS="$save_CFLAGS $XCFLAGS"
LIBITM_CHECK_SYNC_BUILTINS
LIBITM_CHECK_64BIT_SYNC_BUILTINS
LIBITM_CHECK_AS_AVX
+LIBITM_CHECK_WORKING_WEAKREF

# Cleanup and exit.
CFLAGS="$save_CFLAGS"
Index: libitm/alloc_cpp.cc
===
--- libitm/alloc_cpp.cc (revision 181470)
+++ libitm/alloc_cpp.cc (working copy)
@@ -60,7 +60,7 @@ extern void _ZdlPvRKSt9nothrow_t (void *, c_nothro
extern void *_ZnaXRKSt9nothrow_t (size_t, c_nothrow_p)  
__attribute__((weak));
extern void _ZdaPvRKSt9nothrow_t (void *, c_nothrow_p)  
__attribute__((weak));


-#ifdef __osf__ /* Really: !HAVE_WEAKDEF  */
+#if !defined (HAVE_WORKING_WEAKREF)
void *_ZnwX (size_t) { return NULL; }
void _ZdlPv (void *) { return; }
void *_ZnaX (size_t) { return NULL; }
@@ -70,7 +70,7 @@ void *_ZnwXRKSt9nothrow_t (size_t, c_nothrow_p) {
void _ZdlPvRKSt9nothrow_t (void *, c_nothrow_p) { return; }
void *_ZnaXRKSt9nothrow_t (size_t, c_nothrow_p) { return NULL; }
void _ZdaPvRKSt9nothrow_t (void *, c_nothrow_p) { return; }
-#endif /* __osf__ */
+#endif /* HAVE_WORKING_WEAKREF */

/* Wrap the delete nothrow symbols for usage with a single argument.
   Perhaps should have a configure type check for this, because the
Index: libitm/eh_cpp.cc
===
--- libitm/eh_cpp.cc(revision 181470)
+++ libitm/eh_cpp.cc(working copy)
@@ -39,13 +39,13 @@ extern v

Re: [PATCH, debug] Emit basic block markers in .debug_line section

2011-11-18 Thread Tom Tromey
> "Roberto" == Roberto Agostino Vitillo  writes:

Roberto> I ended up not using it and it's clear to me that its practical
Roberto> uses may be questionable ("fast" single stepping in a
Roberto> debugger?) but I thought it might be worth to share it.

Thanks.

I think that if there is no use for the output, then the patch should
not go in.

Tom


Re: [Patch RFA libitm] config-based assessment of weakref capability

2011-11-18 Thread Rainer Orth
Hi Iain,

> one of the three remaining libitm issues for Darwin is to supply the dummy
> funcs fro the weakrefs (as Rainer has done for Tru64) for the  versions of
> Darwin that need them.
>
> Since we now have the situation where there are several targets which might
> need dummy functions for the weak declarations, it seemed worth  trying to
> auto-foo this.
>
> .. the attached works for me on Darwin9 (weakref doesn't work like elf***)
> and Darwin10+XCode3.2.5 (weakref works like elf)
>
> I hope it also works for Rainer  and that I've got the right designator
> for the Tru64 cross-case.

I guess it does, given that the testcase is based on my own one :-)

A few comments:

* Move the macro definition to toplevel config/weakref.m4 (or
  weakdef.m4, I'm not sure about the terminology), omitting the libitm
  reference.   libgfortran already uses something similar (although
  partially hardcoded), we should share the code (not now, but in the
  future).

* Omit the _working_ everywhere, we don't care for non-working
  variants.

> Index: libitm/acinclude.m4
> ===
> --- libitm/acinclude.m4   (revision 181470)
> +++ libitm/acinclude.m4   (working copy)
> @@ -109,6 +109,29 @@ i[[34567]]86 | x86_64)
>;;
>  esac])
>  
> +dnl Check whether weak refs actually work.
> +AC_DEFUN([LIBITM_CHECK_WORKING_WEAKREF], [
> +  AC_CACHE_CHECK([whether weak refs actually work],
> +  libitm_cv_have_working_weakref, [
> +  AC_RUN_IFELSE([AC_LANG_SOURCE([[
> +extern void fNotToBeFoundInAnyStandardLib(void) __attribute__((weak));
> +int main () 
> +{
> +  if (fNotToBeFoundInAnyStandardLib)
> +return 0;
> +  else
> +return 1;
> +}

Just a nit: shorten function name to keep it readable.

Rainer

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


Re: [Patch]: PR49868: Named address space support for AVR, #5

2011-11-18 Thread Denis Chertykov
2011/11/17 Georg-Johann Lay :
> Denis Chertykov wrote:
>
>> Let's wait for
>> http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01874.html
>> Denis.
>
> This are yet more intrinsic named address spaces:
>
> * __pgm1, ... __pgm5 are 16-bit address spaces that refer to
>  the n-th 64k chunk of flash. Counting starts at 0.
>  The 0-th address space __pgm is already upstream.
>
> * __pgmx is a 24-bit address space located in flash.
>
>
> The annoyance in this patch is the movmemhi insn:
>
> * Register allocator does a bad job and might lead to spills
>  inside the copy loop so that it is no more guaranteed that
>  tmp_reg contains the value to be copied because move insns
>  use that register implicitly.  Besides that, spilling in
>  the copy loop leads to unfortunate code. See respective
>  FIXMEs in avr.c:avr_emit_movmemhi()
>
> * Using match_dup in respective patterns shreds web.c to that
>  the insns need up to with 11 operands.
>
> Besides that there are caveats and binutils is missing some support:
>
> * To place variables in __pgm1 ... __pgm5 in appropriate sections
>  a custom linker script is needed.  Data is put in sections
>  progmem1.data ... __progmem5.data, respectively, and these
>  sections must be treated in the linker script.
>
> * Address computation for the 24-bit address space is performed
>  as signed 16-bit.  Thus, accessing an array var[i] for example
>  it is not possible to reach locations that are farther away
>  than +/- 32768 bytes from var[0].
>
> * It is not possible to assemble a 24-bit address, see the
>  assembler warning generated in avr.c:avr_assemble_integer().
>
>  This warning is triggered for code like
>
>        extern const __pgmx int ivar;
>        const __pgmx void * var = &ivar;
>
>        .global var
>                .data
>                .type   var, @object
>                .size   var, 3
>        var:
>                .word   ivar
>                .warning        "24-bit address needs binutils extension for 
> hh8(ivar)"
>                .byte   0        ;  hh8(ivar)
>
>
>
> The patch passes C tests with one FAIL less (SVN 181349):
>
> gcc.dg/pr43300.c (internal compiler error)
>
> ./gcc.dg/pr43300.c: In function 'foo':
> ./gcc.dg/pr43300.c:19:1: internal compiler error: in 
> commit_one_edge_insertion,
> at cfgrtl.c:1582
>
> This tests passes now; seems that the changes to movmemhi allow that test to
> PASS now (for whatever reason).
>
> Ok for trunk?
>
> Johann
>
> gcc/
>        PR target/49868
>        * config/avr/avr.h (base_arch_s): Add field n_segments.
>        (ADDR_SPACE_PGM1, ADDR_SPACE_PGM2, ADDR_SPACE_PGM3,
>        ADDR_SPACE_PGM4, ADDR_SPACE_PGM5, ADDR_SPACE_PGMX): New address spaces.
>        (AVR_HAVE_ELPM, AVR_HAVE_ELPMX): New defines.
>        (INIT_EXPANDERS): New define.
>        * config/avr/avr-protos.h (avr_mem_pgmx_p): New.
>        (avr_init_expanders): New.
>        (avr_emit_movmemhi, avr_out_movmem): New.
>        (avr_xload_libgcc_p): New.
>        * config/avr/avr-c.c (avr_register_target_pragmas): Register
>        address spaces __pgm1, __pgm2,  __pgm3,  __pgm4  __pgm5,  __pgmx.
>        (avr_cpu_cpp_builtins): Add built-in defines __PGM1,
>        __PGM2, __PGM3, __PGM4, __PGM5, __PGMX.
>        * config/avr/avr-devices.c (avr_arch_types): Set field n_segments.
>
>        * config/avr/avr.c (AVR_SECTION_PROGMEM): Change define to cover
>        3 bits instead of just 1.
>        (xstring_empty, xstring_e, rampz_rtx): New static GTYed variables.
>        (progmem_section): Change from section to array of sections.
>        (progmem_section_prefix): New static variable.
>        (avr_file_start): Print set for __RAMPZ__
>        (avr_option_override): Move initialization of RTXes from here...
>        (avr_init_expanders): ...to this new function.
>        (avr_pgm_segment): New static function.
>        (avr_decl_pgm_p): Handle error_mark_node.
>        (avr_mem_pgmx_p, avr_decl_pgmx_p): New static functions.
>        (avr_out_xload, avr_find_unused_d_reg): New static functions.
>        (expand_prologue, expand_epilogue): Use rampz_rtx.
>        (print_operand): Hande CONST_STRING.
>        (avr_xload_libgcc_p): New static function.
>        (avr_out_lpm_no_lpmx, avr_out_lpm): Handle ELPM.
>        (avr_progmem_p): Return 2 for 24-bit flash address space.
>        (avr_out_sbxx_branch): Clean-up code from ASn macros.
>        (out_movqi_r_mr, out_movqi_mr_r): Ditto. And recognize RAMPZ's
>        address and print symbolically.
>        (avr_asm_named_section, avr_section_type_flags,
>        avr_encode_section_info, avr_asm_select_section,
>        avr_addr_space_address_mode, avr_addr_space_pointer_mode,
>        avr_addr_space_legitimate_address_p, avr_addr_space_convert,
>        avr_addr_space_legitimize_address): Handle new address spaces.
>        (avr_output_progmem_section_asm_op): New static function.
>        (avr_asm_init_sections): Initialize progmem_section[].
>        (adjust_insn_length): Handle ADJUST_LEN_XLOAD, ADJ

Re: [C++ Patch] PR 51150

2011-11-18 Thread Paolo Carlini

On 11/18/2011 03:19 PM, Paolo Carlini wrote:

On 11/18/2011 03:11 PM, Jason Merrill wrote:

On 11/18/2011 08:57 AM, Paolo Carlini wrote:

On 11/18/2011 02:53 PM, Jason Merrill wrote:

I think let's go straight to cp_build_unary_op from
tsubst_copy_and_build in this case; it can't be overloaded, and we
don't want to mess with build_non_dependent_expr.
Ok. In the meanwhile I actually tested the attached, and it works. 
Is it

what you have in mind?
That looks the same as the patch I was responding to; I mean to call 
cp_build_unary_op directly rather than build_x_unary_op from 
tsubst_copy_and_build in the FIX_TRUNC_EXPR case.
Ah ok, I didn't understand in the email client which (patch/message) 
you were responding too, sorry, and couldn't see any other direct call 
of cp_build_unary_op in the whole pt.c, but sure I'll test that.

Tested the below (x86_64-linux, as usual). Ok mainline and 4_6?

Thanks,
Paolo.


/cp
2011-11-18  Paolo Carlini  

PR c++/51150
* pt.c (tsubst_copy_and_build): Handle FIX_TRUNC_EXPR.

/testsuite
2011-11-18  Paolo Carlini  

PR c++/51150
* g++.dg/cpp0x/pr51150.C: New.
Index: testsuite/g++.dg/cpp0x/pr51150.C
===
--- testsuite/g++.dg/cpp0x/pr51150.C(revision 0)
+++ testsuite/g++.dg/cpp0x/pr51150.C(revision 0)
@@ -0,0 +1,20 @@
+// PR c++/51150
+// { dg-options "-std=c++0x" }
+
+struct Clock {
+  double Now();
+};
+template  void Foo(Clock* clock) {
+  const int now = clock->Now();
+}
+
+template void Foo(Clock*);
+
+template  void Boo(int val) {
+  const int now1 = (double)(val);
+  const int now2 = const_cast(val); // { dg-error "invalid" }
+  const int now3 = static_cast(val);
+  const int now4 = reinterpret_cast(val); // { dg-error "invalid" }
+}
+
+template void Boo(int);
Index: cp/pt.c
===
--- cp/pt.c (revision 181476)
+++ cp/pt.c (working copy)
@@ -13387,6 +13387,10 @@ tsubst_copy_and_build (tree t,
   return build_x_unary_op (TREE_CODE (t), RECUR (TREE_OPERAND (t, 0)),
complain);
 
+case FIX_TRUNC_EXPR:
+  return cp_build_unary_op (FIX_TRUNC_EXPR, RECUR (TREE_OPERAND (t, 0)),
+   0, complain);
+
 case ADDR_EXPR:
   op1 = TREE_OPERAND (t, 0);
   if (TREE_CODE (op1) == LABEL_DECL)


Re: [C++ Patch] PR 51150

2011-11-18 Thread Jason Merrill

OK.

Jason


Re: [Patch RFA libitm] config-based assessment of weakref capability

2011-11-18 Thread Jack Howarth
On Fri, Nov 18, 2011 at 02:43:58PM +, Iain Sandoe wrote:
>
> On 18 Nov 2011, at 14:40, Jack Howarth wrote:
>
>> On Fri, Nov 18, 2011 at 01:44:40PM +, Iain Sandoe wrote:
>>> Hi,
>>>
>>> one of the three remaining libitm issues for Darwin is to supply the
>>> dummy funcs fro the weakrefs (as Rainer has done for Tru64) for the
>>> versions of Darwin that need them.
>>>
>>> Since we now have the situation where there are several targets which
>>> might need dummy functions for the weak declarations, it seemed worth
>>> trying to auto-foo this.
>>>
>>> .. the attached works for me on Darwin9 (weakref doesn't work like
>>> elf***) and Darwin10+XCode3.2.5 (weakref works like elf)
>>>
>>> I hope it also works for Rainer  and that I've got the right
>>> designator for the Tru64 cross-case.
>>
>> Iain,
>>What steps are you taking to regenerate configure inside of libitm?
>
> aclocal -I. -I.. -I..config
> autoheader
> automake
> autoconf -I. -I.. -I..config
>
> ... you should be able to do this and then:
>  delete your existing libitm build.
>  make configure-target-libitm
>
> ... and then I would hope (from our other discussions) you should see  
> that it says
> checking if weakref actually works ... no
> ... for D11/XC4.2
>

Would appear to be as the config.h generated in x86_64-apple-darwin11.2.0/libitm
has...

/* Define to 1 if target has a working weakref. */
/* #undef HAVE_WORKING_WEAKREF */

>> I am trying...
>>
>> automake-1.11
>> autoconf -I. -I./config
>>
>> but this fails with...
>>
>> configure.ac:166: error: possibly undefined macro:  
>> GCC_AC_FUNC_MMAP_BLACKLIST
>>  If this token and others are legitimate, please use  
>> m4_pattern_allow.
>>  See the Autoconf documentation.
>>
>> when using automake 1.11.1 and autoconf 2.64. Are you able to manually
>> regenerate configure or are you depending on --enable-maintainer-mode?
>>   Jack
>>>
>>> comments/OK for trunk?
>>> Iain
>>>
>>> *** 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).
>>>
>>> -
>>>
>>> libitm:
>>>
>>> * acinclude.m4 (LIBITM_CHECK_WORKING_WEAKREF): New.
>>> * configure.ac: Use LIBITM_CHECK_WORKING_WEAKREF.
>>> * alloc_cpp.cc: Generate dummy functions if we don't
>>> HAVE_WORKING_WEAKREF.
>>> * eh_cpp.cc: Likewise.
>>> * configure: Regenerate.
>>> * aclocal.m4:  Likewise.
>>> * config.h.in: Likewise.
>>>
>>
>>> Index: libitm/acinclude.m4
>>> ===
>>> --- libitm/acinclude.m4 (revision 181470)
>>> +++ libitm/acinclude.m4 (working copy)
>>> @@ -109,6 +109,29 @@ i[[34567]]86 | x86_64)
>>>   ;;
>>> esac])
>>>
>>> +dnl Check whether weak refs actually work.
>>> +AC_DEFUN([LIBITM_CHECK_WORKING_WEAKREF], [
>>> +  AC_CACHE_CHECK([whether weak refs actually work],
>>> +  libitm_cv_have_working_weakref, [
>>> +  AC_RUN_IFELSE([AC_LANG_SOURCE([[
>>> +extern void fNotToBeFoundInAnyStandardLib(void)  
>>> __attribute__((weak));
>>> +int main ()
>>> +{
>>> +  if (fNotToBeFoundInAnyStandardLib)
>>> +return 0;
>>> +  else
>>> +return 1;
>>> +}
>>> +}]])], libitm_cv_have_working_weakref=yes,  
>>> libitm_cv_have_working_weakref=no, [
>>> +case "${host}" in
>>> +  alpha*-dec-osf*) libitm_cv_have_working_weakref=no ;;
>>> +  *-apple-darwin[[89]]*) libitm_cv_have_working_weakref=no ;;
>>> +  *) libitm_cv_have_working_weakref=yes;;
>>> +esac])])
>>> +if test x"$libitm_cv_have_working_weakref" = xyes; then
>>> +  AC_DEFINE(HAVE_WORKING_WEAKREF, 1, [Define to 1 if target has a  
>>> working weakref.])
>>> +fi])
>>> +
>>> sinclude(../libtool.m4)
>>> dnl The lines below arrange for aclocal not to bring an installed
>>> dnl libtool.m4 into aclocal.m4, while still arranging for automake to
>>> Index: libitm/configure.ac
>>> ===
>>> --- libitm/configure.ac (revision 181470)
>>> +++ libitm/configure.ac (working copy)
>>> @@ -238,6 +238,7 @@ CFLAGS="$save_CFLAGS $XCFLAGS"
>>> LIBITM_CHECK_SYNC_BUILTINS
>>> LIBITM_CHECK_64BIT_SYNC_BUILTINS
>>> LIBITM_CHECK_AS_AVX
>>> +LIBITM_CHECK_WORKING_WEAKREF
>>>
>>> # Cleanup and exit.
>>> CFLAGS="$save_CFLAGS"
>>> Index: libitm/alloc_cpp.cc
>>> ===
>>> --- libitm/alloc_cpp.cc (revision 181470)
>>> +++ libitm/alloc_cpp.cc (working copy)
>>> @@ -60,7 +60,7 @@ extern void _ZdlPvRKSt9nothrow_t (void *, c_nothro
>>> extern void *_ZnaXRKSt9nothrow_t (size_t, c_nothrow_p)  
>>> __attribute__((weak));
>>> extern void _ZdaPvRKSt9nothrow_t (void *, c_nothrow_p)  
>>> __attribute__((weak));
>>>
>>> -#ifdef __osf__ /* Really: !HAVE_WEAKDEF  */
>>> +#if !defined (HAVE_WORKING_WEAKREF)
>>> void *_ZnwX (size_t) { return NULL; }
>>> void _ZdlPv (void *) { retur

Re: [Patch RFA libitm] config-based assessment of weakref capability

2011-11-18 Thread Iain Sandoe

Hi Rainer,

On 18 Nov 2011, at 14:49, Rainer Orth wrote:


I hope it also works for Rainer  and that I've got the right  
designator

for the Tru64 cross-case.


I guess it does, given that the testcase is based on my own one :-)


so long as my wrapping it in m4 hasn't broken the intent .. ;-)


* Move the macro definition to toplevel config/weakref.m4 (or
 weakdef.m4,


I think we're checking the ref side here.


I'm not sure about the terminology), omitting the libitm
 reference.   libgfortran already uses something similar (although
 partially hardcoded), we should share the code (not now, but in the
 future).


In that case, perhaps we should say that this is specifically checking  
for a weakref with elf-like behavior.


Otherwise, if the code is re-used, someone might risk concluding that  
(for example) Darwin had no weakref at all (which is not the case, it  
just doesn't behave in the same manner as the ELF one).


so perhaps HAVE_ELF_STYLE_WEAKREF


* Omit the _working_ everywhere, we don't care for non-working
 variants.


good point.


Index: libitm/acinclude.m4
===
--- libitm/acinclude.m4 (revision 181470)
+++ libitm/acinclude.m4 (working copy)
@@ -109,6 +109,29 @@ i[[34567]]86 | x86_64)
  ;;
esac])

+dnl Check whether weak refs actually work.
+AC_DEFUN([LIBITM_CHECK_WORKING_WEAKREF], [
+  AC_CACHE_CHECK([whether weak refs actually work],
+  libitm_cv_have_working_weakref, [
+  AC_RUN_IFELSE([AC_LANG_SOURCE([[
+extern void fNotToBeFoundInAnyStandardLib(void)  
__attribute__((weak));

+int main ()
+{
+  if (fNotToBeFoundInAnyStandardLib)
+return 0;
+  else
+return 1;
+}


Just a nit: shorten function name to keep it readable.


OK, I suppose that there's no guarantee (however long the name) that a  
given symbol can't appear in a std lib..


thanks for reviewing
Iain



[v3] libstdc++/51209

2011-11-18 Thread Paolo Carlini

Hi,

tested x86_64-linux, committed to mainline.

Paolo.

/
2011-11-18  Harti Brandt  

PR libstdc++/51209
* include/bits/hashtable.h (_Hashtable<>::_M_find_node): Return
nullptr when no node is found.
* include/tr1/hashtable.h (_Hashtable<>::_M_find_node): Return
zero when no node is found.
Index: include/bits/hashtable.h
===
--- include/bits/hashtable.h(revision 181477)
+++ include/bits/hashtable.h(working copy)
@@ -873,7 +873,7 @@
 }
 
   // Find the node whose key compares equal to k, beginning the search
-  // at p (usually the head of a bucket).  Return nil if no node is found.
+  // at p (usually the head of a bucket).  Return nullptr if no node is found.
   template_M_next)
if (this->_M_compare(__k, __code, __p))
  return __p;
-  return false;
+  return nullptr;
 }
 
   // Insert v in bucket n (assumes no element with its key already present).
Index: include/tr1/hashtable.h
===
--- include/tr1/hashtable.h (revision 181477)
+++ include/tr1/hashtable.h (working copy)
@@ -813,7 +813,7 @@
 }
 
   // Find the node whose key compares equal to k, beginning the search
-  // at p (usually the head of a bucket).  Return nil if no node is found.
+  // at p (usually the head of a bucket).  Return zero if no node is found.
   template_M_next)
if (this->_M_compare(__k, __code, __p))
  return __p;
-  return false;
+  return 0;
 }
 
   // Insert v in bucket n (assumes no element with its key already present).


Re: [libitm] Support Solaris 8 and 9/x86 with Sun as

2011-11-18 Thread Rainer Orth
Richard Henderson  writes:

> On 11/16/2011 08:38 AM, Rainer Orth wrote:
>>  * config/generic/asmcfi.h: Fix comment.
>>  * config/x86/sjlj.S (_ITM_beginTransaction): Provide PIC code
>>  sequence without .hidden support.
>>  (GTM_longjmp) [__ELF__]: Only use .hidden if
>>  HAVE_ATTRIBUTE_VISIBILITY.
>
> Nearly ok.
>
>> +subl$4, %esp
>> +movl%ebx, 24(%esp)
>> +call1f
>> +1:  popl%ebx
>> +addl$_GLOBAL_OFFSET_TABLE_+[.-1b], %ebx
>> +callGTM_begin_transaction@PLT
>> +movl24(%esp), %ebx
>> +addl$4, %esp
>
> This is overly complicated.  We've saved %ebx at 12(%esp) above.
> This should be as simple as
>
>   call1f
> 1:popl%ebx
>   addl$_GLOBAL_OFFSET_TABLE_+[.-1b], %ebx
>   callGTM_begin_transaction@PLT
>   movl12(%esp), %ebx
>
> It also needs wrapping like
>
> #elif defined(__ELF__)
>   ...
> #else
> # error "Unsupported PIC sequence"
> #endif
>
> ... which will almost certainly immediately fail on Darwin, but
> at least not with some reference to @PLT.

Here's what I've installed after re-bootstrapping on
i386-pc-solaris2.{8, 9, 10, 11} with both Sun as and gas.

Rainer


2011-11-14  Rainer Orth  

* config/generic/asmcfi.h: Fix comment.
* config/x86/sjlj.S (_ITM_beginTransaction): Provide ELF PIC code
sequence without .hidden support, error for non-ELF targets.
(GTM_longjmp) [__ELF__]: Only use .hidden if
HAVE_ATTRIBUTE_VISIBILITY.

# HG changeset patch
# Parent 3173fc5da3ec7582cb682ba14d4acc6bcc44a0e0
Support Solaris 8 and 9/x86 with Sun as

diff --git a/libitm/config/generic/asmcfi.h b/libitm/config/generic/asmcfi.h
--- a/libitm/config/generic/asmcfi.h
+++ b/libitm/config/generic/asmcfi.h
@@ -41,4 +41,4 @@
 #define cfi_def_cfa(r,n)
 #define cfi_register(o,n)
 
-#endif /* HAVE_ASM_CFI */
+#endif /* HAVE_AS_CFI_PSEUDO_OP */
diff --git a/libitm/config/x86/sjlj.S b/libitm/config/x86/sjlj.S
--- a/libitm/config/x86/sjlj.S
+++ b/libitm/config/x86/sjlj.S
@@ -60,7 +60,17 @@ _ITM_beginTransaction:
 	movl	%edi, 20(%esp)
 	movl	%ebp, 24(%esp)
 	leal	8(%esp), %edx
+#if defined HAVE_ATTRIBUTE_VISIBILITY || !defined __PIC__
 	call	GTM_begin_transaction
+#elif defined __ELF__
+	call	1f
+1:	popl	%ebx
+	addl	$_GLOBAL_OFFSET_TABLE_+[.-1b], %ebx
+	call	GTM_begin_transaction@PLT
+	movl	12(%esp), %ebx
+#else
+# error "Unsupported PIC sequence"
+#endif
 	addl	$28, %esp
 	cfi_def_cfa_offset(4)
 	ret
@@ -108,7 +118,9 @@ GTM_longjmp:
 
 #ifdef __ELF__
 	.type	GTM_longjmp, @function
+#ifdef HAVE_ATTRIBUTE_VISIBILITY
 	.hidden	GTM_longjmp
+#endif
 	.size	GTM_longjmp, .-GTM_longjmp
 #endif
 

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


Re: [Patch RFA libitm] config-based assessment of weakref capability

2011-11-18 Thread Jack Howarth
Iain,
   For gcc trunk at r181476 with 181473-libitm-config-weakref.txt, 
181473-libitm-tests-mapanon.txt
and 181473-libitm-user-label-prefix.txt as well as the regenerations performed 
in libitm, I see
the following failures on x86_64-apple-darwin11 under Xcode 4.2...

Running target unix/-m32
Using /sw/share/dejagnu/baseboards/unix.exp as board description file for 
target.
Using /sw/share/dejagnu/config/unix.exp as generic interface file for target.
Using 
/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-2018/libitm/testsuite/config/default.exp
 as tool-and-target-specific interface file.
Running 
/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-2018/libitm/testsuite/libitm.c/c.exp
 ...
FAIL: libitm.c/cancel.c (test for excess errors)
WARNING: libitm.c/cancel.c compilation failed to produce executable
FAIL: libitm.c/clone-1.c (test for excess errors)
WARNING: libitm.c/clone-1.c compilation failed to produce executable
FAIL: libitm.c/memcpy-1.c execution test
FAIL: libitm.c/memset-1.c execution test
FAIL: libitm.c/reentrant.c (test for excess errors)
WARNING: libitm.c/reentrant.c compilation failed to produce executable
Running 
/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-2018/libitm/testsuite/libitm.c++/c++.exp
 ...
FAIL: libitm.c++/eh-1.C (test for excess errors)
WARNING: libitm.c++/eh-1.C compilation failed to produce executable
WARNING: libitm.c++/static_ctor.C compilation failed to produce executable

=== libitm Summary for unix/-m32 ===

# of expected passes14
# of unexpected failures6
# of expected failures  4
Running target unix/-m64
Using /sw/share/dejagnu/baseboards/unix.exp as board description file for 
target.
Using /sw/share/dejagnu/config/unix.exp as generic interface file for target.
Using 
/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-2018/libitm/testsuite/config/default.exp
 as tool-and-target-specific interface file.
Running 
/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-2018/libitm/testsuite/libitm.c/c.exp
 ...
FAIL: libitm.c/cancel.c (test for excess errors)
WARNING: libitm.c/cancel.c compilation failed to produce executable
FAIL: libitm.c/clone-1.c (test for excess errors)
WARNING: libitm.c/clone-1.c compilation failed to produce executable
FAIL: libitm.c/reentrant.c (test for excess errors)
WARNING: libitm.c/reentrant.c compilation failed to produce executable
Running 
/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-2018/libitm/testsuite/libitm.c++/c++.exp
 ...
FAIL: libitm.c++/eh-1.C (test for excess errors)
WARNING: libitm.c++/eh-1.C compilation failed to produce executable
WARNING: libitm.c++/static_ctor.C compilation failed to produce executable

=== libitm Summary for unix/-m64 ===

# of expected passes16
# of unexpected failures4
# of expected failures  4

=== libitm Summary ===

# of expected passes30
# of unexpected failures10
# of expected failures  8

These appear as...

Executing on host: /sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/xgcc 
-B/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/ 
/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-2018/libitm/testsuite/libitm.c/cancel.c
  
-B/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin11.2.0/i386/libitm/
 
-I/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin11.2.0/i386/libitm
 -I/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-2018/libitm/testsuite/.. 
-march=i486 -shared-libgcc -fmessage-length=0 -fgnu-tm  -O2   
-L/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin11.2.0/i386/libitm/.libs
 -litm -lm   -m32 -o ./cancel.exe(timeout = 300)
/var/tmp//cc4JYjZE.s:130:Expected comma after segment-name
/var/tmp//cc4JYjZE.s:130:Rest of line ignored. 1st junk character valued 32 ( ).
compiler exited with status 1
output is:
/var/tmp//cc4JYjZE.s:130:Expected comma after segment-name
/var/tmp//cc4JYjZE.s:130:Rest of line ignored. 1st junk character valued 32 ( ).

FAIL: libitm.c/cancel.c (test for excess errors)

Executing on host: /sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/xgcc 
-B/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/ 
/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-2018/libitm/testsuite/libitm.c/clone-1.c
  
-B/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin11.2.0/i386/libitm/
 
-I/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin11.2.0/i386/libitm
 -I/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-2018/libitm/testsuite/.. 
-march=i486 -shared-libgcc -fmessage-length=0 -fgnu-tm  -O2   
-L/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin11.2.0/i386/libitm/.libs
 -litm -lm   -m32 -o ./clone-1.exe(timeout = 300)
/var/tmp//ccKvZq3x.s:80:Expected comma after segment-name
/var/tmp//ccKvZq3x.s:80:Rest of line ignored. 1st junk character valued 32 ( ).
compiler exited with status 1
output is:
/var/tmp//ccKvZq3x.s:80:Expected comma after segment-name
/var/tmp//ccKvZq3x.s:80:Rest of line ignored. 1st

Re: Fix libgcc for FreeBSD 10

2011-11-18 Thread Rainer Orth
Gerald Pfeifer  writes:

> The snippet below was written when a new major release of FreeBSD
> would happen every couple of years, not as frequently as recently
> the case.  FreeBSD 1.x and 2.x, and a.out support, have been obsolete
> for what must be a decade or so, yet the regular expressions now
> match, and cause troubles for, FreeBSD 10.x.
>
> I am planing to apply the patch below as obvious.  If we want to
> be more conservative, I could just yank the -*-*-freebsd[12] pattern.
>
> Rainer, Loren, any thoughts?

Given that this is no longer present in gcc/config.gcc, but those a.out
configurations are rejected there wholesale, I think the patch is right.

Rainer

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


Re: [wwwdocs] add news items for TM work

2011-11-18 Thread Aldy Hernandez



+ The project was partially funded by
+ thehttp://www.velox-project.eu/";>Velox  project.  This
+ feature is experimental and is available for C and C++ on selected
+ platforms.


Reading this I was wondering which platforms.  On the other page it
says x86 and alpha; should we just use this here, or were you thinking
to keep this more marketing speak? ;-)


*blush*, yes... marketing speak.  Seeing that people are contributing 
other ports (or planning on), I didn't want to be too restrictive in the 
news file.  I can specify x86 and Alpha if you'd prefer, to keep it in 
sync with gcc-4.7/changes.html.





Index: gcc-4.7/changes.html
===
+Experimental support for transactional memory has been added.
+   It includes support for the compiler, as well as a supporting
+   runtime library calledlibitm.  To compile code
+   with transactional memory constructs, use
+   the-fgnu-tm  option.


Put this under...  as well, I think.


done




+   Support is currently available for the x86 and Alpha platforms.


32-bit, 64-bit x86, or both?


both.  I have updated the patch.




+
+   This work was contributed by Red Hat and was partly funded by
+   thehttp://www.velox-project.eu/";>Velox  project.
+


In the release notes we generally don't have those acknowledgements,
only in the News section.


removed

How does this look?
Index: index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.824
diff -u -r1.824 index.html
--- index.html  15 Nov 2011 06:01:24 -  1.824
+++ index.html  18 Nov 2011 16:39:55 -
@@ -53,6 +53,18 @@
 
 
 
+Transactional memory support
+[2011-11-15]
+An implementation of the
+ongoing http://gcc.gnu.org/wiki/TransactionalMemory";>transactional
+memory standard has been added.  Code was contributed by Richard
+Henderson, Aldy Hernandez, and Torvald Riegel, all of Red Hat, Inc.
+The project was partially funded by
+the http://www.velox-project.eu/";>Velox project.  This
+feature is experimental and is available for C and C++ on selected
+platforms.
+
+
 POWER7 on the GCC Compile Farm
 [2011-11-10]
 IBM has donated a 64 processor POWER7 machine (3.55 GHz, 64 GB RAM)
Index: gcc-4.7/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v
retrieving revision 1.56
diff -u -r1.56 changes.html
--- gcc-4.7/changes.html8 Nov 2011 11:49:53 -   1.56
+++ gcc-4.7/changes.html18 Nov 2011 16:39:55 -
@@ -195,6 +195,26 @@
   through which the compiler can be hinted about pointer alignment
   and can use it to improve generated code.
   
+
+  
+
+  Experimental support for transactional memory has been added.
+  It includes support for the compiler, as well as a supporting
+  runtime library called libitm.  To compile code
+  with transactional memory constructs, use
+  the -fgnu-tm option.
+
+
+
+  Support is currently available for the x86-32, x86-64, and Alpha
+  platforms.
+
+
+
+  For more details on transactional memory
+  see http://gcc.gnu.org/wiki/TransactionalMemory";>here.
+
+  
 
 
 C++


Re: [Patch RFA libitm] config-based assessment of weakref capability

2011-11-18 Thread Iain Sandoe


On 18 Nov 2011, at 16:17, Jack Howarth wrote:
  For gcc trunk at r181476 with 181473-libitm-config-weakref.txt,  
181473-libitm-tests-mapanon.txt
and 181473-libitm-user-label-prefix.txt as well as the regenerations  
performed in libitm, I see

the following failures on x86_64-apple-darwin11 under Xcode 4.2...


you will need a fix for the .tm_clone_table section name (working on  
that ;-))

Iain



Re: [trunk] RFS: translate built-in include paths for sysroot (issue5394041)

2011-11-18 Thread Joseph S. Myers
On Tue, 15 Nov 2011, Han Shen wrote:

> 2011-11-15   Han Shen  
> 
>   * gcc/Makefile.in:
>   * gcc/configure:
>   * gcc/cppdefault.c:

You need to include the full ChangeLog entries with your patch.  Note that 
paths in ChangeLogs are relative to the directory with the ChangeLog, so 
no gcc/ in this case.

Please also include the full rationale with your patch *and URLs for the 
previous discussion* (from June, it seems) so that reviewers don't need to 
track that down themselves.

> diff --git a/gcc/configure b/gcc/configure
> index 99334ce..364d8c2 100755
> --- a/gcc/configure
> +++ b/gcc/configure

It's not possible to review this patch as is because you've only included 
the changes to the generated file configure, not to its source file 
configure.ac.  Please make sure that your resubmission includes all the 
source file changes.  (There is no need to include the changes to the 
generated file configure at all in the submission; the ChangeLog entry can 
just mention it as "* configure: Regenerate.".)

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


Re: Memset/memcpy patch

2011-11-18 Thread H.J. Lu
On Fri, Nov 18, 2011 at 6:18 AM, Jan Hubicka  wrote:
>> I found another bug in current implementation. A patch for it doesn't
>> cure i686-linux- bootstrap, but fixes fails on some tests (see
>> attached).
>>
>> The problem was that we tried to add runtime tests for alignment even
>> if both SRC and DST had unknown alignment - in this case it could be
>> impossible to make them both aligned simultaneously, so I think it's
>> easier to even not try to use aligned SSE-moves at all. Generation of
>> prologues with runtime tests could be used only if at least one
>> alignment is known - otherwise it's incorrect. Probably, generation of
>> such prologues could be removed from MEMMOV at all for now.
>
> The prologues always align the destination as it helps more than aligning
> source on most chips.  I do not see problem with that.  But for SSE either we
> should arrange unaligned load opcodes (that is what I see in generated code, 
> but I
> guess it depends on -march setting) or simply disqualify the sse_loop 
> algorithm
> in decide_alg when alignment is not know.
>>
>> Though, even with this fix i686-bootstrap still fails. Configure for
>> the bootstrap-fail reproducing:
>> CC="gcc -m32" CXX="g++ -m32" ../configure --with-arch=core2
>> --with-cpu=atom --prefix=`pwd` i686-linux --with-fpmath=sse
>> --enable-languages=c,c++,fortran
>
> Default i686-linux bootstrap was working for me. I will try your setting but
> my time today evening and at weekend is limited.
>

Given that x86 memset/memcpy is still broken, I think we should revert
it for now.


-- 
H.J.


Re: PR 44707 testcase failure

2011-11-18 Thread Ulrich Weigand
David Edelsohn wrote:

> I noticed that gcc.c-torture/compile/pr44707.c fails on AIX because it
> generates invalid assembly language:
> 
>  # 12 "/farm/dje/src/src/gcc/testsuite/gcc.c-torture/compile/pr44707.c" 1
> /* 0(6) 0(7) 0(8) 0(9) 0(10) */
>  # 0 "" 2
> 
> I'm confused why
> 
>   __asm__ volatile ("/* %0 %1 %2 %3 %4 */" : : "nro" (e1), "nro" (e2), "nro" 
> (e3
> 
> is suppose to be valid on all targets when assembled.

Huh, it seems the test in this form assumes the assembler supports /* ... */
comments.  But this isn't really necessary for the test to work; I think the
best fix would be to just remove the comment and simply write

   __asm__ volatile ("" : : "nro" (e1), "nro" (e2), "nro" (e3 ...

instead.

Bye,
Ulrich

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


[patch, ia64, libgcc] Patch to fix libunwind build on IA64

2011-11-18 Thread Steve Ellcey
This patch fixes the IA64 bootstrap when building libunwind.  When using
-fexceptions libunwind will have a reference to __gcc_personality_v0 and
the bootstrap fails, using -fno-exceptions fixes this.  This problem
started with r181172, Michael Matz's fix to mark objects death at end of
scope.

Tested on IA64 HP-UX and Linux.

While this change isn't in an ia64 specific file, ia64 is the only
platform affected because no other platform defines LIBUNWIND in order
to build a separate unwind library.  So I will go ahead and check it in
if there are no objections.

Steve Ellcey
s...@cup.hp.com


2011-11-18  Steve Ellcey  

* Makefile.in (c_flags): Set to -fno-exceptions to build libunwind.


Index: Makefile.in
===
--- Makefile.in (revision 181466)
+++ Makefile.in (working copy)
@@ -829,7 +829,7 @@ endif
 
 # Build LIBUNWIND.
 
-c_flags := -fexceptions
+c_flags := -fno-exceptions
 
 libunwind-objects += $(addsuffix $(objext),$(basename $(notdir $(LIBUNWIND
 


Re: [patch, ia64, libgcc] Patch to fix libunwind build on IA64

2011-11-18 Thread Michael Matz
Hi,

On Fri, 18 Nov 2011, Steve Ellcey wrote:

> This patch fixes the IA64 bootstrap when building libunwind.  When using
> -fexceptions libunwind will have a reference to __gcc_personality_v0 and
> the bootstrap fails, using -fno-exceptions fixes this.  This problem
> started with r181172, Michael Matz's fix to mark objects death at end of
> scope.
> 
> Tested on IA64 HP-UX and Linux.

Oh, so you don't even need -fasynchronous-unwind-tables?  Even better then 
:)


Ciao,
Michael.


Re: PR 44707 testcase failure

2011-11-18 Thread Mike Stump
On Nov 18, 2011, at 9:04 AM, "Ulrich Weigand"  wrote:
> David Edelsohn wrote:
>> I noticed that gcc.c-torture/compile/pr44707.c fails on AIX because it
>> generates invalid assembly language:
>> 
>> # 12 "/farm/dje/src/src/gcc/testsuite/gcc.c-torture/compile/pr44707.c" 1
>>/* 0(6) 0(7) 0(8) 0(9) 0(10) */
>> # 0 "" 2
>> 
>> I'm confused why
>> 
>>  __asm__ volatile ("/* %0 %1 %2 %3 %4 */" : : "nro" (e1), "nro" (e2), "nro" 
>> (e3
>> 
>> is suppose to be valid on all targets when assembled.
> 
> Huh, it seems the test in this form assumes the assembler supports /* ... */
> comments.  But this isn't really necessary for the test to work; I think the
> best fix would be to just remove the comment and simply write
> 
>   __asm__ volatile ("" : : "nro" (e1), "nro" (e2), "nro" (e3 ...
> 
> instead.

Sounds good to me.


Re: [Patch libitm/testsuite] MAP_ANON

2011-11-18 Thread Richard Henderson
On 11/18/2011 04:27 AM, Iain Sandoe wrote:
> libitm:
> 
> * testsuite/libitm.c/memcpy-1.c: Allow for MAP_ANON spelling.
> * testsuite/libitm.c/memset-1.c: Likewise.

Ok.


r~


Re: [Patch RFA libitm] Deal with __USER_LABEL_PREFIX__ in the asm

2011-11-18 Thread Richard Henderson
On 11/18/2011 04:00 AM, Iain Sandoe wrote:
> libitm:
> 
> * config/x86/sjlj.S (CONCAT1, CONCAT2, SYM): Respond to
> __USER_LABEL_PREFIX__ for targets that use it.
> TYPE, SIZE, HIDDEN): New macros to assist on non-elf targets.
> (_ITM_beginTransaction): Use SYM, TYPE, SIZE macros to assist
> in portability to non-elf targets.
> (GTM_longjmp): LIkewise.
> * libitm_i.h (begin_transaction): Apply __USER_LABEL_PREFIX__
> where required.

Ok modulo the conflict you're going to have with RO's patch.
Adjust for his use of .hidden, of course, and the extra symbol ref.


r~


Re: [patch, ia64, libgcc] Patch to fix libunwind build on IA64

2011-11-18 Thread Rainer Orth
Steve Ellcey  writes:

> This patch fixes the IA64 bootstrap when building libunwind.  When using
> -fexceptions libunwind will have a reference to __gcc_personality_v0 and
> the bootstrap fails, using -fno-exceptions fixes this.  This problem
> started with r181172, Michael Matz's fix to mark objects death at end of
> scope.
>
> Tested on IA64 HP-UX and Linux.
>
> While this change isn't in an ia64 specific file, ia64 is the only
> platform affected because no other platform defines LIBUNWIND in order
> to build a separate unwind library.  So I will go ahead and check it in
> if there are no objections.

I think there should be a comment explaining this to avoid involuntarily
breaking this in the future ;-)

Thanks.
Rainer

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


Re: RFC: powerpc libgomp locking

2011-11-18 Thread Richard Henderson
On 11/17/2011 03:47 PM, Alan Modra wrote:
> BTW, we're left with dead stores into oldval's stack slot.  Is it
> legal for the first two parameters of __atomic_compare_exchange to
> alias?  I'm guessing that the stores might disappear if we tell gcc
> that they can't alias.

No they cannot alias.

Macleod and I have discussed several ways to get rid of the dead
address slot, and havn't had time to do any of them yet.  I've
been trying to decide if this counts as a regression from gcc 4.6...


r~


Re: powerpc compare_and_swap fails

2011-11-18 Thread Richard Henderson
On 11/17/2011 03:58 PM, Alan Modra wrote:
> Thanks!  This, along with my mutex.h rewrite plus adding a
> memory_barrier insn gets me down to just one libgomp failure.

The memory_barrier thing should be fixed now as well...


r~


Re: [patch, ia64, libgcc] Patch to fix libunwind build on IA64

2011-11-18 Thread Steve Ellcey
On Fri, 2011-11-18 at 18:26 +0100, Michael Matz wrote:
> Hi,
> 
> On Fri, 18 Nov 2011, Steve Ellcey wrote:
> 
> > This patch fixes the IA64 bootstrap when building libunwind.  When using
> > -fexceptions libunwind will have a reference to __gcc_personality_v0 and
> > the bootstrap fails, using -fno-exceptions fixes this.  This problem
> > started with r181172, Michael Matz's fix to mark objects death at end of
> > scope.
> > 
> > Tested on IA64 HP-UX and Linux.
> 
> Oh, so you don't even need -fasynchronous-unwind-tables?  Even better then 
> :)
> 
> 
> Ciao,
> Michael.

Didn't seem to.  Do you know of any special tests I should check and/or
run.  I didn't see any problems in the GCC test suite after the
bootstrap.

Steve Ellcey
s...@cup.hp.com




[PATCH, PR 50744] Prevent overflows in IPA-CP

2011-11-18 Thread Martin Jambor
Hi,

PR 50744 is an issue with an integer overflow when we propagate the
estimated size and time effects from callees to callers.  Because such
paths in the parameter value graph can be arbitrarily long, we simply
need to introduce an artificial cap on these values.  This is what the
patch below does.  The cap should be more than enough for any
reasonable values.

Moreover, I have looked at how we then process the accumulated
estimates and decided to compute evaluation ratio in
good_cloning_opportunity_p in HOST_WIDEST_INT.  Call graph frequencies
are numerators of fractions with denominator 1000 and therefore
capping the size and cost estimate as well as the frequency sums so
that their multiplication would not overflow an int seems too
constraining on 32bit hosts.

Bootstrapped and tested on x86_64-linux without any problems, OK for
trunk?

Thanks,

Martin



2011-11-15  Martin Jambor  

PR tree-optimization/50744
* ipa-cp.c (good_cloning_opportunity_p): Assert size_cost is positive,
compute evaluation in HOST_WIDEST_INT.
(safe_add): New function
(propagate_effects): Use safe_add to accumulate effects.

* testsuite/gcc.dg/ipa/pr50744.c: New test.


Index: src/gcc/testsuite/gcc.dg/ipa/pr50744.c
===
--- /dev/null
+++ src/gcc/testsuite/gcc.dg/ipa/pr50744.c
@@ -0,0 +1,119 @@
+/* { dg-do compile } */
+/* { dg-options "-O3 -fno-optimize-sibling-calls" } */
+
+extern int use_data (void *p_01, void *p_02, void *p_03, void *p_04, void 
*p_05,
+void *p_06, void *p_07, void *p_08, void *p_09, void *p_10,
+void *p_11, void *p_12, void *p_13, void *p_14, void *p_15,
+void *p_16, void *p_17, void *p_18, void *p_19, void *p_20,
+void *p_21, void *p_22, void *p_23, void *p_24, void *p_25,
+void *p_26, void *p_27, void *p_28, void *p_29,
+void *p_30);
+
+extern int idx (int i, int j, int n);
+
+struct stuff
+{
+  int decision;
+  int *a, *b, *c;
+  int res;
+};
+
+
+#define some_large_stuff(stuff, n) { \
+  int i, j, k; \
+  for (i = 0; i < n; i++) \
+for (j = 0; j < n; j++) \
+  { \
+   int v = stuff->c[idx(i, j, n)]; \
+   for (k = 0; k < n; k++) \
+ v += stuff->a[idx(i, k, n)] * stuff->b[idx(k,j,n)]; \
+   stuff->c[idx(i, j, n)] = v; \
+  } \
+}
+
+#define recursion if (iter > 0) \
+foo (stuff, iter - 1, (void *) -1, p_01, p_02, p_03, p_04, p_05, p_06, \
+  p_07, p_08, p_09, p_10, p_11, p_12, p_13, p_14, p_15, p_16, p_17, \
+ p_18, p_19, p_20, p_21, p_22, p_23, p_24, p_25, p_26, p_27, p_28, p_29); \
+else \
+  foo (stuff, iter, p_01, p_02, p_03, p_04, p_05, p_06, p_07, p_08, p_09, \
+   p_10, p_11, p_12, p_13, p_14, p_15, p_16, p_17, p_18, p_19, p_20, \
+p_21,p_22, p_23, p_24, p_25, p_26, p_27, p_28, p_29, p_30)
+
+void
+foo (struct stuff *stuff,
+ int iter,
+ void *p_01, void *p_02, void *p_03, void *p_04, void *p_05,
+ void *p_06, void *p_07, void *p_08, void *p_09, void *p_10,
+ void *p_11, void *p_12, void *p_13, void *p_14, void *p_15,
+ void *p_16, void *p_17, void *p_18, void *p_19, void *p_20,
+ void *p_21, void *p_22, void *p_23, void *p_24, void *p_25,
+ void *p_26, void *p_27, void *p_28, void *p_29, void *p_30)
+{
+ switch (stuff->decision)
+   {
+   case 0:
+ some_large_stuff (stuff, 83);
+ stuff->res =
+   use_data (p_01, p_02, p_03, p_04, p_05, p_06, p_07, p_08, p_09, p_10,
+p_11, p_12, p_13, p_14, p_15, p_16, p_17, p_18, p_19, p_20,
+p_21, p_22, p_23, p_24, p_25, p_26, p_27, p_28, p_29, p_30);
+ recursion;
+ break;
+
+   case 1:
+ some_large_stuff (stuff, 25);
+ stuff->res =
+   use_data (p_11, p_02, p_03, p_04, p_05, p_06, p_07, p_08, p_09, p_10,
+p_21, p_12, p_13, p_14, p_15, p_16, p_17, p_18, p_19, p_20,
+p_01, p_22, p_23, p_24, p_25, p_26, p_27, p_28, p_29, p_30);
+ recursion;
+ break;
+
+   case 3:
+ some_large_stuff (stuff, 139);
+ stuff->res =
+   use_data (p_01, p_12, p_03, p_04, p_05, p_06, p_07, p_08, p_09, p_10,
+p_11, p_22, p_13, p_14, p_15, p_16, p_17, p_18, p_19, p_20,
+p_21, p_02, p_23, p_24, p_25, p_26, p_27, p_28, p_29, p_30);
+ recursion;
+ break;
+
+   case 4:
+ some_large_stuff (stuff, 32);
+ stuff->res =
+   use_data (p_01, p_02, p_13, p_04, p_05, p_06, p_07, p_08, p_09, p_10,
+p_11, p_12, p_23, p_14, p_15, p_16, p_17, p_18, p_19, p_20,
+p_21, p_22, p_03, p_24, p_25, p_26, p_27, p_28, p_29, p_30);
+ recursion;
+ break;
+
+   case 5:
+ some_large_stuff (stuff, 205);
+ stuff->res =
+   use_data (p_01, p_02, p_03, p_04, p_15, p_06, p_07, p_08, p_09, p_10,
+p_11, p_12, p_13, p_14, p_25, p_16, p_17, p_18, p_19, p_20,
+p_2

[Patch] make it possible for the target to rename ".tm_clone_table"

2011-11-18 Thread Iain Sandoe

At least Darwin needs a different name for the tm_clone_table section.

I'm wondering what a target without named sections does for this - is  
there some reason it needs to be in a separate section (from data)...


... perhaps what I'm missing here will help understand why the clone  
tests fail on *x68*-darwin :-)


comments/OK for trunk?
Iain

gcc:

* defaults.h (TM_CLONE_TABLE_SECTION_NAME): Provide default
tm clone section name.
* varasm.c (dump_tm_clone_pairs): Use TM_CLONE_TABLE_SECTION_NAME.
* config/darwin.h (TM_CLONE_TABLE_SECTION_NAME): Define.

Index: gcc/defaults.h
===
--- gcc/defaults.h  (revision 181476)
+++ gcc/defaults.h  (working copy)
@@ -392,6 +392,14 @@ see the files COPYING3 and COPYING.RUNTIME respect
 #endif
 #endif
 
+/* If we have named sections, provide a name for the transaction clone
+   table section.  */
+#if defined (TARGET_ASM_NAMED_SECTION)
+#ifndef TM_CLONE_TABLE_SECTION_NAME
+#define TM_CLONE_TABLE_SECTION_NAME ".tm_clone_table"
+#endif
+#endif
+
 /* If we have named section and we support weak symbols, then use the
.jcr section for recording java classes which need to be registered
at program start-up time.  */
Index: gcc/varasm.c
===
--- gcc/varasm.c(revision 181476)
+++ gcc/varasm.c(working copy)
@@ -5961,7 +5961,9 @@ dump_tm_clone_pairs (VEC(tm_alias_pair,heap) *tm_a
 
   if (!switched)
{
- switch_to_section (get_named_section (NULL, ".tm_clone_table", 3));
+ switch_to_section (get_named_section (NULL, 
+   TM_CLONE_TABLE_SECTION_NAME,
+   3));
  assemble_align (POINTER_SIZE);
  switched = true;
}
Index: gcc/config/darwin.h
===
--- gcc/config/darwin.h (revision 181476)
+++ gcc/config/darwin.h (working copy)
@@ -692,6 +680,10 @@ extern GTY(()) section * darwin_sections[NUM_DARWI
 #define TARGET_ASM_UNIQUE_SECTION darwin_unique_section
 #undef  TARGET_ASM_FUNCTION_RODATA_SECTION
 #define TARGET_ASM_FUNCTION_RODATA_SECTION default_no_function_rodata_section
+
+#undef  TM_CLONE_TABLE_SECTION_NAME
+#define TM_CLONE_TABLE_SECTION_NAME "__DATA,__tm_clone_table"
+
 #undef  TARGET_ASM_RELOC_RW_MASK
 #define TARGET_ASM_RELOC_RW_MASK machopic_reloc_rw_mask
 






Re: [Patch] make it possible for the target to rename ".tm_clone_table"

2011-11-18 Thread Rainer Orth
Iain Sandoe  writes:

> Index: gcc/defaults.h
> ===
> --- gcc/defaults.h(revision 181476)
> +++ gcc/defaults.h(working copy)
> @@ -392,6 +392,14 @@ see the files COPYING3 and COPYING.RUNTIME respect
>  #endif
>  #endif
>  
> +/* If we have named sections, provide a name for the transaction clone
> +   table section.  */
> +#if defined (TARGET_ASM_NAMED_SECTION)
> +#ifndef TM_CLONE_TABLE_SECTION_NAME
> +#define TM_CLONE_TABLE_SECTION_NAME ".tm_clone_table"
> +#endif
> +#endif
> +

This, together with the unconditional use in varasm.c, will lead to a
bootstrap failure on Tru64 UNIX, which lacks named sections completely.

Rainer

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


PATCH: PR target/33944: streaming 64-bit integer stores

2011-11-18 Thread H.J. Lu
Hi,

_mm_stream_si64 intrinsic is missing.  It is implemented in VC++:

http://msdn.microsoft.com/en-us/library/bb531466.aspx

We are adding it to Intel64 SDM.  Here is a patch to implement it in GCC.
I added UNSPEC_MOVNTI so that it won't get confused with

(define_insn "sse_movntdi"
  [(set (match_operand:DI 0 "memory_operand" "=m")
(unspec:DI [(match_operand:DI 1 "register_operand" "y")]
   UNSPEC_MOVNT))]
  "TARGET_SSE || TARGET_3DNOW_A"
  "movntq\t{%1, %0|%0, %1}"
  [(set_attr "type" "mmxmov")
   (set_attr "mode" "DI")])

OK for trunk?

Thanks.

H.J.
---
2011-11-16  H.J. Lu  

PR target/33944
* doc/extend.texi: Document __builtin_ia32_movnti64.

* config/i386/emmintrin.h (_mm_stream_si64): New.

* config/i386/i386-builtin-types.def: Add VOID_FTYPE_PLONGLONG_LONGLONG.

* config/i386/i386.c (ix86_builtins): Add IX86_BUILTIN_MOVNTI64.
(bdesc_special_args): Update __builtin_ia32_movnti.  Add
__builtin_ia32_movnti64.
(ix86_expand_special_args_builtin): Handle
VOID_FTYPE_PLONGLONG_LONGLONG.

* config/i386/i386.md (UNSPEC_MOVNTI): New.

* config/i386/sse.md (sse2_movntsi): Renamed to ...
(sse2_movnti): This.

diff --git a/gcc/config/i386/emmintrin.h b/gcc/config/i386/emmintrin.h
index fe4cd6a..07ac9f3 100644
--- a/gcc/config/i386/emmintrin.h
+++ b/gcc/config/i386/emmintrin.h
@@ -1418,6 +1418,14 @@ _mm_stream_si32 (int *__A, int __B)
   __builtin_ia32_movnti (__A, __B);
 }
 
+#ifdef __x86_64__
+extern __inline void __attribute__((__gnu_inline__, __always_inline__, 
__artificial__))
+_mm_stream_si64 (long long int *__A, long long int __B)
+{
+  __builtin_ia32_movnti64 (__A, __B);
+}
+#endif
+
 extern __inline void __attribute__((__gnu_inline__, __always_inline__, 
__artificial__))
 _mm_stream_si128 (__m128i *__A, __m128i __B)
 {
diff --git a/gcc/config/i386/i386-builtin-types.def 
b/gcc/config/i386/i386-builtin-types.def
index 79fb142..d00b053 100644
--- a/gcc/config/i386/i386-builtin-types.def
+++ b/gcc/config/i386/i386-builtin-types.def
@@ -111,6 +111,7 @@ DEF_POINTER_TYPE (PDOUBLE, DOUBLE)
 DEF_POINTER_TYPE (PFLOAT, FLOAT)
 DEF_POINTER_TYPE (PUSHORT, USHORT)
 DEF_POINTER_TYPE (PINT, INT)
+DEF_POINTER_TYPE (PLONGLONG, LONGLONG)
 DEF_POINTER_TYPE (PULONGLONG, ULONGLONG)
 DEF_POINTER_TYPE (PUNSIGNED, UNSIGNED)
 
@@ -357,6 +358,7 @@ DEF_FUNCTION_TYPE (VOID, PDOUBLE, V4DF)
 DEF_FUNCTION_TYPE (VOID, PFLOAT, V4SF)
 DEF_FUNCTION_TYPE (VOID, PFLOAT, V8SF)
 DEF_FUNCTION_TYPE (VOID, PINT, INT)
+DEF_FUNCTION_TYPE (VOID, PLONGLONG, LONGLONG)
 DEF_FUNCTION_TYPE (VOID, PULONGLONG, ULONGLONG)
 DEF_FUNCTION_TYPE (VOID, PV2SI, V2SI)
 DEF_FUNCTION_TYPE (VOID, PV2DI, V2DI)
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 691c89a..a2a962c 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -25245,6 +25245,7 @@ enum ix86_builtins
   IX86_BUILTIN_CVTTPS2DQ,
 
   IX86_BUILTIN_MOVNTI,
+  IX86_BUILTIN_MOVNTI64,
   IX86_BUILTIN_MOVNTPD,
   IX86_BUILTIN_MOVNTDQ,
 
@@ -26327,7 +26328,8 @@ static const struct builtin_description 
bdesc_special_args[] =
   { OPTION_MASK_ISA_SSE2, CODE_FOR_sse2_movdqu, "__builtin_ia32_storedqu", 
IX86_BUILTIN_STOREDQU, UNKNOWN, (int) VOID_FTYPE_PCHAR_V16QI },
   { OPTION_MASK_ISA_SSE2, CODE_FOR_sse2_movntv2df, "__builtin_ia32_movntpd", 
IX86_BUILTIN_MOVNTPD, UNKNOWN, (int) VOID_FTYPE_PDOUBLE_V2DF },
   { OPTION_MASK_ISA_SSE2, CODE_FOR_sse2_movntv2di, "__builtin_ia32_movntdq", 
IX86_BUILTIN_MOVNTDQ, UNKNOWN, (int) VOID_FTYPE_PV2DI_V2DI },
-  { OPTION_MASK_ISA_SSE2, CODE_FOR_sse2_movntsi, "__builtin_ia32_movnti", 
IX86_BUILTIN_MOVNTI, UNKNOWN, (int) VOID_FTYPE_PINT_INT },
+  { OPTION_MASK_ISA_SSE2, CODE_FOR_sse2_movntisi, "__builtin_ia32_movnti", 
IX86_BUILTIN_MOVNTI, UNKNOWN, (int) VOID_FTYPE_PINT_INT },
+  { OPTION_MASK_ISA_SSE2 | OPTION_MASK_ISA_64BIT, CODE_FOR_sse2_movntidi, 
"__builtin_ia32_movnti64", IX86_BUILTIN_MOVNTI64, UNKNOWN, (int) 
VOID_FTYPE_PLONGLONG_LONGLONG },
   { OPTION_MASK_ISA_SSE2, CODE_FOR_sse2_movupd, "__builtin_ia32_loadupd", 
IX86_BUILTIN_LOADUPD, UNKNOWN, (int) V2DF_FTYPE_PCDOUBLE },
   { OPTION_MASK_ISA_SSE2, CODE_FOR_sse2_movdqu, "__builtin_ia32_loaddqu", 
IX86_BUILTIN_LOADDQU, UNKNOWN, (int) V16QI_FTYPE_PCCHAR },
 
@@ -29313,6 +29315,7 @@ ix86_expand_special_args_builtin (const struct 
builtin_description *d,
 case VOID_FTYPE_PFLOAT_V4SF:
 case VOID_FTYPE_PDOUBLE_V4DF:
 case VOID_FTYPE_PDOUBLE_V2DF:
+case VOID_FTYPE_PLONGLONG_LONGLONG:
 case VOID_FTYPE_PULONGLONG_ULONGLONG:
 case VOID_FTYPE_PINT_INT:
   nargs = 1;
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index bc60253..daf1387 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -116,6 +116,7 @@
   UNSPEC_MASKMOV
   UNSPEC_MOVMSK
   UNSPEC_MOVNT
+  UNSPEC_MOVNTI
   UNSPEC_MOVU
   UNSPEC_RCP
   UNSPEC_RSQRT
diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index b476752..e43310b 100644
--- a/gcc/confi

Re: [Patch] make it possible for the target to rename ".tm_clone_table"

2011-11-18 Thread Iain Sandoe


On 18 Nov 2011, at 17:56, Rainer Orth wrote:


Iain Sandoe  writes:


Index: gcc/defaults.h
===
--- gcc/defaults.h  (revision 181476)
+++ gcc/defaults.h  (working copy)
@@ -392,6 +392,14 @@ see the files COPYING3 and COPYING.RUNTIME  
respect

#endif
#endif

+/* If we have named sections, provide a name for the transaction  
clone

+   table section.  */
+#if defined (TARGET_ASM_NAMED_SECTION)
+#ifndef TM_CLONE_TABLE_SECTION_NAME
+#define TM_CLONE_TABLE_SECTION_NAME ".tm_clone_table"
+#endif
+#endif
+


This, together with the unconditional use in varasm.c, will lead to a
bootstrap failure on Tru64 UNIX, which lacks named sections  
completely.


right, it was worrying me what a target without named sections does -
... I can easily remove the #if defined (TARGET_ASM_NAMED_SECTION)
... what happens when the code runs then?

Iain



Re: [Patch] make it possible for the target to rename ".tm_clone_table"

2011-11-18 Thread Rainer Orth
Iain Sandoe  writes:

>> This, together with the unconditional use in varasm.c, will lead to a
>> bootstrap failure on Tru64 UNIX, which lacks named sections completely.
>
> right, it was worrying me what a target without named sections does -
> ... I can easily remove the #if defined (TARGET_ASM_NAMED_SECTION)
> ... what happens when the code runs then?

We ICE like this:

/vol/gcc/src/hg/trunk/local/libitm/testsuite/libitm.c/cancel.c:55:1: internal
compiler error: in default_no_named_section, at varasm.c:6293

I should probably file a PR, but there's still no proper bugzilla
component for trans-mem.

Rainer

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


Re: PR 44707 testcase failure

2011-11-18 Thread Ulrich Weigand
Mike Stump wrote:
> On Nov 18, 2011, at 9:04 AM, "Ulrich Weigand"  wrote:
> > Huh, it seems the test in this form assumes the assembler supports /* ...  
> > */
> > comments.  But this isn't really necessary for the test to work; I think the
> > best fix would be to just remove the comment and simply write 20
> >   __asm__ volatile ("" : : "nro" (e1), "nro" (e2), "nro" (e3 ...
> > instead.
> 
> Sounds good to me.

OK, I've checked in the following patch.

Tested on i386-linux.

Bye,
Ulrich

ChangeLog:

* gcc.c-torture/compile/pr44707.c: Do not assume assembler
supports /* ... */ comments.

Index: gcc/testsuite/gcc.c-torture/compile/pr44707.c
===
--- gcc/testsuite/gcc.c-torture/compile/pr44707.c   (revision 181162)
+++ gcc/testsuite/gcc.c-torture/compile/pr44707.c   (working copy)
@@ -9,6 +9,6 @@
   int e3 = v.b;
   int e4 = v.c;
   int e5 = v.d;
-  __asm__ volatile ("/* %0 %1 %2 %3 %4 */" : : "nro" (e1), "nro" (e2), "nro" 
(e3), "nro" (e4), "nro" (e5));
+  __asm__ volatile ("" : : "nro" (e1), "nro" (e2), "nro" (e3), "nro" (e4), 
"nro" (e5));
 }
 

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


Re: [Patch] make it possible for the target to rename ".tm_clone_table"

2011-11-18 Thread Iain Sandoe


On 18 Nov 2011, at 18:12, Rainer Orth wrote:


Iain Sandoe  writes:

This, together with the unconditional use in varasm.c, will lead  
to a
bootstrap failure on Tru64 UNIX, which lacks named sections  
completely.


right, it was worrying me what a target without named sections does -
... I can easily remove the #if defined (TARGET_ASM_NAMED_SECTION)
... what happens when the code runs then?


We ICE like this:

/vol/gcc/src/hg/trunk/local/libitm/testsuite/libitm.c/cancel.c:55:1:  
internal

compiler error: in default_no_named_section, at varasm.c:6293

I should probably file a PR, but there's still no proper bugzilla
component for trans-mem.


well ... what about this instead then?
Iain


Index: gcc/defaults.h
===
--- gcc/defaults.h  (revision 181476)
+++ gcc/defaults.h  (working copy)
@@ -392,6 +392,14 @@ see the files COPYING3 and COPYING.RUNTIME respect
 #endif
 #endif
 
+/* If we have named sections, provide a name for the transaction clone
+   table section.  */
+#if defined (TARGET_ASM_NAMED_SECTION)
+#ifndef TM_CLONE_TABLE_SECTION_NAME
+#define TM_CLONE_TABLE_SECTION_NAME ".tm_clone_table"
+#endif
+#endif
+
 /* If we have named section and we support weak symbols, then use the
.jcr section for recording java classes which need to be registered
at program start-up time.  */
Index: gcc/varasm.c
===
--- gcc/varasm.c(revision 181476)
+++ gcc/varasm.c(working copy)
@@ -5961,7 +5961,13 @@ dump_tm_clone_pairs (VEC(tm_alias_pair,heap) *tm_a
 
   if (!switched)
{
- switch_to_section (get_named_section (NULL, ".tm_clone_table", 3));
+#if defined (TARGET_ASM_NAMED_SECTION)
+ switch_to_section (get_named_section (NULL, 
+   TM_CLONE_TABLE_SECTION_NAME,
+   3));
+#else
+ switch_to_section (data_section);
+#endif
  assemble_align (POINTER_SIZE);
  switched = true;
}
Index: gcc/config/darwin.h
===
--- gcc/config/darwin.h (revision 181476)
+++ gcc/config/darwin.h (working copy)
@@ -692,6 +680,10 @@ extern GTY(()) section * darwin_sections[NUM_DARWI
 #define TARGET_ASM_UNIQUE_SECTION darwin_unique_section
 #undef  TARGET_ASM_FUNCTION_RODATA_SECTION
 #define TARGET_ASM_FUNCTION_RODATA_SECTION default_no_function_rodata_section
+
+#undef  TM_CLONE_TABLE_SECTION_NAME
+#define TM_CLONE_TABLE_SECTION_NAME "__DATA,__tm_clone_table"
+
 #undef  TARGET_ASM_RELOC_RW_MASK
 #define TARGET_ASM_RELOC_RW_MASK machopic_reloc_rw_mask
 




Re: [Patch] make it possible for the target to rename ".tm_clone_table"

2011-11-18 Thread Rainer Orth
Iain Sandoe  writes:

> well ... what about this instead then?

That one should at least be no worse than the current situation :-)

> Index: gcc/defaults.h
> ===
> --- gcc/defaults.h(revision 181476)
> +++ gcc/defaults.h(working copy)
> @@ -392,6 +392,14 @@ see the files COPYING3 and COPYING.RUNTIME respect
>  #endif
>  #endif
>  
> +/* If we have named sections, provide a name for the transaction clone
> +   table section.  */
> +#if defined (TARGET_ASM_NAMED_SECTION)

I suggest using #ifdef for single-condition tests; it's less chatty and
thus easier to read (again below).

Rainer

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


Re: PATCH: PR target/33944: streaming 64-bit integer stores

2011-11-18 Thread Uros Bizjak
On Fri, Nov 18, 2011 at 6:58 PM, H.J. Lu  wrote:

> _mm_stream_si64 intrinsic is missing.  It is implemented in VC++:
>
> http://msdn.microsoft.com/en-us/library/bb531466.aspx
>
> We are adding it to Intel64 SDM.  Here is a patch to implement it in GCC.
> I added UNSPEC_MOVNTI so that it won't get confused with
>
> (define_insn "sse_movntdi"
>  [(set (match_operand:DI 0 "memory_operand" "=m")
>        (unspec:DI [(match_operand:DI 1 "register_operand" "y")]
>                   UNSPEC_MOVNT))]
>  "TARGET_SSE || TARGET_3DNOW_A"
>  "movntq\t{%1, %0|%0, %1}"
>  [(set_attr "type" "mmxmov")
>   (set_attr "mode" "DI")])
>
> OK for trunk?
>
> Thanks.
>
> H.J.
> ---
> 2011-11-16  H.J. Lu  
>
>        PR target/33944
>        * doc/extend.texi: Document __builtin_ia32_movnti64.
>
>        * config/i386/emmintrin.h (_mm_stream_si64): New.
>
>        * config/i386/i386-builtin-types.def: Add 
> VOID_FTYPE_PLONGLONG_LONGLONG.
>
>        * config/i386/i386.c (ix86_builtins): Add IX86_BUILTIN_MOVNTI64.
>        (bdesc_special_args): Update __builtin_ia32_movnti.  Add
>        __builtin_ia32_movnti64.
>        (ix86_expand_special_args_builtin): Handle
>        VOID_FTYPE_PLONGLONG_LONGLONG.
>
>        * config/i386/i386.md (UNSPEC_MOVNTI): New.
>
>        * config/i386/sse.md (sse2_movntsi): Renamed to ...
>        (sse2_movnti): This.

OK.

Thanks,
Uros.


[PATCH] PR c++/51145 - Alias template in elaborated-type-specifier

2011-11-18 Thread Dodji Seketeli
Hello,

As reminded in the audit trail of this PR, the identifier of an
elaborate specifier should never be a simple-template-id that resolves
to an alias template specialization, but the current implementation
fails to enforce that.

I reused check_elaborated_type_specifier in
cp_parser_elaborated_type_specifier for cases where the later parses a
template-id.  I had to make check_elaborate_type_specifier be a bit more
robust, accept bound template template parameters and display relevant
diagnostics for alias template specializations.

Not surprisingly, I had to adjust some tests that were wrongly passing
before.

Bootstrapped and tested on x86_64-unknown-linux-gnu against trunk.

gcc/cp/

PR c++/51145
* decl.c (check_elaborated_type_specifier): Gracefully handle
error_mark_node.  Accept bound template template parameters.
Update diagnostics for alias template specializations.  Update
comment.
* parser.c (cp_parser_elaborated_type_specifier): Use
check_elaborated_type_specifier for simple-template-ids as well.

gcc/testsuite/

PR c++/51145
* g++.dg/cpp0x/alias-decl-2.C: Adjust for tests that were wrongly
passing before.
* g++.dg/cpp0x/alias-decl-10.C: Likewise and adjust for diagnostic
change.
* g++.dg/cpp0x/alias-decl-14.C: New test.
---
 gcc/cp/decl.c  |   22 ++
 gcc/cp/parser.c|3 ++-
 gcc/testsuite/g++.dg/cpp0x/alias-decl-10.C |   16 
 gcc/testsuite/g++.dg/cpp0x/alias-decl-14.C |   14 ++
 gcc/testsuite/g++.dg/cpp0x/alias-decl-2.C  |2 +-
 5 files changed, 47 insertions(+), 10 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/alias-decl-14.C

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index b77963b..7170072 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -11342,6 +11342,9 @@ check_elaborated_type_specifier (enum tag_types 
tag_code,
 {
   tree type;
 
+  if (decl == error_mark_node)
+return error_mark_node;
+
   /* In the case of:
 
struct S { struct S *p; };
@@ -11361,10 +11364,15 @@ check_elaborated_type_specifier (enum tag_types 
tag_code,
 type, tag_name (tag_code));
   return error_mark_node;
 }
+  /* Accept bound template template parameters.  */
+  else if (allow_template_p
+  && TREE_CODE (type) == BOUND_TEMPLATE_TEMPLATE_PARM)
+;
   /*   [dcl.type.elab]
 
-   If the identifier resolves to a typedef-name or a template
-   type-parameter, the elaborated-type-specifier is ill-formed.
+   If the identifier resolves to a typedef-name or the
+   simple-template-id resolves to an alias template
+   specialization, the elaborated-type-specifier is ill-formed.
 
  In other words, the only legitimate declaration to use in the
  elaborated type specifier is the implicit typedef created when
@@ -11373,8 +11381,14 @@ check_elaborated_type_specifier (enum tag_types 
tag_code,
   && !DECL_SELF_REFERENCE_P (decl)
   && tag_code != typename_type)
 {
-  error ("using typedef-name %qD after %qs", decl, tag_name (tag_code));
-  error ("%q+D has a previous declaration here", decl);
+  if (alias_template_specialization_p (type))
+   error ("using alias template specialization %qT after %qs",
+  type, tag_name (tag_code));
+  else
+   {
+ error ("using typedef-name %qD after %qs", decl, tag_name (tag_code));
+ error ("%q+D has a previous declaration here", decl);
+   }
   return error_mark_node;
 }
   else if (TREE_CODE (type) != RECORD_TYPE
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index f839112..08b9c13 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -13933,7 +13933,8 @@ cp_parser_elaborated_type_specifier (cp_parser* parser,
   else if (tag_type == typename_type && TREE_CODE (decl) != TYPE_DECL)
 type = NULL_TREE; 
   else 
-   type = TREE_TYPE (decl);
+   type = check_elaborated_type_specifier (tag_type, decl,
+   /*allow_template_p=*/true);
 }
 
   if (!type)
diff --git a/gcc/testsuite/g++.dg/cpp0x/alias-decl-10.C 
b/gcc/testsuite/g++.dg/cpp0x/alias-decl-10.C
index 856e429..6adb785 100644
--- a/gcc/testsuite/g++.dg/cpp0x/alias-decl-10.C
+++ b/gcc/testsuite/g++.dg/cpp0x/alias-decl-10.C
@@ -3,16 +3,24 @@
 template  using Ptr = T*;
 Ptr; // { dg-error "does not declare anything" }
 Ptr; // { dg-error "not a template|does not declare anything" }
-template class Ptr;//{ dg-error "explicit instantiation|non-class 
templ|does not decl|anything" }
+template class Ptr;//{ dg-error "alias 
templ|specialization|Ptr|after|class" }
 
 template  using Arg = T;
 struct A {};
-template class Arg;// { dg-error "explicit instantiation|non-class templ" }
+template class Arg;// { dg-error "alias 
templ|specialization|Arg|after|class" }
 
 template  class TT, class T> using I

[PATCH 1/2] m68k-linux: Implement atomic operations via syscall.

2011-11-18 Thread Richard Henderson
---
 gcc/config/m68k/linux.h   |4 +
 gcc/config/m68k/m68k.c|8 ++
 libgcc/config.host|6 +-
 libgcc/config/m68k/linux-atomic.c |  211 +
 libgcc/config/m68k/t-linux|1 +
 5 files changed, 227 insertions(+), 3 deletions(-)
 create mode 100644 libgcc/config/m68k/linux-atomic.c
 create mode 100644 libgcc/config/m68k/t-linux

diff --git a/gcc/config/m68k/linux.h b/gcc/config/m68k/linux.h
index 70738d2..325faf7 100644
--- a/gcc/config/m68k/linux.h
+++ b/gcc/config/m68k/linux.h
@@ -235,3 +235,7 @@ along with GCC; see the file COPYING3.  If not see
 
 #undef  WCHAR_TYPE_SIZE
 #define WCHAR_TYPE_SIZE BITS_PER_WORD
+
+/* Install the __sync libcalls.  */
+#undef TARGET_INIT_LIBFUNCS
+#define TARGET_INIT_LIBFUNCS  m68k_init_sync_libfuncs
diff --git a/gcc/config/m68k/m68k.c b/gcc/config/m68k/m68k.c
index 51a04ed..61267a8 100644
--- a/gcc/config/m68k/m68k.c
+++ b/gcc/config/m68k/m68k.c
@@ -47,6 +47,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "insn-codes.h"
 #include "ggc.h"
 #include "opts.h"
+#include "optabs.h"
 
 enum reg_class regno_reg_class[] =
 {
@@ -164,6 +165,7 @@ static rtx m68k_function_arg (cumulative_args_t, enum 
machine_mode,
  const_tree, bool);
 static bool m68k_cannot_force_const_mem (enum machine_mode mode, rtx x);
 static bool m68k_output_addr_const_extra (FILE *, rtx);
+static void m68k_init_sync_libfuncs (void) ATTRIBUTE_UNUSED;
 
 /* Initialize the GCC target structure.  */
 
@@ -6524,4 +6526,10 @@ m68k_conditional_register_usage (void)
 fixed_regs[PIC_REG] = call_used_regs[PIC_REG] = 1;
 }
 
+static void
+m68k_init_sync_libfuncs (void)
+{
+  init_sync_libfuncs (UNITS_PER_WORD);
+}
+
 #include "gt-m68k.h"
diff --git a/libgcc/config.host b/libgcc/config.host
index 342d60c..a61a700 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -710,14 +710,14 @@ m68k*-*-netbsdelf*)
;;
 m68k*-*-openbsd*)
;;
-m68k-*-uclinux*)   # Motorola m68k/ColdFire running uClinux with 
uClibc
-   tmake_file="$tmake_file m68k/t-floatlib"
+m68k-*-uclinux*)   # Motorola m68k/ColdFire running uClinux with uClibc
+   tmake_file="$tmake_file m68k/t-floatlib m68k/t-linux"
md_unwind_header=m68k/linux-unwind.h
;;
 m68k-*-linux*) # Motorola m68k's running GNU/Linux
# with ELF format using glibc 2
# aka the GNU/Linux C library 6.
-   tmake_file="$tmake_file m68k/t-floatlib"
+   tmake_file="$tmake_file m68k/t-floatlib m68k/t-linux"
# If not configured with --enable-sjlj-exceptions, bump the
# libgcc version number.
if test x$enable_sjlj_exceptions != xyes; then
diff --git a/libgcc/config/m68k/linux-atomic.c 
b/libgcc/config/m68k/linux-atomic.c
new file mode 100644
index 000..6e81d6b
--- /dev/null
+++ b/libgcc/config/m68k/linux-atomic.c
@@ -0,0 +1,211 @@
+/* Linux-specific atomic operations for m68k Linux.
+   Copyright (C) 2011 Free Software Foundation, Inc.
+   Based on code contributed by CodeSourcery for ARM EABI Linux.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 3, or (at your option) any later
+version.
+
+GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+for more details.
+
+Under Section 7 of GPL version 3, you are granted additional
+permissions described in the GCC Runtime Library Exception, version
+3.1, as published by the Free Software Foundation.
+
+You should have received a copy of the GNU General Public License and
+a copy of the GCC Runtime Library Exception along with this program;
+see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+.  */
+
+/* Coldfire dropped the CAS instruction from the base M68K ISA.
+
+   GCC automatically issues a asm memory barrier when it encounters
+   a __sync_synchronize builtin.  Thus, we do not need to define this
+   builtin.
+
+   We implement byte, short and int versions of each atomic operation
+   using the kernel helper defined below.  There is no support for
+   64-bit operations yet.  */
+
+#include 
+#include 
+
+#ifndef __NR_atomic_cmpxchg_32
+#define __NR_atomic_cmpxchg_32  335
+#endif
+
+/* Kernel helper for compare-and-exchange a 32-bit value.  */
+static inline unsigned
+__kernel_cmpxchg (unsigned *mem, unsigned oldval, unsigned newval)
+{
+  register unsigned *a0 asm("a0") = mem;
+  register unsigned d2 asm("d2") = oldval;
+  register unsigned d1 asm("d1") = newval;
+  register unsigned d0 asm("d0") = __NR_atomic_cmpxchg_32;
+
+  asm volatile ("trap #0"
+   : "=r"(d0), "=r"

[PATCH 0/2] Add atomic support to m68k

2011-11-18 Thread Richard Henderson
The first patch adds support for the m68k-linux syscall.  The second
patch adds native support for the m680[2346]0 CAS instruction, and
the m68000/Coldfire TAS instruction.

Both tested only via cross-compile.  

Please test...


r~


Richard Henderson (2):
  m68k-linux: Implement atomic operations via syscall.
  m68k: Implement CAS and TAS patterns.

 gcc/config/m68k/linux.h   |4 +
 gcc/config/m68k/m68k.c|8 ++
 gcc/config/m68k/m68k.md   |9 ++
 gcc/config/m68k/sync.md   |   80 ++
 libgcc/config.host|6 +-
 libgcc/config/m68k/linux-atomic.c |  211 +
 libgcc/config/m68k/t-linux|1 +
 7 files changed, 316 insertions(+), 3 deletions(-)
 create mode 100644 gcc/config/m68k/sync.md
 create mode 100644 libgcc/config/m68k/linux-atomic.c
 create mode 100644 libgcc/config/m68k/t-linux

-- 
1.7.4.4



[PATCH 2/2] m68k: Implement CAS and TAS patterns.

2011-11-18 Thread Richard Henderson
---
 gcc/config/m68k/m68k.md |9 +
 gcc/config/m68k/sync.md |   80 +++
 2 files changed, 89 insertions(+), 0 deletions(-)
 create mode 100644 gcc/config/m68k/sync.md

diff --git a/gcc/config/m68k/m68k.md b/gcc/config/m68k/m68k.md
index 672ef0d..e4b4b59 100644
--- a/gcc/config/m68k/m68k.md
+++ b/gcc/config/m68k/m68k.md
@@ -124,6 +124,10 @@
 
 (define_constants
   [(UNSPECV_BLOCKAGE   0)
+   (UNSPECV_CAS_1  1)
+   (UNSPECV_CAS_2  2)
+   (UNSPECV_TAS_1  3)
+   (UNSPECV_TAS_2  4)
   ])
 
 ;; Registers by name.
@@ -255,6 +259,10 @@
 (const_int 0)]
(const_int 1)))
 
+;; Mode macros for integer operations.
+(define_mode_iterator I [QI HI SI])
+(define_mode_attr sz [(QI "%.b") (HI "%.w") (SI "%.l")])
+
 ;; Mode macros for floating point operations.
 ;; Valid floating point modes
 (define_mode_iterator FP [SF DF (XF "TARGET_68881")])
@@ -7806,3 +7814,4 @@
   [(set_attr "type" "ib")])
 
 (include "cf.md")
+(include "sync.md")
diff --git a/gcc/config/m68k/sync.md b/gcc/config/m68k/sync.md
new file mode 100644
index 000..9a5bcda4
--- /dev/null
+++ b/gcc/config/m68k/sync.md
@@ -0,0 +1,80 @@
+;; GCC machine description for m68k synchronization instructions.
+;; Copyright (C) 2011
+;; Free Software Foundation, Inc.
+;;
+;; This file is part of GCC.
+;;
+;; GCC is free software; you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation; either version 3, or (at your option)
+;; any later version.
+;;
+;; GCC is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;; GNU General Public License for more details.
+;;
+;; You should have received a copy of the GNU General Public License
+;; along with GCC; see the file COPYING3.  If not see
+;; .
+
+
+(define_expand "atomic_compare_and_swap"
+  [(match_operand:QI 0 "register_operand" "")  ;; bool success output
+   (match_operand:I 1 "register_operand" "")   ;; oldval output
+   (match_operand:I 2 "memory_operand" "") ;; memory
+   (match_operand:I 3 "register_operand" "")   ;; expected input
+   (match_operand:I 4 "register_operand" "")   ;; newval input
+   (match_operand:SI 5 "const_int_operand" "") ;; is_weak
+   (match_operand:SI 6 "const_int_operand" "") ;; success model
+   (match_operand:SI 7 "const_int_operand" "")];; failure model
+  "TARGET_68020 || TARGET_68040"
+{
+  emit_insn (gen_atomic_compare_and_swap_1
+(operands[0], operands[1], operands[2],
+ operands[3], operands[4]));
+  emit_insn (gen_negqi2 (operands[0], operands[0]));
+  DONE;
+})
+
+(define_insn "atomic_compare_and_swap_1"
+  [(set (match_operand:I 1 "register_operand" "=d")
+   (unspec_volatile:I
+ [(match_operand:I 2 "memory_operand" "+m")
+  (match_operand:I 3 "register_operand" "0")
+  (match_operand:I 4 "register_operand" "d")]
+ UNSPECV_CAS_1))
+   (set (match_dup 2)
+   (unspec_volatile:I
+ [(match_dup 2) (match_dup 3) (match_dup 4)]
+ UNSPECV_CAS_2))
+   (set (match_operand:QI 0 "register_operand" "=d")
+   (unspec_volatile:QI
+ [(match_dup 2) (match_dup 3) (match_dup 4)]
+ UNSPECV_CAS_2))]
+  "TARGET_68020 || TARGET_68040"
+  ;; Elide the seq if operands[0] is dead.
+  "cas %1,%4,%2\;seq %0")
+
+(define_expand "sync_test_and_setqi"
+  [(match_operand:QI 0 "register_operand" "")
+   (match_operand:QI 1 "memory_operand" "")
+   (match_operand:QI 2 "general_operand" "")]
+  "!(TARGET_68020 || TARGET_68040)"
+{
+  if (operands[2] != const1_rtx)
+FAIL;
+  emit_insn (gen_sync_test_and_setqi_1 (operands[0], operands[1]));
+  emit_insn (gen_negqi2 (operands[0], operands[0]));
+  DONE;
+})
+
+(define_insn "sync_test_and_setqi_1"
+  [(set (match_operand:QI 0 "register_operand" "=d")
+   (unspec_volatile:QI
+ [(match_operand:QI 1 "memory_operand" "+m")]
+ UNSPECV_TAS_1))
+   (set (match_dup 1)
+   (unspec_volatile:QI [(match_dup 1)] UNSPECV_TAS_2))]
+  "!(TARGET_68020 || TARGET_68040)"
+  "tas %1\;sne %0")
-- 
1.7.4.4



Re: [PATCH] PR c++/51145 - Alias template in elaborated-type-specifier

2011-11-18 Thread Jason Merrill

See my comment in the PR.

Jason


Re: [C++ Patch] PR c++/51188

2011-11-18 Thread Fabien Chêne
2011/11/18 Jason Merrill :
> On 11/18/2011 05:18 AM, Fabien Chêne wrote:
>>
>> +template<  size_t, size_t>  struct AlignedBuffer;
>> +template<  size_t size>  struct AlignedBuffer
>> +<  size, 8>  {
>> +};
>
> This testcase will break on targets where alignof(void*) != 8; just define
> the base template and remove the partial specialization.

Good catch, fixed.

> OK with that change.

I have just committed. Unfortunately, I have mentioned the wrong PR
number in the ChangeLog. Consequently, Bugzilla isn't quite happy,
shall I adjust the previous commit with the good PR number (51188) ?

-- 
Fabien


Re: [PATCH] Remove dead labels to increase superblock scope

2011-11-18 Thread Andrew Pinski
On Fri, Nov 18, 2011 at 5:11 AM, Tom de Vries  wrote:
> Hi Eric,
>
> this patch fixes an inefficiency problem I observed while working on PR50764.
>
> For the test-case of PR50764, a dead label is introduced by 
> fixup_reorder_chain
> in cfg_layout_finalize, called from pass_reorder_blocks.
> The dead label is removed by a cleanup_cfg in pass_duplicate_computed_gotos, 
> but
> is still present during pass_sched2.
> When constructing ebbs in schedule_ebbs, the dead label ends an ebb. If we
> remove the label before pass_sched2, the ebb is allowed to grow larger.
>
> The patch tries to get rid of the dead label immediately after it's 
> introduced,
> in cfg_layout_finalized.
>
> The new test gcc.dg/superblock.c uses -fno-asynchronous-unwind-tables to work
> around PR50764.
>
> bootstrapped and reg-tested on x86_64.
>
> OK for next stage 1?

ENOPATCH.

>
> Thanks,
> - Tom
>
> 2011-11-18  Tom de Vries  
>
>        * rtl.h (delete_dead_labels): Declare.
>        * cfgcleanup.c (delete_dead_labels): New function.
>        * cfglayout.c (cfg_layout_finalize): Use delete_dead_labels.
>
>        * gcc.dg/superblock.c: New test.
>


Re: [C++ Patch] PR c++/51188

2011-11-18 Thread Jason Merrill

On 11/18/2011 02:53 PM, Fabien Chêne wrote:

I have just committed. Unfortunately, I have mentioned the wrong PR
number in the ChangeLog. Consequently, Bugzilla isn't quite happy,
shall I adjust the previous commit with the good PR number (51188) ?


Yes, do adjust the ChangeLog.  I do this periodically, too...

Jason



Re: [PATCH] Remove dead labels to increase superblock scope

2011-11-18 Thread Tom de Vries
On 11/18/2011 09:16 PM, Andrew Pinski wrote:
> On Fri, Nov 18, 2011 at 5:11 AM, Tom de Vries  wrote:
>> Hi Eric,
>>
>> this patch fixes an inefficiency problem I observed while working on PR50764.
>>
>> For the test-case of PR50764, a dead label is introduced by 
>> fixup_reorder_chain
>> in cfg_layout_finalize, called from pass_reorder_blocks.
>> The dead label is removed by a cleanup_cfg in pass_duplicate_computed_gotos, 
>> but
>> is still present during pass_sched2.
>> When constructing ebbs in schedule_ebbs, the dead label ends an ebb. If we
>> remove the label before pass_sched2, the ebb is allowed to grow larger.
>>
>> The patch tries to get rid of the dead label immediately after it's 
>> introduced,
>> in cfg_layout_finalized.
>>
>> The new test gcc.dg/superblock.c uses -fno-asynchronous-unwind-tables to work
>> around PR50764.
>>
>> bootstrapped and reg-tested on x86_64.
>>
>> OK for next stage 1?
> 
> ENOPATCH.
> 

Thanks Andrew.

here it is.

Thanks,
- Tom

>>
>> 2011-11-18  Tom de Vries  
>>
>>* rtl.h (delete_dead_labels): Declare.
>>* cfgcleanup.c (delete_dead_labels): New function.
>>* cfglayout.c (cfg_layout_finalize): Use delete_dead_labels.
>>
>>* gcc.dg/superblock.c: New test.
>>

Index: gcc/rtl.h
===
--- gcc/rtl.h (revision 181377)
+++ gcc/rtl.h (working copy)
@@ -2481,6 +2481,7 @@ extern void dump_combine_total_stats (FI
 
 /* In cfgcleanup.c  */
 extern void delete_dead_jumptables (void);
+extern void delete_dead_labels (void);
 
 /* In sched-vis.c.  */
 extern void debug_bb_n_slim (int);
Index: gcc/cfgcleanup.c
===
--- gcc/cfgcleanup.c (revision 181377)
+++ gcc/cfgcleanup.c (working copy)
@@ -2900,6 +2900,37 @@ delete_dead_jumptables (void)
 }
 }
 
+/* Delete labels which are dead and can be removed.  */
+
+void
+delete_dead_labels (void)
+{
+  basic_block bb;
+
+  FOR_EACH_BB (bb)
+{
+  rtx insn;
+
+  FOR_BB_INSNS (bb, insn)
+	{
+	  if (NOTE_INSN_BASIC_BLOCK_P (insn))
+	continue;
+
+	  if (!LABEL_P (insn)
+	  || LABEL_NUSES (insn) != 0
+	  || LABEL_PRESERVE_P (insn)
+	  || LABEL_NAME (insn) != 0)
+	break;
+
+	  if (dump_file)
+	fprintf (dump_file, "Dead label %i removed\n",
+		 INSN_UID (insn));
+
+	  delete_insn (insn);
+	  break;
+	}
+}
+}
 
 /* Tidy the CFG by deleting unreachable code and whatnot.  */
 
Index: gcc/cfglayout.c
===
--- gcc/cfglayout.c (revision 181377)
+++ gcc/cfglayout.c (working copy)
@@ -1369,6 +1369,7 @@ cfg_layout_finalize (void)
 
   rebuild_jump_labels (get_insns ());
   delete_dead_jumptables ();
+  delete_dead_labels ();
 
 #ifdef ENABLE_CHECKING
   verify_insn_chain ();
Index: gcc/testsuite/gcc.dg/superblock.c
===
--- /dev/null (new file)
+++ gcc/testsuite/gcc.dg/superblock.c (revision 0)
@@ -0,0 +1,23 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fno-asynchronous-unwind-tables -fsched2-use-superblocks -fdump-rtl-sched2 -fdump-rtl-bbro" } */
+
+typedef int aligned __attribute__ ((aligned (64)));
+extern void abort (void);
+
+int bar (void *p);
+
+void
+foo (void)
+{
+  char *p = __builtin_alloca (13);
+  aligned i;
+
+  if (bar (p) || bar (&i))
+abort ();
+}
+
+/* { dg-final { scan-rtl-dump-times "0 uses" 0 "bbro"} } */
+/* { dg-final { scan-rtl-dump-times "ADVANCING TO" 2 "sched2"} } */
+/* { dg-final { cleanup-rtl-dump "bbro" } } */
+/* { dg-final { cleanup-rtl-dump "sched2" } } */
+


PR other/51174: handle architectures with no DECL_COMDAT_GROUP

2011-11-18 Thread Aldy Hernandez

Hi Richard.

David reports that on AIX, you can have DECL_COMDAT defined, but no 
DEC_COMDAT_GROUP.  Consequently tm_mangle() gets called incorrectly with 
a null.  I suggested making tm_mangle() handle nulls, but David 
preferred handling it in the caller.


I tested this patch on x86-64 Linux, and David tells me this fixes the 
problem on his AIX end.


Thanks to David for finding and fixing this problem.

OK?
* trans-mem.c (ipa_tm_create_version_alias): Handle unsupported
HAVE_COMDAT_GROUP.
(ipa_tm_create_version): Same.

Index: trans-mem.c
===
--- trans-mem.c (revision 181488)
+++ trans-mem.c (working copy)
@@ -4198,8 +4198,10 @@ ipa_tm_create_version_alias (struct cgra
   TREE_SYMBOL_REFERENCED (tm_name) = 1;
 
   /* Perform the same remapping to the comdat group.  */
-  if (DECL_COMDAT (new_decl))
+  if (DECL_COMDAT (new_decl) && HAVE_COMDAT_GROUP)
 DECL_COMDAT_GROUP (new_decl) = tm_mangle (DECL_COMDAT_GROUP (old_decl));
+  else
+DECL_COMDAT_GROUP (new_decl) = DECL_COMDAT_GROUP (old_decl);
 
   new_node = cgraph_same_body_alias (NULL, new_decl, info->new_decl);
   new_node->tm_clone = true;
@@ -4233,8 +4235,10 @@ ipa_tm_create_version (struct cgraph_nod
   TREE_SYMBOL_REFERENCED (tm_name) = 1;
 
   /* Perform the same remapping to the comdat group.  */
-  if (DECL_COMDAT (new_decl))
+  if (DECL_COMDAT (new_decl) && HAVE_COMDAT_GROUP)
 DECL_COMDAT_GROUP (new_decl) = tm_mangle (DECL_COMDAT_GROUP (old_decl));
+  else
+DECL_COMDAT_GROUP (new_decl) = DECL_COMDAT_GROUP (old_decl);
 
   new_node = cgraph_copy_node_for_versioning (old_node, new_decl, NULL, NULL);
   new_node->lowered = true;


Re: [PATCH] Remove dead labels to increase superblock scope

2011-11-18 Thread Eric Botcazou
> For the test-case of PR50764, a dead label is introduced by
> fixup_reorder_chain in cfg_layout_finalize, called from
> pass_reorder_blocks.

I presume that there is no reasonable way of preventing fixup_reorder_chain 
from introducing it or of teaching fixup_reorder_chain to remove it?

-- 
Eric Botcazou


Re: Ping! Re: [RFA/ARM][Patch 02/02]: ARM epilogues in RTL

2011-11-18 Thread Ramana Radhakrishnan
On 5 October 2011 17:04, Sameera Deshpande  wrote:
> Ping!
>
> http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01855.html


This should now be rebased given your other changes to the Thumb2
epilogues patch or is there a newer version of this patch . This
doesn't apply cleanly on top of the other patch.

Ramana


Re: [PATCH] postreload: Invalidate reg_state info at barrier/volatile insns

2011-11-18 Thread Eric Botcazou
> With the patch from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452
> the regstate information is resetted at the unspec_volatile instead of
> invalidated!

You're right.  This wouldn't have happened if the code had been properly 
commented.

> 2011-11-14  Andreas Krebbel  
>
>   * postreload.c (reload_combine): Mark reg_state as invalid at a
>   barrier if there has been a use already.

Let's be conservative instead and distinguish the two cases: in the barrier 
case, we don't change anything and just add the missing comment, along the 
lines of "Crossing a barrier resets all the use information".  In the volatile 
case, we unconditionally invalidate with a similar comment.

-- 
Eric Botcazou


Re: [Patch] make it possible for the target to rename ".tm_clone_table"

2011-11-18 Thread Joseph S. Myers
On Fri, 18 Nov 2011, Iain Sandoe wrote:

> > > Index: gcc/defaults.h
> > > ===
> > > --- gcc/defaults.h(revision 181476)
> > > +++ gcc/defaults.h(working copy)
> > > @@ -392,6 +392,14 @@ see the files COPYING3 and COPYING.RUNTIME respect
> > > #endif
> > > #endif
> > > 
> > > +/* If we have named sections, provide a name for the transaction clone
> > > +   table section.  */
> > > +#if defined (TARGET_ASM_NAMED_SECTION)
> > > +#ifndef TM_CLONE_TABLE_SECTION_NAME
> > > +#define TM_CLONE_TABLE_SECTION_NAME ".tm_clone_table"
> > > +#endif
> > > +#endif
> > > +
> > 
> > This, together with the unconditional use in varasm.c, will lead to a
> > bootstrap failure on Tru64 UNIX, which lacks named sections completely.
> 
> right, it was worrying me what a target without named sections does -
> ... I can easily remove the #if defined (TARGET_ASM_NAMED_SECTION)
> ... what happens when the code runs then?

Conditions on definedness of TARGET_ASM_NAMED_SECTION are rather fragile - 
it's a target hook not properly a target macro, it shouldn't need to be 
defined in tm.h.  There are two such tests in defaults.h and two in 
target-def.h, but we should remove them rather than adding to them.  
TM_CLONE_TABLE_SECTION_NAME would better be a target hook, not a macro.

As I noted in  
(when cleaning up another such #ifdef conditional) there are actually very 
few targets without named sections.  And if we deprecate the a.out OpenBSD 
targets then there will be even fewer.

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


Re: [Patch Darwin] be more friendly to gdb

2011-11-18 Thread Mike Stump
On Nov 17, 2011, at 8:24 AM, Iain Sandoe wrote:
> As things stand, Darwin's 'as' cannot produce dwarf debug.

> OK for trunk?

Ok.


Fix gcc.dg/cpp/assert4.c for non-GNU Linux systems

2011-11-18 Thread Joseph S. Myers
The testcase gcc.dg/cpp/assert4.c, which tests that #system(linux) is true 
if and only if __gnu_linux__ is defined, wasn't updated for the changes 
associated with Android support that arranged for __linux__ to be defined 
for all systems with the Linux kernel but __gnu_linux__ only to be defined 
for systems using some form of glibc (not counting uClibc) with that 
kernel.  I've applied this patch to make the test test __linux__ instead 
of __gnu_linux__.  Tested x86_64-unknown-linux-gnu.

2011-11-18  Joseph Myers  

* gcc.dg/cpp/assert4.c: Test __linux__, not __gnu_linux__.

Index: gcc.dg/cpp/assert4.c
===
--- gcc.dg/cpp/assert4.c(revision 181494)
+++ gcc.dg/cpp/assert4.c(working copy)
@@ -1,4 +1,4 @@
-/* Copyright (C) 2003, 2006, 2008 Free Software Foundation, Inc.
+/* Copyright (C) 2003, 2006, 2008, 2009, 2011 Free Software Foundation, Inc.
Test builtin preprocessor assertions.
By Kaveh Ghazi .  */
 
@@ -7,7 +7,7 @@
 
 /* Check for #system assertions.  */
 
-#if defined __gnu_linux__
+#if defined __linux__
 # if !#system(linux) || !#system(unix) || !#system(posix)
 #  error
 # endif

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


Re: PING: [PATCH, ARM, iWMMXt][3/5]: built in define and expand

2011-11-18 Thread Ramana Radhakrishnan
On 20 October 2011 08:39, Xinyu Qi  wrote:
> Ping
>
> http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01103.html
>
>        * config/arm/arm.c (enum arm_builtins): Revise built-in fcode.
>        (builtin_description bdesc_2arg): Revise built in declaration.
>        (builtin_description bdesc_1arg): Likewise.
>        (arm_init_iwmmxt_builtins): Revise built in initialization.
>        (arm_expand_builtin): Revise built in expansion.
>

This currently doesn't apply - can you take a look ?


Re: [RFA/ARM][Patch]: Fix NEG_POOL_RANGE

2011-11-18 Thread Ramana Radhakrishnan
On 17 November 2011 15:16, Sameera Deshpande  wrote:
> Hi!
>
> Please find attached the patch updating NEG_POOL_RANGE from 1008 to
> 1020 -(8 + ).

This is OK - can you add a comment around the neg_pool_range attribute
in arm.md stating that the limit should essentially be  -
(8 +  ?.

cheers
Ramana


Re: [PATCH] Remove dead labels to increase superblock scope

2011-11-18 Thread Tom de Vries
On 11/18/2011 10:29 PM, Eric Botcazou wrote:
>> For the test-case of PR50764, a dead label is introduced by
>> fixup_reorder_chain in cfg_layout_finalize, called from
>> pass_reorder_blocks.
> 
> I presume that there is no reasonable way of preventing fixup_reorder_chain 
> from introducing it or of teaching fixup_reorder_chain to remove it?
> 

This (untested) patch also removes the dead label for the PR, and I think it is
safe.
...
Index: cfglayout.c
===
--- cfglayout.c (revision 181377)
+++ cfglayout.c (working copy)
@@ -702,6 +702,21 @@ relink_block_chain (bool stay_in_cfglayo
 }
 

+static bool
+forced_label_p (rtx label)
+{
+  rtx insn, forced_label;
+  for (insn = forced_labels; insn; insn = XEXP (insn, 1))
+{
+  forced_label = XEXP (insn, 0);
+  if (!LABEL_P (forced_label))
+   continue;
+  if (forced_label == label)
+   return true;
+}
+  return false;
+}
+
 /* Given a reorder chain, rearrange the code to match.  */

 static void
@@ -857,6 +872,12 @@ fixup_reorder_chain (void)
   (e_taken->src, e_taken->dest));
  e_taken->flags |= EDGE_FALLTHRU;
  update_br_prob_note (bb);
+ if (LABEL_NUSES (ret_label) == 0
+ && !LABEL_PRESERVE_P (ret_label)
+ && LABEL_NAME (ret_label) == NULL
+ && !forced_label_p (ret_label)
+ && single_pred_p (e_taken->dest))
+   delete_insn (ret_label);
  continue;
}
}
...

But I see 2 potential issues:
- it only catches this case in fixup_reorder_chain. I don't know if there are
  more cases, but the earlier catch-all-afterwards patch surely will catch
  those, this patch probably not.
- I'm not sure if the use count will drop always drop to 0 in
  fixup_reorder_chain, that might only happen after rebuild_jump_labels.

Thanks,
- Tom


Re: [RFA/ARM][Patch 01/02]: Thumb2 epilogue in RTL

2011-11-18 Thread Ramana Radhakrishnan
On 10 November 2011 18:07, Sameera Deshpande  wrote:
> Please find attached the reworked patch.

OK but for a very small bit .

I'll note that we need to add support for the iwMMXt registers but the
attached patch (untested) should be what is needed to support the
iwMMxt registers and this should be something that should be
incorporated into your ARM RTL epilogues patch as well. My
understanding is that this is all you should need to do as there is a
wldrd as a part of *iwmmx*_movdi instruction and therefore this should
just work in this form.

Xinyu can you help in testing this patch once this is applied along
with your other patches to turn on Thumb2 for iwmmxt ?

cheers
Ramana
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 708142e..1fb86fd 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -264,7 +264,7 @@ static reg_class_t arm_preferred_rename_class (reg_class_t 
rclass);
 static unsigned int arm_autovectorize_vector_sizes (void);
 static int arm_default_branch_cost (bool, bool);
 static int arm_cortex_a5_branch_cost (bool, bool);
-
+static void arm_epilogue_restore_iwmmxt_regs (void);
 
 /* Table of machine attributes.  */
 static const struct attribute_spec arm_attribute_table[] =
@@ -22563,6 +22563,30 @@ thumb2_expand_return (void)
 }
 }
 
+static void
+arm_epilogue_restore_iwmmxt_regs (void)
+{
+   
+  int reg;
+  for (reg = FIRST_IWMMXT_REGNUM; reg <= LAST_IWMMXT_REGNUM; reg++)
+if (df_regs_ever_live_p (reg) && !call_used_regs[reg])
+  {
+   rtx tmp = gen_rtx_SET (DImode,
+  gen_rtx_REG (reg, DImode),
+  gen_frame_mem (DImode, 
+ gen_rtx_POST_INC 
+ (DImode,
+  stack_pointer_rtx)));
+   rtx dwarf = alloc_reg_note (REG_CFA_RESTORE,
+   gen_rtx_REG (reg, DImode),
+   NULL_RTX);
+   
+   RTX_FRAME_RELATED_P (tmp) = 1;
+   emit_insn (tmp);
+  }
+  
+}
+
 /* Generate RTL to represent a Thumb-2 epilogue.
 
Note that this RTL does not include the
@@ -22652,6 +22676,10 @@ thumb2_expand_epilogue (void)
   /* iWMMXt is not supported when Thumb-2 in use.  If it were, we would
  want to be restoring the appropriate iWMMXt regs here, in a similar
  way to arm_output_epilogue.  */
+  if (TARGET_IWMMXT)
+{
+  arm_epilogue_restore_iwmmxt_regs ();
+}
 
   /* If there are registers to restore, make it happen.  */
   if (saved_regs_mask)


Re: PING: [PATCH, ARM, iWMMXt][4/5]: WMMX machine description

2011-11-18 Thread Ramana Radhakrishnan
Hi Xinyu,

This doesn't apply cleanly currently on trunk and the reject appears
to come from iwmmxt.md and I've not yet investigated why.

Can you have a look ?

cheers
Ramana

On 26 September 2011 04:22, Xinyu Qi  wrote:
> Ping.
>
> http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00279.html
>
>        * config/arm/arm.c (arm_output_iwmmxt_shift_immediate): New function.
>        (arm_output_iwmmxt_tinsr): Likewise.
>        * config/arm/arm-protos.h (arm_output_iwmmxt_shift_immediate): Declare.
>        (arm_output_iwmmxt_tinsr): Likewise.
>        * config/arm/iwmmxt.md (WCGR0, WCGR1, WCGR2, WCGR3): New constant.
>        (iwmmxt_psadbw, iwmmxt_walign, iwmmxt_tmrc, iwmmxt_tmcr): Delete.
>        (iwmmxt_tbcstqi, iwmmxt_tbcsthi, iwmmxt_tbcstsi): Likewise
>        (*iwmmxt_clrv8qi, *iwmmxt_clrv4hi, *iwmmxt_clrv2si): Likewise.
>        (tbcstv8qi, tbcstv4hi, tbsctv2si): New pattern.
>        (iwmmxt_clrv8qi, iwmmxt_clrv4hi, iwmmxt_clrv2si): Likewise.
>        (*and3_iwmmxt, *ior3_iwmmxt, *xor3_iwmmxt): Likewise.
>        (rori3, ashri3_iwmmxt, lshri3_iwmmxt): Likewise.
>        (ashli3_iwmmxt, iwmmxt_waligni, iwmmxt_walignr): Likewise.
>        (iwmmxt_walignr0, iwmmxt_walignr1): Likewise.
>        (iwmmxt_walignr2, iwmmxt_walignr3): Likewise.
>        (iwmmxt_setwcgr0, iwmmxt_setwcgr1): Likewise.
>        (iwmmxt_setwcgr2, iwmmxt_setwcgr3): Likewise.
>        (iwmmxt_getwcgr0, iwmmxt_getwcgr1): Likewise.
>        (iwmmxt_getwcgr2, iwmmxt_getwcgr3): Likewise.
>        (All instruction patterns): Add wtype attribute.
>        (*iwmmxt_arm_movdi, *iwmmxt_movsi_insn): iWMMXt coexist with vfp.
>        (iwmmxt_uavgrndv8qi3, iwmmxt_uavgrndv4hi3): Revise the pattern.
>        (iwmmxt_uavgv8qi3, iwmmxt_uavgv4hi3): Likewise.
>        (iwmmxt_tinsrb, iwmmxt_tinsrh, iwmmxt_tinsrw):Likewise.
>        (eqv8qi3, eqv4hi3, eqv2si3, gtuv8qi3): Likewise.
>        (gtuv4hi3, gtuv2si3, gtv8qi3, gtv4hi3, gtv2si3): Likewise.
>        (iwmmxt_wunpckihh, iwmmxt_wunpckihw, iwmmxt_wunpckilh): Likewise.
>        (iwmmxt_wunpckilw, iwmmxt_wunpckehub, iwmmxt_wunpckehuh): Likewise.
>        (iwmmxt_wunpckehuw, iwmmxt_wunpckehsb, iwmmxt_wunpckehsh): Likewise.
>        (iwmmxt_wunpckehsw, iwmmxt_wunpckelub, iwmmxt_wunpckeluh): Likewise.
>        (iwmmxt_wunpckeluw, iwmmxt_wunpckelsb, iwmmxt_wunpckelsh): Likewise.
>        (iwmmxt_wunpckelsw, iwmmxt_wmadds, iwmmxt_wmaddu): Likewise.
>        (iwmmxt_wsadb, iwmmxt_wsadh, iwmmxt_wsadbz, iwmmxt_wsadhz): Likewise.
>        (iwmmxt2.md): Include.
>        * config/arm/iwmmxt2.md: New file.
>        * config/arm/iterators.md (VMMX2): New mode_iterator.
>        * config/arm/arm.md (wtype): New attribute.
>        (UNSPEC_WMADDS, UNSPEC_WMADDU): Delete.
>        (UNSPEC_WALIGNI): New unspec.
>        * config/arm/t-arm (MD_INCLUDES): Add iwmmxt2.md.
>
> At 2011-09-05 17:55:34,"Xinyu Qi"  wrote:
>> At 2011-08-18 10:21:01,"Ramana Radhakrishnan"
>>  wrote:
>> > On 14 July 2011 08:45, Xinyu Qi  wrote:
>> > >> Hi,
>> > >>
>> > >> It is the fourth part of iWMMXt maintenance.
>> > >>
>> >
>> > Can this be broken down further. ? I'll have to do this again but
>> > there are some initial comments below for some discussion.
>>
>> >
>> > >  (*iwmmxt_arm_movdi, *iwmmxt_movsi_insn, iwmmxt_uavgrndv8qi3,
>> > iwmmxt_uavgrndv4hi3, iwmmxt_uavgv8qi3, iwmmxt_uavgv4hi3, iwmmxt_tinsrb,
>> > iwmmxt_tinsrh, iwmmxt_tinsrw, eqv8qi3, eqv4hi3, eqv2si3, gtuv8qi3,
>> gtuv4hi3,
>> > gtuv2si3, gtv8qi3, gtv4hi3, gtv2si3, iwmmxt_wunpckihb, iwmmxt_wunpckihh,
>> > iwmmxt_wunpckihw, iwmmxt_wunpckilb, iwmmxt_wunpckilh, iwmmxt_wunpckilw,
>> > iwmmxt_wunpckehub, iwmmxt_wunpckehuh, iwmmxt_wunpckehuw,
>> iwmmxt_wunpckehsb,
>> > iwmmxt_wunpckehsh, iwmmxt_wunpckehsw, iwmmxt_wunpckelub,
>> iwmmxt_wunpckeluh,
>> > iwmmxt_wunpckeluw, iwmmxt_wunpckelsb, iwmmxt_wunpckelsh,
>> iwmmxt_wunpckelsw,
>> > iwmmxt_wmadds, iwmmxt_wmaddu, iwmmxt_wsadb, iwmmxt_wsadh, iwmmxt_wsadbz,
>> > iwmmxt_wsadhz): Revise.
>> >
>> > Revise to do what ?
>>
>> Sorry for late response.
>>
>> Some of them have incorrect RTL templates. For example, see iwmmxt_uavgv8qi3
>> Its old RTL template is:
>>   [(set (match_operand:V8QI                 0 "register_operand" "=y")
>>         (ashiftrt:V8QI (plus:V8QI
>>                           (match_operand:V8QI 1 "register_operand" "y")
>>                                  (match_operand:V8QI 2 "register_operand" 
>> "y"))
>>                             (const_int 1)))]
>>
>> According to the assembly behavior of wavg2b, the correct one should be:
>>   [(set (match_operand:V8QI  0 "register_operand" "=y")
>>         (truncate:V8QI
>>            (lshiftrt:V8HI
>>              (plus:V8HI (zero_extend:V8HI (match_operand:V8QI 1
>> "register_operand" "y"))
>>                         (zero_extend:V8HI (match_operand:V8QI 2
>> "register_operand" "y")))
>>            (const_int 1]
>>
>> Consider the case:
>> The Operation on element 0x01 and 0xff: gcc with old RTL template would 
>> optimize
>> to the result 0x00.That is:
>> 0x01 + 0xf

[Patch, Fortran] PR50640, PR51207 - fix select_type_12

2011-11-18 Thread Tobias Burnus
The patch in class.c for PR50640 makes the default initializer 
("__def_init_)TREE_READONLY. I also set attr.subroutine for __copy_, 
which is not needed but its lacking irritated me once when stepping 
through trans*.c.


The patch in trans-decl.c/trans.h fixes a 4.7 regressions (P1), which 
causes gfortran.dg/select_type_12.f03 to fail. The actual regression is 
due to a middle-end change, but it can be easier fixed on the front-end 
side. The problem occurs for a derived type that is declared in a 
procedure, but only used in a nested procedure. The vtable is 
consequently generated in the scope of the parent procedure.


As Michael suggested, a solution is to place the vtable at the top 
level. However, that is not sufficient, one also needs to place the 
default member function __copy_ in the top level as its address 
is used in the vtable. Fortunately, user type-bound procedures are only 
allowed for derived-types declared in the specification part of a 
module. Hence, those are by construction in the toplevel.


The patch has been bootstrapped and regtested on x86-64-linux.
OK for the trunk?

Tobias

PS: I see the following unrelated test-suite failures:
- gfortran.fortran-torture/execute/arrayarg.f90 (PR middle-end/51134, 
memset is misoptimized, P1 [4.7], wrong-code)
- gfortran.fortran-torture/execute/entry_4.f90 (PR middle-end/50628, P1 
[4.7], wrong-code)

- gfortran.dg/realloc_on_assign_5.f03 (PR fortran/47674, wrong-code)
2011-11-18  Tobias Burnus  

	PR fortran/51207
	* class.c (gfc_find_derived_vtab): Mark __def_init as PARAMETER
	and hence as TREE_READONLY; add subroutine attribute to
	__copy_ procedure.

	PR fortran/50640
	* trans.h (GFC_DECL_PUSH_TOPLEVEL): New DECL_LANG_FLAG_7.
	* trans-decl.c (gfc_get_symbol_decl): Mark __def_init and vtab as
	GFC_DECL_PUSH_TOPLEVEL.
	(gfc_generate_function_code): If GFC_DECL_PUSH_TOPLEVEL, push it there.
	(build_function_decl): Push __copy_ procedure to the toplevel.


diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c
index dc76ad1..bcb2d0b 100644
--- a/gcc/fortran/class.c
+++ b/gcc/fortran/class.c
@@ -522,7 +522,7 @@ gfc_find_derived_vtab (gfc_symbol *derived)
 		  def_init->attr.target = 1;
 		  def_init->attr.save = SAVE_IMPLICIT;
 		  def_init->attr.access = ACCESS_PUBLIC;
-		  def_init->attr.flavor = FL_VARIABLE;
+		  def_init->attr.flavor = FL_PARAMETER;
 		  gfc_set_sym_referenced (def_init);
 		  def_init->ts.type = BT_DERIVED;
 		  def_init->ts.u.derived = derived;
@@ -552,6 +552,7 @@ gfc_find_derived_vtab (gfc_symbol *derived)
 		  gfc_get_symbol (name, sub_ns, ©);
 		  sub_ns->proc_name = copy;
 		  copy->attr.flavor = FL_PROCEDURE;
+		  copy->attr.subroutine = 1;
 		  copy->attr.if_source = IFSRC_DECL;
 		  if (ns->proc_name->attr.flavor == FL_MODULE)
 		copy->module = ns->proc_name->name;
diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index 02c0ed7..fc8a9ed 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -1471,6 +1471,10 @@ gfc_get_symbol_decl (gfc_symbol * sym)
   && !sym->attr.proc_pointer)
 DECL_BY_REFERENCE (decl) = 1;
 
+  if (sym->attr.vtab
+  || (sym->name[0] == '_' && strncmp ("__def_init", sym->name, 10) == 0))
+GFC_DECL_PUSH_TOPLEVEL (decl) = 1;
+
   return decl;
 }
 
@@ -1891,7 +1895,8 @@ build_function_decl (gfc_symbol * sym, bool global)
   /* Layout the function declaration and put it in the binding level
  of the current function.  */
 
-  if (global)
+  if (global
+  || (sym->name[0] == '_' && strncmp ("__copy", sym->name, 6) == 0))
 pushdecl_top_level (fndecl);
   else
 pushdecl (fndecl);
@@ -5316,7 +5321,10 @@ gfc_generate_function_code (gfc_namespace * ns)
 
   next = DECL_CHAIN (decl);
   DECL_CHAIN (decl) = NULL_TREE;
-  pushdecl (decl);
+  if (GFC_DECL_PUSH_TOPLEVEL (decl))
+	pushdecl_top_level (decl);
+  else
+	pushdecl (decl);
   decl = next;
 }
   saved_function_decls = NULL_TREE;
diff --git a/gcc/fortran/trans.h b/gcc/fortran/trans.h
index 22033d3..8fc7599 100644
--- a/gcc/fortran/trans.h
+++ b/gcc/fortran/trans.h
@@ -802,6 +802,7 @@ struct GTY((variable_size)) lang_decl {
 #define GFC_DECL_CRAY_POINTEE(node) DECL_LANG_FLAG_4(node)
 #define GFC_DECL_RESULT(node) DECL_LANG_FLAG_5(node)
 #define GFC_DECL_SUBREF_ARRAY_P(node) DECL_LANG_FLAG_6(node)
+#define GFC_DECL_PUSH_TOPLEVEL(node) DECL_LANG_FLAG_7(node)
 
 /* An array descriptor.  */
 #define GFC_DESCRIPTOR_TYPE_P(node) TYPE_LANG_FLAG_1(node)


Fwd: Re: Links to release criteria?

2011-11-18 Thread Diego Novillo


Re-posting to gcc-patches.


Diego.

 Original Message 
Subject: Re: Links to release criteria?
Date: Fri, 18 Nov 2011 15:05:24 -0800
From: Diego Novillo 
To: Gerald Pfeifer 
CC: Richard Guenther , g...@gcc.gnu.org

On Fri, Nov 18, 2011 at 07:54, Gerald Pfeifer  wrote:

On Thu, 17 Nov 2011, Diego Novillo wrote:

I was thinking changing the text:

Active development: GCC 4.7.0 (changes)

to

Active development: GCC 4.7.0 (changes, release criteria)


Sounds good to me!


Or simply make 'GCC 4.7.0' a link to a 4.7-specific page.


I'm not sure one would expect release criteria there?  And I think it's
nice to have a larger difference between "released" and "forthcoming"
as we currently have it, but that's more of a feeling.

How about you making this an explicit link as you suggest?


Sure.  I committed the following change:

Index: index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.824
diff -u -d -u -p -r1.824 index.html
--- index.html  15 Nov 2011 06:01:24 -  1.824
+++ index.html  18 Nov 2011 23:03:21 -
@@ -170,7 +170,7 @@ Any additions?  Don't be shy, send them
 

 Active development:
-  GCC 4.7.0 (changes)
+  GCC 4.7.0 (changes, release criteria)
 
   Status:
   


[Patch/RFC] PR 51216

2011-11-18 Thread Paolo Carlini

Hi,

is this the right place to handle these TREE_CODEs and avoid the ICEs on 
invalid or should we do something else/earlier?


(tested x86_64-linux)

Thanks,
Paolo.

///
Index: testsuite/g++.dg/cpp0x/pr51216.C
===
--- testsuite/g++.dg/cpp0x/pr51216.C(revision 0)
+++ testsuite/g++.dg/cpp0x/pr51216.C(revision 0)
@@ -0,0 +1,10 @@
+// PR c++/51216
+// { dg-options "-std=c++0x" }
+
+void foo()
+{
+  int i = ({ if (1) ; });   // { dg-error "ignored" }
+  int j = ({ for (;;) ; }); // { dg-error "ignored" }
+  int k = ({ while (1) ; });// { dg-error "ignored" }
+  int l = ({ do { } while (1); });  // { dg-error "ignored" }
+}
Index: cp/semantics.c
===
--- cp/semantics.c  (revision 181494)
+++ cp/semantics.c  (working copy)
@@ -8178,6 +8178,10 @@ potential_constant_expression_1 (tree t, bool want
 case EXPR_STMT:
 case BIND_EXPR:
 case TRANSACTION_EXPR:
+case IF_STMT:
+case DO_STMT:
+case FOR_STMT:
+case WHILE_STMT:
   if (flags & tf_error)
 error ("expression %qE is not a constant-expression", t);
   return false;


Re: [trunk] RFS: translate built-in include paths for sysroot (issue5394041)

2011-11-18 Thread 沈涵
Hi, Joseph, thanks!

ChangeLog entries added to the issue description.

ChangeLog
* Makefile.in (GPLUSPLUS_INCLUDE_DIR_ADD_SYSROOT): add a macro
definition to compile command.
* cppdefault.c (GPLUSPLUS_INCLUDE_DIR_ADD_SYSROOT): replace hard
coded "add_sysroot" field with the control macro.
* configure.ac (gcc_gxx_include_dir_add_sysroot): add a flag
variable to control whether sysroot should be prepended to gxx
include dir.
* configure : Regenerate.

Yeah, I should include the URL for the previous discussion in the
mail. (I previously put it in the issue description together with the
rationale.)

This is a follow up for issue - http://codereview.appspot.com/4641076.
The rationale for this patch is also copied here:
==

The setup:

Configuring a toolchain targeting x86-64 GNU Linux (Ubuntu Lucid), as a
cross-compiler. Using a sysroot to provide the Lucid headers+libraries,
with the sysroot path being within the GCC install tree. Want to use the
Lucid system libstdc++ and headers, which means that I'm not
building/installing libstdc++-v3.

So, configuring with:
--with-sysroot="$SYSROOT"
--disable-libstdc++-v3 \
--with-gxx-include-dir="$SYSROOT/usr/include/c++/4.4" \
(among other options).

Hoping to support two usage models with this configuration, w.r.t. use of
the sysroot:

(1) somebody installs the sysroot in the normal location relative to the
GCC install, and relocates the whole bundle (sysroot+GCC). This works
great AFAICT, GCC finds its includes (including the C++ includes) thanks
to the add_standard_paths iprefix handling.

(2) somebody installs the sysroot in a non-standard location, and uses
--sysroot to try to access it. This works fine for the C headers, but
doesn't work.

For the C headers, add_standard_paths prepends the sysroot location to
the /usr/include path (since that's what's specified in cppdefault.c for
that path). It doesn't do the same for the C++ include path, though
(again, as specified in cppdefault.c).

add_standard_paths doesn't attempt to relocate built-in include paths that
start with the compiled-in sysroot location (e.g., the g++ include dir, in
this case). This isn't surprising really: normally you either prepend the
sysroot location or you don't (as specified by cppdefault.c); none of the
built-in paths normally *start* with the sysroot location and need to be
relocated. However, in this odd-ball case of trying to use the C++ headers
from the sysroot, one of the paths *does* need to be relocated in this way.
=

Chris(cgd@) provided a patch for the issue, but there was a different opinion,
my patch here is just coded as suggested.

Tested before/after on a x86_64-unknown-linux-gnu system, with
--enable-languages=all, RUNTESTFLAGS='--target_board=unix\{-m32,-m64\}'.
No changes in test results.

-Han

On Fri, Nov 18, 2011 at 8:54 AM, Joseph S. Myers
 wrote:
>
> On Tue, 15 Nov 2011, Han Shen wrote:
>
> > 2011-11-15   Han Shen  
> >
> >       * gcc/Makefile.in:
> >       * gcc/configure:
> >       * gcc/cppdefault.c:
>
> You need to include the full ChangeLog entries with your patch.  Note that
> paths in ChangeLogs are relative to the directory with the ChangeLog, so
> no gcc/ in this case.
>
> Please also include the full rationale with your patch *and URLs for the
> previous discussion* (from June, it seems) so that reviewers don't need to
> track that down themselves.
>
> > diff --git a/gcc/configure b/gcc/configure
> > index 99334ce..364d8c2 100755
> > --- a/gcc/configure
> > +++ b/gcc/configure
>
> It's not possible to review this patch as is because you've only included
> the changes to the generated file configure, not to its source file
> configure.ac.  Please make sure that your resubmission includes all the
> source file changes.  (There is no need to include the changes to the
> generated file configure at all in the submission; the ChangeLog entry can
> just mention it as "* configure: Regenerate.".)
>
> --
> Joseph S. Myers
> jos...@codesourcery.com


Re: Memset/memcpy patch

2011-11-18 Thread Jan Hubicka
> Given that x86 memset/memcpy is still broken, I think we should revert
> it for now.

Well, looking into the code, the SSE alignment issues needs work - the
alignment test merely tests whether some alignmnet is known not whether 16 byte
alignment is known that is the cause of failures in 32bit bootstrap.  I 
originally
convinced myself that this is safe since we soot for unaligned load/stores 
anyway.


I've commited the following patch that disabled SSE codegen and unbreaks atom
bootstrap.  This seems more sensible to me given that the patch cumulated some
good improvements on the non-SSE path as well and we could return into the SSE
alignment issues incremntally.  There is still falure in the fortran testcase
that I am convinced is previously latent issue.

I will be offline tomorrow.  If there are futher serious problems, just fell
free to revert the changes and we could look into them for next stage1.

Honza

* i386.c (atom_cost): Disable SSE loop until alignment issues are fixed.
Index: i386.c
===
--- i386.c  (revision 181479)
+++ i386.c  (working copy)
@@ -1783,18 +1783,18 @@ struct processor_costs atom_cost = {
   /* stringop_algs for memcpy.  
  SSE loops works best on Atom, but fall back into non-SSE unrolled loop 
variant
  if that fails.  */
-  {{{libcall, {{4096, sse_loop}, {4096, unrolled_loop}, {-1, libcall}}}, /* 
Known alignment.  */
-{libcall, {{4096, sse_loop}, {4096, unrolled_loop}, {-1, libcall,
-   {{libcall, {{2048, sse_loop}, {2048, unrolled_loop}, {-1, libcall}}}, /* 
Unknown alignment.  */
-{libcall, {{2048, sse_loop}, {2048, unrolled_loop},
+  {{{libcall, {{4096, unrolled_loop}, {-1, libcall}}}, /* Known alignment.  */
+{libcall, {{4096, unrolled_loop}, {-1, libcall,
+   {{libcall, {{2048, unrolled_loop}, {-1, libcall}}}, /* Unknown alignment.  
*/
+{libcall, {{2048, unrolled_loop},
   {-1, libcall},
 
   /* stringop_algs for memset.  */
-  {{{libcall, {{4096, sse_loop}, {4096, unrolled_loop}, {-1, libcall}}}, /* 
Known alignment.  */
-{libcall, {{4096, sse_loop}, {4096, unrolled_loop}, {-1, libcall,
-   {{libcall, {{1024, sse_loop}, {1024, unrolled_loop}, /* Unknown 
alignment.  */
+  {{{libcall, {{4096, unrolled_loop}, {-1, libcall}}}, /* Known alignment.  */
+{libcall, {{4096, unrolled_loop}, {-1, libcall,
+   {{libcall, {{1024, unrolled_loop},   /* Unknown alignment.  */
   {-1, libcall}}},
-{libcall, {{2048, sse_loop}, {2048, unrolled_loop},
+{libcall, {{2048, unrolled_loop},
   {-1, libcall},
   1,   /* scalar_stmt_cost.  */
   1,   /* scalar load_cost.  */


Re: [wwwdocs] add news items for TM work

2011-11-18 Thread Gerald Pfeifer

On Fri, 18 Nov 2011, Aldy Hernandez wrote:

Reading this I was wondering which platforms.  On the other page it
says x86 and alpha; should we just use this here, or were you thinking
to keep this more marketing speak? ;-)

*blush*, yes... marketing speak.  Seeing that people are contributing other
ports (or planning on), I didn't want to be too restrictive in the news file.


Fair enough, let's keep it as is then.


How does this look?


Looks good to me.  I was actually meaning to imply you can go ahead
in my previous mail. :-)

Gerald


Re: Minor contrib.texi update

2011-11-18 Thread Gerald Pfeifer
On Tue, 15 Nov 2011, Jeff Law wrote:
> Attached wrong file as Andrey pointed out earlier...  Here's the right
> one...  Oh how I wish thunderbird would show the attachment inline...

Ok.

Just mind the long line and it's Rawhide (uppercase), I think.

Gerald


Re: [PATCH] PR c++/51145 - Alias template in elaborated-type-specifier

2011-11-18 Thread Gabriel Dos Reis
Just a terminology note: it should be "template alias" and not the
other way around.