From a build (still not functional) of the UPC runtime on Solaris:

/home/phargrov/llvm-upc/src/llvm/tools/clang/runtime/libupc/smp/upc_backtrace.c:239:38: warning: format specifies type 'int' but the argument has type 'pid_t' (aka 'long') [-Wformat]
              sprintf(pid_buf, "%d", getpid());
                                ~~   ^~~~~~~~
                                %ld
/home/phargrov/llvm-upc/src/llvm/tools/clang/runtime/libupc/smp/upc_backtrace.c:306:41: warning: format specifies type 'int' but the argument has type 'pid_t' (aka 'long') [-Wformat]
          fprintf (stderr, "   %4d   %d\n", i, __upc_info->thread_info[i].pid);
                                     ~~        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                     %ld
2 warnings generated.

The version 1.3 specification refines the semantics of UPC's shared array types. The issue is described here:
http://code.google.com/p/upc-specification/issues/detail?id=3

A test case, td2_arry.c is documented here:
http://code.google.com/p/upc-specification/issues/detail?id=3#c98

The purpose of this issue is to track clang-upc's conformance to the shared array semantics documented in UPC specification issue 3.

After upgrade to 3.4 this test crashes the compiler.

+0.     Program arguments: /eng/upc/dev/nenad/clang-upc/bld/bin/clang-3.4 -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free -disable-llvm-verifier -main-file-name shared-array-init-unsupported.upc -mrelocation-model static -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -momit-leaf-frame-pointer -g -coverage-file /eng/upc/dev/nenad/clang-upc/clang-upc-tests/upc-semantics/shared-array-init-unsupported.o -resource-dir /eng/upc/dev/nenad/clang-upc/bld/bin/../lib/clang/3.4 -internal-isystem /usr/local/include -internal-isystem /eng/upc/dev/nenad/clang-upc/bld/bin/../lib/clang/3.4/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -O2 -Wall -Wextra -Wwrite-strings -Werror -pedantic-errors -fconst-strings -fdebug-compilation-dir /eng/upc/dev/nenad/clang-upc/clang-upc-tests/upc-semantics -ferror-limit 19 -fmessage-length 0 -mstackrealign -fobjc-runtime=gcc -fupc-threads 8 -fdiagnostics-show-option -vectorize-loops -vectorize-slp -o shared-array-init-unsupported.o -x upc shared-array-init-unsupported.upc 
+1.     <eof> parser at end of file
+2.     shared-array-init-unsupported.upc:5:12: LLVM IR generation of declaration 'A'
+3.     shared-array-init-unsupported.upc:5:12: Generating code for declaration 'A'
+clang-3.4: error: unable to execute command: Segmentation fault (core dumped)
+clang-3.4: error: clang frontend command failed due to signal (use -v to see invocation)
+clang version 3.4  (UPC 20140113)
+Target: x86_64-unknown-linux-gnu
+Thread model: posix
+clang-3.4: note: diagnostic msg: PLEASE submit a bug report to  and include the crash backtrace, preprocessed source, and associated run script.
+0  clangupc        0x0000000001c51111 llvm::sys::PrintStackTrace(_IO_FILE*) + 38
+1  clangupc        0x0000000001c51398
+2  clangupc        0x0000000001c50ddc
+3  libpthread.so.0 0x0000003509e0f000
+4  libc.so.6       0x0000003509360551
+5  clangupc        0x0000000000c2e59b
+6  clangupc        0x0000000001e963ce clang::driver::Driver::GetTemporaryPath(llvm::StringRef, char const*) const + 86
+7  clangupc        0x0000000001e94474 clang::driver::Driver::GetNamedOutputPath(clang::driver::Compilation&, clang::driver::JobAction const&, char const*, char const*, bool, bool) const + 1314
+8  clangupc        0x0000000001e93a47 clang::driver::Driver::BuildJobsForAction(clang::driver::Compilation&, clang::driver::Action const*, clang::driver::ToolChain const*, char const*, bool, bool, char const*, clang::driver::InputInfo&) const + 1315
+9  clangupc        0x0000000001e92d06 clang::driver::Driver::BuildJobs(clang::driver::Compilation&) const + 866
+10 clangupc        0x0000000001e8df6d clang::driver::Driver::generateCompilationDiagnostics(clang::driver::Compilation&, clang::driver::Command const*) + 1659
+11 clangupc        0x0000000000c2e36a main + 4142
+12 libc.so.6       0x0000003509221a05 __libc_start_main + 245
+13 clangupc        0x0000000000c2bf49
+Stack dump:
+0.     Program arguments: /eng/upc/dev/nenad/clang-upc/bld/bin/clangupc -O2 -Wall -Wextra -Wwrite-strings -Werror -g -c -pedantic-errors -fupc-threads-8 shared-array-init-unsupported.upc 
+1.     Building compilation jobs
+2.     Building compilation jobs
+3.     Computing output path
make: *** [shared-array-init-unsupported.s-out] Error 1

Today's latest code doesn't build on Linux/ppc64.
This is the first time I've tried in quite a while.

I am seeing an internal compiler error from the just-built clang when it is trying to compile upc_barrier.upc in the smp runtime.

[ 95%] Built target upc-link-script
[ 95%] Building C object tools/clang/runtime/libupc/CMakeFiles/upc-s.dir/smp/upc_barrier.upc.o
fatal error: error in backend: Cannot select: 0x1001078d000: i64 = zero_extend 0x1001078c4f0 [ORD=36] [ID=62]
  0x1001078c4f0: i64 = add 0x1001078bae0, 0x1001078aee0 [ORD=27] [ID=60]
    0x1001078bae0: i64 = PPCISD::TOC_ENTRY 0x100107814e0, 0x1001078c2f0 [ORD=27] [ID=35]
      0x100107814e0: i64 = TargetGlobalAddress<[1 x %struct.barrier_block]* @__upc_btree> 0 [ORD=27] [ID=23]
      0x1001078c2f0: i64 = Register %X2 [ID=24]
    0x1001078aee0: i64 = shl 0x1001078bff0, 0x10010780de0 [ORD=26] [ID=57]
      0x1001078bff0: i64 = select_cc 0x1001078c1f0, 0x100107810e0, 0x1001078c0f0, 0x100107811e0, 0x1001078ade0 [ORD=20] [ID=53]
        0x1001078c1f0: i64 = sub 0x10010780fe0, 0x10010780ee0 [ORD=15] [ID=49]
          0x10010780fe0: i64,ch = load 0x10010761238, 0x1001078b3e0, 0x100107813e0<LD4[@MYTHREAD], sext from i32> [ORD=9] [ID=42]
            0x1001078b3e0: i64 = PPCISD::TOC_ENTRY 0x1001078afe0, 0x1001078c2f0 [ORD=8] [ID=37]
              0x1001078afe0: i64 = TargetGlobalAddress<i32* @MYTHREAD> 0 [ORD=8] [ID=26]
              0x1001078c2f0: i64 = Register %X2 [ID=24]
            0x100107813e0: i64 = undef [ID=3]
          0x10010780ee0: i64 = mul 0x100107811e0, 0x100107815e0 [ORD=15] [ID=46]
            0x100107811e0: i64 = sdiv 0x10010780fe0, 0x100107815e0 [ORD=14] [ID=44]
              0x10010780fe0: i64,ch = load 0x10010761238, 0x1001078b3e0, 0x100107813e0<LD4[@MYTHREAD], sext from i32> [ORD=9] [ID=42]
                0x1001078b3e0: i64 = PPCISD::TOC_ENTRY 0x1001078afe0, 0x1001078c2f0 [ORD=8] [ID=37]
                  0x1001078afe0: i64 = TargetGlobalAddress<i32* @MYTHREAD> 0 [ORD=8] [ID=26]
                  0x1001078c2f0: i64 = Register %X2 [ID=24]
                0x100107813e0: i64 = undef [ID=3]
              0x100107815e0: i64,ch = load 0x10010761238, 0x1001078b1e0, 0x100107813e0<LD4[@THREADS], zext from i32> [ORD=11] [ID=41]
                0x1001078b1e0: i64 = PPCISD::TOC_ENTRY 0x1001078c3f0, 0x1001078c2f0 [ORD=10] [ID=36]
                  0x1001078c3f0: i64 = TargetGlobalAddress<i32* @THREADS> 0 [ORD=10] [ID=25]
                  0x1001078c2f0: i64 = Register %X2 [ID=24]
                0x100107813e0: i64 = undef [ID=3]
            0x100107815e0: i64,ch = load 0x10010761238, 0x1001078b1e0, 0x100107813e0<LD4[@THREADS], zext from i32> [ORD=11] [ID=41]
              0x1001078b1e0: i64 = PPCISD::TOC_ENTRY 0x1001078c3f0, 0x1001078c2f0 [ORD=10] [ID=36]
                0x1001078c3f0: i64 = TargetGlobalAddress<i32* @THREADS> 0 [ORD=10] [ID=25]
                0x1001078c2f0: i64 = Register %X2 [ID=24]
              0x100107813e0: i64 = undef [ID=3]
        0x100107810e0: i64 = Constant<0> [ID=2]
        0x1001078c0f0: i64 = add 0x100107811e0, 0x1001078bbe0 [ORD=19] [ID=47]
          0x100107811e0: i64 = sdiv 0x10010780fe0, 0x100107815e0 [ORD=14] [ID=44]
            0x10010780fe0: i64,ch = load 0x10010761238, 0x1001078b3e0, 0x100107813e0<LD4[@MYTHREAD], sext from i32> [ORD=9] [ID=42]
              0x1001078b3e0: i64 = PPCISD::TOC_ENTRY 0x1001078afe0, 0x1001078c2f0 [ORD=8] [ID=37]
                0x1001078afe0: i64 = TargetGlobalAddress<i32* @MYTHREAD> 0 [ORD=8] [ID=26]
                0x1001078c2f0: i64 = Register %X2 [ID=24]
              0x100107813e0: i64 = undef [ID=3]
            0x100107815e0: i64,ch = load 0x10010761238, 0x1001078b1e0, 0x100107813e0<LD4[@THREADS], zext from i32> [ORD=11] [ID=41]
              0x1001078b1e0: i64 = PPCISD::TOC_ENTRY 0x1001078c3f0, 0x1001078c2f0 [ORD=10] [ID=36]
                0x1001078c3f0: i64 = TargetGlobalAddress<i32* @THREADS> 0 [ORD=10] [ID=25]
                0x1001078c2f0: i64 = Register %X2 [ID=24]
              0x100107813e0: i64 = undef [ID=3]
          0x1001078bbe0: i64 = Constant<-1> [ID=20]
        0x100107811e0: i64 = sdiv 0x10010780fe0, 0x100107815e0 [ORD=14] [ID=44]
          0x10010780fe0: i64,ch = load 0x10010761238, 0x1001078b3e0, 0x100107813e0<LD4[@MYTHREAD], sext from i32> [ORD=9] [ID=42]
            0x1001078b3e0: i64 = PPCISD::TOC_ENTRY 0x1001078afe0, 0x1001078c2f0 [ORD=8] [ID=37]
              0x1001078afe0: i64 = TargetGlobalAddress<i32* @MYTHREAD> 0 [ORD=8] [ID=26]
              0x1001078c2f0: i64 = Register %X2 [ID=24]
            0x100107813e0: i64 = undef [ID=3]
          0x100107815e0: i64,ch = load 0x10010761238, 0x1001078b1e0, 0x100107813e0<LD4[@THREADS], zext from i32> [ORD=11] [ID=41]
            0x1001078b1e0: i64 = PPCISD::TOC_ENTRY 0x1001078c3f0, 0x1001078c2f0 [ORD=10] [ID=36]
              0x1001078c3f0: i64 = TargetGlobalAddress<i32* @THREADS> 0 [ORD=10] [ID=25]
              0x1001078c2f0: i64 = Register %X2 [ID=24]
            0x100107813e0: i64 = undef [ID=3]
      0x10010780de0: i32 = Constant<4> [ID=21]
In function: __upc_notify
clang-3.4: error: clang frontend command failed with exit code 70 (use -v to see invocation)
clang version 3.4  (UPC 3.4.0-1 20140528)
Target: powerpc64-unknown-linux-gnu
Thread model: posix
clang-3.4: note: diagnostic msg: PLEASE submit a bug report to  and include the crash backtrace, preprocessed source, and associated run script.
0  clang     0x00000000116d59e4 llvm::sys::PrintStackTrace(_IO_FILE*) + 4259472620
1  clang     0x00000000116d5d74
2  clang     0x00000000116d53e0
3            0x00000fffb4440418 __kernel_sigtramp_rt64 + 0
4  clang     0x00000000107db568
5  clang     0x0000000011a25dfc clang::driver::Driver::GetTemporaryPath(llvm::StringRef, char const*) const + 4262478908
6  clang     0x0000000011a240c8 clang::driver::Driver::GetNamedOutputPath(clang::driver::Compilation&, clang::driver::JobAction const&, char const*, char const*, bool, bool) const + 4262471504
7  clang     0x0000000011a23624 clang::driver::Driver::BuildJobsForAction(clang::driver::Compilation&, clang::driver::Action const*, clang::driver::ToolChain const*, char const*, bool, bool, char const*, clang::driver::InputInfo&) const + 4262468828
8  clang     0x0000000011a22840 clang::driver::Driver::BuildJobs(clang::driver::Compilation&) const + 4262465344
9  clang     0x0000000011a1d588 clang::driver::Driver::generateCompilationDiagnostics(clang::driver::Compilation&, clang::driver::Command const*) + 4262444648
10 clang     0x00000000107b5d3c main + 4245463684
11 libc.so.6 0x00000080c9b2bcd8
12 libc.so.6 0x00000080c9b2bed0 __libc_start_main + 4293374464
Stack dump:
0.      Program arguments: /home/hargrov1/upcnightly/llvm-upc-cmake/bld/bin/clang -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_REWRITER -DCLANG_ENABLE_STATIC_ANALYZER -DGUPCR_PTS_PHASE_SIZE=32 -DGUPCR_PTS_STRUCT_REP=1 -DGUPCR_PTS_THREAD_SIZE=32 -DGUPCR_PTS_VADDR_FIRST=1 -DGUPCR_PTS_VADDR_SIZE=64 -DIN_TARGET_LIBS=1 -DNDEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -fno-optimize-sibling-calls -fPIC -Wall -W -Wno-unused-parameter -Wwrite-strings -Wno-missing-field-initializers -pedantic -Wno-long-long -I/home/hargrov1/upcnightly/llvm-upc-cmake/bld/tools/clang/runtime/libupc -I/home/hargrov1/upcnightly/llvm-upc-cmake/src/tools/clang/runtime/libupc -I/home/hargrov1/upcnightly/llvm-upc-cmake/src/tools/clang/include -I/home/hargrov1/upcnightly/llvm-upc-cmake/bld/tools/clang/include -I/home/hargrov1/upcnightly/llvm-upc-cmake/bld/include -I/home/hargrov1/upcnightly/llvm-upc-cmake/src/include -I/home/hargrov1/upcnightly/llvm-upc-cmake/src/tools/clang/runtime/libupc/include -I/home/hargrov1/upcnightly/llvm-upc-cmake/src/tools/clang/runtime/libupc/collectives -Wno-gnu -Wno-language-extension-token -fupc-pts=struct -fupc-pts-vaddr-order=first -o CMakeFiles/upc-s.dir/smp/upc_barrier.upc.o -c /home/hargrov1/upcnightly/llvm-upc-cmake/src/tools/clang/runtime/libupc/smp/upc_barrier.upc
1.      Building compilation jobs
2.      Building compilation jobs
3.      Computing output path
/bin/sh: line 1: 17582 Segmentation fault      /home/hargrov1/upcnightly/llvm-upc-cmake/bld/bin/clang -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_REWRITER -DCLANG_ENABLE_STATIC_ANALYZER -DGUPCR_PTS_PHASE_SIZE=32 -DGUPCR_PTS_STRUCT_REP=1 -DGUPCR_PTS_THREAD_SIZE=32 -DGUPCR_PTS_VADDR_FIRST=1 -DGUPCR_PTS_VADDR_SIZE=64 -DIN_TARGET_LIBS=1 -DNDEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -fno-optimize-sibling-calls -fPIC -Wall -W -Wno-unused-parameter -Wwrite-strings -Wno-missing-field-initializers -pedantic -Wno-long-long -I/home/hargrov1/upcnightly/llvm-upc-cmake/bld/tools/clang/runtime/libupc -I/home/hargrov1/upcnightly/llvm-upc-cmake/src/tools/clang/runtime/libupc -I/home/hargrov1/upcnightly/llvm-upc-cmake/src/tools/clang/include -I/home/hargrov1/upcnightly/llvm-upc-cmake/bld/tools/clang/include -I/home/hargrov1/upcnightly/llvm-upc-cmake/bld/include -I/home/hargrov1/upcnightly/llvm-upc-cmake/src/include -I/home/hargrov1/upcnightly/llvm-upc-cmake/src/tools/clang/runtime/libupc/include -I/home/hargrov1/upcnightly/llvm-upc-cmake/src/tools/clang/runtime/libupc/collectives -Wno-gnu -Wno-language-extension-token -fupc-pts=struct -fupc-pts-vaddr-order=first -o CMakeFiles/upc-s.dir/smp/upc_barrier.upc.o -c /home/hargrov1/upcnightly/llvm-upc-cmake/src/tools/clang/runtime/libupc/smp/upc_barrier.upc
make[2]: *** [tools/clang/runtime/libupc/CMakeFiles/upc-s.dir/smp/upc_barrier.upc.o] Error 139
make[1]: *** [tools/clang/runtime/libupc/CMakeFiles/upc-s.dir/all] Error 2
make: *** [all] Error 2

Test bug137c fails to produce the right result. Has nothing to do with UPC and I am able to reproduce the problem on the LLVM/CLANG trunk and this simple code:

#include <stdarg.h>
#include <stdio.h>
#include <string.h>

int x = 1;
int q = 1;
double y = 7.0;

double foo() {
  double d = x + y + q;
  printf("fooL %g\n", d);
  return d;
}

int main(void) {

  double b = foo();
  if (b != 9.0) {
    printf("FAILED (result = %g but expect 9.0)\n", b);
  } else {
    printf("SUCCESS\n");
  }
}

This test fails on -O0 only. IR looks fine, it must be LLVM code generation problem.

I'll see where to file LLVM bugs.

Copied from Redmine:

As of today, the Clang 3.2 release candidate will be feature frozen.
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-November/026095.html

To get a head start, it would be good to set up a 3.2 merge branch in the clang-upc and llvm-upc repositories and make the necessary changes to be ready for the switch over to 3.2.

I'm willing to give this a try and then to perhaps file specific issue tickets as problems arise.

However, I am not git savvy, and would first appreciate some guidance on the steps needed to set this up.

Updated by John Wiegley 3 months ago

* Description updated (diff)
* Assignee set to Gary Funck

Comment

Assuming their release branch is named release-3.2, you would run (in your master):

git merge -s recursive -X patience -X ignore-all-space release-3.2

You will likely have many conflicts to resolve by hand.
#2

Updated by Gary Funck 3 months ago
Comment

John Wiegley wrote:

Assuming their release branch is named release-3.2, you would run (in your master):

git merge -s recursive -X patience -X ignore-all-space release-3.2

You will likely have many conflicts to resolve by hand.

Hmmm ... I'm a bit hazy on the relationship between 'master' in the llvm-upc and clang-upc repositories and the upstream llvm/clang mirror repositories.

clang-mirror <-> clang-upc <-> local clang-upc

Do I some how need to pull from 'clang-mirror' to even see the newer master and any related branches?

Also, how do I list what branches are available, the change logs, etc. for the the clang-mirror without physically cloning it first?

Here is what I see from my local clang-upc repository:

$ git branch -a

• master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
  remotes/origin/release_1
  remotes/origin/release_16
  [...]
  remotes/origin/release_30
  remotes/origin/release_31
  remotes/origin/svn-tags/RELEASE_1
  remotes/origin/svn-tags/RELEASE_20
  [...]
  remotes/origin/svn-tags/RELEASE_30
  remotes/origin/svn-tags/RELEASE_31

$ git config -l
user.name=Gary Funck
user.email=[email protected]
github.user=gary-funck
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
remote.origin.fetch=+refs/heads/:refs/remotes/origin/
remote.origin.url=github.com:Intrepid/clang-upc
branch.master.remote=origin
branch.master.merge=refs/heads/master
#3

Updated by John Wiegley 3 months ago
Comment

You will have to add the clang-mirror as a new remote to your own local repository, and then merge from that remote. Example:

git remote add -f mirror URL
git ... merge mirror/release_32

And then push up to the master in your repository with just a simple push command.
#4

Updated by Gary Funck 3 months ago
Comment

John Wiegley wrote:

You will have to add the clang-mirror as a new remote to your own local repository, and then merge from that remote. Example:

git remote add -f mirror URL
git ... merge mirror/release_32

And then push up to the master in your repository with just a simple push command.

Makes sense. Thanks. Next question: why merge and not rebase?
#5

Updated by John Wiegley 3 months ago
Comment

Because your master branch is already "out in the wild".
#6

Updated by Gary Funck 3 months ago
Comment

John Wiegley wrote:

You will likely have many conflicts to resolve by hand.

Sixty/so files with merge conflicts. Should be interesting.
#7

Updated by John Wiegley 3 months ago
Comment

Sounds about right. This script will give you the total count:

grep '<<<<<<<' *.c *.h | uniq -c | sort -n | sed 's/:<<<<<<< HEAD//'
#8

Updated by Gary Funck 3 months ago
Comment

A slightly different incantation below.

$ grep -cr '^<<<<<<< HEAD' . | sort -t: -k2n | awk -F: '$2 != 0 {s+=$2;print}END{print "Total: " s}'
./llvm/tools/clang/include/clang/AST/OperationKinds.h:1
./llvm/tools/clang/include/clang/AST/Stmt.h:1
./llvm/tools/clang/include/clang/Basic/DiagnosticParseKinds.td:1
./llvm/tools/clang/include/clang/Basic/StmtNodes.td:1
./llvm/tools/clang/include/clang/Basic/TokenKinds.def:1
./llvm/tools/clang/include/clang/Driver/CC1Options.td:1
./llvm/tools/clang/include/clang/Driver/Options.td:1
./llvm/tools/clang/include/clang/Driver/Types.def:1
./llvm/tools/clang/include/clang/Sema/DeclSpec.h:1
./llvm/tools/clang/include/clang/Sema/Scope.h:1
./llvm/tools/clang/include/clang/Serialization/ASTBitCodes.h:1
./llvm/tools/clang/lib/Analysis/UninitializedValues.cpp:1
./llvm/tools/clang/lib/AST/ASTContext.cpp:1
./llvm/tools/clang/lib/AST/MicrosoftMangle.cpp:1
./llvm/tools/clang/lib/AST/StmtProfile.cpp:1
./llvm/tools/clang/lib/Basic/IdentifierTable.cpp:1
./llvm/tools/clang/lib/CodeGen/CGDeclCXX.cpp:1
./llvm/tools/clang/lib/CodeGen/CGExprComplex.cpp:1
./llvm/tools/clang/lib/CodeGen/CGExprScalar.cpp:1
./llvm/tools/clang/lib/CodeGen/CodeGenModule.cpp:1
./llvm/tools/clang/lib/Driver/Tools.cpp:1
./llvm/tools/clang/lib/Frontend/CompilerInvocation.cpp:1
./llvm/tools/clang/lib/Parse/ParseDecl.cpp:1
./llvm/tools/clang/lib/Parse/ParseDeclCXX.cpp:1
./llvm/tools/clang/lib/Parse/ParseExprCXX.cpp:1
./llvm/tools/clang/lib/Parse/ParsePragma.cpp:1
./llvm/tools/clang/lib/Parse/ParseStmt.cpp:1
./llvm/tools/clang/lib/Sema/JumpDiagnostics.cpp:1
./llvm/tools/clang/lib/Sema/Sema.cpp:1
./llvm/tools/clang/lib/Sema/SemaStmt.cpp:1
./llvm/tools/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp:1
./llvm/tools/clang/lib/Serialization/ASTReader.cpp:1
./llvm/tools/clang/lib/Serialization/ASTWriter.cpp:1
./llvm/tools/clang/test/lit.cfg:1
./llvm/tools/clang/test/Misc/warning-flags.c:1
./llvm/tools/clang/test/Parser/recursion-limits.cpp:1
./llvm/tools/clang/test/PCH/cxx11-exception-spec.cpp:1
./llvm/tools/clang/test/SemaTemplate/dependent-names.cpp:1
./llvm/tools/clang/tools/Makefile:1
./llvm/tools/clang/include/clang/AST/ASTContext.h:2
./llvm/tools/clang/include/clang/Frontend/CodeGenOptions.h:2
./llvm/tools/clang/lib/AST/ExprConstant.cpp:2
./llvm/tools/clang/lib/AST/Expr.cpp:2
./llvm/tools/clang/lib/AST/TypePrinter.cpp:2
./llvm/tools/clang/lib/CodeGen/CGDecl.cpp:2
./llvm/tools/clang/lib/CodeGen/CGExprAgg.cpp:2
./llvm/tools/clang/lib/CodeGen/CodeGenFunction.h:2
./llvm/tools/clang/lib/Parse/Parser.cpp:2
./llvm/tools/clang/lib/Sema/SemaDecl.cpp:2
./llvm/tools/clang/lib/Sema/SemaExpr.cpp:2
./llvm/tools/clang/lib/Sema/SemaType.cpp:2
./llvm/tools/clang/test/CMakeLists.txt:2
./llvm/tools/clang/test/CXX/expr/expr.prim/expr.prim.general/p3-0x.cpp:2
./llvm/tools/clang/test/CXX/special/class.copy/p8-cxx11.cpp:2
./llvm/tools/clang/test/SemaTemplate/instantiate-exception-spec-cxx11.cpp:2
./llvm/tools/clang/include/clang/AST/Type.h:3
./llvm/tools/clang/lib/CodeGen/CGValue.h:3
./llvm/tools/clang/include/clang/Parse/Parser.h:4
./llvm/tools/clang/lib/CodeGen/CGExpr.cpp:4
./llvm/tools/clang/lib/Parse/ParseExpr.cpp:4
./llvm/tools/clang/include/clang/Sema/Sema.h:5
./llvm/tools/clang/docs/ReleaseNotes.html:6
./llvm/tools/clang/lib/Sema/SemaDeclCXX.cpp:9
Total: 109

Same as issue #42 on upc2c.

spec1.3/issue64 generates warnings as barrier IDs are not of integer type.

UPC spec 1.3 states that barrier "expression shall have a type such that its value may be assigned to an object of type int". This means that implicit conversion on barrier ID is ok and should not produce a warning.

GUPC driver places "-lm" on the list of library to link with. Should clang-upc do the same?

Recently an issue with atomic test suite came up where 'pow' function was used in some of the tests. It is provided by the math library, but clang-upc does not include one.

An option available in GUPC that is missing from clang-upc is -f[no-]upc-pre-include. The upc2c translator can use this option to exclude runtime library header files from being automatically included. This might be useful for upc2c translator as we have two empty files sitting in UPCR's upcr_preinclude directory (clang-upc.h and clang-upc-lib.h).

I rebuilt PPC version and noticed the following failure. Here is the simplified version of the test:

include <stdio.h>
#include <upc.h>
#include <gula.h>

shared [5] int a[5*THREADS];
int
main()
{
    shared [5] int *p = &a[3];
    shared [5] int *pr;

    pr = upc_resetphase(p); /* should reset phase */

    if (upc_phaseof(p) != 3 || upc_phaseof(pr) != 0)
        GULA_FAIL("failed in upc_phaseof() check - 2");

    upc_barrier;

    if (!MYTHREAD)
        printf ("Passed.\n");
}

When upc_resetphase() is called, register R4 is set to the UPC pointer value, or the value is being placed on the stack:

12          pr = upc_resetphase(p); /* should reset phase */
(gdb) x/10i $pc
=> 0x10001c18 <main+264>:       std     r3,256(r31)
   0x10001c1c <main+268>:       std     r3,56(r1)
   0x10001c20 <main+272>:       ld      r4,256(r31)
   0x10001c24 <main+276>:       addi    r3,r31,264
   0x10001c28 <main+280>:       bl      0x100021ac <.upc_resetphase>

but upc_resetphase() expects pointer in R3:

=> 0x100021ac <.upc_resetphase>:        std     r3,-16(r1)
   0x100021b0 <.upc_resetphase+4>:      ld      r3,-16(r1)
   0x100021b4 <.upc_resetphase+8>:      std     r3,-24(r1)
   0x100021b8 <.upc_resetphase+12>:     ld      r3,-24(r1)
   0x100021bc <.upc_resetphase+16>:     lis     r4,-16
   0x100021c0 <.upc_resetphase+20>:     and     r3,r3,r4
   0x100021c4 <.upc_resetphase+24>:     std     r3,-24(r1)
   0x100021c8 <.upc_resetphase+28>:     ld      r3,-24(r1)
   0x100021cc <.upc_resetphase+32>:     blr

I recall that in GUPC we had to change PPC ABI for something like this.

This issue is a report of the known failure of clang-upc to diagnose the two illegal typedefs in bug3057.upc of the Berkeley UPC testsuite:

  // These are illegal in dynamic threads environment:
  typedef shared int (*pc)[THREADS][ 13  ][THREADS];
  typedef shared int (*pd)[THREADS][ii+jj][THREADS];

I am testing a possible fix now to ensure it does not cause any regressions.

Extracted from issue #36:

Steven Watanabe wrote:

On 03/06/2014 06:57 PM, Paul H. Hargrove wrote:

Hmm... clang-upc doesn't seem to be working to well on PP64 (big-endian) either:

This is almost certainly a mismatch between
the library and clang CodeGen representations
of pointers-to-shared.

$ clangupc upc-runtime/upc-examples/cpi/mcpi.upc
$ ./a.out -n 4
PI estimated to 0.0000000 from 1000000 trials on 4 threads.

Paul responded:

Gary had indicated in email previously that he was unsure the vaddr=first/last logic was right for big-endian. So, that would be a good place to look if somebody wants to pursue this.

I've tried to build on four different x86-32 (aka IA32) platforms: one each of Linux, Solaris-11, FreeBSD-9 and NetBSD-6. All four failed in the compilation (using the freshly built clang) of runtime/libupc/smp/upc_alloc.upc.c

Of the four, Solaris produced the most usable backtrace, below.
The Linux system has a nearly identical backtrace, but is missing function info for the '(anonymous namespace)' frames
The *BSD systems had no stack trace.

[ 90%] Building C object tools/clang/runtime/libupc/CMakeFiles/upc.dir/smp/upc_alloc.upc.o
0  clang-3.4 0x0a5ce6d6 llvm::sys::PrintStackTrace(__FILE*) + 50
1  clang-3.4 0x0a5ce92a PrintStackTraceSignalHandler(void*) + 35
2  clang-3.4 0x0a5ce329 SignalHandler(int) + 299
3  libc.so.1 0xfecb48e5 __sighndlr + 21
4  libc.so.1 0xfeca7ecb call_user_handler + 687
5  clang-3.4 0x09bb547d llvm::SDNode::getValueType(unsigned int) const + 9
6  clang-3.4 0x09bb56d1 llvm::SDValue::getValueType() const + 37
7  clang-3.4 0x09e2a53c llvm::TargetLowering::LowerCallTo(llvm::TargetLowering::CallLoweringInfo&) const + 2106
8  clang-3.4 0x09e22b5d llvm::SelectionDAGBuilder::LowerCallTo(llvm::ImmutableCallSite, llvm::SDValue, bool, llvm::MachineBasicBlock*) + 1835
9  clang-3.4 0x09e25453 llvm::SelectionDAGBuilder::visitCall(llvm::CallInst const&) + 2007
10 clang-3.4 0x09e03c83 llvm::SelectionDAGBuilder::visit(unsigned int, llvm::User const&) + 1163
11 clang-3.4 0x09e03798 llvm::SelectionDAGBuilder::visit(llvm::Instruction const&) + 128
12 clang-3.4 0x09e3f69f llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator<llvm::Instruction const>, llvm::ilist_iterator<llvm::Instruction const>, bool&) + 55
13 clang-3.4 0x09e40f9f llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 1983
14 clang-3.4 0x09e3eb5f llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 641
15 clang-3.4 0x09fcc099 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 87
16 clang-3.4 0x0a4b211a llvm::FPPassManager::runOnFunction(llvm::Function&) + 306
17 clang-3.4 0x0a4b22c1 llvm::FPPassManager::runOnModule(llvm::Module&) + 97
18 clang-3.4 0x0a4b25d2 (anonymous namespace)::MPPassManager::runOnModule(llvm::Module&) + 498
19 clang-3.4 0x0a4b2aa6 llvm::legacy::PassManagerImpl::run(llvm::Module&) + 234
20 clang-3.4 0x0a4b2c9b llvm::legacy::PassManager::run(llvm::Module&) + 39
21 clang-3.4 0x0a603a04 (anonymous namespace)::EmitAssemblyHelper::EmitAssembly(clang::BackendAction, llvm::raw_ostream*) + 870
22 clang-3.4 0x0a603aa4 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::Module*, clang::BackendAction, llvm::raw_ostream*) + 77
23 clang-3.4 0x0a5ffc3b clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 659
24 clang-3.4 0x0a96fb4d clang::ParseAST(clang::Sema&, bool, bool) + 687
25 clang-3.4 0x0a882ac4 clang::ASTFrontendAction::ExecuteAction() + 306
26 clang-3.4 0x0a5fedb8 clang::CodeGenAction::ExecuteAction() + 1090
27 clang-3.4 0x0a882641 clang::FrontendAction::Execute() + 183
28 clang-3.4 0x0a85c2f3 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 559
29 clang-3.4 0x0a5d41b7 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 932
30 clang-3.4 0x09b6f84e cc1_main(char const**, char const**, char const*, void*) + 638
31 clang-3.4 0x09b6ad03 main + 761
32 clang-3.4 0x09b69723 _start + 131
Stack dump:
0.      Program arguments: /export/home/phargrov/upcnightly-64/llvm-upc/bld/bin/clang-3.4 -cc1 -triple i386-pc-solaris2.11 -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name upc_alloc.upc -mrelocation-model pic -pic-level 2 -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -target-cpu pentium4 -coverage-file /export/home/phargrov/upcnightly-64/llvm-upc/bld/tools/clang/runtime/libupc/CMakeFiles/upc.dir/smp/upc_alloc.upc.o -resource-dir /export/home/phargrov/upcnightly-64/llvm-upc/bld/bin/../lib/clang/3.4 -D CLANG_ENABLE_ARCMT -D CLANG_ENABLE_REWRITER -D CLANG_ENABLE_STATIC_ANALYZER -D GUPCR_PTS_PACKED_REP=1 -D GUPCR_PTS_PHASE_SIZE=20 -D GUPCR_PTS_THREAD_SIZE=10 -D GUPCR_PTS_VADDR_FIRST=1 -D GUPCR_PTS_VADDR_SIZE=34 -D IN_TARGET_LIBS=1 -D NDEBUG -D _GNU_SOURCE -D __STDC_CONSTANT_MACROS -D __STDC_FORMAT_MACROS -D __STDC_LIMIT_MACROS -I /export/home/phargrov/upcnightly-64/llvm-upc/bld/tools/clang/runtime/libupc -I /export/home/phargrov/upcnightly-64/llvm-upc/src/tools/clang/runtime/libupc -I /export/home/phargrov/upcnightly-64/llvm-upc/src/tools/clang/include -I /export/home/phargrov/upcnightly-64/llvm-upc/bld/tools/clang/include -I /export/home/phargrov/upcnightly-64/llvm-upc/bld/include -I /export/home/phargrov/upcnightly-64/llvm-upc/src/include -I /export/home/phargrov/upcnightly-64/llvm-upc/src/tools/clang/runtime/libupc/include -I /export/home/phargrov/upcnightly-64/llvm-upc/src/tools/clang/runtime/libupc/collectives -Wall -W -Wno-unused-parameter -Wwrite-strings -Wno-missing-field-initializers -Wno-long-long -Wno-gnu -Wno-language-extension-token -pedantic -fconst-strings -fdebug-compilation-dir /export/home/phargrov/upcnightly-64/llvm-upc/bld/tools/clang/runtime/libupc -ferror-limit 19 -fmessage-length 0 -mstackrealign -fobjc-runtime=gcc -fupc-packed-bits=20,10,34 -fupc-pts=packed -fupc-pts-vaddr-order=first -fdiagnostics-show-option -vectorize-slp -o CMakeFiles/upc.dir/smp/upc_alloc.upc.o -x upc /export/home/phargrov/upcnightly-64/llvm-upc/src/tools/clang/runtime/libupc/smp/upc_alloc.upc
1.      <eof> parser at end of file
2.      Code generation
3.      Running pass 'Function Pass Manager' on module '/export/home/phargrov/upcnightly-64/llvm-upc/src/tools
/clang/runtime/libupc/smp/upc_alloc.upc'.
4.      Running pass 'X86 DAG->DAG Instruction Selection' on function '@__upc_heap_init'
clang-3.4: error: unable to execute command: Segmentation Fault (core dumped)
clang-3.4: error: clang frontend command failed due to signal (use -v to see invocation)
clang version 3.4  (UPC 20140226)
Target: i386-pc-solaris2.11
Thread model: posix
clang-3.4: note: diagnostic msg: PLEASE submit a bug report to  and include the crash backtrace, preprocessed source, and associated run script.
0  clang-3.4 0x0a5ce6d6 llvm::sys::PrintStackTrace(__FILE*) + 50
1  clang-3.4 0x0a5ce92a PrintStackTraceSignalHandler(void*) + 35
2  clang-3.4 0x0a5ce329 SignalHandler(int) + 299
3  libc.so.1 0xfecb48e5 __sighndlr + 21
4  libc.so.1 0xfeca7ecb call_user_handler + 687
5  libc.so.1 0xfec2cda0 strlen + 48
6  clang-3.4 0x0a7e66c8 clang::driver::Driver::GetTemporaryPath(llvm::StringRef, char const*) const + 58
7  clang-3.4 0x0a7e4bb1 clang::driver::Driver::GetNamedOutputPath(clang::driver::Compilation&, clang::driver::JobAction const&, char const*, char const*, bool, bool) const + 1075
8  clang-3.4 0x0a7e4324 clang::driver::Driver::BuildJobsForAction(clang::driver::Compilation&, clang::driver::Action const*, clang::driver::ToolChain const*, char const*, bool, bool, char const*, clang::driver::InputInfo&) const + 1218
9  clang-3.4 0x0a7e37a3 clang::driver::Driver::BuildJobs(clang::driver::Compilation&) const + 805
10 clang-3.4 0x0a7def9e clang::driver::Driver::generateCompilationDiagnostics(clang::driver::Compilation&, clang::driver::Command const*) + 1564
11 clang-3.4 0x09b6b858 main + 3662
12 clang-3.4 0x09b69723 _start + 131
Stack dump:
0.      Program arguments: /export/home/phargrov/upcnightly-64/llvm-upc/bld/bin/clang -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_REWRITER -DCLANG_ENABLE_STATIC_ANALYZER -DGUPCR_PTS_PACKED_REP=1 -DGUPCR_PTS_PHASE_SIZE=20 -DGUPCR_PTS_THREAD_SIZE=10 -DGUPCR_PTS_VADDR_FIRST=1 -DGUPCR_PTS_VADDR_SIZE=34 -DIN_TARGET_LIBS=1 -DNDEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -fPIC -Wall -W -Wno-unused-parameter -Wwrite-strings -Wno-missing-field-initializers -pedantic -Wno-long-long -I/export/home/phargrov/upcnightly-64/llvm-upc/bld/tools/clang/runtime/libupc -I/export/home/phargrov/upcnightly-64/llvm-upc/src/tools/clang/runtime/libupc -I/export/home/phargrov/upcnightly-64/llvm-upc/src/tools/clang/include -I/export/home/phargrov/upcnightly-64/llvm-upc/bld/tools/clang/include -I/export/home/phargrov/upcnightly-64/llvm-upc/bld/include -I/export/home/phargrov/upcnightly-64/llvm-upc/src/include -I/export/home/phargrov/upcnightly-64/llvm-upc/src/tools/clang/runtime/libupc/include -I/export/home/phargrov/upcnightly-64/llvm-upc/src/tools/clang/runtime/libupc/collectives -Wno-gnu -Wno-language-extension-token -fupc-pts=packed -fupc-packed-bits=20,10,34 -fupc-pts-vaddr-order=first -o CMakeFiles/upc.dir/smp/upc_alloc.upc.o -c /export/home/phargrov/upcnightly-64/llvm-upc/src/tools/clang/runtime/libupc/smp/upc_alloc.upc
1.      Building compilation jobs
2.      Building compilation jobs
3.      Computing output path
make[2]: *** [tools/clang/runtime/libupc/CMakeFiles/upc.dir/smp/upc_alloc.upc.o] Segmentation Fault (core dumped)
make[1]: *** [tools/clang/runtime/libupc/CMakeFiles/upc.dir/all] Error 2
make: *** [all] Error 2  

I've just tried for the first time using the clang built with clang-upc2c as the backend compiler. There are many new "expect pass but got warning" failures in a harness run, and more investigation of those is needed (most are probably due to the tests themselves). HOWEVER, one at least is the result of the translator.

Given

  upc_forall(int i=0; i<N; i++; i)
    if (A[i] != MYTHREAD) errflag=1;

the .trans.c contains the following translation of the upc_forall:

        if (upcrt_forall_control)
            for (int i = 0; i < N; i++)
                if ((upcr_get_pshared(&_bupc_spilld0, upcr_add_pshared1(A, 4U, i), 0U, 4U) , _bupc_spilld0) != (int)upcr_mythread())
                    errflag = 1;
        else {
            upcrt_forall_control = 1;
            for (int i = 0; i < N; i++)
                if ((i) % upcr_threads() == upcr_mythread())
                    if ((upcr_get_pshared(&_bupc_spilld0, upcr_add_pshared1(A, 4U, i), 0U, 4U) , _bupc_spilld0) != (int)upcr_mythread())
                        errflag = 1;
            upcrt_forall_control = 0;
        }

That is entirely valid C code, but notice that the line immediately before the translator-supplied instance of else in that code is the if from the user's code. This results in the backend clang warning:

foo.trans.c:18:9: warning: add explicit braces to avoid dangling else [-Wdangling-else]
        else {
        ^
1 warning generated.

If necessary, I am OK with passing Wno-dangling-else to clang as a backend if that is necessary. However, I wanted to first report the issue here to see if it is reasonable to instead ask/expect/require that clang-upc2c generate output that clang itself is willing to accept as input. Thoughts?

The UPC 1.3 Specification states that a UPC compiler should support an implementation-defined conversion from pointer-to-shared to integer.
http://code.google.com/p/upc-specification/issues/detail?id=11 [^]

Here is the summary.

1. Is arithmetic on (void *) and (shared void *) an error? Some implementations of UPC currently define arithmetic on (shared void *) as erroneous. BUPC thinks it is ... and GCC/UPC has now followed suit, but what does C99 say?

Answer: Yes, this is an error.

2. Is conversion from a pointer?to?shared to an integer allowed? BUPC thinks it is and does something, GCC/UPC issues an error. If it is defined in the language, what is the definition? (Note that on 32?bit targets, a shared pointer might be 64 bits, and 128 bits on a 64?bit target.)

Answer: Conversion from a pointer?to?shared to an integer is allowed but the result is implementation-defined.

Clang UPC should be changed to provide a conversion from a PTS to an integer. We will likely make this have the same effect as upc_addrfield().

On Macos/Darwin, the make fails with

fatal error: error in backend: Global variable 'GCCUPCConfig' has an invalid
section specifier 'upc_pgm_info': mach-o section specifier requires a
segment and section separated by a comma.

This GCCUPCConfig variable is generated by this section of code.

diff --git a/lib/CodeGen/CodeGenModule.cpp b/lib/CodeGen/CodeGenModule.cpp
index 9a55c08..895d80b 100644
--- a/lib/CodeGen/CodeGenModule.cpp
+++ b/lib/CodeGen/CodeGenModule.cpp
[...]
void CodeGenModule::Release() {

• if (getContext().getLangOpts().UPC) {
• llvm::SmallString<64> str;
• str += "$GCCUPCConfig: (";
• str += getModule().getModuleIdentifier();
• str += ") ";
• unsigned Threads = getContext().getLangOpts().UPCThreads;
• if (Threads == 0) {

•  str += "dynamicthreads";
  

• } else {

•  str += "staticthreads=";
  

•  llvm::APInt(32, Threads).toStringUnsigned(str);
  

• }
• str += " process$";
• llvm::GlobalVariable * conf =

•  new llvm::GlobalVariable(getModule(), llvm::ArrayType::get(Int8Ty, str.size
  

•                           true, llvm::GlobalValue::InternalLinkage,
  

•                           llvm::ConstantDataArray::getString(getLLVMContext(
  

•                           "GCCUPCConfig");
  

• conf->setSection("upc_pgm_info");
• AddUsedGlobal(conf);
• }

Note the "setSection" call above.

This small test program indicates the expected section name syntax on a Mach OS based system.

static const char GCCUPCConfig[]

if MACH

attribute ((section("DATA,upc_pgm_info"))) __attribute ((used)) =

else

attribute ((section("upc_pgm_info"))) attribute ((used)) =

endif

"$GCCUPCConfig: (" BASE_FILE ") " "$";

int main(void)
{
return 0;
}

I think that the lack of the ""__DATA,upc_pgm_info" syntax might be the source of the problem, but am unsure how this might be best parametrized within the compiler. Perhaps there is already some mechanism to achieve this OS dependent behavior?

After various fixes to the build environment I was able to install the compiler. However, the program does not link. There are two issues with this:

1. "main" has to be renamed to become "_upc_main" (instead of "upc_main"). Here is the change I made:

--- a/lib/Frontend/InitPreprocessor.cpp
+++ b/lib/Frontend/InitPreprocessor.cpp
@@ -321,7 +321,7 @@ static void InitializeStandardPredefinedMacros(const TargetInfo &TI,
     }
     Builder.append("extern const int MYTHREAD;\n");
     Builder.append("typedef shared struct upc_lock_struct upc_lock_t;\n");
-    Builder.append("extern int main() __asm__(\"upc_main\");\n");
+    Builder.append(Twine("extern int main() __asm__(\"") + TI.getUserLabelPrefix() + "upc_main\");\n");
     Builder.defineMacro("exit", "__upc_exit");

1. void darwin::Link::ConstructJob in Driver/Tools.cpp needs to add the UPC specific object files (upc_crtxxxx) and "-lupc" library on the link line.

I tried following the changes from the linuxtools procedure but that did not work:

• ToolChain.GetFilePath() does not put the path in front the upc_crtxxx object files.
• Library paths are not on the command line (there are no "-L"s). I see in the linuxtools link procedure that all the paths are placed on the command line but I don't see anything similar in the darwin routine.

After I compile a simple program I get the following for the link command:

/usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld" -dynamic -arch x86_64 -macosx_version_min 10.8.0 -o t upc-crtbegin.o -lupc /var/folders/z7/83zx0wdj4cx644rg7p7kgwb80000gn/T/t-4uqNps.o -lSystem upc-crtend.o

After hard codding the link line into something like this:

/usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld -dynamic -arch x86_64 -macosx_version_min 10.8.0 -o t /usr/local/clang-upc/lib/upc-crtbegin.o -L/usr/local/clang-upc/lib -lupc t.o -lSystem /usr/local/clang-upc/lib/upc-crtend.o

I am able to link and later execute the UPC program.

This is the first "child" issue of upc2c issue #74.

When one passes -fupc-pts=struct to clang-upc, the value of UPC_MAX_BLOCK_SIZE is correctly set to 4294967295 (aka 2^32-1 or 0xFFFFFFFF). The problem I am seeing is with the following, based on the test guts_main/blocksize_neg.upc:

    shared [-3] int *p;

This code is accepted by clang-upc!
Use of clang-upc2c renders -3 as as its 32-bit twos-complement equivalent 0xFFFFFFFD. So, I assume that clang-upc has accepted the blocksize of -3 after checking 0xFFFFFFFD <= 0xFFFFFFFF. This is consistent with the behavior with the default packed pts rep:

f.upc:1:9: error: block size 4294967293 exceeds UPC_MAX_BLOCK_SIZE
shared [-3] int *p;
        ^~
1 error generated.

It would appear that some additional logic is needed to protect against negative block size in the pts=struct case, which the pts=packed is detecting for the wrong reason. The additional check would/could also improve the error message for the pts=packed case.

RFE: while somebody is looking at this, I think it would be helpful to the end-user to include the value of UPC_MAX_BLOCK_SIZE in the error message for block-size-too-large.

The following test produces an error:

TEST(RecursiveASTVisitor, VisitsCompoundLiteralType) {                          
  TypeLocVisitor Visitor;                                                       
  Visitor.ExpectMatch("struct S", 1, 26);                                       
  EXPECT_TRUE(Visitor.runOver(                                                  
      "int f() { return (struct S { int a; }){.a = 0}.a; }",                    
      TypeLocVisitor::Lang_C));                                                 
}

I think this is the reported error:

error: invalid argument '-std=c99' not allowed with 'C++/ObjC++'

While compiling libupc the following warnings come up.

Many warnings of this kind:

/eng/upc/dev/nenad/clang-upc/src/llvm/tools/clang/runtime/libupc/smp/upc_vm.c:78:3: warning: extension used
[-Wlanguage-extension-token]
GUPCR_FENCE ();
^
/eng/upc/dev/nenad/clang-upc/src/llvm/tools/clang/runtime/libupc/smp/upc_sync.h:35:25: note: expanded from macro 'GUPCR_FENCE'

define GUPCR_FENCE() { GUPCR_READ_FENCE (); GUPCR_WRITE_FENCE (); }

                    ^

/eng/upc/dev/nenad/clang-upc/src/llvm/tools/clang/runtime/libupc/smp/upc_sync.h:45:28: note: expanded from macro
'GUPCR_READ_FENCE'

define GUPCR_READ_FENCE() asm volatile ("":::"memory")

An option "-Wno-language-extension-token" suppressed the above.

/eng/upc/dev/nenad/clang-upc/src/llvm/tools/clang/runtime/libupc/smp/upc_pupc.h:34:78: warning: token pasting of ',' and VA_ARGS is a GNU extension [-Wgnu]

define p_atomic(evttag, ...) pupc_event_atomicg (evttag, filename, linenum, ##VA_ARGS)

An option "-Wno-gnu" suppressed the warning.

/eng/upc/dev/nenad/clang-upc/src/llvm/tools/clang/runtime/libupc/collectives/upc_coll_init.upc:35:7: warning: implicit
declaration of function '__upc_exit' is invalid in C99 [-Wimplicit-function-declaration]
exit (1);
^
:167:14: note: expanded from here

define exit __upc_exit

In the above, it seems that upc_coll_init.upc is missing inclusion of <stdlib.h>. Things are getting strange here as we do not provide the prototype for "__upc_exit()", but instead, "exit()" prototype in stdlib.h is being converted into __upc_exit() prototype.

After converting "exit()" into "upc_global_exit()" the warning disappeared.

[ 90%] Building C object tools/clang/runtime/libupc/CMakeFiles/upc.dir/smp/upc_alloc.upc.o
/eng/upc/dev/nenad/clang-upc/src/llvm/tools/clang/runtime/libupc/smp/upc_alloc.upc:241:45: warning: implicit
declaration of function '__upc_vm_get_cur_page_alloc' is invalid in C99 [-Wimplicit-function-declaration]

const upc_page_num_t cur_page_alloc = __upc_vm_get_cur_page_alloc ();

The above warning comes from the fact that we don't include "upc-lib.h" when compiling non-optimized. Prototypes are defined in the upc-lib.h.

/eng/upc/dev/nenad/clang-upc/src/llvm/tools/clang/runtime/libupc/smp/upc_vm.c:344:20: warning: arithmetic on a
pointer to void is a GNU extension [-Wpointer-arith]

addr = page_base + p_offset;

addr and page_vase are declared void. We probably need to add some cast.

Reverted to cmake 2.8.6, ran the usual cmake and make steps and ran into this:

[ 5%] Building C object lib/Support/CMakeFiles/LLVMSupport.dir/regerror.c.o
cc1: error: unrecognized command line option "-Wcovered-switch-default"
make[2]: *** [lib/Support/CMakeFiles/LLVMSupport.dir/regcomp.c.o] Error 1
make[2]: *** Waiting for unfinished jobs....
cc1: error: unrecognized command line option "-Wcovered-switch-default"
make[2]: *** [lib/Support/CMakeFiles/LLVMSupport.dir/regerror.c.o] Error 1

This failure is reminiscent of a problem recently reported to clang-dev:
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-October/024748.html
which resulted in this reply:
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-October/024753.html
which states:

this is a guess, but it's possible you're setting the C++
compiler to clang++, but not setting the C compiler to clang.

This appears to be the case.

-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works

And on the system that I'm working on, the various c and c++ paths look like this.

$ for p in gcc g++ llvm-gcc-4.2 llvm-g++-4.2 /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2 /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 clang clang++ cc c++; do ls -l which $p; done
lrwxr-xr-x 1 root wheel 12 Oct 16 13:44 /usr/bin/gcc -> llvm-gcc-4.2
lrwxr-xr-x 1 root wheel 12 Oct 16 13:44 /usr/bin/g++ -> llvm-g++-4.2
lrwxr-xr-x 1 root wheel 32 Oct 16 13:44 /usr/bin/llvm-gcc-4.2 -> ../llvm-gcc-4.2/bin/llvm-gcc-4.2
lrwxr-xr-x 1 root wheel 32 Oct 16 13:44 /usr/bin/llvm-g++-4.2 -> ../llvm-gcc-4.2/bin/llvm-g++-4.2
-rwxr-xr-x 1 root wheel 117168 Oct 16 13:44 /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2
-rwxr-xr-x 1 root wheel 117168 Oct 16 13:44 /usr/llvm-gcc-4.2/bin/llvm-g++-4.2
-rwxr-xr-x 1 root wheel 21622640 Oct 16 13:44 /usr/bin/clang
lrwxr-xr-x 1 root wheel 5 Oct 16 13:44 /usr/bin/clang++ -> clang
lrwxr-xr-x 1 root wheel 5 Oct 16 13:44 /usr/bin/cc -> clang
lrwxr-xr-x 1 root wheel 7 Oct 16 13:44 /usr/bin/c++ -> clang++

We see that the "C" compiler choice resolves to /usr/bin/gcc (/usr/llvm-gcc-4.2/bin/llvm-gcc-4.2) and the "CXX" compiler resolves to /usr/bin/c++ (clang++).

The question is: what cmake incantation do I need to work around this issue? For example, I'd like to set CC to 'clang'.
Add

Subtasks
Add

Related issues

Issue #
Delay: days Cancel
History
#1

Updated by Gary Funck 3 months ago
Comment

Gary Funck wrote:

The question is: what cmake incantation do I need to work around this issue?
For example, I'd like to set CC to 'clang'.

I think that I found the answer here:
http://www.cmake.org/Wiki/CMake_Useful_Variables

I can set the CC and CXX environment variables when running cmake. Will try that.

It is more consistent with the rest of the clang/llvm tools.

Also, crate a upc command. Both upc and clang-upc will be symbolic links to clang.

When compiling already preprocessed UPC code I get the errors tat suggest that the code is treated as a regular C code. For example:

# clang-upc -g  -c t.upci
/eng/upc/dev/nenad/clang-upc/src/upcr-clang/upcr.h:241:
/eng/upc/dev/nenad/clang-upc/src/upcr-clang/upcr_io.h:7:11: error: unknown type name 'shared'
  typedef shared void *bupc_sharedptr_t;
          ^
/eng/upc/dev/nenad/clang-upc/src/upcr-clang/upcr_io.h:7:18: error: expected identifier or '('
  typedef shared void *bupc_sharedptr_t;

Also, compiling files with ".i" extension gets this warning:

clang-3.4: warning: treating 'cpp-output' input as 'upc-cpp-output' when in UPC mode, this behavior is deprecated

Also note that Clang does not support "-fpreprocessed" switch that GCC has.

Three of the intrepid tests fail with a segmentation fault.

./test18 -n 8
test: test18 opt: -O0 threads: dynamic elapsed: 0.102 user: 0.000 sys: 0.000
thread 0 terminated with signal: 'Segmentation fault'
failed: status = 143
--
./test25 -n 8
test: test25 opt: -O0 threads: dynamic elapsed: 0.102 user: 0.000 sys: 0.001
thread 1 terminated with signal: 'Segmentation fault'
failed: status = 143
--
./test29 -n 8
test: test29 opt: -O0 threads: dynamic elapsed: 0.103 user: 0.001 sys: 0.002
thread 0 terminated with signal: 'Segmentation fault'
failed: status = 143

These tests fail on an x86_64 system running FC18. We have seen this failure with GUPC on a recent version of SUSE. The fix we made was to no longer locate the initialization code into its own .upc_init linker section. This change was made in the following GUPC commit.

Author: nenadv
Date: Sat Oct 27 19:37:34 2012
New Revision: 192880

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192880 [^]
Log:
        Place shared initialization code into the .text
        section instead of a separate .upc_init section.
        * gcc/defaults.h (UPC_INIT_SECTION_NAME): Delete.
        (UPC_INIT_BEGIN_NAME): Delete.
        (UPC_INIT_END_NAME): Delete.
        * gcc/doc/tm.texi.in: Ditto.
        * gcc/doc/tm.texi: Ditto.
        * gcc/upc/upc-act.c (upc_build_init_func): Remove settings
        of the section for shared initialization code.
        * libgupc/config/default/upc-crt-config.h (UPC_INIT_SECTION_BEGIN):
        Delete.
        (UPC_INIT_SECTION_END): Delete.
        * libgupc/config/darwin/upc-crt-config.h: Ditto.
        * libgupc/upc-crtstuff.c: Remove declarations for .upc_init
        section start/end.

The UPC 1.3 specification clarifies the behavior of relational operators applied to a PTS where the target type of the PTS is an incomplete type [including (shared void *)].
http://code.google.com/p/upc-specification/issues/detail?id=104 [^]

If the relational operation is defined, then its effect is equivalent to testing the result of PTS subtraction of the two operands.

Clang UPC should be changed to conform to the definition stated above.

When compiling programs with Clang UPC 3.2, we're seeing the following spurious warning:

/usr/local/clang-upc/bin/clangupc -fupc-pts-packed -g  -I. -Wno-implicit-functi
on-declaration -Wno-deprecated -fno-caret-diagnostics -Wno-logical-op-parenthes
es -Wno-unused-comparison -Wno-unused-value -Wno-dangling-else -g   -lm -fupc-t
hreads-4 -o issue64_st04 issue64.upc
clang-3: warning: argument unused during compilation: '-fupc-pts-packed'

The following test case failed with the following internal error.

clangupc -fupc-pts-packed -g  -I. -Wno-implicit-functi
on-declaration -Wno-deprecated -fno-caret-diagnostics -Wno-logical-op-parenthes
es -Wno-unused-comparison -Wno-unused-value -Wno-dangling-else -g   -DBUPC_TEST
_HARNESS -fupc-threads-4 -c issue64b.upc

clang-3.2: /eng/upc/dev/gary/clang/src/llvm/lib/VMCore/Constants.cpp:1393: stat
ic llvm::Constant* llvm::ConstantExpr::getCast(unsigned int, llvm::Constant*, l
lvm::Type*): Assertion `CastInst::castIsValid(opc, C, Ty) && "Invalid constante
xpr cast!"' failed.
0  clang-3.2       0x00000000016975a6
1  clang-3.2       0x000000000169727c
2  libpthread.so.0 0x0000003991a0f00
3  libc.so.6       0x0000003991635ba5 gsignal + 53
4  libc.so.6       0x0000003991637358 abort + 328
5  libc.so.6       0x000000399162e972
6  libc.so.6       0x000000399162ea22
7  clang-3.2       0x00000000014d9ba1 llvm::ConstantExpr::getCast(unsigned int,
 llvm::Constant*, llvm::Type*) + 177
8  clang-3.2       0x0000000000ca22f2
9  clang-3.2       0x0000000000ca4940
10 clang-3.2       0x000000000119a814
11 clang-3.2       0x00000000017eeb9b
12 clang-3.2       0x00000000017f9d93
13 clang-3.2       0x00000000017f90d1
14 clang-3.2       0x00000000017e8be5
15 clang-3.2       0x00000000017f7dc6 clang::CodeGen::CodeGenFunction::EmitScal
arExpr(clang::Expr const*, bool) + 156
[...]

We tried running some tests on an Apple system, which didn't have cmake installed.
We installed it from the latest source release, downloaded from here:
http://www.cmake.org/files/v2.8/cmake-2.8.10.2.tar.gz
after ../src/bootstrap && make > make.log && sudo make install > install.log, we tried build Clang UPC.

The build failed as follows.

-- Targeting X86
-- Clang version: 3.1
-- Found Subversion: /usr/bin/svn (found version "1.6.18")
CMake Error at tools/clang/runtime/libupc/CMakeLists.txt:211 (add_library):
add_library cannot create target "upc" because another target with the same
name already exists. The existing target is a static library created in
source directory
"/eng/upc/dev/gary/clang/src/llvm/tools/clang/runtime/libupc". See
documentation for policy CMP0002 for more details.

CMake Error at tools/clang/runtime/libupc/CMakeLists.txt:211 (add_library):
add_library cannot create target "upc-s" because another target with the
same name already exists. The existing target is a static library created
in source directory
"/eng/upc/dev/gary/clang/src/llvm/tools/clang/runtime/libupc". See
documentation for policy CMP0002 for more details.

We replicated this build failure on a generic x86_64 host running FC15, where we have been build Clang UPC successfully with the installed 2.8.4 version of cmake.
Add

Subtasks
Add

Related issues

Issue #
Delay: days Cancel
History
#1

Updated by John Wiegley 3 months ago

* Assignee set to Steven Watanabe

#2

Updated by Gary Funck about 1 month ago
Comment

We're still seeing this failure. It would be good to find a fix because at present, the Github version of clang-upc won't build correctly on newer Linux systems. Recently, we upgraded to FC17. Its cmake version is: 2.8.9. We're seeing the same error messages as in the original bug report, above.
#3

Updated by John Wiegley about 1 month ago

* Priority changed from Normal to High

Comment

Steven, can you take a look at this one?

Test failure, using latest commit:

commit a4a81f7694a5b69887efdcef8844cb1c9825dc5b
Author: Nenad Vukicevic <[email protected]>
Date:   Wed Jan 29 16:16:37 2014 -0800

src/llvm/tools/clang/test/CodeGenUPC/upc-debug.upc:5:11
: error: expected string not found in input
// CHECK: i8* getelementptr inbounds ([80 x i8]* @.str, i32 0, i32 0)
          ^
<stdin>:14:17: note: scanning from here
define i8* @file() #0 {
                ^
<stdin>:16:6: note: possible intended match here
 ret i8* getelementptr inbounds ([75 x i8]* @.str, i32 0, i32 0)
     ^

On MacOS, I have tried building Clang UPC twice with -j12 (on an 8 HT/4 core system) and it fails the same way.

Scanning dependencies of target upc-link-script
Scanning dependencies of target upc-headers
Scanning dependencies of target upc-header
Scanning dependencies of target profile_rt-shared
Scanning dependencies of target LLVMHello
[ 0%] [ 0%] [ 0%] [ 0%] [ 0%] [ 0%] [ 0%] [ 0%] [ 0%] [ 0%] Copying clan
g's upc_tick.h...
.
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@[ 0%] Generating ../.
./../../lib/clang/3.1/include/upc-lib.h
Copying clang's upc_relaxed.h...
Copying clang's upc_collective.h...
Generating ../../../../lib/upc.ld
Copying clang's upc.h...
Building C object runtime/libprofile/CMakeFiles/profile_rt-shared.dir/BasicBlockTr
acing.c.o
ld: unknown option: --verbose
Building C object runtime/libprofile/CMakeFiles/profile_rt-shared.dir/BasicBlockTr
acing.c.o
ld: unknown option: --verbose
Building C object runtime/libprofile/CMakeFiles/profile_rt-shared.dir/CommonProfil
ing.c.o
Building CXX object lib/Transforms/Hello/CMakeFiles/LLVMHello.dir/Hello.cpp.o
Building C object runtime/libprofile/CMakeFiles/profile_rt-shared.dir/GCDAProfilin
g.c.o
Not a GNU ld script? at /eng/upc/dev/gary/clang/src/llvm/tools/clang/runtime/libup
c/gen-upc-ld-script.pl line 44, <> line 1.
make[2]: *** [lib/upc.ld] Error 255
make[1]: *** [tools/clang/runtime/libupc/CMakeFiles/upc-link-script.dir/all] Error
2
make[1]: *** Waiting for unfinished jobs....
[ 0%] [ 0%] [ 1%] [ 1%] Building C object runtime/libprofile/CMakeFiles/profil
e_rt-shared.dir/PathProfiling.c.o
Built target upc-headers

However, if I run "make -j1", the compiler appears to build properly ... though it does run into problems compiling the libupc runtime (some files are written in .upc) due to pgm_info bug.

The intrepid test, test31 fails to link.

/usr/local/clang-upc/bin/clangupc  -O0 -fupc-pts=packed -fupc-pts-vaddr-order=f
irst  -Wall -Wextra -Wwrite-strings -Werror  -g test31.upc -o test31
/usr/local/clang-upc/bin/../lib/libupc.a(upc_tick.c.o): In function `upc_ticks_
now':
/eng/upc/dev/gary/clang/src/llvm/tools/clang/runtime/libupc/smp/upc_tick.c:31:
undefined reference to `clock_gettime'
clang-3: error: linker command failed with exit code 1 (use -v to see invocatio
n)

Per "man clock_gettime":

NAME
       clock_getres, clock_gettime, clock_settime - clock and time functions

SYNOPSIS
       #include 

       int clock_getres(clockid_t clk_id, struct timespec *res);

       int clock_gettime(clockid_t clk_id, struct timespec *tp);

       int clock_settime(clockid_t clk_id, const struct timespec *tp);

       Link with -lrt.

When GUPC is configured, it will add -lrt to the linker line on systems linking with librt is required (most modern Linux systems).

The addition of -lrt is handled by this logic in configure.ac in GUPC's libgupc configure logic.

# At least for glibc, clock_gettime is in librt.  But don't pull that
# in if it still doesn't give us the function we want.
if test $ac_cv_func_clock_gettime = no; then
  AC_CHECK_LIB(rt, clock_gettime,[ac_cv_func_clock_gettime="yes"])
  if test $ac_cv_func_clock_gettime = yes; then
    LIBS="-lrt $LIBS"
    AC_DEFINE(HAVE_CLOCK_GETTIME, 1,
              [Define to 1 if you have the `clock_gettime' function.])
  fi
fi

While testing atomics with PPC struct representation, tests failed to link with the following error:

upc_atomic.upc:(.text+0x638c): undefined reference to `__atomic_load'
upc_atomic.upc:(.text+0x63cc): undefined reference to `__atomic_store'
upc_atomic.upc:(.text+0x6408): undefined reference to `__atomic_exchange'
upc_atomic.upc:(.text+0x64dc): undefined reference to `__atomic_compare_exchange'

I think we have to install 'compiler-rt' LLVM project that provides libgcc functionality.

Building on my MacBook Pro fails as shown below (make VERBOSE=1).

The /usr/bin/cc and c++ on this system are llvm-gcc. However, the failure occurs when compiling with the just-built clang. It looks to me like a configure probe for the addr2line utility is either missing or is ignored, because which addr2line tells me the command is not present.

[ 91%] Building C object tools/clang/runtime/libupc/CMakeFiles/upc.dir/smp/upc_backtrace.c.o
cd /Users/paul/upc2c/bld/tools/clang/runtime/libupc && /Users/paul/upc2c/bld/bin/clang  -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_REWRITER -DCLANG_ENABLE_STATIC_ANALYZER -DGUPCR_PTS_PACKED_REP=1 -DGUPCR_PTS_PHASE_SIZE=20 -DGUPCR_PTS_THREAD_SIZE=10 -DGUPCR_PTS_VADDR_FIRST=1 -DGUPCR_PTS_VADDR_SIZE=34 -DIN_TARGET_LIBS=1 -DNDEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -fPIC -Wall -W -Wno-unused-parameter -Wwrite-strings -Wno-missing-field-initializers -pedantic -Wno-long-long -I/Users/paul/upc2c/bld/tools/clang/runtime/libupc -I/Users/paul/upc2c/src/llvm/tools/clang/runtime/libupc -I/Users/paul/upc2c/src/llvm/tools/clang/include -I/Users/paul/upc2c/bld/tools/clang/include -I/Users/paul/upc2c/bld/include -I/Users/paul/upc2c/src/llvm/include -I/Users/paul/upc2c/src/llvm/tools/clang/runtime/libupc/include -I/Users/paul/upc2c/src/llvm/tools/clang/runtime/libupc/collectives    -Wno-gnu -Wno-language-extension-token -fupc-pts=packed -fupc-packed-bits=20,10,34 -fupc-pts-vaddr-order=first -o CMakeFiles/upc.dir/smp/upc_backtrace.c.o   -c /Users/paul/upc2c/src/llvm/tools/clang/runtime/libupc/smp/upc_backtrace.c
/Users/paul/upc2c/src/llvm/tools/clang/runtime/libupc/smp/upc_backtrace.c:116:27: error: use of undeclared
      identifier 'GUPCR_BACKTRACE_ADDR2LINE'
          int cmd_size = strlen (GUPCR_BACKTRACE_ADDR2LINE) +
                                 ^
/Users/paul/upc2c/src/llvm/tools/clang/runtime/libupc/smp/upc_backtrace.c:123:44: error: use of undeclared
      identifier 'GUPCR_BACKTRACE_ADDR2LINE'
          sz = snprintf (cmd, cmd_size, CMD_TMPL, GUPCR_BACKTRACE_ADDR2LINE,
                                                  ^
/usr/include/secure/_stdio.h:58:62: note: expanded from macro 'snprintf'
  __builtin___snprintf_chk (str, len, 0, __darwin_obsz(str), __VA_ARGS__)
                                                             ^
2 errors generated.
make[2]: *** [tools/clang/runtime/libupc/CMakeFiles/upc.dir/smp/upc_backtrace.c.o] Error 1
make[1]: *** [tools/clang/runtime/libupc/CMakeFiles/upc.dir/all] Error 2
make: *** [all] Error 2

The following code produces warnings:

shared int *s;
int
main ()
{
  strict shared int *p = upc_alloc (5);
  strict shared int *a = s;
}

$ ../../bld/bin/clangupc -c t.upc
t.upc:9:22: warning: initializing 'shared strict int *' with an expression of type 'shared void *' discards qualifiers
      [-Wincompatible-pointer-types-discards-qualifiers]
  strict shared int *p = upc_alloc (5);
                     ^   ~~~~~~~~~~~~~
t.upc:10:22: warning: initializing 'shared strict int *' with an expression of type 'shared int *' discards qualifiers
      [-Wincompatible-pointer-types-discards-qualifiers]
  strict shared int *a = s;

The same warning is being produced if I place "#pragama upc strict" at the top of the program or I include upc_strict.h.

I have built and successfully tested clang-upc2c on recent versions of FreeBSD, NetBSD and OpeBSD. I then tried clang-upc as well and was unable to get a working system.

My initial attempts to get clang-upc running on the BSD systems was not passing the necessary options to the linker to get the UPC runtime. I have addressed the link issues for all three systems at https://github.com/PHHargrove/clang-upc/tree/bsd-support

In addition to the changes in my bsd-support branch, one must pass -DLIBUPC_ENABLE_BACKTRACE=FALSE to cmake on these systems).

Having gotten past the linker issues on all three systems, I now find that on all three systems the UPC runtime aborts at startup for even a simple "Hello, World!" UPC program:

$ ./a.out -n1
./a.out: UPC initialization failed.
./a.out: reason: Invalid argument
Abort trap (core dumped)

So, this issue is an RFE for porting of the UPC runtime to BSD systems. I have no clue at this point in time as to the amount of work that may be required.

I've been using CMake exclusively since I couldn't get my first configure-based build to work. I've come back to look again and think this is a bug (as opposed to pilot error on my part).

The "make" runs for a faily long time before failing:

make[4]: Entering directory `/global/u1/h/hargrove/upc2c/bb/tools/clang/lib/Frontend'
llvm[4]: Compiling ASTConsumers.cpp for Debug+Asserts build
llvm[4]: Compiling ASTMerge.cpp for Debug+Asserts build
llvm[4]: Compiling ASTUnit.cpp for Debug+Asserts build
llvm[4]: Compiling CacheTokens.cpp for Debug+Asserts build
llvm[4]: Compiling ChainedDiagnosticConsumer.cpp for Debug+Asserts build
llvm[4]: Compiling ChainedIncludesSource.cpp for Debug+Asserts build
llvm[4]: Compiling CompilerInstance.cpp for Debug+Asserts build
llvm[4]: Compiling CompilerInvocation.cpp for Debug+Asserts build
/global/u1/h/hargrove/upc2c/src/llvm/tools/clang/lib/Frontend/CompilerInvocation.cpp: In function 'void ParseLangArgs(clang::LangOptions&, llvm::opt::ArgList&, clang::InputKind, clang::DiagnosticsEngine&)':
/global/u1/h/hargrove/upc2c/src/llvm/tools/clang/lib/Frontend/CompilerInvocation.cpp:1368:60: error: 'UPC_PTS' was not declared in this scope
/global/u1/h/hargrove/upc2c/src/llvm/tools/clang/lib/Frontend/CompilerInvocation.cpp:1370:74: error: 'UPC_PACKED_BITS' was not declared in this scope
/global/u1/h/hargrove/upc2c/src/llvm/tools/clang/lib/Frontend/CompilerInvocation.cpp:1407:76: error: 'UPC_PTS_VADDR_ORDER' was not declared in this scope
/global/u1/h/hargrove/upc2c/src/llvm/tools/clang/lib/Frontend/CompilerInvocation.cpp:1421:59: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
/bin/rm: cannot remove `/global/u1/h/hargrove/upc2c/bb/tools/clang/lib/Frontend/Debug+Asserts/CompilerInvocation.d.tmp': No such file or directory
make[4]: *** [/global/u1/h/hargrove/upc2c/bb/tools/clang/lib/Frontend/Debug+Asserts/CompilerInvocation.o] Error 1
make[4]: Leaving directory `/global/u1/h/hargrove/upc2c/bb/tools/clang/lib/Frontend'
make[3]: *** [Frontend/.makeall] Error 2
make[3]: Leaving directory `/global/u1/h/hargrove/upc2c/bb/tools/clang/lib'
make[2]: *** [all] Error 1
make[2]: Leaving directory `/global/u1/h/hargrove/upc2c/bb/tools/clang'
make[1]: *** [clang/.makeall] Error 2
make[1]: Leaving directory `/global/u1/h/hargrove/upc2c/bb/tools'
make: *** [all] Error 1

Intrepid's test18 test fails on PPC platform with bad vaddr. Here is a small example that duplicates this problem:

#include <upc.h>

static shared int int1 = 5;
void x ()
{
  static shared int int2 = 10;
}
int
main ()
{
  x ();
  int1 = 1;
}

After looking into the generated code I noticed that 'int2' is not being declared from the shared section. Instead, '.comm' is used.

        .type   x.int2,@object
        .local  x.int2
        .comm   x.int2,4,4
        .type   int1,@object
        .section        upc_shared,"",@nobits
        .align  2
int1:
        .long   0
        .size   int1, 4

GUPC allocates this variable from the upc_shared section.

While this bug was exhibited on PPC, the same issues exists on x86-64, but it is not visible as vaddr is small enough to fit inside the thread's sahred space (we just write at the random shared space). On PPC all VMAs start at 0x10000000 that puts our vaddr high enough to be detected.

The cmake build step concludes with

Migrating from a git-svn v1 layout...
Data from a previous version of git-svn exists, but
.git/svn
(required for this version (1.7.11.7) of git-svn) does not exist.
Done migrating from a git-svn v1 layout

when building Clang UPC under FC17, using clang-upc from Github.

We have git-svn installed, so I guess that this error/warning is innocuous, but would like some confirmation on this.
Add

Subtasks
Add

Related issues

Issue #
Delay: days Cancel
History
#1

Updated by Gary Funck about 1 month ago
Comment

FYI, "git status" shows the working directory clean, as expected.

$ git status

On branch master

nothing to commit (working directory clean)
#2

Updated by John Wiegley about 1 month ago
Comment

As far as I can tell, the Clang build process only uses git-svn to determine which SVN revision you are building against. The information is completely optional, and I've even commented out the code in CMake which runs git-svn with no adverse effects.

I am in the process of upgrading the UPC runtime to the latest version in GUPC. That version has support for inter-node communications via a networking API called "portals4". It is enabled via a configure option. The choices are: (1) the current 'smp' runtime, or (2) the 'portals4' runtime. At some point in the future, we might try to unify these runtimes. Another improvement is re-licensing from FSF-assigned GPL licensing to BSD-licensing.

As a first cut, I copied over the new files, tweaked CMakelists.txt by adding the new 'smp' files to LIBUPC_SOURCES. I also copied the new 'config.h.in' onto 'config.h.make'. This, however, led to some build issues. The important diff's follow.

46a64,69

/* Whether UPC pointers-to-shared use the 'packed' representation */

undef GUPCR_PTS_PACKED_REP

/* Size of shared pointer's phase field (in bits) */

undef GUPCR_PTS_PHASE_SIZE

49a73,78
/* Whether UPC shared pointers use the 'struct' representation */

undef GUPCR_PTS_STRUCT_REP

/* Size of shared pointer's thread field (in bits) */

undef GUPCR_PTS_THREAD_SIZE

52a82,87
/* Whether the 'vaddr' field comes first (ie, [[vaddr,thread,phase]]) */

undef GUPCR_PTS_VADDR_FIRST

/* Size of shared pointer's vaddr field (in bits) */

undef GUPCR_PTS_VADDR_SIZE

57c92,95

< #define GUPCR_TREE_FANOUT @UPC_TREE_FANOUT@

undef GUPCR_TREE_FANOUT

/* Define to 1 if UPC runtime will use Portals4 triggered operations. */

undef GUPCR_USE_PORTALS4_TRIGGERED_OPS

After reading through the cmake logic, it seems that the version of config.h that is created from 'config.h.cmake' is built at the top-level of the libupc build structure, but is not built for each {packed,struct}-pts,{first,last}-vaddr variant. The variants pick up their values of 'GUPCR_PTS_PACKED_REP', etc. from the 'COMPILER_DEFINITIONS' property:

set_property(TARGET ${lib_name} PROPERTY COMPILE_DEFINITIONS ${lib_defs})

Then, for the runtime sources written 'upc', there is this logic in 'smp/upc-lib.in':

ifdef UPC_PTS_PACKED_REP

define GUPCR_PTS_PACKED_REP 1

elif defined(UPC_PTS_STRUCT_REP)

define GUPCR_PTS_STRUCT_REP 1

endif

The logic above is a divergence from the logic in the GUPC runtime, because there 'config.h.in' is customized by configure for each runtime variant.

Is the above summary correct?

In the short term, I can remove the explicit #undef of the various shared pointer format related definitions and let the existing cmake logic take care of it, but I am wondering if the logic might be reworked to be more similar to the method used by GUPC?

In a related matter, as shown in the diff's above, there is the cmake substitution that I need to bring back:

define GUPCR_TREE_FANOUT @UPC_TREE_FANOUT@

In general, however, there appear to be many few configuration-related definitions that are either tested by 'cmake' or that might be provided as cmake parameters. (I don't know the syntax for setting those parameters, however.) In particular, the portals4 runtime introduces some new configuration parameters. For example,

40a25,36

/* Size of get/put bounce buffer */

undef GUPCR_BOUNCE_BUFFER_SIZE

/* upc_global_exit() timeout in seconds. */

undef GUPCR_GLOBAL_EXIT_TIMEOUT

/* Define to 1 if UPC runtime checks are supported. */

undef GUPCR_HAVE_CHECKS

/* Define to 1 if UPC runtime debugging mode is enabled. */

undef GUPCR_HAVE_DEBUG

43a40,60
/* Define to 1 if UPC runtime statistics collection is supported. */

undef GUPCR_HAVE_STATS

/* Define to 1 if UPC runtime tracing is supported. */

undef GUPCR_HAVE_TRACE

/* Maximum number of locks held per thread */

undef GUPCR_MAX_LOCKS

/* Define to 1 if UPC runtime will use node local memory accesses. */

undef GUPCR_NODE_LOCAL_MEM

/* Define to 1 if UPC node local access uses mmap-ed file. */

undef GUPCR_NODE_LOCAL_MEM_MMAP

/* Define to 1 if UPC node local access uses Posix shared memory. */

undef GUPCR_NODE_LOCAL_MEM_POSIX

/* Portals4 PTE base index. */

undef GUPCR_PTE_BASE

Summarizing:

1. I'd like to move the shared pointer characteristics back into config.h and have config.h customized for each runtime variant. Is that feasible?
2. I'd like it config.h.cmake produced the same definitions as found in GUPC's config.h.in both in the configuration tests it runs and also by providing similar configuration-specific parameters.

When using cmake, is it sometimes possible to actually run configure as a way of making configuration tests? Or does cmake have another way of implementing configure-like checks?
Add

Subtasks
Add

Related issues

Issue #
Delay: days Cancel
History
#1

Updated by John Wiegley 3 months ago

* Assignee set to Steven Watanabe

#2

Updated by Gary Funck 3 months ago
Comment

I recently merged the current GUPC libgupc runtime into the Clang UPC runtime. Most of the problems encountered relate to the fact that config.h is not fully processed via configure and is not instantiated for each runtime variant.

This web page summarizes the key differences:
[[http://gccupc.org/clang-upc-runtime-mods/]]

While going through the process of updating the runtime, I discovered a couple other differences that I will summarize here, but that might be logically separated out into other issues.

1. In GUPC, there is a file named gcc-upc-lib.in that is pre-processed by a script to produce a header file, gcc-upc-lib.h . However, in Clang it is renamed to upc-lib.in and then pre-processed into upc-lib.h.
2. In GUPC, gcc-upc-lib.h is #included from a file named include/gcc-upc.h. In GUPC, gcc-upc.h is pre-included by the gupc command.
3. In Clang UPC, gcc-upc.h appears to be un-used.
4. In Clang UPC, upc-lib.h is pre-included by the clang command when compiling UPC programs, only when the driver has determined that the runtime should be inlined.

Thus in addition to fully processing config.h.in and customizing it to each runtime variant, it appears that gcc-upc.h should be unconditionally pre-included (as this is the way that gupc works). This in turn will include gcc-upc-lib.h.

A note regarding the rename of gcc-upc-lib.in to upc-lib.in: Although there is some logic in doing that, it does make the task of tracking changes between gupc and clang upc more difficult.
#3

Updated by Steven Watanabe 3 months ago
Comment

1. I'm not sure that moving the #defines back into config.h will help.
   The real problem is that you're trying to use the same file for
   config.h.in and config.h.cmake. Unfortunately, CMake uses a different
   syntax than autoconf, so this isn't really going to work.

2. CMake has its own method of running configuration tests. I just didn't implement it, because it worked without on the platforms we tested with. I don't know of a way for CMake to use the autotools script (It may be possible, but I doubt that there's an easy way--running configure and parsing the output doesn't seem like a very good idea.).
   #4

   Updated by Gary Funck 3 months ago

   • Priority changed from Normal to Urgent
     #5

Updated by Steven Watanabe 3 months ago

* Status changed from New to In Progress

#6

Updated by Steven Watanabe 2 months ago
Comment

The following macros in config.h are apparently unused. I'm assuming that it's okay just to remove them.

HAVE_AS_SYMVER_DIRECTIVE
HAVE_ATTRIBUTE_ALIAS
HAVE_ATTRIBUTE_DLLEXPORT
HAVE_ATTRIBUTE_VISIBILITY
HAVE_BACKTRACE
HAVE_BACKTRACE SYMBOLS
HAVE_BACKTRACE_SYMBOLS_FD
HAVE_BROKEN_POSIX_SEMAPHORES
HAVE_CC_TLS
HAVE_DECL_SYS_SIGLIST
HAVE_DLFCN_H
HAVE_FCNTL_H
HAVE_FORK
HAVE_FTRUNCATE
HAVE_GETCWD
HAVE_GETHOSTBYNAME
HAVE_GETLOADAVG
HAVE_GETPAGESIZE
HAVE_GTHR_DEFAULT
HAVE_INTTYPES_H
HAVE_MALLOC
HAVE_MEMORY_H
HAVE_MEMSET
HAVE_MKDIR
HAVE_MMAP
HAVE_MUNMAP
HAVE_NETDB_H
HAVE_NETINET_IN_H
HAVE_PTHREAD_AFFINITY_NP
HAVE_PTRDIFF_T
HAVE_SCHED_H
HAVE_SEMAPHORE_H
HAVE_SOCKET
HAVE_STAT_EMPTY_STRING_BUG
HAVE_STDDEF_H
HAVE_STDINT_H
HAVE_STDLIB_H
HAVE_STRCASECMP
HAVE_STRDUP
HAVE_STRERROR
HAVE_STRINGS_H
HAVE_STRING_H
HAVE_STRTOL
HAVE_STRTOULL
HAVE_SYNC_BUILTINS
HAVE_SYS_LOADAVG_H
HAVE_SYS_SOCKET_H
HAVE_SYS_STAT_H
HAVE_SYS_TYPES_H
HAVE_TYPE_WAIT_H
HAVE_TLS
HAVE_UNISTD_H
HAVE_VFORK
HAVE_VFORK_H
HAVE_WORKING_FORK
HAVE_WORKING_VFORK
LIBGUPC_GNU_SYMBOL_VERSIONING
LSTAT_FOLLOWS_SLASHED_SYMLINK
LT_OBJDIR
PACKAGE
PACKAGE_NAME
PACKAGE_STRING
PACKAGE_TARNAME
PACKAGE_URL
PACKAGE_VERSION
SIZEOF_CHAR
SIZEOF_INT
SIZEOF_LONG
SIZEOF_SHORT
SIZEOF_VOID_P
STDC_HEADERS
STRING_WITH_STRINGS
VERSION
#7

Updated by Gary Funck 2 months ago
Comment

Steven Watanabe wrote:

The following macros in config.h are apparently unused.
I'm assuming that it's okay just to remove them.

Yes. That's OK. We have a tendency to add (or inherit) autoconf tests that we don't use.
#8

Updated by Steven Watanabe 2 months ago
Comment

Where can I find portals4?
#9

Updated by Steven Watanabe 2 months ago
Comment

I'm not sure that specializing config.h for each build variant is feasible.
config.h is one of the sources for gcc-upc-lib.h, and I'd really rather avoid specializing gcc-upc-lib.h as this would mean extra logic to #include the correct file depending on the compiler options.
#10

Updated by Gary Funck 2 months ago
Comment

Steven Watanabe wrote:

Where can I find portals4?

I will send you a "how to" under separate cover.
#11

Updated by Gary Funck 2 months ago
Comment

Steven Watanabe wrote:

I'm not sure that specializing config.h for each build variant is feasible.
config.h is one of the sources for gcc-upc-lib.h, and I'd really rather avoid specializing gcc-upc-lib.h as this would mean extra logic to #include the correct file depending on the compiler options.

We may need to discuss this in a telecon, so that I can be sure that I understand the issues.

However we do it, the goal is for the libgupc runtime sources (the non-make/config related files) to match those in the clang libupc directory. I don't think that Intrepid wants to use the approach used in the clang runtime, but perhaps there is a middle ground some where.

See below for the error I encounter building clang-upc on NetBSD6/amd64.

Looks like sys_siglist is not very portable, as you already have an #if for sgi.

I will see about a patch for this issue mysef, since I am able to test.

[ 91%] Building C object tools/clang/runtime/libupc/CMakeFiles/upc.dir/smp/upc_sysdep.c.o
/home/phargrov/upcnightly/llvm-upc/src/tools/clang/runtime/libupc/smp/upc_sysdep.c:46:29: error: redefinition of 'sys_siglist' with a different type: 'const char *const []' vs 'const char *const *'
  extern const char * const sys_siglist[];
                            ^
/usr/include/signal.h:52:27: note: previous definition is here
extern const char *const *sys_siglist __RENAME(__sys_siglist14);
                          ^
1 error generated.

After the upgrade to 3.3 I tried to re-run the test suite. Two things happen:

(1) Running with only one thread hangs the program on the first barrier
(2) Running with two or more threads reports the following error:
./t: UPC error: Invalid conversion of shared address to local pointer;
thread does not have affinity to shared address
thread 1 terminated with signal: 'Aborted'

Is it possible that this code in lib/CodeGen/CGExprScalar.cpp has the return values reversed:

Value *VisitUPCMyThreadExpr(UPCMyThreadExpr *E) {
return CGF.EmitUPCThreads();
}

Value *VisitUPCThreadExpr(UPCThreadExpr *E) {
return CGF.EmitUPCMyThread();
}

Attached, is a file that lists various compile-time warnings that are detected when building the Clang UPC compiler.

The affected source files are:

clang/lib/AST/ExprConstant.cpp
clang/lib/CodeGen/CGRTTI.cpp
clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp
clang/tools/libclang/CXCursor.cpp

Not sure if you will agree this is a bug, but I consider it one....

Currently clangupc (and therefore upc2c) is pre-defining __GCC_UPC__. I think it would be far better to have __CLANG_UPC__ or just about anything other than an identifier that is already used to identify a different UPC compiler.

FWIW: this definition had hidden upc2c issue #59

The following three options deal with UPC pointer representation

UPC_PTS
UPC_PACKED_BITS
UPC_PTS_VADDR_ORDER

To make things consistent (with GUPC configure options) UPC_PACKED_BITS needs to be renamed to UPC_PTS_PACKED_BITS.

The UPC 1.3 Specification states that an automatic layout qualifier ([]) are invalid and should issue an error diagnostic. GUPC currently will issue an error for dynamic threads, but will attempt to evaluate [] for static threads.
http://code.google.com/p/upc-specification/issues/detail?id=71 [^]

Clang UPC should diagnose '[*]' as an error for static threads compilations.

commit a4a81f7694a5b69887efdcef8844cb1c9825dc5b
Author: Nenad Vukicevic <[email protected]>
Date:   Wed Jan 29 16:16:37 2014 -0800

clang -cc1 -internal-isystem /eng/upc/dev/gar
y/clang/bld/bin/../lib/clang/3.4/include -fsyntax-only -fupc-threads 1 -verify
/eng/upc/dev/gary/clang/src/llvm/tools/clang/test/SemaUPC/dup-layout-specifier.
upc

error: 'error' diagnostics expected but not seen:
  File /eng/upc/dev/gary/clang/src/llvm/tools/clang/test/SemaUPC/dup-layout-spe
cifier.upc Line 17: cannot combine with previous 'shared' declaration specifier
[...]

Here is an example (at line 17):

shared [ ] shared [1] int ie1; // expected-error{{cannot combine with previous 'shared' declaration specifier}}

Above, "[]" implies a layout qualifier of 0, which cannot be merged with [1]. Thus the expected error seems to be correct. There are many failures to match expected output in this test.

A few tests in upc-sematic test suite are passing in harness with clangupc but should fail:

[upc-semantic-checks/invalid-local-ptr-to-void-arith_st04] FAILED: expect fail  
[upc-semantic-checks/invalid-local-ptr-to-void-arith] FAILED: expect fail but   
[upc-semantic-checks/invalid-sizeof-shared-void_st04] FAILED: expect fail but   
[upc-semantic-checks/invalid-sizeof-shared-void] FAILED: expect fail but passed 
[upc-semantic-checks/invalid-sizeof-void_st04] FAILED: expect fail but got      
[upc-semantic-checks/invalid-sizeof-void] FAILED: expect fail but got warning 

I don't know if this is related to 3.4 update or this never worked the way it was supposed. For example this should produce an error:

void *x;
..
y = x + 1;

However, clangupc does not treat this as an error. It treats it as an error/waring if "-pedantic-errors" option is specified. GUPC produces an error.

Note that this error is masked by the options we use when we test clangupc with intrepid test suite. A -pedantic-errors switch together with -Wall -Wextra -Werror is used that makes this warning an error and test checking gets the right result.

This error should not be masked by switches.

The following ICE occurred when running the following command:

$ clangupc -fupc-pts-packed -g  -I. -Wno-implicit-functi
on-declaration -Wno-deprecated -fno-caret-diagnostics -Wno-logical-op-parenthes
es -Wno-unused-comparison -Wno-unused-value -Wno-dangling-else -Wno-duplicate-d
ecl-specifier -g    -fupc-threads-4 -c dup_quals.upc

clang-3.2:clang/src/llvm/tools/clang/lib/CodeGen/CGDebugInfo
.cpp:496: llvm::DIType clang::CodeGen::CGDebugInfo::CreateQualifiedType(clang::
QualType, llvm::DIFile): Assertion `Qc.empty() && "Unknown type qualifier for d
ebug info"' failed.
0  clang-3.2       0x00000000016975a6
1  clang-3.2       0x000000000169727c
2  libpthread.so.0 0x0000003991a0f000
3  libc.so.6       0x0000003991635ba5 gsignal + 53
4  libc.so.6       0x0000003991637358 abort + 328
3  libc.so.6       0x0000003991635ba5 gsignal + 53
4  libc.so.6       0x0000003991637358 abort + 328
5  libc.so.6       0x000000399162e972
6  libc.so.6       0x000000399162ea22
7  clang-3.2       0x00000000017731d5 clang::CodeGen::CGDebugInfo::CreateQualif
iedType(clang::QualType, llvm::DIFile) + 349
8  clang-3.2       0x0000000001779319 clang::CodeGen::CGDebugInfo::CreateTypeNo
de(clang::QualType, llvm::DIFile) + 59
9  clang-3.2       0x0000000001779139 clang::CodeGen::CGDebugInfo::getOrCreateT
ype(clang::QualType, llvm::DIFile) + 181
10 clang-3.2       0x000000000177e744 clang::CodeGen::CGDebugInfo::EmitGlobalVa
riable(llvm::GlobalVariable*, clang::VarDecl const*) + 828
11 clang-3.2       0x00000000016d703e clang::CodeGen::CodeGenModule::EmitGlobal
VarDefinition(clang::VarDecl const*) + 2492
12 clang-3.2       0x00000000016d58b2 clang::CodeGen::CodeGenModule::EmitTentat
iveDefinition(clang::VarDecl const*) + 276
13 clang-3.2       0x00000000016cca31
14 clang-3.2       0x00000000016cb7c0
[...]

Building with CC=clang/CXX=clang++, I see the following two warnings:

/usr/home/phargrov/upcnightly/llvm-upc/src/tools/clang/lib/Frontend/CompilerInvocation.cpp:1421:22: warning: comparison of integers of different signs: 'int' and 'uint64_t' (aka 'unsigned long long') [-Wsign-compare]
  } else if (Threads > (uint64_t(1u) << Opts.UPCThreadBits)) {
             ~~~~~~~ ^  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.

/usr/home/phargrov/upcnightly/llvm-upc/src/tools/clang/lib/Edit/RewriteObjCFoundationAPI.cpp:1000:13: warning: enumeration values 'CK_UPCSharedToLocal' and 'CK_UPCBitCastZeroPhase' not handled in switch [-Wswitch]
    switch (ICE->getCastKind()) {
            ^
1 warning generated.

I am trying to build clang-upc on a ppc64/linux system.
I was unsuccessful with gcc-4.4.7, but the system as a Clang installation which reports itself as version "clang version 3.5 (trunk)".

So, I've run cmake with -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++.

The build eventually fails with:

[ 91%] Building C object tools/clang/runtime/libupc/CMakeFiles/upc.dir/smp/upc_allocg.upc.o
In file included from <built-in>:169:
In file included from <command line>:15:
In file included from /home/hargrove/upc2c/src/llvm/tools/clang/runtime/libupc/include/clang-upc.h:15:
/gpfs/vesta-home/hargrove/upc2c/bld/bin/../lib/clang/3.4/include/clang-upc-lib.h:548:58: error: redefinition of parameter 'os_atomic_t'
  extern int __upc_atomic_cas (os_atomic_p, os_atomic_t, os_atomic_t);
                                                         ^
/gpfs/vesta-home/hargrove/upc2c/bld/bin/../lib/clang/3.4/include/clang-upc-lib.h:548:32: error: a parameter list without types is only allowed in a function definition
  extern int __upc_atomic_cas (os_atomic_p, os_atomic_t, os_atomic_t);
                               ^
2 errors generated.
make[2]: *** [tools/clang/runtime/libupc/CMakeFiles/upc.dir/smp/upc_allocg.upc.o] Error 1
make[1]: *** [tools/clang/runtime/libupc/CMakeFiles/upc.dir/all] Error 2
make: *** [all] Error 2

While not straight-forward, these error messages seem to be saying that type os_atomic_p and os_atomic_t have not been defined. The messages are confusing because clang seems to think it might be parsing a K&R-style function definition (the main clues are "redefinition of parameter" in the first message, and "a parameter list without types" in the second message).