On Thu, Aug 07, 2003 at 01:13:18AM +0200, Matthias Klose wrote:
> so make -mcpu=i586 -mtune=i686 the default? anything else as the default?
I think you mean "-march=i588 -mcpu=i686", -mtune is not a valid
option for i386 gcc.
--
Lionel
pgpxFylVXY9J9.pgp
Description: PGP signature
At 08 Aug 2003 13:40:42 +0100,
Philip Blundell wrote:
> On Fri, 2003-08-08 at 13:35, GOTO Masanori wrote:
> > So how to act for two bugs?:
> >
> > #203322: python2.2: Python fails with illegal instruction during
> > postinst on sparc32
> > #203324: libc6: __strtod_internal fails with ille
On Fri, 2003-08-08 at 13:35, GOTO Masanori wrote:
> So how to act for two bugs?:
>
> #203322: python2.2: Python fails with illegal instruction during
> postinst on sparc32
> #203324: libc6: __strtod_internal fails with illegal instruction on
> sparc32.
>
> Keeping them as "Critical"
At Thu, 7 Aug 2003 07:33:09 +0200,
Jan-Benedict Glaw wrote:
>
> [1 ]
> On Wed, 2003-08-06 17:22:19 -0400, Ben Collins <[EMAIL PROTECTED]>
> wrote in message <[EMAIL PROTECTED]>:
> > On Wed, Aug 06, 2003 at 11:08:22PM +0200, Matthias Klose wrote:
> > > Jan-Benedict Glaw writes:
> >
> > Someone is
On Thu, 2003-08-07 08:34:37 +0200, Matthias Klose <[EMAIL PROTECTED]>
wrote in message <[EMAIL PROTECTED]>:
> Jan-Benedict Glaw writes:
> > Would Debian accept two ix86 distributions? One i386 and, say, i[56]86?
>
> No, unless you can explain why you need to run KDE, eclipse and
> openoffice on an
Jan-Benedict Glaw writes:
> Would Debian accept two ix86 distributions? One i386 and, say, i[56]86?
No, unless you can explain why you need to run KDE, eclipse and
openoffice on an i386. This has to be a subset due to bandwidth and
disk limitations.
> I'd even volunteer to rebuild all the package
Jan-Benedict Glaw <[EMAIL PROTECTED]> writes:
> Would Debian accept two ix86 distributions? One i386 and, say, i[56]86?
Most developers probably would, if presented with a sound plan that
makes that happen and has no downsides (except for the obvious one
that ftp archives will need more space).
Jan-Benedict Glaw <[EMAIL PROTECTED]> writes:
> > You are wrong. There are two versions of atomicity.h, one for i486+,
> > and the other for i386+ (at the time the other distributors released
> > their compilers, there was only the i486+ version, and it was assumed
> > to work for i386+, but didn'
On Thu, 2003-08-07 07:58:01 +0200, Martin v. Löwis <[EMAIL PROTECTED]>
wrote in message <[EMAIL PROTECTED]>:
> Jan-Benedict Glaw <[EMAIL PROTECTED]> writes:
> > Am I wrong or did we, "forced" because we wanted to be binary compatible
> > to some major distributions, just follow others and doing opt
Jan-Benedict Glaw <[EMAIL PROTECTED]> writes:
> Am I wrong or did we, "forced" because we wanted to be binary compatible
> to some major distributions, just follow others and doing optimization
> just as they did?
You are wrong. There are two versions of atomicity.h, one for i486+,
and the other
On Wed, 2003-08-06 15:52:31 -0400, Nathanael Nerode <[EMAIL PROTECTED]>
wrote in message <[EMAIL PROTECTED]>:
> Jan-Benedict Glaw said:
> >...and up to now, I haven't seen real hard numbers that show that
> >optimizing for i486 does really make anything noticeable faster. From
>
> I've given such
On Wed, 2003-08-06 17:22:19 -0400, Ben Collins <[EMAIL PROTECTED]>
wrote in message <[EMAIL PROTECTED]>:
> On Wed, Aug 06, 2003 at 11:08:22PM +0200, Matthias Klose wrote:
> > Jan-Benedict Glaw writes:
>
> Someone is making statements without knowing the real situation.
> Changing to hwmul ops in l
On Thu, 2003-08-07 00:48:04 -0400, Daniel Jacobowitz <[EMAIL PROTECTED]>
wrote in message <[EMAIL PROTECTED]>:
> On Thu, Aug 07, 2003 at 06:43:35AM +0200, Jan-Benedict Glaw wrote:
> > On Wed, 2003-08-06 23:08:22 +0200, Matthias Klose <[EMAIL PROTECTED]>
> > wrote in message <[EMAIL PROTECTED]>:
> >
On Thu, 2003-08-07 01:13:18 +0200, Matthias Klose <[EMAIL PROTECTED]>
wrote in message <[EMAIL PROTECTED]>:
> Marcus Brinkmann writes:
> > On Wed, Aug 06, 2003 at 10:05:13AM +0200, Matthias Klose wrote:
> > > IIRC the Hurd can be built for i586 only, so it could be used as the
> > > default target
On Thu, Aug 07, 2003 at 06:43:35AM +0200, Jan-Benedict Glaw wrote:
> On Wed, 2003-08-06 23:08:22 +0200, Matthias Klose <[EMAIL PROTECTED]>
> wrote in message <[EMAIL PROTECTED]>:
> > Jan-Benedict Glaw writes:
> > > i386 seems to die, sun4m also does have servere problems... Where does
> > > this le
On Wed, 2003-08-06 23:08:22 +0200, Matthias Klose <[EMAIL PROTECTED]>
wrote in message <[EMAIL PROTECTED]>:
> Jan-Benedict Glaw writes:
> > i386 seems to die, sun4m also does have servere problems... Where does
> > this lead to? All these seem to arise from doing optimization which
> > hasn't been
On Thu, Aug 07, 2003 at 01:13:18AM +0200, Matthias Klose wrote:
> Marcus Brinkmann writes:
> > On Wed, Aug 06, 2003 at 10:05:13AM +0200, Matthias Klose wrote:
> > > IIRC the Hurd can be built for i586 only, so it could be used as the
> > > default target CPU as well.
> >
> > We only require a copr
Marcus Brinkmann writes:
> On Wed, Aug 06, 2003 at 10:05:13AM +0200, Matthias Klose wrote:
> > IIRC the Hurd can be built for i586 only, so it could be used as the
> > default target CPU as well.
>
> We only require a coprocessor, but anything < i586 doesn't make much sense
> at all at this stage.
On Wed, Aug 06, 2003 at 11:08:22PM +0200, Matthias Klose wrote:
> Jan-Benedict Glaw writes:
> > i386 seems to die, sun4m also does have servere problems... Where does
> > this lead to? All these seem to arise from doing optimization which
> > hasn't been proved to (really) make things better... Eve
Jan-Benedict Glaw writes:
> i386 seems to die, sun4m also does have servere problems... Where does
> this lead to? All these seem to arise from doing optimization which
> hasn't been proved to (really) make things better... Everything I see is
> that it's breaking stuff.
the ix86 change was for _c
Nathanael Nerode writes:
> Jan-Benedict Glaw said:
> >my point of view, you're making something marginally (at best...)
> >faster but giving up i386 compatibility (relying on a hackish emulator
> >which isn't right now available for the latest kernel).
>
> i386 compatibility already requires the
Jan-Benedict Glaw said:
>...and up to now, I haven't seen real hard numbers that show that
>optimizing for i486 does really make anything noticeable faster. From
I've given such numbers for the use of i486 instructions. The speed
increase applies to specific applications only and is quite large
>Now that the kernel-image packages supports hw emulation of i486
>instructions on i386 hardware, I'd like to change the code generation
>to default to i486 (not sure if it should be tuned for any other
Yes. I think -march=i486 is quite appropriate here, provided that the
kernel-image packages re
On Wed, 2003-08-06 20:11:32 +0200, Martin v. Löwis <[EMAIL PROTECTED]>
wrote in message <[EMAIL PROTECTED]>:
> Jan-Benedict Glaw <[EMAIL PROTECTED]> writes:
>
> > Having a "broken" libstdc++ is already bad enough. Please, please please
> > please please don't make it worse as it's already today. I
Jan-Benedict Glaw <[EMAIL PROTECTED]> writes:
> Having a "broken" libstdc++ is already bad enough. Please, please please
> please please don't make it worse as it's already today. I heared rumors
> that gcc-3.4 might fix the current situation (wrt. libstdc++).
Don't believe these rumors; they are
On Wed, 2003-08-06 09:52:57 -0600, Joel Baker <[EMAIL PROTECTED]>
wrote in message <[EMAIL PROTECTED]>:
> On Wed, Aug 06, 2003 at 10:05:13AM +0200, Matthias Klose wrote:
> > Now that the kernel-image packages supports hw emulation of i486
> > instructions on i386 hardware, I'd like to change the co
On Wed, Aug 06, 2003 at 10:05:13AM +0200, Matthias Klose wrote:
> Now that the kernel-image packages supports hw emulation of i486
> instructions on i386 hardware, I'd like to change the code generation
> to default to i486 (not sure if it should be tuned for any other
> target, i.e. -mtune=i686).
On Wed, Aug 06, 2003 at 10:05:13AM +0200, Matthias Klose wrote:
> Now that the kernel-image packages supports hw emulation of i486
> instructions on i386 hardware, I'd like to change the code generation
> to default to i486 (not sure if it should be tuned for any other
> target, i.e. -mtune=i686).
On Wed, 2003-08-06 10:05:13 +0200, Matthias Klose <[EMAIL PROTECTED]>
wrote in message <[EMAIL PROTECTED]>:
> Now that the kernel-image packages supports hw emulation of i486
> instructions on i386 hardware, I'd like to change the code generation
> to default to i486 (not sure if it should be tuned
On Wed, Aug 06, 2003 at 10:05:13AM +0200, Matthias Klose wrote:
> IIRC the Hurd can be built for i586 only, so it could be used as the
> default target CPU as well.
We only require a coprocessor, but anything < i586 doesn't make much sense
at all at this stage. So no problem on our side.
Thanks,
30 matches
Mail list logo
