- ghc-tickets - Haskell.org

[GHC] #13382: Join ceilings incorrectly getting placed outside value lambdas by SetLevels
by GHC 14 Mar '17

14 Mar '17

#13382: Join ceilings incorrectly getting placed outside value lambdas by SetLevels -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: JoinPoints | 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 a latent bug, so there's no test case. Given code like {{{ let f = \x y z -> e1 in e2 }}} we have `SetLevels` put a “join ceiling” around `e1` to be sure that we don't let a join point float out, since any jump to that join point from `e1` would be invalid. However, an oversight in `lvlFloatRhs` has us putting the join ceiling around the lambdas instead—in other words, it appears that we might produce {{{ let f = join j = ... in \x y z -> ... jump j ... in e2 }}} (which is wrong because you can't jump out of a lambda) rather than {{{ let f = \x y z -> join j = ... in ... jump j ... in e2 }}} As it happens, this bug is latent because of the way `FloatOut` and `SetLevels` interact. `FloatOut` correctly understands where the join ceiling //should// be. Then, at each join ceiling, `FloatOut` drops all bindings marked “float me to the nearest join ceiling,” so if `j` is so marked, the latter example (the correct one) is the result and not the former. Nonetheless, `lvlFloatRhs` as written is clearly wrong. (This of course illustrates a shortcoming of the “join ceiling” scheme, at least as implemented: we rely on `FloatOut` and `SetLevels` agreeing on where the join ceilings are. It's easy to specify where they //should// be, but since there are two modules implementing them, we have twice the opportunities to get it wrong.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13382> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13326: Implement `-ferror-limit` for GHC
by GHC 14 Mar '17

14 Mar '17

#13326: Implement `-ferror-limit` for GHC -------------------------------------+------------------------------------- Reporter: coopercm | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- Clang has an option `-ferror-limit=n` which is very handy for development since it lets you focus on the first error message when there is a long list of errors. A similar flag for GHC would be very helpful. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13326> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13414: shebang + literate haskell causes line numbering skew
by GHC 14 Mar '17

14 Mar '17

#13414: shebang + literate haskell causes line numbering skew -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Noticed on doctest's Setup.lhs file. Minimal example: {{{#!hs #!/usr/bin/env runhaskell > main = return () }}} {{{ $ inplace/bin/ghc-stage2 -fforce-recomp -Wall Setup [1 of 1] Compiling Main ( Setup.lhs, Setup.o ) Setup.lhs:1:3: warning: [-Wmissing-signatures] Top-level binding with no type signature: main :: IO () | 1 | #!/usr/bin/env runhaskell | ^^^^ }}} Notice how it points 4 characters a line before '''main'''. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13414> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13298: Compact API design improvements
by GHC 14 Mar '17

14 Mar '17

#13298: Compact API design improvements -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: | Version: 8.0.1 libraries/compact | 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: -------------------------------------+------------------------------------- I took a look at the compact API today and I realized that there are a lot of improvements we should make to it: 1. `fmap getCompact . compact` is a pretty common thing to do, if you don't actually care about the compact pointer. We should make a helper function for this. 2. The `SerializedCompact` data structure needs a bunch of instances. Especially, a user who wants to serialize the compact region needs to save this metadata somewhere, but we don't offer any help for doing this. 3. `importCompact` will always print a message to stderr saying pointer fixup is happening. Need to be able to suppress this message. 4. The serialization API is really unsafe; we should make it more safe by default by including some sort of fingerprint, at least. 5. There should be a convenience function for serializing to and from a file, and serializing to and from a handle. RDMA is always going to be delicate business (so keep the old API around) but for these cases we should pave the cowpaths. Here is some sample code that might help: {{{ {-# LANGUAGE ScopedTypeVariables #-} import System.Environment (getArgs) import qualified Data.Set as Set import System.IO import Data.Compact import Data.Compact.Serialized import Foreign.Ptr import Foreign.Storable import Foreign.Marshal.Alloc import Control.Monad main = do [dict_file, out_file] <- getArgs dict <- readFileLatin1 dict_file c <- compact (Set.fromList (words dict)) withBinaryFile out_file WriteMode $ \h -> withSerializedCompact c $ \sc -> do -- Write out the metadata header hPutStorable h (serializedCompactRoot sc) forM_ (serializedCompactBlockList sc) $ \(ptr, l) -> do hPutStorable h ptr hPutStorable h l hPutStorable h nullPtr -- Write out the payload forM_ (serializedCompactBlockList sc) $ \(ptr, l) -> hPutBuf h ptr (fromIntegral l) mb_r <- withBinaryFile out_file ReadMode $ \h -> do -- Read out the metadata header root <- hGetStorable h let go h xs = do ptr <- hGetStorable h if ptr == nullPtr then return (reverse xs) else do l <- hGetStorable h go h ((ptr, l):xs) blocks <- go h [] let sc = SerializedCompact { serializedCompactBlockList = blocks, serializedCompactRoot = root } -- Read the payload into memory importCompact sc $ \ptr l -> void $ hGetBuf h ptr (fromIntegral l) print (fmap getCompact mb_r == Just (getCompact c)) hPutStorable :: forall a. Storable a => Handle -> a -> IO () hPutStorable h a = alloca $ \ptr -> do poke ptr a hPutBuf h ptr (sizeOf (undefined :: a)) hGetStorable :: forall a. Storable a => Handle -> IO a hGetStorable h = alloca $ \ptr -> do hGetBuf h ptr (sizeOf (undefined :: a)) peek ptr readFileLatin1 f = do h <- openFile f ReadMode hSetEncoding h latin1 hGetContents h }}} I'm happy to do these but I want to make sure I'm not stepping on FB's toes, also I don't know if bgamari wants to take patches along these lines so late in the release cycle. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13298> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] Trac email verification for user: ralf
by GHC 13 Mar '17

13 Mar '17

Please visit the following URL to confirm your email address. Verification URL: <http://ghc.haskell.org/trac/ghc/verify_email?verify=1&token=H6OSjo6d> Username: ralf Verification Token: H6OSjo6d -- GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13416: Unsolved Constraints (initTc)
by GHC 13 Mar '17

13 Mar '17

#13416: Unsolved Constraints (initTc) -------------------------------------+------------------------------------- Reporter: sgschlesinger | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: constraint | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Another bug here: ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] nub_a1U2 :: t_a1U1[tau:1] (CHoleCan: nub)} I've attached the relevant code. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13416> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: that is so great!
by matthew 13 Mar '17

13 Mar '17

Spam detection software, running on the system "mail.haskell.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Greetings, Look what I've just found on the web! It's so amazing, check it out http://truth.sindyslade.com/9796 Warm regards, matthew [...] Content analysis details: (6.6 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.3 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL [113.194.133.139 listed in zen.spamhaus.org] 0.4 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL 1.2 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist [URIs: sindyslade.com] 0.0 SPF_FAIL SPF: sender does not match SPF record (fail) [SPF failed: Please see http://www.openspf.net/Why?s=mfrom;id=matthew%40wellquite.org;ip=113.194.13…] 0.0 HTML_MESSAGE BODY: HTML included in message 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4656] 0.8 RDNS_NONE Delivered to internal network by a host with no rDNS The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor.

1 0

[GHC] #13342: Core Lint warnings are emitted on stdout rather than stderr
by GHC 12 Mar '17

12 Mar '17

#13342: Core Lint warnings are emitted on stdout rather than stderr -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 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: -------------------------------------+------------------------------------- It seems that they should be outputted on stderr like other warnings. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13342> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13412: Centralize the definition for GHC's libdir on Windows
by GHC 12 Mar '17

12 Mar '17

#13412: Centralize the definition for GHC's libdir on Windows ----------------------------------------+---------------------------- Reporter: Elieux | Owner: (none) Type: task | Status: new Priority: low | Milestone: Component: None | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+---------------------------- The location of GHC libraries on Windows is currently something like `$bindir/../lib` (because the whole distribution can be put anywhere on the filesystem, there are no absolute paths), but this information is hard-coded in multiple places instead of being defined in one place. To be clear, I mean only the relative path (`../lib`); the base still needs to be determined at runtime. I assume that tools that can rely on `ghc --info` (or equivalent) already do that. If there are any that don't, they should be fixed regardless. The build system, ghc, ghc-cabal, ghc-pkg, hsc2hs, haddock... should all be able to get the relative path from `configure`'s output. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13412> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13265: perf-llvm build fails with "Too many sections: 123418 (>= 65280)"
by GHC 11 Mar '17

11 Mar '17

#13265: perf-llvm build fails with "Too many sections: 123418 (>= 65280)" -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- Building current git head in the "BuildFlavour = perf-llvm", the build fails with: {{{ "inplace/bin/ghc-stage1" -o iserv/stage2_p/build/tmp/ghc-iserv-prof -hisuf \ p_hi -osuf p_o -hcsuf p_hc -static -prof -eventlog -O -H64m -fllvm -Wall \ -Werror -hide-all-packages -i -iiserv/src -iiserv/stage2_p/build \ -Iiserv/stage2_p/build -iiserv/stage2_p/build/iserv/autogen \ -Iiserv/stage2_p/build/iserv/autogen \ -optP-include -optPiserv/stage2_p/build/iserv/autogen/cabal_macros.h \ -package-id array-0.5.1.2 -package-id base-4.10.0.0 \ -package-id binary-0.8.4.1 -package-id bytestring-0.10.8.2 \ -package-id containers-0.5.7.1 -package-id deepseq-1.4.3.0 \ -package-id ghci-8.1 -package-id unix-2.7.2.1 -XHaskell2010 \ -threaded -optl-Wl,--export-dynamic -no-hs-main -no-user-package-db \ -rtsopts -Wnoncanonical-monad-instances -odir iserv/stage2_p/build \ -hidir iserv/stage2_p/build -stubdir iserv/stage2_p/build \ -static -prof -eventlog -O -H64m -fllvm -Wall -Werror -hide-all- packages \ -i -iiserv/src -iiserv/stage2_p/build \ -Iiserv/stage2_p/build -iiserv/stage2_p/build/iserv/autogen \ -Iiserv/stage2_p/build/iserv/autogen -optP-include \ -optPiserv/stage2_p/build/iserv/autogen/cabal_macros.h -package-id \ array-0.5.1.2 -package-id base-4.10.0.0 -package-id binary-0.8.4.1 \ -package-id bytestring-0.10.8.2 -package-id containers-0.5.7.1 \ -package-id deepseq-1.4.3.0 -package-id ghci-8.1 -package-id unix-2.7.2.1 \ -XHaskell2010 -threaded -optl-Wl,--export-dynamic -no-hs-main \ -no-user-package-db -rtsopts -Wnoncanonical-monad-instances \ iserv/stage2_p/build/Main.p_o iserv/stage2_p/build/GHCi/Utils.p_o \ iserv/stage2_p/build/cbits/iservmain.p_o Warning: -rtsopts and -with-rtsopts have no effect with -no-hs-main. Call hs_init_ghc() from your main() function to set these options. /usr/bin/ld: iserv/stage2_p/build/tmp/ghc-iserv-prof: Too many sections: 123418 (>= 65280) /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: error: ld returned 1 exit status `gcc' failed in phase `Linker'. (Exit code: 1) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13265> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9