Unable to compile llvm bc emitted from rustc

[nickdesaulniers]

Using this example file, compile with: rustc --emit-llvm hello_world.rs to get llvm-ir in bitcode. Compile the bitcode with emcc hello_world.bc. Trying to compile the emitted bitcode with emscripten fails and produces this stack trace.

[nickdesaulniers]

Here's the ir generated from the bc using llvm-dis hello_world.bc -o hello_world.ll.

[nickdesaulniers]

I updated emcc, but am still failing during the same compilation step, but with a new error this time.

[nickdesaulniers]

Also, I'm running llvm 4.2 instead of 3.2, which may be the problem?

[int3]

I get a slightly different error with 3.2:

undefined:191
          while (tokens[openBrace].text.substr(-1) != '{') openBrace --;
                              ^
TypeError: Cannot read property 'text' of undefined

[nickdesaulniers]

@int3 that's the same error.

[int3]

Ah right. I'd only looked at the first stack trace.

[int3]

So the problem is that we don't support pointers to separate address spaces. The current stack trace is due to the lexer not knowing how to parse the addrspace token; that's easy enough to fix, but implementing the semantics will require more investigation.

[kripken]

Do we know why rust generates code using multiple address spaces?

[int3]

@nickdesaulniers mentioned today that the use of multiple address spaces is being phased out, so I guess this is now a non-issue.

[nickdesaulniers]

Yes, it was part of the old gc. There's an open issue to remove it.

[int3]

Now that addrspace has been fixed, the compile step runs to completion, but trying to run the JS throws a parse error. Apparently we're creating invalid syntax when generating the memory initializer; in particular, we seem to be generating too many [ braces and no matching ]. It looks like ptrtoint is not being handled correctly; processMathop in parseTools.js calls makeI64 to handle the ptrtoint, but instead of passing it two ints, it passes a string and an int instead.

Here's the bitcode.

[kripken]

First issue I see is that this is

target triple = "x86_64-apple-darwin"

which means it has 64-bit pointers and ptrtoints and such, which we can't handle. We need LLVM to emit one of the targets we expect, preferably le32-unknown-nacl.

[stale]

This issue has been automatically marked as stale because there has been no activity in the past 2 years. It will be closed automatically if no further activity occurs in the next 7 days. Feel free to re-open at any time if this issue is still relevant.