From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32199 invoked by alias); 12 Dec 2002 20:28:51 -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 32114 invoked from network); 12 Dec 2002 20:28:46 -0000 Received: from unknown (HELO nikam.ms.mff.cuni.cz) (195.113.18.106) by sources.redhat.com with SMTP; 12 Dec 2002 20:28:46 -0000 Received: from camelot.ms.mff.cuni.cz (kampanus.ms.mff.cuni.cz [195.113.18.107]) by nikam.ms.mff.cuni.cz (Postfix) with SMTP id 5E26A4DDF1; Thu, 12 Dec 2002 21:28:47 +0100 (CET) Received: by camelot.ms.mff.cuni.cz (sSMTP sendmail emulation); Thu, 12 Dec 2002 21:28:44 +0100 Date: Thu, 12 Dec 2002 12:44:00 -0000 From: Jan Hubicka To: Peter Barada Cc: Peter.Barada@motorola.com, rth@redhat.com, gcc@gcc.gnu.org Subject: Re: Saga of m68k PIC continues Message-ID: <20021212202844.GJ15490@kam.mff.cuni.cz> References: <200212112045.gBBKjnQ13223@hyper.wm.sps.mot.com> <20021211235940.GF6975@redhat.com> <200212120011.gBC0B5W08189@hyper.wm.sps.mot.com> <200212122025.gBCKPd819055@hyper.wm.sps.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200212122025.gBCKPd819055@hyper.wm.sps.mot.com> User-Agent: Mutt/1.3.28i X-SW-Source: 2002-12/txt/msg00659.txt.bz2 > > > > >> 2) If not, does anyone have an idea how I should get this instruction > >> recognized? > > > >You *may* want to wrap the unspec in a CONST. That would > >make the thing be recognized by general_operand. But I > >can't tell if that's exactly right, since you've posted > >no code. > > Using the extremely simple test program: > > extern int foo; > void z(void) > { > foo = 1; > } > > Compiled with -fPIC -O2 -S, I get: > > z: > link.w %a6,#0 > move.l %a5,-(%sp) > lea (%pc, _GLOBAL_OFFSET_TABLE_@GOTPC), %a5 > lea foo,%a0 > moveq.l #1,%d0 > move.l %d0,(%a0) > move.l (%sp)+,%a5 > unlk %a6 > rts > > Looks like the -fPIC stuff failed and completely due to something > betwwen zz.c.03.jump and zz.c.08.cse converting the (const (uspec:SI > [...] 3)) into (uspec:SI [...] 3). > > >From the debug output, I see the following: > > >From zz.c.00.rtl I see: > > (note 2 0 3 NOTE_INSN_DELETED) > > (note 3 2 4 NOTE_INSN_FUNCTION_BEG) > > (note 4 3 5 NOTE_INSN_DELETED) > > (note 5 4 6 NOTE_INSN_DELETED) > > (note 6 5 9 NOTE_INSN_DELETED) > > (insn 9 6 11 (set (reg:SI 30) > (const:SI (unspec:SI[ > (symbol_ref:SI ("foo")) > ] 3))) -1 (nil) > (expr_list:REG_EQUAL (const:SI (unspec:SI[ > (symbol_ref:SI ("foo")) > ] 3)) > (nil))) > > (insn 11 9 13 (set (reg/f:SI 29) > (mem/u:SI (plus:SI (reg:SI 13 %a5) > (reg:SI 30)) [0 S4 A8])) -1 (nil) > (expr_list:REG_EQUAL (symbol_ref:SI ("foo")) > (nil))) > > (insn 13 11 14 (set (mem/f:SI (reg/f:SI 29) [2 foo+0 S4 A16]) > (const_int 1 [0x1])) -1 (nil) > (nil)) > > (note 14 13 16 NOTE_INSN_FUNCTION_END) > > > Which looks the same in zz.c.03.jump. From zz.c.08.cse I see: > > (note 2 0 3 NOTE_INSN_DELETED) > > (note 3 2 17 NOTE_INSN_FUNCTION_BEG) > > (note 17 3 11 [bb 0] NOTE_INSN_BASIC_BLOCK) > > (insn 11 17 13 (set (reg/f:SI 29) > (symbol_ref:SI ("foo"))) 29 {*m68k.md:1011} (nil) > (expr_list:REG_EQUAL (symbol_ref:SI ("foo")) > (nil))) > > (insn 13 11 14 (set (mem/f:SI (reg/f:SI 29) [2 foo+0 S4 A16]) > (const_int 1 [0x1])) 29 {*m68k.md:1011} (nil) > (nil)) > > > Note the removal of the (const ... ) in insn 11. > > Any ideas where this is being stripped off? GCC will happily put in the subreg when your machine description accept it. There are hooks defining valid addresses and constants and these must refuse invalid stuff, like (symbol_ref:SI ("foo") is for PIC. Honza > > -- > Peter Barada Peter.Barada@motorola.com > Wizard 781-852-2768 (direct) > WaveMark Solutions(wholly owned by Motorola) 781-270-0193 (fax)