On Wed, Jul 18, 2007 at 04:03:05PM -0400, Jeff Garzik wrote:
> Greg KH wrote:
> > On Tue, Jul 17, 2007 at 05:42:39PM -0400, Jeff Garzik wrote:
> >> commit ae97fec3701a559929c3529e35417fab133a4d39
> >> Author: Jeff Garzik <[EMAIL PROTECTED]>
> >> Date: Tue Jul 17 01:08:29 2007 -0400
> >>
> >>
Greg KH wrote:
On Tue, Jul 17, 2007 at 05:42:39PM -0400, Jeff Garzik wrote:
commit ae97fec3701a559929c3529e35417fab133a4d39
Author: Jeff Garzik <[EMAIL PROTECTED]>
Date: Tue Jul 17 01:08:29 2007 -0400
drivers/usb/misc/auerswald: fix status check, remove redundant check
1) We shou
On Wed, 18 Jul 2007, Roland Dreier wrote:
>
> BTW, I noticed one interesting thing while starting on this cleanup.
> I wanted to make sure that the generated code didn't change with the
> first step, and I actually discovered that the patch below seems to
> make the generated code *better*, mayb
> Hey, I appreciate it, but I really do have to warn you that I did this all
> blind, and just meant for it to be a "I think this kind of direction is
> more productive" thing. I'm not going to guarantee that it works at all.
Oh, understood, and I'm definitely planning on taking your patch as
On Tue, Jul 17, 2007 at 05:42:39PM -0400, Jeff Garzik wrote:
> commit ae97fec3701a559929c3529e35417fab133a4d39
> Author: Jeff Garzik <[EMAIL PROTECTED]>
> Date: Tue Jul 17 01:08:29 2007 -0400
>
> drivers/usb/misc/auerswald: fix status check, remove redundant check
>
> 1) We should o
On Tue, 17 Jul 2007, Roland Dreier wrote:
>
> > Anyway, here's a totally untested cleanup that compiles but probably
> > doesn't work, because I didn't check that I did the right thing with all
> > the pointer arithmetic (ie when I change "wqe" to a real structure pointer
> > instead of j
> Quite frankly, I don't quite understand where you get those enormous balls
> you have, that you can then talk about how ugly it is to just add a "= 0"
> that shuts up a compiler warning. That's the _least_ ugly part of the
> whole damn function!
The clanking when I walk annoys people in t
On Tue, 17 Jul 2007, Roland Dreier wrote:
>
> I think this patch (on top of the previous one) actually makes the
> code clearer
Quite frankly, calling this "making the code clearer" is a bit ridiculous.
That code still is absolute *crap* from a readability angle. It doesn't
follow any sane cod
Roland Dreier wrote:
In this case the code is basically
u32 x;
for (n = 0; cond; ++n) {
...
if (!n)
x = something;
...
}
if (n) {
...
use(x);
> > So setting a variable to something meaningless (guaranteeing that a
> > garbage value is used in case of a bug) just to shut up a warning makes
> > no sense -- it's no safer than leaving the code as is.
>
> Wrong.
>
> It's safer for two reasons:
> - now everybody will see the *sa
On Tue, 17 Jul 2007, Roland Dreier wrote:
>
> So setting a variable to something meaningless (guaranteeing that a
> garbage value is used in case of a bug) just to shut up a warning makes
> no sense -- it's no safer than leaving the code as is.
Wrong.
It's safer for two reasons:
- now ever
I think this patch (on top of the previous one) actually makes the
code clearer, and also makes it smaller:
add/remove: 0/0 grow/shrink: 0/3 up/down: 0/-41 (-41)
function old new delta
mthca_tavor_post_send 13441335 -9
mthca_
> I don't buy that performance argument, in this case. You are already
> dirtying the same cacheline with other variable initializations.
>
> Like I noted in the changeset description (hey, this is precisely why
> I included it, so that we could have this discussion), IMO the flow of
> cont
On Tue, 17 Jul 2007, Andrew Morton wrote:
>
> (rofl, look at that mess: it was utterly impractical, unrealistic and
> stupid for gcc to go and UTFify the compiler output. Sigh. LANG=C, guys).
Yeah, I absolutely *detest* how gcc does idiotic quoting just because you
happen to be in a UTF-8 lo
On Tue, 17 Jul 2007 14:53:02 -0700
Roland Dreier <[EMAIL PROTECTED]> wrote:
> > drivers/infiniband/hw/mthca/mthca_qp: kill uninit'd var warning
> >
> > drivers/infiniband/hw/mthca/mthca_qp.c: In function
> > __mthca_tavor_post_send__:
> > drivers/infiniband/hw/mthca/
Jeff Garzik wrote:
I don't buy that performance argument, in this case. You are already
dirtying the same cacheline with other variable initializations.
Or simply sitting in a CPU register for large stretches of function
runtime...
Jeff
-
To unsubscribe from this list: send the li
Roland Dreier wrote:
> drivers/infiniband/hw/mthca/mthca_qp: kill uninit'd var warning
>
> drivers/infiniband/hw/mthca/mthca_qp.c: In function
> ‘mthca_tavor_post_send’:
> drivers/infiniband/hw/mthca/mthca_qp.c:1594: warning: ‘f0’ may be
used
> uniniti
> drivers/infiniband/hw/mthca/mthca_qp: kill uninit'd var warning
>
> drivers/infiniband/hw/mthca/mthca_qp.c: In function
> âmthca_tavor_post_sendâ:
> drivers/infiniband/hw/mthca/mthca_qp.c:1594: warning: âf0â may be
> used
> uninitialized in this functi
Those "may be used uninitialized" warnings are annoying. So annoying
that kernel developers tune them out, and that occasionally hides
real bugs, as my past patches (and those below) indicate.
I included the full-length changelog below the diffstat, because
that is where the best explanation for
19 matches
Mail list logo