#12095: GHC and LLVM don't agree on what to do with byteSwap16# -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler (LLVM) | Version: 8.0.1 Resolution: | Keywords: codegen, llvm Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thoughtpolice): So you're right, and the answer with a little more detail is outlined in this commit in `binary-serialise-cbor`: https://github.com/well-typed /binary-serialise-cbor/commit/d419bdeae39e56531a86d8208e059967863cffb5 if you want to read the novel about the LLVM view of things. But something about this ticket still makes me feel uneasy. In particular, is there ever any reason why the `byteSwap#` primitives do not imply such narrowing themselves? Are the high bits always undefined even if they were set before? Why does it imply that - because it can't be guaranteed on every platform? (e.g. on x86 I believe should be able to do a 16-byte swap with simply `xchg ah, al` which should not modify the high 16 bits, that's legitimate). Obviously not every primitive can be safe (if it pokes memory or whatever), but I'm strongly in favor of having sensible behavior for operators like this which are merely 'bit fiddling' wrapped up in a single MachOp, as opposed to leaving them to have 'undefined behavior' like in C which is just a cue for clever compilers to torment me more than they need to. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12095#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler