Questions on IVF 12

[Christ_F_]

Hi Steve,

I am trying to get all my sotftware updated to VS 10 and IVF 12 and I had a couple of questions.
1. Is it possible to get the Help>IVF>Help IVF menu item in VS 10 to only show Intel Fortran help?
2. Can I use dll's that use both CVF and C calling conventions in the same program? There are hundreds of routines involved so recompiling with Assignment statements or generating a def file looks to be a lot of work.
3. Where I have gotten program using libraries to compile and run they are usually followed by a series of error messages about not being able to find the prb file.

As usual, any help appreciated

[Wendy_Doerner__Intel]

Let me take a stab at your questions.

1. Is it possible to get the Help>IVF>Help IVF menu item in VS 10 to only show Intel Fortran help?

: You can configure it to use local help which will allow you to view the Intel documentation, see the instructions below. You can also always view the help from the start menu under the product name.

Visual Studio 2010

You must enable local help mode to view Intel documentation in Microsoft Help Viewer 1.0. This type of documentation displays in your default web browser.

Visual Studio 2010 supports two viewing modes: online and local. In online mode, you can view only documentation available from Microsoft web sites. You cannot view Intel documentation. Only local help mode allows you to view the installed Intel documentation.

To enable local help mode:

1. Start Microsoft Visual Studio 2010.

2. Click Help > Manage Help settings. (The Help Library Manager launches.)

3. Click the Settings link.

4. Select I want to use local help radio button.

5. Click the OK button.

To launch help:

1. From the Help menu, choose View Help. (The documentation should appear in your default web browser.)

2. Intel documentation should appear in the Related Links area.

For the first release of Visual Studio 2010 you must also have at least one document from Microsoft installed to view any local documentation. Click Help in the Help Library Manager for more information.

2. Can I use dll's that use both CVF and C callingconventions in the same program? There are hundreds of routines involved so recompiling with Assignment statements or generating a def file looks to be a lot of work.

You can pick at a file level which convention you want to use by using the CVF default on External Procedueres property page or with the /iface:cvf command-line switch. You will need to make sure you dont use one standard on the call and a different on the callee. More information on CVF and IVF here: http://software.intel.com/en-us/articles/migrating-from-compaq-visual-fortran/

3. Where I have gotten program using libraries to compile and run they are usually followed by a series of error messages about not being able to find the prb file.

: I am not sure what the prb file is. Could it be a third party library or debugging tool? Can I get the full error message?

------

Wendy

Attaching or including files in a post

[Steven_L_Intel1]

What I recommend for the mix of C and CVF conventions is to declare an interface block for the CVF routines and add a directive of this form:

!DEC$ ATTRIBUTES STDCALL,REFERENCE,DECORATE,ALIAS:"ROUTINE"::routine

inside the block. Upcase the routine name in the ALIAS string. I do not recommend use of /iface.

[Christ_F_]

Wendy,

Thanks for your answers.

1. Even with local help selected searching IVF help will produces responses from all links searched which include all Visual Studio help files. I have found it much more useful to set up separate links to IVF and MKL help files as desktop icons to limit the noise in help inquiries.

2. I don't understand your reply with respect using DLLs. I have a main fortran program and several compiled DLL's I want to use. I compiled all the other libraries with the default option but one was pre-compiled with the CVF protocol. Do I have to recompile all the libraries I use to the CVF protocol ? This seems to be the answer since the External Procedures property refers to the project as a whole

3. There was a typo in part three of my question. I meant the pdb, program data bases file, could not be found.

Steve,

Maybe I am missing the point but using an interface block still looks like a massive change for a 400 routine library.

[Steven_L_Intel1]

I agree - writing that many interfaces is a lot of work, but it can pay off in the end. If you must use a library that was built with CVF conventions, then it's not unreasonable to build your project with /iface:cvf. You can use interfaces as needed if you are also calling other routines that use the C convention.

I'll note that while you CAN set the /iface:cvf property on individual sources, that will cause problems when you call that code from elsewhere in your application.

[Wendy_Doerner__Intel]

1. Sounds like you have a working solution for the help files.

2. I think Steve is addressing this through his post.

3. Unable to find pdb files.

Please make sure that you are trying to debug a debug build. This error says the debugger can not find the debug information. Can we get a full error message?

------

Wendy

Attaching or including files in a post

[TimP]

We have seen situations in the past where Microsoft link says .pdb file generated by ifort \Zi is invalid. The consequence is that debugging or VTune source code event association won't be effective for the source files involved. You would have to submit a full reproducer if you want such a situation to be analyzed. At least, you would need to quote exact messages before any useful response could be made here.

[Christ_F_]

Thanks all for your help.

Steve, I just want to get the dll procedure straight. First of all I am working in the IDE. I have a large file filled only with subroutines that I want to make into a dll. There is no way for me to tell which subroutines will be called in use or which subroutines are only called internally. I have hacked a program that looks for the subroutine statement and then adds "!DEC$ ATTRIBUTES DLLEXPORT :: routine_name" after it for each routine.

I choose dll as the project type and set the calling interface I want in the fortran>external procedures tab. I build the dll. When I write an application that uses the dll, I add the .lib file to the project and make sure the .dll file is on the path of the project. Working in the IDE and strictly in fortran do I need to have an import statement in the calling program?

[Steven_L_Intel1]

If you are calling DLL routines and not accessing DLL data, then a DLLIMPORT directive is optional. If you don't have it, there will be an extra instruction or two used for each call, but it will still work.

[Christ_F_]

Steve and Wendy,

1. I put the subroutines into a dll and compiled it. The test program linked to the lib with no problems but run-time errors started showing up that did not show up when I just did a straight compile of the test program and all subroutines without using a dll. I fixed the first few but it looks like a hopeless way to go. There must be something else going on but I could find no compiler switches that would cure it.

2. As for the pdb problem, I wrote the simple program below called tesfortran and set it up in a new solution.

!This is a test program
parameter (n=256)
real a(n,n)

do j = 1, n

do k = 1, n

a(j,k) = abs(j + K)

end do

end do

stop
end

When I set a breakpoint and started debug I got the following in the output window:

'testfortran.exe': Loaded 'C:\updates\Fortran\testfortran\Debug\testfortran.exe', Symbols loaded.
'testfortran.exe': Loaded 'C:\Windows\SysWOW64\ntdll.dll', Cannot find or open the PDB file
'testfortran.exe': Loaded 'C:\Windows\SysWOW64\kernel32.dll', Cannot find or open the PDB file
'testfortran.exe': Loaded 'C:\Windows\SysWOW64\KernelBase.dll', Cannot find or open the PDB file
'testfortran.exe': Loaded 'C:\Windows\SysWOW64\imagehlp.dll', Cannot find or open the PDB file
'testfortran.exe': Loaded 'C:\Windows\SysWOW64\msvcrt.dll', Cannot find or open the PDB file

Any ideas?

christ

[IanH]

(In reference to your point 2...) Those messages are normal. The DLL's listed without symbols are operating system libraries. Unless you are debugging the operating system itself (or some peculiar interaction of your program with the operating system) you normally don't care about the detail inside those libraries and therefore don't need their symbol files.

If you really, really want you can get the (very version specific) symbol files for those system DLL's off a Microsoft web site.

The only DLL's/EXE's you would normally care about in terms of symbols are the DLL's/EXE's that you are creating. The first line in the messages you posted indicates that its symbols were located in this case.

[Steven_L_Intel1]

What "run-time errors" did you see? If it was just the informational messages from the debugger, those indeed can be ignored.

[Christ_F_]

Thanks, that clears up the messages

[Christ_F_]

No, when I ran the test program it caused a break in the execution. I went back and made sure the compier options for the dll were matched to those for the testprogram and turned off all runtime checks. The breakpoint changed and I get further into the test program before it crashes.

[Steven_L_Intel1]

Still looking for details as to how "it crashes". What is the exact and complete text of the error messages?

[Christ_F_]

Finally worked my way through the program and fixed some suspect code - got the test program to run. I don't know why these errors were not a problem when I compiled the subroutnes directly but showed up in the dll. In any event it aseems to work but I will keep checking - I don't like voodoo fixes.


Is there any word on IMSL in VS10 with IVF 12? I bought the studio and compiler licenses anticipating IMSL would be available but it has not appeared?

Have a good new year

cf

[Steven_L_Intel1]

No news on IMSL, but qualification is in progress.