My change (https://codereview.chromium.org/2158753003) to build lld is almost ready, and I want to roll Clang with lld once that CL is submitted.

Unless someone objects, I am assigning this issue to myself.

Note that ToT weather is not great, so we'll need to resolve these issue prior to the roll.

VERSION in update.py will need to be updated to 4.0.0. This is what's causing the #include failures on ToT ASan bots. I'll try to fix that.

I'm also a little worried about llvm.org/PR28606 and gvn-hoist in general.

The current top reason for ToT bot being red is some AVX2 crasher:
https://build.chromium.org/p/chromium.fyi/builders/ClangToTLinux/builds/5826/steps/compile/logs/stdio

FAILED: obj/third_party/libvpx/libvpx_intrinsics_avx2/loopfilter_avx2.o 
../../third_party/llvm-build/Release+Asserts/bin/clang -MMD -MF obj/third_party/libvpx/libvpx_intrinsics_avx2/loopfilter_avx2.o.d -DV8_DEPRECATION_WARNINGS -DENABLE_MDNS=1 -DENABLE_NOTIFICATIONS -DENABLE_PEPPER_CDMS -DENABLE_PLUGINS=1 -DENABLE_PDF=1 -DENABLE_PRINTING=1 -DENABLE_BASIC_PRINTING=1 -DENABLE_PRINT_PREVIEW=1 -DENABLE_SPELLCHECK=1 -DUSE_UDEV -DUI_COMPOSITOR_IMAGE_TRANSPORT -DUSE_AURA=1 -DUSE_PANGO=1 -DUSE_CAIRO=1 -DUSE_CLIPBOARD_AURAX11=1 -DUSE_DEFAULT_RENDER_THEME=1 -DUSE_GLIB=1 -DUSE_NSS_CERTS=1 -DUSE_X11=1 -DENABLE_WEBRTC=1 -DENABLE_EXTENSIONS=1 -DENABLE_TASK_MANAGER=1 -DENABLE_THEMES=1 -DENABLE_CAPTIVE_PORTAL_DETECTION=1 -DENABLE_SESSION_SERVICE=1 -DENABLE_SUPERVISED_USERS=1 -DENABLE_SERVICE_DISCOVERY=1 -DFULL_SAFE_BROWSING -DSAFE_BROWSING_CSD -DSAFE_BROWSING_DB_LOCAL -DCHROMIUM_BUILD -DENABLE_MEDIA_ROUTER=1 -DFIELDTRIAL_TESTING_ENABLED -DCR_CLANG_REVISION=276352 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DCOMPONENT_BUILD -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -I../.. -Igen -I../../third_party/libvpx/source/config -I../../third_party/libvpx/source/config/linux/x64 -I../../third_party/libvpx/source/libvpx -Igen/third_party/libvpx -mavx2 -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -funwind-tables -fPIC -pipe -B../../third_party/binutils/Linux_x64/Release/bin -fcolor-diagnostics -fdebug-prefix-map=/b/c/b/ClangToTLinux/src=. -pthread -m64 -march=x86-64 -O2 -fno-ident -fdata-sections -ffunction-sections -g2 --sysroot=../../build/linux/debian_wheezy_amd64-sysroot -fvisibility=hidden -Wheader-hygiene -Wstring-conversion -Werror -Wall -Wno-unused-variable -Wno-missing-field-initializers -Wno-unused-parameter -Wno-c++11-narrowing -Wno-covered-switch-default -Wno-deprecated-register -Wno-unneeded-internal-declaration -Wno-inconsistent-missing-override -Wno-shift-negative-value -Wno-undefined-var-template -Wno-nonportable-include-path -Wno-conversion -Wno-parentheses-equality -Wno-unused-function  -c ../../third_party/libvpx/source/libvpx/vpx_dsp/x86/loopfilter_avx2.c -o obj/third_party/libvpx/libvpx_intrinsics_avx2/loopfilter_avx2.o
fatal error: error in backend: Cannot select: intrinsic %llvm.x86.avx.vbroadcastf128.pd.256
clang-4.0: error: clang frontend command failed with exit code 70 (use -v to see invocation)
clang version 4.0.0 (trunk 276352)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /b/c/b/ClangToTLinux/src/out/Release/../../third_party/llvm-build/Release+Asserts/bin
clang-4.0: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script.
clang-4.0: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-4.0: note: diagnostic msg: /tmp/loopfilter_avx2-fcc9b0.c
clang-4.0: note: diagnostic msg: /tmp/loopfilter_avx2-fcc9b0.sh
clang-4.0: note: diagnostic msg: 

The suspected revision is blame r276281: https://reviews.llvm.org/D22460
Plus, there're a few relevant revisions right before that.

Deleted: loopfilter_avx2-fcc9b0.sh 8.5 KB

loopfilter_avx2-fcc9b0.sh 8.5 KB View Download

Deleted: loopfilter_avx2-fcc9b0.c 2.1 MB

loopfilter_avx2-fcc9b0.c 2.1 MB View Download

filed https://llvm.org/bugs/show_bug.cgi?id=28657

For the record, the AVX2 issue is now resolved. 

The Windows bootstrap situation is not so great at the moment. Currently looking at https://llvm.org/bugs/show_bug.cgi?id=28705

At this point, we should have everything but Windows green (when the bots cycle, assuming no new regressions from the LLVM trunk come). On Windows there's at least 3 issues:

1. Bootstrap: https://llvm.org/bugs/show_bug.cgi?id=28705
2. ASAN: https://bugs.chromium.org/p/chromium/issues/detail?id=630742
3. elf_imports_unittests:  https://crbug.com/630744  (a fix is under review)

I don't quite remember how to Windows, nor I have a machine for that. So, I'll focus on getting lld packaged, as it's another thing we want to have in the current roll: https://codereview.chromium.org/2158753003/ (almost there)

The Windows bootstrap issue from llvm.org/PR28705 should be fixed after r276822 (hopefully there are no more hiding behind it..)

A fix for elf_imports_unittests is also being submitted: https://codereview.chromium.org/2181793002/

And the bots for the resurrected slaves cycled green.

We probably only have this Windows + ASAN + allocator issue left.

Why is https://codereview.chromium.org/2181793002/ needed only with trunk clang but not with current clang or cl?

The CL has the following remark:

"""Recent changes to chrome_elf to integrate with crashpad for crash
reporting have brought in dependencies on base which pull in UuidCreate
from rpcrt4. This code path is not exercised in chrome_elf which delay
loads rpcrt4."""

Could be some subtle differences in the application manifest, but I don't want to guess too much. Ananta, can you please clarify what has happened there?

but pinned clang uses the same application manifest. if this works with pinned clang (does it?) but not tot clang, then the difference has to be in the compiler

krasin, ananta: ping on comment 19 (assuming it was indeed only needed for the tot bots)

Nico,

I have no additional information about that: Windows is the system I used to know, and I barely can build Chrome on Windows now.

Ananta,
can you please address the concerns thakis@ raised?

krasin: I don't think ananta is in a position to evaluate changes in clang itself.

Do you remember if only the tot bots were red? I don't see redness on Jul 22 on https://build.chromium.org/p/chromium.fyi/builders/CrWinClang%20tester?numbuilds=200 , so it seems it's ToT only. Someone familiar with clang needs to investigate this, I think.

I didn't look into that on Jul 22 (my fault), but I tried to look that up yesterday. I didn't find redness on the bots other ToT for the time period when ToT bots were red.

Would you like to revert the CL that suppresses the problem? In this case, we'll at least see the real status, and then someone with Windows knowledge could take a look.

I'll try building packages at rL277621

https://codereview.chromium.org/2214333004

The TOT waterfall looks relatively green right now. The remaining redness occurs in testing steps, which suggests the problems are in Chromium, not clang.

- Android ASan testing: this line looks relevant, maybe a gyp-to-gn migration issue:
STDERR: /b/c/b/ClangToTAndroidASan_tester/src/out/Debug/md5sum_bin_host: error while loading shared libraries: libbase.cr.so: wrong ELF class: ELFCLASS32

- Mac ASan testing: core.minidump_unittest.BrowserMinidumpTest.testSymbolizeMinidump looks flaky, and has failed a lot in the past

- Windows testing: PPAPI Nacl tests failing left and right, this is not a clang issue, it is http://crbug.com/633067

Am I missing anything? Think we're ready to roll?

Yup, I agree. (See comment 28)

I think that chrome_elf_unittests still failing: https://build.chromium.org/p/chromium.fyi/builders/CrWinAsanCov%20tester/builds/469/steps/chrome_elf_unittests%20on%20Windows-7-SP1

They fail due to multiple problems, but one of them might still be these new dependencies, although the test log is hard to decipher.

Probably, just a red herring since the failure is just on the ASAN bot. The regular bot has this test green: https://build.chromium.org/p/chromium.fyi/builders/ClangToTWin%20tester/builds/5752/steps/chrome_elf_unittests%20on%20Windows-7-SP1

I filed  bug 634982  for the android asan bot issue.

The revision I picked crashes during bootstrap:

[475/1596] Building CXX object lib/CodeGen/SelectionDAG/CMakeFiles/LLVMSelectionDAG.dir/SelectionDAGBuilder.cpp.o
FAILED: lib/CodeGen/SelectionDAG/CMakeFiles/LLVMSelectionDAG.dir/SelectionDAGBuilder.cpp.o 
/b/build/slave/linux_upload_clang/build/src/third_party/llvm-bootstrap-install/bin/clang++   -DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/CodeGen/SelectionDAG -I/b/build/slave/linux_upload_clang/build/src/third_party/llvm/lib/CodeGen/SelectionDAG -Iinclude -I/b/build/slave/linux_upload_clang/build/src/third_party/llvm/include -flto --gcc-toolchain=/b/build/slave/linux_upload_clang/build/src/third_party/llvm-build-tools/gcc482precise -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Werror=date-time -std=c++11 -fcolor-diagnostics -ffunction-sections -fdata-sections -O3    -UNDEBUG  -fno-exceptions -fno-rtti -MMD -MT lib/CodeGen/SelectionDAG/CMakeFiles/LLVMSelectionDAG.dir/SelectionDAGBuilder.cpp.o -MF lib/CodeGen/SelectionDAG/CMakeFiles/LLVMSelectionDAG.dir/SelectionDAGBuilder.cpp.o.d -o lib/CodeGen/SelectionDAG/CMakeFiles/LLVMSelectionDAG.dir/SelectionDAGBuilder.cpp.o -c /b/build/slave/linux_upload_clang/build/src/third_party/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
clang-4.0: /b/build/slave/linux_upload_clang/build/src/third_party/llvm/include/llvm/Support/Casting.h:251: typename std::enable_if<(! llvm::is_simple_type<Y>::value), typename llvm::cast_retty<X, const Y>::ret_type>::type llvm::cast_or_null(const Y&) [with X = llvm::Instruction; Y = llvm::WeakVH; typename std::enable_if<(! llvm::is_simple_type<Y>::value), typename llvm::cast_retty<X, const Y>::ret_type>::type = llvm::Instruction*]: Assertion `isa<X>(Val) && "cast_or_null<Ty>() argument of incompatible type!"' failed.
#0 0x0000000001310535 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/b/build/slave/linux_upload_clang/build/src/third_party/llvm-bootstrap-install/bin/clang-4.0+0x1310535)
#1 0x000000000130e4ce llvm::sys::RunSignalHandlers() (/b/build/slave/linux_upload_clang/build/src/third_party/llvm-bootstrap-install/bin/clang-4.0+0x130e4ce)
#2 0x000000000130e632 SignalHandler(int) (/b/build/slave/linux_upload_clang/build/src/third_party/llvm-bootstrap-install/bin/clang-4.0+0x130e632)
#3 0x00007f4a3d020330 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10330)
#4 0x00007f4a3bc14c37 gsignal /build/eglibc-oGUzwX/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0
#5 0x00007f4a3bc18028 abort /build/eglibc-oGUzwX/eglibc-2.19/stdlib/abort.c:91:0
#6 0x00007f4a3bc0dbf6 __assert_fail_base /build/eglibc-oGUzwX/eglibc-2.19/assert/assert.c:92:0
#7 0x00007f4a3bc0dca2 (/lib/x86_64-linux-gnu/libc.so.6+0x2fca2)

https://build.chromium.org/p/tryserver.chromium.linux/builders/linux_upload_clang/builds/56/steps/package%20clang/logs/stdio

That crash also happened on the win bootstrap llvm bot. Started here http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/14529 ended here http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/14542 Trying again at r277642

That revision fails to link like so:

232/1596] Linking CXX executable bin/llvm-tblgen
FAILED: bin/llvm-tblgen 
: && /b/build/slave/linux_upload_clang/build/src/third_party/llvm-bootstrap-install/bin/clang++   -flto --gcc-toolchain=/b/build/slave/linux_upload_clang/build/src/third_party/llvm-build-tools/gcc482precise -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Werror=date-time -std=c++11 -fcolor-diagnostics -ffunction-sections -fdata-sections -O3  -fuse-ld=lld -Wl,-allow-shlib-undefined    -Wl,-O3 -Wl,--gc-sections utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/AsmMatcherEmitter.cpp.o utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/AsmWriterEmitter.cpp.o utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/AsmWriterInst.cpp.o utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/Attributes.cpp.o utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/CallingConvEmitter.cpp.o utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/CodeEmitterGen.cpp.o utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/CodeGenDAGPatterns.cpp.o utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/CodeGenInstruction.cpp.o utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/CodeGenMapTable.cpp.o utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/CodeGenRegisters.cpp.o utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/CodeGenSchedule.cpp.o utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/CodeGenTarget.cpp.o utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/DAGISelEmitter.cpp.o utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/DAGISelMatcherEmitter.cpp.o utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/DAGISelMatcherGen.cpp.o utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/DAGISelMatcherOpt.cpp.o utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/DAGISelMatcher.cpp.o utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/DFAPacketizerEmitter.cpp.o utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/DisassemblerEmitter.cpp.o utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/FastISelEmitter.cpp.o utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/FixedLenDecoderEmitter.cpp.o utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/InstrInfoEmitter.cpp.o utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/IntrinsicEmitter.cpp.o utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/OptParserEmitter.cpp.o utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/PseudoLoweringEmitter.cpp.o utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/RegisterInfoEmitter.cpp.o utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/SearchableTableEmitter.cpp.o utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/SubtargetEmitter.cpp.o utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/TableGen.cpp.o utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/X86DisassemblerTables.cpp.o utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/X86ModRMFilters.cpp.o utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/X86RecognizableInstr.cpp.o utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/CTagsEmitter.cpp.o  -o bin/llvm-tblgen  lib/libLLVMSupport.a lib/libLLVMTableGen.a -lpthread lib/libLLVMSupport.a -lrt -ldl -ltinfo -lpthread -lz -lm -Wl,-rpath,"\$ORIGIN/../lib" && :
undefined symbol: _ZN4llvm20emitSourceFileHeaderENS_9StringRefERNS_11raw_ostreamE in utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/AsmMatcherEmitter.cpp.o
undefined symbol: _ZN4llvm2cl18GenericOptionValue6anchorEv in utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/AsmMatcherEmitter.cpp.o
undefined symbol: _ZNK4llvm6Record16getValueAsStringENS_9StringRefE in utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/AsmMatcherEmitter.cpp.o
undefined symbol: _ZN4llvm18isCurrentDebugTypeEPKc in utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/AsmMatcherEmitter.cpp.o



krasin, could that be due to the lto changes?

Not directly, but yes, disabling my changes should help, see https://codereview.chromium.org/2158753003#msg14

"there's a chance that the build is not deterministic
anymore. While it's bad and a sign of a bigger problem in LLVM, we are better
learn that from package-Clang-on-bots CLs rather than while building desktop
Chrome: https://crbug.com/630335"

This is an issue that I consistently failed to reproduce locally. :(

Feel free to revert my CL and try again.

At that revision tests also fail on mac like so:

[286/287] Running all regression tests
lit.py: /b/build/slave/mac_upload_clang/build/src/third_party/llvm/tools/clang/test/lit.cfg:195: note: using clang: '/b/build/slave/mac_upload_clang/build/src/third_party/llvm-build/Release+Asserts/./bin/clang'
lit.py: /b/build/slave/mac_upload_clang/build/src/third_party/llvm/utils/lit/lit/util.py:254: note: using SDKROOT: '/Applications/Xcode7.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk'
-- Testing: 28049 tests, 8 threads --
Testing: 0 .. 10.. 20.. 30.. 40.. 
FAIL: LLVM :: CodeGen/ARM/subtarget-no-movt.ll (14453 of 28049)
******************** TEST 'LLVM :: CodeGen/ARM/subtarget-no-movt.ll' FAILED ********************


Only in stage 2 though :-( Is there a bootstrap mac bot on the llvm waterfall?

The linux bot did make it past linking llvm-tblgen, so the revert helped a bit. I'm now in meetings for 1.5h, maybe someone else could play the "pick promising revision, kick off try jobs, repeat" game a bit until then? My wip CL is at https://codereview.chromium.org/2214333004/ (it has some additional bits that are needed for actually landing the roll. For just building binaries, krasin's upload script is enough)

As a blind guess, I am going to kickoff building r277849

If you need help to fix upstream stuff... ping me.

a CL just to build the packages: https://codereview.chromium.org/2220013002

It failed on some lld code:

[1100/2066] Building CXX object tools/lld/lib/ReaderWriter/CMakeFiles/lldReaderWriter.dir/FileArchive.cpp.o
FAILED: tools/lld/lib/ReaderWriter/CMakeFiles/lldReaderWriter.dir/FileArchive.cpp.o 
/Applications/Xcode7.0.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++   -DGTEST_HAS_RTTI=0 -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools/lld/lib/ReaderWriter -I/b/build/slave/mac_upload_clang/build/src/third_party/llvm/tools/lld/lib/ReaderWriter -I/b/build/slave/mac_upload_clang/build/src/third_party/llvm/tools/lld/include -Itools/lld/include -Iinclude -I/b/build/slave/mac_upload_clang/build/src/third_party/llvm/include -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Werror=date-time -std=c++11 -fcolor-diagnostics -O3  -isysroot /Applications/Xcode7.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk   -UNDEBUG  -fno-exceptions -fno-rtti -MMD -MT tools/lld/lib/ReaderWriter/CMakeFiles/lldReaderWriter.dir/FileArchive.cpp.o -MF tools/lld/lib/ReaderWriter/CMakeFiles/lldReaderWriter.dir/FileArchive.cpp.o.d -o tools/lld/lib/ReaderWriter/CMakeFiles/lldReaderWriter.dir/FileArchive.cpp.o -c /b/build/slave/mac_upload_clang/build/src/third_party/llvm/tools/lld/lib/ReaderWriter/FileArchive.cpp
/b/build/slave/mac_upload_clang/build/src/third_party/llvm/tools/lld/lib/ReaderWriter/FileArchive.cpp:55:24: error: no viable conversion from 'Expected<llvm::StringRef>' to 'ErrorOr<llvm::StringRef>'
    ErrorOr<StringRef> buf = c.getBuffer();
                       ^     ~~~~~~~~~~~~~
/b/build/slave/mac_upload_clang/build/src/third_party/llvm/include/llvm/Support/ErrorOr.h:92:3: note: candidate constructor not viable: no known conversion from 'Expected<llvm::StringRef>' to 'std::error_code' for 1st argument
  ErrorOr(std::error_code EC) : HasError(true) {
  ^
/b/build/slave/mac_upload_clang/build/src/third_party/llvm/include/llvm/Support/ErrorOr.h:104:3: note: candidate constructor not viable: no known conversion from 'Expected<llvm::StringRef>' to 'const llvm::ErrorOr<llvm::StringRef> &' for 1st argument
  ErrorOr(const ErrorOr &Other) {
  ^
/b/build/slave/mac_upload_clang/build/src/third_party/llvm/include/llvm/Support/ErrorOr.h:124:3: note: candidate constructor not viable: no known conversion from 'Expected<llvm::StringRef>' to 'llvm::ErrorOr<llvm::StringRef> &&' for 1st argument
  ErrorOr(ErrorOr &&Other) {
  ^
/b/build/slave/mac_upload_clang/build/src/third_party/llvm/include/llvm/Support/ErrorOr.h:85:35: note: candidate template ignored: disabled by 'enable_if' [with E = llvm::Expected<llvm::StringRef>]
          typename std::enable_if<std::is_error_code_enum<E>::value ||
                                  ^
/b/build/slave/mac_upload_clang/build/src/third_party/llvm/include/llvm/Support/ErrorOr.h:98:35: note: candidate template ignored: disabled by 'enable_if' [with OtherT = llvm::Expected<llvm::StringRef>]
          typename std::enable_if<std::is_convertible<OtherT, T>::value>::type
                                  ^
/b/build/slave/mac_upload_clang/build/src/third_party/llvm/include/llvm/Support/ErrorOr.h:109:3: note: candidate template ignored: could not match 'ErrorOr' against 'Expected'
  ErrorOr(
  ^
/b/build/slave/mac_upload_clang/build/src/third_party/llvm/include/llvm/Support/ErrorOr.h:129:3: note: candidate template ignored: could not match 'ErrorOr' against 'Expected'
  ErrorOr(
  ^
/b/build/slave/mac_upload_clang/build/src/third_party/llvm/tools/lld/lib/ReaderWriter/FileArchive.cpp:169:31: error: no viable conversion from 'Expected<llvm::object::Archive::Child>' to 'ErrorOr<Archive::Child>'
      ErrorOr<Archive::Child> memberOrErr = sym.getMember();
                              ^             ~~~~~~~~~~~~~~~
/b/build/slave/mac_upload_clang/build/src/third_party/llvm/include/llvm/Support/ErrorOr.h:92:3: note: candidate constructor not viable: no known conversion from 'Expected<llvm::object::Archive::Child>' to 'std::error_code' for 1st argument
  ErrorOr(std::error_code EC) : HasError(true) {
  ^
/b/build/slave/mac_upload_clang/build/src/third_party/llvm/include/llvm/Support/ErrorOr.h:104:3: note: candidate constructor not viable: no known conversion from 'Expected<llvm::object::Archive::Child>' to 'const llvm::ErrorOr<llvm::object::Archive::Child> &' for 1st argument
  ErrorOr(const ErrorOr &Other) {
  ^
/b/build/slave/mac_upload_clang/build/src/third_party/llvm/include/llvm/Support/ErrorOr.h:124:3: note: candidate constructor not viable: no known conversion from 'Expected<llvm::object::Archive::Child>' to 'llvm::ErrorOr<llvm::object::Archive::Child> &&' for 1st argument
  ErrorOr(ErrorOr &&Other) {
  ^
/b/build/slave/mac_upload_clang/build/src/third_party/llvm/include/llvm/Support/ErrorOr.h:85:35: note: candidate template ignored: disabled by 'enable_if' [with E = llvm::Expected<llvm::object::Archive::Child>]
          typename std::enable_if<std::is_error_code_enum<E>::value ||
                                  ^
/b/build/slave/mac_upload_clang/build/src/third_party/llvm/include/llvm/Support/ErrorOr.h:98:35: note: candidate template ignored: disabled by 'enable_if' [with OtherT = llvm::Expected<llvm::object::Archive::Child>]
          typename std::enable_if<std::is_convertible<OtherT, T>::value>::type
                                  ^
/b/build/slave/mac_upload_clang/build/src/third_party/llvm/include/llvm/Support/ErrorOr.h:109:3: note: candidate template ignored: could not match 'ErrorOr' against 'Expected'
  ErrorOr(
  ^
/b/build/slave/mac_upload_clang/build/src/third_party/llvm/include/llvm/Support/ErrorOr.h:129:3: note: candidate template ignored: could not match 'ErrorOr' against 'Expected'
  ErrorOr(
  ^
2 errors generated.


Looking...

The error does not make sense to me; it's not reproducible locally, and the code actually shows:

197788       ruiu     // Don't return a member already returned
277657    enderby     Expected<StringRef> buf = c.getBuffer();
277657    enderby     if (!buf) {
277657    enderby       // TODO: Actually report errors helpfully.
277657    enderby       consumeError(buf.takeError());
242216     rafael       return nullptr;
277657    enderby     }

Which is not what the error tells us (it says there's ErrorOr in that line).
I'll pick another revision and try again.

r277856 (ToT at the moment): https://codereview.chromium.org/2217763006

By the way, the previous Windows build failed with

==1960==ERROR: SanitizerTool failed to allocate 0x10000 (65536) bytes of memory at address 0xd613c9000 (error code: 1455)
==1960==Dumping process modules:
	0x000077430000-0x000077550000 C:\Windows\system32\kernel32.dll
	0x000077550000-0x0000776f9000 C:\Windows\SYSTEM32\ntdll.dll
	0x00013f070000-0x00013ff67000 E:\b\build\slave\win_upload_clang\build\src\third_party\llvm-bootstrap\projects\compiler-rt\lib\sanitizer_common\tests\Sanitizer-x86_64-Test.exe
	0x07fefada0000-0x07fefaec5000 C:\Windows\system32\dbghelp.dll
	0x07fefd3c0000-0x07fefd42c000 C:\Windows\system32\KERNELBASE.dll
	0x07fefdd20000-0x07fefdd3f000 C:\Windows\SYSTEM32\sechost.dll
	0x07fefe360000-0x07fefe43b000 C:\Windows\system32\ADVAPI32.dll
	0x07fefe440000-0x07fefe56d000 C:\Windows\system32\RPCRT4.dll
	0x07fefe570000-0x07fefe60f000 C:\Windows\system32\msvcrt.dll
==1960==Sanitizer CHECK failed: E:\b\build\slave\win_upload_clang\build\src\third_party\llvm\projects\compiler-rt\lib\sanitizer_common\sanitizer_common.cc:120 ((0 && "unable to mmap")) != (0) (0, 0)

ASAN ToT bots were fixed by rebooting (I believe). We might need to do the same with the trybot slaves. We'll see how the current attempt goes.

Mac bot died with the same error message. I will verify that the source code on the bot is up to the revision.

AND IT'S NOT!

chrome-bot@vm648-m4:(Mac 10.11.4):/b/build/slave/mac_upload_clang/build/src/third_party/llvm/tools/lld$ svn info
Path: .
Working Copy Root Path: /b/build/slave/mac_upload_clang/build/src/third_party/llvm/tools/lld
URL: https://llvm.org/svn/llvm-project/lld/trunk
Repository Root: https://llvm.org/svn/llvm-project
Repository UUID: 91177308-0d34-0410-b5e6-96231b3b80d8
Revision: 277642
Node Kind: directory
Schedule: normal
Last Changed Author: nico
Last Changed Rev: 277616
Last Changed Date: 2016-08-03 11:07:28 -0700 (Wed, 03 Aug 2016)

Compare with what I have locally:

$ svn info
Path: .
Working Copy Root Path: /usr/local/google/home/krasin/src/llvm.org/llvm/tools/lld
URL: http://llvm.org/svn/llvm-project/lld/trunk
Relative URL: ^/lld/trunk
Repository Root: http://llvm.org/svn/llvm-project
Repository UUID: 91177308-0d34-0410-b5e6-96231b3b80d8
Revision: 277856
Node Kind: directory
Schedule: normal
Last Changed Author: compnerd
Last Changed Rev: 277846
Last Changed Date: 2016-08-05 11:20:31 -0700 (Fri, 05 Aug 2016)

As a quick workaround, I will delete the lld directory on the bots and send another try. A proper fix will be in update.py.

I have deleted lld dirs on linux and mac slaves, but I could not send another try job as there's some issue with tryserver. The web UI shows:
"Could not load try jobs. Please try again later"

And git cl try just hangs. This is unlikely to be isolated to just me.

Try jobs for linux and mac were sent. Waiting.

Windows failed with the same "no page file while running under ASAN" issue. I will ask troopers to reboot the slave, if Mac / Linux builds look good.

Actually, I'll ask them to reboot slaves anyway.

I just found https://codereview.chromium.org/2199003002/
Hans, is it working? Do I need to ask them to reboot the tryserver master, instead of slaves to make your change effective?

That change is active, but that's also irrelevant as it's for bots on the fyi waterfall, not for trybots (those probably all already autoreboot)

277616 above looks like it could've belonged to my first attempt to 277621. Maybe you ssh'd to the wrong slave?

Okay, you're right. I have found the change, but didn't look at the list of files changed (sorry, I tend to be shallow when in a rush).

From https://codereview.chromium.org/2217763006 :

[354/355] Running all regression tests
-- Testing: 28319 tests, 8 threads --
Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.
FAIL: SanitizerCommon-Unit :: Sanitizer-x86_64-Test.exe/SanitizerCommon.SizeClassAllocator64GetBlockBegin (27391 of 28319)
******************** TEST 'SanitizerCommon-Unit :: Sanitizer-x86_64-Test.exe/SanitizerCommon.SizeClassAllocator64GetBlockBegin' FAILED ********************
Note: Google Test filter = SanitizerCommon.SizeClassAllocator64GetBlockBegin

[==========] Running 1 test from 1 test case.

[----------] Global test environment set-up.

[----------] 1 test from SanitizerCommon

[ RUN      ] SanitizerCommon.SizeClassAllocator64GetBlockBegin

==3380==ERROR: SanitizerTool failed to allocate 0x10000 (65536) bytes of memory at address 0xd5ca08000 (error code: 1455)
==3380==Dumping process modules:
ERROR: Failed to mmap

********************
Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.
FAIL: SanitizerCommon-Unit :: Sanitizer-x86_64-Test.exe/SanitizerCommon.SizeClassAllocator64DynamicGetBlockBegin (27392 of 28319)
******************** TEST 'SanitizerCommon-Unit :: Sanitizer-x86_64-Test.exe/SanitizerCommon.SizeClassAllocator64DynamicGetBlockBegin' FAILED ********************
Note: Google Test filter = SanitizerCommon.SizeClassAllocator64DynamicGetBlockBegin

[==========] Running 1 test from 1 test case.

[----------] Global test environment set-up.

[----------] 1 test from SanitizerCommon

[ RUN      ] SanitizerCommon.SizeClassAllocator64DynamicGetBlockBegin

==2408==ERROR: SanitizerTool failed to allocate 0x10000 (65536) bytes of memory at address 0xd7147a000 (error code: 1455)
==2408==Dumping process modules:
ERROR: Failed to mmap

********************
Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.
FAIL: SanitizerCommon-Unit :: Sanitizer-x86_64-Test.exe/SanitizerCommon.SizeClassAllocator64CompactGetBlockBegin (27397 of 28319)
******************** TEST 'SanitizerCommon-Unit :: Sanitizer-x86_64-Test.exe/SanitizerCommon.SizeClassAllocator64CompactGetBlockBegin' FAILED ********************
Note: Google Test filter = SanitizerCommon.SizeClassAllocator64CompactGetBlockBegin

[==========] Running 1 test from 1 test case.

[----------] Global test environment set-up.

[----------] 1 test from SanitizerCommon

[ RUN      ] SanitizerCommon.SizeClassAllocator64CompactGetBlockBegin

==2676==ERROR: SanitizerTool failed to allocate 0x10000 (65536) bytes of memory at address 0xd6fa78000 (error code: 1455)
==2676==Dumping process modules:
ERROR: Failed to mmap

********************
Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. 
Testing Time: 419.96s
********************
Failing Tests (3):
    SanitizerCommon-Unit :: Sanitizer-x86_64-Test.exe/SanitizerCommon.SizeClassAllocator64CompactGetBlockBegin
    SanitizerCommon-Unit :: Sanitizer-x86_64-Test.exe/SanitizerCommon.SizeClassAllocator64DynamicGetBlockBegin
    SanitizerCommon-Unit :: Sanitizer-x86_64-Test.exe/SanitizerCommon.SizeClassAllocator64GetBlockBegin



etienneb, that's probably your test? Maybe that test doesn't pass on win7? Does that need an xfail?

No, that test fails because ASAN shadow memory on Windows has all the pages backed by the page file. And these slaves don't currently have enough space for that. I have filed a bug to restart those slaves: https://crbug.com/635087

Are you sure that's the cause? https://viceroy.corp.google.com/chrome_infra/Machines/per_machine?hostname=vm166-m4 claims that vm166-m4 has > 80% free memory at least...

Based on the uptime graph here: https://viceroy.corp.google.com/chrome_infra/Machines/per_machine?hostname=vm166-m4 the slave had been up for 140 hours and rebooted less than an hour ago.

And the slave made 2 unsuccessful builds today:
https://build.chromium.org/p/tryserver.chromium.win/buildslaves/vm166-m4

Which means it was not rebooted in between them, if we're to believe the graph.

Hm... no. It is autoreboot. The graph shows it, but it's hard to spot, as 140 hours >> 0.5 hours. Sorry for the noise.

It was rebooted, it's just hard to see due to the y axis being 120 hours (slaves reboot after builds, so I guess that slave didn't get a build scheduled for 120 hours before today's 2 builds). If you click the uptime graph, then use the mousewheel you can zoom in. If you zoom in and then pan to the right often enough, you can see an uptime drop between the two builds today.

re #60:

>Are you sure that's the cause? >https://viceroy.corp.google.com/chrome_infra/Machines/per_machine?hostname=vm166-m4 claims that vm166-m4 has > 80% free memory at least...

Potentially, you can get "System error #1455: The paging file is too small for this operation to complete" even if there's enough physical RAM available. Is there a way to see the size of the page file on the bots?

Filed  https://crbug.com/635108  for lld sync issue.

I can repro the asan x64 win test failures on my windows box. I filed https://llvm.org/bugs/show_bug.cgi?id=28875 for that. I guess that blocks rolling as well :-(

r277882 disables the failing asan64 tests. (But the llvm buildbot is currently very red, so not safe to roll to)

Looks like someone reverted the cause for redness (or at least one of them). Another binary build attempt is at https://codereview.chromium.org/2221653002

And another attempt at https://codereview.chromium.org/2212393004 with yet a few more asan64 tests disabled.

I'm running to the train now, will check back later.

Attempt at #70 failed on all platforms. Another attempt: https://codereview.chromium.org/2224503003

That includes a few fixes from Reid up to r277898.

The mac bots failed with

-- Testing: 27289 tests, 8 threads --
Testing: 0 
FAIL: LLVM-Unit :: Analysis/AnalysisTests/BlockFrequencyInfoTest.Basic (633 of 27289)
******************** TEST 'LLVM-Unit :: Analysis/AnalysisTests/BlockFrequencyInfoTest.Basic' FAILED ********************
Note: Google Test filter = BlockFrequencyInfoTest.Basic
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from BlockFrequencyInfoTest
[ RUN      ] BlockFrequencyInfoTest.Basic
/b/build/slave/mac_upload_clang/build/src/third_party/llvm/unittests/Analysis/BlockFrequencyInfoTest.cpp:76: Failure
Value of: BB1Freq + BB2Freq
  Actual: 1
Expected: BB0Freq
Which is: 18446744073709551615
/b/build/slave/mac_upload_clang/build/src/third_party/llvm/unittests/Analysis/BlockFrequencyInfoTest.cpp:81: Failure
Value of: 100 * BB1Freq / BB0Freq
  Actual: 0
Expected: BFI.getBlockProfileCount(BB1).getValue()
Which is: 37
/b/build/slave/mac_upload_clang/build/src/third_party/llvm/unittests/Analysis/BlockFrequencyInfoTest.cpp:82: Failure
Value of: 100 * BB2Freq / BB0Freq
  Actual: 0
Expected: BFI.getBlockProfileCount(BB2).getValue()
Which is: 62
[  FAILED  ] BlockFrequencyInfoTest.Basic (1 ms)
[----------] 1 test from BlockFrequencyInfoTest (1 ms total)

[----------] Global test environment tear-down
[==========] 1 test from 1 test case ran. (1 ms total)
[  PASSED  ] 0 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] BlockFrequencyInfoTest.Basic

 1 FAILED TEST

********************
Testing: 0 
FAIL: LLVM-Unit :: Support/SupportTests/ScaledNumberHelpersTest.getQuotient (1500 of 27289)
******************** TEST 'LLVM-Unit :: Support/SupportTests/ScaledNumberHelpersTest.getQuotient' FAILED ********************
Note: Google Test filter = ScaledNumberHelpersTest.getQuotient
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from ScaledNumberHelpersTest
[ RUN      ] ScaledNumberHelpersTest.getQuotient
/b/build/slave/mac_upload_clang/build/src/third_party/llvm/unittests/Support/ScaledNumberTest.cpp:185: Failure
Value of: getQuotient64(9, 3)
  Actual: (3, -60)
Expected: SP64((3ULL) << 60, -60)
Which is: 3458764513820540928*2^-60
/b/build/slave/mac_upload_clang/build/src/third_party/llvm/unittests/Support/ScaledNumberTest.cpp:186: Failure
Value of: getQuotient64(63, 7)
  Actual: (9, -58)
Expected: SP64((9ULL) << 58, -58)
Which is: 2594073385365405696*2^-58
/b/build/slave/mac_upload_clang/build/src/third_party/llvm/unittests/Support/ScaledNumberTest.cpp:189: Failure
Value of: getQuotient64(1, 3)
  Actual: (12297829382473034411, -128)
Expected: SP64(0xaaaaaaaaaaaaaaab, -65)
Which is: 12297829382473034411*2^-65
/b/build/slave/mac_upload_clang/build/src/third_party/llvm/unittests/Support/ScaledNumberTest.cpp:190: Failure
Value of: getQuotient64(5, 3)
  Actual: (15372286728091293013, -124)
Expected: SP64(0xd555555555555555, -63)
Which is: 15372286728091293013*2^-63
[  FAILED  ] ScaledNumberHelpersTest.getQuotient (0 ms)
[----------] 1 test from ScaledNumberHelpersTest (0 ms total)


I don't see anything fixing those problems.

I had to revert https://codereview.chromium.org/2220113002/ as it was the fastest way to unblock clang_upload bots.

(Linux failed with that too)

Broken on http://lab.llvm.org:8011/builders/clang-x64-ninja-win7 too

Started here: http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/14599 Either r277877 or one of the dannyb commits.

That is resolved, it looks like I successfully built binaries at r277909 at https://codereview.chromium.org/2220793002/

I wanted to push them to goma, but apparently my linux box is down -- at least I can't ssh in. If someone can push them to goma, that'd be cool. Else I'll do it Monday morning.

Oh nevermind, it works. (Secure Shell for some reason doesn't work, but SSHInAWin does)

That roll has problems:

1. when building cast_shell_android:

FAILED: obj/skia/skia/SkLightingImageFilter.o 
/b/c/cipd/goma/gomacc ../../third_party/llvm-build/Release+Asserts/bin/clang++ -MMD -MF obj/skia/skia/SkLightingImageFilter.o.d -DV8_DEPRECATION_WARNINGS -DENABLE_NOTIFICATIONS -DENABLE_BROWSER_CDMS -DENABLE_PLUGINS=1 -DENABLE_SPELLCHECK=1 -DUSE_BROWSER_SPELLCHECKER=1 -DUSE_OPENSSL_CERTS=1 -DNO_TCMALLOC -DUSE_EXTERNAL_POPUP_MENU=1 -DENABLE_WEBRTC=1 -DDISABLE_NACL -DUSE_PROPRIETARY_CODECS -DSAFE_BROWSING_DB_REMOTE -DCHROMIUM_BUILD -DENABLE_WEBVR -DFIELDTRIAL_TESTING_ENABLED -DCR_CLANG_REVISION=277909-1 -D_FILE_OFFSET_BITS=64 -DANDROID -DHAVE_SYS_UIO_H -DANDROID_NDK_VERSION=r10e -D__GNU_SOURCE=1 -D__compiler_offsetof=__builtin_offsetof -Dnan=__builtin_nan -D_DEBUG -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DWTF_USE_DYNAMIC_ANNOTATIONS=1 -DSK_IGNORE_DW_GRAY_FIX -DSK_IGNORE_LINEONLY_AA_CONVEX_PATH_OPTS -DSK_SUPPORT_GPU=1 -DSK_BUILD_FOR_ANDROID -DUSE_CHROMIUM_SKIA -DSK_ARM_HAS_NEON -DSK_GAMMA_APPLY_TO_A8 -DSK_GAMMA_EXPONENT=1.4 -DSK_GAMMA_CONTRAST=0.0 -DSK_DEFAULT_FONT_CACHE_LIMIT=1048576 -DXML_STATIC -I../.. -Igen -I../../skia/config -I../../skia/ext -I../../third_party/skia/include/c -I../../third_party/skia/include/config -I../../third_party/skia/include/core -I../../third_party/skia/include/effects -I../../third_party/skia/include/images -I../../third_party/skia/include/lazy -I../../third_party/skia/include/pathops -I../../third_party/skia/include/pdf -I../../third_party/skia/include/pipe -I../../third_party/skia/include/ports -I../../third_party/skia/include/utils -I../../third_party/skia/include/gpu -I../../third_party/skia/src/gpu -I../../third_party/skia/include/private -I../../third_party/skia/include/client/android -I../../third_party/skia/src/core -I../../third_party/skia/src/image -I../../third_party/skia/src/opts -I../../third_party/skia/src/pdf -I../../third_party/skia/src/ports -I../../third_party/skia/src/sfnt -I../../third_party/skia/src/utils -I../../third_party/skia/src/lazy -I../../third_party/zlib -I../../third_party/android_tools/ndk/sources/android/cpufeatures -I../../third_party/expat/files/lib -I../../third_party/freetype-android/include -I../../third_party/freetype-android/src/include -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -funwind-tables -fPIC -pipe -fcolor-diagnostics -ffunction-sections -fno-short-enums --target=arm-linux-androideabi -march=armv7-a -mfloat-abi=softfp -mthumb -mtune=generic-armv7-a -mfpu=neon -Os -fdata-sections -ffunction-sections -fomit-frame-pointer -g1 --sysroot=../../third_party/android_tools/ndk/platforms/android-16/arch-arm -fvisibility=hidden -Xclang -load -Xclang ../../third_party/llvm-build/Release+Asserts/lib/libFindBadConstructs.so -Xclang -add-plugin -Xclang find-bad-constructs -Xclang -plugin-arg-find-bad-constructs -Xclang check-templates -Xclang -plugin-arg-find-bad-constructs -Xclang follow-macro-expansion -Xclang -plugin-arg-find-bad-constructs -Xclang check-implicit-copy-ctors -Werror -Wall -Wno-unused-variable -Wno-missing-field-initializers -Wno-unused-parameter -Wno-c++11-narrowing -Wno-covered-switch-default -Wno-deprecated-register -Wno-unneeded-internal-declaration -Wno-inconsistent-missing-override -Wno-shift-negative-value -Wno-undefined-var-template -Wno-nonportable-include-path -fno-threadsafe-statics -fvisibility-inlines-hidden -Wno-undefined-bool-conversion -Wno-tautological-undefined-compare -std=gnu++11 -fno-rtti -isystem../../third_party/android_tools/ndk/sources/cxx-stl/llvm-libc++/libcxx/include -isystem../../third_party/android_tools/ndk/sources/cxx-stl/llvm-libc++abi/libcxxabi/include -isystem../../third_party/android_tools/ndk/sources/android/support/include -fno-exceptions -Wno-deprecated -c ../../third_party/skia/src/effects/SkLightingImageFilter.cpp -o obj/skia/skia/SkLightingImageFilter.o
clang: /b/build/slave/linux_upload_clang/build/src/third_party/llvm/lib/CodeGen/MachineBasicBlock.cpp:1184: MachineBasicBlock::const_probability_iterator llvm::MachineBasicBlock::getProbabilityIterator(MachineBasicBlock::const_succ_iterator) const: Assertion `index < Probs.size() && "Not a current successor!"' failed.
#0 0x0000000001921cc5 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/b/c/b/cast_shell_android/src/third_party/llvm-build/Release+Asserts/bin/clang+0x1921cc5)
#1 0x00000000019223a6 (/b/c/b/cast_shell_android/src/third_party/llvm-build/Release+Asserts/bin/clang+0x19223a6)
#2 0x00007f7695b08cb0 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0xfcb0)
#3 0x00007f7694712035 gsignal /build/eglibc-oqps9y/eglibc-2.15/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:64:0
#4 0x00007f769471579b abort /build/eglibc-oqps9y/eglibc-2.15/stdlib/abort.c:93:0
#5 0x00007f769470ae1e __assert_fail_base /build/eglibc-oqps9y/eglibc-2.15/assert/assert.c:55:0
#6 0x00007f769470aec2 (/lib/x86_64-linux-gnu/libc.so.6+0x2eec2)
#7 0x00000000012968df llvm::MachineBasicBlock::getSuccProbability(__gnu_cxx::__normal_iterator<llvm::MachineBasicBlock* const*, std::vector<llvm::MachineBasicBlock*, std::allocator<llvm::MachineBasicBlock*> > >) const (/b/c/b/cast_shell_android/src/third_party/llvm-build/Release+Asserts/bin/clang+0x12968df)
#8 0x000000000125ff60 (/b/c/b/cast_shell_android/src/third_party/llvm-build/Release+Asserts/bin/clang+0x125ff60)
#9 0x00000000012bcd96 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/b/c/b/cast_shell_android/src/third_party/llvm-build/Release+Asserts/bin/clang+0x12bcd96)
#10 0x0000000001541ecf llvm::FPPassManager::runOnFunction(llvm::Function&) (/b/c/b/cast_shell_android/src/third_party/llvm-build/Release+Asserts/bin/clang+0x1541ecf)
#11 0x000000000154211b llvm::FPPassManager::runOnModule(llvm::Module&) (/b/c/b/cast_shell_android/src/third_party/llvm-build/Release+Asserts/bin/clang+0x154211b)
#12 0x00000000015425f5 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/b/c/b/cast_shell_android/src/third_party/llvm-build/Release+Asserts/bin/clang+0x15425f5)
#13 0x0000000001a9a157 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream> >) (/b/c/b/cast_shell_android/src/third_party/llvm-build/Release+Asserts/bin/clang+0x1a9a157)
#14 0x0000000002167efc (/b/c/b/cast_shell_android/src/third_party/llvm-build/Release+Asserts/bin/clang+0x2167efc)
#15 0x0000000001e85f3c clang::MultiplexConsumer::HandleTranslationUnit(clang::ASTContext&) (/b/c/b/cast_shell_android/src/third_party/llvm-build/Release+Asserts/bin/clang+0x1e85f3c)
#16 0x0000000002535486 clang::ParseAST(clang::Sema&, bool, bool) (/b/c/b/cast_shell_android/src/third_party/llvm-build/Release+Asserts/bin/clang+0x2535486)
#17 0x0000000001e4e0a5 clang::FrontendAction::Execute() (/b/c/b/cast_shell_android/src/third_party/llvm-build/Release+Asserts/bin/clang+0x1e4e0a5)
#18 0x0000000001e17911 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/b/c/b/cast_shell_android/src/third_party/llvm-build/Release+Asserts/bin/clang+0x1e17911)
#19 0x0000000001ee063e clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/b/c/b/cast_shell_android/src/third_party/llvm-build/Release+Asserts/bin/clang+0x1ee063e)
#20 0x0000000000787b2c cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (/b/c/b/cast_shell_android/src/third_party/llvm-build/Release+Asserts/bin/clang+0x787b2c)
#21 0x0000000000785fad main (/b/c/b/cast_shell_android/src/third_party/llvm-build/Release+Asserts/bin/clang+0x785fad)
#22 0x00007f76946fd7ed __libc_start_main /build/eglibc-oqps9y/eglibc-2.15/csu/libc-start.c:258:0
#23 0x0000000000783542 _start (/b/c/b/cast_shell_android/src/third_party/llvm-build/Release+Asserts/bin/clang+0x783542)
Stack dump:
0.	Program arguments: /b/c/b/cast_shell_android/src/third_party/llvm-build/Release+Asserts/bin/clang -cc1 -triple thumbv7--linux-android -emit-obj -disable-free -main-file-name SkLightingImageFilter.cpp -mrelocation-model pic -pic-level 2 -mthread-model posix -relaxed-aliasing -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu cortex-a8 -target-feature +soft-float-abi -target-feature -fp-only-sp -target-feature -d16 -target-feature +vfp3 -target-feature -fp16 -target-feature -vfp4 -target-feature -fp-armv8 -target-feature +neon -target-feature -crypto -target-abi aapcs-linux -mfloat-abi soft -dwarf-column-info -debug-info-kind=line-tables-only -dwarf-version=4 -debugger-tuning=gdb -ffunction-sections -fdata-sections -coverage-file /b/c/b/cast_shell_android/src/out/Debug/obj/skia/skia/SkLightingImageFilter.o -resource-dir /b/c/b/cast_shell_android/src/third_party/llvm-build/Release+Asserts/bin/../lib/clang/4.0.0 -dependency-file obj/skia/skia/SkLightingImageFilter.o.d -MT obj/skia/skia/SkLightingImageFilter.o -isystem ../../third_party/android_tools/ndk/sources/cxx-stl/llvm-libc++/libcxx/include -isystem ../../third_party/android_tools/ndk/sources/cxx-stl/llvm-libc++abi/libcxxabi/include -isystem ../../third_party/android_tools/ndk/sources/android/support/include -D V8_DEPRECATION_WARNINGS -D ENABLE_NOTIFICATIONS -D ENABLE_BROWSER_CDMS -D ENABLE_PLUGINS=1 -D ENABLE_SPELLCHECK=1 -D USE_BROWSER_SPELLCHECKER=1 -D USE_OPENSSL_CERTS=1 -D NO_TCMALLOC -D USE_EXTERNAL_POPUP_MENU=1 -D ENABLE_WEBRTC=1 -D DISABLE_NACL -D USE_PROPRIETARY_CODECS -D SAFE_BROWSING_DB_REMOTE -D CHROMIUM_BUILD -D ENABLE_WEBVR -D FIELDTRIAL_TESTING_ENABLED -D CR_CLANG_REVISION=277909-1 -D _FILE_OFFSET_BITS=64 -D ANDROID -D HAVE_SYS_UIO_H -D ANDROID_NDK_VERSION=r10e -D __GNU_SOURCE=1 -D __compiler_offsetof=__builtin_offsetof -D nan=__builtin_nan -D _DEBUG -D DYNAMIC_ANNOTATIONS_ENABLED=1 -D WTF_USE_DYNAMIC_ANNOTATIONS=1 -D SK_IGNORE_DW_GRAY_FIX -D SK_IGNORE_LINEONLY_AA_CONVEX_PATH_OPTS -D SK_SUPPORT_GPU=1 -D SK_BUILD_FOR_ANDROID -D USE_CHROMIUM_SKIA -D SK_ARM_HAS_NEON -D SK_GAMMA_APPLY_TO_A8 -D SK_GAMMA_EXPONENT=1.4 -D SK_GAMMA_CONTRAST=0.0 -D SK_DEFAULT_FONT_CACHE_LIMIT=1048576 -D XML_STATIC -I ../.. -I gen -I ../../skia/config -I ../../skia/ext -I ../../third_party/skia/include/c -I ../../third_party/skia/include/config -I ../../third_party/skia/include/core -I ../../third_party/skia/include/effects -I ../../third_party/skia/include/images -I ../../third_party/skia/include/lazy -I ../../third_party/skia/include/pathops -I ../../third_party/skia/include/pdf -I ../../third_party/skia/include/pipe -I ../../third_party/skia/include/ports -I ../../third_party/skia/include/utils -I ../../third_party/skia/include/gpu -I ../../third_party/skia/src/gpu -I ../../third_party/skia/include/private -I ../../third_party/skia/include/client/android -I ../../third_party/skia/src/core -I ../../third_party/skia/src/image -I ../../third_party/skia/src/opts -I ../../third_party/skia/src/pdf -I ../../third_party/skia/src/ports -I ../../third_party/skia/src/sfnt -I ../../third_party/skia/src/utils -I ../../third_party/skia/src/lazy -I ../../third_party/zlib -I ../../third_party/android_tools/ndk/sources/android/cpufeatures -I ../../third_party/expat/files/lib -I ../../third_party/freetype-android/include -I ../../third_party/freetype-android/src/include -isysroot ../../third_party/android_tools/ndk/platforms/android-16/arch-arm -internal-isystem ../../third_party/android_tools/ndk/platforms/android-16/arch-arm/usr/local/include -internal-isystem /b/c/b/cast_shell_android/src/third_party/llvm-build/Release+Asserts/bin/../lib/clang/4.0.0/include -internal-externc-isystem ../../third_party/android_tools/ndk/platforms/android-16/arch-arm/include -internal-externc-isystem ../../third_party/android_tools/ndk/platforms/android-16/arch-arm/usr/include -Os -Werror -Wall -Wno-unused-variable -Wno-missing-field-initializers -Wno-unused-parameter -Wno-c++11-narrowing -Wno-covered-switch-default -Wno-deprecated-register -Wno-unneeded-internal-declaration -Wno-inconsistent-missing-override -Wno-shift-negative-value -Wno-undefined-var-template -Wno-nonportable-include-path -Wno-undefined-bool-conversion -Wno-tautological-undefined-compare -Wno-deprecated -std=gnu++11 -fdebug-compilation-dir /b/c/b/cast_shell_android/src/out/Debug -ferror-limit 19 -fmessage-length 0 -fvisibility hidden -fvisibility-inlines-hidden -femulated-tls -stack-protector 1 -stack-protector-buffer-size 4 -fallow-half-arguments-and-returns -fno-rtti -fno-signed-char -fno-threadsafe-statics -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp -load ../../third_party/llvm-build/Release+Asserts/lib/libFindBadConstructs.so -add-plugin find-bad-constructs -plugin-arg-find-bad-constructs check-templates -plugin-arg-find-bad-constructs follow-macro-expansion -plugin-arg-find-bad-constructs check-implicit-copy-ctors -o obj/skia/skia/SkLightingImageFilter.o -x c++ ../../third_party/skia/src/effects/SkLightingImageFilter.cpp 
1.	<eof> parser at end of file
2.	Code generation
3.	Running pass 'Function Pass Manager' on module '../../third_party/skia/src/effects/SkLightingImageFilter.cpp'.
4.	Running pass 'If Converter' on function '@_ZNK12_GLOBAL__N_120SpecularLightingType5lightERK8SkPoint3S3_S3_'
clang: error: unable to execute command: Aborted (core dumped)
clang: error: clang frontend command failed due to signal (use -v to see invocation)
clang version 4.0.0 (trunk 277909)
Target: arm--linux-android
Thread model: posix
InstalledDir: /b/c/b/cast_shell_android/src/out/Debug/../../third_party/llvm-build/Release+Asserts/bin
clang: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script.
clang: note: diagnostic msg: 
********************


This needs to be tracked down, reverted upstream, and then rolled to a version with fix.  We probably want a tot bot building in that config.


2. I forgot to up VERSION in update.py, so all asan bots fail to find asan headers etc. I'm building a new package with that addressed, and I wrote ttps://codereview.chromium.org/2224783002/ to make sure the upload bots detect this problem at upload time.

filed https://llvm.org/bugs/show_bug.cgi?id=28894 for the assert

Actually that assert is visible on https://build.chromium.org/p/chromium.fyi/builders/ClangToTAndroidASan/builds/3609/steps/compile/logs/stdio , so no need for more tot bots.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/78f40fbff7fe6ea54b0de1492268f4f5f76f6eb6

commit 78f40fbff7fe6ea54b0de1492268f4f5f76f6eb6
Author: thakis <thakis@chromium.org>
Date: Mon Aug 08 02:19:58 2016

Roll clang 274369:277962.

Ran `tools/clang/scripts/upload_revision.py 277909`.

New:
* version number is now 4.0.0
* much better debug info on Windows
* asan/win runtime detects EXCEPTION_ILLEGAL_INSTRUCTION / EXCEPTION_BREAKPOINT
* improved integrated assembler on arm
* sanitizer coverage improvements
* lto devirtualization fixes
* …and over 3500 other changes

This is the first clang roll with gn as default meta-buildsystem. With gyp,
all .o files got automatically rebuilt after clang rolls. With gn, this doesn't
always work ( https://crbug.com/612340 ). If you're getting errors about
having to rebuild pch files after this roll (on Mac and Windows), manually
run `gn gen out/gn` (or whatever your build dir is) and then build again.

BUG= 629966 
TBR=hans

Review-Url: https://codereview.chromium.org/2220793002
Cr-Commit-Position: refs/heads/master@{#410289}

[modify] https://crrev.com/78f40fbff7fe6ea54b0de1492268f4f5f76f6eb6/build/toolchain/toolchain.gni
[modify] https://crrev.com/78f40fbff7fe6ea54b0de1492268f4f5f76f6eb6/tools/clang/scripts/update.py

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1a12f0dc15e89907a833f7ad38e91bc89d4ef4e4

commit 1a12f0dc15e89907a833f7ad38e91bc89d4ef4e4
Author: thakis <thakis@chromium.org>
Date: Mon Aug 08 21:30:23 2016

clang update script: Verify that VERSION is correct.

BUG= 629966 

Review-Url: https://codereview.chromium.org/2224783002
Cr-Commit-Position: refs/heads/master@{#410467}

[modify] https://crrev.com/1a12f0dc15e89907a833f7ad38e91bc89d4ef4e4/tools/clang/scripts/update.py

The roll's been in the tree for a day, let's optimistically declare success.

Sorry to be the bearer of bad news, but Win ASAN is crashing on startup consistently on ClusterFuzz bots after this.