Derek Schuff

I don't think we want to take non-JS engine support into account for Emscripten though. Not that we want to leave anything behind on purpose but it's complicated enough as...

We do get requests for support in targeting non-web JS environments such as node, Electron, and weird web environments like webviews, old environments like TVs, etc. Those are not the...

LGTM, but it's possible that #390 will land soon, which would also cover this. so maybe let's hold off for a couple of days and maybe we won't need this...

Generally speaking, I like the idea of ABIs being specifiable per-function. I think this is similar to what you can do on ARM with all the various ABIs that use...

The CPU target needs to match; In your case you compiled one module targeting x86_64-unkown-linux-gnu whereas Emscripten by default uses asmjs-unknown-emscripten. Support for that target is one of the modifications...

It might be straightforward to e.g. "just" include flang with emscripten's build of LLVM, but would that be enough to be useful? What about runtime libraries? What else would be...

A new proposal has been started that covers this: https://github.com/WebAssembly/128-bit-arithmetic The use cases for arithmetic with carry are in-scope for the proposal (despite the limited-sounding name).

@tabatkins maybe you can give some insight on what might be happening? I'm happy to send you a full reproducer or chat offline.

It's odd actually, because there are a lot of instances of `\[` in the document, and they don't get touched. There are also instances such as `... \phantom{thisshouldbeenough} \\[-2ex] &&|&`...

Also, applying the escape sequence above works perfectly for the ` \\[1ex]` sequences (i.e. replace them with `\\\[1ex]` in the source)... but doing the same for the ` \\[-2ex]` sequences...