This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Deprecate i386 for GCC 4.8?
- From: Janne Blomqvist <blomqvist dot janne at gmail dot com>
- To: Joel Sherrill <joel dot sherrill at oarcorp dot com>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, Steven Bosscher <stevenb dot gcc at gmail dot com>, GCC Mailing List <gcc at gcc dot gnu dot org>, Uros Bizjak <ubizjak at gmail dot com>
- Date: Thu, 20 Dec 2012 00:13:51 +0200
- Subject: Re: Deprecate i386 for GCC 4.8?
- References: <00ylsjwi1bldkdpkwkq3kjci.1355877179864@email.android.com>
On Wed, Dec 19, 2012 at 2:32 AM, Joel Sherrill
<joel.sherrill@oarcorp.com> wrote:
> My primary concern centers whether any 386 w/o fpu IP cores or space hardened i386dx/sx or 486sx CPUs are impacted. These could be used in new designs.
>
> This also eliminates gcc from use on any older embedded x86 boards w/o fpu.
AFAICT nobody was suggesting dropping 486sx support, so x86 soft-float
support wouldn't be going away.
Wikipedia doesn't list any x86-compatible space hardened CPU's, though
it links to a 1998 press release about Sandia making a rad-hardened
variant of the Pentium for US gov space and defense applications;
presumably not to be available on the open market.
On the positive side, by dropping 386 you could, in some situations,
use the new 486 atomic instructions such as cmpxchg instead of a
critical section with interrupts disabled.
> RTEMS still supports these but depends on gcc as the foundation. We can use qemu to automate testing gcc. We have been periodically posting results but not in the past few months. I did a build sweep in the 4.8 devel cycle but ended up using most of my time to report PRs.
>
> I realize that for mainstream PCs, these are ancient and a good candidate for deprecation.
>
> --joel
>
> "Joseph S. Myers" <joseph@codesourcery.com> wrote:
>
>>On Wed, 12 Dec 2012, Steven Bosscher wrote:
>>
>>> Linux support for i386 has been removed. Should we do the same for GCC?
>>
>>FWIW, glibc hasn't really supported i386 for several years (at least with
>>the Linux kernel; I don't know about Hurd), since NPTL requires atomic
>>operations that i386 doesn't have, so fails to link unless you use
>>-march=i486 or later.
>>
>>--
>>Joseph S. Myers
>>joseph@codesourcery.com
--
Janne Blomqvist