Progress:
* VIRT-65 [QEMU upstream maintainership]
+ More wrangling of release stuff and unreliable infrastructure.
* VIRT-364 [QEMU support for ARMv8.1-M extensions]
+ Managed to find a few days to put in some more work pushing fp16
handling forwards. I now have implementations of fp16 for most of
the VFP insns (still todo: VCVT, VSEL, VMAXNM/VMINNM, VRINT*; then
the few insns that are new-for-fp16. Then all of Neon, which is larger.)
thanks
-- PMM
Progress:
* VIRT-65 [QEMU upstream maintainership]
+ softfreeze this week, so a lot of handling of pull requests,
reviewing various patchsets, sorting through newly reported
Coverity issues, etc etc.
thanks
-- PMM
== Progress ==
* GCC upstream validation:
- reported a few regressions / minor testcase fix
- enabled gcc-testresults for release branches, which will send even more emails
* benchmarking:
- added HAL support for the stm32 board we have in the Lab. Will start
testing once the board is actually connected to a builder
* misc:
- infra patches/reviews
== Next ==
* Holidays next two weeks, back on July 28th
* GCC/cortex-M testing improvements & fixes
* cortex-m benchmarking
== Progress ==
* Uploaded binaries for llvm 10.0.1 rc3 and rc4
* More work on Morello (including docs)
== Plan ==
* More Morello
* On vacation between July 20 - 31
4 day week.
[VIRT-327 # Richard's upstream QEMU work ]
Bug hunting vs aa32 ldrex/strex. I had hoped it would be relatively easy to
reproduce -- just run something from the .NET testsuite -- but even getting
that far wasn't obvious. So I put that aside; let's see if Peter's request for
an actual reproducer gets results.
Bug hunting vs aa64 gcc sync-4.c as reported by clyon. I determined that it's
not the fault of the null-pointer dereference, and that something goes wrong
somewhere in libgcc's exception unwind prior to the c++ throw. But it doesn't
fail all of the time. And worse, the problem vanishes when randomize_va_space
is disabled. So I can neither get a "good" vs "bad" trace without needless
differences nor produce a failure under gdb. I should try again with rr and
see if that works...
r~
Linaro folks - why is this buildbot sending mail when it's already red
(looks like this buildbot has been red for a while, at least 11187
seems to be red for the same reason that 11188 is red - so the people
on this blame list aren't relevant)? That adds noise to the buildbot
results & makes it harder for developers to find actionable email.
On Mon, Jul 6, 2020 at 9:30 PM <llvm.buildmaster(a)lab.llvm.org> wrote:
>
> The Buildbot has detected a new failure on builder clang-cmake-armv7-full while building llvm.
> Full details are available at:
> http://lab.llvm.org:8011/builders/clang-cmake-armv7-full/builds/11188
>
> Buildbot URL: http://lab.llvm.org:8011/
>
> Buildslave for this Build: linaro-tk1-08
>
> Build Reason: scheduler
> Build Source Stamp: [branch master] 0c6b6e28e70c06a3cb4704d2d8f90829a689e230
> Blamelist: Amara Emerson <amara(a)apple.com>,Amy Kwan <amy.kwan1(a)ibm.com>,Biplob Mishra <biplmish(a)in.ibm.com>,David Blaikie <dblaikie(a)gmail.com>,Eric Christopher <echristo(a)gmail.com>,Jordan Rupprecht <rupprecht(a)google.com>,LLVM GN Syncbot <llvmgnsyncbot(a)gmail.com>,Nico Weber <thakis(a)chromium.org>,Sanjay Patel <spatel(a)rotateright.com>,Wolfgang Pieb <wolfgang_pieb(a)playstation.sony.com>,Yuanfang Chen <yuanfang.chen(a)sony.com>
>
> BUILD FAILED: failed build stage 2
>
> sincerely,
> -The Buildbot
>
>
>
== Progress ==
* GCC upstream validation:
- reported a few regressions
- added fortran to arm-none-eabi configs
- enabled gcc-testresults for most configurations, which now sends a
lot of emails
* GCC:
- PR94743 (IRQ handler and Neon registers): patch committed.
* benchmarking:
- cleanup of hal lib to run benchmarks on stm32, the board we have in
TCWG is different from the ones we used in ST, I'll have to update the
hal settings accordingly.
* misc:
- switch tcwg_gnu job to use our gcc-compare-results script, to be
able to ignore some tests with random results (especially under qemu)
== Next ==
* GCC/cortex-M testing improvements & fixes
* cortex-m benchmarking
