This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: is subreg with subreg_byte outside source valid?
- To: Jan Hubicka <jh at suse dot cz>
- Subject: Re: is subreg with subreg_byte outside source valid?
- From: David Edelsohn <dje at watson dot ibm dot com>
- Date: Fri, 18 May 2001 17:40:04 -0400
- cc: gcc at gcc dot gnu dot org
>>>>> Jan Hubicka writes:
Jan> I've reorganized subreg simplification code and added some sanity checking.
Jan> The checking alarms on the subreg, as I believe it is not correct.
Jan> If you remove offending abort, the test may pass, but this is of course
Jan> not the way to go officially.
My initial reaction is agreement with you that the SUBREG cannot
be valid in the form you are seeing.
Jan> If you are familiar with the powerpc port, you may help me with the
Jan> last failure. I am getting crash on outputting insn:
Jan> (insn:TI 35 8 15 (set (reg:QI 9 r9)
Jan> (mem/s/u:QI (plus:SI (lo_sum:SI (reg/f:SI 9 r9 [84])
Jan> (symbol_ref:SI ("*.LC0")))
Jan> (const_int 1 [0x1])) 2)) 289 {*rs6000.md:7526} (insn_list 8 (nil))
Jan> (nil))
Jan> it looks like the mem expression is wrong. Do you have some idea what
Jan> goes wrong and how should look the correct expression? I don't have any
Jan> idea how my patch can introduce such a extraordinary crash so late in
Jan> the way, as all subregs disappear after reload and compiler should crash
Jan> if insn were invalid.
I am not as familiar with the SVR4 mode. What jumps out at me is
that PowerPC is a RISC architecture: loading a register from that many
operands cannot be valid. You've been working on Hammer code generation
for too long (:^). I would guess that there is something wrong with the
legitimate address code to allow a MEM like that to exist so late.
David