ANN: Pure 0.33
Albert Graef
uploaded a new bugfix release now:
http://pure-lang.googlecode.com/files/pure-0.33.tar.gz (source)
http://pure-lang.googlecode.com/files/pure-0.33.msi (Windows package)
Here's the blurb from the NEWS file:
** Pure 0.33 2009-08-28
Another bugfix release. This one fixes some more incompatibilities with
latest LLVM revisions and some failed LLVM assertions hit by the
overhauled version of the batch compiler if LLVM was compiled with
--enable-assertions. Moreover, the linkage options were massaged a bit,
reportedly they work better with FreeBSD and FC12 now.
Emacs Pure mode now provides sensible defaults for the location of the
Pure interpreter executable and the library directory if PATH and/or the
PURELIB environment variable are set accordingly. This makes it easier
to install Pure mode on Windows, as you don't have to edit the file any
more if you want to use it with the Pure MSI package.
Enjoy! :)
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.G...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
Albert Graef
updated version.
Albert Graef wrote:
> Well, as some of you noticed, Pure 0.32 had a few issues. So I've
> uploaded a new bugfix release now:
I just wanted to add that the 0.33 release is confirmed to work on
FreeBSD now, as reported by Roman Neuhauser. As Michel Salim reported,
it also works on Fedora Core 11.
Also, post-release, there's a new revision in svn (r2162) to make Pure
work if LLVM was compiled with --enable-expensive-checks, thanks to
Roman Neuhauser for reporting this bug.
There are still some issues with FC12-x86_64 (the current development
branch of Fedora), the dynamic linker there seems to be broken, but this
will hopefully go away as FC12 matures. Unfortunately, the PPC port
seems to be broken, too, I'm working with Michel to fix that.
Ryan, if you have the time, could you please give Pure 0.33 another go
on OSX-PPC and post the log diffs of any failed tests that you see? That
would be helpful to get the PPC kinks ironed out, TIA.
Cheers,
Eddie Rucker
> I just wanted to add that the 0.33 release is confirmed to work on
> FreeBSD now, as reported by Roman Neuhauser. As Michel Salim reported,
> it also works on Fedora Core 11.
Hurray! If I have some time tonight, I'll get a fresh copy of FreeBSD 7.2 installed on Old Clunker.
e.r.
Albert Graef
> Hurray! If I have some time tonight, I'll get a fresh copy of FreeBSD 7.2 installed on Old Clunker.
I thought that you might like that. Also, I've just committed some
changes to svn to make the batch compiler work without llvm-gcc, so
there's no need to install that behemoth any more. ;-)
Eddie Rucker
> I thought that you might like that. Also, I've just committed some
> changes to svn to make the batch compiler work without llvm-gcc, so
> there's no need to install that behemoth any more. ;-)
Even more hurrays :) I never could get llvm-gcc to install properly on Vector Linux, at least on Old Clunker. I just got through installing FreeBSD on old clunker while preparing for my class tomorrow. hopefully I can install LLVM and Pure tonight and still get a little sleep so that I can function at work tomorrow.
e.r.
Ryan Schmidt
I've never gotten llvm-gcc to work right in MacPorts either:
http://trac.macports.org/ticket/20890
So this change means pure-gen won't need llvm-gcc anymore?
Albert Graef
> I've never gotten llvm-gcc to work right in MacPorts either:
>
> http://trac.macports.org/ticket/20890
>
> So this change means pure-gen won't need llvm-gcc anymore?
Exactly. Compiling pure-gen, as of Pure 0.34, now works fine with just a
basic LLVM installation and gcc. (Of course, pure-gen still needs gcc
4.3 or later at *runtime* to preprocess C header files.)
Ryan Schmidt
On Sep 2, 2009, at 04:46, Albert Graef wrote:
> Ryan, if you have the time, could you please give Pure 0.33 another go
> on OSX-PPC and post the log diffs of any failed tests that you see?
> That
> would be helpful to get the PPC kinks ironed out, TIA.
Here are the failed tests for pure 0.34 on Mac OS X 10.4.11 PowerPC:
prelude.pure: passed
test001.pure: FAILED
test002.pure: passed
test003.pure: passed
test004.pure: FAILED
test005.pure: passed
test006.pure: passed
test007.pure: passed
test008.pure: FAILED
test009.pure: FAILED
test010.pure: passed
test011.pure: FAILED
test012.pure: passed
test013.pure: passed
test014.pure: FAILED
test015.pure: FAILED
test016.pure: passed
test017.pure: FAILED
test018.pure: FAILED
test019.pure: FAILED
test020.pure: FAILED
test021.pure: FAILED
test022.pure: passed
test023.pure: FAILED
test024.pure: FAILED
test025.pure: FAILED
test026.pure: passed
test027.pure: passed
test028.pure: passed
test029.pure: passed
test030.pure: passed
test031.pure: passed
test032.pure: passed
test033.pure: passed
test034.pure: FAILED
test035.pure: passed
test036.pure: FAILED
test037.pure: passed
test038.pure: passed
test039.pure: passed
test040.pure: passed
test041.pure: FAILED
test042.pure: FAILED
Albert Graef
> Here are the failed tests for pure 0.34 on Mac OS X 10.4.11 PowerPC:
Is that ppc32 or 64?
Thanks for the logs. I'll try to figure out what's going on there asap.
I certainly want to fix all this mess before Pure 1.0.
Interestingly, OSX/ppc seems to work a lot better than the FC12/ppc port
that I'm currently looking into (Michel thankfully arranged access for
me on one of those machines in the Fedora build farm), which segfaults
on pretty much any nontrivial computation (similar to your OSX x64
tests, but the failure pattern is not identical).
Did you do all these tests with LLVM 2.5, straight from MacPorts? I'm
currently trying to find out whether there are some issues with the ppc
code generator in LLVM 2.5, I vaguely recall having read about this
somewhere.
Ryan Schmidt
> Ryan Schmidt wrote:
>
>> Here are the failed tests for pure 0.34 on Mac OS X 10.4.11 PowerPC:
>
> Is that ppc32 or 64?
It's 32-bit (Power Mac G4 466 MHz "Digital Audio")
> Did you do all these tests with LLVM 2.5, straight from MacPorts? I'm
> currently trying to find out whether there are some issues with the
> ppc
> code generator in LLVM 2.5, I vaguely recall having read about this
> somewhere.
Yes, llvm @2.5_0.
Albert Graef
> Yes, llvm @2.5_0.
Ok, looking at the ports file this means it's configured with
--enable-optimized --enable-jit on ppc32, nothing else. Is that right?
Albert Graef
> On Sep 4, 2009, at 17:36, Albert Graef wrote:
>
>> Ryan Schmidt wrote:
>>
>>> Here are the failed tests for pure 0.34 on Mac OS X 10.4.11 PowerPC:
>> Is that ppc32 or 64?
>
> It's 32-bit (Power Mac G4 466 MHz "Digital Audio")
Ok, it looks like fastcc and/or tail call elimination is what's broken
on ppc, so Pure is ok; LLVM is the culprit. I also tried the latest LLVM
from svn, and it still doesn't work there. When I disable this in the
Pure source, most tests pass just fine. I remember that tail call
elimination just didn't work on ppc in earlier LLVM releases, but it
seems that they have gone from bad to worse: It segfaults now, which
indicates that LLVM generates broken machine code on ppc. :(
Ryan, could you please try whether disabling USE_FASTCC in the Pure
sources helps on OSX/ppc, too? I'm adding a configure option for that
now, but for the time being you can just patch line 44 in
interpreter.hh, so that instead of:
#define USE_FASTCC 1
it reads:
#define USE_FASTCC 0
Could you please try that and report the results of make check?
Thanks,
Albert Graef
> Ryan, could you please try whether disabling USE_FASTCC in the Pure
> sources helps on OSX/ppc, too? I'm adding a configure option for that
Done, see r2208. You can now configure Pure with --disable-fastcc to
disable this option.
http://code.google.com/p/pure-lang/source/detail?r=2208
Ryan Schmidt
On Sep 5, 2009, at 04:48, Albert Graef wrote:
> Ryan Schmidt wrote:
>> Yes, llvm @2.5_0.
>
> Ok, looking at the ports file this means it's configured with
> --enable-optimized --enable-jit on ppc32, nothing else. Is that right?
The llvm portfile in MacPorts doesn't seem to do anything processor-
specific, so --enable-optimized --enable-jit is what's used on all
four Mac OS X architectures.
http://trac.macports.org/browser/trunk/dports/lang/llvm/Portfile?rev=56930#L42
Albert Graef
> The llvm portfile in MacPorts doesn't seem to do anything processor-
> specific, so --enable-optimized --enable-jit is what's used on all
> four Mac OS X architectures.
>
> http://trac.macports.org/browser/trunk/dports/lang/llvm/Portfile?rev=56930#L42
You should really consider to always add --disable-assertions and
--disable-expensive-checks, because leaving these options enabled is a
major performance hog in both the IR builder and the JIT. Even worse,
--enable-expensive-checks makes Pure hit some bogus assertions in LLVM
>= 2.6. I hear that other LLVM applications have issues with these
options, too, and anyway they shouldn't be needed unless you want to
hunt down bugs in LLVM itself.
Meanwhile, I have a new Pure release (0.35) in svn which works fine on
Linux/ppc, so I see no reason why it shouldn't work on OSX/ppc as well.
Could you please give that a try? Instructions are in the system notes
section of the INSTALL file, but here's the gist of it:
- You need LLVM >= 2.6 (pre1 works fine, you can grab this at
http://llvm.org/prereleases/2.6/; trunk works fine, too). LLVM 2.5 won't
work, as it generates broken code for double constants on ppc (symptom
is a failed check in Pure test020). Make sure that you configure LLVM
(at least) with --disable-expensive-checks, otherwise you'll hit the
bogus assertions mentioned above.
- Pure needs to be configured with --disable-fastcc (new configure
option in Pure 0.35). Apparently, LLVM has some code for fastcc and tail
call optimization on ppc now, but it's broken.
Then just run the usual make && make check, hopefully all tests should
pass this time. :)
Cheers,
Albert
Ryan Schmidt
On Sep 6, 2009, at 19:13, Albert Graef wrote:
> You should really consider to always add --disable-assertions and
> --disable-expensive-checks, because leaving these options enabled is a
> major performance hog in both the IR builder and the JIT. Even worse,
> --enable-expensive-checks makes Pure hit some bogus assertions in LLVM
>> = 2.6. I hear that other LLVM applications have issues with these
> options, too, and anyway they shouldn't be needed unless you want to
> hunt down bugs in LLVM itself.
I've filed a ticket requesting the maintainer of our llvm ports make
these changes:
http://trac.macports.org/ticket/21173
> Meanwhile, I have a new Pure release (0.35) in svn which works fine on
> Linux/ppc, so I see no reason why it shouldn't work on OSX/ppc as
> well.
> Could you please give that a try? Instructions are in the system notes
> section of the INSTALL file, but here's the gist of it:
>
> - You need LLVM >= 2.6 (pre1 works fine, you can grab this at
> http://llvm.org/prereleases/2.6/; trunk works fine, too). LLVM 2.5
> won't
> work, as it generates broken code for double constants on ppc (symptom
> is a failed check in Pure test020). Make sure that you configure LLVM
> (at least) with --disable-expensive-checks, otherwise you'll hit the
> bogus assertions mentioned above.
Will pure 0.35 require llvm >= 2.6 everywhere or only on PowerPC?
> - Pure needs to be configured with --disable-fastcc (new configure
> option in Pure 0.35). Apparently, LLVM has some code for fastcc and
> tail
> call optimization on ppc now, but it's broken.
>
> Then just run the usual make && make check, hopefully all tests should
> pass this time. :)
I've filed an update request ticket for the maintainer of our llvm
development-version port:
http://trac.macports.org/ticket/21174
Albert Graef
> Will pure 0.35 require llvm >= 2.6 everywhere or only on PowerPC?
Only on ppc. Pure continues to work fine with LLVM >=2.3, whereever LLVM
works.
> I've filed an update request ticket for the maintainer of our llvm
> development-version port:
>
> http://trac.macports.org/ticket/21174
Great, thanks. But please note that Pure 0.35 does *not* require LLVM
2.6. LLVM 2.5 just doesn't fully work on ppc.
Ryan Schmidt
> You should really consider to always add --disable-assertions and
> --disable-expensive-checks, because leaving these options enabled is a
> major performance hog in both the IR builder and the JIT. Even worse,
> --enable-expensive-checks makes Pure hit some bogus assertions in LLVM
>>
> >= 2.6. I hear that other LLVM applications have issues with these
> options, too, and anyway they shouldn't be needed unless you want to
> hunt down bugs in LLVM itself.
>
> Meanwhile, I have a new Pure release (0.35) in svn which works fine on
> Linux/ppc, so I see no reason why it shouldn't work on OSX/ppc as well.
> Could you please give that a try? Instructions are in the system notes
> section of the INSTALL file, but here's the gist of it:
>
> - You need LLVM >= 2.6 (pre1 works fine, you can grab this at
> http://llvm.org/prereleases/2.6/; trunk works fine, too). LLVM 2.5 won't
> work, as it generates broken code for double constants on ppc (symptom
> is a failed check in Pure test020). Make sure that you configure LLVM
> (at least) with --disable-expensive-checks, otherwise you'll hit the
> bogus assertions mentioned above.
>
> - Pure needs to be configured with --disable-fastcc (new configure
> option in Pure 0.35). Apparently, LLVM has some code for fastcc and tail
> call optimization on ppc now, but it's broken.
>
> Then just run the usual make && make check, hopefully all tests should
> pass this time. :)
Now that llvm in MacPorts has been updated to 2.6, I was able to test this. Using pure 0.36 or trunk r2611, all tests pass now on my Tiger / PowerPC machine, except test017, which fails because pure crashes. See attached crash log.
Note: MacPorts is using --disable-fastcc in pure on PowerPC, and uses --disable-assertions now in llvm as of 2.6. It doesn't explicitly set --disable-expensive-checks, because as our llvm maintainer pointed out to me, that's the default. pure in MacPorts also ensures the user is running a recent-enough llvm (2.4 on Intel, 2.6 on PowerPC).
Albert Graef
> Now that llvm in MacPorts has been updated to 2.6, I was able to test this. Using pure 0.36 or trunk r2611, all tests pass now on my Tiger / PowerPC machine, except test017, which fails because pure crashes. See attached crash log.
Yes, this is because it runs out of stack space in the tail recursion on
'foo'. I can reproduce this here if I compile Pure with --disable-fastcc
(which disables tail call optimization).
It would be interesting to know whether --disable-fastcc is still
needed, or whether the underlying LLVM issue has been fixed in the final
2.6 release. What does 'make check' say when you build Pure without
--disable-fastcc?
Ryan Schmidt
On Nov 17, 2009, at 03:02, Albert Graef wrote:
> Ryan Schmidt wrote:
>
>> Now that llvm in MacPorts has been updated to 2.6, I was able to test this. Using pure 0.36 or trunk r2611, all tests pass now on my Tiger / PowerPC machine, except test017, which fails because pure crashes. See attached crash log.
>
> Yes, this is because it runs out of stack space in the tail recursion on
> 'foo'. I can reproduce this here if I compile Pure with --disable-fastcc
> (which disables tail call optimization).
>
> It would be interesting to know whether --disable-fastcc is still
> needed, or whether the underlying LLVM issue has been fixed in the final
> 2.6 release. What does 'make check' say when you build Pure without
> --disable-fastcc?
Without --disable-fastcc, on llvm 2.6, we're back to half the tests failing [1] with many of them crashing pure.
Did you ever get Mac OS X upgraded to 10.4 or 10.5 on your Power Mac G4? If so it would be easy to get pure and its dependencies up and running on it, by installing Xcode and MacPorts and then running "sudo port -d test pure-devel".
[1]
Running tests.
Albert Graef
> Without --disable-fastcc, on llvm 2.6, we're back to half the tests failing [1] with many of them crashing pure.
Ok, so this hasn't been fixed yet.
> Did you ever get Mac OS X upgraded to 10.4 or 10.5 on your Power Mac G4? If so it would be easy to get pure and its dependencies up and running on it, by installing Xcode and MacPorts and then running "sudo port -d test pure-devel".
I think we already upgraded it, but I never seem to find the time for
setting up the rest of the environment. Anyway, I've already looked into
this on Linux/ppc (we have the same issues there) and I'm pretty sure
that it's a bug in the LLVM JIT, not a bug in Pure.
A quick search on LLVM's bugzilla doesn't seem to turn up anything
useful. So the proper course of action would be to boil it down to a
simple enough LLVM assembler code snippet which exhibits the bug, and
file a problem report on LLVM's bugzilla. But I'm snowed under work
right now, so I don't have the time to do it. :( I still have it on my
TODO list, though.