ts-7000
[Top] [All Lists]

Re: [ts-7000] Warning: Floating point format bug encountered using arm-l

To:
Subject: Re: [ts-7000] Warning: Floating point format bug encountered using arm-linux-gcc-3.3.4
From: Joe Bouchard <>
Date: Sat, 21 Oct 2006 10:25:08 -0400
On Sat, Oct 21, 2006 at 12:30:47PM -0000, arm.user wrote:
> Hi All,
> 
> While porting an x86-based communications project to a TS-7250, I 
> encountered an bug relating to how (8-byte) doubles are stored 
> internally in applications compiled using arm-linux-gcc-3.3.4.
> 
> The bug manifests itself as a non-standard byte ordering in memory. 
> Specifically, instead of the 8-bytes bytes associated with double 
> precision float being ordered as:
> 
>    B0 B1 B2 B3 B4 B5 B6 B7
> 
> they are actually ordered as:
> 
>    B4 B5 B6 B7 B0 B1 B2 B3
> 
> which is neither LSB or MSB.  The bytes, when re-arranged, do 
> correspond to the IEEE-754 format and yield correct floating point 
> value.
> 
> A note about this bug appear this appears 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18620, where the issue 
> declared "WONTFIX".
> 
> Regards
> Roy

It's important to ask "what does this mean in the real world?", and I'm not able
to translate the implications of the above statements.  I will make a few
statements and hopefully you can tell me which ones are wrong...

1) Performing traditional mathematical operations should work fine, as the
   compiler knows what it is doing in a consistant manner.

2) It does not matter whether the code is compiled on the ARM or cross-compiled
   on an x86, the behavior is consistant.

3) the following should work OK: printf("value is %d",double), again because the
   compiler is familiar with what it is doing.

4) If I open an ASCII text file for output, and write records which include
   double using fprintf, everything will work fine.  I tend to do this anyway.

5) If I open a binary file for output, and write records which include doubles,
   and then try to read those files later on on an x86 or PowerPC system, I will
   not get the results I had hoped for.

6) If I have a double in memory, and then take that pointer and cast it to
   (void *) and start manipulating the bytes directly, I will definitely run
   into troubles if I use the same algorithm used on x86 or powerPC.

7) The above failures (5) and (6) are valid concerns, but they would also be a
   problem when you are switching between x86 and powerPC, or possibly any of
   the 11 platforms supported by Debian at this time.  That's just good old
   fashioned binary incompatibility.

8) The workaround described in bugzilla is probably in place much of the time,
   even if we aren't even aware of it.  When I'm doing cross compiles I believe
   I normally see -mcpu=arm9 or -mcpu=arm9tdmi flying by, and if so, the
   workaround is in place, although it's not clear to me what difference this
   makes.

Thanks,
Joe


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/ts-7000/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/ts-7000/join
    (Yahoo! ID required)

<*> To change settings via email:
     
    

<*> To unsubscribe from this group, send an email to:
    

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 

<Prev in Thread] Current Thread [Next in Thread>
Admin

Disclaimer: Neither Andrew Taylor nor the University of NSW School of Computer and Engineering take any responsibility for the contents of this archive. It is purely a compilation of material sent by many people to the birding-aus mailing list. It has not been checked for accuracy nor its content verified in any way. If you wish to get material removed from the archive or have other queries about the archive e-mail Andrew Taylor at this address: andrewt@cse.unsw.EDU.AU