FWD: Re: OpenACC subarray specifications in the GCC Fortran front end

[Cesar Philippidis]

On 07/11/2014 03:29 AM, Jakub Jelinek wrote:
> 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.

This patch has the openacc data clauses use the new openmp maps. In the
process of doing so, I removed a lot of the old OMP_LIST_ enums and
added a few OMP_MAP enums to match what the c frontend currently supports.

Thomas, is this OK for gomp-4_0-branch? There are no new regressions.
This patch doesn't depend on the nested function patch I posted a while ago.

>> 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, should I drop the map-1.f90 test?

Thanks,
Cesar

-------------- next part --------------
A non-text attachment was scrubbed...
Name: subarrays-mappings-gcc.diff
Type: text/x-patch
Size: 37653 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20140724/85c693f2/attachment.bin>