[Bug fortran/52846] [F2008] Support submodules

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846
Bug 52846 depends on bug 66762, which changed state.

Bug 66762 Summary: ICE when compiling gfortran.dg/submodule_[16].f90 with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66762

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug fortran/52846] [F2008] Support submodules

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846

Paul Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #28 from Paul Thomas  ---
The LTO issue is another PR, so closing this one

Paul

[Bug fortran/52846] [F2008] Support submodules

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846

--- Comment #27 from Paul Thomas  ---
Author: pault
Date: Thu Sep 17 09:09:34 2015
New Revision: 227855

URL: https://gcc.gnu.org/viewcvs?rev=227855=gcc=rev
Log:
2015-09-17  Paul Thomas  

PR fortran/52846
PR fortran/67588
* module.c : Add static no_module_procedures.
(gfc_match_submodule): Correct memory leakage caused during the
freeing of use_lists.
(mio_symbol_attribute): Reset above if module procedure is
encountered.
(gfc_dump_module): Set above and exit without writing smod file
if it reset.
* gfortran.texi : Add section on submodule support.

2015-09-17  Paul Thomas  

PR fortran/52846
* gfortran.dg/public_private_module_5.f90: Add module procedure
trigger_smod to ensure that the smod file is written.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.texi
trunk/gcc/fortran/module.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/submodule_5.f08

[Bug fortran/52846] [F2008] Support submodules

[Joost.VandeVondele at mat dot ethz.ch]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846

--- Comment #26 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 
---
One more datapoint on the .smod / .mod issue. 

I ran into the first package that fails to build with 6.0 because of this.
libxc (version 2.2.2, Tobias Burnus actually being one of the authors), relies
on a configure macro named ax_cv_f90_modext this macro now leads in the
Makefile to :

[...]
am__untar = $${TAR-tar} xf -
ax_cv_f90_modext = mod
smod
bindir = ${exec_prefix}/bin
[...]

which leads to an obvious: make -j
Makefile:319: *** missing separator.  Stop.

While arguably this is a bug in the ax_cv_f90_modext macro, it might be
indicative of possible problems 'in the wild'.

However, I do like the idea of having only public info in the .mod, and hence
improving the recompilation cascade problem.

[Bug fortran/52846] [F2008] Support submodules

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846

--- Comment #25 from Paul Thomas pault at gcc dot gnu.org ---
Author: pault
Date: Wed Aug  5 12:06:25 2015
New Revision: 226622

URL: https://gcc.gnu.org/viewcvs?rev=226622root=gccview=rev
Log:
2015-08-05  Paul Thomas  pa...@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-08-05  Paul Thomas  pa...@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

Added:
trunk/gcc/testsuite/gfortran.dg/submodule_10.f08
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/module.c
trunk/gcc/fortran/trans-decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/public_private_module_2.f90
trunk/gcc/testsuite/gfortran.dg/public_private_module_6.f90
trunk/gcc/testsuite/gfortran.dg/submodule_1.f08
trunk/gcc/testsuite/gfortran.dg/submodule_5.f08
trunk/gcc/testsuite/gfortran.dg/submodule_9.f08
trunk/gcc/testsuite/lib/fortran-modules.exp

[Bug fortran/52846] [F2008] Support submodules

[Joost.VandeVondele at mat dot ethz.ch]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846

Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:

   What|Removed |Added

 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch

--- Comment #24 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 
---
(In reply to Paul Thomas from comment #23)

   (gfc_dump_module): If current state is COMP_SUBMODULE, write
   to file 'submodule_name', using SUBMODULE_EXTENSION.

just a comment / question. I wonder if the use of a different extension makes
life more easy / more difficult for people using dependencies based on .mod
files to stop recompilation cascades, or other aspects of the build system. I
haven't looked carefully enough at the submodule feature to know, but maybe it
is worth thinking about. Similarly, if the .smod changes, while this reflect in
a .mod timestamp change. 

There is obviously no standard requirement on this, but this gfortran feature
is very useful for those who develop  recompile large Fortran projects.

[Bug fortran/52846] [F2008] Support submodules

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846

--- Comment #15 from Paul Thomas pault at gcc dot gnu.org ---
Author: pault
Date: Fri Jul 17 17:23:45 2015
New Revision: 225945

URL: https://gcc.gnu.org/viewcvs?rev=225945root=gccview=rev
Log:
2015-07-17  Paul Thomas  pa...@gcc.gnu.org

PR fortran/52846
* decl.c (gfc_match_end): Pick out declared submodule name from
the composite identifier.
* gfortran.h : Add 'submodule_name' to gfc_use_list structure.
* module.c (gfc_match_submodule): Define submodule_name and add
static 'submodule_name'.
(gfc_match_submodule): Build up submodule filenames, using '@'
as a delimiter. Store the output filename in 'submodule_name'.
Similarly, the submodule identifier is built using '.' as an
identifier.
(gfc_dump_module): If current state is COMP_SUBMODULE, write
to file 'submodule_name', using SUBMODULE_EXTENSION.
(gfc_use_module): Similarly, use the 'submodule_name' field in
the gfc_use_list structure and SUBMODULE_EXTENSION to read the
implicitly used submodule files.

2015-07-17  Paul Thomas  pa...@gcc.gnu.org

PR fortran/52846
* lib/fortran-modules.exp (proc cleanup-submodules): New
procedure.
* gfortran.dg/submodule_1.f08: Change extension and clean up
the submodule files.
* gfortran.dg/submodule_2.f08: ditto
* gfortran.dg/submodule_6.f08: ditto
* gfortran.dg/submodule_7.f08: ditto
* gfortran.dg/submodule_8.f08: New test
* gfortran.dg/submodule_9.f08: New test

Added:
trunk/gcc/testsuite/gfortran.dg/submodule_1.f08
  - copied, changed from r225943,
trunk/gcc/testsuite/gfortran.dg/submodule_1.f90
Removed:
trunk/gcc/testsuite/gfortran.dg/submodule_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/module.c
trunk/gcc/testsuite/lib/fortran-modules.exp

[Bug fortran/52846] [F2008] Support submodules

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846

--- Comment #18 from Paul Thomas pault at gcc dot gnu.org ---
Author: pault
Date: Fri Jul 17 17:25:04 2015
New Revision: 225948

URL: https://gcc.gnu.org/viewcvs?rev=225948root=gccview=rev
Log:
2015-07-17  Paul Thomas  pa...@gcc.gnu.org

PR fortran/52846
* decl.c (gfc_match_end): Pick out declared submodule name from
the composite identifier.
* gfortran.h : Add 'submodule_name' to gfc_use_list structure.
* module.c (gfc_match_submodule): Define submodule_name and add
static 'submodule_name'.
(gfc_match_submodule): Build up submodule filenames, using '@'
as a delimiter. Store the output filename in 'submodule_name'.
Similarly, the submodule identifier is built using '.' as an
identifier.
(gfc_dump_module): If current state is COMP_SUBMODULE, write
to file 'submodule_name', using SUBMODULE_EXTENSION.
(gfc_use_module): Similarly, use the 'submodule_name' field in
the gfc_use_list structure and SUBMODULE_EXTENSION to read the
implicitly used submodule files.

2015-07-17  Paul Thomas  pa...@gcc.gnu.org

PR fortran/52846
* lib/fortran-modules.exp (proc cleanup-submodules): New
procedure.
* gfortran.dg/submodule_1.f08: Change extension and clean up
the submodule files.
* gfortran.dg/submodule_2.f08: ditto
* gfortran.dg/submodule_6.f08: ditto
* gfortran.dg/submodule_7.f08: ditto
* gfortran.dg/submodule_8.f08: New test
* gfortran.dg/submodule_9.f08: New test

Added:
trunk/gcc/testsuite/gfortran.dg/submodule_4.f08
  - copied unchanged from r225922,
trunk/gcc/testsuite/gfortran.dg/submodule_4.f90
Removed:
trunk/gcc/testsuite/gfortran.dg/submodule_4.f90

[Bug fortran/52846] [F2008] Support submodules

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846

--- Comment #17 from Paul Thomas pault at gcc dot gnu.org ---
Author: pault
Date: Fri Jul 17 17:24:49 2015
New Revision: 225947

URL: https://gcc.gnu.org/viewcvs?rev=225947root=gccview=rev
Log:
2015-07-17  Paul Thomas  pa...@gcc.gnu.org

PR fortran/52846
* decl.c (gfc_match_end): Pick out declared submodule name from
the composite identifier.
* gfortran.h : Add 'submodule_name' to gfc_use_list structure.
* module.c (gfc_match_submodule): Define submodule_name and add
static 'submodule_name'.
(gfc_match_submodule): Build up submodule filenames, using '@'
as a delimiter. Store the output filename in 'submodule_name'.
Similarly, the submodule identifier is built using '.' as an
identifier.
(gfc_dump_module): If current state is COMP_SUBMODULE, write
to file 'submodule_name', using SUBMODULE_EXTENSION.
(gfc_use_module): Similarly, use the 'submodule_name' field in
the gfc_use_list structure and SUBMODULE_EXTENSION to read the
implicitly used submodule files.

2015-07-17  Paul Thomas  pa...@gcc.gnu.org

PR fortran/52846
* lib/fortran-modules.exp (proc cleanup-submodules): New
procedure.
* gfortran.dg/submodule_1.f08: Change extension and clean up
the submodule files.
* gfortran.dg/submodule_2.f08: ditto
* gfortran.dg/submodule_6.f08: ditto
* gfortran.dg/submodule_7.f08: ditto
* gfortran.dg/submodule_8.f08: New test
* gfortran.dg/submodule_9.f08: New test

Added:
trunk/gcc/testsuite/gfortran.dg/submodule_3.f08
  - copied unchanged from r225922,
trunk/gcc/testsuite/gfortran.dg/submodule_3.f90
Removed:
trunk/gcc/testsuite/gfortran.dg/submodule_3.f90

[Bug fortran/52846] [F2008] Support submodules

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846

--- Comment #16 from Paul Thomas pault at gcc dot gnu.org ---
Author: pault
Date: Fri Jul 17 17:24:32 2015
New Revision: 225946

URL: https://gcc.gnu.org/viewcvs?rev=225946root=gccview=rev
Log:
2015-07-17  Paul Thomas  pa...@gcc.gnu.org

PR fortran/52846
* decl.c (gfc_match_end): Pick out declared submodule name from
the composite identifier.
* gfortran.h : Add 'submodule_name' to gfc_use_list structure.
* module.c (gfc_match_submodule): Define submodule_name and add
static 'submodule_name'.
(gfc_match_submodule): Build up submodule filenames, using '@'
as a delimiter. Store the output filename in 'submodule_name'.
Similarly, the submodule identifier is built using '.' as an
identifier.
(gfc_dump_module): If current state is COMP_SUBMODULE, write
to file 'submodule_name', using SUBMODULE_EXTENSION.
(gfc_use_module): Similarly, use the 'submodule_name' field in
the gfc_use_list structure and SUBMODULE_EXTENSION to read the
implicitly used submodule files.

2015-07-17  Paul Thomas  pa...@gcc.gnu.org

PR fortran/52846
* lib/fortran-modules.exp (proc cleanup-submodules): New
procedure.
* gfortran.dg/submodule_1.f08: Change extension and clean up
the submodule files.
* gfortran.dg/submodule_2.f08: ditto
* gfortran.dg/submodule_6.f08: ditto
* gfortran.dg/submodule_7.f08: ditto
* gfortran.dg/submodule_8.f08: New test
* gfortran.dg/submodule_9.f08: New test

Added:
trunk/gcc/testsuite/gfortran.dg/submodule_2.f08
  - copied, changed from r225922,
trunk/gcc/testsuite/gfortran.dg/submodule_2.f90
Removed:
trunk/gcc/testsuite/gfortran.dg/submodule_2.f90

[Bug fortran/52846] [F2008] Support submodules

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846

--- Comment #22 from Paul Thomas pault at gcc dot gnu.org ---
Author: pault
Date: Fri Jul 17 17:27:42 2015
New Revision: 225957

URL: https://gcc.gnu.org/viewcvs?rev=225957root=gccview=rev
Log:
2015-07-17  Paul Thomas  pa...@gcc.gnu.org

PR fortran/52846
* decl.c (gfc_match_end): Pick out declared submodule name from
the composite identifier.
* gfortran.h : Add 'submodule_name' to gfc_use_list structure.
* module.c (gfc_match_submodule): Define submodule_name and add
static 'submodule_name'.
(gfc_match_submodule): Build up submodule filenames, using '@'
as a delimiter. Store the output filename in 'submodule_name'.
Similarly, the submodule identifier is built using '.' as an
identifier.
(gfc_dump_module): If current state is COMP_SUBMODULE, write
to file 'submodule_name', using SUBMODULE_EXTENSION.
(gfc_use_module): Similarly, use the 'submodule_name' field in
the gfc_use_list structure and SUBMODULE_EXTENSION to read the
implicitly used submodule files.

2015-07-17  Paul Thomas  pa...@gcc.gnu.org

PR fortran/52846
* lib/fortran-modules.exp (proc cleanup-submodules): New
procedure.
* gfortran.dg/submodule_1.f08: Change extension and clean up
the submodule files.
* gfortran.dg/submodule_2.f08: ditto
* gfortran.dg/submodule_6.f08: ditto
* gfortran.dg/submodule_7.f08: ditto
* gfortran.dg/submodule_8.f08: New test
* gfortran.dg/submodule_9.f08: New test

Added:
trunk/gcc/testsuite/gfortran.dg/submodule_8.f08
trunk/gcc/testsuite/gfortran.dg/submodule_9.f08

[Bug fortran/52846] [F2008] Support submodules

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846

--- Comment #19 from Paul Thomas pault at gcc dot gnu.org ---
Author: pault
Date: Fri Jul 17 17:25:55 2015
New Revision: 225953

URL: https://gcc.gnu.org/viewcvs?rev=225953root=gccview=rev
Log:
2015-07-17  Paul Thomas  pa...@gcc.gnu.org

PR fortran/52846
* decl.c (gfc_match_end): Pick out declared submodule name from
the composite identifier.
* gfortran.h : Add 'submodule_name' to gfc_use_list structure.
* module.c (gfc_match_submodule): Define submodule_name and add
static 'submodule_name'.
(gfc_match_submodule): Build up submodule filenames, using '@'
as a delimiter. Store the output filename in 'submodule_name'.
Similarly, the submodule identifier is built using '.' as an
identifier.
(gfc_dump_module): If current state is COMP_SUBMODULE, write
to file 'submodule_name', using SUBMODULE_EXTENSION.
(gfc_use_module): Similarly, use the 'submodule_name' field in
the gfc_use_list structure and SUBMODULE_EXTENSION to read the
implicitly used submodule files.

2015-07-17  Paul Thomas  pa...@gcc.gnu.org

PR fortran/52846
* lib/fortran-modules.exp (proc cleanup-submodules): New
procedure.
* gfortran.dg/submodule_1.f08: Change extension and clean up
the submodule files.
* gfortran.dg/submodule_2.f08: ditto
* gfortran.dg/submodule_6.f08: ditto
* gfortran.dg/submodule_7.f08: ditto
* gfortran.dg/submodule_8.f08: New test
* gfortran.dg/submodule_9.f08: New test

Added:
trunk/gcc/testsuite/gfortran.dg/submodule_5.f08
  - copied unchanged from r225922,
trunk/gcc/testsuite/gfortran.dg/submodule_5.f90
Removed:
trunk/gcc/testsuite/gfortran.dg/submodule_5.f90

[Bug fortran/52846] [F2008] Support submodules

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846

--- Comment #21 from Paul Thomas pault at gcc dot gnu.org ---
Author: pault
Date: Fri Jul 17 17:26:42 2015
New Revision: 225956

URL: https://gcc.gnu.org/viewcvs?rev=225956root=gccview=rev
Log:
2015-07-17  Paul Thomas  pa...@gcc.gnu.org

PR fortran/52846
* decl.c (gfc_match_end): Pick out declared submodule name from
the composite identifier.
* gfortran.h : Add 'submodule_name' to gfc_use_list structure.
* module.c (gfc_match_submodule): Define submodule_name and add
static 'submodule_name'.
(gfc_match_submodule): Build up submodule filenames, using '@'
as a delimiter. Store the output filename in 'submodule_name'.
Similarly, the submodule identifier is built using '.' as an
identifier.
(gfc_dump_module): If current state is COMP_SUBMODULE, write
to file 'submodule_name', using SUBMODULE_EXTENSION.
(gfc_use_module): Similarly, use the 'submodule_name' field in
the gfc_use_list structure and SUBMODULE_EXTENSION to read the
implicitly used submodule files.

2015-07-17  Paul Thomas  pa...@gcc.gnu.org

PR fortran/52846
* lib/fortran-modules.exp (proc cleanup-submodules): New
procedure.
* gfortran.dg/submodule_1.f08: Change extension and clean up
the submodule files.
* gfortran.dg/submodule_2.f08: ditto
* gfortran.dg/submodule_6.f08: ditto
* gfortran.dg/submodule_7.f08: ditto
* gfortran.dg/submodule_8.f08: New test
* gfortran.dg/submodule_9.f08: New test

Added:
trunk/gcc/testsuite/gfortran.dg/submodule_7.f08
  - copied, changed from r225922,
trunk/gcc/testsuite/gfortran.dg/submodule_7.f90
Removed:
trunk/gcc/testsuite/gfortran.dg/submodule_7.f90

[Bug fortran/52846] [F2008] Support submodules

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846

--- Comment #20 from Paul Thomas pault at gcc dot gnu.org ---
Author: pault
Date: Fri Jul 17 17:26:12 2015
New Revision: 225955

URL: https://gcc.gnu.org/viewcvs?rev=225955root=gccview=rev
Log:
2015-07-17  Paul Thomas  pa...@gcc.gnu.org

PR fortran/52846
* decl.c (gfc_match_end): Pick out declared submodule name from
the composite identifier.
* gfortran.h : Add 'submodule_name' to gfc_use_list structure.
* module.c (gfc_match_submodule): Define submodule_name and add
static 'submodule_name'.
(gfc_match_submodule): Build up submodule filenames, using '@'
as a delimiter. Store the output filename in 'submodule_name'.
Similarly, the submodule identifier is built using '.' as an
identifier.
(gfc_dump_module): If current state is COMP_SUBMODULE, write
to file 'submodule_name', using SUBMODULE_EXTENSION.
(gfc_use_module): Similarly, use the 'submodule_name' field in
the gfc_use_list structure and SUBMODULE_EXTENSION to read the
implicitly used submodule files.

2015-07-17  Paul Thomas  pa...@gcc.gnu.org

PR fortran/52846
* lib/fortran-modules.exp (proc cleanup-submodules): New
procedure.
* gfortran.dg/submodule_1.f08: Change extension and clean up
the submodule files.
* gfortran.dg/submodule_2.f08: ditto
* gfortran.dg/submodule_6.f08: ditto
* gfortran.dg/submodule_7.f08: ditto
* gfortran.dg/submodule_8.f08: New test
* gfortran.dg/submodule_9.f08: New test

Added:
trunk/gcc/testsuite/gfortran.dg/submodule_6.f08
  - copied, changed from r225922,
trunk/gcc/testsuite/gfortran.dg/submodule_6.f90
Removed:
trunk/gcc/testsuite/gfortran.dg/submodule_6.f90

[Bug fortran/52846] [F2008] Support submodules

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846

--- Comment #23 from Paul Thomas pault at gcc dot gnu.org ---
Author: pault
Date: Fri Jul 17 17:32:09 2015
New Revision: 225958

URL: https://gcc.gnu.org/viewcvs?rev=225958root=gccview=rev
Log:
2015-07-17  Paul Thomas  pa...@gcc.gnu.org

PR fortran/52846
* decl.c (gfc_match_end): Pick out declared submodule name from
the composite identifier.
* gfortran.h : Add 'submodule_name' to gfc_use_list structure.
* module.c (gfc_match_submodule): Define submodule_name and add
static 'submodule_name'.
(gfc_match_submodule): Build up submodule filenames, using '@'
as a delimiter. Store the output filename in 'submodule_name'.
Similarly, the submodule identifier is built using '.' as an
identifier.
(gfc_dump_module): If current state is COMP_SUBMODULE, write
to file 'submodule_name', using SUBMODULE_EXTENSION.
(gfc_use_module): Similarly, use the 'submodule_name' field in
the gfc_use_list structure and SUBMODULE_EXTENSION to read the
implicitly used submodule files.

2015-07-17  Paul Thomas  pa...@gcc.gnu.org

PR fortran/52846
* lib/fortran-modules.exp (proc cleanup-submodules): New
procedure.
* gfortran.dg/submodule_1.f08: Change extension and clean up
the submodule files.
* gfortran.dg/submodule_2.f08: ditto
* gfortran.dg/submodule_6.f08: ditto
* gfortran.dg/submodule_7.f08: ditto
* gfortran.dg/submodule_8.f08: New test
* gfortran.dg/submodule_9.f08: New test

Modified:
trunk/gcc/testsuite/ChangeLog

[Bug fortran/52846] [F2008] Support submodules

[paul.richard.thomas at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846

--- Comment #10 from paul.richard.thomas at gmail dot com paul.richard.thomas 
at gmail dot com ---
Hi Salvatore,

If you could reduce the source that produces this error for me, I
would be grateful. By the looks of it, the name mangling is
functioning correctly but is picking up the wrong program unit name.

Thanks

Paul

On 14 July 2015 at 14:44, sfilippone at uniroma2 dot it
gcc-bugzi...@gcc.gnu.org wrote:
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846

 --- Comment #9 from Salvatore Filippone sfilippone at uniroma2 dot it ---
 (In reply to Salvatore Filippone from comment #8)
 (In reply to Paul Thomas from comment #7)
 Salvatore

 Spoke too quickly: I get this linker error

 ppde3d.f90:(.text+0x9d0): undefined reference to
 `__psb_error_mod_MOD_psb_perror'
 ../../lib/libpsb_prec.a(psb_dilu_fct.o): In function `psb_dilu_fct_':
 psb_dilu_fct.f90:(.text+0x6a0): undefined reference to
 `__psb_error_mod_MOD_psb_serror'
 psb_dilu_fct.f90:(.text+0x21db): undefined reference to
 `__psb_error_mod_MOD_psb_serror'


 whereas the relevant implementation submodule shows:
  T __psb_error_impl_mod_MOD_psb_perror
 0220 T __psb_error_impl_mod_MOD_psb_serror

 i.e. the name mangling is going wrong.
 Salvatore

 --
 You are receiving this mail because:
 You are on the CC list for the bug.
 You are the assignee for the bug.

[Bug fortran/52846] [F2008] Support submodules

[sfilippone at uniroma2 dot it]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846

--- Comment #11 from Salvatore Filippone sfilippone at uniroma2 dot it ---
Created attachment 35995
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35995action=edit
test case

[Bug fortran/52846] [F2008] Support submodules

[sfilippone at uniroma2 dot it]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846

--- Comment #12 from Salvatore Filippone sfilippone at uniroma2 dot it ---
(In reply to Salvatore Filippone from comment #11)
 Created attachment 35995 [details]
 test case

Enjoy :) 

[sfilippo@jacobi tlink]$ gfortran -v 
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/opt/gnu/dev/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-dev/configure --prefix=/opt/gnu/dev
--enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp
--with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc
--with-cloog=/home/travel/GNUBUILD/cloog : (reconfigured) ../gcc-dev/configure
--prefix=/opt/gnu/dev --enable-languages=c,c++,fortran
--with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr
--with-mpc=/home/travel/GNUBUILD/mpc --with-cloog=/home/travel/GNUBUILD/cloog :
(reconfigured) ../gcc-dev/configure --prefix=/opt/gnu/dev
--with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr
--with-mpc=/home/travel/GNUBUILD/mpc --with-cloog=/home/travel/GNUBUILD/cloog
CC=gcc CXX=g++ --enable-languages=c,c++,fortran,lto --no-create --no-recursion
Thread model: posix
gcc version 6.0.0 20150713 (experimental) (GCC) 
[sfilippo@jacobi tlink]$ gfortran -o testlk testlk.f90 
/tmp/cchNLmkr.o: In function `__error_impl_mod_MOD_ser_error_print_stack':
testlk.f90:(.text+0x1b): undefined reference to `__error_mod_MOD_serror'
/tmp/cchNLmkr.o: In function `__error_impl_mod_MOD_par_error_print_stack':
testlk.f90:(.text+0x3b): undefined reference to `__error_mod_MOD_perror'
/tmp/cchNLmkr.o: In function `__error_mod_MOD_par_error_handler':
testlk.f90:(.text+0x5f): undefined reference to `erractionrestore_'
testlk.f90:(.text+0x7b): undefined reference to `__error_mod_MOD_perror'
testlk.f90:(.text+0x97): undefined reference to `__error_mod_MOD_perror'
/tmp/cchNLmkr.o: In function `__error_mod_MOD_ser_error_handler':
testlk.f90:(.text+0xb8): undefined reference to `erractionrestore_'
testlk.f90:(.text+0xc7): undefined reference to `__error_mod_MOD_serror'
/tmp/cchNLmkr.o: In function `MAIN__':
testlk.f90:(.text+0xfc): undefined reference to `__error_mod_MOD_serror'
collect2: error: ld returned 1 exit status

[Bug fortran/52846] [F2008] Support submodules

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846

--- Comment #14 from Paul Thomas pault at gcc dot gnu.org ---
(In reply to Salvatore Filippone from comment #13)
 Created attachment 35996 [details]
 test case
 
 Cleaned up a bit of noise due to the process of reducing the test case: it
 was spitting out a legitimate but pointless liker error about
 erractionrestore.
 
 [sfilippo@jacobi tlink]$ gfortran -o testlk testlk.f90 
 /tmp/ccbhv5VA.o: In function `__error_impl_mod_MOD_ser_error_print_stack':
 testlk.f90:(.text+0x1b): undefined reference to `__error_mod_MOD_serror'
 /tmp/ccbhv5VA.o: In function `__error_impl_mod_MOD_par_error_print_stack':
 testlk.f90:(.text+0x3b): undefined reference to `__error_mod_MOD_perror'
 /tmp/ccbhv5VA.o: In function `__error_mod_MOD_par_error_handler':
 testlk.f90:(.text+0x6a): undefined reference to `__error_mod_MOD_perror'
 testlk.f90:(.text+0x86): undefined reference to `__error_mod_MOD_perror'
 /tmp/ccbhv5VA.o: In function `__error_mod_MOD_ser_error_handler':
 testlk.f90:(.text+0xa5): undefined reference to `__error_mod_MOD_serror'
 /tmp/ccbhv5VA.o: In function `MAIN__':
 testlk.f90:(.text+0xda): undefined reference to `__error_mod_MOD_serror'
 collect2: error: ld returned 1 exit status

OK - this compiles and runs if the PRIVATE statement is removed. As soon as I
return to the privacy issue, I will check that this testcase is OK.

Thanks

Paul

[Bug fortran/52846] [F2008] Support submodules

[sfilippone at uniroma2 dot it]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846

--- Comment #13 from Salvatore Filippone sfilippone at uniroma2 dot it ---
Created attachment 35996
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35996action=edit
test case

Cleaned up a bit of noise due to the process of reducing the test case: it was
spitting out a legitimate but pointless liker error about erractionrestore.

[sfilippo@jacobi tlink]$ gfortran -o testlk testlk.f90 
/tmp/ccbhv5VA.o: In function `__error_impl_mod_MOD_ser_error_print_stack':
testlk.f90:(.text+0x1b): undefined reference to `__error_mod_MOD_serror'
/tmp/ccbhv5VA.o: In function `__error_impl_mod_MOD_par_error_print_stack':
testlk.f90:(.text+0x3b): undefined reference to `__error_mod_MOD_perror'
/tmp/ccbhv5VA.o: In function `__error_mod_MOD_par_error_handler':
testlk.f90:(.text+0x6a): undefined reference to `__error_mod_MOD_perror'
testlk.f90:(.text+0x86): undefined reference to `__error_mod_MOD_perror'
/tmp/ccbhv5VA.o: In function `__error_mod_MOD_ser_error_handler':
testlk.f90:(.text+0xa5): undefined reference to `__error_mod_MOD_serror'
/tmp/ccbhv5VA.o: In function `MAIN__':
testlk.f90:(.text+0xda): undefined reference to `__error_mod_MOD_serror'
collect2: error: ld returned 1 exit status

[Bug fortran/52846] [F2008] Support submodules

[sfilippone at uniroma2 dot it]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846

--- Comment #9 from Salvatore Filippone sfilippone at uniroma2 dot it ---
(In reply to Salvatore Filippone from comment #8)
 (In reply to Paul Thomas from comment #7)
 Salvatore

Spoke too quickly: I get this linker error

ppde3d.f90:(.text+0x9d0): undefined reference to
`__psb_error_mod_MOD_psb_perror'
../../lib/libpsb_prec.a(psb_dilu_fct.o): In function `psb_dilu_fct_':
psb_dilu_fct.f90:(.text+0x6a0): undefined reference to
`__psb_error_mod_MOD_psb_serror'
psb_dilu_fct.f90:(.text+0x21db): undefined reference to
`__psb_error_mod_MOD_psb_serror'


whereas the relevant implementation submodule shows:
 T __psb_error_impl_mod_MOD_psb_perror
0220 T __psb_error_impl_mod_MOD_psb_serror

i.e. the name mangling is going wrong.
Salvatore

[Bug fortran/52846] [F2008] Support submodules

[sfilippone at uniroma2 dot it]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846

--- Comment #8 from Salvatore Filippone sfilippone at uniroma2 dot it ---
(In reply to Paul Thomas from comment #7)
 Created attachment 35926 [details]
 A partially cooked patch to complete the implentation of submodules
 
 The attached is a first attempt to complete the submodule implementation
 such that private entities are correctly dealt with.
 
 There are two parts to the patch:
 
 (i) Modifications to the front end to write a second half to the module
 files, which contains all the information about the private entities in the
 module. This is the bulk of the patch; and
 
 (ii) A change in the way that declarations of private entities are handled
 in trans-decl.c. This follows a suggestion from Richard Biener to use a
 technique borrowed from g++. In this patch it is only applied to variables.
 
 Cheers
 
 Paul

Seems to work for my codes.

I am not completely happy with the fact that a change in the PRIVATE entities
will cause a change of the .mod file; it may be argued that changes are more
likely to occur in the submodules than in the main module, but still, this is
not 100% satisfactory wrt the advertisement that submodules are ssolving the
compilation cascade problem. 
From a user's point of view, I do not see a good solution to this; if the .mod
file contains any kind of timestamp, it's going to change anyway, even in the
case where the PRIVATE part is written to a separate file. 

On a relate note, the point raised in the mailing list about protecting trade
secrets by putting them in the PRIVATE parts is IMHO moot: if I really wanted
to protect trade secrets, I would put them in a separate module that is only
ever USEd by the implementation files of the user visible module, files of
which I only distribute the object code. 
I don't think that C++ is any different in this respect. 

Salvatore

[Bug fortran/52846] [F2008] Support submodules

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846

--- Comment #7 from Paul Thomas pault at gcc dot gnu.org ---
Created attachment 35926
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35926action=edit
A partially cooked patch to complete the implentation of submodules

The attached is a first attempt to complete the submodule implementation such
that private entities are correctly dealt with.

There are two parts to the patch:

(i) Modifications to the front end to write a second half to the module files,
which contains all the information about the private entities in the module.
This is the bulk of the patch; and

(ii) A change in the way that declarations of private entities are handled in
trans-decl.c. This follows a suggestion from Richard Biener to use a technique
borrowed from g++. In this patch it is only applied to variables.

Concerning (i), I am open to opinions as to whether or not it is better to
write the private parts to a separate file. At present, anything other than a
submodule does not visit the private part of the module file. Mention was made
on the list of encrypting this part of the file. Unfortunately, this overwhelms
the compression and module files remain rather large. This might be a strong
argument for emitting two files; one for the public part, as at present, and
the other for the private. In this way, a build could result in a library that
is only propagated with the public module file.

In respect of (ii), I have checked that the map shows no signs of the private
variables and that the library only carries their names.

A typical, basic makefile might look like this:

# Build submodule_8
#
submodule_8 : submodule_8_prog.o submodule_8_lib.so
~/irun/bin/gfortran -O3 submodule_8_prog.o submodule_8_lib.so -o
submodule_8
#
submodule_8_prog.o : submodule_8_prog.f90
~/irun/bin/gfortran -O3 -c submodule_8_prog.f90 -o submodule_8_prog.o
#
submodule_8_lib.so : submodule_8_lib1.o submodule_8_lib2.o
~/irun/bin/gfortran -O3 -shared submodule_8_lib1.o submodule_8_lib2.o
-o submodule_8_lib.so
#
# Relocation runs into problems without -fPIC for both of these compilations.
#
submodule_8_lib1.o : submodule_8_lib1.f90
~/irun/bin/gfortran -O3 -fPIC -c submodule_8_lib1.f90 -o
submodule_8_lib1.o
#
submodule_8_lib2.o : submodule_8_lib2.f90
~/irun/bin/gfortran -O3 -fPIC -c submodule_8_lib2.f90 -o
submodule_8_lib2.o

In this tested case, ~lib1 contains two modules and ~lib2 the submodules. Some
of the entities in ~lib1 are private but they are correctly propagated to ~lib2
but not to the program, ~prog.

Cheers

Paul

[Bug fortran/52846] [F2008] Support submodules

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846

--- Comment #6 from Paul Thomas pault at gcc dot gnu.org ---
I have yet to sort out private symbols before I close this PR. It will take
some days to conclude because of the issues discussed on the list.

I'm on to it!

Paul

[Bug fortran/52846] [F2008] Support submodules

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846

--- Comment #5 from Paul Thomas pault at gcc dot gnu.org ---
Author: pault
Date: Thu Jul  2 20:39:56 2015
New Revision: 225354

URL: https://gcc.gnu.org/viewcvs?rev=225354root=gccview=rev
Log:
2015-07-02  Paul Thomas  pa...@gcc.gnu.org

PR fortran/52846
* decl.c (get_proc_name): Make a partially populated interface
symbol to carry the characteristics of a module procedure and
its result.
(variable_decl): Declarations of dummies or results in the
abreviated form of module procedure is an error.
(gfc_match_import): IMPORT is not permitted in the interface
declaration of module procedures.
(match_attr_spec): Submodule variables have implicit save
attribute for F2008 onwards.
(gfc_match_prefix): Add 'module' as the a prefix and set the
module_procedure attribute.
(gfc_match_formal_arglist): For a module procedure keep the
interface formal_arglist from the interface, match new the
formal arguments and then compare the number and names of each.
(gfc_match_procedure): Add case COMP_SUBMODULE.
(gfc_match_function_decl, gfc_match_subroutine_decl): Set the
module_procedure attribute.
(gfc_match_entry, gfc_match_end):  Add case COMP_SUBMODULE. If
attr abr_modproc_decl is set, switch the message accordingly
for subroutines and functions.
(gfc_match_submod_proc): New function to match the abbreviated
style of submodule declaration.
* gfortran.h : Add ST_SUBMODULE and ST_END_SUBMODULE. Add the
attribute bits 'used_in_submodule' and 'module_procedure'. Add
the bit field 'abr_modproc_decl' to gfc_symbol. Add prototypes
for 'gfc_copy_dummy_sym', 'gfc_check_dummy_characteristics' and
'gfc_check_result_characteristics'.
* interface.c : Add the prefix 'gfc_' to the names of functions
'check_dummy(result)_characteristics' and all their references.
* match.h : Add prototype for 'gfc_match_submod_proc' and
'gfc_match_submodule'.
(check_sym_interfaces): A module procedure is not an error in
a module procedure statment in a generic interface.
* module.c (gfc_match_submodule): New function. Add handling
for the 'module_procedure' attribute bit.
(gfc_use_module): Make sure that a submodule cannot use itself.
* parse.c (decode_statement): Set attr has_'import_set' for
the interface declaration of module procedures. Handle a match
occurring in 'gfc_match_submod_proc' and a match for
'submodule'.
(gfc_enclosing_unit): Include the state COMP_SUBMODULE.
(gfc_ascii_statement): Add END SUBMODULE.
(accept_statement): Add ST_SUBMODULE.
(parse_spec): Disallow statement functions in a submodule
specification part.
(parse_contained): Add ST_END_SUBMODULE and COMP_SUBMODULE
twice each.
(get_modproc_result): Copy the result symbol of the interface.
(parse_progunit): Call it.
(set_syms_host_assoc): Make symbols from the ancestor module
and submodules use associated, as required by the standard and
set all private components public. Module procedures 'external'
attribute bit is reset and the 'used_in_submodule' bit is set.
(parse_module): If this is a submodule, use the ancestor module
and submodules. Traverse the namespace, calling
'set_syms_host_assoc'. Add ST_END_SUBMODULE and COMP_SUBMODULE.
* parse.h : Add COMP_SUBMODULE.
* primary.c (match_variable): Add COMP_SUBMODULE.
* resolve.c (compare_fsyms): New function to compare the dummy
characteristics of a module procedure with its interface.
(resolve_fl_procedure): Compare the procedure, result and dummy
characteristics of a module_procedure with its interface, using
'compare_fsyms' for the dummy arguments.
* symbol.c (gfc_add_procedure): Suppress the check for existing
procedures in the case of a module procedure.
(gfc_add_explicit_interface): Skip checks that must fail for
module procedures.
(gfc_add_type): Allow a new type to be added to module
procedures, their results or their dummy arguments.
(gfc_copy_dummy_sym): New function to generate new dummy args
and copy the characteristics from the interface.
* trans-decl.c (gfc_sym_mangled_function_id): Module procedures
must always have their names mangled as if they are symbols
coming from a declaration in a module.
(gfc_get_symbol_decl): Add 'used_in_submodule' to the assert.
(gfc_finish_var_decl): Symbols with the 'used_in_submodule' bit
set are set DECL_EXTERNAL as if they were use associated.

2015-07-02  Paul Thomas  pa...@gcc.gnu.org

PR fortran/52846
* 

[Bug fortran/52846] [F2008] Support submodules

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846

--- Comment #4 from Paul Thomas pault at gcc dot gnu.org ---
Testcase:

! Test vehicle for submodules
! 14th June 2015
!
! Paul Thomas - check1406b.diff applies
!
! FIXED OR MOSTLY FIXED:
! Access in submodules to PROCEDURE COMPONENTS - FIXED 06/06/2015
! MODULE FUNCTIONS - partially FIXED 10/06/15 - syntax errors give difficult to
understand messages
! Salvatore's submodbug fixed 10/06/15 - module variable must remain use
associated
! Name mangling of MODULE PROCEDUREs - FIXED 13/06
! Parsing of SUBMODULE (module:parent_submodule:.) - already worked(!)
tested 14/06
! Checking characteristics between interface and submodule declaration - FIXED
14/06
!
! TODOs:
! Clean up and comment all the new code (Partially done 14/06)
! Prepare testcases for testsuite
! Constraints as delineated in N1602.pdf or F2008 standard (will have to check
what is left!)
! Restricting output of .mod file from submodules to local symbols, etc. only
(not essential)
! Prepare ChangeLogs
! Submit :-)
!
 module foo_interface
   implicit none

   type foo
 character(len=15) :: greeting = Hello, world!  
   contains
 procedure :: greet = say_hello
 procedure :: farewell = bye
   end type foo

   interface
 module subroutine say_hello(this)
   import foo
   class(foo), intent(in) :: this
 end subroutine
 module subroutine bye(this)
   import foo
   class(foo), intent(in) :: this
 end subroutine
 module function realf (arg) result (res)
   real :: arg, res
 end function
 integer module function intf (arg)
   integer :: arg
 end function
 real module function realg (arg)
   real :: arg
 end function
 integer module function intg (arg)
   integer :: arg
 end function
   end interface
 contains
   subroutine smurf
 class(foo), allocatable :: this
 allocate (this)
 print *, say_hello from SMURF ---
! Test that say_hello is effectively host associated
 call say_hello (this)
   end subroutine
 end module

!_!
  SUBMODULE (foo_interface) foo_interface_son
!
  contains
! Test module procedure with conventional specification part for dummies
 module subroutine say_hello(this)
   class(foo), intent(in) :: this
   class(foo), allocatable :: that
   allocate (that, source = this)
! Test that components of foo are accessible
   print *, (say_hello), that%greeting
!   call this%farewell ! NOTE WELL: This compiles and causes a
crash in run-time
!   due to recursion through the
call to this procedure from
!   say hello.
 end subroutine
 module function realf (arg) result (res)
   real :: arg, res
   res = 2*arg
 end function
  end SUBMODULE foo_interface_son

!_!
! Check that multiple generations of submodules are OK
  SUBMODULE (foo_interface:foo_interface_son) foo_interface_grandson
!
  contains
 integer module function intf (arg)
   integer :: arg
   intf = 2*arg
 end function
  end SUBMODULE foo_interface_grandson

!_!
  SUBMODULE (foo_interface) foo_interface_daughter
!
  contains
! Test module procedure with abbreviated declaration and no specification of
dummies
 module procedure bye
! Verify the derived type foo is accessible - had problems with this because
if_source != IFSRC_DECL
   class(foo), allocatable :: that
   print *, (bye) , this%greeting
   print *, say_hello from BYE ---
   call say_hello (this)
   allocate (that, source = this)
! Test that components of foo are accessible
   print *, (bye), that%greeting
   print *, call that%greet from BYE ---
   call that%greet
 end subroutine
 module procedure intg
   intg = 3*arg
 end function
 module procedure realg
   realg = 3*arg
 end function
  end SUBMODULE foo_interface_daughter

!_!
 program try
   use foo_interface
   implicit none
   type(foo) :: bar
   call bar%greet ! typebound call

!   Unnecessary tests at present
!   bar%greeting = Goodbye, world!
!   call bar%greet ! typebound call with changed message

   print *, say_hello from TRY ---
   call say_hello(bar) ! Checks use association of 'say_hello'
   call bye(bar) ! Checks use association in another submodule
   call smurf ! Checks host association of 'say_hello'
   bar%greeting = farewell 
   call bar%farewell
   print *, realf(2.0) ! Check module procedure with explicit result
   print *, intf(2)! ditto
   print *, realg(3.0) ! Check module procedure with function declaration
result
   print *, intg(3)! ditto
 end program

[Bug fortran/52846] [F2008] Support submodules

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846

Paul Thomas pault at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||pault at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #2 from Paul Thomas pault at gcc dot gnu.org ---
Dear Dominique and Tobias,

Whatever is the purpose of this PR, I will use it to hang my hat on :-) I have
a submodule patch nearly ready to go.

My plan is to submit next Saturday.

Cheers

Paul

[Bug fortran/52846] [F2008] Support submodules

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846

--- Comment #3 from Paul Thomas pault at gcc dot gnu.org ---
Created attachment 35779
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35779action=edit
draft patch

[Bug fortran/52846] [F2008] Support submodules

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846

Dominique d'Humieres dominiq at lps dot ens.fr changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2014-12-21
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr ---
What is the purpose of this PR? To remind that submodules are not yet supported
and/or that the commits for PR 52751 and PR 40973 will have to be updated when
submodules will be supported?

In the latter case could you elaborate?