October 2013 - ghc-tickets

[GHC] #8265: getTokenStream fails for source using cpp
by GHC 07 Feb '16

07 Feb '16

#8265: getTokenStream fails for source using cpp -----------------------------------+--------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- Calling getTokenStream (or getRichTokenStream) on a module that has CPP directives fails as the lexer is given un-preprocessed source -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8265> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8287: exploring calling convention changes and related engineering for 7.10
by GHC 25 Jan '16

25 Jan '16

#8287: exploring calling convention changes and related engineering for 7.10 ------------------------------------+------------------------------------- Reporter: carter | Owner: Type: task | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Rocket Science | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I'm creating this as a master ticket for systematically exploring and benchmarking (possibly breaking) changes to the GHC calling convention. This work will initially focus on x86/x86_64, but may have larger scope. Goals: 1. if possible, improve performance systematically for code run on recent CPU micro architecture generations (eg sandybridge, haswell, and future extensions like Knights Landing and Skylake), ideally without pessimizing code on other or older x86_64 micro-architectures 2. Try to bring native and llvm codegens closer to feature parity (or at the very least, do not widen their capability gap) 3. a few other pieces too, will amend this ticket as ideas / plans clarify -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8287> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #8325: Pattern guards in anonymous functions
by GHC 25 Jan '16

25 Jan '16

#8325: Pattern guards in anonymous functions ------------------------------------+------------------------------------- Reporter: mcollis | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- In the course of a project, I had an idea that would allow less cumbersome use of cases in anonymous functions. Here's a simple example of what I'm proposing: {{{ (\x y | x > y -> x | otherwise -> something else) }}} Currently, the only way to accomplish this is with if() then ... else syntax or the use of the MultiWayIf and LambdaCase extensions. The syntax I've proposed here matches with existing anonymous function syntax and doesn't conflict with any other GHC syntax. This would greatly improve the readability of complex anonymous functions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8325> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8285: unexpected behavior with encodeFloat on large inputs
by GHC 23 Jan '16

23 Jan '16

#8285: unexpected behavior with encodeFloat on large inputs --------------------------+------------------------------------------------ Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: | Version: 7.7 Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result at runtime Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ benjamin scarlet discovered some unexpected behavior in encodeFloat today {{{ <bscarlet> > map (\x -> encodeFloat 1 (shiftL 1 x)) [30,31] [23:47:47] <lambdabot> [Infinity,0.0] [23:49:09] <arkeet> > encodeFloat 1 60 [23:49:10] <lambdabot> 1.152921504606847e18 [23:49:09] <arkeet> > encodeFloat 1 60 [23:49:10] <lambdabot> 1.152921504606847e18 [23:49:18] <arkeet> er. [23:50:21] <bscarlet> down in the sane range I suspect it's just fine. [23:50:43] <bscarlet> > encodeFloat 1 1000 [23:50:44] <lambdabot> 1.0715086071862673e301 [23:50:52] <bscarlet> > encodeFloat 1 10000 [23:50:53] <lambdabot> Infinity [23:50:58] <bscarlet> That's sane. [23:51:03] <arkeet> > encodeFloat 1 (2^31) [23:51:04] <lambdabot> 0.0 [23:51:13] <bscarlet> That's what I think is weird. [23:51:19] <carter> bscarlet floats are weird [23:51:23] <arkeet> > encodeFloat 1 (2^31-1) [23:51:24] <lambdabot> Infinity }}} Benjamin did a wee bit of investigation, and the problem seems to lie in https://github.com/ghc/packages-integer- gmp/blob/master/cbits/float.c#L177 in integer-gmp, where it deliberately doesn't handle the edge cases (probably worth investigating) if integer-simple has similar behavior or not -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8285> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8403: Pretty-printing of long types
by GHC 23 Jan '16

23 Jan '16

#8403: Pretty-printing of long types ------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Low priority, but this ghci output could be more packed. {{{ λ> :t (,,,,,,,,,,,,,,,,,,,,,,,) (,,,,,,,,,,,,,,,,,,,,,,,) :: a -> b -> c -> d -> e -> f -> g -> h -> i -> j -> k -> l -> m -> n -> o -> p -> q -> r -> s -> t -> u -> v -> w -> x -> (a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, q, r, s, t, u, v, w, x) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8403> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8064: Warning out when "undefined" value has been used.
by GHC 23 Jan '16

23 Jan '16

#8064: Warning out when "undefined" value has been used. ------------------------------------+------------------------------------- Reporter: freizl | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Programmer may like to use "undefined" to define a function or value, which usually means "later implementation". However, people might forget to implement it thus cause run time error. Wish GHC will show some warning/errors at compilation. This idea comes from this article (http://www.devalot.com/articles/2013/07 /why-haskell.html) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8064> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8422: type nats solver is too weak!
by GHC 23 Jan '16

23 Jan '16

#8422: type nats solver is too weak! -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler (Type | Version: 7.7 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: Unknown/Multiple | valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- I just built ghc HEAD today, and the type nat solver can't handle the attached program, which *should* be simple to check! (and while I could use unsafeCoerce to "prove" it correct, that defeats the purpose of having the type nat solver!) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8422> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8114: GHC panic when building `thyme`
by GHC 16 Jan '16

16 Jan '16

#8114: GHC panic when building `thyme` -----------------------------------+--------------------------------------- Reporter: Ptharien's | Owner: Flame | Status: new Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Operating System: MacOS X Keywords: | Type of failure: Compile-time crash Architecture: x86_64 (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- While attempting to build `thyme` from Hackage with core, stg, and cmm linting and -O2 enabled, GHC crashed with an internal panic. See attached terminal log. {{{ rrdhcp-10-32-234-247:thyme-0.2.4.1 Alexander$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.6.3 rrdhcp-10-32-234-247:thyme-0.2.4.1 Alexander$ cabal --version cabal-install version 1.16.0.2 using version 1.16.0 of the Cabal library rrdhcp-10-32-234-247:thyme-0.2.4.1 Alexander$ which ghc /usr/local/bin/ghc rrdhcp-10-32-234-247:thyme-0.2.4.1 Alexander$ which cabal /Users/Alexander/Library/Haskell/bin/cabal }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8114> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8060: Undefined symbols when using Template Haskell linked from another object with unexposed modules
by GHC 08 Jan '16

08 Jan '16

#8060: Undefined symbols when using Template Haskell linked from another object with unexposed modules -----------------------------------+--------------------------------------- Reporter: tvynr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- I have constructed two Cabal projects named "first" and "second". The "first" project defines three files: Logging.hs (which provides some basic logging functionality) and FirstExample.hs and FirstDependent.hs (the latter of which imports the former). In the cabal file, only Logging and FirstDependent are exposed modules. FirstDependent uses a Template Haskell function "loggingFunctions" which defines logging functions for that module. Using cabal or cabal-dev to build this package works quite nicely. The second project depends on the first project and contains a single file, Second.hs. This file imports Logging but neither of the other two files. It also uses the loggingFunctions routine to generate local logging functions. The presence of the "$(loggingFunctions)" splice in Second.hs makes the problem visible, but the real problem is in the first project. Upon compilation of the "second" project with cabal or cabal- dev, the following error is generated: {{{ cabal-dev -s ../cabal-dev-sandbox --with-cabal-install=cabal configure Resolving dependencies... Configuring second-0.1... cabal-dev -s ../cabal-dev-sandbox --with-cabal-install=cabal build Building second-0.1... Preprocessing library second-0.1... [1 of 1] Compiling Second ( lib-src/Second.hs, dist/build/Second.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.4.0.1 ... linking ... done. Loading package deepseq-1.3.0.1 ... linking ... done. Loading package containers-0.5.0.0 ... linking ... done. Loading package filepath-1.3.0.1 ... linking ... done. Loading package old-locale-1.0.0.5 ... linking ... done. Loading package time-1.4.0.1 ... linking ... done. Loading package bytestring-0.10.0.2 ... linking ... done. Loading package unix-2.6.0.1 ... linking ... done. Loading package directory-1.2.0.1 ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package mtl-2.1.2 ... linking ... done. Loading package text-0.11.3.1 ... linking ... done. Loading package parsec-3.1.3 ... linking ... done. Loading package network-2.4.1.2 ... linking ... done. Loading package process-1.1.0.2 ... linking ... done. Loading package hslogger-1.2.1 ... linking ... done. Loading package pretty-1.1.1.0 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package first-0.2 ... linking ... ghc: /home/some- directories/example/first/../cabal-dev- sandbox//lib/first-0.2/ghc-7.6.1.20121207/HSfirst-0.2.o: unknown symbol `firstzm0zi2_FirstExample_zdfShowErrorSpec3_closure' ghc: unable to load package `first-0.2' make[1]: *** [build] Error 1 }}} Upon further investigation, it would seem that the .o file constructed to represent the "first" project has not been completely constructed: {{{ $ objdump -t cabal-dev- sandbox/lib/first-0.2/ghc-7.6.1.20121207/HSfirst-0.2.o | grep '\*UND\*' | grep first 00000000 *UND* 00000000 firstzm0zi2_FirstExample_zdfOrdErrorSpeczuzdczg_info 00000000 *UND* 00000000 firstzm0zi2_FirstExample_zdfShowErrorSpec3_closure 00000000 *UND* 00000000 firstzm0zi2_FirstExample_zdfOrdErrorSpeczuzdczl_info 00000000 *UND* 00000000 firstzm0zi2_FirstExample_zdfEqErrorSpeczuzdczeze_info 00000000 *UND* 00000000 firstzm0zi2_FirstExample_zdfOrdErrorSpeczuzdczlze_info 00000000 *UND* 00000000 firstzm0zi2_FirstExample_zdfOrdErrorSpeczuzdccompare_info 00000000 *UND* 00000000 firstzm0zi2_FirstExample_zdfOrdErrorSpeczuzdczgze_info }}} (While the above dump is for ghc 7.6.1, this has also been tested on ghc 7.6.3 as well as on both i386- and amd64-based OS installs.) If the "$(loggingFunctions)" splice is removed from Second.hs, then the project builds (presumably because the logic used by non-Template Haskell projects for linking differs from that of Template Haskell projects). Fortunately, it seems that exposing every module of the "first" project resolves this issue. But please note that the FirstExample.hs and FirstDependent.hs files are completely unrelated to the Second.hs file; the latter does not depend on the former in any way. It seems strange that I can't use Template Haskell across projects without exposing all of my project modules. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8060> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8182: Parser.y.pp needs special treatment with -fcmm-sink
by GHC 31 Dec '15

31 Dec '15

#8182: Parser.y.pp needs special treatment with -fcmm-sink ------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Build System | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- This bug is really more of a reminder, but it's critical for the 7.8.1 release. Right now, `Parser.y.pp` uses a very weird hack to pass `-fcmm-sink` to the compiler. Here's the relevant comment: {{{ -- CPP tricks because we want the directives in the output of the -- first CPP pass. -- -- Clang note, 6/17/2013 by aseipp: It is *extremely* important (for -- some reason) that there be a line of whitespace between the two -- definitions here, and the subsequent use of __IF_GHC_77__ - this -- seems to be a bug in clang or something, where having the line of -- whitespace will make the preprocessor correctly format the rendered -- lines in the 'two step' CPP pass. No, this is not a joke. #define __IF_GHC_77__ #if __GLASGOW_HASKELL__ >= 707 #define __ENDIF__ #endif __IF_GHC_77__ -- Required on x86 to avoid the register allocator running out of -- stack slots when compiling this module with -fPIC -dynamic. {-# OPTIONS_GHC -fcmm-sink #-} __ENDIF__ }}} This is because the parser is first preprocessed before being run with GHC (which again preprocesses,) so we want the resulting `#ifdef` in the final `.hs` file. Things to note: * We really shouldn't be doing this, it's amazingly fragile. I think the correct thing to do is to ensure the build system correctly passes `-fcmm- sink` during the stage[2,3] build. * `./configure.ac` needs to check to see if the bootstrapping compiler is `ghc >= 7.7` (or `7.8`) and if it is, ''also'' pass `-fcmm-sink` during the stage1 build. * This hack needs to be removed once we can rely on >= 7.8 for bootstrap. Probably something like the hypothetical 7.12-7.14 timeframe. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8182> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3