public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: snyder@fnal.gov To: gcc-gnats@gcc.gnu.org Subject: c++/2781: bad code generated for reference call with -O2 (regression from 2.95) Date: Tue, 08 May 2001 17:06:00 -0000 [thread overview] Message-ID: <200105090005.f49059W03433@karma.fnal.gov> (raw) >Number: 2781 >Category: c++ >Synopsis: bad code generated for reference call with -O2 (regression from 2.95) >Confidential: no >Severity: serious >Priority: medium >Responsible: unassigned >State: open >Class: wrong-code >Submitter-Id: net >Arrival-Date: Tue May 08 17:06:01 PDT 2001 >Closed-Date: >Last-Modified: >Originator: scott snyder >Release: 3.0 20010507 (prerelease) >Organization: >Environment: System: Linux karma 2.2.16-22 #1 Tue Aug 22 16:49:06 EDT 2000 i686 unknown Architecture: i686 host: i686-pc-linux-gnu build: i686-pc-linux-gnu target: i686-pc-linux-gnu configured with: ../egcs/configure --prefix=/usr/local/egcs --enable-threads=posix --enable-long-long >Description: g++ miscompiles the program below if -O2 is used. I expect it to print 2.00000; what it actually prints is 1.00000. I get the correct behavior if i compile without -O2. (gcc 2.95 also behaves correctly, so this is a regression.) $ g++ -O2 -o x x.cc $ ./x 1.000000 $ g++ -o x x.cc $ ./x 2.000000 $ Here is the relevant extract of the assembly output: .globl _ZN12PSurfXYPlaneC2Ed .type _ZN12PSurfXYPlaneC2Ed,@function _ZN12PSurfXYPlaneC2Ed: .LFB1: pushl %ebp .LCFI0: movl %esp, %ebp .LCFI1: pushl %esi .LCFI2: pushl %ebx .LCFI3: subl $28, %esp .LCFI4: leal -24(%ebp), %eax movl 16(%ebp), %esi movl 12(%ebp), %ebx pushl %eax movl %esi, -20(%ebp) movl %ebx, -24(%ebp) .LCFI5: call _Z5xswapRd leal -8(%ebp), %esp movl %ebx, xxx popl %ebx movl %esi, xxx+4 popl %esi popl %ebp ret We start by loading v1 into registers. To make the call to xswap, v1 is saved to memory, and we pass a reference to that. However, after returning from xswap, we continue to use the value of v1 contained in registers, rather than reading the (modified) value back to memory. Are we erroneously making the call using a temporary? I also observe that the problem goes away if i change the function being compiled to an ordinary member instead of a ctor. If i compile with -fno-optimize-sibling-calls, then the problem is evident in the .00.rtl dump, so it's not a backend problem. >How-To-Repeat: struct PSurfXYPlane { PSurfXYPlane(double v1); }; void xswap(double& x1) ; double xxx = 0; PSurfXYPlane::PSurfXYPlane(double v1) { xswap(v1); xxx = v1; } void xswap (double& x1) { x1 = 2; } extern "C" void printf (...); int main () { PSurfXYPlane p (1); printf ("%lf\n", xxx); return 0; } >Fix: >Release-Note: >Audit-Trail: >Unformatted:
reply other threads:[~2001-05-08 17:06 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=200105090005.f49059W03433@karma.fnal.gov \ --to=snyder@fnal.gov \ --cc=gcc-gnats@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).