Re: [Patch, Fortran, OOP] PR 56284: ICE with alternate return in type-bound procedure

[Janus Weil]

>>> Regarding the second point, one should mention that we already have a
>>> warning for "alternate return", but this only triggers if there is an
>>> actual RETURN statement (which is not the case for the test code in
>>> the PR). The warning I'm adding triggers on the appearance of an
>>> asterisk argument.
>>
>> Shouldn't one then remove the other warning, which should be then
>> unreachable? If so, please do so.
>
> Yes, will do so in a follow-up patch.
>
>
>>> This induces a certain redundancy, i.e. we warn about both the
>>> alternate-return argument and the alternate RETURN statement. The
>>> question is if we want to keep this, or whether on can remove the old
>>> warning for the RETURN statement (which could be done in a follow-up
>>> patch).
>>
>> Or it is not unreachable but leads to double-diagnostic which is not better,
>> either.
>
> Right.
>
>>> The patch is regtested on x86_64-unknown-linux-gnu. Ok for trunk?
>>
>> OK with the -std= change. (Please run "make
>> RUNTESTFLAGS="dg.exp=..f90" prior committal to check whether it indeed
>> works with -std=gnu.)
>
> All of them still work with std=gnu.

I have just committed the patch as 197389.

Will take care of removing the double diagnostics next. Also I just
noticed that there still seem to be cases where one does not get a
warning for alternate return (such as altreturn_1 and altreturn_4 in
the testsuite).

Cheers,
Janus


>>> 2013-04-01  Janus Weil  
>>>
>>>  PR fortran/56284
>>>  PR fortran/40881
>>>  * decl.c (gfc_match_formal_arglist): Warn about alternate-return
>>>  arguments.
>>>  * interface.c (check_dummy_characteristics): Return if symbols are
>>> NULL.
>>>
>>> 2013-04-01  Janus Weil  
>>>
>>>  PR fortran/56284
>>>  PR fortran/40881
>>>  * gfortran.dg/altreturn_8.f90: New.
>>>  * gfortran.dg/altreturn_2.f90: Add -std=legacy.
>>>  * gfortran.dg/intrinsic_actual_3.f90: Ditto.
>>>  * gfortran.dg/invalid_interface_assignment.f90: Ditto.
>>
>>

[PATCH] Fix PR56778

[Richard Biener]

This fixes PR56778 - a fallout of my vectorizer TLC regarding
dataref analysis.  The patch restores a check that disallows
runtime alias checks for gather loads (those are not loop
invariant).  It also fixes another possible source of issues.

Bootstrapped and tested on x86_64-unknown-linux-gnu, applied
yesterday already (forget to post the patch ...).

Richard.

2013-04-02  Richard Biener  

PR tree-optimization/56778
* tree-vect-data-refs.c (vect_analyze_data_ref_dependence):
Runtime alias tests are not supported for gather loads.
* tree-vect-loop-manip.c (vect_loop_versioning): Insert
stmts referenced from SSA operands before updating SSA form.

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

Index: gcc/tree-vect-data-refs.c
===
*** gcc/tree-vect-data-refs.c   (revision 197341)
--- gcc/tree-vect-data-refs.c   (working copy)
*** vect_analyze_data_ref_dependence (struct
*** 280,285 
--- 280,302 
/* Unknown data dependence.  */
if (DDR_ARE_DEPENDENT (ddr) == chrec_dont_know)
  {
+   if (STMT_VINFO_GATHER_P (stmtinfo_a)
+ || STMT_VINFO_GATHER_P (stmtinfo_b))
+   {
+ if (dump_enabled_p ())
+   {
+ dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
+  "versioning for alias not supported for: "
+  "can't determine dependence between ");
+ dump_generic_expr (MSG_MISSED_OPTIMIZATION, TDF_SLIM,
+DR_REF (dra));
+ dump_printf (MSG_MISSED_OPTIMIZATION, " and ");
+ dump_generic_expr (MSG_MISSED_OPTIMIZATION, TDF_SLIM,
+DR_REF (drb));
+   }
+ return false;
+   }
+ 
if (dump_enabled_p ())
{
  dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
*** vect_analyze_data_ref_dependence (struct
*** 299,304 
--- 316,338 
/* Known data dependence.  */
if (DDR_NUM_DIST_VECTS (ddr) == 0)
  {
+   if (STMT_VINFO_GATHER_P (stmtinfo_a)
+ || STMT_VINFO_GATHER_P (stmtinfo_b))
+   {
+ if (dump_enabled_p ())
+   {
+ dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
+  "versioning for alias not supported for: "
+  "bad dist vector for ");
+ dump_generic_expr (MSG_MISSED_OPTIMIZATION, TDF_SLIM,
+DR_REF (dra));
+ dump_printf (MSG_MISSED_OPTIMIZATION, " and ");
+ dump_generic_expr (MSG_MISSED_OPTIMIZATION, TDF_SLIM,
+DR_REF (drb));
+   }
+ return false;
+   }
+ 
if (dump_enabled_p ())
  {
dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location, 
Index: gcc/tree-vect-loop-manip.c
===
*** gcc/tree-vect-loop-manip.c  (revision 197341)
--- gcc/tree-vect-loop-manip.c  (working copy)
*** vect_loop_versioning (loop_vec_info loop
*** 2476,2486 
  
/* End loop-exit-fixes after versioning.  */
  
-   update_ssa (TODO_update_ssa);
if (cond_expr_stmt_list)
  {
cond_exp_gsi = gsi_last_bb (condition_bb);
gsi_insert_seq_before (&cond_exp_gsi, cond_expr_stmt_list,
 GSI_SAME_STMT);
  }
  }
--- 2476,2486 
  
/* End loop-exit-fixes after versioning.  */
  
if (cond_expr_stmt_list)
  {
cond_exp_gsi = gsi_last_bb (condition_bb);
gsi_insert_seq_before (&cond_exp_gsi, cond_expr_stmt_list,
 GSI_SAME_STMT);
  }
+   update_ssa (TODO_update_ssa);
  }
Index: gcc/testsuite/gcc.dg/torture/pr56778.c
===
*** gcc/testsuite/gcc.dg/torture/pr56778.c  (revision 0)
--- gcc/testsuite/gcc.dg/torture/pr56778.c  (working copy)
***
*** 0 
--- 1,14 
+ /* { dg-do compile } */
+ 
+ typedef struct {
+ float a,b,c;
+ } S;
+ 
+ S * arr[100];
+ 
+ void bar (float *in[], int n)
+ {
+   int i;
+   for (i=0; ib;
+ }

[PATCH] Fix PR56812

[Richard Biener]

This fixes PR56812 - the vectorizer TLC got rid of special-casing
interleaving chain members in data dependence analysis.  I re-instantiated
that after having a quick look why dependence analysis doesn't
disambiguate them (it should - known issue, on my TODO list).
And added a testcase to make sure we don't regress.

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

Richard.

2013-04-03  Richard Biener  

PR tree-optimization/56812
* tree-vect-data-refs.c (vect_slp_analyze_data_ref_dependence):
DRs of the same interleaving chain are independent.

* g++.dg/vect/slp-pr56812.cc: New testcase.

Index: gcc/tree-vect-data-refs.c
===
*** gcc/tree-vect-data-refs.c   (revision 197356)
--- gcc/tree-vect-data-refs.c   (working copy)
*** vect_slp_analyze_data_ref_dependence (st
*** 484,489 
--- 484,496 
if (DR_IS_READ (dra) && DR_IS_READ (drb))
  return false;
  
+   /* If dra and drb are part of the same interleaving chain consider
+  them independent.  */
+   if (STMT_VINFO_GROUPED_ACCESS (vinfo_for_stmt (DR_STMT (dra)))
+   && (GROUP_FIRST_ELEMENT (vinfo_for_stmt (DR_STMT (dra)))
+ == GROUP_FIRST_ELEMENT (vinfo_for_stmt (DR_STMT (drb)
+ return false;
+ 
/* Unknown data dependence.  */
if (DDR_ARE_DEPENDENT (ddr) == chrec_dont_know)
  {
Index: gcc/testsuite/g++.dg/vect/slp-pr56812.cc
===
*** gcc/testsuite/g++.dg/vect/slp-pr56812.cc(revision 0)
--- gcc/testsuite/g++.dg/vect/slp-pr56812.cc(working copy)
***
*** 0 
--- 1,20 
+ /* { dg-do compile } */
+ /* { dg-require-effective-target vect_float } */
+ /* { dg-options "-O3 -funroll-loops -fdump-tree-slp-details" } */
+ 
+ class mydata {
+ public:
+ mydata() {Set(-1.0);}
+ void Set (float);
+ static int upper() {return 8;}
+ float data[8];
+ };
+ 
+ void mydata::Set (float x)
+ {
+   for (int i=0; i

4.7 backports

[Jakub Jelinek]

Hi!

I've backported, bootstrapped/regtested and committed the following two
patches to 4.7 branch.

Jakub
2013-04-03  Jakub Jelinek  

Backported from mainline
2013-03-05  Jakub Jelinek  

PR debug/56510
* cfgexpand.c (expand_debug_parm_decl): Call copy_rtx on incoming.
(avoid_complex_debug_insns): New function.
(expand_debug_locations): Call it.

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

--- gcc/cfgexpand.c (revision 196478)
+++ gcc/cfgexpand.c (revision 196479)
@@ -2622,6 +2622,8 @@ expand_debug_parm_decl (tree decl)
  reg = gen_raw_REG (GET_MODE (reg), OUTGOING_REGNO (REGNO (reg)));
  incoming = replace_equiv_address_nv (incoming, reg);
}
+ else
+   incoming = copy_rtx (incoming);
}
 #endif
 
@@ -2637,7 +2639,7 @@ expand_debug_parm_decl (tree decl)
  || (GET_CODE (XEXP (incoming, 0)) == PLUS
  && XEXP (XEXP (incoming, 0), 0) == virtual_incoming_args_rtx
  && CONST_INT_P (XEXP (XEXP (incoming, 0), 1)
-return incoming;
+return copy_rtx (incoming);
 
   return NULL_RTX;
 }
@@ -3704,6 +3706,56 @@ expand_debug_source_expr (tree exp)
   return op0;
 }
 
+/* Ensure INSN_VAR_LOCATION_LOC (insn) doesn't have unbound complexity.
+   Allow 4 levels of rtl nesting for most rtl codes, and if we see anything
+   deeper than that, create DEBUG_EXPRs and emit DEBUG_INSNs before INSN.  */
+
+static void
+avoid_complex_debug_insns (rtx insn, rtx *exp_p, int depth)
+{
+  rtx exp = *exp_p;
+
+  if (exp == NULL_RTX)
+return;
+
+  if ((OBJECT_P (exp) && !MEM_P (exp)) || GET_CODE (exp) == CLOBBER)
+return;
+
+  if (depth == 4)
+{
+  /* Create DEBUG_EXPR (and DEBUG_EXPR_DECL).  */
+  rtx dval = make_debug_expr_from_rtl (exp);
+
+  /* Emit a debug bind insn before INSN.  */
+  rtx bind = gen_rtx_VAR_LOCATION (GET_MODE (exp),
+  DEBUG_EXPR_TREE_DECL (dval), exp,
+  VAR_INIT_STATUS_INITIALIZED);
+
+  emit_debug_insn_before (bind, insn);
+  *exp_p = dval;
+  return;
+}
+
+  const char *format_ptr = GET_RTX_FORMAT (GET_CODE (exp));
+  int i, j;
+  for (i = 0; i < GET_RTX_LENGTH (GET_CODE (exp)); i++)
+switch (*format_ptr++)
+  {
+  case 'e':
+   avoid_complex_debug_insns (insn, &XEXP (exp, i), depth + 1);
+   break;
+
+  case 'E':
+  case 'V':
+   for (j = 0; j < XVECLEN (exp, i); j++)
+ avoid_complex_debug_insns (insn, &XVECEXP (exp, i, j), depth + 1);
+   break;
+
+  default:
+   break;
+  }
+}
+
 /* Expand the _LOCs in debug insns.  We run this after expanding all
regular insns, so that any variables referenced in the function
will have their DECL_RTLs set.  */
@@ -3724,7 +3776,7 @@ expand_debug_locations (void)
 if (DEBUG_INSN_P (insn))
   {
tree value = (tree)INSN_VAR_LOCATION_LOC (insn);
-   rtx val;
+   rtx val, prev_insn, insn2;
enum machine_mode mode;
 
if (value == NULL_TREE)
@@ -3753,6 +3805,9 @@ expand_debug_locations (void)
  }
 
INSN_VAR_LOCATION_LOC (insn) = val;
+   prev_insn = PREV_INSN (insn);
+   for (insn2 = insn; insn2 != prev_insn; insn2 = PREV_INSN (insn2))
+ avoid_complex_debug_insns (insn2, &INSN_VAR_LOCATION_LOC (insn2), 0);
   }
 
   flag_strict_aliasing = save_strict_alias;
--- gcc/testsuite/gcc.dg/pr56510.c  (revision 0)
+++ gcc/testsuite/gcc.dg/pr56510.c  (revision 196479)
@@ -0,0 +1,37 @@
+/* PR debug/56510 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -g" } */
+
+struct S { unsigned long s1; void **s2[0]; };
+void **a, **b, **c, **d, **e, **f;
+
+static void **
+baz (long x, long y)
+{
+  void **s = f;
+  *f = (void **) (y << 8 | (x & 0xff));
+  f += y + 1;
+  return s;
+}
+
+void bar (void);
+void
+foo (void)
+{
+  void **g = b[4];
+  a = b[2];
+  b = b[1];
+  g[2] = e;
+  void **h
+= ((void **)
+   
a)[1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][66];
+  void **i = ((struct S *) h)->s2[4];
+  d = baz (4, 3);
+  d[1] = b;
+  d[2] = a;
+  d[3] = bar;
+  b = d;
+  g[1] = i[2];
+  a = g;
+  ((void (*) (void)) (i[1])) ();
+}
2013-04-03  Jakub Jelinek  

Backported from mainline
2013-03-06  Jakub Jelinek  

PR tree-optimization/56539
* tree-tailcall.c (adjust_return_value_with_ops): Use GSI_SAME_STMT
instead of GSI_CONTINUE_LINKING as last argument to
force_gimple_operand_gsi.  Adjust function comment.

* gcc.c-torture/compile/pr56539.c: New test.

--- gcc/tree-tailcall.c (revision 196510)
+++ gcc/tree-tailcall.c (revision 196511)
@@ -601,8 +601,8 @@ add_successor_phi_arg (edge e, tree var,
 }
 
 /* Creates a GIMPLE statement which computes the operation specified by
-   CODE, OP0 and OP1 to a new variable with name LABEL and inserts the
-   statement in the positio

Re: patch to fix constant math - 4th patch - the wide-int class - patch ping for the next stage 1

[Richard Biener]

On Tue, Apr 2, 2013 at 7:35 PM, Kenneth Zadeck  wrote:
> Yes, I agree that you win the challenge that it can be done.What you
> have always failed to address is why anyone would want to do this.  Or how
> this would at all be desirable.But I completely agree that from a purely
> abstract point of view you can add a storage model.
>
> Now here is why we REALLY do not want to go down this road:
>
> 1)  The following comment from your earlier mail is completely wrong
>
>
>> +#ifdef NEW_REP_FOR_INT_CST
>> +  /* This is the code once the tree level is converted.  */
>> +  wide_int result;
>> +  int i;
>> +
>> +  tree type = TREE_TYPE (tcst);
>> +
>> +  result.bitsize = GET_MODE_BITSIZE (TYPE_MODE (type));
>> +  result.precision = TYPE_PRECISION (type);
>> +  result.len = TREE_INT_CST_LEN (tcst);
>> +  for (i = 0; i < result.len; i++)
>> +result.val[i] = TREE_INT_CST_ELT (tcst, i);
>> +
>> +  return result;
>> +#else
>
>
>> this also shows the main reason I was asking for storage abstraction.
>> The initialization from tree is way too expensive.
>
>
> In almost all cases, constants will fit in a single HWI.  Thus, the only
> thing that you are copying is the length and a single HWI. So you are
> dragging in a lot of machinery just to save these two copies?   Certainly
> there has to be more to it than that.

In the end you will have a variable-size storage in TREE_INT_CST thus
you will have at least to emit _code_ copying over meta-data and data
from the tree representation to the wide-int (similar for RTX CONST_DOUBLE/INT).
I'm objecting to the amount of code you emit and agree that the runtime
cost is copying the meta-data (hopefully optimizable via CSE / SRA)
and in most cases one (or two) iterations of the loop copying the data
(not optimizable).

> 2)  You present this as if the implementor actually should care about the
> implementation and you give 3 alternatives:  the double_int, the current
> one, and HWI. We have tried to make it so that the client should not
> care.   Certainly in my experience here, I have not found a place to care.

Well, similar as for the copying overhead for tree your approach requires
overloading operations for HOST_WIDE_INT operands to be able to
say wi + 1 (which is certainly desirable), or the overhead of using
wide_int_one ().

> In my opinion double_int needs to go away.  That is the main thrust of my
> patches.   There is no place in a compiler for an abi that depends on
> constants fitting into 2 two words whose size is defined by the host.

That's true.  I'm not arguing to preserve "double-int" - I'm arguing to
preserve a way to ask for an integer type on the host with (at least)
N bits.  Almost all double-int users really ask for an integer type on the
host that has at least as many bits as the pointer representation (or
word_mode) on
the target (we do have HOST_WIDEST_INT == 32bits for 64bit pointer
targets).  No double-int user specifically wants 2 * HOST_WIDE_INT
precision - that is just what happens to be there.  Thus I am providing
a way to say get me a host integer with at least N bits (VRP asks for
this, for example).

What I was asking for is that whatever can provide the above should share
the functional interface with wide-int (or the othert way around).  And I
was claiming that wide-int is too fat, because current users of double-int
eventually store double-ints permanently.

> This is not a beauty contest argument, we have public ports are beginning to
> use modes that are larger than two x86-64 HWIs and i have a private port
> that has such modes and it is my experience that any pass that uses this
> interface has one of three behaviors: it silently gets the wrong answer, it
> ices, or it fails to do the transformation.  If we leave double_int as an
> available option, then any use of it potentially will have one of these
> three behaviors.  And so one of my strong objections to this direction is
> that i do not want to fight this kind of bug for the rest of my life.
> Having a single storage model that just always works is in my opinion a
> highly desirable option.  What you have never answered in a concrete manner
> is, if we decide to provide this generality, what it would be used for.
> There is no place in a portable compiler where the right answer for every
> target is two HOST wide integers.
>
> However, i will admit that the HWI option has some merits.   We try to
> address this in our implementation by dividing what is done inline in
> wide-int.h to the cases that fit in an HWI and then only drop into the heavy
> code in wide-int.c if mode is larger (which it rarely will be).   However, a
> case could be made that for certain kinds of things like string lengths and
> such, we could use another interface or as you argue, a different storage
> model with the same interface.   I just do not see that the cost of the
> conversion code is really going to show up on anyone's radar.

What's the issue with abstracting away the model so a fix

Re: patch to fix constant math - first small patch - patch ping for the next stage 1

[Richard Biener]

On Tue, Apr 2, 2013 at 9:08 PM, Kenneth Zadeck  wrote:
> this time for sure.

Almost ...

diff --git a/gcc/hwint.c b/gcc/hwint.c
index 330b42c..92d54a3 100644
--- a/gcc/hwint.c
+++ b/gcc/hwint.c
@@ -204,3 +204,35 @@ least_common_multiple (HOST_WIDE_INT a, HOST_WIDE_INT b)
 {
   return mul_hwi (abs_hwi (a) / gcd (a, b), abs_hwi (b));
 }
+
+#ifndef ENABLE_CHECKING

#ifdef ENABLE_CHECKING

+/* Sign extend SRC starting from PREC.  */
+
+HOST_WIDE_INT
+sext_hwi (HOST_WIDE_INT src, unsigned int prec)
+{
+  gcc_checking_assert (prec <= HOST_BITS_PER_WIDE_INT);
+

Ok with that change.  (maybe catch one random use of the pattern
in code and use the helpers - that would have catched this issue)

Thanks,
Richard.



> kenny
>
> On 04/02/2013 10:54 AM, Richard Biener wrote:
>>
>> On Tue, Apr 2, 2013 at 3:49 PM, Kenneth Zadeck 
>> wrote:
>>>
>>> Richard,
>>>
>>> did everything that you asked here.  bootstrapped and regtested on
>>> x86-64.
>>> ok to commit?
>>
>> diff --git a/gcc/hwint.c b/gcc/hwint.c
>> index 330b42c..7e5b85c 100644
>> --- a/gcc/hwint.c
>> +++ b/gcc/hwint.c
>> @@ -204,3 +204,33 @@ least_common_multiple (HOST_WIDE_INT a, HOST_WIDE_INT
>> b)
>>   {
>> return mul_hwi (abs_hwi (a) / gcd (a, b), abs_hwi (b));
>>   }
>> +
>> +#ifndef ENABLE_CHECKING
>> +/* Sign extend SRC starting from PREC.  */
>> +
>> +HOST_WIDE_INT
>> +sext_hwi (HOST_WIDE_INT src, unsigned int prec)
>>
>> this should go to hwint.h, and without the masking of prec.
>> while ...
>>
>> diff --git a/gcc/hwint.h b/gcc/hwint.h
>> index da62fad..9dddf05 100644
>> --- a/gcc/hwint.h
>> +++ b/gcc/hwint.h
>> @@ -276,4 +316,42 @@ extern HOST_WIDE_INT pos_mul_hwi (HOST_WIDE_INT,
>> HOST_WIDE_INT);
>>   extern HOST_WIDE_INT mul_hwi (HOST_WIDE_INT, HOST_WIDE_INT);
>>   extern HOST_WIDE_INT least_common_multiple (HOST_WIDE_INT,
>> HOST_WIDE_INT);
>>
>> +/* Sign extend SRC starting from PREC.  */
>> +
>> +#ifdef ENABLE_CHECKING
>> +extern HOST_WIDE_INT sext_hwi (HOST_WIDE_INT, unsigned int);
>> +#else
>> +static inline HOST_WIDE_INT
>> +sext_hwi (HOST_WIDE_INT src, unsigned int prec)
>> +{
>> +  gcc_checking_assert (prec <= HOST_BITS_PER_WIDE_INT);
>>
>> this should go to hwint.c (also without masking prec).
>>
>> Richard.
>>
>>
>>
>>
>>> kenny
>>>
>>>
>>> On 04/02/2013 05:38 AM, Richard Biener wrote:

 On Sun, Mar 31, 2013 at 7:51 PM, Kenneth Zadeck
  wrote:
>
> richard,
>
> I was able to add everything except for the checking asserts.While
> I
> think that this is a reasonable idea, it is difficult to add that to a
> function that is defined in hwint.h because of circular includes.   I
> could
> move this another file (though this appears to be the logical correct
> place
> for it), or we can do without the asserts.
>
> The context is that [sz]ext_hwi is that are used are over the compiler
> but
> are generally written out long.   The wide-int class uses them also,
> but
> wide-int did not see like the right place for them to live and i
> believe
> that you suggested that i move them.
>
> ok to commit, or do you have a suggested resolution to the assert
> issue?

 Yes, do

 #ifdef ENABLE_CHECKING
 extern HOST_WIDE_INT sext_hwi (HOST_WIDE_INT, unsigned int);
 #else
 +/* Sign extend SRC starting from PREC.  */
 +
 +static inline HOST_WIDE_INT
 +sext_hwi (HOST_WIDE_INT src, unsigned int prec)
 +{
 +  if (prec == HOST_BITS_PER_WIDE_INT)
 +return src;
 +  else
 +{
   int shift = HOST_BITS_PER_WIDE_INT - prec;
 +  return (src << shift) >> shift;
 +}
 +}
 #endif

 and for ENABLE_CHECKING only provide an out-of-line implementation
 in hwint.c.  That's how we did it with abs_hwi (well, we just do not
 provide
 an inline variant there - that's another possibility).

 Note that hwint.h is always included after config.h so the
 ENABLE_CHECKING
 definition should be available.

 Richard.

> kenny
>
>
> On 03/27/2013 10:13 AM, Richard Biener wrote:
>>
>> On Wed, Feb 27, 2013 at 1:22 AM, Kenneth Zadeck
>>  wrote:
>>>
>>> Here is the first of my wide int patches with joseph's comments and
>>> the
>>> patch rot removed.
>>>
>>> I would like to get these pre approved for the next stage 1.
>>
>> +  int shift = HOST_BITS_PER_WIDE_INT - (prec &
>> (HOST_BITS_PER_WIDE_INT - 1));
>>
>> I think this should gcc_checking_assert that prec is not out of range
>> (any reason why prec is signed int and not unsigned int?) rather than
>> ignore bits in prec.
>>
>> +static inline HOST_WIDE_INT
>> +zext_hwi (HOST_WIDE_INT src, int prec)
>> +{
>> +  if (prec == HOST_BITS_PER_WIDE_INT)
>> +return src;
>> +  else
>> +return src & (((HOST_WIDE_INT)1
>> +  << (prec & (HOST_BITS_PER_WIDE_INT - 1

Re: [PATCH GCC]Fix typo in definition of macro AUTO_INC_DEC in rtl.h

[Richard Biener]

On Wed, Apr 3, 2013 at 3:38 AM, Bin Cheng  wrote:
> Hi,
> When I look into code of auto-inc-dec.c in GCC, I found this typo in rtl.h,
> as
> #if (defined (HAVE_PRE_INCREMENT) || defined (HAVE_PRE_DECREMENT) \
>  || defined (HAVE_POST_INCREMENT) || defined (HAVE_POST_DECREMENT) \
>  || defined (HAVE_PRE_MODIFY_DISP) || defined (HAVE_PRE_MODIFY_DISP) \
>  || defined (HAVE_PRE_MODIFY_REG) || defined (HAVE_POST_MODIFY_REG))
> #define AUTO_INC_DEC
> #endif
>
> The 2nd HAVE_PRE_MODIFY_DISP should be HAVE_POST_MODIFY_DISP.
>
> Tested on Thumb2(cortex-m3), no failure introduced. Since the pass is
> disabled on x86/x86_64, so I did not run regression test on it.

Ok.

Thanks,
Richard.

> Thanks.
>
> 2013-04-03  Bin Cheng  
>
> * rtl.h (AUTO_INC_DEC): Fix typo of HAVE_POST_MODIFY_DISP.
>
>
>

[PATCH][4.7] Fix PR56501

[Richard Biener]

The following obvious fix fixes the ICE in PR56501.

Boostrap / regtest pending on x86_64-unknown-linux-gnu.

Richard.

2013-04-03  Richard Biener  

PR tree-optimization/56501
* tree-switch-conversion.c (check_process_case): Properly
handle !single_succ_p case.

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

Index: gcc/tree-switch-conversion.c
===
--- gcc/tree-switch-conversion.c(revision 197348)
+++ gcc/tree-switch-conversion.c(working copy)
@@ -283,7 +283,12 @@ check_process_case (tree cs)
  return false;
}
 
-  e = single_succ_edge (label_bb);
+  if (!single_succ_p (label_bb))
+   {
+ info.reason
+   = "  Bad case - a non-final BB without a single successor\n";
+ return false;
+   }
   following_bb = single_succ (label_bb);
 }
 
Index: gcc/testsuite/gcc.dg/torture/pr56501.c
===
--- gcc/testsuite/gcc.dg/torture/pr56501.c  (revision 0)
+++ gcc/testsuite/gcc.dg/torture/pr56501.c  (working copy)
@@ -0,0 +1,27 @@
+/* { dg-do compile } */
+/* { dg-options "-w" } */
+
+int a;
+void try_help () __attribute__ ((__noreturn__));
+void try_help ()
+{
+}
+
+int main ()
+{
+  switch (a)
+{
+  case '1':
+  case '2':
+  case '3':
+  case '4':
+  case '5':
+  case '6':
+  case '7':
+  case '8':
+  case '9':
+ break;
+  default:
+ try_help ();
+}
+}

Re: [PATCH, generic] Support printing of escaped curly braces and vertical bar in assembler output

[Maksim Kuznetsov]

Thank you for your feedback!

> For '}' case, can you simply just add
>
> /* Skip over any character after a percent sign.  */
> if (*p == '%' && *(p + 1))
> {
>   p += 2;
>   continue;
> }
>
> without changing the do-while loop to the while loop?

Loop condition (*p++ != '}') must be moved to loop body for it to not
execute after "continue" (we just want to skip over % with following
character without any other increments or checks). Although, loop form
doesn't matter so I changed it back to do-while.

> That's not the same thing though.  Maksim's code is correct,
> although it could certainly be written more clearly.
> Maybe something like
>
>   if (*p == '%')
> p++;
>   if (*p)
> p++;

Fixed.


I also noticed that previous patch broke intel (or any alternative)
syntax. This was because the original loop:

while (*p && *p != '}' && *p++ != '|');

incremented p after '|' is found, but loop in my patch didn't:

while (*p && *p != '}' && *p != '|')
  p += (*p == '%' && *(p + 1)) ? 2 : 1;

I fixed it too.

Updated patch is attached. Could you please have a look?

ChangeLog:

2013-04-03  Maxim Kuznetsov  

* final.c (do_assembler_dialects): Don't handle curly braces
escaped by % as dialect delimiters.
* config/i386/i386.c (ix86_print_operand_punct_valid_p): Add '{' and
'}'.
(ix86_print_operand): Handle '{' and '}'.

testsuite/ChangeLog:

2013-04-03  Maxim Kuznetsov  

* gcc.target/i386/asm-dialect-2.c: New testcase.

--
Maxim Kuznetsov


curly_braces_20130403.patch
Description: Binary data

[PATCH] testcase for PR56407

[Richard Biener]

The testcase no longer fails on the 4.8 branch and trunk,
committed there so we do not regress.

Richard.

2013-04-03  Richard Biener  

PR tree-optimization/56407
* gcc.dg/torture/pr56407.c: New testcase.

Index: gcc/testsuite/gcc.dg/torture/pr56407.c
===
--- gcc/testsuite/gcc.dg/torture/pr56407.c  (revision 0)
+++ gcc/testsuite/gcc.dg/torture/pr56407.c  (working copy)
@@ -0,0 +1,48 @@
+/* { dg-do run } */
+
+extern void abort(void);
+extern int rand(void);
+
+static void copy(int *r,int *a,int na)
+{
+  int i;
+  for( i = 0 ; i < na ; i++ )
+r[i] = a[i];
+}
+
+static void foo(int *a,int na)
+{
+  int i;
+  for( i = 0 ; i < na ; i++ )
+a[i] = rand();
+}
+
+static int cmp(int *a,int *b,int n)
+{
+  int i;
+  for( i = 0 ; i < n ; i++ )
+if ( a[i] != b[i] )
+  return -1;
+  return 0;
+}
+
+void __attribute__((noinline,noclone))
+test(int sz,int comm)
+{
+  int j,n;
+  int v[64],w[64];
+  for( j = 1 ; j <= sz ; j++ )
+{
+  n = (2 * j - 1) * (2 * j - 1);
+  foo(w,n);
+  copy(v,w,n);
+  if ( comm )
+   if ( cmp(v,w,n) ) abort ();
+}
+}
+
+int main()
+{
+  test(2,1);
+  return 0;
+}

RE: [patch] Stop using JUMP_INSN for jump table data

[Kyrylo Tkachov]

Hi Steven,

> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Steven Bosscher
> Sent: 30 March 2013 13:10
> To: Jeff Law
> Cc: GCC Patches
> Subject: Re: [patch] Stop using JUMP_INSN for jump table data
> 
> On Sat, Mar 30, 2013 at 2:02 PM, Jeff Law wrote:
> 
> > OK.
> 
> Thanks for the quick review!
> 
> > Note that on at least one target, the jump table data is actual code
> (PA).
> > I don't think it makes a difference at this stage, but please keep
> that in
> > mind as you continue this work.
> 
> Right, the PA "explodes" table jumps to individual jumps in
> pa_reorg(). I actually tested on PA too (on my US$15 bargain HP
> visualize J5600 workstation :-) and things work just fine. I'm more
> concerned about some of the back ends that use
> {next,prev}_{real,active}_insn to find jump table data after a
> JUMP_INSN instead of using tablejump_p, but we'll see and I'll
> obviously be on the hook to fix any fall-out.

Unfortunately, this patch breaks arm-none-eabi, arm-none-linux-gnueabi(hf)
and aarch64-none-elf.
See PR56809 for more info. GCC ICEs when building newlib and produces
invalid assembly when building glibc.

Any ideas?

> 
> Ciao!
> Steven

Thanks,
Kyrill

[PATCH] Testcase for PR55964 from PR56097

[Richard Biener]

Slightly different and less arcane.

Tested on x86_64-unknown-linux-gnu, applied to trunk and branch.

Richard.

2013-04-03  Richard Biener  

PR tree-optimization/55964
* gcc.dg/torture/pr55964-2.c: New testcase.

Index: gcc/testsuite/gcc.dg/torture/pr55964-2.c
===
--- gcc/testsuite/gcc.dg/torture/pr55964-2.c(revision 0)
+++ gcc/testsuite/gcc.dg/torture/pr55964-2.c(working copy)
@@ -0,0 +1,21 @@
+/* { dg-do compile } */
+/* { dg-options "-ftree-loop-distribution -funswitch-loops" } */
+
+struct test_struct {
+int a, b[10], c[10], d[10];
+};
+
+extern struct test_struct* new_struct;
+
+void testfunc(struct test_struct* old_struct)
+{
+  int i;
+  for (i = 0; i < 10; ++i)
+{
+  new_struct->b[i] = old_struct ? old_struct->b[i] : -1;
+  new_struct->c[i] = old_struct ? old_struct->c[i] : 0;
+  new_struct->d[i] = old_struct ? old_struct->d[i] : 0;
+}
+  if (old_struct)
+old_struct->a++;
+}

Re: [PATCH, ARM] ARM Linux kernel-assisted atomic operation helpers vs. libcall argument promotion

[Julian Brown]

On Fri, 15 Mar 2013 18:16:48 +
Julian Brown  wrote:

> Hi,
> 
> At present, the libcall helpers implementing atomic operations
> (__sync_val_compare_and_swap_X) for char and short types suffer from
> a type mismatch. This is leading to test failures, i.e.:
> 
> FAIL: gcc.dg/atomic-compare-exchange-1.c execution test
> FAIL: gcc.dg/atomic-compare-exchange-2.c execution test

Ping?

Julian

Re: patch to fix constant math - first small patch - patch ping for the next stage 1

[Kenneth Zadeck]

yes, i had caught that when i merged it in with the patches that used 
it, is it ok aside from that?

kenny
On 04/03/2013 05:32 AM, Richard Biener wrote:

On Tue, Apr 2, 2013 at 9:08 PM, Kenneth Zadeck  wrote:

this time for sure.

Almost ...

diff --git a/gcc/hwint.c b/gcc/hwint.c
index 330b42c..92d54a3 100644
--- a/gcc/hwint.c
+++ b/gcc/hwint.c
@@ -204,3 +204,35 @@ least_common_multiple (HOST_WIDE_INT a, HOST_WIDE_INT b)
  {
return mul_hwi (abs_hwi (a) / gcd (a, b), abs_hwi (b));
  }
+
+#ifndef ENABLE_CHECKING

#ifdef ENABLE_CHECKING

+/* Sign extend SRC starting from PREC.  */
+
+HOST_WIDE_INT
+sext_hwi (HOST_WIDE_INT src, unsigned int prec)
+{
+  gcc_checking_assert (prec <= HOST_BITS_PER_WIDE_INT);
+

Ok with that change.  (maybe catch one random use of the pattern
in code and use the helpers - that would have catched this issue)

Thanks,
Richard.




kenny

On 04/02/2013 10:54 AM, Richard Biener wrote:

On Tue, Apr 2, 2013 at 3:49 PM, Kenneth Zadeck 
wrote:

Richard,

did everything that you asked here.  bootstrapped and regtested on
x86-64.
ok to commit?

diff --git a/gcc/hwint.c b/gcc/hwint.c
index 330b42c..7e5b85c 100644
--- a/gcc/hwint.c
+++ b/gcc/hwint.c
@@ -204,3 +204,33 @@ least_common_multiple (HOST_WIDE_INT a, HOST_WIDE_INT
b)
   {
 return mul_hwi (abs_hwi (a) / gcd (a, b), abs_hwi (b));
   }
+
+#ifndef ENABLE_CHECKING
+/* Sign extend SRC starting from PREC.  */
+
+HOST_WIDE_INT
+sext_hwi (HOST_WIDE_INT src, unsigned int prec)

this should go to hwint.h, and without the masking of prec.
while ...

diff --git a/gcc/hwint.h b/gcc/hwint.h
index da62fad..9dddf05 100644
--- a/gcc/hwint.h
+++ b/gcc/hwint.h
@@ -276,4 +316,42 @@ extern HOST_WIDE_INT pos_mul_hwi (HOST_WIDE_INT,
HOST_WIDE_INT);
   extern HOST_WIDE_INT mul_hwi (HOST_WIDE_INT, HOST_WIDE_INT);
   extern HOST_WIDE_INT least_common_multiple (HOST_WIDE_INT,
HOST_WIDE_INT);

+/* Sign extend SRC starting from PREC.  */
+
+#ifdef ENABLE_CHECKING
+extern HOST_WIDE_INT sext_hwi (HOST_WIDE_INT, unsigned int);
+#else
+static inline HOST_WIDE_INT
+sext_hwi (HOST_WIDE_INT src, unsigned int prec)
+{
+  gcc_checking_assert (prec <= HOST_BITS_PER_WIDE_INT);

this should go to hwint.c (also without masking prec).

Richard.





kenny


On 04/02/2013 05:38 AM, Richard Biener wrote:

On Sun, Mar 31, 2013 at 7:51 PM, Kenneth Zadeck
 wrote:

richard,

I was able to add everything except for the checking asserts.While
I
think that this is a reasonable idea, it is difficult to add that to a
function that is defined in hwint.h because of circular includes.   I
could
move this another file (though this appears to be the logical correct
place
for it), or we can do without the asserts.

The context is that [sz]ext_hwi is that are used are over the compiler
but
are generally written out long.   The wide-int class uses them also,
but
wide-int did not see like the right place for them to live and i
believe
that you suggested that i move them.

ok to commit, or do you have a suggested resolution to the assert
issue?

Yes, do

#ifdef ENABLE_CHECKING
extern HOST_WIDE_INT sext_hwi (HOST_WIDE_INT, unsigned int);
#else
+/* Sign extend SRC starting from PREC.  */
+
+static inline HOST_WIDE_INT
+sext_hwi (HOST_WIDE_INT src, unsigned int prec)
+{
+  if (prec == HOST_BITS_PER_WIDE_INT)
+return src;
+  else
+{
   int shift = HOST_BITS_PER_WIDE_INT - prec;
+  return (src << shift) >> shift;
+}
+}
#endif

and for ENABLE_CHECKING only provide an out-of-line implementation
in hwint.c.  That's how we did it with abs_hwi (well, we just do not
provide
an inline variant there - that's another possibility).

Note that hwint.h is always included after config.h so the
ENABLE_CHECKING
definition should be available.

Richard.


kenny


On 03/27/2013 10:13 AM, Richard Biener wrote:

On Wed, Feb 27, 2013 at 1:22 AM, Kenneth Zadeck
 wrote:

Here is the first of my wide int patches with joseph's comments and
the
patch rot removed.

I would like to get these pre approved for the next stage 1.

+  int shift = HOST_BITS_PER_WIDE_INT - (prec &
(HOST_BITS_PER_WIDE_INT - 1));

I think this should gcc_checking_assert that prec is not out of range
(any reason why prec is signed int and not unsigned int?) rather than
ignore bits in prec.

+static inline HOST_WIDE_INT
+zext_hwi (HOST_WIDE_INT src, int prec)
+{
+  if (prec == HOST_BITS_PER_WIDE_INT)
+return src;
+  else
+return src & (((HOST_WIDE_INT)1
+  << (prec & (HOST_BITS_PER_WIDE_INT - 1))) - 1);
+}

likewise.  Also I'm not sure I agree about the signedness of the
result
/
src.
zext_hwi (-1, HOST_BITS_PER_WIDE_INT) < 0 is true which is odd.

The patch misses context of uses, so I'm not sure what the above
functions
are intended to do.

Richard.


On 10/05/2012 08:14 PM, Joseph S. Myers wrote:

On Fri, 5 Oct 2012, Kenneth Zadeck wrote:


+# define HOST_HALF_WIDE_INT_PRINT "h"

This may cause problems on hosts not supporting %hd (MinGW?), and
there's
no real need for using "h" here give

RE: [PATCH GCC]Fix typo in definition of macro AUTO_INC_DEC in rtl.h

[Bin Cheng]

> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Wednesday, April 03, 2013 5:36 PM
> To: Bin Cheng
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH GCC]Fix typo in definition of macro AUTO_INC_DEC in
rtl.h
> 
> On Wed, Apr 3, 2013 at 3:38 AM, Bin Cheng  wrote:
> > Hi,
> > When I look into code of auto-inc-dec.c in GCC, I found this typo in
> > rtl.h, as #if (defined (HAVE_PRE_INCREMENT) || defined
> > (HAVE_PRE_DECREMENT) \
> >  || defined (HAVE_POST_INCREMENT) || defined (HAVE_POST_DECREMENT) \
> >  || defined (HAVE_PRE_MODIFY_DISP) || defined (HAVE_PRE_MODIFY_DISP)
\
> >  || defined (HAVE_PRE_MODIFY_REG) || defined
> > (HAVE_POST_MODIFY_REG)) #define AUTO_INC_DEC #endif
> >
> > The 2nd HAVE_PRE_MODIFY_DISP should be HAVE_POST_MODIFY_DISP.
> >
> > Tested on Thumb2(cortex-m3), no failure introduced. Since the pass is
> > disabled on x86/x86_64, so I did not run regression test on it.
> 
> Ok.
> 

Committed as 197398.

Thanks.

Re: [Patch, committed, wwwdocs] Re: Typo in GCC 4.8 release page

[Kartik Singhal]

On Thu, Mar 28, 2013 at 2:18 PM, Tobias Burnus  wrote:
> Foone Turing wrote:
>>
>> This page: http://gcc.gnu.org/gcc-4.8/
>> under "release history" says GCC 4.8 was released on March 22, 2012.
>> This should be 2013, not 2012.
>
>
> Thanks for the report! I have corrected it now.


Same typo at GCC Timeline page:
http://gcc.gnu.org/develop.html#timeline GCC 4.8.0 release
(2012-03-22) should be 2013.

--
Kartik
http://k4rtik.wordpress.com/

Re: [patch] C++11: Observers for the three 'handler functions'

[Paolo Carlini]

On 04/03/2013 02:09 AM, Jonathan Wakely wrote:

This patch implements
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3189.htm
Thanks Jon. I'm seeing abi_check fails which seem related. Could you 
please double check?


Thanks again,
Paolo.

Re: [patch] C++11: Observers for the three 'handler functions'

[Jonathan Wakely]

On 3 April 2013 12:45, Paolo Carlini wrote:
> On 04/03/2013 02:09 AM, Jonathan Wakely wrote:
>>
>> This patch implements
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3189.htm
>
> Thanks Jon. I'm seeing abi_check fails which seem related. Could you please
> double check?

Ah sorry, I didn't commit the change to add GLIBCXX_3.4.19 to the
known_versions.  I'll do that later today.

Re: [patch] C++11: Observers for the three 'handler functions'

[Paolo Carlini]

On 04/03/2013 01:53 PM, Jonathan Wakely wrote:

On 3 April 2013 12:45, Paolo Carlini wrote:

On 04/03/2013 02:09 AM, Jonathan Wakely wrote:

This patch implements
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3189.htm

Thanks Jon. I'm seeing abi_check fails which seem related. Could you please
double check?

Ah sorry, I didn't commit the change to add GLIBCXX_3.4.19 to the
known_versions.  I'll do that later today.

Yeah, but I'm afraid isn't enough. Thanks for looking into it.

Paolo.

Re: patch to fix constant math - 4th patch - the wide-int class - patch ping for the next stage 1

[Kenneth Zadeck]

On 04/03/2013 05:17 AM, Richard Biener wrote:


In the end you will have a variable-size storage in TREE_INT_CST thus
you will have at least to emit _code_ copying over meta-data and data
from the tree representation to the wide-int (similar for RTX CONST_DOUBLE/INT).
I'm objecting to the amount of code you emit and agree that the runtime
cost is copying the meta-data (hopefully optimizable via CSE / SRA)
and in most cases one (or two) iterations of the loop copying the data
(not optimizable).
i did get rid of the bitsize in the wide-int patch so at this point the 
meta data is the precision and the len.
not really a lot here.   As usual we pay a high price in gcc for not 
pushing the tree rep down into the rtl level, then it would have been 
acceptable to have the tree type bleed into the wide-int code.




2)  You present this as if the implementor actually should care about the
implementation and you give 3 alternatives:  the double_int, the current
one, and HWI. We have tried to make it so that the client should not
care.   Certainly in my experience here, I have not found a place to care.

Well, similar as for the copying overhead for tree your approach requires
overloading operations for HOST_WIDE_INT operands to be able to
say wi + 1 (which is certainly desirable), or the overhead of using
wide_int_one ().


In my opinion double_int needs to go away.  That is the main thrust of my
patches.   There is no place in a compiler for an abi that depends on
constants fitting into 2 two words whose size is defined by the host.

That's true.  I'm not arguing to preserve "double-int" - I'm arguing to
preserve a way to ask for an integer type on the host with (at least)
N bits.  Almost all double-int users really ask for an integer type on the
host that has at least as many bits as the pointer representation (or
word_mode) on
the target (we do have HOST_WIDEST_INT == 32bits for 64bit pointer
targets).  No double-int user specifically wants 2 * HOST_WIDE_INT
precision - that is just what happens to be there.  Thus I am providing
a way to say get me a host integer with at least N bits (VRP asks for
this, for example).

What I was asking for is that whatever can provide the above should share
the functional interface with wide-int (or the othert way around).  And I
was claiming that wide-int is too fat, because current users of double-int
eventually store double-ints permanently.
The problem is that, in truth, double int is too fat. 99.something% of 
all constants fit in 1 hwi and that is likely to be true forever (i 
understand that tree vpn may need some thought here).  The rtl level, 
which has, for as long as i have known it, had 2 reps for integer 
constants. So it was relatively easy to slide the CONST_WIDE_INT in.  It 
seems like the right trickery here rather than adding a storage model 
for wide-ints might be a way to use the c++ to invisibly support several 
(and by "several" i really mean 2) classes of TREE_CSTs.





This is not a beauty contest argument, we have public ports are beginning to
use modes that are larger than two x86-64 HWIs and i have a private port
that has such modes and it is my experience that any pass that uses this
interface has one of three behaviors: it silently gets the wrong answer, it
ices, or it fails to do the transformation.  If we leave double_int as an
available option, then any use of it potentially will have one of these
three behaviors.  And so one of my strong objections to this direction is
that i do not want to fight this kind of bug for the rest of my life.
Having a single storage model that just always works is in my opinion a
highly desirable option.  What you have never answered in a concrete manner
is, if we decide to provide this generality, what it would be used for.
There is no place in a portable compiler where the right answer for every
target is two HOST wide integers.

However, i will admit that the HWI option has some merits.   We try to
address this in our implementation by dividing what is done inline in
wide-int.h to the cases that fit in an HWI and then only drop into the heavy
code in wide-int.c if mode is larger (which it rarely will be).   However, a
case could be made that for certain kinds of things like string lengths and
such, we could use another interface or as you argue, a different storage
model with the same interface.   I just do not see that the cost of the
conversion code is really going to show up on anyone's radar.

What's the issue with abstracting away the model so a fixed-size 'len'
is possible?  (let away the argument that this would easily allow an
adaptor to tree)
I have a particularly pessimistic perspective because i have already 
written most of this patch.   It is not that i do not want to change 
that code, it is that i have seen a certain set of mistakes that were 
made and i do not want to fix them more than once.   At the rtl level 
you can see the transition from only supporting 32 bit ints to 
supporting 64 bit

Re: patch to fix constant math - first small patch - patch ping for the next stage 1

[Richard Biener]

On Wed, Apr 3, 2013 at 12:47 PM, Kenneth Zadeck
 wrote:
> yes, i had caught that when i merged it in with the patches that used it, is
> it ok aside from that?

Yes.

Thanks,
Richard.

> kenny
>
> On 04/03/2013 05:32 AM, Richard Biener wrote:
>>
>> On Tue, Apr 2, 2013 at 9:08 PM, Kenneth Zadeck 
>> wrote:
>>>
>>> this time for sure.
>>
>> Almost ...
>>
>> diff --git a/gcc/hwint.c b/gcc/hwint.c
>> index 330b42c..92d54a3 100644
>> --- a/gcc/hwint.c
>> +++ b/gcc/hwint.c
>> @@ -204,3 +204,35 @@ least_common_multiple (HOST_WIDE_INT a, HOST_WIDE_INT
>> b)
>>   {
>> return mul_hwi (abs_hwi (a) / gcd (a, b), abs_hwi (b));
>>   }
>> +
>> +#ifndef ENABLE_CHECKING
>>
>> #ifdef ENABLE_CHECKING
>>
>> +/* Sign extend SRC starting from PREC.  */
>> +
>> +HOST_WIDE_INT
>> +sext_hwi (HOST_WIDE_INT src, unsigned int prec)
>> +{
>> +  gcc_checking_assert (prec <= HOST_BITS_PER_WIDE_INT);
>> +
>>
>> Ok with that change.  (maybe catch one random use of the pattern
>> in code and use the helpers - that would have catched this issue)
>>
>> Thanks,
>> Richard.
>>
>>
>>
>>> kenny
>>>
>>> On 04/02/2013 10:54 AM, Richard Biener wrote:

 On Tue, Apr 2, 2013 at 3:49 PM, Kenneth Zadeck
 
 wrote:
>
> Richard,
>
> did everything that you asked here.  bootstrapped and regtested on
> x86-64.
> ok to commit?

 diff --git a/gcc/hwint.c b/gcc/hwint.c
 index 330b42c..7e5b85c 100644
 --- a/gcc/hwint.c
 +++ b/gcc/hwint.c
 @@ -204,3 +204,33 @@ least_common_multiple (HOST_WIDE_INT a,
 HOST_WIDE_INT
 b)
{
  return mul_hwi (abs_hwi (a) / gcd (a, b), abs_hwi (b));
}
 +
 +#ifndef ENABLE_CHECKING
 +/* Sign extend SRC starting from PREC.  */
 +
 +HOST_WIDE_INT
 +sext_hwi (HOST_WIDE_INT src, unsigned int prec)

 this should go to hwint.h, and without the masking of prec.
 while ...

 diff --git a/gcc/hwint.h b/gcc/hwint.h
 index da62fad..9dddf05 100644
 --- a/gcc/hwint.h
 +++ b/gcc/hwint.h
 @@ -276,4 +316,42 @@ extern HOST_WIDE_INT pos_mul_hwi (HOST_WIDE_INT,
 HOST_WIDE_INT);
extern HOST_WIDE_INT mul_hwi (HOST_WIDE_INT, HOST_WIDE_INT);
extern HOST_WIDE_INT least_common_multiple (HOST_WIDE_INT,
 HOST_WIDE_INT);

 +/* Sign extend SRC starting from PREC.  */
 +
 +#ifdef ENABLE_CHECKING
 +extern HOST_WIDE_INT sext_hwi (HOST_WIDE_INT, unsigned int);
 +#else
 +static inline HOST_WIDE_INT
 +sext_hwi (HOST_WIDE_INT src, unsigned int prec)
 +{
 +  gcc_checking_assert (prec <= HOST_BITS_PER_WIDE_INT);

 this should go to hwint.c (also without masking prec).

 Richard.




> kenny
>
>
> On 04/02/2013 05:38 AM, Richard Biener wrote:
>>
>> On Sun, Mar 31, 2013 at 7:51 PM, Kenneth Zadeck
>>  wrote:
>>>
>>> richard,
>>>
>>> I was able to add everything except for the checking asserts.
>>> While
>>> I
>>> think that this is a reasonable idea, it is difficult to add that to
>>> a
>>> function that is defined in hwint.h because of circular includes.   I
>>> could
>>> move this another file (though this appears to be the logical correct
>>> place
>>> for it), or we can do without the asserts.
>>>
>>> The context is that [sz]ext_hwi is that are used are over the
>>> compiler
>>> but
>>> are generally written out long.   The wide-int class uses them also,
>>> but
>>> wide-int did not see like the right place for them to live and i
>>> believe
>>> that you suggested that i move them.
>>>
>>> ok to commit, or do you have a suggested resolution to the assert
>>> issue?
>>
>> Yes, do
>>
>> #ifdef ENABLE_CHECKING
>> extern HOST_WIDE_INT sext_hwi (HOST_WIDE_INT, unsigned int);
>> #else
>> +/* Sign extend SRC starting from PREC.  */
>> +
>> +static inline HOST_WIDE_INT
>> +sext_hwi (HOST_WIDE_INT src, unsigned int prec)
>> +{
>> +  if (prec == HOST_BITS_PER_WIDE_INT)
>> +return src;
>> +  else
>> +{
>>int shift = HOST_BITS_PER_WIDE_INT - prec;
>> +  return (src << shift) >> shift;
>> +}
>> +}
>> #endif
>>
>> and for ENABLE_CHECKING only provide an out-of-line implementation
>> in hwint.c.  That's how we did it with abs_hwi (well, we just do not
>> provide
>> an inline variant there - that's another possibility).
>>
>> Note that hwint.h is always included after config.h so the
>> ENABLE_CHECKING
>> definition should be available.
>>
>> Richard.
>>
>>> kenny
>>>
>>>
>>> On 03/27/2013 10:13 AM, Richard Biener wrote:

 On Wed, Feb 27, 2013 at 1:22 AM, Kenneth Zadeck
  wrote:
>
> Here is the first of my wide int patches with joseph's comments and
> the
> patch rot removed.
>
>>>

[commit] Fix SPU breakage (Re: [patch] Stop using JUMP_INSN for jump table data)

[Ulrich Weigand]

Steven Bosscher wrote:

> GCC uses fake JUMP_INSNs as placeholders for jump table data. These
> JUMP_INSNs have an ADDR_VEC or ADDR_DIFF_VEC as PATTERN, but they are
> not real instructions and they are not inside basic blocks. This
> results in special-casing JUMP_P insns in various places throughout
> the compiler.
> 
> The attached patch adds a new object, JUMP_TABLE_DATA, to hold jump
> table data. All remaining JUMP_P insns will be real insns, which helps
> simplify things a bit -- or at least make things more intuitive.

This broke the SPU target.  The emit_nop_for_insn routine needs to handle
jump tables as well, but performs operations that now no longer work on
the new JUMP_TABLE_DATA object (in particular getting attributes,
inspecting INSN_LOCATION).

Fix this by handling JUMP_TABLE_DATA separately from real insns.

Tested on spu-elf.  Committed to mainline.

Bye,
Ulrich


ChangeLog:

* config/spu/spu.c (emit_nop_for_insn): Handle JUMP_TABLE_DATA.

Index: gcc/config/spu/spu.c
===
*** gcc/config/spu/spu.c(revision 197352)
--- gcc/config/spu/spu.c(working copy)
*** static struct spu_bb_info *spu_bb_info;
*** 1978,1990 
  /* Emit a nop for INSN such that the two will dual issue.  This assumes
 INSN is 8-byte aligned.  When INSN is inline asm we emit an lnop.
 We check for TImode to handle a MULTI1 insn which has dual issued its
!first instruction.  get_pipe returns -1 for MULTI0, inline asm, or
!ADDR_VEC insns. */
  static void
  emit_nop_for_insn (rtx insn)
  {
int p;
rtx new_insn;
p = get_pipe (insn);
if ((CALL_P (insn) || JUMP_P (insn)) && SCHED_ON_EVEN_P (insn))
  new_insn = emit_insn_after (gen_lnop (), insn);
--- 1978,1999 
  /* Emit a nop for INSN such that the two will dual issue.  This assumes
 INSN is 8-byte aligned.  When INSN is inline asm we emit an lnop.
 We check for TImode to handle a MULTI1 insn which has dual issued its
!first instruction.  get_pipe returns -1 for MULTI0 or inline asm.  */
  static void
  emit_nop_for_insn (rtx insn)
  {
int p;
rtx new_insn;
+ 
+   /* We need to handle JUMP_TABLE_DATA separately.  */
+   if (JUMP_TABLE_DATA_P (insn))
+ {
+   new_insn = emit_insn_after (gen_lnop(), insn);
+   recog_memoized (new_insn);
+   INSN_LOCATION (new_insn) = UNKNOWN_LOCATION;
+   return;
+ }
+ 
p = get_pipe (insn);
if ((CALL_P (insn) || JUMP_P (insn)) && SCHED_ON_EVEN_P (insn))
  new_insn = emit_insn_after (gen_lnop (), insn);

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

[PATCH] Fix g++.dg/vect/slp-pr56812.cc

[Richard Biener]

This uses dg-additional-options, not dg-options which overrides
target specific flags added by dg-require-effective-target vect_float.

Tested on x86_64-unknown-linux-gnu, applied.

Richard.

2013-04-03  Richard Biener  

* g++.dg/vect/slp-pr56812.cc: Use dg-additional-options.

Index: gcc/testsuite/g++.dg/vect/slp-pr56812.cc
===
--- gcc/testsuite/g++.dg/vect/slp-pr56812.cc(revision 197397)
+++ gcc/testsuite/g++.dg/vect/slp-pr56812.cc(working copy)
@@ -1,6 +1,6 @@
 /* { dg-do compile } */
 /* { dg-require-effective-target vect_float } */
-/* { dg-options "-O3 -funroll-loops -fdump-tree-slp-details" } */
+/* { dg-additional-options "-O3 -funroll-loops -fvect-cost-model" } */
 
 class mydata {
 public:

[C++ PATCH] Fix up strip_typedefs (PR debug/56819)

[Jakub Jelinek]

Hi!

On the following testcase we ICE with -fcompare-debug with
--enable-checking=yes, because strip_typedefs copies args to a new TREE_VEC,
but doesn't copy over NON_DEFAULT_TEMPLATE_ARGS_COUNT.  For ENABLE_CHECKING
the code requires that it is set, for !ENABLE_CHECKING it would be needed
only if NON_DEFAULT_TEMPLATE_ARGS_COUNT was already non-NULL (otherwise
GET_NON_DEFAULT_TEMPLATE_ARGS_COUNT would use length of the TREE_VEC).

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

2013-04-03  Jakub Jelinek  

PR debug/56819
* tree.c (strip_typedefs): SET_NON_DEFAULT_TEMPLATE_ARGS_COUNT
on new_args.

* g++.dg/debug/pr56819.C: New test.

--- gcc/cp/tree.c.jj2013-04-02 20:24:34.0 +0200
+++ gcc/cp/tree.c   2013-04-03 10:51:56.614548181 +0200
@@ -1255,8 +1255,16 @@ strip_typedefs (tree t)
  changed = true;
  }
if (changed)
- fullname = lookup_template_function (TREE_OPERAND (fullname, 0),
-  new_args);
+ {
+#ifndef ENABLE_CHECKING
+   if (NON_DEFAULT_TEMPLATE_ARGS_COUNT (args))
+#endif
+ SET_NON_DEFAULT_TEMPLATE_ARGS_COUNT
+   (new_args, GET_NON_DEFAULT_TEMPLATE_ARGS_COUNT (args));
+   fullname
+ = lookup_template_function (TREE_OPERAND (fullname, 0),
+ new_args);
+ }
else
  ggc_free (new_args);
  }
--- gcc/testsuite/g++.dg/debug/pr56819.C.jj 2013-04-03 10:57:55.187410867 
+0200
+++ gcc/testsuite/g++.dg/debug/pr56819.C2013-04-03 10:56:42.0 
+0200
@@ -0,0 +1,27 @@
+// PR debug/56819
+// { dg-do compile }
+// { dg-options "-fcompare-debug" }
+
+template 
+struct A
+{
+  template 
+  struct B;
+};
+
+template 
+struct C
+{
+  typedef int I;
+};
+
+template 
+class D
+{
+  typedef A  E;
+  typedef typename T::template B  F;
+  typedef typename C ::I I;
+  A  foo () { return A (); }
+};
+
+template class D  >;

Jakub

GCC 4.7.3 Status Report (2013-04-03)

[Richard Biener]

Status
==

The GCC 4.7 branch is ready for a release candidate of GCC 4.7.3
which I will do tomorrow if no serious issue shows up until then.
The branch is frozen now, all changes require release manager approval
until the final release of GCC 4.7.3 which should happen roughly
one week after the release candidate.


Quality Data


Priority  #   Change from Last Report
---   ---
P10
P2   86   +  2
P36   - 12
---   ---
Total92   - 10


Previous Report
===

http://gcc.gnu.org/ml/gcc/2012-09/msg00182.html


The next report will be sent by me after the release

Re: GCC 4.7.3 Status Report (2013-04-03)

[Joel Sherrill]

The RTEMS Community would like to squeeze pr56771 in. It only got a fix in the 
past few days. It is a one line arm-rtems specific path to libcpp configure.

Can I commit that?

--joel
RTEMS

Richard Biener  wrote:


Status
==

The GCC 4.7 branch is ready for a release candidate of GCC 4.7.3
which I will do tomorrow if no serious issue shows up until then.
The branch is frozen now, all changes require release manager approval
until the final release of GCC 4.7.3 which should happen roughly
one week after the release candidate.


Quality Data


Priority  #   Change from Last Report
---   ---
P10
P2   86   +  2
P36   - 12
---   ---
Total92   - 10


Previous Report
===

http://gcc.gnu.org/ml/gcc/2012-09/msg00182.html


The next report will be sent by me after the release

[Patch] Add microMIPS jraddiusp support

[Moore, Catherine]

This doesn't seem to have made it to the list.

-Original Message-
From: Moore, Catherine 
Sent: Tuesday, April 02, 2013 12:26 PM
To: 'Richard Sandiford'
Cc: gcc-patches@gcc.gnu.org; Rozycki, Maciej; 'c...@codesourcery.com'
Subject: RE: [Patch] Add microMIPS jraddiusp support

Hi Richard,
I've now updated this patch.  How does this version look?
Catherine

2013-04-02  Catherine Moore  

* config/mips/micromips.md (jraddiusp): New pattern.
* config/mips/mips.c (mips_expand_epilogue): Use the JRADDIUSP
instruction if possible.

> -Original Message-
> From: Richard Sandiford [mailto:rdsandif...@googlemail.com]
> Sent: Thursday, March 14, 2013 5:38 PM
> To: Moore, Catherine
> Cc: gcc-patches@gcc.gnu.org; Rozycki, Maciej
> Subject: Re: [Patch] Add microMIPS jraddiusp support
> 
> "Moore, Catherine"  writes:
> > Hi Richard,
> >
> > I updated this patch using your suggestions.  I'm having a problem 
> > though, that I'm having trouble nailing.  Building libstdc++ for 
> > microMIPS is failing trying to generate dwarf2 CFI info:
> >
> > _Unwind_Ptr base_of_encoded_value(unsigned char,
> _Unwind_Context*)
> > Analyzing compilation unit Performing interprocedural optimizations 
> > <*free_lang_data>  
> <*free_inline_summary>
>   Assembling functions:
> >  _Unwind_Ptr base_of_encoded_value(unsigned char,
> _Unwind_Context*)
> > mm.cc: In function '_Unwind_Ptr base_of_encoded_value(unsigned char,
> _Unwind_Context*)':
> > mm.cc:34:1: internal compiler error: in maybe_record_trace_start, at
> > dwarf2cfi.c:2209
> > 0x8570656 maybe_record_trace_start
> >
> > /scratch/cmoore/umips-elf/src/gcc-4.7-2012.09/gcc/dwarf2cfi.c:2209
> > 0x857113f create_trace_edges
> >
> > /scratch/cmoore/umips-elf/src/gcc-4.7-2012.09/gcc/dwarf2cfi.c:2301
> > 0x8572505 scan_trace
> >
> > /scratch/cmoore/umips-elf/src/gcc-4.7-2012.09/gcc/dwarf2cfi.c:2514
> > 0x85726b3 create_cfi_notes
> >
> > /scratch/cmoore/umips-elf/src/gcc-4.7-2012.09/gcc/dwarf2cfi.c:2540
> > 0x8572703 execute_dwarf2_frame
> >
> > /scratch/cmoore/umips-elf/src/gcc-4.7-2012.09/gcc/dwarf2cfi.c:2897
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > Please include the complete backtrace with any bug report.
> > See  for instructions.
> >
> > I've attached a testcase hoping that you might have some ideas.  I 
> > plan to keep debugging in the meanwhile.  I was able to reproduce 
> > with ./cc1plus -mmicromips -Os mm.ii.
> 
> Ah, sorry, I expect it should be:
> 
>   mips_epilogue_set_cfa (stack_pointer_rtx, 0);
> 
> instead of:
> 
>   mips_epilogue_emit_cfa_restores ();
> 
> It would probably be better to call mips_epilogue_set_cfa immediately 
> after emitting the jraddiusp, if that works (in which case making the 
> assert conditional is OK).
> 
> Richard


jraddiusp.patch
Description: jraddiusp.patch

[Patch, AArch64] Fix duplication in test case.

[Tejas Belagod]

Hi,

The attached patch fixes duplication in a test case for gcc.target/aarch64/.

Tested on aarch64-none-elf. OK for trunk and branch?

Thanks,
Tejas Belagod
ARM.

2013-04-03  Tejas Belagod  

testsuite/
* gcc.target/aarch64/inc/asm-adder-clobber-lr.c: Remove duplication.
* gcc.target/aarch64/inc/asm-adder-no-clobber-lr.c: Likewise.
* gcc.target/aarch64/test-framepointer-1.c: Likewise.
* gcc.target/aarch64/test-framepointer-2.c: Likewise.
* gcc.target/aarch64/test-framepointer-3.c: Likewise.
* gcc.target/aarch64/test-framepointer-4.c: Likewise.
* gcc.target/aarch64/test-framepointer-5.c: Likewise.
* gcc.target/aarch64/test-framepointer-6.c: Likewise.
* gcc.target/aarch64/test-framepointer-7.c: Likewise.
* gcc.target/aarch64/test-framepointer-8.c: Likewise.diff --git a/gcc/testsuite/gcc.target/aarch64/asm-adder-clobber-lr.c 
b/gcc/testsuite/gcc.target/aarch64/asm-adder-clobber-lr.c
index 8a02abc..540c79b 100644
--- a/gcc/testsuite/gcc.target/aarch64/asm-adder-clobber-lr.c
+++ b/gcc/testsuite/gcc.target/aarch64/asm-adder-clobber-lr.c
@@ -21,28 +21,3 @@ main (int argc, char** argv)
 
   return 0;
 }
-
-extern void abort (void);
-
-int
-adder (int a, int b)
-{
-  int result;
-  __asm__ ("add %w0,%w1,%w2" : "=r"(result) : "r"(a), "r"(b) : "x30");
-  return result;
-}
-
-int
-main (int argc, char** argv)
-{
-  int i;
-  int total = argc;
-  for (i = 0; i < 20; i++)
-total = adder (total, i);
-
-  if (total != (190 + argc))
-abort ();
-
-  return 0;
-}
-
diff --git a/gcc/testsuite/gcc.target/aarch64/asm-adder-no-clobber-lr.c 
b/gcc/testsuite/gcc.target/aarch64/asm-adder-no-clobber-lr.c
index f60cfd3..2543d50 100644
--- a/gcc/testsuite/gcc.target/aarch64/asm-adder-no-clobber-lr.c
+++ b/gcc/testsuite/gcc.target/aarch64/asm-adder-no-clobber-lr.c
@@ -21,28 +21,3 @@ main (int argc, char** argv)
 
   return 0;
 }
-
-extern void abort (void);
-
-int
-adder (int a, int b)
-{
-  int result;
-  __asm__ ("add %w0,%w1,%w2" : "=r"(result) : "r"(a), "r"(b) : );
-  return result;
-}
-
-int
-main (int argc, char** argv)
-{
-  int i;
-  int total = argc;
-  for (i = 0; i < 20; i++)
-total = adder (total, i);
-
-  if (total != (190 + argc))
-abort ();
-
-  return 0;
-}
-
diff --git a/gcc/testsuite/gcc.target/aarch64/test-framepointer-1.c 
b/gcc/testsuite/gcc.target/aarch64/test-framepointer-1.c
index ae10959..e44ca6d 100644
--- a/gcc/testsuite/gcc.target/aarch64/test-framepointer-1.c
+++ b/gcc/testsuite/gcc.target/aarch64/test-framepointer-1.c
@@ -13,18 +13,3 @@
 /* { dg-final { scan-assembler-times "stp\tx29, x30, \\\[sp, -\[0-9\]+\\\]!" 2 
} } */
 
 /* { dg-final { cleanup-saved-temps } } */
-/* { dg-do run } */
-/* { dg-options "-O2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer 
-fno-inline --save-temps" } */
-
-#include "asm-adder-no-clobber-lr.c"
-
-/* omit-frame-pointer is FALSE.
-   omit-leaf-frame-pointer is FALSE.
-   LR is not being clobbered in the leaf.
-
-   With no frame pointer omissions, we expect a frame record
-   for main and the leaf.  */
-
-/* { dg-final { scan-assembler-times "stp\tx29, x30, \\\[sp, -\[0-9\]+\\\]!" 2 
} } */
-
-/* { dg-final { cleanup-saved-temps } } */
diff --git a/gcc/testsuite/gcc.target/aarch64/test-framepointer-2.c 
b/gcc/testsuite/gcc.target/aarch64/test-framepointer-2.c
index 71bc58d..40e4835 100644
--- a/gcc/testsuite/gcc.target/aarch64/test-framepointer-2.c
+++ b/gcc/testsuite/gcc.target/aarch64/test-framepointer-2.c
@@ -13,18 +13,3 @@
 /* { dg-final { scan-assembler-not "stp\tx29, x30, \\\[sp, -\[0-9\]+\\\]!" } } 
*/
 
 /* { dg-final { cleanup-saved-temps } } */
-/* { dg-do run } */
-/* { dg-options "-O2 -fomit-frame-pointer -mno-omit-leaf-frame-pointer 
-fno-inline --save-temps" } */
-
-#include "asm-adder-no-clobber-lr.c"
-
-/* omit-frame-pointer is TRUE.
-   omit-leaf-frame-pointer is false, but irrelevant due to omit-frame-pointer.
-   LR is not being clobbered in the leaf.
-
-   Since we asked to have no frame pointers anywhere, we expect no frame
-   record in main or the leaf.  */
-
-/* { dg-final { scan-assembler-not "stp\tx29, x30, \\\[sp, -\[0-9\]+\\\]!" } } 
*/
-
-/* { dg-final { cleanup-saved-temps } } */
diff --git a/gcc/testsuite/gcc.target/aarch64/test-framepointer-3.c 
b/gcc/testsuite/gcc.target/aarch64/test-framepointer-3.c
index de1b32c..98cb2e0 100644
--- a/gcc/testsuite/gcc.target/aarch64/test-framepointer-3.c
+++ b/gcc/testsuite/gcc.target/aarch64/test-framepointer-3.c
@@ -13,18 +13,3 @@
 /* { dg-final { scan-assembler-not "stp\tx29, x30, \\\[sp, -\[0-9\]+\\\]!" } } 
*/
 
 /* { dg-final { cleanup-saved-temps } } */
-/* { dg-do run } */
-/* { dg-options "-O2 -fomit-frame-pointer -momit-leaf-frame-pointer 
-fno-inline --save-temps" } */
-
-#include "asm-adder-no-clobber-lr.c"
-
-/* omit-frame-pointer is TRUE.
-   omit-leaf-frame-pointer is true, but irrelevant due to omit-frame-pointer.
-   LR is not being clobbered in the leaf.
-
-   Since we asked to have no 

Re: GCC 4.7.3 Status Report (2013-04-03)

[Richard Biener]

On Wed, 3 Apr 2013, Joel Sherrill wrote:

> The RTEMS Community would like to squeeze pr56771 in. It only got a fix in 
> the past few days. It is a one line arm-rtems specific path to libcpp 
> configure.
> 
> Can I commit that?

Sure, if it got RTEMS maintainer approval.

Richard.

> --joel
> RTEMS
> 
> Richard Biener  wrote:
> 
> 
> Status
> ==
> 
> The GCC 4.7 branch is ready for a release candidate of GCC 4.7.3
> which I will do tomorrow if no serious issue shows up until then.
> The branch is frozen now, all changes require release manager approval
> until the final release of GCC 4.7.3 which should happen roughly
> one week after the release candidate.
> 
> 
> Quality Data
> 
> 
> Priority  #   Change from Last Report
> ---   ---
> P10
> P2   86   +  2
> P36   - 12
> ---   ---
> Total92   - 10
> 
> 
> Previous Report
> ===
> 
> http://gcc.gnu.org/ml/gcc/2012-09/msg00182.html
> 
> 
> The next report will be sent by me after the release
> 
> 

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

Re: [C++ PATCH] Fix up strip_typedefs (PR debug/56819)

[Gabriel Dos Reis]

On Wed, Apr 3, 2013 at 7:36 AM, Jakub Jelinek  wrote:
> Hi!
>
> On the following testcase we ICE with -fcompare-debug with
> --enable-checking=yes, because strip_typedefs copies args to a new TREE_VEC,
> but doesn't copy over NON_DEFAULT_TEMPLATE_ARGS_COUNT.  For ENABLE_CHECKING
> the code requires that it is set, for !ENABLE_CHECKING it would be needed
> only if NON_DEFAULT_TEMPLATE_ARGS_COUNT was already non-NULL (otherwise
> GET_NON_DEFAULT_TEMPLATE_ARGS_COUNT would use length of the TREE_VEC).
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk/4.8/4.7?
>
> 2013-04-03  Jakub Jelinek  
>
> PR debug/56819
> * tree.c (strip_typedefs): SET_NON_DEFAULT_TEMPLATE_ARGS_COUNT
> on new_args.
>
> * g++.dg/debug/pr56819.C: New test.
>
> --- gcc/cp/tree.c.jj2013-04-02 20:24:34.0 +0200
> +++ gcc/cp/tree.c   2013-04-03 10:51:56.614548181 +0200
> @@ -1255,8 +1255,16 @@ strip_typedefs (tree t)
>   changed = true;
>   }
> if (changed)
> - fullname = lookup_template_function (TREE_OPERAND (fullname, 0),
> -  new_args);
> + {
> +#ifndef ENABLE_CHECKING
> +   if (NON_DEFAULT_TEMPLATE_ARGS_COUNT (args))
> +#endif
> + SET_NON_DEFAULT_TEMPLATE_ARGS_COUNT
> +   (new_args, GET_NON_DEFAULT_TEMPLATE_ARGS_COUNT (args));
> +   fullname
> + = lookup_template_function (TREE_OPERAND (fullname, 0),
> + new_args);
> + }
> else
>   ggc_free (new_args);

Hmm, the resulting code does not look simpler.
Why can't we always copy the stuff as opposed to
playing cat-n-fish with the CPP macro ENABLE_CHECKING?

-- Gaby

[PATCH] Fix PR56817

[Richard Biener]

This fixes PR56817 - when unrolling a loop we may not process
to outer loops of that loop without updating SSA form inbetween.
The following patch arranges for that by defering outer loop
processing to the next unrolling iteration.

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

Richard.

2013-04-03  Richard Biener  

PR tree-optimization/56817
* tree-ssa-loop-ivcanon.c (tree_unroll_loops_completely):
Split out ...
(tree_unroll_loops_completely_1): ... new function to manually
walk the loop tree, properly defering outer loops of unrolled
loops to later iterations.

* g++.dg/torture/pr56817.C: New testcase.

Index: gcc/tree-ssa-loop-ivcanon.c
===
--- gcc/tree-ssa-loop-ivcanon.c (revision 197397)
+++ gcc/tree-ssa-loop-ivcanon.c (working copy)
@@ -1097,6 +1097,63 @@ propagate_constants_for_unrolling (basic
 }
 }
 
+/* Process loops from innermost to outer, stopping at the innermost
+   loop we unrolled.  */
+
+static bool
+tree_unroll_loops_completely_1 (bool may_increase_size, bool unroll_outer,
+   vec& father_stack,
+   struct loop *loop)
+{
+  struct loop *loop_father;
+  bool changed = false;
+  struct loop *inner;
+  enum unroll_level ul;
+
+  /* Process inner loops first.  */
+  for (inner = loop->inner; inner != NULL; inner = inner->next)
+changed |= tree_unroll_loops_completely_1 (may_increase_size,
+  unroll_outer, father_stack,
+  inner);
+ 
+  /* If we changed an inner loop we cannot process outer loops in this
+ iteration because SSA form is not up-to-date.  Continue with
+ siblings of outer loops instead.  */
+  if (changed)
+return true;
+
+  /* Try to unroll this loop.  */
+  loop_father = loop_outer (loop);
+  if (!loop_father)
+return false;
+
+  if (may_increase_size && optimize_loop_nest_for_speed_p (loop)
+  /* Unroll outermost loops only if asked to do so or they do
+not cause code growth.  */
+  && (unroll_outer || loop_outer (loop_father)))
+ul = UL_ALL;
+  else
+ul = UL_NO_GROWTH;
+
+  if (canonicalize_loop_induction_variables
+(loop, false, ul, !flag_tree_loop_ivcanon))
+{
+  /* If we'll continue unrolling, we need to propagate constants
+within the new basic blocks to fold away induction variable
+computations; otherwise, the size might blow up before the
+iteration is complete and the IR eventually cleaned up.  */
+  if (loop_outer (loop_father) && !loop_father->aux)
+   {
+ father_stack.safe_push (loop_father);
+ loop_father->aux = loop_father;
+   }
+
+  return true;
+}
+
+  return false;
+}
+
 /* Unroll LOOPS completely if they iterate just few times.  Unless
MAY_INCREASE_SIZE is true, perform the unrolling only if the
size of the code does not increase.  */
@@ -1105,10 +1162,7 @@ unsigned int
 tree_unroll_loops_completely (bool may_increase_size, bool unroll_outer)
 {
   vec father_stack;
-  loop_iterator li;
-  struct loop *loop;
   bool changed;
-  enum unroll_level ul;
   int iteration = 0;
   bool irred_invalidated = false;
 
@@ -1124,34 +1178,9 @@ tree_unroll_loops_completely (bool may_i
   free_numbers_of_iterations_estimates ();
   estimate_numbers_of_iterations ();
 
-  FOR_EACH_LOOP (li, loop, LI_FROM_INNERMOST)
-   {
- struct loop *loop_father = loop_outer (loop);
-
- if (may_increase_size && optimize_loop_nest_for_speed_p (loop)
- /* Unroll outermost loops only if asked to do so or they do
-not cause code growth.  */
- && (unroll_outer || loop_outer (loop_father)))
-   ul = UL_ALL;
- else
-   ul = UL_NO_GROWTH;
-
- if (canonicalize_loop_induction_variables
-(loop, false, ul, !flag_tree_loop_ivcanon))
-   {
- changed = true;
- /* If we'll continue unrolling, we need to propagate constants
-within the new basic blocks to fold away induction variable
-computations; otherwise, the size might blow up before the
-iteration is complete and the IR eventually cleaned up.  */
- if (loop_outer (loop_father) && !loop_father->aux)
-   {
- father_stack.safe_push (loop_father);
- loop_father->aux = loop_father;
-   }
-   }
-   }
-
+  changed = tree_unroll_loops_completely_1 (may_increase_size,
+   unroll_outer, father_stack,
+   current_loops->tree_root);
   if (changed)
{
  struct loop **iter;
Index: gcc/testsuite/g++.dg/torture/pr56817.C
=

Re: [C++ PATCH] Fix up strip_typedefs (PR debug/56819)

[Jason Merrill]

We should be able to just copy NON_DEFAULT_TEMPLATE_ARGS_COUNT over 
rather than mess with looking into and building an INTEGER_CST.


Jason

Re: [C++ PATCH] Fix up strip_typedefs (PR debug/56819)

[Jakub Jelinek]

On Wed, Apr 03, 2013 at 08:38:01AM -0500, Gabriel Dos Reis wrote:
> > 2013-04-03  Jakub Jelinek  
> >
> > PR debug/56819
> > * tree.c (strip_typedefs): SET_NON_DEFAULT_TEMPLATE_ARGS_COUNT
> > on new_args.
> >
> > * g++.dg/debug/pr56819.C: New test.
> >
> > --- gcc/cp/tree.c.jj2013-04-02 20:24:34.0 +0200
> > +++ gcc/cp/tree.c   2013-04-03 10:51:56.614548181 +0200
> > @@ -1255,8 +1255,16 @@ strip_typedefs (tree t)
> >   changed = true;
> >   }
> > if (changed)
> > - fullname = lookup_template_function (TREE_OPERAND (fullname, 
> > 0),
> > -  new_args);
> > + {
> > +#ifndef ENABLE_CHECKING
> > +   if (NON_DEFAULT_TEMPLATE_ARGS_COUNT (args))
> > +#endif
> > + SET_NON_DEFAULT_TEMPLATE_ARGS_COUNT
> > +   (new_args, GET_NON_DEFAULT_TEMPLATE_ARGS_COUNT (args));
> > +   fullname
> > + = lookup_template_function (TREE_OPERAND (fullname, 0),
> > + new_args);
> > + }
> > else
> >   ggc_free (new_args);
> 
> Hmm, the resulting code does not look simpler.
> Why can't we always copy the stuff as opposed to
> playing cat-n-fish with the CPP macro ENABLE_CHECKING?

I didn't want to slow it down in the common case (--enable-checking=release)
and null NON_DEFAULT_TEMPLATE_ARGS_COUNT, in that case it would
build_int_cst unnecessarily.  If that isn't something we care about, why are
we differentiating between ENABLE_CHECKING vs. !ENABLE_CHECKING for
*NON_DEFAULT_TEMPLATE_ARGS_COUNT everywhere at all?
Though, as INTEGER_CSTs should be shared, perhaps this could be just
  NON_DEFAULT_TEMPLATE_ARGS_COUNT (new_args)
= NON_DEFAULT_TEMPLATE_ARGS_COUNT (args);
and strip_typedefs_expr could be changed to do the same thing.

Jakub

Re: [PATCH] Fix -Wformat-security warning in arm.c

[Matthew Gretton-Dann]

Is it okay for this patch to be backported to the 4.8 branch?

Thanks,

Matt

On 25/03/13 18:34, Roland McGrath wrote:

This fixes a gratuitous warning.


Thanks,
Roland


gcc/
2013-03-25  Roland McGrath  

* config/arm/arm.c (arm_print_operand: case 'w'): Use fputs rather
than fprintf with a non-constant, non-format string.

--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -17997,7 +17997,7 @@ arm_print_operand (FILE *stream, rtx x, int code)
  "wC12",  "wC13",  "wC14",  "wC15"
};

- fprintf (stream, wc_reg_names [INTVAL (x)]);
+ fputs (wc_reg_names [INTVAL (x)], stream);
}
return;




--
Matthew Gretton-Dann
Toolchain Working Group, Linaro

[Patch] Emit error for negative _Alignas alignment values

[Senthil Kumar Selvaraj]

This patch detects and emits an error if the value provided in _Alignas
is negative. The fix was approved pending full regression testing in a
previous discussion (http://gcc.gnu.org/ml/gcc/2013-03/msg00282.html). 
To add to that patch, I have added a testcase that explicitly checks for the
error for a negative power of 2.

Bootstrapped and regression tested with x86_64-unknown-linux-gnu with no new
failures.

If ok, could someone commit please? I don't have commit access.

Regards
Senthil

ChangeLog

2013-04-03  Senthil Kumar Selvaraj  

* c-common.c (check_user_alignment): Emit error for negative values

* gcc.dg/c1x-align-3.c: Add test for negative power of 2

diff --git gcc/c-family/c-common.c gcc/c-family/c-common.c
index c7cdd0f..dfdfbb6 100644
--- gcc/c-family/c-common.c
+++ gcc/c-family/c-common.c
@@ -7308,9 +7308,10 @@ check_user_alignment (const_tree align, bool allow_zero)
 }
   else if (allow_zero && integer_zerop (align))
 return -1;
-  else if ((i = tree_log2 (align)) == -1)
+  else if (tree_int_cst_sgn (align) == -1
+   || (i = tree_log2 (align)) == -1)
 {
-  error ("requested alignment is not a power of 2");
+  error ("requested alignment is not a positive power of 2");
   return -1;
 }
   else if (i >= HOST_BITS_PER_INT - BITS_PER_UNIT_LOG)
diff --git gcc/testsuite/gcc.dg/c1x-align-3.c gcc/testsuite/gcc.dg/c1x-align-3.c
index 0b2a77f..b97351c 100644
--- gcc/testsuite/gcc.dg/c1x-align-3.c
+++ gcc/testsuite/gcc.dg/c1x-align-3.c
@@ -23,6 +23,7 @@ _Alignas (-(__LONG_LONG_MAX__-1)/4) char i3; /* { dg-error 
"too large|power of 2
 _Alignas (-(__LONG_LONG_MAX__-1)/8) char i4; /* { dg-error "too large|power of 
2" } */
 _Alignas (-(__LONG_LONG_MAX__-1)/16) char i5; /* { dg-error "too large|power 
of 2" } */
 _Alignas (-1) char j; /* { dg-error "power of 2" } */
+_Alignas (-2) char j; /* { dg-error "positive power of 2" } */
 _Alignas (3) char k; /* { dg-error "power of 2" } */
 
 _Alignas ((void *) 1) char k; /* { dg-error "integer constant" } */

Re: patch to fix constant math - 4th patch - the wide-int class - patch ping for the next stage 1

[Richard Biener]

On Wed, Apr 3, 2013 at 2:05 PM, Kenneth Zadeck  wrote:
>
> On 04/03/2013 05:17 AM, Richard Biener wrote:
>
>> In the end you will have a variable-size storage in TREE_INT_CST thus
>> you will have at least to emit _code_ copying over meta-data and data
>> from the tree representation to the wide-int (similar for RTX
>> CONST_DOUBLE/INT).
>> I'm objecting to the amount of code you emit and agree that the runtime
>> cost is copying the meta-data (hopefully optimizable via CSE / SRA)
>> and in most cases one (or two) iterations of the loop copying the data
>> (not optimizable).
>
> i did get rid of the bitsize in the wide-int patch so at this point the meta
> data is the precision and the len.
> not really a lot here.   As usual we pay a high price in gcc for not pushing
> the tree rep down into the rtl level, then it would have been acceptable to
> have the tree type bleed into the wide-int code.
>
>
>
>>> 2)  You present this as if the implementor actually should care about the
>>> implementation and you give 3 alternatives:  the double_int, the current
>>> one, and HWI. We have tried to make it so that the client should not
>>> care.   Certainly in my experience here, I have not found a place to
>>> care.
>>
>> Well, similar as for the copying overhead for tree your approach requires
>> overloading operations for HOST_WIDE_INT operands to be able to
>> say wi + 1 (which is certainly desirable), or the overhead of using
>> wide_int_one ().
>>
>>> In my opinion double_int needs to go away.  That is the main thrust of my
>>> patches.   There is no place in a compiler for an abi that depends on
>>> constants fitting into 2 two words whose size is defined by the host.
>>
>> That's true.  I'm not arguing to preserve "double-int" - I'm arguing to
>> preserve a way to ask for an integer type on the host with (at least)
>> N bits.  Almost all double-int users really ask for an integer type on the
>> host that has at least as many bits as the pointer representation (or
>> word_mode) on
>> the target (we do have HOST_WIDEST_INT == 32bits for 64bit pointer
>> targets).  No double-int user specifically wants 2 * HOST_WIDE_INT
>> precision - that is just what happens to be there.  Thus I am providing
>> a way to say get me a host integer with at least N bits (VRP asks for
>> this, for example).
>>
>> What I was asking for is that whatever can provide the above should share
>> the functional interface with wide-int (or the othert way around).  And I
>> was claiming that wide-int is too fat, because current users of double-int
>> eventually store double-ints permanently.
>
> The problem is that, in truth, double int is too fat. 99.something% of all
> constants fit in 1 hwi and that is likely to be true forever (i understand
> that tree vpn may need some thought here).  The rtl level, which has, for as
> long as i have known it, had 2 reps for integer constants. So it was
> relatively easy to slide the CONST_WIDE_INT in.  It seems like the right
> trickery here rather than adding a storage model for wide-ints might be a
> way to use the c++ to invisibly support several (and by "several" i really
> mean 2) classes of TREE_CSTs.

The truth is that _now_ TREE_INT_CSTs use double-ints and we have
CONST_INT and CONST_DOUBLE.  What I (and you) propose would
get us to use variable-size storage for both, allowing to just use a single
HOST_WIDE_INT in the majority of cases.  In my view the constant
length of the variable-size storage for TREE_INT_CSTs is determined
by its type (thus, it doesn't have "optimized" variable-size storage
but "unoptimized" fixed-size storage based on the maximum storage
requirement for the type).  Similar for RTX CONST_INT which would
have fixed-size storage based on the mode-size of the constant.
Using optimized space (thus using the encoding properties) requires you
to fit the 'short len' somewhere which possibly will not pay off in the end
(for tree we do have that storage available, so we could go with optimized
storage for it, not sure with RTL, I don't see available space there).

>>> This is not a beauty contest argument, we have public ports are beginning
>>> to
>>> use modes that are larger than two x86-64 HWIs and i have a private port
>>> that has such modes and it is my experience that any pass that uses this
>>> interface has one of three behaviors: it silently gets the wrong answer,
>>> it
>>> ices, or it fails to do the transformation.  If we leave double_int as an
>>> available option, then any use of it potentially will have one of these
>>> three behaviors.  And so one of my strong objections to this direction is
>>> that i do not want to fight this kind of bug for the rest of my life.
>>> Having a single storage model that just always works is in my opinion a
>>> highly desirable option.  What you have never answered in a concrete
>>> manner
>>> is, if we decide to provide this generality, what it would be used for.
>>> There is no place in a portable compiler where the right answe

Re: [C++ PATCH] Fix up strip_typedefs (PR debug/56819)

[Jakub Jelinek]

On Wed, Apr 03, 2013 at 09:43:01AM -0400, Jason Merrill wrote:
> We should be able to just copy NON_DEFAULT_TEMPLATE_ARGS_COUNT over
> rather than mess with looking into and building an INTEGER_CST.

So is this ok instead?

2013-04-03  Jakub Jelinek  

PR debug/56819
* tree.c (strip_typedefs): Copy NON_DEFAULT_TEMPLATE_ARGS_COUNT
from args to new_args.
(strip_typedefs_expr): Copy NON_DEFAULT_TEMPLATE_ARGS_COUNT from t to
r instead of doing {S,G}ET_NON_DEFAULT_TEMPLATE_ARGS_COUNT.

* g++.dg/debug/pr56819.C: New test.

--- gcc/cp/tree.c.jj2013-04-03 11:15:39.412081151 +0200
+++ gcc/cp/tree.c   2013-04-03 15:49:54.885694171 +0200
@@ -1255,8 +1255,13 @@ strip_typedefs (tree t)
  changed = true;
  }
if (changed)
- fullname = lookup_template_function (TREE_OPERAND (fullname, 0),
-  new_args);
+ {
+   NON_DEFAULT_TEMPLATE_ARGS_COUNT (new_args)
+ = NON_DEFAULT_TEMPLATE_ARGS_COUNT (args);
+   fullname
+ = lookup_template_function (TREE_OPERAND (fullname, 0),
+ new_args);
+ }
else
  ggc_free (new_args);
  }
@@ -1389,8 +1394,8 @@ strip_typedefs_expr (tree t)
r = copy_node (t);
for (i = 0; i < n; ++i)
  TREE_VEC_ELT (r, i) = (*vec)[i];
-   SET_NON_DEFAULT_TEMPLATE_ARGS_COUNT
- (r, GET_NON_DEFAULT_TEMPLATE_ARGS_COUNT (t));
+   NON_DEFAULT_TEMPLATE_ARGS_COUNT (r)
+ = NON_DEFAULT_TEMPLATE_ARGS_COUNT (t);
  }
else
  r = t;
--- gcc/testsuite/g++.dg/debug/pr56819.C.jj 2013-04-03 15:49:05.384965717 
+0200
+++ gcc/testsuite/g++.dg/debug/pr56819.C2013-04-03 15:49:05.384965717 
+0200
@@ -0,0 +1,27 @@
+// PR debug/56819
+// { dg-do compile }
+// { dg-options "-fcompare-debug" }
+
+template 
+struct A
+{
+  template 
+  struct B;
+};
+
+template 
+struct C
+{
+  typedef int I;
+};
+
+template 
+class D
+{
+  typedef A  E;
+  typedef typename T::template B  F;
+  typedef typename C ::I I;
+  A  foo () { return A (); }
+};
+
+template class D  >;


Jakub

Re: [PATCH] Fix -Wformat-security warning in arm.c

[Richard Biener]

On Wed, 3 Apr 2013, Matthew Gretton-Dann wrote:

> Is it okay for this patch to be backported to the 4.8 branch?

Yes.

Richard.

> Thanks,
> 
> Matt
> 
> On 25/03/13 18:34, Roland McGrath wrote:
> > This fixes a gratuitous warning.
> > 
> > 
> > Thanks,
> > Roland
> > 
> > 
> > gcc/
> > 2013-03-25  Roland McGrath  
> > 
> > * config/arm/arm.c (arm_print_operand: case 'w'): Use fputs rather
> > than fprintf with a non-constant, non-format string.
> > 
> > --- a/gcc/config/arm/arm.c
> > +++ b/gcc/config/arm/arm.c
> > @@ -17997,7 +17997,7 @@ arm_print_operand (FILE *stream, rtx x, int code)
> >   "wC12",  "wC13",  "wC14",  "wC15"
> > };
> > 
> > - fprintf (stream, wc_reg_names [INTVAL (x)]);
> > + fputs (wc_reg_names [INTVAL (x)], stream);
> > }
> > return;
> > 
> 
> 
> 

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

[Patch] Fix PR56780: --disable-install-libiberty still installs libiberty.a

[Matt Burgess]

Hi,

Please find attached a patch that fixes PR56780.  Build tested on
x86_64-linux.  I've also attached it to the bug.

Regards,

Matt Burgess

2013-04-03 Matt Burgess 

other/PR56780
* libiberty/configure.ac:
Move test for --enable-install-libiberty outside of the
'with_target_subdir' test so that it actually gets run.
Add output messages to show the test result.

* libiberty/configure:
Regenerate.

* libiberty/Makefile.in (install_to_libdir):
Place the installation of the libiberty library in the same guard as
that used for the headers to prevent it being installed unless requested
via --enable-install-libiberty.
Index: libiberty/Makefile.in
===
--- libiberty/Makefile.in	(revision 197373)
+++ libiberty/Makefile.in	(working copy)
@@ -355,19 +355,19 @@
 # since it will be passed the multilib flags.
 MULTIOSDIR = `$(CC) $(CFLAGS) -print-multi-os-directory`
 install_to_libdir: all
-	${mkinstalldirs} $(DESTDIR)$(libdir)/$(MULTIOSDIR)
-	$(INSTALL_DATA) $(TARGETLIB) $(DESTDIR)$(libdir)/$(MULTIOSDIR)/$(TARGETLIB)n
-	( cd $(DESTDIR)$(libdir)/$(MULTIOSDIR) ; chmod 644 $(TARGETLIB)n ;$(RANLIB) $(TARGETLIB)n )
-	mv -f $(DESTDIR)$(libdir)/$(MULTIOSDIR)/$(TARGETLIB)n $(DESTDIR)$(libdir)/$(MULTIOSDIR)/$(TARGETLIB)
 	if test -n "${target_header_dir}"; then \
-	  case "${target_header_dir}" in \
-	/*)thd=${target_header_dir};; \
-	*) thd=${includedir}/${target_header_dir};; \
-	  esac; \
-	  ${mkinstalldirs} $(DESTDIR)$${thd}; \
-	  for h in ${INSTALLED_HEADERS}; do \
-	${INSTALL_DATA} $$h $(DESTDIR)$${thd}; \
-	  done; \
+		${mkinstalldirs} $(DESTDIR)$(libdir)/$(MULTIOSDIR); \
+		$(INSTALL_DATA) $(TARGETLIB) $(DESTDIR)$(libdir)/$(MULTIOSDIR)/$(TARGETLIB)n; \
+		( cd $(DESTDIR)$(libdir)/$(MULTIOSDIR) ; chmod 644 $(TARGETLIB)n ;$(RANLIB) $(TARGETLIB)n ); \
+		mv -f $(DESTDIR)$(libdir)/$(MULTIOSDIR)/$(TARGETLIB)n $(DESTDIR)$(libdir)/$(MULTIOSDIR)/$(TARGETLIB); \
+		case "${target_header_dir}" in \
+		  /*)thd=${target_header_dir};; \
+		  *) thd=${includedir}/${target_header_dir};; \
+		esac; \
+		${mkinstalldirs} $(DESTDIR)$${thd}; \
+		for h in ${INSTALLED_HEADERS}; do \
+		  ${INSTALL_DATA} $$h $(DESTDIR)$${thd}; \
+		done; \
 	fi
 	@$(MULTIDO) $(FLAGS_TO_PASS) multi-do DO=install
 
Index: libiberty/configure.ac
===
--- libiberty/configure.ac	(revision 197373)
+++ libiberty/configure.ac	(working copy)
@@ -128,6 +128,31 @@
cross_compiling=maybe
 fi
 
+# We may wish to install the target headers somewhere.
+AC_MSG_CHECKING([whether to install libiberty headers and static library])
+dnl install-libiberty is disabled by default
+
+AC_ARG_ENABLE(install-libiberty,
+[  --enable-install-libiberty   Install headers for end users],
+enable_install_libiberty=$enableval,
+enable_install_libiberty=no)dnl
+
+# Option parsed, now set things appropriately.
+case x"$enable_install_libiberty" in
+  xyes|x)
+target_header_dir=libiberty
+;;
+  xno)   
+target_header_dir=
+;;
+  *) 
+# This could be sanity-checked in various ways...
+target_header_dir="${enable_install_libiberty}"
+;;
+esac
+AC_MSG_RESULT($enable_install_libiberty)
+AC_MSG_NOTICE([target_header_dir = $target_header_dir])
+
 GCC_NO_EXECUTABLES
 AC_PROG_CC
 AC_SYS_LARGEFILE
@@ -492,27 +517,6 @@
 
   esac
 
-  # We may wish to install the target headers somewhere.
-  AC_ARG_ENABLE(install-libiberty,
-  [  --enable-install-libiberty   Install headers for end users],
-  enable_install_libiberty=$enableval,
-  enable_install_libiberty=no)dnl
-  
-  # Option parsed, now set things appropriately.
-  case x"$enable_install_libiberty" in
-xyes|x)
-  target_header_dir=libiberty
-  ;;
-xno)   
-  target_header_dir=
-  ;;
-*) 
-  # This could be sanity-checked in various ways...
-  target_header_dir="${enable_install_libiberty}"
-  ;;
-  esac
-
-
 else
 
# Not a target library, so we set things up to run the test suite.

Commit: V850: Use FPU-3.0 multiply-add instructions on E3V5 architectures

[Nick Clifton]

Hi Guys,

  I am checking in the patch below to make gcc generate the FPU-3.0
  multiply-add instructions when targeting the E3V5 V850 architecture.

Cheers
  Nick

gcc/ChangeLog
2013-04-03  Nick Clifton  

* config/v850/v850e3v5.md (fmasf4): Use fmaf.s on E3V5
architectures.
(fmssf4): Use fmsf.s on E3V5 architectures.
(fnmasf4): Use fnmaf.s on E3V5 architectures.
(fnmssf4): Use fnmsf.s on E3V5 architectures.

Index: gcc/config/v850/v850.md
===
--- gcc/config/v850/v850.md (revision 197406)
+++ gcc/config/v850/v850.md (working copy)
@@ -2508,14 +2508,18 @@
(set_attr "cc" "none_0hit")
(set_attr "type" "fpu")])
 
+;; Note: The FPU-2.0 (ie pre e3v5) versions of these routines do not actually
+;; need operand 4 to be the same as operand 0.  But the FPU-2.0 versions are
+;; also deprecated so the loss of flexibility is unimportant.
+
 ;;; multiply-add
 (define_insn "fmasf4"
   [(set (match_operand:SF 0 "register_operand" "=r")
(fma:SF (match_operand:SF 1 "register_operand" "r")
(match_operand:SF 2 "register_operand" "r")
-   (match_operand:SF 3 "register_operand" "r")))]
+   (match_operand:SF 3 "register_operand" "0")))]
   "TARGET_USE_FPU"
-  "maddf.s %2,%1,%3,%0"
+  { return TARGET_V850E3V5_UP ? "fmaf.s %1, %2, %0" : "maddf.s %2, %1, %3, 
%0"; }
   [(set_attr "length" "4")
(set_attr "cc" "none_0hit")
(set_attr "type" "fpu")])
@@ -2525,9 +2529,9 @@
   [(set (match_operand:SF 0 "register_operand" "=r")
(fma:SF (match_operand:SF 1 "register_operand" "r")
(match_operand:SF 2 "register_operand" "r")
-   (neg:SF (match_operand:SF 3 "register_operand" "r"]
+   (neg:SF (match_operand:SF 3 "register_operand" "0"]
   "TARGET_USE_FPU"
-  "msubf.s %2,%1,%3,%0"
+  { return TARGET_V850E3V5_UP ? "fmsf.s %1, %2, %0" : "msubf.s %2, %1, %3, 
%0"; }
   [(set_attr "length" "4")
(set_attr "cc" "none_0hit")
(set_attr "type" "fpu")])
@@ -2537,21 +2541,21 @@
   [(set (match_operand:SF 0 "register_operand" "=r")
(neg:SF (fma:SF (match_operand:SF 1 "register_operand" "r")
(match_operand:SF 2 "register_operand" "r")
-   (match_operand:SF 3 "register_operand" "r"]
+   (match_operand:SF 3 "register_operand" "0"]
   "TARGET_USE_FPU"
-  "nmaddf.s %2,%1,%3,%0"
+  { return TARGET_V850E3V5_UP ? "fnmaf.s %1, %2, %0" : "nmaddf.s %2, %1, %3, 
%0"; }
   [(set_attr "length" "4")
(set_attr "cc" "none_0hit")
(set_attr "type" "fpu")])
 
 ;; negative-multiply-subtract
 (define_insn "fnmssf4"
-  [(set (match_operand:SF 0 "register_operand" "=r")
+  [(set (match_operand:SF 0 "register_operand" "=r")
(neg:SF (fma:SF (match_operand:SF 1 "register_operand" "r")
(match_operand:SF 2 "register_operand" "r")
-   (neg:SF (match_operand:SF 3 "register_operand" "r")]
+   (neg:SF (match_operand:SF 3 "register_operand" "0")]
   "TARGET_USE_FPU"
-  "nmsubf.s %2,%1,%3,%0"
+  { return TARGET_V850E3V5_UP ? "fnmsf.s %1, %2, %0" : "nmsubf.s %2, %1, %3, 
%0"; }
   [(set_attr "length" "4")
(set_attr "cc" "none_0hit")
(set_attr "type" "fpu")])

Fold BIT_FIELD_REF of a reference

[Marc Glisse]

Hello,

I am not 100% convinced that it is always better to fold to a MEM_REF, but 
that's what the PR asks for.


bootstrap+testsuite on x86_64-linux-gnu.

2013-04-03  Marc Glisse  

PR middle-end/52436
gcc/
* fold-const.c (fold_ternary_loc) : Handle nested
reference.

gcc/testsuite/
* gcc.dg/pr52436.c: New testcase.
* gcc.dg/tree-ssa/ssa-fre-33.c: Adjust optimizer message.
* gcc.dg/tree-ssa/ssa-fre-34.c: Adjust optimizer message.

--
Marc GlisseIndex: gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-33.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-33.c  (revision 197411)
+++ gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-33.c  (working copy)
@@ -11,12 +11,12 @@ struct {
 float x;
 int main(int argc)
 {
   vector float res = (vector float){0.0f,0.0f,0.0f,1.0f};
   res += (vector float){1.0f,2.0f,3.0f,4.0f};
   s.global_res = res;
   x = *((float*)&s.global_res + 1);
   return 0;
 }
 
-/* { dg-final { scan-tree-dump "Replaced BIT_FIELD_REF.*with 2" "fre1" } } */
+/* { dg-final { scan-tree-dump "Replaced .* with 2" "fre1" } } */
 /* { dg-final { cleanup-tree-dump "fre1" } } */
Index: gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-34.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-34.c  (revision 197411)
+++ gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-34.c  (working copy)
@@ -8,12 +8,12 @@ struct {
 float i;
 vector float global_res;
 } s;
 float foo(float f)
 {
   vector float res = (vector float){0.0f,f,0.0f,1.0f};
   s.global_res = res;
   return *((float*)&s.global_res + 1);
 }
 
-/* { dg-final { scan-tree-dump "Replaced BIT_FIELD_REF.*with f" "fre1" } } */
+/* { dg-final { scan-tree-dump "Replaced .* with f" "fre1" } } */
 /* { dg-final { cleanup-tree-dump "fre1" } } */
Index: gcc/testsuite/gcc.dg/pr52436.c
===
--- gcc/testsuite/gcc.dg/pr52436.c  (revision 0)
+++ gcc/testsuite/gcc.dg/pr52436.c  (revision 0)
@@ -0,0 +1,18 @@
+/* { dg-do compile } */
+/* { dg-options "-O -fdump-tree-optimized" } */
+
+typedef long long __m128i __attribute__ ((vector_size (2 * sizeof (long long)),
+  may_alias));
+typedef struct
+{
+  __m128i b;
+} s_1a;
+typedef s_1a s_1m __attribute__((aligned(1)));
+void
+foo (s_1m *p)
+{
+  p->b[1] = 5;
+}
+
+/* { dg-final { scan-tree-dump-not "BIT_FIELD_EXPR" "optimized" } } */
+/* { dg-final { cleanup-tree-dump "optimized" } } */

Property changes on: gcc/testsuite/gcc.dg/pr52436.c
___
Added: svn:keywords
   + Author Date Id Revision URL
Added: svn:eol-style
   + native

Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 197411)
+++ gcc/fold-const.c(working copy)
@@ -14293,20 +14293,34 @@ fold_ternary_loc (location_t loc, enum t
{
  tree v = native_interpret_expr (type,
  b + bitpos / BITS_PER_UNIT,
  bitsize / BITS_PER_UNIT);
  if (v)
return v;
}
}
}
 
+  /* BIT_FIELD_REF[a.b, *, CST] -> MEM[&a, offsetof (a, b) + CST / 8].  */
+  if ((handled_component_p (arg0) || TREE_CODE (arg0) == MEM_REF)
+ && TREE_INT_CST_LOW (arg1) % BITS_PER_UNIT == 0
+ && TREE_INT_CST_LOW (arg2) % BITS_PER_UNIT == 0)
+   {
+ HOST_WIDE_INT coffset;
+ tree base = get_addr_base_and_unit_offset (arg0, &coffset);
+ if (base)
+   return fold_build2 (MEM_REF, type, build_fold_addr_expr (base),
+   build_int_cst (build_pointer_type
+(TYPE_MAIN_VARIANT (type)),
+  coffset + TREE_INT_CST_LOW (arg2)
+/ BITS_PER_UNIT));
+   }
   return NULL_TREE;
 
 case FMA_EXPR:
   /* For integers we can decompose the FMA if possible.  */
   if (TREE_CODE (arg0) == INTEGER_CST
  && TREE_CODE (arg1) == INTEGER_CST)
return fold_build2_loc (loc, PLUS_EXPR, type,
const_binop (MULT_EXPR, arg0, arg1), arg2);
   if (integer_zerop (arg2))
return fold_build2_loc (loc, MULT_EXPR, type, arg0, arg1);

Re: [C++ PATCH] Fix up strip_typedefs (PR debug/56819)

[Jason Merrill]

OK.

Jason

[c++-concepts] constrained declarations

[Andrew Sutton]

Associate requirements with declarations. This introduces a new node
(constraint-info) stores requirements and (eventually) decomposed
assumptions for all C++ declaration types. Template constraints are
associated with template declarations (including aliases and template
template parameters) and non-template member functions.


2013-04-03  Andrew Sutton  
* gcc/cp/cp-tree.def (CONSTRAINT_INFO): New node
* gcc/cp/cp-tree.h (require): New
(tree_constraint_info): New node type
(constraint_info_p): New
(cp_tree_node_structure_enum): New value TP_CONSTRAINT_INFO
(lang_tree_node): New member, constraint_info
(lang_decl): New member, constraint_info
(decl_constrained_p): New
(decl_constraints): New
(make_constraints): New
* semantics.c (finish_template_template_parm): Set requirements
for new template declaration
(finish_templtae_requirements): Build constraints from a
the required expression
* pt.c (build_template_decl): New parameter reqs. Associate
requiremetns with the new template decl
(push_template_decl_real): Build template decl with requirements
(add_inherited_template_parms): Build template decl without
requiremnts
* decl.c (cp_tree_node_structure): Include CONSTRAINT_INFO in
* constraint.cc (join_requirements): New
(conjoin_requirements): Return exacttly one expr if either is null
(disjoin_requirements): Likewise
(make_constraints): New
* ptree.c (cxx_print_decl): Print constraints
(cxx_print_xnode): Print constraint info
* cp-objcp-common.c (cp_tree_size): Include CONSTRAINT_INFO in
switch


req-assoc.patch
Description: Binary data

Re: GCC 4.7.3 Status Report (2013-04-03)

[Joel Sherrill]

On 4/3/2013 8:36 AM, Richard Biener wrote:

On Wed, 3 Apr 2013, Joel Sherrill wrote:


The RTEMS Community would like to squeeze pr56771 in. It only got a fix in the 
past few days. It is a one line arm-rtems specific path to libcpp configure.

Can I commit that?

Sure, if it got RTEMS maintainer approval.

That's me. So I will commit it .

Thanks.

Richard.


--joel
RTEMS

Richard Biener  wrote:


Status
==

The GCC 4.7 branch is ready for a release candidate of GCC 4.7.3
which I will do tomorrow if no serious issue shows up until then.
The branch is frozen now, all changes require release manager approval
until the final release of GCC 4.7.3 which should happen roughly
one week after the release candidate.


Quality Data


Priority  #   Change from Last Report
---   ---
P10
P2   86   +  2
P36   - 12
---   ---
Total92   - 10


Previous Report
===

http://gcc.gnu.org/ml/gcc/2012-09/msg00182.html


The next report will be sent by me after the release





--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

[PATCH][tsan] Fix PR55702

[Marek Polacek]

In this PR we ICEd because instrument_func_exit checked that
the last stmt of predecessors of EXIT_BLOCK_PTR is GIMPLE_RETURN,
but here we should allow BUILT_IN_RETURN function as well, as
it's basically the same as return.

I'm not sure about the testcase, but we don't have tsan testsuite
yet ...

Regtested on x86_64-linux, ok for trunk?

2013-04-03  Marek Polacek  

PR sanitizer/55702
* tsan.c (instrument_func_exit): Allow BUILT_IN_RETURN
functions.

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

--- gcc/tsan.c.mp   2013-04-03 15:20:20.525933474 +0200
+++ gcc/tsan.c  2013-04-03 16:06:36.482160964 +0200
@@ -681,7 +681,8 @@ instrument_func_exit (void)
 {
   gsi = gsi_last_bb (e->src);
   stmt = gsi_stmt (gsi);
-  gcc_assert (gimple_code (stmt) == GIMPLE_RETURN);
+  gcc_assert (gimple_code (stmt) == GIMPLE_RETURN
+ || gimple_call_builtin_p (stmt, BUILT_IN_RETURN));
   loc = gimple_location (stmt);
   builtin_decl = builtin_decl_implicit (BUILT_IN_TSAN_FUNC_EXIT);
   g = gimple_build_call (builtin_decl, 0);
--- gcc/testsuite/gcc.dg/pr55702.c.mp   2013-04-03 16:06:02.650055814 +0200
+++ gcc/testsuite/gcc.dg/pr55702.c  2013-04-03 16:05:33.984962743 +0200
@@ -0,0 +1,9 @@
+/* PR sanitizer/55702 */
+/* { dg-do compile { target { x86_64-*-linux* && lp64 } } } */
+/* { dg-options "-fsanitize=thread" } */
+
+void
+foo ()
+{
+  __builtin_return (0);
+}

Marek

Re: Fold BIT_FIELD_REF of a reference

[Richard Biener]

On Wed, Apr 3, 2013 at 4:15 PM, Marc Glisse  wrote:
> Hello,
>
> I am not 100% convinced that it is always better to fold to a MEM_REF, but
> that's what the PR asks for.
>
> bootstrap+testsuite on x86_64-linux-gnu.
>
> 2013-04-03  Marc Glisse  
>
> PR middle-end/52436
> gcc/
> * fold-const.c (fold_ternary_loc) : Handle nested
> reference.
>
> gcc/testsuite/
> * gcc.dg/pr52436.c: New testcase.
> * gcc.dg/tree-ssa/ssa-fre-33.c: Adjust optimizer message.
> * gcc.dg/tree-ssa/ssa-fre-34.c: Adjust optimizer message.
>
> --
> Marc Glisse
> Index: gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-33.c
> ===
> --- gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-33.c  (revision 197411)
> +++ gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-33.c  (working copy)
> @@ -11,12 +11,12 @@ struct {
>  float x;
>  int main(int argc)
>  {
>vector float res = (vector float){0.0f,0.0f,0.0f,1.0f};
>res += (vector float){1.0f,2.0f,3.0f,4.0f};
>s.global_res = res;
>x = *((float*)&s.global_res + 1);
>return 0;
>  }
>
> -/* { dg-final { scan-tree-dump "Replaced BIT_FIELD_REF.*with 2" "fre1" } }
> */
> +/* { dg-final { scan-tree-dump "Replaced .* with 2" "fre1" } } */
>  /* { dg-final { cleanup-tree-dump "fre1" } } */
> Index: gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-34.c
> ===
> --- gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-34.c  (revision 197411)
> +++ gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-34.c  (working copy)
> @@ -8,12 +8,12 @@ struct {
>  float i;
>  vector float global_res;
>  } s;
>  float foo(float f)
>  {
>vector float res = (vector float){0.0f,f,0.0f,1.0f};
>s.global_res = res;
>return *((float*)&s.global_res + 1);
>  }
>
> -/* { dg-final { scan-tree-dump "Replaced BIT_FIELD_REF.*with f" "fre1" } }
> */
> +/* { dg-final { scan-tree-dump "Replaced .* with f" "fre1" } } */
>  /* { dg-final { cleanup-tree-dump "fre1" } } */
> Index: gcc/testsuite/gcc.dg/pr52436.c
> ===
> --- gcc/testsuite/gcc.dg/pr52436.c  (revision 0)
> +++ gcc/testsuite/gcc.dg/pr52436.c  (revision 0)
> @@ -0,0 +1,18 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O -fdump-tree-optimized" } */
> +
> +typedef long long __m128i __attribute__ ((vector_size (2 * sizeof (long
> long)),
> +  may_alias));
> +typedef struct
> +{
> +  __m128i b;
> +} s_1a;
> +typedef s_1a s_1m __attribute__((aligned(1)));
> +void
> +foo (s_1m *p)
> +{
> +  p->b[1] = 5;
> +}
> +
> +/* { dg-final { scan-tree-dump-not "BIT_FIELD_EXPR" "optimized" } } */
> +/* { dg-final { cleanup-tree-dump "optimized" } } */
>
> Property changes on: gcc/testsuite/gcc.dg/pr52436.c
> ___
> Added: svn:keywords
>+ Author Date Id Revision URL
> Added: svn:eol-style
>+ native
>
> Index: gcc/fold-const.c
> ===
> --- gcc/fold-const.c(revision 197411)
> +++ gcc/fold-const.c(working copy)
> @@ -14293,20 +14293,34 @@ fold_ternary_loc (location_t loc, enum t
> {
>   tree v = native_interpret_expr (type,
>   b + bitpos /
> BITS_PER_UNIT,
>   bitsize / BITS_PER_UNIT);
>   if (v)
> return v;
> }
> }
> }
>
> +  /* BIT_FIELD_REF[a.b, *, CST] -> MEM[&a, offsetof (a, b) + CST / 8].
> */
> +  if ((handled_component_p (arg0) || TREE_CODE (arg0) == MEM_REF)

This check means the optimization is not performed for
BIT_FIELD_REF[a, *, CST] which I see no particularly good reason for.
Did something break when you just remove the whole check above?

Richard.

> + && TREE_INT_CST_LOW (arg1) % BITS_PER_UNIT == 0
> + && TREE_INT_CST_LOW (arg2) % BITS_PER_UNIT == 0)
> +   {
> + HOST_WIDE_INT coffset;
> + tree base = get_addr_base_and_unit_offset (arg0, &coffset);
> + if (base)
> +   return fold_build2 (MEM_REF, type, build_fold_addr_expr (base),
> +   build_int_cst (build_pointer_type
> +(TYPE_MAIN_VARIANT (type)),
> +  coffset + TREE_INT_CST_LOW
> (arg2)
> +/ BITS_PER_UNIT));
> +   }
>return NULL_TREE;
>
>  case FMA_EXPR:
>/* For integers we can decompose the FMA if possible.  */
>if (TREE_CODE (arg0) == INTEGER_CST
>   && TREE_CODE (arg1) == INTEGER_CST)
> return fold_build2_loc (loc, PLUS_EXPR, type,
> const_binop (MULT_EXPR, arg0, arg1), arg2);
>if (integer_zerop (arg2))
> return f

[PATCH][ARM] Fix PR 56809

[Kyrylo Tkachov]

Hi all,

This patch fixes an ICE that we encounter when building gcc on arm targets.
The jump table reorganisation exposed a bug in the backend. This fixes it
by using next_active_insn instead of next_real_insn when looking for the
diff vector in the jump table handling code. (Thanks to Steven Bosscher for
the tip).

A separate aarch64 patch is coming soon separately.

Tested arm-none-eabi on qemu and confirmed that the build for
arm-none-linux-gnueabi is fixed.
Since the PR affects both arm and aarch64 I put a testcase into gcc.dg.

Ok for trunk?

Thanks,
Kyrill

gcc/ChangeLog
2013-04-03  Kyrylo Tkachov  

PR target/56809
* config/arm/arm.c (is_jump_table): Use next_active_insn instead of
next_real_insn.
(thumb1_output_casesi): Likewise.
(thumb2_output_casesi): Likewise.

gcc/testsuite/ChangeLog
2013-04-03  Kyrylo Tkachov  

PR target/56809
* gcc.dg/pr56809.c: New testcase.

pr56809_arm.patch
Description: Binary data

[PATCH][AArch64] Fix PR 56809

[Kyrylo Tkachov]

Hi all,

This patch fixes a PR that was exposed in the recent jump table
reorganisation.
We should use next_active_insn instead of next_real_insn in the jump table
handling code.

This fixes the incorrect assembly generation that we get when building
newlib for aarch64.

Tested aarch64-none-elf.
A testcase to gcc.dg is added with the separate arm patch.

Ok for trunk?

Thanks,
Kyrill

gcc/ChangeLog

2013-04-03  Kyrylo Tkachov  

PR target/56809
* config/aarch64/aarch64.c (is_jump_table): Use next_active_insn
instead of
next_real_insn.

pr56809_aarch64.patch
Description: Binary data

[v3] Fix libstdc++/56834

[Paolo Carlini]

Hi,

admittedly, I'm still missing some details of the 
--enable-symvers=gnu-versioned-namespace configuration, but this is 
straightforweard enough. Applied mainline and 4_8-branch.


Thanks,
Paolo.

///
2013-04-03  Paolo Carlini  

PR libstdc++/56834
* include/debug/array (tuple_size, tuple_element): Do not declare.
* include/profile/array: Likewise.
* testsuite/23_containers/array/tuple_interface/
tuple_element_debug_neg.cc: Adjust dg-error line number.
Index: include/debug/array
===
--- include/debug/array (revision 197411)
+++ include/debug/array (working copy)
@@ -289,17 +289,11 @@
   // Tuple interface to class template array.
 
   /// tuple_size
-  template 
-class tuple_size;
-
   template
 struct tuple_size<__debug::array<_Tp, _Nm>>
 : public integral_constant { };
 
   /// tuple_element
-  template
-class tuple_element;
-
   template
 struct tuple_element<_Int, __debug::array<_Tp, _Nm>>
 {
Index: include/profile/array
===
--- include/profile/array   (revision 197411)
+++ include/profile/array   (working copy)
@@ -251,17 +251,11 @@
   // Tuple interface to class template array.
 
   /// tuple_size
-  template 
-class tuple_size;
-
   template
 struct tuple_size<__profile::array<_Tp, _Nm>>
 : public integral_constant { };
 
   /// tuple_element
-  template
-class tuple_element;
-
   template
 struct tuple_element<_Int, __profile::array<_Tp, _Nm>>
 {
Index: testsuite/23_containers/array/tuple_interface/tuple_element_debug_neg.cc
===
--- testsuite/23_containers/array/tuple_interface/tuple_element_debug_neg.cc
(revision 197411)
+++ testsuite/23_containers/array/tuple_interface/tuple_element_debug_neg.cc
(working copy)
@@ -23,4 +23,4 @@
 
 typedef std::tuple_element<1, std::array>::type type;
 
-// { dg-error "static assertion failed" "" { target *-*-* } 306 }
+// { dg-error "static assertion failed" "" { target *-*-* } 300 }

Re: [PATCH][tsan] Fix PR55702

[Jakub Jelinek]

On Wed, Apr 03, 2013 at 04:40:30PM +0200, Marek Polacek wrote:
> In this PR we ICEd because instrument_func_exit checked that
> the last stmt of predecessors of EXIT_BLOCK_PTR is GIMPLE_RETURN,
> but here we should allow BUILT_IN_RETURN function as well, as
> it's basically the same as return.
> 
> I'm not sure about the testcase, but we don't have tsan testsuite
> yet ...
> 
> Regtested on x86_64-linux, ok for trunk?

Ok for trunk/4.8.

> 2013-04-03  Marek Polacek  
> 
>   PR sanitizer/55702
>   * tsan.c (instrument_func_exit): Allow BUILT_IN_RETURN
>   functions.
> 
>   * gcc.dg/pr55702.c: New test.

Jakub

Re: [PATCH][ARM] Fix PR 56809

[Ramana Radhakrishnan]

On 04/03/13 16:07, Kyrylo Tkachov wrote:

Hi all,

This patch fixes an ICE that we encounter when building gcc on arm targets.
The jump table reorganisation exposed a bug in the backend.
This fixes it
by using next_active_insn instead of next_real_insn when looking for the
diff vector in the jump table handling code. (Thanks to Steven Bosscher for
the tip).

A separate aarch64 patch is coming soon separately.

Tested arm-none-eabi on qemu and confirmed that the build for
arm-none-linux-gnueabi is fixed.
Since the PR affects both arm and aarch64 I put a testcase into gcc.dg.

Ok for trunk?


Ok for trunk.

regards
Ramana

Re: [PATCH v2] PR56771: Fix arm-rtems target for 32-bit hosts

[Joel Sherrill]

This patch has been applied to 4.7, 4.8 and 4.9.

PR 56771 closed.

--joel

On 4/2/2013 10:08 AM, Sebastian Huber wrote:

This patch is for GCC 4.8 and 4.9.

v2: Fix ChangeLog.

libcpp/ChangeLog
2013-04-02  Sebastian Huber  

PR target/56771
* configure.ac: Require 64-bit int for arm*-*-rtems*.
* configure: Regenerate.
---
  libcpp/configure|1 +
  libcpp/configure.ac |1 +
  2 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/libcpp/configure b/libcpp/configure
index f21b361..7158186 100755
--- a/libcpp/configure
+++ b/libcpp/configure
@@ -7153,6 +7153,7 @@ case $target in
aarch64*-*-* | \
alpha*-*-* | \
arm*-*-*eabi* | \
+   arm*-*-rtems* | \
arm*-*-symbianelf* | \
x86_64-*-* | \
ia64-*-* | \
diff --git a/libcpp/configure.ac b/libcpp/configure.ac
index e0c4ae6..43ac9ba 100644
--- a/libcpp/configure.ac
+++ b/libcpp/configure.ac
@@ -185,6 +185,7 @@ case $target in
aarch64*-*-* | \
alpha*-*-* | \
arm*-*-*eabi* | \
+   arm*-*-rtems* | \
arm*-*-symbianelf* | \
x86_64-*-* | \
ia64-*-* | \



--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

Re: [C++ PATCH] Fix up strip_typedefs (PR debug/56819)

[Gabriel Dos Reis]

> Though, as INTEGER_CSTs should be shared, perhaps this could be just
>   NON_DEFAULT_TEMPLATE_ARGS_COUNT (new_args)
> = NON_DEFAULT_TEMPLATE_ARGS_COUNT (args);

Yes, thanks!

> and strip_typedefs_expr could be changed to do the same thing.

Re: [PATCH][ARM] use vsel instruction for floating point conditional moves in ARMv8

[Matthew Gretton-Dann]

Would it be possible for this patch and the others Kyrylo has recently done 
for the new ARMv8 AArch32 instructions to be backported to 4.8?


In particular I'm refering to:

http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00994.html (trunk r197052)
http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00874.html (trunk r197051)
http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00873.html (trunk r197046)
http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00652.html (trunk r197040 and 
197041)


Thanks,

Matt


On 25/03/13 15:21, Kyrylo Tkachov wrote:

-Original Message-
From: Ramana Radhakrishnan
Sent: 18 February 2013 11:51
To: Kyrylo Tkachov
Cc: gcc-patches@gcc.gnu.org; Richard Earnshaw
Subject: Re: [PATCH][ARM] use vsel instruction for floating point
conditional moves in ARMv8

On 01/30/13 09:24, Kyrylo Tkachov wrote:

Hi all,
This patch uses the new ARMv8 AArch32 vsel instruction to implement
conditional moves of floating point numbers.
For example, an instruction of the form:
vsel.f32  s0, s1, s2
means
s0 := cond ? s1 : s2

This can be useful, among other places, in Thumb2 because it doesn't

require

an enclosing IT block.
A small catch: The condition code used in vsel can only be one of

{GE, GT,

EQ, VS}. If we want to use their negations {LT, LE, NE, VC} we just

flip the

source operands.
A new predicate is introduced that checks that the comparison yields

an ARM

condition code in the set {GE, GT, EQ, VS, LT, LE, NE, VC}.

New compilation tests are added. They pass on a model and no new

regressions

on arm-none-eabi with qemu.




Ok for trunk?


Ok for stage1 4.9.


Hi Ramana,

Thanks for the review.
Re-tested on arm-none-eabi against current trunk and applied as r197052.



Ramana


Thanks,
Kyrill




Thanks,
Kyrill

gcc/ChangeLog

2013-01-30  Kyrylo Tkachov  

* config/arm/arm.md (f_sels, f_seld): New types.
(*cmov): New pattern.
* config/arm/predicates.md (arm_vsel_comparison_operator): New
predicate.


gcc/testsuite/ChangeLog

2013-01-30  Kyrylo Tkachov  

* gcc.target/arm/vseleqdf.c: New test.
* gcc.target/arm/vseleqsf.c: Likewise.
* gcc.target/arm/vselgedf.c: Likewise.
* gcc.target/arm/vselgesf.c: Likewise.
* gcc.target/arm/vselgtdf.c: Likewise.
* gcc.target/arm/vselgtsf.c: Likewise.
* gcc.target/arm/vselledf.c: Likewise.
* gcc.target/arm/vsellesf.c: Likewise.
* gcc.target/arm/vselltdf.c: Likewise.
* gcc.target/arm/vselltsf.c: Likewise.
* gcc.target/arm/vselnedf.c: Likewise.
* gcc.target/arm/vselnesf.c: Likewise.
* gcc.target/arm/vselvcdf.c: Likewise.
* gcc.target/arm/vselvcsf.c: Likewise.
* gcc.target/arm/vselvsdf.c: Likewise.
* gcc.target/arm/vselvssf.c: Likewise.









--
Matthew Gretton-Dann
Toolchain Working Group, Linaro

[C++ Patch] PR 56815

[Paolo Carlini]

Hi,

thus, as discussed in the audit trail, I'm simply changing the permerror 
in the C++ front-end to pedwarn.


Tested x86_64-linux.

Thanks,
Paolo.

PS: there is a couple of issues noticed while working on this - 
essentially, tweaks to c.opt and c-common.c - which I prefer to handle 
separately.


///
/cp
2013-04-03  Paolo Carlini  

PR c++/56815
* typeck.c (cp_build_unary_op): Change -Wpointer-arith permerror to
pedwarn.

/testsuite
2013-04-03  Paolo Carlini  

PR c++/56815
* g++.dg/warn/Wpointer-arith-1.C: New.
* g++.dg/gomp/for-19.C: Adjust.
Index: cp/typeck.c
===
--- cp/typeck.c (revision 197414)
+++ cp/typeck.c (working copy)
@@ -5574,15 +5574,16 @@ cp_build_unary_op (enum tree_code code, tree xarg,
 else
   return error_mark_node;
   }
-   else if ((pedantic || warn_pointer_arith)
-&& !TYPE_PTROB_P (argtype)) 
+   else if (!TYPE_PTROB_P (argtype)) 
   {
 if (complain & tf_error)
-  permerror (input_location, (code == PREINCREMENT_EXPR
+  pedwarn (input_location,
+  pedantic ? OPT_Wpedantic : OPT_Wpointer_arith,
+  (code == PREINCREMENT_EXPR
   || code == POSTINCREMENT_EXPR)
- ? G_("ISO C++ forbids incrementing a pointer of 
type %qT")
- : G_("ISO C++ forbids decrementing a pointer of 
type %qT"),
- argtype);
+  ? G_("ISO C++ forbids incrementing a pointer of type 
%qT")
+  : G_("ISO C++ forbids decrementing a pointer of type 
%qT"),
+  argtype);
 else
   return error_mark_node;
   }
Index: testsuite/g++.dg/gomp/for-19.C
===
--- testsuite/g++.dg/gomp/for-19.C  (revision 197414)
+++ testsuite/g++.dg/gomp/for-19.C  (working copy)
@@ -9,7 +9,7 @@ void
 f1 (void)
 {
 #pragma omp for
-  for (void *q = (void *)p; q < (void *) (p + 4); q++) // { dg-error "forbids 
incrementing a pointer of type" }
+  for (void *q = (void *)p; q < (void *) (p + 4); q++) // { dg-warning 
"forbids incrementing a pointer of type" }
 ;
 }
 
@@ -27,7 +27,7 @@ void
 f3 (void)
 {
 #pragma omp for
-  for (T q = T (p); q < T (p + 4); q++)// { dg-error "forbids 
incrementing a pointer of type" }
+  for (T q = T (p); q < T (p + 4); q++)// { dg-warning "forbids 
incrementing a pointer of type" }
 ;
 }
 
Index: testsuite/g++.dg/warn/Wpointer-arith-1.C
===
--- testsuite/g++.dg/warn/Wpointer-arith-1.C(revision 0)
+++ testsuite/g++.dg/warn/Wpointer-arith-1.C(working copy)
@@ -0,0 +1,13 @@
+// PR c++/56815
+// { dg-options "-Wpointer-arith" }
+
+int main()
+{
+  void *pv = 0;
+  pv++;// { dg-warning "forbids incrementing a pointer" }
+
+  typedef void (*pft) ();
+
+  pft pf = 0;
+  pf++;// { dg-warning "forbids incrementing a pointer" }
+}

RFC: elimination of global state relating to passes

[David Malcolm]

I'm working on my first gcc contribution, but it's a large patch, and I
wanted to sound things out on this list.

I want to eliminate/minimize global state within gcc, since I think
doing so is a key part of making gcc more modular.

Currently there's a lot of global state associated with passes:
* the pass tree itself: a single global tree of passes, with callbacks
("gate" and "execute")
* globals within individual pass .c files

My plan is to instead have the passes be dynamically created instances
of pass subclasses, where each pass has a custom subclass of the
appropriate pass class:

So, for example, mudflap would become something like:

   class pass_mudflap_2 : public gimple_opt_pass
   {
 public:
  bool gate() { return gate_mudflap(); }
  unsigned int execute() { return execute_mudflap_function_ops(); }
   };

where these subclasses are hidden inside the .c files (in this case
inside gcc/tree-mudflap.c).

All that's exposed to the headers would then be a factory function:

  gimple_opt_pass *
  make_pass_mudflap_2 (context &ctxt)
  {
 return new pass_mudflap_2 (ctxt);
  }

Globals within a .c file that are specific to a particular pass may then
be movable to instance data of the pass subclass (on a case-by-case
basis).

Each pass also has a reference back to a new "context" class, shared by
all the passes: this is currently empty, but I see it being useful as a
place to add any global state that isn't part of the pass itself: given
that this patch is touching hundreds of files I'd rather add it now,
rather than having to go back and add it later.

I started doing this by hand, however, there are hundreds of passes, so
to avoid lots of error-prone typing I've written a refactoring script.

You can see the test suite for the refactoring script here:
https://github.com/davidmalcolm/gcc-refactoring-scripts/blob/master/test_refactor.py
which should give a better idea of the before/after when applying the
refactoring (and the use of a test suite hopefully increases the
credibility that the resulting patch doesn't change the effective
behavior of the code).

When run, the refactoring script generates this
107 files changed, 5008 insertions(+), 4214 deletions(-)

There's also a hand-written part of the patch, which I'm attaching the
most pertinent parts of i.e. gcc/tree-pass.h

It doesn't quite compile yet, gcc/passes.c needs work - in particular
the code to construct and manage the tree of passes (I think I can do
this, but it may need moving the bulk of init_optimization_passes() into
a new passes.def file so that I can include it again elsewhere with a
different defintion of NEXT_PASS).   There's also a new "pipeline" class
representing the pass hierarchy, which stores the pointers to the pass
instances, so that it's easy to access them from gdb when debugging.

One wart in my plan is that a lot of the existing callbacks are checked
against NULL and if non-NULL, then extra things happen before/after the
call.

I don't know of a portable way to do this for a C++ virtual function, so
each callback becomes *two* vtable entries:
  bool has_FOO()   // equivalent to (pass->FOO != NULL) in old code
and 
  impl_FOO()   // equivalent to (pass->FOO ()) in old code

I'm currently working off of this git repo:
  git://gcc.gnu.org/git/gcc.git
in the hope of getting this into 4.9 during stage 1.

Hope this is constructive
Dave
diff --git a/gcc/tree-pass.h b/gcc/tree-pass.h
index 0942ad7..d45b6a5 100644
--- a/gcc/tree-pass.h
+++ b/gcc/tree-pass.h
@@ -25,6 +25,17 @@ along with GCC; see the file COPYING3.  If not see
 #include "timevar.h"
 #include "dumpfile.h"
 
+class context;
+class pipeline;
+class opt_pass;
+
+/* Holder for state */
+class context
+{
+public:
+  pipeline *passes;
+};
+
 /* Optimization pass type.  */
 enum opt_pass_type
 {
@@ -34,10 +45,80 @@ enum opt_pass_type
   IPA_PASS
 };
 
+/* Sets of properties input and output from this pass.  */
+struct pass_properties
+{
+public:
+  pass_properties(unsigned int required,
+  unsigned int provided,
+  unsigned int destroyed)
+: required(required),
+  provided(provided),
+  destroyed(destroyed)
+  {}
+
+  unsigned int required;
+  unsigned int provided;
+  unsigned int destroyed;
+};
+
+/* Flags indicating common sets things to do before and after a pass.  */
+struct pass_todo_flags
+{
+public:
+  pass_todo_flags(unsigned int start,
+  unsigned int finish)
+: start(start),
+  finish(finish)
+  {}
+
+  unsigned int start;
+  unsigned int finish;
+};
+
 /* Describe one pass; this is the common part shared across different pass
types.  */
-struct opt_pass
+class opt_pass
 {
+public:
+  virtual ~opt_pass () { }
+
+  /* Public Methods */
+
+  /* This pass and all sub-passes are executed only if
+ the function returns true.  */
+  virtual bool has_gate() { return false; }
+  virtual bool gate() { return true; }
+
+  /* This is the code to run. The return value contains

Re: [C++ Patch] PR 56815

[Jason Merrill]

OK.

Jason

Re: patch to fix constant math - 4th patch - the wide-int class - patch ping for the next stage 1

[Kenneth Zadeck]

On 04/03/2013 09:53 AM, Richard Biener wrote:

On Wed, Apr 3, 2013 at 2:05 PM, Kenneth Zadeck  wrote:

On 04/03/2013 05:17 AM, Richard Biener wrote:


In the end you will have a variable-size storage in TREE_INT_CST thus
you will have at least to emit _code_ copying over meta-data and data
from the tree representation to the wide-int (similar for RTX
CONST_DOUBLE/INT).
I'm objecting to the amount of code you emit and agree that the runtime
cost is copying the meta-data (hopefully optimizable via CSE / SRA)
and in most cases one (or two) iterations of the loop copying the data
(not optimizable).

i did get rid of the bitsize in the wide-int patch so at this point the meta
data is the precision and the len.
not really a lot here.   As usual we pay a high price in gcc for not pushing
the tree rep down into the rtl level, then it would have been acceptable to
have the tree type bleed into the wide-int code.




2)  You present this as if the implementor actually should care about the
implementation and you give 3 alternatives:  the double_int, the current
one, and HWI. We have tried to make it so that the client should not
care.   Certainly in my experience here, I have not found a place to
care.

Well, similar as for the copying overhead for tree your approach requires
overloading operations for HOST_WIDE_INT operands to be able to
say wi + 1 (which is certainly desirable), or the overhead of using
wide_int_one ().


In my opinion double_int needs to go away.  That is the main thrust of my
patches.   There is no place in a compiler for an abi that depends on
constants fitting into 2 two words whose size is defined by the host.

That's true.  I'm not arguing to preserve "double-int" - I'm arguing to
preserve a way to ask for an integer type on the host with (at least)
N bits.  Almost all double-int users really ask for an integer type on the
host that has at least as many bits as the pointer representation (or
word_mode) on
the target (we do have HOST_WIDEST_INT == 32bits for 64bit pointer
targets).  No double-int user specifically wants 2 * HOST_WIDE_INT
precision - that is just what happens to be there.  Thus I am providing
a way to say get me a host integer with at least N bits (VRP asks for
this, for example).

What I was asking for is that whatever can provide the above should share
the functional interface with wide-int (or the othert way around).  And I
was claiming that wide-int is too fat, because current users of double-int
eventually store double-ints permanently.

The problem is that, in truth, double int is too fat. 99.something% of all
constants fit in 1 hwi and that is likely to be true forever (i understand
that tree vpn may need some thought here).  The rtl level, which has, for as
long as i have known it, had 2 reps for integer constants. So it was
relatively easy to slide the CONST_WIDE_INT in.  It seems like the right
trickery here rather than adding a storage model for wide-ints might be a
way to use the c++ to invisibly support several (and by "several" i really
mean 2) classes of TREE_CSTs.

The truth is that _now_ TREE_INT_CSTs use double-ints and we have
CONST_INT and CONST_DOUBLE.  What I (and you) propose would
get us to use variable-size storage for both, allowing to just use a single
HOST_WIDE_INT in the majority of cases.  In my view the constant
length of the variable-size storage for TREE_INT_CSTs is determined
by its type (thus, it doesn't have "optimized" variable-size storage
but "unoptimized" fixed-size storage based on the maximum storage
requirement for the type).  Similar for RTX CONST_INT which would
have fixed-size storage based on the mode-size of the constant.
Using optimized space (thus using the encoding properties) requires you
to fit the 'short len' somewhere which possibly will not pay off in the end
(for tree we do have that storage available, so we could go with optimized
storage for it, not sure with RTL, I don't see available space there).
There are two questions here:   one is the fact that you object to the 
fact that we represent small constants efficiently and the second is 
that we take advantage of the fact that fixed size stack allocation is 
effectively free for short lived objects like wide-ints (as i use them).


At the rtl level your idea does not work.   rtl constants do not have a 
mode or type.So if you do not compress, how are you going to 
determine how many words you need for the constant 1.   I would love to 
have a rep that had the mode in it.But it is a huge change that 
requires a lot of hacking to every port.


I understand that this makes me vulnerable to the argument that we 
should not let the rtl level ever dictate anything about the tree level, 
but the truth is that a variable len rep is almost always used for big 
integers.   In our code, most constants of large types are small 
numbers.   (Remember i got into this because the tree constant prop 
thinks that left shifting any number by anything greater than 128 is 
al

Re: [PATCH][AArch64] Fix PR 56809

[Ramana Radhakrishnan]

On Wed, Apr 3, 2013 at 4:07 PM, Kyrylo Tkachov  wrote:
>
> Hi all,
>
> This patch fixes a PR that was exposed in the recent jump table
> reorganisation.
> We should use next_active_insn instead of next_real_insn in the jump table
> handling code.
>
> This fixes the incorrect assembly generation that we get when building
> newlib for aarch64.
>
> Tested aarch64-none-elf.
> A testcase to gcc.dg is added with the separate arm patch.
>
> Ok for trunk?


As discussed on IRC - given this is identical to the changes in the
ARM backend go ahead and commit this as obvious.

If there are any issues we can always revert this.

Ramana
>
>
> Thanks,
> Kyrill
>
> gcc/ChangeLog
>
> 2013-04-03  Kyrylo Tkachov  
>
> PR target/56809
> * config/aarch64/aarch64.c (is_jump_table): Use next_active_insn
> instead of
> next_real_insn.

Re: [PATCH][AArch64] Fix PR 56809

[Jakub Jelinek]

On Wed, Apr 03, 2013 at 04:07:50PM +0100, Kyrylo Tkachov wrote:
> This patch fixes a PR that was exposed in the recent jump table
> reorganisation.
> We should use next_active_insn instead of next_real_insn in the jump table
> handling code.
> 
> This fixes the incorrect assembly generation that we get when building
> newlib for aarch64.
> 
> Tested aarch64-none-elf.
> A testcase to gcc.dg is added with the separate arm patch.
> 
> Ok for trunk?

Ok, thanks.

> gcc/ChangeLog
> 
> 2013-04-03  Kyrylo Tkachov  
> 
>   PR target/56809
>   * config/aarch64/aarch64.c (is_jump_table): Use next_active_insn
> instead of
>   next_real_insn.

Jakub

Re: C++ PATCH for c++/56821 (ref-qualifier mangling)

[Jason Merrill]

And here's the demangler patch.
commit 7a39cc5b85f6f100427515c7031f7ec9fe6ac84f
Author: Jason Merrill 
Date:   Wed Apr 3 12:27:03 2013 -0400

	Demangle C++11 ref-qualifier.
include/
	* demangle.h (enum demangle_component_type): Add
	DEMANGLE_COMPONENT_REFERENCE_THIS,
	DEMANGLE_COMPONENT_RVALUE_REFERENCE_THIS.
libiberty/
	* cp-demangle.c (d_ref_qualifier): New.
	(d_nested_name, d_function_type): Use it.
	(d_parmlist): Don't get confused by a ref-qualifier.
	(cplus_demangle_type): Reorder ref-qualifier.
	(d_pointer_to_member_type): Likewise.
	(d_dump): Handle DEMANGLE_COMPONENT_REFERENCE_THIS and
	DEMANGLE_COMPONENT_RVALUE_REFERENCE_THIS.
	(d_make_comp, has_return_type, d_encoding): Likewise.
	(d_print_comp, d_print_mod_list, d_print_mod): Likewise.
	(d_print_function_type, is_ctor_or_dtor): Likewise.

diff --git a/include/demangle.h b/include/demangle.h
index ed01950..58bf547 100644
--- a/include/demangle.h
+++ b/include/demangle.h
@@ -302,6 +302,12 @@ enum demangle_component_type
   /* The const qualifier modifying a member function.  The one subtree
  is the type which is being qualified.  */
   DEMANGLE_COMPONENT_CONST_THIS,
+  /* C++11 A reference modifying a member function.  The one subtree is the
+ type which is being referenced.  */
+  DEMANGLE_COMPONENT_REFERENCE_THIS,
+  /* C++11: An rvalue reference modifying a member function.  The one
+ subtree is the type which is being referenced.  */
+  DEMANGLE_COMPONENT_RVALUE_REFERENCE_THIS,
   /* A vendor qualifier.  The left subtree is the type which is being
  qualified, and the right subtree is the name of the
  qualifier.  */
diff --git a/libiberty/cp-demangle.c b/libiberty/cp-demangle.c
index 39be031..271d3d3 100644
--- a/libiberty/cp-demangle.c
+++ b/libiberty/cp-demangle.c
@@ -382,6 +382,9 @@ static struct demangle_component **
 d_cv_qualifiers (struct d_info *, struct demangle_component **, int);
 
 static struct demangle_component *
+d_ref_qualifier (struct d_info *, struct demangle_component *);
+
+static struct demangle_component *
 d_function_type (struct d_info *);
 
 static struct demangle_component *
@@ -614,6 +617,12 @@ d_dump (struct demangle_component *dc, int indent)
 case DEMANGLE_COMPONENT_CONST_THIS:
   printf ("const this\n");
   break;
+case DEMANGLE_COMPONENT_REFERENCE_THIS:
+  printf ("reference this\n");
+  break;
+case DEMANGLE_COMPONENT_RVALUE_REFERENCE_THIS:
+  printf ("rvalue reference this\n");
+  break;
 case DEMANGLE_COMPONENT_VENDOR_TYPE_QUAL:
   printf ("vendor type qualifier\n");
   break;
@@ -893,6 +902,8 @@ d_make_comp (struct d_info *di, enum demangle_component_type type,
 case DEMANGLE_COMPONENT_RESTRICT_THIS:
 case DEMANGLE_COMPONENT_VOLATILE_THIS:
 case DEMANGLE_COMPONENT_CONST_THIS:
+case DEMANGLE_COMPONENT_REFERENCE_THIS:
+case DEMANGLE_COMPONENT_RVALUE_REFERENCE_THIS:
 case DEMANGLE_COMPONENT_ARGLIST:
 case DEMANGLE_COMPONENT_TEMPLATE_ARGLIST:
   break;
@@ -1131,6 +1142,8 @@ has_return_type (struct demangle_component *dc)
 case DEMANGLE_COMPONENT_RESTRICT_THIS:
 case DEMANGLE_COMPONENT_VOLATILE_THIS:
 case DEMANGLE_COMPONENT_CONST_THIS:
+case DEMANGLE_COMPONENT_REFERENCE_THIS:
+case DEMANGLE_COMPONENT_RVALUE_REFERENCE_THIS:
   return has_return_type (d_left (dc));
 }
 }
@@ -1186,7 +1199,9 @@ d_encoding (struct d_info *di, int top_level)
 	 v2 demangler without DMGL_PARAMS.  */
 	  while (dc->type == DEMANGLE_COMPONENT_RESTRICT_THIS
 		 || dc->type == DEMANGLE_COMPONENT_VOLATILE_THIS
-		 || dc->type == DEMANGLE_COMPONENT_CONST_THIS)
+		 || dc->type == DEMANGLE_COMPONENT_CONST_THIS
+		 || dc->type == DEMANGLE_COMPONENT_REFERENCE_THIS
+		 || dc->type == DEMANGLE_COMPONENT_RVALUE_REFERENCE_THIS)
 	dc = d_left (dc);
 
 	  /* If the top level is a DEMANGLE_COMPONENT_LOCAL_NAME, then
@@ -1200,7 +1215,9 @@ d_encoding (struct d_info *di, int top_level)
 	  dcr = d_right (dc);
 	  while (dcr->type == DEMANGLE_COMPONENT_RESTRICT_THIS
 		 || dcr->type == DEMANGLE_COMPONENT_VOLATILE_THIS
-		 || dcr->type == DEMANGLE_COMPONENT_CONST_THIS)
+		 || dcr->type == DEMANGLE_COMPONENT_CONST_THIS
+		 || dcr->type == DEMANGLE_COMPONENT_REFERENCE_THIS
+		 || dcr->type == DEMANGLE_COMPONENT_RVALUE_REFERENCE_THIS)
 		dcr = d_left (dcr);
 	  dc->u.s_binary.right = dcr;
 	}
@@ -1322,8 +1339,8 @@ d_name (struct d_info *di)
 }
 }
 
-/*  ::= N []   E
- ::= N []   E
+/*  ::= N [] []   E
+ ::= N [] []   E
 */
 
 static struct demangle_component *
@@ -1331,6 +1348,7 @@ d_nested_name (struct d_info *di)
 {
   struct demangle_component *ret;
   struct demangle_component **pret;
+  struct demangle_component *rqual;
 
   if (! d_check_char (di, 'N'))
 return NULL;
@@ -1339,10 +1357,20 @@ d_nested_name (struct d_info *di)
   if (pret == NULL)
 return NULL;
 
+  /* Parse th

[C++ Patch / RFC] Tidy c-common.c:pointer_int_sum?

[Paolo Carlini]

Hi,

earlier today I noticed that I wasn't able to construct a testcase 
tirggering this warning and decided to replace the body with a 
gcc_unreachable () and boot & test C/OBJC/C++/OBJC++. No regressions. 
Its this some sort of legacy case which can go away?


Thanks!
Paolo.

//
Index: c-common.c
===
--- c-common.c  (revision 197432)
+++ c-common.c  (working copy)
@@ -4290,12 +4290,6 @@ pointer_int_sum (location_t loc, enum tree_code re
   "pointer to a function used in arithmetic");
   size_exp = integer_one_node;
 }
-  else if (TREE_CODE (TREE_TYPE (result_type)) == METHOD_TYPE)
-{
-  pedwarn (loc, pedantic ? OPT_Wpedantic : OPT_Wpointer_arith,
-  "pointer to member function used in arithmetic");
-  size_exp = integer_one_node;
-}
   else
 size_exp = size_in_bytes (TREE_TYPE (result_type));
 

Re: [PATCH] Compute and emit working set information from gcov-dump (issue6940061)

[Jan Hubicka]

> >
> > 2012-12-14  Teresa Johnson  
> >
> > * lto-cgraph.c (input_symtab): Replace call to compute_working_sets
> > to get_working_sets.
> > * gcov-io.c (compute_working_sets): Moved most of body of old
> > compute_working_sets here from profile.c.
> > * gcov-io.h (NUM_GCOV_WORKING_SETS): Moved here from profile.c.
> > (gcov_working_set_t): Moved typedef here from basic-block.h
> > (compute_working_set): Declare.
> > * profile.c (NUM_GCOV_WORKING_SETS): Moved to gcov-io.h.
> > (get_working_sets): Renamed from compute_working_set,
> > replace most of body with call to new compute_working_sets.
> > (get_exec_counts): Replace call to compute_working_sets
> > to get_working_sets.
> > * profile.h (get_working_sets): Renamed from
> > compute_working_set.
> > * basic-block.h (gcov_working_set_t): Moved to gcov-io.h.
> > * gcov-dump.c (dump_working_sets): New function.

Looks like good idea.  We probaby couold extend gcov-dump to also compute the 
real
histogram across multiple input files and compare these two.

Patch is OK.
Thanks,
Honza

Re: [PATCH] Fix -Wformat-security warning in arm.c

[Roland McGrath]

Backport committed to gcc-4_8-branch.

Re: extend fwprop optimization

[Jakub Jelinek]

On Thu, Mar 28, 2013 at 04:49:47PM +0100, Uros Bizjak wrote:
> 2013-03-27  Wei Mi  
> 
>   * config/i386/i386.md: Do shift truncation in define_insn
>   instead of define_insn_and_split.
> 
> Please write ChangeLog as:
> 
>   * config/i386/i386.md (*ashl3_mask): Rewrite as define_insn.
>   Truncate operand 2 using %b asm operand modifier.
>   (*3_mask): Ditto.
>   (*3_mask): Ditto.
> 
> OK for mainline and all release branches with these changes.

This broke bootstrap on x86_64-linux as well as i686-linux on the 4.6
branch.  Fixed thusly, committed as obvious after bootstrapping/regtesting
on those targets.

2013-04-03  Jakub Jelinek  

* config/i386/i386.md (*3_mask): Use
 instead of .

--- gcc/config/i386/i386.md.jj  2013-04-03 16:11:07.0 +0200
+++ gcc/config/i386/i386.md 2013-04-03 17:42:15.034672014 +0200
@@ -9827,7 +9827,7 @@ (define_insn "*3_mas
&& (INTVAL (operands[3]) & (GET_MODE_BITSIZE (mode)-1))
   == GET_MODE_BITSIZE (mode)-1"
 {
-  return "{}\t{%b2, %0|%0, %b2}";
+  return "{}\t{%b2, %0|%0, %b2}";
 }
   [(set_attr "type" "ishift")
(set_attr "mode" "")])


Jakub

Re: [PATCH, committed] Fix PR 45472

[Jakub Jelinek]

On Mon, Apr 01, 2013 at 12:36:55PM +0400, Andrey Belevantsev wrote:
> Now backported to 4.7 and 4.6 with Jakub's patch for the
> sel-sched-ir.c memory leak added.

Test fixed thusly on the 4.6 branch, 4.7 branch has been apparently taken
care by Richi already.

2013-04-03  Jakub Jelinek  

* gcc.dg/pr45472.c: Remove copies.

--- gcc/testsuite/gcc.dg/pr45472.c  (revision 197437)
+++ gcc/testsuite/gcc.dg/pr45472.c  (working copy)
@@ -19,66 +19,3 @@ foo (int j, int c)
   s1 = s2;
 }
 }
-/* { dg-do compile { target powerpc*-*-* ia64-*-* x86_64-*-* } } */
-/* { dg-options "-O -fschedule-insns2 -fselective-scheduling2" } */
-
-struct S
-{
-  volatile long vl;
-  int i;
-};
-struct S s1, s2;
-
-void
-foo (int j, int c)
-{
-  int i;
-  for (i = 0; i <= j; i++)
-{
-  if (c)
-   s2.vl += s1.vl;
-  s1 = s2;
-}
-}
-/* { dg-do compile { target powerpc*-*-* ia64-*-* x86_64-*-* } } */
-/* { dg-options "-O -fschedule-insns2 -fselective-scheduling2" } */
-
-struct S
-{
-  volatile long vl;
-  int i;
-};
-struct S s1, s2;
-
-void
-foo (int j, int c)
-{
-  int i;
-  for (i = 0; i <= j; i++)
-{
-  if (c)
-   s2.vl += s1.vl;
-  s1 = s2;
-}
-}
-/* { dg-do compile { target powerpc*-*-* ia64-*-* x86_64-*-* } } */
-/* { dg-options "-O -fschedule-insns2 -fselective-scheduling2" } */
-
-struct S
-{
-  volatile long vl;
-  int i;
-};
-struct S s1, s2;
-
-void
-foo (int j, int c)
-{
-  int i;
-  for (i = 0; i <= j; i++)
-{
-  if (c)
-   s2.vl += s1.vl;
-  s1 = s2;
-}
-}

Jakub

4.6 backports

[Jakub Jelinek]

Hi!

I've backported 11 patches of mine to 4.6 branch, bootstrapped/regtested
on x86_64-linux and i686-linux, committed.

Jakub
2013-04-03  Jakub Jelinek  

Backported from mainline
2012-03-01  Jakub Jelinek  

PR tree-optimization/52445
* tree-ssa-phiopt.c (struct name_to_bb): Remove ssa_name field,
add ssa_name_ver, offset and size fields and change store field
to bool.
(name_to_bb_hash, name_to_bb_eq): Adjust for the above changes.
(add_or_mark_expr): Likewise.  Only consider previous stores
with the same size and offset.
(nt_init_block): Only look at gimple_assign_single_p stmts,
doesn't look at rhs2.

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

--- gcc/tree-ssa-phiopt.c   (revision 184742)
+++ gcc/tree-ssa-phiopt.c   (revision 184743)
@@ -1122,9 +1122,10 @@ abs_replacement (basic_block cond_bb, ba
same accesses.  */
 struct name_to_bb
 {
-  tree ssa_name;
+  unsigned int ssa_name_ver;
+  bool store;
+  HOST_WIDE_INT offset, size;
   basic_block bb;
-  unsigned store : 1;
 };
 
 /* The hash table for remembering what we've seen.  */
@@ -1133,23 +1134,26 @@ static htab_t seen_ssa_names;
 /* The set of MEM_REFs which can't trap.  */
 static struct pointer_set_t *nontrap_set;
 
-/* The hash function, based on the pointer to the pointer SSA_NAME.  */
+/* The hash function.  */
 static hashval_t
 name_to_bb_hash (const void *p)
 {
-  const_tree n = ((const struct name_to_bb *)p)->ssa_name;
-  return htab_hash_pointer (n) ^ ((const struct name_to_bb *)p)->store;
+  const struct name_to_bb *n = (const struct name_to_bb *) p;
+  return n->ssa_name_ver ^ (((hashval_t) n->store) << 31)
+ ^ (n->offset << 6) ^ (n->size << 3);
 }
 
-/* The equality function of *P1 and *P2.  SSA_NAMEs are shared, so
-   it's enough to simply compare them for equality.  */
+/* The equality function of *P1 and *P2.  */
 static int
 name_to_bb_eq (const void *p1, const void *p2)
 {
   const struct name_to_bb *n1 = (const struct name_to_bb *)p1;
   const struct name_to_bb *n2 = (const struct name_to_bb *)p2;
 
-  return n1->ssa_name == n2->ssa_name && n1->store == n2->store;
+  return n1->ssa_name_ver == n2->ssa_name_ver
+ && n1->store == n2->store
+ && n1->offset == n2->offset
+ && n1->size == n2->size;
 }
 
 /* We see the expression EXP in basic block BB.  If it's an interesting
@@ -1161,8 +1165,12 @@ static void
 add_or_mark_expr (basic_block bb, tree exp,
  struct pointer_set_t *nontrap, bool store)
 {
+  HOST_WIDE_INT size;
+
   if (TREE_CODE (exp) == MEM_REF
-  && TREE_CODE (TREE_OPERAND (exp, 0)) == SSA_NAME)
+  && TREE_CODE (TREE_OPERAND (exp, 0)) == SSA_NAME
+  && host_integerp (TREE_OPERAND (exp, 1), 0)
+  && (size = int_size_in_bytes (TREE_TYPE (exp))) > 0)
 {
   tree name = TREE_OPERAND (exp, 0);
   struct name_to_bb map;
@@ -1172,9 +1180,12 @@ add_or_mark_expr (basic_block bb, tree e
 
   /* Try to find the last seen MEM_REF through the same
  SSA_NAME, which can trap.  */
-  map.ssa_name = name;
+  map.ssa_name_ver = SSA_NAME_VERSION (name);
   map.bb = 0;
   map.store = store;
+  map.offset = tree_low_cst (TREE_OPERAND (exp, 1), 0);
+  map.size = size;
+
   slot = htab_find_slot (seen_ssa_names, &map, INSERT);
   n2bb = (struct name_to_bb *) *slot;
   if (n2bb)
@@ -1197,9 +1208,11 @@ add_or_mark_expr (basic_block bb, tree e
  else
{
  n2bb = XNEW (struct name_to_bb);
- n2bb->ssa_name = name;
+ n2bb->ssa_name_ver = SSA_NAME_VERSION (name);
  n2bb->bb = bb;
  n2bb->store = store;
+ n2bb->offset = map.offset;
+ n2bb->size = size;
  *slot = n2bb;
}
}
@@ -1219,13 +1232,10 @@ nt_init_block (struct dom_walk_data *dat
 {
   gimple stmt = gsi_stmt (gsi);
 
-  if (is_gimple_assign (stmt))
+  if (gimple_assign_single_p (stmt))
{
  add_or_mark_expr (bb, gimple_assign_lhs (stmt), nontrap_set, true);
  add_or_mark_expr (bb, gimple_assign_rhs1 (stmt), nontrap_set, false);
- if (get_gimple_rhs_num_ops (gimple_assign_rhs_code (stmt)) > 1)
-   add_or_mark_expr (bb, gimple_assign_rhs2 (stmt), nontrap_set,
- false);
}
 }
 }
--- gcc/testsuite/gcc.dg/pr52445.c  (revision 0)
+++ gcc/testsuite/gcc.dg/pr52445.c  (revision 184743)
@@ -0,0 +1,15 @@
+/* PR tree-optimization/52445 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -ftree-cselim -fdump-tree-cselim" } */
+
+void
+foo (char *buf, unsigned long len)
+{
+  buf[0] = '\n';
+  if (len > 1)
+buf[1] = '\0'; /* We can't cselim "optimize" this, while
+  buf[0] doesn't trap, buf[1] could.  */
+}
+
+/* { dg-final { scan-tree-dump-not "cstore\." "cselim" } } */
+/* { dg-final { cleanup-tree-dump "cselim" } } *

GCC 4.6.4 Status Report (2013-04-03)

[Jakub Jelinek]

Status
==

The GCC 4.6 branch is ready for a release candidate of GCC 4.6.4
which I will do on Friday if no serious issue shows up until then.
The branch is frozen now, all changes require release manager approval.
The final release should happen roughly one week after the release
candidate, after the release the 4.6 branch will be closed.

Quality Data


Priority  # Change from Last Report
--- ---
P10 +- 0
P2   95 -  8
P3   36 + 24
--- ---
Total   131 + 16

Previous Report
===

http://gcc.gnu.org/ml/gcc/2012-03/msg6.html

The next report will be sent by me after the release.

[PATCH] PR56799

[Jeff Law]

Per Richi's suggestions I tweaked the recent tree-ssa-dom.c equivalence 
code to use int_fits_type_p rather than creating a new integer node and 
verifying it had the same value as the old node.


At the time I dropped the TYPE_PRECISION check as I thought it was 
redundant with the int_fits_type_p tests.  However int_fits_type_p only 
checks for a widening precision if it can't prove the constant fits 
within the bounds of the new type.


Thus we could record an equivalence after a narrowing conversion, which 
is wrong in this particular case.


Fixed by adding the TYPE_PRECISION checks back.

Bootstrapped & regression tested on x86_64-unknown-linux-gnu.  Installed.

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 1e25a82..a3b60c9 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,10 @@
+2013-04-03  Jeff Law  
+
+   PR tree-optimization/56799
+* tree-ssa-dom.c (record_equivalences_from_incoming_edge): Bring
+   back test for widening conversion erroneously dropped in prior
+   change.
+
 2013-04-03  Kyrylo Tkachov  
 
PR target/56809
@@ -896,6 +903,7 @@
* config/tilegx/tilepro.h (PROFILE_BEFORE_PROLOGUE): Define.
 
 2013-03-25  Jeff Law  
+
 * tree-ssa-dom.c (record_equivalences_from_incoming_edge): Add missing
 check for INTEGRAL_TYPE_P that was missing due to checking in
wrong version of prior patch.
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 2cc5fa8..dc0b745 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2013-04-03  Jeff Law  
+
+   PR tree-optimization/56799
+   * gcc.c-torture/execute/pr56799.c: New test.
+
 2013-04-03  Paolo Carlini  
 
PR c++/56815
diff --git a/gcc/testsuite/gcc.c-torture/execute/pr56799.c 
b/gcc/testsuite/gcc.c-torture/execute/pr56799.c
new file mode 100644
index 000..d9ee26b
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/execute/pr56799.c
@@ -0,0 +1,43 @@
+
+#include 
+typedef struct { int x; int y;} S;
+extern int foo(S*);
+int hi = 0, lo = 0;
+
+int main()
+{
+  S a;
+  int r;
+  a.x = (int) 0x0001;
+  a.y = 1;
+  r = foo (&a);
+  if (r == 2 && lo==0 && hi==1)
+{
+  exit (0);
+}
+  abort ();
+}
+
+typedef unsigned short u16;
+
+__attribute__ ((noinline)) int foo (S* ptr)
+{
+  int a = ptr->x;
+  int c = 0;
+  u16 b = (u16) a;
+  if (b != 0)
+  {
+lo = 1;
+c += ptr->y;
+  }
+  b = a >> 16;
+  if (b != 0)
+  {
+hi = 1;
+c+= ptr->y;
+  }
+  c += ptr->y;
+  return c;
+}
+
+ 
diff --git a/gcc/tree-ssa-dom.c b/gcc/tree-ssa-dom.c
index 29d2bb4..d98a646 100644
--- a/gcc/tree-ssa-dom.c
+++ b/gcc/tree-ssa-dom.c
@@ -1151,9 +1151,15 @@ record_equivalences_from_incoming_edge (basic_block bb)
{
  tree old_rhs = gimple_assign_rhs1 (defstmt);
 
- /* If the constant is in the range of the type of OLD_RHS,
-then convert the constant and record the equivalence.  */
+ /* If the conversion widens the original value and
+the constant is in the range of the type of OLD_RHS,
+then convert the constant and record the equivalence. 
+
+Note that int_fits_type_p does not check the precision
+if the upper and lower bounds are OK.  */
  if (INTEGRAL_TYPE_P (TREE_TYPE (old_rhs))
+ && (TYPE_PRECISION (TREE_TYPE (lhs))
+ > TYPE_PRECISION (TREE_TYPE (old_rhs)))
  && int_fits_type_p (rhs, TREE_TYPE (old_rhs)))
{
  tree newval = fold_convert (TREE_TYPE (old_rhs), rhs);

[wwwdocs] Updating svn.html

[Iyer, Balaji V]

Hello,
I would like to add information about the Cilkplus branch into the 
svn.html webpage. Here is the patch for it (I generated it using cvs diff -p 
svn.html). Is this OK to commit? Am I sending this to the correct 
location/mailing list?

Thanks,

Balaji V. Iyer.



Index: svn.html
*** svn.html29 Mar 2013 17:07:16 -  1.182
--- svn.html3 Apr 2013 18:43:15 -
*** the command svn log --stop-on-copy
*** 523,528 
--- 523,536 
variable template for C++.  It is maintained by
mailto:g...@gcc.gnu.org";>Gabriel Dos Reis.

+   cilkplus
+   This branch is for the development of
+ http://www.cilkplus.org";>Cilk Plus language extension support
+ on GCC and G++ compilers.  This branch is maintained by
+ mailto:balaji.v.i...@intel.com";>Balaji V. Iyer.
+ Patches to this branch must be prefixed with [cilkplus] in 
the
+ subject line.  It is also highly encouraged to CC the maintainer.
+
  

  Distribution Branches

Re: Fill more delay slots in conditional returns

[Steven Bosscher]

On Tue, Apr 2, 2013 at 6:56 PM, Steven Bosscher wrote:
> The SPARC back
> end also calls dbr_schedule() in its machine_reorg pass to work around
> errata in Atmel AT697F chips (LEON2-like, i.e. fairly new, see
> r179921).

Thinking about this some more: This could be fixed by inserting a
machine-specific pass just after delayed-branch scheduling, like in
the attached patch. I think the same is possible with the dbr_schedule
call in the MIPS backend.

Eric, what do you think of this approach?

With those two dbr_schedule calls out of the way, it will be a lot
easier to change things such that pass_free_cfg can run after
pass_machine_reorg (and after pass_cleanup_barriers that can be
simplified if there's still a CFG around). It will also help make the
DELAY_SLOTS hack in cfgrtl.c:rest_of_pass_free_cfg redundant.

I'm unsure how to test this patch. It's going through a bootstrap&test
cycle on sparc64-unknown-linux-gnu at the moment (on gcc62) but there
are no test cases for the errata that are being worked around...

Ciao!
Steven
* config/sparc/sparc.c: Include tree-pass.h.
(TARGET_MACHINE_DEPENDENT_REORG): Do not redefine.
(sparc_reorg): Rename to sparc_do_work_around_errata.  Move to
head of file.  Change return type.  Split off gate function.
(sparc_gate_work_around_errata): New function.
(pass_work_around_errata): New pass definition.
(insert_pass_work_around_errata) New pass insert definition to
insert pass_work_around_errata just after delayed-branch scheduling.
(sparc_option_override): Insert the pass.

Index: config/sparc/sparc.c
===
--- config/sparc/sparc.c(revision 197452)
+++ config/sparc/sparc.c(working copy)
@@ -52,6 +52,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "params.h"
 #include "df.h"
 #include "opts.h"
+#include "tree-pass.h"
 
 /* Processor costs */
 
@@ -538,7 +539,6 @@ static void sparc_output_mi_thunk (FILE *, tree, H
   HOST_WIDE_INT, tree);
 static bool sparc_can_output_mi_thunk (const_tree, HOST_WIDE_INT,
   HOST_WIDE_INT, const_tree);
-static void sparc_reorg (void);
 static struct machine_function * sparc_init_machine_status (void);
 static bool sparc_cannot_force_const_mem (enum machine_mode, rtx);
 static rtx sparc_tls_get_addr (void);
@@ -680,9 +680,6 @@ char sparc_hard_reg_printed[8];
 #undef TARGET_ASM_CAN_OUTPUT_MI_THUNK
 #define TARGET_ASM_CAN_OUTPUT_MI_THUNK sparc_can_output_mi_thunk
 
-#undef TARGET_MACHINE_DEPENDENT_REORG
-#define TARGET_MACHINE_DEPENDENT_REORG sparc_reorg
-
 #undef TARGET_RTX_COSTS
 #define TARGET_RTX_COSTS sparc_rtx_costs
 #undef TARGET_ADDRESS_COST
@@ -804,6 +801,136 @@ char sparc_hard_reg_printed[8];
 
 struct gcc_target targetm = TARGET_INITIALIZER;
 
+/* We use the machine specific reorg pass to enable workarounds for errata.
+   We need to have the (essentially) final form of the insn stream in order
+   to properly detect the various hazards.  Therefore, this machine specific
+   pass runs as late as possible.  The pass is inserted in the pass pipeline
+   at the end of sparc_options_override().  */
+
+static bool
+sparc_gate_work_arround_errata (void)
+{
+  /* The only erratum we handle for now is that of the AT697F processor.  */
+  return sparc_fix_at697f != 0;
+}
+
+static unsigned int
+sparc_do_work_around_errata (void)
+{
+  rtx insn, next;
+
+  /* Now look for specific patterns in the insn stream.  */
+  for (insn = get_insns (); insn; insn = next)
+{
+  bool insert_nop = false;
+  rtx set;
+
+  /* Look for a single-word load into an odd-numbered FP register.  */
+  if (NONJUMP_INSN_P (insn)
+ && (set = single_set (insn)) != NULL_RTX
+ && GET_MODE_SIZE (GET_MODE (SET_SRC (set))) == 4
+ && MEM_P (SET_SRC (set))
+ && REG_P (SET_DEST (set))
+ && REGNO (SET_DEST (set)) > 31
+ && REGNO (SET_DEST (set)) % 2 != 0)
+   {
+ /* The wrong dependency is on the enclosing double register.  */
+ unsigned int x = REGNO (SET_DEST (set)) - 1;
+ unsigned int src1, src2, dest;
+ int code;
+
+ /* If the insn has a delay slot, then it cannot be problematic.  */
+ next = next_active_insn (insn);
+ if (NONJUMP_INSN_P (next) && GET_CODE (PATTERN (next)) == SEQUENCE)
+   code = -1;
+ else
+   {
+ extract_insn (next);
+ code = INSN_CODE (next);
+   }
+
+ switch (code)
+   {
+   case CODE_FOR_adddf3:
+   case CODE_FOR_subdf3:
+   case CODE_FOR_muldf3:
+   case CODE_FOR_divdf3:
+ dest = REGNO (recog_data.operand[0]);
+ src1 = REGNO (recog_data.operand[1]);
+ src2 = REGNO (recog_data.operand[2]);
+ if (src1 != src2)
+   {
+ /* 

Re: patch to fix constant math - first small patch - patch ping for the next stage 1

[Kenneth Zadeck]

committed as revision 197456

kenny
On 04/03/2013 08:05 AM, Richard Biener wrote:

On Wed, Apr 3, 2013 at 12:47 PM, Kenneth Zadeck
 wrote:

yes, i had caught that when i merged it in with the patches that used it, is
it ok aside from that?

Yes.

Thanks,
Richard.


kenny

On 04/03/2013 05:32 AM, Richard Biener wrote:

On Tue, Apr 2, 2013 at 9:08 PM, Kenneth Zadeck 
wrote:

this time for sure.

Almost ...

diff --git a/gcc/hwint.c b/gcc/hwint.c
index 330b42c..92d54a3 100644
--- a/gcc/hwint.c
+++ b/gcc/hwint.c
@@ -204,3 +204,35 @@ least_common_multiple (HOST_WIDE_INT a, HOST_WIDE_INT
b)
   {
 return mul_hwi (abs_hwi (a) / gcd (a, b), abs_hwi (b));
   }
+
+#ifndef ENABLE_CHECKING

#ifdef ENABLE_CHECKING

+/* Sign extend SRC starting from PREC.  */
+
+HOST_WIDE_INT
+sext_hwi (HOST_WIDE_INT src, unsigned int prec)
+{
+  gcc_checking_assert (prec <= HOST_BITS_PER_WIDE_INT);
+

Ok with that change.  (maybe catch one random use of the pattern
in code and use the helpers - that would have catched this issue)

Thanks,
Richard.




kenny

On 04/02/2013 10:54 AM, Richard Biener wrote:

On Tue, Apr 2, 2013 at 3:49 PM, Kenneth Zadeck

wrote:

Richard,

did everything that you asked here.  bootstrapped and regtested on
x86-64.
ok to commit?

diff --git a/gcc/hwint.c b/gcc/hwint.c
index 330b42c..7e5b85c 100644
--- a/gcc/hwint.c
+++ b/gcc/hwint.c
@@ -204,3 +204,33 @@ least_common_multiple (HOST_WIDE_INT a,
HOST_WIDE_INT
b)
{
  return mul_hwi (abs_hwi (a) / gcd (a, b), abs_hwi (b));
}
+
+#ifndef ENABLE_CHECKING
+/* Sign extend SRC starting from PREC.  */
+
+HOST_WIDE_INT
+sext_hwi (HOST_WIDE_INT src, unsigned int prec)

this should go to hwint.h, and without the masking of prec.
while ...

diff --git a/gcc/hwint.h b/gcc/hwint.h
index da62fad..9dddf05 100644
--- a/gcc/hwint.h
+++ b/gcc/hwint.h
@@ -276,4 +316,42 @@ extern HOST_WIDE_INT pos_mul_hwi (HOST_WIDE_INT,
HOST_WIDE_INT);
extern HOST_WIDE_INT mul_hwi (HOST_WIDE_INT, HOST_WIDE_INT);
extern HOST_WIDE_INT least_common_multiple (HOST_WIDE_INT,
HOST_WIDE_INT);

+/* Sign extend SRC starting from PREC.  */
+
+#ifdef ENABLE_CHECKING
+extern HOST_WIDE_INT sext_hwi (HOST_WIDE_INT, unsigned int);
+#else
+static inline HOST_WIDE_INT
+sext_hwi (HOST_WIDE_INT src, unsigned int prec)
+{
+  gcc_checking_assert (prec <= HOST_BITS_PER_WIDE_INT);

this should go to hwint.c (also without masking prec).

Richard.





kenny


On 04/02/2013 05:38 AM, Richard Biener wrote:

On Sun, Mar 31, 2013 at 7:51 PM, Kenneth Zadeck
 wrote:

richard,

I was able to add everything except for the checking asserts.
While
I
think that this is a reasonable idea, it is difficult to add that to
a
function that is defined in hwint.h because of circular includes.   I
could
move this another file (though this appears to be the logical correct
place
for it), or we can do without the asserts.

The context is that [sz]ext_hwi is that are used are over the
compiler
but
are generally written out long.   The wide-int class uses them also,
but
wide-int did not see like the right place for them to live and i
believe
that you suggested that i move them.

ok to commit, or do you have a suggested resolution to the assert
issue?

Yes, do

#ifdef ENABLE_CHECKING
extern HOST_WIDE_INT sext_hwi (HOST_WIDE_INT, unsigned int);
#else
+/* Sign extend SRC starting from PREC.  */
+
+static inline HOST_WIDE_INT
+sext_hwi (HOST_WIDE_INT src, unsigned int prec)
+{
+  if (prec == HOST_BITS_PER_WIDE_INT)
+return src;
+  else
+{
int shift = HOST_BITS_PER_WIDE_INT - prec;
+  return (src << shift) >> shift;
+}
+}
#endif

and for ENABLE_CHECKING only provide an out-of-line implementation
in hwint.c.  That's how we did it with abs_hwi (well, we just do not
provide
an inline variant there - that's another possibility).

Note that hwint.h is always included after config.h so the
ENABLE_CHECKING
definition should be available.

Richard.


kenny


On 03/27/2013 10:13 AM, Richard Biener wrote:

On Wed, Feb 27, 2013 at 1:22 AM, Kenneth Zadeck
 wrote:

Here is the first of my wide int patches with joseph's comments and
the
patch rot removed.

I would like to get these pre approved for the next stage 1.

+  int shift = HOST_BITS_PER_WIDE_INT - (prec &
(HOST_BITS_PER_WIDE_INT - 1));

I think this should gcc_checking_assert that prec is not out of
range
(any reason why prec is signed int and not unsigned int?) rather
than
ignore bits in prec.

+static inline HOST_WIDE_INT
+zext_hwi (HOST_WIDE_INT src, int prec)
+{
+  if (prec == HOST_BITS_PER_WIDE_INT)
+return src;
+  else
+return src & (((HOST_WIDE_INT)1
+  << (prec & (HOST_BITS_PER_WIDE_INT - 1))) - 1);
+}

likewise.  Also I'm not sure I agree about the signedness of the
result
/
src.
zext_hwi (-1, HOST_BITS_PER_WIDE_INT) < 0 is true which is odd.

The patch misses context of uses, so I'm not sure what the above
functions
are intended to do.

Richard.


On 10/05/2012 08:14 PM, Joseph S. Myers wrote:

On Fri, 5 Oct 2012, Ke

Re: [C++ Patch / RFC] Tidy c-common.c:pointer_int_sum?

[Paolo Carlini]

.. I analyzed a bit what is happening and this is what I see: the only 
interesting case is that of C++, where pointer_int_sum is called via 
cp_pointer_int_sum. The latter is only called by cp_build_binary_op but 
that happens for MINUS_EXPR and PLUS_EXPR as operator. In such cases 
however, only operands with POINTER_TYPE as TREE_TYPE are passed to 
cp_pointer_int_sum. AFAICS this never happens for actual pointers to 
(non-static) member function, eg, for:


struct A { void f(); };

auto p = &A::f + 1;

the TREE_TYPE of the first operand is RECORD_TYPE (the TREE_CODE is 
PTRMEM_CST).


On the other hand, for static member functions the representation uses 
as TREE_TYPE a POINTER_TYPE to FUNCTION_TYPE, which is correctly handled 
by pointer_int_sum.


Paolo.

Re: extend fwprop optimization

[Wei Mi]

Thanks for helping fixing it. I will take care to verify regression
and bootstrap before checkin to release branches next time.

Regards,
Wei.

On Wed, Apr 3, 2013 at 11:08 AM, Jakub Jelinek  wrote:
> On Thu, Mar 28, 2013 at 04:49:47PM +0100, Uros Bizjak wrote:
>> 2013-03-27  Wei Mi  
>>
>>   * config/i386/i386.md: Do shift truncation in define_insn
>>   instead of define_insn_and_split.
>>
>> Please write ChangeLog as:
>>
>>   * config/i386/i386.md (*ashl3_mask): Rewrite as define_insn.
>>   Truncate operand 2 using %b asm operand modifier.
>>   (*3_mask): Ditto.
>>   (*3_mask): Ditto.
>>
>> OK for mainline and all release branches with these changes.
>
> This broke bootstrap on x86_64-linux as well as i686-linux on the 4.6
> branch.  Fixed thusly, committed as obvious after bootstrapping/regtesting
> on those targets.
>
> 2013-04-03  Jakub Jelinek  
>
> * config/i386/i386.md (*3_mask): Use
>  instead of .
>
> --- gcc/config/i386/i386.md.jj  2013-04-03 16:11:07.0 +0200
> +++ gcc/config/i386/i386.md 2013-04-03 17:42:15.034672014 +0200
> @@ -9827,7 +9827,7 @@ (define_insn "*3_mas
> && (INTVAL (operands[3]) & (GET_MODE_BITSIZE (mode)-1))
>== GET_MODE_BITSIZE (mode)-1"
>  {
> -  return "{}\t{%b2, %0|%0, %b2}";
> +  return "{}\t{%b2, %0|%0, %b2}";
>  }
>[(set_attr "type" "ishift")
> (set_attr "mode" "")])
>
>
> Jakub

Re: [C++ Patch / RFC] Tidy c-common.c:pointer_int_sum?

[Jason Merrill]

Ok.

Jason

Re: [PATCH] Compute and emit working set information from gcov-dump (issue6940061)

[Teresa Johnson]

On Wed, Apr 3, 2013 at 10:52 AM, Jan Hubicka  wrote:
>> >
>> > 2012-12-14  Teresa Johnson  
>> >
>> > * lto-cgraph.c (input_symtab): Replace call to compute_working_sets
>> > to get_working_sets.
>> > * gcov-io.c (compute_working_sets): Moved most of body of old
>> > compute_working_sets here from profile.c.
>> > * gcov-io.h (NUM_GCOV_WORKING_SETS): Moved here from profile.c.
>> > (gcov_working_set_t): Moved typedef here from basic-block.h
>> > (compute_working_set): Declare.
>> > * profile.c (NUM_GCOV_WORKING_SETS): Moved to gcov-io.h.
>> > (get_working_sets): Renamed from compute_working_set,
>> > replace most of body with call to new compute_working_sets.
>> > (get_exec_counts): Replace call to compute_working_sets
>> > to get_working_sets.
>> > * profile.h (get_working_sets): Renamed from
>> > compute_working_set.
>> > * basic-block.h (gcov_working_set_t): Moved to gcov-io.h.
>> > * gcov-dump.c (dump_working_sets): New function.
>
> Looks like good idea.  We probaby couold extend gcov-dump to also compute the 
> real
> histogram across multiple input files and compare these two.

cc'ing Rong Xu - he has a tool under development that he plans to
contribute upstream which does both offline merging of different sets
of profile data, and full, exact recomputation of the histogram. I'm
using an early version of his tool right now to compare the accuracy
of the libgcov-merged histogram to the exactly merged histogram (I'll
update the thread on that hopefully later today).

>
> Patch is OK.

Thanks, committed.

Teresa

> Thanks,
> Honza



--
Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413

Re: [Patch, Fortran, OOP] PR 56284: ICE with alternate return in type-bound procedure

[Janus Weil]

Ok, here is the follow-up patch, which removes the warning on
(alternate) RETURN statements, in order to avoid double diagnostics.

However, it also adds another warning for alternate-return actual
arguments (in addition to the formal ones), in order to catch
additional cases, which were not warned for up to now (e.g.
altreturn_{1,4}). Unfortunately this again introduces some potentially
redundant warnings, but I hope this is not too bad.

The patch also adds -std=gnu consistently for all altreturn_* cases.
(In altreturn_5.f90 there apparently were some superfluous control
characters, which were removed by my editor.)

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

Cheers,
Janus


2013-04-03  Janus Weil  

PR fortran/40881
* match.c (gfc_match_return): Remove standard notification.
* primary.c (gfc_match_actual_arglist): Add standard notification.

2013-04-03  Janus Weil  

PR fortran/40881
* gfortran.dg/altreturn_1.f90: Add -std=gnu.
* gfortran.dg/altreturn_4.f90: Ditto.
* gfortran.dg/altreturn_3.f90: Replace -std=legacy by -std=gnu.
* gfortran.dg/altreturn_5.f90: Ditto.
* gfortran.dg/altreturn_6.f90: Ditto.
* gfortran.dg/altreturn_7.f90: Ditto.




2013/4/3 Janus Weil :
 Regarding the second point, one should mention that we already have a
 warning for "alternate return", but this only triggers if there is an
 actual RETURN statement (which is not the case for the test code in
 the PR). The warning I'm adding triggers on the appearance of an
 asterisk argument.
>>>
>>> Shouldn't one then remove the other warning, which should be then
>>> unreachable? If so, please do so.
>>
>> Yes, will do so in a follow-up patch.
>>
>>
 This induces a certain redundancy, i.e. we warn about both the
 alternate-return argument and the alternate RETURN statement. The
 question is if we want to keep this, or whether on can remove the old
 warning for the RETURN statement (which could be done in a follow-up
 patch).
>>>
>>> Or it is not unreachable but leads to double-diagnostic which is not better,
>>> either.
>>
>> Right.
>>
 The patch is regtested on x86_64-unknown-linux-gnu. Ok for trunk?
>>>
>>> OK with the -std= change. (Please run "make
>>> RUNTESTFLAGS="dg.exp=..f90" prior committal to check whether it indeed
>>> works with -std=gnu.)
>>
>> All of them still work with std=gnu.
>
> I have just committed the patch as 197389.
>
> Will take care of removing the double diagnostics next. Also I just
> noticed that there still seem to be cases where one does not get a
> warning for alternate return (such as altreturn_1 and altreturn_4 in
> the testsuite).
>
> Cheers,
> Janus
>
>
 2013-04-01  Janus Weil  

  PR fortran/56284
  PR fortran/40881
  * decl.c (gfc_match_formal_arglist): Warn about alternate-return
  arguments.
  * interface.c (check_dummy_characteristics): Return if symbols are
 NULL.

 2013-04-01  Janus Weil  

  PR fortran/56284
  PR fortran/40881
  * gfortran.dg/altreturn_8.f90: New.
  * gfortran.dg/altreturn_2.f90: Add -std=legacy.
  * gfortran.dg/intrinsic_actual_3.f90: Ditto.
  * gfortran.dg/invalid_interface_assignment.f90: Ditto.
>>>
>>>


altreturn.diff
Description: Binary data

Re: [Patch, Fortran] PR50269 - Add some checking fixes for C_LOC

[Mikael Morin]

Le 02/04/2013 18:26, Tobias Burnus a écrit :
> diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
> index 99174bc..b0c831e 100644
> --- a/gcc/fortran/check.c
> +++ b/gcc/fortran/check.c
> @@ -3649,11 +3649,12 @@ gfc_check_sizeof (gfc_expr *arg)
>  /* Check whether an expression is interoperable.  When returning false,
> msg is set to a string telling why the expression is not interoperable,
> otherwise, it is set to NULL.  The msg string can be used in diagnostics.
> -   If all_len_okay is true, all length-type parameters (for character) are
> -   allowed.  Required for C_LOC (cf. Fortran 2003corr5 or Fortran 2008).  */
> +   If c_len is true, character with len > 1 are allowed (cf. Fortran
s/c_len/c_loc/ (or s/c_loc/c_len/ everywhere else).

> +   2003corr5); additionally, assumed-shape/assumed-rank/deferred-shape
> +   arrays are permitted.  */
>  
>  static bool
> -is_c_interoperable (gfc_expr *expr, const char **msg, bool all_len_okay)
> +is_c_interoperable (gfc_expr *expr, const char **msg, bool c_loc)



> Build + regtested on x86-64-gnu-linux.
> OK for the trunk?
>
OK

Re: [Patch, Fortran] PR56810 - fix I/O READ of COMPLEX with repeat count

[Mikael Morin]

Le 02/04/2013 19:19, Tobias Burnus a écrit :
>  {
>snprintf (message, MSGLEN,
> "Read kind %d %s where kind %d is required for item %d",
> -   dtp->u.p.saved_length, type_name (dtp->u.p.saved_type), len,
> +   type == BT_COMPLEX ? dtp->u.p.saved_length / 2
> +  : type == BT_COMPLEX,
thinko?

> +   type_name (dtp->u.p.saved_type), kind,
> dtp->u.p.item_count);
>generate_error (&dtp->common, LIBERROR_READ_VALUE, message);
>return 1;

Re: [Patch, Fortran] PR56810 - fix I/O READ of COMPLEX with repeat count

[Tobias Burnus]

Am 04.04.2013 00:27, schrieb Mikael Morin:

Le 02/04/2013 19:19, Tobias Burnus a écrit :

  {
snprintf (message, MSGLEN,
  "Read kind %d %s where kind %d is required for item %d",
- dtp->u.p.saved_length, type_name (dtp->u.p.saved_type), len,
+ type == BT_COMPLEX ? dtp->u.p.saved_length / 2
+: type == BT_COMPLEX,

thinko?


Rather "copy&pasto": Obviously, it should be ": dtp->u.p.saved_length," 
in the last line.


OK with that changed (after regtesting)?

Tobias

C++ PATCH to correct mangling/demangling of cv-qualified function types

[Jason Merrill]

While I was working on the ref-qualifier mangling, I noticed that we 
were handling function-cv-quals wrong; those quals should be considered 
an indivisible part of the function type rather than a separate qualifier.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit 6af1b337883b2c88e6411f24d8cb7bf2a76ea94e
Author: Jason Merrill 
Date:   Wed Apr 3 12:37:41 2013 -0400

libiberty/
	* cp-demangle.c (cplus_demangle_type): Fix function quals.
	(d_pointer_to_member_type): Simplify.
gcc/cp/
	* mangle.c (write_type): When writing a function type with
	function-cv-quals, don't add the unqualified type as a
	substitution candidate.

diff --git a/gcc/common.opt b/gcc/common.opt
index bdbd3b6..e02e7ed 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -792,6 +792,11 @@ Driver Undocumented
 ; 7: The version of the ABI that treats nullptr_t as a builtin type and
 ;corrects the mangling of lambdas in default argument scope.
 ;First selectable in G++ 4.8.
+;
+; 8: The version of the ABI that corrects the substitution behavior of
+;function types with function-cv-qualifiers.
+;First selectable in G++ 4.9.
+;
 ; Additional positive integers will be assigned as new versions of
 ; the ABI become the default version of the ABI.
 fabi-version=
diff --git a/gcc/cp/mangle.c b/gcc/cp/mangle.c
index 4e68c51..83c3e62 100644
--- a/gcc/cp/mangle.c
+++ b/gcc/cp/mangle.c
@@ -1897,8 +1897,16 @@ write_type (tree type)
   tree t = TYPE_MAIN_VARIANT (type);
   if (TREE_CODE (t) == FUNCTION_TYPE
 	  || TREE_CODE (t) == METHOD_TYPE)
-	t = build_ref_qualified_type (t, type_memfn_rqual (type));
-  write_type (t);
+	{
+	  t = build_ref_qualified_type (t, type_memfn_rqual (type));
+	  if (abi_version_at_least (8))
+	/* Avoid adding the unqualified function type as a substitution.  */
+	write_function_type (t);
+	  else
+	write_type (t);
+	}
+  else
+	write_type (t);
 }
   else if (TREE_CODE (type) == ARRAY_TYPE)
 /* It is important not to use the TYPE_MAIN_VARIANT of TYPE here
diff --git a/gcc/testsuite/g++.dg/abi/mangle62.C b/gcc/testsuite/g++.dg/abi/mangle62.C
new file mode 100644
index 000..6dbfd78
--- /dev/null
+++ b/gcc/testsuite/g++.dg/abi/mangle62.C
@@ -0,0 +1,11 @@
+// Before v8, we mistakenly treated an unqualified function type
+// as a substitution candidate for a function type with function-cv-quals.
+// Test for the conformant behavior.
+
+// { dg-options -fabi-version=0 }
+
+template  struct A { };
+// { dg-final { scan-assembler "_Z1fP1AIKFvvEFvvEE" } }
+void f (A *){}
+// { dg-final { scan-assembler "_Z1gP1AIFvvEKFvvEE" } }
+void g (A *){}
diff --git a/gcc/testsuite/g++.dg/abi/mangle62a.C b/gcc/testsuite/g++.dg/abi/mangle62a.C
new file mode 100644
index 000..fca1cb6
--- /dev/null
+++ b/gcc/testsuite/g++.dg/abi/mangle62a.C
@@ -0,0 +1,11 @@
+// Before v8, we mistakenly treated an unqualified function type
+// as a substitution candidate for a function type with function-cv-quals.
+// Test for that for backward compatibility.
+
+// { dg-options -fabi-version=7 }
+
+template  struct A { };
+// { dg-final { scan-assembler "_Z1fP1AIKFvvES0_E" } }
+void f (A *){}
+// { dg-final { scan-assembler "_Z1gP1AIFvvEKS0_E" } }
+void g (A *){}
diff --git a/libiberty/cp-demangle.c b/libiberty/cp-demangle.c
index 271d3d3..70f5438 100644
--- a/libiberty/cp-demangle.c
+++ b/libiberty/cp-demangle.c
@@ -2198,8 +2198,16 @@ cplus_demangle_type (struct d_info *di)
   pret = d_cv_qualifiers (di, &ret, 0);
   if (pret == NULL)
 	return NULL;
-  *pret = cplus_demangle_type (di);
-  if (! *pret)
+  if (d_peek_char (di) == 'F')
+	{
+	  /* cv-qualifiers before a function type apply to 'this',
+	 so avoid adding the unqualified function type to
+	 the substitution list.  */
+	  *pret = d_function_type (di);
+	}
+  else
+	*pret = cplus_demangle_type (di);
+  if (!*pret)
 	return NULL;
   if ((*pret)->type == DEMANGLE_COMPONENT_RVALUE_REFERENCE_THIS
 	  || (*pret)->type == DEMANGLE_COMPONENT_REFERENCE_THIS)
@@ -2739,53 +2747,32 @@ d_pointer_to_member_type (struct d_info *di)
 {
   struct demangle_component *cl;
   struct demangle_component *mem;
-  struct demangle_component **pmem;
 
   if (! d_check_char (di, 'M'))
 return NULL;
 
   cl = cplus_demangle_type (di);
-
-  /* The ABI specifies that any type can be a substitution source, and
- that M is followed by two types, and that when a CV-qualified
- type is seen both the base type and the CV-qualified types are
- substitution sources.  The ABI also specifies that for a pointer
- to a CV-qualified member function, the qualifiers are attached to
- the second type.  Given the grammar, a plain reading of the ABI
- suggests that both the CV-qualified member function and the
- non-qualified member function are substitution sources.  However,
- g++ does not work that way.  g++ treats only the CV-qualified
- member function as a substitution source

Re: C++ PATCH to implement C++11 ref-qualifiers

[Jason Merrill]

On 04/01/2013 03:03 PM, Jason Merrill wrote:

(FUNCTION_OR_METHOD_TYPE_CHECK): New.


It turns out that there's already a FUNC_OR_METHOD_CHECK in tree.h, so 
I'm removing this duplicate.




commit 4a01f2f261f9f0cb33bd959a80fe47782474ab18
Author: Jason Merrill 
Date:   Tue Apr 2 21:01:21 2013 -0400

	* cp-tree.h (FUNCTION_OR_METHOD_TYPE_CHECK): Remove.
	(TYPE_RAISES_EXCEPTIONS): Use FUNC_OR_METHOD_CHECK instead.
	(FUNCTION_REF_QUALIFIED, FUNCTION_RVALUE_QUALIFIED): Likewise.

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 83164a2..e1d1238 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -223,9 +223,6 @@ c-common.h, not after.
 #define BOUND_TEMPLATE_TEMPLATE_PARM_TYPE_CHECK(NODE) \
   TREE_CHECK(NODE,BOUND_TEMPLATE_TEMPLATE_PARM)
 
-#define FUNCTION_OR_METHOD_TYPE_CHECK(NODE) \
-  TREE_CHECK2(NODE,FUNCTION_TYPE,METHOD_TYPE)
-
 #if defined ENABLE_TREE_CHECKING && (GCC_VERSION >= 2007)
 #define THUNK_FUNCTION_CHECK(NODE) __extension__			\
 ({  __typeof (NODE) const __t = (NODE);	\
@@ -1888,7 +1885,7 @@ struct GTY((variable_size)) lang_type {
(for templates) or an OVERLOAD list of functions (for implicitly
declared functions).  */
 #define TYPE_RAISES_EXCEPTIONS(NODE) \
-  TYPE_LANG_SLOT_1 (FUNCTION_OR_METHOD_TYPE_CHECK (NODE))
+  TYPE_LANG_SLOT_1 (FUNC_OR_METHOD_CHECK (NODE))
 
 /* For FUNCTION_TYPE or METHOD_TYPE, return 1 iff it is declared `throw()'
or noexcept(true).  */
@@ -2536,11 +2533,11 @@ struct GTY((variable_size)) lang_decl {
 
 /* 1 iff FUNCTION_TYPE or METHOD_TYPE has a ref-qualifier (either & or &&). */
 #define FUNCTION_REF_QUALIFIED(NODE) \
-  TREE_LANG_FLAG_4 (FUNCTION_OR_METHOD_TYPE_CHECK (NODE))
+  TREE_LANG_FLAG_4 (FUNC_OR_METHOD_CHECK (NODE))
 
 /* 1 iff FUNCTION_TYPE or METHOD_TYPE has &&-ref-qualifier.  */
 #define FUNCTION_RVALUE_QUALIFIED(NODE) \
-  TREE_LANG_FLAG_5 (FUNCTION_OR_METHOD_TYPE_CHECK (NODE))
+  TREE_LANG_FLAG_5 (FUNC_OR_METHOD_CHECK (NODE))
 
 /* Returns 1 iff VAR_DECL is a construction virtual table.
DECL_VTABLE_OR_VTT_P will be true in this case and must be checked

Re: C++ PATCH to implement C++11 ref-qualifiers

[Gabriel Dos Reis]

On Wed, Apr 3, 2013 at 10:13 PM, Jason Merrill  wrote:
> On 04/01/2013 03:03 PM, Jason Merrill wrote:
>>
>> (FUNCTION_OR_METHOD_TYPE_CHECK): New.
>
>
> It turns out that there's already a FUNC_OR_METHOD_CHECK in tree.h, so I'm
> removing this duplicate.

and maybe rename the old one to what you thought was a natural name? :-)

-- Gaby

Missing dependencies in Makefile.in

[Jeff Law]

lra-constraints.c and lra-eliminations.c include optabs.h, but don't 
have a dependency on $(OPTABS_H).


This is obviously bad.

Fixed via the attached patch, which I checked with c/c++ only bootstrap.

Applied to the trunk as obvious.



commit d5bbf015a843c696478a36e3f048c92307e221c6
Author: Jeff Law 
Date:   Wed Apr 3 23:01:10 2013 -0600

   * Makefile.in (lra-constraints.o): Depend on $(OPTABS_H).
(lra-eliminations.o): Likewise.

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 52a8b36..b8a6900 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2013-04-03  Jeff Law  
+
+   * Makefile.in (lra-constraints.o): Depend on $(OPTABS_H).
+   (lra-eliminations.o): Likewise.
+
 2013-04-03  Teresa Johnson  
 
* gcov-io.c (compute_working_sets): Moved most of body of old
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 19377a9..37569ad 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -3301,12 +3301,12 @@ lra-constraints.o : lra-constraints.c $(CONFIG_H) 
$(SYSTEM_H) coretypes.h \
$(TM_H) $(RTL_H) $(REGS_H) insn-config.h insn-codes.h $(DF_H) \
$(RECOG_H) output.h addresses.h $(REGS_H) hard-reg-set.h $(FLAGS_H) \
$(FUNCTION_H) $(EXPR_H) $(BASIC_BLOCK_H) $(TM_P_H) $(EXCEPT_H) \
-   ira.h rtl-error.h $(LRA_INT_H)
+   ira.h rtl-error.h $(LRA_INT_H) $(OPTABS_H)
 lra-eliminations.o : lra-eliminations.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \
$(TM_H) $(RTL_H) $(REGS_H) insn-config.h $(DF_H) \
$(RECOG_H) output.h $(REGS_H) hard-reg-set.h $(FLAGS_H) $(FUNCTION_H) \
$(EXPR_H) $(BASIC_BLOCK_H) $(TM_P_H) $(EXCEPT_H) ira.h \
-   rtl-error.h $(LRA_INT_H)
+   rtl-error.h $(LRA_INT_H) $(OPTABS_H)
 lra-lives.o : lra-lives.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) \
$(RTL_H) $(REGS_H) insn-config.h $(DF_H) \
$(RECOG_H) output.h $(REGS_H) hard-reg-set.h $(FLAGS_H) $(FUNCTION_H) \