This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Input on new i386 atomics (was Re: Python 2.3 in testing)
- From: martin at v dot loewis dot de (Martin v. Löwis)
- To: Joel Sherrill <joel dot sherrill at OARcorp dot com>
- Cc: Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>, libstdc++ at gcc dot gnu dot org
- Date: 29 Apr 2003 21:39:34 +0200
- Subject: Re: Input on new i386 atomics (was Re: Python 2.3 in testing)
- References: <3EAB2A4B.2000105@v.loewis.de><200304290458.h3T4wZg2064844@latour.rsch.comm.mot.com><3EAEB6A6.8F1374F4@OARcorp.com>
Joel Sherrill <joel.sherrill@OARcorp.com> writes:
> In the embedded community, when we build a target CPU-XXX, we EXPECT
> that the generated code and multilib'ed libraries are appropriate to
> support ALL of the CPU models within that family using OS XXX. That
> is the case for arm, m68k, powerpc, mips, sparc, sh, etc. and the
> i386 should be no different.
That is not the issue. It is very clear that an i386 binary will work
on i486, Pentium (|Pro|II|III|IV), Itanium-in-Pentium-mode.
The issue is whether mixing i386 and i486 binaries is supposed to work
or not.
> If you end up with everyone using an i386 version, so be it.
That may be acceptable for the embedded community, but it is not for
desktop users. It is, in general, not acceptable for a desktop user to
pay a penalty for a hardware that nobody uses on the desktop.
Regards,
Martin