This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [aarch64] question about user.h, ucontext.h, procfs.h
- From: Szabolcs Nagy <nsz at port70 dot net>
- To: Szabolcs Nagy <szabolcs dot nagy at arm dot com>, GNU C Library <libc-alpha at sourceware dot org>, Marcus Shawcroft <Marcus dot Shawcroft at arm dot com>, Ramana Radhakrishnan <Ramana dot Radhakrishnan at arm dot com>
- Date: Thu, 23 Apr 2015 23:03:40 +0200
- Subject: Re: [aarch64] question about user.h, ucontext.h, procfs.h
- Authentication-results: sourceware.org; auth=none
- References: <54FDBC60 dot 6020902 at arm dot com> <5538F7B9 dot 3060206 at arm dot com> <20150423201310 dot GR12496 at vapier>
* Mike Frysinger <vapier@gentoo.org> [2015-04-23 16:13:10 -0400]:
> On 23 Apr 2015 14:46, Szabolcs Nagy wrote:
> > >
> > > aarch64 user_fpsimd_struct has
> > >
> > > __uint128_t vregs[32];
> > >
> > > member to represent the 128bit floating point registers
> > >
> > > is it ok to expose __uint128_t in public headers?
> >
> > (i'd prefer 'long double' so compilers without __uint128
> > can use signal.h)
>
> vregs is supposed to hold the content of the registers. it doesn't need to be
> able to represent the data directly (i.e. use doubles). using uint128_t is the
> right thing to do here.
>
uint128_t is not in the reserved namespace of signal.h
if _POSIX_C_SOURCE is defined before its inclusion
__uint128_t is namespace clean, just non-standard compiler
extension, but probably i shouldn't worry about compiler
support on a new arch