So while it doesn't happen for any of the build environments we test on, Jonathan Kew reported an internal compiler error resulting from the landing of the first eight parts of bug 913586 that seems worth fixing if we can. Here's his comment, originally posted as bug 913586 comment 52: >FTR, this appears to have broken my local build (on Mac OS X 10.7.5, clang from MacPorts, debug build of Gecko); it dies with an internal compiler error: > >28:09.89 Invalid operator call kind >28:09.89 UNREACHABLE executed at StmtProfile.cpp:566! >28:09.94 0 libLLVM-3.4.dylib 0x0000000103690936 llvm::sys::PrintStackTrace(__sFILE*) + 40 >28:09.94 1 libLLVM-3.4.dylib 0x0000000103690d3d _ZL13SignalHandleri + 241 >28:09.94 2 libsystem_c.dylib 0x00007fff85ca9cfa _sigtramp + 26 >28:09.94 3 libsystem_c.dylib 000000000000000000 _sigtramp + 2050319136 >28:09.94 4 libLLVM-3.4.dylib 0x0000000103690bb5 abort + 22 >28:09.94 5 libLLVM-3.4.dylib 0x0000000103681f2e LLVMInstallFatalErrorHandler + 0 >28:09.94 6 clang 0x00000001020b35a7 clang::StmtVisitorBase<clang::make_const_ptr, (anonymous namespace)::StmtProfiler, void>::Visit(clang::Stmt const*) + 4851 >28:09.94 7 clang 0x00000001020b3db9 (anonymous namespace)::StmtProfiler::VisitStmt(clang::Stmt const*) + 153 >28:09.94 8 clang 0x00000001020b2e36 clang::StmtVisitorBase<clang::make_const_ptr, (anonymous namespace)::StmtProfiler, void>::Visit(clang::Stmt const*) + 2946 >28:09.94 9 clang 0x00000001020b3db9 (anonymous namespace)::StmtProfiler::VisitStmt(clang::Stmt const*) + 153 >28:09.94 10 clang 0x00000001020b239c clang::StmtVisitorBase<clang::make_const_ptr, (anonymous namespace)::StmtProfiler, void>::Visit(clang::Stmt const*) + 232 >28:09.94 11 clang 0x00000001020b3db9 (anonymous namespace)::StmtProfiler::VisitStmt(clang::Stmt const*) + 153 >28:09.94 12 clang 0x00000001020b23c0 clang::StmtVisitorBase<clang::make_const_ptr, (anonymous namespace)::StmtProfiler, void>::Visit(clang::Stmt const*) + 268 >28:09.94 13 clang 0x00000001020b22ae clang::Stmt::Profile(llvm::FoldingSetNodeID&, clang::ASTContext const&, bool) const + 34 ><...and many more frames...> > >28:10.00 0. Program arguments: /opt/local/libexec/llvm-3.4/bin/clang -cc1 -triple x86_64-apple-macosx10.6.0 -emit-obj -mrelax-all -disable-free -main-file-name RegExp.cpp -mrelocation-model pic -pic-level 2 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 236.3 -gdwarf-2 -coverage-file /Users/jkew/mozdev/mc-clean/obj-ff-dbg/js/src/RegExp.o -resource-dir /opt/local/libexec/llvm-3.4/bin/../lib/clang/3.4.2 -dependency-file .deps/RegExp.o.pp -MT RegExp.o -sys-header-deps -MP -include ../../js/src/js-confdefs.h -D FFI_BUILDING -D ENABLE_PARALLEL_JS -D ENABLE_BINARYDATA -D ENABLE_SHARED_ARRAY_BUFFER -D JSGC_FJGENERATIONAL -D EXPORT_JS_API -D JS_HAS_CTYPES -D DLL_PREFIX="lib" -D DLL_SUFFIX=".dylib" -D USE_SYSTEM_MALLOC=1 -D ENABLE_ASSEMBLER=1 -D AB_CD= -D NO_NSPR_10_SUPPORT -D MOZILLA_CLIENT -D DEBUG -D TRACING -I /Users/jkew/mozdev/mc-clean/js/src -I . -I /Users/jkew/mozdev/mc-clean/js/src/../../mfbt/double-conversion -I ctypes/libffi/include -I /Users/jkew/mozdev/mc-clean/intl/icu/source/common -I /Users/jkew/mozdev/mc-clean/intl/icu/source/i18n -I ../../dist/include -I /Users/jkew/mozdev/mc-clean/obj-ff-dbg/dist/include/nspr -Wall -Wpointer-arith -Woverloaded-virtual -Werror=return-type -Werror=int-to-pointer-cast -Wtype-limits -Wempty-body -Werror=conversion-null -Wsign-compare -Wno-invalid-offsetof -Wno-c++0x-extensions -Wno-extended-offsetof -Wno-unknown-warning-option -Wno-return-type-c-linkage -std=gnu++0x -fdeprecated-macro -fdebug-compilation-dir /Users/jkew/mozdev/mc-clean/obj-ff-dbg/js/src -ferror-limit 19 -fmessage-length 0 -fvisibility hidden -pthread -stack-protector 1 -mstackrealign -fblocks -fno-rtti -fobjc-runtime=macosx-10.6.0 -fencode-extended-block-signature -fno-common -fdiagnostics-show-option -vectorize-slp -o RegExp.o -x c++ /Users/jkew/mozdev/mc-clean/js/src/builtin/RegExp.cpp > > >Obviously, this isn't happening in automation, so it's some kind of local issue; time to try updating my compiler, I suppose. Unfortunately, MacPorts thinks what I have is current, so I'll have to try some other approach. > >(Tried the MacPorts versions of clang 3.3, 3.4.2, and 3.6, and all three fail similarly.)

Based on what Jonathan told me on IRC, the ICE was at this line: http://mxr.mozilla.org/mozilla-central/source/js/src/gc/Zone.h#420 I strongly suspect the problem here is an interaction between |Maybe<T>::operator->()| and ValidateAssertConditionType() in |mfbt/Assertions.h|. In other words, there is probably a bad interaction between bug 920292 and this bug for the particular build environment that Jonathan is using. Jonathan, if you get a chance, could you try commenting out the contents of |ValidateAssertConditionType()| and see if the problem goes away? If so, could you try commenting out the individual conditions so we can figure out which one it is? It may be that the real fix here needs to happen in Assertions.h. At any rate, if we can't figure out a fix, we know that changing |JS_ASSERT(!comp->done())| to |JS_ASSERT(!comp.ref().done())| fixes it, so it's a simple matter to resolve the problem either way. I'd prefer to fix the underlying issue, though.

(In reply to Seth Fowler [:seth] from comment #1) > Based on what Jonathan told me on IRC, the ICE was at this line: > > http://mxr.mozilla.org/mozilla-central/source/js/src/gc/Zone.h#420 > > I strongly suspect the problem here is an interaction between > |Maybe<T>::operator->()| and ValidateAssertConditionType() in > |mfbt/Assertions.h|. In other words, there is probably a bad interaction > between bug 920292 and this bug for the particular build environment that > Jonathan is using. That sounds correct, I think. > Jonathan, if you get a chance, could you try commenting out the contents of > |ValidateAssertConditionType()| and see if the problem goes away? Commenting out the contents (or removing it entirely) does NOT resolve the problem; but commenting out the call to MOZ_VALIDATE_ASSERT_CONDITION_TYPE in MOZ_ASSERT_HELPER1 does resolve it. So it looks to me like clang (some versions, at least) chokes on the use of <decltype(x)> with Maybe<T>::operator->(), even when the template using <decltype(x)> is completely empty and doesn't try to do anything with it.

FWIW, here's another observation: at the problematic call site in http://mxr.mozilla.org/mozilla-central/source/js/src/gc/Zone.h#420, if I explicitly cast |comp| to its declared type, with something like JS_ASSERT(!static_cast<mozilla::Maybe<CompartmentsInZoneIter>>(comp)->done()); then the error goes away. Which makes no sense... except that it seems to support the idea that it's decltype getting confused, and explicitly putting the type here helps it to avoid the confusion.

I looked into this extensively, and I just don't see a workaround other than disabling bug 920292 for some versions of clang, which I don't think we want to do. There are some very bugged |decltype()| implementations out there, unfortunately. If I can find the time I'll try to put together a minimal testcase and see if we can get this fixed in clang upstream. For now though, I think the original workaround we found this morning is the best bet. It's semantically identical to the other version, but it uses |.ref().| instead of |->|, which avoids the bug because the bug is specifically related to the handling of type-dependent overloads of|operator->()| in clang's front end.

Here's the insanely trivial patch that fixes the bug.

Comment on attachment 8474039 [details] [diff] [review] Avoid clang internal compiler error in Zone.h Review of attachment 8474039 [details] [diff] [review]: ----------------------------------------------------------------- Yes, this fixes the build for me, thanks.

Nice. Pushed: https://hg.mozilla.org/integration/mozilla-inbound/rev/ea9d82ca5387

I filed a LLVM bug: http://llvm.org/bugs/show_bug.cgi?id=20707