public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Steve Kargl <sgk@troutmask.apl.washington.edu>
To: Mikael Morin <mikael.morin@sfr.fr>
Cc: Andre Vehreschild <vehre@gmx.de>,
	GCC-Patches-ML <gcc-patches@gcc.gnu.org>,
	       GCC-Fortran-ML <fortran@gcc.gnu.org>,
	       Paul Richard Thomas <paul.richard.thomas@gmail.com>
Subject: Re: [RFC, Fortran, (pr66775)] Allocatable function result
Date: Sat, 11 Jul 2015 15:37:00 -0000	[thread overview]
Message-ID: <20150711153716.GA10645@troutmask.apl.washington.edu> (raw)
In-Reply-To: <55A0F5E9.2070705@sfr.fr>

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

      parent reply	other threads:[~2015-07-11 15:37 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-09 10:25 Andre Vehreschild
2015-07-09 17:50 ` Steve Kargl
2015-07-09 18:59   ` Andre Vehreschild
2015-07-09 19:41     ` Steve Kargl
2015-07-10  9:44       ` Andre Vehreschild
2015-07-10 13:41         ` Steve Kargl
2015-07-10 16:20           ` Mikael Morin
2015-07-10 16:44             ` Andre Vehreschild
2015-07-10 18:57             ` Steve Kargl
2015-07-11 10:37               ` Andre Vehreschild
2015-07-11 11:06                 ` Mikael Morin
2015-07-11 11:58                 ` Dan Nagle
2015-07-13 17:27                   ` Mike Stump
2015-07-11 10:54               ` Mikael Morin
2015-07-11 10:58                 ` Andre Vehreschild
2015-07-11 15:37                 ` Steve Kargl [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150711153716.GA10645@troutmask.apl.washington.edu \
    --to=sgk@troutmask.apl.washington.edu \
    --cc=fortran@gcc.gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=mikael.morin@sfr.fr \
    --cc=paul.richard.thomas@gmail.com \
    --cc=vehre@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).