On Wed, Dec 4, 2013 at 10:40 AM, Yann Ylavic <ylavic....@gmail.com> wrote:
> On Wed, Dec 4, 2013 at 1:22 AM, Daniel Lescohier < > daniel.lescoh...@cbsi.com> 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 ]) So prior to r64861: native atomics were enabled on i[456]86 when --enable-nonportable-atomics=yes. After r64861: native atomics are disabled (forcibly) on those CPUs, whatever --enable-nonportable-atomics is. Was this intented?
