all: drop GO386=387 support in Go 1.16 #40255
Comments
|
Change https://golang.org/cl/243137 mentions this issue: |
|
We should wait a little longer for public comment, but I've gone ahead and prepared the pre-announcement for the release notes. (We could also submit the release notes change and roll it back if necessary.) Nick Craig-Wood pointed out on golang-nuts that we should make sure GO386=387 fails with a useful error message if we do drop it (rather than, say, starting to ignore the GO386 environment variable entirely). |
|
Perhaps a silly question, but would this affect GOARCH=amd64 at all? |
|
@mvdan, no it would not. |
|
I guess I am the only one who still has such an old computer. Emulated coprocessor support is also still useful for certain embedded systems. I would keep the feature around for a few more years. |
|
It is known that systems still exists that do not support SSE2. I have several too. It would be interesting if there are users of them relying on current versions of Go for more than hobbyist use and if they cant use gccgo. |
rsc
changed the title
For #40255. Updates #37419. Change-Id: If9210c855cc2eea079e7e469463d4203888748f7 Reviewed-on: https://go-review.googlesource.com/c/go/+/243137 Reviewed-by: Andrew Bonventre <andybons@golang.org>
|
I've gone ahead and submitted the deprecation notice to the 1.15 release notes. However, this issue is still in proposal review. If it does get declined, we can revert the CL. I've asked for this to get reviewed in next week's proposal review meeting. |
|
This went into the proposal minutes last week, and @aclements mailed it to golang-nuts and golang-dev as well. Let's leave this open another week before moving to likely accept, but there doesn't seem to be much pushback here. |
|
Based on the discussion above, this seems like a likely accept. |
|
One data point: just today somebody asked for 387 binaries in tailscale/tailscale#651 We already cross-compile a number of architectures (https://pkgs.tailscale.com/unstable/#static) and it's easy to add 387 to that list. If we had to use gccgo, though, it's a bit harder. Perhaps add some docs linked from the release notes pointing to gccgo instructions for building static 387 binaries? |
|
To build a static executable with gccgo: But note that gccgo executables use the C libraries, so static executables on GNU/Linux systems have some limitations, as glibc generally expects to be dynamically linked. Specifically not all /etc/nsscache.conf values are supported, unless the dynamic C library is also present at run time. |
|
The most feedback to keep support seems to come from users with AMD Geode GX/LX (the kind with MMX but not SSE or SSE2) boards still used in the embedded space (e.g. routers like the ALIX boards). Im in favor of dropping 387. As an alternative go1.16 could be made to reinterpret GO386=387 to mean use softfloat support instead of 387 or SSE2 instructions. This would make ordinary go programs on 387 hardware still work, but slower. It would make the register based calling convention still easier as other platforms (e.g. arm and mips) also require softfloat support. We would also have a mainstream platform for builders to test the softfloat code paths frequently. The upside is that e.g. Athlon XP and Pentium II/III (there were quite alot produced in the Windows XP time) keep on working and linux distros dont need to switch away from go gc to gogcc for their package builders for 386 distros supporting older hardware. This would allow linux distros to keep on using the same build/verification processes in place for 386 and amd64. For verifying no newer instructionsets are used we could potentially use something like: |
|
No change in consensus, so accepted. |
rsc
changed the title
|
Small question here. What to do with |
|
I would keep it around to generate the error. (https://golang.org/design/28221-go2-transitions strongly prefers additions and removals over redefinitions, and ignoring |
|
I agree we should keep it and error out if it's set to anything but sse2 (see also previous comment). |
|
Change https://golang.org/cl/258957 mentions this issue: |
|
Change https://golang.org/cl/259449 mentions this issue: |
Also update some test cases to be more relevant. For golang/go#40255. Fixes golang/go#41799. Change-Id: Ie63e068a46058bcaf7866f2090049fb888612cbe Reviewed-on: https://go-review.googlesource.com/c/build/+/259449 Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Carlos Amedee <carlos@golang.org> Trust: Dmitri Shuralyov <dmitshur@golang.org>
Support for GO386=387 is being dropped in Go 1.16. There is no need for the target to be available for testing on the master branch (where Go 1.16 development is ongoing). For #40255. Change-Id: I4a4ee80b0c0a535b6b0b246fe991f26964eb07ca Reviewed-on: https://go-review.googlesource.com/c/go/+/257963 Reviewed-by: Ian Lance Taylor <iant@golang.org> Trust: Dmitri Shuralyov <dmitshur@golang.org>
|
We replaced 387 support with softfloat support |
…bbering registers The 387 port needs to load a floating-point control word from a global location to implement float32 arithmetic. When compiling with -pie, loading that control word clobbers an integer register. If that register had something important in it, boom. Fix by using LEAL to materialize the address of the global location first. LEAL with -pie works because the destination register is used as the scratch register. 387 support is about to go away (golang#40255), so this will need to be backported to have any effect. No test. I have one, but it requires building with -pie, which requires cgo. Our testing infrastructure doesn't make that easy. Not worth it for a port which is about to vanish. Fixes golang#41620 Change-Id: I140f9fc8fdce4e74a52c2c046e2bd30ae476d295 Reviewed-on: https://go-review.googlesource.com/c/go/+/257277 Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Go Bot <gobot@golang.org> Trust: Keith Randall <khr@golang.org> (cherry picked from commit ea106cc) Reviewed-on: https://go-review.googlesource.com/c/go/+/257207
387 has been removed from go 1.16 see [1] [1] golang/go#40255 Signed-off-by: Khem Raj <raj.khem@gmail.com>
387 has been removed from go 1.16 see [1] [1] golang/go#40255 Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
387 has been removed from go 1.16 see [1] [1] golang/go#40255 (From OE-Core rev: 6f5a7daa3478cfb8febd170f08f7777d3db43865) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
387 has been removed from go 1.16 see [1] [1] golang/go#40255 (From OE-Core rev: 6f5a7daa3478cfb8febd170f08f7777d3db43865) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
387 has been removed from go 1.16 see [1] [1] golang/go#40255 Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
387 has been removed from go 1.16 see [1] [1] golang/go#40255 (From OE-Core rev: dddd90e708ac93f11ca4a156f9dfdbe18fe223bb) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
387 has been removed from go 1.16 see [1] [1] golang/go#40255 (From OE-Core rev: dddd90e708ac93f11ca4a156f9dfdbe18fe223bb) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
387 has been removed from go 1.16 see [1] [1] golang/go#40255 (From OE-Core rev: dddd90e708ac93f11ca4a156f9dfdbe18fe223bb) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
387 has been removed from go 1.16 see [1] [1] golang/go#40255 Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
387 has been removed from go 1.16 see [1] [1] golang/go#40255 (From OE-Core rev: bf0d24ea11221eec9191094a4f4213982a146d54) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
387 has been removed from go 1.16 see [1] [1] golang/go#40255 Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
387 has been removed from go 1.16 see [1] [1] golang/go#40255 (From OE-Core rev: fd549c139f534f28974c86a4e4c7acf6f5c40a79) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Previously we used the i386 target, probably with all optional features disabled. However, the Pentium 4 has been released a _long_ time ago and it seems reasonable to me to take that as a minimum requirement. Upstream Go now also seems to move in this direction: golang/go#40255 The main motivation for this is that there were floating point issues when running the tests for the math package: GOARCH=386 tinygo test math I haven't investigated what's the issue, but I strongly suspect it's caused by the weird x87 80-bit floating point format. This could perhaps be fixed in a different way (by setting the FPU precision to 64 bits) but I figured that just setting the minimum requirement to the Pentium 4 would probably be fine. If needed, we can respect the GO386 environment variable to support these very old CPUs. To support this newer CPU, I had to make sure that the stack is aligned to 16 bytes everywhere. This was not yet always the case.
Previously we used the i386 target, probably with all optional features disabled. However, the Pentium 4 has been released a _long_ time ago and it seems reasonable to me to take that as a minimum requirement. Upstream Go now also seems to move in this direction: golang/go#40255 The main motivation for this is that there were floating point issues when running the tests for the math package: GOARCH=386 tinygo test math I haven't investigated what's the issue, but I strongly suspect it's caused by the weird x87 80-bit floating point format. This could perhaps be fixed in a different way (by setting the FPU precision to 64 bits) but I figured that just setting the minimum requirement to the Pentium 4 would probably be fine. If needed, we can respect the GO386 environment variable to support these very old CPUs. To support this newer CPU, I had to make sure that the stack is aligned to 16 bytes everywhere. This was not yet always the case.
|
Change https://golang.org/cl/342895 mentions this issue: |
The linux-386-387 was only in use for Go 1.15 development. It is being removed as there is no further development for Go 1.15. For golang/go#40255 For golang/go#41799 Change-Id: If636c0099bce195e227a5036842ace92e8305fc9 Reviewed-on: https://go-review.googlesource.com/c/build/+/342895 Trust: Carlos Amedee <carlos@golang.org> Run-TryBot: Carlos Amedee <carlos@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Alexander Rakoczy <alex@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
I propose dropping 387 floating-point support and requiring SSE2 support for GOARCH=386 in the native gc compiler for Go 1.16. This would raise the minimum GOARCH=386 requirement to the Intel Pentium 4 (released in 2000) or AMD Opteron/Athlon 64 (released in 2003).
We would need to pre-announce this in the 1.15 release notes. (I've put it in the 1.15 milestone for this reason.)
There are several benefits to doing this:
The gccgo toolchain will continue to support 387 floating-point, so this remains an option for projects that absolutely must use 387 floating-point.
I proposed this on golang-nuts to get feedback on significant uses of GO386=387, particularly for which using gccgo would not be a viable option.
The text was updated successfully, but these errors were encountered: