From: Bill Davidsen <davidsen@tmr.com>
To: Andi Kleen <andi@firstfloor.org>
Cc: "Justin P. Mattock" <justinmattock@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: warning from gcc version 4.6.0 20100416
Date: Mon, 14 Jun 2010 10:51:03 -0400 [thread overview]
Message-ID: <4C1641D7.3070802@tmr.com> (raw)
In-Reply-To: <20100614074955.GB17092@basil.fritz.box>
Andi Kleen wrote:
> On Sun, Jun 13, 2010 at 09:17:41PM -0400, Bill Davidsen wrote:
>
>> Justin P. Mattock wrote:
>>
>>> o.k. andi,
>>>
>>> here is the rest of the warnings that
>>> I see when compiling the kernel
>>>
>>> I can try and create some patches for
>>> this(hopefully!!)
>>>
>>>
>> There is no great solution to this, in a fair number of cases the fix would
>> slow the code or make it harder to read, so some of these probably don't
>>
>
> Sorry that's wrong: the optimizer will generate the same
> code anyways as if the unused variable was not there
> because it eliminates unused variables.
>
>
If one puts an 'if' around the variable set (I've seen it) the test may
well take longer than the assign, assuming that there's a case where the
assign is done.
> So fixing this cannot make code slower.
>
> I also don't see how unused variables make the code easier
> to read.
>
>
No, my point was that putting a bunch of ifdef statements in to avoid
the warning will make the code harder to read.
> The only difficult case sometimes is with #ifdef code,
> that has to be handled case by case. One elegant solution
> is to replace the ifdef code with an inline.
>
>
>> want a fix. Of course some clearly are errors, so you are doing something
>>
>
> All warnings should be fixed, I only left those in that
> are real code bugs if I couldn't fix the code.
>
> Kernel builds are expected to be relatively warning free
> so that you can easily spot new warnings.
>
> But eventually someone who knows the code better has to
> fix that bug.
>
> --Andi
>
>
--
Bill Davidsen <davidsen@tmr.com>
"We can't solve today's problems by using the same thinking we
used in creating them." - Einstein
prev parent reply other threads:[~2010-06-14 14:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-11 2:55 warning from gcc version 4.6.0 20100416 Justin P. Mattock
2010-06-11 6:16 ` Andi Kleen
2010-06-11 6:34 ` Justin P. Mattock
2010-06-14 1:17 ` Bill Davidsen
2010-06-14 2:54 ` Justin P. Mattock
2010-06-14 7:49 ` Andi Kleen
2010-06-14 14:51 ` Bill Davidsen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C1641D7.3070802@tmr.com \
--to=davidsen@tmr.com \
--cc=andi@firstfloor.org \
--cc=justinmattock@gmail.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.