This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: New hook for custom-mangling of C++ scalars
On 21 Mar 2004, at 17.48, Gabriel Dos Reis wrote:
Ziemowit Laski <zlaski@apple.com> writes:
| I have mixed feelings here. While I agree that it's good to point
out
| that these extended scalar types must follow the C++ ABI mangling
| rules for vendor extensions, I don't quite see why it is necessary
| to narrowly define these types as 'new fundamental types' or
| 'qualified versions of ordinary fundamental types'. Actually, I'm
not
| even certain that the AltiVec extended scalar types meet either of
| these definitions. :-( For example, is 'bool int' really a qualified
| version of an ordinary fundamental type?
As far as C and C++ are concerned, the answer is clearly no.
Now, I would think that your use of __bool is like "unsigned" that
instructs the compiler that you would want to treat that int as a
packet of bits. And in that regard, I would join Zack's view that
it acts like a fundamental type. Since that combination is not
standard, it is a new one.
Ok, so perhaps we should strike the 'qualified versions of ordinary
fundamental types' from the description. I guess my misgivings here
are not necessarily that Zack's description is incorrect, but that it
is unnecessary. :-) We are, after all, dealing with _vendor_
extensions,
so just saying 'vendor beware' should be enough. But I'll be happily
overruled here; it is, after all, just documentation. :-)
| Moreover, these four AltiVec
| "types" cannot be used on their own, but only as vector elements.
Yes, that is a *semantic restriction* on their uses. Just like when
you get a void*, you can't apply the unary operator '*' on it.
Yes, you're right.
| Anyhoo, I'll incorporate your prose (most of which I agree with) into
| the next version of my patch, and we can iterate from there.
|
| (Come to think of it, we should do something about the
_pretty-printing_
| of these types. Currently, error messages refer to nonsensical
things
| like '__bool int __vector__' and '__bool short __vector__'. I'll
whip
| up a separate patch.)
What do you think would make sense? I'm asking because I'm working
currently in that area.
'__vector', followed by the element type (e.g., '__vector __bool int',
'__vector __bool short'); at least this is what AltiVec requires. If
other targets (e.g., MMX) require other human-readable forms, then we
would need another hook.
Thanks,
--Zem