Warning about undefined return values

[Anonymous]

Hi

Since I use the oneAPI Fortran compiler ifort on Windows I get sometimes spurious warnings about undefined return values:

sourcefile.f90: warning #6178: The return value of this FUNCTION has not been defined.    [RES]

The warning does not say which function it means!

sourcefile.f90 uses a module which itselfs compiles cleanly without warnings.

The warning does not come up in every case.

Could someone explain to me why this warning is shown?

Thank you in advance

--tsbg

[Arjen_Markus]

You did not provide any code, so I concocted a small test program instead:

module chk
    implicit none
contains

real function f( x )
    real, intent(in) :: x

    if ( x > 0.0 ) then
        !f = sqrt(x)
    endif
end function f
end module chk

If I uncomment the statement with sqrt, I get no complains, but with the above version:

chk_func_ret.f90(8): warning #6178: The return value of this FUNCTION has not been defined.   [F]
real function f( x )
--------------^

So the answer to your question: the function name is contained in the square brackets.

[Anonymous]

Thanks for the code, but it does not represent my problem. In your example you get 3 lines back from the compiler:

chk_func_ret.f90(8): warning #6178: The return value of this FUNCTION has not been defined.   [F]
real function f( x )
--------------^

in my case I get only one line:

sourcefile.f90: warning #6178: The return value of this FUNCTION has not been defined. [RES]

As you can see, neither the line number nor the function declaration is shown.

The module that is used by sourcefile.f90 is the top module of a bigger library which contains hundreds of functions with a return value of "res".  And the library compiles cleanly without any warnings.

I couldn't replicate the problem with a small code example, thats why I try to describe my problem.

-- tsbg

[Anonymous]

Thank you for the example, but it does not represent exactly my problem.

In your example, the compiler responds with 3 lines of output:

chk_func_ret.f90(8): warning #6178: The return value of this FUNCTION has not been defined.   [F]
real function f( x )
--------------^

In my case, the compiler outputs only one line:

sourcefile.f90: Warning #6178: The return value of this FUNCTION has not been defined.    [RES]

Neither the line number after the source file, nor the function declaration is shown.

sourcefile.f90 uses a module that is the top module of a bigger library which contains hundreds of function with the return value "res". The library for itself compiles cleanly without any warnings.

I wasn't able to reproduce the problem with a small example, thats the reason why I try to explain it.

-- tsbg

[Arjen_Markus]

This top module, does it allow you to pull in smaller pieces of the large library? Then you might be able to divide the problem into smaller problems. As you do not show any code, it is difficult to judge where this is coming from

Another suggestion: a different compiler.

[Arjen_Markus]

By another compiler I mean that chances are that it produces different messages and may indicate the correct location in the code.

[mecej4]

I tried the following variation of Arjen's example

function f( x ) result(s)
    real, intent(in) :: x
    real :: s

    if ( x > 0.0 ) then
        !s = sqrt(x)
    endif
end function f

and the compiler said

arj.f90(5): warning #6178: The return value of this FUNCTION has not been defined.   [S]

Note that the name inside [] is the name of the result variable, rather than the function name.

I don't know why the compiler did not provide the line number. Perhaps, OP can look in the source file for "RESULT (RES)".

[Arjen_Markus]

Hm, how about changing the function result names to something like RES1, RES2, ... This could be done by a small script in your favourite scripting language (you will need support for regular expressions or the like, as doing it by hand is error-prone and quite tedious).

[Anonymous]

@Arjen_Markus That's an interesting idea, thank you.

My prefered scripting language is Tcl, and I have already some scripts processing Fortran source code.

-- tsbg

[Arjen_Markus]

Re Tcl: Nice, so is mine :).

[jimdempseyatthecove]

Also note in mecej4's example, the line number(5) of the source file arj.f90(5) is listed, whereas in your example there was no such line number. Did you edit the error message to hide the file name, and in the process omit the line number?

Jim Dempsey

[andrew_4619]

which compiler version is this? Are you using submodules?  I remember reporting several bugs when submodules were first introduced in ifort some versions back and this looks a bit like one of them.

[Anonymous]

The compiler is from the Intel oneAPI HPC toolkit 2021.1

No submodules involved in the entire code base.

-- tsbg

[andrew_4619]

Is it the classic or IFX compiler in oneapi, that later is beta version and has many features not working/implemented

[Anonymous]

It is the classic ifort compiler from the oneAPI HPC toolkit.

[Anonymous]

Thanks for your suggestions.

Unfortunately the code is proprietary and cannot be shared. The entire code base is developed with 2 compilers, ifort and gfortran. With gfortran everything is fine, no warnings, no errors. With ifort, everything was fine until we switched to version 2021.1 from the oneAPI HPC toolkit.

It is not easy to split the top module in smaller pieces, because the are quite some dependencies between the used modules. It also seems, that the warning propagates through the modules.

I think this warning #6178 shouldn't be displayed only because I'am using a module. The warning should be displayed when compiling the module that contains the faulty function.

I am gratefull for any idea that helps to silence this warning, because I don't want it to disable generaly.

-- tsbg

[Anonymous]

Here is is a follow up:

I implemented the idea from Arjen Markus and wrote a Tcl script which gave all result variables a unique name.

After running the script and recompiling everything, I was able to identify two functions which seem to be responsible for the generation of the "faulty" warning. The functions are in different modules included by the top module. The only thing they have in common is that the result type is of type(c_ptr).

I am still not able to produce a small example that represents the problem.

-- tsbg

[FortranFan]

@Anonymous ,

Can you post those 2 functions here?  If you have any concerns about proprietary aspects, you can ".." out the body of the function i.e., hide your implementation details.

The key aspect, I think, will be to share the function signature in the module host exactly as you have it without any editing.

The reason for this request, if you can oblige, is only to try to help you create a small reproducer.

[Arjen_Markus]

And are these the only functions that return type(c_ptr)? Just speculating about the underlying cause here.

[Anonymous]

Arjen_Markus wrote:
And are these the only functions that return type(c_ptr)? 

Indeed, this are the only "real" functions that return type(c_ptr). But there are a lot of interfaces to the Windows API and the C runtime.

-- tsbg

[jimdempseyatthecove]

Because this is function not return a value error and the return value is a c_ptr, what I suggest you do is to insert a new first statement that initializes the return value to an invalid c_ptr such as 1 or -1.

This will (may) satisfy two issues

1) It will (should) eliminate the compiler warning
2) Should your function have a programming error and actually return without specifying a proper return value, the use of an invalid c_ptr may cause an illegal addressing problem shortly after the return. This then ought to aid you in locating when the bug crops up.

Jim Dempsey