Problem with printf and float

Jeppe Ledet-Pedersen
Wed Oct 27 17:39:00 GMT 2010

Hi Pavel, All,

On 2010-10-26 13:57, Pavel Pisa wrote:
> I am not expert, but your results points to to something strange
> in GCC. Other thing which is strict for EABI is 8 bytes alignment
> on the stack. But I am not sure if soft float arm7tdmi can be
> influenced by this problem. I think not, because it does not
> have 64 bit multimedia or FP registers and accesses as ARM5
> and above. Other problem could some bug in parameters passing
> conventions. Does the problem appears in dtoa() case as well.

No, dtoa seems to work fine. I have updated my test code:

dtoa output: 84, decpt is 2 and sign is 1

I have also tried to copy the ldieee struct (53 bit mantissa) from 
stdio/vfieeefp.h to my test code, to see if the bitfields matched. I had 
to add a packed attribute, but then I got the correct output:

manl: 0
manh: 50000000
exp: 405
sign: 1

Adding __attribute__ ((packed)) to the bitfields in vfieeefp.h does not 
solve the problem, but it could be needed. IIRC, C does not guarantee 
anything about the layout of bitfields, so the ldieee structs could be 
part of the problem. This is further supported by the fact that dtoa, 
which does not use the structs, works.

> If there are some strange problems in varargs you can try
>    printf("a is %f\r\n", a);
>    printf("fill %ld and a is %f\r\n", 1L, a);
>    printf("fill %ld, %ld  and a is %f\r\n", 1L, 2L, a);
>    printf("fill %ld, %ld, %ld and a is %f\r\n", 1L, 2L, 3L, a);
> These options should push passing of "a" out from parameters
> passed by registers.

I added your suggestions to my test code and did get some weird results:

Before flip:
00 00 00 00 00 00 55 c0
a is 0.000000
fill 1 and a is 3135806246969956017225324825[...]
fill 1, 2  and a is 0.000000
fill 1, 2, 3 and a is 31352364387915649882790342116430[...]

After flip:
00 00 55 c0 00 00 00 00
a flipped is -84.000000
fill 1 and a flipped is 0.000000
fill 1, 2  and a flipped is -84.000000
fill 1, 2, 3 and a flipped is 313523477950794742515896974[...]

> Your paste code doesnot include #include<stdio.h>.
> Vaargs should work even for functions without declarations,
> but I would not write code depending on that and elimination
> of this possibility should be right step.

My code does include stdio.h, so that is not the reason.

> You can test with other GCC release (4.4.x) as well.

Yes, I will try that.

Thank you.

Best regards,

More information about the Newlib mailing list