[C++ PATCH] bogus error using __real__ in a template instantiation

[scott snyder <snyder at fnal dot gov>]

hi -

This is relevant to gcc checked out from cvs as of about a week ago,
with the patches given in my previous messages:

  http://egcs.cygnus.com/ml/gcc-patches/1999-10/msg00824.html
  http://egcs.cygnus.com/ml/gcc-patches/1999-10/msg00825.html

[Without these patches, the compiler gives an ICE on the example given here.]
I'm using a i686-pc-linux-gnu platform.

For the following input:

------------------------------------------------------------------------
class c8
{
public:
  template <typename T> void bar (const T&);
  __complex__ double m;
};
    
template<typename T>
void c8::bar (const T&)
{
  __real__ m = 1;
}

typedef c8 Complex8;

void foo (  Complex8& x )
{ 
  x.bar (0);
}

------------------------------------------------------------------------

gcc gives the mysterious error:

$ cc1plus -quiet x.cc
x.cc: In method `void c8::bar (const T &) [with T = int]':
x.cc:18:   instantiated from here
x.cc:10: prior parameter's size depends on `c8 *this'


This error is generated from expand_expr in expr.c:

    case PARM_DECL:
      if (DECL_RTL (exp) == 0)
	{
	  error_with_decl (exp, "prior parameter's size depends on `%s'");
	  return CONST0_RTX (mode);
	}

      /* ... fall through ...  */


Since the error goes away if bar is turned into a non-template type,
my hypothesis was that when the template tree gets copied,
REALPART_EXPR's are not completely processed.

Indeed, in tsubst_copy in pt.c, i see in the big switch statement that
there are cases for other unary operators, but not for REALPART_EXPR
and IMAGPART_EXPR.  I tried simply adding these cases, treating them
like other unary ops:

--- pt.c-orig	Sun Oct 31 20:38:20 1999
+++ pt.c	Sun Oct 31 20:38:24 1999
@@ -6928,6 +6928,8 @@ tsubst_copy (t, args, complain, in_decl)
     case ARROW_EXPR:
     case THROW_EXPR:
     case TYPEID_EXPR:
+    case REALPART_EXPR:
+    case IMAGPART_EXPR:
       return build1
 	(code, tsubst (TREE_TYPE (t), args, complain, in_decl),
 	 tsubst_copy (TREE_OPERAND (t, 0), args, complain, in_decl));


With this change, the example compiles without error, and the generated
code appears reasonable.  I've further checked that it does not
change the results of the testsuite.


I ran into these problems in the first place while trying to test out
a recent snapshot of the new libstdc++, which uses these built-in complex
types to implement the std::complex classes.

sss