- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We have discovered an error which only occurs in optimised (-O2) code. The following example illustrates the problem. Note that this is cut down version of the full production code just to illustrate the problem
MODULE mod1 IMPLICIT NONE TYPE neuts_type INTEGER, POINTER :: no_total=>null() INTEGER, POINTER :: no_prompt=>null() END TYPE neuts_type TYPE (neuts_type), SAVE :: neuts CONTAINS SUBROUTINE cp_file1(neuts_out) TYPE(neuts_type), INTENT(INOUT) :: neuts_out INTEGER, TARGET, SAVE :: total_neuts=0 CALL total() total_neuts = neuts_out%no_total neuts_out%no_prompt => total_neuts total_neuts = neuts_out%no_prompt neuts_out%no_total => total_neuts CONTAINS SUBROUTINE total() INTEGER, TARGET, SAVE :: no_neutrons=0 REAL, TARGET, SAVE :: nubar=0.0 no_neutrons = 4 neuts_out%no_total => no_neutrons END SUBROUTINE total END SUBROUTINE cp_file1 END MODULE mod1 PROGRAM abc USE mod1 IMPLICIT NONE CALL cp_file1(neuts) PRINT *,neuts%no_total END PROGRAM abc
This code should produce the answer neuts%no_total=4, but if I build this with -O2 using the 2016 version of the ifort compiler it produces the answer neuts%no_total=0. If I build with -O0 it produces the correct answer, so the issue only occurs with optimised code. I have also tried using gfortran, NAG fortran and the 2017 version of ifort and the results are correct in all cases, so only the 2016 compiler demonstrates the issue. Unfortunately 2016 is our current release version as we need to support RHEL5 users.
The issue appears to be related to the assignments and pointer associations after the call to total(). I realise that these lines appear confusing and redundant, but that is because this is a cut down version of something which is more complicated in the production code. The error has been fixed in the production code by some minor code changes, but what I really want to understand is why we are seeing this error in the first place. Is this caused by a bug in the compiler or is there something wrong with the Fortran? Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You have provided fairly solid evidence of a compiler bug, and also that the bug is not present in newer versions (it seems ok in version 19 as well.)
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You have provided fairly solid evidence of a compiler bug, and also that the bug is not present in newer versions (it seems ok in version 19 as well.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yep, indeed, if I do a print statement in the cp_file1 (forcing a side-effect), also ifort v16 produces the correct result. So indeed an optimization bug.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page