------- Comment #11 from ghazi at gcc dot gnu dot org 2009-10-14 06:15 ------- (In reply to comment #10) > > except for cproj because that has a wierd non-c99 implementation in glibc. > > I don't see why one particular library having a bug in its implementation > of cproj should prevent GCC from optimizing that function correctly for > constant arguments.
Had it been any other system, I would agree. But that "one particular library" is the C lib for the GNU system and I was reluctant to make the GNU compiler incompatible with the GNU C library. There is a bug report filed for cproj from July, but nothing appears to have been done about it. http://sourceware.org/bugzilla/show_bug.cgi?id=10401 If there is consensus that we don't care what glibc does, I can implement the cproj opt. However you may recall I have most of these MPFR/MPC transformations back out if Inf is passed in. The main rationale for cproj is to handle Inf specially. So it would require hacking the infrastructure to allow Inf to pass through. I did this for two-argument calls like mpc_div, but not one-argument calls like mpc_proj. Since it's stage3 I'd defer that till later. Another (perhaps interim) option would be to do the opt only for finite numbers. That would be a one-liner and perhaps suitable for stage3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30447
