Mon, Jun 29
Mon, Jun 22
Sun, Jun 14
Fri, Jun 12
Wed, Jun 10
Jun 4 2020
Jun 1 2020
May 27 2020
May 26 2020
May 25 2020
May 24 2020
Also may worth adding the test just in case.
May 18 2020
Does -fopenmp-version work with the Intel Compiler? How will this work if the GCC eventually gets support for OpenMP 5.0?
May 14 2020
May 12 2020
Joachim, thanks for taking care of this bug.
Apr 15 2020
Apr 13 2020
Should I also add memory barriers to __kmp_linear_barrier_gather_template, __kmp_tree_barrier_gather, and __kmp_hierarchical_barrier_gather? They seem to suffer from the same problem on systems with weak memory order (but I don't have a handy test case to prove it).
Sorry, found one more issue.
May worth waiting for a day or two for others' comments, up to you.
Apr 8 2020
I don't see paired memory barrier in a child thread between assigning th.th_local.reduce_data in __kmp_barrier_template() and releasing b_arrived barrier flag that frees parent to go to reduce data. So it might be that the problem could just become lesser probable. Should paired KMP_MB be added after the reduce_data assignment? Or does atomic releasing of a flag serves as a memory barrier? Then my assumption is wrong and second MB is not needed.
Could you please tell which part is monitor thread?
Code under "#if KMP_USE_MONITOR" implements monitor thread which used earlier to control behavior of worker threads. Now it is not used by default, and worker threads follow requested wait policy themselves.
Apr 7 2020
The idea looks feasible to me in general.
Apr 2 2020
Could you please run clang-format on the changes (new lines are too long). Thanks.
Mar 25 2020
Mar 23 2020
Mar 18 2020
Adde check of task tiedness, and comment on why this is needed.
Shall the compiler generate the call of omp_fulfill_event after __kmpc_omp_task call? Or is it a user code?
Mar 5 2020
Mar 4 2020
Mar 3 2020
Addressed comments: removed "#if 0" code block; added basic checks for the test.
Mar 2 2020
We can have filechek tests, right? We should verify a bit more than the existence of a function that will return.
Feb 21 2020
Addressed Kelvin's comment.
Added full context.
Also added (missed) "value" attribute to Fortran interfaces.
We may need to also loose the internal tough limit of number of threads in the teams construct, which is currently not convenient to overcome. But this needs time to work on..
Jan 23 2020
Jan 20 2020
If possible, please also fix typo in FreeBSD-related code on line 289 of z_Linux_util.cpp (< is used instead of comma).
Jan 15 2020
Having a copy function per type allows us to reuse it, otherwise we have one copy function per static task location (at worst). Either works for me I think.
I also would be OK with either option.
But note that using per-type functions will require more additions to the interface, like:
(..., num_objects, array_of_copy_wrappers, array_of_desctuctor_wrappers, array_of_obj_offsets).
Then the library can iterate over objects to copy-construct them, then iterate to destroy them after the task is complete. Without any possibility of inlining of any wrappers.
Jan 14 2020
the task create and task issue step are
conceptually not separated anymore as it is
I don't think this can work reliably. Because not all C++ objects can be mem-copied.
E.g. an object can keep its own address or reference, and mem-copy will make it broken.
This could be fixed by generating (optional) thunk routine which would create all needed objects
in the library-allocated space, and similar routine which would destroy all the created objects.
Nov 27 2019
Nov 26 2019
Nov 25 2019
I am not an ARM expert, but don't see any problems with checking extra define here.
Nov 19 2019
Nov 18 2019
Nov 13 2019
I will try removing __kmp_internal_end_fini with a test that __kmp_internal_end_atexit is still called.
It is open-sourced many years ago, now under BSD license; IINM, it can be found at https://github.com/intel/IntelSEAPI/tree/master/ittnotify (though we don't update it regularly without real need);
and it is also part of Intel Tools products (e.g. Amplifier, etc.).
They already agreed to upstream the last change (removal of const). Not sure it will be possible to upstream .c --> .cpp, because they depend on many other customers. But I think this is minor issue for us.
One mode detail - the link I provided is not an "official" location of ittnotify, but just one more usage of it by SEAPI project. The updates of the ittnotify itself were published sporadically. And it will get its own stable location on githab soon (the publishing is in process).
Nov 7 2019
Looks acceptable to me. As well as removing the kmp_internal_end_fini symbol at all, as it duplicates the functionality of kmp_internal_end_dtor which has attribute "destructor". I am OK with either solution, would be good to hear others opinion.
Oct 30 2019
Oct 25 2019
Oct 8 2019
you may want to ask for D68045 landing there directly, as compiler-rt is a different project which I don't work on.
Sep 27 2019
Sep 25 2019
Sep 16 2019
Sep 4 2019
Sep 3 2019
BTW, there is also workaround without runtime patching, - set KMP_TEAMS_THREAD_LIMIT to the same value as OMP_THREAD_LIMIT. This avoids runtime segfault with old library.
Sep 2 2019
Aug 16 2019
Aug 12 2019
Aug 7 2019
Aug 6 2019
For the correct solution, could you point me to code that uses the dll_path_ptr member? Given that there were no problem with static const char dll_path[PATH_MAX] I guess it never assigns to *dll_path_ptr, but then I don't fully understand why it needs a pointer to a pointer...
Jul 29 2019
Jul 26 2019
I will contact ittnotify owners just in case. So that we might have lesser burden with possible future updates of this third-party code.
Jul 25 2019
LGTM (I'd treat this as NFC :).
Jul 16 2019
Jul 12 2019
Jul 10 2019
Jul 2 2019
Jun 27 2019
Of cause you are free to choose your own test, or simply extend existing test(s).