OpenACC build of standalone ocean fails with link error with Cray FTN on Crusher

[philipwjones]

(Already reported to OLCF help but replicated here) When building the OpenACC version of MPAS-Ocean in standalone mode with the Cray Fortran compiler on Crusher, the link fails with error:

llc: /b/worker/clang-release-craystable-x86/build/src/llvm/lib/Analysis/ScalarEvolution.cpp:1619: const llvm::SCEV* llvm::ScalarEvolution::getZeroExtendExpr(const llvm::SCEV*, llvm::Type*, unsigned int): Assertion `!Op->getType()->isPointerTy() && "Can't extend pointer!"' failed.
PLEASE submit a bug report to Cray and include the crash backtrace.
Stack dump:
0.	Program arguments: /opt/cray/pe/cce/13.0.0/cce-clang/x86_64/bin/llc -mtriple=amdgcn-amd-amdhsa -disable-promote-alloca-to-lds -mcpu=gfx90a -filetype=asm /tmp/cooltmpdir-XaerRv/ocean_model-cce-openmppre-llc.bc -o /tmp/cooltmpdir-XaerRv/ocean_model-cce-openmppost-llc.s
1.	Running pass 'Function Pass Manager' on module '/tmp/cooltmpdir-XaerRv/ocean_model-cce-openmppre-llc.bc'.
2.	Running pass 'Loop Pass Manager' on function '@"ocn_diagnostic_solve_pressure$ocn_diagnostics_$ck_L1893_41"'
3.	Running pass 'Loop Strength Reduction' on basic block '%"file mpas_ocn_diagnostics.F, line 1908, in inner loop at depth 2, bb741703"'
 #0 0x0000000002ead10e PrintStackTraceSignalHandler(void*) Signals.cpp:0:0
 #1 0x0000000002eaa47d SignalHandler(int) Signals.cpp:0:0
 #2 0x0000154b16b7a8bf (/lib64/libpthread.so.0+0x168bf)
 #3 0x0000154b158aacda raise (/lib64/libc.so.6+0x4acda)
 #4 0x0000154b158ac374 abort (/lib64/libc.so.6+0x4c374)
 #5 0x0000154b158a2cd9 __assert_fail_base (/lib64/libc.so.6+0x42cd9)
 #6 0x0000154b158a2d61 __assert_fail (/lib64/libc.so.6+0x42d61)
 #7 0x0000000001f0beb2 llvm::ScalarEvolution::getZeroExtendExpr(llvm::SCEV const*, llvm::Type*, unsigned int) (/opt/cray/pe/cce/13.0.0/cce-clang/x86_64/bin/llc+0x1f0beb2)
 #8 0x0000000001f17eb7 llvm::ScalarEvolution::getAnyExtendExpr(llvm::SCEV const*, llvm::Type*) (/opt/cray/pe/cce/13.0.0/cce-clang/x86_64/bin/llc+0x1f17eb7)
 #9 0x00000000028c81af (anonymous namespace)::LSRInstance::GenerateAllReuseFormulae() LoopStrengthReduce.cpp:0:0
#10 0x00000000028cf470 (anonymous namespace)::LSRInstance::LSRInstance(llvm::Loop*, llvm::IVUsers&, llvm::ScalarEvolution&, llvm::DominatorTree&, llvm::LoopInfo&, llvm::TargetTransformInfo const&, llvm::AssumptionCache&, llvm::TargetLibraryInfo&, llvm::MemorySSAUpdater*) LoopStrengthReduce.cpp:0:0
#11 0x00000000028d26b8 ReduceLoopStrength(llvm::Loop*, llvm::IVUsers&, llvm::ScalarEvolution&, llvm::DominatorTree&, llvm::LoopInfo&, llvm::TargetTransformInfo const&, llvm::AssumptionCache&, llvm::TargetLibraryInfo&, llvm::MemorySSA*) LoopStrengthReduce.cpp:0:0
#12 0x00000000028d436e (anonymous namespace)::LoopStrengthReduce::runOnLoop(llvm::Loop*, llvm::LPPassManager&) LoopStrengthReduce.cpp:0:0
#13 0x0000000001e7b4a6 llvm::LPPassManager::runOnFunction(llvm::Function&) (/opt/cray/pe/cce/13.0.0/cce-clang/x86_64/bin/llc+0x1e7b4a6)
#14 0x00000000026b70fe llvm::FPPassManager::runOnFunction(llvm::Function&) (/opt/cray/pe/cce/13.0.0/cce-clang/x86_64/bin/llc+0x26b70fe)
#15 0x00000000026b7268 llvm::FPPassManager::runOnModule(llvm::Module&) (/opt/cray/pe/cce/13.0.0/cce-clang/x86_64/bin/llc+0x26b7268)
#16 0x00000000026b7a77 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/opt/cray/pe/cce/13.0.0/cce-clang/x86_64/bin/llc+0x26b7a77)
#17 0x0000000000999dd6 compileModule(char**, llvm::LLVMContext&) llc.cpp:0:0
#18 0x00000000008d55b1 main (/opt/cray/pe/cce/13.0.0/cce-clang/x86_64/bin/llc+0x8d55b1)
#19 0x0000154b158952bc __libc_start_main (/lib64/libc.so.6+0x352bc)
#20 0x0000000000990609 _start /home/abuild/rpmbuild/BUILD/glibc-2.19/csu/../sysdeps/x86_64/start.S:122:0

[sarats]

I presume the Cray folks (@mattdturner, @twhite-cray and @abbotts) are already aware of this.

[abbotts]

The backtrace on this resembles several other errors in other applications, all of which have been confirmed fixed in an upcoming compiler release. I haven't seen the bug for this specific case yet though, so I can't say that for certain.

I don't remember if there's a workaround for this one. I'll try to check.

[philipwjones]

This has been fixed with cce14 (though created some additional issues that I will open).