[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320 Paul Thomas changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #29 from Paul Thomas --- This was completely fixed way back when :-) Thanks for the report, Damian. Closing Paul
[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320 --- Comment #28 from CVS Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:eaf883710c0039eca5caea5115e848adb4ab67bd commit r11-6832-geaf883710c0039eca5caea5115e848adb4ab67bd Author: Paul Thomas Date: Thu Jan 21 10:00:00 2021 + Fortran: This patch fixes comments 23 and 24 of PR96320. 2021-01-21 Paul Thomas gcc/fortran PR fortran/96320 * decl.c (gfc_match_modproc): It is not an error to find a module procedure declaration within a contains block. * expr.c (gfc_check_vardef_context): Pure procedure result is assignable. Change 'own_scope' accordingly. * resolve.c (resolve_typebound_procedure): A procedure that has the module procedure attribute is almost certainly a module procedure, whatever its interface. gcc/testsuite/ PR fortran/96320 * gfortran.dg/module_procedure_5.f90 : New test. * gfortran.dg/module_procedure_6.f90 : New test.
[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320 --- Comment #27 from Paul Thomas --- Created attachment 49875 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49875=edit Fix for the cases in comments 23 and 24 Hi Damian, Happy New Year! or I wish you a better one anyway. I have been doing a bit of catching up. The original patch for this PR is now applied as far back as I want to go. The new attachment fixes the testcases in comments 23 and 24. It even regtests OK. Thanks for your patience. Paul
[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320 --- Comment #26 from CVS Commits --- The releases/gcc-9 branch has been updated by Paul Thomas : https://gcc.gnu.org/g:101873f243237de4d868af95b89120a48cf86f6e commit r9-9149-g101873f243237de4d868af95b89120a48cf86f6e Author: Paul Thomas Date: Mon Jan 4 14:42:10 2021 + This patch fixes PR96320. See the explanatory comment in the testcase. 2021-01-04 Paul Thomas gcc/fortran PR fortran/96320 * interface.c (gfc_check_dummy_characteristics): If a module procedure arrives with assumed shape in the interface and deferred shape in the procedure itself, update the latter and copy the lower bounds. gcc/testsuite/ PR fortran/96320 * gfortran.dg/module_procedure_4.f90 : New test.
[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320 --- Comment #25 from CVS Commits --- The releases/gcc-10 branch has been updated by Paul Thomas : https://gcc.gnu.org/g:c2840cf16aaa665aaac4f51345104c5766fb2406 commit r10-9180-gc2840cf16aaa665aaac4f51345104c5766fb2406 Author: Paul Thomas Date: Sun Aug 2 10:57:59 2020 +0100 This patch fixes PR96320. See the explanatory comment in the testcase. 2020-08-01 Paul Thomas gcc/fortran PR target/96320 * interface.c (gfc_check_dummy_characteristics): If a module procedure arrives with assumed shape in the interface and deferred shape in the procedure itself, update the latter and copy the lower bounds. gcc/testsuite/ PR target/96320 * gfortran.dg/module_procedure_4.f90 : New test. (cherry picked from commit a5baf71b0a5bd79923c095cf81218b8194008f60)
[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320 --- Comment #24 from Damian Rouson --- This appears to be another example of an issue with a module procedure defined in the same module as its interface body. In this case, the compiler doesn't recognize a reference to the procedure: ± cat subroutine-call.f90 module hole_interface type hole_t contains procedure set_user_defined end type interface module subroutine set_diameter (this) class(hole_t) this end subroutine module subroutine set_user_defined(this) class(hole_t) this end subroutine end interface contains module procedure set_user_defined end procedure module procedure set_diameter call this%set_user_defined end procedure end module use hole_interface end ± gfortran subroutine-call.f90 subroutine-call.f90:26:6: 26 | use hole_interface | 1 Error: ‘set_user_defined’ must be a module procedure or an external procedure with an explicit interface at (1) ± gfortran --version GNU Fortran (GCC) 11.0.0 20200804 (experimental)
[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320 --- Comment #23 from Damian Rouson --- A related issue arises if the procedure in question is a pure function as demonstrated below. The code compiles cleanly if either 1. The result-spec is absent and the procedure is renamed new_foo in both the interface body and in the procedure definition, or 2. The interface body is repeated in the procedure definition instead the "module procedure" syntax. ± cat pure-shape-mismatch.f90 module foobar implicit none type foo integer bar end type interface pure module function create() result(new_foo) implicit none type(foo) new_foo end function end interface contains module procedure create new_foo%bar = 1 end procedure end module ± gfortran -c pure-shape-mismatch.f90 pure-shape-mismatch.f90:17:4: 17 | new_foo%bar = 1 |1 Error: Variable ‘new_foo’ cannot appear in a variable definition context (assignment) at (1) in PURE procedure ± gfortran --version GNU Fortran (GCC) 11.0.0 20200804 (experimental)
[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320 --- Comment #22 from Steve Kargl --- On Mon, Aug 03, 2020 at 11:45:20PM +, damian at sourceryinstitute dot org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320 > > --- Comment #21 from Damian Rouson --- > Now that the patch fixing this PR has been committed to the trunk, should it > be > marked as "Resolved" instead of "Assigned?" > Depends on if someone (whomever committed the patch) is going to backport it to 9 and 10 branch.
[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320 --- Comment #21 from Damian Rouson --- Now that the patch fixing this PR has been committed to the trunk, should it be marked as "Resolved" instead of "Assigned?"
[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320 --- Comment #20 from Paul Thomas --- (In reply to CVS Commits from comment #19) > The master branch has been updated by Paul Thomas : > > https://gcc.gnu.org/g:a5baf71b0a5bd79923c095cf81218b8194008f60 > > commit r11-2489-ga5baf71b0a5bd79923c095cf81218b8194008f60 > Author: Paul Thomas > Date: Sun Aug 2 10:57:59 2020 +0100 > > This patch fixes PR96320. See the explanatory comment in the testcase. > > 2020-08-01 Paul Thomas > > gcc/fortran > PR target/96320 > * interface.c (gfc_check_dummy_characteristics): If a module > procedure arrives with assumed shape in the interface and > deferred shape in the procedure itself, update the latter and > copy the lower bounds. > > gcc/testsuite/ > PR target/96320 > * gfortran.dg/module_procedure_4.f90 : New test. 'target' has been replaced with 'fortran' in the ChangeLog commit :-) Paul
[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320 --- Comment #19 from CVS Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:a5baf71b0a5bd79923c095cf81218b8194008f60 commit r11-2489-ga5baf71b0a5bd79923c095cf81218b8194008f60 Author: Paul Thomas Date: Sun Aug 2 10:57:59 2020 +0100 This patch fixes PR96320. See the explanatory comment in the testcase. 2020-08-01 Paul Thomas gcc/fortran PR target/96320 * interface.c (gfc_check_dummy_characteristics): If a module procedure arrives with assumed shape in the interface and deferred shape in the procedure itself, update the latter and copy the lower bounds. gcc/testsuite/ PR target/96320 * gfortran.dg/module_procedure_4.f90 : New test.
[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320
--- Comment #18 from Dominique d'Humieres ---
With
--- ../_clean/gcc/fortran/interface.c 2020-07-11 20:06:47.0 +0200
+++ gcc/fortran/interface.c 2020-07-28 11:41:57.0 +0200
@@ -1466,8 +1466,19 @@ gfc_check_dummy_characteristics (gfc_sym
int i, compval;
gfc_expr *shape1, *shape2;
+ if (s1->ns->proc_name && s1->ns->proc_name->attr.module_procedure
+ && s1->as->type == AS_ASSUMED_SHAPE
+ && s2->as->type == AS_DEFERRED)
+ {
+ s2->as->type = AS_ASSUMED_SHAPE;
+ for (i = 0; i < s2->as->rank; i++)
+ if (s1->as->lower[i] != NULL)
+ s2->as->lower[i] = gfc_copy_expr (s1->as->lower[i]);
+ }
+
if (s1->as->type != s2->as->type)
{
+/* gfc_warning_now (0, "s1 %i s2 %i \n", s1->as->type, s2->as->type);
*/
snprintf (errmsg, err_len, "Shape mismatch in argument '%s'",
s1->name);
return false;
the patch regtest without regression.
> > /opt/gcc/work/gcc/testsuite/gfortran.dg/whole_file_23.f90:18:32:
> >
> >18 | pure integer function lensum (words, sep)
> > Warning: Interface mismatch in global procedure 'lensum' at (1): Shape
> > mismatch
> > in argument 'words'
>
> So, change the dg-error to "Interface mismatch in" from
> "Shape mismatch in". Clearly, Paul's patch detects an
> error earlier in the parsing than previously detected.
The warning is at least as old as GCC7 but is suppressed in the testsuite by
-pedantic-errors (very surprising) thus doesn't fail.
[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320 --- Comment #17 from Steve Kargl --- On Tue, Jul 28, 2020 at 10:32:50AM +, dominiq at lps dot ens.fr wrote: > > What I guessed, but I still see (not new) > > /opt/gcc/work/gcc/testsuite/gfortran.dg/whole_file_23.f90:18:32: > >18 | pure integer function lensum (words, sep) > |1 > Warning: Interface mismatch in global procedure 'lensum' at (1): Shape > mismatch > in argument 'words' > So, change the dg-error to "Interface mismatch in" from "Shape mismatch in". Clearly, Paul's patch detects an error earlier in the parsing than previously detected.
[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320 --- Comment #16 from Dominique d'Humieres --- > Bother - I left the diagnostic line in the patch: > > + gfc_warning_now (0, "s1 %i s2 %i \n", s1->as->type, s2->as->type); > >Sorry about that What I guessed, but I still see (not new) /opt/gcc/work/gcc/testsuite/gfortran.dg/whole_file_23.f90:18:32: 18 | pure integer function lensum (words, sep) |1 Warning: Interface mismatch in global procedure 'lensum' at (1): Shape mismatch in argument 'words'
[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320
--- Comment #15 from paul.richard.thomas at gmail dot com ---
Bother - I left the diagnostic line in the patch:
+ gfc_warning_now (0, "s1 %i s2 %i \n", s1->as->type, s2->as->type);
Sorry about that
Paul
On Tue, 28 Jul 2020 at 10:24, dominiq at lps dot ens.fr <
gcc-bugzi...@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320
>
> --- Comment #14 from Dominique d'Humieres ---
> After fixing the ICEs by replacing
> 's1->ns->proc_name->attr.module_procedure'
> with 's1->ns->proc_name && s1->ns->proc_name->attr.module_procedure' I am
> left
> with two regressions:
>
> FAIL: gfortran.dg/proc_decl_26.f90 -O 2 blank line(s) in output
> FAIL: gfortran.dg/proc_decl_26.f90 -O (test for excess errors)
> FAIL: gfortran.dg/whole_file_23.f90 -O 1 blank line(s) in output
> FAIL: gfortran.dg/whole_file_23.f90 -O (test for excess errors)
>
> % gfc /opt/gcc/work/gcc/testsuite/gfortran.dg/proc_decl_26.f90
> f951: Warning: s1 2 s2 1
>
> /opt/gcc/work/gcc/testsuite/gfortran.dg/proc_decl_26.f90:20:11:
>
>20 | call foo(two) ! { dg-error "Shape mismatch in argument" }
> | 1
> Error: Interface mismatch in dummy procedure 'f1' at (1): Shape mismatch in
> argument 'a'
> f951: Warning: s1 2 s2 1
>
> /opt/gcc/work/gcc/testsuite/gfortran.dg/proc_decl_26.f90:21:11:
>
>21 | call bar(two) ! { dg-error "Shape mismatch in argument" }
> | 1
> Error: Interface mismatch in dummy procedure 'f2' at (1): Shape mismatch in
> argument 'a'
> % gfc /opt/gcc/work/gcc/testsuite/gfortran.dg/whole_file_23.f90
> f951: Warning: s1 3 s2 2
>
> /opt/gcc/work/gcc/testsuite/gfortran.dg/whole_file_23.f90:18:32:
>
>18 | pure integer function lensum (words, sep)
> |1
> Warning: Interface mismatch in global procedure 'lensum' at (1): Shape
> mismatch
> in argument 'words'
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You are the assignee for the bug.
[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320
--- Comment #14 from Dominique d'Humieres ---
After fixing the ICEs by replacing 's1->ns->proc_name->attr.module_procedure'
with 's1->ns->proc_name && s1->ns->proc_name->attr.module_procedure' I am left
with two regressions:
FAIL: gfortran.dg/proc_decl_26.f90 -O 2 blank line(s) in output
FAIL: gfortran.dg/proc_decl_26.f90 -O (test for excess errors)
FAIL: gfortran.dg/whole_file_23.f90 -O 1 blank line(s) in output
FAIL: gfortran.dg/whole_file_23.f90 -O (test for excess errors)
% gfc /opt/gcc/work/gcc/testsuite/gfortran.dg/proc_decl_26.f90
f951: Warning: s1 2 s2 1
/opt/gcc/work/gcc/testsuite/gfortran.dg/proc_decl_26.f90:20:11:
20 | call foo(two) ! { dg-error "Shape mismatch in argument" }
| 1
Error: Interface mismatch in dummy procedure 'f1' at (1): Shape mismatch in
argument 'a'
f951: Warning: s1 2 s2 1
/opt/gcc/work/gcc/testsuite/gfortran.dg/proc_decl_26.f90:21:11:
21 | call bar(two) ! { dg-error "Shape mismatch in argument" }
| 1
Error: Interface mismatch in dummy procedure 'f2' at (1): Shape mismatch in
argument 'a'
% gfc /opt/gcc/work/gcc/testsuite/gfortran.dg/whole_file_23.f90
f951: Warning: s1 3 s2 2
/opt/gcc/work/gcc/testsuite/gfortran.dg/whole_file_23.f90:18:32:
18 | pure integer function lensum (words, sep)
|1
Warning: Interface mismatch in global procedure 'lensum' at (1): Shape mismatch
in argument 'words'
[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320
--- Comment #13 from Dominique d'Humieres ---
With the attached patch I get several ICEs:
(lldb) run /opt/gcc/work/gcc/testsuite/gfortran.dg/asan/pointer_assign_16.f90
Process 88073 launched:
'/opt/gcc/gcc11w/libexec/gcc/x86_64-apple-darwin19.5.0/11.0.0/f951' (x86_64)
Process 88073 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=1, address=0x58)
frame #0: 0x00010004f9e7
f951`gfc_check_dummy_characteristics(s1=0x0001453175e0,
s2=0x0001453175e0, type_must_agree=, errmsg="\b\x02???,
err_len=200) at interface.c:1469:7
1466 int i, compval;
1467 gfc_expr *shape1, *shape2;
1468
-> 1469 if (s1->ns->proc_name->attr.module_procedure
1470 && s1->as->type == AS_ASSUMED_SHAPE
1471 && s2->as->type == AS_DEFERRED)
1472 {
[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320 --- Comment #12 from Damian Rouson --- Thanks to each of you for looking at and working on this.
[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320
--- Comment #11 from Paul Thomas ---
Created attachment 48935
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48935=edit
Proposed patch for the PR
I decided that the best way of proceeding was to correct the array spec and
benefit from the rest of the tests in gfc_check_dummy_characteristics.
My tree is polluted with work on PDTs right now and so I cannot do a full
regtest. However, with the patch applied submodule* and module_procedure* test
just fine as does 'module_procedure_4.f90':
! { dg-do run }
!
! Test the fix for PR96320 in which the assumed shape of 'arg' in the
! interface for 'bar' was mirrored by the 'arg' in the module procedure
! incorrectly have deferred shape.
!
! Contributed by Damian Rouson
!
module foobar
type foo
contains
procedure, nopass :: bar1
procedure, nopass :: bar2
procedure, nopass :: bar3
end type
interface
module subroutine bar1(arg)
character(len=*) arg(:)
end subroutine
module subroutine bar2(arg)
character(len=*) arg(3:)
end subroutine
module subroutine bar3(arg)
character(len=*) arg(2)
end subroutine
end interface
contains
module procedure bar1
if (lbound(arg, 1) .ne. 1) stop 1
if (arg(3) .ne. 'hijk') stop 2
end procedure
! Make sure that the lower bound of an assumed shape array dummy,
! if defined, is passed to the module procedure.
module procedure bar2
if (lbound(arg, 1) .ne. 3) stop 3
if (arg(3) .ne. 'abcd') stop 4
end procedure
! This makes sure that an dummy with explicit shape has the upper
! bound correctly set in the module procedure.
module procedure bar3
if (lbound(arg, 1) .ne. 1) stop 5
if (arg(3) .ne. 'hijk') stop 6 ! { dg-warning "is out of bounds" }
end procedure
end module
use foobar
character(4) :: list(3) = ['abcd', 'efgh' , 'hijk']
type(foo) :: f
call f%bar1(list)
call f%bar2(list)
call f%bar3(list)
end
[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320 Dominique d'Humieres changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320
Paul Thomas changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org
CC||pault at gcc dot gnu.org
--- Comment #10 from Paul Thomas ---
Confirmed.
The argument in the interface is assumed shape, as expected, while its shadow
in the module procedure is tagged as deferred shape. Yet another fix (!):
index ba1c8bc322e..9e822f5c396 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -1464,8 +1464,12 @@ gfc_check_dummy_characteristics (gfc_symbol *s1,
gfc_symb
ol *s2,
{
int i, compval;
gfc_expr *shape1, *shape2;
+ bool module_procedure;
- if (s1->as->type != s2->as->type)
+ module_procedure = s1->ns->proc_name &&
+s1->ns->proc_name->attr.module_procedure;
+
+ if (s1->as->type != s2->as->type && !module_procedure)
{
snprintf (errmsg, err_len, "Shape mismatch in argument '%s'",
s1->name);
This fixes the problem but I rather think that the proper way to do it is
further upstream. decl.c(gfc_match_submod_proc) looks as if the array spec is
copied as it should be but I need to do a gdb session to check this. I'll have
to put my thinking cap on regarding Steve's offering in comment 5.
It should be noted that the submodule version works as intended in all versions
of gfortran for which submodules are implemented:
module foobar
type foo
contains
procedure, nopass :: bar
end type
interface
module subroutine bar(arg)
character(len=*) arg(:)
end subroutine
end interface
end module
submodule (foobar) sbar
contains
module procedure bar
print *, arg
end procedure
end submodule
use foobar
character(4) :: book(2) = ['abcd', 'efgh']
call bar(book)
end
I'm onto it.
Thanks for the report
Paul
[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320 --- Comment #9 from Damian Rouson --- (In reply to Dominique d'Humieres from comment #3) > > Do you mean this is F2008 extension? Usually I think of "extension" as describing something non-standard. This is a standard feature. I meant simply that it was not allowed before Fortran 2008 introduced submodules. I think the primary purpose of submodules is to facilitate the separation of interfaces and procedure definitions. And for programmers who prefer to not repeat the argument list in two places (and then have to change it in two places), Fortran 2008 (and 2018) allow the "module procedure" syntax used in the submitted code.
[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320 --- Comment #8 from Steve Kargl --- On Sun, Jul 26, 2020 at 09:35:56PM +, jvdelisle at charter dot net wrote: > > I my too simple terms, when you define the interface and then use > module procedure in the contains, all of the declarations in the > interface exist as if you had them in the declaration of the > subroutine or function in the contains. This includes all arguments > and whether or not the procedure is a subroutine or a function. > > I was not aware of this either untill I saw some other code > Damian was doing earlier this week that does actually compile > fine like this with gfortran. It is a modern feature and if you > think about it, very useful in that it saves a lot of typing. > One can choose do do it either way, but this way shown truly uses > the interface to define everything. > I have thought about it, and I have concluded it is rather curious programming paradigm, because ... module foo private public bar interface bar ! Make bar generic module subroutine bar1(x) real, intent(in) :: x end subroutine bar1 end interface integer x contains ! ! Several hundreds to several thousand lines of code may ! appear here, which separates dummy argument declarations ! from where the dummy arguments are used. ! module procedure bar1 print *, x end procedure bar1 end module foo Oh, and at least, this simply test program works with my 2nd patch. program bah use foo real y y = 42. call bar(y) end program bah Likely, yet another patch that will sit in bugzilla.
[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320 --- Comment #7 from Damian Rouson --- For context, I nearly always put the procedure definition in a submodule. In this case, I'm attempting to use a tool that needs to parse the code and the tool doesn't support submodules so I moved the procedure definition into the module. The workaround is easy: I just eliminate the interface and put all the argument declarations in the procedure definition. So this is not an important bug for me. It just cost me some time to figure out what the problem was.
[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320 jvdelisle at charter dot net changed: What|Removed |Added CC||jvdelisle at charter dot net --- Comment #6 from jvdelisle at charter dot net --- I my too simple terms, when you define the interface and then use module procedure in the contains, all of the declarations in the interface exist as if you had them in the declaration of the subroutine or function in the contains. This includes all arguments and whether or not the procedure is a subroutine or a function. I was not aware of this either untill I saw some other code Damian was doing earlier this week that does actually compile fine like this with gfortran. It is a modern feature and if you think about it, very useful in that it saves a lot of typing. One can choose do do it either way, but this way shown truly uses the interface to define everything.
[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |NEW
Priority|P3 |P4
--- Comment #5 from kargl at gcc dot gnu.org ---
May be better patch.
Index: gcc/fortran/resolve.c
===
@@ -13241,6 +13253,9 @@ resolve_fl_procedure (gfc_symbol *sym, int mp_flag)
}
check_formal:
+ if (iface && !iface->formal)
+ return true;
+
/* Check the characteristics of the formal arguments. */
if (sym->formal && sym->formal_ns)
{
[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #4 from kargl at gcc dot gnu.org ---
This patch
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 280157)
+++ gcc/fortran/resolve.c (working copy)
@@ -13242,7 +13254,7 @@ resolve_fl_procedure (gfc_symbol *sym, int mp_flag)
check_formal:
/* Check the characteristics of the formal arguments. */
- if (sym->formal && sym->formal_ns)
+ if (sym->formal && iface->formal && sym->formal_ns)
{
for (arg = sym->formal; arg && arg->sym; arg = arg->next)
{
allows Damian's example to compile without error.
Damian's use of 'module precedure' is backwards from the way I
use it. That is, I use it to construct generic interfaces
like
module foo
private
public bar
interface bar ! Make bar generic
module procedure bar1
module procedure bar2
end interface
contains
subroutine bar1(x)
real x
end subroutine bar1
subroutine bar2(x)
double precision x
end subroutine bar2
end module foo
It seems strange to me to put a subroutine interface in
an interface construct, and then in the 'contain' section of
a module simply using 'module procedure bar' where there are
no details of the interface and implementation details occur.
I do not know if the patch permits valid Fortran to compile,
nor I have regression tested the patch, nor do I care.
[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320 --- Comment #3 from Dominique d'Humieres --- > Fortran 2008 added module subroutine interface bodies specifically to allow > interface bodies in the same scope a the corresponding procedure definitions. > In order to avoid duplication, the standard also allows the procedure > definition > to begin with "module procedure" and then to omit all arguments. That's what > is > done in the submitted code. The code is accepted by the NAG and Intel > compilers. Do you mean this is F2008 extension?
[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320 --- Comment #2 from Damian Rouson --- Hi Dominique, > What do you want to do with your test? I don't understand the question. The submitted code is designed to be a minimal demonstration of the problem so I don't want to do anything with it other than demonstrate the problem. In case you're asking what the original application was doing, it was for handling command-line arguments. > Why do you think it is standard conforming? Fortran 2008 added module subroutine interface bodies specifically to allow interface bodies in the same scope a the corresponding procedure definitions. In order to avoid duplication, the standard also allows the procedure definition to begin with "module procedure" and then to omit all arguments. That's what is done in the submitted code. The code is accepted by the NAG and Intel compilers.
[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320 Dominique d'Humieres changed: What|Removed |Added Last reconfirmed||2020-07-26 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed down to GCC7. What do you want to do with your test? Why do you think it is standard conforming?
