Problem reading from console w Intel 9.1 Fortran

[hannahse]

I have a fortran program that is several years old but is updated a few times per year. I use a perl script to compile it on three platforms with 3 different compilers. I have a compaq compiler for W2K, Intel 8.1 for WXP and now I have Intel 9.1 for WXP64. This last version is the first one to give me a problem with reading input from the console. I'm hoping its just some compiler flag.

The program writes out a prompt using a formatted write statement and then attempts to read a user input from keyboard using a formatted read. The problem is that the program does not seem to take the carriage return as the end of the input. I seem to have to hit ctrl c. A subsequent write statement verifies that the input was otherwise read correctly.

The program was originally asking for character input, but I tried a variation trying to enter an integer and both versions have this problem.

FMT2 = '(A)'

1000 WRITE(*, FMT1 ) PROMPT

READ( *, FMT2, ERR=1000 ) STRING

Any help would be greatly appreciated.

[Steven_L_Intel1]

What you have described here seems rather mundane - there's probably more to it. That said, 9.1 is, um, rather old by this point. I have a vague memory of some issues with list-directed input fixed a long time ago. Have you tried 11.1?

[hannahse]

I work for a rather large company and they tend to lag behind. I have to use the same compiler issued to many many users because my program gets compiled into another program on a daily basis. Rumor has it, we will switch to a later version of the compiler on machines distributed later this year. But for now I have to support people with all three of the older compilers. And I will probably have to continue supporting a 9.1 version as long as users in the field still have that compiler.

Unless there is a compiler flag issue, I can't see why version 9.1 should behave differently than 8.1.

[Steven_L_Intel1]

If you can post or attach a small but complete program that shows the problem, and a description of the input, I'll be glad to check it out. But if it was a bug fixed in a later version, that's what I'd have to tell you.

[hannahse]

I wrote a six line program and compiled it from the command line with ifort but the resulting exexutable did not exhibit the observed problem. So I dug up the compiling flags from my make script and compiled with those flags. The problem returned. By trial and error, I found that the libs:dll flag seemed to be the problem. Without that flag, my small program works properly.

But when I compile my real program without that flag, I get a host of errors related to MSVCRT.LIB and various functions already defined.

If I try to fix that with nodefaultlib:MSVCRT, I get other errors regarding one of our own libraries with unresolved external symbols. I have to use that internal library but have no control over how it is compiled and I am not familiar enough with all this library/dll stuff to know how to resolve all these things except with my original libs:dll.

Any thoughts on how to resolve these issues?

[Steven_L_Intel1]

Your real program is apparently a mix of Fortran and C or C++. It is important to use the same type of library (static vs. dll, debug vs. non-debig) for both languages. This is why you get linking errors when you remove the /libs:dll because the C/C++ code was built with /MD (same as /libs:dll).

Please show me your six-line program and describe the input you provide.

You may have an old copy of the Fortran DLLs on the system - search the system for libifcoremd.dll and see how many copies you have and where they are.

[hannahse]

OK. Its a little more than 6 lines but here it is:

Program Main
INTEGER :: I
WRITE(*, 1) 'This is the first prompt '
READ (*, 2) I
WRITE(*, 3) 'The first value entered was ', I
WRITE(*, 1) 'This is the second prompt '
READ (*, 2) I
WRITE(*, 3) 'The second value entered was ', I
1 Format (1X, A)
2 FORMAT (I3)
3 FORMAT (1X, A, I6)
END
I can't seem to paste with the same formatting. My file is based on /nofree so most of the code starts in col 7.

compiled with
ifort /iface:nomixed_str_len_arg /nologo /Qip /4L132 /nofree /4Na /libs:dll /threads /fpscomp:all /convert:big_endian /traceback /fpe:0 /Od /debug:full /Z7 /check:all console.f90

Here's the result where the program's output after the first prompt occured after I hit ctrl C:

console.exe

This is the first prompt

12345

78

34

22

The first value entered was 123

This is the second prompt

The second value entered was 78

forrtl: severe (28): CLOSE error, unit -4, file "Unknown"

The dll file is found in several places on my system but the which command tells this is the one being used:

which libifcoremd.dll /
c/Program Files (x86)/Intel/Compiler/Fortran/9.1/EM64T/Bin/libifcoremd.dll
This is dated in 2007. There some from 2009 in system folders.

[Steven_L_Intel1]

There should not be any copies of libifcoremd.dll in system folders.

I am confused by your description of running the program. You show four lines of input data, but talk about pressing ^C "after the first prompt". Please explain what you did in more detail. I don't see how this program could accept four lines of input.

[hannahse]

When I ran the program, I entered the first number at the prompt and hit enter. The program should have come back with an output from the write statements and prompted for the second input. However, it did not. It just sat there as if waiting for a buffer flush or something. So I entered a second number and followed with a third and fourth just to demonstrate that the program was not going to respond no matter what I did and to see what would end up being read by the program. So after I entered the last number and nothing happened again, I hit ctrl C. That's when the program responded with output from the write statements, etc.

So no, the program should not have taken 4 numbers and in fact it only read the first 2. But I could have entered as many numbers as I had patience for and the program would not respond until I finally entered ctrl C.

[Steven_L_Intel1]

I can't reproduce this problem with the 9.1 I have on my system. Which exact 9.1 are you using? (9.1.xxx) Can you attach a zip of the EXE you are using?

[hannahse]

Our version appears to be 9.1.039 - according to control panel installed programs. The zip file contains the source, the executable, the manifestand a 1 line script file to do the compilation. I run this from a bash window.

I also found a fortran cfg file that sets the -Qvc8 option.

[Steven_L_Intel1]

The key option you are using is -fpscomp:all There was a bug in some earler versions where if -fpscomp:general was in effect that a list-directed read from the console might hang. It is fixed in current versions and the fix was in the run-time library, so a possibility is that you could keep using the 9.1 compiler and use the 11.1 run-time libraries, which you can install from here.

That said, I still have not been able to reproduce the problem using 9.1, but there might be something tied into your using a bash window.

Do you really need -fpscomp:all?

[hannahse]

I don't honestly know if I need that option or not. Once we find a set of flags that seem to work, we try to change them as little as possible. If I compile with the 11.1 libraries, can my object files be linked with other object files compiled with 9.1 libraries?

I will try compiling the small program without the fpscomp to see if that fixes the problem. I noticed that your 9.1 version was slightly later than mine. We have a site license controlled by the IT department. Should it be difficult for them to update to the latest 9.1 and would it be free?

If I try the 11.1 libraries, what would I have to do to backup my existing libraries in case I need to revert?

[Steven_L_Intel1]

We don't license by version, but by date. If your admins log in to the Intel Registration Center, it will show them the latest version they are eligible to install for a given license.

If you use the redistributable package, it puts the new libraries in a separate location and leaves the 9.1 libraries alone. Note that you need to be linked to the DLL libraries for this to work for you.

[hannahse]

Thanks. I'm sure they know that. I did not.

I was reminded that policy forbids anyone from installing anything except through internal approved sources so I can not install the libraries from your link. With so many computers to support, the IT folks like to keep a tight rein on installed software and "images".

I did recompile without the fpscomp flag and my problem did go away. I also recompiled my real application and it seems to work fine. I don't know how or why that flag got into our flag set but I am not the only one using it. I had thought it might be required in order for the executable to be compatible with some users' hardware but now, as I look at the description, it seems to be needed only if we are using some non-standard fortran features that were available in power station fortran. Although our code is a mixture of old and somewhat current fortran, we do not use nonstandard features so I believe we do not need the fpscomp flag. And if that is the case, I would prefer to get rid of it and keep my software image standard with the rest of the company.

Unless you can advise further regarding the criteria for using or not using the fpscomp flag, I think I have my answer and I thank youfor finding it.

It's too bad that my trial and error method of looking for a problem flag led to the libs:dll before I tried the fpscomp.

[Steven_L_Intel1]

Ok - I think that removing /fpscomp is the better solution for you.