Re: [patch, openmp/openacc] Allow Fortran parameters in map/copy.

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [patch, openmp/openacc] Allow Fortran parameters in map/copy.

Andrew Stubbs-4
On 05/07/2019 12:49, Jakub Jelinek wrote:

> On Fri, Jul 05, 2019 at 12:31:17PM +0100, Andrew Stubbs wrote:
>> This patch allows Fortran "parameter" named constants to be named in OpenMP
>> map and OpenACC copy directives.
>>
>> Right now, the compiler just says something like:
>>
>>       !$omp target data map(tofrom:N,x)
>>                                   1
>>    Error: Object 'n' is not a variable at (1)
>>
>> This is technically correct, but is surprising to the user and AFAICT the
>> OpenMP/OpenACC documents don't say you can't name parameters, so I'd like it
>> to be allowed.
>
> I don't think you can do it in OpenMP, I can discuss in the language
> committee, but the definition of variable is:
>
> "A named data storage block, for which the value can be defined and redefined during
> the execution of a program."
>
> so I don't believe Fortran parameters are OpenMP variables.
> Scalar Fortran parameters don't even have any data storage block associated
> with them at all.

Agreed, they are not variables (nor variable), and copying them about is
entirely pointless (although, if you simply remove the error check GCC
will happily create storage for 'N' and do the copies).

And yet, this issue has generated a support request from a blocked
customer, and I'd like to improve their experience.

I could generate a warning, or add a note to the error message, but in
the interests of portability I thought just doing the right thing would
be nicer.

Any suggestions?

Andrew
Reply | Threaded
Open this post in threaded view
|

Re: [patch, openmp/openacc] Allow Fortran parameters in map/copy.

Jakub Jelinek
On Fri, Jul 05, 2019 at 02:15:12PM +0200, Jakub Jelinek wrote:

> On Fri, Jul 05, 2019 at 01:10:00PM +0100, Andrew Stubbs wrote:
> > > so I don't believe Fortran parameters are OpenMP variables.
> > > Scalar Fortran parameters don't even have any data storage block associated
> > > with them at all.
> >
> > Agreed, they are not variables (nor variable), and copying them about is
> > entirely pointless (although, if you simply remove the error check GCC will
> > happily create storage for 'N' and do the copies).
> >
> > And yet, this issue has generated a support request from a blocked customer,
> > and I'd like to improve their experience.
> >
> > I could generate a warning, or add a note to the error message, but in the
> > interests of portability I thought just doing the right thing would be
> > nicer.
> >
> > Any suggestions?
>
> I don't know what OpenACC says, perhaps it is different.
>
> For OpenMP, a warning is not good enough, because if Fortran PARAMETER is
> not a variable, then the program is invalid and needs to be rejected.
> You could improve the diagnostics by adding some explanation message that fortran
> PARAMETER is not a variable.

Got it confirmed, it might change in a future OpenMP release; and there has
been a change already in OpenMP 3.1 that might have intended to allow
Fortran PARAMETERs in firstprivate clause, but because the glossary hasn't
been changed, it is not valid even in firstprivate clause.

Note, if there is adjusted wording for Fortran PARAMETERs, it shouldn't be
done just for map clause, but all other OpenMP data sharing clauses.  Even
if PARAMETERs are eventually allowed as variables, it will be still limited
to firstprivate clause and perhaps some sorts of map clauses, nothing else,
e.g. for non-firstprivate privatization clauses you really need a definable
object or allocatable.

        Jakub
Reply | Threaded
Open this post in threaded view
|

Re: [patch, openmp/openacc] Allow Fortran parameters in map/copy.

Jakub Jelinek
On Fri, Jul 05, 2019 at 03:40:55PM +0100, Andrew Stubbs wrote:

> On 05/07/2019 15:04, Jakub Jelinek wrote:
> > > For OpenMP, a warning is not good enough, because if Fortran PARAMETER is
> > > not a variable, then the program is invalid and needs to be rejected.
> > > You could improve the diagnostics by adding some explanation message that fortran
> > > PARAMETER is not a variable.
> >
> > Got it confirmed, it might change in a future OpenMP release; and there has
> > been a change already in OpenMP 3.1 that might have intended to allow
> > Fortran PARAMETERs in firstprivate clause, but because the glossary hasn't
> > been changed, it is not valid even in firstprivate clause.
>
> OK, here is an alternative patch that merely tries to make the error message
> more informative.
>
> Basically, the user needs to get past "it isn't working but I need that
> value in this kernel", so hopefully this will help get them there.
>
> WDYT?

I don't like it, I'd end the message where you put ;, the rest doesn't make
sense and will just confuse users.  For one, the compiler should know if the
parameter needs to be copied or not, so doesn't need to talk about
probability thereof, and if it needs to be copied, it should be the compiler
that arranges that (PR90779) and the user has no way to overide or force
that behavior.

        Jakub