Re: [PATCH] Disable building with i386-*, -march=i386 or -mcpu=i386.

["Carlos O'Donell" <carlos at redhat dot com>]

On 03/13/2013 12:15 PM, Joseph S. Myers wrote:
> On Tue, 12 Mar 2013, Carlos O'Donell wrote:
> 
>> +  [AC_EGREP_CPP(yes,[#ifdef __tune_i386__
> 
> That's the wrong test.  Tuning for i386, although strange, shouldn't cause 
> any problems at all for building glibc; it's -march= not -mtune= that's 
> the issue, and this would fail to detect -march=i386 with -mtune= for some 
> more recent processor.
> 
> Instead, try building (to .s) a source file using a __sync intrinsic 
> that's expanded inline for i486 and later, and see if the generated .s 
> file has a call to an out-of-line __sync library function; that reflects 
> the actual problem you get building with -march=i386.
> 
> Also mention [BZ #10060] and [BZ #10062] in the ChangeLog entry and those 
> bug numbers in NEWS.
> 

This second version of the patch does things slightly differently.

We are kinder on users who configure with i386-* and elide that they
actually mean i686. This appears to be the common case for many distros
and packages e.g. using i386 to mean 32-bit x86. We emit a warning 
when we elide i686.

However, we can't tolerate code generation for i386 and abort if we 
detect that __sync_val_compare_and_swap was not inlined.

Comments?

Tested by building with and without -march=i386, and -mtune=i386.
Tested by building with and without i386-pc-linux-gnu and i686-pc-linux-gnu.

OK to checkin?

I will followup with a patch to README and NEWS to officially note the
dropping of i386 for all configurations.

Note: I think we can use LIBC_COMPILER_BUILTIN_INLINED to simplify
a couple of other checks in top-level configure.in.

v2
- Convert i386 to i686 for $machine.
- Check for __sync_val_compare_and_swap to detect invalid -march/-mtune.

2013-03-22  Carlos O'Donell  <carlos@redhat.com>

	* aclocal.m4 (LIBC_COMPILER_BUILTIN_INLINED): New macro.
	* sysdeps/i386/configure.in: Use LIBC_COMPILER_BUILTIN_INLINED and
	fail configure if __sync_val_compare_and_swap is not inlined.
	* sysdeps/i386/configure: Regenerate.
	* configure.in: Build for i686 when configured for i386.
	* configure: Regenerate.

diff --git a/aclocal.m4 b/aclocal.m4
index 042a7e3..64351d0 100644
--- a/aclocal.m4
+++ b/aclocal.m4
@@ -248,3 +248,36 @@ dnl LIBC_CONFIG_VAR(make-variable, shell-value)
 AC_DEFUN([LIBC_CONFIG_VAR],
 [config_vars="$config_vars
 $1 = $2"])
+
+dnl Check that function FUNC was inlined as a builtin.  The code fragment
+dnl CODE is compiled with additional options CC_OPTION.  If FUNC is
+dnl not found in the assembly then it is assumed the compiler has support
+dnl for this builtin and has inlined the call.  If the compiler has the
+dnl feature then ACTION-IF-TRUE is called, otherwise ACTION-IF-FALSE.
+dnl It is up to the caller to provide a CC_OPTION that ensures the
+dnl builtin is inlined if present.
+dnl Warning: This may not work for some machines. For example on ARM the
+dnl ABI dictates that some functions should not be inlined and instead
+dnl should be provided by a compiler helper library e.g. __aeabi_memcpy.
+dnl This is done to reduce code size.
+dnl LIBC_COMPILER_BUILTIN([func], [code], [cc_option], [action-if-true], [action-if-false])
+AC_DEFUN([LIBC_COMPILER_BUILTIN_INLINED],
+[AC_MSG_CHECKING([for compiler support of inlined builtin function $1])
+libc_compiler_builtin_inlined=no
+cat > conftest.c <<EOF
+int _start (void) { $2 return 0; }
+EOF
+if ! AC_TRY_COMMAND([${CC-cc} $CFLAGS $CPPFLAGS $LDFLAGS
+		     $3 -nostdlib -nostartfiles
+		     -S conftest.c -o - | fgrep "$1"
+		     1>&AS_MESSAGE_LOG_FD])
+then
+  libc_compiler_builtin_inlined=yes
+fi
+rm -f conftest*
+if test $libc_compiler_builtin_inlined = yes; then
+  $4
+else
+  $5
+fi
+AC_MSG_RESULT($libc_compiler_builtin_inlined)])
diff --git a/configure.in b/configure.in
index bbdf156..c51ed89 100644
--- a/configure.in
+++ b/configure.in
@@ -390,6 +390,15 @@ case "$machine-$host_os" in
     ;;
 esac
 
+# Configure for i686 if the user asks for i386. We don't support
+# i386 any more but it continues to be common for users to configure
+# 32-bit x86 as i386. We build for i686 instead.
+if test "$machine" = i386; then
+  machine="i686"
+  echo "\
+*** WARNING: Support for i386 is deprecated. Building for i686 instead."
+fi
+
 submachine=
 AC_ARG_WITH([cpu],
 	    AS_HELP_STRING([--with-cpu=CPU], [select code for CPU variant]),
diff --git a/sysdeps/i386/configure.in b/sysdeps/i386/configure.in
index 9967a16..56a7c1f 100644
--- a/sysdeps/i386/configure.in
+++ b/sysdeps/i386/configure.in
@@ -1,6 +1,25 @@
 GLIBC_PROVIDES dnl See aclocal.m4 in the top level source directory.
 # Local configure fragment for sysdeps/i386.
 
+# The GNU C Library can't be built for i386.  There are several reasons for
+# this restriction.  The primary reason is that i386 lacks the atomic
+# operations required to support the current NPTL implementation.  While it is
+# possible that such atomic operations could be emulated in the kernel to date
+# no such work has been done to enable this.  Even with NPTL disabled you still
+# have no atomic.h implementation.  Given the declining use of i386 we disable
+# support for building with `-march=i386' or `-mcpu=i386.' We don't explicitly
+# check for i386, instead we make sure the compiler has support for inlining
+# the builtin __sync_val_compare_and_swap. If it does then we should have no
+# problem building for i386.
+LIBC_COMPILER_BUILTIN_INLINED(
+  [__sync_val_compare_and_swap],
+  [int a, b, c; __sync_val_compare_and_swap (&a, b, c);],
+  [-O0],
+  [libc_cv_unsupported_i386=no],
+  [AC_MSG_ERROR([
+*** Building with -march=i386/-mcpu=i386 is not supported.
+*** Please use host i786, i686, i586, or i486.])])
+
 AC_CHECK_HEADER([cpuid.h], ,
   [AC_MSG_ERROR([gcc must provide the <cpuid.h> header])],
   [/* No default includes.  */])
---