Skip to content
  • Arnd Bergmann's avatar
    Kbuild: enable -Wmaybe-uninitialized warning for "make W=1" · a76bcf55
    Arnd Bergmann authored
    Traditionally, we have always had warnings about uninitialized variables
    enabled, as this is part of -Wall, and generally a good idea [1], but it
    also always produced false positives, mainly because this is a variation
    of the halting problem and provably impossible to get right in all cases
    [2].
    
    Various people have identified cases that are particularly bad for false
    positives, and in commit e74fc973 ("Turn off -Wmaybe-uninitialized
    when building with -Os"), I turned off the warning for any build that
    was done with CC_OPTIMIZE_FOR_SIZE.  This drastically reduced the number
    of false positive warnings in the default build but unfortunately had
    the side effect of turning the warning off completely in 'allmodconfig'
    builds, which in turn led to a lot of warnings (both actual bugs, and
    remaining false positives) to go in unnoticed.
    
    With commit 877417e6 ("Kbuild: change CC_OPTIMIZE_FOR_SIZE
    definition") enabled the warning again for allmodconfig builds in v4.7
    and in v4.8-rc1, I had finally managed to address all warnings I get in
    an ARM allmodconfig build and most other maybe-uninitialized warnings
    for ARM randconfig builds.
    
    However, commit 6e8d666e ("Disable "maybe-uninitialized" warning
    globally") was merged at the same time and disabled it completely for
    all configurations, because of false-positive warnings on x86 that I had
    not addressed until then.  This caused a lot of actual bugs to get
    merged into mainline, and I sent several dozen patches for these during
    the v4.9 development cycle.  Most of these are actual bugs, some are for
    correct code that is safe because it is only called under external
    constraints that make it impossible to run into the case that gcc sees,
    and in a few cases gcc is just stupid and finds something that can
    obviously never happen.
    
    I have now done a few thousand randconfig builds on x86 and collected
    all patches that I needed to address every single warning I got (I can
    provide the combined patch for the other warnings if anyone is
    interested), so I hope we can get the warning back and let people catch
    the actual bugs earlier.
    
    This reverts the change to disable the warning completely and for now
    brings it back at the "make W=1" level, so we can get it merged into
    mainline without introducing false positives.  A follow-up patch enables
    it on all levels unless some configuration option turns it off because
    of false-positives.
    
    Link: https://rusty.ozlabs.org/?p=232 [1]
    Link: https://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
    
     [2]
    Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    a76bcf55