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.
