From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20515 invoked by alias); 5 Nov 2008 18:29:16 -0000 Received: (qmail 20470 invoked by uid 22791); 5 Nov 2008 18:29:15 -0000 X-Spam-Check-By: sourceware.org Received: from miranda.se.axis.com (HELO miranda.se.axis.com) (193.13.178.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 05 Nov 2008 18:28:38 +0000 Received: from ignucius.se.axis.com (ignucius.se.axis.com [10.13.11.50]) by miranda.se.axis.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id mA5ISvSW025939; Wed, 5 Nov 2008 19:28:57 +0100 Received: from ignucius.se.axis.com (localhost [127.0.0.1]) by ignucius.se.axis.com (8.12.8p1/8.12.8/Debian-2woody1) with ESMTP id mA5ISYJ9021787; Wed, 5 Nov 2008 19:28:34 +0100 Received: (from hp@localhost) by ignucius.se.axis.com (8.12.8p1/8.12.8/Debian-2woody1) id mA5ISYJe021783; Wed, 5 Nov 2008 19:28:34 +0100 Date: Wed, 05 Nov 2008 18:29:00 -0000 Message-Id: <200811051828.mA5ISYJe021783@ignucius.se.axis.com> From: Hans-Peter Nilsson To: gcc-patches@gcc.gnu.org Subject: Committed: fix for PR38016 -fno-ivopts exposes CRIS port bug MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2008-11/txt/msg00182.txt.bz2 Not so much a new bug as the fix for PR25947 being incomplete. This was exposed by local patch, that I consider committing here too for OPTIMIZATION_OPTIONS (but properly commenting the cause for each, to enable simple re-testing and removal): Index: cris.h =================================================================== --- cris.h (revision 22658) +++ cris.h (working copy) @@ -335,6 +335,9 @@ extern int target_flags; { \ if ((OPTIMIZE) >= 2 || (SIZE)) \ flag_omit_frame_pointer = 1; \ + flag_gcse = 0; \ + flag_ivopts = 0; \ + flag_tree_reassoc = 0; \ } \ while (0) My benchmarks say those passes don't do any good on average for CRIS. I'd be interesting to hear what -fno-tree-reassoc does for peoples benchmarks as it seems what good it does is negated by far by the higher register pressure for all architectures, see PR37916. I understand this testsuite change is preferred to adding a special reduced version of fp-cmp-8 (whether in the generic parts or gcc.target/cris) or extending TORTURE_OPTIONS with -fno-ivopts (and/or -fno-gcse). Only the former option is needed to expose the bug, but the latter makes the test fail for more iterations. (Actually, -fno-gcse exposes a bug too, PR38026.) Yes, gcc.c-torture/execute/ieee still needs .x files, it doesn't understand dg- annotations. Tested cross to cris-axis-elf on trunk and 4.3 branch, committed to both. gcc: PR target/38016 * config/cris/cris.c (cris_order_for_addsi3): Test for !REG_P, not just MEM_P. gcc/testsuite: PR target/38016 * gcc.c-torture/execute/ieee/pr38016.c, gcc.c-torture/execute/ieee/pr38016.c: New test. Index: gcc.c-torture/execute/ieee/pr38016.c =================================================================== --- gcc.c-torture/execute/ieee/pr38016.c (revision 0) +++ gcc.c-torture/execute/ieee/pr38016.c (revision 0) @@ -0,0 +1 @@ +#include "fp-cmp-8.c" Index: gcc.c-torture/execute/ieee/pr38016.x =================================================================== --- gcc.c-torture/execute/ieee/pr38016.x (revision 0) +++ gcc.c-torture/execute/ieee/pr38016.x (revision 0) @@ -0,0 +1,2 @@ +lappend additional_flags "-fno-ivopts" "-fno-gcse" +return 0 Index: config/cris/cris.c =================================================================== --- config/cris/cris.c (revision 141613) +++ config/cris/cris.c (working copy) @@ -3565,14 +3565,15 @@ cris_expand_pic_call_address (rtx *opp) } /* Make sure operands are in the right order for an addsi3 insn as - generated by a define_split. A MEM as the first operand isn't - recognized by addsi3 after reload. OPERANDS contains the operands, - with the first at OPERANDS[N] and the second at OPERANDS[N+1]. */ + generated by a define_split. Nothing but REG_P as the first + operand is recognized by addsi3 after reload. OPERANDS contains + the operands, with the first at OPERANDS[N] and the second at + OPERANDS[N+1]. */ void cris_order_for_addsi3 (rtx *operands, int n) { - if (MEM_P (operands[n])) + if (!REG_P (operands[n])) { rtx tem = operands[n]; operands[n] = operands[n + 1]; brgds, H-P