- ghc-tickets - Haskell.org

[GHC] #12602: Add NUMA support to Windows
by GHC 02 Oct '16

02 Oct '16

#12602: Add NUMA support to Windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11054 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Add support for NUMA for Windows. Core APIs are here https://msdn.microsoft.com/en- us/library/windows/desktop/aa363804(v=vs.85).aspx and map pretty closely to the Linux ones for our needs. Support is just filling in the gaps in the new functions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12602> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12186: GHC compiled executable incompatible with 3rd party software
by GHC 02 Oct '16

02 Oct '16

#12186: GHC compiled executable incompatible with 3rd party software -------------------------------------+------------------------------------- Reporter: tim-m89 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've been trying to work on a library that allows Haskell to call into .Net code, but there's a major show stopper in that the .Net runtime starting with version 4.0, doesn't like the executable files that GHC produces. I've managed to reduce a test case to not actually depend on using Haskell, but just using GHC to compile a C file, and that C file being nothing but a dumb wrapper around a small dll. The resulting executable exhibits the incorrect behaviour: {{{ > stack exec ghc -- main.c -no-hs-main > main 1 2 3 4 5 6 ICLRRuntimeHost Start failed w/hr 0x80004005 }}} Then I can also use GCC on the intermediate object file that was created, and produce an executable that exhibits the correct behaviour: {{{ > stack exec gcc -- main.o -o main2.exe > main2 1 2 3 4 5 6 7 8 }}} I've put a copy of the test case here: https://gitlab.com/tim-m89/DotNetHostingTest -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12186> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits
by GHC 02 Oct '16

02 Oct '16

#8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits ----------------------------+--------------------------------------- Reporter: facundoq | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+--------------------------------------- Windows shows a window that says "GHC has stopped working" when compiling a simple hello world. Steps to reproduce 1) Download GHC 7.8 RC2 (http://www.haskell.org/ghc/dist/7.8.1-rc2/ghc-7.8.0.20140228-i386 -unknown-mingw32.tar.bz2) 2) Extract the contents of the tar to folder $GHC$ 3) Add $GHC$\bin and $GHC$\mingw\bin folder to the PATH, add env var "LANG=C". 4) Create file test.hs with contents: main = putStrLn "Hello, World!" 5) run "ghc test.hs". Interestingly, the error is not deterministic, ie, after running the command several times the program gets compiled. When that happens, and ff the file test.o is not deleted, further attempts to compile run succesfully. GHCi appears to work normally (when doing simple tests). More details: http://stackoverflow.com/questions/22291739/cant-install-packages-with- cabal-using-ghc-7-8rc2-and-windows-7 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8870> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #12575: Support US spelling of `specialise` throughout
by GHC 02 Oct '16

02 Oct '16

#12575: Support US spelling of `specialise` throughout -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC doesn't accept `-Wmissed-specializations`. Based on the [http://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts… #specialize-pragma docs], it seems like GHC is trying to support both spellings, so both spellings in the warning should be supported. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12575> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #12019: Profiling option -hb is not thread safe
by GHC 02 Oct '16

02 Oct '16

#12019: Profiling option -hb is not thread safe -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Runtime | Version: 8.1 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11978, #12009 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This ticket is a continuation of #11978 and #12009. After fixing a couple of issues in those two tickets I found that the profiling run time is not thread safe. Have a trivial test program (written as one of the tests for #11978): {{{ import Control.Concurrent import Control.Concurrent.MVar import Control.Exception import Control.Monad main :: IO () main = do putStrLn "Start ..." mvar <- newMVar (0 :: Int) let count = 50 forM_ [ 1 .. count ] $ const $ forkIO $ do threadDelay 100 i <- takeMVar mvar putMVar mvar $! i + 1 threadDelay 1000000 end <- takeMVar mvar putStrLn $ "Final result " ++ show end assert (end == count) $ return () }}} Compiling that with a compiler that has bug fixes arising from #11978 and #12009 as: {{{ inplace/bin/ghc-stage2 testsuite/tests/profiling/should_run/T11978b.hs \ -fforce-recomp -rtsopts -fno-warn-tabs -O -prof -static -auto-all \ -threaded -debug -o T11978b }}} and run as: {{{ ./T11978b +RTS -p -hb -N10 }}} crashes in a number of different ways. I've seen at least 3 different assertion failures and numerous segfaults (in different `stg_ap_*` functions). Replace `-hb` with other profiling options like `-hr` etc do not seem to crash. Looking at code, one example of lack of thread safetly is the function `LDV_recordDead` which mutates global variable `censuses` which does not have any locking around it. Only figured this out because the following assert (in `LDV_recordDead`) was being triggered occasionally. {{{ ASSERT(censuses[t].void_total < censuses[t].not_used); }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12019> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

Re: [GHC] #6018: Injective type families
by GHC 01 Oct '16

01 Oct '16

#6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.4.1 Resolution: fixed | Keywords: TypeFamilies, | Injective Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T6018, | T6018fail, T6018rnfail, T6018th, | T6018failclosed1, T6018failclosed2, | T6018ghci, T6018ghcifail, | T6018ghcirnfail Blocked By: | Blocking: Related Tickets: #4259, #10832, | Differential Rev(s): Phab:D202 #10833 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Use case of more complicated injectivity annotations from [http://www.diku.dk/~paba/pubs/files/serrano15haskell-paper.pdf Type Families with Class, Type Classes with Family], simulating the type class: {{{#!hs class Collection c e | c -> e where empty :: c add :: e -> c -> c }}} with a type family {{{#!hs data Defined = Yes | No type family IsCollection t e = (result :: Defined) | result t -> e }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:119> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3919: Or-patterns as GHC extension
by GHC 30 Sep '16

30 Sep '16

#3919: Or-patterns as GHC extension -------------------------------------+------------------------------------- Reporter: BjornEdstrom | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Good point. I think we may require parens around or patterns. So the parsing rule would be like: {{{ pat ::= '(' or-pattern-or-pat ')' | ... (where none of the productions accept '|') or-pattern-or-pat ::= pat '|' or-pattern-or-pat | pat }}} I personally dislike messier syntax like `:|` and `:|:`, because I'm hoping to use this syntax instead of `_` patterns, and I may need to chain a lot of constructors. {{{ f (T1 ...) = ... f (T2{} | T3{} | T4{}) = ... }}} vs {{{ f (T1 ...) = ... f (T2{} :|: T3{} :|: T4{}) = ... }}} Second one looks really bad IMHO. In addition, `:|:` is a valid operator syntax, but `|` is a reserved operator. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3919#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12645: 7.10.3 porting feedback
by GHC 30 Sep '16

30 Sep '16

#12645: 7.10.3 porting feedback -------------------------------------+------------------------------------- Reporter: jhpb | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.10.3 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: Installing GHC | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have to run GHC on older LINUX versions and this requires patches. I thought I would feed these back so they can be rolled into an official release. The particular release I build on is RHEL 3 and the changes have persisted over several years and are due to lack of "configure" tests for such an old LINUX I suppose. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12645> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #10740: Ensure that ticky, profiler, and GC allocation numbers agree
by GHC 30 Sep '16

30 Sep '16

#10740: Ensure that ticky, profiler, and GC allocation numbers agree -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: 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 Revisions: | -------------------------------------+------------------------------------- Currently we have several subsystems independently tracking allocations. It is very likely there are discrepancies between them. Ensuring that they agree would be a great way to test each of them (especially ticky, which is almost certainly bitrotted, see #10739). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10740> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12644: Lack of instantiation in GHC 8.0.1
by GHC 30 Sep '16

30 Sep '16

#12644: Lack of instantiation in GHC 8.0.1 -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- Consider {{{ data T a = T1 Int instance Show (T a) where show (T1 x) = show x t1 :: T a t1 = T1 1 f :: String f = show t1 }}} This should typecheck fine. The `a` in data type `T` is phantom, but we often use phantom types. But it isn't with GHC 8.0.1: {{{ • No instance for (Show (forall a. T a)) arising from a use of ‘show’ • In the expression: show t1 In an equation for ‘f’: f = show t1 }}} The problem is in the lack of instantation of `t1` in the argument of `show`. I'm fixing this, but I wanted to make a ticket to exhibit it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12644> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2