January 2018 - ghc-tickets

[GHC] #14182: Allow full control over dyn lib names
by GHC 12 Jan '18

12 Jan '18

#14182: Allow full control over dyn lib names -------------------------------------+------------------------------------- Reporter: duncan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Package | Version: 8.2.1 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: -------------------------------------+------------------------------------- This is related to: * GHC ticket #11587 * Cabal issue https://github.com/haskell/cabal/issues/4263 * Cabal PR https://github.com/haskell/cabal/pull/4656 * Cabal PR https://github.com/haskell/cabal/pull/4426 Currently GHC hard codes the naming convention for shared/dynamic libraries. For example: For `hs-libraries: HScpu-0.1.2-b25995` in the package registration, on ELF GHC uses the name `libHScpu-0.1.2-b2599-ghc8.0.1.so` (and .dynlib on OSX). This naming convention is based on an old assumption that shared libraries would go in a shared `$libdir`, and that all that was needed to ensure uniqueness was the combination of the package id and ghc version. This assumption is very out of date now. Different install schemes are used by different packaging tools (nix style vs classic style) and sometimes we want shared lib dirs and sometimes not, and of course we all know now that a package id is not nearly enough to ensure file names are unique. The obvious solution is for GHC to stop making any unnecessary naming convention assumptions and allow specifying the full library name in the package registration information. We would of course keep the remaining necessary naming convention is the `lib` prefix and `.so`/`.dynlib`/`.dll` suffix, which is the same convention used by the system linker for `-lfoo` vs `libfoo.so`. **So specifically:** * Add a new `dynamic-hs-libraries` (to go along with `hs-libraries`) to the `ghc-pkg` registration information. This naming convention follows the existing `library-dirs` and `dynamic-library-dirs`. * When this field is used then these library names will by used for dynamic linking. For backward compatibility, when this field is not supplied then the existing `-ghc8.0.1` convention is used. While we are at it, we should do the same for the `extra-libraries` and add a `dynamic-extra-libraries`. Note that there is an existing `extra- ghci-libraries` which was added for a similar reason (though prior to ghci switching to dynamic libs by default) because in rare cases the dyn libs are just named differently from the static libs, or occasionally there are extra static vs dynamic libs. For example, `pkg-config` makes a clear distinction between static and dynamic libs (because dynamic libs only need direct deps whereas static needs the full transitive closure). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14182> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14659: assertions are turned off if -O2 comes after -fno-ignore-asserts
by GHC 10 Jan '18

10 Jan '18

#14659: assertions are turned off if -O2 comes after -fno-ignore-asserts -------------------------------------+------------------------------------- Reporter: mwotton | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- test.hs: {{{#!hs import Control.Exception main = assert False (return ()) }}} ➜ ~ rm test; rm test.o; stack ghc -- -fno-ignore-asserts -O2 test.hs; ./test && echo $? [1 of 1] Compiling Main ( test.hs, test.o ) Linking test ... 0 ➜ ~ rm test; rm test.o; stack ghc -- -O2 -fno-ignore-asserts test.hs; ./test && echo $? [1 of 1] Compiling Main ( test.hs, test.o ) Linking test ... test: Assertion failed CallStack (from HasCallStack): assert, called at test.hs:3:8 in main:Main ``` tested with ghc 8.0.2 and 8.2.2. would have expected -fno-ignore-asserts to override -O2, no matter where it is in the options list. https://twitter.com/AlecMuffett/status/950699975767482370 shows how dangerous this could be. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14659> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14657: Quadratic constructor tag allocation
by GHC 10 Jan '18

10 Jan '18

#14657: Quadratic constructor tag allocation -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: genManyConstructors | Blocking: | Related Tickets: Differential Rev(s): phab:D4289 | Wiki Page: -------------------------------------+------------------------------------- With a large data type like: {{{ data A = A0 | A0001 | A0002 ... | A9999 }}} GHC spends a lot of time allocating constructor tags. It accounts for half of allocations for large data types like this. The hot piece of code is in `mkDataCon`: {{{ tag = assoc "mkDataCon" (tyConDataCons rep_tycon `zip` [fIRST_TAG..]) con }}} Previous discussion: https://mail.haskell.org/pipermail/ghc-devs/2017-October/014974.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14657> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14378: Unreasonably high memory use when compiling with profiling and -O2/-O2
by GHC 09 Jan '18

09 Jan '18

#14378: Unreasonably high memory use when compiling with profiling and -O2/-O2 -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Based on [https://github.com/Daniel-Diaz/matrix/issues/43] I tried that myself. * Without profiling: <10 sec, <110M Residency * Profiling and -O: 90sec, 1.5GB Residency * Profiling and -O2: Killed it after 4 Minutes and it started swapping on a 16GB Ram machine. The invocation was: ghc Matrix.hs -prof -fprof-auto -c -fforce-recomp -O -v -fprof-auto-exported -caf-all -auto-all -fstatic-argument- transformation Numbers above from 8.0.2. 8.2.1 improved to slightly worse than -O1 with ~95 sec and ~2.5GB ram usage. Still seems like a bug though. I haven't tried HEAD yet. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14378> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14649: ghc panic: mergeSATInfo
by GHC 09 Jan '18

09 Jan '18

#14649: ghc panic: mergeSATInfo -------------------------------------+------------------------------------- Reporter: tianxiaogu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- ghc panic with option `-O` and `-fstatic-argument-transformation`. Affected versions include 8.2.2 and HEAD (8.5.20180108) {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE PartialTypeSignatures #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} module T12844 where barWraper :: ('(r,r') ~ Head rngs, Foo rngs) => FooData rngs barWraper = bar bar :: (_) => FooData rngs bar = barWraper data FooData rngs class Foo xs where foo :: (Head xs ~ '(r,r')) => FooData xs type family Head (xs :: [k]) where Head (x ': xs) = x }}} Log: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.5.20180108 for x86_64-unknown-linux): mergeSATInfo Left:STSTSTSTSTSVSV, Right:STSTSTSTSTSVSC Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/simplCore/SAT.hs:152:20 in ghc:SAT Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14649> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14647: Invalid C in the via-C backend due to EFF_
by GHC 09 Jan '18

09 Jan '18

#14647: Invalid C in the via-C backend due to EFF_ -------------------------------------+------------------------------------- Reporter: | Owner: (none) ElvishJerricco | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #8965 #11395 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ // Stg.h #define EFF_(f) void f() /* See Note [External function prototypes] */ }}} Whenever Cmm uses a foreign C symbol, the generated C will declare the symbol with `EFF_`. Later, it will cast it to the appropriate type before calling it, often casting it to `void *` beforehand. `EFF_` is used in case the symbol is needed multiple times at incompatible types. This is invalid and discouraged in standard C for a number of reasons. - Even with incomplete args lists, it is invalid to declare a function with an inaccurate return type. - Incomplete args lists is considered "an obsolescent feature" of C. - It is invalid to call a function declared with an incomplete args list at multiple incompatible types. - It is invalid to cast a function to `void *`, as function pointers can technically have different width than regular pointers. This one obviously doesn't matter very much. - Using incomplete args lists to declare a function implemented with varargs is invalid, though this isn't really solvable for `foreign import ccall` without requiring the user to annotate such imports as varargs functions. On all the platforms GHC currently supports, this happens to work out fine. The C ABI on most platforms makes all of this compatible. But I've been working on making GHC target WebAssembly with via-C, and WebAssembly does not currently support this. Although it is [https://bugs.llvm.org/show_bug.cgi?id=35385 an LLVM bug] that incomplete args lists are unsupported on WebAssembly, it's fair-game that the inaccurate return type and liberal casting is broken. The fix is to declare externs with the proper types. We shouldn't use top level extern declarations in case the same symbol needs to be declared with multiple incompatible types (though frankly, I can't think of a good reason for this to occur, aside from varargs symbols, which is already invalid). We can use local externs to avoid the type incompatibilities. {{{ void foo() { extern int bar(int, int); ... } }}} The difficulty here is that Cmm doesn't carry the information necessary to make such declarations. {{{ module Test where foreign import ccall unsafe "testCSymbol" testHaskellSymbol :: Int -> Int -> Int -> Int }}} {{{ ghc -c Test.hs -o Test.o -ddump-cmm-raw }}} {{{ ... _s17E::I64 = I64[_s17D::P64 + 7]; _c188::I64 = testCSymbol; _c189::I64 = _s17A::I64; _c18a::I64 = _s17C::I64; _c18b::I64 = _s17E::I64; (_s17I::I64) = call "ccall" arg hints: [‘signed’, ‘signed’, ‘signed’] result hints: [‘signed’] (_c188::I64)(_c189::I64, _c18a::I64, _c18b::I64); ... }}} Cmm does not make any forward declaration of `testCSymbol`. It just uses the name ad-hoc, assigning it to the `c188` variable, eventually calling that variable at the proper type. This makes it nontrival to infer `testCSymbol`'s type (probably undecidable, considering anything can theoretically happen to these variables). It seems to me that Cmm needs to outlaw implicit declarations of foreign C symbols, `EFF_` needs to be removed, and there needs to be a local extern declaration syntax in Cmm. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14647> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14651: recompilation checker overeager on executables produced with -o
by GHC 09 Jan '18

09 Jan '18

#14651: recompilation checker overeager on executables produced with -o -------------------------------------+------------------------------------- Reporter: gershomb | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- {{{ -- Foo.hs module Main where main :: IO () main = putStrLn "foo" }}} {{{ -- Bar.hs module Main where main :: IO () main = putStrLn "bar" }}} {{{ ghc --make Foo.hs -o hello ghc --make Bar.hs -o hello }}} The first runthough this is fine. Any subsequent invocation of either of the above commands won't create a new executable again, even if the existing one is for "foo" and the command is invoked with "bar" or vice- versa. My guess is it sees that the *.hi and *.o files are up to date and sees the mtime of the executable is chronologically subsequent, so doesn't account for the fact that the file being compiled to an executable could itself have been changed. I don't know how fixable this is without always recompiling the executable, which is of course to be avoided. #13829 seems like it might be the flip-side of the same coin, so maybe fixing one also lets us fix the other... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14651> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14641: GHC panics in incomplete program
by GHC 08 Jan '18

08 Jan '18

#14641: GHC panics in incomplete program -------------------------------------+------------------------------------- Reporter: mmc | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I misspell a variable and GHC panics. I have the following test1.hs file: {{{ foo :: Double -> Double -> Bool foo a b = c > b }}} Then I do ghc -c test1.hs and get: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] x_a1LD :: t_a1LC[tau:1] (CHoleCan: x)} }}} If I add a "main" method to my test.hs, I get the expected {{{ test1.hs:2:11: error: Variable not in scope: c :: Double }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14641> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14042: Data type with type family in return kind spuriously rejected
by GHC 07 Jan '18

07 Jan '18

#14042: Data type with type family in return kind spuriously rejected -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: TypeInType, | Operating System: Unknown/Multiple TypeFamilies | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This typechecks: {{{#!hs {-# LANGUAGE TypeInType #-} import Data.Kind type Id (a :: Type) = a data Foo :: Id Type }}} But changing the type synonym to a type family causes it to fail: {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} import Data.Kind type family Id (a :: Type) :: Type where Id a = a data Foo :: Id Type }}} {{{ $ ghci Foo.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Foo.hs, interpreted ) Foo.hs:9:1: error: • Kind signature on data type declaration has non-* return kind Id * • In the data declaration for ‘Foo’ | 9 | data Foo :: Id Type | ^^^^^^^^ }}} That error message is wrong, since `Id * = *`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14042> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #10245: panic in new integer switch logic with "out-of-range" literals
by GHC 07 Jan '18

07 Jan '18

#10245: panic in new integer switch logic with "out-of-range" literals -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.11 (CodeGen) | Operating System: Unknown/Multiple Keywords: | Type of failure: Compile-time Architecture: x86_64 | crash (amd64) | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Compiling this module {{{ module D (f) where f :: Int -> String f n = case n of 0x8000000000000000 -> "yes" _ -> "no" }}} crashes with the error {{{ [1 of 1] Compiling D ( /tmp/D.hs, /tmp/D.o ) ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.11.20150403 for x86_64-unknown-linux): Map.findMin: empty map has no minimal element }}} The constant does not have to be exactly `0x8000000000000000`, everything I tested from there up to `0xffffffffffffffff` yields the same crash. Also occurs with `Word` and negative literals. The bug seems to be tied to the target's word size somehow, though: a 64-bit compiler does not panic on `Int32` and `0x80000000`, but a 32-bit compiler does. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10245> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18