This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Disable building with i386-*, -march=i386 or -mcpu=i386.
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, Roland McGrath <roland at hack dot frob dot com>, Andreas Jaeger <aj at suse dot com>, Thomas Schwinge <thomas at codesourcery dot com>
- Date: Tue, 26 Mar 2013 23:58:47 -0400
- Subject: Re: [PATCH] Disable building with i386-*, -march=i386 or -mcpu=i386.
- References: <513FE49D dot 3050406 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1303131610540 dot 19781 at digraph dot polyomino dot org dot uk>
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. */])
---