thr3ads.net - llvm dev - [llvm-dev] [cfe-dev] [3.8 Release] RC1 has been tagged [Jan 2016]

If this information is useful, please help other people find it:
Share via:

Hans Wennborg via llvm-dev

2016-Jan-19 23:55 UTC

[llvm-dev] [3.8 Release] RC1 has been tagged

(cc'ing non-legacy llvm-dev this time; apologies if you get this
twice. Please don't reply-all to the first one.)

On Tue, Jan 19, 2016 at 3:47 PM, Hans Wennborg <hans at chromium.org>
wrote:> Dear testers,
>
> Start your engines; 3.8.0-rc1 was just tagged from the 3.8 branch at
> r258223. (It took a little longer than I'd planned, sorry about that.)
>
> There are still a bunch of open merge requests and bug reports, but I
> wanted to get the tag in so we can see what the build and test status
> are on the various platforms.
>
> I verified that it currently builds and tests cleanly for me on x86_64
> Linux, Mac OS X* and Windows.
>
> Please build, test, and upload binaries to the sftp. Let me know if how it
goes.
>
> Thanks,
> Hans
>
>
> [*] For Mac, I had to set CFLAGS="-isysroot `xcrun
-show-sdk-path`"
> CXXFLAGS="-isysroot `xcrun -show-sdk-path`" for the build to
work,
> otherwise stage-2 Clang couldn't find the SDK. I don't remember if
I
> had to do this last time; maybe some upgrade changed something.

Sylvestre Ledru via llvm-dev

2016-Jan-20 09:31 UTC

head link

[llvm-dev] [3.8 Release] RC1 has been tagged

What about creating a release management mailing list ?
The testers are usually the same (hello folks!) :)

Sylvestre

Le 20/01/2016 00:55, Hans Wennborg a écrit :> (cc'ing non-legacy llvm-dev this time; apologies if you get this
> twice. Please don't reply-all to the first one.)
>
> On Tue, Jan 19, 2016 at 3:47 PM, Hans Wennborg <hans at chromium.org>
wrote:
>> Dear testers,
>>
>> Start your engines; 3.8.0-rc1 was just tagged from the 3.8 branch at
>> r258223. (It took a little longer than I'd planned, sorry about
that.)
>>
>> There are still a bunch of open merge requests and bug reports, but I
>> wanted to get the tag in so we can see what the build and test status
>> are on the various platforms.
>>
>> I verified that it currently builds and tests cleanly for me on x86_64
>> Linux, Mac OS X* and Windows.
>>
>> Please build, test, and upload binaries to the sftp. Let me know if how
it goes.
>>
>> Thanks,
>> Hans
>>
>>
>> [*] For Mac, I had to set CFLAGS="-isysroot `xcrun
-show-sdk-path`"
>> CXXFLAGS="-isysroot `xcrun -show-sdk-path`" for the build to
work,
>> otherwise stage-2 Clang couldn't find the SDK. I don't remember
if I
>> had to do this last time; maybe some upgrade changed something.

Daniel Sanders via llvm-dev

2016-Jan-20 10:30 UTC

head link

[llvm-dev] [3.8 Release] RC1 has been tagged

This isn't rc1 but the tip of the release branch had some X86 test failures
on my most recent build:
Failing Tests (24):
    libc++ ::
std/input.output/file.streams/fstreams/filebuf.virtuals/overflow.pass.cpp
    libc++ ::
std/input.output/file.streams/fstreams/filebuf.virtuals/underflow.pass.cpp
    libc++ :: std/input.output/iostream.format/ext.manip/get_time.pass.cpp
    libc++ :: std/input.output/iostream.format/ext.manip/put_time.pass.cpp
    libc++ ::
std/input.output/iostreams.base/ios.base/ios.base.callback/register_callback.pass.cpp
    libc++ ::
std/input.output/iostreams.base/ios.base/ios.base.locales/imbue.pass.cpp
    libc++ ::
std/input.output/iostreams.base/ios/basic.ios.members/imbue.pass.cpp
    libc++ ::
std/input.output/stream.buffers/streambuf/streambuf.cons/copy.pass.cpp
    libc++ ::
std/input.output/stream.buffers/streambuf/streambuf.cons/default.pass.cpp
    libc++ ::
std/input.output/stream.buffers/streambuf/streambuf.protected/streambuf.assign/assign.pass.cpp
    libc++ ::
std/input.output/stream.buffers/streambuf/streambuf.protected/streambuf.assign/swap.pass.cpp
    libc++ ::
std/localization/locale.categories/category.collate/locale.collate.byname/hash.pass.cpp
    libc++ ::
std/localization/locale.categories/category.collate/locale.collate.byname/types.pass.cpp
    libc++ ::
std/localization/locale.categories/category.ctype/locale.codecvt.byname/ctor_wchar_t.pass.cpp
    libc++ ::
std/localization/locale.categories/category.ctype/locale.ctype.byname/types.pass.cpp
    libc++ :: std/localization/locales/locale/locale.cons/default.pass.cpp
    libc++ :: std/localization/locales/locale/locale.members/name.pass.cpp
    libc++ :: std/localization/locales/locale/locale.operators/eq.pass.cpp
    libc++ :: std/localization/locales/locale/locale.statics/global.pass.cpp
    libc++ :: std/re/re.regex/re.regex.locale/imbue.pass.cpp
    libc++ :: std/re/re.traits/default.pass.cpp
    libc++ :: std/re/re.traits/getloc.pass.cpp
    libc++ :: std/re/re.traits/imbue.pass.cpp
    libomp :: barrier/omp_barrier.c

Big-endian mips gave this during phase 3:
	CMake Error at cmake/modules/HandleLLVMOptions.cmake:43 (message):
	  Host Clang must be able to find libstdc++4.7 or newer!
It's possible that this is a machine config issue. We moved offices over the
weekend (just across the street) and my normal machine somehow lost the ability
to boot in the process. I'm borrowing a replacement at the moment.

Little-endian mips is just about to finish Phase 2 so I'll know if it's
a more general problem soon.
> -----Original Message-----
> From: hwennborg at google.com [mailto:hwennborg at google.com] On Behalf
> Of Hans Wennborg
> Sent: 19 January 2016 23:56
> To: Ben Pope; Dimitry Andric; Daniel Sanders; Nikola Smiljanić; Brian Cain;
> Renato Golin; Sylvestre Ledru
> Cc: cfe-dev; lldb-dev at lists.llvm.org; openmp-dev at lists.llvm.org;
llvm-dev
> Subject: Re: [3.8 Release] RC1 has been tagged
> 
> (cc'ing non-legacy llvm-dev this time; apologies if you get this
> twice. Please don't reply-all to the first one.)
> 
> On Tue, Jan 19, 2016 at 3:47 PM, Hans Wennborg <hans at chromium.org>
> wrote:
> > Dear testers,
> >
> > Start your engines; 3.8.0-rc1 was just tagged from the 3.8 branch at
> > r258223. (It took a little longer than I'd planned, sorry about
that.)
> >
> > There are still a bunch of open merge requests and bug reports, but I
> > wanted to get the tag in so we can see what the build and test status
> > are on the various platforms.
> >
> > I verified that it currently builds and tests cleanly for me on x86_64
> > Linux, Mac OS X* and Windows.
> >
> > Please build, test, and upload binaries to the sftp. Let me know if
how it
> goes.
> >
> > Thanks,
> > Hans
> >
> >
> > [*] For Mac, I had to set CFLAGS="-isysroot `xcrun
-show-sdk-path`"
> > CXXFLAGS="-isysroot `xcrun -show-sdk-path`" for the build to
work,
> > otherwise stage-2 Clang couldn't find the SDK. I don't
remember if I
> > had to do this last time; maybe some upgrade changed something.

Dimitry Andric via llvm-dev

2016-Jan-20 13:25 UTC

head link

[llvm-dev] [3.8 Release] RC1 has been tagged

Unfortunately I'm having lots of trouble with rc1 at this point:
* libcxxabi can't build, because it requires unwind.h, which we do not yet
have on FreeBSD 10.x (Ed Maste is working on it for 11.x, but that is not ready
for general consumption).
* The test-release.sh script has no option to disable only libcxxabi, you can
only disable libcxx, libcxxabi and libunwind together (maybe this can be
improved)
* Last time I hand-built libcxx, it still had a lot of test failures in the
locale parts, but I haven't had time to investigate.
* OpenMP does not support i386-freebsd, so I have to disable it there
* Last but not least: the host compiler on FreeBSD 10.x is clang 3.4.1 (the last
version that can build without C++11 support), and it crashes with a segfault
during building of CGBlocks.cpp.  I'll need to find some way to work around
this failure, since we cannot upgrade the compiler easily on FreeBSD 10.x.

I also had to hack the test-release.sh script to fix a number of problems that I
encountered during the 3.7.1 release, but haven't gotten to upstreaming
them.  E.g. the way the source code is checked out with symlinks all over the
place does not work, and I need to add a custom patch to clang-tools-extra to
make the tests succeed, because there is a race condition in the Makefile.

-Dimitry
> On 20 Jan 2016, at 11:30, Daniel Sanders <Daniel.Sanders at
imgtec.com> wrote:
> 
> This isn't rc1 but the tip of the release branch had some X86 test
failures on my most recent build:
> Failing Tests (24):
>    libc++ ::
std/input.output/file.streams/fstreams/filebuf.virtuals/overflow.pass.cpp
>    libc++ ::
std/input.output/file.streams/fstreams/filebuf.virtuals/underflow.pass.cpp
>    libc++ :: std/input.output/iostream.format/ext.manip/get_time.pass.cpp
>    libc++ :: std/input.output/iostream.format/ext.manip/put_time.pass.cpp
>    libc++ ::
std/input.output/iostreams.base/ios.base/ios.base.callback/register_callback.pass.cpp
>    libc++ ::
std/input.output/iostreams.base/ios.base/ios.base.locales/imbue.pass.cpp
>    libc++ ::
std/input.output/iostreams.base/ios/basic.ios.members/imbue.pass.cpp
>    libc++ ::
std/input.output/stream.buffers/streambuf/streambuf.cons/copy.pass.cpp
>    libc++ ::
std/input.output/stream.buffers/streambuf/streambuf.cons/default.pass.cpp
>    libc++ ::
std/input.output/stream.buffers/streambuf/streambuf.protected/streambuf.assign/assign.pass.cpp
>    libc++ ::
std/input.output/stream.buffers/streambuf/streambuf.protected/streambuf.assign/swap.pass.cpp
>    libc++ ::
std/localization/locale.categories/category.collate/locale.collate.byname/hash.pass.cpp
>    libc++ ::
std/localization/locale.categories/category.collate/locale.collate.byname/types.pass.cpp
>    libc++ ::
std/localization/locale.categories/category.ctype/locale.codecvt.byname/ctor_wchar_t.pass.cpp
>    libc++ ::
std/localization/locale.categories/category.ctype/locale.ctype.byname/types.pass.cpp
>    libc++ :: std/localization/locales/locale/locale.cons/default.pass.cpp
>    libc++ :: std/localization/locales/locale/locale.members/name.pass.cpp
>    libc++ :: std/localization/locales/locale/locale.operators/eq.pass.cpp
>    libc++ :: std/localization/locales/locale/locale.statics/global.pass.cpp
>    libc++ :: std/re/re.regex/re.regex.locale/imbue.pass.cpp
>    libc++ :: std/re/re.traits/default.pass.cpp
>    libc++ :: std/re/re.traits/getloc.pass.cpp
>    libc++ :: std/re/re.traits/imbue.pass.cpp
>    libomp :: barrier/omp_barrier.c
> 
> Big-endian mips gave this during phase 3:
> 	CMake Error at cmake/modules/HandleLLVMOptions.cmake:43 (message):
> 	  Host Clang must be able to find libstdc++4.7 or newer!
> It's possible that this is a machine config issue. We moved offices
over the weekend (just across the street) and my normal machine somehow lost the
ability to boot in the process. I'm borrowing a replacement at the moment.
> 
> Little-endian mips is just about to finish Phase 2 so I'll know if
it's a more general problem soon.
> 
>> -----Original Message-----
>> From: hwennborg at google.com [mailto:hwennborg at google.com] On
Behalf
>> Of Hans Wennborg
>> Sent: 19 January 2016 23:56
>> To: Ben Pope; Dimitry Andric; Daniel Sanders; Nikola Smiljanić; Brian
Cain;
>> Renato Golin; Sylvestre Ledru
>> Cc: cfe-dev; lldb-dev at lists.llvm.org; openmp-dev at lists.llvm.org;
llvm-dev
>> Subject: Re: [3.8 Release] RC1 has been tagged
>> 
>> (cc'ing non-legacy llvm-dev this time; apologies if you get this
>> twice. Please don't reply-all to the first one.)
>> 
>> On Tue, Jan 19, 2016 at 3:47 PM, Hans Wennborg <hans at
chromium.org>
>> wrote:
>>> Dear testers,
>>> 
>>> Start your engines; 3.8.0-rc1 was just tagged from the 3.8 branch
at
>>> r258223. (It took a little longer than I'd planned, sorry about
that.)
>>> 
>>> There are still a bunch of open merge requests and bug reports, but
I
>>> wanted to get the tag in so we can see what the build and test
status
>>> are on the various platforms.
>>> 
>>> I verified that it currently builds and tests cleanly for me on
x86_64
>>> Linux, Mac OS X* and Windows.
>>> 
>>> Please build, test, and upload binaries to the sftp. Let me know if
how it
>> goes.
>>> 
>>> Thanks,
>>> Hans
>>> 
>>> 
>>> [*] For Mac, I had to set CFLAGS="-isysroot `xcrun
-show-sdk-path`"
>>> CXXFLAGS="-isysroot `xcrun -show-sdk-path`" for the build
to work,
>>> otherwise stage-2 Clang couldn't find the SDK. I don't
remember if I
>>> had to do this last time; maybe some upgrade changed something.
-------------- 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/20160120/e720be85/attachment.sig>

Hans Wennborg via llvm-dev

2016-Jan-20 17:14 UTC

head link

[llvm-dev] [3.8 Release] RC1 has been tagged

That would certainly make my emails easier to address :-) On the other
hand, I do think there's a point to asking for testers each time and
then only addressing those that sign up explicitly. What do the rest
of you think about having a list?

On Wed, Jan 20, 2016 at 1:31 AM, Sylvestre Ledru <sylvestre at debian.org>
wrote:> What about creating a release management mailing list ?
> The testers are usually the same (hello folks!) :)
>
> Sylvestre
>
> Le 20/01/2016 00:55, Hans Wennborg a écrit :
>> (cc'ing non-legacy llvm-dev this time; apologies if you get this
>> twice. Please don't reply-all to the first one.)
>>
>> On Tue, Jan 19, 2016 at 3:47 PM, Hans Wennborg <hans at
chromium.org> wrote:
>>> Dear testers,
>>>
>>> Start your engines; 3.8.0-rc1 was just tagged from the 3.8 branch
at
>>> r258223. (It took a little longer than I'd planned, sorry about
that.)

Daniel Sanders via llvm-dev

2016-Jan-21 11:54 UTC

head link

[llvm-dev] [3.8 Release] RC1 has been tagged

I still haven't built rc1 yet but I've found the cause of most (if not
all) of the libc++ failures. This system does not have the en_US.UTF-8 locale.

I'm currently putting a patch together to add appropriate REQUIRES lines to
tests that require en_US.UTF-8. Once I've done that and committed it,
I'm going to enable this locale along with the others that lit is
complaining about (fr_FR.UTF-8, ru_RU.UTF-8, zh_CN.UTF-*, fr_CA.ISO8859-1, and
cs_CZ.ISO8859-2).
> -----Original Message-----
> From: cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org] On Behalf Of
Daniel
> Sanders via cfe-dev
> Sent: 20 January 2016 10:30
> To: Hans Wennborg; Ben Pope; Dimitry Andric; Nikola Smiljanić; Brian Cain;
> Renato Golin; Sylvestre Ledru
> Cc: llvm-dev; cfe-dev; openmp-dev at lists.llvm.org; lldb-dev at
lists.llvm.org
> Subject: Re: [cfe-dev] [3.8 Release] RC1 has been tagged
> 
> This isn't rc1 but the tip of the release branch had some X86 test
failures on
> my most recent build:
> Failing Tests (24):
>     libc++ ::
> std/input.output/file.streams/fstreams/filebuf.virtuals/overflow.pass.cpp
>     libc++ ::
> std/input.output/file.streams/fstreams/filebuf.virtuals/underflow.pass.cpp
>     libc++ :: std/input.output/iostream.format/ext.manip/get_time.pass.cpp
>     libc++ :: std/input.output/iostream.format/ext.manip/put_time.pass.cpp
>     libc++ ::
> std/input.output/iostreams.base/ios.base/ios.base.callback/register_callbac
> k.pass.cpp
>     libc++ ::
> std/input.output/iostreams.base/ios.base/ios.base.locales/imbue.pass.cpp
>     libc++ ::
> std/input.output/iostreams.base/ios/basic.ios.members/imbue.pass.cpp
>     libc++ ::
> std/input.output/stream.buffers/streambuf/streambuf.cons/copy.pass.cpp
>     libc++ ::
> std/input.output/stream.buffers/streambuf/streambuf.cons/default.pass.c
> pp
>     libc++ ::
> std/input.output/stream.buffers/streambuf/streambuf.protected/streamb
> uf.assign/assign.pass.cpp
>     libc++ ::
> std/input.output/stream.buffers/streambuf/streambuf.protected/streamb
> uf.assign/swap.pass.cpp
>     libc++ ::
>
std/localization/locale.categories/category.collate/locale.collate.byname/has
> h.pass.cpp
>     libc++ ::
>
std/localization/locale.categories/category.collate/locale.collate.byname/typ
> es.pass.cpp
>     libc++ ::
> std/localization/locale.categories/category.ctype/locale.codecvt.byname/cto
> r_wchar_t.pass.cpp
>     libc++ ::
> std/localization/locale.categories/category.ctype/locale.ctype.byname/types
> .pass.cpp
>     libc++ :: std/localization/locales/locale/locale.cons/default.pass.cpp
>     libc++ :: std/localization/locales/locale/locale.members/name.pass.cpp
>     libc++ :: std/localization/locales/locale/locale.operators/eq.pass.cpp
>     libc++ ::
std/localization/locales/locale/locale.statics/global.pass.cpp
>     libc++ :: std/re/re.regex/re.regex.locale/imbue.pass.cpp
>     libc++ :: std/re/re.traits/default.pass.cpp
>     libc++ :: std/re/re.traits/getloc.pass.cpp
>     libc++ :: std/re/re.traits/imbue.pass.cpp
>     libomp :: barrier/omp_barrier.c
> 
> Big-endian mips gave this during phase 3:
> 	CMake Error at cmake/modules/HandleLLVMOptions.cmake:43
> (message):
> 	  Host Clang must be able to find libstdc++4.7 or newer!
> It's possible that this is a machine config issue. We moved offices
over the
> weekend (just across the street) and my normal machine somehow lost the
> ability to boot in the process. I'm borrowing a replacement at the
moment.
> 
> Little-endian mips is just about to finish Phase 2 so I'll know if
it's a more
> general problem soon.
> 
> > -----Original Message-----
> > From: hwennborg at google.com [mailto:hwennborg at google.com] On
> Behalf
> > Of Hans Wennborg
> > Sent: 19 January 2016 23:56
> > To: Ben Pope; Dimitry Andric; Daniel Sanders; Nikola Smiljanić; Brian
Cain;
> > Renato Golin; Sylvestre Ledru
> > Cc: cfe-dev; lldb-dev at lists.llvm.org; openmp-dev at lists.llvm.org;
llvm-dev
> > Subject: Re: [3.8 Release] RC1 has been tagged
> >
> > (cc'ing non-legacy llvm-dev this time; apologies if you get this
> > twice. Please don't reply-all to the first one.)
> >
> > On Tue, Jan 19, 2016 at 3:47 PM, Hans Wennborg <hans at
chromium.org>
> > wrote:
> > > Dear testers,
> > >
> > > Start your engines; 3.8.0-rc1 was just tagged from the 3.8 branch
at
> > > r258223. (It took a little longer than I'd planned, sorry
about that.)
> > >
> > > There are still a bunch of open merge requests and bug reports,
but I
> > > wanted to get the tag in so we can see what the build and test
status
> > > are on the various platforms.
> > >
> > > I verified that it currently builds and tests cleanly for me on
x86_64
> > > Linux, Mac OS X* and Windows.
> > >
> > > Please build, test, and upload binaries to the sftp. Let me know
if how it
> > goes.
> > >
> > > Thanks,
> > > Hans
> > >
> > >
> > > [*] For Mac, I had to set CFLAGS="-isysroot `xcrun
-show-sdk-path`"
> > > CXXFLAGS="-isysroot `xcrun -show-sdk-path`" for the
build to work,
> > > otherwise stage-2 Clang couldn't find the SDK. I don't
remember if I
> > > had to do this last time; maybe some upgrade changed something.
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

Renato Golin via llvm-dev

2016-Jan-21 13:18 UTC

head link

[llvm-dev] [3.8 Release] RC1 has been tagged

On 20 January 2016 at 09:31, Sylvestre Ledru <sylvestre at debian.org>
wrote:> What about creating a release management mailing list ?
> The testers are usually the same (hello folks!) :)
I second that! It'd also be much easier on mail filters... :)

--renato

Brian Cain via llvm-dev

2016-Jan-22 02:04 UTC

head link

[llvm-dev] [3.8 Release] RC1 has been tagged

SuSE Linux Enterprise Server 11SP3 x86_64

Looks like I see several failures that weren't in 3.7.1.  Is there any way
to tell whether these are regressions vs new-to-3.8.0-but-failing?  The
MSan ones were in 3.7.1 but the ThreadPoolTest and the libc++ errors were
not in 3.7.1.

~~~~~~~~~~~~~~~~
Failing Tests (27):
    LLVM-Unit :: Support/SupportTests/ThreadPoolTest.Async
    LLVM-Unit :: Support/SupportTests/ThreadPoolTest.AsyncBarrier
    LLVM-Unit :: Support/SupportTests/ThreadPoolTest.AsyncBarrierArgs
    LLVM-Unit :: Support/SupportTests/ThreadPoolTest.GetFuture
    LLVM-Unit :: Support/SupportTests/ThreadPoolTest.PoolDestruction
    MemorySanitizer :: Linux/obstack.cc
    MemorySanitizer :: Linux/process_vm_readv.cc
    MemorySanitizer :: fork.cc
    MemorySanitizer :: iconv.cc
    MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.fgetgrent_r
    MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getgrent
    MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getgrent_r
    MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getpwent
    MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getpwent_r
    MemorySanitizer-Unit ::
Msan-x86_64-with-call-Test/MemorySanitizer.fgetgrent_r
    MemorySanitizer-Unit ::
Msan-x86_64-with-call-Test/MemorySanitizer.getgrent
    MemorySanitizer-Unit ::
Msan-x86_64-with-call-Test/MemorySanitizer.getgrent_r
    MemorySanitizer-Unit ::
Msan-x86_64-with-call-Test/MemorySanitizer.getpwent
    MemorySanitizer-Unit ::
Msan-x86_64-with-call-Test/MemorySanitizer.getpwent_r
    SanitizerCommon-Unit ::
Sanitizer-x86_64-Test/SanitizerLinux.ThreadDescriptorSize
    ThreadSanitizer :: Linux/mutex_robust.cc
    ThreadSanitizer :: Linux/mutex_robust2.cc
    ThreadSanitizer :: thread_name2.cc
    libc++ :: std/depr/depr.c.headers/uchar_h.pass.cpp
    libc++ ::
std/localization/locale.categories/category.time/locale.time.get.byname/get_monthname.pass.cpp
    libc++ ::
std/localization/locale.categories/category.time/locale.time.get.byname/get_monthname_wide.pass.cpp
    libc++abi :: cxa_thread_atexit_test.pass.cpp

  Expected Passes    : 31153
  Expected Failures  : 203
  Unsupported Tests  : 518
  Unexpected Failures: 27
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Uploads:
7b837b2c4b7884a4277b947b795948ecd983b0f3
 clang+llvm-3.8.0-rc1-linux-x86_64-sles11.3.tar.xz


On Tue, Jan 19, 2016 at 5:55 PM, Hans Wennborg <hans at chromium.org>
wrote:
> (cc'ing non-legacy llvm-dev this time; apologies if you get this
> twice. Please don't reply-all to the first one.)
>
> On Tue, Jan 19, 2016 at 3:47 PM, Hans Wennborg <hans at chromium.org>
wrote:
> > Dear testers,
> >
> > Start your engines; 3.8.0-rc1 was just tagged from the 3.8 branch at
> > r258223. (It took a little longer than I'd planned, sorry about
that.)
> >
> > There are still a bunch of open merge requests and bug reports, but I
> > wanted to get the tag in so we can see what the build and test status
> > are on the various platforms.
> >
> > I verified that it currently builds and tests cleanly for me on x86_64
> > Linux, Mac OS X* and Windows.
> >
> > Please build, test, and upload binaries to the sftp. Let me know if
how
> it goes.
> >
> > Thanks,
> > Hans
> >
> >
> > [*] For Mac, I had to set CFLAGS="-isysroot `xcrun
-show-sdk-path`"
> > CXXFLAGS="-isysroot `xcrun -show-sdk-path`" for the build to
work,
> > otherwise stage-2 Clang couldn't find the SDK. I don't
remember if I
> > had to do this last time; maybe some upgrade changed something.
>


-- 
-Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160121/2e8b0c9f/attachment.html>

Eric Fiselier via llvm-dev

2016-Jan-22 02:31 UTC

head link

[llvm-dev] [cfe-dev] [3.8 Release] RC1 has been tagged

On Thu, Jan 21, 2016 at 7:04 PM, Brian Cain via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> SuSE Linux Enterprise Server 11SP3 x86_64
>
> Looks like I see several failures that weren't in 3.7.1.  Is there any
way
> to tell whether these are regressions vs new-to-3.8.0-but-failing?  The
> MSan ones were in 3.7.1 but the ThreadPoolTest and the libc++ errors were
> not in 3.7.1.
>
>All of the libc++ failures seem like non-issues and should be in 3.7.1. Did
you change or upgrade your platform or libc version?  I'm not sure about
the libc++abi error though.

> ~~~~~~~~~~~~~~~~
> Failing Tests (27):
>     LLVM-Unit :: Support/SupportTests/ThreadPoolTest.Async
>     LLVM-Unit :: Support/SupportTests/ThreadPoolTest.AsyncBarrier
>     LLVM-Unit :: Support/SupportTests/ThreadPoolTest.AsyncBarrierArgs
>     LLVM-Unit :: Support/SupportTests/ThreadPoolTest.GetFuture
>     LLVM-Unit :: Support/SupportTests/ThreadPoolTest.PoolDestruction
>     MemorySanitizer :: Linux/obstack.cc
>     MemorySanitizer :: Linux/process_vm_readv.cc
>     MemorySanitizer :: fork.cc
>     MemorySanitizer :: iconv.cc
>     MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.fgetgrent_r
>     MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getgrent
>     MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getgrent_r
>     MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getpwent
>     MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getpwent_r
>     MemorySanitizer-Unit ::
> Msan-x86_64-with-call-Test/MemorySanitizer.fgetgrent_r
>     MemorySanitizer-Unit ::
> Msan-x86_64-with-call-Test/MemorySanitizer.getgrent
>     MemorySanitizer-Unit ::
> Msan-x86_64-with-call-Test/MemorySanitizer.getgrent_r
>     MemorySanitizer-Unit ::
> Msan-x86_64-with-call-Test/MemorySanitizer.getpwent
>     MemorySanitizer-Unit ::
> Msan-x86_64-with-call-Test/MemorySanitizer.getpwent_r
>     SanitizerCommon-Unit ::
> Sanitizer-x86_64-Test/SanitizerLinux.ThreadDescriptorSize
>     ThreadSanitizer :: Linux/mutex_robust.cc
>     ThreadSanitizer :: Linux/mutex_robust2.cc
>     ThreadSanitizer :: thread_name2.cc
>     libc++ :: std/depr/depr.c.headers/uchar_h.pass.cpp
>
This is caused because the system does not provide a uchar.h header.

>     libc++ ::
>
std/localization/locale.categories/category.time/locale.time.get.byname/get_monthname.pass.cpp
>     libc++ ::
>
std/localization/locale.categories/category.time/locale.time.get.byname/get_monthname_wide.pass.cpp
>

These are marked XFAIL on open-suse, They should probably be marked as
XFAIL on your platform as well.
Can you send me the output of Python's
"platform.linux_distribution()"?

>     libc++abi :: cxa_thread_atexit_test.pass.cpp
>
Not sure about this failure. Can you send me the output?

>
>   Expected Passes    : 31153
>   Expected Failures  : 203
>   Unsupported Tests  : 518
>   Unexpected Failures: 27
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Uploads:
> 7b837b2c4b7884a4277b947b795948ecd983b0f3
>  clang+llvm-3.8.0-rc1-linux-x86_64-sles11.3.tar.xz
>
>
> On Tue, Jan 19, 2016 at 5:55 PM, Hans Wennborg <hans at chromium.org>
wrote:
>
>> (cc'ing non-legacy llvm-dev this time; apologies if you get this
>> twice. Please don't reply-all to the first one.)
>>
>> On Tue, Jan 19, 2016 at 3:47 PM, Hans Wennborg <hans at
chromium.org> wrote:
>> > Dear testers,
>> >
>> > Start your engines; 3.8.0-rc1 was just tagged from the 3.8 branch
at
>> > r258223. (It took a little longer than I'd planned, sorry
about that.)
>> >
>> > There are still a bunch of open merge requests and bug reports,
but I
>> > wanted to get the tag in so we can see what the build and test
status
>> > are on the various platforms.
>> >
>> > I verified that it currently builds and tests cleanly for me on
x86_64
>> > Linux, Mac OS X* and Windows.
>> >
>> > Please build, test, and upload binaries to the sftp. Let me know
if how
>> it goes.
>> >
>> > Thanks,
>> > Hans
>> >
>> >
>> > [*] For Mac, I had to set CFLAGS="-isysroot `xcrun
-show-sdk-path`"
>> > CXXFLAGS="-isysroot `xcrun -show-sdk-path`" for the
build to work,
>> > otherwise stage-2 Clang couldn't find the SDK. I don't
remember if I
>> > had to do this last time; maybe some upgrade changed something.
>>
>
>
>
> --
> -Brian
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160121/8dcd10bd/attachment.html>

Seemingly Similar Threads

Search for more maybe matching threads

llvm dev - Jan 2016 - [cfe-dev] [3.8 Release] RC1 has been tagged

[llvm-dev] [3.8 Release] RC1 has been tagged

[llvm-dev] [3.8 Release] RC1 has been tagged

[llvm-dev] [3.8 Release] RC1 has been tagged

[llvm-dev] [3.8 Release] RC1 has been tagged

[llvm-dev] [3.8 Release] RC1 has been tagged

[llvm-dev] [3.8 Release] RC1 has been tagged

[llvm-dev] [3.8 Release] RC1 has been tagged

[llvm-dev] [3.8 Release] RC1 has been tagged

[llvm-dev] [cfe-dev] [3.8 Release] RC1 has been tagged

Seemingly Similar Threads