This is the mail archive of the gcc-bugs@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]

gcc coldfire code generation problem



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


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