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 19.33, Gabriel Dos Reis wrote:


Ziemowit Laski <zlaski@apple.com> writes:

| > | 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.


With the big caveat that I'm not an English native speaker, I've
however come across expressions like "Int list", "Float list"
(e.g. particularly in the Standard ML and derived communities), so I
would think that "int __vector__" sounds English as well.
A reason I'm not fan of "__vector int" is that it is easily mistaken
for "vector<int>" which is a different beast.

I'm not a native speaker, either :-); fortunately, we are dealing with C/C++ and _not_ English. :-) Not to mention the fact that the human-readable form I propose is consistent with how AltiVec types are actually written by users.

So, do you think I should add a target hook here? What do others think?


(Note too, that the C standard seems to establish the coding style covention of "T _Complex". In C++ however, it would be "_Complex T". Oh well).

I don't think that trying to squeeze AltiVec (or any other _existing_ vendor extension, for that matter) into a language standard is a worthwhile endeavor. :-) AltiVec is what it is, whatever its flaws. :-(

--Zem
--------------------------------------------------------------
Ziemowit Laski                 1 Infinite Loop, MS 301-2K
Mac OS X Compiler Group        Cupertino, CA USA  95014-2083
Apple Computer, Inc.           +1.408.974.6229  Fax .5477


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