September 2017 - ghc-tickets

[GHC] #9775: "Failed to remove" errors during Windows build from hsc2hs
by GHC 18 Sep '17

18 Sep '17

#9775: "Failed to remove" errors during Windows build from hsc2hs -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The Windows build over here spews a bunch of errors during the build like the ones below. All of them seem to be related to hsc2hs. The errors do not the build for some reason, so the problem is not critical, but we should look into what's going on here. Note that the errors are indeterministic and the set of files affected varies between builds. Examples: {{{ ghctrace.2/3.log:Failed to remove file libraries/base/dist- install/build/System/CPUTime_hsc_make.exe; error= DeleteFile "libraries/base/dist-install/build/System/CPUTime_hsc_make.exe": permission denied (Access is denied.) ghctrace.2/4.log:Failed to remove file libraries/hpc/dist- boot/build/Trace/Hpc/Reflect_hsc_make.exe; error= DeleteFile "libraries/hpc/dist-boot/build/Trace/Hpc/Reflect_hsc_make.exe": permission denied (Access is denied.) ghctrace.2/4.log:Failed to remove file compiler/stage2/build/Fingerprint_hsc_make.exe; error= DeleteFile "compiler/stage2/build/Fingerprint_hsc_make.exe": permission denied (Access is denied.) ghctrace.3/1.log:Failed to remove file libraries/hpc/dist- boot/build/Trace/Hpc/Reflect_hsc_make.exe; error= DeleteFile "libraries/hpc/dist-boot/build/Trace/Hpc/Reflect_hsc_make.exe": permission denied (Access is denied.) ghctrace.3/4.log:Failed to remove file libraries/old-time/dist- install/build/System/Time_hsc_make.exe; error= DeleteFile "libraries/old- time/dist-install/build/System/Time_hsc_make.exe": permission denied (Access is denied.) ghctrace.3/5.log:Failed to remove file libraries/Win32/dist- install/build/Graphics/Win32/GDI/Pen_hsc_make.exe; error= DeleteFile "libraries/Win32/dist-install/build/Graphics/Win32/GDI/Pen_hsc_make.exe": permission denied (Access is denied.) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9775> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

Re: [GHC] #6084: Add stg_ap_pnnv and related call patterns
by GHC 18 Sep '17

18 Sep '17

#6084: Add stg_ap_pnnv and related call patterns -------------------------------------+------------------------------------- Reporter: SimonMeier | Owner: simonmar Type: feature request | Status: closed Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 8313 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): So what's the actual problem here? The caller assigns a couple of registers that are ignored by the callee, and the callee doesn't need to declare them to be live because they aren't used. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6084#comment:39> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13767: GHCi trips -DS checks at rts/sm/Sanity.c, line 210
by GHC 17 Sep '17

17 Sep '17

#13767: GHCi trips -DS checks at rts/sm/Sanity.c, line 210 -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.3 System | 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: -------------------------------------+------------------------------------- Error: {{{ $ echo -e ":quit\n" | ./inplace/bin/ghc-stage2 --interactive +RTS -DS -RTS -ignore-dot-ghci GHCi, version 8.3.20170515: http://www.haskell.org/ghc/ :? for help Prelude> Leaving GHCi. ghc-stage2: internal error: ASSERTION FAILED: file rts/sm/Sanity.c, line 210 (GHC version 8.3.20170515 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} Steps to reproduce: * Set `BuildFlavour = prof` in `mk/build.mk` * Add `GhcLibWays += p debug_p thr_debug_p` to `mk/build.mk`, I think you only need `thr_debug_p` * Build GHC * (cd ghc; make re2 GhcDebugged=YES), I think you can build it right away, but I'm not that familiar with the build system * `echo -e ":quit\n" | ./inplace/bin/ghc-stage2 --interactive +RTS -DS -RTS -ignore-dot-ghci` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13767> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #14036: GHCi HEAD segfaults upon startup with a prof build
by GHC 17 Sep '17

17 Sep '17

#14036: GHCi HEAD segfaults upon startup with a prof build -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHCi crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- After building GHC HEAD using a `mk/build.mk` file with the following settings: {{{ BuildFlavour = prof GhcStage2HcOpts = -O0 $(GhcFAsm) -fprof-auto -DDEBUG }}} I find myself knee-deep in segfault town: {{{ $ inplace/bin/ghc-stage2 --interactive GHCi, version 8.3.20170726: http://www.haskell.org/ghc/ :? for help Segmentation fault (core dumped) }}} Welp. Here's what happens when I run it through `gdb`: {{{ $ gdb inplace/lib/bin/ghc-stage2 GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from inplace/lib/bin/ghc-stage2...done. (gdb) r -B"/u/rgscott/Software/ghc2/inplace/lib" --interactive Starting program: /home/rgscott/Software/ghc2/inplace/lib/bin/ghc-stage2 -B"/u/rgscott/Software/ghc2/inplace/lib" --interactive [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7ffff635e700 (LWP 13161)] [New Thread 0x7ffff5b5d700 (LWP 13162)] [New Thread 0x7ffff535c700 (LWP 13163)] [New Thread 0x7ffff4b5b700 (LWP 13164)] GHCi, version 8.3.20170726: http://www.haskell.org/ghc/ :? for help Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff4b5b700 (LWP 13164)] 0x000000000514ecb3 in interpretBCO (cap=0x64b9fc0 <MainCapability>) at rts/Interpreter.c:743 743 if (get_itbl(UNTAG_CLOSURE(pap->fun))->type != BCO) { }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14036> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14241: Pattern synonyms defined through other pattern synonyms produce `impossible happened`
by GHC 16 Sep '17

16 Sep '17

#14241: Pattern synonyms defined through other pattern synonyms produce `impossible happened` ---------------------------------------+------------------------------- Reporter: Heimdell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: PatternSynonyms | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------------+------------------------------- This module content (Bug.hs) {{{#!hs {-# language PatternSynonyms #-} data A a = A a pattern B a = A a pattern C a = B a }}} causes ghci/runhaskell to fail: {{{ > :l Bug [1 of 1] Compiling Main ( Bug.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): kindPrimRep.go rep_a1r0 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} When using ghc everything compiles and even works, so adding the code {{{#!hs main = do let C a = A 1 print a }}} produced executable that prints "1". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14241> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10601: GHC should be distributed with debug symbols
by GHC 16 Sep '17

16 Sep '17

#10601: GHC should be distributed with debug symbols -------------------------------------+------------------------------------- Reporter: bitonic | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Now that we have the capability of producing code with DWARF symbols, we should distribute GHC with them, or at least give the option. The DWARF symbols in these case would be both for the C RTS and for the base Haskell libraries shipped with GHC. Building GHC with said symbols amounts to adding {{{ GhcRtsHcOpts += -g GhcLibHcOpts += -g }}} to `mk/build.mk`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10601> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #6084: Add stg_ap_pnnv and related call patterns
by GHC 16 Sep '17

16 Sep '17

#6084: Add stg_ap_pnnv and related call patterns -------------------------------------+------------------------------------- Reporter: SimonMeier | Owner: simonmar Type: feature request | Status: closed Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 8313 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > On the other hand, I don't see where we'd use those in the body of `p_entry`. And thus why we'd want to pass them in the first place? Because this is what the calling convention that the function exposes. If the functions in `T6084` didn't have `NOINLINE` pragmas then we would have eliminated these dead arguments during core2core. However, since they do we are forced to expose precisely the calling convention that the user wrote. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6084#comment:38> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6084: Add stg_ap_pnnv and related call patterns
by GHC 16 Sep '17

16 Sep '17

#6084: Add stg_ap_pnnv and related call patterns -------------------------------------+------------------------------------- Reporter: SimonMeier | Owner: simonmar Type: feature request | Status: closed Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 8313 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by angerman): cmm, as per `-ddump-cmm`. I believe the relevant part is {{{ ==================== Output Cmm ==================== [section ""relreadonly" . S4QA_srt" { S4QA_srt: const Main.q1_closure; }, section ""data" . Main.p_closure" { Main.p_closure: const Main.p_info; const 0; }, Main.p_slow() // [R1] { info_tbl: [] stack_info: arg_space: 0 updfr_space: Nothing } {offset c4Qt: // global D2 = F64[Sp + 16]; F1 = F32[Sp + 8]; R2 = I64[Sp]; R1 = R1; Sp = Sp + 24; call Main.p_info(D2, F1, R2, R1) args: 8, res: 0, upd: 8; } }, Main.p_entry() // [] { info_tbl: [(c4Qx, label: Main.p_info rep:HeapRep static { Fun {arity: 3 fun_type: ArgGen [True, True, True]} })] stack_info: arg_space: 0 updfr_space: Nothing } {offset c4Qx: // global R1 = Main.q1_closure; call (I64[R1])(R1) args: 8, res: 0, upd: 8; } }] }}} However, my Cmm knowledge is rather limited. The llvm backend then does: {{{ pprLlvmCmmDecl (CmmProc mb_info entry_lbl live (ListGraph blks)) = do let lbl = case mb_info of Nothing -> entry_lbl Just (Statics info_lbl _) -> info_lbl link = if externallyVisibleCLabel lbl then ExternallyVisible else Internal lmblocks = map (\(BasicBlock id stmts) -> LlvmBlock (getUnique id) stmts) blks funDec <- llvmFunSig live lbl link dflags <- getDynFlags let buildArg = fsLit . showSDoc dflags . ppPlainName funArgs = map buildArg (llvmFunArgs dflags live) funSect = llvmFunSection dflags (decName funDec) -- generate the info table prefix <- case mb_info of Nothing -> return Nothing Just (Statics _ statics) -> do infoStatics <- mapM genData statics let infoTy = LMStruct $ map getStatType infoStatics return $ Just $ LMStaticStruc infoStatics infoTy let fun = LlvmFunction funDec funArgs llvmStdFunAttrs funSect prefix lmblocks name = decName $ funcDecl fun defName = name `appendFS` fsLit "$def" funcDecl' = (funcDecl fun) { decName = defName } fun' = fun { funcDecl = funcDecl' } funTy = LMFunction funcDecl' funVar = LMGlobalVar name (LMPointer funTy) link Nothing Nothing Alias defVar = LMGlobalVar defName (LMPointer funTy) (funcLinkage funcDecl') (funcSect fun) (funcAlign funcDecl') Alias alias = LMGlobal funVar (Just $ LMBitc (LMStaticPointer defVar) (LMPointer $ LMInt 8)) return (ppLlvmGlobal alias $+$ ppLlvmFunction fun', []) -- ... llvmFunSig :: LiveGlobalRegs -> CLabel -> LlvmLinkageType -> LlvmM LlvmFunctionDecl llvmFunSig live lbl link = do lbl' <- strCLabel_llvm lbl llvmFunSig' live lbl' link llvmFunSig' :: LiveGlobalRegs -> LMString -> LlvmLinkageType -> LlvmM LlvmFunctionDecl llvmFunSig' live lbl link = do let toParams x | isPointer x = (x, [NoAlias, NoCapture]) | otherwise = (x, []) dflags <- getDynFlags return $ LlvmFunctionDecl lbl link (llvmGhcCC dflags) LMVoid FixedArgs (map (toParams . getVarType) (llvmFunArgs dflags live)) (llvmFunAlign dflags) -- ... -- | A Function's arguments llvmFunArgs :: DynFlags -> LiveGlobalRegs -> [LlvmVar] llvmFunArgs dflags live = map (lmGlobalRegArg dflags) (filter isPassed (activeStgRegs platform)) where platform = targetPlatform dflags isLive r = not (isSSE r) || r `elem` alwaysLive || r `elem` live isPassed r = not (isSSE r) || isLive r isSSE (FloatReg _) = True isSSE (DoubleReg _) = True isSSE (XmmReg _) = True isSSE (YmmReg _) = True isSSE (ZmmReg _) = True isSSE _ = False -- ... -- | A list of STG Registers that should always be considered alive alwaysLive :: [GlobalReg] alwaysLive = [BaseReg, Sp, Hp, SpLim, HpLim, node] }}} As the set of live registers for `Main.p_info` (`Main.p_entry()`) is empty, we end up generating the default signature for {{{ ["BaseReg","Sp","Hp","R1","R2","R3","R4","R5","R6","SpLim"] }}} only, when we supposedly would want to have included `F1` and `D2` as well. On the other hand, I don't see where we'd use those in the body of `p_entry`. And thus why we'd want to pass them in the first place? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6084#comment:37> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6084: Add stg_ap_pnnv and related call patterns
by GHC 15 Sep '17

15 Sep '17

#6084: Add stg_ap_pnnv and related call patterns -------------------------------------+------------------------------------- Reporter: SimonMeier | Owner: simonmar Type: feature request | Status: closed Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 8313 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by angerman): * Attachment "T6084.cmm" added. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6084> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13870: Empty record construction for record-less constructor gives surprising runtime error (and surprisingly few warnings)
by GHC 15 Sep '17

15 Sep '17

#13870: Empty record construction for record-less constructor gives surprising runtime error (and surprisingly few warnings) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: newcomer | 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: -------------------------------------+------------------------------------- The crux of this ticket is this sort of code: {{{#!hs module Main where f :: Maybe Int f = Just{} main :: IO () main = print f }}} {{{ $ runghc --ghc-arg=-Wall Bug.hs Just Bug.hs: Bug.hs:4:5-10: Missing field in record construction }}} Yikes. There are a couple of very surprising things happening here. First, the message `Missing field in record construction` is very misleading. After all, `Just` has no records! We really should give a more specific error which highlights this fact. (The fact that you can even use record construction syntax with a record- less constructor in the first place is a bit baffling, but the [https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-520003.… language standard does allow it], so I suppose we have to live with this.) The second surprising bit is the fact that is program compiled with no warnings whatsoever. This is in contrast to, say, the `Identity` datatype, which has a record (`runIdentity`): {{{#!hs module Main where import Data.Functor.Identity f :: Identity Int f = Identity{} main :: IO () main = print f }}} {{{ $ runghc --ghc-arg=-Wall Bug.hs Bug.hs:6:5: warning: [-Wmissing-fields] • Fields of ‘Identity’ not initialised: runIdentity • In the expression: Identity {} In an equation for ‘f’: f = Identity {} Identity Bug.hs: Bug.hs:6:5-14: Missing field in record construction runIdentity }}} Here, GHC warned me that I was doing something stupid. GHC ought to be warning me with equivalent fervor when I use `Just{}`. The warning would obviously have to be tweaked a bit, since warning that `Fields of ‘Just’ not initialised` doesn't make any sense, but you get the idea. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13870> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4