- ghc-tickets - Haskell.org

[GHC] #10382: Template Haskell quotes should work with stage 1 compiler
by GHC 18 Jun '16

18 Jun '16

#10382: Template Haskell quotes should work with stage 1 compiler -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Milestone: 7.12.1 Priority: normal | Version: 7.11 Component: Template | Operating System: Unknown/Multiple Haskell | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Right now, you must enable the `TemplateHaskell` extension to use quotes, and `TemplateHaskell` is not supported by the stage 1 compiler. But there actually is no good reason why this should be the case: quoting doesn't require any user-written code to be loaded up and run, so it should be doable by the stage 1 compiler. I propose adding a new extension, `Quotation`, which turns on JUST quotation and works with the stage 1 compiler. This will solve len's problem https://github.com/ekmett/lens/issues/496 where they want to rename some syntax using quotation, but don't want break compilation on a stage 1 compiler. See also #10279. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10382> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 27

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

17 Jun '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 simonmar): Hmm, this seems a bit dodgy. The RULE is not semantics-preserving (deliberately, I know), so if you use `viewCString#` you get a non- deterministic result that depends on whether optimisation is turned on and whether the RULE fired. I suppose the idea is that you hide the non- determinism behind a layer of library code, but still, I'm not keen on having non-deterministic primitives. What's wrong with the approach in #10064 to have string literals of type `(# Int#, Addr# #)`? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:38> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12202: GHC 7.10.3 throws away callstack frames for outer
by GHC 17 Jun '16

17 Jun '16

#12202: GHC 7.10.3 throws away callstack frames for outer -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It was noticed that GHC 7.10.3 sometimes drops outer callers from IP callstacks. For instance, {{{#!hs {-# LANGUAGE ImplicitParams #-} import GHC.Stack import Control.Monad.Catch newtype MyError = MyError CallStack instance Exception MyError instance Show MyError where show (MyError e) = show e fromEvents :: (MonadThrow m, ?loc :: CallStack) => m (Maybe Int) fromEvents = do Just <$> require 42 where -- require :: (MonadThrow m, ?loc :: CallStack) => Int -> m Int require n -- line 17 | even n = throwM $ MyError ?loc | otherwise = return n main = do putStrLn "Hello world" fromEvents -- line 24 }}} GHC 8.0.1 produces the correct output, {{{ $ ./Hi Hello world Hi: [("fromEvents",SrcLoc {srcLocPackage = "main", srcLocModule = "Main", srcLocFile = "Hi.hs", srcLocStartLine = 24, srcLocStartCol = 5, srcLocEndLine = 24, srcLocEndCol = 15})] }}} GHC 7.10.3 produces only one {{{#!hs $ ./Hi Hello world Hi: CallStack {getCallStack = [("?loc",SrcLoc {srcLocPackage = "main", srcLocModule = "Main", srcLocFile = "Hi.hs", srcLocStartLine = 17, srcLocStartCol = 35, srcLocEndLine = 17, srcLocEndCol = 39})]} }}} Uncommenting the type signature for `require` however results in more-or- less the expected callstack with 7.10.3, {{{#!hs $ ./Hi Hello world Hi: CallStack {getCallStack = [("?loc",SrcLoc {srcLocPackage = "main", srcLocModule = "Main", srcLocFile = "Hi.hs", srcLocStartLine = 18, srcLocStartCol = 35, srcLocEndLine = 18, srcLocEndCol = 39}),("require",SrcLoc {srcLocPackage = "main", srcLocModule = "Main", srcLocFile = "Hi.hs", srcLocStartLine = 14, srcLocStartCol = 14, srcLocEndLine = 14, srcLocEndCol = 21}),("fromEvents",SrcLoc {srcLocPackage = "main", srcLocModule = "Main", srcLocFile = "Hi.hs", srcLocStartLine = 24, srcLocStartCol = 5, srcLocEndLine = 24, srcLocEndCol = 15})]} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12202> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12196: ghc-pkg should drop trailing path separator when computing package database root
by GHC 16 Jun '16

16 Jun '16

#12196: ghc-pkg should drop trailing path separator when computing package database root -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Package | Version: 8.0.1 system | 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: -------------------------------------+------------------------------------- Reported on `ghc-devs@`, Nicolas Dudebout <nicolas.dudebout(a)gmail.com> writes, > When passing a package database to ghc-pkg via `GHC_PACKAGE_PATH` or `--package-db`, `${pkgroot}` does not get computed properly if the input path contains a trailing slash. > > Default behavior: > {{{ > $ ghc-pkg describe base | grep pkgroot > pkgroot: "/usr/lib/ghc-7.10.2" > }}} > > Correct behavior (no trailing slash): > {{{ > $ ghc-pkg --package-db /usr/lib/ghc-7.10.2/package.conf.d describe base > | grep pkgroot > pkgroot: "/usr/lib/ghc-7.10.2" > > $ GHC_PACKAGE_PATH=/usr/lib/ghc-7.10.2/package.conf.d ghc-pkg describe > base | grep pkgroot > pkgroot: "/usr/lib/ghc-7.10.2" > }}} > > Incorrect behavior (with trailing slash): > {{{ > $ ghc-pkg --package-db /usr/lib/ghc-7.10.2/package.conf.d/ describe > base | grep pkgroot > pkgroot: "/usr/lib/ghc-7.10.2/package.conf.d" > > $ GHC_PACKAGE_PATH=/usr/lib/ghc-7.10.2/package.conf.d/ ghc-pkg describe > base | grep pkgroot > pkgroot: "/usr/lib/ghc-7.10.2/package.conf.d" > }}} > > When this bug happens, `ghc-pkg` check complains about missing files for > packages using `${pkgroot}`. > > This bug happens because `${pkgroot}` is computed using `takeDirectory`. It > should instead use `(takeDirectory . dropTrailingPathSeparator)`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12196> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9525: +RTS -xc stack trace sometimes reported twice
by GHC 16 Jun '16

16 Jun '16

#9525: +RTS -xc stack trace sometimes reported twice -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: new Priority: low | Milestone: Component: Runtime System | Version: 7.8.3 Keywords: profiling, stack | Operating System: trace, error | Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: Incorrect Difficulty: Unknown | result at runtime Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Not sure if really a bug but just wanted to show. If this is a bug I'm hoping to fix this myself but I may need some guidance. Stack trace reported by `+RTS -xc` is sometimes printed twice. This program reports it only once, as expected: {{{#!haskell f :: Int -> Int f = error "hello" main = print (f 20) }}} {{{ ➜ ghc_patch ./error +RTS -xc *** Exception (reporting due to +RTS -xc): (THUNK_1_0), stack trace: Main.f, called from Main.CAF --> evaluated by: Main.main, called from Main.CAF error: hello }}} But if I change it to this: {{{#!haskell f :: Int -> Int f x = let x = x + 20 in x main = print (f 20) }}} Stack trace is reported twice: {{{ ➜ ghc_patch ./error +RTS -xc *** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: Main.f.x, called from Main.f, called from Main.main, called from Main.CAF *** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: Main.f.x, called from Main.f, called from Main.main, called from Main.CAF error: <<loop>> }}} Can anyone confirm that this is really a bug? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9525> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

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

15 Jun '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 simonpj): Sounds plausible, although I have not re-read the whole thread. Best to think of `viewCString#` as a primop, I think. Check with the `bytestring` folk to be sure it'll meet their goals. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:37> 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 15 Jun '16

15 Jun '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 jscholl): How about instead of adding a new type {{{String#}}}, as suggested in #10064, or adding a function {{{unpackCStringLen#}}}, we add the ability to query the size of the payload of an {{{Addr#}}} at compile-time? We could provide a function which, given an {{{Addr#}}} constant, turns this into a {{{(# Int#, Addr# #)}}} pair without introducing a new type, thus keeping the overall changes low and the design flexible. How do we get the length at compile-time? We use a special builtin rewrite-rule, which writes the length to the appropiate places. For example: {{{ {-# INLINE[0] viewCString# #-} viewCString# :: Addr# -> (# Int#, Addr# #) viewCString# addr# = (# -1#, addr# #) {-# RULES "viewCString#" forall addr . viewCString# addr = (# <length of addrs pointee>#, addr #) #-} }}} Library code could then use {{{viewCString#}}} to try to determine the length at compile-time, and, if optimizations are enabled, the call gets rewritten to the correct result. Otherwise, {{{viewCString#}}} inlines in phase 0, the resulting -1 is seen by the library code and the code is simplified to determine the length at runtime, like it does today. Why does {{{viewCString#}}} return the {{{Addr#}}} again? If it does not, the {{{Addr#}}} given to {{{viewCString#}}} will be used multiple times, thus, GHC will bind it in some let, complicating the design of the rule. If the function returns it, the library can continue to use the returned {{{Addr#}}}, and GHC will less likely share it. One could go even further and extend {{{viewCString#}}} to handle two additional cases: Converting the encoding at compile-time as well as determining the number of characters of the string. So {{{viewCString#}}} would become: {{{viewCString# :: Int# -> Addr# -> (# Int#, Addr#, Int#, Int# #)}}} The first input determines the requested mode of operation (only count bytes and characters, convert to utf16le/be, utf32le/be). The first output {{{Int#}}} determines the performed operation, it should always either be the input {{{Int#}}} or some "No operation performed" code. The other two {{{Int#}}} results are the number of bytes and number of characters, and the {{{Addr#}}} contains the potentially converted literal. Of course, an interface passing around magic {{{Int#}}}s is not the nicest, but I think, this is quite low-level code and only a few libraries like text and bytestring will have to deal with it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:36> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8825: ghc can't determine gcc version on ru_RU locale
by GHC 15 Jun '16

15 Jun '16

#8825: ghc can't determine gcc version on ru_RU locale ------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Current ghc spits warnings time to time: {{{ <no location info>: Warning: Couldn't figure out linker information! Make sure you're using GNU gcc, or clang }}} It's because my default locale is '''LANG=ru_RU.UTF-8''' [1] {{{ ... gcc версия 4.8.2 (Gentoo 4.8.2-r1 p1.4-ssptest, pie-0.5.9-ssptest) }}} versus '''LANG=C''' {{{ ... gcc version 4.8.2 (Gentoo 4.8.2-r1 p1.4-ssptest, pie-0.5.9-ssptest) }}} [1]: {{{ $ gcc -v Используются внутренние спецификации. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.2/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.2/lto-wrapper Целевая архитектура: x86_64-pc-linux-gnu Параметры конфигурации: /subvolumes/var_tmp/portage/sys- devel/gcc-4.8.2-r1/work/gcc-4.8.2/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux- gnu/gcc-bin/4.8.2 --includedir=/usr/lib/gcc/x86_64-pc-linux- gnu/4.8.2/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.2 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.2/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.2/info --with-gxx- include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include/g++-v4 --with- python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.8.2/python --enable- languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable- werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with- pkgversion='Gentoo 4.8.2-r1 p1.4-ssptest, pie-0.5.9-ssptest' --enable- libstdcxx-time --enable-shared --enable-threads=posix --enable- __cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib- list=m32,m64 --disable-altivec --disable-fixed-point --enable-targets=all --disable-libgcj --enable-libgomp --disable-libmudflap --disable-libssp --enable-lto --without-cloog Модель многопоточности: posix gcc версия 4.8.2 (Gentoo 4.8.2-r1 p1.4-ssptest, pie-0.5.9-ssptest) }}} [2]: While LANG=C output: {{{ $ LANG=C gcc -v Using built-in specs. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.2/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.2/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /subvolumes/var_tmp/portage/sys- devel/gcc-4.8.2-r1/work/gcc-4.8.2/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux- gnu/gcc-bin/4.8.2 --includedir=/usr/lib/gcc/x86_64-pc-linux- gnu/4.8.2/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.2 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.2/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.2/info --with-gxx- include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include/g++-v4 --with- python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.8.2/python --enable- languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable- werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with- pkgversion='Gentoo 4.8.2-r1 p1.4-ssptest, pie-0.5.9-ssptest' --enable- libstdcxx-time --enable-shared --enable-threads=posix --enable- __cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib- list=m32,m64 --disable-altivec --disable-fixed-point --enable-targets=all --disable-libgcj --enable-libgomp --disable-libmudflap --disable-libssp --enable-lto --without-cloog Thread model: posix gcc version 4.8.2 (Gentoo 4.8.2-r1 p1.4-ssptest, pie-0.5.9-ssptest) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8825> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 14 Jun '16

14 Jun '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: 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:"9d22fbe2d3d8c4609919040007ea8bb561bf9a38/ghc" 9d22fbe2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9d22fbe2d3d8c4609919040007ea8bb561bf9a38" Rename cmpType to nonDetCmpType This makes it obvious that it's nondeterministic and hopefully will prevent someone from using it accidentally. GHC Trac: #4012 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:210> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12188: Pattern variables bound by PatternGuards are not accessible in where clause
by GHC 14 Jun '16

14 Jun '16

#12188: Pattern variables bound by PatternGuards are not accessible in where clause -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- Consider: {{{#!hs foo :: Int -> Bool foo a | Just b <- return a = c where c = a == b }}} I get: {{{ test.hs:3:18: Not in scope: b }}} Is there any reason why pattern variables originating from pattern guards should not work in `where` clauses? Problem is present in GHC HEAD too. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12188> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6