This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]