10.0.1-rc4 tagged

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.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?

-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.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 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.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 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?

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