From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1E1A672 for ; Mon, 6 Sep 2021 21:52:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1630965152; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=RiQRlnc+QePT23Ng+AhQWm6c9mQGSn/3BlHMqrjDwFk=; b=FIA6gbJ4RxmqooOh/hXT+GMzZ5urZSaNKJL+BfnPbFYHwthTau3ysQ8si1hc1h+uA80HYh YteUgbFx1kHtAxbj7FfMeGRtcgtYjNB1s3JUvRtzqmMTeRzk4MHFOmIOwgruZL55/yySJu oHZ9VIKutz5x0V0se0EENuOWO3QHGkE= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-185-ElLduOG-PemaJUlHEYPt9Q-1; Mon, 06 Sep 2021 17:52:31 -0400 X-MC-Unique: ElLduOG-PemaJUlHEYPt9Q-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0995A80196C; Mon, 6 Sep 2021 21:52:30 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.10]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A295F5D9CA; Mon, 6 Sep 2021 21:52:28 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.16.1/8.16.1) with ESMTPS id 186LqIvf393816 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 6 Sep 2021 23:52:18 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 186LqIUA393220; Mon, 6 Sep 2021 23:52:18 +0200 Date: Mon, 6 Sep 2021 23:52:18 +0200 From: Jakub Jelinek To: Linus Torvalds Cc: Segher Boessenkool , 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: <20210906215218.GA920497@tucnak> Reply-To: Jakub Jelinek References: <20210904191531.GS1583@gate.crashing.org> <20210906154642.GV1583@gate.crashing.org> <20210906172701.GX1583@gate.crashing.org> <87lf49wodu.fsf@oldenburg.str.redhat.com> <20210906194808.GY1583@gate.crashing.org> <20210906201432.GZ920497@tucnak> Precedence: bulk X-Mailing-List: llvm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 On Mon, Sep 06, 2021 at 02:08:58PM -0700, Linus Torvalds wrote: > > the only guaranteed APIs are > > those provided by the headers (x86intrin.h/*mmintrin.h etc. on x86, > > arm_{neon,sve}.h etc. on arm*, ...) > > You guys realize we don't use those, do you? The x86intrin.h/*mmintrin.h on x86 indeed not, arm_neon.h is used in the kernel: arch/arm64/include/asm/neon-intrinsics.h:#include arch/arm64/lib/xor-neon.c:#include The arm intrinsics headers are similar to the x86 ones in that the only supported APIs are the ones provided by the headers, the underlying builtins can change. > That "immintrin.h" file, for example, is simply not usable for the > kernel. I just checked. > > Why? Because it ends up doing exactly all those things that MUST NOT > be done for the kernel. > > In file included from > /usr/lib/gcc/x86_64-redhat-linux/11/include/xmmintrin.h:34, > from > /usr/lib/gcc/x86_64-redhat-linux/11/include/immintrin.h:31, > from t.c:1: > /usr/lib/gcc/x86_64-redhat-linux/11/include/mm_malloc.h:27:10: > fatal error: stdlib.h: No such file or directory > 27 | #include > | ^~~~~~~~~~ > > Oops. 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 #include will get rid of the stdlib.h include and those 2 APIs that wouldn't be usable in the kernel anyway. There is a stddef.h include too and that's it (I must say I don't see the reason for that include though). Other compiler provided headers (not talking about C++ now) also have no or very limited includes, including stddef.h, stdarg.h, stdatomic.h, etc. The only exceptions are tgmath.h which isn't usable without libc math.h/complex.h, in some cases stdint.h and limits.h which are in some configurations provided both by the C library and the compiler and include each other in that case (but e.g. stdint.h has an alternate version that only uses compiler provided builtin macros) and openacc.h. Sure, the glibc headers are a different thing. Jakub