#10383: AArch64: get GHC Calling convention working ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+---------------------------------- Comment (by erikd): I loaded the failing ghc-stage2 command into gdb, set a breakpoint on the `main` function and then single stepped through the assembler. These are the instructions executed: {{{ 0x41b5d8 ldr x4, [x4,#2584] 0x7fb1b44a08 mov x19, x2 0x7fb1b44a0c ldp x10, x11, [x3] 0x7fb1b44a24 str w0, [sp,#108] 0x7fb1b44a24 str w0, [sp,#108] 0x7fb1b44a28 add x0, sp, #0x6c 0x7fb1b44a2c str x1, [sp,#96] 0x7fb1b44a30 add x1, sp, #0x60 0x7fb1b6f080 <MainCapability> .inst 0xb1b55488 ; undefined }}} The text of the `MainCapability` function seems to be full of invalid instructions which suggests a linker problem or maybe something going wrong with `TABLES_NEXT_CODE`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10383#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10383: AArch64: get GHC Calling convention working ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+---------------------------------- Comment (by erikd): By adding `-debug` to `GhcStage2HcOpts` of `mk/build.mk` I turned up a different issue that I'm pretty sure is related, `inplace/bin/dll-split` exits with: {{{ dll-split: internal error: invalid closure, info=(nil) (GHC version 7.11.20150514 for aarch64_unknown_linux) }}} trigger by the assert: {{{ ASSERTM(LOOKS_LIKE_CLOSURE_PTR(q), "invalid closure, info=%p", q->header.info); }}} Adding a bit of `printf` debugging showed that the above assert passed a couple of hundred times before it found a NULL in `q->header.info`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10383#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10383: AArch64: get GHC Calling convention working ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+---------------------------------- Comment (by rwbarton): That means the beginning of a closure (heap object) got overwritten with zeros somehow and it was discovered during garbage collection. Have you tried running with `-DS`? That might find the offender earlier. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10383#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10383: AArch64: get GHC Calling convention working ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+---------------------------------- Comment (by erikd): I am reasonably certain that this is the same problem as #10375. Running: {{{ inplace/bin/ghc-stage2 +RTS -Ds -Di -Dw -DG -Dg -Db -DS -Dt -Dp -Da -Dl -Dm \ -Dc -Dr }}} otherwise know as "all the damn debug flags I can find" results in: {{{ stg_ap_v_ret... FUN/1(0x7f99ceba88, 0x7f98f041b9, 0x7f98f05448, 0x7f98f084c8, 0x7f98f084d8, 0x7f993cb861, 0x7f98f08558, (nil)d#, (nil)d#, 0x1fd#, 0x4d#, 0x5d#, 0x6d#) stg_ap_0_ret... base:GHC.Event.Manager.Created() 7f98eff1f0: cap 0: thread 2 stopped (yielding) 7f98eff1f0: giving up capability 0 7f98eff1f0: passing capability 0 to bound task 0x7f990ff000 7f990ff000: woken up on capability 0 7f990ff000: resuming capability 0 7f990ff000: cap 0: running thread 1 (ThreadRunGHC) Segmentation fault }}} which just like trac #10375 is GHC crashing in the `schedule` function of `rts/Schedule.c` with `what_next == ThreadRunGHC`. Will keep this open just in case its not. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10383#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10383: AArch64: get GHC Calling convention working ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+---------------------------------- Comment (by erikd): The `xchg` issue above was fixed in git commit f6ca6959e54ede0b28735ab7e011c16b3cb172db. Running `inplace/bin/ghc-stage2 +RTS -Da` under GDB now results in: {{{ ..... stg_ap_pppv_ret... FUN/4(0x7fb46fcc28) stg_ap_0_ret... FUN/4(0x7fb46fcc28) stg_ap_pppv_ret... FUN/4(0x7fb46fcc28) stg_ap_0_ret... FUN/4(0x7fb46fcc28) stg_ap_pppv_ret... FUN/4(0x7fb46fcc28) stg_ap_0_ret... FUN/4(0x7fb46fcc28) stg_ap_pppv_ret... FUN/4(0x7fb46fcc28) stg_ap_0_ret... FUN/4(0x7fb46fcc28) stg_ap_pppv_ret... FUN/4(0x7fb46fcc28) stg_ap_0_ret... FUN/4(0x7fb46fcc28) stg_ap_pppv_ret... FUN/4(0x7fb46fcc28) [New Thread 0x7fb39ff1f0 (LWP 25080)] stg_ap_v_ret... FUN/1(0x7fb47b8c78, 0x7fb3a041b9, 0x7fb3a05448, 0x7fb3a084c8 , 0x7fb3a084d8, 0x7fb3e96861, 0x7fb3a08558, (nil)d#, (nil)d#, 0x1fd#, 0x4d# , 0x5d#, 0x6d#) stg_ap_0_ret... base:GHC.Event.Manager.Created() Program received signal SIGSEGV, Segmentation fault. 0x0000007fb3dac244 in stg_ap_p_fast$def () from /home/erikd/ghc- upstream/rts/ dist/build/libHSrts_thr_debug-ghc7.11.20150602.so (gdb) bt #0 0x0000007fb3dac244 in stg_ap_p_fast$def () from /home/erikd/ghc- upstream/ rts/dist/build/libHSrts_thr_debug-ghc7.11.20150602.so Backtrace stopped: previous frame identical to this frame (corrupt stack?) }}} By hacking on `utils/genapply/GenApply.hs` I was able to add some more debug to the generated file `rts/dist/build/AutoApply.cmm` so that the generaed code for `stg_ap_pv_fast` looks like: {{{ stg_ap_pv_fast { W_ info; W_ arity; W_ xxxx; if (GETTAG(R1)==2) { Sp_adj(0); jump %GET_ENTRY(R1-2) [R1,R2]; } #ifdef PROFILING if (Sp - WDS(3) < SpLim) { Sp_adj(-2); W_[Sp+WDS(1)] = R2; Sp(0) = stg_ap_pv_info; jump __stg_gc_enter_1 [R1]; } #else if (Sp - WDS(2) < SpLim) { Sp_adj(-2); W_[Sp+WDS(1)] = R2; Sp(0) = stg_ap_pv_info; jump __stg_gc_enter_1 [R1]; } #endif R1 = UNTAG(R1); info = %GET_STD_INFO(R1); IF_DEBUG(apply,foreign "C" debugBelch("genApplyFast before\n");); xxxx = TO_W_(%INFO_TYPE(info)); IF_DEBUG(apply,foreign "C" debugBelch("genApplyFast after\n");); switch [INVALID_OBJECT .. N_CLOSURE_TYPES] (xxxx) { .... }}} With thjis debug the backtrace in GDB now looks like: {{{ stg_ap_0_ret... FUN/4(0x7fb46fcc28) stg_ap_pppv_ret... FUN/4(0x7fb46fcc28) [New Thread 0x7fb39ff1f0 (LWP 25080)] stg_ap_v_ret... FUN/1(0x7fb47b8c78, 0x7fb3a041b9, 0x7fb3a05448, 0x7fb3a084c8 , 0x7fb3a084d8, 0x7fb3e96861, 0x7fb3a08558, (nil)d#, (nil)d#, 0x1fd#, 0x4d# , 0x5d#, 0x6d#) stg_ap_0_ret... base:GHC.Event.Manager.Created() genApplyFast before genApplyFast after genApplyFast before Program received signal SIGSEGV, Segmentation fault. 0x0000007fb3dac244 in stg_ap_p_fast$def () from /home/erikd/ghc- upstream/rts/ dist/build/libHSrts_thr_debug-ghc7.11.20150602.so }}} suggesting it is segfaulting on the line: {{{ xxxx = TO_W_(%INFO_TYPE(info)); }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10383#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10383: AArch64: get GHC Calling convention working ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+---------------------------------- Comment (by erikd): At @rwbarton's suggestion, compiled this program {{{ main = print $ foldl (+) 0 [1..10000000] }}} with `ghc-stage1 -O0` (to thrash the GC) and the resulting program ran correctly. The problem does not seem to be GC related. Can also compile this program with {{{ inplace/bin/ghc-stage1 -O0 -dynamic hello.hs -o hello }}} and that too runs fine so this is unlikely to be dynamic library loading. Running `inplace/bin/ghc-stage2 +RTS -Ds` results in: {{{ 7fb3bc9000: created capset 0 of type 2 7fb3bc9000: created capset 1 of type 3 7fb3bc9000: cap 0: initialised 7fb3bc9000: assigned cap 0 to capset 0 7fb3bc9000: assigned cap 0 to capset 1 7fb3bc9000: allocated 1 more capabilities 7fb3bc9000: new task (taskCount: 1) 7fb3bc9000: returning; I want capability 0 7fb3bc9000: resuming capability 0 7fb3bc9000: cap 0: created thread 1 7fb3bc9000: new bound thread (1) 7fb3bc9000: cap 0: schedule() 7fb3bc9000: cap 0: running thread 1 (ThreadRunGHC) 7fb3bc9000: cap 0: created thread 2 7fb3bc9000: cap 0: thread 1 stopped (yielding) 7fb3bc9000: giving up capability 0 7fb3bc9000: starting new worker on capability 0 7fb3bc9000: new worker task (taskCount: 2) 7fb39ff1f0: cap 0: schedule() 7fb39ff1f0: cap 0: running thread 2 (ThreadRunGHC) 7fb39ff1f0: cap 0: thread 2 stopped (yielding) 7fb39ff1f0: giving up capability 0 7fb39ff1f0: passing capability 0 to bound task 0x7fb3bc9000 7fb3bc9000: woken up on capability 0 7fb3bc9000: resuming capability 0 7fb3bc9000: cap 0: running thread 1 (ThreadRunGHC) Segmentation fault (core dumped) }}} so the crash happens right after it switches threads. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10383#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10383: AArch64: get GHC Calling convention working ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+---------------------------------- Comment (by erikd): With the above patch to `StgRun`, the new backtrace in GDB looks like: {{{ ghc-stage2: internal error: invalid closure, info=(nil) (GHC version 7.11.20150602 for aarch64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Program received signal SIGABRT, Aborted. 0x0000007fb3c009b8 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/ linux/raise.c:56 56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 0x0000007fb3c009b8 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/ sysv/linux/raise.c:56 #1 0x0000007fb3c01cc0 in __GI_abort () at abort.c:89 #2 0x0000007fb3d74628 in rtsFatalInternalErrorFn (s=0x7fb3dbb820 "invalid closure, info=%p", ap=...) at rts/RtsMessages.c:170 #3 0x0000007fb3d74140 in barf (s=0x7fb3dbb820 "invalid closure, info=%p") at rts/RtsMessages.c:42 #4 0x0000007fb3d92740 in evacuate1 (p=0x7fb3aad560) at rts/sm/Evac.c:384 #5 0x0000007fb3d8392c in scavenge_block1 (bd=0x7fb3a02b40) at rts/sm/Scav.c:464 #6 0x0000007fb3d85df4 in scavenge_find_work () at rts/sm/Scav.c:2009 #7 0x0000007fb3d85f98 in scavenge_loop1 () at rts/sm/Scav.c:2085 #8 0x0000007fb3d8d980 in scavenge_until_all_done () at rts/sm/GC.c:977 #9 0x0000007fb3d8c334 in GarbageCollect (collect_gen=0, do_heap_census=rtsFalse, gc_type=2, cap=0x7fb3dc4980 <MainCapability>) at rts/sm/GC.c:396 #10 0x0000007fb3d608bc in scheduleDoGC (pcap=0x7fffffec88, task=0x5151c0, force_major=rtsFalse) at rts/Schedule.c:1674 #11 0x0000007fb3d5ed8c in schedule (initialCapability=0x7fb3dc4980 <MainCapability>, task=0x5151c0) at rts/Schedule.c:557 #12 0x0000007fb3d61ab4 in scheduleWaitThread (tso=0x7fb3a0b388, ret=0x0, pcap=0x7fffffee00) at rts/Schedule.c:2383 #13 0x0000007fb3d6349c in rts_evalLazyIO (cap=0x7fffffee00, p=0x4c36a0 , ret=0x0) at rts/RtsAPI.c:500 #14 0x0000007fb3d7b348 in hs_main (argc=2, argv=0x7ffffff018, main_closure=0x4c36a0 , rts_config=...) at rts/RtsMain.c:64 #15 0x00000000004bca48 in main () }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10383#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10383: AArch64: get GHC Calling convention working ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+---------------------------------- Comment (by erikd): With the un-reasonable effectiveness of wolf-fence debugging on #10375 I decided to apply it to this one as well and quickly found that the stage2 compiler was crashing in the function `SysTools.initSysTools`. With my added debug that function currently looks like: {{{ initSysTools :: Maybe String -- Maybe TopDir path (without the '-B' prefix) -> IO Settings -- Set all the mutable variables above, holding -- (a) the system programs -- (b) the package-config file -- (c) the GHC usage message initSysTools mbMinusB = do top_dir <- findTopDir mbMinusB -- see [Note topdir] -- NB: top_dir is assumed to be in standard Unix -- format, '/' separated let settingsFile = top_dir "settings" platformConstantsFile = top_dir "platformConstants" installed :: FilePath -> FilePath installed file = top_dir file putStrLn "initSysTools: About to read settingsFile" settingsStr <- readFile settingsFile putStrLn $ "initSysTools: settingsStr = \n" ++ settingsStr ++ "\n" mySettings <- case maybeReadFuzzy settingsStr of Just s -> do putStrLn "initSysTools: mySettings is Just" return s Nothing -> do putStrLn $ "initSysTools mySettings is Nothing" pgmError ("Can't parse " ++ show settingsFile) putStrLn $ "initSysTools " ++ show (__LINE__ :: Int) ... }}} and it crashes with: {{{ initSysTools: About to read settingsFile initSysTools: settingsStr = [("GCC extra via C opts", " -fwrapv"), ("C compiler command", "/usr/bin/gcc"), ("C compiler flags", " -fno-stack-protector"), ("C compiler link flags", " -fuse-ld=gold -Wl,-z,noexecstack"), ("Haskell CPP command","/usr/bin/gcc"), ("Haskell CPP flags","-E -undef -traditional"), ("ld command", "/usr/bin/ld.gold"), ("ld flags", " -z noexecstack"), ("ld supports compact unwind", "YES"), ("ld supports build-id", "YES"), ("ld supports filelist", "NO"), ("ld is GNU ld", "YES"), ("ar command", "/usr/bin/ar"), ("ar flags", "q"), ("ar supports at file", "YES"), ("touch command", "touch"), ("dllwrap command", "/bin/false"), ("windres command", "/bin/false"), ("libtool command", "libtool"), ("perl command", "/usr/bin/perl"), ("cross compiling", "NO"), ("target os", "OSLinux"), ("target arch", "ArchARM64"), ("target word size", "8"), ("target has GNU nonexec stack", "True"), ("target has .ident directive", "True"), ("target has subsections via symbols", "False"), ("Unregisterised", "NO"), ("LLVM llc command", "/usr/bin/llc-3.6"), ("LLVM opt command", "/usr/bin/opt-3.6") ] ghc-stage2: internal error: invalid closure, info=(nil) (GHC version 7.11.20150916 for aarch64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} It reads the `String` from `settingsFile` and prints it and then crashes in the pure function `maybeReadFuzzy`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10383#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10383: AArch64: get GHC Calling convention working ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+---------------------------------- Comment (by erikd): Yes, the build always fails the first time it tries to use the `ghc- stage2` binary. In fact that binary will also fail the same way when building the most trivial "hello world" program. It fails in exactly the same way when run as `taskset 0x02 inplace/bin /ghc-stage2 hello.hs -o hello`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10383#comment:17 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10383: AArch64: get GHC Calling convention working ----------------------------------------+------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ----------------------------------------+------------------------------- Comment (by rwbarton): You can certainly try to run the test suite against the stage1 compiler, see Building/RunningTests/Running. {{{ make TEST_HC=/path/to/ghc/inplace/bin/ghc-stage1 }}} I don't think we mark tests for whether they are expected to work under the stage1 compiler, so there will be a lot of false negatives (anything involving ghci or TH). But you could compare the failures to those on x86_64 and hopefully there will be some new, small tests that fail. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10383#comment:19 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10383: AArch64: get GHC Calling convention working ----------------------------------------+------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ----------------------------------------+------------------------------- Comment (by edmund): By the way, what BuildFlavour are you using? https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend says: "GHC HEAD now requires LLVM 3.6.x" https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796343 says: "arm64 has some (many) problems with older llvm such as the currently Debian default one. I tried to reproduce this (really nice) bug report, and I succeeded with llvm-3.4, 3.5 and 3.6." What's the best way of building GHC without LLVM? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10383#comment:21 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10383: AArch64: get GHC Calling convention working ----------------------------------------+------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ----------------------------------------+------------------------------- Comment (by edmund): Have you had any LLVM errors, such as the segfault in 'Greedy Register Allocator'? If you haven't, it might be because you're using the "native code generator" rather than the "LLVM code generator". That might be because of your BuildFlavour. Which BuildFlavour are you using? How are you building GHC, exactly? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10383#comment:23 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10383: AArch64: get GHC Calling convention working ----------------------------------------+------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ----------------------------------------+------------------------------- Comment (by edmund): That error from opt-3.7 looks like a syntax error in the IR. If there had been a fundamental change in the IR's syntax then it would probably be mentioned in http://llvm.org/releases/3.7.0/docs/ReleaseNotes.html, but I don't see it mentioned there. Also, it says in https://www.reddit.com/r/haskell/comments/3nf3q1/improved_llvm_backend/: "There are tests in LLVM upstream for our needed features (including the new ones in LLVM 3.6+), so hopefully the scope for regressions is lower (indeed, crude hacks simply increase the cost of supporting it.) In fact, LLVM 3.7.0 worked perfectly on release, and we did some prerelease testing too." So I wouldn't be so sure that the problem you're seeing there is caused by the IR changing. Can you try using GHC with llvm-3.7 on x86_64? In general, an LLVM load instruction does contain at least one comma, I think (http://llvm.org/docs/LangRef.html#id201), so the line you quoted looks suspicious. Can you get GHC to generate some more IR and see what the other loads look like? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10383#comment:25 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10383: AArch64: get GHC Calling convention working ----------------------------------------+------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------- Comment (by erikd): I have a patch in progress that allows building GHC with llvm-3.7 and `BuildFlavour=quick-llvm` on x86_64. In the process of testing that on arm64. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10383#comment:27 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10383: AArch64: get GHC Calling convention working ----------------------------------------+------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------- Comment (by edmund): That's excellent! Some questions: - Did you run the testsuite? - Are there any regressions? - Is concurrency ("-threaded") now enabled? - Did that get tested by the testsuite? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10383#comment:29 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10383: AArch64: get GHC Calling convention working ----------------------------------------+------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------- Comment (by erikd): There is definitely some work to do: {{{ OVERALL SUMMARY for test run started at Sat Oct 10 08:41:17 2015 UTC 0:28:32 spent to go through 4693 total tests, which gave rise to 14892 test cases, of which 10249 were skipped 72 had missing libraries 4146 expected passes 100 expected failures 21 caused framework failures 0 unexpected passes 307 unexpected failures 14 unexpected stat failures }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10383#comment:31 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10383: AArch64: get GHC Calling convention working ----------------------------------------+------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------- Comment (by erikd): Now that GHCi is working: {{{ OVERALL SUMMARY for test run started at Mon Oct 12 08:37:45 2015 UTC 0:30:52 spent to go through 4695 total tests, which gave rise to 14901 test cases, of which 10255 were skipped 72 had missing libraries 4284 expected passes 100 expected failures 22 caused framework failures 0 unexpected passes 172 unexpected failures 14 unexpected stat failures }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10383#comment:33 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10383: AArch64: get GHC Calling convention working ----------------------------------------+------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------- Comment (by erikd): Yep, added `%d15` to the clobbered regs list and added a comment along the lines you suggested. As usual its in the `wip/aarch64-regd` in the GHC git repo. Behavour as expected is unchanged. Currently have ~170 test failing. Choosing one, pretty much at random, I notice that it fails in three different ways (as do many of the other failing tests): {{{ $ inplace/bin/ghc-stage2 -O -v0 -fforce-recomp \ testsuite/tests/numeric/should_run/T7014.hs -o a.out Illegal instruction (core dumped) $ inplace/bin/ghc-stage2 -O -v0 -fforce-recomp \ testsuite/tests/numeric/should_run/T7014.hs -o a.out Segmentation fault (core dumped) $ inplace/bin/ghc-stage2 -O -v0 -fforce-recomp \ testsuite/tests/numeric/should_run/T7014.hs -o a.out Bus error (core dumped) }}} Even after disabling ASLR (Address space layout randomization) it still fails in at least two ways. The above failure only happens with optimisation (`-O`) turned on. As usual, GDB provides nothing but a very poor backtrace: {{{ Program received signal SIGSEGV, Segmentation fault. 0x000006d6f9400288 in ?? () (gdb) bt #0 0x000006d6f9400288 in ?? () #1 0x0000007fb6db8ca4 in cwTZ_info$def () from .../libHSghc-7.11.20151019-ghc7.11.20151019.so }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10383#comment:35 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10383: AArch64: get GHC Calling convention working ----------------------------------------+------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------- Comment (by edmund): You're quoting cases of ghc-stage2 segfaulting. Presumably that's because ghc-stage1 generated bad code. And I'm guessing both stage1 and stage2 are registerised. It would be nice if you could find a simple program that gets compiled incorrectly, and to get that you could either run the test suite with the stage1 compiler (bearing in mind that some tests are expected to fail with a stage1 compiler) or find a way of building a registerised stage2 using an unregisterised stage1 (which doesn't appear to be entirely straightforward with the way the build infrastructure works). What do you think? You can tell GDB "info reg" and "x/i 0x0000007fb6db8ca4" to find out how it got from there to 0x000006d6f9400288. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10383#comment:37 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10383: AArch64: get GHC Calling convention working ----------------------------------------+------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------- Comment (by erikd): The test `( cd testsuite && make TEST=ado001 stage=1 )` passes on arm64. Running the whole test suite like that and I get a number of failures due to the fact that its only the stage1 compiler (ie all ghci, TH and annoations tests), but I also get this one failing: {{{ make test stage=1 TEST="T5435_v_asm" }}} but that passes on x86_64. Sure enough, looking at `rts/Linker.c` there is no `aarch64_ HOST_ARCH` section. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10383#comment:39 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10383: AArch64: get GHC Calling convention working ----------------------------------------+------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------- Changes (by bgamari): * milestone: 8.2.1 => Comment: De-milestoning due to lack of progress. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10383#comment:42 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler