A follow-up on this.
On 20/09/2013 16:33, David Matthews wrote:
On 20/09/2013 08:59, Anthony Fox wrote:
- I?ve noticed a change in evaluation behaviour between PolyML 5.5.0
and 5.5.1. Given the functions:
fun foo () = let val () = print "x\n" in SOME end
fun bar f = List.mapPartial (Option.compose (Int.~, f ())) [1, 2, 3]
then under 5.5.0 ?bar foo? gives us
x val it = [~1, ~2, ~3]: int list
whereas under 5.5.1 we get
x x x val it = [~1, ~2, ~3]: int list
What?s happening here?
This doesn't look good. I need to investigate further but it looks as though a bug has crept in during the work on the intermediate code optimiser.
I've fixed this and another bug that appeared when I disabled the optimisation that was causing the problem. I've ported the fixes to the fixes branch. I'm a bit concerned about this because it's clearly generating incorrect code. Should there perhaps be another release fairly soon?
- I?ve installed Poly/ML 5.5.1 using MacPorts (Mac OS 10.8.5). When
using polyc I get a couple of warning messages, i.e.
$ polyc -o foo foo.o
gives me
ld: warning: could not create compact unwind for _ffi_call_unix64: does not use RBP or RSP based frame ld: warning: PIE disabled. Absolute addressing (perhaps -mdynamic-no-pic) not allowed in code signed PIE, but used in area1 from vimpoly.o. To fix this warning, don't compile with -mdynamic-no-pic or link with -Wl,-no_pie
Is there any way to suppress this? When using cc for linking, one can get rid of these messages by adding
-Wl,-no_compact_unwind,-no_pie
Is this advisable or is there a better solution?
I've done a search on this. It looks as though it has something to do with libffi (_ffi_call_unix64 is certainly part of libffi). I don't know if there's a newer version of libffi around that fixes this.
It's a bit difficult to get any further with this at the moment. The only Mac OS X machine I have access to is running 10.8.0 and that doesn't seem to have the problem.
David