New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Test suite doesn't pass using latest compiler #7227
Comments
Comment author: @gasche Last February, the compiler development was split into two branch:
You seem to be using the trunk branch. I would highly recommend trying from the 4.03 branch, which is supposed to be stable and is under testing in preparation for the release. In particular, testsuite failures under 4.03 are even more interesting to report, as they are sign of things that should be fixed quickly before the release (planned in the following weeks). A testsuite failure on trunk is of course already helpful and will be investigated as well. Thanks! |
Comment author: @gasche It was not clear in my previous message, but I think that it is likely that the cause for the regression is a change to the unboxing strategy present in trunk but not in 4.03. (There were also important compiler changes when flambda was merged, so there may still be regressions in 4.03 compared to your tests in November, before flambda.) |
Comment author: RichN I'll switch to the 4.03 branch and report the results. Thanks! |
Comment author: @alainfrisch Well, the part of the test which is failing has been added to test the new unboxing strategy (post 4.03), and it is flambda-specific (it's a case where flambda allows the unboxer to be more precise). I'm pretty sure this does not happen 4.03. |
Comment author: RichN Okay. I'm currently testing 'classic' on the RPi. When it completes, I'll rebuild with 'flambda' and test again. I'll post both results. Thanks, everyone, for the help and information. |
Comment author: @chambart The problem comes from int64 not being unboxed on 32bit systems. I will fix the test by simply replacing int64 by int32. |
Comment author: @gasche Just to clarify, you are saying that RichN should be able to go back to compiling trunk if they want to. |
Comment author: RichN 4.03 branch. Classic tested fine. Tests using flambda: Summary: List of failed tests: List of skipped tests: Something failed. Exiting with error status. |
Comment author: RichN The flambda build had one failure in the tests. |
Comment author: RichN NetBSD/arm failed the "tests/lib-scanf-2" test under flambda. Building and testing on NetBSD/i386 (which is the 32-bit Intel port) completes successfully. |
Comment author: @gasche It seems to me that there are still issues, so I'm reopening the bug and marking it for 4.03+dev to make sure it doesn't escape the release QA. chambart, do you have an idea of what is going on with the scanf test? |
Comment author: RichN Unfortunately the only output (on NetBSD/arm) is: Running tests from 'tests/lib-scanf-2' ... |
Comment author: @gasche From the root repository of the OCaml project, you could go to testsuite/tests/lib-scanf-2 after the test has run, this file should contain files result.byte The latter is the reference result of the test. Could you report the content of the two result files? Also, running make in this directory (after maybe running "make lib" in testsuite/) may produce more informative failure messages. |
Comment author: RichN This may be a subtle shell issue on NetBSD (although my x86 system built fine.) reference, result.byte, and result.native all contain: Ping-pong Ping-pong Ping-pong Ping-pong Ping-pong Ping-pong Ping-pong Ping-pong! And, indeed, diff reports they are identical. I ran the tests like you requested: rpi$ cd testsuite/tests/lib-scanf-2/ I re-ran 'make tests' from the project's top directory and it succeeded! Yet three time now, after building the compiler and running the tests, it fails in the scanf-2 test. I recommend closing this issue out since it seems to be something subtle on NetBSD 7.0/arm using GNUMake. The affected audience is me, so I don't want to hold things up. I'll submit a PR if I can determine why that system has problems the first time it runs the tests. Thank you for your help and suggestions. |
Comment author: @damiendoligez Let's keep the PR open, but I'm setting the target to 4.04 to avoid holding up the 4.03.0 release. |
Comment author: @mshinwell RichN: I'm going to defer this to the 4.05 release, but if you can come up with a patch quickly, we could fix it in 4.04 too. |
Comment author: @mshinwell RichN: have you had any time to investigate this further (e.g. with the 4.04 release)? |
Comment author: RichN During the 4.04 development phase, I took the time to install 'git' on my RPi and cloned OCaml on it (up to then, I was 'rsync'ing the source from my x86 box to the RPi.) When I build it from the locally cloned repo, I can't reproduce the problem. I would have thought that 'git clone' and 'rsync' would end up with the same source tree but, apparently, something was subtly different. Earlier this month, my RPi's SD card died and I haven't had time to restore the machine, so I can't run another test. I think we should just close this issue since it was only seen in this one, unique configuration. |
Comment author: @xavierleroy Suspending as suggested by reporter. |
Original bug ID: 7227
Reporter: RichN
Status: resolved (set by @xavierleroy on 2017-02-16T08:15:36Z)
Resolution: unable to duplicate
Priority: normal
Severity: minor
Platform: ARMv6-hf
OS: NetBSD
OS Version: 7.0
Category: ~DO NOT USE (was: OCaml general)
Tags: arm
Bug description
Back in November, I contributed patches to get the compiler to build and work on a RaspberryPi running NetBSD 7.0. It passed all the tests. Recently, I built the compiler again, but this time specifying "-flambda". One test fails:
Running tests from 'tests/float-unboxing' ...
... testing with ocamlc ocamlopt Fatal error: exception Failure("float and int64 record; alloc = 56000")
=> failed
I'm building the sources from commit 7924ec5 (from GitHub.) Building the compiler suite on the RaspberryPi takes a long time, so if anyone has an educated guess as to where to try to rebuild (using a git commit hash) I won't mind rebuilding from that point and reporting the results.
Steps to reproduce
Run the tests after building the compiler suite.
The text was updated successfully, but these errors were encountered: