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