The following legal Fortran causes a runtime ICE in certain cases. Also, valgrind reports use of an unitialized memory reference (UMR). Steve's list of F95 compliance tests exposed this problem.
real :: a(5) a = 1.1 a(3) = 2.2 i = maxloc(a,dim=1) print*, i end
The resulting ICE:
fatal Fortran runtime error(/local/home/mleair/fir-dev/f18-llvm-project/flang/runtime/reduction-templates.h:203): Internal error: RUNTIME_CHECK(at[0] == 1) failed at /local/home/mleair/fir-dev/f18-llvm-project/flang/runtime/reduction-templates.h(203)
The ICE occurs because a scalar result descriptor has 1 element and a rank == 0. The runtime calls GetLowerBounds() which does nothing with rank == 0. This can lead to an ICE and/or UMR.
Since this occurs with only a handful of intrinsics, I propose adding a check for this case where result.GetLowerBounds(at) is called instead of changing GetLowerBounds(). We may not want to make an assumption with rank == 0 in other cases. But I'll let the code reviewers weigh in on whether we should just modify GetLowerBounds() to work with rank == 0 and number of elements == 1.
This change is done for the maxloc, maxval, minloc, minval, findloc, count, parity, all, any intrinsics. I also added scalar cases to the unit tests for each of these intrinsics as well. Let me know if there are other intrinsics to consider with this change.
INTERNAL_CHECK(result.rank() == 0 || at[0] == 1);