Re: unrecognizable insn ICE in latticemico32 (lm32-elf) when building Linux kernel

[Philip Pemberton <philpem at gmail dot com>]

On 25/05/10 06:06, Ian Lance Taylor wrote:
> 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.

Yeah, I spotted that in SVN about five minutes after I posted ;)
Funny how you spot things in websvn that get missed when you're just 
'ls'-ing the source tree...

> 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])

Let me see if I understand this right...

It's using an SImode (machine-native size, 32 bit) subreg over a DImode 
(DWORD, 64bit) address of a 32-bit addition operation? That can't be 
right...

What's interesting is that this happens on a variable initialisation 
statement... although maybe I shouldn't be assuming the SLoC-number part 
of the ICE error is accurate...

> 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.

The questions raised by that would be:
  1) Where is the subreg being created? (or: "how can a subreg be 
created?" -- then grep the lm32 source for the answer(s) to that question)
  2) (assuming [1] isn't the problem) How do you handle a SUBREG in 
*_legitimate_address_p?


Thanks,
Phil.