This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Soft floating point emulation problems
- To: linux at lists dot arm dot linux dot org dot uk, gcc at gcc dot gnu dot org, Richard dot Earnshaw at arm dot com
- Subject: Re: Soft floating point emulation problems
- From: cyril dot germond at philips dot com
- Date: Mon, 22 Oct 2001 18:15:50 +0200
>> Even if the process dramatically reduced the number of floating points instructions, there are still a few ones...where they should not be (AFAIK)!!!
>> For example, in the library libm.a, there are 3 stf instructions.
>>
>> arm-linux/lib/libm.a
>> 290: adad51ec stfges f5, [sp, #944]!
>> 308: bd241146 stflts f1, [r4, -#280]!
>> 470: bd241146 stflts f1, [r4, -#280]!
>>
>> I am quite confused !
>> I am wondering if I should have had generated gcc itsel with some kind of -msoft-float option (it was generated with -nfp in the configuration script).
>> Maybe is it a gcc configuration bug ?
>> Has anyone information about this problem ?
>> Does anyone know where could I find a set of floating-point instructions library ?
>>
>1) Are you sure these are really instructions in the code, and not
>constants in constant pools? The latter is quite probable, and the
>disassembler can't tell this (find the object file containing this
>instructions, compile the file to assembly and look for the same
>instructions in the output file).
- Yes, there is code at this location.
...
270: ea0000ac b 2b8 <__cbrt+0x2b8>
274: 3fc29801 swicc 0x00c29801
278: e893366d ldmia r3, {r0, r2, r3, r5, r6, r9, sl, ip, sp}
27c: 3fe91e2a swicc 0x00e91e2a
280: 6fe7e984 swivs 0x00e7e984
284: bffd5ae6 swilt 0x00fd5ae6
288: cfa20f0c swigt 0x00a20f0c
28c: 40039350 andmi r9, r3, r0, asr r3
290: adad51ec stfges f5, [sp, #944]!
294: c000eb82 andgt lr, r0, r2, lsl #23
298: 77cd8d5d undefined
29c: 3ff8218d swicc 0x00f8218d
2a0: de9028b4 mrcle 8, 4, r2, cr0, cr4, {5}
2a4: 3fd6b69c swicc 0x00d6b69c
2a8: ba168ff2 blt 5a4278 <__cbrt+0x5a4278>
...
2b8: e91babf0 ldmdb fp, {r4, r5, r6, r7, r8, r9, fp, sp, pc}
....
>2) If they are real FP instructions, are they coming from asm statements
>in the source?
Actually, those instructions come from C code statements (return calling a)
return __ldexp (x > 0.0 ? ym : -ym, xe / 3);
220: e28f2088 add r2, pc, #136 ; 0x88
224: e892000c ldmia r2, {r2, r3}
228: e24bc030 sub ip, fp, #48 ; 0x30
22c: e89c0003 ldmia ip, {r0, r1}
230: ebfffffe bl 0 <__cbrt>
234: e3500000 cmp r0, #0 ; 0x0
238: e51b6028 ldr r6, [fp, -#40]
23c: ca000093 bgt 254 <__cbrt+0x254>
240: e1a01005 mov r1, r5
244: e1a00004 mov r0, r4
248: ebfffffe bl 0 <__cbrt>
24c: e1a05001 mov r5, r1
250: e1a04000 mov r4, r0
254: e1a00006 mov r0, r6
258: e3a01003 mov r1, #3 ; 0x3
25c: ebfffffe bl 0 <__cbrt>
260: e1a02000 mov r2, r0
264: e1a01005 mov r1, r5
268: e1a00004 mov r0, r4
26c: ebfffffe bl 0 <__cbrt>
270: ea0000ac b 2b8 <__cbrt+0x2b8>
274: 3fc29801 swicc 0x00c29801
278: e893366d ldmia r3, {r0, r2, r3, r5, r6, r9, sl, ip, sp}
27c: 3fe91e2a swicc 0x00e91e2a
280: 6fe7e984 swivs 0x00e7e984
284: bffd5ae6 swilt 0x00fd5ae6
288: cfa20f0c swigt 0x00a20f0c
28c: 40039350 andmi r9, r3, r0, asr r3
290: adad51ec stfges f5, [sp, #944]!
294: c000eb82 andgt lr, r0, r2, lsl #23
298: 77cd8d5d undefined
29c: 3ff8218d swicc 0x00f8218d
2a0: de9028b4 mrcle 8, 4, r2, cr0, cr4, {5}
2a4: 3fd6b69c swicc 0x00d6b69c
2a8: ba168ff2 blt 5a4278 <__cbrt+0x5a4278>
...
But the statement contains a call (ldexp) which might be a macro calling a macro calling a macro... that is maybe using assembler statement (???).
I'am still investigating...
Anyway, I don't think such statements should be allowed in a non floating point mode.
Regards,
Cyril Germond
E-mail : cyril.germond@philips.com