This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix EQUIVALENCE vs. SAVE (PR fortran/18518)
- From: Tobias Schlüter <tobias dot schlueter at physik dot uni-muenchen dot de>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org, fortran at gcc dot gnu dot org
- Date: Tue, 27 Sep 2005 23:40:20 +0200
- Subject: Re: [PATCH] Fix EQUIVALENCE vs. SAVE (PR fortran/18518)
- References: <20050927212050.GB1020@devserv.devel.redhat.com>
Jakub Jelinek wrote:
> I couldn't find details on SAVE and EQUIVALENCE coexistence in the standard,
> but g77 certainly saved equivalences if any of the equivalenced variables
> were saved.
> Is this ok for HEAD/4.0 (tested on x86_64-linux)?
Yes. I didn't find any specifics in the standard, so I think you're doing the
right thing. It's weird that something like
save i, j
equivalence (i,j)
is legal. It's not completely surprising, because
save
equivalence (i,j)
is allowed, but still, the former example contains redundant information.
Thanks,
- Tobi
> 2005-09-27 Jakub Jelinek <jakub@redhat.com>
>
> PR fortran/18518
> * trans-common.c (build_equiv_decl): Add IS_SAVED argument.
> If it is true, set TREE_STATIC on the decl.
> (create_common): If any symbol in equivalence has SAVE attribute,
> pass true as last argument to build_equiv_decl.
>
> * gfortran.fortran-torture/execute/save_2.f90: New decl.