[RFC, Fortran, (pr66775)] Allocatable function result

[RFC, Fortran, (pr66775)] Allocatable function result

[Andre Vehreschild]

Hi all,

I need your help on how to interpret the standard(s) or how to implement
handling an allocatable function's result, when that result is not allocated by
the function. Imagine the simple (albeit artificial) case:

integer function read_input()
  ! Do whatever is needed to read an int.
  read_input = ...
end function

integer function getNext()
  allocatable :: getNext
  if (more_input_available ()) getNext = read_input()
end function

where the function getNext () returns an (automatically) allocated result when
more_input_available() returns .true.. Otherwise getNext () returns an
unallocated object, i.e., the result's allocation status is .false.. I don't
want to argue about this design's quality (considering it poor myself). I
suppose that this code is legal, right?

Unfortunately gfortran can not handle it currently. The issue here is shown in
the pseudo code of:

integer, allocatable :: res
res = getNext ()

The pseudo code does this:

 	integer(kind=4) * D.3425;

        if (res != 0B) goto L.6;
        res = (integer(kind=4) *) __builtin_malloc (4);
        L.6:;
        D.3425 = getnext ();
        *res = *D.3425; // Oooops! D.3425 is NULL, when more_input_available ()
		        // is .false.

That is there is a classic null-pointer dereference.

I am curious why the memory allocated (or not) by the function is not reused for
the allocatable object on the lhs? I propose to generally handle an assignment
of a scalar allocatable(!) function result to a scalar allocatable(!) variable
like this (shortened a bit for brevity):

 	TYPE * res, D.3415, D.3417;

        D.3415 = get_next ();
        // Swap new result and old contents of res.
        D.3417 = D.3415;
        D.3415 = res;
        res = D.3417;
        // Deallocate old content of res to prevent memory leaks.
        if (D.3415 != 0B)  __builtin_free (D.3415);

Note there is no initial malloc of res! Would this do any harm, besides
preventing memory loss, saving an allocation and be cleaner to read on the
pseudo code side. Does it violate the standard somehow? Any ideas on
alternatives to prevent the null-pointer dereference in the initial code?

Suggestions, issues, objections???

Regards,
	Andre
-- 
Andre Vehreschild * Email: vehre ad gmx dot de 

Re: [RFC, Fortran, (pr66775)] Allocatable function result

[Steve Kargl]

On Thu, Jul 09, 2015 at 12:25:18PM +0200, Andre Vehreschild wrote:
> 
> I need your help on how to interpret the standard(s) or how to
> implement handling an allocatable function's result, when that
> result is not allocated by the function.  Imagine the simple
> (albeit artificial) case:
> 
> integer function read_input()
>   read_input = ...
> end function
> 
> integer function getNext()
>   allocatable :: getNext
>   if (more_input_available ()) getNext = read_input()
> end function
> 
> where the function getNext () returns an (automatically)
> allocated result when more_input_available() returns .true..
> Otherwise getNext () returns an unallocated object, i.e.,
> the result's allocation status is .false.. I don't want to
> argue about this design's quality (considering it poor myself). I
> suppose that this code is legal, right?

Code is both valid and invalid.  As you point out, it
depends on the return value of more_input_available().
Also, note, it is always invalid under -std=f95 as it
is using automatic (re-)allocation of the LHS.

> Unfortunately gfortran can not handle it currently.

Whatever gfortran does is "correct", because the code is
invalid in the more_input_available() = .false. case.  It is
the responsible of the programmer to ensure that getNext() has
an allocated and assigned value before it returns.  IHMO,
I think that gfortran should not try to guess what the
programmer might have intended.

Yes, the compiled code may dereference a possibly invalid pointer.
The compiled program should segfault, and the programmer should
fix the Fortran code.

function getNext()
   allocatable :: getNext
   if (more_input_available ())
      getNext = read_input()
   else
      allocate(getNext, source=some_error_code?)
   end if
end function

or

function getNext()
   allocatable :: getNext
   allocate(getNext, source=some_error_code?)
   if (more_input_available ()) getNext = read_input()
end function

-- 
Steve

Re: [RFC, Fortran, (pr66775)] Allocatable function result

[Andre Vehreschild]

Hi Steve,

Thanks for your knowledge. Can you support your statement that an allocatable function has to return an allocated object by a part of the standard? I totally agree with you that this code is ill-designed, but IMO is it not the task of the compiler to address ill design. The compiler has to comply to the standard and the standard allows allocatable objects to be unallocated. So why has the result of a function be allocated always?

Regards,
Andre

Am 9. Juli 2015 19:50:47 MESZ, schrieb Steve Kargl <sgk@troutmask.apl.washington.edu>:
>On Thu, Jul 09, 2015 at 12:25:18PM +0200, Andre Vehreschild wrote:
>> 
>> I need your help on how to interpret the standard(s) or how to
>> implement handling an allocatable function's result, when that
>> result is not allocated by the function.  Imagine the simple
>> (albeit artificial) case:
>> 
>> integer function read_input()
>>   read_input = ...
>> end function
>> 
>> integer function getNext()
>>   allocatable :: getNext
>>   if (more_input_available ()) getNext = read_input()
>> end function
>> 
>> where the function getNext () returns an (automatically)
>> allocated result when more_input_available() returns .true..
>> Otherwise getNext () returns an unallocated object, i.e.,
>> the result's allocation status is .false.. I don't want to
>> argue about this design's quality (considering it poor myself). I
>> suppose that this code is legal, right?
>
>Code is both valid and invalid.  As you point out, it
>depends on the return value of more_input_available().
>Also, note, it is always invalid under -std=f95 as it
>is using automatic (re-)allocation of the LHS.
>
>> Unfortunately gfortran can not handle it currently.
>
>Whatever gfortran does is "correct", because the code is
>invalid in the more_input_available() = .false. case.  It is
>the responsible of the programmer to ensure that getNext() has
>an allocated and assigned value before it returns.  IHMO,
>I think that gfortran should not try to guess what the
>programmer might have intended.
>
>Yes, the compiled code may dereference a possibly invalid pointer.
>The compiled program should segfault, and the programmer should
>fix the Fortran code.
>
>function getNext()
>   allocatable :: getNext
>   if (more_input_available ())
>      getNext = read_input()
>   else
>      allocate(getNext, source=some_error_code?)
>   end if
>end function
>
>or
>
>function getNext()
>   allocatable :: getNext
>   allocate(getNext, source=some_error_code?)
>   if (more_input_available ()) getNext = read_input()
>end function

-- 
Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen
Mail: vehre@gmx.de * Tel.: +49 241 9291018

Re: [RFC, Fortran, (pr66775)] Allocatable function result

[Steve Kargl]

On Thu, Jul 09, 2015 at 08:59:08PM +0200, Andre Vehreschild wrote:
> Hi Steve,
> 
> Thanks for your knowledge. Can you support your statement that an allocatable function has to return an allocated object by a part of the standard? I totally agree with you that this code is ill-designed, but IMO is it not the task of the compiler to address ill design. The compiler has to comply to the standard and the standard allows allocatable objects to be unallocated. So why has the result of a function be allocated always?
> 
> Regards,
> Andre
> 

I think the following excerpts from F2008 are the relevant
clauses, especially the 2nd to last sentence in the excerpt
from 12.6.2.2.

!  12.5.3
!
!  When execution of the function is complete, the value of
!  the function result is available for use in the expression
!  that caused the function to be invoked.
!
!  12.6.2.2
!
!  If RESULT appears, the name of the result variable of the
!  function is result-name and all occurrences of the function
!  name in execution-part statements in its scope refer to the
!  function itself.  If RESULT does not appear, the name of the
!  result variable is function-name and all occurrences of the
!  function name in execution-part statements in its scope are
!  references to the result variable.  The characteristics (12.3.3)
!  of the function result are those of the result variable.  On
!  completion of execution of the function, the value returned is
!  that of its result variable.  If the function result is a pointer,
!  the shape of the value returned by the function is determined by
!  the shape of the result variable when the execution of the function
!  is completed.  If the result variable is not a pointer, its value
!  shall be defined by the function.  If the function result is a
!  pointer, on return the pointer association status of the result
!  variable shall not be undefined.

-- 
Steve

Re: [RFC, Fortran, (pr66775)] Allocatable function result

[Andre Vehreschild]

Hi all,

this means that pr66775 is to be closed as resolved invalid, because the
current implementation is alright, but only the program to compile is garbage.
Ok, suits me.

- Andre

On Thu, 9 Jul 2015 12:41:31 -0700
Steve Kargl <sgk@troutmask.apl.washington.edu> wrote:

> On Thu, Jul 09, 2015 at 08:59:08PM +0200, Andre Vehreschild wrote:
> > Hi Steve,
> > 
> > Thanks for your knowledge. Can you support your statement that an
> > allocatable function has to return an allocated object by a part of the
> > standard? I totally agree with you that this code is ill-designed, but IMO
> > is it not the task of the compiler to address ill design. The compiler has
> > to comply to the standard and the standard allows allocatable objects to be
> > unallocated. So why has the result of a function be allocated always?
> > 
> > Regards,
> > Andre
> > 
> 
> I think the following excerpts from F2008 are the relevant
> clauses, especially the 2nd to last sentence in the excerpt
> from 12.6.2.2.
> 
> !  12.5.3
> !
> !  When execution of the function is complete, the value of
> !  the function result is available for use in the expression
> !  that caused the function to be invoked.
> !
> !  12.6.2.2
> !
> !  If RESULT appears, the name of the result variable of the
> !  function is result-name and all occurrences of the function
> !  name in execution-part statements in its scope refer to the
> !  function itself.  If RESULT does not appear, the name of the
> !  result variable is function-name and all occurrences of the
> !  function name in execution-part statements in its scope are
> !  references to the result variable.  The characteristics (12.3.3)
> !  of the function result are those of the result variable.  On
> !  completion of execution of the function, the value returned is
> !  that of its result variable.  If the function result is a pointer,
> !  the shape of the value returned by the function is determined by
> !  the shape of the result variable when the execution of the function
> !  is completed.  If the result variable is not a pointer, its value
> !  shall be defined by the function.  If the function result is a
> !  pointer, on return the pointer association status of the result
> !  variable shall not be undefined.
> 


-- 
Andre Vehreschild * Email: vehre ad gmx dot de 

Re: [RFC, Fortran, (pr66775)] Allocatable function result

[Steve Kargl]

Yes, it should be closed.  When I asked you to open it,
I thought the issue was a corner case in your patch.

-- 
steve

On Fri, Jul 10, 2015 at 11:44:32AM +0200, Andre Vehreschild wrote:
> 
> this means that pr66775 is to be closed as resolved invalid, because the
> current implementation is alright, but only the program to compile is garbage.
> Ok, suits me.
> 
> - Andre
> 
> On Thu, 9 Jul 2015 12:41:31 -0700
> Steve Kargl <sgk@troutmask.apl.washington.edu> wrote:
> 
> > On Thu, Jul 09, 2015 at 08:59:08PM +0200, Andre Vehreschild wrote:
> > > Hi Steve,
> > > 
> > > Thanks for your knowledge. Can you support your statement that an
> > > allocatable function has to return an allocated object by a part of the
> > > standard? I totally agree with you that this code is ill-designed, but IMO
> > > is it not the task of the compiler to address ill design. The compiler has
> > > to comply to the standard and the standard allows allocatable objects to be
> > > unallocated. So why has the result of a function be allocated always?
> > > 
> > > Regards,
> > > Andre
> > > 
> > 
> > I think the following excerpts from F2008 are the relevant
> > clauses, especially the 2nd to last sentence in the excerpt
> > from 12.6.2.2.
> > 
> > !  12.5.3
> > !
> > !  When execution of the function is complete, the value of
> > !  the function result is available for use in the expression
> > !  that caused the function to be invoked.
> > !
> > !  12.6.2.2
> > !
> > !  If RESULT appears, the name of the result variable of the
> > !  function is result-name and all occurrences of the function
> > !  name in execution-part statements in its scope refer to the
> > !  function itself.  If RESULT does not appear, the name of the
> > !  result variable is function-name and all occurrences of the
> > !  function name in execution-part statements in its scope are
> > !  references to the result variable.  The characteristics (12.3.3)
> > !  of the function result are those of the result variable.  On
> > !  completion of execution of the function, the value returned is
> > !  that of its result variable.  If the function result is a pointer,
> > !  the shape of the value returned by the function is determined by
> > !  the shape of the result variable when the execution of the function
> > !  is completed.  If the result variable is not a pointer, its value
> > !  shall be defined by the function.  If the function result is a
> > !  pointer, on return the pointer association status of the result
> > !  variable shall not be undefined.
> > 
> 
> 
> -- 
> Andre Vehreschild * Email: vehre ad gmx dot de 

-- 
Steve

Re: [RFC, Fortran, (pr66775)] Allocatable function result

[Mikael Morin]

Hello all,

I'm not completely convinced by the standard excerpts that have been
quoted about this topic, as they don't have any explicit mention of
allocatable variables/expressions.
For what it's worth, in my opinion, the handling of allocatable that was
proposed by Andre makes sense to me.  It's consistent with what is done
for derived type assignment, the lhs' allocatable components are
deallocated if their rhs counter part are unallocated.  Doing the same
for whole objects would be, well, consistent.
What is done by the other compilers?

Mikael

Re: [RFC, Fortran, (pr66775)] Allocatable function result

[Andre Vehreschild]

Hi Mikael, hi all,

I only had the chance to check with ifort (different versions; including the most recent one) and that compiler is consistent with gfortran as it is now, I.e., the executable segfaults after the function has been called.

I am though curious what other compilers opinion on that point is.

Regards,
Andre

Am 10. Juli 2015 18:20:47 MESZ, schrieb Mikael Morin <mikael.morin@sfr.fr>:
>Hello all,
>
>I'm not completely convinced by the standard excerpts that have been
>quoted about this topic, as they don't have any explicit mention of
>allocatable variables/expressions.
>For what it's worth, in my opinion, the handling of allocatable that
>was
>proposed by Andre makes sense to me.  It's consistent with what is done
>for derived type assignment, the lhs' allocatable components are
>deallocated if their rhs counter part are unallocated.  Doing the same
>for whole objects would be, well, consistent.
>What is done by the other compilers?
>
>Mikael

-- 
Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen
Mail: vehre@gmx.de * Tel.: +49 241 9291018

Re: [RFC, Fortran, (pr66775)] Allocatable function result

[Steve Kargl]

On Fri, Jul 10, 2015 at 06:20:47PM +0200, Mikael Morin wrote:
> 
> I'm not completely convinced by the standard excerpts that have been
> quoted about this topic, as they don't have any explicit mention of
> allocatable variables/expressions.

I did not quote 12.3.3 about "characteristics of function results",
which mentions the allocatable attribute.  But, that is not 
necessarily relevant.  The pieces I quoted explicitly states

   "On completion of execution of the function, the value returned
    is that of its function result. ... If the function result is
    not a pointer, its value shall be defined by the function."

The function not only needs to allocate memory, it needs to
assign it a value.  In the following, if i <= 0, the function
result is not defined. 

module foo
   contains
   function bar(i)
      integer, allocatable :: bar
      integer, intent(in) :: i
      if (i > 0) bar = i
   end function bar
end module foo

program test
   use foo
   integer j
   j = bar( 3); print *, j
   j = bar(-3); print *, j
   end if
end program test

Even if Andre developed a patch to allocate memory in
bar() for the i <= 0 case to prevent the segfault, the
function must return a value.  What should that value be?

I suppose one could argue that gfortran should issue
a run-time error if it can detect the undefined function
result.  But may lead to a run-time penalty.

-- 
Steve

Re: [RFC, Fortran, (pr66775)] Allocatable function result

[Andre Vehreschild]

[-- Attachment #1: Type: text/plain, Size: 1755 bytes --]

Hi,

<snip>
>    "On completion of execution of the function, the value returned
>     is that of its function result. ... If the function result is
>     not a pointer, its value shall be defined by the function."

Now we can argue whether the "shall be defined" is to be interpreted as "has to
be" or as "might be". For me - being a non-native English speaker - that "shall"
is not an obligation but should be interpreted as "commonly the function result
is to be defined, but there can be exceptions". Now I am curious about how
native English speakers understand that standard statement.

My argument on returning an unallocated object is not to support programatical
errors, but rather for circumstances, where one tries to allocate a resource
and on failure nothing is returned. Think about a function like
try_to_acquire_resource(), when the resource could be reserved (like, for
example, a co-processor), then its (private) structure is returned
(implementing the OO concept of information hiding). Furthermore one could
think about using concepts like memory pools, where a memory fragment is
returned by a function as long as the capacity of the pool is no exhausted.
This of course is more difficult in Fortran as is lacks the ways of doing
C-style pointer arithmetic. This is just an example. So please don't nail me on
this one. I just wanted to give you my idea, why I think returning an
unallocated "object" should be legal for an allocatable function result. (Note,
the result is called allocatable, not allocated function result :-). Meaning,
that it can be allocated, but does not have to be.)

When someone has other compilers available the test program is attached.

Regards,
	Andre
-- 
Andre Vehreschild * Email: vehre ad gmx dot de 

[-- Attachment #2: test_pr66775.f03 --]
[-- Type: application/octet-stream, Size: 1363 bytes --]

! { dg-do run }

module test_alloc_func_mod
  implicit none

  type t
    integer :: i = 5
  end type

contains

  type(t) function t_init()
    allocatable :: t_init
  end function

  type(t) function t_init2()
    allocatable :: t_init2
    allocate(t_init2)
  end function

  integer function i_init()
    allocatable :: i_init
  end function

  integer function i_init2()
    allocatable :: i_init2
    allocate(i_init2)
  end function

end module test_alloc_func_mod

program test_alloc_func
  use test_alloc_func_mod

  type(t), allocatable :: temp
  type(t), allocatable :: vec(:)
  integer, allocatable :: i

  temp = t_init()
  if (allocated (temp)) call abort()

  temp = t_init2()
  if (.not. allocated (temp)) call abort()
  if (temp%i /= 5) call abort()
  deallocate(temp)

! The next two lines create a memory corruption/segfault, because the result
! of i_init() is not allocated but dereferenced.
!  i = i_init()
!  if (allocated (i)) call abort()

  i = i_init2()
  if (.not. allocated(i)) call abort()
  deallocate(i)

  allocate (vec(5))
  vec = t_init2()
  if (.not. allocated(vec)) call abort()
  if (any(vec%i /= [5,5,5,5,5])) call abort()
  deallocate (vec)

  allocate (vec(5))
  vec(:) = t_init2() ! Note the colon op.
  if (.not. allocated(vec)) call abort()
  if (any(vec%i /= [5,5,5,5,5])) call abort()
  deallocate (vec)

end program

Re: [RFC, Fortran, (pr66775)] Allocatable function result

[Mikael Morin]

Le 11/07/2015 12:36, Andre Vehreschild a écrit :
> Hi,
> 
> <snip>
>>    "On completion of execution of the function, the value returned
>>     is that of its function result. ... If the function result is
>>     not a pointer, its value shall be defined by the function."
> 
> Now we can argue whether the "shall be defined" is to be interpreted as "has to
> be" or as "might be". For me - being a non-native English speaker - that "shall"
> is not an obligation but should be interpreted as "commonly the function result
> is to be defined, but there can be exceptions". Now I am curious about how
> native English speakers understand that standard statement.
I'm non-native as well, but my interpretation is "has to be". :-(
Which (if correct) puts this topic out of the standard territory.

Mikael

Re: [RFC, Fortran, (pr66775)] Allocatable function result

[Dan Nagle]

Hi,

> On Jul 11, 2015, at 04:36 , Andre Vehreschild <vehre@gmx.de> wrote:
> 
>> 
>>   "On completion of execution of the function, the value returned
>>    is that of its function result. ... If the function result is
>>    not a pointer, its value shall be defined by the function."
> 
> Now we can argue whether the "shall be defined" is to be interpreted as "has to
> be" or as "might be". For me - being a non-native English speaker - that "shall"
> is not an obligation but should be interpreted as "commonly the function result
> is to be defined, but there can be exceptions". Now I am curious about how
> native English speakers understand that standard statement.

The standard is written in standardese, not English.

“Shall” is a requirement.  Full stop.

--

Cheers!
Dan Nagle

Re: [RFC, Fortran, (pr66775)] Allocatable function result

[Mike Stump]

On Jul 11, 2015, at 4:58 AM, Dan Nagle <danlnagle@mac.com> wrote:
> The standard is written in standardese, not English.

While what you say is true, sorry, shall _is_ English:

  used in laws, regulations, or directives to express what is mandatory

Re: [RFC, Fortran, (pr66775)] Allocatable function result

[Mikael Morin]

Le 10/07/2015 20:57, Steve Kargl a écrit :
> On Fri, Jul 10, 2015 at 06:20:47PM +0200, Mikael Morin wrote:
>>
>> I'm not completely convinced by the standard excerpts that have been
>> quoted about this topic, as they don't have any explicit mention of
>> allocatable variables/expressions.
> 
> I did not quote 12.3.3 about "characteristics of function results",
> which mentions the allocatable attribute.  But, that is not 
> necessarily relevant.  The pieces I quoted explicitly states
> 
>    "On completion of execution of the function, the value returned
>     is that of its function result. ... If the function result is
>     not a pointer, its value shall be defined by the function."
Yeah, well, if the standard committee had allowed unallocated
allocatable results, they would have put it here together with pointer,
I guess.

> 
> The function not only needs to allocate memory, it needs to
> assign it a value.  In the following, if i <= 0, the function
> result is not defined. 
> 
> module foo
>    contains
>    function bar(i)
>       integer, allocatable :: bar
>       integer, intent(in) :: i
>       if (i > 0) bar = i
>    end function bar
> end module foo
> 
> program test
>    use foo
>    integer j
>    j = bar( 3); print *, j
>    j = bar(-3); print *, j
>    end if
> end program test
> 
> Even if Andre developed a patch to allocate memory in
> bar() for the i <= 0 case to prevent the segfault, the
> function must return a value.  What should that value be?
Your example is, of course, 100% invalid; a value is needed to put in j.
But the case is more debatable to me, if j is allocatable.
In that case an unallocated bar() result could just make j unallocated.

Mikael

Re: [RFC, Fortran, (pr66775)] Allocatable function result

[Andre Vehreschild]

Hi,

> > module foo
> >    contains
> >    function bar(i)
> >       integer, allocatable :: bar
> >       integer, intent(in) :: i
> >       if (i > 0) bar = i
> >    end function bar
> > end module foo
> > 
> > program test
> >    use foo
> >    integer j
> >    j = bar( 3); print *, j
> >    j = bar(-3); print *, j
> >    end if
> > end program test
> > 
> > Even if Andre developed a patch to allocate memory in
> > bar() for the i <= 0 case to prevent the segfault, the
> > function must return a value.  What should that value be?
> Your example is, of course, 100% invalid; a value is needed to put in j.
> But the case is more debatable to me, if j is allocatable.
> In that case an unallocated bar() result could just make j unallocated.

Yes, completely right. The example so far is not on the point I try to make.
For your example Steve, the result of bar has to be allocated, no argument on
that, but what about, when j is allocatable? As stated in a previous mail,
that property is not called allocated, but allocatable...

- Andre
-- 
Andre Vehreschild * Email: vehre ad gmx dot de 

Re: [RFC, Fortran, (pr66775)] Allocatable function result

[Steve Kargl]

On Sat, Jul 11, 2015 at 12:54:33PM +0200, Mikael Morin wrote:
> Le 10/07/2015 20:57, Steve Kargl a ?crit :
> > On Fri, Jul 10, 2015 at 06:20:47PM +0200, Mikael Morin wrote:
> >>
> >> I'm not completely convinced by the standard excerpts that have been
> >> quoted about this topic, as they don't have any explicit mention of
> >> allocatable variables/expressions.
> > 
> > I did not quote 12.3.3 about "characteristics of function results",
> > which mentions the allocatable attribute.  But, that is not 
> > necessarily relevant.  The pieces I quoted explicitly states
> > 
> >    "On completion of execution of the function, the value returned
> >     is that of its function result. ... If the function result is
> >     not a pointer, its value shall be defined by the function."
> Yeah, well, if the standard committee had allowed unallocated
> allocatable results, they would have put it here together with pointer,
> I guess.
> 

From F95, 6.3.1.1.  "An allocatable array that has been allocated 
by an ALLOCATE statement and has not been subsequently deallocated
(6.3.3) is currently allocated and is definable."

Note it is "definable".  It is not defined.

I cannot find a similar statement in F08 due to the massive 
rewrite of the standard to accommodate new features (e.g.,
co-arrays and allocation-on-assignment).  F08 6.7.1.3 does
say

  The allocation status of an allocatable entity is one of the
  following at any time.

  * The status of an allocatable variable becomes "allocated" if
    it is allocated by and ALLOCATE statement, if it allocated
    during assignment, or if it is given that status by the 
    intrinsic subroutine MOVE_ALLOC (13.7.118).  An allocatable
    variable with this status my be referenced, defined, or 
    deallocated; ...

  * An allocatable variable has a status of "unallocated" if it
    is not allocated.  The status of an allocatable variable 
    becomes unallocated if it is deallocated (6.7.3) or if it is
    given that status by the allocation transfer procedure.

So, change my example to what you want

module foo
   contains
   function bar(i)
      integer, allocatable :: bar
      integer, intent(in) :: i
      if (i > 0) bar = i
   end function bar
end module foo

program test
   use foo
   integer, allocatable :: j
   j = bar( 3); if (allocated(j)) print *, j
   j = bar(-3); if (allocated(j)) print *, j
end program test

So, it seems you want the allocation status of j in 'j = bar(-3)'
to be unallocated due to the "allocation-on-assignment" feature
of f08.  I'll simply note that *there is no assignment* as bar(-3)
does not return an a value, which is required by
 
  If the function result is not a pointer, its value shall be
  defined by the function.

So, you want unallocation-on-nonassignment, which is not in the
standard.

-- 
steve