Closed Bug 1245783 Opened 4 years ago Closed 4 years ago

[GCC 6] Crashes rapidly in JIT engine, jit_test.py fails

Categories

(Core :: JavaScript Engine: JIT, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla49
Tracking Status
firefox47 --- affected

People

(Reporter: stransky, Assigned: jandem)

References

Details

When FF is built by GCC 6 (Fedora 24, gcc-6.0.0-0.9.fc24.x86_64) it crashes 1-2 mins after start. Build with "ac_add_options --disable-ion" makes FF usable again, although there are some failed test in jit_test.py.

Firefox 44, gcc 6.0, --disable-ion, jit_test.py:

Exit code: -11
FAIL - basic/bug1118996.js
Exit code: -11
FAIL - gc/bug-1146696.js
/home/komat/CVS/firefox/firefox-44.0/firefox-44.0/js/src/jit-test/tests/ion/bug909997.js:31:5 Error: Assertion failed: got 0, expected 1
Stack:
  @/home/komat/CVS/firefox/firefox-44.0/firefox-44.0/js/src/jit-test/tests/ion/bug909997.js:31:5
Exit code: 3
FAIL - ion/bug909997.js
FAILURES:
    --fuzzing-safe --no-threads --no-ion /home/komat/CVS/firefox/firefox-44.0/firefox-44.0/js/src/jit-test/tests/basic/bug1118996.js
    --no-ggc /home/komat/CVS/firefox/firefox-44.0/firefox-44.0/js/src/jit-test/tests/gc/bug-1146696.js
    /home/komat/CVS/firefox/firefox-44.0/firefox-44.0/js/src/jit-test/tests/ion/bug909997.js

Trunk, gcc 6.0, --enable-ion, jit_test.py:

Assertion failure: isDebuggerEvalFrame(), at /home/komat/tmp676-trunk-gtk3/src-light/js/src/vm/Stack.cpp:64
Exit code: -11
FAIL - auto-regress/bug1147907.js
Assertion failure: isDebuggerEvalFrame(), at /home/komat/tmp676-trunk-gtk3/src-light/js/src/vm/Stack.cpp:64
Exit code: -11
FAIL - basic/testGeneratorDieButScopeAlive.js
Assertion failure: isDebuggerEvalFrame(), at /home/komat/tmp676-trunk-gtk3/src-light/js/src/vm/Stack.cpp:64
Exit code: -11
FAIL - debug/Debugger-findScripts-17.js
Assertion failure: isDebuggerEvalFrame(), at /home/komat/tmp676-trunk-gtk3/src-light/js/src/vm/Stack.cpp:64
Exit code: -11
Assertion failure: isDebuggerEvalFrame(), at /home/komat/tmp676-trunk-gtk3/src-light/js/src/vm/Stack.cpp:64
Exit code: -11
FAIL - debug/Frame-eval-15.js
Assertion failure: isDebuggerEvalFrame(), at /home/komat/tmp676-trunk-gtk3/src-light/js/src/vm/Stack.cpp:64
Exit code: -11
FAIL - debug/Frame-eval-27.js
Assertion failure: isDebuggerEvalFrame(), at /home/komat/tmp676-trunk-gtk3/src-light/js/src/vm/Stack.cpp:64
Exit code: -11
FAIL - debug/Frame-eval-29.js
Assertion failure: isDebuggerEvalFrame(), at /home/komat/tmp676-trunk-gtk3/src-light/js/src/vm/Stack.cpp:64
Exit code: -11
FAIL - debug/Frame-evalWithBindings-03.js
Assertion failure: isDebuggerEvalFrame(), at /home/komat/tmp676-trunk-gtk3/src-light/js/src/vm/Stack.cpp:64
Exit code: -11
FAIL - debug/Frame-evalWithBindings-09.js
Assertion failure: isDebuggerEvalFrame(), at /home/komat/tmp676-trunk-gtk3/src-light/js/src/vm/Stack.cpp:64
Exit code: -11
FAIL - debug/Frame-evalWithBindings-14.js
Assertion failure: isDebuggerEvalFrame(), at /home/komat/tmp676-trunk-gtk3/src-light/js/src/vm/Stack.cpp:64
Exit code: -11
FAIL - debug/Frame-this-06.js
[...]
FAILURES:
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/auto-regress/bug1147907.js
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/basic/testGeneratorDieButScopeAlive.js
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/debug/Debugger-findScripts-17.js
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/debug/Frame-eval-07.js
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/debug/Frame-eval-15.js
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/debug/Frame-eval-27.js
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/debug/Frame-eval-29.js
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/debug/Frame-evalWithBindings-03.js
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/debug/Frame-evalWithBindings-09.js
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/debug/Frame-evalWithBindings-14.js
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/debug/Frame-this-06.js
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/debug/Frame-this-07.js
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/debug/Script-getAllColumnOffsets-02.js
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/debug/Script-getAllColumnOffsets-03.js
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/debug/Script-getAllColumnOffsets-04.js
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/debug/Script-getAllColumnOffsets-05.js
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/debug/Script-getAllColumnOffsets-06.js
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/debug/Script-getAllColumnOffsets-01.js
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/debug/Script-getLineOffsets-04.js
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/debug/bug1109964.js
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/debug/bug1130768.js
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/debug/bug1188334.js
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/debug/bug1232655.js
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/debug/onEnterFrame-03.js
    /home/komat/tmp676-trunk-gtk3/src-light/js/src/jit-test/tests/gc/bug-1104162.js
The isDebuggerEvalFrame assertion failure is likely bug 1246112. Debug only.

Not sure about the other failures.
Depends on: 1246112
It also crashes w/o debug enabled, in release builds we do for Fedora.
Looks like only optimized build crashes. For instance:

$./js /home/komat/CVS/firefox/firefox-44.0.1/firefox-44.0.1/js/src/jit-test/tests/arguments/args4.js

Assertion failure: !isFloat(), at /home/komat/CVS/firefox/firefox-44.0.1/firefox-44.0.1/js/src/jit/RegisterSets.h:47
(gdb) bt
#0  0x00005555557bb03c in js::jit::AnyRegister::gpr (this=this@entry=0x7fffecf19a90)
    at /home/komat/CVS/firefox/firefox-44.0.1/firefox-44.0.1/js/src/jit/RegisterSets.h:47
#1  0x000055555592c95a in js::jit::MacroAssembler::Push (this=this@entry=0x7ffff3cd9058, v=...)
    at /home/komat/CVS/firefox/firefox-44.0.1/firefox-44.0.1/js/src/jit/MacroAssembler.cpp:2404
#2  0x000055555592cafa in js::jit::MacroAssembler::Push (this=0x7ffff3cd9058, v=...)
    at /home/komat/CVS/firefox/firefox-44.0.1/firefox-44.0.1/js/src/jit/MacroAssembler.cpp:2414
#3  0x000055555580566c in js::jit::CodeGeneratorShared::pushArg<js::jit::ConstantOrRegister> (this=0x7ffff3cd9000, 
    this=0x7ffff3cd9000, t=...)
    at /home/komat/CVS/firefox/firefox-44.0.1/firefox-44.0.1/js/src/jit/shared/CodeGenerator-shared.h:428
#4  js::jit::CodeGenerator::visitGetPropertyIC (this=0x7ffff3cd9000, ool=0x7fffeb01bf80, ic=...)
    at /home/komat/CVS/firefox/firefox-44.0.1/firefox-44.0.1/js/src/jit/CodeGenerator.cpp:8548
#5  0x00005555558058b6 in js::jit::OutOfLineUpdateCache::visitGetPropertyIC (this=<optimized out>, codegen=<optimized out>)
    at /home/komat/CVS/firefox/firefox-44.0.1/firefox-44.0.1/js/src/jit/CodeGenerator.cpp:106
#6  0x00005555559a9dc3 in js::jit::CodeGeneratorShared::generateOutOfLineCode (this=this@entry=0x7ffff3cd9000)
    at /home/komat/CVS/firefox/firefox-44.0.1/firefox-44.0.1/js/src/jit/shared/CodeGenerator-shared.cpp:182
#7  0x0000555555a0c2d9 in js::jit::CodeGeneratorX86Shared::generateOutOfLineCode (this=this@entry=0x7ffff3cd9000)
    at /home/komat/CVS/firefox/firefox-44.0.1/firefox-44.0.1/js/src/jit/x86-shared/CodeGenerator-x86-shared.cpp:409
#8  0x000055555580de20 in js::jit::CodeGenerator::generate (this=this@entry=0x7ffff3cd9000)
    at /home/komat/CVS/firefox/firefox-44.0.1/firefox-44.0.1/js/src/jit/CodeGenerator.cpp:7907
#9  0x000055555581fdca in js::jit::GenerateCode (mir=mir@entry=0x7fffeb018270, lir=0x7fffeb01a480)
    at /home/komat/CVS/firefox/firefox-44.0.1/firefox-44.0.1/js/src/jit/Ion.cpp:1950
#10 0x000055555587fa58 in js::jit::CompileBackEnd (mir=mir@entry=0x7fffeb018270)
    at /home/komat/CVS/firefox/firefox-44.0.1/firefox-44.0.1/js/src/jit/Ion.cpp:1972
#11 0x0000555555be4544 in js::HelperThread::handleIonWorkload (this=this@entry=0x7ffff3c40200)
    at /home/komat/CVS/firefox/firefox-44.0.1/firefox-44.0.1/js/src/vm/HelperThreads.cpp:1294
#12 0x0000555555be7937 in js::HelperThread::threadLoop (this=0x7ffff3c40200)
    at /home/komat/CVS/firefox/firefox-44.0.1/firefox-44.0.1/js/src/vm/HelperThreads.cpp:1612
#13 0x00007ffff4f955db in _pt_root (arg=0x7ffff3c49380) at ../../../nspr/pr/src/pthreads/ptthread.c:212
#14 0x00007ffff7bc169a in start_thread (arg=0x7fffecf1a700) at pthread_create.c:333
#15 0x00007ffff41e4dbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Blocks: 1253216
My blind guess would be the same as what happened with gcc4.9, which is that gcc developers made some optimizations, which are not working as expected when used on our code base.

Would it be possible to bisect the set of compiler flags which are required to make the JS shell crash?
Flags: needinfo?(stransky)
Well, I suspect -flifetime-dse=2 (default option with -O1 and above), aka: https://bugzilla.mozilla.org/show_bug.cgi?id=1232696#c6

Thus I would try to add following flags to the default ones:
-flifetime-dse=1
-fno-delete-null-pointer-checks

Maybe there would be another problematic option:
https://gcc.gnu.org/gcc-6/porting_to.html

Martin
(In reply to Martin Liška from comment #5)
> Well, I suspect -flifetime-dse=2 (default option with -O1 and above), aka:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1232696#c6

Indeed, this kind of initialization is used by the allocator used in IonMonkey.  Still, we should consider it as a bug if we do not initialized these values our-self.

I guess we could change the pattern used for initializing the LifoAlloc used by IonMonkey and make sure that we properly initialize the memory after the fact.

Idependently of the placement new, I think we are doing the same kind of  memset  in the constructor of JSScript, which is a central point of the JS engine.

(In reply to Martin Liška from comment #5)
> -fno-delete-null-pointer-checks

I do not recall seeing any code which can have a null "this" pointer in our code base.
(In reply to Nicolas B. Pierron [:nbp] from comment #6)
> (In reply to Martin Liška from comment #5)
> > Well, I suspect -flifetime-dse=2 (default option with -O1 and above), aka:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1232696#c6
> 
> Indeed, this kind of initialization is used by the allocator used in
> IonMonkey.  Still, we should consider it as a bug if we do not initialized
> these values our-self.
> 
> I guess we could change the pattern used for initializing the LifoAlloc used
> by IonMonkey and make sure that we properly initialize the memory after the
> fact.
> 
> Idependently of the placement new, I think we are doing the same kind of 
> memset  in the constructor of JSScript, which is a central point of the JS
> engine.
> 
> (In reply to Martin Liška from comment #5)
> > -fno-delete-null-pointer-checks
> 
> I do not recall seeing any code which can have a null "this" pointer in our
> code base.

Please check UBSAN output here: https://bugzilla.mozilla.org/show_bug.cgi?id=996026#c3
I see couple of this pointer being null in the report

Martin
I see the same JIT crashes when built with -flifetime-dse=1.
Flags: needinfo?(stransky)
JIT also crashes with both -flifetime-dse=1 -fno-delete-null-pointer-checks.
Blocks: 1257055
Duplicate of this bug: 1256687
I can reproduce this with an --enable-debug --enable-optimize Linux x64 shell build.

    g++-6 (Ubuntu 6-20160319-0ubuntu11) 6.0.0 20160319 (experimental) [trunk revision 234350]

GCC 6 is miscompiling (the last part of) CodeGenerator::toConstantOrRegister:

    return TypedOrValueRegister(type, ToAnyRegister(value));

Annotated assembly below:

callq  0x617d30 <js::jit::ToAnyRegister(js::jit::LAllocation const&)>

// Get pointer to TypedOrValueRegister.
lea    -0x40(%rbp),%rdi

// Move ToAnyRegister return value to r13d.
mov    %eax,%r13d

// Store TypedOrValueRegister type_.
mov    %r12d,-0x40(%rbp)

callq  0x65aec0 <js::jit::TypedOrValueRegister::dataTyped()>

// ---> This load is bogus. I think GCC attempts to load the AnyRegister value stored
// to the TypedOrValueRegister pointer we just loaded, but it was never stored there
// so we read uninitialized memory.
mov    -0x38(%rbp),%rdx

// Store AnyRegister to dataTyped() return value.
mov    %r13d,(%rax)

// Load TypedOrValueRegister::type_ into rax.
mov    -0x40(%rbp),%rax

// ConstantOrRegister constructor.
// ---> this uses the bogus value in rdx
movb   $0x0,(%rbx)      // constant_ = false
mov    %rdx,0x10(%rbx)  // store TypedOrValueRegister data
mov    %rax,0x8(%rbx)   // store TypedOrValueRegister type_

mov    -0x28(%rbp),%rcx
xor    %fs:0x28,%rcx
mov    %rbx,%rax
jne    0x61edc1 <js::jit::CodeGenerator::toConstantOrRegister(js::jit::LInstruction*, unsigned long, js::jit::MIRType)+209>
add    $0x28,%rsp
pop    %rbx
pop    %r12
pop    %r13
pop    %rbp
retq
Can you please isolate the function and create a PR for GCC?

Thanks,
Martin
(In reply to Jan de Mooij [:jandem] from comment #11)

I forgot to mention that the bogus load here:

  mov    -0x38(%rbp),%rdx

Reads memory that's initialized by the next instruction:

  // Store AnyRegister to dataTyped() return value.
  mov    %r13d,(%rax)

(If the second instruction came before the first, everything would be fine probably.)
(In reply to Martin Liška from comment #12)
> Can you please isolate the function and create a PR for GCC?

I'll try that next, but I've no idea how hard it will be and I've other bugs to work on..
I filed a GCC bug with a minimal testcase:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70526
gcc-6.0.0-0.20.fc24.x86_64 on Fedora 24 should contain a fix for 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70526 bug JS keeps crashing when JIT is enabled (and so Firefox). 

But the crash-rate is much better and also the JIT test produces less errors then before, but some test still fails with a crash. Can anyone else confirm the fix?
(In reply to Martin Stránský from comment #16)
> But the crash-rate is much better and also the JIT test produces less errors
> then before, but some test still fails with a crash. Can anyone else confirm
> the fix?

Do you have a stack trace for this? Does an --enable-debug --enable-optimize build also fail?
It's easy to reproduce from the jit-tests.

for instance js js/src/jit-test/tests/auto-regress/bug675251.js crashes right away.

bt:

#0  0x00007ffff3c5b800 in ?? ()
#1  0x00005555557ef3a7 in js::jit::SnapshotIterator::numAllocations (this=0x7fffffefdf00)
    at /home/komat/CVS/firefox/firefox-45.0.1/firefox-45.0.1/js/src/jit/JitFrames.cpp:2159
#2  js::jit::IonFrameStackDepthOp::IonFrameStackDepthOp (frame=..., this=<optimized out>)
    at /home/komat/CVS/firefox/firefox-45.0.1/firefox-45.0.1/js/src/jit/JitFrames.cpp:421
#3  js::jit::TryNoteIterIon::TryNoteIterIon (frame=..., cx=0x7ffff3c19000, this=0x7fffffefdec0)
    at /home/komat/CVS/firefox/firefox-45.0.1/firefox-45.0.1/js/src/jit/JitFrames.cpp:431
#4  js::jit::HandleExceptionIon (overrecursed=0x7fffffefddaf, rfe=0x7fffffefe368, frame=..., cx=0x7ffff3c19000)
    at /home/komat/CVS/firefox/firefox-45.0.1/firefox-45.0.1/js/src/jit/JitFrames.cpp:478
#5  js::jit::HandleException (rfe=0x7fffffefe368)
    at /home/komat/CVS/firefox/firefox-45.0.1/firefox-45.0.1/js/src/jit/JitFrames.cpp:853
#6  0x00007ffff7fe6162 in ?? ()
#7  0x00007fffeb2c8740 in ?? ()
#8  0x00007fffffefe368 in ?? ()
#9  0x00007ffffffec7c0 in ?? ()
#10 0x0000000000000000 in ?? ()
Correct FF backtrace, looks like the one from jit-tests:

(gdb) up
#1  js::jit::TryNoteIterIon::TryNoteIterIon (frame=..., cx=0x7fffdb586800, this=0x7fffffff7440)
    at /usr/src/debug/firefox-45.0.1/firefox-45.0.1/js/src/jit/JitFrames.cpp:431
#2  js::jit::HandleExceptionIon (overrecursed=0x7fffffff732f, rfe=0x7fffffff78e8, frame=..., cx=0x7fffdb586800)
    at /usr/src/debug/firefox-45.0.1/firefox-45.0.1/js/src/jit/JitFrames.cpp:478
#3  js::jit::HandleException (rfe=0x7fffffff78e8)
    at /usr/src/debug/firefox-45.0.1/firefox-45.0.1/js/src/jit/JitFrames.cpp:853
--enable-debug, --enable-optimize produces this crash, actually the same as in comment 3:

46	    Register gpr() const {
47	        MOZ_ASSERT(!isFloat());
48	        return Register::FromCode(code_);

#0  js::jit::AnyRegister::gpr (this=<optimized out>)
    at /home/komat/CVS/firefox/firefox-45.0.2/firefox-45.0.2/js/src/jit/RegisterSets.h:47
#1  js::jit::MacroAssembler::storeTypedOrValue<js::jit::Address> (dest=..., src=..., this=0x7ffff3cc8058)
    at /home/komat/CVS/firefox/firefox-45.0.2/firefox-45.0.2/js/src/jit/MacroAssembler.h:900
#2  js::jit::MacroAssembler::storeConstantOrRegister<js::jit::Address> (this=0x7ffff3cc8058, src=..., dest=...)
    at /home/komat/CVS/firefox/firefox-45.0.2/firefox-45.0.2/js/src/jit/MacroAssembler.h:920
#3  0x000055555583f1f1 in js::jit::CodeGenerator::visitStoreFixedSlotT (this=0x7ffff3cc8000, ins=<optimized out>)
    at /home/komat/CVS/firefox/firefox-45.0.2/firefox-45.0.2/js/src/jit/CodeGenerator.cpp:8580
#4  0x0000555555856ac7 in js::jit::CodeGenerator::generateBody (this=this@entry=0x7ffff3cc8000)
    at /home/komat/CVS/firefox/firefox-45.0.2/firefox-45.0.2/js/src/jit/CodeGenerator.cpp:4263
#5  0x0000555555857886 in js::jit::CodeGenerator::generate (this=this@entry=0x7ffff3cc8000)
    at /home/komat/CVS/firefox/firefox-45.0.2/firefox-45.0.2/js/src/jit/CodeGenerator.cpp:7999
#6  0x0000555555864b3a in js::jit::GenerateCode (mir=mir@entry=0x7fffeb11a270, lir=0x7fffeb11be38)
    at /home/komat/CVS/firefox/firefox-45.0.2/firefox-45.0.2/js/src/jit/Ion.cpp:1974
#7  0x00005555558bdb44 in js::jit::CompileBackEnd (mir=mir@entry=0x7fffeb11a270)
    at /home/komat/CVS/firefox/firefox-45.0.2/firefox-45.0.2/js/src/jit/Ion.cpp:1996
#8  0x0000555555c23114 in js::HelperThread::handleIonWorkload (this=this@entry=0x7ffff3c40200)
    at /home/komat/CVS/firefox/firefox-45.0.2/firefox-45.0.2/js/src/vm/HelperThreads.cpp:1264
#9  0x0000555555c26a87 in js::HelperThread::threadLoop (this=0x7ffff3c40200)
    at /home/komat/CVS/firefox/firefox-45.0.2/firefox-45.0.2/js/src/vm/HelperThreads.cpp:1582
#10 0x00007ffff4f997df in _pt_root (arg=0x7ffff3c6a380) at ../../../nspr/pr/src/pthreads/ptthread.c:216
#11 0x00007ffff7bc458a in start_thread (arg=0x7fffed08c700) at pthread_create.c:333
#12 0x00007ffff41ee5cd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
This is what building with GCC 6.1 looks on automation:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=20df2b5901930713f5a14504121545ce235da18f

It's not pretty.

This is the tooltool manifest change required to use GCC 6.1 on automation for anyone who would want to try it some more:
https://hg.mozilla.org/try/diff/20df2b590193/browser/config/tooltool-manifests/linux64/releng.manifest

I didn't try to disable lifetime DSE yet.
It looks equally bad with -fno-lifetime-dse -fno-delete-null-pointer-checks:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=86d7709526d4ddacaac38fd3b31cbdb0b900b2a6
I'll take another look at this. If it turns out to be another GCC 6 bug that will be disappointing though...
The crash is very similar to the last one, and my original test case for the GCC bug still fails. It looks like either it wasn't fixed completely, or there is also a problem in our code.
(In reply to Julian Seward [:jseward] from comment #26)
> Jan, can you try the patch at 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1232696#c16 ?

I'm building and testing just the JS shell, so no xpcom :)
Depends on: 1269319
Duplicate of this bug: 1272944
I cannot see how CodeGenerator::toConstantOrRegister() (see Comment 11) is executed within the stack trace reported at Comment 21 and in Bug 1272944.

Also gcc bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70526 that has been opened from this bug does not seem to propose a valid fix with respect to this bug, despite being currently marked as RESOLVED FIXED.

Debugging and resolution of this problem do not seem to me on the right track...
However, I found that the referenced gcc bug provides a possible workaround: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70526#c14

So, I am testing the following Makefile patch with gcc6 and it seems to build a working firefox:

--- firefox-45.0.1-orig/js/src/Makefile.in	2016-05-17 14:53:58.753178403 +0200
+++ firefox-45.0.1/js/src/Makefile.in	2016-05-17 14:53:28.432817862 +0200
@@ -144,6 +144,11 @@ distclean::
 
 CFLAGS += $(MOZ_ZLIB_CFLAGS)
 
+# Avoid GNU gcc bug #70526
+# https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70526#c14
+CFLAGS += -fno-schedule-insns2
+CXXFLAGS += -fno-schedule-insns2
+
 # Silence warnings on AIX/HP-UX from non-GNU compilers
 ifndef GNU_CC
 ifeq ($(OS_ARCH),AIX)
With the "-fno-schedule-insns2" the jit-test passes cleanly, Thanks!
Try seems to say we're good with "-fno-schedule-insns2 -fno-delete-null-pointer-checks" (-fno-schedule-insns2 still has plenty of broken tests):
https://treeherder.mozilla.org/#/jobs?repo=try&revision=19e8885a104a5ef99cbd0d4a3ad0305f96cfff2a
Would you mind waiting till I land bug 1269319? I hope that will take care of at least the 'schedule-insns2' failures...

I'll try to get that landed today.
Depends on: 1269317
jit-tests pass for me with GCC 6 + the patches for bug 1269319 and bug 1245783.

I'll try to get those backported.
(In reply to Jan de Mooij [:jandem] from comment #35)
> jit-tests pass for me with GCC 6 + the patches for bug 1269319 and bug
> 1245783.

Er, bug 1269319 and bug 1269317.
Flags: needinfo?(jdemooij)
Duplicate of this bug: 1275199
Requested uplift of bug 1269319 and bug 1269317 to Aurora and ESR45.

Marking this fixed as the JS tests pass now.
Assignee: nobody → jdemooij
Status: NEW → RESOLVED
Closed: 4 years ago
Flags: needinfo?(jdemooij)
Resolution: --- → FIXED
Target Milestone: --- → mozilla49
Blocks: 1316555
You need to log in before you can comment on or make changes to this bug.