DFORMT.LIB

[mbaureis]

Hello.

We have to replace our old CVF-compiler and so I am trying the Intel Parallel Studio XE 2011.

By now I have a problem with my old CVF-code. When I try to link it, I get the error message saying 'cannot open file dformt.lib'

Searching through this forum I find this problem discribed several times, but - I don't understand the solution.
As I have understood the lib is part of CVF, it can't be used under Intel fortran and I have to compile it with the Intel compiler. For that I need the source code of the lib, is that right? Where do I get it from?

Kind regards
Martin

[Steven_L_Intel1]

No - you need the source code of your Fortran code. The problem is that you are linking in an object or library file that was compiled with CVF.

Perhaps all you need to do is a "rebuild" so that you are not using any CVF-created objects? If you are using third-party libraries for which you don't have the sources you will need to contact the supplier and ask for a library compatible with Intel Fortran.

[mbaureis]

Hello Steve,
thanks for your kind answer.

Sorry, but the rebuild didn't really help anything. I have now added a new project to the existing solution, moved all of the files from the old cvf-project to the new project and deleted the cvf-project afterwards. This seemed to help a little bit futher.

Now I have a lot of error messages saying "#7977: The type of the function reference does not match the type of the function definition" or "#6633: The type of the actual argument differs from the type of the dummy argument." Can you help me?

Kind regards
Martin

[TimP]

Quoting mbaureis

Now I have a lot of error messages saying "#7977: The type of the function reference does not match the type of the function definition" or "#6633: The type of the actual argument differs from the type of the dummy argument." Can you help me?

It would be good to look into those, as there are cases where you might have got away in CVF with considering two different types as equivalent; for example, a double precision function treated as implicit real at the calling site.

[Steven_L_Intel1]

As Tim says, these messages indicate serious errors in your program and should be investigated. Such errors can yield wrong results or other failures. CVF did not catch such errors across source files, but Intel Fortran does.

[mbaureis]

Hello Tim, hello Steve,

here is one example:

error #7977: The type of the function reference does not match the type of the function definition. [DMODX]

This is the error-causing line:

WSTART = DMODX(1.0D0, 360.0D0)

Function dmodx starts with:

FUNCTION DMODX (PHI,X)

REAL*8 PHI,X,DMODX

So what's wrong with that?

Kind regards
Martin

PS. Where can I configure to be informed by mail, when there is an answer to my posting?

[Steven_L_Intel1]

You have not shown the whole program, but what is most likely wrong is that DMODX is not declared as REAL*8 in the caller. That means it is implicitly "default real" or REAL*4. The effect of this mismatch is that the value returned by the call will be improperly treated as a REAL*4 and the wrong value used. (It won't just be a less precise value, it will be wrong by a factor of 8).

To be notified by email when there is a reply, view the thread and check the box next to "Subscribed to this Thread".

[RBARBOSA]

Hello there,

Maybe you should use:

REAL*8::WSTART,A,B

...

A = 1.

B = 360.

...

WSTART = DMODX(A, B)

Regards,

R. Barbosa

[mbaureis]

Hello.
Thanks for this idea. No, that doesn't work. I get the same error message as before.

Kind regards
Martin

[mbaureis]

Hello Steve,
thanks for your answer.

What do you mean with "DMODX is not declared as REAL*8 in the caller" ? Please give me an example.

Kind regards
Martin

[mbaureis]

Hello Steve,

I have another question by the way: When I am searching for a function or a subroutine , do I have to toogle through my code with the find & replace-function or is there a way to jump directly to the header of what I am searching for? I know this from C#, it's very comfortable.

Regards
Martin

[IanH]

In the callling scope (in the specification section at the start of the program unit that has the WSTART = DMODX(...) line), make sure you have:

REAL(8) :: DMODX

or other statements that make it clear to the compiler that the DMODX function is of type REAL(8). (REAL(8) is the equivalent standard syntax for REAL*8).

For new code consider using IMPLICIT NONE and module procedures.

When searching for procedure definitions I just use a search term of the procedure name prefixed with the subroutine or function keyword as appropriate.

[mecej4]

The message is quite precise and, if you look at the source code of the caller, you would most likely find that DMODX was not declared and, under implicit type rules, is REAL*4.

However, since you insist, here is an example

[fortran]function dmodx(x,y)
real*8 x,y,dmodx
integer i
if(x.lt.y)then
   dmodx=x
   return
else
   i=int(x/y)
   dmodx=x-i*y
   return
endif
end function dmodx

program tstdmod
  real*8 x,y,z
  real dmodx                ! <<<<==== inconsistent
  x=9d0; y=4d0; z=dmodx(x,y)
  write(*,'(1x,E12.5)')z
end program tstdmod
[/fortran]

Compile this program using IFort with and without the /warn option and observe the differences. Repeat after commenting out the statement marked "inconsistent".

Because of the way that a real function result is passed from a function to a caller on x86/x64, you may find that the code gives correct results despite the bug. You cannot count on this on a different CPU type.

[Steven_L_Intel1]

Quoting mbaureis

Hello Steve,

I have another question by the way: When I am searching for a function or a subroutine , do I have to toogle through my code with the find & replace-function or is there a way to jump directly to the header of what I am searching for? I know this from C#, it's very comfortable.

Not at this time - but we are working on that capability.

[mbaureis]

Hello Ian,
that's it. Thanks a lot.

Now I have the next problem:

error #7938: Character length argument mismatch. ['(F8.4)']

call dlg_setreal(dlg,IDC_DWZ ,'(F8.4)',DWZ)

subroutine dlg_setreal(dlg,idc,fmt,value)
use dflogm
implicit none
character*32 str,fmt
integer ios,idc,i
real*8 value
type (dialog) dlg


What's wrong with F8.4?


Kind regards
Martin

[Steven_L_Intel1]

What is wrong is that '(F8.4)' is 6 characters but you declared the dummy argument as character*32. This is not legal Fortran and can lead to unpredictable results.

In general, character dummy arguments should be declared CHARACTER(*) unless you have a very good reason not to.