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

bon at elektron.ikp.physik.tu-darmstadt.de bon at elektron.ikp.physik.tu-darmstadt.de
Sun Sep 15 23:02:39 CEST 2013

>>>>> "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);
                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?


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

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

More information about the En-Nut-Discussion mailing list