Closed Bug 136100 Opened 24 years ago Closed 24 years ago

Numerical calculation incorrect on ARM with kernel v2.4.5

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Platform:
Other
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED WORKSFORME

People

(Reporter: nicolas, Assigned: khanson)

Details

Here is my problem : I run the engine on my PC and on ARM platform, but the results are differents. I have traced the problem down to this small script : char *script = "-1248700309&0xFFFF"; The return value on the PC is 22635, which is correct. The same script on ARM return 22636. I use the engine from Mozilla's 0-9-8 release.
Well, yeah. Don't ARMs use 1's complement instead of 2's complement for negation? I don't know if the JS spec mandates a particular signed complement.
I think it's 2's complement for arm too (0xff for -1). And the problem just appears for this particuliar value (-1248700309), not for all negative values.
Why is this a "blocker"???
I've tried to have some answers in the jseng newsgroup, but nobody cared. So I've written this bug ... with a blocker severity. Obviously, it's a blocker only for me : I cannot login to yahoo mail because of incorrect encryption of the password. (I don't use Mozilla, but another browser). The platform is Arm, but on the whole bunch of site I've tested so far, it's the first time I have this kind of platform dependent error in the js engine. You can change its severity to whatever it should be.
severity=>major blocker means it blocks development of Mozilla.
Severity: blocker → major
Ok, I looked through their data sheets and it does appear that arithmetic uses 2's complement on the ARM. I was just seriously confused after reading MVN and CMN. Anyway, could you try evaluating the following expressions on an ARM: 1 & 0xFFFF -1 & 0xFFFF 1248700309 & 0xFFFF -1248700309 & 0xFFFF -(1248700309 & 0xFFFF) & 0xFFFF -(0xA795 & 0xFFFF) & 0xFFFF -0xA795 & 0xFFFF -0x586B & 0xFFFF -(-0x586B & 0xFFFF) & 0xFFFF which should be 1 65535 42901 22635 22635 22635 42901 22635
[1 & 0xFFFF] result: 1 [-1 & 0xFFFF] result: 65535 [1248700309 & 0xFFFF] result: 42901 [-1248700309 & 0xFFFF] result: 22636 [-(1248700309 & 0xFFFF) & 0xFFFF] result: 22635 [-(0xA795 & 0xFFFF) & 0xFFFF] result: 22635 [-0xA795 & 0xFFFF] result: 22635 [-0x586B & 0xFFFF] result: 42901 [-(-0x586B & 0xFFFF) & 0xFFFF] result: 22635
> I cannot login to Yahoo mail because of incorrect encryption of the password. Compare bug 121115, "Cannot login to Yahoo! mail when JavaScript enabled " cc'ing Dan and Andrew from that bug; cc'ing Brendan, Mike. Is this bug related? The other one occurred on a 64-bit platform, right?
Assignee: rogerl → khanson
Formally confirming to get this on the radar screen -
Status: UNCONFIRMED → NEW
Ever confirmed: true
I don't think it's the same as 1248700309 is larger than any number Javascript-Alpha-Linux could represent. Nicolas: try out attachment 71504 [details] and compare with bug 121115 comment 18 what compiler are you using?
Mozilla 20020327, Linux-Alpha. <script > var i=-1248700309&0xFFFF; alert(i); </script> ==>22635
Debian Linux/ARM on a Netwinder js> 1248700309 & 0xFFFF 42901 js> -1248700309 & 0xFFFF 22635 js> -(1248700309 & 0xFFFF) & 0xFFFF 22635 crichton@tegan:/opt/mozilla/mozilla/dist/bin$ gcc -v Reading specs from /usr/lib/gcc-lib/arm-linux/2.95.4/specs gcc version 2.95.4 (Debian prerelease) crichton@tegan:/opt/mozilla/mozilla/dist/bin$ uname -a Linux tegan 2.4.18-rmk1 #1 Sun Mar 3 10:18:08 EST 2002 armv4l unknown This also worked with a really old 0.9.8 era CVS tree with the same compiler. Sorry, forgot the date on the tree (it was before all the xpcall landings for ARM, however).
Whoops. I also forgot to mention the above was done with a nightly source pull off of the trunk.
> It was before all the xpcall landings for ARM, however Mark: do you recall any bug numbers or contributors for these landings? If so, I can cc them on this bug. Thanks -
Bug #106864 The xptcall reference was more of me trying to put a date on my old CVS tree. The results are from a nightly I pulled today. One thing I am missing, however, are some compiler/system specifics. What compiler (gcc -v) version was used for the build, and what version of the ARM/Linux kernel is running. Also, was this a cross compile. Reason I ask is I've had problems with certain versions of gcc on the arm. For example, g++-3.0 on ARM I think is still iffy at best. Cross builds are also problematic, but I see most of that in NSS...
Mark: thanks. cc'ing folks from bug 106864
The range of signed 32-bit integers is -2147483648 to 2147483647, i.e., -(2^31) to (2^31) - 1 "-1248700309&0xFFFF" The range of unsigned 32-bit integers is 0 to 4294967295, i.e., 0 to (2^32) - 1 The range of consecutive representable integers in the double formats is - 18014398509481983 to 18014398509481983, i.e., -((2^54) - 1) to (2^54) - 1 In the expression "-1248700309&0xFFFF" the value -1248700309 should convert exactly into a double. The double value should convert exactly into a 32 bit int. The & operator is exact. The result can be stored exactly in an int or doulbe. The conversion to string should be exact prducing, 22635. One of these steps is going awray in the ARM environment.
Ugh, better format! In the expression "-1248700309&0xFFFF" the string "-1248700309" should convert exactly into a double. The double value should convert exactly into a 32-bit int. The & operator is exact. The result can be stored exactly in an int or double. The conversion to string should be exact producing the string, "22635". One of these steps is going awray in the ARM environment.
From attachment 71504 [details] : max uint = 4294967298 max uint+1=4294967298 max int = 4294967296 max int+1=4294967296 Reading specs from /usr/local/arm/lib/gcc-lib/arm-linux/2.95.2/specs gcc version 2.95.2 19991024 (release)
Executing in 'javascript:' the test from comment 11 : Using gcc-3.0.4 (+arm float reload patch (bug target/5228) on arm for mozilla 0.9.8 + patches for bug 106864, bug 87965 and bug 9519, I get '22635'... For mozilla 0.9.9 + patches for the same bugs where needed, I also get '22635'... Maybe time to upgrade the compiler ??
I've tried with gcc 3.0.4 [Reading specs from /usr/local/armv3/bin/../lib/gcc-lib/arm-linux/3.0.4/specs Configured with: ./configure --target=arm-linux --prefix=/usr/local/arm --with-headers=/usr/local/arm/include --enable-shared --enable-languages=c c++ Thread model: posix gcc version 3.0.4] on 0-9-8 with the patch for 106864 about the engine (jsnum.h) and the result is the same. I don't know where to find the "arm float reload patch (bug target/5228)" though. Could it be related to some compilation options for the js engine ? Mine are : arm-linux-gcc -o Linux_All_DBG.OBJ/jsarena.o -c -Wall -Wno-format -g -DXP_UNIX -DSVR4 -DSYSV -D_BSD_SOURCE -DPOSIX_SOURCE -DX86_LINUX -DDEBUG -DDEBUG_nicolas -DEDITLINE -ILinux_All_DBG.OBJ jsarena.c
If you don't have the 'float reload' patch in your gcc-3.0.4 (or didn't recompile glibc, and maybe other libraries), all results based on floats/doubles should be taken with a largepile of salt (? een extreem grote korrel/hoop zout) : as this could/would corrupt floating point registers (or the emulated version of them). You can find a patch for gcc at <http://gcc.gnu.org/ml/gcc-patches/2002-03/msg00829.html>
Correction to comment #17 The range of consecutive representable integers in the double formats is - 18014398509481984 to 18014398509481984, i.e., -2^54 to 2^54
Based on Comment #20 and the comments following, this seems to be a gcc-related issue, not a JS Engine one. Thus I'm going to resolve this bug as WORKSFORME. Nicolas, do you agree? If so, could you mark this bug "Verified"? If not, you can reopen the bug; thanks -
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Updating summary to make this bug easier to search for. Please correct me if I don't have it quite right. Changing from: "Calculation is false" to: "Numerical calculation incorrect on ARM [gcc compiler bug]"
Summary: Calculation is false → Numerical calculation incorrect on ARM [gcc compiler bug]
An update to a typo in comment 20 : the float reload bug of gcc (arm target) is described in target/5828, _not_ in target/5228. A link to a patch for it can be found in comment 22
I've updated my gcc, patched it, but the problem was still here. I've put a few printf in the js interpreter and finally found an addition (double + double) whose result differs from the correct one. The problem seems to be in the floating point emulator, rather than in gcc. My kernel is quite old (2.4.5), and a quick test on a 2.4.16 shows that the problem disappears ( for whatever gcc version ). This bug is verified. Thanks for your help and comments.
Status: RESOLVED → VERIFIED
Nicolas, thanks! Based on your findings, I'm updating the summary - From: "Numerical calculation incorrect on ARM [gcc compiler bug]" To: "Numerical calculation incorrect on ARM with kernel v2.4.5"
Summary: Numerical calculation incorrect on ARM [gcc compiler bug] → Numerical calculation incorrect on ARM with kernel v2.4.5
You need to log in before you can comment on or make changes to this bug.