From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-351672-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 28979 invoked by alias); 29 Mar 2011 12:10:48 -0000
Received: (qmail 28968 invoked by uid 22791); 29 Mar 2011 12:10:46 -0000
X-SWARE-Spam-Status: No, hits=-2.9 required=5.0	tests=ALL_TRUSTED,AWL,BAYES_00
X-Spam-Check-By: sourceware.org
Received: from localhost (HELO gcc.gnu.org) (127.0.0.1)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 29 Mar 2011 12:10:43 +0000
From: "zsojka at seznam dot cz" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/48331] [4.7 Regression] gcc.c-torture/execute/built-in-setjmp.c FAILs with -O -fira-algorithm=priority -fPIC
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: zsojka at seznam dot cz
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:
Message-ID: <bug-48331-4-hCyDDhaJaX@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-48331-4@http.gcc.gnu.org/bugzilla/>
References: <bug-48331-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
Date: Tue, 29 Mar 2011 12:54:00 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
X-SW-Source: 2011-03/txt/msg02985.txt.bz2

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48331

--- Comment #1 from Zdenek Sojka <zsojka at seznam dot cz> 2011-03-29 12:10:38 UTC ---
The "while (1)" part of the testcase is not actually needed.

The problem seems to be there (at the assembly level):
...
    mov    rax, QWORD PTR buf@GOTPCREL[rip]    #,
    mov    rax, QWORD PTR 8[rax]    #,
    mov    QWORD PTR -8[rbp], rax    # %sfp, # stores value
    mov    rax, QWORD PTR buf@GOTPCREL[rip]    #,
    mov    rbp, QWORD PTR [rax]    #, # rbp changes
    mov    rsp, QWORD PTR 16[rax]    #,
    jmp    [QWORD PTR -8[rbp]]    # %sfp # uses new value or rbp
...

Maybe this was just uncovered by recent changes - comparing asm output from
r171626 and r171653 shows the priority allocator now gives much worse results.

In r171626, the generated code is the same as with CB's allocator, but in
r171653 there is much higher stack usage, causing this problem to show up.