Re: amd64Translate.Operand.toAMD64Operand: strange Offset: ...

Thanks - that explains it.

I didn't actually use the "Download ZIP" button.  I do all building on a 
large tmpfs (to prolong the life of my SSD and perhaps speed things up) 
so copied the working directory contents but not the .git directory.

Sometimes, to build a specific version of a tool, I use git archive, for 
example:
   mkdir /tmp/src/<dir>/
   git archive <tag|commit> . | tar -x -C /tmp/src/<dir>/
which is like "Download ZIP" and would also omit the .git directory.

I note that the default behaviour using a version based on the initial 7 
digits of the SHA1 hashes doesn't respect version order.  The first 
digit is always 'g' so any check against a dated release version based 
on lexicographic order would pass.  (I use such a check in a custom 
configure script.)  One idea is to generate a version based on the 
commit time in UTC, assuming no more than one per second, for example:
   echo $(date --date "$(git log -n 1 --pretty="format:%cD")" --utc 
+%Y%m%d.%H%M%S)-$(git log -n 1 --pretty="format:%h")

The suggestion:
   make version VERSION=$(...)
   make all
works well but, as you say, the first command only has any effect on a 
fresh copy.


27/09/15 21:45, Matthew Fluet wrote:
> On Sun, Sep 27, 2015 at 12:26 PM, Phil Clayton <[email protected]> wrote:
>> Thanks for the explanation - very interesting!  I've now got the version
>> from master running.  In future I'll work with both master and the last
>> release.  (I've just noticed that the helloworld GTK+ app built with
>> master causes a seg fault when exiting, so I'll investigate.)
>>
>> One question - how do I specify a version name when building from
>> master?  I tried
>>     VERSION=<version> make all
>> but mlton still prints
>>     MLton ???????? ...
>> when run.  I must be missing something obvious.
>
> I don't think that you are missing anything obvious.  The build system
> is a bit convoluted and fragile (updating it to something a little
> more maintainable and robust is not too far down the infinite TODO
> list).
>
> The VERSION variable in the top-level Makefile is really only used for
> constructing file names when packaging releases.
>
> The version string that appears when mlton is invoked with no
> arguments (another TODO: give mlton a proper '-version' flag) is
> generated in the mlton/Makefile:
>    https://github.com/MLton/mlton/blob/master/mlton/Makefile#L68
> This uses 'git log' and 'git status' to determine the last commit; you
> get the '??????' if these git commands fail (e.g., 'git' not on PATH
> or not in a git repository).  I'm guessing that you used GitHub's
> "Download ZIP" button, rather than using 'git clone', leading to not
> in a git repository.
>
> The exception to the use of VERSION in the top-level Makefile is to
> instantiate a few places with a fixed version number:
>    https://github.com/MLton/mlton/blob/master/Makefile#L259
> This is an irreversible operation, so we've generally only done it
> when preparing a source release; see:
>    http://mlton.org/ReleaseChecklist
>    https://github.com/MLton/mlton/blob/master/Makefile#L401
>
> That said, if one wanted to record where/when a "Download ZIP"
> acquired version of mlton came from, then the following would probably
> be the best approach:
>    make version VERSION=git-master-on-20150927
>    make all
> Of course, you should be able to use anything you want for the VERSION string.
>
>> The isNull test is used in my FFI library when converting from a string
>> option value to an optionally-null pointer in C.  In the case NONE is
>> given explicitly, there will be a test 'isNull Pointer.null', so a 'null
>> = null' optimization would remove a little bit of dead code there.
>
> Fair enough; should be easy enough to add.
>
>> 27/09/15 02:25, Matthew Fluet wrote:
>>> On Fri, Sep 25, 2015 at 2:38 PM, Phil Clayton <[email protected]> wrote:
>>>> I was getting the following error when compiling with 20130715:
>>>>
>>>> amd64Translate.Operand.toAMD64Operand: strange Offset: base: $0x0 index:
>>>> MEM<q>{Locals}[(localWord64)+(0x8)]
>>>>
>>>> Sometimes the message reported "...+(0x0)".  I have reduced this to an
>>>> example which is attached.
>>>>
>>>> In the process of reducing it, I found an error in my code - an exception
>>>> would always be raised.  Presumably that is related to this issue because I
>>>> no longer get this error after fixing my code.
>>>
>>> Confirmed with mlton-20130715.  Arguably, it is actually a bug in the
>>> translation to the Machine IL, since compiling with "-type-check true"
>>> gives:
>>>
>>> [matthew@shadow mlton_compiler_issue-20150925-1]$ mlton
>>> MLton 20130715 (built Wed Jul 17 03:58:25 EDT 2013 on shadowvm02)
>>> [matthew@shadow mlton_compiler_issue-20150925-1]$ mlton -type-check
>>> true mlton.mlb
>>> invalid operand: XW8 (NULL, RW64(1): Word64, 1, 0): Word8
>>> invalid statement: RW8(0): Word8  = XW8 (NULL, RW64(1): Word64, 1, 0): Word8
>>> invalid block: L_181: {kind = Jump,
>>>         live = (RW64(0): Word64,
>>>         SP(24): Objptr (opt_8),
>>>         SW64(32): Word64,
>>>         SP(48): Objptr (opt_11),
>>>         SP(40): Objptr (opt_10),
>>>         SP(16): Objptr (opt_9)),
>>>         raises = None,
>>>         returns = Some ()}
>>>     RW32(0): Word32  = WordU64_extdToWord32 (RW64(0): Word64)
>>>     RW64(1): Word64  = WordS32_extdToWord64 (RW32(0): Word32)
>>>     RW8(0): Word8  = XW8 (NULL, RW64(1): Word64, 1, 0): Word8
>>>     XW8 (SP(24): Objptr (opt_8), RW64(0): Word64, 1, 0): Word8
>>>      = RW8(0): Word8
>>>     RW64(2): Word64  = Word64_add (0x1, RW64(0): Word64)
>>>     RW64(0): Word64  = RW64(2): Word64
>>>     Goto loop_14
>>> Machine.typeCheck
>>>
>>> The Machine IL program has an array offset operation on a manifestly NULL value.
>>>
>>> But, it is already fixed in master:
>>>
>>> [matthew@shadow mlton_compiler_issue-20150925-1]$
>>> ~/devel/mlton/builds/build.gc611cbb/bin/mlton
>>> MLton gc611cbb (built Mon Aug  3 09:19:31 EDT 2015 on shadow)
>>> [matthew@shadow mlton_compiler_issue-20150925-1]$
>>> ~/devel/mlton/builds/build.gc611cbb/bin/mlton mlton.mlb
>>>
>>> I believe this was fixed by either:
>>>     https://github.com/MLton/mlton/commit/444ca04f3630d90e316b0434e52df6c661a84923
>>> or:
>>>     https://github.com/MLton/mlton/commit/24b7e0bd003f7435225543b2c798da12109d995a
>>> Probably the latter, since the commit message notes that the issue
>>> should only arise in dead code, and you observe that your program
>>> always raises an exception, so that the array offset operation is dead
>>> code.
>>>
>>> Actually, looking at you program, it also turns out that we are
>>> missing a reasonable optimization.  MLton is able to constant
>>> propagate the MLton.Pointer.null value through the program, to the
>>> point that it is manifestly the base for an array offset operation.
>>> However, that array offset is guarded by "isNull", but MLton is not
>>> simplifying a "NULL == NULL" comparison; the RSSA IL program (both
>>> mlton-20130715 and mlton-master) has:
>>>
>>>         x_63: Word32 = CPointer_equal (NULL: CPointer, NULL: CPointer)
>>>
>>> If that had been simplified to "true", then the array offset operation
>>> would have been eliminated as dead code.
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> MLton-user mailing list
>> [email protected]; [email protected]
>> https://lists.sourceforge.net/lists/listinfo/mlton-user
>
> To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
>
> ------------------------------------------------------------------------------
> _______________________________________________
> MLton-user mailing list
> [email protected]; [email protected]
> https://lists.sourceforge.net/lists/listinfo/mlton-user
>
>


------------------------------------------------------------------------------