On Wed, Jan 02, 2019 at 06:29:27PM +0100, Jakub Jelinek wrote:
> On Wed, Jan 02, 2019 at 06:23:57PM +0100, Ulrich Drepper wrote:
> > On 1/2/19 6:21 PM, Jakub Jelinek wrote:
> > > As we aren't implementing OpenMP 5.0 fully yet and especially because
> > > we aren't implementing the new nesting ICV semantics, we shouldn't do it
> > > now,
> > > they are valid in OpenMP 4.5.
> >
> > OK, that applies to omp_[gs]et_nested.
> >
> > How about the lock symbols? All the sync symbols are already defined as
> > aliases (or more correctly, the other way around). The sooner people
> > change, the better, and at least those parts of OpenMP5 are "implemented".
>
> We ignore the hints, so "implemented" is the right term ;).
>
> I'd say there is no hurry for them either, I believe what is deprecated in
> 5.0 is going to be removed only (if at all) in 6.0, so like 5 years from
> now, so waiting until we implement all of OpenMP 5.0 shouldn't hurt that
> much.
E.g. if somebody tries hard to write portable OpenMP code and has:
omp_lock_t lock;
#if __OPENMP__ >= 201811L
omp_init_lock_with_hint (&lock, omp_sync_hint_contended);
#elif __OPENMP__ >= 201511L
omp_init_lock_with_hint (&lock, omp_lock_hint_contended);
#else
omp_init_lock (&lock);
#endif
they would now get a warning even when they did the right thing.
So, deprecating those when we change __OPENMP__ macro is the right thing.
Jakub
