Question on compiler warning

Question on compiler warning

[Larry Finger]

In his regular article entitled Build regressions/improvements in v3.13-rc6" 
(http://lkml.indiana.edu/hypermail/linux/kernel/1312.3/01550.html), Geert 
Uytterhoeven reports the following warning regression:

+ /scratch/kisskb/src/drivers/net/wireless/b43/phy_n.c: warning: 'val_addr' may 
be used uninitialized in this function [-Wuninitialized]: => 178:21

This warning does not show up on any of my compilers, and it should not as the 
initialization and usage of that variable both take place in conditional 
branches that are testing exactly the same pointer.

Despite the fact that the warning is bogus, should a patch be submitted to clear 
it? I lean toward "no" as an answer because that would mask the warning if there 
were some future change that screwed up the flow; however, I wanted to check 
with the community.

Larry

Re: Question on compiler warning

[Geert Uytterhoeven]

On Tue, Dec 31, 2013 at 2:24 AM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> In his regular article entitled Build regressions/improvements in v3.13-rc6"
> (http://lkml.indiana.edu/hypermail/linux/kernel/1312.3/01550.html), Geert
> Uytterhoeven reports the following warning regression:
>
> + /scratch/kisskb/src/drivers/net/wireless/b43/phy_n.c: warning: 'val_addr'
> may be used uninitialized in this function [-Wuninitialized]: => 178:21
>
> This warning does not show up on any of my compilers, and it should not as
> the initialization and usage of that variable both take place in conditional
> branches that are testing exactly the same pointer.

It depends on the compiler version. Some versions of gcc are not smart enough
to notice all usage sites depends on the same condition.

> Despite the fact that the warning is bogus, should a patch be submitted to
> clear it? I lean toward "no" as an answer because that would mask the
> warning if there were some future change that screwed up the flow; however,
> I wanted to check with the community.

If it's clearly bogus, there's no reason to submit a patch.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Question on compiler warning

[Mark Cave-Ayland]

On 31/12/13 01:24, Larry Finger wrote:

> In his regular article entitled Build regressions/improvements in
> v3.13-rc6"
> (http://lkml.indiana.edu/hypermail/linux/kernel/1312.3/01550.html),
> Geert Uytterhoeven reports the following warning regression:
>
> + /scratch/kisskb/src/drivers/net/wireless/b43/phy_n.c: warning:
> 'val_addr' may be used uninitialized in this function [-Wuninitialized]:
> => 178:21
>
> This warning does not show up on any of my compilers, and it should not
> as the initialization and usage of that variable both take place in
> conditional branches that are testing exactly the same pointer.

Hi Larry,

Could it be that you don't see the issue the locally because you've got 
different compiler optimisation settings? I've seen a similar bug 
recently on another project where the "may be used uninitialized" 
warning appears with -O0 and -O1 but magically disappears with the 
default -O2 setting (presumably because the optimiser performs some kind 
of inlining/reordering that makes the issue go away).


HTH,

Mark.

Re: Question on compiler warning

[Larry Finger]

On 12/31/2013 04:56 AM, Mark Cave-Ayland wrote:
> Hi Larry,
>
> Could it be that you don't see the issue the locally because you've got
> different compiler optimisation settings? I've seen a similar bug recently on
> another project where the "may be used uninitialized" warning appears with -O0
> and -O1 but magically disappears with the default -O2 setting (presumably
> because the optimiser performs some kind of inlining/reordering that makes the
> issue go away).

Mark,

It is possible. Certainly, a higher optimization level will force the compiler 
to do a better job of flow analysis. I am using -O2, which is the standard in 
the kernel makefile. I would expect that Geert is also using the same lever, but 
perhaps not.

Larry

Re: Question on compiler warning

[David Rientjes]

On Mon, 30 Dec 2013, Larry Finger wrote:

> + /scratch/kisskb/src/drivers/net/wireless/b43/phy_n.c: warning: 'val_addr'
> may be used uninitialized in this function [-Wuninitialized]: => 178:21
> 
> This warning does not show up on any of my compilers, and it should not as the
> initialization and usage of that variable both take place in conditional
> branches that are testing exactly the same pointer.
> 

You may not be compiling this file depending on your .config or you may 
have a different setting for CONFIG_CC_OPTIMIZE_FOR_SIZE.

Re: Question on compiler warning

[Larry Finger]

On 01/02/2014 03:56 PM, David Rientjes wrote:
> On Mon, 30 Dec 2013, Larry Finger wrote:
>
>> + /scratch/kisskb/src/drivers/net/wireless/b43/phy_n.c: warning: 'val_addr'
>> may be used uninitialized in this function [-Wuninitialized]: => 178:21
>>
>> This warning does not show up on any of my compilers, and it should not as the
>> initialization and usage of that variable both take place in conditional
>> branches that are testing exactly the same pointer.
>>
>
> You may not be compiling this file depending on your .config or you may
> have a different setting for CONFIG_CC_OPTIMIZE_FOR_SIZE.

I am definitely building this driver in my configuration. Variable 
CONFIG_CC_OPTIMIZE_FOR_SIZE was not set, but changing it to "y" did not change 
the result.

Thanks,

Larry

Re: Question on compiler warning

[David Rientjes]

On Thu, 2 Jan 2014, Larry Finger wrote:

> I am definitely building this driver in my configuration. Variable
> CONFIG_CC_OPTIMIZE_FOR_SIZE was not set, but changing it to "y" did not change
> the result.
> 

I get this warning with gcc-4.6.3 and my gcc-4.5.1 cross compiler.