Re: Is fastcall broken?

[Daniel Lohmann <daniel dot lohmann at informatik dot uni-erlangen dot de>]

Andrew Haley schrieb:
> Daniel Lohmann writes:
>  > Angus schrieb:
>  > > 
>  > >    BTW, in my opinion it is dangerous. Usually one can rely on
>  > > compile or link errors to catch mismatched function
>  > > characteristics, but with attributes there is no such
>  > > checking. So even if you aren't doing something *really*
>  > > dangerous, like working with virtual methods, you might do what I
>  > > did, and you'll never know about it until you notice you've
>  > > mismatched your attributes. So if you ask me, attributes like
>  > > this one should be used sparingly, and with much caution.
>  > 
>  > I would consider this as a significant defect of gcc's attribute handling. 
>  > Attributes that change a function to a non-standard calling convention 
>  > effectively modify the interface of the function, which should be encoded 
>  > into the (mangled) symbol name. Thereby incompatible prototypes on on the 
>  > caller and callee side could be detected at link-time.
>
> But attributes such as fastcall are used in C programs, and C doesn't
> do mangling.  

But in this cases it should! As soon as we use the fastcall (or interrupt 
or interrupt_handler or ...) attribute, we already have left the safe haven 
of the C ABI for an inherently incompatible compiler-specific extensions. 
Pretending nevertheless compatibility to the standard ABI at link time is 
just insane.

> I don't know that many people combine C++ and weirdo
> attributes like fastcall.  

You would be surprised. C++ is facing an immense popularity gain in the 
embedded systems community. And these people (I am one of them...) often 
need a much finer control over code generation.

This may also explain the increasing requests for #pragma support in gcc. I 
know, the gcc guys favor attributes - which are a great thing, indeed. 
However, IMHO attributes and pragmas, despite the fact that they *can* be 
used to achieve the same effects, are completely orthogonal concepts. 
Actually, we need them both. But I suppose this issue has already been 
discussed too many times.

> Otherwise it's not such a bad idea, but it
> is an ABI change: such changes, being non-backwards compatible, are
> usually unpopular.

For good reasons. But maybe in gcc 5...

Daniel