Opened 8 years ago

Closed 8 years ago

Last modified 3 months 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: Difficulty: Unknown
Test Case: Blocked By:
Blocking: Related Tickets:

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@… 8 years ago.
output of running ghc -v
Bug795.hs (567 bytes) - added by ravi@… 8 years ago.
Boiled-down testcase

Download all attachments as: .zip

Change History (12)

Changed 8 years ago by ravi@…

output of running ghc -v

comment:1 Changed 8 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 8 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 8 years ago by ravi@…

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

comment:4 Changed 8 years ago by ravi@…

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

comment:5 Changed 8 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 8 years ago by simonmar

  • Milestone set to 6.6

comment:7 Changed 8 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 8 years ago by ravi@…

Boiled-down testcase

comment:8 Changed 8 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 8 years ago by simonpj

  • Resolution set to fixed
  • Status changed from new to closed

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 months ago by simonpj <simonpj@…>

Note: See TracTickets for help on using tickets.