On Fri, 22 Aug 2008, Richard Henderson wrote: > H.J. Lu wrote: > > Can we declare that Linux/ia32 generates i486 insn by default? > > We the gcc team? I'm not sure. For now I'll say no. > > We an individual linux distributor? Certainly. > In fact I would be surprised if i586 wasn't a > decent minimum these days.
glibc has certainly required -march=i486 or greater for some time to build for IA32; it will fail to link for -march=i386 because of missing atomic operations. (And I hold that i686-* should mean -march=i686 default not -mcpu=i386 and similarly x86_64-* -m32 should default to -march=x86_64, subject to --with-arch etc. in both cases.) For the C++ interfaces in question, atomic and threading interfaces of C++0x, and atomic and threading interfaces that may end up in C1x, I think there are several cases to consider: * Does the target support threads? If so, let's assume for now that GCC will always know about what sort of threads are in use at configure time. (In principle, generic bare-metal *-elf and *-eabi targets might allow someone to swap in their choice of RTOS threading library, not present when GCC is built, but I doubt that works well at present.) * Does the CPU support atomic operations? If not, are there OS-provided atomic operations that can be used as a fallback. Then some cases are clear: * If the CPU provides atomic operations, libstdc++ can use them, independent of what OS may be in use. * libstdc++ can only provide some threading interfaces if underlying OS threads are available. Now consider the case where no threads are available. The atomic interfaces still need to be atomic if they are meant to be async-signal-safe as well as thread-safe - are they? What about the exception interfaces in question that use atomic operations internally? Is atomicity needed for signal-safety here, or only for thread-safety? Perhaps an implementation of the standard interfaces should be provided even if it's not safe with signals in certain cases. The most troublesome case is where there are threads but no adequate atomic operations. (It's not clear to me that threads exist without *any* atomic operations, but there may be cases without *enough* atomic operations for libstdc++, e.g. ColdFire Linuxthreads using test-and-set with no compare-and-exchange operation available.) In such a case certain interfaces may not be providable in a thread-safe way without kernel help. In a way it might be good to provide the interfaces in single-threaded programs and somehow give a link failure if the interfaces are used in a program linked with -lpthread - but I don't know how to do that. One significant case is where atomic operations are available with kernel help. SH GNU/Linux provides __sync_* in libgcc and there is an unreviewed patch to do the same for ARM GNU/Linux; both use kernel help in those implementations, and more targets may do this in future. (It's been proposed for HPPA. The ColdFire NPTL specification doesn't include exporting such helpers from libgcc but they could easily be exported from libc; the use of a vDSO may make exporting from libgcc harder.) The GLIBCXX_ENABLE_ATOMIC_BUILTINS configure test looks like it's incorrect for such cases, because it greps for __sync in a .s file and these targets will have such __sync_* references resolved in libgcc. So on GNU/Linux that configure test ought to be a link test. If someone cares about -march=i386 GNU/Linux, they should provide appropriate kernel helpers for atomic operations and make libgcc provide the relevant functions, calling the helpers for i386 and written in assembly for i486 and later (present for i486 and later only so the interfaces provided by libgcc don't depend on the target). One form of helpers would be emulation for the relevant instructions, in which case a single assembly implementation could be used. Similarly, any other case where there are threads but no native atomic operations can have helpers provided in libgcc or libc using kernel support, and the libstdc++ configure test can be made to allow for this case. -- Joseph S. Myers [EMAIL PROTECTED]