https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84891
--- Comment #6 from Steve Kargl <sgk at troutmask dot apl.washington.edu> --- On Mon, Mar 19, 2018 at 11:46:11AM +0000, rguenth at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84891 > > Richard Biener <rguenth at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |kargl at gcc dot gnu.org, > | |pault at gcc dot gnu.org > > --- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> --- > (In reply to jos...@codesourcery.com from comment #2) > > I'm not sure what the C++ complex multiplication / division requirements > > are here (for that matter, C doesn't seem to precisely define which NaN - > > which value with at least one NaN part and the other part not infinite - > > is produced from complex multiplication / division in this case, though > > NaN + iNaN probably makes more sense). > > I don't see anything in the C++ standard going into detail here either. > It simply says (from C++14 26.4/3): > > "If the result of a function is not mathematically defined or not in the > range of representable vaslues for its type, the behavior is undefined." > > which to my reading makes any operation with NaN/Inf undefined given > "mathematically" a NaN or Inf does not exist. > > I can't find anything in the Fortran2008 standard specifying how > arithmetic on intrinsic complex types work. CCing two Fortran maintainers > to see whether Fortran requires us to do any changes here. > It's a little complicated. If the Fortran program isn't using a module from the Fortran 2008, Sec. 14, "Exceptions and IEEE arithmetic", then the following applies F20008 7.1.5.2.4 Evaluation of numeric intrinsic operations The execution of any numeric operation whose result is not defined by the arithmetic used by the processor is prohibited. Raising a negative-valued primary of type real to a real power is prohibited. Note "the processor" here is "the compiler". What complicates the matter is that Fortran makes a distinct between a model number and a representable number. For gfortran with a binary radix, the model numbers are essentially the normalized finite IEEE 754 binary floating pointing numbers. The representable numbers, which are a property of the compiler, can be considered to include Inf/NaN and subnormal. So, in this Fortran program program foo x = 1 y = 0 call sub(x,y) end program foo subroutine sub(x,y) print *, x/y end subroutine sub gfortran gives an Infinity on output with no error or warning. gfortran does have the -ffpe-trap=zero option, which with enables trapping of division-by-zero errors. With all that said, gfortran uses the GCC backend, and follows whatever is enforced by the backend.