Sorry, I had no intention to send this offlist. ---------- Forwarded message ---------- From: Yann Ylavic <ylavic....@gmail.com> Date: Wed, Dec 4, 2013 at 10:37 AM Subject: Re: nonportable-atomics configure.in setting To: Daniel Lescohier <daniel.lescoh...@cbsi.com>
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...
