This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
gcc coldfire code generation problem
- From: Greg Ungerer <gerg at snapgear dot com>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 05 Aug 2002 13:06:21 +1000
- Subject: gcc coldfire code generation problem
- Organization: SnapGear
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.c
You can get a sample file that reproduces the problem at
http://www.uclinux.org/ports/coldfire/rd.c
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 ~260k in size, but it is mostly
the expanded headers that cause the bloat.
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