#15617: Unboxed tuples/sum error message on `a = show 5` in expression evaluation and interactive modes -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): So monoidal pointed out to me about this flag {{{ GHCi and -O --------------- When using optimization, the compiler can introduce several things (such as unboxed tuples) into the intermediate code, which GHCi later chokes on since the bytecode interpreter can't handle this (and while this is arguably a bug these aren't handled, there are no plans to fix it.) While the driver pipeline always checks for this particular erroneous combination when parsing flags, we also need to check when we update the flags; this is because API clients may parse flags but update the DynFlags afterwords, before finally running code inside a session (see T10052 and #10052). }}} I think this says that optimisation flags should be ignored by ghci. Indeed normally are: {{{ ~ $ ghci -O2 when making flags consistent: warning: -O conflicts with --interactive; -O ignored. GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/omer/rcbackup/.ghci }}} The problem is when we also add `-fbyte-code` then I guess the consistency check does not work as expected and accepts `-O2`: {{{ ~ $ ghci -fobject-code -O2 GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/omer/rcbackup/.ghci λ:1> a = show 5 Error: bytecode compiler can't handle unboxed tuples and sums. Possibly due to foreign import/export decls in source. Workaround: use -fobject-code, or compile this module to .o separately. }}} So this is probably just a matter of fixing the flag consistency check (whatever that is). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15617#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler