This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: unrecognizable insn ICE in latticemico32 (lm32-elf) when building Linux kernel
- From: Ian Lance Taylor <iant at google dot com>
- To: Philip Pemberton <philpem at gmail dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Mon, 24 May 2010 22:06:59 -0700
- Subject: Re: unrecognizable insn ICE in latticemico32 (lm32-elf) when building Linux kernel
- References: <htf8cb$n2f$1@dough.gmane.org>
Philip Pemberton <philpem@gmail.com> writes:
> 1) Who's the current maintainer for the lm32 port? Jon Beniston?
> I can't see anything on the gcc website that says definitively "target
> X is maintained by $PERSON", and I really don't want to step on
> his/her toes and start a flame war, turf war or any other kind of war
> here...
The official list of maintainers is stored in the gcc source code in
the file MAINTAINERS. Having said that, there is no maintainer listed
for lm32. I assume that it must be, as you suggest, Jon Beniston.
> 2) What are these error messages telling me? Is there a "decoding ICE
> Error Messages HOWTO" for aspiring GCC developers?
That ICE is telling you that an RTL insn was generated for some reason
but there is no matching define_insn in the CPU MD file. In this case
it is an SImode move using a SUBREG.
The address is unusual:
(subreg:SI (mem/s:DI (plus:SI (reg/v/f:SI 39 [ ctx ])
(const_int 64 [0x40])) [0 S8 A64]) 4)
Why isn't that simply
(mem/s:SI (plus:SI (reg/v/f:SI 39 [ ctx ])
(const_int 68 [0x40])) [0 S8 A64])
That makes it look like something is creating a subreg without going
through simplify_gen_subreg.
It's also possible that the problem is simply that
lm32_legitimate_address_p needs to handle a SUBREG memory address.
> 3) I've established that the bug has been present in the lm32 port
> since it was merged into the mainline GCC source. What part of the gcc
> source should I start digging into first?
See above.
Ian