linux-toolchains.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Linus Torvalds <torvalds@linuxfoundation.org>,
	Segher Boessenkool <segher@kernel.crashing.org>,
	Nathan Chancellor <nathan@kernel.org>,
	Masahiro Yamada <masahiroy@kernel.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	clang-built-linux <clang-built-linux@googlegroups.com>,
	llvm@lists.linux.dev, linux-toolchains@vger.kernel.org
Subject: Re: [GIT PULL v2] Kbuild updates for v5.15-rc1
Date: Mon, 06 Sep 2021 08:54:13 +0200	[thread overview]
Message-ID: <87a6kq2nze.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <CAHk-=wi+XKYN+3u=_fm=ExqpEaHdER0XuKxVauHYVCPKpKR97Q@mail.gmail.com> (Linus Torvalds's message of "Sat, 4 Sep 2021 10:22:25 -0700")

* Linus Torvalds:

> On Sat, Sep 4, 2021 at 8:19 AM Florian Weimer <fweimer@redhat.com> wrote:
>>
>> In any case, it would be nice to know what the real motivation is.
>
> I don't know about the original motivation, but the reason I like that
> patch after-the-fact is that I've actually been in situations where I
> test out self-built compilers without installing them.

Does this really simplify matters?  Why wouldn't the gcc compiler driver
find cc1, but not be able to pass the right path options, so that the
include/ subdirectory can be located as well?

> Then it's convenient to have a completely standalone kernel tree.

The final patch in the series is here:

  isystem: delete global -isystem compile option
  <https://lore.kernel.org/linux-kernel/YQhY40teUJcTc5H4@localhost.localdomain/>

It's still not self-contained.  And it seems that there has been quite a
bit of fallout from the removal of <stddef.h>.

> Nobody cares about things like <stdatomic.h> They are completely
> irrelevant for the kernel, exactly because we've always just done our
> own, or used __builtin_xyz() for things.

Apparently, some people care enough about <stdatomic.h> to prevent its
use.  I still have not seen an explanation.  Maybe it's because we
haven't Cc:ed the patch author so far (oops).

Alexey, why are <stdatomic.h> and <float.h> so special that you called
them out in your patch?

If it's about unintended use of libatomic, then maybe we should work on
a proper compiler option that also works for __atomic builtins and the
_Atomic keyword.

Thanks,
Florian


  parent reply	other threads:[~2021-09-06  6:54 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAK7LNAQ0Q6CdXaD-dVGj_e3O3JYs_crpejWKpXHYQJYxyk-1VQ@mail.gmail.com>
     [not found] ` <CAHk-=wgoX0pVqNMMOcrhq=nuOfoZB_3qihyHB3y1S8qo=MDs6w@mail.gmail.com>
2021-09-03 23:04   ` [GIT PULL v2] Kbuild updates for v5.15-rc1 Nathan Chancellor
2021-09-04  8:01     ` Florian Weimer
2021-09-04 13:19       ` Segher Boessenkool
2021-09-04 15:19         ` Florian Weimer
2021-09-04 16:19           ` Segher Boessenkool
2021-09-04 17:22           ` Linus Torvalds
2021-09-04 19:15             ` Segher Boessenkool
2021-09-04 19:58               ` Linus Torvalds
2021-09-06 15:46                 ` Segher Boessenkool
2021-09-06 16:30                   ` Linus Torvalds
2021-09-06 17:27                     ` Segher Boessenkool
2021-09-06 18:11                       ` Linus Torvalds
2021-09-06 18:27                         ` Florian Weimer
2021-09-06 19:48                           ` Segher Boessenkool
2021-09-06 20:14                             ` Jakub Jelinek
2021-09-06 21:08                               ` Linus Torvalds
2021-09-06 21:24                                 ` Linus Torvalds
2021-09-07 14:41                                   ` Segher Boessenkool
2021-09-06 21:52                                 ` Jakub Jelinek
2021-09-06 22:24                                   ` Linus Torvalds
2021-09-07 15:26                                     ` Segher Boessenkool
2021-09-07 14:52                                   ` Segher Boessenkool
2021-09-09  5:14                                     ` Masahiro Yamada
2021-09-07 14:29                                 ` Segher Boessenkool
2021-09-06  6:54             ` Florian Weimer [this message]
2021-09-06 16:02               ` Alexey Dobriyan
2021-09-08  3:09                 ` Masahiro Yamada

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=87a6kq2nze.fsf@oldenburg.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=adobriyan@gmail.com \
    --cc=clang-built-linux@googlegroups.com \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-toolchains@vger.kernel.org \
    --cc=llvm@lists.linux.dev \
    --cc=masahiroy@kernel.org \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=segher@kernel.crashing.org \
    --cc=torvalds@linuxfoundation.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).