Compiler flags only one incorrectly declared variable

In the code shown below, there is an erroneous declaration for three variables that are already in scope through USE association. The compiler flags only one of the three variables in its error message. If that variable is removed and the compiler is run again, the next re-declared variable is flagged. When such an error occurs while refactoring a large program, it would be more convenient for the compiler to flag all the re-declared variables the first time.

      module par_C
         double precision :: alpha = 0.139d0, eta = 0.008d0, tau, rhodh, dis
      end module par_C

      program pfinag
      use par_C
      integer neqn,i,j,n
      double precision  work, y, beta, rhop, dif, hd, t, tend
      double precision rtol(1), atol(1), h
      double precision tau, rhodh, dis ! ERROR, all are declared in module par_C
      parameter (neqn=400)
      dimension y(neqn),work(7*neqn)
      integer iwork(12),idid
      external finag
      data beta /2.54d0/, rhop /0.3d0/, dif/0.010d0/
      n=neqn
      hd=200
      dis=(hd*dif)**2
      tau=-eta*beta
      rhodh=rhop/(hd*dif)
      iwork(1)=1
      iwork(2)=1
      iwork(3)=0
      iwork(4)=0
      y(1:n)=0.d0
      t=0.0d0
      tend=400.d0
      rtol(1)=1d-6
      atol(1)=rtol(1)
      h=1d-4
      write(6,*) 'Integration of the Finag problem'
      call rock4(neqn,t,tend,h,y,finag,atol,rtol,work,iwork,idid)
      write (8,'(es15.7)') (y(j), j=1,400,7)
      end

The error message:

ERROR S:\LANG\ftn95\finag.F90 10:  TAU has already been declared in MODULE PAR_C

I am requesting that similar error messages be issued for RHODH and DIS in a sigle run of the compiler. Thanks.

Hi Mecej4,

RHODH has NOT been declared twice! (EDIT: well it wasn't as originally posted, but Mecej4 has edited his original post in light of this response, which is cheating - a little).

I think that working on Christmas Day has caused you to suffer some Dannian Devilry!

While you are right to imply that it would be helpful if the double specification of all variables could be indicated, I suspect that the compiler stops looking after the first error is detected. Moreover, if I was looking at the code after an error had been indicated I do think that there's a fair chance I might see the double specification of DIS as well.

The declaration of RHODH in the DOUBLE PRECISION statement has no impact as far as I can see, as RHODN is in the code and in the MODULE while RHODH is not used in the demonstrator. (So the demonstrator has been edited).

Eddie

Thanks for spotting the slip, Eddie. I have corrected the reproducer above.

The issue still stands. In the actual code (not the small reproducer that I posted), the common block contains hundreds of variables, so the issue regarding (reporting one at a time versus reporting all) is quite real.

When one programmer error causes a clump of error messages to be given out, my habit of glancing at line numbers in the error messages is usually effective in detecting such clumps.

mecj4

Thank you for the feedback. This behaviour is by design but I have changed it to suit your preferences. The change may not be in time for the pending full release.

The FTN95 error handling has a flag (set by the FTN95 developer) that suppresses further errror reports for the current line. I have simply removed this flag.

Naturally the downside is that, if you have many such errors on one line then you will get a whole batch of error reports.

Thanks, Paul, perhaps a better solution would be to allow that hidden flag (now accessible only to the compiler developers) to be set by the user in FTN95.cfg or as a compiler command option. As Eddie states, many users may prefer the current behaviour. I can understand that users who develop using Plato or VS may prefer to keep the current behaviour.

Mecej4,

I don't think that I've ever represented 'many users' (much as I'd like to), and as you point out, just being given a tip off enables an experienced programmer to detect the other weeds in that particular clump of vegetation.

Your solution of making the behaviour configurable seems to me to be a particularly useful suggestion, and one that I commend to Paul. What about a compiler option?

Eddie

The error in question is number 655. This is one of about 200 error reports out of about 1300 that have a flag that suppresses a repeat of the given error message on the current line.

The simplest and probably best solution is that we provide a command line option that over-rides this flag for all 200 error reports of this kind. Otherwise the user will have more flexibility than is useful and also the change would become much more time consuming to implement.

The new command line option will be /ALL_ERRORS.

Brilliant solution, Paul. Simple, elegant, and meets everyone's needs.

It will have to do until you implement the psychic algorithm to detect what the programmer meant, instead of what they typed!

Eddie

I second that. I will be glad to have the /ALL_ERRORS compiler option.

This looks to be a good approach.

I also use ftn95.cfg to include: /SET_ERROR_LEVEL Warning 327 ( I assume there can be multiple of these instructions in ftn95.cfg or multiple error numbers listed; either way is ok. )

I am hoping this will not be confused with /ALL_ERRORS

The use of C:\Program Files (x86)\Silverfrost\FTN95_8.92.37b\ftn95.cfg works effectively for me.

John

Yes. /SET_ERROR_LEVEL allows you the option to change the status of particular error messages and to upgrade or downgrade their severity.

Also /CONFIG provides a dialog that allows you to configure FTN95 in order to change the severity of particular error messages.

/ALL_ERRORS will be configurable via /CONFIG. It should have no adverse effect on the existing mechanism.

Almost all of the error messages that relate to /ALL_ERRORS are in fact 'error' as opposed to 'warning', 'comment' or 'fatal'. In theory some of these may also be upgraded to 'fatal' or downgraded to 'warning'. But downgrading is often unsafe.

/ALL_ERRORS has now been added for the next release of FTN95.