http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=221319 raises a question whether: std::complex<double> (1.0, 1.0) / 0.0 and std::complex<double> (1.0, 1.0) / std::complex<double> (0.0, 0.0) can or can't be NaN. In C say: #define I (__extension__ 1.0iF) _Complex double d = 1.0 + 0.0 * I, e, f, z = 0.0 + 0.0 * I; int main (void) { e = d / 0.0; f = d / z; __builtin_printf ("%g %g %g %g\n", __real__ e, __imag__ e, __real__ f, __imag__ f); return 0; } in -std=c99 always prints inf (where complex inf is even when just one of the parts is inf), no matter what optimization options, in C89 the first division when optimizing is usually optimized into the simpler __real__ d / 0.0, __imag__ d / 0.0 division and thus gives inf too, but the latter and when not optimizing even the first one gives NaN. What do we want in C++? C++ doesn't use flag_complex_method = 2, so unless that changes, only the division by double (rather than std::complex <double>) could generally (when not optimizing) return inf - with a help in the specialization, see the above URL.
Jakub, a few observations: the first one, we have got other PRs about complex math (e.g., 24581, 28408), I don't know if you are aware of that, it would be great if you could have a unified look. Also, I don't think we want to change the library here (like in you link), I think we discussed this kind of solution for such troubles other times and we came to the conclusion that really these are compiler issues, because we are relying in a very straightforward way on the complex extension (maybe Gaby has something to add). Also, as you may also find in some of the existing audit trails and past discussions on gcc@, people is particularly troubled by the large differences in behavior when optimizing and not, I think we should tackle that issue. Ah, maybe the most important point for this specific PR: I think we *do* want a behavior of the complex division in C++ consistent with C99 (and LIA-2, which, AFAIK, is consistent with C99), for many different reasons, among other things, the new standard will be "based" on C99, not C89, probably Gaby has something to add. Unfortunately, I'm afraid the way we are implementing C99 vs complex in the middle-end is buggy, see 24581, Joseph' comments in particular, but consistency between the C99 and the C++ math seems to me an improvement anyway.
Subject: Bug 30482 Author: paolo Date: Wed Jul 11 10:23:56 2007 New Revision: 126546 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126546 Log: 2007-07-11 Paolo Carlini <pcarlini@suse.de> PR middle-end/30482 * c-opts.c (c_common_post_options): Do not change flag_complex_method conditional to flag_isoc99. (c_common_init_options): Do it here, unconditionally. Modified: trunk/gcc/ChangeLog trunk/gcc/c-opts.c
Fixed.