[Bug fortran/32365] New: OpenMP: Better error message for specification statement in executable section

[Bug fortran/32365] New: OpenMP: Better error message for specification statement in executable section

[burnus at gcc dot gnu dot org]

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.


-- 
           Summary: OpenMP: Better error message for specification statement
                    in executable section
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Keywords: diagnostic, openmp
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: burnus at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32365

[Bug fortran/32365] OpenMP: Better error message for specification statement in executable section

[jakub at gcc dot gnu dot org]

------- Comment #1 from jakub at gcc dot gnu dot org  2007-06-20 16:23 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32365

[Bug fortran/32365] Better error message for specification statement in executable section

[burnus at gcc dot gnu dot org]

------- Comment #2 from burnus at gcc dot gnu dot org  2007-06-20 16:39 -------
> 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);


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|openmp                      |
            Summary|OpenMP: Better error message|Better error message for
                   |for specification statement |specification statement in
                   |in executable section       |executable section


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32365

[Bug fortran/32365] Better error message for specification statement in executable section

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2007-07-03 10:26:21
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32365

[Bug fortran/32365] Better error message for specification statement in executable section

[dfranke at gcc dot gnu dot org]

------- Comment #3 from dfranke at gcc dot gnu dot org  2009-12-11 21:44 -------
(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.


-- 

dfranke at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dfranke at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32365