kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
From: knut.omang@oracle.com (Knut Omang)
To: kernelnewbies@lists.kernelnewbies.org
Subject: clang warning: implicit conversion in intel_ddi.c:1481
Date: Sat, 03 Feb 2018 08:04:05 +0100	[thread overview]
Message-ID: <1517641445.3118.342.camel@oracle.com> (raw)
In-Reply-To: <20180202155022.GA29918@kroah.com>

On Fri, 2018-02-02 at 16:50 +0100, Greg KH wrote:
> On Fri, Feb 02, 2018 at 04:37:55PM +0200, Jani Nikula wrote:
> > On Fri, 02 Feb 2018, Greg KH <gregkh@linuxfoundation.org> wrote:
> > > 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
> > 
> > Same as HOSTCC, mixing different CC's in a single build dir seems like a
> > bad idea. Sure, everyone can setup a separate build dir for clang, but
> > IMHO having 'make CHECK=clang C=1' work has least resistance. YMMV.
> 
> "O=some_output_dir" is your friend.  If you aren't doing that already
> for your test builds, you don't know what you are missing :)

I use O= a lot myself - so good not to have all the output files "pollute" the source
tree, and to be able to switch branches and compile without having to recompile everything
by having multiple O= set up.

I think what my runchecks wrapper script brings in addition is the ability to to a number
of checks which may or may not pass, even return error codes, from the same 'make' command
and configure what errors to fix now and what to postpone/ignore (and thus not fail from).

As an example, I just tried clang (on v4.15-rc6) with:

cd $HOME/src/kernel
make O=$HOME/build/kernel/clang
cd $HOME/build/kernel/clang
make

and it fails to compile for me in arch/x86/xen/mmu_pv.o. 

If I'd want to just make sure that some patches did not introduce new errors with clang, 
I would waste some time with unrelated errors, and there will be noise in the output, also
consuming personal "cycles".

I haven't really looked at the details of much of what clang outputs of errors yet, but I
can imagine that specific errors reported by clang might be useful to correct even in old
kernels, where some files inevitably will fail to compile like this.

This would be easy to handle with runchecks using a few exceptions for those
problems/files not yet fixed, allowing a run to easily detect (while compiling with gcc as
the main compiler) that no new clang errors were introduced of any other kind than those
suppressed.

Thanks,
Knut

> 
> thanks,
> 
> greg k-h

  reply	other threads:[~2018-02-03  7:04 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-01 17:33 clang warning: implicit conversion in intel_ddi.c:1481 Ozan Alpay
2018-02-01 18:02 ` Greg KH
2018-02-01 19:27   ` Ozgur
2018-02-01 22:13   ` Lukas Bulwahn
2018-02-02  8:36     ` Jani Nikula
2018-02-02  9:56       ` Lukas Bulwahn
2018-02-02 10:06         ` Greg KH
2018-02-02 10:44           ` Jani Nikula
2018-02-02 11:04             ` Knut Omang
2018-02-02 13:13             ` Greg KH
2018-02-02 14:37               ` Jani Nikula
2018-02-02 15:50                 ` Greg KH
2018-02-03  7:04                   ` Knut Omang [this message]
2018-02-05 18:46     ` Ruben Safir
2018-02-02 14:33   ` Ruben Safir

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1517641445.3118.342.camel@oracle.com \
    --to=knut.omang@oracle.com \
    --cc=kernelnewbies@lists.kernelnewbies.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).