Opened 12 years ago

Closed 10 years ago

#1501 closed bug (fixed)

Panic in RegisterAlloc

Reported by: guest Owned by: benl
Priority: high Milestone: 6.12 branch
Component: Compiler (NCG) Version: 6.9
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: x86
Type of failure: None/Unknown Test Case: cmm002
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


The following code causes a panic when compiling with the NCG (i.e. with -fasm).

stg_ap_0_fast {
    bits32 y, x;
    c7: y = bits32[x];
        goto c7;

The panic is

ghc-6.7.20070620: panic! (the 'impossible' happened)
  (GHC version 6.7.20070620 for i386-unknown-linux):

I do not know of any code that depends on this yet. I just tripped over it when writting tests for the CPS pass.

Change History (11)

comment:1 Changed 12 years ago by igloo

Milestone: 6.8

comment:2 Changed 12 years ago by simonmar

Resolution: fixed
Status: newclosed

I think the register allocator is confused because x is used without being assigned to, so the allocator doesn't think it's live. If you add an assignment to x it compiles without error.

Furthermore, the new graph-colouring allocator handles this just fine, so I'm going to close the bug.

comment:3 Changed 12 years ago by guest

Milestone: 6.8 branch
Resolution: fixed
Status: closedreopened
Version: 6.76.9

I have found a new manifestation of this bug even when all the variables are properly initialized.

stg_ap_0_fast {
    bits32 y, x;
    x = 16;
    if (0 != 0) { /* Doesn't matter what is here */ }
    y = bits32[x];
    c7: goto c7;

The same panic happens but only when the '-dcmm-lint' option is specified.

Some of the PrimOp.cmm code newPinnedByteArrayzh_fast does exactly this and trips the bug once the call to MAYBE_GC is removed from that function which I have to do to convert the RTS to use the CPS pass.

-- Michael D. Adams

comment:4 Changed 12 years ago by igloo

Milestone: 6.10 branch

comment:5 Changed 11 years ago by igloo

Milestone: 6.10 branch6.10.1
Priority: normalhigh

comment:6 Changed 11 years ago by simonmar

Resolution: worksforme
Status: reopenedclosed

Unable to reproduce with 6.8.3 on x86 or x86_64, with or without -dcmm-lint.

comment:7 Changed 11 years ago by simonmar

Milestone: branch
Resolution: worksforme
Status: closedreopened

However, on a hunch I added -O, and that made the compiler go into an infinite loop. We should check that the new code generator gets this right.

comment:8 Changed 11 years ago by simonmar

Operating System: MultipleUnknown/Multiple

comment:9 Changed 11 years ago by benl

Owner: set to benl
Status: reopenednew

comment:10 Changed 11 years ago by benl

Status: newassigned

comment:11 Changed 10 years ago by benl

Resolution: fixed
Status: assignedclosed
Note: See TracTickets for help on using tickets.