[Bug other/57675] Complex division of NaN by zero not handled correctly

[Bug other/57675] Complex division of NaN by zero not handled correctly

[ian at airs dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57675

Ian Lance Taylor <ian at airs dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jsm28 at gcc dot gnu.org

--- Comment #1 from Ian Lance Taylor <ian at airs dot com> ---
Adding Joseph in case he has any comment on the standards-based argument.

[Bug other/57675] Complex division of NaN by zero not handled correctly

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57675

--- Comment #2 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
N1399 has a detailed analysis of issues with complex multiply and divide 
in C99.  There was no consensus to adopt requirements in that detail, but 
N1496 was adopted with a more minimal fix for (1.0+1.0*I)/(0.0+NAN*I).  It 
appears that the GCC implementation does not suffer the particular issue 
being addressed in N1496.

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1399.txt
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1496.htm

I believe the model in N1399 (and more generally for NaNs in C99/C11 and 
the draft TS 18661 bindings to IEEE 754-2008; see e.g. how hypot(NaN, Inf) 
works) is that NaN+1.0i is considered (for a quiet NaN) to be 
<unspecified-real>+1.0i.  Dividing by zero then gives an unspecified (or 
not fully specified) infinity, so a result with one part infinity and one 
part NaN seems appropriate.

[Bug other/57675] Complex division of NaN by zero not handled correctly

[ian at airs dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57675

Ian Lance Taylor <ian at airs dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #3 from Ian Lance Taylor <ian at airs dot com> ---
Closing as being C standard conformant.

Now I have to decide what to do with Go.