552650 - Solaris SPARC fails

Status: VERIFIED DUPLICATE of bug 551173

(Tamarin Graveyard :: Baseline JIT (CodegenLIR), defect)

Description

[Brent Baker]

Not sure exactly what has started to cause this issue but it started around the time that the verifier change came into tamarin-redux-argo (which I think also contained a merge from nanojit-central).

This failure is happening in both tr and tr-argo (NOTE: in tr you still need to apply patch http://hg.mozilla.org/projects/nanojit-central/rev/3b1d24a51ce4 to compile on sparc, as of tr rev4030)

Running most acceptance testcases results in the following error:
test/acceptance/ecma3/Date/e15_9_5_4.abc

15.9.5.4 Date.prototype.toTimeString()
t@1 (l@1) signal SEGV (no mapping at the fault address) in nanojit::LIns::opcode at line 400 in file "LIR.h"
  400           LOpcode opcode() const { return lastWord.opcode; }

Comment 1

[Brent Baker]

There is another SPARC tracking bug #551173 for acceptance failures, it does not appear to be the same issue to me but cross commenting anyways.

Comment 2

[Brent Baker]

Same error happens in TR and TR-Argo, just code location is slightly different, but same code:

TR-Argo:
t@1 (l@1) signal SEGV (no mapping at the fault address) in nanojit::LIns::opcode at line 400 in file "LIR.h"
  400           LOpcode opcode() const { return lastWord.opcode; }

TR:
t@1 (l@1) signal SEGV (no mapping at the fault address) in nanojit::LIns::opcode at line 493 in file "LIR.h"
  493           LOpcode opcode() const { return lastWord.opcode; }

Comment 3

[Leon Sha]

I just confirmed, it is the same bug as bug 551173. In mozilla tree we use -xO2 to compile Assembler.cpp instead of -xO5 as a workaround.