This is the mail archive of the
mailing list for the GCC project.
Re: PATCH: New hook for custom-mangling of C++ scalars
Ziemowit Laski <firstname.lastname@example.org> 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.
| 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.
| 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.