forrtl severe (408) fort (19) Dummy character variable ...

[Han_H_]

Hi,

I have encountered a problem when porting fortran algorithm to C++.

The console has reported forrtl severe (408) fort (19) Dummy character variable 'TASK' has length 60 which is greater than actual variable length -3689***********

The calling code looks like this

SETULB(&n_, &m_, &param_.x[0], &param_.lb[0], &param_.ub[0],
        &param_.constraints[0], &f_, &g_[0], &factr_, &pgtol_, &wa_[0],
        &iwa_[0], &task_[0], &iprint, csave_, lsave_, isave_,
        dsave_, 60, 60);

where    char task_[60];

And the fortran routine looks like

subroutine setulb(n, m, x, l, u, nbd, f, g, factr, pgtol, wa, iwa,
     +                 task, iprint, csave, lsave, isave, dsave)
 
      character(60)     task, csave
      logical          lsave(4)
      integer          n, m, iprint, 
     +                 nbd(n), iwa(3*n), isave(44)
      double precision f, factr, pgtol, x(n), l(n), u(n), g(n),
c
c-jlm-jn
     +                 wa(2*m*n + 5*n + 11*m*m + 8*m), dsave(29)

The code breaks at

 if (task .eq. 'START') then ...

Could anyone give some instructions on how to solve this problem? By the way, I'm using Visual Studio 2010 for C++ compiler

[mecej4]

Are you targeting 64-bits? If so, the character string lengths should be passed as 8-byte integers with some compilers including IFort; since Fortran does not have strings of negative length, it looks likely that the length is being read from an improper stack location.

See if this older thread covers your question: https://software.intel.com/en-us/forums/topic/279684 .

[Lorri_M_Intel]

What command qualifiers are you using to compile the Fortran piece?

[Anthony_Richards]

Your subroutine definition has 18 arguments. Your call to it gives 20 arguments.

Your C-code should prototype your subroutine as a null and use EXTERN 'C' and specify the calling convention.
Search this forum for mixed  C++-Fortran and plenty of advice is available here.

[Lorri_M_Intel]

Hi Anthony --

    The "18 vs 20" arguments is probably OK; by default ifort expects the length of character arguments appended to the end of the argument list and passed by value.     There are two character arguments, and the lengths being passed are "60".

I asked about the compilation switches for the Fortran code to see whether something may have disrupted that default expectation.

[Anthony_Richards]

..and what if you want to send the lengths explicitly and not have 'hidden' lengths expected?

[mecej4]

Tony, the character arguments have their lengths hidden only when the subroutine call / function invocation takes place in Fortran. The user is calling from C, and has to conform to the conventions of Fortran that the called subroutine expects..

For passing strings to C from Fortran (not the issue of this thread), compilers may provide switches to prevent the extra length arguments from being passed, and for conversion to C strings.

[Han_H_]

Hello everyone, I have tested this issue for several methods and got several solutions. Here is the summary, although I don't quite understand the reasons. Maybe someone here may explain them,

For the first one, using Intel FORTRAN Compiler,

Win32 - the code need not to be changed, it will not cause any run-time problem.

X64 - add the following code under the declaration of the subroutine as suggested by mecej4

!DEC$ ATTRIBUTES REFERENCE :: SETULB
!DEC$ ATTRIBUTES REFERENCE :: task
!DEC$ ATTRIBUTES REFERENCE :: csave

For the second one, compile the fortran code in gfortran and I'm using Code::Blocks as the IDE.

It will not cause any problem with the code unchanged. However, the declaration in C-code should be in lowercase and with striping as "setulb_". The fortran code is compiled as a static library, and when linking it in C/C++, I should also link "libgfortran.dll.a". Then everything will works fine.

In the end, I have to say that I don't know why these should work indeed~

[mecej4]

Han H. wrote:
n the end, I have to say that I don't know why these should work indeed~

The details are gory, and at the assembler level. Therefore, one can take solace from this quote of Thomas Gray, "Where ignorance is bliss, 'tis folly to be wise!"