On Wed, Feb 20, 2019 at 8:06 AM Thierry fa...@linux.ibm.com < thie...@linux.ibm.com> wrote:
> On Tue, 19 Feb 2019 16:50:00 +0100 "Thierry fa...@linux.ibm.com" > <thie...@linux.ibm.com> wrote: > > On Mon, 7 Jan 2019 16:49:41 +0000 Steve McIntyre <st...@einval.com> > wrote: > > > Hi Matthew, > > > > > > On Sun, Dec 30, 2018 at 05:38:57PM -0500, Matthew Fluet wrote: > > > >If it is just the `world` regression tests that are failing, then it > > > >is almost certainly due to save/restore world being incompatible with > > > >ASLR; see http://mlton.org/MLtonWorld#_notes. Perhaps Debian > > > >arm64-linux has gained ASLR since the last time the regression suite > > > >was run on this platform? In any case, you'll notice that the `world` > > > >regression tests are explicitly whitelisted (i.e., these tests failing > > > >do not cause a failure exit status from the regression script) because > > > >of this issue. > > > > > As this bug is not specifically opened for one arch, I also want to > > mention it fails on ppc64el. I see the sequence > > testing wordn-array > > testing world1 > > 2c2,3 > > < I am the clone > > --- > > > unhandled exception: Fail: child failed > > > Nonzero exit status. > > world1: difference with -type-check true > > testing world2 > > 1c1,2 > > < 30 > > --- > > > unhandled exception: Fail: child failed > > > Nonzero exit status. > > world2: difference with -type-check true > > testing world3 > > 1c1,2 > > < caught foo > > --- > > > unhandled exception: Fail: child failed > > > Nonzero exit status. > > world3: difference with -type-check true > > testing world4 > > 4,6c4,5 > > < between saves > > < after saves > > < after saves > > --- > > > unhandled exception: Fail: child failed > > > Nonzero exit status. > > world4: difference with -type-check true > > testing world5 > > 2c2,3 > > < success > > --- > > > unhandled exception: Fail: child failed > > > Nonzero exit status. > > world5: difference with -type-check true > > testing world6 > > 1,4c1 > > < ./world6 > > < a > > < b > > < c > > --- > > This pad is hosted in Toulouse LTC lab. Created at 2019-02-19 09:45:56. > > Hi, > I have run make check without world tests and result is code 1 because > of failing tests on some architectures > testing mlton.overload > testing mlton.share > 1c1 > < size of a is 1600 > --- > > size of a is 2408 > 102c102 > < size of a is 484 > --- > > size of a is 920 > > testing size2 > 2,23c2,23 > < The size of an int list of length 4 is = 48 bytes. > < The size of a string of length 10 is = 24 bytes. > < The size of an int array of length 10 is = 52 bytes. > < The size of a double array of length 10 is = 92 bytes. > < The size of a (word32 * double) array of length 10 is = 132 bytes. > < The size of a (word32 * word32 * double) array of length 10 is = 172 > bytes. > < The size of a (word64 * double) array of length 10 is = 172 bytes. > < The size of a (word16 * double) array of length 10 is = 132 bytes. > < The size of a word64 array of length 10 is = 92 bytes. > < The size of a (word32 * word64) array of length 10 is = 132 bytes. > < The size of a (word32 * word32 * word64) array of length 10 is = 172 > bytes. > < The size of a (word64 * word64) array of length 10 is = 172 bytes. > < The size of a (word16 * word64) array of length 10 is = 132 bytes. > < The size of an array of length 10 of 2-ples of ints is = 92 bytes. > < The size of an array of length 10 of 2-ples of (shared) ints is = 92 > bytes. > < The size of an array of length 10 of arrays of length 20 of ints is = > 972 bytes. > < The size of an array of length 10 of (shared) arrays of length 20 of > ints is = 144 bytes. > < The size of an array of length 10 of tuples of word16 * (arrays of > length 20 of ints) is = 1012 bytes. > < The size of an array of length 10 of tuples of word32 * (arrays of > length 20 of ints) is = 1012 bytes. > < The size of an array of length 10 of tuples of word64 * (arrays of > length 20 of ints) is = 1052 bytes. > < The size of an array of length 10 of tuples of real32 * (arrays of > length 20 of ints) is = 1012 bytes. > < The size of an array of length 10 of tuples of real64 * (arrays of > length 20 of ints) is = 1052 bytes. > --- > > The size of an int list of length 4 is = 96 bytes. > > The size of a string of length 10 is = 40 bytes. > > The size of an int array of length 10 is = 64 bytes. > > The size of a double array of length 10 is = 104 bytes. > > The size of a (word32 * double) array of length 10 is = 184 bytes. > > The size of a (word32 * word32 * double) array of length 10 is = 184 > bytes. > > The size of a (word64 * double) array of length 10 is = 184 bytes. > > The size of a (word16 * double) array of length 10 is = 184 bytes. > testing size3 > 1c1,114 > < size3.$arch-$os.ok missing > --- > > The size of unit is = 0 bytes. > > The size of unit * unit is = 0 bytes. > > The size of bool is = 0 bytes. > > The size of bool * bool is = 16 bytes. > > The size of day is = 0 bytes. > > The size of day * day is = 0 bytes. > > The size of a char is = 0 bytes. > > The size of a char * char is = 0 bytes. > > The size of a word8 is = 0 bytes. > > The size of a word8 * word8 is = 0 bytes. > > The size of a word16 is = 0 bytes. > The `mlton.share` and `size` regression tests are platform dependent. If there is a `size2.$arch-$os.ok` file that matches the platform, then the program output is matched against that, but if not, then it is compared against a `size2.ok` file which corresponds to `x86-linux`. You must be running on platforms for which there are not platform specific files. Note that the `size3.ok` file doesn't correspond to `x86-linux`, instead using contents that remind you that it is platform dependent. It is admittedly a mess, because most of the platform dependencies are really just due to 32-bit vs 64-bit and possibly due to default alignment. Upstream the regression suite was reworked to avoid that; see https://github.com/MLton/mlton/pull/287.
