#9125: int-to-float conversion broken on ARM - 7.8.1-rc2 ------------------------------------------------+-------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Incorrect result at runtime | Difficulty: Test Case: | Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by amurrayc): I have the same problem on iOS (simulator or device) with 7.8.2 or 7.8.3 compiled from source tarballs. I'm not sure if it should be a separate ticket. I don't think this is an `Integer` to `Float` problem per se. If I run {{{ print (F# 29.0#) -- to pick a value at random }}} I get {{{ 2109.0 }}} as in the original ticket. This should be using a direct `Float` literal, no? A little digging showed that {{{ print (floor (29.0 :: Float) :: Int) }}} shows {{{ 2109 }}} with no optimisation, but {{{ 29 }}} with `-O` Another clue is that `floor :: Float -> Integer` doesn't give the correct result, even with `-O`. Optimised `floor :: Float -> Int` uses the primop `float2Int#` while its unoptimised version and both versions of `floor :: Float -> Integer` use `decodeFloat_Int#` as does `show :: Float -> String` which last explains the original ticket. running {{{ let (m,e) = decodeFloat (29.0 :: Float) mstr = printf "%#x" m putStrLn $ "(" ++ mstr ++ ", " ++ show e ++ ")" }}} gives {{{ (0x41e80000, -19) }}} instead of the correct {{{ (0xe80000, -19) }}} Notably the erroneous `0x41e80000` is the correct value for the entire bitfield of `29.0 :: Float#` rather than just the mantissa. This all suggests that the problem lies within `decodeFloat_Int#`. I looked at `__decodeFloat_Int` in `rts/StgPrimFloat.c`, even inserting a couple of `assert`s at the end to check the values for 29.0 which passed. That led me to look at `stg_decodeFloatzuIntzh` in `rts/PrimOps.cmm` but at that point I was getting a bit lost. Any ideas anyone? For the record I'm running the above snippets in a simple Haskell `Main.hs` like: {{{ {-# LANGUAGE ForeignFunctionInterface #-} module Main where import Foreign import Text.Printf ( printf ) foreign import ccall safe "c_main" c_main :: IO () main = do let (m,e) = decodeFloat (29.0 :: Float) mstr = printf "%#x" m putStrLn $ "(" ++ mstr ++ ", " ++ show e ++ ")" c_main }}} with a skeleton Xcode 5.1.1 project and observing the results in the debug window. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9125#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9125: int-to-float conversion broken on ARM - 7.8.1-rc2 ------------------------------------------------+-------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Incorrect result at runtime | Difficulty: Test Case: | Unknown Blocking: | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by simonpj): * priority: normal => highest * milestone: => 7.8.4 Comment: I have not tried to reproduce any of this, but it looks like a solid, well-characterised bug to me. Could anyone spare the time to investigate, please? Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9125#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9125: int-to-float conversion broken on ARM -------------------------------------+------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: arm | Type of failure: Incorrect result Difficulty: Unknown | at runtime Blocked By: | Test Case: Related Tickets: | Blocking: -------------------------------------+------------------------------------- Comment (by amurrayc): So here's a thing: On a hunch I switched the assignments of `r1` and `r2` in `stg_decodeFloatzuIntzh` so that it now reads {{{ r2 = W_[mp_tmp1]; r1 = W_[mp_tmp_w]; }}} with everything else the same. What do you know, {{{ let (m,e) = decodeFloat (29.0 :: Float) estr = printf "%#x" e putStrLn $ "(" ++ show m ++ ", " ++ estr ++ ")" }}} gives {{{ (-19, 0xe80000) }}} Does that give anyone any clues? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9125#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9125: int-to-float conversion broken on ARM -------------------------------------+------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Differential Revisions: | Operating System: Unknown/Multiple Architecture: arm | Type of failure: Incorrect result Difficulty: Unknown | at runtime Blocked By: | Test Case: Related Tickets: | Blocking: -------------------------------------+------------------------------------- Changes (by bgamari): * cc: bgamari@… (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9125#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9125: int-to-float conversion broken on ARM -------------------------------------+------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.4 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: arm Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Here is the disassembly of `stg_decodeFloatzuIntzh` from that build, annotated with my primitive understanding of ARM assembly. It's ... not right. {{{ 0000051c : 51c: e2450004 sub r0, r5, #4 ; r0 = Sp - 4 520: e2458008 sub r8, r5, #8 ; r8 = Sp - 8 -- r8 happens to be R2, but irrelevant for now 524: ed058a01 vstr s16, [r5, #-4] ; Sp[-4] = F1 -- Useless, and we haven't done the stack check yet! 528: e150000b cmp r0, fp 52c: 3a000007 bcc 550 ; if (Sp - 4 <= SpLim) goto gc; ; -- Not sure how it optimized Sp - 8 < SpLim to this, but looks correct. 530: eeb00a48 vmov.f32 s0, s16 ; s0 = F1 534: e1a01008 mov r1, r8 ; r1 = Sp - 8 ; -- At this point the args r0, r1, s0 are set up properly for the ccall. 538: ee187a10 vmov r7, s16 ; R1 = F1 ; -- Very odd! This is the only time we set R1, but it should be set to Sp[-4] ; -- after the ccall! 53c: ebfffffe bl 0 <__decodeFloat_Int> 53c: R_ARM_CALL __decodeFloat_Int ; ccall __decodeFloat_Int 540: e5988000 ldr r8, [r8] ; R2 = Sp[-8] -- good, but what about R1? 544: e5953000 ldr r3, [r5] ; r3 = Sp[0] -- return address 548: e12fff33 blx r3 54c: e12fff1e bx lr ; return to r3 (this sequence is odd but apparently harmless, and used everywhere) ; gc branch follows 550: e59f500c ldr r5, [pc, #12] ; 564 554: e5885000 str r5, [r8] 558: e1a05008 mov r5, r8 55c: ebfffffe bl 0 55c: R_ARM_CALL stg_gc_noregs 560: e12fff1e bx lr }}} May be a bug in GHC or LLVM. It would be nice to see the LLVM IR we output. What version of LLVM are you using, Ansible, amurrayc? I eyeballed the assembly for `__decodeFloat_Int` also and it appears correct at first glance. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9125#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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: | -------------------------------------+------------------------------------- Changes (by hvr): * cc: hvr, simonmar (added) * component: Compiler => Compiler (CodeGen) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9125#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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 bgamari): I think you will also need to add `-keep-llvm-files` to the command line as well. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9125#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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): I don't know whether this is the actual problem, but I think our TBAA is going wrong on this code. I tried to build GHC for Android with `-march=armv6`, so that it would use the floating point registers `s16` and so on. The build didn't finish for other reasons, but it got far enough to build `PrimOps.cmm`. Here is the `-ddump-cmm`: {{{ ==================== Post CPS Cmm ==================== [...] stg_decodeFloatzuIntzh() // [F1] { info_tbl: [] stack_info: arg_space: 0 updfr_space: Nothing } {offset c4w: F32[Sp - 4] = F1; Sp = Sp - 8; call block_c4o_info() args: 0, res: 0, upd: 0; } }, block_c4o_entry() // [] { info_tbl: [(c4o, label: block_c4o_info rep:StackRep [True])] stack_info: arg_space: 0 updfr_space: Nothing } {offset c4o: if ((Sp + 4) < SpLim) goto c4q; else goto c4r; c4q: I32[Sp] = block_c4o_info; call stg_gc_noregs() args: 4, res: 4, upd: 4; c4r: _c4k::I32 = Sp + 4; call "ccall" arg hints: [PtrHint, PtrHint,] result hints: [] __decodeFloat_Int(_c4k::I32, Sp, F32[Sp + 4]); R2 = I32[Sp]; R1 = I32[_c4k::I32]; Sp = Sp + 8; call (P32[Sp])(R2, R1) args: 4, res: 0, upd: 4; } }, }}} What's unusual about this is that R1 is read by dereferencing the variable `_c4k`, even though the address it points to lives on the stack. This violates the assumptions made by our TBAA: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM/Alia... And indeed, in the `.ll` file, the read of R2 is done using the "stack" type, but the read of R1 is done using the "other" type, which supposedly cannot alias the "stack" type. However, while it seems potentially relevant, I don't see specifically how this could cause our problem. (And my LLVM produced the correct assembly for `stg_decodeFloatzuIntzh`.) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9125#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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): Replying to [comment:16 amurrayc]:

Replying to [comment:9 rwbarton]:

As per the warning on https://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling/iOS I am using LLVM 3.0 binaries from http://llvm.org/releases/3.0/clang+llvm-3.0-x86_64-apple-darwin11.tar.gz

I can try recompiling with 3.5. Would it still be useful to have the -ddump-cmm? I just got back to my computer after a few days away but I could easily do that.

Let's figure out whether this is a bug in GHC or LLVM before we change any variables like the version of LLVM. I think LLVM 3.5 won't work with GHC 7.8 anyways. (Ben?) Yes, the -ddump-cmm output would still be useful. If you still have your built ghc tree, then you can follow the steps I listed above, skipping the first step. Thanks! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9125#comment:17 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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): Thanks. Actually, for completeness, can you attach your `rts/dist/build/PrimOps.o` too? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9125#comment:19 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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 bgamari): Replying to [comment:17 rwbarton]:

Let's figure out whether this is a bug in GHC or LLVM before we change any variables like the version of LLVM. I think LLVM 3.5 won't work with GHC 7.8 anyways. (Ben?)

Indeed LLVM 3.5 disagrees with the aliases that the LLVM backend produces (in all GHC versions as far as I know). This is being tracked in #9142 where you'll find a patch that I threw together to rework the LLVM code generator to comply with LLVM's new restrictions on alias usage. The patch works with LLVM 3.4 and should work for 3.5 although I'm still waiting for the build to finish to verify this. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9125#comment:21 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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): Replying to [comment:24 amurrayc]:

The patch didn't do anything (although I only applied it and re-`make && make install`-ed it. Should I have done a full `make clean && configure ...`?)

You don't need to rerun `configure`, but yeah you will need to rebuild the stage1 compiler so that it can rebuild the RTS correctly, and `make clean` is the easiest way.

However, LLVM 3.4 seems to work. It at least produces {{{ 29.0 }}} when fed {{{ main = print (29.0 :: Float) }}}

Well that's good to know, at least! I still think our TBAA information is wrong for this code, though. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9125#comment:25 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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): Curious. Would you mind extracting the `.cmm` and `.ll` and `.o` files in the same way as before, so I can make sure the patch is having the expected effect? If it is then I think we can declare this to be a bug in LLVM 3.0. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9125#comment:27 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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): Hopefully the `.cmm` and `.ll` files will be the same, but sure, let's have the 3.4 `.o` file too for the record. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9125#comment:29 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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): Actually I prefer this one, since I can read x86 assembly better than ARM assembly :) The TBAA patch had the expected effect on the .ll file. But LLVM 3.0 still decided to carefully save the input value across the function call so that it can erroneously return it as the result (esi). {{{ 00000748 83ec1c sub esp, 0x1c 0000074b 8d45fc lea eax, [ebp-4] 0000074e 3bab1c030000 cmp ebp, [ebx+0x31c] 00000754 7235 jc 0x78b 00000756 f30f104500 movss xmm0, [ebp] 0000075b f30f11442418 movss [esp+0x18], xmm0 00000761 f30f11442408 movss [esp+0x8], xmm0 00000767 89442404 mov [esp+0x4], eax 0000076b 892c24 mov [esp], ebp 0000076e e815faffff call __decodeFloat_Int 00000773 8b45fc mov eax, [ebp-4] 00000776 894500 mov [ebp], eax 00000779 8b4504 mov eax, [ebp+0x4] 0000077c f30f10442418 movss xmm0, [esp+0x18] 00000782 660f7ec6 movd esi, xmm0 00000786 83c41c add esp, 0x1c 00000789 ffe0 jmp eax }}} I think this is just a bug in LLVM 3.0, particularly as you say LLVM 3.4 has the expected behavior. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9125#comment:31 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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 amurrayc): Replying to [comment:32 rwbarton]:

Would you mind trying one more thing with LLVM 3.0 (with either the original or patched source tree)? Could you find the BuildFlavour stanza you are using in `mk/build.mk` (or just globally replace all of them if not sure) and change all occurrences of `-fllvm` to `-fllvm -fno-llvm- tbaa`? Curious if that would fix the issue.

That did not appear to change anything for the better. I tried building the device (ARM) compiler with LLVM 3.4 but it failed. I suppose this is related to the info in comment:21. I'm trying now with the patch mentioned there. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9125#comment:33 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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): Try applying https://phabricator.haskell.org/D208 to HEAD. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9125#comment:35 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9125: int-to-float conversion broken on ARM -------------------------------------+------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 (CodeGen) | Keywords: Resolution: | Architecture: arm Operating System: Unknown/Multiple | Test Case: Type of failure: Incorrect result | Blocking: at runtime | Differential Revisions: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * priority: highest => high Comment: Moving down in priority since this hasn't seen any updates; @bgamari, think you could look into this maybe? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9125#comment:38 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9125: int-to-float conversion broken on ARM -------------------------------------+------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 (CodeGen) | Keywords: Resolution: | Architecture: arm Operating System: Unknown/Multiple | Test Case: Type of failure: Incorrect result | Blocking: at runtime | Differential Revisions: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by rwbarton): Could you run ghc with `-keep-tmp-files` and attach both the pre- and post-mangling assembly files? (IIRC, these have extensions `.ll_s` and `.s` respectively.) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9125#comment:40 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9125: int-to-float conversion broken on ARM -------------------------------------+------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.8.3 (CodeGen) | Keywords: Resolution: | Architecture: arm Operating System: Unknown/Multiple | Test Case: Type of failure: Incorrect result | Blocking: at runtime | Differential Revisions: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.10.1 => 7.12.1 Comment: OK, so right now Ben Gamari and I are working on fixing up the LLVM backend in HEAD soon by shipping a known good version of LLVM for users to use; the new changes require LLVM 3.6 but seems to be stable on ARM and x86. So I'm punting this one out to 7.12 for now, since hopefully it will be fixed by using a fixed compiler with good test results. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9125#comment:42 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9125: int-to-float conversion broken on ARM -------------------------------------+------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.8.3 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): With #10074, ./configure checks for llvm-3.6 to be installed, with which this problem does not occur, according to comment:43. Replying to [comment:25 rwbarton]:

Well that's good to know, at least! I still think our TBAA information is wrong for this code, though.

Is that the reason this ticket is still open? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9125#comment:44 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9125: int-to-float conversion broken on ARM -------------------------------------+------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.8.3 (CodeGen) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"90fae01c326bf8b0802b4e8968f84886be4e1380/ghc" 90fae01c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="90fae01c326bf8b0802b4e8968f84886be4e1380" Fix LLVM TBAA metadata Accesses through a Cmm local are currently reported as having the "other" type, which can only alias other "other" accesses. However, this assumption is incorrect, which can result in silent bad LLVM codegen. Fixes #9308. Fixes #9504. Test Plan: GHC CI Reviewers: rwbarton, austin, bgamari Reviewed By: bgamari Subscribers: michalt, thomie Differential Revision: https://phabricator.haskell.org/D2758 GHC Trac Issues: #9125, #9308, #9504 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9125#comment:47 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler