assertion: Invalid scalar expression to emit in CGExprScalar

[llvmbot]

Bugzilla Link	16644
Version	trunk
OS	Linux
Reporter	LLVM Bugzilla Contributor
CC	@efriedma-quic

Extended Description

It crashed with the Ubuntu release of llvm/clang so I compiled the trunk instead and got this.

The project is a C program. Unfortunately the source code is proprietary so I cannot paste the include file. Building with debug works but it appears the SROA pass crashes clang. Instructions on how to manually disable this pass would be a helpful workaround.

==========================================================================================

0 clang-3.4 0x0000000001becf94 llvm::sys::PrintStackTrace(_IO_FILE) + 38 1 clang-3.4 0x0000000001bed21b 2 clang-3.4 0x0000000001becc56 3 libpthread.so.0 0x00007f39796e3bd0 4 clang-3.4 0x0000000000ca7046 5 clang-3.4 0x0000000001ad3f7c llvm::PointerType::get(llvm::Type, unsigned int) + 28 6 clang-3.4 0x0000000000ed57b9 7 clang-3.4 0x0000000000ed5873 8 clang-3.4 0x0000000000ed574d 9 clang-3.4 0x0000000000efd337 10 clang-3.4 0x0000000002ca01b2 11 clang-3.4 0x0000000002c9d0fc 12 clang-3.4 0x0000000002ca128e 13 clang-3.4 0x0000000002ca1566 14 clang-3.4 0x0000000002c9d343 15 clang-3.4 0x0000000002ca644f 16 clang-3.4 0x0000000002ca37a3 17 clang-3.4 0x0000000002ca0ba5 18 clang-3.4 0x0000000002c9cbb7 19 clang-3.4 0x0000000002c9e41e 20 clang-3.4 0x0000000002c9ed7f 21 clang-3.4 0x0000000001ac109a llvm::FPPassManager::runOnFunction(llvm::Function&) + 382 22 clang-3.4 0x0000000001ac0de4 llvm::FunctionPassManagerImpl::run(llvm::Function&) + 84 23 clang-3.4 0x0000000001ac09e2 llvm::FunctionPassManager::run(llvm::Function&) + 180 24 clang-3.4 0x0000000001c24d2a 25 clang-3.4 0x0000000001c24f00 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::Module, clang::BackendAction, llvm::raw_ostream) + 136 26 clang-3.4 0x0000000001c20a9c 27 clang-3.4 0x0000000001f95fbf clang::ParseAST(clang::Sema&, bool, bool) + 785 28 clang-3.4 0x0000000001ea406a clang::ASTFrontendAction::ExecuteAction() + 298 29 clang-3.4 0x0000000001c1fa74 clang::CodeGenAction::ExecuteAction() + 1414 30 clang-3.4 0x0000000001ea3bc0 clang::FrontendAction::Execute() + 200 31 clang-3.4 0x0000000001e7dcf8 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 564 32 clang-3.4 0x0000000001bf1ac5 clang::ExecuteCompilerInvocation(clang::CompilerInstance) + 1012 33 clang-3.4 0x0000000000c58f37 cc1_main(char const, char const, char const, void*) + 717 34 clang-3.4 0x0000000000c52fd1 main + 523 35 libc.so.6 0x00007f3978b0fea5 __libc_start_main + 245 36 clang-3.4 0x0000000000c51739 Stack dump:

0. Program arguments: /usr/local/bin/clang-3.4 -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free -disable-llvm-verifier -main-file-name src_lwthreads.i -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 /redacted/src_lwthreads.o -resource-dir /usr/local/bin/../lib/clang/3.4 -O1 -Werror -std=c99 -fdebug-compilation-dir /redacted/oc-init -ferror-limit 19 -fmessage-length 0 -mstackrealign -fobjc-runtime=gcc -fobjc-default-synthesize-properties -fdiagnostics-show-option -vectorize-loops -fcolor-diagnostics -o /redacted/src_lwthreads.o -x cpp-output /redacted/src_lwthreads.i
1. parser at end of file
2. Per-function optimization
3. Running pass 'SROA' on function '@lwt_sigtkill_thread' 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 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. clang-3.4: note: diagnostic msg: Error generating preprocessed source(s) - no preprocessable inputs.

[TNorthover]

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

[TNorthover]

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

[llvmbot]

The standard isn't entirely clear on what to do with something like this:

union U { struct A { char x[2]; } a; struct B { char y[2]; } b; }; union U a = { .b.y[1] = '2', .a.x[0] = '1' };

gcc's behavior is to treat this as equivalent to "{ { '1', '\0' } }", which is probably the most reasonable interpretation.

I didn't even realize that I was initializing two different union members at once because the glibc macros was hiding it. A compiler warning or error had been helpful since that doesn't make sense.

[efriedma-quic]

The standard isn't entirely clear on what to do with something like this:

union U { struct A { char x[2]; } a; struct B { char y[2]; } b; }; union U a = { .b.y[1] = '2', .a.x[0] = '1' };

gcc's behavior is to treat this as equivalent to "{ { '1', '\0' } }", which is probably the most reasonable interpretation.

[llvmbot]

I found a workaround in the meantime. The bug is not triggered when I initialize the struct to {0} and then initialize the fields one by one in separate expressions.

[llvmbot]

It reproduces. The bug will be updated when there's a fix upstream.

Further reduced:

union sigval { int sival_int; };

struct siginfo { union { struct { int si_uid; union sigval si_sigval; } rt; struct { int si_pid; long si_stime; } sigchld; }; };

void lwt_sigtkill_thread(int x) { struct siginfo w = { .__sigchld.si_pid = x, .__rt.si_sigval = 0, }; }

[llvmbot]

It would be nice if you could tell me when there is a fix for this so I can compile again. The 3.2 release is too old for what I'm working on. The 3.3 release has problematic DWARF bugs that starting to appear april/june-ish which breaks struct debug information so I want to stay on the trunk so I can get the fix immediately. Also I want to know if reproducing the problem works on your end or if I need to create another test case.

[llvmbot]

Since the source code is proprietary you'll need to reduce the testcase for us. Sorry!

Please use a tool like delta http://delta.tigris.org or c-reduce http://embed.cs.utah.edu/creduce on the preprocessed C program and narrow down the crash to the smallest possible input (you may need to run the tool again on its output after the first round). Once it's below 100 lines it should be small enough that you can extract anything that looks proprietary by hand.

Or we can try building up a testcase instead of taking yours and stripping it down (or both in parallel). Can you run clang under gdb? Note that clang exec's itself and gdb normally follows the parent. Run 'clang -v' to get the 'clang -cc1 ...' command it would run and gdb that one. From there we can examine the failing expression, "print E->getType()" and "call E->dump()". Can you show us the (preprocessed) declaration of lwt_sigtkill_thread?

I can reproduce the problem with this minimal include file:

========================================

typedef unsigned long size_t;

typedef int int32_t;

typedef int uid_t; typedef int pid_t;

typedef long clock_t;

typedef struct siginfo siginfo_t;

union sigval { int sival_int; void *sival_ptr; };

struct siginfo { int si_signo, si_errno, si_code; union { char pad[128 - 2sizeof(int) - sizeof(long)]; struct { pid_t si_pid; uid_t si_uid; union sigval si_sigval; } rt; struct { unsigned int si_timer1, si_timer2; } timer; struct { pid_t si_pid; uid_t si_uid; int si_status; clock_t si_utime, si_stime; } __sigchld; struct { void si_addr; } sigfault; struct { long si_band; int si_fd; } sigpoll; } si_fields; };

pid_t getpid();

uid_t getuid();

void lwt_sigtkill_thread(int32_t x, int32_t y, union sigval z) { int32_t w = getpid(); siginfo_t w2 = { .si_signo = y, .si_code = (-1), .si_fields.__sigchld.si_pid = w, .si_fields.sigchld.si_uid = getuid(), .__si_fields.rt.si_sigval = z, }; }

========================================

This is the command line I use:

/usr/local/bin/clang -Xclang -fcolor-diagnostics -Qunused-arguments -x cpp-output -nostdlib -g -std=c99 -Werror -O1 -o mini.o -c mini.i

[llvmbot]

Since the source code is proprietary you'll need to reduce the testcase for us. Sorry!

Please use a tool like delta http://delta.tigris.org or c-reduce http://embed.cs.utah.edu/creduce on the preprocessed C program and narrow down the crash to the smallest possible input (you may need to run the tool again on its output after the first round). Once it's below 100 lines it should be small enough that you can extract anything that looks proprietary by hand.

Or we can try building up a testcase instead of taking yours and stripping it down (or both in parallel). Can you run clang under gdb? Note that clang exec's itself and gdb normally follows the parent. Run 'clang -v' to get the 'clang -cc1 ...' command it would run and gdb that one. From there we can examine the failing expression, "print E->getType()" and "call E->dump()". Can you show us the (preprocessed) declaration of lwt_sigtkill_thread?

[llvmbot]

OK, this means the problem is that clang is producing invalid IR. If feed invalid IR, it is to be expected that optimizers like SROA crash. I suggest you build clang with assertions enabled to track down better what is going wrong inside clang.

I use RelWithDebInfo which should enable assertions. I also tried CMAKE_BUILD_TYPE:STRING=Debug and got the exact same crash.

NVM, I must have compiled or installed it incorrectly. I finally got a good debug build with assertions working and got a different crash.

clang-3.4: /redacted/libs/llvm/tools/clang/lib/CodeGen/CGExprScalar.cpp:3184: llvm::Value clang::CodeGen::CodeGenFunction::EmitScalarExpr(const clang::Expr, bool): Assertion `E && hasScalarEvaluationKind(E-> getType()) && "Invalid scalar expression to emit"' failed. 0 clang-3.4 0x0000000001d26a7e llvm::sys::PrintStackTrace(_IO_FILE) + 38 1 clang-3.4 0x0000000001d26d05 2 clang-3.4 0x0000000001d26740 3 libpthread.so.0 0x00007f8f43bcdbd0 4 libc.so.6 0x00007f8f4300f037 gsignal + 55 5 libc.so.6 0x00007f8f43012698 abort + 328 6 libc.so.6 0x00007f8f43007e03 7 libc.so.6 0x00007f8f43007eb2 8 clang-3.4 0x0000000001eedb27 clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const, bool) + 89 9 clang-3.4 0x0000000001e86f55 clang::CodeGen::CodeGenFunction::EmitScalarInit(clang::Expr const, clang::ValueDecl const, clang::CodeGen::LValue, bool) + 99 10 clang-3.4 0x0000000001eb73ca 11 clang-3.4 0x0000000001eb7f8b 12 clang-3.4 0x0000000001eb9dd5 13 clang-3.4 0x0000000001eb8a47 clang::CodeGen::CodeGenFunction::EmitAggExpr(clang::Expr const, clang::CodeGen::AggValueSlot) + 225 14 clang-3.4 0x0000000001eb7335 15 clang-3.4 0x0000000001eb7c44 16 clang-3.4 0x0000000001eb9dd5 17 clang-3.4 0x0000000001eb8a47 clang::CodeGen::CodeGenFunction::EmitAggExpr(clang::Expr const, clang::CodeGen::AggValueSlot) + 225 18 clang-3.4 0x0000000001eb7335 19 clang-3.4 0x0000000001eb7f8b 20 clang-3.4 0x0000000001eb9dd5 21 clang-3.4 0x0000000001eb8a47 clang::CodeGen::CodeGenFunction::EmitAggExpr(clang::Expr const, clang::CodeGen::AggValueSlot) + 225 22 clang-3.4 0x0000000001e89951 clang::CodeGen::CodeGenFunction::EmitExprAsInit(clang::Expr const, clang::ValueDecl const, clang::CodeGen::LValue, bool) + 899 23 clang-3.4 0x0000000001e89085 clang::CodeGen::CodeGenFunction::EmitAutoVarInit(clang::CodeGen::CodeGenFunction::AutoVarEmission const&) + 807 24 clang-3.4 0x0000000001e87e7c clang::CodeGen::CodeGenFunction::EmitAutoVarDecl(clang::VarDecl const&) + 58 25 clang-3.4 0x0000000001e85420 clang::CodeGen::CodeGenFunction::EmitVarDecl(clang::VarDecl const&) + 238 26 clang-3.4 0x0000000001e852d7 clang::CodeGen::CodeGenFunction::EmitDecl(clang::Decl const&) + 367 27 clang-3.4 0x0000000001d9c923 clang::CodeGen::CodeGenFunction::EmitDeclStmt(clang::DeclStmt const&) + 107 28 clang-3.4 0x0000000001d99ce5 clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const) + 265 29 clang-3.4 0x0000000001d997a7 clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const) + 73 30 clang-3.4 0x0000000001d99f5f clang::CodeGen::CodeGenFunction::EmitCompoundStmtWithoutScope(clang::CompoundStmt const&, bool, clang::CodeGen::AggValueSlot) + 103 31 clang-3.4 0x0000000001db5c6b clang::CodeGen::CodeGenFunction::EmitFunctionBody(clang::CodeGen::FunctionArgList&) + 217 32 clang-3.4 0x0000000001db62aa clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl, llvm::Function, clang::CodeGen::CGFunctionInfo const&) + 1260 33 clang-3.4 0x0000000001dc7bd9 clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl) + 943 34 clang-3.4 0x0000000001dc528d clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl) + 395 35 clang-3.4 0x0000000001dc3b23 clang::CodeGen::CodeGenModule::EmitDeferred() + 341 36 clang-3.4 0x0000000001dc0b4d clang::CodeGen::CodeGenModule::Release() + 25 37 clang-3.4 0x0000000001d5ee11 38 clang-3.4 0x0000000001d5db10 39 clang-3.4 0x0000000002108633 clang::ParseAST(clang::Sema&, bool, bool) + 785 40 clang-3.4 0x000000000200a798 clang::ASTFrontendAction::ExecuteAction() + 298 41 clang-3.4 0x0000000001d5ca9a clang::CodeGenAction::ExecuteAction() + 1414 42 clang-3.4 0x000000000200a2ee clang::FrontendAction::Execute() + 200 43 clang-3.4 0x0000000001fe3a46 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 720 44 clang-3.4 0x0000000001d2ba19 clang::ExecuteCompilerInvocation(clang::CompilerInstance) + 1012 45 clang-3.4 0x0000000000c71873 cc1_main(char const, char const, char const, void*) + 717 46 clang-3.4 0x0000000000c6b321 main + 523 47 libc.so.6 0x00007f8f42ff9ea5 __libc_start_main + 245 48 clang-3.4 0x0000000000c69a89 Stack dump:

0. Program arguments: /usr/local/bin/clang-3.4 -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name src_lwthreads.i -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 /redacted/src_lwthreads.o -resource-dir /usr/local/bin/../lib/clang/3.4 -O1 -Werror -std=c99 -fdebug-compilation-dir /redacted/oc-init -ferror-limit 19 -fmessage-length 0 -mstackrealign -fobjc-runtime=gcc -fobjc-default-synthesize-properties -f diagnostics-show-option -vectorize-loops -fcolor-diagnostics -o /redacted/src_lwthreads.o -x cpp-output /redacted/src_lwthreads.i
1. parser at end of file
2. Per-file LLVM IR generation
3. lwthreads.c:398:16: Generating code for declaration 'lwt_sigtkill_thread' clang-3.4: error: unable to execute command: Aborted (core dumped) clang-3.4: error: clang frontend command failed due to signal (use -v to see invocation) clang version 3.4 Target: x86_64-unknown-linux-gnu Thread model: posix clang-3.4: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. clang-3.4: note: diagnostic msg: Error generating preprocessed source(s) - no preprocessable inputs.

[llvmbot]

OK, this means the problem is that clang is producing invalid IR. If feed invalid IR, it is to be expected that optimizers like SROA crash. I suggest you build clang with assertions enabled to track down better what is going wrong inside clang.

I use RelWithDebInfo which should enable assertions. I also tried CMAKE_BUILD_TYPE:STRING=Debug and got the exact same crash.

[llvmbot]

OK, this means the problem is that clang is producing invalid IR. If feed invalid IR, it is to be expected that optimizers like SROA crash. I suggest you build clang with assertions enabled to track down better what is going wrong inside clang.

[llvmbot]

You can produce a testcase like this: execute the clang command line as usual but append the following: -mllvm -disable-llvm-optzns -emit-llvm

Attach the output (the .o or .s file) to this bug report. If you are worried about leaking information, you can obfuscate all names by doing the following: opt -metarenamer file -o obfuscated.bc where file is the .o or the .s file, and attach obfuscated.bc instead. You can look inside obfuscated.bc, to check what you are attaching, by doing: llvm-dis obfuscated.bc -o -

Running the opt command gives me:

Stored value type does not match pointer operand type! store %struct.spam.19 %tmp23, i32 %tmp22, align 4, !dbg !​2505, !tbaa !​2499 i32Broken module found, compilation aborted! 0 opt 0x0000000001817304 llvm::sys::PrintStackTrace(_IO_FILE) + 38 1 opt 0x000000000181758b 2 opt 0x0000000001816fc6 3 libpthread.so.0 0x00007fd8753f7bd0 4 libc.so.6 0x00007fd874839037 gsignal + 55 5 libc.so.6 0x00007fd87483c698 abort + 328 6 opt 0x000000000170804d 7 opt 0x0000000001707d83 8 opt 0x00000000016e9d26 llvm::FPPassManager::runOnFunction(llvm::Function&) + 382 9 opt 0x00000000016e9f14 llvm::FPPassManager::runOnModule(llvm::Module&) + 84 10 opt 0x00000000016ea23b llvm::MPPassManager::runOnModule(llvm::Module&) + 505 11 opt 0x00000000016ea761 llvm::PassManagerImpl::run(llvm::Module&) + 249 12 opt 0x00000000016ea973 llvm::PassManager::run(llvm::Module&) + 39 13 opt 0x00000000009005e5 main + 5700 14 libc.so.6 0x00007fd874823ea5 __libc_start_main + 245 15 opt 0x00000000008f2e29 Stack dump:

0. Program arguments: opt -metarenamer out.o -o obfuscated.bc
1. Running pass 'Function Pass Manager' on module 'out.o'.
2. Running pass 'Module Verifier' on function '@snork386' fish: Job 1, “opt -metarenamer out.o -o obfuscated.bc” terminated by signal SIGABRT (Abort)

[llvmbot]

You can produce a testcase like this: execute the clang command line as usual but append the following: -mllvm -disable-llvm-optzns -emit-llvm

Attach the output (the .o or .s file) to this bug report. If you are worried about leaking information, you can obfuscate all names by doing the following: opt -metarenamer file -o obfuscated.bc where file is the .o or the .s file, and attach obfuscated.bc instead. You can look inside obfuscated.bc, to check what you are attaching, by doing: llvm-dis obfuscated.bc -o -

[Endilll]

Both reductions appear to be fixed in Clang 3.4: https://godbolt.org/z/MM5hfKnc7 https://godbolt.org/z/MjGnqr8x9

[Endilll]

CC @AaronBallman