Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#10549 closed bug (fixed)

floatExpr tick break<2>

Reported by: NeilMitchell Owned by: bgamari
Priority: high Milestone: 7.10.3
Component: Compiler Version: 7.10.2
Keywords: Cc: ndmitchell@…, scpmw
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case: T10549,T10549a
Blocked By: Blocking:
Related Tickets: Differential Rev(s): Phab:D1128
Wiki Page:

Description

When running the Shake test suite against GHC HEAD I get:

ghc: panic! (the 'impossible' happened)
  (GHC version 7.11.20150615 for x86_64-unknown-linux):
	floatExpr tick break<2>()

Full log at https://travis-ci.org/ndmitchell/shake/jobs/67636563. The command line that produced it is:

runhaskell -ignore-package=hashmap -ioutput/docs/ -isrc output/docs/Main.hs

If this seems like a legitimate bug that you don't already know about and are interested in tracking down, I'll try and grab the output/docs directory (it's on a remote machine I don't have access to on a different OS with a compiler I don't have installed, so it's not trivial to find it, but should be possible).

Change History (18)

comment:1 Changed 3 years ago by simonpj

Cc: scpmw added

Sounds like one for Peter Wortmann. Peter, can you help?

Simon

comment:2 Changed 3 years ago by scpmw

This looks almost exactly like #10052. The gist of the discussion was that it is undefined to try to run optimisation passes such as FloatIn on a program with breakpoints.

So the question here is why runhaskell ends up running optimisations, especially after Austin's fix...

comment:3 Changed 3 years ago by simonpj

Can't we at least give a more civilised error message like "Attempting to run FloatIn on a program with breakpoints"?

And where are the breakpoints in the example?

comment:4 Changed 3 years ago by NeilMitchell

From what I can see, it looks like Austin's changes and all of #10052 was all in by 20150615, suggesting the bug is something different? I'm not deliberately doing anything with breakpoints, but it does have plenty of generated code (I convert the Haddock code snippets into code and try and type check them with some dummy definitions and the real Shake code).

comment:5 Changed 3 years ago by thomie

Milestone: 7.10.3
Priority: normalhigh
Version: 7.117.10.2

Here is a test to reproduce the problem with ghci.

{-# OPTIONS_GHC -O2 #-}
module T10549 where

import qualified Data.ByteString.Internal as Internal
import System.IO.Unsafe (unsafePerformIO)
import Data.Word (Word8)
import Foreign.Ptr (Ptr)
import Foreign.Storable (peek)

type S = Ptr Word8

chr :: S -> Char
chr x = Internal.w2c $ unsafePerformIO $ peek x

Running ghc-7.10.1 --interactive T10549.hs results in:

GHCi, version 7.10.1: http://www.haskell.org/ghc/  :? for help

T10549.hs:1:16: Warning:
    -O conflicts with --interactive; -O ignored
[1 of 1] Compiling T10549           ( T10549.hs, interpreted )
Ok, modules loaded: T10549.

Running ghc-7.10.2 --interactive T10549.hs results in:

GHCi, version 7.10.2: http://www.haskell.org/ghc/  :? for help
[1 of 1] Compiling T10549           ( T10549.hs, interpreted )
ghc: panic! (the 'impossible' happened)
  (GHC version 7.10.2 for x86_64-unknown-linux):
	floatExpr tick break<3>()

So somehow the OPTIONS_GHC -O2 in the file doesn't get ignored (it does when the -O2 is given on the command line instead).

To reproduce the problem with the Shake sources (version 0.15.4), run ghci src/Development/Ninja/Lexer.hs -isrc.

Last edited 3 years ago by thomie (previous) (diff)

comment:6 Changed 3 years ago by bgamari

Owner: set to bgamari

comment:7 Changed 3 years ago by bgamari

Austin's previous fix, 46edc43cbe011978d903dd0b5f0ffc62c602fbaa, is the first bad commit here. It seems the commit forgot to treat the case of -O coming from OPTIONS_GHC.

comment:8 Changed 3 years ago by thomie

See also the questions I raised about that patch in https://phabricator.haskell.org/D727.

comment:9 Changed 3 years ago by bgamari

Differential Rev(s): Phab:D1128
Status: newpatch
Test Case: T10549

comment:10 Changed 3 years ago by Ben Gamari <ben@…>

In eca9a1a1/ghc:

Ensure DynFlags are consistent

While we have always had makeDynFlagsConsistent to enforce a variety of
consistency invariants on DynFlags, it hasn't been widely used.
GHC.Main, for instance, ignored it entirely. This leads to issues like
Trac #10549, where an OPTIONS_GHC pragma introduced an inconsistency,
leading to a perplexing crash later in compilation.

Here I add consistency checks in GHC.Main.set{Session,Program}DynFlags,
closing this hole.

Fixes #10549.

Test Plan: Validate with T10549

Reviewers: austin

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D1128

GHC Trac Issues: #10549

comment:11 Changed 3 years ago by bgamari

Resolution: fixed
Status: patchclosed

comment:12 Changed 3 years ago by bgamari

Status: closedmerge

comment:13 Changed 3 years ago by nomeata

As Debian is moving to GHC-7.10, this is affecting us. So if someone would do the merge (which is not automatic) soon, that would be appreciated, as we would include that patch in our 7.10.2 package.

comment:14 Changed 3 years ago by bgamari

Status: mergeclosed

nomeata, your wish is my command.

I've merged this with 5af80e79b0b679565ffcfae8ed34188561ef1452 and 75fd8747c128c3f946769510ce8cfe089821116d. Sorry about the two commits; I pushed a bit before noticing some testsuite failures.

comment:15 Changed 3 years ago by nomeata

Thanks! Debian upload on its way.

comment:16 Changed 3 years ago by NeilMitchell

I ran into this again and reduced it to something fairly different, and quite a lot simpler. You may want to incorporate the new example as an additional test case:

{-# OPTIONS_GHC -O #-}
module Main(main) where
import GHC.Exts
main = print 1
go (Ptr a) = a

Note the revised test case only requires GHC, not ByteString etc. With GHC 7.10.2, running runhaskell over it gives:

ghc: panic! (the 'impossible' happened)
  (GHC version 7.10.2 for i386-unknown-mingw32):
        floatExpr tick break<1>()

comment:17 Changed 3 years ago by Ben Gamari <ben@…>

In c633f71/ghc:

Add another test for #10549

comment:18 Changed 3 years ago by bgamari

Test Case: T10549T10549,T10549a
Note: See TracTickets for help on using tickets.