Repository navigation
Build failure on most Linux systems #77
Description
There seems to be something in V8's code that GCC 6 can't handle.
@nodejs/v8-update
CI run: https://ci.nodejs.org/job/node-test-commit-node-v8/98/
Error output:
06:55:28 In file included from ../deps/v8/src/x64/assembler-x64-inl.h:12:0,
06:55:28 from ../deps/v8/src/assembler-inl.h:13,
06:55:28 from ../deps/v8/src/compiler/wasm-compiler.cc:9:
06:55:28 ../deps/v8/src/objects-inl.h: In function 'bool v8::internal::InstanceTypeChecker::IsName(v8::internal::InstanceType)':
06:55:28 ../deps/v8/src/objects-inl.h:95:26: warning: comparison is always true due to limited range of data type [-Wtype-limits]
06:55:28 return instance_type >= first_instance_type && \
06:55:28 ^
06:55:28 ../deps/v8/src/objects.h:1061:3: note: in expansion of macro 'INSTANCE_TYPE_CHECKER_RANGE'
06:55:28 V(Name, FIRST_TYPE, LAST_NAME_TYPE) \
06:55:28 ^
06:55:28 ../deps/v8/src/objects-inl.h:98:1: note: in expansion of macro 'INSTANCE_TYPE_CHECKERS_RANGE'
06:55:28 INSTANCE_TYPE_CHECKERS_RANGE(INSTANCE_TYPE_CHECKER_RANGE);
06:55:28 ^
06:55:28 ../deps/v8/src/objects-inl.h: In function 'bool v8::internal::InstanceTypeChecker::IsString(v8::internal::InstanceType)':
06:55:28 ../deps/v8/src/objects-inl.h:95:26: warning: comparison is always true due to limited range of data type [-Wtype-limits]
06:55:28 return instance_type >= first_instance_type && \
06:55:28 ^
06:55:28 ../deps/v8/src/objects.h:1062:3: note: in expansion of macro 'INSTANCE_TYPE_CHECKER_RANGE'
06:55:28 V(String, FIRST_TYPE, FIRST_NONSTRING_TYPE - 1) \
06:55:28 ^
06:55:28 ../deps/v8/src/objects-inl.h:98:1: note: in expansion of macro 'INSTANCE_TYPE_CHECKERS_RANGE'
06:55:28 INSTANCE_TYPE_CHECKERS_RANGE(INSTANCE_TYPE_CHECKER_RANGE);
06:55:28 ^
06:55:28 ../deps/v8/src/compiler/wasm-compiler.cc: In member function 'bool v8::internal::compiler::{anonymous}::WasmWrapperGraphBuilder::BuildWasmToJSWrapper(v8::internal::Handle<v8::internal::JSReceiver>, int)':
06:55:28 ../deps/v8/src/compiler/wasm-compiler.cc:4519:74: warning: comparison is always true due to limited range of data type [-Wtype-limits]
06:55:28 } else if (function->shared()->internal_formal_parameter_count() >= 0) {
06:55:28 ^
06:55:28 ../deps/v8/src/compiler/wasm-compiler.cc: In member function 'v8::internal::compiler::SourcePositionTable* v8::internal::compiler::TurbofanWasmCompilationUnit::BuildGraphForWasmFunction(v8::internal::wasm::WasmFeatures*, double*, v8::internal::compiler::MachineGraph*, v8::internal::compiler::NodeOriginTable*)':
06:55:28 ../deps/v8/src/compiler/wasm-compiler.cc:5049:30: error: use of deleted function 'v8::internal::wasm::Result<T>& v8::internal::wasm::Result<T>::operator=(v8::internal::wasm::Result<T>&&) [with T = v8::internal::wasm::DecodeStruct*]'
06:55:28 graph_construction_result_ = wasm::BuildTFGraph(
06:55:28 ^
06:55:28 In file included from ../deps/v8/src/wasm/decoder.h:15:0,
06:55:28 from ../deps/v8/src/wasm/function-body-decoder.h:12,
06:55:28 from ../deps/v8/src/compiler/wasm-compiler.h:13,
06:55:28 from ../deps/v8/src/compiler/wasm-compiler.cc:5:
06:55:28 ../deps/v8/src/wasm/wasm-result.h:79:11: note: 'v8::internal::wasm::Result<T>& v8::internal::wasm::Result<T>::operator=(v8::internal::wasm::Result<T>&&) [with T = v8::internal::wasm::DecodeStruct*]' is implicitly deleted because the default definition would be ill-formed:
06:55:28 Result& operator=(Result&& other) V8_NOEXCEPT = default;
06:55:28 ^
06:55:28 ../deps/v8/src/wasm/wasm-result.h:79:11: error: use of deleted function 'v8::internal::wasm::ResultBase& v8::internal::wasm::ResultBase::operator=(v8::internal::wasm::ResultBase&&)'
06:55:28 ../deps/v8/src/wasm/wasm-result.h:29:15: note: 'v8::internal::wasm::ResultBase& v8::internal::wasm::ResultBase::operator=(v8::internal::wasm::ResultBase&&) noexcept' is implicitly deleted because its exception-specification does not match the implicit exception-specification ''
06:55:28 ResultBase& operator=(ResultBase&& other) V8_NOEXCEPT = default;
06:55:28 ^
06:55:28 make[2]: *** [deps/v8/gypfiles/v8_base.target.mk:630: /home/iojs/build/workspace/node-test-commit-smartos/nodes/smartos16-64/out/Release/obj.target/v8_base/deps/v8/src/compiler/wasm-compiler.o] Error 1
Activity
refack commentedon Sep 1, 2018
I've made some progress by adding:
since we run with
-fno-exceptionsanyway.refack commentedon Sep 8, 2018
@targos IIRC I can just push to this branch (since it gets overwritten every day)?
I just wanted to test 085d7c2
targos commentedon Sep 8, 2018
@refack sure, but you don't need to. You can start
node-test-commitjobs against your forkrefack commentedon Sep 8, 2018
Well it's compiling, so https://chromium-review.googlesource.com/c/v8/v8/+/1215222
vulder commentedon Sep 10, 2018
Hi, I tried to reproduce this issue but it compiles on my machine.
Could you please point me to a specific version and steps to reproduce this.
Then I can try to fix this upstream.
targos commentedon Sep 10, 2018
@vulder Well, me neither... I tried on my usual computer (Fedora 28) and on a fresh CentOS 7 VM.
@refack Is it possible that this is a bug in GCC that was fixed and the version on our CI is just not up to date?
vulder commentedon Sep 10, 2018
It's not a gcc bug. It related to the function's exception specification that is generated for default members. If gcc decides to generate a default member without noexcept and we specify this member as noexcept the specification does not longer match. Therefore, we get an error.
refack commentedon Sep 10, 2018
@vulder thank for reviewing this. I'll try to supply as much info on the platforms where this fails:
One example is https://ci.nodejs.org/job/node-test-commit-linux/21235/nodes=ubuntu1604-64/
Machine is:
toolset:
The command line is:
vulder commentedon Sep 10, 2018
thx for the Infos:
I checked out a fresh copy of the node repo.
Build it with:
CXX=g++-6 CC=gcc-6 ./configure --debugCXX=g++6 CC=gcc-6 make BUILDTYPE=Debug V=2 alland it worked. Maybe I need to use a different build target, not sure. What did you use?
I see that you have gcc-5 installed and not 6 but before mentioned 6, does it work for you on 6 or do you get the same error?
refack commentedon Sep 10, 2018
Did you try building
https://github.com/nodejs/node-v8/tree/canaryor thecanary-basebranch of the "regular" node repo (it's where we keep V8 LKGR).I picked one machine that failed, I'm not sure we have GCC 6 in our CI mix, and ATM our CI server is vvveerrryyy slow https://ci.nodejs.org/job/node-test-commit-linux/21235.
For easier repro I've pre-processed the file:
wasm-compiler.post.zip
Locally with GCC7 on the pre-processed file I get:
targos commentedon Sep 10, 2018
I'm the one who mentioned GCC 6. It was because one of the failing CI run was on
centos7-64-gcc6vulder commentedon Sep 10, 2018
thanks, the file helped. It's what I expected.
I'm going to building a patch cl for v8 and send it to you for testing. If it compiles afterwards and your problems are fixed I'm going to land it an bug fix merge it into the last release, so you can pull in v8 as usual.
vulder commentedon Sep 10, 2018
Ok, sadly my first idea did not work -.-
I preprocessed the same file on my machine, the relevant parts of the code look the same.
Using gcc-6 I cannot figure out why ResultBase move constructor gets deleted in your version but not in my one.
Could you please compile the two attached files on your machine and post the output.
foo.cpp is just a smaller test that hopefully triggers the behavior.
wasm.zip
refack commentedon Sep 10, 2018
Your preprocessed file compiles,
foo.cppdoesn't (I used all the-Ds and-Is just because I'm lazy)...P.S. this is GCC 5 (on our CI cluster). Locally with GCC7 it works.
refack commentedon Sep 16, 2018
Landed upstream as https://chromium-review.googlesource.com/c/v8/v8/+/1219632 (by @vulder)
targos commentedon Sep 17, 2018
Thank you @vulder and @refack!