llvm/clang test failures on powerpc-darwin8

Project Infrastructure LLVM Dev List Archives
1

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:

2

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

3

Hi,
   Thanks for the quick reply again.

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. :slight_smile:

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): CVS Info for project fink
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.)

4

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. :slight_smile:

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): CVS Info for project fink
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

5

Hi,
  Thanks for the quick reply again.

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. :slight_smile:

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):
CVS Info for project fink
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

6

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

7

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

8

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.

9957 – cmake -DLLVM_TARGETS_TO_BUILD=PowerPC broken

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

9

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