Remove SPARC backend by mshinwell · Pull Request #659 · ocaml/ocaml

mshinwell · 2016-07-05T11:01:04Z

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.

johnwhitington · 2016-07-05T11:41:55Z

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.

mshinwell · 2016-07-05T11:48:43Z

Hmm. We may need to keep it around in that case. Do you know if the target is Solaris or Linux?

avsm · 2016-07-05T11:52:29Z

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...

johnwhitington · 2016-07-05T11:55:52Z

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.

xavierleroy · 2016-07-05T12:16:33Z

@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...

johnwhitington · 2016-07-05T12:23:21Z

@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.

alainfrisch · 2016-07-10T12:10:21Z

(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.)

DemiMarie · 2016-07-11T00:48:57Z

Could we cross-compile from a different architecture, and they run the binaries?

DemiMarie · 2016-07-11T00:50:55Z

This is a motivation to provide a backend – even an unoptimized one – that generates C code and/or LLVM IR, to provide platform independence.

avsm · 2016-07-11T11:28:43Z

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 ocamlc compiler is a (mostly) unoptimized and highly portable backend that only needs a C compiler.

bobzhang · 2016-07-11T13:04:08Z

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?
CC @shayne-fletcher

const-rs · 2016-07-18T19:53:45Z

I have SPARC/Solaris machine (last OpenSolaris). Current ocaml d6c72fc 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).

damiendoligez · 2016-10-05T12:38:00Z

@bobzhang I can see a few options:

set it up as a slave for Inria's CI system (needs you to accept ssh connections from Inria)
set it up as a Travis slave (if that's possible)
set it up in your own Jenkins and send reports to ocaml-ci-notifications(at)inria.fr, which is the address used by Inria's CI system. BTW I can give you access to the Inria CI system if you want.

bobzhang · 2016-10-05T13:52:43Z

@damiendoligez I will try to set up a Jenkins job this week and see what can be improved

mshinwell · 2017-04-04T14:15:07Z

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.

mshinwell · 2017-04-07T12:10:13Z

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.

damiendoligez · 2017-04-07T15:23:23Z

@mshinwell as far as I know, the Sparc CI was never live.

xavierleroy · 2017-04-07T17:32:53Z

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.

mshinwell · 2017-04-10T09:24:00Z

This is ready for review.

xavierleroy

You're removing too much stuff, see below. Remember, this is just native-code SPARC support that is being removed, not bytecode support.

xavierleroy · 2017-04-10T09:30:52Z

asmrun/signals_asm.c


 #if defined(TARGET_power) \
-  || defined(TARGET_s390x) \
-  || (defined(TARGET_sparc) && defined(SYS_solaris))


Explain why you're touching s390x support, here?

I'm not -- the s390x line is still there, just without the backslash...

xavierleroy · 2017-04-10T09:32:10Z

configure


 case "$target" in
  # PR#5088: autodetection is unreliable on ARM.  PR#5280: also on MIPS.
-  sparc*-*-*|hppa*-*-*|arm*-*-*|mips*-*-*)


Don't remove, SPARC is still supported in bytecode, and this alignment business affects the bytecode system.

Ah yes, sorry, I misread that as being for native only.

xavierleroy · 2017-04-10T09:33:04Z

otherlibs/num/.depend

 bng_digit.$(O): bng_digit.c
 bng_ia32.$(O): bng_ia32.c
 bng_ppc.$(O): bng_ppc.c
-bng_sparc.$(O): bng_sparc.c


Don't remove, this can still help with the bytecode version of the library

Resurrected

xavierleroy · 2017-04-10T09:33:37Z

otherlibs/num/bng_sparc.c

@@ -1,77 +0,0 @@
-/**************************************************************************/


More generally, don't touch otherlibs/num at all

xavierleroy · 2017-04-11T08:50:37Z

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-jst a6d6e0e flambda-backend: Merge ocaml-jst 88a4f63 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: ocaml git-subtree-split: ce76e02

glaubitz · 2025-10-07T17:35:48Z

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.

I'm super late to the party, but in case anyone is interested, Oracle engineers actually ported the SPARC backend to 64 bits. The patch can be found here.

If someone is interested on hacking on 64-bit SPARC, there are two fast SPARC servers running both Debian unstable as well as Solaris 11.4 available in the GCC Compile Farm.

alainfrisch closed this Jul 10, 2016

mshinwell reopened this Apr 4, 2017

Remove SPARC backend

3efe66e

mshinwell force-pushed the remove_sparc_backend branch from 62a18d1 to 3efe66e Compare April 10, 2017 08:18

xavierleroy requested changes Apr 10, 2017

View reviewed changes

mshinwell added 3 commits April 10, 2017 12:35

Unrevert

3da1c33

Merge remote-tracking branch 'ocaml/trunk' into remove_sparc_backend

a8a478f

Changes

85a6624

xavierleroy approved these changes Apr 11, 2017

View reviewed changes

xavierleroy merged commit 90714f6 into ocaml:trunk Apr 11, 2017

tleedjarv mentioned this pull request Dec 28, 2020

(Re-)enable building on illumos (SmartOS, OmniOS, ...) and Solaris #10063

Merged

quartz55 pushed a commit to quartz55/ocaml that referenced this pull request Feb 1, 2022

Merge pull request ocaml#659 from Engil/reimport_threadsigmask_test

f004c18

Reimport the threadsigmask test and remove systhread-todo test directory

stedolan added a commit to stedolan/ocaml that referenced this pull request May 24, 2022

Bugfix for Translmod.all_idents (ocaml#659)

020a693

lukemaurer pushed a commit to lukemaurer/ocaml that referenced this pull request Jul 19, 2022

flambda-backend: Bugfix for Translmod.all_idents (ocaml#659)

1829150

		@@ -1,77 +0,0 @@
		/**************************************************************************/

Conversation

mshinwell commented Jul 5, 2016

Uh oh!

johnwhitington commented Jul 5, 2016

Uh oh!

mshinwell commented Jul 5, 2016

Uh oh!

avsm commented Jul 5, 2016

Uh oh!

johnwhitington commented Jul 5, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

xavierleroy commented Jul 5, 2016

Uh oh!

johnwhitington commented Jul 5, 2016

Uh oh!

alainfrisch commented Jul 10, 2016

Uh oh!

DemiMarie commented Jul 11, 2016

Uh oh!

DemiMarie commented Jul 11, 2016

Uh oh!

avsm commented Jul 11, 2016

Uh oh!

bobzhang commented Jul 11, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

const-rs commented Jul 18, 2016

Uh oh!

damiendoligez commented Oct 5, 2016

Uh oh!

bobzhang commented Oct 5, 2016

Uh oh!

mshinwell commented Apr 4, 2017

Uh oh!

mshinwell commented Apr 7, 2017

Uh oh!

damiendoligez commented Apr 7, 2017

Uh oh!

xavierleroy commented Apr 7, 2017

Uh oh!

mshinwell commented Apr 10, 2017

Uh oh!

xavierleroy left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

xavierleroy commented Apr 11, 2017

Uh oh!

glaubitz commented Oct 7, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

10 participants

johnwhitington commented Jul 5, 2016 •

edited

Loading

bobzhang commented Jul 11, 2016 •

edited

Loading