January 2017 - ghc-tickets

[GHC] #11006: Warning: Glomming in Main
by GHC 07 Mar '17

07 Mar '17

#11006: Warning: Glomming in Main -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 Travis build bot is reporting a test failure with debugging on, relating to glomming: {{{ Actual stderr output differs from expected: --- /dev/null 2015-01-28 16:31:58.000000000 +0000 +++ ./lib/integer/integerConstantFolding.run.stderr.normalised 2015-10-22 20:31:03.287376925 +0000 @@ -0,0 +1,2 @@ +WARNING: file compiler/simplCore/OccurAnal.hs, line 66 + Glomming in Main: [s3k0 :->, s3kc :->, s3kq :->, s3kr :->] \ No newline at end of file *** unexpected failure for integerConstantFolding(normal) }}} Full log https://s3.amazonaws.com/archive.travis- ci.org/jobs/86899099/log.txt -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11006> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13130: atomicModifyMutVar# has incorrect type
by GHC 06 Mar '17

06 Mar '17

#13130: atomicModifyMutVar# has incorrect type -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | 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: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- this ticket specifically, currently we only expose in ghc-prim {{{ atomicModifyMutVar# :: MutVar# s a -> (a -> b) -> State# s -> (# State# s,c #) }}} is the type more like the following? {{{ atomicModifyMutVar# :: MutVar# s a -> (a -> (#a,b #)) -> State# s -> (# State# s,b #) }}} looking at GHC.IOREF {{{ atomicModifyIORef :: IORef a -> (a -> (a,b)) -> IO b atomicModifyIORef (IORef (STRef r#)) f = IO $ \s -> atomicModifyMutVar# r# f s }}} it seems that either way, something screwy is afoot i'm not sure where the spurious c type variable comes from -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13130> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13174: Fix mismatch between unsafeDupablePerformIO and note
by GHC 06 Mar '17

06 Mar '17

#13174: Fix mismatch between unsafeDupablePerformIO and note -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Core | Version: 8.1 Libraries | 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/libraries/base/GHC/IO/Unsafe.hs` contains the following note: {{{ -- Note [unsafeDupablePerformIO is NOINLINE] -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- Why do we NOINLINE unsafeDupablePerformIO? See the comment with -- GHC.ST.runST. Essentially the issue is that the IO computation -- inside unsafePerformIO must be atomic: it must either all run, or -- not at all. If we let the compiler see the application of the IO -- to realWorld#, it might float out part of the IO. }}} However, `unsafeDupablePerformIO` does not actually have a `NOINLINE` pragma. So either the note is out of date and should be removed/modified, or someone messed up the code. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13174> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11076: Demand information of foreign calls is wrong
by GHC 06 Mar '17

06 Mar '17

#11076: Demand information of foreign calls is wrong -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Foreign calls of all types (including prim calls) use `mkFCallId` to create a fresh `Id` for each one. This Id claims to be strict in all arguments, which is not correct for foreign calls that allow lifted types to be passed. This also causes some trouble for GHCJS. I hope to get a fix in 7.10.3. Can we leave the strictness sig out entirely perhaps? Most arguments would be trivially strict since they're unboxed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11076> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #13141: Don't check for Perl in ./configure when not splitting objects
by GHC 06 Mar '17

06 Mar '17

#13141: Don't check for Perl in ./configure when not splitting objects -------------------------------------+------------------------------------- Reporter: dobenour | Owner: dobenour Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- GHC needs Perl for exactly two reasons: - To run `boot` and the Autotools - For the splitter As such, there is no reason to check for Perl in `./configure` unless split-objs is supported. Even then, Perl is optional. The current check most likely comes from the days of the Evil Mangler. I'll take this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13141> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13027: Core lint errors compiling containers HEAD with GHC HEAD
by GHC 06 Mar '17

06 Mar '17

#13027: Core lint errors compiling containers HEAD with GHC HEAD -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Git HEAD of containers compiles fine with ghc-8.0.1, but when compiling with GHC git HEAD gives core lint errors: {{{ *** Core Lint errors : in result of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) *** <no location info>: warning: In the expression: tagToEnum# @ Bool (reallyUnsafePtrEquality# @ (Set a) l'_a4Fk l_a4Fi) This argument does not satisfy the let/app invariant: reallyUnsafePtrEquality# @ (Set a) l'_a4Fk l_a4Fi *** Offending Program *** Rec { $dTypeable_s9vn :: Proxy# Set -> TypeRep }}} This issue can be reproduced using: {{{ (cd libraries/containers ; git checkout master ; git pull) perl boot && ./configure && make clean && make -j }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13027> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 38

[GHC] #10830: maximumBy has a space leak
by GHC 04 Mar '17

04 Mar '17

#10830: maximumBy has a space leak -------------------------------------+------------------------------------- Reporter: | Owner: NeilMitchell | Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.2 libraries/base | Keywords: | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Given the program: {{{#!hs import Data.List main = print $ maximumBy compare [1..10000] }}} Compiling with {{{-O2}}}, on GHC 7.8.3 this runs in constant stack space (works fine with {{{+RTS -K1K}}}). With GHC 7.10.2 I get: {{{ $ ghc --make Test.hs -O2 -rtsopts [1 of 1] Compiling Main ( Test.hs, Test.o ) Linking Test.exe ... $ Test +RTS -K100K Stack space overflow: current size 33680 bytes. Use `+RTS -Ksize -RTS' to increase it. }}} Not sure why it's failing at 33K instead of 100K, but it's certainly taking more than 1K as GHC 7.8.3 did. See #3416 for previous discussion of this issue. My guess is that in older versions of GHC the strictness analysis managed to kick in and optimise things. With the burnt bridges that no longer works. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10830> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 33

[GHC] #11421: adding a PartialTypeSignatures to a binding affected by MonoLocalBinds leads compile-time failure
by GHC 03 Mar '17

03 Mar '17

#11421: adding a PartialTypeSignatures to a binding affected by MonoLocalBinds leads compile-time failure -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- See attached file. I think both type signatures for xs should work. The ghci error unfortunately doesn't show up on :reload, but it shows up when trying to run an unrelated function (main here). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11421> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12441: Conflicting definitions error does not print explicit quantifiers when necessary
by GHC 03 Mar '17

03 Mar '17

#12441: Conflicting definitions error does not print explicit quantifiers when necessary -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | 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: -------------------------------------+------------------------------------- {{{ -- Y.hs-boot {-# LANGUAGE ScopedTypeVariables #-} module Y where f :: forall a b. (a, b) -- YY.hs module YY where import {-# SOURCE #-} Y -- Y.hs {-# LANGUAGE ScopedTypeVariables #-} module Y where import YY f :: forall b a. (a, b) f = undefined }}} I get the following unhelpful error: {{{ ezyang@sabre:~$ ghc-8.0 --make Y.hs -fforce-recomp [1 of 3] Compiling Y[boot] ( Y.hs-boot, Y.o-boot ) [2 of 3] Compiling YY ( YY.hs, YY.o ) [3 of 3] Compiling Y ( Y.hs, Y.o ) Y.hs-boot:3:1: error: Identifier ‘f’ has conflicting definitions in the module and its hs-boot file Main module: f :: (a, b) Boot file: f :: (a, b) The two types are different }}} Yes this example is purposely shooting itself in the foot, but in the wild I encountered an un-annotated type which inferred a different quantifier ordering than what I expected, and I subsequently spent a while puzzling over the error message. `-fprint-explicit-foralls` is a sufficient workaround. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12441> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12429: Pattern synonym parse error should recommend enabling extension
by GHC 02 Mar '17

02 Mar '17

#12429: Pattern synonym parse error should recommend enabling extension -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.3 Keywords: pattern | Operating System: Unknown/Multiple synonym error messages | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently, if you try to use pattern synonyms in a module without -XPatternSynonyms, you can get a very uninformative parse error. For example: {{{#!hs module X where import Data.Text (pattern Y) x = 3 }}} Yields, when compiled on GHC 7.10, {{{ test.hs:3:27: parse error on input "Y" }}} It would be helpful if in addition to the error, the message suggested to the user to enable the PatternSynonyms extension, as many other error messages already do. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12429> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7