Intrinsic gives warning #7322: Symbol not previously declared. [LEN]

Intrinsic gives warning #7322: Symbol not previously declared. [LEN]

I have an application with around a 1000 routines and functions, IMPLICIT NONE is present in >95% of them. I compile everything with /warn:declarations also.

I re-organised some module variables from one module to another and made use of declaration warnings to identify where USE statements needed changing. By a twist of fate (read error on my part)  /warn:declarations was not switched on so my fixes were a result of that good old saviour IMPLICIT NONE. Of course I then later got screwed over by some of the few rogue routines that  did not have this....

As an aside, a complier option to give a warning or error when  IMPLICIT NONE  is not present would be very very helpful. I spent a couple of hours searching and pasting in IMPLICIT NONE and think this is now everywhere but I cannot be 100% certain and there is no guarantee that I will omit it when making new routines....

As a belt and braces and a further piece of string I added !DEC$ DECLARE  to the top of all my source files and was surprised to get some warnings on use of the intrinsic LEN (warning #7322: Symbol not previously declared.   [LEN]). An example is below...

subroutine fred(title)
implicit none
character(*), intent(IN) :: title 
character(LEN(title)+1)  :: newtitle

This doesn't make sense to me?

18 posts / 0 nouveau(x)
Dernière contribution
Reportez-vous à notre Notice d'optimisation pour plus d'informations sur les choix et l'optimisation des performances dans les produits logiciels Intel.

I usually put my routines in modules and place implicit none in the module heading. Since I have far fewer modules than routines I don't need to type implicit none very often. Using modules also explicitly provides interfaces which helps in detecting dummy argument mismatches.

@Andrew Yes a valid point, about 25% of the routines are in various modules according to some logical grouping and to provide a degree of 'encapsulation' where possible. The scope of IMPLICIT NONE within the module is helpful. There is a large bulk of older stuff that there would be quite a lot of edits to 'modulise', e.g. adding the words function or subroutine to the end statements in most cases, and lots of adding and removing USE statements all over the place.  I can't see any logic in doing this as /check interfaces does a good job with respect to interfaces. I do periodically break out a set of routines into a module where I am making some changes and there is logic to grouping the routines. 

Notwithstanding the above I still feel that a compiler warning option for the absence of IMPLICIT NONE within the scope of a routine would be helpful and I suspect quite easy to implement as for each routine the compiler must already have a flag(s) set for the declaration status I would expect.

I noticed your employer from your user entry. It is a small world, I used to have my business on that Science Park up to about 17 years ago, I was in the large yellow building from not long after it was built.

I think if you do a little digging (or someone here might reply) you will be able to find a "LINT" program that will fetter out the undeclared symbols (and typeo's).

Jim Dempsey

www.quickthreadprogramming.com

@Jim. Thanks Jim but no Lint is required as I don't have  any  undeclared symbols, ifort correctly finds these with the correct compiler options.

Regarding your original question - it seems to be the !DEC$ DECLARE that does this. I wasn't even aware this directive existed! The description of it in the documentation is very strange, and inconsistent. I will let the developers know about this problem - thanks. Issue ID is DPD200251086.

I assume you do know about /warn:declarations

Steve - Intel Developer Support

It is indeed !DEC$ DECLARE that does this, it surprised me as I would have expected it would be exactly the same as /warn:declarations. I had not used this directive before today but it harks back to the $DECLARE directive that was in the old Microsoft Fortran.

It begs the question of what is the point of NODECLARE does this override  /warn:declarations or IMPLICIT NONE or does it in fact do precisely nothing? 

 

 

I'm not sure - my guess is that it's supposed to be like IMPLICIT NONE for the statements between DECLARE and NODECLARE. I have asked the developers to clarify, and then I will have the documentation clarified.

Steve - Intel Developer Support

Citation :

app4619 a écrit :

As an aside, a complier option to give a warning or error when  IMPLICIT NONE  is not present would be very very helpful. I spent a couple of hours searching and pasting in IMPLICIT NONE and think this is now everywhere but I cannot be 100% certain and there is no guarantee that I will omit it when making new routines....

Not sure if this would help you, but in our situtation, it usually translates to one "IMPLICIT NONE" statement per Fortran source file since our Fortran files are either MODULEs or those that have single SUBROUTINEs/FUNCTIONs in a file.  So I usually do a search for "IMPLICIT NONE" string in a source folder and I expect the number of hits to be equal to the number of Fortran files in the folder.  I use Unix-like "grep" utilities (for freeware, one can look at http://astrogrep.sourceforge.net/) using which I can quickly determine if any file is missing the declaration and fix it as needed.

For new source code, I always start with my own Fortran MODULE "template" which includes IMPLICIT NONE in addition to various other things including beginning and ending lines, USE statements (e.g., for my variable KINDS module), header, description, etc.

 

@fortranfan - Yes that is a thought whilst there are large numbers of routines per source file I do have a utility that explodes a source file into one file per function with a file name being that of the routine. I have another utility that (works like like grep as you say) that would find and list any files that didn't have a string like 'implicit none'.

.I fixed things for now anyway so will not looki at this any further, but my suggestion of the 'Implicit none' checker in the compiler I still think is a valid suggestion as it is yet another 'good practice' checker.

One of the things I like these days (in Ifort) is the array of options that allow you to find and eliminate bugs at an early stage. 

Citation :

app4619 a écrit :

.. but my suggestion of the 'Implicit none' checker in the compiler I still think is a valid suggestion as it is yet another 'good practice' checker.

I agree: something like /warn:implicit would be a nice warning for the programmer that implicit typing is in effect for the given source.

Citation :

app4619 a écrit :

.. I do have a utility that explodes a source file into one file per function with a file name being that of the routine.

Is it the good, old FSPLIT.EXE that used to come with Digital Fortran?!  I have FSPLIT via my copy of Digital Fortran and I used it not too long ago on code from 1979!  I wonder why Intel doesn't include FSPLIT and FSPLIT90 in their software suite anymore!

FSPLIT or programs of that name pre-date DVF. I used such on Microsoft Fortran on 8086 PC's in the 80s as I recall batch files split the source compiled each unit and added to a library. When you linked redundant/unused routines did not get baked into your exe increasing its size. The was a similar tool on Apollo Fortran and I guess many others.

That would be perfect!....

I agree: something like /warn:implicit would be a nice warning for the programmer that implicit typing is in effect for the given source.

We've had the request for an option to warn of implicit interface, this might go with it.
 

Steve - Intel Developer Support

We've had the request for an option to warn of implicit interface, this might go with it.

 

Yes Please :-)

As an aside, I spent an hour knocking up a quick console program that reads a free format source file and reports the starting line  number of any subroutine or function that does not contains a specific string (in this case IMPLICITNONE - all white space gets removed).

I have to report my earlier manual endeavours must have worked worked well as I only found one rogue in 40,000 lines of code and a couple that I had deliberately made to prove it worked.

 

fsplit.c should still show up in your searches,  It required fixed form source. f90split might interest you. 

In the old days, we had not only to use fsplit to make separate objects, we had to process through lorder | tsort to filter out those which weren't referenced.  Those don't work so well nowadays, so the advice posted elsewhere on these forums to use the compiler ipo facilities might be of interest.

@tim/fortranfan

Having not used a "spitter" for years I downloaded http://people.sc.fsu.edu/~jburkardt/f_src/f90split/f90split.f90 a couple of days back, it is F90 free form splitter was last updated in 2011 and seems to work well.

Using that and a free dos find in files search/replace/count utility (FART.exe!) I checked though a swath of code for various things (knowing some many routines i.e. files you have and making lists of which contain or do not contain specific strings) and managed to make some significant reorganisations, For example, grouping routines with specific external module dependencies in different source files, and ordering routines within the source in alphabetic order, the previous ordering in non-modulised source files had no logic and was just a result of a process of 'semi-random' evolution over many years.

This process took only a short amount of time and I am finding builds much quicker now as some sources changes are generating smaller builds as the source file interdependencies are reduced. Ultimately this will help in organising more code with logical modules in the future.

 

Intelligent grouping of procedures into source files should help with /Qip optimization (which is on by default). Possible improvements might be in effectiveness or reduced compiler time or object code expansion. The original intent of lorder ("library order") was to make single pass library scanning work, but it could help with instruction cache locality as an automatic side effect.

Laisser un commentaire

Veuillez ouvrir une session pour ajouter un commentaire. Pas encore membre ? Rejoignez-nous dès aujourd’hui