[Bug fortran/97390] New: Error compiling acc data present

[Bug fortran/97390] New: Error compiling acc data present

[afernandez at odyhpc dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97390

            Bug ID: 97390
           Summary: Error compiling acc data present
           Product: gcc
           Version: 9.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: afernandez at odyhpc dot com
  Target Milestone: ---

Hello,
While trying to compile an app with gfortran 9.3.0 & -fopenacc, the compiler
doesn't seem to recognize some directive and causes the following error
message:
 6475 |           !$acc data present(tempRbuffer, array, compactHaloInfo,
dimsizes, nHaloLayers, gpu_nList_send, gpu_idx_send, gpu_bufferOffset_send)
async(counter+1)
      |                1
Error: Unclassifiable OpenACC directive at (1)
The compiler recognizes other OpenACC directives but this error happens at
several points of the code. I'm not the developer and the app is supposed to
compile smoothly with the PGI compiler. Could this problem be caused by the
compiler or should I be looking at some specific conflict? Thanks.

[Bug fortran/97390] Error compiling acc data present

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97390

Thomas Schwinge <tschwinge at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
                 CC|                            |burnus at gcc dot gnu.org,
                   |                            |tschwinge at gcc dot gnu.org
   Last reconfirmed|                            |2020-10-13
             Status|UNCONFIRMED                 |WAITING
           Assignee|unassigned at gcc dot gnu.org      |tschwinge at gcc dot gnu.org

--- Comment #1 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
Would it be the case that this line is longer than 132 characters?  After this,
"characters are ignored in typical free-form lines in the source file"; see the
'-ffree-line-length' option.  Thus, does '-ffree-line-length-none' help?

(I cannot comment on (a) why that's a useful limit to have, and (b) whether the
error reporting shouldn't be improved.)

[Bug fortran/97390] Error compiling acc data present

[afernandez at odyhpc dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97390

--- Comment #2 from afernandez at odyhpc dot com ---
Hi Thomas. That was a good guess but it's not the problem. The flag
'-ffree-line-length-none' is already on and there are many other long lines in
the code. The compilation completes when the openacc directives are deactivated
so it's something specifically related to openacc. Thanks.

[Bug fortran/97390] Error compiling acc data present

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97390

--- Comment #3 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
Thanks for checking/confirming that.


Next try:

(In reply to afernandez from comment #0)
>  6475 |           !$acc data present([...]) async(counter+1)
>       |                1
> Error: Unclassifiable OpenACC directive at (1)

> I'm not the developer and the app

Is the source code freely available?

> is supposed to
> compile smoothly with the PGI compiler.

Per the current versions of the OpenACC specification, the 'data' construct
doesn't allow an 'async' clause, so this isn't valid OpenACC code.  If you
know, can you tell (is there some documentation) how PGI are implementing this?

[Bug fortran/97390] Error compiling acc data present

[afernandez at odyhpc dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97390

--- Comment #4 from afernandez at odyhpc dot com ---
The code can be downloaded from GitHub:
        git clone https://github.com/MPAS-Dev/MPAS-Model
        cd MPAS-Model
        git checkout atmosphere/v6.x-openacc
My experience with OpenACC is limited as I participated in a workshop 3 years
ago but haven't used it since then. Yesterday I began to read some
documentation (to refresh my memory) and the OpenACC 2.6 reference guide
(https://www.openacc.org/sites/default/files/inline-files/OpenACC%20API%202.6%20Reference%20Guide.pdf)
led me to think of this contruct as a standard one. Could this be an
enhancement of 2.6 versus 2.5? If this were the case, would moving GNU from
version 9 to 10 help? 
I'm unfamiliar with the PGI compilers so someone else might be able to chime in
and shed some light on any PGI implementation.

[Bug fortran/97390] [OpenAError compiling acc data present

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97390

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Error compiling acc data    |[OpenAError compiling acc
                   |present                     |data present

--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Thomas Schwinge from comment #1)
> Would it be the case that this line is longer than 132 characters?  [...]
> (I cannot comment on (a) why that's a useful limit to have

I don't know whether it is useful or not, but the Fortran standard has:

"In free source form [...] If a line consists entirely of characters of default
kind (7.4.4), it shall contain at most 132 characters" (Fortran 2018, 6.3.2.1 
Free form line length)


> , and (b) whether the error reporting shouldn't be improved.)

Well, the error message without changing the maximal supported line length is
(GCC 9, 10 or 11):

test.f90:2:132:
    2 |            !$acc data present(tempRbuffer, array, compactHaloInfo,
dimsizes, nHaloLayers, gpu_nList_send, gpu_idx_send, gpu_bufferOffset_send)
async(counter+1)
      |                                                                        
                                                           1
Error: Syntax error in OpenMP variable list at (1)

Which looks fine.



However, my error message improvements for GCC 10 really help. With
-ffree-line-length-none, the error is:

With GCC 9's : Error: Unclassifiable OpenACC directive at (1)

With GCC 10 or GCC 11:

    2 |            !$acc data present(tempRbuffer, array, compactHaloInfo,
dimsizes, nHaloLayers, gpu_nList_send, gpu_idx_send, gpu_bufferOffset_send)
async(counter+1)
      |                                                                        
                                                                       1
Error: Failed to match clause at (1)

Note the '1' is at 'async(...)'


I claim that GCC is right: 'acc data' does not have a 'async' clause in OpenACC
neither in 2.6 (= supported by GCC 10) nor in 3.0; see
https://www.openacc.org/specification

BTW: Consider using GCC 10, which extended the OpenACC support, cf.
https://gcc.gnu.org/gcc-10/changes.html

[Bug fortran/97390] [OpenACC] Error compiling acc data present

[afernandez at odyhpc dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97390

--- Comment #6 from afernandez at odyhpc dot com ---
After reading some more documentation and the pdf that you mentioned, I concur
that the line doesn't follow OpenACC standards. I will keep looking into the
problem (maybe the PGI compiler simply ignores the 'async' clause) and try
upgrading to GCC 10. Thanks.

[Bug fortran/97390] [OpenACC] 'async' clause on 'data' construct

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97390

Thomas Schwinge <tschwinge at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://github.com/OpenACC/
                   |                            |openacc-spec/issues/318
             Status|WAITING                     |SUSPENDED
            Summary|[OpenACC] Error compiling   |[OpenACC] 'async' clause on
                   |acc data present            |'data' construct

--- Comment #7 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
(In reply to Tobias Burnus from comment #5)
> I claim that GCC is right: 'acc data' does not have a 'async' clause in
> OpenACC neither in 2.6 (= supported by GCC 10) nor in 3.0; see
> https://www.openacc.org/specification

Thanks for confirming.

I've filed <https://github.com/OpenACC/openacc-spec/issues/318> "'async' clause
on 'data' construct" (need to be a member to see).  Thus setting this PR to
SUSPENDED until a decision is made.

[Bug fortran/97390] [OpenACC] 'async' clause on 'data' construct

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97390

--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tobias Burnus <burnus@gcc.gnu.org>:

https://gcc.gnu.org/g:4aa9742252ea419947fe32ff64c7546c92286b96

commit r11-3875-g4aa9742252ea419947fe32ff64c7546c92286b96
Author: Tobias Burnus <tobias@codesourcery.com>
Date:   Wed Oct 14 15:48:22 2020 +0200

    Fortran: Fix line-truncation warning for !$acc and !gcc$

    gcc/fortran/ChangeLog:

            PR fortran/97390
            * scanner.c (load_line): Fix line-truncation warning for !$acc
            and !gcc$ in free-form source code.

    gcc/testsuite/ChangeLog:

            PR fortran/97390
            * gfortran.dg/goacc/warn_truncated.f90: New test.

[Bug fortran/97390] [OpenACC] 'async' clause on 'data' construct

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97390

Thomas Schwinge <tschwinge at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|SUSPENDED                   |NEW
           Assignee|tschwinge at gcc dot gnu.org       |unassigned at gcc dot gnu.org

--- Comment #9 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
OpenACC 3.2, 1.16 "Changes from Version 3.1 to 3.2": "The 'async', 'wait' [...]
clauses may be specified on 'data' constructs."  (Not yet implemented in GCC.)