llvm/clang test failures on powerpc-darwin8

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

llvm/clang test failures on powerpc-darwin8

David Fang
Hi,

I've bootstrapped llvm/clang from svn-trunk on powerpc-darwin8 (g++-4.0.1), and
have the following test results to share.
Summary below, full log at:
http://www.csl.cornell.edu/~fang/sw/llvm/r146586-powerpc-darwin8-results.txt

The only edits required were those I posted to llvm-commits yesterday (re:
"some missing clang libs").  And I also edited LitConfig.py to point to
/sw/bin/bash (4.2) because /bin/bash is missing support for pipefail.

Some of the tests hung indefinitely on 'lli', so I had to kill them.

My question is: which of the following test failures should be addressed first
as top priority?  Are there any low-hanging fruit that look easy to fix
(looking at the full log)?

Fang

powerpc-darwin8-g++-4.0.1 bootstrap test summary:

********************
Testing Time: 65105.62s
********************
Unexpected Passing Tests (1):
      Clang :: CodeGenCXX/member-alignment.cpp

********************
Failing Tests (204):
     Clang : :  CXX/expr/expr.unary/expr.unary.noexcept/cg.cpp
     Clang : :  CodeGen/2003-08-17-DeadCodeShortCircuit.c
     Clang : :  CodeGen/2004-06-17-UnorderedBuiltins.c
     Clang : :  CodeGen/bitfield-promote.c
     Clang : :  CodeGenCXX/2005-02-19-UnnamedVirtualThunkArgument.cpp
     Clang : :  CodeGenCXX/conditional-expr-lvalue.cpp
     Clang : :  CodeGenCXX/cxx0x-delegating-ctors.cpp
     Clang : :  CodeGenCXX/expr.cpp
     Clang : :  CodeGenCXX/nrvo.cpp
     Clang : :  CodeGenCXX/throw-expressions.cpp
     Clang : :  CodeGenCXX/vtable-debug-info.cpp
     Clang : :  CodeGenObjC/arc-ivar-layout.m
     Clang : :  CodeGenObjC/debug-info-class-extension.m
     Clang : :  CodeGenObjC/debug-info-class-extension2.m
     Clang : :  CodeGenObjC/debug-info-crash-2.m
     Clang : :  Index/c-index-api-loadTU-test.m
     Clang : :  Index/nested-binaryoperators.cpp
     Clang : :  Index/recursive-member-access.c
     Clang : :  Index/redeclarations.cpp
     Clang : :  Modules/decldef.mm
     Clang : :  Modules/diamond-pch.c
     Clang : :  Modules/diamond.c
     Clang : :  Modules/lookup.cpp
     Clang : :  Modules/module-private.cpp
     Clang : :  Modules/objc-categories.m
     Clang : :  Modules/on-demand-build.m
     Clang : :  Modules/submodules.cpp
     Clang : :  Modules/wildcard-submodule-exports.cpp
     Clang : :  PCH/chain-categories.m
     Clang : :  PCH/chain-categories2.m
     Clang : :  PCH/chain-conversion-lookup.cpp
     Clang : :  PCH/chain-cxx.cpp
     Clang : :  PCH/chain-empty-initial-namespace.cpp
     Clang : :  PCH/chain-friend-instantiation.cpp
     Clang : :  PCH/chain-implicit-definition.cpp
     Clang : :  PCH/chain-late-anonymous-namespace.cpp
     Clang : :  PCH/chain-pending-instantiations.cpp
     Clang : :  PCH/chain-selectors.m
     Clang : :  PCH/check-deserializations.cpp
     Clang : :  PCH/cuda-kernel-call.cu
     Clang : :  PCH/cxx-alias-decl.cpp
     Clang : :  PCH/cxx-chain-function-template.cpp
     Clang : :  PCH/cxx-for-range.cpp
     Clang : :  PCH/cxx-friends.cpp
     Clang : :  PCH/cxx-implicit-moves.cpp
     Clang : :  PCH/cxx-member-init.cpp
     Clang : :  PCH/cxx-method.cpp
     Clang : :  PCH/cxx-ms-function-specialization-class-scope.cpp
     Clang : :  PCH/cxx-namespaces.cpp
     Clang : :  PCH/cxx-static_assert.cpp
     Clang : :  PCH/cxx-templates.cpp
     Clang : :  PCH/cxx-traits.cpp
     Clang : :  PCH/cxx-typeid.cpp
     Clang : :  PCH/cxx-using.cpp
     Clang : :  PCH/cxx-variadic-templates.cpp
     Clang : :  PCH/cxx0x-default-delete.cpp
     Clang : :  PCH/cxx0x-delegating-ctors.cpp
     Clang : :  PCH/cxx_exprs.cpp
     Clang : :  PCH/exprs.c
     Clang : :  PCH/headersearch.cpp
     Clang : :  PCH/missing-file.cpp
     Clang : :  PCH/ms-if-exists.cpp
     Clang : :  PCH/namespaces.cpp
     Clang : :  PCH/objc_import.m
     Clang : :  PCH/objc_methods.m
     Clang : :  PCH/objc_property.m
     Clang : :  PCH/objcxx-ivar-class.mm
     Clang : :  PCH/pragma-diag-section.cpp
     Clang : :  PCH/reinclude.cpp
     Clang : :  PCH/struct.c
     Clang : :  PCH/typo.cpp
     Clang : :  PCH/typo.m
     Clang : :  PCH/va_arg.cpp
     Clang : :  PCH/working-directory.cpp
     Clang : :  Preprocessor/mmx.c
     Clang : :  Preprocessor/predefined-arch-macros.c
     Clang : :  Sema/arm-neon-types.c
     Clang : :  SemaObjC/cocoa.m
     Clang : :  SemaTemplate/instantiate-function-1.cpp
     LLVM : :  CodeGen/Generic/2003-05-27-phifcmpd.ll
     LLVM : :  CodeGen/Generic/2003-05-27-useboolinotherbb.ll
     LLVM : :  CodeGen/Generic/2003-05-27-usefsubasbool.ll
     LLVM : :  CodeGen/Generic/2003-05-30-BadPreselectPhi.ll
     LLVM : :  CodeGen/Generic/2003-07-29-BadConstSbyte.ll
     LLVM : :  CodeGen/Generic/2006-02-12-InsertLibcall.ll
     LLVM : :  CodeGen/Generic/2006-03-01-dagcombineinfloop.ll
     LLVM : :  CodeGen/Generic/2006-06-28-SimplifySetCCCrash.ll
     LLVM : :  CodeGen/Generic/2006-07-03-schedulers.ll
     LLVM : :  CodeGen/Generic/2007-04-30-LandingPadBranchFolding.ll
     LLVM : :  CodeGen/Generic/2007-12-17-InvokeAsm.ll
     LLVM : :  CodeGen/Generic/2008-01-30-LoadCrash.ll
     LLVM : :  CodeGen/Generic/2008-02-04-Ctlz.ll
     LLVM : :  CodeGen/Generic/2009-03-17-LSR-APInt.ll
     LLVM : :  CodeGen/Generic/2009-11-16-BadKillsCrash.ll
     LLVM : :  CodeGen/Generic/2010-11-04-BigByval.ll
     LLVM : :  CodeGen/Generic/add-with-overflow-128.ll
     LLVM : :  CodeGen/Generic/badCallArgLRLLVM.ll
     LLVM : :  CodeGen/Generic/badarg6.ll
     LLVM : :  CodeGen/Generic/builtin-expect.ll
     LLVM : :  CodeGen/Generic/crash.ll
     LLVM : :  CodeGen/Generic/exception-handling.ll
     LLVM : :  CodeGen/Generic/fwdtwice.ll
     LLVM : :  CodeGen/Generic/llvm-ct-intrinsics.ll
     LLVM : :  CodeGen/Generic/nested-select.ll
     LLVM : :  CodeGen/Generic/overflow.ll
     LLVM : :  CodeGen/Generic/print-mul.ll
     LLVM : :  CodeGen/Generic/print-shift.ll
     LLVM : :  CodeGen/Generic/select-cc.ll
     LLVM : :  CodeGen/Generic/select.ll
     LLVM : :  CodeGen/PowerPC/2006-04-19-vmaddfp-crash.ll
     LLVM : :  CodeGen/PowerPC/2006-09-28-shift_64.ll
     LLVM : :  CodeGen/PowerPC/2007-03-30-SpillerCrash.ll
     LLVM : :  CodeGen/PowerPC/2007-05-14-InlineAsmSelectCrash.ll
     LLVM : :  CodeGen/PowerPC/2007-05-22-tailmerge-3.ll
     LLVM : :  CodeGen/PowerPC/2007-08-04-CoalescerAssert.ll
     LLVM : :  CodeGen/PowerPC/2007-10-18-PtrArithmetic.ll
     LLVM : :  CodeGen/PowerPC/2007-11-16-landingpad-split.ll
     LLVM : :  CodeGen/PowerPC/2008-02-05-LiveIntervalsAssert.ll
     LLVM : :  CodeGen/PowerPC/2008-03-05-RegScavengerAssert.ll
     LLVM : :  CodeGen/PowerPC/2008-03-17-RegScavengerCrash.ll
     LLVM : :  CodeGen/PowerPC/2008-04-23-CoalescerCrash.ll
     LLVM : :  CodeGen/PowerPC/2008-06-23-LiveVariablesCrash.ll
     LLVM : :  CodeGen/PowerPC/2008-07-15-Bswap.ll
     LLVM : :  CodeGen/PowerPC/2008-07-15-Fabs.ll
     LLVM : :  CodeGen/PowerPC/2008-09-12-CoalescerBug.ll
     LLVM : :  CodeGen/PowerPC/2008-10-28-f128-i32.ll
     LLVM : :  CodeGen/PowerPC/2009-07-16-InlineAsm-M-Operand.ll
     LLVM : :  CodeGen/PowerPC/2009-08-17-inline-asm-addr-mode-breakage.ll
     LLVM : :  CodeGen/PowerPC/2009-09-18-carrybit.ll
     LLVM : :  CodeGen/PowerPC/2010-02-12-saveCR.ll
     LLVM : :  CodeGen/PowerPC/2010-04-01-MachineCSEBug.ll
     LLVM : :  CodeGen/PowerPC/2011-12-05-NoSpillDupCR.ll
     LLVM : :  CodeGen/PowerPC/2011-12-06-SpillAndRestoreCR.ll
     LLVM : :  CodeGen/PowerPC/Atomics-32.ll
     LLVM : :  CodeGen/PowerPC/Frames-large.ll
     LLVM : :  CodeGen/PowerPC/addc.ll
     LLVM : :  CodeGen/PowerPC/atomic-1.ll
     LLVM : :  CodeGen/PowerPC/atomic-2.ll
     LLVM : :  CodeGen/PowerPC/available-externally.ll
     LLVM : :  CodeGen/PowerPC/branch-opt.ll
     LLVM : :  CodeGen/PowerPC/div-2.ll
     LLVM : :  CodeGen/PowerPC/fp-branch.ll
     LLVM : :  CodeGen/PowerPC/iabs.ll
     LLVM : :  CodeGen/PowerPC/indirectbr.ll
     LLVM : :  CodeGen/PowerPC/int-fp-conv-0.ll
     LLVM : :  CodeGen/PowerPC/int-fp-conv-1.ll
     LLVM : :  CodeGen/PowerPC/lsr-postinc-pos.ll
     LLVM : :  CodeGen/PowerPC/ppc32-vaarg.ll
     LLVM : :  CodeGen/PowerPC/ppcf128-4.ll
     LLVM : :  CodeGen/PowerPC/rlwimi-keep-rsh.ll
     LLVM : :  CodeGen/PowerPC/rlwimi3.ll
     LLVM : :  CodeGen/PowerPC/select-cc.ll
     LLVM : :  CodeGen/PowerPC/shift128.ll
     LLVM : :  CodeGen/PowerPC/stack-protector.ll
     LLVM : :  CodeGen/PowerPC/tailcall1-64.ll
     LLVM : :  CodeGen/PowerPC/tailcall1.ll
     LLVM : :  CodeGen/PowerPC/tailcallpic1.ll
     LLVM : :  CodeGen/PowerPC/varargs.ll
     LLVM : :  CodeGen/PowerPC/vec_auto_constant.ll
     LLVM : :  CodeGen/PowerPC/vec_br_cmp.ll
     LLVM : :  CodeGen/PowerPC/vec_buildvector_loadstore.ll
     LLVM : :  CodeGen/PowerPC/vec_misaligned.ll
     LLVM : :  CodeGen/PowerPC/vec_splat_constant.ll
     LLVM : :  DebugInfo/array.ll
     LLVM : :  ExecutionEngine/2002-12-16-ArgTest.ll
     LLVM : :  ExecutionEngine/2003-01-04-ArgumentBug.ll
     LLVM : :  ExecutionEngine/2003-01-04-LoopTest.ll
     LLVM : :  ExecutionEngine/2003-01-04-PhiTest.ll
     LLVM : :  ExecutionEngine/2003-01-09-SARTest.ll
     LLVM : :  ExecutionEngine/2003-01-10-FUCOM.ll
     LLVM : :  ExecutionEngine/2003-01-15-AlignmentTest.ll
     LLVM : :  ExecutionEngine/2003-05-06-LivenessClobber.ll
     LLVM : :  ExecutionEngine/2003-05-07-ArgumentTest.ll
     LLVM : :  ExecutionEngine/2003-05-11-PHIRegAllocBug.ll
     LLVM : :  ExecutionEngine/2003-06-04-bzip2-bug.ll
     LLVM : :  ExecutionEngine/2003-06-05-PHIBug.ll
     LLVM : :  ExecutionEngine/2003-08-15-AllocaAssertion.ll
     LLVM : :  ExecutionEngine/2003-08-21-EnvironmentTest.ll
     LLVM : :  ExecutionEngine/2003-08-23-RegisterAllocatePhysReg.ll
     LLVM : :
ExecutionEngine/2003-10-18-PHINode-ConstantExpr-CondCode-Failure.ll
     LLVM : :  ExecutionEngine/2005-12-02-TailCallBug.ll
     LLVM : :  ExecutionEngine/hello.ll
     LLVM : :  ExecutionEngine/hello2.ll
     LLVM : :  ExecutionEngine/simplesttest.ll
     LLVM : :  ExecutionEngine/simpletest.ll
     LLVM : :  ExecutionEngine/stubs.ll
     LLVM : :  ExecutionEngine/test-arith.ll
     LLVM : :  ExecutionEngine/test-branch.ll
     LLVM : :  ExecutionEngine/test-call.ll
     LLVM : :  ExecutionEngine/test-cast.ll
     LLVM : :  ExecutionEngine/test-constantexpr.ll
     LLVM : :  ExecutionEngine/test-fp.ll
     LLVM : :  ExecutionEngine/test-loadstore.ll
     LLVM : :  ExecutionEngine/test-logical.ll
     LLVM : :  ExecutionEngine/test-loop.ll
     LLVM : :  ExecutionEngine/test-phi.ll
     LLVM : :  ExecutionEngine/test-ret.ll
     LLVM : :  ExecutionEngine/test-setcond-fp.ll
     LLVM : :  ExecutionEngine/test-setcond-int.ll
     LLVM : :  ExecutionEngine/test-shift.ll
     LLVM : :  Instrumentation/AddressSanitizer/bug_11395.ll
     LLVM : :  Transforms/LICM/2003-12-11-SinkingToPHI.ll
     LLVM : :  Transforms/LoopStrengthReduce/2011-11-29-postincphi.ll
     LLVM : :  Transforms/LoopStrengthReduce/2011-12-04-loserreg.ll

    Expected Passes    : 6537
    Expected Failures  : 40
    Unsupported Tests  : 2881
    Unexpected Passes  : 1
    Unexpected Failures: 204
make[3]: *** [tools/clang/test/CMakeFiles/check-all] Error 1
make[2]: *** [tools/clang/test/CMakeFiles/check-all.dir/all] Error 2
make[1]: *** [tools/clang/test/CMakeFiles/check-all.dir/rule] Error 2
make: *** [check-all] Error 2

Fang

--
David Fang
http://www.csl.cornell.edu/~fang/

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: llvm/clang test failures on powerpc-darwin8

Eli Friedman-2
On Thu, Dec 15, 2011 at 1:17 PM, David Fang <[hidden email]> wrote:

> Hi,
>
> I've bootstrapped llvm/clang from svn-trunk on powerpc-darwin8 (g++-4.0.1), and
> have the following test results to share.
> Summary below, full log at:
> http://www.csl.cornell.edu/~fang/sw/llvm/r146586-powerpc-darwin8-results.txt
>
> The only edits required were those I posted to llvm-commits yesterday (re:
> "some missing clang libs").  And I also edited LitConfig.py to point to
> /sw/bin/bash (4.2) because /bin/bash is missing support for pipefail.
>
> Some of the tests hung indefinitely on 'lli', so I had to kill them.
>
> My question is: which of the following test failures should be addressed first
> as top priority?  Are there any low-hanging fruit that look easy to fix
> (looking at the full log)?

All the tests that say "No available targets" are incorrectly
configured; they assume the x86 backend is available.  They can be
"fixed" easily, but that won't really get you closer to a usable
compiler.

I would guess that all the PCH tests are crashing for the same reason,
so fixing that could fix a lot of failures at once on the clang side.

If you're interested in actually having a usable compiler for your
system, I would say the crashes in CodeGen/Generic and CodeGen/PowerPC
are the highest priority.

-Eli

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: llvm/clang test failures on powerpc-darwin8

David Fang
Hi,
  Thanks for the quick reply again.

> On Thu, Dec 15, 2011 at 1:17 PM, David Fang <[hidden email]> wrote:
>> Hi,
>>
>> I've bootstrapped llvm/clang from svn-trunk on powerpc-darwin8 (g++-4.0.1), and
>> have the following test results to share.
>> Summary below, full log at:
>> http://www.csl.cornell.edu/~fang/sw/llvm/r146586-powerpc-darwin8-results.txt
>>
>> The only edits required were those I posted to llvm-commits yesterday (re:
>> "some missing clang libs").  And I also edited LitConfig.py to point to
>> /sw/bin/bash (4.2) because /bin/bash is missing support for pipefail.
>>
>> Some of the tests hung indefinitely on 'lli', so I had to kill them.
>>
>> My question is: which of the following test failures should be addressed first
>> as top priority?  Are there any low-hanging fruit that look easy to fix
>> (looking at the full log)?
>
> All the tests that say "No available targets" are incorrectly
> configured; they assume the x86 backend is available.  They can be
> "fixed" easily, but that won't really get you closer to a usable
> compiler.
I think these can be ignored for the time being...

> I would guess that all the PCH tests are crashing for the same reason,
> so fixing that could fix a lot of failures at once on the clang side.

> If you're interested in actually having a usable compiler for your
> system, I would say the crashes in CodeGen/Generic and CodeGen/PowerPC
> are the highest priority.

Indeed I am interested.  :)

Here's another interesting data point.
My full build/test log of release-3.0, bootstrapping with
powerpc-darwin8-g++-4.0.1 is here:
http://www.csl.cornell.edu/~fang/sw/llvm/llvm-clang-release-3.0-powerpc-darwin8-g++-4.0.1-fink-build-log.txt
(append .bz2 to URL for compressed version)
fink info file (for darwin8 only):
http://fink.cvs.sourceforge.net/viewvc/fink/experimental/fangism/finkinfo/llvm30.info?view=log
at revision 1.9.  (also patch file needed from the same dir.)

These results have far fewer failures than svn-trunk, and are also
comparable to bootstrapping with gcc-4.6.2, summarized here:
http://paste.lisp.org/display/126363
(Unfortunately, I no longer have the whole build/test log for the gcc46 bootstrap.)
This consistency between different bootstraps of the release gives me some
hope that g++-4.0.1 is yet usable.

I don't know how far diverged trunk is from the 3.0-branch, but there are
far fewer CodeGen test failures than with svn-trunk.  Both trunk and
branch exhibit numerous PCH failures.  Does this suggest some code-gen
regression on the trunk that others could hunt for?

In the full bootstrap log, I see numerous compiler warnings.  Could any of
them be related to potential PCH errors?  For example, I see:
tools/clang/include/clang/Serialization/ASTBitCodes.h:100: warning: passing negative
value '-0x00000000000000001' for argument 1 to 'clang::serialization::TypeIdx::TypeIdx(uint32_t)'
Is the Serialization code involved PCH reading/writing?

Thanks for entertaining my questions.  I know I'm just getting my feet wet
with llvm/clang.

Fang
(I'm fangism in IRC.)

--
David Fang
http://www.csl.cornell.edu/~fang/

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: llvm/clang test failures on powerpc-darwin8

David Fang
>>  I would guess that all the PCH tests are crashing for the same reason,
>>  so fixing that could fix a lot of failures at once on the clang side.
>
>>  If you're interested in actually having a usable compiler for your
>>  system, I would say the crashes in CodeGen/Generic and CodeGen/PowerPC
>>  are the highest priority.
>
> Indeed I am interested.  :)
>
> Here's another interesting data point.
> My full build/test log of release-3.0, bootstrapping with
> powerpc-darwin8-g++-4.0.1 is here:
> http://www.csl.cornell.edu/~fang/sw/llvm/llvm-clang-release-3.0-powerpc-darwin8-g++-4.0.1-fink-build-log.txt
> (append .bz2 to URL for compressed version)
> fink info file (for darwin8 only):
> http://fink.cvs.sourceforge.net/viewvc/fink/experimental/fangism/finkinfo/llvm30.info?view=log
> at revision 1.9.  (also patch file needed from the same dir.)
>
> These results have far fewer failures than svn-trunk, and are also comparable
> to bootstrapping with gcc-4.6.2, summarized here:
> http://paste.lisp.org/display/126363
> (Unfortunately, I no longer have the whole build/test log for the gcc46
> bootstrap.)
> This consistency between different bootstraps of the release gives me some
> hope that g++-4.0.1 is yet usable.

Hi,
  Here's a single run of one failing PCH test.
In clang/lib/Serialization/ASTReader.cpp, I've added a print stmt:
Decl *ASTReader::GetDecl(DeclID ID) {
...
   unsigned Index = ID - NUM_PREDEF_DECL_IDS;

   if (Index > DeclsLoaded.size()) {
     std::fprintf(stderr, "Index = %u\n", Index);
     Error("declaration ID out-of-range for AST file");
     return 0;
   }
...
}

recompiled, re-ran one test:


[fangism:fink.build/llvm30-3.0-0.1/build] fang% bin/llvm-lit -v
../llvm-3.0.src/tools/clang/test/CXX/expr/expr.unary/expr.unary.noexcept/cg.cpp
llvm-lit: lit.cfg:146: note: using clang:
'/Volumes/Mercedes2/sw/src/fink.build/llvm30-3.0-0.1/build/bin/./clang'
-- Testing: 1 tests, 2 threads --
FAIL: Clang :: CXX/expr/expr.unary/expr.unary.noexcept/cg.cpp (1 of 1)
******************** TEST 'Clang ::
CXX/expr/expr.unary/expr.unary.noexcept/cg.cpp' FAILED
********************
Script:
--
/Volumes/Mercedes2/sw/src/fink.build/llvm30-3.0-0.1/build/bin/./clang -cc1
-internal-isystem
/Volumes/Mercedes2/sw/src/fink.build/llvm30-3.0-0.1/build/bin/../lib/clang/3.0/include
-fcxx-exceptions -fexceptions -triple x86_64-apple-darwin10 -S -emit-llvm
-std=c++11 -include
/Volumes/Mercedes2/sw/src/fink.build/llvm30-3.0-0.1/llvm-3.0.src/tools/clang/test/CXX/expr/expr.unary/expr.unary.noexcept/ser.h
/Volumes/Mercedes2/sw/src/fink.build/llvm30-3.0-0.1/llvm-3.0.src/tools/clang/test/CXX/expr/expr.unary/expr.unary.noexcept/cg.cpp
-o - | FileCheck
/Volumes/Mercedes2/sw/src/fink.build/llvm30-3.0-0.1/llvm-3.0.src/tools/clang/test/CXX/expr/expr.unary/expr.unary.noexcept/cg.cpp
/Volumes/Mercedes2/sw/src/fink.build/llvm30-3.0-0.1/build/bin/./clang -cc1
-internal-isystem
/Volumes/Mercedes2/sw/src/fink.build/llvm30-3.0-0.1/build/bin/../lib/clang/3.0/include
-fcxx-exceptions -fexceptions -triple x86_64-apple-darwin10 -emit-pch -o
/Volumes/Mercedes2/sw/src/fink.build/llvm30-3.0-0.1/build/tools/clang/test/CXX/expr/expr.unary/expr.unary.noexcept/Output/cg.cpp.tmp-ser.pch
-std=c++11 -x c++
/Volumes/Mercedes2/sw/src/fink.build/llvm30-3.0-0.1/llvm-3.0.src/tools/clang/test/CXX/expr/expr.unary/expr.unary.noexcept/ser.h
/Volumes/Mercedes2/sw/src/fink.build/llvm30-3.0-0.1/build/bin/./clang -cc1
-internal-isystem
/Volumes/Mercedes2/sw/src/fink.build/llvm30-3.0-0.1/build/bin/../lib/clang/3.0/include
-fcxx-exceptions -fexceptions -triple x86_64-apple-darwin10 -S -emit-llvm
-std=c++11 -include-pch
/Volumes/Mercedes2/sw/src/fink.build/llvm30-3.0-0.1/build/tools/clang/test/CXX/expr/expr.unary/expr.unary.noexcept/Output/cg.cpp.tmp-ser.pch
/Volumes/Mercedes2/sw/src/fink.build/llvm30-3.0-0.1/llvm-3.0.src/tools/clang/test/CXX/expr/expr.unary/expr.unary.noexcept/cg.cpp
-o - | FileCheck
/Volumes/Mercedes2/sw/src/fink.build/llvm30-3.0-0.1/llvm-3.0.src/tools/clang/test/CXX/expr/expr.unary/expr.unary.noexcept/cg.cpp
--
Exit Code: 1
Command Output (stderr):
--
/Volumes/Mercedes2/sw/src/fink.build/llvm30-3.0-0.1/llvm-3.0.src/tools/clang/test/CXX/expr/expr.unary/expr.unary.noexcept/cg.cpp:23:8:
warning: expression result unused
   D(), noexcept(E());
        ^~~~~~~~~~~~~
1 warning generated.
Index = 184549368
fatal error: malformed or corrupted PCH file: 'declaration ID out-of-range
for AST file'
Index = 201326584
1 error generated.
FileCheck error: '-' is empty.
--

********************
Testing Time: 5.22s
********************
Failing Tests (1):
     Clang :: CXX/expr/expr.unary/expr.unary.noexcept/cg.cpp

   Unexpected Failures: 1


According to the printed "Index = ...",
GetDecl returns twice with what looks like some garbage integers.
Any possible explanation or hints on where to look from here?

Fang


--
David Fang
http://www.csl.cornell.edu/~fang/

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: llvm/clang test failures on powerpc-darwin8

Jack Howarth-3
In reply to this post by David Fang
On Fri, Dec 16, 2011 at 01:51:57AM -0500, David Fang wrote:

> Hi,
> Thanks for the quick reply again.
>
>> On Thu, Dec 15, 2011 at 1:17 PM, David Fang <[hidden email]> wrote:
>>> Hi,
>>>
>>> I've bootstrapped llvm/clang from svn-trunk on powerpc-darwin8 (g++-4.0.1), and
>>> have the following test results to share.
>>> Summary below, full log at:
>>> http://www.csl.cornell.edu/~fang/sw/llvm/r146586-powerpc-darwin8-results.txt
>>>
>>> The only edits required were those I posted to llvm-commits yesterday (re:
>>> "some missing clang libs").  And I also edited LitConfig.py to point to
>>> /sw/bin/bash (4.2) because /bin/bash is missing support for pipefail.
>>>
>>> Some of the tests hung indefinitely on 'lli', so I had to kill them.
>>>
>>> My question is: which of the following test failures should be addressed first
>>> as top priority?  Are there any low-hanging fruit that look easy to fix
>>> (looking at the full log)?
>>
>> All the tests that say "No available targets" are incorrectly
>> configured; they assume the x86 backend is available.  They can be
>> "fixed" easily, but that won't really get you closer to a usable
>> compiler.
>
> I think these can be ignored for the time being...
>
>> I would guess that all the PCH tests are crashing for the same reason,
>> so fixing that could fix a lot of failures at once on the clang side.
>
>> If you're interested in actually having a usable compiler for your
>> system, I would say the crashes in CodeGen/Generic and CodeGen/PowerPC
>> are the highest priority.
>
> Indeed I am interested.  :)
>
> Here's another interesting data point.
> My full build/test log of release-3.0, bootstrapping with  
> powerpc-darwin8-g++-4.0.1 is here:
> http://www.csl.cornell.edu/~fang/sw/llvm/llvm-clang-release-3.0-powerpc-darwin8-g++-4.0.1-fink-build-log.txt
> (append .bz2 to URL for compressed version)
> fink info file (for darwin8 only):  
> http://fink.cvs.sourceforge.net/viewvc/fink/experimental/fangism/finkinfo/llvm30.info?view=log
> at revision 1.9.  (also patch file needed from the same dir.)
>
> These results have far fewer failures than svn-trunk, and are also  
> comparable to bootstrapping with gcc-4.6.2, summarized here:  
> http://paste.lisp.org/display/126363
> (Unfortunately, I no longer have the whole build/test log for the gcc46 bootstrap.)
> This consistency between different bootstraps of the release gives me
> some hope that g++-4.0.1 is yet usable.

David,
   Another alternative for darwin8 would be to bootstrap llvm/clang 3.0 using
the clang from the fink llvm29 package (since clang 2.9 should build fine against
gcc-4.0.1).
            Jack

>
> I don't know how far diverged trunk is from the 3.0-branch, but there are
> far fewer CodeGen test failures than with svn-trunk.  Both trunk and  
> branch exhibit numerous PCH failures.  Does this suggest some code-gen  
> regression on the trunk that others could hunt for?
>
> In the full bootstrap log, I see numerous compiler warnings.  Could any
> of them be related to potential PCH errors?  For example, I see:
> tools/clang/include/clang/Serialization/ASTBitCodes.h:100: warning:
> passing negative value '-0x00000000000000001' for argument 1 to
> 'clang::serialization::TypeIdx::TypeIdx(uint32_t)'
> Is the Serialization code involved PCH reading/writing?
>
> Thanks for entertaining my questions.  I know I'm just getting my feet
> wet with llvm/clang.
>
> Fang
> (I'm fangism in IRC.)
>
> --
> David Fang
> http://www.csl.cornell.edu/~fang/

> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: llvm/clang test failures on powerpc-darwin8

David Fang
>> These results have far fewer failures than svn-trunk, and are also
>> comparable to bootstrapping with gcc-4.6.2, summarized here:
>> http://paste.lisp.org/display/126363
>> (Unfortunately, I no longer have the whole build/test log for the gcc46 bootstrap.)
>> This consistency between different bootstraps of the release gives me
>> some hope that g++-4.0.1 is yet usable.
>
> David,
>   Another alternative for darwin8 would be to bootstrap llvm/clang 3.0 using
> the clang from the fink llvm29 package (since clang 2.9 should build fine against
> gcc-4.0.1).
>            Jack

Hi Jack,
  I never managed to successfully build llvm29 on powerpc-darwin8,
after running into some build issues, and having filed bug 9958, I got the
impression of ppc-darwin being "not supported", so I didn't put much more
effort into it back then.  However llvm28 did build, and I still have
it installed and hidden away.  (It looks like *someone* runs ppc-darwin
a buildbot, but not for darwin8.)  Knowing what I've learned so far, the
effort would be similar, perhaps even duplicate to just trying to fix
things directly with g++-4.0.1.  Time will tell, I suppose.

Fang


--
David Fang
http://www.csl.cornell.edu/~fang/

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: llvm/clang test failures on powerpc-darwin8

Jack Howarth-3
On Fri, Dec 16, 2011 at 12:17:32PM -0500, David Fang wrote:

>>> These results have far fewer failures than svn-trunk, and are also
>>> comparable to bootstrapping with gcc-4.6.2, summarized here:
>>> http://paste.lisp.org/display/126363
>>> (Unfortunately, I no longer have the whole build/test log for the gcc46 bootstrap.)
>>> This consistency between different bootstraps of the release gives me
>>> some hope that g++-4.0.1 is yet usable.
>>
>> David,
>>   Another alternative for darwin8 would be to bootstrap llvm/clang 3.0 using
>> the clang from the fink llvm29 package (since clang 2.9 should build fine against
>> gcc-4.0.1).
>>            Jack
>
> Hi Jack,
> I never managed to successfully build llvm29 on powerpc-darwin8, after
> running into some build issues, and having filed bug 9958, I got the  
> impression of ppc-darwin being "not supported", so I didn't put much more
> effort into it back then.  However llvm28 did build, and I still have it
> installed and hidden away.  (It looks like *someone* runs ppc-darwin a
> buildbot, but not for darwin8.)  Knowing what I've learned so far, the  
> effort would be similar, perhaps even duplicate to just trying to fix  
> things directly with g++-4.0.1.  Time will tell, I suppose.
>
> Fang
>

David,
   I suspect you might be running into problem with...

CMAKE_OPTIONS="-DLLVM_BUILD_32_BITS:BOOL=ON -DLLVM_TARGETS_TO_BUILD=PowerPC"

not working properly in the llvm 2.9 release for building with cmake.

http://llvm.org/bugs/show_bug.cgi?id=9957

If you can tolerate the complete build by changing this to...

CMAKE_OPTIONS="-DLLVM_BUILD_32_BITS:BOOL=ON"

then llvm 2.9 should build on powerpc-apple-darwin8. This issue shouldn't exist for
i386-apple-darwin8.
           Jack
>
> --
> David Fang
> http://www.csl.cornell.edu/~fang/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: llvm/clang test failures on powerpc-darwin8

David Fang
>> Hi Jack,
>> I never managed to successfully build llvm29 on powerpc-darwin8, after
>> running into some build issues, and having filed bug 9958, I got the
>> impression of ppc-darwin being "not supported", so I didn't put much more
>> effort into it back then.  However llvm28 did build, and I still have it
>> installed and hidden away.  (It looks like *someone* runs ppc-darwin a
>> buildbot, but not for darwin8.)  Knowing what I've learned so far, the
>> effort would be similar, perhaps even duplicate to just trying to fix
>> things directly with g++-4.0.1.  Time will tell, I suppose.
>>
>> Fang
>>
>
> David,
>   I suspect you might be running into problem with...
>
> CMAKE_OPTIONS="-DLLVM_BUILD_32_BITS:BOOL=ON -DLLVM_TARGETS_TO_BUILD=PowerPC"
>
> not working properly in the llvm 2.9 release for building with cmake.
>
> http://llvm.org/bugs/show_bug.cgi?id=9957
>
> If you can tolerate the complete build by changing this to...
>
> CMAKE_OPTIONS="-DLLVM_BUILD_32_BITS:BOOL=ON"
>
> then llvm 2.9 should build on powerpc-apple-darwin8. This issue shouldn't exist for
> i386-apple-darwin8.
>           Jack

I took care of that issue already, then there's:
http://llvm.org/bugs/show_bug.cgi?id=9958

/usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: multiple definitions of
symbol _abort
/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libpthread.dylib(abort.So)
definition of _abort
../../lib/libLLVMSupport.a(Signals.cpp.o) definition of _abort in section
(__TEXT,__text)
collect2: ld returned 1 exit status
make[2]: *** [bin/tblgen] Error 1

I don't see this issue on 3.0 or trunk, but the linker does issue
repeated warnings in all of my build logs with 3.0 and trunk:

/usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: warning suggest use of
-bind_at_load, as lazy binding may result in errors or different symbols being used
symbol _abort used from dynamic library
../../lib/libLLVMSupport.dylib(Signals.cpp.o) not from earlier dynamic library
/usr/lib/libSystem.B.dylib(abort.So)
symbol _raise used from dynamic library
../../lib/libLLVMSupport.dylib(Signals.cpp.o) not from earlier dynamic library
/usr/lib/libSystem.B.dylib(raise.So)

I haven't tried to add the -bind_at_load flag to the executable linker
flags yet, not even sure if that would be correct.

Fang

--
David Fang
http://www.csl.cornell.edu/~fang/

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: llvm/clang test failures on powerpc-darwin8

David Fang
In reply to this post by David Fang
>>> These results have far fewer failures than svn-trunk, and are also
>>> comparable to bootstrapping with gcc-4.6.2, summarized here:
>>> http://paste.lisp.org/display/126363
>>> (Unfortunately, I no longer have the whole build/test log for the gcc46 bootstrap.)
>>> This consistency between different bootstraps of the release gives me
>>> some hope that g++-4.0.1 is yet usable.
>>
>> David,
>>   Another alternative for darwin8 would be to bootstrap llvm/clang 3.0 using
>> the clang from the fink llvm29 package (since clang 2.9 should build fine against
>> gcc-4.0.1).
>>            Jack
>
> Hi Jack,
> I never managed to successfully build llvm29 on powerpc-darwin8,
> after running into some build issues, and having filed bug 9958, I got the
> impression of ppc-darwin being "not supported", so I didn't put much more
> effort into it back then.  However llvm28 did build, and I still have
> it installed and hidden away.  (It looks like *someone* runs ppc-darwin
> a buildbot, but not for darwin8.)  Knowing what I've learned so far, the
> effort would be similar, perhaps even duplicate to just trying to fix
> things directly with g++-4.0.1.  Time will tell, I suppose.

I just tried to cmake with clang/llvm 2.8, the last release that built
cleanly (but never tested), and it just spews out endless nonsense when I
try to compile simple test programs during cmake.  It's also missing a C++
include path, /usr/include/c++/4.0.0/powerpc-darwin8 (bunch of paths
mis-hardcoded to darwin10), which I've fixed in my local patches
and edits for trunk and release-3.0 builds.

% /sw/opt/llvm-2.8/bin/clang -x c++ -v -fsyntax-only /dev/null
clang version 2.8 (branches/release_28)
Target: powerpc-apple-darwin8
Thread model: posix
  "/Volumes/Mercedes2/sw/opt/llvm-2.8/bin/clang" -cc1 -triple
powerpc-apple-darwin8 -fsyntax-only -disable-free -disable-llvm-verifier
-main-file-name null -pic-level 1 -mdisable-fp-elim -v -resource-dir
/Volumes/Mercedes2/sw/opt/llvm-2.8/lib/clang/2.8 -ferror-limit 19
-fmessage-length 80 -fexceptions -fdiagnostics-show-option
-fcolor-diagnostics -x c++ /dev/null
clang -cc1 version 2.8 based upon llvm 2.8 hosted on powerpc-apple-darwin8
ignoring nonexistent directory "/usr/include/c++/4.2.1"
ignoring nonexistent directory
"/usr/include/c++/4.2.1/powerpc-apple-darwin10/"
ignoring nonexistent directory "/usr/include/c++/4.2.1/backward"
ignoring nonexistent directory
"/usr/include/c++/4.0.0/powerpc-apple-darwin10/"
ignoring nonexistent directory "/usr/local/include"
#include "..." search starts here:
#include <...> search starts here:
  /usr/include/c++/4.0.0
  /usr/include/c++/4.0.0/backward
  /Volumes/Mercedes2/sw/opt/llvm-2.8/lib/clang/2.8/include
  /usr/include
  /System/Library/Frameworks (framework directory)
  /Library/Frameworks (framework directory)
End of search list.

I don't think it would be very productive to fix up 2.8 or 2.9 for the
sake of bootstrapping 3.0+, when I've gotten so far using the system
g++-4.0.1, and fink gcc46.

Fang

--
David Fang
http://www.csl.cornell.edu/~fang/

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev