Inconsistent Order of Execution
| SimCon Home | fpt Reference Manual Home |
How Can Program Flow be Inconsistent?
When two or more functions are invoked in the same statement the Fortran standard explicitly states that the order of execution is undefined and processor-dependent. We have found that it varies between different compilers. One feels that there must have been a good reason for this at the time.
Why Does This Matter?
For at least two reasons:
Finding Inconsistent Flow
The fpt command to report inconsistent flow is:
fpt reports occurrences of ambiguous flow and marks the occurrences in the Fortran code. The end of the report from the climate code WRFV3.6.1 is shown below.
Line: 12289, File: ... /wrf_re-eng/UCAR_clean_build/WRFV3/frame/md_calls.inc IF (multi_files(io_form) .OR. .NOT. (for_out .AND. use_output_servers())) THEN !-------------------------^---------------------------------------------------^ !!! FPT - 3665 Program flow is ambiguous. Functions may be invoked in any order !------------------------------------------------------------------------------ Line: 12293, File: ... /wrf_re-eng/UCAR_clean_build/WRFV3/frame/md_calls.inc IF (multi_files(io_form) .OR. wrf_dm_on_monitor()) THEN !-------------------------------^-------------------------------^-------------- !!! FPT - 3665 Program flow is ambiguous. Functions may be invoked in any order !------------------------------------------------------------------------------ Line: 12336, File: ... /wrf_re-eng/UCAR_clean_build/WRFV3/frame/md_calls.inc IF (multi_files(io_form) .OR. wrf_dm_on_monitor()) THEN !-------------------------------^-------------------------------^-------------- !!! FPT - 3665 Program flow is ambiguous. Functions may be invoked in any order !------------------------------------------------------------------------------ Line: 12372, File: ... /wrf_re-eng/UCAR_clean_build/WRFV3/frame/md_calls.inc IF (multi_files(io_form) .OR. wrf_dm_on_monitor()) THEN !-------------------------------^-------------------------------^-------------- !!! FPT - 3665 Program flow is ambiguous. Functions may be invoked in any order !------------------------------------------------------------------------------ ------------------------------------------------------------------------------- Number of statements with ambiguous flow: 440
Correcting Ambiguous Flow
fpt can correct ambiguous flow automatically. The command is:
fpt inserts new statements to capture the results of the second and all subsequent function invocations in a statement to temporary variables. Declarations of these variables are inserted with the same type and kind as the functions. The ambiguous statement is re-programmed, replacing the function invocations with the temporary variables.
The code shown below occurs in the climate and weather code WRFV3.3.1.
! Limit the increase of dtInterval to the specified input limit num = NINT( max_increase_factor * precision ) den = precision tmpTimeInterval = last_dtInterval * num / den if ( (domain_get_current_time ( grid ) .ne. domain_get_start_time ( grid )) & .and. (dtInterval .gt. tmpTimeInterval ) ) then dtInterval = tmpTimeInterval endif
The order of evaluation of domain_get_current_time ( grid ) and domain_get_start_time ( grid ) is ambiguous.
The code is re-programmed as shown below:
! ! Limit the increase of dtInterval to the specified input limit ! num = NINT(max_increase_factor*precision) den = precision tmptimeinterval = last_dtinterval*num/den domain_get_start_time_return = domain_get_start_time(grid) IF ((domain_get_current_time(grid) .NE. domain_get_start_time_return) & !---------------------------------------------------------------------^ !!! FPT - 3669 Ambiguous program flow has been resolved !---------------------------------------------------------------------- .AND. (dtinterval .GT. tmptimeinterval)) THEN dtinterval = tmptimeinterval ENDIF
Copyright ©1995 to 2024 Software Validation Ltd. All rights reserved.