public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "anlauf at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/109500] SIGABRT when calling a function that returns an unallocated value
Date: Mon, 17 Apr 2023 20:20:53 +0000	[thread overview]
Message-ID: <bug-109500-4-ecepDZnQcm@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-109500-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500

--- Comment #11 from anlauf at gcc dot gnu.org ---
(In reply to Leandro Lupori from comment #10)
> Wouldn't it be better to turn this into a warning?
> 
> Although using the result of a function as an allocatable argument doesn't
> conform with Fortran standards, it has been supported by gfortran for quite
> some time. This change may break existing code.

Well, then the existing code seems to violate the Fortran standard,
and it seems it was a bug that gfortran accepted it silently.

The code in comment#0 seems to be silently accepted by the Intel classic
Fortran compiler (ifort), but crashes the new one (ifx).  I've asked
Intel on their opinion.

I've also learned that the same happens for the case of passing f() to
a subroutine, as in:

  call s(f())
[...]
contains
  subroutine s(p)
    integer, allocatable :: p
  end subroutine s
[...]

This is rejected by NAG and also Nvidia and AMD flang, and crashes ifx.

Do you have anybody else supporting the view that the code in question
should work as an extension?

As I said before, there are legal ways to return from a procedure with
the result variable either allocated or not, but this cannot be a function.

  parent reply	other threads:[~2023-04-17 20:20 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-13 13:24 [Bug fortran/109500] New: " leandro.lupori at linaro dot org
2023-04-13 15:05 ` [Bug fortran/109500] " kargl at gcc dot gnu.org
2023-04-13 17:06 ` leandro.lupori at linaro dot org
2023-04-13 18:12 ` kargl at gcc dot gnu.org
2023-04-13 18:32 ` anlauf at gcc dot gnu.org
2023-04-13 19:44 ` leandro.lupori at linaro dot org
2023-04-13 21:28 ` anlauf at gcc dot gnu.org
2023-04-13 21:34 ` sgk at troutmask dot apl.washington.edu
2023-04-14 19:24 ` anlauf at gcc dot gnu.org
2023-04-16 19:42 ` anlauf at gcc dot gnu.org
2023-04-17 12:14 ` leandro.lupori at linaro dot org
2023-04-17 20:20 ` anlauf at gcc dot gnu.org [this message]
2023-04-19 17:25 ` leandro.lupori at linaro dot org
2023-04-19 19:02 ` sgk at troutmask dot apl.washington.edu
2023-04-19 19:06 ` anlauf at gcc dot gnu.org
2023-04-19 19:15 ` anlauf at gcc dot gnu.org
2023-04-19 19:42 ` sgk at troutmask dot apl.washington.edu
2023-04-19 21:03 ` anlauf at gcc dot gnu.org
2023-04-20  5:22 ` kargl at gcc dot gnu.org
2023-04-20 16:29 ` sgk at troutmask dot apl.washington.edu
2023-04-20 19:02 ` anlauf at gcc dot gnu.org
2023-04-20 19:04 ` anlauf at gcc dot gnu.org
2023-04-20 20:02 ` anlauf at gcc dot gnu.org
2023-04-22 18:50 ` cvs-commit at gcc dot gnu.org
2023-04-23 18:59 ` anlauf at gcc dot gnu.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=bug-109500-4-ecepDZnQcm@http.gcc.gnu.org/bugzilla/ \
    --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).