public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [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).