[Bug fortran/52846] [F2008] Support submodules - part 3/3

[Bug fortran/52846] [F2008] Support submodules - part 3/3

[Paul Richard Thomas]

[-- Attachment #1: Type: text/plain, Size: 4528 bytes --]

Dear All,

This is the third and final patch to implement submodules in gfortran.
It is the part that deals with private module entities. Unfortunately,
it is the most invasive and I would either like to have strong support
for it to be committed or a bright idea as to how to do it otherwise.

Since all the private entities in a module have to be transmitted to
their descendant submodules, whilst keeping them hidden from normal
use statements, I have chosen to write the module file as usual and
add a second part that contains the private entities. This latter is
only read when processing submodule statements.

I looked into encrypting the second part but could not find a way to
obtain the compression ratios that gzipping the module file affords,
largely from the repetition of attribute keywords. It was tempting to
reform completely the format of module files such that the symbol tree
is represented in binary format rather than in text. However, being
able to gunzip the files is very helpful from the diagnostic point of
view. Perhaps this is a suitable future upgrade for 6.0.0? That said,
I do not regard it as being high priority nor necessarily useful.

The other significant change is in respect of making module variable,
string length and procedure pointer declarations unconditionally
TREE_PUBLIC, whilst recycling the conditions to set DECL_VISIBILITY to
VISIBILITY_HIDDEN. This was a suggestion from Richard Biener, which
seems to do what is needed in libraries. This affects two existing
testcases: public_private_module_[2,6].f90, where xfails have been
added, where assembler symbols should be optimized away. These tests
can be removed if the above changes prove to be robust and acceptable
but I was reluctant to do this right away.

The rest of the patch is concerned with signaling to module.c that a
submodule statement is being processed.

It does cross my mind that all of this part of the submodule
implementation could be subject to the condition that a compiler
option is set. I am struck by the notion that making private module
entities available to submodules is an unnecessary complication and
that it amounts to be an error in the standard. This is why I am
suggesting the possibility of a specific compiler option.

The new testcase submodule_10.f08 is a near verbatim contribution from
Salvatore Filippone, for which thanks are due.

The remaining tasks are to try to fix PR66762, where submodule_6.f08
fails with -fto, and to update the documentation.

Bootstraps and regtests on FC21/x86_64 - OK for trunk?

Cheers

Paul

2015-07-23  Paul Thomas  <pault@gcc.gnu.org>

    PR fortran/52846
    * match.h : Add bool argument to gfc_use_modules so that it can
    signal to module.c that a submodule statement is being
    processed.
    * module.c (read_module): Add new module_locus, 'end_module'.
    Set it at the end of the public part of the module file. Then go
    there once the public part has been processed, ready to read
    the private part of the module file.
    (check_access): Change original to 'check_access1' and call it
    from 'check_access'. This latter inverts the result, according
    to whether or not static 'invert_access' is true.
    (gfc_dump_module): Write the public part of the module file as
    before and then follow it with the private part, obtained by
    setting 'invert_access' true. Once done, this is reset.
    (gfc_use_module): Read the public part of the module file. If
    this is a submodule and static 'submodule_stmt' is true, then
    read the private part. This permits the private part of module
    files to be respected with conventional use statements.
    (gfc_use_modules): 'submodule_stmt' set true if the ancestor
    module file is being used in processing submodule statement.
    * parse.c (use_modules): Introduce 'using_ancestor_modules' as
    a boolean argument. All calls set this argument false, except;
    (parse_module): Call use_modules with 'using_ancestor_modules'
    set true to signal the processing of a submodule statement.
    * trans-decl.c (gfc_finish_var_decl, gfc_build_qualified_array,
    get_proc_pointer_decl): Set TREE_PUBLIC unconditionally and use
    the conditions to set DECL_VISIBILITY as hidden and to set as
    true DECL_VISIBILITY_SPECIFIED.

2015-07-23  Paul Thomas  <pault@gcc.gnu.org>

    PR fortran/52846

    * gfortran.dg/public_private_module_2.f90: Add two XFAILS.
    * gfortran.dg/public_private_module_6.f90: Add an XFAIL.
    * gfortran.dg/submodule_10.f08: New test

[-- Attachment #2: private_final.diff --]
[-- Type: text/plain, Size: 18767 bytes --]

Index: gcc/fortran/match.h
===================================================================
*** gcc/fortran/match.h	(revision 226054)
--- gcc/fortran/match.h	(working copy)
*************** match gfc_match_expr (gfc_expr **);
*** 293,299 ****
  /* module.c.  */
  match gfc_match_use (void);
  match gfc_match_submodule (void);
! void gfc_use_modules (void);
  
  #endif  /* GFC_MATCH_H  */
  
--- 293,299 ----
  /* module.c.  */
  match gfc_match_use (void);
  match gfc_match_submodule (void);
! void gfc_use_modules (bool);
  
  #endif  /* GFC_MATCH_H  */
  
Index: gcc/fortran/module.c
===================================================================
*** gcc/fortran/module.c	(revision 226054)
--- gcc/fortran/module.c	(working copy)
*************** check_for_ambiguous (gfc_symtree *st, po
*** 4942,4948 ****
  static void
  read_module (void)
  {
!   module_locus operator_interfaces, user_operators, omp_udrs;
    const char *p;
    char name[GFC_MAX_SYMBOL_LEN + 1];
    int i;
--- 4942,4948 ----
  static void
  read_module (void)
  {
!   module_locus operator_interfaces, user_operators, omp_udrs, end_module;
    const char *p;
    char name[GFC_MAX_SYMBOL_LEN + 1];
    int i;
*************** read_module (void)
*** 5192,5197 ****
--- 5192,5198 ----
      }
  
    mio_rparen ();
+   get_module_locus (&end_module);
  
    /* Load intrinsic operator interfaces.  */
    set_module_locus (&operator_interfaces);
*************** read_module (void)
*** 5274,5279 ****
--- 5275,5284 ----
       to hidden symbols.  */
  
    read_cleanup (pi_root);
+ 
+   /* Go to the end so that we are ready to read the private entities
+      for submodules.  */
+   set_module_locus (&end_module);
  }
  
  
*************** read_module (void)
*** 5282,5290 ****
     element is declared as PUBLIC, then it is public; if declared 
     PRIVATE, then private, and otherwise it is public unless the default
     access in this context has been declared PRIVATE.  */
  
  static bool
! check_access (gfc_access specific_access, gfc_access default_access)
  {
    if (specific_access == ACCESS_PUBLIC)
      return TRUE;
--- 5287,5296 ----
     element is declared as PUBLIC, then it is public; if declared 
     PRIVATE, then private, and otherwise it is public unless the default
     access in this context has been declared PRIVATE.  */
+ static bool invert_access = false;
  
  static bool
! check_access1 (gfc_access specific_access, gfc_access default_access)
  {
    if (specific_access == ACCESS_PUBLIC)
      return TRUE;
*************** check_access (gfc_access specific_access
*** 5298,5303 ****
--- 5304,5320 ----
  }
  
  
+ static bool
+ check_access (gfc_access specific_access, gfc_access default_access)
+ {
+   bool res;
+   res = check_access1 (specific_access, default_access);
+   if (invert_access)
+     res = res ? false : true;
+   return res;
+ }
+ 
+ 
  bool
  gfc_check_symbol_access (gfc_symbol *sym)
  {
*************** gfc_dump_module (const char *name, int d
*** 6024,6035 ****
    /* Write the module itself.  */
    iomode = IO_OUTPUT;
  
    init_pi_tree ();
- 
    write_module ();
  
    free_pi_tree (pi_root);
    pi_root = NULL;
  
    write_char ('\n');
  
--- 6041,6061 ----
    /* Write the module itself.  */
    iomode = IO_OUTPUT;
  
+   /* Write the public part of the module.  */
    init_pi_tree ();
    write_module ();
+   free_pi_tree (pi_root);
+   pi_root = NULL;
  
+   /* Now write the private part for submodules.  */
+   write_char ('\n');
+   write_char ('\n');
+   init_pi_tree ();
+   invert_access = true;
+   write_module ();
    free_pi_tree (pi_root);
    pi_root = NULL;
+   invert_access = false;
  
    write_char ('\n');
  
*************** use_iso_fortran_env_module (void)
*** 6732,6737 ****
--- 6758,6764 ----
  
  
  /* Process a USE directive.  */
+ static bool submodule_stmt;
  
  static void
  gfc_use_module (gfc_use_list *module)
*************** gfc_use_module (gfc_use_list *module)
*** 6888,6903 ****
        gfc_fatal_error ("Can't USE the same %smodule we're building!",
  		       p->state == COMP_SUBMODULE ? "sub" : "");
  
    init_pi_tree ();
    init_true_name_tree ();
- 
    read_module ();
- 
    free_true_name (true_name_root);
    true_name_root = NULL;
  
    free_pi_tree (pi_root);
    pi_root = NULL;
  
    XDELETEVEC (module_content);
    module_content = NULL;
--- 6915,6941 ----
        gfc_fatal_error ("Can't USE the same %smodule we're building!",
  		       p->state == COMP_SUBMODULE ? "sub" : "");
  
+   /* Do the normal module read.  */
    init_pi_tree ();
    init_true_name_tree ();
    read_module ();
    free_true_name (true_name_root);
    true_name_root = NULL;
+   free_pi_tree (pi_root);
+   pi_root = NULL;
  
+   /* Read the private entities into submodules.  */
+   if (gfc_state_stack->state == COMP_SUBMODULE
+       && submodule_stmt)
+     {
+       init_pi_tree ();
+       init_true_name_tree ();
+       read_module ();
+       free_true_name (true_name_root);
+       true_name_root = NULL;
    free_pi_tree (pi_root);
    pi_root = NULL;
+     }
  
    XDELETEVEC (module_content);
    module_content = NULL;
*************** rename_list_remove_duplicate (gfc_use_re
*** 6936,6948 ****
  }
  
  
! /* Process all USE directives.  */
  
  void
! gfc_use_modules (void)
  {
    gfc_use_list *next, *seek, *last;
  
    for (next = module_list; next; next = next->next)
      {
        bool non_intrinsic = next->non_intrinsic;
--- 6974,6990 ----
  }
  
  
! /* Process all USE directives. 'using_ancestor_modules' flags up that
!    the SUBMODULE statement is being processed and so all objects that
!    are PRIVATE in the ancestor module must be read.  */
  
  void
! gfc_use_modules (bool using_ancestor_modules)
  {
    gfc_use_list *next, *seek, *last;
  
+   submodule_stmt = using_ancestor_modules;
+ 
    for (next = module_list; next; next = next->next)
      {
        bool non_intrinsic = next->non_intrinsic;
Index: gcc/fortran/parse.c
===================================================================
*** gcc/fortran/parse.c	(revision 226054)
--- gcc/fortran/parse.c	(working copy)
*************** match_word_omp_simd (const char *str, ma
*** 103,118 ****
  }
  
  
! /* Load symbols from all USE statements encountered in this scoping unit.  */
  
  static void
! use_modules (void)
  {
    gfc_error_buffer old_error;
  
    gfc_push_error (&old_error);
    gfc_buffer_error (false);
!   gfc_use_modules ();
    gfc_buffer_error (true);
    gfc_pop_error (&old_error);
    gfc_commit_symbols ();
--- 103,121 ----
  }
  
  
! /* Load symbols from all USE statements encountered in this scoping unit.
!    'using_ancestor_modules' flags up that the SUBMODULE statement is
!    being processed and so all objects that are PRIVATE in the ancestor
!    module must be read.  */
  
  static void
! use_modules (bool using_ancestor_modules)
  {
    gfc_error_buffer old_error;
  
    gfc_push_error (&old_error);
    gfc_buffer_error (false);
!   gfc_use_modules (using_ancestor_modules);
    gfc_buffer_error (true);
    gfc_pop_error (&old_error);
    gfc_commit_symbols ();
*************** decode_specification_statement (void)
*** 167,173 ****
      {
        undo_new_statement ();
        if (last_was_use_stmt)
! 	use_modules ();
      }
  
    match ("import", gfc_match_import, ST_IMPORT);
--- 170,176 ----
      {
        undo_new_statement ();
        if (last_was_use_stmt)
! 	use_modules (false);
      }
  
    match ("import", gfc_match_import, ST_IMPORT);
*************** decode_statement (void)
*** 328,334 ****
      }
  
    if (last_was_use_stmt)
!     use_modules ();
  
    /* Try matching a data declaration or function declaration. The
        input "REALFUNCTIONA(N)" can mean several things in different
--- 331,337 ----
      }
  
    if (last_was_use_stmt)
!     use_modules (false);
  
    /* Try matching a data declaration or function declaration. The
        input "REALFUNCTIONA(N)" can mean several things in different
*************** verify_token_free (const char* token, in
*** 923,929 ****
    gcc_assert (gfc_is_whitespace(c));
    gfc_gobble_whitespace ();
    if (last_was_use_stmt)
!     use_modules ();
  }
  
  /* Get the next statement in free form source.  */
--- 926,932 ----
    gcc_assert (gfc_is_whitespace(c));
    gfc_gobble_whitespace ();
    if (last_was_use_stmt)
!     use_modules (false);
  }
  
  /* Get the next statement in free form source.  */
*************** verify_token_fixed (const char *token, i
*** 1077,1083 ****
        return false;
      }
    if (last_was_use_stmt)
!     use_modules ();
  
    return true;
  }
--- 1080,1086 ----
        return false;
      }
    if (last_was_use_stmt)
!     use_modules (false);
  
    return true;
  }
*************** parse_module (void)
*** 5321,5327 ****
       inherits and to set (most) of the symbols as host associated.  */
    if (gfc_current_state () == COMP_SUBMODULE)
      {
!       use_modules ();
        gfc_traverse_ns (gfc_current_ns, set_syms_host_assoc);
      }
  
--- 5324,5330 ----
       inherits and to set (most) of the symbols as host associated.  */
    if (gfc_current_state () == COMP_SUBMODULE)
      {
!       use_modules (true);
        gfc_traverse_ns (gfc_current_ns, set_syms_host_assoc);
      }
  
Index: gcc/fortran/trans-decl.c
===================================================================
*** gcc/fortran/trans-decl.c	(revision 226054)
--- gcc/fortran/trans-decl.c	(working copy)
*************** gfc_finish_var_decl (tree decl, gfc_symb
*** 596,601 ****
--- 596,606 ----
  	 both, of course.) (J3/04-007, section 15.3).  */
        TREE_PUBLIC(decl) = 1;
        DECL_COMMON(decl) = 1;
+       if (sym->attr.access == ACCESS_PRIVATE && !sym->attr.public_used)
+ 	{
+ 	  DECL_VISIBILITY (decl) = VISIBILITY_HIDDEN;
+ 	  DECL_VISIBILITY_SPECIFIED (decl) = true;
+ 	}
      }
  
    /* If a variable is USE associated, it's always external.  */
*************** gfc_finish_var_decl (tree decl, gfc_symb
*** 609,615 ****
        /* TODO: Don't set sym->module for result or dummy variables.  */
        gcc_assert (current_function_decl == NULL_TREE || sym->result == sym);
  
-       if (sym->attr.access != ACCESS_PRIVATE || sym->attr.public_used)
  	TREE_PUBLIC (decl) = 1;
        TREE_STATIC (decl) = 1;
      }
--- 614,619 ----
*************** gfc_build_qualified_array (tree decl, gf
*** 837,845 ****
  	  else
  	    TREE_STATIC (token) = 1;
  
! 	  if (sym->attr.use_assoc || sym->attr.access != ACCESS_PRIVATE ||
! 	      sym->attr.public_used)
! 	    TREE_PUBLIC (token) = 1;
  	}
        else
  	{
--- 841,853 ----
  	  else
  	    TREE_STATIC (token) = 1;
  
! 	  TREE_PUBLIC (token) = 1;
! 
! 	  if (sym->attr.access == ACCESS_PRIVATE && !sym->attr.public_used)
! 	    {
! 	      DECL_VISIBILITY (token) = VISIBILITY_HIDDEN;
! 	      DECL_VISIBILITY_SPECIFIED (token) = true;
! 	    }
  	}
        else
  	{
*************** get_proc_pointer_decl (gfc_symbol *sym)
*** 1747,1755 ****
    else if (sym->module && sym->ns->proc_name->attr.flavor == FL_MODULE)
      {
        /* This is the declaration of a module variable.  */
!       if (sym->ns->proc_name->attr.flavor == FL_MODULE
! 	  && (sym->attr.access != ACCESS_PRIVATE || sym->attr.public_used))
! 	TREE_PUBLIC (decl) = 1;
        TREE_STATIC (decl) = 1;
      }
  
--- 1755,1766 ----
    else if (sym->module && sym->ns->proc_name->attr.flavor == FL_MODULE)
      {
        /* This is the declaration of a module variable.  */
!       TREE_PUBLIC (decl) = 1;
!       if (sym->attr.access == ACCESS_PRIVATE && !sym->attr.public_used)
! 	{
! 	  DECL_VISIBILITY (decl) = VISIBILITY_HIDDEN;
! 	  DECL_VISIBILITY_SPECIFIED (decl) = true;
! 	}
        TREE_STATIC (decl) = 1;
      }
  
Index: gcc/testsuite/gfortran.dg/public_private_module_2.f90
===================================================================
*** gcc/testsuite/gfortran.dg/public_private_module_2.f90	(revision 226054)
--- gcc/testsuite/gfortran.dg/public_private_module_2.f90	(working copy)
***************
*** 18,29 ****
          integer, bind(C,name='') :: qq
        end module mod
  
        ! { dg-final { scan-assembler "__mod_MOD_aa" } }
!       ! { dg-final { scan-assembler-not "iii" } }
        ! { dg-final { scan-assembler "jj" } }
        ! { dg-final { scan-assembler "lll" } }
        ! { dg-final { scan-assembler-not "kk" } }
!       ! { dg-final { scan-assembler-not "mmmm" } }
        ! { dg-final { scan-assembler "nnn" } }
        ! { dg-final { scan-assembler "oo" } }
        ! { dg-final { scan-assembler "__mod_MOD_qq" } }
--- 18,32 ----
          integer, bind(C,name='') :: qq
        end module mod
  
+ ! The two xfails below have appeared with the introduction of submodules. 'iii' and
+ ! 'mmm' now are TREE_PUBLIC but has DECL_VISIBILITY (decl) = VISIBILITY_HIDDEN set.
+ 
        ! { dg-final { scan-assembler "__mod_MOD_aa" } }
!       ! { dg-final { scan-assembler-not "iii" { xfail *-*-* } } }
        ! { dg-final { scan-assembler "jj" } }
        ! { dg-final { scan-assembler "lll" } }
        ! { dg-final { scan-assembler-not "kk" } }
!       ! { dg-final { scan-assembler-not "mmmm" { xfail *-*-* } } }
        ! { dg-final { scan-assembler "nnn" } }
        ! { dg-final { scan-assembler "oo" } }
        ! { dg-final { scan-assembler "__mod_MOD_qq" } }
Index: gcc/testsuite/gfortran.dg/public_private_module_6.f90
===================================================================
*** gcc/testsuite/gfortran.dg/public_private_module_6.f90	(revision 226054)
--- gcc/testsuite/gfortran.dg/public_private_module_6.f90	(working copy)
*************** module m
*** 11,14 ****
    integer, save :: aaaa
  end module m
  
! ! { dg-final { scan-assembler-not "aaaa" } }
--- 11,17 ----
    integer, save :: aaaa
  end module m
  
! ! The xfail below has appeared with the introduction of submodules. 'aaaa'
! ! now is TREE_PUBLIC but has DECL_VISIBILITY (decl) = VISIBILITY_HIDDEN set.
! 
! ! { dg-final { scan-assembler-not "aaaa" { xfail *-*-* } } }
Index: gcc/testsuite/gfortran.dg/submodule_10.f08
===================================================================
*** gcc/testsuite/gfortran.dg/submodule_10.f08	(revision 0)
--- gcc/testsuite/gfortran.dg/submodule_10.f08	(working copy)
***************
*** 0 ****
--- 1,170 ----
+ ! { dg-do compile }
+ !
+ ! Checks that PRIVATE enities are visible to submodules.
+ !
+ ! Contributed by Salvatore Filippone  <salvatore.filippone@uniroma2.it>
+ !
+ module const_mod
+   integer, parameter  :: ndig=8
+   integer, parameter  :: ipk_ = selected_int_kind(ndig)
+   integer, parameter  :: longndig=12
+   integer, parameter  :: long_int_k_ = selected_int_kind(longndig)
+   integer, parameter  :: mpik_ = kind(1)
+ 
+   integer(ipk_), parameter, public :: success_=0
+ 
+ end module const_mod
+ 
+ 
+ module error_mod
+   use const_mod
+ 
+   integer(ipk_), parameter, public :: act_ret_=0
+   integer(ipk_), parameter, public :: act_print_=1
+   integer(ipk_), parameter, public :: act_abort_=2
+ 
+   integer(ipk_), parameter, public ::  no_err_ = 0
+ 
+   public error, errcomm, get_numerr, &
+        & error_handler, &
+        & ser_error_handler, par_error_handler
+ 
+ 
+   interface error_handler
+     module subroutine ser_error_handler(err_act)
+       integer(ipk_), intent(inout) ::  err_act
+     end subroutine ser_error_handler
+     module subroutine par_error_handler(ictxt,err_act)
+       integer(mpik_), intent(in) ::  ictxt
+       integer(ipk_), intent(in) ::  err_act
+     end subroutine par_error_handler
+   end interface
+ 
+   interface error
+     module subroutine serror()
+     end subroutine serror
+     module subroutine perror(ictxt,abrt)
+       integer(mpik_), intent(in) ::  ictxt
+       logical, intent(in), optional  :: abrt
+     end subroutine perror
+   end interface
+ 
+ 
+   interface error_print_stack
+     module subroutine par_error_print_stack(ictxt)
+       integer(mpik_), intent(in) ::  ictxt
+     end subroutine par_error_print_stack
+     module subroutine ser_error_print_stack()
+     end subroutine ser_error_print_stack
+   end interface
+ 
+   interface errcomm
+     module subroutine errcomm(ictxt, err)
+       integer(mpik_), intent(in)   :: ictxt
+       integer(ipk_), intent(inout):: err
+     end subroutine errcomm
+   end interface errcomm
+ 
+ 
+   private
+ 
+   type errstack_node
+ 
+     integer(ipk_) ::   err_code=0
+     character(len=20)        ::   routine=''
+     integer(ipk_),dimension(5)     ::   i_err_data=0
+     character(len=40)        ::   a_err_data=''
+     type(errstack_node), pointer :: next
+ 
+   end type errstack_node
+ 
+ 
+   type errstack
+     type(errstack_node), pointer :: top => null()
+     integer(ipk_) :: n_elems=0
+   end type errstack
+ 
+ 
+   type(errstack), save  :: error_stack
+   integer(ipk_), save   :: error_status    = no_err_
+   integer(ipk_), save   :: verbosity_level = 1
+   integer(ipk_), save   :: err_action      = act_abort_
+   integer(ipk_), save   :: debug_level     = 0, debug_unit, serial_debug_level=0
+ 
+ contains
+ end module error_mod
+ 
+ submodule (error_mod) error_impl_mod
+   use const_mod
+ contains
+   ! checks whether an error has occurred on one of the processes in the execution pool
+   subroutine errcomm(ictxt, err)
+     integer(mpik_), intent(in)   :: ictxt
+     integer(ipk_), intent(inout):: err
+ 
+ 
+   end subroutine errcomm
+ 
+   subroutine ser_error_handler(err_act)
+     implicit none
+     integer(ipk_), intent(inout) ::  err_act
+ 
+     if (err_act /= act_ret_)     &
+          &  call error()
+     if (err_act == act_abort_) stop
+ 
+     return
+   end subroutine ser_error_handler
+ 
+   subroutine par_error_handler(ictxt,err_act)
+     implicit none
+     integer(mpik_), intent(in) ::  ictxt
+     integer(ipk_), intent(in) ::  err_act
+ 
+     if (err_act == act_print_)     &
+          &  call error(ictxt, abrt=.false.)
+     if (err_act == act_abort_)      &
+          &  call error(ictxt, abrt=.true.)
+ 
+     return
+ 
+   end subroutine par_error_handler
+ 
+   subroutine par_error_print_stack(ictxt)
+     integer(mpik_), intent(in) ::  ictxt
+ 
+     call error(ictxt, abrt=.false.)
+ 
+   end subroutine par_error_print_stack
+ 
+   subroutine ser_error_print_stack()
+ 
+     call error()
+   end subroutine ser_error_print_stack
+ 
+   subroutine serror()
+ 
+     implicit none
+ 
+   end subroutine serror
+ 
+   subroutine perror(ictxt,abrt)
+     use const_mod
+     implicit none
+     integer(mpik_), intent(in) :: ictxt
+     logical, intent(in), optional  :: abrt
+ 
+   end subroutine perror
+ 
+ end submodule error_impl_mod
+ 
+ program testlk
+   use error_mod
+   implicit none
+ 
+   call error()
+ 
+   stop
+ end program testlk
+ 
+ 

Re: [Bug fortran/52846] [F2008] Support submodules - part 3/3

[Damian Rouson]

> On Jul 23, 2015, at 12:46 AM, Paul Richard Thomas <paul.richard.thomas@gmail.com> wrote:
> 
> Since all the private entities in a module have to be transmitted to
> their descendant submodules, whilst keeping them hidden from normal
> use statements, I have chosen to write the module file as usual and
> add a second part that contains the private entities. This latter is
> only read when processing submodule statements.

Hi Paul,

Could you comment on whether this approach alleviates compilation cascades as 
seems to have been envisioned when submodules were added to the standard?  My 
guess is that a developer could adopt a policy of putting only public information in a
module and reserving all private information for submodules, which would mitigate
against unnecessary compilation cascades and would be consistent with putting
the interface in the module and the implementation in a submodule.. 

> It does cross my mind that all of this part of the submodule
> implementation could be subject to the condition that a compiler
> option is set. I am struck by the notion that making private module
> entities available to submodules is an unnecessary complication and
> that it amounts to be an error in the standard. This is why I am
> suggesting the possibility of a specific compiler option.

I strongly advocate against having to pass flags to force standard-compliant behavior 
(I happened to have just posted to c.l.f on a frustrating way in which two compilers
currently require flags to comply with the standard), although it sounds like it might 
not matter in this case if one adopts the aforementioned policy 
of putting only pubic information in modules.

Damian

Re: [Bug fortran/52846] [F2008] Support submodules - part 3/3

[Paul Richard Thomas]

Dear Damian,

I do not think that there is any effect on compilation cascades. As
long as the private part of the module file remains unchanged, it will
not be recompiled if a descendant submodule is modified. Naturally,
the size of the module file is increased but, if one is careful, this
is not a big deal. A gotcha, which I will have to emphasize in the
documentation occurs if another module file is used and its symbols
are not exposed by public statements. If there are large numbers of
symbols this can have a big effect on the size of the module file. I
noticed this, when examining one of gfortran's testcases where the
ISO_C_BINDING intrinsic module is used. Generous sprinklings of USE
ONLYs are required to keep the module file sizes under control.

I am not over enthusiastic about using compilation flags to uphold
standards either.

Cheers

Paul

On 23 July 2015 at 10:22, Damian Rouson <damian@sourceryinstitute.org> wrote:
>
>
>> On Jul 23, 2015, at 12:46 AM, Paul Richard Thomas <paul.richard.thomas@gmail.com> wrote:
>>
>> Since all the private entities in a module have to be transmitted to
>> their descendant submodules, whilst keeping them hidden from normal
>> use statements, I have chosen to write the module file as usual and
>> add a second part that contains the private entities. This latter is
>> only read when processing submodule statements.
>
> Hi Paul,
>
> Could you comment on whether this approach alleviates compilation cascades as
> seems to have been envisioned when submodules were added to the standard?  My
> guess is that a developer could adopt a policy of putting only public information in a
> module and reserving all private information for submodules, which would mitigate
> against unnecessary compilation cascades and would be consistent with putting
> the interface in the module and the implementation in a submodule..
>
>> It does cross my mind that all of this part of the submodule
>> implementation could be subject to the condition that a compiler
>> option is set. I am struck by the notion that making private module
>> entities available to submodules is an unnecessary complication and
>> that it amounts to be an error in the standard. This is why I am
>> suggesting the possibility of a specific compiler option.
>
> I strongly advocate against having to pass flags to force standard-compliant behavior
> (I happened to have just posted to c.l.f on a frustrating way in which two compilers
> currently require flags to comply with the standard), although it sounds like it might
> not matter in this case if one adopts the aforementioned policy
> of putting only pubic information in modules.
>
> Damian



-- 
Outside of a dog, a book is a man's best friend. Inside of a dog it's
too dark to read.

Groucho Marx

Re: [Bug fortran/52846] [F2008] Support submodules - part 3/3

[Mikael Morin]

Hello Paul,

Le 23/07/2015 09:46, Paul Richard Thomas a écrit :
> Since all the private entities in a module have to be transmitted to
> their descendant submodules, whilst keeping them hidden from normal
> use statements, I have chosen to write the module file as usual and
> add a second part that contains the private entities. This latter is
> only read when processing submodule statements.
>
why not write them to the/a .smod file?  It was its primary purpose, 
wasn't it?
[Sorry, I followed the submodule stuff very remotely].

It's probably bad practice to put private entities in module files, at 
least now that submodules are supported.  Nevertheless with your change, 
modifications made to private entities produce recompilation cascades, 
even though the public interfaces are left unchanged.

Mikael

Re: [Bug fortran/52846] [F2008] Support submodules - part 3/3

[Paul Richard Thomas]

Dear Mikael,

It had crossed my mind also that a .mod and a .smod file could be
written. Normally, the .smod files are produced by the submodules
themselves, so that their descendants can pick up the symbols that
they generate. There is no reason at all why this could not be
implemented; early on in the development I did just this, although I
think that it would now be easier to modify this patch.

One huge advantage of proceeding in this way is that any resulting
library can be distributed with the .mod file alone so that the
private entities are never exposed. The penalty is that a second file
is output.

With best regards

Paul

On 23 July 2015 at 17:42, Mikael Morin <mikael.morin@sfr.fr> wrote:
> Hello Paul,
>
> Le 23/07/2015 09:46, Paul Richard Thomas a écrit :
>>
>> Since all the private entities in a module have to be transmitted to
>> their descendant submodules, whilst keeping them hidden from normal
>> use statements, I have chosen to write the module file as usual and
>> add a second part that contains the private entities. This latter is
>> only read when processing submodule statements.
>>
> why not write them to the/a .smod file?  It was its primary purpose, wasn't
> it?
> [Sorry, I followed the submodule stuff very remotely].
>
> It's probably bad practice to put private entities in module files, at least
> now that submodules are supported.  Nevertheless with your change,
> modifications made to private entities produce recompilation cascades, even
> though the public interfaces are left unchanged.
>
> Mikael



-- 
Outside of a dog, a book is a man's best friend. Inside of a dog it's
too dark to read.

Groucho Marx

Re: [Bug fortran/52846] [F2008] Support submodules - part 3/3

[Damian Rouson]

I love this idea and had similar thoughts as well.  

:D 

Sent from my iPhone

> On Jul 24, 2015, at 1:06 AM, Paul Richard Thomas <paul.richard.thomas@gmail.com> wrote:
> 
> Dear Mikael,
> 
> It had crossed my mind also that a .mod and a .smod file could be
> written. Normally, the .smod files are produced by the submodules
> themselves, so that their descendants can pick up the symbols that
> they generate. There is no reason at all why this could not be
> implemented; early on in the development I did just this, although I
> think that it would now be easier to modify this patch.
> 
> One huge advantage of proceeding in this way is that any resulting
> library can be distributed with the .mod file alone so that the
> private entities are never exposed. The penalty is that a second file
> is output.
> 
> With best regards
> 
> Paul
> 
>> On 23 July 2015 at 17:42, Mikael Morin <mikael.morin@sfr.fr> wrote:
>> Hello Paul,
>> 
>> Le 23/07/2015 09:46, Paul Richard Thomas a écrit :
>>> 
>>> Since all the private entities in a module have to be transmitted to
>>> their descendant submodules, whilst keeping them hidden from normal
>>> use statements, I have chosen to write the module file as usual and
>>> add a second part that contains the private entities. This latter is
>>> only read when processing submodule statements.
>> why not write them to the/a .smod file?  It was its primary purpose, wasn't
>> it?
>> [Sorry, I followed the submodule stuff very remotely].
>> 
>> It's probably bad practice to put private entities in module files, at least
>> now that submodules are supported.  Nevertheless with your change,
>> modifications made to private entities produce recompilation cascades, even
>> though the public interfaces are left unchanged.
>> 
>> Mikael
> 
> 
> 
> -- 
> Outside of a dog, a book is a man's best friend. Inside of a dog it's
> too dark to read.
> 
> Groucho Marx

Re: [Bug fortran/52846] [F2008] Support submodules - part 3/3

[Paul Richard Thomas]

Dear All,

In the words of Jean-Luc Picard, "I will make it so.... "

Paul

On 24 July 2015 at 10:08, Damian Rouson <damian@sourceryinstitute.org> wrote:
> I love this idea and had similar thoughts as well.
>
> :D
>
> Sent from my iPhone
>
>> On Jul 24, 2015, at 1:06 AM, Paul Richard Thomas <paul.richard.thomas@gmail.com> wrote:
>>
>> Dear Mikael,
>>
>> It had crossed my mind also that a .mod and a .smod file could be
>> written. Normally, the .smod files are produced by the submodules
>> themselves, so that their descendants can pick up the symbols that
>> they generate. There is no reason at all why this could not be
>> implemented; early on in the development I did just this, although I
>> think that it would now be easier to modify this patch.
>>
>> One huge advantage of proceeding in this way is that any resulting
>> library can be distributed with the .mod file alone so that the
>> private entities are never exposed. The penalty is that a second file
>> is output.
>>
>> With best regards
>>
>> Paul
>>
>>> On 23 July 2015 at 17:42, Mikael Morin <mikael.morin@sfr.fr> wrote:
>>> Hello Paul,
>>>
>>> Le 23/07/2015 09:46, Paul Richard Thomas a écrit :
>>>>
>>>> Since all the private entities in a module have to be transmitted to
>>>> their descendant submodules, whilst keeping them hidden from normal
>>>> use statements, I have chosen to write the module file as usual and
>>>> add a second part that contains the private entities. This latter is
>>>> only read when processing submodule statements.
>>> why not write them to the/a .smod file?  It was its primary purpose, wasn't
>>> it?
>>> [Sorry, I followed the submodule stuff very remotely].
>>>
>>> It's probably bad practice to put private entities in module files, at least
>>> now that submodules are supported.  Nevertheless with your change,
>>> modifications made to private entities produce recompilation cascades, even
>>> though the public interfaces are left unchanged.
>>>
>>> Mikael
>>
>>
>>
>> --
>> Outside of a dog, a book is a man's best friend. Inside of a dog it's
>> too dark to read.
>>
>> Groucho Marx



-- 
Outside of a dog, a book is a man's best friend. Inside of a dog it's
too dark to read.

Groucho Marx

Re: [Bug fortran/52846] [F2008] Support submodules - part 3/3

[Paul Richard Thomas]

[-- Attachment #1: Type: text/plain, Size: 2566 bytes --]

Dear All,

On 24 July 2015 at 10:08, Damian Rouson <damian@sourceryinstitute.org> wrote:
> I love this idea and had similar thoughts as well.
>
> :D
>
> Sent from my iPhone
>
>> On Jul 24, 2015, at 1:06 AM, Paul Richard Thomas <paul.richard.thomas@gmail.com> wrote:
>>
>> Dear Mikael,
>>
>> It had crossed my mind also that a .mod and a .smod file could be
>> written. Normally, the .smod files are produced by the submodules
>> themselves, so that their descendants can pick up the symbols that
>> they generate. There is no reason at all why this could not be
>> implemented; early on in the development I did just this, although I
>> think that it would now be easier to modify this patch.
>>
>> One huge advantage of proceeding in this way is that any resulting
>> library can be distributed with the .mod file alone so that the
>> private entities are never exposed. The penalty is that a second file
>> is output.
>>
>> With best regards
>>
>> Paul
>>

Please find attached the implementation of this suggestion.

Bootstraps and regtests on FC21/x86_64 - OK for trunk or is the
original preferred?

Cheers

Paul

2015-07-29  Paul Thomas  <pault@gcc.gnu.org>

    PR fortran/52846
    * module.c (check_access): Return true if new static flag
    'dump_smod' is true..
    (gfc_dump_module): Rename original 'dump_module' and call from
    new version. Use 'dump_smod' rather than the stack state to
    determine if a submodule is being processed. The new version of
    this procedure sets 'dump_smod' depending on the stack state and
    then writes both the mod and smod files if a module is being
    processed or just the smod for a submodule.
    (gfc_use_module): Eliminate the check for module_name and
    submodule_name being the same.
    * trans-decl.c (gfc_finish_var_decl, gfc_build_qualified_array,
    get_proc_pointer_decl): Set TREE_PUBLIC unconditionally and use
    the conditions to set DECL_VISIBILITY as hidden and to set as
    true DECL_VISIBILITY_SPECIFIED.

2015-07-29  Paul Thomas  <pault@gcc.gnu.org>

    PR fortran/52846

    * lib/fortran-modules.exp: Call cleanup-submodules from
    cleanup-modules.
    * gfortran.dg/public_private_module_2.f90: Add two XFAILS to
    cover the cases where private entities are no longer optimized
    away.
    * gfortran.dg/public_private_module_6.f90: Add an XFAIL for the
    same reason.
    * gfortran.dg/submodule_1.f08: Change cleanup module names.
    * gfortran.dg/submodule_5.f08: The same.
    * gfortran.dg/submodule_9.f08: The same.
    * gfortran.dg/submodule_10.f08: New test

[-- Attachment #2: private-alternative.diff --]
[-- Type: text/plain, Size: 15882 bytes --]

Index: gcc/fortran/module.c
===================================================================
*** gcc/fortran/module.c	(revision 226054)
--- gcc/fortran/module.c	(working copy)
*************** read_module (void)
*** 5283,5291 ****
--- 5283,5296 ----
     PRIVATE, then private, and otherwise it is public unless the default
     access in this context has been declared PRIVATE.  */

+ static bool dump_smod = false;
+
  static bool
  check_access (gfc_access specific_access, gfc_access default_access)
  {
+   if (dump_smod)
+     return true;
+
    if (specific_access == ACCESS_PUBLIC)
      return TRUE;
    if (specific_access == ACCESS_PRIVATE)
*************** read_crc32_from_module_file (const char*
*** 5961,5968 ****
     processing the module, dump_flag will be set to zero and we delete
     the module file, even if it was already there.  */

! void
! gfc_dump_module (const char *name, int dump_flag)
  {
    int n;
    char *filename, *filename_tmp;
--- 5966,5973 ----
     processing the module, dump_flag will be set to zero and we delete
     the module file, even if it was already there.  */

! static void
! dump_module (const char *name, int dump_flag)
  {
    int n;
    char *filename, *filename_tmp;
*************** gfc_dump_module (const char *name, int d
*** 5970,5976 ****

    module_name = gfc_get_string (name);

!   if (gfc_state_stack->state == COMP_SUBMODULE)
      {
        name = submodule_name;
        n = strlen (name) + strlen (SUBMODULE_EXTENSION) + 1;
--- 5975,5981 ----

    module_name = gfc_get_string (name);

!   if (dump_smod)
      {
        name = submodule_name;
        n = strlen (name) + strlen (SUBMODULE_EXTENSION) + 1;
*************** gfc_dump_module (const char *name, int d
*** 5991,5997 ****
        strcpy (filename, name);
      }

!   if (gfc_state_stack->state == COMP_SUBMODULE)
      strcat (filename, SUBMODULE_EXTENSION);
    else
    strcat (filename, MODULE_EXTENSION);
--- 5996,6002 ----
        strcpy (filename, name);
      }

!   if (dump_smod)
      strcat (filename, SUBMODULE_EXTENSION);
    else
    strcat (filename, MODULE_EXTENSION);
*************** gfc_dump_module (const char *name, int d
*** 6060,6065 ****
--- 6065,6091 ----
  }


+ void
+ gfc_dump_module (const char *name, int dump_flag)
+ {
+   if (gfc_state_stack->state == COMP_SUBMODULE)
+     dump_smod = true;
+   else
+     dump_smod =false;
+
+   dump_module (name, dump_flag);
+
+   if (dump_smod)
+     return;
+
+   /* Write a submodule file from a module.  The 'dump_smod' flag switches
+      off the check for PRIVATE entities.  */
+   dump_smod = true;
+   submodule_name = module_name;
+   dump_module (name, dump_flag);
+   dump_smod = false;
+ }
+
  static void
  create_intrinsic_function (const char *name, int id,
  			   const char *modname, intmod_id module,
*************** gfc_use_module (gfc_use_list *module)
*** 6754,6761 ****
  		     "USE statement at %C has no ONLY qualifier");

    if (gfc_state_stack->state == COMP_MODULE
!       || module->submodule_name == NULL
!       || strcmp (module_name, module->submodule_name) == 0)
      {
        filename = XALLOCAVEC (char, strlen (module_name)
  				   + strlen (MODULE_EXTENSION) + 1);
--- 6780,6786 ----
  		     "USE statement at %C has no ONLY qualifier");

    if (gfc_state_stack->state == COMP_MODULE
!       || module->submodule_name == NULL)
      {
        filename = XALLOCAVEC (char, strlen (module_name)
  				   + strlen (MODULE_EXTENSION) + 1);
Index: gcc/fortran/trans-decl.c
===================================================================
*** gcc/fortran/trans-decl.c	(revision 226054)
--- gcc/fortran/trans-decl.c	(working copy)
*************** gfc_finish_var_decl (tree decl, gfc_symb
*** 596,601 ****
--- 596,606 ----
  	 both, of course.) (J3/04-007, section 15.3).  */
        TREE_PUBLIC(decl) = 1;
        DECL_COMMON(decl) = 1;
+       if (sym->attr.access == ACCESS_PRIVATE && !sym->attr.public_used)
+ 	{
+ 	  DECL_VISIBILITY (decl) = VISIBILITY_HIDDEN;
+ 	  DECL_VISIBILITY_SPECIFIED (decl) = true;
+ 	}
      }

    /* If a variable is USE associated, it's always external.  */
*************** gfc_finish_var_decl (tree decl, gfc_symb
*** 609,617 ****
        /* TODO: Don't set sym->module for result or dummy variables.  */
        gcc_assert (current_function_decl == NULL_TREE || sym->result == sym);

-       if (sym->attr.access != ACCESS_PRIVATE || sym->attr.public_used)
  	TREE_PUBLIC (decl) = 1;
        TREE_STATIC (decl) = 1;
      }

    /* Derived types are a bit peculiar because of the possibility of
--- 614,626 ----
        /* TODO: Don't set sym->module for result or dummy variables.  */
        gcc_assert (current_function_decl == NULL_TREE || sym->result == sym);

        TREE_PUBLIC (decl) = 1;
        TREE_STATIC (decl) = 1;
+       if (sym->attr.access == ACCESS_PRIVATE && !sym->attr.public_used)
+ 	{
+ 	  DECL_VISIBILITY (decl) = VISIBILITY_HIDDEN;
+ 	  DECL_VISIBILITY_SPECIFIED (decl) = true;
+ 	}
      }

    /* Derived types are a bit peculiar because of the possibility of
*************** gfc_build_qualified_array (tree decl, gf
*** 837,845 ****
  	  else
  	    TREE_STATIC (token) = 1;

- 	  if (sym->attr.use_assoc || sym->attr.access != ACCESS_PRIVATE ||
- 	      sym->attr.public_used)
  	    TREE_PUBLIC (token) = 1;
  	}
        else
  	{
--- 846,858 ----
  	  else
  	    TREE_STATIC (token) = 1;

  	  TREE_PUBLIC (token) = 1;
+
+ 	  if (sym->attr.access == ACCESS_PRIVATE && !sym->attr.public_used)
+ 	    {
+ 	      DECL_VISIBILITY (token) = VISIBILITY_HIDDEN;
+ 	      DECL_VISIBILITY_SPECIFIED (token) = true;
+ 	    }
  	}
        else
  	{
*************** get_proc_pointer_decl (gfc_symbol *sym)
*** 1747,1755 ****
    else if (sym->module && sym->ns->proc_name->attr.flavor == FL_MODULE)
      {
        /* This is the declaration of a module variable.  */
-       if (sym->ns->proc_name->attr.flavor == FL_MODULE
- 	  && (sym->attr.access != ACCESS_PRIVATE || sym->attr.public_used))
  	TREE_PUBLIC (decl) = 1;
        TREE_STATIC (decl) = 1;
      }

--- 1760,1771 ----
    else if (sym->module && sym->ns->proc_name->attr.flavor == FL_MODULE)
      {
        /* This is the declaration of a module variable.  */
        TREE_PUBLIC (decl) = 1;
+       if (sym->attr.access == ACCESS_PRIVATE && !sym->attr.public_used)
+ 	{
+ 	  DECL_VISIBILITY (decl) = VISIBILITY_HIDDEN;
+ 	  DECL_VISIBILITY_SPECIFIED (decl) = true;
+ 	}
        TREE_STATIC (decl) = 1;
      }

Index: gcc/testsuite/lib/fortran-modules.exp
===================================================================
*** gcc/testsuite/lib/fortran-modules.exp	(revision 226054)
--- gcc/testsuite/lib/fortran-modules.exp	(working copy)
***************
*** 17,22 ****
--- 17,23 ----
  # helper to deal with fortran modules

  # Remove files for specified Fortran modules.
+ # This includes both .mod and .smod files.
  proc cleanup-modules { modlist } {
      global clean
      foreach mod [concat $modlist $clean] {
*************** proc cleanup-modules { modlist } {
*** 27,32 ****
--- 28,34 ----
  	}
  	remote_file build delete $m
      }
+     cleanup-submodules $modlist
  }

  # Remove files for specified Fortran submodules.
Index: gcc/testsuite/gfortran.dg/public_private_module_2.f90
===================================================================
*** gcc/testsuite/gfortran.dg/public_private_module_2.f90	(revision 226054)
--- gcc/testsuite/gfortran.dg/public_private_module_2.f90	(working copy)
***************
*** 18,29 ****
          integer, bind(C,name='') :: qq
        end module mod

        ! { dg-final { scan-assembler "__mod_MOD_aa" } }
!       ! { dg-final { scan-assembler-not "iii" } }
        ! { dg-final { scan-assembler "jj" } }
        ! { dg-final { scan-assembler "lll" } }
        ! { dg-final { scan-assembler-not "kk" } }
!       ! { dg-final { scan-assembler-not "mmmm" } }
        ! { dg-final { scan-assembler "nnn" } }
        ! { dg-final { scan-assembler "oo" } }
        ! { dg-final { scan-assembler "__mod_MOD_qq" } }
--- 18,32 ----
          integer, bind(C,name='') :: qq
        end module mod

+ ! The two xfails below have appeared with the introduction of submodules. 'iii' and
+ ! 'mmm' now are TREE_PUBLIC but has DECL_VISIBILITY (decl) = VISIBILITY_HIDDEN set.
+
        ! { dg-final { scan-assembler "__mod_MOD_aa" } }
!       ! { dg-final { scan-assembler-not "iii" { xfail *-*-* } } }
        ! { dg-final { scan-assembler "jj" } }
        ! { dg-final { scan-assembler "lll" } }
        ! { dg-final { scan-assembler-not "kk" } }
!       ! { dg-final { scan-assembler-not "mmmm" { xfail *-*-* } } }
        ! { dg-final { scan-assembler "nnn" } }
        ! { dg-final { scan-assembler "oo" } }
        ! { dg-final { scan-assembler "__mod_MOD_qq" } }
Index: gcc/testsuite/gfortran.dg/public_private_module_6.f90
===================================================================
*** gcc/testsuite/gfortran.dg/public_private_module_6.f90	(revision 226054)
--- gcc/testsuite/gfortran.dg/public_private_module_6.f90	(working copy)
*************** module m
*** 11,14 ****
    integer, save :: aaaa
  end module m

! ! { dg-final { scan-assembler-not "aaaa" } }
--- 11,17 ----
    integer, save :: aaaa
  end module m

! ! The xfail below has appeared with the introduction of submodules. 'aaaa'
! ! now is TREE_PUBLIC but has DECL_VISIBILITY (decl) = VISIBILITY_HIDDEN set.
!
! ! { dg-final { scan-assembler-not "aaaa" { xfail *-*-* } } }
Index: gcc/testsuite/gfortran.dg/submodule_1.f08
===================================================================
*** gcc/testsuite/gfortran.dg/submodule_1.f08	(revision 226054)
--- gcc/testsuite/gfortran.dg/submodule_1.f08	(working copy)
***************
*** 170,175 ****
       message2 = ""
     end subroutine
   end program
! ! { dg-final { cleanup-submodules "foo_interface_son" } }
! ! { dg-final { cleanup-submodules "foo_interface_grandson" } }
! ! { dg-final { cleanup-submodules "foo_interface_daughter" } }
--- 170,175 ----
       message2 = ""
     end subroutine
   end program
! ! { dg-final { cleanup-submodules "foo_interface@foo_interface_son" } }
! ! { dg-final { cleanup-submodules "foo_interface@foo_interface_grandson" } }
! ! { dg-final { cleanup-submodules "foo_interface@foo_interface_daughter" } }
Index: gcc/testsuite/gfortran.dg/submodule_10.f08
===================================================================
*** gcc/testsuite/gfortran.dg/submodule_10.f08	(revision 0)
--- gcc/testsuite/gfortran.dg/submodule_10.f08	(working copy)
***************
*** 0 ****
--- 1,170 ----
+ ! { dg-do compile }
+ !
+ ! Checks that PRIVATE enities are visible to submodules.
+ !
+ ! Contributed by Salvatore Filippone  <salvatore.filippone@uniroma2.it>
+ !
+ module const_mod
+   integer, parameter  :: ndig=8
+   integer, parameter  :: ipk_ = selected_int_kind(ndig)
+   integer, parameter  :: longndig=12
+   integer, parameter  :: long_int_k_ = selected_int_kind(longndig)
+   integer, parameter  :: mpik_ = kind(1)
+
+   integer(ipk_), parameter, public :: success_=0
+
+ end module const_mod
+
+
+ module error_mod
+   use const_mod
+
+   integer(ipk_), parameter, public :: act_ret_=0
+   integer(ipk_), parameter, public :: act_print_=1
+   integer(ipk_), parameter, public :: act_abort_=2
+
+   integer(ipk_), parameter, public ::  no_err_ = 0
+
+   public error, errcomm, get_numerr, &
+        & error_handler, &
+        & ser_error_handler, par_error_handler
+
+
+   interface error_handler
+     module subroutine ser_error_handler(err_act)
+       integer(ipk_), intent(inout) ::  err_act
+     end subroutine ser_error_handler
+     module subroutine par_error_handler(ictxt,err_act)
+       integer(mpik_), intent(in) ::  ictxt
+       integer(ipk_), intent(in) ::  err_act
+     end subroutine par_error_handler
+   end interface
+
+   interface error
+     module subroutine serror()
+     end subroutine serror
+     module subroutine perror(ictxt,abrt)
+       integer(mpik_), intent(in) ::  ictxt
+       logical, intent(in), optional  :: abrt
+     end subroutine perror
+   end interface
+
+
+   interface error_print_stack
+     module subroutine par_error_print_stack(ictxt)
+       integer(mpik_), intent(in) ::  ictxt
+     end subroutine par_error_print_stack
+     module subroutine ser_error_print_stack()
+     end subroutine ser_error_print_stack
+   end interface
+
+   interface errcomm
+     module subroutine errcomm(ictxt, err)
+       integer(mpik_), intent(in)   :: ictxt
+       integer(ipk_), intent(inout):: err
+     end subroutine errcomm
+   end interface errcomm
+
+
+   private
+
+   type errstack_node
+
+     integer(ipk_) ::   err_code=0
+     character(len=20)        ::   routine=''
+     integer(ipk_),dimension(5)     ::   i_err_data=0
+     character(len=40)        ::   a_err_data=''
+     type(errstack_node), pointer :: next
+
+   end type errstack_node
+
+
+   type errstack
+     type(errstack_node), pointer :: top => null()
+     integer(ipk_) :: n_elems=0
+   end type errstack
+
+
+   type(errstack), save  :: error_stack
+   integer(ipk_), save   :: error_status    = no_err_
+   integer(ipk_), save   :: verbosity_level = 1
+   integer(ipk_), save   :: err_action      = act_abort_
+   integer(ipk_), save   :: debug_level     = 0, debug_unit, serial_debug_level=0
+
+ contains
+ end module error_mod
+
+ submodule (error_mod) error_impl_mod
+   use const_mod
+ contains
+   ! checks whether an error has occurred on one of the processes in the execution pool
+   subroutine errcomm(ictxt, err)
+     integer(mpik_), intent(in)   :: ictxt
+     integer(ipk_), intent(inout):: err
+
+
+   end subroutine errcomm
+
+   subroutine ser_error_handler(err_act)
+     implicit none
+     integer(ipk_), intent(inout) ::  err_act
+
+     if (err_act /= act_ret_)     &
+          &  call error()
+     if (err_act == act_abort_) stop
+
+     return
+   end subroutine ser_error_handler
+
+   subroutine par_error_handler(ictxt,err_act)
+     implicit none
+     integer(mpik_), intent(in) ::  ictxt
+     integer(ipk_), intent(in) ::  err_act
+
+     if (err_act == act_print_)     &
+          &  call error(ictxt, abrt=.false.)
+     if (err_act == act_abort_)      &
+          &  call error(ictxt, abrt=.true.)
+
+     return
+
+   end subroutine par_error_handler
+
+   subroutine par_error_print_stack(ictxt)
+     integer(mpik_), intent(in) ::  ictxt
+
+     call error(ictxt, abrt=.false.)
+
+   end subroutine par_error_print_stack
+
+   subroutine ser_error_print_stack()
+
+     call error()
+   end subroutine ser_error_print_stack
+
+   subroutine serror()
+
+     implicit none
+
+   end subroutine serror
+
+   subroutine perror(ictxt,abrt)
+     use const_mod
+     implicit none
+     integer(mpik_), intent(in) :: ictxt
+     logical, intent(in), optional  :: abrt
+
+   end subroutine perror
+
+ end submodule error_impl_mod
+
+ program testlk
+   use error_mod
+   implicit none
+
+   call error()
+
+   stop
+ end program testlk
+ ! { dg-final { cleanup-submodules "error_mod@error_impl_mod" } }
+
Index: gcc/testsuite/gfortran.dg/submodule_5.f08
===================================================================
*** gcc/testsuite/gfortran.dg/submodule_5.f08	(revision 226054)
--- gcc/testsuite/gfortran.dg/submodule_5.f08	(working copy)
*************** contains
*** 49,51 ****
--- 49,52 ----
  end SUBMODULE foo_interface_daughter

  end
+ ! { dg-final { cleanup-submodules "foo_interface@foo_interface_daughter" } }
Index: gcc/testsuite/gfortran.dg/submodule_9.f08
===================================================================
*** gcc/testsuite/gfortran.dg/submodule_9.f08	(revision 226054)
--- gcc/testsuite/gfortran.dg/submodule_9.f08	(working copy)
*************** program a_s
*** 38,40 ****
--- 38,41 ----
    implicit none
    call p()
  end program
+ ! { dg-final { cleanup-submodules "mod_a@b" } }

Re: [Bug fortran/52846] [F2008] Support submodules - part 3/3

[Marek Polacek]

On Wed, Jul 29, 2015 at 05:08:19PM +0200, Paul Richard Thomas wrote:
> Index: gcc/fortran/module.c
> ===================================================================
> *** gcc/fortran/module.c	(revision 226054)
> --- gcc/fortran/module.c	(working copy)
> *************** read_module (void)
> *** 5283,5291 ****
> --- 5283,5296 ----
>      PRIVATE, then private, and otherwise it is public unless the default
>      access in this context has been declared PRIVATE.  */
> 
> + static bool dump_smod = false;

Why do you initialize a static variable to false?

	Marek

Re: [Bug fortran/52846] [F2008] Support submodules - part 3/3

[FX]

> Why do you initialize a static variable to false?

You mean because false is equal to zero and it will be the default initialization anyway?
I quite like that the default value is explicit.

FX

Re: [Bug fortran/52846] [F2008] Support submodules - part 3/3

[Marek Polacek]

On Wed, Jul 29, 2015 at 05:31:57PM +0200, FX wrote:
> > Why do you initialize a static variable to false?
> 
> You mean because false is equal to zero and it will be the default initialization anyway?

Yes.

> I quite like that the default value is explicit.

Ok then. 

	Marek

Re: [Bug fortran/52846] [F2008] Support submodules - part 3/3

[Paul Richard Thomas]

Dear All,

My reply is the same as FX's. However, I am perfectly happy to
eliminate the initialization. The correct state is ensured by
gfc_dump_module.

Cheers

Paul

On 29 July 2015 at 17:31, FX <fxcoudert@gmail.com> wrote:
>> Why do you initialize a static variable to false?
>
> You mean because false is equal to zero and it will be the default initialization anyway?
> I quite like that the default value is explicit.
>
> FX



-- 
Outside of a dog, a book is a man's best friend. Inside of a dog it's
too dark to read.

Groucho Marx

Re: [Bug fortran/52846] [F2008] Support submodules - part 3/3

[Mikael Morin]

Le 29/07/2015 17:08, Paul Richard Thomas a écrit :
> Dear All,
>
> On 24 July 2015 at 10:08, Damian Rouson <damian@sourceryinstitute.org> wrote:
>> I love this idea and had similar thoughts as well.
>>
>> :D
>>
>> Sent from my iPhone
>>
>>> On Jul 24, 2015, at 1:06 AM, Paul Richard Thomas <paul.richard.thomas@gmail.com> wrote:
>>>
>>> Dear Mikael,
>>>
>>> It had crossed my mind also that a .mod and a .smod file could be
>>> written. Normally, the .smod files are produced by the submodules
>>> themselves, so that their descendants can pick up the symbols that
>>> they generate. There is no reason at all why this could not be
>>> implemented; early on in the development I did just this, although I
>>> think that it would now be easier to modify this patch.
>>>
>>> One huge advantage of proceeding in this way is that any resulting
>>> library can be distributed with the .mod file alone so that the
>>> private entities are never exposed. The penalty is that a second file
>>> is output.
>>>
>>> With best regards
>>>
>>> Paul
>>>
>
> Please find attached the implementation of this suggestion.
>
> Bootstraps and regtests on FC21/x86_64 - OK for trunk or is the
> original preferred?
>
There hasn't been a lot of voices about this among the other active and 
less active team members.
I prefer this "private members to separate smod" variant.
It's OK for trunk as far as I'm concerned.
Thanks.

Mikael

PS: Regarding redundant initializations: rather have too many than too 
few. ;-)

Re: [Bug fortran/52846] [F2008] Support submodules - part 3/3

[Paul Richard Thomas]

Dear Mikael,

Thanks for your green light!

I have been mulling over the trans-decl part of the patch and having
been wondering if it is necessary. Without optimization, private
entities can be linked to. Given the discussion concerning the
combination of submodules and private entities, I wonder if this is
not sufficient? Within submodule scope, an advisory could be given for
undefined references to suggest recompiling the module without
optimization or making the entities public.

Cheers

Paul

On 3 August 2015 at 12:44, Mikael Morin <mikael.morin@sfr.fr> wrote:
> Le 29/07/2015 17:08, Paul Richard Thomas a écrit :
>>
>> Dear All,
>>
>> On 24 July 2015 at 10:08, Damian Rouson <damian@sourceryinstitute.org>
>> wrote:
>>>
>>> I love this idea and had similar thoughts as well.
>>>
>>> :D
>>>
>>> Sent from my iPhone
>>>
>>>> On Jul 24, 2015, at 1:06 AM, Paul Richard Thomas
>>>> <paul.richard.thomas@gmail.com> wrote:
>>>>
>>>> Dear Mikael,
>>>>
>>>> It had crossed my mind also that a .mod and a .smod file could be
>>>> written. Normally, the .smod files are produced by the submodules
>>>> themselves, so that their descendants can pick up the symbols that
>>>> they generate. There is no reason at all why this could not be
>>>> implemented; early on in the development I did just this, although I
>>>> think that it would now be easier to modify this patch.
>>>>
>>>> One huge advantage of proceeding in this way is that any resulting
>>>> library can be distributed with the .mod file alone so that the
>>>> private entities are never exposed. The penalty is that a second file
>>>> is output.
>>>>
>>>> With best regards
>>>>
>>>> Paul
>>>>
>>
>> Please find attached the implementation of this suggestion.
>>
>> Bootstraps and regtests on FC21/x86_64 - OK for trunk or is the
>> original preferred?
>>
> There hasn't been a lot of voices about this among the other active and less
> active team members.
> I prefer this "private members to separate smod" variant.
> It's OK for trunk as far as I'm concerned.
> Thanks.
>
> Mikael
>
> PS: Regarding redundant initializations: rather have too many than too few.
> ;-)



-- 
Outside of a dog, a book is a man's best friend. Inside of a dog it's
too dark to read.

Groucho Marx

Re: [Bug fortran/52846] [F2008] Support submodules - part 3/3

[Mikael Morin]

Le 03/08/2015 14:36, Paul Richard Thomas a écrit :
> Dear Mikael,
>
> Thanks for your green light!
>
> I have been mulling over the trans-decl part of the patch and having
> been wondering if it is necessary.
You mean marking entities as public?  Or setting the hidden visibility 
attribute?  Or both?
I think both are necessary.

> Without optimization, private
> entities can be linked to. Given the discussion concerning the
> combination of submodules and private entities, I wonder if this is
> not sufficient? Within submodule scope, an advisory could be given for
> undefined references to suggest recompiling the module without
> optimization or making the entities public.
>
About recompiling without optimization:
If the module contains no code, I guess that would be OK.
But otherwise, it would be pretty bad.
And one would have to do the same for submodules of a submodule: the 
parent submodule would be compiled without optimization. :-(

About making the entities public:
I think the goal of submodules is providing a way to specify a 
(hopefully) stable interface free of any internal implementation details 
that users would start playing with if the opportunity was given to 
them.  Making all entities public would go against that.


I've been reading about the hidden visibility attribute since you 
submitted the 3/3 patch(es).  I think it's the right thing. :-)

Mikael

Re: [Bug fortran/52846] [F2008] Support submodules - part 3/3

[Paul Richard Thomas]

Dear Mikael,

Thanks for your comments. I will commit the patch tonight. If folk get
steamed up about .smod files appearing when they compile their
favourite non-submodule-based code, I guess that we can put in a
compilation flag to suppress them. We have plenty of time to tweak
this before the release of 6 branch.

Once committed, I will get on with the documentation and updating of
gfortran wiki.

Cheers

Paul

On 3 August 2015 at 17:39, Mikael Morin <mikael.morin@sfr.fr> wrote:
> Le 03/08/2015 14:36, Paul Richard Thomas a écrit :
>>
>> Dear Mikael,
>>
>> Thanks for your green light!
>>
>> I have been mulling over the trans-decl part of the patch and having
>> been wondering if it is necessary.
>
> You mean marking entities as public?  Or setting the hidden visibility
> attribute?  Or both?
> I think both are necessary.
>
>> Without optimization, private
>> entities can be linked to. Given the discussion concerning the
>> combination of submodules and private entities, I wonder if this is
>> not sufficient? Within submodule scope, an advisory could be given for
>> undefined references to suggest recompiling the module without
>> optimization or making the entities public.
>>
> About recompiling without optimization:
> If the module contains no code, I guess that would be OK.
> But otherwise, it would be pretty bad.
> And one would have to do the same for submodules of a submodule: the parent
> submodule would be compiled without optimization. :-(
>
> About making the entities public:
> I think the goal of submodules is providing a way to specify a (hopefully)
> stable interface free of any internal implementation details that users
> would start playing with if the opportunity was given to them.  Making all
> entities public would go against that.
>
>
> I've been reading about the hidden visibility attribute since you submitted
> the 3/3 patch(es).  I think it's the right thing. :-)
>
> Mikael



-- 
Outside of a dog, a book is a man's best friend. Inside of a dog it's
too dark to read.

Groucho Marx

Re: [Bug fortran/52846] [F2008] Support submodules - part 3/3

[Paul Richard Thomas]

Dear All,

I had some unexpected regressions, which turned out to be associated
with mulling over FX's problem with intrinsic IEEE modules.

Sending        gcc/fortran/ChangeLog
Sending        gcc/fortran/module.c
Sending        gcc/fortran/trans-decl.c
Sending        gcc/testsuite/ChangeLog
Sending        gcc/testsuite/gfortran.dg/public_private_module_2.f90
Sending        gcc/testsuite/gfortran.dg/public_private_module_6.f90
Sending        gcc/testsuite/gfortran.dg/submodule_1.f08
Adding         gcc/testsuite/gfortran.dg/submodule_10.f08
Sending        gcc/testsuite/gfortran.dg/submodule_5.f08
Sending        gcc/testsuite/gfortran.dg/submodule_9.f08
Sending        gcc/testsuite/lib/fortran-modules.exp
Transmitting file data ...........
Committed revision 226622.

The final step is documentation and wiki updates.

Cheers

Paul

On 4 August 2015 at 11:40, Paul Richard Thomas
<paul.richard.thomas@gmail.com> wrote:
> Dear Mikael,
>
> Thanks for your comments. I will commit the patch tonight. If folk get
> steamed up about .smod files appearing when they compile their
> favourite non-submodule-based code, I guess that we can put in a
> compilation flag to suppress them. We have plenty of time to tweak
> this before the release of 6 branch.
>
> Once committed, I will get on with the documentation and updating of
> gfortran wiki.
>
> Cheers
>
> Paul
>
> On 3 August 2015 at 17:39, Mikael Morin <mikael.morin@sfr.fr> wrote:
>> Le 03/08/2015 14:36, Paul Richard Thomas a écrit :
>>>
>>> Dear Mikael,
>>>
>>> Thanks for your green light!
>>>
>>> I have been mulling over the trans-decl part of the patch and having
>>> been wondering if it is necessary.
>>
>> You mean marking entities as public?  Or setting the hidden visibility
>> attribute?  Or both?
>> I think both are necessary.
>>
>>> Without optimization, private
>>> entities can be linked to. Given the discussion concerning the
>>> combination of submodules and private entities, I wonder if this is
>>> not sufficient? Within submodule scope, an advisory could be given for
>>> undefined references to suggest recompiling the module without
>>> optimization or making the entities public.
>>>
>> About recompiling without optimization:
>> If the module contains no code, I guess that would be OK.
>> But otherwise, it would be pretty bad.
>> And one would have to do the same for submodules of a submodule: the parent
>> submodule would be compiled without optimization. :-(
>>
>> About making the entities public:
>> I think the goal of submodules is providing a way to specify a (hopefully)
>> stable interface free of any internal implementation details that users
>> would start playing with if the opportunity was given to them.  Making all
>> entities public would go against that.
>>
>>
>> I've been reading about the hidden visibility attribute since you submitted
>> the 3/3 patch(es).  I think it's the right thing. :-)
>>
>> Mikael
>
>
>
> --
> Outside of a dog, a book is a man's best friend. Inside of a dog it's
> too dark to read.
>
> Groucho Marx



-- 
Outside of a dog, a book is a man's best friend. Inside of a dog it's
too dark to read.

Groucho Marx

Re: [Bug fortran/52846] [F2008] Support submodules - part 3/3

[Toon Moene]

[-- Attachment #1: Type: text/plain, Size: 2793 bytes --]

On 08/03/2015 02:36 PM, Paul Richard Thomas wrote:
> Dear Mikael,
>
> Thanks for your green light!
>
> I have been mulling over the trans-decl part of the patch and having
> been wondering if it is necessary. Without optimization, private
> entities can be linked to. Given the discussion concerning the
> combination of submodules and private entities, I wonder if this is
> not sufficient? Within submodule scope, an advisory could be given for
> undefined references to suggest recompiling the module without
> optimization or making the entities public.
>
> Cheers
>
> Paul
>
> On 3 August 2015 at 12:44, Mikael Morin <mikael.morin@sfr.fr> wrote:
>> Le 29/07/2015 17:08, Paul Richard Thomas a écrit :
>>>
>>> Dear All,
>>>
>>> On 24 July 2015 at 10:08, Damian Rouson <damian@sourceryinstitute.org>
>>> wrote:
>>>>
>>>> I love this idea and had similar thoughts as well.
>>>>
>>>> :D
>>>>
>>>> Sent from my iPhone
>>>>
>>>>> On Jul 24, 2015, at 1:06 AM, Paul Richard Thomas
>>>>> <paul.richard.thomas@gmail.com> wrote:
>>>>>
>>>>> Dear Mikael,
>>>>>
>>>>> It had crossed my mind also that a .mod and a .smod file could be
>>>>> written. Normally, the .smod files are produced by the submodules
>>>>> themselves, so that their descendants can pick up the symbols that
>>>>> they generate. There is no reason at all why this could not be
>>>>> implemented; early on in the development I did just this, although I
>>>>> think that it would now be easier to modify this patch.
>>>>>
>>>>> One huge advantage of proceeding in this way is that any resulting
>>>>> library can be distributed with the .mod file alone so that the
>>>>> private entities are never exposed. The penalty is that a second file
>>>>> is output.
>>>>>
>>>>> With best regards
>>>>>
>>>>> Paul
>>>>>
>>>
>>> Please find attached the implementation of this suggestion.
>>>
>>> Bootstraps and regtests on FC21/x86_64 - OK for trunk or is the
>>> original preferred?
>>>
>> There hasn't been a lot of voices about this among the other active and less
>> active team members.
>> I prefer this "private members to separate smod" variant.
>> It's OK for trunk as far as I'm concerned.
>> Thanks.
>>
>> Mikael
>>
>> PS: Regarding redundant initializations: rather have too many than too few.
>> ;-)

Although I do not immediately know if this is relevant for *this* 
debate, J3 passed the following (attached) interpretation on submodules 
the past week (it still has to go to several mail ballots, but still), 
overwhelmingly prefering option 3:

[attached]

Kind regards,

-- 
Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news

[-- Attachment #2: 15-208.txt --]
[-- Type: text/plain, Size: 7316 bytes --]

                                                     J3/15-208
To: J3
From: Malcolm Cohen
Subject: Interp of USE and submodules
Date: 2015 August 06


1. Introduction

Three options are provided for the answer to this interp:

Option 1: Basically what the actual text of the standard says now.
          Accessing a PROTECTED item by a USE statement will hide the
          host association, and therefore the item will be protected.

Option 2: Continue to allow a submodule to USE its ancestor, but say
          that PROTECTED has no effect in this case.

Option 3: Decide that it was a mistake to allow a submodule to access
          its ancestor module by use association, and forbid it.

2. The interpretation request

----------------------------------------------------------------------

NUMBER: F08/0128
TITLE: Is recursive USE within a submodule permitted?
KEYWORDS: SUBMODULE, USE
DEFECT TYPE: Erratum
STATUS: J3 consideration in progress

QUESTION:

Consider
  Module m1
    Real x
  End Module
  Submodule(m1) subm1
    Use m1
  End Submodule

Q1. The module m1 is referenced from within one of its own
    submodules.  Is this standard-conforming?

Note that the "submodule TR", Technical Report 19767 contains, an edit
with the normative requirement:
  "A submodule shall not reference its ancestor module by use
   association, either directly or indirectly."
along with a note which says
  "It is possible for submodules with different ancestor modules to
   access each other's ancestor modules by use association."
It also contains an edit to insert the direct reference prohibition
as a constraint.

However, none of this text appears in ISO/IEC 1539-1:2010.

The Introduction simply comments that submodules are available, but
not that they have been extended beyond the Technical Report that
created them.

Also, consider

  Module m2
    Real, Private :: a
    Real, Protected :: b
    ...
  End Module
  Submodule(m2) subm2
  Contains
    Subroutine s
      Use m2
      Implicit None
      a = 3
      b = 4
    End Subroutine
  End Submodule

In submodule SUBM2, procedure S references M2 by use association.
Use association does not make "A" accessible.

Q2. Is "A" still accessible by host association?

Also, procedure S attempts to assign a value to B, which is accessed
by use association, but has the PROTECTED attribute.  Normally, this
attribute prevents assignment to variables accessed by use
association.

Q3. Is the assignment to "B" standard-conforming?

DISCUSSION:

The requirement appears in the early drafts of Fortran 2008, up to
08-007r1, then it was modified by paper 08-154r1 creating a UTI
(because the modification was broken), and finally the requirement was
completely removed by paper 09-141.

ANSWER OPTION 1:

A1. Yes, the example is conforming.  An edit is supplied to add this
    extension to the Introduction, and to add normative text to clause
    11 to make this completely unambiguous.

A2. Yes, A is still accessible by host association.
    Subclause 16.5.1.4 paragraph 2 states
      "If an entity that is accessed by use association has the same
       nongeneric name as a host entity, the host entity is
       inaccessible by that name."
    This does not apply since A is not being accessed by use
    association (because it is PRIVATE), therefore A can still be
    accessed by host association.
{J3 note: no edit necessary here.}

A3. No, the assignment to B is not conforming as it violates
    constraint C551 which states
      "A nonpointer object that has the PROTECTED attribute and is
       accessed by use association shall not appear in a variable
       definition context..."
    An edit is provided to add an explanation of this.

ANSWER OPTION 2:

A1. Yes, the example is conforming.  An edit is supplied to add this
    extension to the Introduction, and to add normative text to clause
    11 to make this completely unambiguous.

A2. Yes, A is still accessible by host association.
    Subclause 16.5.1.4 paragraph 2 states
      "If an entity that is accessed by use association has the same
       nongeneric name as a host entity, the host entity is
       inaccessible by that name."
    This does not apply since A is not being accessed by use
    association (because it is PRIVATE), therefore A can still be
    accessed by host association.
{J3 note: no edit necessary here.}

A3. The assignment to B was intended to be conforming.
    An edit is provided to correct constraint C551 to permit this.

ANSWER OPTION 3:

A1. No, the example was not intended to be conforming.  Permission for
    a submodule to access its ancestor module by use associated was a
    mistake.  An edit is provided to correct this error.

A2. Moot.

A3. Moot.

EDITS OPTION 1:

[xv] Introduction, p2, first bullet,
  After "Submodules provide ... for modules."
  Insert new sentence
    "A submodule can reference its ancestor module by use
     association."

[100:12] 5.3.15 PROTECTED attribute, insert this text immediately after
         the word "descendants" (i.e. before the comma)
         "where it is accessed by host association".

[272:23] 11.2.2 The USE statement and use association, p1,
  After
    "A module shall not reference itself, either directly or
     indirectly."
  Append to paragraph
    "A submodule is permitted to reference its ancestor module by
     use association.  "

[273:2+4] Same subclause, NOTE 11.7, append
  "If a submodule accesses a PROTECTED entity from its ancestor
   module by use association, use of that entity is constrained by
   the PROTECTED attribute, e.g. if it is not a pointer it cannot
   appear in a variable definition context.".

EDITS OPTION 2:

[xv] Introduction, p2, first bullet,
  After "Submodules provide ... for modules."
  Insert new sentence
    "A submodule can reference its ancestor module by use
     association."

[100:6] 5.3.15 PROTECTED attribute, C551,
  After "and is accessed by use association"
  insert "from a scoping unit that is not within a submodule
          of the module containing the definition of the
          PROTECTED entity"
{Remove PROTECTED effect from ancestor module variables.}

[100:9] same subclause, C552,
        same edit.
{Remove PROTECTED effect from ancestor module pointers.}

[272:23] 11.2.2 The USE statement and use association, p1,
  After
    "A module shall not reference itself, either directly or
     indirectly."
  Append to paragraph
    "A submodule is permitted to reference its ancestor module by
     use association.  "

EDITS OPTION 3:

[275:9+] 11.2.3 Submodules,
         "A submodule shall not reference its ancestor module by
          use association, either directly or indirectly."
{NOTE TO J3: This could be inserted at [272:23] if that is thought
 to be a better place.}

SUBMITTED BY: Malcolm Cohen

HISTORY: 15-134    m206  F08/0128 submitted
         15-134r1  m206  Revised edits - passed by J3 meeting
         15-187    m207  Failed J3 letter ballot 15-159
         15-nnn    m207  Revised with 3 options

----------------------------------------------------------------------

AW: [Bug fortran/52846] [F2008] Support submodules - part 3/3

[Bader, Reinhold]

[-- Attachment #1: Type: text/plain, Size: 2549 bytes --]

Hello Toon, all else, 

a bit unfortunate, in my opinion (I was present at the discussion). 
I've in the meantime taken some effort to implement what the design pattern 
experts might call an "abstract factory with full dependency inversion" as 
a bare-bones framework and have attached an archive with three variants:

* pre_interp contains the code that is presently valid (and indeed compiles fine
   with both gfortran and ifort), but would become invalid due to indirect
   parent module access
* post_interp contains a variant that uses a helper module (mod_glue) to avoid
   the indirect ancestor use access (if there is a more concise way to do this, 
   I'd like to know ... up to now this is the best I can do)
* post_interp_v2 another shorter variant that pushes the extension types into a submodule
   (with the disadvantage that these types are not really reusable, and
    that the monster module problem is shifted to a monster submodule, or a chain of
    submodules)
You may need to edit the Makefiles to build. 

I would of course like to know how people feel about reintroducing this restriction, 
especially since the only reason given was that ancestor module access and its
use association overriding host association would confuse users ... which is a 
problem which in my opinion could have been dealt with in a slightly different
manner without removing the  permission for indirect parent module-referencing 
use statements. It is not clear to me whether *implementations* other than 
gfortran have problems with this, though.

More germane to this thread's discussion actually is another interp that was also passed, 
and which appears entirely uncontroversial:
http://j3-fortran.org/doc/meeting/207/15-209.txt 
It seems to me that this would permit avoiding generation of the .smod files for
modules that do not specify an separate module procedure interface.

Cheers
Reinhold
 
> -----Ursprüngliche Nachricht-----
> 
> Although I do not immediately know if this is relevant for *this*
> debate, J3 passed the following (attached) interpretation on submodules
> the past week (it still has to go to several mail ballots, but still),
> overwhelmingly prefering option 3:
> 
> [attached]
> 
> Kind regards,
> 
> --
> Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290
> Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
> At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
> Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news

[-- Attachment #2: examples.tgz --]
[-- Type: application/x-compressed, Size: 1631 bytes --]

Re: [Bug fortran/52846] [F2008] Support submodules - part 3/3

[Paul Richard Thomas]

Dear All,

Has this been occasioned by this thread or have other makes
encountered the same difficulty in implementation?

Cheers

Paul

On 10 August 2015 at 20:57, Bader, Reinhold <Reinhold.Bader@lrz.de> wrote:
> Hello Toon, all else,
>
> a bit unfortunate, in my opinion (I was present at the discussion).
> I've in the meantime taken some effort to implement what the design pattern
> experts might call an "abstract factory with full dependency inversion" as
> a bare-bones framework and have attached an archive with three variants:
>
> * pre_interp contains the code that is presently valid (and indeed compiles fine
>    with both gfortran and ifort), but would become invalid due to indirect
>    parent module access
> * post_interp contains a variant that uses a helper module (mod_glue) to avoid
>    the indirect ancestor use access (if there is a more concise way to do this,
>    I'd like to know ... up to now this is the best I can do)
> * post_interp_v2 another shorter variant that pushes the extension types into a submodule
>    (with the disadvantage that these types are not really reusable, and
>     that the monster module problem is shifted to a monster submodule, or a chain of
>     submodules)
> You may need to edit the Makefiles to build.
>
> I would of course like to know how people feel about reintroducing this restriction,
> especially since the only reason given was that ancestor module access and its
> use association overriding host association would confuse users ... which is a
> problem which in my opinion could have been dealt with in a slightly different
> manner without removing the  permission for indirect parent module-referencing
> use statements. It is not clear to me whether *implementations* other than
> gfortran have problems with this, though.
>
> More germane to this thread's discussion actually is another interp that was also passed,
> and which appears entirely uncontroversial:
> http://j3-fortran.org/doc/meeting/207/15-209.txt
> It seems to me that this would permit avoiding generation of the .smod files for
> modules that do not specify an separate module procedure interface.
>
> Cheers
> Reinhold
>
>> -----Ursprüngliche Nachricht-----
>>
>> Although I do not immediately know if this is relevant for *this*
>> debate, J3 passed the following (attached) interpretation on submodules
>> the past week (it still has to go to several mail ballots, but still),
>> overwhelmingly prefering option 3:
>>
>> [attached]
>>
>> Kind regards,
>>
>> --
>> Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290
>> Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
>> At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
>> Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news



-- 
Outside of a dog, a book is a man's best friend. Inside of a dog it's
too dark to read.

Groucho Marx

AW: [Bug fortran/52846] [F2008] Support submodules - part 3/3

[Bader, Reinhold]

Hello Paul, 

To my knowledge, the J3 interp F08/128 was triggered by a question coming from Bill Long from Cray. 
The interp's text was written by the Fortran standard's editor. So there is no direct relation to this thread.

F08/0142 (useless submodules) was in turn triggered by the example given for F08/128, by Daniel Chen from IBM.
And indeed this seems to have caused some grief to other implementors.

Cheers
Reinhold

> -----Ursprüngliche Nachricht-----
> Von: Paul Richard Thomas [mailto:paul.richard.thomas@gmail.com]
> Gesendet: Dienstag, 11. August 2015 12:28
> An: Bader, Reinhold <Reinhold.Bader@lrz.de>
> Cc: Toon Moene <toon@moene.org>; Mikael Morin <mikael.morin@sfr.fr>;
> Damian Rouson <damian@sourceryinstitute.org>; fortran@gcc.gnu.org; gcc-
> patches <gcc-patches@gcc.gnu.org>; salvatore.filippone@uniroma2.it
> Betreff: Re: [Bug fortran/52846] [F2008] Support submodules - part 3/3
> 
> Dear All,
> 
> Has this been occasioned by this thread or have other makes encountered the
> same difficulty in implementation?
> 
> Cheers
> 
> Paul
> 
> On 10 August 2015 at 20:57, Bader, Reinhold <Reinhold.Bader@lrz.de> wrote:
> > Hello Toon, all else,
> >
> > a bit unfortunate, in my opinion (I was present at the discussion).
> > I've in the meantime taken some effort to implement what the design
> > pattern experts might call an "abstract factory with full dependency
> > inversion" as a bare-bones framework and have attached an archive with three
> variants:
> >
> > * pre_interp contains the code that is presently valid (and indeed compiles fine
> >    with both gfortran and ifort), but would become invalid due to indirect
> >    parent module access
> > * post_interp contains a variant that uses a helper module (mod_glue) to avoid
> >    the indirect ancestor use access (if there is a more concise way to do this,
> >    I'd like to know ... up to now this is the best I can do)
> > * post_interp_v2 another shorter variant that pushes the extension types into
> a submodule
> >    (with the disadvantage that these types are not really reusable, and
> >     that the monster module problem is shifted to a monster submodule, or a
> chain of
> >     submodules)
> > You may need to edit the Makefiles to build.
> >
> > I would of course like to know how people feel about reintroducing
> > this restriction, especially since the only reason given was that
> > ancestor module access and its use association overriding host
> > association would confuse users ... which is a problem which in my
> > opinion could have been dealt with in a slightly different manner
> > without removing the  permission for indirect parent
> > module-referencing use statements. It is not clear to me whether
> *implementations* other than gfortran have problems with this, though.
> >
> > More germane to this thread's discussion actually is another interp
> > that was also passed, and which appears entirely uncontroversial:
> > http://j3-fortran.org/doc/meeting/207/15-209.txt
> > It seems to me that this would permit avoiding generation of the .smod
> > files for modules that do not specify an separate module procedure interface.
> >
> > Cheers
> > Reinhold
> >
> >> -----Ursprüngliche Nachricht-----
> >>
> >> Although I do not immediately know if this is relevant for *this*
> >> debate, J3 passed the following (attached) interpretation on
> >> submodules the past week (it still has to go to several mail ballots,
> >> but still), overwhelmingly prefering option 3:
> >>
> >> [attached]
> >>
> >> Kind regards,
> >>
> >> --
> >> Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290
> >> Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands At home:
> >> http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress
> >> of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
> 
> 
> 
> --
> Outside of a dog, a book is a man's best friend. Inside of a dog it's too dark to
> read.
> 
> Groucho Marx

Re: [Bug fortran/52846] [F2008] Support submodules - part 3/3

[Paul Richard Thomas]

Dear Reinhold,

I am glad that it was not just me being anxious about the issue!

For a day or two, I am somewhat distracted by loading up a new Lenovo
workstation and installing a xeon phi on it. Given the current insane
low price of the BC31S1P, I thought to see how best to allow gfortran
to make use of the Knight's Corner vector processor. I will start with
a vector class and associated methods. Combined with coarrays, it
should be possible to get a reasonable performance out of the phi.
After that, well we will see...

Cheers

Paul



On 11 August 2015 at 13:17, Bader, Reinhold <Reinhold.Bader@lrz.de> wrote:
> Hello Paul,
>
> To my knowledge, the J3 interp F08/128 was triggered by a question coming from Bill Long from Cray.
> The interp's text was written by the Fortran standard's editor. So there is no direct relation to this thread.
>
> F08/0142 (useless submodules) was in turn triggered by the example given for F08/128, by Daniel Chen from IBM.
> And indeed this seems to have caused some grief to other implementors.
>
> Cheers
> Reinhold
>
>> -----Ursprüngliche Nachricht-----
>> Von: Paul Richard Thomas [mailto:paul.richard.thomas@gmail.com]
>> Gesendet: Dienstag, 11. August 2015 12:28
>> An: Bader, Reinhold <Reinhold.Bader@lrz.de>
>> Cc: Toon Moene <toon@moene.org>; Mikael Morin <mikael.morin@sfr.fr>;
>> Damian Rouson <damian@sourceryinstitute.org>; fortran@gcc.gnu.org; gcc-
>> patches <gcc-patches@gcc.gnu.org>; salvatore.filippone@uniroma2.it
>> Betreff: Re: [Bug fortran/52846] [F2008] Support submodules - part 3/3
>>
>> Dear All,
>>
>> Has this been occasioned by this thread or have other makes encountered the
>> same difficulty in implementation?
>>
>> Cheers
>>
>> Paul
>>
>> On 10 August 2015 at 20:57, Bader, Reinhold <Reinhold.Bader@lrz.de> wrote:
>> > Hello Toon, all else,
>> >
>> > a bit unfortunate, in my opinion (I was present at the discussion).
>> > I've in the meantime taken some effort to implement what the design
>> > pattern experts might call an "abstract factory with full dependency
>> > inversion" as a bare-bones framework and have attached an archive with three
>> variants:
>> >
>> > * pre_interp contains the code that is presently valid (and indeed compiles fine
>> >    with both gfortran and ifort), but would become invalid due to indirect
>> >    parent module access
>> > * post_interp contains a variant that uses a helper module (mod_glue) to avoid
>> >    the indirect ancestor use access (if there is a more concise way to do this,
>> >    I'd like to know ... up to now this is the best I can do)
>> > * post_interp_v2 another shorter variant that pushes the extension types into
>> a submodule
>> >    (with the disadvantage that these types are not really reusable, and
>> >     that the monster module problem is shifted to a monster submodule, or a
>> chain of
>> >     submodules)
>> > You may need to edit the Makefiles to build.
>> >
>> > I would of course like to know how people feel about reintroducing
>> > this restriction, especially since the only reason given was that
>> > ancestor module access and its use association overriding host
>> > association would confuse users ... which is a problem which in my
>> > opinion could have been dealt with in a slightly different manner
>> > without removing the  permission for indirect parent
>> > module-referencing use statements. It is not clear to me whether
>> *implementations* other than gfortran have problems with this, though.
>> >
>> > More germane to this thread's discussion actually is another interp
>> > that was also passed, and which appears entirely uncontroversial:
>> > http://j3-fortran.org/doc/meeting/207/15-209.txt
>> > It seems to me that this would permit avoiding generation of the .smod
>> > files for modules that do not specify an separate module procedure interface.
>> >
>> > Cheers
>> > Reinhold
>> >
>> >> -----Ursprüngliche Nachricht-----
>> >>
>> >> Although I do not immediately know if this is relevant for *this*
>> >> debate, J3 passed the following (attached) interpretation on
>> >> submodules the past week (it still has to go to several mail ballots,
>> >> but still), overwhelmingly prefering option 3:
>> >>
>> >> [attached]
>> >>
>> >> Kind regards,
>> >>
>> >> --
>> >> Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290
>> >> Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands At home:
>> >> http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress
>> >> of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
>>
>>
>>
>> --
>> Outside of a dog, a book is a man's best friend. Inside of a dog it's too dark to
>> read.
>>
>> Groucho Marx



-- 
Outside of a dog, a book is a man's best friend. Inside of a dog it's
too dark to read.

Groucho Marx

Re: [Bug fortran/52846] [F2008] Support submodules - part 3/3

[Salvatore Filippone]

I agree with Paul that this is orthogonal to the compilation cascade
phenomenon.

In my opinion, putting PRIVATE entities in a module does not make much
sense (yes, I know my example does it, but it is a quick adaptation of
an existing code, not a clean design). If the main MODULE only contains
the public interfaces, then all those PRIVATE entities really belong to
the submodule together with the implementation(s) that use them. Even
though within the submodule they can  not formally have the PRIVATE
attribute, they would still be invisible outside the submodule,
therefore the end result would be the same.

I have not yet enough experience to say whether I am totally comfortable
with submodules as they are; however it seems to me that most of the
doubts voiced so far  depend more on programmer's discipline than on
language facilities.


Salvatore


Il giorno gio, 23/07/2015 alle 10.37 +0200, Paul Richard Thomas ha
scritto:
> Dear Damian,
>
> I do not think that there is any effect on compilation cascades. As
> long as the private part of the module file remains unchanged, it will
> not be recompiled if a descendant submodule is modified. Naturally,
> the size of the module file is increased but, if one is careful, this
> is not a big deal. A gotcha, which I will have to emphasize in the
> documentation occurs if another module file is used and its symbols
> are not exposed by public statements. If there are large numbers of
> symbols this can have a big effect on the size of the module file. I
> noticed this, when examining one of gfortran's testcases where the
> ISO_C_BINDING intrinsic module is used. Generous sprinklings of USE
> ONLYs are required to keep the module file sizes under control.
>
> I am not over enthusiastic about using compilation flags to uphold
> standards either.
>
> Cheers
>
> Paul