This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/30447] Evaluate complex math functions at compile-time
- From: "ghazi at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 14 Oct 2009 06:15:12 -0000
- Subject: [Bug middle-end/30447] Evaluate complex math functions at compile-time
- References: <bug-30447-578@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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