T11758 testcase help needed
Hi, all! I was working on #11758, which is about dropping binutils<2.17 hack, and while it was relatively easy to remove the hack itself, I'm not sure how to add a test case for it. As I understand, after removing the aforementioned hack, native codegen now shouldn't generate sign extension. So my question is how to test it? Should it be Cmm file that will be tested with `compile_cmp_asm` like memcpy in "codeGen/should_gen_asm/memcpy.cmm"? Or should I stick to the Haskell test? Thanks, Alex Dzyoba ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
first unboxed sums patch is ready for reviews
Hi all, I'm almost done with the unboxed sums patch and I'd like to get some reviews at this point. https://phabricator.haskell.org/D2259 Two key files in the patch are UnariseStg.hs and RepType.hs. For the example programs see files in testsuite/tests/unboxedsums/ In addition to any comments about the code and documentation, it'd be appreciated if you tell me about some potential uses of unboxed sums, example programs, edge cases etc. so that I can test it a bit more and make sure the generated code is good. Thanks, Omer ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: T11758 testcase help needed
I am not sure if this will work, but how about dumping the assembly and looking for sign extension? C-- might be easier! Excerpts from Alex Dzyoba's message of 2016-07-09 08:25:39 -0400: > Hi, all! > > I was working on #11758, which is about dropping binutils<2.17 hack, and while > it was relatively easy to remove the hack itself, I'm not sure how to add a > test case for it. > > As I understand, after removing the aforementioned hack, native codegen now > shouldn't generate sign extension. So my question is how to test it? Should it > be Cmm file that will be tested with `compile_cmp_asm` like memcpy in > "codeGen/should_gen_asm/memcpy.cmm"? Or should I stick to > the Haskell test? > > Thanks, > Alex Dzyoba ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: Windows build
Hi Simon, Thomie changed it so the in place gcc can be called from the testsuite. The tests should pass now. Kind regards, Tamar Sent from my Mobile On Jul 8, 2016 23:02, wrote: > Hi Simon, > > > > For these tests it shouldn’t matter much so I guess I can change them. > > > > The Windows Build guide does ask to put /mingw64/bin/ on your path. > > The reason I tend not to want to use GHC to compile my c files for the > tests is that GHC doesn’t just pass the commands along to gcc. > > It adds to them. While for these single object files it doesn’t matter (as > it just adds a few defines and include paths) It has bitten me multiple > times in the past. Particularly when compiling shared libraries for tests > since GHC wants to link in the RTS, which makes the files considerably > larger and harder to debug so > > I tend to avoid using GHC to compile just pure C code. > > > > It means (with shared libraries) that I’ll end up with multiple RTSs > loaded (at least in memory, which means stepping in gdb I have to keep > track of the memory locations so I know which one I’m in). So I really wish > there was a way to tell GHC not to do this. > > > > Also you’ll likely be linking against libraries compiled against other > versions of GCC or MSVC so that shouldn’t be an issue. > > > > I’ll change the tests tomorrow, but I would much prefer if the testsuite > can tell me where the GCC to use is, so I don’t have to use GHC. > > > > Regards, > > Tamar > > > > *From: *Simon Peyton Jones via ghc-devs > *Sent: *Friday, July 8, 2016 22:27 > *To: *ghc-devs@haskell.org > *Subject: *Windows build > > > > I’ve completed a successful build on my Surface Book! Thank you. > > > > One last glitch. I’m getting the validate failure bellow. > > > > No other test requires gcc in my path. GHC itself carefully navigates to > its own private gcc. Do we really want this family of tests (half a dozen > variants of T11223) to rely on some random gcc, which might or might not be > the same as GHC is using? Shouldn’t we use ‘ghc foo.c’? > > > > Simon > > > > => T11223_simple_unused_duplicate_lib(normal) 3371 of 5211 [0, 6, 1] > > cd "/c/Users/simonpj/AppData/Local/Temp/ghctest-hFCtmi/test > spaces/./rts/T11223/T11223_simple_unused_duplicate_lib.run" && $MAKE -s > --no-print-directory t_11223_simple_unused_duplicate_lib > > Wrong exit code (expected 0 , actual 2 ) > > Stdout: > > > > Stderr: > > /bin/sh: gcc: command not found > > make[2]: *** [Makefile:42: t_11223_simple_unused_duplicate_lib] Error 127 > > > > > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Rethinking GHC's approach to managing proposals
Hello everyone, Recently there has been a fair bit of discussion[1,2] around the mechanisms by which proposed changes to GHC are evaluated. While we have something of a formal proposal protocol [3], it is not clearly documented, inconsistently applied, and may be failing to serve a significant fraction of GHC's potential contributor pool. Over the last few weeks, I have been doing a fair amount of reading, thinking, and discussing to try to piece together a proposal scheme which better serves our community. The resulting proposal [4] is strongly inspired by the RFC process in place in the Rust community [5], the leaders of which have thought quite hard about fostering community growth and participation. While no process is perfect, I feel like the Rust process is a good starting point for discussion, offering enough structure to guide new contributors through the process while requiring only a modest investment of developer time. To get a sense for how well this will work in our community, I propose that we attempt to self-host the proposed process. To this end I have setup a ghc-proposals repository [6] and opened a pull request for discussion of the process proposal [4]. Let's see how this goes. Cheers, - Ben [1] https://www.reddit.com/r/haskell/comments/4oyxo2/blog_contributing_to_ghc/ [2] https://www.reddit.com/r/haskell/comments/4isua9/ghc_development_outsidein/ [3] https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/AddingFeatures [4] https://github.com/ghc-proposals/ghc-proposals/pull/1/files?short_path=14d66cd#diff-14d66cda32248456a5f223b6333c6132 [5] https://github.com/rust-lang/rfcs [6] https://github.com/ghc-proposals/ghc-proposals signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
