Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28558 Discussions

Code compiles in Release but not in Debug

Feng__Jesse
New Contributor II
589 Views

I have a fixed form code that I have used for almost 10 years now and never seen this issue before. I added 6 arguments to a subroutine:

Old:

 

 

      SUBROUTINE UMAT(STRESS,STATEV,DDSDDE,SSE,SPD,SCD,
     1           RPL,DDSDDT,DRPLDE,DRPLDT,
     2           STRAN,DSTRAN,TIME,DTIME,TEMP,DTEMP,PREDEF,DPRED,CMNAME,
     3           NDI,NSHR,NTENS,NSTATV,PROPS,NPROPS,COORDS,DROT,PNEWDT,
     4           CELENT,DFGRD0,DFGRD1,NOEL,NPT,LAYER,KSPT,KSTEP,KINC)

 

 

New:

 

 

      SUBROUTINE UMAT(STRESS,STATEV,DDSDDE,SSE,SPD,SCD,
     1           RPL,DDSDDT,DRPLDE,DRPLDT,
     2           STRAN,DSTRAN,TIME,DTIME,TEMP,DTEMP,PREDEF,DPRED,CMNAME,
     3           NDI,NSHR,NTENS,NSTATV,PROPS,NPROPS,COORDS,DROT,PNEWDT,
     4           CELENT,DFGRD0,DFGRD1,NOEL,NPT,LAYER,KSPT,KSTEP,KINC,
     5           outputArray1,outputArray2,outputArray3,nsp1,nsp2,nsp3)

 

 

I changed the calls to the subroutine accordingly:

 

 

      CALL UMAT(STRESS,STATEV,DDSDDE,SSE,SPD,SCD,RPL,DDSDDT,
     1            DRPLDE,DRPLDT,STRAN,DSTRAN,TIME,DTIME,TEMP,DTEMP,
     2            PREDEF,DPRED,CMNAME,NDI,NSHR,NTENS,NSTATV,PROPS,
     3            NPROPS,COORDS,DROT,PNEWDT,CELENT,DFGRD0,DFGRD1,
     4            NOEL,NPT,LAYER,KSPT,KSTEP,KINC,outputArray1,
     5            outputArray2,outputArray3,nsp1,nsp2,nsp3)

 

 

The code compiles in Release as it should, but in Debug it says: 

 

 

error #6784: The number of actual arguments cannot be greater than the number of dummy arguments.   [UMAT]		...\modules_main.for	547	
error #6784: The number of actual arguments cannot be greater than the number of dummy arguments.   [UMAT]		...\modules_main.for	695	
error #6784: The number of actual arguments cannot be greater than the number of dummy arguments.   [UMAT]		...\modules_main.for	717	

 

 

The 6 new outputs are defined with:

 

 

      DIMENSION outputArray1(100),outputArray2(100),outputArray3(100)
      integer :: nsp1,nsp2,nsp3

 

 

If I remove the 6 added arguments from everywhere, the code can compile as expected. If I remove the 6 added arguments from the subroutine calls (but leave it in the definition), the code can compile. And again the code can compile with the change in release but not in debug.

Does anyone have any ideas on how to fix this?

Jesse

 

PS. I have a new symptom. I was suspecting maybe it is exceeding the number of continuation lines (it shouldn't), so I changed the code to the following, it does not change the number of parameters, but now it only has 4 continued lines instead of 5:

 

              CALL UMAT(STRESS,STATEV,DDSDDE,SSE,SPD,SCD,RPL,DDSDDT,
     1 DRPLDE,DRPLDT,STRAN,DSTRAN,TIME,DTIME,TEMP,DTEMP,PREDEF,DPRED,
     2 CMNAME,NDI,NSHR,NTENS,NSTATV,PROPS,NPROPS,COORDS,DROT,PNEWDT,
     3 CELENT,DFGRD0,DFGRD1,NOEL,NPT,LAYER,KSPT,KSTEP,KINC,outputArray1,
     4 outputArray2,outputArray3,nsp1,nsp2,nsp3)

 

 I get new errors:

 

error #7983: The storage extent of the dummy argument exceeds that of the actual argument.   [OUTPUTARRAY1]		...\modules_main.for	550	
error #7983: The storage extent of the dummy argument exceeds that of the actual argument.   [OUTPUTARRAY3]		...\modules_main.for	551	
error #7983: The storage extent of the dummy argument exceeds that of the actual argument.   [OUTPUTARRAY2]		...\modules_main.for	551	
error #7983: The storage extent of the dummy argument exceeds that of the actual argument.   [OUTPUTARRAY1]		...\modules_main.for	697	
error #7983: The storage extent of the dummy argument exceeds that of the actual argument.   [OUTPUTARRAY3]		...\modules_main.for	698	
error #7983: The storage extent of the dummy argument exceeds that of the actual argument.   [OUTPUTARRAY2]		...\modules_main.for	698	
error #7983: The storage extent of the dummy argument exceeds that of the actual argument.   [OUTPUTARRAY1]		...\modules_main.for	718	
error #7983: The storage extent of the dummy argument exceeds that of the actual argument.   [OUTPUTARRAY3]		...\modules_main.for	719	
error #7983: The storage extent of the dummy argument exceeds that of the actual argument.   [OUTPUTARRAY2]		...\modules_main.for	719	

PPS: There is one more symptom and now I think it might be my computer system. Since the code compiles in release I wanted to proceed with my work. So I reverted all the changes since it was only for output anyway. Now the compiler is complaining that I need to put the 6 new parameters in:

error #6631: A non-optional actual argument must be present when invoking a procedure with an explicit interface.   [OUTPUTARRAY1]		...\modules_main.for	547	
error #6631: A non-optional actual argument must be present when invoking a procedure with an explicit interface.   [NSP3]		...\modules_main.for	547	
error #6631: A non-optional actual argument must be present when invoking a procedure with an explicit interface.   [NSP2]		...\modules_main.for	547	
error #6631: A non-optional actual argument must be present when invoking a procedure with an explicit interface.   [OUTPUTARRAY2]		...\modules_main.for	547	
error #6631: A non-optional actual argument must be present when invoking a procedure with an explicit interface.   [OUTPUTARRAY3]		...\modules_main.for	547	
error #6631: A non-optional actual argument must be present when invoking a procedure with an explicit interface.   [NSP1]		...\modules_main.for	547	

Usually these issues are fixed when I close and re-open visual studio, but it did not fix it. I will try restarting my computer and see if that helps. If anyone still have any ideas any suggestions would be appreciated.

 

0 Kudos
1 Solution
Ron_Green
Moderator
568 Views

Debug config turns on /warn:interfaces.  that option implicitly turns on /gen-interfaces. You have a mismatch between a generated interface for the subroutine and your call sites listed above.

 

First read /gen-interfaces documentation to understand the automatically created interfaces for your subroutines.  Remember that you will not see this option directly in your Project settings for Debug configuration.  Rather, it is implicitly invoked when ...

/warn:interfaces is an option in your Project/Configuration settings.  This option is turned on for Debug configurations by default.

 

With this background, first CLEAN all your projects, particularly the project containing the source file with SUBROUTINE UMAT.  Now, use File Explorer and dive down into your Debug folder and see if any .mod files are left over.  In particular, look for procedure-name__GENmod.f90 as well as the procedure-name__GENmod.mod files.  These should have been cleaned up, if not, remove them.

 

Rebuild Debug config

 

Use file explorer again.  Find the procedure-name__GENmod.f90 file for UMAT.  This is a text file.  Open it. Examine.  This is what the compiler thinks are your arguments and kinds for the arguments.
Now keep that open and go to any warning/error about CALL UMAT and compare what the compiler thinks the arguments should be, and what you are using in the CALL.  Do they match in number and KIND?  

The compiler is trying to help you out here and prevent stack corruptions due to mismatched arguments.  Take this very seriously, there is a problem in your code that needs to be addressed.

View solution in original post

4 Replies
Ron_Green
Moderator
569 Views

Debug config turns on /warn:interfaces.  that option implicitly turns on /gen-interfaces. You have a mismatch between a generated interface for the subroutine and your call sites listed above.

 

First read /gen-interfaces documentation to understand the automatically created interfaces for your subroutines.  Remember that you will not see this option directly in your Project settings for Debug configuration.  Rather, it is implicitly invoked when ...

/warn:interfaces is an option in your Project/Configuration settings.  This option is turned on for Debug configurations by default.

 

With this background, first CLEAN all your projects, particularly the project containing the source file with SUBROUTINE UMAT.  Now, use File Explorer and dive down into your Debug folder and see if any .mod files are left over.  In particular, look for procedure-name__GENmod.f90 as well as the procedure-name__GENmod.mod files.  These should have been cleaned up, if not, remove them.

 

Rebuild Debug config

 

Use file explorer again.  Find the procedure-name__GENmod.f90 file for UMAT.  This is a text file.  Open it. Examine.  This is what the compiler thinks are your arguments and kinds for the arguments.
Now keep that open and go to any warning/error about CALL UMAT and compare what the compiler thinks the arguments should be, and what you are using in the CALL.  Do they match in number and KIND?  

The compiler is trying to help you out here and prevent stack corruptions due to mismatched arguments.  Take this very seriously, there is a problem in your code that needs to be addressed.

Feng__Jesse
New Contributor II
552 Views

Thank you very much! This solved it. I will remember that from now on.

0 Kudos
mecej4
Honored Contributor III
562 Views

I suspect that the subroutine UMAT being discussed is an ABAQUS Umat subroutine, in which case the user is not free to change the argument list of the subroutine. These subroutines are intended to be called from the Abaqus FEA program, and their interface is defined by the program vendor. A user may add arguments and pass those new additional arguments from calls within the user's own sources, but the Abaqus program will not pass those additional arguments since it knows nothing about them.

If there are include files in which are located standard Umat interface blocks, those will be incompatible with the new interface. A compilation with checking options enabled will flag those incompatibilities, whereas a Release build will not.

0 Kudos
Feng__Jesse
New Contributor II
553 Views

This is true if I am running it with Abaqus. But I am running it standalone with an umat wrapper that simulates Abaqus. So it is just like any other Fortran code.

Reply