Re: [PATCH] PR c++/PR48035
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
Re: [C++0x patch] constexpr in attribute argument
On Fri, Mar 11, 2011 at 6:51 AM, Jason Merrill ja...@redhat.com 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 S3int: .../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
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 mjam...@suse.cz
* 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
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
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 mjam...@suse.cz
* 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 rguent...@suse.de
Novell / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex
Re: [PATCH][C] Fix PR47939
On Thu, 10 Mar 2011, Joseph S. Myers wrote: On Wed, 2 Mar 2011, Richard Guenther wrote: 2011-03-02 Richard Guenther rguent...@suse.de 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
2011/3/11 Paolo Bonzini bonz...@gnu.org: 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: [build, lto] Only accept -fuse-linker-plugin if linker supports -plugin (PR lto/46944)
On Thu, 10 Mar 2011, Rainer Orth wrote:
Richard Guenther rguent...@suse.de 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: Problem with procedure pointers
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 Weilja...@gcc.gnu.org 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 Weilja...@gcc.gnu.org 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
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
On Fri, Mar 11, 2011 at 5:23 AM, Nathan Froyd froy...@codesourcery.com 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)) except for a
FIELD_DECL. */
@@ -2900,7 +2904,7 @@ struct GTY(()) tree_decl_with_rtl {
#define
Re: [PATCH 05/18] remove TREE_CHAIN from CONSTRUCTOR nodes
On Fri, Mar 11, 2011 at 5:23 AM, Nathan Froyd froy...@codesourcery.com 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
On Fri, Mar 11, 2011 at 5:23 AM, Nathan Froyd froy...@codesourcery.com 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 06/18] define CASE_CHAIN accessor for CASE_LABEL_EXPR
On Fri, Mar 11, 2011 at 5:23 AM, Nathan Froyd froy...@codesourcery.com 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
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 17/18] introduce block_chainon and use BLOCK_CHAIN more
On Fri, Mar 11, 2011 at 02:15:20PM +0100, Richard Guenther wrote: On Fri, Mar 11, 2011 at 5:23 AM, Nathan Froyd froy...@codesourcery.com 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
On Fri, Mar 11, 2011 at 5:23 AM, Nathan Froyd froy...@codesourcery.com 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
On Fri, Mar 11, 2011 at 5:23 AM, Nathan Froyd froy...@codesourcery.com 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_INITIALIZER;
diff --git a/gcc/c-decl.c b/gcc/c-decl.c
index b438b06..14aef5f 100644
--- a/gcc/c-decl.c
+++
Re: [PATCH, 4.7] Have all inlining destinations analyzed
On Fri, Mar 11, 2011 at 10:58 AM, Martin Jambor mjam...@suse.cz 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
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
[Patch][AVR]: Support tail calls
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 a...@gjlay.de
* 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 %x0
+ [(set_attr cc clobber)
(set_attr_alternative length
- [(const_int 1)
- (if_then_else (eq_attr mcu_have_movw yes)
Re: [PATCH 15/18] move REAL_IDENTIFIER_TYPE_VALUE to be a field of lang_identifier
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
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
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 Weilja...@gcc.gnu.org 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 Weilja...@gcc.gnu.org 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
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 07/18] generalize build_case_label to the rest of the compiler
Nathan == Nathan Froyd froy...@codesourcery.com 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
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 01/18] add typed_tree structure
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: [build, lto] Only accept -fuse-linker-plugin if linker supports -plugin (PR lto/46944)
On Fri, 11 Mar 2011, Rainer Orth wrote: Richard Guenther rguent...@suse.de 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
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: [build, lto] Only accept -fuse-linker-plugin if linker supports -plugin (PR lto/46944)
Richard Guenther rguent...@suse.de 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
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
Re: 4.5 backport request...
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.
[PATCH, rs6000] Fix PR48053, ICEs in SPEC benchmarks
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 (DFmode, XVECEXP
Re: fix for pr47837
-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
-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 l...@redhat.com wrote: On 03/09/11 02:45, Richard Guenther wrote: On Tue, Mar 8, 2011 at 11:04 PM, Jeff Law l...@redhat.com 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-
Re: PATCH to attribute_takes_identifier_p for c++/46803
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 jason@138bc75d-0d04-0410-961f-82ee72b054a4
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)
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 ja...@redhat.com
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
+
+templatetypename 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
I checked in this patch to always allow the offsetted memory references
for TARGET_X32.
H.J.
commit 8dba2cfc28716e09853233e19500e44ba2619cb6
Author: H.J. Lu hjl.to...@gmail.com
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 hongjiu...@intel.com
+
+ 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 hongjiu...@intel.com
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 hongjiu...@intel.com
+
+ PR target/47446
+ * gcc.target/i386/pr47446-3.c: New.
+
2011-03-06 H.J. Lu hongjiu...@intel.com
* 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[1peek_bits];
+ for (len = 1;
+ len = peek_bits;
+ len++) {
+ }
+ while (prefixp outbuf) *--prefixp = 0;
+}
Re: fix for pr47837
On Fri, Mar 11, 2011 at 8:50 PM, Jeff Law l...@redhat.com 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 l...@redhat.com wrote: On 03/09/11 02:45, Richard Guenther wrote: On Tue, Mar 8, 2011 at 11:04 PM, Jeff Law l...@redhat.com 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.
On Fri, Mar 11, 2011 at 10:38 PM, Sebastian Pop seb...@gmail.com 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 sebastian@amd.com
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 sebastian@amd.com
+
+ 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 richard.sandif...@linaro.org
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
Re: fix for pr47837
On Fri, Mar 11, 2011 at 11:50 AM, Jeff Law l...@redhat.com 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 l...@redhat.com wrote: On 03/09/11 02:45, Richard Guenther wrote: On Tue, Mar 8, 2011 at 11:04 PM, Jeff Law l...@redhat.com 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)
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 ja...@redhat.com
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 }
