From gcc-patches-return-67141-listarch-gcc-patches=gcc dot gnu dot org at gcc dot gnu dot org Sat Aug 31 12:29:04 2002 Return-Path: Delivered-To: listarch-gcc-patches at gcc dot gnu dot org Received: (qmail 31966 invoked by alias); 31 Aug 2002 12:29:02 -0000 Mailing-List: contact gcc-patches-help at gcc dot gnu dot org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner at gcc dot gnu dot org Delivered-To: mailing list gcc-patches at gcc dot gnu dot org Received: (qmail 31959 invoked from network); 31 Aug 2002 12:29:01 -0000 Received: from unknown (HELO mta02ps.bigpond.com) (144.135.25.134) by sources dot redhat dot com with SMTP; 31 Aug 2002 12:29:01 -0000 Received: from bubble.local ([144.135.25.81]) by mta02ps dot bigpond dot com (Netscape Messaging Server 4 dot 15 mta02ps May 23 2002 23:53:28) with SMTP id H1PK0B00 dot DWS for ; Sat, 31 Aug 2002 22:28:59 +1000 Received: from CPE-144-136-184-138.sa.bigpond.net.au ([144.136.184.138]) by psmam05.mailsvc.email.bigpond.com(MailRouter V3.0n 107/11254735); 31 Aug 2002 22:28:59 Received: (qmail 23013 invoked by uid 179); 31 Aug 2002 12:28:59 -0000 Date: Sat, 31 Aug 2002 21:58:59 +0930 From: Alan Modra To: gcc-patches at gcc dot gnu dot org Subject: Fix a reload problem on powerpc64-linux Message-ID: <20020831215859.D18764@bubble.sa.bigpond.net.au> Mail-Followup-To: gcc-patches at gcc dot gnu dot org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Is this a reasonable thing to do? * reload.c (find_reloads

): Pass operand_mode to find_reloads_address. Index: gcc/reload.c =================================================================== RCS file: /cvs/gcc/gcc/gcc/reload.c,v retrieving revision 1.178.2.4 diff -u -p -r1.178.2.4 reload.c --- gcc/reload.c 13 Jun 2002 16:08:12 -0000 1.178.2.4 +++ gcc/reload.c 31 Aug 2002 11:44:03 -0000 @@ -2643,7 +2643,7 @@ find_reloads (insn, replace, ind_levels, ; else if (constraints[i][0] == 'p') { - find_reloads_address (VOIDmode, (rtx*) 0, + find_reloads_address (recog_data.operand_mode[i], (rtx*) 0, recog_data.operand[i], recog_data.operand_loc[i], i, operand_type[i], ind_levels, insn); The background to the patch is that the builtin-prefetch-2.c test has been failing lately like this: GNU C version 3.2.1 20020830 (prerelease) (powerpc64-linux) compiled by GNU C version 2.95.4 20011006 (Debian prerelease). Program received signal SIGSEGV, Segmentation fault. 0x10264278 in build_def_use (bb=0x103b3660) at /src/gcc-3.2/gcc/regrename.c:803 (gdb) p debug_rtx (insn) (insn 341 335 565 (prefetch (plus:DI (reg/f:DI 1 r1) (const_int 520 [0x208])) (const_int 0 [0x0]) (const_int 0 [0x0])) 530 {prefetch} (nil) (nil)) OK, so we got a stack slot, which isn't valid for this particular insn. A little debugging reveals that the constrain_operands call a few lines earlier is failing (it really should have an abort), because: - the rs6000 prefetch insn has operand[0] as V4SImode, with a 'p' constraint - strict_memory_address_p calls rs6000_legitimate_address - rs6000.h:LEGITIMATE_OFFSET_ADDRESS_P tests ALTIVEC_VECTOR_MODE (MODE) which is true for V4SImode, false for VOIDmode, and only allows a zero offset for V4SImode. This insn should have been fixed earlier by reload, but since VOIDmode was passed down to find_reloads_address, the call to strict_memory_address_p there returned true, convincing reload that the address was OK. Hence the patch. But I won't be at all surprised to be told I don't know what I'm doing. -- Alan Modra IBM OzLabs - Linux Technology Centre