public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
From: Paul Richard Thomas <paul.richard.thomas@gmail.com>
To: Mikael Morin <mikael@gcc.gnu.org>
Cc: fortran@gcc.gnu.org, gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] fortran: Release symbols in reversed order [PR106050]
Date: Tue, 11 Jul 2023 14:13:11 +0100	[thread overview]
Message-ID: <CAGkQGiJHBkWS8x1xQQ2K=06GxFr==H2Vzjc=JhCThfsY+2-tAg@mail.gmail.com> (raw)
In-Reply-To: <20230711120835.2043753-1-mikael@gcc.gnu.org>

Hi Mikhail,

That's more than OK by me.

Thanks for attacking this PR.

I have a couple more of Steve's orphans waiting to be packaged up -
91960 and 104649. I'll submit them this evening.100607 is closed-fixed
and 103796 seems to be fixed.

Regards

Paul

On Tue, 11 Jul 2023 at 13:08, Mikael Morin via Fortran
<fortran@gcc.gnu.org> wrote:
>
> Hello,
>
> I saw the light regarding this PR after Paul posted a comment yesterday.
>
> Regression test in progress on x86_64-pc-linux-gnu.
> I plan to push in the next hours.
>
> Mikael
>
> -- >8 --
>
> Release symbols in reversed order wrt the order they were allocated.
> This fixes an error recovery ICE in the case of a misplaced
> derived type declaration.  Such a declaration creates nested
> symbols, one for the derived type and one for each type parameter,
> which should be immediately released as the declaration is
> rejected.  This breaks if the derived type is released first.
> As the type parameter symbols are in the namespace of the derived
> type, releasing the derived type releases the type parameters, so
> one can't access them after that, even to release them.  Hence,
> the type parameters should be released first.
>
>         PR fortran/106050
>
> gcc/fortran/ChangeLog:
>
>         * symbol.cc (gfc_restore_last_undo_checkpoint): Release symbols
>         in reverse order.
>
> gcc/testsuite/ChangeLog:
>
>         * gfortran.dg/pdt_33.f90: New test.
> ---
>  gcc/fortran/symbol.cc                |  2 +-
>  gcc/testsuite/gfortran.dg/pdt_33.f90 | 15 +++++++++++++++
>  2 files changed, 16 insertions(+), 1 deletion(-)
>  create mode 100644 gcc/testsuite/gfortran.dg/pdt_33.f90
>
> diff --git a/gcc/fortran/symbol.cc b/gcc/fortran/symbol.cc
> index 37a9e8fa0ae..4a71d84b3fe 100644
> --- a/gcc/fortran/symbol.cc
> +++ b/gcc/fortran/symbol.cc
> @@ -3661,7 +3661,7 @@ gfc_restore_last_undo_checkpoint (void)
>    gfc_symbol *p;
>    unsigned i;
>
> -  FOR_EACH_VEC_ELT (latest_undo_chgset->syms, i, p)
> +  FOR_EACH_VEC_ELT_REVERSE (latest_undo_chgset->syms, i, p)
>      {
>        /* Symbol in a common block was new. Or was old and just put in common */
>        if (p->common_block
> diff --git a/gcc/testsuite/gfortran.dg/pdt_33.f90 b/gcc/testsuite/gfortran.dg/pdt_33.f90
> new file mode 100644
> index 00000000000..0521513f2f8
> --- /dev/null
> +++ b/gcc/testsuite/gfortran.dg/pdt_33.f90
> @@ -0,0 +1,15 @@
> +! { dg-do compile }
> +!
> +! PR fortran/106050
> +! The following used to trigger an error recovery ICE by releasing
> +! the symbol T before the symbol K which was leading to releasing
> +! K twice as it's in T's namespace.
> +!
> +! Contributed by G. Steinmetz <gscfq@t-online.de>
> +
> +program p
> +   a = 1
> +   type t(k)                  ! { dg-error "Unexpected derived type declaration" }
> +      integer, kind :: k = 4  ! { dg-error "not allowed outside a TYPE definition" }
> +   end type                   ! { dg-error "Expecting END PROGRAM" }
> +end
> --
> 2.40.1
>


--
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein

      reply	other threads:[~2023-07-11 13:13 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-11 12:08 Mikael Morin
2023-07-11 13:13 ` Paul Richard Thomas [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='CAGkQGiJHBkWS8x1xQQ2K=06GxFr==H2Vzjc=JhCThfsY+2-tAg@mail.gmail.com' \
    --to=paul.richard.thomas@gmail.com \
    --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).