Reproducible Clang crash + strongly suspected invalid code generation

[llvmbot]

Bugzilla Link	36055
Resolution	FIXED
Resolved on	Feb 26, 2018 15:08
Version	unspecified
OS	MacOS X
Blocks	#35152
Attachments	run script, preprocessed source
Reporter	LLVM Bugzilla Contributor
CC	@DimitryAndric,@zmodem,@nlewycky,@zygoloid

Extended Description

--- 1. Command-line which caused the crash and output:

gcc -DITHARE_OBF_SEED=0xbcef7cc0201ec100 -DITHARE_OBF_SEED2=0x0ec20b00a6b0f5ee -DITHARE_OBF_INIT -DITHARE_OBF_CONSISTENT_XPLATFORM_IMPLICIT_SEEDS -DITHARE_OBF_DBG_RUNTIME_CHECKS -o obftemp -std=c++1z -lstdc++ -Werror -g ../official.cpp
clang: error: unable to execute command: Killed: 9
clang: error: clang frontend command failed due to signal (use -v to see invocation)
Apple LLVM version 9.0.0 (clang-900.0.39.2)
Target: x86_64-apple-darwin17.3.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ 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: /var/folders/28/484cmxmd5g7dzh3jd2fkhvfw0000gn/T/official-cc1d9a.cpp
clang: note: diagnostic msg: /var/folders/28/484cmxmd5g7dzh3jd2fkhvfw0000gn/T/official-cc1d9a.sh
clang: note: diagnostic msg: Crash backtrace is located in
clang: note: diagnostic msg: /Users/nemo/Library/Logs/DiagnosticReports/clang__.crash
clang: note: diagnostic msg: (choose the .crash file that corresponds to your crash)
clang: note: diagnostic msg:

---

NOTES:

• .cpp and .sh are attached
• no crash backtrace was created
• #defines in command-line are of CRITICAL importance; in general, ANY change to the parameters will lead to VERY different results.
• don't ask why the source is written like this - there are other reasons to write it, but apparently it happens to be a very good open-source tool to torture compiler :-).

--- 2. IF changing command line above, keeping it almost-the-same but removing '-g' option, the code will compile, but resulting Mac OS X executable will crash with segfault (only with these #defines, with ~10'000 other random #defines it was ok). There is a strong suspicion that this is a manifestation of a code generation bug in Clang (there are very few pointers in the whole program - except for occasional type punning, and it is very difficult to get a segfault there); of course, technically speaking, there is always a chance that there is some UB which manifests like this - but combined with the Clang crashing with almost-exactly the same command line - chances are that it is a manifestation of the same bug in Clang.

[DimitryAndric]

Since you specifically mention Apple Clang, and the error out even says "PLEASE submit a bug report to http://developer.apple.com/bugreporter/", normally I would ask you to please go to Apple and report it there. :)

However, it looks like what you have found is something that causes clang to slowly eat up all RAM until it gets killed, at least with the Apple version 9.0.0 from Xcode 9. If you run the test case with stock llvm/clang on e.g. FreeBSD, you get an assertion instead:

Assertion failed: (!E->isValueDependent()), function EvaluateInPlace, file /share/dim/src/llvm/trunk/tools/clang/lib/AST/ExprConstant.cpp, line 9984.
#​0 0x00000000024b4858 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/share/dim/llvm/322755-trunk-freebsd12-amd64-ninja-rel-1/bin/clang+0x24b4858)
#​1 0x00000000024b4ea6 SignalHandler(int) (/share/dim/llvm/322755-trunk-freebsd12-amd64-ninja-rel-1/bin/clang+0x24b4ea6)
#​2 0x0000000804234166 handle_signal /usr/src/lib/libthr/thread/thr_sig.c:0:3
Stack dump:
0. Program arguments: /share/dim/llvm/322755-trunk-freebsd12-amd64-ninja-rel-1/bin/clang -cc1 -triple x86_64-apple-macosx10.13.0 -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -S -mrelax-all -disable-free -disable-llvm-verifier -discard-value-names -main-file-name official.cpp -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -fno-strict-return -masm-verbose -munwind-tables -target-cpu penryn -target-linker-version 305 -stdlib=libc++ -Werror -std=c++1z -fdeprecated-macro -ferror-limit 19 -fmessage-length 80 -stack-protector 1 -fblocks -fobjc-runtime=macosx-10.13.0 -fencode-extended-block-signature -fcxx-exceptions -fexceptions -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics testcase0.cpp

1.  ../../src/obf.h:429:4: current parser token ';'
   

2.  ../../src/obf.h:52:1: parsing namespace 'ithare'
   

3.  ../../src/obf.h:53:2: parsing namespace 'ithare::obf'
   

4.  ../../src/obf.h:407:2: parsing struct/union/class body 'ithare::obf::obf_str_literal'
   

Abort trap

Minimizing your test case gives:

// clang -cc1 -triple x86_64 -S -std=c++11 official-minimized.cpp
typedef int a;
typedef int b;
template <class c, int d> struct array { c e[d]; };
using f = int;
struct g {
bool h;
f i;
b j;
constexpr g(bool, f, b) : h(), i(), j() {}
};
template struct k {
static constexpr a l = 4;
constexpr static array<g, 8> m{g(true, 0, 0), g(true, 0, 0), g(true, 0, 0),
g(true, 0, 0), g(true, 0, 0), g(true, 0, 0),
g(true, 0, 0), g(l)};
};

I don't know where this assertion got introduced, though. This will need some bisection.

Still, it would be good to report this bug separately on Apple's bug reporter.

[DimitryAndric]

Bisection shows that the minimized test case worked without any errors until at least https://reviews.llvm.org/rL306325, then from https://reviews.llvm.org/rL306327 ("Check that the initializer of a non-dependent constexpr variable is constant even within templates") onwards, it started giving:

official-minimized.cpp:14:32: error: constexpr variable 'm' must be initialized by a constant expression
constexpr static array<g, 8> m{g(true, 0, 0), g(true, 0, 0), g(true, 0, 0),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

However, after https://reviews.llvm.org/rL306346 ("Revert r301742, which caused us to try to evaluate all full-expressions"), it started asserting:

Assertion failed: (!E->isValueDependent()), function EvaluateInPlace, file /home/dim/src/llvm/llvm-project-20170507/clang/lib/AST/ExprConstant.cpp, line 9891.

And it still asserts with top-of-trunk as of 2018-01-24. Adding Richard on CC, who is the author of r306346.

[zygoloid]

Fixed in r324537.

[zmodem]

Fixed in r324537.

Do you think we should merge it to 6.0?

[DimitryAndric]

Fixed in r324537.

Do you think we should merge it to 6.0?

Would certainly be nice, as the assertion is a regression from 5.0.

[zygoloid]

The particular symptom is a regression, but every prior version of Clang has produced a broken AST for that code. Regardless, yes, let's take this fix for clang 6; it's low risk and fixes a subtle but nasty bug.

[zmodem]

The particular symptom is a regression, but every prior version of Clang has
produced a broken AST for that code. Regardless, yes, let's take this fix
for clang 6; it's low risk and fixes a subtle but nasty bug.

Merged in r324719.

[zygoloid]

*** Bug llvm/llvm-bugzilla-archive#36333 has been marked as a duplicate of this bug. ***

[zygoloid]

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