This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: ARM/AAarch64: NEON intrinsics in the kernel
- From: Ard Biesheuvel <ard dot biesheuvel at linaro dot org>
- To: Richard Earnshaw <rearnsha at arm dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, Christophe Lyon <christophe dot lyon at linaro dot org>, Matthew Gretton-Dann <matthew dot gretton-dann at linaro dot org>, Ramana Radhakrishnan <Ramana dot Radhakrishnan at arm dot com>, Marcus Shawcroft <Marcus dot Shawcroft at arm dot com>
- Date: Tue, 21 May 2013 12:06:55 +0200
- Subject: Re: ARM/AAarch64: NEON intrinsics in the kernel
- References: <CAKv+Gu-FaFnODdcVtdtrVsoJmE95vgdvcicRQ7N9_MvKuFXd8w at mail dot gmail dot com> <519B41B5 dot 8040904 at arm dot com>
On 21 May 2013 11:43, Richard Earnshaw <rearnsha@arm.com> wrote:
> Why don't you add a (maybe cut-down) stdint.h to the kernel. It seems
> bizarre to me that the kernel is trying to provide standard types through a
> non-standard interface.
>
There have been heated debates going on for years about these things.
Quote from Linus Torvalds: (http://yarchive.net/comp/linux/kernel_headers.html)
"
The user is supposed to see "int32_t" and friends _only_ if the user
himself includes <stdint.h> or one of the very specific headers that is
documented by the standard to include it.
Trust me. We are NOT going to use <stdint.h> in the kernel.
"
This is fairly old, and some of the types have in fact been added to
<linux/types.h>, even if stdint.h is still absent.
The bottom line is that including arm_neon.h pulls in a host of stuff
into the namespace, even with -ffreestanding. (And in that case, the
fact that GCC built for bare metal and GCC built for GLIBC disagree on
the definition of __UINTPTR_TYPE__ is not helping a lot either)
I understand that the uintXX_t types have already been made part of
the public NEON instrinsics interface, so I am not proposing changing
that. I am just looking for a way to enable the use of NEON intrinsics
in the kernel.
Are there any other solution possible in your opinion? Do you agree
that POSIX states that stdint.h may only be included in specific well
defined cases? Could we perhaps make the #inclusion conditional? An
alternate header perhaps to accomodate non-C99 environments?
Regards,
Ard.