ARCMT test failures

I'm seeing these failures from "make check-all" on Linux/x86_this morning:

Failing Tests (17):
    Clang :: ARCMT/alloc-with-zone.m
    Clang :: ARCMT/atautorelease-2.m
    Clang :: ARCMT/atautorelease-3.m
    Clang :: ARCMT/atautorelease.m
    Clang :: ARCMT/autoreleases.m
    Clang :: ARCMT/checking.m
    Clang :: ARCMT/cxx-checking.mm
    Clang :: ARCMT/init.m
    Clang :: ARCMT/nonobjc-to-objc-cast.m
    Clang :: ARCMT/releases-driver.m
    Clang :: ARCMT/releases.m
    Clang :: ARCMT/remove-dealloc-zerouts.m
    Clang :: ARCMT/remove-statements.m
    Clang :: ARCMT/retains.m
    Clang :: ARCMT/rewrite-block-var.m
    Clang :: ARCMT/safe-arc-assign.m
    Clang :: ARCMT/with-working-dir.m

  Expected Passes : 8669
  Expected Failures : 69
  Unsupported Tests : 551
  Unexpected Failures: 17

The failures all seem to be segfaults or assertion failures in arcmt-test, e.g:

$ Release+Asserts/bin/arcmt-test --args -triple
x86_64-apple-macosx10.7 -fobjc-nonfragile-abi -fblocks -fsyntax-only
/home/jay/svn/llvm-project/cfe/trunk/test/ARCMT/rewrite-block-var.m
arcmt-test: /home/jay/svn/llvm-project/cfe/trunk/lib/ARCMigrate/../../include/clang/AST/StmtVisitor.h:45:
RetTy clang::StmtVisitorBase<Ptr, ImplClass, RetTy>::Visit(typename
Ptr<clang::Stmt>::type) [with Ptr = clang::make_ptr, ImplClass =
<unnamed>::EmptyChecker, RetTy = bool, typename Ptr<clang::Stmt>::type
= clang::Stmt*]: Assertion `0 && "Unknown binary operator!"' failed.
0 arcmt-test 0x0000000000b3702f
1 arcmt-test 0x0000000000b37b6a
2 libpthread.so.0 0x00007fa05de1fc60
3 libc.so.6 0x00007fa05d10ad05 gsignal + 53
4 libc.so.6 0x00007fa05d10eab6 abort + 390
5 libc.so.6 0x00007fa05d1037c5 __assert_fail + 245
6 arcmt-test 0x00000000004c2cf0
7 arcmt-test 0x00000000004c5382
8 arcmt-test 0x00000000004c4490
9 arcmt-test 0x00000000004d0fca
10 arcmt-test 0x00000000004ca012
11 arcmt-test 0x00000000004cbeb1
12 arcmt-test 0x00000000004c96e1
13 arcmt-test 0x00000000004cb816
14 arcmt-test 0x000000000040e25a
15 arcmt-test 0x0000000000407c98
16 arcmt-test 0x000000000040814e
17 libc.so.6 0x00007fa05d0f5eff __libc_start_main + 255
18 arcmt-test 0x00000000004057a9
Aborted

The GDB backtrace for this one is:

(gdb) bt
#0 0x00007ffff6eb8d05 in raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x00007ffff6ebcab6 in abort () at abort.c:92
#2 0x00007ffff6eb17c5 in __assert_fail (assertion=0xbaa4d0 "0 &&
\"Unknown binary operator!\"", file=<value optimised out>, line=45,
function=<value optimised out>)
    at assert.c:81
#3 0x00000000004c2cf0 in clang::StmtVisitorBase<clang::make_ptr,
(anonymous namespace)::EmptyChecker, bool>::Visit(clang::Stmt*) ()
#4 0x00000000004c5382 in clang::RecursiveASTVisitor<(anonymous
namespace)::EmptyStatementsRemover>::TraverseCompoundStmt ()
#5 0x00000000004c4490 in clang::RecursiveASTVisitor<(anonymous
namespace)::EmptyStatementsRemover>::TraverseStmt(clang::Stmt*) ()
#6 0x00000000004d0fca in clang::RecursiveASTVisitor<(anonymous
namespace)::EmptyStatementsRemover>::TraverseFunctionHelper(clang::FunctionDecl*)
()
#7 0x00000000004ca012 in clang::RecursiveASTVisitor<(anonymous
namespace)::EmptyStatementsRemover>::TraverseDecl(clang::Decl*) ()
#8 0x00000000004cbeb1 in clang::RecursiveASTVisitor<(anonymous
namespace)::EmptyStatementsRemover>::TraverseDeclContextHelper(clang::DeclContext*)
()
#9 0x00000000004c96e1 in clang::RecursiveASTVisitor<(anonymous
namespace)::EmptyStatementsRemover>::TraverseDecl(clang::Decl*) ()
#10 0x00000000004cb816 in
clang::arcmt::trans::removeEmptyStatementsAndDealloc(clang::arcmt::MigrationPass&)
()
#11 0x000000000040e25a in
clang::arcmt::MigrationProcess::applyTransform(void
(*)(clang::arcmt::MigrationPass&),
clang::arcmt::MigrationProcess::RewriteListener*) ()
#12 0x0000000000407c98 in performTransformations ()
#13 0x000000000040814e in main ()

Jay.

I only get these failures on a Release+Asserts build. On a
Debug+Asserts build they go away.

Thanks,
Jay.

I only get these failures on a Release+Asserts build. On a
Debug+Asserts build they go away.

What is the host compiler? Maybe it is miscompiling clang?

Thanks,
Jay.

Cheers,
Rafael

With GCC 4.2.1 on FreeBSD, I can't compile the ARCMT library. Or, at least, I got bored waiting after GCC had spent 10 minutes of CPU time and 500MB of memory (still slowly climbing) on a single file. Does it do some particularly evil template things? I can build all of the rest of clang in the time it took to give up compiling that file...

David

-- Sent from my brain

I only get these failures on a Release+Asserts build. On a
Debug+Asserts build they go away.

What is the host compiler? Maybe it is miscompiling clang?

I see the failures with gcc (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2

I don't see them with gcc-4.4 (Ubuntu/Linaro 4.4.5-15ubuntu1) 4.4.5

Thanks,
Jay.

Note that Argyrios just split up the ARCMT library into several different .cpp files, which should improve compile times.

  - Doug

I only get these failures on a Release+Asserts build. On a
Debug+Asserts build they go away.

What is the host compiler? Maybe it is miscompiling clang?

I see the failures with gcc (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2

I don't see them with gcc-4.4 (Ubuntu/Linaro 4.4.5-15ubuntu1) 4.4.5

I don't see something suspicious in the source code, I'm leaning towards Rafael's "diagnosis".

Valgrinding, maybe? Could be undefined behavior.

John.

I only get these failures on a Release+Asserts build. On a
Debug+Asserts build they go away.

What is the host compiler? Maybe it is miscompiling clang?

I see the failures with gcc (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2

I don't see them with gcc-4.4 (Ubuntu/Linaro 4.4.5-15ubuntu1) 4.4.5

I don't see something suspicious in the source code, I'm leaning towards Rafael's "diagnosis".

Valgrinding, maybe? Could be undefined behavior.

Looks fine. Jay, you'd need to investigate, not sure how I can help.

Jay Foad <jay.foad-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:

I'm seeing these failures from "make check-all" on Linux/x86_this morning:

[...]

    Clang :: ARCMT/with-working-dir.m

I'm seeing this today too, on Windows 7 using Visual Studio 2008. I do not
see it on Mac OS X, however.

John

Valgrinding, maybe? Could be undefined behavior.

I've attached the valgrind log. The first complaint is:

==3607== Conditional jump or move depends on uninitialised value(s)
==3607== at 0x4C5353:
_ZN5clang19RecursiveASTVisitorIN12_GLOBAL__N_122EmptyStatementsRemoverEE20TraverseCompoundStmtEPNS_12CompoundStmtE.clone.2086
(in /home/jay/llvm/objdir/Release+Asserts/bin/arcmt-test)
==3607== by 0x4C448F: clang::RecursiveASTVisitor<(anonymous
namespace)::EmptyStatementsRemover>::TraverseStmt(clang::Stmt*) (in
/home/jay/llvm/objdir/Release+Asserts/bin/arcmt-test)
==3607== by 0x4D0FC9: clang::RecursiveASTVisitor<(anonymous
namespace)::EmptyStatementsRemover>::TraverseFunctionHelper(clang::FunctionDecl*)
(in /home/jay/llvm/objdir/Release+Asserts/bin/arcmt-test)
==3607== by 0x4CA011: clang::RecursiveASTVisitor<(anonymous
namespace)::EmptyStatementsRemover>::TraverseDecl(clang::Decl*) (in
/home/jay/llvm/objdir/Release+Asserts/bin/arcmt-test)
==3607== by 0x4CBEB0: clang::RecursiveASTVisitor<(anonymous
namespace)::EmptyStatementsRemover>::TraverseDeclContextHelper(clang::DeclContext*)
(in /home/jay/llvm/objdir/Release+Asserts/bin/arcmt-test)
==3607== by 0x4C96E0: clang::RecursiveASTVisitor<(anonymous
namespace)::EmptyStatementsRemover>::TraverseDecl(clang::Decl*) (in
/home/jay/llvm/objdir/Release+Asserts/bin/arcmt-test)
==3607== by 0x4CB815:
clang::arcmt::trans::removeEmptyStatementsAndDealloc(clang::arcmt::MigrationPass&)
(in /home/jay/llvm/objdir/Release+Asserts/bin/arcmt-test)
==3607== by 0x40DC0E:
clang::arcmt::checkForManualIssues(clang::CompilerInvocation&,
llvm::StringRef, clang::InputKind, clang::DiagnosticClient*) (in
/home/jay/llvm/objdir/Release+Asserts/bin/arcmt-test)
==3607== by 0x4068C7:
_ZL17checkForMigrationN4llvm9StringRefENS_8ArrayRefIPKcEE.clone.180
(in /home/jay/llvm/objdir/Release+Asserts/bin/arcmt-test)
==3607== by 0x407227:
_ZL22performTransformationsN4llvm9StringRefENS_8ArrayRefIPKcEE.clone.252
(in /home/jay/llvm/objdir/Release+Asserts/bin/arcmt-test)
==3607== by 0x40814D: main (in
/home/jay/llvm/objdir/Release+Asserts/bin/arcmt-test)

The function it's complaining about, up to the point of the complaint, is:

00000000004c5330
<_ZN5clang19RecursiveASTVisitorIN12_GLOBAL__N_122EmptyStatementsRemoverEE20TraverseCompoundStmtEPNS_12CompoundStmtE.clone.2086>:
  4c5330: 41 57 push %r15
  4c5332: 49 89 d7 mov %rdx,%r15
  4c5335: 41 56 push %r14
  4c5337: 41 55 push %r13
  4c5339: 41 54 push %r12
  4c533b: 55 push %rbp
  4c533c: 48 89 f5 mov %rsi,%rbp
  4c533f: 53 push %rbx
  4c5340: 48 89 fb mov %rdi,%rbx
  4c5343: 48 83 ec 68 sub $0x68,%rsp
  4c5347: 8b 06 mov (%rsi),%eax
  4c5349: 4c 8b 22 mov (%rdx),%r12
  4c534c: 4d 8d 34 c4 lea (%r12,%rax,8),%r14
  4c5350: 4d 39 f4 cmp %r14,%r12
  4c5353: 74 70 je 4c53c5

Jay.

valgrind.log (18.4 KB)

I see the crashes on linux x86_64 with gcc 4.5.0. I'll see if I can find the problem.