[Bug other/42333] complex division failure on darwin10 with -lm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333 --- Comment #54 from Kaveh Ghazi 2011-02-06 16:43:38 UTC --- (In reply to comment #53) > I think we should fix this by patching in a new linkage name for the routine > in > question with darwin_patch_builtins and creating a forwarding stub from the > old > name to the new name that we link against. We could mix in _ieee into the new > name. If we compile with -fast-math we can call the old routine, no patch, > and > if one wants accuracy, the we call the new name. I believe GCC already does the "fast" method in some situations. See tree-complex.c:expand_complex_division(). It switches on flag_complex_method, the difference is that the operation is done inline rather than a libcall. I'm foget under what circumstances flag_complex_method triggers, but GCC may already do what you propose in some fashion. --Kaveh
[Bug c++/49813] [C++0x] sinh vs asinh vs constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #48 from Kaveh Ghazi 2011-07-27 22:32:57
UTC ---
(In reply to comment #41)
> The testcase in Comment #30 has the types wrong, the below is a corrected
> version (the substance of the issue doesn't change at all). I'm also thinking
> of checking in the library bits with a temporary workaround of the form:
> inline constexpr bool
> isinf(long double __x)
> { return fpclassify(__x) == FP_INFINITE; }
> which works.
> /
> inline constexpr bool
> isinf(long double __x)
> { return __builtin_isinf(__x); }
> inline constexpr bool
> isinf(double __x)
> { return __builtin_isinf(__x); }
> inline constexpr bool
> isnan(long double __x)
> { return __builtin_isnan(__x); }
> int main()
> {
> constexpr int i1 = __builtin_isinf(1.l); // Ok.
> constexpr bool b2 = isinf(1.l);// Error.
> constexpr bool b3 = isinf(1.); // Ok.
> constexpr bool b4 = isnan(1.l);// Ok.
> }
The isinf (and isinf_sign) functions use the (...) signature, but isinff and
isinfl do not. So if as noted in comment#42 the problem is with the long
double variant using ellipses by calling isinf(...), perhaps you can fix it by
using __builtin_isinfl (with the trailng "L") in the inline definition. I'm
not sure why isnan passes, cause that one uses ellipses for the double variant
also. Probably best to fix all the inlines to use the specific "L" or "F"
function.
[Bug c++/49813] [C++0x] sinh vs asinh vs constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813 --- Comment #50 from Kaveh Ghazi 2011-07-27 23:13:18 UTC --- (In reply to comment #46) > Another note, about std::nextafter, std::nexttoward, & co: I see mpfr provides > an mpfr_nexttoward, which likely could be exploited in builtins.c pretty > easily. > Kaveh, do you have any plan about those? It's been several years since I did the mpfr work so my memory is a little foggy, but I think I intentionally skipped the next* functions. IIRC, these functions are very sensitive to the target floating point format. It wasn't clear to me that the "next" FP value in mpfr actually corresponded to the "next" value in the target FP format or how to verify if it was so. (I'm thinking mainly of the non-ieee formats here.) If these odd formats aren't used in GCC anymore then it might be okay to implement the builtins using mpfr. Alternatively, you can implement the builtins only for the formats where mpfr's format is identical to the target fp format. But then the optimization won't work everywhere so your library testcase will fail on some cpus. I'm not sure it's worth the trouble (and to answer your question I don't have any plans to work on it.)
