From: Jeff Law <law@redhat.com>
To: Mark Eggleston <mark.eggleston@codethink.co.uk>,
Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>,
Steve Kargl <sgk@troutmask.apl.washington.edu>
Cc: fortran <fortran@gcc.gnu.org>, gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] Automatics in equivalence statements
Date: Tue, 23 Jul 2019 00:23:00 -0000 [thread overview]
Message-ID: <dc118b01-e478-f16b-a2e7-a90016d2e7b5@redhat.com> (raw)
In-Reply-To: <8d987cfc-b9ff-491c-3453-eb8d1d8f3936@codethink.co.uk>
On 7/1/19 3:35 AM, Mark Eggleston wrote:
>
> On 25/06/2019 14:17, Mark Eggleston wrote:
>>
>> On 25/06/2019 00:17, Jeff Law wrote:
>>> On 6/24/19 2:19 AM, Bernhard Reutner-Fischer wrote:
>>>> On Fri, 21 Jun 2019 07:10:11 -0700
>>>> Steve Kargl <sgk@troutmask.apl.washington.edu> wrote:
>>>>
>>>>> On Fri, Jun 21, 2019 at 02:31:51PM +0100, Mark Eggleston wrote:
>>>>>> Currently variables with the AUTOMATIC attribute can not appear in an
>>>>>> EQUIVALENCE statement. However its counterpart, STATIC, can be
>>>>>> used in
>>>>>> an EQUIVALENCE statement.
>>>>>>
>>>>>> Where there is a clear conflict in the attributes of variables in an
>>>>>> EQUIVALENCE statement an error message will be issued as is currently
>>>>>> the case.
>>>>>>
>>>>>> If there is no conflict e.g. a variable with a AUTOMATIC attribute
>>>>>> and a
>>>>>> variable(s) without attributes all variables in the EQUIVALENCE will
>>>>>> become AUTOMATIC.
>>>>>>
>>>>>> Note: most of this patch was written by Jeff Law <law@redhat.com>
>>>>>>
>>>>>> Please review.
>>>>>>
>>>>>> ChangeLogs:
>>>>>>
>>>>>> gcc/fortran
>>>>>>
>>>>>>     Jeff Law <law@redhat.com>
>>>>>>     Mark Eggleston <mark.eggleston@codethink.com>
>>>>>>
>>>>>> Â Â Â Â * gfortran.h: Add check_conflict declaration.
>>>>> This is wrong. By convention a routine that is not static
>>>>> has the gfc_ prefix.
> Updated the code to use gfc_check_conflict instead.
>>>>>
>>>> Furthermore doesn't this export indicate that you're committing a
>>>> layering violation somehow?
>>> Possibly. I'm the original author, but my experience in our fortran
>>> front-end is minimal. I fully expected this patch to need some
>>> tweaking.
>>>
>>> We certainly don't want to recreate all the checking that's done in
>>> check_conflict. We just need to defer it to a later point --
>>> find_equivalence seemed like a good point since we've got the full
>>> equivalence list handy and can accumulate the attributes across the
>>> entire list, then check for conflicts.
>>>
>>> If there's a concrete place where you think we should be doing this, I'm
>>> all ears.
>>>
>> Any suggestions will be appreciate.
>>>>> Â Â Â Â * symbol.c (check_conflict): Remove automatic in equivalence
>>>>> conflict
>>>>> Â Â Â Â check.
>>>>> Â Â Â Â * symbol.c (save_symbol): Add check for in equivalence to
>>>>> stop the
>>>>> Â Â Â Â the save attribute being added.
>>>>> Â Â Â Â * trans-common.c (build_equiv_decl): Add is_auto parameter and
>>>>> Â Â Â Â add !is_auto to condition where TREE_STATIC (decl) is set.
>>>>> Â Â Â Â * trans-common.c (build_equiv_decl): Add local variable is_auto,
>>>>> Â Â Â Â set it true if an atomatic attribute is encountered in the
>>>>> variable
>>>> atomatic? I read atomic but you mean automatic.
>>> Yes.
>>>
>>>>>     list. Call build_equiv_decl with is_auto as an additional
>>>>> parameter.
>>>>> Â Â Â Â flag_dec_format_defaults is enabled.
>>>>> Â Â Â Â * trans-common.c (accumulate_equivalence_attributes) : New
>>>>> subroutine.
>>>>> Â Â Â Â * trans-common.c (find_equivalence) : New local variable
>>>>> dummy_symbol,
>>>>> Â Â Â Â accumulated equivalence attributes from each symbol then
>>>>> check for
>>>>> Â Â Â Â conflicts.
>>>> I'm just curious why you don't gfc_copy_attr for the most part of
>>>> accumulate_equivalence_attributes?
>>>> thanks,
>>> Simply didn't know about it. It could probably significantly simplify
>>> the accumulation of attributes step.
>> Using gfc_copy_attr causes a great many "Duplicate DIMENSION attribute
>> specified at (1)" errors. This is because there is a great deal of
>> checking done instead of simply keeping track of the attributes used
>> which is all that is required for determining whether there is a
>> conflict in the equivalence statement.
>>
>> Also, the final section of accumulate_equivalence_attributes involving
>> SAVE, INTENT and ACCESS look suspect to me. I'll check and update the
>> patch if necessary.
>
> No need to check intent as there is already a conflict with DUMMY and
> INTENT can only be present for dummy variables.
>
> Please find attached an updated patch. Change logs:
>
> gcc/fortran
>
>    Jeff Law <law@redhat.com>
>    Mark Eggleston <mark.eggleston@codethink.com>
>
> Â Â Â * gfortran.h: Add gfc_check_conflict declaration.
> Â Â Â * symbol.c (check_conflict): Rename cfg_check_conflict and remove
> Â Â Â static.
> Â Â Â * symbol.c (cfg_check_conflict): Remove automatic in equivalence
> Â Â Â conflict check.
> Â Â Â * symbol.c (save_symbol): Add check for in equivalence to stop the
> Â Â Â the save attribute being added.
> Â Â Â * trans-common.c (build_equiv_decl): Add is_auto parameter and
> Â Â Â add !is_auto to condition where TREE_STATIC (decl) is set.
> Â Â Â * trans-common.c (build_equiv_decl): Add local variable is_auto,
> Â Â Â set it true if an atomatic attribute is encountered in the variable
>    list. Call build_equiv_decl with is_auto as an additional parameter.
> Â Â Â flag_dec_format_defaults is enabled.
> Â Â Â * trans-common.c (accumulate_equivalence_attributes) : New subroutine.
> Â Â Â * trans-common.c (find_equivalence) : New local variable dummy_symbol,
> Â Â Â accumulated equivalence attributes from each symbol then check for
> Â Â Â conflicts.
>
> gcc/testsuite
>
> Â Â Â Mark Eggleston <mark.eggleston@codethink.com>
>
> Â Â Â * gfortran.dg/auto_in_equiv_1.f90: New test.
> Â Â Â * gfortran.dg/auto_in_equiv_2.f90: New test.
> Â Â Â * gfortran.dg/auto_in_equiv_3.f90: New test.
>
> If the updated patch is acceptable, please can someone with the
> privileges commit the patch.
[ ... ]
BTW, I've put the latest version of this into my tester. I don't expect
to see any problems, of course.
Jeff
next prev parent reply other threads:[~2019-07-23 0:19 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-21 13:31 Mark Eggleston
2019-06-21 14:10 ` Steve Kargl
2019-06-24 8:19 ` Bernhard Reutner-Fischer
2019-06-24 13:47 ` Mark Eggleston
2019-06-24 23:18 ` Jeff Law
2019-06-25 13:17 ` Mark Eggleston
2019-07-01 9:35 ` Mark Eggleston
2019-07-08 13:51 ` **ping** " Mark Eggleston
2019-07-10 10:07 ` Mark Eggleston
2019-07-23 0:23 ` Jeff Law [this message]
[not found] <fe0dee5c-e2d7-5e69-94e4-0a807f9f0886@redhat.com>
[not found] ` <20190723013806.GA12299@troutmask.apl.washington.edu>
[not found] ` <3497ca30-0bd6-ac0a-0069-098f25de44d3@redhat.com>
[not found] ` <20190723023614.GA12520@troutmask.apl.washington.edu>
[not found] ` <cd31af75-cc5a-3cab-1993-21f431a6f09f@redhat.com>
2019-08-14 8:49 ` Mark Eggleston
2019-08-14 17:24 ` Jeff Law
2019-08-16 15:51 ` Mark Eggleston
2019-09-28 20:33 ` Andreas Schwab
2019-09-30 10:25 ` Jakub Jelinek
2019-10-02 13:39 ` Mark Eggleston
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=dc118b01-e478-f16b-a2e7-a90016d2e7b5@redhat.com \
--to=law@redhat.com \
--cc=fortran@gcc.gnu.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=mark.eggleston@codethink.co.uk \
--cc=rep.dot.nop@gmail.com \
--cc=sgk@troutmask.apl.washington.edu \
/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).