#8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.2 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ------------------------------------+---------------------------------- Comment (by carter): CMM is generated *before* the NCG and LLVM backends... so is there some code path before the code gen that depends on which code gen is selected? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8974#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.2 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ------------------------------------+---------------------------------- Changes (by ezyang): * cc: dterei (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8974#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.2 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ------------------------------------+---------------------------------- Comment (by awson): Perhaps it would be interesting: `performMajorGC` alone and `putStrLn "Done"` alone works. `putStrLn "Done" >> performMajorGC` works. And {{{ foreign import ccall unsafe puts :: Ptr a -> IO () performMajorGC >> puts (Ptr "Done"#) }}} works too. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8974#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.2 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ------------------------------------+---------------------------------- Comment (by awson): I've decided to investigate things further. After firing GDB I've seen a painfully familiar picture of what I saw at #8834. Looking into LLVM codegen code i see [http://git.haskell.org/ghc.git/blob/HEAD:/compiler/llvmGen/LlvmCodeGen/CodeG... ... For Caller save registers across C calls the saving and restoring of them is done by the Cmm code generator, using Cmm local vars. So to stop LLVM saving them as well (and saving all of them since it thinks they're always live, we trash them just before the call by assigning the 'undef' value to them. The ones we need are restored from the Cmm local var and the ones we don't need are fine to be trashed.] But recent #8834 saga teach us that after [http://git.haskell.org/ghc.git/blobdiff/66aa489fcbfca30dc3c3b553fce4f1e4debf...] this already is not the case. And after this [http://git.haskell.org/ghc.git/commitdiff/c4eeacdfdf4578eb6e75bbf2e067bfe70e... NCG became responsible for saving registers across the C call]. It looks LLVM backend still does not take this into account. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8974#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.3 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ------------------------------------+---------------------------------- Comment (by awson): I've decided that intervening at [http://git.haskell.org/ghc.git/blob/HEAD:/compiler/llvmGen/LlvmCodeGen/Data.... `genStaticLit (CmmLabelDiffOff l1 l2 off)`] is safe and have rewritten the code to generate 32-bit arithmetic and pointer conversion, but it turned out LLVM generates unsuitable code for `ptrtoint ... to i32` applied to 64-bit pointer. For example, if {{{ @T8947_t1_info_itable = constant %T8947_t1_entry_struct<{i64 add (i64 sub (i64 ptrtoint (i8* @S1fL_srt$alias to i64),i64 ptrtoint (void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)* @T8947_t1_info to i64)),i64 0), i64 4294967299, i64 0, i64 64424509455}>, section "X98A__STRIP,__me3", align 8 }}} gets rewritten to {{{ @T8947_t1_info_itable = constant %T8947_t1_entry_struct<{i32 add (i32 sub (i32 ptrtoint (i8* @S1i6_srt$alias to i32),i32 ptrtoint (void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)* @T8947_t1_info to i32)),i32 0), i32 0, i64 4294967299, i64 0, i64 64424509455}>, section "X98A__STRIP,__me3", align 8 }}} LLVM instead of {{{ T8947_t1_info_itable: .quad S1i6_srt-T8947_t1_info }}} generates (assembler spits {{{Error: invalid operands (.rdata and *ABS* sections) for `&'}}}) {{{ T8947_t1_info_itable: .long (S1i6_srt&-1)-(T8947_t1_info&-1) .long 0 # 0x0 }}} while we want it to be {{{ T8947_t1_info_itable: .long S1i6_srt-T8947_t1_info .long 0 # 0x0 }}} I'm in no way an LLVM expert and know very little about it. Is there a way to make LLVM generate the code we want or are we use the mangler here? Any thoughts? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8974#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.3 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ------------------------------------+---------------------------------- Comment (by awson): I've decided to simplify things and returned to [https://ghc.haskell.org/trac/ghc/ticket/8974#comment:12 original design]. No more magics. Just fixing resulting assembler in the mangler. I think the patterns like `..._srt&-1` and `..._info&-1` may not be generated by any *other* code and hence could be rewritten to `..._srt` and `..._info` safely. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8974#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.3 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ------------------------------------+---------------------------------- Changes (by simonmar): * cc: simonmar (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8974#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+---------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.3 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ------------------------------------+---------------------------------- Comment (by altaic): LLVM has to be able to do a proper pointer cast. I'd definitely take Ben's advise and talk to the LLVM folks about this. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8974#comment:18 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

For example, if {{{ @T8947_t1_info_itable = constant %T8947_t1_entry_struct<{i64 add (i64 sub (i64 ptrtoint (i8* @S1fL_srt$alias to i64),i64 ptrtoint (void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)* @T8947_t1_info to i64)),i64 0), i64 4294967299, i64 0, i64 64424509455}>, section "X98A__STRIP,__me3", align 8 }}} gets rewritten to {{{ @T8947_t1_info_itable = constant %T8947_t1_entry_struct<{i32 add (i32 sub (i32 ptrtoint (i8* @S1i6_srt$alias to i32),i32 ptrtoint (void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)* @T8947_t1_info to i32)),i32 0), i32 0, i64 4294967299, i64 0, i64 64424509455}>, section "X98A__STRIP,__me3", align 8 }}}

LLVM instead of {{{ T8947_t1_info_itable: .quad S1i6_srt-T8947_t1_info }}} generates (assembler spits {{{Error: invalid operands (.rdata and *ABS*

#8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults -------------------------------------+------------------------------------- Reporter: awson | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.9 (LLVM) | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Windows | Difficulty: Unknown Type of failure: Runtime | Blocked By: crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Fanael): Replying to [comment:12 awson]: sections) for `&'}}})

{{{ T8947_t1_info_itable: .long (S1i6_srt&-1)-(T8947_t1_info&-1) .long 0 # 0x0 }}} while we want it to be {{{ T8947_t1_info_itable: .long S1i6_srt-T8947_t1_info .long 0 # 0x0 }}}

I'm in no way an LLVM expert and know very little about it. Is there a way to make LLVM generate the code we want or are we use the mangler here? Any thoughts?

Yes, there is. Use `trunc`, for example: {{{ %foo = type <{i32, i32}> @aaa = global i32 5 @bbb = global i32 5 @foo = constant %foo<{i32 trunc(i64 sub(i64 ptrtoint (i32* @aaa to i64), i64 ptrtoint (i32* @bbb to i64)) to i32), i32 0}> }}} LLVM will generate {{{ foo: .long aaa-bbb .long 0 # 0x0 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8974#comment:21 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults -------------------------------------+------------------------------------- Reporter: awson | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.9 (LLVM) | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Windows | Difficulty: Unknown Type of failure: Runtime | Blocked By: crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Fanael): Replying to [comment:22 awson]:

AFAIR, the `trunc` alone is '''not''' sufficient. What you propose in fact is to '''declare''' a pair of 32-bit int variables instead of one 64-bit pointer global variable, right?

As shown in the example, yes. The ideal solution would be to convert that truncated value back to `i64`, but even though the LLVM docs say that `sext` and `zext` are valid constant expressions, they don't work and yield an "Unsupported expression in static initializer" error. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8974#comment:23 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults -------------------------------------+------------------------------------- Reporter: awson | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 7.12.1 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Fanael): It's not Windows, it's binutils being broken (nothing new). For example, LLVM emits this: {{{ .quad S1kt_srt$def-Main_main1_info$def # @"Main_main1_info$def" .quad 4294967299 # 0x100000003 .quad 0 # 0x0 .quad 64424509455 # 0xf0000000f Main_main1_info$def: }}} With GDB, we can learn that this value should equal {{{ (gdb) p ((char*)&S1kt_srt$def - (char*)&Main_main1_info$def) $1 = 3062336 }}} But what actually lands in the executable is {{{ (gdb) x/d Main_main1_info$def - 32 0x4015b0 : 3062340 }}} Makes me wonder if binutils devs are aware of the problem. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8974#comment:27 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults -------------------------------------+------------------------------------- Reporter: awson | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 7.12.1 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Fanael, could you test this with `ld.gold`? We already advise users to use gold on ARM; perhaps we should just do the same here. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8974#comment:29 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+-------------------------------------- Reporter: awson | Owner: Type: bug | Status: upstream Priority: high | Milestone: 8.2.1 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Changes (by bgamari): * status: infoneeded => upstream * milestone: 8.0.1 => 8.2.1 Comment: Looks like we we can't do much other than wait for the binutils people. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8974#comment:32 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+-------------------------------------- Reporter: awson | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler (LLVM) | Version: 7.9 Resolution: worksforme | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Changes (by thomie): * status: upstream => closed * resolution: => worksforme * milestone: 8.2.1 => 8.0.1 Comment: Replying to [comment:33 awson]:

GHC HEAD with LLVM 3.7 and current released binutils doesn't have this bug and works without any modifications.

Ok, let's close this. There won't be another 7.10 release afaik. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8974#comment:34 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+-------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Changes (by Fanael): * status: closed => new * resolution: worksforme => -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8974#comment:36 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+-------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Comment (by YellowOnion): I've been experiencing segfaults with -Odph and -fllvm on ghc 7.10.3 and llvm 3.5 on my app, Is this bug related, or should I file another one? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8974#comment:38 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+-------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Comment (by awson): Since I have now quite a bit of spare time, I've decided to look into this. Indeed, binutils `ld` is wrong here. I've created [https://sourceware.org/bugzilla/show_bug.cgi?id=17955#c1 the patch to binutils] which fixes things for me. OTOH, mention should be made that R_X86_64_PC64 reloc is '''not supported''' by MS in PE-COFF and neither MS `link` nor LLVM `lld` can handle it (the former simply ignores it and the latter complains about unsupported relocation type). Thus the proper way to fix it is to use a workaround similar to that used in NCG (see my comment above) to make LLVM generate R_X86_64_PC32 relocs instead. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8974#comment:40 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+-------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Changes (by bgamari): * cc: Phyx (added) Comment: Phyx, do you know anyone in the msys2 project? This sounds important. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8974#comment:42 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+-------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Changes (by dterei): * cc: dterei (removed) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8974#comment:44 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+-------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Comment (by Phyx-): Binutils 2.27-2 has been released on msys, this contains Awson's patch. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8974#comment:46 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+-------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Comment (by GordonBGood): Replying to [comment:46 Phyx-]:

Binutils 2.27-2 has been released on msys, this contains Awson's patch.

I need to boil down a version that consistently fails using -fllvm (with the patch on 64-bit Windows) and not without and will submit it here...

Failure code as follows: {{{ {-# LANGUAGE FlexibleContexts #-} {-# OPTIONS_GHC -O3 -rtsopts #-} -- or O2 import Data.Array.ST (runSTUArray) import Data.Array.Base numLOOPS = 50000 :: Integer -- Uses a very simple Sieve of Eratosthenes to 2 ^ 18 (so one L1 cache size). test :: () -> [Int] test() = 2 : [fromIntegral i * 2 + 3 | (i, False) <- assocs bufb] where bufb = runSTUArray $ do let bfLmt = (256 * 1024) `div` 2 - 1 -- to 2^18 + 2 is 128 KBits - 1 = 16 KBytes cmpstsb <- newArray (0, bfLmt) False :: ST s (STUArray s Int Bool) let loop n = -- cull a number of times to test timing if n <= 0 then return cmpstsb else loop (n - 1) loop numLOOPS main = print $ length $ test() }}} The above code consistently segfaults with 64-bit GHC 8.0.1 with LLVM 3.7 with the latest MSYS2_64 including the patch on Windows when compiled with the -fllvm flag but not on Linux 64-bit (Fedora 24) under the same conditions or without the -fllvm flag (defaulting to using NCG). It does not segfault if 'numLOOPS' is made only 1000 or if the type of 'numLOOPS' is changed from multi-precision 'Integer' to base 'Int' (64-bit integer value for 64-bit systems). I suspect there is a value such as 32768 where the segfault starts when using 'Integer'. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8974#comment:48 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+-------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Comment (by GordonBGood): Replying to [comment:49 awson]:

Can't reproduce this neither with ghc-8.0.1.20160826+llvm-3.7, nor with ghc-8.1.20160921+llvm-4.0(HEAD). I have no segfaults in both cases (tried to increase numLOOPS to 100000 and 200000 -- no segfaults either).

Perhaps, that was a bug in GHC which was fixed since 8.0.1 release?

@awson, Perhaps it has been fixed which would be good - I'm using 64-bit Haskell Platform with stock/stable 8.0.1. I'm also having segfaults with -fllvm and not without even though I don't believe it's using 'Integer' with the following paged Sieve of Eratosthenes code: {{{ {-# LANGUAGE FlexibleContexts #-} {-# OPTIONS_GHC -O3 -rtsopts #-} -- or O2 import Data.Bits import Data.Array.Base import Data.Array.ST (runSTUArray, STUArray(..)) type PrimeType = Int range = 1000000 :: PrimeType szPGBTS = (2^14) * 8 :: PrimeType -- CPU L1 cache in bits szBPBTS = (2^7) * 8 :: PrimeType -- base primes pages can be much smaller primesPages :: PrimeType -> [UArray PrimeType Bool] primesPages szpgbts = pagesFrom 0 szPGBTS bppgs where makePg lowi szbts bps = runSTUArray $ do let limi = lowi + szbts - 1 let nxt = 3 + limi + limi -- last candidate in range cmpsts <- newArray (lowi, limi) False let pbts = fromIntegral szbts let cull (p:ps) = let sqr = p * p in if sqr > nxt then return cmpsts else let pi = fromIntegral p in let cullp c = if c > pbts then return () else do unsafeWrite cmpsts c True cullp (c + pi) in let a = (sqr - 3) `shiftR` 1 in let s = if a >= lowi then fromIntegral (a - lowi) else let r = fromIntegral ((lowi - a) `rem` p) in if r == 0 then 0 else pi - r in do { cullp s; cull ps } if bps == [] then do pg0 <- unsafeFreezeSTUArray cmpsts cull $ listPagePrms [pg0] else cull bps pagesFrom lowi bts bps = let cf lwi = case makePg lwi bts bps of pg -> pg `seq` pg : cf (lwi + bts) in cf lowi bppgs = -- secondary stream of primes listPagePrms (makePg 0 szBPBTS [] : (pagesFrom szBPBTS szBPBTS bppgs)) listPagePrms :: [UArray PrimeType Bool] -> [PrimeType] listPagePrms (hdpg @ (UArray lowi _ rng _) : tlpgs) = let loop i = if i >= rng then listPagePrms tlpgs else if unsafeAt hdpg i then loop (i + 1) else let ii = lowi + fromIntegral i in case 3 + ii + ii of p -> p `seq` p : loop (i + 1) in loop 0 primesPaged :: () -> [PrimeType] primesPaged() = 2 : (listPagePrms $ primesPages szPGBTS) main = print $ length $ takeWhile ((>=) range) $ primesPaged() }}} The above segfaults for the "range" set to a million, but not for some lesser values (ie. a hundred thousand) for '-fllvm' with the same environment as before. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8974#comment:50 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+-------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Comment (by GordonBGood): Replying to [comment:51 awson]:

Weird. No problems with this also. I tried to increase `range` to `10000000` (10 millions), no problems either.

When it works, the program will output the number of primes up to trillions if you give it enough time, but this simple version works best for ranges up to about 16 billion ;)

And yes, I mean 64-bit GHCs only.

Well, it's not too much of a problem if it is fixed in HEAD as 8.2.1 will take care of it, but we need to verify that 8.0.1 standard has the problem on your Windows machine and I need to verify that HEAD fixes the problem on mine. Any suggestions on how to get a development release for Windows 64-bit that you show as working without going through hoops to compile it on my machine? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8974#comment:52 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+-------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Comment (by GordonBGood): Replying to [comment:53 awson]:

Well, I've downloaded 8.0.1 release, tried it and all your examples immediately started to segfault, but after I replaced distributed binutils with the correct one all started to work flawlessly, no segfaults altogether for all your examples.

So, Yes, I was unable to compile anything to run at all without segfaults using -fllvm on Windows 64-bit until I updated MSYS2 with pacman update so as to update to binutils 2.27-2, then downgraded LLVM from 3.8 back to 3.7.0-6, which is where I am sitting now with this problem. I think that one difference between our setups is that my path finds the MSYS2 bindir first before the mingw that comes with GHC 8.0.1, and perhaps some of those GHC mingw files have been patched or are versions that work with GHC 8.0.1 whereas the up-to-date MSYS2 ones aren't quite compatible. This would explain why 'Integer' has problems as I notice that MSYS2 has updated GMP files. I can move the LLVM 3.7 and binutils files into the GHC mingw folder and temporarily remove MSYS2 bindir from the path, but I need to know what binutil files were patched for binutils 2.27-2 or if I should just replace all of them. Another possible difference is that I am using the MSYS2 LLVM version 3.7.0 where you might be using the LLVM version 3.7.1 which may have some differences. I don't have a copy of LLVM 3.7.1 and don't know how to get the crucial two files 'llc.exe' and 'opt.exe' without compiling it as most binary distros have been replaced with newer versions. However, I did find a copy of a binary distro for MSYS2 mingw x86_64 LLVM 3.7.0-9 which I will try. It seems that this is just another case of incompatibilities between GHC and the versions of programs it requires such as specific versions of LLVM but perhaps others, which hopefully will be fixed with GHC 8.2.1 distributing versions that are known to work and automatically setting the path to use those versions. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8974#comment:54 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+-------------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2749 Wiki Page: | ------------------------------------+-------------------------------------- Comment (by Ben Gamari ): In [changeset:"20c06143a7bfc6548351e610350a8e1c0d8a0bb9/ghc" 20c06143/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="20c06143a7bfc6548351e610350a8e1c0d8a0bb9" Update Mingw-w64 bindist for Windows This updates the binary dists for windows to GCC 6.2.0 and binutils 2.27.2 which has fixes required for LLVM. Test Plan: ./validate Reviewers: simonmar, erikd, austin, bgamari Reviewed By: simonmar, bgamari Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2749 GHC Trac Issues: #12871, #8974 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8974#comment:56 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler