From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 1251B385840E; Mon, 3 Jan 2022 15:37:24 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1251B385840E From: "puetzk at puetzk dot org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/95222] [10/11 Regression] GCC 10.1 x86 issue with function pointers with calling convention attribute and template specialization Date: Mon, 03 Jan 2022 15:37:24 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 10.1.0 X-Bugzilla-Keywords: rejects-valid X-Bugzilla-Severity: normal X-Bugzilla-Who: puetzk at puetzk dot org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: jason at gcc dot gnu.org X-Bugzilla-Target-Milestone: 10.2 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2022 15:37:25 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D95222 Kevin Puetz changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |puetzk at puetzk dot org --- Comment #8 from Kevin Puetz --- This bug can also manifest as wrong-code, e.g. >>>>>>>>>>>>>>> template struct func_ptr_t; template struct func_ptr_t { using type =3D void(*)(T); }; template struct func_ptr_t { #if 1 using type =3D void(__attribute__((__stdcall__))*)(T); #else using type =3D void(__attribute__((__stdcall__))*)(int); // this wo= rks, using T is important somehow #endif }; #if 1 using foo_stdcall_ptr =3D func_ptr_t::type; using foo_cdecl_ptr =3D func_ptr_t::type; #else using foo_stdcall_ptr =3D void(__attribute__((__stdcall__))*)(int,i= nt); using foo_cdecl_ptr =3D void(*)(int,int); #endif foo_stdcall_ptr foo_stdcall; foo_cdecl_ptr foo_cdecl; void bar_stdcall() { foo_stdcall(1); } void bar_cdecl() { foo_cdecl(1); } >>>>>>>>>>>>>>> Should compile so that the bar_stdcall versions pops fewer bytes off the st= ack (as foo_stdcall already cleaned up its own arguments). >>>>>>>>>>>>>>> --- bar_cdecl.S 2021-03-09 00:54:58.404022904 +0000 +++ bar_stdcall.S 2021-03-09 00:52:07.900015002 +0000 @@ -1,15 +1,15 @@ -: +: 0: f3 0f 1e fb endbr32=20 4: 55 push %ebp 5: 89 e5 mov %esp,%ebp 7: 83 ec 08 sub $0x8,%esp - a: e8 fc ff ff ff call 32 + a: e8 fc ff ff ff call b f: 05 01 00 00 00 add $0x1,%eax 14: 8b 80 00 00 00 00 mov 0x0(%eax),%eax 1a: 83 ec 0c sub $0xc,%esp 1d: 6a 01 push $0x1 1f: ff d0 call *%eax - 21: 83 c4 10 add $0x10,%esp + 21: 83 c4 0c add $0xc,%esp 24: 90 nop 25: c9 leave=20=20 26: c3 ret=20=20=20=20 >>>>>>>>>>>>>>> But doesn't in 9.4, 10.0, and 10.1 (seems to be fixed again in 10.2+, presumably per this fix). I mention this only because I finally found this relevant PR, and perhaps knowing it might affect decisions about which bran= ches should get fixed - e.g. 9.x is in stage 4 but this is a 9.3.0->9.4.0 regres= sion (presumably PR090750), and also wrong-code. But we were able to work around= it, and so I'm not directly arguing for (or against) a backport to=20 Ubuntu 20.04 compiler **is** affected despite claiming to be 9.3.0 - Ubuntu= has seemingly backported the gcc 9 branch through 4ad02cfb768 (git-updates.patc= h in gcc-9_9.3.0-17ubuntu1~20.04.debian.tar.xz). But I'll raise that separately = in their bug tracker.=