sloppy bug report
Hi, Apologies for the sloppiness of this bug report. in ghc 5.04.2 I get this message: ghc-5.04.2: panic! (the `impossible' happened, GHC version 5.04.2): coreSyn/Subst.lhs:385: Non-exhaustive patterns in function zip_ty_env I would love to try and give you a simple test case, but I can't. It happens when I am building a (buddha-transformed) raytracer which I am also trying to profile (there is a lot of code involved - and it is mangled because of the debugging transformation, so finding a simplified expression of the bug is somewhat tricky). The bug disappears if I re-compile all my code from scratch. In any case the code for zip_ty_env is simple enough that someone who understands it may want to consider its assumptions: zip_ty_env [] [] env = env zip_ty_env (tv:tvs) (ty:tys) env = Obviously one of the lists is empty and the other is not - though the code assumes this will never happen. Cheers, Bernie. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: floating point literals
> On Mon, Mar 17, 2003 at 10:33:47AM +, Ross Paterson wrote: > > GHC doesn't recognize literals like 9e2, and nor does lex. > > Correction: > GHC doesn't recognize 9e2 > lex is confused by 0xy, 0oy, 9e+y and 9.0e+y Fixed GHC, I'll leave lex to someone more familiar with the code... Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: floating point literals
On Mon, Mar 17, 2003 at 10:33:47AM +, Ross Paterson wrote: > GHC doesn't recognize literals like 9e2, and nor does lex. Correction: GHC doesn't recognize 9e2 lex is confused by 0xy, 0oy, 9e+y and 9.0e+y ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
floating point literals
GHC doesn't recognize literals like 9e2, and nor does lex. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs