Bug with USE renaming, inlining, and optimization report

[Brian1]

I believe I found a bug with the Intel 15.0 compiler where a USE-renamed subroutine shows up in the optimization report under the USE-renamed name, rather than the subroutine's actual name.  I'm not sure if this is the compiler's intended behavior, but it seems unnecessarily confusing.  Consider the code:

! Compile with:
!   ifort -O3 -openmp -openmp-report bug.f90

module mod
  implicit none
  public

contains

subroutine sub(array)
  real :: array(42)
  integer :: i

  !$omp parallel do private(i)
  do i = 1, 42
    array(i) = 42.0
  end do
  !$omp end parallel do
end subroutine

end module


program bug
  use mod, use_renamed_sub => sub
  implicit none

  real :: array(42)

  call use_renamed_sub(array)
end program

Compiled as stated in the comment above, this produces the following optimization report:

Begin optimization report for: BUG

    Report from: OpenMP optimizations [openmp]

OpenMP Construct at bug.f90(14,9) inlined into bug.f90(30,8)
   remark #16200: OpenMP DEFINED LOOP WAS PARALLELIZED
===========================================================================

Begin optimization report for: USE_RENAMED_SUB

    Report from: OpenMP optimizations [openmp]

OpenMP Construct at bug.f90(14,9)
   remark #16200: OpenMP DEFINED LOOP WAS PARALLELIZED
===========================================================================

The name mentioned in the optimization report is "USE_RENAMED_SUB" rather than the expected "SUB".  I have verified that this occurs only when "SUB" is inlined; if by some means inlining is prevented, then the expected name "SUB" is referenced in the report.

This result was obtained using Intel Fortran 15.0.1 20141022 on Mac OS X 10.10.1.

[Steven_L_Intel1]

Is this really a bug? To my eyes, the current behavior is the preferable one, since the report is calling the procedure by the name used in the procedure where it is inlined. I'd be interested in the comments of other users.

[Brian1]

Consider the case where this occurs when compiling a very large source file containing dozens of subprograms, each with many loops, directives, and so on, that results in a very long optimization report.  The programmer is trying to figure out what optimizations were performed on SUB, but SUB doesn't appear anywhere in the optimization report.  This is exactly what happened in my case and it took me quite a while to sort out what was happening.

That said, I realize now that a better way to deal with this would have been to request a complete optimization report (-opt-report) rather than just the OpenMP portion (-openmp-report).  Once that's done it's not so critical what exactly the subroutine gets referred to as, I guess, since one can more easily follow where inlining occurred or originated from.