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

[Louis Dionne via llvm-dev]

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

Louis

> 
> -Dimitry
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev