https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95222
Kevin Puetz <puetzk at puetzk dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |puetzk at puetzk dot org
--- Comment #8 from Kevin Puetz <puetzk at puetzk dot org> ---
This bug can also manifest as wrong-code, e.g.
>>>>>>>>>>>>>>>
template<bool bIsStdcall, typename T> struct func_ptr_t;
template<typename T> struct func_ptr_t<false,T> {
using type = void(*)(T);
};
template<typename T> struct func_ptr_t<true,T> {
#if 1
using type = void(__attribute__((__stdcall__))*)(T);
#else
using type = void(__attribute__((__stdcall__))*)(int); // this works,
using T is important somehow
#endif
};
#if 1
using foo_stdcall_ptr = func_ptr_t<true,int>::type;
using foo_cdecl_ptr = func_ptr_t<false,int>::type;
#else
using foo_stdcall_ptr = void(__attribute__((__stdcall__))*)(int,int);
using foo_cdecl_ptr = 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 stack
(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 @@
-<bar_cdecl()>:
+<bar_stdcall()>:
0: f3 0f 1e fb endbr32
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 <bar_cdecl()+0xb>
+ a: e8 fc ff ff ff call b <bar_stdcall()+0xb>
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
26: c3 ret
>>>>>>>>>>>>>>>
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 branches
should get fixed - e.g. 9.x is in stage 4 but this is a 9.3.0->9.4.0 regression
(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
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.patch in
gcc-9_9.3.0-17ubuntu1~20.04.debian.tar.xz). But I'll raise that separately in
their bug tracker.
