January 2016 - ghc-tickets

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

[GHC] Batch modify: #9630, #5642, #11068
by GHC 26 Jan '16

26 Jan '16

Batch modification to #9630, #5642, #11068 by thomie: keywords to Generics -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=9630%2C5642%2C11068> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11492: http://jackedmuscleextremeadvice.com/crevalor/
by GHC 26 Jan '16

26 Jan '16

#11492: http://jackedmuscleextremeadvice.com/crevalor/ -------------------------------------+------------------------------------- Reporter: yanwitti | 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: -------------------------------------+------------------------------------- The biggest error most people make gone it comes to how to construct thin muscles terse is to think that the number of repetitions they pro will back taking place its not real. [http://jackedmuscleextremeadvice.com/crevalor/ Crevalor] Heavier weights and functional out at a compound severity is how to construct thin muscles rapid. Working harder for a shorter period of era is the way to achieve the goals you indulgent. http://jackedmuscleextremeadvice.com/crevalor/ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11492> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #11490: check architecture before attempting to load object files
by GHC 25 Jan '16

25 Jan '16

#11490: check architecture before attempting to load object files -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Runtime | Version: 8.0.1-rc1 System (Linker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If a user somehow manages to trick ghci into loading a `.o` file for the wrong architecture (e.g. arm vs x86), the runtime linker doesn't notice and tries to load it anyway. That is likely to result in a confusing error or crash. `ocVerifyImage_ELF` does already check the "ELF class", which amounts to 32-bit vs 64-bit. It should also check the architecture and, I think, endianness to make sure they are compatible with the running process. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11490> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #7149: Heap profiling restricted with retainers (+RTS -hrfoo -hc) segfaults
by GHC 25 Jan '16

25 Jan '16

#7149: Heap profiling restricted with retainers (+RTS -hrfoo -hc) segfaults ----------------------------------+-------------------------------------- Reporter: akio | Owner: pcapriotti Type: bug | Status: closed Priority: normal | Milestone: 7.6.1 Component: Profiling | Version: 7.5 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #11489 | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Changes (by thomie): * related: => #11489 Comment: This didn't fix the problem completely, or at least there was another bug in the same function 10 lines down, see #11489. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7149#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[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] #10433: Fix load/store barriers in pre-ARMv7 builds
by GHC 25 Jan '16

25 Jan '16

#10433: Fix load/store barriers in pre-ARMv7 builds -------------------------------------+------------------------------------- Reporter: | Owner: simonmar thoughtpolice | Status: new Type: bug | Milestone: 7.12.1 Priority: high | Version: Component: Runtime | Operating System: Unknown/Multiple System | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: arm | Related Tickets: #10244 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- As pointed out in #10244 and Phab:D894, the fix we committed for this problem isn't 100% correct - from 753b156dc6b0c38b106c390952750fb800bf27e7: {{{ #elif arm_HOST_ARCH && defined(arm_HOST_ARCH_PRE_ARMv7) // TODO FIXME: This case probably isn't totally correct - just because we // use a pre-ARMv7 toolchain (e.g. to target an old Android device), doesn't // mean the binary won't run on a newer ARMv7 system - in which case it // needs a proper barrier. So we should rethink this // - Reid __asm__ __volatile__ ("" : : : "memory"); }}} This is a reminder to fix this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10433> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9149: Description of openFileBlocking is wrong
by GHC 25 Jan '16

25 Jan '16

#9149: Description of openFileBlocking is wrong ------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The documentation states: ''Like openFile, but opens the file in ordinary blocking mode. This can be useful for opening a FIFO for reading: if we open in non-blocking mode then the open will fail if there are no writers, whereas a blocking open will block until a writer appears. '' but I think this is the wrong way around, and should be: ''Like openFile, but opens the file in ordinary blocking mode. This can be useful for opening a FIFO for writing: if we open in non-blocking mode then the open will fail if there are no readers, whereas a blocking open will block until a reader appears. '' -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9149> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2