assertion: Invalid scalar expression to emit in CGExprScalar

[Quuxplusone]

Bugzilla Link	PR16644
Status	NEW
Importance	P normal
Reported by	Hannes Landeholm (hannes@jumpstarter.io)
Reported on	2013-07-17 09:23:07 -0700
Last modified on	2013-09-25 08:54:09 -0700
Version	trunk
Hardware	PC Linux
CC	baldrick@free.fr, efriedma@quicinc.com, llvm-bugs@lists.llvm.org, marceloabsousa@gmail.com, mcurtis@codeaurora.org, nlewycky@google.com, rafael@espindo.la
Fixed by commit(s)
Attachments
Blocks
Blocked by
See also

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.      <eof> 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.

[Quuxplusone]

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 -

[Quuxplusone]

(In reply to comment #1)
> 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)

[Quuxplusone]

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.

[Quuxplusone]

(In reply to comment #3)
> 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.

[Quuxplusone]

(In reply to comment #4)
> (In reply to comment #3)
> > 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.      <eof> 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.

[Quuxplusone]

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?

[Quuxplusone]

(In reply to comment #6)
> 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 - 2*sizeof(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

[Quuxplusone]

(In reply to comment #6)

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.

[Quuxplusone]

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,
  };
}

[Quuxplusone]

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.

[Quuxplusone]

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.

[Quuxplusone]

(In reply to comment #11)
> 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.

[Quuxplusone]

_Bug 17210 has been marked as a duplicate of this bug._