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

John McCall rjmccall at apple.com
Tue Oct 26 16:47:45 PDT 2010


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.

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.

Similar, if callback_t is __attribute__((cdecl)), then instance methods declared with that typedef (which is legal!) should be called with cdecl.

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.

But I'm open to argument.

John.



More information about the cfe-dev mailing list