From mario.alvarez739 at gmail.com Thu May 7 18:38:15 2015 From: mario.alvarez739 at gmail.com (Mario Alvarez Picallo) Date: Thu, 7 May 2015 19:38:15 +0100 Subject: [jhc] Internal pattern match failure when using QuickCheck Message-ID: Hello all, I'm using JHC for a small research project and I've run across the following bug when compiling a very simple program: module Main where import Test.QuickCheck foo_prop x = True main = do quickCheck foo_prop When compiling with the command `jhc -p QuickCheck Main.hs`, the compiler will crash with the following error message: JGC DETECTED JGC DETECTED jhc -p QuickCheck Main.hs jhc 0.8.2 (mydniquipepo-32) Finding Dependencies... Using Ho Cache: '/home/mario/.jhc/cache' Main [Main.hs] Typechecking... [1 of 1] Main (.............................................) Compiling... [1 of 1] Main <.................................wwwwwwwww........> Collected Compilation... -- TypeAnalyzeMethods -- BoxifyProgram -- Boxy WorkWrap >>> Exception thrown Writing: hs.out_lint-before-Boxy WorkWrap.jhc_core Stack: transformProgram: Boxy WorkWrap jhc: Pattern match failure in do expression at src/E/Demand.hs:287:13-28 Is this a known bug? Is there any workaround? Thanks for your time. -- Now I do not know whether I was then a lambda expression emulating a Turing machine, or whether I am a Turing machine emulating a lambda expression. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Fri May 8 17:01:39 2015 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Fri, 08 May 2015 19:01:39 +0200 Subject: [jhc] "case fell off" for trivial program Message-ID: <87mw1f0zrg.fsf@gmail.com> Hello, When compiling and running the following trivial Haskell program below w/ jhc 0.8.2, it aborts right away with a "case fell off" error (see output below) As this seems to be a rather visible bug, is this actually a known issue? --8<---------------cut here---------------start------------->8--- data T2 = T2C1 | T2C2 String deriving (Show,Eq) data T3 = T3C1 | T3C2 | T3C3 String deriving (Show,Eq) main :: IO () main = do print (T2C2 "works fine") print (T3C3 "case falls off") --8<---------------cut here---------------end--------------->8--- ...output when run: --8<---------------cut here---------------start------------->8--- T2C2 "works fine" /tmp/jhc_8nHiAa/rts/rts_support.c:887: case fell off Aborted --8<---------------cut here---------------end--------------->8--- Cheers, hvr From mario.alvarez739 at gmail.com Fri May 8 20:02:55 2015 From: mario.alvarez739 at gmail.com (Mario Alvarez Picallo) Date: Fri, 8 May 2015 21:02:55 +0100 Subject: [jhc] "case fell off" for trivial program In-Reply-To: <87mw1f0zrg.fsf@gmail.com> References: <87mw1f0zrg.fsf@gmail.com> Message-ID: I've been looking into the generated C code. The problem seems to be caused by an erroneous optimization that causes the tag for the variant type T3 to be dropped altogether. This would be OK, since the other two constructors are immediate (i.e. aren't boxed) and therefore, at runtime, you can just check if the constructor is a pointer and if it is, then it must be T3C3, and if it's not, check the immediate tag. However, while the representation of the constructors is optimized, the code that checks for tags is not, and expects T3C3 to be tagged. If you added parameters to any other T3 constructors the optimization wouldn't be triggered and there would be no bug. I'm a bit hesitant to look further into this, as I'm not involved in the development of JHC (I just happen to have some understanding of the C backend). However, since my current project depends heavily on JHC, if nobody else steps up I might try to fix it myself. Cheers! On Fri, May 8, 2015 at 6:01 PM, Herbert Valerio Riedel wrote: > Hello, > > When compiling and running the following trivial Haskell program below w/ > jhc > 0.8.2, it aborts right away with a "case fell off" error (see output > below) > > As this seems to be a rather visible bug, is this actually a known issue? > > --8<---------------cut here---------------start------------->8--- > data T2 = T2C1 | T2C2 String > deriving (Show,Eq) > > data T3 = T3C1 | T3C2 | T3C3 String > deriving (Show,Eq) > > main :: IO () > main = do > print (T2C2 "works fine") > print (T3C3 "case falls off") > --8<---------------cut here---------------end--------------->8--- > > > ...output when run: > > --8<---------------cut here---------------start------------->8--- > T2C2 "works fine" > > /tmp/jhc_8nHiAa/rts/rts_support.c:887: case fell off > Aborted > --8<---------------cut here---------------end--------------->8--- > > > Cheers, > hvr > _______________________________________________ > jhc mailing list > jhc at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/jhc > -- Now I do not know whether I was then a lambda expression emulating a Turing machine, or whether I am a Turing machine emulating a lambda expression. -------------- next part -------------- An HTML attachment was scrubbed... URL: From travis at athougies.net Tue May 19 21:24:14 2015 From: travis at athougies.net (Travis Athougies) Date: Tue, 19 May 2015 14:24:14 -0700 Subject: [jhc] "case fell off" for trivial program Message-ID: disclaimer: I found this e-mail thread through the jhc archives while I was not subscribed to jhc@ because I was having the same problems as Mario and Herbert. I subscribed afterwards, so I could join in on the discussion. I'm not sure how this will affect the mailing list's thread handling. I am having the same problem with JHC, and like Mario says, it's due to a pre-mature optimization. Basically, when JHC encounters a type where only one constructor has arguments, it erroneously thinks that it can store it as untagged. This is true only for types with two constructors, but not for types with more than two. I have the feeling this was written as a quick way to optimize list storage without realizing that the optimization would break types with more than two constructors. The optimization works for types with two constructors because JHC specifically handles the case of scrutinizing a two-constructor type when it generates C. Anyway, this can be fixed by disabling this optimization for types with more than two constructors. Change the line tyRep k tyty | Just xs <- tySiblings tyty, all triv [ x | x <- xs, x /= k] = Just TyRepUntagged where to tyRep k tyty | Just xs <- tySiblings tyty, length xs < 3 && all triv [ x | x <- xs, x /= k] = Just TyRepUntagged where Any ideas on how to get this bug changed in the official version? Travis -------------- next part -------------- An HTML attachment was scrubbed... URL: From mario.alvarez739 at gmail.com Tue May 19 21:41:59 2015 From: mario.alvarez739 at gmail.com (Mario Alvarez Picallo) Date: Tue, 19 May 2015 22:41:59 +0100 Subject: [jhc] "case fell off" for trivial program In-Reply-To: References: Message-ID: You can find a patched version of the compiler at http://github.com/m-alvarez/jhc (as long as you don't mind using an experimental branch of jhc), but I'm not sure how to go about merging this patch into the official repository. We could try telling John directly, but if he's not paying attention to the mailing list my guess is he's too busy to worry much about JHC. I'm pretty sure the optimization could be made safe, although I'm not sure how easily, and right now I don't have the time or energy to devote to that. If anyone else volunteers, I'll be glad to accept pull requests to the github repo. Cheers! On Tue, May 19, 2015 at 10:24 PM, Travis Athougies wrote: > disclaimer: I found this e-mail thread through the jhc archives while I > was not subscribed to jhc@ because I was having the same problems as > Mario and Herbert. I subscribed afterwards, so I could join in on the > discussion. I'm not sure how this will affect the mailing list's thread > handling. > > I am having the same problem with JHC, and like Mario says, it's due to a > pre-mature optimization. > > Basically, when JHC encounters a type where only one constructor has > arguments, it erroneously thinks that it can store it as untagged. This is > true only for types with two constructors, but not for types with more than > two. I have the feeling this was written as a quick way to optimize list > storage without realizing that the optimization would break types with more > than two constructors. > > The optimization works for types with two constructors because JHC > specifically handles the case of scrutinizing a two-constructor type when > it generates C. > > Anyway, this can be fixed by disabling this optimization for types with > more than two constructors. > > Change the line > > tyRep k tyty | Just xs <- tySiblings tyty, all triv [ x | x <- xs, x > /= k] = Just TyRepUntagged where > > to > > tyRep k tyty | Just xs <- tySiblings tyty, length xs < 3 && all triv [ > x | x <- xs, x /= k] = Just TyRepUntagged where > > Any ideas on how to get this bug changed in the official version? > > Travis > -- Now I do not know whether I was then a lambda expression emulating a Turing machine, or whether I am a Turing machine emulating a lambda expression. -------------- next part -------------- An HTML attachment was scrubbed... URL: