[Webkit-unassigned] [Bug 15416] dtoa Falls into infinite loop on ARMEL

[bugzilla-daemon at webkit.org]

http://bugs.webkit.org/show_bug.cgi?id=15416





------- Comment #15 from david.krause at gmail.com  2008-03-18 06:42 PDT -------
The last patch (r31115) may not provide correct behavior for all ARM platforms. 

It seems that __ARMEL__ isn't enough to define the layout of the floating-point
doubles.  On the particular platform we're working on, the layout does actually
match that shown by MIDDLE_ENDIAN in JavaScriptCore/kjs/vaue.cpp, even though
__ARMEL__ is defined.

Not an expert on the different ARM floating-point layouts (FPA vs. VFP), but
the actual arrangement of the bytes varies - FPA is the "middle endian" format
as it's called by WebKit, and VFP is "natural endian".

In our particular case, we still want MIDDLE_ENDIAN defined to get the proper
behavior in the two places it's used (value.cpp and dtoa.cpp) since we are
using FPA.  Some other searching turns up that the pre-processor define of
__SOFTFP__  might be good enough to trigger that.  Our arm-linux-gcc does
defines that, but the original bug report didn't have that or __VFP_FP__
defined.

If a change is warranted at all in Platform.h, having only our compiler here,
I'd use __SOFTFP__ and __ARMEL__ to enable the WTF_PLATFORM_MIDDLE_ENDIAN
define, but I'm not sure if that will break for those using VFP.  Maybe this at
line 151 in Platform.h:

#elif !defined(__ARM_EABI__) && !defined(__ARMEB__) && defined(__ARMEL__) &&
defined(__SOFTFP__)

Backing out the change in Platform.h would also likely work, and not affect
anyone that wasn't already having issues.

Sorry if my previous post (#13) led to confusion, but the net result is that
the r31115 change will probably break ARM systems using FPA.


-- 
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.