Highly frusterated CDF user

Highly frusterated CDF user

I cannot even get started on IVF, due to the differences from CDF (which are far more drastic than I could have imagined). I am working with code that has been successfully compiled on multiple compilers (PGI, g95, FTN95, CDF, Absoft, HP). Now on IVF for the PC, it can't even get past lines specifying a file open and read the first line (!).

The debugger behavior is particularly grating, as it effectively dumps with a "[code name] has triggered a breakpoint", with no apparent explanation for what the issue is. I'm spending hours fighting the interface, rather than identifying coding issues (which I doubt are there, given previous clean compilation on a half-dozen compilers, including some very persnickety ones). If I try to step into the problem area, it complains about "no source available" and stops. There does not seem to be any particular place where it clearly identifies the problem.

Is there a way to make this thing look more "CDF" interface wise, or documentation helping CDF users adapt quickly to IVF? I used CDF for ten years on complicated production Fortran codes with tens of thousands of lines, and now I can't even read a line in a file with IVF.

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

CDF - Do you mean CVF - Compaq Visual Fortran?

Make sure you are compiling in Debug configuration or you will get the "no source available message".

Finally, are you using the latest IVF (v12). and what Visual Studio?

Earlier versions of some VS options needed to be upgraded with service packs in order to make good debugging env.

Linda

I'm sorry to hear of your problems. I suggest you read "Migrating from Compaq Visual Fortran" for some useful tips.

The issue you are having with the debugger is that the actual error message is being shown in the console window which is probably hiding behind the debugger window. Find the icon for the console window in your taskbar tray and click on it to bring it forward. I will note that Intel Fortran applies more error checking that CVF did and many older applications, that "worked" with other compilers, see errors from Intel Fortran because the other compilers did not look for these errors.

I can understand it is frustrating, but I am sure that if you let us help you over these bumps you will appreciate the new capabilities.

Steve - Intel Developer Support

OK, then explain this. My Fortran coding is this:

====================

CHARACTER( LEN=44 ) :: string
OPEN( UNIT=60, FILE='filename', STATUS='unknown', IOSTAT=ios )
READ ( 60,'(A)' ) string

====================

The input file has a single line with a carriage return:

A string

The result is an EOF during read, even though ios returns 0. WTF?! Please tell me what is wrong with this.

If I can't do this after 20 years of Fortran programming, then I give up. I should buy an old laptop and go back to the simple, reliable CDF. At least it knew what "READ" was.

integer :: ios? carriage return at beginning of file? Also, more likely, debug looks in project directory for the file, not where exe is,and this gives me the same error and ios=0.

It's the same run-time code as CVF. I tried the code you posted with a one-line text file and got no error. Can you show an actual source and attach the input file too? I suspect something else is going on that you did not show here.

Steve - Intel Developer Support

It was there. I forgot to type it in the posting.

Your program attempts to open a file with the name 'filename'. Do you have a file whose name is

filename

in the run directory? Or did you intend to open a different file?

Dear Frustrated:

I spent exaclty 35 seconds in IVF and fixed your code. This code is not perfect, but it works.

You need a filename, you need a program name. You need to put something into file.dat.

Can I also say that the people who mostly populate this excellent site are well meaning people of considerable skills. Most do it for nothing, except Steve and he is a real expert. I find that if I ask a simple polite question I get a better response.Can I suggest you get a good Fortran book.

I have been able to get programs running that date back to 1967 without a great deal of effort in IVF, it can be a bit strange, but so is my ex mother in law.

Have a nice weekend

JMN

Program mine
    
    CHARACTER( LEN=44 ) ::  string
    string = "file.dat"
    OPEN( UNIT=60, FILE=string, STATUS='unknown', IOSTAT=ios )
    READ ( 60,'(A)' ) string
    write(*,*) string

end program

Recently I have been migrating a large code base from Microsoft Fortran to Intel. The Microsoft Fortran became Dec became Compaq, and our codebase actually stems from PDP days. It includes mnay examples of what would be considered poor coding technique today

It has not always been easy going , but it IS possible, especially with some help from the kind people on this forum.

There are some compiler settings which I have found to be needed to make our code work. In particular:

Preprocessor:
Preprocess Source File (/fpp)

Compatibility:
Eanble F77 Run-time compatibility (/f77rtl)
Use F77 Integer Constants (/intconstant)
Use Powerstation IO Foamt (/fpscomp:ioformat)
Use Other Powersation Runtime behaviour (/fpscomp:general)

Diagnostics:
Warn for Undeclared symbols (/warn:declarations)
Check Routine Innterfaces (/warn:interfaces)

Data
Deafult Integer kind (/integer_size:16)
Local Variable Storage (/Qsave)
Initaiulise local saved vars to Zero (/Qzero)

Floating Point
Floating point exception handling Underfow gives 0.0 (/fpe:1)

External Procedures
Calling convention: CVF (/iface:CVF)
Name Case Interpretation Uppercase (/names:uppercase)

Runtime
Generate Traceback information (/traceback)
Check for Null pointers (/check:pointer)
Check Array and String Bounds (/check:bounds)
Check Unitialized Variables (/check:uninit)

I hope maybe this will help.

Just my $0.02

Jim

Leave a Comment

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