1. 12 11月, 2016 1 次提交
    • A
      Kbuild: enable -Wmaybe-uninitialized warning for "make W=1" · a76bcf55
      Arnd Bergmann 提交于
      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: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a76bcf55
  2. 11 5月, 2016 1 次提交
    • A
      kbuild: move -Wunused-const-variable to W=1 warning level · c9c6837d
      Arnd Bergmann 提交于
      gcc-6 started warning by default about variables that are not
      used anywhere and that are marked 'const', generating many
      false positives in an allmodconfig build, e.g.:
      
      arch/arm/mach-davinci/board-da830-evm.c:282:20: warning: 'da830_evm_emif25_pins' defined but not used [-Wunused-const-variable=]
      arch/arm/plat-omap/dmtimer.c:958:34: warning: 'omap_timer_match' defined but not used [-Wunused-const-variable=]
      drivers/bluetooth/hci_bcm.c:625:39: warning: 'acpi_bcm_default_gpios' defined but not used [-Wunused-const-variable=]
      drivers/char/hw_random/omap-rng.c:92:18: warning: 'reg_map_omap4' defined but not used [-Wunused-const-variable=]
      drivers/devfreq/exynos/exynos5_bus.c:381:32: warning: 'exynos5_busfreq_int_pm' defined but not used [-Wunused-const-variable=]
      drivers/dma/mv_xor.c:1139:34: warning: 'mv_xor_dt_ids' defined but not used [-Wunused-const-variable=]
      
      This is similar to the existing -Wunused-but-set-variable warning
      that was added in an earlier release and that we disable by default
      now and only enable when W=1 is set, so it makes sense to do
      the same here. Once we have eliminated the majority of the
      warnings for both, we can put them back into the default list.
      
      We probably want this in backport kernels as well, to allow building
      them with gcc-6 without introducing extra warnings.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NOlof Johansson <olof@lixom.net>
      Acked-by: NLee Jones <lee.jones@linaro.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: NMichal Marek <mmarek@suse.com>
      c9c6837d
  3. 12 1月, 2016 1 次提交
    • L
      kbuild: Demote 'sign-compare' warning to W=2 · 7599ea8b
      Lee Jones 提交于
      Ideally, a kernel compile with W=1 enabled should complete cleanly;
      however, when we run one currently we are presented with ~25k warnings.
      'sign-compare' accounts for ~22k of those ~25k.
      
      In this patch we're demoting 'sign-compare' warnings to W=2, with a view
      to fixing the remaining 3k W=1 warnings required for a clean build.
      
      Arnd adds:
        "As per our discussion, I'd add that this was inadvertedly introduced
         by Behan when he moved the clang specific warnings into an ifdef block
         and did not notice that -Wsign-compare was interpreted by both gcc
         and clang.
      
         Earlier, it was introduced in just the same way by Jan-Simon as part
         of 3d3d6b84 ("kbuild: LLVMLinux: Adapt warnings for compilation
         with clang")."
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Fixes: 26ea6bb1 ("kbuild, LLVMLinux: Supress warnings unless W=1-3")
      Signed-off-by: NLee Jones <lee.jones@linaro.org>
      Signed-off-by: NMichal Marek <mmarek@suse.com>
      7599ea8b
  4. 04 9月, 2015 1 次提交
  5. 05 8月, 2014 1 次提交
  6. 17 4月, 2014 1 次提交