public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "burnus at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/40440] Automatic deallocation component of DT function return value
Date: Thu, 18 Jun 2009 14:45:00 -0000 [thread overview]
Message-ID: <20090618144502.8410.qmail@sourceware.org> (raw)
In-Reply-To: <bug-40440-15192@http.gcc.gnu.org/bugzilla/>
------- Comment #8 from burnus at gcc dot gnu dot org 2009-06-18 14:45 -------
> I am not sure that your testcase should be allowed at all! I am not sure that
> I understand what it means.
I think it is valid and not different from:
integer, pointer :: ptr
allocate(ptr)
ptr = 5
call f(ptr)
where you don't pass the pointer "ptr" to "f" but the target of pointer "f".
My example is invalid, however, as I never set the return value. Add
allocate(func)
if you want. That should make it valid as one now has a pointer target. But it
shouldn't matter regarding the bug. (The not-needed "target" attribute can also
be removed.)
Regarding the big program:
function f(tgt)
integer,target :: tgt
f => tgt
end function f
I am not sure that using "tgt" as return value is valid; I think as soon as one
leaves "f", the "tgt" dummy ceases to exist, which would make it invalid. But I
might be wrong and it is valid. In practice, it should work if the actual
argument is either in static memory or one uses the pointer while the target is
still on the stack (or on the heap).
(If one wants to check the validity, one needs to read all about pointers,
targets and argument association - and maybe scope - in the standard.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40440
next prev parent reply other threads:[~2009-06-18 14:45 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-14 21:50 [Bug fortran/40440] New: [4.5.0 Regression] Garbage or segmentation fault in allocatable array derived type structures juergen dot reuter at desy dot de
2009-06-14 22:14 ` [Bug fortran/40440] " kargl at gcc dot gnu dot org
2009-06-14 22:19 ` juergen dot reuter at desy dot de
2009-06-15 8:52 ` [Bug fortran/40440] [4.4/4.5 " burnus at gcc dot gnu dot org
2009-06-15 12:17 ` burnus at gcc dot gnu dot org
2009-06-15 13:09 ` [Bug fortran/40440] Automatic deallocation component of DT function return value burnus at gcc dot gnu dot org
2009-06-18 9:44 ` pault at gcc dot gnu dot org
2009-06-18 13:33 ` juergen dot reuter at desy dot de
2009-06-18 14:45 ` burnus at gcc dot gnu dot org [this message]
2009-06-18 15:18 ` burnus at gcc dot gnu dot org
2009-06-18 20:52 ` pault at gcc dot gnu dot org
2009-06-18 21:15 ` burnus at gcc dot gnu dot org
2009-06-19 0:20 ` pault at gcc dot gnu dot org
2009-06-19 21:58 ` pault at gcc dot gnu dot org
2009-07-09 19:28 ` pault at gcc dot gnu dot org
2009-07-09 19:29 ` pault at gcc dot gnu dot org
2009-10-11 12:20 ` pault at gcc dot gnu dot org
2009-10-11 12:26 ` pault at gcc dot gnu dot org
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=20090618144502.8410.qmail@sourceware.org \
--to=gcc-bugzilla@gcc.gnu.org \
--cc=gcc-bugs@gcc.gnu.org \
/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).