From: Nathan Lynch <ntl@pobox.com>
To: Tony Breeds <tony@bakeyournoodle.com>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH] Quieten arch/powerpc in a allmodconfig build.
Date: Thu, 9 Apr 2009 23:21:04 -0500 [thread overview]
Message-ID: <20090409232104.60d25d26@manatee.lan> (raw)
In-Reply-To: <20090409000112.GI16602@bilbo.ozlabs.org>
Tony Breeds <tony@bakeyournoodle.com> wrote:
> On Wed, Apr 08, 2009 at 01:47:36PM -0500, Nathan Lynch wrote:
>
> > I think I had some reason for doing it this way, but I'm drawing a
> > blank right now.
> >
> > In the meantime, can someone post the warnings that gcc emits for
> > cacheinfo.c, as well as the gcc version? I can't reproduce them with
> > 4.3.2 on Fedora.
>
> ---
> [tony@thor ~]$ egrep cacheinfo tmp/build.log
> /scratch/tony/working/arch/powerpc/kernel/cacheinfo.c: In function 'associativity_show':
> /scratch/tony/working/arch/powerpc/kernel/cacheinfo.c:562: warning: 'associativity' may be used uninitialized in this function
> /scratch/tony/working/arch/powerpc/kernel/cacheinfo.c: In function 'size_show':
> /scratch/tony/working/arch/powerpc/kernel/cacheinfo.c:513: warning: 'size_kb' may be used uninitialized in this function
Thanks.
So I think I've convinced myself that the warnings are incorrect and
that uninitialized use is not possible.
But I find it odd that gcc gives warnings for these sites but not others
in the file that use the same idiom (e.g. line_size_show,
nr_sets_show). I'd guess that inlining is implicated somehow. Would I
be justified in worrying that this version of gcc is generating
incorrect code?
If not, then I'm fine with the uninitialized_var() changes, but do
please include the warnings and the compiler version in the changelog.
next prev parent reply other threads:[~2009-04-10 4:21 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-08 4:36 [PATCH] Quieten arch/powerpc in a allmodconfig build Tony Breeds
2009-04-08 5:08 ` Michael Ellerman
2009-04-08 5:51 ` Tony Breeds
2009-04-08 6:13 ` Tony Breeds
2009-04-08 6:23 ` Michael Ellerman
2009-04-08 6:48 ` Michael Ellerman
2009-04-08 7:42 ` Geert Uytterhoeven
2009-04-08 18:47 ` Nathan Lynch
2009-04-09 0:01 ` Tony Breeds
2009-04-10 4:21 ` Nathan Lynch [this message]
2009-04-10 17:19 ` Segher Boessenkool
2009-04-09 22:46 ` Segher Boessenkool
2009-04-09 22:45 ` Tony Breeds
2009-04-09 23:11 ` Stephen Rothwell
2009-04-09 23:23 ` Segher Boessenkool
2009-04-10 18:03 ` Scott Wood
2009-04-10 18:35 ` Andreas Schwab
2009-04-10 18:43 ` Scott Wood
2009-04-10 20:28 ` Segher Boessenkool
2009-04-10 20:45 ` Segher Boessenkool
2009-04-10 21:51 ` Scott Wood
2009-04-09 23:18 ` Segher Boessenkool
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=20090409232104.60d25d26@manatee.lan \
--to=ntl@pobox.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=tony@bakeyournoodle.com \
/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.