------- Comment #2 from nmm1 at cam dot ac dot uk 2007-11-12 14:25 ------- Well, yes and no. I am sorry, but that reply has raised several separate points, so there is a threat of a thread split.
1) It is vaguely related to PR323, yes, but not simply. What I was saying could be considered is special-casing complex division and not putting it through all of the code generation stages. I.e. forcibly using native Intel arithmetic, irrespective of the fpmath setting. The instruction scheduling etc. can still be performed. That technique was common on mainframes for conversion to and from integers. 2) Yes, there are QoI issues with __divdc3 - several. The basic code is more robust than the crude code, but still gets some non-overflowing boundary cases wrong. The only system I have used that got those right was AIX on POWER4, and it used a heavyweight function (of course). If anyone has the urge to pursue this, I can help, but I am not sure if it is worth the effort. Personally, I think that the basic _divdc3 code is by-and-large good enough. 3) __divdc3 makes a complete mess of NaN and infinity handling, I am afraid, but it isn't clear how soluble that is. The root cause is that C99 has done precisely the same, so there isn't even a mathematically sensible target to aim at. It can't be got properly 'right' until there is a reasonable NaN/infinity model for complex numbers, and you don't want to start with a Cartesian floating-point representation if you are going there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34071
