Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Warning about undefined return values

Anonymous
Not applicable
884 Views

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

0 Kudos
22 Replies
Arjen_Markus
Valued Contributor III
789 Views

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
Not applicable
630 Views

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
Not applicable
758 Views

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
Valued Contributor III
750 Views

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
Valued Contributor III
745 Views

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

mecej4
Black Belt
735 Views

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
Valued Contributor III
730 Views

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
Not applicable
713 Views

@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
Valued Contributor III
681 Views

Re Tcl: Nice, so is mine :).

jimdempseyatthecove
Black Belt
728 Views

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
Honored Contributor I
718 Views

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
Not applicable
710 Views

The compiler is from the Intel oneAPI HPC toolkit 2021.1

No submodules involved in the entire code base.

-- tsbg

andrew_4619
Honored Contributor I
672 Views

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

 

Anonymous
Not applicable
666 Views

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

 

Anonymous
Not applicable
739 Views

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
Not applicable
615 Views

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
Honored Contributor II
608 Views

@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
Valued Contributor III
605 Views

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

Anonymous
Not applicable
547 Views
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
Black Belt
588 Views

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

Reply