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
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.
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
On Tue, Dec 31, 2013 at 2:24 AM, Larry Finger <[email protected]> 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 -- [email protected]
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
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.
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
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.