Variables get corrupted in 2019 Update 1 compiler

[S__MPay]

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?

[mecej4]

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.

[jimdempseyatthecove]

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.

Jim Dempsey