Repository navigation
tracking: canary doesn't compile on s390 and ppcle #90
Description
- Version:
canary - Platform:
s390xandubuntu@ppcle - Subsystem: V8
s390x:
15:48:02 In file included from ../../src/compiler/backend/s390/code-generator-s390.cc:14:0:
15:48:02 ../../src/s390/macro-assembler-s390.h:6:2: error: #error This header must be included via macro-assembler.h
15:48:02 #error This header must be included via macro-assembler.h
15:48:02 ^
ubuntu@ppcle
15:48:41 FAILED: obj/v8_base/code-generator-ppc.o
15:48:41 g++ -MMD -MF obj/v8_base/code-generator-ppc.o.d -DV8_DEPRECATION_WARNINGS -DUSE_UDEV -DUSE_AURA=1 -DUSE_GLIB=1 -DUSE_NSS_CERTS=1 -DUSE_X11=1 -DFULL_SAFE_BROWSING -DSAFE_BROWSING_CSD -DSAFE_BROWSING_DB_LOCAL -DCHROMIUM_BUILD -DFIELDTRIAL_TESTING_ENABLED -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DV8_TYPED_ARRAY_MAX_SIZE_IN_HEAP=64 -DENABLE_GDB_JIT_INTERFACE -DENABLE_MINOR_MC -DV8_DEPRECATION_WARNINGS -DV8_IMMINENT_DEPRECATION_WARNINGS -DV8_INTL_SUPPORT -DENABLE_HANDLE_ZAPPING -DV8_USE_SNAPSHOT -DV8_USE_EXTERNAL_STARTUP_DATA -DV8_CONCURRENT_MARKING -DV8_EMBEDDED_BUILTINS -DV8_EMBEDDED_BYTECODE_HANDLERS -DV8_TARGET_ARCH_PPC -DV8_TARGET_ARCH_PPC64 -DV8_TARGET_ARCH_PPC_LE -DDISABLE_UNTRUSTED_CODE_MITIGATIONS -DU_USING_ICU_NAMESPACE=0 -DU_ENABLE_DYLOAD=0 -DUSE_CHROMIUM_ICU=1 -DU_STATIC_IMPLEMENTATION -DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_FILE -DUCHAR_TYPE=uint16_t -I../.. -Igen -I../.. -Igen -I../../third_party/icu/source/common -I../../third_party/icu/source/i18n -I../../include -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -Wno-builtin-macro-redefined -D__DATE__= -D__TIME__= -D__TIMESTAMP__= -funwind-tables -fPIC -pipe -pthread -m64 -Wall -Werror -Wno-unused-local-typedefs -Wno-maybe-uninitialized -Wno-deprecated-declarations -Wno-comments -Wno-missing-field-initializers -Wno-unused-parameter -fno-omit-frame-pointer -g0 -fvisibility=hidden -Wno-strict-overflow -Wno-return-type -O3 -fno-ident -fdata-sections -ffunction-sections -std=gnu++14 -Wno-narrowing -fno-exceptions -fno-rtti -fvisibility-inlines-hidden -c ../../src/compiler/backend/ppc/code-generator-ppc.cc -o obj/v8_base/code-generator-ppc.o
15:48:41 In file included from ../../src/compiler/backend/ppc/code-generator-ppc.cc:15:0:
15:48:41 ../../src/ppc/macro-assembler-ppc.h:6:2: error: #error This header must be included via macro-assembler.h
15:48:41 #error This header must be included via macro-assembler.h
15:48:41 ^
Activity
[-]tracking: doesn't compile on s390 and ppcle[/-][+]tracking: canary doesn't compile on s390 and ppcle[/+]mhdawson commentedon Nov 19, 2018
@john-yan can you take a look.
john-yan commentedon Nov 19, 2018
Please wait until these 4 changes get in:
https://chromium-review.googlesource.com/c/v8/v8/+/1342738
https://chromium-review.googlesource.com/c/v8/v8/+/1342977
https://chromium-review.googlesource.com/c/v8/v8/+/1342661
https://chromium-review.googlesource.com/c/v8/v8/+/1342978
remaining ppc issue has to be waited until:
https://chromium-review.googlesource.com/c/v8/v8/+/1336110
refack commentedon Nov 19, 2018
To reiterate this is just a tracking issue, and is related to our canary build. If you are already dealing with it, it would be enough if you just keep up in the loop.
FTR: Still relevant as of last night with V8 7.2.378
P.S. I just saw your reply @john-yan , thank you very much for the context.
mhdawson commentedon Jan 10, 2019
@refack is this still an issue?
mhdawson commentedon Jan 10, 2019
Actually, I'll answer that myself. I think the answer is yes. The originally reported issues were fixed but there have been new issues since them.
I'm wondering if this should be closed or if we should keep it. I think a lot of the time canary will not be working for those platforms as canary is the bleeding edge and we are always catching up.
refack commentedon Jan 10, 2019
I'd say it's your (s390 & linux@ppc team's) call.
refack commentedon Jan 10, 2019
Wrong button (the time off made me rusty)
I'm thinking maybe there's a wider conversation to be had. Maybe we want to have a different CI/CR flow for these platforms....
mhdawson commentedon Jan 16, 2019
I think everything is fine except for Canary. We might want to exclude them from the Canary builds but they should be good for everything else.
targos commentedon Jan 16, 2019
Do we care to know if/when they fail on canary? If not, I can remove them from the test job.
mhdawson commentedon Jan 16, 2019
@john-yan what's your take. If they are not going to be passing more than 50% of the time it might be better to just remove them.
@targos since this would just be for canary but its the same job for release we'd have to be careful that they are only removed for the canary builds.
john-yan commentedon Jan 16, 2019
I don't think it's necessary to track master branch either.
targos commentedon Jan 16, 2019
@mhdawson It's a different job: https://ci.nodejs.org/view/MyJobs/job/node-test-commit-node-v8/
mhdawson commentedon Jan 16, 2019
Ok I was thinking of the nightly canary builds. I'm fine removing it from the job testing canary v8 with Node. While I'd like our platforms to be there, at this point I think it adds more noise than benefit.
targos commentedon Jan 18, 2019
Ok, I removed
aix,plinuxandlinuxonefrom the job. I think we can keep the release job as it is, so we get a chance to have canary builds on those platforms when compilation works.mhdawson commentedon Jan 18, 2019
@targos + 1
targos commentedon Feb 8, 2019
@refack Is this resolved from your POV?
refack commentedon May 22, 2019
this cycle was resolved (and another one since then)