Feedback on 11.0 beta release

[murpup]

I just tried the beta release of 11.0 and thought I should provide some feedback.

1) when running the installation program (Intel IA32) after entering the serial number and clicking Next, the entire program simply hangs (Task Manager says the process is "Not Responding"). I am guessing the installation process is either running into our proxy or the local Windows firewall. Either way, the installer didn't offer any hint as to the problem or provide some means to circumvent the problem (like entering the proxy information or checkbox to inherit the IE proxy settings, etc). I had to restart the installation process and choose the Advanced license options to install the license file manually. Then it worked OK.

2) compile time for our code (~350,000 lines of Fortran) seems to be much slower than 10.1, by perhaps a factor of 2 or 3. Looks like it might be a couple of modules where all the extra time is being spent. If we ever get to a point where we can use IVF (see below) then I will raise the issue to premier support.

3) We submitted Issue number 462438 a little under a year ago and have yet to see a resolution to the problem (or even notification that it is still being looked at). The problem still remains with this beta release and is a showstopper for us as none of our executables run without a suitable fix or recommended work-around. Until it is resolved, we have to stay with CVF. Fixing the issue so we are able to use IVF will mean about 10-20 additional purchases of IVF licenses from our organization, our contractors, and user community.

Chris

[Andrew_Smith]

"We submitted Issue number 462438 "

Is this something you can post here. Maybe one or more forum users have found a solution.

Andrew Smith

[murpup]

Quoting - andrews@romaxtech.com

"We submitted Issue number 462438 "

Is this something you can post here. Maybe one or more forum users have found a solution.

Andrew Smith

OK, here is what I wrote in the trouble report, with a little bit of new info at the very bottom:

"After compiling our application with Intel Fortran for Windows, whenever we run the application, we see an access violation due to a corruption of memory upon entering a particular subroutine.

The specific situation is that we have a call to a subroutine with a long series of actual arguments, some of which are pointer arrays, derived-type components, and scalars of type INTEGER, REAL, and CHARACTER. When the call to the subroutine is made, the last argument, a CHARACTER string of length 8, becomes an undefined address. Subsequent attempts to assign a value to this variable fail with an access violation. I dont believe this should happen.

The calling semantics are:

INTEGER(sik) :: jc, ioff
CHARACTER(LEN=8) :: varType, varV
REAL(sdk), POINTER :: ptrVar, rArPtr(:)
INTEGER(sik), POINTER :: iptrVar, iArPtr(:)
LOGICAL, POINTER :: lptrVar
CHARACTER(LEN=8), POINTER :: charptr
REAL(sdk) :: x1, x2, x3

CALL GetPointer(varV, junCells(jc)%compNum, 'junNum',
-jc, ioff, 0, x1, x2, x3, ptrVar, iptrVar, lptrVar, charptr, rArPtr, iArPtr, flipJun, varType)



The dummy arguments look like this:

SUBROUTINE GetPointer(varName, compNum, locType, i1, i2, i3, x1, x2, x3, realptr, intptr, logptr, charptr, realAr, intAr, flipSign, vType)

CHARACTER(LEN=*), INTENT(IN) :: varName, locType
INTEGER(sik), INTENT(IN) :: i1, i2, i3, compNum
REAL(sdk), INTENT(IN) :: x1, x2, x3
LOGICAL, INTENT(OUT) :: flipSign
CHARACTER(LEN=*), INTENT(OUT) :: vType
INTEGER(sik), POINTER :: intptr
INTEGER(sik), POINTER :: intAr(:)
REAL(sdk), POINTER :: realptr
REAL(sdk), POINTER :: realAr(:)
CHARACTER(LEN=8), POINTER :: charptr
LOGICAL, POINTER :: logptr


There are several observations that lead me to believe this is an error in the Intel compiler for Windows:

a) this code runs fine with CVF, Absoft, Lahey, G95, and NAG compilers on Linux, Windows, and MacOS

b) this code runs fine when compiled with Intel Fortran on Linux and MacOS

c) We have compiled the code with all run time error checks in CVF and Lahey, Intel & NAG (on linux) to look for the existence of uninitialized variables, array bounds errors, etc. but it does not indicate anything unusual in this regard

Unfortunately, I was not able to decompose this into a simple example."

NEW INFO:

One of my colleagues did a little more investigation at the machine code level and says that he can see the problem as a 4-byte offset in the data that the subroutine is receiving vs what is being passed. He is working on sending me more details about what he did to make him believe this is true.

Thanks for help that might be provided,

Chris

[Les_Neilson]

Quoting - cjm4@nrc.gov

CALL GetPointer(varV, junCells(jc)%compNum, 'junNum',
-jc, ioff, 0, x1, x2, x3, ptrVar, iptrVar, lptrVar, charptr, rArPtr, iArPtr, flipJun, varType)


The dummy arguments look like this:

SUBROUTINE GetPointer(varName, compNum, locType, i1, i2, i3, x1, x2, x3, realptr, intptr, logptr, charptr, realAr, intAr, flipSign, vType)

CHARACTER(LEN=*), INTENT(IN) :: varName, locType
INTEGER(sik), INTENT(IN) :: i1, i2, i3, compNum
REAL(sdk), INTENT(IN) :: x1, x2, x3
LOGICAL, INTENT(OUT) :: flipSign
CHARACTER(LEN=*), INTENT(OUT) :: vType
INTEGER(sik), POINTER :: intptr
INTEGER(sik), POINTER :: intAr(:)
REAL(sdk), POINTER :: realptr
REAL(sdk), POINTER :: realAr(:)
CHARACTER(LEN=8), POINTER :: charptr
LOGICAL, POINTER :: logptr

If you haven't already done so, you could also try compiling with "Generate Interface Blocks" and "Check Routine Interfaces" switched on. You have i1,i2,i3 declared as INTEGER(sik) - what is the the size of the resulting integer?
Whatare the sizes of your "default integer" and "default real" and "double" (Project Properties->Fortran->Data) as you call the routine with a default integer zero for i3 If they are not the same size then you have an argument mismatch. I have been caught out beforein some of our owncode where the project setting defautreal size was8 bytes, andI thought itwas 4 bytes.

Les