- ghc-devs - Haskell.org

Re: FFI library error building GHC
by member MP2E 20 Sep '14

20 Sep '14

Filed a bug under GHC Trac, #9620 On Sat, Sep 20, 2014 at 7:24 AM, Herbert Valerio Riedel <hvriedel(a)gmail.com> wrote: > Hello! > > Is there a ticket for that already on GHC Trac? If not, please create > one, and try to document everything we already know about this issue > > On 2014-09-20 at 14:25:56 +0200, member MP2E wrote: > > Symlinking lib64 to lib didn't seem to work, I think the directory is > > getting cleared before build. But if I copy the contents of lib64 to lib > > after the build fails and then type make again, ghc compiles! > > > > Thanks for the workaround, hopefully a real fix will be found soon > enough :) > > > > On Sat, Sep 20, 2014 at 4:18 AM, Moritz Angermann <moritz(a)lichtzwerge.de > > > > wrote: > > > >> While this is not a proper fix. Assuming there is no no lib folder, and > >> the proper lib is in lib64, does: symlinking lib64 to lib and continuing > >> with make solve the issue? > >> > >> On Sep 20, 2014, at 12:32 PM, member MP2E <mp2e(a)archlinux.us> wrote: > >> > >> > Yep, I reported this same build error for NixOS on x86_64, > unfortunately > >> I haven't found any way to solve it. Reverting the commit that upgrades > to > >> libffi-3.1 still showed this issue. I'd love to see this fixed, as I am > >> unable to do any development on GHC until it's fixed :( > >

1 0

Fwd: FFI library error building GHC
by member MP2E 20 Sep '14

20 Sep '14

Yep, I reported this same build error for NixOS on x86_64, unfortunately I haven't found any way to solve it. Reverting the commit that upgrades to libffi-3.1 still showed this issue. I'd love to see this fixed, as I am unable to do any development on GHC until it's fixed :( On Sat, Sep 20, 2014 at 3:15 AM, Moritz Angermann <moritz(a)lichtzwerge.de> wrote: > Could you check if you had any other libffi.a or (any other .a) file for > that matter in the > libffi folder? I have the suspicion that the new libffi builds the > archives for some platforms into different target folders, as someone on > irc mentioned that for nix, there was a lib64 folder or so, and hence the > libffi.a was in libffi/build/inst/lib64/libffi.a iirc. > > On Sep 20, 2014, at 8:13 AM, David Feuer <david.feuer(a)gmail.com> wrote: > > > I keep getting this error. Can anyone help? I tried removing the file as > suggested, but it made no difference. > > > > "/home/dfeuer/GHC/7.8.3.bin/bin/ghc" -o > utils/genapply/dist/build/tmp/genapply -hisuf hi -osuf o -hcsuf hc > -static -O -H64m -package pretty -package-db libraries/bootstrapping.conf > -i -iutils/genapply/. -iutils/genapply/dist/build > -iutils/genapply/dist/build/autogen -Iutils/genapply/dist/build > -Iutils/genapply/dist/build/autogen -no-user-package-db -rtsopts > -odir utils/genapply/dist/build -hidir utils/genapply/dist/build -stubdir > utils/genapply/dist/build -static -O -H64m -package pretty -package-db > libraries/bootstrapping.conf -i -iutils/genapply/. > -iutils/genapply/dist/build -iutils/genapply/dist/build/autogen > -Iutils/genapply/dist/build -Iutils/genapply/dist/build/autogen > -no-user-package-db -rtsopts utils/genapply/dist/build/GenApply.o > > libffi/stamp.ffi.static-shared.install exists, but > libffi/build/inst/lib/libffi.a does not. > > Suggest removing libffi/stamp.ffi.static-shared.install. > > make[1]: *** [libffi/build/inst/lib/libffi.a] Error 1 > > make[1]: *** Waiting for unfinished jobs.... > > make: *** [all] Error 2 > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs(a)haskell.org > > http://www.haskell.org/mailman/listinfo/ghc-devs > > ————————————————— > Moritz Angermann > +49 170 54 33 0 74 > moritz(a)lichtzwerge.de > > lichtzwerge GmbH > Freisinger Landstr. 25 > 85748 Garching b. München > > Amtsgericht München HRB 207882 > Geschäftsführung: Moritz Angermann, Ralf Sangl > USt-Id: DE291948767 > > Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte > Informationen. Wenn Sie nicht der richtige Adressat sind oder diese > E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den > Absender und vernichten Sie diese Mail. > Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail > ist nicht gestattet. > This e-mail may contain confidential and/or privileged information. > If you are not the intended recipient (or have received this e-mail in > error) please notify the sender immediately and destroy this e-mail. > Any unauthorized copying, disclosure or distribution of the material in > this e-mail is strictly forbidden. > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs >

2 2

Where can I stick a dead code elimination rule for quotRemInt#?
by David Feuer 19 Sep '14

19 Sep '14

As I describe in #9617, GHC's CSE in 7.9 seems to be good enough to let Int and Integer use quot x y = fst (x `quotRem` y) rem x y = snd (x `quotRem` y) And actually get good results in code that uses both the quotient and the remainder. I believe the only thing left to be able to actually implement this is a simple rule to turn a match on quotRemInt# into one on quotInt# or remInt# if only the quotient or only the remainder is used. My question is where I could stick such a rule. Can anyone advise me? All I know is that it has to happen after CSE.

1 0

RE: Volatile T4801 test
by Simon Peyton Jones 19 Sep '14

19 Sep '14

Agreed. Let's remove the max_bytes_used threshold from the test. Simn | -----Original Message----- | From: Herbert Valerio Riedel [mailto:hvriedel@gmail.com] | Sent: 19 September 2014 16:02 | To: Simon Peyton Jones; Austin Seipp | Subject: Volatile T4801 test | | Hello! | | If you look at | | https://phabricator.haskell.org/diffusion/GHC/history/ | | the four of the recent commits failed mostly due to the volatilness of | T4801; I've seen it fail myself in Phab code-revisions as well... | | What shall we do about T4801, it seems to create unnecessary noise, as | any build-failure raises alarm flags for no good reason (imho)... | | Cheers, | hvr

1 0

Re: [commit: ghc] master's head updated: Add default case (fixes -Werror) (4d90e44)
by Gabor Greif 19 Sep '14

19 Sep '14

Dear devs, I must admit I screwed this up again, I wanted to push on my branch git push darcs 4d90e44101559800947ce3cd7fd8704dc520b332:wip/generics-propeq-conservative but muscle memory betrayed me and I pushed like this: git push darcs 4d90e44101559800947ce3cd7fd8704dc520b332:master Sorry for the messup. How can I repair this? I did not intend to "merge" my work yet. It is not totally wrong though. It has three failures, but they are okay. I have a commit in my tree for that, but my firewall won't let them out (they are more than a kilobyte :-( The changes should be reviewed on the branch, and some changes are still expected. Second thought, how could this happen? Was this just a fast-forward of "master" ? Git seems to be a dangerous tool. Cheers and all help welcome, (also review comments regarding this WIP), remorsefully, Gabor On 9/19/14, git(a)git.haskell.org <git(a)git.haskell.org> wrote: > Repository : ssh://git@git.haskell.org/ghc > > Branch 'master' now includes: > > e12a6a8 Propositional equality for Datatype meta-information > 0a8e6fc Make constructor metadata parametrized (with intended parameter > <- datatype) > f097b77 Implement sameConstructor > cc618e6 get roles right and fix a FIXME > 79c7125 Actually parametrize the Constructor with the Datatype > 7bd4bab Supply a reasonable name (should be derived from d_name tho) > 09fcd70 Use 'd_name' as the name (should be derived from d_name tho) > 4d90e44 Add default case (fixes -Werror) > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

3 4

Problems with updating Phab revision using arcanist
by Jan Stolarek 19 Sep '14

19 Sep '14

Hi all, I have a question to Phab gurus about using arcanist. I created a git branch, hacked a bit and then submitted a review using `arc diff`. Then I make a few more commits and want to update my revision. Running `arc diff` opens up an editor where I can create a new revision. Obviously, that's not what I want so I follow the suggestion from the comment in the editor to use `--update`: # arc diff --update D202 Exception Can't parse an empty diff! (Run with --trace for a full exception trace.) That's not what I want either. I'm left with manually specifying the base commit: arc diff 1719c42 and that works. But that's not really convenient. Any ideas why neither `arc diff` nor `arc diff --update <rev>` don't work (I believe they should)? Janek

1 0

Should we occasionally merge haddock master into ghc-head?
by Edward Z. Yang 19 Sep '14

19 Sep '14

Hello Mateusz and all, With ghc-head and master being developed concurrently, I am wondering if GHC developers should be allowed to occasionally merge in changes from master. Seems like a good service which would help Mateusz out a bit when it comes time to update master for the next version GHC. Or is there some reason we shouldn't do this? Cheers, Edward

2 2

RE: D202: Injective type families
by Simon Peyton Jones 18 Sep '14

18 Sep '14

Dear GHC devs I'm sure I should know this, but if I want to build a Phab patch, to reproduce some issue (example below). How would I do that? If Phabs were branches in the GHC repo I could say Git checkout phab/D202 That would be cool. I know how to do that. But I don't think they are. So what do I do? Simon | -----Original Message----- | From: noreply(a)phabricator.haskell.org | [mailto:noreply@phabricator.haskell.org] | Sent: 18 September 2014 09:35 | To: Simon Peyton Jones | Subject: [Differential] [Commented On] D202: Injective type families | | jstolarek added a comment. | | I made two important adjustments: | | - first of all I removed the `result` from the parser and lexer. | Instead of `result` I'm planning to use type variable introduced by | the user for the result (as described in [[ | https://ghc.haskell.org/trac/ghc/wiki/InjectiveTypeFamilies#Proposal7 | | Proposal 7 ]] on the wiki. | | - following Richard's suggestion I changed `InjectivityInfo` to | contain `[Located name]` instead of `[LHsType name]`. But I keep | getting "Not in scope" errors. When I try to compile: | ``` | type family F a :: r | r -> a where | F a = a | ``` | I get errors that `r` and `a` are not in scope. According to my | tracing line 1149 of RnSource.lhs is responsible for this. I looked at | other code in this module and it seems to me that `bindHsTyVars` | should bring these variables into scope when renaming `r -> a`. I have | no idea why this does not happen. Simon, help? | | Also, build error reported by Harbormaster is nonsense. | | REPOSITORY | rGHC Glasgow Haskell Compiler | | REVISION DETAIL | https://phabricator.haskell.org/D202 | | REPLY HANDLER ACTIONS | Reply to comment, or !reject, !abandon, !reclaim, !resign, !rethink, | !unsubscribe. | | To: jstolarek, simonpj, austin | Cc: goldfire, simonmar, ezyang, carter

2 1

Equality check for types that respects type families? (#9582)
by Andreas Abel 18 Sep '14

18 Sep '14

Looking at bug #9582 Associated Type Synonyms do not unfold in InstanceSigs https://ghc.haskell.org/trac/ghc/ticket/9582 I found that the given type in an instance signature is compared to the expected type using Type.eqType, which does not seem to know about type families. https://github.com/ghc/ghc/blob/master/compiler/typecheck/TcInstDcls.lhs -- Check that any type signatures have exactly the right type check_inst_sig hs_ty@(L loc _) = setSrcSpan loc $ do { sig_ty <- tcHsSigType (FunSigCtxt sel_name) hs_ty ; inst_sigs <- xoptM Opt_InstanceSigs ; if inst_sigs then unless (sig_ty `eqType` local_meth_ty) (badInstSigErr sel_name local_meth_ty) ... https://github.com/ghc/ghc/blob/master/compiler/types/Type.lhs eqType :: Type -> Type -> Bool -- ^ Type equality on source types. Does not look through @newtypes@ or -- 'PredType's, but it does look through type synonyms. -- Watch out for horrible hack: See Note [Comparison with OpenTypeKind] Question: Is there a (monadic) function for checking type equality which knows about the current type family rules in scope and honors them? Maybe the better question is where to find it, since there should be such a beast (used in the type checker somewhere to compare expected with inferred types). Cheers, Andreas (new to the GHC source code) -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel(a)gu.se http://www2.tcs.ifi.lmu.de/~abel/

1 1

Re: Remove special casing of singleton strings, split all strings, Re: Implement `decodeDouble_Int64#` primop
by Joachim Breitner 17 Sep '14

17 Sep '14

Hi, Am Dienstag, den 16.09.2014, 12:59 +0000 schrieb git(a)git.haskell.org: > commit fe9f7e40844802443315ef2238c4cdefda756b62 > Author: Thijs Alkemade <thijsalkemade(a)gmail.com> > Date: Tue Sep 16 07:55:34 2014 -0500 > > Remove special casing of singleton strings, split all strings. > > Summary: > exprIsConApp_maybe now detects string literals and correctly > splits them. This means case-statemnts on string literals can > now push the literal into the cases. if you are curious: This improves the runtime of the binary-trees nofib benchmark by 6% and reduces the size of the parstof nofib benchmark by 4.6%, although on average, binary sizes are increased by a very small amount (0.12%). There is a notable increase in allocations in bspt, cacheprof and gg (>3%). Details: http://ghcspeed-nomeata.rhcloud.com/changes/?rev=fe9f7e4084&exe=2&env=1 Am Mittwoch, den 17.09.2014, 15:58 +0000 schrieb git(a)git.haskell.org: > commit b62bd5ecf3be421778e4835010b6b334e95c5a56 > Author: Herbert Valerio Riedel <hvr(a)gnu.org> > Date: Wed Sep 17 17:54:20 2014 +0200 > > Implement `decodeDouble_Int64#` primop > > The existing `decodeDouble_2Int#` primop is rather inconvenient to use > (and in fact is not even used by `integer-gmp`) as the mantissa is split > into 3 components which would actually fit in an `Int64#` value. > > However, `decodeDouble_Int64#` is to be used by the new `integer-gmp2` > re-implementation (see #9281). > > Moreover, `decodeDouble_2Int#` performs direct bit-wise operations on the > IEEE representation which can be replaced by a combination of the > portable standard C99 `scalbn(3)` and `frexp(3)` functions. This commit undoes the improvement of binary-trees’s runtime (4.6% regression), but no other notable changes. Again, I leave it to the respective commiters to decide if any of this is worth investigating. See http://ghcspeed-nomeata.rhcloud.com/timeline/?exe=2&base=2%2B68&ben=nofib%2… for the history of that particular benchmark. Greetings, Joachim -- Joachim Breitner e-Mail: mail(a)joachim-breitner.de Homepage: http://www.joachim-breitner.de Jabber-ID: nomeata(a)joachim-breitner.de

1 0