Errors due to porting from CVF6.6 to IVF8.0

[jimwon]

I have been porting my DLL apps from CVF 6.6 to IVF 8.0and followed the instructions by Steve L. However my compilation with IVF 8.0failedwith2 Internal Compiler Errors out of 3 DLL projects. I hope I could get answers to my simple questions belowbefore I submit any issue reports.

1) Will the source code I submit to Intel Premier Support end up in the public domain?

2) Is there any FAQ aboutporting from CVF 6.6 to IVF 8.0?

3) I use stdcall calling convention very often like this !DEC$ ATTRIBUTES STDCALL, DLLEXPORT ::MatrixVector. Will this stdcall cause any problem?

4) I could not find any IVF online help from VS.NET 2002.

Thank you.

Jim

[TimP]

1) the code you submit is not visible to anyone, except those specifically working on your problem. Definitely treated as the customer's "IP," unless possibly there is a request to put it in the test suites.

2) only the publication which Steve posted on this forum a few days ago

3) stdcall support is only there for compatibility with CVF; I don't think you gave enough information to know how urgent it is for you to change. You will need to watch the compiler flags.

4) the help menus are in the .pdf and .html files accessible from Start>Programs>Intel Software Dev

[Steven_L_Intel1]

Help is also available from the Help menu in Visual Studio, but it's a separate menu item and not combined with the VS.NET help.

As Tim said, all submissions are considered private and are not disclosed to anyone who is not working on your problem. Access to support cases is limited to specific support engineers per product.

[Peter_Priestley]

I don't see anything aboutIVF help on my Visual Studio.Net 2003 Help menu.? Even with a Fortran project open. IVF build 047.

Peter.

[Steven_L_Intel1]

Hmm - my mistake. I thought it was there. Sorry. Use the shortcut in the Start menu.

[g_f_thomas]

Of course, IVF Help is NOT integrated into VS.NET. This isn't due to some Microsoft conspiracy it's just an inadequacy in the Intel product.

Ciao,
Gerry T.

[Steven_L_Intel1]

At the time we were developing the product, we found that there were problems with the MS implementation that we didn't know how to work around. Now we have some more information and are looking into such integration for a future version. We know it's a sore point with users, understandably.

[jimwon]

Thank you for your responses.

Good news! My Internal Compiler Errors are all gone after I reinstalled VS.NET 2002 and IVF8.0.047. I successfully ported my DLL projects from CVF 6.6 to IVF8.

My new question is that "Do I have to change stdcall calling convention intoC calling convention?" My Fortran DLL's are called by Delphi main program. But there is no C calling convention in Delphi. Instead, there is a cdecl calling convention which sounds similar to C in IVF.

Thanks.

Jim

[Steven_L_Intel1]

Do you HAVE to change? No. "cdecl" is the same as "C" in Intel Fortran, so you can use that if you wish.

[jimwon]

I successfully compiled my DLL projects, but I got an error message "The procedure entry point StartSim could not be located in the dynamic link lib MyDLL1.dll" when I started my Delphi main program. Is this a problem of calling convention? I used stdcall in both IVF8 and Delphi code. Thanks.

[Steven_L_Intel1]

This could be a bug I recently reported. In CVF, the compiler would generate two global names for each routine, one that had the normal STDCALL decoration of @n, and one without. The latter was used when you passed a routine as an argument. IVF does this too if you are using STDCALL.

If you DLLEXPORT the routine, CVF exported both of the global names, but IVF currently exports only the @n version. A workaround is to add an ALIAS attribute to the Fortran routine to specify the name you want.

[jimwon]

The problem was solved by changing the calling convention from stdcall to c in IVF. At the same time, I changed the calling convention from stdcall to cdecl in my Borland Delphi main program.

It is unfortunate that my IVF8 DLL isabout 10% slower than my CVF6.6 counterpart. My laptop has an Intel Pentium3 Mobile CPU, so optimization for Pentium 4 is not applicable.

Any recommendation of compiler/linker properties for a fast executable is appreciated. Thanks.

[Steven_L_Intel1]

Be sure you're not using a Debug configuration. The default Release options should be good.

[TimP]

8.0 still hasa P-III specific optimization, /QxK. I can't tell from your previous posts whether you're interested in that, and why or why not. Assuming you have a purchased license, you're also entitled to try 7.1, which may optimize better for P-III.