From: gregkh@linuxfoundation.org (Greg KH)
To: kernelnewbies@lists.kernelnewbies.org
Subject: clang warning: implicit conversion in intel_ddi.c:1481
Date: Fri, 2 Feb 2018 16:50:22 +0100 [thread overview]
Message-ID: <20180202155022.GA29918@kroah.com> (raw)
In-Reply-To: <871si3ihj0.fsf@intel.com>
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 :)
thanks,
greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@linuxfoundation.org>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: sil2review@lists.osadl.org, kernelnewbies@kernelnewbies.org,
David Airlie <airlied@linux.ie>,
llvmlinux@lists.linuxfoundation.org,
intel-gfx@lists.freedesktop.org,
Knut Omang <knut.omang@oracle.com>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Ozan Alpay <ozyalpy@gmail.com>,
Lukas Bulwahn <lukas.bulwahn@gmail.com>
Subject: Re: clang warning: implicit conversion in intel_ddi.c:1481
Date: Fri, 2 Feb 2018 16:50:22 +0100 [thread overview]
Message-ID: <20180202155022.GA29918@kroah.com> (raw)
In-Reply-To: <871si3ihj0.fsf@intel.com>
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 :)
thanks,
greg k-h
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@linuxfoundation.org>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: sil2review@lists.osadl.org, kernelnewbies@kernelnewbies.org,
"David Airlie" <airlied@linux.ie>,
llvmlinux@lists.linuxfoundation.org,
intel-gfx@lists.freedesktop.org,
"Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>,
"Knut Omang" <knut.omang@oracle.com>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
"Ozan Alpay" <ozyalpy@gmail.com>,
"Lukas Bulwahn" <lukas.bulwahn@gmail.com>,
"Ville Syrjälä" <ville.syrjala@linux.intel.com>
Subject: Re: clang warning: implicit conversion in intel_ddi.c:1481
Date: Fri, 2 Feb 2018 16:50:22 +0100 [thread overview]
Message-ID: <20180202155022.GA29918@kroah.com> (raw)
In-Reply-To: <871si3ihj0.fsf@intel.com>
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 :)
thanks,
greg k-h
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
next prev parent reply other threads:[~2018-02-02 15:50 UTC|newest]
Thread overview: 41+ 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 17:33 ` Ozan Alpay
2018-02-01 17:33 ` Ozan Alpay
2018-02-01 18:02 ` Greg KH
2018-02-01 18:02 ` Greg KH
2018-02-01 18:02 ` Greg KH
2018-02-01 19:27 ` Ozgur
2018-02-01 19:27 ` Ozgur
2018-02-01 19:27 ` Ozgur
2018-02-01 22:13 ` Lukas Bulwahn
2018-02-01 22:13 ` Lukas Bulwahn
2018-02-02 8:36 ` Jani Nikula
2018-02-02 8:36 ` Jani Nikula
2018-02-02 8:36 ` Jani Nikula
2018-02-02 9:56 ` Lukas Bulwahn
2018-02-02 9:56 ` Lukas Bulwahn
2018-02-02 10:06 ` Greg KH
2018-02-02 10:06 ` Greg KH
2018-02-02 10:06 ` Greg KH
2018-02-02 10:44 ` Jani Nikula
2018-02-02 10:44 ` Jani Nikula
2018-02-02 10:44 ` Jani Nikula
2018-02-02 11:04 ` Knut Omang
2018-02-02 11:04 ` Knut Omang
2018-02-02 13:13 ` Greg KH
2018-02-02 13:13 ` Greg KH
2018-02-02 13:13 ` Greg KH
2018-02-02 14:37 ` Jani Nikula
2018-02-02 14:37 ` Jani Nikula
2018-02-02 14:37 ` Jani Nikula
2018-02-02 15:50 ` Greg KH [this message]
2018-02-02 15:50 ` Greg KH
2018-02-02 15:50 ` Greg KH
2018-02-03 7:04 ` Knut Omang
2018-02-03 7:04 ` Knut Omang
2018-02-05 18:46 ` Ruben Safir
2018-02-05 18:46 ` Ruben Safir
2018-02-05 18:46 ` Ruben Safir
2018-02-02 14:33 ` Ruben Safir
2018-02-02 14:33 ` 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=20180202155022.GA29918@kroah.com \
--to=gregkh@linuxfoundation.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.