libupc build failure on x86-32

[PHHargrove]

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  

[gary-funck]

On 02/26/14 19:03:00, Paul H. Hargrove wrote:

I've tried to build on four different x86-23 (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

I tried building on a CentOS 32-bit VM and can duplicate a similar failure. Made sure to run the make with -j1 and enabled a debug build.

Here are the top 10/so traceback frames.

[ 90%] Building C object tools/clang/runtime/libupc/CMakeFiles/upc.dir/smp/upc_allocg.upc.o
clang-3.4: /eng/upc/dev/gary/clang/src/llvm/lib/IR/Instructions.cpp:1084: void llvm::StoreInst::AssertO
K(): Assertion `getOperand(0)->getType() == cast<PointerType>(getOperand(1)->getType())->getElementType
() && "Ptr must be a pointer to Val type!"' failed.
0  clang-3.4 0x092f4194 llvm::sys::PrintStackTrace(_IO_FILE*) + 50
1  clang-3.4 0x092f43e7
2  clang-3.4 0x092f3de4
3            0x00516400 __kernel_sigreturn + 0
4  libc.so.6 0x001506ca abort + 378
5  libc.so.6 0x00147efb
6  libc.so.6 0x00147fb6
7  clang-3.4 0x091a685f llvm::StoreInst::AssertOK() + 309
8  clang-3.4 0x091a6ba5 llvm::StoreInst::StoreInst(llvm::Value*, llvm::Value*, bool, llvm::Instruction*
) + 251
9  clang-3.4 0x088f7108
10 clang-3.4 0x0947bb83 clang::CodeGen::CodeGenFunction::EmitStoreOfScalar(llvm::Value*, llvm::Value*,
bool, unsigned int, clang::QualType, llvm::MDNode*, bool, clang::QualType, unsigned long long) + 1141
11 clang-3.4 0x0947bdf3 clang::CodeGen::CodeGenFunction::EmitStoreOfScalar(llvm::Value*, clang::CodeGen
::LValue, bool) + 487
[...]

[PHHargrove]

Any estimate on when this might be addressed?

[PHHargrove]

Related question:

Is it possible to build without libupc, specifically for the case where I only care about clang-up2c? I tried scanning the cmake files but did't find anything that looked to me like a switch for this.

[gary-funck]

On 03/05/14 17:49:46, Paul H. Hargrove wrote:

Related question:

Is it possible to build without libupc, specifically for the case where I only care about clang-up2c? I tried scanning the cmake files but did't find anything that looked to me like a switch for this.

See my previous reply.

[PHHargrove]

Is it possible to build without libupc, specifically for the case where I only care about clang-up2c?[...]

See my previous reply.

????

Your previous email reply dealt with issue #31 (building w/o cmake). I don't see anything there about disabling libupc in the build.

[gary-funck]

On 03/05/14 18:05:59, Paul H. Hargrove wrote:

Is it possible to build without libupc, specifically for the case where I only care about clang-up2c?[...]

See my previous reply.

????

Your previous email reply dealt with issue #31 (building w/o cmake). I don't see anything there about disabling libupc in the build.

I'd need to double check, but I thought that I suggested that if we're building upc2c we could look into not compiling/building the runtime library (libupc), but only building/installing the header files as needed ....

[PHHargrove]

On Wed, Mar 5, 2014 at 9:19 PM, gary-funck notifications@github.com wrote:

On 03/05/14 18:05:59, Paul H. Hargrove wrote:

Is it possible to build without libupc, specifically for the case where I only care about clang-up2c?[...]

See my previous reply.

????

Your previous email reply dealt with issue #31 (building w/o cmake). I don't see anything there about disabling libupc in the build.

I'd need to double check, but I thought that I suggested that if we're building upc2c we could look into not compiling/building the runtime library (libupc), but only building/installing the header files as needed ....

Yes, I do see something along those lines now. Sorry I missed it before.

-Paul

Paul H. Hargrove PHHargrove@lbl.gov Future Technologies Group Computer and Data Sciences Department Tel: +1-510-495-2352 Lawrence Berkeley National Laboratory Fax: +1-510-486-6900

[swatanabe]

On 03/05/2014 05:49 PM, Paul H. Hargrove wrote:

Is it possible to build without libupc, specifically for the case where I only care about clang-up2c? I tried scanning the cmake files but did't find anything that looked to me like a switch for this.

There isn't a specific switch for this, but the CMake files do allow you specify which library variants to build. (i.e. packed/struct etc.) Setting this to nothing might work.

[PHHargrove]

I see a fair amount of interest/effort now in the idea of building clang-upc w/o also building libupc. While I am the one who asked about this in the first place, I am not sure it will accomplish much.

The error I reported here initially is that clang was crashing building libupc on x86-32. Since it crashed trying to compile upc_alloc.upc, I really don't expect that the compiler will work on a user's UPC code either. If I am right about that, then skipping the build of libupc doesn't get us any closer to a working x86-32 build of clang-upc.

[swatanabe]

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

I see a fair amount of interest/effort now in the idea of building clang-upc w/o also building libupc. While I am the one who asked about this in the first place, I am not sure it will accomplish much.

The error I reported here initially is that clang was crashing building libupc on x86-32. Since it crashed trying to compile upc_alloc.upc, I really don't expect that the compiler will work on a user's UPC code either. If I am right about that, then skipping the build of libupc doesn't get us any closer to a working x86-32 build of clang-upc.

clang-upc only targets x86-64. Various parts of the code that deal with sizes and alignments may need to be changed to make it work with x86-32.

[PHHargrove]

clang-upc only targets x86-64. Various parts of the code that deal with sizes and alignments may need to be changed to make it work with x86-32.

Pretty sure the UPC support will never be accepted upstream if it can't support 32-bit targets.

-Paul

[PHHargrove]

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

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

However, clang-upc2c does work on this system. So, maybe not building libupc will yield a usable clang-upc2c, even if clang-upc remains broken.

[swatanabe]

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.

However, clang-upc2c does work on this system. So, maybe not building libupc will yield a usable clang-upc2c, even if clang-upc remains broken.

Most likely true. Since the problem is in CodeGen instead of in ASTContext (as with the 32-bit problems) it won't affect clang-upc2c.

[swatanabe]

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

Pretty sure the UPC support will never be accepted upstream if it can't support 32-bit targets.

Nod. It's not very hard to add support. It just wasn't a requirement for the original clangupc project.

[PHHargrove]

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.

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.

[nenadv]

I don't think first/last has anything to do with machine endian, it is only the way we lay it out in the overlaying register. E.g. for 64 bit packed first is if vaddr is in the upper portion of the register, last if it is aligned with bit lowest significant bit (or the other way around). And both machines, Intel/IBM, this layout is the same.

[swatanabe]

The library at least builds without errors now, as of 77a5f3c8ebf0a6afb1bad89e292d456ce8a764b1

[nenadv]

Regarding 32 bit implementation, I noticed in couple of places (and I added one last week on PPC function return fix), that the code checks for packed/struct implementation by checking the size of the address field for 64. Which is now incorrect for 32-bit implementation. Maybe the best is to add a UPC flag for struct/packed pointer representation.

[nenadv]

Branch issue-36 contains my current changes for 32-bit.

[nenadv]

I was able to pass almost all of the tests with dbg packed/struct on 32 bit machine. The failing ones are linker related:

- 'pow' was not found in some atomic tests 
- '__atomic_fetch_[add,and,or,xor]_8' are not found - missing compiler-rt library (same as
atomics problem in x86_64 struct implementation).

For these errors I need to check and updated the expected results.

- bug846.upc:9:58: error: array is too large (256 elements)
unsigned long long localsz = upc_localsizeof(shared int [256][1024][1024*THREADS]);
- bug342.upc:10:10: warning: size of field 'd' (64 bits) does not match the size of the first field in transparent union; transpar
ent_union attribute ignored [-Wignored-attributes]
  double d;
- bug247.upc:5:20: error: array is too large (1090584576 elements)
shared double buff[THREADS*1065024ull];
                   ^~~~~~~~~~~~~~~~~~

[nenadv]

Fixed by this commit: https://github.com/Intrepid/clang-upc/commit/ff266f0b6adc2ab16142c8d5210889b9b70ae481