Frontend bug: Argument number 2 to value: type mismatch

Accelerated Computing HPC Compilers nvc, nvc++ and nvfortran
1

There seems to be a confusion about the string value in the frontend, which in case of a variable declaration has a special meaning, but is apparently parsed incorrectly in another context.

module counter_m
  type counter_t
    procedure(get_value), pointer :: value
  end type counter_t
  abstract interface
    integer function get_value(this, elapsed)
      import counter_t
      class(counter_t) :: this
      logical, optional :: elapsed
    end function get_value
  end interface
contains
  subroutine progress(ctr)
    class(counter_t) :: ctr
    write(*,*) ctr%value()
  end subroutine progress
end module counter_m

$ nvfortran --version

nvfortran 26.1-0 64-bit target on x86-64 Linux -tp icelake-server 
NVIDIA Compilers and Tools
Copyright (c) 2026, NVIDIA CORPORATION & AFFILIATES.  All rights reserved.
$ nvfortran -c repro.f90 
NVFORTRAN-S-0188-Argument number 2 to value: type mismatch (repro.f90: 15)
  0 inform,   0 warnings,   1 severes, 0 fatal for progress

Other compilers (in particular NAG, known for strict standard conformance) accept this code.

$ nagfor -c repro.f90 
NAG Fortran Compiler Release 7.2(Shin-Urayasu) Build 7200
[NAG Fortran Compiler normal termination]
2

Thanks for the report henri.menke.

I was able to reproduce the error and filed a problem report, TPR #38319. Engineering will investigate.

Note that the error doesn’t appear to be due to the “value” keyword, but rather the use of the “optional”. If you pass a logical argument in the “ctr%value(lval)” call, then the error goes away.

-Mat

3

FYI, TPR #38319 was fixed in our 26.5 release.

-Mat

% nvfortran -c test.F90 -V26.3
NVFORTRAN-S-0188-Argument number 2 to value: type mismatch (test.F90: 19)
  0 inform,   0 warnings,   1 severes, 0 fatal for progress
% nvfortran -c test.F90 -V26.5
%