Problem with subroutine with a lot of arguments

[albert]

Dear all,

I have a subroutine with 10 double precision, 10 integer and one character type of argument. On a windows 32-bit system with /iface:cvf one would expect a "signature" of 88 (TEST_CALLEE@88). For the subroutine I get this signature, but when calling the routine I get the "signature" 92. When linking this gives problems.
When I reduce the number of integers I get in both cases "signatures" 84.

When using the intel 11 compiler (Intel Visual Fortran Compiler Professional for applications running on IA-32, Version 11.1 Build 20091012 Package ID: w_cprof_p_11.1.051) I encounter this problem, when using the Intel 10 compiler (Intel Visual Fortran Compiler for applications running on IA-32, Version 10.1 Build 20080212 Package ID: w_fc_p_10.1.019) I do not encounter this problem.

used command lines to compile the (attached) sources:
ifort /O3 /G7 /QxW /nologo /MD /Qvec-report0 /iface:cvf -c a1.f90 /Fo:a1.o
ifort /O3 /G7 /QxW /nologo /MD /Qvec-report0 /iface:cvf -c a2.f90 /Fo:a2.o

What am I doing wrong ?

Best Regards,

Albert

[Steven_L_Intel1]

We've had bugs in that area at times. I see no problem with version 12, and I would expect a more recent 11.1 to also not have an issue. Do you still need /iface:cvf? /QxW is the default in version 11, by the way.

[albert]

Dear Steve,

Thank you for the quick answer.
I have some subsequent quetions regarding this problem:
- Is there more information available about this bug ? or canI find the release notes of the subsequent compilers somewhere ?
- Does this or a similar problem occur on Linux as well ?
- In which version of the Intel 11 compiler is this problem solved ?

Best regards,

Albert

[Steven_L_Intel1]

I can't readily find a particular issue that matches your code. Such a problem would be on IA-32 Windows only, and then only if you used /iface:cvf or otherwise forced a STDCALL calling mechanism, and don't have those old compilers currently installed to test. It does work with the current release.

Lists of bugs fixed are provided as "README" files at the Intel Registration Center alongside the downloads for the individual compiler updates. (Release notes are also there, but there is a release notes link at the top of the main forum page.)

[Lorri_M_Intel]

The sources you attached had one argument commented out; I'm guessing that's why Steve couldn't reproduce the failure.

If you remove the comment character so that there are 21 arguments to the routine, then the problem happily reproduces.

And no, it is not caused by /iface:cvf, and without /iface:cvf, it could also show itself as an odd failure at runtime.

We recently received a different example of this same problem; its internal number is DPD200170498, and is still there as of today, in current compilers.

However --- there is a workaround I can offer.We have an undocumented command line switch that disables the code that caused the problem.

If you add /switch:fe_inline_all_arg_copy_inout to your command line, that will avoid the problem.

I hope this helps ---

-- Lorri

[albert]

Dear Lorri,

Thank you very much for the answer.
I thought it might have been clear from the description that I had some problems with the number of arguments and looking at the code it should have been clear that one variable was commented out to simualte the rigth execution. In the future I'll put some extra comment in either the code or the description of the problem so this is clear to everybody (the problem how to simulate both ways was clear to me ,, but I now can understand that it might be not clear to other people straight away). Sorry for this inconvenience.

I have some additional questions:
- does this /switch:fe_inline_all_arg_copy_inout have a speed disadvantage ?
- is this bug present on other platforms (windows 64-bit, Linux), it does not show there but there there is no "decoration" of function calls as there is (possible) on Windows 32-bit
- would the problem be solved as well by using an explicit interface ?

Best Regards,

Albert

[mecej4]

As far as I understand, with /iface:cvf the problem is caught at link time. Without the option, there is no name decoration with the byte count of the argument list, and no link-time error occurs. However, the compiled code is wrong, and may cause unpredictable failures. Worse, the program may run with no apparent errors but the results could be wrong and the errors could go undetected.

If an explicit interface is added, the problem is not caught at link time, but the bug appears to remain. With

ifort /iface:cvf a1.f90 a2.f90 /link /stack:1000000

the 11.1.070 compiler on Windows-32 gives a stack overflow with your example code (with interface block added).

[Lorri_M_Intel]

No need to apologize; I was mainly trying to let Steve know why I saw the issue and he didn't.

Anyway - to answer your questions:
Does it have a speed disadvantage?
For this example, no.
*IF* you had many (sorry, I can't quantify "many", but probably more than 5) arrays (of any data type)that needed to be copyin/copyout, then it could affect performance.

Yes, the bug is present everywhere, although it shows itself differently (ie, bad runtime)

Finally, no, an explicit interface would not help. The characteristic of the bug is 20+ arguments,at least one of which isaCHARACTER copyin/copyout.

-- Lorri

[albert]

Dear Lorri,

Thank you for your answer. This means that we have to walk trough our entrire code base to find routines with "a lot of: arguments and having at least one of them of type character. Therfore it is quite important for us to know the excact conditions this problem occurs. We have seen in my example that it manifests itself when I have 20 integer / floatin point arguments plus 1 character argument. Does it show too with in case of 18 Integer / floating point plus 2 character arguments ? (as Fortran places in our case an extra length argument with the character string) I don't think so otherwise it would also have given an error in the case of 18 integer / floating point arguments and 1 character argument. But I'd like to be sure about when the problem occurs.

Is there also a relation with the optional keyword ? we recently had a case that a character argument was not passed (we got an emtry string) on the first invocation of a subroutine but it was passed in subsequent calls. I "solved" this by handing over all optional character arguments and at that time it did work (This problem was on Linux). I have to see if I can generate a small example of this problem.

Best regards,

Albert

[Steven_L_Intel1]

Albert,

Regarding the OPTIONAL keyword - was an explicit interface to the procedure visible to the caller? This is required when you use OPTIONAL.

If you use the option Lorri provided, you'll avoid the "too many arguments" problem.

[albert]

Hi Steve,

Yes, there was on interface definition.
The problem with the option provide is that, as far as I can see, a copy of the input is made and after the routine the data is copied back. For one or 2 routines this would not be a problem but with a lot of routines and having large array's this might have speed implications.
Therfore we'd rather know exactly how to overcome the problem and restructure the few routines that cause problems.

Best Regards,

Albert

[Lorri_M_Intel]

Ah ah ah, I see the misunderstanding.

For arrays that require copyin/copyout, there will *always* be copyin/copyout. That will not change whether the switch is passed or not.

All the switch does is change whether the copyin/copyout code is created as inline code, or whether a run-time routine is called to do the copies.

The copies always happen.

Now --- your other question: To provoke the bug, you need 20+ arguments, and at least one of them is a CHARACTER that requires copyin/copyout. There can be two CHARACTER arguments that require copyin/copyout, or 3, or all 20+.

In this particular case, what is requiring the copyin/copyout is the fact that you are passing a pointer to a non-pointer.

Ie, in test_caller:

CHARACTER(LEN=80), DIMENSION(:), POINTER :: pc_string

CHARACTER(LEN=80), DIMENSION(20), TARGET :: tc_string

pc_string => tc_string

CALL TEST_CALLEE( &

,

pc_string)

Then, in test_callee, the string is received as:
CHARACTER(LEN=*), DIMENSION(2,*) :: c_string

Bottom line, just use -switch:fe_inline_all_arg_copy_inout and you should be perfectly fine.
No need to scour your code to determine which files need it.

-- Lorri

[Michael_J_Slater__In]

I have published a Knowledge Base article on this in case anyone is interested.

It contains a simple test case and the workaround.

http://software.intel.com/en-us/articles/subroutine-20-arguments-with-character-pointer-invalid-string-length/

[albert]

Dear all,

I'm now in the process of "correcting" the relevant subroutines. One of the routines has on Windows 32-bit the decoration @96, when counting the number of arguments it are 17 of which there are 7 of type character.
So on the stack there will be 17 arguments and 7 length specifications.
In the problem description we always see more than 20 arguments. Do these 20 arguments include those extra length specifications of the character type variables ?
So in my above mentioned case would I have, for the counting in this bug, 17 or 24 arguments?

Thanks in advance,


Best Regards,

Albert

[mecej4]

Put on your "Fortranner" hat when counting arguments. You can see this for yourself by removing the ",s" from the argument list in Michael Slater's example and the corresponding ",0" in the call. With these changes, there are 20 arguments, two of type character and 18 of non-character, and the bug is not seen.

[albert]

Seen the complexity of this bug I think the answer "the bug is not seen" is not sufficient. As this is production code I'd like to know for sure (I know one never can be 100% certain, there might always be flaws in the program, compiler, hardware, but everybody tries to generate the best) if the extra arguments due to the character type arguments have to be taken into account or not. I don't think they should be taken into account but I want to be sure.

Best Regards,

Albert