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

On Mon, Sep 28, 2015 at 11:33 AM, Phil Clayton <[email protected]> wrote:
> 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.

Sure, that makes sense.  I don't know if there is a simple approach to
handle this kind of situation.

> 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.

Might be able to use the export-subst .gitattribute to handle this
kind of situation, but I don't know if it is worth the effort.

> 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")

That's a good suggestion and format.  Looks like git 2.6.0 just added
a "--date=format:..." option to directly invoke strftime, but probably
safest to use the standard 'date' command as you have.  I would
probably keep the "g" prefix on the commit hash, since that seems to
be convention to distinguish a git commit identifier from other scm
identifiers.  I would probably also keep the conditional "-dirty"
suffix, because it helps to identify if the built compiler is exactly
from that commit or from an edited working 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
>>
>>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> 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].

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