We see this in our CI too, but I haven't looked at the details yet. It might have come thru an upstream change at the beginning of October, will try bisecting. I don't think there has been an upstream report for it yet.

and the winner is https://bugzilla.mozilla.org/show_bug.cgi?id=1609381 (Wasm SIMD for arm64 baseline), not confirmed by a build yet as it's still in progress

and it might be another C++ standards related issue with g++ vs clang, I have found eg. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85282

Jon, Jakub, could you give us your opinion? The code in question start at https://github.com/mozilla/gecko-dev/blob/master/js/src/wasm/WasmBaselineCompile.cpp#L662

Yes, it's GCC PR 85282.

The code was not valid in C++14. It is valid now but GCC doesn't implement it yet.

If mozilla code is written in C++14 (or wants to be portable to older compilers) then it shouldn't really depend on that feature.

Seems they use C++17 and clang, so their position is "patches welcome", please see https://bugzilla.mozilla.org/show_bug.cgi?id=1677690#c1

FWIW the latest Intel compiler doesn't support this either. MSVC and Clang support it.

Here's a completely untested patch:
https://github.com/mozilla/gecko-dev/compare/master...jwakely:patch-1

If that works I can create the pull request.

The patch is https://github.com/mozilla/gecko-dev/commit/58acf75f7ddc80f4139869c415ffef84540e0d1b.patch

awesome, most of the issue went away, but there is still one

...
 0:50.65 /usr/bin/g++ -std=gnu++17 -o Unified_cpp_js_src_wasm0.o -c  -I/home/sharkcz/projects/firefox/obj-aarch64-unknown-linux-gnu/dist/system_wrappers -include /home/sharkcz/projects/firefox/config/gcc_hidden.h -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong -DNDEBUG=1 -DTRIMMED=1 -DWASM_SUPPORTS_HUGE_MEMORY -DJS_CACHEIR_SPEW -DJS_STRUCTURED_SPEW -DJS_HAS_CTYPES -DFFI_BUILDING -DEXPORT_JS_API -DMOZ_HAS_MOZGLUE -I/home/sharkcz/projects/firefox/js/src/wasm -I/home/sharkcz/projects/firefox/obj-aarch64-unknown-linux-gnu/js/src/wasm -I/home/sharkcz/projects/firefox/obj-aarch64-unknown-linux-gnu/js/src -I/home/sharkcz/projects/firefox/js/src -I/home/sharkcz/projects/firefox/obj-aarch64-unknown-linux-gnu/dist/include -I/home/sharkcz/projects/firefox/obj-aarch64-unknown-linux-gnu/dist/include/nspr -fPIC -DMOZILLA_CLIENT -include /home/sharkcz/projects/firefox/obj-aarch64-unknown-linux-gnu/js/src/js-confdefs.h -Wall -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings -Wno-invalid-offsetof -Wc++2a-compat -Wduplicated-cond -Wimplicit-fallthrough -Wunused-function -Wunused-variable -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=coverage-mismatch -Wno-error=free-nonheap-object -Wno-multistatement-macros -Wno-error=class-memaccess -Wno-error=deprecated-copy -Wformat -Wformat-overflow=2 -Werror=implicit-function-declaration -Wno-psabi -fno-sized-deallocation -fno-aligned-new -fno-rtti -fno-exceptions -fno-math-errno -pthread -pipe -g -freorder-blocks -O3 -fno-omit-frame-pointer -funwind-tables -fno-strict-aliasing -Werror=format -Wno-shadow -Wno-attributes  -MD -MP -MF .deps/Unified_cpp_js_src_wasm0.o.pp  -fdiagnostics-color  Unified_cpp_js_src_wasm0.cpp
 0:50.66 cc1plus: warning: ‘-Werror=’ argument ‘-Werror=implicit-function-declaration’ is not valid for C++
 1:01.49 In file included from /home/sharkcz/projects/firefox/js/src/vm/Activation.h:25,
 1:01.49                  from /home/sharkcz/projects/firefox/js/src/vm/JSContext.h:28,
 1:01.49                  from /home/sharkcz/projects/firefox/js/src/vm/GlobalObject.h:33,
 1:01.49                  from /home/sharkcz/projects/firefox/js/src/frontend/CompilationInfo.h:28,
 1:01.49                  from /home/sharkcz/projects/firefox/js/src/frontend/Parser.h:184,
 1:01.49                  from /home/sharkcz/projects/firefox/js/src/wasm/AsmJS.cpp:38,
 1:01.50                  from Unified_cpp_js_src_wasm0.cpp:2:
 1:01.50 /home/sharkcz/projects/firefox/js/src/vm/Stack.h: In instantiation of ‘class js::detail::FixedArgsBase<js::NO_CONSTRUCT, 0>’:
 1:01.50 /home/sharkcz/projects/firefox/js/src/vm/Stack.h:933:7:   required from ‘class js::FixedInvokeArgs<0>’
 1:01.50 /home/sharkcz/projects/firefox/js/src/vm/Interpreter.h:90:29:   required from here
 1:01.50 /home/sharkcz/projects/firefox/js/src/vm/Stack.h:890:19: warning: comparison is always true due to limited range of data type [-Wtype-limits]
 1:01.50   890 |   static_assert(N <= ARGS_LENGTH_MAX, "o/~ too many args o/~");
 1:01.50       |                 ~~^~~~~~~~~~~~~~~~~~
 1:09.53 In file included from Unified_cpp_js_src_wasm0.cpp:11:
 1:09.53 /home/sharkcz/projects/firefox/js/src/wasm/WasmBaselineCompile.cpp:750:13: error: explicit specialization in non-namespace scope ‘class js::wasm::BaseRegAlloc’
 1:09.54   750 |   template <>
 1:09.54       |             ^
 1:09.54 /home/sharkcz/projects/firefox/js/src/wasm/WasmBaselineCompile.cpp:751:17: error: template-id ‘allocFPU<js::jit::MIRType::Simd128>’ in declaration of primary template
 1:09.54   751 |   FloatRegister allocFPU<MIRType::Simd128>() {
 1:09.54       |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~
 1:09.55 /home/sharkcz/projects/firefox/js/src/wasm/WasmBaselineCompile.cpp: In member function ‘bool js::wasm::BaseRegAlloc::hasFPU()’:
 1:09.55 /home/sharkcz/projects/firefox/js/src/wasm/WasmBaselineCompile.cpp:658:34: error: ‘T’ was not declared in this scope
 1:09.55   658 |     if constexpr (std::is_same_v<T, MIRType::Simd128>)
 1:09.55       |                                  ^
 1:19.34 /home/sharkcz/projects/firefox/js/src/wasm/WasmBaselineCompile.cpp: In member function ‘bool js::wasm::BaseRegAlloc::hasFPU() [with js::jit::MIRType t = js::jit::MIRType::Float32]’:
 1:19.34 /home/sharkcz/projects/firefox/js/src/wasm/WasmBaselineCompile.cpp:663:3: warning: control reaches end of non-void function [-Wreturn-type]
 1:19.34   663 |   }
 1:19.34       |   ^
 1:19.34 /home/sharkcz/projects/firefox/js/src/wasm/WasmBaselineCompile.cpp: In member function ‘bool js::wasm::BaseRegAlloc::hasFPU() [with js::jit::MIRType t = js::jit::MIRType::Double]’:
 1:19.34 /home/sharkcz/projects/firefox/js/src/wasm/WasmBaselineCompile.cpp:663:3: warning: control reaches end of non-void function [-Wreturn-type]
 1:20.18 gmake[4]: *** [/home/sharkcz/projects/firefox/config/rules.mk:725: Unified_cpp_js_src_wasm0.o] Chyba 1
 1:20.18 gmake[4]: Opouští se adresář „/home/sharkcz/projects/firefox/obj-aarch64-unknown-linux-gnu/js/src/wasm“
...

Fixed patch that builds: https://github.com/mozilla/gecko-dev/commit/71597faac0fde4f608a60dd610d0cefac4972cc3.patch

Ping?

Patches are listed above, but Firefox has had aarch64 builds disabled since 2020-11-20. Martin, can you please look at this? We can't really just have Firefox not building for one of our primary arches.

Proposing as a Beta blocker per "It must be possible to run the default web browser and a terminal application from all release-blocking desktop environments." GNOME is the release-blocking desktop environment for aarch64.

Added to Firefox 84 which coming out 12-15-2020.
Thanks.

Aarch64 fixes seems to be working now, Thanks (https://koji.fedoraproject.org/koji/taskinfo?taskID=57238919).
We'll ship new builds with Firefox 84.0 release.

It would be best not to close this until we actually have a successful build in Rawhide. I don't see one yet.

Side note: you forgot to update the %changelog with the 84.0 builds. The latest entry in the changelog is still 83.0-15.

Yeah, sorry for that.

We do have a successful build in Rawhide now:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1661449

so this can be closed. Please, in future, don't disable aarch64 builds. If aarch64 doesn't build it needs to be fixed before a build can be done. It's a primary, release-blocking arch. Thanks!

(In reply to Adam Williamson from comment #16)
> We do have a successful build in Rawhide now:
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1661449
> 
> so this can be closed. Please, in future, don't disable aarch64 builds. If
> aarch64 doesn't build it needs to be fixed before a build can be done. It's
> a primary, release-blocking arch. Thanks!

In such case we'd hold security updated until aarch64 is fixed and that can take weeks so I don't think it's acceptable. If aarch64 updates are so important it will be great to have second arch experts here to help with it.

> In such case we'd hold security updated until aarch64 is fixed and that can
> take weeks so I don't think it's acceptable. If aarch64 updates are so
> important it will be great to have second arch experts here to help with it.

We do, but you've constantly ignored us, please file a bug and block against ARMTracker so arch maintainers are aware of it (similar blockers exist for other arches), or actively reach out.

(In reply to Peter Robinson from comment #18)
> > In such case we'd hold security updated until aarch64 is fixed and that can
> > take weeks so I don't think it's acceptable. If aarch64 updates are so
> > important it will be great to have second arch experts here to help with it.
> 
> We do, but you've constantly ignored us, please file a bug and block against
> ARMTracker so arch maintainers are aware of it (similar blockers exist for
> other arches), or actively reach out.

Okay, will do that next time.
Thanks.