This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: is subreg with subreg_byte outside source valid?

>>>>> 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 {*} (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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]