- ghc-tickets - Haskell.org

[GHC] #13172: scrutinee constant folding produces wrong answer when remapped values are out of bounds
by GHC 24 Jan '17

24 Jan '17

#13172: scrutinee constant folding produces wrong answer when remapped values are out of bounds -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- This program should output 2, but in 8.1 with `-O` enabled it outputs 3. The problem is with the way that scrutinee constant folding rewrites the case. {{{#!hs f :: Word -> Word f n = case n+1 of 0 -> 2 _ -> 3 {-# NOINLINE f #-} main = print (f (-1)) }}} Core with 8.1 and `-O`: {{{ f [InlPrag=NOINLINE] :: Word -> Word [GblId, Arity=1, Caf=NoCafRefs, Str=<S(S),1*U(1*U)>m] f = \ (n_ay2 :: Word) -> case n_ay2 of { GHC.Types.W# x#_a1SL -> case x#_a1SL of { __DEFAULT -> lvl_r4lD; -1## -> lvl1_r4mD } } }}} Apparently `-1##` isn't okay: it needs to be `9223372036854775807##`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13172> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13170: Core Lint error on git HEAD
by GHC 24 Jan '17

24 Jan '17

#13170: Core Lint error on git HEAD -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- GHC HEAD hits a Core Lint error on this simple module: {{{#!hs module Fold where f :: Int -> Bool f x = y == 2 || y == 3 where y = -x }}} when compiling with `-O -dcore-lint`. This causes the Harbormaster build to fail on ia32. This doesn't effect 8.0.2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13170> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13176: Deprecate the realWorld#
by GHC 24 Jan '17

24 Jan '17

#13176: Deprecate the realWorld# -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- There's some about that's intended to prevent problems with the real world. What if we deprecate `realWorld#`? People will still be able to shoot themselves in the foot by ''defining'' `realWorld#` in terms of `runRW#`, but a warning in the documentation should hopefully be sufficient to prevent that. Another, considerably more invasive, option might be to use something like {{{#!hs runST# :: (forall s . State# s -> o) -> o data RealWorld :: * -> * runIO# :: (forall i . State# (RealWorld i) -> o) -> o }}} This would (I believe) provide a much stronger guarantee that the real world can't escape. But it would probably break considerably more code, so I doubt it would be worth the trouble. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13176> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13169: Documentation for CoreMonad.getAnnotations
by GHC 24 Jan '17

24 Jan '17

#13169: Documentation for CoreMonad.getAnnotations -------------------------------------+------------------------------------- Reporter: abakst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | 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: -------------------------------------+------------------------------------- The documentation for `getAnnotations` in `CoreMonad` is a bit unclear. In particular, the documentation could be improved by indicating that the returned `UniqFM` is keyed off of the `Unique` corresponding to an `AnnTarget`: That is, to look up the annotations on `x`, it seems one should call `getAnnotations` on either `ModuleTarget x` or `NamedTarget x` (if my understanding of how this all works is correct, that is). I stumbled across this by trying to look up the annotations on module `m` using the key `getUnique m`. This was incorrect as the annotation is stored on a unique *derived* from `getUnique m` (which wasn't indicated in the documentation). Thanks! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13169> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4960: Better inlining test in CoreUnfold
by GHC 24 Jan '17

24 Jan '17

#4960: Better inlining test in CoreUnfold -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.0.1 Resolution: | Keywords: newcomer, | Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alexbiehl): I don't know if this is that well defined. I have tried to implement this. Please take a look at https://github.com/alexbiehl/ghc/commit/fd9608ea93fc2389907b82c3fe540805d98…. Is this what you were talking about @simonpj? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4960#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12663: amazonka-ec2 fails to build with --split-objs
by GHC 24 Jan '17

24 Jan '17

#12663: amazonka-ec2 fails to build with --split-objs -------------------------------------+------------------------------------- Reporter: joehillen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've created a repo for reproducing this bug: https://github.com/joehillen/ec2-split-objs-bug The bug can appear as either: {{{ [189 of 207] Compiling Network.AWS.EC2.Waiters ( gen/Network/AWS/EC2/Waiters.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Network/AWS/EC2/Waiters.o ) [190 of 207] Compiling Network.AWS.EC2.DeleteVPNConnection ( gen/Network/AWS/EC2/DeleteVPNConnection.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Network/AWS/EC2/DeleteVPNConnection.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): tyThingTyCon Identifier ‘$fFoldableFirst_$cfold’ Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} or {{{ [189 of 207] Compiling Network.AWS.EC2.Waiters ( gen/Network/AWS/EC2/Waiters.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Network/AWS/EC2/Waiters.o ) [190 of 207] Compiling Network.AWS.EC2.DeleteVPNConnection ( gen/Network/AWS/EC2/DeleteVPNConnection.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Network/AWS/EC2/DeleteVPNConnection.o ) /tmp/stack11/amazonka- ec2-1.4.3/gen/Network/AWS/EC2/DeleteVPNConnection.hs:51:25: error: • Couldn't match expected type ‘Either a0 a10’ with actual type ‘a1 -> ShowS’ • Probable cause: ‘showsPrec’ is applied to too few arguments In the first argument of ‘GHC.Show.showList__’, namely ‘(showsPrec 0)’ In the expression: GHC.Show.showList__ (showsPrec 0) In an equation for ‘showList’: showList = GHC.Show.showList__ (showsPrec 0) When typechecking the code for ‘showList’ in a derived instance for ‘Show DeleteVPNConnection’: To see the code I am typechecking, use -ddump-deriv /tmp/stack11/amazonka- ec2-1.4.3/gen/Network/AWS/EC2/DeleteVPNConnection.hs:104:23: error: • Couldn't match expected type ‘Either a2 a3’ with actual type ‘a4 -> ShowS’ • Probable cause: ‘showsPrec’ is applied to too few arguments In the first argument of ‘GHC.Show.showList__’, namely ‘(showsPrec 0)’ In the expression: GHC.Show.showList__ (showsPrec 0) In an equation for ‘showList’: showList = GHC.Show.showList__ (showsPrec 0) When typechecking the code for ‘showList’ in a derived instance for ‘Show DeleteVPNConnectionResponse’: To see the code I am typechecking, use -ddump-deriv }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12663> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13018: TH-spliced pattern synonym declaration fails to typecheck
by GHC 23 Jan '17

23 Jan '17

#13018: TH-spliced pattern synonym declaration fails to typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.1 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: -------------------------------------+------------------------------------- This pattern synonyms typechecks without issue: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE PatternSynonyms #-} module Works where data T a where MkT :: Eq b => b -> T a pattern P :: b -> T a pattern P x <- MkT x }}} But if you try to create `P` from a Template Haskell splice, it will fail to typecheck: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE TemplateHaskell #-} module Bug where data T a where MkT :: Eq b => b -> T a $([d| pattern P :: b -> T a; pattern P x <- MkT x |]) }}} {{{ $ /opt/ghc/head/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:9:3: error: • Couldn't match expected type ‘b0’ with actual type ‘b’ ‘b’ is a rigid type variable bound by a pattern with constructor: MkT :: forall a b. Eq b => b -> T a, in a pattern synonym declaration at Bug.hs:9:3-52 ‘b0’ is a rigid type variable bound by the signature for pattern synonym ‘P’ at Bug.hs:9:3-52 • In the declaration for pattern synonym ‘P’ • Relevant bindings include x_a4tP :: b (bound at Bug.hs:9:3) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13018> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #13142: GHC emits enormous core starting with 'Arity decrease'
by GHC 23 Jan '17

23 Jan '17

#13142: GHC emits enormous core starting with 'Arity decrease' ----------------------------------------+--------------------------------- Reporter: jeiea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- I discovered this when building [https://github.com/commercialhaskell/stack/commit/f117ffb034658e3e1c3fea2a8… stack] by stack on windows 10. I want to find problem area, but I can't even catch a clue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13142> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

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

23 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] #13124: Template Haskell: Floating point literals that cannot be represented by rationals
by GHC 23 Jan '17

23 Jan '17

#13124: Template Haskell: Floating point literals that cannot be represented by rationals -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1 Haskell | 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: -------------------------------------+------------------------------------- Currently, TH expressions and patterns store Float/Double values as rationals: http://hackage.haskell.org/package/template- haskell-2.11.1.0/docs/Language-Haskell-TH-Syntax.html#t:Lit Unfortunately, this isn't sufficient, as there is no way to properly support usual floating point values such as NaN, Infinity, and Negative- Zero. This is true for both expressions and patterns. It would be nice if Double/Float literals were stored as double-floats themselves, instead of rationals. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13124> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5