We get a bunch of warnings like this with gcc-4.6.x:
e1000.c:4334:3: warning: variable 'x' set but not used [-Wunused-but-set-variable]
Are we get with adding -Wunused-but-set-variable so they don't show up?
- k
On Wednesday, August 24, 2011 14:29:43 Kumar Gala wrote:
We get a bunch of warnings like this with gcc-4.6.x:
e1000.c:4334:3: warning: variable 'x' set but not used [-Wunused-but-set-variable]
Are we get with adding -Wunused-but-set-variable so they don't show up?
in general, i like this new warning as it tends to catch variables that are dead. i wonder why the e1000 driver has this indirection in the first place. simply calling readl() without using the return value shouldnt cause warnings or DCE ... -mike
Dear Kumar Gala,
In message 3AA0E5B6-7E38-4CB0-94E2-F7BBA9A100FA@kernel.crashing.org you wrote:
We get a bunch of warnings like this with gcc-4.6.x:
e1000.c:4334:3: warning: variable 'x' set but not used [-Wunused-but-set-variable]
Are we get with adding -Wunused-but-set-variable so they don't show up?
If the variable is not used, why don't we remove it, then?
Best regards,
Wolfgang Denk
On Aug 24, 2011, at 2:05 PM, Wolfgang Denk wrote:
Dear Kumar Gala,
In message 3AA0E5B6-7E38-4CB0-94E2-F7BBA9A100FA@kernel.crashing.org you wrote:
We get a bunch of warnings like this with gcc-4.6.x:
e1000.c:4334:3: warning: variable 'x' set but not used [-Wunused-but-set-variable]
Are we get with adding -Wunused-but-set-variable so they don't show up?
If the variable is not used, why don't we remove it, then?
In the vast number of cases it because of some #ifdef case not be defined in the given build.
- k
Dear Kumar Gala,
In message 348935C0-0C2D-4A7A-8ABE-9D09E2904B26@kernel.crashing.org you wrote:
If the variable is not used, why don't we remove it, then?
In the vast number of cases it because of some #ifdef case not be defined in the given build.
well, that's the reason for the warnings showing up, it isn't the reason why we cannot fix these?
Best regards,
Wolfgang Denk
On Aug 25, 2011, at 12:52 AM, Wolfgang Denk wrote:
Dear Kumar Gala,
In message 348935C0-0C2D-4A7A-8ABE-9D09E2904B26@kernel.crashing.org you wrote:
If the variable is not used, why don't we remove it, then?
In the vast number of cases it because of some #ifdef case not be defined in the given build.
well, that's the reason for the warnings showing up, it isn't the reason why we cannot fix these?
:), Thus my query if we really wanted to try and fix them by adding more #ifdef's or live with that as an acceptable thing to do.
- k
On Thursday, August 25, 2011 10:27:42 Kumar Gala wrote:
On Aug 25, 2011, at 12:52 AM, Wolfgang Denk wrote:
Kumar Gala wrote:
If the variable is not used, why don't we remove it, then?
In the vast number of cases it because of some #ifdef case not be defined in the given build.
well, that's the reason for the warnings showing up, it isn't the reason why we cannot fix these?
: :), Thus my query if we really wanted to try and fix them by adding more :#ifdef's or live with that as an acceptable thing to do.
i feel like some (many?) #ifdef's in the tree could be done without ifdefs (by relying on gcc's DCE) thus improving overall code quality -mike
On Thu, Aug 25, 2011 at 9:51 AM, Mike Frysinger vapier@gentoo.org wrote:
i feel like some (many?) #ifdef's in the tree could be done without ifdefs (by relying on gcc's DCE) thus improving overall code quality
What's DCE?
On Thursday, August 25, 2011 15:50:57 Tabi Timur-B04825 wrote:
On Thu, Aug 25, 2011 at 9:51 AM, Mike Frysinger vapier@gentoo.org wrote:
i feel like some (many?) #ifdef's in the tree could be done without ifdefs (by relying on gcc's DCE) thus improving overall code quality
What's DCE?
dead code elimination http://en.wikipedia.org/wiki/Dead_code_elimination
if we let the optimizer do it instead of the preprocessor, we get better code coverage in the face of different config settings. -mike
Mike Frysinger wrote:
if we let the optimizer do it instead of the preprocessor, we get better code coverage in the face of different config settings.
Oh, I thought this was some new feature of U-Boot.
Can you give me an example of where DCE could be used to eliminate an #ifdef?
On Thursday, August 25, 2011 17:44:58 Timur Tabi wrote:
Mike Frysinger wrote:
if we let the optimizer do it instead of the preprocessor, we get better code coverage in the face of different config settings.
Oh, I thought this was some new feature of U-Boot.
Can you give me an example of where DCE could be used to eliminate an #ifdef?
a change i talked about but havent yet posted would be to fix debug(). currently it looks more or less like: #ifdef DEBUG # define debug(...) printf(...) #else # define debug(...) #endif this causes people to do things like put local variables only used with debug() code behind an #ifdef DEBUG in their code otherwise they get unused variable warnings.
if, instead, we did something like: #ifdef DEBUG # define __DEBUG_KNOB 1 #else # define __DEBUG_KNOB 0 #endif #define debug(...) do { if (__DEBUG_KNOB) printf(...); } while (0)
the code would always get compiled and checked, but gcc would throw away it at DCE time, and there would be no unused variable warnings. -mike
Dear Kumar Gala,
In message 7056F5B1-AD6C-459E-80F1-8EE436CC781A@kernel.crashing.org you wrote:
well, that's the reason for the warnings showing up, it isn't the reason why we cannot fix these?
:), Thus my query if we really wanted to try and fix them by adding more #ifdef's or live with that as an acceptable thing to do.
My experience is that hushing up GCC warnings is not really a good idea. First, you will then also fail to see when new code adds such problems. Second, there have been cases where warnings in one GCC version because serious bugs in later versions, so we better fix them.
Best regards,
Wolfgang Denk
participants (6)
-
Kumar Gala -
Mike Frysinger -
Tabi Timur-B04825 -
Timur Tabi
-
Timur Tabi -
Wolfgang Denk