November 2017 - ghc-tickets

[GHC] #12372: bug: documentation for Control.Monad.guard not useful after AMP
by GHC 14 Dec '17

14 Dec '17

#12372: bug: documentation for Control.Monad.guard not useful after AMP -------------------------------------+------------------------------------- Reporter: ntc2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Since the AMP refactor, the documentation for `Control.Monad.guard` [1] is no longer useful for beginners. It simply gives the definition of `guard`, but in prose: {{{ guard b is pure () if b is True, and empty if b is False. }}} (and better to just use Haskell instead of prose here, no?) To use `guard` in a `MonadPlus`, you now need to know that `Alternative` is a super class of `MonadPlus`, and that `mzero = zero`. The documentation [2] for `MonadPlus` doens't mention `mzero = zero` in the default definition -- you must look at the source for that -- and the docs for `guard` don't mention `MonadPlus`. The documentation for `Control.Monad.guard` should suggest use with `MonadPlus`, and give an example (compare with the very helpful example for `Control.Monad.when`). A non-monadic example would also be useful. [1] https://hackage.haskell.org/package/base-4.9.0.0/docs/Control- Monad.html#v:guard [2] https://hackage.haskell.org/package/base-4.9.0.0/docs/Control- Monad.html#t:MonadPlus -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12372> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9364: GHCi (or haskeline?) confused by non-single-width characters
by GHC 14 Dec '17

14 Dec '17

#9364: GHCi (or haskeline?) confused by non-single-width characters -------------------------------------+------------------------------------- Reporter: cheater | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Keywords: linux, terminal, | Operating System: colour, color, prompt | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Hi, there's an issue in the GHCi prompt. To reproduce: 1. Do everything in Linux (I don't have other operating systems); I'm using a version of the gnome 2 gnome-terminal. 2. Use the following to colourise the prompt in GHCi: echo -e :set prompt '"\033[32;1m%s\033[34;1m>\033[0m "' >> ~/.ghc/ghci.conf 3. Import quite a few modules (say, 5 to 10 should be enough) 4. Give the prompt enough text that it wraps around. It's best if you start the text with -- so that it's a comment and doesn't produce any output. For example, say I entered "-- bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb", I now see the following: *Types Control.Monad.Writer Control.Monad Data.Functor Control.Applicative Data.Monoid> -- bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb (do note that the first set of b's is located on the same line as the prompt, and the second is located under the prompt) 5. Press Enter. You should now see: *Types Control.Monad.Writer Control.Monad Data.Functor Control.Applicative Data.Monoid> -- bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb *Types Control.Monad.Writer Control.Monad Data.Functor Control.Applicative Data.Monoid> 6. Press Ctrl-P or the up arrow key to select the previous history item. You will now see the following: *Types Control.Monad.Writer Control.Monad Data.Functor Control.Applicative Data.Monoid> -- bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb *Types Control.Monad.Writer Control.Monad Data.Functor Control.Applicative Data.Monoid> -- bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 7. Press Ctrl-A or the Home cursor key to go to the beginning of the text entry, and then type X. You will now see the last prompt to be: *Types Control.Monad.Writer Control.Monad Data.Functor Control.Applicative Data.Monoid> -- bbbbbbbbbbbbX-- bbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 8. If you press Enter, you will find out that prompt was actually (without line breaks): X-- bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb I tried resizing the terminal window to 45 chars to make the lines above shorter; I imported Data.Monoid and Data.Functor in a new GHCi. The prompt contained garbage, most likely badly wrapped escape codes. See attachment. As both likely are a single bug in disguise, I include both reports in this ticket. Creating a test case for whether things actually work in a terminal might be difficult, but creating test for whether things get wrapped correctly (and not testing how things work out in a terminal) should be simple if annoying. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9364> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14448: CircleCI can't build on OS X
by GHC 13 Dec '17

13 Dec '17

#14448: CircleCI can't build on OS X -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: None | Version: 8.2.1 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: -------------------------------------+------------------------------------- As mentioned in [[https://github.com/ghc/ghc/pull/83]] CircleCI seems to have trouble with OS X builds. They invariably end in one of a few ways, * it hangs * it is "cancelled" with CircleCI issuing the vague warning that there was "an issue while running this container" Fuuzetsu has raised the issue with CircleCI support. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14448> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14409: Split GHC(-API) into multiple packages
by GHC 13 Dec '17

13 Dec '17

#14409: Split GHC(-API) into multiple packages -------------------------------------+------------------------------------- Reporter: Lemming | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 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: -------------------------------------+------------------------------------- Current GHC-API is pretty monolithic and a lot of data is hidden in monads. I'd prefer to have cleanly separated packages for parser, module system, type-checker, optimizer, code generator, linker. E.g. Haddock would certainly only use the first two, maybe three, steps. Advanced editing features in an IDE would use only the first three steps. A compiler for a Haskell dialect might use only optimizer and code generator. The packages should have clean interfaces. E.g. it should be possible to enter a Text or String into the parser and get a ByteString containing code or a pointer to executable code in memory from the code generator, with no need to write temporary files. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14409> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14126: Two Failing Test Cases in HEAD
by GHC 12 Dec '17

12 Dec '17

#14126: Two Failing Test Cases in HEAD -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.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: -------------------------------------+------------------------------------- In a freshly cloned GHC code base (c6462ab0...), in my system,`make test TEST="T13780c T13822"` fails.That is while `./validate` passes. Specifically, I follow the following steps: (1) `git clone --recursive git://git.haskell.org/ghc.git` (2) `cd ghc` (3) `cp mk/build.mk.sample mk/build.mk` (4) set `BuildFlavour = devel2` and then (5) ./boot (6) ./configure (7) make -j4 (8) make test TEST="T13780c T13822" I build in a variant of the docker image for GHC development on Linux (64 bit), if it matters. As it seems, @alanz also gets the similar result on his system. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14126> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13210: Can't run terminfo code in GHCi on Windows
by GHC 12 Dec '17

12 Dec '17

#13210: Can't run terminfo code in GHCi on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.2 System (Linker) | Keywords: | Operating System: Windows Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It's possible this is a duplicate of another runtime linker on Windows issue out there, but I'll post this just in case this really is a unique case. I was attempting to compile the `terminfo` library on Windows, and I actually made it surprisingly far--but I quickly stumbled when I actually tried to run some code in GHCi. First, make sure you have a native Windows version of `ncurses` installed. On MSYS2: {{{ $ pacman -S mingw-w64-x86_64-ncurses }}} And here's a stripped-down version of `terminfo`, which I'll use to demonstrate the bug: {{{#!hs module Main where import Control.Exception import Foreign import Foreign.C.String import Foreign.C.Types data TERMINAL newtype Terminal = Terminal (ForeignPtr TERMINAL) -- Use "unsafe" to make set_curterm faster since it's called quite a bit. foreign import ccall unsafe set_curterm :: Ptr TERMINAL -> IO (Ptr TERMINAL) foreign import ccall "&" del_curterm :: FunPtr (Ptr TERMINAL -> IO ()) foreign import ccall setupterm :: CString -> CInt -> Ptr CInt -> IO () setupTerm :: String -> IO Terminal setupTerm term = withCString term $ \c_term -> with 0 $ \ret_ptr -> do -- NOTE: I believe that for the way we use terminfo -- (i.e. custom output function) -- this parameter does not affect anything. let stdOutput = 1 -- Save the previous terminal to be restored after calling setupterm. old_term <- set_curterm nullPtr -- Call setupterm and check the return value. setupterm c_term stdOutput ret_ptr ret <- peek ret_ptr if (ret /=1) then throwIO $ SetupTermError $ "Couldn't look up terminfo entry " ++ show term else do cterm <- set_curterm old_term fmap Terminal $ newForeignPtr del_curterm cterm data SetupTermError = SetupTermError String instance Show SetupTermError where show (SetupTermError str) = "setupTerm: " ++ str instance Exception SetupTermError where main :: IO () main = do Terminal t <- setupTerm "xterm" print t }}} If you compile this code, it "works" (in the sense that it'll actually call the C code): {{{ $ ghc -lncursesw Terminfo.hs [1 of 1] Compiling Main ( Terminfo.hs, Terminfo.o ) Linking Terminfo.exe ... $ ./Terminfo Terminfo.exe: setupTerm: Couldn't look up terminfo entry "xterm" }}} But attempting to run the same code in GHCi is a disaster: {{{ $ runghc -lncursesw Terminfo.hs ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `nanosleep' ghc.exe: Could not on-demand load symbol '_nc_cookie_init' ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `_nc_cookie_init' ghc.exe: Could not on-demand load symbol '.refptr._nc_wacs' ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `.refptr._nc_wacs' ghc.exe: Could not on-demand load symbol '_nc_WIN_DRIVER' ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `_nc_WIN_DRIVER' ghc.exe: Could not on-demand load symbol '_nc_get_driver' ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `_nc_get_driver' ghc.exe: Could not on-demand load symbol '_nc_setupterm_ex' ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `_nc_setupterm_ex' ghc.exe: Could not on-demand load symbol 'newterm' ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `newterm' ghc.exe: Could not on-demand load symbol '.refptr._nc_globals' ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `.refptr._nc_globals' ghc.exe: Could not on-demand load symbol '_nc_err_abort' ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `_nc_err_abort' ghc.exe: Could not on-demand load symbol 'tparm' ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `tparm' ghc.exe: Could not on-demand load symbol '.refptr._nc_prescreen' ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `.refptr._nc_prescreen' ghc.exe: Could not on-demand load symbol '_nc_outch_sp' ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `_nc_outch_sp' ghc.exe: Could not on-demand load symbol '.refptr._nc_outch_sp' ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `.refptr._nc_outch_sp' ghc.exe: Could not on-demand load symbol '_nc_scrolln_sp' ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `_nc_scrolln_sp' ghc.exe: Could not on-demand load symbol '.refptr.SP' ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `.refptr.SP' ghc.exe: Could not on-demand load symbol '.refptr.cur_term' ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `.refptr.cur_term' ghc.exe: Could not on-demand load symbol '_nc_ospeed' ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `_nc_ospeed' ghc.exe: Could not on-demand load symbol 'set_curterm' Terminfo.hs: ByteCodeLink: can't find label During interactive linking, GHCi couldn't find the following symbol: set_curterm This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs(a)haskell.org }}} Also reproducible on GHC HEAD. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13210> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9669: Long compile time/high memory usage for modules with many deriving clauses
by GHC 12 Dec '17

12 Dec '17

#9669: Long compile time/high memory usage for modules with many deriving clauses -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Compile- Difficulty: Unknown | time performance bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I've seen many different people complain about this in various different contexts. One of the most common I personally see is when using Persistent with a large number of entities, which results in multi-minute build times for that single module. Usually, these reports have come from private repositories, which makes for a difficult repro. Also, the usage of Template Haskell in those modules tends to confuse the issue. So I'd like to report this issue from a completely separate project, with the guess that this represents an issue that is affecting many other users. Steps to reproduce: * `cabal unpack fpco-api-1.2.0.1` * `cd fpco-api-1.2.0.1` * `cabal install` * `ghc --make -isrc/library src/library/FP/API/Types.hs` * `touch src/library/FP/API/Types.hs` Then, to see the time and memory usage of compiling just the one module, run: * `time ghc -O2 --make -isrc/library src/library/FP/API/Types.hs +RTS -s` On my system (16GB RAM, quadcore i7), the results are: {{{ $ time ghc -O2 --make -isrc/library src/library/FP/API/Types.hs +RTS -s [3 of 3] Compiling FP.API.Types ( src/library/FP/API/Types.hs, src/library/FP/API/Types.o ) 51,846,533,568 bytes allocated in the heap 6,799,246,288 bytes copied during GC 389,297,584 bytes maximum residency (22 sample(s)) 11,330,472 bytes maximum slop 1041 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 2041 colls, 0 par 9.19s 9.19s 0.0045s 0.0998s Gen 1 22 colls, 0 par 4.33s 4.33s 0.1969s 0.5436s TASKS: 4 (1 bound, 3 peak workers (3 total), using -N1) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.00s ( 0.00s elapsed) MUT time 34.21s ( 37.74s elapsed) GC time 13.52s ( 13.53s elapsed) EXIT time 0.07s ( 0.07s elapsed) Total time 47.81s ( 51.34s elapsed) Alloc rate 1,515,662,937 bytes per MUT second Productivity 71.7% of total user, 66.8% of total elapsed gc_alloc_block_sync: 0 whitehole_spin: 0 gen[0].sync: 0 gen[1].sync: 0 real 0m51.375s user 0m50.864s sys 0m0.456s }}} By contrast, with optimizations turned off: {{{ $ time ghc -O0 --make -isrc/library src/library/FP/API/Types.hs +RTS -s [3 of 3] Compiling FP.API.Types ( src/library/FP/API/Types.hs, src/library/FP/API/Types.o ) 12,767,593,936 bytes allocated in the heap 1,078,202,664 bytes copied during GC 179,551,768 bytes maximum residency (13 sample(s)) 6,684,544 bytes maximum slop 439 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 623 colls, 0 par 1.24s 1.24s 0.0020s 0.0651s Gen 1 13 colls, 0 par 0.76s 0.76s 0.0586s 0.2397s TASKS: 4 (1 bound, 3 peak workers (3 total), using -N1) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.00s ( 0.00s elapsed) MUT time 8.28s ( 9.23s elapsed) GC time 2.00s ( 2.00s elapsed) EXIT time 0.05s ( 0.05s elapsed) Total time 10.34s ( 11.28s elapsed) Alloc rate 1,542,443,897 bytes per MUT second Productivity 80.6% of total user, 73.9% of total elapsed gc_alloc_block_sync: 0 whitehole_spin: 0 gen[0].sync: 0 gen[1].sync: 0 real 0m11.304s user 0m11.108s sys 0m0.172s }}} and -O1: {{{ $ time ghc -O1 --make -isrc/library src/library/FP/API/Types.hs +RTS -s [3 of 3] Compiling FP.API.Types ( src/library/FP/API/Types.hs, src/library/FP/API/Types.o ) 45,550,443,664 bytes allocated in the heap 5,721,700,512 bytes copied during GC 358,036,456 bytes maximum residency (21 sample(s)) 9,167,176 bytes maximum slop 906 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 1642 colls, 0 par 7.70s 7.70s 0.0047s 0.1031s Gen 1 21 colls, 0 par 3.68s 3.69s 0.1756s 0.4968s TASKS: 4 (1 bound, 3 peak workers (3 total), using -N1) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.00s ( 0.00s elapsed) MUT time 30.21s ( 33.09s elapsed) GC time 11.38s ( 11.39s elapsed) EXIT time 0.07s ( 0.07s elapsed) Total time 41.68s ( 44.55s elapsed) Alloc rate 1,507,571,106 bytes per MUT second Productivity 72.7% of total user, 68.0% of total elapsed gc_alloc_block_sync: 0 whitehole_spin: 0 gen[0].sync: 0 gen[1].sync: 0 real 0m44.577s user 0m44.164s sys 0m0.368s }}} Note that this module is essentially just 900 lines of data declarations, with a large number of derived classes, and a few manually written helper functions and instances. This high memory usage hasn't just resulted in user complaints: automated Jenkins and Travis jobs will often times fail without optimizations disabled, which can be problematic for proper testing and production code. In the case of fpco-api, I've worked around this by adding `-O0` to the cabal file, but it would be much nicer to not have to do that. For some other examples of complaints along these lines: * https://groups.google.com/d/msg/yesodweb/MX1bnOFu8Hc/VLQXhnvpIkMJ * https://groups.google.com/d/msg/yesodweb/XPWixNjuOnM/FN26bmkudgwJ I believe there are a few other threads discussing this, if it would be helpful. I did my testing on GHC 7.8.3 64-bit, Ubuntu 12.04. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9669> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #13604: regression in ghc 8.2.1-rc1 (8.2.0.2017040)
by GHC 11 Dec '17

11 Dec '17

#13604: regression in ghc 8.2.1-rc1 (8.2.0.2017040) -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 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: -------------------------------------+------------------------------------- In 8.2.1-rc1 loading a file compiled with -O2 into ghci results in ghci recompiling the file into interpreted byte code. In 8.0.2 it simply loads the compiled object file. 8.2.1 {{{ ghc -dynamic -O2 eh2.hs [1 of 1] Compiling Main ( eh2.hs, eh2.o ) Linking eh2 ... bash-3.2$ ghci -ignore-dot-ghci GHCi, version 8.2.0.20170404: http://www.haskell.org/ghc/ :? for help Prelude> :load eh2 [1 of 1] Compiling Main ( eh2.hs, interpreted ) [flags changed] Ok, modules loaded: Main. }}} 8.0.2 {{{ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.0.2 bash-3.2$ pwd /Users/gcolpitts/haskell bash-3.2$ ghc -dynamic -O2 eh2.hs [1 of 1] Compiling Main ( eh2.hs, eh2.o ) Linking eh2 ... bash-3.2$ ghci -ignore-dot-ghci GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Prelude> :load eh2 Ok, modules loaded: Main (eh2.o). }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13604> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 52

[GHC] #14545: -prof causes -N to default to 1
by GHC 11 Dec '17

11 Dec '17

#14545: -prof causes -N to default to 1 -------------------------------------+------------------------------------- Reporter: gelisam | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Given a simple test program which prints `getNumCapabilities`: {{{#!hs import Control.Concurrent main :: IO () main = print =<< getNumCapabilities }}} Compiling this with `-threaded` and running the program with `+RTS -N` is supposed to set the number of capabilities to the number of cores on the machine. This normally prints 8 on my machine: {{{#!bash $ rm -rf Main Main.hi Main.o && ghc -threaded Main.hs && ./Main +RTS -N [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... 8 }}} But when I compile with `-prof`, it prints 1 instead! Expected output: still 8. {{{#!bash $ rm -rf Main Main.hi Main.o && ghc -prof -threaded Main.hs && ./Main +RTS -N [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... 1 }}} If I use `+RTS -N8` instead, it prints 8 as expected. Reproduced with GHC 8.0.2 and GHC 8.8.2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14545> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14520: GHC panic (TypeInType)
by GHC 11 Dec '17

11 Dec '17

#14520: GHC panic (TypeInType) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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, TypeOperators #-} import Data.Kind type a ~>> b = (a, b) -> Type data family Sing (a::k) type family (·) (f::a~>>b) (x::a)::b class PCategory kat where type Id ::kat·a·a type Comp::kat·b·c -> kat·a·b -> kat·a·c class SCategory kat where sId :: Sing a -> Sing (Id::kat a a) sComp :: Sing f -> Sing g -> Sing (Comp f g) }}} triggers a panic {{{ $ ghci -ignore-dot-ghci Bug.hs GHCi, version 8.3.20171122: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( Bug.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.3.20171122 for x86_64-unknown-linux): piResultTy k_a1KI[tau:1] a_a1vb[sk:1] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1147:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:951:35 in ghc:Type piResultTy, called at compiler/types/Type.hs:2309:34 in ghc:Type typeKind, called at compiler/types/Type.hs:2309:46 in ghc:Type typeKind, called at compiler/typecheck/TcType.hs:1706:11 in ghc:TcType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14520> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2