Re: libobjc: Remove Traditional Objective-C runtime API

[Jakub Jelinek]

On Tue, Jun 07, 2011 at 09:37:42PM +0200, Nicola Pero wrote:
> This patch completes the removal of the public part of the 
> Traditional Objective-C runtime API from libobjc.
> 
> From now on, the only supported API is the "Modern" API. :-)

If you are removing exported functions from libobjc.so, you should
bump VERSION= in libobjc/configure.ac.

Jakub

Re: [PATH] PR/49139 fix always_inline failures diagnostics

[Christian Bruel]

Hello Richard,

On 06/06/2011 11:55 AM, Richard Guenther wrote:

On Mon, Jun 6, 2011 at 10:58 AM, Christian Bruel  wrote:




OK, the only difference is that we don't have the node analyzed here, so
externally_visible, etc are not set. With the initial proposal the
warning
was emitted only if the function could not be inlined. Now it will be
emitted for each  DECL_COMDAT (decl)&&!DECL_DECLARED_INLINE_P (decl))
even
if not preemptible, so conservatively we don't want to duplicate the
availability check.


Hm, I'm confused.  Do all DECL_COMDAT functions have the
always_inline attribute set?  I would have expected

+  if (lookup_attribute ("always_inline", DECL_ATTRIBUTES (decl)))
+   {
+ if (!DECL_DECLARED_INLINE_P (decl))
+   warning (OPT_Wattributes,
+"always_inline not declared inline might not be
inlinable");
+   }



I meant !DECL_COMDAT || !DECL_DECLARED_INLINE_P. but I was overprecautious.
Didn't realize that member functions was already marked with
DECLARED_INLINED_P even if not explicitly set. So OK one check is enough


do you get excessive warnings with this?



No I don't. That's enough to catch the original issue




Unfortunately still not satisfactory, I've been testing it against a few 
packages, and I notice excessive warnings with the use of __typeof 
(__error) that doesn't propagate the inline keyword.


For instance, a reduced use extracted from the glibc

extern __inline __attribute__ ((__always_inline__))  void
error ()
{

}

extern void
__error ()
{
}

extern __typeof (__error) error __attribute__ ((weak, alias ("__error")));

emits an annoying warning on the error redefinition.

So, a check in addition of the DECL_DECLARED_INLINED_P is needed, 
TREE_ADDRESSABLE seems appropriate, since in the case of missing inline 
the function would be emitted. So I'm testing:


if (lookup_attribute ("always_inline", DECL_ATTRIBUTES (decl))
  && !DECL_DECLARED_INLINE_P (decl)
  && TREE_ADDRESSABLE (decl))

other idea ? or should be just drop this warning ?


Ok.  The patch is ok with the !DECL_DECLARED_INLINE_P check
if it still passes bootstrap&  regtest.



thanks, for now I postpone until glibc is ok and more legacy checks.

Cheers

Christian


Thanks,
Richard.


Cheers

Christian

Re: libobjc: Remove Traditional Objective-C runtime API

[Nicola Pero]

>> This patch completes the removal of the public part of the 
>> Traditional Objective-C runtime API from libobjc.
>> 
>> From now on, the only supported API is the "Modern" API. :-)
> 
> If you are removing exported functions from libobjc.so, you should
> bump VERSION= in libobjc/configure.ac.

Yes, sure ... shall I do that now ?  I'm not done with changes yet. ;-)

I suppose we'll bump VERSION only once between 4.6.0 and 4.7.0 ?
Or do we want to keep bumping it at every change ?

Thanks

Re: libobjc: Remove Traditional Objective-C runtime API

[Nicola Pero]

>>> This patch completes the removal of the public part of the 
>>> Traditional Objective-C runtime API from libobjc.
>>> 
>>> From now on, the only supported API is the "Modern" API. :-)
>> 
>> If you are removing exported functions from libobjc.so, you should
>> bump VERSION= in libobjc/configure.ac.
> 
> Yes, sure ... shall I do that now ?  I'm not done with changes yet. ;-)

But - you're right that we should bump it, so I bumped it :-)
I suppose we could bump it again when we get into phase 3, when we're finished
with the changes.

Thanks

Index: configure
===
--- configure   (revision 174797)
+++ configure   (working copy)
@@ -2274,7 +2274,7 @@
 # We need the following definitions because AC_PROG_LIBTOOL relies on them
 PACKAGE=libobjc
 # Version is pulled out to make it a bit easier to change using sed.
-VERSION=3:0:0
+VERSION=4:0:0
 
 
 # This works around the fact that libtool configuration may change LD
Index: configure.ac
===
--- configure.ac(revision 174797)
+++ configure.ac(working copy)
@@ -27,7 +27,7 @@
 # We need the following definitions because AC_PROG_LIBTOOL relies on them
 PACKAGE=libobjc
 # Version is pulled out to make it a bit easier to change using sed.
-VERSION=3:0:0
+VERSION=4:0:0
 AC_SUBST(VERSION)
 
 # This works around the fact that libtool configuration may change LD
Index: ChangeLog
===
--- ChangeLog   (revision 174797)
+++ ChangeLog   (working copy)
@@ -1,5 +1,10 @@
 2011-06-08  Nicola Pero  
 
+   * configure.ac (VERSION): Bumped to 4:0:0.
+   * configure (VERSION): Likewise.
+
+2011-06-08  Nicola Pero  
+
* objc/README: Updated.
* objc-private/selector.h: Updated comments.

Re: [PATCH] Better propagation of flags in access trees of SRA

[Richard Guenther]

On Tue, 7 Jun 2011, Martin Jambor wrote:

> Hi,
> 
> the way we propagate flags in SRA access tree has evolved in an
> unfortunate way, this patch simplifies the whole thing while doing
> exactly the same thing.
> 
> Bootstrapped and tested on x86_64-linux, OK for trunk?

Ok.

Thanks,
Richard.

> Thanks,
> 
> Martin
> 
> 
> 
> 2011-06-06  Martin Jambor  
> 
>   * tree-sra.c (mark_rw_status): Removed.
>   (analyze_access_subtree): New parameter parent instead of
>   mark_read and mark_write, propagate from that.
> 
> Index: src/gcc/tree-sra.c
> ===
> *** src.orig/gcc/tree-sra.c
> --- src/gcc/tree-sra.c
> *** expr_with_var_bounded_array_refs_p (tree
> *** 1864,1871 
> return false;
>   }
>   
> - enum mark_rw_status { SRA_MRRW_NOTHING, SRA_MRRW_DIRECT, SRA_MRRW_ASSIGN};
> - 
>   /* Analyze the subtree of accesses rooted in ROOT, scheduling replacements 
> when
>  both seeming beneficial and when ALLOW_REPLACEMENTS allows it.  Also set 
> all
>  sorts of access flags appropriately along the way, notably always set
> --- 1864,1869 
> *** enum mark_rw_status { SRA_MRRW_NOTHING,
> *** 1905,1913 
>  11   1   1   Yes Any of the above yeses  
> */
>   
>   static bool
> ! analyze_access_subtree (struct access *root, bool allow_replacements,
> ! enum mark_rw_status mark_read,
> ! enum mark_rw_status mark_write)
>   {
> struct access *child;
> HOST_WIDE_INT limit = root->offset + root->size;
> --- 1903,1910 
>  11   1   1   Yes Any of the above yeses  
> */
>   
>   static bool
> ! analyze_access_subtree (struct access *root, struct access *parent,
> ! bool allow_replacements)
>   {
> struct access *child;
> HOST_WIDE_INT limit = root->offset + root->size;
> *** analyze_access_subtree (struct access *r
> *** 1915,1943 
> bool scalar = is_gimple_reg_type (root->type);
> bool hole = false, sth_created = false;
>   
> !   if (root->grp_assignment_read)
> ! mark_read = SRA_MRRW_ASSIGN;
> !   else if (mark_read == SRA_MRRW_ASSIGN)
> ! {
> !   root->grp_read = 1;
> !   root->grp_assignment_read = 1;
> ! }
> !   else if (mark_read == SRA_MRRW_DIRECT)
> ! root->grp_read = 1;
> !   else if (root->grp_read)
> ! mark_read = SRA_MRRW_DIRECT;
> ! 
> !   if (root->grp_assignment_write)
> ! mark_write = SRA_MRRW_ASSIGN;
> !   else if (mark_write == SRA_MRRW_ASSIGN)
>   {
> !   root->grp_write = 1;
> !   root->grp_assignment_write = 1;
>   }
> -   else if (mark_write == SRA_MRRW_DIRECT)
> - root->grp_write = 1;
> -   else if (root->grp_write)
> - mark_write = SRA_MRRW_DIRECT;
>   
> if (root->grp_unscalarizable_region)
>   allow_replacements = false;
> --- 1912,1928 
> bool scalar = is_gimple_reg_type (root->type);
> bool hole = false, sth_created = false;
>   
> !   if (parent)
>   {
> !   if (parent->grp_read)
> ! root->grp_read = 1;
> !   if (parent->grp_assignment_read)
> ! root->grp_assignment_read = 1;
> !   if (parent->grp_write)
> ! root->grp_write = 1;
> !   if (parent->grp_assignment_write)
> ! root->grp_assignment_write = 1;
>   }
>   
> if (root->grp_unscalarizable_region)
>   allow_replacements = false;
> *** analyze_access_subtree (struct access *r
> *** 1952,1960 
> else
>   covered_to += child->size;
>   
> !   sth_created |= analyze_access_subtree (child,
> !  allow_replacements && !scalar,
> !  mark_read, mark_write);
>   
> root->grp_unscalarized_data |= child->grp_unscalarized_data;
> hole |= !child->grp_covered;
> --- 1937,1944 
> else
>   covered_to += child->size;
>   
> !   sth_created |= analyze_access_subtree (child, root,
> !  allow_replacements && !scalar);
>   
> root->grp_unscalarized_data |= child->grp_unscalarized_data;
> hole |= !child->grp_covered;
> *** analyze_access_trees (struct access *acc
> *** 2002,2009 
>   
> while (access)
>   {
> !   if (analyze_access_subtree (access, true,
> !   SRA_MRRW_NOTHING, SRA_MRRW_NOTHING))
>   ret = true;
> access = access->next_grp;
>   }
> --- 1986,1992 
>   
> while (access)
>   {
> !   if (analyze_access_subtree (access, NULL, true))
>   ret = true;
> access = access->next_grp;
>   }
> 
> 

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

Re: libobjc: Remove Traditional Objective-C runtime API

[Nicola Pero]

I also bumped the API version #define marker.

Committed to trunk.

Thanks

Index: ChangeLog
===
--- ChangeLog   (revision 174798)
+++ ChangeLog   (working copy)
@@ -1,5 +1,9 @@
 2011-06-08  Nicola Pero  
 
+   * objc/objc.h (__GNU_LIBOBJC__): Bumped to 20110608.
+
+2011-06-08  Nicola Pero  
+
* configure.ac (VERSION): Bumped to 4:0:0.
* configure (VERSION): Likewise.
 
Index: objc/objc.h
===
--- objc/objc.h (revision 174797)
+++ objc/objc.h (working copy)
@@ -43,7 +43,7 @@
release).  This macro is only defined starting with the GNU
Objective-C Runtime shipped with GCC 4.6.0.  If it is not defined,
it is either an older version of the runtime, or another runtime.  */
-#define __GNU_LIBOBJC__ 20100911
+#define __GNU_LIBOBJC__ 20110608
 
 /* Definition of the boolean type.

Re: libobjc: Remove Traditional Objective-C runtime API

[Jakub Jelinek]

On Wed, Jun 08, 2011 at 09:25:09AM +0100, Nicola Pero wrote:
> >>> This patch completes the removal of the public part of the 
> >>> Traditional Objective-C runtime API from libobjc.
> >>> 
> >>> From now on, the only supported API is the "Modern" API. :-)
> >> 
> >> If you are removing exported functions from libobjc.so, you should
> >> bump VERSION= in libobjc/configure.ac.
> > 
> > Yes, sure ... shall I do that now ?  I'm not done with changes yet. ;-)
> 
> But - you're right that we should bump it, so I bumped it :-)

Thanks.  All I want to ensure is that it is not forgotten, releasing 4.7
with ABI incompatible libobjc.so.3 would be bad.  And there have been many
incompatible changes already...

> I suppose we could bump it again when we get into phase 3, when we're finished
> with the changes.

No, IMHO it should stay at 4:0:0 then.  It won't be in any released
gcc in between.

Jakub

Re: -fdump-passes -fenable-xxx=func_name_list

[Richard Guenther]

On Tue, Jun 7, 2011 at 8:54 PM, Xinliang David Li  wrote:
> Please review the attached two patches.
>
> In the first patch, gate functions are cleaned up. All the per
> function legality checks are moved into the executor and the
> optimization heuristic checks (optimize for size) remain in the
> gators. These allow the the following overriding order:
>
>    common flags (O2, -ftree-vrp, -fgcse etc)   <---  compiler
> heuristic (optimize for size/speed) <--- -fdisable/enable forcing pass
> options  <--- legality check
>
> Testing under going. Ok for trunk?

It's somewhat odd that you keep the optimize for size/speed checks
in the gate - yes, they also work with a NULL cfun, returning a "default"
(previously they were just optimize_size checks).  So probably it
makes sense to keep those in the gates.

I notice that with the patch we will now unconditionally execute
TODOs for those passes that were disabled per function which
will eventually cause some compile-time regression, mostly
restricted to checking enabled builds (which is ok I guess).  I
suppose we could allow the execute function to return a special
value that says "I really didn't do anything".  OTOH most of the
pass machinery needs some cleanup anyway which can be done
as followup.

The gate cleanup patch looks ok to me, please give others a chance
to comment on this change.

Thanks,
Richard.

> Thanks,
>
> David
>
> On Tue, Jun 7, 2011 at 9:24 AM, Xinliang David Li  wrote:
>> Ok -- that sounds good.
>>
>> David
>>
>> On Tue, Jun 7, 2011 at 3:10 AM, Richard Guenther
>>  wrote:
>>> On Mon, Jun 6, 2011 at 6:00 PM, Xinliang David Li  
>>> wrote:
 On Mon, Jun 6, 2011 at 4:38 AM, Richard Guenther
  wrote:
> On Thu, Jun 2, 2011 at 9:12 AM, Xinliang David Li  
> wrote:
>> This is the version of the patch that walks through pass lists.
>>
>> Ok with this one?
>
> +/* Dump all optimization passes.  */
> +
> +void
> +dump_passes (void)
> +{
> +  struct cgraph_node *n, *node = NULL;
> +  tree save_fndecl = current_function_decl;
> +
> +  fprintf (stderr, "MAX_UID = %d\n", cgraph_max_uid);
>
> this isn't accurate info - cloning can cause more cgraph nodes to
> appear (it also looks completely unrelated to dump_passes ...).
> Please drop it.

 Ok.


>
> +  create_pass_tab();
> +  gcc_assert (pass_tab);
>
> you have quite many asserts of this kind - we don't want them when
> the previous stmt as in this case indicates everything is ok.

 ok.

>
> +  push_cfun (DECL_STRUCT_FUNCTION (node->decl));
>
> this has side-effects, I'm not sure we want this here.  Why do you
> need it?  Probably because of
>
> +  is_really_on = override_gate_status (pass, current_function_decl, 
> is_on);
>
> ?  But that is dependent on the function given which should have no
> effect (unless it is overridden globally in which case 
> override_gate_status
> and friends should deal with a NULL cfun).

 As we discussed, currently some pass gate functions depend on per node
 information -- those checks need to be pushed into execute functions.
 I would like to clean those up later -- at which time, the push/pop
 can be removed.
>>>
>>> I'd like to do it the other way around, first clean up the gate functions 
>>> then
>>> drop in this patch without the cfun push/pop.  The revised patch looks ok
>>> to me with the cfun push/pop removed.
>>>
>>> Thanks,
>>> Richard.
>>>
>
> I don't understand why you need another table mapping pass to name
> when pass->name is available and the info is trivially re-constructible.

 This is needed as the pass->name is not the canonicalized name (i.e.,
 not with number suffix etc), so the extra mapping from id to
 normalized name is needed.

 Thanks,

 David

>
> Thanks,
> Richard.
>
>> David
>>
>> On Wed, Jun 1, 2011 at 12:45 PM, Xinliang David Li  
>> wrote:
>>> On Wed, Jun 1, 2011 at 12:29 PM, Richard Guenther
>>>  wrote:
 On Wed, Jun 1, 2011 at 6:16 PM, Xinliang David Li  
 wrote:
> On Wed, Jun 1, 2011 at 1:51 AM, Richard Guenther
>  wrote:
>> On Wed, Jun 1, 2011 at 1:34 AM, Xinliang David Li 
>>  wrote:
>>> The following patch implements the a new option that dumps gcc PASS
>>> configuration. The sample output is attached.  There is one
>>> limitation: some placeholder passes that are named with '*xxx' are
>>> note registered thus they are not listed. They are not important as
>>> they can not be turned on/off anyway.
>>>
>>> The patch also enhanced -fenable-xxx and -fdisable-xx to allow a 
>>> list
>>> of function assembler names to be specified.
>>>
>>> Ok for trunk?
>>
>> Please split the patch.
>>
>>

Re: -fdump-passes -fenable-xxx=func_name_list

[Richard Guenther]

On Tue, Jun 7, 2011 at 10:20 PM, Xinliang David Li  wrote:
> The dump-pass patch with test case.

Ok.

Thanks,
Richard.

> David
>
> On Tue, Jun 7, 2011 at 11:54 AM, Xinliang David Li  wrote:
>> Please review the attached two patches.
>>
>> In the first patch, gate functions are cleaned up. All the per
>> function legality checks are moved into the executor and the
>> optimization heuristic checks (optimize for size) remain in the
>> gators. These allow the the following overriding order:
>>
>>    common flags (O2, -ftree-vrp, -fgcse etc)   <---  compiler
>> heuristic (optimize for size/speed) <--- -fdisable/enable forcing pass
>> options  <--- legality check
>>
>> Testing under going. Ok for trunk?
>>
>> Thanks,
>>
>> David
>>
>> On Tue, Jun 7, 2011 at 9:24 AM, Xinliang David Li  wrote:
>>> Ok -- that sounds good.
>>>
>>> David
>>>
>>> On Tue, Jun 7, 2011 at 3:10 AM, Richard Guenther
>>>  wrote:
 On Mon, Jun 6, 2011 at 6:00 PM, Xinliang David Li  
 wrote:
> On Mon, Jun 6, 2011 at 4:38 AM, Richard Guenther
>  wrote:
>> On Thu, Jun 2, 2011 at 9:12 AM, Xinliang David Li  
>> wrote:
>>> This is the version of the patch that walks through pass lists.
>>>
>>> Ok with this one?
>>
>> +/* Dump all optimization passes.  */
>> +
>> +void
>> +dump_passes (void)
>> +{
>> +  struct cgraph_node *n, *node = NULL;
>> +  tree save_fndecl = current_function_decl;
>> +
>> +  fprintf (stderr, "MAX_UID = %d\n", cgraph_max_uid);
>>
>> this isn't accurate info - cloning can cause more cgraph nodes to
>> appear (it also looks completely unrelated to dump_passes ...).
>> Please drop it.
>
> Ok.
>
>
>>
>> +  create_pass_tab();
>> +  gcc_assert (pass_tab);
>>
>> you have quite many asserts of this kind - we don't want them when
>> the previous stmt as in this case indicates everything is ok.
>
> ok.
>
>>
>> +  push_cfun (DECL_STRUCT_FUNCTION (node->decl));
>>
>> this has side-effects, I'm not sure we want this here.  Why do you
>> need it?  Probably because of
>>
>> +  is_really_on = override_gate_status (pass, current_function_decl, 
>> is_on);
>>
>> ?  But that is dependent on the function given which should have no
>> effect (unless it is overridden globally in which case 
>> override_gate_status
>> and friends should deal with a NULL cfun).
>
> As we discussed, currently some pass gate functions depend on per node
> information -- those checks need to be pushed into execute functions.
> I would like to clean those up later -- at which time, the push/pop
> can be removed.

 I'd like to do it the other way around, first clean up the gate functions 
 then
 drop in this patch without the cfun push/pop.  The revised patch looks ok
 to me with the cfun push/pop removed.

 Thanks,
 Richard.

>>
>> I don't understand why you need another table mapping pass to name
>> when pass->name is available and the info is trivially re-constructible.
>
> This is needed as the pass->name is not the canonicalized name (i.e.,
> not with number suffix etc), so the extra mapping from id to
> normalized name is needed.
>
> Thanks,
>
> David
>
>>
>> Thanks,
>> Richard.
>>
>>> David
>>>
>>> On Wed, Jun 1, 2011 at 12:45 PM, Xinliang David Li  
>>> wrote:
 On Wed, Jun 1, 2011 at 12:29 PM, Richard Guenther
  wrote:
> On Wed, Jun 1, 2011 at 6:16 PM, Xinliang David Li 
>  wrote:
>> On Wed, Jun 1, 2011 at 1:51 AM, Richard Guenther
>>  wrote:
>>> On Wed, Jun 1, 2011 at 1:34 AM, Xinliang David Li 
>>>  wrote:
 The following patch implements the a new option that dumps gcc PASS
 configuration. The sample output is attached.  There is one
 limitation: some placeholder passes that are named with '*xxx' are
 note registered thus they are not listed. They are not important as
 they can not be turned on/off anyway.

 The patch also enhanced -fenable-xxx and -fdisable-xx to allow a 
 list
 of function assembler names to be specified.

 Ok for trunk?
>>>
>>> Please split the patch.
>>>
>>> I'm not too happy how you dump the pass configuration.  Why not 
>>> simply,
>>> at a _single_ place, walk the pass tree?  Instead of doing pieces 
>>> of it
>>> at pass execution time when it's not already dumped - that really 
>>> looks
>>> gross.
>>
>> Yes, that was the original plan -- but it has problems
>> 1) the dumper needs to know the root pass lists -- which can change
>> frequently -- it can be a long term maintanance burden;
>> 2) the cen

Re: [google] pessimize stack accounting during inlining

[Richard Guenther]

On Wed, Jun 8, 2011 at 1:36 AM, Xinliang David Li  wrote:
> Ok for google/main.   A good candidate patch for trunk too.

Well, it's still not a hard limit as we can't tell how many spill slots
or extra call argument or return value slots we need.

Richard.

> Thanks,
>
> David
>
> On Tue, Jun 7, 2011 at 4:29 PM, Mark Heffernan  wrote:
>> This patch pessimizes stack accounting during inlining.  This enables
>> setting a firm stack size limit (via parameters "large-stack-frame" and
>> "large-stack-frame-growth").  Without this patch the inliner is overly
>> optimistic about potential stack reuse resulting in actual stack frames much
>> larger than the parameterized limits.
>> Internal benchmarks show minor performance differences with non-fdo and
>> lipo, but overall neutral.  Tested/bootstrapped on x86-64.
>> Ok for google-main?
>> Mark
>>
>> 2011-06-07  Mark Heffernan  
>>         * cgraph.h (cgraph_global_info): Remove field.
>>         * ipa-inline.c (cgraph_clone_inlined_nodes): Change
>>         stack frame computation.
>>         (cgraph_check_inline_limits): Ditto.
>>         (compute_inline_parameters): Remove dead initialization.
>>
>> Index: gcc/cgraph.h
>> ===
>> --- gcc/cgraph.h        (revision 174512)
>> +++ gcc/cgraph.h        (working copy)
>> @@ -136,8 +136,6 @@ struct GTY(()) cgraph_local_info {
>>  struct GTY(()) cgraph_global_info {
>>    /* Estimated stack frame consumption by the function.  */
>>    HOST_WIDE_INT estimated_stack_size;
>> -  /* Expected offset of the stack frame of inlined function.  */
>> -  HOST_WIDE_INT stack_frame_offset;
>>
>>    /* For inline clones this points to the function they will be
>>       inlined into.  */
>> Index: gcc/ipa-inline.c
>> ===
>> --- gcc/ipa-inline.c    (revision 174512)
>> +++ gcc/ipa-inline.c    (working copy)
>> @@ -229,8 +229,6 @@ void
>>  cgraph_clone_inlined_nodes (struct cgraph_edge *e, bool duplicate,
>>                             bool update_original)
>>  {
>> -  HOST_WIDE_INT peak;
>> -
>>    if (duplicate)
>>      {
>>        /* We may eliminate the need for out-of-line copy to be output.
>> @@ -279,13 +277,13 @@ cgraph_clone_inlined_nodes (struct cgrap
>>      e->callee->global.inlined_to = e->caller->global.inlined_to;
>>    else
>>      e->callee->global.inlined_to = e->caller;
>> -  e->callee->global.stack_frame_offset
>> -    = e->caller->global.stack_frame_offset
>> -      + inline_summary (e->caller)->estimated_self_stack_size;
>> -  peak = e->callee->global.stack_frame_offset
>> -      + inline_summary (e->callee)->estimated_self_stack_size;
>> -  if (e->callee->global.inlined_to->global.estimated_stack_size < peak)
>> -    e->callee->global.inlined_to->global.estimated_stack_size = peak;
>> +
>> +  /* Pessimistically assume no sharing of stack space.  That is, the
>> +     frame size of a function is estimated as the original frame size
>> +     plus the sum of the frame sizes of all inlined callees.  */
>> +  e->callee->global.inlined_to->global.estimated_stack_size +=
>> +    inline_summary (e->callee)->estimated_self_stack_size;
>> +
>>    cgraph_propagate_frequency (e->callee);
>>
>>    /* Recursively clone all bodies.  */
>> @@ -430,8 +428,7 @@ cgraph_check_inline_limits (struct cgrap
>>
>>    stack_size_limit += stack_size_limit * PARAM_VALUE
>> (PARAM_STACK_FRAME_GROWTH) / 100;
>>
>> -  inlined_stack = (to->global.stack_frame_offset
>> -                  + inline_summary (to)->estimated_self_stack_size
>> +  inlined_stack = (to->global.estimated_stack_size
>>                    + what->global.estimated_stack_size);
>>    if (inlined_stack  > stack_size_limit
>>        && inlined_stack > PARAM_VALUE (PARAM_LARGE_STACK_FRAME))
>> @@ -2064,7 +2061,6 @@ compute_inline_parameters (struct cgraph
>>    self_stack_size = optimize ? estimated_stack_frame_size (node) : 0;
>>    inline_summary (node)->estimated_self_stack_size = self_stack_size;
>>    node->global.estimated_stack_size = self_stack_size;
>> -  node->global.stack_frame_offset = 0;
>>
>>    /* Can this function be inlined at all?  */
>>    node->local.inlinable = tree_inlinable_function_p (node->decl);
>>
>

Re: Dump before flag

[Richard Guenther]

On Wed, Jun 8, 2011 at 1:08 AM, Xinliang David Li  wrote:
> The following is the patch that does the job. Most of the changes are
> just  removing TODO_dump_func. The major change is in passes.c and
> tree-pass.h.
>
> -fdump-xxx-yyy-start       <-- dump before TODO_start
> -fdump-xxx-yyy-before    <-- dump before main pass after TODO_pass
> -fdump-xxx-yyy-after       <-- dump after main pass before TODO_finish
> -fdump-xxx-yyy-finish      <-- dump after TODO_finish

Can we bikeshed a bit more about these names?  "start" and "before"
have no semantical difference to me ... as the dump before TODO_start
of a pass and the dump after TODO_finish of the previous pass are
identical (hopefully ;)), maybe merge those into a -between flag?
If you'd specify it for a single pass then you'd get both -start and -finish
(using your naming scheme).  Splitting that dump(s) to different files
then might make sense (not sure about the name to use).

Note that I find it extremely useful to have dumping done in
chronological order - splitting some of it to different files destroys
this, especially a dump after TODO_start or before TODO_finish
should appear in the same file (or we could also start splitting
individual TODO_ output into sub-dump-files).  I guess what would
be nice instread would be a fancy dump-file viewer that could
show diffs, hide things like SCEV output, etc.

I suppose a patch that removes the dump TODO and unconditionally
dumps at the current point would be a good preparation for this
enhancing patch.

Richard.

> The default is 'finish'.
>
> Does it look ok?
>
> Thanks,
>
> David
>
> On Tue, Jun 7, 2011 at 2:36 AM, Richard Guenther
>  wrote:
>> On Mon, Jun 6, 2011 at 6:20 PM, Xinliang David Li  wrote:

 Your patch doesn't really improve this but adds to the confusion.

 +  /* Override dump TODOs.  */
 +  if (dump_file && (pass->todo_flags_finish & TODO_dump_func)
 +      && (dump_flags & TDF_BEFORE))
 +    {
 +      pass->todo_flags_finish &= ~TODO_dump_func;
 +      pass->todo_flags_start |= TODO_dump_func;
 +    }

 and certainly writing to pass is not ok.  And the TDF_BEFORE flag
 looks misplaced as it controls TODOs, not dumping behavior.
 Yes, it's a mess right now but the above looks like a hack ontop
 of that mess (maybe because of it, but well ...).

>>>
>>> How about removing dumping TODO completely -- this can be done easily
>>> -- I don't understand why pass wants extra control on the dumping if
>>> user already asked for dumping -- it is annoying to see empty IR dump
>>> for a pass when I want to see it.
>>>
 At least I would have expected to also get the dump after the
 pass, not only the one before it with this dump flag.

 Now, why can't you look at the previous pass output for the
 before-dump (as I do usually)?
>>>
>>> For one thing, you need to either remember what is the previous pass,
>>> or dump all passes which for large files can take very long time. Even
>>> with all the dumps, you will need to eyeballing to find the previous
>>> pass which may or may not have the IR dumped.
>>>
>>> How about removing dump TODO?
>>
>> Yeah, I think this would go in the right direction.  Currently some passes
>> do not dump function bodies because they presumably do no IL
>> modification.  But this is certainly the minority (and some passes do not
>> dump bodies even though they are modifying the IL ...).
>>
>> So I'd say we should by default dump function bodies.
>>
>> Note that there are three useful dumping positions (maybe four),
>> before todo-start, after todo-start, before todo-finish and after 
>> todo-finish.
>> By default we'd want after todo-finish.  When we no longer dump via
>> a TODO then we could indeed use dump-flags to control this
>> (maybe -original for the body before todo-start).
>>
>> What to others think?
>>
>> Richard.
>>
>>> Thanks,
>>>
>>> David
>>>
>>>

 Richard.

>>>
>>
>

Re: [PATH] PR/49139 fix always_inline failures diagnostics

[Richard Guenther]

On Wed, Jun 8, 2011 at 9:46 AM, Christian Bruel  wrote:
> Hello Richard,
>
> On 06/06/2011 11:55 AM, Richard Guenther wrote:
>>
>> On Mon, Jun 6, 2011 at 10:58 AM, Christian Bruel
>>  wrote:
>>>
>>>
> OK, the only difference is that we don't have the node analyzed here,
> so
> externally_visible, etc are not set. With the initial proposal the
> warning
> was emitted only if the function could not be inlined. Now it will be
> emitted for each  DECL_COMDAT (decl)&&    !DECL_DECLARED_INLINE_P
> (decl))
> even
> if not preemptible, so conservatively we don't want to duplicate the
> availability check.

 Hm, I'm confused.  Do all DECL_COMDAT functions have the
 always_inline attribute set?  I would have expected

 +      if (lookup_attribute ("always_inline", DECL_ATTRIBUTES (decl)))
 +       {
 +         if (!DECL_DECLARED_INLINE_P (decl))
 +           warning (OPT_Wattributes,
 +                    "always_inline not declared inline might not be
 inlinable");
 +       }

>>>
>>> I meant !DECL_COMDAT || !DECL_DECLARED_INLINE_P. but I was
>>> overprecautious.
>>> Didn't realize that member functions was already marked with
>>> DECLARED_INLINED_P even if not explicitly set. So OK one check is enough
>>>
 do you get excessive warnings with this?

>>>
>>> No I don't. That's enough to catch the original issue
>>
>
> Unfortunately still not satisfactory, I've been testing it against a few
> packages, and I notice excessive warnings with the use of __typeof (__error)
> that doesn't propagate the inline keyword.
>
> For instance, a reduced use extracted from the glibc
>
> extern __inline __attribute__ ((__always_inline__))  void
> error ()
> {
>
> }
>
> extern void
> __error ()
> {
> }
>
> extern __typeof (__error) error __attribute__ ((weak, alias ("__error")));
>
> emits an annoying warning on the error redefinition.
>
> So, a check in addition of the DECL_DECLARED_INLINED_P is needed,
> TREE_ADDRESSABLE seems appropriate, since in the case of missing inline the
> function would be emitted. So I'm testing:
>
> if (lookup_attribute ("always_inline", DECL_ATTRIBUTES (decl))
>          && !DECL_DECLARED_INLINE_P (decl)
>          && TREE_ADDRESSABLE (decl))
>
> other idea ? or should be just drop this warning ?

Hmm.  Honza, any idea on the above?  Christian, I suppose you
could check if the cgraph node for that decl has the redefined_extern_inline
flag set (checking TREE_ADDRESSABLE looks bogus to me).
I'm not sure how the frontend merges those two decls - I suppose
it will have a weak always-inline function with body :/

Richard.

>> Ok.  The patch is ok with the !DECL_DECLARED_INLINE_P check
>> if it still passes bootstrap&  regtest.
>>
>
> thanks, for now I postpone until glibc is ok and more legacy checks.
>
> Cheers
>
> Christian
>
>> Thanks,
>> Richard.
>>
>>> Cheers
>>>
>>> Christian
>>>
>>
>

Re: [build] Define HAVE_GAS_HIDDEN on Darwin

[Rainer Orth]

Jason Merrill  writes:

> On 05/19/2011 01:33 PM, Rainer Orth wrote:
>> The cleanest way to account for this seems to allow overriding
>> USE_LINKONCE_INDIRECT in target headers (darwin.h in this case).
>>
>> If Jason or Richard consider this appropriate, I'll modify the patch
>> accordingly and apply after retesting.
>
> Not really.  The use in dwarf2asm seems no different from the use in
> i386.c, except that the latter has a special TARGET_MACHO case instead. As
> you say, dwarf2asm shouldn't be using .hidden directly, and that's the bug
> to fix.

Once I got around to it, this proved to be remarkably easy, as can be
seen below.

One additional complication was detected during Darwin testing: with
HAVE_GAS_HIDDEN defined, the 32-bit {ix86, rs6000}_stack_protect_fail
would call default_hidden_stack_protect_fail.  This emits calls to
__stack_chk_fail_local which is missing from Darwin libc, so I had to
revert to the default on Darwin.

Bootstrapped without regressions on i386-apple-darwin9.8.0.
powerpc-apple-darwin9.8.0 bootstrap is still running.  Unfortunately,
Darwin seems to be exceedingly unreliable under load: tests randomly
time out and work again the next time.  This doesn't happen for me on
any other platform.  This makes actually checking for regressions quite
tedious.  I've checked that any newly failing test was a timeout, not an
actual failure.

The patch has also been bootstrapped without regressions on
i386-pc-solaris2.8 and i386-pc-solaris2.11 and the DW.ref.* symbols are
still hidden as before.

The Darwin parts of the previous versions have already been approved,
but I'd appreciate if Mike could have a look at the changes.  Ok for
mainline?

Thanks.
Rainer


2011-04-30  Rainer Orth  

gcc:
* configure.ac (gcc_cv_as_hidden): Enable on *-*-darwin*.
(gcc_cv_ld_hidden): Likewise.
* configure: Regenerate.
* config/i386/i386.c (USE_HIDDEN_LINKONCE): Remove TARGET_MACHO.
(ix86_stack_protect_fail): Mark unused.
(TARGET_STACK_PROTECT_FAIL) [TARGET_MACHO]: Don't redefine.
* config/rs6000/rs6000.c (rs6000_assemble_visibility)
[TARGET_MACHO]: Don't define.
(TARGET_ASM_ASSEMBLE_VISIBILITY): Likewise.
(TARGET_STACK_PROTECT_FAIL): Likewise.
(rs6000_stack_protect_fail): Mark unused.
* dwarf2asm.c (dw2_output_indirect_constant_1): Mark decl hidden if
USE_LINKONCE_INDIRECT.
Don't emit .hidden expicitly.

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -8725,7 +8725,7 @@ ix86_setup_frame_addresses (void)
 }
 
 #ifndef USE_HIDDEN_LINKONCE
-# if (defined(HAVE_GAS_HIDDEN) && (SUPPORTS_ONE_ONLY - 0)) || TARGET_MACHO
+# if defined(HAVE_GAS_HIDDEN) && (SUPPORTS_ONE_ONLY - 0)
 #  define USE_HIDDEN_LINKONCE 1
 # else
 #  define USE_HIDDEN_LINKONCE 0
@@ -32207,7 +32207,7 @@ ix86_mangle_type (const_tree type)
__stack_chk_fail directly.  64-bit code doesn't need to setup any PIC
register, so it is better to call __stack_chk_fail directly.  */
 
-static tree
+static tree ATTRIBUTE_UNUSED
 ix86_stack_protect_fail (void)
 {
   return TARGET_64BIT
@@ -35407,8 +35407,10 @@ ix86_autovectorize_vector_sizes (void)
 #undef TARGET_MANGLE_TYPE
 #define TARGET_MANGLE_TYPE ix86_mangle_type
 
+#ifndef TARGET_MACHO
 #undef TARGET_STACK_PROTECT_FAIL
 #define TARGET_STACK_PROTECT_FAIL ix86_stack_protect_fail
+#endif
 
 #undef TARGET_SUPPORTS_SPLIT_STACK
 #define TARGET_SUPPORTS_SPLIT_STACK ix86_supports_split_stack
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -884,7 +884,7 @@ static bool legitimate_lo_sum_address_p 
 static struct machine_function * rs6000_init_machine_status (void);
 static bool rs6000_assemble_integer (rtx, unsigned int, int);
 static bool no_global_regs_above (int, bool);
-#ifdef HAVE_GAS_HIDDEN
+#if defined (HAVE_GAS_HIDDEN) && !defined (TARGET_MACHO)
 static void rs6000_assemble_visibility (tree, int);
 #endif
 static int rs6000_ra_ever_killed (void);
@@ -1349,7 +1349,7 @@ static const struct default_options rs60
 #undef TARGET_ASM_INTEGER
 #define TARGET_ASM_INTEGER rs6000_assemble_integer
 
-#ifdef HAVE_GAS_HIDDEN
+#if defined (HAVE_GAS_HIDDEN) && !defined (TARGET_MACHO)
 #undef TARGET_ASM_ASSEMBLE_VISIBILITY
 #define TARGET_ASM_ASSEMBLE_VISIBILITY rs6000_assemble_visibility
 #endif
@@ -1558,8 +1558,10 @@ static const struct default_options rs60
 #define TARGET_DEFAULT_TARGET_FLAGS \
   (TARGET_DEFAULT)
 
+#ifndef TARGET_MACHO
 #undef TARGET_STACK_PROTECT_FAIL
 #define TARGET_STACK_PROTECT_FAIL rs6000_stack_protect_fail
+#endif
 
 /* MPC604EUM 3.5.2 Weak Consistency between Multiple Processors
The PowerPC architecture requires only weak consistency among
@@ -16390,7 +16392,7 @@ rs6000_assemble_integer (rtx x, unsigned
   return default_assemble_integer (x, size, aligned_p);
 }
 
-#ifdef HAVE_GAS_HIDDEN
+#if 

[PATCH, PR43864] Gimple level duplicate block cleanup.

[Tom de Vries]

Hi Richard,

I have a patch for PR43864. The patch adds a gimple level duplicate block
cleanup. The patch has been bootstrapped and reg-tested on x86_64, and
reg-tested on ARM. The size impact on ARM for spec2000 is shown in the following
table (%, lower is better).

 nonepic
thumb1  thumb2  thumb1 thumb2
spec2000  99.999.999.8   99.8

PR43864 is currently marked as a duplicate of PR20070, but I'm not sure that the
optimizations proposed in PR20070 would fix this PR.

The problem in this PR is that when compiling with -O2, the example below should
only have one call to free. The original problem is formulated in terms of -Os,
but currently we generate one call to free with -Os, although still not the
smallest code possible. I'll show here the -O2 case, since that's similar to the
original PR.

#include 
void foo (char*, FILE*);
char* hprofStartupp(char *outputFileName, char *ctx)
{
char fileName[1000];
FILE *fp;
sprintf(fileName, outputFileName);
if (access(fileName, 1) == 0) {
free(ctx);
return 0;
}

fp = fopen(fileName, 0);
if (fp == 0) {
free(ctx);
return 0;
}

foo(outputFileName, fp);

return ctx;
}

AFAIU, there are 2 complementary methods of rtl optimizations proposed in 
PR20070.
- Merging 2 blocks which are identical expect for input registers, by using a
  conditional move to choose between the different input registers.
- Merging 2 blocks which have different local registers, by ignoring those
  differences

Blocks .L6 and.L7 have no difference in local registers, but they have a
difference in input registers: r3 and r1. Replacing the move to r5 by a
conditional move would probably be benificial in terms of size, but it's not
clear what condition the conditional move should be using. Calculating such a
condition would add in size and increase the execution path.

gcc -O2 -march=armv7-a -mthumb pr43864.c -S:
...
push{r4, r5, lr}
mov r4, r0
sub sp, sp, #1004
mov r5, r1
mov r0, sp
mov r1, r4
bl  sprintf
mov r0, sp
movsr1, #1
bl  access
mov r3, r0
cbz r0, .L6
movsr1, #0
mov r0, sp
bl  fopen
mov r1, r0
cbz r0, .L7
mov r0, r4
bl  foo
.L3:
mov r0, r5
add sp, sp, #1004
pop {r4, r5, pc}
.L6:
mov r0, r5
mov r5, r3
bl  free
b   .L3
.L7:
mov r0, r5
mov r5, r1
bl  free
b   .L3
...

The proposed patch solved the problem by dealing with the 2 blocks at a level
when they are still identical: at gimple level. It detect that the 2 blocks are
identical, and removes one of them.

The following table shows the impact of the patch on the example in terms of
size for -march=armv7-a:

  without withdelta
Os  : 108  104   -4
O2  : 120  104  -16
Os thumb:  68   64   -4
O2 thumb:  76   64  -12

The gain in size for -O2 is that of removing the entire block, plus the
replacement of 2 moves by a constant set, which also decreases the execution
path. The patch ensures optimal code for both -O2 and -Os.


By keeping track of equivalent definitions in the 2 blocks, we can ignore those
differences in comparison. Without this feature, we would only match blocks with
resultless operations, due the the ssa-nature of gimples.
For example, with this feature, we reduce the following function to its minimum
at gimple level, rather than at rtl level.

int f(int c, int b, int d)
{
  int r, e;

  if (c)
r = b + d;
  else
{
  e = b + d;
  r = e;
}

  return r;
}

;; Function f (f)

f (int c, int b, int d)
{
  int e;

:
  e_6 = b_3(D) + d_4(D);
  return e_6;

}

I'll send the patch with the testcases in a separate email.

OK for trunk?

Thanks,
- Tom

2011-06-08  Tom de Vries  

PR middle-end/43864
* tree-cfgcleanup.c (int_int_splay_lookup, int_int_splay_insert)
(int_int_splay_node_contained_in, int_int_splay_contained_in)
(equiv_lookup, equiv_insert, equiv_contained_in, equiv_init)
(equiv_delete, gimple_base_equal_p, pt_solution_equal_p, gimple_equal_p)
(bb_gimple_equal_p, update_debug_stmts, cleanup_duplicate_preds_1)
(same_or_local_phi_alternatives, cleanup_duplicate_preds): New function.
(cleanup_tree_cfg_bb): Use cleanup_duplicate_preds.
Index: gcc/tree-cfgcleanup.c
===
--- gcc/tree-cfgcleanup.c	(revision 173703)
+++ gcc/tree-cfgcleanup.c	(working copy)
@@ -641,6 +641,552 @@ cleanup_omp_return (basic_block bb)
   return true;
 }
 
+/* Returns true if S contains (I1, I2).  */
+
+static bool
+int_int_splay_lookup (splay_tree s, unsigned

[PATCH, PR43864] Gimple level duplicate block cleanup - test cases.

[Tom de Vries]

On 06/08/2011 11:42 AM, Tom de Vries wrote:

> I'll send the patch with the testcases in a separate email.

OK for trunk?

Thanks,
- Tom

2011-06-08  Tom de Vries  

PR middle-end/43864
* gcc.dg/pr43864.c: New test.
* gcc.dg/pr43864-2.c: New test.
Index: gcc/testsuite/gcc.dg/pr43864-2.c
===
--- /dev/null (new file)
+++ gcc/testsuite/gcc.dg/pr43864-2.c (revision 0)
@@ -0,0 +1,22 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+
+int f(int c, int b, int d)
+{
+  int r, e;
+
+  if (c)
+r = b + d;
+  else
+{
+  e = b + d;
+  r = e;
+}
+
+  return r;
+}
+
+/* { dg-final { scan-tree-dump-times "if " 0 "optimized"} } */
+/* { dg-final { scan-tree-dump-times "\\\+" 1 "optimized"} } */
+/* { dg-final { scan-tree-dump-times "PHI" 0 "optimized"} } */
+/* { dg-final { cleanup-tree-dump "optimized" } } */
Index: gcc/testsuite/gcc.dg/pr43864.c
===
--- /dev/null (new file)
+++ gcc/testsuite/gcc.dg/pr43864.c (revision 0)
@@ -0,0 +1,33 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+
+#include 
+#include 
+
+void foo (char*, FILE*);
+
+char* hprofStartupp (char *outputFileName, char *ctx)
+{
+  char fileName[1000];
+  FILE *fp;
+  sprintf (fileName, outputFileName);
+  if (access (fileName, 1) == 0)
+{
+  free (ctx);
+  return 0;
+}
+
+  fp = fopen (fileName, 0);
+  if (fp == 0)
+{
+  free (ctx);
+  return 0;
+}
+
+  foo (outputFileName, fp);
+
+  return ctx;
+}
+
+/* { dg-final { scan-tree-dump-times "free" 1 "optimized"} } */
+/* { dg-final { cleanup-tree-dump "optimized" } } */

Re: [build] Define HAVE_GAS_HIDDEN on Darwin

[IainS]

On 8 Jun 2011, at 10:29, Rainer Orth wrote:


Darwin seems to be exceedingly unreliable under load: tests randomly
time out and work again the next time.


If you mean random timeouts in dejagnu - I suspect (but have not yet  
proved) that the culprit is insufficient stack allocation in some  
component of tcl or expect itself.


One used to find that non-parallel "make check" would be quite  
reliable - but parallel very unreliable.


I use the following local (not submitted, unofficial) patch to dejagnu  
on Darwin9 - which retries tests that timeout (once) - this has been  
enough to eliminate the frustration for me...


YMMV, of course.

cheers
Iain


--- dejagnu-1.4.4/lib/remote.exp2003-10-11 07:42:46.0 +0100
+++ dejagnu-1.4.4-installed/lib/remote.exp  2010-03-12 09:32:49.0 
+
@@ -74,7 +74,7 @@
 # or output is redirected. If the program needs to be killed, /bin/sh and
 # the kill command will be invoked.
 #
-proc local_exec { commandline inp outp timeout } {
+proc one_local_exec { commandline inp outp timeout } {
 # Tcl's exec is a pile of crap. It does two very inappropriate things
 # firstly, it has no business returning an error if the program being
 # executed happens to write to stderr. Secondly, it appends its own
@@ -155,7 +155,7 @@
 
 set got_eof 0
 set output ""
-
+set status 0
 # Wait for either $timeout seconds to elapse, or for the program to
 # exit.
 expect {
@@ -163,16 +163,19 @@
append output $expect_out(buffer)
if { [string length $output] < 512000 } {
exp_continue -continue_timer
+   } else {
+ warning "one_local_exec: (output string overflow)"
}
}
timeout {
-   warning "program timed out."
+#  warning "one_local_exec: program timed out."
+   set status -2
}
eof {
set got_eof 1
}
 }
-
+
 # Uuugh. Now I'm getting really sick.
 # If we didn't get an EOF, we have to kill the poor defenseless program.
 # However, Tcl has no kill primitive, so we have to execute an external
@@ -207,12 +210,16 @@
set res "wait failed"
}
 }
+
 if { $r2 != 0 || $res != "" || ! $got_eof } {
verbose "close result is $res"
-   set status 1
+   if { $status != -2 } {
+   set status 1
+   }
 } else {
set status 0
 }
+
 verbose "output is $output"
 if { $outp == "" } {
 return [list $status $output]
@@ -221,6 +228,29 @@
 }
 }
 
+proc local_exec { commandline inp outp timeout } {
+set res [one_local_exec $commandline $inp $outp $timeout]
+set stat [lindex $res 0]
+# OK?
+if { $stat != -2 } {
+   return $res 
+}
+# nope...
+#warning "local_exec $commandline timed out : retrying"
+verbose -log "RE-TRIED: (timeout = $timeout) : $commandline "
+if { $timeout < 150 } {
+   set timeout [expr {$timeout} * 2]
+}
+set res [one_local_exec $commandline $inp $outp $timeout]
+set stat [lindex $res 0]
+if { $stat == -2 } {
+   set msg "" 
+   warning "TIMED OUT: $commandline timed out after retry"
+   verbose -log "TIMED OUT: $commandline (timeout = $timeout)"
+}
+return $res
+}
+
 #
 # Execute the supplied program on HOSTNAME. There are four optional arguments
 # the first is a set of arguments to pass to PROGRAM, the second is an
@@ -1090,7 +1120,8 @@
}
}
timeout {
-   warning "program timed out."
+   warning "standard_wait: program timed out"
+   set status -2 
}
eof {
if [board_info $dest exists fileid_origid] {

Re: [PATCH, PR43864] Gimple level duplicate block cleanup.

[Richard Guenther]

On Wed, Jun 8, 2011 at 11:42 AM, Tom de Vries  wrote:
> Hi Richard,
>
> I have a patch for PR43864. The patch adds a gimple level duplicate block
> cleanup. The patch has been bootstrapped and reg-tested on x86_64, and
> reg-tested on ARM. The size impact on ARM for spec2000 is shown in the 
> following
> table (%, lower is better).
>
>                     none            pic
>                thumb1  thumb2  thumb1 thumb2
> spec2000          99.9    99.9    99.8   99.8
>
> PR43864 is currently marked as a duplicate of PR20070, but I'm not sure that 
> the
> optimizations proposed in PR20070 would fix this PR.
>
> The problem in this PR is that when compiling with -O2, the example below 
> should
> only have one call to free. The original problem is formulated in terms of 
> -Os,
> but currently we generate one call to free with -Os, although still not the
> smallest code possible. I'll show here the -O2 case, since that's similar to 
> the
> original PR.
>
> #include 
> void foo (char*, FILE*);
> char* hprofStartupp(char *outputFileName, char *ctx)
> {
>    char fileName[1000];
>    FILE *fp;
>    sprintf(fileName, outputFileName);
>    if (access(fileName, 1) == 0) {
>        free(ctx);
>        return 0;
>    }
>
>    fp = fopen(fileName, 0);
>    if (fp == 0) {
>        free(ctx);
>        return 0;
>    }
>
>    foo(outputFileName, fp);
>
>    return ctx;
> }
>
> AFAIU, there are 2 complementary methods of rtl optimizations proposed in 
> PR20070.
> - Merging 2 blocks which are identical expect for input registers, by using a
>  conditional move to choose between the different input registers.
> - Merging 2 blocks which have different local registers, by ignoring those
>  differences
>
> Blocks .L6 and.L7 have no difference in local registers, but they have a
> difference in input registers: r3 and r1. Replacing the move to r5 by a
> conditional move would probably be benificial in terms of size, but it's not
> clear what condition the conditional move should be using. Calculating such a
> condition would add in size and increase the execution path.
>
> gcc -O2 -march=armv7-a -mthumb pr43864.c -S:
> ...
>        push    {r4, r5, lr}
>        mov     r4, r0
>        sub     sp, sp, #1004
>        mov     r5, r1
>        mov     r0, sp
>        mov     r1, r4
>        bl      sprintf
>        mov     r0, sp
>        movs    r1, #1
>        bl      access
>        mov     r3, r0
>        cbz     r0, .L6
>        movs    r1, #0
>        mov     r0, sp
>        bl      fopen
>        mov     r1, r0
>        cbz     r0, .L7
>        mov     r0, r4
>        bl      foo
> .L3:
>        mov     r0, r5
>        add     sp, sp, #1004
>        pop     {r4, r5, pc}
> .L6:
>        mov     r0, r5
>        mov     r5, r3
>        bl      free
>        b       .L3
> .L7:
>        mov     r0, r5
>        mov     r5, r1
>        bl      free
>        b       .L3
> ...
>
> The proposed patch solved the problem by dealing with the 2 blocks at a level
> when they are still identical: at gimple level. It detect that the 2 blocks 
> are
> identical, and removes one of them.
>
> The following table shows the impact of the patch on the example in terms of
> size for -march=armv7-a:
>
>          without     with    delta
> Os      :     108      104       -4
> O2      :     120      104      -16
> Os thumb:      68       64       -4
> O2 thumb:      76       64      -12
>
> The gain in size for -O2 is that of removing the entire block, plus the
> replacement of 2 moves by a constant set, which also decreases the execution
> path. The patch ensures optimal code for both -O2 and -Os.
>
>
> By keeping track of equivalent definitions in the 2 blocks, we can ignore 
> those
> differences in comparison. Without this feature, we would only match blocks 
> with
> resultless operations, due the the ssa-nature of gimples.
> For example, with this feature, we reduce the following function to its 
> minimum
> at gimple level, rather than at rtl level.
>
> int f(int c, int b, int d)
> {
>  int r, e;
>
>  if (c)
>    r = b + d;
>  else
>    {
>      e = b + d;
>      r = e;
>    }
>
>  return r;
> }
>
> ;; Function f (f)
>
> f (int c, int b, int d)
> {
>  int e;
>
> :
>  e_6 = b_3(D) + d_4(D);
>  return e_6;
>
> }
>
> I'll send the patch with the testcases in a separate email.
>
> OK for trunk?

I don't like that you hook this into cleanup_tree_cfg - that is called
_way_ too often.

This also duplicates the literal matching done on the RTL level - instead
I think this optimization would be more related to value-numbering
(either that of SCCVN/FRE/PRE or that of DOM which also does
jump-threading).

Richard.

> Thanks,
> - Tom
>
> 2011-06-08  Tom de Vries  
>
>        PR middle-end/43864
>        * tree-cfgcleanup.c (int_int_splay_lookup, int_int_splay_insert)
>        (int_int_splay_node_contained_in, int_int_splay_contained_in)
>        (equiv_lookup, equiv_insert, equiv_contained_in, equiv_init)
>        (equiv_delete, gimple_base_equal_p,

[PATCH] better warning for section conflict

[Andi Kleen]

When erroring on a section type conflict print both locations.
This makes it a lot easier to track them down, especially in LTO.

This is still not quite good before it prints only one
conflict pair currently instead of all, but at least all
the problems can be fixed iteratively now.

Better would be likely to have a majority vote and print
everyone disagreeing.

Passes bootstrap & test suite on x86_64-linux. Ok to commit?

2011-06-06  Andi Kleen  

* varasm.c (get_section): Print location of other conflict
for section conflicts.
---
 gcc/varasm.c |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/gcc/varasm.c b/gcc/varasm.c
index f46c21b..5f4f796 100644
--- a/gcc/varasm.c
+++ b/gcc/varasm.c
@@ -313,7 +313,11 @@ get_section (const char *name, unsigned int flags, tree 
decl)
  if (decl == 0)
decl = sect->named.decl;
  gcc_assert (decl);
- error ("%+D causes a section type conflict", decl);
+ error ("%+D causes a section type conflict with %D", 
+   decl, sect->named.decl);
+ if (decl != sect->named.decl)
+inform (DECL_SOURCE_LOCATION (sect->named.decl), 
+   "%qD was declared here", sect->named.decl);
  /* Make sure we don't error about one section multiple times.  */
  sect->common.flags |= SECTION_OVERRIDE;
}
-- 
1.7.5.3

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

[PATCH] add another sandy bridge model number

[Andi Kleen]

Add another sandy bridge model number.

Passes bootstrap & test suite on x86_64-linux. Ok for trunk and 
4.6?

2011-06-6  Andi Kleen  

* config/i386/driver-i386.c (host_detect_local_cpu):
Add model 0x2d Intel CPU.
---
 gcc/config/i386/driver-i386.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/gcc/config/i386/driver-i386.c b/gcc/config/i386/driver-i386.c
index 4fc6b45..98cd6f6 100644
--- a/gcc/config/i386/driver-i386.c
+++ b/gcc/config/i386/driver-i386.c
@@ -572,6 +572,7 @@ const char *host_detect_local_cpu (int argc, const char 
**argv)
  cpu = "corei7";
  break;
case 0x2a:
+   case 0x2d:
  /* Sandy Bridge.  */
  cpu = "corei7-avx";
  break;
-- 
1.7.5.3

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

[PATCH] Print location for conflicting global regs in warning

[Andi Kleen]

Print location for conflicting global regs when warning
about them. Otherwise it's hard to track down where they are.

To review: I hope the way I use the garbage collector for the global
variable is ok?

Passes bootstrap & test suite on x86_64-linux. Ok to commit?

2011-06-06  Andi Kleen  

* reginfo.c (global_regs_decl): Add.
(globalize_reg): Add decl parameter. Compute location.
Pass location to warnings and add inform. Store decl
in global_regs_decl.
* rtl.h (globalize_reg): Update prototype.
* varasm.c (make_decl_rtl): Pass decl to globalize_reg().
---
 gcc/reginfo.c |   18 ++
 gcc/rtl.h |2 +-
 gcc/varasm.c  |2 +-
 3 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/gcc/reginfo.c b/gcc/reginfo.c
index a283a90..1da4cb8 100644
--- a/gcc/reginfo.c
+++ b/gcc/reginfo.c
@@ -87,6 +87,9 @@ static const char initial_call_really_used_regs[] = 
CALL_REALLY_USED_REGISTERS;
and are also considered fixed.  */
 char global_regs[FIRST_PSEUDO_REGISTER];
 
+/* Declaration for the global register. */
+static tree GTY(()) global_regs_decl[FIRST_PSEUDO_REGISTER];
+
 /* Same information as REGS_INVALIDATED_BY_CALL but in regset form to be used
in dataflow more conveniently.  */
 regset regs_invalidated_by_call_regset;
@@ -825,8 +828,10 @@ fix_register (const char *name, int fixed, int call_used)
 
 /* Mark register number I as global.  */
 void
-globalize_reg (int i)
+globalize_reg (tree decl, int i)
 {
+  location_t loc = DECL_SOURCE_LOCATION (decl);
+
 #ifdef STACK_REGS
   if (IN_RANGE (i, FIRST_STACK_REG, LAST_STACK_REG))
 {
@@ -836,18 +841,23 @@ globalize_reg (int i)
 #endif
 
   if (fixed_regs[i] == 0 && no_global_reg_vars)
-error ("global register variable follows a function definition");
+error_at (loc, "global register variable follows a function definition");
 
   if (global_regs[i])
 {
-  warning (0, "register used for two global register variables");
+  warning_at (loc, 0, 
+ "register of %qD used for multiple global register variables",
+ decl);
+  inform (DECL_SOURCE_LOCATION (global_regs_decl[i]),
+ "conflicts with %qD", global_regs_decl[i]); 
   return;
 }
 
   if (call_used_regs[i] && ! fixed_regs[i])
-warning (0, "call-clobbered register used for global register variable");
+warning_at (loc, 0, "call-clobbered register used for global register 
variable");
 
   global_regs[i] = 1;
+  global_regs_decl[i] = decl;
 
   /* If we're globalizing the frame pointer, we need to set the
  appropriate regs_invalidated_by_call bit, even if it's already
diff --git a/gcc/rtl.h b/gcc/rtl.h
index 62b677a..f2c2983 100644
--- a/gcc/rtl.h
+++ b/gcc/rtl.h
@@ -2451,7 +2451,7 @@ extern void mark_elimination (int, int);
 /* In reginfo.c */
 extern int reg_classes_intersect_p (reg_class_t, reg_class_t);
 extern int reg_class_subset_p (reg_class_t, reg_class_t);
-extern void globalize_reg (int);
+extern void globalize_reg (tree, int);
 extern void init_reg_modes_target (void);
 extern void init_regs (void);
 extern void reinit_regs (void);
diff --git a/gcc/varasm.c b/gcc/varasm.c
index 5f4f796..a0a0582 100644
--- a/gcc/varasm.c
+++ b/gcc/varasm.c
@@ -1241,7 +1241,7 @@ make_decl_rtl (tree decl)
 #endif
  nregs = hard_regno_nregs[reg_number][DECL_MODE (decl)];
  while (nregs > 0)
-   globalize_reg (reg_number + --nregs);
+   globalize_reg (decl, reg_number + --nregs);
}
 
  /* As a register variable, it has no section.  */
-- 
1.7.5.3

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

Re: [testsuite] skip ARM neon-fp16 tests for other -mcpu values

[Joseph S. Myers]

On Tue, 7 Jun 2011, Janis Johnson wrote:

> These tests fail when multilib options use -mfpu= and override the
> -mfpu=neon-fp16 used for the test:
> 
>   g++.dg/ext/arm-fp16/arm-fp16-ops-5.C
>   g++.dg/ext/arm-fp16/arm-fp16-ops-6.C
>   gcc.dg/torture/arm-fp16-ops-5.c
>   gcc.dg/torture/arm-fp16-ops-6.c
>   gcc.target/arm/fp16-compile-vcvt.c
> 
> The option -mfpu-neon-fp16 is added via "dg-add-options arm_neon_fp16"
> after an earlier "dg-require-effective-target arm_neon_fp16_ok".
> This patch modifies check_effective_target_arm_neon_fp16_ok_nocache to
> return 0 (causing the test to be skipped) if multilib flags include
> -mfpu= with a value other than neon-fp16.

But I'd think they ought to work with any -mfpu= option supporting 
half-precision instructions - that is, vfpv3-fp16, vfpv3-d16-fp16, 
vfpv3xd-fp16, neon-fp16, vfpv4, vfpv4-d16, fpv4-sp-d16, neon-vfpv4 
(anything with "true" in the last field in arm-fpus.def; for the 
testsuite, you can probably suppose anything -mfpu=*fp16*, 
-mfpu=*fpv[4-9]*, -mfpu=*fpv[1-9][0-9]*).

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

Re: [PATCH] better warning for section conflict

[Richard Guenther]

On Wed, Jun 8, 2011 at 12:07 PM, Andi Kleen  wrote:
> When erroring on a section type conflict print both locations.
> This makes it a lot easier to track them down, especially in LTO.
>
> This is still not quite good before it prints only one
> conflict pair currently instead of all, but at least all
> the problems can be fixed iteratively now.
>
> Better would be likely to have a majority vote and print
> everyone disagreeing.
>
> Passes bootstrap & test suite on x86_64-linux. Ok to commit?

Ok.

Thanks,
Richard.

> 2011-06-06  Andi Kleen  
>
>        * varasm.c (get_section): Print location of other conflict
>        for section conflicts.
> ---
>  gcc/varasm.c |    6 +-
>  1 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/gcc/varasm.c b/gcc/varasm.c
> index f46c21b..5f4f796 100644
> --- a/gcc/varasm.c
> +++ b/gcc/varasm.c
> @@ -313,7 +313,11 @@ get_section (const char *name, unsigned int flags, tree 
> decl)
>          if (decl == 0)
>            decl = sect->named.decl;
>          gcc_assert (decl);
> -         error ("%+D causes a section type conflict", decl);
> +         error ("%+D causes a section type conflict with %D",
> +                       decl, sect->named.decl);
> +         if (decl != sect->named.decl)
> +            inform (DECL_SOURCE_LOCATION (sect->named.decl),
> +                   "%qD was declared here", sect->named.decl);
>          /* Make sure we don't error about one section multiple times.  */
>          sect->common.flags |= SECTION_OVERRIDE;
>        }
> --
> 1.7.5.3
>
> --
> a...@linux.intel.com -- Speaking for myself only.
>

Re: [PATCH] Print location for conflicting global regs in warning

[Richard Guenther]

On Wed, Jun 8, 2011 at 12:11 PM, Andi Kleen  wrote:
> Print location for conflicting global regs when warning
> about them. Otherwise it's hard to track down where they are.
>
> To review: I hope the way I use the garbage collector for the global
> variable is ok?
>
> Passes bootstrap & test suite on x86_64-linux. Ok to commit?

Ok.

Thanks,
Richard.

> 2011-06-06  Andi Kleen  
>
>        * reginfo.c (global_regs_decl): Add.
>        (globalize_reg): Add decl parameter. Compute location.
>        Pass location to warnings and add inform. Store decl
>        in global_regs_decl.
>        * rtl.h (globalize_reg): Update prototype.
>        * varasm.c (make_decl_rtl): Pass decl to globalize_reg().
> ---
>  gcc/reginfo.c |   18 ++
>  gcc/rtl.h     |    2 +-
>  gcc/varasm.c  |    2 +-
>  3 files changed, 16 insertions(+), 6 deletions(-)
>
> diff --git a/gcc/reginfo.c b/gcc/reginfo.c
> index a283a90..1da4cb8 100644
> --- a/gcc/reginfo.c
> +++ b/gcc/reginfo.c
> @@ -87,6 +87,9 @@ static const char initial_call_really_used_regs[] = 
> CALL_REALLY_USED_REGISTERS;
>    and are also considered fixed.  */
>  char global_regs[FIRST_PSEUDO_REGISTER];
>
> +/* Declaration for the global register. */
> +static tree GTY(()) global_regs_decl[FIRST_PSEUDO_REGISTER];
> +
>  /* Same information as REGS_INVALIDATED_BY_CALL but in regset form to be used
>    in dataflow more conveniently.  */
>  regset regs_invalidated_by_call_regset;
> @@ -825,8 +828,10 @@ fix_register (const char *name, int fixed, int call_used)
>
>  /* Mark register number I as global.  */
>  void
> -globalize_reg (int i)
> +globalize_reg (tree decl, int i)
>  {
> +  location_t loc = DECL_SOURCE_LOCATION (decl);
> +
>  #ifdef STACK_REGS
>   if (IN_RANGE (i, FIRST_STACK_REG, LAST_STACK_REG))
>     {
> @@ -836,18 +841,23 @@ globalize_reg (int i)
>  #endif
>
>   if (fixed_regs[i] == 0 && no_global_reg_vars)
> -    error ("global register variable follows a function definition");
> +    error_at (loc, "global register variable follows a function definition");
>
>   if (global_regs[i])
>     {
> -      warning (0, "register used for two global register variables");
> +      warning_at (loc, 0,
> +                 "register of %qD used for multiple global register 
> variables",
> +                 decl);
> +      inform (DECL_SOURCE_LOCATION (global_regs_decl[i]),
> +             "conflicts with %qD", global_regs_decl[i]);
>       return;
>     }
>
>   if (call_used_regs[i] && ! fixed_regs[i])
> -    warning (0, "call-clobbered register used for global register variable");
> +    warning_at (loc, 0, "call-clobbered register used for global register 
> variable");
>
>   global_regs[i] = 1;
> +  global_regs_decl[i] = decl;
>
>   /* If we're globalizing the frame pointer, we need to set the
>      appropriate regs_invalidated_by_call bit, even if it's already
> diff --git a/gcc/rtl.h b/gcc/rtl.h
> index 62b677a..f2c2983 100644
> --- a/gcc/rtl.h
> +++ b/gcc/rtl.h
> @@ -2451,7 +2451,7 @@ extern void mark_elimination (int, int);
>  /* In reginfo.c */
>  extern int reg_classes_intersect_p (reg_class_t, reg_class_t);
>  extern int reg_class_subset_p (reg_class_t, reg_class_t);
> -extern void globalize_reg (int);
> +extern void globalize_reg (tree, int);
>  extern void init_reg_modes_target (void);
>  extern void init_regs (void);
>  extern void reinit_regs (void);
> diff --git a/gcc/varasm.c b/gcc/varasm.c
> index 5f4f796..a0a0582 100644
> --- a/gcc/varasm.c
> +++ b/gcc/varasm.c
> @@ -1241,7 +1241,7 @@ make_decl_rtl (tree decl)
>  #endif
>              nregs = hard_regno_nregs[reg_number][DECL_MODE (decl)];
>              while (nregs > 0)
> -               globalize_reg (reg_number + --nregs);
> +               globalize_reg (decl, reg_number + --nregs);
>            }
>
>          /* As a register variable, it has no section.  */
> --
> 1.7.5.3
>
> --
> a...@linux.intel.com -- Speaking for myself only.
>

Re: [PATCH, PR43864] Gimple level duplicate block cleanup.

[Steven Bosscher]

On Wed, Jun 8, 2011 at 11:55 AM, Richard Guenther
 wrote:
> On Wed, Jun 8, 2011 at 11:42 AM, Tom de Vries  wrote:
>> Hi Richard,
>>
>> I have a patch for PR43864. The patch adds a gimple level duplicate block
>> cleanup. The patch has been bootstrapped and reg-tested on x86_64, and
>> reg-tested on ARM. The size impact on ARM for spec2000 is shown in the 
>> following
>> table (%, lower is better).
>>
>>                     none            pic
>>                thumb1  thumb2  thumb1 thumb2
>> spec2000          99.9    99.9    99.8   99.8
>>
>> PR43864 is currently marked as a duplicate of PR20070, but I'm not sure that 
>> the
>> optimizations proposed in PR20070 would fix this PR.
>>
>> The problem in this PR is that when compiling with -O2, the example below 
>> should
>> only have one call to free. The original problem is formulated in terms of 
>> -Os,
>> but currently we generate one call to free with -Os, although still not the
>> smallest code possible. I'll show here the -O2 case, since that's similar to 
>> the
>> original PR.
>>
>> #include 
>> void foo (char*, FILE*);
>> char* hprofStartupp(char *outputFileName, char *ctx)
>> {
>>    char fileName[1000];
>>    FILE *fp;
>>    sprintf(fileName, outputFileName);
>>    if (access(fileName, 1) == 0) {
>>        free(ctx);
>>        return 0;
>>    }
>>
>>    fp = fopen(fileName, 0);
>>    if (fp == 0) {
>>        free(ctx);
>>        return 0;
>>    }
>>
>>    foo(outputFileName, fp);
>>
>>    return ctx;
>> }
>>
>> AFAIU, there are 2 complementary methods of rtl optimizations proposed in 
>> PR20070.
>> - Merging 2 blocks which are identical expect for input registers, by using a
>>  conditional move to choose between the different input registers.
>> - Merging 2 blocks which have different local registers, by ignoring those
>>  differences
>>
>> Blocks .L6 and.L7 have no difference in local registers, but they have a
>> difference in input registers: r3 and r1. Replacing the move to r5 by a
>> conditional move would probably be benificial in terms of size, but it's not
>> clear what condition the conditional move should be using. Calculating such a
>> condition would add in size and increase the execution path.
>>
>> gcc -O2 -march=armv7-a -mthumb pr43864.c -S:
>> ...
>>        push    {r4, r5, lr}
>>        mov     r4, r0
>>        sub     sp, sp, #1004
>>        mov     r5, r1
>>        mov     r0, sp
>>        mov     r1, r4
>>        bl      sprintf
>>        mov     r0, sp
>>        movs    r1, #1
>>        bl      access
>>        mov     r3, r0
>>        cbz     r0, .L6
>>        movs    r1, #0
>>        mov     r0, sp
>>        bl      fopen
>>        mov     r1, r0
>>        cbz     r0, .L7
>>        mov     r0, r4
>>        bl      foo
>> .L3:
>>        mov     r0, r5
>>        add     sp, sp, #1004
>>        pop     {r4, r5, pc}
>> .L6:
>>        mov     r0, r5
>>        mov     r5, r3
>>        bl      free
>>        b       .L3
>> .L7:
>>        mov     r0, r5
>>        mov     r5, r1
>>        bl      free
>>        b       .L3
>> ...
>>
>> The proposed patch solved the problem by dealing with the 2 blocks at a level
>> when they are still identical: at gimple level. It detect that the 2 blocks 
>> are
>> identical, and removes one of them.
>>
>> The following table shows the impact of the patch on the example in terms of
>> size for -march=armv7-a:
>>
>>          without     with    delta
>> Os      :     108      104       -4
>> O2      :     120      104      -16
>> Os thumb:      68       64       -4
>> O2 thumb:      76       64      -12
>>
>> The gain in size for -O2 is that of removing the entire block, plus the
>> replacement of 2 moves by a constant set, which also decreases the execution
>> path. The patch ensures optimal code for both -O2 and -Os.
>>
>>
>> By keeping track of equivalent definitions in the 2 blocks, we can ignore 
>> those
>> differences in comparison. Without this feature, we would only match blocks 
>> with
>> resultless operations, due the the ssa-nature of gimples.
>> For example, with this feature, we reduce the following function to its 
>> minimum
>> at gimple level, rather than at rtl level.
>>
>> int f(int c, int b, int d)
>> {
>>  int r, e;
>>
>>  if (c)
>>    r = b + d;
>>  else
>>    {
>>      e = b + d;
>>      r = e;
>>    }
>>
>>  return r;
>> }
>>
>> ;; Function f (f)
>>
>> f (int c, int b, int d)
>> {
>>  int e;
>>
>> :
>>  e_6 = b_3(D) + d_4(D);
>>  return e_6;
>>
>> }
>>
>> I'll send the patch with the testcases in a separate email.
>>
>> OK for trunk?
>
> I don't like that you hook this into cleanup_tree_cfg - that is called
> _way_ too often.
>
> This also duplicates the literal matching done on the RTL level - instead
> I think this optimization would be more related to value-numbering
> (either that of SCCVN/FRE/PRE or that of DOM which also does
> jump-threading).

And while at it: Put it in a separate file ;-)

Ciao!
Steven

Re: [pph] Stream TREE_TYPE for identifier node (issue4550121)

[Steven Bosscher]

On Tue, Jun 7, 2011 at 11:50 PM, Diego Novillo  wrote:
> On Tue, Jun 7, 2011 at 14:12, Steven Bosscher  wrote:
>> On Tue, Jun 7, 2011 at 8:44 PM, Gabriel Charette  wrote:
>>> We need to stream TREE_TYPE for identifier node.
>>
>> That seems unlikely, as identifiers do not have a type. There is some
>> TREE_TYPE abuse in cp-tree.h, perhaps you should find out what you're
>> streaming.
>
> It's used by the C++ parser, so it needs to be streamed in pph.

Yes, but you should not stream TREE_TYPE but use the accessor macro
that uses TREE_TYPE. Otherwise, if someone gets around to making
IDENTIFIER nodes non-typed trees (and update cp-tree.h accordingly)
the streaming will break.

Ciao!
Steven

Re: [testsuite] skip ARM tests with conflicting options

[Richard Earnshaw]

On 08/06/11 03:14, Janis Johnson wrote:
> On 06/07/2011 06:25 PM, Mike Stump wrote:
>> On Jun 7, 2011, at 4:24 PM, Janis Johnson wrote:
>>> On 06/07/2011 02:07 PM, Joseph S. Myers wrote:
 On Tue, 7 Jun 2011, Janis Johnson wrote:

> Several tests in gcc.target/arm use dg-options with -mcpu=, which
> causes compiler warnings or errors when the multilib flags include
> -march=.  This patch causes those tests to be skipped.  It also
> prevents gcc.target/arm/20090811-1.c from running with multilibs that
> would override -mcpu or -mfloat-abi options specified for the test.

 I think you should allow compatible -march options - for example, if 
 dg-options has -mcpu=cortex-a8, allow -march=armv7-a but disallow all 
 other -march options.

>>> Is this one OK?
>>
>> Not sure if the arm people want to review this or would rather I review it...
>>
>> Let's give the arm folks a couple days to comment, if no objections, Ok.
>>
>> A point of warning, eventually, you'll discover that when a compiler 
>> defaults to the argument you want to skip, that you'll needs slightly more 
>> power to skip them.  darwin ran into this with things like -m64, and 
>> eventually had to do something like lp64.  configure options like 
>> --with-cpu=arm9 are the sort that can change the default.
> 
> Yes, I hope to hear from ARM people.
> 
> On ARM, the default from --with-cpu= is overridden by -march at
> compile so it's not a problem for this particular set of tests.
> As I said originally, this set is the tip of the iceberg and they
> get more difficult.
> 
> Janis
> 
> 


I'm worried by this whole approach of command-line checking.  It works,
just about, for testsuite variations set with target_list, but it won't
work with options used to configure the compiler (eg --with-mode=thumb,
or --with-cpu=...).  Perhaps a better approach would be a new dg- test
that built a trivial file with all the options and disabled the test if
that test failed for any reason.  Something like:

dg-target-compatible (target, , additional-opts)

The test is only performed if target matches the current target.

I'm not sure if this is something that can be easily cached (well, it
might be possible if you could index off additional-opts and the default
opts), so it might be that this test has to be re-run every time there
is a test that needs it.

R.

Re: [PATH] PR/49139 fix always_inline failures diagnostics

[Christian Bruel]

On 06/08/2011 11:11 AM, Richard Guenther wrote:

On Wed, Jun 8, 2011 at 9:46 AM, Christian Bruel  wrote:

Hello Richard,

On 06/06/2011 11:55 AM, Richard Guenther wrote:


On Mon, Jun 6, 2011 at 10:58 AM, Christian Bruel
  wrote:




OK, the only difference is that we don't have the node analyzed here,
so
externally_visible, etc are not set. With the initial proposal the
warning
was emitted only if the function could not be inlined. Now it will be
emitted for each  DECL_COMDAT (decl)&&  !DECL_DECLARED_INLINE_P
(decl))
even
if not preemptible, so conservatively we don't want to duplicate the
availability check.


Hm, I'm confused.  Do all DECL_COMDAT functions have the
always_inline attribute set?  I would have expected

+  if (lookup_attribute ("always_inline", DECL_ATTRIBUTES (decl)))
+   {
+ if (!DECL_DECLARED_INLINE_P (decl))
+   warning (OPT_Wattributes,
+"always_inline not declared inline might not be
inlinable");
+   }



I meant !DECL_COMDAT || !DECL_DECLARED_INLINE_P. but I was
overprecautious.
Didn't realize that member functions was already marked with
DECLARED_INLINED_P even if not explicitly set. So OK one check is enough


do you get excessive warnings with this?



No I don't. That's enough to catch the original issue




Unfortunately still not satisfactory, I've been testing it against a few
packages, and I notice excessive warnings with the use of __typeof (__error)
that doesn't propagate the inline keyword.

For instance, a reduced use extracted from the glibc

extern __inline __attribute__ ((__always_inline__))  void
error ()
{

}

extern void
__error ()
{
}

extern __typeof (__error) error __attribute__ ((weak, alias ("__error")));

emits an annoying warning on the error redefinition.

So, a check in addition of the DECL_DECLARED_INLINED_P is needed,
TREE_ADDRESSABLE seems appropriate, since in the case of missing inline the
function would be emitted. So I'm testing:

if (lookup_attribute ("always_inline", DECL_ATTRIBUTES (decl))
  &&  !DECL_DECLARED_INLINE_P (decl)
  &&  TREE_ADDRESSABLE (decl))

other idea ? or should be just drop this warning ?


Hmm.  Honza, any idea on the above?  Christian, I suppose you
could check if the cgraph node for that decl has the redefined_extern_inline
flag set (checking TREE_ADDRESSABLE looks bogus to me).
I'm not sure how the frontend merges those two decls - I suppose
it will have a weak always-inline function with body :/



ooops, yes, TREE_ADDRESSABLE was in 4.5 :
   "In a FUNCTION_DECL, nonzero means its address is needed.
   So it must be compiled even if it is an inline function."
but indeed in 4.6 and above is is:
   "In a FUNCTION_DECL it has no meaning."

so can't use TREE_ADDRESSABLE, (I'm also patching the 4.5 locally). I'll 
check if redefined_extern_value does the job.


thanks

Christian


Richard.


Ok.  The patch is ok with the !DECL_DECLARED_INLINE_P check
if it still passes bootstrap®test.



thanks, for now I postpone until glibc is ok and more legacy checks.

Cheers

Christian


Thanks,
Richard.


Cheers

Christian

[testsuite] Build tmpdir-gcc.dg-struct-layout-1 tests with -fno-common on Tru64 UNIX (PR middle-end/21953)

[Rainer Orth]

Looking at the remaining Tru64 UNIX testsuite failures, I noticed that
the gcc.dg/compat/struct-layout-1.exp tests are built with -fno-common
on PA HP-UX.  Since Alpha Tru64 UNIX is often similar, I tried this and
in fact most of the failures are gone.  The single one in
g++.dg/compat/struct-layout-1.exp is unaffected, but I changed that
along the same line for consistency.

Tested with the appropriate runtest invocations, installed on mainline.

There are only 4 remaining failures now:

FAIL: tmpdir-g++.dg-struct-layout-1/t027 cp_compat_x_tst.o-cp_compat_y_tst.o 
execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t025 c_compat_x_tst.o-c_compat_y_tst.o 
execute 
FAIL: tmpdir-gcc.dg-struct-layout-1/t027 c_compat_x_tst.o-c_compat_y_tst.o 
execute 
FAIL: tmpdir-gcc.dg-struct-layout-1/t028 c_compat_x_tst.o-c_compat_y_tst.o 
execute 

As an example, I had a look at tmpdir-gcc.dg-struct-layout-1/t025:
compiled with -DDBG, the first failure is

fail 2210.1

with 17 more (all N.1): the failure is like this:

typedef int __attribute__((mode(HI))) hi;
typedef hi __attribute__((vector_size (32))) v16hi;
struct S2210 { v16hi a; };
struct S2210 s2210;
extern struct S2210 a2210[5];
info.als = __alignof__ (s2210);
if (((long) &a2210[3]) & (info.als - 1)) printf ("fail %d.%d\n", 2210, 1), 
++fails;

info.als is 32, ((long) &a2210[3]) & (info.als - 1) is 16; it seems the
alignment of vector types is inconsistent here.

Rainer


2011-06-07  Rainer Orth  

PR middle-end/21953
* gcc.dg/compat/struct-layout-1_generate.c (dg-options): Use
-fno-common on alpha*-dec-osf*.
* g++.dg/compat/struct-layout-1_generate.c (dg-options): Likewise.

diff --git a/gcc/testsuite/g++.dg/compat/struct-layout-1_generate.c 
b/gcc/testsuite/g++.dg/compat/struct-layout-1_generate.c
--- a/gcc/testsuite/g++.dg/compat/struct-layout-1_generate.c
+++ b/gcc/testsuite/g++.dg/compat/struct-layout-1_generate.c
@@ -1,5 +1,6 @@
 /* Structure layout test generator.
-   Copyright (C) 2004, 2005, 2007, 2008, 2009 Free Software Foundation, Inc.
+   Copyright (C) 2004, 2005, 2007, 2008, 2009, 2011
+   Free Software Foundation, Inc.
Contributed by Jakub Jelinek .
 
 This file is part of GCC.
@@ -45,7 +46,7 @@ along with GCC; see the file COPYING3.  
 const char *dg_options[] = {
 "/* { dg-options \"%s-I%s\" } */\n",
 "/* { dg-options \"%s-I%s -mno-mmx -Wno-abi\" { target i?86-*-* x86_64-*-* } } 
*/\n",
-"/* { dg-options \"%s-I%s -fno-common\" { target hppa*-*-hpux* 
powerpc*-*-darwin* *-*-mingw32* *-*-cygwin* } } */\n",
+"/* { dg-options \"%s-I%s -fno-common\" { target alpha*-dec-osf* hppa*-*-hpux* 
powerpc*-*-darwin* *-*-mingw32* *-*-cygwin* } } */\n",
 "/* { dg-options \"%s-I%s -mno-mmx -fno-common -Wno-abi\" { target 
i?86-*-darwin* x86_64-*-darwin* } } */\n",
 "/* { dg-options \"%s-I%s -mno-base-addresses\" { target mmix-*-* } } */\n",
 "/* { dg-options \"%s-I%s -mlongcalls -mtext-section-literals\" { target 
xtensa*-*-* } } */\n"
diff --git a/gcc/testsuite/gcc.dg/compat/struct-layout-1_generate.c 
b/gcc/testsuite/gcc.dg/compat/struct-layout-1_generate.c
--- a/gcc/testsuite/gcc.dg/compat/struct-layout-1_generate.c
+++ b/gcc/testsuite/gcc.dg/compat/struct-layout-1_generate.c
@@ -1,5 +1,6 @@
 /* Structure layout test generator.
-   Copyright (C) 2004, 2005, 2007, 2008, 2009 Free Software Foundation, Inc.
+   Copyright (C) 2004, 2005, 2007, 2008, 2009, 2011
+   Free Software Foundation, Inc.
Contributed by Jakub Jelinek .
 
 This file is part of GCC.
@@ -46,7 +47,7 @@ const char *dg_options[] = {
 "/* { dg-options \"%s-I%s\" } */\n",
 "/* { dg-options \"%s-I%s -Wno-abi\" } */\n",
 "/* { dg-options \"%s-I%s -mno-mmx -Wno-abi\" { target i?86-*-* x86_64-*-* } } 
*/\n",
-"/* { dg-options \"%s-I%s -fno-common\" { target hppa*-*-hpux* 
powerpc*-*-darwin* } } */\n",
+"/* { dg-options \"%s-I%s -fno-common\" { target alpha*-dec-osf* hppa*-*-hpux* 
powerpc*-*-darwin* } } */\n",
 "/* { dg-options \"%s-I%s -mno-mmx -fno-common -Wno-abi\" { target 
i?86-*-darwin* x86_64-*-darwin* } } */\n",
 "/* { dg-options \"%s-I%s -mno-base-addresses\" { target mmix-*-* } } */\n",
 "/* { dg-options \"%s-I%s -mlongcalls -mtext-section-literals\" { target 
xtensa*-*-* } } */\n"


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

Re: Libiberty: POSIXify psignal definition

[Hans-Peter Nilsson]

On Thu, 26 May 2011, DJ Delorie wrote:
>
> > Yes please.  I've been arguing for that for some time.
>
> Since you feel so strongly about it and nobody objects, go ahead.

Backport to open branches?  (And note PR48825.)

brgds, H-P

[v3] Avoid including the whole in a couple of places + small fix to std::duration_values

[Paolo Carlini]

Hi,

tested x86_64-linux, committed.

Paolo.

///
2011-06-08  Paolo Carlini  

* include/ext/extptr_allocator.h: Include 
instead of .
* include/bits/allocator.h: Likewise.

* include/std/chrono (duration_values<>::min): Call lowest, not min.
Index: include/std/chrono
===
--- include/std/chrono  (revision 174804)
+++ include/std/chrono  (working copy)
@@ -203,7 +203,7 @@
 
static constexpr _Rep
min()
-   { return numeric_limits<_Rep>::min(); }
+   { return numeric_limits<_Rep>::lowest(); }
   };
 
 template
Index: include/ext/extptr_allocator.h
===
--- include/ext/extptr_allocator.h  (revision 174804)
+++ include/ext/extptr_allocator.h  (working copy)
@@ -1,6 +1,6 @@
 //  -*- C++ -*-
 
-// Copyright (C) 2008, 2009, 2010 Free Software Foundation, Inc.
+// Copyright (C) 2008, 2009, 2010, 2011 Free Software Foundation, Inc.
 //
 // This file is part of the GNU ISO C++ Library.  This library is free
 // software; you can redistribute it and/or modify it under the
@@ -37,7 +37,7 @@
 #define _EXTPTR_ALLOCATOR_H 1
 
 #include 
-#include 
+#include 
 #include 
 
 namespace __gnu_cxx _GLIBCXX_VISIBILITY(default)
@@ -98,7 +98,7 @@
   { _M_real_alloc.deallocate(__p.get(), __n); }
 
   size_type max_size() const throw()
-  { return std::numeric_limits::max() / sizeof(_Tp); }
+  { return __numeric_traits::__max / sizeof(_Tp); }
 
 #ifdef __GXX_EXPERIMENTAL_CXX0X__
   template
@@ -111,6 +111,7 @@
 destroy(_Up* __p)
 { __p->~_Up(); }
 #else
+
   void construct(pointer __p, const _Tp& __val)
   { ::new(__p.get()) _Tp(__val); }
 
Index: include/bits/allocator.h
===
--- include/bits/allocator.h(revision 174804)
+++ include/bits/allocator.h(working copy)
@@ -50,7 +50,7 @@
 #ifdef __GXX_EXPERIMENTAL_CXX0X__
 #include 
 #include 
-#include 
+#include 
 #endif
 
 namespace std _GLIBCXX_VISIBILITY(default)
@@ -477,7 +477,7 @@
static typename
enable_if::value, size_type>::type
_S_max_size(_Alloc2&)
-   { return numeric_limits::max(); }
+   { return __gnu_cxx::__numeric_traits::__max; }
 
   template
struct __select_helper

Re: Libiberty: POSIXify psignal definition

[Richard Earnshaw]

On 08/06/11 12:56, Hans-Peter Nilsson wrote:
> On Thu, 26 May 2011, DJ Delorie wrote:
>>
>>> Yes please.  I've been arguing for that for some time.
>>
>> Since you feel so strongly about it and nobody objects, go ahead.
> 
> Backport to open branches?  (And note PR48825.)
> 
> brgds, H-P
> 
> 

I think we have to, given that at present this breaks building older
compilers with newer versions of newlib.

R.

Re: [PATCH] add another sandy bridge model number

[Uros Bizjak]

Hello!

> 2011-06-6  Andi Kleen  

2011-06-08 ...

>   * config/i386/driver-i386.c (host_detect_local_cpu):
>   Add model 0x2d Intel CPU.

OK with updated ChangeLog entry.

Thanks,
Uros.

C++ PATCH for c++/49322 (libstdc++ testsuite failures)

[Jason Merrill]

In my last patch I ggc_freed a tree that was used in tinst levels, 
leading to GC corruption when a tinst level is saved in a pending 
template.  This patch avoids that by not freeing if we've allocated a 
pending template.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit c8c28d6fc74a40f62e5a88352a04787931423e41
Author: Jason Merrill 
Date:   Tue Jun 7 23:49:29 2011 -0400

	* pt.c (deduction_tsubst_fntype): Don't free the tinst entry
	if a pending_template entry is pointing at it.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index f93fa7f..61ca31c 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -13611,6 +13611,7 @@ deduction_tsubst_fntype (tree fn, tree targs)
   static bool excessive_deduction_depth;
   static int deduction_depth;
   location_t save_loc = input_location;
+  struct pending_template *old_last_pend = last_pending_template;
 
   tree fntype = TREE_TYPE (fn);
   tree tinst;
@@ -13644,7 +13645,9 @@ deduction_tsubst_fntype (tree fn, tree targs)
 }
 
   pop_tinst_level ();
-  ggc_free (tinst);
+  /* We can't free this if a pending_template entry is pointing at it.  */
+  if (last_pending_template == old_last_pend)
+ggc_free (tinst);
   return r;
 }
 

[libffi] Fix libffi.call/huge_struct.c on Tru64 UNIX

[Rainer Orth]

The last libffi failure on Tru64 UNIX is libffi.call/huge_struct.c:

FAIL: libffi.call/huge_struct.c -O0 -W -Wall execution test
FAIL: libffi.call/huge_struct.c -O2 execution test
FAIL: libffi.call/huge_struct.c -O3 execution test
FAIL: libffi.call/huge_struct.c -Os execution test
FAIL: libffi.call/huge_struct.c -O2 -fomit-frame-pointer execution test

The test SEGVs in huge_struct.c (test_large_fn):

Program received signal SIGSEGV, Segmentation fault.
0x03ff8021dcc4 in _doprnt_dis () from /usr/shlib/libc.so
(gdb) where
#0  0x03ff8021dcc4 in _doprnt_dis () from /usr/shlib/libc.so
#1  0x03ff800e1754 in printf () from /usr/shlib/libc.so
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Some testing with a massively reduced testcase revealed that the cause
is simple: Tru64 UNIX printf doesn't support %hhu/%hhd formats and gets
confused.  As a workaround, I use PRIu8, PRId8 instead, providing a
default for Tru64 UNIX that doesn't have those PRI* macros, and IRIX
6.5, that reveals them only for C99 compilations.

Tested with the appropriate runtest invocation on alpha-dec-osf5.1b,
mips-sgi-irix6.5, and sparc-sun-solaris2.8.

Ok for mainline (and eventual backports to the 4.5 and 4.6 branches)?

Thanks.
Rainer


2011-06-08  Rainer Orth  

* testsuite/libffi.call/huge_struct.c (test_large_fn): Use PRIu8,
PRId8 instead of %hhu, %hhd.
* testsuite/libffi.call/ffitest.h [__alpha__ && __osf__] (PRId8,
PRIu8): Define.
[__sgi__] (PRId8, PRIu8): Define.

diff --git a/libffi/testsuite/libffi.call/ffitest.h 
b/libffi/testsuite/libffi.call/ffitest.h
--- a/libffi/testsuite/libffi.call/ffitest.h
+++ b/libffi/testsuite/libffi.call/ffitest.h
@@ -67,6 +67,8 @@
 #define PRIdLL "ld"
 #undef PRIuLL
 #define PRIuLL "lu"
+#define PRId8 "hd"
+#define PRIu8 "hu"
 #define PRId64 "ld"
 #define PRIu64 "lu"
 #define PRIuPTR "lu"
@@ -81,6 +83,8 @@
 #if defined(__sgi)
 /* IRIX 6.5  provides all definitions, but only for C99
compilations.  */
+#define PRId8 "hhd"
+#define PRIu8 "hhu"
 #if (_MIPS_SZLONG == 32)
 #define PRId64 "lld"
 #define PRIu64 "llu"
diff --git a/libffi/testsuite/libffi.call/huge_struct.c 
b/libffi/testsuite/libffi.call/huge_struct.c
--- a/libffi/testsuite/libffi.call/huge_struct.c
+++ b/libffi/testsuite/libffi.call/huge_struct.c
@@ -129,14 +129,14 @@ test_large_fn(
ui64_4 + 4, si64_4 + 4, f_4 + 4, d_4 + 4, ld_4 + 4, 
(char*)((intptr_t)p_4 + 4), 
ui8_5 + 5, si8_5 + 5};
 
-   printf("%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f %.0Lf 
%#lx "
-   "%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f 
%.0Lf %#lx "
-   "%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f 
%.0Lf %#lx "
-   "%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f 
%.0Lf %#lx %hhu %hhd: "
-   "%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f 
%.0Lf %#lx "
-   "%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f 
%.0Lf %#lx "
-   "%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f 
%.0Lf %#lx "
-   "%hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f 
%.0Lf %#lx %hhu %hhd\n",
+   printf("%" PRIu8 " %" PRId8 " %hu %hd %u %d %" PRIu64 " %" PRId64 " 
%.0f %.0f %.0Lf %#lx "
+   "%" PRIu8 " %" PRId8 " %hu %hd %u %d %" PRIu64 " %" PRId64 " 
%.0f %.0f %.0Lf %#lx "
+   "%" PRIu8 " %" PRId8 " %hu %hd %u %d %" PRIu64 " %" PRId64 " 
%.0f %.0f %.0Lf %#lx "
+   "%" PRIu8 " %" PRId8 " %hu %hd %u %d %" PRIu64 " %" PRId64 " 
%.0f %.0f %.0Lf %#lx %" PRIu8 " %" PRId8 ": "
+   "%" PRIu8 " %" PRId8 " %hu %hd %u %d %" PRIu64 " %" PRId64 " 
%.0f %.0f %.0Lf %#lx "
+   "%" PRIu8 " %" PRId8 " %hu %hd %u %d %" PRIu64 " %" PRId64 " 
%.0f %.0f %.0Lf %#lx "
+   "%" PRIu8 " %" PRId8 " %hu %hd %u %d %" PRIu64 " %" PRId64 " 
%.0f %.0f %.0Lf %#lx "
+   "%" PRIu8 " %" PRId8 " %hu %hd %u %d %" PRIu64 " %" PRId64 " 
%.0f %.0f %.0Lf %#lx %" PRIu8 " %" PRId8 "\n",
   ui8_1, si8_1, ui16_1, si16_1, ui32_1, si32_1, ui64_1, si64_1, 
f_1, d_1, ld_1, (unsigned long)p_1,
ui8_2, si8_2, ui16_2, si16_2, ui32_2, si32_2, ui64_2, si64_2, 
f_2, d_2, ld_2, (unsigned long)p_2,
ui8_3, si8_3, ui16_3, si16_3, ui32_3, si32_3, ui64_3, si64_3, 
f_3, d_3, ld_3, (unsigned long)p_3,
@@ -296,10 +296,10 @@ main(int argc __UNUSED__, const char** a
 
ffi_call(&cif, FFI_FN(test_large_fn), &retVal, argValues);
// { dg-output "1 2 3 4 5 6 7 8 9 10 11 0x12345678 1 2 3 4 5 6 7 8 9 10 
11 0x12345678 1 2 3 4 5 6 7 8 9 10 11 0x12345678 1 2 3 4 5 6 7 8 9 10 11 
0x12345678 1 2: 2 3 4 5 6 7 8 9 10 11 12 0x12345679 3 4 5 6 7 8 9 10 11 12 13 
0x1234567a 4 5 6 7 8 9 10 11 12 13 14 0x1234567b 5 6 7 8 9 10 11 12 13 14 15 
0x1234567c 6 7" }
-   printf("res: %hhu %hhd %hu %hd %u %d %" PRIu64 " %" PRId64 " %.0f %.0f 
%.

PATCH: Support unknown Intel family 0x6 CPUs

[H.J. Lu]

Hi,

This patch supports unknown Intel family 0x6 CPUs.  OK for trunk and
4.6 branch?

Thanks.

H.J.
--
2011-06-08  H.J. Lu  

* config/i386/driver-i386.c (host_detect_local_cpu): Support
unknown Intel family 0x6 CPUs.

diff --git a/gcc/config/i386/driver-i386.c b/gcc/config/i386/driver-i386.c
index 4fc6b45..985a6ff 100644
--- a/gcc/config/i386/driver-i386.c
+++ b/gcc/config/i386/driver-i386.c
@@ -587,9 +587,22 @@ const char *host_detect_local_cpu (int argc, const char 
**argv)
default:
  if (arch)
{
- if (has_ssse3)
-   /* If it is an unknown CPU with SSSE3, assume Core 2.  */
-   cpu = "core2";
+ /* This is unknown family 0x6 CPU.  */
+ if (has_avx)
+   /* Assume Sandy Bridge.  */
+   cpu = "corei7-avx";
+ else if (has_sse4_2)
+   /* Assume Core i7.  */
+   cpu = "corei7";
+ else if (has_ssse3)
+   {
+ if (has_movbe)
+   /* Assume Atom.  */
+   cpu = "atom";
+ else
+   /* Assume Core 2.  */
+   cpu = "core2";
+   }
  else if (has_sse3)
/* It is Core Duo.  */
cpu = "pentium-m";

Re: PATCH: Support unknown Intel family 0x6 CPUs

[Uros Bizjak]

On Wed, Jun 8, 2011 at 3:20 PM, H.J. Lu  wrote:
> Hi,
>
> This patch supports unknown Intel family 0x6 CPUs.  OK for trunk and
> 4.6 branch?
>
> Thanks.
>
> H.J.
> --
> 2011-06-08  H.J. Lu  
>
>        * config/i386/driver-i386.c (host_detect_local_cpu): Support
>        unknown Intel family 0x6 CPUs.

OK.

Thanks,
Uros.

Re: Libiberty: POSIXify psignal definition

[DJ Delorie]

> > Since you feel so strongly about it and nobody objects, go ahead.
> 
> Backport to open branches?  (And note PR48825.)

I've already given my OK, it's up to the branch managers to apply as
they see fit.

Cgraph alias reorg 0/14

[Jan Hubicka]

Hi,
in the following series of patches I want to reorganize handling of alises in
cgraph infastructure.

The longer term plan is to introduce symbol table into GCC that will be common
base for cgraph, varpool and aliases (i.e. all kinds of symbols we have in
GCC).

Original design of cgraph/varpool was motivated by needs of IPA passes that
sort of don't want to know about existence of multiple symbols defining same
object and thus aliases was not present in the structures.

The implementation of aliases is ackward. We do collect them in alias pairs and
then we mark all aliased symbols as "needed" that is kind of full optimization
barrier for IPA. This produce lousy code and thus we added special case of
same body aliases and thunks for C++ use.

I already changed thunks to be stand alone function, this series is going to do
the same for standard aliases (i.e. function-function aliases that are not
weakrefs). Weakrefs, variable aliases and introduction of symbtab will follow
incremnetally.

The repsentation of function alias is a cgraph_node with node->alias set and
with only one reference of new type IPA_REF_ALIAS pointing to the real
function.

This imply a need for IPA passes to actually understand the aliases.  Most
passes want to simply pretend that edges/references go to the final objects
instead of the alias nodes.  This is hoever not 100% direct transition because
alias can have different visibility than the final function (i.e. one can take
overwritable alias of static or hidden function).

For this reason I added several accestor functions.

cgraph_function_or_thunk_node that for given node walks the chain of aliases
until it finds a real function or thunk node and cgraph_for_node_and_aliases
that takes a callback and calls it on given function and all its alias nodes.

For passes that wants to go through thunks, too, there is
cgraph_for_node_thunks_and_aliases and cgraph_function_node.

The merge plan of this series is as follows:

 - first few fixes and cleanups
 - cgraph_function_or_thunk_node, cgraph_for_node_and_aliases,
   cgraph_for_node_thunks_and_aliases, cgraph_function_node functions that do
   nothing, since they are pointless on current representaiton.
 - update of each of the individual optimizers to use them
 - introduction of the new representation + all the changes that has to
   go along with it.

I've tested the combined patch on x86_64-linux, x86-linux, ppc-linux
by bootstrap/regtest as well as on the Mozilla.

Honza

[PATCH] Improve debug info for IPA-SRA optimized code - add DW_OP_GNU_parameter_ref support (PR debug/47858)

[Jakub Jelinek]

Hi!

This is something I've already briefly talked about in my GCC Summit talk.
E.g. given a simple testcase like:

volatile int vv;

static __attribute__((noinline)) int
foo (int x, int y, int z)
{
  int a = x * 2;
  int b = y * 2;
  int c = z * 2;
  vv++;
  return x + z;
}

int
bar (int x)
{
  return foo (x, 2, 3) + foo (x, 4, 3) + foo (x + 6, x, 3) + x;
}

or the slightly larger testcase from this PR distilled from Linux kernel,
when this is compiled with -O2 -g, there is no debug info for
variable b and parameter y in foo.  The problem is that IPA-SRA decides
that y isn't really used and clones foo into a function which isn't passed
that argument at all.  z isn't passed at all either, as it is IPA-CP
optimized too, but there we emit already DEBUG z => 3 stmt (and similarly
for c debug stmt; we can do that because the passed parameter is constant
and always the same).

This patch introduces a new DWARF GNU extension opcode,
DW_OP_GNU_parameter_ref, which is similar to DW_OP_GNU_entry_value in that
it can use parent's DW_TAG_call_site DIE and its children, but is identified
by a DIE reference to the abstract optimized away DW_TAG_formal_parameter
(and corresponding DW_TAG_GNU_call_site_parameter should have the same
DW_AT_abstract_origin).  The operand is 4 byte CU relative reference like
in DW_OP_call4, the caller and callee should be in the same CU for this
anyway.

The patch has multiple parts:
1) introduces source bind debug stmts, printed as
   DEBUG x s=> y
   where x can be either some decl or DEBUG_EXPR_DECL and y is some
   parameter or variable.  This says that x at this spot has the same
   location as y at that spot, so in the future something representable
   by DW_OP_call*, currently just used early in the function
   to refer to PARM_DECLs or optimized away PARM_DECLs.
   tree_versioning and IPA-SRA modifications then can use these
   source binds to say that something is based on an original value
   of a parameter.  This alone fixes the above testcase with
   -O2 -g -fno-ipa-sra, where during versioning no SSA_NAME is created
   for the y parameter which isn't otherwise used, thus we were
   resetting DEBUG b => y_3(D) * 2 stmt because to avoid -g/-g0 codegen
   differences we couldn't create SSA_NAME in that case.
   In that case the source debug bind resulted in DEBUG_INSN mapping
   b to 2 * ENTRY_VALUE (y) and var-tracking even figured out it is still
   alive in %rsi.
2) introduces debug args vector, attached to the called function, which
   maps the abstract origin PARM_DECLs that were optimized out to
   some DEBUG_EXPR_DECLs.  This is populated by IPA-SRA (or, in the
   future other passes that do similar argument changes), the
   DEBUG_EXPR_DECLs are the same in all callers of the IPA-SRA modified
   function and there are debug bind stmts in front of the calls
   mapping the temps to some expressions.
3) introduces DEBUG_PARAMETER_REF rtl, whose parameter is the abstract
   origin PARM_DECL.  This is used in DEBUG_INSNs (from source debug binds
   of optimized away parameters) and during vartracking and in
   NOTE_INSN_CALL_ARG_LOCATION to reference call site values for the
   optimized away parameters.
4) and include/dwarf2.h and dwarf2out.c introduce the new
   DW_OP_GNU_parameter_ref op and emit it.

E.g. on the testcase distilled from the kernel the argument isn't removed,
but replaced by a field from a structure pointed out by the original
parameter, in that case still DW_OP_GNU_parameter_ref allows (when possible)
to query the value of it in the debugger.

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

2011-06-08  Jakub Jelinek  

PR debug/47858
* gimple.h (enum gimple_debug_subcode): Add GIMPLE_DEBUG_SOURCE_BIND.
(gimple_build_debug_source_bind_stat): New prototype.
(gimple_build_debug_source_bind): Define.
(gimple_debug_source_bind_p, gimple_debug_source_bind_get_var,
gimple_debug_source_bind_get_value,
gimple_debug_source_bind_get_value_ptr,
gimple_debug_source_bind_set_var,
gimple_debug_source_bind_set_value): New inlines.
* gimple.c (gimple_build_debug_source_bind_stat): New function.
* gimple-pretty-print.c (dump_gimple_debug): Handle
GIMPLE_DEBUG_SOURCE_BIND.
* sese.c (rename_uses): Handle gimple_debug_source_bind_p.
* tree-ssa-dce.c (mark_stmt_if_obviously_necessary): Likewise.
* tree-parloops.c (eliminate_local_variables,
separate_decls_in_region): Likewise.
(separate_decls_in_region_debug): Renamed from
separate_decls_in_region_debug_bind.  Handle
gimple_debug_source_bind_p.
* tree.h (decl_debug_args_lookup, decl_debug_args_insert): New
prototypes.
(DECL_HAS_DEBUG_ARGS_P): Define.
(struct tree_function_decl): Add has_debug_args_flag field.
* tree.c (debug_args_for_decl): New variable.
(decl_debug_args_lookup, decl_debug_args_insert): New funct

Re: [pph] Stream TREE_TYPE for identifier node (issue4550121)

[Diego Novillo]

On Wed, Jun 8, 2011 at 03:38, Steven Bosscher  wrote:
> On Tue, Jun 7, 2011 at 11:50 PM, Diego Novillo  wrote:
>> On Tue, Jun 7, 2011 at 14:12, Steven Bosscher  wrote:
>>> On Tue, Jun 7, 2011 at 8:44 PM, Gabriel Charette  wrote:
 We need to stream TREE_TYPE for identifier node.
>>>
>>> That seems unlikely, as identifiers do not have a type. There is some
>>> TREE_TYPE abuse in cp-tree.h, perhaps you should find out what you're
>>> streaming.
>>
>> It's used by the C++ parser, so it needs to be streamed in pph.
>
> Yes, but you should not stream TREE_TYPE but use the accessor macro
> that uses TREE_TYPE. Otherwise, if someone gets around to making
> IDENTIFIER nodes non-typed trees (and update cp-tree.h accordingly)
> the streaming will break.

It does, actually:

cp/rtti.c:
bool
emit_tinfo_decl (tree decl)
{
  tree type = TREE_TYPE (DECL_NAME (decl));


Diego.

[Patch ARM] Unify movdi patterns and fix case for mvn in const_ok_for_op.

[Ramana Radhakrishnan]

Hi,

This fixes a testsuite failure with 20041011-1.c where we are
generating out of range adr instructions because a splitter goes awry
because we didn't consider the mvn case in const_ok_for_op.

So we ended up splitting this

movdi reg:r1 0x

to

(insn 370 21 371 (set (reg:SI 2 r2)
(const_int -2147483648 [0x8000]))
/home/ramrad01/sources/fsf/trunk/gcc/testsuite/gcc.c-torture/execute/20041011-1.c:56
624 {*arm_movsi_vfp}
 (nil))

(insn 371 370 372 (set (reg:SI 2 r2)
(ashiftrt:SI (reg:SI 2 r2)
(const_int 31 [0x1f])))
/home/ramrad01/sources/fsf/trunk/gcc/testsuite/gcc.c-torture/execute/20041011-1.c:56
119 {*arm_shiftsi3}
 (nil))

(insn 372 371 23 (set (reg:SI 3 r3 [+4 ])
(const_int 0 [0]))
/home/ramrad01/sources/fsf/trunk/gcc/testsuite/gcc.c-torture/execute/20041011-1.c:56
624 {*arm_movsi_vfp}
 (nil))

After this patch we now split this to a mvn 0 followed by a mov 0
which is much better.

I've also taken the opportunity to rejig the *movdi patterns to make
them simpler - unified them with thumb2 movdi patterns and taken out
the check for TARGET_VFP_SINGLE from the cortex-a8 version . Tested
with cross on armv7-a for qemu in both ARM and Thumb2 state using
arm-linux-gnueabi.

I will commit this in 24 hours if there are no objections.

cheers
Ramana


2011-06-03  Ramana Radhakrishnan  
  Richard Earnshaw  

* config/arm/arm.c (const_ok_for_op): Check to see
if mvn can be used.
* config/arm/vfp.md (*arm_movdi_vfp): Delete.
(*thumb2_movdi_vfp): Delete.
(*arm_movdi_vfp_cortexa8): Delete.
(*movdi_vfp): Consolidate from *arm_movdi_vfp and *thumb2_movdi_vfp.
(*movdi_vfp_cortexa8): Likewise.
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 57c5238..c2d69c8 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -2210,7 +2210,8 @@ const_ok_for_op (HOST_WIDE_INT i, enum rtx_code code)
   if (arm_arch_thumb2 && (i & 0x) == 0)
return 1;
   else
-   return 0;
+   /* Otherwise, try mvn.  */
+   return const_ok_for_arm (ARM_SIGN_EXTEND (~i));
 
 case PLUS:
 case COMPARE:
diff --git a/gcc/config/arm/vfp.md b/gcc/config/arm/vfp.md
index d257cb8..42be2ff 100644
--- a/gcc/config/arm/vfp.md
+++ b/gcc/config/arm/vfp.md
@@ -133,127 +133,92 @@
 
 ;; DImode moves
 
-(define_insn "*arm_movdi_vfp"
-  [(set (match_operand:DI 0 "nonimmediate_di_operand" "=r, r, m,w,r,w,w, Uv")
-   (match_operand:DI 1 "di_operand"  "rIK,mi,r,r,w,w,Uvi,w"))]
-  "TARGET_ARM && TARGET_HARD_FLOAT && TARGET_VFP && arm_tune != cortexa8
+(define_insn "*movdi_vfp"
+  [(set (match_operand:DI 0 "nonimmediate_di_operand" "=r,r,r,r,r,r,m,w,r,w,w, 
Uv")
+   (match_operand:DI 1 "di_operand"  
"r,rDa,Db,Dc,mi,mi,r,r,w,w,Uvi,w"))]
+  "TARGET_32BIT && TARGET_HARD_FLOAT && TARGET_VFP && arm_tune != cortexa8
&& (   register_operand (operands[0], DImode)
|| register_operand (operands[1], DImode))"
   "*
   switch (which_alternative)
 {
 case 0: 
-  return \"#\";
 case 1:
 case 2:
-  return output_move_double (operands);
 case 3:
-  return \"fmdrr%?\\t%P0, %Q1, %R1\\t%@ int\";
+  return \"#\";
 case 4:
-  return \"fmrrd%?\\t%Q0, %R0, %P1\\t%@ int\";
 case 5:
+case 6:
+  return output_move_double (operands);
+case 7:
+  return \"fmdrr%?\\t%P0, %Q1, %R1\\t%@ int\";
+case 8:
+  return \"fmrrd%?\\t%Q0, %R0, %P1\\t%@ int\";
+case 9:
   if (TARGET_VFP_SINGLE)
return \"fcpys%?\\t%0, %1\\t%@ int\;fcpys%?\\t%p0, %p1\\t%@ int\";
   else
return \"fcpyd%?\\t%P0, %P1\\t%@ int\";
-case 6: case 7:
+case 10: case 11:
   return output_move_vfp (operands);
 default:
   gcc_unreachable ();
 }
   "
-  [(set_attr "type" "*,load2,store2,r_2_f,f_2_r,ffarithd,f_loadd,f_stored")
-   (set_attr "neon_type" "*,*,*,neon_mcr_2_mcrr,neon_mrrc,neon_vmov,*,*")
-   (set (attr "length") (cond [(eq_attr "alternative" "0,1,2") (const_int 8)
-  (eq_attr "alternative" "5")
-   (if_then_else
-(eq (symbol_ref "TARGET_VFP_SINGLE") 
(const_int 1))
-(const_int 8)
-(const_int 4))]
- (const_int 4)))
-   (set_attr "pool_range" "*,1020,*,*,*,*,1020,*")
-   (set_attr "neg_pool_range" "*,1008,*,*,*,*,1008,*")]
+  [(set_attr "type" 
"*,*,*,*,load2,load2,store2,r_2_f,f_2_r,ffarithd,f_loadd,f_stored")
+   (set_attr "neon_type" 
"*,*,*,*,*,*,*,neon_mcr_2_mcrr,neon_mrrc,neon_vmov,*,*")
+   (set (attr "length") (cond [(eq_attr "alternative" "1,4,5,6") (const_int 8)
+  (eq_attr "alternative" "2") (const_int 12)
+  (eq_attr "alternative" "3") (const_int 16)
+  (eq_attr "alternative" "9")
+   

Re: [testsuite] skip ARM tests with conflicting options

[Janis Johnson]

On 06/08/2011 03:39 AM, Richard Earnshaw wrote:
> On 08/06/11 03:14, Janis Johnson wrote:
>> On 06/07/2011 06:25 PM, Mike Stump wrote:
>>> On Jun 7, 2011, at 4:24 PM, Janis Johnson wrote:
 On 06/07/2011 02:07 PM, Joseph S. Myers wrote:
> On Tue, 7 Jun 2011, Janis Johnson wrote:
>
>> Several tests in gcc.target/arm use dg-options with -mcpu=, which
>> causes compiler warnings or errors when the multilib flags include
>> -march=.  This patch causes those tests to be skipped.  It also
>> prevents gcc.target/arm/20090811-1.c from running with multilibs that
>> would override -mcpu or -mfloat-abi options specified for the test.
>
> I think you should allow compatible -march options - for example, if 
> dg-options has -mcpu=cortex-a8, allow -march=armv7-a but disallow all 
> other -march options.
>
 Is this one OK?
>>>
>>> Not sure if the arm people want to review this or would rather I review 
>>> it...
>>>
>>> Let's give the arm folks a couple days to comment, if no objections, Ok.
>>>
>>> A point of warning, eventually, you'll discover that when a compiler 
>>> defaults to the argument you want to skip, that you'll needs slightly more 
>>> power to skip them.  darwin ran into this with things like -m64, and 
>>> eventually had to do something like lp64.  configure options like 
>>> --with-cpu=arm9 are the sort that can change the default.
>>
>> Yes, I hope to hear from ARM people.
>>
>> On ARM, the default from --with-cpu= is overridden by -march at
>> compile so it's not a problem for this particular set of tests.
>> As I said originally, this set is the tip of the iceberg and they
>> get more difficult.
>>
>> Janis
>>
>>
> 
> 
> I'm worried by this whole approach of command-line checking.  It works,
> just about, for testsuite variations set with target_list, but it won't
> work with options used to configure the compiler (eg --with-mode=thumb,
> or --with-cpu=...).  Perhaps a better approach would be a new dg- test
> that built a trivial file with all the options and disabled the test if
> that test failed for any reason.  Something like:
> 
> dg-target-compatible (target, , additional-opts)
> 
> The test is only performed if target matches the current target.
> 
> I'm not sure if this is something that can be easily cached (well, it
> might be possible if you could index off additional-opts and the default
> opts), so it might be that this test has to be re-run every time there
> is a test that needs it.
> 
> R.

There's a similar functionality now with effective targets that end with
"_ok"; they test with options that would be added with a later directive.
The problem is that they can't be specific enough for what the test is
looking for; arm_neon_fp16_ok, for example, currently passes when the
multilib options include -mfpu=neon, which overrides the options provided
by dg-options, and that leads to problems.

I think that a test that requires a specific option should provide that
option, but be skipped if multilib options include a conflict.  This
includes -mcpu, -mfpu, -march, -mfloat-abi, -mbig-endian, and possibly
more.  Those options override the defaults for the configuration, so we
shouldn't have to worry about the defaults.

The big question is whether such a test should be run for all multilibs
that might possibly pass the test, or only for default and for mulitlibs
that provide the same options.  There are a lot of arm tests that use
-march but pass for a great many other -march options.  In most cases
they use -march with the value for which the problem was reported.
Should those tests be run for all multilibs, with the multilib options
overriding the "defaults" for the test from dg-options, or should they
be skipped multilibs that use other values?  The answer might depend on
the individual test; maybe some should be run for a large number of
multilib options to find problems with specific ones, while others can
be limited to run just once or a few times.

Janis

Re: [testsuite] skip ARM neon-fp16 tests for other -mcpu values

[Janis Johnson]

On 06/08/2011 03:17 AM, Joseph S. Myers wrote:
> On Tue, 7 Jun 2011, Janis Johnson wrote:
> 
>> These tests fail when multilib options use -mfpu= and override the
>> -mfpu=neon-fp16 used for the test:
>>
>>   g++.dg/ext/arm-fp16/arm-fp16-ops-5.C
>>   g++.dg/ext/arm-fp16/arm-fp16-ops-6.C
>>   gcc.dg/torture/arm-fp16-ops-5.c
>>   gcc.dg/torture/arm-fp16-ops-6.c
>>   gcc.target/arm/fp16-compile-vcvt.c
>>
>> The option -mfpu-neon-fp16 is added via "dg-add-options arm_neon_fp16"
>> after an earlier "dg-require-effective-target arm_neon_fp16_ok".
>> This patch modifies check_effective_target_arm_neon_fp16_ok_nocache to
>> return 0 (causing the test to be skipped) if multilib flags include
>> -mfpu= with a value other than neon-fp16.
> 
> But I'd think they ought to work with any -mfpu= option supporting 
> half-precision instructions - that is, vfpv3-fp16, vfpv3-d16-fp16, 
> vfpv3xd-fp16, neon-fp16, vfpv4, vfpv4-d16, fpv4-sp-d16, neon-vfpv4 
> (anything with "true" in the last field in arm-fpus.def; for the 
> testsuite, you can probably suppose anything -mfpu=*fp16*, 
> -mfpu=*fpv[4-9]*, -mfpu=*fpv[1-9][0-9]*).
> 

If someone is testing with a multilib using "-mfpu=vfpv4" they're probably
also testing with a multilib that doesn't use -mfpu, so they're running
the test somewhere.  Do we want to run these tests for all multilibs that
use one of those,or is it enough to only use -mfpu=neon-fp16 for the tests?

I think we're going to be looking at that question for a lot of individual
tests, and the answer will vary depending on the test.  I want to clean up
these tests so they can be run cleanly with a lot of multilibs so that
real failures can be noticed, so I really appreciate this discussion.

The mips tests use their own scheme to override multilib options, but I
find it confusing and would rather do something else, unless the arm
developers want to use that for arm tests as well.  

Janis

Re: [google] Patch to add compiler flag to dump callgraph edge profiles in special .note sections (issue4591045)

[Sriraman Tallam]

+davidxl

On Tue, Jun 7, 2011 at 7:05 PM, Sriraman Tallam  wrote:
> Patch Description:
> =
>
> I am working on a project to do global function layout in the linker where 
> the linker reads the callgraph edge profile information, generated by FDO, 
> and uses that to find a ordering of functions that will place functions 
> calling each other frequently closer, like the Pettis-Hansen code ordering 
> algorithm described in the paper "Profile-guided Code Poisitioning" in PLDI 
> 1990.
>
> This patch adds a flag that allows the callgraph edge profile information to 
> be stored .note sections called ".note.callgraph.text". The new compiler flag 
> -fcallgraph-profiles-sections generates these sections and must be used along 
> with -fprofile-use. I have added a PARAM to only output callgraph edges 
> greater than a specified threshold. Once this is available, the linker can 
> read these sections and generate a global callgraph which can be used to 
> determine a global function ordering.
>
> I am adding plugin support in the gold linker to allow linker plugins to be 
> able to read the contents of sections and also adding plugin hooks to specify 
> a desired ordering of functions to the linker. The linker patch is available 
> here : http://sourceware.org/ml/binutils/2011-03/msg00043.html. Once this is 
> available, linker plugins can be used to determine the function layout, like 
> the Pettis-Hansen algorithm, of the final binary.
>
> Example: The new .note.callgraph.text sections looks like this for a function 
> foo that calls bar 100 times and zap 50 times:
> 
> .section        .note.callgraph.text._Z3foov,"",@progbits
>        .string "Function _Z3foov"
>        .string "_Z3barv"
>        .string "100"
>        .string "_Z3zapv"
>        .string "50"
> ***
>
> For now, this is for google/main. I will re-submit for review to trunk along 
> with data layout.
>
> Google ref 41940
>
> 2011-06-07  Sriraman Tallam  
>
>        * doc/invoke.texi: document option -fcallgraph-profiles-sections.
>        * final.c  (dump_cgraph_profiles): New function.
>        (rest_of_handle_final): Create new section '.note.callgraph.text'
>        with compiler flag -fcallgraph-profiles-sections
>        * common.opt: New option -fcallgraph-profiles-sections.
>        * params.def (DEFPARAM): New param
>        PARAM_NOTE_CGRAPH_SECTION_EDGE_THRESHOLD.
>
> Index: doc/invoke.texi
> ===
> --- doc/invoke.texi     (revision 174789)
> +++ doc/invoke.texi     (working copy)
> @@ -351,7 +351,7 @@ Objective-C and Objective-C++ Dialects}.
>  -falign-labels[=@var{n}] -falign-loops[=@var{n}] -fassociative-math @gol
>  -fauto-inc-dec -fbranch-probabilities -fbranch-target-load-optimize @gol
>  -fbranch-target-load-optimize2 -fbtr-bb-exclusive -fcaller-saves @gol
> --fcheck-data-deps -fclone-hot-version-paths @gol
> +-fcallgraph-profiles-sections -fcheck-data-deps -fclone-hot-version-paths 
> @gol
>  -fcombine-stack-adjustments -fconserve-stack @gol
>  -fcompare-elim -fcprop-registers -fcrossjumping @gol
>  -fcse-follow-jumps -fcse-skip-blocks -fcx-fortran-rules @gol
> @@ -8114,6 +8114,15 @@ Do not promote static functions with always inline
>  @opindex fripa-verbose
>  Enable printing of verbose information about dynamic inter-procedural 
> optimizations.
>  This is used in conjunction with the @option{-fripa}.
> +
> +@item -fcallgraph-profiles-sections
> +@opindex fcallgraph-profiles-sections
> +Emit call graph edge profile counts in .note.callgraph.text sections. This is
> +used in conjunction with @option{-fprofile-use}. A new .note.callgraph.text
> +section is created for each function. This section lists every callee and the
> +number of times it is called. The params variable
> +"note-cgraph-section-edge-threshold" can be used to only list edges above a
> +certain threshold.
>  @end table
>
>  The following options control compiler behavior regarding floating
> Index: final.c
> ===
> --- final.c     (revision 174789)
> +++ final.c     (working copy)
> @@ -4321,13 +4321,37 @@ debug_free_queue (void)
>       symbol_queue_size = 0;
>     }
>  }
> -
> +
> +/* List the call graph profiled edges whise value is greater than
> +   PARAM_NOTE_CGRAPH_SECTION_EDGE_THRESHOLD in the
> +   ".note.callgraph.text" section. */
> +static void
> +dump_cgraph_profiles (void)
> +{
> +  struct cgraph_node *node = cgraph_node (current_function_decl);
> +  struct cgraph_edge *e;
> +  struct cgraph_node *callee;
> +
> +  for (e = node->callees; e != NULL; e = e->next_callee)
> +    {
> +      if (e->count <= PARAM_VALUE (PARAM_NOTE_CGRAPH_SECTION_EDGE_THRESHOLD))
> +        continue;
> +      callee = e->callee;
> +      fprintf (asm_out_file, "\t.string \"%s\"\n",
> +               IDENTIFIER_POINTER (decl_assembler_name (callee->decl)));
> +      fprintf (asm_

Re: [google] Patch to add compiler flag to dump callgraph edge profiles in special .note sections (issue4591045)

[Xinliang David Li]

ok for google/main.

David

On Wed, Jun 8, 2011 at 9:13 AM, Sriraman Tallam  wrote:
> +davidxl
>
> On Tue, Jun 7, 2011 at 7:05 PM, Sriraman Tallam  wrote:
>> Patch Description:
>> =
>>
>> I am working on a project to do global function layout in the linker where 
>> the linker reads the callgraph edge profile information, generated by FDO, 
>> and uses that to find a ordering of functions that will place functions 
>> calling each other frequently closer, like the Pettis-Hansen code ordering 
>> algorithm described in the paper "Profile-guided Code Poisitioning" in PLDI 
>> 1990.
>>
>> This patch adds a flag that allows the callgraph edge profile information to 
>> be stored .note sections called ".note.callgraph.text". The new compiler 
>> flag -fcallgraph-profiles-sections generates these sections and must be used 
>> along with -fprofile-use. I have added a PARAM to only output callgraph 
>> edges greater than a specified threshold. Once this is available, the linker 
>> can read these sections and generate a global callgraph which can be used to 
>> determine a global function ordering.
>>
>> I am adding plugin support in the gold linker to allow linker plugins to be 
>> able to read the contents of sections and also adding plugin hooks to 
>> specify a desired ordering of functions to the linker. The linker patch is 
>> available here : http://sourceware.org/ml/binutils/2011-03/msg00043.html. 
>> Once this is available, linker plugins can be used to determine the function 
>> layout, like the Pettis-Hansen algorithm, of the final binary.
>>
>> Example: The new .note.callgraph.text sections looks like this for a 
>> function foo that calls bar 100 times and zap 50 times:
>> 
>> .section        .note.callgraph.text._Z3foov,"",@progbits
>>        .string "Function _Z3foov"
>>        .string "_Z3barv"
>>        .string "100"
>>        .string "_Z3zapv"
>>        .string "50"
>> ***
>>
>> For now, this is for google/main. I will re-submit for review to trunk along 
>> with data layout.
>>
>> Google ref 41940
>>
>> 2011-06-07  Sriraman Tallam  
>>
>>        * doc/invoke.texi: document option -fcallgraph-profiles-sections.
>>        * final.c  (dump_cgraph_profiles): New function.
>>        (rest_of_handle_final): Create new section '.note.callgraph.text'
>>        with compiler flag -fcallgraph-profiles-sections
>>        * common.opt: New option -fcallgraph-profiles-sections.
>>        * params.def (DEFPARAM): New param
>>        PARAM_NOTE_CGRAPH_SECTION_EDGE_THRESHOLD.
>>
>> Index: doc/invoke.texi
>> ===
>> --- doc/invoke.texi     (revision 174789)
>> +++ doc/invoke.texi     (working copy)
>> @@ -351,7 +351,7 @@ Objective-C and Objective-C++ Dialects}.
>>  -falign-labels[=@var{n}] -falign-loops[=@var{n}] -fassociative-math @gol
>>  -fauto-inc-dec -fbranch-probabilities -fbranch-target-load-optimize @gol
>>  -fbranch-target-load-optimize2 -fbtr-bb-exclusive -fcaller-saves @gol
>> --fcheck-data-deps -fclone-hot-version-paths @gol
>> +-fcallgraph-profiles-sections -fcheck-data-deps -fclone-hot-version-paths 
>> @gol
>>  -fcombine-stack-adjustments -fconserve-stack @gol
>>  -fcompare-elim -fcprop-registers -fcrossjumping @gol
>>  -fcse-follow-jumps -fcse-skip-blocks -fcx-fortran-rules @gol
>> @@ -8114,6 +8114,15 @@ Do not promote static functions with always inline
>>  @opindex fripa-verbose
>>  Enable printing of verbose information about dynamic inter-procedural 
>> optimizations.
>>  This is used in conjunction with the @option{-fripa}.
>> +
>> +@item -fcallgraph-profiles-sections
>> +@opindex fcallgraph-profiles-sections
>> +Emit call graph edge profile counts in .note.callgraph.text sections. This 
>> is
>> +used in conjunction with @option{-fprofile-use}. A new .note.callgraph.text
>> +section is created for each function. This section lists every callee and 
>> the
>> +number of times it is called. The params variable
>> +"note-cgraph-section-edge-threshold" can be used to only list edges above a
>> +certain threshold.
>>  @end table
>>
>>  The following options control compiler behavior regarding floating
>> Index: final.c
>> ===
>> --- final.c     (revision 174789)
>> +++ final.c     (working copy)
>> @@ -4321,13 +4321,37 @@ debug_free_queue (void)
>>       symbol_queue_size = 0;
>>     }
>>  }
>> -
>> +
>> +/* List the call graph profiled edges whise value is greater than
>> +   PARAM_NOTE_CGRAPH_SECTION_EDGE_THRESHOLD in the
>> +   ".note.callgraph.text" section. */
>> +static void
>> +dump_cgraph_profiles (void)
>> +{
>> +  struct cgraph_node *node = cgraph_node (current_function_decl);
>> +  struct cgraph_edge *e;
>> +  struct cgraph_node *callee;
>> +
>> +  for (e = node->callees; e != NULL; e = e->next_callee)
>> +    {
>> +      if (e->count <= PARAM_VALUE 
>> (PARAM_NOTE_CGRAPH_SECTION_EDGE_THRESHOL

Re: [google] Patch to add compiler flag to dump callgraph edge profiles in special .note sections (issue4591045)

[Sriraman Tallam]

On Wed, Jun 8, 2011 at 9:16 AM, Xinliang David Li  wrote:
> ok for google/main.

Thanks, the patch is now committed.

>
> David
>
> On Wed, Jun 8, 2011 at 9:13 AM, Sriraman Tallam  wrote:
>> +davidxl
>>
>> On Tue, Jun 7, 2011 at 7:05 PM, Sriraman Tallam  wrote:
>>> Patch Description:
>>> =
>>>
>>> I am working on a project to do global function layout in the linker where 
>>> the linker reads the callgraph edge profile information, generated by FDO, 
>>> and uses that to find a ordering of functions that will place functions 
>>> calling each other frequently closer, like the Pettis-Hansen code ordering 
>>> algorithm described in the paper "Profile-guided Code Poisitioning" in PLDI 
>>> 1990.
>>>
>>> This patch adds a flag that allows the callgraph edge profile information 
>>> to be stored .note sections called ".note.callgraph.text". The new compiler 
>>> flag -fcallgraph-profiles-sections generates these sections and must be 
>>> used along with -fprofile-use. I have added a PARAM to only output 
>>> callgraph edges greater than a specified threshold. Once this is available, 
>>> the linker can read these sections and generate a global callgraph which 
>>> can be used to determine a global function ordering.
>>>
>>> I am adding plugin support in the gold linker to allow linker plugins to be 
>>> able to read the contents of sections and also adding plugin hooks to 
>>> specify a desired ordering of functions to the linker. The linker patch is 
>>> available here : http://sourceware.org/ml/binutils/2011-03/msg00043.html. 
>>> Once this is available, linker plugins can be used to determine the 
>>> function layout, like the Pettis-Hansen algorithm, of the final binary.
>>>
>>> Example: The new .note.callgraph.text sections looks like this for a 
>>> function foo that calls bar 100 times and zap 50 times:
>>> 
>>> .section        .note.callgraph.text._Z3foov,"",@progbits
>>>        .string "Function _Z3foov"
>>>        .string "_Z3barv"
>>>        .string "100"
>>>        .string "_Z3zapv"
>>>        .string "50"
>>> ***
>>>
>>> For now, this is for google/main. I will re-submit for review to trunk 
>>> along with data layout.
>>>
>>> Google ref 41940
>>>
>>> 2011-06-07  Sriraman Tallam  
>>>
>>>        * doc/invoke.texi: document option -fcallgraph-profiles-sections.
>>>        * final.c  (dump_cgraph_profiles): New function.
>>>        (rest_of_handle_final): Create new section '.note.callgraph.text'
>>>        with compiler flag -fcallgraph-profiles-sections
>>>        * common.opt: New option -fcallgraph-profiles-sections.
>>>        * params.def (DEFPARAM): New param
>>>        PARAM_NOTE_CGRAPH_SECTION_EDGE_THRESHOLD.
>>>
>>> Index: doc/invoke.texi
>>> ===
>>> --- doc/invoke.texi     (revision 174789)
>>> +++ doc/invoke.texi     (working copy)
>>> @@ -351,7 +351,7 @@ Objective-C and Objective-C++ Dialects}.
>>>  -falign-labels[=@var{n}] -falign-loops[=@var{n}] -fassociative-math @gol
>>>  -fauto-inc-dec -fbranch-probabilities -fbranch-target-load-optimize @gol
>>>  -fbranch-target-load-optimize2 -fbtr-bb-exclusive -fcaller-saves @gol
>>> --fcheck-data-deps -fclone-hot-version-paths @gol
>>> +-fcallgraph-profiles-sections -fcheck-data-deps -fclone-hot-version-paths 
>>> @gol
>>>  -fcombine-stack-adjustments -fconserve-stack @gol
>>>  -fcompare-elim -fcprop-registers -fcrossjumping @gol
>>>  -fcse-follow-jumps -fcse-skip-blocks -fcx-fortran-rules @gol
>>> @@ -8114,6 +8114,15 @@ Do not promote static functions with always inline
>>>  @opindex fripa-verbose
>>>  Enable printing of verbose information about dynamic inter-procedural 
>>> optimizations.
>>>  This is used in conjunction with the @option{-fripa}.
>>> +
>>> +@item -fcallgraph-profiles-sections
>>> +@opindex fcallgraph-profiles-sections
>>> +Emit call graph edge profile counts in .note.callgraph.text sections. This 
>>> is
>>> +used in conjunction with @option{-fprofile-use}. A new .note.callgraph.text
>>> +section is created for each function. This section lists every callee and 
>>> the
>>> +number of times it is called. The params variable
>>> +"note-cgraph-section-edge-threshold" can be used to only list edges above a
>>> +certain threshold.
>>>  @end table
>>>
>>>  The following options control compiler behavior regarding floating
>>> Index: final.c
>>> ===
>>> --- final.c     (revision 174789)
>>> +++ final.c     (working copy)
>>> @@ -4321,13 +4321,37 @@ debug_free_queue (void)
>>>       symbol_queue_size = 0;
>>>     }
>>>  }
>>> -
>>> +
>>> +/* List the call graph profiled edges whise value is greater than
>>> +   PARAM_NOTE_CGRAPH_SECTION_EDGE_THRESHOLD in the
>>> +   ".note.callgraph.text" section. */
>>> +static void
>>> +dump_cgraph_profiles (void)
>>> +{
>>> +  struct cgraph_node *node = cgraph_node (current_function_decl);
>>> +  struct

FORBIDDEN_INC_DEC_CLASSES in ira-costs.c

[Hans-Peter Nilsson]

There's a lot of dead code inside the obsolete (removed in 2009)
and nowhere else set #ifdef FORBIDDEN_INC_DEC_CLASSES.
Remove and poison?

I'd say borderline obvious, but maybe there's instead reason to
reinstate it, if that code is tested and supposed to be live.

brgds, H-P

Re: Dump before flag

[Xinliang David Li]

On Wed, Jun 8, 2011 at 2:06 AM, Richard Guenther
 wrote:
> On Wed, Jun 8, 2011 at 1:08 AM, Xinliang David Li  wrote:
>> The following is the patch that does the job. Most of the changes are
>> just  removing TODO_dump_func. The major change is in passes.c and
>> tree-pass.h.
>>
>> -fdump-xxx-yyy-start       <-- dump before TODO_start
>> -fdump-xxx-yyy-before    <-- dump before main pass after TODO_pass
>> -fdump-xxx-yyy-after       <-- dump after main pass before TODO_finish
>> -fdump-xxx-yyy-finish      <-- dump after TODO_finish
>
> Can we bikeshed a bit more about these names?

Yes.

>"start" and "before"
> have no semantical difference to me ... as the dump before TODO_start
> of a pass and the dump after TODO_finish of the previous pass are
> identical (hopefully ;)), maybe merge those into a -between flag?

But the key usefulness here is pass isolation -- you don't need to
know the phase ordering -- the 'before' and 'after' are relative to
the pass that is specified.

> If you'd specify it for a single pass then you'd get both -start and -finish
> (using your naming scheme).  Splitting that dump(s) to different files
> then might make sense (not sure about the name to use).
>

The only downside is it loses fine grain control --- e.g, split IR
emission for the any one of the dumping points (before start todo,
before pass, after pass, after finish todo) into a separate file when
that point is specified. The content of the default dumping remains
unchanged  unless the 'finish' point is specified explicitly. In
short, the patch I had has minimal impact on default behavior, just
adding the capability to extract clean IR into different files for
diffing purpose.


> Note that I find it extremely useful to have dumping done in
> chronological order - splitting some of it to different files destroys
> this, especially a dump after TODO_start or before TODO_finish
> should appear in the same file (or we could also start splitting
> individual TODO_ output into sub-dump-files).  I guess what would
> be nice instread would be a fancy dump-file viewer that could
> show diffs, hide things like SCEV output, etc.

I don't quite understand this comment.  The processing order of
functions are kept in the split files.The main purpose of splitting is
to ease diffing for any transformation -- and our current dump can be
really hard to parse :)

>
> I suppose a patch that removes the dump TODO and unconditionally
> dumps at the current point would be a good preparation for this
> enhancing patch.

Yes -- that can be done.

Thanks,

David

>
> Richard.
>
>> The default is 'finish'.
>>
>> Does it look ok?
>>
>> Thanks,
>>
>> David
>>
>> On Tue, Jun 7, 2011 at 2:36 AM, Richard Guenther
>>  wrote:
>>> On Mon, Jun 6, 2011 at 6:20 PM, Xinliang David Li  
>>> wrote:
>
> Your patch doesn't really improve this but adds to the confusion.
>
> +  /* Override dump TODOs.  */
> +  if (dump_file && (pass->todo_flags_finish & TODO_dump_func)
> +      && (dump_flags & TDF_BEFORE))
> +    {
> +      pass->todo_flags_finish &= ~TODO_dump_func;
> +      pass->todo_flags_start |= TODO_dump_func;
> +    }
>
> and certainly writing to pass is not ok.  And the TDF_BEFORE flag
> looks misplaced as it controls TODOs, not dumping behavior.
> Yes, it's a mess right now but the above looks like a hack ontop
> of that mess (maybe because of it, but well ...).
>

 How about removing dumping TODO completely -- this can be done easily
 -- I don't understand why pass wants extra control on the dumping if
 user already asked for dumping -- it is annoying to see empty IR dump
 for a pass when I want to see it.

> At least I would have expected to also get the dump after the
> pass, not only the one before it with this dump flag.
>
> Now, why can't you look at the previous pass output for the
> before-dump (as I do usually)?

 For one thing, you need to either remember what is the previous pass,
 or dump all passes which for large files can take very long time. Even
 with all the dumps, you will need to eyeballing to find the previous
 pass which may or may not have the IR dumped.

 How about removing dump TODO?
>>>
>>> Yeah, I think this would go in the right direction.  Currently some passes
>>> do not dump function bodies because they presumably do no IL
>>> modification.  But this is certainly the minority (and some passes do not
>>> dump bodies even though they are modifying the IL ...).
>>>
>>> So I'd say we should by default dump function bodies.
>>>
>>> Note that there are three useful dumping positions (maybe four),
>>> before todo-start, after todo-start, before todo-finish and after 
>>> todo-finish.
>>> By default we'd want after todo-finish.  When we no longer dump via
>>> a TODO then we could indeed use dump-flags to control this
>>> (maybe -original for the body before todo-start).
>>>
>>> What to others thin

PATCH: PR other/49325: Incorrect target HAVE_INITFINI_ARRAY check

[H.J. Lu]

Hi,

Target HAVE_INITFINI_ARRAY support was added by:

http://gcc.gnu.org/ml/gcc-patches/2002-11/msg00387.html

Unfortunately, it checks if host supports init_array/fini_array
sections, not target.  It will generate wrong result for cross compiler. 

This patch uses the target compiler instead of host compiler to check
this feature.  For ia64, we set HAVE_INITFINI_ARRAY to 1 if
init_array/fini_array section can be used.  For other targets, we
set it only if we can mix init_array/fini_array sections with
ctors/dtors sections.  OK for trunk?

Thanks.


H.J.
---
2011-06-07  H.J. Lu  

PR other/49325
* acinclude.m4 (gcc_AC_INITFINI_ARRAY): Removed.

* configure.ac: Remove gcc_AC_INITFINI_ARRAY.  Add
--enable-initfini-array and check if .init_array can be used with
.ctors.
* configure: Regenerated.

diff --git a/gcc/acinclude.m4 b/gcc/acinclude.m4
index 3eec559..0f5f686 100644
--- a/gcc/acinclude.m4
+++ b/gcc/acinclude.m4
@@ -369,26 +369,6 @@ else
 fi
 fi])
 
-AC_DEFUN([gcc_AC_INITFINI_ARRAY],
-[AC_ARG_ENABLE(initfini-array,
-   [  --enable-initfini-array  use .init_array/.fini_array sections],
-   [], [
-AC_CACHE_CHECK(for .preinit_array/.init_array/.fini_array support,
-gcc_cv_initfini_array, [dnl
-  AC_RUN_IFELSE([AC_LANG_SOURCE([
-static int x = -1;
-int main (void) { return x; }
-int foo (void) { x = 0; }
-int (*fp) (void) __attribute__ ((section (".init_array"))) = foo;])],
-[gcc_cv_initfini_array=yes], [gcc_cv_initfini_array=no],
-[gcc_cv_initfini_array=no])])
-  enable_initfini_array=$gcc_cv_initfini_array
-])
-if test $enable_initfini_array = yes; then
-  AC_DEFINE(HAVE_INITFINI_ARRAY, 1,
-[Define .init_array/.fini_array sections are available and working.])
-fi])
-
 dnl # _gcc_COMPUTE_GAS_VERSION
 dnl # Used by gcc_GAS_VERSION_GTE_IFELSE
 dnl #
diff --git a/gcc/configure b/gcc/configure
index a373518..a23e2fa 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -10447,6 +10447,7 @@ fi
 # Restore CFLAGS from before the gcc_AC_NEED_DECLARATIONS tests.
 CFLAGS="$saved_CFLAGS"
 
+# Check if .init_array can be used with .ctors.
 # Check whether --enable-initfini-array was given.
 if test "${enable_initfini_array+set}" = set; then :
   enableval=$enable_initfini_array;
@@ -10457,16 +10458,114 @@ $as_echo_n "checking for 
.preinit_array/.init_array/.fini_array support... " >&6
 if test "${gcc_cv_initfini_array+set}" = set; then :
   $as_echo_n "(cached) " >&6
 else
+if test "x${build}" = "x${target}" ; then
 if test "$cross_compiling" = yes; then :
   gcc_cv_initfini_array=no
 else
   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
 
+#ifdef __ia64__
+/* We turn on .preinit_array/.init_array/.fini_array support for ia64
+   if it can be used.  */
 static int x = -1;
 int main (void) { return x; }
 int foo (void) { x = 0; }
 int (*fp) (void) __attribute__ ((section (".init_array"))) = foo;
+#else
+extern void abort ();
+static int count;
+
+static void
+init1005 ()
+{
+  if (count != 0)
+abort ();
+  count = 1005;
+}
+void (*const init_array1005) ()
+  __attribute__ ((section (".init_array.01005"), aligned (sizeof (void *
+  = { init1005 };
+static void
+fini1005 ()
+{
+  if (count != 1005)
+abort ();
+}
+void (*const fini_array1005) ()
+  __attribute__ ((section (".fini_array.01005"), aligned (sizeof (void *
+  = { fini1005 };
+
+static void
+ctor1007 ()
+{
+  if (count != 1005)
+abort ();
+  count = 1007;
+}
+void (*const ctors1007) ()
+  __attribute__ ((section (".ctors.64528"), aligned (sizeof (void *
+  = { ctor1007 };
+static void
+dtor1007 ()
+{
+  if (count != 1007)
+abort ();
+  count = 1005;
+}
+void (*const dtors1007) ()
+  __attribute__ ((section (".dtors.64528"), aligned (sizeof (void *
+  = { dtor1007 };
+
+static void
+init65530 ()
+{
+  if (count != 1007)
+abort ();
+  count = 65530;
+}
+void (*const init_array65530) ()
+  __attribute__ ((section (".init_array.65530"), aligned (sizeof (void *
+  = { init65530 };
+static void
+fini65530 ()
+{
+  if (count != 65530)
+abort ();
+  count = 1007;
+}
+void (*const fini_array65530) ()
+  __attribute__ ((section (".fini_array.65530"), aligned (sizeof (void *
+  = { fini65530 };
+
+static void
+ctor65535 ()
+{
+  if (count != 65530)
+abort ();
+  count = 65535;
+}
+void (*const ctors65535) ()
+  __attribute__ ((section (".ctors"), aligned (sizeof (void *
+  = { ctor65535 };
+static void
+dtor65535 ()
+{
+  if (count != 65535)
+abort ();
+  count = 65530;
+}
+void (*const dtors65535) ()
+  __attribute__ ((section (".dtors"), aligned (sizeof (void *
+  = { dtor65535 };
+
+int
+main ()
+{
+  return 0;
+}
+#endif
+
 _ACEOF
 if ac_fn_c_try_run "$LINENO"; then :
   gcc_cv_initfini_array=yes
@@ -10477,6 +10576,9 @@ rm -f core *.core core.conftest.* gmon.out bb.out 
conftest$ac_exeext \
   conftest.$ac_objext conftest.beam conftest.$ac_ext
 fi
 
+   else
+ gcc_cv_ini

Re: Dump before flag

[Xinliang David Li]

On Wed, Jun 8, 2011 at 2:06 AM, Richard Guenther
 wrote:
> On Wed, Jun 8, 2011 at 1:08 AM, Xinliang David Li  wrote:
>> The following is the patch that does the job. Most of the changes are
>> just  removing TODO_dump_func. The major change is in passes.c and
>> tree-pass.h.
>>
>> -fdump-xxx-yyy-start       <-- dump before TODO_start
>> -fdump-xxx-yyy-before    <-- dump before main pass after TODO_pass
>> -fdump-xxx-yyy-after       <-- dump after main pass before TODO_finish
>> -fdump-xxx-yyy-finish      <-- dump after TODO_finish
>
> Can we bikeshed a bit more about these names?

These names may be less confusing:

before_preparation
before
after
after_cleanup

David

> "start" and "before"
> have no semantical difference to me ... as the dump before TODO_start
> of a pass and the dump after TODO_finish of the previous pass are
> identical (hopefully ;)), maybe merge those into a -between flag?
> If you'd specify it for a single pass then you'd get both -start and -finish
> (using your naming scheme).  Splitting that dump(s) to different files
> then might make sense (not sure about the name to use).
>
> Note that I find it extremely useful to have dumping done in
> chronological order - splitting some of it to different files destroys
> this, especially a dump after TODO_start or before TODO_finish
> should appear in the same file (or we could also start splitting
> individual TODO_ output into sub-dump-files).  I guess what would
> be nice instread would be a fancy dump-file viewer that could
> show diffs, hide things like SCEV output, etc.
>
> I suppose a patch that removes the dump TODO and unconditionally
> dumps at the current point would be a good preparation for this
> enhancing patch.
>
> Richard.
>
>> The default is 'finish'.
>>
>> Does it look ok?
>>
>> Thanks,
>>
>> David
>>
>> On Tue, Jun 7, 2011 at 2:36 AM, Richard Guenther
>>  wrote:
>>> On Mon, Jun 6, 2011 at 6:20 PM, Xinliang David Li  
>>> wrote:
>
> Your patch doesn't really improve this but adds to the confusion.
>
> +  /* Override dump TODOs.  */
> +  if (dump_file && (pass->todo_flags_finish & TODO_dump_func)
> +      && (dump_flags & TDF_BEFORE))
> +    {
> +      pass->todo_flags_finish &= ~TODO_dump_func;
> +      pass->todo_flags_start |= TODO_dump_func;
> +    }
>
> and certainly writing to pass is not ok.  And the TDF_BEFORE flag
> looks misplaced as it controls TODOs, not dumping behavior.
> Yes, it's a mess right now but the above looks like a hack ontop
> of that mess (maybe because of it, but well ...).
>

 How about removing dumping TODO completely -- this can be done easily
 -- I don't understand why pass wants extra control on the dumping if
 user already asked for dumping -- it is annoying to see empty IR dump
 for a pass when I want to see it.

> At least I would have expected to also get the dump after the
> pass, not only the one before it with this dump flag.
>
> Now, why can't you look at the previous pass output for the
> before-dump (as I do usually)?

 For one thing, you need to either remember what is the previous pass,
 or dump all passes which for large files can take very long time. Even
 with all the dumps, you will need to eyeballing to find the previous
 pass which may or may not have the IR dumped.

 How about removing dump TODO?
>>>
>>> Yeah, I think this would go in the right direction.  Currently some passes
>>> do not dump function bodies because they presumably do no IL
>>> modification.  But this is certainly the minority (and some passes do not
>>> dump bodies even though they are modifying the IL ...).
>>>
>>> So I'd say we should by default dump function bodies.
>>>
>>> Note that there are three useful dumping positions (maybe four),
>>> before todo-start, after todo-start, before todo-finish and after 
>>> todo-finish.
>>> By default we'd want after todo-finish.  When we no longer dump via
>>> a TODO then we could indeed use dump-flags to control this
>>> (maybe -original for the body before todo-start).
>>>
>>> What to others think?
>>>
>>> Richard.
>>>
 Thanks,

 David


>
> Richard.
>

>>>
>>
>

[PATCH] Fix PR lto/49302

[William J. Schmidt]

This patch adds code to the cse_sincos pass to expand builtin cabs (x)
into sqrt (r*r + i*i), where r = realpart(x) and i = imagpart(x).  This
is usually handled by fold_builtin_cabs; however, PR49302 shows a case
where compile flags of -O0 -flto combined with link flags of -O2
-ffast-math allow cabs to leak through.

Test case gcc.dg/lto/20110201-1_0.c indicates that cabs is not
guaranteed to be implemented in libm, so -lm is not specified for the
test.  This patch does not present a perfect solution, in that it will
produce a builtin call to sqrt for targets that don't have a hardware
sqrt instruction.  Although sqrt should always be provided by libm, this
test case will fail since -lm is not specified.  Note that this is not
new behavior introduced by the patch, so this is probably OK; it just
restores what was happening prior to the pow/powi fixes for PR46728.

The test case has been verified fixed on x86_64-linux, and verified to
fail only with an unsatisfied reference to sqrt on powerpc64-linux.
Bootstrapped and regtested on both platforms.

OK for trunk?

Thanks,
Bill


2011-06-08  Bill Schmidt  

PR lto/49302
* tree-ssa-math-opts.c (build_and_insert_ref): New.
(gimple_expand_builtin_cabs): New.
(execute_cse_sincos): Add case for BUILT_IN_CABS.


Index: gcc/tree-ssa-math-opts.c
===
--- gcc/tree-ssa-math-opts.c(revision 174765)
+++ gcc/tree-ssa-math-opts.c(working copy)
@@ -1070,6 +1070,22 @@ build_and_insert_binop (gimple_stmt_iterator *gsi,
   return result;
 }
 
+/* Build a gimple reference operation with the given CODE and argument
+   ARG, assigning the result to a new SSA name for variable TARGET.  
+   Insert the statement prior to GSI's current position, and return
+   the fresh SSA name.*/
+
+static inline tree
+build_and_insert_ref (gimple_stmt_iterator *gsi, location_t loc, tree type,
+ tree target, enum tree_code code, tree arg0)
+{
+  tree result = make_ssa_name (target, NULL);
+  gimple stmt = gimple_build_assign (result, build1 (code, type, arg0));
+  gimple_set_location (stmt, loc);
+  gsi_insert_before (gsi, stmt, GSI_SAME_STMT);
+  return result;
+}
+
 /* ARG0 and ARG1 are the two arguments to a pow builtin call in GSI
with location info LOC.  If possible, create an equivalent and
less expensive sequence of statements prior to GSI, and return an
@@ -1306,6 +1322,41 @@ gimple_expand_builtin_pow (gimple_stmt_iterator *g
   return NULL_TREE;
 }
 
+/* ARG is the argument to a cabs builtin call in GSI with location info
+   LOC.  Create a sequence of statements prior to GSI that calculates
+   sqrt(R*R + I*I), where R and I are the real and imaginary components
+   of ARG, respectively.  Return an expression holding the result.  */
+
+static tree
+gimple_expand_builtin_cabs (gimple_stmt_iterator *gsi, location_t loc, tree 
arg)
+{
+  tree target, real_part, imag_part, addend1, addend2, sum, result, sqrtfn;
+  tree type = TREE_TYPE (arg);
+  
+  gcc_assert (TREE_CODE (type) == COMPLEX_TYPE);
+  type = TREE_TYPE (type);
+  sqrtfn = mathfn_built_in (type, BUILT_IN_SQRT);
+
+  if (!sqrtfn)
+return NULL_TREE;
+
+  target = create_tmp_var (type, "cabs");
+  add_referenced_var (target);
+
+  real_part = build_and_insert_ref (gsi, loc, type, target,
+   REALPART_EXPR, arg);
+  addend1 = build_and_insert_binop (gsi, loc, target, MULT_EXPR,
+   real_part, real_part);
+  imag_part = build_and_insert_ref (gsi, loc, type, target, 
+   IMAGPART_EXPR, arg);
+  addend2 = build_and_insert_binop (gsi, loc, target, MULT_EXPR,
+   imag_part, imag_part);
+  sum = build_and_insert_binop (gsi, loc, target, PLUS_EXPR, addend1, addend2);
+  result = build_and_insert_call (gsi, loc, &target, sqrtfn, sum);
+
+  return result;
+}
+
 /* Go through all calls to sin, cos and cexpi and call execute_cse_sincos_1
on the SSA_NAME argument of each of them.  Also expand powi(x,n) into
an optimal number of multiplies, when n is a constant.  */
@@ -1388,6 +1439,34 @@ execute_cse_sincos (void)
}
  break;
 
+   CASE_FLT_FN (BUILT_IN_CABS):
+ /* This code is usually redundant with fold_builtin_cabs.
+There is a possible edge case where compile flags
+include -O0 -flto, while link flags include -O2
+-ffast-math.  In this case, the fold does not occur
+and cabs can leak through.  Since it is not guaranteed
+to be implemented in libm on all targets, we need to
+lower it here.
+
+See test case gcc.dg/lto/20110201-1_0.c.  */
+ if (!flag_unsafe_math_optimizations
+ || !optimize_function_for_speed_p (cfun))
+ 

Re: libobjc: Remove Traditional Objective-C runtime API

[Mike Stump]

On Jun 8, 2011, at 1:25 AM, Nicola Pero wrote:
> But - you're right that we should bump it, so I bumped it :-)
> I suppose we could bump it again when we get into phase 3, when we're finished
> with the changes.

No.  The next number is for the next release, and ideally, we want to sit on it 
for another 10 years or so.  We offer no compatibility before the RM says, done 
with the release.  Up until then, you can twiddle, after that, no more changes 
to the abi, though, you can bug fix it.

Re: libobjc: Remove Traditional Objective-C runtime API

[Nicola Pero]

> No.  The next number is for the next release, and ideally, we want to sit on 
> it for another 10 years or so.  We offer no compatibility before the RM says, 
> done with the release.  Up until then, you can twiddle, after that, no more 
> changes to the abi, though, you can bug fix it.

Sounds good.  That was my original understanding - one ABI version per release. 
 For GCC 4.6.0 we bumped
the version number after the end of phase 1, which made sense to me, so I was 
expecting we'd do the same
for GCC 4.7.0.

But, as Jakub seemed to urge me to bump the version number right now, I got 
confused about whether there was
an expectation of more than one bump per release; maybe to distinguish 
snapshots from one another or
something like that ?

Anyhow, we have done the bumping well in advance of the 4.7.0 release and we 
all seem to agree on what
we should be doing (one bump per release), so it's all good. ;-)

Thanks

[C++ PATCH] Add chain_next GTY markup to struct tinst_level

[Jakub Jelinek]

Hi!

We shouldn't recurse in GC to mark tinst_level chain,
it is IMHO better to iterate through the chain instead.
Bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk?

2011-06-08  Jakub Jelinek  

* cp-tree.h (struct tinst_level): Add chain_next GTY
markup.

--- gcc/cp/cp-tree.h.jj 2011-05-31 08:03:00.0 +0200
+++ gcc/cp/cp-tree.h2011-06-08 16:31:28.0 +0200
@@ -4635,7 +4635,7 @@ struct cp_declarator {
 };
 
 /* A level of template instantiation.  */
-struct GTY(()) tinst_level {
+struct GTY((chain_next ("%h.next"))) tinst_level {
   /* The immediately deeper level in the chain.  */
   struct tinst_level *next;
 

Jakub

[committed] Fix integer-typedef.C testcase (PR testsuite/49323)

[Jakub Jelinek]

Hi!

This testcase suffered from the same issues as cdtor-1.C testcase recently.
Fixed thusly, regtested on x86_64-linux and i686-linux, committed to trunk
as obvious.

2011-06-08  Jakub Jelinek  

PR testsuite/49323
* g++.dg/debug/dwarf2/integer-typedef.C: Add -fno-merge-debug-strings
to dg-options, match also DW_AT_linkage_name.

--- gcc/testsuite/g++.dg/debug/dwarf2/integer-typedef.C.jj  2011-06-08 
08:53:13.0 +0200
+++ gcc/testsuite/g++.dg/debug/dwarf2/integer-typedef.C 2011-06-08 
13:48:39.0 +0200
@@ -1,5 +1,5 @@
 // Origin: PR debug/49130
-// { dg-options "-g -dA" }
+// { dg-options "-g -dA -fno-merge-debug-strings" }
 
 typedef long unsigned int size_t;
 static const size_t foo = 2048;
@@ -24,5 +24,5 @@ main()
   s1.f(10);
 }
 
-// { dg-final {scan-assembler-times "\[^\n\r\]*DW_AT_name: \"S<2048ul>\"" 1 } }
-// { dg-final {scan-assembler-times "\[^\n\r\]*DW_AT_MIPS_linkage_name: 
\"_ZN1SILm2048EE1fEm\"" 1 } }
+// { dg-final {scan-assembler-times "\"S<2048ul>.0\"\[^\n\r\]* DW_AT_name" 1 } 
}
+// { dg-final {scan-assembler-times "\"_ZN1SILm2048EE1fEm.0\"\[^\n\r\]* 
DW_AT_\[MIPS_\]*linkage_name" 1 } }

Jakub

Go patch committed: Fix type comparison

[Ian Lance Taylor]

This patch to the Go frontend fixes a dumb mistake I made: I compared
the TYPE_SIZE pointers rather than the actual type size.  Bootstrapped
and ran Go testsuite on x86_64-unknown-linux-gnu.  Committed to
mainline.

Ian

diff -r 292aa99c6436 go/expressions.cc
--- a/go/expressions.cc	Tue May 31 11:14:19 2011 -0700
+++ b/go/expressions.cc	Wed Jun 08 11:52:32 2011 -0700
@@ -754,8 +754,13 @@
 	ret = NULL_TREE;
 }
 
-  if ((TYPE_UNSIGNED(val_type) && !TYPE_UNSIGNED(bound_type))
-  || TYPE_SIZE(val_type) > TYPE_SIZE(bound_type))
+  HOST_WIDE_INT val_type_size = int_size_in_bytes(val_type);
+  HOST_WIDE_INT bound_type_size = int_size_in_bytes(bound_type);
+  go_assert(val_type_size != -1 && bound_type_size != -1);
+  if (val_type_size > bound_type_size
+  || (val_type_size == bound_type_size
+	  && TYPE_UNSIGNED(val_type)
+	  && !TYPE_UNSIGNED(bound_type)))
 {
   tree max = TYPE_MAX_VALUE(bound_type);
   tree big = fold_build2_loc(loc, GT_EXPR, boolean_type_node, val,

Re: [testsuite] skip ARM tests with conflicting options

[Mike Stump]

On Jun 8, 2011, at 8:28 AM, Janis Johnson wrote:
> The big question is whether such a test should be run for all multilibs
> that might possibly pass the test, or only for default and for mulitlibs
> that provide the same options.

Here, reasonable people may disagree.  I suspect in the end, we'll have both 
solutions, and then individual testcases will make their own decision.  A 
collection of testcases will tend to follow the same convention...  So, for 
objective-c, we face the same sort of issue, and we do what we do, and that 
isn't necessarily going to match exactly what for example the gcc.arm does, nor 
I suspect are we going to change just because gcc.arm changes.  I think it 
makes sense to cache as much as possible and skip conflicts.  Taking off my 
testsuite maintainer hat, I think soft conflicts with defaults should mean we 
run it, and punch in the options we want.  If there is something that prohibits 
that from working (hard conflict), it should be skipped.  Feel free to ignore 
this, as I don't know that this is the best answer.

I'd like to think that dg-skip-if and dg-require-effective-target and general 
target selection is beefy enough to do everything we need it to, or can be made 
to.

Re: [pph] Stream TREE_TYPE for identifier node (issue4550121)

[Steven Bosscher]

On Wed, Jun 8, 2011 at 4:12 PM, Diego Novillo wrote:
 That seems unlikely, as identifiers do not have a type. There is some
 TREE_TYPE abuse in cp-tree.h, perhaps you should find out what you're
 streaming.
>>>
>>> It's used by the C++ parser, so it needs to be streamed in pph.
>>
>> Yes, but you should not stream TREE_TYPE but use the accessor macro
>> that uses TREE_TYPE. Otherwise, if someone gets around to making
>> IDENTIFIER nodes non-typed trees (and update cp-tree.h accordingly)
>> the streaming will break.
>
> It does, actually:
>
> cp/rtti.c:
> bool
> emit_tinfo_decl (tree decl)
> {
>  tree type = TREE_TYPE (DECL_NAME (decl));

Well, I wasn't saying that TREE_TYPE isn't used, just that it is not
actually TREE_TYPE.

Not very thorough, but consider this:

stevenb@gcc17:~/devel/trunk/gcc$ egrep "TREE_TYPE.*DECL_NAME" *.[ch]
{fortran,java,ada/gcc-interface,cp,objc}/*.[ch]
fortran/f95-lang.c: TYPE_NAME (TREE_TYPE (decl)) = DECL_NAME (decl);
cp/cp-tree.h:  (DECL_CONV_FN_P (FN) ? TREE_TYPE (DECL_NAME (FN)) : NULL_TREE)
cp/decl2.c:   tree underlying_type = TREE_TYPE (DECL_NAME (decl));
cp/decl2.c: (decl, type_visibility (TREE_TYPE (DECL_NAME (decl;
cp/decl2.c:   && CLASS_TYPE_P (TREE_TYPE (DECL_NAME (decl)))
cp/decl2.c:   && !CLASSTYPE_VISIBILITY_SPECIFIED (TREE_TYPE
(DECL_NAME (decl
cp/decl2.c:  tree type = TREE_TYPE (DECL_NAME (decl));
cp/decl.c:if (TREE_TYPE (DECL_NAME (decl)) && TREE_TYPE (decl) != type)
cp/repo.c:  type = TREE_TYPE (DECL_NAME (decl));
cp/rtti.c:  tree type = TREE_TYPE (DECL_NAME (decl));

The one in fortran looks like a mistake (this is in pushdecl which was
copy-and-pasted long ago from treelang or something). The
documentation in doc/generic.text is pretty clear about it: TYPE_NAME
of a TYPE_DECL is not an IDENTIFIER node. There should probably be a
checker for that, some kind of negative tree code check perhaps...

The rest are all in cp/.  It looks like g++ uses TREE_TYPE as a cache
for name lookups. Perhaps Jason can comment. Obviously not a front end
I know very well, but let's look at them one at a time:

cp/cp-tree.h:  (DECL_CONV_FN_P (FN) ? TREE_TYPE (DECL_NAME (FN)) : NULL_TREE)

Apparently g++ puts the type of an operator in TREE_TYPE of an
IDENTIFIER_NODE. This should probably be using
REAL_IDENTIFIER_TYPE_VALUE() instead of TREE_TYPE().


cp/decl.c:if (TREE_TYPE (DECL_NAME (decl)) && TREE_TYPE (decl) != type)

This is in a warning for a type declaration shadowing a local or class
scope.  Should use identifier_type_value (or
REAL_IDENTIFIER_TYPE_VALUE but I think that's supposed to be used
directly only in name-lookup.c??)


cp/decl2.c:   tree underlying_type = TREE_TYPE (DECL_NAME (decl));
cp/decl2.c: (decl, type_visibility (TREE_TYPE (DECL_NAME (decl;
cp/decl2.c:   && CLASS_TYPE_P (TREE_TYPE (DECL_NAME (decl)))
cp/decl2.c:   && !CLASSTYPE_VISIBILITY_SPECIFIED (TREE_TYPE
(DECL_NAME (decl
cp/decl2.c:  tree type = TREE_TYPE (DECL_NAME (decl));
cp/repo.c:  type = TREE_TYPE (DECL_NAME (decl));
cp/rtti.c:  tree type = TREE_TYPE (DECL_NAME (decl));

All of these are covered by a check on DECL_TINFO_P. I am not sure
what that means but probably these should also be using
identifier_type_value or REAL_IDENTIFIER_TYPE_VALUE instead of
TREE_TYPE. Jason?


Anyway, it seems that there are already a lot of places where
TREE_TYPE is used instead of a separate accessor macro for this
overloaded meaning of TREE_TYPE on IDENTIFIER_NODEs. That is no reason
to further confuse things with pph. It seems to me that in the long
run tree_identifier could (should) be made a non-tree_typed tree...

Would you be willing to try if it is sufficient to only stream
REAL_IDENTIFIER_TYPE_VALUE?

Ciao!
Steven

Re: [testsuite] skip ARM tests with conflicting options

[Mike Stump]

On Jun 8, 2011, at 3:39 AM, Richard Earnshaw wrote:
> I'm worried by this whole approach of command-line checking.

Right, and this was essentially my point originally.  Luckily there is enough 
beef I think behind the curtains to do everything that needs doing without 
worrying about adding yet more infrastructure.

> Perhaps a better approach would be a new dg- test

A new mechanism would be necessary if the existing ones turn out to be poor or 
unworkable.  To be concrete, could you give a specific example of something 
that doesn't work well with the existing mechanisms?

Re: [build] Define HAVE_GAS_HIDDEN on Darwin

[Mike Stump]

On Jun 8, 2011, at 2:29 AM, Rainer Orth wrote:
> The Darwin parts of the previous versions have already been approved,
> but I'd appreciate if Mike could have a look at the changes.  Ok for
> mainline?

Ok.

Re: [C++ PATCH] Add chain_next GTY markup to struct tinst_level

[Jason Merrill]

OK.

Jason

Re: [build] Define HAVE_GAS_HIDDEN on Darwin

[Mike Stump]

On Jun 8, 2011, at 2:29 AM, Rainer Orth wrote:
> Bootstrapped without regressions on i386-apple-darwin9.8.0.
> powerpc-apple-darwin9.8.0 bootstrap is still running.  Unfortunately,
> Darwin seems to be exceedingly unreliable under load: tests randomly
> time out and work again the next time.  This doesn't happen for me on
> any other platform.

:-(  There are one or two testcases that are slightly less than deterministic 
(in java), though, for me, they seem always to be deterministic.  I wonder if 
the actual time required for a testcase is just too close to the margin and 
failing because you gave it a loaded machine.  In my experience, if you do a 
normal -j check run, and another -j make run (unrelated), we will then time out 
things, simply because people say, I have 300 seconds to run a testcase, so I 
am going to use 100% of the machine for 298 seconds and if I don't get it, I'm 
going to fail.  :-(  Nasty.  I think any testcase that takes more than 30 
seconds should be shot on sight, then you can have 3 running at the same time, 
and never fail on time outs.

Feel free to name the testcases that gave you problems...  Maybe someone has 
ideas.  Another thought, change the 300 to 600, and see if it is then perfectly 
reliable.  If so, well...  Maybe the compiler is just slower than it used to 
be.  :-(

[patch, testsuite] Fix PR 49191 with test for STRICT_ALIGNMENT

[Steve Ellcey]

Here is a patch to skip gcc.dg/memcpy-3.c on platforms that define
STRICT_ALIGNMENT.  It adds a new check_effective routine,
check_effective_target_strict_align that looks for a warning that will
only be produced on platforms that define STRICT_ALIGNMENT.

Technically, the test may not work if the default alignment for char
variables is the same as __BIGGEST_ALIGNMENT__ but hopefully that is a
rare or non-existent case.  If it does happen we can modify
check_effective_target_strict_align to explicitly check for that
platform.

This new check should be useful for other tests as well but for now
I have just modified gcc.dg/memcpy-3.c to use it.  I verified that
this patch makes gcc.dg/memcpy-3.c UNSUPPORTED on IA64 HP-UX and I will
verify other platforms tonight including X86 Linux where STRICT_ALIGNMENT
is not defined before checking it in.

OK for checkin once my testing is done?

Steve Ellcey
s...@cup.hp.com


2011-06-08  Steve Ellcey  

PR middle-end/49191
* lib/target-supports.exp (check_effective_target_strict_align): New.
* gcc.dg/memcpy-3.c: Add dg-require-effective-target strict_align.

Index: lib/target-supports.exp
===
--- lib/target-supports.exp (revision 174336)
+++ lib/target-supports.exp (working copy)
@@ -3901,3 +3901,11 @@
 return 1
 }
 
+proc check_effective_target_strict_align {} {
+return [check_no_compiler_messages strict_align assembly {
+   char *y;
+   typedef char __attribute__ ((__aligned__(__BIGGEST_ALIGNMENT__))) c;
+   c *z;
+   void foo(void) { z = (c *) y; }
+} "-Wcast-align"]
+}
Index: gcc.dg/memcpy-3.c
===
--- gcc.dg/memcpy-3.c   (revision 174336)
+++ gcc.dg/memcpy-3.c   (working copy)
@@ -1,5 +1,6 @@
 /* { dg-do compile } */
 /* { dg-options "-O -fdump-tree-optimized" } */
+/* { dg-require-effective-target strict_align } */
 
 int get_int(const void *p)
 {

Re: [patch, testsuite] Fix PR 49191 with test for STRICT_ALIGNMENT

[Jakub Jelinek]

On Wed, Jun 08, 2011 at 01:03:53PM -0700, Steve Ellcey wrote:
> 2011-06-08  Steve Ellcey  
> 
>   PR middle-end/49191
>   * lib/target-supports.exp (check_effective_target_strict_align): New.
>   * gcc.dg/memcpy-3.c: Add dg-require-effective-target strict_align.

Isn't the test backwards, i.e. doesn't
{ dg-require-effective-target strict_align }
actually mean !STRICT_ALIGNMENT?

> Index: lib/target-supports.exp
> ===
> --- lib/target-supports.exp   (revision 174336)
> +++ lib/target-supports.exp   (working copy)
> @@ -3901,3 +3901,11 @@
>  return 1
>  }
>  
> +proc check_effective_target_strict_align {} {
> +return [check_no_compiler_messages strict_align assembly {
> + char *y;
> + typedef char __attribute__ ((__aligned__(__BIGGEST_ALIGNMENT__))) c;
> + c *z;
> + void foo(void) { z = (c *) y; }
> +} "-Wcast-align"]
> +}
> Index: gcc.dg/memcpy-3.c
> ===
> --- gcc.dg/memcpy-3.c (revision 174336)
> +++ gcc.dg/memcpy-3.c (working copy)
> @@ -1,5 +1,6 @@
>  /* { dg-do compile } */
>  /* { dg-options "-O -fdump-tree-optimized" } */
> +/* { dg-require-effective-target strict_align } */
>  
>  int get_int(const void *p)
>  {

Jakub

Re: [patch, testsuite] Fix PR 49191 with test for STRICT_ALIGNMENT

[Steve Ellcey]

On Wed, 2011-06-08 at 22:08 +0200, Jakub Jelinek wrote:
> On Wed, Jun 08, 2011 at 01:03:53PM -0700, Steve Ellcey wrote:
> > 2011-06-08  Steve Ellcey  
> > 
> > PR middle-end/49191
> > * lib/target-supports.exp (check_effective_target_strict_align): New.
> > * gcc.dg/memcpy-3.c: Add dg-require-effective-target strict_align.
> 
> Isn't the test backwards, i.e. doesn't
> { dg-require-effective-target strict_align }
> actually mean !STRICT_ALIGNMENT?

You are right.  What do you think I should do, reverse the test or just
rename it?  I would be inclined to just rename it, maybe:

dg-require-effective-target non_strict_align

Steve Ellcey
s...@cup.hp.com

Re: [patch, testsuite] Fix PR 49191 with test for STRICT_ALIGNMENT

[Jakub Jelinek]

On Wed, Jun 08, 2011 at 01:16:26PM -0700, Steve Ellcey wrote:
> On Wed, 2011-06-08 at 22:08 +0200, Jakub Jelinek wrote:
> > On Wed, Jun 08, 2011 at 01:03:53PM -0700, Steve Ellcey wrote:
> > > 2011-06-08  Steve Ellcey  
> > > 
> > >   PR middle-end/49191
> > >   * lib/target-supports.exp (check_effective_target_strict_align): New.
> > >   * gcc.dg/memcpy-3.c: Add dg-require-effective-target strict_align.
> > 
> > Isn't the test backwards, i.e. doesn't
> > { dg-require-effective-target strict_align }
> > actually mean !STRICT_ALIGNMENT?
> 
> You are right.  What do you think I should do, reverse the test or just
> rename it?  I would be inclined to just rename it, maybe:
> 
> dg-require-effective-target non_strict_align

Yeah, either that, or reverse the test and then
{ dg-do run { target { !strict_align } } } */
(if that is the right syntax).

Jakub

Re: [testsuite] skip ARM tests with conflicting options

[Janis Johnson]

On 06/08/2011 12:30 PM, Mike Stump wrote:
> On Jun 8, 2011, at 8:28 AM, Janis Johnson wrote:
>> The big question is whether such a test should be run for all multilibs
>> that might possibly pass the test, or only for default and for mulitlibs
>> that provide the same options.
> 
> Here, reasonable people may disagree.  I suspect in the end, we'll have
> both solutions, and then individual testcases will make their own decision.
> A collection of testcases will tend to follow the same convention...  So, for 
> objective-c, we face the same sort of issue, and we do what we do, and that 
> isn't
> necessarily going to match exactly what for example the gcc.arm does, nor I 
> suspect
> are we going to change just because gcc.arm changes.  I think it makes sense 
> to
> cache as much as possible and skip conflicts.  Taking off my testsuite 
> maintainer
> hat, I think soft conflicts with defaults should mean we run it, and punch in 
> the
> options we want.  If there is something that prohibits that from working (hard
> conflict), it should be skipped.  Feel free to ignore this, as I don't know 
> that
> this is the best answer.

I agree that the answer will be different for different tests.

The problem is that in the case of a "soft conflict", the multilib options
go at the end of the compile line and override the options given in the
test via dg-options.  That's OK if dg-options is providing defaults for when
there is no similar option in the multilib options, but a problem if the test
depends on the flags from dg-options being used, as when a dg-final checks
for specific code generation.  Then we have the choice of running the test
only with the specific values specified in the test, or allowing a range of
values, for mfpu or march or whatever; that gets trickier but we have the
tools to do it.

> I'd like to think that dg-skip-if and dg-require-effective-target and general
> target selection is beefy enough to do everything we need it to, or can be 
> made to.

Right, it's easy to add new effective targets, I don't think we need new test
directives.

Janis

[pph] Test cleanup (issue4572050)

[Lawrence Crowl]

Update the test suite to reflect recent fixes and merges from trunk.

The following changes happened in this patch.

Conversion of a compilation failure to an assembly diff failure:

remove the dg comments and add the comment // pph asm xdiff

Conversion of a ICE to a BOGUS

change the dg-xfail-if line from ICE to BOGUS
change the dg-bogus line from the ICE message to the BOGUS message
remove the dg-prune-output lines corresponding to the ICE
(dg knows to remove them for errors, but not for ICEs)

Update line numbers from a merge (or other edits to regular sources)
change the line number from old to new as reflected in the test log

The output of make check filtered through the following sed command
should yield no FAIL and no XPASS.

sed -e '
/-fpph-map=pph.map/ ! {
/^XPASS: .*test for bogus messages/ d
/^XPASS: .*test for excess errors/  d
}

/^#/p
/^ERROR: /  p
/^XFAIL: /  p
/^XPASS: /  p
/^FAIL: /   p

d
'

The same command works to filter the log file to its essential record
of pass/fail.  In particular, it enables listing XFAILs that need work.


Index: gcc/testsuite/ChangeLog.pph

2011-06-08  Lawrence Crowl 

* lib/dg-pph.exp (dg-pph-pos): Stop redundantly reporting a missing
pph assembly as an xfail when its compile xfails.
* g++.dg/pph/x1typerefs.cc: Replace ICE xfail with a bogus error xfail.
* g++.dg/pph/x1tmplclass.cc: Likewise.
* g++.dg/pph/x1autometh.cc: Replace ICE xfail with an assembly diff
xfail.
* g++.dg/pph/x1special.cc: Remove ICE xfail.
* g++.dg/pph/x1functions.cc: Correct xfail to BOGUS rather than ERROR.
Remove leftover pruning from previous ICE.
* g++.dg/pph/x1template.cc: Update line number of ICE.
* g++.dg/pph/x1variables.cc: Update line number of BOGUS.


Index: gcc/testsuite/lib/dg-pph.exp
===
--- gcc/testsuite/lib/dg-pph.exp(revision 174789)
+++ gcc/testsuite/lib/dg-pph.exp(working copy)
@@ -94,9 +94,7 @@ proc dg-pph-pos { subdir test options ma
 # Quit if it did not compile successfully.
 if { ![file_on_host exists "$bname.s"] } {
# Expect assembly to be missing when the compile is an expected fail.
-   if { [llength [grep $test "dg-xfail-if.*-fpph-map"]] } {
-   xfail "$nshort $options (pph assembly missing)"
-   } else {
+   if { ![llength [grep $test "dg-xfail-if.*-fpph-map"]] } {
fail "$nshort $options (pph assembly missing)"
}
return
Index: gcc/testsuite/g++.dg/pph/x1typerefs.cc
===
--- gcc/testsuite/g++.dg/pph/x1typerefs.cc  (revision 174789)
+++ gcc/testsuite/g++.dg/pph/x1typerefs.cc  (working copy)
@@ -1,6 +1,5 @@
-// { dg-xfail-if "ICE" { "*-*-*" } { "-fpph-map=pph.map" } }
-// { dg-bogus "c1typerefs.h:11:18: internal compiler error: Segmentation 
fault" "" { xfail *-*-* } 0 }
-// { dg-prune-output "In file included from " }
+// { dg-xfail-if "BOGUS" { "*-*-*" } { "-fpph-map=pph.map" } }
+// { dg-bogus "c1typerefs.h:11:18: error: cannot convert 'const 
std::type_info.' to 'const std::type_info.' in initialization" "" { xfail *-*-* 
} 0 }
 
 #include "x1typerefs.h"
 
Index: gcc/testsuite/g++.dg/pph/x1autometh.cc
===
--- gcc/testsuite/g++.dg/pph/x1autometh.cc  (revision 174789)
+++ gcc/testsuite/g++.dg/pph/x1autometh.cc  (working copy)
@@ -1,6 +1,4 @@
-// { dg-xfail-if "ICE" { "*-*-*" } { "-fpph-map=pph.map" } }
-// { dg-bogus "x1autometh.h:8:1: internal compiler error: Segmentation fault" 
"" { xfail *-*-* } 0 }
-// { dg-prune-output "In file included from " }
+// pph asm xdiff
 
 #include "x1autometh.h"
 
Index: gcc/testsuite/g++.dg/pph/x1special.cc
===
--- gcc/testsuite/g++.dg/pph/x1special.cc   (revision 174789)
+++ gcc/testsuite/g++.dg/pph/x1special.cc   (working copy)
@@ -1,7 +1,3 @@
-// { dg-xfail-if "ICE" { "*-*-*" } { "-fpph-map=pph.map" } }
-// { dg-bogus "x1special.h:10:5: internal compiler error: Segmentation fault" 
"" { xfail *-*-* } 0 }
-// { dg-prune-output "In file included from " }
-
 #include "x1special.h"
 
 B b(1);
Index: gcc/testsuite/g++.dg/pph/x1functions.cc
===
--- gcc/testsuite/g++.dg/pph/x1functions.cc (revision 174789)
+++ gcc/testsuite/g++.dg/pph/x1functions.cc (working copy)
@@ -1,8 +1,5 @@
-// { dg-xfail-if "ERROR" { "*-*-*" } { "-fpph-map=pph.map" } }
+// { dg-xfail-if "BOGUS" { "*-*-*" } { "-fpph-map=pph.map" } }
 // { dg-bogus "'mbr_decl_inline' was not declared in this scope" "" { xfail 
*-*-* } 0 }
-// { dg-prune-output "In file included from " }
-// { dg-prune-output "I

Re: [patch, testsuite] Fix PR 49191 with test for STRICT_ALIGNMENT

[Steve Ellcey]

On Wed, 2011-06-08 at 22:19 +0200, Jakub Jelinek wrote:
> On Wed, Jun 08, 2011 at 01:16:26PM -0700, Steve Ellcey wrote:
> > On Wed, 2011-06-08 at 22:08 +0200, Jakub Jelinek wrote:
> > > On Wed, Jun 08, 2011 at 01:03:53PM -0700, Steve Ellcey wrote:
> > > > 2011-06-08  Steve Ellcey  
> > > > 
> > > > PR middle-end/49191
> > > > * lib/target-supports.exp 
> > > > (check_effective_target_strict_align): New.
> > > > * gcc.dg/memcpy-3.c: Add dg-require-effective-target 
> > > > strict_align.
> > > 
> > > Isn't the test backwards, i.e. doesn't
> > > { dg-require-effective-target strict_align }
> > > actually mean !STRICT_ALIGNMENT?
> > 
> > You are right.  What do you think I should do, reverse the test or just
> > rename it?  I would be inclined to just rename it, maybe:
> > 
> > dg-require-effective-target non_strict_align
> 
> Yeah, either that, or reverse the test and then
> { dg-do run { target { !strict_align } } } */
> (if that is the right syntax).
> 
>   Jakub

Renaming it seems simpler.  If we reverse the test, I can't just return
the result of check_no_compiler_messages, I need to save the result and
reverse the return value.  Then in the actual tests we can't use
dg-require-effective-target but need to modify the dg-do line to do the
check and it will probably always include the '!' to (re-)negate the
check.  It can be done but renaming the test seems a lot simpler.

Steve Ellcey
s...@cup.hp.com

Re: [pph] Clean up PPH tests (issue4572042)

[Lawrence Crowl]

On 6/7/11, Diego Novillo  wrote:
> After getting new failures due to an unrelated fix, I think this will
> be more trouble than it's worth.
>
> First, we can't get rid of the XPASSes, so those will always be noisy.

Remove all the noise with:

sed -e '
/-fpph-map=pph.map/ ! {
/^XPASS: .*test for bogus messages/ d
/^XPASS: .*test for excess errors/  d
}

/^#/p
/^ERROR: /  p
/^XFAIL: /  p
/^XPASS: /  p
/^FAIL: /   p

d
'

>
> Second, some XPASSes will need to be unmarked because we just fixed
> the underlying problem.

That is how we know that what progress we have made.  These should
be reflected in the work list.

>
> Third, we are at such an early stage, that fixes to a test case will
> generally expose failures in other already failing tests, but these
> failures will be in a different place.  So more noise.

That is now we expose remaining tasks.  These should be reflected
in the work list.

>
> I really think that for now the easiest way to keep track of this is
> to have a clean build to compare against.

But the clean build isn't a decent comparison.  The existing tools
only compare against whether or not tests fail.  They fail to
report that a test failed for different reasons.  Given that there
are only twelve tests for which there is a concern, I think we are
better off know where we are.

-- 
Lawrence Crowl

Re: [build] Define HAVE_GAS_HIDDEN on Darwin

[Jason Merrill]

On 06/08/2011 05:29 AM, Rainer Orth wrote:

Once I got around to it, this proved to be remarkably easy, as can be
seen below.


Yes, much better.  The dwarf2asm change is OK.

Jason

Re: [PATCH] c-pragma: adding a data field to pragma_handler

[Pierre Vittet]

I have written a test for this patch and run it (it works correctly). I 
guess there is no reason why it should not be accepted now.
To recap, this patch add a void * data field to the pragma handler, 
allowing to pass extra data. If we want to use this field, we need to 
use the function c_register_pragma_with_data or 
c_register_pragma_with_expansion_and_data. The old 
c_register_pragma(_with_expansion) is kept compatible.


I give two diff and two ChangeLog, the first are for the patch itself, 
the second are for the test.


I have tried to make things as good as possible, if there is a remark, 
please, send me it. Especially, I am not sure about the format of my 
ChangeLog, if there is an issue, I am ready to change it.


Changelog gcc:

2011-06-08  Pierre Vittet  

* c-pragma.h (pragma_handler_1arg, pragma_handler_2arg,
gen_pragma_handler, internal_pragma_handler, c_register_pragma,
c_register_pragma_with_data, c_register_pragma_with_expansion,
c_register_pragma_with_expansion_and_data): allows to add data to a
pragma handler using a new c_register. Old c_register keep old
behaviour for compatibility.
* c-pragma.c (registered_pragmas, c_register_pragma_1,
c_register_pragma, c_register_pragma_with_data,
c_register_pragma_with_expansion,
c_register_pragma_with_expansion_and_data, c_invoke_pragma_handler,
init_pragma): allows to add data to a pragma handler using a new
c_register. Old registers keep old behaviour for compatibility.

Changelog testsuite

2011-06-08  Pierre Vittet  

* g++.dg/plugin/pragma_plugin_with_data.c: New test.


Thanks!

Pierre Vittet
Index: gcc/c-family/c-pragma.c
===
--- gcc/c-family/c-pragma.c (revision 174521)
+++ gcc/c-family/c-pragma.c (working copy)
@@ -1148,12 +1148,12 @@ handle_pragma_float_const_decimal64 (cpp_reader *A
 }
 
 /* A vector of registered pragma callbacks.  */
+/* This is never freed as we need it during the whole execution.  */
+DEF_VEC_O (internal_pragma_handler);
+DEF_VEC_ALLOC_O (internal_pragma_handler, heap);
 
-DEF_VEC_O (pragma_handler);
-DEF_VEC_ALLOC_O (pragma_handler, heap);
+static VEC(internal_pragma_handler, heap) *registered_pragmas;
 
-static VEC(pragma_handler, heap) *registered_pragmas;
-
 typedef struct
 {
   const char *space;
@@ -1216,7 +1216,7 @@ c_pp_lookup_pragma (unsigned int id, const char **
 
 static void
 c_register_pragma_1 (const char *space, const char *name,
-pragma_handler handler, bool allow_expansion)
+ internal_pragma_handler ihandler, bool allow_expansion)
 {
   unsigned id;
 
@@ -1235,8 +1235,9 @@ c_register_pragma_1 (const char *space, const char
 }
   else
 {
-  VEC_safe_push (pragma_handler, heap, registered_pragmas, &handler);
-  id = VEC_length (pragma_handler, registered_pragmas);
+  VEC_safe_push (internal_pragma_handler, heap, registered_pragmas,
+ &ihandler);
+  id = VEC_length (internal_pragma_handler, registered_pragmas);
   id += PRAGMA_FIRST_EXTERNAL - 1;
 
   /* The C++ front end allocates 6 bits in cp_token; the C front end
@@ -1248,28 +1249,90 @@ c_register_pragma_1 (const char *space, const char
allow_expansion, false);
 }
 
+/* Register a C pragma handler, using a space and a name.  It disallows pragma
+expansion (if you want it, use c_register_pragma_with_expansion instead).  */
 void
-c_register_pragma (const char *space, const char *name, pragma_handler handler)
+c_register_pragma (const char *space, const char *name,
+   pragma_handler_1arg handler)
 {
-  c_register_pragma_1 (space, name, handler, false);
+  internal_pragma_handler ihandler;
+
+  ihandler.handler.handler_1arg = handler;
+  ihandler.extra_data = false;
+  ihandler.data = NULL;
+  c_register_pragma_1 (space, name, ihandler, false);
 }
 
+/* Register a C pragma handler, using a space and a name, it also carries an
+extra data field which can be used by the handler.  It disallows pragma
+expansion (if you want it, use c_register_pragma_with_expansion instead).  */
 void
+c_register_pragma_with_data (const char *space, const char *name,
+ pragma_handler_2arg handler, void * data)
+{
+  internal_pragma_handler ihandler;
+
+  ihandler.handler.handler_2arg = handler;
+  ihandler.extra_data = true;
+  ihandler.data = data;
+  c_register_pragma_1 (space, name, ihandler, false);
+}
+
+/* Register a C pragma handler, using a space and a name.  It allows pragma
+expansion as in the following exemple:
+  #define NUMBER 10
+  #pragma count (NUMBER)
+Name expansion is still disallowed.  */
+void
 c_register_pragma_with_expansion (const char *space, const char *name,
- pragma_handler handler)
+ pragma_handler_1arg handler)
 {
-  c_register_pragma_1

C++ PATCH for c++/49107 (excessive instantiation due to noexcept)

[Jason Merrill]

49107 is an issue with the addition of noexcept to the standard library 
causing extra instantiations, to the point that code that worked before 
doesn't work now due to circular dependency.  Someone suggested that to 
avoid this problem we could defer instantiation of noexcept-specifiers 
until they are actually needed.  This patch implements that suggestion, 
and does in fact seem to fix the problem.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit 03a304001f8fdb776a96648786fe667ad416ebeb
Author: Jason Merrill 
Date:   Wed Jun 8 09:06:07 2011 -0400

	PR c++/49107
	* cp-tree.def (DEFERRED_NOEXCEPT): New.
	* cp-tree.h (struct tree_deferred_noexcept): New.
	(DEFERRED_NOEXCEPT_PATTERN, DEFERRED_NOEXCEPT_ARGS): New.
	(DEFERRED_NOEXCEPT_SPEC_P): New.
	(enum cp_tree_node_structure_enum): Add TS_CP_DEFERRED_NOEXCEPT.
	(union lang_tree_node): Add tree_deferred_noexcept.
	(maybe_instantiate_noexcept): Declare.
	* cp-objcp-common.c (cp_tree_size): Handle DEFERRED_NOEXCEPT.
	* error.c (dump_exception_spec): Likewise.
	* cxx-pretty-print.c (pp_cxx_exception_specification): Likewise.
	* ptree.c (cxx_print_xnode): Likewise.
	* tree.c (cp_tree_equal): Likewise.
	* decl.c (cp_tree_node_structure): Likewise.
	(duplicate_decls): Call maybe_instantiate_noexcept.
	* except.c (build_noexcept_spec): Handle DEFERRED_NOEXCEPT.
	(nothrow_spec_p, type_noexcept_p, type_throw_all_p): Check
	DEFERRED_NOEXCEPT_SPEC_P.
	* typeck2.c (merge_exception_specifiers): Likewise.
	* decl2.c (mark_used): Call maybe_instantiate_noexcept.
	* method.c (process_subob_fn, defaulted_late_check): Likewise.
	* pt.c (tsubst_exception_specification): Add defer_ok parm.
	Build DEFERRED_NOEXCEPT.
	(maybe_instantiate_noexcept): New.
	(tsubst, regenerate_decl_from_template, instantiate_decl): Adjust.
	* search.c (check_final_overrider): Call maybe_instantiate_noexcept.

diff --git a/gcc/cp/cp-objcp-common.c b/gcc/cp/cp-objcp-common.c
index df6b1dd..1866b81 100644
--- a/gcc/cp/cp-objcp-common.c
+++ b/gcc/cp/cp-objcp-common.c
@@ -79,6 +79,7 @@ cp_tree_size (enum tree_code code)
 case BASELINK:		return sizeof (struct tree_baselink);
 case TEMPLATE_PARM_INDEX:	return sizeof (template_parm_index);
 case DEFAULT_ARG:		return sizeof (struct tree_default_arg);
+case DEFERRED_NOEXCEPT:	return sizeof (struct tree_deferred_noexcept);
 case OVERLOAD:		return sizeof (struct tree_overload);
 case STATIC_ASSERT: return sizeof (struct tree_static_assert);
 case TYPE_ARGUMENT_PACK:
diff --git a/gcc/cp/cp-tree.def b/gcc/cp/cp-tree.def
index 001ef10..ce11417 100644
--- a/gcc/cp/cp-tree.def
+++ b/gcc/cp/cp-tree.def
@@ -214,6 +214,11 @@ DEFTREECODE (USING_STMT, "using_directive", tcc_statement, 1)
parsing had occurred.  */
 DEFTREECODE (DEFAULT_ARG, "default_arg", tcc_exceptional, 0)
 
+/* An uninstantiated noexcept-specification.  DEFERRED_NOEXCEPT_PATTERN is
+   the pattern from the template, and DEFERRED_NOEXCEPT_ARGS are the
+   template arguments to substitute into the pattern when needed.  */
+DEFTREECODE (DEFERRED_NOEXCEPT, "deferred_noexcept", tcc_exceptional, 0)
+
 /* A template-id, like foo.  The first operand is the template.
The second is NULL if there are no explicit arguments, or a
TREE_VEC of arguments.  The template will be a FUNCTION_DECL,
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 0395db7..71f7dd4 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -507,6 +507,22 @@ struct GTY (()) tree_default_arg {
   VEC(tree,gc) *instantiations;
 };
 
+
+#define DEFERRED_NOEXCEPT_PATTERN(NODE) \
+  (((struct tree_deferred_noexcept *)DEFERRED_NOEXCEPT_CHECK (NODE))->pattern)
+#define DEFERRED_NOEXCEPT_ARGS(NODE) \
+  (((struct tree_deferred_noexcept *)DEFERRED_NOEXCEPT_CHECK (NODE))->args)
+#define DEFERRED_NOEXCEPT_SPEC_P(NODE)\
+  ((NODE) && (TREE_PURPOSE (NODE))\
+   && TREE_CODE (TREE_PURPOSE (NODE)) == DEFERRED_NOEXCEPT)
+
+struct GTY (()) tree_deferred_noexcept {
+  struct tree_base base;
+  tree pattern;
+  tree args;
+};
+
+
 /* The condition associated with the static assertion.  This must be
an integral constant expression.  */
 #define STATIC_ASSERT_CONDITION(NODE) \
@@ -693,6 +709,7 @@ enum cp_tree_node_structure_enum {
   TS_CP_BASELINK,
   TS_CP_WRAPPER,
   TS_CP_DEFAULT_ARG,
+  TS_CP_DEFERRED_NOEXCEPT,
   TS_CP_STATIC_ASSERT,
   TS_CP_ARGUMENT_PACK_SELECT,
   TS_CP_TRAIT_EXPR,
@@ -711,6 +728,7 @@ union GTY((desc ("cp_tree_node_structure (&%h)"),
   struct tree_overload GTY ((tag ("TS_CP_OVERLOAD"))) overload;
   struct tree_baselink GTY ((tag ("TS_CP_BASELINK"))) baselink;
   struct tree_default_arg GTY ((tag ("TS_CP_DEFAULT_ARG"))) default_arg;
+  struct tree_deferred_noexcept GTY ((tag ("TS_CP_DEFERRED_NOEXCEPT"))) deferred_noexcept;
   struct lang_identifier GTY ((tag ("TS_CP_IDENTIFIER"))) identifier;
   struct tree_static_assert GTY ((tag ("TS_CP_STATIC_ASSERT"))) 
 st

C++ PATCH for C++0x failure on template/dtor6.C

[Jason Merrill]

Running the testsuite in C++0x mode caught this issue.

Tested x86_64-pc-linux-gnu, applied to trunk.
commit b531be395b85f7872c51e79ffb5db9a30a2a4f66
Author: Jason Merrill 
Date:   Thu Jun 2 14:35:59 2011 -0400

	* semantics.c (potential_constant_expression_1): Handle destructor
	call.

diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index ebca840..53e5993 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -7763,6 +7763,12 @@ potential_constant_expression_1 (tree t, bool want_rval, tsubst_flags_t flags)
   want_rval = true;
   goto binary;
 
+case BIT_NOT_EXPR:
+  /* A destructor.  */
+  if (TYPE_P (TREE_OPERAND (t, 0)))
+	return true;
+  /* else fall through.  */
+
 case REALPART_EXPR:
 case IMAGPART_EXPR:
 case CONJ_EXPR:
@@ -7771,7 +,6 @@ potential_constant_expression_1 (tree t, bool want_rval, tsubst_flags_t flags)
 case FLOAT_EXPR:
 case NEGATE_EXPR:
 case ABS_EXPR:
-case BIT_NOT_EXPR:
 case TRUTH_NOT_EXPR:
 case FIXED_CONVERT_EXPR:
 case UNARY_PLUS_EXPR:

[pph] Front-end builtin macros (issue4575055)

[Lawrence Crowl]

Some builtin macros are more builtin than others.  In particular, front-end
builtin macros are weaker than libcpp builtin macros, and should not be
processed with the libcpp builtin tools.


Index: gcc/testsuite/ChangeLog.pph

2011-06-08  Lawrence Crowl 

* g++.dg/pph/c120060625-1.h: Make expected pass.
* g++.dg/pph/c120060625-1.cc: Make expected pass.

Index: libcpp/ChangeLog.pph

2011-06-08  Lawrence Crowl  

* symtab.c (lt_query_macro): Querying "user builtin" macros should not
call _cpp_builtin_macro_text.  Instead, call regular query, but first
let the front end define the value.


Index: gcc/testsuite/g++.dg/pph/c120060625-1.cc
===
--- gcc/testsuite/g++.dg/pph/c120060625-1.cc(revision 174789)
+++ gcc/testsuite/g++.dg/pph/c120060625-1.cc(working copy)
@@ -1,5 +1 @@
-// { dg-xfail-if "ICE" { "*-*-*" } { "-fpph-map=pph.map" } }
-// { dg-bogus "c120060625-1.h:14:22: internal compiler error: invalid built-in 
macro .__FLT_MAX__." "" { xfail *-*-* } 0 }
-// { dg-prune-output "In file included from " }
-
 #include "c120060625-1.h"
Index: gcc/testsuite/g++.dg/pph/c120060625-1.h
===
--- gcc/testsuite/g++.dg/pph/c120060625-1.h (revision 174789)
+++ gcc/testsuite/g++.dg/pph/c120060625-1.h (working copy)
@@ -1,6 +1,3 @@
-// { dg-xfail-if "ICE" { "*-*-*" } { "-fpph-map=pph.map" } }
-// { dg-bogus "c120060625-1.h:14:22: internal compiler error: invalid built-in 
macro .__FLT_MAX__." "" { xfail *-*-* } 0 }
-
 #ifndef __PPH_GUARD_H
 #define __PPH_GUARD_H
 
Index: libcpp/symtab.c
===
--- libcpp/symtab.c (revision 174789)
+++ libcpp/symtab.c (working copy)
@@ -494,7 +494,8 @@ static const char *
 lt_query_macro (cpp_reader *reader, cpp_hashnode *cpp_node)
 {
   const char *definition = NULL;
-  if (cpp_node->flags & NODE_BUILTIN)
+  if ((cpp_node->flags & NODE_BUILTIN)
+  && cpp_node->value.builtin < BT_FIRST_USER)
 {
   const char *str = (const char *)cpp_node->ident.str;
   if (   strcmp(str, "__DATE__") == 0
@@ -527,6 +528,8 @@ lt_query_macro (cpp_reader *reader, cpp_
   else
 {
   char c;
+  if ((cpp_node->flags & NODE_BUILTIN) && reader->cb.user_builtin_macro)
+reader->cb.user_builtin_macro (reader, cpp_node);
   definition = (const char *) cpp_macro_definition (reader, cpp_node);
   /* Skip over the macro name within the definition.  */
   c = *definition;

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

ObjC/ObjC++/testsuite: Remove unused method_get_* functions from next-encode-assist files

[Nicola Pero]

This patch removes a number of functions from the ObjC/ObjC++ testsuite 
next-encode-assist
files which are never used in the testsuite ... and will never be, since they 
have been removed
from the GNU runtime. ;-)

The next-encode-assist provides a compatible implementation for the NeXT 
runtime of some
special GNU runtime functions.  There is obviously no point in providing an 
implementation
of functions that have been removed and are never used.

OK to commit ?

Thanks

Index: ChangeLog
===
--- ChangeLog   (revision 174812)
+++ ChangeLog   (working copy)
@@ -1,3 +1,21 @@
+2011-06-08  Nicola Pero  
+
+   * objc-obj-c++-shared/objc-test-suite-next-encode-assist.h
+   (PMETH, arglist_t): Removed.
+   (method_get_number_of_arguments): Removed.  
+   (method_get_nth_argument): Removed.
+   (method_get_first_argument): Removed.
+   (method_get_next_argument): Removed.
+   (method_get_sizeof_arguments): Removed.
+   * objc-obj-c++-shared/objc-test-suite-next-encode-assist-impl.h
+   (PMETH): Removed.
+   (method_get_number_of_arguments): Removed.
+   (method_get_nth_argument): Removed.
+   (method_get_first_argument): Removed.
+   (method_get_next_argument): Removed.
+   (method_get_sizeof_arguments): Removed. 
+   * objc-obj-c++-shared/objc-test-suite-types.h (PMETH): Removed.
+   
 2011-06-08  Rainer Orth  
 
PR middle-end/21953
Index: objc-obj-c++-shared/objc-test-suite-next-encode-assist-impl.h
===
--- objc-obj-c++-shared/objc-test-suite-next-encode-assist-impl.h   
(revision 174812)
+++ objc-obj-c++-shared/objc-test-suite-next-encode-assist-impl.h   
(working copy)
@@ -7,10 +7,8 @@
 #include "next-abi.h"
 #ifdef NEXT_OBJC_USE_NEW_INTERFACE
 #include 
-typedef void * PMETH;
 #else
 #include 
-typedef struct objc_method * PMETH;
 #endif
 
 /*  */
@@ -486,136 +484,7 @@ objc_skip_argspec (const char *type)
   type = objc_skip_offset (type);
   return type;
 }
-/*
-  Return the number of arguments that the method MTH expects.
-  Note that all methods need two implicit arguments `self' and
-  `_cmd'.
-*/
-int
-method_get_number_of_arguments (PMETH mth)
-{
-  int i = 0;
-#ifdef NEXT_OBJC_USE_NEW_INTERFACE
-  const char *type = method_getTypeEncoding((Method)mth);
-#else
-  const char *type = mth->method_types;
-#endif
-  while (*type)
-{
-  type = objc_skip_argspec (type);
-  i += 1;
-}
-  return i - 1;
-}
 
-/*
-  Return the size of the argument block needed on the stack to invoke
-  the method MTH.  This may be zero, if all arguments are passed in
-  registers.
-*/
-
-int
-method_get_sizeof_arguments (PMETH mth)
-{
-#ifdef NEXT_OBJC_USE_NEW_INTERFACE
-  const char *type = objc_skip_typespec (method_getTypeEncoding((Method)mth));
-#else
-  const char *type = objc_skip_typespec (mth->method_types);
-#endif
-  return atoi (type);
-}
-
-/*
-  Return a pointer to the next argument of ARGFRAME.  type points to
-  the last argument.  Typical use of this look like:
-
-  {
-char *datum, *type;
-for (datum = method_get_first_argument (method, argframe, &type);
- datum; datum = method_get_next_argument (argframe, &type))
-  {
-unsigned flags = objc_get_type_qualifiers (type);
-type = objc_skip_type_qualifiers (type);
-   if (*type != _C_PTR)
-  [portal encodeData: datum ofType: type];
-   else
- {
-   if ((flags & _F_IN) == _F_IN)
-  [portal encodeData: *(char **) datum ofType: ++type];
- }
-  }
-  }
-*/
-
-char *
-method_get_next_argument (arglist_t argframe, const char **type)
-{
-  const char *t = objc_skip_argspec (*type);
-
-  if (*t == '\0')
-return 0;
-
-  *type = t;
-  t = objc_skip_typespec (t);
-
-  if (*t == '+')
-return argframe->arg_regs + atoi (++t);
-  else
-return argframe->arg_ptr + atoi (t);
-}
-
-/*
-  Return a pointer to the value of the first argument of the method
-  described in M with the given argumentframe ARGFRAME.  The type
-  is returned in TYPE.  type must be passed to successive calls of
-  method_get_next_argument.
-*/
-char *
-method_get_first_argument (PMETH m,
-  arglist_t argframe,
-  const char **type)
-{
-#ifdef NEXT_OBJC_USE_NEW_INTERFACE
-  *type = method_getTypeEncoding((Method)m);
-#else
-  *type = m->method_types;
-#endif
-
-  return method_get_next_argument (argframe, type);
-}
-
-/*
-   Return a pointer to the ARGth argument of the method
-   M from the frame ARGFRAME.  The type of the argument
-   is returned in the value-result argument TYPE
-*/
-
-char *
-method_get_nth_argument (PMETH m,
-arglist_t argframe, int arg,
-const char **type)
-{
-#ifdef NEXT_OBJC_USE_NEW_INTERFACE
-  const char *t = objc_skip_argspec (method_getTypeEncoding((Method)m));

Re: [pph] Front-end builtin macros (issue4575055)

[Diego Novillo]

On Wed, Jun 8, 2011 at 15:09, Lawrence Crowl  wrote:
> Some builtin macros are more builtin than others.  In particular, front-end
> builtin macros are weaker than libcpp builtin macros, and should not be
> processed with the libcpp builtin tools.

Nice!  This fixes a whole chunk of C test cases.


Diego.

Re: Dump before flag

[Xinliang David Li]

this is the patch that just removes the TODO_dump flag and forces it
to dump. The original code cfun->last_verified = flags &
TODO_verify_all looks weird -- depending on TODO_dump is set or not,
the behavior of the update is different (when no other todo flags is
set).

Ok for trunk?

David

On Wed, Jun 8, 2011 at 9:52 AM, Xinliang David Li  wrote:
> On Wed, Jun 8, 2011 at 2:06 AM, Richard Guenther
>  wrote:
>> On Wed, Jun 8, 2011 at 1:08 AM, Xinliang David Li  wrote:
>>> The following is the patch that does the job. Most of the changes are
>>> just  removing TODO_dump_func. The major change is in passes.c and
>>> tree-pass.h.
>>>
>>> -fdump-xxx-yyy-start       <-- dump before TODO_start
>>> -fdump-xxx-yyy-before    <-- dump before main pass after TODO_pass
>>> -fdump-xxx-yyy-after       <-- dump after main pass before TODO_finish
>>> -fdump-xxx-yyy-finish      <-- dump after TODO_finish
>>
>> Can we bikeshed a bit more about these names?
>
> These names may be less confusing:
>
> before_preparation
> before
> after
> after_cleanup
>
> David
>
>> "start" and "before"
>> have no semantical difference to me ... as the dump before TODO_start
>> of a pass and the dump after TODO_finish of the previous pass are
>> identical (hopefully ;)), maybe merge those into a -between flag?
>> If you'd specify it for a single pass then you'd get both -start and -finish
>> (using your naming scheme).  Splitting that dump(s) to different files
>> then might make sense (not sure about the name to use).
>>
>> Note that I find it extremely useful to have dumping done in
>> chronological order - splitting some of it to different files destroys
>> this, especially a dump after TODO_start or before TODO_finish
>> should appear in the same file (or we could also start splitting
>> individual TODO_ output into sub-dump-files).  I guess what would
>> be nice instread would be a fancy dump-file viewer that could
>> show diffs, hide things like SCEV output, etc.
>>
>> I suppose a patch that removes the dump TODO and unconditionally
>> dumps at the current point would be a good preparation for this
>> enhancing patch.
>>
>> Richard.
>>
>>> The default is 'finish'.
>>>
>>> Does it look ok?
>>>
>>> Thanks,
>>>
>>> David
>>>
>>> On Tue, Jun 7, 2011 at 2:36 AM, Richard Guenther
>>>  wrote:
 On Mon, Jun 6, 2011 at 6:20 PM, Xinliang David Li  
 wrote:
>>
>> Your patch doesn't really improve this but adds to the confusion.
>>
>> +  /* Override dump TODOs.  */
>> +  if (dump_file && (pass->todo_flags_finish & TODO_dump_func)
>> +      && (dump_flags & TDF_BEFORE))
>> +    {
>> +      pass->todo_flags_finish &= ~TODO_dump_func;
>> +      pass->todo_flags_start |= TODO_dump_func;
>> +    }
>>
>> and certainly writing to pass is not ok.  And the TDF_BEFORE flag
>> looks misplaced as it controls TODOs, not dumping behavior.
>> Yes, it's a mess right now but the above looks like a hack ontop
>> of that mess (maybe because of it, but well ...).
>>
>
> How about removing dumping TODO completely -- this can be done easily
> -- I don't understand why pass wants extra control on the dumping if
> user already asked for dumping -- it is annoying to see empty IR dump
> for a pass when I want to see it.
>
>> At least I would have expected to also get the dump after the
>> pass, not only the one before it with this dump flag.
>>
>> Now, why can't you look at the previous pass output for the
>> before-dump (as I do usually)?
>
> For one thing, you need to either remember what is the previous pass,
> or dump all passes which for large files can take very long time. Even
> with all the dumps, you will need to eyeballing to find the previous
> pass which may or may not have the IR dumped.
>
> How about removing dump TODO?

 Yeah, I think this would go in the right direction.  Currently some passes
 do not dump function bodies because they presumably do no IL
 modification.  But this is certainly the minority (and some passes do not
 dump bodies even though they are modifying the IL ...).

 So I'd say we should by default dump function bodies.

 Note that there are three useful dumping positions (maybe four),
 before todo-start, after todo-start, before todo-finish and after 
 todo-finish.
 By default we'd want after todo-finish.  When we no longer dump via
 a TODO then we could indeed use dump-flags to control this
 (maybe -original for the body before todo-start).

 What to others think?

 Richard.

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

>>>
>>
>

libobjc: updated documentation for removal of traditional API

[Nicola Pero]

This patch (trivially) updates the libobjc documentation to state
that the Traditional Objective-C runtime API is no longer available.

Committed to trunk.

Thanks

Index: ChangeLog
===
--- ChangeLog   (revision 174821)
+++ ChangeLog   (working copy)
@@ -1,3 +1,8 @@
+2011-06-09  Nicola Pero  
+
+   * doc/objc.texi (Traditional GNU Objective-C runtime API):
+   Updated.
+
 2011-06-08  Alexandre Oliva  
 
* tree-flow-inline.h (op_iter_init): Reject GIMPLE_PHI stmts.
Index: doc/objc.texi
===
--- doc/objc.texi   (revision 174821)
+++ doc/objc.texi   (working copy)
@@ -121,25 +121,9 @@ different naming convention, such as @code{class_g
 API).  Software using this API includes the file
 @file{objc/objc-api.h} where it is declared.
 
-The traditional API is deprecated but it is still supported in this
-release of the runtime; you can access it as usual by including
-@file{objc/objc-api.h}.
+Starting with GCC 4.7.0, the traditional GNU runtime API is no longer
+available.
 
-If you are using the traditional API you are urged to upgrade your
-software to use the modern API because the traditional API requires
-access to private runtime internals to do anything serious with it;
-for this reason, there is no guarantee that future releases of the GNU
-Objective-C runtime library will be able to provide a fully compatible
-@file{objc/objc-api.h} as the private runtime internals change.  It is
-expected that the next release will hide a number of runtime internals
-making the traditional API nominally supported but fairly useless
-beyond very simple use cases.
-
-Finally, you can not include both @file{objc/objc-api.h} and
-@file{objc/runtime.h} at the same time.  The traditional and modern
-APIs unfortunately have some conflicting declarations (such as the one
-for @code{Method}) and can not be used at the same time.
-
 @c =
 @node Executing code before main
 @section @code{+load}: Executing code before main

[patch committed] Fix PR target/49305

[Kaz Kojima]

Hi,

My patch r174586 on trunk was a bit incomplete and causes
PR49305 on sh2a target.  The attached patch is to fix it.
Tested on sh-elf and sh4-unknown-linux-gnu and applied on
trunk.

BTW, when looking into PR, I noticed that we forgot to utilize
32-bit mov.w instructions on sh2a while 32-bit mov.[bl]
instructions are enabled on that target already.  I'll prepare
the patch for it.

Regards,
kaz
--
2011-06-08  Kaz Kojima  

PR target/49305
* config/sh/predicates.md (general_movsrc_operand): Check
mode for memory with indexed address for QI and HImode.
(general_movdst_operand): Likewise.

--- ORIG/trunk/gcc/config/sh/predicates.md  2011-06-04 10:16:51.0 
+0900
+++ trunk/gcc/config/sh/predicates.md   2011-06-08 18:55:09.0 +0900
@@ -395,6 +395,7 @@
 }
 
   if ((mode == QImode || mode == HImode)
+  && mode == GET_MODE (op)
   && (MEM_P (op)
  || (GET_CODE (op) == SUBREG && MEM_P (SUBREG_REG (op)
 {
@@ -432,6 +433,7 @@
 return 0;
 
   if ((mode == QImode || mode == HImode)
+  && mode == GET_MODE (op)
   && (MEM_P (op)
  || (GET_CODE (op) == SUBREG && MEM_P (SUBREG_REG (op)
 {

Re: ObjC/ObjC++/testsuite: Remove unused method_get_* functions from next-encode-assist files

[Mike Stump]

On Jun 8, 2011, at 3:21 PM, Nicola Pero wrote:
> This patch removes a number of functions from the ObjC/ObjC++ testsuite 
> next-encode-assist
> files which are never used in the testsuite ... and will never be, since they 
> have been removed
> from the GNU runtime. ;-)

> OK to commit ?

Ok.

toplevel libgcc md-unwind-support.h change breaks build

[David Miller]

The bootstrap breaks in stage1 when trying to build libgcc for
multilib (this is sparc-unknown-linux with "--enable-targets=all"):

make[3]: Leaving directory `/home/davem/src/GIT/GCC/build-sparc-linux/gcc'
mkdir -p -- sparc-unknown-linux-gnu/libgcc
Checking multilib configuration for libgcc...
Configuring stage 1 in sparc-unknown-linux-gnu/libgcc
configure: creating cache ./config.cache
...
checking for __attribute__((visibility("hidden")))... yes
checking whether the target assembler supports thread-local storage... yes
checking whether the thread-local storage support is from emutls... no
configure: updating cache ./config.cache
configure: creating ./config.status
config.status: creating Makefile
config.status: linking ../../../gcc/libgcc/config/sparc/linux.h to 
md-unwind-support.h
config.status: error: ../../../gcc/libgcc/config/sparc/linux.h: file not found
make[2]: *** [configure-stage1-target-libgcc] Error 1
make[2]: Leaving directory `/home/davem/src/GIT/GCC/build-sparc-linux'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/home/davem/src/GIT/GCC/build-sparc-linux'
make: *** [all] Error 2

It's using "linux.h" instead of "linux-unwind.h" for whatever reason.

So we need something like this?

diff --git a/libgcc/config.host b/libgcc/config.host
index 24282e1..713b2a9 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -600,7 +600,7 @@ sparc-*-elf*)
 sparc-*-linux*)# SPARC's running GNU/Linux, libc6
extra_parts="$extra_parts crtfastmath.o"
tmake_file="${tmake_file} t-crtfm"
-   md_unwind_header=sparc/linux.h
+   md_unwind_header=sparc/linux-unwind.h
;;
 sparc-*-rtems* | sparc64-*-rtems* )
tmake_file="sparc/t-elf t-crtin t-crtfm t-rtems"

[pph] Remove some additional cruft we no longer use (issue4547091)

[Diego Novillo]

No functional changes in this patch.  Additional cleanups after the
various trunk merges and old code removal patches.

Tested on x86_64.  Committed to branch.


Diego.

Fix spurious differences with trunk.

* c-parser.c (c_parser_declaration_or_fndef): Remove call to
timevar_push.
* ggc-page.c (ggc_collect): Change timevar_start to
timevar_push and timevar_stop to timevar_pop.
* ggc-zone.c (ggc_collect): Likewise.
* langhooks-def.h (LANG_HOOKS_INITIALIZER): Remove ',' at the
end.
* lto-streamer-out.c (lto_output_tree_header): Remove
assertion.
* timevar.def (TV_GC): Revert to trunk version.
* toplev.c (compile_file): Remove some timevar_start and
timevar_stop calls.
(do_compile): Likewise.

cp/ChangeLog.pph

* call.c: Do not include pph.h.
(implicit_conversion): Remove unnecessary braces.
(build_new_op_1): Likewise.
* cp-gimplify.c (cp_genericize): Remove FIXME comment.
* cp-lang.c: Do not include pph.h.
* decl.c (duplicate_decls): Rename from duplicate_decls_internal.
(xref_tag_1): Remove FIXME comment.
* Make-lang.in (cp/cp-lang.o): Remove $(CXX_PPH_H) dependency.
(cp/decl.o): Remove $(CXX_PPH_H) and langhooks.h dependencies.
(cp/pt.o): Remove $(CXX_PPH_H) dependency.
* pt.c: Do not include pph.h.
* rtti.c (create_pseudo_type_info): Remove setting of
DECL_ARTIFICIAL.


diff --git a/gcc/c-parser.c b/gcc/c-parser.c
index c8e7aa5..65966a9 100644
--- a/gcc/c-parser.c
+++ b/gcc/c-parser.c
@@ -1685,7 +1685,6 @@ c_parser_declaration_or_fndef (c_parser *parser, bool 
fndef_ok,
  return;
}
   /* Function definition (nested or otherwise).  */
-  timevar_push (TV_PARSE_FUNC);
   if (nested)
{
  pedwarn (here, OPT_pedantic, "ISO C forbids nested functions");
diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index e6b6977..ff3dc06 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -39,7 +39,6 @@ along with GCC; see the file COPYING3.  If not see
 #include "target.h"
 #include "convert.h"
 #include "langhooks.h"
-#include "pph.h"
 #include "c-family/c-objc.h"
 #include "timevar.h"
 
@@ -1757,9 +1756,7 @@ implicit_conversion (tree to, tree from, tree expr, bool 
c_cast_p,
 
   cand = build_user_type_conversion_1 (to, expr, convflags);
   if (cand)
-{
- conv = cand->second_conv;
-}
+   conv = cand->second_conv;
 
   /* We used to try to bind a reference to a temporary here, but that
 is now handled after the recursive call to this function at the end
@@ -5014,9 +5011,7 @@ build_new_op_1 (enum tree_code code, int flags, tree 
arg1, tree arg2, tree arg3,
  if (resolve_args (arglist, complain) == NULL)
result = error_mark_node;
  else
-{
- result = build_over_call (cand, LOOKUP_NORMAL, complain);
-}
+   result = build_over_call (cand, LOOKUP_NORMAL, complain);
}
   else
{
diff --git a/gcc/cp/cp-gimplify.c b/gcc/cp/cp-gimplify.c
index 2aeb05d..d26c0e0 100644
--- a/gcc/cp/cp-gimplify.c
+++ b/gcc/cp/cp-gimplify.c
@@ -1177,8 +1177,6 @@ cp_genericize (tree fndecl)
   pointer_set_destroy (wtd.p_set);
   VEC_free (tree, heap, wtd.bind_expr_stack);
 
-  /* FIXME pph: save function to hunk.  */
-
   /* Do everything else.  */
   c_genericize (fndecl);
 
diff --git a/gcc/cp/cp-lang.c b/gcc/cp/cp-lang.c
index c47fafd..7b1f450 100644
--- a/gcc/cp/cp-lang.c
+++ b/gcc/cp/cp-lang.c
@@ -33,7 +33,6 @@ along with GCC; see the file COPYING3.  If not see
 #include "hashtab.h"
 #include "target.h"
 #include "parser.h"
-#include "pph.h"
 
 enum c_language_kind c_language = clk_cxx;
 static void cp_init_ts (void);
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index f73ade5..30f70d9 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -54,8 +54,6 @@ along with GCC; see the file COPYING3.  If not see
 #include "pointer-set.h"
 #include "splay-tree.h"
 #include "plugin.h"
-#include "langhooks.h"
-#include "pph.h"
 
 /* Possible cases of bad specifiers type used by bad_specifiers. */
 enum bad_spec_place {
@@ -1180,8 +1178,8 @@ validate_constexpr_redeclaration (tree old_decl, tree 
new_decl)
 
NEWDECL_IS_FRIEND is true if NEWDECL was declared as a friend.  */
 
-static tree
-duplicate_decls_internal (tree newdecl, tree olddecl, bool newdecl_is_friend)
+tree
+duplicate_decls (tree newdecl, tree olddecl, bool newdecl_is_friend)
 {
   unsigned olddecl_uid = DECL_UID (olddecl);
   int olddecl_friend = 0, types_match = 0, hidden_friend = 0;
@@ -2301,28 +2299,6 @@ duplicate_decls_internal (tree newdecl, tree olddecl, 
bool newdecl_is_friend)
 
   return olddecl;
 }
-
-
-/* Wrapper for duplicate_decls_internal used by PPH support to
-   decide whether NEWDECL or OLDDECL should be removed from the
-   AST catching data structures.  This is necessary when NEWDECL
-   is a r

[pph] Fix cp_debug_parser (issue4571058)

[Diego Novillo]

This fixes the ICE that Gab ran into while calling cp_debug_parser on a
test case.

We were not handling the case of empty token buffers and when the
caller set the starting token to NULL.

Additionally, the window of tokens to print was too small to be of any
real use.


* parser.c (cp_lexer_dump_tokens): If START_TOKEN is NULL,
set it to the start of the token buffer.
If BUFFER is NULL, do nothing.
(cp_debug_parser): Increase token window size.

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 300fcba..e241cc7 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -265,10 +265,16 @@ cp_lexer_dump_tokens (FILE *file, VEC(cp_token,gc) 
*buffer,
 
   fprintf (file, "%u tokens\n", VEC_length (cp_token, buffer));
 
+  if (buffer == NULL)
+return;
+
   if (num == 0)
 num = VEC_length (cp_token, buffer);
 
-  if (start_token && start_token > VEC_address (cp_token, buffer))
+  if (start_token == NULL)
+start_token = VEC_address (cp_token, buffer);
+
+  if (start_token > VEC_address (cp_token, buffer))
 {
   cp_lexer_print_token (file, VEC_index (cp_token, buffer, 0));
   fprintf (file, " ... ");
@@ -436,7 +442,7 @@ void
 cp_debug_parser (FILE *file, cp_parser *parser)
 {
   cp_token *start_token, *first_token, *next_token;
-  const size_t window_size = 20;
+  const size_t window_size = 200;
 
   if (file == NULL)
 file = stderr;

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

Re-factor TS_* marking code (issue4572051)

[Diego Novillo]

This is a fairly simple re-factoring that simplifies the TS_* marking
code, but it changes how the C++ front end marks the tree codes, so
I'm looking for an explicit approval.

There are no functional changes.  The code in
initialize_tree_contains_struct moves to mark_ts_structures_for and
tree_node_structure_for_code is now an extern function so the C++
parser can mark the common codes as well as the C++ codes.

This is mostly useful in pph, since the streamer relies on the TS_*
markers to be complete.  The C++ parser only used to mark a few trees,
not all of them.

Tested on x86_64.  OK for trunk?


Diego.


* tree.c (tree_node_structure_for_code): Make extern.
Return LAST_TS_ENUM if the code is not recognized.
(mark_ts_structures_for): Factor out of ...
(initialize_tree_contains_struct): ... here.
* tree.h (tree_node_structure_for_code): Declare.
(mark_ts_structures_for): Declare.

cp/ChangeLog

* cp/cp-objcp-common.c (cp_common_init_ts): Re-factor.
Traverse all language nodes, calling mark_ts_structures_for.
Mark all expressions codes as typed.
Assert that all the codes have been marked.

diff --git a/gcc/cp/cp-objcp-common.c b/gcc/cp/cp-objcp-common.c
index 1866b81..ec34584 100644
--- a/gcc/cp/cp-objcp-common.c
+++ b/gcc/cp/cp-objcp-common.c
@@ -228,78 +228,103 @@ init_shadowed_var_for_decl (void)
 void
 cp_common_init_ts (void)
 {
-  MARK_TS_DECL_NON_COMMON (NAMESPACE_DECL);
-  MARK_TS_DECL_NON_COMMON (USING_DECL);
-  MARK_TS_DECL_NON_COMMON (TEMPLATE_DECL);
-
-  MARK_TS_COMMON (TEMPLATE_TEMPLATE_PARM);
-  MARK_TS_COMMON (TEMPLATE_TYPE_PARM);
-  MARK_TS_COMMON (TEMPLATE_PARM_INDEX);
-  MARK_TS_COMMON (OVERLOAD);
-  MARK_TS_COMMON (TEMPLATE_INFO);
-  MARK_TS_COMMON (TYPENAME_TYPE);
-  MARK_TS_COMMON (TYPEOF_TYPE);
-  MARK_TS_COMMON (UNDERLYING_TYPE);
-  MARK_TS_COMMON (BASELINK);
-  MARK_TS_COMMON (TYPE_PACK_EXPANSION);
-  MARK_TS_COMMON (TYPE_ARGUMENT_PACK);
-  MARK_TS_COMMON (DECLTYPE_TYPE);
-  MARK_TS_COMMON (BOUND_TEMPLATE_TEMPLATE_PARM);
-  MARK_TS_COMMON (UNBOUND_CLASS_TEMPLATE);
-
-  MARK_TS_TYPED (EXPR_PACK_EXPANSION);
-  MARK_TS_TYPED (SWITCH_STMT);
-  MARK_TS_TYPED (IF_STMT);
-  MARK_TS_TYPED (FOR_STMT);
-  MARK_TS_TYPED (RANGE_FOR_STMT);
-  MARK_TS_TYPED (AGGR_INIT_EXPR);
-  MARK_TS_TYPED (EXPR_STMT);
-  MARK_TS_TYPED (EH_SPEC_BLOCK);
-  MARK_TS_TYPED (CLEANUP_STMT);
-  MARK_TS_TYPED (SCOPE_REF);
-  MARK_TS_TYPED (CAST_EXPR);
-  MARK_TS_TYPED (NON_DEPENDENT_EXPR);
-  MARK_TS_TYPED (MODOP_EXPR);
-  MARK_TS_TYPED (TRY_BLOCK);
-  MARK_TS_TYPED (THROW_EXPR);
-  MARK_TS_TYPED (HANDLER);
-  MARK_TS_TYPED (REINTERPRET_CAST_EXPR);
-  MARK_TS_TYPED (CONST_CAST_EXPR);
-  MARK_TS_TYPED (STATIC_CAST_EXPR);
-  MARK_TS_TYPED (DYNAMIC_CAST_EXPR);
-  MARK_TS_TYPED (TEMPLATE_ID_EXPR);
-  MARK_TS_TYPED (ARROW_EXPR);
-  MARK_TS_TYPED (SIZEOF_EXPR);
-  MARK_TS_TYPED (ALIGNOF_EXPR);
-  MARK_TS_TYPED (AT_ENCODE_EXPR);
-  MARK_TS_TYPED (UNARY_PLUS_EXPR);
-  MARK_TS_TYPED (TRAIT_EXPR);
-  MARK_TS_TYPED (TYPE_ARGUMENT_PACK);
-  MARK_TS_TYPED (NOEXCEPT_EXPR);
-  MARK_TS_TYPED (NONTYPE_ARGUMENT_PACK);
-  MARK_TS_TYPED (WHILE_STMT);
-  MARK_TS_TYPED (NEW_EXPR);
-  MARK_TS_TYPED (VEC_NEW_EXPR);
-  MARK_TS_TYPED (BREAK_STMT);
-  MARK_TS_TYPED (MEMBER_REF);
-  MARK_TS_TYPED (DOTSTAR_EXPR);
-  MARK_TS_TYPED (DO_STMT);
-  MARK_TS_TYPED (DELETE_EXPR);
-  MARK_TS_TYPED (VEC_DELETE_EXPR);
-  MARK_TS_TYPED (CONTINUE_STMT);
-  MARK_TS_TYPED (TAG_DEFN);
-  MARK_TS_TYPED (PSEUDO_DTOR_EXPR);
-  MARK_TS_TYPED (TYPEID_EXPR);
-  MARK_TS_TYPED (MUST_NOT_THROW_EXPR);
-  MARK_TS_TYPED (STMT_EXPR);
-  MARK_TS_TYPED (OFFSET_REF);
-  MARK_TS_TYPED (OFFSETOF_EXPR);
-  MARK_TS_TYPED (PTRMEM_CST);
-  MARK_TS_TYPED (EMPTY_CLASS_EXPR);
-  MARK_TS_TYPED (VEC_INIT_EXPR);
-  MARK_TS_TYPED (USING_STMT);
-  MARK_TS_TYPED (LAMBDA_EXPR);
-  MARK_TS_TYPED (CTOR_INITIALIZER);
+  unsigned i;
+
+  for (i = LAST_AND_UNUSED_TREE_CODE; i < MAX_TREE_CODES; i++)
+{
+  enum tree_node_structure_enum ts_code;
+  enum tree_code code;
+
+  code = (enum tree_code) i;
+  ts_code = tree_node_structure_for_code (code);
+  if (ts_code != LAST_TS_ENUM)
+   {
+ /* All expressions in C++ are typed.  */
+ if (ts_code == TS_EXP)
+   MARK_TS_TYPED (code);
+ mark_ts_structures_for (code, ts_code);
+   }
+  else
+   {
+ /* tree_node_structure_for_code does not recognize language
+specific nodes (unless they use standard code classes).  */
+ MARK_TS_COMMON (code);
+   }
+}
+
+  /* Consistency checks for codes used in the front end.  */
+  gcc_assert (tree_contains_struct[NAMESPACE_DECL][TS_DECL_NON_COMMON]);
+  gcc_assert (tree_contains_struct[USING_DECL][TS_DECL_NON_COMMON]);
+  gcc_assert (tree_contains_struct[TEMPLATE_DECL][TS_DECL_NON_COMMON]);
+
+  gcc_assert (tree_contains_struct[TEMPLATE_TEMPLATE_PARM][TS_COMMON]);
+  gcc_assert (tree_contains_struct[TEMPLATE_TYPE_PARM][TS_COMMON]);
+  

Re: Re-factor TS_* marking code (issue4572051)

[Jason Merrill]

It seems like you're changing to mark a lot of things as TS_COMMON that 
previously were only TS_TYPED or even only TS_BASE.


Jason

Fix PR49154-related SEGV in IRA. And ping.

[Hans-Peter Nilsson]

First, a ping for
;
updated regclass documentation.  Ok?

Second, I updated the CRIS port to fit the proposed
documentation update (adding a class as the patch you sent, but
more complete), with regtest results clean for revisions before
the revision where build started failing.  But, after that
revision, I get a SEGV; details added to
.  At first
I thought I messed up the regclass description but it appears to
be just an obvious miss, fixed below.  If it isn't, I think
setup_regno_cost_classes_by_mode should have a comment as to who
else should set up regno_cost_classes[regno] and that "who else"
needs to be fixed to do the setup.  Odd that this bug didn't
trig before or for any of the targets on which you tested.
Maybe that makes cris-elf qualify for the set of targets you
test IRA changes on?

By the way, can we do a s/_aclass/_class/ in applicable files,
for example ira-costs.c?  Someone appears to have done a botched
word-replace of class to aclass; besides the identifier "class"
it changed occurrences within identifiers too (at least those
after a _) so we have e.g. cost_classes_aclass_cache and
setup_regno_cost_classes_by_aclass vs. cost_classes_mode_cache
and setup_regno_cost_classes_by_mode.

Tested on cris-elf; together with the mentioned update it
restores build with results consistent with those before the
breakage.

Ok to commit?

gcc:
PR rtl-optimization/49154
* ira-costs.c (setup_regno_cost_classes_by_mode): If there
already is a matching slot in the hashtable, assign it to
classes_ptr.

diff --git gcc/ira-costs.c gcc/ira-costs.c
index f517386..a22bb15 100644
--- gcc/ira-costs.c
+++ gcc/ira-costs.c
@@ -299,6 +299,8 @@ setup_regno_cost_classes_by_mode (int regno, enum 
machine_mode mode)
  classes_ptr = setup_cost_classes (&classes);
  *slot = classes_ptr;
}
+  else
+   classes_ptr = *slot;
   cost_classes_mode_cache[mode] = (cost_classes_t) *slot;
 }
   regno_cost_classes[regno] = classes_ptr;

brgds, H-P

Re: [pph] Stream TREE_TYPE for identifier node (issue4550121)

[Jason Merrill]

On 06/08/2011 03:31 PM, Steven Bosscher wrote:

The rest are all in cp/.  It looks like g++ uses TREE_TYPE as a cache
for name lookups. Perhaps Jason can comment. Obviously not a front end
I know very well, but let's look at them one at a time:

cp/cp-tree.h:  (DECL_CONV_FN_P (FN) ? TREE_TYPE (DECL_NAME (FN)) : NULL_TREE)

Apparently g++ puts the type of an operator in TREE_TYPE of an
IDENTIFIER_NODE. This should probably be using
REAL_IDENTIFIER_TYPE_VALUE() instead of TREE_TYPE().


Yes, this is to associate the name of a type conversion operator with 
the type it converts to.  Using a different macro would be fine.



cp/decl.c:if (TREE_TYPE (DECL_NAME (decl))&&  TREE_TYPE (decl) != type)

This is in a warning for a type declaration shadowing a local or class
scope.  Should use identifier_type_value (or
REAL_IDENTIFIER_TYPE_VALUE but I think that's supposed to be used
directly only in name-lookup.c??)


Sure, identifier_type_value would work.  But that code looks bitrotted; 
type is always equal to TREE_TYPE (decl).  I'd be inclined to try 
removing it and seeing if anything breaks.



cp/decl2.c:   tree underlying_type = TREE_TYPE (DECL_NAME (decl));
cp/decl2.c: (decl, type_visibility (TREE_TYPE (DECL_NAME (decl;
cp/decl2.c:&&  CLASS_TYPE_P (TREE_TYPE (DECL_NAME (decl)))
cp/decl2.c:&&  !CLASSTYPE_VISIBILITY_SPECIFIED (TREE_TYPE
(DECL_NAME (decl
cp/decl2.c:  tree type = TREE_TYPE (DECL_NAME (decl));
cp/repo.c:  type = TREE_TYPE (DECL_NAME (decl));
cp/rtti.c:  tree type = TREE_TYPE (DECL_NAME (decl));

All of these are covered by a check on DECL_TINFO_P. I am not sure
what that means but probably these should also be using
identifier_type_value or REAL_IDENTIFIER_TYPE_VALUE instead of
TREE_TYPE. Jason?


This is a way of finding the class a type_info node/vtable pertains to. 
 Using a different lookup strategy would be fine.


Jason

[patch] Committed: Fix the printable name typo in treestruct.def

[Mingjie Xing]

Hi,

This small patch fixes the printable name typo in treestruct.def.
I've committed as it is obvious.
(http://gcc.gnu.org/ml/gcc/2011-06/msg00083.html)

2011-06-09  Mingjie Xing  

* treestruct.def (TS_TYPE_DECL): Fix the printable name typo.

Index: treestruct.def
===
--- treestruct.def  (revision 174800)
+++ treestruct.def  (working copy)
@@ -51,7 +51,7 @@ DEFTREESTRUCT(TS_PARM_DECL, "parm decl")
 DEFTREESTRUCT(TS_LABEL_DECL, "label decl")
 DEFTREESTRUCT(TS_RESULT_DECL, "result decl")
 DEFTREESTRUCT(TS_CONST_DECL, "const decl")
-DEFTREESTRUCT(TS_TYPE_DECL, "label decl")
+DEFTREESTRUCT(TS_TYPE_DECL, "type decl")
 DEFTREESTRUCT(TS_FUNCTION_DECL, "function decl")
 DEFTREESTRUCT(TS_TRANSLATION_UNIT_DECL, "translation-unit decl")
 DEFTREESTRUCT(TS_TYPE_COMMON, "type common")

Thanks,
Mingjie

Re: Remove SETJMP_VIA_SAVE_AREA support

[Hans-Peter Nilsson]

On Thu, 2 Jun 2011, Eric Botcazou wrote:

> This removes the (undocumented) support for SETJMP_VIA_SAVE_AREA from the
> compiler.

Poison it (in system.h)?

brgds, H-P

Re: [PATCH] c-pragma: adding a data field to pragma_handler

[Basile Starynkevitch]

On Wed, 08 Jun 2011 23:26:39 +0200
Pierre Vittet  wrote:

> I have written a test for this patch and run it (it works correctly). I 
> guess there is no reason why it should not be accepted now.
> To recap, this patch add a void * data field to the pragma handler, 
> allowing to pass extra data. If we want to use this field, we need to 
> use the function c_register_pragma_with_data or 
> c_register_pragma_with_expansion_and_data. The old 
> c_register_pragma(_with_expansion) is kept compatible.


===
--- gcc/c-family/c-pragma.c (revision 174521)
+++ gcc/c-family/c-pragma.c (working copy)
@@ -1148,12 +1148,12 @@ handle_pragma_float_const_decimal64 (cpp_reader
*A }
 
 /* A vector of registered pragma callbacks.  */
+/* This is never freed as we need it during the whole execution.  */
+DEF_VEC_O (internal_pragma_handler);
+DEF_VEC_ALLOC_O (internal_pragma_handler, heap);

Sorry to be picky Pierre, but that comment is not correct. It should be
instead.

/* A vector of registered pragma callbacks, which is never freed.   */

What I mean is that you are right that the vector is never freed, but
it is not because it is needed during the entire execution, since
middle-end and back-end passes don't know about pragmas.

I hope your patch will be ok-ed with that small change.

Perhaps a future patch would free that registered_pragmas vector, but I
feel that is not necessary, since it is not a big vector in practice.

Regards.

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