Bug: arm-linux-gcc 3.3.6 compiled with iwmmxt support

[Daniel Santos <daniel at bytesage dot com>]

Ok, let me try this again.  I was subscribed from a different address 
then I attempted to send it from.. and nothing happened.

So, compile the attached code with -O2 or -O3 and compiler goes boom.  
I'm using ezx-crosstool-0.5 (http://lsb.blogdns.net/ezx-devkit), which 
is gcc-3.3.6 /w glibc-2.3.2 and a collection of patches.  I sometimes 
pick my nose in public when I think nobody is looking.  gcc-3.3.6 is 
built with the options "--with-cpu=iwmmxt 
--enable-cxx-flags=-mcpu=iwmmxt --with-float=soft" and I'm running on 
Cygwin.  It's my understanding that this problem occurs on Linux as 
well, but I haven't had that confirmed yet.

   *$ /opt/ezx-crosstool-0.5-iwmmxt/bin/arm-linux-gcc -O2 -o boom boom.c*
   boom.c: In function `func1':
   boom.c:27: error: unable to find a register to spill in class `LO_REGS'
   boom.c:27: error: this is the insn:
   (insn:HI 73 86 75 3 0x18dd0360 (set (reg/v:DI 5 r5 [57])
           (ashift:DI (reg/v:DI 5 r5 [57])
               (subreg:SI (reg/v:DI 41 wr10 [56]) 0))) 450
   {ashldi3_iwmmxt} (insn_list 47 (insn_list 45 (nil)))
       (expr_list:REG_DEAD (reg/v:DI 41 wr10 [56])
           (expr_list:REG_EQUAL (ashift:DI (const_int 1 [0x1])
                   (subreg:SI (reg/v:DI 41 wr10 [56]) 0))
               (nil))))
   boom.c:27: confused by earlier errors, bailing out
   *$ /opt/ezx-crosstool-0.5-iwmmxt/bin/arm-linux-gcc --version
   *


If I compile with -O0, -O1 or -Os it works fine.  Also, I rebuilt my 
toolkit with the gcc options "--with-float=soft" (i.e., excluding the 
iwmmxt support) and it also compiles at any optimization level with that 
toolkit.  The attached code is the smallest I could get it and still 
reproduce the error.  Also included are -S output from each of the 5 
different optimization levels and with both compilers (i.e., with and 
without iwmmxt support).

Unfortunately, I don't have the smarts to troubleshoot compiler problems 
like that, and the last assembly I've used was for the 6502.  Please let 
me know if there's anything else I can supply to help troubleshoot this 
problem or if I should be reporting this to somebody else.  Also, if 
anybody can confirm that this occurs on Linux as well, that would be 
helpful.

Thanks,
Daniel
PS:  I'm not actually doing GUI right now, so this isn't effecting me 
personally.
--

dd if=/dev/zero of=/ram/awsomeswap bs=1024 count=16384
mkswap -v0 /ram/awsomeswap 16384
/bin/sync
/sbin/swapon /ram/awsomeswap

Attachment: boom.tar.gz
Description: application/gzip

--
For unsubscribe information see http://sourceware.org/lists.html#faq