December 2015 - ghc-tickets

[GHC] #11167: Fixity of field-deconstructors incorrect
by GHC 05 Jan '16

05 Jan '16

#11167: Fixity of field-deconstructors incorrect -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The example below {{{#!hs module Foo where data SomeException newtype ContT r m a = ContT {runContT :: (a -> m r) -> m r} runContT' :: ContT r m a -> (a -> m r) -> m r runContT' = runContT catch_ :: IO a -> (SomeException -> IO a) -> IO a catch_ = undefined -- has type error foo :: IO () foo = (undefined :: ContT () IO a) `runContT` (undefined :: a -> IO ()) `catch_` (undefined :: SomeException -> IO ()) -- typechecks foo' :: IO () foo' = (undefined :: ContT () IO a) `runContT'` (undefined :: a -> IO ()) `catch_` (undefined :: SomeException -> IO ()) }}} works with GHC 7.10 but breaks with GHC HEAD currently with: {{{ foo.hs:15:47: error: • Couldn't match expected type ‘a0 -> IO ()’ with actual type ‘IO ()’ • In the second argument of ‘runContT’, namely ‘(undefined :: a -> IO ()) `catch_` (undefined :: SomeException -> IO ())’ In the expression: runContT (undefined :: ContT () IO a) (undefined :: a -> IO ()) `catch_` (undefined :: SomeException -> IO ()) In an equation for ‘foo’: foo = runContT (undefined :: ContT () IO a) (undefined :: a -> IO ()) `catch_` (undefined :: SomeException -> IO ()) foo.hs:15:48: error: • Couldn't match expected type ‘IO ()’ with actual type ‘a1 -> IO ()’ • In the first argument of ‘catch_’, namely ‘(undefined :: a -> IO ())’ In the second argument of ‘runContT’, namely ‘(undefined :: a -> IO ()) `catch_` (undefined :: SomeException -> IO ())’ In the expression: runContT (undefined :: ContT () IO a) (undefined :: a -> IO ()) `catch_` (undefined :: SomeException -> IO ()) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11167> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #11103: DuplicateRecordFields + TemplateHaskell
by GHC 05 Jan '16

05 Jan '16

#11103: DuplicateRecordFields + TemplateHaskell -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Template | Version: 7.11 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The [wiki:Records/OverloadedRecordFields/DuplicateRecordFields DuplicateRecordFields] extension works by mangling the Names of field selector functions, and treating fields specially in the renamer. Thus if you define {{{ data T = MkT { foo :: Int } }}} then GHC will actually generate a selector called `$sel:foo:MkT`, but will resolve `foo` to refer to this selector. In general we want this name-mangling to be internal only, but at the moment it is visible when using Template Haskell, because the TH AST doesn't have a way to represent the distinction between the selector name and the field label. For example, if you reify `''T` above and then pretty-print it you will currently get {{{ data T = MkT { $sel:foo:MkT :: Int } }}} which is obviously bad. I'm not sure how best to address this. We could represent the name as `mkNameG_v pkg mod "foo"`, which will look okay when inspected, but if it is subsequently reified it might be ambiguous. Should we add a new `NameFlavour`? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11103> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10643: GHC cannot import submodules when run from subfolder
by GHC 05 Jan '16

05 Jan '16

#10643: GHC cannot import submodules when run from subfolder -------------------------------------+------------------------------------- Reporter: FPtje | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: subfolder | Operating System: Unknown/Multiple import submodule cd | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I'm taking a huge risk in looking like an idiot, but it's worth trying to attack the elephant in the room. The first response I expect is ''"This is expected behaviour!"''. This is what intuition says, but I disagree. It's a simple problem and the fix should be easy, unless there's some advanced import mechanism that would conflict with the solution that I don't know about. That is exactly where I'm taking the risk in reporting this issue. The problem is simple: 1. Create a folder called "Yes". 2. Create Yes/A.hs with the following code: {{{#!hs module Yes.A where import Yes.B }}} 3. Create Yes/B.hs with the following code: {{{#!hs module Yes.B where }}} 4. Open a terminal in the folder that contains "Yes" and run: {{{ $ ghc Yes/A.hs }}} '''This works fine'''. Now try the following: {{{ $ cd Yes Yes/ $ ghc A.hs }}} You'll be greeted with the beautiful error: {{{ A.hs:3:8: Could not find module ‘Yes.B’ Use -v to see a list of the files searched for. }}} A screenshot is worth the above thousand words: http://i.imgur.com/8AxRa0K.png '''This is silly'''. Running with the -v option shows that ghc is not looking for Yes/B.hs, but Yes/Yes/B.hs. I can understand ''why'' it looks there, but not why ghc isn't just this ''tiny'' bit more intelligent in knowing where to look. After all, the module name tells ghc ''exactly'' in which subfolder it is located: {{{#!hs module Yes.A where -- This module is very likely to be in Yes/, because otherwise a name inconsistency error is thrown. }}} '''Proposed solution:''' The module name tells ghc exactly where it is located. If Yes.A imports Yes.B, then you know that they're in the same subfolder. Simple as that. Instead of ignoring that information and looking for Yes/Yes/B.hs, it should simply look for Yes/B.hs. Relative to ghc (which is run from Yes/) this would be ./B.hs. This solution is scalable. Imagine a module Ding.Dong.Biddly.Bong that imports Ding.Dong.Doodle.Bell. Running "ghc Bong.hs" from Ding/Dong/Biddly/ should '''not''' make it look for "Ding/Dong/Biddly/Ding/Dong/Doodle/Bell.hs", but for Ding/Dong/Doodle/Bell.hs. Relative to ghc (run from Ding/Dong/Biddly/), this would be ../Doodle/Bell.hs. So yeah, right now ghc is arbitrarily restricted to run from the root of the source directory. This '''looks''' like intended behaviour until you realise that the silly bug mentioned here is probably the only thing that prevents ghc from running from ''any'' subfolder. Of course there are the -i and :set options for ghc that allows one to work around this, but one should not be expected to jump through all the -iFile hoops to be allowed to run ghc from any arbitrary subdirectory of the source folder. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10643> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #10984: the ghc-7.8.4 source distribution contents (README, etc.)
by GHC 05 Jan '16

05 Jan '16

#10984: the ghc-7.8.4 source distribution contents (README, etc.) -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- ghc-7.8.4-src.tar.xz from https://www.haskell.org/ghc/download_ghc_7_8_4 does not include a README or INSTALL file. Its ANNOUNCE file talks of ghc-7.8.2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10984> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #11290: T6031: *** Core Lint errors : in result of Common sub-expression ***
by GHC 04 Jan '16

04 Jan '16

#11290: T6031: *** Core Lint errors : in result of Common sub-expression *** -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: deriving/should_compile/T6031 | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ $ make test TEST=T6031 WAY=optasm TEST_HC=ghc-7.11.20151225 ... =====> T6031(optasm) 1 of 1 [0, 0, 0] cd ./deriving/should_compile && "/opt/ghc/head/bin/ghc-head" --make T6031 -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user- package-db -rtsopts -fno-warn-tabs -fno-warn-missed-specialisations -fno- ghci-history -O -fasm -v0 > T6031.comp.stderr 2>&1 Compile failed (status 256) errors were: *** Core Lint errors : in result of Common sub-expression *** <no location info>: warning: [in body of lambda with binder x_aSX :: Empty] No alternatives for a case scrutinee not known to diverge for sure: lvl_sUb *** Offending Program *** lvl_sTZ :: [Char] [LclId, Str=DmdType] lvl_sTZ = unpackCString# "error"# lvl_sU0 :: [Char] [LclId, Str=DmdType] lvl_sU0 = unpackCString# "main"# lvl_sU1 :: [Char] [LclId, Str=DmdType] lvl_sU1 = unpackCString# "T6031"# lvl_sU2 :: [Char] [LclId, Str=DmdType] lvl_sU2 = unpackCString# "T6031.hs"# lvl_sU3 :: Int [LclId, Str=DmdType] lvl_sU3 = I# 7# lvl_sU4 :: Int [LclId, Str=DmdType] lvl_sU4 = I# 1# lvl_sU5 :: Int [LclId, Str=DmdType] lvl_sU5 = lvl_sU3 lvl_sU6 :: Int [LclId, Str=DmdType] lvl_sU6 = I# 29# lvl_sU7 :: SrcLoc [LclId, Str=DmdType] lvl_sU7 = SrcLoc lvl_sU0 lvl_sU1 lvl_sU2 lvl_sU3 lvl_sU4 lvl_sU3 lvl_sU6 lvl_sU8 :: ([Char], SrcLoc) [LclId, Str=DmdType] lvl_sU8 = (lvl_sTZ, lvl_sU7) lvl_sU9 :: CallStack [LclId, Str=DmdType] lvl_sU9 = PushCallStack lvl_sU8 EmptyCallStack lvl_sUa :: [Char] [LclId, Str=DmdType] lvl_sUa = unpackCString# "Void showsPrec"# $cshowsPrec_aQD :: Int -> Empty -> ShowS [LclId, Str=DmdType b] $cshowsPrec_aQD = error @ 'Lifted @ (Int -> Empty -> ShowS) (lvl_sU9 `cast` (Sym (NTCo:IP[0] <"callStack">_N <CallStack>_N) :: CallStack ~R# (?callStack::CallStack))) lvl_sUa lvl_sUb :: Empty -> ShowS [LclId, Str=DmdType] lvl_sUb = case $cshowsPrec_aQD of wild_00 { } $cshowList_aQR :: [Empty] -> ShowS [LclId, Arity=2, Str=DmdType] $cshowList_aQR = showList__ @ Empty lvl_sUb $cshow_aQN :: Empty -> String [LclId, Arity=1, Str=DmdType <B,A>b, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=1,unsat_ok=True,boring_ok=False) Tmpl= \ _ [Occ=Dead] -> case $cshowsPrec_aQD of _ [Occ=Dead] { }}] $cshow_aQN = \ _ [Occ=Dead] -> case $cshowsPrec_aQD of wild_00 { } $fShowEmpty [InlPrag=[ALWAYS] CONLIKE] :: Show Empty [LclIdX[DFunId], Str=DmdType m, Unf=DFun: \ -> D:Show TYPE: Empty $cshowsPrec_aQD $cshow_aQN $cshowList_aQR] $fShowEmpty = D:Show @ Empty $cshowsPrec_aQD $cshow_aQN $cshowList_aQR $sshows_sTu :: Empty -> String -> String [LclId, Str=DmdType b, Unf=Unf{Src=InlineStable, TopLvl=True, Value=False, ConLike=False, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=False) Tmpl= case $cshowsPrec_aQD of _ [Occ=Dead] { }}] $sshows_sTu = lvl_sUb $s$dmshow_sTv :: Empty -> String [LclId, Arity=1, Str=DmdType <B,A>b, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=-1,unsat_ok=True,boring_ok=False) Tmpl= \ _ [Occ=Dead] -> case lvl_sUb of _ [Occ=Dead] { }}] $s$dmshow_sTv = $cshow_aQN a_sT8 :: TrName [LclId, Str=DmdType m1] a_sT8 = TrNameS "main"# a_sT9 :: TrName [LclId, Str=DmdType m1] a_sT9 = TrNameS "T6031"# $trModule :: Module [LclIdX[ReflectionId], Str=DmdType m] $trModule = Module a_sT8 a_sT9 *** End of Offense *** <no location info>: error: Compilation had errors *** unexpected failure for T6031(optasm) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11290> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #10874: Implement `:type-at`, `:all-types`, `:loc-at` in GHCi
by GHC 04 Jan '16

04 Jan '16

#10874: Implement `:type-at`, `:all-types`, `:loc-at` in GHCi -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- We missed the opportunity to merge this for GHC 7.10 but I hope this can make it for GHC 8.0 See https://github.com/chrisdone/ghci-ng/blob/master/README.md for a description of the new GHCi commands I've started rebasing the changes from Chris' ghci-ng repo against GHC HEAD and pushed the work-in-progress state as branch `wip/T10874`. One blocker right now is the use of SYB to traverse the AST which I don't want to drag into GHC as a dependency. So one thing that needs to be done is rewrite those 20 lines of code without relying on SYB. Other than that some minor polishing needs to be done. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10874> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10045: type holes related ghc panic
by GHC 04 Jan '16

04 Jan '16

#10045: type holes related ghc panic -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- {{{ sample.hs:9:13: Couldn't match expected type ‘t’ with actual type ‘()’ ‘t’ is untouchable inside the constraints () bound by the inferred type of foo :: Meta -> t1 at sample.hs:(6,1)-(9,17)ghc: panic! (the 'impossible' happened) (GHC version 7.10.0.0 for x86_64-unknown-linux): No skolem info: t_avJ[sk] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug sample.hs: module Blah where newtype Meta = Meta () foo (Meta ws1) = let copy :: _ copy w from = copy w 1 in copy ws1 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10045> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #10737: GHC panic durring MVar operation
by GHC 04 Jan '16

04 Jan '16

#10737: GHC panic durring MVar operation -------------------------------------+------------------------------------- Reporter: dohaqatar7 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The following error message was displayed while loading a program into ghci by executing `:r` in a ghci session: {{{ ghc.exe: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-mingw32): thread blocked indefinitely in an MVar operation Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The only edit made to the source file before compiling was the removal of an unnecessary `do` on line 20 of the source file. The `do` was used even though the monodic computations were written in a single line style. I have not been able to reproduce the panic at all. The source file, unedited since the panic, now compiles without error. The ghci session leading up to the crash is below {{{ *Main> :t runState (filterM untouchable [1..3]) M.empty runState (filterM untouchable [1..3]) M.empty :: ([Int], M.Map Int Int) *Main> runState (filterM untouchable [1..3]) M.empty ([2],fromList [(1,1),(2,1),(3,1),(4,3)]) *Main> runState (filterM untouchable [1..10]) M.empty ([2,5],fromList [(1,1),(2,1),(3,1),(4,3),(5,1),(6,6),(7,1),(8,7),(9,4),(10,8),(11,1),(12,16),(13,1),(14,10),(15,9),(16,15),(17,1),(18,21),(19,1),(20,22),(21,11),(22,14),(23,1),(24,36),(25,6),(26,16),(27,13),(28,28),(29,1),(30,42),(31,1),(32,31),(33,15),(34,20),(35,13),(36,55),(37,1),(38,22),(39,17),(40,50),(41,1),(42,54),(43,1),(44,40),(45,33),(46,26),(47,1),(48,76),(49,8),(50,43),(51,21),(52,46),(53,1),(54,66),(55,17),(56,64),(57,23),(58,32),(59,1),(60,108),(61,1),(62,34),(63,41),(64,63),(65,19),(66,78),(67,1),(68,58),(69,27),(70,74),(71,1)(72,123),(73,1),(74,40),(75,49),(76,64),(77,19),(78,90),(79,1),(80,106),(81,40)]) *Main> runState (filterM untouchable [1..100]) M.empty ([2,5,52,88Interrupted. *Main> *Main> *Main> *Main> *Main> *Main> *Main> *Main> *Main> :r [1 of 1] Compiling Main ( C:\Users\admin\Programming\Haskell\codegolf\Untouchable.hs, interpreted ) Ok, modules loaded: Main. *Main> ghc.exe: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-mingw32): thread blocked indefinitely in an MVar operation Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10737> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11175: Holding Ctrl+C on Windows GHCI Prompt crashes with concurrency panic
by GHC 04 Jan '16

04 Jan '16

#11175: Holding Ctrl+C on Windows GHCI Prompt crashes with concurrency panic ----------------------------------------+--------------------------------- Reporter: cwfenner | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: GHCi | Version: 7.10.2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- When I hold Control-C in the GHCI prompt (on either Windows Powershell or Command Prompt), then release, the prompt stops responding. The first few keystrokes will be ignored altogether, then the next ignored intermittently. After typing around 5 words, GHCi crashes with the following output: {{{ ghc.exe: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-mingw32): thread blocked indefinitely in an MVar operation }}} If I don't type after holding Ctrl+C, GHCi seems to sit happily without crashing. No amount of waiting after holding Ctrl+C seems to make it recover. It does not matter whether I press return or not. However, faster typing seems to make it crash in fewer keystrokes. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11175> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #10531: modules that can be linked successfully when compiled with optimizations, fail to link with: multiple definition of `__stginit_ZCMain'
by GHC 03 Jan '16

03 Jan '16

#10531: modules that can be linked successfully when compiled with optimizations, fail to link with: multiple definition of `__stginit_ZCMain' -------------------------------------+------------------------------------- Reporter: imz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: GHC rejects (amd64) | valid program Test Case: attached | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When compiling a set of 3 modules (in a certain order), linking of the final executable fails because there conflicting symbols in some of the `.o`. When doing the compilation in the same order, but with optimizations, it succeeds. The simple test case: A.hs: {{{#!hs module A where main :: IO () main = putStrLn "A" }}} B.hs: {{{#!hs module B where import A() main :: IO () main = putStrLn "B" }}} C.hs: {{{#!hs import B() main :: IO () main = putStrLn "hi" }}} When I compile it with in the order specified by the attached `./bug- reproduce.sh` and `Makefile`, the following happens: {{{ ./bug-reproduce.sh rm -fv a A.o A.hi removed 'a' removed 'A.o' removed 'A.hi' rm -fv b B.o B.hi removed 'b' removed 'B.o' removed 'B.hi' rm -fv c C.o C.hi removed 'c' removed 'C.o' removed 'C.hi' ghc -Wall A.hs -main-is A.main -o a [1 of 1] Compiling A ( A.hs, A.o ) Linking a ... ghc -Wall B.hs -main-is B.main -o b [1 of 2] Compiling A ( A.hs, A.o ) [flags changed] [2 of 2] Compiling B ( B.hs, B.o ) Linking b ... ghc -Wall C.hs -o c [2 of 3] Compiling B ( B.hs, B.o ) [flags changed] [3 of 3] Compiling Main ( C.hs, C.o ) Linking c ... removed 'A.o' ghc -Wall A.hs -main-is A.main -o a [1 of 1] Compiling A ( A.hs, A.o ) Linking a ... ghc -Wall B.hs -main-is B.main -o b [2 of 2] Compiling B ( B.hs, B.o ) [flags changed] Linking b ... ./A.o: In function `siv_closure': (.data+0x0): multiple definition of `__stginit_ZCMain' B.o:(.data+0x0): first defined here ./A.o: In function `ZCMain_main_srt': (.data+0x70): multiple definition of `ZCMain_main_closure' B.o:(.data+0x70): first defined here ./A.o:(.text+0xb8): multiple definition of `ZCMain_main_info' B.o:(.text+0xb8): first defined here collect2: error: ld returned 1 exit status make: *** [B.o] Error 1 }}} But it succeeds if done as `./bug-reproduce.sh GHC_OPTS=-O1` (probably, the optimizations remove the conflicting symbols): {{{ ./bug-reproduce.sh GHC_OPTS=-O1 rm -fv a A.o A.hi removed 'a' removed 'A.o' removed 'A.hi' rm -fv b B.o B.hi removed 'b' removed 'B.o' removed 'B.hi' rm -fv c C.o C.hi removed 'c' removed 'C.o' removed 'C.hi' ghc -Wall -O1 A.hs -main-is A.main -o a [1 of 1] Compiling A ( A.hs, A.o ) Linking a ... ghc -Wall -O1 B.hs -main-is B.main -o b [1 of 2] Compiling A ( A.hs, A.o ) [flags changed] [2 of 2] Compiling B ( B.hs, B.o ) Linking b ... ghc -Wall -O1 C.hs -o c [2 of 3] Compiling B ( B.hs, B.o ) [flags changed] [3 of 3] Compiling Main ( C.hs, C.o ) Linking c ... removed 'A.o' ghc -Wall -O1 A.hs -main-is A.main -o a [1 of 1] Compiling A ( A.hs, A.o ) Linking a ... ghc -Wall -O1 B.hs -main-is B.main -o b [1 of 2] Compiling A ( A.hs, A.o ) [flags changed] [2 of 2] Compiling B ( B.hs, B.o ) [flags changed] Linking b ... ghc -Wall -O1 C.hs -o c [2 of 3] Compiling B ( B.hs, B.o ) [flags changed] Linking c ... }}} Couldn't the compiler detect and handle such cases? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10531> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9