Not sure if this is a known issue or not, My code gave different results after updating to update 1 of 2019.
I was wondering if I have accidentally change the code but after hours of debugging I found this happening:
In this part of the code after calling a method of a an object the value of a variable gets corrupted while that variable has got nothing to do with the method call:
subroutine fileCsvWriter_outputVecBySspc(self, darVector, intSspcId, itp) use mdlMultiDict class(fileCsvWriter), intent(in) :: self class(bdfInterpreter), intent(in) :: itp real*8, dimension(:), intent(in) :: darVector integer, intent(in) :: intSspcId character(len=10) strSegKey type(segment) seg type(INTEGER_DICT_DATA) index integer intDOF1, intDOF2, i, j real*8, dimension(itp%database%intSspcConstraintDof) :: darRow darRow = 0.d0 j = 0 do i = 1, size(itp%database%carSspc) if(itp%database%carSspc(i)%intSid==intSspcId) then strSegKey = itp%database%generateSegmentKey(itp%database%carSspc(i)%intG1, itp%database%carSspc(i)%intG2) ! after this line the value of darRow is not 0.d0 anymore. !... end subroutine fileCsvWriter_outputVecBySspc
In the code, itp%database%generateSegmentKey simply returns a char array and should not affect darRow.
It seems changing real*8, dimension(itp%database%intSspcConstraintDof) :: darRow to real*8, dimension(3) :: darRow solves the problem. (I need to investigate more).
Update, I was wondering if
class(bdfInterpreter), intent(in) :: itp
should be actually
type(bdfInterpreter), intent(in) :: itp
would that make any difference?
Did you notice that the code display is broken? Lines have been trimmed after Col. 65 (?). Syntax highlighting is off. There are no line numbers to use in discussing the code.
It is possible for a procedure that is called from the current procedure to overwrite a local array in the caller as a result of exceeding the bounds when writing to an array in the callee. To check this, you would need to look inside itp%database%generateSegmentKey().
I don't expect that anything can be done without a complete reproducer -- can you provide one?
I suspect that the error is attributable to bugs in the code rather than to the compiler version number.
When assumed size arguments (Dummy such as real*8, dimension(:), ...) is used, the caller must have an interface. This is available by default should the subroutine be located within a module, but is not the case when it is not unless the compiler is directed to generate and warn of interfaces. Because this appeared to work before, you may have had this option enabled before, but not now.