DannyBee, it is you who are demonstrating considerable misunderstanding here (and in other posts here).
To respond to your comments in this post, the asm.js validator is not checking for undefined behavior. In fact, it has nothing to do with undefined behavior whatsoever. It also has nothing to do with decidability. It is merely determining which execution strategy to use. And, behaving according to a spec is actually a pretty ordinary definition of "defined behavior".
You have misunderstood how asm.js works, you have misunderstood other people's comments, and you have mischaractarized LLVM in other posts here. I know you're capable of much higher-quality discussion than this. Please take a moment to reflect.
"To respond to your comments in this post, the asm.js validator is not checking for undefined behavior."
So let's start simple:
asm.js's validator does in fact, statically try to decide asm.js spec conformance. That means it is checking for undefined behavior, since it is checking whether the program meets the language specification, and the language spec disallows various undefined behavior. I'm not sure how you could characterize it as anything else, when the spec itself says this is what it does:
"This sublanguage effectively describes a safe virtual machine for memory-unsafe languages like C or C++. A combination of static and dynamic validation allows JavaScript engines to employ an ahead-of-time (AOT) optimizing compilation strategy for valid asm.js code."
Note: it says it uses static and dynamic checking to validate spec conformance. It also claims it is safe. Such claims and static program validation of any sufficiently complex language, like asm.js, involves decidability issues and issues about undefined behavior. Period. If you disbelieve this, all I can suggest is delving into the field of program validation and static analysis. I completely understand the cases it cannot validate fall back to normal javascript engine execution, but that actually changes exactly nothing about what the validation is doing, the language specification, undefined behavior, whether it has fundamental limitations, etc.
"You have misunderstood how asm.js works, you have misunderstood other people's comments, and you have mischaractarized LLVM in other posts here. "
I disagree that I have done anything of the sort.
Starting from the last, I have not mischaracterized LLVM in any way.
What I see here is a discussion with people who are trying to make very imprecise comments about very precise technical specifications and definitions, and then argue about them. I feel like i'm trying to argue physics with a bunch of chemists. It's not that they aren't smart, it's that they are abusing terminology and trying to make nonsense out of very well understood issues in the field.
In fact, i don't believe anyone working in the compiler field (even on asm.js) would disagree with anything i've said, because as far as I can tell, they understand these are all issues, and try to stay away from ridiculous claims about competitors.
pcwalton originally made some very direct claims about LLVM's IR, and asm.js. I have pointed out they are directly false. That is not mischaracterizing LLVM, or asm.js. It is in fact, a response to such mischaracterizations. Out of kindness, I did not originally point out that a very trivial reading of any paper on LLVM, it's bitcode, or the IR, would have shown that his claims are false, and instead responded directly. The very first LLVM paper ever written even covers exactly the claim he makes about portability, platform independence, and specificity. He would not have had to look very far on the website to find a refutation.
I actually have no real love for either (they are both a set of engineering tradeoffs). I just cannot stand to see one side or the other pretend that the other side is completely horrible, and that they have chosen "the one true path". I am also not going to watch one side or the other make claims that are simply false in an attempt to support that path.
In any case, i'm not going to argue about it anymore here, as it is a mild exercise in futility. You are welcome to believe what you like about asm.js and LLVM, and their relative merits.
To respond to your comments in this post, the asm.js validator is not checking for undefined behavior. In fact, it has nothing to do with undefined behavior whatsoever. It also has nothing to do with decidability. It is merely determining which execution strategy to use. And, behaving according to a spec is actually a pretty ordinary definition of "defined behavior".
You have misunderstood how asm.js works, you have misunderstood other people's comments, and you have mischaractarized LLVM in other posts here. I know you're capable of much higher-quality discussion than this. Please take a moment to reflect.