This is the mail archive of the
newlib@sources.redhat.com
mailing list for the newlib project.
Re: newlib printf %f BUG
- From: Ted Merrill <ted at arraycomm dot com>
- To: "J. Johnston" <jjohnstn at cygnus dot com>
- Cc: newlib at sourceware dot cygnus dot com, jjohnstn at redhat dot com
- Date: Tue, 20 Nov 2001 17:54:54 -0800 (PST)
- Subject: Re: newlib printf %f BUG
Thanks for trying to find the bug. See comments below.
On Tue, 20 Nov 2001, J. Johnston wrote:
> Ted Merrill wrote:
> >
> > I hope this is where to report bugs.
> >
> > Using both newlib-1.8.2 and newlib-1.9.0 compiled using gcc for ARM/thumb
> > architecture using gcc 3.0,
> > a bug in printf floating point formatting is seen for some numbers.
> >
> > Sample code:
> >
> > void MathTest2(void)
> > {
> > /* This tests a bug we found in newlib 1.8.2
> > */
> > double R = 3.4263125;
> > printf("%.6f\n", R );
> > }
> >
>
> Ted,
>
> Have you tried this using the latest newlib sources? Newlib 1.9.0 is simply
> a snapshot. A number of fixes have been applied to these sources, including
> at least one fix to printf %f.
I'm reluctant to pull anything out of CVS because i will have no idea
whether it is working or not, whereas with an "official" release there
is some more assurance that it is working...
I don't see any policy statement in this regard on the newlib web pages,
and for that matter i don't see any lists of bugs found or fixed...
i did peruse the mailing list archives but saw nothing like my problem.
It would seem reasonable that i at least retrieve the latest dtoa.c
file and compare it with the one from 1.9.0 ...
>
> Are you specifying any special options on the compile/link? If so,
> you should consider doing a unified source-tree build so that gcc can
> locate the proper newlib based on your options.
Compile options are:
-mthumb -Wall -g -O -fno-omit-frame-pointer
The -mthumb option builds for the 16-bit instruction set.
Linking is done with a special script that uses ld to do exactly what
i want it to do.
In addition, the correct source code pathnames were emitted from objdump.
>
> Using the latest newlib sources and the armulator simulator, I am able to
> get the accompanying test case to print the correct value. I am using default
> options and because I did not do a unified build, I had to copy the crt0.o
> file to my test directory. My arm-elf-gcc is slightly ahead of yours.
Ok, if i don't see a significant fix to dtoa.c then i should suspect
a compiler bug i guess...
>
> Regards,
>
> -- Jeff J.
>
> #include <stdio.h>
>
> int main()
> {
> /* This tests a bug we found in newlib 1.8.2
> */
> double R = 3.4263125;
> printf("%.6f\n", R );
> }
>
> >% arm-elf-run a.out
> 3.426312
>