pFUnit
pFUnit copied to clipboard
FYI: pFUnit triggers a GNU Fortran/Coverage bug
Just if you are curious (not a pFUnit bug), and for reference: the Fortran code generated from the .pf files by funitproc trigger a bug in GNU Fortran 9+10 when compiled with coverage (gfortran --coverage). Since one doesn't need the coverage on these files, one can leave out this flag here; it is however still needed when linking the test executables.
One additional comment here which may be of interest: kargl at (from gcc.gnu.org) wrote:
First, the caveat, the Fortran code in the attached example is invalid so a compiler can to do whatever it wants, including dying with an ICE.
Split the example code into a file with only the module (say, d.f90) and a file with only the function foo_suite (say, e.f90). I get
% gfcx -c --coverage d.f90 % gfcx -c --coverage e.f90with no ICE. […] (Internal Compiler Error)
This refers to my (extremely shortened) example
module foo
contains
subroutine sbr()
end subroutine sbr
end module foo
function foo_suite() result(suite)
use foo
integer :: bar
integer :: res
res = bar(sbr)
end function foo_suite
which I generated from the pFUnit generated code. It seems to violate some Fortran standard. I am not an expert in this, so this is just FYI.
I'm a bit tired this morning, but I'm not seeing anything invalid. Tried turning on aggressive flags with a few compilers and just got warnings about not assigning values to the function result and such.
I'll take it to the Fortran mailing list unless you happen to know what was concerning.
I am not an Fortran expert at all, so I have no glue why this shall be invalid. Just wanted to keep you up-to-date about comments on the code.
I'm now thinking that it is technically illegal not to assign a value to the function result. I'll try to find the language in the standard before I pester the committee.
OK in 15.6.2.1
"If the function result is not a pointer, its value shall be defined by the function."