fix handling of odd lengths in swab function

this function is specified to leave the last byte with "unspecified
disposition" when the length is odd, so for the most part correct
programs should not be calling swab with odd lengths. however, doing
so is permitted, and should not write past the end of the destination
buffer.
ignore access mode bits of flags in mkostemps and functions that use it

per the text accepted for inclusion in POSIX, behavior is unspecified
when any of the access mode bits are set. since it's impossible to
consistently report this usage error (O_RDONLY could not be detected
since its value happens to be zero), the most consistent way to handle
them is just to ignore them.

previously, if a caller erroneously passed O_WRONLY, the resulting
access mode would be O_WRONLY|O_RDWR, which has the value 3, and this
resulted in a file descriptor which rejects both read and write
attempts when it is subsequently used.
always provide __fpclassifyl and __signbitl definitions

previously the external definitions of these functions were omitted on
archs where long double is the same as double, since the code paths in
the math.h macros which would call them are unreachable. however, even
if they are unreachable, the definitions are still mandatory. omitting
them is invalid C, and in the case of a non-optimizing compiler, will
result in a link error.
add new syscall numbers for seccomp, getrandom, memfd_create

these syscalls are new in linux v3.17 and present on all supported
archs except sh.

seccomp was added in commit 48dc92b9fc3926844257316e75ba11eb5c742b2c
it has operation, flags and pointer arguments (if flags==0 then it is
the same as prctl(PR_SET_SECCOMP,...)), the uapi header for flag
definitions is linux/seccomp.h

getrandom was added in commit c6e9d6f38894798696f23c8084ca7edbf16ee895
it provides an entropy source when open("/dev/urandom",..) would fail,
the uapi header for flags is linux/random.h

memfd_create was added in commit 9183df25fe7b194563db3fec6dc3202a5855839c
it allows anon mmap to have an fd, that can be shared, sealed and needs no
mount point, the uapi header for flags is linux/memfd.h
add new IPV6_AUTOFLOWLABEL socket option in netinet/in.h

added in linux v3.17 commit 753a2ad54ef45e3417a9d49537c2b42b04a2e1be
enables automatic flow label generation on transmit
add new linux file sealing api to fcntl.h

new in linux v3.17 commit 40e041a2c858b3caefc757e26cb85bfceae5062b
sealing allows some operations to be blocked on a file which makes
file access safer when fds are shared between processes (only
supported for shared mem fds currently)

flags:
F_SEAL_SEAL prevents further sealing
F_SEAL_SHRINK prevents file from shrinking
F_SEAL_GROW prevents file from growing
F_SEAL_WRITE prevents writes

fcntl commands:
F_GET_SEALS get the current seal flags
F_ADD_SEALS add new seal flags
fix handling of negative offsets in timezone spec strings

previously, the hours were considered as a signed quantity while
minutes and seconds were always treated as positive offsets. however,
semantically the '-' sign should negate the whole hh:mm:ss offset.
this bug only affected timezones east of GMT with non-whole-hours
offsets, such as those used in India and Nepal.
add explicit barrier operation to internal atomic.h API
fix missing barrier in pthread_once/call_once shortcut path

these functions need to be fast when the init routine has already run,
since they may be called very often from code which depends on global
initialization having taken place. as such, a fast path bypassing
atomic cas on the once control object was used to avoid heavy memory
contention. however, on archs with weakly ordered memory, the fast
path failed to ensure that the caller actually observes the side
effects of the init routine.

preliminary performance testing showed that simply removing the fast
path was not practical; a performance drop of roughly 85x was observed
with 20 threads hammering the same once control on a 24-core machine.
so the new explicit barrier operation from atomic.h is used to retain
the fast path while ensuring memory visibility.

performance may be reduced on some archs where the barrier actually
makes a difference, but the previous behavior was unsafe and incorrect
on these archs. future improvements to the implementation of a_barrier
should reduce the impact.
eliminate global waiters count in pthread_once
implement uchar.h (C11 UTF-16/32 conversion) interfaces
suppress macro definitions of ctype functions under C++

based on patch by Sergey Dmitrouk.
release 1.1.5
manually "shrink wrap" fast path in pthread_once

this change is a workaround for the inability of current compilers to
perform "shrink wrapping" optimizations. in casual testing, it roughly
doubled the performance of pthread_once when called on an
already-finished once control object.
fix failure of open to read variadic mode argument for O_TMPFILE
fix invalid access by openat to possibly-missing variadic mode argument

the mode argument is only required to be present when the O_CREAT or
O_TMPFILE flag is used.
fix rint.c and rintf.c when FLT_EVAL_METHOD!=0

The old code used the rounding idiom incorrectly:

  y = (double)(x + 0x1p52) - 0x1p52;

the cast is useless if FLT_EVAL_METHOD==0 and causes a second rounding
if FLT_EVAL_METHOD==2 which can give incorrect result in nearest rounding
mode, so the correct idiom is to add/sub a power-of-2 according to the
characteristics of double_t.

This did not cause actual bug because only i386 is affected where rint
is implemented in asm.

Other rounding functions use a similar idiom, but they give correct
results because they only rely on getting a neighboring integer result
and the rounding direction is fixed up separately independently of the
current rounding mode. However they should be fixed to use the idiom
correctly too.
math: use the rounding idiom consistently

the idiomatic rounding of x is

  n = x + toint - toint;

where toint is either 1/EPSILON (x is non-negative) or 1.5/EPSILON
(x may be negative and nearest rounding mode is assumed) and EPSILON is
according to the evaluation precision (the type of toint is not very
important, because single precision float can represent the 1/EPSILON of
ieee binary128).

in case of FLT_EVAL_METHOD!=0 this avoids a useless store to double or
float precision, and the long double code became cleaner with
1/LDBL_EPSILON instead of ifdefs for toint.

__rem_pio2f and __rem_pio2 functions slightly changed semantics:
on i386 a double-rounding is avoided so close to half-way cases may
get evaluated differently eg. as sin(pi/4-eps) instead of cos(pi/4+eps)
fix uninitialized mode variable in openat function

this was introduced in commit 2da3ab1382ca8e39eb1e4428103764a81fba73d3
as an oversight while making the variadic argument access conditional.
fix 64-bit syscall argument passing on or1k

the kernel syscall interface for or1k does not expect 64-bit arguments
to be aligned to "even" register boundaries. this incorrect alignment
broke truncate/ftruncate and as well as a few less-common syscalls.