[Bug fortran/108369] New: FM509 Fails to compile with error

[Bug fortran/108369] New: FM509 Fails to compile with error

[ben.brewer at codethink dot co.uk]

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

            Bug ID: 108369
           Summary: FM509 Fails to compile with error
           Product: gcc
           Version: 11.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ben.brewer at codethink dot co.uk
  Target Milestone: ---

7 years ago I developed a legacy fortran transpiler, to test that it is
behaviourally correct the test suite runs gfortran over the sources, and then
runs gfortran over the transpiled sources and compares output.

Running this project recently showed numerous behavioural changes/errors and if
this is of interest then the project can be found here:
https://github.com/CodethinkLabs/ofc

The test suite I run against (mostly legacy) can be found here:
https://github.com/CodethinkLabs/ofc-tests

The most critical of these behavioural changes is that the NIST F77 test suite
fails on FM509.FOR with the following:
"Error: Actual argument contains too few elements for dummy argument ‘c1d001’
(19/48) at (1)"

[Bug fortran/108369] FM509 Fails to compile with error

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2023-01-11
     Ever confirmed|0                           |1

--- Comment #1 from anlauf at gcc dot gnu.org ---
(In reply to Ben Brewer from comment #0)
> The most critical of these behavioural changes is that the NIST F77 test
> suite fails on FM509.FOR with the following:
> "Error: Actual argument contains too few elements for dummy argument
> ‘c1d001’ (19/48) at (1)"

The error message refers to:

      SUBROUTINE SN512(C1D001,CVD001)
      CHARACTER C1D001(6)*8,CVD001*8
      CVD001 = C1D001(1)
      RETURN
      END

and the caller is:

      CALL SN512(C1N001(5)(2:9),CVCOMP)

which passes an array of size 1.

Workaround: either use -std=legacy or fix the above argument declaration to:

      CHARACTER C1D001(*)*8,CVD001*8

[Bug fortran/108369] FM509 Fails to compile with error

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
Reduced testcase

      PROGRAM FM509

      IMPLICIT CHARACTER*27 (C)

      CHARACTER C1N001(6)*10
      DATA C1N001 /'FIRST-AID:','SECONDRATE','THIRD-TERM',
     1             'FOURTH-DAY','FIFTHROUND','SIXTHMONTH'/

      CVCOMP = ' '
      CALL SN512(C1N001(5)(2:9),CVCOMP)

      END

      SUBROUTINE SN512(C1D001,CVD001)
      CHARACTER C1D001(6)*8,CVD001*8
      CVD001 = C1D001(1)
      END

gfcx -w -o z y.f 
y.f:10:17:

   10 |       CALL SN512(C1N001(5)(2:9),CVCOMP)
      |                 1
Error: Actual argument contains too few elements for dummy argument 'c1d001'
(19/48) at (1)

Normally, this comes down to type, kind type parameter, and rank (TKR)
matching of the actual and dummy arguments.

In the call to sn512, c1n001(5)(2:9) is a substring of length
8 of the fifth element of the array c1n001.  The subroutine is
expecting to receive a 6-element array with each element having
a length of 8.

   15.5.2.4 Ordinary dummy variables
   ...
   The dummy argument shall be type compatible with the actual
   argument.
   ...
   The kind type parameter values of the actual argument shall
   agree with the corresponding ones of the dummy argument. The
   length type parameter values of a present actual argument shall
   agree with the corresponding ones of the dummy argument that
   are not assumed, except for the case of the character length
   parameter of an actual argument of type character with default
   kind or C character kind (18.2.2) associated with a dummy
   argument that is not assumed-shape or assumed-rank.

   3.147.11
   type compatible
   compatibility of the type of one entity with respect to another for
   purposes such as argument association, pointer association, and
   allocation (7.3.2)

Hmmm, it appears the argument mismatch feature added under the
-fallow-argmument-mismatch option might be running afoul of the 
standard.

[Bug fortran/108369] FM509 Fails to compile with error

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #1)
> (In reply to Ben Brewer from comment #0)
> Workaround: either use -std=legacy or fix the above argument declaration to:
> 
>       CHARACTER C1D001(*)*8,CVD001*8

While the workaround will work, it does so because it disables
-fallow-argument-mismatch.  But, that feature emitting a bogus
error/warning.

Note the following all compile and execute.  TKR is satisfied
as I discussion in comment #2.

! Compiles and executes
program foo1
   character(len=10) a
   a = '1234567890'
   call sub1(a)
end
subroutine sub1(s)
   character(len=8) s
   print *, '>' // s // '<'
end

! Compiles and executes
program foo2
   character(len=10) a(5)
   a = '1234567890'
   call sub2(a)
end
subroutine sub2(s)
    character(len=8) s(2)
   print *, '>' // s(1) // '<'
end

! Compiles and executes
program foo3
   character(len=10) a(5)
   a = '1234567890'
   call sub3(a(2)(2:4))
end
subroutine sub3(s)
    character(len=8) s(2)
   print *, '>' // s(1) // '<'
end

But,

% gfcx -o z a.f90 && ./z
a.f90:40:13:

   40 |    call sub4(a(2)(2:4))
      |             1
Error: Actual argument contains too few elements for dummy
argument 's' (39/80) at (1)

! Whoops
program foo4
   character(len=10) a(5)
   a = '1234567890'
   call sub4(a(2)(2:4))
end
subroutine sub4(s)
    character(len=8) s(10)    ! <-- only difference from foo3
   print *, '>' // s(1) // '<'
end

The give away that something is amiss is the (39/80) part of
the error message.  80 = 8*10, i.e., total number of characters.
I cannot quite get 39.  39 = 50 - 11, but 11 does not match up
with the substring length of a(2)(2:4).

Now, looking at interface.cc starting at line 3354, we have


          if (a->expr->ts.type == BT_CHARACTER && !f->sym->as && where)
            {
              gfc_warning (0, "Character length of actual argument shorter "
                           "than of dummy argument %qs (%lu/%lu) at %L",
                           f->sym->name, actual_size, formal_size,
                           &a->expr->where);
              goto skip_size_check;
            }
          else if (where)
            {
              /* Emit a warning for -std=legacy and an error otherwise. */
              if (gfc_option.warn_std == 0)
                gfc_warning (0, "Actual argument contains too few "
                             "elements for dummy argument %qs (%lu/%lu) "
                             "at %L", f->sym->name, actual_size,
                             formal_size, &a->expr->where);
              else
                gfc_error_now ("Actual argument contains too few "
                               "elements for dummy argument %qs (%lu/%lu) "
                               "at %L", f->sym->name, actual_size,
                               formal_size, &a->expr->where);
            }

clearly we want the first branch about character length, so
`where` == NULL

[Bug fortran/108369] FM509 Fails to compile with error

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #4 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Wed, Jan 11, 2023 at 09:50:37PM +0000, kargl at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369
> 
> --- Comment #3 from kargl at gcc dot gnu.org ---
> (In reply to anlauf from comment #1)
> > (In reply to Ben Brewer from comment #0)
> > Workaround: either use -std=legacy or fix the above argument declaration to:
> > 
> >       CHARACTER C1D001(*)*8,CVD001*8
> 
> While the workaround will work, it does so because it disables
> -fallow-argument-mismatch.  But, that feature emitting a bogus
> error/warning.
> 
> Note the following all compile and execute.  TKR is satisfied
> as I discussion in comment #2.
> 

After looking into this a bit closer, Harald is indeed correct
with the need for -std=legacy (or -fallow-argument-mismatch).
In the line

      CALL SN512(C1N001(5)(2:9),CVCOMP)

'C1N001(5)(2:9)' is a substring of the array element 'C1N001(5)',
which is a scalar (ie., rank = 0).  The interface for SN512 is

      SUBROUTINE SN512(C1D001,CVD001)
      CHARACTER C1D001(6)*8,CVD001*8

The first dummy argument is a rank 1 array.  

Now, if the test is changed to pass an array section such as

      CALL SN512(C1N001(4:5)(2:9),CVCOMP)

then gfortran gives

%  gfcx -w -c fm509.f
fm509.f:378:17:

  378 |       CALL SN512(C1N001(4:5)(2:9),CVCOMP)                              
  03770509
      |                 1
Error: Actual argument contains too few elements for dummy
argument 'c1d001' (16/48) at (1)

which I believe may be wrong.

[Bug fortran/108369] FM509 Fails to compile with error

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jvdelisle at gcc dot gnu.org

--- Comment #5 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
I use to run the NIST tests regularly many years ago. Even then, we would hita
bug once in a while.  FM509 has failed before in those times and I would not be
surprised something got broke.  I do remember you have to use -std=legacy no
matter what.

Steve you may have discovered something new.  I the meantime I hope I can find
the old script I used to run the tests.  Its about three disk drive ago
connected to three different computers, however, I never delete things. (on the
hunt tonight)

[Bug fortran/108369] FM509 Fails to compile with error

[jvdelisle at gcc dot gnu.org]

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

--- Comment #6 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Unbelievable! I found the folder in my test directory. The NIST test suite
passes as before with my test script using the latest gfortran trunk rev 13.

I do some comparisons way back with some example outputs in some of these
cases.  I will zip this up and send it to Ben and Steve.

I was actually surprised things still passed.

[Bug fortran/108369] FM509 Fails to compile with error

[jvdelisle at gcc dot gnu.org]

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

--- Comment #7 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Created attachment 54262
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54262&action=edit
Script used. may need to be adjusted for ones envoronment

[Bug fortran/108369] FM509 Fails to compile with error

[jvdelisle at gcc dot gnu.org]

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

--- Comment #8 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Created attachment 54263
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54263&action=edit
Reference files used by script

[Bug fortran/108369] FM509 Fails to compile with error

[jvdelisle at gcc dot gnu.org]

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

--- Comment #9 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
The NIST files themselves are too large to attach here.

[Bug fortran/108369] FM509 Fails to compile with error

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #10 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Fri, Jan 13, 2023 at 01:09:22AM +0000, jvdelisle at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369
> 
> --- Comment #6 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
> Unbelievable! I found the folder in my test directory. The NIST test suite
> passes as before with my test script using the latest gfortran trunk rev 13.
> 
> I do some comparisons way back with some example outputs in some of these
> cases.  I will zip this up and send it to Ben and Steve.
> 
> I was actually surprised things still passed.
> 

Thanks Jerry.  I have NIST, but have only ever done compile
tests.  I've not tried to actually run all of the tests.

[Bug fortran/108369] FM509 Fails to compile with error

[ben.brewer at codethink dot co.uk]

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

--- Comment #11 from Ben Brewer <ben.brewer at codethink dot co.uk> ---
So I was using "-x f77" which I would expect to instruct the compiler to run in
a mode compatible with Fortran 77, it seems non-intuitive to have to enable
-std=legacy to compile the very tests which define f77.

[Bug fortran/108369] FM509 Fails to compile with error

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #12 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Fri, Jan 13, 2023 at 11:49:44AM +0000, ben.brewer at codethink dot co.uk
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369
> 
> --- Comment #11 from Ben Brewer <ben.brewer at codethink dot co.uk> ---
> So I was using "-x f77" which I would expect to instruct the compiler to run in
> a mode compatible with Fortran 77, it seems non-intuitive to have to enable
> -std=legacy to compile the very tests which define f77.
> 

gfortran started life as a Fortran 95 compiler with a bunch of
extensions.  The -x f77 option might be a relic from g77 and 
only effects whether one has fixed source form code or free
source form code.  "f77" appears twice in gcc.info under the
description of the -x option.  The meaning of "-x f77" isn't
actually documented.  

To set the Fortran standard conformance, use the -std option (e.g.,
-std=legacy, -std=f95, -std=f2003, -std=f2008, -std=f2018).  There
isn't an -std=f77,  If one is compiling old code, it is recommended
to use -std=legacy to turn off a bunch of warning/errors.

[Bug fortran/108369] FM509 Fails to compile with error

[jvdelisle at gcc dot gnu.org]

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

--- Comment #13 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Created attachment 54267
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54267&action=edit
FM509 that I have here.

This morning I also recall there was one NIST test that had an error. I
contacted them regarding this error with a correction.  This was based on a lot
of sleuthing. I do not remember if they ever corrected it or not and I do not
remember which one.  FWIW I will attach the FM509 case I am using here.

[Bug fortran/108369] FM509 Fails to compile with error

[jvdelisle at gcc dot gnu.org]

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

--- Comment #14 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
the '-x f77' id documented here:

https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Overall-Options.html#Overall-Options

All it does is tell the compiler the source is fixed form or free-form. 
Admittedly that is confusing. -std= is definately what should be used for
various dialects of fortran.  The .f suffix on the file also tells the compiler
fixed form.

With this, we should consider changing the use of the option as it does no
relate to dialect but rather the form of the source code.

[Bug fortran/108369] FM509 Fails to compile with error

[jvdelisle at gcc dot gnu.org]

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

--- Comment #15 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Do we close this bug as invalid or do we need to adjustsomething?

[Bug fortran/108369] FM509 Fails to compile with error when using undocumented -x option

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |jvdelisle at gcc dot gnu.org
             Status|NEW                         |ASSIGNED
            Summary|FM509 Fails to compile with |FM509 Fails to compile with
                   |error                       |error when using
                   |                            |undocumented -x option

--- Comment #16 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Works using the correct compiler option.  We probably should get rid of or
change the -x option or document it.

[Bug fortran/108369] FM509 Fails to compile with error when using undocumented -x option

[anlauf at gcc dot gnu.org]

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

--- Comment #17 from anlauf at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #16)
> Works using the correct compiler option.  We probably should get rid of or
> change the -x option or document it.

Is there a way to warn the user that this is a deprecated option that
will be removed in a future version?  We could start issuing this warning
immediately and finally remove it e.g. in gcc-14.

At least we should stop mentioning this option in gcc/doc/invoke.texi,
so that it does no longer appear in the documentation under "-x language".

[Bug fortran/108369] FM509 Fails to compile with error when using undocumented -x option

[jvdelisle at gcc dot gnu.org]

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

--- Comment #18 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
(In reply to anlauf from comment #17)
> (In reply to Jerry DeLisle from comment #16)
> > Works using the correct compiler option.  We probably should get rid of or
> > change the -x option or document it.
> 
I was imagining deleting it altogether and document that it is deleted and
advise users to use one of the correct options that specifies fixed form. I was
going to wait for 14.

> Is there a way to warn the user that this is a deprecated option that
> will be removed in a future version?  We could start issuing this warning
> immediately and finally remove it e.g. in gcc-14.
> 
> At least we should stop mentioning this option in gcc/doc/invoke.texi,
> so that it does no longer appear in the documentation under "-x language".

I can indeed do this warning in 13 pretty quickly I think.