Re: [PATCH] drm/i915/bxt: Fix uninitialized variables in intel_check_sprite_plane

From: Daniel Vetter <daniel@ffwll.ch>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915/bxt: Fix uninitialized variables in intel_check_sprite_plane
Date: Thu, 10 Dec 2015 09:42:28 +0100	[thread overview]
Message-ID: <20151210084228.GY20822@phenom.ffwll.local> (raw)
In-Reply-To: <87bna1xk3c.fsf@intel.com>

On Tue, Dec 08, 2015 at 01:20:39PM +0200, Jani Nikula wrote:
> On Mon, 07 Dec 2015, Nabendu Maiti <nabendu.bikash.maiti@intel.com> wrote:
> > On 11/26/2015 11:33 PM, Nabendu Maiti wrote:
> >>
> >>
> >> On 11/18/2015 10:56 PM, Ville Syrjälä wrote:
> >>> On Wed, Nov 18, 2015 at 10:33:55PM +0530, Maiti, Nabendu Bikash wrote:
> >>>>
> >>>> On 11/18/2015 7:00 PM, Ville Syrjälä wrote:
> >>>>> On Wed, Nov 18, 2015 at 06:48:37PM +0530, Maiti, Nabendu Bikash wrote:
> >>>>>> Then just one line change of initializing the variables is better?
> >>>>> Or maybe fix your compiler instead? I don't get any warning/errors 
> >>>>> from
> >>>>> this. What version of gcc are you using?
> >>>>    I still get the warning and error if -Werror is enabled, And on
> >>>> Makefile O1 optimization is enabled.
> >>> And why exactly are you building with -O1?
> >> I am using it for platform level debug symbol inclusion in elf which 
> >> are excluded in Os/O2 . We need it.Else it will break generic kernel.
> > Any comments? Please let me know if anything need to be done from my side.
> 
> Nobody is doing anything about this because it's the compiler being
> silly.
> 
> We could merge your patch (provided it said this was a compiler issue)
> but frankly it wouldn't take long for someone to submit a patch to drop
> the unnecessary initializations again.
> 
> We could probably rearrange the code to avoid warnings (e.g. use a local
> temp variable for state->visible, or use "goto out" where state->visible
> is set to false) but seems like a lot of churn just to make a silly tool
> happy.
> 
> Your build is bound to produce a lot of false positives across the whole
> kernel build. What do you do with those?

Also I never had problem compiling with debug symbols. Well I only use
them to let gdb help me read binary code, but it works for that ;-)

What exactly are you trying to do here?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx