[PATCH][AArch64] update libm-test-ulps

[Joseph Myers]

On Fri, 10 Apr 2015, Szabolcs Nagy wrote:

> i don't see the bessel function bug report on bugzilla (but y0 is hard
> to search for) i assume the large ulp errors near zeros are known then.

See bugs 2555, 2567, 2577, 14469, 14470, 14471, 14472, 16492, 16507, 
16559, at least.  The basic issue is much the same everywhere (at least 
where inaccuracy near zeros is concerned).

> i don't see lgammal bug report either, my test case is lgammal(-2.5)
> which gives -10.465 ulp error on x86_64.

See bugs 2542, 2543, 2558 (gamma = lgamma - and since the underlying issue 
is the same in all implementations, extra bugs for long double versions 
aren't really that useful; I think only the completely separate ia64 
implementation might be accurate near zeros).

> api:
> BZ #16747 aio.h missing required restrict in lio_listio
> BZ #18228 fcntl.h missing O_ constants
> BZ #18229 limits.h missing _XOPEN constants
> BZ #18230 netinet/in.h IN6_IS_ADDR_* macros are broken
> BZ #18231 sys/ipc.h wrong ipc_perm mode member type
> BZ #18232 sys/sem.h wrong semid_ds sem_nsems member type
> BZ #18233 sys/socket.h wrong msghdr and cmsghdr types
> BZ #18234 sys/stat.h missing st_atim, etc in linux generic stat
> BZ #18235 utmpx.h utmpx struct ut_tv member type
> BZ #18236 wchar.h missing va_list type

I presume many of these correspond to (XFAILed) failures of conform/ tests 
(some such failures indicate actual API bugs, some indicate bugs in the 
tests - anyway, where there are actual API bugs, having them in Bugzilla 
is useful, since they'd need to be filed there as part of a fix if not 
filed before).

> shm_open does not work with static linking because __shm_directory
> depends on dynamic linking (fails at link time), sem_open likewise
> (except it segfaults at runtime)

Why does it depend on dynamic linking?  That looks rather like a bug to 
me.  Functions should work for static linking unless there are strong 
reasons it can't be supported.

> rounding functions (ceil,trunc,floor,round) don't have specified
> inexact behaviour, but i think the next C floating-point standard
> will be more strict, on x86_64 i see inconsistent raise of inexact.

See bug 15479.

I hope other people will help review / fix more of these bugs (we still 
need more people adopting the role of experts in particular glibc areas 
and systematically reviewing and fixing open bugs and looking for related 
issues in the code as they do so ...).

-- 
Joseph S. Myers
joseph@codesourcery.com