This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
| Other format: | [Raw text] | |
On 23 Apr 2015 23:03, Szabolcs Nagy wrote: > * 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 i don't mean exactly "uint128_t", i mean wrt double -- you don't want that -mike
Attachment:
signature.asc
Description: Digital signature
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |