mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Fengguang Wu <fengguang.wu@intel.com>
To: Sedat Dilek <sedat.dilek@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: Use (two) different compilers at build-time?
Date: Mon, 14 Sep 2015 10:13:22 +0800	[thread overview]
Message-ID: <20150914021322.GA18239@wfg-t540p.sh.intel.com> (raw)
In-Reply-To: <CA+icZUVhqpCDXB_zswRiQ4zviNKh=Zb6Yw2jJUts89XkMtV=8A@mail.gmail.com>

On Sun, Sep 13, 2015 at 05:21:41PM +0200, Sedat Dilek wrote:
> On Thu, Sep 10, 2015 at 2:25 AM, Fengguang Wu <fengguang.wu@intel.com> wrote:
> > On Mon, Sep 07, 2015 at 09:12:58PM +0200, Sedat Dilek wrote:
> >> Hi,
> >>
> >> is it possible to use a different compiler at build-time?
> >
> > btw, it'd be great if clang can just work on mainline kernel.
> >
> 
> I am not a member of that LLVMLinux team, but they upstreamed a lot of patches.
> 
> > I tried to run clang in 0day kbuild tests, however make aborts
> > quickly in seconds. There are dozens of clang patches provided in
> >
> >     http://llvm.linuxfoundation.org/index.php/Main_Page
> >
> > however such our-of-tree patches are not bisect friendly.
> >
> 
> I agree, there is a high potential for improvements in LLVMLinux :-).
> 
> Unfortunately, I struggled here some days with $COMPILER's
> inline-optimization (disable | force| noinline) and it turned out to
> be a "known" x86-hweight issue (a patch was archived and thrown away
> from the series of x86 patches).
> 
> Finally, I have a "buildable" and "running-on-bare-metal"
> llvmlinux-patched Linux v4.2 here on Ubuntu/precise AMD64.

That's great!

> It is everytime interesting to see where the root cause sits.
> It's like in everyday life - never assume - just ask - stay curious
> and attentive :-).

If upstream kernels can just work (at least work for one kconfig),
I'll be able to follow up add run regular 0day build tests for LLVM.
Which should guarantee new break ups are detected ASAP and hopefully
the developer that breaks it may help fix it up "automatically". :-)

Thanks,
Fengguang

      reply	other threads:[~2015-09-14  2:13 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-07 19:12 Sedat Dilek
2015-09-07 20:15 ` Linus Torvalds
2015-09-07 20:31   ` Sedat Dilek
2015-09-07 20:42     ` Linus Torvalds
2015-09-07 20:53       ` Sedat Dilek
2015-09-07 20:59         ` Linus Torvalds
2015-09-07 21:20           ` Sedat Dilek
2015-09-07 22:30             ` Sedat Dilek
2015-09-08  5:45               ` Sedat Dilek
2015-09-08  5:55                 ` Sedat Dilek
2015-09-10  0:25 ` Fengguang Wu
2015-09-13 15:21   ` Sedat Dilek
2015-09-14  2:13     ` Fengguang Wu [this message]

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=20150914021322.GA18239@wfg-t540p.sh.intel.com \
    --to=fengguang.wu@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sedat.dilek@gmail.com \
    --cc=torvalds@linux-foundation.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

all inboxes | Powered by JetHome®