On 24/06/2019 09:19, Bernhard Reutner-Fischer wrote:
On Fri, 21 Jun 2019 07:10:11 -0700
Steve Kargl <s...@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 <l...@redhat.com>

Please review.

ChangeLogs:

gcc/fortran

      Jeff Law  <l...@redhat.com>
      Mark Eggleston  <mark.eggles...@codethink.com>

      * gfortran.h: Add check_conflict declaration.
This is wrong.  By convention a routine that is not static
has the gfc_ prefix.

Furthermore doesn't this export indicate that you're committing a
layering violation somehow?
Don't know what this means.

      * 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.

      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,

I didn't write the original of this patch, I made a minor change and wrote the test cases. The main body of the work was done by Jeff Law  <l...@redhat.com>. I'll have a look at gfc_copy_attr to see if better code can be used.

I have inherited the responsibility of getting this patch upstreamed, any help in achieving this will be appreciated.

Mark

--
https://www.codethink.co.uk/privacy.html

Reply via email to