* [C++ PATCH] Fix vector_size handling in templates (PR c++/35758) @ 2008-04-01 14:37 Jakub Jelinek 2008-04-01 16:23 ` Mark Mitchell 2008-04-07 17:42 ` Jason Merrill 0 siblings, 2 replies; 14+ messages in thread From: Jakub Jelinek @ 2008-04-01 14:37 UTC (permalink / raw) To: Jason Merrill, Mark Mitchell; +Cc: gcc-patches Hi! As attached testcase shows, I believe we can't make vector_size attribute a late tmpl attribute unconditionally. This patch ressurrects my patch from January, though this time in a hopefully cleaner form of a langhook. Ok for trunk/4.3? 2008-04-01 Jakub Jelinek <jakub@redhat.com> PR c++/35758 * c-common.c (handle_vector_size_attribute): Call lang_hooks.types.reconstruct_complex_type instead of reconstruct_complex_type. * langhooks.h (struct lang_hooks_for_types): Add reconstruct_complex_type hook. * langhooks-def.h (LANG_HOOKS_RECONSTRUCT_COMPLEX_TYPE): Define. (LANG_HOOKS_FOR_TYPES_INITIALIZER): Add it. * cp-tree.h (cp_reconstruct_complex_type): New prototype. * cp-objcp-common.h (LANG_HOOKS_RECONSTRUCT_COMPLEX_TYPE): Define. * decl2.c (is_late_template_attribute): Only make vector_size late tmpl attribute if argument is type or value dependent. (cp_reconstruct_complex_type): New function. * g++.dg/ext/vector14.C: New test. --- gcc/c-common.c.jj 2008-04-01 13:34:25.000000000 +0200 +++ gcc/c-common.c 2008-04-01 13:44:56.000000000 +0200 @@ -6073,7 +6073,7 @@ handle_vector_size_attribute (tree *node new_type = build_vector_type (type, nunits); /* Build back pointers if needed. */ - *node = reconstruct_complex_type (*node, new_type); + *node = lang_hooks.types.reconstruct_complex_type (*node, new_type); return NULL_TREE; } --- gcc/langhooks.h.jj 2008-04-01 13:34:25.000000000 +0200 +++ gcc/langhooks.h 2008-04-01 13:44:56.000000000 +0200 @@ -150,6 +150,12 @@ struct lang_hooks_for_types for the debugger about the array bounds, strides, etc. */ bool (*get_array_descr_info) (const_tree, struct array_descr_info *); + /* If we requested a pointer to a vector, build up the pointers that + we stripped off while looking for the inner type. Similarly for + return values from functions. The argument TYPE is the top of the + chain, and BOTTOM is the new type which we will point to. */ + tree (*reconstruct_complex_type) (tree, tree); + /* Nonzero if types that are identical are to be hashed so that only one copy is kept. If a language requires unique types for each user-specified type, such as Ada, this should be set to TRUE. */ --- gcc/langhooks-def.h.jj 2008-04-01 13:34:25.000000000 +0200 +++ gcc/langhooks-def.h 2008-04-01 13:44:56.000000000 +0200 @@ -182,6 +182,7 @@ extern tree lhd_make_node (enum tree_cod lhd_omp_firstprivatize_type_sizes #define LANG_HOOKS_TYPE_HASH_EQ NULL #define LANG_HOOKS_GET_ARRAY_DESCR_INFO NULL +#define LANG_HOOKS_RECONSTRUCT_COMPLEX_TYPE reconstruct_complex_type #define LANG_HOOKS_HASH_TYPES true #define LANG_HOOKS_FOR_TYPES_INITIALIZER { \ @@ -197,6 +198,7 @@ extern tree lhd_make_node (enum tree_cod LANG_HOOKS_OMP_FIRSTPRIVATIZE_TYPE_SIZES, \ LANG_HOOKS_TYPE_HASH_EQ, \ LANG_HOOKS_GET_ARRAY_DESCR_INFO, \ + LANG_HOOKS_RECONSTRUCT_COMPLEX_TYPE, \ LANG_HOOKS_HASH_TYPES \ } --- gcc/cp/cp-tree.h.jj 2008-04-01 13:34:25.000000000 +0200 +++ gcc/cp/cp-tree.h 2008-04-01 13:44:56.000000000 +0200 @@ -4284,6 +4284,7 @@ extern tree grokfield (const cp_declarat tree, bool, tree, tree); extern tree grokbitfield (const cp_declarator *, cp_decl_specifier_seq *, tree); +extern tree cp_reconstruct_complex_type (tree, tree); extern void cplus_decl_attributes (tree *, tree, int); extern void finish_anon_union (tree); extern void cp_write_global_declarations (void); --- gcc/cp/cp-objcp-common.h.jj 2008-04-01 13:34:25.000000000 +0200 +++ gcc/cp/cp-objcp-common.h 2008-04-01 13:44:56.000000000 +0200 @@ -130,6 +130,8 @@ extern tree objcp_tsubst_copy_and_build #define LANG_HOOKS_TYPE_PROMOTES_TO cxx_type_promotes_to #undef LANG_HOOKS_REGISTER_BUILTIN_TYPE #define LANG_HOOKS_REGISTER_BUILTIN_TYPE c_register_builtin_type +#undef LANG_HOOKS_RECONSTRUCT_COMPLEX_TYPE +#define LANG_HOOKS_RECONSTRUCT_COMPLEX_TYPE cp_reconstruct_complex_type #undef LANG_HOOKS_TO_TARGET_CHARSET #define LANG_HOOKS_TO_TARGET_CHARSET c_common_to_target_charset #undef LANG_HOOKS_GIMPLIFY_EXPR --- gcc/cp/decl2.c.jj 2008-04-01 13:34:25.000000000 +0200 +++ gcc/cp/decl2.c 2008-04-01 15:21:59.000000000 +0200 @@ -991,11 +991,8 @@ is_late_template_attribute (tree attr, t /* Unknown attribute. */ return false; - /* Attribute vector_size handling wants to dive into the back end array - building code, which breaks during template processing. */ - if (is_attribute_p ("vector_size", name) - /* Attribute weak handling wants to write out assembly right away. */ - || is_attribute_p ("weak", name)) + /* Attribute weak handling wants to write out assembly right away. */ + if (is_attribute_p ("weak", name)) return true; /* If any of the arguments are dependent expressions, we can't evaluate @@ -1120,6 +1117,62 @@ save_template_attributes (tree *attr_p, } } +/* Like reconstruct_complex_type, but handle also template trees. */ + +tree +cp_reconstruct_complex_type (tree type, tree bottom) +{ + tree inner, outer; + + if (TREE_CODE (type) == POINTER_TYPE) + { + inner = cp_reconstruct_complex_type (TREE_TYPE (type), bottom); + outer = build_pointer_type_for_mode (inner, TYPE_MODE (type), + TYPE_REF_CAN_ALIAS_ALL (type)); + } + else if (TREE_CODE (type) == REFERENCE_TYPE) + { + inner = cp_reconstruct_complex_type (TREE_TYPE (type), bottom); + outer = build_reference_type_for_mode (inner, TYPE_MODE (type), + TYPE_REF_CAN_ALIAS_ALL (type)); + } + else if (TREE_CODE (type) == ARRAY_TYPE) + { + inner = cp_reconstruct_complex_type (TREE_TYPE (type), bottom); + outer = build_cplus_array_type (inner, TYPE_DOMAIN (type)); + /* Don't call cp_build_qualified_type on ARRAY_TYPEs, the + element type qualification will be handled by the recursive + cp_reconstruct_complex_type call and cp_build_qualified_type + for ARRAY_TYPEs changes the element type. */ + return outer; + } + else if (TREE_CODE (type) == FUNCTION_TYPE) + { + inner = cp_reconstruct_complex_type (TREE_TYPE (type), bottom); + outer = build_function_type (inner, TYPE_ARG_TYPES (type)); + } + else if (TREE_CODE (type) == METHOD_TYPE) + { + inner = cp_reconstruct_complex_type (TREE_TYPE (type), bottom); + /* The build_method_type_directly() routine prepends 'this' to argument list, + so we must compensate by getting rid of it. */ + outer + = build_method_type_directly + (TREE_TYPE (TREE_VALUE (TYPE_ARG_TYPES (type))), + inner, + TREE_CHAIN (TYPE_ARG_TYPES (type))); + } + else if (TREE_CODE (type) == OFFSET_TYPE) + { + inner = cp_reconstruct_complex_type (TREE_TYPE (type), bottom); + outer = build_offset_type (TYPE_OFFSET_BASETYPE (type), inner); + } + else + return bottom; + + return cp_build_qualified_type (outer, TYPE_QUALS (type)); +} + /* Like decl_attributes, but handle C++ complexity. */ void --- gcc/testsuite/g++.dg/ext/vector14.C.jj 2008-04-01 15:30:42.000000000 +0200 +++ gcc/testsuite/g++.dg/ext/vector14.C 2008-04-01 14:27:47.000000000 +0200 @@ -0,0 +1,17 @@ +// PR c++/35758 +// { dg-do compile } + +#define vector __attribute__((vector_size(16))) + +template<int N> vector signed int foo (vector float value) {} + +template<int> void foo (float) {} + +int +main () +{ + vector float v; + float f; + foo<1> (v); + foo<1> (f); +} Jakub ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [C++ PATCH] Fix vector_size handling in templates (PR c++/35758) 2008-04-01 14:37 [C++ PATCH] Fix vector_size handling in templates (PR c++/35758) Jakub Jelinek @ 2008-04-01 16:23 ` Mark Mitchell 2008-04-01 16:39 ` Andrew Pinski 2008-04-07 17:42 ` Jason Merrill 1 sibling, 1 reply; 14+ messages in thread From: Mark Mitchell @ 2008-04-01 16:23 UTC (permalink / raw) To: Jakub Jelinek; +Cc: Jason Merrill, gcc-patches Jakub Jelinek wrote: > As attached testcase shows, I believe we can't make vector_size > attribute a late tmpl attribute unconditionally. This patch ressurrects > my patch from January, though this time in a hopefully cleaner form > of a langhook. I don't understand how the testcase shows that. Would you please explain in more detail? > +#define vector __attribute__((vector_size(16))) > +template<int N> vector signed int foo (vector float value) {} > +template<int> void foo (float) {} > + > +int > +main () > +{ > + vector float v; > + float f; > + foo<1> (v); > + foo<1> (f); > +} Thanks, -- Mark Mitchell CodeSourcery mark@codesourcery.com (650) 331-3385 x713 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [C++ PATCH] Fix vector_size handling in templates (PR c++/35758) 2008-04-01 16:23 ` Mark Mitchell @ 2008-04-01 16:39 ` Andrew Pinski 2008-04-01 16:44 ` Mark Mitchell 0 siblings, 1 reply; 14+ messages in thread From: Andrew Pinski @ 2008-04-01 16:39 UTC (permalink / raw) To: Mark Mitchell; +Cc: Jakub Jelinek, Jason Merrill, gcc-patches Sent from my iPhone On Apr 1, 2008, at 9:23, Mark Mitchell <mark@codesourcery.com> wrote: > Jakub Jelinek wrote: > >> As attached testcase shows, I believe we can't make vector_size >> attribute a late tmpl attribute unconditionally. This patch >> ressurrects >> my patch from January, though this time in a hopefully cleaner form >> of a langhook. > > I don't understand how the testcase shows that. Would you please > explain in more detail? I will explain what happens here. First we mark the attribute as being expanded late so we have a type of float in the function agrument; then at overload time, we don't resolve the attribute. As shown by a different testcase in the bug report which I mention in this bug report, we should be resolving the attributes at overload time so I disagree with Jakub's patch. Thanks, Andrew Pinski > > >> +#define vector __attribute__((vector_size(16))) >> +template<int N> vector signed int foo (vector float value) {} >> +template<int> void foo (float) {} >> + >> +int >> +main () >> +{ >> + vector float v; >> + float f; >> + foo<1> (v); >> + foo<1> (f); >> +} > > Thanks, > > -- > Mark Mitchell > CodeSourcery > mark@codesourcery.com > (650) 331-3385 x713 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [C++ PATCH] Fix vector_size handling in templates (PR c++/35758) 2008-04-01 16:39 ` Andrew Pinski @ 2008-04-01 16:44 ` Mark Mitchell 2008-04-02 13:10 ` Jakub Jelinek 0 siblings, 1 reply; 14+ messages in thread From: Mark Mitchell @ 2008-04-01 16:44 UTC (permalink / raw) To: Andrew Pinski; +Cc: Jakub Jelinek, Jason Merrill, gcc-patches Andrew Pinski wrote: > I will explain what happens here. First we mark the attribute as being > expanded late so we have a type of float in the function agrument; then > at overload time, we don't resolve the attribute. As shown by a > different testcase in the bug report which I mention in this bug report, > we should be resolving the attributes at overload time so I disagree > with Jakub's patch. That was my thinking too. Overload resolution requires instantiation of template arguments in the parameter types, and, for us, that includes late attributes. -- Mark Mitchell CodeSourcery mark@codesourcery.com (650) 331-3385 x713 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [C++ PATCH] Fix vector_size handling in templates (PR c++/35758) 2008-04-01 16:44 ` Mark Mitchell @ 2008-04-02 13:10 ` Jakub Jelinek 0 siblings, 0 replies; 14+ messages in thread From: Jakub Jelinek @ 2008-04-02 13:10 UTC (permalink / raw) To: Mark Mitchell, Jason Merrill; +Cc: Andrew Pinski, gcc-patches On Tue, Apr 01, 2008 at 09:43:49AM -0700, Mark Mitchell wrote: > Andrew Pinski wrote: > > >I will explain what happens here. First we mark the attribute as being > >expanded late so we have a type of float in the function agrument; then > >at overload time, we don't resolve the attribute. As shown by a > >different testcase in the bug report which I mention in this bug report, > >we should be resolving the attributes at overload time so I disagree > >with Jakub's patch. > > That was my thinking too. Overload resolution requires instantiation of > template arguments in the parameter types, and, for us, that includes > late attributes. You're right, my patch doesn't cure e.g.: // PR c++/35758 // { dg-do compile } #define vector __attribute__((vector_size(16))) template<typename T> vector signed int foo (vector T value) {} template<typename T> void foo (T value) {} int main () { vector float v; float f; foo<float> (v); foo<float> (f); } fn_type_unification calls: processing_template_decl += incomplete; fntype = tsubst (fntype, converted_args, tf_none, NULL_TREE); processing_template_decl -= incomplete; which doesn't apply late template attributes to either TREE_TYPE (fntype), nor TYPE_ARG_TYPES (fntype), because the attributes aren't actually TYPE_ATTRIBUTES on those types, but DECL_ATTRIBUTES on DECL_TEMPLATE_RESULT (fn) for the return type resp. individual DECL_ARGUMENTS (DECL_TEMPLATE_RESULT (fn)), and the attributes have type_required set, so they apply to the PARM_DECL types resp. result type. So, to make fn_type_unification work, I'm afraid we need something like - fntype = tsubst (fntype, converted_args, tf_none, NULL_TREE); + parms = tsubst (DECL_ARGUMENTS (DECL_TEMPLATE_RESULT (fn), converted_args, tf_none, NULL_TREE); + fntype_args = recreate_type_arg_types_from_parm_decl_types (parms, TREE_TYPE_ARGS (fntype)); + fntype_rettype = tsubst (TREE_TYPE (fntype), converted_args, tf_none, NULL_TREE); + apply_late_template_args (&fntype_rettype, DECL_ATTRIBUTES (DECL_TEMPLATE_RESULT (fn)), 0, converted_args, tf_none, NULL_TREE); and then use fntype_args instead of TYPE_ARG_TYPES (fntype) and fntype_rettype instead of TREE_TYPE (fntype) later on in the function. Plus I think something like recreate_type_arg_types_from_parm_decl_types would be needed for tsubst_decl as well, because from what I can see ATM TYPE_ARG_TYPES aren't being updated. Consider #define vector __attribute__((vector_size(16))) vector signed int p; template<typename T> struct S { vector signed int foo (vector T *value) { vector float *f = value; return p; } }; int main () { S<float> s; s.foo (__null); } where middle-end sees: <function_decl 0x2aaaaea7a410 foo type <method_type 0x2aaaaea876c0 type <vector_type 0x2aaaaea209c0 type <integer_type 0x2aaaae93b540 int> type_6 V4SI size <integer_cst 0x2aaaae928d80 constant invariant 128> unit size <integer_cst 0x2aaaae928db0 constant invariant 16> align 128 symtab 0 alias set -1 canonical type 0x2aaaaea209c0 nunits 4> QI size <integer_cst 0x2aaaae928780 constant invariant 8> unit size <integer_cst 0x2aaaae9287b0 constant invariant 1> align 8 symtab 0 alias set -1 canonical type 0x2aaaaea876c0 method basetype <record_type 0x2aaaaea83b40 S> arg-types <tree_list 0x2aaaaea84bd0 value <pointer_type 0x2aaaaea83d80> chain <tree_list 0x2aaaaea849f0 value <pointer_type 0x2aaaae94bd80> chain <tree_list 0x2aaaae9498a0 value <void_type 0x2aaaae94b840 void>>>> pointer_to_this <pointer_type 0x2aaaaea87840>> arguments <parm_decl 0x2aaaae92ec60 this ... chain <parm_decl 0x2aaaae92ecf0 value type <pointer_type 0x2aaaaea87300> ... where 0x2aaaaea87300 used in TREE_TYPE (TREE_CHAIN (DECL_ARGUMENTS (current_function_decl))) is: <pointer_type 0x2aaaaea87300 type <vector_type 0x2aaaaea203c0 type <real_type 0x2aaaae94bb40 float type_6 SF while 0x2aaaae94bd80 used as TREE_VALUE (TREE_CHAIN (TYPE_ARG_TYPES (TREE_TYPE (current_function_decl)))) is: <pointer_type 0x2aaaae94bd80 type <real_type 0x2aaaae94bb40 float type_6 SF Jakub ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [C++ PATCH] Fix vector_size handling in templates (PR c++/35758) 2008-04-01 14:37 [C++ PATCH] Fix vector_size handling in templates (PR c++/35758) Jakub Jelinek 2008-04-01 16:23 ` Mark Mitchell @ 2008-04-07 17:42 ` Jason Merrill 2008-04-08 10:18 ` Jakub Jelinek 2008-04-08 19:52 ` Mark Mitchell 1 sibling, 2 replies; 14+ messages in thread From: Jason Merrill @ 2008-04-07 17:42 UTC (permalink / raw) To: Jakub Jelinek; +Cc: Mark Mitchell, gcc-patches I believe this patch is appropriate and correct and fixes the regression, regardless of whether we also try to implement deduction for 'vector T'. If reconstruct_complex_type doesn't do the right thing for C++, this is the way to fix it. Jason ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [C++ PATCH] Fix vector_size handling in templates (PR c++/35758) 2008-04-07 17:42 ` Jason Merrill @ 2008-04-08 10:18 ` Jakub Jelinek 2008-04-08 10:34 ` Andrew Pinski 2008-04-08 19:52 ` Mark Mitchell 1 sibling, 1 reply; 14+ messages in thread From: Jakub Jelinek @ 2008-04-08 10:18 UTC (permalink / raw) To: Jason Merrill; +Cc: Mark Mitchell, gcc-patches On Mon, Apr 07, 2008 at 01:32:22PM -0400, Jason Merrill wrote: > I believe this patch is appropriate and correct and fixes the > regression, regardless of whether we also try to implement deduction for > 'vector T'. If reconstruct_complex_type doesn't do the right thing for > C++, this is the way to fix it. Here is an updated patch, which also changes rs6000 and spu reconstruct_complex_type calls to lang_hoos.types.reconstruct_complex_type (__altivec__ and __spu_vector__ attributes aren't late and I don't think the C++ FE should hardcode their names, so they have the same issues as vector_size before it was changed into an unconditionally late attribute). I believe this patch fixes the regression part of these problems, as gcc 4.2.x and earlier weren't allowing these attributes on type dependent decls. So ok for trunk/4.3? That said, even when not regression I think the remaining issues are serious wrong-code issues and so should be fixed even on 4.3. If the needed calls of apply_late_template_attributes for TYPE_ATTRIBUTES are added where needed in tsubst* (not sure exactly where, unfortunately), then a patch like http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35758#c15 could fix the non-deduction cases (e.g. when using explicit template args etc.), both for vector_size attribute, but also for the target specific altivec/spu_vector. The deduction for vector_size is perhaps possible, it is just a matter of checking that the template parameter has vector_size attribute and if it does, see whether the matching type is VECTOR_TYPE and deduce its TREE_TYPE. But altivec/spu_vector attributes will be much harder or impossible to deduce, given that they seem to throw away the original type and only use TYPE_MODE to find out what vector type to use. Furthermore, I wonder why e.g. the altivec attribute only uses the first letter of the attribute argument, so even __attribute((altivec (bar))) will be handled as __attribute((altivec (bool__))). 2008-04-08 Jakub Jelinek <jakub@redhat.com> PR c++/35758 * c-common.c (handle_vector_size_attribute): Call lang_hooks.types.reconstruct_complex_type instead of reconstruct_complex_type. * config/rs6000/rs6000.c (rs6000_handle_altivec_attribute): Likewise. * config/spu/spu.c (spu_handle_vector_attribute): Likewise. * langhooks.h (struct lang_hooks_for_types): Add reconstruct_complex_type hook. * langhooks-def.h (LANG_HOOKS_RECONSTRUCT_COMPLEX_TYPE): Define. (LANG_HOOKS_FOR_TYPES_INITIALIZER): Add it. * cp-tree.h (cp_reconstruct_complex_type): New prototype. * cp-objcp-common.h (LANG_HOOKS_RECONSTRUCT_COMPLEX_TYPE): Define. * decl2.c (is_late_template_attribute): Only make vector_size late tmpl attribute if argument is type or value dependent. (cp_reconstruct_complex_type): New function. * g++.dg/ext/vector14.C: New test. --- gcc/c-common.c.jj 2008-03-31 23:54:50.000000000 +0200 +++ gcc/c-common.c 2008-04-08 11:37:36.000000000 +0200 @@ -6104,7 +6104,7 @@ handle_vector_size_attribute (tree *node new_type = build_vector_type (type, nunits); /* Build back pointers if needed. */ - *node = reconstruct_complex_type (*node, new_type); + *node = lang_hooks.types.reconstruct_complex_type (*node, new_type); return NULL_TREE; } --- gcc/config/rs6000/rs6000.c.jj 2008-04-08 11:27:37.000000000 +0200 +++ gcc/config/rs6000/rs6000.c 2008-04-08 11:45:55.000000000 +0200 @@ -19743,7 +19743,7 @@ rs6000_handle_altivec_attribute (tree *n *no_add_attrs = true; /* No need to hang on to the attribute. */ if (result) - *node = reconstruct_complex_type (*node, result); + *node = lang_hooks.types.reconstruct_complex_type (*node, result); return NULL_TREE; } --- gcc/config/spu/spu.c.jj 2008-04-08 11:46:09.000000000 +0200 +++ gcc/config/spu/spu.c 2008-04-08 11:47:13.000000000 +0200 @@ -3022,7 +3022,7 @@ spu_handle_vector_attribute (tree * node if (!result) warning (0, "`%s' attribute ignored", IDENTIFIER_POINTER (name)); else - *node = reconstruct_complex_type (*node, result); + *node = lang_hooks.types.reconstruct_complex_type (*node, result); return NULL_TREE; } --- gcc/langhooks.h.jj 2008-04-07 10:42:57.000000000 +0200 +++ gcc/langhooks.h 2008-04-08 11:37:36.000000000 +0200 @@ -130,6 +130,12 @@ struct lang_hooks_for_types for the debugger about the array bounds, strides, etc. */ bool (*get_array_descr_info) (const_tree, struct array_descr_info *); + /* If we requested a pointer to a vector, build up the pointers that + we stripped off while looking for the inner type. Similarly for + return values from functions. The argument TYPE is the top of the + chain, and BOTTOM is the new type which we will point to. */ + tree (*reconstruct_complex_type) (tree, tree); + /* Nonzero if types that are identical are to be hashed so that only one copy is kept. If a language requires unique types for each user-specified type, such as Ada, this should be set to TRUE. */ --- gcc/langhooks-def.h.jj 2008-04-07 10:42:57.000000000 +0200 +++ gcc/langhooks-def.h 2008-04-08 11:37:36.000000000 +0200 @@ -167,6 +167,7 @@ extern tree lhd_make_node (enum tree_cod lhd_omp_firstprivatize_type_sizes #define LANG_HOOKS_TYPE_HASH_EQ NULL #define LANG_HOOKS_GET_ARRAY_DESCR_INFO NULL +#define LANG_HOOKS_RECONSTRUCT_COMPLEX_TYPE reconstruct_complex_type #define LANG_HOOKS_HASH_TYPES true #define LANG_HOOKS_FOR_TYPES_INITIALIZER { \ @@ -182,6 +183,7 @@ extern tree lhd_make_node (enum tree_cod LANG_HOOKS_OMP_FIRSTPRIVATIZE_TYPE_SIZES, \ LANG_HOOKS_TYPE_HASH_EQ, \ LANG_HOOKS_GET_ARRAY_DESCR_INFO, \ + LANG_HOOKS_RECONSTRUCT_COMPLEX_TYPE, \ LANG_HOOKS_HASH_TYPES \ } --- gcc/cp/cp-tree.h.jj 2008-04-07 10:42:55.000000000 +0200 +++ gcc/cp/cp-tree.h 2008-04-08 11:37:36.000000000 +0200 @@ -4282,6 +4282,7 @@ extern tree grokfield (const cp_declarat tree, bool, tree, tree); extern tree grokbitfield (const cp_declarator *, cp_decl_specifier_seq *, tree); +extern tree cp_reconstruct_complex_type (tree, tree); extern void cplus_decl_attributes (tree *, tree, int); extern void finish_anon_union (tree); extern void cp_write_global_declarations (void); --- gcc/cp/cp-objcp-common.h.jj 2008-04-07 10:42:55.000000000 +0200 +++ gcc/cp/cp-objcp-common.h 2008-04-08 11:37:36.000000000 +0200 @@ -125,6 +125,8 @@ extern tree objcp_tsubst_copy_and_build #define LANG_HOOKS_TYPE_PROMOTES_TO cxx_type_promotes_to #undef LANG_HOOKS_REGISTER_BUILTIN_TYPE #define LANG_HOOKS_REGISTER_BUILTIN_TYPE c_register_builtin_type +#undef LANG_HOOKS_RECONSTRUCT_COMPLEX_TYPE +#define LANG_HOOKS_RECONSTRUCT_COMPLEX_TYPE cp_reconstruct_complex_type #undef LANG_HOOKS_TO_TARGET_CHARSET #define LANG_HOOKS_TO_TARGET_CHARSET c_common_to_target_charset #undef LANG_HOOKS_GIMPLIFY_EXPR --- gcc/cp/decl2.c.jj 2008-03-25 23:31:25.000000000 +0100 +++ gcc/cp/decl2.c 2008-04-08 11:37:36.000000000 +0200 @@ -991,11 +991,8 @@ is_late_template_attribute (tree attr, t /* Unknown attribute. */ return false; - /* Attribute vector_size handling wants to dive into the back end array - building code, which breaks during template processing. */ - if (is_attribute_p ("vector_size", name) - /* Attribute weak handling wants to write out assembly right away. */ - || is_attribute_p ("weak", name)) + /* Attribute weak handling wants to write out assembly right away. */ + if (is_attribute_p ("weak", name)) return true; /* If any of the arguments are dependent expressions, we can't evaluate @@ -1120,6 +1117,62 @@ save_template_attributes (tree *attr_p, } } +/* Like reconstruct_complex_type, but handle also template trees. */ + +tree +cp_reconstruct_complex_type (tree type, tree bottom) +{ + tree inner, outer; + + if (TREE_CODE (type) == POINTER_TYPE) + { + inner = cp_reconstruct_complex_type (TREE_TYPE (type), bottom); + outer = build_pointer_type_for_mode (inner, TYPE_MODE (type), + TYPE_REF_CAN_ALIAS_ALL (type)); + } + else if (TREE_CODE (type) == REFERENCE_TYPE) + { + inner = cp_reconstruct_complex_type (TREE_TYPE (type), bottom); + outer = build_reference_type_for_mode (inner, TYPE_MODE (type), + TYPE_REF_CAN_ALIAS_ALL (type)); + } + else if (TREE_CODE (type) == ARRAY_TYPE) + { + inner = cp_reconstruct_complex_type (TREE_TYPE (type), bottom); + outer = build_cplus_array_type (inner, TYPE_DOMAIN (type)); + /* Don't call cp_build_qualified_type on ARRAY_TYPEs, the + element type qualification will be handled by the recursive + cp_reconstruct_complex_type call and cp_build_qualified_type + for ARRAY_TYPEs changes the element type. */ + return outer; + } + else if (TREE_CODE (type) == FUNCTION_TYPE) + { + inner = cp_reconstruct_complex_type (TREE_TYPE (type), bottom); + outer = build_function_type (inner, TYPE_ARG_TYPES (type)); + } + else if (TREE_CODE (type) == METHOD_TYPE) + { + inner = cp_reconstruct_complex_type (TREE_TYPE (type), bottom); + /* The build_method_type_directly() routine prepends 'this' to argument list, + so we must compensate by getting rid of it. */ + outer + = build_method_type_directly + (TREE_TYPE (TREE_VALUE (TYPE_ARG_TYPES (type))), + inner, + TREE_CHAIN (TYPE_ARG_TYPES (type))); + } + else if (TREE_CODE (type) == OFFSET_TYPE) + { + inner = cp_reconstruct_complex_type (TREE_TYPE (type), bottom); + outer = build_offset_type (TYPE_OFFSET_BASETYPE (type), inner); + } + else + return bottom; + + return cp_build_qualified_type (outer, TYPE_QUALS (type)); +} + /* Like decl_attributes, but handle C++ complexity. */ void --- gcc/testsuite/g++.dg/ext/vector14.C.jj 2008-04-08 11:37:36.000000000 +0200 +++ gcc/testsuite/g++.dg/ext/vector14.C 2008-04-08 11:37:36.000000000 +0200 @@ -0,0 +1,17 @@ +// PR c++/35758 +// { dg-do compile } + +#define vector __attribute__((vector_size(16))) + +template<int N> vector signed int foo (vector float value) {} + +template<int> void foo (float) {} + +int +main () +{ + vector float v; + float f; + foo<1> (v); + foo<1> (f); +} Jakub ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [C++ PATCH] Fix vector_size handling in templates (PR c++/35758) 2008-04-08 10:18 ` Jakub Jelinek @ 2008-04-08 10:34 ` Andrew Pinski 0 siblings, 0 replies; 14+ messages in thread From: Andrew Pinski @ 2008-04-08 10:34 UTC (permalink / raw) To: Jakub Jelinek; +Cc: Jason Merrill, Mark Mitchell, gcc-patches On Tue, Apr 8, 2008 at 3:09 AM, Jakub Jelinek <jakub@redhat.com> wrote: > * config/spu/spu.c (spu_handle_vector_attribute): Likewise. This part is ok, if the rest of the patch is approved. Thanks, Andrew Pinski ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [C++ PATCH] Fix vector_size handling in templates (PR c++/35758) 2008-04-07 17:42 ` Jason Merrill 2008-04-08 10:18 ` Jakub Jelinek @ 2008-04-08 19:52 ` Mark Mitchell 2008-04-09 13:13 ` Jakub Jelinek ` (2 more replies) 1 sibling, 3 replies; 14+ messages in thread From: Mark Mitchell @ 2008-04-08 19:52 UTC (permalink / raw) To: Jason Merrill; +Cc: Jakub Jelinek, gcc-patches Jason Merrill wrote: > I believe this patch is appropriate and correct and fixes the > regression, regardless of whether we also try to implement deduction for > 'vector T'. If reconstruct_complex_type doesn't do the right thing for > C++, this is the way to fix it. Yes, that's true. Then again, given that reconstruct_complex_type is documented as: /* HACK. GROSS. This is absolutely disgusting. perhaps we should try to figure out how not to need this? -- Mark Mitchell CodeSourcery mark@codesourcery.com (650) 331-3385 x713 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [C++ PATCH] Fix vector_size handling in templates (PR c++/35758) 2008-04-08 19:52 ` Mark Mitchell @ 2008-04-09 13:13 ` Jakub Jelinek 2008-04-10 16:53 ` Jason Merrill 2008-04-19 1:34 ` Jason Merrill 2008-04-23 15:34 ` Jason Merrill 2 siblings, 1 reply; 14+ messages in thread From: Jakub Jelinek @ 2008-04-09 13:13 UTC (permalink / raw) To: Mark Mitchell; +Cc: Jason Merrill, gcc-patches On Tue, Apr 08, 2008 at 12:30:11PM -0700, Mark Mitchell wrote: > Jason Merrill wrote: > >I believe this patch is appropriate and correct and fixes the > >regression, regardless of whether we also try to implement deduction for > >'vector T'. If reconstruct_complex_type doesn't do the right thing for > >C++, this is the way to fix it. > > Yes, that's true. Then again, given that reconstruct_complex_type is > documented as: > > /* HACK. GROSS. This is absolutely disgusting. > > perhaps we should try to figure out how not to need this? Do you have suggestions? I'm afraid we have our hands seriously tied by where we accept the vector_size attribute and what semantics it has. As there is already quite a lot of code using vector_size attribute in the wild, I'm afraid changing where we allow it won't fly, so I don't see how we can easily avoid the complex type reconstruction. Jakub ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [C++ PATCH] Fix vector_size handling in templates (PR c++/35758) 2008-04-09 13:13 ` Jakub Jelinek @ 2008-04-10 16:53 ` Jason Merrill 0 siblings, 0 replies; 14+ messages in thread From: Jason Merrill @ 2008-04-10 16:53 UTC (permalink / raw) To: Jakub Jelinek; +Cc: Mark Mitchell, gcc-patches Jakub Jelinek wrote: > I'm afraid we have our hands seriously tied by where we accept the vector_size > attribute and what semantics it has. As there is already quite a lot of > code using vector_size attribute in the wild, I'm afraid changing where we > allow it won't fly, so I don't see how we can easily avoid the complex type > reconstruction. Yes, attribute syntax/parsing is horrible. We really want attribute vector to work like a type-specifier, rather than a decl-specifier, so that we would apply it to the type early in grokdeclarator rather than waiting until cp_decl_attributes. I wonder how feasible that change would be. Jason ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [C++ PATCH] Fix vector_size handling in templates (PR c++/35758) 2008-04-08 19:52 ` Mark Mitchell 2008-04-09 13:13 ` Jakub Jelinek @ 2008-04-19 1:34 ` Jason Merrill 2008-04-23 15:34 ` Jason Merrill 2 siblings, 0 replies; 14+ messages in thread From: Jason Merrill @ 2008-04-19 1:34 UTC (permalink / raw) To: Mark Mitchell; +Cc: Jakub Jelinek, gcc-patches Mark Mitchell wrote: > Jason Merrill wrote: >> I believe this patch is appropriate and correct and fixes the >> regression, regardless of whether we also try to implement deduction >> for 'vector T'. If reconstruct_complex_type doesn't do the right >> thing for C++, this is the way to fix it. > > Yes, that's true. Then again, given that reconstruct_complex_type is > documented as: > > /* HACK. GROSS. This is absolutely disgusting. > > perhaps we should try to figure out how not to need this? Anyway, yes, but I'd still like to get this patch in to fix the important regression. Jason ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [C++ PATCH] Fix vector_size handling in templates (PR c++/35758) 2008-04-08 19:52 ` Mark Mitchell 2008-04-09 13:13 ` Jakub Jelinek 2008-04-19 1:34 ` Jason Merrill @ 2008-04-23 15:34 ` Jason Merrill 2008-04-24 8:59 ` Mark Mitchell 2 siblings, 1 reply; 14+ messages in thread From: Jason Merrill @ 2008-04-23 15:34 UTC (permalink / raw) To: Mark Mitchell; +Cc: Jakub Jelinek, gcc-patches Mark Mitchell wrote: > Jason Merrill wrote: >> I believe this patch is appropriate and correct and fixes the >> regression, regardless of whether we also try to implement deduction >> for 'vector T'. If reconstruct_complex_type doesn't do the right >> thing for C++, this is the way to fix it. > > Yes, that's true. Then again, given that reconstruct_complex_type is > documented as: > > /* HACK. GROSS. This is absolutely disgusting. > > perhaps we should try to figure out how not to need this? As Jakub wrote in the PR yesterday, 'Especially for 4.3.x getting rid of the "HACK. GROSS. This is absolutely disgusting." might not be something desirable for a stable branch. We've lived with this gross absolutely disgusting hack for more than 7 years, and the patch doesn't make the hack IMHO any more disgusting than it was till now, but fixes an important regression.' I agree with this. Finding a better way would be nice for 4.4, but trying to rewrite type attribute handling is inappropriate for 4.3. Jason ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [C++ PATCH] Fix vector_size handling in templates (PR c++/35758) 2008-04-23 15:34 ` Jason Merrill @ 2008-04-24 8:59 ` Mark Mitchell 0 siblings, 0 replies; 14+ messages in thread From: Mark Mitchell @ 2008-04-24 8:59 UTC (permalink / raw) To: Jason Merrill; +Cc: Jakub Jelinek, gcc-patches Jason Merrill wrote: >> /* HACK. GROSS. This is absolutely disgusting. >> >> perhaps we should try to figure out how not to need this? > > As Jakub wrote in the PR yesterday, > > 'Especially for 4.3.x getting rid of the "HACK. GROSS. This is > absolutely disgusting." might not be something desirable for a stable > branch. > > I agree with this. Finding a better way would be nice for 4.4, but > trying to rewrite type attribute handling is inappropriate for 4.3. I fully agree. -- Mark Mitchell CodeSourcery mark@codesourcery.com (650) 331-3385 x713 ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2008-04-24 3:04 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-04-01 14:37 [C++ PATCH] Fix vector_size handling in templates (PR c++/35758) Jakub Jelinek 2008-04-01 16:23 ` Mark Mitchell 2008-04-01 16:39 ` Andrew Pinski 2008-04-01 16:44 ` Mark Mitchell 2008-04-02 13:10 ` Jakub Jelinek 2008-04-07 17:42 ` Jason Merrill 2008-04-08 10:18 ` Jakub Jelinek 2008-04-08 10:34 ` Andrew Pinski 2008-04-08 19:52 ` Mark Mitchell 2008-04-09 13:13 ` Jakub Jelinek 2008-04-10 16:53 ` Jason Merrill 2008-04-19 1:34 ` Jason Merrill 2008-04-23 15:34 ` Jason Merrill 2008-04-24 8:59 ` Mark Mitchell
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).