Quoting Michal Wajdeczko (2017-10-14 21:02:05) > On Sat, 14 Oct 2017 12:12:50 +0200, Chris Wilson > > diff --git a/drivers/gpu/drm/i915/Makefile > > b/drivers/gpu/drm/i915/Makefile > > index 52f0f8f101ec..e1bbb2565426 100644 > > --- a/drivers/gpu/drm/i915/Makefile > > +++ b/drivers/gpu/drm/i915/Makefile > > @@ -15,7 +15,6 @@ subdir-ccflags-y := -Wall -Wextra > > subdir-ccflags-y += $(call cc-option,-Wno-unused-parameter,) > > subdir-ccflags-y += $(call cc-option,-Wno-type-limits,) > > subdir-ccflags-y += $(call cc-option,-Wno-missing-field-initializers,) > > -subdir-ccflags-y += $(call cc-option,-Wno-override-init,) > > Maybe it would be better to re-order patches to avoid this step My intention was for this to be an example of the steps we probably want to take with these and new warnings in future. If gcc brings in a new warning, we will probably first do the simple patch to disable it, and then a series to fix the errors before re-enabling. Simply to minimise the pain of breaking the build. > > subdir-ccflags-y += $(call cc-option,-Wno-implicit-fallthrough,) > > subdir-ccflags-$(CONFIG_DRM_I915_WERROR) += -Werror > > diff --git a/drivers/gpu/drm/i915/i915_pci.c > > b/drivers/gpu/drm/i915/i915_pci.c > > index bf467f30c99b..2ad0738eb2e7 100644 > > --- a/drivers/gpu/drm/i915/i915_pci.c > > +++ b/drivers/gpu/drm/i915/i915_pci.c > > @@ -29,6 +29,9 @@ > > #include "i915_drv.h" > > #include "i915_selftest.h" > > +#pragma GCC diagnostic push > > +#pragma GCC diagnostic ignored "-Woverride-init" /* used for > > inheritance */ > > + > > As -Wextra is also supported by clang then maybe it's worth do add Bleh. I guess we actually want to make the -Werror conditional on using gcc. I don't really want to maintain two sets of suppressions, we already multiple for different gcc versions, but anything outside of common use (read CI) simply won't be used that much and liable to rot. Otoh, if did compile every patch with both gcc and clang, that should give us the widest set of error detection -- and possibly also the most noise. clang is not a drop in replacement, that increases the burden of adoption significantly. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
