[LLVMdev] llvm 3.2 regression

[Pawel Wodnicki]

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