December 2018 - ghc-tickets

[GHC] #16082: Sort out treatment of underscores in types
by GHC 07 Feb '19

07 Feb '19

#16082: Sort out treatment of underscores in types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I can count 4 different meanings for underscores in Haskell programs: 1. A pattern for which we don't care to write a name. (This dates back to antiquity.) Example: {{{#!hs const x _ = x }}} 2. An expression for which we want GHC to tell us what its expected type should be. (Relatively new: these are typed holes.) Example: {{{#!hs plus x y = x + _ }}} 3. A type which we want GHC to infer, by looking at the expression. (Relatively new: these are wild cards in partial type signatures.) Example: {{{#!hs plus :: forall a. Num a => a -> a -> _ plus x y = x + y }}} 4. A type which we want GHC to infer, by looking at the underscore's context. (Relatively new: these are wild cards in type applications.) Example: {{{#!hs x = const @_ @Bool 'x' -- the _ is inferred to mean Char }}} Problems arise with the advent of visible kind application (#12045): In type signatures, 3 of these meanings make sense (2, 3, and 4). In type/data family patterns, 3 of these meanings make sense (1, 2, and 4). Ideally, the user should have the opportunity to choose which meaning they want. In contrast, right now we use heuristics: in visible type/kind applications, we always use (4); otherwise, we use (1) (in patterns) or (3) (in types). This is a mess, for at least three reasons: A. Users might conceivably want different behavior than what we provide. For example, perhaps a user is writing an intricate pattern (at either term or type level) and wants to know the type (resp. kind) of the next bit of pattern. Or maybe the user wants to do this in a visible type application. Right now, there's just no way to do this. B. It causes trouble for pretty-printing. Aside from term-level patterns, all the uses of underscores above are stored identically in the AST. This means that they are printed identically. But that's strange. For example, uses (3) and (4) might have different underscores meaning different variables. Should we number the underscores? But that would be silly for usage (1). It's all a bit muddy. C. This causes awkwardness in the implementation. #12045 has to twiddle DynFlags to get its desired behavior, and that's sad. This ticket is to track resolutions to these problems. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16082> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14730: Missing predicate for "ResourceVanished" IOException/IOErrorType
by GHC 06 Feb '19

06 Feb '19

#14730: Missing predicate for "ResourceVanished" IOException/IOErrorType -------------------------------------+------------------------------------- Reporter: bit | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.2.2 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `IOErrorType` has a "`ResourceVanished`" constructor: https://hackage.haskell.org/package/base-4.10.1.0/docs/src/GHC.IO.Exception… But there is no way to detect this for an `IOException` or `IOErrorType`. Here is some real-world code I found, where the author wants to catch "`ResourceVanished`", but resorts to catching all `IOException`: https://hackage.haskell.org/package/http-client-tls-0.3.5.1/docs/src /Network-HTTP-Client-TLS.html#convertConnection Docs for `hPutBuf` also mention the public existence of "`ResourceVanished`": https://hackage.haskell.org/package/base-4.10.1.0/docs/GHC-IO- Handle.html#v:hPutBuf Suggestion: We need to add functions: {{{#!haskell isResourceVanished :: IOError -> Bool resourceVanishedErrorType :: IOErrorType isResourceVanishedErrorType :: IOErrorType -> Bool }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14730> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #16106: Remove PowerPC OS X (Darwin) support
by GHC 06 Feb '19

06 Feb '19

#16106: Remove PowerPC OS X (Darwin) support --------------------------------+--------------------------------- Reporter: trommler | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.6.3 Keywords: | Operating System: MacOS X Architecture: powerpc | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+--------------------------------- OS X for PowerPC is not supported by Apple anymore. GHC's support has most likely bit-rotted and we have no test machine. Let's go ahead and remove support for PowerPC Darwin. The following components contain PowerPC Darwin specific code: * native code generator * RTS * driver * build system -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16106> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15897: Negative MUT time in +RTS -s -RTS when heap profiling is enabled
by GHC 06 Feb '19

06 Feb '19

#15897: Negative MUT time in +RTS -s -RTS when heap profiling is enabled -------------------------------------+------------------------------------- Reporter: maoe | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Profiling | Version: 8.6.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Debugging (amd64) | information is incorrect Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Mutator run time in +RTS -s -RTS can go negative in GHC 8.6.x when retainer profiling is enabled. Here is an example taken from https://ghc.haskell.org/trac/ghc/ticket/881#comment:9 {{{ {-# OPTIONS_GHC -fprof-auto #-} import Control.Monad import Data.IORef import System.Environment main = do [n] <- getArgs replicateM (read n) (newIORef [1,2,3]) }}} {{{ % ghc-8.6.2 -prof -rtsopts -fforce-recomp repro.hs [1 of 1] Compiling Main ( repro.hs, repro.o ) Linking repro ... % ./repro 10000000 +RTS -s -h 3,053,080,472 bytes allocated in the heap 5,538,404,848 bytes copied during GC 1,013,615,328 bytes maximum residency (16 sample(s)) 36,422,944 bytes maximum slop 966 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 2600 colls, 0 par 1.375s 1.376s 0.0005s 0.0019s Gen 1 16 colls, 0 par 4.355s 4.355s 0.2722s 1.0136s INIT time 0.000s ( 0.000s elapsed) MUT time 0.000s ( -0.833s elapsed) GC time 4.016s ( 4.016s elapsed) RP time 0.000s ( 0.000s elapsed) PROF time 1.715s ( 1.715s elapsed) EXIT time 1.715s ( 1.715s elapsed) Total time 6.612s ( 6.612s elapsed) %GC time 0.0% (0.0% elapsed) Alloc rate 0 bytes per MUT second Productivity -12.6% of total user, -12.6% of total elapsed }}} Here is what I found so far: * GHC 8.6.1, 8.6.2, and yesterday's HEAD have the same issue. GHC 8.4.4 doesn't have this issue. * `-hr` has the same issue. `-hT` is fine. * Without heap profiling the numbers this doesn't happen -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15897> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #15558: Locally handling an empty constraint
by GHC 05 Feb '19

05 Feb '19

#15558: Locally handling an empty constraint -------------------------------------+------------------------------------- Reporter: Ericson2314 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I need something like `\case {}` for constraints. See the code below. There's nothing I can replace the `undefined` with that will satisfy the type checker. The dead code warning also bubbled up out of the field incorrectly. I think this will require new language features tangentially related to Lambdas for `forall`. (Both `forall _.` and `=>` are invisible quantifiers.) I will link this ticket in that GHC proposal, but am making it's own issue in the first place in case this is a genuine bug that can be fixed by less intrusive means. {{{ {-# LANGUAGE RankNTypes #-} {-# LANGUAGE EmptyCase #-} {-# LANGUAGE LambdaCase #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE ScopedTypeVariables #-} module Asdf where import Data.Kind import Data.Type.Equality data Sing a where X :: Sing Int Y :: Sing [Bool] data Foo a = Foo a (forall b. [b] :~: a -> b) data Bar a = Bar a (forall b. [b] ~ a => b) f, f' :: forall a. Sing a -> Foo a f s = Foo a b where a :: a a = case s of X -> 0 Y -> [] b :: forall b. [b] :~: a -> b b = case s of X -> \case {} Y -> \Refl -> False f' = \case X -> Foo 0 (\case {}) Y -> Foo [] (\Refl -> False) g, g' :: forall a. Sing a -> Bar a g s = Bar a b where a :: a a = case s of X -> 0 Y -> [] b :: forall b. [b] ~ a => b b = case s of Y -> False g' = \case X -> Bar 0 undefined -- can't make this happy Y -> Bar [] False }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15558> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #12149: Support bit-fields
by GHC 05 Feb '19

05 Feb '19

#12149: Support bit-fields -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | Version: 8.0.1 Keywords: bit-fields | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Having C type like: {{{ typedef struct S { int f0: 1; int f1: 15; } S; }}} and {{{hsc}}} code like {{{ #{peek S, f0} p }}} Causes {{{hsc2hs}}} to fail with {{{ error: attempt to take address of bit-field structure member 'f0' }}} Apparently this is an error from gcc, which cannot provide the address of bit-fields. However, in Haskell we are not interested in the address of the bit-field but in its value. It would be useful to have a way to get and set the values of these fields. Some former discussion [https://mail.haskell.org/pipermail/haskell- cafe/2008-November/050317.html here] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12149> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #16092: Bug when trying to combine two lists
by GHC 05 Feb '19

05 Feb '19

#16092: Bug when trying to combine two lists -------------------------------------+------------------------------------- Reporter: sutbult | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Building GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I want to write a function that takes two lists and returns a list that includes every possible combination of elements from the two given lists, using a given function. I thought that this code would work: {{{#!hs combine :: (a -> b -> c) [a] -> [b] -> [c] combine fn alist blist = [fn a b | a <- alist, b <- blist] }}} However, when compiling, this message arises from GHC: Glasgow Haskell Compiler, Version 8.2.1, stage 2 booted by GHC version 7.10.3 Using binary package database: /Library/Frameworks/GHC.framework/Versions/8.2.1-x86_64/usr/lib/ghc-8.2.1/package.conf.d/package.cache Using binary package database: /Users/samuelutbult/.ghc/x86_64-darwin-8.2.1/package.conf.d/package.cache package flags [] loading package database /Library/Frameworks/GHC.framework/Versions/8.2.1-x86_64/usr/lib/ghc-8.2.1/package.conf.d loading package database /Users/samuelutbult/.ghc/x86_64-darwin-8.2.1/package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.1.0 wired-in package integer-gmp mapped to integer-gmp-1.0.1.0 wired-in package base mapped to base-4.10.0.0 wired-in package rts mapped to rts wired-in package template-haskell mapped to template-haskell-2.12.0.0 wired-in package ghc mapped to ghc-8.2.1 wired-in package dph-seq not found. wired-in package dph-par not found. package flags [] loading package database /Library/Frameworks/GHC.framework/Versions/8.2.1-x86_64/usr/lib/ghc-8.2.1/package.conf.d loading package database /Users/samuelutbult/.ghc/x86_64-darwin-8.2.1/package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.1.0 wired-in package integer-gmp mapped to integer-gmp-1.0.1.0 wired-in package base mapped to base-4.10.0.0 wired-in package rts mapped to rts-1.0 wired-in package template-haskell mapped to template-haskell-2.12.0.0 wired-in package ghc mapped to ghc-8.2.1 wired-in package dph-seq not found. wired-in package dph-par not found. *** Chasing dependencies: Chasing modules from: *Combine.hs !!! Chasing dependencies: finished in 0.69 milliseconds, allocated 0.222 megabytes Stable obj: [] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = 2018-12-23 17:18:05.830132761 UTC ms_mod = Main, ms_textual_imps = [(Nothing, Prelude)] ms_srcimps = [] }] *** Deleting temp files: Deleting: compile: input file Combine.hs *** Checking old interface for Main (use -ddump-hi-diffs for more details): [1 of 1] Compiling Main ( Combine.hs, Combine.o ) *** Parser [Main]: !!! Parser [Main]: finished in 1.05 milliseconds, allocated 0.171 megabytes *** Renamer/typechecker [Main]: *** Deleting temp files: Deleting: *** Deleting temp dirs: Deleting: ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-apple-darwin): repSplitAppTys a_anL[sk:1] b_anM[sk:1] -> c_anN[sk:1] [] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:808:9 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16092> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #16004: Vector performance regression in GHC 8.6
by GHC 04 Feb '19

04 Feb '19

#16004: Vector performance regression in GHC 8.6 -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello. With the following code, I can observe a performance regression between ghc 8.4 and 8.6: {{{#!haskell {-# LANGUAGE ScopedTypeVariables #-} module Main where import qualified Data.Vector.Unboxed.Mutable as Vector import qualified Data.Vector.Unboxed as VectorU import Data.Foldable (for_) main :: IO () main = do let n = 1000 let vUnmutable :: VectorU.Vector Double = VectorU.generate (n * n) (\i -> fromIntegral i) v :: Vector.IOVector Double <- VectorU.unsafeThaw vUnmutable for_ [0..(n - 1)] $ \k -> do for_ [0..(n - 1)] $ \i -> do for_ [0..(n - 1)] $ \j -> do a <- Vector.unsafeRead v (i * n + k) b <- Vector.unsafeRead v (k * n + j) c <- Vector.unsafeRead v (i * n + j) Vector.unsafeWrite v (i * n + j) (min (a + b) c) }}} Built with `-O2` and with / without `-fllvm`. I'm using `vector-0.12.0.1`. Here are the timing results: GHC 8.2.2 no llvm: 1.7s llvm: 1.0s GHC 8.4.4 no llvm: 1.6s llvm: 0.9s GHC 8.6.2 no llvm: 4.8s llvm: 4.3s I'm using the following bash + nix script to gather theses timings: {{{#!bash nix-shell -p 'haskell.packages.ghc822.ghcWithPackages(p: [p.vector])' --run "ghc-pkg list | grep vector; ghc -O2 FloydBench.hs -Wall -fforce- recomp; time ./FloydBench" nix-shell -p 'haskell.packages.ghc822.ghcWithPackages(p: [p.vector])' -p llvm_39 --run "ghc-pkg list | grep vector; ghc -O2 FloydBench.hs -Wall -fforce-recomp -fllvm; time ./FloydBench" nix-shell -p 'haskell.packages.ghc844.ghcWithPackages(p: [p.vector])' --run "ghc-pkg list | grep vector; ghc -O2 FloydBench.hs -Wall -fforce- recomp; time ./FloydBench" nix-shell -p 'haskell.packages.ghc844.ghcWithPackages(p: [p.vector])' -p llvm_5 --run "ghc-pkg list | grep vector; ghc -O2 FloydBench.hs -Wall -fforce-recomp -fllvm; time ./FloydBench" nix-shell -p 'haskell.packages.ghc862.ghcWithPackages(p: [p.vector])' --run "ghc-pkg list | grep vector; ghc -O2 FloydBench.hs -Wall -fforce- recomp; time ./FloydBench" nix-shell -p 'haskell.packages.ghc862.ghcWithPackages(p: [p.vector])' -p llvm_6 --run "ghc-pkg list | grep vector; ghc -O2 FloydBench.hs -Wall -fforce-recomp -fllvm; time ./FloydBench" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16004> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #14180: Strange/bad error message binding unboxed type variable
by GHC 04 Feb '19

04 Feb '19

#14180: Strange/bad error message binding unboxed type variable -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.3 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# language TypeInType, TypeFamilies, MagicHash #-} import GHC.Exts type family MatchInt (f :: Int) :: () where MatchInt ('I# x) = '() }}} produces {{{ <interactive>:2:59: error: • Couldn't match a lifted type with an unlifted type When matching kinds k0 :: * Int# :: TYPE 'IntRep Expected kind ‘Int#’, but ‘x’ has kind ‘k0’ • In the first argument of ‘ 'I#’, namely ‘x’ In the first argument of ‘MatchInt’, namely ‘( 'I# x)’ In the type family declaration for ‘MatchInt’ }}} If, however, I replace `x` in the pattern with `_`, the type checker is satisfied. If I give it a pattern signature, {{{#!hs MatchInt ('I# (x :: Int#)) = '() }}} I get a different (and equally unhelpful) error message, {{{ • Expecting a lifted type, but ‘Int#’ is unlifted • In the kind ‘Int#’ In the first argument of ‘ 'I#’, namely ‘(x :: Int#)’ In the first argument of ‘MatchInt’, namely ‘( 'I# (x :: Int#))’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14180> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #13624: loadObj() does not respect alignment
by GHC 04 Feb '19

04 Feb '19

#13624: loadObj() does not respect alignment -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System (Linker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is perhaps known, but I'll write it down here in case somebody else runs into this problem as well. Since `loadObj()` just `mmap()`s the entire object file and decodes it ''in place'', it does not respect the alignment requirements specified in the section headers. This is problematic for instructions which require alignment, e.g. SSE, AVX. The attached `map.ll` program is `map (+1)` over an array of floating point numbers. In particular, the core loop is 8-way SIMD vectorised x 4-way unrolled, for 32-elements per loop iteration. A tail loop handles any remainder one-at-a-time. You can compile it using `llc -filetype=obj -mcpu=native map.ll`. For a CPU with AVX instructions (sandy bridge or later) you should get the following: {{{ $ objdump -d map.o Disassembly of section .text: 0000000000000000 <map>: 0: 49 89 f3 mov %rsi,%r11 3: 49 29 fb sub %rdi,%r11 6: 0f 8e f9 00 00 00 jle 105 <map+0x105> c: 49 83 fb 20 cmp $0x20,%r11 10: 0f 82 bd 00 00 00 jb d3 <map+0xd3> 16: 4d 89 da mov %r11,%r10 19: 49 83 e2 e0 and $0xffffffffffffffe0,%r10 1d: 4d 89 d9 mov %r11,%r9 20: 49 83 e1 e0 and $0xffffffffffffffe0,%r9 24: 0f 84 a9 00 00 00 je d3 <map+0xd3> 2a: 49 01 fa add %rdi,%r10 2d: 48 8d 44 ba 60 lea 0x60(%rdx,%rdi,4),%rax 32: 49 8d 7c b8 60 lea 0x60(%r8,%rdi,4),%rdi 37: c5 fc 28 05 00 00 00 vmovaps 0x0(%rip),%ymm0 # 3f <map+0x3f> 3e: 00 3f: 4c 89 c9 mov %r9,%rcx 42: 66 66 66 66 66 2e 0f data16 data16 data16 data16 nopw %cs:0x0(%rax,%rax,1) 49: 1f 84 00 00 00 00 00 50: c5 f8 10 4f a0 vmovups -0x60(%rdi),%xmm1 55: c5 f8 10 57 c0 vmovups -0x40(%rdi),%xmm2 5a: c5 f8 10 5f e0 vmovups -0x20(%rdi),%xmm3 5f: c5 f8 10 27 vmovups (%rdi),%xmm4 63: c4 e3 75 18 4f b0 01 vinsertf128 $0x1,-0x50(%rdi),%ymm1,%ymm1 6a: c4 e3 6d 18 57 d0 01 vinsertf128 $0x1,-0x30(%rdi),%ymm2,%ymm2 71: c4 e3 65 18 5f f0 01 vinsertf128 $0x1,-0x10(%rdi),%ymm3,%ymm3 78: c4 e3 5d 18 67 10 01 vinsertf128 $0x1,0x10(%rdi),%ymm4,%ymm4 7f: c5 f4 58 c8 vaddps %ymm0,%ymm1,%ymm1 83: c5 ec 58 d0 vaddps %ymm0,%ymm2,%ymm2 87: c5 e4 58 d8 vaddps %ymm0,%ymm3,%ymm3 8b: c5 dc 58 e0 vaddps %ymm0,%ymm4,%ymm4 8f: c4 e3 7d 19 48 b0 01 vextractf128 $0x1,%ymm1,-0x50(%rax) 96: c5 f8 11 48 a0 vmovups %xmm1,-0x60(%rax) 9b: c4 e3 7d 19 50 d0 01 vextractf128 $0x1,%ymm2,-0x30(%rax) a2: c5 f8 11 50 c0 vmovups %xmm2,-0x40(%rax) a7: c4 e3 7d 19 58 f0 01 vextractf128 $0x1,%ymm3,-0x10(%rax) ae: c5 f8 11 58 e0 vmovups %xmm3,-0x20(%rax) b3: c4 e3 7d 19 60 10 01 vextractf128 $0x1,%ymm4,0x10(%rax) ba: c5 f8 11 20 vmovups %xmm4,(%rax) be: 48 83 e8 80 sub $0xffffffffffffff80,%rax c2: 48 83 ef 80 sub $0xffffffffffffff80,%rdi c6: 48 83 c1 e0 add $0xffffffffffffffe0,%rcx ca: 75 84 jne 50 <map+0x50> cc: 4d 39 cb cmp %r9,%r11 cf: 75 05 jne d6 <map+0xd6> d1: eb 32 jmp 105 <map+0x105> d3: 49 89 fa mov %rdi,%r10 d6: 4c 29 d6 sub %r10,%rsi d9: 4a 8d 04 92 lea (%rdx,%r10,4),%rax dd: 4b 8d 0c 90 lea (%r8,%r10,4),%rcx e1: c5 fa 10 05 00 00 00 vmovss 0x0(%rip),%xmm0 # e9 <map+0xe9> e8: 00 e9: 0f 1f 80 00 00 00 00 nopl 0x0(%rax) f0: c5 fa 58 09 vaddss (%rcx),%xmm0,%xmm1 f4: c5 fa 11 08 vmovss %xmm1,(%rax) f8: 48 83 c0 04 add $0x4,%rax fc: 48 83 c1 04 add $0x4,%rcx 100: 48 ff ce dec %rsi 103: 75 eb jne f0 <map+0xf0> 105: c5 f8 77 vzeroupper 108: c3 req }}} The attached `test.c` will load the object file and try to execute it. The `#define N` on line 7 will change the size of the array. For fewer than 32 elements this works as expected (where the input array is [0..N-1]): {{{ $ ./build.sh + llc-4.0 -filetype=obj -mcpu=native map.ll + ghc --make -no-hs-main test.c $ ./a.out array size is 31 calling function... ok 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0 11.0 12.0 13.0 14.0 15.0 16.0 17.0 18.0 19.0 20.0 21.0 22.0 23.0 24.0 25.0 26.0 27.0 28.0 29.0 30.0 31.0 }}} For 32 elements or larger (i.e. entering the core loop) the program will (almost certainly) segfault. {{{ $ lldb a.out (lldb) target create "a.out" Current executable set to 'a.out' (x86_64). (lldb) run Process 7294 launched: '<snip>/a.out' (x86_64) array size is 32 calling function... Process 7294 stopped * thread #1: tid = 0xc41676, 0x000000010019f207, queue = 'com.apple.main- thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT) frame #0: 0x000000010019f207 -> 0x10019f207: vmovaps 0xe1(%rip), %ymm0 0x10019f20f: movq %r9, %rcx 0x10019f212: nopw %cs:(%rax,%rax) 0x10019f220: vmovups -0x60(%rdi), %xmm1 }}} The `VMOVAPS` instruction requires the source address to be 32-byte aligned. It is attempting to load 8 floats from one of the const sections (the ones for the +1), but since the section was not loaded at the required alignment, fails. I've tested this on x86_64 macOS (Mach-O) and ubuntu (ELF). I don't have any other systems to test on. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13624> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21