- Notifications
You must be signed in to change notification settings - Fork1.1k
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Remove SPARC backend#659
Conversation
I have about half a dozen customers of my PDF software using this backend, the most recent of whom purchased from us in 2015. Now, since I'm not able to contribute to its maintenance, or willing to pay for someone to contribute to it, I can hardly complain. But it is still in use. |
Hmm. We may need to keep it around in that case. Do you know if the target is Solaris or Linux? |
If there's an actual user (thanks@johnwhitington!) then I can dig out SparcStation hardware in the Computer Lab. One issue is that Linux kernel support for sparc32 has lagged for years, so it's likely that an old Solaris installation is the only practical OS target to support. I don't have a copy of Solaris lying around... |
Solaris 8 in the most recent case. The customer compiled it themselves. Because of the following issue I know OCaml builds ok on solaris SPARC at least up to 4.01.0: http://caml.inria.fr/mantis/view.php?id=6214 In this instance, I compiled it by remote login to the customer's machine. @avsm Thanks, but I think I still have access to sparc hardware via polarhome.com, if I can dig out the login details, so I'm willing to test build before 4.04. |
@johnwhitington : I have a polarhome.com account as well, but recently they reduced disk quotas so much that you can't even check out the OCaml source tree, let alone build it... |
@xavierleroy Oh dear. I remember having to disable camlp4 last time (when it was in-tree), because there wasn't enough disk space to do the build, but I didn't realise it had got so bad. |
(Closing the PR, since it seems this backend is not going away soon. Feel free to continue using this thread to discuss how to best access such hardware for testing purposes.) |
Could we cross-compile from a different architecture, and they run the binaries? |
This is a motivation to provide a backend – even an unoptimized one – that generates C code and/or LLVM IR, to provide platform independence. |
The bytecode |
hi@xavierleroy , we have solaris sparc machine, we don't use it in production for ocaml code base, but I can help set up a jenkins job, where should I report failures? |
I have SPARC/Solaris machine (last OpenSolaris). Current ocamld6c72fc builds and works well enough for me. The only problem I had - OPAM compiled with 4.02 (its lib-ext does not compile with current trunk) crashed several times with SIGSEGV somewhere deep in GC. Though I can not reproduce it now (perhaps it was a problem with installation). |
@bobzhang I can see a few options:
|
@damiendoligez I will try to set up a Jenkins job this week and see what can be improved |
Reopening this pull request. Having a backend which the core team has no means of testing seems untenable, roughly speaking. @damiendoligez@bobzhang Have there been any updates on trying to get one of these machines in the CI? I think it needs to be running Solaris as per the discussion above. |
I checked with@johnwhitington and the conclusion was that it was ok to remove the SPARC backend now. The code concerns compiles with versions of OCaml going back some way, and in any case, the bytecode version could always be used. If there are no further objections soon then I'll rebase this patch for the backend's removal. |
@mshinwell as far as I know, the Sparc CI was never live. |
All right, it is clear now that no one wants to pay the (financial and human) costs of proper SPARC/Solaris support in OCaml. I'm in favor of removing this compiler back-end. |
62a18d1 to3efe66eCompareThis is ready for review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
You're removing too much stuff, see below. Remember, this is just native-code SPARC support that is being removed, not bytecode support.
| @@ -158,21 +158,9 @@ int caml_set_signal_action(int signo, int action) | |||
| /* Machine- and OS-dependent handling of bound check trap */ | |||
| #if defined(TARGET_power) \ | |||
| || defined(TARGET_s390x) \ | |||
| || (defined(TARGET_sparc) && defined(SYS_solaris)) | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Explain why you're touching s390x support, here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
I'm not -- the s390x line is still there, just without the backslash...
configure Outdated
| @@ -696,7 +696,7 @@ esac | |||
| case "$target" in | |||
| # PR#5088: autodetection is unreliable on ARM. PR#5280: also on MIPS. | |||
| sparc*-*-*|hppa*-*-*|arm*-*-*|mips*-*-*) | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Don't remove, SPARC is still supported in bytecode, and this alignment business affects the bytecode system.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Ah yes, sorry, I misread that as being for native only.
otherlibs/num/.depend Outdated
| @@ -6,7 +6,6 @@ bng_arm64.$(O): bng_arm64.c | |||
| bng_digit.$(O): bng_digit.c | |||
| bng_ia32.$(O): bng_ia32.c | |||
| bng_ppc.$(O): bng_ppc.c | |||
| bng_sparc.$(O): bng_sparc.c | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Don't remove, this can still help with the bytecode version of the library
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Resurrected
otherlibs/num/bng_sparc.c Outdated
| @@ -1,77 +0,0 @@ | |||
| /**************************************************************************/ | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
More generally, don't touch otherlibs/num at all
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Likewise
Looks good to me. Merging in trunk. |
Reimport the threadsigmask test and remove systhread-todo test directory
ce76e02 flambda-backend: Bugfix for type_application (ocaml#746)44f3afb flambda-backend: PR580 for main branch (ocaml#743)b851eaa flambda-backend: Backport first part of ocaml/ocaml PR10498 (ocaml#737)fafb4bd flambda-backend: Fix return mode for eta-expanded function in type_argument (ocaml#735)c31f6c3 flambda-backend: Fix treatment of functions called [@nontail] (ocaml#725)847781e flambda-backend: Fix build_upstream post-PR703 (ocaml#712)bfcbbf8 flambda-backend: Extend Pblock value kind to handle variants (ocaml#703)b2cab95 flambda-backend: Merge ocaml-jsta6d6e0e flambda-backend: Merge ocaml-jst88a4f63 flambda-backend: Use Pmakearray for immutable arrays (ocaml#699)eeaa44b flambda-backend: Install an ocamldoc binary (ocaml#695)48d322b flambda-backend: Ensure that GC is not invoked from bounds check failures (ocaml#681)4370fa1 flambda-backend: Review changes of term directory (ocaml#602)65a4566 flambda-backend: Add code coverage using bisect_ppx (ocaml#352)63ab65f flambda-backend: Bugfix for primitive inclusion (ocaml#662)7e3e0c8 flambda-backend: Fix inclusion checks for primitives (ocaml#661)96c68f9 flambda-backend: Speed up linking by changing cmxa format (ocaml#607)1829150 flambda-backend: Bugfix for Translmod.all_idents (ocaml#659)git-subtree-dir: ocamlgit-subtree-split:ce76e02
The SPARC backend, which only generates 32-bit code, is difficult to test these days due to lack of available hardware. It is suspected that there is no actual use for this backend in the wild at the moment. The maintenance burden of maintaining this backend would seem to be higher than any extra cost (due to bitrot) that its removal would incur in the future should it be resurrected and ported to modern SPARC64 hardware.