On May 25, 2010, at 1:34 PM, Douglas Gregor wrote:
On May 25, 2010, at 1:33 PM, John McCall wrote:
On May 25, 2010, at 12:56 PM, Douglas Gregor wrote:
On May 25, 2010, at 12:54 PM, Charles Davis wrote:
On 5/25/10 11:18 AM, John McCall wrote:
On May 24, 2010, at 10:43 PM, Charles Davis wrote:
This is the first patch in my GSoC series, in which I will
factor out
C++ ABI support in IRgen so that we can support other C++ ABIs.
This
patch is very simple. It just adds a class hierarchy similar to
the one
for Objective-C runtimes, and a basic implementation for the
current GNU
C++ ABI. All it supports is name mangling. CodeGenFunction has
been
redirected to use this new interface instead of holding the
MangleContext itself (which is very specific to the GNU ABI
right now).
For better or worse, people call this the Itanium ABI; gcc's
implementation hews
faithfully to that standard, and we should use that name. The
term "GNU ABI" is likely
to make people think of the old (pre-v3.2) gcc ABI.
Noted.
Also, I think we can live without the "CG" prefix on "CGCXXABI".
Done. (The header name still has the CG prefix, though.)
I'd prefer to avoid lazy initialization. We should never be
calling into the
CXXABI for non-C++ code, so you should be able to create it
during initialization
if CPlusPlus is set and then assert on its existence in
getCXXABI().
I don't know about that.
When I added the assert, clang started asserting whenever it was
generating IR for non-C++ (that's C and ObjC) code. I think clang
right
now just assumes that the MangleContext is always available and
will "Do
the Right Thing" based on whether or not Features.CPlusPlus is set.
I agree, C and ObjC IRgen shouldn't be calling into any C++-
specific
stuff. But I'll fix that later.
We use the "C++" mangler for some things in C/Objective-C as well,
including blocks (a recent change), overloaded functions in C, and
(IIRC) some Objective-C method names.
Ah, right, I'd forgotten about that. So yeah, we should continue
to lazily create the C++ ABI.
I suppose it's reasonable to always defer these manglings to the
target C++ ABI. Maybe we can abstract out some common
functionality so that new ABIs don't need so many redundant
manglings.
Yes, I think that makes sense. Separating ObjC from C++ might be
reasonable, for example.
ObjC does not do any C++ style mangling (ObjC's type encoding is in
ASTContext.cpp). Blocks are part of all languages. There might be
some ObjC specific code
added inadvertently though which should be moved out.
- Fariborz
- Doug
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
