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

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

If a user manages to configure their build for i386 then we get
a build failure in the library at the point at which i486 and
above features are needed. We should alert our users of this
configuration problem and abort the configuration instead of
allowing it to progress. I've already had one Red Hat BZ report
about this for GNU/Linux.

I'm suggesting the following patch which disables i386 building:

(a) --host=i386-*

and

(b) CFLAGS with -march=i386 or -mcpu=i386

We support neither (a) nor (b), so we should abort the configuration
with an appropriate error:

*** Building for host i386 is not supported.
*** Please use host i786, i686, i586, or i486.

and

*** Building with -march=i386/-mcpu=i386 is not supported. 
*** Please use host i786, i686, i586, or i486.

respectively.

This has nothing to do with the *base* machine being i386, which
is an implementation detail of the way we handle building for x86.
The following check only prevents (a) or (b) which does not prevent
configuring or compiling for i486, i586 and i686. Perhaps at one
point we'll change i386 to x86 for the base machine.

Tested by building the various variants of (a) and (b) and ensuring
it aborts where it should instead of 

OK?

Comments?

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

	* README: Remove i386-*-gnu from GNU/Hurd supported systems.
	* sysdeps/i386/configure.in: Error if CPP defines __tune_i386__.
	Error if configured machine is i386.
	* sysdeps/i386/configure: Regenerate.

--- a/README
+++ b/README
@@ -12,7 +12,7 @@ implement the operating system behavior seen by user applications.
 In GNU/Hurd systems, it works with a microkernel and Hurd servers.
 
 The GNU C Library implements much of the POSIX.1 functionality in the
-GNU/Hurd system, using configurations i[34567]86-*-gnu.  The current
+GNU/Hurd system, using configurations i[4567]86-*-gnu.  The current
 GNU/Hurd support requires out-of-tree patches that will eventually be
 incorporated into an official GNU C Library release.
 
~~~
diff --git a/sysdeps/i386/configure.in b/sysdeps/i386/configure.in
index 36cb3e4..6cebb14 100644
--- a/sysdeps/i386/configure.in
+++ b/sysdeps/i386/configure.in
@@ -1,6 +1,34 @@
 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.'
+AC_CACHE_CHECK(for use of unsupported -march=i386/-mcpu=i386,
+  [libc_cv_unsupported_i386],
+  [AC_EGREP_CPP(yes,[#ifdef __tune_i386__
+                     yes
+                    #endif
+  ], libc_cv_unsupported_i386=yes, libc_cv_unsupported_i386=no)])
+if test $libc_cv_unsupported_i386 = yes; then
+  AC_MSG_ERROR([
+*** Building with -march=i386/-mcpu=i386 is not supported.
+*** Please use host i786, i686, i586, or i486.])
+fi
+# Check to see if the original configured machine was i386, if it is then we
+# abort for the same reasons as we do with -march=i386.  While it is
+# technically possible to build GNU/Hurd for i386 we don't actually care
+# about anything this old so we support i486 and above similar to GNU/Linux.
+if test $config_machine = i386; then
+  AC_MSG_ERROR([
+*** Building for host i386 is not supported.
+*** Please use host i786, i686, i586, or i486.])
+fi
+
 AC_CHECK_HEADER([cpuid.h], ,
   [AC_MSG_ERROR([gcc must provide the <cpuid.h> header])],
   [/* No default includes.  */])
~~~

Notes:
I actually have a Fedora glibc.spec patch that promotes i386 to i686.
In the case of rpm it use i386 when it actually means "Whatever is 
the lastest 32-bit x86 arch/cpu you support please." Why go to all 
this trouble? If you don't install redhat-rpm-config and try to build
the glibc rpm it will actually attempt an i386 build and fail. Users 
have reported this error, and thus I want to prevent it from happening
in both the spec file (without needing to build depend on 
redhat-rpm-config) and in upstream. In the case of upstream I don't
feel that it is correct to promote i386 to i686 and thus we make it an
error.

Cheers,
Carlos.