Hi,
I've tagged 10.0.1-rc4, please test and report the results.
-Tom
Uploaded Ubuntu 20.04
sha256sum clang+llvm-10.0.1-rc4-x86_64-unknown-linux-gnu.tar.xz
b3ccab7f6667311f36970b70ebf924f2431b14446d9722603a1a9c80a168489c
15 warning(s) in tests
Testing Time: 502.07s
Expected Passes : 67745
Expected Failures : 269
Unsupported Tests : 1946
[100%] Built target check-all
Neil Nelson
Hi,
Uploaded ARM & AArch64:
4d46ad0ecfc32a8835e9b9f10af8a07a74f9c7f6618d3cd99e5197748bde32a9
clang+llvm-10.0.1-rc4-aarch64-linux-gnu.tar.xz
f0a1f2849d03abe0dc9ff0fdec920e6c38966d277c938fb4b0aefda3edfdb5fb
clang+llvm-10.0.1-rc4-armv7a-linux-gnueabihf.tar.xz
AArch64 is green and ARM has no new failures.
Cheers,
Diana
For this rc, I used four patches, which are attached.
Main results on amd64-freebsd11:
Expected Passes : 67554
Passes With Retry : 1
Expected Failures : 265
Unsupported Tests : 5114
Unexpected Passes : 2
Unexpected Failures: 513
Individual Timeouts: 11
Test suite results on amd64-freebsd11:
Expected Passes : 2398
Unexpected Failures: 3
Main results on i386-freebsd11:
Expected Passes : 64619
Passes With Retry : 1
Expected Failures : 248
Unsupported Tests : 3541
Unexpected Passes : 1
Unexpected Failures: 192
Individual Timeouts: 7
Uploaded:
SHA256 (clang+llvm-10.0.1-rc4-amd64-unknown-freebsd11.tar.xz) = 26b4d7554bee13386978766a4c3efb1a71569dd885c5c79673a3e69c16478286
SHA256 (clang+llvm-10.0.1-rc4-i386-unknown-freebsd11.tar.xz) = b4640a5efd146899f1daaa34ab33994d3f9600fbcb3593aad203102a2175925e
-Dimitry
fix-clang-1.diff (447 Bytes)
fix-compiler-rt-1.diff (890 Bytes)
fix-libcxx-1.diff (987 Bytes)
fix-test-suite-1.diff (552 Bytes)
Why are these patches not applied to the repository?
Uploaded:
dcf43e25a77a2ffb4ffaa5a04babe409b2b3ffac07bc989a1dca730ecacb43c2 clang+llvm-10.0.1-rc4-x86_64-linux-sles12.4.tar.xz
6db54d9f55fb41877b23f4b89e7b68d44fcc5378d615d232c820307237dc33f7 clang+llvm-10.0.1-rc2-x86_64-linux-sles12.4.tar.xz
2d907945d8d8d5d2969c6947c50d91e100d5dd09ccb37214a811c11cbfa635af clang+llvm-10.0.1-rc3-x86_64-linux-sles12.4.tar.xz
ccdfda65932661e5fd4faba1fde17fe3800f39b4c21687242b7cdfdbea4cf131 clang+llvm-10.0.1-rc3-x86_64-linux-gnu-ubuntu-16.04.tar.xz
761a6f4658545f733f14dcd6c50a16b49994a4c448c779616c5716eed80b90f1 clang+llvm-10.0.1-rc4-x86_64-linux-gnu-ubuntu-16.04.tar.xz
I saw phase2/3 mismatches that seem concerning. Are these the only platforms that encountered them?
I can open a bug, let me know if there’s particular data beyond the logs I should gather.
Hello,
I finished testing llvm-10.0.1 RC4 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.
Thanks,
Anil Mahmud.
clang+llvm-10.0.1-rc4-powerpc64le-linux-ubuntu-16.04.sha1 (102 Bytes)
Hello,
I finished testing llvm-10.0.1 RC4 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,
Anil Mahmud
clang+llvm-10.0.1-rc4-powerpc64le-linux-rhel-7.4.sha1 (98 Bytes)
This one looks good on Gentoo.
Hello
rc4 looks great on Debian!
BTW, folks here might be interested by
http://lists.llvm.org/pipermail/llvm-dev/2020-July/143247.html
and
https://github.com/opencollab/llvm-toolchain-integration-test-suite/
Cheers,
Sylvestre
If there is an rc5 is it too late to get these changes in? I'd like an authoritative yes or no for the below-mentioned bug report. I'd guess it is too late but it's not my decision. And the code did just go in the tree today.
523a8513f8ba4d6b111496c541b9ba9f4d5f0261
d4ce862f2aa8b7e4b11462bd72014b08ab9468b3
Reland "[FPEnv][Clang][Driver] Disable constrained floating point on targets lacking support."
We currently have strict floating point/constrained floating point enabled
for all targets. Constrained SDAG nodes get converted to the regular ones
before reaching the target layer. In theory this should be fine.
However, the changes are exposed to users through multiple clang options
already in use in the field, and the changes are _completely_ _untested_
on almost all of our targets. Bugs have already been found, like
"https://bugs.llvm.org/show_bug.cgi?id=45274".
This patch disables constrained floating point options in clang everywhere
except X86 and SystemZ. A warning will be printed when this happens.
Use the new -fexperimental-strict-floating-point flag to force allowing
strict floating point on hosts that aren't already marked as supporting
it (X86 and SystemZ).
Differential Revision: https://reviews.llvm.org/D80952
Uploaded:
dcf43e25a77a2ffb4ffaa5a04babe409b2b3ffac07bc989a1dca730ecacb43c2 clang+llvm-10.0.1-rc4-x86_64-linux-sles12.4.tar.xz
6db54d9f55fb41877b23f4b89e7b68d44fcc5378d615d232c820307237dc33f7 clang+llvm-10.0.1-rc2-x86_64-linux-sles12.4.tar.xz
2d907945d8d8d5d2969c6947c50d91e100d5dd09ccb37214a811c11cbfa635af clang+llvm-10.0.1-rc3-x86_64-linux-sles12.4.tar.xzccdfda65932661e5fd4faba1fde17fe3800f39b4c21687242b7cdfdbea4cf131 clang+llvm-10.0.1-rc3-x86_64-linux-gnu-ubuntu-16.04.tar.xz
761a6f4658545f733f14dcd6c50a16b49994a4c448c779616c5716eed80b90f1 clang+llvm-10.0.1-rc4-x86_64-linux-gnu-ubuntu-16.04.tar.xzI saw phase2/3 mismatches that seem concerning. Are these the only platforms that encountered them?
I can open a bug, let me know if there's particular data beyond the logs I should gather.
Can you attach 2 of the binary files the are different?
-Tom
From: llvm-dev <llvm-dev-bounces@lists.llvm.org> On Behalf Of Tom Stellard
via llvm-dev
...
> Uploaded:
> dcf43e25a77a2ffb4ffaa5a04babe409b2b3ffac07bc989a1dca730ecacb43c2
> clang+llvm-10.0.1-rc4-x86_64-linux-sles12.4.tar.xz
> 6db54d9f55fb41877b23f4b89e7b68d44fcc5378d615d232c820307237dc33f7
> clang+llvm-10.0.1-rc2-x86_64-linux-sles12.4.tar.xz
> 2d907945d8d8d5d2969c6947c50d91e100d5dd09ccb37214a811c11cbfa635af
> clang+llvm-10.0.1-rc3-x86_64-linux-sles12.4.tar.xz
>
> ccdfda65932661e5fd4faba1fde17fe3800f39b4c21687242b7cdfdbea4cf131
> clang+llvm-10.0.1-rc3-x86_64-linux-gnu-ubuntu-16.04.tar.xz
> 761a6f4658545f733f14dcd6c50a16b49994a4c448c779616c5716eed80b90f1
> clang+llvm-10.0.1-rc4-x86_64-linux-gnu-ubuntu-16.04.tar.xz
>
> I saw phase2/3 mismatches that seem concerning. Are these the only
> platforms that encountered them?
>
> I can open a bug, let me know if there's particular data beyond the
> logs I should gather.
>Can you attach 2 of the binary files the are different?
Attached a few from each impacted platform. Additional notes below.
# for ubuntu16, 10.0.1-rc4:
$ grep 'differs between' rc4/logs/testing.10.0.1-rc4.log |wc -l
14
$ grep 'differs between' rc4/logs/testing.10.0.1-rc4.log
file omptarget-nvptx_intermediate_link.o differs between phase 2 and phase 3
file omptarget-nvptx_generated_target_impl.cu.o differs between phase 2 and phase 3
file omptarget-nvptx_generated_reduction.cu.o differs between phase 2 and phase 3
file omptarget-nvptx_generated_omptarget.cu.o differs between phase 2 and phase 3
file omptarget-nvptx_generated_support.cu.o differs between phase 2 and phase 3
file omptarget-nvptx_generated_libcall.cu.o differs between phase 2 and phase 3
file omptarget-nvptx_generated_critical.cu.o differs between phase 2 and phase 3
file omptarget-nvptx_generated_data_sharing.cu.o differs between phase 2 and phase 3
file omptarget-nvptx_generated_task.cu.o differs between phase 2 and phase 3
file omptarget-nvptx_generated_cancel.cu.o differs between phase 2 and phase 3
file omptarget-nvptx_generated_sync.cu.o differs between phase 2 and phase 3
file omptarget-nvptx_generated_loop.cu.o differs between phase 2 and phase 3
file omptarget-nvptx_generated_omp_data.cu.o differs between phase 2 and phase 3
file omptarget-nvptx_generated_parallel.cu.o differs between phase 2 and phase 3
llvm_sles12_rc3_differences.tar (20 KB)
testing.10.0.1-rc3_sles12.log.xz (695 KB)
llvm_ubuntu16_rc4_differences.tar (350 KB)
testing.10.0.1-rc4_ubuntu16.log.xz (505 KB)
From: llvm-dev <llvm-dev-bounces@lists.llvm.org> On Behalf Of Tom Stellard
via llvm-dev...
Uploaded:
dcf43e25a77a2ffb4ffaa5a04babe409b2b3ffac07bc989a1dca730ecacb43c2
clang+llvm-10.0.1-rc4-x86_64-linux-sles12.4.tar.xz
6db54d9f55fb41877b23f4b89e7b68d44fcc5378d615d232c820307237dc33f7
clang+llvm-10.0.1-rc2-x86_64-linux-sles12.4.tar.xz
2d907945d8d8d5d2969c6947c50d91e100d5dd09ccb37214a811c11cbfa635af
clang+llvm-10.0.1-rc3-x86_64-linux-sles12.4.tar.xzccdfda65932661e5fd4faba1fde17fe3800f39b4c21687242b7cdfdbea4cf131
clang+llvm-10.0.1-rc3-x86_64-linux-gnu-ubuntu-16.04.tar.xz
761a6f4658545f733f14dcd6c50a16b49994a4c448c779616c5716eed80b90f1
clang+llvm-10.0.1-rc4-x86_64-linux-gnu-ubuntu-16.04.tar.xzI saw phase2/3 mismatches that seem concerning. Are these the only
platforms that encountered them?I can open a bug, let me know if there's particular data beyond the
logs I should gather.Can you attach 2 of the binary files the are different?
Attached a few from each impacted platform. Additional notes below.
# for ubuntu16, 10.0.1-rc4:
$ grep 'differs between' rc4/logs/testing.10.0.1-rc4.log |wc -l
14$ grep 'differs between' rc4/logs/testing.10.0.1-rc4.log
file omptarget-nvptx_intermediate_link.o differs between phase 2 and phase 3
file omptarget-nvptx_generated_target_impl.cu.o differs between phase 2 and phase 3
file omptarget-nvptx_generated_reduction.cu.o differs between phase 2 and phase 3
file omptarget-nvptx_generated_omptarget.cu.o differs between phase 2 and phase 3
file omptarget-nvptx_generated_support.cu.o differs between phase 2 and phase 3
file omptarget-nvptx_generated_libcall.cu.o differs between phase 2 and phase 3
file omptarget-nvptx_generated_critical.cu.o differs between phase 2 and phase 3
file omptarget-nvptx_generated_data_sharing.cu.o differs between phase 2 and phase 3
file omptarget-nvptx_generated_task.cu.o differs between phase 2 and phase 3
file omptarget-nvptx_generated_cancel.cu.o differs between phase 2 and phase 3
file omptarget-nvptx_generated_sync.cu.o differs between phase 2 and phase 3
file omptarget-nvptx_generated_loop.cu.o differs between phase 2 and phase 3
file omptarget-nvptx_generated_omp_data.cu.o differs between phase 2 and phase 3
file omptarget-nvptx_generated_parallel.cu.o differs between phase 2 and phase 3~~~~~~~~~~
The difference in ubuntu 10.0.1-rc4 are in the '__nv_module_id'
section of binaries, which contains a GUID that is unique to the
binary, so this is expected.
# for sles12, 10.0.1-rc3:
$ grep 'differs between' rc3/logs/testing.10.0.1-rc3.log |wc -l
4860$ tail rc3/logs/testing.10.0.1-rc3.log
file interface.cpp.o differs between phase 2 and phase 3
file rtl.cpp.o differs between phase 2 and phase 3
file omptarget.cpp.o differs between phase 2 and phase 3
file ompt-tsan.cpp.o differs between phase 2 and phase 3
file Bye.cpp.o differs between phase 2 and phase 3
file TestPlugin.cpp.o differs between phase 2 and phase 3
file PipSqueak.cpp.o differs between phase 2 and phase 3
file ExportedFuncs.cpp.o differs between phase 2 and phase 3
Do you get these same failures on sles with rc4?
-Tom
From: llvm-dev <llvm-dev-bounces@lists.llvm.org> On Behalf Of Tom Stellard
via llvm-dev...
Uploaded:
dcf43e25a77a2ffb4ffaa5a04babe409b2b3ffac07bc989a1dca730ecacb43c2
clang+llvm-10.0.1-rc4-x86_64-linux-sles12.4.tar.xz
6db54d9f55fb41877b23f4b89e7b68d44fcc5378d615d232c820307237dc33f7
clang+llvm-10.0.1-rc2-x86_64-linux-sles12.4.tar.xz
2d907945d8d8d5d2969c6947c50d91e100d5dd09ccb37214a811c11cbfa635af
clang+llvm-10.0.1-rc3-x86_64-linux-sles12.4.tar.xzccdfda65932661e5fd4faba1fde17fe3800f39b4c21687242b7cdfdbea4cf131
clang+llvm-10.0.1-rc3-x86_64-linux-gnu-ubuntu-16.04.tar.xz
761a6f4658545f733f14dcd6c50a16b49994a4c448c779616c5716eed80b90f1
clang+llvm-10.0.1-rc4-x86_64-linux-gnu-ubuntu-16.04.tar.xzI saw phase2/3 mismatches that seem concerning. Are these the only
platforms that encountered them?I can open a bug, let me know if there's particular data beyond the
logs I should gather.Can you attach 2 of the binary files the are different?
Attached a few from each impacted platform. Additional notes below.
# for ubuntu16, 10.0.1-rc4:
$ grep 'differs between' rc4/logs/testing.10.0.1-rc4.log |wc -l
14$ grep 'differs between' rc4/logs/testing.10.0.1-rc4.log
file omptarget-nvptx_intermediate_link.o differs between phase 2 and phase 3
file omptarget-nvptx_generated_target_impl.cu.o differs between phase 2 and phase 3
file omptarget-nvptx_generated_reduction.cu.o differs between phase 2 and phase 3
file omptarget-nvptx_generated_omptarget.cu.o differs between phase 2 and phase 3
file omptarget-nvptx_generated_support.cu.o differs between phase 2 and phase 3
file omptarget-nvptx_generated_libcall.cu.o differs between phase 2 and phase 3
file omptarget-nvptx_generated_critical.cu.o differs between phase 2 and phase 3
file omptarget-nvptx_generated_data_sharing.cu.o differs between phase 2 and phase 3
file omptarget-nvptx_generated_task.cu.o differs between phase 2 and phase 3
file omptarget-nvptx_generated_cancel.cu.o differs between phase 2 and phase 3
file omptarget-nvptx_generated_sync.cu.o differs between phase 2 and phase 3
file omptarget-nvptx_generated_loop.cu.o differs between phase 2 and phase 3
file omptarget-nvptx_generated_omp_data.cu.o differs between phase 2 and phase 3
file omptarget-nvptx_generated_parallel.cu.o differs between phase 2 and phase 3~~~~~~~~~~
The difference in ubuntu 10.0.1-rc4 are in the '__nv_module_id'
section of binaries, which contains a GUID that is unique to the
binary, so this is expected.# for sles12, 10.0.1-rc3:
$ grep 'differs between' rc3/logs/testing.10.0.1-rc3.log |wc -l
4860$ tail rc3/logs/testing.10.0.1-rc3.log
file interface.cpp.o differs between phase 2 and phase 3
file rtl.cpp.o differs between phase 2 and phase 3
file omptarget.cpp.o differs between phase 2 and phase 3
file ompt-tsan.cpp.o differs between phase 2 and phase 3
file Bye.cpp.o differs between phase 2 and phase 3
file TestPlugin.cpp.o differs between phase 2 and phase 3
file PipSqueak.cpp.o differs between phase 2 and phase 3
file ExportedFuncs.cpp.o differs between phase 2 and phase 3Do you get these same failures on sles with rc4?
It looks like the difference in the objects on sles is because
the compiler ID string in phase 2 and phase 3 have a different
git commit hash. The git hash in the phase 3 binaries is
acd921f02c39fa5cf7aa055b6062bfe9025e3781, which I don't see in
the llvm git tree.
-Tom
From: Tom Stellard <tstellar@redhat.com>
Sent: Wednesday, July 15, 2020 1:17 PM
To: bcain@codeaurora.org; 'Brian Cain' <brian.cain@gmail.com>
Cc: 'Release-testers' <release-testers@lists.llvm.org>; 'Clang Dev' <cfe-
dev@lists.llvm.org>; 'openmp-dev' <openmp-dev@lists.llvm.org>; 'LLDB Dev'
<lldb-dev@lists.llvm.org>
Subject: Re: [Release-testers] [llvm-dev] 10.0.1-rc4 tagged>>> From: llvm-dev <llvm-dev-bounces@lists.llvm.org> On Behalf Of Tom
>>> Stellard via llvm-dev
>> ...
>>>> Uploaded:
>>>> dcf43e25a77a2ffb4ffaa5a04babe409b2b3ffac07bc989a1dca730ecacb43c2
>>>> clang+llvm-10.0.1-rc4-x86_64-linux-sles12.4.tar.xz
>>>>
6db54d9f55fb41877b23f4b89e7b68d44fcc5378d615d232c820307237dc33f7
>>>> clang+llvm-10.0.1-rc2-x86_64-linux-sles12.4.tar.xz
>>>>
2d907945d8d8d5d2969c6947c50d91e100d5dd09ccb37214a811c11cbfa635af
>>>> clang+llvm-10.0.1-rc3-x86_64-linux-sles12.4.tar.xz
>>>>
>>>> ccdfda65932661e5fd4faba1fde17fe3800f39b4c21687242b7cdfdbea4cf131
>>>> clang+llvm-10.0.1-rc3-x86_64-linux-gnu-ubuntu-16.04.tar.xz
>>>>
761a6f4658545f733f14dcd6c50a16b49994a4c448c779616c5716eed80b90f1
>>>> clang+llvm-10.0.1-rc4-x86_64-linux-gnu-ubuntu-16.04.tar.xz
>>>>
>>>> I saw phase2/3 mismatches that seem concerning. Are these the only
>>>> platforms that encountered them?
>>>>
>>>> I can open a bug, let me know if there's particular data beyond the
>>>> logs I should gather.
>>>>
>>>
>>> Can you attach 2 of the binary files the are different?
>>>
>>
>> Attached a few from each impacted platform. Additional notes below.
>>
>> # for ubuntu16, 10.0.1-rc4:
>> $ grep 'differs between' rc4/logs/testing.10.0.1-rc4.log |wc -l
>> 14
>>
>> $ grep 'differs between' rc4/logs/testing.10.0.1-rc4.log file
>> omptarget-nvptx_intermediate_link.o differs between phase 2 and phase
>> 3 file omptarget-nvptx_generated_target_impl.cu.o differs between
>> phase
>> 2 and phase 3
>> file omptarget-nvptx_generated_reduction.cu.o differs between phase 2
>> and phase 3 file omptarget-nvptx_generated_omptarget.cu.o differs
>> between phase 2 and phase 3 file
>> omptarget-nvptx_generated_support.cu.o differs between phase 2 and
>> phase 3 file omptarget-nvptx_generated_libcall.cu.o differs between
>> phase 2 and phase 3 file omptarget-nvptx_generated_critical.cu.o
>> differs between phase 2 and phase 3 file
>> omptarget-nvptx_generated_data_sharing.cu.o differs between phase
>> 2 and phase 3
>> file omptarget-nvptx_generated_task.cu.o differs between phase 2 and
>> phase 3 file omptarget-nvptx_generated_cancel.cu.o differs between
>> phase 2 and phase 3 file omptarget-nvptx_generated_sync.cu.o differs
>> between phase 2 and phase 3 file omptarget-nvptx_generated_loop.cu.o
>> differs between phase 2 and phase 3 file
>> omptarget-nvptx_generated_omp_data.cu.o differs between phase 2 and
>> phase 3 file omptarget-nvptx_generated_parallel.cu.o differs between
>> phase 2 and phase 3
>>
>> ~~~~~~~~~~
>
> The difference in ubuntu 10.0.1-rc4 are in the '__nv_module_id'
> section of binaries, which contains a GUID that is unique to the
> binary, so this is expected.
>
>>
>> # for sles12, 10.0.1-rc3:
>> $ grep 'differs between' rc3/logs/testing.10.0.1-rc3.log |wc -l
>> 4860
>>
>> $ tail rc3/logs/testing.10.0.1-rc3.log file interface.cpp.o differs
>> between phase 2 and phase 3 file rtl.cpp.o differs between phase 2
>> and phase 3 file omptarget.cpp.o differs between phase 2 and phase 3
>> file ompt-tsan.cpp.o differs between phase 2 and phase 3 file
>> ompt-tsan.cpp.o differs between phase 2 and phase 3 file Bye.cpp.o
>> differs between phase 2 and phase 3 file TestPlugin.cpp.o differs
>> between phase 2 and phase 3 file PipSqueak.cpp.o differs between
>> phase 2 and phase 3 file PipSqueak.cpp.o differs between phase 2 and
>> phase 3 file ExportedFuncs.cpp.o differs between phase 2 and phase 3
>>
>
> Do you get these same failures on sles with rc4?
No, I did not.
It looks like the difference in the objects on sles is because the compiler ID
string in phase 2 and phase 3 have a different git commit hash. The git hash in
the phase 3 binaries is acd921f02c39fa5cf7aa055b6062bfe9025e3781, which I
don't see in the llvm git tree.
Ugh -- yes, I realize now -- this was my fault. Apologies, I deviated from the process. I had a local change to test-release.sh that I committed that caused this problem. Sorry for the distraction!
-Brian