llvm dev - Jul 2015 - [LLVMdev] [3.7 Release] RC1 has been tagged, Testing Phase I begins

On Mon, Jul 20, 2015 at 2:37 PM, Dimitry Andric <dimitry at andric.com>
wrote:
> On 20 Jul 2015, at 22:50, Hans Wennborg <hans at chromium.org> wrote:
>>
>> On Sat, Jul 18, 2015 at 3:17 PM, Dimitry Andric <dimitry at
andric.com> wrote:
>>> On 17 Jul 2015, at 01:09, Hans Wennborg <hans at
chromium.org> wrote:
>>>>
>>>> On Thu, Jul 16, 2015 at 3:47 PM, Dimitry Andric <dimitry at
andric.com> wrote:
>>>>> On 17 Jul 2015, at 00:31, Hans Wennborg <hans at
chromium.org> wrote:
>>>>>>
>>>>>> Dear testers,
>>>>>>
>>>>>> 3.7.0-rc1 was just tagged; please start your testing
engines :-)
>>>>>>
>>>>>> Upload binaries to the sftp and report your results to
this thread.
>>>>>>
>>>>>> I'm sorry for the delay between branching and
tagging. The changes to
>>>>>> the release script took a little longer than I hoped.
>>>>>>
>>>>>> Thanks for helping with the release, and do let me know
of any issues,
>>>>>> questions, etc.
>>>>>>
>>>>>> The tracking bug for release blockers is PR24126.
>>>>>
>>>>> Is it OK to do an autoconf build?  The CMake build tries to
build various components which do not yet work on FreeBSD, e.g. libcxxabi does
not compile at all, libcompiler-rt has a bunch of test failures, etc. 
Alternatively, can I disable these components in the CMake build locally?
>>>>
>>>> Yes, go ahead and use the autoconf build.
>>>>
>>>> Can you send a patch to test-release.sh that makes this default
for
>>>> FreeBSD? It's already the default for Darwin.
>>>
>>> Here it is.  While here, I replaced the multiple calls to uname -s
with a variable assignment.
>>>
>>> It's currently building for FreeBSD 10.x i386 and amd64.
>>
>> Renato ran into the same problem of some components not working when
>> building on ARM and has a patch out for disabling them:
>> http://reviews.llvm.org/D11326
>>
>> That might be a better approach actually. Since we didn't use to
>> include libcxx or libcxxabi in previous releases, feel free to disable
>> those (but please file bugs for the problems anyway). For compiler-rt,
>> we did include that in previous releases so it would be good if we
>> could make it work. What errors are you running into?
>
> The compilation fails because it cannot find unwind.h, since we still
> have not cleaned up our act in FreeBSD, and chose one of the 4 (or so)
> available versions we have in our tree, to install into the standard
> system include directories.
>
> Other than that, I recall there were still several test failures in the
> sanitizer parts.  This needs more work to get it completely done.
>
> I'm not sure if the llvm libunwind you added in r242543 will get picked
> up during the build of compiler-rt, but that could at least provide
> *some* form of unwinding library.  It would be better for FreeBSD to
> just import that wholesale, so we can finally ditch libgcc... :-)
If r242543 fixes it, that's great. Otherwise, feel free to exclude
compiler-rt or fall back to autoconf (doesn't that need unwind.h too,
though?) - whatever is most appropriate for FreeBSD.

Thanks,
Hans

On 20 Jul 2015, at 23:55, Hans Wennborg <hans at chromium.org>
wrote:
> 
> On Mon, Jul 20, 2015 at 2:37 PM, Dimitry Andric <dimitry at
andric.com> wrote:
...
>> I'm not sure if the llvm libunwind you added in r242543 will get
picked
>> up during the build of compiler-rt, but that could at least provide
>> *some* form of unwinding library.  It would be better for FreeBSD to
>> just import that wholesale, so we can finally ditch libgcc... :-)
> 
> If r242543 fixes it, that's great. Otherwise, feel free to exclude
> compiler-rt or fall back to autoconf (doesn't that need unwind.h too,
> though?) - whatever is most appropriate for FreeBSD.
On FreeBSD, the autoconf build only builds llvm and clang, so it
encounters no problems.  Since the other components still need more
(possibly disruptive) work to make them build and test on FreeBSD, let's
keep the autoconf build for this release.

Ed, are you OK with this too?  We should put some effort in post 3.7.0
release to get the CMake build up to par, especially since autoconf's
days are probably numbered. :-)

-Dimitry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: Message signed with OpenPGP using GPGMail
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150721/da371dc7/attachment.sig>

Fedora 22 x64

Failing Tests (8):
    LeakSanitizer-AddressSanitizer :: TestCases/cleanup_in_tsd_destructor.cc
    LeakSanitizer-AddressSanitizer :: TestCases/disabler.cc
    LeakSanitizer-AddressSanitizer ::
TestCases/disabler_in_tsd_destructor.cc
    LeakSanitizer-AddressSanitizer :: TestCases/ignore_object.cc
    LeakSanitizer-Standalone :: TestCases/cleanup_in_tsd_destructor.cc
    LeakSanitizer-Standalone :: TestCases/disabler.cc
    LeakSanitizer-Standalone :: TestCases/disabler_in_tsd_destructor.cc
    LeakSanitizer-Standalone :: TestCases/ignore_object.cc

Log attached.


On Tue, Jul 21, 2015 at 8:20 AM, Dimitry Andric <dimitry at andric.com>
wrote:
> On 20 Jul 2015, at 23:55, Hans Wennborg <hans at chromium.org> wrote:
> >
> > On Mon, Jul 20, 2015 at 2:37 PM, Dimitry Andric <dimitry at
andric.com>
> wrote:
> ...
> >> I'm not sure if the llvm libunwind you added in r242543 will
get picked
> >> up during the build of compiler-rt, but that could at least
provide
> >> *some* form of unwinding library.  It would be better for FreeBSD
to
> >> just import that wholesale, so we can finally ditch libgcc... :-)
> >
> > If r242543 fixes it, that's great. Otherwise, feel free to exclude
> > compiler-rt or fall back to autoconf (doesn't that need unwind.h
too,
> > though?) - whatever is most appropriate for FreeBSD.
>
> On FreeBSD, the autoconf build only builds llvm and clang, so it
> encounters no problems.  Since the other components still need more
> (possibly disruptive) work to make them build and test on FreeBSD,
let's
> keep the autoconf build for this release.
>
> Ed, are you OK with this too?  We should put some effort in post 3.7.0
> release to get the CMake build up to par, especially since autoconf's
> days are probably numbered. :-)
>
> -Dimitry
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150721/03267ad9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm.check-Phase3-Release.log.zip
Type: application/zip
Size: 8312 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150721/03267ad9/attachment.zip>