From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16279 invoked by alias); 27 Mar 2006 01:41:49 -0000 Received: (qmail 16256 invoked by uid 48); 27 Mar 2006 01:41:45 -0000 Date: Mon, 27 Mar 2006 01:41:00 -0000 Message-ID: <20060327014145.16255.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug target/26459] [4.1/4.2 Regression] gcc fails to build on powerpc e500-double targets In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "amodra at bigpond dot net dot au" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2006-03/txt/msg02607.txt.bz2 List-Id: ------- Comment #19 from amodra at bigpond dot net dot au 2006-03-27 01:41 ------- After applying the patch, I decided I really ought to find where the regression from 4.0 occurred. It's a pity I didn't do that before developing the patch.. To my surprise I found that on the face of it, 4.0 ought to have the same problem, because it has exactly the same peephole. A debug session revealed that 4.0 doesn't think that (subreg:DF (reg:DI 3 3 [128]) 0) is a valid gpc_reg_operand for e500 double target, while 4.1 does. After some head-scratching, I discovered the reason for this is the TARGET_IEEEQUAD change to rs6000.h:CANNOT_CHANGE_MODE_CLASS (well, really, it's the change to use IBM extended double for powerpc-linux targets). The first few lines of this macro are: #define CANNOT_CHANGE_MODE_CLASS(FROM, TO, CLASS) \ (!TARGET_IEEEQUAD \ && GET_MODE_SIZE (FROM) >= 8 && GET_MODE_SIZE (TO) >= 8 \ ? 0 \ This of course interacts badly with later TARGET_E500_DOUBLE tests for DFmode and DImode, because now that TARGET_IEEEQUAD is false for linuxspe, we never get to make the TARGET_E500_DOUBLE checks. At the minimum, the TARGET_E500_DOUBLE checks ought to be done before this test allows a zero return. These lines were added here PR target/11848 * rs6000.h (CANNOT_CHANGE_MODE_CLASS): Allow change of mode in floating-point registers between TFmode and DImode. Really, I think it would be better to check for TFmode<->DImode explicitly rather than the rather obscure check that Geoff added. We have quite a few modes that have size greater than eight. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26459