(REGRESSION) crash in coverage build: error in backend: File exit not handled before popRegions

[llvmbot]

Bugzilla Link	38987
Resolution	FIXED
Resolved on	Nov 28, 2018 18:57
Version	7.0
OS	Linux
Blocks	#38454
Reporter	LLVM Bugzilla Contributor
CC	@AaronBallman,@DougGregor,@orivej,@tstellar,@vsapsai,@vedantk
Fixed by commit(s)	r347261 r347797

Extended Description

compiler is crashing during coverage build.

---

FAILED: ccache /usr/bin/clang++ -DBEAST_CHECK_MEMORY_LEAKS=0 -DBOOST_ASIO_DISABLE_HANDLER_TYPE_REQUIREMENTS -DBOOST_ASIO_HAS_STD_ARRAY -DBOOST_BEAST_ALLOW_DEPRECATED -DBOOST_COROUTINES_NO_DEPRECATION_WARNING -DBOOST_FILESYSTEM_DEPRECATED -DBOOST_NO_AUTO_PTR -DDEBUG -DLIBARCHIVE_STATIC -DOPENSSL_NO_SSL2 -DOS_LINUX -DRIPPLE_DUMP_LEAKS_ON_EXIT=1 -DRIPPLE_ROCKSDB_AVAILABLE=1 -DROCKSDB_LIB_IO_POSIX -DROCKSDB_PLATFORM_POSIX -DSNAPPY -DSOCI_HAVE_CXX_C11=1 -D_DEBUG -I../../src -Ilz4/include -Isqlite3/include -I../../src/soci/src -I../../src/soci/include -I../../src/sqlite -I../../ -I../../src/snappy/snappy -I../../src/snappy/config -I../../src/rocksdb2/include -I../../src/nudb/include -I../../src/ripple -I../../src/beast/extras -isystem /usr/local/include -isystem ../../.nih_c/ninja/Clang_7.0.0/src/libarchive/libarchive -isystem /opt/boost_1_67_0 -isystem proto_gen -Wall -Wdeprecated -g -fPIE -Werror -frtti -Wnon-virtual-dtor -Wno-sign-compare -Wno-char-subscripts -Wno-format -Wno-unused-local-typedefs -O0 -fprofile-instr-generate -fcoverage-mapping -pthread --system-header-prefix=rocksdb2 -std=gnu++14 -MD -MT CMakeFiles/rippled.dir/src/ripple/app/consensus/RCLConsensus.cpp.o -MF CMakeFiles/rippled.dir/src/ripple/app/consensus/RCLConsensus.cpp.o.d -o CMakeFiles/rippled.dir/src/ripple/app/consensus/RCLConsensus.cpp.o -c ../../src/ripple/app/consensus/RCLConsensus.cpp
fatal error: error in backend: File exit not handled before popRegions
clang: error: clang frontend command failed with exit code 70 (use -v to see invocation)
clang version 7.0.0-svn341916-1exp120180911120538.25 (branches/release_70)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
clang: note: diagnostic msg: PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script.
clang: note: diagnostic msg:

---

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /tmp/RCLConsensus-9c88e7.cpp
clang: note: diagnostic msg: /tmp/RCLConsensus-9c88e7.sh
clang: note: diagnostic msg:

---

[llvmbot]

assigned to @zygoloid

[llvmbot]

Just wanted to clarify: this same build/code works fine in llvm-6

[llvmbot]

sh mentioned in crash

[llvmbot]

the cpp file in the bugreport:

https://raw.githubusercontent.com/mellery451/bugfiles/master/llvm/RCLConsensus-9c88e7.cpp

[llvmbot]

FWIW, the latest apple clang (Apple LLVM version 10.0.0 (clang-1000.11.45.2)) has exactly the same issue and that's where I first encountered it.

[orivej]

This issue was introduced in rL322729 (https://reviews.llvm.org/D41921).

Here is a small test case:

 class A {};
 class B : A {};
 template <typename T> void f() { 0 ? T{} : T{}; }
 template void f<B>();

Test it with:

 clang++ -std=c++17 -fprofile-instr-generate -fcoverage-mapping -c test.cpp

[orivej]

Here is a slightly simpler example that does not require -std=c++17:

 struct A { A(); operator bool(); };
 template <class T> void f() { if (T{}); }
 template void f<A>();

[orivej]

Here is a minimal example that does not break coverage, but it demonstrates the regression in the source locations:

 struct A { A(); };
 template <class T> void f() { T{}; }
 template void f<A>();

"clang -cc1 -ast-dump" at r322728 prints:

-FunctionTemplateDecl 0xbb83a50 <line:2:1, col:36> col:25 f |-TemplateTypeParmDecl 0xbb838e0 <col:11, col:17> col:17 referenced class depth 0 index 0 T |-FunctionDecl 0xbb839b0 <col:20, col:36> col:25 f 'void ()' | -CompoundStmt 0xbb83b60 <col:29, col:36>
| -CXXUnresolvedConstructExpr 0xbb83b30 <col:31, col:33> 'T' 'T' list | -InitListExpr 0xbb83af0 <col:32, col:33> 'void'
-FunctionDecl 0xbb83c80 <col:20, col:36> col:25 f 'void ()' |-TemplateArgument type 'A' -CompoundStmt 0xbb842f0 <col:29, col:36>
`-CXXTemporaryObjectExpr 0xbb84198 <col:31, col:33> 'A':'A' 'void ()' list

and r322729 prints the same except for the final line:

  `-CXXTemporaryObjectExpr 0xb85a198 <col:31, <invalid sloc>> 'A':'A' 'void ()' list

This can be fixed by reverting this hunk: https://reviews.llvm.org/D41921#inline-468844. I'll send a PR.

[orivej]

Review: https://reviews.llvm.org/D53231

[llvmbot]

Ah, I should have looked up the error message before I bothered running c-reduce. Not sure if this is useful additional data in understanding things, but I'll attach what I was able to reduce it to.

[llvmbot]

automated replication
This is the output of c-reduce on some code of mine that triggered (apparently?) this bug or at least the same message. The script is suitable for use with c-reduce: it returns 0 error code if the bug is reproduced (builds with clang 6 but not 8), and 1 otherwise.

[orivej]

My review fixes the compilation of your example.

[tstellar]

mentioned in issue #38454

[orivej]

mentioned in issue llvm/llvm-bugzilla-archive#39258

[orivej]

mentioned in issue llvm/llvm-bugzilla-archive#39740