pFUnit icon indicating copy to clipboard operation
pFUnit copied to clipboard

FYI: pFUnit triggers a GNU Fortran/Coverage bug

Open olebole opened this issue 5 years ago • 5 comments

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.

olebole avatar Jun 24 '20 06:06 olebole

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.f90

with 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.

olebole avatar Nov 06 '20 09:11 olebole

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.

tclune avatar Nov 06 '20 14:11 tclune

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.

olebole avatar Nov 06 '20 14:11 olebole

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.

tclune avatar Nov 06 '20 14:11 tclune

OK in 15.6.2.1
"If the function result is not a pointer, its value shall be defined by the function."

tclune avatar Nov 06 '20 14:11 tclune