[cfe-dev] RFC: Flesh out the IRGen C++ ABI class

[Charles Davis]

On 10/26/10 5:51 PM, Douglas Gregor wrote:
> 
> On Oct 26, 2010, at 4:47 PM, John McCall wrote:
> 
>> On Oct 26, 2010, at 4:09 PM, Charles Davis wrote:
>>> On 10/25/10 10:28 PM, John McCall wrote:
>>>> My inclination is to say that "canonicalizing" the function type is the wrong thing to do, and that the default CC for a function in any particular context should be determined by that context.  That means that a default-CC function type is different from a specifically-cdecl function type, but I can live with that.
>>> So you're saying we should get rid of getCanonicalCallConv()? Then I can
>>> dispense with the AST hook, too.
>>>
>>> I don't know about this. The whole point of canonicalizing the CC was
>>> that cdecl function types were compatible with default-CC function
>>> types. This matters when, e.g., trying to merge two compatible
>>> declarations, or assigning function pointers. Are you sure you can live
>>> with it now?
>>
>> There's already explicit function-merging logic that deals with CCs.
Yeah, and it uses getCanonicalCallConv().
>>
>> The problem is that a function type with no explicit CC really is different in important ways from a function type with an explicit CC.  In particular, if I have
>>  typedef void callback_t(A*);
>> then this:
>>  callback_t B::*cb = ...;  (b->*cb)(a);
>> uses the default calling convention for instance methods, whereas this:
>>  callback_t *f; f(a);
>> uses the default calling convention for normal functions.
That's why, when getCanonicalCallConv() is called, it needs to know if
it's dealing with a method instead of a normal function.
>>
>> Similar, if callback_t is __attribute__((cdecl)), then instance methods declared with that typedef (which is legal!) should be called with cdecl.
Hmm... This complicates things.
>>
>> The point is that function types exist independent of any particular declaring context, and the right rule is to fill in a sensible calling convention based on context when none was mandated.  If that means that we have to produce different template instantiations for __attribute__((cdecl)) functions than unadorned ones, I can live with that.
> 
> 
> I think we have to live with the fact that we produce different template instantiations for __attribute__((cdecl)) functions than unadorned ones. I haven't looked into what GCC does, but different name-mangling for cdecl, fastcall, etc. function types makes perfect sense. 
Last I checked, the Itanium ABI didn't mangle calling conventions at all ;).

I tried just now to gut getCanonicalCallConv(), and a bunch of tests
started failing horribly. (By that, I mean *crash* horrible.) I don't
think it's worth removing this function. There must be another way.

Chip