drivers/video: fix compiler warnings
Subsystems (2)
PATCH 1/1 drivers/video: fix compiler warnings
Fix some compile warnings:
warning: ‘*’ may be used uninitialized in this function
---
Compile tested on i386.
Diffed against Linus' git tree.
drivers/video/matrox/matroxfb_maven.c | 6 +++--- drivers/video/riva/riva_hw.c | 3 ++- 2 files changed, 5 insertions(+), 4 deletions(-)
drivers/video/matrox/matroxfb_maven.c +3 -3
@@ -284,7 +284,7 @@ static unsigned int matroxfb_mavenclock(const struct matrox_pll_ctl* ctl, unsigned int* in, unsigned int* feed, unsigned int* post, unsigned int* htotal2) { unsigned int fvco; -unsigned int p; +unsigned int p =0 ; fvco =matroxfb_PLL_mavenclock (&maven1000_pll, ctl, htotal, vtotal, in, feed, &p, htotal2);if (!fvco)
@@ -305,7 +305,7 @@ static unsigned int matroxfb_mavenclock(const struct matrox_pll_ctl* ctl,static void DAC1064_calcclock (unsigned int freq,unsigned int fmax,unsigned int * in,unsigned int * feed,unsigned int * post) {unsigned int fvco; -unsigned int p; +unsigned int p =0 ; fvco =matroxfb_PLL_calcclock (&maven_pll, freq, fmax, in, feed, &p); p = (1 << p) -1 ;
@@ -715,7 +715,7 @@ static int maven_find_exact_clocks(unsigned int ht, unsigned int vt, m->regs[0x82 ] =0x81 ;for (x =0 ; x <8 ; x++) { -unsigned int a, b, c, h2; +unsigned int a =0 , b =0 , c =0 , h2 =0 ;unsigned int h = ht +2 + x;if (!matroxfb_mavenclock ((m->mode =MATROXFB_OUTPUT_MODE_PAL ) ? &maven_PAL : &maven_NTSC, h, vt, &a, &b, &c, &h2)) {
drivers/video/riva/riva_hw.c +2 -1
@@ -1240,7 +1240,8 @@ int CalcStateExtint dotClock ) { -int pixelDepth, VClk, m, n, p; +int pixelDepth; +int VClk =0 , m =0 , n =0 , p =0 ;/* * Save mode parameters. */
Signature · 6 lines
1.5.2 _______________________________________________ Kernel-janitors mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/kernel-janitors
Quoted 17 lines · Martin Baeuml
Fix some compile warnings:
warning: ‘*’ may be used uninitialized in this functionSigned-off-by Martin Baeuml <[email protected]>---
Compile tested on i386.
Diffed against Linus' git tree.drivers/video/matrox/matroxfb_maven.c | 6 +++--- drivers/video/riva/riva_hw.c | 3 ++- 2 files changed, 5 insertions(+), 4 deletions(-)drivers/video/matrox/matroxfb_maven.c +0
-0
drivers/video/matrox/matroxfb_maven.c static unsigned int matroxfb_mavenclock(const struct matrox_pll_ctl* ctl, · line 290
Quoted 8 lines
drivers/video/matrox/matroxfb_maven.c +1
-1@@ -284,7 +284,7 @@ static unsigned int matroxfb_mavenclock(const struct matrox_pll_ctl* ctl, unsigned int* in, unsigned int* feed, unsigned int* post, unsigned int* htotal2) { unsigned int fvco; -unsigned int p; +unsigned int p =0 ; fvco =matroxfb_PLL_mavenclock (&maven1000_pll, ctl, htotal, vtotal, in, feed, &p, htotal2);
matroxfb_PLL_mavenclock() will initialize this variable (have not checked the rest). When the compiler warns about "may be used uninitialized", it is code for "I have no clue what is happening". So most of them is alright and we need to check them by hand. There has been some attempt to fix this (the problem is, initialize them when it is not needed is just cruft) by some macros and such... I have done some minor testing to diff the output of builds (with trees pulled one week apart) to see when there is new warnings.
Richard Knutsson
_______________________________________________
Kernel-janitors mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/kernel-janitors
Quoted 2 lines · Richard Knutsson
matroxfb_PLL_mavenclock()will initialize this variable (have not checked the rest).
The rest will be initialized, too. This patch was only supposed to remove the warnings.
Quoted 5 lines
When the compiler warns about "may be used
uninitialized", it is code for "I have no clue what is happening". So most of them is alright and we need to check them by hand. There has been some attempt to fix this (the problem is, initialize them when it is not needed is just cruft) by some macros and such...
Is there a preferred way of removing such warnings then? I'd say it's ok to let the compiler generate one or two more instructions to remove the warning unless in very critical paths... Nobody should ever be able to measure this as a performance penalty.
Martin
_______________________________________________
Kernel-janitors mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/kernel-janitors
Quoted 17 lines · Martin Baeuml
Quoted 3 lines · Richard Knutsson
matroxfb_PLL_mavenclock()will initialize this variable (have not checked the rest).The rest will be initialized, too. This patch was only supposed to remove the warnings.
Quoted 6 lines
When the compiler warns about "may be used
uninitialized", it is code for "I have no clue what is happening". So most of them is alright and we need to check them by hand. There has been some attempt to fix this (the problem is, initialize them when it is not needed is just cruft) by some macros and such...
Quoted 5 lines
Is there a preferred way of removing such warnings then? I'd say it's ok to let the compiler generate one or two more instructions to remove the warning unless in very critical paths... Nobody should ever be able to measure this as a performance penalty.
Well, it is preferred to fix it where it is doing "wrong", in this case it is the compiler. Unfortunately this does not seem to be solved soon... Also, initializing the variable with a bogus value may hide bugs introduced later on.
Some quick searches in a lkml-archive should reveal some of the approaches.
Richard Knutsson
_______________________________________________
Kernel-janitors mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/kernel-janitors
Quoted 23 lines · Richard Knutsson
Quoted 17 lines · Martin Baeuml
Quoted 3 lines · Richard Knutsson
matroxfb_PLL_mavenclock()will initialize this variable (have not checked the rest).The rest will be initialized, too. This patch was only supposed to remove the warnings.
Quoted 6 lines
When the compiler warns about "may be used
uninitialized", it is code for "I have no clue what is happening". So most of them is alright and we need to check them by hand. There has been some attempt to fix this (the problem is, initialize them when it is not needed is just cruft) by some macros and such...Quoted 5 lines
Is there a preferred way of removing such warnings then? I'd say it's ok to let the compiler generate one or two more instructions to remove the warning unless in very critical paths... Nobody should ever be able to measure this as a performance penalty.
Quoted 5 lines
Well, it is preferred to fix it where it is doing "wrong", in this case it is the compiler. Unfortunately this does not seem to be solved soon... Also, initializing the variable with a bogus value may hide bugs introduced later on.
Some quick searches in a lkml-archive should reveal some of the approaches.
Thanks for the pointer. The macro uninitialized_var() has only recently been added for this matter ( http://marc.info/?l=linux-kernel&m7783880325621&w=2 ). The adjusted patch is below.
Thank you for your comments.
Martin
Fix some compiler warnings:
warning: '*' may be used uninitialized in this function
--- drivers/video/matrox/matroxfb_maven.c | 6 +++--- drivers/video/riva/riva_hw.c | 3 ++- 2 files changed, 5 insertions(+), 4 deletions(-)
drivers/video/matrox/matroxfb_maven.c +3 -3
@@ -284,7 +284,7 @@ static unsigned int matroxfb_mavenclock(const struct matrox_pll_ctl* ctl, unsigned int* in, unsigned int* feed, unsigned int* post, unsigned int* htotal2) { unsigned int fvco; -unsigned int p; +unsigned int uninitialized_var (p ); fvco =matroxfb_PLL_mavenclock (&maven1000_pll, ctl, htotal, vtotal, in, feed, &p, htotal2);if (!fvco)
@@ -305,7 +305,7 @@ static unsigned int matroxfb_mavenclock(const struct matrox_pll_ctl* ctl,static void DAC1064_calcclock (unsigned int freq,unsigned int fmax,unsigned int * in,unsigned int * feed,unsigned int * post) {unsigned int fvco; -unsigned int p; +unsigned int uninitialized_var (p ); fvco =matroxfb_PLL_calcclock (&maven_pll, freq, fmax, in, feed, &p); p = (1 << p) -1 ;
@@ -715,7 +715,7 @@ static int maven_find_exact_clocks(unsigned int ht, unsigned int vt, m->regs[0x82 ] =0x81 ;for (x =0 ; x <8 ; x++) { -unsigned int a, b, c, h2; +unsigned int uninitialized_var (a ),uninitialized_var (b ),uninitialized_var (c ),uninitialized_var (h2 );unsigned int h = ht +2 + x;if (!matroxfb_mavenclock ((m->mode =MATROXFB_OUTPUT_MODE_PAL ) ? &maven_PAL : &maven_NTSC, h, vt, &a, &b, &c, &h2)) {
drivers/video/riva/riva_hw.c +2 -1
@@ -1240,7 +1240,8 @@ int CalcStateExtint dotClock ) { -int pixelDepth, VClk, m, n, p; +int pixelDepth; +int uninitialized_var (VClk ),uninitialized_var (m ),uninitialized_var (n ),uninitialized_var (p );/* * Save mode parameters. */
Signature · 6 lines
1.5.2 _______________________________________________ Kernel-janitors mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/kernel-janitors