Jack,
> On Fri, Dec 21, 2012 at 05:58:59PM +0400, Alexander Potapenko wrote:
>> Neither we have them now.
>
> Alexander,
> Do you mean to say that you can't reproduce this failure locally on
x86_64 darwin?
> I am testing with current llvm 3.2 branches for
llvm/compiler-rt/clang/polly/testsuite
> against Xcode 4.5.2 on x86_64-apple-darwin12 using a cmake build with...
>
> -DLLVM_ENABLE_ASSERTIONS=OFF -DCMAKE_BUILD_TYPE=Release ..
>
> and have CC set to clang and CXX to clang++.
> Jack
>
I can not reproduce this failure with Xcode 4.5.2 on
x86_64-apple-darwin11, LLVM-3.2 final is passing all
regression tests.
Could be darwin12 or maybe your branch is not up to date.
> > Can this be fixed before the 3.2 release?
> Given that release is tomorrow, then - no, unfortunately.
In an any case 3.2 release on x86_64-apple-darwin11 is fine.
Paweł
[100%] Running all regression tests
lit.py: lit.common.cfg:19: note: using clang:
'/32bitmicro/build/llvm-3.2-final-cmake/bin/clang'
lit.py: lit.cfg:171: note: using clang:
'/32bitmicro/build/llvm-3.2-final-cmake/bin/./clang'
Testing Time: 1109.29s
Expected Passes : 12465
Expected Failures : 81
Unsupported Tests : 85
[100%] Built target check-all
And Asan on Mac
[==========] Running 109 tests from 3 test cases.
[----------] Global test environment set-up.
... lots and lots of RUN OK tests ...
[----------] 17 tests from AddressSanitizerMac
[ RUN ] AddressSanitizerMac.CFAllocatorDefaultDoubleFree
[ OK ] AddressSanitizerMac.CFAllocatorDefaultDoubleFree (1573 ms)
[ RUN ] AddressSanitizerMac.CFAllocatorDefaultDoubleFree_ChildPhread
[ OK ]
AddressSanitizerMac.CFAllocatorDefaultDoubleFree_ChildPhread (1549 ms)
[ RUN ] AddressSanitizerMac.CFAllocator_PassMemoryToAnotherThread
[ OK ] AddressSanitizerMac.CFAllocator_PassMemoryToAnotherThread
(1578 ms)
[ RUN ] AddressSanitizerMac.CFAllocatorMallocDoubleFree
[ OK ] AddressSanitizerMac.CFAllocatorMallocDoubleFree (1565 ms)
[ RUN ] AddressSanitizerMac.GCDDispatchAsync
[ OK ] AddressSanitizerMac.GCDDispatchAsync (1620 ms)
[ RUN ] AddressSanitizerMac.GCDDispatchSync
[ OK ] AddressSanitizerMac.GCDDispatchSync (1561 ms)
[ RUN ] AddressSanitizerMac.GCDReuseWqthreadsAsync
[ OK ] AddressSanitizerMac.GCDReuseWqthreadsAsync (1532 ms)
[ RUN ] AddressSanitizerMac.GCDReuseWqthreadsSync
[ OK ] AddressSanitizerMac.GCDReuseWqthreadsSync (1562 ms)
[ RUN ] AddressSanitizerMac.GCDDispatchAfter
[ OK ] AddressSanitizerMac.GCDDispatchAfter (2559 ms)
[ RUN ] AddressSanitizerMac.GCDSourceEvent
[ OK ] AddressSanitizerMac.GCDSourceEvent (2554 ms)
[ RUN ] AddressSanitizerMac.GCDSourceCancel
[ OK ] AddressSanitizerMac.GCDSourceCancel (2544 ms)
[ RUN ] AddressSanitizerMac.GCDGroupAsync
[ OK ] AddressSanitizerMac.GCDGroupAsync (1535 ms)
[ RUN ] AddressSanitizerMac.MallocIntrospectionLock
[ OK ] AddressSanitizerMac.MallocIntrospectionLock (41934 ms)
[ RUN ] AddressSanitizerMac.CFStringCreateCopy
[ OK ] AddressSanitizerMac.CFStringCreateCopy (506 ms)
[ RUN ] AddressSanitizerMac.NSObjectOOB
[ OK ] AddressSanitizerMac.NSObjectOOB (2041 ms)
[ RUN ] AddressSanitizerMac.NSURLDeallocation
[ OK ] AddressSanitizerMac.NSURLDeallocation (165 ms)
[ RUN ] AddressSanitizerMac.Mstats
[ OK ] AddressSanitizerMac.Mstats (0 ms)
[----------] 17 tests from AddressSanitizerMac (66383 ms total)
[----------] Global test environment tear-down
[==========] 109 tests from 3 test cases ran. (1350454 ms total)
[ PASSED ] 109 tests.
YOU HAVE 27 DISABLED TESTS
>
>> Unfortunately disabling the test in the 3.2 branch won't fix the
>> problem, and the actual fix may require cherry-picking a number of
>> recent CLs, which may be rather intrusive.
>>
>> On Fri, Dec 21, 2012 at 12:06 PM, Alexey Samsonov <samsonov at
google.com> wrote:
>> > +glider
>> >
>> > Weird, we haven't seen problems with this test for quite a
while.
>> >
>> >
>> > On Fri, Dec 21, 2012 at 12:08 AM, Jack Howarth <howarth at
bromo.med.uc.edu>
>> > wrote:
>> >>
>> >> On Thu, Dec 20, 2012 at 11:35:47PM +0400, Anton Korobeynikov
wrote:
>> >> > > Can this be fixed before the 3.2 release?
>> >> > Given that release is tomorrow, then - no, unfortunately.
>> >>
>> >> Well if you can't fix the bug by tomorrow, can't you
at least revert the
>> >> failing part of...
>> >>
>> >>
>> >>
https://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/asan/tests/asan_test.cc?sortby=log&r1=145953&r2=145952&pathrev=145953
>> >>
>> >> with...
>> >>
>> >> Index: lib/asan/tests/asan_test.cc
>> >>
==================================================================>>
>> --- lib/asan/tests/asan_test.cc (revision 170724)
>> >> +++ lib/asan/tests/asan_test.cc (working copy)
>> >> @@ -2046,7 +2046,7 @@ TEST(AddressSanitizerMac, GCDSourceEvent
>> >> EXPECT_DEATH(TestGCDSourceEvent(), "Shadow byte and
word");
>> >> }
>> >>
>> >> -TEST(AddressSanitizerMac, GCDSourceCancel) {
>> >> +TEST(AddressSanitizerMac, DISABLED_GCDSourceCancel) {
>> >> // Make sure the whole ASan report is printed, i.e. that we
don't die
>> >> // on a CHECK.
>> >> EXPECT_DEATH(TestGCDSourceCancel(), "Shadow byte and
word");
>> >>
>> >> so that we show clean testsuite results on darwin (which is a
primary
>> >> target)?
>> >> Jack
>> >> ps I'll try to find sometime to regression hunt to see if
this commit ever
>> >> passed on darwin or if it was broken on the initial backport
from llvm
>> >> trunk.
>> >>
>> >> >
>> >> > --
>> >> > With best regards, Anton Korobeynikov
>> >> > Faculty of Mathematics and Mechanics, Saint Petersburg
State University
>> >> _______________________________________________
>> >> LLVM Developers mailing list
>> >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>> >
>> >
>> >
>> >
>> > --
>> > Alexey Samsonov, MSK
>> >
>>
>>
>>
>> --
>> Alexander Potapenko
>> Software Engineer
>> Google Moscow
