W_Fc_PC_8.1.028 problem

W_Fc_PC_8.1.028 problem

I tried to rebuild and every source file( even tiny ones)I try generates an abort with code 1, which according to the log in an internal compiler error. SInce it's happening with every file, perhaps I've gotten some systemic problem or setting changed, since others aren't having trouble. Any suggestions?

Even this one (compile invoked by right click on file):



23 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

This not a complete compilable source - the include file is missing and appears to be required.

Please submit all reports of possible compiler problems to Intel Premier Support, and include all necessary files to reproduce the problem.

Steve - Intel Developer Support

Well, no, it's not, but the same thing happens with

Subroutine test

Works if I start a new project from scratch, though, so I'll try the whole thing that way too.

Error message in log was

fortcom: Fatal: There has been an internal compiler error (C0000005).

if that helps

Message Edited by nvaneck@comcast.net on 02-28-2005 10:24 AM

I would suggest uninstalling and reinstalling - I have used that version on many programs already and haven't seen an issue.

Steve - Intel Developer Support

Thanks, Steve; tried it but didn't work. I rebuilt the project from scratch and everything now compiles, so perhaps somthing got corrupted in the project file.

But now it can't find _APPENDMENUQQ and _DELETEMENUQQ when it tries to link. Any suggestiion as to why?

I've seen a report of that and am looking into it. Do you have the appropriate USE statement?

Steve - Intel Developer Support

Yup, these three, actually. Note this worked in the earlier releases--no changes in code since last July.


Do you have any non printable characters in your code that could confuse the compiler?

Nope; that's not it.....

I tried to install W_Fc_PC_8.1.028 today, but had similar problems. I'm unable to start the programs after compiling them. I get an error saying either a Server Exception occured or just crahes.
I had to remove it. Strange thing I'm waiting for the next update...

Did you do a Build..Rebuild? I am not seeing similar complaints come in to us at Premier Support.

Steve - Intel Developer Support

I can reproduce the APPENDMENUQQ/MODIFYMENUQQ problem - I am still investigating to see what the particular issue is. It doesn't show up all the time...

Steve - Intel Developer Support

Ok, here's the scoop on the linking errors.

The various QuickWin routines such as APPENDMENUQQ are defined in module ifqwin with ATTRIBUTES DEFAULT,C. DEFAULT means "do not apply any command line switches that change naming or calling conventions", then C means to apply the C conventions (lowercase name and pass by value.)

The DEFAULT attribute really should never have been necessary to create, as the specification in the interface should override switches, but that's not how it was implemented eight years ago (!) so we had to invent a mechanism to override that - hence DEFAULT.

A bug was introduced into 8.1.028 where if /names:uppercase was specified on the command line, the routine name was upcased even in the presence of DEFAULT. We'll fix that.

"But wait," you say, "I didn't specify /names:uppercase!". For reasons not entirely clear to me, the IDE is forcing this option on the generated command line unless you change it. The default is to upcase names, so this really shouldn't make a difference, but the correct behavior would be to omit the switch. I've asked the IDE people to look into why this is forced on. Furthermore, it's harder to turn off than it looks. Here's how.

Close the solution. Open the .vfproj file in Notepad and remove any occurrences of 'ExternalNameInterpretation="uppercase"' It may or may not be there. Close the .vfproj file. Now double-click on the .vfproj file. This will open the project, but not your original solution. From the File menu, select Close Solution. It will prompt you for a .sln file to write to - select your original .sln file and click OK.

Now open the solution, right click on the project, select Properties, Fortran, Command Line. Verify that /names:uppercase does not appear. Rebuild.

Sorry for the inconvenience.

Steve - Intel Developer Support

Steve, your explanation seems clear, but for some reason I can't get it to work. I find the uppercase switch twice in the proj file, but even after eliminating it per directions, It doesn't want to go away.. After saving it and double clicking, I still get the solution ( containing only the one project) loaded and the project switch set with uppercase--even if I rename the original solution to something else to prevent confusion. I didn't try to recompile or link, though. Very mysterious; must be doing something wrong in some way.

I wonder if the following problem is related?:

I use a tweaked version of iflogm.

If I build thisversion of iflogm with /iface:default, I will get an unresolved external for the function DlgIssueError (interfaced in iflogm) when a project is linked against this library.
If I build iflogm with /iface:cvf there is no problem:

DlgIssueError is the only function interfaced in iflogm with the C attribute


Walter, I would need more information, such as what name the linker is looking for. I would recommend submitting a support request and attaching all the files needed to reproduce the problem. You may want to first check to see if the above advice works for you.

Steve - Intel Developer Support

This seems to have caught me with one of my external libraries (written in C/C++). I snooped their file and it looks like their routines are all lower case(?)

Caused unresolved external references?. Weird because another library is also in C/C++ and not causing unresolved external references?

Trying "lowercase" now.



I could get around the problem with DlgIssueError in iflogm.f90 by compiling with /iface:CVF, however the library routines then don't function correctly anymore. So my only option is to comment out the call to DlgIssueError (from DlgBadStyle) and hope that it won't be needed. I can then compile with /iface:default and everything functions OK.

I suppose that this has to do with the extra functionality of the DEFAULT attribute not functioning properly, but the trick of deleting ExternalNameInterpretation="uppercase" didn't help


It isn't enough to just remove the option from the .vfproj file or check to see that it is not there. You also have to open the .vfproj file and then save the solution.

Steve - Intel Developer Support

Double-clicking on the .vfproj fileopened theoriginal solution (in contrast to what you described). I then saved the original solution, but the effect was not what I hoped for. 'ExternalNameInterpretation="uppercase"' does not reoccur in the .vfproj file.


What was the effect? You haven't said what the current problem is in detail.

I suggest that you submit an example to Premier Support so that we may investigate.

Steve - Intel Developer Support

Same with me; doubleclicking on vproj opened solution, which I saved, but still had the same problem.

In VS.NET, right click on the project, select Properties. Then select Fortran..Command Line. Does /names:uppercase appear under "All options"?

Steve - Intel Developer Support

Leave a Comment

Please sign in to add a comment. Not a member? Join today