Re: [Patch, i386] Avoid LCP stalls (issue5975045)

[Uros Bizjak]

Hello!

> New patch to avoid LCP stalls based on feedback from earlier patch. I modified
> H.J.'s old patch to perform the peephole2 to split immediate moves to HImode
> memory. This is now enabled for Core2, Corei7 and Generic.

> 2012-04-04   Teresa Johnson  
>
>   * config/i386/i386.h (ix86_tune_indices): Add
>   X86_TUNE_LCP_STALL.
>   * config/i386/i386.md (move immediate to memory peephole2):
>   Add cases for HImode move when LCP stall avoidance is needed.
>   * config/i386/i386.c (initial_ix86_tune_features): Initialize
>   X86_TUNE_LCP_STALL entry.

   "optimize_insn_for_speed_p ()
-   && !TARGET_USE_MOV0
-   && TARGET_SPLIT_LONG_MOVES
-   && get_attr_length (insn) >= ix86_cur_cost ()->large_insn
+   && ((TARGET_LCP_STALL
+   && GET_MODE (operands[0]) == HImode)
+   || (!TARGET_USE_MOV0
+  && TARGET_SPLIT_LONG_MOVES
+  && get_attr_length (insn) >= ix86_cur_cost ()->large_insn))

Please change added condition to:

&& ((mode == HImode
&& TARGET_LCP_STALL)
   || (...))

Please also add H.J. as co-author of this change to ChangeLog.

OK with these changes.

Thanks,
Uros.

[PATCH] RX: Fix min instruction for unsigned variables

[Naveen H. S]

Hi,

Please find attached the patch "smin.patch" which fixes the issue for
unsigned values with "min" instruction. 
Currently, unsigned values greater than QI mode are converted into
signed values and hence generates wrong value.
The patch fixes the issue. 

Tested with rx-elf. No new regressions.

ChangeLog
2012-04-05  Naveen H.S  

* config/rx/rx.md (umin3): Allow const int
values in HImode.

Thanks & Regards,
Naveen



smin.patch
Description: smin.patch

Re: [lra] spilling general class pseudos into SSE regs instead of memory (a target hooks driven implementation)

[Ye Joey]

On Mon, Apr 2, 2012 at 10:11 PM, Vladimir Makarov  wrote:
> On 03/31/2012 01:38 AM, Ye Joey wrote:
>
> Yes, if you mean spilling in LRA.  But IRA can assign union of general and
> SSE classes to a pseudo if it is profitable.
Any chance for IRA not to do so, saying by introducing an option?

- Joey

Re: [PATCH 2/2] arm: add iwMMXt mmx-2.c test

[Ramana Radhakrishnan]

On 4 April 2012 19:35, Matt Turner  wrote:


>
>  gcc/testsuite/gcc.target/arm/mmx-2.c |  158 
> ++
>  1 files changed, 158 insertions(+), 0 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/arm/mmx-2.c
>
> diff --git a/gcc/testsuite/gcc.target/arm/mmx-2.c 
> b/gcc/testsuite/gcc.target/arm/mmx-2.c
> new file mode 100644
> index 000..603a63b
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/mmx-2.c
> @@ -0,0 +1,158 @@
> +/* { dg-do compile } */
> +/* { dg-skip-if "Test is specific to the iWMMXt" { arm*-*-* } { "-mcpu=*" } 
> { "-mcpu=iwmmxt" } } */
> +/* { dg-skip-if "Test is specific to the iWMMXt" { arm*-*-* } { "-mabi=*" } 
> { "-mabi=iwmmxt" } } */
> +/* { dg-skip-if "Test is specific to the iWMMXt" { arm*-*-* } { "-march=*" } 
> { "-march=iwmmxt" } } */
> +/* { dg-skip-if "Test is specific to ARM mode" { arm*-*-* } { "-mthumb" } { 
> "" } } */

How about simplifying this with a dg-require-effective-target
arm_arm_ok instead of doing
dg-require-effective-target arm32 and then skipping it for Thumb2 ?

Otherwise looks OK to me. Please don't commit any of these patches
till your copyright assignment is sorted -

Thanks,
Ramana

Re: [patch, fortran] Fix PR 52668, bogus warning for only list

[Tobias Burnus]

Thomas Koenig wrote:
> this fixes a 4.7/4.8 regression with a bogus warning for variables
> which were excluded from being imported by "use, only" if they
> were in a common block inside the module.
>
> Regression-tested. OK for trunk and for 4.7 after a few days?

OK and thanks for the patch.


> ! { dg-final { cleanup-modules "mm" } }

I think due to Bernhard's patch, this line is no longer needed.
Cf. http://gcc.gnu.org/ml/fortran/2012-03/msg00069.html and
the unreviewed patch at http://gcc.gnu.org/ml/fortran/2012-04/msg2.html

Tobias

Re: [C11-atomic] [patch] gimple atomic statements

[Richard Guenther]

On Wed, Apr 4, 2012 at 5:50 PM, Andrew MacLeod  wrote:
> On 04/04/2012 10:33 AM, Richard Guenther wrote:
>>
>> On Wed, Apr 4, 2012 at 3:28 PM, Andrew MacLeod
>>  wrote:
>> This is a WIP... that fntype fields is there for simplicity..   and no...
>> you can do a 1 byte atomic operation on a full word object if you want by
>>
>> Oh, so you rather need a size or a mode specified, not a "fntype"?
>
>
> yes, poorly named perhaps as I created things... its just a type node at the
> moment that indicates the size being operated on that I collected from the
> builtin in function.

Ok.  Remember that you should use non-tree things if you can in GIMPLE
land.  This probably means that both the size and the memmodel "operands"
should be

+ struct GTY(()) gimple_statement_atomic
+ {
+   /* [ WORD 1-8 ]  */
+   struct gimple_statement_with_memory_ops_base membase;
+
+   /* [ WORD 9 ] */
+   enum gimple_atomic_kind kind;
+
 enum gimple_atomic_memmodel memmodel;

 unsigned size;

and not be trees in the ops array.  Even more, both kind and memmodel
should probably go in membase.base.subcode

>> In the example you only ever use address operands (not memory operands)
>> to the GIMPLE_ATOMIC - is that true in all cases?  Is the result always
>> non-memory?
>
> The atomic address can be any arbitrary memory location... I haven't gotten
> to that yet.  its commonly just an address so I'm working with that first as
> proof of concept. When it gets something else it'll trap and I'll know :-)

Ok.  Please try to avoid memory operands and stick to address operands ;)
You can make tree-ssa-operands.c not consider ADDR_EXPRs in the
address operands, similar to the ADDR_EXPRs in MEM_REF operand zero.

> Results are always non-memory, other than the side effects of the atomic
> contents changing and having to up date the second parameter to the
> compare_exchange routine.  The generic routines for arbitary structures (not
> added in yet), actually just work with blocks of memory, but they are all
> handled by addresses and the functions themselves are typically void.  I was
> planning on folding them right into the existing atomic_kinds as well... I
> can recognize from the type that it wont map to a integral type.  I needed
> separate builtins in 4.7  for them since the parameter list was different.
>
>> I suppose the GIMPLE_ATOMICs are still optimization barriers for all
>> memory, not just that possibly referenced by them?
>
>
> yes, depending on the memory model used.  It can force synchronization with
> other CPUs/threads which will have the appearence of changing any shared
> memory location.  Various guarantees are made about whether those changes
> are visible to this thread after an atomic operation so we can't reuse
> shared values in those cases.  Various guarantees are made about what
> changes this thread has made are visible to other CPUs/threads at an atomic
> call as well, so that precludes moving stores downward in some models.
>
>>
>>> and during expansion to RTL, can trivially see that cmpxchg.2_4 is not
>>> used,
>>> and generate the really efficient compare and swap pattern which only
>>> produces a boolean result.
>>
>> I suppose gimple stmt folding could transform it as well?
>
> it could if I provided gimple statements for the 3 different forms of C&S. I
> was planning to just leave it this way since its the interface being forced
> by C++11 as well as C11... and then just emit the appropriate RTL for this
> one C&S type.  The RTL patterns are already defined for the 2 easy cases for
> the __sync routines. the third one was added for __atomic.  Its possible
> that the process of integrating the __sync routines with GIMPLE_ATOMIC will
> indicate its better to add those forms as atomic_kinds and then
> gimple_fold_stmt could take care of it as well.   Maybe that is just a good
> idea anyway...  I'll keep it in mind.
>
>
>>
>>>   if only cmpxchg.2_4 were used, we can generate
>>> the C&S pattern which only returns the result.  Only if we see both are
>>> actually used do we have to fall back to the much uglier pattern we have
>>> that produces both results.  Currently we always generate this pattern.
>>>
>>> Next, we have the C11 atomic type qualifier which needs to be
>>> implemented.
>>>  Every reference to this variable is going to have to be expanded into
>>> one
>>> or more atomic operations of some sort.  Yes, I probably could do that by
>>> emitting built-in functions, but they are a bit more unwieldy, its far
>>> simpler to just create gimple_statements.
>>
>> As I understand you first generate builtins anyway and then lower them?
>> Or are you planning on emitting those for GENERIC as well?  Remember
>> GENERIC is not GIMPLE, so you'd need new tree codes anyway ;)
>> Or do you plan to make __atomic integral part of GENERIC and thus
>> do this lowering during gimplification?
>
> I was actually thinking about doing it during gimplification... I hadnt
> gotten as far as figuring out what to do with t

[v3] Export std::_List_node_base for non-PIC code

[Rainer Orth]

As discussed in PR libstdc++/52689, no longer exporting
std::_List_node_base for non-PIC code breaks linking go1 on Solaris with
static libstdc++:

Undefined   first referenced
 symbol in file
_ZNSt15_List_node_base4swapERS_S0_  
/vol/gcc/lib/libppl_c.a(ppl_c_Pointset_Powerset_C_Polyhedron.o)
_ZNSt15_List_node_base4hookEPS_ /vol/gcc/lib/libppl_c.a(ppl_c_Polyhedron.o)
_ZNSt15_List_node_base6unhookEv 
/vol/gcc/lib/libppl_c.a(ppl_c_Pointset_Powerset_C_Polyhedron.o)
_ZNSt15_List_node_base8transferEPS_S0_ 
/vol/gcc/lib/libppl_c.a(ppl_c_Pointset_Powerset_C_Polyhedron.o)
ld: fatal: symbol referencing errors. No output written to go1

The following patch fixes this, bootstrapped without regressions on
i386-pc-solaris2.11, approved by Benjamin in the PR, installed on
mainline.

Rainer


2012-04-05  Rainer Orth  

Partially revert:
2012-03-28  Benjamin Kosnik  

PR libstdc++/52689
* src/c++98/compatibility-list.cc: Same.

# HG changeset patch
# Parent 5e498daa5c157ffd17681f8d800f6866eb837cf6
Export std::_List_node_base for non-PIC code

diff --git a/libstdc++-v3/src/c++98/compatibility-list.cc b/libstdc++-v3/src/c++98/compatibility-list.cc
--- a/libstdc++-v3/src/c++98/compatibility-list.cc
+++ b/libstdc++-v3/src/c++98/compatibility-list.cc
@@ -24,8 +24,6 @@
 
 #include 
 
-#ifdef PIC
-
 #ifndef _GLIBCXX_BEGIN_NAMESPACE_COMPAT
 # define _GLIBCXX_BEGIN_NAMESPACE_COMPAT
 #endif
@@ -146,5 +144,3 @@ _GLIBCXX_BEGIN_NAMESPACE_COMPAT
 _GLIBCXX_END_NAMESPACE_COMPAT
 
 } // namespace std
-
-#endif


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

Re: [PATCH] Fix PR18589

[Richard Guenther]

On Wed, Apr 4, 2012 at 9:15 PM, William J. Schmidt
 wrote:
> On Wed, 2012-04-04 at 15:08 +0200, Richard Guenther wrote:
>> On Wed, Apr 4, 2012 at 2:35 PM, William J. Schmidt
>>  wrote:
>> > On Wed, 2012-04-04 at 13:35 +0200, Richard Guenther wrote:
>> >> On Tue, Apr 3, 2012 at 10:25 PM, William J. Schmidt
>> >>  wrote:
>> >> >
>> >> >
>> >> > On Wed, 2012-03-28 at 15:57 +0200, Richard Guenther wrote:
>> >> >> On Tue, Mar 6, 2012 at 9:49 PM, William J. Schmidt
>> >> >>  wrote:
>> >> >> > Hi,
>> >> >> >
>> >> >> > This is a re-post of the patch I posted for comments in January to
>> >> >> > address http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18589.  The patch
>> >> >> > modifies reassociation to expose repeated factors from __builtin_pow*
>> >> >> > calls, optimally reassociate repeated factors, and possibly 
>> >> >> > reconstitute
>> >> >> > __builtin_powi calls from the results of reassociation.
>> >> >> >
>> >> >> > Bootstrapped and passes regression tests for powerpc64-linux-gnu.  I
>> >> >> > expect there may need to be some small changes, but I am targeting 
>> >> >> > this
>> >> >> > for trunk approval.
>> >> >> >
>> >> >> > Thanks very much for the review,
>> >> >>
>> >> >> Hmm.  How much work would it be to extend the reassoc 'IL' to allow
>> >> >> a repeat factor per op?  I realize what you do is all within what 
>> >> >> reassoc
>> >> >> already does though ideally we would not require any GIMPLE IL changes
>> >> >> for building up / optimizing the reassoc IL but only do so when we 
>> >> >> commit
>> >> >> changes.
>> >> >>
>> >> >> Thanks,
>> >> >> Richard.
>> >> >
>> >> > Hi Richard,
>> >> >
>> >> > I've revised my patch along these lines; see the new version below.
>> >> > While testing it I realized I could do a better job of reducing the
>> >> > number of multiplies, so there are some changes to that logic as well,
>> >> > and a couple of additional test cases.  Regstrapped successfully on
>> >> > powerpc64-linux.
>> >> >
>> >> > Hope this looks better!
>> >>
>> >> Yes indeed.  A few observations though.  You didn't integrate
>> >> attempt_builtin_powi
>> >> with optimize_ops_list - presumably because it's result does not really 
>> >> fit
>> >> the single-operation assumption?  But note that undistribute_ops_list and
>> >> optimize_range_tests have the same issue.  Thus, I'd have prefered if
>> >> attempt_builtin_powi worked in the same way, remove the parts of the
>> >> ops list it consumed and stick an operand for its result there instead.
>> >> That should simplify things (not having that special powi_result) and
>> >> allow for multiple "powi results" in a single op list?
>> >
>> > Multiple powi results are already handled, but yes, what you're
>> > suggesting would simplify things by eliminating the need to create
>> > explicit multiplies to join them and the cached-multiply results
>> > together.  Sounds reasonable on the surface; it just hadn't occurred to
>> > me to do it this way.  I'll have a look.
>> >
>> > Any other major concerns while I'm reworking this?
>>
>> No, the rest looks fine (you should not need to repace
>> -fdump-tree-reassoc-details
>> with -fdump-tree-reassoc1-details -fdump-tree-reassoc2-details in the first
>> testcase).
>
> Unfortunately this seems to be necessary if I name the two passes
> "reassoc1" and "reassoc2".  If I try to name both of them "reassoc" I
> get failures in other tests like gfortran.dg/reassoc_4, where
> -fdump-tree-reassoc1 doesn't work.  Unless I'm missing something
> obvious, I think I need to keep that change.

Hm, naming them "reassoc1" and "reassoc2" is a hack.  Naming both
"reassoc" will not trigger re-naming them to reassoc1 and reassoc2
I think.  How ugly.  Especially that -fdump-tree-reassoc will no longer
work.  Maybe instead of using two pass structs resort to using
the existing hack with using first_pass_instance and TODO_mark_first_instance.

> Frankly I was surprised and relieved that there weren't more tests that
> used the generic -fdump-tree-reassoc.
>
> Thanks,
> Bill
>>
>> Thanks,
>> Richard.
>>
>> > Thanks,
>> > Bill
>> >>
>> >> Thanks,
>> >> Richard.
>> >>
>> >
>> >
>>
>
>

Re: [PATCH] Fix PR52614

[Richard Guenther]

On Thu, Apr 5, 2012 at 6:22 AM, Mike Stump  wrote:
> On Apr 4, 2012, at 7:56 PM, William J. Schmidt wrote:
>> There seems to be tacit agreement that the vector tests should use
>> -fno-common on all targets to avoid the recent spate of failures (see
>> discussion in 52571 and 52603).
>
>> OK for trunk?
>
> Ok.  Any other solution I think will be real work and we shouldn't loose the 
> testing between now and then by not having the test cases working.

Ian, you are the "source" of all of these problems.  While I did not notice
any degradations in SPEC (on x86) with handling commons "correctly"
now, the fact
that our testsuite needs -fno-common to make things vectorizable shows
that users might be impacted negatively by this, which is only a real problem
in corner cases.  Why can the link editor not promote the definitions alignment
when merging with a common with bigger alignment?

Richard.

[PATCH][1/3] Release SSA names properly

[Richard Guenther]

This releases SSA names properly in some places.

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

Richard.

2012-02-10  Richard Guenther  

* tree-nrv.c (tree_nrv): Release VDEFs.
* tree-sra.c (sra_modify_constructor_assign): Likewise.
(sra_modify_assign): Likewise.
* tree-vect-stmts.c (vect_remove_stores): Likewise.
* tree-vect-loop.c (vect_transform_loop): Likewise.
* tree-ssa-dom.c (optimize_stmt): Likewise.
* tree-vect-slp.c (vect_schedule_slp): Likewise.
* tree-ssa-math-opts.c (execute_cse_sincos): Likewise.

Index: gcc/tree-nrv.c
===
*** gcc/tree-nrv.c.orig 2012-04-04 14:57:38.0 +0200
--- gcc/tree-nrv.c  2012-04-04 15:17:13.331595050 +0200
*** tree_nrv (void)
*** 244,249 
--- 244,250 
{
  unlink_stmt_vdef (stmt);
  gsi_remove (&gsi, true);
+ release_defs (stmt);
}
  else
{
Index: gcc/tree-sra.c
===
*** gcc/tree-sra.c.orig 2012-04-04 14:57:38.0 +0200
--- gcc/tree-sra.c  2012-04-04 15:17:13.334595082 +0200
*** sra_modify_constructor_assign (gimple *s
*** 2821,2826 
--- 2821,2827 
{
  unlink_stmt_vdef (*stmt);
  gsi_remove (gsi, true);
+ release_defs (*stmt);
  return SRA_AM_REMOVED;
}
else
*** sra_modify_constructor_assign (gimple *s
*** 2844,2849 
--- 2845,2851 
init_subtree_with_zero (acc, gsi, false, loc);
unlink_stmt_vdef (*stmt);
gsi_remove (gsi, true);
+   release_defs (*stmt);
return SRA_AM_REMOVED;
  }
else
*** sra_modify_assign (gimple *stmt, gimple_
*** 3094,3099 
--- 3096,3102 
  gsi_next (gsi);
  unlink_stmt_vdef (*stmt);
  gsi_remove (&orig_gsi, true);
+ release_defs (*stmt);
  sra_stats.deleted++;
  return SRA_AM_REMOVED;
}
*** sra_modify_assign (gimple *stmt, gimple_
*** 3114,3119 
--- 3117,3123 
  gcc_assert (*stmt == gsi_stmt (*gsi));
  unlink_stmt_vdef (*stmt);
  gsi_remove (gsi, true);
+ release_defs (*stmt);
  sra_stats.deleted++;
  return SRA_AM_REMOVED;
}
Index: gcc/tree-vect-stmts.c
===
*** gcc/tree-vect-stmts.c.orig  2012-04-04 14:57:38.0 +0200
--- gcc/tree-vect-stmts.c   2012-04-04 15:17:13.337595115 +0200
*** vect_remove_stores (gimple first_stmt)
*** 5653,5659 
--- 5653,5661 
next = STMT_VINFO_RELATED_STMT (stmt_info);
/* Free the attached stmt_vec_info and remove the stmt.  */
next_si = gsi_for_stmt (next);
+   unlink_stmt_vdef (next);
gsi_remove (&next_si, true);
+   release_defs (next);
free_stmt_vec_info (next);
next = tmp;
  }
Index: gcc/tree-vect-loop.c
===
*** gcc/tree-vect-loop.c.orig   2012-04-04 14:57:38.0 +0200
--- gcc/tree-vect-loop.c2012-04-04 15:17:13.338595125 +0200
*** vect_transform_loop (loop_vec_info loop_
*** 5476,5483 
  else
{
  /* Free the attached stmt_vec_info and remove the stmt.  */
! free_stmt_vec_info (gsi_stmt (si));
  gsi_remove (&si, true);
  continue;
}
}
--- 5476,5486 
  else
{
  /* Free the attached stmt_vec_info and remove the stmt.  */
! gimple store = gsi_stmt (si);
! free_stmt_vec_info (store);
! unlink_stmt_vdef (store);
  gsi_remove (&si, true);
+ release_defs (store);
  continue;
}
}
Index: gcc/tree-ssa-dom.c
===
*** gcc/tree-ssa-dom.c.orig 2012-04-04 15:02:16.0 +0200
--- gcc/tree-ssa-dom.c  2012-04-04 15:17:52.463010484 +0200
*** optimize_stmt (basic_block bb, gimple_st
*** 2301,2306 
--- 2301,2307 
  if (dump_file && (dump_flags & TDF_DETAILS))
fprintf (dump_file, "  Flagged to clear EH edges.\n");
}
+ release_defs (stmt);
  return;
}
}
Index: gcc/tree-vect-slp.c
===
*** gcc/tree-vect-slp.c.orig2012-04-04 14:57:38.0 +0200
--- gcc/tree-vect-slp.c 2012-04-04 15:17:13.341595156 +0200
*** vect_schedule_slp (loop_vec_info loop_vi
*** 3043,3049 
--- 3

[PATCH] Compact SSA version namespace when releasing the freelist

[Richard Guenther]

Currently we release the memory for released SSA names (which we keep
around on a freelist, mainly to try to keep the SSA version namespace
dense) after early optimizations.  This has the negative impact
(as documented) of permanently establishing holes in the SSA version
namespace.  The following patch fixes this in a simple way.

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

If you build fold-const.c with -O2 the distribution of released
ssa names / removed holes is as follows:

43 release_ssa "SSA names released" 34900
43 release_ssa "SSA name holes removed" 34900

which means we never have "trailing" released SSA names, all SSA
names on the freelist are for holes.  The following is the
distribution over releases happening per function:

43 release_ssa "SSA name holes removed == 0" 16
43 release_ssa "SSA name holes removed == 1" 13
43 release_ssa "SSA name holes removed == 2" 13
43 release_ssa "SSA name holes removed == 3" 6
43 release_ssa "SSA name holes removed == 4" 12
43 release_ssa "SSA name holes removed == 5" 3
43 release_ssa "SSA name holes removed == 6" 4
43 release_ssa "SSA name holes removed == 7" 5
43 release_ssa "SSA name holes removed == 8" 4
43 release_ssa "SSA name holes removed == 9" 4
43 release_ssa "SSA name holes removed == 10" 4
43 release_ssa "SSA name holes removed == 11" 4
43 release_ssa "SSA name holes removed == 13" 1
43 release_ssa "SSA name holes removed == 14" 5
43 release_ssa "SSA name holes removed == 16" 4
43 release_ssa "SSA name holes removed == 17" 1
43 release_ssa "SSA name holes removed == 18" 4
43 release_ssa "SSA name holes removed == 19" 1
43 release_ssa "SSA name holes removed == 20" 3
43 release_ssa "SSA name holes removed == 22" 1
43 release_ssa "SSA name holes removed == 23" 4
43 release_ssa "SSA name holes removed == 24" 1
43 release_ssa "SSA name holes removed == 26" 2
43 release_ssa "SSA name holes removed == 27" 1
43 release_ssa "SSA name holes removed == 28" 1
43 release_ssa "SSA name holes removed == 30" 2
43 release_ssa "SSA name holes removed == 32" 2
43 release_ssa "SSA name holes removed == 33" 3
43 release_ssa "SSA name holes removed == 34" 2
43 release_ssa "SSA name holes removed == 35" 1
43 release_ssa "SSA name holes removed == 36" 1
43 release_ssa "SSA name holes removed == 37" 1
43 release_ssa "SSA name holes removed == 39" 1
43 release_ssa "SSA name holes removed == 40" 1
43 release_ssa "SSA name holes removed == 41" 1
43 release_ssa "SSA name holes removed == 42" 1
43 release_ssa "SSA name holes removed == 46" 1
43 release_ssa "SSA name holes removed == 47" 2
43 release_ssa "SSA name holes removed == 48" 1
43 release_ssa "SSA name holes removed == 50" 1
43 release_ssa "SSA name holes removed == 51" 1
43 release_ssa "SSA name holes removed == 57" 1
43 release_ssa "SSA name holes removed == 59" 1
43 release_ssa "SSA name holes removed == 61" 2
43 release_ssa "SSA name holes removed == 63" 2
43 release_ssa "SSA name holes removed == 67" 1
43 release_ssa "SSA name holes removed == 68" 1
43 release_ssa "SSA name holes removed == 70" 1
43 release_ssa "SSA name holes removed == 75" 1
43 release_ssa "SSA name holes removed == 76" 1
43 release_ssa "SSA name holes removed == 78" 1
43 release_ssa "SSA name holes removed == 86" 1
43 release_ssa "SSA name holes removed == 87" 1
43 release_ssa "SSA name holes removed == 89" 2
43 release_ssa "SSA name holes removed == 90" 1
43 release_ssa "SSA name holes removed == 94" 1
43 release_ssa "SSA name holes removed == 95" 1
43 release_ssa "SSA name holes removed == 100" 1
43 release_ssa "SSA name holes removed == 103" 1
43 release_ssa "SSA name holes removed == 106" 1
43 release_ssa "SSA name holes removed == 109" 1
43 release_ssa "SSA name holes removed == 114" 1
43 release_ssa "SSA name holes removed == 116" 1
43 release_ssa "SSA name holes removed == 121" 1
43 release_ssa "SSA name holes removed == 122" 2
43 release_ssa "SSA name holes removed == 125" 1
43 release_ssa "SSA name holes removed == 131" 1
43 release_ssa "SSA name holes removed == 132" 1
43 release_ssa "SSA name holes removed == 133" 2
43 release_ssa "SSA name holes removed == 145" 3
43 release_ssa "SSA name holes removed == 150" 1
43 release_ssa "SSA name holes removed == 154" 1
43 release_ssa "SSA name holes removed == 168" 1
43 release_ssa "SSA name holes removed == 171" 1
43 release_ssa "SSA name holes removed == 178" 1
43 release_ssa "SSA name holes removed == 181" 1
43 release_ssa "SSA name holes removed == 195" 1
43 release_ssa "SSA name holes removed == 199" 1
43 release_ssa "SSA name holes removed == 206" 1
43 release_ssa "SSA name holes removed == 257" 1
43 release_ssa "SSA name holes removed == 258" 1
43 release_ssa "SSA name holes removed == 288" 1
43 release_ssa "SSA name holes removed == 375" 1
43 release_ssa "SSA name holes removed == 517" 1
43 release_ssa "SSA name holes removed == 542" 1
43 release_ssa "SSA name holes removed == 547" 1
43 release_ssa "SSA name holes removed == 727" 1
43 release_ssa "SSA name holes removed 

Re: [RS6000] Stack tie fix.

[Olivier Hainque]

Hello Alan,

On Apr 4, 2012, at 03:22 , Alan Modra wrote:
> I'll see whether my approach fixes pr30282 for gcc-4.4 which has known
> deficiencies in alias analysis.  Olivier, would you be kind enough to
> backport and test against other versions of gcc that needed your
> bigger hammer?

 Sure. I can debug the paths taken for the testcases where we had
 observed problems and see. I'll see if I can do a few tests comparing
 generated code on some source base. The problems are hard to observe
 at runtime because they are very timing/event/environment dependant.

 I still feel a bit unclear/concerned on a couple of aspects. One is:
 
 There are lots of places in the emit_epilogue code that assign
 frame_reg_rtx with different possible values, (hard_fp, sp, r11)
 before we first get to points where we emit ties. There are also
 multiple places where we do emit ties.

 It is not at all obvious to me that the all places where we emit ties
 have an accurate perception of what frame_reg's were possibly used before.

 IOW, I am not 100% convinced that we cannot have a bad case where
 we emit a tie that misses a reg reference. The various paths are all
 controlled by intricate conditions, so getting that 100% conviction
 (at least on paper) isn't easy to me.

 Is it clearer to you ?

 FWIW, I had made an experiment at trying to extract subfunctions,
 which might help such reasoning.  Set of patches attached. This doesn't
 apply to the current mainline, would need to refined, and we probably
 couldn't/shouldn't put something like this on the path to the resolution
 of our current issue, so this is JIC you are curious.



ppcepi-split.tar.gz
Description: GNU Zip compressed data

Re: [PATCH] Make gsi_remove return whether EH cleanup is required

[Rainer Orth]

Richard Guenther  writes:

> Several passes needlessly cleanup EH after gsi_remove because they do
> not know whether the stmt was removed from EH regions.  The following
> patch returns this information from gsi_remove and adjusts all users
> I could find appropriately.

I suspect this patch caused a go1 SEGV compiling the non-PIC
libgo/exp/norm.o on i386-pc-solaris2.10:

> /var/gcc/regression/trunk/10-gcc-gld/build/./gcc/gccgo 
> -B/var/gcc/regression/trunk/10-gcc-gld/build/./gcc/ 
> -B/vol/gcc/i386-pc-solaris2.10/bin/ -B/vol/gcc/i386-pc-solaris2.10/lib/ 
> -isystem /vol/gcc/i386-pc-solaris2.10/include -isystem 
> /vol/gcc/i386-pc-solaris2.10/sys-include -minline-all-stringops -g -O2 -I . 
> -c -fgo-prefix=libgo_exp 
> /vol/gcc/src/hg/trunk/local/libgo/go/exp/norm/composition.go 
> /vol/gcc/src/hg/trunk/local/libgo/go/exp/norm/forminfo.go 
> /vol/gcc/src/hg/trunk/local/libgo/go/exp/norm/input.go 
> /vol/gcc/src/hg/trunk/local/libgo/go/exp/norm/iter.go 
> /vol/gcc/src/hg/trunk/local/libgo/go/exp/norm/normalize.go 
> /vol/gcc/src/hg/trunk/local/libgo/go/exp/norm/readwriter.go 
> /vol/gcc/src/hg/trunk/local/libgo/go/exp/norm/tables.go 
> /vol/gcc/src/hg/trunk/local/libgo/go/exp/norm/trie.go -o exp/norm.o 
> -save-temps
/vol/gcc/src/hg/trunk/local/libgo/go/exp/norm/normalize.go: In function 
'norm.decomposeToLastBoundary':
/vol/gcc/src/hg/trunk/local/libgo/go/exp/norm/normalize.go:429:1: internal 
compiler error: Segmentation Fault

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0x0852aefc in dse_optimize_stmt (gsi=...) at 
/vol/gcc/src/hg/trunk/local/gcc/tree-ssa-dse.c:262
(gdb) where
#0  0x0852aefc in dse_optimize_stmt (gsi=...) at 
/vol/gcc/src/hg/trunk/local/gcc/tree-ssa-dse.c:262
#1  dse_enter_block (walk_data=0x8046ed0, bb=0xfe2c6640) at 
/vol/gcc/src/hg/trunk/local/gcc/tree-ssa-dse.c:278
#2  0x08875e85 in walk_dominator_tree (walk_data=0x8046ed0, bb=0xfe2c6640) at 
/vol/gcc/src/hg/trunk/local/gcc/domwalk.c:188
#3  0x0852a757 in tree_ssa_dse () at 
/vol/gcc/src/hg/trunk/local/gcc/tree-ssa-dse.c:313
#4  0x0840cb64 in execute_one_pass (pass=pass@entry=0x8dbe8a0) at 
/vol/gcc/src/hg/trunk/local/gcc/passes.c:2079
#5  0x0840cebd in execute_pass_list (pass=0x8dbe8a0) at 
/vol/gcc/src/hg/trunk/local/gcc/passes.c:2134
#6  0x0840ced0 in execute_pass_list (pass=0x8dbe4e0) at 
/vol/gcc/src/hg/trunk/local/gcc/passes.c:2135
#7  0x084ea0f6 in tree_rest_of_compilation (fndecl=0xfeb9d300) at 
/vol/gcc/src/hg/trunk/local/gcc/tree-optimize.c:422
#8  0x08283417 in cgraph_expand_function (node=0xfebb599c) at 
/vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:1784
#9  0x08284c55 in cgraph_expand_all_functions () at 
/vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:1851
#10 cgraph_optimize () at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2542
#11 0x0828518f in cgraph_finalize_compilation_unit () at 
/vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2628
#12 0x081d117d in Gogo::write_globals (this=0x8f2f170) at 
/vol/gcc/src/hg/trunk/local/gcc/go/gofrontend/gogo-tree.cc:934
#13 0x081cb343 in go_write_globals () at 
/vol/gcc/src/hg/trunk/local/gcc/go/gofrontend/go.cc:154
#14 0x084a432b in compile_file () at 
/vol/gcc/src/hg/trunk/local/gcc/toplev.c:572
#15 do_compile () at /vol/gcc/src/hg/trunk/local/gcc/toplev.c:1936
#16 toplev_main (argc=26, argv=0x80471cc) at 
/vol/gcc/src/hg/trunk/local/gcc/toplev.c:2012
#17 0x0819f3bb in main (argc=26, argv=0x80471cc) at 
/vol/gcc/src/hg/trunk/local/gcc/main.c:36

Unfortunately, I cannot look into most of the variables used since gdb
just shows them as `optimized out'.

I'm just running a x86_64-unknown-linux-gnu bootstrap to check if it
also occurs there.

Rainer

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

Re: [PATCH] Make gsi_remove return whether EH cleanup is required

[Richard Guenther]

On Thu, Apr 5, 2012 at 1:20 PM, Rainer Orth  
wrote:
> Richard Guenther  writes:
>
>> Several passes needlessly cleanup EH after gsi_remove because they do
>> not know whether the stmt was removed from EH regions.  The following
>> patch returns this information from gsi_remove and adjusts all users
>> I could find appropriately.
>
> I suspect this patch caused a go1 SEGV compiling the non-PIC
> libgo/exp/norm.o on i386-pc-solaris2.10:

Ah.  Try

Index: gcc/tree-ssa-dse.c
===
--- gcc/tree-ssa-dse.c  (revision 186161)
+++ gcc/tree-ssa-dse.c  (working copy)
@@ -232,6 +232,8 @@ dse_optimize_stmt (gimple_stmt_iterator
gimple_get_lhs (use_stmt), 0)))
  || stmt_kills_ref_p (use_stmt, gimple_assign_lhs (stmt)))
{
+ basic_block bb;
+
  /* If use_stmt is or might be a nop assignment, e.g. for
 struct { ... } S a, b, *p; ...
 b = a; b = b;
@@ -258,8 +260,9 @@ dse_optimize_stmt (gimple_stmt_iterator
  unlink_stmt_vdef (stmt);

  /* Remove the dead store.  */
+ bb = gimple_bb (stmt);
  if (gsi_remove (&gsi, true))
-   bitmap_set_bit (need_eh_cleanup, gimple_bb (stmt)->index);
+   bitmap_set_bit (need_eh_cleanup, bb->index);

  /* And release any SSA_NAMEs set in this statement back to the
 SSA_NAME manager.  */


>> /var/gcc/regression/trunk/10-gcc-gld/build/./gcc/gccgo 
>> -B/var/gcc/regression/trunk/10-gcc-gld/build/./gcc/ 
>> -B/vol/gcc/i386-pc-solaris2.10/bin/ -B/vol/gcc/i386-pc-solaris2.10/lib/ 
>> -isystem /vol/gcc/i386-pc-solaris2.10/include -isystem 
>> /vol/gcc/i386-pc-solaris2.10/sys-include -minline-all-stringops -g -O2 -I . 
>> -c -fgo-prefix=libgo_exp 
>> /vol/gcc/src/hg/trunk/local/libgo/go/exp/norm/composition.go 
>> /vol/gcc/src/hg/trunk/local/libgo/go/exp/norm/forminfo.go 
>> /vol/gcc/src/hg/trunk/local/libgo/go/exp/norm/input.go 
>> /vol/gcc/src/hg/trunk/local/libgo/go/exp/norm/iter.go 
>> /vol/gcc/src/hg/trunk/local/libgo/go/exp/norm/normalize.go 
>> /vol/gcc/src/hg/trunk/local/libgo/go/exp/norm/readwriter.go 
>> /vol/gcc/src/hg/trunk/local/libgo/go/exp/norm/tables.go 
>> /vol/gcc/src/hg/trunk/local/libgo/go/exp/norm/trie.go -o exp/norm.o 
>> -save-temps
> /vol/gcc/src/hg/trunk/local/libgo/go/exp/norm/normalize.go: In function 
> 'norm.decomposeToLastBoundary':
> /vol/gcc/src/hg/trunk/local/libgo/go/exp/norm/normalize.go:429:1: internal 
> compiler error: Segmentation Fault
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1 (LWP 1)]
> 0x0852aefc in dse_optimize_stmt (gsi=...) at 
> /vol/gcc/src/hg/trunk/local/gcc/tree-ssa-dse.c:262
> (gdb) where
> #0  0x0852aefc in dse_optimize_stmt (gsi=...) at 
> /vol/gcc/src/hg/trunk/local/gcc/tree-ssa-dse.c:262
> #1  dse_enter_block (walk_data=0x8046ed0, bb=0xfe2c6640) at 
> /vol/gcc/src/hg/trunk/local/gcc/tree-ssa-dse.c:278
> #2  0x08875e85 in walk_dominator_tree (walk_data=0x8046ed0, bb=0xfe2c6640) at 
> /vol/gcc/src/hg/trunk/local/gcc/domwalk.c:188
> #3  0x0852a757 in tree_ssa_dse () at 
> /vol/gcc/src/hg/trunk/local/gcc/tree-ssa-dse.c:313
> #4  0x0840cb64 in execute_one_pass (pass=pass@entry=0x8dbe8a0) at 
> /vol/gcc/src/hg/trunk/local/gcc/passes.c:2079
> #5  0x0840cebd in execute_pass_list (pass=0x8dbe8a0) at 
> /vol/gcc/src/hg/trunk/local/gcc/passes.c:2134
> #6  0x0840ced0 in execute_pass_list (pass=0x8dbe4e0) at 
> /vol/gcc/src/hg/trunk/local/gcc/passes.c:2135
> #7  0x084ea0f6 in tree_rest_of_compilation (fndecl=0xfeb9d300) at 
> /vol/gcc/src/hg/trunk/local/gcc/tree-optimize.c:422
> #8  0x08283417 in cgraph_expand_function (node=0xfebb599c) at 
> /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:1784
> #9  0x08284c55 in cgraph_expand_all_functions () at 
> /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:1851
> #10 cgraph_optimize () at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2542
> #11 0x0828518f in cgraph_finalize_compilation_unit () at 
> /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2628
> #12 0x081d117d in Gogo::write_globals (this=0x8f2f170) at 
> /vol/gcc/src/hg/trunk/local/gcc/go/gofrontend/gogo-tree.cc:934
> #13 0x081cb343 in go_write_globals () at 
> /vol/gcc/src/hg/trunk/local/gcc/go/gofrontend/go.cc:154
> #14 0x084a432b in compile_file () at 
> /vol/gcc/src/hg/trunk/local/gcc/toplev.c:572
> #15 do_compile () at /vol/gcc/src/hg/trunk/local/gcc/toplev.c:1936
> #16 toplev_main (argc=26, argv=0x80471cc) at 
> /vol/gcc/src/hg/trunk/local/gcc/toplev.c:2012
> #17 0x0819f3bb in main (argc=26, argv=0x80471cc) at 
> /vol/gcc/src/hg/trunk/local/gcc/main.c:36
>
> Unfortunately, I cannot look into most of the variables used since gdb
> just shows them as `optimized out'.
>
> I'm just running a x86_64-unknown-linux-gnu bootstrap to check if it
> also occurs there.
>
>        Rainer
>
> --
> -
> Rainer Orth, Center for Biotechnology, Bielefel

Re: [PATCH] Make gsi_remove return whether EH cleanup is required

[Rainer Orth]

Richard Guenther  writes:

> On Thu, Apr 5, 2012 at 1:20 PM, Rainer Orth  
> wrote:
>> Richard Guenther  writes:
>>
>>> Several passes needlessly cleanup EH after gsi_remove because they do
>>> not know whether the stmt was removed from EH regions.  The following
>>> patch returns this information from gsi_remove and adjusts all users
>>> I could find appropriately.
>>
>> I suspect this patch caused a go1 SEGV compiling the non-PIC
>> libgo/exp/norm.o on i386-pc-solaris2.10:
>
> Ah.  Try
>
> Index: gcc/tree-ssa-dse.c
> ===
> --- gcc/tree-ssa-dse.c  (revision 186161)
> +++ gcc/tree-ssa-dse.c  (working copy)
> @@ -232,6 +232,8 @@ dse_optimize_stmt (gimple_stmt_iterator
> gimple_get_lhs (use_stmt), 0)))
>   || stmt_kills_ref_p (use_stmt, gimple_assign_lhs (stmt)))
> {
> + basic_block bb;
> +
>   /* If use_stmt is or might be a nop assignment, e.g. for
>  struct { ... } S a, b, *p; ...
>  b = a; b = b;
> @@ -258,8 +260,9 @@ dse_optimize_stmt (gimple_stmt_iterator
>   unlink_stmt_vdef (stmt);
>
>   /* Remove the dead store.  */
> + bb = gimple_bb (stmt);
>   if (gsi_remove (&gsi, true))
> -   bitmap_set_bit (need_eh_cleanup, gimple_bb (stmt)->index);
> +   bitmap_set_bit (need_eh_cleanup, bb->index);
>
>   /* And release any SSA_NAMEs set in this statement back to the
>  SSA_NAME manager.  */
>

Works fine on x86_64-unknown-linux-gnu, where the failure happened as
well.

Thanks.
Rainer

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

Re: [C11-atomic] [patch] gimple atomic statements

[Andrew MacLeod]

On 04/05/2012 05:14 AM, Richard Guenther wrote:


Ok.  I suppose having a GIMPLE_ATOMIC is fine then.

Thanks for all the feedback, I haven't really had to play in gimple land 
much lately. Some of those routines I guessed at what to do in order to 
get through initial compilation and your comments help clear those up 
too :-)


I will address everything next week since I doubt I will get to them 
before the long weekend arrives here.


Andrew

Re: [PATCH] Fix PR52614

[William J. Schmidt]

On Thu, 2012-04-05 at 11:30 +0200, Richard Guenther wrote:
> On Thu, Apr 5, 2012 at 6:22 AM, Mike Stump  wrote:
> > On Apr 4, 2012, at 7:56 PM, William J. Schmidt wrote:
> >> There seems to be tacit agreement that the vector tests should use
> >> -fno-common on all targets to avoid the recent spate of failures (see
> >> discussion in 52571 and 52603).
> >
> >> OK for trunk?
> >
> > Ok.  Any other solution I think will be real work and we shouldn't loose 
> > the testing between now and then by not having the test cases working.
> 
> Ian, you are the "source" of all of these problems.  While I did not notice
> any degradations in SPEC (on x86) with handling commons "correctly"
> now, the fact
> that our testsuite needs -fno-common to make things vectorizable shows
> that users might be impacted negatively by this, which is only a real problem
> in corner cases.  Why can the link editor not promote the definitions 
> alignment
> when merging with a common with bigger alignment?
> 
> Richard.
> 

Follow-up question:  Should -ftree-vectorize imply -fno-common in the
short term?

Thanks,
Bill

Re: [branches/google/gcc-4_6] Backported r179661 and 179662 from mainline. (issue 5989043)

[Andrew Stubbs]

On 05/04/12 05:43, Michael Hope wrote:

Andrew, could you check that the Google guys have the final version of
your patch?


Yes, it looks fine to me.


Could you backport the fix to the 4.6 release branch if valid?  Better
than having the same patch in three places.


Ok, I'll need permission from a maintainer, I think.

Andrew

Re: [PATCH] Fix PR52614

[Richard Guenther]

On Thu, Apr 5, 2012 at 1:59 PM, William J. Schmidt
 wrote:
> On Thu, 2012-04-05 at 11:30 +0200, Richard Guenther wrote:
>> On Thu, Apr 5, 2012 at 6:22 AM, Mike Stump  wrote:
>> > On Apr 4, 2012, at 7:56 PM, William J. Schmidt wrote:
>> >> There seems to be tacit agreement that the vector tests should use
>> >> -fno-common on all targets to avoid the recent spate of failures (see
>> >> discussion in 52571 and 52603).
>> >
>> >> OK for trunk?
>> >
>> > Ok.  Any other solution I think will be real work and we shouldn't loose 
>> > the testing between now and then by not having the test cases working.
>>
>> Ian, you are the "source" of all of these problems.  While I did not notice
>> any degradations in SPEC (on x86) with handling commons "correctly"
>> now, the fact
>> that our testsuite needs -fno-common to make things vectorizable shows
>> that users might be impacted negatively by this, which is only a real problem
>> in corner cases.  Why can the link editor not promote the definitions 
>> alignment
>> when merging with a common with bigger alignment?
>>
>> Richard.
>>
>
> Follow-up question:  Should -ftree-vectorize imply -fno-common in the
> short term?

That's probably more a C language question - you would get valid C
rejected with -fno-common.  But maybe -ftree-vectorize should suggest
-fno-common when it encounters a case it would like to promote alignment
for.  Not sure if for example Fortran would ever work with -fno-common though.

Richard.

> Thanks,
> Bill
>

Re: [PATCH] Make gsi_remove return whether EH cleanup is required

[Richard Guenther]

On Thu, 5 Apr 2012, Rainer Orth wrote:

> Richard Guenther  writes:
> 
> > On Thu, Apr 5, 2012 at 1:20 PM, Rainer Orth  
> > wrote:
> >> Richard Guenther  writes:
> >>
> >>> Several passes needlessly cleanup EH after gsi_remove because they do
> >>> not know whether the stmt was removed from EH regions.  The following
> >>> patch returns this information from gsi_remove and adjusts all users
> >>> I could find appropriately.
> >>
> >> I suspect this patch caused a go1 SEGV compiling the non-PIC
> >> libgo/exp/norm.o on i386-pc-solaris2.10:
> >
> > Ah.  Try
> >
> > Index: gcc/tree-ssa-dse.c
> > ===
> > --- gcc/tree-ssa-dse.c  (revision 186161)
> > +++ gcc/tree-ssa-dse.c  (working copy)
> > @@ -232,6 +232,8 @@ dse_optimize_stmt (gimple_stmt_iterator
> > gimple_get_lhs (use_stmt), 0)))
> >   || stmt_kills_ref_p (use_stmt, gimple_assign_lhs (stmt)))
> > {
> > + basic_block bb;
> > +
> >   /* If use_stmt is or might be a nop assignment, e.g. for
> >  struct { ... } S a, b, *p; ...
> >  b = a; b = b;
> > @@ -258,8 +260,9 @@ dse_optimize_stmt (gimple_stmt_iterator
> >   unlink_stmt_vdef (stmt);
> >
> >   /* Remove the dead store.  */
> > + bb = gimple_bb (stmt);
> >   if (gsi_remove (&gsi, true))
> > -   bitmap_set_bit (need_eh_cleanup, gimple_bb (stmt)->index);
> > +   bitmap_set_bit (need_eh_cleanup, bb->index);
> >
> >   /* And release any SSA_NAMEs set in this statement back to the
> >  SSA_NAME manager.  */
> >
> 
> Works fine on x86_64-unknown-linux-gnu, where the failure happened as
> well.

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

Richard.

2012-04-05  Richard Guenther  

* tree-ssa-dse.c (dse_optimize_stmt): Remember the stmt
basic-block before removing it.

Index: gcc/tree-ssa-dse.c
===
--- gcc/tree-ssa-dse.c  (revision 186161)
+++ gcc/tree-ssa-dse.c  (working copy)
@@ -232,6 +232,8 @@ dse_optimize_stmt (gimple_stmt_iterator
gimple_get_lhs (use_stmt), 0)))
  || stmt_kills_ref_p (use_stmt, gimple_assign_lhs (stmt)))
{
+ basic_block bb;
+
  /* If use_stmt is or might be a nop assignment, e.g. for
 struct { ... } S a, b, *p; ...
 b = a; b = b;
@@ -258,8 +260,9 @@ dse_optimize_stmt (gimple_stmt_iterator
  unlink_stmt_vdef (stmt);
 
  /* Remove the dead store.  */
+ bb = gimple_bb (stmt);
  if (gsi_remove (&gsi, true))
-   bitmap_set_bit (need_eh_cleanup, gimple_bb (stmt)->index);
+   bitmap_set_bit (need_eh_cleanup, bb->index);
 
  /* And release any SSA_NAMEs set in this statement back to the
 SSA_NAME manager.  */

fix install-no-fixedincludes mishaps

[Olivier Hainque]

Hello,

This is following up on a proposal first discussed at
http://gcc.gnu.org/ml/gcc-patches/2010-10/msg00666.html

The initial issue to resolve is still present today:
install-no-fixedincludes remains a useful Makefile target
and it misbehaves in two ways:
  
  1) past the second invocation, it rebuilds a lot of things
 un-necessarily (because the first invocation touches stamps
 it should preserve)

  2) it does install the contents of 'include-fixed' while part of
 it's purpose is precisely not to

This can be observed rapidly on a standard x86-linux configuration,
just to illustrate: 

  configure --prefix= --enable-languages=c --disable-libada 
--disable-bootstrap

  make install-no-fixedincludes >& ins-nofixed-1.log
  mv  

  make install-no-fixedincludes >& ins-nofixed-2.log
  mv  

  diff ins-nofixed-1.log ins-nofixed-2.log
  < + lots of stuff, rebuilds, etc>

  ls /lib/gcc/x86_64-unknown-linux-gnu/4.7.1/include-fixed
  

The attached patch is a proposal to fix this, moving details to the gcc/
Makefile where they belong (as suggested in the aforementioned thread),
and adding explicit targets+comments to clarify what is going on.

After the patch

- all the un-necessary extra operations disappear from the second step
  (and this remains stable on later invocations),

- the undesired parts of 'include-fixed' are not installed any more

I have compared the install trees and found them identical otherwise.

Bootstrapped and regtested on x86_64-pc-linux-gnu with languages=all,ada.

OK to commit ?

Thanks in advance for your feedback,

Olivier

2012-04-05  Olivier Hainque  

* Makefile.tpl (gcc-no-fixedincludes): Rename into ...
(gcc-install-no-fixedincludes): Forwarder to local target in gcc/
* Makefile.in: Regenerate.

gcc/
* Makefile.in (install-no-fixedincludes): New target.  Former toplevel
gcc-no-fixedincludes, interlacing stmp-int-hdrs and install with ...
(stash-maybefixed-headers, restore-header-stamps,
 restore-maybefixed-headers): New subtargets. Add -p to cp syslimits.h.
Stash and restore include-fixed as well as include.
(stmp-int-hdrs): Use move-if-change + cp -p to setup fix_dir/limits.h.



no-fixedincludes.dif
Description: video/dv

Re: fix install-no-fixedincludes mishaps

[Richard Guenther]

On Thu, Apr 5, 2012 at 2:54 PM, Olivier Hainque  wrote:
> Hello,
>
> This is following up on a proposal first discussed at
> http://gcc.gnu.org/ml/gcc-patches/2010-10/msg00666.html
>
> The initial issue to resolve is still present today:
> install-no-fixedincludes remains a useful Makefile target
> and it misbehaves in two ways:
>
>  1) past the second invocation, it rebuilds a lot of things
>     un-necessarily (because the first invocation touches stamps
>     it should preserve)
>
>  2) it does install the contents of 'include-fixed' while part of
>     it's purpose is precisely not to
>
> This can be observed rapidly on a standard x86-linux configuration,
> just to illustrate:
>
>  configure --prefix= --enable-languages=c --disable-libada 
> --disable-bootstrap
>
>  make install-no-fixedincludes >& ins-nofixed-1.log
>  mv  
>
>  make install-no-fixedincludes >& ins-nofixed-2.log
>  mv  
>
>  diff ins-nofixed-1.log ins-nofixed-2.log
>  < + lots of stuff, rebuilds, etc>
>
>  ls /lib/gcc/x86_64-unknown-linux-gnu/4.7.1/include-fixed
>  
>
> The attached patch is a proposal to fix this, moving details to the gcc/
> Makefile where they belong (as suggested in the aforementioned thread),
> and adding explicit targets+comments to clarify what is going on.
>
> After the patch
>
> - all the un-necessary extra operations disappear from the second step
>  (and this remains stable on later invocations),
>
> - the undesired parts of 'include-fixed' are not installed any more
>
> I have compared the install trees and found them identical otherwise.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu with languages=all,ada.
>
> OK to commit ?

Nice.  I suppose this would enable a --disable-fixinclude?  fixinclude can
take quite some time when a lot of headers are installed and if we are
not going to install them, why produce them ...

Richard.

> Thanks in advance for your feedback,
>
> Olivier
>
> 2012-04-05  Olivier Hainque  
>
>        * Makefile.tpl (gcc-no-fixedincludes): Rename into ...
>        (gcc-install-no-fixedincludes): Forwarder to local target in gcc/
>        * Makefile.in: Regenerate.
>
>        gcc/
>        * Makefile.in (install-no-fixedincludes): New target.  Former toplevel
>        gcc-no-fixedincludes, interlacing stmp-int-hdrs and install with ...
>        (stash-maybefixed-headers, restore-header-stamps,
>         restore-maybefixed-headers): New subtargets. Add -p to cp syslimits.h.
>        Stash and restore include-fixed as well as include.
>        (stmp-int-hdrs): Use move-if-change + cp -p to setup fix_dir/limits.h.
>

Re: fix install-no-fixedincludes mishaps

[Olivier Hainque]

On Apr 5, 2012, at 15:07 , Richard Guenther wrote:
> Nice.

 Thanks :)

> I suppose this would enable a --disable-fixinclude?  fixinclude can
> take quite some time when a lot of headers are installed and if we are
> not going to install them, why produce them ...

 That was another suggestion in the original thread. I agree it might be
 interesting as well, but that remains a different thing and the Makefile
 target remains useful even without this.

 First, we often need the fixed include files to build the libraries in any
 case. And most of the time, we (at least we=us at AdaCore) need to keep the
 possibility to have both kinds of install targets from a single tree.

 We use the regular "install" on our machines and the no-fixedincludes one
 to produce binary distributions, so we don't distribute sources derived from
 system ones. We also package a program gcc provides to (re)execute fix-includes
 at install time.

 Olivier

Re: PATCH: Define TRY_EMPTY_VM_SPACE for Linux/x32

[H.J. Lu]

On Wed, Apr 4, 2012 at 11:56 AM, H.J. Lu  wrote:
> On Wed, Apr 4, 2012 at 11:53 AM, Andrew Pinski  wrote:
>> On Wed, Apr 4, 2012 at 11:50 AM, Uros Bizjak  wrote:
>>> Looking at how other targets implement this check, I don't think that
>>> this is a problem at all. This issue only shows on a non-bootstrapped
>>> build. A full bootstrap will use correct address.
>>
>> The other place where it shows up is cross compilers but who is going
>> to use a 3.2 compiler with GCC 4.8 anyways?
>>
>
> FWIW, I have no problem with checking __LP64__ only. I just want to
> mention this potential issue.
>

Here is a different patch.  It checks sizeof (void *) for those hosts
where it is appropriate.  Does it look OK?

Thanks.


-- 
H.J.
---
diff --git a/gcc/config/host-linux.c b/gcc/config/host-linux.c
index 94b7a0b..93c513e 100644
--- a/gcc/config/host-linux.c
+++ b/gcc/config/host-linux.c
@@ -64,14 +64,12 @@

 /* For various ports, try to guess a fixed spot in the vm space
that's probably free.  */
-#if defined(__alpha)
-# define TRY_EMPTY_VM_SPACE0x100
+#if defined(__alpha) || defined(__ARM_EABI__) || defined(__i386) \
+|| defined(__x86_64)
+# define TRY_EMPTY_VM_SPACE\
+  (sizeof (void *) == 8 ? 0x10 : 0x6000)
 #elif defined(__ia64)
 # define TRY_EMPTY_VM_SPACE0x2001
-#elif defined(__x86_64)
-# define TRY_EMPTY_VM_SPACE0x10
-#elif defined(__i386)
-# define TRY_EMPTY_VM_SPACE0x6000
 #elif defined(__powerpc__)
 # define TRY_EMPTY_VM_SPACE0x6000
 #elif defined(__s390x__)
@@ -84,8 +82,6 @@
 # define TRY_EMPTY_VM_SPACE0x6000
 #elif defined(__mc68000__)
 # define TRY_EMPTY_VM_SPACE0x4000
-#elif defined(__ARM_EABI__)
-# define TRY_EMPTY_VM_SPACE 0x6000
 #elif defined(__mips__) && defined(__LP64__)
 # define TRY_EMPTY_VM_SPACE0x80
 #elif defined(__mips__)

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Konstantinos Margaritis]

On Wed, 4 Apr 2012 07:09:46 -0500
Dennis Gilmore  wrote:
> Fedora does use /lib64 on x86_64 I would personally prefer /libhfp but
> wouldn't object to /libhf  though today we have f17 about to go beta
> and all of rawhide built using /lib 

Hi Dennis,

  One potential problem that is born from the /libhf suggestion is the danger 
of having a new top level directory (/libhf) with only one file, the dynamic 
linker. AFAIU it, no distro is currently willing to move away from its existing 
scheme (/lib), Debian is most likely not going to, at best there could be a 
symlink /libhf -> /lib/, but that is not solving the problem IMHO. 
What about other distros, if everyone is going to use a symlink for /libhf, 
then even suggesting it and relying on new top-level directories to solve the 
problem is the wrong approach. 

Loic suggested a -IMHO- better solution: to change the dynamic linker filename, 
not the dir, i.e. /lib/ld-linux-hf.so.3 (for this particular case).

My 2c.

-- 
Konstantinos Margaritis 

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Dennis Gilmore]

El Wed, 4 Apr 2012 08:54:12 +0200
Jakub Jelinek  escribió:
> On Wed, Apr 04, 2012 at 01:34:30PM +1200, Michael Hope wrote:
> > >  I did two ports of Mandriva to armv7. One of my choice to use
> > > softfp, and another hardfp port to be compatible with other
> > > distros. But other than a previous armv5 port, there is not much
> > > else of Mandriva arm, so, it would be "good to have" to be able
> > > to run binaries for either without resorting to a chroot, and
> > > only testing purposes.
> > >
> > >  Bumping major or calling it ld-linux-foo.so.3 is out of question?
> > 
> > I suspect /lib/ld-linux-$foo.so.3 would be fine.  There's two
> > questions here though: can the hard float loader have a different
> > path and, if so, what should it be?  We're still working on the
> > first part.
> 
> If the agreement is that arm 32-bit softfp really needs to be
> installable alongside 32-bit hardfp (and alongside aarch64), then
> IMHO it should do it like all other multilib ports (x86_64/i?86/x32,
> s390/s390x, ppc/ppc64, the various MIPS variants) and what FSB says,
> e.g. use /lib/ld-linux.so.3 and */lib dirs for softfp,
> /libhf/ld-linux.so.3 and */libhf dirs for hardfp and
> /lib64/ld-linux.so.3 and */lib64 dirs for aarch64, have 32-bit
> arm-linux-gnueabi gcc configured for softfp/hardfp multilib with
> MULTILIB_OSDIRNAMES, etc., have it configured in glibc, and for those
> that choose the Debian layout instead, if it is added somehow
> configurable into upstream gcc/glibc of course handle it similarly
> there.  I just wonder why that hasn't been done 10 years ago and only
> needs doing now (of course, aarch64 is going to be new, talking now
> about the 32-bit softfp vs. hardfp).

Fedora at least plans to not support installing hfp and sfp on the same
system, while not completely decided I don't think we will be
supporting running 32 bit arm binaries on 64 bit arm.  there is not
 a legacy support use case that I can think of i.e. existing common
 proprietary software. Though I imagine that we will use /lib64 for
 consistency with existing 64 bit arches.

Dennis

[PATCH] Move predicates that only make sense during gimplification

[Richard Guenther]

This continues what I've started some time ago - move predicates that
do not deeply inspect trees to gimplify.c and make them private.

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

Richard.

2012-04-05  Richard Guenther  

* gimple.c (walk_gimple_op): Compute val_only for the LHS
of an assigment in the canonical way, avoiding is_gimple_mem_rhs.
(is_gimple_mem_rhs, is_gimple_reg_rhs, is_gimple_stmt): Move ...
* gimplify.c (is_gimple_mem_rhs, is_gimple_reg_rhs, is_gimple_stmt):
... here and make static.
* gimple.h (is_gimple_mem_rhs, is_gimple_reg_rhs, is_gimple_stmt):
Remove.

Index: gcc/gimple.c
===
--- gcc/gimple.c(revision 186162)
+++ gcc/gimple.c(working copy)
@@ -1496,15 +1496,12 @@ walk_gimple_op (gimple stmt, walk_tree_f
 may use a COMPONENT_REF on the LHS.  */
   if (wi)
{
-  /* If the RHS has more than 1 operand, it is not appropriate
- for the memory.
-???  A lhs always requires an lvalue, checking the val_only flag
-does not make any sense, so we should be able to avoid computing
-it here.  */
+  /* If the RHS is of a non-renamable type or is a register variable,
+we may use a COMPONENT_REF on the LHS.  */
  tree rhs1 = gimple_assign_rhs1 (stmt);
- wi->val_only = !(is_gimple_mem_rhs (rhs1)
-  || TREE_CODE (rhs1) == CONSTRUCTOR)
- || gimple_assign_rhs_class (stmt) != 
GIMPLE_SINGLE_RHS;
+ wi->val_only
+   = (is_gimple_reg_type (TREE_TYPE (rhs1)) && !is_gimple_reg (rhs1))
+ || gimple_assign_rhs_class (stmt) != GIMPLE_SINGLE_RHS;
  wi->is_lhs = true;
}
 
@@ -2639,29 +2636,6 @@ const unsigned char gimple_rhs_class_tab
 
 /* Validation of GIMPLE expressions.  */
 
-/* Returns true iff T is a valid RHS for an assignment to a renamed
-   user -- or front-end generated artificial -- variable.  */
-
-bool
-is_gimple_reg_rhs (tree t)
-{
-  return get_gimple_rhs_class (TREE_CODE (t)) != GIMPLE_INVALID_RHS;
-}
-
-/* Returns true iff T is a valid RHS for an assignment to an un-renamed
-   LHS, or for a call argument.  */
-
-bool
-is_gimple_mem_rhs (tree t)
-{
-  /* If we're dealing with a renamable type, either source or dest must be
- a renamed variable.  */
-  if (is_gimple_reg_type (TREE_TYPE (t)))
-return is_gimple_val (t);
-  else
-return is_gimple_val (t) || is_gimple_lvalue (t);
-}
-
 /*  Return true if T is a valid LHS for a GIMPLE assignment expression.  */
 
 bool
@@ -2835,58 +2809,6 @@ is_gimple_ip_invariant (const_tree t)
   return is_gimple_constant (t);
 }
 
-/* Return true if T looks like a valid GIMPLE statement.  */
-
-bool
-is_gimple_stmt (tree t)
-{
-  const enum tree_code code = TREE_CODE (t);
-
-  switch (code)
-{
-case NOP_EXPR:
-  /* The only valid NOP_EXPR is the empty statement.  */
-  return IS_EMPTY_STMT (t);
-
-case BIND_EXPR:
-case COND_EXPR:
-  /* These are only valid if they're void.  */
-  return TREE_TYPE (t) == NULL || VOID_TYPE_P (TREE_TYPE (t));
-
-case SWITCH_EXPR:
-case GOTO_EXPR:
-case RETURN_EXPR:
-case LABEL_EXPR:
-case CASE_LABEL_EXPR:
-case TRY_CATCH_EXPR:
-case TRY_FINALLY_EXPR:
-case EH_FILTER_EXPR:
-case CATCH_EXPR:
-case ASM_EXPR:
-case STATEMENT_LIST:
-case OMP_PARALLEL:
-case OMP_FOR:
-case OMP_SECTIONS:
-case OMP_SECTION:
-case OMP_SINGLE:
-case OMP_MASTER:
-case OMP_ORDERED:
-case OMP_CRITICAL:
-case OMP_TASK:
-  /* These are always void.  */
-  return true;
-
-case CALL_EXPR:
-case MODIFY_EXPR:
-case PREDICT_EXPR:
-  /* These are valid regardless of their type.  */
-  return true;
-
-default:
-  return false;
-}
-}
-
 /* Return true if T is a variable.  */
 
 bool
Index: gcc/gimple.h
===
--- gcc/gimple.h(revision 186162)
+++ gcc/gimple.h(working copy)
@@ -961,8 +961,6 @@ gimple gimple_alloc_stat (enum gimple_co
 const char *gimple_decl_printable_name (tree, int);
 tree gimple_get_virt_method_for_binfo (HOST_WIDE_INT, tree);
 tree gimple_extract_devirt_binfo_from_cst (tree);
-/* Returns true iff T is a valid GIMPLE statement.  */
-extern bool is_gimple_stmt (tree);
 
 /* Returns true iff T is a scalar register variable.  */
 extern bool is_gimple_reg (tree);
@@ -996,11 +994,6 @@ extern bool is_gimple_val (tree);
 extern bool is_gimple_asm_val (tree);
 /* Returns true iff T is a valid address operand of a MEM_REF.  */
 bool is_gimple_mem_ref_addr (tree);
-/* Returns true iff T is a valid rhs for a MODIFY_EXPR where the LHS is a
-   GIMPLE temporary, a renamed user variable, or something else,
-   respectively.  */
-extern bool is_gimple_reg_rhs (tree);
-extern bool is_gimple_mem_

Re: [PATCH] Fix PR18589

[William J. Schmidt]

On Thu, 2012-04-05 at 11:23 +0200, Richard Guenther wrote:
> On Wed, Apr 4, 2012 at 9:15 PM, William J. Schmidt
>  wrote:
> > 
> > Unfortunately this seems to be necessary if I name the two passes
> > "reassoc1" and "reassoc2".  If I try to name both of them "reassoc" I
> > get failures in other tests like gfortran.dg/reassoc_4, where
> > -fdump-tree-reassoc1 doesn't work.  Unless I'm missing something
> > obvious, I think I need to keep that change.
> 
> Hm, naming them "reassoc1" and "reassoc2" is a hack.  Naming both
> "reassoc" will not trigger re-naming them to reassoc1 and reassoc2
> I think.  How ugly.  Especially that -fdump-tree-reassoc will no longer
> work.  Maybe instead of using two pass structs resort to using
> the existing hack with using first_pass_instance and TODO_mark_first_instance.

OK, that seems to be the best among evils.  Using the
first_pass_instance hack, the patch is transformed as below.
Regstrapped on powerpc64-linux, no additional failures.  OK for trunk?

Thanks,
Bill


gcc:

2012-04-05  Bill Schmidt  

PR tree-optimization/18589
* tree-ssa-reassoc.c (reassociate_stats): Add two fields.
(operand_entry): Add count field.
(add_repeat_to_ops_vec): New function.
(completely_remove_stmt): Likewise.
(remove_def_if_absorbed_call): Likewise.
(remove_visited_stmt_chain): Remove feeding builtin pow/powi calls.
(acceptable_pow_call): New function.
(linearize_expr_tree): Look for builtin pow/powi calls and add operand
entries with repeat counts when found.
(repeat_factor_d): New struct and associated typedefs.
(repeat_factor_vec): New static vector variable.
(compare_repeat_factors): New function.
(get_reassoc_pow_ssa_name): Likewise.
(attempt_builtin_powi): Likewise.
(reassociate_bb): Call attempt_builtin_powi.
(fini_reassoc): Two new calls to statistics_counter_event.

gcc/testsuite:

2012-04-05  Bill Schmidt  

PR tree-optimization/18589
* gcc.dg/tree-ssa/pr18589-1.c: New test.
* gcc.dg/tree-ssa/pr18589-2.c: Likewise.
* gcc.dg/tree-ssa/pr18589-3.c: Likewise.
* gcc.dg/tree-ssa/pr18589-4.c: Likewise.
* gcc.dg/tree-ssa/pr18589-5.c: Likewise.
* gcc.dg/tree-ssa/pr18589-6.c: Likewise.
* gcc.dg/tree-ssa/pr18589-7.c: Likewise.
* gcc.dg/tree-ssa/pr18589-8.c: Likewise.
* gcc.dg/tree-ssa/pr18589-9.c: Likewise.
* gcc.dg/tree-ssa/pr18589-10.c: Likewise.


Index: gcc/testsuite/gcc.dg/tree-ssa/pr18589-4.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/pr18589-4.c   (revision 0)
+++ gcc/testsuite/gcc.dg/tree-ssa/pr18589-4.c   (revision 0)
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-options "-O3 -ffast-math -fdump-tree-optimized" } */
+
+double baz (double x, double y, double z, double u)
+{
+  return x * x * y * y * y * z * z * z * z * u;
+}
+
+/* { dg-final { scan-tree-dump-times " \\* " 6 "optimized" } } */
+/* { dg-final { cleanup-tree-dump "optimized" } } */
Index: gcc/testsuite/gcc.dg/tree-ssa/pr18589-5.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/pr18589-5.c   (revision 0)
+++ gcc/testsuite/gcc.dg/tree-ssa/pr18589-5.c   (revision 0)
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-options "-O3 -ffast-math -fdump-tree-optimized" } */
+
+double baz (double x, double y, double z, double u)
+{
+  return x * x * x * y * y * y * z * z * z * z * u * u * u * u;
+}
+
+/* { dg-final { scan-tree-dump-times " \\* " 6 "optimized" } } */
+/* { dg-final { cleanup-tree-dump "optimized" } } */
Index: gcc/testsuite/gcc.dg/tree-ssa/pr18589-6.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/pr18589-6.c   (revision 0)
+++ gcc/testsuite/gcc.dg/tree-ssa/pr18589-6.c   (revision 0)
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-options "-O3 -ffast-math -fdump-tree-optimized" } */
+
+double baz (double x, double y)
+{
+  return __builtin_pow (x, 3.0) * __builtin_pow (y, 4.0);
+}
+
+/* { dg-final { scan-tree-dump-times " \\* " 4 "optimized" } } */
+/* { dg-final { cleanup-tree-dump "optimized" } } */
Index: gcc/testsuite/gcc.dg/tree-ssa/pr18589-7.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/pr18589-7.c   (revision 0)
+++ gcc/testsuite/gcc.dg/tree-ssa/pr18589-7.c   (revision 0)
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-options "-O3 -ffast-math -fdump-tree-optimized" } */
+
+float baz (float x, float y)
+{
+  return x * x * x * x * y * y * y * y;
+}
+
+/* { dg-final { scan-tree-dump-times " \\* " 3 "optimized" } } */
+/* { dg-final { cleanup-tree-dump "optimized" } } */
Index: gcc/testsuite/gcc.dg/tree-ssa/pr18589-8.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/pr18589-8.c   (revision 0)
+++ gcc/tes

Re: [Patch, i386] Avoid LCP stalls (issue5975045)

[Teresa Johnson]

Thanks, I will do both and update the comment as suggested by David,
retest and then commit.

Teresa

On Thu, Apr 5, 2012 at 12:41 AM, Uros Bizjak  wrote:
> Hello!
>
>> New patch to avoid LCP stalls based on feedback from earlier patch. I 
>> modified
>> H.J.'s old patch to perform the peephole2 to split immediate moves to HImode
>> memory. This is now enabled for Core2, Corei7 and Generic.
>
>> 2012-04-04   Teresa Johnson  
>>
>>       * config/i386/i386.h (ix86_tune_indices): Add
>>       X86_TUNE_LCP_STALL.
>>       * config/i386/i386.md (move immediate to memory peephole2):
>>       Add cases for HImode move when LCP stall avoidance is needed.
>>       * config/i386/i386.c (initial_ix86_tune_features): Initialize
>>       X86_TUNE_LCP_STALL entry.
>
>   "optimize_insn_for_speed_p ()
> -   && !TARGET_USE_MOV0
> -   && TARGET_SPLIT_LONG_MOVES
> -   && get_attr_length (insn) >= ix86_cur_cost ()->large_insn
> +   && ((TARGET_LCP_STALL
> +       && GET_MODE (operands[0]) == HImode)
> +       || (!TARGET_USE_MOV0
> +          && TARGET_SPLIT_LONG_MOVES
> +          && get_attr_length (insn) >= ix86_cur_cost ()->large_insn))
>
> Please change added condition to:
>
> && ((mode == HImode
>        && TARGET_LCP_STALL)
>       || (...))
>
> Please also add H.J. as co-author of this change to ChangeLog.
>
> OK with these changes.
>
> Thanks,
> Uros.



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

[PATCH][1/n] Cleanup global pass execution flow

[Richard Guenther]

I'm trying to get an idea where and why we execute what part of the
pass pipeline (yeah, a two-line patch doing -Og should be possible
after this series ...).  This patch removes an odd caller of
execute_pass_list (pass_early_local_passes.pass.sub), named
tree_lowering_passes, which is even undocumented.  The two callers
will end up executing distinct parts of the function and the
function performs unnecessary setup.  Thus I inlined the
function into its two callers.

I'm not sure about the history of tree_lowering_passes but
freeing up stuff and compacting blocks is not done consistently
at least ;)  The idea is obviously to save memory.

I'll give this the usual bootstrap & regtest testing.

Honza, does this look ok?  I am going to continue this way
until I can re-architect the toplevel pass structure in a way
that we hand control more to the pass manager.  Well, hopefully ;)

Thanks,
Richard.

2012-04-05  Richard Guenther  

* tree-pass.h (tree_lowering_passes): Remove.
* tree-optimize.c (tree_lowering_passes): Remove.
* cgraph.c (cgraph_add_new_function): Inline relevant parts
of tree_lowering_passes, avoid redundant call of early local
passes.
* cgraphunit.c (cgraph_lower_function): Fold into ...
(cgraph_analyze_function): ... its single caller.  Inline
relevant parts of tree_lowering_passes.

Index: gcc/tree-pass.h
===
*** gcc/tree-pass.h (revision 186163)
--- gcc/tree-pass.h (working copy)
*** struct register_pass_info
*** 349,356 
enum pass_positioning_ops pos_op; /* how to insert the new pass.  */
  };
  
- extern void tree_lowering_passes (tree decl);
- 
  extern struct gimple_opt_pass pass_mudflap_1;
  extern struct gimple_opt_pass pass_mudflap_2;
  extern struct gimple_opt_pass pass_lower_cf;
--- 349,354 
Index: gcc/tree-optimize.c
===
*** gcc/tree-optimize.c (revision 186163)
--- gcc/tree-optimize.c (working copy)
*** struct gimple_opt_pass pass_init_datastr
*** 366,391 
0   /* todo_flags_finish */
   }
  };
- 
- void
- tree_lowering_passes (tree fn)
- {
-   tree saved_current_function_decl = current_function_decl;
- 
-   current_function_decl = fn;
-   push_cfun (DECL_STRUCT_FUNCTION (fn));
-   gimple_register_cfg_hooks ();
-   bitmap_obstack_initialize (NULL);
-   execute_pass_list (all_lowering_passes);
-   if (optimize && cgraph_global_info_ready)
- execute_pass_list (pass_early_local_passes.pass.sub);
-   free_dominance_info (CDI_POST_DOMINATORS);
-   free_dominance_info (CDI_DOMINATORS);
-   compact_blocks ();
-   current_function_decl = saved_current_function_decl;
-   bitmap_obstack_release (NULL);
-   pop_cfun ();
- }
  
  /* For functions-as-trees languages, this performs all optimization and
 compilation for FNDECL.  */
--- 366,371 
Index: gcc/cgraph.c
===
*** gcc/cgraph.c(revision 186163)
--- gcc/cgraph.c(working copy)
*** cgraph_add_new_function (tree fndecl, bo
*** 2437,2446 
push_cfun (DECL_STRUCT_FUNCTION (fndecl));
current_function_decl = fndecl;
gimple_register_cfg_hooks ();
-   tree_lowering_passes (fndecl);
bitmap_obstack_initialize (NULL);
!   if (!gimple_in_ssa_p (DECL_STRUCT_FUNCTION (fndecl)))
! execute_pass_list (pass_early_local_passes.pass.sub);
bitmap_obstack_release (NULL);
pop_cfun ();
current_function_decl = NULL;
--- 2437,2445 
push_cfun (DECL_STRUCT_FUNCTION (fndecl));
current_function_decl = fndecl;
gimple_register_cfg_hooks ();
bitmap_obstack_initialize (NULL);
!   execute_pass_list (all_lowering_passes);
!   execute_pass_list (pass_early_local_passes.pass.sub);
bitmap_obstack_release (NULL);
pop_cfun ();
current_function_decl = NULL;
Index: gcc/cgraphunit.c
===
*** gcc/cgraphunit.c(revision 186163)
--- gcc/cgraphunit.c(working copy)
*** cgraph_reset_node (struct cgraph_node *n
*** 313,332 
cgraph_node_remove_callees (node);
  }
  
- static void
- cgraph_lower_function (struct cgraph_node *node)
- {
-   if (node->lowered)
- return;
- 
-   if (node->nested)
- lower_nested_functions (node->decl);
-   gcc_assert (!node->nested);
- 
-   tree_lowering_passes (node->decl);
-   node->lowered = true;
- }
- 
  /* DECL has been parsed.  Take it, queue it, compile it at the whim of the
 logic in effect.  If NESTED is true, then our caller cannot stand to have
 the garbage collector run at the moment.  We would need to either create
--- 313,318 
*** cgraph_an

Re: [RS6000] Stack tie fix.

[Alan Modra]

Hi Olivier,

On Thu, Apr 05, 2012 at 12:36:01PM +0200, Olivier Hainque wrote:
> On Apr 4, 2012, at 03:22 , Alan Modra wrote:
> > I'll see whether my approach fixes pr30282 for gcc-4.4 which has known
> > deficiencies in alias analysis.  Olivier, would you be kind enough to
> > backport and test against other versions of gcc that needed your
> > bigger hammer?

Well it turns out that gcc-4.4 still gets this testcase from pr30282
wrong.

int find_num(int i)
{
int arr[5] = {0, 1, 2, 3, 4};
return arr[i];
}

The read from arr[i] is scheduled past the frame teardown.

[snip]
>  There are lots of places in the emit_epilogue code that assign
>  frame_reg_rtx with different possible values, (hard_fp, sp, r11)

r12 too

>  before we first get to points where we emit ties. There are also
>  multiple places where we do emit ties.
> 
>  It is not at all obvious to me that the all places where we emit ties
>  have an accurate perception of what frame_reg's were possibly used before.
> 
>  IOW, I am not 100% convinced that we cannot have a bad case where
>  we emit a tie that misses a reg reference. The various paths are all
>  controlled by intricate conditions, so getting that 100% conviction
>  (at least on paper) isn't easy to me.
> 
>  Is it clearer to you ?

I spent quite some time looking at it. ;)  Have you spotted an error
somewhere, apart from spe_save_area_ptr not being mentioned in the
stack tie?  I left that one for a later fix since the SPE reg saves
use alias set 0 mems (which is another bug).

Hmm, I see I accidentally left out an assert from the stack tie
patch.  This one may make you feel a little better.  :)

  /* Update stack and set back pointer unless this is V.4,
 for which it was done previously.  */
  if (!WORLD_SAVE_P (info) && info->push_p
  && !(DEFAULT_ABI == ABI_V4 || crtl->calls_eh_return))
{
  rtx copy_reg = NULL;

  /* If using some other frame reg previously, then we ought to
 ensure it is mentioned in the stack tie emitted below.  */
  gcc_checking_assert (REGNO (frame_reg_rtx) == 1
   || REGNO (frame_reg_rtx) == 12);


>  FWIW, I had made an experiment at trying to extract subfunctions,
>  which might help such reasoning.  Set of patches attached. This doesn't
>  apply to the current mainline, would need to refined, and we probably
>  couldn't/shouldn't put something like this on the path to the resolution
>  of our current issue, so this is JIC you are curious.

I think this is worthwhile doing, but more important to try to make
the logic simpler.  For example, this

  /* If we need to save CR, put it into r12 or r11.  */
  if (!WORLD_SAVE_P (info) && info->cr_save_p && frame_reg_rtx != frame_ptr_rtx)
{
  rtx set;

  cr_save_rtx
= gen_rtx_REG (SImode, DEFAULT_ABI == ABI_AIX && !saving_GPRs_inline
   ? 11 : 12);

is better written as

  /* If we need to save CR, put it into r12 or r11.  */
  cr_save_regno = DEFAULT_ABI == ABI_AIX && !saving_GPRs_inline ? 11 : 12;
  if (!WORLD_SAVE_P (info)
  && info->cr_save_p
  && REGNO (frame_reg_rtx) != cr_save_regno)
{
  rtx set;

  cr_save_rtx = gen_rtx_REG (SImode, cr_save_regno);

This way it's obvious why there is a test of frame_reg_rtx, and that
the test is correct.  ie. you aren't clobbering frame_reg_rtx with cr.

-- 
Alan Modra
Australia Development Lab, IBM

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Niels de Vos]

On 04/05/2012 03:30 PM, Konstantinos Margaritis wrote:

On Wed, 4 Apr 2012 07:09:46 -0500
Dennis Gilmore  wrote:

Fedora does use /lib64 on x86_64 I would personally prefer /libhfp but
wouldn't object to /libhf  though today we have f17 about to go beta
and all of rawhide built using /lib


Hi Dennis,

One potential problem that is born from the /libhf suggestion is the
danger of having a new top level directory (/libhf) with only one
file, the dynamic linker. AFAIU it, no distro is currently willing to
move away from its existing scheme (/lib), Debian is most likely not
going to, at best there could be a symlink /libhf ->  /lib/,
but that is not solving the problem IMHO. What about other distros,
if everyone is going to use a symlink for /libhf, then even
suggesting it and relying on new top-level directories to solve the
problem is the wrong approach.

Loic suggested a -IMHO- better solution: to change the dynamic linker
filename, not the dir, i.e. /lib/ld-linux-hf.so.3 (for this
particular case).


Note that Fedora is a moving target and there already was a mentioning¹ 
of /lib/ for libraries earlier this year during a developers 
conference². I am not sure what the current status of that proposal is, 
but I think it is entirely possible that Fedora may follow the format 
Debian is using.


Cheers,
Niels


¹ see page 5 from this presentation: 
http://rvokal.fedorapeople.org/devconf2012/harald-A_streamlined_and_fully_compatible_Linux_Files.pdf


² http://fedoraproject.org/wiki/DeveloperConference2012

[PATCH] Remove definition of LANG_HOOKS_CALLGRAPH_EXPAND_FUNCTION

[Richard Guenther]

It's gone since 2007.

Committed as obvious.

Richard.

2012-04-05  Richard Guenther  

* lto-lang.c (LANG_HOOKS_CALLGRAPH_EXPAND_FUNCTION): Remove
definition.

Index: lto-lang.c
===
--- lto-lang.c  (revision 186165)
+++ lto-lang.c  (working copy)
@@ -1259,8 +1259,6 @@ static void lto_init_ts (void)
 #define LANG_HOOKS_INIT lto_init
 #undef LANG_HOOKS_PARSE_FILE
 #define LANG_HOOKS_PARSE_FILE lto_main
-#undef LANG_HOOKS_CALLGRAPH_EXPAND_FUNCTION
-#define LANG_HOOKS_CALLGRAPH_EXPAND_FUNCTION tree_rest_of_compilation
 #undef LANG_HOOKS_REDUCE_BIT_FIELD_OPERATIONS
 #define LANG_HOOKS_REDUCE_BIT_FIELD_OPERATIONS true
 #undef LANG_HOOKS_TYPES_COMPATIBLE_P

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Steve McIntyre]

On Wed, Apr 04, 2012 at 01:11:33AM +0200, Jakub Jelinek wrote:
>On Wed, Apr 04, 2012 at 09:18:59AM +1200, Michael Hope wrote:
>> >> The subdirectories could be called fred and jim and it would still work.
>> >>  The only thing required is that this part of the naming scheme be
>> >> agreed amongst the distros.
>> >>
>> >> This looks to me like it's turning into a bike-shed painting excerise
>> >> between the distros out there.  That's really sad.
>> >
>> > I don't think we ever even had the discussion: Debian invented their
>> > Debian-internal scheme for managing multiple ABIs.  They have in the past
>> > used patched versions of gcc, as in the case of x86_64.
>> 
>> (cc'ed cross-distro as the discussion is also going on there[1].  This
>> patch continues that)
>> 
>> I like the idea of incompatible binaries having different loaders.
>> The path doesn't matter but the concept does.  Like i686/x86_64, it
>> gives distros the option to install different binaries alongside each
>> other for compatibility, performance, or upgrade reasons.  The
>> compatibility cost is nice and low and lets Debian do some interesting
>> cross development things.
>
>Does the dynamic linker itself contain any routines that depend on the
>soft/hard ABI?  That would quite surprise me, so I don't see the point of
>having different dynamic linkers for those ABIs.  One dynamic linker should
>handle both just fine.

That's been discussed previously, yes. While technically quite
feasible in terms of code, there's enough potential for confusion that
we though it was just simpler to use two different linker binaries.

Cheers,
-- 
Steve McIntyresteve.mcint...@linaro.org
 Linaro.org | Open source software for ARM SoCs

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Steve McIntyre]

On Wed, Apr 04, 2012 at 01:34:30PM +1200, Michael Hope wrote:
>2012/4/4 Paulo César Pereira de Andrade
>>
>>  I did two ports of Mandriva to armv7. One of my choice to use softfp,
>> and another hardfp port to be compatible with other distros. But other
>> than a previous armv5 port, there is not much else of Mandriva arm,
>> so, it would be "good to have" to be able to run binaries for either
>> without resorting to a chroot, and only testing purposes.
>>
>>  Bumping major or calling it ld-linux-foo.so.3 is out of question?
>
>I suspect /lib/ld-linux-$foo.so.3 would be fine.  There's two
>questions here though: can the hard float loader have a different path
>and, if so, what should it be?  We're still working on the first part.

We've previously discussed changing the name or the version number of
the linker, but there was a worry that compatibility would be
broken. Apparently the Meego folks have released a hard-float system
using ld-linux.so.3 and were concerned about this.

Cheers,
-- 
Steve McIntyresteve.mcint...@linaro.org
 Linaro.org | Open source software for ARM SoCs

Re: [PATCH][ARM] NEON DImode not

[Andrew Stubbs]

On 28/03/12 14:37, Ramana Radhakrishnan wrote:

OK if no regressions.


There was a small problem with VMVN being not actually predicable. I've 
made the obvious change and committed the attached.


Andrew
2012-04-05  Andrew Stubbs  

	gcc/
	* config/arm/arm.md (arch): Add neon_onlya8 and neon_nota8.
	(arch_enabled): Handle new arch types.
	(one_cmpldi2): Add NEON support.

diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index 751997f..383c585 100644
--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -207,7 +207,7 @@
 ; for ARM or Thumb-2 with arm_arch6, and nov6 for ARM without
 ; arm_arch6.  This attribute is used to compute attribute "enabled",
 ; use type "any" to enable an alternative in all cases.
-(define_attr "arch" "any,a,t,32,t1,t2,v6,nov6,onlya8,nota8"
+(define_attr "arch" "any,a,t,32,t1,t2,v6,nov6,onlya8,neon_onlya8,nota8,neon_nota8"
   (const_string "any"))
 
 (define_attr "arch_enabled" "no,yes"
@@ -246,8 +246,18 @@
 	  (eq_attr "tune" "cortexa8"))
 	 (const_string "yes")
 
+	 (and (eq_attr "arch" "neon_onlya8")
+	  (eq_attr "tune" "cortexa8")
+	  (match_test "TARGET_NEON"))
+	 (const_string "yes")
+
 	 (and (eq_attr "arch" "nota8")
 	  (not (eq_attr "tune" "cortexa8")))
+	 (const_string "yes")
+
+	 (and (eq_attr "arch" "neon_nota8")
+	  (not (eq_attr "tune" "cortexa8"))
+	  (match_test "TARGET_NEON"))
 	 (const_string "yes")]
 	(const_string "no")))
 
@@ -4207,11 +4217,16 @@
   "")
 
 (define_insn_and_split "one_cmpldi2"
-  [(set (match_operand:DI 0 "s_register_operand" "=&r,&r")
-	(not:DI (match_operand:DI 1 "s_register_operand" "0,r")))]
+  [(set (match_operand:DI 0 "s_register_operand"	 "=w,&r,&r,?w")
+	(not:DI (match_operand:DI 1 "s_register_operand" " w, 0, r, w")))]
   "TARGET_32BIT"
-  "#"
-  "TARGET_32BIT && reload_completed"
+  "@
+   vmvn\t%P0, %P1
+   #
+   #
+   vmvn\t%P0, %P1"
+  "TARGET_32BIT && reload_completed
+   && arm_general_register_operand (operands[0], DImode)"
   [(set (match_dup 0) (not:SI (match_dup 1)))
(set (match_dup 2) (not:SI (match_dup 3)))]
   "
@@ -4221,8 +4236,10 @@
 operands[3] = gen_highpart (SImode, operands[1]);
 operands[1] = gen_lowpart (SImode, operands[1]);
   }"
-  [(set_attr "length" "8")
-   (set_attr "predicable" "yes")]
+  [(set_attr "length" "*,8,8,*")
+   (set_attr "predicable" "no,yes,yes,no")
+   (set_attr "neon_type" "neon_int_1,*,*,neon_int_1")
+   (set_attr "arch" "neon_nota8,*,*,neon_onlya8")]
 )
 
 (define_expand "one_cmplsi2"

Re: [PATCH][1/n] Cleanup global pass execution flow

[Jan Hubicka]

> 
> I'm trying to get an idea where and why we execute what part of the
> pass pipeline (yeah, a two-line patch doing -Og should be possible
> after this series ...).  This patch removes an odd caller of
> execute_pass_list (pass_early_local_passes.pass.sub), named
> tree_lowering_passes, which is even undocumented.  The two callers
> will end up executing distinct parts of the function and the
> function performs unnecessary setup.  Thus I inlined the
> function into its two callers.
> 
> I'm not sure about the history of tree_lowering_passes but
> freeing up stuff and compacting blocks is not done consistently
> at least ;)  The idea is obviously to save memory.
> 
> I'll give this the usual bootstrap & regtest testing.
> 
> Honza, does this look ok?  I am going to continue this way
> until I can re-architect the toplevel pass structure in a way
> that we hand control more to the pass manager.  Well, hopefully ;)

Yes, it seems fine.
The original idea was to have limited entry points into the pass
manager and have one function per every action instead of exposing
pass lists as our interface. 

That is 
 - lowering passes that used to be executed during the parsing
   to output lower level warnings early enough and compact function
   body representation to save memory. 
   This was supposed to happen on all functions, even unused, to get
   more consistency of errors/warnings output here.

   So program was at one point represented in the lowered functions.  This the
   reason for compactification/dominator tree destruction.  The idea was to do
   this cleanup always when we ended up having program represented in this form 
at
   once.  That is after lowering, early opt, IPA and assembling

   This is what tree_lowering_passes used to be.
 - early optimization passes done during the construction of callgraph
   lazilly only for reachable functions. 
   At the end of this stage unused stuff was removed and this stage
   used to happen at the end of each source unit for --combine, so
   we don't blow up memory completely for --combine GCC bootstrap.
 - IPA passes

   This is ipa_passes that sits in cgraphunit.c more or less for
   historical reasons when non-cgraph enabled frontends would not
   link anymore if it was elsewhere.
   (cgraph.c and rest was part of libbackend.a, while cgraphunit.c
   and tree-inline.c was part only of cgraph enabled backend, that
   is not f77, and it was having access to tree walking stuff).
 - rest of optimization executed form final pass over cgraph when
   it is being output and destroyed.

   (tree_rest_of_compilation, that probably should also go)

My longer term plan was to get cgraphunit out of busyness by moving
all the compilation driving logic (i.e. cgraph_optimize) into passes.c
and moving most of stuff done out of pass manager into passes.

Things got more complicated with introduction of LTO/WHOPR and we moved
to unit-at-a-time gimplification that killed original purpose of lowering
pases.  

Honza

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Steve McIntyre]

On Tue, Apr 03, 2012 at 10:56:18PM +, Joseph S. Myers wrote:
>
>(c) Please include libc-ports on future submissions and provide both the 
>GCC patch and the glibc ports patch that have been tested to work together 
>to build and install the library in the given path; a patch to one 
>component like this cannot sensibly be considered in isolation.  I imagine 
>you'll need appropriate ARM preconfigure support to detect what ABI the 
>compiler is using, much like the support for MIPS, so that the right 
>shlib-versions files are used.  I try to follow all ARM glibc discussions 
>on libc-ports closely, as the ARM glibc maintainer; was there a previous 
>discussion of the dynamic linker naming issue there that I missed?  (The 
>only previous relevant discussion that I recall is one on 
>patc...@eglibc.org starting at 
>, regarding how the 
>dynamic linker should check that a library has the right ABI, and there 
>was no real followup on that after I indicated what would seem to be the 
>appropriate implementation approaches and places for subsequent 
>discussion.)

Apologies, that was my fault - I was kept busy on other things and
didn't get back to that. At the time it didn't seem so critical when
we were still experimenting with other aspects of the system. I'll get
back to that shortly...

Cheers,
-- 
Steve McIntyresteve.mcint...@linaro.org
 Linaro.org | Open source software for ARM SoCs

[Libiberty - V2]: Handle VMS as a LLP64 platform in splay-tree.h

[Tristan Gingold]

On Apr 4, 2012, at 5:07 PM, Ian Lance Taylor wrote:

> Tristan Gingold  writes:
> 
>> Would something like that be acceptable ?
>> I have just checked that I can still build gcc with that patch.  If you like 
>> this approach I will properly submit a patch.
> 
> Thanks.
> 
> You should also test that gdb continues to build with this patch.
> 
> I guess the question here is portability.  Do we still care about
> portability to systems that have neither inttypes.h nor stdint.h?  I'm
> willing to try this and see if anybody complains.
> 
> Ian

Hi,

here is my formal patch submission.  I am not concerned by portability as
configure will define uintptr_t if not found in inttypes.h or stdint.h
(both in libiberty and gcc.  gdb indeed uses stdint.h from gnulib).

Tested by bootstrapping gcc for c,c++ and fortran on x86_64-darwin,
and by building gdb on x86_64-darwin.

Ok for trunk ?

Tristan.

gcc/
2012-04-05  Tristan Gingold  

* gengtype.c (main): Make uintptr_t a known type.

include/
2012-04-05  Tristan Gingold  

* splay-tree.h: Conditionnaly includes stdint.h and inttypes.h
(libi_uhostptr_t, libi_shostptr_t): Remove, replaced by uintptr_t.

diff --git a/gcc/gengtype.c b/gcc/gengtype.c
index 7450eeb..fa45392 100644
--- a/gcc/gengtype.c
+++ b/gcc/gengtype.c
@@ -4976,6 +4976,7 @@ main (int argc, char **argv)
   POS_HERE (do_scalar_typedef ("double_int", &pos));
   POS_HERE (do_scalar_typedef ("uint64_t", &pos));
   POS_HERE (do_scalar_typedef ("uint8", &pos));
+  POS_HERE (do_scalar_typedef ("uintptr_t", &pos));
   POS_HERE (do_scalar_typedef ("jword", &pos));
   POS_HERE (do_scalar_typedef ("JCF_u2", &pos));
   POS_HERE (do_scalar_typedef ("void", &pos));


diff --git a/include/splay-tree.h b/include/splay-tree.h
index 480b2c4..a26135a 100644
--- a/include/splay-tree.h
+++ b/include/splay-tree.h
@@ -37,18 +37,11 @@ extern "C" {
 
 #include "ansidecl.h"
 
-#ifndef _WIN64
-  typedef unsigned long int libi_uhostptr_t;
-  typedef long int libi_shostptr_t;
-#else
-#ifdef __GNUC__
-  __extension__
+#ifdef HAVE_STDINT_H
+#include 
 #endif
-  typedef unsigned long long libi_uhostptr_t;
-#ifdef __GNUC__
-  __extension__
-#endif
-  typedef long long libi_shostptr_t;
+#ifdef HAVE_INTTYPES_H
+#include 
 #endif
 
 #ifndef GTY
@@ -59,8 +52,8 @@ extern "C" {
these types, if necessary.  These types should be sufficiently wide
that any pointer or scalar can be cast to these types, and then
cast back, without loss of precision.  */
-typedef libi_uhostptr_t splay_tree_key;
-typedef libi_uhostptr_t splay_tree_value;
+typedef uintptr_t splay_tree_key;
+typedef uintptr_t splay_tree_value;
 
 /* Forward declaration for a node in the tree.  */
 typedef struct splay_tree_node_s *splay_tree_node;

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Mike Frysinger]

On Thursday 05 April 2012 09:30:23 Konstantinos Margaritis wrote:
> On Wed, 4 Apr 2012 07:09:46 -0500 Dennis Gilmore wrote:
> > Fedora does use /lib64 on x86_64 I would personally prefer /libhfp but
> > wouldn't object to /libhf  though today we have f17 about to go beta
> > and all of rawhide built using /lib
> 
>   One potential problem that is born from the /libhf suggestion is the
> danger of having a new top level directory (/libhf) with only one file,
> the dynamic linker. AFAIU it, no distro is currently willing to move away
> from its existing scheme (/lib)

i don't think that's true.  on an x86_64 system, the 64bit libs are in 
/lib64/.  some distros tried to (pointlessly imo) resist and force 64bits into 
/lib/ when the native ABI was x86_64 (Gentoo included), but those are legacy 
imo, and afaik, they didn't break the ldso paths.

so in a setup that only has hardfloat binaries, you'd have all the libs in 
/libhf/, not just the ldso.

> Loic suggested a -IMHO- better solution: to change the dynamic linker
> filename, not the dir, i.e. /lib/ld-linux-hf.so.3 (for this particular
> case).

the implication in supporting both hardfloat and softfloat simultaneously is 
that you'd could have them both installed.  thus putting them both in /lib/ 
doesn't make much sense if you're still going to need /libhf/ to hold 
everything else.
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Mike Frysinger]

On Thursday 05 April 2012 10:38:07 Steve McIntyre wrote:
> On Wed, Apr 04, 2012 at 01:34:30PM +1200, Michael Hope wrote:
> >2012/4/4 Paulo César Pereira de Andrade
> >
> >>  I did two ports of Mandriva to armv7. One of my choice to use softfp,
> >> and another hardfp port to be compatible with other distros. But other
> >> than a previous armv5 port, there is not much else of Mandriva arm,
> >> so, it would be "good to have" to be able to run binaries for either
> >> without resorting to a chroot, and only testing purposes.
> >> 
> >>  Bumping major or calling it ld-linux-foo.so.3 is out of question?
> >
> >I suspect /lib/ld-linux-$foo.so.3 would be fine.  There's two
> >questions here though: can the hard float loader have a different path
> >and, if so, what should it be?  We're still working on the first part.
> 
> We've previously discussed changing the name or the version number of
> the linker, but there was a worry that compatibility would be
> broken. Apparently the Meego folks have released a hard-float system
> using ld-linux.so.3 and were concerned about this.

i'm not sure how changing the leading dir components but leaving the base path 
the same would be any more or less work for meego to maintain backwards 
compatibility.  whatever random path is picked, they're going to be broken, as 
the ELF encodes the full path to the ldso.
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH][1/n] Cleanup global pass execution flow

[Diego Novillo]

On 4/5/12 9:54 AM, Richard Guenther wrote:


Honza, does this look ok?  I am going to continue this way
until I can re-architect the toplevel pass structure in a way
that we hand control more to the pass manager.  Well, hopefully ;)


Related to this, have you thought about the handoff points between front 
ends and the middle end?


In LTO (and at some point in the gimple front end branch) we have all 
this code setting up various tidbits like:


- Creating cgraph nodes.
- Creating FUNCTION_DECLs
- Setting their gimple bodies
- Etc.

It would be nice if front ends had a single handoff point into the 
middle-end.


So, for instance, if the FE only needed to call cgraph_create_node() or 
varpool_node() to register new functions and globals.


After doing all that registration, the FE calls cgraph_optimize() (or 
some other unique entry point).


I *think* this is roughly how things work, but there seem to be various 
other cgraph/middle-end calls made from front ends.




Diego.

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Konstantinos Margaritis]

On Thu, 5 Apr 2012 11:08:56 -0400
Mike Frysinger  wrote:
> i don't think that's true.  on an x86_64 system, the 64bit libs are in 
> /lib64/.  some distros tried to (pointlessly imo) resist and force 64bits 
> into 
> /lib/ when the native ABI was x86_64 (Gentoo included), but those are legacy 
> imo, and afaik, they didn't break the ldso paths.
> 
> so in a setup that only has hardfloat binaries, you'd have all the libs in 
> /libhf/, not just the ldso.

That's exactly my concern. If /libhf is chosen for the dymamic linker path, but 
it's not adopted by everyone else for libraries and other files, then at best 
you'd have a symlink, at worst a dir with only one file inside. 

> the implication in supporting both hardfloat and softfloat simultaneously is 
> that you'd could have them both installed.  thus putting them both in /lib/ 
> doesn't make much sense if you're still going to need /libhf/ to hold 
> everything else.

That case has only any chance of realization in a multiarch environment such as 
Debian/Ubuntu. The rest won't be affected at all. And the dynamic linkers 
-different filename of course- are the only libs that will be in /lib straight, 
the rest will be in /lib/. So there is no danger of any conflict, at 
least not with libraries.

-- 
Konstantinos Margaritis 

Re: [PATCH] Compact SSA version namespace when releasing the freelist

[Diego Novillo]

On 4/5/12 6:13 AM, Richard Guenther wrote:


Currently we release the memory for released SSA names (which we keep
around on a freelist, mainly to try to keep the SSA version namespace
dense) after early optimizations.  This has the negative impact
(as documented) of permanently establishing holes in the SSA version
namespace.  The following patch fixes this in a simple way.

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

If you build fold-const.c with -O2 the distribution of released
ssa names / removed holes is as follows:

43 release_ssa "SSA names released" 34900
43 release_ssa "SSA name holes removed" 34900


Could you elaborate on what this output means?  What is 43?  What is 34900?


which means we never have "trailing" released SSA names, all SSA
names on the freelist are for holes.  The following is the
distribution over releases happening per function:

43 release_ssa "SSA name holes removed == 0" 16
43 release_ssa "SSA name holes removed == 1" 13


Likewise here.  What does this output mean?



We seem to have quite some "dead" functions in fold-const.c ;)

I didn't measure any off-noise memory/compile-time effect of this
patch though.


I ask because I don't understand these two conclusions.  You're saying 
that we don't do a lot of this, so compile-time effects should be nil?



Thanks.  Diego.

latch mem to reg before multi-access in convert_move

[Olivier Hainque]

Hello,

At some point in convert_move we have:

<>

With a previous version of the compiler, we happened to get there
pretty easily with MEM_P(from) and the multi-insn sequence producing
multiple memory references to the source.

The original problem we had with this was the introduction of an
artificial race condition in addition to the potential performance
impact.

We had fixed this with the attached patch, which simply forces "from"
into a REG if it is a MEM, in addition to the current condition.
While our original testcases don't expose the problem with current
versions of the compiler, the issue appears to remain latent and the
change still looks sensible in any case.

We have been running with it for years across several versions of 
gcc on numerous platforms. I have just bootstrapped and regtested
with mainline on x86_64-linux.

OK to commit ?

Thanks in advance,

Olivier

2012-04056  Olivier Hainque  

* expr.c (convert_move): Latch mem integer inputs into a
register before expanding a multi-instructions sequence.



memlatch.dif
Description: video/dv

Re: [PATCH][1/n] Cleanup global pass execution flow

[Jan Hubicka]

> On 4/5/12 9:54 AM, Richard Guenther wrote:
> 
> >Honza, does this look ok?  I am going to continue this way
> >until I can re-architect the toplevel pass structure in a way
> >that we hand control more to the pass manager.  Well, hopefully ;)
> 
> Related to this, have you thought about the handoff points between
> front ends and the middle end?
> 
> In LTO (and at some point in the gimple front end branch) we have
> all this code setting up various tidbits like:
> 
> - Creating cgraph nodes.
> - Creating FUNCTION_DECLs
> - Setting their gimple bodies
> - Etc.
> 
> It would be nice if front ends had a single handoff point into the
> middle-end.
> 
> So, for instance, if the FE only needed to call cgraph_create_node()
> or varpool_node() to register new functions and globals.

There are cgraph_finalize_function and varpool equivalent for this.
the actual nodes are then build lazily while constructing cgraph...

Out of date description of the basic FE API is in the beggining of
cgraphunit.c. I guess I should update it.
Have some patches to cleanup FE abuse of cgraph in queue now ad
symtab front - I am getting rid of the needed flag and thus also
all those mark_needed calls done for magical purposes.

Honza
> 
> After doing all that registration, the FE calls cgraph_optimize()
> (or some other unique entry point).
> 
> I *think* this is roughly how things work, but there seem to be
> various other cgraph/middle-end calls made from front ends.
> 
> 
> 
> Diego.

Re: PATCH: Define TRY_EMPTY_VM_SPACE for Linux/x32

[Uros Bizjak]

On Thu, Apr 5, 2012 at 3:28 PM, H.J. Lu  wrote:

 Looking at how other targets implement this check, I don't think that
 this is a problem at all. This issue only shows on a non-bootstrapped
 build. A full bootstrap will use correct address.
>>>
>>> The other place where it shows up is cross compilers but who is going
>>> to use a 3.2 compiler with GCC 4.8 anyways?
>>>
>>
>> FWIW, I have no problem with checking __LP64__ only. I just want to
>> mention this potential issue.
>>
>
> Here is a different patch.  It checks sizeof (void *) for those hosts
> where it is appropriate.  Does it look OK?

Looks OK to me, but you need a GWP reviewer to OK this change now...

Thanks,
Uros.

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Paulo César Pereira de Andrade]

Em 5 de abril de 2012 12:09, Mike Frysinger  escreveu:
> On Thursday 05 April 2012 10:38:07 Steve McIntyre wrote:
>> On Wed, Apr 04, 2012 at 01:34:30PM +1200, Michael Hope wrote:
>> >2012/4/4 Paulo César Pereira de Andrade
>> >
>> >>  I did two ports of Mandriva to armv7. One of my choice to use softfp,
>> >> and another hardfp port to be compatible with other distros. But other
>> >> than a previous armv5 port, there is not much else of Mandriva arm,
>> >> so, it would be "good to have" to be able to run binaries for either
>> >> without resorting to a chroot, and only testing purposes.
>> >>
>> >>  Bumping major or calling it ld-linux-foo.so.3 is out of question?
>> >
>> >I suspect /lib/ld-linux-$foo.so.3 would be fine.  There's two
>> >questions here though: can the hard float loader have a different path
>> >and, if so, what should it be?  We're still working on the first part.
>>
>> We've previously discussed changing the name or the version number of
>> the linker, but there was a worry that compatibility would be
>> broken. Apparently the Meego folks have released a hard-float system
>> using ld-linux.so.3 and were concerned about this.
>
> i'm not sure how changing the leading dir components but leaving the base path
> the same would be any more or less work for meego to maintain backwards
> compatibility.  whatever random path is picked, they're going to be broken, as
> the ELF encodes the full path to the ldso.
> -mike

  I guess now it is too late to defer --with-float=hard for 64 bit armv8, but
besides possibly tedious, full rebuilds of, (hopefully) yet to be released
hardfp distros per se is not a bad thing.

  My suggestion for lib$color is $color == vfp (one could choose neon :-),
and then it is a distro choice if using /lib as software float to be able to
install the same binaries on armv4+, or build with vfp but use software float
abi so that armv4+ binaries work.

  Major issue IMO is that things are being done thinking too much on
the now, so, hardfp is good to support nvidia drivers, and plain soft float
(armv5) is good for raspberry pi...

> ___
> cross-distro mailing list
> cross-dis...@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/cross-distro

Paulo

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Mike Frysinger]

On Thursday 05 April 2012 11:24:15 Konstantinos Margaritis wrote:
> On Thu, 5 Apr 2012 11:08:56 -0400 Mike Frysinger wrote:
> > i don't think that's true.  on an x86_64 system, the 64bit libs are in
> > /lib64/.  some distros tried to (pointlessly imo) resist and force 64bits
> > into /lib/ when the native ABI was x86_64 (Gentoo included), but those
> > are legacy imo, and afaik, they didn't break the ldso paths.
> > 
> > so in a setup that only has hardfloat binaries, you'd have all the libs
> > in /libhf/, not just the ldso.
> 
> That's exactly my concern. If /libhf is chosen for the dymamic linker path,
> but it's not adopted by everyone else for libraries and other files, then
> at best you'd have a symlink, at worst a dir with only one file inside.

if gcc declares libhf as another multilib target, then everyone else will get 
it automatically

note: i don't care about /lib/ld-linux-hf.so.3 or /lib/ld-linux.so.4 or 
/libhf/ld-linux.so.[34].  /lib// is really the only one i don't 
think doesn't belong.

> > the implication in supporting both hardfloat and softfloat simultaneously
> > is that you'd could have them both installed.  thus putting them both in
> > /lib/ doesn't make much sense if you're still going to need /libhf/ to
> > hold everything else.
> 
> That case has only any chance of realization in a multiarch environment
> such as Debian/Ubuntu.

don't really know what you're talking about here.  other distros have no 
problem with handling multilib.
-mike


signature.asc
Description: This is a digitally signed message part.

Re: PATCH: Define TRY_EMPTY_VM_SPACE for Linux/x32

[H.J. Lu]

On Thu, Apr 5, 2012 at 8:36 AM, Uros Bizjak  wrote:
> On Thu, Apr 5, 2012 at 3:28 PM, H.J. Lu  wrote:
>
> Looking at how other targets implement this check, I don't think that
> this is a problem at all. This issue only shows on a non-bootstrapped
> build. A full bootstrap will use correct address.

 The other place where it shows up is cross compilers but who is going
 to use a 3.2 compiler with GCC 4.8 anyways?

>>>
>>> FWIW, I have no problem with checking __LP64__ only. I just want to
>>> mention this potential issue.
>>>
>>
>> Here is a different patch.  It checks sizeof (void *) for those hosts
>> where it is appropriate.  Does it look OK?
>
> Looks OK to me, but you need a GWP reviewer to OK this change now...
>

Here is the patch with ChangeLog.  Tested on Linux/x32.  Jakub,
is this OK for trunk?

Thanks.


-- 
H.J.
2012-04-03  H.J. Lu  

	* config/host-linux.c (TRY_EMPTY_VM_SPACE): Check pointer size
	for alpha, arm, i386 and x86-64.

diff --git a/gcc/config/host-linux.c b/gcc/config/host-linux.c
index 94b7a0b..93c513e 100644
--- a/gcc/config/host-linux.c
+++ b/gcc/config/host-linux.c
@@ -64,14 +64,12 @@
 
 /* For various ports, try to guess a fixed spot in the vm space
that's probably free.  */
-#if defined(__alpha)
-# define TRY_EMPTY_VM_SPACE	0x100
+#if defined(__alpha) || defined(__ARM_EABI__) || defined(__i386) \
+|| defined(__x86_64)
+# define TRY_EMPTY_VM_SPACE	\
+  (sizeof (void *) == 8 ? 0x10 : 0x6000)
 #elif defined(__ia64)
 # define TRY_EMPTY_VM_SPACE	0x2001
-#elif defined(__x86_64)
-# define TRY_EMPTY_VM_SPACE	0x10
-#elif defined(__i386)
-# define TRY_EMPTY_VM_SPACE	0x6000
 #elif defined(__powerpc__)
 # define TRY_EMPTY_VM_SPACE	0x6000
 #elif defined(__s390x__)
@@ -84,8 +82,6 @@
 # define TRY_EMPTY_VM_SPACE	0x6000
 #elif defined(__mc68000__)
 # define TRY_EMPTY_VM_SPACE	0x4000
-#elif defined(__ARM_EABI__)
-# define TRY_EMPTY_VM_SPACE 0x6000
 #elif defined(__mips__) && defined(__LP64__)
 # define TRY_EMPTY_VM_SPACE	0x80
 #elif defined(__mips__)

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Steve McIntyre]

On Thu, Apr 05, 2012 at 11:32:39AM +1200, Michael Hope wrote:
>
>So:
> * Big endian: undefined, defaults to /lib/ld-linux.so.3
> * Little endian, soft float: /lib/ld-linux.so.3
> * Little endian, hard float: /libhf/ld-linux.so.3
>
>> Standard upstream practice supports having multiple variants that
>> plausibly run on the same system at the same time, such as /lib and
>> /lib64, and it seems reasonable to support hard and soft float variants
>> that way via a directory such as /libhf.  The Debian-style paths are not
>> the default on any other architecture and I don't think it's appropriate
>> to make them the default for this particular case only.
>
>OK.  Debian multiarch covers libraries and headers but not
>executables.  As a MIPS hard float /usr/bin/ls would collide with an
>ARM hard float /usr/bin/ls then it's fine for the loader names to
>potentially collide as well.
>
>In practice they wouldn't as most architecture has a subtily different
>loader name (cf. ld.so.1 for MIPS, ld-linux.so.2 for i386, and
>ld-linux.so.3 for ARM).

Yes, thankfully. More by luck than any design.

Cheers,
-- 
Steve McIntyresteve.mcint...@linaro.org
 Linaro.org | Open source software for ARM SoCs

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Steve McIntyre]

On Thu, Apr 05, 2012 at 01:16:27PM +1200, Michael Hope wrote:
>On 5 April 2012 12:07, Joseph S. Myers  wrote:
>>
>> No.  A system is either purely hard-float or purely soft-float, and the
>> same paths are used for both so they can't coexist.  (Mismatches at
>> *static* link time are detected through object attributes.)
>
>Ah, the same as ARM then.  The MIPS community would need something
>similar to this patch if they wanted to support soft and hard float
>side by side.

Yes, definitely.

>>> Big endian is extremely uncommon on ARM and I'd rather define it when
>>> needed.  For strictness sake I'll change the patch to use the new path
>>> for hard float little endian only.
>>
>> I don't think that's correct; the new path should be used independent of
>> endian, just as the existing path is.
>
>OK.
>
>> But any multiarch support patch
>> should presumably define separate multiarch paths for each endianness.
>
>That's up to Debian.  I've asked for documentation on the final tuples
>and what they mean as the one at:
> http://wiki.debian.org/Multiarch/Tuples
>
>is out of date.  I prefer defining what is needed now and doing others
>as needed.

I'm most of the way through an update for that page now; I'll ask for
comments/review shortly.

Cheers,
-- 
Steve McIntyresteve.mcint...@linaro.org
 Linaro.org | Open source software for ARM SoCs

[patch optimization]: Add some basic folding for ==/!= comparison

[Kai Tietz]

Hello,

this patch adds some basic folding capabilities to fold-const for
equal and none-equal comparisons
on integer typed argument.

ChangeLog

2012-04-05  Kai Tietz  

* fold-const.c (fold_comparison_1): New
function.
(fold_comparison): Use fold_comparison_1.

2012-04-05  Kai Tietz  

* gcc.dg/fold-compare-1.c: Adjust matching rule
for a == b without argument swap.
* gcc.dg/fold-compare-7.c: New test.

Regession tested for x86_64-unknown-linux-gnu for all languages
(including Ada and Obj-C++).  Ok for apply?

Regards,
Kai

Index: gcc/gcc/fold-const.c
===
--- gcc.orig/gcc/fold-const.c
+++ gcc/gcc/fold-const.c
@@ -8739,6 +8739,241 @@ pointer_may_wrap_p (tree base, tree offs
   return total_low > (unsigned HOST_WIDE_INT) size;
 }

+/* Sub-routine of fold_comparison.  Folding of EQ_EXPR/NE_EXPR
+   comparisons with integral typed arguments.  */
+
+static tree
+fold_comparison_1 (location_t loc, enum tree_code code, tree type,
+  tree arg0, tree arg1)
+{
+  enum tree_code c1, c2;
+  tree optype, op0, op1, opr0, opr1, tem;
+
+  if (code != NE_EXPR && code != EQ_EXPR)
+return NULL_TREE;
+
+  optype = TREE_TYPE (arg0);
+  if (!INTEGRAL_TYPE_P (optype))
+return NULL_TREE;
+
+  c1 = TREE_CODE (arg0);
+  c2 = TREE_CODE (arg1);
+
+  /* Integer constant is on right-hand side.  */
+  if (c1 == INTEGER_CST
+  && c2 != c1)
+return fold_build2_loc (loc, code, type, arg1, arg0);
+
+  if (!TREE_SIDE_EFFECTS (arg0)
+  && operand_equal_p (arg0, arg1, 0))
+{
+  if (code == EQ_EXPR)
+return build_one_cst (type);
+  return build_zero_cst (type);
+}
+   
+
+  if (c1 == NEGATE_EXPR)
+{
+  op0 = TREE_OPERAND (arg0, 0);
+  /* -X ==/!= -Y -> X ==/!= Y.  */
+  if (c2 == c1)
+return fold_build2_loc (loc, code, type,
+   op0,
+   TREE_OPERAND (arg1, 0));
+  /* -X ==/!= CST -> X ==/!= CST' with CST'= -CST.  */
+  else if (c2 == INTEGER_CST)
+return fold_build2_loc (loc, code, type, op0,
+   fold_build1_loc (loc, NEGATE_EXPR,
+optype, arg1));
+ }
+  else if (c1 == BIT_NOT_EXPR)
+{
+  op0 = TREE_OPERAND (arg0, 0);
+  /* ~X ==/!= ~Y -> X ==/!= Y.  */
+  if (c2 == c1)
+return fold_build2_loc (loc, code, type, op0,
+   TREE_OPERAND (arg1, 0));
+  /* ~X ==/!= CST -> X ==/!= CST' with CST'= ~CST.  */
+  else if (c2 == INTEGER_CST)
+return fold_build2_loc (loc, code, type, op0,
+   fold_build1_loc (loc, BIT_NOT_EXPR,
+optype, arg1));
+}
+
+  /* See if we can simplify case X == (Y +|-|^ Z).  */
+  if (c1 != PLUS_EXPR && c1 != MINUS_EXPR && c1 != BIT_XOR_EXPR)
+{
+  if ((c2 != PLUS_EXPR && c2 != MINUS_EXPR
+   && c2 != BIT_XOR_EXPR)
+  || TREE_SIDE_EFFECTS (arg0))
+return NULL_TREE;
+
+  op0 = TREE_OPERAND (arg1, 0);
+  op1 = TREE_OPERAND (arg1, 1);
+
+  /* Convert temporary X - Y to X + (-Y).  */
+  if (c2 == MINUS_EXPR)
+op1 = fold_build1_loc (loc, NEGATE_EXPR, optype, op1);
+
+  /* Check if we can simplify X ==/!= (X ^ Y) to Y ==/!= 0,
+ or X ==/!= (X +|- Y) to Y ==/!= 0.  */
+  tem = fold_build2_loc (loc, (c2 == BIT_XOR_EXPR ? c2 : MINUS_EXPR),
+optype, arg0, op0);
+  if (TREE_CODE (tem) == INTEGER_CST
+ && (integer_zerop (tem) || TYPE_UNSIGNED (optype)
+ || c2 == BIT_XOR_EXPR))
+   return fold_build2_loc (loc, code, type, op1, tem);
+
+  /* Check if we can simplify X ==/!= (Y ^ X) to Y ==/!= 0,
+ or X ==/!= (Y + X) to Y ==/!= 0.  */
+  tem = fold_build2_loc (loc, (c2 == BIT_XOR_EXPR ? c2 : MINUS_EXPR),
+optype, arg0, op1);
+  if (TREE_CODE (tem) == INTEGER_CST
+ && (integer_zerop (tem) || TYPE_UNSIGNED (optype)
+ || c2 == BIT_XOR_EXPR))
+   return fold_build2_loc (loc, code, type, op0, tem);
+}
+  else if (c2 != PLUS_EXPR && c2 != MINUS_EXPR && c2 != BIT_XOR_EXPR)
+{
+  if ((c1 != PLUS_EXPR && c1 != MINUS_EXPR
+   && c1 != BIT_XOR_EXPR)
+  || TREE_SIDE_EFFECTS (arg1))
+return NULL_TREE;
+
+  op0 = TREE_OPERAND (arg0, 0);
+  op1 = TREE_OPERAND (arg0, 1);
+
+  /* Convert temporary X - Y to X + (-Y).  */
+  if (c1 == MINUS_EXPR)
+op1 = fold_build1_loc (loc, NEGATE_EXPR, optype, op1);
+
+  /* Check if we can simplify X ==/!= (X ^ Y) to Y ==/!= 0,
+ or X ==/!= (X +|- Y) to Y ==/!= 0.  */
+  tem = fold_build2_loc (loc, (c1 == BIT_XOR_EXPR ? c1 : MINUS_EXPR),
+optype, arg1, op0);
+  if (TREE_CODE (tem) == INTEGER_CST
+ && (integer_

Re: [branches/google/gcc-4_6] Backported r179661 and 179662 from mainline. (issue 5989043)

[Xinliang David Li]

ok for google branches

David

On Wed, Apr 4, 2012 at 8:56 PM,   wrote:
> Reviewers: Diego Novillo, jingyu, davidxl,
>
> Message:
> Please take a look at this patch and tell me if it's OK for
> branches/google/gcc-4_6.
>
> Description:
> Backported the following patch from trunk:
>
> 2011-10-07  Andrew Stubbs  
>
>    gcc/
>    * config/arm/predicates.md (shift_amount_operand): Remove constant
>    range check.
>    (shift_operator): Check range of constants for all shift operators.
>
>    gcc/testsuite/
>    * gcc.dg/pr50193-1.c: New file.
>    * gcc.target/arm/shiftable.c: New file.
>
>
> Please review this at http://codereview.appspot.com/5989043/
>
> Affected files:
>   M    .
>  M     gcc/ChangeLog
>  M     gcc/ChangeLog.google-4_6
>  M     gcc/config/arm/predicates.md
>  M     gcc/testsuite/ChangeLog
>  A  +  gcc/testsuite/gcc.dg/pr50193-1.c
>  A  +  gcc/testsuite/gcc.target/arm/shiftable.c
>
>

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Steve McIntyre]

On Thu, Apr 05, 2012 at 11:08:56AM -0400, Mike Frysinger wrote:
>On Thursday 05 April 2012 09:30:23 Konstantinos Margaritis wrote:
>> On Wed, 4 Apr 2012 07:09:46 -0500 Dennis Gilmore wrote:
>> > Fedora does use /lib64 on x86_64 I would personally prefer /libhfp but
>> > wouldn't object to /libhf  though today we have f17 about to go beta
>> > and all of rawhide built using /lib
>> 
>>   One potential problem that is born from the /libhf suggestion is the
>> danger of having a new top level directory (/libhf) with only one file,
>> the dynamic linker. AFAIU it, no distro is currently willing to move away
>> from its existing scheme (/lib)
>
>i don't think that's true.  on an x86_64 system, the 64bit libs are in 
>/lib64/.  some distros tried to (pointlessly imo) resist and force 64bits into 
>/lib/ when the native ABI was x86_64 (Gentoo included), but those are legacy 
>imo, and afaik, they didn't break the ldso paths.
>
>so in a setup that only has hardfloat binaries, you'd have all the libs in 
>/libhf/, not just the ldso.
>
>> Loic suggested a -IMHO- better solution: to change the dynamic linker
>> filename, not the dir, i.e. /lib/ld-linux-hf.so.3 (for this particular
>> case).
>
>the implication in supporting both hardfloat and softfloat simultaneously is 
>that you'd could have them both installed.  thus putting them both in /lib/ 
>doesn't make much sense if you're still going to need /libhf/ to hold 
>everything else.

Except you wouldn't - the Debian/Ubuntu plan with multi-arch is to put
them all in cleanly-separated paths corresponding to the triplets.

I'm concerned that the potential proliferation of /lib* directories
here could become very messy over time. I'm surprised that people seem
to be happy to invent another namespace on a much more ad-hoc and
arbitrary basis than the (mostly) well-understood triplets that we
already have defined in the toolchains.

Multi-arch is an attempt to make things cleaner for those of us that
care about having lots of different platforms supported in
parallel. Seen against that background, I was hoping that using the
multi-arch path for the armhf linker would make sense. For people that
don't care about multi-arch for themselves, a simple symbolic link is
all that's needed.

Cheers,
-- 
Steve McIntyresteve.mcint...@linaro.org
 Linaro.org | Open source software for ARM SoCs

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Konstantinos Margaritis]

On Thu, 5 Apr 2012 11:55:14 -0400
Mike Frysinger  wrote: 
> note: i don't care about /lib/ld-linux-hf.so.3 or /lib/ld-linux.so.4 or 
> /libhf/ld-linux.so.[34].  /lib// is really the only one i 
> don't 
> think doesn't belong.

and I'm just saying that I dislike /libhf, I also think that just raising the 
version is a wrong solution.

> don't really know what you're talking about here.  other distros have no 
> problem with handling multilib.

multilib for softfloat/hardfloat on arm? I don't think so, even for other 
arches -it was already demonstrated that you cannot e.g. have powerpc e500v2 
and e600 installed concurrently, and anyway that's not the topic of the 
discussion here. Apart from multiarch there is no other solution to do that 
*for* arm, at least at the moment, because the two ABIs use exactly the same 
paths on a non-multiarch system. And I get back to the proposed solution /libhf 
-which is the multilib path you're referring to- and I'm saying that the topic 
here is for the linker path alone. In the hypothetical scenario that everyone 
agreed on /libhf for the linker path, but not for libraries -which would stay 
in /lib- , then we'd have a /libhf top directory with just one file, the 
linker. Or a symlink from /lib to /libhf or /lib/ to /libhf in 
Debian's case, but that defeats the purposes of having a new /libhf directory, 
doesn't it?

I hope I was clearer now.

-- 
Konstantinos Margaritis 

Re: RFA: RL78: Add -fstack-usage support

[DJ Delorie]

> OK for mainline/4.7 branch ?

Ok with me

Re: [RS6000] Stack tie fix.

[Olivier Hainque]

On Apr 5, 2012, at 16:03 , Alan Modra wrote:

> Well it turns out that gcc-4.4 still gets this testcase from pr30282
> wrong.

 Hmph :-(

>> There are lots of places in the emit_epilogue code that assign
>> frame_reg_rtx with different possible values, (hard_fp, sp, r11)
> 
> r12 too

 Right ... 

>> It is not at all obvious to me that the all places where we emit ties
>> have an accurate perception of what frame_reg's were possibly used before.
>> Is it clearer to you ?
> 
> I spent quite some time looking at it. ;)

 Oh, sure, that's why I'm asking :)

> Have you spotted an error
> somewhere, apart from spe_save_area_ptr not being mentioned in the
> stack tie?

 No, not really ... (more below)

> Hmm, I see I accidentally left out an assert from the stack tie
> patch.  This one may make you feel a little better.  :)
> 
>  /* Update stack and set back pointer unless this is V.4,
> for which it was done previously.  */

>  /* If using some other frame reg previously, then we ought to
>ensure it is mentioned in the stack tie emitted below.  */
>  gcc_checking_assert (REGNO (frame_reg_rtx) == 1
>  || REGNO (frame_reg_rtx) == 12);

 My concern (apart from possible remaining aliasing issues) was exactly
 what the comment above expresses, but right away I don't see how the assert
 does the check expressed by the comment, and there are other places where
 we emit ties.

 I need to review the function with your changes applied in greater detail.
 
 IIUC (please correct me if I'm wrong), every time we need to emit a tie, we
 must ensure that it references all the base regs that were used before to
 restore regs from the frame (to prevent the sp adjustment past the tie from
 moving prior to any of these accesses)
 
 Since we have several possible uses of different registers ahead, controlled
 by intricate conditions, I would have thought we'd need to maintain a list
 of these registers, to which we add every time we use a new one to access, and
 which we'd use to feed the tie references.

 If we don't do that, I still find it difficult to see that the ties alway do
 reference the proper set of regs (all those used to access the frame earlier).

 It might just be that there's part of the logic I still haven't grasped, so ...

>> FWIW, I had made an experiment at trying to extract subfunctions,
>> which might help such reasoning.

> I think this is worthwhile doing, but more important to try to make
> the logic simpler.
[...]

Entirely agreed! The exercise was just aimed at helping me understand
some of the logic :-)

Thanks a lot for your feedback, much appreciated,

Olivier

[google/gcc-4_6] Added dejagnu base line for x86_64-cros-linux-gnu. (issue 5990044)

[shenhan]

Reviewers: asharif1, jingyu,

Message:
Hi Jing and Ahmad,

This adds a new test base line for x86_64-cros-linux-gnu. Please take a
look.

Thanks,
Han

Description:
The new test base line for x86_64-cros-linux-gnu.

Please review this at http://codereview.appspot.com/5990044/

Affected files:
  A contrib/testsuite-management/x86_64-cros-linux-gnu.xfail


Index: contrib/testsuite-management/x86_64-cros-linux-gnu.xfail
diff --git a/contrib/testsuite-management/x86_64-cros-linux-gnu.xfail  
b/contrib/testsuite-management/x86_64-cros-linux-gnu.xfail

new file mode 100644
index 000..e9d8c0c
--- /dev/null
+++ b/contrib/testsuite-management/x86_64-cros-linux-gnu.xfail
@@ -0,0 +1,19 @@
+XPASS: g++.dg/uninit-pred-3_b.C (test for excess errors)
+FAIL: gcc.c-torture/compile/limits-exprparen.c -O3 -g  (test for excess  
errors)
+FAIL: gcc.c-torture/compile/limits-exprparen.c -O0  (internal compiler  
error)
+FAIL: gcc.c-torture/compile/limits-exprparen.c -Os  (test for excess  
errors)
+FAIL: gcc.c-torture/compile/limits-exprparen.c -O3 -fomit-frame-pointer   
(internal compiler error)
+FAIL: gcc.c-torture/compile/limits-exprparen.c -O2 -flto  (internal  
compiler error)
+FAIL: gcc.c-torture/compile/limits-exprparen.c -O2 -flto  (test for excess  
errors)
+FAIL: gcc.c-torture/compile/limits-exprparen.c -O3 -g  (internal compiler  
error)
+FAIL: gcc.c-torture/compile/limits-exprparen.c -O1  (test for excess  
errors)
+FAIL: gcc.c-torture/compile/limits-exprparen.c -O2  (internal compiler  
error)
+FAIL: gcc.c-torture/compile/limits-exprparen.c -Os  (internal compiler  
error)
+FAIL: gcc.c-torture/compile/limits-exprparen.c -O0  (test for excess  
errors)
+FAIL: gcc.c-torture/compile/limits-exprparen.c -O2 -flto  
-flto-partition=none  (internal compiler error)
+FAIL: gcc.c-torture/compile/limits-exprparen.c -O3 -fomit-frame-pointer   
(test for excess errors)
+FAIL: gcc.c-torture/compile/limits-exprparen.c -O2 -flto  
-flto-partition=none  (test for excess errors)
+FAIL: gcc.c-torture/compile/limits-exprparen.c -O2  (test for excess  
errors)
+FAIL: gcc.c-torture/compile/limits-exprparen.c -O1  (internal compiler  
error)
+FAIL: gcc.dg/tree-prof/ic-misattribution-1.c compilation,  -fprofile-use  
-D_PROFILE_USE
+UNRESOLVED: gcc.dg/tree-prof/ic-misattribution-1.c execution, 
-fprofile-use -D_PROFILE_USE

Re: [PATCH] Fix PR52614

[Mike Stump]

On Apr 5, 2012, at 2:30 AM, Richard Guenther wrote:
> Why can the link editor not promote the definitions alignment
> when merging with a common with bigger alignment?

The problem is that when a common symbol is upped in alignment, but then not 
chosen by ld (or worse, by the dynamic linker), but the codegen that assumes a 
larger alignment is used, then you realize the alignment of the data actually 
selected must be retroactively upped as well.  This means, the alignment in 
existing .a files, .o files, and .so files.  The .a and .o files can be easily 
solved by simply requiring the compile of the world after upgrading all linkers 
(static and dynamic) to only have -fdata-sections.  For .so files, well, that's 
above my pay grade.  Darwin, I'll note, can manage the upping on the size and 
alignment, but only between all the commons, not a hard definition behind it.

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Mike Frysinger]

On Thursday 05 April 2012 12:15:41 Steve McIntyre wrote:
> On Thu, Apr 05, 2012 at 11:08:56AM -0400, Mike Frysinger wrote:
> >On Thursday 05 April 2012 09:30:23 Konstantinos Margaritis wrote:
> >> Loic suggested a -IMHO- better solution: to change the dynamic linker
> >> filename, not the dir, i.e. /lib/ld-linux-hf.so.3 (for this particular
> >> case).
> >
> >the implication in supporting both hardfloat and softfloat simultaneously
> >is that you'd could have them both installed.  thus putting them both in
> >/lib/ doesn't make much sense if you're still going to need /libhf/ to
> >hold everything else.
> 
> Except you wouldn't - the Debian/Ubuntu plan with multi-arch is to put
> them all in cleanly-separated paths corresponding to the triplets.

/lib/ and /libhf/ is just as "clean" as /lib/ and /lib64/ (and now /libx32/).  
i see no difference here with a gcc configured for these multilib paths.

> I'm concerned that the potential proliferation of /lib* directories
> here could become very messy over time. I'm surprised that people seem
> to be happy to invent another namespace on a much more ad-hoc and
> arbitrary basis than the (mostly) well-understood triplets that we
> already have defined in the toolchains.

the triplet situation isn't as clean as you imply here.  there are already 
examples of not being able to tell the ABI based purely on that.  mips64-
linux-gnu could be n32 or n64.  x86_64-linux-gnu could be x86_64 or x32.

the Debian multiarch project might have made up new triplets to account for 
this, but those don't translate exactly into the same triplet that are used 
for e.g. configure --host.

> Multi-arch is an attempt to make things cleaner for those of us that
> care about having lots of different platforms supported in
> parallel. Seen against that background, I was hoping that using the
> multi-arch path for the armhf linker would make sense.

if you think that's a useful goal, then sure.  but not everyone thinks the 
multiarch proposal is really all that useful.  however, that (much larger) 
discussion is really out of scope here.

> For people that don't care about multi-arch for themselves, a simple
> symbolic link is all that's needed.

i think it's safe to say that the wider community has yet to be convinced, so 
extending existing support via the existing standards makes more sense.
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [branches/google/gcc-4_6] Backported r179661 and 179662 from mainline. (issue 5989043)

[asharif]

Committed as r186168.

http://codereview.appspot.com/5989043/

[branches/google/gcc-4_6_2-mobile] Backported r186168 from branches/google/gcc-4_6. (issue 5991052)

[asharif]

Reviewers: jingyu, bjanakiraman_google.com, dougkwan,

Message:
PTAL.

Description:
2012-04-04   Ahmad Sharif  

Backport from mainline r179661, r179662.

2011-10-07  Andrew Stubbs  

gcc/
* config/arm/predicates.md (shift_amount_operand): Remove constant
range check.
(shift_operator): Check range of constants for all shift operators.

gcc/testsuite/
* gcc.dg/pr50193-1.c: New file.
* gcc.target/arm/shiftable.c: New file.


Please review this at http://codereview.appspot.com/5991052/

Affected files:
   M.
  M gcc/ChangeLog
  M gcc/ChangeLog.google-4_6
  M gcc/config/arm/predicates.md
  M gcc/testsuite/ChangeLog
  A  +  gcc/testsuite/gcc.dg/pr50193-1.c
  A  +  gcc/testsuite/gcc.target/arm/shiftable.c

[SH] Simplify cstore patterns

[Oleg Endo]

Hi,

The attached patch simplifies the cstore patterns by removing GET_CODE
checks that are already done in sh_expand_t_scc.

Tested against rev 185893 with...
make -k check RUNTESTFLAGS="--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a-single/-mb,
-m4-single/-ml,-m4-single/-mb,
-m4a-single/-ml,-m4a-single/-mb}"

...and no new failures.

OK?

Cheers,
Oleg


ChangeLog:

* config/sh/sh.c (sh_expand_t_scc): Change return type from int
to bool.
* config/sh/sh.md (cstoresi4, cstoredi4): Remove GET_CODE checks
before calling sh_expand_t_scc.
Index: gcc/config/sh/sh-protos.h
===
--- gcc/config/sh/sh-protos.h	(revision 185893)
+++ gcc/config/sh/sh-protos.h	(working copy)
@@ -117,7 +117,7 @@
 extern int sh_can_redirect_branch (rtx, rtx);
 extern void sh_expand_unop_v2sf (enum rtx_code, rtx, rtx);
 extern void sh_expand_binop_v2sf (enum rtx_code, rtx, rtx, rtx);
-extern int sh_expand_t_scc (rtx *);
+extern bool sh_expand_t_scc (rtx *);
 extern rtx sh_gen_truncate (enum machine_mode, rtx, int);
 extern bool sh_vector_mode_supported_p (enum machine_mode);
 #endif /* RTX_CODE */
Index: gcc/config/sh/sh.c
===
--- gcc/config/sh/sh.c	(revision 185894)
+++ gcc/config/sh/sh.c	(working copy)
@@ -11942,7 +11942,7 @@
   return val;
 }
 
-int
+bool
 sh_expand_t_scc (rtx operands[])
 {
   enum rtx_code code = GET_CODE (operands[1]);
@@ -11954,21 +11954,21 @@
 
   if (!REG_P (op0) || REGNO (op0) != T_REG
   || !CONST_INT_P (op1))
-return 0;
+return false;
   if (!REG_P (result))
 result = gen_reg_rtx (SImode);
   val = INTVAL (op1);
   if ((code == EQ && val == 1) || (code == NE && val == 0))
 emit_insn (gen_movt (result));
   else if ((code == EQ && val == 0) || (code == NE && val == 1))
-   emit_insn (gen_movnegt (result));
+emit_insn (gen_movnegt (result));
   else if (code == EQ || code == NE)
 emit_insn (gen_move_insn (result, GEN_INT (code == NE)));
   else
-return 0;
+return false;
   if (result != target)
 emit_move_insn (target, result);
-  return 1;
+  return true;
 }
 
 /* INSN is an sfunc; return the rtx that describes the address used.  */
Index: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md	(revision 185893)
+++ gcc/config/sh/sh.md	(working copy)
@@ -9575,8 +9575,7 @@
   DONE;
 }
 
-   if ((GET_CODE (operands[1]) == EQ || GET_CODE (operands[1]) == NE)
-   && sh_expand_t_scc (operands))
+   if (sh_expand_t_scc (operands))
  DONE;
 
if (! currently_expanding_to_rtl)
@@ -9600,8 +9599,7 @@
   DONE;
 }
 
-   if ((GET_CODE (operands[1]) == EQ || GET_CODE (operands[1]) == NE)
-   && sh_expand_t_scc (operands))
+   if (sh_expand_t_scc (operands))
  DONE;
 
if (! currently_expanding_to_rtl)

[SH] Fold big/little endian word code with MSW and LSW

[Oleg Endo]

Hi,

The attached patch folds some of the code that needs to access high/low
subwords depending on the target endianess by utilizing the existing MSW
and LSW macros.

Tested against rev 185893 with...
make -k check RUNTESTFLAGS="--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a-single/-mb,
-m4-single/-ml,-m4-single/-mb,
-m4a-single/-ml,-m4a-single/-mb}"

...and no new failures.

OK?

Cheers,
Oleg


ChangeLog:

* config/sh/sh.c (MSW, LSW): Move macros to...
* config/sh/sh.h: ...here.
* config/sh/sh.md: Use MSW and LSW macros where applicable.
Index: gcc/config/sh/sh.c
===
--- gcc/config/sh/sh.c	(revision 185894)
+++ gcc/config/sh/sh.c	(working copy)
@@ -61,9 +61,6 @@
 
 int code_for_indirect_jump_scratch = CODE_FOR_indirect_jump_scratch;
 
-#define MSW (TARGET_LITTLE_ENDIAN ? 1 : 0)
-#define LSW (TARGET_LITTLE_ENDIAN ? 0 : 1)
-
 /* These are some macros to abstract register modes.  */
 #define CONST_OK_FOR_ADD(size) \
   (TARGET_SHMEDIA ? CONST_OK_FOR_I10 (size) : CONST_OK_FOR_I08 (size))
Index: gcc/config/sh/sh.h
===
--- gcc/config/sh/sh.h	(revision 185893)
+++ gcc/config/sh/sh.h	(working copy)
@@ -483,6 +483,10 @@
numbered.  */
 #define WORDS_BIG_ENDIAN (TARGET_LITTLE_ENDIAN == 0)
 
+/* Most/least significant (sub)word indices.  */
+#define MSW (TARGET_LITTLE_ENDIAN ? 1 : 0)
+#define LSW (TARGET_LITTLE_ENDIAN ? 0 : 1)
+
 #define MAX_BITS_PER_WORD 64
 
 /* Width in bits of an `int'.  We want just 32-bits, even if words are
Index: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md	(revision 185893)
+++ gcc/config/sh/sh.md	(working copy)
@@ -940,15 +940,11 @@
(set (reg:SI T_REG) (eq:SI (match_dup 4) (match_dup 5)))
(match_dup 6)]
 {
-  operands[2]
-= gen_rtx_REG (SImode,
-		   true_regnum (operands[0]) + (TARGET_LITTLE_ENDIAN ? 1 : 0));
-  operands[3]
-= (operands[1] == const0_rtx
-   ? const0_rtx
-   : gen_rtx_REG (SImode,
-		  true_regnum (operands[1])
-		  + (TARGET_LITTLE_ENDIAN ? 1 : 0)));
+  operands[2] = gen_rtx_REG (SImode, true_regnum (operands[0]) + MSW);
+  operands[3] = (operands[1] == const0_rtx
+		 ? const0_rtx
+		 : gen_rtx_REG (SImode, true_regnum (operands[1]) + MSW));
+
   operands[4] = gen_lowpart (SImode, operands[0]);
   operands[5] = gen_lowpart (SImode, operands[1]);
   operands[6] = gen_label_rtx ();
@@ -1452,12 +1448,8 @@
   [(const_int 0)]
 {
   rtx high0, high2, low0 = gen_lowpart (SImode, operands[0]);
-  high0 = gen_rtx_REG (SImode,
-		   true_regnum (operands[0])
-		   + (TARGET_LITTLE_ENDIAN ? 1 : 0));
-  high2 = gen_rtx_REG (SImode,
-		   true_regnum (operands[2])
-		   + (TARGET_LITTLE_ENDIAN ? 1 : 0));
+  high0 = gen_rtx_REG (SImode, true_regnum (operands[0]) + MSW);
+  high2 = gen_rtx_REG (SImode, true_regnum (operands[2]) + MSW);
   emit_insn (gen_clrt ());
   emit_insn (gen_addc (low0, low0, gen_lowpart (SImode, operands[2])));
   emit_insn (gen_addc1 (high0, high0, high2));
@@ -1580,12 +1572,8 @@
   [(const_int 0)]
 {
   rtx high0, high2, low0 = gen_lowpart (SImode, operands[0]);
-  high0 = gen_rtx_REG (SImode,
-		   true_regnum (operands[0])
-		   + (TARGET_LITTLE_ENDIAN ? 1 : 0));
-  high2 = gen_rtx_REG (SImode,
-		   true_regnum (operands[2])
-		   + (TARGET_LITTLE_ENDIAN ? 1 : 0));
+  high0 = gen_rtx_REG (SImode, true_regnum (operands[0]) + MSW);
+  high2 = gen_rtx_REG (SImode, true_regnum (operands[2]) + MSW);
   emit_insn (gen_clrt ());
   emit_insn (gen_subc (low0, low0, gen_lowpart (SImode, operands[2])));
   emit_insn (gen_subc1 (high0, high0, high2));
@@ -3919,13 +3907,11 @@
(match_operand:DI 2 "const_int_operand" "n")))]
   "TARGET_SH1 && INTVAL (operands[2]) < 32"
 {
-  int low_word = (TARGET_LITTLE_ENDIAN ? 0 : 1);
-  int high_word = (TARGET_LITTLE_ENDIAN ? 1 : 0);
-  rtx low_src = operand_subword (operands[1], low_word, 0, DImode);
-  rtx high_src = operand_subword (operands[1], high_word, 0, DImode);
+  rtx low_src = operand_subword (operands[1], LSW, 0, DImode);
+  rtx high_src = operand_subword (operands[1], MSW, 0, DImode);
   rtx dst = gen_reg_rtx (DImode);
-  rtx low_dst = operand_subword (dst, low_word, 1, DImode);
-  rtx high_dst = operand_subword (dst, high_word, 1, DImode);
+  rtx low_dst = operand_subword (dst, LSW, 1, DImode);
+  rtx high_dst = operand_subword (dst, MSW, 1, DImode);
   rtx tmp0, tmp1;
 
   tmp0 = gen_reg_rtx (SImode);
@@ -4373,15 +4359,12 @@
   "TARGET_SH1"
   [(const_int 0)]
 {
-  int low_word = (TARGET_LITTLE_ENDIAN ? 0 : 1);
-  int high_word = (TARGET_LITTLE_ENDIAN ? 1 : 0);
+  rtx low_src = operand_subword (operands[1], LSW, 0, DImode);
+  rtx high_src = operand_subword (operands[1], MSW, 0, DImode);
 
-  rtx low_src = operand_subword (operands[1], low_word, 0, DImode);
-  rtx high_src = operand_subword (operands[1], high_word, 0, DIm

[SH] Replace hi_const with satisfies_constraint_I16

[Oleg Endo]

Hi,

The attached patch removes the hi_const function and replaces its use
with satisfies_constraint_I16.

Tested against rev 185893 with...
make -k check RUNTESTFLAGS="--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a-single/-mb,
-m4-single/-ml,-m4-single/-mb,
-m4a-single/-ml,-m4a-single/-mb}"

...and no new failures.

OK?

Cheers,
Oleg

ChangeLog:

* config/sh/sh.c (hi_const): Remove.
(find_barrier, sh_reorg): Use satisfies_constraint_I16 instead
of hi_const.

Index: gcc/config/sh/sh.c
===
--- gcc/config/sh/sh.c	(revision 185894)
+++ gcc/config/sh/sh.c	(working copy)
@@ -174,7 +174,6 @@
 static void print_slot (rtx);
 static rtx add_constant (rtx, enum machine_mode, rtx);
 static void dump_table (rtx, rtx);
-static int hi_const (rtx);
 static int broken_move (rtx);
 static int mova_p (rtx);
 static rtx find_barrier (int, rtx, rtx);
@@ -4293,17 +4292,6 @@
   pool_window_last = 0;
 }
 
-/* Return nonzero if constant would be an ok source for a
-   mov.w instead of a mov.l.  */
-
-static int
-hi_const (rtx src)
-{
-  return (CONST_INT_P (src)
-	  && INTVAL (src) >= -32768
-	  && INTVAL (src) <= 32767);
-}
-
 #define MOVA_LABELREF(mova) XVECEXP (SET_SRC (PATTERN (mova)), 0, 0)
 
 /* Nonzero if the insn is a move instruction which needs to be fixed.  */
@@ -4583,7 +4571,8 @@
 	 front end will generate code to load unsigned constants into
 	 HImode targets without properly sign extending them.  */
 	  if (mode == HImode
-	  || (mode == SImode && hi_const (src) && REGNO (dst) != FPUL_REG))
+	  || (mode == SImode && satisfies_constraint_I16 (src)
+		  && REGNO (dst) != FPUL_REG))
 	{
 	  found_hi += 2;
 	  /* We put the short constants before the long constants, so
@@ -5726,7 +5715,7 @@
 		  dst = SET_DEST (pat);
 		  mode = GET_MODE (dst);
 
-		  if (mode == SImode && hi_const (src)
+		  if (mode == SImode && satisfies_constraint_I16 (src)
 		  && REGNO (dst) != FPUL_REG)
 		{
 		  int offset = 0;

RFC: PR rtl-optimization/52876: Sign extend 32 to 64bit then clear upper 32bits fails O1 or higher

[H.J. Lu]

Hi,

CSE turns (reg:DI 64)

(insn 6 3 7 2 (set (reg:DI 64)
(sign_extend:DI (subreg/u:SI (reg/v/f:DI 63 [ addr ]) 0))) x.i:6 122
{*extendsidi2_rex64} (nil))

into (reg/f:DI 64 [ addr ]).  But nonzero_bits1 in rtlanal.c has

#if defined(POINTERS_EXTEND_UNSIGNED) && !defined(HAVE_ptr_extend)
  /* If pointers extend unsigned and this is a pointer in Pmode, say that
 all the bits above ptr_mode are known to be zero.  */
  /* As we do not know which address space the pointer is refering to,
 we can do this only if the target does not support different pointer
 or address modes depending on the address space.  */
  if (target_default_pointer_address_modes_p ()
  && POINTERS_EXTEND_UNSIGNED && GET_MODE (x) == Pmode
  && REG_POINTER (x))
nonzero &= GET_MODE_MASK (ptr_mode);
#endif

Setting REG_POINTER with incompatible pointer sign extension is wrong.
This patch adds a bool parameter to set_reg_attrs_from_value to
indicate if a register can be marked as a pointer.  Does it look OK?

Thanks.


H.J.
---
gcc/

2012-04-05  H.J. Lu  

PR rtl-optimization/52876
* emit-rtl.c (set_reg_attrs_from_value): Add a bool parameter
to indicate if a register can be a pointer.
(gen_reg_rtx_and_attrs): Pass true to set_reg_attrs_from_value.
(set_reg_attrs_for_parm): Likewise.

* emit-rtl.h (set_reg_attrs_from_value): Add a bool parameter.

* reginfo.c (reg_scan_mark_refs): Pass false to
set_reg_attrs_from_value with incompatible pointer sign
extension.

gcc/testsuite

2012-04-05  H.J. Lu  

PR rtl-optimization/52876
* gcc.target/i386/pr52876.c: New.

diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c
index 8d7d441..791ff5c 100644
--- a/gcc/emit-rtl.c
+++ b/gcc/emit-rtl.c
@@ -967,7 +967,7 @@ adjust_reg_mode (rtx reg, enum machine_mode mode)
have different modes, REG is a (possibly paradoxical) lowpart of X.  */
 
 void
-set_reg_attrs_from_value (rtx reg, rtx x)
+set_reg_attrs_from_value (rtx reg, rtx x, bool can_be_reg_pointer)
 {
   int offset;
 
@@ -983,14 +983,14 @@ set_reg_attrs_from_value (rtx reg, rtx x)
   if (MEM_OFFSET_KNOWN_P (x))
REG_ATTRS (reg) = get_reg_attrs (MEM_EXPR (x),
 MEM_OFFSET (x) + offset);
-  if (MEM_POINTER (x))
+  if (can_be_reg_pointer && MEM_POINTER (x))
mark_reg_pointer (reg, 0);
 }
   else if (REG_P (x))
 {
   if (REG_ATTRS (x))
update_reg_offset (reg, x, offset);
-  if (REG_POINTER (x))
+  if (can_be_reg_pointer && REG_POINTER (x))
mark_reg_pointer (reg, REGNO_POINTER_ALIGN (REGNO (x)));
 }
 }
@@ -1002,7 +1002,7 @@ rtx
 gen_reg_rtx_and_attrs (rtx x)
 {
   rtx reg = gen_reg_rtx (GET_MODE (x));
-  set_reg_attrs_from_value (reg, x);
+  set_reg_attrs_from_value (reg, x, true);
   return reg;
 }
 
@@ -1013,7 +1013,7 @@ void
 set_reg_attrs_for_parm (rtx parm_rtx, rtx mem)
 {
   if (REG_P (parm_rtx))
-set_reg_attrs_from_value (parm_rtx, mem);
+set_reg_attrs_from_value (parm_rtx, mem, true);
   else if (GET_CODE (parm_rtx) == PARALLEL)
 {
   /* Check for a NULL entry in the first slot, used to indicate that the
diff --git a/gcc/emit-rtl.h b/gcc/emit-rtl.h
index bc91193..2f259ef 100644
--- a/gcc/emit-rtl.h
+++ b/gcc/emit-rtl.h
@@ -63,7 +63,7 @@ extern rtx copy_insn_1 (rtx);
 extern rtx copy_insn (rtx);
 extern rtx gen_int_mode (HOST_WIDE_INT, enum machine_mode);
 extern rtx emit_copy_of_insn_after (rtx, rtx);
-extern void set_reg_attrs_from_value (rtx, rtx);
+extern void set_reg_attrs_from_value (rtx, rtx, bool);
 extern void set_reg_attrs_for_parm (rtx, rtx);
 extern void set_reg_attrs_for_decl_rtl (tree t, rtx x);
 extern void adjust_reg_mode (rtx, enum machine_mode);
diff --git a/gcc/reginfo.c b/gcc/reginfo.c
index 6353126..585d7a8 100644
--- a/gcc/reginfo.c
+++ b/gcc/reginfo.c
@@ -1224,14 +1224,24 @@ reg_scan_mark_refs (rtx x, rtx insn)
   if (REG_P (dest) && !REG_ATTRS (dest))
{
  rtx src = SET_SRC (x);
+ bool can_be_reg_pointer = true;
 
  while (GET_CODE (src) == SIGN_EXTEND
 || GET_CODE (src) == ZERO_EXTEND
 || GET_CODE (src) == TRUNCATE
 || (GET_CODE (src) == SUBREG && subreg_lowpart_p (src)))
-   src = XEXP (src, 0);
+   {
+#if defined(POINTERS_EXTEND_UNSIGNED) && !defined(HAVE_ptr_extend)
+ if ((GET_CODE (src) == SIGN_EXTEND
+  && POINTERS_EXTEND_UNSIGNED)
+ || (GET_CODE (src) != SIGN_EXTEND
+ && ! POINTERS_EXTEND_UNSIGNED))
+   can_be_reg_pointer = false;
+#endif
+ src = XEXP (src, 0);
+   }
 
- set_reg_attrs_from_value (dest, src);
+ set_reg_attrs_from_value (dest, src, can_be_reg_pointer);
}
 
   /* ... fall through ...  */
diff --git a/gcc/testsuite/gcc.target/i386/pr52876.c 
b/gcc/testsuite/gcc.target/i38

Added better handling of outdated profile data. (issue 5989046)

[asharif]

Reviewers: jh_suse.cz, davidxl, bjanakiraman_google.com,

Message:
Jan, please take a look and provide some feedback.

Thanks,

Description:
Added better handling of outdated profiles.

gcc dumps profile information in .gcda files that contain the function
id and
the corresponding counter information. The function cfg and line number
checksums are also stored along with the ids. When the program source
changes
between when the instrumentation run is done vs. when the -fprofile-use
is
passed, gcc will have functions that do not have a valid profile. These
functions could be hot and may not be inlined because the summary of the
profile
is still valid (sum_max, etc.). This can lead to a situation where the
performance with -fprofile-use is lower than with -fno-profile-use.

It is easy to have a situation where the profile is outdated. A single
line
change in the header file can potentially renumber all functions and
none of the
ids will match the profile generated from the old source.

This patch makes the performance degradation in the outdated case much
less
severe. It adds checks that the profile has been read for a certain
function
before using the counter values (which are 0 in the case where the
profile is
invalid).

Without this patch we see up to 15% performance degradation by using
outdated
profiles vs. not using any profile information for Chrome. This patch
decreases
that degradation down to (0% to 4%).


Please review this at http://codereview.appspot.com/5989046/

Affected files:
  M gcc/ipa-inline.c
  M gcc/predict.c
  M gcc/profile.c
  M gcc/tree.h


From 88d8094b6408b38d05241ecf574a51edabeabb3a Mon Sep 17 00:00:00 2001
From: Ahmad Sharif 
Date: Wed, 4 Apr 2012 19:09:23 -0700
Subject: [PATCH] Added better handling of outdated profiles.

gcc dumps profile information in .gcda files that contain the function id  
and

the corresponding counter information. The function cfg and line number
checksums are also stored along with the ids. When the program source  
changes

between when the instrumentation run is done vs. when the -fprofile-use is
passed, gcc will have functions that do not have a valid profile. These
functions could be hot and may not be inlined because the summary of the  
profile

is still valid (sum_max, etc.). This can lead to a situation where the
performance with -fprofile-use is lower than with -fno-profile-use.

It is easy to have a situation where the profile is outdated. A single line
change in the header file can potentially renumber all functions and none  
of the

ids will match the profile generated from the old source.

This patch makes the performance degradation in the outdated case much less
severe. It adds checks that the profile has been read for a certain function
before using the counter values (which are 0 in the case where the profile  
is

invalid).

Without this patch we see up to 15% performance degradation by using  
outdated
profiles vs. not using any profile information for Chrome. This patch  
decreases

that degradation down to (0% to 4%).
---
 gcc/ipa-inline.c |4 +++-
 gcc/predict.c|   13 +
 gcc/profile.c|2 +-
 gcc/tree.h   |5 +
 4 files changed, 18 insertions(+), 6 deletions(-)

Index: gcc/ipa-inline.c
diff --git a/gcc/ipa-inline.c b/gcc/ipa-inline.c
index d7ccf68..fbc6c4a 100644
--- a/gcc/ipa-inline.c
+++ b/gcc/ipa-inline.c
@@ -780,7 +780,9 @@ edge_badness (struct cgraph_edge *edge, bool dump)
 The fraction is upside down, becuase on edge counts and time beneits
 the bounds are known. Edge growth is essentially unlimited.  */

-  else if (max_count)
+  else if (max_count
+   && DECL_READ_PROFILE_P(edge->caller->decl)
+   && DECL_READ_PROFILE_P(edge->callee->decl))
 {
   int relbenefit = relative_time_benefit (callee_info, edge,  
time_growth);

   badness =
Index: gcc/predict.c
diff --git a/gcc/predict.c b/gcc/predict.c
index c12b45f..94af954 100644
--- a/gcc/predict.c
+++ b/gcc/predict.c
@@ -114,7 +114,8 @@ static inline bool
 maybe_hot_frequency_p (int freq)
 {
   struct cgraph_node *node = cgraph_get_node (current_function_decl);
-  if (!profile_info || !flag_branch_probabilities)
+  if (!profile_info || !flag_branch_probabilities
+  || !DECL_READ_PROFILE_P(current_function_decl))
 {
   if (node->frequency == NODE_FREQUENCY_UNLIKELY_EXECUTED)
 return false;
@@ -162,6 +163,7 @@ bool
 cgraph_maybe_hot_edge_p (struct cgraph_edge *edge)
 {
   if (profile_info && flag_branch_probabilities
+  && DECL_READ_PROFILE_P(edge->caller->decl)
   && (edge->count
  <= profile_info->sum_max / PARAM_VALUE (HOT_BB_COUNT_FRACTION)))
 return false;
@@ -202,9 +204,11 @@ maybe_hot_edge_p (edge e)
 bool
 probably_never_executed_bb_p (const_basic_block bb)
 {
-  if (profile_info && flag_branch_probabilities)
+  if (profile_info && flag_branch_probabilities
+  && DECL_READ_PROFILE_P(current_function_decl))
 return ((bb->count + profile_info->runs / 2

Re: [libjava] Restore HAVE_INET6 tests (PR libgcj/52645)

[Tom Tromey]

> "Rainer" == Rainer Orth  writes:

Rainer> 2012-03-21  Rainer Orth  
Rainer> PR libgcj/52645
Rainer> * gnu/java/net/natPlainDatagramSocketImplPosix.cc (setOption):
Rainer> Restore HAVE_INET6 check.
Rainer> * gnu/java/net/natPlainDatagramSocketImplWin32.cc (setOption):
Rainer> Likewise.

This is ok.

Tom

Re: RFA: consolidate DWARF strings into libiberty

[Tom Tromey]

> "Tom" == Tom Tromey  writes:

Tom> Here is a new patch for gcc.
Tom> I still haven't updated the src side, but there's little to do there
Tom> that isn't already done in this patch.

Tom> Ok?

Ping.

Tom

[SH] Use bool return types where possible

[Oleg Endo]

Hi,

The attached patch changes the return types from int to bool for
functions where it seems appropriate and removes the forward declaration
of the no longer exiting function sh_pass_in_reg_p.

Tested by doing 'make all'.
Will run the testsuite on it just in case.

OK?

Cheers,
Oleg

ChangeLog:

* config/sh/sh-protos.h (fp_zero_operand, fp_one_operand,
nonpic_symbol_mentioned_p, expand_block_move, expand_ashiftrt,
sh_dynamicalize_shift_p, gen_shl_and, gen_shl_sext,
system_reg_operand, reg_unused_after, sh_can_redirect_branch,
sh_need_epilogue, fldi_ok, sh_hard_regno_rename_ok,
sh_cfun_interrupt_handler_p, sh_cfun_resbank_handler_p,
sh_attr_renesas_p, sh_cfun_attr_renesas_p, check_use_sfunc_addr,
sh_contains_memref_p, sh_loads_bankedreg_p,
sh2a_is_function_vector_call): Use bool as return type.
(sh_pass_in_reg_p): Remove.
* config/sh/sh.c (broken_move, mova_p, noncall_uses_reg,
high_pressure, flow_dependent_p, sh2a_function_vector_p,
expand_block_move, expand_ashiftrt, sh_dynamicalize_shift_p,
gen_shl_and, gen_shl_sext, sh_need_epilogue,
sh2a_is_function_vector_call, sh_attr_renesas_p,
sh_cfun_attr_renesas_p, sh_cfun_interrupt_handler_p,
sh_cfun_resbank_handler_p, system_reg_operand, fp_zero_operand,
fp_one_operand, fldi_ok, reg_unused_after,
sh_can_redirect_branch, sh_hard_regno_rename_ok,
check_use_sfunc_addr, sh_contains_memref_p, 
sh_loads_bankedreg_p): Use bool as return type.
(nonpic_symbol_mentioned_p): Use bool as return type.  Remove
'register' modifier.
Index: gcc/config/sh/sh-protos.h
===
--- gcc/config/sh/sh-protos.h	(revision 186168)
+++ gcc/config/sh/sh-protos.h	(working copy)
@@ -53,18 +53,18 @@
 extern rtx sfunc_uses_reg (rtx);
 extern int barrier_align (rtx);
 extern int sh_loop_align (rtx);
-extern int fp_zero_operand (rtx);
-extern int fp_one_operand (rtx);
+extern bool fp_zero_operand (rtx);
+extern bool fp_one_operand (rtx);
 extern int fp_int_operand (rtx);
 extern rtx get_fpscr_rtx (void);
 extern bool sh_legitimate_index_p (enum machine_mode, rtx);
 extern bool sh_legitimize_reload_address (rtx *, enum machine_mode, int, int);
 extern rtx legitimize_pic_address (rtx, enum machine_mode, rtx);
-extern int nonpic_symbol_mentioned_p (rtx);
+extern bool nonpic_symbol_mentioned_p (rtx);
 extern void emit_sf_insn (rtx);
 extern void emit_df_insn (rtx);
 extern void output_pic_addr_const (FILE *, rtx);
-extern int expand_block_move (rtx *);
+extern bool expand_block_move (rtx *);
 extern int prepare_move_operands (rtx[], enum machine_mode mode);
 extern enum rtx_code prepare_cbranch_operands (rtx *, enum machine_mode mode,
 	   enum rtx_code comparison);
@@ -79,15 +79,15 @@
 extern void gen_ashift_hi (int, int, rtx);
 extern void gen_shifty_op (int, rtx *);
 extern void gen_shifty_hi_op (int, rtx *);
-extern int expand_ashiftrt (rtx *);
-extern int sh_dynamicalize_shift_p (rtx);
+extern bool expand_ashiftrt (rtx *);
+extern bool sh_dynamicalize_shift_p (rtx);
 extern int shl_and_kind (rtx, rtx, int *);
 extern int shl_and_length (rtx);
 extern int shl_and_scr_length (rtx);
-extern int gen_shl_and (rtx, rtx, rtx, rtx);
+extern bool gen_shl_and (rtx, rtx, rtx, rtx);
 extern int shl_sext_kind (rtx, rtx, int *);
 extern int shl_sext_length (rtx);
-extern int gen_shl_sext (rtx, rtx, rtx, rtx);
+extern bool gen_shl_sext (rtx, rtx, rtx, rtx);
 extern rtx gen_datalabel_ref (rtx);
 extern int regs_used (rtx, int);
 extern void fixup_addr_diff_vecs (rtx);
@@ -95,7 +95,7 @@
 extern void final_prescan_insn (rtx, rtx *, int);
 extern int symbol_ref_operand (rtx, enum machine_mode);
 extern enum tls_model tls_symbolic_operand (rtx, enum machine_mode);
-extern int system_reg_operand (rtx, enum machine_mode);
+extern bool system_reg_operand (rtx, enum machine_mode);
 extern int general_movsrc_operand (rtx, enum machine_mode);
 extern int general_movdst_operand (rtx, enum machine_mode);
 extern int arith_reg_operand (rtx, enum machine_mode);
@@ -107,14 +107,14 @@
 extern int fpul_operand (rtx, enum machine_mode);
 extern int commutative_float_operator (rtx, enum machine_mode);
 extern int noncommutative_float_operator (rtx, enum machine_mode);
-extern int reg_unused_after (rtx, rtx);
+extern bool reg_unused_after (rtx, rtx);
 extern void expand_sf_unop (rtx (*)(rtx, rtx, rtx), rtx *);
 extern void expand_sf_binop (rtx (*)(rtx, rtx, rtx, rtx), rtx *);
 extern void expand_df_unop (rtx (*)(rtx, rtx, rtx), rtx *);
 extern void expand_df_binop (rtx (*)(rtx, rtx, rtx, rtx), rtx *);
 extern void expand_fp_branch (rtx (*)(void), rtx (*)(void));
 extern int sh_insn_length_adjustment (rtx);
-extern int sh_can_redirect_branch (rtx, rtx);
+extern bool sh_can_redirect_branch (rtx, rtx);
 extern void sh_expand_unop_v2sf (enum rtx_code, rtx, rtx);
 extern void sh_expand

[PATCH, i386]: FIX PR 52882, ICE in memory_address_length, at config/i386/i386.c:23373

[Uros Bizjak]

Hello!

We can allow AND zero-extended CONST_INT operands in
ix86_decompose_address. These are sometimes generated by IRA for
certain corner cases, as in attached testcase.

2012-04-05  Uros Bizjak  

PR target/52882
* config/i386/i386.c (ix86_decompose_address): Allow VOIDmode
CONST_INT operands, zero-extended with AND.

testsuite/ChangeLog:

2012-04-05  Uros Bizjak  

PR target/52882
* gcc.target/i386/pr52882.c: New test.

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

Uros.
Index: config/i386/i386.c
===
--- config/i386/i386.c  (revision 186169)
+++ config/i386/i386.c  (working copy)
@@ -11510,7 +11510,7 @@ ix86_decompose_address (rtx addr, struct ix86_addr
addr = SUBREG_REG (addr);
  else if (GET_MODE (addr) == DImode)
addr = gen_rtx_SUBREG (SImode, addr, 0);
- else
+ else if (GET_MODE (addr) != VOIDmode)
return 0;
}
 }
Index: testsuite/gcc.target/i386/pr52882.c
===
--- testsuite/gcc.target/i386/pr52882.c (revision 0)
+++ testsuite/gcc.target/i386/pr52882.c (revision 0)
@@ -0,0 +1,19 @@
+/* { dg-do compile } */
+/* { dg-options "-O" } */
+
+struct S1 {
+  int f0;
+  int f1;
+};
+
+int fn1 ();
+void fn2 (struct S1);
+
+void
+fn3 () {
+  struct S1 a = { 1, 0 };
+  if (fn1 ())
+fn2 (a);
+  for (; a.f1;) {
+  }
+}

Re: [branches/google/gcc-4_6_2-mobile] Backported r186168 from branches/google/gcc-4_6. (issue 5991052)

[asharif]

Added shenhan to the list of reviewers.

http://codereview.appspot.com/5991052/

Re: [PATCH] Fix PR52614

[Ian Lance Taylor]

Richard Guenther  writes:

> On Thu, Apr 5, 2012 at 6:22 AM, Mike Stump  wrote:
>> On Apr 4, 2012, at 7:56 PM, William J. Schmidt wrote:
>>> There seems to be tacit agreement that the vector tests should use
>>> -fno-common on all targets to avoid the recent spate of failures (see
>>> discussion in 52571 and 52603).
>>
>>> OK for trunk?
>>
>> Ok.  Any other solution I think will be real work and we shouldn't loose the 
>> testing between now and then by not having the test cases working.
>
> Ian, you are the "source" of all of these problems.  While I did not notice
> any degradations in SPEC (on x86) with handling commons "correctly"
> now, the fact
> that our testsuite needs -fno-common to make things vectorizable shows
> that users might be impacted negatively by this, which is only a real problem
> in corner cases.  Why can the link editor not promote the definitions 
> alignment
> when merging with a common with bigger alignment?

The defined symbol will be embedded in a data section along with other
defined data symbols, at some offset O from the start of the section.
The data section will have a required alignment A.  It is entirely
possible that there is no way to honor A and also ensure that A+O is
aligned as requested by the common symbol.

This whole issue only applies to vectorization involving global symbols
defined with no initializer in C, when vectorization requires an
alignment greater than that implied by the type of the symbol.  It does
not affect function arguments or local variables.  It does not affect
C++.  Is vectorization of uninitialized global symbols really a common
case?

Another approach we could use is to say that when the vectorizer wants
to increase the alignment of a common symbol, it would force the symbol
to be defined rather than common.  That would be safe, as it would lead
to a multiple-definition error at link time in cases where it would be
unsafe.  I would be fine with making the compiler work that way for C,
although of course there would have to be an option to disable it.

I don't know enough about Fortran to know whether the same issues arise
there.  Perhaps in Fortran a common symbol is always a common symbol and
can never be a defined symbol.  If that is the case then for Fortran I
think it would be safe to change the alignment of the common symbol.  Of
course we would need to have some way to indicate that in the
middle-end--DECL_ALWAYS_COMMON or something.

Ian

Re: [Libiberty - V2]: Handle VMS as a LLP64 platform in splay-tree.h

[Ian Lance Taylor]

Tristan Gingold  writes:

> gcc/
> 2012-04-05  Tristan Gingold  
>
>   * gengtype.c (main): Make uintptr_t a known type.
>
> include/
> 2012-04-05  Tristan Gingold  
>
>   * splay-tree.h: Conditionnaly includes stdint.h and inttypes.h
>   (libi_uhostptr_t, libi_shostptr_t): Remove, replaced by uintptr_t.

This is OK.

Thanks.

Ian

[PATCH][Cilkplus] Elemental function cloning with vector params.

[Iyer, Balaji V]

Hello Everyone,
This patch is for Cilkplus branch affecting mainly C and C++ compilers. It 
will clone a function that is marked as elemental function and pass the 
parameters and return values into the appropriate vector registers.

Thanking You,

Yours Sincerely,

Balaji V. Iyer. 
diff --git a/gcc/ChangeLog.cilk b/gcc/ChangeLog.cilk
index 8bfb689..6b7c176 100644
--- a/gcc/ChangeLog.cilk
+++ b/gcc/ChangeLog.cilk
@@ -1,3 +1,17 @@
+2012-04-05  Balaji V. Iyer  
+
+   * config/i386/i386.c (type_natural_mode): Added a flag_enable_cilk
+   check.
+   (ix86_function_arg_boundary): Likewise.
+   * expr.c (expand_expr_real_1): Likewise.
+   * elem-function.c (create_processor_attribute): Added avx to target
+   string.
+   (create_elem_fn_nodes): called copy_node to new_decl's type.  Replaced
+   tree_function_versioning call with tree_elem_fn_versioning.
+   * tree-inline.c (elem_fn_add_local_variables): New function.
+   (elem_fn_copy_arguments_for_versioning): Likewise.
+   (tree_elem_fn_versioning): Likewise.
+
 2012-03-20  Balaji V. Iyer  
 
* elem-function.c (extract_elem_fn_values): Initialized proc_type field
diff --git a/gcc/cgraph.h b/gcc/cgraph.h
index 7262859..66fd3c6 100644
--- a/gcc/cgraph.h
+++ b/gcc/cgraph.h
@@ -584,6 +584,8 @@ struct cgraph_node *cgraph_function_versioning (struct 
cgraph_node *,
basic_block, const char *);
 void tree_function_versioning (tree, tree, VEC (ipa_replace_map_p,gc)*,
   bool, bitmap, bool, bitmap, basic_block);
+void tree_elem_fn_versioning (tree, tree, VEC (ipa_replace_map_p,gc)*,
+ bool, bitmap, bool, bitmap, basic_block, int);
 void record_references_in_initializer (tree, bool);
 bool cgraph_process_new_functions (void);
 void cgraph_process_same_body_aliases (void);
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 92604ae..754d53d 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -5816,9 +5816,12 @@ type_natural_mode (const_tree type, const 
CUMULATIVE_ARGS *cum)
&& !warnedavx
&& cum->warn_avx)
  {
-   warnedavx = true;
-   warning (0, "AVX vector argument without AVX "
-"enabled changes the ABI");
+   if (!flag_enable_cilk)
+ {
+   warnedavx = true;
+   warning (0, "AVX vector argument without AVX "
+"enabled changes the ABI");
+ }
  }
return TYPE_MODE (type);
  }
@@ -7203,11 +7206,14 @@ ix86_function_arg_boundary (enum machine_mode mode, 
const_tree type)
  && align != ix86_compat_function_arg_boundary (mode, type,
 saved_align))
{
- warned = true;
- inform (input_location,
- "The ABI for passing parameters with %d-byte"
- " alignment has changed in GCC 4.6",
- align / BITS_PER_UNIT);
+ if (!flag_enable_cilk)
+   {
+ warned = true;
+ inform (input_location,
+ "The ABI for passing parameters with %d-byte"
+ " alignment has changed in GCC 4.6",
+ align / BITS_PER_UNIT);
+   }
}
 }
 
diff --git a/gcc/elem-function.c b/gcc/elem-function.c
index a6bc4e3..dd3b75b 100644
--- a/gcc/elem-function.c
+++ b/gcc/elem-function.c
@@ -265,6 +265,8 @@ create_processor_attribute (elem_fn_info *elem_fn_values, 
tree *opposite_attr)
 build_string (strlen ("arch=corei7"), "arch=corei7"));
   VEC_safe_push (tree, gc, proc_vec_list,
 build_string (strlen ("sse4.2"), "sse4.2"));
+  VEC_safe_push (tree, gc, proc_vec_list,
+build_string (strlen ("avx"), "avx"));
   if (opposite_attr)
{
  VEC_safe_push (tree, gc, opp_proc_vec_list,
@@ -307,7 +309,7 @@ create_optimize_attribute (int option)
   opt_attr = build_tree_list (get_identifier ("optimize"), opt_attr);
   return opt_attr;
 }
-  
+
 /* this function will find the appropriate mangling suffix for the vector
  * function */
 static char *
@@ -362,6 +364,7 @@ create_elem_fn_nodes (struct cgraph_node *node)
   
   old_decl = node->decl;
   new_decl = copy_node (old_decl);
+  TREE_TYPE (new_decl) = copy_node (TREE_TYPE (old_decl));
   elem_fn_values = extract_elem_fn_values (old_decl);
 
   if (elem_fn_values)
@@ -381,8 +384,8 @@ create_elem_fn_nodes (struct cgraph_node *node)
   new_node->local.externally_visible = node->local.externally_visible;
   new_node->lowered = true;
 
-  tree_function_versioning (old_decl, new_decl, NULL, false, NULL, false, NULL,
-  

Re: [SH] Simplify cstore patterns

[Kaz Kojima]

Oleg Endo  wrote:
> The attached patch simplifies the cstore patterns by removing GET_CODE
> checks that are already done in sh_expand_t_scc.
> 
> Tested against rev 185893 with...
> make -k check RUNTESTFLAGS="--target_board=sh-sim
> \{-m2/-ml,-m2/-mb,-m2a-single/-mb,
> -m4-single/-ml,-m4-single/-mb,
> -m4a-single/-ml,-m4a-single/-mb}"
> 
> ...and no new failures.
> 
> OK?

OK.

Regards,
kaz

Re: [SH] Fold big/little endian word code with MSW and LSW

[Kaz Kojima]

Oleg Endo  wrote:
> The attached patch folds some of the code that needs to access high/low
> subwords depending on the target endianess by utilizing the existing MSW
> and LSW macros.
[snip]
>   * config/sh/sh.c (MSW, LSW): Move macros to...
>   * config/sh/sh.h: ...here.
>   * config/sh/sh.md: Use MSW and LSW macros where applicable.

Exposing three-letter macro MSW and LSW globally looks not
a good idea to me.

Regards,
kaz

Re: [SH] Replace hi_const with satisfies_constraint_I16

[Kaz Kojima]

Oleg Endo  wrote:
> The attached patch removes the hi_const function and replaces its use
> with satisfies_constraint_I16.

OK.

Regards,
kaz

Re: [SH] Use bool return types where possible

[Kaz Kojima]

Oleg Endo  wrote:
> The attached patch changes the return types from int to bool for
> functions where it seems appropriate and removes the forward declaration
> of the no longer exiting function sh_pass_in_reg_p.
> 
> Tested by doing 'make all'.
> Will run the testsuite on it just in case.
> 
> OK?

OK.

Regards,
kaz

Re: [RS6000] Stack tie fix.

[Alan Modra]

On Thu, Apr 05, 2012 at 07:23:20PM +0200, Olivier Hainque wrote:
>  IIUC (please correct me if I'm wrong), every time we need to emit a tie, we
>  must ensure that it references all the base regs that were used before to
>  restore regs from the frame (to prevent the sp adjustment past the tie from
>  moving prior to any of these accesses)

The minimal requirement is:  In the prologue, the next frame write
must be prevented from moving before the stack adjust.  In the
epilogue, the previous frame read must be prevented from moving after
the stack adjust.  If the adjacent write/read uses r1 as a base reg,
then we don't need a stack tie at all.

Writes/reads further away won't be reordered over the adjacent
write/read.  At least, I've never seen gcc do so, even with older
versions known to have bugs in aliasing analysis.  Every single case
I've seen of improper reordering had a stack tie that didn't mention
the base reg used by the adjacent write/read (or no tie).

(Hah!  In writing this, I remember why I took out that assert.  What
happens prior to the tie in the prologue is of no concern.)

-- 
Alan Modra
Australia Development Lab, IBM

Re: [google/gcc-4_6] Added dejagnu base line for x86_64-cros-linux-gnu. (issue 5990044)

[asharif]

On 2012/04/05 17:25:44, shenhan wrote:

Hi Jing and Ahmad,



This adds a new test base line for x86_64-cros-linux-gnu. Please take

a look.


Thanks,
Han


lgtm.

http://codereview.appspot.com/5990044/

Re: [SH] Fold big/little endian word code with MSW and LSW

[Oleg Endo]

On Fri, 2012-04-06 at 07:38 +0900, Kaz Kojima wrote:
> Oleg Endo  wrote:
> > The attached patch folds some of the code that needs to access high/low
> > subwords depending on the target endianess by utilizing the existing MSW
> > and LSW macros.
> [snip]
> > * config/sh/sh.c (MSW, LSW): Move macros to...
> > * config/sh/sh.h: ...here.
> > * config/sh/sh.md: Use MSW and LSW macros where applicable.
> 
> Exposing three-letter macro MSW and LSW globally looks not
> a good idea to me.

Would 'HIGH_WORD' and 'LOW_WORD' be OK as an alternative?

Cheers,
Oleg

Re: [branches/google/gcc-4_6_2-mobile] Backported r186168 from branches/google/gcc-4_6. (issue 5991052)

[asharif]

On 2012/04/05 21:56:19, asharif wrote:

Added shenhan to the list of reviewers.


I'm abandoning this CL in favor of a new one which will be a bulk
integrate from branches/google/gcc-4_6 to
branches/google/gcc-4_6_2-mobile.

Sorry about the noise.

http://codereview.appspot.com/5991052/

Re: [SH] Fold big/little endian word code with MSW and LSW

[Kaz Kojima]

From: Oleg Endo 
>> Exposing three-letter macro MSW and LSW globally looks not
>> a good idea to me.
> 
> Would 'HIGH_WORD' and 'LOW_WORD' be OK as an alternative?

Sounds better but still a bit too generic.  SH_{HIGH,LOW}_WORD
would be Ok, though not so cool. 

Regards,
kaz

[Patch, ARM] Enable GCC to support new ARM core cortex-m0+

[Terry Guo]

Hello,

This simple patch is to enable GCC to accept new option -mcpu=cortex-m0plus
in order to support newly released Cortex-M0+. Is it OK to trunk, 4.7 branch
and 4.6 branch?

BR,
Terry

2012-04-06  Terry Guo  

* config/arm/arm-cores.def: Added core cortex-m0plus.
* config/arm/arm-tune.md: Regenerated.
* config/arm/arm-tables.opt: Regenerated.
* doc/invoke.texi: Added entry for cpu ARM Cortex-M0PLUS.diff --git a/gcc/config/arm/arm-cores.def b/gcc/config/arm/arm-cores.def
index 80609e0..d82b10b 100644
--- a/gcc/config/arm/arm-cores.def
+++ b/gcc/config/arm/arm-cores.def
@@ -137,4 +137,4 @@ ARM_CORE("cortex-m4", cortexm4, 7EM,
 FL_LDSCHED, cortex)
 ARM_CORE("cortex-m3",cortexm3, 7M,  
FL_LDSCHED, cortex)
 ARM_CORE("cortex-m1",cortexm1, 6M,  
FL_LDSCHED, cortex)
 ARM_CORE("cortex-m0",cortexm0, 6M,  
FL_LDSCHED, cortex)
-
+ARM_CORE("cortex-m0plus", cortexm0plus,6M, 
 FL_LDSCHED, cortex)
diff --git a/gcc/config/arm/arm-tables.opt b/gcc/config/arm/arm-tables.opt
index c0b2437..aa64f9c 100644
--- a/gcc/config/arm/arm-tables.opt
+++ b/gcc/config/arm/arm-tables.opt
@@ -270,6 +270,9 @@ Enum(processor_type) String(cortex-m1) Value(cortexm1)
 EnumValue
 Enum(processor_type) String(cortex-m0) Value(cortexm0)
 
+EnumValue
+Enum(processor_type) String(cortex-m0plus) Value(cortexm0plus)
+
 Enum
 Name(arm_arch) Type(int)
 Known ARM architectures (for use with the -march= option):
diff --git a/gcc/config/arm/arm-tune.md b/gcc/config/arm/arm-tune.md
index 54ef0f1..040587a 100644
--- a/gcc/config/arm/arm-tune.md
+++ b/gcc/config/arm/arm-tune.md
@@ -1,5 +1,5 @@
 ;; -*- buffer-read-only: t -*-
 ;; Generated automatically by gentune.sh from arm-cores.def
 (define_attr "tune"
-   
"arm2,arm250,arm3,arm6,arm60,arm600,arm610,arm620,arm7,arm7d,arm7di,arm70,arm700,arm700i,arm710,arm720,arm710c,arm7100,arm7500,arm7500fe,arm7m,arm7dm,arm7dmi,arm8,arm810,strongarm,strongarm110,strongarm1100,strongarm1110,fa526,fa626,arm7tdmi,arm7tdmis,arm710t,arm720t,arm740t,arm9,arm9tdmi,arm920,arm920t,arm922t,arm940t,ep9312,arm10tdmi,arm1020t,arm9e,arm946es,arm966es,arm968es,arm10e,arm1020e,arm1022e,xscale,iwmmxt,iwmmxt2,fa606te,fa626te,fmp626,fa726te,arm926ejs,arm1026ejs,arm1136js,arm1136jfs,arm1176jzs,arm1176jzfs,mpcorenovfp,mpcore,arm1156t2s,arm1156t2fs,genericv7a,cortexa5,cortexa7,cortexa8,cortexa9,cortexa15,cortexr4,cortexr4f,cortexr5,cortexm4,cortexm3,cortexm1,cortexm0"
+   
"arm2,arm250,arm3,arm6,arm60,arm600,arm610,arm620,arm7,arm7d,arm7di,arm70,arm700,arm700i,arm710,arm720,arm710c,arm7100,arm7500,arm7500fe,arm7m,arm7dm,arm7dmi,arm8,arm810,strongarm,strongarm110,strongarm1100,strongarm1110,fa526,fa626,arm7tdmi,arm7tdmis,arm710t,arm720t,arm740t,arm9,arm9tdmi,arm920,arm920t,arm922t,arm940t,ep9312,arm10tdmi,arm1020t,arm9e,arm946es,arm966es,arm968es,arm10e,arm1020e,arm1022e,xscale,iwmmxt,iwmmxt2,fa606te,fa626te,fmp626,fa726te,arm926ejs,arm1026ejs,arm1136js,arm1136jfs,arm1176jzs,arm1176jzfs,mpcorenovfp,mpcore,arm1156t2s,arm1156t2fs,genericv7a,cortexa5,cortexa7,cortexa8,cortexa9,cortexa15,cortexr4,cortexr4f,cortexr5,cortexm4,cortexm3,cortexm1,cortexm0,cortexm0plus"
(const (symbol_ref "((enum attr_tune) arm_tune)")))
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 8571a8b..f81a223 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -10668,6 +10668,7 @@ assembly code.  Permissible names are: @samp{arm2}, 
@samp{arm250},
 @samp{cortex-m4}, @samp{cortex-m3},
 @samp{cortex-m1},
 @samp{cortex-m0},
+@samp{cortex-m0plus},
 @samp{xscale}, @samp{iwmmxt}, @samp{iwmmxt2}, @samp{ep9312},
 @samp{fa526}, @samp{fa626},
 @samp{fa606te}, @samp{fa626te}, @samp{fmp626}, @samp{fa726te}.