Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1897675
Summary: | Firefox fails to build on aarch64 | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Martin Stransky <stransky> |
Component: | firefox | Assignee: | Gecko Maintainer <gecko-bugs-nobody> |
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | urgent | ||
Version: | rawhide | CC: | awilliam, dan, dominik, elxreno, erack, gecko-bugs-nobody, jakub, jhorak, jwakely, kai-engert-fedora, pbrobinson, pjasicek, rhughes, robatino, rstrode, sandmann |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | openqa | ||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2021-01-02 19:57:33 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 245418, 1829022 |
Description
Martin Stransky
2020-11-13 18:14:57 UTC
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. |