On Tue, Aug 7, 2018 at 10:38 PM, Louis Dionne <ldio...@apple.com> wrote: > > >> On Aug 7, 2018, at 16:17, Dimitry Andric via llvm-dev >> <llvm-...@lists.llvm.org> wrote: >> >> On 3 Aug 2018, at 13:37, Hans Wennborg via Release-testers >> <release-test...@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 _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
