Hi (Simon, Sigbjorn?),
I'm putting the static argument transformation (simplCore/SAT.lhs)
back to GHC 2.0899, which works as advertised but:
when it gets to code generation (codeGen/ClosureInfo.lhs) the
impossible happens.
panic! (the `impossible' happened):
fun
Trying to compile happy 1.5 using ghc 3.02:
NOTE: Simplifier still going after 4 iterations; bailing out.
NOTE: Simplifier still going after 4 iterations; bailing out.
panic! (the `impossible' happened):
lookupBindC:no info!
for: actionFunction_sqBJ
(pro
===========
> ghc-2.02 -v -c Set.lhs
The Glorious Glasgow Haskell Compilation System, version 2.02, patchlevel 0
literate pre-processor:
echo '#line 1 "Set.lhs"' > /tmp/ghc3903.lpp &&am
Colin Paul Adams writes:
>
> Trying to compile happy 1.5 using ghc 3.02:
>
...
> panic! (the `impossible' happened):
> lookupBindC:no info!
> for: actionFunction_sqBJ
> (probably: data dependencies broken by an optimisation pass)
>
='-}'
-DEND_GHC_ONLY='{-' -DBEGIN_NOT_FOR_GHC='{-' -DEND_NOT_FOR_GHC='-}'
-DELSE_FOR_GHC='-}-}' -c main/Main.lhs -o main/Main.o
panic! (the `impossible' happened):
dsExpr: tuple pattern:
let { fail = patError __a (IO ()) __string
Laszlo Nemeth wrote:
> I'm putting the static argument transformation (simplCore/SAT.lhs)
> back to GHC 2.0899, which works as advertised but:
> when it gets to code generation (codeGen/ClosureInfo.lhs) the
> impossible happens.
>
> panic! (th
f o
panic! (the `impossible' happened):
cgEvalAlts: dodgy case of unboxed tuple type
Please report it as a compiler bug to [EMAIL PROTECTED]
I am using gcc2.95.2 with -m32 option; this option is necessary because by
default gcc uses 64 bit things and GHC barfs at that. (It shoul
hello. I am using ghc-2.01 on alpha-dec-osf4.0
(the binary package - base and prof).
ghc has trouble compiling let expressions inside list comprehensions.
when i replace let foo = bar with foo <- [bar], then everything seems
to work.
is this a known bug? (if no, do you need example files that re
Hi,
thanks for the report - the compiler does not gracefully deal with
duplicate method definitions coming from your Set [] instance:
class Set set where
...
size :: (Ord a) => set a -> Int
...
instance Set [] where
...
size = length
size = genericLength
..
delete the latt
During the compilation of a small project with ghc-3.01 (Linux) I get:
panic! (the `impossible' happened):
unboxArg: PrelBase.(){-40-}
The code leading to this error is available at:
http://www.pms.informatik.uni-muenchen.de/mitarbeiter/panne/impossible.tar.gz
Just
fier still going after 4 iterations; bailing out.
NOTE: Simplifier still going after 4 iterations; bailing out.
Warning: discarding polymorphic case: PrelErr.error{-87-}
_@_ RExp.Set{-rTV-} Map.$ga{-rS7-}
panic! (the `impossible' happened):
lo
x27; -DEND_NOT_FOR_GHC='-}'
> -DELSE_FOR_GHC='-}-}' -c main/Main.lhs -o main/Main.o
>
> panic! (the `impossible' happened):
> dsExpr: tuple pattern:
> let { fail = patError __a (IO ()) __string "Main.lhs:540|case"
> } in
> case d
f __rm_food ; fi ;
> ../../ghc/driver/ghc-inplace -recomp -cpp -optC-fglasgow-exts -fvia-C -Rghc-timing
>-I../../ghc/includes -imonads -static -O -split-objs -odir Weak -H20m -H30m
>-Onot -c Weak.lhs -o Weak.o -osuf o
>
> panic! (the `impossible' happened):
>
| ghc has trouble compiling let expressions inside list comprehensions.
| when i replace let foo =3D bar with foo <- [bar], then everything seems
| to work.
|
| is this a known bug? (if no, do you need example files that reporduce it?=
| )
|
| is my workaround morally correct (strictness, polym
--
X-Sun-Data-Type: text
X-Sun-Data-Description: text
X-Sun-Data-Name: text
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 9
During compilation of the enclosed module, the following happened:
panic! (the `impossible' happened):
tcInstType:1
Herewith reported as a GHC 2.04 bug.
Sven Panne writes:
> During the compilation of a small project with ghc-3.01 (Linux) I get:
>
> panic! (the `impossible' happened):
>unboxArg: PrelBase.(){-40-}
>
> The code leading to this error is available at:
>
>http://www.pms.informati
Mariano Suarez Alvarez writes:
> Compiling lx (the lexical analyser generator) with -O, everything goes
> smoothly until we get to the main file Lx.hs, on which ghc-3.02 panics
> and dies. The (long!) -v output is included below. If I compile without
> -O, everything is fine.
>
Hi,
thanks - lo
iterations; bailing out.
panic! (the `impossible' happened):
lookupBindC:no info!
for: actionFunction_sqBJ
(probably: data dependencies broken by an optimisation pas
s)
static binds for:
ProduceCode.$g
>
> During compilation of the enclosed module, the following happened:
>
> panic! (the `impossible' happened):
> tcInstType:1
>
> Herewith reported as a GHC 2.04 bug.
>
Here's what I get when compiling it
foo$ $ghc/driver/ghc -c -noC guiv.hs
guiv
Einar Wolfgang Karlsen writes:
> > odd instance decl - is this really the file that shows up the bug?
> >
>
> The file is the "correct" one - Yes. I played around with some of the
> ghc options. It seems as if it is -fglasgow-exts that is causing the
> problem. [...]
>
Thanks, -fglasgow-ext
ran into this bug when compiling with the optimization flags:
-H10M -O -fvia-C -O2-for-C
"
NOTE: Simplifier still going after 4 iterations; bailing out.
NOTE: Simplifier still going after 4 iterations; bailing out.
panic! (the `impossible' happened):
getWorkerIdAndCons de
{-
Hi,
Compiling the following module results in the following error message
(with GHC 2.09, patchlevel 0, i386-linux
--
panic! (the `impossible' happened):
getWorkerIdAndCons area2{-r3g,
Thomas Nordin writes:
> Hi ghc-3.02 on cywin32 19.3 told me to mail this to you, from
> compiling Happy 1.5:
>
> /usr/local/bin/ghc -cpp -fhaskell-1.3 -fglasgow-exts -O -H12m-c ProduceCode.
> lhs -o ProduceCode.o -osuf o
>
>
> panic! (the `impossible' happen
= bar
where bar = \baz -> (baz + boing, truncate baz, truncate boing)
boing = 0
--
Transcript:
ghc -c Foo.hs
zonkIdOcc: truncate_aXz
panic! (the `impossible' happened):
lookupBindC:no in
> {-
>Hi,
>
>Compiling the following module results in the following error message
>(with GHC 2.09, patchlevel 0, i386-linux
>
>
> ------
> panic! (the `impossible' happene
> ran into this bug when compiling with the optimization flags:
> -H10M -O -fvia-C -O2-for-C
>
> "
> NOTE: Simplifier still going after 4 iterations; bailing out.
>
> NOTE: Simplifier still going after 4 iterations; bailing out.
>
> p
Great bug report, thanks. I've fixed it in the upcoming 2.09
S
> As a by-product of hacking Fudgets to death, a bug in ghc-2.08 showed up.
> Compiling the fragment from Fudgets below (the real names made as much
> sense to me as the ones below :-), ghc fails ungracefully:
>
>
27 matches
Mail list logo
