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

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Carlos O'Donell-6
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  <[hidden email]>

        * 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.
Reply | Threaded
Open this post in threaded view
|

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

Joseph Myers
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.

--
Joseph S. Myers
[hidden email]
Reply | Threaded
Open this post in threaded view
|

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

Roland McGrath-4
In reply to this post by Carlos O'Donell-6
The notion is fine.  The configure check is all wrong, as Joseph explained.
A better configure check (along with "checking" text that describes what
it's actually checking) would make it OK.

Thanks,
Roland
Reply | Threaded
Open this post in threaded view
|

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

Carlos O'Donell-6
In reply to this post by Joseph Myers
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  <[hidden email]>

        * 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.  */])
---
Reply | Threaded
Open this post in threaded view
|

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

Joseph Myers
On Tue, 26 Mar 2013, Carlos O'Donell wrote:

> +# 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"

Wouldn't i486 be more conservative?

Really, given this change, I think sysdeps/i386/i486 should be merged into
sysdeps/i386, and likewise for nptl/sysdeps/i386/i486 and
nptl/sysdeps/unix/sysv/linux/i386/i486, since i486 will be the minimum
supported x86 processor.  Given that, there would be no real point setting
machine to i486 since there wouldn't be i486 sysdeps directories any more.  
If you don't do that followup moving of files, it should at least go on
the wiki / Bugzilla as a todo item.

--
Joseph S. Myers
[hidden email]
Reply | Threaded
Open this post in threaded view
|

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

Carlos O'Donell-6
On 03/27/2013 10:35 AM, Joseph S. Myers wrote:
> On Tue, 26 Mar 2013, Carlos O'Donell wrote:
>
>> +# 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"
>
> Wouldn't i486 be more conservative?

It would be, but in truth *everyone* I've talked to wants i686.

The distros build for i686, users use i686, there is no real use
of i486 or i586 that I can see.

Therefore I would like the elision of i386 to be to a value i686
which has real value for users and is a sensible default in 99%
of the cases. Defaulting to i486 or i586 might be more conservative
but is less useful.

What do you think? Is it valid to balance usefullness in this way?

> Really, given this change, I think sysdeps/i386/i486 should be merged into
> sysdeps/i386, and likewise for nptl/sysdeps/i386/i486 and
> nptl/sysdeps/unix/sysv/linux/i386/i486, since i486 will be the minimum
> supported x86 processor.  Given that, there would be no real point setting
> machine to i486 since there wouldn't be i486 sysdeps directories any more.  
> If you don't do that followup moving of files, it should at least go on
> the wiki / Bugzilla as a todo item.

I agree. I'd actually like to rename i386 to x86 and merge i486 down
in two steps.

I will admit that I *tried* to merge i486 down a directory but found
that it was considerably more work than I had anticipated.

If you agree that eliding i386 to i686 is acceptable then I'll file
a BZ with the details of my initial work to remove i386, and add it
to the master todo list.

Cheers,
Carlos.
 

Reply | Threaded
Open this post in threaded view
|

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

Joseph Myers
On Thu, 28 Mar 2013, Carlos O'Donell wrote:

> On 03/27/2013 10:35 AM, Joseph S. Myers wrote:
> > On Tue, 26 Mar 2013, Carlos O'Donell wrote:
> >
> >> +# 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"
> >
> > Wouldn't i486 be more conservative?
>
> It would be, but in truth *everyone* I've talked to wants i686.
>
> The distros build for i686, users use i686, there is no real use
> of i486 or i586 that I can see.

Is it really common for people to configure for i386 at all, rather than
explicitly i686?  One option would simply be to give an error.

> Therefore I would like the elision of i386 to be to a value i686
> which has real value for users and is a sensible default in 99%
> of the cases. Defaulting to i486 or i586 might be more conservative
> but is less useful.
>
> What do you think? Is it valid to balance usefullness in this way?

What do other architectures do, when configuring for generic versions of
the architecture name?

> I agree. I'd actually like to rename i386 to x86 and merge i486 down
> in two steps.

ix86?  x86 is taken for things shared between 32-bit and 64-bit....

--
Joseph S. Myers
[hidden email]
Reply | Threaded
Open this post in threaded view
|

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

Joseph Myers
On Thu, 28 Mar 2013, Joseph S. Myers wrote:

> What do other architectures do, when configuring for generic versions of
> the architecture name?

I should add: this doesn't necessarily determine what should be done for
i386-*, but would be useful information for considering the options.

(On the whole I like the ARM approach of examining the system for which
the compiler generates code and determining sysdeps directories based on
that, so avoiding a proliferation of configure triplets.)

--
Joseph S. Myers
[hidden email]
Reply | Threaded
Open this post in threaded view
|

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

Carlos O'Donell-6
In reply to this post by Joseph Myers
On 03/28/2013 11:59 AM, Joseph S. Myers wrote:

> On Thu, 28 Mar 2013, Carlos O'Donell wrote:
>
>> On 03/27/2013 10:35 AM, Joseph S. Myers wrote:
>>> On Tue, 26 Mar 2013, Carlos O'Donell wrote:
>>>
>>>> +# 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"
>>>
>>> Wouldn't i486 be more conservative?
>>
>> It would be, but in truth *everyone* I've talked to wants i686.
>>
>> The distros build for i686, users use i686, there is no real use
>> of i486 or i586 that I can see.
>
> Is it really common for people to configure for i386 at all, rather than
> explicitly i686?  One option would simply be to give an error.

Unfortunately for RPM based distros it is. On 32-bit systems the
configure triplet is actually i386-*, without any options, which
leads automatically to i386-based code generation.

I can't easily fix the rpm glibc.spec file to override this, since
everything is expecting "i386" to mean something other than what
it should mean.

>> Therefore I would like the elision of i386 to be to a value i686
>> which has real value for users and is a sensible default in 99%
>> of the cases. Defaulting to i486 or i586 might be more conservative
>> but is less useful.
>>
>> What do you think? Is it valid to balance usefullness in this way?
>
> What do other architectures do, when configuring for generic versions of
> the architecture name?

They don't. In RPM based distros you are technically required to
install some customization packages that make RPM build for i686-*
instead of i386-*, but for several historical reasons those customizations
are not required. So users do attempt to build things for i386 all
the time and file bugs.

Does that answer your question?

>> I agree. I'd actually like to rename i386 to x86 and merge i486 down
>> in two steps.
>
> ix86?  x86 is taken for things shared between 32-bit and 64-bit....

Yes, ix86 might be reasonable.

I wanted to investigate if I could use x86/ia32/, like the linux kernel does.

Cheers,
Carlos.
Reply | Threaded
Open this post in threaded view
|

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

Carlos O'Donell-6
In reply to this post by Joseph Myers
On 03/28/2013 12:56 PM, Joseph S. Myers wrote:
> On Thu, 28 Mar 2013, Joseph S. Myers wrote:
>
>> What do other architectures do, when configuring for generic versions of
>> the architecture name?
>
> I should add: this doesn't necessarily determine what should be done for
> i386-*, but would be useful information for considering the options.

Could you expand on that?

I thought my patch was clear, that configuring for i386-* actually
gets you an i686 build, even if you wanted an i386-* target.

> (On the whole I like the ARM approach of examining the system for which
> the compiler generates code and determining sysdeps directories based on
> that, so avoiding a proliferation of configure triplets.)

Agreed.

Cheers,
Carlos.
 

Reply | Threaded
Open this post in threaded view
|

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

Carlos O'Donell-6
In reply to this post by Carlos O'Donell-6
On 03/28/2013 11:49 AM, Carlos O'Donell wrote:
> If you agree that eliding i386 to i686 is acceptable then I'll file
> a BZ with the details of my initial work to remove i386, and add it
> to the master todo list.

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

I'm not going to file a bug because there really isn't a serious
bug here, unlike the pthread_once cleanup bug I filed which also
points out spurious wakeups in several of the implementations.

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 you suggest 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.

I've checked in this version of the patch, I'm happy to back it
out if you have any objections. I feel like it's forward progress
and crosses off two more bugs.

Updated NEWS with BZ #10060 and #10062.

v2
- Remove i386 reference in README.
- Mention and close BZ#10060 and BZ#10062.

2013-03-22  Carlos O'Donell  <[hidden email]>

        [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.

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..d93ca5c 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.  */])
diff --git a/README b/README
index 6fdfc03..bb4ccb8 100644
--- 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.
---


Cheers,
Carlos.
Reply | Threaded
Open this post in threaded view
|

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

Roland McGrath-4
> On 03/28/2013 11:49 AM, Carlos O'Donell wrote:
> > If you agree that eliding i386 to i686 is acceptable then I'll file
> > a BZ with the details of my initial work to remove i386, and add it
> > to the master todo list.

I am not really convinced that this is the right thing to do.  The
stuff about RPM does not convince me at all.  For one thing,
limitations in downstream package systems are not real reasons for
changing the meanings of things in GNU packages.  For another thing,
people who use rpmbuild to build glibc themselves but can't be
bothered to figure out how to configure their rpmbuild setup don't
deserve our consideration or assistance.  If anything, just an
"i386-* is not supported; you lose" failure at configure time ought
to suffice.

But I don't really object if all it means is that i386-*
configurations elicit a loud complaint and are implicitly transmuted
into i686-*.  I would object strongly if you did anything to break
i[45]86-* configurations that work just fine today.

> +# 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

Use AS_MSG_WARN.  Also, this really belongs in sysdeps/x86/preconfigure
so as not to worsen the situation wrt non-generic magic in generic files.
Reply | Threaded
Open this post in threaded view
|

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

Carlos O'Donell-6
On 04/08/2013 05:09 PM, Roland McGrath wrote:

>> On 03/28/2013 11:49 AM, Carlos O'Donell wrote:
>>> If you agree that eliding i386 to i686 is acceptable then I'll file
>>> a BZ with the details of my initial work to remove i386, and add it
>>> to the master todo list.
>
> I am not really convinced that this is the right thing to do.  The
> stuff about RPM does not convince me at all.  For one thing,
> limitations in downstream package systems are not real reasons for
> changing the meanings of things in GNU packages.  For another thing,
> people who use rpmbuild to build glibc themselves but can't be
> bothered to figure out how to configure their rpmbuild setup don't
> deserve our consideration or assistance.  If anything, just an
> "i386-* is not supported; you lose" failure at configure time ought
> to suffice.

That's true, and I'm willing to make it hard error if that's what
people think we should actually do.

Even if you disagree that downstream should not be a reason, what
about budding developers that want to get started hacking GNU and
for some reason or another their system target triplet is i386-*
and everything breaks. I'd rather just commute that to i686-* and
have them happy little hackers :-)

The BZ's we have fixed with this issue are all about novice developers
needing help or a configure error to tell them to do the right thing.

> But I don't really object if all it means is that i386-*
> configurations elicit a loud complaint and are implicitly transmuted
> into i686-*.  I would object strongly if you did anything to break
> i[45]86-* configurations that work just fine today.

Agreed.

>> +# 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
>
> Use AS_MSG_WARN.  Also, this really belongs in sysdeps/x86/preconfigure
> so as not to worsen the situation wrt non-generic magic in generic files.

Good point, I'll fix this up.

Cheers,
Carlos.
Reply | Threaded
Open this post in threaded view
|

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

Roland McGrath-4
> That's true, and I'm willing to make it hard error if that's what
> people think we should actually do.

It's my preference, but I don't insist on it.

> Even if you disagree that downstream should not be a reason, what
> about budding developers that want to get started hacking GNU and
> for some reason or another their system target triplet is i386-*
> and everything breaks. I'd rather just commute that to i686-* and
> have them happy little hackers :-)
>
> The BZ's we have fixed with this issue are all about novice developers
> needing help or a configure error to tell them to do the right thing.

A hard configure error should certainly tell them the right thing to do.


Thanks,
Roland
Reply | Threaded
Open this post in threaded view
|

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

Allan McRae-3
On 09/04/13 09:11, Roland McGrath wrote:
>> That's true, and I'm willing to make it hard error if that's what
>> people think we should actually do.
>
> It's my preference, but I don't insist on it.
>

I am also in favour of the hard error - in line with every other
building issue found during configure.

>> Even if you disagree that downstream should not be a reason, what
>> about budding developers that want to get started hacking GNU and
>> for some reason or another their system target triplet is i386-*
>> and everything breaks. I'd rather just commute that to i686-* and
>> have them happy little hackers :-)

An error on configure is not exactly a high bar to get passed compared
to anything they are going to hit next...

Allan


Reply | Threaded
Open this post in threaded view
|

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

Carlos O'Donell-6
In reply to this post by Roland McGrath-4
On 04/08/2013 07:11 PM, Roland McGrath wrote:
>> That's true, and I'm willing to make it hard error if that's what
>> people think we should actually do.
>
> It's my preference, but I don't insist on it.

Preference noted. I'd like to leave it as-is to help new developers
on such systems, and to assist downstream. While I agree that on
principle it should be a hard error, the practical side of me says
that it helps more than it hinders to do the elision.

There is a "hard-line" somewhere in my decision making process, but
it's something I try hard *not* to listen to. It may be the case that
our decisions are a continual hegellian dialectic, and that the
community really can't do without you Roland ;-)

I mention again that it would be an additional enhancement to add
--march=i686 when configuring for i686-* to avoid problems with
users that have compilers defaulting to i386 code generation.

>> Even if you disagree that downstream should not be a reason, what
>> about budding developers that want to get started hacking GNU and
>> for some reason or another their system target triplet is i386-*
>> and everything breaks. I'd rather just commute that to i686-* and
>> have them happy little hackers :-)
>>
>> The BZ's we have fixed with this issue are all about novice developers
>> needing help or a configure error to tell them to do the right thing.
>
> A hard configure error should certainly tell them the right thing to do.

Agreed, all such hard configure errors should say why it failed and what
you should do to fix it with examples.

Cheers,
Carlos.

Reply | Threaded
Open this post in threaded view
|

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

Roland McGrath-4
> Preference noted. I'd like to leave it as-is to help new developers
> on such systems, and to assist downstream. While I agree that on
> principle it should be a hard error, the practical side of me says
> that it helps more than it hinders to do the elision.

I'm ambivalent enough that I don't have any more arguments on that.

> I mention again that it would be an additional enhancement to add
> --march=i686 when configuring for i686-* to avoid problems with
> users that have compilers defaulting to i386 code generation.

I don't think we should do any individual ad hoc bits like that.  We
should only do anything like this at all if we make it thorough and
coherent.  That is, one of:

1. The tuple rules the roost: if you configure for i486, you get
   -march=i486.  Likewise for i586 or i686.

   This also fixes the case of someone configuring for i586 with the
   intent of producing binaries compatible with i586 hardware, but not
   realizing that their compiler defaults to -march=i686.

2. The compiler rules the roost: the tuple just selects the top-level
   machine architecture, and then configure examines what the
   compiler's doing (i.e. its predefines) to choose submachine.

   This is what ARM does today.

3. Something involving --with-cpu.

#1 and #2 both have the advantage of ruling out the possibility of any
mismatch between what the compiler targets and what libc's assembly code
targets.  

#3 exists today mostly for submachines that are not
config.sub-friendly, such as powerN for powerpc.

#2 and #3 both could mean that someone configures with
i386-pc-linux-gnu as the tuple (and probably uses that tuple to name
other things in the packaging world or whatnot) but is actually
producing binaries only compatible with i686 or whatever.  That might
be a bug or a feature, depending on your perspective.

Joseph has advocated #2 before.  It seems reasonable to me.  If we'd
thought about that route when the powerpc folks wanted what became the
--with-cpu case, we probably never would have added --with-cpu.

So my starting idea is that we do #2 for all machines, and demote the
--with-cpu support to just being a shorthand (perhaps add --with-tune
too).  That is, --with-cpu=foo just means CC="$CC -march=foo" and the
actual submachine selection is still based on what the compiler says.
The sysdeps/arm/preconfigure code would get refactored into a generic
thing for all machines, with each sysdeps/CPU/preconfigure just
supplying a table mapping predefine names (or patterns or regexps)
to submachine settings.

We don't have the arch vs tune distinction in our submachine sysdeps
layouts today.  We might consider adding that in some fashion.  For
example, today some i386/foo.S and i386/i686/foo.S files don't differ
in the set of instructions they use, just in tuning choices.


Thanks,
Roland
Reply | Threaded
Open this post in threaded view
|

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

Carlos O'Donell-6
In reply to this post by Allan McRae-3
On 04/08/2013 07:23 PM, Allan McRae wrote:
> On 09/04/13 09:11, Roland McGrath wrote:
>>> That's true, and I'm willing to make it hard error if that's what
>>> people think we should actually do.
>>
>> It's my preference, but I don't insist on it.
>>
>
> I am also in favour of the hard error - in line with every other
> building issue found during configure.

I concede, I'll make this to a hard error.
 
>>> Even if you disagree that downstream should not be a reason, what
>>> about budding developers that want to get started hacking GNU and
>>> for some reason or another their system target triplet is i386-*
>>> and everything breaks. I'd rather just commute that to i686-* and
>>> have them happy little hackers :-)
>
> An error on configure is not exactly a high bar to get passed compared
> to anything they are going to hit next...

Very very true.

Cheers,
Carlos.

Reply | Threaded
Open this post in threaded view
|

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

Carlos O'Donell-6
In reply to this post by Roland McGrath-4
On 04/11/2013 05:51 PM, Roland McGrath wrote:

>> Preference noted. I'd like to leave it as-is to help new developers
>> on such systems, and to assist downstream. While I agree that on
>> principle it should be a hard error, the practical side of me says
>> that it helps more than it hinders to do the elision.
>
> I'm ambivalent enough that I don't have any more arguments on that.
>
>> I mention again that it would be an additional enhancement to add
>> --march=i686 when configuring for i686-* to avoid problems with
>> users that have compilers defaulting to i386 code generation.
>
> I don't think we should do any individual ad hoc bits like that.  We
> should only do anything like this at all if we make it thorough and
> coherent.  That is, one of:
>
> 1. The tuple rules the roost: if you configure for i486, you get
>    -march=i486.  Likewise for i586 or i686.
>
>    This also fixes the case of someone configuring for i586 with the
>    intent of producing binaries compatible with i586 hardware, but not
>    realizing that their compiler defaults to -march=i686.

OK.

> 2. The compiler rules the roost: the tuple just selects the top-level
>    machine architecture, and then configure examines what the
>    compiler's doing (i.e. its predefines) to choose submachine.
>
>    This is what ARM does today.

I assume that this option encompases thing like:
CC="arm-none-linux-gnueabi-gcc -mfpu=neon -mfloat-abi=hardfp" ?

That's a ABI + hardware selection.

Where the compiler doesn't really rule the roost, but the user
still has to say which of the N code generation options should
be used to build glibc?

> 3. Something involving --with-cpu.

I like this better than compiler rules the roost.

> #1 and #2 both have the advantage of ruling out the possibility of any
> mismatch between what the compiler targets and what libc's assembly code
> targets.  

Agreed.

> #3 exists today mostly for submachines that are not
> config.sub-friendly, such as powerN for powerpc.

Right.

> #2 and #3 both could mean that someone configures with
> i386-pc-linux-gnu as the tuple (and probably uses that tuple to name
> other things in the packaging world or whatnot) but is actually
> producing binaries only compatible with i686 or whatever.  That might
> be a bug or a feature, depending on your perspective.

Right.

> Joseph has advocated #2 before.  It seems reasonable to me.  If we'd
> thought about that route when the powerpc folks wanted what became the
> --with-cpu case, we probably never would have added --with-cpu.

Agreed.

> So my starting idea is that we do #2 for all machines, and demote the
> --with-cpu support to just being a shorthand (perhaps add --with-tune
> too).  That is, --with-cpu=foo just means CC="$CC -march=foo" and the
> actual submachine selection is still based on what the compiler says.
> The sysdeps/arm/preconfigure code would get refactored into a generic
> thing for all machines, with each sysdeps/CPU/preconfigure just
> supplying a table mapping predefine names (or patterns or regexps)
> to submachine settings.

If you agree about that my assumption about compiler rules the roost
also includes setting CC to compiler for a specific ABI/hardware
target then I would agree.

It has been a long long time since target ruled the roost, and the
target name is a fragile thing that unfortunately has been misused
or poorly used by users and developers. I don't see us recapturing
the use of target triplets for our purposes.

> We don't have the arch vs tune distinction in our submachine sysdeps
> layouts today.  We might consider adding that in some fashion.  For
> example, today some i386/foo.S and i386/i686/foo.S files don't differ
> in the set of instructions they use, just in tuning choices.

Could expand your kernel of a thought here a little more? I don't quite
see what you mean by arch vs. tune distinction?

Cheers,
Carlos.

Reply | Threaded
Open this post in threaded view
|

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

Roland McGrath-4
> I assume that this option encompases thing like:
> CC="arm-none-linux-gnueabi-gcc -mfpu=neon -mfloat-abi=hardfp" ?
>
> That's a ABI + hardware selection.

Yes.  Hence it would also subsume --with{,out}-fp, which I'd forgotten
about.  That needs a bit more thought about all the details.

> Where the compiler doesn't really rule the roost, but the user
> still has to say which of the N code generation options should
> be used to build glibc?

By "the compiler" I meant "$CC", so the compiler does rule the roost.

> > 3. Something involving --with-cpu.
>
> I like this better than compiler rules the roost.

Elaborate.

> If you agree about that my assumption about compiler rules the roost
> also includes setting CC to compiler for a specific ABI/hardware
> target then I would agree.

Since that is indeed what I meant, then I guess you agree, in which case
you need not elaborate on your disagreement. ;-)

> It has been a long long time since target ruled the roost, and the
> target name is a fragile thing that unfortunately has been misused
> or poorly used by users and developers. I don't see us recapturing
> the use of target triplets for our purposes.

Agreed (with s/target/host/g since we're not a compiler).

> > We don't have the arch vs tune distinction in our submachine sysdeps
> > layouts today.  We might consider adding that in some fashion.  For
> > example, today some i386/foo.S and i386/i686/foo.S files don't differ
> > in the set of instructions they use, just in tuning choices.
>
> Could expand your kernel of a thought here a little more? I don't quite
> see what you mean by arch vs. tune distinction?

-march=i586 -mtune=i686 produces code that executes correctly on an i586 as
well as an i686, but executes optimally only on an i686.  sysdeps/i386/i686
contains some code that won't execute correctly on an i586, but mostly
actually contains code that is just optimized for an i686.


Thanks,
Roland
12