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

2015-07-16 Thread Steve Kargl
See any dictionary for the definition of 'old'. :-)

Last time I used VMS in 1990i, and upgrading to 
newer versions of software on the systems required 
a few hurdles to clear.

On Thu, Jul 16, 2015 at 02:13:54PM -0700, Douglas B Rupp wrote:
> VMS hasn't had a 3 character filename extension limit since before 
> VAX/VMS version 4.0 was released in 1984.
> 
> On 07/16/2015 01:41 PM, Steve Kargl wrote:
> > On Thu, Jul 16, 2015 at 05:08:50PM +0200, Paul Richard Thomas wrote:
> >>
> >> Please find attached a new version of the patch that fixes the
> >> inconsistency with the standard, pointed out by Reinhold. It is weird
> >> but a read the appropriate part of the standard several times and
> >> simply did not pick up the critical information :-)
> >>
> >> Note that the delimiter used for submodule file name is '@', whereas
> >> the internal identifiers is '.'.
> >>
> >> I have added a procedure to cleanup submodules produced by the
> >> testsuite and implemented them in submodule_[1-8].f90. Submodule_8.f90
> >> tests the resolution of the spurious error found by Reinhold.
> >>
> >> Booststraps and regtests on FC_21/x86_64 - OK for trunk?
> >>
> >
> > Patch looks ok to me.  One item I wonder if we need to care
> > about is old filesytems (FAT) or operating systems (VMS) with
> > a 3 character file extension limit.
> >

-- 
Steve


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

2015-07-16 Thread Douglas B Rupp
VMS hasn't had a 3 character filename extension limit since before 
VAX/VMS version 4.0 was released in 1984.


On 07/16/2015 01:41 PM, Steve Kargl wrote:

On Thu, Jul 16, 2015 at 05:08:50PM +0200, Paul Richard Thomas wrote:


Please find attached a new version of the patch that fixes the
inconsistency with the standard, pointed out by Reinhold. It is weird
but a read the appropriate part of the standard several times and
simply did not pick up the critical information :-)

Note that the delimiter used for submodule file name is '@', whereas
the internal identifiers is '.'.

I have added a procedure to cleanup submodules produced by the
testsuite and implemented them in submodule_[1-8].f90. Submodule_8.f90
tests the resolution of the spurious error found by Reinhold.

Booststraps and regtests on FC_21/x86_64 - OK for trunk?



Patch looks ok to me.  One item I wonder if we need to care
about is old filesytems (FAT) or operating systems (VMS) with
a 3 character file extension limit.



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

2015-07-16 Thread Steve Kargl
On Thu, Jul 16, 2015 at 05:08:50PM +0200, Paul Richard Thomas wrote:
> 
> Please find attached a new version of the patch that fixes the
> inconsistency with the standard, pointed out by Reinhold. It is weird
> but a read the appropriate part of the standard several times and
> simply did not pick up the critical information :-)
> 
> Note that the delimiter used for submodule file name is '@', whereas
> the internal identifiers is '.'.
> 
> I have added a procedure to cleanup submodules produced by the
> testsuite and implemented them in submodule_[1-8].f90. Submodule_8.f90
> tests the resolution of the spurious error found by Reinhold.
> 
> Booststraps and regtests on FC_21/x86_64 - OK for trunk?
> 

Patch looks ok to me.  One item I wonder if we need to care
about is old filesytems (FAT) or operating systems (VMS) with
a 3 character file extension limit.

-- 
Steve


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

2015-07-16 Thread Paul Richard Thomas
Dear Reinhold, dear all,

Please find attached a new version of the patch that fixes the
inconsistency with the standard, pointed out by Reinhold. It is weird
but a read the appropriate part of the standard several times and
simply did not pick up the critical information :-)

Note that the delimiter used for submodule file name is '@', whereas
the internal identifiers is '.'.

I have added a procedure to cleanup submodules produced by the
testsuite and implemented them in submodule_[1-8].f90. Submodule_8.f90
tests the resolution of the spurious error found by Reinhold.

Booststraps and regtests on FC_21/x86_64 - OK for trunk?

Paul

2015-07-16  Paul Thomas  

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-16  Paul Thomas  

PR fortran/52846
* lib/fortran-modules.exp (proc cleanup-submodules): New proc..
* gfortran.dg/submodule_1.f90: Clean up submodules
* gfortran.dg/submodule_2.f90: Clean up submodules
* gfortran.dg/submodule_3.f90: Clean up submodules
* gfortran.dg/submodule_4.f90: Clean up submodules
* gfortran.dg/submodule_5.f90: Clean up submodules
* gfortran.dg/submodule_6.f90: Clean up submodules
* gfortran.dg/submodule_7.f90: Clean up submodules
* gfortran.dg/submodule_8.f90: New test






On 14 July 2015 at 13:10, Paul Richard Thomas
 wrote:
> Dear All,
>
> Reinhold Bader has pointed out the naming the submodule files after
> the submodule name and using .mod as the extension can potentially
> lead to clashes. Therefore, I have written a patch to change gfortran
> to follow the naming convention of another leading brand:
>
> submodule filename = module@ancestor@@submodule.smod
>
> The implementation is straightforward and the ChangeLog and the patch
> provide an adequate description.
>
> Bootstraps and regtests on x86_64 - OK for trunk?
>
> Paul
>
> 2015-07-14  Paul Thomas  
>
> PR fortran/52846
> * 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'.
> (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.



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

Groucho Marx
Index: gcc/fortran/decl.c
===
*** gcc/fortran/decl.c  (revision 225410)
--- gcc/fortran/decl.c  (working copy)
*** gfc_match_end (gfc_statement *st)
*** 6451,6456 
--- 6451,6461 
if (block_name == NULL)
  goto syntax;

+   /* We have to pick out the declared submodule name from the composite
+  required by F2008:11.2.3 para 2, which ends in the declared name.  */
+   if (state == COMP_SUBMODULE)
+ block_name = strchr (block_name, '.') + 1;
+
if (strcmp (name, block_name) != 0 && strcmp (block_name, "ppr@") != 0)
  {
gfc_error ("Expected label %qs for %s statement at %C", block_name,
Index: gcc/fortran/gfortran.h
===
*** gcc/fortran/gfortran.h  (revision 225410)
--- gcc/fortran/gfortran.h  (working copy)
*** gfc_use_rename;
*** 1556,1561 
--- 1556,1562 
  typedef struct gfc_use_list
  {
const char *module_name;
+   const char *submodule_name;
bool intrinsic;
bool non_intrinsic;
bool only_flag;
Index: gcc/fortran/module.c
===
*** gcc/fortran/module.c(revision 225410)
--- gcc/fortran/module.c(working copy)
*** along with GCC; see the file COPYING3.
*** 82,87 
--- 82,88 
  #include 

  #define MODULE_EXTENSION ".mod"
+ #define SUBMODULE_EXTENSION ".smod"

  /* Don't put any single quote (') in MOD_VERSION, if you want it to be
 recognized.  */
*** static gzFile module_fp;
*** 191,196