I have just tagged the 10.0.1-rc1 release. Testers can begin testing and uploading
binaries.
If you still want to get a fix into the 10.0.1 release, you still have about a month
to get your fix in. To request a patch be backported to the release/10.x branch,
file a bug and mark it as a blocker of the release-10.0.1 meta bug.
I finished testing llvm-10.0.1 RC1 on Power PC 64bit Little Endian Ubuntu 16.04 machine and have uploaded the binary from IBM.
There were no regressions. The sha1 file is attached.
I finished testing llvm-10.0.1 RC1 on Power PC 64bit Little Endian Red Hat 7.4 machine and have uploaded the binary from IBM.
There were no regressions. The sha1 file is attached.
Thanks a lot. Just out of curiosity regarding 10.0.1, will it somehow
address the 7%-8% of performance loss that some users reported, or
will that be postponed to 11.0.0?
Thanks a lot. Just out of curiosity regarding 10.0.1, will it somehow
address the 7%-8% of performance loss that some users reported, or
will that be postponed to 11.0.0?
I don't know yet, there is still 1 month left of 10.0.1 stabilization.
Someone would need to pinpoint the issues and propose a fix for it.
but none of the regression tests could run, due to a lit/googletest exception:
llvm-lit: /home/dim/llvm/10.0.1/rc1/llvm-project/llvm/utils/lit/lit/formats/googletest.py:43: warning: unable to discover google-tests in '/home/dim/llvm/10.0.1/rc1/Phase3/Release/llvmCore-10.0.1-rc1.obj/tools/mlir/unittests/Dialect/SPIRV/./MLIRSPIRVTests': Command '['/home/dim/llvm/10.0.1/rc1/Phase3/Release/llvmCore-10.0.1-rc1.obj/tools/mlir/unittests/Dialect/SPIRV/./MLIRSPIRVTests', '--gtest_list_tests']' returned non-zero exit status 1.. Process output: b''
Traceback (most recent call last):
File "/home/dim/llvm/10.0.1/rc1/llvm-project/llvm/utils/lit/lit/formats/googletest.py", line 39, in getGTestTests
env=localConfig.environment)
File "/usr/local/lib/python3.7/subprocess.py", line 411, in check_output
**kwargs).stdout
File "/usr/local/lib/python3.7/subprocess.py", line 512, in run
output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command '['/home/dim/llvm/10.0.1/rc1/Phase3/Release/llvmCore-10.0.1-rc1.obj/tools/mlir/unittests/Dialect/SPIRV/./MLIRSPIRVTests', '--gtest_list_tests']' returned non-zero exit status 1.
Running the MLIRSPIRVTests executable shows the actual problem:
$ /home/dim/llvm/10.0.1/rc1/Phase3/Release/llvmCore-10.0.1-rc1.obj/tools/mlir/unittests/Dialect/SPIRV/./MLIRSPIRVTests
Shared object "libc++abi.so.1" not found, required by "MLIRSPIRVTests"
On FreeBSD we use libcxxrt, not libc++abi. Does anybody have an idea why this appears to have changed between 10.0.0 and 10.0.1? And if so, how I tell the build not to link against libc++abi?
Just FYI, the sky seems to have fallen on me here. I'm not really sure
why it worked before but a lot of parts of clang fail now due to
duplicate registered command-line options. I will file bugs when I'm
done figuring out all the fixes but giving you an early heads-up.
Ok, it turns out my issues were due to py3.7+. I've requested
backporting one lit patch and with it, there are no new regressions.
However, it made me notice that some clangd unittest are failing to
execute with duplicate command-line option errors but the errors are
ignored by lit. It happens when clang is linked to dylib, and it is
non-trivial to fix and I'm not sure if I'll be able to fix it myself.
Any and all help appreciated.
I've tried to see if it is fixed in master but I can't seem to manage to
find a recent clang revision that wouldn't segfault all the way.
Uploaded binaries for ARM & AArch64:
e7cdf76722c9f5b90ec3f5d0e6cf5545badc6a7eaf8477b764a25845aee9a844 clang+llvm-10.0.1-rc1-aarch64-linux-gnu.tar.xz
a11427f38283a522a22f4799c40518b09b72bdd4170ecb456544b459f74d1fc3 clang+llvm-10.0.1-rc1-armv7a-linux-gnueabihf.tar.xz
AArch64 is green (yay! IIRC 10.0.0 had an issue).
For ARM we still have PR44157 & PR44158 (which we also had for llvm 10.0.0), and I have also opened PR46092 and PR46093 for some new failures. I’ll try to have a quick look to see if they’re environment problems or if we can bisect them.