From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 371DF385E02F; Tue, 10 Aug 2021 07:02:18 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 371DF385E02F From: "marxin at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug ipa/101839] New: [9/10/11/12 Regression] Hand in C++ code with -fdevirtualize Date: Tue, 10 Aug 2021 07:02:17 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: ipa X-Bugzilla-Version: 12.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: marxin at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status keywords bug_severity priority component assigned_to reporter cc target_milestone Message-ID: 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: Tue, 10 Aug 2021 07:02:18 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D101839 Bug ID: 101839 Summary: [9/10/11/12 Regression] Hand in C++ code with -fdevirtualize Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- Reported by leon zadorin via email: The following produces hanged application (busy-polling by what appears to = be calling self-method in a loop indefinitely) when, essentially, "-fdevirtual= ize" is brought into play (albeit with other options possibly). The reproduction was achieved on Linux: gcc version 9.2.1 20191008 (Ubuntu 9.2.1-9ubuntu2), x86_64-linux-gnu and Windows: gcc version 11.1.0 (GCC), x86_64-w64-mingw32 Code compiled as: c++ -O3 -fprofile-generate ./devirtualize.cpp Whilst consistently reproducible ("done writing" is never printed out), the buggy behavior is rather strange and any of the following would change/"fix" the situation: Taking out the anonymous namespace; Marking BA::type() as non-final; Taking out std::map from CA; Adding -fno-devirtualize flag to GCC compilation flags. Note: taking out -fprofile-generate from GCC compilation flags results in different busy-print loop (potentially followed by segfault) i.e. different, yet still buggy behaviour. The repro code could be simplified even further (e.g. by taking out Buf cla= ss, reducing number of calls to 'add', etc) and still reproduce in gcc-9.2 on Linux. However on gcc-11.1 on Windows it would then no longer reproduce. So I've left the following code in its current state so as to hopefully ind= uce more consistent reproduction across different versions. Here it is, devirtualize.cpp (also attached): #include #include #include namespace { struct Buf { char * buf; int a{0}; int b{0}; Buf(char * b) : buf(b) { } void add(int v) { ::memcpy(buf, &v, sizeof(v)); a +=3D sizeof(v); b +=3D sizeof(v); } }; struct A { virtual void fill(Buf &buf) { buf.add(type()); buf.add(type()); } virtual ~A() {} virtual int type() =3D 0; }; struct BA : A { void fill(Buf &buf) { A::fill(buf); buf.add(type()); buf.add(type()); } int type() final { return 1; } }; struct CBA final : BA { }; struct CA final : A { ::std::map m; int type() final { return 2; } }; } int main(int argc, char ** ) { char d[1024]; CBA cba; ::std::cerr << "writing \n"; ::std::cerr.flush(); Buf buf(d); cba.fill(buf); ::std::cerr << "done writing \n"; ::std::cerr.flush(); CA ca; } Richi replied: The issue also reproduces with GCC 7.5 (on Leap 15.3), -O -fprofile-generate -fdevirtualize is enough to trigger it there. Confirmed also with GCC 9, 10, 11 and trunk and those options. We hang in Program received signal SIGINT, Interrupt. 0x00000000004017d5 in (anonymous namespace)::A::fill (buf=3D...,=20 this=3D) at t.C:16 16 buf.add(type()); Missing separate debuginfos, use: zypper install=20 libgcc_s1-debuginfo-10.3.0+git1587-1.6.4.x86_64=20 libstdc++6-debuginfo-10.3.0+git1587-1.6.4.x86_64 (gdb) bt #0 0x00000000004017d5 in (anonymous namespace)::A::fill (buf=3D...,=20 this=3D) at t.C:16 #1 (anonymous namespace)::BA::fill (this=3Dthis@entry=3D0x7fffffffde08,=20 buf=3D...) at t.C:24 #2 0x0000000000401860 in main (argc=3D) at t.C:46 (gdb) s=20=20=20=20=20=20=20=20 (anonymous namespace)::BA::fill (this=3Dthis@entry=3D0x7fffffffde08, buf=3D= ...) at t.C:24 24 A::fill(buf); (gdb) s (anonymous namespace)::A::fill (buf=3D..., this=3D0x7fffffffddd8) at t.C:15 15 virtual void fill(Buf &buf) { (gdb) s 16 buf.add(type()); (gdb) s (anonymous namespace)::BA::fill (this=3Dthis@entry=3D0x7fffffffde08, buf=3D= ...) at t.C:24 24 A::fill(buf); (gdb) s (anonymous namespace)::A::fill (buf=3D..., this=3D0x7fffffffddd8) at t.C:15 15 virtual void fill(Buf &buf) { (gdb) s 16 buf.add(type()); there is one thing that I'm not sure is allowed. You do: struct A { virtual void fill(Buf &buf) { buf.add(type()); buf.add(type()); } virtual ~A() {} virtual int type() =3D 0; }; struct BA : A { void fill(Buf &buf) { A::fill(buf); buf.add(type()); buf.add(type()); } thus override virtual A::fill with non-virtual BA::fill. But this might be where the devirtualization code (or the indirect call/devirt profiling code?) is confused.=