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

Weirdness in the Land

JohnNichols
Valued Contributor III
393 Views
Dear Steve:

A few weeks ago I put a simple Windows Fortran program that runs nicely, but one complaint was the variables that were declared but never used.

So I went back and turned on the two warn about variables, ie not declared and not used. I got a couple of interesting ones, thought they would brighten up your day.

lparam = not used, so I put in a dummy lparam1 and simply used the assign statement. Fools the compiler. Not neat but humourous.

I then started to get a complaint about a block jump with the following code, which is shown fixed here, but I had put 9997 at the end of the subroutine set an error message and then returned. The warning message was annoying so I did the following quick fix.

Any better ideas on hitting the end of a file of unknown length and stopping neatly.

Thanks

JMN

[bash]Do 5210 I=1, FFTSize Read(FCSV,*, IOSTAT=ERRC, END=9997)DX(I),FX(I) !write(*,*)IOSTAT goto 9996 9997 continue sRet1 = SetStatusBar(ihwndstatus, IDS_STRING115, 1) return 9996 Continue If (ERRC .eq. 0) then Time(I) =0.0 CX3 = "Fixed" WRITE(FOUT,5231)I,TIME(I),DX(I),FX(I),CX3 ENDIF 5210 END Do [/bash]
0 Kudos
6 Replies
Paul_Curtis
Valued Contributor I
393 Views
lparam = not used, so I put in a dummy lparam1 and simply used the assign statement. Fools the compiler. Not neat but humourous.

I observed this issue, particularly when the only reference is POINTER(lParam, sometype), and called it to Intel's attention a long time ago, I think back with IVF10, and it got registered on the bug list. Steve has posted here that this is now supposed to be fixed, also a long time ago. My codes still contain a few unused = lParam statements to stop these warning messages (and, btw, you want to do this by transferring the value of lParam to some variable, not the other way around since in fact lParam is very likely to contain important message information).

If you're reading record-structured files, as your example indicates, you might try getting the file's total size and dividing by the record length (including the crlf record terminators), which will tell you exactly how many records are present before the start of your read loop. It would also be hugely more efficient to read the entire file in one operation into a buffer, and then work your calculation loop from the buffer. If you were to use the Windows file-handling API routines, you could simply dump the file content directly into the DX() and FX() memory: one step, job done.
0 Kudos
IanH
Honored Contributor II
393 Views
The distinct integer error code that corresponds to END is available in the intrinsic module ISO_FORTRAN_ENV. So you could do something like:

[fortran]USE, INTRINSIC :: ISO_FORTRAN_ENV, ONLY: IOSTAT_END ... READ (FCSV, *, IOSTAT=ERRC) DX(I), FX(I) IF (ERRC == IOSTAT_END) THEN ! Test for end of file sRet1 = SetStatusBar(ihwndStatus, IDS_SOMETHINGDESCRIPTIVE, 1) RETURN END IF ... [/fortran]
Don't forget that ERRC might be some other non-zero value in the event of error or an end of record condition (IOSTAT_EOR) - you don't want to end up in an endless loop.

I use "IF (lparam /= 0) CONTINUE" to avoid "not-used" warnings.
0 Kudos
JohnNichols
Valued Contributor III
393 Views
Dear Paul and Ian:

Thanks for the reply, I will amend my code, should have thought of that method. I blame4 hours of driving to and from Houston listening to Curious George for my relative dumbness this afternoon. I just did the hair for a Rapunzel doll. Multipurpose father.

Speed: I was thinking about this point this afternoon. When I was writing my OLAF code as shown in the sample FL and LINK module yesterday I was using a COMPAQ Portable with an 8086 processor and a 20 MB hard drive with MSDOS and MS Fortran 3.3. It took 45 minutes to compile and link the code so I could make a cup of tea and drink it whilst I waited. Now it links and runs in less than a minute. Moore's Law is so awesomely awful for coders. No breaks. As I have to have all of this finished in three weeks, I will stick with the tried and true. I actually prefer to do an hour of writing and then use a slow compiler instead of checking every other line.

Steve: Please arrange for Intel to bring back the 8086, DOS and MS Fortran.

Regards

JMN

Just took the hair stuff out with my pocketknife.

0 Kudos
Steven_L_Intel1
Employee
393 Views
Want us to resurrect paper tape and plugboards too?
0 Kudos
JohnNichols
Valued Contributor III
393 Views
Dear Steve:

Send street address and I will send t_shirt

"bend the punch cards fool the computer" t shirt

JMN
0 Kudos
Les_Neilson
Valued Contributor II
393 Views
After graduation,at my new jobinthe computer centre of a UK national corporation I was given a box of cards and told to feed them into the card reader. I had never seen a box of cards before. Paper tape yes, cards no. I took afist fullof cards - from the back of the box - and put them in, upside down. Then I took the next buch from the back ...
Anotherjob I was given was to go through a stack of paper output.I wastold to findany "diagnostics" and although I searched through that pile of paper for 20 minutes or moreI couldn't find one diagnostic.

Fortunately I was spared being sent to the hardware store to get a file for a disk and other such "in" jokes.

Somehow I survived and 40 years later am still in the computer industry.

Can I haveone of yourt-shirts please?

Les
0 Kudos
Reply