httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <ylavic....@gmail.com>
Subject Fwd: nonportable-atomics configure.in setting
Date Wed, 04 Dec 2013 09:40:21 GMT
Sorry, I had no intention to send this offlist.

---------- Forwarded message ----------
From: Yann Ylavic <ylavic.dev@gmail.com>
Date: Wed, Dec 4, 2013 at 10:37 AM
Subject: Re: nonportable-atomics configure.in setting
To: Daniel Lescohier <daniel.lescohier@cbsi.com>


On Wed, Dec 4, 2013 at 1:22 AM, Daniel Lescohier
<daniel.lescohier@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...

Mime
View raw message