- ghc-tickets - Haskell.org

[GHC] #8398: reify module list in TH
by GHC 18 Nov '14

18 Nov '14

#8398: reify module list in TH -------------------------------------------+------------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: #8337 | Test Case: | Blocking: 7867 -------------------------------------------+------------------------------- This patch is for the use-case detailed in #7867. The added Q monad method provides the ability to get a list of module names in a format that is compatible with the module annotation reification in #8337. The patch contains a helper method that depends on #8337, so that should be applied first. If this is problematic, it's easy to separate this patch into one that doesn't depend on #8337 and an other that does. Then we can add the latter later. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8398> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8401: parsec issues
by GHC 18 Nov '14

18 Nov '14

#8401: parsec issues ----------------------------------+--------------------------------------- Reporter: dsamperi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------------- Built ghc-7.7 using BuildFlavour quick under Fedora 18 Linux and I encounter a problem after installing parsec and trying to load example ch16/csv9.hs from RealWorldHaskell: Could not find module 'Text.ParserCombinators.Parsec' Perhaps you haven't installed the "dyn" libraries for package parsec-3.1.3 There are also Warnings while installing parsec: Data/Text/Lazy/Builder/Int.hs:52:11: Warning: Rule "decimal/Int" may never fire because ‛decimal’ might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ‛decimal’ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8401> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8404: Default to turning on architecture specific optimizations in the codegen
by GHC 18 Nov '14

18 Nov '14

#8404: Default to turning on architecture specific optimizations in the codegen ------------------------------------+------------------------------------- Reporter: tibbe | 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: | ------------------------------------+------------------------------------- LLVM defaults to turning on whatever architecture specific optimizations are supported on the user's machine (e.g. `-msse4.2`). This makes programs run faster during testing and generally gives users a better perception of the compiler. If the user wants to compile for some more portable subset (e.g. when cross-compiling) he/she adds `-march`, `-mcpu`, etc flags on the command line. To implement this we'd have to detect what CPU type is used etc and initialize our `DynFlags` based on that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8404> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8415: GHC bug using darcs on Kubuntu 13.04
by GHC 18 Nov '14

18 Nov '14

#8415: GHC bug using darcs on Kubuntu 13.04 ----------------------------------+------------------------------------- Reporter: JoeAquilina | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------------- I was trying to push a darcs patch when it failed with a GHC error. This is the text of the error message on the console: darcs: internal error: evacuate: strange closure type 536064 (GHC version 7.6.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) Not sure if this is exactly what is required when reporting a bug, I am very new to this and am unsure of the procedures involved regarding GHC bug reporting. Thanks in advance. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8415> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8419: add rawSystem variant that takes an environment
by GHC 18 Nov '14

18 Nov '14

#8419: add rawSystem variant that takes an environment -------------------------------------+------------------------------------- Reporter: dagit | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/process | 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: | -------------------------------------+------------------------------------- rawSystem properly handles the case of ^C while waiting. Instead of requiring people to recreate this behavior when using runProcess, it would be good if we add and export a rawSystemWithEnv or directly export syncProcess. See for example: https://github.com/haskell/cabal/issues/1448 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8419> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8420: Spurious dynamic library dependencies
by GHC 18 Nov '14

18 Nov '14

#8420: Spurious dynamic library dependencies ------------------------------------+--------------------------------- Reporter: AndreasVoellmy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- It should be possible to have an executable A that depends on dynamic library B which in turn depends on dynamic library C, without A directly depending on C. {{{ A --> B --> C }}} Unfortunately, GHC 7.6.3 does not seem to allow this. Instead it copies the dependencies of B to dependencies of A, so that we get {{{ A -> B,C and B --> C }}} This is unfortunately, because running A will cause the loader to locate C based on the rpaths (assuming we are using rpaths to locate dynamic libraries), whereas only B should know how to get to C from B. The problem seems to be that ghc copies all the library dependencies of B (presumably from the package specification of B) as library dependencies of the A. I verified the problem in GHC 7.6.3, but haven't tried in HEAD yet. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8420> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #5364: Access RTS flag values from inside Haskell programs
by GHC 18 Nov '14

18 Nov '14

#5364: Access RTS flag values from inside Haskell programs -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ekmett Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.3 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D306 | -------------------------------------+------------------------------------- Changes (by thomie): * cc: core-libraries-committee@… (added) * differential: => Phab:D306 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5364#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3827: Compiling fails on linux-powerpc
by GHC 18 Nov '14

18 Nov '14

#3827: Compiling fails on linux-powerpc ----------------------------------------------+--------------------------- Reporter: speleologic | Owner: Type: bug | Status: closed Priority: normal | Milestone: ⊥ Component: Build System | Version: 6.12.1 Resolution: worksforme | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Changes (by thomie): * status: new => closed * difficulty: => Unknown * component: Compiler => Build System * resolution: => worksforme Comment: Closing this 5 year old ticket. Probably a lot has change since then, and #8437 leads me to believe the powerpc build actually worked quite recently. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3827#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8437: pprCallishMachOp_for_C: MO_Prefetch_Data 0 not supported
by GHC 18 Nov '14

18 Nov '14

#8437: pprCallishMachOp_for_C: MO_Prefetch_Data 0 not supported -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build | Version: 7.7 System | Keywords: Resolution: fixed | Architecture: powerpc64 Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Building | Related Tickets: GHC failed | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * failure: None/Unknown => Building GHC failed * component: Compiler => Build System * resolution: => fixed Comment: Replying to [comment:2 rwbarton]: > Ideally, you would output a `__builtin_prefetch` call where `rw` is 0, `locality` is the argument of the `MO_Prefetch_Data` constructor, and `addr` comes from the `args` field of the `CmmUnsafeForeignCall`. That looks pretty easy to do, by adding another special case for `fn_addr` and sending `MO_Prefetch_Data _` to `__builtin_prefetch` in `pprCallishMachOp_for_C`. Please open a new task ticket if that is still needed. Commit 896cee02e766c687a52cd75382bcfed64a623619 should have fixed the powerpc64 build, so I'm closing this ticket if you agree. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8437#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8438: Validation failure compiling primitive-memops.c
by GHC 18 Nov '14

18 Nov '14

#8438: Validation failure compiling primitive-memops.c -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build | Version: 7.7 System | Keywords: Resolution: worksforme | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Building | Related Tickets: GHC failed | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * failure: None/Unknown => Building GHC failed * component: Compiler => Build System * resolution: => worksforme -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8438#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0