Re: Function attributes and x32, x64

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 5 Feb 2020 at 03:31, Liu Hao <lh_mouse@xxxxxxx> wrote:
>
> 在 2020/2/4 上午2:37, Edward Diener 写道:
> > On 2/2/2020 8:11 AM, Liu Hao wrote:
> >> 在 2020/2/1 下午7:06, Edward Diener 写道:
> >>> Given the code:
> >>>
> >>> class cbase;
> >>> int main()
> >>>     {
> >>>     typedef int __attribute__ ((__stdcall__)) (cbase::* atype)();
> >>>     typedef int __attribute__ ((__cdecl__)) (cbase::* btype)();
> >>>     typedef int __attribute__ ((__fastcall__)) (cbase::* ctype)();
> >>>     typedef int __attribute__ ((__thiscall__)) (cbase::* dtype)();
> >>>     return 0;
> >>>     }
> >>>
>
> > This does not make sense to me as the compiler seems to be objecting to
> > just having different pointer to member function types with different
> > calling conventions for the same class, as if all member functions for a
> > class must have the same calling conventions. Does gcc not allow
> > different calling conventions for different member functions of a class,
> > and, if so, where is this documented ?
> >
> >
>
> If I substitute the first typedef with an equivalent(?)
> using-declaration then I get a warning:
>
> ```
> test.cc: In function ‘int main()’:
> test.cc:5:65: warning: ‘__stdcall__’ attribute only applies to function
> types [-Wattributes]
>      using atype = int __attribute__ ((__stdcall__)) (cbase::* )();
> ```
>
> It looks to me that in the typedef case, the stdcall attribute attaches
> to the `int`, not the (indirect) function type.

I think that's correct. The attribute grammar is confusing, but it
does apply to the return type as used above, and that's obviously
meaningless since 'int' has no calling convention.

> So long as GCC parses it
> as such, this eliminates the warning:
>
> ```
> typedef int ( __attribute__ ((__stdcall__ ))  cbase::* atype)();
> //          ^_______parenthesis_moved_______/
> ```
>
> The mangled names of these two types (which can be examined using
> `typeid(___).name`) don't differ, so I presume it is kind of a bug in
> intermediate representation.
>
>
> --
> Best regards,
> LH_Mouse
>




[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux