From mboxrd@z Thu Jan  1 00:00:00 1970
From: gregkh@linuxfoundation.org (Greg KH)
Date: Fri, 2 Feb 2018 14:13:28 +0100
Subject: clang warning: implicit conversion in intel_ddi.c:1481
In-Reply-To: <87h8qzisbt.fsf@intel.com>
References: <alpine.DEB.2.20.1802011823340.4316@alpaca>
 <20180201180240.GA28042@kroah.com>
 <alpine.DEB.2.20.1802012045570.29994@hsp>
 <87372jkcu5.fsf@intel.com>
 <alpine.DEB.2.20.1802021054500.13838@hsp>
 <20180202100613.GA21492@kroah.com> <87h8qzisbt.fsf@intel.com>
Message-ID: <20180202131328.GA4456@kroah.com>
To: kernelnewbies@lists.kernelnewbies.org
List-Id: kernelnewbies.lists.kernelnewbies.org

On Fri, Feb 02, 2018 at 12:44:38PM +0200, Jani Nikula wrote:
> 
> +Knut, Fengguang
> 
> On Fri, 02 Feb 2018, Greg KH <gregkh@linuxfoundation.org> wrote:
> > 	- If clang now builds the kernel "cleanly", yes, I want to take
> > 	  warning fixes in the stable tree.  And even better yet, if you
> > 	  keep working to ensure the tree is "clean", that would be
> > 	  wonderful.
> 
> So we can run sparse using 'make C=1' and friends, or other static
> analysis tools using 'make CHECK=foo C=1', as long as the passed command
> line params work. There was work by Knut to extend this make checker
> stuff [1]. Since mixing different HOSTCC's in a single workdir seems
> like a bad idea, I wonder how hard it would be to make clang work like
> this:
> 
> $ make CHECK=clang C=1
> 
> Or using Knut's wrapper. Feels like that could increase the use of clang
> for static analysis of patches.

Why not just build with clang itself:
	make CC=clang

thanks,

greg k-h