From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 78994 invoked by alias); 5 Feb 2020 09:52:29 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 78984 invoked by uid 89); 5 Feb 2020 09:52:28 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.2 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.1 spammy=Liu, liu, Edward, edward X-HELO: mail-wm1-f67.google.com Received: from mail-wm1-f67.google.com (HELO mail-wm1-f67.google.com) (209.85.128.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 05 Feb 2020 09:52:27 +0000 Received: by mail-wm1-f67.google.com with SMTP id p9so1697439wmc.2 for ; Wed, 05 Feb 2020 01:52:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=j8KEJqdIrO0hi7ySf96vQwX9ppJqXMlZ104zXRtLUe0=; b=o5gQHUdahS4tm/+zNit6PZXa9zbH3q3PnIVRlWUw6KGgtXpOc1fLrBcyzL0PflcvRG ysCwTHtznHyAwvLlggPViH95MzkuaJ1fYTkR//37t3J2UtLPIU8/U8Z6GYCAAa1jyqy+ s0Ti7kd4pNC4NDdHuByIS+v2GVu6M+bYm2qgdFCKRcyW45pa8yDwyQHjlXqPYg4fAlmO fxhoukzB/+tZYeRjnoSPOT69TvjYpYzmGeeJ1gX9fv1eANmtXs4oZBqE6RQIZXitmEoS MX5h/4ihbxql+j9HN+hJNY8h+08BaPeJP7Xzguj0uBNfBep75S+2Sg+k8HqQNC7CXxta zyaQ== MIME-Version: 1.0 References: <29e08084.e493.17006075515.Coremail.lh_mouse@126.com> In-Reply-To: From: Jonathan Wakely Date: Wed, 05 Feb 2020 09:52:00 -0000 Message-ID: Subject: Re: Function attributes and x32, x64 To: Liu Hao Cc: Edward Diener , gcc-help Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2020-02/txt/msg00038.txt.bz2 On Wed, 5 Feb 2020 at 03:31, Liu Hao wrote: > > =E5=9C=A8 2020/2/4 =E4=B8=8A=E5=8D=882:37, Edward Diener =E5=86=99=E9=81= =93: > > On 2/2/2020 8:11 AM, Liu Hao wrote: > >> =E5=9C=A8 2020/2/1 =E4=B8=8B=E5=8D=887:06, Edward Diener =E5=86=99=E9= =81=93: > >>> 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 =E2=80=98int main()=E2=80=99: > test.cc:5:65: warning: =E2=80=98__stdcall__=E2=80=99 attribute only appli= es to function > types [-Wattributes] > using atype =3D 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 >