Intel Software Network - feed

Structure constructor with UNION ... END UNION

Sat, 07 Nov 2009 01:45:32 -0800

Hello,

I get the following error message for a structure constructor of a derived type:

error #8212: Omitted field is not initialized. Field initialization missing: [RR143]

However, RR143 is not an additional field, but a mapping. Am I missing something or is this a compiler problem?
Before I used equivalence to map an instance of the derived type and the array representation in the same memory. Since this presented serious problems (which are actually resolved in 11.1.051) I tried the UNION..END UNION, which obviously resulted in a different kind of problem. What would be the preferred method anyway, equivalencing or using UNION .. END UNION (provided the issue with the structure constructor is resolved)?

The constructor looks like this:

RC143=ST143(' ',(/' ',' ',' '/),0.,0.,0.,0.,0., &
0.,0.,0.,0.,0.,0.,0.,0.,0.,0.,0.,0.,0.,0)

and the derived type declaration looks like this:

TYPE ST143
SEQUENCE
UNION
MAP
    CHARACTER(4) IDF
    CHARACTER(4) NAME(3)
    REAL(4) TFL1
    REAL(4) TFLX
    REAL(4) DTMX
    REAL(4) FFL
    REAL(4) CPFL
    REAL(4) UA
    REAL(4) WFH
    REAL(4) XT
    REAL(4) DUA
    REAL(4) TFL2
    REAL(4) WCFL
    REAL(4) WCS
    REAL(4) CPS
    REAL(4) XNTU
    REAL(4) CAR
    REAL(4) EFF
    REAL(4) TS2
    REAL(4) XLMTD
    INTEGER(4) IP2
END MAP
MAP
    REAL(4) RR143(23)
END MAP
END UNION
END TYPE
TYPE(ST143)    RC143

Walter Kramer

LNK2019: unresolved external symbol imp VF 11.1?

Fri, 06 Nov 2009 17:27:58 -0800

Just upgraded to 11.1.48 on Windows XP. Recompiled a C++ wrapped Fortran DLL with generate interfaces turned on got
error LNK2019: unresolved external symbol __imp__MYSUBB@448 referenced in function _MYSUBA in file mydll_lib.lib

* Where did the _imp_ come from? How can I make it go away and work like it did before?

As frustrating as "it used to work" with Compaq Visual Fortran 6 and even Intel 11.0 is, I'd like to thank the new compiler for finding 4 other seriously wrong problems with our interface! I'm sure we've done something stupid again, I just can't find it. I see there is another upgrade to Intel 11.1.51, should I try that? Nothing more fun than comparing declarations of calling arguments until you find the one array that's off but the compiler was right!

mysubb in question is being called from mysuba as two files in the same DLL that also has a C++ wrapper. These two subs are not the public interface that C++ exports, they are internal sub sub routines. However, mysubb is also used by another DLL and is exported so the line
cDEC$ attributes dllexport::mysubb
is present. In desperation, after double checking each calling argument with the generated interface, I removed the cDEC command, deleted the contents of the DEBUG folder, and did a clean rebuild with no luck.

From all the previous discussion on LNK2019, I see our C++ has the uppercase name with
extern "C" void __stdcall MYSUBB

(a) upgrading to the latest compiler will fix this _imp_ problem?
(b) I need to add more stuff to the cDEC$ line because things have changed? The discussion on CVF vs "C" vs stdcall is not clear since we seem to be using all 3?
(c) I can't sit on the fence and need to call the DLL from the DLL if cDEC is present?

workaround: turn off generate interface blocks which then generates the expected _MYSUBB@448 in the .obj file

We're using /iface:cvf I saw some discussion of Fortran 2003 Bind(C) but at the moment we have to support both the old and new compilers with our code. The above mentioned good finds by generate interface blocks still work in the old compiler but F2003 would not.

I made a separate .exe project, put all the code in it, set all the compiler options the same, and it works! Which gives 3 scenarios:
1. stand alone Fortran exe with all the code
2. C++ wrapped Fortran DLL that calls sub sub routine that is also exported by another DLL
3. DLL that calls another DLL

Problem with Fortran Compiler and Vista

Fri, 06 Nov 2009 14:14:58 -0800

The latest Fortran compiler works well on a computer with XP Pro, but on Vista it does not. The drop down menu is different -- I do not see the "Extract Compaq Virtual Fortran.." option on the drop-down menu as it shows on XP Pro. How to fix this?

Vijay

Bad compiler error with procedure pointer component array

Fri, 06 Nov 2009 13:33:30 -0800

I am attaching two files (one module that USEs another) that demonstrate an incorrect compiler error. I have a derived type that contains a pointer array of another derived type, which contains a procedure pointer. When I create a subroutine that sets the procedure pointer, the compiler complains that the procedure pointer targets "must have matching arguments", but they are both declared with the same interface ("response_template"), so they do have matching arguments.

The compiler error seems to have something to do with the definition of the ABSTRACT INTERFACE in a separate module, because including the code from GlobalDef.f90 directly in FPointer.f90 (as opposed to referencing it as a module) makes the error go away...

Thanks in advance,
John

Position-dependent explicit interface?

Fri, 06 Nov 2009 13:17:28 -0800

Hi,

When I try to compile the code below, I get an error stating that the specified interface (for the procedure func) is not declared. But if I place the "square" function right before "loopOverFunc" then I get no error (although I get a misleading warning regarding the result of the "square" function). Is it a bug in the compiler or the intended behavior?

module mod1

implicit none

contains
!------------------------------------------------------------------------------
function loopOverFunc(func, array) result(sq)
procedure(square) :: func
integer, intent(IN) :: array(:)
integer :: sq(SIZE(array))
integer :: i
continue
do i = 1, SIZE(array)
sq(i) = func(array(i))
enddo

end function
!------------------------------------------------------------------------------
elemental function square(a) result(sq)
integer :: sq
integer, intent(IN) :: a

continue
sq = a ** 2
end function

end module mod1

Memory allocation using Cray pointer and malloc (of C)

Fri, 06 Nov 2009 13:07:21 -0800

Halo All,

I am FORTRAN user, and encountered forllowing problem.

I am alocating memory for the fortran arrays using cray type pointer and malloc function of C. Here is simple program which describes my usage:

Program MemTest
implicit none

integer*4, parameter ::     Len=4000,Size=8

integer*4     ::    Array1(Size,Len)

integer*4     ::    ii, memalloc

pointer           (Array1Ptr,Array1)

Array1Ptr = memalloc(Size*Len*4)

do ii = 1, Len

Array1(1,ii) = ii*2
Array1(2,ii) = ii*3
Array1(3,ii) = ii*4

end do

stop

end

#include
#include
#include

int *memalloc_(int *length)

{
int *alocptr;

alocptr = (int *) malloc((unsigned) *length);

if (alocptr == 0) {
printf("Unable to allocate --> %d bytes)\n", *length);

}
return(alocptr);
}

Compiling with ifort -- Intel(R) 64, Version 11.1    Build 20090827 Package ID: l_cprof_p_11.1.056.
It works well below and eqal LEN=4000, but does not work further. Any help.. Thank you in advance..

Regards,

PS

Slow Response Time

Fri, 06 Nov 2009 09:08:12 -0800

It is difficult to set records. My issue may of set a record for slow Premier support time. It has taken 188 days to hear back on an issue of Classic VB calling an Intel Fortran .dll. It will run Ok on one computer but not another. In the past, Digital and Compaq would respond in 1 to 5 days.

Using lapack in fortran code

Fri, 06 Nov 2009 09:05:44 -0800

Hello friends,
Im facing a problem when I compile my fortran file (.f90) calling a routine from lapack.
I want to use the routine GETRS to solve linear systems. My exemple .f90 file is described below.

*** file Text1.f90 ***

PROGRAM TEST_IFORT
USE mkl95_lapack
USE mkl95_precision
IMPLICIT NONE

COMPLEX(8) :: Atild(2,2), Btild (2)
INTEGER :: ipiv(2)

Atild = reshape( (/ 1,1,1,-1 /) , (/2,2/) )
Btild = (/ 3,1 /)

print*, Atild(1,1),Atild(1,2)
print*, Atild(2,1),Atild(2,2)
print*, "--"
print*, Btild

CALL GETRS( Atild, ipiv, Btild )

print*,Btild

END PROGRAM
**********************

When I use the command "ifort Text1.f90" I get the following message:
>ifort Text1.f90
Intel(R) Visual Fortran Compiler Professional for applications running on IA-32,
Version 11.1    Build 20090930 Package ID: w_cprof_p_11.1.048
Copyright (C) 1985-2009 Intel Corporation. All rights reserved.

Text1.f90(2): error #7002: Error in opening the compiled module file. Check INC
LUDE paths.   [MKL95_LAPACK]
USE mkl95_lapack
----^
Text1.f90(3): error #7002: Error in opening the compiled module file. Check INC
LUDE paths.   [MKL95_PRECISION]
USE mkl95_precision
----^
compilation aborted for Text1.f90 (code 1)

>

I dont know what to do since I have used the USE command following the instructions from the reference manual C:/Program Files/Intel/Compiler/11.1/048/Documentation/en_US/mkl/mklman.pdf
I have MS visual studio 2008 and visual fortran 11.1.048 installed on my pc and I wanna use the command line compiler.

Thankyou in advance.

recursive subroutines with intel 10.1.030

Fri, 06 Nov 2009 05:28:29 -0800

I have previously compiled programs using the intel visual fortran 10.1.021 compiler. When upgrading to the 10.1.030 compiler, I discovered a different behaviour when compiling recursive subroutines while using the "Qsave" option. The compiler documentation for both versions claims that "This option saves all variables in static allocation except local variables within a recursive routine and variables declared as AUTOMATIC.".

However, my experience is that the Qsave option using 10.1.030 also saves local variables in recursive subroutines.

Is this an intended feature? Does anyone have experience with this?

OMP Warning: Cannot open message catalog "2060libguide40ui.dll"

Fri, 06 Nov 2009 00:46:04 -0800

A user of my console application has reported that he is getting following warnings on a specific computer:

OMP: Warning #2: Cannot open message catalog "2060\libguide40ui.dll":
OMP: System error #126: The specified module could not be found.
OMP: Info #3: Default messages will be used.

The application is compiled using following options:

/nologo /fpp /fixed /extend_source:132 /Qopenmp /fpscomp:general /warn:declarations /warn:unused /assume:byterecl /module:"Release\\" /object:"Release\\" /libs:static /threads /c /align:all /heap-arrays

And linked using following options:

/OUT:"Release\MyApp.exe" /NOLOGO /DELAYLOAD:"Cstuff.dll" /MANIFEST /MANIFESTFILE:"...\MyApp.exe.intermediate.manifest" /SUBSYSTEM:CONSOLE /STACK:100000000 /IMPLIB:"...\MyApp.lib" delayimp.lib libguide.lib Cstuff.lib

The question is what I can do in my application so that the user does not get the above mentioned warnings.

Does the configuration of his computer matter? Or is it any compiler option which my application is missing? I found an archived thread discussing the compiler option /Qopenmp-lib:compat; should I try using it? I can also try recompiling my application using the latest version of the compiler (11.1.051).

Finally, do these warnings affect the parallelization?

PS: Cstuff.dll and Cstuff.lib were created in Visual Studio 2008 using following compiler options:

/O2 /Oi /GL /D "WIN32" /FD /EHa /MD /Gy /Yu"stdafx.h" /Fp"Release\Cstuff.pch" /Fo"Release\\" /Fd"Release\vc90.pdb" /W3 /nologo /c /Zi /TP /errorReport:prompt /clr

and linked using

/OUT:"...\Cstuff.dll" /INCREMENTAL:NO /NOLOGO /DLL /MANIFEST /MANIFESTFILE:"Release\Cstuff.dll.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEF:".\Cstuff.def" /DEBUG /PDB:"...\Release\Cstuff.pdb" /SUBSYSTEM:WINDOWS /OPT:REF /OPT:ICF /LTCG /DYNAMICBASE /NXCOMPAT /MACHINE:X86 /ERRORREPORT:PROMPT

Anyway, I think and hope the DLL created by VS does not play any role in this problem.