Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted

Compiler not warning on poor syntax in DO loop construct

I've been chasing my tail for an hour trying to understand why some variables were not initialised and finally twigged that I had a missing comma in a do loop.

I had;

DO J=NCHAN, 1 -1

   DO STUFF

END DO

I had missed the comma between the end of iteration control and the step. I have IMPLICIT NONE and  I'm compiling with  -c -m64 -g -check all -debug full -traceback -warn all -heap-arrays

Shouldn't this get flagged at compile time? I'm using XE 2017 Update 4.

Cheers

Kim

0 Kudos
6 Replies
Highlighted

>>Shouldn't this get flagged

>>Shouldn't this get flagged at compile time?

DO J=begin, end
DO J=begin, (expression defining end)

are perfectly valid (step is implied as 1)
You have an expression.

Jim Dempsey

0 Kudos
Highlighted

Thanks Jim..

Thanks Jim..

I guess that means my loop went from NCHAN (70 in this case) to 0 with no explicit step and so never ran, which was the symptom I observed.

A hard one to spot.

Cheers

Kim

 

 

0 Kudos
Highlighted
Black Belt

Unless inspection (of the

Unless inspection (of the code that logically precedes the lines that you showed) shows that nchan has a negative value when the DO statement is executed, this is just one more instance of "code does not do what the programmer intended", for which there can be no warning that a compiler could think of issuing. For the more specific case where the compiler can determine at compile time that the start, end, step values are such that the body of the DO loop will not be executed, it could issue a warning, but I know of no compiler that does that.

The expression "1 -1" does not raise more than very mild suspicion, since one can think of several reasons why the programmer wrote that instead of "0".

The Ifort compiler does provide options to spot some instances of code in which variables are used prior to initialization. Once the location of such usage is trapped, one could backtrack to the lines where the programmer expected the initialization to have taken place, put one or more breakpoints in those lines, and re-execute the program in the debugger. One could also use a code profiler for the same purpose.

0 Kudos
Highlighted

Thanks also mecej4

Thanks also mecej4

I misused the term initialise in my initial post as the variables I was setting were in an allocatable array and I had initialised them to 0.0 immediately after allocation and before the loop so they did have a value, just not the one I was expecting. They were not therefore picked up as being used prior to initialisation. 

My "profiler" was to insert write statements, working back through the code until I got to the DO loop and then stare blankly at it for a while before the penny dropped.

Cheers
Kim

0 Kudos
Highlighted
Black Belt

I have long felt that

I have long felt that initializing variables to zero, either in code or by using options such as -zero, unless a good justification exists for zero to be a suitable initial value, is heavy-handed and makes it harder to locate and rectify initialization errors.

0 Kudos
Highlighted

Agreed although I always

Agreed although I always initialise with a dummy before use. In this case the choice of zero was not a problem as I had offset the array by a constant and all elements were identical. I recognised the value as the constant I had added and so found my way back to the DO loop fairly quickly. The time waster was in spotting the missing comma - it was the end of a long day and I'm officially no longer a young bloke so may have been a lot quicker had I tackled it after breakfast.

0 Kudos