[Bug middle-end/84891] -fno-signed-zeros leads to optimization which should be possible only if also -ffinite-math-only is on

["sgk at troutmask dot apl.washington.edu" <gcc-bugzilla at gcc dot gnu dot org>]

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 joseph@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.