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
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
https://ozlabs.org/m
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
behavi
Andreas Schwab wrote:
Scott Wood 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 rejec
Scott Wood 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 reject this c
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, i
/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
Tony Breeds 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?
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
-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
On Fri, 10 Apr 2009 08:45:53 +1000 Tony Breeds 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
> > for that one
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 susp
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 w
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
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 prefer, but t
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 gener
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 ho
On Wed, 2009-04-08 at 16:13 +1000, Tony Breeds wrote:
> 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 CONF
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, 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
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
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 "neate
22 matches
Mail list logo
