linux-gcc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: Borislav Petkov <bp@alien8.de>
Cc: Amy Parker <enbyamy@gmail.com>,
	linux-kernel@vger.kernel.org, linux-gcc@vger.kernel.org,
	linux-kbuild@vger.kernel.org, Michael Matz <matz@suse.de>
Subject: Re: Alternative compilers to GCC/Clang
Date: Tue, 2 Feb 2021 22:41:01 +0100	[thread overview]
Message-ID: <20210202214101.GA29871@1wt.eu> (raw)
In-Reply-To: <20210202212048.GG18075@zn.tnic>

On Tue, Feb 02, 2021 at 10:20:48PM +0100, Borislav Petkov wrote:
> It would be good to start forward-porting and integrating some of the
> fixes and even extend tcc to handle some of the gnuisms we're using in
> the kernel so that we can build the kernel with it too.

I agree. And the team is responsive and shows great consideration for
patches.

> I can imagine having CONFIG_TCC - as long as that doesn't get too
> intrusive and get in the way of things - and those who wanna build the
> kernel with it, can enable it. For example...

I like this idea. It's way better than having to implement everything
at once or degrade some code just to make it build. It could be solved
at config time by automatically excluding some features.

It should also be less of a hassle than dealing with many gcc versions
because if we see it as a development speed up tool we can easily accept
that we occasionaly break compatibility with older of its versions and
that those who want to use it just rebuild the latest one (it's trivial
and fast, basically "make" and you're done, not the typical toolchain
experience). You don't care if it doesn't work for one week, you're not
supposed to ship any form of official code built with it anyway. It's
just an aid, and a nice one.

Willy

  reply	other threads:[~2021-02-02 21:41 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-01 23:31 Alternative compilers to GCC/Clang Amy Parker
2021-02-02  5:33 ` Willy Tarreau
2021-02-02 16:26   ` Amy Parker
2021-02-02 19:11     ` Amy Parker
2021-02-02 20:19       ` Borislav Petkov
2021-02-02 21:00         ` Willy Tarreau
2021-02-02 21:20           ` Borislav Petkov
2021-02-02 21:41             ` Willy Tarreau [this message]
2021-02-02 23:20             ` Michael Matz
2021-03-10  8:53   ` Pavel Machek

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=20210202214101.GA29871@1wt.eu \
    --to=w@1wt.eu \
    --cc=bp@alien8.de \
    --cc=enbyamy@gmail.com \
    --cc=linux-gcc@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matz@suse.de \
    /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 read-only IMAP folder(s) and NNTP newsgroup(s).