project upgrade problem

[Brian_Murphy]

I am encountering problems building a project with XE2020 which builds successfully with XE2013.

error #7983: The storage extent of the dummy argument exceeds that of the actual argument.   [KG_]

In XE2013 the compiler command line is:

/nologo /debug:full /Od /warn:interfaces /module:"Debug\\" /object:"Debug\\" /Fd"Debug\vc100.pdb" /traceback /check:bounds /check:stack /libs:static /threads /c

In XE3020 this is:

/nologo /debug:full /Od /warn:interfaces /module:"Debug\\" /object:"Debug\\" /Fd"Debug\vc160.pdb" /traceback /check:bounds /check:stack /libs:static /threads /c

Cleaning up the array sizes in this very old code would be a huge undertaking (if it ain't broke don't fix it).  Why does XE2013 build this and XE2020 not?  Is vc160.pdb instead of vc100.pdb relative?

I found this related thread.  So I tried "cleaning" the project but that didn't help.

[jimdempseyatthecove]

Remove the /warn:interfaces for this source file to remove the error ***** However **** Warning Will Robinson ****

This error messages states that the procedure dummy argument, IOW the array as known by the procedure (subroutine or function) is larger than the array provided by the caller. This presents two potential sources for error:

1) When(data past end of argument) will be used for data. IOW using junk.
2) When used on the left hand side of a statement (without limiting subscripts) the excess size will be overwritten and thus unintentionally overwriting data past the argument supplied by the caller. IOW trashing data.

This stated, should the procedure explicitly subscript the dummy argument in a manner such that only the valid data portion of the actual argument is used, then you can safely ignore this error/warning.

*** I strongly suggest you carefully examine the code for safety before ignoring this error
The best route is to fix the code.

The fact that your program runs to completion (did not crash) is no indication that the results were correct. This error may have serendipitously produced the correct results in one build, with a specific set of options and/or version of compiler, is no guarantee that the results are not (will not be) adversely altered under different circumstances.

Jim Dempsey

[jimdempseyatthecove]

What is your objective? Or possibly what is your supervisor and/or users objectives:

a) Build without error messages
b) Run producing desired/correct results

These are not necessarily the same objectives.

Jim Dempsey

[Brian_Murphy]

My own objective is to retire an old computer with VS2010 and XE2013 and move to a new one with VS2019 and XE2020.  In addition to a mere platform change of the development environment, I am also revising small bits of code which is unrelated to the problems I'm encountering with XE2020.

My sponsor's objective (Texas A&M) is to get it done fast because user's are waiting.

I turned off /warn:interfaces, and that got me past this problem, but I still can't build the program because of yet more problems.

I agree that examining the code and fixing the array size problems makes sense, but that will have to be done by whoever takes my place.

From my perspective, the best solution would be to find out the proper way to port a project from XE2013 to XE2020 which addresses the problems I'm encountering.

This MSDN thread said to add legacy_stdio_definitions.lib to the list of Properties/Linker/Input/Additional Dependencies, and the program now links.  Yippee!

[JohnNichols]

Brian Murphy wrote:

My own objective is to retire an old computer with VS2010 and XE2013 and move to a new one with VS2019 and XE2020.  In addition to a mere platform change of the development environment, I am also revising small bits of code which is unrelated to the problems I'm encountering with XE2020.

My sponsor's objective (Texas A&M) is to get it done fast because user's are waiting.

I turned off /warn:interfaces, and that got me past this problem, but I still can't build the program because of yet more problems.

I agree that examining the code and fixing the array size problems makes sense, but that will have to be done by whoever takes my place.

From my perspective, the best solution would be to find out the proper way to port a project from XE2013 to XE2020 which addresses the problems I'm encountering.

The actual problem is that Intel slowly but completely fixes Fortran and slowly catches old errors that old compilers used to miss. My worst experience with this was moving from MS 3.03 to Powerstation in about 1990.  personally MS3.03 was better from my view than Powerstation. 

Often the old printed Fortran manuals provide better examples than is currently available - but it is usually trial and a lot of error. 

Updating old code is a trial and good luck - but this forum is the best place to ask questions - if it is Fortran these are the Pros from Dover  - of course if it is about the mating habits of the hedgehog then this is not the place - you need BBC radio 4 which just provided a 20 minute lecture on the topic.