public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Mark Mitchell <mark@codesourcery.com>, Jason Merrill <jason@redhat.com>
Cc: Andrew Pinski <pinskia@gmail.com>,
	        "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: Re: [C++ PATCH] Fix vector_size handling in templates (PR c++/35758)
Date: Wed, 02 Apr 2008 13:10:00 -0000	[thread overview]
Message-ID: <20080402130738.GV30807@devserv.devel.redhat.com> (raw)
In-Reply-To: <47F26645.1030706@codesourcery.com>

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

  reply	other threads:[~2008-04-02 13:10 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-01 14:37 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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080402130738.GV30807@devserv.devel.redhat.com \
    --to=jakub@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jason@redhat.com \
    --cc=mark@codesourcery.com \
    --cc=pinskia@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).