August 2013 - ghc-tickets

[GHC] #8136: arr020 test fails randomly with ghci way
by GHC 07 Feb '16

07 Feb '16

#8136: arr020 test fails randomly with ghci way -----------------------------+---------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.7 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -----------------------------+---------------------------------- I noticed that when I run arr020 (`make TEST=arr020`) it randomly segfaults when running `ghci` way. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8136> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[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] #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

[GHC] #8098: Faulty Word64 arithmetic if optimized
by GHC 02 Dec '15

02 Dec '15

#8098: Faulty Word64 arithmetic if optimized ----------------------------+--------------------------------- Reporter: achp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+--------------------------------- The following program produces different results depending on optimization: Checked.hs: {{{ module Checked ((.-.)) where (.-.) :: (Bounded a, Integral a) => a -> a -> Maybe a x .-. y | x >= 0 && y < 0 = if z > x then Just z else Nothing | x >= 0 = if z <= x then Just z else Nothing | x < 0 && y > 0 = if z < x then Just z else Nothing | otherwise = Just z where z = x - y }}} Main.hs: {{{ module Main (main) where import Data.Maybe import Data.Word import Numeric import Checked main :: IO () main = print $ showHex (fromJust ((0xFFFFFFFF00000000 :: Word64) .-. 0x00000000FFFFFFFF)) "" }}} {{{ D:\dev\haskell\ch1>ghc --make Checked.hs Main.hs [1 of 2] Compiling Checked ( Checked.hs, Checked.o ) [2 of 2] Compiling Main ( Main.hs, Main.o ) Linking Main.exe ... D:\dev\haskell\ch1>Main.exe "fffffffe00000001" D:\dev\haskell\ch1>del *.hi *.o *.exe D:\dev\haskell\ch1>ghc --make -O2 Checked.hs Main.hs [1 of 2] Compiling Checked ( Checked.hs, Checked.o ) [2 of 2] Compiling Main ( Main.hs, Main.o ) Linking Main.exe ... D:\dev\haskell\ch1>Main.exe "fffe00000001" D:\dev\haskell\ch1> }}} The bug disappears if definition and usage of (.-.) are in the same module. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8098> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8079: Redo T7919 with a cabal file
by GHC 21 Nov '15

21 Nov '15

#8079: Redo T7919 with a cabal file -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Compile-time Difficulty: Easy (less than 1 | crash hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Right now T7919 fails because the new dynamic-by-default GHC means that Template Haskell must be built with dynamic; of course, GHC isn't clever enough to figure this out. If we Cabalize the test, the example should start building again (and if they don't, well, that's a bug!) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8079> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8199: Get rid of HEAP_ALLOCED
by GHC 21 Nov '15

21 Nov '15

#8199: Get rid of HEAP_ALLOCED ----------------------------------------------+---------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Project (more than a week) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- This bug is to track progress of removing HEAP_ALLOCED from GHC, promising faster GC, as long as we can keep the cost of indirections down. The relevant wiki article: http://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/HeapAlloced ; we are implementing method 2. The attached patchset is *almost* able to support GHC itself; a ghc-stage2 built this way can compile most files, but is much slower in some cases, and probably has some correctness bugs. Improvements possible: * Don't pay for a double indirection when -fPIC is turned on. Probably the easiest way to do this is to *not* bake in the indirections into compiled code when it is -fPIC'd, and instead scribble over the GOT. However, I don't know how to go backwards from a symbol to a GOT entry, so we might need some heinous assembly hacks to get this working. * Closure tables should have their indirections short-circuited by the initialization code. * We are paying an indirection when a GC occurs when the closure is not in R1. According to the wiki page, technically this is not needed, but I don't know how to eliminate references to the closure itself from stg_gc_fun. * Properly handle the Windows DLL case (e.g. SRTs); this should be simpler now that everything is an indirection. * Bikeshed hs_main API changes (because closures are not valid prior to RTS initialization, so you have to pass in an indirection instead) * Improve static indirection and stable pointer registration, avoiding binary bloat from `__attribute(constructor)__` stubs. * Need to implement a new megablock tracking structure so we can free/check for lost blocks -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8199> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 52

[GHC] #8168: ghc "Simplifier ticks exhausted" "When trying UnfoldingDone"
by GHC 16 Sep '15

16 Sep '15

#8168: ghc "Simplifier ticks exhausted" "When trying UnfoldingDone" -------------------------------------+------------------------------------- Reporter: sp55aa | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.6.3 Keywords: Simplifier, | Operating System: Windows UnfoldingDone, simpl-tick-factor | Type of failure: GHC rejects Architecture: x86 | valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- ghc fail to compile this file: ---- begin Y.hs ---- newtype Rec a = Rec { unRec :: Rec a -> a } y :: (a -> a) -> a y = \f -> (\x -> f (unRec x x)) (Rec (\x -> f (unRec x x))) foo :: (a -> a) -> a -> a foo f n = f n main = print $ y foo 4 ---- end Y.hs ---- C:\Users\user\Desktop>ghc Y.lhs [1 of 1] Compiling Main ( Y.lhs, Y.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for i386-unknown-mingw32): Simplifier ticks exhausted When trying UnfoldingDone a_sqe{v} [lid] To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 5601 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8168> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8127: iOS patch no 19: Linking
by GHC 05 Sep '15

05 Sep '15

#8127: iOS patch no 19: Linking -------------------------------------+------------------------------------- Reporter: StephenBlackheath | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Other Architecture: arm | Type of failure: GHC doesn't work Difficulty: Moderate (less | at all than a day) | Test Case: Blocked By: | Blocking: 7724 Related Tickets: | -------------------------------------+------------------------------------- Fix linking for cross compiler to iOS. This patch does these things: 1. use libtool to link to a static library in place of an executable (because on iOS the final link must be done in Xcode), 2. for packages, keep only the HS package libraries and throw out other options (because libtool doesn't accept them), 3. fail if you try to link a dynamic library on iOS because it isn't supported (not really needed but there for completeness). Note that there is a minor risk here, because in the normal case, the order of options passed to the linker is slightly different: The options relating to each dependent package are separated into three different kinds, but they're still in the same relative order per package. This should be perfectly OK. The name of "libtool" is hard-coded and can't be set by options. Is this OK? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8127> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14