Opened 8 years ago

Closed 4 years ago

Last modified 9 months ago

#1257 closed bug (wontfix)

Bytecode generator can't handle unboxed tuples

Reported by: igloo Owned by:
Priority: high Milestone: 7.4.1
Component: GHCi Version: 6.6
Keywords: Cc: michal.terepeta@…, hvr, rodlogic
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case: dsrun014
Blocked By: Blocking:
Related Tickets: Differential Revisions:

Description

We need to implement unboxed tuple support in ghci.

For example, with:

f :: a -> b -> (# a, b #)
f x y = (# x, y #)

we get:

$ ghci -v0 -fglasgow-exts w.hs
ghc-6.6: panic! (the 'impossible' happened)
  (GHC version 6.6 for x86_64-unknown-linux):
        Bytecode generator can't handle unboxed tuples.  Possibly due
        to foreign import/export decls in source.  Workaround:
        compile this module to a .o file, then restart session.

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

Change History (11)

comment:1 Changed 8 years ago by simonmar

  • Owner set to simonmar

IIRC, it's not really feasible to do this in general. I'll investigate before 6.8 anyway.

comment:2 Changed 8 years ago by simonmar

  • Milestone changed from 6.8 branch to _|_
  • Owner simonmar deleted

This isn't going to happen, mainly because there are an infinite family of return conventions for unboxed tuples. We could cover more cases without too much difficulty, but the general case is really hard. Given that you can now do -fobject-code, it doesn't really seem worth it.

comment:3 Changed 7 years ago by simonmar

  • Architecture changed from Unknown to Unknown/Multiple

comment:4 Changed 7 years ago by simonmar

  • Operating System changed from Unknown to Unknown/Multiple

comment:5 follow-up: Changed 4 years ago by michalt

  • Cc michal.terepeta@… added
  • Status changed from new to infoneeded
  • Type of failure set to None/Unknown

I've just tried to load a file with the above example and ghci just printed a
nice error message:

[1 of 1] Compiling Test             ( Test.hs, interpreted )
Error: bytecode compiler can't handle unboxed tuples.
  Possibly due to foreign import/export decls in source.
  Workaround: use -fobject-code, or compile this module to .o separately.
>

So if it is difficult to implement and one can use -fobject-code then maybe
we should just close the ticket?

comment:6 in reply to: ↑ 5 Changed 4 years ago by simonmar

Replying to michalt:

So if it is difficult to implement and one can use -fobject-code then maybe
we should just close the ticket?

That's what the _|_ milestone is for: bugs that either we can't fix, or aren't important enough to fix.

In this case, wouldn't it be better if GHC just automatically switched on -fobject-code?

comment:7 Changed 4 years ago by igloo

  • Milestone changed from _|_ to 7.4.1
  • Priority changed from normal to high
  • Status changed from infoneeded to new

Let's either automatically enable -fobject-code, or add a suggestion to turn it on to the error message, and then close this ticket as wontfix.

comment:8 Changed 4 years ago by igloo

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

Oh, the error already suggests -fobject-code.

I'm not a fan of magic like turning -fobject-code on automatically, so let's just mark this wontfix.

comment:9 Changed 9 months ago by rodlogic

  • Cc hvr added

Could someone expand a bit on why there are infinite family of return conventions for unboxed tuples? And possibly how could this restriction be lifted?

comment:10 Changed 9 months ago by rodlogic

  • Cc rodlogic added

comment:11 Changed 9 months ago by simonmar

The problem is at the boundary between compiled code and interpreted code. We have a few special-purpose stack frames that do the impedence matching between the two worlds, one for each return convention. The problem with unboxed tuples is that there aren't a fixed number of return conventions, so we can't cover all the cases with a few stack frames.

I haven't thought about this for a long time, but perhaps there's a way to make a generic stack frame that takes some kind of descriptor to describe the convention.

Last edited 9 months ago by simonmar (previous) (diff)
Note: See TracTickets for help on using tickets.