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. John. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
