From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-390418-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 21434 invoked by alias); 1 May 2012 22:27:42 -0000
Received: (qmail 21422 invoked by uid 22791); 1 May 2012 22:27:40 -0000
X-SWARE-Spam-Status: No, hits=-4.3 required=5.0	tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED
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, 01 May 2012 22:27:27 +0000
From: "davem at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/52684] [4.7 regression] glibc long double math tests fail on sparc 64-bit
Date: Tue, 01 May 2012 22:27: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: davem at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: davem at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.7.1
X-Bugzilla-Changed-Fields:
Message-ID: <bug-52684-4-Y0t3uqKAZK@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-52684-4@http.gcc.gnu.org/bugzilla/>
References: <bug-52684-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
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: 2012-05/txt/msg00036.txt.bz2

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

--- Comment #3 from davem at gcc dot gnu.org 2012-05-01 22:27:11 UTC ---
Sadly, the bug is even more severe.

Even something as simple as:

long double f(long double a, long double b)
{
   return a + b;
}

will be miscompiled with -O1 -ffloat-store on 64-bit.  The problem
is that the call instructions emitted lack the reg use notes so that
the compiler can see the stack frame inputs to the libcall.  Strangely,
the notes are created properly on 32-bit.

Then DSE thinks that the stack stores can be eliminated and proceeds
to kill those insns off.

Also, code generation is significantly better with -ffloat-store
enabled.  If you don't believe me, see for yourself.