forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Compiler flags only one incorrectly declared variable

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
mecej4



Joined: 31 Oct 2006
Posts: 1762

PostPosted: Sun Dec 25, 2022 6:17 pm    Post subject: Compiler flags only one incorrectly declared variable Reply with quote

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.

Code:
      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:
Code:
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.


Last edited by mecej4 on Tue Dec 27, 2022 1:47 am; edited 1 time in total
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2360
Location: Yateley, Hants, UK

PostPosted: Tue Dec 27, 2022 1:36 am    Post subject: Reply with quote

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


Last edited by LitusSaxonicum on Tue Dec 27, 2022 12:46 pm; edited 1 time in total
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1762

PostPosted: Tue Dec 27, 2022 1:51 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7550
Location: Salford, UK

PostPosted: Tue Dec 27, 2022 8:25 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
mecej4



Joined: 31 Oct 2006
Posts: 1762

PostPosted: Tue Dec 27, 2022 9:20 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2360
Location: Yateley, Hants, UK

PostPosted: Tue Dec 27, 2022 11:18 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7550
Location: Salford, UK

PostPosted: Wed Dec 28, 2022 8:32 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2360
Location: Yateley, Hants, UK

PostPosted: Wed Dec 28, 2022 12:25 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
simon



Joined: 05 Jul 2006
Posts: 241

PostPosted: Wed Dec 28, 2022 5:52 pm    Post subject: Reply with quote

I second that. I will be glad to have the /ALL_ERRORS compiler option.
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2450
Location: Sydney

PostPosted: Thu Dec 29, 2022 2:26 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7550
Location: Salford, UK

PostPosted: Thu Dec 29, 2022 9:50 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7550
Location: Salford, UK

PostPosted: Mon Jan 09, 2023 8:23 am    Post subject: Reply with quote

/ALL_ERRORS has now been added for the next release of FTN95.
Back to top
View user's profile Send private message AIM Address
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group