{"push_id":1348403516,"size":1,"distinct_size":1,"ref":"refs/heads/master","head":"e886c36771c1a941cdfc5c4df4dc85b3f8f6d4ef","before":"07c18a008c2ed8f5660adba2b778671db159a141","commits":[{"sha":"e886c36771c1a941cdfc5c4df4dc85b3f8f6d4ef","author":{"name":"Joseph Myers","email":"9b6e24a661c030e39d84e80f958c2d82d5dc3d65@codesourcery.com"},"message":"Clean up some complex functions raising FE_INVALID.\n\nSome of the complex arithmetic functions have the following pattern:\nin some piece of code, one part of the input (real or imaginary,\ndepending on the function) is either infinite or NaN.  Part of the\nresult is to be set to NaN in either case, and FE_INVALID raised only\nif the relevant part of the input was infinite.\n\nIn such a case, there is no actual need for the conditional on the\ntype of the input, since subtracting the relevant part of the input\nfrom itself will produce a NaN, with FE_INVALID only if the relevant\npart of the input was infinite.  This simplifies the code, and as a\nquality-of-implementation matter also improves things by propagating\nNaN payloads.  (Right now these functions always raise FE_INVALID for\nsignaling NaN arguments because of the call to fpclassify - at least\nunless glibc is built with -Os - but if fpclassify moves to using\ninteger arithmetic in future, doing arithmetic on the NaN argument\nalso ensures an exception for sNaNs.)\n\nTested for x86_64 and x86.\n\n\t* math/s_ccosh_template.c (M_DECL_FUNC (__ccosh)): Instead of\n\traising FE_INVALID with feraisexcept in case where part of\n\targument is infinite, subtract that part of argument from itself.\n\t* math/s_cexp_template.c (M_DECL_FUNC (__cexp)): Likewise.\n\t* math/s_csin_template.c (M_DECL_FUNC (__csin)): Likewise.\n\t* math/s_csinh_template.c (M_DECL_FUNC (__csinh)): Likewise.","distinct":true,"url":"https://api.github.com/repos/francois-wellenreiter/glibc/commits/e886c36771c1a941cdfc5c4df4dc85b3f8f6d4ef"}]}
{"actor":{"display_login":"francois-wellenreiter"}}