- ghc-tickets - Haskell.org

Re: [GHC] #7428: GHC compile times are seriously non-linear in program size
by GHC 09 Jun '15

09 Jun '15

#7428: GHC compile times are seriously non-linear in program size -------------------------------------+------------------------------------- Reporter: nudded | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thoughtpolice): Here's a smaller version (that actually completes in a reasonable amount of time), along with a profile. Something is definitely quadratic or something around `CorePrep`/`TidyCore`; when run with `-v3`, I estimate `CorePrep` alone takes about 20 seconds. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7428#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7428: GHC compile times are seriously non-linear in program size
by GHC 09 Jun '15

09 Jun '15

#7428: GHC compile times are seriously non-linear in program size -------------------------------------+------------------------------------- Reporter: nudded | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thoughtpolice): I've updated the test case. By default, even on my monster build machine, it looks like the compilation of this test is literally never going to finish, so it needs to be toned down to look at it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7428#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10441: msys native python testsuite support doesn't work in some situations
by GHC 09 Jun '15

09 Jun '15

#10441: msys native python testsuite support doesn't work in some situations -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Test Suite | Version: 7.11 Keywords: | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- On a vanilla Windows 8.1, msys2 GHC installation with only msys python installed, the testsuite driver is broken. I know of one other person whose testsuite is also not working. The usual error message is: {{{ cd ./typecheck/should_compile && "C:/msys64/home/ezy.exe" -c tc055.hs -fforce-recomp -dcore-lint -dcmm-lib -rtsopts -fno-warn-tabs -fno-ghci- history -fno-warnrr 2>&1 '..\timeout\install-inplace\bin\timeout.exe" "300" "cexternal command, operable program or batch file. Compile failed (status 256) errors were: }}} I have diagnosed the problem to the fact that we are passing a complex command string to cmd with adequately quoting it. In particular, when I inspect the command line that Python is attempting to invoke, it looks something like this: {{{ cmd \c 'timeout.exe 300 "cd . && "inplace/ghc-stage2" -c blah blah"' }}} Notice, in particular, that the quoted GHC executable was not inside the timeout invocation is not double-quoted, so cmd does NOT parse the command the way you want it to. Curiously enough, when I remove this fix (introduced by commit `101c62e26286353dd3fac1ef54323529b64c9902`), the msys Python runner works fine. So I don't even know what this commit was intended to fix; it seems to have done more harm than good Here are some details about my configuration: {{{ ezyang@cutlass MSYS ~/ghc-validate/testsuite $ python2 --version Python 2.7.9 ezyang@cutlass MSYS ~/ghc-validate/testsuite $ bash --version GNU bash, version 4.3.33(3)-release (x86_64-pc-msys) Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10441> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #9626: Test command lines munged on Windows when running on msys Python
by GHC 09 Jun '15

09 Jun '15

#9626: Test command lines munged on Windows when running on msys Python -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.9 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Building Difficulty: Unknown | GHC failed Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- On Windows, the test runner works fine if run under Windows-native Python, but fails with the msys Python because of the heuristic transformations that msys applies to all binary invocations of non-msys binaries (such as timeout.exe) by msys binaries (such as python). This is relatively easy to sidestep by going through /usr/bin/cmd in msys which sidesteps the argument munging. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9626> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10501: Exception in :cmd command can terminate GHCi
by GHC 09 Jun '15

09 Jun '15

#10501: Exception in :cmd command can terminate GHCi ----------------------------------+------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: GHCi | Version: 7.10.1 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------+------------------------------- {{{ watashi % ghci -ignore-dot-ghci GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help Prelude> :cmd return $ head [] ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for i386-unknown-linux): Prelude.head: empty list Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10501> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10488: Inconsistent reduction of type family
by GHC 09 Jun '15

09 Jun '15

#10488: Inconsistent reduction of type family -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Consider this module: {{{ {-# LANGUAGE TemplateHaskell, TypeFamilies, GADTs, PolyKinds, DataKinds, ScopedTypeVariables, TypeOperators, UndecidableInstances #-} module SingBug where import Data.Singletons.TH $(promote [d| data Nat = Zero | Succ Nat deriving (Eq, Ord) |]) foo :: Proxy (Zero :< Succ Zero) foo = (Proxy :: Proxy True) }}} It fails to compile, with this: {{{ SingBug.hs:14:8: Couldn't match type ‘'False’ with ‘'True’ Expected type: Proxy ('Zero :< 'Succ 'Zero) Actual type: Proxy 'True In the expression: (Proxy :: Proxy True) In an equation for ‘foo’: foo = (Proxy :: Proxy True) }}} However, if I remove the last two lines, it compiles fine. Witness this bizarre interaction: {{{ Prelude> :load "SingBug.hs" [1 of 1] Compiling SingBug ( SingBug.hs, interpreted ) Ok, modules loaded: SingBug. *SingBug> :kind! Zero :< Succ Zero Zero :< Succ Zero :: Bool = TrueSym0 *SingBug> :i TrueSym0 type TrueSym0 = 'True -- Defined in ‘singletons-1.2:Data.Singletons.Prelude.Instances’ *SingBug> :kind! (Proxy (Zero :< Succ Zero)) (Proxy (Zero :< Succ Zero)) :: * = Proxy TrueSym0 *SingBug> :t (Proxy :: Proxy (Zero :< Succ Zero)) (Proxy :: Proxy (Zero :< Succ Zero)) :: Proxy ('Zero :< 'Succ 'Zero) *SingBug> :t (Proxy :: Proxy (Zero :< Succ Zero)) :: Proxy True <interactive>:1:2: Couldn't match type ‘'False’ with ‘'True’ Expected type: Proxy 'True Actual type: Proxy ('Zero :< 'Succ 'Zero) In the expression: (Proxy :: Proxy (Zero :< Succ Zero)) :: Proxy True *SingBug> :t (Proxy :: Proxy (Zero :< Succ Zero)) :: Proxy False (Proxy :: Proxy (Zero :< Succ Zero)) :: Proxy False :: Proxy 'False }}} It seems GHC can't decide if 0 is less than 1! When I ask it to use `:kind!`, it does the right thing. But if it's reducing a type during type-checking, it does very much the '''wrong''' thing. This is a regression compared to 7.8. I've been unable to minimize the test case or remove the `singletons` dependency, sadly. When I try to mimic the behavior of singletons without TH, it all works as expected. But I've found the problem. The apartness check for closed type families is very subtly broken, and I believe you can break the type system exploiting this bug. I can't quite tickle it directly though. Fix on the way in the next day. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10488> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10442: Loading of shared libraries is problematic in ghc 7.10.1
by GHC 09 Jun '15

09 Jun '15

#10442: Loading of shared libraries is problematic in ghc 7.10.1 -------------------------------------+------------------------------------- Reporter: | Owner: artella.coding | Status: new Type: bug | Milestone: 7.10.2 Priority: high | Version: 7.10.1 Component: Compiler | Operating System: Linux Keywords: | Type of failure: Runtime crash Architecture: x86_64 | Blocked By: (amd64) | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Suppose that I have : {{{#!hs //test.h int add(int a, int b); }}} {{{#!hs //test.c int add(int a, int b){ return (a + b); } }}} {{{#!hs //mylib.c #include "test.h" int testAdd(){ return add(2,3); } }}} Then I compile via : {{{#!hs gcc -shared -o libtest.so test.c gcc -fPIC -c mylib.c -o mylib.o gcc -shared -o libMy.so mylib.o }}} Then I have Main.hs with : {{{#!hs module Main where import Foreign.C.Types foreign import ccall "testAdd" c_testAdd :: CInt -> CInt -> IO (CInt) main = do result <- c_testAdd 3 4 print result }}} and I have the associated cabal file : {{{#!hs name: illustrate version: 0.1.0.0 build-type: Simple cabal-version: >=1.10 executable illustrate main-is: Main.hs build-depends: base >=4.8 && <4.9 default-language: Haskell2010 extra-lib-dirs: ./ ghc-options: -ltest -lMy }}} Then upon running "cabal repl" I get the following error message (in ghc 7.10.1) : {{{#!hs *Main> main /home/linux/programs/ghc-7.10.1/lib/ghc-7.10.1/bin/ghc: symbol lookup error: ./libMy.so: undefined symbol: add }}} If I do "cabal run" I get : {{{#!hs Preprocessing executable 'illustrate' for illustrate-0.1.0.0... [1 of 1] Compiling Main ( Main.hs, dist/build/illustrate /illustrate-tmp/Main.o ) Linking dist/build/illustrate/illustrate ... Running illustrate... /home/linux/Downloads/illustrate/dist/build/illustrate/illustrate: error while loading shared libraries: libtest.so: cannot open shared object file: No such file or directory }}} Note that in ghc 7.8.3, cabal 1.22.0.0 it works fine. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10442> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 08 Jun '15

08 Jun '15

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonmar): * owner: => niteria Comment: @niteria is going to look at this, with help from me. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:105> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9259: GHCi should list its available command line options
by GHC 08 Jun '15

08 Jun '15

#9259: GHCi should list its available command line options -------------------------------------------+------------------------------- Reporter: jstolarek | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Driver | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- GHC can now list its command line options with `--show-options` (#7843). GHCi should be able to do the same. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9259> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #10500: GHC runs out of memory building unicode-properties
by GHC 08 Jun '15

08 Jun '15

#10500: GHC runs out of memory building unicode-properties -------------------------------------+------------------------------------- Reporter: dsf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Building package https://hackage.haskell.org/package/unicode-properties uses extraordinary amounts of memory with recent compilers - it dies on my 16GB desktop, though the travis build does eventually complete (see it here: https://travis-ci.org/seereason/unicode-properties/builds/65815442.) I have imported the repo to github and untabified it here: https://github.com/seereason/unicode-properties. Building this package was somewhat slow but did complete under ghc-7.8.3. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10500> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3