Re:  problem while building arm vfp softfloat gcc 

["add" <addsub at eyou dot com>]

>> > sorry for my testcase, I had rewriten it to easy to understand, but on
the
>> > contrary...
>> > Here is my true test case using printf:
>> > ----main.c
>> > #include <stdio.h>
>> > #include <stdlib.h>
>> > 
>> > int main()
>> > {
>> >         float i=1.0;
>> >         printf("%f",i);
>> >         return 0;
>> > }
>> > ----main.c
>> > 
>> > here is generated by arm-linux-gcc -S main.c -o main.s
>> > ----main.s
>> > <sniz>
>> > main:
>> >           @ args = 0, pretend = 0, frame = 4
>> >           @ frame_needed = 1, uses_anonymous_args = 0
>> >           mov     ip, sp
>> >           stmfd   sp!, {r4, fp, ip, lr, pc}
>> >           sub     fp, ip, #4
>> >           sub     sp, sp, #4
>> >           ldr     r3, .L2 @ float
>> >           str     r3, [fp, #-20]  @ float
>> >           ldr     r0, [fp, #-20]  @ float
>> >           bl      __extendsfdf2
>> >           mov     r4, r1
>> >           mov     r3, r0
>> >           ldr     r0, .L2+4
>> >           mov     r2, r4
>> >           mov     r1, r3
>> >           bl      printf
>> >           mov     r3, #0
>> >           mov     r0, r3
>> > <sniz>
>> > -----main.s
>> > 
>> > if I arm-linux-gcc main.s -o test
>> > then execute test on pxa board, it will output: -1.999744
>> > 
>> > but if I modified the two lines before "bl printf" in main.s to:
>> > mov	r2, r3
>> > mov	r3, r4
>> > then compile main.s and execute,
>> > it will print right result: 1.00000
>> > 
>> > so conclusion:
>> > my toolchain must has a problem of float param passing, seemly related
to
>> > float word order. so I want to dig into my gcc source tree to find where
is
>> > responsible for generating this wrong asm code.
>> > I hope this time it's clearer :)
>> > 
>> > and Dan, I think the most recently snapshot ptxdist still has this
problem
>> > :(
>> 
>> The code above is correct.  You should not be doing a word order swap 
>> before the call to printf.
>> 
>> So I think the problem must be in your printf library function (or a 
>> subroutine of that).  Two possibilities here:
>> 
>> 1) The library was compiled without soft-vfp (it for traditional FPA 
>> format floats).
>> 2) The library needs porting to support soft-vfp (there will probably be 
>> #ifdef __arm__ somewhere in the library, where the code will then assume 
>> that you have FPA format floats).
>> 
>
>There is of course, one more possibility.  Do you get correct output if 
>you compile the following program?
>
>#include <stdio.h>
>#include <stdlib.h>
>
>int main()
>{
>        double i=1.0;
>        printf("%f",i);
>        return 0;
>}
>
>If you do, then the problem is most likely in the call to __extendsfdf2
>
>R.
>
I have already tried this on my platform, it still print out 0.000000
so it seems like a problem of glibc.
I swapped the register according to montavista's iwmmxt_le-gcc produced asm
code. Are you sure that code is correct? if so, then that means montavista's
toolchain is not compatible with others, although it uses the same vfp
softfloat patch.

>
>------
>Want more information?  See the CrossGCC FAQ,
http://www.objsw.com/CrossGCC/
>Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
>
> 





--http://www.eyou.com
--Îȶ¨¿É¿¿µÄµç×ÓÐÅÏä  ÓïÒôÓʼþ  Òƶ¯ÊéÇ©  ÈÕÀú·þÎñ  ÍøÂç´æ´¢...ÒÚÓÊδ¾¡

--http://vip.eyou.com
--¿ì¿ìµÇ¼ÒÚÓÊVIPÐÅÏä  ×¢²áÄúÖÐÒâµÄÓû§Ãû



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com