[Bug fortran/108369] FM509 Fails to compile with error when using undocumented -x option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369 --- Comment #18 from Jerry DeLisle --- (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.
[Bug fortran/108369] FM509 Fails to compile with error when using undocumented -x option
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369 Jerry DeLisle 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 --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369 --- Comment #15 from Jerry DeLisle --- Do we close this bug as invalid or do we need to adjustsomething?
[Bug fortran/108369] FM509 Fails to compile with error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369 --- Comment #14 from Jerry DeLisle --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369 --- Comment #13 from Jerry DeLisle --- Created attachment 54267 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54267=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369 --- Comment #12 from Steve Kargl --- On Fri, Jan 13, 2023 at 11:49:44AM +, ben.brewer at codethink dot co.uk wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369 > > --- Comment #11 from Ben Brewer --- > 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369 --- Comment #11 from Ben Brewer --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369 --- Comment #10 from Steve Kargl --- On Fri, Jan 13, 2023 at 01:09:22AM +, jvdelisle at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369 > > --- Comment #6 from Jerry DeLisle --- > 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369 --- Comment #9 from Jerry DeLisle --- The NIST files themselves are too large to attach here.
[Bug fortran/108369] FM509 Fails to compile with error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369 --- Comment #8 from Jerry DeLisle --- Created attachment 54263 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54263=edit Reference files used by script
[Bug fortran/108369] FM509 Fails to compile with error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369 --- Comment #7 from Jerry DeLisle --- Created attachment 54262 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54262=edit Script used. may need to be adjusted for ones envoronment
[Bug fortran/108369] FM509 Fails to compile with error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369 --- Comment #6 from Jerry DeLisle --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #5 from Jerry DeLisle --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369 --- Comment #4 from Steve Kargl --- On Wed, Jan 11, 2023 at 09:50:37PM +, 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
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,
>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, >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, >expr->where);
}
clearly we want the first branch about character length, so
`where` == NULL
[Bug fortran/108369] FM509 Fails to compile with error
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
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
