1*412f47f9SXin LiCode in this sub-directory should follow the GNU Coding Standard, but it is 2*412f47f9SXin Linot expected to be upstreamed into glibc without modification, so 3*412f47f9SXin Liglibc-specific conventions need not be followed. 4*412f47f9SXin Li 5*412f47f9SXin LiThe requirements for portable code apply to non-portable code with the 6*412f47f9SXin Lifollowing differences: 7*412f47f9SXin Li 8*412f47f9SXin Li 9*412f47f9SXin Li1. Worst-case ULP error should be encoded in filenames (e.g. sin_u35.c). There 10*412f47f9SXin Li are no specific restrictions on acceptable ULP error, but if functions 11*412f47f9SXin Li provide significantly less accuracy than portable equivalents then a clear 12*412f47f9SXin Li justification for inclusion should be stated in comments at the top of the 13*412f47f9SXin Li source file. Error bounds of the approximation should be clearly documented 14*412f47f9SXin Li in comments. 15*412f47f9SXin Li 16*412f47f9SXin Li2. Functions are assumed to support round-to-nearest mode by default, unless 17*412f47f9SXin Li stated; other rounding modes are not required to be provided. 18*412f47f9SXin Li 19*412f47f9SXin Li3. Handling of special cases may be relaxed for vector functions. Checking 20*412f47f9SXin Li whether each vector lane contains special values such as NaN, Inf or 21*412f47f9SXin Li denormal numbers can prove too costly for vector functions. This is often 22*412f47f9SXin Li not required since vector functions are typically used along with aggressive 23*412f47f9SXin Li compiler optimization flags. 24