Re: [PATCH MIPS] Improve unaligned 32bits load on MIPS64

[Richard Sandiford]

"Pinski, Andrew"  writes:
> +  /* If TARGET_64BIT, the destination of a 32-bit "extz" or "extzv" will
> + be a DImode, create a new temp and emit a zero extend at the end.  */

"emit an extend", since it can be signed or unsigned.  OK with that change.

Nice optimisation, thanks.

Richard

[PATCH/MIPS] Fix mips_get_unaligned_mem in some cases

[Andrew Pinski]

Hi,
  The problem here is that adjust_address returns the same rtl as we
already have a BLKmode; mips_block_move_straight pass a BLKmode MEM to
mips_expand_ext_as_unaligned_load.
The following patch fixes the problem by copying the MEM after calling
adjust_address.  This does increase garbage slightly but not enough to
take a notice.  I could only get this to expose after improving
mips_block_move_straight but it could show up in otherwise.  The
testcase where it showed has already been committed as
testsuite/gcc.c-torture/compile/20120524-1.c .

OK?  Bootstrapped and tested on mips64-linux-gnu with no regressions.

ChangeLog:
* config/mips/mips.c (mips_get_unaligned_mem): Copy *op after calling
adjust_address.
Index: config/mips/mips.c
===
--- config/mips/mips.c  (revision 189542)
+++ config/mips/mips.c  (working copy)
@@ -7220,6 +7220,8 @@ mips_get_unaligned_mem (rtx *op, HOST_WI
   /* Adjust *OP to refer to the whole field.  This also has the effect
  of legitimizing *OP's address for BLKmode, possibly simplifying it.  */
   *op = adjust_address (*op, BLKmode, 0);
+  /*  Copy the RTX as adjust_address might return the original rtl. */
+  *op = copy_rtx (*op);
   set_mem_size (*op, width / BITS_PER_UNIT);
 
   /* Get references to both ends of the field.  We deliberately don't

Re: [PATCH][MIPS] Improve Octeon Pop instruction usage

[Richard Sandiford]

"Pinski, Andrew"  writes:
> +;; The POP instruction is special as it does not take into account the upper
> +;; 32bits and is documented that way.
> +(define_insn "*popcountdi2_trunc"
> +  [(set (match_operand:SI 0 "register_operand" "=d")
> +   (popcount:SI (truncate:SI (match_operand:DI 1 "register_operand" 
> "d"]
> +  "ISA_HAS_POP"
> +  "pop\t%0,%1"
> +  [(set_attr "type" "pop")
> +   (set_attr "mode" "SI")])

Just crossing the "i"s really, but we'd better check TARGET_64BIT too.
I realise we wouldn't expect to see truncate otherwise, but the pattern
wouldn't be correct for 32-bit big-endian.

OK with that change, thanks.

Richard

[Patch, Fortran] Add TS29113's C_PTRDIFF_T

[Tobias Burnus]

TS 29113 adds (a bit hidden in "9.9 Edits to clause 15") a new 
ISO_C_Binding parameter: C_PTRDIFF_T.


Build, tested, and currently regtesting on x86-64-gnu-linux.
OK for the trunk?

Tobias
2012-07-21  Tobias Burnus  

	* iso-c-binding.def (C_PTRDIFF_T): New TS29113 parameter.
	* intrinsic.texi (ISO_C_BINDING): Document it.

diff --git a/gcc/fortran/intrinsic.texi b/gcc/fortran/intrinsic.texi
index 9bc36d7..47a9fee 100644
--- a/gcc/fortran/intrinsic.texi
+++ b/gcc/fortran/intrinsic.texi
@@ -13029,11 +13029,11 @@ The @code{ISO_C_BINDING} module provides the following named constants of
 type default integer, which can be used as KIND type parameters.
 
 In addition to the integer named constants required by the Fortran 2003 
-standard, GNU Fortran provides as an extension named constants for the 
-128-bit integer types supported by the C compiler: @code{C_INT128_T, 
-C_INT_LEAST128_T, C_INT_FAST128_T}. Furthermore, if @code{__float} is
-supported in C, the named constants @code{C_FLOAT128, C_FLOAT128_COMPLEX}
-are defined.
+standard and @code{C_PTRDIFF_T} of TS 29113, GNU Fortran provides as an
+extension named constants for the 128-bit integer types supported by the
+C compiler: @code{C_INT128_T, C_INT_LEAST128_T, C_INT_FAST128_T}.
+Furthermore, if @code{__float128} is supported in C, the named constants
+@code{C_FLOAT128, C_FLOAT128_COMPLEX} are defined.
 
 @multitable @columnfractions .15 .35 .35 .35
 @item Fortran Type  @tab Named constant @tab C type@tab Extension
@@ -13060,6 +13060,7 @@ are defined.
 @item @code{INTEGER}@tab @code{C_INT_FAST128_T} @tab @code{int_fast128_t} @tab Ext.
 @item @code{INTEGER}@tab @code{C_INTMAX_T}  @tab @code{intmax_t}
 @item @code{INTEGER}@tab @code{C_INTPTR_T}  @tab @code{intptr_t}
+@item @code{INTEGER}@tab @code{C_PTRDIFF_T} @tab @code{intptr_t}  @tab TS 29113
 @item @code{REAL}   @tab @code{C_FLOAT} @tab @code{float}
 @item @code{REAL}   @tab @code{C_DOUBLE}@tab @code{double}
 @item @code{REAL}   @tab @code{C_LONG_DOUBLE}   @tab @code{long double}
diff --git a/gcc/fortran/iso-c-binding.def b/gcc/fortran/iso-c-binding.def
index f8673b9..66712ad 100644
--- a/gcc/fortran/iso-c-binding.def
+++ b/gcc/fortran/iso-c-binding.def
@@ -61,6 +61,8 @@ NAMED_INTCST (ISOCBINDING_INTMAX_T, "c_intmax_t", \
   get_int_kind_from_name (INTMAX_TYPE), GFC_STD_F2003)
 NAMED_INTCST (ISOCBINDING_INTPTR_T, "c_intptr_t", \
   get_int_kind_from_name (INTPTR_TYPE), GFC_STD_F2003)
+NAMED_INTCST (ISOCBINDING_PTRDIFF_T, "c_ptrdiff_t", \
+  get_int_kind_from_name (PTRDIFF_TYPE), GFC_STD_F2008_TS)
 NAMED_INTCST (ISOCBINDING_SIZE_T, "c_size_t", \
   gfc_index_integer_kind, GFC_STD_F2003)
 NAMED_INTCST (ISOCBINDING_SIGNED_CHAR, "c_signed_char", \

Re: [PATCH/MIPS] Fix mips_get_unaligned_mem in some cases

[Richard Sandiford]

Andrew Pinski  writes:
>   The problem here is that adjust_address returns the same rtl as we
> already have a BLKmode; mips_block_move_straight pass a BLKmode MEM to
> mips_expand_ext_as_unaligned_load.
> The following patch fixes the problem by copying the MEM after calling
> adjust_address.  This does increase garbage slightly but not enough to
> take a notice.  I could only get this to expose after improving
> mips_block_move_straight but it could show up in otherwise.  The
> testcase where it showed has already been committed as
> testsuite/gcc.c-torture/compile/20120524-1.c .
>
> OK?  Bootstrapped and tested on mips64-linux-gnu with no regressions.
>
> ChangeLog:
> * config/mips/mips.c (mips_get_unaligned_mem): Copy *op after calling
> adjust_address.
>
> Index: config/mips/mips.c
> ===
> --- config/mips/mips.c(revision 189542)
> +++ config/mips/mips.c(working copy)
> @@ -7220,6 +7220,8 @@ mips_get_unaligned_mem (rtx *op, HOST_WI
>/* Adjust *OP to refer to the whole field.  This also has the effect
>   of legitimizing *OP's address for BLKmode, possibly simplifying it.  */
>*op = adjust_address (*op, BLKmode, 0);
> +  /*  Copy the RTX as adjust_address might return the original rtl. */
> +  *op = copy_rtx (*op);

Sorry to be so picky, but I'd prefer:

  /* Create a copy of *OP that refers to the whole field.  This also has
 the effect of legitimizing *OP's address for BLKmode, possibly
 simplifying it.  */
  *op = copy_rtx (adjust_address (*op, BLKmode, 0));

OK with that change, thanks.

Richard

[Patch, Fortran, committed] Fix build failure with C

[Tobias Burnus]

Passing TREE_TYPE() to a Boolean work in C++, but fails in C. Besides, 
passing a "true" makes more sense.


Committed (Rev. ) as obvious.

Tobias
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c	(Revision 189738)
+++ gcc/fortran/trans-expr.c	(Arbeitskopie)
@@ -307,8 +307,7 @@
 	  gfc_conv_expr_descriptor (parmse, e, ss);
 
 	  if (e->rank != class_ts.u.derived->components->as->rank)
-	class_array_data_assign (&parmse->pre, ctree, parmse->expr,
- TREE_TYPE (parmse->expr));
+	class_array_data_assign (&parmse->pre, ctree, parmse->expr, true);
 	  else
 	gfc_add_modify (&parmse->pre, ctree, parmse->expr);
 	}
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog	(Revision 189738)
+++ gcc/fortran/ChangeLog	(Arbeitskopie)
@@ -1,3 +1,8 @@
+2012-07-21  Tobias Burnus  
+
+	* trans-expr.c (gfc_conv_derived_to_class): Fix argument passed
+	to class_array_data_assign.
+
 2012-07-20  Tobias Burnus  
 
 	* decl.c (gfc_verify_c_interop_param): Allow assumed-shape

[Patch, Fortran, committed] Another C++ism + Fortran-dev update

[Tobias Burnus]

I build the Fortran-dev branch with C, and it failed because of the 
previous Boolean issue, but also because decl-ordering issue, addressed 
by the attachment. I initially thought that the latter is a merge issue, 
but as it isn't, I have now fixed it first on the trunk – and then 
backported the fix to the Fortran-dev branch.


Trunk commit: Rev. 189740.
Fortran-branch: Rev. 189741.

Tobias
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c	(Revision 189738)
+++ gcc/fortran/resolve.c	(Arbeitskopie)
@@ -257,9 +257,10 @@ resolve_formal_arglist (gfc_symbol *proc)
 
   for (f = proc->formal; f; f = f->next)
 {
-  sym = f->sym;
   gfc_array_spec *as;
 
+  sym = f->sym;
+
   if (sym == NULL)
 	{
 	  /* Alternate return placeholder.  */
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog	(Revision 189739)
+++ gcc/fortran/ChangeLog	(Arbeitskopie)
@@ -1,5 +1,10 @@
 2012-07-21  Tobias Burnus  
 
+	* resolve.c (resolve_formal_arglist): Put variable
+	declaration before the first assignment.
+
+2012-07-21  Tobias Burnus  
+
 	* trans-expr.c (gfc_conv_derived_to_class): Fix argument passed
 	to class_array_data_assign.
 

[PATCH, frv-linux] Silence warning

[Jan-Benedict Glaw]

Hi!

I currently see

warning: implicit declaration of function ‘frv_ifcvt_machdep_init’

while gcc/ifcvt.c and

warning: no previous prototype for ‘frv_ifcvt_machdep_init’

while gcc/config/frv/frv.c are built.  The following patch fixes it.

MfG, JBG

gcc/
2012-07-21  Jan-Benedict Glaw  
* config/frv/frv-protos.h: Update copyright year,
include basic-block.h (for ce_if_block_t).
(frv_ifcvt_machdep_init): Declare.


diff --git a/gcc/config/frv/frv-protos.h b/gcc/config/frv/frv-protos.h
index 62e2506..97d6730 100644
--- a/gcc/config/frv/frv-protos.h
+++ b/gcc/config/frv/frv-protos.h
@@ -1,6 +1,6 @@
 /* Frv prototypes.
Copyright (C) 1999, 2000, 2001, 2003, 2004, 2005, 2007, 2008, 2009, 2010,
-   2011
+   2011, 2012
Free Software Foundation, Inc.
Contributed by Red Hat, Inc.
 
@@ -21,11 +21,13 @@ along with GCC; see the file COPYING3.  If not see
 .  */
 
 /* Define functions defined in frv.c */
+#include "basic-block.h"
 extern void frv_expand_prologue(void);
 extern void frv_expand_epilogue(bool);
 extern frv_stack_t *frv_stack_info (void);
 extern void frv_debug_stack(frv_stack_t *);
 extern int frv_initial_elimination_offset  (int, int);
+extern void frv_ifcvt_machdep_init (ce_if_block_t *ce_info 
ATTRIBUTE_UNUSED);
 
 #ifdef RTX_CODE
 extern int frv_legitimate_address_p_1  (enum machine_mode, rtx,




-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of: Gib Dein Bestes. Dann übertriff Dich selbst!
the second  :


signature.asc
Description: Digital signature

Re: [Patch, fortran] PR44354 implied-do-loop array constructors using the induction variable in the bounds

[Mikael Morin]

On 20/07/2012 22:03, Mikael Morin wrote:
> On 20/07/2012 20:16, Mikael Morin wrote:
>> I have started a regression test.
>> OK for trunk if it passes?
>>
> Unfortunately, it fails with errors like:
> 
> /home/mik/gcc4x/src/gcc/testsuite/gfortran.dg/char_pack_1.f90:55.10:
> 
> do i = i + 1, nv
>   1
> Warning: AC-IMPLIED-DO initial expression references control variable at
> (1)
> 
> FAIL: gfortran.dg/char_pack_1.f90  -O3 -fomit-frame-pointer  (test for
> excess errors)

Here is another attempt.
I moved the diagnostic code from gfc_resolve_iterator to
resolve_array_list, so that it doesn't trigger for do loops.
Regression test in progress. OK?

Mikael

2012-07-20  Mikael Morin  

	PR fortran/44354
	* array.c (sought_symbol): New variable.
	(expr_is_sought_symbol_ref, find_symbol_in_expr): New functions.
	(resolve_array_list): Check for references to the induction
	variable in the iteration bounds and issue a diagnostic if some
	are found.

2012-07-20  Mikael Morin  

	PR fortran/44354
	* gfortran.dg/array_constructor_38.f90: New test.

diff --git a/array.c b/array.c
index 51528b4..fc34f92 100644
--- a/array.c
+++ b/array.c
@@ -1718,6 +1718,50 @@ gfc_expanded_ac (gfc_expr *e)
 
 /*** Type resolution of array constructors ***/
 
+
+/* The symbol expr_is_sought_symbol_ref will try to find.  */
+static const gfc_symbol *sought_symbol = NULL;
+
+
+/* Tells whether the expression E is a variable reference to the symbol
+   in the static variable SOUGHT_SYMBOL, and sets the locus pointer WHERE
+   accordingly.
+   To be used with gfc_expr_walker: if a reference is found we don't need
+   to look further so we return 1 to skip any further walk.  */
+
+static int
+expr_is_sought_symbol_ref (gfc_expr **e, int *walk_subtrees ATTRIBUTE_UNUSED,
+			   void *where)
+{
+  gfc_expr *expr = *e;
+  locus *sym_loc = (locus *)where;
+
+  if (expr->expr_type == EXPR_VARIABLE
+  && expr->symtree->n.sym == sought_symbol)
+{
+  *sym_loc = expr->where;
+  return 1;
+}
+
+  return 0;
+}
+
+
+/* Tells whether the expression EXPR contains a reference to the symbol
+   SYM and in that case sets the position SYM_LOC where the reference is.  */
+
+static bool
+find_symbol_in_expr (gfc_symbol *sym, gfc_expr *expr, locus *sym_loc)
+{
+  int ret;
+
+  sought_symbol = sym;
+  ret = gfc_expr_walker (&expr, &expr_is_sought_symbol_ref, sym_loc);
+  sought_symbol = NULL;
+  return ret;
+}
+
+
 /* Recursive array list resolution function.  All of the elements must
be of the same type.  */
 
@@ -1726,14 +1770,46 @@ resolve_array_list (gfc_constructor_base base)
 {
   gfc_try t;
   gfc_constructor *c;
+  gfc_iterator *iter;
 
   t = SUCCESS;
 
   for (c = gfc_constructor_first (base); c; c = gfc_constructor_next (c))
 {
-  if (c->iterator != NULL
-	  && gfc_resolve_iterator (c->iterator, false) == FAILURE)
-	t = FAILURE;
+  iter = c->iterator;
+  if (iter != NULL)
+{
+	  gfc_symbol *iter_var;
+	  locus iter_var_loc;
+	 
+	  if (gfc_resolve_iterator (iter, false) == FAILURE)
+	t = FAILURE;
+
+	  /* Check for bounds referencing the iterator variable.  */
+	  gcc_assert (iter->var->expr_type == EXPR_VARIABLE);
+	  iter_var = iter->var->symtree->n.sym;
+	  if (find_symbol_in_expr (iter_var, iter->start, &iter_var_loc))
+	{
+	  if (gfc_notify_std (GFC_STD_LEGACY, "AC-IMPLIED-DO initial "
+  "expression references control variable "
+  "at %L", &iter_var_loc) == FAILURE)
+	   t = FAILURE;
+	}
+	  if (find_symbol_in_expr (iter_var, iter->end, &iter_var_loc))
+	{
+	  if (gfc_notify_std (GFC_STD_LEGACY, "AC-IMPLIED-DO final "
+  "expression references control variable "
+  "at %L", &iter_var_loc) == FAILURE)
+	   t = FAILURE;
+	}
+	  if (find_symbol_in_expr (iter_var, iter->step, &iter_var_loc))
+	{
+	  if (gfc_notify_std (GFC_STD_LEGACY, "AC-IMPLIED-DO step "
+  "expression references control variable "
+  "at %L", &iter_var_loc) == FAILURE)
+	   t = FAILURE;
+	}
+	}
 
   if (gfc_resolve_expr (c->expr) == FAILURE)
 	t = FAILURE;

! { dg-do compile }
! { dg-options "-std=f95" }
!
! PR fortran/44354
! array constructors were giving unexpected results when the ac-implied-do
! variable was used in one of the ac-implied-do bounds.
!
! Original testcase by Vittorio Zecca 
!
  I=5
  print *,(/(i,i=I,8)/) ! { dg-error "initial expression references control variable" }
  print *,(/(i,i=1,I)/) ! { dg-error "final expression references control variable" }
  print *,(/(i,i=1,50,I)/) ! { dg-error "step expression references control variable" }
  end


2012-07-20  Mikael Morin  

	PR fortran/44354
	* trans-array.c (gfc_trans_array_constructor_value):
	Evaluate the iteration bounds before the inner variable shadows
	the outer.

2012-07-20  Mikael Morin  

	PR fortran/44354
	* gfortran.dg/array_constructor_39.f90: New test.

diff --git a/trans-array.c b/trans-array.c
index d289ac3..4aaed15 1

Re: [PR52983] eliminate autoinc from debug_insn locs

[Alexandre Oliva]

On Jul 17, 2012, Richard Henderson  wrote:

> On 07/17/2012 02:36 PM, Alexandre Oliva wrote:
>> http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00300.html

> ... except that post has patch 1 repeated as patch 3.
> The actual patch 3 is missing.

> That said, the first two patches are ok.

Thanks.

> Please repost #3.

Sorry, I'd reposted it on Jul 2nd and forgot about the mistake in the
earlier posting whose URL I sent you.  Here's the 3rd patch again.

for  gcc/ChangeLog
from  Alexandre Oliva  

	PR debug/52983
	* valtrack.c (dead_debug_insert_temp): Use cleanup_auto_inc_dec.

Index: gcc/valtrack.c
===
--- gcc/valtrack.c.orig	2012-05-03 15:44:47.934692987 -0300
+++ gcc/valtrack.c	2012-05-03 15:44:52.540628548 -0300
@@ -385,7 +385,7 @@ dead_debug_insert_temp (struct dead_debu
 	breg = NULL;
   /* Cool, it's the same REG, we can use SRC.  */
   else if (dest == reg)
-	breg = copy_rtx (src);
+	breg = cleanup_auto_inc_dec (src, VOIDmode);
   else if (REG_P (dest))
 	{
 	  /* Hmm...  Something's fishy, we should be setting REG here.  */
@@ -394,7 +394,8 @@ dead_debug_insert_temp (struct dead_debu
 	  /* Ok, it's the same (hardware) REG, but with a different
 	 mode, so SUBREG it.  */
 	  else
-	breg = lowpart_subreg (GET_MODE (reg), copy_rtx (src),
+	breg = lowpart_subreg (GET_MODE (reg),
+   cleanup_auto_inc_dec (src, VOIDmode),
    GET_MODE (dest));
 	}
   else if (GET_CODE (dest) == SUBREG)
@@ -415,7 +416,8 @@ dead_debug_insert_temp (struct dead_debu
 	breg = NULL;
 	  /* Yay, we can use SRC, just adjust its mode.  */
 	  else
-	breg = lowpart_subreg (GET_MODE (reg), copy_rtx (src),
+	breg = lowpart_subreg (GET_MODE (reg),
+   cleanup_auto_inc_dec (src, VOIDmode),
    GET_MODE (dest));
 	}
   /* Oh well, we're out of luck.  */


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

Re: [Patch, Fortran] assumed-rank some bound intrinsics support, fix failures and improve diagnostcs

[Mikael Morin]

On 20/07/2012 12:19, Tobias Burnus wrote:
> Mikael: I wouldn't mind if you could have a look at the scalarizer - you
> seem to have an idea how one can implement it with minimal effort/code
> cluttering.
This is exaggerated. I just said that the scalarizer can't generate a
variable number of loops.
I can have a look next week. Could you post what is left from your
initial {l,u}bound patch? It has been raining assumed rank patches and
I'm lost now.

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

Mikael

Re: [Patch, Fortran] assumed-rank some bound intrinsics support, fix failures and improve diagnostcs

[Tobias Burnus]

Mikael Morin wrote:

On 20/07/2012 12:19, Tobias Burnus wrote:

Build and regtested on x86-64-linux.
OK for the trunk?


OK.


Thanks! Committed as Rev. 189743.


Mikael: I wouldn't mind if you could have a look at the scalarizer - you
seem to have an idea how one can implement it with minimal effort/code
cluttering.

This is exaggerated. I just said that the scalarizer can't generate a variable 
number of loops. I can have a look next week. Could you post what is left from 
your initial {l,u}bound patch? It has been raining assumed rank patches and I'm 
lost now.


Well, the good news is that the just approved/committed patch contains 
everything which I had before. It turned out that I don't need the 
scalarizer change for the current implementation.


Thus, lbound(x, dim=i) works now; as do ubound(x, dim=i) and 
size(x)/size(x,dim=i).


Only failing are:
  lbound(x) / ubound(x) / shape(x)

Thanks for offering to take a look!


In terms of pending patches, I currently only have one: The just posted 
C_PTRDIFF_T patch.


Tobias

Re: [patch] Move lowering of switches to bit tests to GIMPLE

[Steven Bosscher]

On Fri, Jul 20, 2012 at 12:41 AM, Richard Henderson  wrote:
> Notes for future cleanups:
>
>> +  /* If the targer has no lshift in word_mode, the operation will most
>> + probably not be cheap.  ??? Does GCC even work for such targets?  */
>
> Yes, it does.  We're perfectly happy to let this expand to a libcall.  
> Indeed, many teeny tiny targets don't have a full barrel shifter and only 
> implement x << 1.  See sh1, avr, etc.

Thanks for those references! I'll fix this comment with some
references into the machine descriptions of those ports.


>> +  int cost = set_src_cost (gen_rtx_ASHIFT (word_mode, const1_rtx, reg),
> ...
>> +if CST constains at least 3 bits, and "x << 1" is cheap.  The bit tests are
>
> Code is correct, comment is incorrect: 1 << x.

Fixed that now.


>> +* The compounded constant could be shifted rather than the one.  The
>> +  test would be either on the sign bit or on the least significant bit,
>> +  depending on the direction of the shift.  On some machines, the test
>> +  for the branch would be free if the bit to test is already set by the
>> +  shift operation.
>
> I'm reasonably certain that this would be an improvement for most targets.

It probably is an improvement for most targets if there are just two
target basic blocks (one for the default case, and one for all
non-default cases). With more than one target block for the
non-default cases, you have to shift the compound constant for every
test. That's why Roger didn't implement this (see
http://gcc.gnu.org/ml/gcc-patches/2003-01/msg01796.html).

I plan to implement this transformation for the simple
1-non-default-target, but it isn't very high on my TODO list...

Thanks for the review!
(Oh, and sorry for the CODE_FOR_nothing == 0 breakage! :-)

Ciao!
Steven

Re: [patch] Move lowering of switches to bit tests to GIMPLE

[Oleg Endo]

On Sat, 2012-07-21 at 14:41 +0200, Steven Bosscher wrote:
> On Fri, Jul 20, 2012 at 12:41 AM, Richard Henderson  wrote:
> > Notes for future cleanups:
> >
> >> +  /* If the targer has no lshift in word_mode, the operation will most
> >> + probably not be cheap.  ??? Does GCC even work for such targets?  */
> >
> > Yes, it does.  We're perfectly happy to let this expand to a libcall.  
> > Indeed, many teeny tiny targets don't have a full barrel shifter and only 
> > implement x << 1.  See sh1, avr, etc.
> 
> Thanks for those references! I'll fix this comment with some
> references into the machine descriptions of those ports.
> 

I think on SH the cost test in lshift_cheap_p with
gen_rtx_ASHIFT (word_mode, const1_rtx, reg), speed_p);

will always 'fail', because of sh.c (shiftcosts):
  /* There is no pattern for constant first operand.  */
  if (CONST_INT_P (XEXP (x, 0)))
return MAX_COST;

On SH3 / SH4* / SH2A there is a dynamic shift that does "reg << reg" or
"reg >> reg", which is not that expensive actually.  However, the
constant "1" must be loaded into a register first.  I'm currently trying
to brush up the shift code in SH a little bit and could add some things
to handle the "const << reg" case.  Or would it be better to make the
lshift_cheap_p try out more shifty things?

Cheers,
Oleg

Re: [patch] Move lowering of switches to bit tests to GIMPLE

[Steven Bosscher]

On Sat, Jul 21, 2012 at 3:10 PM, Oleg Endo  wrote:
> to handle the "const << reg" case.  Or would it be better to make the
> lshift_cheap_p try out more shifty things?

The simpler lshift_cheap stays, the better. It's already warty to have
to look at rtx_cost in a GIMPLE pass.

Ciao!
Steven

Re: [patch] Move lowering of switches to bit tests to GIMPLE

[Oleg Endo]

On Sat, 2012-07-21 at 15:12 +0200, Steven Bosscher wrote:
> On Sat, Jul 21, 2012 at 3:10 PM, Oleg Endo  wrote:
> > to handle the "const << reg" case.  Or would it be better to make the
> > lshift_cheap_p try out more shifty things?
> 
> The simpler lshift_cheap stays, the better. It's already warty to have
> to look at rtx_cost in a GIMPLE pass.

OK, correction in the target code it'll be then :)

Cheers,
Oleg

[PATCH] propagate anti-range to switch in tree-vrp

[Tom de Vries]

Jakub,

this patch adds propagation of anti-ranges to switches.

The test-case is this:
...
void
f3 (int s)
{
  if (s >> 3 == -2)
/* s in range [ -16, -9].  */
;
  else
{
  /* s in range ~[-16, -9], so none of the case labels can be taken.  */
  switch (s)
{
case -16:
case -12:
case -9:
  link_error ();
  break;
default:
  break;
}
}
}   
...

The call to link_error is unreachable but tree-vrp fails to analyze that.

Using the patch, the switch is replaced by the default case.

Bootstrapped and reg-tested (Ada inclusive) on x86_64.

OK for trunk?

Thanks,
- Tom

2012-07-21  Tom de Vries  

* tree-vrp.c (find_case_label_ranges): New function.
(vrp_visit_switch_stmt, simplify_switch_using_ranges): Use
find_case_label_ranges instead of find_case_label_range.  Handle second
range.

* gcc.dg/tree-ssa/vrp72.c: New test.
Index: gcc/tree-vrp.c
===
--- gcc/tree-vrp.c (revision 189508)
+++ gcc/tree-vrp.c (working copy)
@@ -6736,6 +6736,84 @@ find_case_label_range (gimple stmt, tree
 }
 }
 
+/* Searches the case label vector VEC for the ranges of CASE_LABELs that are
+   used in range VR.  The indices are placed in MIN_IDX1, MAX_IDX, MIN_IDX2 and
+   MAX_IDX2.  If the ranges of CASE_LABELs are empty then MAX_IDX1 < MIN_IDX1.
+   Returns true if the default label is not needed.  */
+
+static bool
+find_case_label_ranges (gimple stmt, value_range_t *vr, size_t *min_idx1,
+			size_t *max_idx1, size_t *min_idx2,
+			size_t *max_idx2)
+{
+  size_t i, j, k, l;
+  unsigned int n = gimple_switch_num_labels (stmt);
+  bool take_default;
+  tree case_low, case_high;
+  tree min = vr->min, max = vr->max;
+
+  gcc_checking_assert (vr->type == VR_RANGE || vr->type == VR_ANTI_RANGE);
+
+  take_default = !find_case_label_range (stmt, min, max, &i, &j);
+
+  /* Set second range to emtpy.  */
+  *min_idx2 = 1;
+  *max_idx2 = 0;
+
+  if (vr->type == VR_RANGE)
+{
+  *min_idx1 = i;
+  *max_idx1 = j;
+  return !take_default;
+}
+
+  /* Set first range to all case labels.  */
+  *min_idx1 = 1;
+  *max_idx1 = n - 1;
+
+  if (i > j)
+return false;
+
+  /* Make sure all the values of case labels [i , j] are contained in
+ range [MIN, MAX].  */
+  case_low = CASE_LOW (gimple_switch_label (stmt, i));
+  case_high = CASE_HIGH (gimple_switch_label (stmt, j));
+  if (tree_int_cst_compare (case_low, min) < 0)
+i += 1;
+  if (case_high != NULL_TREE
+  && tree_int_cst_compare (max, case_high) < 0)
+j -= 1;
+
+  if (i > j)
+return false;
+
+  /* If the range spans case labels [i, j], the corresponding anti-range spans
+ the labels [1, i - 1] and [j + 1, n -  1].  */
+  k = j + 1;
+  l = n - 1;
+  if (k > l)
+{
+  k = 1;
+  l = 0;
+}
+
+  j = i - 1;
+  i = 1;
+  if (i > j)
+{
+  i = k;
+  j = l;
+  k = 1;
+  l = 0;
+}
+
+  *min_idx1 = i;
+  *max_idx1 = j;
+  *min_idx2 = k;
+  *max_idx2 = l;
+  return false;
+}
+
 /* Visit switch statement STMT.  If we can determine which edge
will be taken out of STMT's basic block, record it in
*TAKEN_EDGE_P and return SSA_PROP_INTERESTING.  Otherwise, return
@@ -6746,7 +6824,7 @@ vrp_visit_switch_stmt (gimple stmt, edge
 {
   tree op, val;
   value_range_t *vr;
-  size_t i = 0, j = 0;
+  size_t i = 0, j = 0, k, l;
   bool take_default;
 
   *taken_edge_p = NULL;
@@ -6764,12 +6842,13 @@ vrp_visit_switch_stmt (gimple stmt, edge
   fprintf (dump_file, "\n");
 }
 
-  if (vr->type != VR_RANGE
+  if ((vr->type != VR_RANGE
+   && vr->type != VR_ANTI_RANGE)
   || symbolic_range_p (vr))
 return SSA_PROP_VARYING;
 
   /* Find the single edge that is taken from the switch expression.  */
-  take_default = !find_case_label_range (stmt, vr->min, vr->max, &i, &j);
+  take_default = !find_case_label_ranges (stmt, vr, &i, &j, &k, &l);
 
   /* Check if the range spans no CASE_LABEL. If so, we only reach the default
  label */
@@ -6803,6 +6882,16 @@ vrp_visit_switch_stmt (gimple stmt, edge
 	  return SSA_PROP_VARYING;
 	}
 }
+  for (; k <= l; ++k)
+{
+  if (CASE_LABEL (gimple_switch_label (stmt, k)) != CASE_LABEL (val))
+	{
+	  if (dump_file && (dump_flags & TDF_DETAILS))
+		fprintf (dump_file, "  not a single destination for this "
+			 "range\n");
+	  return SSA_PROP_VARYING;
+	}
+}
 }
 
   *taken_edge_p = find_edge (gimple_bb (stmt),
@@ -8195,18 +8284,20 @@ simplify_switch_using_ranges (gimple stm
   size_t i = 0, j = 0, n, n2;
   tree vec2;
   switch_update su;
+  size_t k = 1, l = 0;
 
   if (TREE_CODE (op) == SSA_NAME)
 {
   vr = get_value_range (op);
 
   /* We can only handle integer ranges.  */
-  if (vr->type != VR_RANGE
+  if ((vr->type != VR_RANGE
+	   && vr->type != VR_ANTI_RANGE)
 	  || symbolic_range_p (vr))
 	retu

Re: [RESEND-2][PATCH] Allow printing of escaped curly braces in assembler directives with operands

[Siddhesh Poyarekar]

On Fri, 20 Jul 2012 22:24:57 -0400 (EDT), Hans-Peter wrote:
> Sounds like a good idea, but I think you shouldn't limit that to
> "{}" but rather introduce \ to escape and cause any next
> character to be emitted as-is, in particular "|".

I had dropped the change to escape "|" thinking it wasn't needed -- it
gets interpreted as a special character only if it is within a {}. It
makes sense to add it though, since there could be a use case to have
a '|' within the assembler dialect options.

> That's a target (yes, counting it as one target) that defines
> ASSEMBLER_DIALECT wherein "{}|" has the predefined meaning you
> try to escape.  I suggest testing a non-ASSEMBLER_DIALECT target
> as well.  And check that no target uses \\ for something else
> through ASM_FPRINTF_EXTENSIONS... ...so it seems like %{ etc.
> would be safer.

OK, I'll do this and post a modified patch. Thanks for the review!

Regards,
Siddhesh

Re: [Patch, Fortran] Add TS29113's C_PTRDIFF_T

[Janne Blomqvist]

On Sat, Jul 21, 2012 at 10:53 AM, Tobias Burnus  wrote:
> TS 29113 adds (a bit hidden in "9.9 Edits to clause 15") a new ISO_C_Binding
> parameter: C_PTRDIFF_T.
>
> Build, tested, and currently regtesting on x86-64-gnu-linux.
> OK for the trunk?

Ok. Thanks for the patch.

-- 
Janne Blomqvist

[Patch, build, ppc] allow ppc config "--with-mcpu=native"

[Iain Sandoe]

Hi,

The PPC port can handle -mcpu=native.
The patch below enables its use at config time,
OK for trunk?
thanks,
Iain

gcc:

* config.gcc (powerpc*-*-* | rs6000-*-*): Allow 'native' as a
valid configured CPU choice.

Index: gcc/config.gcc
===
--- gcc/config.gcc  (revision 189745)
+++ gcc/config.gcc  (working copy)
@@ -3285,7 +3285,7 @@
tm_defines="${tm_defines} CONFIG_PPC405CR"
eval "with_$which=405"
;;
-   "" | common \
+   "" | common | native \
| power | power[234567] | power6x | powerpc | powerpc64 
\
| rios | rios1 | rios2 | rsc | rsc1 | rs64a \
| 401 | 403 | 405 | 405fp | 440 | 440fp | 464 | 464fp \

[Patch, PPC] extend TARGET_NO_LWSYNC to cover 440 and 603 processors.

[Iain Sandoe]

Hi,

The following patch was been in use internally, for some time, to handle two 
further cases where the processor does not have lwsync.  Verified on a cross 
from i686-linux-gnu to powerpc-linux-gnu.

OK for trunk?
thanks,
Iain

gcc/
* config/rs6000/rs6000.h (TARGET_NO_LWSYNC): Extended to cover PPC
440 and 603 processors.

Index: gcc/config/rs6000/rs6000.h
===
--- gcc/config/rs6000/rs6000.h  (revision 189745)
+++ gcc/config/rs6000/rs6000.h  (working copy)
@@ -501,9 +512,11 @@ extern int rs6000_vector_align[];
  || TARGET_ALTIVEC  \
  || TARGET_VSX)))
 
-/* E500 cores only support plain "sync", not lwsync.  */
+/* E500, 440 and 603 cores only support plain "sync", not lwsync.  */
 #define TARGET_NO_LWSYNC (rs6000_cpu == PROCESSOR_PPC8540 \
- || rs6000_cpu == PROCESSOR_PPC8548)
+ || rs6000_cpu == PROCESSOR_PPC8548 \
+ || rs6000_cpu == PROCESSOR_PPC440 \
+ || rs6000_cpu == PROCESSOR_PPC603)
 
 
 /* Which machine supports the various reciprocal estimate instructions.  */

[Patch, Darwin, ppc] constrain processor usage for m32.

[Iain Sandoe]

Hi,

At present, if a G5 or 970 processor is selected (-mcpu=), we can (and do) 
generate 64 bit register usage for m32 code.   This appears to be a 
long-standing bug.

OK for trunk & all open branches?
Iain

gcc/
* config/rs6000/darwin.h (OS_MISSING_POWERPC64): New.


Index: gcc/config/rs6000/darwin.h
===
--- gcc/config/rs6000/darwin.h  (revision 189712)
+++ gcc/config/rs6000/darwin.h  (working copy)
@@ -398,6 +398,9 @@ extern int darwin_emit_branch_islands;
default, as kernel code doesn't save/restore those registers.  */
 #define OS_MISSING_ALTIVEC (flag_mkernel || flag_apple_kext)
 
+/* When building m32 code, we cannot use POWERPC64.  */
+#define OS_MISSING_POWERPC64 !TARGET_64BIT
+
 /* Darwin has support for section anchors on powerpc*.  
It is disabled for any section containing a "zero-sized item" (because these
are re-written as size=1 to be compatible with the OSX ld64).

Re: [Patch, PPC] extend TARGET_NO_LWSYNC to cover 440 and 603 processors.

[Andrew Pinski]

On Sat, Jul 21, 2012 at 9:12 AM, Iain Sandoe  wrote:
> Hi,
>
> The following patch was been in use internally, for some time, to handle two 
> further cases where the processor does not have lwsync.  Verified on a cross 
> from i686-linux-gnu to powerpc-linux-gnu.
>
> OK for trunk?

This was only done for e500 and not other proessors as the e500 was
not fully compatible even with the older spec.  In that lwsync would
cause an illegal instruction exception.  This is NOT the case for 603
and the 440 so I don't think this patch should applied.

Thanks,
Andrew Pinski


> thanks,
> Iain
>
> gcc/
> * config/rs6000/rs6000.h (TARGET_NO_LWSYNC): Extended to cover PPC
> 440 and 603 processors.
>
> Index: gcc/config/rs6000/rs6000.h
> ===
> --- gcc/config/rs6000/rs6000.h  (revision 189745)
> +++ gcc/config/rs6000/rs6000.h  (working copy)
> @@ -501,9 +512,11 @@ extern int rs6000_vector_align[];
>   || TARGET_ALTIVEC  \
>   || TARGET_VSX)))
>
> -/* E500 cores only support plain "sync", not lwsync.  */
> +/* E500, 440 and 603 cores only support plain "sync", not lwsync.  */
>  #define TARGET_NO_LWSYNC (rs6000_cpu == PROCESSOR_PPC8540 \
> - || rs6000_cpu == PROCESSOR_PPC8548)
> + || rs6000_cpu == PROCESSOR_PPC8548 \
> + || rs6000_cpu == PROCESSOR_PPC440 \
> + || rs6000_cpu == PROCESSOR_PPC603)
>
>
>  /* Which machine supports the various reciprocal estimate instructions.  */
>
>

Re: [Patch, PPC] extend TARGET_NO_LWSYNC to cover 440 and 603 processors.

[Iain Sandoe]

Hi Andrew,

On 21 Jul 2012, at 17:43, Andrew Pinski wrote:

> On Sat, Jul 21, 2012 at 9:12 AM, Iain Sandoe  wrote:
>> Hi,
>> 
>> The following patch was been in use internally, for some time, to handle two 
>> further cases where the processor does not have lwsync.  Verified on a cross 
>> from i686-linux-gnu to powerpc-linux-gnu.
>> 
>> OK for trunk?
> 
> This was only done for e500 and not other proessors as the e500 was
> not fully compatible even with the older spec.  In that lwsync would
> cause an illegal instruction exception.  This is NOT the case for 603
> and the 440 so I don't think this patch should applied.

The original report, for which our change was made, was of an instruction 
exception caused by lwsync on 440.
I'm not personally familiar with that processor, I'll try and get access to a 
board/confirm in due course.

thanks
Iain



> 
> Thanks,
> Andrew Pinski
> 
> 
>> thanks,
>> Iain
>> 
>>gcc/
>>* config/rs6000/rs6000.h (TARGET_NO_LWSYNC): Extended to cover PPC
>>440 and 603 processors.
>> 
>> Index: gcc/config/rs6000/rs6000.h
>> ===
>> --- gcc/config/rs6000/rs6000.h  (revision 189745)
>> +++ gcc/config/rs6000/rs6000.h  (working copy)
>> @@ -501,9 +512,11 @@ extern int rs6000_vector_align[];
>>  || TARGET_ALTIVEC  \
>>  || TARGET_VSX)))
>> 
>> -/* E500 cores only support plain "sync", not lwsync.  */
>> +/* E500, 440 and 603 cores only support plain "sync", not lwsync.  */
>> #define TARGET_NO_LWSYNC (rs6000_cpu == PROCESSOR_PPC8540 \
>> - || rs6000_cpu == PROCESSOR_PPC8548)
>> + || rs6000_cpu == PROCESSOR_PPC8548 \
>> + || rs6000_cpu == PROCESSOR_PPC440 \
>> + || rs6000_cpu == PROCESSOR_PPC603)
>> 
>> 
>> /* Which machine supports the various reciprocal estimate instructions.  */
>> 
>> 

Re: [Patch, Darwin, ppc] constrain processor usage for m32.

[Mike Stump]

On Jul 21, 2012, at 9:12 AM, Iain Sandoe wrote:
> At present, if a G5 or 970 processor is selected (-mcpu=), we can (and do) 
> generate 64 bit register usage for m32 code.   This appears to be a 
> long-standing bug.

Hum, do you have an example of something that fails?  I ask, cause I think the 
if you say that you have a 64-bit processor, then, generating code for a 64-bit 
processor isn't necessarily wrong.  If you say you have a 64-bit processor, 
then you likely have an OS that runs on that processor, and that OS I'm 
thinking will save and restore the full 64-bit registers.  If not, do you have 
a pointer to documentation that says this won't work?

Re: [Patch, Darwin, ppc] constrain processor usage for m32.

[Andrew Pinski]

On Sat, Jul 21, 2012 at 10:27 AM, Mike Stump  wrote:
> On Jul 21, 2012, at 9:12 AM, Iain Sandoe wrote:
>> At present, if a G5 or 970 processor is selected (-mcpu=), we can (and do) 
>> generate 64 bit register usage for m32 code.   This appears to be a 
>> long-standing bug.
>
> Hum, do you have an example of something that fails?  I ask, cause I think 
> the if you say that you have a 64-bit processor, then, generating code for a 
> 64-bit processor isn't necessarily wrong.  If you say you have a 64-bit 
> processor, then you likely have an OS that runs on that processor, and that 
> OS I'm thinking will save and restore the full 64-bit registers.  If not, do 
> you have a pointer to documentation that says this won't work?

In fact OS_MISSING_POWERPC64 was added because GNU/Linux does not have
support but Darwin has the support in the OS.  The whole point of
-mpu=G5 means generate G5 code which includes generating PowerPC64
code.  This was added explicitly to speed up code like crafty in SPEC.

Do you have any data that says it should be disabled?
If you don't want to generate powerpc64 code then use -mno-powerpc64.

Thanks,
Andrew Pinski

Re: [Patch, Darwin, ppc] constrain processor usage for m32.

[Iain Sandoe]

Hi Mike,

On 21 Jul 2012, at 18:27, Mike Stump wrote:

> On Jul 21, 2012, at 9:12 AM, Iain Sandoe wrote:
>> At present, if a G5 or 970 processor is selected (-mcpu=), we can (and do) 
>> generate 64 bit register usage for m32 code.   This appears to be a 
>> long-standing bug.
> 
> Hum, do you have an example of something that fails?  

I can look for something, if necessary.

> I ask, cause I think the if you say that you have a 64-bit processor, then, 
> generating code for a 64-bit processor isn't necessarily wrong.  

indeed, highly desirable to make use of any improvements available.

> If you say you have a 64-bit processor, then you likely have an OS that runs 
> on that processor, and that OS I'm thinking will save and restore the full 
> 64-bit registers.  If not, do you have a pointer to documentation that says 
> this won't work?

Mac_OS_X_ABI_Function_Calls.pdf pp 19 para 2 (box).  This stipulates that even 
on a 64 bit processor, only the lower 32 bits of nonvolatile registers are 
saved/restored.  All 64 bits are saved across context switches/asynchronous 
events.

That is to quote the doc: one can *only* use the full 64 bits 'between function 
calls' safely. 

If there's a different mechanism for enforcing what's implied above, then we 
could use that.
cheers
Iain

Re: [Patch, Darwin, ppc] constrain processor usage for m32.

[Andrew Pinski]

On Sat, Jul 21, 2012 at 10:56 AM, Iain Sandoe  wrote:
> Hi Mike,
>
> On 21 Jul 2012, at 18:27, Mike Stump wrote:
>
>> On Jul 21, 2012, at 9:12 AM, Iain Sandoe wrote:
>>> At present, if a G5 or 970 processor is selected (-mcpu=), we can (and do) 
>>> generate 64 bit register usage for m32 code.   This appears to be a 
>>> long-standing bug.
>>
>> Hum, do you have an example of something that fails?
>
> I can look for something, if necessary.
>
>> I ask, cause I think the if you say that you have a 64-bit processor, then, 
>> generating code for a 64-bit processor isn't necessarily wrong.
>
> indeed, highly desirable to make use of any improvements available.
>
>> If you say you have a 64-bit processor, then you likely have an OS that runs 
>> on that processor, and that OS I'm thinking will save and restore the full 
>> 64-bit registers.  If not, do you have a pointer to documentation that says 
>> this won't work?
>
> Mac_OS_X_ABI_Function_Calls.pdf pp 19 para 2 (box).  This stipulates that 
> even on a 64 bit processor, only the lower 32 bits of nonvolatile registers 
> are saved/restored.  All 64 bits are saved across context 
> switches/asynchronous events.
>
> That is to quote the doc: one can *only* use the full 64 bits 'between 
> function calls' safely.
>
> If there's a different mechanism for enforcing what's implied above, then we 
> could use

Yes HARD_REGNO_CALL_PART_CLOBBERED should work.  If that is not
working there is a bug somewhere else in the compiler.

Thanks,
Andrew Pinski

Re: [Patch, Darwin, ppc] constrain processor usage for m32.

[Iain Sandoe]

On 21 Jul 2012, at 19:02, Andrew Pinski wrote:
>> If there's a different mechanism for enforcing what's implied above, then we 
>> could use
> 
> Yes HARD_REGNO_CALL_PART_CLOBBERED should work.  If that is not
> working there is a bug somewhere else in the compiler.

thanks, that looks solid enough, will have to delve a bit deeper, re the 
original issue.
Iain

[SH][committed] Correct comment.

[Oleg Endo]

Hello,

I have just committed the attached patch as obvious as rev 189747.

Cheers,
Oleg

ChangeLog:

* config/sh/sh.md: Correct comment regarding clrt and sett
insns.

Index: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md	(revision 189733)
+++ gcc/config/sh/sh.md	(working copy)
@@ -5094,9 +5094,14 @@
   DONE;
 })
 
-;; These two patterns can happen as the result of optimization, when
-;; comparisons get simplified to a move of zero or 1 into the T reg.
-;; They don't disappear completely, because the T reg is a fixed hard reg.
+;; The clrt and sett patterns can happen as the result of optimization and
+;; insn expansion.
+;; Comparisons might get simplified to a move of zero or 1 into the T reg.
+;; In this case they might not disappear completely, because the T reg is
+;; a fixed hard reg.
+;; When DImode operations that use the T reg as carry/borrow are split into
+;; individual SImode operations, the T reg is usually cleared before the
+;; first SImode insn.
 
 (define_insn "clrt"
   [(set (reg:SI T_REG) (const_int 0))]

Re: PR53914, rs6000 constraints and reload queries

[David Edelsohn]

On Thu, Jul 19, 2012 at 8:45 PM, Alan Modra  wrote:

> This on the other hand works.  Please consider the patch amended to
> remove mem_operand_fpr, the 'wY' constraint, and uses thereof replaced
> with "m".

What, exactly, is the current proposed patch? Remove offsettable
address constraint from movXX patterns but not from LO_SUM, and not
adding wY constraint?

Thanks, David

[PATCH/MIPS] Add a delegitimize target hook for MIPS

[Pinski, Andrew]

Hi,
  MIPS does not currently implement a mips_delegitimize_address target hook and 
for n64, a RTL is produced which the standard delegitimize cannot handle:
(const:DI (plus:DI (unspec:DI [
(symbol_ref:DI ("s")  )
] 229)
(const_int 4 [0x4])))

This patch implements a simple mips_delegitimize_address for this and some 
related cases.

OK?  Bootstrapped and tested on mips64-linux-gnu with no regressions.

Thanks,
Andrew Pinski

ChangeLog:
* config/mips/mips.c (mips_delegitimize_address): New function.
(TARGET_DELEGITIMIZE_ADDRESS): Define.
Index: tree-pretty-print.c
===
--- tree-pretty-print.c (revision 189746)
+++ tree-pretty-print.c (working copy)
@@ -855,6 +855,7 @@ dump_generic_node (pretty_printer *buffe
&& TREE_TYPE (TREE_OPERAND (node, 0)) != NULL_TREE
/* Same pointer types, but ignoring POINTER_TYPE vs.
   REFERENCE_TYPE.  */
+   && TREE_TYPE (TREE_OPERAND (node, 0))
&& (TREE_TYPE (TREE_TYPE (TREE_OPERAND (node, 0)))
== TREE_TYPE (TREE_TYPE (TREE_OPERAND (node, 1
&& (TYPE_MODE (TREE_TYPE (TREE_OPERAND (node, 0)))
@@ -1218,6 +1219,7 @@ dump_generic_node (pretty_printer *buffe
  || (TREE_CODE (op0) == MEM_REF
  && TREE_CODE (TREE_OPERAND (op0, 0)) != ADDR_EXPR
  && integer_zerop (TREE_OPERAND (op0, 1))
+ && TREE_TYPE (TREE_OPERAND (op0, 0))
  /* Dump the types of INTEGER_CSTs explicitly, for we
 can't infer them and MEM_ATTR caching will share
 MEM_REFs with differently-typed op0s.  */
Index: config/mips/mips.c
===
--- config/mips/mips.c  (revision 189746)
+++ config/mips/mips.c  (working copy)
@@ -2991,6 +2991,75 @@ mips_legitimize_address (rtx x, rtx oldx
   return x;
 }
 
+/* In the name of slightly smaller debug output, and to cater to
+   general assembler lossage, recognize various UNSPEC sequences
+   and turn them back into a direct symbol reference.  */
+
+static rtx
+mips_delegitimize_address (rtx orig_x)
+{
+  orig_x = delegitimize_mem_from_attrs (orig_x);
+
+  /* Turn (PLUS:DI (XX)
+   (CONST:DI (UNSPEC:DI [(A)] SYMBOL_64_LOW)))
+ into A.  */
+  /* Turn (PLUS:DI (XX)
+   (CONST:DI (PLUS:DI (UNSPEC:DI [(A)] SYMBOL_64_LOW) 
(const_int)))
+ into (PLUS:DI A (const_int)).  */
+  /* Turn (PLUS:DI (ASHIFT:DI (CONST:DI (UNSPEC:DI [(A)] SYMBOL_64_HIGH)) (32) 
)
+   (XX))
+ into A.  */
+  /* Turn (PLUS:DI (ASHIFT:DI (CONST:DI (PLUS:DI (UNSPEC:DI [(A)] 
SYMBOL_64_HIGH)
+   (const_int))) (32))
+  (XX))
+ into (PLUS:DI A (const_int)).  */
+  if (GET_CODE (orig_x) == PLUS)
+{
+  rtx addon = NULL_RTX;
+  rtx inconst1 = XEXP (orig_x, 1);
+  enum mips_symbol_type type = SYMBOL_64_LOW;
+
+  /* Strip the possible LO_SUM.*/
+  if (GET_CODE (inconst1) == LO_SUM)
+   inconst1 = XEXP (inconst1, 1);
+
+  /* If we don't have a const on the right hand side, see if
+we have a shift of a const. */
+  if (GET_CODE (inconst1) != CONST
+ && GET_CODE (XEXP (orig_x, 0)) == ASHIFT
+ && XEXP (XEXP (orig_x, 0), 1) == GEN_INT (32))
+   {
+ inconst1 = XEXP (XEXP (orig_x, 0), 0);
+
+ if (GET_CODE (inconst1) == LO_SUM)
+   inconst1 = XEXP (inconst1, 1);
+ type = SYMBOL_64_HIGH;
+   }
+
+  if (GET_CODE (inconst1) != CONST)
+   return orig_x;
+
+  inconst1 = XEXP (inconst1, 0);
+   
+  if (GET_CODE (inconst1) == PLUS
+ && CONST_INT_P (XEXP (inconst1, 1)))
+   {
+ addon = XEXP (inconst1, 1);
+ inconst1 = XEXP (inconst1, 0);
+   }
+  if (GET_CODE (inconst1) == UNSPEC
+ && XINT (inconst1, 1) == UNSPEC_ADDRESS_FIRST + type)
+   {
+ rtx symbol = XVECEXP (inconst1, 0, 0);
+ if (addon != NULL_RTX)
+   symbol = simplify_gen_binary (PLUS, GET_MODE (symbol), symbol, 
addon);
+ return symbol;
+   }
+}
+
+  return orig_x;
+}
+
 /* Load VALUE into DEST.  TEMP is as for mips_force_temporary.  */
 
 void
@@ -17447,6 +17516,9 @@ mips_expand_vec_minmax (rtx target, rtx
 #undef TARGET_LEGITIMIZE_ADDRESS
 #define TARGET_LEGITIMIZE_ADDRESS mips_legitimize_address
 
+#undef TARGET_DELEGITIMIZE_ADDRESS
+#define TARGET_DELEGITIMIZE_ADDRESS mips_delegitimize_address
+
 #undef TARGET_ASM_FUNCTION_PROLOGUE
 #define TARGET_ASM_FUNCTION_PROLOGUE mips_output_function_prologue
 #undef TARGET_ASM_FUNCTION_EPILOGUE

[SH] Fold negc expander and insn

[Oleg Endo]

Hello,

The attached patch folds the negc expander and *negc insn.
Tested with 'make all'.  CSiBE result-size (-m4-single -ml
-mpretend-cmove) also doesn't show any change.

OK?

Cheers,
Oleg

ChangeLog:

* config/sh/sh.md (negc): Delete expander.
(*negc): Rename insn to negc.
Index: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md	(revision 189747)
+++ gcc/config/sh/sh.md	(working copy)
@@ -4256,17 +4256,7 @@
 ;; Unary arithmetic
 ;; -
 
-(define_expand "negc"
-  [(parallel [(set (match_operand:SI 0 "arith_reg_dest" "")
-	(neg:SI (plus:SI (reg:SI T_REG)
-			 (match_operand:SI 1 "arith_reg_operand" ""
-   (set (reg:SI T_REG)
-	(ne:SI (ior:SI (reg:SI T_REG) (match_dup 1))
-	   (const_int 0)))])]
-  ""
-  "")
-
-(define_insn "*negc"
+(define_insn "negc"
   [(set (match_operand:SI 0 "arith_reg_dest" "=r")
 	(neg:SI (plus:SI (reg:SI T_REG)
 			 (match_operand:SI 1 "arith_reg_operand" "r"

[patch] Profiling infrastructure TLC (1/n)

[Steven Bosscher]

Hello,

This patch cleans up some "interesting" things in GCC's profiling
support. The most significant changes are the removal of
BB_TO_GCOV_INDEX and after_tree_profile. Another visible cleanup is
that -profile-generate no longer sets
flag_value_profile_transformations.

The rest is mostly just comment updates, because the comments (and the
code, see BB_TO_GCOV_INDEX ;-) have not been maintained very well for
everything that has changed since, oh, tree-ssa was merged?

For example, in value-prof.c:"the flow graph is annotated with actual
execution counts, which are later propagated into the rtl for
optimization purposes."

Or before profile.c:branch_prob():
-/* Instrument and/or analyze program behavior based on program flow graph.
-   In either case, this function builds a flow graph for the function being
-   compiled.  The flow graph is stored in BB_GRAPH.
...
- (...) In this case, the flow graph is
-   annotated with actual execution counts, which are later propagated into the
-   rtl for optimization purposes.

But (a) branch_prob doesn't build a CFG; (b) the flow graph it doesn't
build is not stored in BB_GRAPH; and (c) the execution counts are not
"propagated into the rtl".

The whole profiling infrastructure needs a lot of TLC before it looks
somewhat decent again. This is just the first step :-)

Bootstrapped and tested on powerpc64-unknown-linux-gnu.
Profilebootstrapped and tested on x86_64-unknown-linux-gnu.
OK for trunk?

Ciao!
Steven


prof_cleanup.diff
Description: Binary data

[patch] PR gcov-profile/32543

[Steven Bosscher]

Committed as obvious.

Index: ChangeLog
===
--- ChangeLog   (revision 189747)
+++ ChangeLog   (working copy)
@@ -1,3 +1,9 @@
+2012-07-21  Steven Bosscher 
+
+   PR gcov-profile/32543
+   * profile.c (branch_prob): Update total_num_edges_instrumented and
+   report the number of edges to instrument.
+
 2012-07-21  Oleg Endo  

* config/sh/sh.md: Correct comment regarding clrt and sett insns.
Index: profile.c
===
--- profile.c   (revision 189747)
+++ profile.c   (working copy)
@@ -1133,6 +1133,9 @@ branch_prob (void)
   if (dump_file)
 fprintf (dump_file, "%d ignored edges\n", ignored_edges);

+  total_num_edges_instrumented += num_instrumented;
+  if (dump_file)
+fprintf (dump_file, "%d instrumentation edges\n", num_instrumented);

   /* Compute two different checksums. Note that we want to compute
  the checksum in only once place, since it depends on the shape

[SH] Add TARGET_DYNSHIFT macro

[Oleg Endo]

Hello,

Currently the check for availability of dynamic shift instructions on a
particular SH target is repeated in several places.  The attached patch
adds a new macro for that.

Tested with 'make all'.  CSiBE result-size (-m4-single -ml
-mpretend-cmove) also doesn't show any change.

OK?

Cheers,
Oleg

ChangeLog:

* config/sh/sh.h (TARGET_DYNSHIFT): New macro.
(SH_DYNAMIC_SHIFT_COST): Use it.
* config/sh/sh.c (expand_ashiftrt, shl_sext_kind): Likewise.
(sh_dynamicalize_shift_p): Add TARGET_DYNSHIFT condition.  Add 
sanity check for input value.  Add function description.
* config/sh/sh.md (ashlsi3, ashlsi3_std, ashrsi3_d, lshrsi3, 
lshrsi3_d): Use TARGET_DYNSHIFT.
Index: gcc/config/sh/sh.c
===
--- gcc/config/sh/sh.c	(revision 189746)
+++ gcc/config/sh/sh.c	(working copy)
@@ -3437,7 +3437,7 @@
   char func[18];
   int value;
 
-  if (TARGET_SH3 || TARGET_SH2A)
+  if (TARGET_DYNSHIFT)
 {
   if (!CONST_INT_P (operands[2]))
 	{
@@ -3507,10 +3507,16 @@
   return true;
 }
 
+/* Return true if it is potentially beneficial to use a dynamic shift
+   instruction (shad / shar) instead of a combination of 1/2/8/16 
+   shift instructions for the specified shift count.
+   If dynamic shifts are not available, always return false.  */
 bool
 sh_dynamicalize_shift_p (rtx count)
 {
-  return shift_insns[INTVAL (count) & 31] > 1 + SH_DYNAMIC_SHIFT_COST;
+  gcc_assert (CONST_INT_P (count));
+  return TARGET_DYNSHIFT
+	 && (shift_insns[INTVAL (count) & 31] > 1 + SH_DYNAMIC_SHIFT_COST);
 }
 
 /* Try to find a good way to implement the combiner pattern
@@ -3886,7 +3892,7 @@
 	}
 	}
 }
-  if (TARGET_SH3 || TARGET_SH2A)
+  if (TARGET_DYNSHIFT)
 {
   /* Try to use a dynamic shift.  */
   cost = shift_insns[32 - insize] + 1 + SH_DYNAMIC_SHIFT_COST;
Index: gcc/config/sh/sh.h
===
--- gcc/config/sh/sh.h	(revision 189746)
+++ gcc/config/sh/sh.h	(working copy)
@@ -1928,6 +1928,13 @@
 /* Nonzero if access to memory by bytes is no faster than for words.  */
 #define SLOW_BYTE_ACCESS 1
 
+/* Nonzero if the target supports dynamic shift instructions
+   like shad and shld.  */
+#define TARGET_DYNSHIFT (TARGET_SH3 || TARGET_SH2A)
+
+#define SH_DYNAMIC_SHIFT_COST \
+  (TARGET_HARD_SH4 ? 1 : TARGET_DYNSHIFT ? (optimize_size ? 1 : 2) : 20)
+
 /* Immediate shift counts are truncated by the output routines (or was it
the assembler?).  Shift counts in a register are truncated by SH.  Note
that the native compiler puts too large (> 32) immediate shift counts
@@ -2317,11 +2324,6 @@
prologue rather than duplicate around each call.  */
 #define ACCUMULATE_OUTGOING_ARGS TARGET_ACCUMULATE_OUTGOING_ARGS
 
-#define SH_DYNAMIC_SHIFT_COST \
-  (TARGET_HARD_SH4 ? 1	\
-   : (TARGET_SH3 || TARGET_SH2A) ? (optimize_size ? 1 : 2) : 20)
-
-
 #define NUM_MODES_FOR_MODE_SWITCHING { FP_MODE_NONE }
 
 #define OPTIMIZE_MODE_SWITCHING(ENTITY) (TARGET_SH4 || TARGET_SH2A_DOUBLE)
Index: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md	(revision 189747)
+++ gcc/config/sh/sh.md	(working copy)
@@ -3514,7 +3514,7 @@
   if (CONST_INT_P (operands[2])
   && sh_dynamicalize_shift_p (operands[2]))
 operands[2] = force_reg (SImode, operands[2]);
-  if (TARGET_SH3 || TARGET_SH2A)
+  if (TARGET_DYNSHIFT)
 {
   emit_insn (gen_ashlsi3_std (operands[0], operands[1], operands[2]));
   DONE;
@@ -3530,14 +3530,13 @@
 	(ashift:SI (match_operand:SI 1 "arith_reg_operand" "0,0,0,0")
 		   (match_operand:SI 2 "nonmemory_operand" "r,M,P27,?ri")))
(clobber (match_scratch:SI 3 "=X,X,X,&r"))]
-  "(TARGET_SH3 || TARGET_SH2A)
-   || (TARGET_SH1 && satisfies_constraint_P27 (operands[2]))"
+  "TARGET_DYNSHIFT || (TARGET_SH1 && satisfies_constraint_P27 (operands[2]))"
   "@
shld	%2,%0
add	%0,%0
shll%O2	%0
#"
-  "(TARGET_SH3 || TARGET_SH2A)
+  "TARGET_DYNSHIFT
&& reload_completed
&& CONST_INT_P (operands[2])
&& ! satisfies_constraint_P27 (operands[2])"
@@ -3797,7 +3796,7 @@
   [(set (match_operand:SI 0 "arith_reg_dest" "=r")
 	(ashiftrt:SI (match_operand:SI 1 "arith_reg_operand" "0")
 		 (neg:SI (match_operand:SI 2 "arith_reg_operand" "r"]
-  "TARGET_SH3 || TARGET_SH2A"
+  "TARGET_DYNSHIFT"
   "shad	%2,%0"
   [(set_attr "type" "dyn_shift")])
 
@@ -3912,7 +3911,7 @@
   if (CONST_INT_P (operands[2])
   && sh_dynamicalize_shift_p (operands[2]))
 operands[2] = force_reg (SImode, operands[2]);
-  if ((TARGET_SH3 || TARGET_SH2A)
+  if (TARGET_DYNSHIFT
   && arith_reg_operand (operands[2], GET_MODE (operands[2])))
 {
   rtx count = copy_to_mode_reg (SImode, operands[2]);
@@ -3928,7 +3927,7 @@
   [(set (match_operand:SI 0 "arith_reg_dest" "=r")
 	(lshiftrt:SI (match_operand:SI 1 "arith_reg_operand" "0")
 		 (neg:SI (match_operand:SI 2 "arith_re

[Committed] Add two new aliasing testcases

[Andrew Pinski]

Hi,
  I thought I would add these two aliasing testcases which I have in
Cavium's private tree for a while now.  They both pass since the
addition of MEM_REF.

 Committed as obvious after a bootstrap and test on x86_64-linux-gnu
with no regressions.

Thanks,
Andrew Pinski

2012-07-21  Andrew Pinski  

* gcc.dg/tree-ssa/alias-21.c: New testcase.
* gcc.dg/tree-ssa/alias-22.c: New testcase.
Index: testsuite/gcc.dg/tree-ssa/alias-21.c
===
--- testsuite/gcc.dg/tree-ssa/alias-21.c(revision 0)
+++ testsuite/gcc.dg/tree-ssa/alias-21.c(revision 0)
@@ -0,0 +1,15 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+
+
+int f(int *r)
+{
+  r[0] = 0;
+  r[1] = 1;
+  return r[0];
+}
+
+
+/* { dg-final { scan-tree-dump-times "return 0;" 1 "optimized" } } */
+/* { dg-final { cleanup-tree-dump "optimized" } } */
+
Index: testsuite/gcc.dg/tree-ssa/alias-22.c
===
--- testsuite/gcc.dg/tree-ssa/alias-22.c(revision 0)
+++ testsuite/gcc.dg/tree-ssa/alias-22.c(revision 0)
@@ -0,0 +1,15 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+
+
+int f(int *r)
+{
+  r[1] = 0;
+  r[2] = 1;
+  return r[1];
+}
+
+
+/* { dg-final { scan-tree-dump-times "return 0;" 1 "optimized" } } */
+/* { dg-final { cleanup-tree-dump "optimized" } } */
+
Index: testsuite/ChangeLog
===
--- testsuite/ChangeLog (revision 189751)
+++ testsuite/ChangeLog (working copy)
@@ -1,5 +1,10 @@
 2012-07-21  Andrew Pinski  
 
+   * gcc.dg/tree-ssa/alias-21.c: New testcase.
+   * gcc.dg/tree-ssa/alias-22.c: New testcase.
+
+2012-07-21  Andrew Pinski  
+
* gcc.target/mips/octeon-pop-2.c: New testcase.
 
 2012-07-21  Tobias Burnus  

[PATCH] Add a few more VRP IOR testcases

[Andrew Pinski]

Hi,
  We (Cavium) has had these VRP testcases in our testsuite for a while
and I found they pass without any patches.

Committed as obvious after a test on x86_64-linux-gnu with no regressions.

Thanks,
Andrew Pinski

2012-07-21  Andrew Pinski  

*  gcc.dg/tree-ssa/vrp72.c: New test.
*  gcc.dg/tree-ssa/vrp73.c: New test.
*  gcc.dg/tree-ssa/vrp74.c: New test.
*  gcc.dg/tree-ssa/vrp75.c: New test.
Index: gcc.dg/tree-ssa/vrp72.c
===
--- gcc.dg/tree-ssa/vrp72.c (revision 0)
+++ gcc.dg/tree-ssa/vrp72.c (revision 0)
@@ -0,0 +1,30 @@
+/* { dg-options "-O2" } */
+
+typedef unsigned long long uint64_t;
+
+static inline void cvmx_write64_uint64(uint64_t addr, uint64_t val)
+{
+  *(volatile uint64_t *)(long)addr = val;
+};
+static inline uint64_t cvmx_read64_uint64(uint64_t addr)
+{
+  return *(volatile uint64_t *)(long)addr;
+};
+
+static inline void cvmx_write_csr(uint64_t csr_addr, uint64_t val)
+{
+cvmx_write64_uint64 (csr_addr, val);
+if ((csr_addr >> 40) != 0x800118)
+  linker_error ();
+}
+
+int uart;
+
+int
+main ()
+{
+  cvmx_write_csr (uint64_t) 2LL) << 62)
+  | (0x000118000808ull+((uart&0xff)*1024))),
+ 0xfff);
+  return 0;
+}
Index: gcc.dg/tree-ssa/vrp73.c
===
--- gcc.dg/tree-ssa/vrp73.c (revision 0)
+++ gcc.dg/tree-ssa/vrp73.c (revision 0)
@@ -0,0 +1,30 @@
+/* { dg-options "-O2" } */
+
+typedef unsigned long long uint64_t;
+
+static inline void cvmx_write64_uint64(uint64_t addr, uint64_t val)
+{
+  *(volatile uint64_t *)(long)addr = val;
+};
+static inline uint64_t cvmx_read64_uint64(uint64_t addr)
+{
+  return *(volatile uint64_t *)(long)addr;
+};
+
+static inline void cvmx_write_csr(uint64_t csr_addr, uint64_t val)
+{
+cvmx_write64_uint64 (csr_addr, val);
+if ((csr_addr >> 40) == 0x800118)
+  linker_error ();
+}
+
+int dest_core, src_core;
+
+int
+main ()
+{
+  cvmx_write_csr ((uint64_t)2LL) << 62)
+   | ((0x000107000600ull+((dest_core&0xff)*8),
+ 1ull << src_core);
+  return 0;
+}
Index: gcc.dg/tree-ssa/vrp74.c
===
--- gcc.dg/tree-ssa/vrp74.c (revision 0)
+++ gcc.dg/tree-ssa/vrp74.c (revision 0)
@@ -0,0 +1,23 @@
+/* { dg-options "-O2" } */
+
+void abort (void);
+void exit (int);
+
+__attribute__ ((noinline)) void
+f (unsigned long long i)
+{
+  if (i <= 0x1000ull)
+{
+  unsigned long long j = i | 0x1000ull;
+  if (j == 0x1100ull)
+   exit (0);
+}
+}
+
+int
+main ()
+{
+  f (0x0100ull);
+  abort ();
+}
+
Index: gcc.dg/tree-ssa/vrp75.c
===
--- gcc.dg/tree-ssa/vrp75.c (revision 0)
+++ gcc.dg/tree-ssa/vrp75.c (revision 0)
@@ -0,0 +1,31 @@
+/* { dg-options "-O2" } */
+
+typedef unsigned long long uint64_t;
+
+static inline void cvmx_write64_uint64(uint64_t addr, uint64_t val)
+{
+  *(volatile uint64_t *)(long)addr = val;
+};
+static inline uint64_t cvmx_read64_uint64(uint64_t addr)
+{
+  return *(volatile uint64_t *)(long)addr;
+};
+static inline void cvmx_write_csr(uint64_t csr_addr, uint64_t val)
+{
+cvmx_write64_uint64 (csr_addr, val);
+if ((csr_addr >> 40) != 0x800118)
+  linker_error ();
+}
+
+int interface;
+int idx;
+
+int
+main ()
+{
+cvmx_write_csr((uint64_t) 2LL) << 62)
+| ((0x0001180008000208ull
++ (((idx)&3)*2048)
++ (((interface)&1)*0x800ull), 1);
+  return 0;
+}