On Thu, Aug 27, 2015 at 12:30:42AM +0200, Julian Taylor wrote: > On 26.08.2015 21:08, Josh Triplett wrote: > > Andreas Barth wrote: > >> Specific issues: > >> - for i386, there is still sold new hardware with 32bit-only. Are > >> there open issues for i386 (apart from the 32bit-generic ones)? > >> Discussion that we need to get rid of it one day should be started. > > > > Brand-new 32-bit-only x86 hardware is currently being sold, and will > > continue to be in the future. In particular, the Quark embedded > > platform is a 32-bit x86, roughly i586-class, with no 64-bit support, > > and no MMX or SSE, though it has a few modern instruction set extensions > > (notably for security). So, i386 needs to stick around for the > > foreseeable future. > > > > That said, I see no particular issue with moving all the i386 buildd > > systems to cross-compile from x86-64, to give the linker more address > > space to work with. LTO will become increasingly important, since new > > 32-bit systems will want small, optimized binaries, and building a large > > project with LTO requires a huge amount of memory. > > > > - Josh Triplett > > > > Does this cpu then have a 80 bit x87 fpu?
Yes, for architectural compatibility and the expectation of working floating-point support. > That thing is usually the most time consuming part in supporting i386 > for numerical and scientific applications due to its compiler > optimization dependant rounding behaviour. > Its probably a better approach to just not build these type of packages > on i386 at all. Nobody will seriously use them anyway and upstreams are > not likely to care about bug reports either. While it's unlikely that anyone will want to run high-performance HPC-focused numeric applications on such platforms, some forms of numeric algorithms are critical on embedded platforms, such as positioning and sensor processing. I don't think it makes sense to stop building numeric algorithms for i386. Ideally, any alorithm that has particular dependencies on numeric behavior (such as rounding) should make the appropriate library calls (such as fesetround) to set the mode it wants. It might, on the other hand, make sense to carefully review the default compiler flags for the platform to ensure a safe default (that programs can then opt out of for performance if they know they can do so safely). I had the impression that gcc for i386 did that already (with options like -ffast-math or -Ofast changing that default). - Josh Triplett
