[ECOS] sprintf test failure?

[ECOS] sprintf test failure?

[Grant Edwards]

Good afternoon campers,

I've been doing testing on the eCos snapshot from November 11, and
things are going pretty well.  So far all of the kernel tests pass,
and almost all of the libc tests pass -- a few of the sprintf tests
involving floating point fail.  (Sample output from the sprintf test
shown below.)  I don't think I'm going to actually be using sprintf
with floating point numbers. All of the other libc tests seem to pass.

Should I be concerned about the failures?

     Ecos rev: CVS snapshot as of 11 November 1999
  Ecos Target: arm
Ecos Platform: pidBE (modified to run on a Samsung SNDS eval board).
     Compiler: gcc 2.95.1
  Host System: Linux/i386 RedHat 6.0


----------------------------------------------------------------------
INFO:<Starting floating point specific tests>
PASS:<simple %f test #1>
PASS:<simple %f test #1 return code>
PASS:<simple %f test #2>
PASS:<simple %f test #2 return code>
PASS:<simple %f test #3>
PASS:<simple %f test #3 return code>
FAIL:<%f mixed with others> Line: 245, File: /home/grante/ecos/ecos/packages/ecos-snds/../language/c/libc/current/tests/stdio/sprintf1.c
FAIL:<%f mixed with others return code> Line: 246, File: /home/grante/ecos/ecos/packages/ecos-snds/../language/c/libc/current/tests/stdio/sprintf1.c
FAIL:<%f mixed with others> Line: 251, File: /home/grante/ecos/ecos/packages/ecos-snds/../language/c/libc/current/tests/stdio/sprintf1.c
FAIL:<%f mixed with others return code> Line: 252, File: /home/grante/ecos/ecos/packages/ecos-snds/../language/c/libc/current/tests/stdio/sprintf1.c
FAIL:<rounding test #1> Line: 257, File: /home/grante/ecos/ecos/packages/ecos-snds/../language/c/libc/current/tests/stdio/sprintf1.c
FAIL:<rounding test #1 return code> Line: 258, File: /home/grante/ecos/ecos/packages/ecos-snds/../language/c/libc/current/tests/stdio/sprintf1.c
PASS:<rounding test #2>
PASS:<rounding test #2 return code>
PASS:<+ modifier #1>
PASS:<+ modifier #1 return code>
FAIL:<+ modifier #2> Line: 275, File: /home/grante/ecos/ecos/packages/ecos-snds/../language/c/libc/current/tests/stdio/sprintf1.c
PASS:<+ modifier #2 return code>
PASS:<width modifier #1>
PASS:<width modifier #1 return code>
FAIL:<width modifier #2> Line: 287, File: /home/grante/ecos/ecos/packages/ecos-snds/../language/c/libc/current/tests/stdio/sprintf1.c
FAIL:<width modifier #2 return code> Line: 288, File: /home/grante/ecos/ecos/packages/ecos-snds/../language/c/libc/current/tests/stdio/sprintf1.c
----------------------------------------------------------------------

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] sprintf test failure?

[Grant Edwards]

On Mon, Nov 15, 1999 at 02:22:56PM -0600, Grant Edwards wrote:

> I don't think I'm going to actually be using sprintf with floating
> point numbers. All of the other libc tests seem to pass.  Should I
> be concerned about the failures?

I've also got some failures in libm (all of the failures were due to
results out of tolerance).  In my initial application, I doubt that I
will need any of the functions that failed, but if these failures are
due to something I did in my porting efforts, I'd like to get it
fixed.

PASS:<acos() is stable>
PASS:<asin() is stable>
FAIL:<atan() failed tests> Line: 82, File: [...]../language/c/libm/current/tests/vectors/atan.c
FAIL:<atan2() failed tests> Line: 82, File: [...]../language/c/libm/current/tests/vectors/atan2.c
PASS:<ceil() is stable>
FAIL:<cos() failed tests> Line: 82, File: [...]../language/c/libm/current/tests/vectors/cos.c
PASS:<cosh() is stable>
PASS:<exp() is stable>
PASS:<fabs() is stable>
PASS:<floor() is stable>
PASS:<fmod() is stable>
PASS:<frexp() is stable>
PASS:<ldexp() is stable>
FAIL:<log() failed tests> Line: 82, File: [...]../language/c/libm/current/tests/vectors/log.c
FAIL:<log10() failed tests> Line: 82, File: [...]../language/c/libm/current/tests/vectors/log10.c
PASS:<modf() is stable>
PASS:<pow() is stable>
FAIL:<sin() failed tests> Line: 82, File: [...]../language/c/libm/current/tests/vectors/sin.c
FAIL:<sinh() failed tests> Line: 82, File: [...]../language/c/libm/current/tests/vectors/sinh.c
PASS:<sqrt() is stable>
FAIL:<tan() failed tests> Line: 82, File: [...]../language/c/libm/current/tests/vectors/tan.c
FAIL:<tanh() failed tests> Line: 82, File: [...]../language/c/libm/current/tests/vectors/tanh.c

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] sprintf test failure?

[Gary Thomas]

On 15-Nov-99 Grant Edwards wrote:
> On Mon, Nov 15, 1999 at 02:22:56PM -0600, Grant Edwards wrote:
> 
>> I don't think I'm going to actually be using sprintf with floating
>> point numbers. All of the other libc tests seem to pass.  Should I
>> be concerned about the failures?
> 
> I've also got some failures in libm (all of the failures were due to
> results out of tolerance).  In my initial application, I doubt that I
> will need any of the functions that failed, but if these failures are
> due to something I did in my porting efforts, I'd like to get it
> fixed.
> 

These are most likely due to ARM compiler setup.

What [exactly] is your platform?  Which core?
What compiler flags do you use?

Re: [ECOS] sprintf test failure?

[Grant Edwards]

On Mon, Nov 15, 1999 at 02:30:55PM -0700, Gary Thomas wrote:

> > I've also got some failures in libm (all of the failures were due to
> > results out of tolerance).  In my initial application, I doubt that I
> > will need any of the functions that failed, but if these failures are
> > due to something I did in my porting efforts, I'd like to get it
> > fixed.
> 
> These are most likely due to ARM compiler setup.
> 
> What [exactly] is your platform?  

Samsung SNDS eval board with Samsung KS32C5000 uController.

I configured eCos with the tcl script for arm/pidBE/ram.

I've modified some of the pid platform stuff having to do with the
interrupt controlelr, timers, UARTs etc.  None of the makefiles were
touched.

> Which core?

ARM7TDMI.   (Big Endian)

> What compiler flags do you use?

Heres what a "make tests" did to compile the acos.c test file (FYI
arm-elf-gcc is gcc 2.25.1):

arm-elf-gcc  
 -c  
 -I/home/grante/ecos/ecos/packages/ecos-snds/install/include 
 -I. 
 -I/home/grante/ecos/ecos/packages/ecos-snds/../language/c/libm/current/tests 
 -mcpu=arm7tdmi 
 -mbig-endian 
 -Wall 
 -Wpointer-arith 
 -Wstrict-prototypes 
 -Winline 
 -Wundef 
 -ffunction-sections 
 -fdata-sections 
 -g 
 -O2   
 -Wp,-MD,vectors/libm_acos.tmp 
 -o vectors/libm_acos.o 
 /home/grante/ecos/ecos/packages/ecos-snds/../language/c/libm/current/tests/vectors/acos.c 

Re: [ECOS] sprintf test failure?

[Grant Edwards]

On Mon, Nov 15, 1999 at 04:06:37PM -0600, Grant Edwards wrote:

> Heres what a "make tests" did to compile the acos.c test file (FYI
> arm-elf-gcc is gcc 2.25.1):

That should read 2.95.1 -- And I wonder why things dont work....

Re: [ECOS] sprintf test failure?

[Jonathan Larmour]

Grant Edwards wrote:
> 
> On Mon, Nov 15, 1999 at 02:22:56PM -0600, Grant Edwards wrote:
> 
> > I don't think I'm going to actually be using sprintf with floating
> > point numbers. All of the other libc tests seem to pass.  Should I
> > be concerned about the failures?
> 
> I've also got some failures in libm (all of the failures were due to
> results out of tolerance).  In my initial application, I doubt that I
> will need any of the functions that failed, but if these failures are
> due to something I did in my porting efforts, I'd like to get it
> fixed.
> 
> PASS:<acos() is stable>
> PASS:<asin() is stable>
> FAIL:<atan() failed tests> Line: 82, File: [...]../language/c/libm/current/tests/vectors/atan.c

The fact that some of them pass but not all of them makes me think a
compiler bug (or more specifically, a miscompilation of libgcc, since that's
where the soft float code lives).

FWIW, I've compiled eCos with gcc 2.95.2 with a binutils snapshot of about
two weeks ago. I built for ARM PID (arm7tdmi specifically), but
little-endian. It works fine. I just went back and verified, and both
sprintf1 and atan tests work.

It could be a code generation issue with 2.95.1 or older binutils (less
likely) - I don't know. Or it could be something to do with the
big-endianness.

Jifl
-- 
Cygnus Solutions, 35 Cambridge Place, Cambridge, UK.  Tel: +44 (1223) 728762
"I used to have an open mind but || Get yer free open source RTOS's here...
 my brains kept falling out."    || http://sourceware.cygnus.com/ecos
Help fight spam! http://spam.abuse.net/  These opinions are all my own fault

Re: [ECOS] sprintf test failure?

[Grant Edwards]

On Mon, Nov 15, 1999 at 11:01:53PM +0000, Jonathan Larmour wrote:
>
> > > I don't think I'm going to actually be using sprintf with floating
> > > point numbers. All of the other libc tests seem to pass.  Should I
> > > be concerned about the failures?
> > 
> > I've also got some failures in libm (all of the failures were due to
> > results out of tolerance).  In my initial application, I doubt that I
> > will need any of the functions that failed, but if these failures are
> > due to something I did in my porting efforts, I'd like to get it
> > fixed.
> > 
> > PASS:<acos() is stable>
> > PASS:<asin() is stable>
> > FAIL:<atan() failed tests> Line: 82, File: [...]/tests/vectors/atan.c
> 
> The fact that some of them pass but not all of them makes me think a
> compiler bug (or more specifically, a miscompilation of libgcc, since that's
> where the soft float code lives).
>
> Fwiw, I've compiled eCos with gcc 2.95.2 with a binutils snapshot of about
> two weeks ago. I built for ARM PID (arm7tdmi specifically), but
> little-endian. It works fine. I just went back and verified, and both
> sprintf1 and atan tests work.

I'll make a note of that and perhaps build 2.95.2 tomorrow.  I'm going
to need a faster computer if I'm going to start hacking on gcc.

> It could be a code generation issue with 2.95.1 or older binutils (less
> likely) - I don't know. Or it could be something to do with the
> big-endianness.

I should probably forget about the floating point stuff for now and
get back to work on the interrupt-driven serial port driver so that
I've got some relevent progress to report in the weekly staff meeting
tomorrow.  :)

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] sprintf test failure?

[Grant Edwards]

On Mon, Nov 15, 1999 at 11:01:53PM +0000, Jonathan Larmour wrote:

> > I've also got some failures in libm (all of the failures were due to
> > results out of tolerance).  In my initial application, I doubt that I
> > will need any of the functions that failed, but if these failures are
> > due to something I did in my porting efforts, I'd like to get it
> > fixed.

> FWIW, I've compiled eCos with gcc 2.95.2 with a binutils snapshot of about
> two weeks ago. I built for ARM PID (arm7tdmi specifically), but
> little-endian. It works fine. I just went back and verified, and both
> sprintf1 and atan tests work.

Using gcc 2.95.2 and binutils-991018 (four weeks ago) still fails the
same tests on the Samsung board (ARM7tdmi big-endian).

> It could be a code generation issue with 2.95.1 or older binutils (less
> likely) - I don't know. 

It could theoretically be binutils (but I doubt it).

> Or it could be something to do with the big-endianness.

That's where I'd put my money if I were a betting man.

Any suggestions on tracking down the source of the problem, should I
choose to bet a few hours on that horse?

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] sprintf test failure?

[Jonathan Larmour]

Grant Edwards wrote:
> 
> On Mon, Nov 15, 1999 at 11:01:53PM +0000, Jonathan Larmour wrote:
> 
> > Or it could be something to do with the big-endianness.
> 
> That's where I'd put my money if I were a betting man.
> 
> Any suggestions on tracking down the source of the problem, should I
> choose to bet a few hours on that horse?

It's a bit of a toughie because all the libm failures are in relatively
complex functions. One of the failures was with sprintf(x, "hello%fworld",
2.3456786); which is probably as simple as you're going to get.

Make a new file with just this in, and something that prints out the result,
so you can see what is actually happening. Then fire up GDB, set a
breakpoint on `cvt' and have a look :-/.

NB Have you tried compiling with optimization to see if that fixes the
problem? If so, it could be an optimization bug. If not, you should probably
still try to debug this with optimization turned off as it can make
debugging that bit more difficult.

Jifl
-- 
Cygnus Solutions, 35 Cambridge Place, Cambridge, UK.  Tel: +44 (1223) 728762
"I used to have an open mind but || Get yer free open source RTOS's here...
 my brains kept falling out."    || http://sourceware.cygnus.com/ecos
Help fight spam! http://spam.abuse.net/  These opinions are all my own fault

Re: [ECOS] sprintf test failure?

[Jesper Skov]

>>>>> "Grant" == Grant Edwards <grante@visi.com> writes:

Grant> Any suggestions on tracking down the source of the problem,
Grant> should I choose to bet a few hours on that horse?

The ARM has some funny layout of doubles in BE mode (or possibly LE
mode) where the order of the words are different than the order of the
individual bytes. I.e., EFGHABCD or DCBAHGFE... See what I mean?

That's the firsd thing I would check.

If time allows, I'll try to run the test the pid in BE mode tomorrow.

Jesper

Re: [ECOS] sprintf test failure?

[Grant Edwards]

On Wed, Nov 17, 1999 at 08:45:52PM +0000, Jonathan Larmour wrote:

> NB Have you tried compiling with optimization to see if that fixes the
> problem? If so, it could be an optimization bug. If not, you should probably
> still try to debug this with optimization turned off as it can make
> debugging that bit more difficult.

Here's what I think I did: Changed to -O0 and recompiled everything
under language/c -- everything quit working.  Changed back to -O2
recompiled everything under language/c, and still everything was
broken.  Started over with a clean configuration and got it working
again (with the default optimization of -O2).

Before I try shutting off optimization again (not sure what went wrong
last time) is there stuff that I should _not_ compile with -O0?  IIRC
that shuts of __inline__ functions, and that breaks some stuff when
compiling certain Linux apps (e.g. port I/O breaks).  I really don't
think that it was the -O0 that broke my configuration before, but I
thought I'd ask before repeating the experiment.

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] sprintf test failure?

[Jonathan Larmour]

Grant Edwards wrote:
> 
> Before I try shutting off optimization again (not sure what went wrong
> last time) is there stuff that I should _not_ compile with -O0?  

No, everything should be able to be compiled with -O0. If not, it's a bug.

I do it quite often, so if it broke, it must have been recent.

Jifl
-- 
Cygnus Solutions, 35 Cambridge Place, Cambridge, UK.  Tel: +44 (1223) 728762
"I used to have an open mind but || Get yer free open source RTOS's here...
 my brains kept falling out."    || http://sourceware.cygnus.com/ecos
Help fight spam! http://spam.abuse.net/  These opinions are all my own fault

Re: [ECOS] sprintf test failure?

[Jesper Skov]

>>>>> "Jonathan" == Jonathan Larmour <jlarmour@cygnus.co.uk> writes:

Jonathan> No, everything should be able to be compiled with -O0. If
Jonathan> not, it's a bug.

Jonathan> I do it quite often, so if it broke, it must have been
Jonathan> recent.

Or it could be in the BE GCC code only. I'm sure there must be
separate BE/LE code to handle that silly layout of doubles.

Jesper

Re: [ECOS] sprintf test failure?

[Gary Thomas]

On 18-Nov-99 Jesper Skov wrote:
>>>>>> "Jonathan" == Jonathan Larmour <jlarmour@cygnus.co.uk> writes:
> 
> Jonathan> No, everything should be able to be compiled with -O0. If
> Jonathan> not, it's a bug.
> 
> Jonathan> I do it quite often, so if it broke, it must have been
> Jonathan> recent.
> 
> Or it could be in the BE GCC code only. I'm sure there must be
> separate BE/LE code to handle that silly layout of doubles.
> 

I don't see how this can be a LE/BE issue.  Grant is only having failures
on _some_ tests.  Surely if things were screwed up by the compiler, they
would all fail.

NB: I haven't looked at this in depth [yet], this is just my initial impression.

Re: [ECOS] sprintf test failure?

[Grant Edwards]

On Wed, Nov 17, 1999 at 08:45:52PM +0000, Jonathan Larmour wrote:

> NB Have you tried compiling with optimization to see if that fixes the
> problem? If so, it could be an optimization bug. If not, you should probably
> still try to debug this with optimization turned off as it can make
> debugging that bit more difficult.

With -O0 the behavior appears to be the same as with -O2.  I guess
it's time to step through some simple tests, though I may not have a
chance to look more closely at it until Monday.

-- 
Grant

Re: [ECOS] sprintf test failure?

[Grant Edwards]

On Wed, Nov 17, 1999 at 09:48:44PM +0100, Jesper Skov wrote:

> Grant> Any suggestions on tracking down the source of the problem,
> Grant> should I choose to bet a few hours on that horse?
> 
> The ARM has some funny layout of doubles in BE mode (or possibly LE
> mode) where the order of the words are different than the order of the
> individual bytes. I.e., EFGHABCD or DCBAHGFE... See what I mean?

Yup, It looks like the the type Cyg_libm_ieee_double_shape_type is not
right.

I'm stepping thorugh cvt(), and see the following values:

   ieefp.value == -2.5
   ieefp.number.sign == 0

ieefp.number.sign should be non-zero for values ieefp.value <= -0.0, so
the union seems to be wrong.  More news later...

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] sprintf test failure?

[Grant Edwards]

On Wed, Nov 17, 1999 at 09:48:44PM +0100, Jesper Skov wrote:

> The ARM has some funny layout of doubles in BE mode (or possibly LE
> mode) where the order of the words are different than the order of the
> individual bytes. I.e., EFGHABCD or DCBAHGFE... See what I mean?

At least w/ gcc 2.95.2 the layout is strictly MSB first.

The problem was that the macro CYG_BYTEORDER in the file
ecos-snds/install/include/cyg/hal/basetype.h was defined as
CYG_LSBFIRST and it should be CYG_MSBFIRST.

This caused the wrong unions to be used for disecting IEEE floats and
doubles.

I don't know how that file gets generated, I presume the package
config processes copied it from hal/arm/arch/current/include/basetype.h.  

Apparently there's only the one "basetype.h" file for the arm, and
there should be two?

Somehow the pidBE platform package needs to handle this.

Changing to CYG_MSBFIRST fixed the sprintf errors, and though I
haven't re-run the libm tests, I expect those will be OK.  But, I'm
going to go home while I'm ahead, just in case...

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] sprintf test failure?

[Jonathan Larmour]

Grant Edwards wrote:
> 
> The problem was that the macro CYG_BYTEORDER in the file
> ecos-snds/install/include/cyg/hal/basetype.h was defined as
> CYG_LSBFIRST and it should be CYG_MSBFIRST.
> 
> This caused the wrong unions to be used for disecting IEEE floats and
> doubles.
> 
> I don't know how that file gets generated, I presume the package
> config processes copied it from hal/arm/arch/current/include/basetype.h.
> 
> Apparently there's only the one "basetype.h" file for the arm, and
> there should be two?

No need, see below.
 
> Changing to CYG_MSBFIRST fixed the sprintf errors, and though I
> haven't re-run the libm tests, I expect those will be OK.  But, I'm
> going to go home while I'm ahead, just in case...

Wow. It's a wonder it wasn't found for so long. Now fixed in the master
repository, although I just happened to send out an anonymous CVS update 10
mins ago :-/. The change is obvious though:

#ifdef (__ARMEB__)
# define CYG_BYTEORDER           CYG_MSBFIRST    // Big endian
#else
# define CYG_BYTEORDER           CYG_LSBFIRST    // Little endian
#endif

Jifl
-- 
Cygnus Solutions, 35 Cambridge Place, Cambridge, UK.  Tel: +44 (1223) 728762
"I used to have an open mind but || Get yer free open source RTOS's here...
 my brains kept falling out."    || http://sourceware.cygnus.com/ecos
Help fight spam! http://spam.abuse.net/  These opinions are all my own fault

Re: [ECOS] sprintf test failure?

[Jesper Skov]

>>>>> "Grant" == Grant Edwards <grante@visi.com> writes:

Grant> On Wed, Nov 17, 1999 at 09:48:44PM +0100, Jesper Skov wrote:
>> The ARM has some funny layout of doubles in BE mode (or possibly LE
>> mode) where the order of the words are different than the order of
>> the individual bytes. I.e., EFGHABCD or DCBAHGFE... See what I
>> mean?

Grant> At least w/ gcc 2.95.2 the layout is strictly MSB first.

Grant> The problem was that the macro CYG_BYTEORDER in the file
Grant> ecos-snds/install/include/cyg/hal/basetype.h was defined as
Grant> CYG_LSBFIRST and it should be CYG_MSBFIRST.

Grant> This caused the wrong unions to be used for disecting IEEE
Grant> floats and doubles.

Grant> I don't know how that file gets generated, I presume the
Grant> package config processes copied it from
Grant> hal/arm/arch/current/include/basetype.h.

Grant> Apparently there's only the one "basetype.h" file for the arm,
Grant> and there should be two?

Grant> Somehow the pidBE platform package needs to handle this.

Grant> Changing to CYG_MSBFIRST fixed the sprintf errors, and though I
Grant> haven't re-run the libm tests, I expect those will be OK.  But,
Grant> I'm going to go home while I'm ahead, just in case...

Bugger!

This is what it should look like - and actually does look like in my
tree. It's a merge oversight. I'll check in the changes right away.

Sorry for the hassle I've caused you.

Jesper

#if defined(__ARMEB__)
#define CYG_BYTEORDER           CYG_MSBFIRST    // Big endian
#else
#define CYG_BYTEORDER           CYG_LSBFIRST    // Little endian
#endif

Re: [ECOS] sprintf test failure?

[Jonathan Larmour]

Jesper Skov wrote:
> 
> This is what it should look like - and actually does look like in my
> tree. It's a merge oversight. I'll check in the changes right away.

Heh. Beat you :-).

Jifl
-- 
Cygnus Solutions, 35 Cambridge Place, Cambridge, UK.  Tel: +44 (1223) 728762
"I used to have an open mind but || Get yer free open source RTOS's here...
 my brains kept falling out."    || http://sourceware.cygnus.com/ecos
Help fight spam! http://spam.abuse.net/  These opinions are all my own fault

Re: [ECOS] sprintf test failure?

[Grant Edwards]

On Fri, Nov 19, 1999 at 11:46:07PM +0000, Jonathan Larmour wrote:

> > The problem was that the macro CYG_BYTEORDER in the file
> > ecos-snds/install/include/cyg/hal/basetype.h was defined as
> > CYG_LSBFIRST and it should be CYG_MSBFIRST.
> 
> Wow. It's a wonder it wasn't found for so long. 

Were I an author of eCos, I would regard it as a testament to my
ability to write portable code that doesn't make assumptions about
byte-ordering.  ;)

You don't want to hear about how long it once took me and another guy
to get a CRC routine coded so that it worked right regardless of the
CPU type...

-- 
Grant Edwards
grante@visi.com