/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
Segher Boessenkool wrote:
Unfortunately -Wno-uninitialized also suppresses the warnings that point
to real bugs.
It's a double-edged sword, yes. Warnings are always like that:
if the compiler could know that something _is_ wrong for certain,
it wouldn't need a warning (it would use an error,
Scott Wood scottw...@freescale.com writes:
The problem is that GCC does not give an error (only a warning) even for
things like this where it should be trivial to detect that the usage *is*
uninitialized, not just might be:
int foo(void)
{
int a;
return a;
}
The compiler must not
Andreas Schwab wrote:
Scott Wood scottw...@freescale.com writes:
The problem is that GCC does not give an error (only a warning) even for
things like this where it should be trivial to detect that the usage *is*
uninitialized, not just might be:
int foo(void)
{
int a;
return a;
}
The
The problem is that GCC does not give an error (only a warning)
even for
things like this where it should be trivial to detect that the
usage *is*
uninitialized, not just might be:
int foo(void)
{
int a;
return a;
}
The compiler must not reject this code, because the undefined
And further, there is no separation of warning classes into might-
be-uninitialized and is-uninitialized-compiler-can-tell-for-sure.
Indeed. Please file a bug report.
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
Segher Boessenkool wrote:
And further, there is no separation of warning classes into
might-be-uninitialized and is-uninitialized-compiler-can-tell-for-sure.
Indeed. Please file a bug report.
Done: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39731
-Scott
Gah, gcc sucks. It should just not warn in these cases where it
doesn't
know wth is going on.
I don't think you'll get any arguments. it only there was a -
Wnowarnunused!
-Wno-unused or -Wno-unused-pparameter and/or -Wno-unused-variable.
But I
thought this was about uninitialised var
On Fri, Apr 10, 2009 at 12:46:06AM +0200, Segher Boessenkool wrote:
-Wno-unused or -Wno-unused-pparameter and/or -Wno-unused-variable. But I
thought this was about uninitialised var warnings? -Wno-uninitialized
for that one.
If you are asking for a GCC option that will warn for all suspect
On Fri, 10 Apr 2009 08:45:53 +1000 Tony Breeds t...@bakeyournoodle.com wrote:
On Fri, Apr 10, 2009 at 12:46:06AM +0200, Segher Boessenkool wrote:
-Wno-unused or -Wno-unused-pparameter and/or -Wno-unused-variable. But I
thought this was about uninitialised var warnings? -Wno-uninitialized
-Wno-unused or -Wno-unused-pparameter and/or -Wno-unused-
variable. But I
thought this was about uninitialised var warnings? -Wno-
uninitialized
for that one.
If you are asking for a GCC option that will warn for all suspect
cases
_except_ for the ones where it is obvious to you there is
Unfortunately -Wno-uninitialized also suppresses the warnings that
point
to real bugs.
It's a double-edged sword, yes. Warnings are always like that:
if the compiler could know that something _is_ wrong for certain,
it wouldn't need a warning (it would use an error, instead -- and
it does do
Tony Breeds t...@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
On Wed, Apr 08, 2009 at 03:51:26PM +1000, Tony Breeds wrote:
Hmm actually I think you're right. I dont want to push my luck with the gcc
hackers though
Replying to myself.
Yes this is a gcc bug but one introduced by CONFIG_TRACE_ALL_BRANCHES (or
whatever that's called).
Yours Tony
On Wed, 2009-04-08 at 15:51 +1000, Tony Breeds wrote:
On Wed, Apr 08, 2009 at 03:08:55PM +1000, Michael Ellerman wrote:
The getter routines in here could really multiplex their return values
with a negative error code, which I generally prefer, but this works I
guess.
I was hoping
On Wed, 8 Apr 2009, Michael Ellerman wrote:
On Wed, 2009-04-08 at 15:51 +1000, Tony Breeds wrote:
On Wed, Apr 08, 2009 at 03:08:55PM +1000, Michael Ellerman wrote:
The getter routines in here could really multiplex their return values
with a negative error code, which I generally
Michael Ellerman mich...@ellerman.id.au wrote:
On Wed, 2009-04-08 at 15:51 +1000, Tony Breeds wrote:
On Wed, Apr 08, 2009 at 03:08:55PM +1000, Michael Ellerman wrote:
The getter routines in here could really multiplex their return values
with a negative error code, which I generally
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
This patch silences all the warnings generated in arch/powerpc for
allmodconfig build.
It does:
* Where appropriate use the uninitialized_var() macro to help GCC
understand we know what's going on.
* Explicitly casts PHYSICAL_START in one printk()
* Initialise a few variables, as it's
On Wed, 2009-04-08 at 14:36 +1000, Tony Breeds wrote:
This patch silences all the warnings generated in arch/powerpc for
allmodconfig build.
It does:
* Where appropriate use the uninitialized_var() macro to help GCC
understand we know what's going on.
* Explicitly casts PHYSICAL_START
On Wed, Apr 08, 2009 at 03:08:55PM +1000, Michael Ellerman wrote:
The getter routines in here could really multiplex their return values
with a negative error code, which I generally prefer, but this works I
guess.
I was hoping someone would notice and suggest it. tag you're it!
Do you
21 matches
Mail list logo
