[Bug c++/11078] [ABI] ICE in write_type with typeof and templates

["ian at wasabisystems dot com" <gcc-bugzilla@gcc.gnu.org>]

------- Additional Comments From ian at wasabisystems dot com  2004-08-03 20:57 -------
It would be nice to be able to use something as simple as v16typeof, or
v17typeofe/v17typeoft, but it is not.  The problem is that typeof can introduce
expressions in cases where the mangling ABI does not permit them.  Consider the
test case in this PR:

template <class T1, class T2>
typeof(T1() + T2()) add(T1 a, T2 b) { return a+b; }
static double foo = add(3.1, 'c');

When mangling add<double, char>(double, char), we need to mangle the return
type.  The mangling ABI requires this to be a <type>.  If we are going to mangle
this using typeof, then we need to be able to use an <expression> in a <type>. 
But the mangling ABI does not provide any mechanism for that.

However, I note that we don't actually have to use typeof when mangling this
name.  When the compiler sees the template arguments, it can always resolve the
typeof down to a basic type.  Would it be reasonable to address the issue in
that way?

In fact, in general the compiler can resolve typeof.  In what cases will it not
be able to?

If there a case in which the compiler can not resolve typeof, I think we should
use the vendor extended operator syntax.  Separating typeoft and typeofe doesn't
actually work, because the parameter to typeof may itself be an expression
involving types.  What we need is a way to express a <type> as an
<expr-primary>.  Since typeof only cares about the types of its arguments, I
think we can get away with representing a type using the existing L <type>
<value> E syntax, and always using the value "0".

But I think we need some examples.  My current guess is that the example in this
PR should not require us to mangle typeof.  Any thoughts on this?

If it does require us to mangle typeof, then we need to decide how to express
typeof in a <type>, which will require an ABI extension.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11078