- ghc-tickets - Haskell.org

Re: [GHC] #1851: "make install-strip" should work
by GHC 24 May '16

24 May '16

#1851: "make install-strip" should work -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Build System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Ack. Maybe the new build system (https://github.com/snowleopard/hadrian) will do better, although it doesn't know how to install GHC at all yet. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1851#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1851: "make install-strip" should work
by GHC 24 May '16

24 May '16

#1851: "make install-strip" should work -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Build System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by gidyn): * status: closed => new * resolution: fixed => Comment: OK, I think I've found the libraries which aren't stripped. (Apologies for the earlier comment, a problem with my gcc installation had led me to think that nothing is stripped.) {{{ # cd /usr/local/lib/ghc-8.0.1/rts # du -h * 3.1M libHSrts.a 3.9M libHSrts_thr.a # strip --strip-unneeded * # du -h * 736K libHSrts.a 848K libHSrts_thr.a }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1851#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1851: "make install-strip" should work
by GHC 24 May '16

24 May '16

#1851: "make install-strip" should work -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Build System | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by gidyn): * status: new => closed * resolution: => fixed Comment: I seem to be having a problem with gcc. I'll re-open if it turns out that there was an issue in ghc after all. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1851#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1965: Allow unconstrained existential contexts in newtypes
by GHC 24 May '16

24 May '16

#1965: Allow unconstrained existential contexts in newtypes -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:9 simonpj]: > Anything involving existentials is going to be hard to implement using newtype directly. But as 'mokus' says, it might be possible to make a guarantee, right in the code generator, that certain sorts of data types do not allocate a box. The conditions are, I think, very nearly as 'mokus' says: > 1. Only one constructor > 2. Only one field with nonzero width in that constructor (counting constraints as fields) > 3. That field is marked strict > 4. That field has a boxed (or polymorphic) type > I think this'd be do-able. The question is how important it is in practice; it's one more thing to maintain. I would like to have something like this very much! Among other things, it's one possible way to make `IntMap` nicer. One potential extension: I think constraints only need to count as fields if any of them are classes that have methods, or whose superclasses have methods. In particular, it could be very useful to have equality constraints involving type families. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1965#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1965: Allow unconstrained existential contexts in newtypes
by GHC 24 May '16

24 May '16

#1965: Allow unconstrained existential contexts in newtypes -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1965#comment:27> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12107: Strange behavior of Foldable (,) a
by GHC 24 May '16

24 May '16

#12107: Strange behavior of Foldable (,) a -------------------------------------+------------------------------------- Reporter: polarke | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 8.0.1 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The definion of ''Foldable (,) a'' is as follows. {{{#!hs instance Foldable ((,) a) where foldMap f (_, y) = f y foldr f z (_, y) = f y z }}} I am very confused with this definition. As a consequence, we have {{{#!hs maximum (1,0) == 0 }}} I believe this is not something we want. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12107> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12060: GHC panic depending on what a Haskell module is named
by GHC 24 May '16

24 May '16

#12060: GHC panic depending on what a Haskell module is named --------------------------------------+---------------------------------- Reporter: Darwin226 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- I'm trying to make bindings for the imgui C++ library and have encountered an apparent bug. I'm unable to produce a minimal example so I've packed up the whole project in a zip file. It only works on Windows for now but I assume this problem is platform dependant anyways. There's a module `UI.Imgui` that imports two things. A `FunPtr` wrapping function and an actual function defined in a .cpp file. Another module Main imports this module. If the project is run in a repl (in my case I'm doing `stack repl`) and then the `test` function is evaluated it results in a GHC panic {{{#!hs ghc.exe: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-unknown-mingw32): loadObj "C:\\Users\\Luka\\AppData\\Local\\Temp\\ghc5900_0\\ghc_5.o": failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Now here's the fun part. If you rename the module, file and it's import to something like Imgui2 it works. If you rename it to UI2.Imgui (with appropriate folder renaming) it also works! I'm sure a huge portion of the code is irrelevant. I couldn't reproduce this with simple .cpp files. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12060> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11967: Custom message when showing functions, comparing functions, ...
by GHC 24 May '16

24 May '16

#11967: Custom message when showing functions, comparing functions, ... -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- One of the [https://ghc.haskell.org/trac/ghc/wiki/Proposal/CustomTypeErrors#Examples examples] of type errors: {{{#!hs instance TypeError (Text "Cannot 'Show' functions." :$$: Text "Perhaps there is a missing argument?") => Show (a -> b) where showsPrec = error "unreachable" }}} We already have [https://hackage.haskell.org/package/base-4.8.2.0/docs/src/Text.Show.Functio… Text.Show.Functions], is there a place in `base` for this along with `Ord (a -> b)` instances and co. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11967> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11034: ghc 7.10.2 testsuite: "T367(normal)" test compilation fails
by GHC 24 May '16

24 May '16

#11034: ghc 7.10.2 testsuite: "T367(normal)" test compilation fails ----------------------------------------+--------------------------------- Reporter: dtonhofer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- {{{ =====> T367(normal) 39 of 4142 [0, 1, 0] cd ./concurrent/should_run && "/usr/local/bin/ghc" -o T367 T367.hs -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package- db -rtsopts -fno-warn-tabs -fno-ghci-history -O2 -fno-omit-yields > T367.comp.stderr 2>&1 Compile failed (status 256) errors were: [1 of 1] Compiling Main ( T367.hs, T367.o ) *** Core Lint errors : in result of Simplifier *** <no location info>: Warning: In the expression: seq @ (Id Int) @ (# State# RealWorld, () #) (foldlM' @ Int @ Int @ Id @ Vector $fMonadId ($fNumInt_$c+ `cast` (<Int>_R -> <Int>_R -> Sym (NTCo:Id[0] <Int>_R) :: (Int -> Int -> Int) ~R# (Int -> Int -> Id Int))) z_a2UZ (enumFromTo_int @ Id @ Vector $fMonadId (I# 1) (I# 1000000000))) (# eta_B1, () #) Kinds don't match in type application: Type variable: b_13 :: * Arg type: (# State# RealWorld, () #) :: # xx # (.... offending program attached ...) *** End of Offense *** <no location info>: Compilation had errors *** unexpected failure for T367(normal) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11034> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8990: Performance tests behave differently depending on presence of .hi file (even with -fforce-recomp)
by GHC 24 May '16

24 May '16

#8990: Performance tests behave differently depending on presence of .hi file (even with -fforce-recomp) ------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Example: {{{ [ezyang@hs01 compiler]$ cat T6048.comp.stats /home/hs01/ezyang/ghc-compalloc/inplace/lib/bin/ghc-stage2 -B/home/hs01/ezyang/ghc-compalloc/inplace/lib -fforce-recomp -dno-debug- output -no-user-package-db -rtsopts -fno-ghci-history -c T6048.hs -O -fasm +RTS -V0 -tT6048.comp.stats --machine-readable [("bytes allocated", "119871672") ,("num_GCs", "100") ,("average_bytes_used", "4388904") ,("max_bytes_used", "12539576") ,("num_byte_usage_samples", "7") ,("peak_megabytes_allocated", "27") ,("init_cpu_seconds", "0.00") ,("init_wall_seconds", "0.00") ,("mutator_cpu_seconds", "0.09") ,("mutator_wall_seconds", "0.10") ,("GC_cpu_seconds", "0.15") ,("GC_wall_seconds", "0.15") ] [ezyang@hs01 compiler]$ rm T6048.hi [ezyang@hs01 compiler]$ '/home/hs01/ezyang/ghc-compalloc/inplace/bin/ghc- stage2' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T6048.hs -O -fasm +RTS -V0 -tT6048.comp.stats --machine-readable -RTS [ezyang@hs01 compiler]$ cat T6048.comp.stats /home/hs01/ezyang/ghc-compalloc/inplace/lib/bin/ghc-stage2 -B/home/hs01/ezyang/ghc-compalloc/inplace/lib -fforce-recomp -dno-debug- output -no-user-package-db -rtsopts -fno-ghci-history -c T6048.hs -O -fasm +RTS -V0 -tT6048.comp.stats --machine-readable [("bytes allocated", "121022912") ,("num_GCs", "100") ,("average_bytes_used", "4022069") ,("max_bytes_used", "11224944") ,("num_byte_usage_samples", "7") ,("peak_megabytes_allocated", "25") ,("init_cpu_seconds", "0.00") ,("init_wall_seconds", "0.00") ,("mutator_cpu_seconds", "0.09") ,("mutator_wall_seconds", "0.11") ,("GC_cpu_seconds", "0.15") ,("GC_wall_seconds", "0.14") ] }}} It's a slight but present difference: I noticed because one of the perf tests was failing on an initial run of the test suite, but passing when I re-ran it. There are two possible bugs here. One is that our implementation of `-fforce-recomp` is buggy and we shouldn't be reading in the hi file at all if `-fforce-recomp` is on; the other is that we should always clean up interface files before running one of these perf tests. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8990> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10