[En-Nut-Discussion] Probable GCC Compiler error, was: Re: Problem with ARM floating point, again

[bon at elektron.ikp.physik.tu-darmstadt.de]

>>>>> "Bob" == Bob Wirka <bobwirka at yahoo.com> writes:

    Bob> Hello, I'm having issues with printf("%f") on my AT91SAM7X512
    Bob> platform (using ethernut-4.10.3). We're using the Codesourcery
    Bob> compiler (gcc version 4.5.1 (Sourcery G++ Lite 2010.09-51)).


Sending a working, stripped down example may lower the barrier for others
to enter that problem...

Anyway, I tried on STM32F4 with Launchpad gcc and I can see the problem
too. Debugging and stepping a lot through the code, I am quite sure that it
is a compiler problem. I can get things to print right with substituting
                _double = va_arg(ap, double);
by
                uint32_t *l = (uint32_t *)&_double;

                if (*(uint32_t*)&ap & 4) {
                    l[0]= va_arg(ap, uint32_t);
                    l[1]= va_arg(ap, uint32_t);
                }
                else {
                    l[0]= va_arg(ap, uint32_t);
                    l[0]= va_arg(ap, uint32_t);
                    l[1]= va_arg(ap, uint32_t);
                }

When pushing the arguments on the stack, the arm calling convention tells to
put 64-bit units in R0/1 or R2/3 or stack aligned. I see this happening. It
seems as va_start doesn't care for that alignment. The 64-bit data has also
either its 32-bit words swapped in the va_list, or va_arg(ap, double) uses the
wrong order.

Can anybody confirm that this may not me caused by some strange compiler
option we give?

Bye

-- 
Uwe Bonnes                bon at elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------