public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
From: Harald Anlauf <anlauf@gmx.de>
To: Mikael Morin <mikael@gcc.gnu.org>,
	fortran@gcc.gnu.org, gcc-patches@gcc.gnu.org
Subject: Re: [PATCH v2 2/2] fortran: Fix specification expression error with dummy procedures [PR111781]
Date: Sun, 17 Mar 2024 21:57:37 +0100	[thread overview]
Message-ID: <5d5b9838-cc2a-49d0-8746-0a054dc53af8@gmx.de> (raw)
In-Reply-To: <20240317165749.1003825-3-mikael@gcc.gnu.org>

Hi Mikael,

thanks for the patch!

Regarding the first part of the patch, I think that fixing bad testcases
can be done at any time.  Retaining identified, broken testcases means
that one may hit bogus regressions, hindering progress.

The second part of the patch looks at first glance fine to me.  And as
the patch changes less than its size suggests, in particular due to
code refactoring, I don't see a reason to postpone it to stage 1.

(On the contrary, deferring it to stage 1 might make future backports
from 15 for later patches on top of that code harder.
This is my opinion, and others might see this differently.)

On 3/17/24 17:57, Mikael Morin wrote:
> 	* expr.cc (check_restricted): Remove the case where symbol is dummy
> 	and declared in the current ns.  Use gfc_get_spec_ns to get the
> 	right namespace.

Looking at the original and new code, I don't fully understand
that part of the commit message: the changed check comes into play
when the symbol is *not* in_common, ..., a dummy, ...
So technically, we didn't access the (now removed) formal_arg_flag
here in those cases.
Or am I missing something?

> diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
> index 82a642b01f7..0852bc5f493 100644
> --- a/gcc/fortran/expr.cc
> +++ b/gcc/fortran/expr.cc
> @@ -3509,19 +3509,13 @@ check_restricted (gfc_expr *e)
>         if (!check_references (e->ref, &check_restricted))
>   	break;
>
> -      /* gfc_is_formal_arg broadcasts that a formal argument list is being
> -	 processed in resolve.cc(resolve_formal_arglist).  This is done so
> -	 that host associated dummy array indices are accepted (PR23446).
> -	 This mechanism also does the same for the specification expressions
> -	 of array-valued functions.  */
>         if (e->error
>   	    || sym->attr.in_common
>   	    || sym->attr.use_assoc
>   	    || sym->attr.dummy
>   	    || sym->attr.implied_index
>   	    || sym->attr.flavor == FL_PARAMETER
> -	    || is_parent_of_current_ns (sym->ns)
> -	    || (gfc_is_formal_arg () && (sym->ns == gfc_current_ns)))
> +	    || is_parent_of_current_ns (gfc_get_spec_ns (sym)))
>   	{
>   	  t = true;
>   	  break;


> diff --git a/gcc/testsuite/gfortran.dg/spec_expr_8.f90 b/gcc/testsuite/gfortran.dg/spec_expr_8.f90
> new file mode 100644
> index 00000000000..5885810d421
> --- /dev/null
> +++ b/gcc/testsuite/gfortran.dg/spec_expr_8.f90
> @@ -0,0 +1,24 @@
> +! { dg-do compile }
> +!
> +! PR fortran/111781
> +! We used to reject the example below because the dummy procedure g was
> +! setting the current namespace without properly restoring it, which broke
> +! the specification expression check for the dimension of A later on.
> +!
> +! Contributed by Markus Vikhamar-Sandberg  <rasmus.vikhamar-sandberg@uit.no>

Is the reporter's first name Markus or Rasmus?


Thanks,
Harald


  reply	other threads:[~2024-03-17 20:57 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-17 16:57 [PATCH v2 0/2] fortran: Fix specification checks [PR111781] Mikael Morin
2024-03-17 16:57 ` [PATCH v2 1/2] testsuite: Declare fortran array bound variables Mikael Morin
2024-03-17 16:57 ` [PATCH v2 2/2] fortran: Fix specification expression error with dummy procedures [PR111781] Mikael Morin
2024-03-17 20:57   ` Harald Anlauf [this message]
2024-03-17 21:39     ` Mikael Morin

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=5d5b9838-cc2a-49d0-8746-0a054dc53af8@gmx.de \
    --to=anlauf@gmx.de \
    --cc=fortran@gcc.gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=mikael@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).