Received: by 2002:a05:6a10:eb17:0:0:0:0 with SMTP id hx23csp3835720pxb; Tue, 7 Sep 2021 08:34:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz0kzCCZZr9PXxZ1POUuK9bmxOcA1Tx/+gi37gG0nZwKuqpFjIssmNMogdop7LOt8r4T+3c X-Received: by 2002:a17:906:7250:: with SMTP id n16mr18986570ejk.147.1631028868718; Tue, 07 Sep 2021 08:34:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631028868; cv=none; d=google.com; s=arc-20160816; b=qlVmVBcYwG3hmf/+2mRuqUX/69RvVliiAbY7n0JmKk+coJbXDWlNzPfTeHiumxL1dp Svdvkzohni/K04GPY6n0QuxCjneeA0uD65s8uOlqmAKBHmGULhDTqHd2CCVbzMQ2Ljnk pASGJaqs9ieMjTgtqRb6gVdpLa5hh1oX65NV5UGxnybYH7aH6BII9gNhM3IW7MpwHSCc /Lw9e/ZDQqo0clJNXJH1PchSneEUUm/DC3e9hM0WWhcItvs4EVcUjLcCnrdcsNgBvH5n 8BzsRDLZ8AdrLH9Nh0wEi5orjfodXzL5RkoZ3o/88VEMHRzfBb0373/T02QhOK1j/vEt /l7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=RxPUL4Fz6ueYkWOA5l/E6gb1g8mBLW1NR7jxxFF5iDE=; b=MPY4yOiaf26VEvHMc6R3TFB/RNrF7LPG+V+LDlSnbSNHbIyTUWcvm8u3J9bITT/QTT 3FwzEUjDljawcn5uQeLjyiNQPZ8lzsKXpx13VQOcf+rMZ9l9fT9g62zeaNvScZ25KpOi 1zf1VE4lrse7yKhdvXW7hg/zLdZTbpCNW2uTR9hSCWDKLsZpHYkEROZD+lbrjSgVvh8/ SCPUM8/jDgZ0nstxJ74UkTjpf5IzC9uNwrDujMSm91e2qbjhsdQ6bVV6MEnILqsQIqnH SvAGNn0fP3hZlRLQt6ymZg6UWWtl2BYYGhwJgCpMX8mdoHAHgGvoYTbIDLTyZJ8yAaD0 OysQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f25si12614021ejh.250.2021.09.07.08.34.05; Tue, 07 Sep 2021 08:34:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345270AbhIGPcS (ORCPT + 99 others); Tue, 7 Sep 2021 11:32:18 -0400 Received: from gate.crashing.org ([63.228.1.57]:49179 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345158AbhIGPcQ (ORCPT ); Tue, 7 Sep 2021 11:32:16 -0400 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 187FQwd6012880; Tue, 7 Sep 2021 10:26:58 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 187FQuaU012874; Tue, 7 Sep 2021 10:26:56 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Tue, 7 Sep 2021 10:26:56 -0500 From: Segher Boessenkool To: Linus Torvalds Cc: Jakub Jelinek , Florian Weimer , Nathan Chancellor , Masahiro Yamada , Nick Desaulniers , Linux Kbuild mailing list , Linux Kernel Mailing List , clang-built-linux , llvm@lists.linux.dev, linux-toolchains@vger.kernel.org Subject: Re: [GIT PULL v2] Kbuild updates for v5.15-rc1 Message-ID: <20210907152656.GI1583@gate.crashing.org> References: <20210906154642.GV1583@gate.crashing.org> <20210906172701.GX1583@gate.crashing.org> <87lf49wodu.fsf@oldenburg.str.redhat.com> <20210906194808.GY1583@gate.crashing.org> <20210906201432.GZ920497@tucnak> <20210906215218.GA920497@tucnak> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 06, 2021 at 03:24:41PM -0700, Linus Torvalds wrote: > On Mon, Sep 6, 2021 at 2:52 PM Jakub Jelinek wrote: > > > > It is actually not that bad, stdlib.h is indeed included there because of 2 > > intrinsics out of more than 5000 and when one doesn't need those, just > > #define _MM_MALLOC_H_INCLUDED > > .. and on clang? Clang apparently has __MM_MALLOC_H as header guard here. But Clang does say #if __STDC_HOSTED__ #include #endif so they do not have this bug in the first place. GCC should fix this as well. I filed . Thanks for bringing thisd to our attention! > There, I think you have to undefine __STDC_HOSTED__. Maybe by using > -ffreestanding? That defines it to 0, instead, as required by the C standard: $ :|gcc -E -dM -|grep HOSTED #define __STDC_HOSTED__ 1 $ :|gcc -E -dM - -ffreestanding|grep HOSTED #define __STDC_HOSTED__ 0 Yes, that is how this works: the command line flag says how the macro should be defined by the compiler (and changing it in your code is UB btw). > Except if you use -ffreestanding, you lose some very bvasic > functionality (*), (see below) > And they should very much *not*at*all* be considered some kind of > sacred "this is the only way to do things". Because that is clearly > not true, and has *never* been true. Take for example . There is no other way to find out what types to use for exact-width integers. Unless you really want to do typedef unsigned int __attribute__((mode (DI))) u64; but that is rather unportable to other compilers but GCC. *is* the only portable way for getting exact-width integers (and some other things). This is not something we decide, it is not something you can decide, it follows directly from the C standard. Using it is easy. Not using it leads to the forest of include files and preprocessor conditionals the kernel currently uses. > The usable header files are the odd special case, not the general case. > > Really. > > Is it really so hard to just admit that the kernel shouldn't use those > headers? When we have 30 years of experience in doing exactly that? That isn't the core issue at hand. Yes, Linux has implemented all of it manually historically, and there even were good reasons for some of that. That does not mean that it would be a good idea to throw out the few standard C headers it does use, and implement those with compiler internal interfaces instead, which we advice you against. > (*) iirc, with -ffreestanding gcc doesn't do all the basic memcpy() > optimizations. But I forget the exact details. I would love to hear any details about that. I do know the Glibc headers do (or did?) some premature optimisation wrt. some mem* and str*, hurting performance on newer compilers. But you should not be using the Glibc headers for compiling the kernel at all anyway, so maybe there was some bug thereabouts? Segher