This is the mail archive of the gcc@gcc.gnu.org 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]
Other format: [Raw text]

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


Philip Pemberton <philpem@gmail.com> writes:

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

This means that it is taking an SImode slice out of a DImode value.


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

I don't know where the subreg is being created.  There are several
different ways to create one.

>   2) (assuming [1] isn't the problem) How do you handle a SUBREG in
> *_legitimate_address_p?

In *_legitimate_address_p you can usually do something along the lines
of 
  if (GET_CODE (x) == SUBREG)
    x = SUBREG_REG (x);

However, as I mentioned, this whole SUBREG is odd, so it's first
necessary to find out whether it should have been created at all.

Ian


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