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

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

[Philip Pemberton]

Hi guys,
About a month ago I opened a bug on Bugzilla:
   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43805

This relates to gcc crashing out with an Internal Compiler Error when 
doing a build of Linux kernel 2.6.34-rc4. Basically, as soon as the 
build hits fs/timerfd.c, an ICE is thrown:

fs/timerfd.c: In function ‘timerfd_poll’:
fs/timerfd.c:105:1: error: unrecognizable insn:
(insn 44 43 45 5 fs/timerfd.c:94 (set (reg:SI 68)
         (subreg:SI (mem/s:DI (plus:SI (reg/v/f:SI 39 [ ctx ])
                     (const_int 64 [0x40])) [0 S8 A64]) 4)) -1 (nil))
fs/timerfd.c:105:1: internal compiler error: in extract_insn, at 
recog.c:2103
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

Compiling without -O2 allows the build to get a little further, but it 
falls over on mm/filemap.c:

mm/filemap.c: In function ‘do_generic_file_read’:
mm/filemap.c:1171:1: error: unrecognizable insn:
(insn 402 401 403 20 mm/filemap.c:1029 (set (reg:SI 389)
         (subreg:SI (mem/c/i:DI (plus:SI (reg/f:SI 33 virtual-stack-vars)
                     (const_int -52 [0xffffffffffffffcc])) [0 isize+0 S8 
A64])
4)) -1 (nil))
mm/filemap.c:1171:1: internal compiler error: in extract_insn, at 
recog.c:2103

The full details are in the bug report, along with the compiler command 
line, .i file and preprocessed source. Seeing as it's been over a month 
and nothing seems to have happened with the bug, I'd like to have a go 
at fixing it myself...

I have a couple of questions:

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

2) What are these error messages telling me? Is there a "decoding ICE 
Error Messages HOWTO" for aspiring GCC developers?

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?

I guess ultimately I'm just asking for a few starting points from the 
gurus here... :)

Thanks,
Phil.

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

[Ian Lance Taylor]

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

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

[Philip Pemberton]

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.

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

[Ian Lance Taylor]

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