Re: amd64Translate.Operand.toAMD64Operand: strange Offset: ...
Ram Raghunathan <[email protected]> Wed, 30 Sep 2015 14:15:17 -0400
| Newsgroups | gmane.comp.lang.ml.mlton.user |
|---|---|
| Message-ID | <[email protected]> |
Another versioning possiblity is ---- printf "r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)" ---- This results in a versions number like 'r$V.$S' where $V is the number of commits down the primary branch (which should be a monotonically increasing number) and $S is the commit SHA. $V can be useful for quick "before/after" comparisions of versions. Regards, Ram Raghunathan On Sep 30, Matthew Fluet wrote: > 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]. > > ------------------------------------------------------------------------------ > _______________________________________________ > 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]. ------------------------------------------------------------------------------