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 like
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 =
om
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__ >= 2
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 (&lock, omp_sync_hint_contended);
#
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 s
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
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 t
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 f
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 for the time being.
Aside from the header changes the files implementing
11 matches
Mail list logo