From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31157 invoked by alias); 11 Nov 2012 14:30:33 -0000 Received: (qmail 31098 invoked by uid 48); 11 Nov 2012 14:30:17 -0000 From: "mikpe at it dot uu.se" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/55171] incorrect virtual thunk on mingw Date: Sun, 11 Nov 2012 14:30:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: mikpe at it dot uu.se X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: CC Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-11/txt/msg00936.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55171 Mikael Pettersson changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mikpe at it dot uu.se --- Comment #5 from Mikael Pettersson 2012-11-11 14:30:14 UTC --- It's caused by "[patch i386]: Set for method-functions default calling-convention to thiscall for 32-bit msabi" in r171890: http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00066.html http://gcc.gnu.org/ml/gcc-cvs/2011-04/msg00082.html With x86_64-w64-mingw32-g++ -m32 -O2 there are numerous code generation differences in r171890 for this test case (as expected with the changed calling convention), but looking only at the virtual thunk we see: --- pr55171.s-r171889 2012-11-11 14:51:38.000000000 +0100 +++ pr55171.s-r171890 2012-11-11 15:00:58.000000000 +0100 ... __ZTv0_n16_NK7Derived3fooEv: - movl 8(%esp), %eax - movl (%eax), %ecx - addl -16(%ecx), %eax - movl %eax, 8(%esp) + movl 4(%esp), %eax + movl (%eax), %eax + addl -16(%eax), %eax + movl %eax, 4(%esp) jmp LTHUNK2 ... The two code sequences are clearly not equivalent (ignore the stack position of the pointer being adjusted). Running the test case confirms: with g++ @ r171889 it succeeds, but with g++ @ r171890 it gets a runtime failure.