[Bug c/44478] -Wunused- but-set-variable is incredible noisy in kernel builds

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44478

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #7 from Marek Polacek  ---
Looks like there isn't anything to do.

[Bug c/44478] -Wunused- but-set-variable is incredible noisy in kernel builds

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2010-06-09 09:49 
---
I'm sure you are right, but I don't understand your explanation: even when
SYMBOL
is undefined, why no code actually uses (roughly speaking, reads) var? That's
the point of the warning and your example doesn't seem to shed any special
light on that.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44478

[Bug c/44478] -Wunused- but-set-variable is incredible noisy in kernel builds

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2010-06-09 09:53 ---
The warning is useful and can find (and already found) several real bugs e.g.
in gcc itself.  Icc has similar warning.
If kernel has lots of useless code like that and doesn't wish to use this
warning, it can add -Wno-unused-but-set-{variable,parameter} to CFLAGS it uses.

Note that in the snippet you mentioned -Wunused would warn always, no matter
whether SYMBOL is defined or not.  When it is not defined, var is unused (also
warned with 4.5 and earlier), when it is defined, var is only set but never
used.

I guess what you really mean is that kernel has lots of snippets that set some
variable to some value and then only conditionally (in #ifdef guarded code)
uses it.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44478

[Bug c/44478] -Wunused- but-set-variable is incredible noisy in kernel builds

[andi-gcc at firstfloor dot org]

--- Comment #3 from andi-gcc at firstfloor dot org  2010-06-09 10:13 ---
Sorry my example was not very good.

Anyways this typically happens with #ifdefs, so the some ifdef path
is actually using the variable, it's just not enabled in the current build.
In theory the ifdefs could be put around the variables too, but
it would increase the ifdef frequency a lot.

Another case i've also seen is to use it as a dummy output variable of inline
assembler, where the assembler is in a macro and it's sometimes used
and sometimes not.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44478

[Bug c/44478] -Wunused- but-set-variable is incredible noisy in kernel builds

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2010-06-09 10:52 ---
We don't warn on
void foo (void)
{
  int dummy;
  asm ( : =r (dummy));
}
- the use in the asm is considered as a use, not just set.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44478

[Bug c/44478] -Wunused- but-set-variable is incredible noisy in kernel builds

[andi-gcc at firstfloor dot org]

--- Comment #5 from andi-gcc at firstfloor dot org  2010-06-09 11:08 ---
Hmm yes there was another temporary and a inline inbetween

unsigned inlinefunc(void)
{
   unsigned var;
   asm( ...  : =r (var));
   return var;
}

#define macro(x,y)
{ 
unsigned var = inlinefunc();
x = var;
y = var  16;
};

caller macro(x,y)  y is just a dummy


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44478

[Bug c/44478] -Wunused- but-set-variable is incredible noisy in kernel builds

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2010-06-09 11:36 ---
Then it has nothing to do with the asm.
If the macro is widely used and very often sets a var that isn't used, all
you can do is add (void) cast to shut the warning up.
(void) (y = var  16);
in this case.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44478