- ghc-tickets - Haskell.org

[GHC] #11496: Build profiling libraries on `validate --slow`
by GHC 27 Jan '16

27 Jan '16

#11496: Build profiling libraries on `validate --slow` -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | 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: -------------------------------------+------------------------------------- It would be good to test the `profiling` test ways regularly (`prof`, `profasm`, `profthreaded` etc.). These test ways require the profiling libraries to be built first, which `validate` doesn't do at the moment. We do release profiling libraries, so we'd better make sure they work correctly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11496> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11451: Inconsistent warnings for unused binders
by GHC 27 Jan '16

27 Jan '16

#11451: Inconsistent warnings for unused binders -------------------------------------+------------------------------------- Reporter: simonpj | 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 compiling this with `-Wunused-matches`: {{{ class C a where op :: a -> a instance C (Maybe a) where op x = x }}} We get no warnings, even though `a` is patently unused. But suppose we add an associated type {{{ class C a where type T a op :: a -> a instance C (Maybe a) where type T (Maybe a) = Int -- Warning on this line op x = x }}} Now we get a warning for an unused binding for `a` on the `type instance`. Edward complained about this inconsistent behaviour in [https://mail.haskell.org/pipermail/glasgow-haskell- users/2016-January/026114.html this email thread]. My thoughts: * Currently GHC does not warn about type variables bound in the instance head but unused in the `where` part. Fixing that might be a good idea, but would be a new feature. * However, given that we don't warn about them, we should definitely not warn about instance type variables being unused in an associated type. But we could warn about ones specific to the associated type itself. Eg {{{ class C2 a where type T2 a b instance C2 (Maybe a) where type T2 (Maybe a) x = Int -- Line XXX }}} Here, on line `XXX`, we might reasonably warn about the unused `x`, but not about the unused `a`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11451> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 37

[GHC] #11489: Segmentation fault when .prof file not writeable
by GHC 27 Jan '16

27 Jan '16

#11489: Segmentation fault when .prof file not writeable -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Profiling | Version: 7.0.1 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: -------------------------------------+------------------------------------- To reproduce: {{{ $ echo 'main = return ()' > Test.hs $ touch Test.prof $ chmod -w Test.prof $ ghc -prof Test.hs [1 of 1] Compiling Main ( Test.hs, Test.o ) Linking Test ... $ ./Test +RTS -hr{} -hc Can't open profiling report file Test.prof Segmentation fault (core dumped) }}} The warning is ok (maybe it should be an error?), but it shouldn't segfault. Running `./Test +RTS -hr` works fine. http://downloads.haskell.org/~ghc/master/users-guide/profiling.html#rts- options-for-heap-profiling: * `-hc`: Breaks down the graph by the cost-centre stack which produced the data. * `-hr⟨cc⟩`: Restrict the profile to closures with retainer sets containing cost-centre stacks with one of the specified cost centres at the top. Bug exists since dbef766ce79e37a74468a07a93b15ba1f06fe8f8 (2002): {{{ - you can now restrict a heap profile to certain retainer sets, but still display by cost centre (or type, or closure or whatever). }}} Because it didn't update this code+comment introduced in db61851c5472bf565cd1da900b33d6e033fd743d (2001): {{{ // The following line was added by Sung; retainer/LDV profiling may need // two output files, i.e., <program>.prof/hp. if (RtsFlags.ProfFlags.doHeapProfile == HEAP_BY_RETAINER) RtsFlags.ProfFlags.doHeapProfile = 0; }}} Another relevant commit a4e17de6a38eb37cabff165e8f280a236ffa8af6: {{{ Author: simonmar <unknown> Date: Wed Nov 28 15:42:26 2001 +0000 [project @ 2001-11-28 15:42:26 by simonmar] Don't need the .prof file when LDV-profiling. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11489> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11497: LAMBORGHINI MANYLINE JOINT SHARE
by GHC 27 Jan '16

27 Jan '16

#11497: LAMBORGHINI MANYLINE JOINT SHARE -------------------------------------+------------------------------------- Reporter: | Owner: kamaljitchakraborty | Type: feature | Status: new request | Priority: highest | Milestone: 7.10.4 Component: Build System | Version: 7.0.4 Keywords: LAMBORGHINI | Operating System: MacOS X MANYLINE JOINT SHARE | Architecture: Other | Type of failure: Other Test Case: none | Blocked By: Blocking: | Related Tickets: no Differential Rev(s): no | Wiki Page: none -------------------------------------+------------------------------------- http://lamborghini.com [[Image(link company_profile_1800x405.kamaljit.jpg )]] * '''bold''', ''' myself a worker in this company : THIS THE COMPANY WEBSITE ADDRESS ''', * ''italic'' * '''''VIA MODENA 12,40019,SAN'T AGATA BOLOGNESE [B0]''''' or ''italic and ''' italic bold ''' '' * __LAMBORGHINI MANYLINE JOINT SHARE__ * {{{schoolbook century}}} or `monospace` (hence ` RESPECTED FERRUCCIO LAMBORGHINI` or {{{:LAMBORGHINI}}} quoting `{{{VAT ID:00591801204 wire with ||:ICIC0002790}}} quoting) * ~~strike-through KAMALJITCHAKRABORTY~~ * ^LAMBORGHINI AUTOMOBILI S.p.A^ * ,,subscript,, * **RESPECTED STEPHAN WINKELMANN**, //**RESPECTED PATRICK KUJALA as well**//,**SRI SUSIT KUMAR CHAKRABARTI**, and **'' bold italic **'' //(since 0.40)// [[Image(thumb_IMG_0216_1024.jpg)]] * {{{Item}}} 1CK: Friday, February 19th, 2016 - Monday, February 22nd, 2016 {{{WINTER ACCADEMIA LIVIGNO - AVANZATO 1 }}} * Item 1.1 * Item 1.1.1 * Item 1.1.2 * Item 1.1.3 * Item 1.2 * {{{Item}}} 2CK: Sunday, February 21st, 2016 - Wednesday, February 24th, 2016 {{{WINTER ACCADEMIA LIVIGNO - AVANZATO 2 }}} * Item 2.2.1 * Item 2.2.2 * Item 2.2.3 * {{{Item}}} 3CK:Tuesday, February 23rd, 2016 - Friday, February 26th, 2016 {{{WINTER ACCADEMIA LIVIGNO - AVANZATO 3}}} * Item 3.3.1 * Item 3.3.2 * Item 3.3.3 * {{{Item}}} 4CK: Thursday, February 25th, 2016 - Saturday, February 27th, 2016 {{{WINTER ACCADEMIA LIVIGNO - INTENSIVO 1}}} * Item 4.4.1 * Item 4.4.2 * Item 4.4.3 - items can start at the beginning of a line and they can span multiple lines - be careful though to continue the line with the appropriate indentation, otherwise that will start a new paragraph... 1. Item 1 a. Item 1.a a. Item 1.b i. Item 1.b.i i. Item 1.b.ii 1. Item 2 And numbered lists can also be restarted with an explicit number: 3. Item 3 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11497> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10324: our rts/ghc-prim/base shared library tricks don't work on Android
by GHC 27 Jan '16

27 Jan '16

#10324: our rts/ghc-prim/base shared library tricks don't work on Android -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature | Status: new request | Milestone: Priority: low | Version: 7.10.1 Component: Compiler | Operating System: Other Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I experimented with building dynamically linked executables on Android, and figured I should record my findings somewhere. (I'm interested in dynamic Haskell libraries because I'd like to eventually get ghci on Android, though obviously that would also require a bunch of packaging work!) Building a GHC with dynamic library support was no major problem, and I could build a dynamically linked "Hello, world" executable too. The problem arose when trying to actually run the executable: I got a message to the effect that there were unresolved symbols (that live in libHSrts) when loading libHSbase. I tried relinking the executable to put libHSrts before libHSbase in the list of NEEDED shared libraries, and now I instead got an error about missing symbols (that live in libHSbase) when loading libHSrts. I then tried rebuilding libHSrts against libHSbase... and then I got the first error again, about missing symbols (that live in libHSrts) when loading libHSbase, while loading libHSrts. I didn't try also rebuilding libHSbase against libHSrts, because at that point the base library would be dependent on the RTS flavor, which we don't really want. It appears based on these tests that the Android dynamic loader only looks for missing symbols in a shared library in the dependencies of that library in a depth-first fashion, while the Linux ld.so seems to do something more like loading every (direct and indirect) dependency of the executable first and then resolving symbol references between them all at once. I didn't fully characterize the Android loader behavior though, and it's possible that if we could remove the references from libHSrts to libHSbase and libHSghc-prim, then we could list libHSrts first among the dependencies of an executable, and hopefully once libHSrts has been loaded, the loader would then use its symbols to resolve references when loading the libHSghc-prim and libHSbase libraries, even without those libraries having NEEDED entries for libHSrts. Removing the references from libHSrts to libHSbase/libHSghc-prim should be fairly mechanical if we can use constructors in the latter libraries (basically emulate dynamic linking by adding a global variable to libHSrts which is a struct holding the addresses of the base/ghc-prim symbols it needs, and have constructors in those libraries fill in those addresses on load). If that doesn't work, another possibility may be to statically link libHSrts (or whatever part of it we need) into the executable and export libHSrts's dynamic symbols so that they can be used by libHSghc-prim (or other Haskell libraries). I also haven't tested whether this kind of mutual recursion between an executable and its shared library dependencies works on Android. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10324> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #7790: Add dummy undefined symbols to indicate ways
by GHC 27 Jan '16

27 Jan '16

#7790: Add dummy undefined symbols to indicate ways -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 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 rwbarton): Clever and simple, I like it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7790#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4505: Segmentation fault on long input (list of pairs)
by GHC 26 Jan '16

26 Jan '16

#4505: Segmentation fault on long input (list of pairs) -------------------------------------+------------------------------------- Reporter: cathper | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Segmentation | fault, segfault, long input Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: 4258 | Blocking: Related Tickets: | Differential Rev(s): Phab:D1180 Wiki Page: | -------------------------------------+------------------------------------- Changes (by niteria): * owner: => niteria Comment: I'm going to try my hand at this in my spare cycles. If it's blocking anyone feel free to grab it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4505#comment:42> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2258: ghc --cleanup
by GHC 26 Jan '16

26 Jan '16

#2258: ghc --cleanup -------------------------------------+------------------------------------- Reporter: claus | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.8.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4114 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bheklilr): Replying to [comment:26 shubhaml]: > I'm willing to help @bheklilr with this. I'm a first-time contributor too. > > So far I've created a {{{--cleanup}}} flag which does exactly what {{{--make}}} does. I need to figure out the subsequent parts. > > One idea is that {{{hi}}} and {{{o}}} files will be deleted only if target directories are not specified using {{{-odir}}} and {{{-hidir}}} (since the target directories could be {{{/dev/null}}}). In this case these files are put in the same directory with the same name as the source file, and will be deleted. Other generated files from {{{-keep-*-files}}} will be preserved. > > So running with {{{ghc --cleanup}}} will, in effect, only create executables, and possibly some intermediate files other than {{{hi}}} and {{{o}}}. Is this a good idea? Also, have I missed something? I'm going to have to just pass this to you. I've been struggling with my home computer, trying to diagnose what appears to be hardware problems so I haven't had a stable computer for about a week now and won't for at least another week. Sorry to pass it on without having gotten any work done on it myself, this just hasn't been a good month for me, thanks for looking into it already =) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2258#comment:29> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5987: Too many symbols in ghc package DLL
by GHC 26 Jan '16

26 Jan '16

#5987: Too many symbols in ghc package DLL ---------------------------------+---------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 5355 Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by rassilon): I'm not sure I completely understand your GHCi suggestion (but that is unnecessary) , but I certainly agree with the rest of your suggestions. If someone cares enough, they can fund the necessary engineering. :) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5987#comment:53> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5987: Too many symbols in ghc package DLL
by GHC 26 Jan '16

26 Jan '16

#5987: Too many symbols in ghc package DLL ---------------------------------+---------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 5355 Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by simonmar): I propose: * Do not dynamically-link GHC on Windows * Do not build a dynamic version of the GHC package * Continue to build dynamic versions of everything else * Use Remote GHCi (`-fexternal-interpreter`) to get dynamic linking in GHCi * Close this ticket :) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5987#comment:52> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0