Thanks for that data point, Nick. It's a good idea to make the build fail if GO386 is set to 387 if we drop support. It already fails if GO386 is set to any unsupported value, but we could continue to check GO386 even though there would only be one supported value, and perhaps give a nicer error if it's set to 387.
On Wed, Jul 15, 2020 at 1:21 PM Nick Craig-Wood <n...@craig-wood.com> wrote: > I make a GO386=387 build for rclone, eg > > https://github.com/rclone/rclone/issues/437 > > People love running rclone on ancient computers to rescue data off them I > guess. > > This would affect a very small percentage of users and there are always > older versions of rclone they can use so I'm not too bothered if support is > dropped. > > I haven't tried compiling rclone with gccgo for a while. > > It would be helpful if the build fails rather than silently ignoring the > GO386 flag if this proposal does go forward. > > On Tuesday, 14 July 2020 at 13:56:58 UTC+1 aus...@google.com wrote: > >> Hi everyone. We’re exploring the possibility of dropping 387 >> floating-point support and requiring SSE2 support for GOARCH=386 in the >> native gc compiler, potentially in 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). >> >> There are several reasons we’re considering this: >> >> 1. While 387 support isn’t a huge maintenance burden, it does take >> time away from performance and feature work and represents a fair amount >> of >> latent complexity. >> 2. 387 support has been a regular source of bugs (#36400 >> <http://golang.org/issue/36400#issuecomment-591101886>, #27516 >> <http://golang.org/issue/27516>, #22429 >> <http://golang.org/issue/22429>, #17357 >> <http://golang.org/issue/17357>, #13923 >> <http://golang.org/issue/13923>, #12970 >> <http://golang.org/issue/12970>, #4798 <http://golang.org/issue/4798>, >> just to name a few). >> 3. 387 bugs often go undetected for a long time because we don’t have >> builders that support only 387 (so unsupported instructions can slip in >> unnoticed). >> 4. Raising the minimum requirement to SSE2 would allow us to also >> assume many other useful architectural features, such as proper memory >> fences and 128 bit registers, which would simplify the compiler and >> runtime >> and allow for much more efficient implementations of core functions like >> memmove on 386. >> 5. We’re exploring switching to a register-based calling convention >> in Go 1.16, which promises significant performance improvements, but >> retaining 387 support will definitely complicate this and slow our >> progress. >> >> >> The gccgo toolchain will continue to support 387 floating-point, so this >> remains an option for projects that absolutely must use 387 floating-point. >> >> We’d like to know if there are still significant uses of GO386=387, >> particularly for which using gccgo would not be a viable option. >> >> Thanks! >> > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/babd66fd-fe7f-4840-b1aa-8cb32b499b67n%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/babd66fd-fe7f-4840-b1aa-8cb32b499b67n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CALgmw1-sDfxmeQ7CUvJ8wSUWm3vWCzzb2ZRrH-vdu_Yvqvb_MQ%40mail.gmail.com.
