Re: Anyone else failing to validate on 'linker_unload'?

2013-09-01 Thread Austin Seipp
I (think) I see the problem, but maybe I'm just tired and shooting in the dark. The only time checkUnload really iteratively calls free is in CheckUnload.c (I say 'iteratively', because the fact you're touching/freeing blocks inside already free blocks make me suspicious.) The relevant code is: -

Re: Anyone else failing to validate on 'linker_unload'?

2013-09-01 Thread Ryan Newton
Ah, yes I see. Well, giving it the proper arguments when running via valgrind puts me back to an "Invalid read" segfault. I confirmed that the linker_unload executable itself is 64 bit: $ file linker_unload linker_unload: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (u

Re: Anyone else failing to validate on 'linker_unload'?

2013-09-01 Thread Austin Seipp
Oops, should have said this: if you checkout the Makefile for testsuite/tests/rts - at the very bottom - you'll see the linker_unload target. When run, the executable needs some arguments so it knows what to try and load: --- ./linker_unload $(BASE) $(GHC_PRIM) $(INTEGER_GMP) --- So you also need

Re: Anyone else failing to validate on 'linker_unload'?

2013-09-01 Thread Edward Z. Yang
Excerpts from Ryan Newton's message of Sun Sep 01 19:54:34 -0700 2013: > But then when I run it by hand with "./linker_unload" or "valgrind > ./linker_unload" I get an unknown symbol error with exit code 1: Well, that's because that's not what make is running: ./linker_unload $(BASE) $(GHC_PR

Re: Anyone else failing to validate on 'linker_unload'?

2013-09-01 Thread Ryan Newton
Hi Austin, Should have said -- this is 64-bit RHEL 6 (my academic departments standardized configuration). $ uname -a Linux 2.6.32-358.14.1.el6.x86_64 #1 SMP Mon Jun 17 15:54:20 EDT 2013 x86_64 x86_64 x86_64 GNU/Linux Weirdly it seems to have a different behavior when run by "make" and by

Re: Anyone else failing to validate on 'linker_unload'?

2013-09-01 Thread Austin Seipp
I have also not seen this test fail on amd64/Linux since Simon committed it. From the valgrind output, it looks like your machine is 32bit, correct Ryan? Edward told me yesterday on IRC he saw this fail on 64bit Linux, so I'm a little confused. Can you please try this? $ cd testsuite/tests/rts $

Re: Anyone else failing to validate on 'linker_unload'?

2013-09-01 Thread Edward Z. Yang
However, as far as I can tell, it is not 100% reproduceable. In a recent validate of 5f98d44d8617756971cf47c040f2556de4e98f63, this test does not fail. Edward Excerpts from Edward Z. Yang's message of Fri Aug 30 21:55:29 -0700 2013: > Yes, this one is failing for me too. Probably related to the >

Re: [Haskell-cafe] Announcing GHC iOS

2013-09-01 Thread Dominick Samperi
Hello Luke, Thanks for the note. I'm testing on OS X 10.8.4, Xcode 4.6.3, and llvm-gcc 4.2.1 (I placed the scripts directory ghc-ios-scripts-master at the front of PATH). LVM Build is 2336.11.00. I fetched GHC sources and tried to build using: $ git clone git://git.haskell.org/ghc.git $ cd ghc $

Re: [Haskell-cafe] Announcing GHC iOS

2013-09-01 Thread Luke Iannini
Hi Dominick, Hm, this should have been fixed by http://ghc.haskell.org/trac/ghc/ticket/7700 . When you say you downloaded GHC, do you mean you cloned GHC HEAD (e.g. git clone git://git.haskell.org/ghc.git ?) — the patches have only just landed : ). Also can you give us an idea of what your build

Re: [Haskell-cafe] Announcing GHC iOS

2013-09-01 Thread Dominick Samperi
Hi, I followed the instructions on the link, downloaded ghc, created build.mk, etc., and configured for ghc-ios-sim. But the make fails with the message below. Tried installing terminfo (cabal install terminfo) but this didn't help... ghc $ make ===--- building phase 0 make -r --no-print-director

Re: Current state of ghc boot lib versions vs. hackage

2013-09-01 Thread Edward Z. Yang
Hello Jan, As far as I can tell, this should be handled using the standard procedure for externally maintained bootstrap libraries: http://ghc.haskell.org/trac/ghc/wiki/Repositories/Upstream You should coordinate with Roman about this. In the worst case, you can manually make a new (GHC-spe

Re: AMP (#8004) almost finished, review would be nice

2013-09-01 Thread Edward Z. Yang
Have not looked at patch. Excerpts from David Luposchainsky's message of Sun Sep 01 12:23:06 -0700 2013: > 1. Validation does not work due to the warnings issued. Since "sh > validate" uses -Werror, an AMP warning will stop the compilation before > tests can even be run. Unfortunately, the build s

Re: Nightlies not working?

2013-09-01 Thread Jan Stolarek
If you mean the nightly validation runs, then yes - Geoffrey turned them off before leaving MSR. Janek Dnia piątek, 30 sierpnia 2013, Edward Z. Yang napisał: > The last nightly I see is from the 22nd; did they get turned off? > > Edward > > ___ > ghc-d

AMP (#8004) almost finished, review would be nice

2013-09-01 Thread David Luposchainsky
Hey ghc-devs, I finished #8004. The patch introduces a new compiler flag, "-fwarn-amp", that is on by default. The changes are pretty local, affecting TcRnDriver.lhs, PrelNames.lhs and DynFlags.hs, and you can view it here: https://github.com/quchen/ghc/compare/amp_warnings?expand=1 (Note that t

Re: Anyone having trouble with "make install" in HEAD?

2013-09-01 Thread Tuncer Ayaz
On Sun, Sep 1, 2013 at 8:55 PM, Ryan Newton wrote: > Earlier this summer I had no problem with "configure; make; make > install" But recently I'm getting errors like this on GHC HEAD: > > /u/rrnewton/opt/ghc-7.7.20130831/lib/ghc-7.7.20130831/bin/ghc-pkg: error > while loading shared libraries:

Anyone having trouble with "make install" in HEAD?

2013-09-01 Thread Ryan Newton
Earlier this summer I had no problem with "configure; make; make install" But recently I'm getting errors like this on GHC HEAD: /u/rrnewton/opt/ghc-7.7.20130831/lib/ghc-7.7.20130831/bin/ghc-pkg: error while loading shared libraries: libHSbin-package-db-0.0.0 .0-ghc7.7.20130831.so: cannot ope

Re: [Haskell-cafe] Announcing GHC iOS

2013-09-01 Thread Luke Iannini
Thanks! This seems to do the trick wonderfully. -ghclibdir = $(libdir)/ghc-$(ProjectVersion) +ghclibdir = $(libdir)/$(CrossCompilePrefix)ghc-$(ProjectVersion) I've just done a clean build with this and it's working perfectly. On Sat, Aug 31, 2013 at 2:26 PM, Gabor Greif wrote: > On 8/