- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
21 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
Which version of IMSL do you have?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have theIMSL v7.0 x86-x64.
So, this can be the problem?
Do we have any solution?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Also, I was supposed to unzip the file in the I64 folder, but I was using the I32 files.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
Do you get this error building a 32-bit application?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Please attach the linear_operators.mod file from the IMSL include\dll folder.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page