This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: FWD: Re: OpenACC subarray specifications in the GCC Fortran front end
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Thomas Schwinge <thomas at codesourcery dot com>
- Cc: Cesar Philippidis <cesar at codesourcery dot com>, gcc-patches at gcc dot gnu dot org, fortran at gcc dot gnu dot org, Ilmir Usmanov <i dot usmanov at samsung dot com>, Ilmir Usmanov <zfts at yandex dot ru>
- Date: Fri, 11 Jul 2014 12:29:20 +0200
- Subject: Re: FWD: Re: OpenACC subarray specifications in the GCC Fortran front end
- Authentication-results: sourceware.org; auth=none
- References: <87ha4p92qj dot fsf at schwinge dot name> <53763254 dot 1000402 at samsung dot com> <537DA7CD dot 4050407 at samsung dot com> <87fvi8p5mp dot fsf at schwinge dot name>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Fri, Jul 11, 2014 at 12:11:10PM +0200, Thomas Schwinge wrote:
> To avoid duplication of work: with Jakub's Fortran OpenMP 4 target
> changes recently committed to trunk, and now merged into gomp-4_0-branch,
> I have trimmed down Ilmir's patch to just the OpenACC bits, OpenMP 4
> target changes removed, and TODO markers added to integrate into that.
Resolving the TODO markers would be nice, indeed.
> Jakub, before your Fortran OpenMP 4 target changes, Ilmir had written the
> test case gcc/testsuite/gfortran.dg/gomp/map-1.f90 (based on his
> interpretation and implementation of OpenMP 4 target), which I have now
> amended with XFAILs and changed error messages -- anything in there that
> you'd like to see addressed for Fortran OpenMP 4 target?
> + !$omp target map(j(5:4)) ! { dg-error "Lower bound of OpenMP array section in greater than upper" "" { xfail *-*-* } }
> + !$omp end target
I think this isn't an error in Fortran, if low bound is above upper bound,
then it is considered a zero size array section. Though supposedly for
depend clause we might want to diagnose that.
> + !$omp target map(aas) ! { dg-error "The upper bound in the last dimension must appear" "" { xfail *-*-* } }
> + !$omp end target
Assumed-size in map without array section would be indeed nice thing to
diagnose.
> + !$omp target map(tt%i) ! { dg-error "Syntax error in OpenMP variable list" }
> + !$omp end target ! { dg-bogus "Unexpected !\\\$OMP END TARGET statement" "" { xfail *-*-* } }
Right now the parsing of !$omp directives in case of parsing error rejects
the whole directive, perhaps it should be reconsidered unless it is a fatal
error from which there is no easy way out.
> + !$omp target map(tt%j(1)) ! { dg-bogus "Syntax error in OpenMP variable list" "" { xfail *-*-* } }
> + !$omp end target ! { dg-bogus "Unexpected !\\\$OMP END TARGET statement" "" { xfail *-*-* } }
> +
> + !$omp target map(tt%j(1:)) ! { dg-bogus "Syntax error in OpenMP variable list" "" { xfail *-*-* } }
> + !$omp end target ! { dg-bogus "Unexpected !\\\$OMP END TARGET statement" "" { xfail *-*-* } }
These two are pending resolution on omp-lang, I had exchanged a few mails
about it, I think we shouldn't support those for consistency with the C/C++
support, where tt.j[1] or tt.j[1:] and similar is explicitly invalid.
Jakub