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

[Nikola Smiljanic via cfe-dev]

Two libc++ tests fail on 64bit Fedora 23, get_monthname and
get_monthname_wide. Test suite looks good.

On Fri, Jan 22, 2016 at 10:09 PM, Nikola Smiljanic <popizdeh at gmail.com>
wrote:

> Something is failing on 32bit Fedora 23 (compiler-rt?), test suite looks
> good.
>
> On Fri, Jan 22, 2016 at 2:52 PM, Brian Cain via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> On Thu, Jan 21, 2016 at 8:31 PM, Eric Fiselier <eric at efcs.ca> wrote:
>>
>>>
>>> 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.
>>>
>>
>> I don't recall any changes to libc.  Attached is the testing log from
>> 3.7.1 rc2 (I don't have logs from -final handy).
>>
>> I can repeat a 3.7.1 release build on this system now.  I don't think the
>> results will change, 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()"?
>>>
>>>
>>
>> Ok, I'll be able to get this tomorrow.  But I suspect it will be "('SUSE
>> Linux Enterprise Server ', '11', 'x86_64')"
>>
>>
>>>     libc++abi :: cxa_thread_atexit_test.pass.cpp
>>>>
>>>
>>> Not sure about this failure. Can you send me the output?
>>>
>>>
>> That one failed in 3.7.1 also.  IIRC this libstdc++ doesn't have
>> cxa_thread_atexit.
>>
>> _______________________________________________
>> 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/cfe-dev/attachments/20160123/4c067218/attachment.html>