From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.smtpout.orange.fr (smtp-14.smtpout.orange.fr [80.12.242.14]) by sourceware.org (Postfix) with ESMTPS id F28F33858D32; Sun, 21 Jan 2024 10:51:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F28F33858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=orange.fr Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=orange.fr ARC-Filter: OpenARC Filter v1.0.0 sourceware.org F28F33858D32 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=80.12.242.14 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705834267; cv=none; b=wihq5uy34ZnkTMIX4oLV3jO+iaD4JbbiCfPBD8hpdlVAgzBfTcaq9/EyvnvQGgWP5A+KvscC0ghRat/oyIbkerc+Ptur16P6YCqTQNp6E8DAxoaKVbHRxrBFWJ0GCDgMfnc/QHG51znwqgc7BRXpBl6R0r3TWOW4fhywr+tWEp0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705834267; c=relaxed/simple; bh=HtDFsXgBeX5AoibAm5lxDtQUm2WlnZOc+1rwpwx8wek=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=WO9v7Pzl073uBFtZAQKH1uFS8y01VPBBBa8cZlrqitM/5NrLbZ6c8Ap/Utskd47IQgYVTm3ZeUwnuenWsOdqVTV0lD1WZOLeQ3MxCnTphJC+3UJ6dN7/yqSecblIjpLi/3SpxQEggqB9Cfz680HIBzJsHN8VdlLVD7eQitKC+/U= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from [192.168.1.16] ([86.215.161.51]) by smtp.orange.fr with ESMTPA id RVPgrfyaLgeksRVPrroJkE; Sun, 21 Jan 2024 11:51:03 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1705834263; bh=J2jbO+iIyIw+9CVbet4T5tsYK5InK7HlxOe8p66xrWY=; h=Date:Subject:To:References:From:In-Reply-To; b=H5Ztnwb+uqIowv+AN/1A/pCZRnoY37HrXdpC9vPXk43eYrQiL39kQCQmPJnmAkYQm bTPenyE6KkfRkx3CxeRjVYNpoYXgtCWOwInc6BvzkjYsfjWw9kA6xnNu2mcGGqoiQx 68Yr/oazIJq1IAKhhdpMSU6G/pxV6hfZroxZ7g/3ps8s3X2OK13pXrUkZym5dMEMvu IiO07VQ3K3NRkxCU7mvYk+foJYMHfwRuyq7m3a8VedwO+vzozRpKrT6RqH9tblBvHl qRZ1pchHLMOr98z4un2IQvfINZDi2DfHo1bZD15oYCFxwTDyws8UU8tN9UI7d28Z/v GmSsLiuKzpgMg== X-ME-Helo: [192.168.1.16] X-ME-Auth: bW9yaW4tbWlrYWVsQG9yYW5nZS5mcg== X-ME-Date: Sun, 21 Jan 2024 11:51:03 +0100 X-ME-IP: 86.215.161.51 Message-ID: <818b7f17-2d2d-476d-af31-14a0702f53bf@orange.fr> Date: Sun, 21 Jan 2024 11:50:51 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Fortran: passing of optional scalar arguments with VALUE attribute [PR113377] To: Harald Anlauf , fortran , gcc-patches References: Content-Language: fr From: Mikael Morin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-11.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hello, Le 20/01/2024 à 22:58, Harald Anlauf a écrit : > Dear all, > > here's the first part of an attempt to fix issues with optional > dummy arguments as actual arguments to optional dummies. This patch > rectifies the case of scalar dummies with the VALUE attribute, > which in gfortran's argument passing convention are passed on the > stack when they are of intrinsic type, and have a hidden variable > for the presence status. > > The testcase tries to cover valid combinations of actual and dummy > argument. A few tests that are not standard-conforming but would > still work with gfortran (due to the argument passing convention) > are left there but commented out with a pointer to the standard > (thanks, Mikael!). > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > Well, not yet. > > diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc > index 9dd1f4086f4..2f47a75955c 100644 > --- a/gcc/fortran/trans-expr.cc > +++ b/gcc/fortran/trans-expr.cc > @@ -6526,6 +6526,10 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym, > gfc_init_se (&argse, NULL); > argse.want_pointer = 1; > gfc_conv_expr (&argse, e); > + if (e->symtree->n.sym->attr.dummy > + && POINTER_TYPE_P (TREE_TYPE (argse.expr))) > + argse.expr = gfc_build_addr_expr (NULL_TREE, > + argse.expr); The second part of the condition looks superfluous: if argse.want_pointer was set, we can expect to get a pointer result. But more important, I don't understand the need for this whole part, the new test seems to pass without it. And here is an example that regresses with it. program p type :: t integer, allocatable :: c end type call s2(t()) contains subroutine s1(a) integer, value, optional :: a if (present(a)) stop 1 end subroutine subroutine s2(a) type(t) :: a call s1(a%c) end subroutine end program > cond = fold_convert (TREE_TYPE (argse.expr), > null_pointer_node); > cond = fold_build2_loc (input_location, NE_EXPR, > @@ -7256,6 +7260,7 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym, > && e->symtree->n.sym->attr.optional > && (((e->rank != 0 && elemental_proc) > || e->representation.length || e->ts.type == BT_CHARACTER > + || (e->rank == 0 && e->symtree->n.sym->attr.value) This looks good. > || (e->rank != 0 > && (fsym == NULL > || (fsym->as > diff --git a/gcc/testsuite/gfortran.dg/optional_absent_9.f90 b/gcc/testsuite/gfortran.dg/optional_absent_9.f90 > new file mode 100644 > index 00000000000..495a6c00d7f > --- /dev/null > +++ b/gcc/testsuite/gfortran.dg/optional_absent_9.f90 > @@ -0,0 +1,324 @@ > +! { dg-do run } > +! PR fortran/113377 > +! > +! Test passing of missing optional scalar dummies of intrinsic type > + > +module m_int > + implicit none > +contains > + subroutine test_int () > + integer :: k = 1 > + call one (k) > + call one_val (k) > + call one_all (k) > + call one_ptr (k) > + end > + > + subroutine one (i, j) > + integer, intent(in) :: i > + integer ,optional :: j > + integer, allocatable :: aa > + integer, pointer :: pp => NULL() > + if (present (j)) error stop "j is present" > + call two (i, j) > + call two_val (i, j) > + call two (i, aa) > + call two (i, pp) To be complete, you could check two_val(i, aa) and two_val(i, pp) as well. Both seem to pass already without the patch, so not absolutely needed. Your call. > + end > + I think the patch is OK with the first trans-expr.cc hunk removed. Thanks. Mikael