[Bug fortran/38312] Unexpected STATEMENT FUNCTION statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38312 Joost VandeVondele changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #8 from Joost VandeVondele --- The current error message has changed : test.f90:7:6: co(i,j)=t1(i,k)*t2(j,k) 1 Error: The function result on the lhs of the assignment at (1) must have the pointer attribute. now the location gives a hint.
[Bug fortran/38312] Unexpected STATEMENT FUNCTION statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38312 --- Comment #9 from Dominique d'Humieres --- > The current error message has changed : > > test.f90:7:6: > > co(i,j)=t1(i,k)*t2(j,k) > 1 > > Error: The function result on the lhs of the assignment at (1) must have > the pointer attribute. > > now the location gives a hint. Confirmed. The change occurred between revisions r227754 (2015-09-14, old error) and r228407 (2015-10-02, new error), likely r228222 (pr63921). How do you prefer to resolve this PR: as FIXED or WONTFIX?
[Bug fortran/38312] Unexpected STATEMENT FUNCTION statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38312 Joost VandeVondele changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Joost VandeVondele --- let's go for fixed.
[Bug fortran/38312] Unexpected STATEMENT FUNCTION statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38312 Bud Davis bdavis at gcc dot gnu.org changed: What|Removed |Added CC||bdavis at gcc dot gnu.org --- Comment #7 from Bud Davis bdavis at gcc dot gnu.org --- 18 months since any comments were made... If I had a vote, it would be close as a WONT FIX. --bud
[Bug fortran/38312] Unexpected STATEMENT FUNCTION statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38312 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #5 from kargl at gcc dot gnu.org 2011-11-12 22:03:49 UTC --- I've looked at this issue, and I have come to the conclusion that it should be closed as WONTFIX. First, an error is issued, so one can fix their Fortran code. Now, for the problem. The matchers are called from the parser according this diagram (parse.c line 1717). +---+ | program subroutine function module | +---+ |use| +---+ |import | +---+ | |implicit none| | +---+-+ | | parameter | implicit | | +---+-+ | format | | derived type | | entry | parameter | interface | | | data| specification | | | | statement func | | +---+-+ | | data|executable | +-+---+-+ |contains | +---+ | internal module/subprogram | +---+ |end| +---+ As one can see, a DATA statement and a statement function are parsed at the same level. A programmer can use an implied do-loop within a DATA statement. Unfortunately, an implied do-loop is parsed by the same code that parses a regular do-loop. It appears that insufficient information is contained within the parser at the point where the error is issued to determine that the do-loop is in an executable portion of the program.
[Bug fortran/38312] Unexpected STATEMENT FUNCTION statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38312 --- Comment #6 from Steve Kargl sgk at troutmask dot apl.washington.edu 2011-11-12 22:41:06 UTC --- On Sat, Nov 12, 2011 at 10:03:49PM +, kargl at gcc dot gnu.org wrote: --- Comment #5 from kargl at gcc dot gnu.org 2011-11-12 22:03:49 UTC --- I've looked at this issue, and I have come to the conclusion that it should be closed as WONTFIX. First, an error is issued, so one can fix their Fortran code. Now, for the problem. The matchers are called from the parser according this diagram (parse.c line 1717). +---+ | program subroutine function module | +---+ |use| +---+ |import | +---+ | |implicit none| | +---+-+ | | parameter | implicit | | +---+-+ | format | | derived type | | entry | parameter | interface | | | data| specification | | | | statement func | | +---+-+ | | data|executable | +-+---+-+ |contains | +---+ | internal module/subprogram | +---+ |end| +---+ As one can see, a DATA statement and a statement function are parsed at the same level. A programmer can use an implied do-loop within a DATA statement. Unfortunately, an implied do-loop is parsed by the same code that parses a regular do-loop. It appears that insufficient information is contained within the parser at the point where the error is issued to determine that the do-loop is in an executable portion of the program. I can generate laptop:kargl[230] gfc4x -c foo.f90 foo.f90:6.19: co(i)=t1(i)*2 1 Warning: Line at (1) parsed as a STATEMENT FUNCTION foo.f90:6.8: co(i)=t1(i)*2 1 Error: Variable type is UNKNOWN in assignment at (1) with this very ugly kludge. Index: parse.c === --- parse.c(revision 181307) +++ parse.c(working copy) @@ -1723,30 +1723,30 @@ unexpected_statement (gfc_statement st) valid before calling here, i.e., ENTRY statements are not allowed in INTERFACE blocks. The following diagram is taken from the standard: -+---+ -| program subroutine function module | -+---+ -| use | -+---+ -| import| -+---+ -||implicit none | -|+---+--+ -|| parameter | implicit| -|+---+--+ -| format | | derived type| -| entry | parameter | interface | -|| data| specification | -|| | statement func | -|+---+--+ -|| data|executable| -++---+--+ -|contains | -+---+ -| internal module/subprogram | -+---+ -| end | -+---+ ++---+ +| program subroutine function module | ++---+ +|use| ++---+ +|import | ++---+ +| |implicit none| +| +---+-+ +| | parameter | implicit | +| +---+-+ +| format | | derived type | +| entry | parameter | interface | +| | data| specification | +| | | statement func | +| +---+-+ +| | data|executable | ++-+---+-+ +|contains | +
[Bug fortran/38312] Unexpected STATEMENT FUNCTION statement
--- Comment #3 from kargl at gcc dot gnu dot org 2008-12-11 18:58 --- Change subject line. Reduced test case troutmask:sgk[204] cat pr38312.f90 SUBROUTINE S1(t1,t2,c0,n) REAL :: t1(n),c0(n) INTEGER :: i,j,k DO i=1,n co(i)=t1(i)*2 ENDDO END SUBROUTINE S1 -- kargl at gcc dot gnu dot org changed: What|Removed |Added Summary|poor error message |Unexpected STATEMENT ||FUNCTION statement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38312
[Bug fortran/38312] Unexpected STATEMENT FUNCTION statement
--- Comment #4 from kargl at gcc dot gnu dot org 2008-12-11 18:59 --- *** Bug 37793 has been marked as a duplicate of this bug. *** -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38312
