I repost my comments here since they all went to the httpd list... On Wed, Dec 4, 2013 at 1:22 AM, Daniel Lescohier <[email protected]>wrote:
> I see this in configure.in: > > AC_ARG_ENABLE(nonportable-atomics, > [ --enable-nonportable-atomics Use optimized atomic code which may > produce nonportable binaries], > [if test $enableval = yes; then > force_generic_atomics=no > else > force_generic_atomics=yes > fi > ], > [case $host_cpu in > i[[456]]86) force_generic_atomics=yes ;; > *) force_generic_atomics=no ;; > esac > ]) > > I was wondering why the three host_cpus i486, i586, and i686 have special > treatment for the default setting as compared to all other cpu > architectures? > > I don't see any reason since the code in "srclib/apr/atomic/unix/ia32.c" seems compatible with >i386 (cmpxchg starts with i486), and atomic builtins work with gcc-v2+ (at worst USE_ATOMICS_IA32 could be defined for gcc-v1). The issue could have been in apr_atomic_casptr() and apr_atomic_xchgptr(), but APR_SIZEOF_VOIDP is checked to do the right thing with 32bits cpus... The changes in configure.in last http://svn.apache.org/viewvc?view=revision&revision=r64861, where "force_generic_atomics" went from : case $host in *linux*) apr_force_atomic_generic=1 case $host_cpu in i486|i586|i686|powerpc64) if test "$nonportable_atomics_enabled" = 1; then apr_force_atomic_generic=0 fi ;; esac To : AC_ARG_ENABLE(nonportable-atomics, [ --enable-nonportable-atomics Use optimized atomic code which may produce nonportable binaries], [if test $enableval = yes; then force_generic_atomics=no else force_generic_atomics=yes fi ], [case $host_cpu in i[[456]]86) force_generic_atomics=yes ;; *) force_generic_atomics=no ;; esac ]) Before r64861: native atomics were enabled on i[456]86 only when --enable-nonportable-atomics=yes. After r64861: when --enable-nonportable-atomics is not specified, native atomics are disabled (forcibly) on those CPUs. So it seems to have changed from "use native atomics when explicitely specified AND the cpu is compatible" to "use native atomics when explicitely specified OR the CPU is compatible but not i[456]86 " (probably to not have to declare new capable cpus as they arrive). Was this intented?
