November 2014 - ghc-tickets

Re: [GHC] #5364: Access RTS flag values from inside Haskell programs
by GHC 18 Nov '14

18 Nov '14

#5364: Access RTS flag values from inside Haskell programs -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ekmett Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.3 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D306 | -------------------------------------+------------------------------------- Changes (by thomie): * cc: core-libraries-committee@… (added) * differential: => Phab:D306 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5364#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3827: Compiling fails on linux-powerpc
by GHC 18 Nov '14

18 Nov '14

#3827: Compiling fails on linux-powerpc ----------------------------------------------+--------------------------- Reporter: speleologic | Owner: Type: bug | Status: closed Priority: normal | Milestone: ⊥ Component: Build System | Version: 6.12.1 Resolution: worksforme | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Changes (by thomie): * status: new => closed * difficulty: => Unknown * component: Compiler => Build System * resolution: => worksforme Comment: Closing this 5 year old ticket. Probably a lot has change since then, and #8437 leads me to believe the powerpc build actually worked quite recently. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3827#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8437: pprCallishMachOp_for_C: MO_Prefetch_Data 0 not supported
by GHC 18 Nov '14

18 Nov '14

#8437: pprCallishMachOp_for_C: MO_Prefetch_Data 0 not supported -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build | Version: 7.7 System | Keywords: Resolution: fixed | Architecture: powerpc64 Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Building | Related Tickets: GHC failed | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * failure: None/Unknown => Building GHC failed * component: Compiler => Build System * resolution: => fixed Comment: Replying to [comment:2 rwbarton]: > Ideally, you would output a `__builtin_prefetch` call where `rw` is 0, `locality` is the argument of the `MO_Prefetch_Data` constructor, and `addr` comes from the `args` field of the `CmmUnsafeForeignCall`. That looks pretty easy to do, by adding another special case for `fn_addr` and sending `MO_Prefetch_Data _` to `__builtin_prefetch` in `pprCallishMachOp_for_C`. Please open a new task ticket if that is still needed. Commit 896cee02e766c687a52cd75382bcfed64a623619 should have fixed the powerpc64 build, so I'm closing this ticket if you agree. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8437#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8438: Validation failure compiling primitive-memops.c
by GHC 18 Nov '14

18 Nov '14

#8438: Validation failure compiling primitive-memops.c -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build | Version: 7.7 System | Keywords: Resolution: worksforme | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Building | Related Tickets: GHC failed | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * failure: None/Unknown => Building GHC failed * component: Compiler => Build System * resolution: => worksforme -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8438#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8447: A combination of type-level comparison and subtraction does not work for 0
by GHC 18 Nov '14

18 Nov '14

#8447: A combination of type-level comparison and subtraction does not work for 0 -------------------------------------+------------------------------------- Reporter: nushio | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Operating System: Linux Keywords: | Type of failure: GHC rejects Architecture: Unknown/Multiple | valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- The following function on type level naturals {{{ Diff x y = If (x <=? y) (y-x) (x-y) }}} does not work when either x or y is 0. https://github.com/nushio3/practice/blob/ea8a1716b1d6221ce32d77432b6de3f38e… /type-nats/int-bug.hs I've tested this code on ghc 7.7.20130926 since I couldn't build the really latest ghc. I'm sorry if it is already fixed on the ghc head. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8447> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8442: Cabal-install internal error with any use
by GHC 18 Nov '14

18 Nov '14

#8442: Cabal-install internal error with any use ----------------------------------+--------------------------------- Reporter: senk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.6.3 Keywords: | Operating System: FreeBSD Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------- Any attempt to use cabal-install fails with an internal error. Used FreeBSD (9.1) port hs-haskell-platform and built with hs-colour support, LLVM (3.2) backend, and profiling enabled. Warnings were given that the version of LLVM used was untested, but no issues were apparent when compiling. {{{ cabal install hakyll cabal-install: internal error: evacuate(static): strange closure type -385875968 (GHC version 7.6.3 for x86_64_portbld_freebsd) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort trap }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8442> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8465: ./configure fails on ghc-7.6.3: does not find installed libgmp.so.3 and current directory
by GHC 18 Nov '14

18 Nov '14

#8465: ./configure fails on ghc-7.6.3: does not find installed libgmp.so.3 and current directory ------------------------------------+------------------------------------- Reporter: ygramoel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I am trying to reproduce bug #8464 with the newest ghc; not available in my repositories, so I am trying to install it manually. With a freshly downloaded and unpacked ghc-7.6.3-x86_64-unknown- linux.tar.bz2, and after cleanly installing libgmp.3 (from source of gmp-4.3.1) johan@morla:~/work/ghc-7.6.3\> ./configure checking for path to top of build tree... utils/ghc-pwd/dist- install/build/tmp/ghc-pwd: error while loading shared libraries: libgmp.so.3: cannot open shared object file: No such file or directory configure: error: cannot determine current directory johan@morla:~/work/ghc-7.6.3\> pwd -P /home/johan/work/ghc-7.6.3 johan@morla:~/work/ghc-7.6.3\> whereis libgmp libgmp: /usr/local/lib/libgmp.la /usr/local/lib/libgmp.a /usr/local/lib/libgmp.so johan@morla:~/work/ghc-7.6.3\> ls -l /usr/local/lib/libgmp* -rw-r--r-- 1 root root 1017334 Oct 20 20:56 /usr/local/lib/libgmp.a -rwxr-xr-x 1 root root 785 Oct 20 20:56 /usr/local/lib/libgmp.la lrwxrwxrwx 1 root root 15 Oct 20 20:56 /usr/local/lib/libgmp.so -> libgmp.so.3.5.0 lrwxrwxrwx 1 root root 15 Oct 20 20:56 /usr/local/lib/libgmp.so.3 -> libgmp.so.3.5.0 -rwxr-xr-x 1 root root 403890 Oct 20 20:56 /usr/local/lib/libgmp.so.3.5.0 johan@morla:~/work/ghc-7.6.3\> -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8465> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8477: Allow inferring ambiguous types
by GHC 18 Nov '14

18 Nov '14

#8477: Allow inferring ambiguous types ------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 8390 | ------------------------------------+------------------------------------- Previous versions of ghc could infer types that are potentially ambiguous. This allowed things like http://okmij.org/ftp/Haskell/TypeLambdaVal.hs or assigning keyword args functions to variables http://code.haskell.org/~aavogt/HList/docs/HList/Data-HList-Keyword.html. Presently (7.6 and 7.7), you need to write a type signature yourself to allow such definitions, which in these situations doubles the amount of code to write. For the keyword case, the workaround is to use the kw function to apply the keyword function instead of ordinary function application. More related discussion http://www.haskell.org/pipermail/glasgow-haskell- users/2013-October/024404.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8477> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8490: OS X 10.9 gcc-4.8 unknown symbol `__objc_empty_table`
by GHC 18 Nov '14

18 Nov '14

#8490: OS X 10.9 gcc-4.8 unknown symbol `__objc_empty_table` ----------------------------------+--------------------------------------- Reporter: jloos | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------------- I'm not sure if and how far the ghc-7.6.3 support for OS X is planned, but I hit a (possible) linker error with 7.6.3. I installed a homebrew gcc-4.8 and changed the ghc config to use it. I tried to compile the [http://hackage.haskell.org/package/bindings-GLFW bindings-GLFW] package, which was successful, and run `cabal test` on it, which fails with following error: {{{ final link ... ghc: lookupSymbol failed in relocateSection (relocate external) dist/build/HSbindings-GLFW-3.0.3.o: unknown symbol `__objc_empty_vtable' linking extra libraries/objects failed }}} After some research I discovered that this symbol (surely just the first which fails) is part of the Objective-C Runtime. The /usr/lib/libobjc.dylib exports this symbol. In desperation I think I nearly reached the google quota with my research, further steps I tried: Explicitly link the libobjc lib {{{ ghci -lobjc dist/build/HSbindings-GLFW-3.0.3.o -framework Foundation -framework Cocoa -framework IOKit }}} With the same result as above: {{{ GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading object (static) dist/build/HSbindings-GLFW-3.0.3.o ... done Loading object (dynamic) /usr/lib/libobjc.dylib ... done Loading object (framework) IOKit ... done Loading object (framework) Cocoa ... done Loading object (framework) Foundation ... done final link ... ghc: lookupSymbol failed in relocateSection (relocate external) dist/build/HSbindings-GLFW-3.0.3.o: unknown symbol `__objc_empty_vtable' linking extra libraries/objects failed }}} I found a [https://github.com/mxcl/homebrew/issues/23687 homebrew issue] related to gcc and the Apple switch from libstdc++to libc++ in 10.9 and i tried to force linking with explicit `-stdlib=libstdc++` in the cabal file (ld-options). But i guess this issue isn't related to the `__objc_***` problem, just tried it in desperation. Last week I managed to build ghc HEAD with clang bootstrapped with 7.4.6: the new linker mechanic seems to resolves this problem in a way (sadly some other packages aren't jet compatible with 7.8) So I'm not sure if this report is okay, if not, pardon me :) I'm aware of the problems with the current ghc-7.6.3 and the the changes OS X 10.9 brings with it (according to reddit/haskell cafe). The current suggestions is to not use the XCode-5.0.1/clang together with ghc-7.6.3. So I tried gcc from homebrew. I know that 7.8 will bring better linker capabilities, maybe there are just some flags to fix this specific problem with 7.6.3...? I didn't find it. So I thought it's better to report it. If further informations are required, I will try to provide them as fast as possible but I will have to downgrade to 10.8 tomorrow around 6 a.m. UTC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8490> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9391: LLVM 3.2 crash (AVX messes up GHC calling convention)
by GHC 18 Nov '14

18 Nov '14

#9391: LLVM 3.2 crash (AVX messes up GHC calling convention) -------------------------------------+------------------------------------- Reporter: scpmw | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.8.2 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Runtime Difficulty: Easy (less than 1 | crash hour) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- I stumbled across the problem of LLVM 3.2 builds seemingly randomly crashing on my Mac. After quite a bit of investigation I found that the source of the problem was somewhere in the `base` library (`span` to be precise), where it encountered Cmm like follows: {{{ cp7n: if ((Sp + -56) < SpLim) goto cp8c; else goto cp8d; ... cp8d: I64[Sp - 40] = block_cp7g_info; _smKL::P64 = P64[R1 + 7]; _smKO::P64 = P64[R1 + 15]; _smKP::P64 = P64[R1 + 23]; _smL0::P64 = P64[R1 + 31]; R1 = R2; P64[Sp - 32] = _smKL::P64; P64[Sp - 24] = _smKO::P64; P64[Sp - 16] = _smKP::P64; P64[Sp - 8] = _smL0::P64; Sp = Sp - 40; if (R1 & 7 != 0) goto up8R; else goto cp7h; up8R: call block_cp7g_info(R1) args: 0, res: 0, upd: 0; ... }}} which leads LLVM 3.2 to produce the following assembly: {{{ _smL1_info: ## @smL1_info ## BB#0: ## %cp7n pushq %rbp movq %rsp, %rbp movq %r14, %rax movq %rbp, %rcx leaq -56(%rcx), %rdx cmpq %r15, %rdx jae LBB160_1 ... LBB160_1: ## %cp8d leaq _cp7g_info(%rip), %rdx movq %rdx, -40(%rcx) vmovups 7(%rbx), %ymm0 vmovups %ymm0, -32(%rcx) addq $-40, %rcx testb $7, %al je LBB160_4 ## BB#2: ## %up8R movq %rcx, %rbp movq %rax, %rbx popq %rbp vzeroupper jmp _cp7g_info ## TAILCALL }}} So here LLVM has figured out that it can use `vmovups` in order to move 4 words at the same time. However, there is a puzzling side effect: All of sudden we have a `pushq %rbp` at the start of the function with a matching `popq %rbp` at the very end. This overwrites the stack pointer update (`movq %rcx, %rbp`) and - unsurprisingly - causes the program to crash rather quickly. My interpretation is that LLVM 3.2 erroneously thinks that AVX instructions are incompatible with frame pointer elimination. The reasoning is that this is exactly the kind of code LLVM generates if we disable this "optimisation" (`--disable-fp-elim`). Furthermore, disabling AVX instructions (`-mattr=-avx`) fixes the problem - LLVM falls back to the less efficient `movups`, with `pushq $rbp` vanishing as well. Finally, this bug seems to happen exactly with LLVM 3.2, with 3.3 upwards generating correct code. My proposed fix would be to add `-mattr=-avx` to the `llc` command line by default for LLVM 3.2. This issue might be related to #7694. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9391> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7