On Thu, Nov 05, 2020 at 06:18:11PM +, Kwok Cheung Yeung wrote:
> I have run the tests (with _OPENMP >= 201511) and added
> -Wno-deprecated-declarations option to the testcases that trigger the
> deprecation warning.
>
> I also found a bug in the previous version of the patch - C++ doesn't
On 04/11/2020 2:33 pm, Jakub Jelinek wrote:
LGTM, except:
+ omp_lock_hint_contended __GOMP_DEPRECATED_5_0 = omp_sync_hint_contended,
omp_sync_hint_nonspeculative = 4,
- omp_lock_hint_nonspeculative = omp_sync_hint_nonspeculative,
+ omp_lock_hint_nonspeculative __GOMP_DEPRECATED_5_0 =
On Wed, Nov 04, 2020 at 02:23:17PM +, Kwok Cheung Yeung wrote:
> I have used Tobias' recently added patch for Fortran deprecation support to
> mark omp_get_nested and omp_set_nested as deprecated. If the omp_lock_hint_*
> integer parameters are marked though, then the deprecation warnings will
On 28/10/2020 4:06 pm, Jakub Jelinek wrote:
On Wed, Oct 28, 2020 at 03:41:25PM +, Kwok Cheung Yeung wrote:
What if we made the definition of __GOMP_DEPRECATED in the original patch
conditional on the current value of __OPENMP__? i.e. Something like:
+#if defined(__GNUC__) && __OPENMP__ >=
On Wed, Oct 28, 2020 at 03:41:25PM +, Kwok Cheung Yeung wrote:
> I found this almost two-year old thread while looking for how the OpenMP 5.0
> deprecations were to be handled.
>
> > E.g. if somebody tries hard to write portable OpenMP code and has:
> > omp_lock_t lock;
> > #if __OPENMP__
Hello
I found this almost two-year old thread while looking for how the OpenMP 5.0
deprecations were to be handled.
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 (, omp_sync_hint_contended);
#elif
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
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
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
On Wed, Jan 02, 2019 at 05:58:07PM +0100, Ulrich Drepper wrote:
> Should we mark the symbols that are deprecated in OpenMP 5.0 as such in
> the header? Yes, this will break code that uses the symbols and -Werror
> but this is the standard writers intend, right? It's easy enough to
> work around
10 matches
Mail list logo
