From: Andrew Walrond <[EMAIL PROTECTED]>
Date: Fri, 14 Sep 2007 23:54:13 +0100
> David Miller wrote:
> >
> > And _NO_ this does mean continuing to say that Sun isn't doing enough
> > to satisfy you, that discourages rather than encourages in case you
> >
I have a bug I'm trying to investigate where, starting in gcc-4.2.x,
the loop invariant pass considers a computation involving a global
register variable as invariant across a call. The basic structure
of the code is:
register unsigned long regvar asm ("foo");
func(arg)
{
for (...) {
From: David Miller <[EMAIL PROTECTED]>
Date: Tue, 16 Oct 2007 03:12:23 -0700 (PDT)
> I have a bug I'm trying to investigate where, starting in gcc-4.2.x,
> the loop invariant pass considers a computation involving a global
> register variable as invariant across a call. The
From: "Seongbae Park (박성배, 朴成培)" <[EMAIL PROTECTED]>
Date: Tue, 16 Oct 2007 21:53:37 -0700
Annyoung haseyo, Park-sanseng-nim,
> loop-invariant.cc uses ud-chain.
> So if there's something wrong with the chain,
> it could go nuts.
> Can you send me the rtl dump of loop2_invariant pass ?
I have fou
From: "Seongbae Park (박성배, 朴成培)" <[EMAIL PROTECTED]>
Date: Tue, 16 Oct 2007 22:56:49 -0700
> We need to add DEF as well as USE:
>
> diff -r fd0f94fbe89d gcc/df-scan.c
> --- a/gcc/df-scan.c Wed Oct 10 03:32:43 2007 +
> +++ b/gcc/df-scan.c Tue Oct 16 22:52:44 2007 -0700
> @@ -3109,8 +31
From: David Miller <[EMAIL PROTECTED]>
Date: Tue, 16 Oct 2007 23:04:22 -0700 (PDT)
> I will do some regression testing of the following patch against
> gcc-4.2.x:
>
> --- ./gcc/df-scan.c.ORIG 2007-10-16 02:07:46.0 -0700
> +++ ./gcc/df-scan.c 2007-10-16 23:
From: "Seongbae Park (박성배, 朴成培)" <[EMAIL PROTECTED]>
Date: Tue, 16 Oct 2007 22:56:49 -0700
> Did you replace the DF_REF_REG_USE with DEF ?
> If so, that's not correct. We need to add DEF as well as USE:
...
> Then, we'll need to change the df_invalidated_by_call loop
> not to add global_regs[] a
From: "Seongbae Park (박성배, 朴成培)" <[EMAIL PROTECTED]>
Date: Fri, 19 Oct 2007 17:25:14 -0700
> If you're not in a hurry, can you wait
> till I run the regtest against 4.2 on x86-64 ?
> I've already discussed the patch with Kenny
> and we agreed that this is the right approach,
> but I'd like to see
From: Jason Merrill <[EMAIL PROTECTED]>
Date: Mon, 22 Oct 2007 15:42:50 -0400
> For instance, Bug 32252 is an ice-on-valid bug in a new C++ feature,
> variadic templates. But since 4.2 gave a syntax error instead of an
> ICE, this gets marked as a regression.
I agree that the regression marker i
From: "Seongbae Park (박성배, 朴成培)" <[EMAIL PROTECTED]>
Date: Mon, 22 Oct 2007 11:31:18 -0700
> On x86-64, no regression in 4.2 with the patch.
> So both 4.2 and mainline patches are OK.
Thank you for doing this extra regression testing.
> I'd appreciate it if you can add the testcase
> - it's up t
From: Ian Lance Taylor <[EMAIL PROTECTED]>
Date: 25 Oct 2007 21:31:56 -0700
> Samuel Tardieu <[EMAIL PROTECTED]> writes:
>
> > int
> > trylock()
> > {
> > int res;
> >
> > res = pthread_mutex_trylock(&mutex);
> > if (res == 0)
> > ++acquires_count;
> >
> > return res;
> > }
...
> C
From: Ian Lance Taylor <[EMAIL PROTECTED]>
Date: 25 Oct 2007 21:50:16 -0700
> We could have a global variable "lock_is_held". The
> code could look like this:
>
> if (lock_is_held)
> ++still_holding;
>
> If the earlier code should work in a multi-threaded environment, then
> this code
From: Jakub Jelinek <[EMAIL PROTECTED]>
Date: Fri, 26 Oct 2007 09:48:25 +0200
> On Fri, Oct 26, 2007 at 12:27:01AM -0700, David Miller wrote:
> > From: Jakub Jelinek <[EMAIL PROTECTED]>
> > Date: Fri, 26 Oct 2007 09:09:03 +0200
> >
> > > MEMs in curren
From: Jakub Jelinek <[EMAIL PROTECTED]>
Date: Fri, 26 Oct 2007 09:09:03 +0200
> MEMs in current function's stack frame can be considered safe as
> well.
Unless they are passed by reference down into functions or
a reference to them is assigned into an externally visible
structure.
We actually ha
From: "Dave Korn" <[EMAIL PROTECTED]>
Date: Fri, 26 Oct 2007 17:35:44 +0100
> On 26 October 2007 17:28, Andrew Haley wrote:
>
> > Richard Guenther writes:
> > > >
> > > > This is legal POSIX threads code: counter is not accessed when we do
> > > > not hold the mutex. According to POSIX we do
From: Michael Matz <[EMAIL PROTECTED]>
Date: Fri, 26 Oct 2007 19:04:10 +0200 (CEST)
> Certainly some suggestions for another memory model look quite
> similar to considering all non-automatic objects as volatile, at
> which point the question should be allowed why not simply using
> 'volatile'.
T
From: Michael Matz <[EMAIL PROTECTED]>
Date: Sun, 28 Oct 2007 18:08:23 +0100 (CET)
> I mean who am I to demand that people write correct code,
> I must be insane.
Correctness is defined by pervasive common usage as much as it
is by paper standards.
From: Michael Matz <[EMAIL PROTECTED]>
Date: Sun, 28 Oct 2007 18:08:23 +0100 (CET)
>
> You mean like POSIX doesn't count very much for the kernel behaviour?
>
Nice scarecrow.
Linux has and will break POSIX where POSIX asks unreasonable and
stupid things.
And in particular we will not follow P
From: "Dave Korn" <[EMAIL PROTECTED]>
Date: Mon, 29 Oct 2007 01:05:06 -
> "My way is right and everyone else's is wrong".
I didn't say that. I said that what users do on a broad scale is an
important consideration that often trumps paper standards. And yes,
users as well as the implemento
From: "Dave Korn" <[EMAIL PROTECTED]>
Date: Mon, 29 Oct 2007 01:16:07 -
> Thing is, if you disable all optimisations that are potentially
> unsafe in the presence of threads, won't you just get the same
> effect as if you had used volatile anyway, only on every single
> variable in the progr
From: "Dave Korn" <[EMAIL PROTECTED]>
Date: Mon, 29 Oct 2007 02:39:15 -
> BTW, you and Tomash should get your stories in synch. He says
> speculative loads are ok, just no stores, and wants a kind of
> half-volatile flag that would only suppress stores. I think you're
> already looking one
From: "Dave Korn" <[EMAIL PROTECTED]>
Date: Mon, 29 Oct 2007 02:39:15 -
> On 29 October 2007 01:38, David Miller wrote:
>
> > Even basic correct single-threaded UNIX programs are broken by these
> > speculative stores. If I use a conditional test to pro
From: skaller <[EMAIL PROTECTED]>
Date: Mon, 29 Oct 2007 14:21:10 +1100
>
> On Sun, 2007-10-28 at 18:37 -0700, David Miller wrote:
> > Even basic correct single-threaded UNIX programs are broken by these
> > speculative stores. If I use a conditional test to protect a
From: Darryl Miles <[EMAIL PROTECTED]>
Date: Mon, 29 Oct 2007 04:53:49 +
> What are the issues with "speculative loads" ?
The conditional might be protecting whether the pointer is valid and
can be dereferenced at all.
int *counter;
void foo(int counter_is_valid)
{
if (counter_is_va
From: NightStrike <[EMAIL PROTECTED]>
Date: Thu, 1 Nov 2007 22:34:33 -0400
> I think what is more important is the resulting binary -- does it
> run faster?
The answer to this is situational dependant.
For example, for me, the speed of compilation at -O2 is very important
because I'm constantly
From: NightStrike <[EMAIL PROTECTED]>
Date: Fri, 2 Nov 2007 10:42:01 -0400
> I agree with you 100%. It has always been my view that if you can't
> compile fast enough, then get another machine and use distcc, or get a
> quad core and do make -j5, etc etc.
I have 64 cpu machines and use make -j64
From: Robert Dewar <[EMAIL PROTECTED]>
Date: Sat, 03 Nov 2007 11:40:34 -0400
> Jack Howarth wrote:
> > Is an external copy of GNAT really required to build the
> > ada language in gcc trunk? On powerpc-apple-darwin9, I am
> > seeing configure fail with...
> >
> > configure: error: GNAT is requi
From: Robert Dewar <[EMAIL PROTECTED]>
Date: Sat, 03 Nov 2007 18:40:56 -0400
> David Miller wrote:
>
> > But we don't need a fortran compiler to compile the gfortran compiler,
> > and we don't need a c++ compiler to compile the g++ compiler, and we
> > do
From: Ted Byers <[EMAIL PROTECTED]>
Date: Sat, 3 Nov 2007 21:32:43 -0400 (EDT)
> On a different note, I wish I had your budget for
> hardware. :-)
What budget?
These systems sit right at here with me at home, and I got all of them
for free.
From: Ted Byers <[EMAIL PROTECTED]>
Date: Sun, 4 Nov 2007 01:32:16 -0400 (EDT)
> --- David Miller <[EMAIL PROTECTED]> wrote:
> > From: Ted Byers <[EMAIL PROTECTED]>
> > Date: Sat, 3 Nov 2007 21:32:43 -0400 (EDT)
> >
> > > On a different n
From: "Daniel Berlin" <[EMAIL PROTECTED]>
Date: Wed, 5 Dec 2007 14:08:41 -0500
> So I tried a full history conversion using git-svn of the gcc
> repository (IE every trunk revision from 1-HEAD as of yesterday)
> The git-svn import was done using repacks every 1000 revisions.
> After it finished, I
From: "Daniel Berlin" <[EMAIL PROTECTED]>
Date: Wed, 5 Dec 2007 21:41:19 -0500
> It is true I gave up quickly, but this is mainly because i don't like
> to fight with my tools.
> I am quite fine with a distributed workflow, I now use 8 or so gcc
> branches in mercurial (auto synced from svn) and m
From: "Daniel Berlin" <[EMAIL PROTECTED]>
Date: Wed, 5 Dec 2007 22:47:01 -0500
> The size is clearly not just svn data, it's in the git pack itself.
And other users have shown much smaller metadata from a GIT import,
and yes those are including all of the repository history and branches
not just
From: "Daniel Berlin" <[EMAIL PROTECTED]>
Date: Wed, 5 Dec 2007 23:32:52 -0500
> On 12/5/07, David Miller <[EMAIL PROTECTED]> wrote:
> > From: "Daniel Berlin" <[EMAIL PROTECTED]>
> > Date: Wed, 5 Dec 2007 22:47:01 -0500
> >
> > >
From: Jeff King <[EMAIL PROTECTED]>
Date: Thu, 6 Dec 2007 12:39:47 -0500
> I tried the threaded repack with pack.threads = 3 on a dual-processor
> machine, and got:
>
> time git repack -a -d -f --window=250 --depth=250
>
> real309m59.849s
> user377m43.948s
> sys 8m23.319s
>
From: "Jon Smirl" <[EMAIL PROTECTED]>
Date: Fri, 7 Dec 2007 02:10:49 -0500
> On 12/7/07, Jeff King <[EMAIL PROTECTED]> wrote:
> > On Thu, Dec 06, 2007 at 07:31:21PM -0800, David Miller wrote:
> >
> > # and test multithreaded large depth/window repackin
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Fri, 7 Dec 2007 09:23:47 -0800 (PST)
>
>
> On Fri, 7 Dec 2007, David Miller wrote:
> >
> > Also I could end up being performance limited by SHA, it's not very
> > well tuned on Sparc. It's been on
From: David Miller <[EMAIL PROTECTED]>
Date: Fri, 07 Dec 2007 04:53:29 -0800 (PST)
> I should run oprofile...
While doing the initial object counting, most of the time is spent in
lookup_object(), memcmp() (via hashcmp()), and inflate(). I tried to
see if I could do some tricks on s
From: Nicolas Pitre <[EMAIL PROTECTED]>
Date: Tue, 11 Dec 2007 12:21:11 -0500 (EST)
> BUT. The point is that repacking the gcc repo using "git repack -a -f
> --window=250" has a radically different memory usage profile whether you
> do the repack on the earlier 2.1GB pack or the later 300MB pac
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Wed, 12 Dec 2007 08:37:10 -0800 (PST)
> I'm not saying that particular case happens in git, I'm just saying that
> it's not unheard of. And with the delta cache and the object lookup, it's
> not at _all_ impossible that we hit the "allocate in one t
101 - 140 of 140 matches
Mail list logo
