[llvm-dev] [Release-testers] [7.0.0 Release] rc1 has been tagged

[Hans Wennborg via llvm-dev]

On Tue, Aug 7, 2018 at 10:38 PM, Louis Dionne <ldionne at apple.com> wrote:
>
>
>> On Aug 7, 2018, at 16:17, Dimitry Andric via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>
>> On 3 Aug 2018, at 13:37, Hans Wennborg via Release-testers <release-testers at lists.llvm.org> wrote:
>>>
>>> Dear testers,
>>>
>>> 7.0.0-rc1 was just tagged (from the branch at r338847).
>>>
>>> It's early in the release process, but I'd like to find out what the
>>> status is of the branch on our various platforms.
>>>
>>> Please run the test script, share the results, and upload binaries.
>>
>> I've built and tested for FreeBSD 11 (a.k.a 11-STABLE) this time, since
>> FreeBSD 10 will be going EOL pretty soon now.  Uploaded:
>>
>> SHA256 (clang+llvm-7.0.0-rc1-amd64-unknown-freebsd11.tar.xz) = ed3191635be26cced8c75d5e57ff7e559f44b927a64c10d22611d8d912cf6df4
>>
>> I posted the full test results here:
>>
>> https://gist.github.com/DimitryAndric/64e9a7805a01e6027e2aaabfcda42bed
>>
>> Summary:
>>  Expected Passes    : 50388
>>  Expected Failures  : 233
>>  Unsupported Tests  : 3687
>>  Unexpected Passes  : 1
>>  Unexpected Failures: 2490
>>
>> The failures are distributed as follows:
>>
>>  2028 libc++
>>   205 AddressSanitizer-i386-freebsd-dynamic
>>   200 AddressSanitizer-x86_64-freebsd-dynamic
>>    20 XRay-Unit
>>    11 MemorySanitizer-Unit
>>     7 lldb-Suite
>>     4 libunwind
>>     3 XRay-x86_64-freebsd
>>     3 lldb
>>     2 ThreadSanitizer-x86_64
>>     2 UBSan-MemorySanitizer-x86_64
>>     2 libFuzzer
>>     1 SanitizerCommon-asan-i386-FreeBSD
>>     1 SanitizerCommon-asan-x86_64-FreeBSD
>>     1 libomp
>>
>> Almost all libc++ failures are due to FreeBSD missing timespec_get(),
>> and this became mandatory with https://reviews.llvm.org/rL338419:
>>
>> In file included from /home/dim/llvm/7.0.0/rc1/llvm.src/projects/libcxx/test/libcxx/containers/unord/next_pow2.pass.cpp:26:
>> In file included from /home/dim/llvm/7.0.0/rc1/llvm.src/projects/libcxx/include/iostream:38:
>> In file included from /home/dim/llvm/7.0.0/rc1/llvm.src/projects/libcxx/include/ios:216:
>> In file included from /home/dim/llvm/7.0.0/rc1/llvm.src/projects/libcxx/include/__locale:18:
>> In file included from /home/dim/llvm/7.0.0/rc1/llvm.src/projects/libcxx/include/mutex:191:
>> In file included from /home/dim/llvm/7.0.0/rc1/llvm.src/projects/libcxx/include/__mutex_base:15:
>> In file included from /home/dim/llvm/7.0.0/rc1/llvm.src/projects/libcxx/include/chrono:795:
>> /home/dim/llvm/7.0.0/rc1/llvm.src/projects/libcxx/include/ctime:77:9: error: no member named 'timespec_get' in the global namespace; did you mean 'timespec'?
>> using ::timespec_get;
>>      ~~^~~~~~~~~~~~
>>        timespec
>> /usr/include/sys/_timespec.h:44:8: note: 'timespec' declared here
>> struct timespec {
>>       ^
>>
>> We're tracking this in FreeBSD here: https://bugs.freebsd.org/230400,
>> but for existing FreeBSD releases this isn't fixable, so we could really
>> use some sort of workaround in libc++. :-)
>
> Ugh. The problem here is that libc++ checks whether the underlying C standard library implementation has support for C11 as a whole, not on a function-by-function basis. This means that the easiest workaround is to pretend that FreeBSD does NOT support C11 as a whole, but that is going to be a regression from prior releases, which provided a subset of C11 through libc++.
>
> Generally, I think supporting things on a per-platform basis like this is a bad idea because it becomes a complete maze. Perhaps the current situation justifies a workaround, perhaps only targeted to the LLVM 7 branch. Marshall, what’s your opinion?

Can you please file a release-blocking PR to make this easier to track?

Thanks,
Hans