From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25756 invoked by alias); 4 Mar 2002 23:22:02 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 25592 invoked from network); 4 Mar 2002 23:21:50 -0000 Received: from unknown (HELO ftpbox.mot.com) (129.188.136.101) by sources.redhat.com with SMTP; 4 Mar 2002 23:21:50 -0000 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id QAA19248 for ; Mon, 4 Mar 2002 16:21:50 -0700 (MST)] Received: [from mail.wm.sps.mot.com ([199.10.246.2]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id QAA26489 for ; Mon, 4 Mar 2002 16:21:49 -0700 (MST)] Received: from hyper.wm.sps.mot.com (hyper.wm.sps.mot.com [199.10.246.43]) by mail.wm.sps.mot.com (8.9.3/8.9.3) with ESMTP id SAA08475 for ; Mon, 4 Mar 2002 18:21:41 -0500 Received: by hyper.wm.sps.mot.com (8.11.2) id g24NLmA28354; Mon, 4 Mar 2002 18:21:48 -0500 Date: Mon, 04 Mar 2002 15:22:00 -0000 Message-Id: <200203042321.g24NLmA28354@hyper.wm.sps.mot.com> From: Peter Barada To: gcc@gcc.gnu.org Subject: Re: PR #5753 X-SW-Source: 2002-03/txt/msg00124.txt.bz2 I've reported a PR (see #5753) while compiling some code from a m68k-elf configured 3.0.4 compiler for -m5200. I'm attempting to figure out a fix. The compiler reports: m68k-elf-gcc -fno-exceptions -S -gstabs -malign-int -Wall -Wno-format -m5200 /tmp/cfprintf4.c -o /tmp/cfprintf4.s -da /tmp/cfprintf4.c: In function `_vformat': /tmp/cfprintf4.c:58: Insn does not satisfy its constraints: (insn 258 38 185 (set (reg:QI 8 %a0) (mem/f:QI (plus:SI (reg/f:SI 14 %a6) (const_int -1 [0xffffffff])) 0)) 37 {*m68k.md:1060} (nil) (nil)) /tmp/cfprintf4.c:58: Internal compiler error in final_scan_insn, at final.c:2876 Which indicates that it is trying to load a QImode from memory and into an address register which the 68k architecture allows, but the ColdFire architecture rejects. I've tried to modify HARD_REGNO_MODE_OK to be: /* Value is 1 if hard register REGNO can hold a value of machine-mode MODE. On the 68000, the cpu registers can hold any mode but the 68881 registers can hold only SFmode or DFmode. On ColdFire, no instruction exists to move bytes into or out of the address registers. */ #define HARD_REGNO_MODE_OK(REGNO, MODE) \ ((TARGET_5200 && ((REGNO) >= 8 && (REGNO) < 16) \ && GET_MODE_SIZE (MODE) == 1) ? 0 : \ (((REGNO) < 16 \ && !((REGNO) < 8 && (REGNO) + GET_MODE_SIZE (MODE) / 4 > 8)) \ || ((REGNO) >= 16 && (REGNO) < 24 \ && (GET_MODE_CLASS (MODE) == MODE_FLOAT \ || GET_MODE_CLASS (MODE) == MODE_COMPLEX_FLOAT) \ && GET_MODE_UNIT_SIZE (MODE) <= 12))) This rejects placing bytes into address registers, and I can successfully build a compiler, but when I try this code again I get: /tmp/crap-304-new/bin/m68k-elf-gcc -c -gstabs -malign-int -m5200 /tmp/cfprintf4.c -o /tmp/cfprintf4.o /tmp/cfprintf4.c: In function `_vformat': /tmp/cfprintf4.c:58: Unable to find a register to spill in class `ADDR_REGS'. /tmp/cfprintf4.c:58: This is the insn: (insn 185 184 186 (set (reg:SI 68) (plus:SI (subreg:SI (mem/f:QI (plus:SI (reg/f:SI 14 %a6) (const_int -1 [0xffffffff])) 0) 0) (const_int -100 [0xffffff9c]))) 100 {*addsi3_5200} (nil) (nil)) /tmp/cfprintf4.c:58: confused by earlier errors, bailing out 1) Is limiting HARD_REGNO_MODE_OK() correct in this case? While debugging this, I find its failing because find_reg is returning a zero. At the start of the second loop in find_reg (the one that tests each of the bits in not_usable), the values of the various bitstrings is: Breakpoint 8, find_reg (chain=0x82dd164, order=1) at /home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-304/gcc/reload1.c:1701 (gdb) p/x bad_spill_regs $20 = 0xffc000 (gdb) p/x bad_spill_regs_global $21 = 0x4000 (gdb) p/x reg_class_contents[rl->class] $22 = 0xff00 (gdb) p rl->class $23 = ADDR_REGS (gdb) p/x not_usable $24 = 0xffffc0ff (gdb) p rl->mode $25 = QImode (gdb) p/x used_by_other_reload $26 = 0x0 And it fails since the only registers available int not_usable are the address registers a0 through a5(zero bits 8..13). Apparently all the data registers are taken due to the inverse of reg_class_contents. Now the next question is why is the class ADDR_REGS while the mode is QImode? 2) How can rl->mode be QImode while the class is ADDR_REGS. 3) Any ideas where I should look from here? -- Peter Barada Peter.Barada@motorola.com Wizard 781-852-2768 (direct) WaveMark Solutions(wholly owned by Motorola) 781-270-0193 (fax)