Florian,
> * H. J. Lu:
>
> > Here are diffs of SPEC CPU 2K between before and after with gcc 4.1
> > using "-O2 -ffast-math" on Nocona:
>
> And what about Opterons? IOW, how "generic" is the optimization?
The generic code generation should cost a small compromise in performance
relative to
ECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Mark Mitchell
Sent: Wednesday, March 01, 2006 8:22 PM
To: H. J. Lu
Cc: Steven Bosscher; [EMAIL PROTECTED]; Richard Guenther;
gcc@gcc.gnu.org
Subject: Re: GCC 4.1.0 Released
H. J. Lu wrote:
> You are comparing apply with orange. If a user uses -O2, he/
* H. J. Lu:
> Here are diffs of SPEC CPU 2K between before and after with gcc 4.1
> using "-O2 -ffast-math" on Nocona:
And what about Opterons? IOW, how "generic" is the optimization?
Roman Belenov wrote:
> David Edelsohn <[EMAIL PROTECTED]> writes:
>
>> Upgrading GNU tar to 1.15.1 fixed the problem for me.
>
> So what is the actual requirement - 1.14 or "1.14 or above" ?
The latter.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
On 2006-03-01 14:51:45 -0800, H. J. Lu wrote:
> Here are diffs of "-O2 -mtune=nocona -ffast-math" vs
> "-O2 -mtune=generic -ffast-math" on Nocona:
[...]
Optimization is much less important than correct results. From
this point of view, I don't think that using an option known to
produce incorrect
David Edelsohn <[EMAIL PROTECTED]> writes:
> Upgrading GNU tar to 1.15.1 fixed the problem for me.
So what is the actual requirement - 1.14 or "1.14 or above" ?
--
With regards, Roman.
> Dan Kegel writes:
>> The problem has nothing to do with warnings from tar, which are neither
>> errors nor silent failures. I believe a file either got skipped or
>> unpacked with the wrong name.
Dan> Egads. Can you point me to more info? I've been building with older
Dan> versions of t
On 03/01/06 17:51, H. J. Lu wrote:
> SPECint_base2000 1.31%
> SPECfp_base2000 1.62%
>
All these numbers are within the usual SPEC noise. Not Worth It.
H. J. Lu wrote:
> You are comparing apply with orange. If a user uses -O2, he/she will
> see much more than that.
We can argue about that, but I don't think so. I'm comparing a user can
achieve without the patch with the performance they can achieve with the
patch. On all chips, for all time, u
On Wed, Mar 01, 2006 at 04:05:16PM -0800, H. J. Lu wrote:
> On Wed, Mar 01, 2006 at 03:06:46PM -0800, Mark Mitchell wrote:
> > H. J. Lu wrote:
> >
> > > Here are diffs of "-O2 -mtune=nocona -ffast-math" vs
> > > "-O2 -mtune=generic -ffast-math" on Nocona:
> >
> > A 1.5% performance improvement, w
On Wed, Mar 01, 2006 at 03:06:46PM -0800, Mark Mitchell wrote:
> H. J. Lu wrote:
>
> > Here are diffs of "-O2 -mtune=nocona -ffast-math" vs
> > "-O2 -mtune=generic -ffast-math" on Nocona:
>
> A 1.5% performance improvement, while certainly significant for some
> users, is not worth taking any ser
H. J. Lu wrote:
> Here are diffs of "-O2 -mtune=nocona -ffast-math" vs
> "-O2 -mtune=generic -ffast-math" on Nocona:
A 1.5% performance improvement, while certainly significant for some
users, is not worth taking any serious risks on a release branch. The
purpose of bug-fix releases on the relea
On Wednesday 01 March 2006 23:51, H. J. Lu wrote:
> I'd like to see the default -O2 generate decent code for Nocona.
But then, you did so too months ago, when the GCC 4.1 development
cycle was still in stage1/stage2. Nocona has been around for a
very long time already (I have a Prescott-T myself
On Wed, Mar 01, 2006 at 02:19:47PM -0800, Mark Mitchell wrote:
> H. J. Lu wrote:
>
> > Here are diffs of SPEC CPU 2K between before and after with gcc 4.1
> > using "-O2 -ffast-math" on Nocona:
>
> Steven's right; this is clearly a new feature. HJ's also right; we've
> made exceptions before.
>
On Wednesday 01 March 2006 22:06, Steven Bosscher wrote:
> Your patch implements a new feature. New features usually don't fix
> regression. So your patch should be considered for GCC 4.1 IMHO.
I mean should not, obviously.
Gr.
Steven
On Wed, Mar 01, 2006 at 02:24:58PM -0800, Mark Mitchell wrote:
> Joe Buck wrote:
>
> > What is the basis for the report that older tars don't work?
>
> This posting:
>
> http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01861.html
>
> It may certainly be the case that some patched version of tar on
Joe Buck wrote:
> What is the basis for the report that older tars don't work?
This posting:
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01861.html
It may certainly be the case that some patched version of tar on RHEL
works fine (one would indeed hope and expect that distributors are
adding va
H. J. Lu wrote:
> Here are diffs of SPEC CPU 2K between before and after with gcc 4.1
> using "-O2 -ffast-math" on Nocona:
Steven's right; this is clearly a new feature. HJ's also right; we've
made exceptions before.
Like Steven, I would like to see what the difference is between
-mtune=generic
> That is the whole point: I'd like to back port the -mtune=generic
> change to 4.1 branch. There are so many different IA32/x86-64
> processors. The default optimization is more useful than -mtune=xxx.
> The new default (-mtune=generic) is much better than the old one for
> the current IA32/x86-64
On Wed, Mar 01, 2006 at 10:43:40PM +0100, Richard Guenther wrote:
> On 3/1/06, H. J. Lu <[EMAIL PROTECTED]> wrote:
> > On Wed, Mar 01, 2006 at 10:06:57PM +0100, Steven Bosscher wrote:
> > > On Wednesday 01 March 2006 21:49, H. J. Lu wrote:
> > > > It is the issue of quality of gcc 4.1 on IA32/x86-6
On 3/1/06, H. J. Lu <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 01, 2006 at 10:06:57PM +0100, Steven Bosscher wrote:
> > On Wednesday 01 March 2006 21:49, H. J. Lu wrote:
> > > It is the issue of quality of gcc 4.1 on IA32/x86-64. The current gcc
> > > 4.1 performs very poorly on IA32/x86-64, comparin
On Wed, Mar 01, 2006 at 10:06:57PM +0100, Steven Bosscher wrote:
> On Wednesday 01 March 2006 21:49, H. J. Lu wrote:
> > It is the issue of quality of gcc 4.1 on IA32/x86-64. The current gcc
> > 4.1 performs very poorly on IA32/x86-64, comparing against gcc 4.2.
>
> Oh, really? Where are the numb
On Wednesday 01 March 2006 21:49, H. J. Lu wrote:
> It is the issue of quality of gcc 4.1 on IA32/x86-64. The current gcc
> 4.1 performs very poorly on IA32/x86-64, comparing against gcc 4.2.
Oh, really? Where are the numbers you have to support this, may I
say, unlikely claim?
It seemed to me t
> > It's a new feature and not a fix for a regression. -> totally
> > inappropriate.
>
> It is the issue of quality of gcc 4.1 on IA32/x86-64. The current gcc
> 4.1 performs very poorly on IA32/x86-64, comparing against gcc 4.2. I
> can't recommond gcc 4.1 to most people using IA32/x86-64. This ch
On Wed, Mar 01, 2006 at 09:42:19PM +0100, Richard Guenther wrote:
> On 3/1/06, H. J. Lu <[EMAIL PROTECTED]> wrote:
> > On Wed, Mar 01, 2006 at 09:21:19PM +0100, Steven Bosscher wrote:
> > > On Wednesday 01 March 2006 21:14, H. J. Lu wrote:
> > > > Is 4.1 branch open now? I'd like to back port the x
On 3/1/06, H. J. Lu <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 01, 2006 at 09:21:19PM +0100, Steven Bosscher wrote:
> > On Wednesday 01 March 2006 21:14, H. J. Lu wrote:
> > > Is 4.1 branch open now? I'd like to back port the x86
> > > -mtune=generic patch:
> >
> > Isn't that totally inappropriate fo
On Wed, Mar 01, 2006 at 09:21:19PM +0100, Steven Bosscher wrote:
> On Wednesday 01 March 2006 21:14, H. J. Lu wrote:
> > Is 4.1 branch open now? I'd like to back port the x86
> > -mtune=generic patch:
>
> Isn't that totally inappropriate for a release branch?
>
What is it inappropriate about?
On Wednesday 01 March 2006 21:14, H. J. Lu wrote:
> Is 4.1 branch open now? I'd like to back port the x86
> -mtune=generic patch:
Isn't that totally inappropriate for a release branch?
Gr.
Steven
On Wed, Mar 01, 2006 at 08:24:18AM -0800, Mark Mitchell wrote:
>
> GCC 4.1.0 has been released.
>
It is great. Is 4.1 branch open now? I'd like to back port the x86
-mtune=generic patch:
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01436.html
to 4.1.1.
Thanks.
H.J.
On Wed, Mar 01, 2006 at 08:24:18AM -0800, Mark Mitchell wrote:
> 1. GNU TAR 1.14 is required to unpack the source releases. Other
>versions of tar are likely to report errors or silently unpack the
>file incorrectly.
Red Hat EL3 comes with tar 1.13.25 (though since the RPM package on the
On Wed, Mar 01, 2006 at 10:10:39AM -0800, Dan Kegel wrote:
> On 3/1/06, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
> > > > 1. GNU TAR 1.14 is required to unpack the source releases. Other
> > > > versions of tar are likely to report errors or silently unpack the
> > > > file incorrectly.
> >
On 3/1/06, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
> > > 1. GNU TAR 1.14 is required to unpack the source releases. Other
> > > versions of tar are likely to report errors or silently unpack the
> > > file incorrectly.
>
> The problem has nothing to do with warnings from tar, which are ne
On Wed, Mar 01, 2006 at 10:05:52AM -0800, Dan Kegel wrote:
> Mark wrote:
> > 1. GNU TAR 1.14 is required to unpack the source releases. Other
> > versions of tar are likely to report errors or silently unpack the
> > file incorrectly.
>
> Now hold on there, bubaloo.
> I thought the warnings f
Mark wrote:
> 1. GNU TAR 1.14 is required to unpack the source releases. Other
> versions of tar are likely to report errors or silently unpack the
> file incorrectly.
Now hold on there, bubaloo.
I thought the warnings from older versions of tar were benign.
The warnings I'm seeing from tar-1
34 matches
Mail list logo
