subroutine test use omp_lib implicit none integer, parameter :: NT = 4 integer :: a save a = 1 !$omp threadprivate(a) end subroutine test gfortran: Error: Unexpected !$OMP THREADPRIVATE statement at (1) Intel: Error: A specification statement cannot appear in the executable section. sunf95: ERROR: Compiler directive THREADPRIVATE must appear before the first executable statement.
There is nothing special about ST_OMP_THREADPRIVATE here, the Fortran parser as whole behaves this way. You get the same if you write say subroutine test integer :: i i = 1 common /myi/ i end subroutine test etc. Handling just ST_OMP_THREADPRIVATE specially would be IMHO a mistake, what perhaps could be done is e.g. adding something like case_decl: gfc_error ("%s statement can't appear after the first executable statement at %C", gfc_ascii_statement (st)); reject_statement (); break; into parse_executable before default: return st; in there.
> There is nothing special about ST_OMP_THREADPRIVATE here, the Fortran parser > as whole behaves this way. Sorry for missing that. > what perhaps could be done is e.g. adding something like > case_decl: > gfc_error ("%s statement can't appear after the first executable statement I wonder why this is not caught in parse.c's verify_st_order; the error message there is much nicer: gfc_error ("%s statement at %C cannot follow %s statement at %L", gfc_ascii_statement (st), gfc_ascii_statement (p->last_statement), &p->where);
(In reply to comment #2) > I wonder why this is not caught in parse.c's verify_st_order; the error > message there is much nicer Because it seems that verify_st_order is not called for every accepted statement. In the testcase of comment #1, this function is called just twice. Not at least three times as one would expect.