Re: [PATCH] libstdc++: Add mem_order_hle_acquire/release to atomic.h v2

2013-01-14 Thread Jonathan Wakely
On 14 January 2013 06:06, Andi Kleen  wrote:
>
> The underlying compiler supports additional __ATOMIC_HLE_ACQUIRE/RELEASE
> memmodel flags for TSX, but this was not exposed to the C++ wrapper.
> Handle it there.
>
> These are additional flags, so some of assert checks need to mask
> off the flags before checking the memory model type.
>
> This is a reworked version over the version last year, including
> using operator overloading as suggested by Jonathan Wakely
> and a real test case
>
> Needs the earlier __atomic_clear/store HLE fix patch to make
> the test case succeed.
>
> Passes bootstrap and testsuite on x86_64-linux.

This looks good, thanks for reworking it.

I think the new testcase should only have 2013 in the copyright dates,
and does atomic_base.h need 2013 added?

As the earlier version was first posted some time ago I think it's OK
even though the trunk's now in release branch mode.  Please wait 24
hours in case anyone else objects and if not it can be committed.

Thanks.


[PATCH] Do not allow sharing of handled_component_p's

2013-01-14 Thread Richard Biener

For some reason they were allowed, which is definitely not a good
idea (they are unshared by all regular unsharing).  Direct fallout
is minor - it's the graphite changes which makes sure not to
share a[0].  The rest of the adjustments are for bugs sharing
ADDR_EXPRs (which is also bad as that has a location).

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

Richard.

2013-01-14  Richard Biener  

* tree-cfgcleanup.c (remove_forwarder_block): Unshare propagated
PHI argument.
* graphite-sese-to-poly.c (insert_out_of_ssa_copy): Properly
unshare reference.
(insert_out_of_ssa_copy_on_edge): Likewise.
(rewrite_close_phi_out_of_ssa): Likewise.
* tree-ssa.c (insert_debug_temp_for_var_def): Properly unshare
debug expressions.
* tree-ssa-pre.c (insert_into_preds_of_block): Properly unshare
propagated constants.
* tree-cfg.c (tree_node_can_be_shared): Handled component-refs
can not be shared.

Index: gcc/tree-cfgcleanup.c
===
*** gcc/tree-cfgcleanup.c   (revision 195142)
--- gcc/tree-cfgcleanup.c   (working copy)
*** remove_forwarder_block (basic_block bb)
*** 412,418 
{
  gimple phi = gsi_stmt (gsi);
  source_location l = gimple_phi_arg_location_from_edge (phi, succ);
! add_phi_arg (phi, gimple_phi_arg_def (phi, succ->dest_idx), s, l);
}
}
  }
--- 412,419 
{
  gimple phi = gsi_stmt (gsi);
  source_location l = gimple_phi_arg_location_from_edge (phi, succ);
! tree def = gimple_phi_arg_def (phi, succ->dest_idx);
! add_phi_arg (phi, unshare_expr (def), s, l);
}
}
  }
Index: gcc/graphite-sese-to-poly.c
===
*** gcc/graphite-sese-to-poly.c (revision 195142)
--- gcc/graphite-sese-to-poly.c (working copy)
*** insert_out_of_ssa_copy (scop_p scop, tre
*** 2020,2026 
gimple_seq stmts;
gimple_stmt_iterator gsi;
tree var = force_gimple_operand (expr, &stmts, true, NULL_TREE);
!   gimple stmt = gimple_build_assign (res, var);
vec x;
x.create (3);
  
--- 2020,2026 
gimple_seq stmts;
gimple_stmt_iterator gsi;
tree var = force_gimple_operand (expr, &stmts, true, NULL_TREE);
!   gimple stmt = gimple_build_assign (unshare_expr (res), var);
vec x;
x.create (3);
  
*** insert_out_of_ssa_copy_on_edge (scop_p s
*** 2076,2082 
gimple_stmt_iterator gsi;
gimple_seq stmts = NULL;
tree var = force_gimple_operand (expr, &stmts, true, NULL_TREE);
!   gimple stmt = gimple_build_assign (res, var);
basic_block bb;
vec x;
x.create (3);
--- 2076,2082 
gimple_stmt_iterator gsi;
gimple_seq stmts = NULL;
tree var = force_gimple_operand (expr, &stmts, true, NULL_TREE);
!   gimple stmt = gimple_build_assign (unshare_expr (res), var);
basic_block bb;
vec x;
x.create (3);
*** rewrite_close_phi_out_of_ssa (scop_p sco
*** 2232,2238 
  {
tree zero_dim_array = create_zero_dim_array (res, "Close_Phi");
  
!   stmt = gimple_build_assign (res, zero_dim_array);
  
if (TREE_CODE (arg) == SSA_NAME)
insert_out_of_ssa_copy (scop, zero_dim_array, arg,
--- 2232,2238 
  {
tree zero_dim_array = create_zero_dim_array (res, "Close_Phi");
  
!   stmt = gimple_build_assign (res, unshare_expr (zero_dim_array));
  
if (TREE_CODE (arg) == SSA_NAME)
insert_out_of_ssa_copy (scop, zero_dim_array, arg,
*** rewrite_phi_out_of_ssa (scop_p scop, gim
*** 2258,2267 
gimple phi = gsi_stmt (*psi);
basic_block bb = gimple_bb (phi);
tree res = gimple_phi_result (phi);
-   tree var;
tree zero_dim_array = create_zero_dim_array (res, "phi_out_of_ssa");
gimple stmt;
-   gimple_seq stmts;
  
for (i = 0; i < gimple_phi_num_args (phi); i++)
  {
--- 2258,2265 
*** rewrite_phi_out_of_ssa (scop_p scop, gim
*** 2278,2290 
insert_out_of_ssa_copy_on_edge (scop, e, zero_dim_array, arg);
  }
  
!   var = force_gimple_operand (zero_dim_array, &stmts, true, NULL_TREE);
! 
!   stmt = gimple_build_assign (res, var);
remove_phi_node (psi, false);
SSA_NAME_DEF_STMT (res) = stmt;
! 
!   insert_stmts (scop, stmt, stmts, gsi_after_labels (bb));
  }
  
  /* Rewrite the degenerate phi node at position PSI from the degenerate
--- 2276,2285 
insert_out_of_ssa_copy_on_edge (scop, e, zero_dim_array, arg);
  }
  
!   stmt = gimple_build_assign (res, unshare_expr (zero_dim_array));
remove_phi_node (psi, false);
SSA_NAME_DEF_STMT (res) = stmt;
!   insert_stmts (scop, stmt, NULL, gsi_after_labels (bb));
  }
  
  /* Rewrite the degenerate phi node at position PSI from the degenerate
Index

Re: [patch, Fortran] PR 55806 - Inefficient ANY with array constructors

2013-01-14 Thread Mikael Morin

Le 13/01/2013 23:14, Thomas Koenig a écrit :

Hi Mikael,

thanks a lot for your comments!


+ actual_arglist->expr = gfc_copy_expr (e); +
actual_arglist->next = gfc_get_actual_arglist ();

Another one is needed. I get a segmentation fault with SUM.


Fixed by using gfc_build_intrisic_call.

Nice.




Updated test case and patch attached.
Index: frontend-passes.c
===
--- frontend-passes.c   (Revision 195136)
+++ frontend-passes.c   (Arbeitskopie)

[...]

+  else if (id == GFC_ISYM_ANY || id == GFC_ISYM_ALL)
+   fcn = gfc_build_intrinsic_call (current_ns,
+   fn->value.function.isym->id,
+   fn->value.function.isym->name,
+   fn->where, 2, gfc_copy_expr (e),
+   NULL);
+  else
+   gfc_error ("Illegal id in copy_walk_reduction_arg");


This is not very useful for a user.  It should be an internal error (or 
gcc_unreachable would do as well).




+
+/* Callback function for optimzation of reductions to scalars.  Transform ANY
+   ([f1,f2,f3, ...]) to f1 .or. f2 .or. f3 .or. ..., with ANY, SUM and PRODUCT
+   correspondingly.  Handly only the simple cases without MASK and DIM.  */
+
+static int
+callback_reduction (gfc_expr **e, int *walk_subtrees ATTRIBUTE_UNUSED,
+   void *data ATTRIBUTE_UNUSED)
+{
+  gfc_expr *fn, *arg;
+  gfc_intrinsic_op op;
+  gfc_isym_id id;
+  gfc_actual_arglist *a;
+  gfc_actual_arglist *dim;
+  gfc_constructor *c;
+  gfc_expr *res, *new_expr;
+  gfc_actual_arglist *mask;
+
+  fn = *e;
+
+  if (fn->rank != 0 || fn->expr_type != EXPR_FUNCTION
+  || fn->value.function.isym == NULL)
+return 0;
+
+  id = fn->value.function.isym->id;
+
+  if (id != GFC_ISYM_SUM && id != GFC_ISYM_PRODUCT
+  && id != GFC_ISYM_ANY && id != GFC_ISYM_ALL)
+return 0;
+
+  a = fn->value.function.actual;
+
+  /* Don't handle MASK or DIM.  */
+
+  dim = a->next;
+
+  if (dim->expr != NULL)
+return 0;
+

Trailing whitespace.


+  mask = dim->next;
+  if (mask != NULL)
+if ( mask->expr != NULL)
+  return 0;
This is a bit confusing as mask is the first argument in the ANY/ALL 
case.  You can use something like this instead:

if (id == GFC_ISYM_SUM || id == GFC_ISYM_PRODUCT)
  {
mask = dim->next;
if (mask->expr != NULL)
  return 0;
  }





OK for trunk?


OK with the changes suggested above. Thanks.

Mikael


Re:[PING] [Patch, AArch64] Implement support for LD1R.

2013-01-14 Thread Tejas Belagod


PING.

Tejas Belagod wrote:

Hi,

Attached is a patch that implements support for AdvSIMD instruction LD1R.

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

Thanks,
Tejas Belagod
ARM.

2013-01-09  Tejas Belagod  

gcc/
* config/aarch64/aarch64-simd.md (*aarch64_simd_ld1r): New.
* config/aarch64/iterators.md (VALLDI): New.

testsuite/
* gcc.target/aarch64/aarch64/vect-ld1r-compile-fp.c: New.
* gcc.target/aarch64/vect-ld1r-compile.c: New.
* gcc.target/aarch64/vect-ld1r-fp.c: New.
* gcc.target/aarch64/vect-ld1r.c: New.
* gcc.target/aarch64/vect-ld1r.x: New.






Re: [PING][Patch, AArch64-4.7] Implement support for LD1R.

2013-01-14 Thread Tejas Belagod

PING.

Tejas Belagod wrote:

Hi,

Attached is a patch that implements support for AdvSIMD instruction LD1R.

Tested on aarch64-none-elf. OK to commit on aarch64-4.7-branch?

Thanks,
Tejas Belagod
ARM.

2013-01-09  Tejas Belagod  

gcc/
* config/aarch64/aarch64-simd.md (*aarch64_simd_ld1r): New.
* config/aarch64/iterators.md (VALLDI): New.

testsuite/
* gcc.target/aarch64/aarch64/vect-ld1r-compile-fp.c: New.
* gcc.target/aarch64/vect-ld1r-compile.c: New.
* gcc.target/aarch64/vect-ld1r-fp.c: New.
* gcc.target/aarch64/vect-ld1r.c: New.
* gcc.target/aarch64/vect-ld1r.x: New.






Re: testsuite: missing or wrong dg-* directives?

2013-01-14 Thread Mikael Morin

Le 13/01/2013 21:30, Harald Anlauf a écrit :

On 01/12/13 22:02, Mikael Morin wrote:

Le 08/01/2013 22:32, Harald Anlauf a écrit :

On 12/28/12 21:49, Harald Anlauf wrote:

Hello all,

is there a default directive that is assumed when the testsuite is run?

Running an "fgrep -L" on the fortran testsuite, I found several files
that are missing either dg-do compile or run.

I also found a funny typo in gomp/appendix-a/a.11.2.f90
! { do-do compile }


find gfortran.dg -name "*.[fF]90" -o -name "*.[fF]" | \
xargs fgrep -w -L 'dg-do' | \
xargs head -1 -v

and manual inspection of the resulting output results in:

- Typos


[...]


- Possibly missing { dg-do run }


[...]

Mind sending patch and changelog to @gcc-patches ?



Here we go. No failures, but additional passes because of the dg-do
run's. Somebody please take care of it?


Thanks.  Committed as revision 195146.

Mikael


Re: [PATCH] PR c++/55663 - constexpr function templ instantiation considered non-const as alias templ arg

2013-01-14 Thread Jason Merrill

OK.

Jason


Re: testsuite: missing or wrong dg-* directives?

2013-01-14 Thread Mikael Morin

Le 14/01/2013 00:37, Manfred Schwarb a écrit :

Am 14.01.2013 00:10, schrieb Manfred Schwarb:


There are several other oddities: d_g-final, braces have to be
separated by spaces.


Want to send a patch?


Not sure about the double braces in lto, I guess they act simply as
single braces.


I don't know, you may ask a testsuite maintainer, or the author.  It is 
unlikely though that the author made a typo at the opening brace _and_ 
at the closing one.


Mikael


[PATCH] Allow new ISL/CLooG versions

2013-01-14 Thread Richard Biener

This makes us accept the CLooG 0.18.0 and ISL 0.11.1 combo.

It's probably not the best stage to move the version checks to
gcc/ where we can rely on built in-tree ISL/CLooG, so this avoids
it with the caveat that in-tree CLooG 0.18.0 will fail the
version check (they no longer ship built version.h but only
version.h.in).

I verified all GRAPHITE tests pass with 0.18.0/0.11.1.

Ok for trunk?

Or do people prefer to move CLooG/ISL checks to gcc/ configure
time to fix the in-tree use of 0.18.0 and also do version checks
of in-tree ISL at all (they don't have a version.h).

Thanks,
Richard.

2013-01-14  Richard Biener  

* configure.ac (cloog/isl): Also allow ISL 0.11.x and CLooG 0.18.0.
* configure: Re-generate.

Index: configure.ac
===
--- configure.ac(revision 195144)
+++ configure.ac(working copy)
@@ -1606,8 +1606,11 @@ if test "x$with_isl" != "xno" &&
   dnl Provide configure switches and initialize islinc & isllibs
   dnl with user input.
   ISL_INIT_FLAGS
-  dnl The minimal version of ISL required for Graphite.
+  dnl The versions of ISL that work for Graphite
   ISL_CHECK_VERSION(0,10)
+  if test "${gcc_cv_isl}" = no ; then
+ISL_CHECK_VERSION(0,11)
+  fi
   dnl Only execute fail-action, if ISL has been requested.
   ISL_IF_FAILED([
 AC_MSG_ERROR([Unable to find a usable ISL.  See config.log for details.])])
@@ -1617,11 +1620,11 @@ if test "x$with_isl" != "xno" &&
 dnl Provide configure switches and initialize clooginc & clooglibs
 dnl with user input.
 CLOOG_INIT_FLAGS
-dnl The minimal version of CLooG required for Graphite.
-dnl
-dnl If we use CLooG-Legacy, the provided version information is
-dnl ignored.
+dnl The versions of CLooG that work for Graphite.
 CLOOG_CHECK_VERSION(0,17,0)
+if test "${gcc_cv_cloog}" = no ; then
+  CLOOG_CHECK_VERSION(0,18,0)
+fi
 
 dnl Only execute fail-action, if CLooG has been requested.
 CLOOG_IF_FAILED([


Re: RFA: Update copyright for libcpp

2013-01-14 Thread Tom Tromey
> "Richard" == Richard Sandiford  writes:

Richard> Here's the result of running the copyright script on libcpp/.
Richard> It's nice and short, but for consistency with the other patches,
Richard> I've not listed out every file in the changelog.

Richard> Tested on x86_64-linux-gnu.  OK to install?

Yes, thanks.

Tom


Re: [RFC, middlend] Fix for PR54218

2013-01-14 Thread Richard Biener
On Fri, Jan 11, 2013 at 6:37 PM, George Thomas
 wrote:
> On Fri, Jan 11, 2013 at 9:53 PM, Andrew Pinski  wrote:
>> On Fri, Jan 11, 2013 at 8:17 AM, George Thomas
>>  wrote:
>>> Hi,
>>>
>>> I am sending a patch which solves the debugging issue (PR 54218).
>>>
>>> The fix is to allocate stack space only once for parameters in expand pass.
>>>
>>> The patch is attached. Could someone suggest if its right ?
>>
>> I have just a formatting issue:
>> + if (TREE_CODE (SSA_NAME_VAR (var)) != PARM_DECL)
>> +  {
>> +if (!bitmap_bit_p (SA.partition_has_default_def, i))
>>
>> I think it would have been better if you had done instead:
>>   if (TREE_CODE (SSA_NAME_VAR (var)) != PARM_DECL
>>  && !bitmap_bit_p (SA.partition_has_default_def, i))
>>
>
> I have attached the updated patch with the changes suggested.
> Also adding a dejagnu test case to reproduce the bug.
>
>> So there are no other white space changes.
>>
>> Also missing a changelog entry too.
>>
>
> I am adding the change logs below.
>
> 2013-01-11  George Thomas  
>  Senthil Kumar Selvaraj 
>
>  PR middle-end/54218
>
>  * gcc/cfgexpand.c (expand_used_vars ) :Added
>   a step to not allocate stack space if its a parameter
>
>  * gcc.dg/pr54218.c : New test
>
>
> Hoping that the changes are fine for trunk.

Please state how you tested the patch (bootstrap and regtest on which target?)

Thanks,
Richard.

>
> Thanks,
> George


[PATCH] Fix fixinclude common/non-common mix

2013-01-14 Thread Richard Biener

fixincludes mixes common declarations (in fixlib.h) and non-common
decls (where they are defined) for verbose_level and fixinc_mode.
XCode on Mountain Lion doesn't like this and its linker (rightfully)
complains.

Fixed with the following, committed as obvious.

Richard.

2013-01-14  Richard Biener  

* fixlib.h (verbose_level, fixinc_mode): Mark extern.

Index: fixincludes/fixlib.h
===
--- fixincludes/fixlib.h(revision 195140)
+++ fixincludes/fixlib.h(working copy)
@@ -223,7 +223,7 @@ typedef enum {
   VERB_EVERYTHING
 } te_verbose;
 
-te_verbose  verbose_level;
+extern te_verbose  verbose_level;
 
 #define VLEVEL(l)  ((unsigned int) verbose_level >= (unsigned int) l)
 #define NOT_SILENT VLEVEL(VERB_FIXES)
@@ -233,7 +233,7 @@ typedef enum {
   TESTING_ON  = 1
 } fixinc_mode_t;
 
-fixinc_mode_t fixinc_mode;
+extern fixinc_mode_t fixinc_mode;
 
 #ifdef HAVE_MMAP_FILE
 #define UNLOAD_DATA() do { if (curr_data_mapped) { \


Re: RFA: Allow widening multiplication in tree-ssa/slsr-8.c

2013-01-14 Thread Richard Biener
On Sun, Jan 13, 2013 at 9:50 AM, Richard Sandiford
 wrote:
> gcc.dg/tree-ssa/slsr-8.c does "(int) index * (size_t) element_size",
> which on LP64 targets can use a widening multiplication.  Of course,
> for simple element sizes like these, we end up using a shift instead,
> but that's a decision that's rightly made later.
>
> Tested on x86_64-linux-gnu, mips64-linux-gnu and mipsisa64-elf.
> OK to install?

Ok.

Thanks,
Richard.

> Richard
>
>
> gcc/testsuite/
> * gcc.dg/tree-ssa/slsr-8.c: Allow widening multiplications.
>
> Index: gcc/testsuite/gcc.dg/tree-ssa/slsr-8.c
> ===
> --- gcc/testsuite/gcc.dg/tree-ssa/slsr-8.c  2013-01-13 08:05:03.403375571 
> +
> +++ gcc/testsuite/gcc.dg/tree-ssa/slsr-8.c  2013-01-13 08:46:05.246550444 
> +
> @@ -18,6 +18,7 @@ f (int s, int *c)
>  }
>
>  /* There are 4 ' * ' instances in the decls (since "int * iftmp.0;" is
> -   added), 1 parm, 2 in the code.  */
> -/* { dg-final { scan-tree-dump-times " \\* " 7 "optimized" } } */
> +   added), 1 parm, 2 in the code.  The second one in the code can be
> +   a widening mult.  */
> +/* { dg-final { scan-tree-dump-times " w?\\* " 7 "optimized" } } */
>  /* { dg-final { cleanup-tree-dump "optimized" } } */


Re: [PATCH] Fix PR55876 - Make generation of paradoxical subreg in widen_operand more robust

2013-01-14 Thread Tom de Vries
On 07/01/13 18:48, Richard Henderson wrote:
> On 01/07/2013 02:16 AM, Tom de Vries wrote:
>> -  /* If MODE is no wider than a single word, we return a paradoxical
>> - SUBREG.  */
>> +  /* If MODE is no wider than a single word, we return a
>> + lowpart or paradoxical SUBREG.  */
>>if (GET_MODE_SIZE (mode) <= UNITS_PER_WORD)
>> -return gen_rtx_SUBREG (mode, force_reg (GET_MODE (op), op), 0);
>> +{
>> +  if (GET_MODE_SIZE (mode) < GET_MODE_SIZE (GET_MODE (op)))
>> +   return gen_lowpart_SUBREG (mode, op);
>> +  else
>> +   return gen_rtx_SUBREG (mode, force_reg (GET_MODE (op), op), 0);
>> +}
> 
> Is there any good reason we're using gen_rtx_SUBREG directly here?
> Seems like this sort of logic would be present in plain gen_lowpart,
> generating the paradoxical subreg that we want.
> 

Ah, didn't realize that. Attached patch uses gen_lowpart.

Bootstrapped and reg-tested on x86_64.

Build and reg-tested on mips64, -mabi=n32 and -mabi=64.

OK for trunk?

Thanks,
- Tom

2013-01-14  Tom de Vries  

PR target/55876
* optabs.c (widen_operand): Use gen_lowpart instead of gen_rtx_SUBREG.
Update comment.

Index: gcc/optabs.c
===
--- gcc/optabs.c (revision 194898)
+++ gcc/optabs.c (working copy)
@@ -327,10 +327,10 @@ widen_operand (rtx op, enum machine_mode
 	  && SUBREG_PROMOTED_UNSIGNED_P (op) == unsignedp))
 return convert_modes (mode, oldmode, op, unsignedp);
 
-  /* If MODE is no wider than a single word, we return a paradoxical
+  /* If MODE is no wider than a single word, we return a lowpart or paradoxical
  SUBREG.  */
   if (GET_MODE_SIZE (mode) <= UNITS_PER_WORD)
-return gen_rtx_SUBREG (mode, force_reg (GET_MODE (op), op), 0);
+return gen_lowpart (mode, force_reg (GET_MODE (op), op));
 
   /* Otherwise, get an object of MODE, clobber it, and set the low-order
  part to OP.  */


Re: [PATCH 1/2] Document HLE / RTM intrinsics

2013-01-14 Thread Richard Biener
On Sat, Jan 12, 2013 at 6:20 PM, Andi Kleen  wrote:
> On Sat, Jan 12, 2013 at 06:04:19PM +0100, Bernhard Reutner-Fischer wrote:
>> On 12 January 2013 16:28:41 Andi Kleen  wrote:
>> >From: Andi Kleen 
>>
>> >+Returns _XBEGIN_STARTED when the transaction
>> >+started successfully (not this is not 0, so the constant has to be
>>
>> not this is not 0? Or note?
>
> "note"
>
> Thanks. Will fix before comitting.

I think (somewhere else) we agreed to only document intrinsics,
not the __builtin_ia32_ variants (they are an implementation detail).
Yes, we're not consistent with that, but we do miss a lot of
documentation for these kind of builtins.  I suppose we also do not
document all intrinsics either (though that's desired, as we provide
those headers - even manpages would be nice for them I suppose).

Target maintainers?

Thanks,
Richard.

> -Andi


Re: [PATCH] Fix fixinclude common/non-common mix

2013-01-14 Thread Bruce Korb
Hi,

On Mon, Jan 14, 2013 at 12:42 AM, Richard Biener  wrote:
>
> fixincludes mixes common declarations (in fixlib.h) and non-common
> decls (where they are defined) for verbose_level and fixinc_mode.
> XCode on Mountain Lion doesn't like this and its linker (rightfully)
> complains.

It is not rightful that it complain, but it is rightful to accommodate
it.  "approved."


[PATCH] Location verifier

2013-01-14 Thread Richard Biener

This adds a verification that we do not refer to BLOCKs not in the
functions BLOCK tree from locations.

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

Richard.

2013-01-14  Richard Biener  

* tree-cfg.c (verify_expr_location, verify_expr_location_1,
verify_location, collect_subblocks): New functions.
(verify_gimple_in_cfg): Verify that locations only reference
BLOCKs in the functions BLOCK tree.

Index: gcc/tree-cfg.c
===
*** gcc/tree-cfg.c.orig 2013-01-14 14:09:49.0 +0100
--- gcc/tree-cfg.c  2013-01-14 14:11:29.401025151 +0100
*** verify_eh_throw_stmt_node (void **slot,
*** 4519,4524 
--- 4519,4581 
return 1;
  }
  
+ /* Verify if the location LOCs block is in BLOCKS.  */
+ 
+ static bool
+ verify_location (pointer_set_t *blocks, location_t loc)
+ {
+   tree block = LOCATION_BLOCK (loc);
+   if (block != NULL_TREE
+   && !pointer_set_contains (blocks, block))
+ {
+   error ("location references block not in block tree");
+   return true;
+ }
+   return false;
+ }
+ 
+ /* Called via walk_tree.  Verify locations of expressions.  */
+ 
+ static tree
+ verify_expr_location_1 (tree *tp, int *walk_subtrees, void *data)
+ {
+   struct pointer_set_t *blocks = (struct pointer_set_t *) data;
+ 
+   if (!EXPR_P (*tp))
+ {
+   *walk_subtrees = false;
+   return NULL;
+ }
+ 
+   location_t loc = EXPR_LOCATION (*tp);
+   if (verify_location (blocks, loc))
+ return *tp;
+ 
+   return NULL;
+ }
+ 
+ /* Called via walk_gimple_op.  Verify locations of expressions.  */
+ 
+ static tree
+ verify_expr_location (tree *tp, int *walk_subtrees, void *data)
+ {
+   struct walk_stmt_info *wi = (struct walk_stmt_info *) data;
+   return verify_expr_location_1 (tp, walk_subtrees, wi->info);
+ }
+ 
+ /* Insert all subblocks of BLOCK into BLOCKS and recurse.  */
+ 
+ static void
+ collect_subblocks (pointer_set_t *blocks, tree block)
+ {
+   tree t;
+   for (t = BLOCK_SUBBLOCKS (block); t; t = BLOCK_CHAIN (t))
+ {
+   pointer_set_insert (blocks, t);
+   collect_subblocks (blocks, t);
+ }
+ }
+ 
  /* Verify the GIMPLE statements in the CFG of FN.  */
  
  DEBUG_FUNCTION void
*** verify_gimple_in_cfg (struct function *f
*** 4526,4537 
  {
basic_block bb;
bool err = false;
!   struct pointer_set_t *visited, *visited_stmts;
  
timevar_push (TV_TREE_STMT_VERIFY);
visited = pointer_set_create ();
visited_stmts = pointer_set_create ();
  
FOR_EACH_BB_FN (bb, fn)
  {
gimple_stmt_iterator gsi;
--- 4583,4602 
  {
basic_block bb;
bool err = false;
!   struct pointer_set_t *visited, *visited_stmts, *blocks;
  
timevar_push (TV_TREE_STMT_VERIFY);
visited = pointer_set_create ();
visited_stmts = pointer_set_create ();
  
+   /* Collect all BLOCKs referenced by the BLOCK tree of FN.  */
+   blocks = pointer_set_create ();
+   if (DECL_INITIAL (fn->decl))
+ {
+   pointer_set_insert (blocks, DECL_INITIAL (fn->decl));
+   collect_subblocks (blocks, DECL_INITIAL (fn->decl));
+ }
+ 
FOR_EACH_BB_FN (bb, fn)
  {
gimple_stmt_iterator gsi;
*** verify_gimple_in_cfg (struct function *f
*** 4552,4557 
--- 4617,4629 
  
  err2 |= verify_gimple_phi (phi);
  
+ /* Only PHI arguments have locations.  */
+ if (gimple_location (phi) != UNKNOWN_LOCATION)
+   {
+ error ("PHI node with location");
+ err2 = true;
+   }
+ 
  for (i = 0; i < gimple_phi_num_args (phi); i++)
{
  tree arg = gimple_phi_arg_def (phi, i);
*** verify_gimple_in_cfg (struct function *f
*** 4563,4568 
--- 4635,4654 
  debug_generic_expr (addr);
  err2 |= true;
}
+ location_t loc = gimple_phi_arg_location (phi, i);
+ if (virtual_operand_p (gimple_phi_result (phi))
+ && loc != UNKNOWN_LOCATION)
+   {
+ error ("virtual PHI with argument locations");
+ err2 = true;
+   }
+ addr = walk_tree (&arg, verify_expr_location_1, blocks, NULL);
+ if (addr)
+   {
+ debug_generic_expr (addr);
+ err2 = true;
+   }
+ err2 |= verify_location (blocks, loc);
}
  
  if (err2)
*** verify_gimple_in_cfg (struct function *f
*** 4587,4592 
--- 4673,4679 
}
  
  err2 |= verify_gimple_stmt (stmt);
+ err2 |= verify_location (blocks, gimple_location (stmt));
  
  memset (&wi, 0, sizeof (wi));
  wi.info = (void *) visited;
*** verify_gimple_in_cfg (struct function *f
*** 4598,4603 
--- 4685,4699 
  err2 |= true;
}
  
+ memse

[4.7/4.6] Backport typo fix

2013-01-14 Thread Eric Botcazou
Having vect_get_single_scalar_iteraion_cost is really not pretty.  This was 
fixed on the mainline only (r188611) so this patch completes the work.

Tested on x86-64/Linux, applied on the 4.7 branch and 4.6 branch as obvious.


2013-01-14  Eric Botcazou  

* tree-vectorizer.h (vect_get_single_scalar_iteraion_cost): Fix typo.
* tree-vect-loop.c (vect_get_single_scalar_iteraion_cost): Likewise.
(vect_estimate_min_profitable_iter): Adjust to above fix.
* tree-vect-data-refs.c (vect_peeling_hash_get_lowest_cost): Likewise.


-- 
Eric BotcazouIndex: tree-vectorizer.h
===
--- tree-vectorizer.h	(revision 194927)
+++ tree-vectorizer.h	(working copy)
@@ -916,7 +916,7 @@ extern int vect_estimate_min_profitable_
 extern tree get_initial_def_for_reduction (gimple, tree, tree *);
 extern int vect_min_worthwhile_factor (enum tree_code);
 extern int vect_get_known_peeling_cost (loop_vec_info, int, int *, int);
-extern int vect_get_single_scalar_iteraion_cost (loop_vec_info);
+extern int vect_get_single_scalar_iteration_cost (loop_vec_info);
 
 /* In tree-vect-slp.c.  */
 extern void vect_free_slp_instance (slp_instance);
Index: tree-vect-loop.c
===
--- tree-vect-loop.c	(revision 194927)
+++ tree-vect-loop.c	(working copy)
@@ -2386,7 +2386,7 @@ vect_force_simple_reduction (loop_vec_in
 
 /* Calculate the cost of one scalar iteration of the loop.  */
 int
-vect_get_single_scalar_iteraion_cost (loop_vec_info loop_vinfo)
+vect_get_single_scalar_iteration_cost (loop_vec_info loop_vinfo)
 {
   struct loop *loop = LOOP_VINFO_LOOP (loop_vinfo);
   basic_block *bbs = LOOP_VINFO_BBS (loop_vinfo);
@@ -2619,7 +2619,7 @@ vect_estimate_min_profitable_iters (loop
 	}
 }
 
-  scalar_single_iter_cost = vect_get_single_scalar_iteraion_cost (loop_vinfo);
+  scalar_single_iter_cost = vect_get_single_scalar_iteration_cost (loop_vinfo);
 
   /* Add additional cost for the peeled instructions in prologue and epilogue
  loop.
Index: tree-vect-data-refs.c
===
--- tree-vect-data-refs.c	(revision 194927)
+++ tree-vect-data-refs.c	(working copy)
@@ -1296,7 +1296,7 @@ vect_peeling_hash_get_lowest_cost (void
 }
 
   outside_cost += vect_get_known_peeling_cost (loop_vinfo, elem->npeel, &dummy,
- vect_get_single_scalar_iteraion_cost (loop_vinfo));
+ vect_get_single_scalar_iteration_cost (loop_vinfo));
 
   if (inside_cost < min->inside_cost
   || (inside_cost == min->inside_cost && outside_cost < min->outside_cost))


[avr,committed] Some no-op changes: Typo, Add copyright notices, Coding rules, Trailing blanks, etc.

2013-01-14 Thread Georg-Johann Lay
Added copyright notices (avr-lib.h, avr-modes.def):

http://gcc.gnu.org/viewcvs?view=revision&revision=195143
http://gcc.gnu.org/viewcvs?view=revision&revision=195145

Fix typos, remove trailing blanks, coding rules, ...

http://gcc.gnu.org/viewcvs?view=revision&revision=195151


[PATCH] Let target get_memmodel know about stores/barriers

2013-01-14 Thread Andi Kleen
From: Andi Kleen 

For HLE stores are only valid with __ATOMIC_HLE_RELEASE. The middle end
didn't know this. This adds a new parameter to the get_memmodel target
hook to distingush stores and give an warning for acquire stores.

I also did a similar check for the barriers where HLE is not useful
at all.

Fixes one todo in the earlier hle release patch.

gcc/:
2013-01-13  Andi Kleen  

PR target/55948
* builtins.c (get_memmodel): Pass store, barrier parameters to target
hook.
(expand_builtin_atomic_exchange,
 expand_builtin_atomic_compare_exchange,
 expand_builtin_atomic_load,
 expand_builtin_atomic_store,
 expand_builtin_atomic_fetch_op,
 expand_builtin_atomic_test_and_set,
 expand_builtin_atomic_test_lock,
 expand_builtin_atomic_clear,
 expand_builtin_atomic_thread_fence): Pass store, barrier
parameters to get_memmodel.
* config/i386/i386.c (ix86_memmodel_check): Add store, barrier warning.
* doc/tm.texi (TARGET_GET_MEMMODEL): Add store, barrier parameters.
* doc/tm.exit.in (TARGET_GET_MEMMODEL): Dito.
* target.def (TARGET_GET_MEMMODEL): Dito.
---
 gcc/builtins.c |   30 +++---
 gcc/config/i386/i386.c |   21 +++--
 gcc/doc/tm.texi|6 --
 gcc/doc/tm.texi.in |4 +++-
 gcc/target.def |3 ++-
 5 files changed, 43 insertions(+), 21 deletions(-)

diff --git a/gcc/builtins.c b/gcc/builtins.c
index 1d0aec6..f9c5656 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -5272,10 +5272,12 @@ expand_builtin_sync_lock_release (enum machine_mode 
mode, tree exp)
 }
 
 /* Given an integer representing an ``enum memmodel'', verify its
-   correctness and return the memory model enum.  */
+   correctness and return the memory model enum.  When STORE
+   is true this for a store only. When BARRIER is true this if for
+   a barrier.  */
 
 static enum memmodel
-get_memmodel (tree exp)
+get_memmodel (tree exp, bool store, bool barrier)
 {
   rtx op;
   unsigned HOST_WIDE_INT val;
@@ -5289,7 +5291,7 @@ get_memmodel (tree exp)
 
   val = INTVAL (op);
   if (targetm.memmodel_check)
-val = targetm.memmodel_check (val);
+val = targetm.memmodel_check (val, store, barrier);
   else if (val & ~MEMMODEL_MASK)
 {
   warning (OPT_Winvalid_memory_model,
@@ -5318,7 +5320,7 @@ expand_builtin_atomic_exchange (enum machine_mode mode, 
tree exp, rtx target)
   rtx val, mem;
   enum memmodel model;
 
-  model = get_memmodel (CALL_EXPR_ARG (exp, 2));
+  model = get_memmodel (CALL_EXPR_ARG (exp, 2), false, false);
   if ((model & MEMMODEL_MASK) == MEMMODEL_CONSUME)
 {
   error ("invalid memory model for %<__atomic_exchange%>");
@@ -5352,8 +5354,8 @@ expand_builtin_atomic_compare_exchange (enum machine_mode 
mode, tree exp,
   tree weak;
   bool is_weak;
 
-  success = get_memmodel (CALL_EXPR_ARG (exp, 4));
-  failure = get_memmodel (CALL_EXPR_ARG (exp, 5));
+  success = get_memmodel (CALL_EXPR_ARG (exp, 4), false, false);
+  failure = get_memmodel (CALL_EXPR_ARG (exp, 5), false, false);
 
   if ((failure & MEMMODEL_MASK) == MEMMODEL_RELEASE
   || (failure & MEMMODEL_MASK) == MEMMODEL_ACQ_REL)
@@ -5408,7 +5410,7 @@ expand_builtin_atomic_load (enum machine_mode mode, tree 
exp, rtx target)
   rtx mem;
   enum memmodel model;
 
-  model = get_memmodel (CALL_EXPR_ARG (exp, 1));
+  model = get_memmodel (CALL_EXPR_ARG (exp, 1), false, false);
   if ((model & MEMMODEL_MASK) == MEMMODEL_RELEASE
   || (model & MEMMODEL_MASK) == MEMMODEL_ACQ_REL)
 {
@@ -5437,7 +5439,7 @@ expand_builtin_atomic_store (enum machine_mode mode, tree 
exp)
   rtx mem, val;
   enum memmodel model;
 
-  model = get_memmodel (CALL_EXPR_ARG (exp, 2));
+  model = get_memmodel (CALL_EXPR_ARG (exp, 2), true, false);
   if ((model & MEMMODEL_MASK) != MEMMODEL_RELAXED
   && (model & MEMMODEL_MASK) != MEMMODEL_SEQ_CST
   && (model & MEMMODEL_MASK) != MEMMODEL_RELEASE)
@@ -5477,7 +5479,7 @@ expand_builtin_atomic_fetch_op (enum machine_mode mode, 
tree exp, rtx target,
   tree fndecl;
   tree addr;
 
-  model = get_memmodel (CALL_EXPR_ARG (exp, 2));
+  model = get_memmodel (CALL_EXPR_ARG (exp, 2), false, false);
 
   /* Expand the operands.  */
   mem = get_builtin_sync_mem (CALL_EXPR_ARG (exp, 0), mode);
@@ -5544,7 +5546,7 @@ expand_builtin_atomic_clear (tree exp)
 
   mode = mode_for_size (BOOL_TYPE_SIZE, MODE_INT, 0);
   mem = get_builtin_sync_mem (CALL_EXPR_ARG (exp, 0), mode);
-  model = get_memmodel (CALL_EXPR_ARG (exp, 1));
+  model = get_memmodel (CALL_EXPR_ARG (exp, 1), true, false);
 
   if ((model & MEMMODEL_MASK) == MEMMODEL_ACQUIRE
   || (model & MEMMODEL_MASK) == MEMMODEL_ACQ_REL)
@@ -5553,8 +,6 @@ expand_builtin_atomic_clear (tree exp)
   return const0_rtx;
 }
 
-  /* need target hook there to check for not hle acquire */
-
   if (HAVE_atomic_clear)
 {
   emit_insn (gen_atomic_clear (mem, model));

Re: [PATCH] Allow new ISL/CLooG versions

2013-01-14 Thread Tobias Grosser

On 01/14/2013 03:29 PM, Richard Biener wrote:


This makes us accept the CLooG 0.18.0 and ISL 0.11.1 combo.

It's probably not the best stage to move the version checks to
gcc/ where we can rely on built in-tree ISL/CLooG, so this avoids
it with the caveat that in-tree CLooG 0.18.0 will fail the
version check (they no longer ship built version.h but only
version.h.in).

I verified all GRAPHITE tests pass with 0.18.0/0.11.1.

Ok for trunk?

Or do people prefer to move CLooG/ISL checks to gcc/ configure
time to fix the in-tree use of 0.18.0 and also do version checks
of in-tree ISL at all (they don't have a version.h).


Hi Richi,

I think this is a good thing. But this probably requires some config 
guys to approve it.


All the best,
Tobi



[PATCH] Fix PR55792

2013-01-14 Thread Richard Biener

This fixes LTO profiledbootstrap by pruning locations at
tree_function_versioning time - there seems to be at least one
uncatched case in IPA opts.

LTO profilebootstrapped and tested on x86_64-unknown-linux-gnu.

I also had the extended lto-cgraph.c verification in-tree but do not
plan to commit that.

Does this look reasonable or should somebody (not me ;)) try to track
down the place where we fail to unshare?

Thanks,
Richard.

2013-01-14  Richard Biener  

PR bootstrap/55792
* tree-inline.c (tree_function_versioning): Purge locations
from replaced parameters.

Index: gcc/lto-cgraph.c
===
*** gcc/lto-cgraph.c(revision 195144)
--- gcc/lto-cgraph.c(working copy)
*** output_edge_opt_summary (struct output_b
*** 1492,1497 
--- 1492,1513 
  {
  }
  
+ static tree
+ verify_no_location_r (tree *tp, int *walk_subtrees, void *)
+ {
+   if (EXPR_P (*tp))
+ gcc_assert (EXPR_LOCATION (*tp) == UNKNOWN_LOCATION);
+   else
+ *walk_subtrees = 0;
+   return NULL_TREE;
+ }
+ 
+ static void
+ verify_no_location (tree expr)
+ {
+   walk_tree (&expr, verify_no_location_r, NULL, NULL);
+ }
+ 
  /* Output optimization summary for NODE to OB.  */
  
  static void
*** output_node_opt_summary (struct output_b
*** 1536,1542 
   mechanism to store function local declarations into summaries.  */
gcc_assert (parm);
streamer_write_uhwi (ob, parm_num);
!   gcc_assert (EXPR_LOCATION (map->new_tree) == UNKNOWN_LOCATION);
stream_write_tree (ob, map->new_tree, true);
bp = bitpack_create (ob->main_stream);
bp_pack_value (&bp, map->replace_p, 1);
--- 1552,1560 
   mechanism to store function local declarations into summaries.  */
gcc_assert (parm);
streamer_write_uhwi (ob, parm_num);
! #ifdef ENABLE_CHECKING
!   verify_no_location (map->new_tree);
! #endif
stream_write_tree (ob, map->new_tree, true);
bp = bitpack_create (ob->main_stream);
bp_pack_value (&bp, map->replace_p, 1);
Index: gcc/tree-inline.c
===
*** gcc/tree-inline.c   (revision 195144)
--- gcc/tree-inline.c   (working copy)
*** tree_function_versioning (tree old_decl,
*** 5190,5196 
replace_info = (*tree_map)[i];
if (replace_info->replace_p)
  {
!   tree op = replace_info->new_tree;
if (!replace_info->old_tree)
  {
int i = replace_info->parm_num;
--- 5190,5196 
replace_info = (*tree_map)[i];
if (replace_info->replace_p)
  {
!   tree op = unshare_expr_without_location (replace_info->new_tree);
if (!replace_info->old_tree)
  {
int i = replace_info->parm_num;
*** tree_function_versioning (tree old_decl,
*** 5199,5216 
  i --;
replace_info->old_tree = parm;
  }
-   
- 
-   STRIP_NOPS (op);
- 
-   if (TREE_CODE (op) == VIEW_CONVERT_EXPR)
- op = TREE_OPERAND (op, 0);
- 
gcc_assert (TREE_CODE (replace_info->old_tree) == PARM_DECL);
init = setup_one_parameter (&id, replace_info->old_tree,
!   replace_info->new_tree, id.src_fn,
!   NULL,
!   &vars);
if (init)
  init_stmts.safe_push (init);
  }
--- 5199,5208 
  i --;
replace_info->old_tree = parm;
  }
gcc_assert (TREE_CODE (replace_info->old_tree) == PARM_DECL);
+ 
init = setup_one_parameter (&id, replace_info->old_tree,
!   op, id.src_fn, NULL, &vars);
if (init)
  init_stmts.safe_push (init);
  }


Re: [RFC PATCH] Implementing ifunc target hook

2013-01-14 Thread Alexander Ivchenko
thank you very much for your review!

I fixed the arm build and all other issues that you raised.

the patch is attached. Bootstrap and tested on x86-64 linux

Alexander

2013/1/11 Maxim Kuvyrkov :
> On 10/01/2013, at 12:24 AM, Alexander Ivchenko wrote:
>
>>> Config/linux-android.h is a better place for this declaration.
>
> I was wrong here.  Config/linux-android.h is not a "re-includable" header, 
> and is not fit for function declarations.
>
>>
>> That wouldn't help, I got the following error:
>>
>> In file included from ../../.././gcc/tm.h:24:0,
>> from [..]/src/gcc/libgcc/generic-morestack-thread.c:29:
>> [..]/src/gcc/libgcc/../gcc/config/linux-android.h:62:1: error: unknown
>> type name ‘bool’
>> extern bool linux_android_has_ifunc_p (void);
>> ^
>>
>> Anyway, linux-protos.h looks to me as a good thing to have (e.g. for
>> libc_has_function hook, that is
>> supposed to be commited in a near future) for declaring linux (and
>> Android) specific versions of hooks..
>
> OK, I agree.  In theory linux_android_has_ifunc_p could've been placed into 
> linux-android-protos.h, but having a separate file (from linux-protos.h) just 
> for 1-2 declarations is not justified.
>
 + "It returns true if the target supports GNU indirect functions.\n\
 +The support includes the assembler, linker and dynamic linker.\n\
 +The default value of this hook is defined as for the host machine.",
>>>
>>> Are your sure the last sentence is correct?  It seems the default value for 
>>> this hook is based on which libc is being used.  Maybe it would be more 
>>> accurate to say "The default value of this hook is based on target's libc."?
>>
>> Well yes, you are right that the default value depends on version of
>> libc, but this version
>> is checked on the configure time for the host machine
>> (HAVE_GNU_INDIRECT_FUNCTION),
>
> No.  And even if that was the case that would be a bug.
>
> HAVE_GNU_INDIRECT_FUNCTION is set based on default_gnu_indirect_function 
> variable defined in config.gcc (unless overridden with a configure argument). 
>  This variable is set to true for targets that support IFUNCs irrespective of 
> host and host's libc.
>
>> --- a/gcc/config.gcc
>> +++ b/gcc/config.gcc
>> @@ -637,6 +637,11 @@ case ${target} in
>>native_system_header_dir=/include
>>;;
>>esac
>> +  case $target in
>> +*linux*)
>> +  tm_p_file="${tm_p_file} linux-protos.h"
>> +  ;;
>> +  esac
>># glibc / uclibc / bionic switch.
>># uclibc and bionic aren't usable for GNU/Hurd and neither for GNU/k*BSD.
>>case $target in
>> @@ -662,8 +667,10 @@ case ${target} in
>># Add Android userspace support to Linux targets.
>>case $target in
>>  *linux*)
>> +  tmake_file="${tmake_file} t-linux-android"
>>tm_file="$tm_file linux-android.h"
>>extra_options="$extra_options linux-android.opt"
>> +  extra_objs="$extra_objs linux-android.o"
>>;;
>>esac
>># Enable compilation for Android by default for *android* targets.
>>
>
> Also scan config.gcc for any other occurences of linux-android.h and add same 
> changes there.  I believe only arm*-*-linux-* is affected.
>
>
>> --- a/gcc/config/host-linux.c
>> +++ b/gcc/config/host-linux.c
>> @@ -23,7 +23,6 @@
>>  #include "hosthooks.h"
>>  #include "hosthooks-def.h"
>>
>> -
>>  /* Linux has a feature called exec-shield-randomize that perturbs the
>> address of non-fixed mapped segments by a (relatively) small amount.
>> The feature is intended to make it harder to attack the system with
>
> Don't change formatting unless you are editing the code around it.
>
>> diff --git a/gcc/config/linux-android.c b/gcc/config/linux-android.c
>> new file mode 100644
>> index 000..47cc50a
>> --- /dev/null
>> +++ b/gcc/config/linux-android.c
> ...
>> +You should have received a copy of the GNU General Public License
>> +along with GCC; see the file COPYING3.  If not see
>> +.  */
>> +
>> +#include "config.h"
>> +#include "system.h"
>> +#include "coretypes.h"
>> +#include "tm.h"
>
> Add '#include "linux-protos.h"'.  Remember to update t-linux-android.
>
>> +
>> +/* Android does not support GNU indirect functions.  */
>> +
>> +bool
>> +linux_android_has_ifunc_p (void)
>> +{
>> +  return TARGET_ANDROID ? false : HAVE_GNU_INDIRECT_FUNCTION;
>> +}
>>
>
>
> Please send one last version for the final review, primarily to double check 
> your changes to arm*-linux-* to avoid breaking it.
>
> Thanks!
>
> --
> Maxim Kuvyrkov
>
>
>
>
>


disable_ifunc_for_android_06.patch
Description: Binary data


[PATCH][RFC] Fix PR55964

2013-01-14 Thread Richard Biener

I happen to have a patch for PR55964 around - preparatory work
to make loop distribution (and vectorization) handle nested loops.
It mostly kills the broken way loop distribution copies loops
(which is where we ICE in this PR).  So instead of trying to
make that old logic slightly less broken I consider to simply
apply this work now ... (I've posted this before in December).

I'm re-bootstrapping and testing this on x86_64-unknown-linux-gnu.

So ... ok at this stage?

Thanks,
Richard.

2013-01-14  Richard Biener  

PR tree-optimization/55964
* tree-flow.h (rename_variables_in_loop): Remove.
(rename_variables_in_bb): Likewise.
* tree-loop-distribution.c (update_phis_for_loop_copy): Remove.
(copy_loop_before): Adjust and delete update-ssa status.
* tree-vect-loop-manip.c (rename_variables_in_bb): Make static.
(rename_variables_in_bb): Likewise.  Properly walk over
predecessors.
(rename_variables_in_loop): Remove.
(slpeel_update_phis_for_duplicate_loop): Likewise.
(slpeel_tree_duplicate_loop_to_edge_cfg): Handle nested loops,
use available cfg machinery instead of duplicating it.
Update PHI nodes and perform poor-mans SSA update here.
(slpeel_tree_peel_loop_to_edge): Adjust.

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

Index: trunk/gcc/tree-loop-distribution.c
===
*** trunk.orig/gcc/tree-loop-distribution.c 2013-01-14 16:44:58.0 
+0100
--- trunk/gcc/tree-loop-distribution.c  2013-01-14 16:45:07.609800223 +0100
*** stmt_has_scalar_dependences_outside_loop
*** 151,208 
return false;
  }
  
- /* Update the PHI nodes of NEW_LOOP.  NEW_LOOP is a duplicate of
-ORIG_LOOP.  */
- 
- static void
- update_phis_for_loop_copy (struct loop *orig_loop, struct loop *new_loop)
- {
-   tree new_ssa_name;
-   gimple_stmt_iterator si_new, si_orig;
-   edge orig_loop_latch = loop_latch_edge (orig_loop);
-   edge orig_entry_e = loop_preheader_edge (orig_loop);
-   edge new_loop_entry_e = loop_preheader_edge (new_loop);
- 
-   /* Scan the phis in the headers of the old and new loops
-  (they are organized in exactly the same order).  */
-   for (si_new = gsi_start_phis (new_loop->header),
-si_orig = gsi_start_phis (orig_loop->header);
-!gsi_end_p (si_new) && !gsi_end_p (si_orig);
-gsi_next (&si_new), gsi_next (&si_orig))
- {
-   tree def;
-   source_location locus;
-   gimple phi_new = gsi_stmt (si_new);
-   gimple phi_orig = gsi_stmt (si_orig);
- 
-   /* Add the first phi argument for the phi in NEW_LOOP (the one
-associated with the entry of NEW_LOOP)  */
-   def = PHI_ARG_DEF_FROM_EDGE (phi_orig, orig_entry_e);
-   locus = gimple_phi_arg_location_from_edge (phi_orig, orig_entry_e);
-   add_phi_arg (phi_new, def, new_loop_entry_e, locus);
- 
-   /* Add the second phi argument for the phi in NEW_LOOP (the one
-associated with the latch of NEW_LOOP)  */
-   def = PHI_ARG_DEF_FROM_EDGE (phi_orig, orig_loop_latch);
-   locus = gimple_phi_arg_location_from_edge (phi_orig, orig_loop_latch);
- 
-   if (TREE_CODE (def) == SSA_NAME)
-   {
- new_ssa_name = get_current_def (def);
- 
- if (!new_ssa_name)
-   /* This only happens if there are no definitions inside the
-  loop.  Use the the invariant in the new loop as is.  */
-   new_ssa_name = def;
-   }
-   else
-   /* Could be an integer.  */
-   new_ssa_name = def;
- 
-   add_phi_arg (phi_new, new_ssa_name, loop_latch_edge (new_loop), locus);
- }
- }
- 
  /* Return a copy of LOOP placed before LOOP.  */
  
  static struct loop *
--- 151,156 
*** copy_loop_before (struct loop *loop)
*** 215,223 
res = slpeel_tree_duplicate_loop_to_edge_cfg (loop, preheader);
gcc_assert (res != NULL);
free_original_copy_tables ();
! 
!   update_phis_for_loop_copy (loop, res);
!   rename_variables_in_loop (res);
  
return res;
  }
--- 163,169 
res = slpeel_tree_duplicate_loop_to_edge_cfg (loop, preheader);
gcc_assert (res != NULL);
free_original_copy_tables ();
!   delete_update_ssa ();
  
return res;
  }
Index: trunk/gcc/tree-flow.h
===
*** trunk.orig/gcc/tree-flow.h  2013-01-14 16:44:58.0 +0100
--- trunk/gcc/tree-flow.h   2013-01-14 16:45:07.610800234 +0100
*** bool gimple_duplicate_loop_to_header_edg
*** 654,661 
 edge, vec *,
 int);
  struct loop *slpeel_tree_duplicate_loop_to_edge_cfg (struct loop *, edge);
- void rename_variables_in_loop (struct loop *);
- void rename_variables_in_bb (basic_block bb);
  tree expand_simple_operations (tree);
  void substitute_in_loop_info (struct loop *, tree, tree)

[patch] fix relinking libasan and libtsan on installation

2013-01-14 Thread Matthias Klose
with the recent libsanitizer update, libasan and libtsan got a dependency on
libstdc++.so.6, however when installing into an empty directory, and
libstdc++.so.6 isn't installed there first, both libasan and libtsan are
relinked against the system libstdc++.so.6. So make sure that libstdc++-v3 is
installed first.

ok for the trunk?

  Matthias
2013-01-13  Matthias Klose  

	* Makefile.def (install-target-libsanitizer): Depend on
	install-target-libstdc++-v3.
	* Makefile.in: Regenerate.

Index: Makefile.def
===
--- Makefile.def	(Revision 195136)
+++ Makefile.def	(Arbeitskopie)
@@ -524,6 +524,7 @@
 dependencies = { module=install-target-libgo; on=install-target-libatomic; };
 dependencies = { module=install-target-libgfortran; on=install-target-libquadmath; };
 dependencies = { module=install-target-libgfortran; on=install-target-libgcc; };
+dependencies = { module=install-target-libsanitizer; on=install-target-libstdc++-v3; };
 dependencies = { module=install-target-libsanitizer; on=install-target-libgcc; };
 dependencies = { module=install-target-libjava; on=install-target-libgcc; };
 dependencies = { module=install-target-libitm; on=install-target-libgcc; };
Index: Makefile.in
===
--- Makefile.in	(Revision 195136)
+++ Makefile.in	(Arbeitskopie)
@@ -46216,6 +46216,7 @@
 install-target-libgo: maybe-install-target-libatomic
 install-target-libgfortran: maybe-install-target-libquadmath
 install-target-libgfortran: maybe-install-target-libgcc
+install-target-libsanitizer: maybe-install-target-libstdc++-v3
 install-target-libsanitizer: maybe-install-target-libgcc
 install-target-libjava: maybe-install-target-libgcc
 install-target-libitm: maybe-install-target-libgcc


Re: [PATCH] Allow new ISL/CLooG versions

2013-01-14 Thread Jack Howarth
On Mon, Jan 14, 2013 at 04:44:04PM +0100, Tobias Grosser wrote:
> On 01/14/2013 03:29 PM, Richard Biener wrote:
>>
>> This makes us accept the CLooG 0.18.0 and ISL 0.11.1 combo.
>>
>> It's probably not the best stage to move the version checks to
>> gcc/ where we can rely on built in-tree ISL/CLooG, so this avoids
>> it with the caveat that in-tree CLooG 0.18.0 will fail the
>> version check (they no longer ship built version.h but only
>> version.h.in).
>>
>> I verified all GRAPHITE tests pass with 0.18.0/0.11.1.
>>
>> Ok for trunk?
>>
>> Or do people prefer to move CLooG/ISL checks to gcc/ configure
>> time to fix the in-tree use of 0.18.0 and also do version checks
>> of in-tree ISL at all (they don't have a version.h).
>
> Hi Richi,
>
> I think this is a good thing. But this probably requires some config  
> guys to approve it.
>
> All the best,
> Tobi

Tnis change has already been committed at...

r195150 | rguenth | 2013-01-14 10:01:13 -0500 (Mon, 14 Jan 2013) | 5 lines

2013-01-14  Richard Biener  

* configure.ac (cloog/isl): Also allow ISL 0.11.x and CLooG 0.18.0.
* configure: Re-generate


This change is broken in several ways. The current commit doesn't handle
isl 0.11.1 because it omits teaching config/isl.m4 how to handle revsions
with...

Index: config/isl.m4
===
--- config/isl.m4   (revision 194744)
+++ config/isl.m4   (working copy)
@@ -89,13 +89,13 @@ AC_DEFUN([ISL_REQUESTED],
 ]
 )
 
-# _ISL_CHECK_CT_PROG(MAJOR, MINOR)
+# _ISL_CHECK_CT_PROG(MAJOR, MINOR, REVISION)
 # 
 # Helper for verifying ISL compile time version.
 m4_define([_ISL_CHECK_CT_PROG],[AC_LANG_PROGRAM(
   [#include 
#include ],
-  [if (strncmp (isl_version (), "isl-$1.$2", strlen ("isl-$1.$2")) != 0)
+  [if (strncmp (isl_version (), "isl-$1.$2.$3", strlen ("isl-$1.$2.$3")) != 0)
  return 1;
])])
 
@@ -115,9 +115,9 @@ AC_DEFUN([ISL_CHECK_VERSION],
 LIBS="${_isl_saved_LIBS} -lisl"
 echo $CFLAGS
 
-AC_CACHE_CHECK([for version $1.$2 of ISL],
+AC_CACHE_CHECK([for version $1.$2.$3 of ISL],
   [gcc_cv_isl],
-  [AC_RUN_IFELSE([_ISL_CHECK_CT_PROG($1,$2)],
+  [AC_RUN_IFELSE([_ISL_CHECK_CT_PROG($1,$2,$3)],
[gcc_cv_isl=yes],
[gcc_cv_isl=no],
[gcc_cv_isl=yes])])

like config/cloog.m4 does. Also the current commit leaves the legacy...

   ISL_CHECK_VERSION(0,10)
+  if test "${gcc_cv_isl}" = no ; then
+ISL_CHECK_VERSION(0,11)
+  fi

test on isl 0.10 present insuring that it will fail for any out of tree
isl version.
 Jack





Re: [patch] fix relinking libasan and libtsan on installation

2013-01-14 Thread Jakub Jelinek
On Mon, Jan 14, 2013 at 05:01:28PM +0100, Matthias Klose wrote:
> 2013-01-13  Matthias Klose  
> 
>   * Makefile.def (install-target-libsanitizer): Depend on
>   install-target-libstdc++-v3.
>   * Makefile.in: Regenerate.

Okay.

> --- Makefile.def  (Revision 195136)
> +++ Makefile.def  (Arbeitskopie)
> @@ -524,6 +524,7 @@
>  dependencies = { module=install-target-libgo; on=install-target-libatomic; };
>  dependencies = { module=install-target-libgfortran; 
> on=install-target-libquadmath; };
>  dependencies = { module=install-target-libgfortran; 
> on=install-target-libgcc; };
> +dependencies = { module=install-target-libsanitizer; 
> on=install-target-libstdc++-v3; };
>  dependencies = { module=install-target-libsanitizer; 
> on=install-target-libgcc; };
>  dependencies = { module=install-target-libjava; on=install-target-libgcc; };
>  dependencies = { module=install-target-libitm; on=install-target-libgcc; };
> Index: Makefile.in
> ===
> --- Makefile.in   (Revision 195136)
> +++ Makefile.in   (Arbeitskopie)
> @@ -46216,6 +46216,7 @@
>  install-target-libgo: maybe-install-target-libatomic
>  install-target-libgfortran: maybe-install-target-libquadmath
>  install-target-libgfortran: maybe-install-target-libgcc
> +install-target-libsanitizer: maybe-install-target-libstdc++-v3
>  install-target-libsanitizer: maybe-install-target-libgcc
>  install-target-libjava: maybe-install-target-libgcc
>  install-target-libitm: maybe-install-target-libgcc


Jakub


Re: [lra] resync with trunk

2013-01-14 Thread Vladimir Makarov

On 13-01-11 5:39 PM, Steven Bosscher wrote:

Hello Vlad,

The attached patch back-ports to the LRA branch (or foward-ports,
depending on how you look at it :-) all the changes made on the trunk
to LRA.

Bootstrapped&tested on powerpc64-unknown-linux-gnu[1] and
ia64-unknown-linux-gnu[2], and cross-built and tested mipsisa64-elf
[3].

[1] http://gcc.gnu.org/ml/gcc-testresults/2013-01/msg01098.html
[2] http://gcc.gnu.org/ml/gcc-testresults/2013-01/msg01129.html
[3] http://gcc.gnu.org/ml/gcc-testresults/2013-01/msg01120.html

OK for the LRA branch?



Yes.  Thanks for this and installing automatic LRA branch testing, Steven.



Re: [PATCH] Fix PR55833 + cheaper checking

2013-01-14 Thread Marek Polacek
On Thu, Jan 10, 2013 at 11:19:43PM +0100, Zdenek Dvorak wrote:
> I agree -- at the very least, unswitch_single_loop should check whether there
> is any possiblity it could have affected irreducible loops information (this
> should only be the case when some already existing irreducible loop is altered
> in the progress).  Which is what it (or more precisely, remove_path function
> used by it) tries to do -- so is should be sufficient to check why this fails
> for the considered testcase, and make sure the situation is correctly 
> detected,

Actually, in this case, we don't call remove_path from unswitch_single_loop
at all.  So, here's another stab at it.  In this version, we will call
mark_irreducible_loops only in case where we're removing a loop
from loop hierarchy tree.  Because when we do that (and we're in some
irreducible region), the edge that connects those two loops
should be marked as EDGE_IRREDUCIBLE_LOOP.  And the preheader BB
eventually as BB_IRREDUCIBLE_LOOP.  Does this look any better?
I'm not actually checking whether we really are in a irreducible
region, should that be done (how?)?  Thanks.

Bootstrap and regtest pending on x86_64-unknown-linux-gnu.

2013-01-14  Richard Biener  
Marek Polacek  

PR rtl-optimization/55833
* loop-unswitch.c (unswitch_loops): Move loop verification...
(unswitch_single_loop): ...here.  Call mark_irreducible_loops.
* cfgloopmanip.c (fix_loop_placement): Add IRRED_INVALIDATED parameter.
Set it to true when we're removing a loop from hierarchy tree.
(fix_bb_placements): Adjust caller.
(fix_loop_placements): Likewise.

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

--- gcc/loop-unswitch.c.mp  2013-01-10 16:50:28.899559875 +0100
+++ gcc/loop-unswitch.c 2013-01-14 15:44:30.574158810 +0100
@@ -145,12 +144,7 @@ unswitch_loops (void)
   /* Go through inner loops (only original ones).  */
 
   FOR_EACH_LOOP (li, loop, LI_ONLY_INNERMOST)
-{
-  unswitch_single_loop (loop, NULL_RTX, 0);
-#ifdef ENABLE_CHECKING
-  verify_loop_structure ();
-#endif
-}
+unswitch_single_loop (loop, NULL_RTX, 0);
 
   iv_analysis_done ();
 }
@@ -370,6 +364,10 @@ unswitch_single_loop (struct loop *loop,
   nloop = unswitch_loop (loop, bbs[i], copy_rtx_if_shared (cond), cinsn);
   gcc_assert (nloop);
 
+#ifdef ENABLE_CHECKING
+  verify_loop_structure ();
+#endif
+
   /* Invoke itself on modified loops.  */
   unswitch_single_loop (nloop, rconds, num + 1);
   unswitch_single_loop (loop, conds, num + 1);
--- gcc/cfgloopmanip.c.mp   2013-01-14 14:42:52.502002650 +0100
+++ gcc/cfgloopmanip.c  2013-01-14 16:48:40.693799547 +0100
@@ -111,10 +111,13 @@ fix_bb_placement (basic_block bb)
 /* Fix placement of LOOP inside loop tree, i.e. find the innermost superloop
of LOOP to that leads at least one exit edge of LOOP, and set it
as the immediate superloop of LOOP.  Return true if the immediate superloop
-   of LOOP changed.  */
+   of LOOP changed.
+
+   IRRED_INVALIDATED is set to true if a change in the loop structures might
+   invalidate the information about irreducible regions.  */
 
 static bool
-fix_loop_placement (struct loop *loop)
+fix_loop_placement (struct loop *loop, bool *irred_invalidated)
 {
   unsigned i;
   edge e;
@@ -136,6 +139,9 @@ fix_loop_placement (struct loop *loop)
   flow_loop_tree_node_remove (loop);
   flow_loop_tree_node_add (father, loop);
 
+  /* We may need to recompute irreducible loops.  */
+  *irred_invalidated = true;
+
   /* The exit edges of LOOP no longer exits its original immediate
 superloops; remove them from the appropriate exit lists.  */
   FOR_EACH_VEC_ELT (exits, i, e)
@@ -212,7 +218,7 @@ fix_bb_placements (basic_block from,
   if (from->loop_father->header == from)
{
  /* Subloop header, maybe move the loop upward.  */
- if (!fix_loop_placement (from->loop_father))
+ if (!fix_loop_placement (from->loop_father, irred_invalidated))
continue;
  target_loop = loop_outer (from->loop_father);
}
@@ -965,7 +971,7 @@ fix_loop_placements (struct loop *loop,
   while (loop_outer (loop))
 {
   outer = loop_outer (loop);
-  if (!fix_loop_placement (loop))
+  if (!fix_loop_placement (loop, irred_invalidated))
break;
 
   /* Changing the placement of a loop in the loop tree may alter the
--- gcc/testsuite/gcc.dg/pr55833.c.mp   2013-01-10 17:23:26.016102692 +0100
+++ gcc/testsuite/gcc.dg/pr55833.c  2013-01-10 17:23:15.898073384 +0100
@@ -0,0 +1,28 @@
+/* PR rtl-optimization/55833 */
+/* { dg-do compile } */
+/* { dg-options "-O3" } */
+
+int a, b, c;
+
+void foo()
+{
+unsigned d, l, *p, k = 1;
+
+if(bar())
+{
+label:
+   if((a = a <= 0))
+{
+if(c)
+d = b;
+
+if (b || d ? l : k ? : 0)
+a = d = 0;
+
+goto label;
+   }
+}
+
+while(*p++)
+ 

Re: Mention of gcc 4.5 as first version with plugin support

2013-01-14 Thread Dave Johansen
On Mon, Jan 14, 2013 at 12:21 AM, Richard Biener
 wrote:
> On Fri, Jan 11, 2013 at 9:46 PM, Basile Starynkevitch
>  wrote:
>> On Fri, 11 Jan 2013 09:58:49 +0100
>> Dodji Seketeli  wrote:
>>
>>> Thank you Dave for this documentation patch that looks OK to my casual
>>> eyes.  Let's CC the documentation maintainers.
>>>
>>> Dave Johansen  a écrit:
>>>
>>> >
>>> > +GCC plugin support is available in GCC version 4.5.0 and
>>> > +later.
>>
>> Maybe we should say that a later version is preferable.
>> IIRC 4.5 plugin support was not very good -it was more an experimental stage 
>> than
>> anything else. I believe that we should not encourage people to write 
>> plugins against
>> 4.5.
>
> What's the value of documenting the availability of an unstable API in
> older versions
> of GCC?  Mind this documentation is version specific.
>
> Richard.
>
>> Cheers.
>>
>> --
>> Basile STARYNKEVITCH http://starynkevitch.net/Basile/
>> email: basilestarynkevitchnet mobile: +33 6 8501 2359
>> 8, rue de la Faiencerie, 92340 Bourg La Reine, France
>> *** opinions {are only mine, sont seulement les miennes} ***

My point wasn't to encourage people to use 4.5 for plugins, but just
to state when it became available. I was looking into
enabling/installing plugin support on RHEL 5/6 and spent several hours
trying to figure out why it wasn't available only to later find out
that it wasn't available in gcc 4.4. If the documentation had at least
mentioned the version when this feature was introduced, then it would
have saved me a lot of headache and is why I submitted this patch.


Re: ping Re: [patch] multiarch backports for the 4.7 and 4.6 branches

2013-01-14 Thread Jakub Jelinek
On Mon, Jan 14, 2013 at 05:09:36PM +0100, Matthias Klose wrote:
> ping on the backports, attaching two new versions which do include the
> powerpcspe and kfreebsd fixes from 2012-12-19/20.

Ok, but please watch for fallouts.

> 2012-11-20  Matthias Klose  
> 
>   * doc/invoke.texi: Document -print-multiarch.
>   * doc/install.texi: Document --enable-multiarch.
>   * doc/fragments.texi: Document MULTILIB_OSDIRNAMES, MULTIARCH_DIRNAME.
>   * configure.ac: Add --enable-multiarch option.
>   Substitute with_cpu, with_float.
>   * configure: Regenerate.
>   * Makefile.in (s-mlib): Pass MULTIARCH_DIRNAME to genmultilib.
>   enable_multiarch, with_cpu, with_float: New macros.
>   if_multiarch: New macro, define in terms of enable_multiarch.
>   * genmultilib: Add new argument for the multiarch name.
>   * gcc.c (multiarch_dir): Define.
>   (for_each_path): Search for multiarch suffixes.
>   (driver_handle_option): Handle multiarch option.
>   (do_spec_1): Pass -imultiarch if defined.
>   (main): Print multiarch.
>   (set_multilib_dir): Separate multilib and multiarch names
>   from multilib_select.
>   (print_multilib_info): Ignore multiarch names in multilib_select.
>   * incpath.c (add_standard_paths): Search the multiarch include dirs.
>   * cppdefault.h (default_include): Document multiarch in multilib
>   member.
>   * cppdefault.c: [LOCAL_INCLUDE_DIR, STANDARD_INCLUDE_DIR] Add an
> include directory for multiarch directories.

Wrong whitespace at the start of the above line?

Jakub


Re: [PATCH] Allow new ISL/CLooG versions

2013-01-14 Thread Jack Howarth
On Mon, Jan 14, 2013 at 11:03:41AM -0500, Jack Howarth wrote:
> On Mon, Jan 14, 2013 at 04:44:04PM +0100, Tobias Grosser wrote:
> > On 01/14/2013 03:29 PM, Richard Biener wrote:
> >>
> >> This makes us accept the CLooG 0.18.0 and ISL 0.11.1 combo.
> >>
> >> It's probably not the best stage to move the version checks to
> >> gcc/ where we can rely on built in-tree ISL/CLooG, so this avoids
> >> it with the caveat that in-tree CLooG 0.18.0 will fail the
> >> version check (they no longer ship built version.h but only
> >> version.h.in).
> >>
> >> I verified all GRAPHITE tests pass with 0.18.0/0.11.1.
> >>
> >> Ok for trunk?

Richard,
   Did you see my patch proposal in the gcc mailing list  before you crafted 
your patch?

http://gcc.gnu.org/ml/gcc/2012-12/msg00195.html

Jack

> >>
> >> Or do people prefer to move CLooG/ISL checks to gcc/ configure
> >> time to fix the in-tree use of 0.18.0 and also do version checks
> >> of in-tree ISL at all (they don't have a version.h).
> >
> > Hi Richi,
> >
> > I think this is a good thing. But this probably requires some config  
> > guys to approve it.
> >
> > All the best,
> > Tobi
> 
> Tnis change has already been committed at...
> 
> r195150 | rguenth | 2013-01-14 10:01:13 -0500 (Mon, 14 Jan 2013) | 5 lines
> 
> 2013-01-14  Richard Biener  
> 
> * configure.ac (cloog/isl): Also allow ISL 0.11.x and CLooG 0.18.0.
> * configure: Re-generate
> 
> 
> This change is broken in several ways. The current commit doesn't handle
> isl 0.11.1 because it omits teaching config/isl.m4 how to handle revsions
> with...
> 
> Index: config/isl.m4
> ===
> --- config/isl.m4 (revision 194744)
> +++ config/isl.m4 (working copy)
> @@ -89,13 +89,13 @@ AC_DEFUN([ISL_REQUESTED],
>  ]
>  )
>  
> -# _ISL_CHECK_CT_PROG(MAJOR, MINOR)
> +# _ISL_CHECK_CT_PROG(MAJOR, MINOR, REVISION)
>  # 
>  # Helper for verifying ISL compile time version.
>  m4_define([_ISL_CHECK_CT_PROG],[AC_LANG_PROGRAM(
>[#include 
> #include ],
> -  [if (strncmp (isl_version (), "isl-$1.$2", strlen ("isl-$1.$2")) != 0)
> +  [if (strncmp (isl_version (), "isl-$1.$2.$3", strlen ("isl-$1.$2.$3")) != 
> 0)
>   return 1;
> ])])
>  
> @@ -115,9 +115,9 @@ AC_DEFUN([ISL_CHECK_VERSION],
>  LIBS="${_isl_saved_LIBS} -lisl"
>  echo $CFLAGS
>  
> -AC_CACHE_CHECK([for version $1.$2 of ISL],
> +AC_CACHE_CHECK([for version $1.$2.$3 of ISL],
>[gcc_cv_isl],
> -  [AC_RUN_IFELSE([_ISL_CHECK_CT_PROG($1,$2)],
> +  [AC_RUN_IFELSE([_ISL_CHECK_CT_PROG($1,$2,$3)],
>   [gcc_cv_isl=yes],
>   [gcc_cv_isl=no],
>   [gcc_cv_isl=yes])])
> 
> like config/cloog.m4 does. Also the current commit leaves the legacy...
> 
>ISL_CHECK_VERSION(0,10)
> +  if test "${gcc_cv_isl}" = no ; then
> +ISL_CHECK_VERSION(0,11)
> +  fi
> 
> test on isl 0.10 present insuring that it will fail for any out of tree
> isl version.
>  Jack
> 
> 


Re: [PATCH 2/2] Support __ATOMIC_HLE_RELEASE for __atomic_clear/store_n

2013-01-14 Thread Uros Bizjak
On Sun, Jan 13, 2013 at 11:29 PM, Andi Kleen  wrote:
> On Sun, Jan 13, 2013 at 11:23:24PM +0100, Uros Bizjak wrote:
>> On Sun, Jan 13, 2013 at 11:12 PM, Andi Kleen  wrote:
>> >> >> +(define_insn "atomic_store_1"
>> >> >> +  [(set (match_operand:ATOMIC 0 "memory_operand" "=m")
>> >> >> + (unspec:ATOMIC [(match_operand:ATOMIC 1 "" 
>> >> >> "")
>> >> >> + (match_operand:SI 2 "const_int_operand")]
>> >> >> +UNSPEC_MOVA))]
>> >> >> +  ""
>> >> >> +  "%K2mov{}\t{%1, %0|%0, %1}")
>> >> >
>> >> > Is that the updated pattern you wanted? It looks similar to mine.
>> >>
>> >> Yes the attached patch actually implements all proposed fixes.
>> >
>> > Ok great. Can you just commit it then? It looks good to me.
>>
>> No problem, but what about this part:
>
> Right now it just means its silently ignored, no wrong code generated.
> If people are ok with a new target hook I can add one.
> There are some more bugs in this area, like PR55947
>
> Giving a warning is imho less important than supporting this at all.
> So I would prefer to not delay this patch.
>
>>
>> diff --git a/gcc/builtins.c b/gcc/builtins.c
>> index 2b615a1..c283869 100644
>> --- a/gcc/builtins.c
>> +++ b/gcc/builtins.c
>> @@ -5556,6 +5556,8 @@ expand_builtin_atomic_clear (tree exp)
>>return const0_rtx;
>>  }
>>
>> +  /* need target hook there to check for not hle acquire */
>> +
>>if (HAVE_atomic_clear)
>>  {
>>emit_insn (gen_atomic_clear (mem, model));
>>
>> Middle-end support should be implemented before target support is
>> committed. So, please figure out how to emit correct error on
>> unsupported models and get middle-end patch reviewed first. We do get
>> "Error: instruction `mov' after `xacquire' not allowed" assembler
>> error with "xacquire movb $0,mem" asm, though.
>
> The sync.md code is only called for the acquire bit.
>
> The only case where it may happen I guess if someone sets both.

This cannot happen, we reject code that sets both __HLE* flags.

2012-01-14  Uros Bizjak  
Andi Kleen  

PR target/55948
* config/i386/sync.md (atomic_store_1): New pattern.
(atomic_store): Call atomic_store_1 for IX86_HLE_RELEASE
memmodel flag.

testsuite/ChangeLog

2012-01-14  Andi Kleen  

PR target/55948
* gcc.target/i386/hle-clear-rel.c: New file
* gcc.target/i386/hle-store-rel.c: New file.

I have committed attached patch to mainline SVN, after re-tested it on
x86_64-pc-linux-gnu.

Uros.
Index: config/i386/sync.md
===
--- config/i386/sync.md (revision 195152)
+++ config/i386/sync.md (working copy)
@@ -224,8 +224,12 @@
  DONE;
}
 
-  /* Otherwise use a normal store.  */
-  emit_move_insn (operands[0], operands[1]);
+  /* Otherwise use a store.  */
+  if (INTVAL (operands[2]) & IX86_HLE_RELEASE)
+   emit_insn (gen_atomic_store_1 (operands[0], operands[1],
+operands[2]));
+  else
+   emit_move_insn (operands[0], operands[1]);
 }
   /* ... followed by an MFENCE, if required.  */
   if (model == MEMMODEL_SEQ_CST)
@@ -233,6 +237,14 @@
   DONE;
 })
 
+(define_insn "atomic_store_1"
+  [(set (match_operand:ATOMIC 0 "memory_operand" "=m")
+   (unspec:ATOMIC [(match_operand:ATOMIC 1 "" "")
+   (match_operand:SI 2 "const_int_operand")]
+  UNSPEC_MOVA))]
+  ""
+  "%K2mov{}\t{%1, %0|%0, %1}")
+
 (define_insn_and_split "atomic_storedi_fpu"
   [(set (match_operand:DI 0 "memory_operand" "=m,m,m")
(unspec:DI [(match_operand:DI 1 "register_operand" "x,m,?r")]
Index: testsuite/gcc.target/i386/hle-clear-rel.c
===
--- testsuite/gcc.target/i386/hle-clear-rel.c   (revision 0)
+++ testsuite/gcc.target/i386/hle-clear-rel.c   (working copy)
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-options "-mhle" } */
+/* { dg-final { scan-assembler "\[ \n\t\]+\(xrelease\|\.byte\[ \t\]+0xf3\)\[ 
\t\n\]+mov" } } */
+
+void
+hle_clear (char *p, int v)
+{
+  __atomic_clear (p, __ATOMIC_RELEASE | __ATOMIC_HLE_RELEASE);
+}
Index: testsuite/gcc.target/i386/hle-store-rel.c
===
--- testsuite/gcc.target/i386/hle-store-rel.c   (revision 0)
+++ testsuite/gcc.target/i386/hle-store-rel.c   (working copy)
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-options "-mhle" } */
+/* { dg-final { scan-assembler "\[ \n\t\]+\(xrelease\|\.byte\[ \t\]+0xf3\)\[ 
\t\n\]+mov" } } */
+
+void
+hle_store (int *p, int v)
+{
+  __atomic_store_n (p, v, __ATOMIC_RELEASE | __ATOMIC_HLE_RELEASE);
+}


Re: [PATCH] Let target get_memmodel know about stores/barriers

2013-01-14 Thread Uros Bizjak
On Mon, Jan 14, 2013 at 4:38 PM, Andi Kleen  wrote:

> For HLE stores are only valid with __ATOMIC_HLE_RELEASE. The middle end
> didn't know this. This adds a new parameter to the get_memmodel target
> hook to distingush stores and give an warning for acquire stores.
>
> I also did a similar check for the barriers where HLE is not useful
> at all.
>
> Fixes one todo in the earlier hle release patch.
>
> gcc/:
> 2013-01-13  Andi Kleen  
>
> PR target/55948
> * builtins.c (get_memmodel): Pass store, barrier parameters to target
> hook.
> (expand_builtin_atomic_exchange,
>  expand_builtin_atomic_compare_exchange,
>  expand_builtin_atomic_load,
>  expand_builtin_atomic_store,
>  expand_builtin_atomic_fetch_op,
>  expand_builtin_atomic_test_and_set,
>  expand_builtin_atomic_test_lock,
>  expand_builtin_atomic_clear,
>  expand_builtin_atomic_thread_fence): Pass store, barrier
> parameters to get_memmodel.
> * config/i386/i386.c (ix86_memmodel_check): Add store, barrier 
> warning.
> * doc/tm.texi (TARGET_GET_MEMMODEL): Add store, barrier parameters.
> * doc/tm.exit.in (TARGET_GET_MEMMODEL): Dito.
> * target.def (TARGET_GET_MEMMODEL): Dito.
> ---
>  gcc/builtins.c |   30 +++---
>  gcc/config/i386/i386.c |   21 +++--
>  gcc/doc/tm.texi|6 --
>  gcc/doc/tm.texi.in |4 +++-
>  gcc/target.def |3 ++-
>  5 files changed, 43 insertions(+), 21 deletions(-)
>

> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 4f778c1..50b6297 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -42076,14 +42076,31 @@ ix86_destroy_cost_data (void *data)
>free (data);
>  }
>
> -/* Validate target specific memory model bits in VAL. */
> +/* Validate target specific memory model bits in VAL. When
> +   STORE is true this for a store.  When BARRIER is true
> +   this is for a barrier. */
>
>  static unsigned HOST_WIDE_INT
> -ix86_memmodel_check (unsigned HOST_WIDE_INT val)
> +ix86_memmodel_check (unsigned HOST_WIDE_INT val, bool store,
> +bool barrier)
>  {
>unsigned HOST_WIDE_INT model = val & MEMMODEL_MASK;
>bool strong;
>
> +  if (barrier && (val & (IX86_HLE_ACQUIRE|IX86_HLE_RELEASE)))
> +{
> +  warning (OPT_Winvalid_memory_model,
> +  "__ATOMIC_HLE_ACQUIRE or __ATOMIC_HLE_RELEASE not valid for 
> barriers.");

No dot at the end of warning sentence.

> +  return MEMMODEL_SEQ_CST;
> +}
> +
> +  if (store && (val & IX86_HLE_ACQUIRE))
> +{
> +  warning (OPT_Winvalid_memory_model,
> +  "__ATOMIC_HLE_ACQUIRE not valid for stores.");

Also here.

The target part is OK, the rest needs a review from a middle-end reviewer.

Thanks,
Uros.


Re: [Patch, AArch64-4.7] Implement support for LD1R.

2013-01-14 Thread Marcus Shawcroft

On 09/01/13 16:36, Tejas Belagod wrote:


Hi,

Attached is a patch that implements support for AdvSIMD instruction LD1R.

Tested on aarch64-none-elf. OK to commit on aarch64-4.7-branch?

Thanks,
Tejas Belagod
ARM.

2013-01-09  Tejas Belagod  

gcc/
* config/aarch64/aarch64-simd.md (*aarch64_simd_ld1r): New.
* config/aarch64/iterators.md (VALLDI): New.

testsuite/
* gcc.target/aarch64/aarch64/vect-ld1r-compile-fp.c: New.
* gcc.target/aarch64/vect-ld1r-compile.c: New.
* gcc.target/aarch64/vect-ld1r-fp.c: New.
* gcc.target/aarch64/vect-ld1r.c: New.
* gcc.target/aarch64/vect-ld1r.x: New.



OK



Re: [Patch, AArch64] Implement support for LD1R.

2013-01-14 Thread Marcus Shawcroft

On 09/01/13 16:41, Tejas Belagod wrote:

Hi,

Attached is a patch that implements support for AdvSIMD instruction LD1R.

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

Thanks,
Tejas Belagod
ARM.

2013-01-09  Tejas Belagod  

gcc/
* config/aarch64/aarch64-simd.md (*aarch64_simd_ld1r): New.
* config/aarch64/iterators.md (VALLDI): New.

testsuite/
* gcc.target/aarch64/aarch64/vect-ld1r-compile-fp.c: New.
* gcc.target/aarch64/vect-ld1r-compile.c: New.
* gcc.target/aarch64/vect-ld1r-fp.c: New.
* gcc.target/aarch64/vect-ld1r.c: New.
* gcc.target/aarch64/vect-ld1r.x: New.



OK
/Marcus



Re: RFA: Update copyright for libatomic

2013-01-14 Thread Richard Henderson

On 01/13/2013 12:25 AM, Richard Sandiford wrote:

Here's the result of running the copyright script on libatomic/.
Tested on x86_64-linux-gnu.  OK to install?

Richard


libatomic/
Update copyright years


Ok.


r~


[patch,avr]:

2013-01-14 Thread Georg-Johann Lay
This patch is a no-op change that uses typedefs starting with avr_ in order to
make clear that they are in the avr "namespace".  Old types were: struct
base_arch_s, struct arch_info_s, struct mcu_type_s.

avr-cross builds fine.

Ok to apply?


* config/avr/avr-arch.h
(struct base_arch_s): Use typedef avr_arch_t instead.
(struct arch_info_s): Use typedef avr_arch_info_t instead.
(struct mcu_type_s): Use typedef avr_mcu_t instead.
* config/avr/avr.c: Same.
* config/avr/avr-devices.c: Same.
* config/avr/driver-avr.c: Same.
* config/avr/gen-avr-mmcu-texi.c: Same.
* config/avr/avr-mcus.def: Adjust comment.
Index: config/avr/gen-avr-mmcu-texi.c
===
--- config/avr/gen-avr-mmcu-texi.c	(revision 195150)
+++ config/avr/gen-avr-mmcu-texi.c	(working copy)
@@ -85,7 +85,7 @@ int main (void)
 {
   enum avr_arch arch = ARCH_UNKNOWN;
   size_t i, n_mcus = 0;
-  const struct mcu_type_s *mcu;
+  const avr_mcu_t *mcu;
 
   printf ("@c Copyright (C) 2012-2013 Free Software Foundation, Inc.\n");
   printf ("@c This is part of the GCC manual.\n");
Index: config/avr/avr-arch.h
===
--- config/avr/avr-arch.h	(revision 195151)
+++ config/avr/avr-arch.h	(working copy)
@@ -45,7 +45,7 @@ enum avr_arch
 
 /* Architecture-specific properties.  */
 
-struct base_arch_s
+typedef struct
 {
   /* Assembler only.  */
   int asm_only;
@@ -87,12 +87,12 @@ struct base_arch_s
 
   /* Architecture name.  */
   const char *const arch_name;
-};
+} avr_arch_t;
 
 
 /* Device-specific properties.  */
 
-struct mcu_type_s
+typedef struct
 {
   /* Device name.  */
   const char *const name;
@@ -134,22 +134,23 @@ struct mcu_type_s
 
   /* Name of device library.  */
   const char *const library_name;
-};
+} avr_mcu_t;
 
 /* Map architecture to its texinfo string.  */
 
-struct arch_info_s
+typedef struct
 {
   /* Architecture ID.  */
   enum avr_arch arch;
 
   /* textinfo source to describe the archtiecture.  */
   const char *texinfo;
-};
+} avr_arch_info_t;
 
 /* Preprocessor macros to define depending on MCU type.  */
 
-extern const struct base_arch_s *avr_current_arch;
-extern const struct mcu_type_s *avr_current_device;
-extern const struct mcu_type_s avr_mcu_types[];
-extern const struct base_arch_s avr_arch_types[];
+extern const avr_arch_t avr_arch_types[];
+extern const avr_arch_t *avr_current_arch;
+
+extern const avr_mcu_t avr_mcu_types[];
+extern const avr_mcu_t *avr_current_device;
Index: config/avr/avr-devices.c
===
--- config/avr/avr-devices.c	(revision 195151)
+++ config/avr/avr-devices.c	(working copy)
@@ -27,7 +27,7 @@
 /* List of all known AVR MCU architectures.
Order as of enum avr_arch from avr.h.  */
 
-const struct base_arch_s
+const avr_arch_t
 avr_arch_types[] =
 {
   /* unknown device specified */
@@ -56,7 +56,7 @@ avr_arch_types[] =
   { 0, 1, 1, 1, 1, 1, 1, 1, 1, 0x2000,  0, "107", "avrxmega7" }
 };
 
-const struct arch_info_s
+const avr_arch_info_t
 avr_texinfo[] =
 {
   { ARCH_AVR1,
@@ -101,9 +101,11 @@ avr_texinfo[] =
 "and more than 64@tie{}KiB of RAM." }
 };
 
-const struct mcu_type_s avr_mcu_types[] = {
-#define AVR_MCU(NAME,ARCH,MACRO,SHORT_SP,ERRATA_SKIP,DATA_SEC,N_FLASH,LIB_NAME)\
-  { NAME, ARCH, MACRO, SHORT_SP, ERRATA_SKIP, DATA_SEC, N_FLASH, LIB_NAME },
+const avr_mcu_t
+avr_mcu_types[] =
+{
+#define AVR_MCU(NAME, ARCH, MACRO, SP8, ERR_SKIP, DATA_SEC, N_FLASH, LIBNAME)\
+  { NAME, ARCH, MACRO, SP8, ERR_SKIP, DATA_SEC, N_FLASH, LIBNAME },
 #include "avr-mcus.def"
 #undef AVR_MCU
 /* End of list.  */
Index: config/avr/avr-mcus.def
===
--- config/avr/avr-mcus.def	(revision 195150)
+++ config/avr/avr-mcus.def	(working copy)
@@ -39,7 +39,7 @@
AVR_MCU (NAME, ARCH, MACRO, SHORT_SP, ERRATA_SKIP, DATA_SEC, N_FLASH,
 LIBRARY_NAME)
 
-   where the arguments are the fields of struct mcu_type_s:
+   where the arguments are the fields of avr_mcu_t:

NAME Accept -mmcu=
 
Index: config/avr/driver-avr.c
===
--- config/avr/driver-avr.c	(revision 195150)
+++ config/avr/driver-avr.c	(working copy)
@@ -24,10 +24,10 @@ along with GCC; see the file COPYING3.
 #include "tm.h"
 
 /* Current architecture.  */
-const struct base_arch_s *avr_current_arch = NULL;
+const avr_arch_t *avr_current_arch = NULL;
 
 /* Current device.  */
-const struct mcu_type_s *avr_current_device = NULL;
+const avr_mcu_t *avr_current_device = NULL;
 
 /* Initialize avr_current_arch and avr_current_device variables.  */
 
Index: config/avr/avr.c
===
--- config/avr/avr.c	(revision 195151)
+++ config/avr/avr.c	(working copy)
@@ -184,10 +184,10 @@ static GTY(()) rtx xstr

RE: [PATCH][ARM][1/3] Add vectorization support for rounding functions

2013-01-14 Thread Kyrylo Tkachov
Ping.

Thanks,
Kyrill

> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Kyrylo Tkachov
> Sent: 07 January 2013 10:35
> To: gcc-patches@gcc.gnu.org
> Cc: Ramana Radhakrishnan; Richard Earnshaw
> Subject: RE: [PATCH][ARM][1/3] Add vectorization support for rounding
> functions
> 
> Ping.
> 
> http://gcc.gnu.org/ml/gcc-patches/2012-12/msg0.html
> 
> Thanks,
> Kyrill
> 
> > -Original Message-
> > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> > ow...@gcc.gnu.org] On Behalf Of Kyrylo Tkachov
> > Sent: 18 December 2012 13:33
> > To: gcc-patches@gcc.gnu.org
> > Cc: Ramana Radhakrishnan; Richard Earnshaw
> > Subject: [PATCH][ARM][1/3] Add vectorization support for rounding
> > functions
> >
> > Hi all,
> >
> > This patch does some refactoring by moving the definitions of the
> NEON
> > builtins to a separate file (arm_neon_builtins.def) and includes that
> > when
> > initialising the neon_builtin_data array and also during
> > the definition of enum arm_builtins (with appropriate redefinitions
> of
> > the
> > VAR* macros). This allows us to have symbolic names for the neon
> > builtins
> > that allows us to look up their declaration in
> > arm_builtin_decls. This is needed for vectorisation support in the
> next
> > patch. The ARM_BUILTIN_NEON_BASE constant which was defined as part
> of
> > the
> > arm_builtins enum is now defined as a macro, since
> > various functions that deal with the initialisation and expansion of
> > builtins use it.
> >
> > No regressions on arm-none-eabi with model.
> >
> > Ok for trunk?
> >
> > Thanks,
> > Kyrill
> >
> >
> > gcc/ChangeLog
> >
> > 2012-12-18  Kyrylo Tkachov  
> >
> > * config/arm/arm_neon_builtins.def: New file.
> > * config/arm/arm.c (neon_builtin_data): Move contents to
> >   arm_neon_builtins.def.
> >   (enum arm_builtins): Include neon builtin definitions.
> >   (ARM_BUILTIN_NEON_BASE): Move from enum to macro.
> 
> 
> 






RE: [PATCH][ARM][2/3] Add vectorization support for rounding functions

2013-01-14 Thread Kyrylo Tkachov
Ping.

Thanks,
Kyrill

> -Original Message-
> From: Kyrylo Tkachov
> Sent: 07 January 2013 10:35
> To: Kyrylo Tkachov; gcc-patches@gcc.gnu.org
> Cc: Ramana Radhakrishnan; Richard Earnshaw
> Subject: RE: [PATCH][ARM][2/3] Add vectorization support for rounding
> functions
> 
> Ping.
> 
> http://gcc.gnu.org/ml/gcc-patches/2012-12/msg01113.html
> 
> Thanks,
> Kyrill
> 
> > -Original Message-
> > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> > ow...@gcc.gnu.org] On Behalf Of Kyrylo Tkachov
> > Sent: 18 December 2012 13:34
> > To: gcc-patches@gcc.gnu.org
> > Cc: Ramana Radhakrishnan; Richard Earnshaw
> > Subject: [PATCH][ARM][2/3] Add vectorization support for rounding
> > functions
> >
> > Hi all,
> >
> > This patch adds support for the vectorisation of the rounding
> > functions:
> > floorf, ceilf, truncf, roundf. These can be implemented using the
> ARMv8
> > NEON
> > instructions: vrintm, vrintp, vrintz, vrinta.
> > This is done by defining the TARGET_VECTORIZE_BUILTINS and
> > TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION macros and the function
> > arm_builtin_vectorized_function that returns the decl of the vector
> > form
> > of a builtin function, or NULL_TREE if no vector variant exists.
> >
> > No regressions on arm-none-eabi with AEM.
> >
> > Ok for trunk?
> >
> > gcc/ChangeLog
> >
> > 2012-12-18  Kyrylo Tkachov  
> >
> > * config/arm/arm-protos.h (arm_builtin_vectorized_function):
> >   New function prototype.
> > * config/arm/arm.c (TARGET_VECTORIZE_BUILTINS): Define.
> >   (TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION): Likewise.
> >   (arm_builtin_vectorized_function): New function.
> 






RE: [patch,avr]:

2013-01-14 Thread Weddington, Eric
> -Original Message-
> From: Georg-Johann Lay
> Sent: Monday, January 14, 2013 10:31 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Denis Chertykov; Weddington, Eric
> Subject: [patch,avr]:
> 
> This patch is a no-op change that uses typedefs starting with avr_ in
> order to
> make clear that they are in the avr "namespace".  Old types were:
> struct
> base_arch_s, struct arch_info_s, struct mcu_type_s.
> 
> avr-cross builds fine.
> 
> Ok to apply?

Please commit! Thanks!

Eric


Re: [PATCH] Fix PR55833 + cheaper checking

2013-01-14 Thread Zdenek Dvorak
Hi,

> On Thu, Jan 10, 2013 at 11:19:43PM +0100, Zdenek Dvorak wrote:
> > I agree -- at the very least, unswitch_single_loop should check whether 
> > there
> > is any possiblity it could have affected irreducible loops information (this
> > should only be the case when some already existing irreducible loop is 
> > altered
> > in the progress).  Which is what it (or more precisely, remove_path function
> > used by it) tries to do -- so is should be sufficient to check why this 
> > fails
> > for the considered testcase, and make sure the situation is correctly 
> > detected,
> 
> Actually, in this case, we don't call remove_path from unswitch_single_loop
> at all.

I am not quite sure what you mean by that -- remove_path is called 
unconditionally
in unswitch_loop (and fix_loop_placement is only called through remove_path).

> So, here's another stab at it.  In this version, we will call
> mark_irreducible_loops only in case where we're removing a loop
> from loop hierarchy tree.  Because when we do that (and we're in some
> irreducible region), the edge that connects those two loops
> should be marked as EDGE_IRREDUCIBLE_LOOP.  And the preheader BB
> eventually as BB_IRREDUCIBLE_LOOP.  Does this look any better?
> I'm not actually checking whether we really are in a irreducible
> region, should that be done (how?)?

Yes, you should check whether you are in an irreducible loop.  This is done by
testing EDGE_IRREDUCIBLE_LOOP flag,

Zdenek


[patch,avr]: Minor fixes to some built-in macros

2013-01-14 Thread Georg-Johann Lay
This patch does:

1) With 8-bit int, __INT24_MAX__ and __UINT24_MAX__ need a long long suffix.

2) Defines like __FLASH that indicate if address space is available should
   be like a predicate, i.e. 1 if the space is available.

Obvious and lightly tested.

Ok?

Johann


* config/avr/avr-c.c (avr_cpu_cpp_builtins): Define __FLASH
etc. to 1 and not to __flash.
Use LL suffix for __INT24_MAX__ with -mint8.
Use ULL suffix for __UINT24_MAX__ with -mint8.
Index: config/avr/avr-c.c
===
--- config/avr/avr-c.c	(revision 195151)
+++ config/avr/avr-c.c	(working copy)
@@ -169,8 +169,7 @@ avr_cpu_cpp_builtins (struct cpp_reader
 const char *name = avr_addrspace[i].name;
 char *Name = (char*) alloca (1 + strlen (name));
 
-cpp_define_formatted (pfile, "%s=%s",
-  avr_toupper (Name, name), name);
+cpp_define (pfile, avr_toupper (Name, name));
   }
 }
 
@@ -187,7 +186,9 @@ avr_cpu_cpp_builtins (struct cpp_reader
 
   /* Builtin macros for the __int24 and __uint24 type.  */
 
-  cpp_define (pfile, "__INT24_MAX__=8388607L");
+  cpp_define_formatted (pfile, "__INT24_MAX__=8388607%s",
+INT_TYPE_SIZE == 8 ? "LL" : "L");
   cpp_define (pfile, "__INT24_MIN__=(-__INT24_MAX__-1)");
-  cpp_define (pfile, "__UINT24_MAX__=16777215UL");
+  cpp_define_formatted (pfile, "__UINT24_MAX__=16777215%s",
+INT_TYPE_SIZE == 8 ? "ULL" : "UL");
 }


[Patch, AArch64, AArch64-4.7] Fix sqdmulh_lane_* intrinsics.

2013-01-14 Thread Tejas Belagod


Hi,

Attached is a patch that fixes sqdmulh_lane_* intrinsics. Previously they,
used to accept 128-bit lane index range. This fixes this bug to accept 64-bit 
lane index range. sqdmulh_laneq_* and AdvSIMD scalar ones still accept 
128-bit lane index range as before.


It has passed regressions on aarch64-none-elf. OK for trunk and 
aarch64-4.7-branch?

Thanks,
Tejas Belagod
ARM.

Changelog

2013-01-14  Tejas Belagod  

gcc/
* config/aarch64/aarch64-simd-builtins.def: Separate sqdmulh_lane
entries into lane and laneq entries.
* config/aarch64/aarch64-simd.md (aarch64_sqdmulh_lane): Remove
AdvSIMD scalar modes.
(aarch64_sqdmulh_laneq): New.
(aarch64_sqdmulh_lane): New RTL pattern for Scalar AdvSIMD
modes.
* config/aarch64/arm_neon.h: Fix all the vqdmulh_lane* intrinsics'
builtin implementations to relfect changes in RTL in aarch64-simd.md.
* config/aarch64/iterators.md (VCOND): New.
(VCONQ): New.diff --git a/gcc/config/aarch64/aarch64-simd-builtins.def 
b/gcc/config/aarch64/aarch64-simd-builtins.def
index d441417..af27079 100644
--- a/gcc/config/aarch64/aarch64-simd-builtins.def
+++ b/gcc/config/aarch64/aarch64-simd-builtins.def
@@ -142,9 +142,13 @@
   /* Implemented by aarch64_sqdmulh.  */
   BUILTIN_VSDQ_HSI (BINOP, sqdmulh)
   BUILTIN_VSDQ_HSI (BINOP, sqrdmulh)
-  /* Implemented by aarch64_sqdmulh_lane.  */
-  BUILTIN_VSDQ_HSI (TERNOP, sqdmulh_lane)
-  BUILTIN_VSDQ_HSI (TERNOP, sqrdmulh_lane)
+  /* Implemented by aarch64_sqdmulh_lane.  */
+  BUILTIN_VDQHS (TERNOP, sqdmulh_lane)
+  BUILTIN_VDQHS (TERNOP, sqdmulh_laneq)
+  BUILTIN_VDQHS (TERNOP, sqrdmulh_lane)
+  BUILTIN_VDQHS (TERNOP, sqrdmulh_laneq)
+  BUILTIN_SD_HSI (TERNOP, sqdmulh_lane)
+  BUILTIN_SD_HSI (TERNOP, sqrdmulh_lane)
 
   BUILTIN_VSDQ_I_DI (BINOP, sshl_n)
   BUILTIN_VSDQ_I_DI (BINOP, ushl_n)
diff --git a/gcc/config/aarch64/aarch64-simd.md 
b/gcc/config/aarch64/aarch64-simd.md
index 63716c3..1fc912c 100644
--- a/gcc/config/aarch64/aarch64-simd.md
+++ b/gcc/config/aarch64/aarch64-simd.md
@@ -2068,17 +2068,49 @@
 ;; sqdmulh_lane
 
 (define_insn "aarch64_sqdmulh_lane"
-  [(set (match_operand:VSDQ_HSI 0 "register_operand" "=w")
-(unspec:VSDQ_HSI
- [(match_operand:VSDQ_HSI 1 "register_operand" "w")
+  [(set (match_operand:VDQHS 0 "register_operand" "=w")
+(unspec:VDQHS
+ [(match_operand:VDQHS 1 "register_operand" "w")
+   (vec_select:
+ (match_operand: 2 "register_operand" "")
+ (parallel [(match_operand:SI 3 "immediate_operand" "i")]))]
+VQDMULH))]
+  "TARGET_SIMD"
+  "*
+   aarch64_simd_lane_bounds (operands[3], 0, GET_MODE_NUNITS (mode));
+   return \"sqdmulh\\t%0., %1., %2.[%3]\";"
+  [(set_attr "simd_type" "simd_sat_mul")
+   (set_attr "simd_mode" "")]
+)
+
+(define_insn "aarch64_sqdmulh_laneq"
+  [(set (match_operand:VDQHS 0 "register_operand" "=w")
+(unspec:VDQHS
+ [(match_operand:VDQHS 1 "register_operand" "w")
+   (vec_select:
+ (match_operand: 2 "register_operand" "")
+ (parallel [(match_operand:SI 3 "immediate_operand" "i")]))]
+VQDMULH))]
+  "TARGET_SIMD"
+  "*
+   aarch64_simd_lane_bounds (operands[3], 0, GET_MODE_NUNITS (mode));
+   return \"sqdmulh\\t%0., %1., %2.[%3]\";"
+  [(set_attr "simd_type" "simd_sat_mul")
+   (set_attr "simd_mode" "")]
+)
+
+(define_insn "aarch64_sqdmulh_lane"
+  [(set (match_operand:SD_HSI 0 "register_operand" "=w")
+(unspec:SD_HSI
+ [(match_operand:SD_HSI 1 "register_operand" "w")
(vec_select:
- (match_operand: 2 "register_operand" "")
+ (match_operand: 2 "register_operand" "")
  (parallel [(match_operand:SI 3 "immediate_operand" "i")]))]
 VQDMULH))]
   "TARGET_SIMD"
   "*
-   aarch64_simd_lane_bounds (operands[3], 0, GET_MODE_NUNITS (mode));
-   return \"sqdmulh\\t%0, %1, %2.[%3]\";"
+   aarch64_simd_lane_bounds (operands[3], 0, GET_MODE_NUNITS (mode));
+   return \"sqdmulh\\t%0, %1, %2.[%3]\";"
   [(set_attr "simd_type" "simd_sat_mul")
(set_attr "simd_mode" "")]
 )
diff --git a/gcc/config/aarch64/arm_neon.h b/gcc/config/aarch64/arm_neon.h
index 5a72029..c455cf0 100644
--- a/gcc/config/aarch64/arm_neon.h
+++ b/gcc/config/aarch64/arm_neon.h
@@ -18877,49 +18877,49 @@ vpaddd_s64 (int64x2_t __a)
 __extension__ static __inline int16x4_t __attribute__ ((__always_inline__))
 vqdmulh_laneq_s16 (int16x4_t __a, int16x8_t __b, const int __c)
 {
-  return __builtin_aarch64_sqdmulh_lanev4hi (__a, __b, __c);
+  return __builtin_aarch64_sqdmulh_laneqv4hi (__a, __b, __c);
 }
 
 __extension__ static __inline int32x2_t __attribute__ ((__always_inline__))
 vqdmulh_laneq_s32 (int32x2_t __a, int32x4_t __b, const int __c)
 {
-  return __builtin_aarch64_sqdmulh_lanev2si (__a, __b, __c);
+  return __builtin_aarch64_sqdmulh_laneqv2si (__a, __b, __c);
 }
 
 __extension__ static __inline int16x8_t __attribute__ ((__always_inline__))
 vqdmulhq_

Re: [PATCH 2/2] Support __ATOMIC_HLE_RELEASE for __atomic_clear/store_n

2013-01-14 Thread Andi Kleen
> This cannot happen, we reject code that sets both __HLE* flags.

Good thanks.

BTW I found more HLE bugs, it looks like some of the fetch_op_*
patterns do not match always and fall back to cmpxchg, which
does not generate HLE code correctly. Not fully sure what's 
wrong, can you spot any obvious problems? You changed the

(define_insn "atomic_"

pattern last.

The only one that should really fallback to cmpxchg is nand,
all the others can be generated directly.

This can be seen by commenting in the #if 0 case in the libstdc++
HLE patch test case I sent yesterday. 

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55966

-Andi


RE: [patch,avr]: Minor fixes to some built-in macros

2013-01-14 Thread Weddington, Eric

> -Original Message-
> From: Georg-Johann Lay 
> Sent: Monday, January 14, 2013 10:52 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Denis Chertykov; Weddington, Eric
> Subject: [patch,avr]: Minor fixes to some built-in macros
> 
> This patch does:
> 
> 1) With 8-bit int, __INT24_MAX__ and __UINT24_MAX__ need a long long
> suffix.
> 
> 2) Defines like __FLASH that indicate if address space is available
> should
>be like a predicate, i.e. 1 if the space is available.

I'm not seeing #2 being done in the patch... Am I missing something?

Eric


> Obvious and lightly tested.
> 
> Ok?
> 
> Johann
> 
> 
>   * config/avr/avr-c.c (avr_cpu_cpp_builtins): Define __FLASH
>   etc. to 1 and not to __flash.
>   Use LL suffix for __INT24_MAX__ with -mint8.
>   Use ULL suffix for __UINT24_MAX__ with -mint8.


Re: [patch,avr]: Minor fixes to some built-in macros

2013-01-14 Thread Georg-Johann Lay
Weddington, Eric wrote:
>> 
>> This patch does:
>> 
>> 1) With 8-bit int, __INT24_MAX__ and __UINT24_MAX__ need a long long 
>> suffix.
>> 
>> 2) Defines like __FLASH that indicate if address space is available should
>>  be like a predicate, i.e. 1 if the space is available.
> 
> I'm not seeing #2 being done in the patch... Am I missing something?

The current "#define __FLASH=__flash" is accomplished by the
cpp_define_formatted with "%s=%s".  The new is just a cpp_define for __FLASH,
retrieved by avr_toupper.

Johann



RE: [patch,avr]: Minor fixes to some built-in macros

2013-01-14 Thread Weddington, Eric
> -Original Message-
> From: Georg-Johann Lay 
> Sent: Monday, January 14, 2013 11:15 AM
> To: Weddington, Eric
> Cc: gcc-patches@gcc.gnu.org; Denis Chertykov
> Subject: Re: [patch,avr]: Minor fixes to some built-in macros
> 
> Weddington, Eric wrote:
> >>
> >> This patch does:
> >>
> >> 1) With 8-bit int, __INT24_MAX__ and __UINT24_MAX__ need a long long
> >> suffix.
> >>
> >> 2) Defines like __FLASH that indicate if address space is available
> should
> >>  be like a predicate, i.e. 1 if the space is available.
> >
> > I'm not seeing #2 being done in the patch... Am I missing something?
> 
> The current "#define __FLASH=__flash" is accomplished by the
> cpp_define_formatted with "%s=%s".  The new is just a cpp_define for
> __FLASH,
> retrieved by avr_toupper.

Thanks for the explanation. Please commit.

Eric


Re: [PATCH] Allow new ISL/CLooG versions

2013-01-14 Thread Richard Biener
Jack Howarth  wrote:

>On Mon, Jan 14, 2013 at 11:03:41AM -0500, Jack Howarth wrote:
>> On Mon, Jan 14, 2013 at 04:44:04PM +0100, Tobias Grosser wrote:
>> > On 01/14/2013 03:29 PM, Richard Biener wrote:
>> >>
>> >> This makes us accept the CLooG 0.18.0 and ISL 0.11.1 combo.
>> >>
>> >> It's probably not the best stage to move the version checks to
>> >> gcc/ where we can rely on built in-tree ISL/CLooG, so this avoids
>> >> it with the caveat that in-tree CLooG 0.18.0 will fail the
>> >> version check (they no longer ship built version.h but only
>> >> version.h.in).
>> >>
>> >> I verified all GRAPHITE tests pass with 0.18.0/0.11.1.
>> >>
>> >> Ok for trunk?
>
>Richard,
>Did you see my patch proposal in the gcc mailing list  before you
>crafted your patch?
>
>http://gcc.gnu.org/ml/gcc/2012-12/msg00195.html
>
Yes I did.  The patch is not broken, it restricts compare to major and minor.

Richard.
>Jack
>
>> >>
>> >> Or do people prefer to move CLooG/ISL checks to gcc/ configure
>> >> time to fix the in-tree use of 0.18.0 and also do version checks
>> >> of in-tree ISL at all (they don't have a version.h).
>> >
>> > Hi Richi,
>> >
>> > I think this is a good thing. But this probably requires some
>config  
>> > guys to approve it.
>> >
>> > All the best,
>> > Tobi
>> 
>> Tnis change has already been committed at...
>> 
>> r195150 | rguenth | 2013-01-14 10:01:13 -0500 (Mon, 14 Jan 2013) | 5
>lines
>> 
>> 2013-01-14  Richard Biener  
>> 
>> * configure.ac (cloog/isl): Also allow ISL 0.11.x and CLooG
>0.18.0.
>> * configure: Re-generate
>> 
>> 
>> This change is broken in several ways. The current commit doesn't
>handle
>> isl 0.11.1 because it omits teaching config/isl.m4 how to handle
>revsions
>> with...
>> 
>> Index: config/isl.m4
>> ===
>> --- config/isl.m4(revision 194744)
>> +++ config/isl.m4(working copy)
>> @@ -89,13 +89,13 @@ AC_DEFUN([ISL_REQUESTED],
>>  ]
>>  )
>>  
>> -# _ISL_CHECK_CT_PROG(MAJOR, MINOR)
>> +# _ISL_CHECK_CT_PROG(MAJOR, MINOR, REVISION)
>>  # 
>>  # Helper for verifying ISL compile time version.
>>  m4_define([_ISL_CHECK_CT_PROG],[AC_LANG_PROGRAM(
>>[#include 
>> #include ],
>> -  [if (strncmp (isl_version (), "isl-$1.$2", strlen ("isl-$1.$2"))
>!= 0)
>> +  [if (strncmp (isl_version (), "isl-$1.$2.$3", strlen
>("isl-$1.$2.$3")) != 0)
>>   return 1;
>> ])])
>>  
>> @@ -115,9 +115,9 @@ AC_DEFUN([ISL_CHECK_VERSION],
>>  LIBS="${_isl_saved_LIBS} -lisl"
>>  echo $CFLAGS
>>  
>> -AC_CACHE_CHECK([for version $1.$2 of ISL],
>> +AC_CACHE_CHECK([for version $1.$2.$3 of ISL],
>>[gcc_cv_isl],
>> -  [AC_RUN_IFELSE([_ISL_CHECK_CT_PROG($1,$2)],
>> +  [AC_RUN_IFELSE([_ISL_CHECK_CT_PROG($1,$2,$3)],
>>  [gcc_cv_isl=yes],
>>  [gcc_cv_isl=no],
>>  [gcc_cv_isl=yes])])
>> 
>> like config/cloog.m4 does. Also the current commit leaves the
>legacy...
>> 
>>ISL_CHECK_VERSION(0,10)
>> +  if test "${gcc_cv_isl}" = no ; then
>> +ISL_CHECK_VERSION(0,11)
>> +  fi
>> 
>> test on isl 0.10 present insuring that it will fail for any out of
>tree
>> isl version.
>>  Jack
>> 
>> 




Re: [PATCH 1/2] Document HLE / RTM intrinsics

2013-01-14 Thread Andi Kleen
> I think (somewhere else) we agreed to only document intrinsics,
> not the __builtin_ia32_ variants (they are an implementation detail).

They are all (poorly) documented.

I didn't really document them, just list them.

> Yes, we're not consistent with that, but we do miss a lot of
> documentation for these kind of builtins.  I suppose we also do not
> document all intrinsics either (though that's desired, as we provide
> those headers - even manpages would be nice for them I suppose).

It would be nice if gcc had proper documentation for all the
 functions. But that's a lot of work.

But I would like to have TSX properly documented at least.

-Andi


[patch, libstdc++, testsuite] Fix simulator timouts.

2013-01-14 Thread Steve Ellcey

Here is a patch for the last of the C++ library tests that fail for me when
run under the gnu simulator due to memory usage.

I am using the same define mechanism to shrink them when run on a simulator
as other tests are already using.

Tested on mips-mti-elf target with no regressions.

OK to checkin?

Steve Ellcey
sell...@mips.com


2013-01-14  Steve Ellcey  

* 
testsuite/libstdc++-v3/testsuite/23_containers/vector/profile/vector.cc:
Shrink memory usage under simulator.
* testsuite/libstdc++-v3/testsuite/26_numerics/valarray/28277.cc: Ditto.
* 
testsuite/libstdc++-v3/testsuite/27_io/basic_istream/extractors_character/wchar_t/4.cc:
Ditto.
* 
testsuite/libstdc++-v3/testsuite/27_io/basic_istream/getline/wchar_t/5.cc:
Ditto.
* 
testsuite/libstdc++-v3/testsuite/27_io/basic_istream/ignore/wchar_t/2.cc:
Ditto.
* 
testsuite/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_character/wchar_t/28277-1.cc:
Ditto.
* 
testsuite/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_character/wchar_t/28277-2.cc:
Ditto.
* 
testsuite/libstdc++-v3/testsuite/27_io/basic_stringbuf/overflow/wchar_t/1.cc:
Ditto.
* 
testsuite/libstdc++-v3/testsuite/27_io/basic_stringbuf/setbuf/wchar_t/4.cc:
Ditto.


diff --git a/libstdc++-v3/testsuite/23_containers/vector/profile/vector.cc 
b/libstdc++-v3/testsuite/23_containers/vector/profile/vector.cc
index 1e9d01a..7806fb2 100644
--- a/libstdc++-v3/testsuite/23_containers/vector/profile/vector.cc
+++ b/libstdc++-v3/testsuite/23_containers/vector/profile/vector.cc
@@ -1,6 +1,12 @@
 // Test vector: performance difference 25% (0.444s vs 0.539s)
 // Advice: set tmp as 1
 
+// { dg-options "-DITERATIONS=20" { target simulator } }
+
+#ifndef ITERATIONS
+#define ITERATIONS 2000
+#endif
+
 #include 
 
 using std::vector;
@@ -9,7 +15,7 @@ int main()
 {
   vector  tmp;
 
-  for (int j=0; j<2000; j++)
+  for (int j=0; jhttp://www.gnu.org/licenses/>.
 
+// { dg-options "-DMAX_SIZE=5000" { target simulator } }
+
+#ifndef MAX_SIZE
+#define MAX_SIZE 500
+#endif
+
 #include 
 #include 
 
@@ -25,7 +31,7 @@ void test01()
 {
   bool test __attribute__((unused)) = true;
 
-  const std::valarray v1(1, 500);
+  const std::valarray v1(1, MAX_SIZE);
 
   const std::valarray v2 = v1.shift(1);
   VERIFY( v2.size() == v1.size() );
diff --git 
a/libstdc++-v3/testsuite/27_io/basic_istream/extractors_character/wchar_t/4.cc 
b/libstdc++-v3/testsuite/27_io/basic_istream/extractors_character/wchar_t/4.cc
index 2e27c80..1b94684 100644
--- 
a/libstdc++-v3/testsuite/27_io/basic_istream/extractors_character/wchar_t/4.cc
+++ 
b/libstdc++-v3/testsuite/27_io/basic_istream/extractors_character/wchar_t/4.cc
@@ -19,6 +19,12 @@
 
 // 27.6.1.2.3 basic_istream::operator>>
 
+// { dg-options "-DMAX_SIZE=466" { target simulator } }
+
+#ifndef MAX_SIZE
+#define MAX_SIZE 666
+#endif
+
 #include 
 #include 
 #include 
@@ -70,7 +76,7 @@ void test01()
   const char filename[] = "inserters_extractors-4.txt";
 
   const unsigned nchunks = 10;
-  const wstring data = prepare(666, nchunks);
+  const wstring data = prepare(MAX_SIZE, nchunks);
 
   wofstream ofstrm;
   ofstrm.open(filename);
diff --git a/libstdc++-v3/testsuite/27_io/basic_istream/getline/wchar_t/5.cc 
b/libstdc++-v3/testsuite/27_io/basic_istream/getline/wchar_t/5.cc
index 39fb595..cd97df5 100644
--- a/libstdc++-v3/testsuite/27_io/basic_istream/getline/wchar_t/5.cc
+++ b/libstdc++-v3/testsuite/27_io/basic_istream/getline/wchar_t/5.cc
@@ -17,6 +17,12 @@
 
 // 27.6.1.3 unformatted input functions
 
+// { dg-options "-DMAX_LENGTH=7" { target simulator } }
+
+#ifndef MAX_LENGTH
+#define MAX_LENGTH 777
+#endif
+
 #include 
 #include 
 #include 
@@ -68,7 +74,7 @@ void test01()
 
   const wchar_t delim = L'|';
   const unsigned nchunks = 10;
-  const wstring data = prepare(777, nchunks, delim);
+  const wstring data = prepare(MAX_LENGTH, nchunks, delim);
 
   wofstream ofstrm;
   ofstrm.open(filename);
diff --git a/libstdc++-v3/testsuite/27_io/basic_istream/ignore/wchar_t/2.cc 
b/libstdc++-v3/testsuite/27_io/basic_istream/ignore/wchar_t/2.cc
index 8a24210..519c038 100644
--- a/libstdc++-v3/testsuite/27_io/basic_istream/ignore/wchar_t/2.cc
+++ b/libstdc++-v3/testsuite/27_io/basic_istream/ignore/wchar_t/2.cc
@@ -17,6 +17,12 @@
 
 // 27.6.1.3 unformatted input functions
 
+// { dg-options "-DMAX_SIZE=355" { target simulator } }
+
+#ifndef MAX_SIZE
+#define MAX_SIZE 555
+#endif
+
 #include 
 #include 
 #include 
@@ -67,7 +73,7 @@ void test01()
 
   const wchar_t delim = L'|';
   const unsigned nchunks = 10;
-  const wstring data = prepare(555, nchunks, delim);
+  const wstring data = prepare(MAX_SIZE, nchunks, delim);
 
   wofstream ofstrm;
   ofstrm.open(filename);
diff --git 
a/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_character/wchar_t/28277-1.cc
 
b/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_character/wchar_t/28277-1.cc

Re: [PATCH 2/2] Support __ATOMIC_HLE_RELEASE for __atomic_clear/store_n

2013-01-14 Thread Uros Bizjak
On Mon, Jan 14, 2013 at 7:06 PM, Andi Kleen  wrote:
>> This cannot happen, we reject code that sets both __HLE* flags.
>
> BTW I found more HLE bugs, it looks like some of the fetch_op_*
> patterns do not match always and fall back to cmpxchg, which
> does not generate HLE code correctly. Not fully sure what's
> wrong, can you spot any obvious problems? You changed the
>
> (define_insn "atomic_"
>
> pattern last.

I don't think this is a target problem, these insns work as expected
and are covered by extensive testsuite in gcc.target/i386/hle-*.c.

Uros.


Re: Support for MIPS r5900

2013-01-14 Thread Maciej W. Rozycki
Hi Jürgen,

> >  Now if that failed for you, then it's a plain bug in GAS that should be 
> > fixed.  Can you therefore check whether a piece like:
> > 
> > .setmips2
> > ll  $2, ($3)
> > 
> > assembles correctly with -march=r5900?
> 
> This seems to work. I didn't know that this would work. I thought it 
> would never be possible to generate ll and sc.

 Excellent, I hoped that it would work as we've been using these overrides 
for years, except that usually they are used to tweak the ISA selected 
rather than a specific CPU (with -march= you can request either an ISA or 
a CPU).  Your case is the first I've personally encountered where the CPU 
selected needs an override, so I'm glad that it just works.

> >  Please note that the issue of LLD and SCD remains open -- these 
> > instructions are a part of the base MIPS III 64-bit ISA and therefore they
> > are assumed by glibc and elsewhere to be present, and they are not 
> > emulated by Linux.  So not only you'll have to fix up glibc to surround 
> > their use with .set mips3 for the n64 and n32 ABIs (please note that .set 
> > mips3 is needed for LL and SC for these ABIs as well to avoid a 
> > miscalculation of addresses where applicable), but you'll have to add 
> > emulation code to Linux as well.
> 
> I didn't see any code yet that uses lld/scd, so it doesn't seem to be a 
> problem. I will create a patch which includes tests that will ensure 
> that .set mips3 will work.

 Glibc uses them exactly where it uses 32-bit LL/SC, except where a 64-bit 
data type is involved.  Of course that also requires a 64-bit ABI, either 
n64 or n32, as these are 64-bit instructions -- from what you wrote thus 
far I've gathered, perhaps incorrectly, that you've been using either or 
both too, in addition to o32 -- is my understanding correct?

> > > There are even more problems when running unchanged code from official 
> > > Fedora 12 on PS2, because of some different opcode encoding. The users 
> > > of my PS2 Linux 2.6 complain about low speed, because many instructions 
> > > are emulated. I need some fast implementation, even if the size of the 
> > > floating point data types is smaller. So 32 bit FPU must be default for 
> > > r5900.
> > 
> >  That sounds weird -- why would anyone want to use a non-standard encoding
> > for any instructions?  The base MIPS III 64-bit ISA was set as far back as
> > in 1991.  Is R5900 documentation publicly available BTW?
> 
> The documentation for r5900 is available on the first DVD of Sony's 
> Linux Toolkit and in the SDK for the PS2 which is only available for 
> people which I would call "verified Sony customers".

 OK, I see, so not really public, sigh...

> The TX79 core is similar to the r5900:
> http://www.lukasz.dk/files/tx79architecture.pdf
> But the TX79 has a 64 Bit FPU, so there are no real problems with opcode 
> encoding. This document also says that mips isa III is supported, but 
> not ll,sc,lld,scd,dmult and ddiv. In binutils/opcodes/mips-opc.c you can 
> see the different opcode encoding for c.lt.s and trunc.w.s, the missing 
> c.olt.s and cvt.w.s instructions. These are caused by the FPU. This is 
> no problem on the TX79.

 Oh well, missing instructions are not that much of a problem, they can 
always be emulated.  Instruction words that implement operation different 
to one expected are a show-stopper though.

 I see that the encodings supposed to implement C.OLT.S and C.OLE.S are 
interpreted as C.LT.S and C.LE.S, respectively.  However the former
instructions differ from the latters only in how quiet NaNs are treated.  
Given that, as you say, the processor does not support NaNs anyway, this 
may well be considered correct operation.  You may still need to emulate 
the other encoding though.

 How are unsupported floating-point data treated, BTW -- what results does 
the processor produce for floating-point encodings that would normally be 
interpreted as not-a-number, an infinity or a denormalised number?  Are 
they treated numerically, beyond the range IEEE-754 single provides?  You 
say that the Invalid Operation exception is not raised, so they cannot be 
trapped and emulated.

> For Fedora 12 I need to disable the FPU and emulate everything.

 Well, given the lack of full IEEE-754 support you'll always have to do 
that for generic MIPS code.  The kernel could interpret E_MIPS_MACH_5900 
set in the ELF file header flags though and enable the FPU selectively for 
compatible binaries.  Such binaries might produce computational results 
different to expected of course.  You'd have to enforce object-file 
compatibility though and make sure R5900 binaries do not run with the FPU 
enabled on other hardware too.

 That might be an interesting project if you'd like to dive into it.

> One of the biggest problem is that most Linux programs use the rdhwr 
> instruction (0x7c03e83b). I don't know any MIPS CPU which supports this 
> instruction.

 Oh, pretty much all modern MIPS processors do --

Re: [PATCH 2/2] Support __ATOMIC_HLE_RELEASE for __atomic_clear/store_n

2013-01-14 Thread Andi Kleen
On Mon, Jan 14, 2013 at 07:40:56PM +0100, Uros Bizjak wrote:
> On Mon, Jan 14, 2013 at 7:06 PM, Andi Kleen  wrote:
> >> This cannot happen, we reject code that sets both __HLE* flags.
> >
> > BTW I found more HLE bugs, it looks like some of the fetch_op_*
> > patterns do not match always and fall back to cmpxchg, which
> > does not generate HLE code correctly. Not fully sure what's
> > wrong, can you spot any obvious problems? You changed the
> >
> > (define_insn "atomic_"
> >
> > pattern last.
> 
> I don't think this is a target problem, these insns work as expected
> and are covered by extensive testsuite in gcc.target/i386/hle-*.c.

Well the C++ test cases I wrote didn't work. It may be related to 
how complex the program is. Simple calls as in the original
test suite seem to work.

e.g.  instead of xacquire lock and ... it ended up with a cmpxchg loop
(which I think is a fallback path). The cmpxchg loop didn't include
a HLE prefix (and simply adding one is not enoigh, would need more
changes for successfull elision)

Before HLE the cmpxchg code was correct, just somewhat inefficient.
Even with HLE it is technically correct, just it'll never elide.

I think I would like to fix and,or,xor and disallow HLE for nand.

Here's a test case. Needs the libstdc++ HLE patch posted.

#include 

#define ACQ memory_order_acquire | __memory_order_hle_acquire
#define REL memory_order_release | __memory_order_hle_release

int main()
{
  using namespace std;
  atomic_ulong au = ATOMIC_VAR_INIT(0);

  if (!au.fetch_and(1, ACQ))
au.fetch_and(-1, REL);

  unsigned lock = 0;
  __atomic_fetch_and(&lock, 1, __ATOMIC_HLE_ACQUIRE|__ATOMIC_ACQUIRE);

  return 0;
}

The first fetch_and generates: (wrong)


.L2:
movq%rax, %rcx
movq%rax, %rdx
andl$1, %ecx
lock; cmpxchgq  %rcx, -24(%rsp)
jne .L2


the second __atomic_fetch_and generates (correct):


lock; 
.byte   0xf2
andl$1, -28(%rsp)
.LBE14:


-Andi

-- 
a...@linux.intel.com -- Speaking for myself only.


[wwwdocs] Mention MIPS changes for 4.8.

2013-01-14 Thread Richard Sandiford
Update the MIPS section of the 4.8 release notes.  Please let me know
if I missed anything, or if you think the entries should be changed.

Committed.

Richard


Index: htdocs/gcc-4.8/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/changes.html,v
retrieving revision 1.82
retrieving revision 1.84
diff -u -r1.82 -r1.84
--- htdocs/gcc-4.8/changes.html 13 Jan 2013 11:29:33 -  1.82
+++ htdocs/gcc-4.8/changes.html 14 Jan 2013 19:01:03 -  1.84
@@ -481,11 +481,21 @@
 
 MIPS
   
+GCC can now generate code specifically for the R4700, Broadcom XLP
+  and MIPS 34kn processors.  The associated -march options
+  are -march=r4700, -march=xlp
+  and -march=34kn respectively.
+GCC now generates better DSP code for MIPS 74k cores thanks
+  to further scheduling optimizations.
+The MIPS port now supports the -fstack-check
+  option.
 GCC now passes the -mmcu and -mno-mcu
-options to the assembler.
-Support for the R4700 has been added.
-GCC now generates better code for Broadcom XLP processors thanks
-  to improvements in scheduling and atomic built-ins support.
+  options to the assembler.
+Previous versions of GCC would silently accept -fpic
+  and -fPIC for -mno-abicalls targets
+  like mips*-elf.  This combination was not intended
+  or supported, and did not generate position-independent code.
+  GCC 4.8 now reports an error when this combination is used.
   
 
 PowerPC / PowerPC64 / RS6000


Re: [PATCH] Fix PR55833 + cheaper checking

2013-01-14 Thread Marek Polacek
On Mon, Jan 14, 2013 at 06:51:54PM +0100, Zdenek Dvorak wrote:
> Hi,
> 
> > On Thu, Jan 10, 2013 at 11:19:43PM +0100, Zdenek Dvorak wrote:
> > > I agree -- at the very least, unswitch_single_loop should check whether 
> > > there
> > > is any possiblity it could have affected irreducible loops information 
> > > (this
> > > should only be the case when some already existing irreducible loop is 
> > > altered
> > > in the progress).  Which is what it (or more precisely, remove_path 
> > > function
> > > used by it) tries to do -- so is should be sufficient to check why this 
> > > fails
> > > for the considered testcase, and make sure the situation is correctly 
> > > detected,
> > 
> > Actually, in this case, we don't call remove_path from unswitch_single_loop
> > at all.
> 
> I am not quite sure what you mean by that -- remove_path is called 
> unconditionally
> in unswitch_loop (and fix_loop_placement is only called through remove_path).

Yeah, that's right, what I meant was that in unswitch_single_loop, we
call remove_path only conditionally (and for this particular TC that's
not the case).

> > So, here's another stab at it.  In this version, we will call
> > mark_irreducible_loops only in case where we're removing a loop
> > from loop hierarchy tree.  Because when we do that (and we're in some
> > irreducible region), the edge that connects those two loops
> > should be marked as EDGE_IRREDUCIBLE_LOOP.  And the preheader BB
> > eventually as BB_IRREDUCIBLE_LOOP.  Does this look any better?
> > I'm not actually checking whether we really are in a irreducible
> > region, should that be done (how?)?
> 
> Yes, you should check whether you are in an irreducible loop.  This is done by
> testing EDGE_IRREDUCIBLE_LOOP flag,

Alright, I was wondering whether there's any other way.  Unfortunately,
here I couldn't do something like

if (loop_preheader_edge (loop)->flags & EDGE_IRREDUCIBLE_LOOP)
  ...
because we're natural loop in a subloop, so I abused the loop exits of
this loop.  Hopefully I'm not doing something evil.

Updated patch attached.  Ok if testing passes?  Thanks,

2013-01-14  Richard Biener  
Marek Polacek  

PR rtl-optimization/55833
* loop-unswitch.c (unswitch_loops): Move loop verification...
(unswitch_single_loop): ...here.  Call mark_irreducible_loops.
* cfgloopmanip.c (fix_loop_placement): Add IRRED_INVALIDATED parameter.
Set it to true when we're removing a loop from hierarchy tree in
an irreducible region.
(fix_bb_placements): Adjust caller.
(fix_loop_placements): Likewise.

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

--- gcc/loop-unswitch.c.mp  2013-01-10 16:50:28.899559875 +0100
+++ gcc/loop-unswitch.c 2013-01-14 19:04:21.675418957 +0100
@@ -145,12 +144,7 @@ unswitch_loops (void)
   /* Go through inner loops (only original ones).  */
 
   FOR_EACH_LOOP (li, loop, LI_ONLY_INNERMOST)
-{
-  unswitch_single_loop (loop, NULL_RTX, 0);
-#ifdef ENABLE_CHECKING
-  verify_loop_structure ();
-#endif
-}
+unswitch_single_loop (loop, NULL_RTX, 0);
 
   iv_analysis_done ();
 }
@@ -370,6 +364,10 @@ unswitch_single_loop (struct loop *loop,
   nloop = unswitch_loop (loop, bbs[i], copy_rtx_if_shared (cond), cinsn);
   gcc_assert (nloop);
 
+#ifdef ENABLE_CHECKING
+  verify_loop_structure ();
+#endif
+
   /* Invoke itself on modified loops.  */
   unswitch_single_loop (nloop, rconds, num + 1);
   unswitch_single_loop (loop, conds, num + 1);
--- gcc/cfgloopmanip.c.mp   2013-01-14 14:42:52.502002650 +0100
+++ gcc/cfgloopmanip.c  2013-01-14 19:55:47.330356459 +0100
@@ -111,10 +111,13 @@ fix_bb_placement (basic_block bb)
 /* Fix placement of LOOP inside loop tree, i.e. find the innermost superloop
of LOOP to that leads at least one exit edge of LOOP, and set it
as the immediate superloop of LOOP.  Return true if the immediate superloop
-   of LOOP changed.  */
+   of LOOP changed.
+
+   IRRED_INVALIDATED is set to true if a change in the loop structures might
+   invalidate the information about irreducible regions.  */
 
 static bool
-fix_loop_placement (struct loop *loop)
+fix_loop_placement (struct loop *loop, bool *irred_invalidated)
 {
   unsigned i;
   edge e;
@@ -139,7 +142,12 @@ fix_loop_placement (struct loop *loop)
   /* The exit edges of LOOP no longer exits its original immediate
 superloops; remove them from the appropriate exit lists.  */
   FOR_EACH_VEC_ELT (exits, i, e)
-   rescan_loop_exit (e, false, false);
+   {
+ /* We may need to recompute irreducible loops.  */
+ if (e->flags & EDGE_IRREDUCIBLE_LOOP)
+   *irred_invalidated = true;
+ rescan_loop_exit (e, false, false);
+   }
 
   ret = true;
 }
@@ -212,7 +220,7 @@ fix_bb_placements (basic_block from,
   if (from->loop_father->header == from)
{
  /* Subloop header, maybe move the loop upward.  */
- if (!fix_loop_placement (from->loop_father))

Re: [PATCH 2/2] Support __ATOMIC_HLE_RELEASE for __atomic_clear/store_n

2013-01-14 Thread Uros Bizjak
On Mon, Jan 14, 2013 at 8:01 PM, Andi Kleen  wrote:
>> >> This cannot happen, we reject code that sets both __HLE* flags.
>> >
>> > BTW I found more HLE bugs, it looks like some of the fetch_op_*
>> > patterns do not match always and fall back to cmpxchg, which
>> > does not generate HLE code correctly. Not fully sure what's
>> > wrong, can you spot any obvious problems? You changed the
>> >
>> > (define_insn "atomic_"
>> >
>> > pattern last.
>>
>> I don't think this is a target problem, these insns work as expected
>> and are covered by extensive testsuite in gcc.target/i386/hle-*.c.
>
> Well the C++ test cases I wrote didn't work. It may be related to
> how complex the program is. Simple calls as in the original
> test suite seem to work.
>
> e.g.  instead of xacquire lock and ... it ended up with a cmpxchg loop
> (which I think is a fallback path). The cmpxchg loop didn't include
> a HLE prefix (and simply adding one is not enoigh, would need more
> changes for successfull elision)
>
> Before HLE the cmpxchg code was correct, just somewhat inefficient.
> Even with HLE it is technically correct, just it'll never elide.

I'd start with attached (mechanical) patch that just blindly adds
masks where memory model is checked. Please note that ATOMIC_HLE
modifies high bits of the model, so these checks fail in presence of
HLE modifiers.

Uros.
Index: emit-rtl.c
===
--- emit-rtl.c  (revision 195152)
+++ emit-rtl.c  (working copy)
@@ -6014,7 +6014,7 @@ insn_file (const_rtx insn)
 bool
 need_atomic_barrier_p (enum memmodel model, bool pre)
 {
-  switch (model)
+  switch (model & MEMMODEL_MASK)
 {
 case MEMMODEL_RELAXED:
 case MEMMODEL_CONSUME:
Index: optabs.c
===
--- optabs.c(revision 195152)
+++ optabs.c(working copy)
@@ -7008,9 +7008,9 @@ maybe_emit_sync_lock_test_and_set (rtx target, rtx
  exists, and the memory model is stronger than acquire, add a release 
  barrier before the instruction.  */
 
-  if (model == MEMMODEL_SEQ_CST
-  || model == MEMMODEL_RELEASE
-  || model == MEMMODEL_ACQ_REL)
+  if ((model & MEMMODEL_MASK) == MEMMODEL_SEQ_CST
+  || (model & MEMMODEL_MASK) == MEMMODEL_RELEASE
+  || (model & MEMMODEL_MASK) == MEMMODEL_ACQ_REL)
 expand_mem_thread_fence (model);
 
   if (icode != CODE_FOR_nothing)
@@ -7388,7 +7388,7 @@ expand_mem_thread_fence (enum memmodel model)
 {
   if (HAVE_mem_thread_fence)
 emit_insn (gen_mem_thread_fence (GEN_INT (model)));
-  else if (model != MEMMODEL_RELAXED)
+  else if ((model & MEMMODEL_MASK) != MEMMODEL_RELAXED)
 {
   if (HAVE_memory_barrier)
emit_insn (gen_memory_barrier ());
@@ -7412,7 +7412,7 @@ expand_mem_signal_fence (enum memmodel model)
 {
   if (HAVE_mem_signal_fence)
 emit_insn (gen_mem_signal_fence (GEN_INT (model)));
-  else if (model != MEMMODEL_RELAXED)
+  else if ((model & MEMMODEL_MASK) != MEMMODEL_RELAXED)
 {
   /* By default targets are coherent between a thread and the signal
 handler running on the same thread.  Thus this really becomes a
@@ -7467,7 +7467,7 @@ expand_atomic_load (rtx target, rtx mem, enum memm
 target = gen_reg_rtx (mode);
 
   /* For SEQ_CST, emit a barrier before the load.  */
-  if (model == MEMMODEL_SEQ_CST)
+  if ((model & MEMMODEL_MASK) == MEMMODEL_SEQ_CST)
 expand_mem_thread_fence (model);
 
   emit_move_insn (target, mem);
@@ -7513,7 +7513,7 @@ expand_atomic_store (rtx mem, rtx val, enum memmod
  if (maybe_expand_insn (icode, 2, ops))
{
  /* lock_release is only a release barrier.  */
- if (model == MEMMODEL_SEQ_CST)
+ if ((model & MEMMODEL_MASK) == MEMMODEL_SEQ_CST)
expand_mem_thread_fence (model);
  return const0_rtx;
}
@@ -7540,7 +7540,7 @@ expand_atomic_store (rtx mem, rtx val, enum memmod
   emit_move_insn (mem, val);
 
   /* For SEQ_CST, also emit a barrier after the store.  */
-  if (model == MEMMODEL_SEQ_CST)
+  if ((model & MEMMODEL_MASK) == MEMMODEL_SEQ_CST)
 expand_mem_thread_fence (model);
 
   return const0_rtx;


Re: [PATCH 2/2] Support __ATOMIC_HLE_RELEASE for __atomic_clear/store_n

2013-01-14 Thread Uros Bizjak
On Mon, Jan 14, 2013 at 8:01 PM, Andi Kleen  wrote:

> Well the C++ test cases I wrote didn't work. It may be related to
> how complex the program is. Simple calls as in the original
> test suite seem to work.
>
> e.g.  instead of xacquire lock and ... it ended up with a cmpxchg loop
> (which I think is a fallback path). The cmpxchg loop didn't include
> a HLE prefix (and simply adding one is not enoigh, would need more
> changes for successfull elision)
>
> Before HLE the cmpxchg code was correct, just somewhat inefficient.
> Even with HLE it is technically correct, just it'll never elide.
>
> I think I would like to fix and,or,xor and disallow HLE for nand.
>
> Here's a test case. Needs the libstdc++ HLE patch posted.

Can you please attach _preprocessed_ (i.e. add -save-temps to compile
flags) source to a PR?

Uros.


Re: [PATCH] Allow new ISL/CLooG versions

2013-01-14 Thread Dominique Dhumieres
In order to bootstrap r195167 with the new ISL/CLooG versions,
I had to apply the following patch:

--- ../work/configure   2013-01-14 19:32:00.0 +0100
+++ configure   2013-01-14 19:42:15.0 +0100
@@ -5848,7 +5848,7 @@ else
 int
 main ()
 {
-if (strncmp (isl_version (), "isl-0.10", strlen ("isl-0.10")) != 0)
+if (strncmp (isl_version (), "isl-0.11", strlen ("isl-0.11")) != 0)
  return 1;
 
   ;
@@ -6033,7 +6033,7 @@ int
 main ()
 {
 #if CLOOG_VERSION_MAJOR != 0 \
-|| CLOOG_VERSION_MINOR != 17 \
+|| CLOOG_VERSION_MINOR != 18 \
 || CLOOG_VERSION_REVISION < 0
 choke me
#endif

(I didn't bother to update the messages: got 
checking for version 0.10 of ISL... yes
checking for version 0.17.0 of CLooG... yes).

Dominique



libgcc patch committed: Change __real_pthread_create ref to be non-weak

2013-01-14 Thread Ian Lance Taylor
The declaration of __real_pthread_create in generic-morestack-thread.c
had attribute weak.  Note that this code is linked with --wrap
pthread_create, so the reference to __real_pthread_create is really to
pthread_create.  Using weak was incorrect, because the reference really
is a strong one.  There is no support for __real_pthread_create aka
pthread_create to not be defined.  It caused some Go programs to fail
when linking statically, because a weak reference does not cause a
symbol definition to be included from an archive.  If there was no other
reason to include pthread_create, then pthread_create would never be
defined, so the call to __real_pthread_create would crash at runtime.

This fixes a regression, as static linking of Go programs used to work.

Bootstrapped and ran Go testsuite and split-stack tests on
x86_64-unknown-linux-gnu.  Committed to mainline.

Ian


2013-01-14  Ian Lance Taylor  

* generic-morestack-thread.c: Change declaration of
__real_pthread_create to not be weak.


Index: generic-morestack-thread.c
===
--- generic-morestack-thread.c	(revision 195171)
+++ generic-morestack-thread.c	(working copy)
@@ -136,8 +136,7 @@ int __wrap_pthread_create (pthread_t *,
   __attribute__ ((visibility ("hidden")));
 
 extern int __real_pthread_create (pthread_t *, const pthread_attr_t *,
-  void *(*start_routine) (void *), void *)
-  __attribute__ ((weak));
+  void *(*start_routine) (void *), void *);
 
 int
 __wrap_pthread_create (pthread_t *tid, const pthread_attr_t *attr,


Re: libgcc patch committed: Change __real_pthread_create ref to be non-weak

2013-01-14 Thread Ian Lance Taylor
On Mon, Jan 14, 2013 at 11:33 AM, Ian Lance Taylor  wrote:
> The declaration of __real_pthread_create in generic-morestack-thread.c
> had attribute weak.  Note that this code is linked with --wrap
> pthread_create, so the reference to __real_pthread_create is really to
> pthread_create.  Using weak was incorrect, because the reference really
> is a strong one.  There is no support for __real_pthread_create aka
> pthread_create to not be defined.  It caused some Go programs to fail
> when linking statically, because a weak reference does not cause a
> symbol definition to be included from an archive.  If there was no other
> reason to include pthread_create, then pthread_create would never be
> defined, so the call to __real_pthread_create would crash at runtime.
>
> This fixes a regression, as static linking of Go programs used to work.
>
> Bootstrapped and ran Go testsuite and split-stack tests on
> x86_64-unknown-linux-gnu.  Committed to mainline.

Sigh, this turned out to be wrong because it causes libgcc_s.so to
require libpthread.so.

Reverted.

Ian


Re: libgcc patch committed: Change __real_pthread_create ref to be non-weak

2013-01-14 Thread H.J. Lu
On Mon, Jan 14, 2013 at 11:33 AM, Ian Lance Taylor  wrote:
> The declaration of __real_pthread_create in generic-morestack-thread.c
> had attribute weak.  Note that this code is linked with --wrap
> pthread_create, so the reference to __real_pthread_create is really to
> pthread_create.  Using weak was incorrect, because the reference really
> is a strong one.  There is no support for __real_pthread_create aka
> pthread_create to not be defined.  It caused some Go programs to fail
> when linking statically, because a weak reference does not cause a
> symbol definition to be included from an archive.  If there was no other
> reason to include pthread_create, then pthread_create would never be
> defined, so the call to __real_pthread_create would crash at runtime.
>
> This fixes a regression, as static linking of Go programs used to work.
>
> Bootstrapped and ran Go testsuite and split-stack tests on
> x86_64-unknown-linux-gnu.  Committed to mainline.
>
> Ian
>
>
> 2013-01-14  Ian Lance Taylor  
>
> * generic-morestack-thread.c: Change declaration of
> __real_pthread_create to not be weak.
>

I think you run into:

http://sourceware.org/bugzilla/show_bug.cgi?id=14556


-- 
H.J.


Re: testsuite: missing or wrong dg-* directives?

2013-01-14 Thread Mike Stump
On Jan 14, 2013, at 6:23 AM, Mikael Morin  wrote:
> Le 14/01/2013 00:37, Manfred Schwarb a écrit :
>> Am 14.01.2013 00:10, schrieb Manfred Schwarb:
>>> 
>>> There are several other oddities: d_g-final, braces have to be
>>> separated by spaces.
> 
> Want to send a patch?
> 
>>> Not sure about the double braces in lto, I guess they act simply as
>>> single braces.
> 
> I don't know, you may ask a testsuite maintainer, or the author.  It is 
> unlikely though that the author made a typo at the opening brace _and_ at the 
> closing one.

Yeah…  A quick check of the _documentation_ (a terrible thing to waste):

http://gcc.gnu.org/onlinedocs/gcc-4.5.4/gccint/LTO-Testing.html

{ dg-lto-options { { options } [{ options }] } [{ target selector }]}
This directive provides a list of one or more sets of compiler options to 
override LTO_OPTIONS. Each test will be compiled and run with each of these 
sets of options.


Re: [PATCH] Allow new ISL/CLooG versions

2013-01-14 Thread Jack Howarth
On Mon, Jan 14, 2013 at 07:22:03PM +0100, Richard Biener wrote:
> Jack Howarth  wrote:
> 
> >On Mon, Jan 14, 2013 at 11:03:41AM -0500, Jack Howarth wrote:
> >> On Mon, Jan 14, 2013 at 04:44:04PM +0100, Tobias Grosser wrote:
> >> > On 01/14/2013 03:29 PM, Richard Biener wrote:
> >> >>
> >> >> This makes us accept the CLooG 0.18.0 and ISL 0.11.1 combo.
> >> >>
> >> >> It's probably not the best stage to move the version checks to
> >> >> gcc/ where we can rely on built in-tree ISL/CLooG, so this avoids
> >> >> it with the caveat that in-tree CLooG 0.18.0 will fail the
> >> >> version check (they no longer ship built version.h but only
> >> >> version.h.in).
> >> >>
> >> >> I verified all GRAPHITE tests pass with 0.18.0/0.11.1.
> >> >>
> >> >> Ok for trunk?
> >
> >Richard,
> >Did you see my patch proposal in the gcc mailing list  before you
> >crafted your patch?
> >
> >http://gcc.gnu.org/ml/gcc/2012-12/msg00195.html
> >
> Yes I did.  The patch is not broken, it restricts compare to major and minor.

How exactly did you test this? I am using isl 0.11.1 and cloog 0.18.0 from fink
installed in /sw out of tree. This fails in config.log as...

configure:5836: checking for version 0.10 of ISL
configure:5858: gcc -o conftest -g -O2 -I/sw/include -I/sw/include 
-I/sw/include-L/sw/lib conftest.c  -lisl >&5
configure:5858: $? = 0
configure:5858: ./conftest
configure:5858: $? = 1
configure: program exited with status 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| #define LT_OBJDIR ".libs/"
| /* end confdefs.h.  */
| #include 
|#include 
| int
| main ()
| {
| if (strncmp (isl_version (), "isl-0.10", strlen ("isl-0.10")) != 0)
|  return 1;
| 
|   ;
|   return 0;
| }
configure:5868: result: no
configure:5889: checking for version 0.11 of ISL
configure:5921: result: no
configure:5956: error: Unable to find a usable ISL.  See config.log for details.

This is with gcc trunk configured as...

 $ ../gcc-4.8-20130114/configure --prefix=/sw --prefix=/sw/lib/gcc4.8 
--mandir=/sw/share/man --infodir=/sw/lib/gcc4.8/info 
--enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw 
--with-libiconv-prefix=/sw --with-isl=/sw --with-cloog=/sw --with-mpc=/sw 
--with-system-zlib --enable-checking=yes --x-includes=/usr/X11R6/include 
--x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.8


> 
> Richard.
> >Jack
> >
> >> >>
> >> >> Or do people prefer to move CLooG/ISL checks to gcc/ configure
> >> >> time to fix the in-tree use of 0.18.0 and also do version checks
> >> >> of in-tree ISL at all (they don't have a version.h).
> >> >
> >> > Hi Richi,
> >> >
> >> > I think this is a good thing. But this probably requires some
> >config  
> >> > guys to approve it.
> >> >
> >> > All the best,
> >> > Tobi
> >> 
> >> Tnis change has already been committed at...
> >> 
> >> r195150 | rguenth | 2013-01-14 10:01:13 -0500 (Mon, 14 Jan 2013) | 5
> >lines
> >> 
> >> 2013-01-14  Richard Biener  
> >> 
> >> * configure.ac (cloog/isl): Also allow ISL 0.11.x and CLooG
> >0.18.0.
> >> * configure: Re-generate
> >> 
> >> 
> >> This change is broken in several ways. The current commit doesn't
> >handle
> >> isl 0.11.1 because it omits teaching config/isl.m4 how to handle
> >revsions
> >> with...
> >> 
> >> Index: config/isl.m4
> >> ===
> >> --- config/isl.m4  (revision 194744)
> >> +++ config/isl.m4  (working copy)
> >> @@ -89,13 +89,13 @@ AC_DEFUN([ISL_REQUESTED],
> >>  ]
> >>  )
> >>  
> >> -# _ISL_CHECK_CT_PROG(MAJOR, MINOR)
> >> +# _ISL_CHECK_CT_PROG(MAJOR, MINOR, REVISION)
> >>  # 
> >>  # Helper for verifying ISL compile time version.
> >>  m4_define([_ISL_CHECK_CT_PROG],[AC_LANG_PROGRAM(
> >>[#include 
> >> #include ],
> >> -  [if (strncmp (isl_version (), "isl-$1.$2", strlen ("isl-$1.$2"))
> >!= 0)
> >> +  [if (strncmp (isl_version (), "isl-$1.$2.$3", strlen
> >("isl-$1.$2.$3")) != 0)
> >>   return 1;
> >> ])])
> >>  
> >> @@ -115,9 +115,9 @@ AC_DEFUN([ISL_CHECK_VERSION],
> >>  LIBS="${_isl_saved_LIBS} -lisl"
> >>  echo $CFLAGS
> >>  
> >> -AC_CACHE_CHECK([for version $1.$2 of ISL],
> >> +AC_CACHE_CHECK([for version $1.$2.$3 of ISL],
> >>[gcc_cv_isl],
> >> -  [AC_RUN_IFELSE([_ISL_CHECK_CT_PROG($1,$2)],
> >> +  [AC_RUN_IFELSE([_ISL_CHECK_CT_PROG($1,$2,$3)],
> >>[gcc_cv_isl=yes],
> >>[gcc_cv_isl=no],
> >>[gcc_cv_isl=yes])])
> >> 
> >> like config/cloog.m4 does. Also the current commit leaves the
> >legacy...
> >> 
> >>ISL_CHECK_VERSION(0,10)
> >> +  if test "${gcc_cv_isl}" = no ; then
> >> +ISL_CHECK_VERSION(0,11)
> >> +  fi
> >> 
> >> test on isl 0.10 present insuring that it will fail for any out of
> >tree
> >> isl version.
> >>  Jack
> >> 
> >> 
> 


Re: [patch, libstdc++, testsuite] Fix simulator timouts.

2013-01-14 Thread Jonathan Wakely
On 14 January 2013 18:40, Steve Ellcey wrote:
>
> Here is a patch for the last of the C++ library tests that fail for me when
> run under the gnu simulator due to memory usage.
>
> I am using the same define mechanism to shrink them when run on a simulator
> as other tests are already using.
>
> Tested on mips-mti-elf target with no regressions.
>
> OK to checkin?

The copyright dates in the tests should be 2013 (sorry to be a pain!)
OK with that change.

.


Re: [PATCH] Allow new ISL/CLooG versions

2013-01-14 Thread Dominique Dhumieres
Jack,

> How exactly did you test this? I am using isl 0.11.1 and cloog 0.18.0 from 
> fink
> installed in /sw out of tree. This fails in config.log as...

Same here (the libs are not in /sw but in /mp) and I got the same errors before
I did the changed in my previous post.

Dominique


Re: [PATCH] Allow new ISL/CLooG versions

2013-01-14 Thread Jack Howarth
On Mon, Jan 14, 2013 at 08:27:12PM +0100, Dominique Dhumieres wrote:
> In order to bootstrap r195167 with the new ISL/CLooG versions,
> I had to apply the following patch:
> 
> --- ../work/configure 2013-01-14 19:32:00.0 +0100
> +++ configure 2013-01-14 19:42:15.0 +0100
> @@ -5848,7 +5848,7 @@ else
>  int
>  main ()
>  {
> -if (strncmp (isl_version (), "isl-0.10", strlen ("isl-0.10")) != 0)
> +if (strncmp (isl_version (), "isl-0.11", strlen ("isl-0.11")) != 0)
>   return 1;
>  
>;
> @@ -6033,7 +6033,7 @@ int
>  main ()
>  {
>  #if CLOOG_VERSION_MAJOR != 0 \
> -|| CLOOG_VERSION_MINOR != 17 \
> +|| CLOOG_VERSION_MINOR != 18 \
>  || CLOOG_VERSION_REVISION < 0
>  choke me
> #endif
> 
> (I didn't bother to update the messages: got 
> checking for version 0.10 of ISL... yes
> checking for version 0.17.0 of CLooG... yes).
> 
> Dominique

Dominique,
   I believe that hack effectively changes...

Index: configure.ac
===
--- configure.ac(revision 195174)
+++ configure.ac(working copy)
@@ -1607,7 +1607,7 @@ if test "x$with_isl" != "xno" &&
   dnl with user input.
   ISL_INIT_FLAGS
   dnl The versions of ISL that work for Graphite
-  ISL_CHECK_VERSION(0,10)
+  ISL_CHECK_VERSION(0,11)
   if test "${gcc_cv_isl}" = no ; then
 ISL_CHECK_VERSION(0,11)
   fi

Richard seems to be assuming that the second call to ISL_CHECK_VERSION(0,11)
in configure.ac will rerun the isl checks on 0.11.x but I suspect this doesn't
take in account the caching of the results from the first call to 
ISL_CHECK_VERSION().
Certainly from my config.log against isl 0.11.1 and cloog 0.18.0, it appears 
that
the version tests from the ISL_CHECK_VERSION(0,11) call aren't run and the
cached result from the first ISL_CHECK_VERSION(0,10) is used instead.
 Jack



Re: Mention of gcc 4.5 as first version with plugin support

2013-01-14 Thread Richard Biener
On Fri, Jan 11, 2013 at 9:46 PM, Basile Starynkevitch
 wrote:
> On Fri, 11 Jan 2013 09:58:49 +0100
> Dodji Seketeli  wrote:
>
>> Thank you Dave for this documentation patch that looks OK to my casual
>> eyes.  Let's CC the documentation maintainers.
>>
>> Dave Johansen  a écrit:
>>
>> >
>> > +GCC plugin support is available in GCC version 4.5.0 and
>> > +later.
>
> Maybe we should say that a later version is preferable.
> IIRC 4.5 plugin support was not very good -it was more an experimental stage 
> than
> anything else. I believe that we should not encourage people to write plugins 
> against
> 4.5.

What's the value of documenting the availability of an unstable API in
older versions
of GCC?  Mind this documentation is version specific.

Richard.

> Cheers.
>
> --
> Basile STARYNKEVITCH http://starynkevitch.net/Basile/
> email: basilestarynkevitchnet mobile: +33 6 8501 2359
> 8, rue de la Faiencerie, 92340 Bourg La Reine, France
> *** opinions {are only mine, sont seulement les miennes} ***


[patch] --with-build-sysroot requires --with-sysroot

2013-01-14 Thread Matthias Klose
this is documented in doc/install.texi:

"""
This option is only useful when you are already using 
@option{--with-sysroot}."""

now, lets error out if you configure --with-build-sysroot without
--with-sysroot. Ok for the trunk?

This was hit in PR55743. I think the patch in
http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00198.html is still valid, but
independent of this.

  Matthias

gcc/

2013-01-14  Matthias Klose 

	* configure.ac: fail --with-build-sysroot without --with-sysroot.
	* configure: Regenerate.

Index: gcc/configure.ac
===
--- gcc/configure.ac	(Revision 195151)
+++ gcc/configure.ac	(Arbeitskopie)
@@ -755,15 +755,6 @@
  configured_native_system_header_dir="${withval}"
 ], [configured_native_system_header_dir=])
 
-AC_ARG_WITH(build-sysroot, 
-  [AS_HELP_STRING([--with-build-sysroot=sysroot],
-  [use sysroot as the system root during the build])],
-  [if test x"$withval" != x ; then
- SYSROOT_CFLAGS_FOR_TARGET="--sysroot=$withval"
-   fi],
-  [SYSROOT_CFLAGS_FOR_TARGET=])
-AC_SUBST(SYSROOT_CFLAGS_FOR_TARGET)
-
 if test "x$prefix" = xNONE; then
  test_prefix=/usr/local
 else
@@ -805,6 +796,19 @@
 AC_SUBST(TARGET_SYSTEM_ROOT_DEFINE)
 AC_SUBST(CROSS_SYSTEM_HEADER_DIR)
 
+AC_ARG_WITH(build-sysroot, 
+  [AS_HELP_STRING([--with-build-sysroot=sysroot],
+  [use sysroot as the system root during the build])],
+  [if test x"$withval" != x ; then
+ SYSROOT_CFLAGS_FOR_TARGET="--sysroot=$withval"
+   fi],
+  [SYSROOT_CFLAGS_FOR_TARGET=])
+AC_SUBST(SYSROOT_CFLAGS_FOR_TARGET)
+if test x"$TARGET_SYSTEM_ROOT" = x && test x"$SYSROOT_CFLAGS_FOR_TARGET" != x
+then
+  AC_MSG_ERROR([option --with-build-sysroot requires --with-sysroot])
+fi
+
 AC_ARG_WITH(specs,
   [AS_HELP_STRING([--with-specs=SPECS],
   [add SPECS to driver command-line processing])],


Re: [PATCH] Allow new ISL/CLooG versions

2013-01-14 Thread Dominique Dhumieres
Jack,

Without the change for isl, I get at configure time:

-g -O2 -I/opt/mp/include -I/opt/mp/include
checking for version 0.10 of ISL... no
-g -O2 -I/opt/mp/include -I/opt/mp/include
checking for version 0.11 of ISL... (cached) no
configure: error: Unable to find a usable ISL.  See config.log for details.

and after it but without the change for CLooG

checking for version 0.10 of ISL... yes
checking for version 0.17.0 of CLooG... no
checking for version 0.18.0 of CLooG... (cached) no

I don't know if this support your claim or not.

Dominique


Re: [PATCH] Allow new ISL/CLooG versions

2013-01-14 Thread Jack Howarth
On Mon, Jan 14, 2013 at 09:28:53PM +0100, Dominique Dhumieres wrote:
> Jack,
> 
> Without the change for isl, I get at configure time:
> 
> -g -O2 -I/opt/mp/include -I/opt/mp/include
> checking for version 0.10 of ISL... no
> -g -O2 -I/opt/mp/include -I/opt/mp/include
> checking for version 0.11 of ISL... (cached) no

Exactly. If you look in config.log you will see that the first instance
of 'checking for version 0.10 of ISL' actually compiles the version check but
the second instance of 'checking for version 0.11 of ISL' is using the cached 
results from the first instance as indicated in the configure output. 
Your hack is just changing the first test from 0.10 to 0.11 so that it
succeeds and configure doesn't even run the second instance of the 
ISL_CHECK_VERSION().

> configure: error: Unable to find a usable ISL.  See config.log for details.
> 
> and after it but without the change for CLooG
> 
> checking for version 0.10 of ISL... yes
> checking for version 0.17.0 of CLooG... no
> checking for version 0.18.0 of CLooG... (cached) no
> 
> I don't know if this support your claim or not.
> 
> Dominique


[PATCH] Fix up ICE with reduction % (PR tree-optimization/55955)

2013-01-14 Thread Jakub Jelinek
Hi!

For *SHIFT_EXPR/*ROTATE_EXPR with VECTOR_TYPE types, optab_for_tree_code
requires us to decide if we want optab_vector or optab_scalar.  It is likely
not worth it to handle these four, they would fail soon anyway.

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

2013-01-14  Jakub Jelinek  

PR tree-optimization/55955
* tree-vect-loop.c (vectorizable_reduction): Give up early on
*SHIFT_EXPR and *ROTATE_EXPR codes.

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

--- gcc/tree-vect-loop.c.jj 2013-01-11 09:02:55.0 +0100
+++ gcc/tree-vect-loop.c2013-01-14 12:21:29.359018748 +0100
@@ -4776,6 +4776,17 @@ vectorizable_reduction (gimple stmt, gim
 {
   /* 4. Supportable by target?  */
 
+  if (code == LSHIFT_EXPR || code == RSHIFT_EXPR
+ || code == LROTATE_EXPR || code == RROTATE_EXPR)
+   {
+ /* Shifts and rotates are only supported by vectorizable_shifts,
+not vectorizable_reduction.  */
+  if (dump_enabled_p ())
+   dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
+"unsupported shift or rotation.");
+ return false;
+   }
+
   /* 4.1. check support for the operation in the loop  */
   optab = optab_for_tree_code (code, vectype_in, optab_default);
   if (!optab)
--- gcc/testsuite/gcc.c-torture/compile/pr55955.c.jj2013-01-14 
12:23:28.273324350 +0100
+++ gcc/testsuite/gcc.c-torture/compile/pr55955.c   2013-01-14 
12:23:14.0 +0100
@@ -0,0 +1,12 @@
+/* PR tree-optimization/55955 */
+
+int b;
+
+void
+foo (int x)
+{
+  int a;
+  for (a = x; a < 2; a++)
+for (b = 0; b < 2; b++)
+  *(unsigned short *) 0x10UL %= 46;
+}

Jakub


[PATCH] Handle -fwrapv -ftrapv (PR tree-optimization/48766)

2013-01-14 Thread Jakub Jelinek
Hi!

With this patch, -fno-[wt]rapv cancels corresponding -f[wt]rapv if any as
before, and later -f[wt]rapv disables -f[tw]rapv, which is IMHO better
behavior than if we use Negative(f[tw]rapv) on f[wt]rapv in common.opt.

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

2013-01-14  Jakub Jelinek  

PR tree-optimization/48766
* opts.c (common_handle_option): For -fwrapv disable -ftrapv, for
-ftrapv disable -fwrapv.

--- gcc/opts.c.jj   2013-01-11 09:02:48.0 +0100
+++ gcc/opts.c  2013-01-14 15:06:54.822968095 +0100
@@ -1755,6 +1755,16 @@ common_handle_option (struct gcc_options
   /* No-op. Used by the driver and passed to us because it starts with f.*/
   break;
 
+case OPT_fwrapv:
+  if (value)
+   opts->x_flag_trapv = 0;
+  break;
+
+case OPT_ftrapv:
+  if (value)
+   opts->x_flag_wrapv = 0;
+  break;
+
 default:
   /* If the flag was handled in a standard way, assume the lack of
 processing here is intentional.  */

Jakub


PING: gcc.target/arm: skip 5 tests for flag conflicts

2013-01-14 Thread Janis Johnson
Richard,

Back in September I submitted a patch to fix five ARM tests in
 .

You responded in < http://gcc.gnu.org/ml/gcc-patches/2012-10/msg00972.html>
and I answered your questions in a reply.

The first of the modified tests doesn't need to be changed, at least for
the sets of flags with which I usually test, but the others all conflict
with some of my multilib flags.  Note that the tests will be run with
the specified options for a default multilib, or one that doesn't use
any of the same options that are needed for the multilib.

Can I check those in now?

Janis


PING: replace gcc.target/arm/ftest-*.c with compile-only tests

2013-01-14 Thread Janis Johnson
Richard,

In December I submitted a patch to replace ftest*.c in gcc.target/arm with
compile-only tests: .
There has been no response to the patch.

One reason for the replacement is that the arch_v*_multilib effective target
checks don't do what they're supposed to do and sometimes cause the simulator
and QEMU to hang, as described in PR testsuite/55780.

Please review the patch or encourage someone to fix the effective target
checks.

Janis


Re: [patch, Fortran] PR 55806 - Inefficient ANY with array constructors

2013-01-14 Thread Thomas Koenig

Am 14.01.2013 14:29, schrieb Mikael Morin:

Le 13/01/2013 23:14, Thomas Koenig a écrit :



OK for trunk?


OK with the changes suggested above. Thanks.


Committed as rev. 195179 with your changes.

Thanks a lot for the thorough review!

Thomas



Re: [PATCH] Remove unnecessaily included limits.h in libgcc2.c

2013-01-14 Thread Matthias Klose
Am 04.01.2013 20:01, schrieb Wookey:
> I filed http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55743 (my first
> upstream gcc bug so be gentle :-)
> 
> Details are there but the short version is that the limits.h inclusion
> in libgcc2.c is now a relic because the constants that it brings
> in are no longer used (since
> http://repo.or.cz/w/official-gcc.git/blobdiff/49f0f270673c4512c11f72a038b84c321ae5534a..7429c938827aa98bf3b02c4ac89510f4d28ef0b1:/gcc/libgcc2.c
> )
> 
> And this inclusion can break --without-headers bootstrapping (which is
> how I noticed it).
> 
> Doko poked me to send the patch to this list for consideration for
> inclusion in trunk.

The --without-headers build failures is unrelated.  To catch this
mis-configuration I did propose a patch in
http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00743.html

I think the patch itself is correct.  However

 - please submit your patch against trunk, and state that you
   did test the patch against trunk (of course, after testing it)

 - please provide a ChangeLog entry

 - thanks for your reference to the repo.or.cz repo, however it
   would be good to reference a GCC commit.
   looks like Alexandre Oliva did commit this without removing
   the unneeded bits in r39365.

  Matthias




Re: testsuite: missing or wrong dg-* directives?

2013-01-14 Thread Harald Anlauf

On 01/14/13 00:10, Manfred Schwarb wrote:

Am 13.01.2013 21:30, schrieb Harald Anlauf:

On 01/12/13 22:02, Mikael Morin wrote:

Le 08/01/2013 22:32, Harald Anlauf a écrit :

On 12/28/12 21:49, Harald Anlauf wrote:

Hello all,

is there a default directive that is assumed when the testsuite is
run?

Running an "fgrep -L" on the fortran testsuite, I found several files
that are missing either dg-do compile or run.

I also found a funny typo in gomp/appendix-a/a.11.2.f90
! { do-do compile }




There are several other oddities: d_g-final, braces have to be separated
by spaces.


Looking at the generated dump, tt appears that the occurence of
"d_g-final" is just some left-over junk and can be removed safely,
see below.  Maybe the author (Tobias B.) knows?


Not sure about the double braces in lto, I guess they act simply as
single braces.

class_array_10.f03:! { dg-do compile}
coarray_lib_token_4.f90:! { d_g-final { scan-tree-dump-times "bar
\\(&parm.\[0-9\]+, caf_token.\[0-9\]+, \\(\\(integer\\(kind=.\\)
parm.\[0-9\]+.data - \\(integer\\(kind=.\\)\\) x.\[0-9\]+\\) \\+
caf_offset.\[0-9\]+\\);" 1 "original" } }
continuation_9.f90:! { dg-warning "not allowed by itself in line 3" ""
{target "*-*-*"} 0 }
continuation_9.f90:! { dg-warning "not allowed by itself in line 4" ""
{target "*-*-*"} 0 }
continuation_9.f90:! { dg-warning "not allowed by itself in line 5" ""
{target "*-*-*"} 0 }
extends_11.f03:! { dg-final { scan-tree-dump-times "
+recruit\\.service\\.education\\.person\\.ss =" 8 "original"} }
lto/20091016-1_0.f90:! { dg-lto-options {{-flto -g -fPIC -r -nostdlib}
{-O -flto -g -fPIC -r -nostdlib}} }
lto/20100110-1_0.f90:! { dg-lto-options {{ -O1 -flto }} }
lto/pr41521_0.f90:! { dg-lto-options {{-g -flto} {-g -O -flto}} }
lto/pr46036_0.f90:! { dg-lto-options {{ -O -flto -ftree-vectorize }} }
lto/pr46629_0.f90:! { dg-lto-options {{ -O2 -flto -ftree-vectorize
-march=x86-64 }} { target i?86-*-* x86_64-*-* } }
lto/pr46629_0.f90:! { dg-lto-options {{ -O2 -flto -ftree-vectorize }} }
lto/pr46911_0.f:! { dg-lto-options {{ -O2 -flto -g }} }
lto/pr47839_0.f90:! { dg-lto-options {{ -g -flto }} }
move_alloc_13.f90:! { dg-do run}
structure_constructor_11.f90:! { dg-do run}
tab_continuation.f:! { dg-warning "Nonconforming tab character in column
1 of line 10" "Nonconforming tab" {target "*-*-*"} 0 }
tab_continuation.f:! { dg-warning "Nonconforming tab character in column
1 of line 11" "Nonconforming tab" {target "*-*-*"} 0 }
tab_continuation.f:! { dg-warning "Nonconforming tab character in column
1 of line 8" "Nonconforming tab" {target "*-*-*"} 0 }
tab_continuation.f:! { dg-warning "Nonconforming tab character in column
1 of line 9" "Nonconforming tab" {target "*-*-*"} 0 }
vect/vect-2.f90:! { dg-final { scan-tree-dump-times "Alignment of access
forced using versioning." 3 "vect" {target { vect_no_align || { { !
vector_alignment_reachable  } && { ! vect_hw_misalign } } } } } }
vect/vect-3.f90:! { dg-final { scan-tree-dump-times "Alignment of access
forced using peeling" 1 "vect" { xfail { vect_no_align || {!
vector_alignment_reachable}} } } }
vect/vect-3.f90:! { dg-final { scan-tree-dump-times "Alignment of access
forced using versioning" 1 "vect" { target { {! vect_no_align} && { {!
vector_alignment_reachable} && {! vect_hw_misalign} } } } } }
vect/vect-3.f90:! { dg-final { scan-tree-dump-times "Vectorizing an
unaligned access" 1 "vect" { xfail { { vect_no_align } || { !
vector_alignment_reachable} } } } }
vect/vect-3.f90:! { dg-final { scan-tree-dump-times "Vectorizing an
unaligned access" 2 "vect" { target { {! vect_no_align} && { {!
vector_alignment_reachable} && {! vect_hw_misalign} } } } } }
vect/vect-4.f90:! { dg-final { scan-tree-dump-times "Alignment of access
forced using peeling" 1 "vect" { xfail { { vect_no_align } || {!
vector_alignment_reachable} } } } }
vect/vect-4.f90:! { dg-final { scan-tree-dump-times "Vectorizing an
unaligned access" 1 "vect" { xfail { { vect_no_align } || {!
vector_alignment_reachable} } } } }
vect/vect-4.f90:! { dg-final { scan-tree-dump-times "Vectorizing an
unaligned access" 2 "vect" { target { {! vector_alignment_reachable} &&
{! vect_hw_misalign} } } } }
vect/vect-5.f90:! { dg-final { scan-tree-dump-times "Alignment of access
forced using peeling" 1 "vect" { xfail { vect_no_align || {!
vector_alignment_reachable} } } } }
vect/vect-5.f90:! { dg-final { scan-tree-dump-times "Alignment of access
forced using versioning." 1 "vect" { target { {!
vector_alignment_reachable} && {! vect_hw_misalign} } } } }
warning-directive-2.F90:! { dg-message "some warnings being treated as
errors" "" {target "*-*-*"} 0 }


cheers,
Manfred



Attached there is a partial patch for the obvious parts, plus other
missed cases (missing options).  No failures, just a few more passes
from the fixed dg-do run's.

2013-01-14  Manfred Schwarb  
Harald Anlauf  

* gfortran.dg/bounds_check_4.f90: Add dg-options "-fbounds-check".
* gfortran.dg/bounds_check_5.f90: Likewise.
* gfort

Re: [PATCH] Handle -fwrapv -ftrapv (PR tree-optimization/48766)

2013-01-14 Thread Joseph S. Myers
On Mon, 14 Jan 2013, Jakub Jelinek wrote:

> Hi!
> 
> With this patch, -fno-[wt]rapv cancels corresponding -f[wt]rapv if any as
> before, and later -f[wt]rapv disables -f[tw]rapv, which is IMHO better
> behavior than if we use Negative(f[tw]rapv) on f[wt]rapv in common.opt.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> 2013-01-14  Jakub Jelinek  
> 
>   PR tree-optimization/48766
>   * opts.c (common_handle_option): For -fwrapv disable -ftrapv, for
>   -ftrapv disable -fwrapv.

OK.

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


[testsuite] skip ARM tests fma.c and fma-sp.c for conflicting options

2013-01-14 Thread Janis Johnson
The options specified for gcc.target/arm/fma.c and fma-sp.c can conflict
with several multilib options.  This patch skips the tests for multilibs
with conflicting options, and it adds option "-mfloat-abi=hard" which is
needed for the test.

OK for trunk?

Janis
2013-01-14  Janis Johnson  

* gcc.target/arm/fma.c: Skip for conflicting multilib options.
* gcc.target/arm/fma-sp.c: Likewise.

Index: gcc.target/arm/fma.c
===
--- gcc.target/arm/fma.c(revision 195178)
+++ gcc.target/arm/fma.c(working copy)
@@ -1,5 +1,9 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -mcpu=cortex-a15 -mfpu=vfpv4" } */
+/* { dg-skip-if "avoid conflicts with multilib options" { ! arm_thumb2_ok } { 
"-mthumb" } { "" } } */
+/* { dg-skip-if "avoid conflicts with multilib options" { *-*-* } { "-mcpu=*" 
} { "-mcpu=cortex-a15" } } */
+/* { dg-skip-if "avoid conflicts with multilib options" { *-*-* } { "-mfpu=*" 
} { "-mfpu=vfpv4" } } */
+/* { dg-skip-if "avoid conflicts with multilib options" { *-*-* } { 
"-mfloat-abi=*" } { "-mfloat-abi=hard" } } */
+/* { dg-options "-O2 -mcpu=cortex-a15 -mfpu=vfpv4 -mfloat-abi=hard" } */
 
 #include "fma.h"
 
Index: gcc.target/arm/fma-sp.c
===
--- gcc.target/arm/fma-sp.c (revision 195178)
+++ gcc.target/arm/fma-sp.c (working copy)
@@ -1,5 +1,9 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mthumb" } */
+/* { dg-skip-if "avoid conflicts with multilib options" { ! arm_thumb2_ok } { 
"-march=*" } { "" } } */
+/* { dg-skip-if "avoid conflicts with multilib options" { *-*-* } { "-mcpu=*" 
} { "-mcpu=cortex-m4" } } */
+/* { dg-skip-if "avoid conflicts with multilib options" { *-*-* } { "-mfpu=*" 
} { "-mfpu=fpv4-sp-d16" } } */
+/* { dg-skip-if "avoid conflicts with multilib options" { *-*-* } { 
"-mfloat-abi=*" } { "-mfloat-abi=hard" } } */
+/* { dg-options "-O2 -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mthumb 
-mfloat-abi=hard" } */
 
 #include "fma.h"
 


[testsuite] fix ARM test gcc.target/arm/neon-vld1_dupQ.c

2013-01-14 Thread Janis Johnson
Test gcc.target/arm/neon-vld1_dupQ.c started failing with r194594, a C
front end change that causes the test to get warnings.  The test passes
local variables of type int64x1_t to functions declared with arguments
of type int64_t.  This patch casts the values passed to those arguments.
It's possible that the patch invalidates the intent of the test, so I've
copied the test's author.

OK for trunk?

Janis


[patch] PR55982 Fix buglet in __strncat_chk

2013-01-14 Thread Paul Pluzhnikov
Greetings,

In libssp/strncat-chk.c, the loop was unrolled 5 times (apparently by
accident).


Ok for trunk?

Thanks,
--
Paul Pluzhnikov

2013-01-14  Paul Pluzhnikov  

PR 55982
* strncat-chk.c (__strncat_chk): Fix loop unroll.


Index: libssp/strncat-chk.c
===
--- libssp/strncat-chk.c(revision 195181)
+++ libssp/strncat-chk.c(working copy)
@@ -87,12 +87,6 @@ __strncat_chk (char *__restrict__ dest, const char
   *++dest = c;
   if (c == '\0')
 return s;
-  if (slen-- == 0)
-__chk_fail ();
-  c = *src++;
-  *++dest = c;
-  if (c == '\0')
-return s;
 } while (--n4 > 0);
   n &= 3;
 }


[testsuite] remove ARM big-endian from some vect effective targets

2013-01-14 Thread Janis Johnson
As described in PR testsuite/54622, lots of tests from gcc.dg/vect fail
for big-endian ARM, apparently with bits of vectorization support
disabled here and there.  This patch removes big-endian ARM from

check_effective_target_vect_perm_byte
check_effective_target_vect_perm_short
check_effective_target_vect_widen_mult_qi_to_hi_pattern,
check_effective_target_vect64

and makes check_effective_target_vect_widen_sum_qi_to_hi return 1 for
ARM.  For each individual change there are tests that no longer fail
and no tests that regress.

Tested for arm-none-eabi with several multilibs; OK for trunk?

Janis
2013-01-15  Janis Johnson  

PR testsuite/54622

* lib/target-supports.exp (check_effective_target_vect_perm_byte,
check_effective_target_vect_perm_short,
check_effective_target_vect_widen_mult_qi_to_hi_pattern,
check_effective_target_vect64): Return 0 for big-endian ARM.
(check_effective_target_vect_widen_sum_qi_to_hi): Return 1 for ARM.

Index: lib/target-supports.exp
===
--- lib/target-supports.exp (revision 195178)
+++ lib/target-supports.exp (working copy)
@@ -3082,7 +3082,8 @@
 verbose "check_effective_target_vect_perm_byte: using cached result" 2
 } else {
 set et_vect_perm_byte_saved 0
-if { [is-effective-target arm_neon_ok]
+if { ([is-effective-target arm_neon_ok]
+ && [is-effective-target arm_little_endian])
 || [istarget aarch64*-*-*]
 || [istarget powerpc*-*-*]
  || [istarget spu-*-*] } {
@@ -3105,7 +3106,8 @@
 verbose "check_effective_target_vect_perm_short: using cached result" 2
 } else {
 set et_vect_perm_short_saved 0
-if { [is-effective-target arm_neon_ok]
+if { ([is-effective-target arm_neon_ok]
+ && [is-effective-target arm_little_endian])
 || [istarget aarch64*-*-*]
 || [istarget powerpc*-*-*]
  || [istarget spu-*-*] } {
@@ -3175,6 +3177,7 @@
 } else {
 set et_vect_widen_sum_qi_to_hi_saved 0
if { [check_effective_target_vect_unpack] 
+|| [check_effective_target_arm_neon_ok]
 || [istarget ia64-*-*] } {
 set et_vect_widen_sum_qi_to_hi_saved 1
}
@@ -3282,7 +3285,9 @@
 } else {
 set et_vect_widen_mult_qi_to_hi_pattern_saved 0
 if { [istarget powerpc*-*-*]
-  || ([istarget arm*-*-*] && [check_effective_target_arm_neon_ok]) 
} {
+  || ([istarget arm*-*-*]
+ && [check_effective_target_arm_neon_ok]
+ && [check_effective_target_arm_little_endian]) } {
 set et_vect_widen_mult_qi_to_hi_pattern_saved 1
 }
 }
@@ -3307,7 +3312,9 @@
   || [istarget ia64-*-*]
   || [istarget i?86-*-*]
   || [istarget x86_64-*-*]
-  || ([istarget arm*-*-*] && [check_effective_target_arm_neon_ok]) 
} {
+  || ([istarget arm*-*-*]
+ && [check_effective_target_arm_neon_ok]
+ && [check_effective_target_arm_little_endian]) } {
 set et_vect_widen_mult_hi_to_si_pattern_saved 1
 }
 }
@@ -3914,7 +3921,9 @@
 verbose "check_effective_target_vect64: using cached result" 2
 } else {
 set et_vect64_saved 0
-if { ([istarget arm*-*-*] && [check_effective_target_arm_neon_ok]) } {
+if { ([istarget arm*-*-*]
+ && [check_effective_target_arm_neon_ok]
+ && [check_effective_target_arm_little_endian]) } {
set et_vect64_saved 1
 }
 }


Re: [RFA/dwarf] Add DW_AT_use_GNAT_descriptive_type flag for Ada units.

2013-01-14 Thread Joel Brobecker
Ping?

Thank you!

On Tue, Jan 08, 2013 at 07:24:14AM -0500, Joel Brobecker wrote:
> Hello,
> 
> I just noticed that part of the proposal we made for...
> http://gcc.gnu.org/wiki/DW_AT_GNAT_descriptive_type
> 
> ... got missed in the patch that got checked in:
> http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00099.html
> 
> In particular, we're missing the second part, where we are
> expected to generate a DW_AT_use_GNAT_descriptive_type flag
> in the CU in order to tell the consumers that we are providing
> the descriptive type.
> 
> gcc/ChangeLog:
> 
> * dwarf2out.c (gen_compile_unit_die): Add
> DW_AT_use_GNAT_descriptive_type attribute for Ada units.
> 
> Tested on x86_64-linux, no regression. I also tested against
> the GDB testsuite, before and after, and no regression.  This
> is expected, since GDB currently does not look for this attribute
> (but I would like it to).
> 
> OK to apply for HEAD and 4.7?
> 
> Thanks,
> -- 
> Joel
> 
> ---
>  gcc/dwarf2out.c |4 
>  1 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
> index a865250..8117ce9 100644
> --- a/gcc/dwarf2out.c
> +++ b/gcc/dwarf2out.c
> @@ -18940,6 +18940,10 @@ gen_compile_unit_die (const char *filename)
>/* The default DW_ID_case_sensitive doesn't need to be specified.  */
>break;
>  }
> +
> +  if (language == DW_LANG_Ada95)
> +add_AT_flag (die, DW_AT_use_GNAT_descriptive_type, 1);
> +
>return die;
>  }
>  
> -- 
> 1.7.0.4

-- 
Joel


Re: [RFC PATCH] Implementing ifunc target hook

2013-01-14 Thread Maxim Kuvyrkov
On 15/01/2013, at 4:55 AM, Alexander Ivchenko wrote:

> thank you very much for your review!
> 
> I fixed the arm build and all other issues that you raised.
> 
> the patch is attached. Bootstrap and tested on x86-64 linux


The patch is OK with the cleanups mentioned below (no need to resubmit for 
review).  Unfortunately, you will have to wait for Stage 1 to commit your patch.


> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -636,6 +636,11 @@ case ${target} in
>native_system_header_dir=/include
>;;
>esac
> +  case $target in
> +*linux*)
> +  tm_p_file="${tm_p_file} linux-protos.h"
> +  ;;
> +  esac
># glibc / uclibc / bionic switch.
># uclibc and bionic aren't usable for GNU/Hurd and neither for GNU/k*BSD.
>case $target in

Can we merge this above hunk into subsequent "case $target" statement ... 

> @@ -661,8 +666,10 @@ case ${target} in
># Add Android userspace support to Linux targets.
>case $target in
>  *linux*)
> +  tmake_file="${tmake_file} t-linux-android"
>tm_file="$tm_file linux-android.h"
>extra_options="$extra_options linux-android.opt"
> +  extra_objs="$extra_objs linux-android.o"
>;;
>esac

... here?

># Enable compilation for Android by default for *android* targets.
> @@ -863,7 +870,9 @@ arm*-*-netbsdelf*)
>   tmake_file="${tmake_file} arm/t-arm"
>   ;;
>  arm*-*-linux-*)  # ARM GNU/Linux with ELF
> + tmake_file="${tmake_file} t-linux-android"

Merge this with tmake_file= setting a couple of lines down.  Put 
t-linux-android last on the line.

>   tm_file="dbxelf.h elfos.h gnu-user.h linux.h linux-android.h 
> glibc-stdint.h arm/elf.h arm/linux-gas.h arm/linux-elf.h"
> + extra_objs="$extra_objs linux-android.o"

Please push extra_objs= setting a couple of lines down so that addition of 
t-linux-android and linux-android.o are side-by-side.

>   case $target in
>   arm*b-*-linux*)
>   tm_defines="${tm_defines} TARGET_BIG_ENDIAN_DEFAULT=1"
> diff --git a/gcc/config/linux-android.c b/gcc/config/linux-android.c
> new file mode 100644
> index 000..f3d82a5
> --- /dev/null
> +++ b/gcc/config/linux-android.c
> @@ -0,0 +1,34 @@
> +/* Functions for Linux Android as target machine for GNU C compiler.
> +   Copyright (C) 2001, 2002, 2003, 2004, 2005, 2007, 2008, 2010, 2011,
> +   2012, 2013.

Should be "Copyright (C) 2013."  The copyright dates start with the year in 
which  a file was added.

Also, for any file that your changes touch please add 2013 to the list of 
copyright years.  This is an annoying chore that committers have to do at the 
beginning of each year.

> diff --git a/gcc/config/linux-protos.h b/gcc/config/linux-protos.h
> new file mode 100644
> index 000..aae1d28
> --- /dev/null
> +++ b/gcc/config/linux-protos.h
> @@ -0,0 +1,22 @@
> +/* Prototypes.
> +   Copyright (C) 2001, 2002, 2003, 2004, 2005, 2007, 2008, 2010, 2011,
> +   2012, 2013

"Copyright (C) 2013."

> --- /dev/null
> +++ b/gcc/config/t-linux-android
> @@ -0,0 +1,23 @@
> +# Copyright (C) 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 
> 2013

"Copyright (C) 2013."

Thanks!

--
Maxim Kuvyrkov



Fwd: [Bug fortran/54286] [4.8 Regression] Accepts invalid proc-pointer assignments involving proc-ptr function result

2013-01-14 Thread Paul Richard Thomas
Dear,

I missed the null interface case in the fix for PR54286.  The fix is
'obvious' and 'safe'.

Thanks to Dominique for identifying the problem and the fix.

Cheers

Paul

Author: pault
Date: Tue Jan 15 05:29:01 2013
New Revision: 195185

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195185
Log:
2013-01-15  Paul Thomas  

PR fortran/54286
* expr.c (gfc_check_pointer_assign): Check for presence of
's2' before using it.

2013-01-15  Paul Thomas  

PR fortran/54286
* gfortran.dg/proc_ptr_result_8.f90 : Add module 'm' to check
case where interface is null.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/proc_ptr_result_8.f90


Re: [patch] PR55982 Fix buglet in __strncat_chk

2013-01-14 Thread Jakub Jelinek
On Mon, Jan 14, 2013 at 04:57:42PM -0800, Paul Pluzhnikov wrote:
> In libssp/strncat-chk.c, the loop was unrolled 5 times (apparently by
> accident).

> 2013-01-14  Paul Pluzhnikov  
> 
> PR 55982
> * strncat-chk.c (__strncat_chk): Fix loop unroll.

Ok.

Jakub