All,
During Connect the suggestion was made that each working group should have
its own IRC Channel for discussions and topics relating to the group in
particular (as opposed to #linaro which is 'generic' Linaro conversations).
Therefore I have just set up #linaro-tcwg on Freenode for the Toolchain
Working Group.
This channel is public and open to anyone who wants to talk with the TCWG
group about anything toolchain related.
Thanks,
Matt
--
Matthew Gretton-Dann
Toolchain Working Group, Linaro
Folks,
I am pleased to announce the move of libc++ to pre-commit CI. Over the past
few months, we have set up Buildkite jobs on top of the Phabricator
integration built by Mikhail and Christian, and we now run almost all of
the libc++ build bots whenever a Phabricator review is created. The bots
also run when a commit is pushed to the master branch, similarly to the
existing Buildbot setup. You can see the libc++ pipeline in action here:
https://buildkite.com/llvm-project/libcxx-ci.
This is great -- we’ve been waiting to set up pre-commit CI for a long
time, and we’ve seen a giant productivity gain since it’s up. I think
everyone who contributes to libc++ greatly benefits, seeing how reviews are
now used to trigger CI and improve our confidence in changes.
This change does have an impact on existing build bots that are not owned
by one of the libc++ maintainers. While I transferred the build bots that
we owned (which Eric had set up) to Buildkite, the remaining build bots
will have to be moved to Buildkite by their respective owners. These builds
bots are (owners in CC):
libcxx-libcxxabi-x86_64-linux-debian
libcxx-libcxxabi-x86_64-linux-debian-noexceptions
libcxx-libcxxabi-libunwind-x86_64-linux-debian
libcxx-libcxxabi-singlethreaded-x86_64-linux-debian
libcxx-libcxxabi-libunwind-armv7-linux
libcxx-libcxxabi-libunwind-armv8-linux
libcxx-libcxxabi-libunwind-armv7-linux-noexceptions
libcxx-libcxxabi-libunwind-armv8-linux-noexceptions
libcxx-libcxxabi-libunwind-aarch64-linux
libcxx-libcxxabi-libunwind-aarch64-linux-noexceptions
The process of moving these bots over to Buildkite is really easy. Please
take a look at the documentation at
https://libcxx.llvm.org/docs/AddingNewCIJobs.html#addingnewcijobs and
contact me if you need additional help.
To make sure we get the full benefits of pre-commit CI soon, I would like
to put a cutoff date on supporting the old libc++ builders at
http://lab.llvm.org:8011/builders. I would propose that after January 1st
2021 (approx. 1 month from now), the libc++ specific build bots at
lab.llvm.org be removed in favor of the Buildkite ones. If you currently
own a bot, please make sure to add an equivalent Buildkite bot by that
cutoff date to make sure your configuration is still supported, or let me
know if you need an extension.
Furthermore, with the ease of creating new CI jobs with this
infrastructure, we will consider any libc++ configuration not covered by a
pre-commit bot as not explicitly supported. It doesn’t mean that such
configurations won’t work -- it just means that we won’t be making bold
claims about supporting configurations we’re unable to actually test. So if
you care about a configuration, please open a discussion and let’s see how
we can make sure it's tested properly!
I am thrilled to be moving into the pre-commit CI era. The benefits we see
so far are huge, and we're loving it.
Thanks,
Louis
PS: This has nothing to do with a potential move or non-move to GitHub. The
current pre-commit CI works with Phabricator, and would work with GitHub if
we decided to switch. Let’s try to keep those discussions separate :-).
PPS: We’re still aiming to support non libc++ specific Buildbots. For
example, if something in libc++ breaks a Clang bot, we’ll still be
monitoring that. I’m just trying to move the libc++-specific configurations
to pre-commit.
== Progress ==
* GCC upstream validation:
- a few regressions to bisect. Fixed a minor testcase issue
* GCC
- MVE autovectorization: Working on vcmp. After some cleanup &
factorization, the cmp operators work on GCC vectors. I will now
resume work on auto-vectorization.
* Misc
- fixes in stm32 benchmarking harness
== Next ==
* MVE auto-vectorization/intrinsics improvements
* GCC/cortex-M testing improvements & fixes
* cortex-m benchmarking
* After proving that the aarch64 host problem with
booting s390x with virtio was lack of barriers for
the guest memory model, I've spent some time working
on a ld-acq/st-rel optimizer for tcg.
* Minor rev of tci rewrite.
* Some patch review on claudio's kvm/tcg split.
r~
Progress:
* QEMU-364 [QEMU support for ARMv8.1-M extensions]
+ sent out v2 of the MPS3-AN524 series (minor changes only)
+ discovered that I need to implement the SSE-300's System Counter
+ implemented the system counter, did some final testing and
reviewing, and sent out v1 of the MPS3-AN547 series to the list
+ once these patches are reviewed and in master the QEMU-413 epic
will be complete
-- PMM
Hello Linaro Toolchain Working Group,
libcxx-libcxxabi-libunwind-armv8-linux has been red for 5 days.
clang-cmake-aarch64-global-isel has been red for 10 days.
clang-cmake-aarch64-quick has been red for 10 days.
clang-cmake-armv7-global-isel has been red for 10 days.
clang-cmake-armv7-lnt has been red for 10 days.
clang-cmake-aarch64-lld has been red for 11 days.
clang-cmake-armv8-lld has been red for 11 days.
clang-cmake-thumbv7-full-sh has been red for 11 days.
clang-cmake-armv7-full has been red for 11 days.
Is anybody looking at this?
I also noticed that some of your workers are less reliable than others. For
example, inaro-tk1-09 worker was last time producing a green build 2 months
ago - http://lab.llvm.org:8011/#/workers/2?numbuilds=500
I'm removing the linaro-tk1-09 worker from the production buildbot for now.
Please feel free to connect it to the staging and make the builder reliably
green. Then it could be returned back to the production.
linaro-armv8-windows-msvc-01 and linaro-armv8-windows-msvc-02 have been red
for the least 4 months. I'm removing them from the production buildbot. You
can return them back to production after they are reliably green in the
staging.
Please feel free to ask if you have questions.
Thanks
Galina
== Progress ==
* GCC upstream validation:
- a few regressions to bisect. Fixed a minor testcase issue
- native validation in Linaro's lab: we still see a few random results
* GCC
- MVE autovectorization: Working on vcmp.
* Misc
- fixes in stm32 benchmarking harness
== Next ==
* MVE auto-vectorization/intrinsics improvements
* GCC/cortex-M testing improvements & fixes
* cortex-m benchmarking
Holidays next week, back Monday 22nd Feb
Progress:
* UM-2 [QEMU upstream maintainership]
+ sent out a small code-cleanup patchset for some arm display device
models to remove no-longer-needed support for non-32bpp outputs
+ tracked down (with the aid of Paolo) why our build system had started
building the documentation every time you run 'make'; sent a fix
+ code review todo queue status: 12 items, but the oldest was only
sent to the list on Monday...
* QEMU-364 [QEMU support for ARMv8.1-M extensions]
+ An MPS3 Cortex-M55 FPGA image is now publicly available: the AN547.
We'll provide a model of this in QEMU. Started working on the
patchseries to implement it (relatively small changes on top of
the SSE-300 work I've already done but not sent out, and the
mps3-an524 series I sent out for review last week). This is basically
code-complete but I need to do some more testing and ideally I'd
like the AN524 series to get reviewed before I send out another
40-patch series that would have to be based on top of that one.
thanks
-- PMM
