This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Problem with printf and float


Hello Jeppe,

On Tuesday 26 October 2010 12:23:13 Jeppe Ledet-Pedersen wrote:
> Hi Pavel, All,
>
> I did some further testing. If I compile an ELF toolchain (non-EABI)
> with crosstool-NG, I get correct output regardless of whether I use
> -mfpu=vfp or not (and thus defines __VFP_FP__) when compiling newlib.
>
> This is my test output:
>
> ARM ELF (__IEEE_BIG_ENDIAN, __IEEE_BYTES_LITTLE_ENDIAN, IEEE_MC68k):
> 00 00 55 c0 00 00 00 00
> a is -84.000000
> ...
>
> ARM ELF (__IEEE_LITTLE_ENDIAN, IEEE_8087):
> 00 00 00 00 00 00 55 c0
> a is -84.000000
> ...
>
> As soon as I compile for arm-unknown-eabi instead of arm-unknown-elf, I
> can only print if I convert to FPA format.
>
> I'll continue my search. If you have any input or suggestions where to
> look, I'll be happy to hear from you.

The __IEEE_BYTES_LITTLE_ENDIAN is a way to declare right endianning
to to endian.h . It could be required for IEEE bitfields overlay
structures, but they use uitnt32_t or equivalent so it is not needed
there now.

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

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

Best wishes,
 
             Pavel Pisa





--
For unsubscribe information see http://sourceware.org/lists.html#faq


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]