Hi all,
This patch removes the "sorry" message for the OpenMP "requires
dynamic_allocators" feature in C, C++ and Fortran.
The clause is supposed to state that the user code will not work without
the omp_alloc/omp_free and omp_init_allocator/omp_destroy_allocator and
these things *are* prese
On 08/03/2022 11:30, Hafiz Abid Qadeer wrote:
gcc/ChangeLog:
* omp-low.cc (omp_enable_pinned_mode): New function.
(execute_lower_omp): Call omp_enable_pinned_mode.
This worked for x86_64, but I needed to make the attached adjustment to
work on powerpc without a linker error.
On 08/03/2022 11:30, Hafiz Abid Qadeer wrote:
This patches changes calls to malloc/free/calloc/realloc and operator new to
memory allocation functions in libgomp with
allocator=ompx_unified_shared_mem_alloc.
This additional patch adds transformation for omp_target_alloc. The
OpenMP 5.0 documen
On 02/04/2022 13:04, Andrew Stubbs wrote:
This additional patch adds transformation for omp_target_alloc. The
OpenMP 5.0 document says that addresses allocated this way needs to work
without is_device_ptr. The easiest way to make that work is to make them
USM addresses.
Actually, reading on
This patch adjusts the testcases, previously proposed, to allow for
testing on machines with varying page sizes and default amounts of
lockable memory. There turns out to be more variation than I had thought.
This should go on mainline at the same time as the previous patches in
this thread.
This patch adds enough support for "requires unified_address" to make
the sollve_vv testcases pass. It implements unified_address as a synonym
of unified_shared_memory, which is both valid and the only way I know of
to unify addresses with Cuda (could be wrong).
This patch should be applied on
On 28/09/2023 20:59, Toon Moene wrote:
On 9/28/23 21:26, Jakub Jelinek wrote:
It is worse than that, usually the LTO format changes e.g. any time any
option or parameter is added on a release branch (several times a
year) and
at other times as well.
Though, admittedly GCC is the single packag
s lost from libgcc if we build it
for DImode/TImode rather than SImode/DImode, a change we make in a later
patch in this series.
I can probably self-approve this, but I'll give Andrew Stubbs a chance
to comment.
Thanks,
Julian
2021-06-18 Julian Brown
gcc/
* config/gcn/gcn.md (mulsi
o fix up the result afterwards.
These patterns are lost from libgcc if we build it for DImode/TImode
rather than SImode/DImode, a change we make in a later patch in this
series.
I can probably self-approve this, but I'll give Andrew Stubbs a chance
to comment.
Thanks,
Julian
2021-06-18 Ju
h alternatives for all operations that
might be needed). Those gaps are filled in by this patch, or by the
preceding patches in the series.
I can probably self-approve this, but I'll give Andrew Stubbs a chance
to comment.
Thanks,
Julian
2021-06-18 Julian Brown
gcc/
* config/
On 18/06/2021 15:19, Julian Brown wrote:
This patch changes the argument and return types for the libgcc __udivsi3
and __umodsi3 helper functions for GCN to USItype instead of SItype.
This is probably just cosmetic in practice.
I can probably self-approve this, but I'll give Andrew Stu
On 17/04/2025 15:10, Tobias Burnus wrote:
Hi all,
@Fortraners: Comments to the added 'do concurrent' item?
@Thomas: Are you fine with this C++ wording?
@Andrew: Likewise for C++ and ROCm bump?
This part is fine with me.
Andrew
Anyone: comments are welcome.
Affected pages:
* https://gcc.
12 matches
Mail list logo
