topic Compilation aborted in Intel® Fortran Compiler

Compilation aborted

pedrohcgs — Tue, 27 Sep 2011 18:20:44 GMT

BuildLog.htmbp.f

Hello all,

I am trying to run the attached code, which is working with my professor computer.

Here, whenever I try, it appears compilation aborted.

Please, any kind of help is really appreciated.

I am using Visual Studio 2008, with IVF 12.

Best

Compilation aborted

mecej4 — Tue, 27 Sep 2011 18:50:46 GMT

IVF 12 is not 100 percent compatible with versions of IMSL other than the one recently released by Intel for that compiler. In particular, some modules supplied by VNI that were compiled using IVF 11.x are known to cause IVF 12 to crash.

Which version of IMSL do you have?

Compilation aborted

pedrohcgs — Tue, 27 Sep 2011 18:57:10 GMT

I have theIMSL v7.0 x86-x64.

So, this can be the problem?

Do we have any solution?

Compilation aborted

Steven_L_Intel1 — Tue, 27 Sep 2011 19:57:54 GMT

I think I understand the problem. With the combination of IMSL 6 and Intel Fortran 11.1 that we sold, there was a bad module LINEAR_OPERATORS that triggered an internal compiler error. I can reproduce the compiler error using the version 12.1 compiler but the old IMSL module. When I use the newer LINEAR_OPERATORS that we rebuilt for Composer XE 2011, no error.

My guess is that Rogue Wave is using the same old pre-release compiler they used before to build their modules. You can try the replacement modules provided in this article, but you should ask Rogue Wave to rebuild the modules with a non-beta compiler.

Compilation aborted

pedrohcgs — Tue, 27 Sep 2011 21:11:13 GMT

Thanks a lot for the information.

Nonetheless, when I follow the steps of the article you posted, it appeared another error:

Error 1 error #8110: The module file for compiler-generated interface was generated for a different platform or by an incompatible compiler or compiler release. It cannot be read. Use -gen-interfaces option. [MP_TYPES] C:\Users\Pedro\Desktop\Fortran\bp.f 265

I don't know how to deal with that also.

Now, how should I proceed? Any tip?

Thanks a lot

Compilation aborted

pedrohcgs — Tue, 27 Sep 2011 21:22:48 GMT

Also, I was supposed to unzip the file in the I64 folder, but I was using the I32 files.

Compilation aborted

Steven_L_Intel1 — Wed, 28 Sep 2011 00:33:54 GMT

The article was specific to x64, so you should have unzipped into the Intel64 folder. You said you were building for Intel 64.

If you are building for IA-32, then I recommend you contact Rogue Wave and ask them for modules recompiled with a non-beta compiler.

Compilation aborted

pedrohcgs — Wed, 28 Sep 2011 07:32:26 GMT

Hey Steve,

Thanks a lot for all the info. I would like to bother you just a bit more.

I am using a x64 computer, but the program was running with the Win32 debug. Nonetheless, I changed to run it with x64, and as I mention, it appears the error, which I am attaching.

Nonetheless, I have already sent an email toRogue Wave.

Thanks a lot for all the support.

Compilation aborted

mecej4 — Wed, 28 Sep 2011 11:28:15 GMT

I think that you have corrupted your IMSL installation. Note that 32-bit and 64-bit module files are not interchangeable.

You unzipped the 64-bit modules into the 32-bit include directory, causing the 64-bit .mod files to overwrite the 32-bit files which are supposed to be there. Any attempt to build a 32-bit application that needs those.mod files will fail.

Meanwhile, your 64-bit IMSL include directory still contains the defective .mod files that Steve wanted you to replace. Therefore, your original problem with 64-bit builds still remains.

Compilation aborted

pedrohcgs — Wed, 28 Sep 2011 12:45:53 GMT

I just have re-installed the IMSL libraries, and then just copied the module into the 64-bit folder.

I still have the same problem.

I contacted Rogue Wave and they say that I should use the IVC 11.1, but I don't like this kind of answers.

Thanks a lot for all the support.

Compilation aborted

Steven_L_Intel1 — Wed, 28 Sep 2011 14:30:24 GMT

You are not using the IMSL that we have validated for use with the 12.0/12.1 compiler. And you're not using the compiler RogueWave has validated for use with the 7.0 IMSL. I was able to see an error when using the old IMSL modules but not the newer ones.

Do you get this error building a 32-bit application?

Compilation aborted

pedrohcgs — Wed, 28 Sep 2011 14:47:55 GMT

When I tried to build it with Win32, it appear the same kind of error, I guess.

I attach the Buildlog.

Compilation aborted

Steven_L_Intel1 — Wed, 28 Sep 2011 15:33:08 GMT

Please attach the linear_operators.mod file from the IMSL include\dll folder.

Compilation aborted

pedrohcgs — Wed, 28 Sep 2011 15:43:46 GMT

Here it is the file.

Thanks

Compilation aborted

Steven_L_Intel1 — Wed, 28 Sep 2011 15:55:03 GMT

Interesting. I can reproduce the error with the .mod files from the article, but not the ones from our update. Let me see if I can put together a different ZIP for you to try.

Compilation aborted

Steven_L_Intel1 — Wed, 28 Sep 2011 16:15:24 GMT

Ok, try the attached. Unzip into your intel64\dll folder. This is for Intel64 only.

Compilation aborted

pedrohcgs — Wed, 28 Sep 2011 17:23:17 GMT

Now, I have a different type of error.

I attach the log file.

Compilation aborted

Steven_L_Intel1 — Wed, 28 Sep 2011 17:46:22 GMT

Did you edit the source? I don't get that with the bp.f you uploaded before. I tried to redownload to be sure but it seems to have disappeared from our server. Perhaps you can reupload?

Compilation aborted

pedrohcgs — Wed, 28 Sep 2011 17:56:37 GMT

I attach both the bp.f and the buildlog, just in case.

Compilation aborted

Steven_L_Intel1 — Wed, 28 Sep 2011 18:15:17 GMT

Please do a Build > Clean Solution and try again.

When I compile I see this:

bp.f(2895): error #6633: The type of the actual argument differs from the type of the dummy argument. [F1DIM]
call mnbrak(ax,xx,bx,fa,fx,fb,f1dim)
------------------------------------^
bp.f(2896): error #6633: The type of the actual argument differs from the type of the dummy argument. [F1DIM]
fret=brent1(ax,xx,bx,f1dim,TOL,xmin)
---------------------------^

In both of these calls you are passing a function implicitly declared REAL*4 to a routine that expects a REAL*8 function. This is harmless in this case, but I recommend you declare f1dim to be REAL*8 in these routines.