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

[Bob Wirka]

Sorry, my email was prematurely cut off.

So, one way to fix this is to modify _putf() so it doesn't use va_arg(). Ugly, I know.
 
This can be done, however, and we don't need to worry about freeing memory 
or any unintended consequences (I think), as the va_end() macro in 
printf does nothing. So the va_list pointer passed to _putb() can be 
manipulated to provide correct values. I'll see if it works.
 
I wonder if anyone at GCC is listening?
 
Best,
 
Bob Wirka
Realtime Control Works
Janesville, WI


________________________________
 From: "bon at elektron.ikp.physik.tu-darmstadt.de" <bon at elektron.ikp.physik.tu-darmstadt.de>
To: Bob Wirka <bobwirka at yahoo.com>; Ethernut User Chat (English) <en-nut-discussion at egnite.de> 
Sent: Sunday, September 15, 2013 4:02 PM
Subject: Probable GCC Compiler error, was: Re: [En-Nut-Discussion] Problem with ARM floating point, again
 

>>>>> "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 ----------