February 2016 - ghc-tickets

[GHC] #11568: Regression in nofib/shootout/k-nucleotide
by GHC 01 Feb '17

01 Feb '17

#11568: Regression in nofib/shootout/k-nucleotide -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 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: -------------------------------------+------------------------------------- Fixing the `sizeExpr` bug in #11564 caused a regression in `nofib/shootout/k-nucleotide`. We don't know yet exactly which function was affected. See Phab:D1900 for details and some `-ddump-simpl` and `-ticky` dumps. We should investigate this before merging Phab:D1900 into a release. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11568> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #10052: Panic (something to do with floatExpr?)
by GHC 31 Jan '17

31 Jan '17

#10052: Panic (something to do with floatExpr?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Loading {{{ main = let (x :: String) = "hello" in putStrLn x }}} using a very simple driver for the GHC API (see T145.hs) causes a ghc panic: {{{ [1 of 1] Compiling Main ( T145-input.hs, interpreted ) T145: T145: panic! (the 'impossible' happened) (GHC version 7.10.0.20150128 for x86_64-apple-darwin): floatExpr tick <<details unavailable>> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This panic is arising in our test case for #8333, so it may be related to that bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10052> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #11444: 8.0 rc1 panics in applyTypeToArgs
by GHC 31 Jan '17

31 Jan '17

#11444: 8.0 rc1 panics in applyTypeToArgs -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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: -------------------------------------+------------------------------------- To reproduce, clone https://github.com/rrnewton/haskell-lockfree and switch to ghc-8.0 branch. Then run {{{cabal install atomic-primops/}}} (note the trailing slash, we don't want to install it from Hackage). It should fail with a message like this: {{{ ➜ haskell-lockfree git:(ghc-8.0) ✗ cabal install atomic-primops/ Warning: The package list for 'hackage.haskell.org' is 25.1 days old. Run 'cabal update' to get the latest list of available packages. Resolving dependencies... Notice: installing into a sandbox located at /home/omer/haskell/haskell-lockfree/.cabal-sandbox Configuring primitive-0.6.1.0... Building primitive-0.6.1.0... Warning: /tmp/pkgConf-primitive-0.6.110252023621350490027.0: Unrecognized field abi on line 21 Installed primitive-0.6.1.0 Configuring atomic-primops-0.8.0.2... Building atomic-primops-0.8.0.2... Failed to install atomic-primops-0.8.0.2 Build log ( /home/omer/haskell/haskell-lockfree/.cabal-sandbox/logs /atomic-primops-0.8.0.2.log ): [1 of 1] Compiling Main ( atomic-primops/dist/dist-sandbox- ad71ba7e/setup/setup.hs, atomic-primops/dist/dist-sandbox- ad71ba7e/setup/Main.o ) Linking atomic-primops/dist/dist-sandbox-ad71ba7e/setup/setup ... Configuring atomic-primops-0.8.0.2... Building atomic-primops-0.8.0.2... Preprocessing library atomic-primops-0.8.0.2... [1 of 3] Compiling Data.Atomics.Internal ( Data/Atomics/Internal.hs, dist /dist-sandbox-ad71ba7e/build/Data/Atomics/Internal.o ) Data/Atomics/Internal.hs:69:20: warning: Defined but not used: data constructor ‘Ticket’ [2 of 3] Compiling Data.Atomics.Counter ( Data/Atomics/Counter.hs, dist /dist-sandbox-ad71ba7e/build/Data/Atomics/Counter.o ) [3 of 3] Compiling Data.Atomics ( Data/Atomics.hs, dist/dist-sandbox- ad71ba7e/build/Data/Atomics.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.0.20160111 for x86_64-unknown-linux): applyTypeToArgs Expression: readMutVar# eta_s4sC st_s4sD Type: forall d_15 a_12. MutVar# d_15 a_12 -> State# d_15 -> (# State# d_15, a_12 #) Args: [eta_s4sC, st_s4sD] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug cabal: Error: some packages failed to install: atomic-primops-0.8.0.2 failed during the building phase. The exception was: ExitFailure 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11444> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #11046: lookupTypeName does not support type operators
by GHC 30 Jan '17

30 Jan '17

#11046: lookupTypeName does not support type operators -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.10.2 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following non-working code (minus a missing import) was [http://stackoverflow.com/questions/33465109/template-haskell-how-to- lookup-type-operator-name posted on stackoverflow]: `IssueTH.hs`: {{{#!hs {-# LANGUAGE TemplateHaskell #-} module IssueTH where import Language.Haskell.TH f :: Q [Dec] f = do Just n <- lookupTypeName "GHC.TypeLits.*" return [] }}} `Issue.hs`: {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Issue where import IssueTH import GHC.TypeLits $f }}} `ghc Issue.hs` fails with message: `Pattern match failure in do expression at IssueTH.hs:7:5-10` This gives no error if `*` is replaced by an alphanumeric type like `Nat`. Similar tests seem to fail whenever attempting to look up a type operator with `lookupTypeName`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11046> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #10420: "Care with plugin imports" is wrong / orphan RULE visibility
by GHC 29 Jan '17

29 Jan '17

#10420: "Care with plugin imports" is wrong / orphan RULE visibility -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- A module loaded by a plugin poisons the module cache, so we never load an orphan RULE or instance even if we legitimately should do so. The way to test this is a bit convoluted, but it goes something like this: plugins07.hs {{{ module Main where import Plugins07a import RuleDefiningPlugin {-# NOINLINE x #-} x = "foo" main = putStrLn (show x) }}} Plugins07a.hs {{{ --{-# OPTIONS_GHC -fplugin RuleDefiningPlugin #-} module Plugins07a where }}} RuleDefiningPlugin.hs, in ANOTHER PACKAGE (otherwise, EPT rules don't apply) {{{ module RuleDefiningPlugin where import GhcPlugins {-# RULES "unsound" forall x. show x = "SHOWED" #-} plugin :: Plugin plugin = defaultPlugin }}} I'll commit the full test. Here's what happens: * Building `Plugins07a` results in `loadPluginInterface` on `RuleDefiningPlugin`. We load the `ModIface` but only add its types to the environment because of the "Care with plugin imports" special case. * Building `plugins07.hs` results in a normal source level import for `RuleDefiningPlugin`, but `ModIface` is already in the cache so we don't load anything. RULE is not loaded, disaster! Admittedly, actually triggering this bug requires a convoluted chain of events. But really this problem arose because the "Care with plugin imports" fix is just completely nonsense. Here's what we should do: * We should apply the same fix from #2182 on orphan instances to orphan rules too. This way, we can safely load RULEs into the EPS without accidentally bringing them into scope when they shouldn't be. * Loading an interface should unconditionally suck in the instances and rules. The result is more correct and simpler, so it seems worth fixing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10420> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #9351: add ability to version symbols .c for packages with C code
by GHC 26 Jan '17

26 Jan '17

#9351: add ability to version symbols .c for packages with C code -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: backpack | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Let's consider an example: We have a haskell package with some C code imported in haskell: {{{ // a.h file int get_something(void); // a.c file #include "a.h" int get_something(void) { return 42; } // M.hs file module M where foreign import ccall "a.h get_something" :: IO Int }}} The problem here is we can't mix that package with other packages having global 'get_something' symbol. Sometimes it happens when a package copies part of implementation from another package with .c bits under different haskell namespace. Haskell parts would coexist freely, but not C symbols. Would be great if ghc would export some unique package identifier in a way C code could attach it to all exported symbols making linking possible. Something like that: {{{ // a.h file #include "HsFFI.h" /* #define FOR_HASKELL(__sym) package_id_##__sym */ int FOR_HASKELL(get_something)(void); // a.c file #include "a.h" int FOR_HASKELL(get_something)(void) { return 42; } // M.hs file module M where foreign import ccall-for-haskell "a.h get_something" :: IO Int }}} That way we explicitly mark symbol as inaccessible to external plain C code. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9351> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8901: (very) bad inline heuristics
by GHC 25 Jan '17

25 Jan '17

#8901: (very) bad inline heuristics ------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I observe a bad case for inlining blowup for the time library. Observed for 7.7, just checked in 7.9. The problem is so bad that the PowerPC32 assembler cannot resolve cross- routine references. (I have no error message at hand, but could try to get one.) Instead here are the stats for x86, with inlining and certain inlining suppressed. The architecture seems irrelevant. {{{ $ file ./libraries/time/dist-install/build/Data/Time/Format.o ./libraries/time/dist-install/build/Data/Time/Format.o: Mach-O object i386 $ ls -l ./libraries/time/dist-install/build/Data/Time/Format.* -rw-r--r-- 1 ggreif staff 61875 Mar 15 16:48 ./libraries/time/dist- install/build/Data/Time/Format.dyn_hi -rw-r--r-- 1 ggreif staff 450864 Mar 15 16:48 ./libraries/time/dist- install/build/Data/Time/Format.dyn_o -rw-r--r-- 1 ggreif staff 61863 Mar 15 16:48 ./libraries/time/dist- install/build/Data/Time/Format.hi -rw-r--r-- 1 ggreif staff 332216 Mar 15 16:48 ./libraries/time/dist- install/build/Data/Time/Format.o }}} With following patch applied: <https://github.com/ggreif/packages- time/commit/83f08b8896b950707a910fed4e30bddb7ee7f52f> I get: {{{ $ ls -l ./libraries/time/dist-install/build/Data/Time/Format.* -rw-r--r-- 1 ggreif staff 10554 Mar 16 00:08 ./libraries/time/dist- install/build/Data/Time/Format.dyn_hi -rw-r--r-- 1 ggreif staff 106832 Mar 16 00:08 ./libraries/time/dist- install/build/Data/Time/Format.dyn_o -rw-r--r-- 1 ggreif staff 10542 Mar 16 00:08 ./libraries/time/dist- install/build/Data/Time/Format.hi -rw-r--r-- 1 ggreif staff 78864 Mar 16 00:08 ./libraries/time/dist- install/build/Data/Time/Format.o }}} The factor is 4.2 for Format.o, Format.dyn_o and 5.8 for the .hi files. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8901> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #8156: amd64 + in-tree gmp build broken
by GHC 22 Jan '17

22 Jan '17

#8156: amd64 + in-tree gmp build broken -------------------------------------+------------------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: Building GHC Difficulty: Easy (less than 1 | failed hour) | Test Case: Blocked By: | Blocking: Related Tickets: #4022 #4366 #4374 | -------------------------------------+------------------------------------- Currently, the GHC build system has an in-tree GMP. This GMP seems to be used only if there is no usable GMP found on the system and the user didn't provide one using configure flags. When we build GHC using an external shared version of GMP, the resulting GHC is dynamically linked against GMP and also the generated programs are linked dynamically against GMP. When the in-tree GMP is used, it is built statically, even if the GHC we are building is shared GHC on GNU/Linux. This feature is currently broken on amd64 (#4366, #4022), but is working currently very well on Linux i686. Apart from the breakage this setting is very flexible and I'd be very happy if it were possible to keep it, in spite of removeal requests like #4374. When there is a system GMP, nothing would change, this is the most typical usage, e.g. distributions are all building this way. On the other hand, if the user removes his GMP (maybe we should provide an option to explicity trigger this in ./configure, instead of having to remove GMP); she can build a GHC that is not linked dynamically against GMP and the resulting programs are not linked either. This makes it possible to generate binaries that link dynamically against libc (no -static) which is quite compatible amongst versions, but doesn't require a libgmp.so to run. For binary deployments this seems to be the best kind of setup nowadays. Now, if we were only able to fix this for amd64. See this: https://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=3 On amd64 we can continue to compile GMP statically and link into the binary library, we just have to compile GMP with the fPIC. I attached the patch to fix this. Previously a similar patch has been rejected in #4022 because "this shouldn't be platform specific", but this is clearly not the case, this is specific to amd64. Tadaaaam: {{{ errge@sid64:~/ghc/inplace/bin$ cat test.hs main = print (2^100) errge@sid64:~/ghc/inplace/bin$ ./ghc-stage2 test.hs [1 of 1] Compiling Main ( test.hs, test.o ) Linking test ... errge@sid64:~/ghc/inplace/bin$ ./test 1267650600228229401496703205376 errge@sid64:~/ghc/inplace/bin$ ldd ./test linux-vdso.so.1 (0x00007fff79962000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe4b9a83000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fe4b987a000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe4b9676000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe4b92c6000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe4b90a6000) /lib64/ld-linux-x86-64.so.2 (0x00007fe4b9d83000) }}} No GMP! I attach the build file patch to the bugreport. So, can we please apply this patch and just keep the in-tree GMP? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8156> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #9223: Type equality makes type variable untouchable
by GHC 21 Jan '17

21 Jan '17

#9223: Type equality makes type variable untouchable -------------------------------------------+------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- This doesn't look right: {{{ {-# LANGUAGE RankNTypes, TypeFamilies #-} type family TF (m :: * -> *) run1 :: (forall m . Monad m => m a) -> a run1 = undefined run2 :: (forall m . (Monad m, TF m ~ ()) => m a) -> a run2 = undefined -- this works x1 = run1 (return ()) -- this fails x2 = run2 (return ()) {- Couldn't match expected type ‘a’ with actual type ‘()’ ‘a’ is untouchable inside the constraints (Monad m, TF m ~ ()) bound by a type expected by the context: (Monad m, TF m ~ ()) => m a at untouchable.hs:15:6-21 ‘a’ is a rigid type variable bound by the inferred type of x2 :: a at untouchable.hs:15:1 Relevant bindings include x2 :: a (bound at untouchable.hs:15:1) In the first argument of ‘return’, namely ‘()’ In the first argument of ‘run2’, namely ‘(return ())’ -} }}} I would expect x2 to type check just like x1 does. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9223> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #10515: ghc: panic: tyThingTyCon Identifier ‘$fStencil:.a(,,,,)7’
by GHC 20 Jan '17

20 Jan '17

#10515: ghc: panic: tyThingTyCon Identifier ‘$fStencil:.a(,,,,)7’ -------------------------------------+------------------------------------- Reporter: yongqli | 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: | -------------------------------------+------------------------------------- Has anyone seen something like this? {{{ <no location info>: ghc: panic! (the 'impossible' happened) (GHC version 7.10.1.20150519 for x86_64-unknown-linux): tyThingTyCon Identifier ‘$fStencil:.a(,,,,)7’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10515> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4