RE: C-- specfication
Thank you Arash! Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Arash | Rouhani | Sent: 04 May 2014 19:54 | To: Andrew Farmer | Cc: ghc-devs@haskell.org | Subject: Re: C-- specfication | | Hi Andrew, | | Thanks for the encouragement! :) | | I went ahead and updated the wiki and incorporated my links. I also gave | some more guidelines for each link. [1] | | Cheers, | Arash | | | | [1]: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Cmm | | On 2014-05-04 16:53, Andrew Farmer wrote: | Are all of these links collected on the GHC wiki somewhere? If not, | would you mind adding them? | | I, for one, appreciate a curated list of references like this! | | On Sat, May 3, 2014 at 5:33 AM, Arash Rouhani | rar...@student.chalmers.se wrote: | (Sorry Florian, I forgot to reply to list!) | | Hi Florian! | | Forget Cminusminus.org, in my experience it seems to have diverged | from the GHC version of Cminusminus. | | I would recommend these resources | | See the top of | https://github.com/ghc/ghc/blob/master/compiler/cmm/CmmParse.y | Be ready to occasionally look into | https://github.com/ghc/ghc/blob/master/includes/Cmm.h | Edward Yang's blog post is a must-read | http://blog.ezyang.com/2013/07/no-grammar-no-problem/ (less than a | year old) You can also get the big picture of Cmm from David Terei's | bachelor thesis: | https://davidterei.com/downloads/papers/terei:2009:honours_thesis.pdf | 2 years ago, Simon Marlow extended the classical Cmm syntax to make | it much | nicer: | https://github.com/ghc/ghc/commit/a7c0387d20c1c9994d1100b14fbb8fb4e28 | a259e The commentary (it is kinda outdated in my experience, but | worth taking a look :)), | https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Cmm and | https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/CmmType | Read the code! There's a lot of Cmm files and after looking at | various parts of it for a while parts start to make sense :) | Shameless plug: You might find sections 4.2 and 4.2.1 from my master | thesis helpful to understand the difference between arguments and | fields. | http://arashrouhani.com/papers/master-thesis.pdf | | And it will take time to learn Cmm. The most unintuitive thing for me | that took me a while to understand is that there are no function | calls in classical cmm code. The newer syntax allows function calls | but you should know that they are kind of magical. Hope this helps! | :) | | (Sorry for giving so many reading references :p) | | Cheers, | Arash | | | | On 2014-05-03 12:05, Florian Weimer wrote: | | I'm looking for a specification of C--. I can't find it on the | cminuscminus.org web site, and it's also not included in the release | tarball. Does anybody know where to get it? | ___ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs | | | | ___ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs | | | ___ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Adding a dependency to the build system
Hi, Today I have split Haddock up a little to allow users to use the Haddock parser without incurring the dependency on GHC. This means the Haddock tree looks like this now: haddock/haddock.cabal haddock/src/… haddock/haddock-library/haddock-library.cabal haddock/haddock-library/src/… haddock/haddock-library/… haddock/… For details see [1]. In the haddock.cabal, we now depend on haddock-library. While this works fine in a regular development scenario, GHC build system needs to be made aware that it has to build haddock/haddock-library before haddock/. I tried looking at the build system but it is far too complicated to comprehend in a reasonable amount of time. Can someone already familiar with it make the change (in a separate branch or give me the diff so I can push the Haddock changes while at the same time updating submodule + build system) or tell me what exactly needs changing? haddock-library only uses a subset of Haddock's existing dependencies so there should be no problem on that end. A workaround would be to simply include haddock-library paths as additional source locations but I don't like it this approach as it breaks the ‘haddock-library is its own package’ abstraction. For example, this would not work if we ever wanted to move haddock-library to its own repository. Thanks! [1]: https://github.com/Fuuzetsu/haddock/tree/parser-split -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
cgrun051
I'm getting Unexpected failures: . cgrun051 [bad exit code] (normal,hpc,optasm,profasm,ghci,threaded1,threaded2,dyn,profthreaded,optllvm,g1) = cgrun051(optasm) 46 of 98 [0, 2, 0] cd . '/5playpen/simonpj/HEAD-2/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o cgrun051 cgrun051.hs -O -fasm cgrun051.comp.stderr 21 cd . ./cgrun051/dev/null cgrun051.run.stdout 2cgrun051.run.stderr Wrong exit code (expected 0 , actual 1 ) cgrun051 throws an exception, so presumably should have exit code 1. And it does. But the test seems to test for exit code 0. Why does the test check for 0 not 1? And what has changed? This is HEAD. I don't have a virgin head right now, but I don't think any of my changes could cause this. I am also seeing the ffi/should_compile cc004 [stderr mismatch] (normal) errors that Joachim reported. It'd be great if someone could fix that, whatever it is. SImon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Status updates
Hi all, - The HCAR entry was quickly completed last week thanks to everyone, much appreciated for the quick response! And it made me aware of some other new things in the pipeline, too. :) - Simon is in-progress reviewing the ORF work still. But it's happening, so be patient of course (it's a large patch after all). - After a short discussion last week and a small grace period I killed external core, and removed all traces of it from the GHC tree. We constantly add things to GHC as Richard noted, so removing something was nice, even if a little sad. The result was about 3,000 fewer lines in the source tree. - I need to send a patch upstream to Ross for the AMP changes, but I slacked off a bit since the release of the new transformers got pushed back, pending some discussions on librar...@haskell.org - I'll be sending the results to Ross later today. - I spent some time working on removing the need for a build from creation of the source distribution like I mentioned last week - so 'make sdist' almost works out of the box. I believe it works fine, but it needs some more testing, and I feel like I should float the patch by for review on the list first, Simon in particular might have something to say. Do watch this space. - I'm going to continue working on trying HEAD with Stackage and putting the results somewhere, I just sort of left this as is right now. Also, remember from last week, the 7.8.3 milestone has been shaped up to be what we will look at - please do look over the tickets here when you get a chance! I'll be likely seeing if any new tickets will go here today: https://ghc.haskell.org/trac/ghc/milestone/7.8.3 https://ghc.haskell.org/trac/ghc/query?status=infoneededstatus=mergestatus=newstatus=patchgroup=statusmilestone=7.8.3 Some other things worth noting: - It's time to merge up a lot of the patch queue. I'll be doing that soon - if you floated a patch by and want to discuss it or you want to make me aware of a patch you have, please let me know. At worst you will just inform me of something I already knew. - Side note, since a few people might be keen to know - Herbert took the time this week to move darcs.haskell.org onto a new server, effectively putting it in legacy mode. The switch has not yet happened, because we need to do a DNS switch. That's all, it was pretty light this week for me actually! We didn't actually have a call today yet actually, but we will have one next week and have more to say for sure. Do let me know if you have questions. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Status updates
Hi Austin, Could you consider #9012 for 7.8.3? * Austin Seipp aus...@well-typed.com [2014-05-05 11:54:20-0500] Hi all, - The HCAR entry was quickly completed last week thanks to everyone, much appreciated for the quick response! And it made me aware of some other new things in the pipeline, too. :) - Simon is in-progress reviewing the ORF work still. But it's happening, so be patient of course (it's a large patch after all). - After a short discussion last week and a small grace period I killed external core, and removed all traces of it from the GHC tree. We constantly add things to GHC as Richard noted, so removing something was nice, even if a little sad. The result was about 3,000 fewer lines in the source tree. - I need to send a patch upstream to Ross for the AMP changes, but I slacked off a bit since the release of the new transformers got pushed back, pending some discussions on librar...@haskell.org - I'll be sending the results to Ross later today. - I spent some time working on removing the need for a build from creation of the source distribution like I mentioned last week - so 'make sdist' almost works out of the box. I believe it works fine, but it needs some more testing, and I feel like I should float the patch by for review on the list first, Simon in particular might have something to say. Do watch this space. - I'm going to continue working on trying HEAD with Stackage and putting the results somewhere, I just sort of left this as is right now. Also, remember from last week, the 7.8.3 milestone has been shaped up to be what we will look at - please do look over the tickets here when you get a chance! I'll be likely seeing if any new tickets will go here today: https://ghc.haskell.org/trac/ghc/milestone/7.8.3 https://ghc.haskell.org/trac/ghc/query?status=infoneededstatus=mergestatus=newstatus=patchgroup=statusmilestone=7.8.3 Some other things worth noting: - It's time to merge up a lot of the patch queue. I'll be doing that soon - if you floated a patch by and want to discuss it or you want to make me aware of a patch you have, please let me know. At worst you will just inform me of something I already knew. - Side note, since a few people might be keen to know - Herbert took the time this week to move darcs.haskell.org onto a new server, effectively putting it in legacy mode. The switch has not yet happened, because we need to do a DNS switch. That's all, it was pretty light this week for me actually! We didn't actually have a call today yet actually, but we will have one next week and have more to say for sure. Do let me know if you have questions. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs signature.asc Description: Digital signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Adding atomic primops
Hi John, My understanding is that GHC does do reordering of memory operations, in the CmmSink pass ( http://www.haskell.org/ghc/docs/latest/html/libraries/ghc/src/CmmSink.html, http://blog.ezyang.com/2014/01/so-you-want-to-add-a-new-concurrency-primitive-to-ghc/). In particular ghc may currently reorder loads, although it doesn't seem to reorder stores (at this time). And ghc *currently* only performs these reorderings in limited cases. Thanks! That's a great summary by ezyang and I hadn't yet read it. I have to confess that I don't understand what you mean by suggesting we should implement these primops without having an underlying memory model. Oh, no, I think we should work on getting as close as possible to said memory model. But given how much work it's been for other languages I hope we can pipeline some of the implementation tasks, at the same time as that is going on. For example, we've got one GSOC working on a concurrent data structure, and it would be great if they could have a GHC branch to test inlined primops, even if there is much more work to do to verify the safety of that prototype before it makes it to the master branch. (There's also the social question of getting someone with enough time to do this memory model -- or port it from other languages. Suggestions?) What does atomicReadIntArray# mean if there's no memory model in which its defined? How can you be sure that other ghc hackers won't break some assumptions that the implementations rely upon, if they don't have a memory model to describe how operations should behave? This is strongly related to the TODO: in Johan's proposal: just because that may be true now (I don't know if it is!) doesn't mean it will remain so in the future. I totally agree. I'm just not sure where we should go with it. I think as a practical matter we need some kind of memory model fuzz tester for GHC, since we certainly won't have formal verification throughout the whole compiler. There's been some neat work on this in the memory models community, it seems. It sounds like Jan-Willem also suggests that there should be invasive changes made to the compiler to reify the memory model as a DAG of dependencies on the individual operations. I guess the concrete choice for Johan's proposed changes is to figure out if its possible to quickly hack the relevant CMM passes that might reorder (to be primop aware), rather than make the more general improvement that Jan-Willem suggested in the comments on ezyang's post. Of course, given the limited number of GHC hackers, everything may work out fine in the end. It just seems to me that it would be more sensible to define the semantics first and build the primops around them, rather than primops first and semantics later. I think it's a bit of a chicken and egg, because we need to get interesting enough data structures and libraries to make someone care enough to do this work ;-). I think we need a collaboration with someone who does memory model stuff for a living if we could get them interested or make this into research somehow. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Adding atomic primops
On 04/05/14 11:10, Johan Tibell wrote: I found myself needing atomic operations on basic, mutable numeric values. I wrote a short design doc that I'd like feedback on: https://ghc.haskell.org/trac/ghc/wiki/AtomicPrimops I will try to implement these for 7.10. Right now, all CmmUnsafeForeignCalls (this includes CallishMachOps) are assumed to read and clobber arbitrary memory, so we won't commute reads or writes past them. We could relax this in the future, so the best thing to do would be to write down what semantics you expect (hah, I realise how difficult this is! An informal description will have to suffice.) Cheers, Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC status report
no, i was saying LLVM-General when static linked to llvm doesnt work. I wasnt talking about ghc being dynamic or static merely that theres no way to get llvm-general to work on ghci in 7.6 afaik On Mon, May 5, 2014 at 4:54 PM, Simon Marlow marlo...@gmail.com wrote: I don't see any reason why llvm-general with the shared-llvm flag shouldn't work with a statically linked GHCi (7.6.3 or 7.8 with DYNAMIC_GHC_PROGRAMS=NO). Doesn't it work? On 03/05/14 02:12, Carter Schonwald wrote: if theres a way i can patch llvm-general so that i can use it with llvm static linked into rather than dylinked, i'm all ears! llvm-general has to use some C++ wrappers (that in turn use extern C sections) to make parts of the llvm api accessible from hasskell. I had trouble following some of the thread earlier today, but is the suggestion to try building those wrappers with -fPIC would make them play nice? On Fri, May 2, 2014 at 8:52 PM, Dominick Samperi djsamp...@gmail.com mailto:djsamp...@gmail.com wrote: I posted a ticket related to this (#8371), but the example provided there has no problems today for all versions of ghci that I tested (including 7.6.3), provided -fno-ghci-sandbox is specified. So this problem was clearly related to the threads issue. Today there are problems when DYNAMIC_GHC_PROGRAMS=NO, but they happen later, and I have not yet narrowed this down to a small example. Basically, I have an Haskell app that embeds R (as in the sample code attached to the above ticket), but when it tries to do some calculations it seg faults (works fine with 7.8.2). On Fri, May 2, 2014 at 3:45 PM, Simon Marlow marlo...@gmail.com mailto:marlo...@gmail.com wrote: Can you give me a quick summary of how to reproduce the problem? (not including the GHC build steps) Cheers, Simon On 02/05/14 18:18, Dominick Samperi wrote: I downloaded HEAD and placed DYNAMIC_GHC_PROGRAMS=NO in the quick section of mk/build.mk http://build.mk (with BuildFlavour = quick), and set DYNAMIC_GHC_PROGRAMS=NO in my environment before running configure (just to be sure!). Near the end of the build I saw some messages like Warning: vectorization failure, but the build completed. The status at the end of configure doesn't say that dynamic linking via RTS has been turned off, and I don't know how to check that this is so. Nevertheless, I checked the linking issue and it is NOT fixed with this build, so DYNAMIC_GHC_PROGRAMS=YES is required to prevent the problems reported by me and others. On Fri, May 2, 2014 at 9:09 AM, Simon Marlow marlo...@gmail.com mailto:marlo...@gmail.com wrote: On 02/05/2014 01:09, Dominick Samperi wrote: If I understand your last comment correctly linking to libR should continue to work, even if you revert to static linking of Haskell compiled code via RTS linker. Since you say this is the way things have always been, perhaps the real explanation for why 7.8 fixed the issue is that some bug was fixed along the way... Indeed. To know for sure we would have to test 7.8 with DYNAMIC_GHC_PROGRAMS=NO with your setup - is there a way to do that? Cheers, Simon Note that R is a C library, so the C++ issues that Carter mentions are not a factor here. Thanks, Dominick On Thu, May 1, 2014 at 5:27 PM, Simon Marlow marlo...@gmail.com mailto:marlo...@gmail.com wrote: On 01/05/14 14:48, Dominick Samperi wrote: The problem with some graphics libraries used via FFI (and other libraries that are not thread-safe), if I understand the situation correctly, is that ghci forks a thread when it shouldn't, causing some programs to miscalculate the available stack space (because they think there is only one thread). The new dynamic linking support and the flag -fno-ghci-sandbox fixes this problem, and I would not vote for the removal of these features. So I understand how -fno-ghci-sandbox avoids problems with GUI libraries that use thread-local state. But how is dynamic linking involved here? What improved in GHC 7.8 relative to 7.6 for you? And could you clarify miscalculate the available stack space? What needs to calculate stack space? Why? C stack space? We can certainly make a smoother experience around -fno-ghci-sandbox for using GUI libraries. It is not clear
Re: GHC status report
On 03/05/14 04:15, Dominick Samperi wrote: I'm trying to understand the dynamic linking situation with the help of https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8, and according to this information I need to specify DYNAMIC_GHC_PROGRAMS=YES for ghci to use the system linker. I don't understand why you suggested I test with DYNAMIC_GHC_PROGRAMS=NO? The question I'm trying to answer is what stops working if we use DYNAMIC_GHC_PROGRAMS=NO?. So that's why I'm interested in what happens if you set this option. Thanks for your help! Cheers, Simon Another interesting twist is that my experience under Windows is the opposite of the negative experience described on this page. What I mean by this is more versions of ghci seem to work under Windows (correctly linking to R.dll) than work under Linux! On Fri, May 2, 2014 at 3:45 PM, Simon Marlow marlo...@gmail.com wrote: Can you give me a quick summary of how to reproduce the problem? (not including the GHC build steps) Cheers, Simon On 02/05/14 18:18, Dominick Samperi wrote: I downloaded HEAD and placed DYNAMIC_GHC_PROGRAMS=NO in the quick section of mk/build.mk (with BuildFlavour = quick), and set DYNAMIC_GHC_PROGRAMS=NO in my environment before running configure (just to be sure!). Near the end of the build I saw some messages like Warning: vectorization failure, but the build completed. The status at the end of configure doesn't say that dynamic linking via RTS has been turned off, and I don't know how to check that this is so. Nevertheless, I checked the linking issue and it is NOT fixed with this build, so DYNAMIC_GHC_PROGRAMS=YES is required to prevent the problems reported by me and others. On Fri, May 2, 2014 at 9:09 AM, Simon Marlow marlo...@gmail.com wrote: On 02/05/2014 01:09, Dominick Samperi wrote: If I understand your last comment correctly linking to libR should continue to work, even if you revert to static linking of Haskell compiled code via RTS linker. Since you say this is the way things have always been, perhaps the real explanation for why 7.8 fixed the issue is that some bug was fixed along the way... Indeed. To know for sure we would have to test 7.8 with DYNAMIC_GHC_PROGRAMS=NO with your setup - is there a way to do that? Cheers, Simon Note that R is a C library, so the C++ issues that Carter mentions are not a factor here. Thanks, Dominick On Thu, May 1, 2014 at 5:27 PM, Simon Marlow marlo...@gmail.com wrote: On 01/05/14 14:48, Dominick Samperi wrote: The problem with some graphics libraries used via FFI (and other libraries that are not thread-safe), if I understand the situation correctly, is that ghci forks a thread when it shouldn't, causing some programs to miscalculate the available stack space (because they think there is only one thread). The new dynamic linking support and the flag -fno-ghci-sandbox fixes this problem, and I would not vote for the removal of these features. So I understand how -fno-ghci-sandbox avoids problems with GUI libraries that use thread-local state. But how is dynamic linking involved here? What improved in GHC 7.8 relative to 7.6 for you? And could you clarify miscalculate the available stack space? What needs to calculate stack space? Why? C stack space? We can certainly make a smoother experience around -fno-ghci-sandbox for using GUI libraries. It is not clear to me from Simon's original post how linking to all of those C++ libs can continue to work if dynamic linking is removed in 7.10? Perhaps I misunderstand what you mean by revert to static linking? When I say revert to static linking I mean make GHCi static linked, and have it load Haskell code compiled for static linking using the RTS linker (like it did in 7.6). Foreign libraries would still be loaded using the system linker, as they always have been. To be clear, I'm not officially proposing that we drop dynamic linking, but I think it's worthwhile exploring the design space again, given that we know dynamic linking has been tougher than we expected. Cheers, Simon Thanks, Dominick On Wed, Apr 30, 2014 at 9:26 PM, George Colpitts george.colpi...@gmail.com wrote: To elaborate, in the past, I had a lot of problems using libraries from the ghci prompt on the Mac but I haven't tried recently. As an example, on the web page for the book the Haskell School of Expression it says: Note for OS X users: running graphics applications from GHCi is no longer supported. Instead, one has to compile a graphics program using GHC in order to run it (see example/GMIExamples.lhs for an example). I had similar problems using the Yale Euterpea music program from ghci. When I inquired I was referred to https://ghc.haskell.org/trac/ghc/ticket/4244 and https://ghc.haskell.org/trac/ghc/ticket/781. I see that the latter is now scheduled for 7.10.1 On Wed, Apr 30, 2014 at 1:45 PM, Simon Marlow marlo...@gmail.com wrote: On 30/04/2014 01:35, George Colpitts wrote: It doesn't
Re: GHC status report
On 05/05/14 21:58, Carter Schonwald wrote: no, i was saying LLVM-General when static linked to llvm doesnt work. I wasnt talking about ghc being dynamic or static I believe you that it doesn't work. But I think that if you use a dynamically-linked llvm (i.e. the shared-llvm flag), it *should* work, even with 7.6.3. What goes wrong in that case? Cheers, Simon merely that theres no way to get llvm-general to work on ghci in 7.6 afaik On Mon, May 5, 2014 at 4:54 PM, Simon Marlow marlo...@gmail.com mailto:marlo...@gmail.com wrote: I don't see any reason why llvm-general with the shared-llvm flag shouldn't work with a statically linked GHCi (7.6.3 or 7.8 with DYNAMIC_GHC_PROGRAMS=NO). Doesn't it work? On 03/05/14 02:12, Carter Schonwald wrote: if theres a way i can patch llvm-general so that i can use it with llvm static linked into rather than dylinked, i'm all ears! llvm-general has to use some C++ wrappers (that in turn use extern C sections) to make parts of the llvm api accessible from hasskell. I had trouble following some of the thread earlier today, but is the suggestion to try building those wrappers with -fPIC would make them play nice? On Fri, May 2, 2014 at 8:52 PM, Dominick Samperi djsamp...@gmail.com mailto:djsamp...@gmail.com mailto:djsamp...@gmail.com mailto:djsamp...@gmail.com wrote: I posted a ticket related to this (#8371), but the example provided there has no problems today for all versions of ghci that I tested (including 7.6.3), provided -fno-ghci-sandbox is specified. So this problem was clearly related to the threads issue. Today there are problems when DYNAMIC_GHC_PROGRAMS=NO, but they happen later, and I have not yet narrowed this down to a small example. Basically, I have an Haskell app that embeds R (as in the sample code attached to the above ticket), but when it tries to do some calculations it seg faults (works fine with 7.8.2). On Fri, May 2, 2014 at 3:45 PM, Simon Marlow marlo...@gmail.com mailto:marlo...@gmail.com mailto:marlo...@gmail.com mailto:marlo...@gmail.com wrote: Can you give me a quick summary of how to reproduce the problem? (not including the GHC build steps) Cheers, Simon On 02/05/14 18:18, Dominick Samperi wrote: I downloaded HEAD and placed DYNAMIC_GHC_PROGRAMS=NO in the quick section of mk/build.mk http://build.mk http://build.mk (with BuildFlavour = quick), and set DYNAMIC_GHC_PROGRAMS=NO in my environment before running configure (just to be sure!). Near the end of the build I saw some messages like Warning: vectorization failure, but the build completed. The status at the end of configure doesn't say that dynamic linking via RTS has been turned off, and I don't know how to check that this is so. Nevertheless, I checked the linking issue and it is NOT fixed with this build, so DYNAMIC_GHC_PROGRAMS=YES is required to prevent the problems reported by me and others. On Fri, May 2, 2014 at 9:09 AM, Simon Marlow marlo...@gmail.com mailto:marlo...@gmail.com mailto:marlo...@gmail.com mailto:marlo...@gmail.com wrote: On 02/05/2014 01:09, Dominick Samperi wrote: If I understand your last comment correctly linking to libR should continue to work, even if you revert to static linking of Haskell compiled code via RTS linker. Since you say this is the way things have always been, perhaps the real explanation for why 7.8 fixed the issue is that some bug was fixed along the way... Indeed. To know for sure we would have to test 7.8 with DYNAMIC_GHC_PROGRAMS=NO with your setup - is there a way to do that? Cheers, Simon Note that R is a C library, so the C++ issues that Carter mentions are not a factor here. Thanks, Dominick On Thu, May 1, 2014 at 5:27 PM,
Re: GHC status report
I think the issue is really loading static C++ libs into GHCi doesn't work properly, and that's true of all versions of GHC, including 7.8. On 05/05/14 22:08, Carter Schonwald wrote: i don't have 7.6 setup anymore, i'll see about reproducing the issue later. it falls under the umbrella of linking not working in ghci, But it could be that didn't try the -fshared-llvm + ghci in 7.6 On Mon, May 5, 2014 at 5:01 PM, Simon Marlow marlo...@gmail.com mailto:marlo...@gmail.com wrote: On 05/05/14 21:58, Carter Schonwald wrote: no, i was saying LLVM-General when static linked to llvm doesnt work. I wasnt talking about ghc being dynamic or static I believe you that it doesn't work. But I think that if you use a dynamically-linked llvm (i.e. the shared-llvm flag), it *should* work, even with 7.6.3. What goes wrong in that case? Cheers, Simon merely that theres no way to get llvm-general to work on ghci in 7.6 afaik On Mon, May 5, 2014 at 4:54 PM, Simon Marlow marlo...@gmail.com mailto:marlo...@gmail.com mailto:marlo...@gmail.com mailto:marlo...@gmail.com wrote: I don't see any reason why llvm-general with the shared-llvm flag shouldn't work with a statically linked GHCi (7.6.3 or 7.8 with DYNAMIC_GHC_PROGRAMS=NO). Doesn't it work? On 03/05/14 02:12, Carter Schonwald wrote: if theres a way i can patch llvm-general so that i can use it with llvm static linked into rather than dylinked, i'm all ears! llvm-general has to use some C++ wrappers (that in turn use extern C sections) to make parts of the llvm api accessible from hasskell. I had trouble following some of the thread earlier today, but is the suggestion to try building those wrappers with -fPIC would make them play nice? On Fri, May 2, 2014 at 8:52 PM, Dominick Samperi djsamp...@gmail.com mailto:djsamp...@gmail.com mailto:djsamp...@gmail.com mailto:djsamp...@gmail.com mailto:djsamp...@gmail.com mailto:djsamp...@gmail.com mailto:djsamp...@gmail.com mailto:djsamp...@gmail.com wrote: I posted a ticket related to this (#8371), but the example provided there has no problems today for all versions of ghci that I tested (including 7.6.3), provided -fno-ghci-sandbox is specified. So this problem was clearly related to the threads issue. Today there are problems when DYNAMIC_GHC_PROGRAMS=NO, but they happen later, and I have not yet narrowed this down to a small example. Basically, I have an Haskell app that embeds R (as in the sample code attached to the above ticket), but when it tries to do some calculations it seg faults (works fine with 7.8.2). On Fri, May 2, 2014 at 3:45 PM, Simon Marlow marlo...@gmail.com mailto:marlo...@gmail.com mailto:marlo...@gmail.com mailto:marlo...@gmail.com mailto:marlo...@gmail.com mailto:marlo...@gmail.com mailto:marlo...@gmail.com mailto:marlo...@gmail.com wrote: Can you give me a quick summary of how to reproduce the problem? (not including the GHC build steps) Cheers, Simon On 02/05/14 18:18, Dominick Samperi wrote: I downloaded HEAD and placed DYNAMIC_GHC_PROGRAMS=NO in the quick section of mk/build.mk http://build.mk http://build.mk http://build.mk (with BuildFlavour = quick), and set DYNAMIC_GHC_PROGRAMS=NO in my environment before running configure (just to be sure!). Near the end of the build I saw some messages like Warning: vectorization failure, but the build completed. The status at the end of configure doesn't say that dynamic linking via RTS has been turned off, and I don't know how to check that this is so.
Re: Adding atomic primops
Hey Johan, Superficial comments for now. Are you planning on supporting word variants? Callish mach-ops, as generated from primops, are not sunk across, but this behavior today is accidental (see Note [Foreign calls clobber heap]), so be sure to adjust the notes. Edward Excerpts from Johan Tibell's message of 2014-05-04 03:10:12 -0700: Hi, I found myself needing atomic operations on basic, mutable numeric values. I wrote a short design doc that I'd like feedback on: https://ghc.haskell.org/trac/ghc/wiki/AtomicPrimops I will try to implement these for 7.10. -- Johan ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
