Re: [PATCH] PR c++/PR48035

[Jakub Jelinek]

On Thu, Mar 10, 2011 at 06:02:50PM -0500, Jason Merrill wrote:
> On 03/10/2011 11:14 AM, Dodji Seketeli wrote:
> >+  /* If we are initializing a sub-object of
> >+ CURRENT_OBJECT_TYPE [for which a primary base class
> >+ sub-object has already been initialized] then we must NOT
> >+ initialize any sub-object from a virtual base that is a
> >+ direct or indirect primary base of
> >+ CURRENT_OBJECT_TYPE.  */
> >+  if (current_object_type
> >+  && is_virtual_base_of (TREE_TYPE (field), current_object_type)
> >+  && is_primary_base_of (TREE_TYPE (field), current_object_type,
> >+ /*indirect_p=*/true))
> >+continue;
> 
> This seems like the wrong test.  If we're currently initializing a
> subobject, then we don't want to initialize any of our virtual base
> fields unless they are primary to the current type.  We don't need
> to consider the complete object type at all.
> 
> I'm also rather nervous about using is_*_base_of tests given that a
> class can have multiple indirect bases of a particular type.
> Whether or not there is a virtual base T of U isn't important; what
> is important is whether the current field represents a virtual base.

Do we need to redo parts of class.c anyway?  From what I understand, the
problematic vtbl pointers are at the end of the base types and DECL_SIZE
is set to the CLASSTYPE_AS_BASE type size, thus those pointers ought to
be at or beyond the containing field's size.
So, can't we simply skip subfields whose bit_position is equal or larger
to containing field's size?  Something like (works on the testcase from this
PR, otherwise untested):

--- gcc/cp/init.c.jj2011-03-11 08:06:36.0 +0100
+++ gcc/cp/init.c   2011-03-11 08:40:29.321401994 +0100
@@ -142,8 +142,9 @@ initialize_vtbl_ptrs (tree addr)
zero-initialization does not simply mean filling the storage with
zero bytes.  */
 
-tree
-build_zero_init (tree type, tree nelts, bool static_storage_p)
+static tree
+build_zero_init_1 (tree type, tree nelts, bool static_storage_p,
+  tree field_size)
 {
   tree init = NULL_TREE;
 
@@ -188,15 +189,32 @@ build_zero_init (tree type, tree nelts, 
  if (TREE_CODE (field) != FIELD_DECL)
continue;
 
+ /* Don't add virtual bases for base classes if they are beyond
+the size of the current field, that means it is present
+somewhere else in the object.  */
+ if (field_size)
+   {
+ tree bitpos = bit_position (field);
+ if (TREE_CODE (bitpos) == INTEGER_CST
+ && !tree_int_cst_lt (bitpos, field_size))
+   continue;
+   }
+
  /* Note that for class types there will be FIELD_DECLs
 corresponding to base classes as well.  Thus, iterating
 over TYPE_FIELDs will result in correct initialization of
 all of the subobjects.  */
  if (!static_storage_p || !zero_init_p (TREE_TYPE (field)))
{
- tree value = build_zero_init (TREE_TYPE (field),
-   /*nelts=*/NULL_TREE,
-   static_storage_p);
+ tree new_field_size
+   = (DECL_FIELD_IS_BASE (field)
+  && DECL_SIZE (field)
+  && TREE_CODE (DECL_SIZE (field)) == INTEGER_CST)
+ ? DECL_SIZE (field) : NULL_TREE;
+ tree value = build_zero_init_1 (TREE_TYPE (field),
+ /*nelts=*/NULL_TREE,
+ static_storage_p,
+ new_field_size);
  if (value)
CONSTRUCTOR_APPEND_ELT(v, field, value);
}
@@ -244,9 +262,9 @@ build_zero_init (tree type, tree nelts, 
ce->index = build2 (RANGE_EXPR, sizetype, size_zero_node,
max_index);
 
- ce->value = build_zero_init (TREE_TYPE (type),
-  /*nelts=*/NULL_TREE,
-  static_storage_p);
+ ce->value = build_zero_init_1 (TREE_TYPE (type),
+/*nelts=*/NULL_TREE,
+static_storage_p, NULL_TREE);
}
 
   /* Build a constructor to contain the initializations.  */
@@ -264,6 +282,12 @@ build_zero_init (tree type, tree nelts, 
   return init;
 }
 
+tree
+build_zero_init (tree type, tree nelts, bool static_storage_p)
+{
+  return build_zero_init_1 (type, nelts, static_storage_p, NULL_TREE);
+}
+
 /* Return a suitable initializer for value-initializing an object of type
TYPE, as described in [dcl.init].  */
 


Jakub

Re: [PATCH 02/18] enforce TREE_CHAIN and TREE_TYPE accesses

[Mike Stump]

The objective c bits are ok.

Re: [4.7 PATCH 00/18] slim down a number of tree nodes

[Mike Stump]

On Mar 10, 2011, at 8:23 PM, Nathan Froyd  wrote:
> This patch series does something similar to what

I am curious what the speed differences are.

Re: [PATCH] PR c++/PR48035

[Jakub Jelinek]

On Fri, Mar 11, 2011 at 09:01:40AM +0100, Jakub Jelinek wrote:
> Do we need to redo parts of class.c anyway?  From what I understand, the
> problematic vtbl pointers are at the end of the base types and DECL_SIZE
> is set to the CLASSTYPE_AS_BASE type size, thus those pointers ought to
> be at or beyond the containing field's size.
> So, can't we simply skip subfields whose bit_position is equal or larger
> to containing field's size?  Something like (works on the testcase from this
> PR, otherwise untested):

Or, in the simplify_aggr_init case where the created tree is handed
immediately to the gimplifier, there is IMHO no point in initializing
all fields to zero when the gimplifier throws that immediately away again.

So something like following works too.  But I have no idea about what
the C++ FE does with all other build_zero_init calls and whether just
returning empty CONSTRUCTOR would work in those cases too or not.

--- gcc/cp/semantics.c.jj   2011-03-08 11:39:32.516389675 +0100
+++ gcc/cp/semantics.c  2011-03-11 09:27:22.340671253 +0100
@@ -3379,8 +3379,18 @@ simplify_aggr_init_expr (tree *tp)
 
   if (AGGR_INIT_ZERO_FIRST (aggr_init_expr))
 {
-  tree init = build_zero_init (type, NULL_TREE,
-  /*static_storage_p=*/false);
+  tree init;
+  /* Empty CONSTRUCTOR is the middle-end alternative of zero
+initialization, so avoid creating a full CONSTRUCTOR
+which will be thrown away immediately.  */
+  if (CLASS_TYPE_P (type) || TREE_CODE (type) == ARRAY_TYPE)
+   {
+ init = build_constructor (type, NULL);
+ TREE_CONSTANT (init) = 1;
+   }
+  else
+   init = build_zero_init (type, NULL_TREE,
+   /*static_storage_p=*/false);
   init = build2 (INIT_EXPR, void_type_node, slot, init);
   call_expr = build2 (COMPOUND_EXPR, TREE_TYPE (call_expr),
  init, call_expr);

Jakub

[PING] 3 pending patches

[Andreas Krebbel]

This one is important to me for 4.6.0. This problem causes wrong code
to be generated for decimal floating point programs:

[PATCH] Fix PR46399 - missing mode promotion for libcall args - updated
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00141.html


To my understandig this is a testcase bug.  Probably the warning is
expected in that line only because it happens to appear there on x86.

[PATCH] Fix PR39246 move uninitialized var warning
http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01638.html


A minor rtx unsharing problem with a simple fix (perhaps even
obvious?):

[PATCH] recog.c: Fix RTX unsharing in change groups
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00187.html

Bye,

-Andreas-

Re: [patch, score] Remove score3 from score backend, delete unusual insn generate

[Paolo Bonzini]

On 03/11/2011 07:16 AM, Liqin Chen wrote:

@@ -181,10 +181,8 @@ score_output_mi_thunk (FILE *file, tree
 HOST_WIDE_INT delta, HOST_WIDE_INT vcall_offset,
 tree function)
  {
-  if (TARGET_SCORE5 || TARGET_SCORE5U || TARGET_SCORE7 || TARGET_SCORE7D)
+  if (TARGET_SCORE7 || TARGET_SCORE7D)
  score7_output_mi_thunk (file, thunk_fndecl, delta, vcall_offset, 
function);
-  else if (TARGET_SCORE3)
-score3_output_mi_thunk (file, thunk_fndecl, delta, vcall_offset, function);
else
  gcc_unreachable ();
  }


Can you please in a follow-up merge score.c and score7.c, so that you 
can remove these forwarding functions?


Paolo

Re: [C++0x patch] constexpr in attribute argument

[Rodrigo Rivas]

On Fri, Mar 11, 2011 at 6:51 AM, Jason Merrill  wrote:
> How about just calling maybe_constant_value call after the
> fold_non_dependent_expr call in cp_parser_parenthesized_expression_list?

Well, I first tried something like this, but the key problem is the
*non_dependent* part, so it does nothing if the expression involves
templates:

$ g++ -std=gnu++0x constexpr-attribute.C
.../constexpr-attribute.C: At global scope:
.../constexpr-attribute.C: In instantiation of S3:
.../constexpr-attribute.C:63:9:   instantiated from here
.../constexpr-attribute.C:59:44: error: requested alignment is not a constant
 void fun() [with T = int]
.../constexpr-attribute.C:33:14:   instantiated from here
.../constexpr-attribute.C:24:7: error: requested alignment is not a constant
.../constexpr-attribute.C:25:7: error: requested alignment is not a constant

BTW, a general question, why isn't there a call to
maybe_constant_value just at the end of fold_non_dependent_expr?

My patch calls maybe_constant_value after taking away any dependent
expression (cplus_decl_attributes does all the job).

--
Rodrigo

[PATCH, 4.6] Do not create new cgraph noes in the verifier

[Martin Jambor]

Hi,

while working on removing lazy cgraph node creation I have noticed
that we might do that even in the call graph verifier which certainly
looks undesirable.  Richi pre-approved removing it on IRC but I am not
sure whether that was for 4.6.  On the other hand I guess the change
is rather obvious and the verifier is disabled with release checking
and so I'd prefer to commit it now.  Is it OK?

Bootstrapped and tested on x86_63-linux without any problems.

Thanks,

Martin


2011-03-10  Martin Jambor  

* cgraphunit.c (verify_cgraph_node): Call cgraph_get_node instead of
cgraph_node.

Index: src/gcc/cgraphunit.c
===
--- src.orig/gcc/cgraphunit.c
+++ src/gcc/cgraphunit.c
@@ -551,7 +551,7 @@ verify_cgraph_node (struct cgraph_node *
   error_found = true;
 }
 
-  if (!cgraph_node (node->decl))
+  if (!cgraph_get_node (node->decl))
 {
   error ("node not found in cgraph_hash");
   error_found = true;

[PATCH, 4.7] Have all inlining destinations "analyzed"

[Martin Jambor]

Hi,

after I simply moved id->dst_node->analyzed check from
expand_call_inline to optimize_inline_calls I tried asserting it there
instead.  When running testsuite I found out this works for everything
but mudflap which adds new nodes late with cgraph_add_new_function
which runs the inliner on nodes which do not have their analyzed flag
set.  I believe that we can "fix" that by running
cgraph_analyze_function on these new functions and test results seem
to agree.  Does the idea look sane?

I have bootstrapped and tested the following patch on x86_64-linux on
both trunk and pretty-ipa.  Can I commit it now to pretty-ipa and to
trunk once stage1 opens?

Thanks,

Martin



Index: src/gcc/tree-inline.c
===
--- src.orig/gcc/tree-inline.c
+++ src/gcc/tree-inline.c
@@ -3766,11 +3766,6 @@ expand_call_inline (basic_block bb, gimp
   if (gimple_code (stmt) != GIMPLE_CALL)
 goto egress;
 
-  /* Objective C and fortran still calls tree_rest_of_compilation directly.
- Kill this check once this is fixed.  */
-  if (!id->dst_node->analyzed)
-goto egress;
-
   cg_edge = cgraph_edge (id->dst_node, stmt);
   gcc_checking_assert (cg_edge);
   /* First, see if we can figure out what function is being called.
@@ -4203,6 +4198,7 @@ optimize_inline_calls (tree fn)
   memset (&id, 0, sizeof (id));
 
   id.src_node = id.dst_node = cgraph_node (fn);
+  gcc_assert (id.dst_node->analyzed);
   id.dst_fn = fn;
   /* Or any functions that aren't finished yet.  */
   if (current_function_decl)
Index: src/gcc/cgraph.c
===
--- src.orig/gcc/cgraph.c
+++ src/gcc/cgraph.c
@@ -2495,11 +2495,11 @@ cgraph_add_new_function (tree fndecl, bo
   case CGRAPH_STATE_FINISHED:
/* At the very end of compilation we have to do all the work up
   to expansion.  */
+   node = cgraph_node (fndecl);
+   cgraph_analyze_function (node);
push_cfun (DECL_STRUCT_FUNCTION (fndecl));
current_function_decl = fndecl;
gimple_register_cfg_hooks ();
-   if (!lowered)
-  tree_lowering_passes (fndecl);
bitmap_obstack_initialize (NULL);
if (!gimple_in_ssa_p (DECL_STRUCT_FUNCTION (fndecl)))
  execute_pass_list (pass_early_local_passes.pass.sub);
Index: src/gcc/cgraph.h
===
--- src.orig/gcc/cgraph.h
+++ src/gcc/cgraph.h
@@ -618,6 +618,7 @@ bool varpool_used_from_object_file_p (st
 extern FILE *cgraph_dump_file;
 void cgraph_finalize_function (tree, bool);
 void cgraph_mark_if_needed (tree);
+void cgraph_analyze_function (struct cgraph_node *);
 void cgraph_finalize_compilation_unit (void);
 void cgraph_optimize (void);
 void cgraph_mark_needed_node (struct cgraph_node *);
Index: src/gcc/cgraphunit.c
===
--- src.orig/gcc/cgraphunit.c
+++ src/gcc/cgraphunit.c
@@ -143,7 +143,6 @@ static void cgraph_expand_all_functions
 static void cgraph_mark_functions_to_output (void);
 static void cgraph_expand_function (struct cgraph_node *);
 static void cgraph_output_pending_asms (void);
-static void cgraph_analyze_function (struct cgraph_node *);
 
 FILE *cgraph_dump_file;
 
@@ -773,7 +772,7 @@ cgraph_output_pending_asms (void)
 }
 
 /* Analyze the function scheduled to be output.  */
-static void
+void
 cgraph_analyze_function (struct cgraph_node *node)
 {
   tree save = current_function_decl;

Re: [PATCH, 4.6] Do not create new cgraph noes in the verifier

[Richard Guenther]

On Fri, 11 Mar 2011, Martin Jambor wrote:

> Hi,
> 
> while working on removing lazy cgraph node creation I have noticed
> that we might do that even in the call graph verifier which certainly
> looks undesirable.  Richi pre-approved removing it on IRC but I am not
> sure whether that was for 4.6.  On the other hand I guess the change
> is rather obvious and the verifier is disabled with release checking
> and so I'd prefer to commit it now.  Is it OK?
> 
> Bootstrapped and tested on x86_63-linux without any problems.

Ok.

Thanks,
Richard.


> Thanks,
> 
> Martin
> 
> 
> 2011-03-10  Martin Jambor  
> 
>   * cgraphunit.c (verify_cgraph_node): Call cgraph_get_node instead of
>   cgraph_node.
> 
> Index: src/gcc/cgraphunit.c
> ===
> --- src.orig/gcc/cgraphunit.c
> +++ src/gcc/cgraphunit.c
> @@ -551,7 +551,7 @@ verify_cgraph_node (struct cgraph_node *
>error_found = true;
>  }
>  
> -  if (!cgraph_node (node->decl))
> +  if (!cgraph_get_node (node->decl))
>  {
>error ("node not found in cgraph_hash");
>error_found = true;
> 
> 

-- 
Richard Guenther 
Novell / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex

[PATCH] Fixup testcase for PR47278

[Richard Guenther]

I forgot to check for visibility support.  I've also copied the
testcases to trunk.

Richard.

2011-03-11  Richard Guenther  

PR tree-optimization/47278
* gcc.dg/torture/pr47278-1.c: Require visibility support.
* gcc.dg/torture/pr47278-2.c: Likewise.

Index: gcc/testsuite/gcc.dg/torture/pr47278-1.c
===
--- gcc/testsuite/gcc.dg/torture/pr47278-1.c(revision 170867)
+++ gcc/testsuite/gcc.dg/torture/pr47278-1.c(working copy)
@@ -1,4 +1,5 @@
 /* { dg-do run } */
+/* { dg-require-visibility "" } */
 /* { dg-additional-sources "pr47278-2.c" } */
 
 int foo (void) { return 1; }
Index: gcc/testsuite/gcc.dg/torture/pr47278-2.c
===
--- gcc/testsuite/gcc.dg/torture/pr47278-2.c(revision 170867)
+++ gcc/testsuite/gcc.dg/torture/pr47278-2.c(working copy)
@@ -1,3 +1,5 @@
+/* { dg-require-visibility "" } */
+
 extern void abort (void);
 
 int __attribute__((weak,visibility("hidden"))) foo (void)

Re: [PATCH][C] Fix PR47939

[Richard Guenther]

On Thu, 10 Mar 2011, Joseph S. Myers wrote:

> On Wed, 2 Mar 2011, Richard Guenther wrote:
> 
> > 2011-03-02  Richard Guenther  
> > 
> > PR c/47939
> > * c-decl.c (grokdeclarator): Drop to the main variant only
> > for array types.  Drop flag_gen_aux_info check.
> 
> I can't convince myself that this is safe - that is, that it will maintain 
> the invariant that TYPE_MAIN_VARIANT for an array type always points to a 
> version where the ultimate element type is unqualified.  The problem would 
> be where the type from the declaration specifiers is a qualified type, not 
> an array type, but becomes an array element type through array declarators 
> being processed by grokdeclarator, and so arrays are built up directly 
> with qualified element type without the unqualified variants being built 
> first to become the main variants.  It certainly appears that in a case 
> such as
> 
> typedef const int T;
> T a[10];
> const int b[10];
> 
> you get multiple copies of the const int[10] type, some of which have a 
> const int[10] variant as their main variant (incorrect) and some of which 
> have an int[10] variant as their main variant (correct); the canonical 
> types look rather odd as well.  It's reasonable have multiple copies here 
> - for the type T[10] to remember the type name T it was derived from - but 
> in such a case they should still all be on the variant chain for a single 
> int[10] main variant.

Indeed.  I tried to let the array case alone (because it's so
complicated) but failed to do so.  Appearantly

  if (declarator->kind == cdk_array && TYPE_QUALS (element_type))
type = TYPE_MAIN_VARIANT (type);

leaves it alone (and doesn't emit a DW_TAG_typedef for T for your
testcase).  Thus out of the set of testcases I added the array
case now fails with the above (as I'd have expected but were of
course positively surprised as it didn't ...).

I verified the main variants and canonical types are sane with
the above variant for your testcase.

If you think such change isn't safe either I'll pursue a dwarf2out.c
local change, somehow forcing out the typedef DIE even if it is unused.
I don't feel at home in the grokdeclarator dungeon.

Thanks,
Richard.

Re: [patch, score] Remove score3 from score backend, delete unusual insn generate

[Liqin Chen]

2011/3/11 Paolo Bonzini :
> On 03/11/2011 07:16 AM, Liqin Chen wrote:
>
> Can you please in a follow-up merge score.c and score7.c, so that you can
> remove these forwarding functions?
>

OK, We will do it.

Thanks,
--liqin

Re: [PATCH 14/18] move TS_STATEMENT_LIST to be a substructure of TS_TYPED

[Nathan Froyd]

On Fri, Mar 11, 2011 at 01:01:37AM -0500, Jason Merrill wrote:
> On 03/10/2011 11:23 PM, Nathan Froyd wrote:
>> The new checks in add_stmt are
>> required to make sure that cur_stmt_list can always point at something
>> when calling append_to_statement_list_force.
>
> Why haven't we already pushed before we get to add_stmt?

That's a good question.  Possibly as a result of
append_to_statement_list_1 helpfully noticing that if we pass in a
pointer to NULL, it goes ahead and creates a list for us.  This works
nicely for the TREE_CHAIN-based stack, but not so nicely for the
VEC-based stack.

One wonders if the NULL checking in append_to_statement_list_1 could go
away...

-Nathan

Re: [build, lto] Only accept -fuse-linker-plugin if linker supports -plugin (PR lto/46944)

[Richard Guenther]

On Thu, 10 Mar 2011, Rainer Orth wrote:

> Richard Guenther  writes:
> 
> >> > Can we to fix 46944 change the dejagnu require-linker-plugin
> >> > to check if a linker plugin is used by default and not add
> >> > -fuse-linker-plugin?
> >> 
> >> That might be involved since it requires parsing gcc -Wl,-debug output.
> >> I suppose the solution outlined above is simpler and thus more robust.
> >
> > It might be as simple as
> >
> > int res;
> > int main() { int x; asm ("mov res, %0" : x(g)); return x; }
> >
> > which should fail to link with the plugin only (but yes, requies
> > target dependent assembly ...).
> 
> ... which I'd consider far too complicated/hard to maintain to consider.
> 
> > Or, use -save-temps and check for the existence of the resolution
> > file for int main() {}.  It should be named t.res for gcc -o t t.c -flto.
> 
> Only with -save-temps, otherwise it's some random file in /var/tmp.  But
> even so the file is removed immediately.

The following seems to work for me

Index: gcc/testsuite/lib/target-supports.exp
===
--- gcc/testsuite/lib/target-supports.exp   (revision 170868)
+++ gcc/testsuite/lib/target-supports.exp   (working copy)
@@ -1011,9 +1011,20 @@ proc check_effective_target_static_libgf
 }
 
 proc check_linker_plugin_available { } {
-  return [check_no_compiler_messages_nocache linker_plugin executable {
+  set result [eval check_compile { linker_plugin object {
  int main() { return 0; }
-  } "-flto -fuse-linker-plugin"]
+  } "-flto" } ]
+  set lines [lindex $result 0]
+  set output [lindex $result 1]
+  set result [gcc_target_compile $output linker_plugin[pid] executable { 
additional_flags=-flto additional_flags=-flto-partition=none 
additional_flags=-save-temps } ]
+  remote_file build delete $output
+  remote_file build delete linker_plugin[pid]
+  remote_file build delete linker_plugin[pid].s
+  if [file exists linker_plugin[pid].res] {
+remote_file build delete linker_plugin[pid].res
+return 1
+  }
+  return 0
 }
 
 # Return 1 if the target supports executing 750CL paired-single 
instructions, 0

it leaves an argument file in /tmp but otherwise nothing.

Eventually scanning -v output for '-plugin' is better.

> And even if we decide to fix PR lto/46944 like this, we're still left
> with the problem of users invoking gcc with -fuse-linker-plugin and
> getting either strange errors or no effect instead of a clear
> diagnostic.

Sure.  But just disabling linker-plugin support for almost everyone
doesn't sound like a good solution either.

I'm ok with fixing 46944 somehow at this point, as well as making
-fuse-linker-plugin the default only for known good linker versions.

Richard.

Re: 4.5 backport request...

[Richard Guenther]

On Thu, Mar 10, 2011 at 10:07 PM, DJ Delorie  wrote:
>
>> This doesn't look like a regression fix.  The changelog doesn't tell
>> if it is mere replacing macros by hooks, so please also attach the
>> patch.
>
> The original patch is here:
>
> http://gcc.gnu.org/ml/gcc/2010-10/msg00076.html
>
> It would need editing for 4.5, which I'll do if there's a good chance
> the change will be accepted into 4.5.
>
> It's just replacing macros with hooks.  The macros do not pass enough
> information to the backend to do insn-specific alignments, which the
> RX needs for optimal performance.  The hooks have an additional
> argument, which is the insn which will be aligned.
>
> On the RX, you pay a one cycle penalty if you branch to an insn which
> spans a fetch line.

I don't think this is suitable for the branch.  Any reason why you can't work
on the trunk?

Richard.

Re: Problem with procedure pointers

[Tobias Burnus]

On 03/10/2011 08:55 PM, Janus Weil wrote:
Ok, since you guys seem to agree on that, here is the patch without 
module version bumping, but this time complete with test case and 
ChangeLog.

Ok for trunk?


OK. Thanks for the patch.

Tobias


2011-03-10  Janus Weil

PR fortran/47768
* module.c (ab_attribute,attr_bits): Add AB_PROC_POINTER_COMP.
(mio_symbol_attribute): Handle attribute 'proc_pointer_comp'.

2011-03-10  Janus Weil

PR fortran/47768
* gfortran.dg/proc_ptr_comp_31.f90: New.

Re: [PATCH 07/18] generalize build_case_label to the rest of the compiler

[Joseph S. Myers]

On Thu, 10 Mar 2011, Nathan Froyd wrote:

> This patch does lose location information on CASE_LABEL_EXPRs from the C
> family of front-ends; it did not seem worth it to have a number of
> places pass input_location when said information isn't even used.  I'm
> happy to add the location_t argument back to CASE_LABEL_EXPRs if people
> think that's worthwhile.

Since implicit use of input_location is deprecated and should be being 
phased out (making more locations explicit - including explicit 
input_location until the places using it have a better location 
available), I think you should keep the location argument.

The C front-end changes in this patch series (including c-family changes) 
are otherwise OK.

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

Re: [PATCH 01/18] add typed_tree structure

[Richard Guenther]

On Fri, Mar 11, 2011 at 5:23 AM, Nathan Froyd  wrote:
> The first step in removing TREE_CHAIN (and even TREE_TYPE) from a select
> few nodes is to create separate substructures for trees-with-type and
> trees-with-chain.  Since trees-with-type but no chain are expected to be
> more common that vice versa, make the hierarchy reflect that.  Modify a
> few macros to reflect the new inheritance structure, and add a new tree
> structure enum for the new structure.  Make note that we support the new
> tree structure in the LTO streamer, even though we don't need to do
> anything about it yet.

Ok for 4.7 (I assume you have tested each patch separately for _all_
languages, or if not, will do so before applying).

Thanks,
Richard.

> -Nathan
>
> gcc/
>        * tree.h (struct typed_tree): New.
>        (struct tree_common): Include it instead of tree_base.
>        (TREE_TYPE): Update for new location of type field.
>        (TYPE_USER_ALIGN, TYPE_PACKED): Refer to base field directly.
>        (DECL_USER_ALIGN, DECL_PACKED): Likewise.
>        (union tree_node): Add typed field.
>        * treestruct.def (TS_TYPED): New.
>        * lto-streamer.c (check_handled_ts_structures): Handle it.
>        * tree.c (MARK_TS_TYPED): New macro.
>        (MARK_TS_COMMON): Call it instead of MARK_TS_BASE.
>
> diff --git a/gcc/lto-streamer.c b/gcc/lto-streamer.c
> index dba9d2d..546228c 100644
> --- a/gcc/lto-streamer.c
> +++ b/gcc/lto-streamer.c
> @@ -270,6 +270,7 @@ check_handled_ts_structures (void)
>   /* These are the TS_* structures that are either handled or
>      explicitly ignored by the streamer routines.  */
>   handled_p[TS_BASE] = true;
> +  handled_p[TS_TYPED] = true;
>   handled_p[TS_COMMON] = true;
>   handled_p[TS_INT_CST] = true;
>   handled_p[TS_REAL_CST] = true;
> diff --git a/gcc/tree.c b/gcc/tree.c
> index c947072..798bc08 100644
> --- a/gcc/tree.c
> +++ b/gcc/tree.c
> @@ -356,9 +356,15 @@ initialize_tree_contains_struct (void)
>     tree_contains_struct[C][TS_BASE] = 1;              \
>   } while (0)
>
> -#define MARK_TS_COMMON(C)                              \
> +#define MARK_TS_TYPED(C)                               \
>   do {                                                 \
>     MARK_TS_BASE (C);                                  \
> +    tree_contains_struct[C][TS_TYPED] = 1;             \
> +  } while (0)
> +
> +#define MARK_TS_COMMON(C)                              \
> +  do {                                                 \
> +    MARK_TS_TYPED (C);                                 \
>     tree_contains_struct[C][TS_COMMON] = 1;            \
>   } while (0)
>
> diff --git a/gcc/tree.h b/gcc/tree.h
> index a49e335..2f772e1 100644
> --- a/gcc/tree.h
> +++ b/gcc/tree.h
> @@ -407,12 +407,16 @@ struct GTY(()) tree_base {
>   unsigned address_space : 8;
>  };
>
> -struct GTY(()) tree_common {
> +struct GTY(()) typed_tree {
>   struct tree_base base;
> -  tree chain;
>   tree type;
>  };
>
> +struct GTY(()) tree_common {
> +  struct typed_tree typed;
> +  tree chain;
> +};
> +
>  /* The following table lists the uses of each of the above flags and
>    for which types of nodes they are defined.
>
> @@ -869,7 +873,7 @@ enum tree_node_structure_enum {
>    In VECTOR_TYPE nodes, this is the type of the elements.  */
>  #define TREE_TYPE(NODE) __extension__ \
>  (*({__typeof (NODE) const __t = (NODE);                                      
>   \
> -    &__t->common.type; }))
> +    &__t->typed.type; }))
>
>  extern void tree_contains_struct_check_failed (const_tree,
>                                               const enum 
> tree_node_structure_enum,
> @@ -2151,7 +2155,7 @@ extern enum machine_mode vector_type_mode (const_tree);
>
>  /* 1 if the alignment for this type was requested by "aligned" attribute,
>    0 if it is the default for this type.  */
> -#define TYPE_USER_ALIGN(NODE) (TYPE_CHECK (NODE)->common.base.user_align)
> +#define TYPE_USER_ALIGN(NODE) (TYPE_CHECK (NODE)->base.user_align)
>
>  /* The alignment for NODE, in bytes.  */
>  #define TYPE_ALIGN_UNIT(NODE) (TYPE_ALIGN (NODE) / BITS_PER_UNIT)
> @@ -2289,7 +2293,7 @@ extern enum machine_mode vector_type_mode (const_tree);
>
>  /* Indicated that objects of this type should be laid out in as
>    compact a way as possible.  */
> -#define TYPE_PACKED(NODE) (TYPE_CHECK (NODE)->common.base.packed_flag)
> +#define TYPE_PACKED(NODE) (TYPE_CHECK (NODE)->base.packed_flag)
>
>  /* Used by type_contains_placeholder_p to avoid recomputation.
>    Values are: 0 (unknown), 1 (false), 2 (true).  Never access
> @@ -2632,7 +2636,7 @@ struct GTY(()) tree_decl_minimal {
>  /* Set if the alignment of this DECL has been set by the user, for
>    example with an 'aligned' attribute.  */
>  #define DECL_USER_ALIGN(NODE) \
> -  (DECL_COMMON_CHECK (NODE)->common.base.user_align)
> +  (DECL_COMMON_CHECK (NODE)->base.user_align)
>  /* Holds the machine mode corresponding to the declaration of a variable or
>    field.  Always equal to TYPE_MODE (TREE_TYPE (decl)) exc

Re: [PATCH 05/18] remove TREE_CHAIN from CONSTRUCTOR nodes

[Richard Guenther]

On Fri, Mar 11, 2011 at 5:23 AM, Nathan Froyd  wrote:
> A straightforward conversion.

Ok for 4.7.

Thanks,
Richard.

> -Nathan
>
> gcc/
>        * tree.h (struct tree_constructor): Include typed_tree instead of
>        tree_common.
>        * tree.c (initialize_tree_contains_struct): Mark TS_CONSTRUCTOR as
>        TS_TYPED instead of TS_COMMON.
>
> diff --git a/gcc/tree.c b/gcc/tree.c
> index 072ff19..da16641 100644
> --- a/gcc/tree.c
> +++ b/gcc/tree.c
> @@ -377,6 +377,7 @@ initialize_tree_contains_struct (void)
>        case TS_STRING:
>        case TS_COMPLEX:
>        case TS_SSA_NAME:
> +       case TS_CONSTRUCTOR:
>          MARK_TS_TYPED (code);
>          break;
>
> @@ -389,7 +390,6 @@ initialize_tree_contains_struct (void)
>        case TS_BLOCK:
>        case TS_BINFO:
>        case TS_STATEMENT_LIST:
> -       case TS_CONSTRUCTOR:
>        case TS_OMP_CLAUSE:
>        case TS_OPTIMIZATION:
>        case TS_TARGET_OPTION:
> diff --git a/gcc/tree.h b/gcc/tree.h
> index 80888bc..35479f9 100644
> --- a/gcc/tree.h
> +++ b/gcc/tree.h
> @@ -1614,7 +1614,7 @@ DEF_VEC_O(constructor_elt);
>  DEF_VEC_ALLOC_O(constructor_elt,gc);
>
>  struct GTY(()) tree_constructor {
> -  struct tree_common common;
> +  struct typed_tree typed;
>   VEC(constructor_elt,gc) *elts;
>  };
>
> --
> 1.7.0.4
>
>

Re: [PATCH 03/18] remove TREE_CHAIN from *_CST nodes

[Richard Guenther]

On Fri, Mar 11, 2011 at 5:23 AM, Nathan Froyd  wrote:
> *_CST nodes don't need TREE_CHAIN.  Make them include typed_tree instead,
> mark them as such in initialize_tree_contains_struct, and don't print out
> their TREE_CHAIN.

Ok for 4.7 if it bootstraps and tests for all languages.

Richard.

> -Nathan
>
> gcc/
>        * tree.h (struct tree_int_cst, struct real_value): Include typed_tree
>        instead of tree_common.
>        (struct tree_fixed_cst, struct tree_string, struct tree_complex):
>        Likewise.
>        * tree.c (initialize_tree_contains_struct): Mark such nodes as being
>        TS_TYPED rather than TS_COMMON.
>        * print-tree.c (print_node): Don't print TREE_CHAIN for constants.
>
> diff --git a/gcc/print-tree.c b/gcc/print-tree.c
> index b0c6899..3b5edeb 100644
> --- a/gcc/print-tree.c
> +++ b/gcc/print-tree.c
> @@ -853,11 +853,6 @@ print_node (FILE *file, const char *prefix, tree node, 
> int indent)
>              }
>            fputc ('\"', file);
>          }
> -         /* Print the chain at second level.  */
> -         if (indent == 4)
> -           print_node (file, "chain", TREE_CHAIN (node), indent + 4);
> -         else
> -           print_node_brief (file, "chain", TREE_CHAIN (node), indent + 4);
>          break;
>
>        case IDENTIFIER_NODE:
> diff --git a/gcc/tree.c b/gcc/tree.c
> index 68f40c9..7d73c74 100644
> --- a/gcc/tree.c
> +++ b/gcc/tree.c
> @@ -370,15 +370,15 @@ initialize_tree_contains_struct (void)
>          break;
>
>        case TS_COMMON:
> -         MARK_TS_TYPED (code);
> -         break;
> -
>        case TS_INT_CST:
>        case TS_REAL_CST:
>        case TS_FIXED_CST:
>        case TS_VECTOR:
>        case TS_STRING:
>        case TS_COMPLEX:
> +         MARK_TS_TYPED (code);
> +         break;
> +
>        case TS_IDENTIFIER:
>        case TS_DECL_MINIMAL:
>        case TS_TYPE:
> diff --git a/gcc/tree.h b/gcc/tree.h
> index 4ad2d3e..11c2f83 100644
> --- a/gcc/tree.h
> +++ b/gcc/tree.h
> @@ -1456,7 +1456,7 @@ extern void omp_clause_range_check_failed (const_tree, 
> const char *, int,
>        && TREE_INT_CST_LOW (A) < TREE_INT_CST_LOW (B)))
>
>  struct GTY(()) tree_int_cst {
> -  struct tree_common common;
> +  struct typed_tree typed;
>   double_int int_cst;
>  };
>
> @@ -1469,7 +1469,7 @@ struct real_value;
>  #define TREE_REAL_CST(NODE) (*TREE_REAL_CST_PTR (NODE))
>
>  struct GTY(()) tree_real_cst {
> -  struct tree_common common;
> +  struct typed_tree typed;
>   struct real_value * real_cst_ptr;
>  };
>
> @@ -1481,7 +1481,7 @@ struct fixed_value;
>  #define TREE_FIXED_CST(NODE) (*TREE_FIXED_CST_PTR (NODE))
>
>  struct GTY(()) tree_fixed_cst {
> -  struct tree_common common;
> +  struct typed_tree typed;
>   struct fixed_value * fixed_cst_ptr;
>  };
>
> @@ -1491,7 +1491,7 @@ struct GTY(()) tree_fixed_cst {
>   ((const char *)(STRING_CST_CHECK (NODE)->string.str))
>
>  struct GTY(()) tree_string {
> -  struct tree_common common;
> +  struct typed_tree typed;
>   int length;
>   char str[1];
>  };
> @@ -1501,7 +1501,7 @@ struct GTY(()) tree_string {
>  #define TREE_IMAGPART(NODE) (COMPLEX_CST_CHECK (NODE)->complex.imag)
>
>  struct GTY(()) tree_complex {
> -  struct tree_common common;
> +  struct typed_tree typed;
>   tree real;
>   tree imag;
>  };
> @@ -1510,7 +1510,7 @@ struct GTY(()) tree_complex {
>  #define TREE_VECTOR_CST_ELTS(NODE) (VECTOR_CST_CHECK (NODE)->vector.elements)
>
>  struct GTY(()) tree_vector {
> -  struct tree_common common;
> +  struct typed_tree typed;
>   tree elements;
>  };
>
> --
> 1.7.0.4
>
>

Re: [PATCH 04/18] remove TREE_CHAIN from SSA_NAME nodes

[Richard Guenther]

On Fri, Mar 11, 2011 at 5:23 AM, Nathan Froyd  wrote:
> This conversion is straightforward.  The tricky part is converting
> FREE_SSANAMES into a VEC to eliminate the only use of TREE_CHAIN on
> SSA_NAMEs.

Ok for 4.7.

Thanks,
Richard.

> -Nathan
>
> gcc/
>        * tree-flow.h (struct gimple_df): Make free_ssanames a VEC.
>        * tree-ssanames.c (fini_ssanames): VEC_free it.
>        (make_ssa_name_fn): Update for VECness of free_ssanames.
>        (release_ssa_name, release_dead_ssa_names): Likewise.
>        * tree.h (struct tree_ssa_name): Include typed_tree instead of
>        tree_common.
>        * tree.c (initialize_tree_contains_struct): Mark TS_SSA_NAME as
>        TS_TYPED instead of TS_COMMON.
>
> diff --git a/gcc/tree-flow.h b/gcc/tree-flow.h
> index 14c8827..6b48697 100644
> --- a/gcc/tree-flow.h
> +++ b/gcc/tree-flow.h
> @@ -61,7 +61,7 @@ struct GTY(()) gimple_df {
>   struct pointer_map_t * GTY((skip(""))) decls_to_pointers;
>
>   /* Free list of SSA_NAMEs.  */
> -  tree free_ssanames;
> +  VEC(tree,gc) *free_ssanames;
>
>   /* Hashtable holding definition for symbol.  If this field is not NULL, it
>      means that the first reference to this variable in the function is a
> diff --git a/gcc/tree-ssanames.c b/gcc/tree-ssanames.c
> index c76dba5..06cdbee 100644
> --- a/gcc/tree-ssanames.c
> +++ b/gcc/tree-ssanames.c
> @@ -96,7 +96,7 @@ void
>  fini_ssanames (void)
>  {
>   VEC_free (tree, gc, SSANAMES (cfun));
> -  FREE_SSANAMES (cfun) = NULL;
> +  VEC_free (tree, gc, FREE_SSANAMES (cfun));
>  }
>
>  /* Dump some simple statistics regarding the re-use of SSA_NAME nodes.  */
> @@ -124,10 +124,9 @@ make_ssa_name_fn (struct function *fn, tree var, gimple 
> stmt)
>   gcc_assert (DECL_P (var));
>
>   /* If our free list has an element, then use it.  */
> -  if (FREE_SSANAMES (fn))
> +  if (!VEC_empty (tree, FREE_SSANAMES (fn)))
>     {
> -      t = FREE_SSANAMES (fn);
> -      FREE_SSANAMES (fn) = TREE_CHAIN (FREE_SSANAMES (fn));
> +      t = VEC_pop (tree, FREE_SSANAMES (fn));
>  #ifdef GATHER_STATISTICS
>       ssa_name_nodes_reused++;
>  #endif
> @@ -234,9 +233,8 @@ release_ssa_name (tree var)
>       /* Note this SSA_NAME is now in the first list.  */
>       SSA_NAME_IN_FREE_LIST (var) = 1;
>
> -      /* And finally link it into the free list.  */
> -      TREE_CHAIN (var) = FREE_SSANAMES (cfun);
> -      FREE_SSANAMES (cfun) = var;
> +      /* And finally put it on the free list.  */
> +      VEC_safe_push (tree, gc, FREE_SSANAMES (cfun), var);
>     }
>  }
>
> @@ -334,8 +332,8 @@ replace_ssa_name_symbol (tree ssa_name, tree sym)
>  static unsigned int
>  release_dead_ssa_names (void)
>  {
> -  tree t, next;
> -  int n = 0;
> +  tree t;
> +  int n = VEC_length (tree, FREE_SSANAMES (cfun));
>   referenced_var_iterator rvi;
>
>   /* Current defs point to various dead SSA names that in turn point to
> @@ -343,17 +341,7 @@ release_dead_ssa_names (void)
>   FOR_EACH_REFERENCED_VAR (cfun, t, rvi)
>     set_current_def (t, NULL);
>   /* Now release the freelist.  */
> -  for (t = FREE_SSANAMES (cfun); t; t = next)
> -    {
> -      next = TREE_CHAIN (t);
> -      /* Dangling pointers might make GGC to still see dead SSA names, so it 
> is
> -        important to unlink the list and avoid GGC from seeing all subsequent
> -        SSA names.  In longer run we want to have all dangling pointers here
> -        removed (since they usually go through dead statements that consume
> -        considerable amounts of memory).  */
> -      TREE_CHAIN (t) = NULL_TREE;
> -      n++;
> -    }
> +  VEC_free (tree, gc, FREE_SSANAMES (cfun));
>   FREE_SSANAMES (cfun) = NULL;
>
>   statistics_counter_event (cfun, "SSA names released", n);
> diff --git a/gcc/tree.c b/gcc/tree.c
> index 7d73c74..072ff19 100644
> --- a/gcc/tree.c
> +++ b/gcc/tree.c
> @@ -376,6 +376,7 @@ initialize_tree_contains_struct (void)
>        case TS_VECTOR:
>        case TS_STRING:
>        case TS_COMPLEX:
> +       case TS_SSA_NAME:
>          MARK_TS_TYPED (code);
>          break;
>
> @@ -385,7 +386,6 @@ initialize_tree_contains_struct (void)
>        case TS_LIST:
>        case TS_VEC:
>        case TS_EXP:
> -       case TS_SSA_NAME:
>        case TS_BLOCK:
>        case TS_BINFO:
>        case TS_STATEMENT_LIST:
> diff --git a/gcc/tree.h b/gcc/tree.h
> index 11c2f83..80888bc 100644
> --- a/gcc/tree.h
> +++ b/gcc/tree.h
> @@ -1970,7 +1970,7 @@ typedef struct GTY(()) ssa_use_operand_d {
>  #define SSA_NAME_IMM_USE_NODE(NODE) SSA_NAME_CHECK (NODE)->ssa_name.imm_uses
>
>  struct GTY(()) tree_ssa_name {
> -  struct tree_common common;
> +  struct typed_tree typed;
>
>   /* _DECL wrapped by this SSA name.  */
>   tree var;
> --
> 1.7.0.4
>
>

Re: [PATCH 06/18] define CASE_CHAIN accessor for CASE_LABEL_EXPR

[Richard Guenther]

On Fri, Mar 11, 2011 at 5:23 AM, Nathan Froyd  wrote:
> This patch begins a subseries of patches aimed at removing TREE_CHAIN
> from expression trees.  tree-cfg.c uses TREE_CHAIN for some analysis
> steps on CASE_LABEL_EXPRs.  I looked at this for a while, thinking it'd
> be easy to use VECs instead, but AFAICS, it wasn't.  I went for the next
> best thing, hiding TREE_CHAIN usage behind CASE_CHAIN; doing this will
> enable swapping out the TREE_CHAIN for a TREE_OPERAND at a later point.

Ok for 4.7.

Thanks,
Richard.

> -Nathan
>
>        * tree.h (CASE_CHAIN): Define.
>        * tree-cfg.c (edge_to_cases_cleanup, get_cases_for_edge): Use it.
>        (gimple_redirect_edge_and_branch): Likewise.
>
> diff --git a/gcc/tree-cfg.c b/gcc/tree-cfg.c
> index 1f533a3..bdce4cb 100644
> --- a/gcc/tree-cfg.c
> +++ b/gcc/tree-cfg.c
> @@ -838,8 +838,8 @@ edge_to_cases_cleanup (const void *key ATTRIBUTE_UNUSED, 
> void **value,
>
>   for (t = (tree) *value; t; t = next)
>     {
> -      next = TREE_CHAIN (t);
> -      TREE_CHAIN (t) = NULL;
> +      next = CASE_CHAIN (t);
> +      CASE_CHAIN (t) = NULL;
>     }
>
>   *value = NULL;
> @@ -922,7 +922,7 @@ get_cases_for_edge (edge e, gimple t)
>       /* Add it to the chain of CASE_LABEL_EXPRs referencing E, or create
>         a new chain.  */
>       slot = pointer_map_insert (edge_to_cases, this_edge);
> -      TREE_CHAIN (elt) = (tree) *slot;
> +      CASE_CHAIN (elt) = (tree) *slot;
>       *slot = elt;
>     }
>
> @@ -4900,7 +4900,7 @@ gimple_redirect_edge_and_branch (edge e, basic_block 
> dest)
>              {
>                last = cases;
>                CASE_LABEL (cases) = label;
> -               cases = TREE_CHAIN (cases);
> +               cases = CASE_CHAIN (cases);
>              }
>
>            /* If there was already an edge in the CFG, then we need
> @@ -4909,8 +4909,8 @@ gimple_redirect_edge_and_branch (edge e, basic_block 
> dest)
>              {
>                tree cases2 = get_cases_for_edge (e2, stmt);
>
> -               TREE_CHAIN (last) = TREE_CHAIN (cases2);
> -               TREE_CHAIN (cases2) = first;
> +               CASE_CHAIN (last) = CASE_CHAIN (cases2);
> +               CASE_CHAIN (cases2) = first;
>              }
>            bitmap_set_bit (touched_switch_bbs, gimple_bb (stmt)->index);
>          }
> diff --git a/gcc/tree.h b/gcc/tree.h
> index 35479f9..58b3b9d 100644
> --- a/gcc/tree.h
> +++ b/gcc/tree.h
> @@ -1689,6 +1689,7 @@ extern void protected_set_expr_location (tree, 
> location_t);
>  #define CASE_LOW(NODE)                 TREE_OPERAND (CASE_LABEL_EXPR_CHECK 
> (NODE), 0)
>  #define CASE_HIGH(NODE)                TREE_OPERAND (CASE_LABEL_EXPR_CHECK 
> (NODE), 1)
>  #define CASE_LABEL(NODE)               TREE_OPERAND (CASE_LABEL_EXPR_CHECK 
> (NODE), 2)
> +#define CASE_CHAIN(NODE)               TREE_CHAIN (CASE_LABEL_EXPR_CHECK 
> (NODE))
>
>  /* The operands of a TARGET_MEM_REF.  Operands 0 and 1 have to match
>    corresponding MEM_REF operands.  */
> --
> 1.7.0.4
>
>

Re: [PATCH][C] Fix PR47939

[Joseph S. Myers]

On Fri, 11 Mar 2011, Richard Guenther wrote:

> Indeed.  I tried to let the array case alone (because it's so
> complicated) but failed to do so.  Appearantly
> 
>   if (declarator->kind == cdk_array && TYPE_QUALS (element_type))
> type = TYPE_MAIN_VARIANT (type);
> 
> leaves it alone (and doesn't emit a DW_TAG_typedef for T for your
> testcase).  Thus out of the set of testcases I added the array
> case now fails with the above (as I'd have expected but were of
> course positively surprised as it didn't ...).
> 
> I verified the main variants and canonical types are sane with
> the above variant for your testcase.
> 
> If you think such change isn't safe either I'll pursue a dwarf2out.c
> local change, somehow forcing out the typedef DIE even if it is unused.
> I don't feel at home in the grokdeclarator dungeon.

What I think is safe in grokdeclarator is using TYPE_MAIN_VARIANT here if 
*either* the type given in the declaration specifiers is an array type 
(TREE_CODE (type) == ARRAY_TYPE, as in your previous patch) *or* the first 
declarator that is not cdk_attrs is cdk_array (as in this version, but 
checking through a chain of declarator->declarator to find a possible 
cdk_array after a sequence of cdk_attrs).

(Aside from all this it is a longstanding known bug that the debug 
information for arrays of qualified types isn't quite right: PR 8354.)

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

Re: [PATCH 07/18] generalize build_case_label to the rest of the compiler

[Richard Guenther]

On Fri, Mar 11, 2011 at 2:01 PM, Joseph S. Myers
 wrote:
> On Thu, 10 Mar 2011, Nathan Froyd wrote:
>
>> This patch does lose location information on CASE_LABEL_EXPRs from the C
>> family of front-ends; it did not seem worth it to have a number of
>> places pass input_location when said information isn't even used.  I'm
>> happy to add the location_t argument back to CASE_LABEL_EXPRs if people
>> think that's worthwhile.
>
> Since implicit use of input_location is deprecated and should be being
> phased out (making more locations explicit - including explicit
> input_location until the places using it have a better location
> available), I think you should keep the location argument.
>
> The C front-end changes in this patch series (including c-family changes)
> are otherwise OK.

Yep, please pass UNKNOWN_LOCATION at callers that didn't set a
location (and add a location argument to build_case_label).

Thanks,
Richard.

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

Re: [PATCH 16/18] make TS_IDENTIFIER be a substructure of TS_BASE

[Richard Guenther]

On Fri, Mar 11, 2011 at 5:23 AM, Nathan Froyd  wrote:
> Now that we've done the requisite surgery on the C++ FE, we can
> eliminate TREE_CHAIN and TREE_TYPE from IDENTIFIER_NODEs.  Doing so
> turns up a couple different places that need to be tweaked.
>
> The bit I'm not quite sure about is free_lang_data_in_decl and
> find_decls_types_r.  Previously, due to C++ FE machinations, we'd free
> REAL_IDENTIFIER_TYPE_VALUE naturally, through punning of TREE_TYPE.  Now
> that we've shuffled that field into lang_identifier, that bit of
> identifiers won't get freed...and I don't know if that causes problems.
> Anybody more knowledgeable than I willing to weigh in on that?

At some point we should zero-out DECL/TYPE_LANG_SPECIFIC, I
don't remember why we don't do that.

The patch is ok for 4.7 anyway.

Thanks,
Richard.

> -Nathan
>
> gcc/
>        * print-tree.c (print_node): Check for TS_TYPED structures before
>        accessing TREE_TYPE.
>        * tree.h (struct tree_identifier): Inherit from tree_base, not
>        tree_common.
>        (HT_IDENT_TO_GCC_IDENT): Adjust for said change.
>        * tree.c (initialize_tree_contains_struct): Mark TS_IDENTIFIER as
>        TS_BASE instead of TS_COMMON.
>        (free_lang_data_in_decl): Don't set TREE_TYPE of DECL_NAME.
>        (find_decls_types_r): Check for TS_TYPED structures before accessing
>        TREE_TYPE.
>        * varasm.c (assemble_name): Remove assert.
>
> gcc/c-family/
>        * c-common.h (struct c_common_identifier): Inherit from tree_base,
>        not tree_common.
>
> diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
> index e7fe209..961dea7 100644
> --- a/gcc/c-family/c-common.h
> +++ b/gcc/c-family/c-common.h
> @@ -306,7 +306,7 @@ enum c_tree_index
>  /* Identifier part common to the C front ends.  Inherits from
>    tree_identifier, despite appearances.  */
>  struct GTY(()) c_common_identifier {
> -  struct tree_common common;
> +  struct tree_base base;
>   struct cpp_hashnode node;
>  };
>
> diff --git a/gcc/print-tree.c b/gcc/print-tree.c
> index d8acd1b..1a1e33f 100644
> --- a/gcc/print-tree.c
> +++ b/gcc/print-tree.c
> @@ -321,7 +321,7 @@ print_node (FILE *file, const char *prefix, tree node, 
> int indent)
>       if (indent <= 4)
>        print_node_brief (file, "type", TREE_TYPE (node), indent + 4);
>     }
> -  else
> +  else if (CODE_CONTAINS_STRUCT (code, TS_TYPED))
>     {
>       print_node (file, "type", TREE_TYPE (node), indent + 4);
>       if (TREE_TYPE (node))
> diff --git a/gcc/tree.c b/gcc/tree.c
> index 81ee05e..001e8c8 100644
> --- a/gcc/tree.c
> +++ b/gcc/tree.c
> @@ -366,6 +366,7 @@ initialize_tree_contains_struct (void)
>       switch (ts_code)
>        {
>        case TS_TYPED:
> +       case TS_IDENTIFIER:
>          MARK_TS_BASE (code);
>          break;
>
> @@ -383,7 +384,6 @@ initialize_tree_contains_struct (void)
>          MARK_TS_TYPED (code);
>          break;
>
> -       case TS_IDENTIFIER:
>        case TS_DECL_MINIMAL:
>        case TS_TYPE:
>        case TS_LIST:
> @@ -4495,10 +4495,6 @@ free_lang_data_in_decl (tree decl)
>   TREE_LANG_FLAG_5 (decl) = 0;
>   TREE_LANG_FLAG_6 (decl) = 0;
>
> -  /* Identifiers need not have a type.  */
> -  if (DECL_NAME (decl))
> -    TREE_TYPE (DECL_NAME (decl)) = NULL_TREE;
> -
>   free_lang_data_in_one_sizepos (&DECL_SIZE (decl));
>   free_lang_data_in_one_sizepos (&DECL_SIZE_UNIT (decl));
>   if (TREE_CODE (decl) == FIELD_DECL)
> @@ -4795,7 +4791,8 @@ find_decls_types_r (tree *tp, int *ws, void *data)
>       fld_worklist_push (BLOCK_ABSTRACT_ORIGIN (t), fld);
>     }
>
> -  fld_worklist_push (TREE_TYPE (t), fld);
> +  if (CODE_CONTAINS_STRUCT (TREE_CODE (t), TS_TYPED))
> +    fld_worklist_push (TREE_TYPE (t), fld);
>
>   return NULL_TREE;
>  }
> diff --git a/gcc/tree.h b/gcc/tree.h
> index c81186a..f4d18f8 100644
> --- a/gcc/tree.h
> +++ b/gcc/tree.h
> @@ -1529,11 +1529,11 @@ struct GTY(()) tree_vector {
>    pointer, and vice versa.  */
>
>  #define HT_IDENT_TO_GCC_IDENT(NODE) \
> -  ((tree) ((char *) (NODE) - sizeof (struct tree_common)))
> +  ((tree) ((char *) (NODE) - sizeof (struct tree_base)))
>  #define GCC_IDENT_TO_HT_IDENT(NODE) (&((struct tree_identifier *) 
> (NODE))->id)
>
>  struct GTY(()) tree_identifier {
> -  struct tree_common common;
> +  struct tree_base base;
>   struct ht_identifier id;
>  };
>
> diff --git a/gcc/varasm.c b/gcc/varasm.c
> index 76675cd..4c429de 100644
> --- a/gcc/varasm.c
> +++ b/gcc/varasm.c
> @@ -2300,7 +2300,6 @@ assemble_name (FILE *file, const char *name)
>       ultimate_transparent_alias_target (&id);
>       if (id != id_orig)
>        name = IDENTIFIER_POINTER (id);
> -      gcc_assert (! TREE_CHAIN (id));
>     }
>
>   assemble_name_raw (file, name);
> --
> 1.7.0.4
>
>

Re: [PATCH 17/18] introduce block_chainon and use BLOCK_CHAIN more

[Richard Guenther]

On Fri, Mar 11, 2011 at 5:23 AM, Nathan Froyd  wrote:
> BLOCKs have a TREE_CHAIN and a TREE_TYPE; TREE_TYPE is useless for
> blocks, but we can't remove TREE_TYPE without also removing TREE_CHAIN.
> This patch lays the groundwork to do just that.  It changes places that
> use chainon on BLOCKs to use block_chainon, which works identically to
> chainon except it uses BLOCK_CHAIN.  And it fixes up a few places that
> used TREE_CHAIN when they meant BLOCK_CHAIN.

The middle-end parts are ok.  Any particular reason why you choose
function.[ch] for block_chainon and not tree.[ch]?

Thanks,
Richard.

> -Nathan
>
> gcc/ada/
>        * gcc-interface/utils.c (gnat_poplevel): Use block_chainon.
>
> gcc/
>        * function.h (block_chainon): Declare.
>        * function.c (block_chainon): Define.
>
> gcc/cp/
>        * decl.c (poplevel): Use block_chainon.
>
> gcc/fortran/
>        * f95-lang.c (poplevel): Use BLOCK_CHAIN and block_chainon.
>
> gcc/java/
>        * decl.c (poplevel): Use BLOCK_CHAIN and block_chainon.
>
> diff --git a/gcc/ada/gcc-interface/utils.c b/gcc/ada/gcc-interface/utils.c
> index eac87e0..dd06ca3 100644
> --- a/gcc/ada/gcc-interface/utils.c
> +++ b/gcc/ada/gcc-interface/utils.c
> @@ -395,8 +395,8 @@ gnat_poplevel (void)
>   else if (BLOCK_VARS (block) == NULL_TREE)
>     {
>       BLOCK_SUBBLOCKS (level->chain->block)
> -       = chainon (BLOCK_SUBBLOCKS (block),
> -                  BLOCK_SUBBLOCKS (level->chain->block));
> +       = block_chainon (BLOCK_SUBBLOCKS (block),
> +                        BLOCK_SUBBLOCKS (level->chain->block));
>       BLOCK_CHAIN (block) = free_block_chain;
>       free_block_chain = block;
>     }
> diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
> index a0ef39f..de96ac2 100644
> --- a/gcc/cp/decl.c
> +++ b/gcc/cp/decl.c
> @@ -794,7 +794,7 @@ poplevel (int keep, int reverse, int functionbody)
>     }
>   else if (block)
>     current_binding_level->blocks
> -      = chainon (current_binding_level->blocks, block);
> +      = block_chainon (current_binding_level->blocks, block);
>
>   /* If we did not make a block for the level just exited,
>      any blocks made for inner levels
> @@ -803,7 +803,7 @@ poplevel (int keep, int reverse, int functionbody)
>      of something else.  */
>   else if (subblocks)
>     current_binding_level->blocks
> -      = chainon (current_binding_level->blocks, subblocks);
> +      = block_chainon (current_binding_level->blocks, subblocks);
>
>   /* Each and every BLOCK node created here in `poplevel' is important
>      (e.g. for proper debugging information) so if we created one
> diff --git a/gcc/fortran/f95-lang.c b/gcc/fortran/f95-lang.c
> index 687f60b..aebe397 100644
> --- a/gcc/fortran/f95-lang.c
> +++ b/gcc/fortran/f95-lang.c
> @@ -444,7 +444,7 @@ poplevel (int keep, int reverse, int functionbody)
>
>   /* Record the BLOCK node just built as the subblock its enclosing scope.  */
>   for (subblock_node = subblock_chain; subblock_node;
> -       subblock_node = TREE_CHAIN (subblock_node))
> +       subblock_node = BLOCK_CHAIN (subblock_node))
>     BLOCK_SUPERCONTEXT (subblock_node) = block_node;
>
>   /* Clear out the meanings of the local variables of this level.  */
> @@ -475,7 +475,7 @@ poplevel (int keep, int reverse, int functionbody)
>   else if (block_node)
>     {
>       current_binding_level->blocks
> -       = chainon (current_binding_level->blocks, block_node);
> +       = block_chainon (current_binding_level->blocks, block_node);
>     }
>
>   /* If we did not make a block for the level just exited, any blocks made for
> @@ -484,7 +484,7 @@ poplevel (int keep, int reverse, int functionbody)
>      else.  */
>   else if (subblock_chain)
>     current_binding_level->blocks
> -      = chainon (current_binding_level->blocks, subblock_chain);
> +      = block_chainon (current_binding_level->blocks, subblock_chain);
>   if (block_node)
>     TREE_USED (block_node) = 1;
>
> diff --git a/gcc/function.c b/gcc/function.c
> index 3f721fb..094cf74 100644
> --- a/gcc/function.c
> +++ b/gcc/function.c
> @@ -4167,6 +4167,34 @@ blocks_nreverse (tree t)
>   return prev;
>  }
>
> +/* Concatenate two chains of blocks (chained through BLOCK_CHAIN)
> +   by modifying the last node in chain 1 to point to chain 2.  */
> +
> +tree
> +block_chainon (tree op1, tree op2)
> +{
> +  tree t1;
> +
> +  if (!op1)
> +    return op2;
> +  if (!op2)
> +    return op1;
> +
> +  for (t1 = op1; BLOCK_CHAIN (t1); t1 = BLOCK_CHAIN (t1))
> +    continue;
> +  BLOCK_CHAIN (t1) = op2;
> +
> +#ifdef ENABLE_TREE_CHECKING
> +  {
> +    tree t2;
> +    for (t2 = op2; t2; t2 = BLOCK_CHAIN (t2))
> +      gcc_assert (t2 != t1);
> +  }
> +#endif
> +
> +  return op1;
> +}
> +
>  /* Count the subblocks of the list starting with BLOCK.  If VECTOR is
>    non-NULL, list them all into VECTOR, in a depth-first preorder
>    traversal of the block tree.  Also clear TREE_ASM_WRITTEN in all
> diff --git a/gcc/function.h b/gcc/function.h
> index 6e7f539..73af294 100644
> --- a/gc

Re: [PATCH 17/18] introduce block_chainon and use BLOCK_CHAIN more

[Nathan Froyd]

On Fri, Mar 11, 2011 at 02:15:20PM +0100, Richard Guenther wrote:
> On Fri, Mar 11, 2011 at 5:23 AM, Nathan Froyd  
> wrote:
> > BLOCKs have a TREE_CHAIN and a TREE_TYPE; TREE_TYPE is useless for
> > blocks, but we can't remove TREE_TYPE without also removing TREE_CHAIN.
> > This patch lays the groundwork to do just that.  It changes places that
> > use chainon on BLOCKs to use block_chainon, which works identically to
> > chainon except it uses BLOCK_CHAIN.  And it fixes up a few places that
> > used TREE_CHAIN when they meant BLOCK_CHAIN.
> 
> The middle-end parts are ok.  Any particular reason why you choose
> function.[ch] for block_chainon and not tree.[ch]?

Because block_nreverse was already in function.[ch].  I'm not
particularly wedded to the location and can move it if you like (I did
spend some time looking through tree.[ch] before rgrep'ing and
remembering that block_nreverse was in a funny location...).

-Nathan

Re: [PATCH 12/18] make CASE_LABEL_EXPR not abuse TREE_CHAIN

[Richard Guenther]

On Fri, Mar 11, 2011 at 5:23 AM, Nathan Froyd  wrote:
> Move CASE_CHAIN into a local operand for CASE_LABEL_EXPR.  Nothing to
> see here.

I wonder if there isn't a better way to do this ... like always requiring
operand 2 of SWITCH_EXPRs.

Richard.

> -Nathan
>
> gcc/
>        * tree.def (CASE_LABEL_EXPR): Add an operand.
>        * tree.h (CASE_CHAIN): Use TREE_OPERAND instead of TREE_CHAIN.
>
> diff --git a/gcc/tree.def b/gcc/tree.def
> index eb94ad2..9c6606d 100644
> --- a/gcc/tree.def
> +++ b/gcc/tree.def
> @@ -863,7 +863,7 @@ DEFTREECODE (SWITCH_EXPR, "switch_expr", tcc_statement, 3)
>    CASE_HIGH, respectively. If CASE_LOW is NULL_TREE, the label is a
>    'default' label. If CASE_HIGH is NULL_TREE, the label is a normal case
>    label.  CASE_LABEL is the corresponding LABEL_DECL.  */
> -DEFTREECODE (CASE_LABEL_EXPR, "case_label_expr", tcc_statement, 3)
> +DEFTREECODE (CASE_LABEL_EXPR, "case_label_expr", tcc_statement, 4)
>
>  /* Used to represent an inline assembly statement.  ASM_STRING returns a
>    STRING_CST for the instruction (e.g., "mov x, y"). ASM_OUTPUTS,
> diff --git a/gcc/tree.h b/gcc/tree.h
> index 3e1ff2c..c81186a 100644
> --- a/gcc/tree.h
> +++ b/gcc/tree.h
> @@ -1689,7 +1689,7 @@ extern void protected_set_expr_location (tree, 
> location_t);
>  #define CASE_LOW(NODE)                 TREE_OPERAND (CASE_LABEL_EXPR_CHECK 
> (NODE), 0)
>  #define CASE_HIGH(NODE)                TREE_OPERAND (CASE_LABEL_EXPR_CHECK 
> (NODE), 1)
>  #define CASE_LABEL(NODE)               TREE_OPERAND (CASE_LABEL_EXPR_CHECK 
> (NODE), 2)
> -#define CASE_CHAIN(NODE)               TREE_CHAIN (CASE_LABEL_EXPR_CHECK 
> (NODE))
> +#define CASE_CHAIN(NODE)               TREE_OPERAND (CASE_LABEL_EXPR_CHECK 
> (NODE), 3)
>
>  /* The operands of a TARGET_MEM_REF.  Operands 0 and 1 have to match
>    corresponding MEM_REF operands.  */
> --
> 1.7.0.4
>
>

Re: [PATCH 02/18] enforce TREE_CHAIN and TREE_TYPE accesses

[Richard Guenther]

On Fri, Mar 11, 2011 at 5:23 AM, Nathan Froyd  wrote:
> Now that we have a structure where not every node might include
> TREE_CHAIN or TREE_TYPE, we need to make sure that when we call said
> accessors that the argument is properly typed.  This requires a number
> of changes:
>
> - It's not enough for FEs to assume that FE-specific DECLs are the only
>  tree that needs to be marked specially; we need to mark things as
>  TS_TYPED or TS_COMMON.
>
> - To facilitate doing so, move the MARK_* macros for initializing
>  tree_contains_struct to tree.h so they are accessible to FEs.
>
> - Additionally, rearrange *_init_ts methods for the C-family languages
>  so that we can share code where code needs to be shared.
>
> - Finally, various places need to check for TS_COMMON structure before
>  blindly calling TREE_CHAIN.

The middle-end changes are ok for 4.7.

Thanks,
Richard.

> -Nathan
>
> gcc/ada/
>        * gcc-interface/ada-tree.h (union lang_tree_node): Check for
>        TS_COMMON before calling TREE_CHAIN.
>        * gcc-interface/misc.c (gnat_init_ts): New function.
>        (LANG_HOOKS_INIT_TS): Define.
>
> gcc/
>        * c-decl.c (union lang_tree_node): Check for TS_COMMON before
>        calling TREE_CHAIN.
>        * print-tree.c (print_node): Likewise.
>        * tree-inline.c (copy_tree_r): Likewise.
>        * c-lang.c (LANG_HOOKS_INIT_TS): Define.
>        * lto-streamer-in.c (lto_input_tree_pointers): Check for TS_TYPED
>        instead of TS_COMMON.
>        * lto-streamer-out.c (lto_output_tree_pointers): Likewise.
>        * tree.c (initialize_tree_contains_struct): Handle TS_TYPED.
>        (copy_node_stat): Zero TREE_CHAIN only if necessary.
>        (MARK_TS_BASE, MARK_TS_TYPED, MARK_TS_COMMON): Move these...
>        (MARK_TS_DECL_COMMON, MARK_TS_DECL_COMMON, MARK_TS_DECL_WRTL):
>        ...and these...
>        (MARK_TS_DECL_WITH_VIS, MARK_TS_DECL_NON_COMMON): ...and these...
>        * tree.h: ...here.
>        (TREE_CHAIN): Check for a TS_COMMON structure.
>        (TREE_TYPE): Check for a TS_TYPED structure.
>
> gcc/c-family/
>        * c-common.h (c_common_init_ts): Declare.
>        * c-common.c (c_common_init_ts): Define.
>
> gcc/cp/
>        * cp-lang.c (cp_init_ts): Call cp_common_init_ts.  Move
>        tree_contains_struct initialization to...
>        * cp-objcp-common.c (cp_common_init_ts): ...here.  Use MARK_*
>        macros.
>        * cp-objcp-common.h (cp_common_init_ts): Declare.
>        * cp-tree.h (union lang_tree_node): Check for TS_COMMON before
>        calling TREE_CHAIN.
>
> gcc/fortran/
>        * f95-lang.c (union lang_tree_node): Check for TS_COMMON before
>        calling TREE_CHAIN.
>
> gcc/go/
>        * go-lang.c (union lang_tree_node): Check for TS_COMMON before
>        calling TREE_CHAIN.
>
> gcc/java/
>        * java-tree.h (union lang_tree_node): Check for TS_COMMON before
>        calling TREE_CHAIN.
>
> gcc/lto/
>        * lto-tree.h (union lang_tree_node): Check for TS_COMMON before
>        calling TREE_CHAIN.
>        * lto.c (lto_fixup_common): Likewise.
>
> gcc/objc/
>        * objc-lang.c (objc_init_ts): Move code for this function...
>        * objc-act.c (objc_common_init_ts): ...here. Define.
>        * objc-act.h (objc_common_init_ts): Declare.
>
> gcc/objcp/
>        * objcp-lang.c (objcxx_init_ts): Call objc_common_init_ts and
>        cp_common_init_ts.
>
> diff --git a/gcc/ada/gcc-interface/ada-tree.h 
> b/gcc/ada/gcc-interface/ada-tree.h
> index 9002fa1..3542349 100644
> --- a/gcc/ada/gcc-interface/ada-tree.h
> +++ b/gcc/ada/gcc-interface/ada-tree.h
> @@ -25,7 +25,7 @@
>
>  /* The resulting tree type.  */
>  union GTY((desc ("0"),
> -          chain_next ("(union lang_tree_node *)TREE_CHAIN (&%h.generic)")))
> +          chain_next ("CODE_CONTAINS_STRUCT (TREE_CODE (&%h.generic), 
> TS_COMMON) ? ((union lang_tree_node *) TREE_CHAIN (&%h.generic)) : NULL")))
>   lang_tree_node
>  {
>   union tree_node GTY((tag ("0"),
> diff --git a/gcc/ada/gcc-interface/misc.c b/gcc/ada/gcc-interface/misc.c
> index 4f7a5e1..89823ca 100644
> --- a/gcc/ada/gcc-interface/misc.c
> +++ b/gcc/ada/gcc-interface/misc.c
> @@ -696,6 +696,20 @@ gnat_eh_personality (void)
>   return gnat_eh_personality_decl;
>  }
>
> +/* Initialize language-specific bits of tree_contains_struct.  */
> +
> +static void
> +gnat_init_ts (void)
> +{
> +  MARK_TS_COMMON (UNCONSTRAINED_ARRAY_TYPE);
> +
> +  MARK_TS_TYPED (UNCONSTRAINED_ARRAY_REF);
> +  MARK_TS_TYPED (LOOP_STMT);
> +  MARK_TS_TYPED (STMT_STMT);
> +  MARK_TS_TYPED (EXIT_STMT);
> +  MARK_TS_TYPED (NULL_EXPR);
> +}
> +
>  /* Definitions for our language-specific hooks.  */
>
>  #undef  LANG_HOOKS_NAME
> @@ -754,6 +768,8 @@ gnat_eh_personality (void)
>  #define LANG_HOOKS_EH_PERSONALITY      gnat_eh_personality
>  #undef  LANG_HOOKS_DEEP_UNSHARING
>  #define LANG_HOOKS_DEEP_UNSHARING      true
> +#undef  LANG_HOOKS_INIT_TS
> +#define LANG_HOOKS_INIT_TS             gnat_init_ts
>
>  struct lang_hooks lang_hooks = LANG_HOOKS

bf54x support

[Henderson, Stuart]

The attached patch adds support for silicon revision 0.4 of the bf54x family.


2011-02-17  Mike Frysinger  

   * gcc.target/bfin/mcpu-bf542.c: Check SILICON_REVISION is 0x0004.
   * gcc.target/bfin/mcpu-bf544.c, gcc.target/bfin/mcpu-bf547.c,
   gcc.target/bfin/mcpu-bf548.c, gcc.target/bfin/mcpu-bf549.c: Likewise.


2011-02-17  Mike Frysinger  

   * config/bfin/bfin.c (bfin_cpus[]): Add 0.4 for
   bf542/bf544/bf547/bf548/bf549.


I don't have write permissions.

Thanks,
Stu


upstream.patch
Description: upstream.patch

Re: [4.7 PATCH 00/18] slim down a number of tree nodes

[Richard Guenther]

On Fri, Mar 11, 2011 at 5:23 AM, Nathan Froyd  wrote:
> This patch series does something similar to what:
>
> http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02491.html
>
> did, only it does it in a cleaner way and it addresses the problem more
> generally.  It introduces a separate substructure (base class) for tree
> nodes that include TREE_TYPE so that a tree node can use TREE_TYPE
> without having to deal with TREE_CHAIN.  It then goes about making
> changes where necessary to both use this new substructure and eliminate
> unnecessary TREE_CHAIN usage.
>
> Eliminating the block field from tree_exp would be another nice-to-have
> for 4.7, but that's not on my radar of things to address at the moment.
> (Matz, you want to do that? :)  Eliminating TREE_TYPE from tree_exp as
> suggested on the wiki would be another interesting project, but not one
> I plan on tackling.

I think removing TREE_TYPE from tree_exp isn't worth it, we do not have
many expression trees left with tuples.  Unifying BLOCK with locations
would indeed be nice (but again we don't have many exp trees left).

> The patch series touches every front-end in various places.  I have CC'd
> the appropriate mailing lists with this introductory email, but I will
> only CC those mailing lists on followup patches that touch the
> appropriate FE.
>
> I have not rigorously measured memory savings with this patch.  Based on
> a (very small) sample, this patch saves ~5% of tree memory according to
> dump_tree_statistics...though the amount of tree memory as reported by
> dump_tree_statistics is somewhat suspect, since it doesn't include
> statistics from copy_node_stat.

I thought I had fixed that ... but appearantly I didn't commit that part.

> The patch series has been bootstrapped on x86_64-unknown-linux-gnu, both
> in its entirety and with sub-patches along the way.  Indeed, the patches
> were not developed in this order; the checking bits were introduced
> first, then any bootstrap or testsuite failures were fixed up, then the
> patches were committed in the proper order.

Did you make sure to enable all languages?  And grep for occurances in
backends?

Thanks,
Richard.

> Nathan Froyd (18):
>  add typed_tree structure
>  enforce TREE_CHAIN and TREE_TYPE accesses
>  remove TREE_CHAIN from *_CST nodes
>  remove TREE_CHAIN from SSA_NAME nodes
>  remove TREE_CHAIN from CONSTRUCTOR nodes
>  define CASE_CHAIN accessor for CASE_LABEL_EXPR
>  generalize build_case_label to the rest of the compiler
>  convert cp *FOR_STMTs to use private scope fields
>  convert cp IF_STMTs to use private scope fields
>  convert cp SWITCH_STMTs to use private scope fields
>  mark EXPR_PACK_EXPANSION as typed only
>  make CASE_LABEL_EXPR not abuse TREE_CHAIN
>  move TS_EXP to be a substructure of TS_TYPED
>  move TS_STATEMENT_LIST to be a substructure of TS_TYPED
>  move REAL_IDENTIFIER_TYPE_VALUE to be a field of lang_identifier
>  make TS_IDENTIFIER be a substructure of TS_BASE
>  introduce block_chainon and use BLOCK_CHAIN more
>  make TS_BLOCK a substructure of TS_BASE
>
>  gcc/ada/gcc-interface/ada-tree.h |    2 +-
>  gcc/ada/gcc-interface/misc.c     |   16 ++
>  gcc/ada/gcc-interface/trans.c    |    5 +-
>  gcc/ada/gcc-interface/utils.c    |    4 +-
>  gcc/c-decl.c                     |    8 ++-
>  gcc/c-family/c-common.c          |   14 +-
>  gcc/c-family/c-common.h          |   20 +---
>  gcc/c-family/c-semantics.c       |   28 ---
>  gcc/c-lang.c                     |    2 +
>  gcc/c-parser.c                   |    2 +-
>  gcc/c-typeck.c                   |    2 +-
>  gcc/cp/cp-lang.c                 |   22 +
>  gcc/cp/cp-objcp-common.c         |   74 +++
>  gcc/cp/cp-objcp-common.h         |    1 +
>  gcc/cp/cp-tree.def               |   19 ---
>  gcc/cp/cp-tree.h                 |   43 ++--
>  gcc/cp/decl.c                    |   28 ++
>  gcc/cp/decl2.c                   |   20 ---
>  gcc/cp/error.c                   |    2 +-
>  gcc/cp/init.c                    |    6 +-
>  gcc/cp/mangle.c                  |   28 +++---
>  gcc/cp/name-lookup.c             |   10 ++--
>  gcc/cp/pt.c                      |   40 +--
>  gcc/cp/repo.c                    |    2 +-
>  gcc/cp/rtti.c                    |    6 +-
>  gcc/cp/search.c                  |    4 +-
>  gcc/cp/semantics.c               |   41 +--
>  gcc/cp/typeck.c                  |    4 +-
>  gcc/except.c                     |    5 +-
>  gcc/fortran/f95-lang.c           |    8 ++--
>  gcc/fortran/trans-decl.c         |    2 +-
>  gcc/fortran/trans-io.c           |    2 +-
>  gcc/fortran/trans-stmt.c         |   14 ++---
>  gcc/function.c                   |   28 ++
>  gcc/function.h                   |    1 +
>  gcc/gimplify.c                   |   14 +++---
>  gcc/go/go-lang.c                 |    2 +-
>  gcc/java/decl.c                  |   13 ++---
>  gcc/java/expr.c                  |    9 ++--

Re: [PATCH, 4.7] Have all inlining destinations "analyzed"

[Richard Guenther]

On Fri, Mar 11, 2011 at 10:58 AM, Martin Jambor  wrote:
> Hi,
>
> after I simply moved id->dst_node->analyzed check from
> expand_call_inline to optimize_inline_calls I tried asserting it there
> instead.  When running testsuite I found out this works for everything
> but mudflap which adds new nodes late with cgraph_add_new_function
> which runs the inliner on nodes which do not have their analyzed flag
> set.  I believe that we can "fix" that by running
> cgraph_analyze_function on these new functions and test results seem
> to agree.  Does the idea look sane?
>
> I have bootstrapped and tested the following patch on x86_64-linux on
> both trunk and pretty-ipa.  Can I commit it now to pretty-ipa and to
> trunk once stage1 opens?

Looks good to me.

Thanks,
Richard.

> Thanks,
>
> Martin
>
>
>
> Index: src/gcc/tree-inline.c
> ===
> --- src.orig/gcc/tree-inline.c
> +++ src/gcc/tree-inline.c
> @@ -3766,11 +3766,6 @@ expand_call_inline (basic_block bb, gimp
>   if (gimple_code (stmt) != GIMPLE_CALL)
>     goto egress;
>
> -  /* Objective C and fortran still calls tree_rest_of_compilation directly.
> -     Kill this check once this is fixed.  */
> -  if (!id->dst_node->analyzed)
> -    goto egress;
> -
>   cg_edge = cgraph_edge (id->dst_node, stmt);
>   gcc_checking_assert (cg_edge);
>   /* First, see if we can figure out what function is being called.
> @@ -4203,6 +4198,7 @@ optimize_inline_calls (tree fn)
>   memset (&id, 0, sizeof (id));
>
>   id.src_node = id.dst_node = cgraph_node (fn);
> +  gcc_assert (id.dst_node->analyzed);
>   id.dst_fn = fn;
>   /* Or any functions that aren't finished yet.  */
>   if (current_function_decl)
> Index: src/gcc/cgraph.c
> ===
> --- src.orig/gcc/cgraph.c
> +++ src/gcc/cgraph.c
> @@ -2495,11 +2495,11 @@ cgraph_add_new_function (tree fndecl, bo
>       case CGRAPH_STATE_FINISHED:
>        /* At the very end of compilation we have to do all the work up
>           to expansion.  */
> +       node = cgraph_node (fndecl);
> +       cgraph_analyze_function (node);
>        push_cfun (DECL_STRUCT_FUNCTION (fndecl));
>        current_function_decl = fndecl;
>        gimple_register_cfg_hooks ();
> -       if (!lowered)
> -          tree_lowering_passes (fndecl);
>        bitmap_obstack_initialize (NULL);
>        if (!gimple_in_ssa_p (DECL_STRUCT_FUNCTION (fndecl)))
>          execute_pass_list (pass_early_local_passes.pass.sub);
> Index: src/gcc/cgraph.h
> ===
> --- src.orig/gcc/cgraph.h
> +++ src/gcc/cgraph.h
> @@ -618,6 +618,7 @@ bool varpool_used_from_object_file_p (st
>  extern FILE *cgraph_dump_file;
>  void cgraph_finalize_function (tree, bool);
>  void cgraph_mark_if_needed (tree);
> +void cgraph_analyze_function (struct cgraph_node *);
>  void cgraph_finalize_compilation_unit (void);
>  void cgraph_optimize (void);
>  void cgraph_mark_needed_node (struct cgraph_node *);
> Index: src/gcc/cgraphunit.c
> ===
> --- src.orig/gcc/cgraphunit.c
> +++ src/gcc/cgraphunit.c
> @@ -143,7 +143,6 @@ static void cgraph_expand_all_functions
>  static void cgraph_mark_functions_to_output (void);
>  static void cgraph_expand_function (struct cgraph_node *);
>  static void cgraph_output_pending_asms (void);
> -static void cgraph_analyze_function (struct cgraph_node *);
>
>  FILE *cgraph_dump_file;
>
> @@ -773,7 +772,7 @@ cgraph_output_pending_asms (void)
>  }
>
>  /* Analyze the function scheduled to be output.  */
> -static void
> +void
>  cgraph_analyze_function (struct cgraph_node *node)
>  {
>   tree save = current_function_decl;
>

Re: [PATCH 15/18] move REAL_IDENTIFIER_TYPE_VALUE to be a field of lang_identifier

[Jason Merrill]

On 03/10/2011 11:23 PM, Nathan Froyd wrote:

I'm not overly fond of the conditionals (especially in error_operand_p)
but I don't think it's reasonable to make IDENTIFIER_NODE bigger and
penalize the other FEs just because the C++ FE is playing games with
TREE_TYPE.


The C++ FE expects that we can check the TREE_TYPE of anything that 
appears as an expression, and uses IDENTIFIER_NODE to indicate a 
dependent name within templates.  If you want to break TREE_TYPE on 
IDENTIFIER_NODE, you need to change the representation of dependent 
names so that we can continue to use TREE_TYPE on all expressions.


Jason

Re: [4.7 PATCH 00/18] slim down a number of tree nodes

[Nathan Froyd]

On Fri, Mar 11, 2011 at 02:25:38PM +0100, Richard Guenther wrote:
> On Fri, Mar 11, 2011 at 5:23 AM, Nathan Froyd  
> wrote:
> > This patch series does something similar to what:
> >
> > http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02491.html
> >
> > did, only it does it in a cleaner way and it addresses the problem more
> > generally.
> >
> > Eliminating the block field from tree_exp would be another nice-to-have
> > for 4.7, but that's not on my radar of things to address at the moment.
> 
> I think removing TREE_TYPE from tree_exp isn't worth it, we do not have
> many expression trees left with tuples.  Unifying BLOCK with locations
> would indeed be nice (but again we don't have many exp trees left).

Well, the patch from last November showed that there are enough
expressions left that eliminating a pointer reduces GC memory by ~1%.
So I'd say shrinking things would still be worthwhile.

> > I have not rigorously measured memory savings with this patch.  Based on
> > a (very small) sample, this patch saves ~5% of tree memory according to
> > dump_tree_statistics...though the amount of tree memory as reported by
> > dump_tree_statistics is somewhat suspect, since it doesn't include
> > statistics from copy_node_stat.
> 
> I thought I had fixed that ... but appearantly I didn't commit that
> part.

I have a patch which I will submit for 4.7, so unless you beat me to
it...

> > The patch series has been bootstrapped on x86_64-unknown-linux-gnu, both
> > in its entirety and with sub-patches along the way.
> 
> Did you make sure to enable all languages?  And grep for occurances in
> backends?

I bootstrapped with
--enable-languages=c,c++,ada,fortran,java,objc,obj-c++,go.  I didn't
check for bits in the backends; I can look around, but any backend
poking in the fields that got eliminated deserves what's coming.

-Nathan

[Patch][AVR]: Support tail calls

[Georg-Johann Lay]

This is a patch to test/review/comment on. It adds tail call
optimization to avr backend.

The implementation uses struct machine_function to pass information
around, i.e. from avr_function_arg_advance to avr_function_ok_for_sibcall.

Tail call support is more general than avr-ld's replacement of
call/ret sequences with --relax which are sometimes wrong, see
http://sourceware.org/PR12494

gcc can, e.g. tail-call bar1 in

void bar0 (void);
void bar1 (int);

int foo (int x)
{
  bar0();
  return bar1 (x);
}

I did not find a way to make this work together with -mcall-prologues.
Please let me know if you have suggestion on how call prologues can be
combine with tail calls.

Regards, Johann


2011-03-10  Georg-Johann Lay  

* config/avr/avr-protos.h (expand_epilogue): Change prototype
* config/avr/avr.h (struct machine_function): Add field
sibcall_fails.
* config/avr/avr.c (init_cumulative_args,
avr_function_arg_advance): Use it.
* config/avr/avr.c (expand_epilogue): Add bool parameter. Handle
sibcall epilogues.
(TARGET_FUNCTION_OK_FOR_SIBCALL): Define to...
(avr_function_ok_for_sibcall): ...this new function.
(avr_lookup_function_attribute1): New static Function.
(avr_naked_function_p, interrupt_function_p,
signal_function_p, avr_OS_task_function_p,
avr_OS_main_function_p): Use it.
* config/avr/avr.md ("sibcall", "sibcall_value",
"sibcall_epilogue"): New expander.
("*call_insn", "*call_value_insn"): New insn.
("call_insn", "call_value_insn"): Remove
("call", "call_value", "epilogue"): Change expander to handle
sibling calls.
Index: config/avr/avr-protos.h
===
--- config/avr/avr-protos.h	(revision 170814)
+++ config/avr/avr-protos.h	(working copy)
@@ -76,7 +76,7 @@ extern const char *lshrsi3_out (rtx insn
 extern bool avr_rotate_bytes (rtx operands[]);
 
 extern void expand_prologue (void);
-extern void expand_epilogue (void);
+extern void expand_epilogue (bool);
 extern int avr_epilogue_uses (int regno);
 
 extern void avr_output_bld (rtx operands[], int bit_nr);
Index: config/avr/avr.md
===
--- config/avr/avr.md	(revision 170814)
+++ config/avr/avr.md	(working copy)
@@ -2647,94 +2647,85 @@
 ;; call
 
 (define_expand "call"
-  [(call (match_operand:HI 0 "call_insn_operand" "")
- (match_operand:HI 1 "general_operand" ""))]
+  [(parallel[(call (match_operand:HI 0 "call_insn_operand" "")
+   (match_operand:HI 1 "general_operand" ""))
+ (use (const_int 0))])]
   ;; Operand 1 not used on the AVR.
   ""
   "")
 
+(define_expand "sibcall"
+  [(parallel[(call (match_operand:HI 0 "call_insn_operand" "")
+   (match_operand:HI 1 "general_operand" ""))
+ (use (const_int 1))])]
+  ""
+  "")
+
 ;; call value
 
 (define_expand "call_value"
-  [(set (match_operand 0 "register_operand" "")
-(call (match_operand:HI 1 "call_insn_operand" "")
-  (match_operand:HI 2 "general_operand" "")))]
+  [(parallel[(set (match_operand 0 "register_operand" "")
+  (call (match_operand:HI 1 "call_insn_operand" "")
+(match_operand:HI 2 "general_operand" "")))
+ (use (const_int 0))])]
   ;; Operand 2 not used on the AVR.
   ""
   "")
 
-(define_insn "call_insn"
-  [(call (mem:HI (match_operand:HI 0 "nonmemory_operand" "!z,*r,s,n"))
- (match_operand:HI 1 "general_operand" "X,X,X,X"))]
-;; We don't need in saving Z register because r30,r31 is a call used registers
+(define_expand "sibcall_value"
+  [(parallel[(set (match_operand 0 "register_operand" "")
+  (call (match_operand:HI 1 "call_insn_operand" "")
+(match_operand:HI 2 "general_operand" "")))
+ (use (const_int 1))])]
+  ""
+  "")
+
+(define_insn "*call_insn"
+  [(parallel[(call (mem:HI (match_operand:HI 0 "nonmemory_operand" "z,s,z,s"))
+   (match_operand:HI 1 "general_operand"   "X,X,X,X"))
+ (use (match_operand:HI 2 "const_int_operand"  "L,L,P,P"))])]
   ;; Operand 1 not used on the AVR.
+  ;; Operand 2 is 1 for tail-call, 0 otherwise.
   "(register_operand (operands[0], HImode) || CONSTANT_P (operands[0]))"
-  "*{
-  if (which_alternative==0)
- return \"%!icall\";
-  else if (which_alternative==1)
-{
-  if (AVR_HAVE_MOVW)
-	return (AS2 (movw, r30, %0) CR_TAB
-   \"%!icall\");
-  else
-	return (AS2 (mov, r30, %A0) CR_TAB
-		AS2 (mov, r31, %B0) CR_TAB
-		\"%!icall\");
-}
-  else if (which_alternative==2)
-return AS1(%~call,%x0);
-  return (AS2 (ldi,r30,lo8(%0)) CR_TAB
-  AS2 (ldi,r31,hi8(%0)) CR_TAB
-  \"%!icall\");
-}"
-  [(set_attr "cc" "clobber,clobber,clobber,clobber")
+  "@
+%!icall
+%~call %x0
+%!ijmp
+%~jmp

Re: [PATCH 15/18] move REAL_IDENTIFIER_TYPE_VALUE to be a field of lang_identifier

[Nathan Froyd]

On Fri, Mar 11, 2011 at 08:40:24AM -0500, Jason Merrill wrote:
> On 03/10/2011 11:23 PM, Nathan Froyd wrote:
>> I'm not overly fond of the conditionals (especially in error_operand_p)
>> but I don't think it's reasonable to make IDENTIFIER_NODE bigger and
>> penalize the other FEs just because the C++ FE is playing games with
>> TREE_TYPE.
>
> The C++ FE expects that we can check the TREE_TYPE of anything that  
> appears as an expression, and uses IDENTIFIER_NODE to indicate a  
> dependent name within templates.  If you want to break TREE_TYPE on  
> IDENTIFIER_NODE, you need to change the representation of dependent  
> names so that we can continue to use TREE_TYPE on all expressions.

I'm confused.  Isn't this what the switching on IDENTIFIER_NODE in a
number of places is doing?  (And any future places that g++/libstdc++
didn't catch will be an ICE.)  Or are you saying that you don't want the
switching and IDENTIFIER_NODEs should retain TREE_TYPE unless and until
somebody comes forth with a better design?

-Nathan

[patch][4.7] Enhance XOR handling in simplify-rtx.c

[Chung-Lin Tang]

Hi,
this patch adds a bit more sophistication to the handled xor RTX cases
in foo().

This may look a bit ad hoc, but I am seeing it useful for some cases
where we combine zero_extend with (not (shift ...)).  The supplied ARM
testcase demonstrates when 3-insn combining comes up with:
(set (reg:SI 145)
(xor:SI (and:SI (not:SI (reg/v:SI 135 [ crc ]))
(const_int 32767 [0x7fff]))
(const_int 65535 [0x])))

when it is actually equivalent to:
(set (reg:SI 145)
(ior:SI (reg/v:SI 135 [ x ])
(const_int 32768 [0x8000])))

This happens on ARM architecture levels v6 and above, due to its
possession of real zero_extend instructions.  On ARMv5 and earlier, the
use of two shifts for zero extending actually helped to work around
this, due to staged combining effects of optimizing the shifts away one
by one...

Cross-tested using QEMU for ARM-Linux, currently undergoing x86
bootstrapping and testing. If results are clear, is this okay for trunk
when stage1 opens again?

Thanks,
Chung-Lin

* simplify-rtx.c (simplify_binary_operation_1): Handle
(xor (and A B) C) case when B and C are both constants.
Index: simplify-rtx.c
===
--- simplify-rtx.c  (revision 170870)
+++ simplify-rtx.c  (working copy)
@@ -2480,6 +2480,43 @@
XEXP (op0, 1), mode),
op1);
 
+  /* Given (xor (and A B) C), using P^Q == ~PQ | ~QP (concat as AND),
+we can transform (AB)^C into:
+  A(~CB) | ~AC | ~BC
+Attempt a few simplifications when B and C are both constants.  */
+  if (GET_CODE (op0) == AND
+ && CONST_INT_P (op1) && CONST_INT_P (XEXP (op0, 1)))
+   {
+ rtx a = XEXP (op0, 0);
+ rtx b = XEXP (op0, 1);
+ rtx c = op1;
+ HOST_WIDE_INT bval = INTVAL (b);
+ HOST_WIDE_INT cval = INTVAL (c);
+
+ rtx na_c
+   = simplify_binary_operation (AND, mode,
+simplify_gen_unary (NOT, mode, a, 
mode),
+c);
+ if ((~cval & bval) == 0)
+   {
+ /* Try to simplify ~AC | ~BC.  */
+ if (na_c != NULL_RTX)
+   return simplify_gen_binary (IOR, mode, na_c,
+   GEN_INT (~bval & cval));
+   }
+ else
+   {
+ /* If ~AC is zero, simplify A(~CB) | ~BC.  */
+ if (na_c == const0_rtx)
+   {
+ rtx a_nc_b = simplify_gen_binary (AND, mode, a,
+   GEN_INT (~cval & bval));
+ return simplify_gen_binary (IOR, mode, a_nc_b,
+ GEN_INT (~bval & cval));
+   }
+   }
+   }
+
   /* (xor (comparison foo bar) (const_int 1)) can become the reversed
 comparison if STORE_FLAG_VALUE is 1.  */
   if (STORE_FLAG_VALUE == 1
Index: testsuite/gcc.target/arm/xor-and.c
===
--- testsuite/gcc.target/arm/xor-and.c  (revision 0)
+++ testsuite/gcc.target/arm/xor-and.c  (revision 0)
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-options "-O -march=armv6" } */
+
+unsigned short foo (unsigned short x)
+{
+  x ^= 0x4002;
+  x >>= 1;
+  x |= 0x8000;
+  return x;
+}
+
+/* { dg-final { scan-assembler "orr" } } */
+/* { dg-final { scan-assembler-not "mvn" } } */
+/* { dg-final { scan-assembler-not "uxth" } } */

Re: Problem with procedure pointers

[Janus Weil]

>> Ok, since you guys seem to agree on that, here is the patch without module
>> version bumping, but this time complete with test case and ChangeLog.
>> Ok for trunk?
>
> OK. Thanks for the patch.

Thanks. Committed as r170871.

Cheers,
Janus



>> 2011-03-10  Janus Weil
>>
>>        PR fortran/47768
>>        * module.c (ab_attribute,attr_bits): Add AB_PROC_POINTER_COMP.
>>        (mio_symbol_attribute): Handle attribute 'proc_pointer_comp'.
>>
>> 2011-03-10  Janus Weil
>>
>>        PR fortran/47768
>>        * gfortran.dg/proc_ptr_comp_31.f90: New.
>
>

Re: [PATCH 15/18] move REAL_IDENTIFIER_TYPE_VALUE to be a field of lang_identifier

[Nathan Froyd]

On Fri, Mar 11, 2011 at 06:04:45AM -0800, Nathan Froyd wrote:
> On Fri, Mar 11, 2011 at 08:40:24AM -0500, Jason Merrill wrote:
> > On 03/10/2011 11:23 PM, Nathan Froyd wrote:
> > The C++ FE expects that we can check the TREE_TYPE of anything that  
> > appears as an expression, and uses IDENTIFIER_NODE to indicate a  
> > dependent name within templates.  If you want to break TREE_TYPE on  
> > IDENTIFIER_NODE, you need to change the representation of dependent  
> > names so that we can continue to use TREE_TYPE on all expressions.
> 
> I'm confused.  Isn't this what the switching on IDENTIFIER_NODE in a
> number of places is doing?  (And any future places that g++/libstdc++
> didn't catch will be an ICE.)  Or are you saying that you don't want the
> switching and IDENTIFIER_NODEs should retain TREE_TYPE unless and until
> somebody comes forth with a better design?

Or, alternatively, are you saying that blindly replacing TREE_TYPE with
REAL_IDENTIFIER_TYPE_VALUE is wrong, semantically speaking, as TREE_TYPE
and REAL_IDENTIFIER_TYPE_VALUE mean different things and should be kept
separate, even if they happen to share the same storage?  And if so,
would moving that storage into lang_identifier be OK so long as the
requisite occurrences of TREE_TYPE are audited and the appropriate name
(REAL_IDENTIFIER_TYPE_VALUE vs. ...I don't know, EXPR_LIKE_TYPE) is
used?

-Nathan

Re: [PATCH, 4.6] Do not create new cgraph noes in the verifier

[Jan Hubicka]

> Hi,
> 
> while working on removing lazy cgraph node creation I have noticed
> that we might do that even in the call graph verifier which certainly
> looks undesirable.  Richi pre-approved removing it on IRC but I am not
> sure whether that was for 4.6.  On the other hand I guess the change
> is rather obvious and the verifier is disabled with release checking
> and so I'd prefer to commit it now.  Is it OK?

Yes it is OK.
Obviously that code never creates new nodes unless the cgraph hash is memory 
corrupted,
but it also never produce the error message.
Originaly the code was testing cgraph_get_node (node->decl) != node
and it was intended to check sanity of cgraph hash table at a time it was 
identifier
based and we was not pretending we have one definition rule.

Honza
> 
> Bootstrapped and tested on x86_63-linux without any problems.
> 
> Thanks,
> 
> Martin
> 
> 
> 2011-03-10  Martin Jambor  
> 
>   * cgraphunit.c (verify_cgraph_node): Call cgraph_get_node instead of
>   cgraph_node.
> 
> Index: src/gcc/cgraphunit.c
> ===
> --- src.orig/gcc/cgraphunit.c
> +++ src/gcc/cgraphunit.c
> @@ -551,7 +551,7 @@ verify_cgraph_node (struct cgraph_node *
>error_found = true;
>  }
>  
> -  if (!cgraph_node (node->decl))
> +  if (!cgraph_get_node (node->decl))
>  {
>error ("node not found in cgraph_hash");
>error_found = true;

RE: [Patch][AVR]: Support tail calls

[Weddington, Eric]

> -Original Message-
> From: Georg-Johann Lay [mailto:a...@gjlay.de]
> Sent: Friday, March 11, 2011 6:44 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Denis Chertykov; Anatoly Sokolov; Weddington, Eric; Boyapati, Anitha
> Subject: [Patch][AVR]: Support tail calls
> 
> This is a patch to test/review/comment on. It adds tail call
> optimization to avr backend.



> I did not find a way to make this work together with -mcall-prologues.
> Please let me know if you have suggestion on how call prologues can be
> combine with tail calls.

Yeah, we're going to have to find a way to make this work with -mcall-prologues 
because that is a very commonly used target optimization switch.

Eric

Re: [PATCH, 4.7] Have all inlining destinations "analyzed"

[Jan Hubicka]

> Index: src/gcc/cgraph.c
> ===
> --- src.orig/gcc/cgraph.c
> +++ src/gcc/cgraph.c
> @@ -2495,11 +2495,11 @@ cgraph_add_new_function (tree fndecl, bo
>case CGRAPH_STATE_FINISHED:
>   /* At the very end of compilation we have to do all the work up
>  to expansion.  */
> + node = cgraph_node (fndecl);
> + cgraph_analyze_function (node);
>   push_cfun (DECL_STRUCT_FUNCTION (fndecl));
>   current_function_decl = fndecl;
>   gimple_register_cfg_hooks ();
> - if (!lowered)
> -  tree_lowering_passes (fndecl);

The analysis shoud happent in cgraph_process_new_functions that should be
called after every IPA pass.
I don't think we should move analysis here nor we should drop the !lowered path
(even if it is unused currently, cgraph_add_new_function is supposed to work
on unlowered functions).

So the problem is that the functions are added but not processed at inlining
time.  I do not see how this can happen given that we process new function
after every IPA pass and mudflap is not part of early optmizations.
Do you have any idea here?  Otherwise i will debug this.

Honza

>   bitmap_obstack_initialize (NULL);
>   if (!gimple_in_ssa_p (DECL_STRUCT_FUNCTION (fndecl)))
> execute_pass_list (pass_early_local_passes.pass.sub);
> Index: src/gcc/cgraph.h
> ===
> --- src.orig/gcc/cgraph.h
> +++ src/gcc/cgraph.h
> @@ -618,6 +618,7 @@ bool varpool_used_from_object_file_p (st
>  extern FILE *cgraph_dump_file;
>  void cgraph_finalize_function (tree, bool);
>  void cgraph_mark_if_needed (tree);
> +void cgraph_analyze_function (struct cgraph_node *);
>  void cgraph_finalize_compilation_unit (void);
>  void cgraph_optimize (void);
>  void cgraph_mark_needed_node (struct cgraph_node *);
> Index: src/gcc/cgraphunit.c
> ===
> --- src.orig/gcc/cgraphunit.c
> +++ src/gcc/cgraphunit.c
> @@ -143,7 +143,6 @@ static void cgraph_expand_all_functions
>  static void cgraph_mark_functions_to_output (void);
>  static void cgraph_expand_function (struct cgraph_node *);
>  static void cgraph_output_pending_asms (void);
> -static void cgraph_analyze_function (struct cgraph_node *);
>  
>  FILE *cgraph_dump_file;
>  
> @@ -773,7 +772,7 @@ cgraph_output_pending_asms (void)
>  }
>  
>  /* Analyze the function scheduled to be output.  */
> -static void
> +void
>  cgraph_analyze_function (struct cgraph_node *node)
>  {
>tree save = current_function_decl;

Re: [build, lto] Only accept -fuse-linker-plugin if linker supports -plugin (PR lto/46944)

[Rainer Orth]

Richard Guenther  writes:

>> Only with -save-temps, otherwise it's some random file in /var/tmp.  But
>> even so the file is removed immediately.
>
> The following seems to work for me
>
> Index: gcc/testsuite/lib/target-supports.exp
> ===
> --- gcc/testsuite/lib/target-supports.exp   (revision 170868)
> +++ gcc/testsuite/lib/target-supports.exp   (working copy)
> @@ -1011,9 +1011,20 @@ proc check_effective_target_static_libgf
>  }
>  
>  proc check_linker_plugin_available { } {
> -  return [check_no_compiler_messages_nocache linker_plugin executable {
> +  set result [eval check_compile { linker_plugin object {
>   int main() { return 0; }
> -  } "-flto -fuse-linker-plugin"]
> +  } "-flto" } ]
> +  set lines [lindex $result 0]
> +  set output [lindex $result 1]
> +  set result [gcc_target_compile $output linker_plugin[pid] executable { 
> additional_flags=-flto additional_flags=-flto-partition=none 
> additional_flags=-save-temps } ]
> +  remote_file build delete $output
> +  remote_file build delete linker_plugin[pid]
> +  remote_file build delete linker_plugin[pid].s
> +  if [file exists linker_plugin[pid].res] {
> +remote_file build delete linker_plugin[pid].res
> +return 1
> +  }
> +  return 0
>  }

Still doesn't work for me if compiling and linking manually with GNU ld
2.21 on Solaris 11/x86: no .res file is being created, although
liblto_plugin.so is used.

> Eventually scanning -v output for '-plugin' is better.

This can only work if we make sure that -plugin is only passed to
linkers that properly handle it.

>> And even if we decide to fix PR lto/46944 like this, we're still left
>> with the problem of users invoking gcc with -fuse-linker-plugin and
>> getting either strange errors or no effect instead of a clear
>> diagnostic.
>
> Sure.  But just disabling linker-plugin support for almost everyone
> doesn't sound like a good solution either.

Why do you say so?  The tri-state solution I've outlined only disables it
completely for non-GNU linkers.  The plugin is used automatically for
gld/gold 2.21+ and for gold 2.20* if -fuse-linker-plugin is given.

I don't see the `almost everyone' here, on the contrary: the situation
is identical to what we have now, with the exception that we don't try
to pass -plugin to linkers we don't know they can somehow (even with
restrictions) handle it.  That's what PR lto/46944 is primarily about.

Rainer

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

Re: [PATCH 15/18] move REAL_IDENTIFIER_TYPE_VALUE to be a field of lang_identifier

[Joseph S. Myers]

On Fri, 11 Mar 2011, Jason Merrill wrote:

> On 03/10/2011 11:23 PM, Nathan Froyd wrote:
> > I'm not overly fond of the conditionals (especially in error_operand_p)
> > but I don't think it's reasonable to make IDENTIFIER_NODE bigger and
> > penalize the other FEs just because the C++ FE is playing games with
> > TREE_TYPE.
> 
> The C++ FE expects that we can check the TREE_TYPE of anything that appears as
> an expression, and uses IDENTIFIER_NODE to indicate a dependent name within
> templates.  If you want to break TREE_TYPE on IDENTIFIER_NODE, you need to
> change the representation of dependent names so that we can continue to use
> TREE_TYPE on all expressions.

There's a longstanding ambition to give identifiers a static type other 
than "tree".  That would tend to suggest a representation such as 
DEPENDENT_NAME_EXPR (a tree wrapping an identifier).

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

Re: RFA (layout): PATCH for c++/48029 (ICE-on-valid with templates and arrays)

[Jason Merrill]

On 03/10/2011 09:56 AM, Jason Merrill wrote:

While looking at the history, it occurred to me that
COMPLETE_OR_UNBOUND_ARRAY_TYPE_P is a better test than TYPE_SIZE in the
type_hash_eq change, so I'm going to make that tweak to the patch


OK, apparently this was a bad idea; it caused 48069.  So I switched back 
to COMPLETE_TYPE_P.


Jason

[Patch ARM] Fix PR47688

[Ramana Radhakrishnan]

Hi,

This patch fixes PR47688 which is a regression from gcc 4.4 and which 
ends up fixing https://bugs.launchpad.net/gcc-linaro/+bug/730440. The 
change is essentially in the punctuation character to only print out the 
lower 16 bits of the constant.


I'll commit this into trunk and backport this to 4.5 branch once testing 
completes. A bootstrap of trunk for C, C++ and Fortran in Thumb2 has 
already completed and regression tests are on.


Cheers
Ramana

2011-03-10  Ramana Radhakrishnan  

PR target/47668
gcc/
* config/arm/arm.md (arm_movtas_ze): Use 'L' instead of 'c'
in the output template.
gcc/testsuite/
* gcc.target/arm/pr47688.c: New.

---
Ramana Radhakrishnan

Index: gcc/config/arm/arm.md
===
--- gcc/config/arm/arm.md   (revision 170820)
+++ gcc/config/arm/arm.md   (working copy)
@@ -10580,13 +10580,15 @@
   [(set_attr "conds" "clob")]
 )
 
+;; We only care about the lower 16 bits of the constant 
+;; being inserted into the upper 16 bits of the register.
 (define_insn "*arm_movtas_ze" 
   [(set (zero_extract:SI (match_operand:SI 0 "s_register_operand" "+r")
(const_int 16)
(const_int 16))
 (match_operand:SI 1 "const_int_operand" ""))]
   "arm_arch_thumb2"
-  "movt%?\t%0, %c1"
+  "movt%?\t%0, %L1"
  [(set_attr "predicable" "yes")
(set_attr "length" "4")]
 )
--- /dev/null   2011-03-10 09:33:21.341560001 +
+++ ./gcc/testsuite/gcc.target/arm/pr47688.c2011-03-10 15:46:16.197181998 
+
@@ -0,0 +1,26 @@
+/* { dg-options "-mthumb -O2" }  */
+/* { dg-require-effective-target arm_thumb2_ok } */
+/* { dg-final { scan-assembler-not "-32768" } } */
+
+typedef union
+{
+  unsigned long int u_32_value;
+  struct 
+  {
+unsigned short int u_16_value_0;
+unsigned short int u_16_value_1;
+  } u_16_values;
+} my_union;
+
+
+unsigned long int Test(const unsigned short int wXe)
+{
+  my_union dwCalcVal;
+  
+  dwCalcVal.u_16_values.u_16_value_0=wXe;
+  dwCalcVal.u_16_values.u_16_value_1=0x8000u;
+
+  dwCalcVal.u_32_value /=3;
+  
+  return (dwCalcVal.u_32_value);
+}

[committed] Fix cgraph ICE with aliases (PR middle-end/48044)

[Jakub Jelinek]

Hi!

I've committed this fix, where cgraph_remove_unreachable_nodes
was clearing vnode->needed for nodes marked as force_output
because something was aliasing them.  For -O1 the varpool nodes
were removed completely (also undesirable), but for -O0 they
were kept around and ICEd because needed wasn't set in them.

Bootstrapped/regtested on x86_64-linux and i686-linux, approved by Honza on
IRC.

2011-03-11  Jakub Jelinek  

PR middle-end/48044
* ipa.c (cgraph_remove_unreachable_nodes): Enqueue
all vnode->force_output nodes as needed.

* gcc.dg/torture/pr48044.c: New test.

--- gcc/ipa.c.jj2011-01-18 12:20:18.0 +0100
+++ gcc/ipa.c   2011-03-11 12:27:04.0 +0100
@@ -259,7 +259,7 @@ cgraph_remove_unreachable_nodes (bool be
 {
   vnode->next_needed = NULL;
   vnode->prev_needed = NULL;
-  if (vnode->analyzed
+  if ((vnode->analyzed || vnode->force_output)
  && !varpool_can_remove_if_no_refs (vnode))
{
  vnode->needed = false;
--- gcc/testsuite/gcc.dg/torture/pr48044.c.jj   2011-03-11 12:28:59.0 
+0100
+++ gcc/testsuite/gcc.dg/torture/pr48044.c  2011-03-11 12:28:48.0 
+0100
@@ -0,0 +1,7 @@
+/* PR middle-end/48044 */
+/* { dg-do compile } */
+/* { dg-require-alias "" } */
+
+int a __asm__ ("b") = 0;
+extern int c __asm__ ("a") __attribute__ ((alias ("b")));
+extern int d __attribute__ ((weak, alias ("a")));

Jakub

Re: [PATCH 07/18] generalize build_case_label to the rest of the compiler

[Tom Tromey]

> "Nathan" == Nathan Froyd  writes:

Nathan> gcc/java/
Nathan> * expr.c (expand_java_switch): Call build_case_label.
Nathan> (expand_java_add_case): Likewise.

The java parts are ok.

FWIW, I tend to think that if a core change like this one is accepted,
then updates to the front ends should be considered obvious, barring
some unusual circumstance.

Your update to this patch to pass a location, per the other reviews, is
pre-approved.

Tom

Re: [PATCH] PR c++/PR48035

[Jason Merrill]

On 03/11/2011 03:01 AM, Jakub Jelinek wrote:

Do we need to redo parts of class.c anyway?  From what I understand, the
problematic vtbl pointers are at the end of the base types and DECL_SIZE
is set to the CLASSTYPE_AS_BASE type size, thus those pointers ought to
be at or beyond the containing field's size.
So, can't we simply skip subfields whose bit_position is equal or larger
to containing field's size?  Something like (works on the testcase from this
PR, otherwise untested):


Sure, that should work.  I had been thinking of stopping when we run out 
of fields in CLASSTYPE_AS_BASE, but your approach seems simpler.



Or, in the simplify_aggr_init case where the created tree is handed
immediately to the gimplifier, there is IMHO no point in initializing
all fields to zero when the gimplifier throws that immediately away again.


Unfortunately, pointers to data members make this not good enough: 
zero-initializing one means setting the bits to -1.  Though I suppose we 
could keep track of whether or not a class has a pointer to data member 
field somewhere (and therefore need to do this the hard way) and if not, 
just use an empty CONSTRUCTOR.


Jason

Re: [Patch][AVR]: Support tail calls

[Georg-Johann Lay]

Weddington, Eric schrieb:
> 
>> -Original Message-
>> From: Georg-Johann Lay [mailto:a...@gjlay.de]
>> Sent: Friday, March 11, 2011 6:44 AM
>> To: gcc-patches@gcc.gnu.org
>> Cc: Denis Chertykov; Anatoly Sokolov; Weddington, Eric; Boyapati, Anitha
>> Subject: [Patch][AVR]: Support tail calls
>>
>> This is a patch to test/review/comment on. It adds tail call
>> optimization to avr backend.
> 
> 
> 
>> I did not find a way to make this work together with -mcall-prologues.
>> Please let me know if you have suggestion on how call prologues can be
>> combine with tail calls.
> 
> Yeah, we're going to have to find a way to make this work with 
> -mcall-prologues because that is a very commonly used target optimization 
> switch.

"Does not work" means here that tail-call optimization won't be
applied in the presence of -mcall-prologues. The code will be correct,
of course. For any module that is compiled with -mcall-prologues the
patch hat no effect, see avr.c:avr_function_ok_for_sibcall()


+  /* Tail-calling must fail if callee-saved regs are used to pass
+ function args.  We must not tail-call when `epilogue_restores'
+ is used.  Unfortunalelly, we cannot tell at this point if that
+ actually will happen or not, and we cannot step back from
+ tail-calling. Thus, we inhibit tail-calling with
-mcall-prologues. */
+
+  if (cfun->machine->sibcall_fails
+  || TARGET_CALL_PROLOGUES)
+{
+  return false;
+}



Johann

Re: [PATCH 15/18] move REAL_IDENTIFIER_TYPE_VALUE to be a field of lang_identifier

[Jason Merrill]

On 03/11/2011 09:19 AM, Nathan Froyd wrote:

On Fri, Mar 11, 2011 at 06:04:45AM -0800, Nathan Froyd wrote:

On Fri, Mar 11, 2011 at 08:40:24AM -0500, Jason Merrill wrote:

On 03/10/2011 11:23 PM, Nathan Froyd wrote:
The C++ FE expects that we can check the TREE_TYPE of anything that
appears as an expression, and uses IDENTIFIER_NODE to indicate a
dependent name within templates.  If you want to break TREE_TYPE on
IDENTIFIER_NODE, you need to change the representation of dependent
names so that we can continue to use TREE_TYPE on all expressions.


I'm confused.  Isn't this what the switching on IDENTIFIER_NODE in a
number of places is doing?  (And any future places that g++/libstdc++
didn't catch will be an ICE.)  Or are you saying that you don't want the
switching and IDENTIFIER_NODEs should retain TREE_TYPE unless and until
somebody comes forth with a better design?


The latter.


Or, alternatively, are you saying that blindly replacing TREE_TYPE with
REAL_IDENTIFIER_TYPE_VALUE is wrong, semantically speaking, as TREE_TYPE
and REAL_IDENTIFIER_TYPE_VALUE mean different things and should be kept
separate, even if they happen to share the same storage?


This too.  I'm surprised that them sharing the same storage hasn't 
broken anything yet.



And if so,
would moving that storage into lang_identifier be OK


Moving the uses of REAL_IDENTIFIER_TYPE_VALUE into lang_identifier or 
even a separate hash table would be OK.



so long as the
requisite occurrences of TREE_TYPE are audited and the appropriate name
(REAL_IDENTIFIER_TYPE_VALUE vs. ...I don't know, EXPR_LIKE_TYPE) is
used?


No, I want to keep using TREE_TYPE.  I was thinking of something more 
like the DEPENDENT_NAME_EXPR that Joseph mentioned.


Jason

testcase for PR c/36299

[Vincent Lefevre]

As asked in PR c/36299[*], here's a testcase for this PR. It checks
the absence of warning for some valid C code, to make sure the warning
no longer reappears in future GCC versions.

[*] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36299#c10

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)
/* PR c/36299 */
/* { dg-do compile } */
/* { dg-options "-Waddress" } */

int
foo(void)
{
  char a[1];
  return a == 0;
}

Re: [PATCH] PR c++/PR48035

[Jakub Jelinek]

On Fri, Mar 11, 2011 at 09:56:59AM -0500, Jason Merrill wrote:
> On 03/11/2011 03:01 AM, Jakub Jelinek wrote:
> >Do we need to redo parts of class.c anyway?  From what I understand, the
> >problematic vtbl pointers are at the end of the base types and DECL_SIZE
> >is set to the CLASSTYPE_AS_BASE type size, thus those pointers ought to
> >be at or beyond the containing field's size.
> >So, can't we simply skip subfields whose bit_position is equal or larger
> >to containing field's size?  Something like (works on the testcase from this
> >PR, otherwise untested):
> 
> Sure, that should work.  I had been thinking of stopping when we run
> out of fields in CLASSTYPE_AS_BASE, but your approach seems simpler.

It worked, here is what I've bootstrapped/regtested on x86_64-linux and
i686-linux.  Is that ok then?

> >Or, in the simplify_aggr_init case where the created tree is handed
> >immediately to the gimplifier, there is IMHO no point in initializing
> >all fields to zero when the gimplifier throws that immediately away again.
> 
> Unfortunately, pointers to data members make this not good enough:
> zero-initializing one means setting the bits to -1.  Though I
> suppose we could keep track of whether or not a class has a pointer
> to data member field somewhere (and therefore need to do this the
> hard way) and if not, just use an empty CONSTRUCTOR.

Np, we'd need to call a recursive function then to tell us if there
is a pointer to data member then.

2011-03-11  Jakub Jelinek  

PR c++/48035
* init.c (build_zero_init_1): Extracted from build_zero_init.
Add FIELD_SIZE argument, if non-NULL and field bit_position
as not smaller than that, don't add that field's initializer.
Pass DECL_SIZE as last argument to build_zero_init_1
for DECL_FIELD_IS_BASE fields.
(build_zero_init): Use build_zero_init_1.

* g++.dg/inherit/virtual8.C: New test.

--- gcc/cp/init.c.jj2011-03-11 08:06:36.0 +0100
+++ gcc/cp/init.c   2011-03-11 08:40:29.321401994 +0100
@@ -140,10 +140,13 @@ initialize_vtbl_ptrs (tree addr)
is the number of elements in the array.  If STATIC_STORAGE_P is
TRUE, initializers are only generated for entities for which
zero-initialization does not simply mean filling the storage with
-   zero bytes.  */
+   zero bytes.  FIELD_SIZE, if non-NULL, is the bit size of the field,
+   subfields with bit positions at or above that bit size shouldn't
+   be added.  */
 
-tree
-build_zero_init (tree type, tree nelts, bool static_storage_p)
+static tree
+build_zero_init_1 (tree type, tree nelts, bool static_storage_p,
+  tree field_size)
 {
   tree init = NULL_TREE;
 
@@ -188,15 +191,32 @@ build_zero_init (tree type, tree nelts, 
  if (TREE_CODE (field) != FIELD_DECL)
continue;
 
+ /* Don't add virtual bases for base classes if they are beyond
+the size of the current field, that means it is present
+somewhere else in the object.  */
+ if (field_size)
+   {
+ tree bitpos = bit_position (field);
+ if (TREE_CODE (bitpos) == INTEGER_CST
+ && !tree_int_cst_lt (bitpos, field_size))
+   continue;
+   }
+
  /* Note that for class types there will be FIELD_DECLs
 corresponding to base classes as well.  Thus, iterating
 over TYPE_FIELDs will result in correct initialization of
 all of the subobjects.  */
  if (!static_storage_p || !zero_init_p (TREE_TYPE (field)))
{
- tree value = build_zero_init (TREE_TYPE (field),
-   /*nelts=*/NULL_TREE,
-   static_storage_p);
+ tree new_field_size
+   = (DECL_FIELD_IS_BASE (field)
+  && DECL_SIZE (field)
+  && TREE_CODE (DECL_SIZE (field)) == INTEGER_CST)
+ ? DECL_SIZE (field) : NULL_TREE;
+ tree value = build_zero_init_1 (TREE_TYPE (field),
+ /*nelts=*/NULL_TREE,
+ static_storage_p,
+ new_field_size);
  if (value)
CONSTRUCTOR_APPEND_ELT(v, field, value);
}
@@ -244,9 +264,9 @@ build_zero_init (tree type, tree nelts, 
ce->index = build2 (RANGE_EXPR, sizetype, size_zero_node,
max_index);
 
- ce->value = build_zero_init (TREE_TYPE (type),
-  /*nelts=*/NULL_TREE,
-  static_storage_p);
+ ce->value = build_zero_init_1 (TREE_TYPE (type),
+/*nelts=*/NULL_TREE,
+static_storage_p, NULL_TREE);
}
 
   /* Build a constructor to contain the initializatio

Re: [build, lto] Only accept -fuse-linker-plugin if linker supports -plugin (PR lto/46944)

[Richard Guenther]

On Fri, 11 Mar 2011, Rainer Orth wrote:

> Richard Guenther  writes:
> 
> >> Only with -save-temps, otherwise it's some random file in /var/tmp.  But
> >> even so the file is removed immediately.
> >
> > The following seems to work for me
> >
> > Index: gcc/testsuite/lib/target-supports.exp
> > ===
> > --- gcc/testsuite/lib/target-supports.exp   (revision 170868)
> > +++ gcc/testsuite/lib/target-supports.exp   (working copy)
> > @@ -1011,9 +1011,20 @@ proc check_effective_target_static_libgf
> >  }
> >  
> >  proc check_linker_plugin_available { } {
> > -  return [check_no_compiler_messages_nocache linker_plugin executable {
> > +  set result [eval check_compile { linker_plugin object {
> >   int main() { return 0; }
> > -  } "-flto -fuse-linker-plugin"]
> > +  } "-flto" } ]
> > +  set lines [lindex $result 0]
> > +  set output [lindex $result 1]
> > +  set result [gcc_target_compile $output linker_plugin[pid] executable { 
> > additional_flags=-flto additional_flags=-flto-partition=none 
> > additional_flags=-save-temps } ]
> > +  remote_file build delete $output
> > +  remote_file build delete linker_plugin[pid]
> > +  remote_file build delete linker_plugin[pid].s
> > +  if [file exists linker_plugin[pid].res] {
> > +remote_file build delete linker_plugin[pid].res
> > +return 1
> > +  }
> > +  return 0
> >  }
> 
> Still doesn't work for me if compiling and linking manually with GNU ld
> 2.21 on Solaris 11/x86: no .res file is being created, although
> liblto_plugin.so is used.

"Work" as in, it detects if -fuse-linker-plugin is enabled by default.
Which it isn't for you?

> > Eventually scanning -v output for '-plugin' is better.
> 
> This can only work if we make sure that -plugin is only passed to
> linkers that properly handle it.

Sure, but your version check patch part would ensure that, if not
overridden by -fuse-linker-plugin.

> >> And even if we decide to fix PR lto/46944 like this, we're still left
> >> with the problem of users invoking gcc with -fuse-linker-plugin and
> >> getting either strange errors or no effect instead of a clear
> >> diagnostic.
> >
> > Sure.  But just disabling linker-plugin support for almost everyone
> > doesn't sound like a good solution either.
> 
> Why do you say so?  The tri-state solution I've outlined only disables it
> completely for non-GNU linkers.  The plugin is used automatically for
> gld/gold 2.21+ and for gold 2.20* if -fuse-linker-plugin is given.
> 
> I don't see the `almost everyone' here, on the contrary: the situation
> is identical to what we have now, with the exception that we don't try
> to pass -plugin to linkers we don't know they can somehow (even with
> restrictions) handle it.  That's what PR lto/46944 is primarily about.

Can you update your patch with the tri-state solution?

Thanks,
Richard.

[PATCH] Fix PR48067

[Richard Guenther]

We shouldn't try to make use of the multiplication result twice in
FMA_EXPR building.  The following ensures that if the uses go
through a negate.

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

Richard.

2011-03-11  Richard Guenther  

PR tree-optimization/48067
* tree-ssa-math-opts.c (convert_mult_to_fma): Verify the
multiplication result will be only used once on the target
stmt.

* gcc.dg/pr48067.c: New testcase.

Index: gcc/tree-ssa-math-opts.c
===
*** gcc/tree-ssa-math-opts.c(revision 170873)
--- gcc/tree-ssa-math-opts.c(working copy)
*** convert_mult_to_fma (gimple mul_stmt, tr
*** 1557,1562 
--- 1557,1565 
/* A negate on the multiplication leads to FNMA.  */
if (use_code == NEGATE_EXPR)
{
+ ssa_op_iter iter;
+ tree use;
+ 
  result = gimple_assign_lhs (use_stmt);
  
  /* Make sure the negate statement becomes dead with this
*** convert_mult_to_fma (gimple mul_stmt, tr
*** 1565,1570 
--- 1568,1578 
   &use_p, &neguse_stmt))
return false;
  
+ /* Make sure the multiplication isn't also used on that stmt.  */
+ FOR_EACH_SSA_TREE_OPERAND (use, neguse_stmt, iter, SSA_OP_USE)
+   if (use == mul_result)
+ return false;
+ 
  /* Re-validate.  */
  use_stmt = neguse_stmt;
  if (gimple_bb (use_stmt) != gimple_bb (mul_stmt))
Index: gcc/testsuite/gcc.dg/pr48067.c
===
*** gcc/testsuite/gcc.dg/pr48067.c  (revision 0)
--- gcc/testsuite/gcc.dg/pr48067.c  (revision 0)
***
*** 0 
--- 1,11 
+ /* { dg-do compile } */
+ /* { dg-options "-O2 -ffast-math -fno-tree-forwprop -fno-tree-reassoc" } */
+ /* { dg-options "-O2 -ffast-math -fno-tree-forwprop -fno-tree-reassoc -mfma4" 
{ target x86_64-*-* i?86-*-* } } */
+ 
+ float
+ foo (float x, float cim)
+ {
+   float c = x * cim;
+   float d = -c;
+   return c - d;
+ }

Re: [PATCH 17/18] introduce block_chainon and use BLOCK_CHAIN more

[Tom Tromey]

> "Nathan" == Nathan Froyd  writes:

Nathan> gcc/java/
Nathan> * decl.c (poplevel): Use BLOCK_CHAIN and block_chainon.

This is ok.

Tom

Re: [PATCH] PR c++/PR48035

[Dodji Seketeli]

Jason Merrill  writes:

> If we're currently initializing a subobject, then we don't want to
> initialize any of our virtual base fields unless they are primary to
> the current type.

Indeed.  I think I understand better now.

> I'm also rather nervous about using is_*_base_of tests given that a
> class can have multiple indirect bases of a particular type.  Whether
> or not there is a virtual base T of U isn't important; what is
> important is whether the current field represents a virtual base.

I have updated is_virtual_base_of to make it test if the current field
represents a virtual base.  Is there a simpler way to detect that?

> In the C++ testcase most testcases return non-zero to indicate
> failure. The main reason for this is to avoid having to deal with
> declaring abort.

Ah okay.  I did notice that C++ tests were using the non-zero return
convention but I didn't know why.  In the patch below I took the liberty
to use abort() nonetheless because as we need to include  for the
placement new operator, I thought just adding another header would be
understandable.

Jakub Jelinek  writes:

> Or, in the simplify_aggr_init case where the created tree is handed
> immediately to the gimplifier, there is IMHO no point in initializing
> all fields to zero when the gimplifier throws that immediately away
> again.

>From what I understand, zero-initializing doesn't necessarily mean
setting all fields to zero, because, e.g, for member pointers fields the
ABI states that a NULL pointer is represented as -1.

So this is the patch I am currently testing.

-- 
Dodji

>From 6a757e998cb6b09883ec366c8c8939a70a215600 Mon Sep 17 00:00:00 2001
From: Dodji Seketeli 
Date: Fri, 11 Mar 2011 15:24:00 +0100
Subject: [PATCH] [PATCH] PR c++/PR48035

gcc/cp/

* cp-tree.h (is_virtual_base_of): Declare new function.
* class.c (is_virtual_base_of): Define it.
* init.c (build_zero_init_1): Extract from from build_zero_init.
Don't initialize non-primary virtual bases of sub-objects.
(build_zero_init_1): Use build_zero_init_1.

gcc/testsuite/

* g++.dg/inherit/virtual8.C: New test.
---
 gcc/cp/class.c  |   21 ++
 gcc/cp/cp-tree.h|1 +
 gcc/cp/init.c   |   66 ++-
 gcc/testsuite/g++.dg/inherit/virtual8.C |   52 
 4 files changed, 121 insertions(+), 19 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/inherit/virtual8.C

diff --git a/gcc/cp/class.c b/gcc/cp/class.c
index 1325260..4c6c9d5 100644
--- a/gcc/cp/class.c
+++ b/gcc/cp/class.c
@@ -7008,6 +7008,27 @@ get_primary_binfo (tree binfo)
   return copied_binfo (primary_base, binfo);
 }
 
+/* Returns TRUE if BASE is a direct virtual base of TYPE, FALSE
+   otherwise.  */
+
+bool
+is_virtual_base_of (tree base, tree type)
+{
+  tree binfo;
+
+  for (binfo = TREE_CHAIN (TYPE_BINFO (type));
+   binfo;
+   binfo = TREE_CHAIN (binfo))
+{
+  if (!BINFO_VIRTUAL_P (binfo))
+   continue;
+
+  if (same_type_p (BINFO_TYPE (binfo), base))
+   return binfo;
+}
+  return NULL_TREE;
+}
+
 /* If INDENTED_P is zero, indent to INDENT. Return nonzero.  */
 
 static int
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 4b49046..558c38b 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -4727,6 +4727,7 @@ extern void fixup_attribute_variants  (tree);
 extern tree* decl_cloned_function_p(const_tree, bool);
 extern void clone_function_decl(tree, int);
 extern void adjust_clone_args  (tree);
+extern bool is_virtual_base_of  (tree, tree);
 
 /* in cvt.c */
 extern tree convert_to_reference   (tree, tree, int, int, tree);
diff --git a/gcc/cp/init.c b/gcc/cp/init.c
index 56f66fa..440db79 100644
--- a/gcc/cp/init.c
+++ b/gcc/cp/init.c
@@ -130,20 +130,17 @@ initialize_vtbl_ptrs (tree addr)
   dfs_walk_once (TYPE_BINFO (type), dfs_initialize_vtbl_ptrs, NULL, list);
 }
 
-/* Return an expression for the zero-initialization of an object with
-   type T.  This expression will either be a constant (in the case
-   that T is a scalar), or a CONSTRUCTOR (in the case that T is an
-   aggregate), or NULL (in the case that T does not require
-   initialization).  In either case, the value can be used as
-   DECL_INITIAL for a decl of the indicated TYPE; it is a valid static
-   initializer. If NELTS is non-NULL, and TYPE is an ARRAY_TYPE, NELTS
-   is the number of elements in the array.  If STATIC_STORAGE_P is
-   TRUE, initializers are only generated for entities for which
-   zero-initialization does not simply mean filling the storage with
-   zero bytes.  */
+/* A subroutine of build_zero_init.
+   
+   The parameters are the same as for build_zero_init.  If
+   IN_SUBOBJECT is TRUE, that means we are currently initializing a
+   subobject.  In that case, we don't initialize virtual bas

Re: [build, lto] Only accept -fuse-linker-plugin if linker supports -plugin (PR lto/46944)

[Rainer Orth]

Richard Guenther  writes:

>> Still doesn't work for me if compiling and linking manually with GNU ld
>> 2.21 on Solaris 11/x86: no .res file is being created, although
>> liblto_plugin.so is used.
>
> "Work" as in, it detects if -fuse-linker-plugin is enabled by default.
> Which it isn't for you?

I'm using gld 2.21, and -flto automatically uses the linker plugin, as
seen with -v.  Despite that, -plugin-opt=-fresolution=ldl.res is passed
to collect2/ld, but no ldl.res file is created.  In truss, I see a stat
of that file, but nothing more.

>> > Eventually scanning -v output for '-plugin' is better.
>> 
>> This can only work if we make sure that -plugin is only passed to
>> linkers that properly handle it.
>
> Sure, but your version check patch part would ensure that, if not
> overridden by -fuse-linker-plugin.

No, -fuse-linker-plugin wouldn't override here: that option is only
accepted if we know that the linker has *some* -plugin support.

>> Why do you say so?  The tri-state solution I've outlined only disables it
>> completely for non-GNU linkers.  The plugin is used automatically for
>> gld/gold 2.21+ and for gold 2.20* if -fuse-linker-plugin is given.
>> 
>> I don't see the `almost everyone' here, on the contrary: the situation
>> is identical to what we have now, with the exception that we don't try
>> to pass -plugin to linkers we don't know they can somehow (even with
>> restrictions) handle it.  That's what PR lto/46944 is primarily about.
>
> Can you update your patch with the tri-state solution?

Sure if the solution is deemed acceptable.  There isn't much point in
following that route if you see problems up front.

Rainer

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

Re: [PATCH 01/18] add typed_tree structure

[Michael Matz]

Hi,

On Thu, 10 Mar 2011, Nathan Froyd wrote:

>   * tree.h (struct typed_tree): New.

IMO this should be called tree_typed, like the other structs in tree.h .


Ciao,
Michael.

Re: [PATCH 02/18] enforce TREE_CHAIN and TREE_TYPE accesses

[Tom Tromey]

> "Nathan" == Nathan Froyd  writes:

Nathan> gcc/java/
Nathan> * java-tree.h (union lang_tree_node): Check for TS_COMMON before
Nathan> calling TREE_CHAIN.

This is ok.

Tom

Re: [build, lto] Only accept -fuse-linker-plugin if linker supports -plugin (PR lto/46944)

[Richard Guenther]

On Fri, 11 Mar 2011, Rainer Orth wrote:

> Richard Guenther  writes:
> 
> >> Still doesn't work for me if compiling and linking manually with GNU ld
> >> 2.21 on Solaris 11/x86: no .res file is being created, although
> >> liblto_plugin.so is used.
> >
> > "Work" as in, it detects if -fuse-linker-plugin is enabled by default.
> > Which it isn't for you?
> 
> I'm using gld 2.21, and -flto automatically uses the linker plugin, as
> seen with -v.  Despite that, -plugin-opt=-fresolution=ldl.res is passed
> to collect2/ld, but no ldl.res file is created.  In truss, I see a stat
> of that file, but nothing more.

Interesting - it works for me with both GNU ld and gold from binutils 
2.21.

> >> > Eventually scanning -v output for '-plugin' is better.
> >> 
> >> This can only work if we make sure that -plugin is only passed to
> >> linkers that properly handle it.
> >
> > Sure, but your version check patch part would ensure that, if not
> > overridden by -fuse-linker-plugin.
> 
> No, -fuse-linker-plugin wouldn't override here: that option is only
> accepted if we know that the linker has *some* -plugin support.

Yeah, of course - that's desirable.

> >> Why do you say so?  The tri-state solution I've outlined only disables it
> >> completely for non-GNU linkers.  The plugin is used automatically for
> >> gld/gold 2.21+ and for gold 2.20* if -fuse-linker-plugin is given.
> >> 
> >> I don't see the `almost everyone' here, on the contrary: the situation
> >> is identical to what we have now, with the exception that we don't try
> >> to pass -plugin to linkers we don't know they can somehow (even with
> >> restrictions) handle it.  That's what PR lto/46944 is primarily about.
> >
> > Can you update your patch with the tri-state solution?
> 
> Sure if the solution is deemed acceptable.  There isn't much point in
> following that route if you see problems up front.

If that solution avoids 3) then yes, I'm fine with going that route.
Both 1) and 2) are very desirable anyway.

Thanks,
Richard.

Re: [PATCH] PR c++/PR48035

[Jason Merrill]

On 03/11/2011 10:08 AM, Jakub Jelinek wrote:

It worked, here is what I've bootstrapped/regtested on x86_64-linux and
i686-linux.  Is that ok then?


OK.

Jason

Re: [wwwdocs] Nits in gcc-4.6/changes.html

[Rainer Orth]

Hi Gerald,

> On Mon, 31 Jan 2011, Rainer Orth wrote:
>> I've read all of the GCC 4.6 changes.html over the weekend and found a
>> couple of issues (mostly nits).  The ones I consider obvious are
>> included in the patch below (though I'm not a native speeker and may
>> simply be mistaken), but there are a couple of others:
>
> I realized that based on your input a number of changes were made,
> but we never took care of your own patch.  Ooops.  I had a look at
> this one, too, and it looks good.  Please go ahead and apply it.

I missed that myself, thanks for noticing.

>> -Optimization for Intel Core 2 processor is now available through
>> +Optimization for the Intel Core 2 processor is now available through
>
> This change is correct, I am just wondering whether saying "Intel
> Core 2 processors" might be better, since there is not just one such
> beast, but it's a family.

I wen't for `the Intel Core 2 processors', and finally checked in the
patch.

Thanks.
Rainer

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

Re: [build, lto] Only accept -fuse-linker-plugin if linker supports -plugin (PR lto/46944)

[Rainer Orth]

Richard Guenther  writes:

>> I'm using gld 2.21, and -flto automatically uses the linker plugin, as
>> seen with -v.  Despite that, -plugin-opt=-fresolution=ldl.res is passed
>> to collect2/ld, but no ldl.res file is created.  In truss, I see a stat
>> of that file, but nothing more.
>
> Interesting - it works for me with both GNU ld and gold from binutils 
> 2.21.

Strange indeed.  Maybe related to using xgcc -B./ from a build tree?
gold still doesn't fully work for me, perhaps it does for this example.
I'll give that a try too.

>> > Can you update your patch with the tri-state solution?
>> 
>> Sure if the solution is deemed acceptable.  There isn't much point in
>> following that route if you see problems up front.
>
> If that solution avoids 3) then yes, I'm fine with going that route.
> Both 1) and 2) are very desirable anyway.

Ok, I'll update the patch over the weekend.

Thanks.
Rainer

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

Re: [PATCH] PR c++/PR48035

[Jason Merrill]

On 03/11/2011 10:15 AM, Dodji Seketeli wrote:

I have updated is_virtual_base_of to make it test if the current field
represents a virtual base.  Is there a simpler way to detect that?


Yeah, let's go with Jakub's patch.

Jason

[PATCH] Fix PR48073

[Richard Guenther]

This fixes PR48073 - we are not interested in types on IDENTIFIER_NODEs
for LTO and thus we don't need to walk types or decls that hang off
such types.

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

Richard.

2011-03-11  Richard Guenther  

PR lto/48073
* tree.c (find_decls_types_r): Do not walk types only reachable
from IDENTIFIER_NODEs.

* g++.dg/lto/20110311-1_0.C: New testcase.

Index: gcc/tree.c
===
--- gcc/tree.c  (revision 170868)
+++ gcc/tree.c  (working copy)
@@ -4822,7 +4822,8 @@ find_decls_types_r (tree *tp, int *ws, v
   fld_worklist_push (BLOCK_ABSTRACT_ORIGIN (t), fld);
 }
 
-  fld_worklist_push (TREE_TYPE (t), fld);
+  if (TREE_CODE (t) != IDENTIFIER_NODE)
+fld_worklist_push (TREE_TYPE (t), fld);
 
   return NULL_TREE;
 }
Index: gcc/testsuite/g++.dg/lto/20110311-1_0.C
===
--- gcc/testsuite/g++.dg/lto/20110311-1_0.C (revision 0)
+++ gcc/testsuite/g++.dg/lto/20110311-1_0.C (revision 0)
@@ -0,0 +1,51 @@
+/* { dg-lto-do link } */
+/* { dg-extra-ld-options "-r -nostdlib" } */
+
+struct NullType {};
+
+template 
+struct TList
+{
+typedef T Head;
+typedef U Tail;
+};
+
+template 
+struct TListLength {};
+
+template 
+struct TListLength >
+{
+enum
+{
+Ret = 1 + TListLength::Ret
+};
+};
+
+template <>
+struct TListLength
+{
+enum
+{
+Ret = 0
+};
+};
+
+template 
+class DDQMC
+{
+public:
+int* moves[TListLength::Ret];
+inline DDQMC();
+private:
+};
+
+template 
+DDQMC::DDQMC()
+{
+}
+
+int main()
+{
+typedef DDQMC< TList > > mytype;
+}

Re: [C++0x patch] constexpr in attribute argument

[Jason Merrill]

On 03/11/2011 04:33 AM, Rodrigo Rivas wrote:

On Fri, Mar 11, 2011 at 6:51 AM, Jason Merrill  wrote:

How about just calling maybe_constant_value call after the
fold_non_dependent_expr call in cp_parser_parenthesized_expression_list?


Well, I first tried something like this, but the key problem is the
*non_dependent* part, so it does nothing if the expression involves
templates:


Ah, yes, you would also need to call it in apply_late_template_attributes.


BTW, a general question, why isn't there a call to
maybe_constant_value just at the end of fold_non_dependent_expr?


I tried combining the two functions at one point but it didn't work so 
well.  It might make sense to try again, though.


The problem is that we don't want to call fold_non_dependent_expr on an 
expression that has already been folded, but it's fine to repeat 
maybe_constant_value.



My patch calls maybe_constant_value after taking away any dependent
expression (cplus_decl_attributes does all the job).


Sure, I guess calling it in one place is better.  But I think let's wait 
until 4.6.1 for this patch.


Jason

Re: [4.7 PATCH 00/18] slim down a number of tree nodes

[Nathan Froyd]

On Fri, Mar 11, 2011 at 12:18:15AM -0800, Mike Stump wrote:
> On Mar 10, 2011, at 8:23 PM, Nathan Froyd  wrote:
> > This patch series does something similar to what
> 
> I am curious what the speed differences are.

A non-rigorous, C-only, release-checking bootstrap (which showed me that
I forgot to change the release-checking TREE_TYPE macro, oops!) make -j4
on a lightly-loaded-ish quad-core machine gave these numbers:

without patch
real10m8.397s
user33m18.060s
sys 2m43.300s

with patch
real 9m57.203s
user 33m12.660s
sys  2m44.090s

So noise-ish territory.  I suppose a more fair comparison would be just
the gcc/ directory, and those non-rigorous numbers, from a 'cd gcc &&
make && time make -j4' post-bootstrap are:

without patch gcc/
real2m41.307s
user8m0.180s
sys 0m30.950s

with patch gcc/
real 2m35.716s
user 7m55.050s
sys  0m30.160s

Of course, these numbers were only measured once, so they are
non-definitive, etc. etc.

-Nathan

[PATCH] Fix inliner defaults in invoke.texi

[Richard Guenther]

Committed.

Richard.

2011-03-11  Richard Guenther  

* doc/invoke.texi (max-inline-insns-single): Adjust default value.

Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 170874)
+++ gcc/doc/invoke.texi (working copy)
@@ -8301,7 +8301,7 @@ This number sets the maximum number of i
 internal representation) in a single function that the tree inliner
 will consider for inlining.  This only affects functions declared
 inline and methods implemented in a class declaration (C++).
-The default value is 300.
+The default value is 400.
 
 @item max-inline-insns-auto
 When you use @option{-finline-functions} (included in @option{-O3}),

Re: [PATCH] Fix PR48073

[Michael Matz]

Hi,

On Fri, 11 Mar 2011, Richard Guenther wrote:

> This fixes PR48073 - we are not interested in types on IDENTIFIER_NODEs 
> for LTO and thus we don't need to walk types or decls that hang off such 
> types.

free_lang_data should probably clear TREE_TYPE for IDENTIFIER_NODEs then.


Ciao,
Michael.

Re: [PATCH 15/18] move REAL_IDENTIFIER_TYPE_VALUE to be a field of lang_identifier

[Nathan Froyd]

On Fri, Mar 11, 2011 at 10:03:43AM -0500, Jason Merrill wrote:
> On 03/11/2011 09:19 AM, Nathan Froyd wrote:
>>> I'm confused.  Isn't this what the switching on IDENTIFIER_NODE in a
>>> number of places is doing?  (And any future places that g++/libstdc++
>>> didn't catch will be an ICE.)  Or are you saying that you don't want the
>>> switching and IDENTIFIER_NODEs should retain TREE_TYPE unless and until
>>> somebody comes forth with a better design?
>
> The latter.

OK.  Well, for the time being, I can drop this particular patch and
simply eliminate TREE_CHAIN from IDENTIFIER_NODEs.  That eliminates any
issues with free_lang_decl and the like anyway.

>> Or, alternatively, are you saying that blindly replacing TREE_TYPE with
>> REAL_IDENTIFIER_TYPE_VALUE is wrong, semantically speaking, as TREE_TYPE
>> and REAL_IDENTIFIER_TYPE_VALUE mean different things and should be kept
>> separate, even if they happen to share the same storage?
>
> This too.  I'm surprised that them sharing the same storage hasn't  
> broken anything yet.
>
>> so long as the
>> requisite occurrences of TREE_TYPE are audited and the appropriate name
>> (REAL_IDENTIFIER_TYPE_VALUE vs. ...I don't know, EXPR_LIKE_TYPE) is
>> used?
>
> No, I want to keep using TREE_TYPE.  I was thinking of something more  
> like the DEPENDENT_NAME_EXPR that Joseph mentioned.

Hm.  OK.  Just as a light sketch of how this would all work, where do
DEPENDENT_NAME_EXPRs get introduced into the AST?  During parsing, or
someplace else?  What about those cases where the FE does TREE_TYPE
(DECL_NAME (X))--are those supposed to be REAL_IDENTIFIER_TYPE_VALUE or
is that supposed to be TREE_TYPE as discussed above (and if so, that
would be an impediment to moving identifiers to a separate static type,
as DECL_NAMEs should be identifiers, not generic trees...)?  There's
also cases like:

--- a/gcc/cp/error.c
+++ b/gcc/cp/error.c
@@ -1011,7 +1011,7 @@ dump_decl (tree t, int flags)
 {
pp_cxx_ws_string (cxx_pp, "operator");
/* Not exactly IDENTIFIER_TYPE_VALUE.  */
-   dump_type (TREE_TYPE (t), flags);
+   dump_type (REAL_IDENTIFIER_TYPE_VALUE (t), flags);
break;
 }
else

is that supposed to be REAL_IDENTIFIER_TYPE_VALUE, the TREE_TYPE
discussed above, or yet another use?  I assume that wherever we test for
IDENTIFIER_TYPENAME_P, we're expecting these dependent types rather than
REAL_IDENTIFIER_TYPE_VALUE?

-Nathan

Re: [C++0x patch] constexpr in attribute argument

[Rodrigo Rivas]

On Fri, Mar 11, 2011 at 4:58 PM, Jason Merrill  wrote:
> Sure, I guess calling it in one place is better.  But I think let's wait
> until 4.6.1 for this patch.

Oh, I didn't notice the only-regression-fixes status. No problem.
--
Rodrigo.

[PATCH] PR c++/46824

[Dodji Seketeli]

Hello,

In my fix for PR c++/42260 I wanted to exclude conversion operators
that return dependent types from the candidates functions during
overload resolution in cases like:

struct A
{
  template operator T*();
};

int i = *A();

During the overload resolution to determine the conversions that would
convert A into a non-class type, we don't want the conversion function
template to be part of the candidates.

I requested the target type of the conversion to be complete and that
was too strong and is not causing the code in the example of the patch
below to be rejected.

I believe Just requesting it to be non-dependent should be enough.

Meanwhile, this comment in the code:

For every cv-qualified or cv-unqualified complete object type T,
there exist candidate operator functions of the form

 T&  operator*(T*);

is not correct (anymore?).  In [over.built]/6 it reads:

For every cv-qualified or cv-unqualified object type T, there exist
candidate operator functions of the form

T& operator*(T *);

Apparently in 1996 the type was required to be complete in the code
and the comment but that changed since then.

So I removed the "complete" from the comment.  I wish I had double
checked that in the spec earlier :-(

Here is the patch I am currently testing against trunk.

-- 
Dodji

>From 9d9f38e1ef36a6ae1240f72834ed6657e382dc0e Mon Sep 17 00:00:00 2001
From: Dodji Seketeli 
Date: Fri, 11 Mar 2011 17:13:16 +0100
Subject: [PATCH] PR c++/46824

gcc/cp/

* call.c (add_builtin_candidate): The type
of the argument of the indirection operator should not be
dependent.  Fix the comment.

gcc/testsuite/

* g++.dg/conversion/cast3.C: New test.
---
 gcc/cp/call.c   |4 ++--
 gcc/testsuite/g++.dg/conversion/cast3.C |   14 ++
 2 files changed, 16 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/conversion/cast3.C

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index a297f53..5953e35 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -2150,7 +2150,7 @@ add_builtin_candidate (struct z_candidate **candidates, 
enum tree_code code,
}
   return;
 
-/* 7 For every cv-qualified or cv-unqualified complete object type T, there
+/* 7 For every cv-qualified or cv-unqualified object type T, there
  exist candidate operator functions of the form
 
 T&  operator*(T*);
@@ -2161,7 +2161,7 @@ add_builtin_candidate (struct z_candidate **candidates, 
enum tree_code code,
 
 case INDIRECT_REF:
   if (TREE_CODE (type1) == POINTER_TYPE
- && is_complete (TREE_TYPE (type1))
+ && !uses_template_parms (TREE_TYPE (type1))
  && (TYPE_PTROB_P (type1)
  || TREE_CODE (TREE_TYPE (type1)) == FUNCTION_TYPE))
break;
diff --git a/gcc/testsuite/g++.dg/conversion/cast3.C 
b/gcc/testsuite/g++.dg/conversion/cast3.C
new file mode 100644
index 000..43287a1
--- /dev/null
+++ b/gcc/testsuite/g++.dg/conversion/cast3.C
@@ -0,0 +1,14 @@
+// Origin: PR c++/46824
+
+class Incomplete;
+struct Ptr
+{
+  operator Incomplete*();
+};
+
+int
+main()
+{
+  Ptr p;
+  *p;
+}
-- 
1.7.3.4

C++ PATCH for c++/47808 (C++0x ICE with VLA in template)

[Jason Merrill]

The problem here was that we were tsubsting twice: first we did 
fold_non_dependent_expr in compute_array_index_type to try and get a 
constant, then because we didn't end up with a constant, we later tsubst 
it again.  So if it didn't work out the first time, we should revert to 
the unfolded form.


Tested x86_64-pc-linux-gnu, applied to trunk.
commit 46d65806fd1f7532dc078887c8dea840ee39dcb6
Author: Jason Merrill 
Date:   Fri Mar 11 11:08:00 2011 -0500

PR c++/47808
* decl.c (compute_array_index_type): Discard folding
if it didn't produce a constant.

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 93c1848..f9d90ad 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -7523,6 +7523,8 @@ compute_array_index_type (tree name, tree size, 
tsubst_flags_t complain)
}
 
  size = maybe_constant_value (size);
+ if (!TREE_CONSTANT (size))
+   size = osize;
}
 
   if (error_operand_p (size))
diff --git a/gcc/testsuite/g++.dg/cpp0x/regress/array1.C 
b/gcc/testsuite/g++.dg/cpp0x/regress/array1.C
new file mode 100644
index 000..629ab41
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/regress/array1.C
@@ -0,0 +1,16 @@
+// PR c++/47808
+// { dg-options -std=c++0x }
+
+template 
+inline T abs (T const & x) { return x; }
+
+template 
+void f (T)
+{
+  typedef int ai[(abs(0.1) > 0) ? 1 : -1];
+}
+
+int main()
+{
+  f(1);
+}

Re: [PATCH] PR c++/46824

[Jason Merrill]

OK.

Jason

Re: [PATCH 15/18] move REAL_IDENTIFIER_TYPE_VALUE to be a field of lang_identifier

[Jason Merrill]

On 03/11/2011 11:23 AM, Nathan Froyd wrote:

Hm.  OK.  Just as a light sketch of how this would all work, where do
DEPENDENT_NAME_EXPRs get introduced into the AST?  During parsing, or
someplace else?


During parsing, yes, wherever we look up a name and currently return the 
plain identifier rather than a decl.



What about those cases where the FE does TREE_TYPE
(DECL_NAME (X))--are those supposed to be REAL_IDENTIFIER_TYPE_VALUE


Kind of.  It seems like there are two uses:

1) Remembering that we've seen a declaration of a type with this name.
2) Remembering which type a particular tinfo or conversion op name 
corresponds to.


It probably makes sense for #2 to use a new and different macro.


There's also cases like:

--- a/gcc/cp/error.c
+++ b/gcc/cp/error.c
@@ -1011,7 +1011,7 @@ dump_decl (tree t, int flags)
  {
pp_cxx_ws_string (cxx_pp, "operator");
 /* Not exactly IDENTIFIER_TYPE_VALUE.  */
-   dump_type (TREE_TYPE (t), flags);
+   dump_type (REAL_IDENTIFIER_TYPE_VALUE (t), flags);
 break;
  }
 else


That's #2.

Jason

Re: 4.5 backport request...

[DJ Delorie]

> I don't think this is suitable for the branch.  Any reason why you
> can't work on the trunk?

The vendor's release is 4.5 based, and 4.6 has some performance
regressions with this chip.  We'd like to sync up the FSF sources with
the minor patches the vendor is using, so that their customers can
take advantage of other 4.5-based bug fixes in the FSF tree.

Note that no target actually uses these macros at the moment.

Re: [PATCH 16/18] make TS_IDENTIFIER be a substructure of TS_BASE

[Nathan Froyd]

On Fri, Mar 11, 2011 at 02:12:06PM +0100, Richard Guenther wrote:
> On Fri, Mar 11, 2011 at 5:23 AM, Nathan Froyd  
> wrote:
> > Now that we've done the requisite surgery on the C++ FE, we can
> > eliminate TREE_CHAIN and TREE_TYPE from IDENTIFIER_NODEs.  Doing so
> > turns up a couple different places that need to be tweaked.
> 
> At some point we should zero-out DECL/TYPE_LANG_SPECIFIC, I
> don't remember why we don't do that.
> 
> The patch is ok for 4.7 anyway.

Given Jason's comments on patch 15/18, I'll be dropping chunks of this
and just eliminating TREE_CHAIN from IDENTIFIER_NODEs for now.  Since
those changes are trivial, I'm going to assume I don't need separate
approval for those (appropriate testing will of course be performed).

-Nathan

Re: [PATCH][ARM] Fix RVCT interoperation issue

[Andrew Stubbs]

On 09/03/11 16:12, Ramana Radhakrishnan wrote:

On Fri, 2011-03-04 at 11:23 +, Andrew Stubbs wrote:

The attached patch, submitted on behalf of Dan Jacobowitz, fixes an
unwind bug when using RealView and libgcc.

It's an old patch that has been in CodeSourcery and Linaro toolchains
for sometime, but somehow escaped being posted here.


I would like to see some context around this patch before accepting or
rejecting this, maybe a testcase (agreed that this is harder) or a
description of the problem this patch is attempting to fix.


A testcase would be difficult. GCC won't produce anything that will 
exercise this code. We'd have to cook something up in hand-coded 
assembler, or maybe import something from RVCT - I don't know.


However, the logic can easily be compared with the ARM EHABI document, 
section 9.2:


http://infocenter.arm.com/help/topic/com.arm.doc.ihi0038a/IHI0038A_ehabi.pdf

The key sentences are:

 "If the high bit is set in the word containing N, then the type_info
  list is followed by a prel31 landing pad offset (with bit 31 clear)
  to be entered in the event that no type matches the thrown type. High
  bit clear in the N word signifies that implicitly the no match case
  should result in a call to __cxa_call_unexpected. When the high bit
  clear format is used, object producers must emit an R_ARM_NONE
  relocation to __cxa_call_unexpected to indicate the dependency to the
  linker."

(Thanks to Paul Brook for explaining this to me. :)

Andrew

RE: [Patch][AVR]: Support tail calls

[Weddington, Eric]

> -Original Message-
> From: Georg-Johann Lay [mailto:a...@gjlay.de]
> Sent: Friday, March 11, 2011 7:59 AM
> To: Weddington, Eric
> Cc: gcc-patches@gcc.gnu.org; Denis Chertykov; Anatoly Sokolov; Boyapati,
> Anitha; Joerg Wunsch
> Subject: Re: [Patch][AVR]: Support tail calls
> 
> "Does not work" means here that tail-call optimization won't be
> applied in the presence of -mcall-prologues. The code will be correct,
> of course. For any module that is compiled with -mcall-prologues the
> patch hat no effect, see avr.c:avr_function_ok_for_sibcall()

Thanks for the clarification! :-)

Eric

[PATCH, rs6000] Fix PR48053, ICEs in SPEC benchmarks

[Peter Bergner]

This patch fixes the two related bugs in PR48053.  The problem here deals
with loading constants into VSX registers.  The first bug occurs when we
try and load up a full constant into the VSX register.  We end up calling
easy_vector_constant_msb which is supported only for V4SI and V4SF modes.
The fix here was to modify the easy_vector_constant_msb predicate to
reject V2DI and V2DF modes.

The second bug was when we attempt to load a VSX register with a constant
for one half of the register and a variable for the other half.  This
caused an ICE in int_mode_for_mode.  I fixed this by first forcing the
correct scalar mode in rs6000_expand_vector_init() and then adding
special support in the movdi_internal* patterns to allow setting of
VSX registers to zero.

These fixed both test cases in PR48053 and Pat Haugen verified that
they fixed the SPEC benchmarks the test cases were reduced from,
without introducing any new SPEC regressions.

This patch passed bootstrapp and regtesting on powerpc64-linux
(test suite run in both 32-bit and 64-bit modes).  Ok for mainline?

Peter


gcc/
PR target/48053
* config/rs6000/predicates.md (easy_vector_constant_add_self,
easy_vector_constant_msb): Do not handle V2DImode and V2DFmode.
* config/rs6000/rs6000.c (const_vector_elt_as_int): Add assert that
mode is not V2DImode or V2DFmode.
(vspltis_constant): Do not handle V2DImode and V2DFmode.
(rs6000_expand_vector_init): Replace copy_to_reg with copy_to_mode_reg.
* config/rs6000/rs6000.md (movdi_internal32): Allow setting VSX
registers to 0.
(movdi_internal64): Likewise.

gcc/testsuite/
PR target/48053
* gcc/testsuite/gcc.target/powerpc/pr48053-1.c: New test.
* gcc/testsuite/gcc.target/powerpc/pr48053-2.c: Likewise.

Index: gcc/config/rs6000/predicates.md
===
--- gcc/config/rs6000/predicates.md (revision 170880)
+++ gcc/config/rs6000/predicates.md (working copy)
@@ -371,7 +371,10 @@ (define_predicate "easy_vector_constant_
(and (match_test "TARGET_ALTIVEC")
(match_test "easy_altivec_constant (op, mode)")))
 {
-  HOST_WIDE_INT val = const_vector_elt_as_int (op, GET_MODE_NUNITS (mode) - 1);
+  HOST_WIDE_INT val;
+  if (mode == V2DImode || mode == V2DFmode)
+return 0;
+  val = const_vector_elt_as_int (op, GET_MODE_NUNITS (mode) - 1);
   val = ((val & 0xff) ^ 0x80) - 0x80;
   return EASY_VECTOR_15_ADD_SELF (val);
 })
@@ -382,7 +385,10 @@ (define_predicate "easy_vector_constant_
(and (match_test "TARGET_ALTIVEC")
(match_test "easy_altivec_constant (op, mode)")))
 {
-  HOST_WIDE_INT val = const_vector_elt_as_int (op, GET_MODE_NUNITS (mode) - 1);
+  HOST_WIDE_INT val;
+  if (mode == V2DImode || mode == V2DFmode)
+return 0;
+  val = const_vector_elt_as_int (op, GET_MODE_NUNITS (mode) - 1);
   return EASY_VECTOR_MSB (val, GET_MODE_INNER (mode));
 })
 
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 170880)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -4855,7 +4855,13 @@ num_insns_constant (rtx op, enum machine
 HOST_WIDE_INT
 const_vector_elt_as_int (rtx op, unsigned int elt)
 {
-  rtx tmp = CONST_VECTOR_ELT (op, elt);
+  rtx tmp;
+
+  /* We can't handle V2DImode and V2DFmode vector constants here yet.  */
+  gcc_assert (GET_MODE (op) != V2DImode
+ && GET_MODE (op) != V2DFmode);
+
+  tmp = CONST_VECTOR_ELT (op, elt);
   if (GET_MODE (op) == V4SFmode
   || GET_MODE (op) == V2SFmode)
 tmp = gen_lowpart (SImode, tmp);
@@ -4876,13 +4882,24 @@ vspltis_constant (rtx op, unsigned step,
   enum machine_mode inner = GET_MODE_INNER (mode);
 
   unsigned i;
-  unsigned nunits = GET_MODE_NUNITS (mode);
-  unsigned bitsize = GET_MODE_BITSIZE (inner);
-  unsigned mask = GET_MODE_MASK (inner);
-
-  HOST_WIDE_INT val = const_vector_elt_as_int (op, nunits - 1);
-  HOST_WIDE_INT splat_val = val;
-  HOST_WIDE_INT msb_val = val > 0 ? 0 : -1;
+  unsigned nunits;
+  unsigned bitsize;
+  unsigned mask;
+
+  HOST_WIDE_INT val;
+  HOST_WIDE_INT splat_val;
+  HOST_WIDE_INT msb_val;
+
+  if (mode == V2DImode || mode == V2DFmode)
+return false;
+
+  nunits = GET_MODE_NUNITS (mode);
+  bitsize = GET_MODE_BITSIZE (inner);
+  mask = GET_MODE_MASK (inner);
+
+  val = const_vector_elt_as_int (op, nunits - 1);
+  splat_val = val;
+  msb_val = val > 0 ? 0 : -1;
 
   /* Construct the value to be splatted, if possible.  If not, return 0.  */
   for (i = 2; i <= copies; i *= 2)
@@ -5314,12 +5331,18 @@ rs6000_expand_vector_init (rtx target, r
}
   else
{
- rtx op0 = copy_to_reg (XVECEXP (vals, 0, 0));
- rtx op1 = copy_to_reg (XVECEXP (vals, 0, 1));
  if (mode == V2DFmode)
-   emit_insn (gen_vsx_concat_v2df (target, op0, op1));
+   {
+ rtx op0 = copy_to_mode_reg (

Re: [PATCH, rs6000] Fix PR48053, ICEs in SPEC benchmarks

[Peter Bergner]

On Fri, 2011-03-11 at 12:34 -0600, Peter Bergner wrote:
> This patch fixes the two related bugs in PR48053.  The problem here deals
> with loading constants into VSX registers.  The first bug occurs when we
> try and load up a full constant into the VSX register.  We end up calling
> easy_vector_constant_msb which is supported only for V4SI and V4SF modes.
> The fix here was to modify the easy_vector_constant_msb predicate to
> reject V2DI and V2DF modes.
> 
> The second bug was when we attempt to load a VSX register with a constant
> for one half of the register and a variable for the other half.  This
> caused an ICE in int_mode_for_mode.  I fixed this by first forcing the
> correct scalar mode in rs6000_expand_vector_init() and then adding
> special support in the movdi_internal* patterns to allow setting of
> VSX registers to zero.
> 
> These fixed both test cases in PR48053 and Pat Haugen verified that
> they fixed the SPEC benchmarks the test cases were reduced from,
> without introducing any new SPEC regressions.

I should mention, the first bug was exposed by Mike's recent fix for
PR47755.  The second was introduced with revision 150271, which was
Mike's initial POWER7 VSX support.

Peter

Re: fix for pr47837

[Jeff Law]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/09/11 11:07, Xinliang David Li wrote:
> Ok.
> 
> Regarding this particular patch, I hope it can be checked in to make
> the test clean. It is a simple enhancement to a wheel that is already
> there. It also serves as a case that can be referenced in the future
> when the more general mechanism is available.
Just to be clear, I'm not going to object to this patch; I don't have
the time right now to really look at it.

I was merely raising the issue that we have a need to solve the larger
problem and that we need to be looking a the bigger picture.

jeff
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNenjEAAoJEBRtltQi2kC7UmcH/0NmpkxPnJNdYzs0VxeU1ywJ
OnYxF1Za0T0JGgFpVB6NUIPwqTM/2oVG5dth6yk8wOyoVAoDKn/T7LgiLtoa/zRL
Zrr45TpvOytfrfhXmnBZCCRg7J+96GWSo4sFTlCPJe97WY9mBLLgaFgjTvHLdDPu
rA24+3a7U5eIxwvT/xfE9SdJr+GVlSiB1Ud0v9sEKlrb+hhe5pXsus3oD/oaIw08
zVqRcfTIvViA8/9c3Gqj/g6yk6Wu5aHjETtxHIQcP8OWasPioLmCda6Or43pJnJX
p8RhCov6FgWTYXdC62XwXNqPJtBE3q8rVadwz6xG28xf7GuNz7uevIfnWPK4i20=
=g4+b
-END PGP SIGNATURE-

Re: fix for pr47837

[Jeff Law]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/09/11 09:24, Xinliang David Li wrote:
> On Wed, Mar 9, 2011 at 6:03 AM, Jeff Law  wrote:
> On 03/09/11 02:45, Richard Guenther wrote:
 On Tue, Mar 8, 2011 at 11:04 PM, Jeff Law  wrote:
> 
 True.  I've been repeatedly thinking of building some on-the-side CFG
 with value-numbered predicates to also catch the CFG vs. scalar-code
 predicate combinations we have.  On such on-the-side data structure
 we could do very aggressive jump-threading just for analysis purposes
 (experiments when working on separating conditions shows that
 a PRE-like algorithm could drive this).
> I'm pondering the same kind of thing.  PRE on the predicates with a more
> structured approach to block copying to isolate the paths seems to be
> the way to go.
> 
> 
>> Any simple examples to show how your idea would work?
Our current jump threading is just a special case of path isolation; the
biggest problem with path isolation is exploding codesize.

I'd like to see that code generalized in a few ways based on well known
algorithms rather than the ad-hoc stuff we've got now keeping a
reasonable knob on the codesize bloat.

In cases where we want more accurate warnings, but aren't willing to
accept the size bloat, on the side structures might be the way to go.

I'm still looking a literature on the subject, but there's clearly
things we can do to improve the path sensitivity of the optimizers and
warning analysis.

jeff

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNenzuAAoJEBRtltQi2kC78csH/iBQvJ7UC8NQSgyYg6VRs0zZ
PeQtFOkEmZ5cmnBSswl6y82hXmBERXrvqx2/jkQa5AkM7m1gOwh8ieI40hDdsDZi
6253orEdlsWxnXJ7LOm/pmGD5JexSPNq2bbPD+fQZ6W+Xtoh4ckoyCA/f3PMQpXG
gugkRMKjwAoMHplEOZHDCQpdgssPQjsa226UwyEcvEb5mi01Atfq4PtvchYF8rnY
P2FisaYgHIbi9Ct7infXZVkPyvh0tVbbCwS/s/OPBkf+Ez6mHmEOx9dwOIkJdQEv
8uV7hXQmGbI9wLh+0Q1ZQ36o918mL4h4zYXQ8TGlqY4kVg1WEWRr1Pt+iNs7heA=
=2zgD
-END PGP SIGNATURE-

PATCH to attribute_takes_identifier_p for c++/46803

[Jason Merrill]

In 46803 we have an unknown attribute that apparently takes an 
identifier as its first argument; since my introduction of 
attribute_takes_identifier_p, we assume that most attributes do not take 
an identifier as their first argument.  But it won't hurt to assume the 
contrary for unknown attributes, since we're just going to ignore them 
anyway.


Tested x86_64-pc-linux-gnu, applied to trunk.
commit c530bce3d9db3b334ea12bde6cb17e95f0048636
Author: Jason Merrill 
Date:   Fri Mar 11 14:09:30 2011 -0500

PR c++/46803
* c-common.c (attribute_takes_identifier_p): Assume that an
unknown attribute takes an identifier.

diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index f029661..32b9a70 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -5665,9 +5665,14 @@ c_init_attributes (void)
 bool
 attribute_takes_identifier_p (const_tree attr_id)
 {
-  if (is_attribute_p ("mode", attr_id)
-  || is_attribute_p ("format", attr_id)
-  || is_attribute_p ("cleanup", attr_id))
+  struct attribute_spec *spec = lookup_attribute_spec (attr_id);
+  if (spec == NULL)
+/* Unknown attribute that we'll end up ignoring, return true so we
+   don't complain about an identifier argument.  */
+return true;
+  else if (!strcmp ("mode", spec->name)
+  || !strcmp ("format", spec->name)
+  || !strcmp ("cleanup", spec->name))
 return true;
   else
 return targetm.attribute_takes_identifier_p (attr_id);
diff --git a/gcc/testsuite/g++.dg/ext/attrib40.C 
b/gcc/testsuite/g++.dg/ext/attrib40.C
new file mode 100644
index 000..9c3f761
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/attrib40.C
@@ -0,0 +1,4 @@
+// PR c++/46803
+
+int strftime(char *, int, const char *, const struct tm *)
+__attribute__ ((__bounded__(__string__,1,2))); // { dg-warning 
"ignored" }

[PATCH] Fix PR47127: call cloog_state_malloc and cloog_state_free only once.

[Sebastian Pop]

Hi,

we currently call cloog_state_malloc and cloog_state_free too many
times.  In CLooG-Parma, these functions contain the init and fini
functions of PPL, and so calling these in the middle of graphite would
finalize all the PPL data structures, leading to memory corruption.

This patch fixes this problem.  It passed make -k check
RUNTESTFLAGS=graphite.exp with CLooG-ISL and CLooG-Parma (with only
one ICE remaining as reported in http://gcc.gnu.org/PR47128 ).  Full
regstrap with CLooG-ISL in progress on amd64-linux.  Ok for trunk?

Thanks,
Sebastian

2011-03-11  Sebastian Pop  

PR tree-optimization/47127
* graphite-clast-to-gimple.c (build_cloog_prog): Removed state
parameter.
(set_cloog_options): Same.
(scop_to_clast): Same.
(print_clast_stmt): Do not call cloog_state_malloc and
cloog_state_free.
(print_generated_program): Same.
(gloog): Same.
* graphite-clast-to-gimple.h (cloog_state): Declared.
(scop_to_clast): Adjust declaration.
* graphite.c (cloog_state): Defined here.
(graphite_initialize): Call cloog_state_malloc.
(graphite_finalize): Call cloog_state_free.
---
 gcc/ChangeLog  |   17 +
 gcc/graphite-clast-to-gimple.c |   37 +++--
 gcc/graphite-clast-to-gimple.h |7 +--
 gcc/graphite.c |4 
 4 files changed, 41 insertions(+), 24 deletions(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 3f58172..76ebc1a 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,20 @@
+2011-03-11  Sebastian Pop  
+
+   PR tree-optimization/47127
+   * graphite-clast-to-gimple.c (build_cloog_prog): Removed state
+   parameter.
+   (set_cloog_options): Same.
+   (scop_to_clast): Same.
+   (print_clast_stmt): Do not call cloog_state_malloc and
+   cloog_state_free.
+   (print_generated_program): Same.
+   (gloog): Same.
+   * graphite-clast-to-gimple.h (cloog_state): Declared.
+   (scop_to_clast): Adjust declaration.
+   * graphite.c (cloog_state): Defined here.
+   (graphite_initialize): Call cloog_state_malloc.
+   (graphite_finalize): Call cloog_state_free.
+
 2011-03-02  Richard Sandiford  
 
PR rtl-optimization/47925
diff --git a/gcc/graphite-clast-to-gimple.c b/gcc/graphite-clast-to-gimple.c
index 47a03d5..41356dc 100644
--- a/gcc/graphite-clast-to-gimple.c
+++ b/gcc/graphite-clast-to-gimple.c
@@ -1236,7 +1236,7 @@ init_cloog_input_file (int scop_number)
 
 static void
 build_cloog_prog (scop_p scop, CloogProgram *prog,
-  CloogOptions *options, CloogState *state ATTRIBUTE_UNUSED)
+  CloogOptions *options)
 {
   int i;
   int max_nb_loops = scop_max_loop_depth (scop);
@@ -1249,7 +1249,7 @@ build_cloog_prog (scop_p scop, CloogProgram *prog,
 
   cloog_program_set_context
 (prog, new_Cloog_Domain_from_ppl_Pointset_Powerset (SCOP_CONTEXT (scop),
-  scop_nb_params (scop), state));
+  scop_nb_params (scop), cloog_state));
   nbs = unify_scattering_dimensions (scop);
   scaldims = (int *) xmalloc (nbs * (sizeof (int)));
   cloog_program_set_nb_scattdims (prog, nbs);
@@ -1267,16 +1267,16 @@ build_cloog_prog (scop_p scop, CloogProgram *prog,
continue;
 
   /* Build the new statement and its block.  */
-  stmt = cloog_statement_alloc (state, pbb_index (pbb));
+  stmt = cloog_statement_alloc (cloog_state, pbb_index (pbb));
   dom = new_Cloog_Domain_from_ppl_Pointset_Powerset (PBB_DOMAIN (pbb),
  scop_nb_params (scop),
- state);
+ cloog_state);
   block = cloog_block_alloc (stmt, 0, NULL, pbb_dim_iter_domain (pbb));
   cloog_statement_set_usr (stmt, pbb);
 
   /* Build loop list.  */
   {
-CloogLoop *new_loop_list = cloog_loop_malloc (state);
+CloogLoop *new_loop_list = cloog_loop_malloc (cloog_state);
 cloog_loop_set_next (new_loop_list, loop_list);
 cloog_loop_set_domain (new_loop_list, dom);
 cloog_loop_set_block (new_loop_list, block);
@@ -1303,7 +1303,7 @@ build_cloog_prog (scop_p scop, CloogProgram *prog,
scat = PBB_TRANSFORMED_SCATTERING (pbb);
 dom = new_Cloog_Scattering_from_ppl_Polyhedron
   (scat, scop_nb_params (scop), pbb_nb_scattering_transform (pbb),
-   state);
+   cloog_state);
 
 cloog_set_next_scattering (new_scattering, scattering);
 cloog_set_scattering (new_scattering, dom);
@@ -1360,9 +1360,9 @@ build_cloog_prog (scop_p scop, CloogProgram *prog,
 /* Return the options that will be used in GLOOG.  */
 
 static CloogOptions *
-set_cloog_options (CloogState *state ATTRIBUTE_UNUSED)
+set_cloog_options (void)
 {
-  CloogOptions *options = cloog_options_malloc (state);
+  CloogOptions *options = c

Re: PATCH to attribute_takes_identifier_p for c++/46803

[Jason Merrill]

On 03/11/2011 04:35 PM, Jason Merrill wrote:

Tested x86_64-pc-linux-gnu, applied to trunk.


Hmm, I thought bootstrap used -Werror, but I just noticed some build 
warnings from this change.  Fixed thus.
commit 9bf1c74e01512f43f764c9a4d437f9d999b74117
Author: jason 
Date:   Fri Mar 11 22:38:58 2011 +

* attribs.c (lookup_attribute_spec): Take const_tree.
* tree.h: Adjust.
* c-family/c-common.c (attribute_takes_identifier_p): Add missing const.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@170887 
138bc75d-0d04-0410-961f-82ee72b054a4

diff --git a/gcc/attribs.c b/gcc/attribs.c
index d8daa6f..fee1499 100644
--- a/gcc/attribs.c
+++ b/gcc/attribs.c
@@ -208,7 +208,7 @@ register_attribute (const struct attribute_spec *attr)
 /* Return the spec for the attribute named NAME.  */
 
 const struct attribute_spec *
-lookup_attribute_spec (tree name)
+lookup_attribute_spec (const_tree name)
 {
   struct substring attr;
 
diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 32b9a70..4da9a2d 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -5665,7 +5665,7 @@ c_init_attributes (void)
 bool
 attribute_takes_identifier_p (const_tree attr_id)
 {
-  struct attribute_spec *spec = lookup_attribute_spec (attr_id);
+  const struct attribute_spec *spec = lookup_attribute_spec (attr_id);
   if (spec == NULL)
 /* Unknown attribute that we'll end up ignoring, return true so we
don't complain about an identifier argument.  */
diff --git a/gcc/tree.h b/gcc/tree.h
index 296e6de..2a94b3a 100644
--- a/gcc/tree.h
+++ b/gcc/tree.h
@@ -5348,7 +5348,7 @@ extern bool must_pass_in_stack_var_size_or_pad (enum 
machine_mode, const_tree);
 
 /* In attribs.c.  */
 
-extern const struct attribute_spec *lookup_attribute_spec (tree);
+extern const struct attribute_spec *lookup_attribute_spec (const_tree);
 
 /* Process the attributes listed in ATTRIBUTES and install them in *NODE,
which is either a DECL (including a TYPE_DECL) or a TYPE.  If a DECL,

C++ PATCH for c++/47144 (accepts-invalid with type definition in template argument)

[Jason Merrill]

G++ was oddly accepting this testcase even though it uses a name which 
is not defined anywhere.  This turns out to be because when we see the 
struct B { } we commit to all tentative parses.  We happened to be in 
the middle of testing whether A<...>::SomeNonSense is a constructor 
declarator, so when we decide that in fact it isn't, we try to abort the 
tentative parse, but we've already committed to it, so the effect is to 
just skip over those tokens and ignore them.  I'll add a sanity check to 
cp_parser_abort_tentative_parse in 4.7, but not 4.6.  In any case, 
prohibiting the type definition avoids this issue.


Tested x86_64-pc-linux-gnu, applied to trunk.
commit a338090ba7d290167871e4fb070bb69870498305
Author: Jason Merrill 
Date:   Fri Mar 11 17:27:43 2011 -0500

PR c++/47144
* parser.c (cp_parser_template_type_arg): Set
type_definition_forbidden_message.

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 7e9b286..4260f6d 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -15685,7 +15685,13 @@ static tree cp_parser_type_id (cp_parser *parser)
 
 static tree cp_parser_template_type_arg (cp_parser *parser)
 {
-  return cp_parser_type_id_1 (parser, true, false);
+  tree r;
+  const char *saved_message = parser->type_definition_forbidden_message;
+  parser->type_definition_forbidden_message
+= G_("types may not be defined in template arguments");
+  r = cp_parser_type_id_1 (parser, true, false);
+  parser->type_definition_forbidden_message = saved_message;
+  return r;
 }
 
 static tree cp_parser_trailing_type_id (cp_parser *parser)
diff --git a/gcc/testsuite/g++.dg/parse/no-type-defn1.C 
b/gcc/testsuite/g++.dg/parse/no-type-defn1.C
new file mode 100644
index 000..9e89957
--- /dev/null
+++ b/gcc/testsuite/g++.dg/parse/no-type-defn1.C
@@ -0,0 +1,5 @@
+// PR c++/47144
+
+template struct A { };
+A< struct B { }* >::SomeNonSense // { dg-error "types may not be defined" }
+int y;

[x32] PR target/47446: [x32] .quad instead of .long is used for address

[H.J. Lu]

I checked in this patch to always allow the offsetted memory references
for TARGET_X32.


H.J.

commit 8dba2cfc28716e09853233e19500e44ba2619cb6
Author: H.J. Lu 
Date:   Fri Mar 11 13:34:17 2011 -0800

Always allow the offsetted memory references for TARGET_X32.

diff --git a/gcc/ChangeLog.x32 b/gcc/ChangeLog.x32
index 3f1f953..ac312af 100644
--- a/gcc/ChangeLog.x32
+++ b/gcc/ChangeLog.x32
@@ -1,3 +1,13 @@
+2011-03-11  H.J. Lu  
+
+   PR target/47446
+   * config/i386/i386.md (*movdi_internal_rex64): Only allow moving
+   integer constants into 64bit registers for TARGET_X32.
+
+   * config/i386/predicates.md (x86_64_immediate_operand): Always
+   allow the offsetted memory references for TARGET_X32.
+   (x86_64_zext_immediate_operand): Likewise.
+
 2011-03-07  H.J. Lu  
 
PR middle-end/48016
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 509ee82..d092a84 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -2023,10 +2023,8 @@
return "mov{l}\t{%k1, %k0|%k0, %k1}";
   else if (which_alternative == 2)
{
- if (TARGET_X32)
-   return "movabs{q}\t{%1, %0|%0, %1}";
- else
-   return "mov{q}\t{%1, %0|%0, %1}";
+ gcc_assert (!TARGET_X32 || CONST_INT_P (operands[1]));
+ return "movabs{q}\t{%1, %0|%0, %1}";
}
   else
return "mov{q}\t{%1, %0|%0, %1}";
diff --git a/gcc/config/i386/predicates.md b/gcc/config/i386/predicates.md
index 4bd5688..7c40958 100644
--- a/gcc/config/i386/predicates.md
+++ b/gcc/config/i386/predicates.md
@@ -188,8 +188,10 @@
  if ((ix86_cmodel == CM_SMALL
   || (ix86_cmodel == CM_MEDIUM
   && !SYMBOL_REF_FAR_ADDR_P (op1)))
- && offset < 16*1024*1024
- && trunc_int_for_mode (offset, SImode) == offset)
+ && (TARGET_X32
+ || (offset < 16*1024*1024
+ && (trunc_int_for_mode (offset, SImode)
+ == offset
return true;
  /* For CM_KERNEL we know that all object resist in the
 negative half of 32bits address space.  We may not
@@ -293,8 +295,11 @@
   || (ix86_cmodel == CM_MEDIUM
   && !SYMBOL_REF_FAR_ADDR_P (op1)))
  && CONST_INT_P (op2)
- && trunc_int_for_mode (INTVAL (op2), DImode) > -0x1
- && trunc_int_for_mode (INTVAL (op2), SImode) == INTVAL (op2))
+ && (TARGET_X32
+ || ((trunc_int_for_mode (INTVAL (op2), DImode)
+  > -0x1)
+ && (trunc_int_for_mode (INTVAL (op2), SImode)
+ == INTVAL (op2)
return true;
  /* ??? For the kernel, we may accept adjustment of
 -0x1000, since we know that it will just convert
diff --git a/gcc/testsuite/ChangeLog.x32 b/gcc/testsuite/ChangeLog.x32
index e5c6bfd..39ed391 100644
--- a/gcc/testsuite/ChangeLog.x32
+++ b/gcc/testsuite/ChangeLog.x32
@@ -1,3 +1,8 @@
+2011-03-11  H.J. Lu  
+
+   PR target/47446
+   * gcc.target/i386/pr47446-3.c: New.
+
 2011-03-06  H.J. Lu  
 
* go.test/go-test.exp (go-set-goarch): Check x32.
diff --git a/gcc/testsuite/gcc.target/i386/pr47446-3.c 
b/gcc/testsuite/gcc.target/i386/pr47446-3.c
new file mode 100644
index 000..faa5f1f
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr47446-3.c
@@ -0,0 +1,21 @@
+/* { dg-do assemble } */
+/* { dg-options "-O3 -funroll-all-loops" } */
+
+extern char inbuf[];
+extern char outbuf[];
+extern unsigned insize;
+extern unsigned inptr;
+static int max_len;
+static int peek_bits;
+void build_tree() {
+  int len;
+  char *prefixp;
+  max_len = inbuf[inptr++];
+  peek_bits = ((max_len) <= (12) ? (max_len) : (12));
+  prefixp = &outbuf[1< outbuf) *--prefixp = 0;
+}

Re: fix for pr47837

[Richard Guenther]

On Fri, Mar 11, 2011 at 8:50 PM, Jeff Law  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 03/09/11 09:24, Xinliang David Li wrote:
>> On Wed, Mar 9, 2011 at 6:03 AM, Jeff Law  wrote:
>> On 03/09/11 02:45, Richard Guenther wrote:
> On Tue, Mar 8, 2011 at 11:04 PM, Jeff Law  wrote:
>>
> True.  I've been repeatedly thinking of building some on-the-side CFG
> with value-numbered predicates to also catch the CFG vs. scalar-code
> predicate combinations we have.  On such on-the-side data structure
> we could do very aggressive jump-threading just for analysis purposes
> (experiments when working on separating conditions shows that
> a PRE-like algorithm could drive this).
>> I'm pondering the same kind of thing.  PRE on the predicates with a more
>> structured approach to block copying to isolate the paths seems to be
>> the way to go.
>>
>>
>>> Any simple examples to show how your idea would work?
> Our current jump threading is just a special case of path isolation; the
> biggest problem with path isolation is exploding codesize.
>
> I'd like to see that code generalized in a few ways based on well known
> algorithms rather than the ad-hoc stuff we've got now keeping a
> reasonable knob on the codesize bloat.
>
> In cases where we want more accurate warnings, but aren't willing to
> accept the size bloat, on the side structures might be the way to go.
>
> I'm still looking a literature on the subject, but there's clearly
> things we can do to improve the path sensitivity of the optimizers and
> warning analysis.

Yes, I am also thinking of static analysis stuff people seem to want.
That requires us to not actually do any transform.

Richard.

Re: [PATCH] Fix PR47127: call cloog_state_malloc and cloog_state_free only once.

[Richard Guenther]

On Fri, Mar 11, 2011 at 10:38 PM, Sebastian Pop  wrote:
> Hi,
>
> we currently call cloog_state_malloc and cloog_state_free too many
> times.  In CLooG-Parma, these functions contain the init and fini
> functions of PPL, and so calling these in the middle of graphite would
> finalize all the PPL data structures, leading to memory corruption.
>
> This patch fixes this problem.  It passed make -k check
> RUNTESTFLAGS=graphite.exp with CLooG-ISL and CLooG-Parma (with only
> one ICE remaining as reported in http://gcc.gnu.org/PR47128 ).  Full
> regstrap with CLooG-ISL in progress on amd64-linux.  Ok for trunk?

Ok.

Thanks,
Richard.

> Thanks,
> Sebastian
>
> 2011-03-11  Sebastian Pop  
>
>        PR tree-optimization/47127
>        * graphite-clast-to-gimple.c (build_cloog_prog): Removed state
>        parameter.
>        (set_cloog_options): Same.
>        (scop_to_clast): Same.
>        (print_clast_stmt): Do not call cloog_state_malloc and
>        cloog_state_free.
>        (print_generated_program): Same.
>        (gloog): Same.
>        * graphite-clast-to-gimple.h (cloog_state): Declared.
>        (scop_to_clast): Adjust declaration.
>        * graphite.c (cloog_state): Defined here.
>        (graphite_initialize): Call cloog_state_malloc.
>        (graphite_finalize): Call cloog_state_free.
> ---
>  gcc/ChangeLog                  |   17 +
>  gcc/graphite-clast-to-gimple.c |   37 +++--
>  gcc/graphite-clast-to-gimple.h |    7 +--
>  gcc/graphite.c                 |    4 
>  4 files changed, 41 insertions(+), 24 deletions(-)
>
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> index 3f58172..76ebc1a 100644
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,3 +1,20 @@
> +2011-03-11  Sebastian Pop  
> +
> +       PR tree-optimization/47127
> +       * graphite-clast-to-gimple.c (build_cloog_prog): Removed state
> +       parameter.
> +       (set_cloog_options): Same.
> +       (scop_to_clast): Same.
> +       (print_clast_stmt): Do not call cloog_state_malloc and
> +       cloog_state_free.
> +       (print_generated_program): Same.
> +       (gloog): Same.
> +       * graphite-clast-to-gimple.h (cloog_state): Declared.
> +       (scop_to_clast): Adjust declaration.
> +       * graphite.c (cloog_state): Defined here.
> +       (graphite_initialize): Call cloog_state_malloc.
> +       (graphite_finalize): Call cloog_state_free.
> +
>  2011-03-02  Richard Sandiford  
>
>        PR rtl-optimization/47925
> diff --git a/gcc/graphite-clast-to-gimple.c b/gcc/graphite-clast-to-gimple.c
> index 47a03d5..41356dc 100644
> --- a/gcc/graphite-clast-to-gimple.c
> +++ b/gcc/graphite-clast-to-gimple.c
> @@ -1236,7 +1236,7 @@ init_cloog_input_file (int scop_number)
>
>  static void
>  build_cloog_prog (scop_p scop, CloogProgram *prog,
> -                  CloogOptions *options, CloogState *state ATTRIBUTE_UNUSED)
> +                  CloogOptions *options)
>  {
>   int i;
>   int max_nb_loops = scop_max_loop_depth (scop);
> @@ -1249,7 +1249,7 @@ build_cloog_prog (scop_p scop, CloogProgram *prog,
>
>   cloog_program_set_context
>     (prog, new_Cloog_Domain_from_ppl_Pointset_Powerset (SCOP_CONTEXT (scop),
> -      scop_nb_params (scop), state));
> +      scop_nb_params (scop), cloog_state));
>   nbs = unify_scattering_dimensions (scop);
>   scaldims = (int *) xmalloc (nbs * (sizeof (int)));
>   cloog_program_set_nb_scattdims (prog, nbs);
> @@ -1267,16 +1267,16 @@ build_cloog_prog (scop_p scop, CloogProgram *prog,
>        continue;
>
>       /* Build the new statement and its block.  */
> -      stmt = cloog_statement_alloc (state, pbb_index (pbb));
> +      stmt = cloog_statement_alloc (cloog_state, pbb_index (pbb));
>       dom = new_Cloog_Domain_from_ppl_Pointset_Powerset (PBB_DOMAIN (pbb),
>                                                          scop_nb_params 
> (scop),
> -                                                         state);
> +                                                         cloog_state);
>       block = cloog_block_alloc (stmt, 0, NULL, pbb_dim_iter_domain (pbb));
>       cloog_statement_set_usr (stmt, pbb);
>
>       /* Build loop list.  */
>       {
> -        CloogLoop *new_loop_list = cloog_loop_malloc (state);
> +        CloogLoop *new_loop_list = cloog_loop_malloc (cloog_state);
>         cloog_loop_set_next (new_loop_list, loop_list);
>         cloog_loop_set_domain (new_loop_list, dom);
>         cloog_loop_set_block (new_loop_list, block);
> @@ -1303,7 +1303,7 @@ build_cloog_prog (scop_p scop, CloogProgram *prog,
>        scat = PBB_TRANSFORMED_SCATTERING (pbb);
>         dom = new_Cloog_Scattering_from_ppl_Polyhedron
>           (scat, scop_nb_params (scop), pbb_nb_scattering_transform (pbb),
> -           state);
> +           cloog_state);
>
>         cloog_set_next_scattering (new_scattering, scattering);
>         cloog_set_scattering (new_scattering, dom);
> @@ -1360,9 +1360,9 @@ build_cloog_prog (scop_p scop, CloogProgram *p

Re: fix for pr47837

[Xinliang David Li]

On Fri, Mar 11, 2011 at 11:50 AM, Jeff Law  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 03/09/11 09:24, Xinliang David Li wrote:
>> On Wed, Mar 9, 2011 at 6:03 AM, Jeff Law  wrote:
>> On 03/09/11 02:45, Richard Guenther wrote:
> On Tue, Mar 8, 2011 at 11:04 PM, Jeff Law  wrote:
>>
> True.  I've been repeatedly thinking of building some on-the-side CFG
> with value-numbered predicates to also catch the CFG vs. scalar-code
> predicate combinations we have.  On such on-the-side data structure
> we could do very aggressive jump-threading just for analysis purposes
> (experiments when working on separating conditions shows that
> a PRE-like algorithm could drive this).
>> I'm pondering the same kind of thing.  PRE on the predicates with a more
>> structured approach to block copying to isolate the paths seems to be
>> the way to go.
>>
>>
>>> Any simple examples to show how your idea would work?
> Our current jump threading is just a special case of path isolation; the
> biggest problem with path isolation is exploding codesize.

Jump threading can reduce size in some cases -- due to more aggressive
cleanups -- the -Os need to be more intelligent about it.

>
> I'd like to see that code generalized in a few ways based on well known
> algorithms rather than the ad-hoc stuff we've got now keeping a
> reasonable knob on the codesize bloat.
>
> In cases where we want more accurate warnings, but aren't willing to
> accept the size bloat, on the side structures might be the way to go.
>
> I'm still looking a literature on the subject, but there's clearly
> things we can do to improve the path sensitivity of the optimizers and
> warning analysis.

There are actually many papers on this (e.g. IMPACT group)  as a
result of research for EPIC optimizations (predication and if
convert). Most of them talk about predicate query systems (efficient
and accurate), e.g PQS using partition graph, PAS using BDD etc.  The
predicates relation can be built as side data structure, and the
following queries can be made:

 p1 = get_predicate (gimple_stmt1);
 p2 = get_predicate (gimple_stmt2);

if (is_disjoint (p1, p2) )
  ..
else if is_subset(p1, p2).
   ..

Keeping the information up to date with transformations can be difficult.

David


>
> jeff
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJNenzuAAoJEBRtltQi2kC78csH/iBQvJ7UC8NQSgyYg6VRs0zZ
> PeQtFOkEmZ5cmnBSswl6y82hXmBERXrvqx2/jkQa5AkM7m1gOwh8ieI40hDdsDZi
> 6253orEdlsWxnXJ7LOm/pmGD5JexSPNq2bbPD+fQZ6W+Xtoh4ckoyCA/f3PMQpXG
> gugkRMKjwAoMHplEOZHDCQpdgssPQjsa226UwyEcvEb5mi01Atfq4PtvchYF8rnY
> P2FisaYgHIbi9Ct7infXZVkPyvh0tVbbCwS/s/OPBkf+Ez6mHmEOx9dwOIkJdQEv
> 8uV7hXQmGbI9wLh+0Q1ZQ36o918mL4h4zYXQ8TGlqY4kVg1WEWRr1Pt+iNs7heA=
> =2zgD
> -END PGP SIGNATURE-
>

C++ PATCH for c++/47125 (ICE with template elaborated-type-specifier)

[Jason Merrill]

A straightforward case of some errors that were not properly protected 
by checking complain.


Tested x86_64-pc-linux-gnu, applied to trunk.
commit 49d36af37792ed3f1359f80443bc2ef9a25270c1
Author: Jason Merrill 
Date:   Fri Mar 11 21:32:40 2011 -0500

PR c++/47125
* pt.c (tsubst) [TYPENAME_TYPE]: Only give errors if tf_error.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index ab2aea3..95b82ee 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -10948,11 +10948,21 @@ tsubst (tree t, tree args, tsubst_flags_t complain, 
tree in_decl)
if (TREE_CODE (f) != TYPENAME_TYPE)
  {
if (TYPENAME_IS_ENUM_P (t) && TREE_CODE (f) != ENUMERAL_TYPE)
- error ("%qT resolves to %qT, which is not an enumeration type",
-t, f);
+ {
+   if (complain & tf_error)
+ error ("%qT resolves to %qT, which is not an enumeration 
type",
+t, f);
+   else
+ return error_mark_node;
+ }
else if (TYPENAME_IS_CLASS_P (t) && !CLASS_TYPE_P (f))
- error ("%qT resolves to %qT, which is is not a class type",
-t, f);
+ {
+   if (complain & tf_error)
+ error ("%qT resolves to %qT, which is is not a class type",
+t, f);
+   else
+ return error_mark_node;
+ }
  }
 
return cp_build_qualified_type_real
diff --git a/gcc/testsuite/g++.dg/template/error45.C 
b/gcc/testsuite/g++.dg/template/error45.C
new file mode 100644
index 000..454acc6
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/error45.C
@@ -0,0 +1,22 @@
+// PR c++/47125
+
+template < bool, typename >
+struct enable_if {};
+
+template < typename T >
+struct enable_if< true, T >
+{
+typedef T type;
+};
+
+template < typename T >
+struct enable_if< true, T >::type
+f( T x );
+
+void
+g( void )
+{
+  f< int >( 0 );   // { dg-error "no match" }
+}
+
+// { dg-prune-output "note" }