== Progress ==
* GCC upstream validation:
- a couple of regressions to bisect.
- minor testcase fix
- reported a couple of new failures
* GCC
- MVE autovectorization:
- vcmp support mostly complete. Minor update needed to support FP types.
- working on interleaved vector load/store support
* Misc
- fixed stm32 benchmarking harness, it's working again.
- submitted patches to reduce the toolchain build time (for
benchmarking we don't need all multilibs which take ages to build)
== Next ==
* MVE auto-vectorization/intrinsics improvements
* GCC/cortex-M testing improvements & fixes
* cortex-m benchmarking
Hi
I've been trying to run clang on a Windows on Arm machine, but it keeps trying to using the link.exe located in "Visual studio/..../Host64/arm64", which is (seemingly) an x64 tool and as such doesn't run, and crashes the process.
Is there a way to set clang to look at VS's x86 link.exe? Or if there is an arm64 version that clang should be using instead?
Thanks,
Joel
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi,
I've been trying to use clang on Windows on Arm machine (Samsung Galaxy Book S), but whenever I try to use it, I get either nothing (in powershell) or an error popup: "The application was unable to start correctly (0x000007b)".
The release I'm using is LLVM-12.0.0-rc1-woa64.exe<https://github.com/llvm/llvm-project/releases/download/llvmorg-12.0.0-rc1/L…> from https://github.com/llvm/llvm-project/releases/tag/llvmorg-12.0.0-rc1
I have a feeling there might be a library or dependency I am missing.
Any help with how to resolve this issue would be appreciated.
Thanks,
Joel
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
[UM-2 # QEMU Upstream Work]
* A lot of patch review.
* Some target/i386 cleanup, as followup to said patch review.
* Collecting patches for tcg-next.
r~
== 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
