October 2014 - ghc-tickets

[GHC] #8044: "Inaccessible code" error reported in wrong place
by GHC 24 Nov '14

24 Nov '14

#8044: "Inaccessible code" error reported in wrong place -------------------------------------------+------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Keywords: GADTs | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Here is my file `Bug.hs`: {{{ {-# LANGUAGE GADTs, TypeFamilies #-} module Bug where data X a where XInt :: X Int XBool :: X Bool XChar :: X Char type family Frob a where Frob Int = Int Frob x = Char frob :: X a -> X (Frob a) frob XInt = XInt frob _ = XChar }}} Compiling this file produces the error {{{ Bug.hs:15:6: Couldn't match type ‛Int’ with ‛Char’ Inaccessible code in a pattern with constructor XInt :: X Int, in an equation for ‛frob’ In the pattern: XInt In an equation for ‛frob’: frob XInt = XInt }}} The line/column number single out the pattern `XInt` in the first clause of the function `frob`. But, the real problem (as I see it), is the right- hand side of the ''second'' clause of `frob`. Indeed, when I comment out the second line of the function, the error goes away, even though it was reported on the first line. I do not believe that this error is caused by closed type families, per se, because I have run across it without them, just in code that was too hard to pare down enough to make a bug report out of. This was tested on 7.7.20130702. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8044> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9318: Type error reported in wrong place with repeated type family expressions
by GHC 22 Nov '14

22 Nov '14

#9318: Type error reported in wrong place with repeated type family expressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Differential Revisions: Keywords: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE TypeFamilies #-} type family F x type instance F Int = Bool foo :: F Int -> () foo True = () bar :: F Int -> () bar 'x' = () }}} I get {{{ /Users/rae/temp/Bug.hs:7:5: Couldn't match type ‘Char’ with ‘Bool’ Expected type: F Int Actual type: Bool In the pattern: True In an equation for ‘foo’: foo True = () /Users/rae/temp/Bug.hs:10:5: Couldn't match type ‘Bool’ with ‘Char’ Expected type: F Int Actual type: Char In the pattern: 'x' In an equation for ‘bar’: bar 'x' = () }}} The second error is most certainly correct, but the first one is most certainly not. Note that the first error is reported on the definition of `foo`, which should type-check. Also, the "Couldn't match ..." bit doesn't correspond at all with the expected/actual bit. And, the expected/actual bit shows two types that are in fact equal. This behavior can be seen in HEAD (as of Jul. 2), 7.8.3, and 7.8.2. This is a regression from 7.6.3, where this behavior does not appear. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9318> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #8046: Make the timer management scale better across multicore
by GHC 21 Nov '14

21 Nov '14

#8046: Make the timer management scale better across multicore ------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | 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: | ------------------------------------+------------------------------------- A recent commit {{{ commit e843e73690f828498f6e33bb89f47a50c3ab2ac9 Author: Ian Lynagh <ian(a)well-typed.com> Date: Sat Jun 8 20:19:59 2013 +0100 IO manager: Edit the timeout queue directly, rather than using an edit list Fixes #7653. }}} undid an optimization to the management of timeouts (to fix a bug, which is good). We should check how much this hurt performance, but it might be better to rewrite the timeout management altogether. The current scheme scales poorly to several cores. We should probably have one priority queue per core and use an efficient mutable data structure. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8046> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8054: Undefined symbol during linking
by GHC 21 Nov '14

21 Nov '14

#8054: Undefined symbol during linking ------------------------------------+------------------------------------- Reporter: case | Owner: Type: bug | 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: | ------------------------------------+------------------------------------- On OSX, using GHC 7.6.3 and the package recursion-schemes 3.0.0.2, the following code causes the compiler to emit an error about undefined symbols. Code: {{{ import Data.Functor.Foldable x = project 1 :: Integer main = x `seq` return () }}} Error: {{{ λ ~/ ghc test.hs Linking test ... Undefined symbols for architecture x86_64: "_Main_x_closure", referenced from: _Main_main_info in test.o _Main_main_srt in test.o ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8054> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8056: Make Install fails on HEAD
by GHC 21 Nov '14

21 Nov '14

#8056: Make Install fails on HEAD ------------------------------------+------------------------------------- Reporter: fryguybob | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I'm trying to build the `perf` flavor of head and I'm getting an error with `make install`. The `quick` flavor works as expected. {{{ $ uname -a Linux ... 3.6.5-1.fc17.x86_64 ... $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.6.3 $ cabal --version cabal-install version 1.16.0.2 using version 1.16.0.3 of the Cabal library $ gcc --version gcc (GCC) 4.7.2 20120921 (Red Hat 4.7.2-2) ... $ git clone http://darcs.haskell.org/ghc.git/ ghc-7.8/ ... $ cd ghc-7.8 $ ./sync-all --testsuite get ... $ cp mk/build.mk.sample mk/build.mk $ vi mk/build.mk $ diff mk/build.mk mk/build.mk.sample 12c12 < BuildFlavour = perf --- > #BuildFlavour = perf $ perl boot ... $ ./configure --prefix=/localdisk/ryates/ghc-7.8-build/ ... $ make -j8 ... $ make install ... Installing library in /localdisk/ryates/ghc-7.8-build/lib/ghc-7.7.20130711/haskell2010-1.1.1.0 "/localdisk/ryates/ghc-7.8-build/lib/ghc-7.7.20130711/bin/ghc-pkg" --force --global-package-db "/localdisk/ryates/ghc-7.8-build/lib/ghc-7.7.20130711/package.conf.d" update rts/dist/package.conf.install /localdisk/ryates/ghc-7.8-build/lib/ghc-7.7.20130711/bin/ghc-pkg: symbol lookup error: /localdisk/ryates/ghc-7.8-build/lib/ghc-7.7.20130711/bin /ghc-pkg: undefined symbol: base_DataziList_intercalatezuzdspolyzugo_info make[1]: *** [install_packages] Error 127 make: *** [install] Error 2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8056> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9540: unwords is not a good producer
by GHC 21 Nov '14

21 Nov '14

#9540: unwords is not a good producer -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: fusion | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: Runtime hour) | performance bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I think we can do something like this, once we've fixed `unfoldr`: {{{#!hs unwords = unfoldr go where go [] = Nothing go ("":ws) = Just (' ', ws) go ((l:ls):ws) = Just (l, ls:ws) }}} With my draft `unfoldr`, GHC turns this into {{{#!hs lvl_r1EN lvl_r1EN = C# ' ' Rec { unwords_$sgo unwords_$sgo = \ sc_s1Gx sc1_s1Gy -> case sc_s1Gx of _ { [] -> : lvl_r1EN (unwords_go sc1_s1Gy); : l_a1Ew ls_a1Ex -> : l_a1Ew (unwords_$sgo ls_a1Ex sc1_s1Gy) } unwords_go unwords_go = \ b1_a1Fb -> case b1_a1Fb of _ { [] -> []; : ds_d1F5 ws_a1Ev -> case ds_d1F5 of _ { [] -> : lvl_r1EN (unwords_go ws_a1Ev); : l_a1Ew ls_a1Ex -> : l_a1Ew (unwords_$sgo ls_a1Ex ws_a1Ev) } } end Rec } unwords unwords = \ b'_a1F9 -> unwords_go b'_a1F9 }}} To my untrained eye, that looks pretty reasonable. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9540> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9628: Add Annotations to the AST to simplify source to source conversions
by GHC 21 Nov '14

21 Nov '14

#9628: Add Annotations to the AST to simplify source to source conversions -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Two different kinds of annotation are proposed to be added to HsSyn 1. Additional elements to explictly track the location of all syntactic elements not currently tracked. In particular, locations of reserved words and punctuation. 2. A top-level type parameter that allows a tool-writer to thread an application-specific annotation through the syntax tree. These two could potentially be merged, if the default annotation parameter is capable of tracking the first category of information. Discussion of the feature is at GhcAstAnnotations -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9628> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 43

[GHC] #9293: GHCI :unset -XLanguageExtension returns "don't know how to reverse -XLanguageExtension"
by GHC 21 Nov '14

21 Nov '14

#9293: GHCI :unset -XLanguageExtension returns "don't know how to reverse -XLanguageExtension" -------------------------+------------------------------------------------- Reporter: | Owner: jfeltz | Status: new Type: bug | Milestone: Priority: | Version: 7.8.2 normal | Operating System: Unknown/Multiple Component: GHCi | Type of failure: None/Unknown Keywords: | Test Case: :set -XCPP followed by Architecture: x86 | :unset -XCPP Difficulty: | Blocking: Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- Any language extension tried appears to not work with :unset. To make matters worse, :unset expands to a number of options, misleading the user into thinking that it should (if that is the case). I eventually had to ask someone on IRC #haskell, leading to the :set -XNoLanguageExtension trick to do what I needed. A fix to :unset is suggested, or removing the misleading/non-working command. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9293> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8568: internal error: allocation of ... bytes too large
by GHC 21 Nov '14

21 Nov '14

#8568: internal error: allocation of ... bytes too large ------------------------------------+------------------------------------- Reporter: mojojojo | Owner: Type: bug | 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: | ------------------------------------+------------------------------------- Running the following GHCi session: {{{ import GHC.DataSize import qualified Data.HashTable.IO as HT import Control.Monad t <- HT.new :: IO (HT.BasicHashTable Int Char) forM_ [0..100000] $ \i -> HT.insert t i 'a' recursiveSize t }}} results in the following error: {{{ <interactive>: internal error: allocation of 1208480 bytes too large (GHC should have complained at compile-time) (GHC version 7.6.3 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort trap: 6 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8568> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9647: allocation of 10790760 bytes too large
by GHC 21 Nov '14

21 Nov '14

#9647: allocation of 10790760 bytes too large -------------------------------------+------------------------------------- Reporter: mirko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: run time | Operating System: Windows insufficient memory | Type of failure: Incorrect Architecture: x86_64 (amd64) | warning at compile-time Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- I got an error message and invitation to submit a bug report. So here is the error message first, followed by my description of what happened. C:\Users\Owner\Documents\hs>ghc -o void void.hs -rtsopts [1 of 1] Compiling Main ( void.hs, void.o ) Linking void.exe ... C:\Users\Owner\Documents\hs>void +RTS -K400M -RTS > void.txt void: internal error: allocation of 10790760 bytes too large (GHC should have complained at compile-time) (GHC version 7.8.3 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug C:\Users\Owner\Documents\hs>void +RTS -K40000M -RTS > void.txt void: internal error: allocation of 10790760 bytes too large (GHC should have complained at compile-time) (GHC version 7.8.3 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Description of what happened. I gave my program really large numbers. It contains the following line: rr = (of40)*(r250^3041) In the above of40 is (if I remember correctly) the product of the first 40000 odd primes. I computed it with reduce (a computer algebra system) which saved the result (as an explicitly written out number in decimal notation), which I copied and inserted in my hs file, initializing of40 with its value. In the file it takes 2457 rows, 1024 cols, so it appears to be about 2 515 968 (that is two million+) decimal digits. As seen it is multiplied by r250^3041, here r250 is a 250-digit number so r250^3041 is about 760 250 (seven hundred sixty thousand+) decimal digits, so the product rr = (of40)*(r250^3041) seems to be more than 3 000 000 (three million+) decimal digits. I tried to compile it yesterday, I did get an error message from the compiler: I do not remember exactly what it was, I may try to reproduce it later and include it, but it was something along the lines of insufficient amount of memory. I run a Hewlett-Packard HPE 500y, upgraded to 16 Gb RAM (the max it would take), Windows 7, AMD Phenom(tm) II X6 1045T Processor 2.70 GHz (6 core). So yesterday after I got the first error message I increased the paging file size from automatic to 32768 Mb initial, and 65536 Mb max. Then tried to compile again, the compiler gradually took more and more memory (I was watching the performance using the Task Manager) so it gradually went up to using all 16 Gb of RAM, and stayed there for I think at least 40 min, could have been more than an hour (or even 2 hours, sorry can't quite remember). At some point it seemed the computer froze, the task manager stopped showing any activity, but I did not attempt to immediately restart it, the mouse would not respond anyway, and in a few minutes it fixed itself, it seemed to continue compiling, after which it eventually gave up and complained about insufficient amount of memory again. So this morning I increased the paging file to initial size 49152 Mb, max size 196608 Mb (I don't know if such big numbers make sense but I tried). I tried to compile again starting around 9am, left my apt at around 4pm and the compiler had not yet finished, and came back after midnight, the compiler had finished. It had produced a big exe file (I see now, around 9 pm, so it must have kept compiling for around 12 hours): 09/27/2014 09:38 PM 20,602,960 void.exe AVG (antivirus) claimed that this file was a threat and refused to let me run it, so I had to disable AVG, after which I got the error messages as already enclosed at the beginning of this description. The Paging file reports as: Recommended 24574 Mb, Currently allocated: 163765 Mb. Note I gave the options -rtsopts to the compiler, I do not remember anymore what they mean, and whether they are valid (or perhaps not used anymore), I got them from a webpage perhaps a couple of years ago and at that time they made sense, so I just kept using them. I also gave the option +RTS -K400M -RTS when I tried to execute the compiled program, and then +RTS -K40000M -RTS, both versions generated the error messages shown above. I tend to believe that giving Haskell such large numbers inside the .hs file explains all of the above problems, it might even be a bit surprising it went so far before it finally gave up. But I do not really know, so let me just report it. So I changed the paging file back to automatic, and I am compiling the same file (after renaming it) to try to reproduce the error message that I got yesterday (or rather the other day, now being after midnight). It has been compiling for about 4 min so far, nothing really visible, memory usage stays at 1.28 Gb (where it was before I started compiling). I don't quite remember what happened the first time when I tried to compile, I think I got the error message (about insufficient amount of memory) immediately, or almost immediately. This does not happen now, I wonder if the computer took into account that I changed the paging file back to automatic, I may need to restart to make sure. Well, ok, 13 min after it started compiling, the memory usage started going up gradually. It goes from e.g. 13.9 to 14 Gb in about a second or two. So in about 2 min it went from 1.28 to 15.9 Gb, and now stays there (I do not know how to interpret all that Task Manager shows me). I may not be able to reproduce the first error message: At that time I was running 5 copies of reduce, each busy multiplying numbers for some hours. Right now I am only running the GHC by itself, so no other load. It is running for about 23 min now, the last 6 of which the memory usage stays at 15.9 Gb. My computer may have learned to increase the paging file on its own. The computer refuses to give up this time, but I can't wait, going to bed is long overdue, if it generates an error message I'll copy it in the morning. Well, memory usage decreased a bit to 15.1, this happened after it stayed at 15.9 for about 15 min. It I remember correctly what had happened the other day, it will increase again, and then give an error message. It's at 15.3 Gb for about 3 min now. On the other hand the processor is doing almost nothing, going between 0% and 1%. Memory 15.4, 15.8, processor went up to 16% to 17% (which is = 1 out of 6 cores), memory 15.9, this is about 40 min after it started compiling and about 23 min after it went up to 15.9 Gb (15.8 presently). I should perhaps be patient and wait for the compiler to give up and give me an error message that I could copy, but I do not have the patience to do that: Again the original error message was something to the effect that the compiler refused to work because of insufficient amount of memory. I kept trying to compile, so apparently the compiler tried to be nice to me, and eventually compiled my program in 9 hours, after which when I tried to execute it, I was invited to write this report. It keeps compiling right now, at 16% (1 of 6 cores) processor, and 15.9 Gb memory usage, for about 47 min (30 min at 15.9). P.S. Thanks for Richard Eisenberg and Herbert Valerio Riedel for replying to my email. I initially had problems, trying to register and submit a new bug report, the BotScout stopped me, and it was too late at night to try to figure it, so I just emailed Richard in my frustration. Now, BotScout may not be the culprit: I did not read carefully what it asked me to do, and it was something like Evaluate `(!!6) ...' My knowledge of Haskell is rather superficial (I use it since it compiles and is relatively fast, and does not need an extra library to work with large numbers), so I have to often consult the tutorial for simple constructs. I have had some previous experience with Common Lisp (or Scheme, a course taken 12 years ago) and in Lisp there is a command "evaluate", and also single quotation marks are used within the language occasionally. So, I just copied the entire line Evaluate `(!!6) (whatever it was)' and pasted it in the interpreter which gave me some nonsense which I sent back to BotScout. BotScout then gave me a second chance, and I do not quite remember if I tried to be more careful, perhaps not, so BotScout wouldn't even let me try anymore after that (even if I started from scratch ... perhaps it remembered me). After that happened I copied only the (!!6), etc, and the my GHC interpreter did evaluate something meaningful (a single number, no error message). I just didn't want to spend the time to think that late at night, and at first it seemed to me that the word Evaluate might have been part of a Haskell expression. I question if the above (perhaps too lengthy) report is of any use, but again, I follow the instruction, if in doubt, submit it. Thank you again! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9647> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7