From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11828 invoked by alias); 18 Dec 2006 21:17:24 -0000 Received: (qmail 10585 invoked by uid 48); 18 Dec 2006 21:16:59 -0000 Date: Mon, 18 Dec 2006 21:17:00 -0000 Message-ID: <20061218211659.10584.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug target/30255] register spills in x87 unit need to be 80-bit, not 64 In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "whaley at cs dot utsa dot edu" 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: 2006-12/txt/msg01557.txt.bz2 ------- Comment #3 from whaley at cs dot utsa dot edu 2006-12-18 21:16 ------- BTW, in case it isn't obvious, here's the fix that I typically use for problems like bug 323 that I cannot when it is gcc itself that is unpredictably spilling the computation: void test(double x, double y) { const double y2 = x + 1.0; volatile double v[2]; v[0] = y2; v[1] = y; if (v[0] != v[1]) printf("error\n"); } The idea being that the volatile keyword prevents gcc from getting rid of the store/load cycle, which forces the round-down. This allows me to still do this kind of comparison, w/o the speed loss of associated with -ffloat-store (the compare itself becomes slow due to the store/load, but the body of the code runs as fast as normal), or the loss of precision associated with always rounding to 64 bit, as when you change the x87 control word. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30255