Opened 11 years ago

Closed 11 years ago

Last modified 3 years ago

#795 closed bug (fixed)

ghc-6.5.20060607: panic! (the 'impossible' happened) ... initC: srt

Reported by: ravi@… Owned by:
Priority: normal Milestone: 6.6
Component: Compiler Version: 6.5
Keywords: Cc:
Operating System: Linux Architecture: x86
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

I got the error above while compiling some of my code with the ghc 2006-06-07 snapshot.

Attachments (2)

ghc-bug.log (48.5 KB) - added by ravi@… 11 years ago.
output of running ghc -v
Bug795.hs (567 bytes) - added by ravi@… 11 years ago.
Boiled-down testcase

Download all attachments as: .zip

Change History (12)

Changed 11 years ago by ravi@…

Attachment: ghc-bug.log added

output of running ghc -v

comment:1 Changed 11 years ago by ravi@…

It's a self-built version of that snapshot where I tweaked the build process until I made a Debian package out of it, so it is *possible* I broke something, but the code that seems to generate that error (in compiler/codeGen/CgMonad.lhs) isn't near anything I remember touching. Unfortunately, I can't give you the relevant source that generates the error because it's internal to Bluespec.

Other relevant bits: I'm on a reasonably up-to-date Debian unstable machine, kernel 2.6.16-2-686 My gcc version is 4.1.2.20060608 (prerelease) (Debian 4.1.1-3)

comment:2 Changed 11 years ago by ravi@…

I also cleared out all of the existing files and compiled from scratch and had the same problem.

comment:3 Changed 11 years ago by ravi@…

I also verified that the code in question compiles without incident with 6.4.2.

comment:4 Changed 11 years ago by ravi@…

Using the native code generator (-fasm) does not avoid this bug.

comment:5 Changed 11 years ago by simonmar

Unfortunately we'll be unable to investigate this bug without a way to reproduce it. Is it possible you could send us the source code privately, if we give you an informal promise to keep it to ourselves and delete it when we've finished?

comment:6 Changed 11 years ago by simonmar

Milestone: 6.6

comment:7 Changed 11 years ago by ravi@…

Running with -dcore-lint was helpful. It was a little odd in that several (unrelated) modules failed to compile the first-time through with -dcore-lint and --make, but succeeded on a reattempt. However, the module in question (IExpand.hs) consistently failed with -dcore-lint and the message pointed to a function that took an implicit parameter as an argument. Rewriting the function to no longer use that implicit parameter fixed the problem. I'm going to attempt to boil things down from there and see if I can come up with a simpler example that illustrates the problem.

Changed 11 years ago by ravi@…

Attachment: Bug795.hs added

Boiled-down testcase

comment:8 Changed 11 years ago by ravi@…

Run ghc -fglasgow-exts -c Bug795.hs to reproduce.

Looking at the resulting code it seems like passing on an implicit parameter twice in the same function triggers the issue.

comment:9 Changed 11 years ago by simonpj

Resolution: fixed
Status: newclosed

Excellent bug report; Core Lint wins again.

It turns out that there's a long-standing bug, which I have now fixed. tc204 tests.

(I fear the commit message may say tc203, but it's 204!)

Meanwhile, I think should be able to work around by replacing

 ...?y...?y...?y...
{{{
   let x = ?y in ...x...x..x..
}}}

Simon

comment:10 Changed 3 years ago by simonpj <simonpj@…>

Note: See TracTickets for help on using tickets.