2

I am currently working to debug a subroutine of some software that my boss has written back in the 90s. There seems to be a floating-point exception that occurs in a do loop of a particular subroutine:

16  irad=1,incmax
    rr1=rr2
    rr2=rr2+rdiv
      if(rr1.gt.rlimit) goto 16
      if(pts(irad).gt.0.0) then
         discrm=(rmsden(mt,irad)/pts(irad))
     1          -((average(mt,irad)**2)/(pts(irad)**2))
      else
         discrm=0.0
      endif
      if(discrm.ge.0.0) then
         rmsden(mt,irad)=sqrt(discrm)
      else
         rmsden(mt,irad)=0.0
      endif

      average(mt,irad)=average(mt,irad)/pts(irad)
      average(mt,irad)=(average(mt,irad)*100.0)/bigmost(mt)
      rmsden(mt,irad)=(rmsden(mt,irad)*100.0)/bigmost(mt)
      denbot(mt,irad)=(denbot(mt,irad)*100.0)/bigmost(mt)
      dentop(mt,irad)=(dentop(mt,irad)*100.0)/bigmost(mt)
      iradmax(mt)=irad


 17   if(iverbose0.ge.1) then
         ipts=pts(irad)
         iptszero=ptszero(irad)
         if(ipts.eq.0) then
            average(mt,irad)=0.0
            rmsden(mt,irad)=0.0
            denbot(mt,irad)=0.0
            dentop(mt,irad)=0.0
         endif
         write(6,99) rr1,rr2,ipts,iptszero,average(mt,irad),
     1               rmsden(mt,irad),denbot(mt,irad),dentop(mt,irad)
 99      format(1x,2f9.2,2i8,2f8.1,2f8.1)
      endif
 16   continue
      stop 'PIPPA'

If I put the stop 'PIPPA' statement before "16  continue", the there are no errors. However, if the stop statement goes after the "16  continue", I get: 
Note: The following floating-point exceptions are signalling: IEEE_INVALID_FLAG
STOP PIPPA

This didn't happen before upgrading the GCC compilers/libraries. I admit that I have found a lot of resources through Googling, but I am still unable to debug this. I have also tried the --fpe-trap flags upon compilation, however they do not output anything.

Why does gfortran now complain?

francescalus
  • 30,576
  • 16
  • 61
  • 96
profilin
  • 21
  • 1
  • 4
  • 2
    See http://stackoverflow.com/questions/35992992/gfortran-ieee-exception-inexact – Vladimir F Героям слава Sep 06 '16 at 15:38
  • 1
    Are you interested why the exception is triggered by your code or just why the diagnostic is printed? – Vladimir F Героям слава Sep 06 '16 at 15:38
  • Vladimir, both... – profilin Sep 06 '16 at 19:01
  • I have noticed that if I insert a large data set ( 174457936) rather than (67109888), the smaller map does not cause the floating-point exception. Could this be do to an array declaration? – profilin Sep 06 '16 at 20:31
  • Please don't add back the chatty parts I deleted again. They don't have place here. Your user name is already below the post. You can choose a better one. There is no reason to talk about how much you are a beginner, you have a specific problem and we are trying a solution applicable to all with this problem, not just for you. – Vladimir F Героям слава Sep 06 '16 at 23:04
  • If gcc has a switch like intel's -check bounds then that would help to find bounds violations. You could also try varying the optimization level. Generally one could also move back to the older gcc compiler. – Holmz Sep 07 '16 at 10:16

1 Answers1

2

There seems to be two questions here. Lets try to answer each one.

1. Why does the new GFortran version print such a message

Since the Fortran 2008 standard requires that execution of the STOP and ERROR STOP statements outputs a list of currently signaling FP exceptions (if such a thing is supported by the system), GFortran follows this as of GFortran version 4.9. See https://gcc.gnu.org/ml/fortran/2013-06/msg00072.html .

2. Why does my code trigger this exception, and why does it only happen with the new GFortran version

Very likely, the exception was signalling before as well, but since it wasn't printed at the STOP statement you weren't aware of it. Since the example you have showed isn't self-contained (I can't compile and test it), I can only recommend you try the usual debugging command line options such as "-fcheck=all, -ffpe-trap=invalid,zero,overflow -g -Wall -Wextra -Werror -pedantic", check running your program under valgrind etc.

janneb
  • 36,249
  • 2
  • 81
  • 97