Software Archive
Read-only legacy content
Announcements
FPGA community forums and blogs on community.intel.com are migrating to the new Altera Community and are read-only. For urgent support needs during this transition, please visit the FPGA Design Resources page or contact an Altera Authorized Distributor.
17060 Discussions

Fatal internal read error

Intel_C_Intel
Employee
469 Views
I've inherited a program that was compiled successfully using a previous version of DVF (version unknown but workspace files were provided). However, the program will not run using the example input file provided with the program and executable. The input file does work with the provided executable. A fatal error occurs when the program attempts an internal read statement:

read(LINE(37:),*,ERR=200) dummy,dlxtmp,dummy !begin at col 37

The line in the input file that causes the error is:

Type RM Length L Ch R = 3 ,20148.80,,,

The error obviously has something to do with reading null values...col 37 begins after "2048.80,"

Why did the program continue to 200 when null values were encountered using an earlier compiler and now results in a fatal error?...and how can I fix this easily...aside from removing null values from the input file before executing the program.

Thanks, Curtis
0 Kudos
2 Replies
Steven_L_Intel1
Employee
469 Views
Send an example that reproduces the problem to us at vf-support@compaq.com, and we'll take a look. Please pack all the files in a ZIP file and attach that to your message, along with a problem description.

Steve
0 Kudos
Steven_L_Intel1
Employee
469 Views
You should have an answer for this from vf-support by now - but for the benefit or others, the answer is to read the following excerpt from the CVF 6.5 release notes:

In order to conform with clarified wording in the Fortran standard, the compiler has been changed so that when a READ statement encounters an end-of-file condition, and there is no END= specifier but there is an ERR= specifier, the ERR= branch is NOT taken. Similarly, if an end-of-record condition occurs but there is no EOR= specifier, an ERR= branch is not taken.

A further behavior change, to conform with the standard, has been implemented. If an EOF (or EOR) condition occurs and there is not an IOSTAT= or END= (or EOR= in the case of EOR) specifier, the program is terminated with an error message.

Steve
0 Kudos
Reply