public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/38312] Unexpected STATEMENT FUNCTION statement
[not found] <bug-38312-4@http.gcc.gnu.org/bugzilla/>
@ 2011-11-12 22:41 ` kargl at gcc dot gnu.org
2011-11-12 23:31 ` sgk at troutmask dot apl.washington.edu
2013-05-18 2:52 ` bdavis at gcc dot gnu.org
2 siblings, 0 replies; 5+ messages in thread
From: kargl at gcc dot gnu.org @ 2011-11-12 22:41 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 5+ messages in thread* [Bug fortran/38312] Unexpected STATEMENT FUNCTION statement
[not found] <bug-38312-4@http.gcc.gnu.org/bugzilla/>
2011-11-12 22:41 ` [Bug fortran/38312] Unexpected STATEMENT FUNCTION statement kargl at gcc dot gnu.org
@ 2011-11-12 23:31 ` sgk at troutmask dot apl.washington.edu
2013-05-18 2:52 ` bdavis at gcc dot gnu.org
2 siblings, 0 replies; 5+ messages in thread
From: sgk at troutmask dot apl.washington.edu @ 2011-11-12 23:31 UTC (permalink / raw)
To: gcc-bugs
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 +0000, 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 |
+ +---------------------------------------+
+ | internal module/subprogram |
+ +---------------------------------------+
+ | end |
+ +---------------------------------------+
*/
@@ -3381,7 +3381,10 @@ loop:
handled inside of parse_executable(), because they aren't really
loop statements. */
-static void
+static bool in_execute_state;
+void parse_do_block (void);
+
+void
parse_do_block (void)
{
gfc_statement st;
@@ -3442,7 +3445,13 @@ loop:
break;
default:
- unexpected_statement (st);
+ if (!in_execute_state)
+ unexpected_statement (st);
+ else
+ {
+ gfc_warning ("Line at %C parsed as a STATEMENT FUNCTION");
+ accept_statement (ST_ASSIGNMENT);
+ }
goto loop;
}
@@ -3810,7 +3819,9 @@ parse_executable (gfc_statement st)
break;
case ST_DO:
+ in_execute_state = true;
parse_do_block ();
+ in_execute_state = false;
if (check_do_closure () == 1)
return ST_IMPLIED_ENDDO;
break;
^ permalink raw reply [flat|nested] 5+ messages in thread* [Bug fortran/38312] Unexpected STATEMENT FUNCTION statement
[not found] <bug-38312-4@http.gcc.gnu.org/bugzilla/>
2011-11-12 22:41 ` [Bug fortran/38312] Unexpected STATEMENT FUNCTION statement kargl at gcc dot gnu.org
2011-11-12 23:31 ` sgk at troutmask dot apl.washington.edu
@ 2013-05-18 2:52 ` bdavis at gcc dot gnu.org
2 siblings, 0 replies; 5+ messages in thread
From: bdavis at gcc dot gnu.org @ 2013-05-18 2:52 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug fortran/38312] New: poor error message
@ 2008-11-28 20:59 jv244 at cam dot ac dot uk
2008-12-11 19:01 ` [Bug fortran/38312] Unexpected STATEMENT FUNCTION statement kargl at gcc dot gnu dot org
2008-12-11 19:03 ` kargl at gcc dot gnu dot org
0 siblings, 2 replies; 5+ messages in thread
From: jv244 at cam dot ac dot uk @ 2008-11-28 20:59 UTC (permalink / raw)
To: gcc-bugs
> cat test.f90
SUBROUTINE S1(t1,t2,c0,n)
REAL :: t1(n,n),t2(n,n),c0(n,n)
INTEGER :: i,j,k
DO i=1,n
DO j=1,n
DO k=1,n
co(i,j)=t1(i,k)*t2(j,k)
ENDDO
ENDDO
ENDDO
END SUBROUTINE S1
> gfortran test.f90
test.f90:7.29:
co(i,j)=t1(i,k)*t2(j,k)
1
Error: Unexpected STATEMENT FUNCTION statement at (1)
I couldn't agree more, but some users might get confused.
Imagine you take your 'Fortran 90/95 for Scientists and Engineers' book to
understand what the compiler really means.
--
Summary: poor error message
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38312
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2013-05-18 2:52 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <bug-38312-4@http.gcc.gnu.org/bugzilla/>
2011-11-12 22:41 ` [Bug fortran/38312] Unexpected STATEMENT FUNCTION statement kargl at gcc dot gnu.org
2011-11-12 23:31 ` sgk at troutmask dot apl.washington.edu
2013-05-18 2:52 ` bdavis at gcc dot gnu.org
2008-11-28 20:59 [Bug fortran/38312] New: poor error message jv244 at cam dot ac dot uk
2008-12-11 19:01 ` [Bug fortran/38312] Unexpected STATEMENT FUNCTION statement kargl at gcc dot gnu dot org
2008-12-11 19:03 ` kargl at gcc dot gnu dot org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).