[PATCH, testsuite]: Tweak obj-c++ TLS errors

[Uros Bizjak]

Hello!

Recent commit changed various c++ TLS errors. Following patch tweaks
obj-c++ testcase accordingly.

2012-10-11  Uros Bizjak  

* obj-c++.dg/tls/init-2.mm: Tweak errors.

Tested on alphaev68-pc-linux-gnu, committed to mainline SVN.

Uros.
Index: obj-c++.dg/tls/init-2.mm
===
--- obj-c++.dg/tls/init-2.mm(revision 192347)
+++ obj-c++.dg/tls/init-2.mm(working copy)
@@ -2,13 +2,13 @@
 /* { dg-require-effective-target tls } */
 
 extern __thread int i;
-__thread int *p = &i;   /* { dg-error "dynamically initialized" } */
+__thread int *p = &i;  /* { dg-error "dynamic initialization" } */
 
 extern int f();
-__thread int j = f();   /* { dg-error "dynamically initialized" } */
+__thread int j = f();  /* { dg-error "dynamic initialization" } */
 
 struct S
 {
   S();
 };
-__thread S s;   /* { dg-error "" } two errors here */
+__thread S s;  /* { dg-error "dynamic initialization" } */

Re: [C++] Omit overflow check for new char[n]

[Dodji Seketeli]

Florian Weimer  a écrit:

> On 10/10/2012 06:02 PM, Dodji Seketeli wrote:
>
>> I just have one question for own education.
>>
>> Regarding:
>>
>> @@ -2450,7 +2450,13 @@
>>if (array_p && TYPE_VEC_NEW_USES_COOKIE (elt_type))
>>  size = size_binop (PLUS_EXPR, size, cookie_size);
>>else
>> -cookie_size = NULL_TREE;
>> +{
>> +  cookie_size = NULL_TREE;
>> +  /* No size arithmetic necessary, so the size check is
>> + not needed. */
>> +  if (outer_nelts_check != NULL && inner_size == double_int_one)
>> +outer_nelts_check = NULL_TREE;
>> +}
>>
>> I couldn't find where in code is TYPE_VEC_NEW_USES_COOKIE is set.  Is it
>> still used?
>
> It's set in gcc/cp/class.c:
>
>5191   /* Figure out whether or not we will need a cookie when
> dynamically
>5192  allocating an array of this type.  */
>5193   TYPE_LANG_SPECIFIC (t)->u.c.vec_new_uses_cookie
>5194 = type_requires_array_cookie (t);

Ah, I see.  So maybe that statement should be trivially replaced by:

TYPE_VEC_NEW_USES_COOKIE (t) = type_requires_array_cookie (t);

for better maintainability?

> I'm not sure if we've got proper test coverage for the concrete cookie
> value, but the test case I've included implicitly check if there's a
> cookie if there's a non-trivial destructor.

I see, Thanks.

-- 
Dodji

Re: [v3] Fix Solaris symbol versioning (PR libstdc++/54872)

[Rainer Orth]

Jonathan Wakely  writes:

>> 2012-10-10  Rainer Orth  
>>
>>         PR libstdc++/54872
>>         * config/abi/pre/gnu.ver (GLIBCXX_3.4.11) [!__sun__ && !__svr4__]:
>>         Don't export _ZNSt12system_errorC*.
>
> OK, thanks, and sorry for causing the problem!

No worries, I just didn't get around to investigating earlier.

Rainer

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

Re: libbacktrace patch committed: Trace through shared libraries

[Rainer Orth]

Ian Lance Taylor  writes:

> On Wed, Oct 10, 2012 at 7:13 AM, Rainer Orth
>  wrote:
>>
>> Solaris 10 Update 10 or sufficiently recent linker patches introduced
>> dl_iterate_phdr on S10 as a backport from Solaris 11, but unlike S11, it
>> lives in libdl.so only.  The current dl_iterate_phdr check misses that,
>> and given that it's only available in the most recent update, it's
>> probably best to avoid d_i_p on Solaris 10 altogether.
>
> Does this patch fix the problem?

Yes, works like a charm: Solaris 10/x86 results (both go and libgo) are
back to normal.  I'm only seeing two failures:

The 32-bit net/http test tails (may be transient):

--- FAIL: http_test.TestTransportPersistConnLeak (3.53 seconds)
:0: goroutine growth: 106 -> 181 -> 125 (delta: 19)
:0: too many new goroutines
FAIL
FAIL: net/http

FAIL: runtime/pprof

Already reported as PR go/54873.

Thanks.
Rainer

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

[doc] Vector operations

[Marc Glisse]

Hello,

this documents both my latest C++ FE patch, something I noticed while 
doing the FE work (shifts can mix vectors and scalars) and the result of 
the conversation with Richard B on how the middle-end should model vector 
truth values. The patch is a little early compared to the code 
(VEC_COND_EXPR still requires a comparison as first argument) but that 
shouldn't take too long to fix and it documents the intent.


2012-10-11  Marc Glisse  

* doc/extend.texi (Vector Extensions): C++ improvements.
* doc/generic.texi (LSHIFT_EXPR, RSHIFT_EXPR): Mixed vector-scalar.
(LT_EXPR, LE_EXPR, GT_EXPR, GE_EXPR, EQ_EXPR, NE_EXPR): Specify
the vector case.
(VEC_COND_EXPR): Document it.

--
Marc GlisseIndex: doc/generic.texi
===
--- doc/generic.texi(revision 192348)
+++ doc/generic.texi(working copy)
@@ -1381,21 +1381,22 @@ a fixed-point value to a floating-point
 
 @item LSHIFT_EXPR
 @itemx RSHIFT_EXPR
 These nodes represent left and right shifts, respectively.  The first
 operand is the value to shift; it will always be of integral type.  The
 second operand is an expression for the number of bits by which to
 shift.  Right shift should be treated as arithmetic, i.e., the
 high-order bits should be zero-filled when the expression has unsigned
 type and filled with the sign bit when the expression has signed type.
 Note that the result is undefined if the second operand is larger
-than or equal to the first operand's type size.
+than or equal to the first operand's type size. Unlike most nodes, these
+can have a vector as first operand and a scalar as second operand.
 
 
 @item BIT_IOR_EXPR
 @itemx BIT_XOR_EXPR
 @itemx BIT_AND_EXPR
 These nodes represent bitwise inclusive or, bitwise exclusive or, and
 bitwise and, respectively.  Both operands will always have integral
 type.
 
 @item TRUTH_ANDIF_EXPR
@@ -1475,25 +1476,26 @@ allows the backend to choose between the
 @code{CEIL_DIV_EXPR} and @code{FLOOR_DIV_EXPR} for the current target.
 
 @item LT_EXPR
 @itemx LE_EXPR
 @itemx GT_EXPR
 @itemx GE_EXPR
 @itemx EQ_EXPR
 @itemx NE_EXPR
 These nodes represent the less than, less than or equal to, greater
 than, greater than or equal to, equal, and not equal comparison
-operators.  The first and second operand with either be both of integral
-type or both of floating type.  The result type of these expressions
-will always be of integral or boolean type.  These operations return
-the result type's zero value for false, and the result type's one value
-for true.
+operators.  The first and second operands will either be both of integral
+type, both of floating type or both of vector type.  The result type of
+these expressions will always be of integral, boolean or signed integral
+vector type.  These operations return the result type's zero value for
+false, the result type's one value for true, and a vector whose elements
+are zero (false) or minus one (true) for vectors.
 
 For floating point comparisons, if we honor IEEE NaNs and either operand
 is NaN, then @code{NE_EXPR} always returns true and the remaining operators
 always return false.  On some targets, comparisons against an IEEE NaN,
 other than equality and inequality, may generate a floating point exception.
 
 @item ORDERED_EXPR
 @itemx UNORDERED_EXPR
 These nodes represent non-trapping ordered and unordered comparison
 operators.  These operations take two floating point operands and
@@ -1762,20 +1764,31 @@ is half as wide.  The elements of the tw
 (concatenated) to form the output vector.
 
 @item VEC_PACK_FIX_TRUNC_EXPR
 This node represents packing of elements of the two input vectors into the
 output vector, where the values are converted from floating point
 to fixed point.  Input operands are vectors that contain the same number
 of elements of a floating point type.  The result is a vector that contains
 twice as many elements of an integral type whose size is half as wide.  The
 elements of the two vectors are merged (concatenated) to form the output
 vector.
+
+@item VEC_COND_EXPR
+These nodes represent @code{?:} expressions.  The three operands must be
+vectors of the same size and number of elements.  The second and third
+operands must have the same type as the entire expression.  The first
+operand is of signed integral vector type.  If an element of the first
+operand evaluates to a zero value, the corresponding element of the
+result is taken from the third operand. If it evaluates to a minus one
+value, it is taken from the second operand. It should never evaluate to
+any other value. In contrast with a @code{COND_EXPR}, all operands are
+always evaluated.
 @end table
 
 
 @c -
 @c Statements
 @c -
 
 @node Statements
 @section Statements
 @cindex Statements
Index: doc/extend.texi
==

Fix PR testsuite/54867

[Eric Botcazou]

The new scan-rtl-dump-not I recently added needs to be tweaked so as to cater 
to x86-64 platforms like Solaris where the prologue isn't elided.

Tested on x86_64-suse-linux, applied on the mainline as obvious.


2012-10-11  Eric Botcazou  

PR testsuite/54867
* gcc.dg/pr44194-1.c: Tweak regexp to exclude prologue insns.


-- 
Eric BotcazouIndex: gcc.dg/pr44194-1.c
===
--- gcc.dg/pr44194-1.c	(revision 192137)
+++ gcc.dg/pr44194-1.c	(working copy)
@@ -15,5 +15,5 @@ void func() {
 /* { dg-final { scan-rtl-dump "global deletions = (2|3)" "dse1" } } */
 /* { dg-final { cleanup-rtl-dump "dse1" } } */
 
-/* { dg-final { scan-rtl-dump-not "set \\(mem" "final" } } */
+/* { dg-final { scan-rtl-dump-not "insn \[^\n\]*set \\(mem" "final" } } */
 /* { dg-final { cleanup-rtl-dump "final" } } */

[C++ testcase] PR 43765

[Paolo Carlini]

Hi,

I'm committing the testcase and closing the PR as fixed in mainline.

Thanks,
Paolo.

///
2012-10-11  Paolo Carlini  

PR c++/43765
* g++.dg/parse/pr43765.C: New.
Index: g++.dg/parse/pr43765.C
===
--- g++.dg/parse/pr43765.C  (revision 0)
+++ g++.dg/parse/pr43765.C  (working copy)
@@ -0,0 +1,14 @@
+// PR c++/43765
+// { dg-options "" }
+
+struct SomeType
+{
+const char *values[];
+};
+const char *temp[] = {"607", "612", 0};
+
+SomeType vals[] =
+{
+{ values : temp, },
+0
+};  // { dg-error "invalid" }

Re: [c-family] Small tweak to -fdump-ada-spec

[Eric Botcazou]

> 2012-10-09  Eric Botcazou  
> 
>   * c-ada-spec.c (dump_ada_template): Bail out for template declarations
>   declaring something coming from another file.

That's a small patch affecting only -fdump-ada-spec so I went ahead and 
installed it on the mainline.

-- 
Eric Botcazou

Committed, PR54897 (was: [C++ PATCH] -Wsizeof-pointer-memaccess warning (take 2))

[Hans-Peter Nilsson]

> From: Hans-Peter Nilsson 
> Date: Thu, 11 Oct 2012 02:13:32 +0200

> There's now an "excess error":
> 
> x/libstdc++-v3/testsuite/23_containers/bitset/45713.cc:24:55:
> error: size of array 'test' is not an integral constant-expression
>  int test[sizeof(std::bitset<0x>) != 1 ? 1 : -1];
> 
> Or is the error message in error and just "missing" before?
> Please have a look.

As per discussion in PR54897, I committed the following, after
correcting the target syntax in the cutnpasted patch there.
(The target parser is picky about matching *-*-*, which I guess is
appropriate since it has to handle effective-targets as well.)

PR testsuite/54897
* testsuite/23_containers/bitset/45713.cc: Skip for avr*-*-*
cris*-*-* h8300*-*-* mcore*-*-* moxie*-*-*.


Index: libstdc++-v3/testsuite/23_containers/bitset/45713.cc
===
--- libstdc++-v3/testsuite/23_containers/bitset/45713.cc(revision 
192353)
+++ libstdc++-v3/testsuite/23_containers/bitset/45713.cc(working copy)
@@ -1,4 +1,4 @@
-// Copyright (C) 2010 Free Software Foundation, Inc.
+// Copyright (C) 2010, 2012 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
@@ -15,7 +15,10 @@
 // with this library; see the file COPYING3.  If not see
 // .
 
-// { dg-do compile }
+// The testcase requires bitsizetype to be wider than sizetype,
+// otherwise types/vars with 0x2000 bytes or larger can't be used.
+// See http://gcc.gnu.org/PR54897
+// { dg-do compile { target { ! { avr*-*-* cris*-*-* h8300*-*-* mcore*-*-* 
moxie*-*-* } } } }
 
 #include 
 
brgds, H-P

Re: [libbacktrace] Use getexecname() on Solaris

[Rainer Orth]

Ian Lance Taylor  writes:

> On Fri, Oct 5, 2012 at 4:21 AM, Rainer Orth  
> wrote:
>>
>> I think this should work.  The only complication might be that users of
>> DEFAULT_PROCESS_FILENAME need to include  on Solaris to get
>> the declaration of getexecname().  Given that this header is already
>> used unconditionally, its inclusion should probably be moved to either
>> internal.h (which doesn't yet include anything) or backtrace.h.  Ian,
>> what do you prefer here?
>
> Definitely not backtrace.h.  I think I would prefer that print.c
> simply #include  directly.

Ok, here's the merged patch, tested on i386-pc-solaris2.10.  Ok for
mainline?

Rainer


2012-10-05  Rainer Orth  
Gerald Pfeifer  

libbacktrace:
* configure.ac: Check for getexecname.
* configure: Regenerate.
* config.h.in: Regenerate.
* internal.h (DEFAULT_PROCESS_FILENAME): Define.
* fileline.c (fileline_initialize): Use it.
* print.c (error_callback): Likewise.
Include .

# HG changeset patch
# Parent e43e8e91417064d0dcfb3b9ec0c2833d7ce00792
Use getexecname() on Solaris

diff --git a/libbacktrace/configure.ac b/libbacktrace/configure.ac
--- a/libbacktrace/configure.ac
+++ b/libbacktrace/configure.ac
@@ -260,6 +260,19 @@ fi
 
 AC_CHECK_DECLS(strnlen)
 
+# Check for getexecname function.
+if test -n "${with_target_subdir}"; then
+   case "${host}" in
+   *-*-solaris2*) have_getexecname=yes ;;
+   *) have_getexecname=no ;;
+   esac
+else
+  AC_CHECK_FUNC(getexecname, [have_getexecname=yes], [have_getexecname=no])
+fi
+if test "$have_getexecname" = "yes"; then
+  AC_DEFINE(HAVE_GETEXECNAME, 1, [Define if getexecname is available.])
+fi
+
 AC_CACHE_CHECK([whether tests can run],
   [libbacktrace_cv_sys_native],
   [AC_RUN_IFELSE([AC_LANG_PROGRAM([], [return 0;])],
diff --git a/libbacktrace/fileline.c b/libbacktrace/fileline.c
--- a/libbacktrace/fileline.c
+++ b/libbacktrace/fileline.c
@@ -82,7 +82,8 @@ fileline_initialize (struct backtrace_st
   if (state->filename != NULL)
 descriptor = backtrace_open (state->filename, error_callback, data);
   else
-descriptor = backtrace_open ("/proc/self/exe", error_callback, data);
+descriptor = backtrace_open (DEFAULT_PROCESS_FILENAME, error_callback,
+ data);
   if (descriptor < 0)
 failed = 1;
 
diff --git a/libbacktrace/internal.h b/libbacktrace/internal.h
--- a/libbacktrace/internal.h
+++ b/libbacktrace/internal.h
@@ -56,6 +56,14 @@ POSSIBILITY OF SUCH DAMAGE.  */
 # endif
 #endif
 
+#ifdef __FreeBSD__
+# define DEFAULT_PROCESS_FILENAME "/proc/curproc/file"
+#elif defined(HAVE_GETEXECNAME)
+# define DEFAULT_PROCESS_FILENAME getexecname ()
+#else
+# define DEFAULT_PROCESS_FILENAME "/proc/self/exe"
+#endif
+
 #ifndef HAVE_SYNC_FUNCTIONS
 
 /* Define out the sync functions.  These should never be called if
diff --git a/libbacktrace/print.c b/libbacktrace/print.c
--- a/libbacktrace/print.c
+++ b/libbacktrace/print.c
@@ -35,6 +35,7 @@ POSSIBILITY OF SUCH DAMAGE.  */
 #include 
 #include 
 #include 
+#include 
 
 #include "backtrace.h"
 #include "internal.h"
@@ -73,7 +74,7 @@ error_callback (void *data, const char *
 
   name = pdata->state->filename;
   if (name == NULL)
-name = "/proc/self/exe";
+name = DEFAULT_PROCESS_FILENAME;
   fprintf (stderr, "%s: libbacktrace: %s", name, msg);
   if (errnum > 0)
 fprintf (stderr, ": %s", strerror (errnum));


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

[PATCH, i386]: Use SSE insns to generate soft-fp exceptions for 64bit targets only

[Uros Bizjak]

Hello!

For 32bit targets, there is no guarantee that mxcsr register will be
set up correctly w.r.t. unmasked FP exceptions, so don't use SSE
instructions to generate INVALID and DIVZERO FP exceptions.

2012-10-10  Uros Bizjak  

* config/i386/sfp-exceptions.c (__sfp_handle_exceptions): Emit SSE
instructions for 64bit targets only.

Patch was bootstrapped and regtested on x86_64-pc-linux-gnu {,-m32},
committed to mainline SVN.

Uros.
Index: config/i386/sfp-exceptions.c
===
--- config/i386/sfp-exceptions.c(revision 192347)
+++ config/i386/sfp-exceptions.c(working copy)
@@ -46,7 +46,7 @@ __sfp_handle_exceptions (int _fex)
   if (_fex & FP_EX_INVALID)
 {
   float f = 0.0f;
-#ifdef __SSE__
+#ifdef __x86_64__
   asm volatile ("%vdivss\t{%0, %d0|%d0, %0}" : "+x" (f));
 #else
   asm volatile ("fdiv\t{%y0, %0|%0, %y0}" : "+t" (f));
@@ -56,7 +56,7 @@ __sfp_handle_exceptions (int _fex)
   if (_fex & FP_EX_DIVZERO)
 {
   float f = 1.0f, g = 0.0f;
-#ifdef __SSE__
+#ifdef __x86_64__
   asm volatile ("%vdivss\t{%1, %d0|%d0, %1}" : "+x" (f) : "xm" (g));
 #else
   asm volatile ("fdivs\t%1" : "+t" (f) : "m" (g));

Re: [libbacktrace] Use getexecname() on Solaris

[Gerald Pfeifer]

On Thu, 11 Oct 2012, Rainer Orth wrote:
> Ok, here's the merged patch, tested on i386-pc-solaris2.10.  Ok for
> mainline?

Cool, thank you!


Just a small note, in the following

  +#ifdef __FreeBSD__
  +# define DEFAULT_PROCESS_FILENAME "/proc/curproc/file"
  +#elif defined(HAVE_GETEXECNAME)
  +# define DEFAULT_PROCESS_FILENAME getexecname ()
  +#else
  +# define DEFAULT_PROCESS_FILENAME "/proc/self/exe"
  +#endif

would it make sense to have the feature test (HAVE_GETEXECNAME) before
the OS test (__FreeBSD__), so that when/if the OS implements the feature
in newer versions that takes precedence?

Gerald

[testsuite] PR 54868

[Marc Glisse]

Hello,

understanding the testsuite is hard, but this patch seems to work. The 
idea is that vect_double and others don't tell that vectors are supported 
with these options, just that there exist options that enable vectors. 
They are thus useless outside of a directory like vect/ that adds those 
flags.


2012-10-11  Marc Glisse  

PR testsuite/54868
* gcc.dg/tree-ssa/forwprop-22.c: Move ...
* gcc.dg/vect/nodump-forwprop-22.c: ... here. Adapt options.

--
Marc GlisseIndex: gcc.dg/vect/nodump-forwprop-22.c
===
--- gcc.dg/vect/nodump-forwprop-22.c(revision 192348)
+++ gcc.dg/vect/nodump-forwprop-22.c(working copy)
@@ -1,14 +1,14 @@
 /* { dg-do compile } */
 /* { dg-require-effective-target vect_double } */
 /* { dg-require-effective-target vect_perm } */
-/* { dg-options "-O -fdump-tree-copyprop1" } */
+/* { dg-additional-options "-fdump-tree-copyprop1" } */
 
 typedef double vec __attribute__((vector_size (2 * sizeof (double;
 void f (vec *px, vec *y, vec *z)
 {
   vec x = *px;
   vec t1 = { x[1], x[0] };
   vec t2 = { x[0], x[1] };
   *y = t1;
   *z = t2;
 }

[v3] std::common_type testsuite tweaks

[Paolo Carlini]

Hi

contributed by Daniel. Tested again and committed.

Paolo.

///
2012-10-11  Daniel Krugler  

* testsuite/20_util/common_type/requirements/sfinae_friendly_1.cc:
Update / extend.
* testsuite/20_util/common_type/requirements/sfinae_friendly_2.cc:
Likewise.
* testsuite/20_util/duration/requirements/sfinae_friendly_1.cc:
Likewise.
 .../common_type/requirements/sfinae_friendly_1.cc  |   62 
 .../common_type/requirements/sfinae_friendly_2.cc  |6 +-
 .../duration/requirements/sfinae_friendly_1.cc |9 ++-
 3 files changed, 50 insertions(+), 27 deletions(-)

diff --git a/libstdc++-v3/testsuite/20_util/common_type/requirements/sfinae_friendly_1.cc b/libstdc++-v3/testsuite/20_util/common_type/requirements/sfinae_friendly_1.cc
index c23521f..f73c6cc 100644
--- a/libstdc++-v3/testsuite/20_util/common_type/requirements/sfinae_friendly_1.cc
+++ b/libstdc++-v3/testsuite/20_util/common_type/requirements/sfinae_friendly_1.cc
@@ -163,20 +163,23 @@ namespace std {
   };
 }
 
-static_assert(is_type, int>(), "");
-static_assert(is_type, ScEn>(), "");
-static_assert(is_type, UnscEn>(), "");
-static_assert(is_type, int>(), "");
+#ifdef HAS_53000_FIXED
+static_assert(is_type, int&&>(), "");
+static_assert(is_type, ScEn&&>(), "");
+static_assert(is_type, UnscEn&&>(), "");
+#endif
 static_assert(is_type, int>(), "");
-static_assert(is_type, int>(), "");
-static_assert(is_type, int>(), "");
-static_assert(is_type, int>(), "");
-static_assert(is_type, S>(), "");
-static_assert(is_type, const S>(), "");
+#ifdef HAS_53000_FIXED
+static_assert(is_type, int&&>(), "");
+static_assert(is_type, int&&>(), "");
+static_assert(is_type, int&&>(), "");
+static_assert(is_type, S&&>(), "");
+static_assert(is_type, const S&&>(), "");
 static_assert(is_type,
-	  std::initializer_list>, std::initializer_list>(), "");
-static_assert(is_type, B>(), "");
-static_assert(is_type, B>(), "");
+	  std::initializer_list>, std::initializer_list&&>(), "");
+static_assert(is_type, B&&>(), "");
+static_assert(is_type, B&&>(), "");
+#endif
 static_assert(is_type, void*>(), "");
 static_assert(is_type, void*>(), "");
 static_assert(is_type, const volatile void*>(), "");
@@ -189,10 +192,15 @@ static_assert(is_type, void>(), "");
 static_assert(is_type, void>(), "");
 static_assert(is_type, int>(), "");
 static_assert(is_type, int&>(), "");
-static_assert(is_type, int>(), "");
+#ifdef HAS_53000_FIXED
+static_assert(is_type, int&&>(), "");
+static_assert(is_type, const int&&>(), "");
+#endif
 static_assert(is_type, const U>(), "");
 static_assert(is_type, U&>(), "");
-static_assert(is_type, U>(), "");
+#ifdef HAS_53000_FIXED
+static_assert(is_type, U&&>(), "");
+#endif
 static_assert(is_type, int D::*>(), "");
 static_assert(is_type, int D::*>(), "");
 static_assert(is_type,
@@ -201,7 +209,9 @@ static_assert(is_type,
 	  int (D::*)()>(), "");
 static_assert(is_type,
 	  int (D::*)() const>(), "");
-static_assert(is_type, int*>(), "");
+#ifdef HAS_53000_FIXED
+static_assert(is_type, int(&&)[3]>(), "");
+#endif
 static_assert(is_type,
 	  const int*>(), "");
 static_assert(is_type, void(&)()>(), "");
@@ -213,14 +223,18 @@ static_assert(is_type,
 static_assert(is_type,
 	  void(&)()>(), "");
 static_assert(is_type, int>, int>(), "");
+#ifdef HAS_53000_FIXED
 static_assert(is_type, ImplicitTo>,
-	  ImplicitTo>(), "");
+	  ImplicitTo&&>(), "");
+#endif
 static_assert(is_type, int,
 	  ImplicitTo>, int>(), "");
+#ifdef HAS_53000_FIXED
 static_assert(is_type, ExplicitTo>,
-	  ExplicitTo>(), "");
+	  ExplicitTo&&>(), "");
 static_assert(is_type,
-	  decltype(lmd1)>(), "");
+	  decltype(lmd1)&&>(), "");
+#endif
 static_assert(is_type,
 	  decltype(lmd1)&>(), "");
 static_assert(is_type,
@@ -248,12 +262,12 @@ static_assert(is_type, Abstract*>(), "");
 
 #ifdef HAS_53000_FIXED
 static_assert(is_type,
-	  Abstract>(), "");
+	  Abstract&&>(), "");
 static_assert(is_type, Abstract>(), "");
-static_assert(is_type, Ukn>(), "");
+   volatile Abstract&&>, const volatile Abstract&&>(), "");
+static_assert(is_type, Ukn&&>(), "");
 static_assert(is_type,
-	  Ukn>(), "");
+	  const volatile Ukn&&>(), "");
 #endif
 
 static_assert(is_type, RX12>(), "");
@@ -323,8 +337,10 @@ void test(int i)
   auto local_lmd1 = [=](int, double) { return i + i; };
   auto local_lmd2 = [=](int, double) { return i - i; };
 
+#ifdef HAS_53000_FIXED
   static_assert(is_type, decltype(local_lmd1)>(), "");
+		decltype(local_lmd1)>, decltype(local_lmd1)&&>(), "");
+#endif
   static_assert(is_type, decltype(local_lmd1)>(), "");
   static_assert(is_type
 constexpr
-std::array::type, sizeof...(Args)>
+std::array::type>::type, 
+  sizeof...(Args)>
 make_array(Args&&... args)  // { dg-error "invalid use" }
 {
-  typedef typename std::common_type::type CT;
+  typedef typename std::decay::type>::type 
+CT;
   return std::array{sta

Re: vec_cond_expr adjustments

[Richard Biener]

On Thu, Oct 11, 2012 at 1:20 AM, Marc Glisse  wrote:
> On Mon, 8 Oct 2012, Richard Guenther wrote:
>
>> On Mon, Oct 8, 2012 at 11:34 AM, Marc Glisse  wrote:
>>>
>>> On Mon, 8 Oct 2012, Richard Guenther wrote:
>>>
> VEC_COND_EXPR is more complicated. We could for instance require that
> it
> takes as first argument a vector of -1 and 0 (thus <0, !=0 and the neon
> thing are equivalent). Which would leave to decide what the expansion
> of
> vec_cond_expr passes to the targets when the first argument is not a
> comparison, between !=0, <0, ==-1 or others (I vote for <0 because of
> opencl). One issue is that targets wouldn't know if it was a dummy
> comparison that can safely be ignored because the other part is the
> result
> of logical operations on comparisons (thus composed of -1 and 0) or a
> genuine comparison with an arbitrary vector, so a new optimization
> would
> be
> needed (in the back-end I guess or we would need an alternate
> instruction
> to
> vcond) to detect if a vector is a "signed boolean" vector.
> We could instead say that vec_cond_expr really follows OpenCL's
> semantics
> and looks at the MSB of each element. I am not sure that would change
> much,
> it would mostly delay the apparition of <0 to RTL expansion time (and
> thus
> make gimple slightly lighter).



 I think we should delay the decision on how to optimize this.  It's
 indeed
 not trivial and the GIMPLE middle-end aggressively forwards feeding
 comparisons into the VEC_COND_EXPR expressions already (somewhat
 defeating any CSE that might be possible here) in forwprop.
>>>
>>>
>>>
>>> Thanks for going through the long email :-)
>>>
>>> What does that imply for the first argument of VEC_COND_EXPR? Currently,
>>> the
>>> expander asserts that it is a comparison, but that is not reflected in
>>> the
>>> gimple checkers.
>>
>>
>> And I don't think we should reflect that in the gimple checkers rather
>> fixup the
>> expander (transparently use p != 0 or p < 0).
>
>
> I guess I'll pick p < 0 then (just because I am more interested in x86 and
> it makes the optimization easier on x86). Having another expander than vcond
> (one that takes the mask directly instead of a comparison, and for which we
> promise that the argument will be a vector of -1/0) would be convenient...
>
>
>>> So is the best choice to document that VEC_COND_EXPR takes as
>>> first argument a comparison and make gimple checking reflect that? (seems
>>> sad, but at least that would tell me what I can/can't do)
>>
>>
>> No, that would just mean that in GIMPLE you'd add this p != 0 or p < 0.
>> And at some point in the future I really really want to push this embedded
>> expression to a separate statement so I have a SSA definition for it.
>
>
> Once the expander is ready to accept it, ok. It seems to me that the scalar
> COND_EXPR may also have an embedded expression, so I assume COND_EXPR and
> VEC_COND_EXPR are meant to diverge (or maybe you also want to do the same
> for COND_EXPR?).

Yes, I want the same for COND_EXPR and even GIMPLE_COND.  I had
patches to do this about two years ago but was too lazy to fixup all the
fallout.  My plan was to eventually return to this and first tackle COND_EXPR
and VEC_COND_EXRP only, leaving GIMPLE_COND in place.

>>> By the way, since we are documenting comparisons as returning 0 and -1,
>>> does
>>> that bring back the integer_truep predicate?
>>
>>
>> Not sure, true would still be != 0 or all_onesp (all bits of the
>> precision are 1), no?
>
>
> I was going to make truep equivalent to onep for scalars and all_onesp for
> vectors (since -1 will be the only value documented as "true" for vectors).
> I guess it can wait, I can manually inline it for now.

Yes please.

> Since we are documenting that comparisons of vectors return -1 and 0 in the
> middle-end, I was wondering whether the comparison expanders would need
> updating so they forward to vcond(...,-1,0), at least on platforms that
> don't define VECTOR_STORE_FLAG_VALUE to constm1_rtx for this mode. But a
> simple test on sparc shows it is already fine :-)

Heh, good.

Richard.

> --
> Marc Glisse

Re: [patch] Fix PR bootstrap/54820

[Eric Botcazou]

> 2012-10-09  Eric Botcazou   
>   PR bootstrap/54820
>   * Makefile.tpl (STAGE1_FLAGS_TO_PASS): New variable.
>   (host_modules): Add STAGE1_FLAGS_TO_PASS to args.
>   * Makefile.in: Regenerate.
>   * configure.ac (have_static_libs): New variable and associated check.
>   (stage1-ldflags): Move to after stage1_libs and set to -static-libstdc++
>   -static-libgcc if stage1_libs is empty and have_static_libs is yes.
>   * configure: Regenerate.
> gcc/ada
>   * gcc-interface/Make-lang.in (GCC_LINK): Remove -static-libstdc++
>   -static-libgcc.

The Makefile.tpl change was a bit rough...  Here is a better patch, where a 
new variable stage1_args is defined for the host modules.

Tested on x86_64-suse-linux, OK for the mainline?


2012-10-11  Eric Botcazou  

PR bootstrap/54820
* Makefile.tpl (STAGE1_FLAGS_TO_PASS): New variable.
(all-[+prefix+][+module+]): Pass stage1_args to sub-makes.
(all-stage[+id+]-[+prefix+][+module+]): Likewise, if prev is false.
(clean-stage[+id+]-[+prefix+][+module+]): Likewise, if prev is false.
(host_modules): Set stage1_args to STAGE1_FLAGS_TO_PASS.
* Makefile.in: Regenerate.
* configure.ac (have_static_libs): New variable and associated check.
(stage1-ldflags): Move to after stage1_libs and set to -static-libstdc++
-static-libgcc if stage1_libs is empty and have_static_libs is yes.
* configure: Regenerate.
gcc/ada
* gcc-interface/Make-lang.in (GCC_LINK): Remove hardcoded options.


-- 
Eric BotcazouIndex: Makefile.tpl
===
--- Makefile.tpl	(revision 192353)
+++ Makefile.tpl	(working copy)
@@ -615,6 +615,12 @@ EXTRA_HOST_FLAGS = \
 
 FLAGS_TO_PASS = $(BASE_FLAGS_TO_PASS) $(EXTRA_HOST_FLAGS)
 
+# Flags to pass to stage1 or when not bootstrapping.
+
+STAGE1_FLAGS_TO_PASS = \
+	LDFLAGS="$${LDFLAGS}" \
+	HOST_LIBS="$${HOST_LIBS}"
+
 # Flags to pass to stage2 and later makes.
 
 POSTSTAGE1_FLAGS_TO_PASS = \
@@ -1076,7 +1082,7 @@ all-[+prefix+][+module+]: configure-[+pr
 	s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
 	[+exports+] [+extra_exports+] \
 	(cd [+subdir+]/[+module+] && \
-	  $(MAKE) $(BASE_FLAGS_TO_PASS) [+args+] [+extra_make_flags+] \
+	  $(MAKE) $(BASE_FLAGS_TO_PASS) [+args+] [+stage1_args+] [+extra_make_flags+] \
 		$(TARGET-[+prefix+][+module+]))
 @endif [+prefix+][+module+]
 
@@ -1109,9 +1115,8 @@ all-stage[+id+]-[+prefix+][+module+]: co
 		CFLAGS_FOR_TARGET="$(CFLAGS_FOR_TARGET)" \
 		CXXFLAGS_FOR_TARGET="$(CXXFLAGS_FOR_TARGET)" \
 		LIBCFLAGS_FOR_TARGET="$(LIBCFLAGS_FOR_TARGET)" \
-		[+args+] [+
-		IF prev +][+poststage1_args+][+ ENDIF prev
-		+] [+extra_make_flags+] \
+		[+args+] [+IF prev +][+poststage1_args+][+ ELSE prev +] \
+		[+stage1_args+][+ ENDIF prev +] [+extra_make_flags+] \
 		TFLAGS="$(STAGE[+id+]_TFLAGS)" \
 		$(TARGET-stage[+id+]-[+prefix+][+module+])
 
@@ -1125,9 +1130,8 @@ clean-stage[+id+]-[+prefix+][+module+]:
 	  $(MAKE) stage[+id+]-start; \
 	fi; \
 	cd [+subdir+]/[+module+] && \
-	$(MAKE) [+args+] [+ IF prev +] \
-		[+poststage1_args+] [+ ENDIF prev +] \
-		[+extra_make_flags+] clean
+	$(MAKE) [+args+] [+ IF prev +][+poststage1_args+][+ ELSE prev +] \
+	[+stage1_args+][+ ENDIF prev +] [+extra_make_flags+] clean
 @endif [+prefix+][+module+]-bootstrap
 
 [+ ENDFOR bootstrap_stage +]
@@ -1162,6 +1166,7 @@ clean-stage[+id+]-[+prefix+][+module+]:
exports="$(HOST_EXPORTS)"
poststage1_exports="$(POSTSTAGE1_HOST_EXPORTS)"
args="$(EXTRA_HOST_FLAGS)"
+   stage1_args="$(STAGE1_FLAGS_TO_PASS)"
poststage1_args="$(POSTSTAGE1_FLAGS_TO_PASS)" +]
 
 .PHONY: check-[+module+] maybe-check-[+module+]
Index: configure.ac
===
--- configure.ac	(revision 192353)
+++ configure.ac	(working copy)
@@ -1182,6 +1182,22 @@ if test -z "$LD"; then
   fi
 fi
 
+# Check whether -static-libstdc++ -static-libgcc is supported
+have_static_libs=no
+if test "$GCC" = yes; then
+  saved_LDFLAGS="$LDFLAGS"
+
+  LDFLAGS="$LDFLAGS -static-libstdc++ -static-libgcc"
+  AC_MSG_CHECKING([whether g++ accepts -static-libstdc++ -static-libgcc])
+  AC_LANG_PUSH(C++)
+  AC_LINK_IFELSE([int main() {}],
+[AC_MSG_RESULT([yes]); have_static_libs=yes],
+[AC_MSG_RESULT([no])])
+  AC_LANG_POP(C++)
+
+  LDFLAGS="$saved_LDFLAGS"
+fi
+
 ACX_PROG_GNAT
 ACX_PROG_CMP_IGNORE_INITIAL
 
@@ -1478,17 +1494,6 @@ case $with_host_libstdcxx in
 ;;
 esac
 
-# Linker flags to use for stage1 or when not boostrapping.
-AC_ARG_WITH(stage1-ldflags,
-[AS_HELP_STRING([--with-stage1-ldflags=FLAGS], [linker flags for stage1])],
-[if test "$withval" = "no" -o "$withval" = "yes"; then
-   stage1_ldflags=
- else
-   stage1_ldflags=$withval
- fi],
-[stage1_ldflags=])
-AC_SUBST(stage1_ldflags)
-
 # Libraries to use for stage1 or when not bootstrapping.
 AC_ARG_WITH(stage1-libs,
 [AS_HELP_STRING([--with-stage1-libs=LIBS], [librarie

Re: [Patch, ARM, testsuite]

[Christophe Lyon]

Hi Richard,

On 21 September 2012 10:49, Richard Earnshaw  wrote:
> On 21/09/12 09:47, Matthew Gretton-Dann wrote:
>> On 20 September 2012 23:06, Christophe Lyon  
>> wrote:
>>> Hi,
>>>
>>> GCC for ARM does not support compiling in Thumb1 mode  and
>>> float-abi=hard.  But  it does not fail unless the program being
>>> compiled actually contains a function with parameters and/or a return
>>> value.
>>>
>>> This is a (minor) problem in the testsuite in some configurations.
>>>
>>> For instance, if I run the testsuite forcing -mthumb (via site.exp)
>>> for a GCC configured for float-abi=hard, and a test uses
>>> /* { dg-require-effective-target arm_arch_v6_ok } */
>>> /* { dg-add-options arm_arch_v6 } */
>>>
>>> it won't be unresolved since effective-target arm_arch_v6_ok is successful.
>>>
>>> The attached patch adds a dummy function body in the test such that it 
>>> fails.
>>>
>>> Another way of achieving the same result is by making sure that the
>>> relevant tests use
>>> arm_arch_v6_multilib
>>> instead of
>>> arm_arch_v6_ok
>>>
>>> even if the test is not intended to be executed.
>>>
>>> OK?
>>
>> [I'm not a maintainer]
>>
>> You could argue that as the test is checking for just ARMv6, but then
>> uses ARMv6+VFPv2 features - and so it going wrong is to be expected
>> :-).
>>
>> So other approaches could be to see what adding
>>
>> /* { dg-require-effective-target arm_vfp_ok } */
>>
>> after dg-add-options achieves.
>
> That the test never runs on a Thumb1 processor.  Which slightly defeats
> the object of testing thumb1 code.
>

I still have a test with
/* { dg-require-effective-target arm_arch_v6_ok } */
/* { dg-add-options arm_arch_v6 } */
which fails when GCC is configured with --with-mode=thumb
--target=arm-none-linuxgnueabihf

Modifying check_effective_target_arm_arch_FUNC_ok as I suggested by
including an empty function definition (as in
check_effective_target_arm_arch_FUNC_multilib) suffices to turn the
test into UNSUPPORTED rather than FAIL.

What would you suggest instead?

Thanks,

Christophe.

Re: Use conditional casting with symtab_node

[Richard Biener]

On Thu, Oct 11, 2012 at 7:31 AM, Xinliang David Li  wrote:
> On Fri, Oct 5, 2012 at 1:49 AM, Richard Guenther
>  wrote:
>> On Thu, Oct 4, 2012 at 8:16 PM, Diego Novillo  wrote:
>>> On Thu, Oct 4, 2012 at 2:14 PM, Lawrence Crowl  wrote:
>>>
 So, Jan Hubicka requested and approved the current spelling.
 What now?
>>>
>>> I don't think we should hold this up.  The names Jan requested seem
>>> reasonable enough.  We seem to be running in circles here.
>>
>> I suppose I have your promise that we'll release with consistent names.
>> Please allocate some work hours on your side for the renaming of
>> cgraph_node and varpool_node for the case Honza doesn't get to it in time.
>>
>> I see all these patches with mixed feeling - it puts breaks on all developers
>> because they need to learn the new interface which does not bring any
>> immediate benefit.  So I think _your_ development time would be better
>> spent by fixing open bugs or by tackling some of the existing scalability
>> issues in GCC (rather than quoting funny '0.001% faster with 99% confidence'
>> stuff).
>>
>
> Interface cleanup will help GCC in the long run assuming it is done
> correctly. There will be short term churns for sure. However I think
> it is also important to get things right in as few steps as possible
> with a better/more carefully thought design.

I agree.

There is no reason to change things just to change them.

Richard.

> David
>
>> Thanks,
>> Richard.
>>
>>>
>>> Diego.

Re: [PATCH, libstdc++] Fix missing gthr-default.h issue on libstdc++ configure

[Olivier Hainque]

Hello,

The change apparently broke targets that have their gthr- header not
in libgcc/ directly, quite a few.

We are seeing failure on ppc-aix for example, which has 

  ./libgcc/config/rs6000/gthr-aix.h

We are also seeing failures while building a win32 canadian
from linux, where we have

  ./libgcc/config/i386/gthr-win32.h

This one is really problematic.

The failures we are seeing are all of the form:

<<
make[5]: Entering directory 
`/obj/powerpc-ibm-aix5.2.0.0/libstdc++-v3/include'
make[5]: *** No rule to make target 
`/src/libstdc++-v3/../libgcc/gthr-aix.h', needed by 
`powerpc-ibm-aix5.2.0.0/bits/gthr-default.h'.  Stop.
>>

This, in particular:

+  glibcxx_thread_h=gthr-$target_thread_file.h

-${host_builddir}/gthr-default.h: ${toplevel_builddir}/libgcc/gthr-default.h \
+${host_builddir}/gthr-default.h: ${toplevel_srcdir}/libgcc/${glibcxx_thread_h} 
\

looks very suspicious wrt gthr headers buried in libgcc
target subdirs.

Can you please have a look ?

Thanks in advance,

Olivier

Re: Move statements upwards after reassociation

[Richard Biener]

On Thu, Oct 11, 2012 at 3:52 AM, Easwaran Raman  wrote:
> Hi,
>  In the expression reassociation pass, statements might get moved
> downwards to ensure that dependences are not violated after
> reassociation. This can increase the live range and, in a tight loop,
> result in spills.  This patch simply does a code motion of those
> statements involved in reassociation and pushes them upwards in the BB
> as far as possible without violating dependences. Bootstraps and no
> tests regressions on a x86_64 machine running linux. Ok for trunk?

I don't think reassoc is the right place to do this.  There was the idea
of a tree-level "scheduling" pass, some of which (and I suppose some
of your changes) TER later happily will un-do.

Few comments:

>
> - Easwaran
>
> ---
> 2012-10-10  Easwaran Raman  
>
>* tree-ssa-reassoc.c (move_stmt_upwards): New function.
>  (rewrite_expr_tree): Record statements to be moved.
>  (reassociate_bb): Move statements affected by reassociation
>  as early as possible.
>
> Index: gcc/tree-ssa-reassoc.c
> ===
> --- gcc/tree-ssa-reassoc.c (revision 191879)
> +++ gcc/tree-ssa-reassoc.c (working copy)
> @@ -2250,13 +2250,51 @@ swap_ops_for_binary_stmt (VEC(operand_entry_t, hea
>  }
>  }
>
> +/* Move STMT up within its BB until it can not be moved any further.  */
> +
> +static void move_stmt_upwards (gimple stmt)
> +{
> +  gimple_stmt_iterator gsi, gsistmt;
> +  tree rhs1, rhs2;
> +  gimple rhs1def = NULL, rhs2def = NULL;
> +  rhs1 = gimple_assign_rhs1 (stmt);
> +  rhs2 = gimple_assign_rhs2 (stmt);
> +  gcc_assert (rhs1);

Please no such senseless asserts.  The following line will segfault anyway
if rhs1 is NULL and with a debugger an assert doesn't add any useful
information.

> +  if (TREE_CODE (rhs1) == SSA_NAME)
> +rhs1def = SSA_NAME_DEF_STMT (rhs1);
> +  else if (TREE_CODE (rhs1) != REAL_CST
> +   && TREE_CODE (rhs1) != INTEGER_CST)
> +return;
> +  if (rhs2)

You may not access gimple_assign_rhs2 if it is not there.  So you have
to check whether you have an unary, binary or ternary (yes) operation.

> +{
> +  if (TREE_CODE (rhs2) == SSA_NAME)
> +rhs2def = SSA_NAME_DEF_STMT (rhs2);
> +  else if (TREE_CODE (rhs1) != REAL_CST
> +   && TREE_CODE (rhs1) != INTEGER_CST)
> +return;
> +}
> +  gsi = gsi_for_stmt (stmt);
> +  gsistmt = gsi;
> +  gsi_prev (&gsi);
> +  for (; !gsi_end_p (gsi); gsi_prev (&gsi))



This doesn't make much sense.  You can move a stmt to the nearest
common post-dominator.  Assuming you only want to handle placing
it after rhs1def or after rhs2def(?) you don't need any loop, just
two dominator queries and an insertion after one of the definition
stmts.

But this code should consider BBs.  And I don't see why more optimal
placement cannot be done during rewrite_expr_tree itself.

NB, the whole reassoc code needs a re-write to avoid the excessive
stmt modifications when it does nothing.  So I'd very much rather avoid
adding anything to reassoc until that rewrite happened.

Richard.

> +{
> +  gimple curr_stmt = gsi_stmt (gsi);
> +  if (curr_stmt == rhs1def || curr_stmt == rhs2def) {
> +gsi_move_after (&gsistmt, &gsi);
> +return;
> +  }
> +}
> +
> +}
> +
>  /* Recursively rewrite our linearized statements so that the operators
> match those in OPS[OPINDEX], putting the computation in rank
> order.  */
>
>  static void
>  rewrite_expr_tree (gimple stmt, unsigned int opindex,
> -   VEC(operand_entry_t, heap) * ops, bool moved)
> +   VEC(operand_entry_t, heap) * ops, bool moved,
> +   VEC(gimple, heap) **stmts_to_move)
>  {
>tree rhs1 = gimple_assign_rhs1 (stmt);
>tree rhs2 = gimple_assign_rhs2 (stmt);
> @@ -2299,6 +2337,7 @@ rewrite_expr_tree (gimple stmt, unsigned int opind
>print_gimple_stmt (dump_file, stmt, 0, 0);
>  }
>   }
> +  VEC_safe_push (gimple, heap, *stmts_to_move, stmt);
>return;
>  }
>
> @@ -2346,7 +2385,9 @@ rewrite_expr_tree (gimple stmt, unsigned int opind
>  }
>/* Recurse on the LHS of the binary operator, which is guaranteed to
>   be the non-leaf side.  */
> -  rewrite_expr_tree (SSA_NAME_DEF_STMT (rhs1), opindex + 1, ops, moved);
> +  rewrite_expr_tree (SSA_NAME_DEF_STMT (rhs1), opindex + 1, ops, moved,
> + stmts_to_move);
> +  VEC_safe_push (gimple, heap, *stmts_to_move, stmt);
>  }
>
>  /* Find out how many cycles we need to compute statements chain.
> @@ -3427,6 +3468,9 @@ reassociate_bb (basic_block bb)
>  {
>gimple_stmt_iterator gsi;
>basic_block son;
> +  VEC(gimple, heap) *stmts_to_move = NULL;
> +  gimple stmt;
> +  int i;
>
>for (gsi = gsi_last_bb (bb); !gsi_end_p (gsi); gsi_prev (&gsi))
>  {
> @@ -3542,7 +3586,7 @@ reassociate_bb (basic_block bb)
>&& VEC_length (operand_entry_t, ops) > 3)
>   

Re: [testsuite] PR 54868

[Richard Biener]

On Thu, Oct 11, 2012 at 2:19 PM, Marc Glisse  wrote:
> Hello,
>
> understanding the testsuite is hard, but this patch seems to work. The idea
> is that vect_double and others don't tell that vectors are supported with
> these options, just that there exist options that enable vectors. They are
> thus useless outside of a directory like vect/ that adds those flags.

Ok.  But you need to cleanup vect dumps as those are enabled by default
in vect.exp I think.  Just check for remaining files in gcc/testsuite/gcc
when running testing with RUNTESTFLAGS="vect.exp=nodump-forwprop-22.c".
Ah, nodump- ... (I hate those weird name-based vect tests ...), so probably
fine as is.

Thanks,
Richard.

> 2012-10-11  Marc Glisse  
>
> PR testsuite/54868
> * gcc.dg/tree-ssa/forwprop-22.c: Move ...
> * gcc.dg/vect/nodump-forwprop-22.c: ... here. Adapt options.
>
> --
> Marc Glisse
> Index: gcc.dg/vect/nodump-forwprop-22.c
> ===
> --- gcc.dg/vect/nodump-forwprop-22.c(revision 192348)
> +++ gcc.dg/vect/nodump-forwprop-22.c(working copy)
> @@ -1,14 +1,14 @@
>  /* { dg-do compile } */
>  /* { dg-require-effective-target vect_double } */
>  /* { dg-require-effective-target vect_perm } */
> -/* { dg-options "-O -fdump-tree-copyprop1" } */
> +/* { dg-additional-options "-fdump-tree-copyprop1" } */
>
>  typedef double vec __attribute__((vector_size (2 * sizeof (double;
>  void f (vec *px, vec *y, vec *z)
>  {
>vec x = *px;
>vec t1 = { x[1], x[0] };
>vec t2 = { x[0], x[1] };
>*y = t1;
>*z = t2;
>  }
>

Re: [testsuite] PR 54868

[Marc Glisse]

On Thu, 11 Oct 2012, Richard Biener wrote:


On Thu, Oct 11, 2012 at 2:19 PM, Marc Glisse  wrote:

Hello,

understanding the testsuite is hard, but this patch seems to work. The idea
is that vect_double and others don't tell that vectors are supported with
these options, just that there exist options that enable vectors. They are
thus useless outside of a directory like vect/ that adds those flags.


Ok.  But you need to cleanup vect dumps as those are enabled by default
in vect.exp I think.  Just check for remaining files in gcc/testsuite/gcc
when running testing with RUNTESTFLAGS="vect.exp=nodump-forwprop-22.c".
Ah, nodump- ... (I hate those weird name-based vect tests ...), so probably
fine as is.


I didn't notice any remaining file, so I committed as is. Having the 
testcase compiled with -ftree-vectorize isn't great, but it doesn't hurt 
:-/


--
Marc Glisse

Re: [PATCH] Fold REDUC_*_EXPR

[Richard Biener]

On Wed, Oct 10, 2012 at 7:49 PM, Jakub Jelinek  wrote:
> Hi!
>
> This patch folds REDUC_*_EXPR (e.g. on pr54877.c -Ofast -mavx
> testcase we end up with unfolded REDUC_PLUS_EXPR till *.optimized).
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Eh, I didn't realize the result type is a vector ... can you adjust the docs
in tree.def to reflect that the _result_ is a vector with the first element
having the result and operand 0 is the vector being reduced?

Ok.

Thanks,
Richard.

> 2012-10-10  Jakub Jelinek  
>
> * fold-const.c (fold_unary_loc): Handle REDUC_MIN_EXPR,
> REDUC_MAX_EXPR and REDUC_PLUS_EXPR.
>
> --- gcc/fold-const.c.jj 2012-10-09 13:42:30.0 +0200
> +++ gcc/fold-const.c2012-10-10 12:28:11.768999520 +0200
> @@ -8294,6 +8294,40 @@ fold_unary_loc (location_t loc, enum tre
> return build_vector (type, elts);
>}
>
> +case REDUC_MIN_EXPR:
> +case REDUC_MAX_EXPR:
> +case REDUC_PLUS_EXPR:
> +  {
> +   unsigned int nelts = TYPE_VECTOR_SUBPARTS (type), i;
> +   tree *elts;
> +   enum tree_code subcode;
> +
> +   if (TREE_CODE (op0) != VECTOR_CST)
> + return NULL_TREE;
> +
> +   elts = XALLOCAVEC (tree, nelts);
> +   if (!vec_cst_ctor_to_array (op0, elts))
> + return NULL_TREE;
> +
> +   switch (code)
> + {
> + case REDUC_MIN_EXPR: subcode = MIN_EXPR; break;
> + case REDUC_MAX_EXPR: subcode = MAX_EXPR; break;
> + case REDUC_PLUS_EXPR: subcode = PLUS_EXPR; break;
> + default: gcc_unreachable ();
> + }
> +
> +   for (i = 1; i < nelts; i++)
> + {
> +   elts[0] = const_binop (subcode, elts[0], elts[i]);
> +   if (elts[0] == NULL_TREE || !CONSTANT_CLASS_P (elts[0]))
> + return NULL_TREE;
> +   elts[i] = build_zero_cst (TREE_TYPE (type));
> + }
> +
> +   return build_vector (type, elts);
> +  }
> +
>  default:
>return NULL_TREE;
>  } /* switch (code) */
>
> Jakub

[asan] Rename tree-asan.[ch] to asan.[ch]

[Diego Novillo]

As discussed earlier, this patch renames tree-asan.[ch] to asan.[ch].

Tested on x86_64.  Committed to branch.


Diego.

* asan.c: Rename from tree-asan.c.
Update all users.
* asan.h: Rename from tree-asan.h
Update all users.

Re: [PATCH] Fold REDUC_*_EXPR

[Jakub Jelinek]

On Thu, Oct 11, 2012 at 03:42:44PM +0200, Richard Biener wrote:
> On Wed, Oct 10, 2012 at 7:49 PM, Jakub Jelinek  wrote:
> > This patch folds REDUC_*_EXPR (e.g. on pr54877.c -Ofast -mavx
> > testcase we end up with unfolded REDUC_PLUS_EXPR till *.optimized).
> >
> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> Eh, I didn't realize the result type is a vector ... can you adjust the docs
> in tree.def to reflect that the _result_ is a vector with the first element
> having the result and operand 0 is the vector being reduced?

The comment wants to say that, but doesn't do it correctly:
   Operand 0 is a vector; the first element in the vector has the result.
   Operand 1 is a vector.  */
because obviously it doesn't have two operands, just one.  So it should be
perhaps
   Operand 0 is a vector.
   The expression returns a vector of the same type, with the first
   element in the vector holding the result of the reduction.  */
?

Jakub

Silecne array bounds warnings in duplicated code

[Jan Hubicka]

Hi,
this patch address problem I run into with strenghtened cunroll pass.  I made
cunroll to use loop_max_iterations bounds into an account that makes us to
occasionally produce out of bounds loop accesses in loop like:

for (i=0;i
  if (test)
break
  a[i]=1;
}
Here the constantly sized array appears in loop with multiple exits and we then
in the last iteration produce out of bound array (since we need to duplicate 
 and tree-ssa-vrp warns.

I think this is more generic problem (though appearing rarely): as soon as we
specialize the code, we can no longer warn about out of bounds accesses when we
prove array ref to be constant.  We have no idea if this code path will execute
in practice.

Seems resonable?  I think similar problems can be constructed by inlining, too.
Regtested/bootstrapped x86_64-linux.

Honza

* tree-cfg.c (gimple_duplicate_bb): Drop NO_WARNING on array refs.
Index: tree-cfg.c
===
*** tree-cfg.c  (revision 192360)
--- tree-cfg.c  (working copy)
*** gimple_duplicate_bb (basic_block bb)
*** 5504,5509 
--- 5504,5519 
if (lhs && TREE_CODE (lhs) != SSA_NAME)
{
  tree base = get_base_address (lhs);
+ tree op = lhs;
+
+ /* Silence the array bounds warning.  After specializing the code we
+no longer know if the particular code path can execute at runtime. 
 */
+ while (handled_component_p (op))
+   {
+ if (TREE_CODE (op) == ARRAY_REF)
+   TREE_NO_WARNING (op) = 1;
+ op =  TREE_OPERAND (op, 0);
+   }
  if (base
  && (TREE_CODE (base) == VAR_DECL
  || TREE_CODE (base) == RESULT_DECL)
*** gimple_duplicate_bb (basic_block bb)
*** 5514,5519 
--- 5521,5539 
  || !DECL_HAS_VALUE_EXPR_P (base)))
DECL_NONSHAREABLE (base) = 1;
}
+
+   /* Silence the array bounds warning.  After specializing the code we
+  no longer know if the particular code path can execute at runtime.  
*/
+   if (gimple_code (stmt) == GIMPLE_ASSIGN)
+   {
+ tree op = gimple_assign_rhs1 (stmt);
+ while (handled_component_p (op))
+   {
+ if (TREE_CODE (op) == ARRAY_REF)
+   TREE_NO_WARNING (op) = 1;
+ op =  TREE_OPERAND (op, 0);
+   }
+   }
  
/* Create new names for all the definitions created by COPY and
 add replacement mappings for each new name.  */

Re: [Dwarf Fission] Implement Fission Proposal (issue6305113)

[Jason Merrill]

On 10/10/2012 08:41 PM, Cary Coutant wrote:

I'm working on a follow-up patch to eliminate the duplicate references
to ".LVL" symbols by keeping a direct-lookup table in
dwarf2out_var_location. That will eliminate 310,266 of the 312,061
duplicates (99.4%) without using a hash table. With that patch, we'll
have only a 22% overhead due to duplicate entries.


That's certainly a big improvement, but 22% still seems worth addressing.


I'm trying to eliminate all .debug_addr entries that could be replaced
by an offset relative to either another .debug_addr entry or an
address in a range list.


Sounds good.


We use force_direct when we're adding an attribute to a DIE in a
skeleton compile unit or type unit (which will be in the .o file).
It's false everywhere else (i.e., when the DIE is going into the .dwo
file).


Right, so I was thinking that you could distinguish at output time 
between output going to .o vs .dwo and choose the appropriate addressing 
form then.


Jason

Re: Silecne array bounds warnings in duplicated code

[Richard Biener]

On Thu, 11 Oct 2012, Jan Hubicka wrote:

> Hi,
> this patch address problem I run into with strenghtened cunroll pass.  I made
> cunroll to use loop_max_iterations bounds into an account that makes us to
> occasionally produce out of bounds loop accesses in loop like:
> 
> for (i=0;i {
>   
>   if (test)
> break
>   a[i]=1;
> }
> Here the constantly sized array appears in loop with multiple exits and we 
> then
> in the last iteration produce out of bound array (since we need to duplicate 
>  and tree-ssa-vrp warns.
> 
> I think this is more generic problem (though appearing rarely): as soon as we
> specialize the code, we can no longer warn about out of bounds accesses when 
> we
> prove array ref to be constant.  We have no idea if this code path will 
> execute
> in practice.
> 
> Seems resonable?  I think similar problems can be constructed by inlining, 
> too.
> Regtested/bootstrapped x86_64-linux.

No, I don't think this is reasonable.  There are other PRs for this
as well, btw.

The array-bounds warning in VRP needs to be conditional if the
path to it isn't always executed, too (thus a may-be warning).

Richard.

> Honza
> 
>   * tree-cfg.c (gimple_duplicate_bb): Drop NO_WARNING on array refs.
> Index: tree-cfg.c
> ===
> *** tree-cfg.c(revision 192360)
> --- tree-cfg.c(working copy)
> *** gimple_duplicate_bb (basic_block bb)
> *** 5504,5509 
> --- 5504,5519 
> if (lhs && TREE_CODE (lhs) != SSA_NAME)
>   {
> tree base = get_base_address (lhs);
> +   tree op = lhs;
> +
> +   /* Silence the array bounds warning.  After specializing the code we
> +  no longer know if the particular code path can execute at runtime. 
>  */
> +   while (handled_component_p (op))
> + {
> +   if (TREE_CODE (op) == ARRAY_REF)
> + TREE_NO_WARNING (op) = 1;
> +   op =  TREE_OPERAND (op, 0);
> + }
> if (base
> && (TREE_CODE (base) == VAR_DECL
> || TREE_CODE (base) == RESULT_DECL)
> *** gimple_duplicate_bb (basic_block bb)
> *** 5514,5519 
> --- 5521,5539 
> || !DECL_HAS_VALUE_EXPR_P (base)))
>   DECL_NONSHAREABLE (base) = 1;
>   }
> +
> + /* Silence the array bounds warning.  After specializing the code we
> +no longer know if the particular code path can execute at runtime.  
> */
> +   if (gimple_code (stmt) == GIMPLE_ASSIGN)
> + {
> +   tree op = gimple_assign_rhs1 (stmt);
> +   while (handled_component_p (op))
> + {
> +   if (TREE_CODE (op) == ARRAY_REF)
> + TREE_NO_WARNING (op) = 1;
> +   op =  TREE_OPERAND (op, 0);
> + }
> + }
>   
> /* Create new names for all the definitions created by COPY and
>add replacement mappings for each new name.  */
> 
> 

-- 
Richard Biener 
SUSE / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imend

Re: [PATCH] Fold REDUC_*_EXPR

[Richard Biener]

On Thu, Oct 11, 2012 at 3:47 PM, Jakub Jelinek  wrote:
> On Thu, Oct 11, 2012 at 03:42:44PM +0200, Richard Biener wrote:
>> On Wed, Oct 10, 2012 at 7:49 PM, Jakub Jelinek  wrote:
>> > This patch folds REDUC_*_EXPR (e.g. on pr54877.c -Ofast -mavx
>> > testcase we end up with unfolded REDUC_PLUS_EXPR till *.optimized).
>> >
>> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>>
>> Eh, I didn't realize the result type is a vector ... can you adjust the docs
>> in tree.def to reflect that the _result_ is a vector with the first element
>> having the result and operand 0 is the vector being reduced?
>
> The comment wants to say that, but doesn't do it correctly:
>Operand 0 is a vector; the first element in the vector has the result.
>Operand 1 is a vector.  */
> because obviously it doesn't have two operands, just one.  So it should be
> perhaps
>Operand 0 is a vector.
>The expression returns a vector of the same type, with the first
>element in the vector holding the result of the reduction.  */
> ?

Yes.  It also should specify that the other elements are zero (or is that
just your choice of "arbitrary"?)

Richard.

> Jakub

[asan] Target hook for shadow memory offset

[Jakub Jelinek]

Hi!

As the shadow memory offset ored into shifted addresses is clearly
target specific (1 << 29 on i?86, 1LL << 44 on x86_64, 0 on ARM?,
no support on other target so far), it should be IMHO a target hook.

Ok for asan?

2012-10-11  Jakub Jelinek  

* toplev.c (process_options): Warn and turn off -fasan
if not supported by target.
* asan.c: Include target.h.
(asan_scale, asan_offset_log_32, asan_offset_log_64,
asan_offset_log): Removed.
(build_check_stmt): Use ASAN_SHADOW_SHIFT and
targetm.asan_shadow_offset ().
(asan_instrument): Don't initialize asan_offset_log.
* asan.h (ASAN_SHADOW_SHIFT): Define.
* target.def (TARGET_ASAN_SHADOW_OFFSET): New hook.
* doc/tm.texi.in (TARGET_ASAN_SHADOW_OFFSET): Add it.
* doc/tm.texi: Regenerated.
* Makefile.in (asan.o): Depend on $(TARGET_H).
* config/i386/i386.c (ix86_asan_shadow_offset): New function.
(TARGET_ASAN_SHADOW_OFFSET): Define.

--- gcc/toplev.c.jj 2012-10-11 15:48:57.0 +0200
+++ gcc/toplev.c2012-10-11 16:02:35.705971610 +0200
@@ -1543,6 +1543,13 @@ process_options (void)
   flag_omit_frame_pointer = 0;
 }
 
+  /* Address Sanitizer needs porting to each target architecture.  */
+  if (flag_asan && targetm.asan_shadow_offset == NULL)
+{
+  warning (0, "-fasan not supported for this target");
+  flag_asan = 0;
+}
+
   /* Enable -Werror=coverage-mismatch when -Werror and -Wno-error
  have not been set.  */
   if (!global_options_set.x_warnings_are_errors
--- gcc/asan.c.jj   2012-10-11 15:48:57.0 +0200
+++ gcc/asan.c  2012-10-11 16:10:05.774466691 +0200
@@ -1,5 +1,5 @@
 /* AddressSanitizer, a fast memory error detector.
-   Copyright (C) 2011 Free Software Foundation, Inc.
+   Copyright (C) 2011, 2012 Free Software Foundation, Inc.
Contributed by Kostya Serebryany 
 
 This file is part of GCC.
@@ -42,6 +42,7 @@ along with GCC; see the file COPYING3.
 #include "gimple.h"
 #include "asan.h"
 #include "gimple-pretty-print.h"
+#include "target.h"
 
 /*
  AddressSanitizer finds out-of-bounds and use-after-free bugs 
@@ -78,15 +79,6 @@ along with GCC; see the file COPYING3.
  to create redzones for stack and global object and poison them.
 */
 
-/* The shadow address is computed as (X>>asan_scale) + (1<> asan_scale) + (1 << asan_offset_log).  */
+  /* Build
+ (base_addr >> ASAN_SHADOW_SHIFT) | targetm.asan_shadow_offset ().  */
 
   t = build2 (RSHIFT_EXPR, uintptr_type, base_addr,
-  build_int_cst (uintptr_type, asan_scale));
+ build_int_cst (uintptr_type, ASAN_SHADOW_SHIFT));
   t = build2 (PLUS_EXPR, uintptr_type, t,
-  build2 (LSHIFT_EXPR, uintptr_type,
-  build_int_cst (uintptr_type, 1),
-  build_int_cst (uintptr_type, asan_offset_log)
- ));
+ build_int_cst (uintptr_type, targetm.asan_shadow_offset ()));
   t = build1 (INDIRECT_REF, shadow_type,
   build1 (VIEW_CONVERT_EXPR, shadow_ptr_type, t));
   t = force_gimple_operand (t, &stmts, false, NULL_TREE);
@@ -367,9 +357,6 @@ static unsigned int
 asan_instrument (void)
 {
   struct gimplify_ctx gctx;
-  tree uintptr_type = lang_hooks.types.type_for_mode (ptr_mode, true);
-  int is_64 = tree_low_cst (TYPE_SIZE (uintptr_type), 0) == 64;
-  asan_offset_log = is_64 ? asan_offset_log_64 : asan_offset_log_32;
   push_gimplify_context (&gctx);
   transform_statements ();
   pop_gimplify_context (NULL);
--- gcc/asan.h.jj   2012-10-11 15:48:57.0 +0200
+++ gcc/asan.h  2012-10-11 16:04:28.104341435 +0200
@@ -1,5 +1,5 @@
 /* AddressSanitizer, a fast memory error detector.
-   Copyright (C) 2011 Free Software Foundation, Inc.
+   Copyright (C) 2011, 2012 Free Software Foundation, Inc.
Contributed by Kostya Serebryany 
 
 This file is part of GCC.
@@ -23,4 +23,8 @@ along with GCC; see the file COPYING3.
 
 extern void asan_finish_file(void);
 
+/* Shadow memory is found at
+   (address >> ASAN_SHADOW_SHIFT) | targetm.asan_shadow_offset ().  */
+#define ASAN_SHADOW_SHIFT  3
+
 #endif /* TREE_ASAN */
--- gcc/target.def.jj   2012-10-11 11:46:34.0 +0200
+++ gcc/target.def  2012-10-11 15:39:50.076618675 +0200
@@ -2025,6 +2025,17 @@ DEFHOOK
  "",
  unsigned HOST_WIDE_INT, (unsigned HOST_WIDE_INT val), NULL)
 
+/* Defines an offset bitwise ored into shifted address to get corresponding
+   Address Sanitizer shadow address, or -1 if Address Sanitizer is not
+   supported by the target.  */
+DEFHOOK
+(asan_shadow_offset,
+ "Return the offset bitwise ored into shifted address to get corresponding\n\
+Address Sanitizer shadow memory address.  NULL if Address Sanitizer is not\n\
+supported by the target.",
+ unsigned HOST_WIDE_INT, (void),
+ NULL)
+
 /* Functions relating to calls - argument passing, returns, etc.  */
 /* Members of struct call have no special macro prefix.  */
 HOOK_VECTOR (TARGET_CALLS, 

Re: [PATCH] Fold REDUC_*_EXPR

[Jakub Jelinek]

On Thu, Oct 11, 2012 at 04:30:42PM +0200, Richard Biener wrote:
> > The comment wants to say that, but doesn't do it correctly:
> >Operand 0 is a vector; the first element in the vector has the result.
> >Operand 1 is a vector.  */
> > because obviously it doesn't have two operands, just one.  So it should be
> > perhaps
> >Operand 0 is a vector.
> >The expression returns a vector of the same type, with the first
> >element in the vector holding the result of the reduction.  */
> > ?
> 
> Yes.  It also should specify that the other elements are zero (or is that
> just your choice of "arbitrary"?)

That was my choice of arbitrary.  Guess what the hw insns leave in there is
pretty much random, could be copies of the result in all elements, or
temporaries from pairwise reductions, etc.

Jakub

Re: [doc] Vector operations

[Richard Biener]

On Thu, Oct 11, 2012 at 11:25 AM, Marc Glisse  wrote:
> Hello,
>
> this documents both my latest C++ FE patch, something I noticed while doing
> the FE work (shifts can mix vectors and scalars) and the result of the
> conversation with Richard B on how the middle-end should model vector truth
> values. The patch is a little early compared to the code (VEC_COND_EXPR
> still requires a comparison as first argument) but that shouldn't take too
> long to fix and it documents the intent.

Ok.

Many thanks,
Richard.

> 2012-10-11  Marc Glisse  
>
> * doc/extend.texi (Vector Extensions): C++ improvements.
> * doc/generic.texi (LSHIFT_EXPR, RSHIFT_EXPR): Mixed vector-scalar.
> (LT_EXPR, LE_EXPR, GT_EXPR, GE_EXPR, EQ_EXPR, NE_EXPR): Specify
> the vector case.
> (VEC_COND_EXPR): Document it.
>
> --
> Marc Glisse
> Index: doc/generic.texi
> ===
> --- doc/generic.texi(revision 192348)
> +++ doc/generic.texi(working copy)
> @@ -1381,21 +1381,22 @@ a fixed-point value to a floating-point
>
>  @item LSHIFT_EXPR
>  @itemx RSHIFT_EXPR
>  These nodes represent left and right shifts, respectively.  The first
>  operand is the value to shift; it will always be of integral type.  The
>  second operand is an expression for the number of bits by which to
>  shift.  Right shift should be treated as arithmetic, i.e., the
>  high-order bits should be zero-filled when the expression has unsigned
>  type and filled with the sign bit when the expression has signed type.
>  Note that the result is undefined if the second operand is larger
> -than or equal to the first operand's type size.
> +than or equal to the first operand's type size. Unlike most nodes, these
> +can have a vector as first operand and a scalar as second operand.
>
>
>  @item BIT_IOR_EXPR
>  @itemx BIT_XOR_EXPR
>  @itemx BIT_AND_EXPR
>  These nodes represent bitwise inclusive or, bitwise exclusive or, and
>  bitwise and, respectively.  Both operands will always have integral
>  type.
>
>  @item TRUTH_ANDIF_EXPR
> @@ -1475,25 +1476,26 @@ allows the backend to choose between the
>  @code{CEIL_DIV_EXPR} and @code{FLOOR_DIV_EXPR} for the current target.
>
>  @item LT_EXPR
>  @itemx LE_EXPR
>  @itemx GT_EXPR
>  @itemx GE_EXPR
>  @itemx EQ_EXPR
>  @itemx NE_EXPR
>  These nodes represent the less than, less than or equal to, greater
>  than, greater than or equal to, equal, and not equal comparison
> -operators.  The first and second operand with either be both of integral
> -type or both of floating type.  The result type of these expressions
> -will always be of integral or boolean type.  These operations return
> -the result type's zero value for false, and the result type's one value
> -for true.
> +operators.  The first and second operands will either be both of integral
> +type, both of floating type or both of vector type.  The result type of
> +these expressions will always be of integral, boolean or signed integral
> +vector type.  These operations return the result type's zero value for
> +false, the result type's one value for true, and a vector whose elements
> +are zero (false) or minus one (true) for vectors.
>
>  For floating point comparisons, if we honor IEEE NaNs and either operand
>  is NaN, then @code{NE_EXPR} always returns true and the remaining operators
>  always return false.  On some targets, comparisons against an IEEE NaN,
>  other than equality and inequality, may generate a floating point
> exception.
>
>  @item ORDERED_EXPR
>  @itemx UNORDERED_EXPR
>  These nodes represent non-trapping ordered and unordered comparison
>  operators.  These operations take two floating point operands and
> @@ -1762,20 +1764,31 @@ is half as wide.  The elements of the tw
>  (concatenated) to form the output vector.
>
>  @item VEC_PACK_FIX_TRUNC_EXPR
>  This node represents packing of elements of the two input vectors into the
>  output vector, where the values are converted from floating point
>  to fixed point.  Input operands are vectors that contain the same number
>  of elements of a floating point type.  The result is a vector that contains
>  twice as many elements of an integral type whose size is half as wide.  The
>  elements of the two vectors are merged (concatenated) to form the output
>  vector.
> +
> +@item VEC_COND_EXPR
> +These nodes represent @code{?:} expressions.  The three operands must be
> +vectors of the same size and number of elements.  The second and third
> +operands must have the same type as the entire expression.  The first
> +operand is of signed integral vector type.  If an element of the first
> +operand evaluates to a zero value, the corresponding element of the
> +result is taken from the third operand. If it evaluates to a minus one
> +value, it is taken from the second operand. It should never evaluate to
> +any other value. In contrast with a @code{COND_EXPR}, all operands are
> +always evaluated.
>  @end table
>
>

Re: [PATCH] Fold REDUC_*_EXPR

[Richard Biener]

On Thu, Oct 11, 2012 at 4:33 PM, Jakub Jelinek  wrote:
> On Thu, Oct 11, 2012 at 04:30:42PM +0200, Richard Biener wrote:
>> > The comment wants to say that, but doesn't do it correctly:
>> >Operand 0 is a vector; the first element in the vector has the result.
>> >Operand 1 is a vector.  */
>> > because obviously it doesn't have two operands, just one.  So it should be
>> > perhaps
>> >Operand 0 is a vector.
>> >The expression returns a vector of the same type, with the first
>> >element in the vector holding the result of the reduction.  */
>> > ?
>>
>> Yes.  It also should specify that the other elements are zero (or is that
>> just your choice of "arbitrary"?)
>
> That was my choice of arbitrary.  Guess what the hw insns leave in there is
> pretty much random, could be copies of the result in all elements, or
> temporaries from pairwise reductions, etc.

Ok - in other places we try to match HW behavior during constant folding
(famous SHIFT_COUNT_TRUNCATED handling ...), but I suppose it's
not even documented.

Richard.

> Jakub

[C++ testcase] PR 36107

[Paolo Carlini]

Hi,

testcase added to testsuite, PR closed as fixed.

Thanks,
Paolo.

/
2012-10-11  Paolo Carlini  

PR c++/36107
* g++.dg/ext/weak5.C: New.
Index: g++.dg/ext/weak5.C
===
--- g++.dg/ext/weak5.C  (revision 0)
+++ g++.dg/ext/weak5.C  (working copy)
@@ -0,0 +1,12 @@
+// PR c++/36107
+// { dg-do assemble }
+// { dg-require-weak "" }
+
+class Test {
+  public:
+  Test() __attribute__((weak));
+};
+
+void test() {
+  Test test;
+}

Re: [asan] Target hook for shadow memory offset

[H.J. Lu]

On Thu, Oct 11, 2012 at 7:32 AM, Jakub Jelinek  wrote:
> Hi!
>
> As the shadow memory offset ored into shifted addresses is clearly
> target specific (1 << 29 on i?86, 1LL << 44 on x86_64, 0 on ARM?,
> no support on other target so far), it should be IMHO a target hook.
>
> Ok for asan?
>

> --- gcc/config/i386/i386.c.jj   2012-10-11 11:53:58.0 +0200
> +++ gcc/config/i386/i386.c  2012-10-11 15:59:45.708922960 +0200
> @@ -5619,6 +5619,14 @@ ix86_legitimate_combined_insn (rtx insn)
>return true;
>  }
>
> +/* Implement the TARGET_ASAN_SHADOW_OFFSET hook.  */
> +
> +static unsigned HOST_WIDE_INT
> +ix86_asan_shadow_offset (void)
> +{
> +  return (unsigned HOST_WIDE_INT) 1 << (Pmode == DImode ? 44 : 29);
> +}
> +

I think you should use TARGET_LP64 instead of Pmode == DImode.


-- 
H.J.

Re: [PATCH, libstdc++] Fix missing gthr-default.h issue on libstdc++ configure

[David Edelsohn]

AIX bootstrap is broken after this change.

This patch also should not have been approved for GCC 4.7 branch
without wider testing on trunk.

Would you please revert this patch while you figure out how to provide
the previous libstdc++ build behavior?

Thanks, David

Re: [PATCH, libstdc++] Fix missing gthr-default.h issue on libstdc++ configure

[Pavel Chupin]

Could you try this fix?

-- 
Pavel Chupin
Intel Corporation


Fix-missing-gthr-aix.h.patch
Description: Binary data

Re: [PATCH, libstdc++] Fix missing gthr-default.h issue on libstdc++ configure

[Rainer Orth]

Pavel Chupin  writes:

> Could you try this fix?

Duplicating this much info from libgcc is certainly the wrong (read:
unmaintainable) approach.

Rainer

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

Re: [PATCH 0/6] Thread pointer built-in functions

[Chung-Lin Tang]

This patch set has been committed, thanks to all maintainers who
reviewed the respective parts.

Thanks,
Chung-Lin

Full ChangeLog:

2012-10-11  Chung-Lin Tang  

* builtins.c (expand_builtin_thread_pointer): New.
(expand_builtin_set_thread_pointer): New.
(expand_builtin): Add BUILT_IN_THREAD_POINTER,
BUILT_IN_SET_THREAD_POINTER expand cases.
* builtins.def (BUILT_IN_THREAD_POINTER):
New __builtin_thread_pointer builtin.
(BUILT_IN_SET_THREAD_POINTER):
New __builtin_set_thread_pointer builtin.
* optabs.def (get_thread_pointer,set_thread_pointer):
New standard names.
* doc/md.texi (Standard Names): Document get_thread_pointer and
set_thread_pointer patterns.
* config/alpha/alpha.md (get_thread_pointerdi): Rename from load_tp.
(set_thread_pointerdi): Rename from set_tp.
* config/alpha/alpha.c (alpha_legitimize_address_1): Change
gen_load_tp calls to gen_get_thread_pointerdi.
(alpha_builtin): Remove ALPHA_BUILTIN_THREAD_POINTER,
ALPHA_BUILTIN_SET_THREAD_POINTER.
(code_for_builtin): Remove CODE_FOR_load_tp, CODE_FOR_set_tp.
(alpha_init_builtins): Remove __builtin_thread_pointer,
__builtin_set_thread_pointer machine-specific builtins.
(alpha_expand_builtin_thread_pointer): Add hook function for
TARGET_EXPAND_BUILTIN_THREAD_POINTER.
(alpha_expand_builtin_set_thread_pointer): Add hook function for
TARGET_EXPAND_BUILTIN_SET_THREAD_POINTER.
(alpha_fold_builtin): Remove ALPHA_BUILTIN_THREAD_POINTER,
ALPHA_BUILTIN_SET_THREAD_POINTER cases.
* config/arm/arm.md (get_thread_pointersi): New pattern.
* config/arm/arm-protos.h (arm_load_tp): Add extern declaration.
* config/arm/arm.c (arm_load_tp): Remove static.
(arm_builtins): Remove ARM_BUILTIN_THREAD_POINTER.
(arm_init_tls_builtins): Remove function.
(arm_init_builtins): Remove call to arm_init_tls_builtins().
(arm_expand_builtin): Remove ARM_BUILTIN_THREAD_POINTER case.
* config/mips/mips.md (get_thread_pointer): New pattern.
* config/mips/mips-protos.h (mips_expand_thread_pointer):
Add extern declaration.
* config/mips/mips.c (mips_expand_thread_pointer):
Renamed from mips_get_tp.
(mips_get_tp): New stub calling mips_expand_thread_pointer.
* config/s390/s390.c (s390_builtin,code_for_builtin_64,
code_for_builtin_31,s390_init_builtins,s390_expand_builtin): Remove.
* config/s390/s390.md (get_tp_64,get_tp_31,set_tp_64,set_tp_31):
Remove.
(get_thread_pointer,set_thread_pointer):
New, adapted from removed patterns.
* config/xtensa/xtensa.md (get_thread_pointersi):
Renamed from load_tp.
(set_thread_pointersi): Renamed from set_tp.
* config/xtensa/xtensa.c (xtensa_legitimize_tls_address):
Change gen_load_tp calls to gen_get_thread_pointersi.
(xtensa_builtin): Remove XTENSA_BUILTIN_THREAD_POINTER and
XTENSA_BUILTIN_SET_THREAD_POINTER.
(xtensa_init_builtins): Remove __builtin_thread_pointer,
__builtin_set_thread_pointer machine-specific builtins.
(xtensa_fold_builtin): Remove XTENSA_BUILTIN_THREAD_POINTER,
XTENSA_BUILTIN_SET_THREAD_POINTER cases.
(xtensa_expand_builtin): Remove XTENSA_BUILTIN_THREAD_POINTER,
XTENSA_BUILTIN_SET_THREAD_POINTER cases.

Small configure.ac PATCH for aix configury

[Jason Merrill]

The check for .ref support on AIX used the wrong syntax, leading to 
broken output from autoconf.


Tested by configuring a cross-compiler, applying to trunk as obvious.
commit 885339b51d3221bcceabeaf9b2e5f39664ad947d
Author: Jason Merrill 
Date:   Thu Oct 11 09:01:49 2012 -0400

* configure.ac (gcc_cv_as_aix_ref): Fix typo.
* configure: Regenerate.

diff --git a/gcc/configure b/gcc/configure
index a7cc645..387de5b 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -25363,8 +25363,8 @@ if test "${gcc_cv_as_aix_ref+set}" = set; then :
 else
   gcc_cv_as_aix_ref=no
 if test $in_tree_gas = yes; then
-if test $gcc_cv_gas_vers -ge `expr \( \( 2.21.0 \* 1000 \) + gcc_cv_as_aix_ref=yes \) \* 1000 + `
-  then :
+if test $gcc_cv_gas_vers -ge `expr \( \( 2 \* 1000 \) + 21 \) \* 1000 + 0`
+  then gcc_cv_as_aix_ref=yes
 fi
   elif test x$gcc_cv_as != x; then
 $as_echo '	.csect stuff[rw]
diff --git a/gcc/configure.ac b/gcc/configure.ac
index f57f3cd..b6c049b 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -3893,7 +3893,7 @@ LCF0:
 case $target in
   *-*-aix*)
 	gcc_GAS_CHECK_FEATURE([.ref support],
-	  gcc_cv_as_aix_ref, [2.21.0],,
+	  gcc_cv_as_aix_ref, [2,21,0],,
 	  [	.csect stuff[[rw]]
 	 stuff:
 		.long 1

Re: Move statements upwards after reassociation

[Xinliang David Li]

On Thu, Oct 11, 2012 at 6:16 AM, Richard Biener
 wrote:
> On Thu, Oct 11, 2012 at 3:52 AM, Easwaran Raman  wrote:
>> Hi,
>>  In the expression reassociation pass, statements might get moved
>> downwards to ensure that dependences are not violated after
>> reassociation. This can increase the live range and, in a tight loop,
>> result in spills.  This patch simply does a code motion of those
>> statements involved in reassociation and pushes them upwards in the BB
>> as far as possible without violating dependences. Bootstraps and no
>> tests regressions on a x86_64 machine running linux. Ok for trunk?
>
> I don't think reassoc is the right place to do this.  There was the idea
> of a tree-level "scheduling" pass, some of which (and I suppose some
> of your changes) TER later happily will un-do.

Before the tree scheduling pass exists, I think the small local change
in the patch is  the right step forward.

>
> Few comments:
>
>>
>> - Easwaran
>>
>> ---
>> 2012-10-10  Easwaran Raman  
>>
>>* tree-ssa-reassoc.c (move_stmt_upwards): New function.
>>  (rewrite_expr_tree): Record statements to be moved.
>>  (reassociate_bb): Move statements affected by reassociation
>>  as early as possible.
>>
>> Index: gcc/tree-ssa-reassoc.c
>> ===
>> --- gcc/tree-ssa-reassoc.c (revision 191879)
>> +++ gcc/tree-ssa-reassoc.c (working copy)
>> @@ -2250,13 +2250,51 @@ swap_ops_for_binary_stmt (VEC(operand_entry_t, hea
>>  }
>>  }
>>
>> +/* Move STMT up within its BB until it can not be moved any further.  */
>> +
>> +static void move_stmt_upwards (gimple stmt)
>> +{
>> +  gimple_stmt_iterator gsi, gsistmt;
>> +  tree rhs1, rhs2;
>> +  gimple rhs1def = NULL, rhs2def = NULL;
>> +  rhs1 = gimple_assign_rhs1 (stmt);
>> +  rhs2 = gimple_assign_rhs2 (stmt);
>> +  gcc_assert (rhs1);
>
> Please no such senseless asserts.  The following line will segfault anyway
> if rhs1 is NULL and with a debugger an assert doesn't add any useful
> information.

Did Ian add the stack trace support?

>
>> +  if (TREE_CODE (rhs1) == SSA_NAME)
>> +rhs1def = SSA_NAME_DEF_STMT (rhs1);
>> +  else if (TREE_CODE (rhs1) != REAL_CST
>> +   && TREE_CODE (rhs1) != INTEGER_CST)
>> +return;
>> +  if (rhs2)
>
> You may not access gimple_assign_rhs2 if it is not there.  So you have
> to check whether you have an unary, binary or ternary (yes) operation.
>
>> +{
>> +  if (TREE_CODE (rhs2) == SSA_NAME)
>> +rhs2def = SSA_NAME_DEF_STMT (rhs2);
>> +  else if (TREE_CODE (rhs1) != REAL_CST
>> +   && TREE_CODE (rhs1) != INTEGER_CST)
>> +return;
>> +}
>> +  gsi = gsi_for_stmt (stmt);
>> +  gsistmt = gsi;
>> +  gsi_prev (&gsi);
>> +  for (; !gsi_end_p (gsi); gsi_prev (&gsi))
>
> 
>
> This doesn't make much sense.  You can move a stmt to the nearest
> common post-dominator.  Assuming you only want to handle placing
> it after rhs1def or after rhs2def(?) you don't need any loop, just
> two dominator queries and an insertion after one of the definition
> stmts.

The loop is used to do intra-bb code motion for all stmts forming a
linearized expressions (which has been sinked down). 'dominance' query
is not any cheaper within a BB.  It is true that re-association can
sink stmts across BB boundaries.

>
> But this code should consider BBs.  And I don't see why more optimal
> placement cannot be done during rewrite_expr_tree itself.
>

I suppose the patch is not trying to do optimal placement, but undo
some of the code motions re-association does that have bad side
effects.

> NB, the whole reassoc code needs a re-write to avoid the excessive
> stmt modifications when it does nothing.  So I'd very much rather avoid
> adding anything to reassoc until that rewrite happened.

When will that happen?

thanks,

David

>
> Richard.
>
>> +{
>> +  gimple curr_stmt = gsi_stmt (gsi);
>> +  if (curr_stmt == rhs1def || curr_stmt == rhs2def) {
>> +gsi_move_after (&gsistmt, &gsi);
>> +return;
>> +  }
>> +}
>> +
>> +}
>> +
>>  /* Recursively rewrite our linearized statements so that the operators
>> match those in OPS[OPINDEX], putting the computation in rank
>> order.  */
>>
>>  static void
>>  rewrite_expr_tree (gimple stmt, unsigned int opindex,
>> -   VEC(operand_entry_t, heap) * ops, bool moved)
>> +   VEC(operand_entry_t, heap) * ops, bool moved,
>> +   VEC(gimple, heap) **stmts_to_move)
>>  {
>>tree rhs1 = gimple_assign_rhs1 (stmt);
>>tree rhs2 = gimple_assign_rhs2 (stmt);
>> @@ -2299,6 +2337,7 @@ rewrite_expr_tree (gimple stmt, unsigned int opind
>>print_gimple_stmt (dump_file, stmt, 0, 0);
>>  }
>>   }
>> +  VEC_safe_push (gimple, heap, *stmts_to_move, stmt);
>>return;
>>  }
>>
>> @@ -2346,7 +2385,9 @@ rewrite_expr_tree (gimple stmt, unsigned int opind
>>  }
>>/* Recurse on the LHS of the

Re: RFC: C++ PATCH to support dynamic initialization and destruction of C++11 and OpenMP TLS variables

[Jason Merrill]

On 10/09/2012 11:27 AM, Jason Merrill wrote:

FAIL: g++.dg/tls/thread_local7.C scan-assembler-not \\.data


I've changed this test to require native TLS.


FAIL: g++.dg/tls/static-1.C *


And I've fixed the compiler to not mess with thread_local wrappers on 
this test, since it uses __thread.


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

commit 3c317cba2f2b6100987ee720f7d7da76f5f43c19
Author: Jason Merrill 
Date:   Tue Oct 9 12:55:52 2012 -0400

	* decl.c (grokdeclarator): Set DECL_GNU_TLS_P for static data
	members, too.

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 0b936ea..e78c664 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -10446,7 +10446,11 @@ grokdeclarator (const cp_declarator *declarator,
 		DECL_EXTERNAL (decl) = 1;
 
 		if (thread_p)
-		  DECL_TLS_MODEL (decl) = decl_default_tls_model (decl);
+		  {
+		DECL_TLS_MODEL (decl) = decl_default_tls_model (decl);
+		if (declspecs->gnu_thread_keyword_p)
+		  DECL_GNU_TLS_P (decl) = true;
+		  }
 
 		if (constexpr_p && !initialized)
 		  {
diff --git a/gcc/testsuite/g++.dg/gomp/tls-5.C b/gcc/testsuite/g++.dg/gomp/tls-5.C
index 74e4faa..f1dcdae 100644
--- a/gcc/testsuite/g++.dg/gomp/tls-5.C
+++ b/gcc/testsuite/g++.dg/gomp/tls-5.C
@@ -1,6 +1,7 @@
 // The reference temp should be TLS, not normal data.
 // { dg-require-effective-target c++11 }
-// { dg-final { scan-assembler-not "\\.data" } }
+// { dg-require-alias }
+// { dg-final { scan-assembler-not "\\.data" { target tls_native } } }
 
 extern int&& ir;
 #pragma omp threadprivate (ir)
diff --git a/gcc/testsuite/g++.dg/tls/static2.C b/gcc/testsuite/g++.dg/tls/static2.C
new file mode 100644
index 000..ab688dd
--- /dev/null
+++ b/gcc/testsuite/g++.dg/tls/static2.C
@@ -0,0 +1,18 @@
+// { dg-final { scan-assembler-not "_ZTHN1A1iE" } }
+// { dg-final { scan-assembler-not "_ZTWN1A1iE" } }
+// { dg-require-effective-target tls }
+
+struct A
+{
+  static __thread int i;
+};
+
+int
+test ()
+{
+  if (A::i != 8)
+return 1;
+
+  A::i = 17;
+  return 0;
+}
diff --git a/gcc/testsuite/g++.dg/tls/thread_local7.C b/gcc/testsuite/g++.dg/tls/thread_local7.C
index 77a1c05..f453b96 100644
--- a/gcc/testsuite/g++.dg/tls/thread_local7.C
+++ b/gcc/testsuite/g++.dg/tls/thread_local7.C
@@ -2,7 +2,7 @@
 // { dg-require-effective-target tls }
 
 // The reference temp should be TLS, not normal data.
-// { dg-final { scan-assembler-not "\\.data" } }
+// { dg-final { scan-assembler-not "\\.data" { target tls_native } } }
 
 void f()
 {

Re: RFA: darwin PATCH to fix build, internal visibility

[Jason Merrill]

OK, I've checked this in:
commit 2425dc8daa33d8b5d15c803c9bf2f51f5e1915a0
Author: Jason Merrill 
Date:   Tue Oct 9 21:16:52 2012 -0400

	* g++.dg/ext/visibility/pragma-override1.C: Fix target markup.
	* g++.dg/ext/visibility/pragma-override2.C: Fix target markup.

diff --git a/gcc/testsuite/g++.dg/ext/visibility/pragma-override1.C b/gcc/testsuite/g++.dg/ext/visibility/pragma-override1.C
index b813390..c13161d 100644
--- a/gcc/testsuite/g++.dg/ext/visibility/pragma-override1.C
+++ b/gcc/testsuite/g++.dg/ext/visibility/pragma-override1.C
@@ -1,7 +1,7 @@
 /* Test that #pragma GCC visibility does not override class member specific settings. */
 /* { dg-do compile } */
 /* { dg-require-visibility "internal" } */
-/* { dg-final { scan-assembler "\\.internal.*Foo.methodEv" { target { ! *-*-solaris2* } { ! *-*-darwin* } } } }*/
+/* { dg-final { scan-assembler "\\.internal.*Foo.methodEv" { target { ! { *-*-solaris2* *-*-darwin* } } } } } */
 /* { dg-final { scan-assembler "\\.(internal|hidden).*Foo.methodEv" { target *-*-solaris2* } } } */
 
 #pragma GCC visibility push(hidden)
diff --git a/gcc/testsuite/g++.dg/ext/visibility/pragma-override2.C b/gcc/testsuite/g++.dg/ext/visibility/pragma-override2.C
index 3ceaf4a..25e9cea 100644
--- a/gcc/testsuite/g++.dg/ext/visibility/pragma-override2.C
+++ b/gcc/testsuite/g++.dg/ext/visibility/pragma-override2.C
@@ -1,7 +1,7 @@
 /* Test that #pragma GCC visibility does not override class member specific settings. */
 /* { dg-do compile } */
 /* { dg-require-visibility "internal" } */
-/* { dg-final { scan-assembler "\\.internal.*Foo.methodEv" { target { ! *-*-solaris2* } { ! *-*-darwin* } } } } */
+/* { dg-final { scan-assembler "\\.internal.*Foo.methodEv" { target { ! { *-*-solaris2* *-*-darwin* } } } } } */
 /* { dg-final { scan-assembler "\\.(internal|hidden).*Foo.methodEv" { target *-*-solaris2* } } } */
 
 #pragma GCC visibility push(hidden)

Re: PING Re: [PATCH, MIPS] add new peephole for 74k dspr2

[Maciej W. Rozycki]

On Wed, 10 Oct 2012, Richard Sandiford wrote:

> >  I've thought of -miterative-mdu or suchlike a knob that would override 
> > the default cost of multiplication/division as appropriate (i.e. to 32/64 
> > plus any extra operation-specific constant as required), perhaps by 
> > forcing the 4Kp insn reservation (extended to 64 bits as required) over 
> > the usual one; of course there would be nothing to override the -mtune=4Kp 
> > arrangement with.  Nothing urgent though, just an idea to ponder.
> 
> FWIW, using the 4Kp reservation itself wouldn't necessarily work,
> because all modern scheduling descriptions define their own CPU units.
> You'd probably need to add new reservations to each affected MIPS32
> and MIPS64 .md file.

 Thanks for the hint.  I have skimmed through documentation I have 
available and the following MTI processors implement an iterative MDU as 
an RTL option: M4K, M14K, M14Kc, and the following ones always have one: 
4Kp, 4KEp.  No 64-bit MTI processor had it so far it would seem (the 5K 
chips have an iterative divider and a high-performance multiplier).

 We currently have no pipeline descriptions for any of the M cores, so my 
concern seemed to be a little bit premature (though still valid of 
course).  The option proposed will only be needed once/if we get any of 
the respective pipeline descriptions.  Arguably anyone targetting them is 
likely going to be after -Os anyway, although at least with the M14Kc I 
think it should not be taken for granted.

 We're missing a pipeline description for the 4KE-family cores as well.  
If not adding costs for the extra MIPS32r2 additions I think at the very 
least we should trivially enable the existing bits of 4k.md for these 
cores; the pipeline is the same across the whole 4K/4KE family and it's 
only the extra instructions that have been added with the E update.

  Maciej

C++ PATCH to limit DECL_THUNKS to virtual functions

[Jason Merrill]

The two current users of this field are DECL_FRIEND_CONTEXT for friend 
functions and DECL_THUNKS for virtual member functions; I would like to 
use it for another purpose for constructors, so I'm changing DECL_THUNKS 
to return null for non-virtual functions.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit 256548b555a1bbfc2ad184ebf9ac9b10cb6798f6
Author: Jason Merrill 
Date:   Tue Oct 9 22:30:49 2012 -0400

	* cp-tree.h (DECL_THUNKS): NULL_TREE for non-virtual functions.
	(SET_DECL_THUNKS): New.
	* decl.c (duplicate_decls): Adjust.
	* method.c (make_thunk): Adjust.

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 35819ed..fdf122f 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -2378,7 +2378,11 @@ struct GTY((variable_size)) lang_decl {
 
 /* The thunks associated with NODE, a FUNCTION_DECL.  */
 #define DECL_THUNKS(NODE) \
-  (LANG_DECL_FN_CHECK (NODE)->context)
+  (DECL_VIRTUAL_P (NODE) ? LANG_DECL_FN_CHECK (NODE)->context : NULL_TREE)
+
+/* Set DECL_THUNKS.  */
+#define SET_DECL_THUNKS(NODE,THUNKS) \
+  (LANG_DECL_FN_CHECK (NODE)->context = (THUNKS))
 
 /* Nonzero if NODE is a thunk, rather than an ordinary function.  */
 #define DECL_THUNK_P(NODE)			\
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index e78c664..f97f7b1 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -2052,7 +2052,7 @@ duplicate_decls (tree newdecl, tree olddecl, bool newdecl_is_friend)
 	  /* DECL_THUNKS is only valid for virtual functions,
 	 otherwise it is a DECL_FRIEND_CONTEXT.  */
 	  if (DECL_VIRTUAL_P (newdecl))
-	DECL_THUNKS (newdecl) = DECL_THUNKS (olddecl);
+	SET_DECL_THUNKS (newdecl, DECL_THUNKS (olddecl));
 	}
   /* Only variables have this field.  */
   else if (TREE_CODE (newdecl) == VAR_DECL
diff --git a/gcc/cp/method.c b/gcc/cp/method.c
index a42ed60..4d44c7d 100644
--- a/gcc/cp/method.c
+++ b/gcc/cp/method.c
@@ -126,7 +126,8 @@ make_thunk (tree function, bool this_adjusting,
 		  FUNCTION_DECL, NULL_TREE, TREE_TYPE (function));
   DECL_LANG_SPECIFIC (thunk) = DECL_LANG_SPECIFIC (function);
   cxx_dup_lang_specific_decl (thunk);
-  DECL_THUNKS (thunk) = NULL_TREE;
+  DECL_VIRTUAL_P (thunk) = true;
+  SET_DECL_THUNKS (thunk, NULL_TREE);
 
   DECL_CONTEXT (thunk) = DECL_CONTEXT (function);
   TREE_READONLY (thunk) = TREE_READONLY (function);
@@ -157,7 +158,7 @@ make_thunk (tree function, bool this_adjusting,
 
   /* Add it to the list of thunks associated with FUNCTION.  */
   DECL_CHAIN (thunk) = DECL_THUNKS (function);
-  DECL_THUNKS (function) = thunk;
+  SET_DECL_THUNKS (function, thunk);
 
   return thunk;
 }

Re: [Patch, Fortran, OOP] PR 54784: [4.7/4.8 Regression] wrong code in polymorphic allocation with SOURCE

[Janus Weil]

Hi Mikael,

>> here is a small patch for a wrong-code regression with polymorphic
>> allocation. The problem is that we falsely detect the allocation
>> variable to be a polymorphic array (although it is a scalar). For
>> further details see the PR, in particular comment 4.
>>
>> Regtested on x86_64-unknown-linux-gnu. Ok for trunk and 4.7?
> Hello, the fix looks incomplete.
>
>>
>> Index: gcc/fortran/trans-stmt.c
>> ===
>> --- gcc/fortran/trans-stmt.c  (revision 192004)
>> +++ gcc/fortran/trans-stmt.c  (working copy)
>> @@ -5145,7 +5145,9 @@ gfc_trans_allocate (gfc_code * code)
>> dataref = actual->next->expr->ref;
>> /* Make sure we go up through the reference chain to
>>the _data reference, where the arrayspec is found.  */
>> -   while (dataref->next && dataref->next->type != REF_ARRAY)
>> +   while (!(dataref->type == REF_COMPONENT
>> +&& strcmp (dataref->u.c.component->name, "_data") == 0)
>> +  && dataref->next)
> this stops on the first class reference, while it seems to me that it
> should stop on the last.

thanks for the review and sorry for taking so long to come back to it.

In fact I did not manage to come up with a test case where the patch
would fail, but maybe I just did not try hard enough. In any case,
please find attached a new version of the patch, which should make
sure to catch the *last* _data reference, not the first one.

Will commit to trunk after another regtest (and to 4.7 after a few
days). If you still see any problems with the patch, please let me
know.

Cheers,
Janus


pr54784_v2.diff
Description: Binary data

[lra] patch to fix GCC crash on a SPEC2006 test

[Vladimir Makarov]

The following patch fixes scheduler crash on a SPEC2006 test because LRA 
did not process CALL_INSN_FUNCTION_USAGE.


The patch was successfully bootstrapped and tested on x86/x86-64.

Committed as rev. 192362.

2012-10-11  Vladimir Makarov  

* lra-spills.c (spill_pseudos): Process CALL_INSN_FUNCTION_USAGE
too.


Index: lra-spills.c
===
--- lra-spills.c	(revision 192341)
+++ lra-spills.c	(working copy)
@@ -480,6 +480,8 @@ spill_pseudos (void)
 	if (bitmap_bit_p (&changed_insns, INSN_UID (insn)))
 	  {
 	remove_pseudos (&PATTERN (insn), insn);
+	if (CALL_P (insn))
+	  remove_pseudos (&CALL_INSN_FUNCTION_USAGE (insn), insn);
 	if (lra_dump_file != NULL)
 	  fprintf (lra_dump_file,
 		   "Changing spilled pseudos to memory in insn #%u\n",
@@ -488,6 +490,12 @@ spill_pseudos (void)
 	if (lra_reg_spill_p || targetm.different_addr_displacement_p ())
 	  lra_set_used_insn_alternative (insn, -1);
 	  }
+	else if (CALL_P (insn))
+	  /* Call insn might have not references for pseudos besides
+	 in CALL_INSN_FUNCTION_USAGE but we don't count them in
+	 insn_bitmap of corresponding lra_reg_info as they don't
+	 need reloads.  */
+	  remove_pseudos (&CALL_INSN_FUNCTION_USAGE (insn), insn);
   bitmap_and_compl_into (DF_LR_IN (bb), &spilled_pseudos);
   bitmap_and_compl_into (DF_LR_OUT (bb), &spilled_pseudos);
 }

Re: [asan] Target hook for shadow memory offset

[Diego Novillo]

On 2012-10-11 10:32 , Jakub Jelinek wrote:


2012-10-11  Jakub Jelinek  

* toplev.c (process_options): Warn and turn off -fasan
if not supported by target.
* asan.c: Include target.h.
(asan_scale, asan_offset_log_32, asan_offset_log_64,
asan_offset_log): Removed.
(build_check_stmt): Use ASAN_SHADOW_SHIFT and
targetm.asan_shadow_offset ().
(asan_instrument): Don't initialize asan_offset_log.
* asan.h (ASAN_SHADOW_SHIFT): Define.
* target.def (TARGET_ASAN_SHADOW_OFFSET): New hook.
* doc/tm.texi.in (TARGET_ASAN_SHADOW_OFFSET): Add it.
* doc/tm.texi: Regenerated.
* Makefile.in (asan.o): Depend on $(TARGET_H).
* config/i386/i386.c (ix86_asan_shadow_offset): New function.
(TARGET_ASAN_SHADOW_OFFSET): Define.


OK with HJ's suggestion for 64 bit pointer support.


Diego.

Re: [PATCH] revised fix for nanosleep check in GLIBCXX_ENABLE_LIBSTDCXX_TIME for darwin

[Jack Howarth]

On Thu, Oct 11, 2012 at 12:18:59AM +0100, Jonathan Wakely wrote:
> On 11 October 2012 00:09, Jonathan Wakely wrote:
> > On 9 October 2012 18:49, Benjamin De Kosnik wrote:
> >>
> >>> I don't like the sched_yield macro being set there because it's
> >>> detected correctly by configure anyway, but I'm not going to labour
> >>> that point any more.
> >>
> >> Indeed. Then somebody will waste hours in the future wondering why
> >> configure says no but their TU says yes.
> >>
> >> At least a comment in the configure bits admitting defeat, people.
> >
> > Committed to trunk like so.
> 
> Oops, that changelog entry missed out the PR number, so it hasn't
> updated Bugzilla, sorry.
> 
> Jack, please test and check and unpatched GCC trunk now supports
> this_thread::yield() and this_thread::sleep_for().

Jonathan,
The committed patch results in the expected this_thread::yield() and 
this_thread::sleep_for()
support. I did run into a regression at -m32/-m64 on darwin10 (but not 
darwin11/12).

WARNING: program timed out.
FAIL: 30_threads/condition_variable/54185.cc execution test

This actually isn't that surprising because the pthread support is buggy on 
darwin10. We always randomly
fail the execution test for 20_util/shared_ptr/thread/default_weaktoshared.cc 
on darwin10. I filed that
as radr://7905357, "testcase 20_util/shared_ptr/thread/default_weaktoshared.cc 
thread handling bug" back
in 2010 and it was fixed in darwin11. Either we tolerate this regression on 
darwin10 or we can
add something like...

Index: libstdc++-v3/config/os/bsd/darwin/os_defines.h
===
--- libstdc++-v3/config/os/bsd/darwin/os_defines.h  (revision 192370)
+++ libstdc++-v3/config/os/bsd/darwin/os_defines.h  (working copy)
@@ -43,8 +43,10 @@
 #define _GTHREAD_USE_RECURSIVE_MUTEX_INIT_FUNC
 
 // Configure checks for nanosleep fail on Darwin, but nanosleep and
-// sched_yield are always available, so use them.
+// sched_yield are always available, so use them 10.6 or later.
+#if __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ >= 1060
 #define _GLIBCXX_USE_NANOSLEEP 1
 #define _GLIBCXX_USE_SCHED_YIELD 1
+#endif
 
 #endif

Hopefully Mike can chime in with an opinion here. I'll test this workaround 
later today on darwin10.
   Jack

> 
> Thanks for persevering to get it working.

Make try_unroll_loop_completely to use loop bounds recorded

[Jan Hubicka]

Hi,
while looking into RTL loop peeling micopmilation I found that we now do a lot 
of
RTL loop peeling for loops of the form

int a[2];
test(int c)
{
  int i;
  for (i=0;isrc && stmt == last_stmt (exit->src))
+ if (exit && body[i] == exit->src && stmt == last_stmt (exit->src))
{
  if (dump_file && (dump_flags & TDF_DETAILS))
fprintf (dump_file, "   Exit condition will be eliminated.\n");
@@ -326,13 +326,43 @@ try_unroll_loop_completely (struct loop 
   unsigned HOST_WIDE_INT n_unroll, ninsns, max_unroll, unr_insns;
   gimple cond;
   struct loop_size size;
+  bool n_unroll_found = false;
+  HOST_WIDE_INT maxiter;
+  basic_block latch;
+  edge latch_edge;
+  location_t locus;
+  int flags;
+  bool irred_invalidated = false;
+  gimple stmt;
+  gimple_stmt_iterator gsi;
+  edge other_edge = NULL, last_exit;
+  int num = loop->num;
+  bool last_iteration_updated = false;
+
+  /* See if we proved number of iterations to be low constant.  */
+  if (host_integerp (niter, 1))
+{
+  n_unroll = tree_low_cst (niter, 1);
+  n_unroll_found = true;
+}
 
-  if (loop->inner)
+  /* See if we can improve our estimate by using recorded loop bounds.  */
+  maxiter = max_loop_iterations_int (loop);
+  if (maxiter >= 0
+  && (!n_unroll_found || (unsigned HOST_WIDE_INT)maxiter < n_unroll))
+{
+  n_unroll = maxiter;
+  n_unroll_found = true;
+}
+
+  if (!n_unroll_found)
 return false;
 
-  if (!host_integerp (niter, 1))
+  /* We unroll only inner loops, because we do not consider it profitable
+ otheriwse.  We still can cancel loopback edge of not rolling loop;
+ this is always a good idea.  */
+  if (loop->inner && n_unroll)
 return false;
-  n_unroll = tree_low_cst (niter, 1);
 
   max_unroll = PARAM_VALUE (PARAM_MAX_COMPLETELY_PEEL_TIMES);
   if (n_unroll > max_unroll)
@@ -340,6 +370,10 @@ try_unroll_loop_completely (struct loop 
 
   if (n_unroll)
 {
+  sbitmap wont_exit;
+  edge e;
+  unsigned i;
+  VEC (edge, heap) *to_remove = NULL;
   if (ul == UL_SINGLE_ITER)
return false;
 
@@ -372,14 +408,6 @@ try_unroll_loop_completely (struct loop 
fprintf (dump_file, "Not unrolling loop %d.\n", loop->num);
  return false;
}
-}
-
-  if (n_unroll)
-{
-  sbitmap wont_exit;
-  edge e;
-  unsigned i;
-  VEC (edge, heap) *to_remove = NULL;
 
   initialize_original_copy_tables ();
   wont_exit = sbitmap_alloc (n_unroll + 1);
@@ -408,24 +436,143 @@ try_unroll_loop_completely (struct loop 
   free_original_copy_tables ();
 }
 
-  cond = last_stmt (exit->src);
-  if (exit->flags & EDGE_TRUE_VALUE)
-gimple_cond_make_true (cond);
-  else
-gimple_cond_make_false (cond);
-  update_stmt (cond);
+  /* After complette unrolling we still may get rid of the conditional
+ on exit in the last copy even if we have no idea what it does.
+ This is quite common case for loops of form
+
+ int a[5];
+ for (i=0;isrc->loop_father != loop
+ || !(last_exit->flags & (EDGE_TRUE_VALUE | EDGE_FALSE_VALUE)))
+   last_exit = NULL;
+  else 
+   {
+ if (last_exit->src->flags & BB_IRREDUCIBLE_LOOP)
+   last_exit = NULL;
+   }
+}
+
+  /* If loop has only one exit edge, we can remove the conditional from
+ the last copy of the loop.  
+ TODO: We should account this update into cost model.  */
+  if (last_exit)
+{
+  cond = last_stmt (last_exit->src);
+  if (last_exit->flags & EDGE_TRUE_VALUE)
+   gimple_cond_make_true (cond);
+  else
+   gimple_cond_make_false (cond);
+  update_stmt (cond);
+  other_edge = EDGE_SUCC (last_exit->src, 0);
+  if (other_edge == last_exit)
+   other_edge = EDGE_SUCC (last_exit->src, 1);
+  last_iteration_updated = true;
+}
+
+  /* Now destroy the loop.  First try to do so by cancelling the
+ patch from exit conditional if we identified good candidate.  
+
+ TODO: We should update the loop profile for the fact that
+ the last iteration no longer executes.  */
+  if (!other_edge || !remove_path (other_edge))
+{
+  /* We did not manage to cancel the loop by removing the patch.
+ The loop latch remains reachable even if it will never be reached
+ at runtime.  We must redirect it to somewhere, so create basic
+ block containg __builtin_unreachable call for this reason.  */
+  latch = loop->latch;
+  latch_edge = loop_latch_edge (loop);
+  flags = latch_edge->flags;
+  locus = latch_edge->goto_locus;
+
+  /* Unloop destroys the latch edge.  */
+  unloop (loop, &irred_invalidated);
+  if (irred_invalidated)
+   mark_irreducible_loops ();
+
+  /* Create new basic block for the latch edge destination and wire
+it in.  */
+  stmt = gimple_build_call (builtin_decl_implicit (BUILT_IN_UNREACHABLE), 
0);
+  latch_edge = make_edge (latch, create_b

[asan] Emit GIMPLE directly, small cleanups

[Jakub Jelinek]

Hi!

Building trees, then gimplifying it, is unnecessarily expensive.
This patch changes build_check_stmt to emit GIMPLE directly, and
a couple of small cleanups here and there.  Also, I'm using a different
alias set for the shadow memory accesses, those obviously can't alias any
other accesses.

Ok for asan?

2012-10-11  Jakub Jelinek  

* Makefile.in (GTFILES): Add $(srcdir)/asan.c.
* asan.c (shadow_ptr_types): New variable.
(report_error_func): Change is_store argument to bool, don't append
newline to function name.
(PROB_VERY_UNLIKELY, PROB_ALWAYS): Define.
(build_check_stmt): Change is_store argument to bool.  Emit GIMPLE
directly instead of creating trees and gimplifying them.  Mark
the error reporting function as very unlikely.
(instrument_derefs): Change is_store argument to bool.  Use
int_size_in_bytes to compute size_in_bytes, simplify size check.
Use build_fold_addr_expr instead of build_addr.
(transform_statements): Adjust instrument_derefs caller.
Use gimple_assign_single_p as stmt test.  Don't look at MEM refs
in rhs2.
(asan_instrument): Don't push/pop gimplify context.
Initialize shadow_ptr_types if not yet initialized.
* asan.h (ASAN_SHADOW_SHIFT): Adjust comment.

--- gcc/Makefile.in.jj  2012-10-11 16:09:02.0 +0200
+++ gcc/Makefile.in 2012-10-11 16:51:59.72099 +0200
@@ -3681,6 +3681,7 @@ GTFILES = $(CPP_ID_DATA_H) $(srcdir)/inp
   $(srcdir)/lto-streamer.h \
   $(srcdir)/target-globals.h \
   $(srcdir)/ipa-inline.h \
+  $(srcdir)/asan.c \
   @all_gtfiles@
 
 # Compute the list of GT header files from the corresponding C sources,
--- gcc/asan.c.jj   2012-10-11 16:33:58.0 +0200
+++ gcc/asan.c  2012-10-11 18:20:35.265675838 +0200
@@ -79,18 +79,20 @@ along with GCC; see the file COPYING3.
  to create redzones for stack and global object and poison them.
 */
 
+static GTY(()) tree shadow_ptr_types[2];
+
 /* Construct a function tree for __asan_report_{load,store}{1,2,4,8,16}.
IS_STORE is either 1 (for a store) or 0 (for a load).
SIZE_IN_BYTES is one of 1, 2, 4, 8, 16.  */
 
 static tree
-report_error_func (int is_store, int size_in_bytes)
+report_error_func (bool is_store, int size_in_bytes)
 {
   tree fn_type;
   tree def;
   char name[100];
 
-  sprintf (name, "__asan_report_%s%d\n",
+  sprintf (name, "__asan_report_%s%d",
is_store ? "store" : "load", size_in_bytes);
   fn_type = build_function_type_list (void_type_node, ptr_type_node, 
NULL_TREE);
   def = build_fn_decl (name, fn_type);
@@ -118,6 +120,9 @@ asan_init_func (void)
 }
 
 
+#define PROB_VERY_UNLIKELY (REG_BR_PROB_BASE / 2000 - 1)
+#define PROB_ALWAYS(REG_BR_PROB_BASE)
+
 /* Instrument the memory access instruction BASE.
Insert new statements before ITER.
LOCATION is source code location.
@@ -127,21 +132,17 @@ asan_init_func (void)
 static void
 build_check_stmt (tree base,
   gimple_stmt_iterator *iter,
-  location_t location, int is_store, int size_in_bytes)
+  location_t location, bool is_store, int size_in_bytes)
 {
   gimple_stmt_iterator gsi;
   basic_block cond_bb, then_bb, join_bb;
   edge e;
-  tree cond, t, u;
-  tree base_addr;
-  tree shadow_value;
+  tree t, base_addr, shadow;
   gimple g;
-  gimple_seq seq, stmts;
-  tree shadow_type = size_in_bytes == 16 ?
-  short_integer_type_node : char_type_node;
-  tree shadow_ptr_type = build_pointer_type (shadow_type);
-  tree uintptr_type = lang_hooks.types.type_for_mode (ptr_mode,
-  /*unsignedp=*/true);
+  tree shadow_ptr_type = shadow_ptr_types[size_in_bytes == 16];
+  tree shadow_type = TREE_TYPE (shadow_ptr_type);
+  tree uintptr_type
+= build_nonstandard_integer_type (TYPE_PRECISION (TREE_TYPE (base)), 1);
 
   /* We first need to split the current basic block, and start altering
  the CFG.  This allows us to insert the statements we're about to
@@ -166,14 +167,15 @@ build_check_stmt (tree base,
 
   /* Create the bb that contains the crash block.  */
   then_bb = create_empty_bb (cond_bb);
-  make_edge (cond_bb, then_bb, EDGE_TRUE_VALUE);
+  e = make_edge (cond_bb, then_bb, EDGE_TRUE_VALUE);
+  e->probability = PROB_VERY_UNLIKELY;
   make_single_succ_edge (then_bb, join_bb, EDGE_FALLTHRU);
 
   /* Mark the pseudo-fallthrough edge from cond_bb to join_bb.  */
   e = find_edge (cond_bb, join_bb);
   e->flags = EDGE_FALSE_VALUE;
   e->count = cond_bb->count;
-  e->probability = REG_BR_PROB_BASE;
+  e->probability = PROB_ALWAYS - PROB_VERY_UNLIKELY;
 
   /* Update dominance info.  Note that bb_join's data was
  updated by split_block.  */
@@ -183,75 +185,123 @@ build_check_stmt (tree base,
   set_immediate_dominator (CDI_DOMINATORS, join_bb, cond_bb);
 }
 
-  base_addr = create_tmp_reg (uintptr_type, "__asan_base_addr");
+  gsi = gsi_last_bb (cond

Re: libbacktrace patch committed: Trace through shared libraries

[Ian Lance Taylor]

On Thu, Oct 11, 2012 at 1:44 AM, Rainer Orth
 wrote:
> Ian Lance Taylor  writes:
>
>> On Wed, Oct 10, 2012 at 7:13 AM, Rainer Orth
>>  wrote:
>>>
>>> Solaris 10 Update 10 or sufficiently recent linker patches introduced
>>> dl_iterate_phdr on S10 as a backport from Solaris 11, but unlike S11, it
>>> lives in libdl.so only.  The current dl_iterate_phdr check misses that,
>>> and given that it's only available in the most recent update, it's
>>> probably best to avoid d_i_p on Solaris 10 altogether.
>>
>> Does this patch fix the problem?
>
> Yes, works like a charm: Solaris 10/x86 results (both go and libgo) are
> back to normal.

Thanks, committed with this ChangeLog entry.

Ian


2012-10-11  Ian Lance Taylor  

* configure.ac: Do not use dl_iterate_phdr on Solaris 10.
* configure: Rebuild.

Re: [PATCH, i386]: AMD bdver3 enablement

[Uros Bizjak]

On Thu, Oct 11, 2012 at 9:19 AM, Gopalasubramanian, Ganesh
 wrote:

> The attached patch (Patch.txt) enables the next version of AMD's bulldozer 
> core.

Please handle new sseshuf type attribute in various attribute
calculations. You should at least add it to unit attribute
calculation, but please review other calculations. This attribute
replaces sselog, so probably all places that mention sselog needs to
be updated.

> A new file (bdver3.md) is also attached which describes the pipelines.

Please note recent addition - sseadd1, similar to sseadd. You should
handle this and other _1 types in a similar way. _1 types only mark
instructions that do not have operand2, but are otherwise the same as
instructions without prefix.


> 2012-10-11  Ganesh Gopalasubramanian  
>
> bdver3 Enablement
> * gcc/doc/extend.texi: Add details about bdver3.
> * gcc/doc/invoke.texi: Add details about bdver3.
> * config.gcc (i[34567]86-*-linux* | ...): Add bdver3.
> (case ${target}): Add bdver3.
> * config/i386/i386.h (TARGET_BDVER3): New definition.
> * config/i386/i386.md (define_attr "cpu"): Add bdver3.
> * config/i386/cpuid.h (bit_XSAVEOPT): New field for
> getting the xsaveopt cpuid flag.

Just say "New." here.

> * config/i386/sse.md (sseshuf): New instruction
> attribute added for identifying the shuffle instructions.

This is actually "New type attribute."

> * config/i386/i386.opt (flag_dispatch_scheduler): Add bdver3.
> * config/i386/i386-c.c (ix86_target_macros_internal): Add
> bdver3 def_and_undef
> * config/i386/driver-i386.c (host_detect_local_cpu): Let
> -march=native recognize bdver3 processors.

"Recognize bdver3 processors."

> * config/i386/i386.c (struct processor_costs btver2_cost): New
> bdver3 cost table.

"New."

> (m_BDVER3): New definition.
> (m_AMD_MULTIPLE): Includes m_BDVER3.
> (initial_ix86_tune_features): Add bdver3 tune.
> (processor_target_table): Add bdver3 entry.
> (static const char *const cpu_names): Add bdver3 entry.
> (software_prefetching_beneficial_p): Add bdver3.
> (ix86_option_override_internal): Add bdver3 instruction sets.
> (ix86_issue_rate): Add bdver3.
> (ix86_adjust_cost): Add bdver3.
> (enum target_cpu_default): Add TARGET_CPU_DEFAULT_bdver3.
> (enum processor_type): Add PROCESSOR_BDVER3.
> * config/i386/bdver3.md: New file describing bdver3 pipelines.

The patch looks OK, but please repost due to suggested attribute changes.

Thanks,
Uros.

Re: [asan] Emit GIMPLE directly, small cleanups

[Diego Novillo]

On 2012-10-11 12:38 , Jakub Jelinek wrote:


-  gimple_seq seq, stmts;
-  tree shadow_type = size_in_bytes == 16 ?
-  short_integer_type_node : char_type_node;
-  tree shadow_ptr_type = build_pointer_type (shadow_type);
-  tree uintptr_type = lang_hooks.types.type_for_mode (ptr_mode,
-  /*unsignedp=*/true);
+  tree shadow_ptr_type = shadow_ptr_types[size_in_bytes == 16];


Add '? 1 : 0' in the array index expression.


/* Build
- (base_addr >> ASAN_SHADOW_SHIFT) | targetm.asan_shadow_offset ().  */
+ (base_addr >> ASAN_SHADOW_SHIFT) + targetm.asan_shadow_offset ().  */


Hm, I wonder if this is a documentation problem or we're generating bad 
runtime code.  Wei, you tested the runtime and it was working with the 
GCC generated code, right?


In any case, we can adjust the expression later.


+  if (shadow_ptr_types[0] == NULL_TREE)
+{
+  alias_set_type set = new_alias_set ();
+  shadow_ptr_types[0]
+   = build_distinct_type_copy (unsigned_char_type_node);
+  TYPE_ALIAS_SET (shadow_ptr_types[0]) = set;
+  shadow_ptr_types[0] = build_pointer_type (shadow_ptr_types[0]);
+  shadow_ptr_types[1]
+   = build_distinct_type_copy (short_unsigned_type_node);
+  TYPE_ALIAS_SET (shadow_ptr_types[1]) = set;
+  shadow_ptr_types[1] = build_pointer_type (shadow_ptr_types[1]);
+}


Move this to an initialization function, please.


OK with those changes.


Diego.

Re: [PATCH] Improve var-tracking memory disambiguation with frame pointer (PR debug/54796)

[Alexandre Oliva]

On Oct  4, 2012, Jakub Jelinek  wrote:

> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

This is ok, except for one nit.

> 2012-10-04  Jakub Jelinek  

>   PR debug/54796
>   * rtl.h: Document jump flag on VALUE.
>   * cselib.h (cselib_set_value_sp_based,
>   cselib_sp_based_value_p): New prototypes.
>   * alias.c (find_base_term): For cselib_sp_based_value_p
>   return static_reg_base_value[STACK_POINTER_REGNUM].
>   * cselib.c (SP_BASED_VALUE_P): Define.
>   (cselib_set_value_sp_based, cselib_sp_based_value_p): New functions.
>   * var-tracking.c (add_stores): Call cselib_set_value_sp_based
>   for not yet preserved VALUEs of sp on sp assignments if
>   hard_frame_pointer_adjustment != -1.
>   (vt_initialize): When setting hard_frame_pointer_adjustment,
>   disassociate sp from its previous value and call
>   cselib_set_value_sp_based on a new VALUE created for sp.

>   * gcc.dg/guality/pr54796.c: New test.



> +/* Test whether a value is preserved.  */
> +
> +bool
> +cselib_sp_based_value_p (cselib_val *v)

The function comment needs rewriting after the cut&paste.

-- 
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist  Red Hat Brazil Compiler Engineer

Re: [asan] Emit GIMPLE directly, small cleanups

[Jakub Jelinek]

On Thu, Oct 11, 2012 at 01:14:31PM -0400, Diego Novillo wrote:
> On 2012-10-11 12:38 , Jakub Jelinek wrote:
> 
> >-  gimple_seq seq, stmts;
> >-  tree shadow_type = size_in_bytes == 16 ?
> >-  short_integer_type_node : char_type_node;
> >-  tree shadow_ptr_type = build_pointer_type (shadow_type);
> >-  tree uintptr_type = lang_hooks.types.type_for_mode (ptr_mode,
> >-  /*unsignedp=*/true);
> >+  tree shadow_ptr_type = shadow_ptr_types[size_in_bytes == 16];
> 
> Add '? 1 : 0' in the array index expression.

Ok.

> >/* Build
> >- (base_addr >> ASAN_SHADOW_SHIFT) | targetm.asan_shadow_offset ().  */
> >+ (base_addr >> ASAN_SHADOW_SHIFT) + targetm.asan_shadow_offset ().  */
> 
> Hm, I wonder if this is a documentation problem or we're generating
> bad runtime code.  Wei, you tested the runtime and it was working
> with the GCC generated code, right?

The asan web pages document |, the old tree-asan.c emitted +, I've changed
it to BIT_IOR_EXPR, but that resulted in worse assembly, and I believe at
least for the current x86_64 and i686 address ranges and shadow offset
values it actually doesn't matter.
On x86_64 stack is like 0x76e0, shifted down by 3 is still smaller
than 1L << 44 that is ored or added to it.  And the negative half of the
address space is used by the kernel, nothing is mapped into it (besides
vsyscall page) and neither | nor + of 1L << 44 to it would work well.
On i386, | and + works the same for all addresses, as 0xU >> 3
is still smaller than 1 << 29.
The reason why + generates better code on x86_64/i686 is that one can use
e.g. movzbl (%r1, %r2), %r3 instead of orq %r2, %r1; movzb (%r1), %r3.

> >+  if (shadow_ptr_types[0] == NULL_TREE)
> >+{
> >+  alias_set_type set = new_alias_set ();
> >+  shadow_ptr_types[0]
> >+= build_distinct_type_copy (unsigned_char_type_node);
> >+  TYPE_ALIAS_SET (shadow_ptr_types[0]) = set;
> >+  shadow_ptr_types[0] = build_pointer_type (shadow_ptr_types[0]);
> >+  shadow_ptr_types[1]
> >+= build_distinct_type_copy (short_unsigned_type_node);
> >+  TYPE_ALIAS_SET (shadow_ptr_types[1]) = set;
> >+  shadow_ptr_types[1] = build_pointer_type (shadow_ptr_types[1]);
> >+}
> 
> Move this to an initialization function, please.

Okay.

Jakub

Re: [asan] Emit GIMPLE directly, small cleanups

[Xinliang David Li]

On Thu, Oct 11, 2012 at 9:38 AM, Jakub Jelinek  wrote:
> Hi!
>
> Building trees, then gimplifying it, is unnecessarily expensive.
> This patch changes build_check_stmt to emit GIMPLE directly, and
> a couple of small cleanups here and there.  Also, I'm using a different
> alias set for the shadow memory accesses, those obviously can't alias any
> other accesses.
>
> Ok for asan?
>
> 2012-10-11  Jakub Jelinek  
>
> * Makefile.in (GTFILES): Add $(srcdir)/asan.c.
> * asan.c (shadow_ptr_types): New variable.
> (report_error_func): Change is_store argument to bool, don't append
> newline to function name.
> (PROB_VERY_UNLIKELY, PROB_ALWAYS): Define.
> (build_check_stmt): Change is_store argument to bool.  Emit GIMPLE
> directly instead of creating trees and gimplifying them.  Mark
> the error reporting function as very unlikely.
> (instrument_derefs): Change is_store argument to bool.  Use
> int_size_in_bytes to compute size_in_bytes, simplify size check.
> Use build_fold_addr_expr instead of build_addr.
> (transform_statements): Adjust instrument_derefs caller.
> Use gimple_assign_single_p as stmt test.  Don't look at MEM refs
> in rhs2.
> (asan_instrument): Don't push/pop gimplify context.
> Initialize shadow_ptr_types if not yet initialized.
> * asan.h (ASAN_SHADOW_SHIFT): Adjust comment.
>
> --- gcc/Makefile.in.jj  2012-10-11 16:09:02.0 +0200
> +++ gcc/Makefile.in 2012-10-11 16:51:59.72099 +0200
> @@ -3681,6 +3681,7 @@ GTFILES = $(CPP_ID_DATA_H) $(srcdir)/inp
>$(srcdir)/lto-streamer.h \
>$(srcdir)/target-globals.h \
>$(srcdir)/ipa-inline.h \
> +  $(srcdir)/asan.c \
>@all_gtfiles@
>
>  # Compute the list of GT header files from the corresponding C sources,
> --- gcc/asan.c.jj   2012-10-11 16:33:58.0 +0200
> +++ gcc/asan.c  2012-10-11 18:20:35.265675838 +0200
> @@ -79,18 +79,20 @@ along with GCC; see the file COPYING3.
>   to create redzones for stack and global object and poison them.
>  */
>
> +static GTY(()) tree shadow_ptr_types[2];
> +
>  /* Construct a function tree for __asan_report_{load,store}{1,2,4,8,16}.
> IS_STORE is either 1 (for a store) or 0 (for a load).
> SIZE_IN_BYTES is one of 1, 2, 4, 8, 16.  */
>
>  static tree
> -report_error_func (int is_store, int size_in_bytes)
> +report_error_func (bool is_store, int size_in_bytes)
>  {
>tree fn_type;
>tree def;
>char name[100];
>
> -  sprintf (name, "__asan_report_%s%d\n",
> +  sprintf (name, "__asan_report_%s%d",
> is_store ? "store" : "load", size_in_bytes);
>fn_type = build_function_type_list (void_type_node, ptr_type_node, 
> NULL_TREE);
>def = build_fn_decl (name, fn_type);
> @@ -118,6 +120,9 @@ asan_init_func (void)
>  }
>
>
> +#define PROB_VERY_UNLIKELY (REG_BR_PROB_BASE / 2000 - 1)
> +#define PROB_ALWAYS(REG_BR_PROB_BASE)
> +


Does it belong here ? -- looks like they can be generally useful for others.



>  /* Instrument the memory access instruction BASE.
> Insert new statements before ITER.
> LOCATION is source code location.
> @@ -127,21 +132,17 @@ asan_init_func (void)
>  static void
>  build_check_stmt (tree base,
>gimple_stmt_iterator *iter,
> -  location_t location, int is_store, int size_in_bytes)
> +  location_t location, bool is_store, int size_in_bytes)
>  {
>gimple_stmt_iterator gsi;
>basic_block cond_bb, then_bb, join_bb;
>edge e;
> -  tree cond, t, u;
> -  tree base_addr;
> -  tree shadow_value;
> +  tree t, base_addr, shadow;
>gimple g;
> -  gimple_seq seq, stmts;
> -  tree shadow_type = size_in_bytes == 16 ?
> -  short_integer_type_node : char_type_node;
> -  tree shadow_ptr_type = build_pointer_type (shadow_type);
> -  tree uintptr_type = lang_hooks.types.type_for_mode (ptr_mode,
> -  /*unsignedp=*/true);
> +  tree shadow_ptr_type = shadow_ptr_types[size_in_bytes == 16];
> +  tree shadow_type = TREE_TYPE (shadow_ptr_type);
> +  tree uintptr_type
> += build_nonstandard_integer_type (TYPE_PRECISION (TREE_TYPE (base)), 1);
>
>/* We first need to split the current basic block, and start altering
>   the CFG.  This allows us to insert the statements we're about to
> @@ -166,14 +167,15 @@ build_check_stmt (tree base,
>
>/* Create the bb that contains the crash block.  */
>then_bb = create_empty_bb (cond_bb);

Missing frequency update for then_bb ?


> -  make_edge (cond_bb, then_bb, EDGE_TRUE_VALUE);
> +  e = make_edge (cond_bb, then_bb, EDGE_TRUE_VALUE);
> +  e->probability = PROB_VERY_UNLIKELY;
>make_single_succ_edge (then_bb, join_bb, EDGE_FALLTHRU);
>
>/* Mark the pseudo-fallthrough edge from cond_bb to join_bb.  */
>e = find_edge (cond_bb, join_bb);
>e->flags = EDGE_FALSE_VALUE;
>e->count = cond_bb->count;
> -  e->probabili

Re: [PATCH] revised fix for nanosleep check in GLIBCXX_ENABLE_LIBSTDCXX_TIME for darwin

[Jonathan Wakely]

On 11 October 2012 17:05, Jack Howarth wrote:
>
> Jonathan,
> The committed patch results in the expected this_thread::yield() and 
> this_thread::sleep_for()
> support. I did run into a regression at -m32/-m64 on darwin10 (but not 
> darwin11/12).
>
> WARNING: program timed out.
> FAIL: 30_threads/condition_variable/54185.cc execution test

That's PR 54407, so not a regression.

> This actually isn't that surprising because the pthread support is buggy on 
> darwin10. We always randomly
> fail the execution test for 20_util/shared_ptr/thread/default_weaktoshared.cc 
> on darwin10. I filed that
> as radr://7905357, "testcase 
> 20_util/shared_ptr/thread/default_weaktoshared.cc thread handling bug" back
> in 2010 and it was fixed in darwin11. Either we tolerate this regression on 
> darwin10 or we can
> add something like...
>
> Index: libstdc++-v3/config/os/bsd/darwin/os_defines.h
> ===
> --- libstdc++-v3/config/os/bsd/darwin/os_defines.h  (revision 192370)
> +++ libstdc++-v3/config/os/bsd/darwin/os_defines.h  (working copy)
> @@ -43,8 +43,10 @@
>  #define _GTHREAD_USE_RECURSIVE_MUTEX_INIT_FUNC
>
>  // Configure checks for nanosleep fail on Darwin, but nanosleep and
> -// sched_yield are always available, so use them.
> +// sched_yield are always available, so use them 10.6 or later.
> +#if __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ >= 1060
>  #define _GLIBCXX_USE_NANOSLEEP 1
>  #define _GLIBCXX_USE_SCHED_YIELD 1
> +#endif
>
>  #endif
>
> Hopefully Mike can chime in with an opinion here. I'll test this workaround 
> later today on darwin10.

I don't think that will make any difference, because that test was
already failing anyway.

Re: [asan] Emit GIMPLE directly, small cleanups

[Wei Mi]

Hi Diego,

>> /* Build
>> - (base_addr >> ASAN_SHADOW_SHIFT) | targetm.asan_shadow_offset ().
>> */
>> + (base_addr >> ASAN_SHADOW_SHIFT) + targetm.asan_shadow_offset ().
>> */
>
>
> Hm, I wonder if this is a documentation problem or we're generating bad
> runtime code.  Wei, you tested the runtime and it was working with the GCC
> generated code, right?
>
> In any case, we can adjust the expression later.

I only tested my smallcase and it worked. Because usually the redzone
are not a very small areas (more than 4K), so I think it is possible
the smallcase works even if the shadow addr calculation is incorrect
and has small deviation.

Thanks,
Wei.

Re: [RFA] Support common C++ declarations inside GTY'd structures

[Laurynas Biveinis]

> Tested on x86_64.  OK for trunk?

Looks OK, with some very minor comments and questions below.

>  static void
> -consume_until_semi (bool immediate)
> +consume_until_eos (void)
>  {
> -  if (immediate && token () != ';')
> -require (';');
>for (;;)
>  switch (token ())
>{
>case ';':
> advance ();
> return;
> -  default:
> -   advance ();
> -   break;
> +
> +  case '{':
> +   consume_balanced ('{', '}');
> +   return;
>
>case '(':
> consume_balanced ('(', ')');
> break;
> +
>case '[':
> consume_balanced ('[', ']');
> break;
> -  case '{':
> -   consume_balanced ('{', '}');
> -   break;

case '{' moved around without any changes? Likewise for
consume_until_comma_or_eos.

> diff --git a/gcc/gengtype.c b/gcc/gengtype.c
> index 2135676..b9fbd96 100644
> --- a/gcc/gengtype.c
> +++ b/gcc/gengtype.c
> @@ -497,10 +497,10 @@ struct type scalar_char = {
>
>  /* Lists of various things.  */
>
> -pair_p typedefs;
> -type_p structures;
> -type_p param_structs;
> -pair_p variables;
> +pair_p typedefs = NULL;
> +type_p structures = NULL;
> +type_p param_structs = NULL;
> +pair_p variables = NULL;
>
>  static type_p find_param_structure (type_p t, type_p param[NUM_PARAM]);
>  static type_p adjust_field_tree_exp (type_p t, options_p opt);

This change...

> @@ -676,8 +677,7 @@ new_structure (const char *name, enum typekind kind, 
> struct fileloc *pos,
>structures = s;
>  }
>
> -  if (s->u.s.line.file != NULL
> -  || (s->u.s.lang_struct && (s->u.s.lang_struct->u.s.bitmap & bitmap)))
> +  if (s->u.s.lang_struct && (s->u.s.lang_struct->u.s.bitmap & bitmap))
>  {
>error_at_line (pos, "duplicate definition of '%s %s'",
>  isunion ? "union" : "struct", s->u.s.tag);

..and this are missing from the ChangeLog. Also, what is the
motivation behind the latter?

Have you compared the before and after gtype state files for the
current GCC sources that there are no unexpected differences?

-- 
Laurynas

Re: [Patch, Fortran, OOP] PR 54784: [4.7/4.8 Regression] wrong code in polymorphic allocation with SOURCE

[Janus Weil]

>>> here is a small patch for a wrong-code regression with polymorphic
>>> allocation. The problem is that we falsely detect the allocation
>>> variable to be a polymorphic array (although it is a scalar). For
>>> further details see the PR, in particular comment 4.
>>>
>>> Regtested on x86_64-unknown-linux-gnu. Ok for trunk and 4.7?
>> Hello, the fix looks incomplete.
>>
>>>
>>> Index: gcc/fortran/trans-stmt.c
>>> ===
>>> --- gcc/fortran/trans-stmt.c  (revision 192004)
>>> +++ gcc/fortran/trans-stmt.c  (working copy)
>>> @@ -5145,7 +5145,9 @@ gfc_trans_allocate (gfc_code * code)
>>> dataref = actual->next->expr->ref;
>>> /* Make sure we go up through the reference chain to
>>>the _data reference, where the arrayspec is found.  */
>>> -   while (dataref->next && dataref->next->type != REF_ARRAY)
>>> +   while (!(dataref->type == REF_COMPONENT
>>> +&& strcmp (dataref->u.c.component->name, "_data") == 0)
>>> +  && dataref->next)
>> this stops on the first class reference, while it seems to me that it
>> should stop on the last.
>
> thanks for the review and sorry for taking so long to come back to it.
>
> In fact I did not manage to come up with a test case where the patch
> would fail, but maybe I just did not try hard enough. In any case,
> please find attached a new version of the patch, which should make
> sure to catch the *last* _data reference, not the first one.
>
> Will commit to trunk after another regtest (and to 4.7 after a few
> days). If you still see any problems with the patch, please let me
> know.

Committed as r192374.

Cheers,
Janus

Re: [PATCH] revised fix for nanosleep check in GLIBCXX_ENABLE_LIBSTDCXX_TIME for darwin

[Jack Howarth]

On Thu, Oct 11, 2012 at 06:46:47PM +0100, Jonathan Wakely wrote:
> On 11 October 2012 17:05, Jack Howarth wrote:
> >
> > Jonathan,
> > The committed patch results in the expected this_thread::yield() and 
> > this_thread::sleep_for()
> > support. I did run into a regression at -m32/-m64 on darwin10 (but not 
> > darwin11/12).
> >
> > WARNING: program timed out.
> > FAIL: 30_threads/condition_variable/54185.cc execution test
> 
> That's PR 54407, so not a regression.

Jonathan,
   Thanks, I missed that. The pthreads support is definitely improved in 
darwin11 and later.
   Jack

> 
> > This actually isn't that surprising because the pthread support is buggy on 
> > darwin10. We always randomly
> > fail the execution test for 
> > 20_util/shared_ptr/thread/default_weaktoshared.cc on darwin10. I filed that
> > as radr://7905357, "testcase 
> > 20_util/shared_ptr/thread/default_weaktoshared.cc thread handling bug" back
> > in 2010 and it was fixed in darwin11. Either we tolerate this regression on 
> > darwin10 or we can
> > add something like...
> >
> > Index: libstdc++-v3/config/os/bsd/darwin/os_defines.h
> > ===
> > --- libstdc++-v3/config/os/bsd/darwin/os_defines.h  (revision 192370)
> > +++ libstdc++-v3/config/os/bsd/darwin/os_defines.h  (working copy)
> > @@ -43,8 +43,10 @@
> >  #define _GTHREAD_USE_RECURSIVE_MUTEX_INIT_FUNC
> >
> >  // Configure checks for nanosleep fail on Darwin, but nanosleep and
> > -// sched_yield are always available, so use them.
> > +// sched_yield are always available, so use them 10.6 or later.
> > +#if __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ >= 1060
> >  #define _GLIBCXX_USE_NANOSLEEP 1
> >  #define _GLIBCXX_USE_SCHED_YIELD 1
> > +#endif
> >
> >  #endif
> >
> > Hopefully Mike can chime in with an opinion here. I'll test this workaround 
> > later today on darwin10.
> 
> I don't think that will make any difference, because that test was
> already failing anyway.

Re: [PATCH] revised fix for nanosleep check in GLIBCXX_ENABLE_LIBSTDCXX_TIME for darwin

[Dominique Dhumieres]

Jack,

> > That's PR 54407, so not a regression.
>
> ... The pthreads support is definitely improved in darwin11 and later.

Do you confirm that 30_threads/condition_variable/54185.cc is passing on 
darwin11 and 12?
If yes, I'll test a patch to skip it on darwin10 and older.

Dominique

Re: [asan] Emit GIMPLE directly, small cleanups

[Jakub Jelinek]

On Thu, Oct 11, 2012 at 10:31:58AM -0700, Xinliang David Li wrote:
> > +#define PROB_VERY_UNLIKELY (REG_BR_PROB_BASE / 2000 - 1)
> > +#define PROB_ALWAYS(REG_BR_PROB_BASE)
> > +
> 
> 
> Does it belong here ? -- looks like they can be generally useful for others.

Perhaps, but then it would need to go on mainline first, and wait for a
merge from the trunk to asan.  So, IMHO better to put it in now this way
and if mainline gets the macros moved from profile.c to a header, asan
branch can be then adjusted.

> > @@ -166,14 +167,15 @@ build_check_stmt (tree base,
> >
> >/* Create the bb that contains the crash block.  */
> >then_bb = create_empty_bb (cond_bb);
> 
> Missing frequency update for then_bb ?

I don't see other places which create very unlikely edges doing
that (e.g. trans-mem.c, omp-low.c, ...).  Shall it be that
  then_bb->frequency = cond_bb->frequency * PROB_VERY_UNLIKELY
   / REG_BR_PROB_BASE;
and join_bb->frequency -= then_bb->frequency; ?
join_bb is clearly misnamed, as then_bb is noreturn, so there is no
joining...

> >gimple_set_location (g, location);
> > -  gimple_seq_add_stmt (&seq, g);
> > +  gsi_insert_after (&gsi, g, GSI_NEW_STMT);
> > +  base_addr = gimple_assign_lhs (g);
> >
> 
> 
> Set base_addr name here?

Why?  I think nameless SSA_NAMEs are just fine for this.

Jakub

Re: [PATCH, libstdc++] Fix missing gthr-default.h issue on libstdc++ configure

[Pavel Chupin]

How about this patch?

2012/10/11 Rainer Orth :
> Pavel Chupin  writes:
>
>> Could you try this fix?
>
> Duplicating this much info from libgcc is certainly the wrong (read:
> unmaintainable) approach.
>
> Rainer
>
> --
> -
> Rainer Orth, Center for Biotechnology, Bielefeld University



-- 
Pavel Chupin
Software Engineer
Intel Corporation


Fix-missing-gthr-aix.h.2.patch
Description: Binary data

Re: [asan] Emit GIMPLE directly, small cleanups

[Xinliang David Li]

On Thu, Oct 11, 2012 at 11:12 AM, Jakub Jelinek  wrote:
> On Thu, Oct 11, 2012 at 10:31:58AM -0700, Xinliang David Li wrote:
>> > +#define PROB_VERY_UNLIKELY (REG_BR_PROB_BASE / 2000 - 1)
>> > +#define PROB_ALWAYS(REG_BR_PROB_BASE)
>> > +
>>
>>
>> Does it belong here ? -- looks like they can be generally useful for others.
>
> Perhaps, but then it would need to go on mainline first, and wait for a
> merge from the trunk to asan.  So, IMHO better to put it in now this way
> and if mainline gets the macros moved from profile.c to a header, asan
> branch can be then adjusted.

reasonable. The existing definitions are in predict.c.
>
>> > @@ -166,14 +167,15 @@ build_check_stmt (tree base,
>> >
>> >/* Create the bb that contains the crash block.  */
>> >then_bb = create_empty_bb (cond_bb);
>>
>> Missing frequency update for then_bb ?
>
> I don't see other places which create very unlikely edges doing
> that (e.g. trans-mem.c, omp-low.c, ...).  Shall it be that
>   then_bb->frequency = cond_bb->frequency * PROB_VERY_UNLIKELY
>/ REG_BR_PROB_BASE;
> and join_bb->frequency -= then_bb->frequency; ?

That looks good to me.

> join_bb is clearly misnamed, as then_bb is noreturn, so there is no
> joining...
>
>> >gimple_set_location (g, location);
>> > -  gimple_seq_add_stmt (&seq, g);
>> > +  gsi_insert_after (&gsi, g, GSI_NEW_STMT);
>> > +  base_addr = gimple_assign_lhs (g);
>> >
>>
>>
>> Set base_addr name here?
>
> Why?  I think nameless SSA_NAMEs are just fine for this.

It makes the GIMPLE dump slightly more readable.

thanks,

David
>
> Jakub

Re: [PATCH] revised fix for nanosleep check in GLIBCXX_ENABLE_LIBSTDCXX_TIME for darwin

[Jack Howarth]

On Thu, Oct 11, 2012 at 08:11:48PM +0200, Dominique Dhumieres wrote:
> Jack,
> 
> > > That's PR 54407, so not a regression.
> >
> > ... The pthreads support is definitely improved in darwin11 and later.
> 
> Do you confirm that 30_threads/condition_variable/54185.cc is passing on 
> darwin11 and 12?
> If yes, I'll test a patch to skip it on darwin10 and older.
> 
> Dominique

Dominique,
   Yes it passes. I never have failures in libstdc++-v3 on darwin11 or darwin12 
(unless they
are new cross-platform bugs).
   Jack

[patch][IRA] Really record loop exits

[Steven Bosscher]

Hello,

IRA uses record_loop_exits() to cache the loop exit edges, but due to
a code ordering bug the edges are not actually recorded.
record_loop_exits() starts with:

  if (!current_loops)
return;

So ira.c should set current_loops before calling record_loop_exits.
With the current order, the exists are not actually recorded. Also,
ira.c should release recorded exits and loops, this releases a
considerable amount of GC memory that can be re-used in the next IRA
iteration.

It's not clear to me why IRA has to re-compute the cfgloop tree from
scratch, though, so I've added a "???" comment for that.

Bootstrapped&tested (with and without checking) on
powerpc64-unknown-linux-gnu. OK for trunk?

Ciao!
Steven

* ira.c (ira): Set current_loops to &ira_loops before recording
loop exits.  Release recorded exits and loops early.

Index: ira.c
===
--- ira.c   (revision 192377)
+++ ira.c   (working copy)
@@ -4233,8 +4233,8 @@ ira (FILE *f)
   if (flag_ira_region == IRA_REGION_ALL || flag_ira_region == IRA_REGION_MIXED)
 {
   flow_loops_find (&ira_loops);
+  current_loops = &ira_loops;
   record_loop_exits ();
-  current_loops = &ira_loops;
 }

   if (internal_flag_ira_verbose > 0 && ira_dump_file != NULL)
@@ -4277,9 +4277,14 @@ ira (FILE *f)
 info.  */
  df_analyze ();

+ /* ??? Rebuild the loop tree, but why?  Does the loop tree
+change if new insns were generated?  Can that be handled
+by updating the loop tree incrementally?  */
+ release_recorded_exits ();
+ flow_loops_free (&ira_loops);
  flow_loops_find (&ira_loops);
+ current_loops = &ira_loops;
  record_loop_exits ();
- current_loops = &ira_loops;

  setup_allocno_assignment_flags ();
  ira_initiate_assign ();
@@ -4363,6 +4368,7 @@ do_reload (void)

   if (current_loops != NULL)
 {
+  release_recorded_exits ();
   flow_loops_free (&ira_loops);
   free_dominance_info (CDI_DOMINATORS);
 }

[google] Move delete with size to its own file (issue6655052)

[Easwaran Raman]

This patch moves the two argument delete operator into its own file.
When a program provides its own definition of operator delete (void
*), but not operator delete (void *, size_t), we could end up linking
two files that define _ZdlPv resulting in a linker error. Bootstraps
with no test regressions on a x86_64 machine running linux. Ok for
google/4_7 and google/main branches?

Google ref b/6982747

2012-10-11  Easwaran Raman  

* libsupc++/Makefile.am: Add del_opsz.cc to sources.
* libsupc++/Makefile.in: Regenerated.
* libsupc++/del_opsz.cc: New file.
* libsupc++/del_op.cc(operator delete(void*,std::size_t)):
  Remove.

Index: libstdc++-v3/libsupc++/Makefile.in
===
--- libstdc++-v3/libsupc++/Makefile.in  (revision 192373)
+++ libstdc++-v3/libsupc++/Makefile.in  (working copy)
@@ -92,8 +92,8 @@ LTLIBRARIES = $(noinst_LTLIBRARIES) $(toolexeclib_
 libsupc___la_LIBADD =
 am__objects_1 = array_type_info.lo atexit_arm.lo bad_alloc.lo \
bad_cast.lo bad_typeid.lo class_type_info.lo del_op.lo \
-   del_opnt.lo del_opv.lo del_opvnt.lo dyncast.lo eh_alloc.lo \
-   eh_arm.lo eh_aux_runtime.lo eh_call.lo eh_catch.lo \
+   del_opsz.lo del_opnt.lo del_opv.lo del_opvnt.lo dyncast.lo \
+   eh_alloc.lo eh_arm.lo eh_aux_runtime.lo eh_call.lo eh_catch.lo \
eh_exception.lo eh_globals.lo eh_personality.lo eh_ptr.lo \
eh_term_handler.lo eh_terminate.lo eh_tm.lo eh_throw.lo \
eh_type.lo eh_unex_handler.lo enum_type_info.lo \
@@ -362,6 +362,7 @@ sources = \
bad_typeid.cc \
class_type_info.cc \
del_op.cc \
+   del_opsz.cc \
del_opnt.cc \
del_opv.cc \
del_opvnt.cc \
Index: libstdc++-v3/libsupc++/del_op.cc
===
--- libstdc++-v3/libsupc++/del_op.cc(revision 192373)
+++ libstdc++-v3/libsupc++/del_op.cc(working copy)
@@ -47,11 +47,3 @@ operator delete(void* ptr) _GLIBCXX_USE_NOEXCEPT
   if (ptr)
 std::free(ptr);
 }
-
-_GLIBCXX_WEAK_DEFINITION void
-operator delete(void* ptr,
-std::size_t bytes __attribute__((__unused__))) throw ()
-{
-  if (ptr)
-std::free(ptr);
-}
Index: libstdc++-v3/libsupc++/del_opsz.cc
===
--- libstdc++-v3/libsupc++/del_opsz.cc  (revision 0)
+++ libstdc++-v3/libsupc++/del_opsz.cc  (revision 0)
@@ -0,0 +1,50 @@
+// Boilerplate support routines for -*- C++ -*- dynamic memory management.
+
+// Copyright (C) 2012
+// Free Software Foundation
+//
+// 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
+// .
+
+#include 
+
+#if !_GLIBCXX_HOSTED
+// A freestanding C runtime may not provide "free" -- but there is no
+// other reasonable way to implement "operator delete".
+namespace std
+{
+_GLIBCXX_BEGIN_NAMESPACE_VERSION
+  extern "C" void free(void*);
+_GLIBCXX_END_NAMESPACE_VERSION
+} // namespace
+#else
+# include 
+#endif
+
+#include "new"
+
+_GLIBCXX_WEAK_DEFINITION void
+operator delete(void* ptr,
+std::size_t bytes __attribute__((__unused__))) throw ()
+{
+  if (ptr)
+std::free(ptr);
+}
Index: libstdc++-v3/libsupc++/Makefile.am
===
--- libstdc++-v3/libsupc++/Makefile.am  (revision 192373)
+++ libstdc++-v3/libsupc++/Makefile.am  (working copy)
@@ -53,6 +53,7 @@ sources = \
bad_typeid.cc \
class_type_info.cc \
del_op.cc \
+   del_opsz.cc \
del_opnt.cc \
del_opv.cc \
del_opvnt.cc \

--
This patch is available for review at http://codereview.appspot.com/6655052

Re: Use conditional casting with symtab_node

[Lawrence Crowl]

On 10/10/12, Xinliang David Li  wrote:
> In a different thread, I proposed the following alternative to 'try_xxx':
>
> template T* symbol::cast_to(symbol* p) {
>if (p->is())
>   return static_cast(p);
>return 0;
>  }
>
> cast:
>
> template T& symbol:as(symbol* p) {
>assert(p->is())
>return static_cast(*p);
>
>  }

My concern here was never the technical feasibility, nor the
desirability of having the facility for generic code, but the amount
of the amount of typing in non-generic contexts.  That is

  if (cgraph_node *q = p->try_function ())

versus

  if (cgraph_node *q = p->cast_to  ())

I thought the latter would generate objections.  Does anyone object
to the extra typing?

If not, I can make that change.

-- 
Lawrence Crowl

Re: Move statements upwards after reassociation

[Steven Bosscher]

On Thu, Oct 11, 2012 at 3:16 PM, Richard Biener
 wrote:
> NB, the whole reassoc code needs a re-write to avoid the excessive
> stmt modifications when it does nothing.  So I'd very much rather avoid
> adding anything to reassoc until that rewrite happened.

IMHO it's fair to Easwaran to hold up a patch for a hypothetical
rewrite. Do you have a plan for this rewrite in mind? If not, and
Easwaran's patch does something good (I haven't looked at it to tell)
then it seems to me it should be considered for including.

Ciao!
Steven

Re: Use conditional casting with symtab_node

[Xinliang David Li]

On Thu, Oct 11, 2012 at 1:23 PM, Lawrence Crowl  wrote:
> On 10/10/12, Xinliang David Li  wrote:
>> In a different thread, I proposed the following alternative to 'try_xxx':
>>
>> template T* symbol::cast_to(symbol* p) {
>>if (p->is())
>>   return static_cast(p);
>>return 0;
>>  }
>>
>> cast:
>>
>> template T& symbol:as(symbol* p) {
>>assert(p->is())
>>return static_cast(*p);
>>
>>  }
>
> My concern here was never the technical feasibility, nor the
> desirability of having the facility for generic code, but the amount
> of the amount of typing in non-generic contexts.  That is
>
>   if (cgraph_node *q = p->try_function ())
>
> versus
>
>   if (cgraph_node *q = p->cast_to  ())
>
> I thought the latter would generate objections.  Does anyone object
> to the extra typing?
>
> If not, I can make that change.

Think about a more complex class hierarchy and interface consistency.
I believe you don't want this:

tree::try_decl () { .. }
tree::try_ssa_name () { ..}
tree::try_type() {...}
tree::try_int_const () {..}
tree::try_exp () { ...}
 ..

Rather one (or two with the const_cast version).

template  T *tree::cast_to ()
{
   if (kind_ == kind_traits::value)
return static_cast (this);

 return 0;
}


thanks,

David


>
> --
> Lawrence Crowl

Re: [google] Move delete with size to its own file (issue6655052)

[Xinliang David Li]

ok.

thanks,

David

On Thu, Oct 11, 2012 at 1:21 PM, Easwaran Raman  wrote:
> This patch moves the two argument delete operator into its own file.
> When a program provides its own definition of operator delete (void
> *), but not operator delete (void *, size_t), we could end up linking
> two files that define _ZdlPv resulting in a linker error. Bootstraps
> with no test regressions on a x86_64 machine running linux. Ok for
> google/4_7 and google/main branches?
>
> Google ref b/6982747
>
> 2012-10-11  Easwaran Raman  
>
> * libsupc++/Makefile.am: Add del_opsz.cc to sources.
> * libsupc++/Makefile.in: Regenerated.
> * libsupc++/del_opsz.cc: New file.
> * libsupc++/del_op.cc(operator delete(void*,std::size_t)):
>   Remove.
>
> Index: libstdc++-v3/libsupc++/Makefile.in
> ===
> --- libstdc++-v3/libsupc++/Makefile.in  (revision 192373)
> +++ libstdc++-v3/libsupc++/Makefile.in  (working copy)
> @@ -92,8 +92,8 @@ LTLIBRARIES = $(noinst_LTLIBRARIES) $(toolexeclib_
>  libsupc___la_LIBADD =
>  am__objects_1 = array_type_info.lo atexit_arm.lo bad_alloc.lo \
> bad_cast.lo bad_typeid.lo class_type_info.lo del_op.lo \
> -   del_opnt.lo del_opv.lo del_opvnt.lo dyncast.lo eh_alloc.lo \
> -   eh_arm.lo eh_aux_runtime.lo eh_call.lo eh_catch.lo \
> +   del_opsz.lo del_opnt.lo del_opv.lo del_opvnt.lo dyncast.lo \
> +   eh_alloc.lo eh_arm.lo eh_aux_runtime.lo eh_call.lo eh_catch.lo \
> eh_exception.lo eh_globals.lo eh_personality.lo eh_ptr.lo \
> eh_term_handler.lo eh_terminate.lo eh_tm.lo eh_throw.lo \
> eh_type.lo eh_unex_handler.lo enum_type_info.lo \
> @@ -362,6 +362,7 @@ sources = \
> bad_typeid.cc \
> class_type_info.cc \
> del_op.cc \
> +   del_opsz.cc \
> del_opnt.cc \
> del_opv.cc \
> del_opvnt.cc \
> Index: libstdc++-v3/libsupc++/del_op.cc
> ===
> --- libstdc++-v3/libsupc++/del_op.cc(revision 192373)
> +++ libstdc++-v3/libsupc++/del_op.cc(working copy)
> @@ -47,11 +47,3 @@ operator delete(void* ptr) _GLIBCXX_USE_NOEXCEPT
>if (ptr)
>  std::free(ptr);
>  }
> -
> -_GLIBCXX_WEAK_DEFINITION void
> -operator delete(void* ptr,
> -std::size_t bytes __attribute__((__unused__))) throw ()
> -{
> -  if (ptr)
> -std::free(ptr);
> -}
> Index: libstdc++-v3/libsupc++/del_opsz.cc
> ===
> --- libstdc++-v3/libsupc++/del_opsz.cc  (revision 0)
> +++ libstdc++-v3/libsupc++/del_opsz.cc  (revision 0)
> @@ -0,0 +1,50 @@
> +// Boilerplate support routines for -*- C++ -*- dynamic memory management.
> +
> +// Copyright (C) 2012
> +// Free Software Foundation
> +//
> +// 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
> +// .
> +
> +#include 
> +
> +#if !_GLIBCXX_HOSTED
> +// A freestanding C runtime may not provide "free" -- but there is no
> +// other reasonable way to implement "operator delete".
> +namespace std
> +{
> +_GLIBCXX_BEGIN_NAMESPACE_VERSION
> +  extern "C" void free(void*);
> +_GLIBCXX_END_NAMESPACE_VERSION
> +} // namespace
> +#else
> +# include 
> +#endif
> +
> +#include "new"
> +
> +_GLIBCXX_WEAK_DEFINITION void
> +operator delete(void* ptr,
> +std::size_t bytes __attribute__((__unused__))) throw ()
> +{
> +  if (ptr)
> +std::free(ptr);
> +}
> Index: libstdc++-v3/libsupc++/Makefile.am
> ===
> --- libstdc++-v3/libsupc++/Makefile.am  (revision 192373)
> +++ libstdc++-v3/libsupc++/Makefile.am  (working copy)
> @@ -53,6 +53,7 @@ sources = \
> bad_typeid.cc \
> class_type_info.cc \
> del_op.cc \
> +   del_opsz.cc \
> del_opnt.cc \
> del_opv.cc \
> del_opvnt.cc \
>
> --
> This patch is available for review at http://codereview.appspot.com/6655052

[PATCH, alpha]: Trivial alpha.md macroizations, part 2

[Uros Bizjak]

Hello!

2012-10-11  Uros Bizjak  

* config/alpha/alpha.md (IMODE): New mode iterator.
(I124MODE): Ditto.
(I248MODE): Ditto.
(modesuffix): Handle QI and HI modes.
(zero_extendqi2): Macroize insn from zero_extendqi{hi,si,di}2
using I248MODE mode iterator.
(zero_extendhi2): Macroize insn from zero_extendhi{si,di}2
using I48MODE mode iterator.
(andnot3): Macroize insn from andnot{si,di}3 using
I48MODE mode iterator.
(insl_const): Macroize insn from ins{b,w,l}l_const
using I248MODE mode iterator.
(insl): Macroize insn from ins{b,w,l}l
using I248MODE mode iterator.
(*movcc_internal): Macroize insn from
*mov{qi,hi,si,di}cc_internal using IMODE mode iterator.
(*movcc_lbc): Macroize insn from
*mov{qi,hi,si,di}cc_lbc using IMODE mode iterator.
(*movcc_lbs): Macroize insn from
*mov{qi,hi,si,di}cc_lbs using IMODE mode iterator.
(movcc): Macroize insn from mov{si,di}cc_lbs
using I48MODE mode iterator.

Tested on alphaev68-linux-gnu, committed to mainline SVN.

Uros.
Index: config/alpha/alpha.md
===
--- config/alpha/alpha.md   (revision 192370)
+++ config/alpha/alpha.md   (working copy)
@@ -90,10 +90,13 @@
 (define_mode_attr reloadmode [(QI "qi") (HI "hi") (CQI "hi")])
 
 ;; Other mode iterators
+(define_mode_iterator IMODE [QI HI SI DI])
 (define_mode_iterator I12MODE [QI HI])
+(define_mode_iterator I124MODE [QI HI SI])
+(define_mode_iterator I248MODE [HI SI DI])
 (define_mode_iterator I48MODE [SI DI])
 (define_mode_attr DWI [(SI "DI") (DI "TI")])
-(define_mode_attr modesuffix [(SI "l") (DI "q")])
+(define_mode_attr modesuffix [(QI "b") (HI "w") (SI "l") (DI "q")])
 
 ;; Where necessary, the suffixes _le and _be are used to distinguish between
 ;; little-endian and big-endian patterns.
@@ -1026,9 +1029,9 @@
   operands[4] = GEN_INT (mask2);
 })
 
-(define_insn "zero_extendqihi2"
-  [(set (match_operand:HI 0 "register_operand" "=r,r")
-   (zero_extend:HI
+(define_insn "zero_extendqi2"
+  [(set (match_operand:I248MODE 0 "register_operand" "=r,r")
+   (zero_extend:I248MODE
  (match_operand:QI 1 "reg_or_bwx_memory_operand" "r,m")))]
   ""
   "@
@@ -1037,31 +1040,9 @@
   [(set_attr "type" "ilog,ild")
(set_attr "isa" "*,bwx")])
 
-(define_insn "zero_extendqisi2"
-  [(set (match_operand:SI 0 "register_operand" "=r,r")
-   (zero_extend:SI
- (match_operand:QI 1 "reg_or_bwx_memory_operand" "r,m")))]
-  ""
-  "@
-   and %1,0xff,%0
-   ldbu %0,%1"
-  [(set_attr "type" "ilog,ild")
-   (set_attr "isa" "*,bwx")])
-
-(define_insn "zero_extendqidi2"
-  [(set (match_operand:DI 0 "register_operand" "=r,r")
-   (zero_extend:DI
- (match_operand:QI 1 "reg_or_bwx_memory_operand" "r,m")))]
-  ""
-  "@
-   and %1,0xff,%0
-   ldbu %0,%1"
-  [(set_attr "type" "ilog,ild")
-   (set_attr "isa" "*,bwx")])
-
-(define_insn "zero_extendhisi2"
-  [(set (match_operand:SI 0 "register_operand" "=r,r")
-   (zero_extend:SI
+(define_insn "zero_extendhi2"
+  [(set (match_operand:I48MODE 0 "register_operand" "=r,r")
+   (zero_extend:I48MODE
  (match_operand:HI 1 "reg_or_bwx_memory_operand" "r,m")))]
   ""
   "@
@@ -1070,17 +1051,6 @@
   [(set_attr "type" "shift,ild")
(set_attr "isa" "*,bwx")])
 
-(define_insn "zero_extendhidi2"
-  [(set (match_operand:DI 0 "register_operand" "=r,r")
-   (zero_extend:DI
- (match_operand:HI 1 "reg_or_bwx_memory_operand" "r,m")))]
-  ""
-  "@
-   zapnot %1,3,%0
-   ldwu %0,%1"
-  [(set_attr "type" "shift,ild")
-   (set_attr "isa" "*,bwx")])
-
 (define_insn "zero_extendsidi2"
   [(set (match_operand:DI 0 "register_operand" "=r")
(zero_extend:DI (match_operand:SI 1 "register_operand" "r")))]
@@ -1088,22 +1058,15 @@
   "zapnot %1,15,%0"
   [(set_attr "type" "shift")])
 
-(define_insn "*andnotsi3"
-  [(set (match_operand:SI 0 "register_operand" "=r")
-   (and:SI (not:SI (match_operand:SI 1 "reg_or_8bit_operand" "rI"))
-   (match_operand:SI 2 "reg_or_0_operand" "rJ")))]
+(define_insn "andnot3"
+  [(set (match_operand:I48MODE 0 "register_operand" "=r")
+   (and:I48MODE
+(not:I48MODE (match_operand:I48MODE 1 "reg_or_8bit_operand" "rI"))
+(match_operand:I48MODE 2 "reg_or_0_operand" "rJ")))]
   ""
   "bic %r2,%1,%0"
   [(set_attr "type" "ilog")])
 
-(define_insn "andnotdi3"
-  [(set (match_operand:DI 0 "register_operand" "=r")
-   (and:DI (not:DI (match_operand:DI 1 "reg_or_8bit_operand" "rI"))
-   (match_operand:DI 2 "reg_or_0_operand" "rJ")))]
-  ""
-  "bic %r2,%1,%0"
-  [(set_attr "type" "ilog")])
-
 (define_insn "*iorsi_internal"
   [(set (match_operand:SI 0 "register_operand" "=r,r")
(ior:SI (match_operand:SI 1 "reg_or_0_operand" "%rJ,rJ")
@@ -1140,9 +1103,9 @@
 
 (define_insn "*iornot3"
   [(set (match_operand:I48MODE 0 "register_operand" "=r")
-  

PR/54893: allow volatiles inside relaxed transactions

[Aldy Hernandez]

Apparently we were a bit too aggressive on disallowing volatiles inside 
transactions.  Torvald seems to agree that volatiles should be allowed 
inside relaxed transactions, since they will go into serial irrevocable 
mode anyhow.


The following patch fixes the PR.

I did not include a test that fails on a volatile in an atomic 
transaction because there is already one in the testsuite.


OK pending tests?

PR middle-end/54893
* trans-mem.c (diagnose_tm_1_op): Allow volatiles inside relaxed
transactions.

diff --git a/gcc/testsuite/c-c++-common/tm/pr54893.c 
b/gcc/testsuite/c-c++-common/tm/pr54893.c
new file mode 100644
index 000..df26f25
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/tm/pr54893.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options "-fgnu-tm" } */
+
+/* Test that volatiles are allowed inside relaxed transactions.  */
+
+volatile int test_var = 0;
+
+int main()
+{
+  __transaction_relaxed {
+test_var++;
+  }
+}
diff --git a/gcc/trans-mem.c b/gcc/trans-mem.c
index ef384ac..dc08bc6 100644
--- a/gcc/trans-mem.c
+++ b/gcc/trans-mem.c
@@ -561,7 +561,7 @@ diagnose_tm_1_op (tree *tp, int *walk_subtrees 
ATTRIBUTE_UNUSED,
   if ((code == VAR_DECL
|| code == RESULT_DECL
|| code == PARM_DECL)
-  && d->block_flags & (DIAG_TM_SAFE | DIAG_TM_RELAXED)
+  && d->block_flags & DIAG_TM_SAFE
   && TREE_THIS_VOLATILE (TREE_TYPE (*tp))
   && !d->saw_volatile)
 {

Re: [Patch, Fortran] Fix OPTIONAL, esp. with polymorphism

[Janus Weil]

Hi Tobias,

> gfortran supports OPTIONAL since quite some time - also some more
> complicated cases involving ELEMENTAL or the new F2008 addition, but as
> testing showed, the support is still incomplete; especially with polymorphic
> arguments there were several bugs.
>
> Besides a simple absent argument, passing an absent argument on also has to
> be supported. Fortran 2008 in addition added that a deallocated allocatable
> and an unassociated pointer also counts as absent - if (and only if) it is
> passed to a nonallocatable, nonpointer optional dummy.
>
> As complication comes on top of it: The CLASS container; especially for
> class->type, type->class, class->(parent)class and when combined with
> arrays, coarrays or assumed-rank arguments. There, one needs to ensure that
> one passes the NULL correctly and that a NULL pointers doesn't get
> dereferenced.
>
> On the way, I fixed some other issues like passing polymorphic coarray
> scalars (i.e. changing a class container with array descriptor to a class
> container without array descriptor).
>
> There are still issues with ELEMENTAL and with creating an array descriptor
> for an (absent) optional array which has no array descriptor. In addition,
> for CLASS->TYPE of assumed-rank arrays, the "packaging" (creating a
> contiguous array) support is also still lacking. See the 146 commented FIXME
> lines in the patch. However, I think the patch is large enough and
> sufficiently complete to be committed without the remaining parts.
>
> Build and regtested on x86-64-linux.
> OK for the trunk?

thanks for this patch. It looks mostly ok to me. Since Dominique has
already inspected the test cases, I only looked at the patch itself. A
few minor comments:


@@ -231,12 +231,16 @@ class_array_data_assign (stmtblock_t *block,
tree lhs_desc, tree rhs_desc,

 /* Takes a derived type expression and returns the address of a temporary
class object of the 'declared' type.  If vptr is not NULL, this is
-   used for the temporary class object.  */
+   used for the temporary class object.
+   alloc_ptr is false when the dummy is neither allocatable
+   nor a pointer; that's only relevant for the optional handling.  */
 void
 gfc_conv_derived_to_class (gfc_se *parmse, gfc_expr *e,
-  gfc_typespec class_ts, tree vptr)
+  gfc_typespec class_ts, tree vptr, bool optional,
+  bool optional_alloc_ptr)

In the comment, 'alloc_ptr' should be 'optional_alloc_ptr'.



+
+static void
+class_scalar_coarray_to_class (gfc_se *parmse, gfc_expr *e,
+  gfc_typespec class_ts, bool optional)
+{

How about a small comment preceding this function, to shortly describe
its functionality and arguments? And then inside ...


+  for (ref = e->ref; ref; ref = ref->next)
+{
+  if (ref->type == REF_COMPONENT
+   && ref->u.c.component->ts.type == BT_CLASS)
+   class_ref = ref;
+
+  if (ref->next == NULL)
+   break;
+}

... I guess the last if statement is not needed, since this condition
is already checked by the for loop.



@@ -323,19 +451,26 @@ gfc_conv_derived_to_class (gfc_se *parmse, gfc_expr *e,
type.
OOP-TODO: This could be improved by adding code that branched on
the dynamic type being the same as the declared type. In this case
-   the original class expression can be passed directly.  */
+   the original class expression can be passed directly.
+   alloc_ptr is false when the dummy is neither allocatable
+   nor a pointer; that's relevant for the optional handling.  */
 void
-gfc_conv_class_to_class (gfc_se *parmse, gfc_expr *e,
-gfc_typespec class_ts, bool elemental)
+gfc_conv_class_to_class (gfc_se *parmse, gfc_expr *e, gfc_typespec class_ts,
+bool elemental, bool copyback, bool optional,
+bool optional_alloc_ptr)

Again: 'alloc_ptr' -> 'optional_alloc_ptr' in the comment. And how
about a short comment on the 'copyback' argument?



That's pretty much all I found. Ok for trunk with the above ...

Cheers,
Janus

Re: PR/54893: allow volatiles inside relaxed transactions

[Richard Henderson]

On 10/11/2012 01:56 PM, Aldy Hernandez wrote:
>   PR middle-end/54893
>   * trans-mem.c (diagnose_tm_1_op): Allow volatiles inside relaxed
>   transactions.

Ok.

r~

Re: [Patch, Fortran] PR 40453: Enhanced (recursive) argument checking

[Janus Weil]

ping!


2012/10/7 Janus Weil :
> Hi all,
>
> here is a rather straightforward patch, which does 'recursive'
> checking of dummy procedures.
>
> Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
>
> Cheers,
> Janus
>
>
> 2012-10-06  Janus Weil  
>
> PR fortran/40453
> * interface.c (check_dummy_characteristics): Recursively check dummy
> procedures.
>
> 2012-10-06  Janus Weil  
>
> PR fortran/40453
> * gfortran.dg/dummy_procedure_9.f90: New.

[PATCH] Reduce conservativeness in REE using machine model (issue6631066)

[Teresa Johnson]

Revised patch to address conservative behavior in redundant extend
elimination that was resulting in redundant extends not being
removed. Now uses a new target hook machine_mode_from_attr_mode
which is currently enabled only for i386.

Bootstrapped and tested on x86_64-unknown-linux-gnu. Is this ok for trunk?

Thanks,
Teresa

2012-10-11  Teresa Johnson  

* doc/tm.texi: Document TARGET_MACHINE_MODE_FROM_ATTR_MODE.
* doc/tm.texi.in: Regenerated.
* targhooks.c (default_machine_mode_from_attr_mode): New function.
* targhooks.h (default_machine_mode_from_attr_mode): Declare.
* target.def (machine_mode_from_attr_mode): New target hook.
* ree.c (get_mode): New function.
(add_removable_extension): Use get_mode to obtain the
machine mode for comparison with other extends.
* config/i386/i386.c (ix86_machine_mode_from_attr_mode): New function.

Index: doc/tm.texi
===
--- doc/tm.texi (revision 192265)
+++ doc/tm.texi (working copy)
@@ -10468,6 +10468,10 @@ In order to enforce the representation of @code{mo
 @code{mode}.
 @end deftypefn
 
+@deftypefn {Target Hook} {enum machine_mode} 
TARGET_MACHINE_MODE_FROM_ATTR_MODE (rtx @var{insn})
+If @var{insn} has an attr_mode that is equivalent to a @code{machine_mode},  
return the corresponding @code{machine_mode}, otherwise return  
@code{MAX_MACHINE_MODE}.
+@end deftypefn
+
 @defmac STORE_FLAG_VALUE
 A C expression describing the value returned by a comparison operator
 with an integral mode and stored by a store-flag instruction
Index: doc/tm.texi.in
===
--- doc/tm.texi.in  (revision 192265)
+++ doc/tm.texi.in  (working copy)
@@ -10326,6 +10326,8 @@ In order to enforce the representation of @code{mo
 @code{mode}.
 @end deftypefn
 
+@hook TARGET_MACHINE_MODE_FROM_ATTR_MODE
+
 @defmac STORE_FLAG_VALUE
 A C expression describing the value returned by a comparison operator
 with an integral mode and stored by a store-flag instruction
Index: targhooks.c
===
--- targhooks.c (revision 192265)
+++ targhooks.c (working copy)
@@ -250,6 +250,14 @@ default_mode_rep_extended (enum machine_mode mode
   return UNKNOWN;
 }
 
+/* The default implementation of TARGET_MACHINE_MODE_FROM_ATTR_MODE.  */
+
+enum machine_mode
+default_machine_mode_from_attr_mode (rtx insn ATTRIBUTE_UNUSED)
+{
+  return MAX_MACHINE_MODE;
+}
+
 /* Generic hook that takes a CUMULATIVE_ARGS pointer and returns true.  */
 
 bool
Index: targhooks.h
===
--- targhooks.h (revision 192265)
+++ targhooks.h (working copy)
@@ -47,6 +47,7 @@ extern unsigned HOST_WIDE_INT default_shift_trunca
   (enum machine_mode);
 extern unsigned int default_min_divisions_for_recip_mul (enum machine_mode);
 extern int default_mode_rep_extended (enum machine_mode, enum machine_mode);
+enum machine_mode default_machine_mode_from_attr_mode (rtx insn);
 
 extern tree default_stack_protect_guard (void);
 extern tree default_external_stack_protect_fail (void);
Index: target.def
===
--- target.def  (revision 192265)
+++ target.def  (working copy)
@@ -1576,6 +1576,17 @@ DEFHOOK
  int, (enum machine_mode mode, enum machine_mode rep_mode),
  default_mode_rep_extended)
 
+/* If the machine description for an rtl INSN defines the
+   attr_mode, and that mode is equivalent to a machine_mode, return
+   the corresponding machine_mode. Return MAX_MACHINE_MODE otherwise.  */
+DEFHOOK
+(machine_mode_from_attr_mode,
+ "If @var{insn} has an attr_mode that is equivalent to a @code{machine_mode},\
+  return the corresponding @code{machine_mode}, otherwise return\
+  @code{MAX_MACHINE_MODE}.",
+ enum machine_mode, (rtx insn),
+ default_machine_mode_from_attr_mode)
+
 /* True if MODE is valid for a pointer in __attribute__((mode("MODE"))).  */
 DEFHOOK
 (valid_pointer_mode,
Index: ree.c
===
--- ree.c   (revision 192265)
+++ ree.c   (working copy)
@@ -756,6 +756,20 @@ combine_reaching_defs (ext_cand *cand, const_rtx s
   return false;
 }
 
+/* Given an INSN, obtain the attr_mode specified by the machine
+   description, and map it to the corresponding machine_mode. If the
+   attr_mode isn't specified, return the machine mode for DEST.  */
+
+static enum machine_mode
+get_mode (rtx insn, rtx dest)
+{
+  enum machine_mode mode;
+  mode = targetm.machine_mode_from_attr_mode(insn);
+  if (mode == MAX_MACHINE_MODE)
+mode = GET_MODE (dest);
+  return mode;
+}
+
 /* Add an extension pattern that could be eliminated.  */
 
 static void
@@ -775,7 +789,7 @@ add_removable_extension (const_rtx expr, rtx insn,
   src = SET_SRC (expr);
   code = GET_CODE (src);
   dest = SET_DEST (expr);
-  mode = GET_MODE (de

[Patch, Fortran, OOP] PR 54881: [4.8 Regression] [OOP] ICE in fold_convert_loc, at fold-const.c:2016

[Janus Weil]

Hi all,

here is an OOP patch for the above PR, which has two disconnected parts:

1) It fixes a problem with ASSOCIATED, when it is fed a CLASS-valued
function as argument (i.e. the ICE in the bug title). This is the
trans-intrinsic part of the patch. Instead of adding the _data
component to the expr first and translating then, we now translate
first and then add the _data component.

2) It fixes an error with SELECT TYPE (which is a 4.8 regression), by
respecting the POINTER argument of the selector when building the
temporaries for the select type branches. This is the match.c part of
the patch, which looks much more complicated than it is, because I
merged two functions into one, which do essentially the same. I think
they were at some point split up by Paul, but I see no advantage this,
to be honest.

Regtested on x86_64-unknown-linux-gnu. Ok for trunk?

Cheers,
Janus


2012-10-11  Janus Weil  

PR fortran/54881
* match.c (select_derived_set_tmp,select_class_set_tmp): Removed and
unified into ...
(select_type_set_tmp): ... this one. Set POINTER argument according to
selector.
* trans-intrinsic.c (gfc_conv_associated): Use 'gfc_class_data_get'
instead of 'gfc_add_data_component'.

2012-10-11  Janus Weil  

PR fortran/54881
* gfortran.dg/associated_6.f90: New.
* gfortran.dg/select_type_30.f03: New.


pr54881.diff
Description: Binary data


associated_6.f90
Description: Binary data


select_type_30.f03
Description: Binary data

Re: [PATCH] Reduce conservativeness in REE using machine model (issue6631066)

[Steven Bosscher]

On Thu, Oct 11, 2012 at 11:44 PM, Teresa Johnson wrote:
> +  mode = targetm.machine_mode_from_attr_mode(insn);

Nit: space between "..._mode" and "(".

A test case would also be Nice To Have.

Looks OK to me otherwise, but I can't approve it.

Ciao!
Steven

Re: RFC: LRA for x86/x86-64 [0/9]

[Peter Bergner]

On Tue, 2012-10-02 at 10:57 -0400, Vladimir Makarov wrote:
> Chaitin-Briggs literature does not discuss the termination, just saying 
> that live-ranges shortening will result to assigning hard regs to all 
> necessary pseudos which is not clearly guaranteed. There is the same 
> problem in LRA.  So LRA checks that too many passes are done or to many 
> reloads for one insn are made and abort LRA.  Porting LRA is mostly 
> fixing such aborts.

IIRC, talking with the guys from Rice, they had a limit on the number of
color/spill iterations (20) before aborting, since anything more than
that would be due to a bug.  I believe the largest number of iterations
I ever saw in my allocator was about 6 iterations of color/spill.  I hit
a few cases that iterated forever, but those were always due to bugs in
my code or special hairy details I hadn't handled.  You're correct that
the hairy details are never discussed in papers. :)



> Another thing omitted by literature is inheritance which is very 
> important for performance.  Although it could be considered as a special 
> case of live-range splitting.  There are also a lot of small important 
> details (e.g. what to do in case of displacement constraints,

To handle displacement constraints, instead of spilling to stack slots,
we spilled to spill pseudos which look like normal register pseudos.
We would then color them just like normal pseudos, but the colors
represent stack slots and not registers.  If "k" becomes too big, it
means you surpassed the maximum displacement, and you'll have to spill
the spill pseudo.  For small displacement cpus, coloring the spill pseudos
does a good job reusing stack slots which reduces the largest displacement
you'll see.  For cpus with no displacement issues, you could just give
each spill pseudo a different color which would mean you wouldn't have
to compute a interference graph of the spill pseudos and all the work
and space that goes into building that.

Note, with spill pseudos, you can perform dead code elimination, coalescing
and other optimizations on them just like normal pseudos to reduce the
amount of spill code generated.

Peter

[SH] PR 51244 - Improve T bit store and cbranch

[Oleg Endo]

Hello,

This one further improves T bit stores and conditional branches on SH
for cases like described in comment #53 in the PR.
Tested on rev 192200 with
make -k check RUNTESTFLAGS="--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"

and no new failures.

Cheers,
Oleg

gcc/ChangeLog:

PR target/51244
* config/sh/sh.md (negsi_cond, negdi_cond, stack_protect_test): 
Remove get_t_reg_rtx when invoking gen_branch_true or 
gen_branch_false.
(*zero_extendsi2_compact): Convert to insn_and_split.  
Convert zero extensions of T bit stores to reg moves in 
splitter.  Remove obsolete unnamed peephole2 that caught zero 
extensions after negc T bit stores.
(*branch_true_eq, *branch_false_ne): Delete.
(branch_true, branch_false): Convert insn to expander.  Move 
actual insn logic to...
(*cbranch_t): ...this new insn_and_split.  Try to find 
preceding redundant T bit stores and tests and combine them 
with the conditional branch if possible in the splitter.
(movrt_xor, *movt_movrt): New insn_and_split.
* config/sh/predicates.md (cbranch_treg_value): New predicate.
* config/sh/sh-protos.h (sh_eval_treg_value): Forward declare...
* config/sh/sh.c (sh_eval_treg_value): ...this new function.
(expand_cbranchsi4, expand_cbranchdi4): Remove get_t_reg_rtx 
when invoking gen_branch_true or gen_branch_false.

testsuite/ChangeLog:

PR target/51244
* gcc.target/sh/pr51244-13.c: New.
* gcc.target/sh/pr51244-14.c: New.
* gcc.target/sh/pr51244-15.c: New.
* gcc.target/sh/pr51244-16.c: New.
Index: gcc/config/sh/sh.c
===
--- gcc/config/sh/sh.c	(revision 192200)
+++ gcc/config/sh/sh.c	(working copy)
@@ -2059,7 +2059,7 @@
 void
 expand_cbranchsi4 (rtx *operands, enum rtx_code comparison, int probability)
 {
-  rtx (*branch_expander) (rtx, rtx) = gen_branch_true;
+  rtx (*branch_expander) (rtx) = gen_branch_true;
   comparison = prepare_cbranch_operands (operands, SImode, comparison);
   switch (comparison)
 {
@@ -2071,7 +2071,7 @@
   emit_insn (gen_rtx_SET (VOIDmode, get_t_reg_rtx (),
   gen_rtx_fmt_ee (comparison, SImode,
   operands[1], operands[2])));
-  rtx jump = emit_jump_insn (branch_expander (operands[3], get_t_reg_rtx ()));
+  rtx jump = emit_jump_insn (branch_expander (operands[3]));
   if (probability >= 0)
 add_reg_note (jump, REG_BR_PROB, GEN_INT (probability));
 }
@@ -2123,7 +2123,7 @@
   if (TARGET_CMPEQDI_T)
 	{
 	  emit_insn (gen_cmpeqdi_t (operands[1], operands[2]));
-	  emit_jump_insn (gen_branch_true (operands[3], get_t_reg_rtx ()));
+	  emit_jump_insn (gen_branch_true (operands[3]));
 	  return true;
 	}
   msw_skip = NE;
@@ -2150,7 +2150,7 @@
   if (TARGET_CMPEQDI_T)
 	{
 	  emit_insn (gen_cmpeqdi_t (operands[1], operands[2]));
-	  emit_jump_insn (gen_branch_false (operands[3], get_t_reg_rtx ()));
+	  emit_jump_insn (gen_branch_false (operands[3]));
 	  return true;
 	}
   msw_taken = NE;
@@ -2281,6 +2281,43 @@
   return true;
 }
 
+/* Given an operand, return 1 if the evaluated operand plugged into an
+   if_then_else will result in a branch_true, 0 if branch_false, or
+   -1 if neither nor applies.  The truth table goes like this:
+
+   op   | cmpval |   code  | result
+   -++-+
+  T (0) |   0|  EQ (1) |  0 = 0 ^ (0 == 1)
+  T (0) |   1|  EQ (1) |  1 = 0 ^ (1 == 1)
+  T (0) |   0|  NE (0) |  1 = 0 ^ (0 == 0)
+  T (0) |   1|  NE (0) |  0 = 0 ^ (1 == 0)
+ !T (1) |   0|  EQ (1) |  1 = 1 ^ (0 == 1)
+ !T (1) |   1|  EQ (1) |  0 = 1 ^ (1 == 1)
+ !T (1) |   0|  NE (0) |  0 = 1 ^ (0 == 0)
+ !T (1) |   1|  NE (0) |  1 = 1 ^ (1 == 0)  */
+int
+sh_eval_treg_value (rtx op)
+{
+  enum rtx_code code = GET_CODE (op);
+  if ((code != EQ && code != NE) || !CONST_INT_P (XEXP (op, 1)))
+return -1;
+
+  int cmpop = code == EQ ? 1 : 0;
+  int cmpval = INTVAL (XEXP (op, 1));
+  if (cmpval != 0 && cmpval != 1)
+return -1;
+
+  int t;
+  if (t_reg_operand (XEXP (op, 0), GET_MODE (XEXP (op, 0
+t = 0;
+  else if (negt_reg_operand (XEXP (op, 0), GET_MODE (XEXP (op, 0
+t = 1;
+  else
+return -1;
+  
+  return t ^ (cmpval == cmpop);
+}
+
 /* Emit INSN, possibly in a PARALLEL with an USE of fpscr for SH4.  */
 
 static void
@@ -2485,9 +2522,9 @@
 sh_emit_set_t_insn (gen_ieee_ccmpeqsf_t (op0, op1), mode);
 
   if (branch_code == code)
-emit_jump_insn (gen_branch_true (operands[3], get_t_reg_rtx ()));
+emit_jump_insn (gen_branch_true (operands[3]));
   else
-emit_jump_insn (gen_branch_false (operands[3], get_t_reg_rtx ()));
+emit_jump_insn (gen_branch_false (operands[3]));
 }
 
 void
@@ -2521,7 +2558,7 @@
  

Re: Move statements upwards after reassociation

[Ian Lance Taylor]

On Thu, Oct 11, 2012 at 1:25 PM, Steven Bosscher  wrote:
> On Thu, Oct 11, 2012 at 3:16 PM, Richard Biener
>  wrote:
>> NB, the whole reassoc code needs a re-write to avoid the excessive
>> stmt modifications when it does nothing.  So I'd very much rather avoid
>> adding anything to reassoc until that rewrite happened.
>
> IMHO it's fair to Easwaran to hold up a patch for a hypothetical
> rewrite. Do you have a plan for this rewrite in mind? If not, and
> Easwaran's patch does something good (I haven't looked at it to tell)
> then it seems to me it should be considered for including.

Did you mean "fair" or "unfair"?

Ian

Re: Move statements upwards after reassociation

[Steven Bosscher]

On Fri, Oct 12, 2012 at 12:00 AM, Ian Lance Taylor wrote:
> On Thu, Oct 11, 2012 at 1:25 PM, Steven Bosscher wrote:
>> On Thu, Oct 11, 2012 at 3:16 PM, Richard Biener wrote:
>>> NB, the whole reassoc code needs a re-write to avoid the excessive
>>> stmt modifications when it does nothing.  So I'd very much rather avoid
>>> adding anything to reassoc until that rewrite happened.
>>
>> IMHO it's fair to Easwaran to hold up a patch for a hypothetical
>> rewrite. Do you have a plan for this rewrite in mind? If not, and
>> Easwaran's patch does something good (I haven't looked at it to tell)
>> then it seems to me it should be considered for including.
>
> Did you mean "fair" or "unfair"?

Oops!

I meant "not fair".

Ciao!
Steven

[C++] PR53055

[Marc Glisse]

Hello,

this is an old patch that Paolo dug out of bugzilla and where I only 
changed the error message. It fixes an ICE on invalid code.


Note that the code uses error() like the nearby code so the caret appears 
on the RHS while the message is about the LHS. Paolo offered to look into 
it as a follow-up (the LHS doesn't have a location attached to it, so it 
isn't just a matter of using error_at).


bootstrap+testsuite ok.

2012-10-12  Marc Glisse  

PR c++/53055

gcc/c-family/
* c-common.h (enum ref_operator) [RO_ARROW_PM]: New.

gcc/cp/
* call.c (build_new_op_1): Pass RO_ARROW_PM to cp_build_indirect_ref.
* typeck.c (cp_build_indirect_ref): Handle RO_ARROW_PM.

gcc/testsuite/
* g++.dg/pr53055.C: New testcase.

--
Marc GlisseIndex: cp/typeck.c
===
--- cp/typeck.c (revision 192378)
+++ cp/typeck.c (working copy)
@@ -2901,20 +2901,24 @@ cp_build_indirect_ref (tree ptr, ref_ope
   {
  case RO_ARRAY_INDEXING:
error ("invalid use of array indexing on pointer to member");
break;
  case RO_UNARY_STAR:
error ("invalid use of unary %<*%> on pointer to member");
break;
  case RO_IMPLICIT_CONVERSION:
error ("invalid use of implicit conversion on pointer to member");
break;
+ case RO_ARROW_PM:
+   error ("left hand operand of %<->*%> must be a pointer to class, "
+ "but is a pointer to member of type %qT", type);
+   break;
  default:
gcc_unreachable ();
   }
   else if (pointer != error_mark_node)
 invalid_indirection_error (input_location, type, errorstring);
 
   return error_mark_node;
 }
 
 /* This handles expressions of the form "a[i]", which denotes
Index: cp/call.c
===
--- cp/call.c   (revision 192378)
+++ cp/call.c   (working copy)
@@ -5302,21 +5302,21 @@ build_new_op_1 (location_t loc, enum tre
 case POSTDECREMENT_EXPR:
 case REALPART_EXPR:
 case IMAGPART_EXPR:
 case ABS_EXPR:
   return cp_build_unary_op (code, arg1, candidates != 0, complain);
 
 case ARRAY_REF:
   return cp_build_array_ref (input_location, arg1, arg2, complain);
 
 case MEMBER_REF:
-  return build_m_component_ref (cp_build_indirect_ref (arg1, RO_NULL, 
+  return build_m_component_ref (cp_build_indirect_ref (arg1, RO_ARROW_PM, 
complain), 
 arg2, complain);
 
   /* The caller will deal with these.  */
 case ADDR_EXPR:
 case COMPONENT_REF:
 case COMPOUND_EXPR:
   return NULL_TREE;
 
 default:
Index: c-family/c-common.h
===
--- c-family/c-common.h (revision 192378)
+++ c-family/c-common.h (working copy)
@@ -470,21 +470,23 @@ extern c_language_kind c_language;
 typedef enum ref_operator {
   /* NULL */
   RO_NULL,
   /* array indexing */
   RO_ARRAY_INDEXING,
   /* unary * */
   RO_UNARY_STAR,
   /* -> */
   RO_ARROW,
   /* implicit conversion */
-  RO_IMPLICIT_CONVERSION
+  RO_IMPLICIT_CONVERSION,
+  /* ->* */
+  RO_ARROW_PM
 } ref_operator;
 
 /* Information about a statement tree.  */
 
 struct GTY(()) stmt_tree_s {
   /* A stack of statement lists being collected.  */
   VEC(tree,gc) *x_cur_stmt_list;
 
   /* In C++, Nonzero if we should treat statements as full
  expressions.  In particular, this variable is non-zero if at the
Index: testsuite/g++.dg/pr53055.C
===
--- testsuite/g++.dg/pr53055.C  (revision 0)
+++ testsuite/g++.dg/pr53055.C  (revision 0)
@@ -0,0 +1,5 @@
+// PR c++/53055
+// { dg-do compile }
+
+struct A A :: * p ;
+int i = p ->* p ; // { dg-error "" }

Property changes on: testsuite/g++.dg/pr53055.C
___
Added: svn:eol-style
   + native
Added: svn:keywords
   + Author Date Id Revision URL

[v3] Remove hack for 53067 in mainline

[Paolo Carlini]

Hi,

not necessary anymore thanks to the resolution of c++/51213. Tested 
x86_64-linux multilib, committed.


Thanks,
Paolo.

///
2012-10-12  Paolo Carlini  

* include/bits/hashtable_policy.h: Revert libstdc++/53067 quick
hacks thanks to the resolution of c++/51213.
Index: include/bits/hashtable_policy.h
===
--- include/bits/hashtable_policy.h (revision 192378)
+++ include/bits/hashtable_policy.h (working copy)
@@ -921,8 +921,7 @@
   /// Specialization using EBO.
   template
 struct _Hashtable_ebo_helper<_Nm, _Tp, true>
-// See PR53067.
-: public _Tp
+: private _Tp
 {
   _Hashtable_ebo_helper() = default;
 
@@ -989,9 +988,8 @@
   template
 struct _Hash_code_base<_Key, _Value, _ExtractKey, _H1, _H2, _Hash, false>
-// See PR53067.
-: public  _Hashtable_ebo_helper<0, _ExtractKey>,
-  public  _Hashtable_ebo_helper<1, _Hash>
+: private _Hashtable_ebo_helper<0, _ExtractKey>,
+  private _Hashtable_ebo_helper<1, _Hash>
 {
 private:
   typedef _Hashtable_ebo_helper<0, _ExtractKey>_EboExtractKey;
@@ -1066,10 +1064,9 @@
   typename _H1, typename _H2>
 struct _Hash_code_base<_Key, _Value, _ExtractKey, _H1, _H2,
   _Default_ranged_hash, false>
-// See PR53067.
-: public  _Hashtable_ebo_helper<0, _ExtractKey>,
-  public  _Hashtable_ebo_helper<1, _H1>,
-  public  _Hashtable_ebo_helper<2, _H2>
+: private _Hashtable_ebo_helper<0, _ExtractKey>,
+  private _Hashtable_ebo_helper<1, _H1>,
+  private _Hashtable_ebo_helper<2, _H2>
 {
 private:
   typedef _Hashtable_ebo_helper<0, _ExtractKey>_EboExtractKey;
@@ -1150,10 +1147,9 @@
   typename _H1, typename _H2>
 struct _Hash_code_base<_Key, _Value, _ExtractKey, _H1, _H2,
   _Default_ranged_hash, true>
-// See PR53067.
-: public  _Hashtable_ebo_helper<0, _ExtractKey>,
-  public  _Hashtable_ebo_helper<1, _H1>,
-  public  _Hashtable_ebo_helper<2, _H2>
+: private _Hashtable_ebo_helper<0, _ExtractKey>,
+  private _Hashtable_ebo_helper<1, _H1>,
+  private _Hashtable_ebo_helper<2, _H2>
 {
 private:
   typedef _Hashtable_ebo_helper<0, _ExtractKey>_EboExtractKey;
@@ -1272,8 +1268,7 @@
   typename _H1, typename _H2, typename _Hash>
 struct _Local_iterator_base<_Key, _Value, _ExtractKey,
_H1, _H2, _Hash, true>
-// See PR53067.
-: public _H2
+: private _H2
 {
   _Local_iterator_base() = default;
   _Local_iterator_base(_Hash_node<_Value, true>* __p,
@@ -1305,9 +1300,8 @@
   typename _H1, typename _H2, typename _Hash>
 struct _Local_iterator_base<_Key, _Value, _ExtractKey,
_H1, _H2, _Hash, false>
-// See PR53067.
-: public _Hash_code_base<_Key, _Value, _ExtractKey,
-_H1, _H2, _Hash, false>
+: private _Hash_code_base<_Key, _Value, _ExtractKey,
+ _H1, _H2, _Hash, false>
 {
   _Local_iterator_base() = default;
   _Local_iterator_base(_Hash_node<_Value, false>* __p,
@@ -1470,10 +1464,9 @@
   typename _ExtractKey, typename _Equal,
   typename _H1, typename _H2, typename _Hash, typename _Traits>
   struct _Hashtable_base
-  // See PR53067.
-  : public  _Hash_code_base<_Key, _Value, _ExtractKey, _H1, _H2, _Hash,
- _Traits::__hash_cached::value>,
-public _Hashtable_ebo_helper<0, _Equal>
+  : public _Hash_code_base<_Key, _Value, _ExtractKey, _H1, _H2, _Hash,
+  _Traits::__hash_cached::value>,
+private _Hashtable_ebo_helper<0, _Equal>
   {
   public:
 typedef _Keykey_type;

VEC_COND_EXPR

[Marc Glisse]

Hello,

this patch brings VEC_COND_EXPR closer to what the doc now says. The 
non-comparison case and gimplification are dead paths currently, but it 
seems convenient to introduce them now. Note that by using the generic 
ternary gimplification code, it will produce VEC_COND_EXPR with an 
SSA_NAME as first argument ;-)


bootstrap+testsuite ok.

2012-10-12  Marc Glisse  

* optabs.c (vector_compare_rtx): Change prototype.
(expand_vec_cond_expr): Handle VEC_COND_EXPR whose first operand
is not a comparison.
* gimplify.c (gimplify_expr): Handle VEC_COND_EXPR.

--
Marc GlisseIndex: gimplify.c
===
--- gimplify.c  (revision 192378)
+++ gimplify.c  (working copy)
@@ -7676,20 +7676,21 @@ gimplify_expr (tree *expr_p, gimple_seq
xop0);
if (!useless_type_conversion_p (new_type, TREE_TYPE (xop1)))
  TREE_OPERAND (*expr_p, 1) = fold_convert_loc (input_location,
new_type,
xop1);
/* Continue classified as tcc_binary.  */
goto expr_2;
  }
 
case FMA_EXPR:
+   case VEC_COND_EXPR:
case VEC_PERM_EXPR:
  /* Classified as tcc_expression.  */
  goto expr_3;
 
case POINTER_PLUS_EXPR:
  {
enum gimplify_status r0, r1;
r0 = gimplify_expr (&TREE_OPERAND (*expr_p, 0), pre_p,
post_p, is_gimple_val, fb_rvalue);
r1 = gimplify_expr (&TREE_OPERAND (*expr_p, 1), pre_p,
Index: optabs.c
===
--- optabs.c(revision 192378)
+++ optabs.c(working copy)
@@ -6381,34 +6381,28 @@ get_rtx_code (enum tree_code tcode, bool
 default:
   gcc_unreachable ();
 }
   return code;
 }
 
 /* Return comparison rtx for COND. Use UNSIGNEDP to select signed or
unsigned operators. Do not generate compare instruction.  */
 
 static rtx
-vector_compare_rtx (tree cond, bool unsignedp, enum insn_code icode)
+vector_compare_rtx (enum tree_code tcode, tree t_op0, tree t_op1,
+   bool unsignedp, enum insn_code icode)
 {
   struct expand_operand ops[2];
-  enum rtx_code rcode;
-  tree t_op0, t_op1;
   rtx rtx_op0, rtx_op1;
+  enum rtx_code rcode = get_rtx_code (tcode, unsignedp);
 
-  /* This is unlikely. While generating VEC_COND_EXPR, auto vectorizer
- ensures that condition is a relational operation.  */
-  gcc_assert (COMPARISON_CLASS_P (cond));
-
-  rcode = get_rtx_code (TREE_CODE (cond), unsignedp);
-  t_op0 = TREE_OPERAND (cond, 0);
-  t_op1 = TREE_OPERAND (cond, 1);
+  gcc_assert (TREE_CODE_CLASS (tcode) == tcc_comparison);
 
   /* Expand operands.  */
   rtx_op0 = expand_expr (t_op0, NULL_RTX, TYPE_MODE (TREE_TYPE (t_op0)),
 EXPAND_STACK_PARM);
   rtx_op1 = expand_expr (t_op1, NULL_RTX, TYPE_MODE (TREE_TYPE (t_op1)),
 EXPAND_STACK_PARM);
 
   create_input_operand (&ops[0], rtx_op0, GET_MODE (rtx_op0));
   create_input_operand (&ops[1], rtx_op1, GET_MODE (rtx_op1));
   if (!maybe_legitimize_operands (icode, 4, 2, ops))
@@ -6677,34 +6671,49 @@ expand_vec_cond_expr_p (tree value_type,
 rtx
 expand_vec_cond_expr (tree vec_cond_type, tree op0, tree op1, tree op2,
  rtx target)
 {
   struct expand_operand ops[6];
   enum insn_code icode;
   rtx comparison, rtx_op1, rtx_op2;
   enum machine_mode mode = TYPE_MODE (vec_cond_type);
   enum machine_mode cmp_op_mode;
   bool unsignedp;
+  tree op0a, op0b;
+  enum tree_code tcode;
 
-  gcc_assert (COMPARISON_CLASS_P (op0));
+  if (COMPARISON_CLASS_P (op0))
+{
+  op0a = TREE_OPERAND (op0, 0);
+  op0b = TREE_OPERAND (op0, 1);
+  tcode = TREE_CODE (op0);
+}
+  else
+{
+  /* Fake op0 < 0.  */
+  gcc_assert (!TYPE_UNSIGNED (TREE_TYPE (op0)));
+  op0a = op0;
+  op0b = build_zero_cst (TREE_TYPE (op0));
+  tcode = LT_EXPR;
+}
+  unsignedp = TYPE_UNSIGNED (TREE_TYPE (op0a));
+  cmp_op_mode = TYPE_MODE (TREE_TYPE (op0a));
 
-  unsignedp = TYPE_UNSIGNED (TREE_TYPE (TREE_OPERAND (op0, 0)));
-  cmp_op_mode = TYPE_MODE (TREE_TYPE (TREE_OPERAND (op0, 0)));
 
   gcc_assert (GET_MODE_SIZE (mode) == GET_MODE_SIZE (cmp_op_mode)
  && GET_MODE_NUNITS (mode) == GET_MODE_NUNITS (cmp_op_mode));
 
   icode = get_vcond_icode (mode, cmp_op_mode, unsignedp);
   if (icode == CODE_FOR_nothing)
 return 0;
 
-  comparison = vector_compare_rtx (op0, unsignedp, icode);
+  comparison = vector_compare_rtx (tcode, op0a, op0b, unsignedp, icode);
   rtx_op1 = expand_normal (op1);
   rtx_op2 = expand_normal (op2);
 
   create_output_operand (&ops[0], target, mode);
   create_input_operand (&ops[1], rtx_op1, mode);
   create_input_operand (&ops[2], rtx_op2, mode);
   create_fixed_operand 

Re: [PATCH 0/6] Thread pointer built-in functions / [SH] PR 54760

[Oleg Endo]

On Thu, 2012-10-11 at 23:11 +0800, Chung-Lin Tang wrote:
> This patch set has been committed, thanks to all maintainers who
> reviewed the respective parts.
> 
> Thanks,
> Chung-Lin
> 

This broke the recently added thread pointer built-ins on SH, but I was
prepared for that, so no problem here.  The attached patch is a straight
forward fix.

However, with the patch applied I get an ICE on one of the SH thread
pointer tests:  gcc/testsuite/gcc.target/sh/pr54760-3.c, function
test04:

internal compiler error: in expand_insn, at optabs.c:8208
__builtin_set_thread_pointer (xx[i]);
 ^
0x8478872 expand_insn
../../gcc-trunk2/gcc/optabs.c:8208
0x8478872 expand_insn
../../gcc-trunk2/gcc/optabs.c:8204
0x81ded5a expand_builtin_set_thread_pointer
../../gcc-trunk2/gcc/builtins.c:5780
0x81e6b18 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode,
int)
../../gcc-trunk2/gcc/builtins.c:6855
0x82eeaf9 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**)
../../gcc-trunk2/gcc/expr.c:10143
0x8216a7b expand_call_stmt
../../gcc-trunk2/gcc/cfgexpand.c:2012
0x8216a7b expand_gimple_stmt_1
../../gcc-trunk2/gcc/cfgexpand.c:2050
0x8216a7b expand_gimple_stmt
../../gcc-trunk2/gcc/cfgexpand.c:2202
0x8218406 expand_gimple_basic_block
../../gcc-trunk2/gcc/cfgexpand.c:3956
0x821a417 gimple_expand_cfg
../../gcc-trunk2/gcc/cfgexpand.c:4475
Please submit a full bug report,


All the other test cases seem to produce code as expected though.
Could you please try out the failing test case mentioned above?
As mentioned in the file gcc/testsuite/gcc.target/sh/pr54760-3.c it
should be moved to C torture tests.

Anyway, regardless of this failure, the attached patch for SH should be
applicable. OK?

Cheers,
Oleg

gcc/ChangeLog:

PR target/54760
* config/sh/sh.c (bdesc): Remove thread pointer built-ins.
* config/sh/sh.md (get_thread_pointer, set_thread_pointer): 
Append mode name 'si'.

Index: gcc/config/sh/sh.c
===
--- gcc/config/sh/sh.c	(revision 192378)
+++ gcc/config/sh/sh.c	(working copy)
@@ -11778,12 +11778,6 @@
 CODE_FOR_byterev,	"__builtin_sh_media_BYTEREV", SH_BLTIN_2, 0 },
   { shmedia_builtin_p,
 CODE_FOR_prefetch,	"__builtin_sh_media_PREFO", SH_BLTIN_PSSV, 0 },
-
-  { sh1_builtin_p,
-CODE_FOR_get_thread_pointer, "__builtin_thread_pointer", SH_BLTIN_VP, 0 },
-  { sh1_builtin_p,
-CODE_FOR_set_thread_pointer, "__builtin_set_thread_pointer",
-SH_BLTIN_PV, 0 },
 };
 
 static void
Index: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md	(revision 192378)
+++ gcc/config/sh/sh.md	(working copy)
@@ -10085,7 +10085,7 @@
 ;;
 ;; On SH the thread pointer is kept in the GBR.
 ;; These patterns are usually expanded from the respective built-in functions.
-(define_expand "get_thread_pointer"
+(define_expand "get_thread_pointersi"
   [(set (match_operand:SI 0 "register_operand") (reg:SI GBR_REG))]
   "TARGET_SH1")
 
@@ -10096,7 +10096,7 @@
   "stc	gbr,%0"
   [(set_attr "type" "tls_load")])
 
-(define_expand "set_thread_pointer"
+(define_expand "set_thread_pointersi"
   [(set (reg:SI GBR_REG)
 	(unspec_volatile:SI [(match_operand:SI 0 "register_operand")]
 	 UNSPECV_GBR))]

Re: [lra] patch to fix GCC crash on a SPEC2006 test

[Peter Bergner]

On Thu, 2012-10-11 at 11:35 -0400, Vladimir Makarov wrote:
> + /* Call insn might have not references for pseudos besides
> +in CALL_INSN_FUNCTION_USAGE but we don't count them in
> +insn_bitmap of corresponding lra_reg_info as they don't
> +need reloads.  */

Was this supposed to read:

  Call insn might have references of pseudos besides those in
  CALL_INSN_FUNCTION_USAGE, but we don't count them in insn_bitmap
  of the corresponding lra_reg_info as they don't need reloads.

???

Peter

Re: [PATCH RFA] Implement register pressure directed hoist pass

[Steven Bosscher]

On Thu, Oct 11, 2012 at 8:50 AM, Bin Cheng wrote:

> +  /* x+y won't be hoisted without defaultly enabled "-fira-hoist-pressure",

defaulty comment.

> + kinds of code motion(including code hoisting) in a unified way.

needs space between "motion" and "(".

> +   flow graph, given if it can reach BB unimpared.  Stop the search if the

s/given if/if/


> +should_hoist_expr_to_dom (basic_block expr_bb, struct expr *expr,
> +   basic_block bb, sbitmap visited, int distance,
> +   int *bb_size, enum reg_class pressure_class,
> +   int *nregs, bitmap hoisted_bbs)

At least BB_SIZE and DISTANCE are not documented (also not before your
patch). While there, can you document these please?


> +  becasue hoisting constant expr aggresively results in worse code
> +  as observed.  */

s/becasue/because/
s/aggresively/aggressively/

Not sure what you mean with "as observed". Observed where/how?

> -  visited = XCNEWVEC (char, last_basic_block);
> +  visited = sbitmap_alloc (last_basic_block);
> +  sbitmap_zero (visited);

Send a separate patch for this change please. Really. Reviewing
patches is much easier if you post things one change at a time.


> +   The code hoisting pass hoists multiple computations of expression
> +   to dominator basic block, like from b2/b3 to b1 as depicted below:

"The code hoisting pass can hoist multiple computations of the same
expression along dominated paths to a dominating basic block, like
from ..."


> +   Unfortunately code hoisting generally extend live range of output

s/extend/extends the/
s/of output/of an output/


> +   from rtx cost of corresponding expression and it's used to control

s/of corresponding/of the corresponding/
Similarly elsewhere in comments.


> + of shrinked live range of input pseudo register when hoisting an

s/range/ranges/
s/register/registers/
After all this is only possible, AFAICT, if there's more than one
input register.

I'll leave all the algorithmic stuff to Jeff...

Ciao!
Steven

Re: [asan] Emit GIMPLE directly, small cleanups

[Wei Mi]

Hi,

Here is the initial test results of gcc asan patch, and it shows us
some missing features in gcc but existing in llvm.
[1]. gcc regression test for gcc-asan passes.
[2]. llvm regression tests for gcc-asan: 18 failures in 123 for tests
written in google test and 24 failures in 28 for tests written in lit
tests.

gcc missing features:
1. gcc implementation doesn't support stack/global overflow check
1. gcc implementation doesn't support some attributes, such as
__attribute__((no_address_safety_analysis)), which llvm does
2. gcc doesn't detect out-of-bound bitfield access of heap, which llvm does
3. gcc doesn't detect out-of-bound memset, memcopy, strcat and strcpy
for heap allocated memory or string, which llvm does
4. gcc doesn't contain similar options: -mllvm -asan-blacklist, -mllvm
-asan-initialization-order
5. gcc -fasan doesn't take effect at -O0, but llvm does. Most lit
tests contain checks from -O0 to -O3, which makes gcc fail.
6. $HOME/llvm/trunk/projects/compiler-rt/lib/asan/scripts/asan_symbolize.py
could generate valid source locations from virtual addresses for llvm
binary, but fail to do that for gcc binary.  example, llvm result #1
0x402694 in main heap-overflow.cc:23 .vs. gcc result: #1 0x402694 in
main ??:0. Some FileCheck in llvm lit tests expect the valid source
locations.

Thanks,
Wei.


On Thu, Oct 11, 2012 at 10:31 AM, Jakub Jelinek  wrote:
> On Thu, Oct 11, 2012 at 01:14:31PM -0400, Diego Novillo wrote:
>> On 2012-10-11 12:38 , Jakub Jelinek wrote:
>>
>> >-  gimple_seq seq, stmts;
>> >-  tree shadow_type = size_in_bytes == 16 ?
>> >-  short_integer_type_node : char_type_node;
>> >-  tree shadow_ptr_type = build_pointer_type (shadow_type);
>> >-  tree uintptr_type = lang_hooks.types.type_for_mode (ptr_mode,
>> >-  /*unsignedp=*/true);
>> >+  tree shadow_ptr_type = shadow_ptr_types[size_in_bytes == 16];
>>
>> Add '? 1 : 0' in the array index expression.
>
> Ok.
>
>> >/* Build
>> >- (base_addr >> ASAN_SHADOW_SHIFT) | targetm.asan_shadow_offset ().  */
>> >+ (base_addr >> ASAN_SHADOW_SHIFT) + targetm.asan_shadow_offset ().  */
>>
>> Hm, I wonder if this is a documentation problem or we're generating
>> bad runtime code.  Wei, you tested the runtime and it was working
>> with the GCC generated code, right?
>
> The asan web pages document |, the old tree-asan.c emitted +, I've changed
> it to BIT_IOR_EXPR, but that resulted in worse assembly, and I believe at
> least for the current x86_64 and i686 address ranges and shadow offset
> values it actually doesn't matter.
> On x86_64 stack is like 0x76e0, shifted down by 3 is still smaller
> than 1L << 44 that is ored or added to it.  And the negative half of the
> address space is used by the kernel, nothing is mapped into it (besides
> vsyscall page) and neither | nor + of 1L << 44 to it would work well.
> On i386, | and + works the same for all addresses, as 0xU >> 3
> is still smaller than 1 << 29.
> The reason why + generates better code on x86_64/i686 is that one can use
> e.g. movzbl (%r1, %r2), %r3 instead of orq %r2, %r1; movzb (%r1), %r3.
>
>> >+  if (shadow_ptr_types[0] == NULL_TREE)
>> >+{
>> >+  alias_set_type set = new_alias_set ();
>> >+  shadow_ptr_types[0]
>> >+= build_distinct_type_copy (unsigned_char_type_node);
>> >+  TYPE_ALIAS_SET (shadow_ptr_types[0]) = set;
>> >+  shadow_ptr_types[0] = build_pointer_type (shadow_ptr_types[0]);
>> >+  shadow_ptr_types[1]
>> >+= build_distinct_type_copy (short_unsigned_type_node);
>> >+  TYPE_ALIAS_SET (shadow_ptr_types[1]) = set;
>> >+  shadow_ptr_types[1] = build_pointer_type (shadow_ptr_types[1]);
>> >+}
>>
>> Move this to an initialization function, please.
>
> Okay.
>
> Jakub

Re: [Patch, Fortran] PR 40453: Enhanced (recursive) argument checking

[Thomas Koenig]

Hi Janus,


ping!


2012/10/7 Janus Weil :

Hi all,

here is a rather straightforward patch, which does 'recursive'
checking of dummy procedures.

Regtested on x86_64-unknown-linux-gnu. Ok for trunk?


This is OK.  Thanks for the patch!

Thomas

[RFA:] Fix frame-pointer-clobbering in builtins.c:expand_builtin_setjmp_receiver

[Hans-Peter Nilsson]

The md.texi entry for nonlocal_goto_receiver says "A typical reason
why you might need this pattern is if some value, such as a pointer to
a global table, must be restored when the frame pointer is restored.
Note that a nonlocal goto only occurs within a unit-of-translation, so
a global table pointer that is shared by all functions of a given
module need not be restored".  One use would be to restore a
hardware-register-value saved in the current frame; the frame where
__builtin_setjmp is called (i.e. not a global context).  This is what
the MMIX port does, saving the register-stack-pointer-register for use
when unwinding the register stack.  I can imagine other similar
register-restoring needs that require something saved in the current
frame, but current ports with that pattern (or setjmp_receiver) but
without a nonlocal_goto pattern (see the HAVE_nonlocal_goto condition
in the patch) don't.  (The AVR port performs what appears to be a
cargo-cult song and dance; the bug below copied into the port, but
the port will not otherwise be affected by the bug or this patch, as it
has a nonlocal_goto pattern.)

But, in the builtins.c:expand_builtin_setjmp_receiver, the
frame-pointer is *clobbered* for a mysterious and fuddy reason:

  /* This might change the hard frame pointer in ways that aren't
 apparent to early optimization passes, so force a clobber.  */
  emit_clobber (hard_frame_pointer_rtx);

That comment might have been true eons ago, but these days clobbering
the frame-pointer means that its value is void and any restoring insns
emitted before the clobber are deleted *because* of the clobber.  For
example, in built-in-setjmp.c at -O2.  Before .191r.ud_dce (i.e. in
the .190r.init-regs dump):

(code_label/s 47 115 48 3 3 "" [2 uses])
(note 48 47 49 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
(insn 49 48 168 3 (use (reg/f:DI 253 $253)) 
/tmp/mmiximp2/gcc/gcc/testsuite/gcc.c-torture/execute/built-in-setjmp.c:21 -1
 (nil))
(insn 168 49 51 3 (set (reg/f:DI 253 $253)
(plus:DI (reg/f:DI 253 $253)
(const_int 24 [0x18]))) 
/tmp/mmiximp2/gcc/gcc/testsuite/gcc.c-torture/execute/built-in-setjmp.c:21 -1
 (nil))
(insn 51 168 52 3 (clobber (reg/f:DI 253 $253)) 
/tmp/mmiximp2/gcc/gcc/testsuite/gcc.c-torture/execute/built-in-setjmp.c:21 -1
 (nil))
(insn 52 51 54 3 (parallel [
(unspec_volatile [
(reg/f:DI 253 $253)
] 1)
(clobber (scratch:DI))
(clobber (reg:DI 259 rJ))
]) 
/tmp/mmiximp2/gcc/gcc/testsuite/gcc.c-torture/execute/built-in-setjmp.c:21 63 
{*nonlocal_goto_receiver_expanded}
 (expr_list:REG_UNUSED (reg:DI 259 rJ)
(nil)))
(insn 54 52 136 3 (asm_input/v ("") (null):0) 
/tmp/mmiximp2/gcc/gcc/testsuite/gcc.c-torture/execute/built-in-setjmp.c:21 -1
 (nil))

After:

(code_label/s 47 115 48 3 3 "" [2 uses])
(note 48 47 49 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
(insn 49 48 51 3 (use (reg/f:DI 253 $253)) 
/tmp/mmiximp2/gcc/gcc/testsuite/gcc.c-torture/execute/built-in-setjmp.c:21 -1
 (nil))
(insn 51 49 52 3 (clobber (reg/f:DI 253 $253)) 
/tmp/mmiximp2/gcc/gcc/testsuite/gcc.c-torture/execute/built-in-setjmp.c:21 -1
 (nil))
(insn 52 51 54 3 (parallel [
(unspec_volatile [
(reg/f:DI 253 $253)
] 1)
(clobber (scratch:DI))
(clobber (reg:DI 259 rJ))
]) 
/tmp/mmiximp2/gcc/gcc/testsuite/gcc.c-torture/execute/built-in-setjmp.c:21 63 
{*nonlocal_goto_receiver_expanded}
 (expr_list:REG_UNUSED (reg:DI 259 rJ)
(nil)))
(insn 54 52 136 3 (asm_input/v ("") (null):0) 
/tmp/mmiximp2/gcc/gcc/testsuite/gcc.c-torture/execute/built-in-setjmp.c:21 -1
 (nil))

Note that insn 168 deleted, which seems a logical optimization.  The
bug is to emit the clobber, not that the restoring insn is removed.
While grepping around for other emitters of nonlocal_goto_receiver I
noticed that builtins.c:expand_builtin_setjmp_receiver is identical to
stmt.c:expand_nl_goto_receiver save for two things: the frame-pointer
clobbering(!) and that expand_builtin_setjmp_receiver instead prefers to
emit setjmp_receiver.  I don't see how the frame-pointer-clobbering
would be needed as part of emitting setjmp_receiver.

I suggest eliminating the bug and one copy of the apparently bug-prone
code.  I kept the function in builtins.c for obvious reasons (if not
obvious, consider the name: expand *builtin* setjmp_receiver) with the
setjmp-ness expressed through the label parameter, which is non-NULL
for pre-existing calls.  Note also the fixed clobber-comment,
obviously incorrect in the stmt.c almost-copy, and at least on the
wrong line in expand_builtin_setjmp_receiver.

Tested mmix-knuth-mmixware, x86_64-unknown-linux-gnu (for good measure)
and rl78-elf (a SJLJ target; fixed-up with a patch from the maintainer
for the current breakage in PR54882, but without fortran), no regressions.

This fixes the following FAILs for mmix-knuth-mmixware:

Running /tmp/

[C++ testcase] PR 51878

[Paolo Carlini]

Hi,

testcase committed, closed as fixed in 4.8.0.

Thanks,
Paolo.

//
2012-10-11  Paolo Carlini  

PR c++/51878
* g++.dg/cpp0x/decltype45.C: New.
Index: g++.dg/cpp0x/decltype45.C
===
--- g++.dg/cpp0x/decltype45.C   (revision 0)
+++ g++.dg/cpp0x/decltype45.C   (working copy)
@@ -0,0 +1,40 @@
+// PR c++/51878
+// { dg-do compile { target c++11 } }
+
+template
+auto indirect_call(F f, T... t) -> decltype(f(t...))
+{
+  return f(t...);
+}
+
+template
+struct VariadicBind
+{
+  F f;
+  T t;
+
+  template
+  auto operator()(A... a) -> decltype(indirect_call(f, t, a...))
+  {
+return indirect_call(f, t, a...);
+  }
+};
+
+template
+void apply(F f)
+{
+  f();
+}
+
+template
+void apply(F f, V1 v1, V... v)
+{
+  apply(VariadicBind{f, v1}, v...);
+}
+
+void func(int, int) { }
+
+int main()
+{
+  apply(func, 0, 0);
+}

Re: [SH] PR 51244 - Improve T bit store and cbranch

[Kaz Kojima]

Oleg Endo  wrote:
> This one further improves T bit stores and conditional branches on SH
> for cases like described in comment #53 in the PR.
> Tested on rev 192200 with
> make -k check RUNTESTFLAGS="--target_board=sh-sim
> \{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
> 
> and no new failures.

The patch is OK.

Regards,
kaz

Re: [PATCH 0/6] Thread pointer built-in functions / [SH] PR 54760

[Kaz Kojima]

Oleg Endo  wrote:
> Anyway, regardless of this failure, the attached patch for SH should be
> applicable. OK?

OK.

Regards,
kaz

Re: Move statements upwards after reassociation

[Easwaran Raman]

Thanks for the comments. As David wrote, the intent of the patch is
not to do a general purpose scheduling, but to compensate for the
possible live range lengthening introduced by reassociation.


On Thu, Oct 11, 2012 at 6:16 AM, Richard Biener
 wrote:
> On Thu, Oct 11, 2012 at 3:52 AM, Easwaran Raman  wrote:
>>
>> +/* Move STMT up within its BB until it can not be moved any further.  */
>> +
>> +static void move_stmt_upwards (gimple stmt)
>> +{
>> +  gimple_stmt_iterator gsi, gsistmt;
>> +  tree rhs1, rhs2;
>> +  gimple rhs1def = NULL, rhs2def = NULL;
>> +  rhs1 = gimple_assign_rhs1 (stmt);
>> +  rhs2 = gimple_assign_rhs2 (stmt);
>> +  gcc_assert (rhs1);
>
> Please no such senseless asserts.  The following line will segfault anyway
> if rhs1 is NULL and with a debugger an assert doesn't add any useful
> information.
Ok.
>
>> +  if (TREE_CODE (rhs1) == SSA_NAME)
>> +rhs1def = SSA_NAME_DEF_STMT (rhs1);
>> +  else if (TREE_CODE (rhs1) != REAL_CST
>> +   && TREE_CODE (rhs1) != INTEGER_CST)
>> +return;
>> +  if (rhs2)
>
> You may not access gimple_assign_rhs2 if it is not there.  So you have
> to check whether you have an unary, binary or ternary (yes) operation.

gimple_assign_rhs2 returns NULL_TREE if it the RHS of an assignment
has less than two operands.  Regarding the check for ternary
operation, I believe it is not necessary. A statement is considered
for reassociation only if the RHS class is GIMPLE_BINARY_RHS.
Subsequently, for rhs1 and rhs2, it checks if the def statements also
have the same code and so it seems to me that a statement with a
ternary operator in the RHS will never be considered in
rewrite_expr_tree.


>
>> +{
>> +  if (TREE_CODE (rhs2) == SSA_NAME)
>> +rhs2def = SSA_NAME_DEF_STMT (rhs2);
>> +  else if (TREE_CODE (rhs1) != REAL_CST
>> +   && TREE_CODE (rhs1) != INTEGER_CST)
>> +return;
>> +}
>> +  gsi = gsi_for_stmt (stmt);
>> +  gsistmt = gsi;
>> +  gsi_prev (&gsi);
>> +  for (; !gsi_end_p (gsi); gsi_prev (&gsi))
>
> 
>
> This doesn't make much sense.  You can move a stmt to the nearest
> common post-dominator.  Assuming you only want to handle placing
> it after rhs1def or after rhs2def(?) you don't need any loop, just
> two dominator queries and an insertion after one of the definition
> stmts.

Within a BB isn't that still O(size of BB)?

> But this code should consider BBs.
For reassociation to look across BBs, the code should look something like this:

L1 :
   a_2 = a_1 + 10
   jc L3
L2:
  a_3 = a_2 + 20

- L1 should dominate L2 (otherwise there will be a phi node at L2 and
the reassociation of a_3 will not consider the definition of a_2)
- There are no other uses of a_2 other than the one in L3.

After reassociation, the stmt defining a_2 would be moved to L2.  In
that case, the downward code motion of a_2 = a_1 + 10 to L2 is
beneficial (one less instruction if the branch is taken). It is not
obvious to me that moving  it to L1 (or whereever a_1 is defined) is
beneficial.

>  And I don't see why more optimal
> placement cannot be done during rewrite_expr_tree itself.

I started with that idea, but my current approach looks more simpler.


Thanks,
Easwaran
>
> NB, the whole reassoc code needs a re-write to avoid the excessive
> stmt modifications when it does nothing.  So I'd very much rather avoid
> adding anything to reassoc until that rewrite happened.
>
> Richard.
>
>> +{
>> +  gimple curr_stmt = gsi_stmt (gsi);
>> +  if (curr_stmt == rhs1def || curr_stmt == rhs2def) {
>> +gsi_move_after (&gsistmt, &gsi);
>> +return;
>> +  }
>> +}
>> +
>> +}
>> +
>>  /* Recursively rewrite our linearized statements so that the operators
>> match those in OPS[OPINDEX], putting the computation in rank
>> order.  */
>>
>>  static void
>>  rewrite_expr_tree (gimple stmt, unsigned int opindex,
>> -   VEC(operand_entry_t, heap) * ops, bool moved)
>> +   VEC(operand_entry_t, heap) * ops, bool moved,
>> +   VEC(gimple, heap) **stmts_to_move)
>>  {
>>tree rhs1 = gimple_assign_rhs1 (stmt);
>>tree rhs2 = gimple_assign_rhs2 (stmt);
>> @@ -2299,6 +2337,7 @@ rewrite_expr_tree (gimple stmt, unsigned int opind
>>print_gimple_stmt (dump_file, stmt, 0, 0);
>>  }
>>   }
>> +  VEC_safe_push (gimple, heap, *stmts_to_move, stmt);
>>return;
>>  }
>>
>> @@ -2346,7 +2385,9 @@ rewrite_expr_tree (gimple stmt, unsigned int opind
>>  }
>>/* Recurse on the LHS of the binary operator, which is guaranteed to
>>   be the non-leaf side.  */
>> -  rewrite_expr_tree (SSA_NAME_DEF_STMT (rhs1), opindex + 1, ops, moved);
>> +  rewrite_expr_tree (SSA_NAME_DEF_STMT (rhs1), opindex + 1, ops, moved,
>> + stmts_to_move);
>> +  VEC_safe_push (gimple, heap, *stmts_to_move, stmt);
>>  }
>>
>>  /* Find out how many cycles we need to compute statements chain.
>> @@ -3427,6 +3468,9 @@ reassociate_bb (basic_block bb)
>>  {
>>gimple_stmt_iterator gsi;

RE: [PATCH RFA] Implement register pressure directed hoist pass

[Bin Cheng]

> -Original Message-
> From: Steven Bosscher [mailto:stevenb@gmail.com]
> Sent: Friday, October 12, 2012 7:04 AM
> To: Bin Cheng
> Cc: Jeff Law; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH RFA] Implement register pressure directed hoist pass
> 
> On Thu, Oct 11, 2012 at 8:50 AM, Bin Cheng wrote:
> 
> > +  /* x+y won't be hoisted without defaultly enabled
> > + "-fira-hoist-pressure",
> 
> defaulty comment.
> 
> > + kinds of code motion(including code hoisting) in a unified way.
> 
> needs space between "motion" and "(".
> 
> > +   flow graph, given if it can reach BB unimpared.  Stop the search
> > + if the
> 
> s/given if/if/
> 
> 
> > +should_hoist_expr_to_dom (basic_block expr_bb, struct expr *expr,
> > + basic_block bb, sbitmap visited, int distance,
> > + int *bb_size, enum reg_class pressure_class,
> > + int *nregs, bitmap hoisted_bbs)
> 
> At least BB_SIZE and DISTANCE are not documented (also not before your
patch).
> While there, can you document these please?
> 
> 
> > +becasue hoisting constant expr aggresively results in worse code
> > +as observed.  */
> 
> s/becasue/because/
> s/aggresively/aggressively/
> 
> Not sure what you mean with "as observed". Observed where/how?
> 
> > -  visited = XCNEWVEC (char, last_basic_block);
> > +  visited = sbitmap_alloc (last_basic_block);
> > +  sbitmap_zero (visited);
> 
> Send a separate patch for this change please. Really. Reviewing patches is
> much easier if you post things one change at a time.
> 
> 
> > +   The code hoisting pass hoists multiple computations of expression
> > +   to dominator basic block, like from b2/b3 to b1 as depicted below:
> 
> "The code hoisting pass can hoist multiple computations of the same
expression
> along dominated paths to a dominating basic block, like from ..."
> 
> 
> > +   Unfortunately code hoisting generally extend live range of output
> 
> s/extend/extends the/
> s/of output/of an output/
> 
> 
> > +   from rtx cost of corresponding expression and it's used to control
> 
> s/of corresponding/of the corresponding/ Similarly elsewhere in comments.
> 
> 
> > +   of shrinked live range of input pseudo register when hoisting an
> 
> s/range/ranges/
> s/register/registers/
> After all this is only possible, AFAICT, if there's more than one input
> register.
> 
> I'll leave all the algorithmic stuff to Jeff...

Very sorry I didn't realize there are so many language errors. Since English
is not my native language, I will pay more attention to comments in the
future.

Thanks very much for your patient.

Re: RFC: LRA for x86/x86-64 [0/9]

[Vladimir Makarov]

On 12-10-11 5:53 PM, Peter Bergner wrote:

On Tue, 2012-10-02 at 10:57 -0400, Vladimir Makarov wrote:

Chaitin-Briggs literature does not discuss the termination, just saying
that live-ranges shortening will result to assigning hard regs to all
necessary pseudos which is not clearly guaranteed. There is the same
problem in LRA.  So LRA checks that too many passes are done or to many
reloads for one insn are made and abort LRA.  Porting LRA is mostly
fixing such aborts.

IIRC, talking with the guys from Rice, they had a limit on the number of
color/spill iterations (20) before aborting, since anything more than
that would be due to a bug.  I believe the largest number of iterations
I ever saw in my allocator was about 6 iterations of color/spill.  I hit
a few cases that iterated forever, but those were always due to bugs in
my code or special hairy details I hadn't handled.  You're correct that
the hairy details are never discussed in papers. :)


Interesting.  The max number passes is very dependent on the target.  
The biggest I saw was about 20 on a test on m68k

Another thing omitted by literature is inheritance which is very
important for performance.  Although it could be considered as a special
case of live-range splitting.  There are also a lot of small important
details (e.g. what to do in case of displacement constraints,

To handle displacement constraints, instead of spilling to stack slots,
we spilled to spill pseudos which look like normal register pseudos.
We would then color them just like normal pseudos, but the colors
represent stack slots and not registers.  If "k" becomes too big, it
means you surpassed the maximum displacement, and you'll have to spill
the spill pseudo.  For small displacement cpus, coloring the spill pseudos
does a good job reusing stack slots which reduces the largest displacement
you'll see.  For cpus with no displacement issues, you could just give
each spill pseudo a different color which would mean you wouldn't have
to compute a interference graph of the spill pseudos and all the work
and space that goes into building that.

Interesting approach to spill a spilled pseudo.

Although it is not wise to give a different color for spilled pseudos on 
targets without displacement issues.  Small space for pseudos (by 
reusing slots) gives better data locality and smaller displacements 
which are important to reduce code size for targets having different 
size of insn displacement field for different displacements (e.g. x86).  
I know only one drawback of reusing stack slots.  It is less freedom for 
insn-scheduling after RA.  But still it is more important to reuse the 
stack than better 2nd insn scheduling at least for most widely used 
target x86/x86-64.


For targets with different displacement sizes, in my experience coloring 
is also not best algorithm for this.  It usually results in smaller 
stack space but it has a tendency to evenly spread pseudos to different 
slots instead of putting important pseudos into slots with smaller 
displacements to generate smaller insns.


Just my observations, coloring is pretty good for register allocation.  
It works particularly well for unknown (or varying) execution profiles.  
But if you have exact execution profiles, there are heuristic approaches 
which could work better coloring.


Note, with spill pseudos, you can perform dead code elimination, coalescing
and other optimizations on them just like normal pseudos to reduce the
amount of spill code generated.

True.