Conversation
Previously the assembler output had symbols removed by grep - now these are added to the "dummy" symbols in i386nt.asm.
|
There was one other question - why is |
|
Not to rain on your parade, but: The tests in testsuite/asmcomp have a rather specific purpose, namely to help with porting to a new target architecture. (That's because those tests exercise only the ocamlopt back-end, and don't even need the runtime system.) Once the whole OCaml system is running, I think those tests are highly redundant with what is tested elsewhere by calling ocamlopt normally. I don't think any future target architecture will use the ml64 assembler... |
|
Is that true for the flambda tests too? In which case, are they more sensibly put elsewhere to stay away from continuous integration? (up one level in testsuite/asmcomp - cf. testsuite/interactive) |
|
Could the symbol naming thing ever be an issue, or is that only arising with those hand-crafted (?) cmm files? |
|
OK, having spoken with Mark it sounds as though we have two, or perhaps even three sets of this tests in one directory where perhaps there should be two directories. For me, it's a bookkeeping nuisance that msvc64 skips all the tests as it makes #975 unnecessarily harder to merge. Can I suggest this course of action:
|
|
@dra27 if nobody has worked on this PR I hope to come back to it once I
can work on ocamltest again.
|
|
@shindere - I want to unblock 975 asap (though I like your proposed change there a lot and will implement that first)... I'm happy to make the changes detailed, as long as there's consensus on the plan! |
|
David Allsopp (2016/12/22 02:05 -0800):
@shindere - I want to unblock 975 asap (though I like your proposed
change there a lot and will implement that first)... I'm happy to make
the changes detailed, as long as there's consensus on the plan!
We discussed with Damien recently and we think ocamltest should really
be merged soon, so tht the migration can really be started.
Wouldn't it be better to just not do anything in this area until the
merge has happened and then focus all the effort on doing things for the
new tests?
|
|
ocamltest doesn't affect the reporting at the end of the testsuite run, though, does it (at least initially?), which is what 975 works on? My hope with the changes there is to have it in place during the development cycle for 4.05 - there were quite a few last-minute testsuite breakages fixed in 4.04.0 (it's been nice with the 4.03 and 4.04 releases to know that the test suite really is supposed to be a 100% pass on all platforms!). There doesn't seem to be any objection (so far) to the principle of what I suggest here - I'll put the diff in (probably after Christmas now) and we can discuss it further then. Good news for merging ocamltest soon! |
|
Hi David,
Really sorry for such a late response.
David Allsopp (2016/12/23 02:01 -0800):
ocamltest doesn't affect the reporting at the end of the testsuite
run, though, does it (at least initially?),
No, it does not. It's just that since the total number of tests will
evolve simply as a consequence of migration (because ocamltest counts
tests differently), the numbers will probably never be right, or at
least it will be painful to maintain them.
And incidentally: the merge of ocamltest will probably be a bit delayed
becaus I broke my left elbow a few days ago so I am supposed to rest
(and not work) if I manage to do so. :)
|
|
Catching up on this discussion: I agree tests/asmcomp is a mess right now and should be split in manual / automatic tests as @dra27 suggests. |
|
@damiendoligez - is it ok to merge testsuite alterations in 4.05 as a matter of course (obviously after review for trunk), or would you prefer those to be explicitly approved too? |
|
Testsuite changes are OK for 4.05, but now that the branch is done, we want to merge ocamltest into trunk very soon, and I'm not sure how much it will impact your work here. |
|
We'll see - it's at least part of the reason I hadn't moved on this and a couple of others! |
|
2.5 years later, any news on this PR? My take is that the "asmcomp" tests (handwritten in C--) are useful only when porting OCaml to a new architecture. Hence, running them on x86 with MASM is not particularly useful -- they are run on x86 anyway. If we agree on this reasoning, could we please close this PR? |
* line editing on the If statements tutorial
So for some reason I decided to port tests/asmcomp to msvc64 this evening. It was interesting, because I've never written any assembler before (and indeed, arguably, I still haven't...).
The first commit corrects a grim hack I added in 4.03.0 which allowed the msvc32 version of these tests to work - i386nt.asm had become stale and I should have fixed that, rather than resorting to hacking the assembler output.
This GPR includes a fix which is already part of #955 (and the fix in #955 is neater, so it should be merged first and the middle commit here removed).
There is a problem which seems to arise because of symbols not being decorated in the amd64 backend - ml64 is very fussy about names and I had to rename some symbols in cmm files. Is that OK - or is this is a sign of a (presumably) hidden problem with the msvc64 backend?
Another thing - why do we not run the programs compiled from the .cmm files? I ask because all of these seem to segfault as soon as they enter the OCaml portion (i.e. some can display usage instructions, but that comes from main.c). The mingw64 examples segfault too, so I'm guessing that something about amd64.S is wrong and therefore (presumably) my translation in amd64nt.asm. Presumably it is informative to run these programs too?
/cc @xavierleroy, @mshinwell