it was already defined for mips, but was missing from other archs

based on linux headers add the missing MCAST_* options
under _GNU_SOURCE as they are not in the reserved namespace
(this api was originally specified by RFC 3678)

missing protocol families based on current linux headers:
PF_RDS, PF_LLC, PF_CAN, PF_TIPC, PF_NFC

this is wasteful and useless from a standpoint of sane programs, but
it is required by the standard, and the current requirements were
upheld with the closure of Austin Group issue #639:
http://austingroupbugs.net/view.php?id=639

the anonymous struct typedef with array notation breaks with
GCC in C++ mode:

error: non-local function 'static<anonymous struct>
(& boost::signal_handler::jump_buffer())[1]' uses anonymous type

this is a known GCC issue, as search results for that error msg
suggest.

since this is hard to work around in the calling C++ code, a
fix in musl is preferable.

some programs (procps, babl) expect it, and it doesn't seem to
cause any harm to just add it.
it's small and straightforward.

since math.h also defines MAXFLOAT, we undef it in both places,
before defining it.

these flags are needed in order to be able to handle lwp id's
which the kernel returns after clone() calls for new threads
via ptrace(PTRACE_GETEVENTMSG).

fortunately, they're the same for all archs and in the reserved
namespace.

for _Noreturn functions, gcc generates code that trashes the
stack frame, and so it makes it impossible to inspect the causes
of an assert error in gdb.

abort() is not affected (i have not yet investigated why).

both jn and yn functions had integer overflow issues for large
and small n

to handle these issues nm1 (== |n|-1) is used instead of n and -n
in the code and some loops are changed to make sure the iteration
counter does not overflow

(another solution could be to use larger integer type or even double
but that has more size and runtime cost, on x87 loading int64_t or
even uint32_t into an fpu register is more than two times slower than
loading int32_t, and using double for n slows down iteration logic)

yn(-1,0) now returns inf

posix2008 specifies that on overflow and at +-0 all y0,y1,yn functions
return -inf, this is not consistent with math when n<0 odd integer in yn
(eg. when x->0, yn(-1,x)->inf, but historically yn(-1,0) seems to be
special cased and returned -inf)

some threshold values in jnf and ynf were fixed that seems to be
incorrectly copy-pasted from the double version

a common code path in j1 and y1 was factored out so the resulting
object code is a bit smaller

unsigned int arithmetics is used for bit manipulation

j1(-inf) now returns 0 instead of -0

an incorrect threshold in the common code of j1f and y1f got fixed
(this caused spurious overflow and underflow exceptions)

the else branch in pone and pzero functions are fixed
(so code analyzers dont warn about uninitialized values)

a common code path in j0 and y0 was factored out so the resulting
object code is smaller

unsigned int arithmetics is used for bit manipulation

the logic of j0 got a bit simplified (x < 1 case was handled
separately with a bit higher precision than now, but there are large
errors in other domains anyway so that branch has been removed)

some threshold values were adjusted in j0f and y0f

reported/requested by Strake; simplified from the provided patch

the old definitions were wrong on some archs. actually, EPOLL_NONBLOCK
probably should not even be defined; it is not accepted by the kernel
and it's not clear to me whether it has any use at all, even if it did
work. this issue should be revisited at some point, but I'm leaving it
in place for now in case some applications reference it.

the POLL prefix is in the reserved namespace for poll.h, so no feature
test macro checks are needed.

libc is the macro, __libc is the internal symbol, but under some
configurations on old/broken compilers, the symbol might not actually
exist and the libc macro might instead use __libc_loc() to obtain
access to the object.

the previous logic was assuming the kernel would give EINVAL when
passed an invalid address, but instead with MAP_FIXED it was giving
EPERM, as it considered this an attempt to map over kernel memory.
instead of trying to get the kernel to do the rigth thing, the new
code just handles the error in userspace.

I have also cleaned up the code to use a single mask to check for
invalid low bits and unsupported high bits, so it's simpler and more
clearly correct. the old code was actually wrong for sizeof(long)
smaller than sizeof(off_t) but not equal to 4; now it should be
correct for all possibilities.

for 64-bit systems, the low-bits test is new and extraneous (the
kernel should catch the error anyway when the mmap2 syscall is not
used), but it's cheap anyway. if this is an issue, the OFF_MASK
definition could be tweaked to omit the low bits when SYS_mmap2 is not
defined.

__IS_FP is a portable integer constant expression now
(uses that unsigned long long is larger than float)
the result casting logic should work now on all compilers
supporting typeof

this is already implemented in the dynliker (see struct debug),
but was not exposed.
we need it to do so to make wine happy...

* return type logic is simplified a bit and fixed (see below)
* return type of conj and cproj were wrong on int arguments
* added comments about the pending issues
(usually we don't have comments in public headers but this is
not the biggest issue with tgmath.h)

casting the result to the right type cannot be done in c99
(c11 _Generic can solve this but that is not widely supported),
so the typeof extension of gcc is used and that the ?: operator
has special semantics when one of the operands is a null
pointer constant

the standard is very strict about the definition of null
pointer constants so typeof with ?: is still not enough so
compiler specific workaround is used for now

on gcc '!1.0' is a null pointer constant so we can use the old
__IS_FP logic (eventhough it's non-standard)

on clang (and on gcc as well) 'sizeof(void)-1' is a null
pointer constant so we can use
 !(sizeof(*(0?(int*)0:(void*)__IS_FP(x)))-1)
(this is non-standard as well), the old logic is used by
default and this new one on clang

previously 0x1p-1000 and 0x1p1000 was used for raising inexact
exception like x+tiny (when x is big) or x+huge (when x is small)

the rational is that these float consts are large enough
(0x1p-120 + 1 raises inexact even on ld128 which has 113 mant bits)
and float consts maybe smaller or easier to load on some platforms
(on i386 this reduced the object file size by 4bytes in some cases)

this is not a full rewrite just fixes to the special case logic:
+-0 and non-integer x<INT_MIN inputs incorrectly raised invalid
exception and for +-0 the return value was wrong

so integer test and odd/even test for negative inputs are changed
and a useless overflow test was removed

comments are kept in the double version of the function

compared to fdlibm/freebsd we partition the domain into one
more part and select different threshold points:
now the [log(5/3)/2,log(3)/2] and [log(3)/2,inf] domains
should have <1.5ulp error
(so only the last bit may be wrong, assuming good exp, expm1)

(note that log(3)/2 and log(5/3)/2 are the points where tanh
changes resolution: tanh(log(3)/2)=0.5, tanh(log(5/3)/2)=0.25)

for some x < log(5/3)/2 (~=0.2554) the error can be >1.5ulp
but it should be <2ulp
(the freebsd code had some >2ulp errors in [0.255,1])

even with the extra logic the new code produces smaller
object files

comments are kept in the double version of the function

changed the algorithm: large input is not special cased
(when exp(-x) is small compared to exp(x))
and the threshold values are reevaluated
(fdlibm code had a log(2)/2 cutoff for which i could not find
justification, log(2) seems to be a better threshold and this
was verified empirically)

the new code is simpler, makes smaller binaries and should be
faster for common cases

the old comments were removed as they are no longer true for the
new algorithm and the fdlibm copyright was dropped as well
because there is no common code or idea with the original anymore
except for trivial ones.

these are not specified in the standard, but in the reserved
namespace, so there is no problem with defining them unconditionally.

with naive exp2l(x*log2e) the last 12bits of the result was incorrect
for x with large absolute value

with hi + lo = x*log2e is caluclated to 128 bits precision and then
  expl(x) = exp2l(hi) + exp2l(hi) * f2xm1(lo)
this gives <1.5ulp measured error everywhere in nearest rounding mode

in tgmath.h the return values are casted to the appropriate
floating-point type (if the compiler supports gcc __typeof__),
this is wrong in case of ilogb, lrint, llrint, lround, llround
which do not need such cast