GCC 2.7.2.3, ARM target bug -
Richard Earnshaw
rearnsha@arm.com
Fri Dec 31 20:54:00 GMT 1999
> I am using:
>
> gcc 2.7.2.3 for target arm-unknown-aout
>
> When I feed it this code:
>
>
> void
> A(var1, var2)
> char *var1;
> char *var2;
> {
> if (var2) {
> foocpy(var1, var2);
> } else {
> var1[0] = '\0';
> }
> }
>
>
> and compile with 'cc -O2 -S foo.c' and look in the resulting foo.s:
>
> [snip leadin stuff]
> _A:
> @ args = 0, pretend = 0, frame = 0
> @ frame_needed = 1, current_function_anonymous_args = 0
> mov ip, sp
> stmfd sp!, {fp, ip, lr, pc}
> cmp r1, #0
> sub fp, ip, #4
> blne _foocpy
> L2:
> moveq r3, #0 @ This is the else, and it only
> streqb r3, [r0, #0] @ works if foocpy() doesn't change
> ldmea fp, {fp, sp, pc}^ @ the flags, which it will
>
> Using no optimisation fixes it, of course. -O1 seems to exhibit
> the same problem, though.
No, this is not a bug. Your compiler is configured to produce code for
26-bit mode. In this mode subroutines preserve the processor flags over a
function call so the optimization above is safe. There are two possible
solutions to your problem:
1) Rebuild the compiler to default to 32-bit mode (the arm-semi-aout
configuration defaults to this mode).
2) Use -macps-32 when compiling source files. This tells the compiler
to generate code in 32-bit mode.
Note: gcc-2.7 is very old now. There have been many other bugs fixed
since then and code generation is much better in more recent releases. I
strongly recommend that you upgrade to gcc-2.95.2
Richard.
More information about the Gcc-bugs
mailing list