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;
From:   Florian Weimer <fweimer@redhat.com>
To:     Segher Boessenkool <segher@kernel.crashing.org>
Cc:     Nathan Chancellor <nathan@kernel.org>,
        Linus Torvalds <torvalds@linuxfoundation.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
References: <CAK7LNAQ0Q6CdXaD-dVGj_e3O3JYs_crpejWKpXHYQJYxyk-1VQ@mail.gmail.com>
        <CAHk-=wgoX0pVqNMMOcrhq=nuOfoZB_3qihyHB3y1S8qo=MDs6w@mail.gmail.com>
        <3b461878-a4a0-2f84-e177-9daf8fe285e7@kernel.org>
        <878s0c4vng.fsf@oldenburg.str.redhat.com>
        <20210904131911.GP1583@gate.crashing.org>
Date:   Sat, 04 Sep 2021 17:19:21 +0200
In-Reply-To: <20210904131911.GP1583@gate.crashing.org> (Segher Boessenkool's
        message of "Sat, 4 Sep 2021 08:19:11 -0500")
Message-ID: <871r644bd2.fsf@oldenburg.str.redhat.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

* Segher Boessenkool:

> Let me quote the original mail (I had to dig it out of the archives as
> well, no nice threading, too lazy, sorry):

It still doesn't say why.  I did see a reference to fleeting reference
to <stdatomic.h> and <float.h>.

My conjecture is that the real reason is avoid atomic emulation
(softatomic?)  and softfloat code.  It's not related to <stdarg.h> at
all: this header is replaced so that GCC's include subdirectory can be
dropped from the include search path.  What I don't know if this is to
avoid obscure linker failures related to libatomic/softfloat (obviously
not great) or run-time failures (worse).

In any case, it would be nice to know what the real motivation is.

After all, <stdatomic.h> is exactly like <stdarg.h> in that it's
possible to use its functionality even without the header file.  The
__atomic builtins are even documented in the GCC manual (unlike
<stdatomic.h>), which is why some programmers prefer them over the
standard interface.  And then there's the _Atomic keyword itself, whose
use can easily result in calls to libatomic functions, too.  So blocking
<stdatomic.h> makes little sense to me.

I don't know enough about softfloat if blocking the inclusion of
<float.h> is worth it.

Thanks,
Florian