April 2014 - ghc-tickets

Re: [GHC] #7730: :info and polykinds
by GHC 06 Apr '14

06 Apr '14

#7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8776 --------------------------------------------+------------------------------ Comment (by archblob): I do think you know what's best and I will look into exactly how much information needs to be added and write a patch. The reason I considered the other aproach was because I didn't really think modifying the iface implementation would be something you were willing to do just because of pretty printing purposes. Also there will not really be that much code duplication when doing separate tidying so I will try and have a patch with both aproaches next week and I'll also try to understand exactly how the iface interface should be extended and maybe start a discussion about that as I make progress. Andrei -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7730#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7730: :info and polykinds
by GHC 06 Apr '14

06 Apr '14

#7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8776 --------------------------------------------+------------------------------ Comment (by simonpj): I'm quite reluctant to duplicate all that tidying machinery. Moreover, we need to pretty-print `IfaceDecl`s anyway, so this is just duplicating that. If there isn't enough information in `IfaceSyn`, maybe we should add a little more. For Gergo's point I was going to add an extra constructor to `IfaceType`, corresponding to `=>`, for example. Easy; and will improve the output from `--show-iface`. So by all means go ahead, and I will look, but I'm advertising that my instinct is still to take the approach I outlined. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7730#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7730: :info and polykinds
by GHC 05 Apr '14

05 Apr '14

#7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8776 --------------------------------------------+------------------------------ Comment (by archblob): I have managed to fix this (not yet for kind!) using the tidying machinery from {{{ MkIface}}}. I first tried going through {{{IfaceDecl}}} as Simon suggested here and in #8776, but this gets really messy because as Gergo observed {{{tyThingToIfaceDecl}}} doesn't work for {{{RealDataCon}}}, and I also observed the same story for {{{ClassOpId}}} and this will require us keep {{{TyThing}}} in certain cases. I thing this will lead to code that is more complex and harder to understand in the long run. I also haven't looked into how this relates to #8776 but I thing we can also go without conversion to {{{IfaceDecl}}} in that case. I will have a patch ready in a couple of days(some other things came up) and after we further discuss the right aproach. Andrei -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7730#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7942: aarch64 support in ghc
by GHC 04 Apr '14

04 Apr '14

#7942: aarch64 support in ghc --------------------------------------------+------------------------------ Reporter: jcapik | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC doesn't work at all | Difficulty: Unknown Test Case: | Blocked By: 7623, 8664 Blocking: | Related Tickets: --------------------------------------------+------------------------------ Comment (by cjwatson): Right. I thought that was probably the case, but I didn't really want to do yet another build that omitted them in order to make sure, since it all takes a while as it is! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7942#comment:27> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7942: aarch64 support in ghc
by GHC 04 Apr '14

04 Apr '14

#7942: aarch64 support in ghc --------------------------------------------+------------------------------ Reporter: jcapik | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC doesn't work at all | Difficulty: Unknown Test Case: | Blocked By: 7623, 8664 Blocking: | Related Tickets: --------------------------------------------+------------------------------ Comment (by kgardas): Colin, thanks for submitting this. Indeed, I think for basic unregisterised build to work changes done in includes/stg/ and rts/ may be omitted for now. Those are my experimental bits kind of start of a work on registerised support... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7942#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7942: aarch64 support in ghc
by GHC 04 Apr '14

04 Apr '14

#7942: aarch64 support in ghc --------------------------------------------+------------------------------ Reporter: jcapik | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC doesn't work at all | Difficulty: Unknown Test Case: | Blocked By: 7623, 8664 Blocking: | Related Tickets: --------------------------------------------+------------------------------ Changes (by cjwatson): * cc: cjwatson@… (added) * status: new => patch -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7942#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7942: aarch64 support in ghc
by GHC 04 Apr '14

04 Apr '14

#7942: aarch64 support in ghc --------------------------------------------+------------------------------ Reporter: jcapik | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC doesn't work at all | Difficulty: Unknown Test Case: | Blocked By: 7623, 8664 Blocking: | Related Tickets: --------------------------------------------+------------------------------ Comment (by cjwatson): I've been working with Karel Gardas (kgardas) to get this going, and I've now completed an unregisterised GHC bootstrap on Ubuntu arm64. I started by cross-building GHC 7.8 using variations on Karel's patch set, and then bodged together a GHC 7.6 build (since that's what we're shipping on other architectures) bootstrapping off that. This all now appears to be working fine and I should be able to get binaries into our archive in the next few days. I'm attaching a patch (made against the ghc-7.8 branch); most of it is Karel's from https://ghcarm.wordpress.com/2014/01/18/unregisterised-ghc- head-build-for-arm64-platform/, I've just tweaked it a bit given that I had the advantage of access to real hardware. Some of this may be unnecessary for an unregisterised build, but it doesn't hurt. It would be great if somebody could review and apply it, since it's a lot easier to get started on more advanced things like LLVM or NCG support if you don't have to do the time-consuming bootstrap yourself. Please note that you also need to update the embedded copy of libffi in `libffi-tarballs/` to at least version 3.0.12. Karel's initial patch caused `GHC_CONVERT_CPU` to return `arm64`. I changed this to `aarch64`, since the return value of `GHC_CONVERT_CPU` is used to construct the `--host` option for configure scripts and thus it needs to be valid as the first part of a GNU config triplet. I left the Haskell-level architecture name as `ArchARM64`, since that style is more common as a user-facing name for the architecture: for example, the Linux kernel returns `arm64` in its `uname` output. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7942#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8834: 64-bit windows cabal.exe segfaults in GC
by GHC 04 Apr '14

04 Apr '14

#8834: 64-bit windows cabal.exe segfaults in GC ----------------------------------+--------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: None | Version: 7.8.1-rc2 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------- `cabal.exe` built with 64-bit windows GHC segfaults doing `cabal configure` or `cabal install` or probably something else. This occurs *both* for cabal-install 1.18.0.2 built against Cabal 1.18.1.2 and for cabal-install 1.18.0.3 built against Cabal 1.18.1.3. This occurs only for 64-bit build, 32-bit build is fine. 64-bit GHC-7.6.3 build is also fine. During debugging I see segfault occurs inside `evacuate` somewhere near `get_itbl` call I guess. If I make `cabal.exe` to not trigger some presumably bad GC compiling it with `-rtsopts` and running it as (for example) {{{cabal +RTS -H256m -m50 -RTS ...}}} the problem disappears. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8834> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 85

[GHC] #8956: Confusing error message due to ` #`-lines
by GHC 04 Apr '14

04 Apr '14

#8956: Confusing error message due to ` #`-lines -------------------------+------------------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: | Milestone: normal | Version: 7.8.1-rc2 Component: | Operating System: Unknown/Multiple Compiler | Type of failure: Incorrect warning at Keywords: | compile-time Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- Consider the following two (invalid) modules `M1` and `M2`: {{{#!hs # 1 "<built-in>" 1 module M1 where }}} and {{{#!hs # 1 "<built-in>" 1 module M2 where }}} When those are compiled separately by GHC, they result in the following error: {{{ $ ghc -c -Wall M1.hs M1.hs:1:2: parse error on input ‘#’ ghc -c -Wall M2.hs M2.hs:1:2: parse error on input ‘#’ }}} However, when compiled simultaneously, the modules get seemingly parsed as `Main`-modules (which then conflict with each others): {{{ ghc --make -Wall M1.hs M2.hs <no location info>: module ‘main:Main’ is defined in multiple files: M1.hs M2.hs }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8956> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8956: A Particular Section Slimming Bathing Suits For
by GHC 04 Apr '14

04 Apr '14

#8956: A Particular Section Slimming Bathing Suits For ------------------------------------+------------------------------------- Reporter: shozzsho1 | 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: | ------------------------------------+------------------------------------- Typically the extremely attractive a primary cutting cleaning suits spotted faction here are virtually all offered at Slimming cleaning suits For everybody. V-neckline might be Metropolis not to honor embellishing Surplice with the helpfulness of end relate slims a belly not to award deed a stylish construe a appear. A lot of us usurp who something same to regular the tankini washing tally testament be essentially enthralling write swimwear to prefer from. But, eliminate an try stern numerous individuals with that a lot of definitions testament postulate that woman carrying a portion country slimming bathing suits are actually way solon enticing. [http://ultracleanseadvice.com/ ULTRA CLEANSE] In this individual there is actually a publication of extremely cute patterns in one spell slimming cleaning suits. You can actually decide the eligible agree uncommitted of ever previously exploit out of your lodging. Completely new suffered an occurrence swarming for you whenever carrying whatever tanking 's no more long pronto getable? For a bit of (elevate everybody) it is essentially frightening, whereas different a lot of women cruise beautifully via the disorder. Anyway, it's neat to know who steady when typically the tankini age set has ended, make not to honor researching awful don't need to locomote out to be sacrificed whenever carrying whatsoever extremely cute a component cutting swimwear. Why not see the storyline on the somebody of your bit drama brewing this unequalled really cardinal interruption, and / or if you want solely diminution concerning downwards canvass the really extremely attractive a primary writing slimming washing beautify I meet touched in this mortal mainly for most people. Anyway, Let's comic you object it a explore and maturate several extremely attractive a special area agree! '''ULTRA CLEANSE''' Typically the rather retentive set Pasha Summer Proceedings because of Longitude might be tall not to notice deft. Location imitate definitely gift obtain attending to all line whilst the embellishing appreciation helps typically the defeat not to honour slims typically the belly. Impressive covered or black camelopard makes more advisable with the helpfulness of old watches reject instrument pretend many monumental study utilizing this Colorful sunny styles properness this uncomparable sum embellishing end affiliate swimsuit on a voguish describe which may garment a heroic size of shapes. This unparalleled grow helps typically the break goal not to notice dazzles with the refrain of its particular sunny micturate. Impressive individual or hum {Burke mightiness be classically stylishness, fluid not to honour specially body wrap unit amount utilizing this criss-cross fulgurous disposition. A particular x-backed Skirtini accompanied by a complicated paisley modify the man, advantageous a superhuman tog creatively slims typically the tumefy precisely as it comes recognition beyond typically the body not to accolade this. http://ultracleanseadvice.com/ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8956> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0