January 2017 - ghc-tickets

[GHC] #8733: I/O manager causes unnecessary syscalls in send/recv loops
by GHC 27 Aug '18

27 Aug '18

#8733: I/O manager causes unnecessary syscalls in send/recv loops ------------------------------------+------------------------------------- Reporter: tibbe | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime 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: | ------------------------------------+------------------------------------- Network applications often call send followed by recv, to send a message and then read an answer. This causes syscall traces like this one: {{{ recvfrom(13, ) -- Haskell thread A sendto(13, ) -- Haskell thread A recvfrom(13, ) = -1 EAGAIN -- Haskell thread A epoll_ctl(3, ) -- Haskell thread A (a job for the IO manager) recvfrom(14, ) -- Haskell thread B sendto(14, ) -- Haskell thread B recvfrom(14, ) = -1 EAGAIN -- Haskell thread B epoll_ctl(3, ) -- Haskell thread B (a job for the IO manager) }}} The recvfrom call always fails, as the response from the partner we're communicating with won't be available right after we send the request. We ought to consider descheduling the thread as soon as sending is "done". The hard part is to figure out when that is. See http://www.yesodweb.com/blog/2014/02/new-warp for a real world example. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8733> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #11470: Support changing cross compiler target at runtime
by GHC 25 Aug '18

25 Aug '18

#11470: Support changing cross compiler target at runtime -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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: -------------------------------------+------------------------------------- Relevant mailing list thread: https://mail.haskell.org/pipermail/ghc- devs/2016-January/011064.html At the moment, GHC's cross-compiling support requires you to build a cross-compiler for every target platform from scratch. (https://ghc.haskell.org/trac/ghc/wiki/CrossCompilation) There are two reasons for this: 1. GHC uses a configure script to interrogate the GCC toolchain about the vagaries of cross-compilation, some parameters of which get baked into various build system scripts and header files and such. Some of this information wends its way into the final built GHC executable. 2. GHC needs to build the boot libraries, using the stage 1 compiler, targeting the cross compiler. It would be very useful to move this configuration from configure time to run time, so that a user can use GHC as a cross-compiler without having to recompile GHC. That is, we would like to (1) ensure that any information from the configure script can alternately be supplemented at runtime, (2) that users can cross-compile the boot libraries on-demand (since GHC won't ship with the ARM versions of the boot libraries), and (3) rearchitect GHC internally so that it handles knows to keep separate the interface files/package database for various cross compilation targets. Such a change will make cross-compiling more convenient (the iOS cross- compiler currently requires GHC to be built twice, once for ARM and once for the simulator!) and will also pave the way for supporting Template Haskell and compiler plugins in the cross-compiler, since a GHC that knows how to deal with both the target and host platforms can simply ensure that it only loads code built for the host platform (a user can then, if necessary, build code twice, once for the host for Template Haskell, and once for the target). Unclear points of design: * How should GHC get the information about the GCC cross-compiler toolchain (which currently is gotten by `configure`?) Preferably, not by running a `configure` script every time you invoke it. What is this information anyway? * How should GHC rebuild the boot libraries? Maybe `cabal-install` can simply handle this for you. Note: please update the top of this ticket as the design becomes clearer. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11470> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #10346: Cross-module SpecConstr
by GHC 24 Aug '18

24 Aug '18

#10346: Cross-module SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Type-class specialisation now happens flawlessly across modules. That is, if I define {{{ module DefineF where f :: Num a => a -> a {-# INLINEABLE f #-} f x = ...f x'.... }}} then modules that import `DefineF` and call `f` at some particular type (say `Int`) will generate a specialised copy of `f`'s code. But this does not happen for `SpecConstr`; we only specialise a function for calls made in the same module. All the infrastructure is in place to allow cross-module `SpecConstr`; it just hasn't been done yet. This ticket is to record the idea. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10346> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #12695: Build failure due to MAP_NORESERVE being removed in FreeBSD 11.x and later
by GHC 24 Aug '18

24 Aug '18

#12695: Build failure due to MAP_NORESERVE being removed in FreeBSD 11.x and later -------------------------------------+------------------------------------- Reporter: abbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: FreeBSD Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While trying to build GHC 8.0.1 on FreeBSD 11.x, I come across following compiler error: {{{ /usr/local/bin/clang-cpp38 -DPROFILING -DTHREADED_RTS -DDEBUG -fno- stack-protector -O2 -pipe -Qunused-arguments -I/usr/local/include -fstack-protector -fno-strict-aliasing -Wall -Wall -Wextra -Wstrict- prototypes -Wmissing-prototypes -Wmissing-declarations -Winline -Waggregate-return -Wpointer-arith -Wmissing-noreturn -Wnested-externs -Wredundant-decls -Iincludes -Iincludes/dist -Iincludes/dist- derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -fno-strict-aliasing -fno-common -Irts/dist/build/autogen -Wno-unknown-pragmas -O2 -fomit-frame- pointer -g -DRtsWay=\"rts_v\" -MM -x c rts/posix/OSMem.c -MF rts/dist/build/.depend-v-p-dyn-l-debug-thr-thr_debug-thr_l-thr_p- debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit rts/posix/OSMem.c:158:5: error: USE_LARGE_ADDRESS_SPACE needs MAP_NORESERVE # error USE_LARGE_ADDRESS_SPACE needs MAP_NORESERVE ^ 1 error generated. }}} From some [https://svnweb.freebsd.org/base/head/sys/sys/mman.h?r1=273249&r2=273250& investigation], it turns out when it was there, it was not even implemented. The value of `__FreeBSD_version` (in case you plan to add conditional based on it), where it is [https://svnweb.freebsd.org/base/head/sys/sys/param.h?r1=273250&r2=273249&pa… changed] is `1100039`. Let me know if you need more information. Thanks for looking -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12695> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11474: incorrect redundant-constraints warning
by GHC 24 Aug '18

24 Aug '18

#11474: incorrect redundant-constraints warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code when compiled with GHC 8 {{{#!hs {-# LANGUAGE Haskell2010, FunctionalDependencies, KindSignatures, ScopedTypeVariables, TypeOperators, UndecidableInstances #-} import GHC.Generics data Options data Value newtype Tagged s b = Tagged {unTagged :: b} class GToJSON f where gToJSON :: Options -> f a -> Value class SumToJSON f allNullary where sumToJSON :: Options -> f a -> Tagged allNullary Value class AllNullary (f :: * -> *) allNullary | f -> allNullary instance ( AllNullary (a :+: b) allNullary, -- <- removing this line causes a compile error SumToJSON (a :+: b) allNullary ) => GToJSON (a :+: b) where gToJSON opts = (unTagged :: Tagged allNullary Value -> Value) . sumToJSON opts }}} emits a warning {{{ bug.hs:19:10: warning: • Redundant constraint: AllNullary (a :+: b) allNullary • In the instance declaration for ‘GToJSON (a :+: b)’ }}} when commenting out the `AllNullary` constraint, this however results the compile error {{{ bug.hs:19:10: error: • Could not deduce (SumToJSON (a :+: b) allNullary0) from the context: SumToJSON (a :+: b) allNullary bound by an instance declaration: SumToJSON (a :+: b) allNullary => GToJSON (a :+: b) at redconstr.hs:(19,10)-(22,24) The type variable ‘allNullary0’ is ambiguous • In the ambiguity check for an instance declaration To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the instance declaration for ‘GToJSON (a :+: b)’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11474> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #9688: Improve the interaction between CSE and the join point transformation
by GHC 24 Aug '18

24 Aug '18

#9688: Improve the interaction between CSE and the join point transformation -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: CSE | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- It appears that the join point transformation sometimes interferes with CSE when CSE would be much better. Two examples: === digitToIntMaybe === Suppose we define {{{#!hs isHexDigit :: Char -> Bool isHexDigit c = (fromIntegral (ord c - ord '0')::Word) <= 9 || (fromIntegral (ord c - ord 'a')::Word) <= 5 || (fromIntegral (ord c - ord 'A')::Word) <= 5 digitToInt c | (fromIntegral dec::Word) <= 9 = dec | (fromIntegral hexl::Word) <= 5 = hexl + 10 | (fromIntegral hexu::Word) <= 5 = hexu + 10 | otherwise = error ("Char.digitToInt: not a digit " ++ show c) -- sigh where dec = ord c - ord '0' hexl = ord c - ord 'a' hexu = ord c - ord 'A' -- We could also expand this out in cases manually, but it makes no -- difference as far as I can tell. }}} Suppose we then write a naive `digitToIntMaybe` function: {{{#!hs digitToIntMaybe c | isHexDigit c = Just (digitToInt c) | otherwise = Nothing }}} What I would want this to do is "zip" the nested cases and give Core like this: {{{ $wdigitToIntMaybe $wdigitToIntMaybe = \ ww_s2Ag -> let { x#_a2yy x#_a2yy = -# (ord# ww_s2Ag) 48 } in case tagToEnum# (leWord# (int2Word# x#_a2yy) (__word 9)) of _ { False -> let { x#1_X2z7 x#1_X2z7 = -# (ord# ww_s2Ag) 97 } in case tagToEnum# (leWord# (int2Word# x#1_X2z7) (__word 5)) of _ { False -> let { x#2_X2zh x#2_X2zh = -# (ord# ww_s2Ag) 65 } in case tagToEnum# (leWord# (int2Word# x#2_X2zh) (__word 5)) of _ { False -> Nothing; True -> Just (I# (+# x#2_X2zh 10)) }; True -> Just (I# (+# x#1_X2z7 10)) }; True -> Just (I# x#_a2yy) } digitToIntMaybe digitToIntMaybe = \ w_s2Ad -> case w_s2Ad of _ { C# ww1_s2Ag -> $wdigitToIntMaybe ww1_s2Ag } }}} But instead, the join point transformation triggers, and we get this: {{{ digitToIntMaybe1 digitToIntMaybe1 = \ ww_s2Cp -> error (unpackAppendCString# "Char.digitToInt: not a digit "# ($w$cshowsPrec15 ww_s2Cp ([]))) $wdigitToIntMaybe $wdigitToIntMaybe = \ ww_s2Cp -> let { $j_s2Bc $j_s2Bc = \ _ -> Just (let { a_s2B5 a_s2B5 = int2Word# (-# (ord# ww_s2Cp) 48) } in case tagToEnum# (leWord# a_s2B5 (__word 9)) of _ { False -> let { a1_s2B7 a1_s2B7 = int2Word# (-# (ord# ww_s2Cp) 97) } in case tagToEnum# (leWord# a1_s2B7 (__word 5)) of _ { False -> let { a2_s2B9 a2_s2B9 = int2Word# (-# (ord# ww_s2Cp) 65) } in case tagToEnum# (leWord# a2_s2B9 (__word 5)) of _ { False -> digitToIntMaybe1 ww_s2Cp; True -> I# (+# (word2Int# a2_s2B9) 10) }; True -> I# (+# (word2Int# a1_s2B7) 10) }; True -> I# (word2Int# a_s2B5) }) } in case tagToEnum# (leWord# (int2Word# (-# (ord# ww_s2Cp) 48)) (__word 9)) of _ { False -> case tagToEnum# (leWord# (int2Word# (-# (ord# ww_s2Cp) 97)) (__word 5)) of _ { False -> case tagToEnum# (leWord# (int2Word# (-# (ord# ww_s2Cp) 65)) (__word 5)) of _ { False -> Nothing; True -> $j_s2Bc void# }; True -> $j_s2Bc void# }; True -> $j_s2Bc void# } digitToIntMaybe digitToIntMaybe = \ w_s2Cm -> case w_s2Cm of _ { C# ww1_s2Cp -> $wdigitToIntMaybe ww1_s2Cp } }}} We perform the same three tests twice each, and test for an error condition that obviously can't happen. === `quotRem` and `divMod` === If we define {{{#!hs x `quot` y = fst (x `quotRem` y) x `rem` y = snd (x `quotRem` y) }}} and then write something like {{{#!hs f x y | x `rem` y == 0 = x `quot` y | otherwise = 17 }}} then CSE works some magic and we only calculate `quotRem x y` once. Unfortunately, if we do this: {{{#!hs whatever x y = if x `myRem` y == 0 then (x `myQuot` y) + 14 else x `myQuot` y }}} then the join point transformation fires, collecting the `myQuot x y` expressions in the case branches and preventing CSE from recognizing the much better opportunity to eliminate those calculations altogether. The situation with `divMod` is much worse. The join point transformation applied to the cases defining `divMod` prevents CSE from working magic on it in even simple situations, unless one of the arguments is known, making this definition unusable (the resulting Core is too horrifyingly long to paste here). It would probably be possible to improve the `divMod` situation to something close to the `quotRem` one by making `divMod` `NOINLINE` and adding special `divModLit` rules, but I'd much rather see a general solution. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9688> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10100: Bogus "redundant constraint" warning with functional dependencies
by GHC 23 Aug '18

23 Aug '18

#10100: Bogus "redundant constraint" warning with functional dependencies -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Compiling this code with GHC HEAD: {{{#!hs {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE UndecidableInstances #-} module T10100 where data Zero data Succ a class Add a b ab | a b -> ab, a ab -> b instance Add Zero b b instance (Add a b ab) => Add (Succ a) b (Succ ab) }}} Gives a bogus warning about redundant constraint: {{{ Redundant constraint: Add a b ab In the instance declaration for ‘Add (Succ a) b (Succ ab)’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10100> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12674: GHC doesn't handle ./ prefixed paths correctly
by GHC 22 Aug '18

22 Aug '18

#12674: GHC doesn't handle ./ prefixed paths correctly -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC doesn't correctly handle paths preceded by `./` on the command line, if their first character (after any number of `./`s) is a `-`. For instance, `ghc ./-a.hs` fails, even if `a.hs` exists. Somewhere, `./-a.hs` is being converted to `-a.hs`. I have not been able to figure out where this happens. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12674> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #11409: Cannot instantiate literals using TypeApplications
by GHC 22 Aug '18

22 Aug '18

#11409: Cannot instantiate literals using TypeApplications -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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: -------------------------------------+------------------------------------- {{{ GHCi, version 8.0.1.20160110: http://www.haskell.org/ghc/ :? for help Prelude> :set -XTypeApplications -fprint-explicit-foralls Prelude> :t 42 42 :: forall {a}. Num a => a Prelude> 42 @Int <interactive>:3:1: error: • Cannot not apply expression of type ‘a0’ to a visible type argument ‘Int’ • In the expression: 42 @Int In an equation for ‘it’: it = 42 @Int }}} (Also, "cannot not" looks like a typo.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11409> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 29

[GHC] #10869: Option to dump preprocessed source
by GHC 22 Aug '18

22 Aug '18

#10869: Option to dump preprocessed source -------------------------------------+------------------------------------- Reporter: phischu | Owner: Type: feature | Status: new request | Priority: low | Milestone: Component: Driver | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- It would be awesome if GHC had an option `-ddump-preprocessed` that dumps the source code for each module after preprocessing. I am not sure what the current definition of "preprocessing" is but I mean the output of at least the following tools: happy, alex, c2hs, hsc2hs and cpp. Additionally even if a module was not subject to any preprocessing it should be dumped anyway. Use case: I want to parse module files from packages from hackage with `haskell-src-exts` but find it prohibitively difficult to get the preprocessing right. The idea is that after `cabal install` with ghc options `-ddump-preprocessed -ddump-to-file -dumpdir real_modules` you get a complete working set of haskell modules that can be parsed directly without any preprocessing in folder `real_modules`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10869> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16