*ping* – Re: [Patch] Fortran: %re/%im fixes for OpenMP/OpenACC + gfc_is_simplify_contiguous

[Tobias Burnus <tobias@codesourcery.com>]

*PING*

this avoids an ICE in gfc_is_simplify_contiguous, which can be at least
triggered with OpenMP/OpenACC.

For %re/%im it outputs a nicer error than an ICE or misleading message.
[Whether %re may be used is still unclear, recently opened OpenMP +
OpenACC spec issues still have to be discussed.]

Tobias

On 09.02.21 12:41, Tobias Burnus wrote:
> Hi Thomas, hi all
>
> Updated patch. Changes: Testcases split + updated/extended.
> OK for mainline?
>
> Regarding the comments:
>
> On 09.02.21 10:45, Thomas Schwinge wrote:
>> Thanks for filing/locating these discussion items for OpenACC/OpenMP
>> upstream.  May also put these references into the testcases, so that
>> once
>> these get addressed, we have something to 'grep' for in GCC?
>
> Actually, they are already in the file. Alternative is to add them as
> link, but I am not sure that's better. (I moved them now to the top.)
>
>> I note that 'zz' variants (see below) are not being checked for OpenMP
>
> I have now added them; I had them before but as many checks triggered,
> I thought the tests were not really worthwhile.
>
>>> +!$acc update self(zz%re)
>>> +!$acc update self(zz%im)
>>> +end
>> And for OpenACC, the 'zz' variants do not emit this error message here.
>> (That's not immediately obvious to me.)
>
> Answer: 'git add' missing. The reason is that with and without
> Julian's patch, the error message is different. Without his patch,
> the error is:
> !$acc update self(zz%re) ! { dg-error "not a proper array section" }
>
>> I can see how data mapping of '[...]%re' etc. are problematic (we're
>> constructing an "incomplete object"?), but 'update' etc. I'd have
>> expected to work: would just copy the respective "part".
> Granted. The array(:)%re access might update too much, but that's not
> different to array with strides or with contiguous arrays sections
> which contain component reference (and more than one component).
>
> But that's more a question for the spec committee – if it is supposed
> to work, the code needs to be updated.
>
> Tobias
>
>
>
-----------------
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank Thürauf