- ghc-tickets - Haskell.org

03 Jul '16

#12359: sdfs -------------------------------------+------------------------------------- Reporter: lisa1938 | 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: -------------------------------------+------------------------------------- sadada -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12359> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 02 Jul '16

02 Jul '16

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): It does seem like a String# style design might be the most tasteful / clean, from my fuzzy understanding -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:40> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 02 Jul '16

02 Jul '16

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Mathnerd314): I have yet another proposal, namely to add low-level construction methods to `IsString`: {{{#!hs class IsString a where fromString :: String -> a -- as before fromString_asc# :: Addr# -> Int# -> a fromString_asc# a _ = fromString (unpackCString# a) fromString_utf8# :: Addr# -> Int# -> a fromString_utf8# a _ = fromString (unpackCStringUtf8# a) fromString_raw# :: Addr# -> Int# -> a fromString_raw# a i = fromString (map chr (addrToWord8List a i) }}} The `String` instance would have `fromString = id`, while the `ByteString` instance would do zero-copy construction with the length information. ASCII literals would use _asc, UTF-8 literals would use _utf8, and primitive string literals would use _raw. Then `"x"# :: ByteString` would typecheck and work as expected. The only tricky part is preserving `"x"# :: Addr#` (which would be expanded to `fromString_raw# "x"# 1# :: Addr#`). It doesn't seem like `instance IsString Addr#` would be suitable. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:39> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 01 Jul '16

01 Jul '16

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 11362 | Blocking: 12262 Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, Wiki Page: | Phab:D1396, Phab:D1457, Phab:D1468, DeterministicBuilds | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Comment (by Bartosz Nitka <niteria@…>): In [changeset:"0ab63cf48580abbfe15ece934aec093203f29ed2/ghc" 0ab63cf/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0ab63cf48580abbfe15ece934aec093203f29ed2" Kill varEnvElts in seqDmdEnv GHC Trac: #4012 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:220> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12230: Non-deterministic ghc-iserv terminated error
by GHC 01 Jul '16

01 Jul '16

#12230: Non-deterministic ghc-iserv terminated error -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: GHCi | 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: -------------------------------------+------------------------------------- I noticed on a recent validate that I have been getting non-deterministic test failures due to external interpreter: {{{ =====> T10891(ext-interp) 12 of 15 [0, 1, 0] [77/9256] cd "./th/T10891.run" && "/home/hs01/ezyang/ghc-validate/inplace/test spaces/ghc-stage2" -c T10891.h s -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-missed-specialisatio ns -fshow-warning-groups -XTemplateHaskell -package template-haskell -fexternal-interpreter -v0 > T108 91.comp.stderr 2>&1 Compile failed (exit code 1) errors were: T10891.hs:30:3: error: • Exception when trying to run compile-time code: ghc-stage2: ghc-iserv terminated (-11) Code: let display :: Name -> Q () display q = ... in do { display ''C; display ''C'; .... } • In the untyped splice: $(let display :: Name -> Q () display q = do { ... } in do { display ''C; display ''C'; display ''C''; .... }) }}} More tests error the higher I crank up parallelism; on a recent full test run I got something like twenty failures of this kind when I have twelve threads. There are at least two problems here. The first is the actual failure, but the second is that there isn't enough diagnostic information here to tell what the actual problem is. Combined with the nondeterministic nature of this bug I'm not sure how to debug it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12230> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #11727: Allow one type signature for multiple pattern synonyms
by GHC 01 Jul '16

01 Jul '16

#11727: Allow one type signature for multiple pattern synonyms -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There's no reason why we shouldn't allow the same type signature for multiple pattern synonyms just like ordinary functions. For example, {{{ pattern A,B,C,D :: Int pattern A = 5 pattern B = 6 pattern C = 7 pattern D = 8 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11727> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12233: Compilation does not stop on XeTeX error
by GHC 01 Jul '16

01 Jul '16

#12233: Compilation does not stop on XeTeX error -------------------------------------+------------------------------------- Reporter: markusr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Short: This bug is important for building in an automated manner, because an error in the documentations Tex code currently results in an interactive shell. I am compiling GHC 8.0.1 and the build system picked up XeTeX, which results in compilation of a PDF. There is a syntax error in the Tex code. Unfortunately, xelatex is called without the `-halt-on-error` option and compilation just sits there in the interactive xelatex promt. {{{ [...] generating indices... genindexcd docs/users_guide/build-pdf/users_guide ; xelatex users_guide.tex writing additional pages... searchThis is XeTeX, Version 3.14159265-2.6-0.99992 (TeX Live 2015/Exherbo texlive-core-2 015-r2) (preloaded format=xelatex) restricted \write18 enabled. copying images... [100%] images/prof_scc.svg copying static files... done copying extra files... done dumping search index in English (code: en) ... done dumping object inventory... done build succeeded, 25 warnings. entering extended mode (./users_guide.tex LaTeX2e <2015/01/01> Babel <3.9l> and hyphenation patterns for 79 languages loaded. (./sphinxmanual.cls Document Class: sphinxmanual 2009/06/02 Document class (Sphinx manual) (/usr/share/texmf-dist/tex/latex/base/report.cls Document Class: report 2014/09/29 v1.4h Standard LaTeX document class (/usr/share/texmf-dist/tex/latex/base/size10.clo))) (/usr/share/texmf-dist/tex/generic/iftex/iftex.sty) (/usr/share/texmf-dist/tex/latex/cmap/cmap.sty Package cmap Warning: pdftex not detected - exiting. ) (/usr/share/texmf-dist/tex/latex/base/fontenc.sty [...] LaTeX Warning: Reference `glasgow_exts:ghc-flag--XIncoherentInstances' on page 285 undefined on input line 26759. ! Missing \endcsname inserted. <to be read again> \let l.26762 \begin{Verbatim}[commandchars=\\\{\}] ? }}} Please consider adding `-halt-on-error` in rules/sphinx.mk. Attached is a patch for master. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12233> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12000: static pointer in ghci
by GHC 01 Jul '16

01 Jul '16

#12000: static pointer in ghci -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | 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: -------------------------------------+------------------------------------- {{{ $ ghci -fobject-code -ignore-dot-ghci -XStaticPointers GHCi, version 8.1.20160428: http://www.haskell.org/ghc/ :? for help Prelude> a = static id Prelude> a <interactive>:2:1: error: Variable not in scope: a Prelude> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12000> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11165: Testsuite framework failures are too easy to ignore and too hard to find
by GHC 01 Jul '16

01 Jul '16

#11165: Testsuite framework failures are too easy to ignore and too hard to find -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | 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: -------------------------------------+------------------------------------- The testsuite driver really should do a better job of drawing the user's attention to framework failures. The only evidence in the testsuite summary that something went wrong is a non-zero "framework failures" count. If you notice that this count is non-zero then you need to sift manually through the initial log output produced by the driver and find the culprit. It's just generally terrible. Testsuite failures are failures, we should at least treat them as such and include them in the `TEST=...` message in the testsuite summary so they can be easily reproduced. Ideally we would also save the exception that caused the failure and show it in the summary as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11165> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #7679: Regression in -fregs-graph performance
by GHC 01 Jul '16

01 Jul '16

#7679: Regression in -fregs-graph performance -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: merge Priority: low | Milestone: 8.0.2 Component: Compiler (NCG) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #7192, #8657 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge * milestone: => 8.0.2 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7679#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0