Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Run-time error due to narrow format

Arjen_Markus
Honored Contributor II
1,056 Views

Hello,

I ran into a problem with format strings like "I4.4". Unfortunately I could not reproduce it in a small program and the version of the compiler I am currently using is fairly old, so it may already have been solved. I thought I'd report it anyway.

Here are the circumstances: the program prints a _negative_ number to the screen using a format (edit descriptor) "I4.4". The result is of course "****", but it crashes on the next statement - at least according to the debugger. When I change the format width to 6, all is okay.

Details: Windows 7, Intel Fortran compiler 12.1, 64-bits.

As I already remarked, I could not reproduce it in a small program, so I cannot exclude that it is caused by something else in an unrelated part of the program. But given that the solution was to increase the format width, it seems related directly to the formatting of numbers that do not fit.

Regards,

Arjen

 

0 Kudos
7 Replies
mecej4
Honored Contributor III
1,056 Views

As formats go, Iw.m, with w=m, is guaranteed to give asterisks even when the number being formatted is -1, so why would you use such a format knowing that some of the numbers being printed are negative?

Given that the crash is not reproducible, if there was a bug in IFort 12.1 the same bug may still be present. However, you would have to provide code that causes a crash, even if only occasionally, do anything about the bug.

0 Kudos
Arjen_Markus
Honored Contributor II
1,056 Views

Well, ordinarily the numbers to be displayed (as an indication of the progress of the calculation in question) are positive. I was just fiddling with a case where these numbers are negative when I came across it. It was rather annoying I must say to see the program crash and the debugger not telling me anything useful.

I can actually provide the source code and the input files. It is just a fairly large amount.

 

 

0 Kudos
mecej4
Honored Contributor III
1,056 Views

If the code+data is, say, 20 Mbytes, you can post it as an attachment or provide a URL to a place where you stored it. In these Intel forums there have been a few instances where large attachments were dealt with, and the moderators did not complain. Do note, however, that once you post something as an attachment you cannot delete or replace the file yourself. I do wish the forum managers would let users delete items that are no longer needed.

0 Kudos
Arjen_Markus
Honored Contributor II
1,056 Views

I am trying to reduce the original program to a minimum. Some of the data files it reads (under normal circumstances) are fairly big though, so the 20 MB limit may be too small.

0 Kudos
mecej4
Honored Contributor III
1,056 Views

The 20 MB figure was just a suggestion. Secondly, if you compress your data and sources into a zip archive, the size may be more manageable.

0 Kudos
Arjen_Markus
Honored Contributor II
1,056 Views

Sure, but right now, I am facing the problem that the reduced program, while in the complete directory tree, did what I wanted it to do, namely crash at the write statement, but it does not when I put it in a directory tree with only the relevant bits and pieces, so that somebody else can have a look. Not sure how to proceed with this. Probably best to leave it for the moment and see if I get some bright idea after the holidays.

0 Kudos
Steven_L_Intel1
Employee
1,056 Views

It would at least help if you told us the full text of the error message.

In some old version, though I think well before 12.1, we would always give a run-time error if you got a field overflow in formatted output. Now we do that only if the option /check:output_conversion is in effect. Did you perhaps turn on all check options in the project that fails?

0 Kudos
Reply