gcc coldfire code generation problem

[Greg Ungerer <gerg at snapgear dot com>]

Hi All,

I have found a problem with the code generation of gcc under some
circumstances when targeted to produce Motorola ColdFire code.

I am using gcc-3.1.1, configured as target=m68k-elf. The host is a
Linux x86 PC - although I don't think this has any effect on the problem.

This problem occurs on older gcc versions too. I get the same result
with gcc-2.95.3.

gcc -v:

   Reading specs from /usr/local/lib/gcc-lib/m68k-elf/3.1.1/specs
   Configured with: ../configure --target=m68k-elf --with-gnu-ld
--with-gnu-as : (reconfigured) ../configure --target=m68k-elf
--with-gnu-ld --with-gnu-as --enable-languages=c
   Thread model: single
   gcc version 3.1.1

When I compile the ramdisk driver (rd.c) from the Linux kernel sources
I get the following error:

   rd.s: Assembler messages:
   rd.s:50: Error: operands mismatch -- statement `move.l
(%a0,%d2.l*4),52(%a1)' ignored

This is not a valid ColdFire addressing mode.

The original C code line that caused this is:

   rd_bdev[unit]->bd_inode->i_size = rd_length[unit];

By reorganizing the code on this line I can get this to compile
with no errors. For example if I change it too:

   rd_bdev[unit]->bd_inode->i_size = ((volatile unsigned long *)
rd_length)[unit];

The gcc command line I use to reproduce the problem is:

   m68k-elf-gcc --save-temps -fno-builtin -nostdinc -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
-fno-strict-aliasing -fno-common -m5200 -Wa,-S -Wa,-m5200 -nostdinc -c
-o rd.o rd.i

You can get a sample file that reproduces the problem at

   http://www.uclinux.org/ports/coldfire/rd.i

This file is actually the c-preprocessed output of the original ramdisk
block driver from the Linux kernel, with just the offending function
left in. I have tried to cut it down, but found it difficult to keep
reproducing the problem. This file is ~270k in size, but it is mostly
the expanded headers that cause the bloat. This is the smallest size
I could get that still reproduces the problem.

Compiling with the above line needs no other support, it can
be run in isolation. So it is quite simple to reproduce after
fetching the file.

Any ideas?

Regards
Greg


--
------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg@snapgear.com
SnapGear Pty Ltd                               PHONE:    +61 7 3435 2888
825 Stanley St,                                  FAX:    +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia              WEB:   www.snapgear.com