Update v8 dtoa.c with latest changes from http://www.netlib.org/fp/dtoa.c...

Update v8 dtoa.c with latest changes from http://www.netlib.org/fp/dtoa.c

This should solve gcc 4.4 strict aliasing issues.

[Craig Schlenter, 2009-05-12 15:49:21]

This should fix http://code.google.com/p/v8/issues/detail?id=266

I have only run the tests on linux with gcc 4.4 and in release mode I get some
crashes BUT those same crashes are present even with the existing dtoa.c thus
suggesting that this patch is probably not involved. In debug mode, everything
passes perfectly.

The easiest way to review this would probably be to diff the new dtoa.c against
the www.netlib.org/fp/dtoa.c version and compare that to the original changes
that were made to the v8 dtoa.c code.

Thank you!

[wtc, 2009-05-12 17:47:46]

http://codereview.chromium.org/115176/diff/4/1003
File src/dtoa-config.c (right):

http://codereview.chromium.org/115176/diff/4/1003#newcode50
Line 50: !defined(__FreeBSD__) && __FLOAT_WORD_ORDER == __BIG_ENDIAN
Strictly speaking, we should test the processor architecture
rather than the OS to determine the byte order, because an OS
may support processors with different byte orders.

Common predefined macros for processor architectures
currently or soon to be supported by V8:
GCC: __i386__, __x86_64__, __arm__ (__ARMEL__ or __ARMEB__)
Visual C++: _M_IX86, _M_X64 (older form _M_AMD64)

http://codereview.chromium.org/115176/diff/4/1003#newcode75
Line 75: #include "stdlib.h"
Nit: use <stdlib.h> for a system header.  You may want to
combine this with line 65 above.

[Mads Ager (chromium), 2009-05-13 08:23:07]

This looks a lot like what I did when I tried to update the dtoa version used in
V8.  

Unfortunately, gcc 4.2.4 has a problem with this version of dtoa when using -O2
or above.  I get the following failure only in release mode when using -O2 or
above:

=== release number-tostring ===                                      
Path: mjsunit/number-tostring
/home/ager/v8/v8/test/mjsunit/mjsunit.js:50: Failure: expected
<0.00000000000000000010> found <0.0000000000000000000:>

Therefore, I cannot put this patch in as is and we will have to compile with
-fno-strict-aliasing on gcc 4.4 for now.

[Craig Schlenter, 2009-05-13 15:39:39]

On 2009/05/13 08:23:07, Mads Ager wrote:
> This looks a lot like what I did when I tried to update the dtoa version used
in
> V8.  
> 
> Unfortunately, gcc 4.2.4 has a problem with this version of dtoa when using
-O2
> or above.  I get the following failure only in release mode when using -O2 or
> above:
> 
> === release number-tostring ===                                      
> Path: mjsunit/number-tostring
> /home/ager/v8/v8/test/mjsunit/mjsunit.js:50: Failure: expected
> <0.00000000000000000010> found <0.0000000000000000000:>

Wow. That's ending in ':' which is one ascii character past 9 so it looks like
it almost got it right and perhaps just forgot to 'carry' that digit over
properly.
 
> Therefore, I cannot put this patch in as is and we will have to compile with
> -fno-strict-aliasing on gcc 4.4 for now.

OK. Unfortunately -fno-strict-aliasing doesn't help for the other crashes I see:

=== release debug-evaluate ===                                  
Path: mjsunit/debug-evaluate
Command: /home/craig/v8/shell --expose-debug-as debug
/home/craig/v8/test/mjsunit/mjsunit.js
/home/craig/v8/test/mjsunit/debug-evaluate.js
--- CRASHED ---
=== release debug-evaluate-locals ===                           
Path: mjsunit/debug-evaluate-locals
Command: /home/craig/v8/shell --expose-debug-as debug
/home/craig/v8/test/mjsunit/mjsunit.js
/home/craig/v8/test/mjsunit/debug-evaluate-locals.js
--- CRASHED ---
=== release debug-evaluate-with ===                                 
Path: mjsunit/debug-evaluate-with
Command: /home/craig/v8/shell --expose-debug-as debug
/home/craig/v8/test/mjsunit/mjsunit.js
/home/craig/v8/test/mjsunit/debug-evaluate-with.js
--- CRASHED ---

etc.

:(

I'll close this for now and perhaps poke at the other crashes sometime to see if
I can figure anything out.

Thank you.