#9125: int-to-float conversion broken on ARM -------------------------------------+------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: infoneeded Priority: highest | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 (CodeGen) | Keywords: Resolution: | Architecture: arm Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): The Cmm code is fine. As far as I can tell, the .ll file is mostly fine except we do write to a memory location (the original Sp - 4) using TBAA metadata 1 and then later read from the same memory location (and LLVM knows it) using TBAA metadata 5. I lost my disassembly of the object file but it is wrong in a similar way to the assembly I annotated above: LLVM coalesces this store and read to a register move, presumably because it thinks for some reason that the intervening function call can not modify the memory. I don't see why it would assume this, but then again we did tell it via TBAA that two memory accesses would not alias that are in fact to the same address, so I suppose it is within its rights to do anything. amurrayc, can you try with this patch applied (effectively reverting e10589a505b44f4f0394500c6a0d2db5baa7f3f4): {{{ diff --git a/compiler/llvmGen/LlvmCodeGen/Regs.hs b/compiler/llvmGen/LlvmCodeGen/Regs.hs index 0048659..d837d13 100644 --- a/compiler/llvmGen/LlvmCodeGen/Regs.hs +++ b/compiler/llvmGen/LlvmCodeGen/Regs.hs @@ -101,11 +101,6 @@ stgTBAA , (heapN, fsLit "heap", Just topN) , (rxN, fsLit "rx", Just heapN) , (baseN, fsLit "base", Just topN) - -- FIX: Not 100% sure about 'others' place. Might need to be under 'heap'. - -- OR I think the big thing is Sp is never aliased, so might want - -- to change the hieracy to have Sp on its own branch that is never - -- aliased (e.g never use top as a TBAA node). - , (otherN, fsLit "other", Just topN) ] -- | Id values @@ -115,7 +110,7 @@ stackN = getUnique (fsLit "LlvmCodeGen.Regs.stackN") heapN = getUnique (fsLit "LlvmCodeGen.Regs.heapN") rxN = getUnique (fsLit "LlvmCodeGen.Regs.rxN") baseN = getUnique (fsLit "LlvmCodeGen.Regs.baseN") -otherN = getUnique (fsLit "LlvmCodeGen.Regs.otherN") +otherN = topN -- | The TBAA metadata identifier tbaa :: LMString }}} If you can try a newer version of LLVM like 3.4, that would be great also. That version is newer than the admonitions to use 3.0 on the wiki page, so it's possible the LLVM bugs have been worked out in 3.4. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9125#comment:23 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler