aboutsummaryrefslogtreecommitdiff
path: root/aclocal.m4
diff options
context:
space:
mode:
authorCarlos O'Donell <carlos@redhat.com>2013-04-06 12:00:35 -0400
committerCarlos O'Donell <carlos@redhat.com>2013-04-06 12:00:35 -0400
commita01f19c8fb12eef419d4112879bc715e2ab6f6d7 (patch)
tree7fc2d8e4007a8b4f7d3a7aecf0734a11ee199ba2 /aclocal.m4
parentb7a329a5614d9001abcc3300a3da548a0865a3ac (diff)
downloadglibc-a01f19c8fb12eef419d4112879bc715e2ab6f6d7.tar
glibc-a01f19c8fb12eef419d4112879bc715e2ab6f6d7.tar.gz
glibc-a01f19c8fb12eef419d4112879bc715e2ab6f6d7.tar.bz2
glibc-a01f19c8fb12eef419d4112879bc715e2ab6f6d7.zip
i386: Fail at configure time for i386 builds.
This change does two things: * Treats a target i386-* as if it were i686. * Fails configure if the user is generating code for i386. We no longer support i386 code-generation because the i386 lacks the atomic operations we need in glibc. You can still configure for i386-*, but you get i686 code. You can't build with --march=i386, --mtune=i386 or a compiler that defaults to i386 code-generation. I've added two i386 entries in the master todo list to discuss merging and renaming: http://sourceware.org/glibc/wiki/Development_Todo/Master#i386 The failure modes are fail-safe here. You compile for i386, get i686, and try to run on i386 and it fails. The configure log has a warning saying we elided to i686. There is no situation that I can see where we run into any serious problems. The patch makes the current state better in that we get less confused users and we build successfully in more default configurations. The next enhancement would be to add --march=i?86 as suggested in #c20 of BZ#10062 for any i?86-* builds, which would solve the problem of a 32-bit compiler that defaults to i386 code-gen and glibc configured for i686-* target. Which previously failed at build time, and now will fail at configure time (requires adding --march=i686). Updated NEWS with BZ #10060 and #10062. No regressions. --- 2013-04-06 Carlos O'Donell <carlos@redhat.com> [BZ #10060, #10062] * 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. * README: Remove i386 reference.
Diffstat (limited to 'aclocal.m4')
-rw-r--r--aclocal.m433
1 files changed, 33 insertions, 0 deletions
diff --git a/aclocal.m4 b/aclocal.m4
index 042a7e3c38..64351d0a00 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)])