March 2015 - ghc-tickets

[GHC] #8713: libdl, libpthread may be unwanted too
by GHC 21 Jun '16

21 Jun '16

#8713: libdl, libpthread may be unwanted too -------------------------------------+------------------------------------- Reporter: ip1981 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/unix | Version: 7.6.3 Keywords: | Operating System: Other Architecture: x86_64 (amd64) | Type of failure: GHC doesn't work Difficulty: Moderate (less | at all than a day) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- I have GHC on an unusual system [1] libdl.so.1, librt.so.1 and some others are "filter libraries": they do not provide real functions (almost all is in libc.so.1), but to make thing work libFOO.so are GNU ld linker scripts: thus linking is successful, libFOO.so.1 is not linked in :-) Unfortunately, runtime linker (ld.so.1) does not understand GNU ld linker scripts. And I get errors like this: {{{ # ghci -package unix GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help 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 bytestring-0.10.0.2 ... linking ... done. Loading package old-locale-1.0.0.5 ... linking ... done. Loading package time-1.4.0.1 ... linking ... done. Loading package unix-2.7.0.0 ... <command line>: can't load .so/.DLL for: /usr/lib/gcc/x86_64-pc-solaris2.11/4.7/../../../x86_64-illumos/libdl.so (ld.so.1: ghc: fatal: /usr/lib/gcc/x86_64-pc- solaris2.11/4.7/../../../x86_64-illumos/libdl.so: unknown file type) }}} The unix package v2.6 had the same issue with librt.so too, in version 2.7 libdl.so remains. I use the attached patch for GHC 7.6.3 to fix this issue. In general I suggest to use AC_SEARCH_LIBS instead of AC_CHECK_LIB [1] http://osdyson.org -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8713> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #9646: Strange performance bug
by GHC 20 Jun '16

20 Jun '16

#9646: Strange performance bug -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I've been chasing a weird performance bug for about a week now. I've reduced the testcase to the following git repo: https://github.com/erikd/ghc-perfbug-test The Readme.md file in that repo contains an explanation of how to reproduce the issue. The benchmark program in the repo uses Criterion to test the performance of one particular function. Running the program in a particular way results into two significanlty different results. The commands are: {{{ make clean bench-integer.html cp -f bench-integer.html bench-integer-slow.html touch New3/GHC/Integer/Natural.hs && make bench-integer.html }}} The results for one function in the file `New3/GHC/Integer/Natural.hs` is 8 times slower in the first test that the second while the other test function always executes at about the speed. I haven't been able to test this with ghc-7.6.3 because the code uses `isTrue#` which isn't available in 7.6.3. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9646> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #9682: Implement "Add bifunctor related classes to base"-Proposal
by GHC 18 Jun '16

18 Jun '16

#9682: Implement "Add bifunctor related classes to base"-Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less | Type of failure: than a day) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- See [http://www.haskell.org/pipermail/libraries/2014-April/022844.html original libraries@ proposal] for more details -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9682> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[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

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

14 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

[GHC] #10117: Change the scheme for reporting redundant imports
by GHC 14 Jun '16

14 Jun '16

#10117: Change the scheme for reporting redundant imports -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The current scheme for reporting redundant imports is given on the [wiki:Commentary/Compiler/UnusedImports unused imports page]. [wiki:Migration/7.10#GHCsaysTheimportof...isredundant The 7.10 migration page] describes a hack to avoid redundant-import warnings during migration, without using CPP. The hack works for {{{ module Foo (Int, Word, Monoid(..)) where import Data.Monoid import Data.Word import Prelude }}} (the hack is putting `import Prelude` at the bottom). To understand why, read the specification on the [wiki:Commentary/Compiler/UnusedImports unused imports page]. But it fails for {{{ module Foo (Int, Word, Monoid(..)) where import Data.Monoid (Monoid(..)) import Data.Word (Word) import Prelude }}} because the specification treats itemised imports like `import Data.Word(Word)` differently to "import all" imports. The question: '''is there alternative spec (vs the one on the [wiki:Commentary/Compiler/UnusedImports unused imports page]) that would support the behaviour desired here, without having other undesirable consequences?''' -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10117> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9553: GHC under Windows with TH can't tell that gtk-win32-2.0 is in gtk-win32-2.0-0 (note the -0 suffix)
by GHC 09 Jun '16

09 Jun '16

#9553: GHC under Windows with TH can't tell that gtk-win32-2.0 is in gtk- win32-2.0-0 (note the -0 suffix) -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: GHC Difficulty: Unknown | rejects valid program Blocked By: | Test Case: Related Tickets: #5289 #1883 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The following compilation under Wine (after applying the workarounds described at http://www.haskell.org/haskellwiki/GHC_under_Wine#Code_that_uses_gtk2hs) {{{ cabal install LambdaHack-0.4.99.0 }}} fails with (the full log attached) {{{ Loading package LambdaHack-0.4.99.1 ... ghc.exe: gtk-win32-2.0: Module not found. <command line>: can't load .so/.DLL for: gtk-win32-2.0.dll (addDLL: could not load DLL) }}} The following workaround sidesteps the problem, leading to a correctly running executable (symlinks are not enough). {{{ cp gtk/bin/libgtk-win32-2.0-0.dll gtk/bin/libgtk-win32-2.0.dll cp gtk/bin/libgdk-win32-2.0-0.dll gtk/bin/libgdk-win32-2.0.dll cp gtk/bin/libatk-1.0-0.dll gtk/bin/libatk-1.0.dll cp gtk/bin/libgio-2.0-0.dll gtk/bin/libgio-2.0.dll cp gtk/bin/libgio-2.0-0.dll gtk/bin/pango- cp gtk/bin/libgio-2.0-0.dll gtk/bin/ cp gtk/bin/libpangowin32-1.0-0.dll gtk/bin/libpangowin32-1.0.dll cp gtk/bin/libpangocairo-1.0-0.dll gtk/bin/libpangocairo-1.0.dll cp gtk/bin/libgdk_pixbuf-2.0-0.dll gtk/bin/libgdk_pixbuf-2.0.dll cp gtk/bin/libpango-1.0-0.dll gtk/bin/libpango-1.0.dll cp gtk/bin/libcairo- gtk/bin/libcairo.dll cp gtk/bin/libcairo-2.dll gtk/bin/libcairo.dll cp gtk/bin/libgobject-2.0-0.dll gtk/bin/libgobject-2.0.dll cp gtk/bin/libgmodule-2.0-0.dll gtk/bin/libgmodule-2.0.dll cp gtk/bin/libgthread-2.0-0.dll gtk/bin/libgthread-2.0.dll cp gtk/bin/libglib-2.0-0.dll gtk/bin/libglib-2.0.dll cp gtk/bin/libfontconfig-1.dll gtk/bin/libfontconfig.dll }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9553> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8510: Clear up what extensions are needed at a Template Haskell splice site
by GHC 08 Jun '16

08 Jun '16

#8510: Clear up what extensions are needed at a Template Haskell splice site ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | 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: | ------------------------------------+------------------------------------- Suppose you write {{{ module M where data T = ... $(cleverThFunction ''T) }}} where `cleverThFunction` is some Template Haskell code in a library somewhere. Question: * '''If `cleverThFunction` generates code that uses `GADTs`, or `ConstraintKinds`, or `TypeFamilies` or whatnot, do those language extension flags have to be in force in module M, or only at the definition of `cleverThFunction`?''' Currently the situation is anarchic; see below. It should be made tidy. My personal preference is to say that the extensions must be in force in the definition of `cleverThFunction`, but '''not''' at the splice site. Reason: the client doesn't know or care how `cleverThFunction` works. This decision would be compatible with the handling of overlapping instances. Gergely writes: There are a lot of extensions that simply can't be used with TH: {{{ - n+k, - RecursiveDo, - TransformListComp, - Arrows, - ImplicitParams, - TupleSections, - Monadcomprehensions. }}} The rest can be grouped into two parts. The following extensions still work when spliced in without the corresponding language pragma: {{{ - UnicodeSyntax, - LambdaCase, - NamedFieldPuns, - RecordWildCards, - DataTypeContexts (and you get rid of the deprecation warning generation this way :)), - ConstraintKind, - MagicHash (note that UnboxedTuples is in the other part), - TraditionalRecordSyntax, - MultiWayIf, - GADTs (extra nice example at the end of this message). }}} The following needs the pragma at the place of splicing: {{{ - PostfixOperators, - ScopedTypeVariables, - Rank2, RankN, - deriving typeable and data, - UnboxedTuples, - ViewPatterns, - ParallelListComp, - ExistentialQuantification, - EmptyDataDecls, - TypeFamilies, - MultiParamTypeClasses, - FunctionalDependencies. }}} I don't see any trivial distinction, like based on Reader vs Typechecker, or anything like that. In particular * Note `ViewPatterns` vs `LambdaCase`. * Note `GADTs` vs `Rank2`. A very interesting example is `ExplicitForAll`. The AST for polymorphic functions always have explicit foralls in TH.Syntax; so there is no way to require the user at the point of splicing to enable the language extension. GADTs are cool too: {{{ {-# LANGUAGE TemplateHaskell #-} -- No need for GADTs at all! -- {-# LANGUAGE GADTs #-} $([d| data Foo where Foo1 :: Int -> Foo Foo2 :: String -> Foo f1 :: Foo f1 = Foo1 5 f :: Foo -> Either Int String f (Foo1 n) = Left n f (Foo2 s) = Right s |]) main = print (f f1) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8510> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9034: GHCi panics when given C++ object file on GNU/Linux
by GHC 08 Jun '16

08 Jun '16

#9034: GHCi panics when given C++ object file on GNU/Linux ------------------------------------------+------------------------------- Reporter: jun0 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Keywords: panic, dynamic linking | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------------+------------------------------- When given a C++ object file, GHCi panics saying that it can't find standard C++ symbols the object file relies on. If foo.cc contains {{{#!C++ #include <iostream> extern "C" void foo () { std::cout << "bar"; } }}} and is compiled with {{{ g++ -fPIC -c -o foo.o foo.cc }}} then {{{ ghci foo.o -lstdc++ }}} fails with {{{ GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading object (static) foo.o ... ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc14109_0/ghc14109_1.so: undefined symbol: _ZSt4cout Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} It makes no difference to add -L<C++ library paths> which was, IIRC, necessary in older versions of GHC. This applies to only GHCi with C++ -- GHC can link C++ object files just fine, while GHCi has no trouble loading C object files. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9034> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9766: Use TypeLits in the meta-data encoding of GHC.Generics
by GHC 02 Jun '16

02 Jun '16

#9766: Use TypeLits in the meta-data encoding of GHC.Generics -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: 9043 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This ticket serves to track the task of improving the meta-data representation in GHC.Generics as described in the following wiki page: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/GenericDeriving#A… I'm working on this in branch `wip/GenericsMetaData`, and I intend to have it in 7.10. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9766> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9