This is a regression from previous releases of Python.  It was introduced by fbe87fb071a6 (for Issue22038) which added the use of C built-in functions for atomic memory access for additional architectures like x86_64.  It seems that the relatively early version of Apple's clang included with Xcode 4 fails compiling this code.  The specific clang version that failed ("Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)") is the version included with the last shipped version of Xcode 4, Xcode 4.6.3, for OS X 10.7 and 10.8.  For OS X 10.8, there is available a more recent version of Xcode, Xcode 5.1.1, which includes a new version of clang, "Apple LLVM 5.1 (clang-503.0.40)", which does correctly compile this code.  In general, we always recommend using the most recent available version of Xcode- or Command Line Tools-installed build tools for a particular version of OS X (with the notable exception of OS X 10.6 - stick with Xcode 3.2.6 there).  So upgrading to Xcode 5.1.1 on OS X 10.8.5 should solve the problem there.  Unfortunately, for OS X 10.7.x, Xcode 4.6.3 is the most recent version and Xcode 4 has always been somewhat problematic for Python builds.  It was in Xcode 4 that Apple stopped shipping the "native" gcc-4.2 compiler in favor of clang and the hybrid Apple llvm-gcc-4.2 compiler (which uses gcc as the front end and LLVM as the backend).  The llvm-gcc-4.2 compiler was a transitional tool, not well-maintained, and is known to incorrectly compile recent versions of Python 3 (Issue13241) so it cannot be used as a substitute for clang in this case on OS X 10.7 (it was no longer shipped as of Xcode 5).

Support for OS X 10.8 is much more important than OS X 10.7: I doubt there are *that* many users are still on 10.7.  So I think a case could be made for marking this as "won't fix".  On the other hand, it should be possible to add tests to ./configure to skip trying to use the atomic builtins when this compiler is in use.