This patch fixes an issue where alignment argument for new operator was being
ignored in the unified
shared memory transform.
Thanks,
--
Hafiz Abid Qadeer
Siemens/CodeSourceryFrom af4162aac4086eb953139f7796bbb2ad232c8975 Mon Sep 17 00:00:00 2001
From: Hafiz Abid Qadeer
Date: Tue, 25 Oct 2022
From: Andrew Stubbs
Implement the -foffload-memory=pinned option such that libgomp is
instructed to enable fully-pinned memory at start-up. The option is
intended to provide a performance boost to certain offload programs without
modifying the code.
This feature only works on Linux, at present,
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 helps existing code to benefit
from the unified shared memory. The libgomp does the correct thing with all
the mapping constructs
From: Andrew Stubbs
This adds support for using Cuda Managed Memory with omp_alloc. It will be
used as the underpinnings for "requires unified_shared_memory" in a later
patch.
There are two new predefined allocators, ompx_unified_shared_mem_alloc and
ompx_host_mem_alloc, plus corresponding memo
From: Andrew Stubbs
This is the front-end portion of the Unified Shared Memory implementation.
It removes the "sorry, unimplemented message" in C, C++, and Fortran, and sets
flag_offload_memory, but is otherwise inactive, for now.
It also checks that -foffload-memory isn't set to an incompatible
From: Andrew Stubbs
Add a new option. It will be used in follow-up patches.
gcc/ChangeLog:
* common.opt: Add -foffload-memory and its enum values.
* coretypes.h (enum offload_memory): New.
* doc/invoke.texi: Document -foffload-memory.
---
gcc/common.opt | 16 +
requires unified_shared_memory
openmp, nvptx: ompx_unified_shared_mem_alloc
openmp: -foffload-memory=pinned
Hafiz Abid Qadeer (1):
openmp: Use libgomp memory allocation functions with unified shared
memory.
gcc/c/c-parser.cc | 13 +-
gcc/common.opt
This patch fixes an issue that although gfortran accepts
'requires dynamic_allocators', it does not set the omp_requires_mask
accordingly.
gcc/fortran/ChangeLog:
* parse.cc (gfc_parse_file): Set OMP_REQUIRES_DYNAMIC_ALLOCATORS
bit in omp_requires_mask.
---
gcc/fortran/parse.cc |
An allocate clause in target region must specify an allocator
unless the compilation unit has requires construct with
dynamic_allocators clause. Current implementation of the allocate
clause did not check for this restriction. This patch fills that
gap.
gcc/ChangeLog:
* omp-low.cc (omp_m
On 05/02/2022 19:09, Hafiz Abid Qadeer wrote:
> On 04/02/2022 11:25, Hafiz Abid Qadeer wrote:
>> On 04/02/2022 09:46, Thomas Schwinge wrote:
>>
>>>
>>> Abid, are you going to address these? I think it does make sense if the
>>> C/C++ and Fortran test ca
On 04/02/2022 11:25, Hafiz Abid Qadeer wrote:
> On 04/02/2022 09:46, Thomas Schwinge wrote:
>
>>
>> Abid, are you going to address these? I think it does make sense if the
>> C/C++ and Fortran test cases match as much as feasible.
>>
> Sure. I will do that.
ait. So it makes sense to me to
not have it in fortran
testcase too. It also seems more cleaner than putting some limits on number of
threads or increasing
the size which will be a bit fragile.
Thanks,
--
Hafiz Abid Qadeer
read.
>
> Location is global '' at 0x ([stack]+0x1ddc0)
>
> Thread T10 (tid=4135398, running) created by main thread at:
> #0 pthread_create
> ../../../../repos/gcc/libsanitizer/tsan/tsan_interceptors_posix.cpp:1001
> (libtsan.so.2+0x62c76)
>
an/allocate-1.f90:116 in
> __m_MOD_foo._omp_fn.2
>
> Tobias
@Tobias: Thanks for your comments and the patch.
@Thomas: Thanks for reporting the problem. Did you notice similar behavior with
libgomp/testsuite/libgomp.c-c++-common/allocate-1.c? It was used as base for
fortran testcase and it
shows similar warnings with -fthread=sanitize. I am trying to figure out if the
problem you observed
is a general one or just specific to fortran testcase.
--
Hafiz Abid Qadeer
Mentor, a Siemens Business
As Thomas reported in
https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588448.html
a test added in my recent allocate clause patch fails on m32. It was due
to default kind for integer matching c_intptr_t for m32. I have now
changed it to 0_1 so that always integer with kind=1 is used.
gcc/te
lue, using c_intptr_t seems to make more sense than
> restricting it to (l)l64.
Problem was with the literal 0 having same kind as c_intptr_t for m32. So there
was no diagnostic in
that case. I am going to change it 0_1 to make the test more robust.
Thanks,
--
Hafiz Abid Qadeer
Mentor, a Siemens Business
This patch looks for malloc/free calls that were generated by allocate statement
that is associated with allocate directive and replaces them with GOMP_alloc
and GOMP_free.
gcc/ChangeLog:
* omp-low.c (scan_sharing_clauses): Handle OMP_CLAUSE_ALLOCATOR.
(scan_omp_allocate): New.
gcc/ChangeLog:
* doc/gimple.texi: Describe GIMPLE_OMP_ALLOCATE.
* gimple-pretty-print.c (dump_gimple_omp_allocate): New function.
(pp_gimple_stmt_1): Call it.
* gimple.c (gimple_build_omp_allocate): New function.
* gimple.def (GIMPLE_OMP_ALLOCATE): New node.
Currently we are only handling omp allocate directive that is associated
with an allocate statement. This statement results in malloc and free calls.
The malloc calls are easy to get to as they are in the same block as allocate
directive. But the free calls come in a separate cleanup block. To h
gcc/fortran/ChangeLog:
* trans-openmp.c (gfc_trans_omp_clauses): Handle OMP_LIST_ALLOCATOR.
(gfc_trans_omp_allocate): New function.
(gfc_trans_omp_directive): Handle EXEC_OMP_ALLOCATE.
gcc/ChangeLog:
* tree-pretty-print.c (dump_omp_clause): Handle OMP_CLAUSE_ALLOC
Currently we only make use of this directive when it is associated
with an allocate statement.
gcc/fortran/ChangeLog:
* dump-parse-tree.c (show_omp_node): Handle EXEC_OMP_ALLOCATE.
(show_code_node): Likewise.
* gfortran.h (enum gfc_statement): Add ST_OMP_ALLOCATE.
statement to GOMP_alloc and GOMP_free calls.
Hafiz Abid Qadeer (5):
[gfortran] Add parsing support for allocate directive (OpenMP 5.0).
[gfortran] Translate allocate directive (OpenMP 5.0).
[gfortran] Handle cleanup of omp allocated variables (OpenMP 5.0).
Gimplify allocate directive (OpenMP 5.0
porarily marking some
> symbols).
Done.
> Also, I think allocate clause like the privatization clauses should allow
> common blocks and I see code that uses the marks uses something like:
> for (list = OMP_LIST_TO; list != OMP_LIST_NUM;
>list = (list ==
Commit 13b6c7639cf assumed that registers in a span will be in a certain
order. But that assumption is not true at least for the big endian targets.
Currently amdgcn is probably only target where CFA is split into multiple
registers so build_span_loc is only gets called for it. However, the
dwf_cfa
On 02/11/2021 16:27, Jakub Jelinek wrote:
> On Fri, Oct 22, 2021 at 02:05:02PM +0100, Hafiz Abid Qadeer wrote:
>> This patch adds support for OpenMP 5.0 allocate clause for fortran. It does
>> not
>> yet support the allocator-modifier as specified in OpenMP 5.1. The allocate
On 09/11/2021 15:59, Jakub Jelinek wrote:
> On Sun, Jun 13, 2021 at 02:27:38PM +0100, Hafiz Abid Qadeer wrote:
>> *** with this patch (edited for brevity)***
>>
>> 0024 CIE
>>
>> DW_CFA_def_cfa_expression: DW_OP_bregx SGPR49+0, DW_OP_const1u
Ping.
On 24/08/2021 16:55, Hafiz Abid Qadeer wrote:
> Ping.
>
> On 22/07/2021 11:58, Hafiz Abid Qadeer wrote:
>> Ping.
>>
>> On 13/06/2021 14:27, Hafiz Abid Qadeer wrote:
>>> Add support for architectures such as AMD GCN, in which the pointer size is
>
This patch adds support for OpenMP 5.0 allocate clause for fortran. It does not
yet support the allocator-modifier as specified in OpenMP 5.1. The allocate
clause is already supported in C/C++.
gcc/fortran/ChangeLog:
* dump-parse-tree.c (show_omp_clauses): Handle OMP_LIST_ALLOCATE.
Ping.
On 22/07/2021 11:58, Hafiz Abid Qadeer wrote:
> Ping.
>
> On 13/06/2021 14:27, Hafiz Abid Qadeer wrote:
>> Add support for architectures such as AMD GCN, in which the pointer size is
>> larger than the register size. This allows the CFI information to include
>&g
4 byte block: 91 68 6 6 (DW_OP_fbreg:
> -2
>
> gdb then fails to see 'foo' at all (cannot break on it) and the lookup of
> 'argc'
> inside it fails (setting a breakpoint also fails without -flto-partition=max,
> but I can print argc just fine).
>
> I suggest you file a bug with gdb and see how that resolves.
I have filed https://sourceware.org/bugzilla/show_bug.cgi?id=28147 for this
issue.
Thanks,
--
Hafiz Abid Qadeer
Mentor, a Siemens Business
ind the concrete parent for the consumer as there is no link from abstract to
concrete.
Thanks,
--
Hafiz Abid Qadeer
Mentor, a Siemens Business
Ping.
On 13/06/2021 14:27, Hafiz Abid Qadeer wrote:
> Add support for architectures such as AMD GCN, in which the pointer size is
> larger than the register size. This allows the CFI information to include
> multi-register locations for the stack pointer, frame pointer, and return
On 19/07/2021 17:41, Richard Biener wrote:
> On July 19, 2021 6:13:40 PM GMT+02:00, Hafiz Abid Qadeer
> wrote:
>> On 19/07/2021 11:45, Richard Biener wrote:
>>> On Fri, Jul 16, 2021 at 10:23 PM Hafiz Abid Qadeer
>>> wrote:
>>>>
>>>> On 15/
On 19/07/2021 11:45, Richard Biener wrote:
> On Fri, Jul 16, 2021 at 10:23 PM Hafiz Abid Qadeer
> wrote:
>>
>> On 15/07/2021 13:09, Richard Biener wrote:
>>> On Thu, Jul 15, 2021 at 12:35 PM Hafiz Abid Qadeer
>>> wrote:
>>>>
>>>> On 15/
On 15/07/2021 13:09, Richard Biener wrote:
> On Thu, Jul 15, 2021 at 12:35 PM Hafiz Abid Qadeer
> wrote:
>>
>> On 15/07/2021 11:33, Thomas Schwinge wrote:
>>>
>>>> Note that the "parent" should be abstract but I don't think dwarf has a
>
interpret"
>> that. I wonder if adding a DW_AT_declaration to the late DWARF
>> emitted "parent" would fix things as well here?
>
> (I suppose not, Abid?)
>
Yes, adding DW_AT_declaration does not fix the problem.
--
Hafiz Abid Qadeer
Mentor, a Siemens Business
Currently, if we look at the debug information for offload kernel
regions, it looks something like this:
void foo (void)
{
#pragma acc kernels
{
}
}
DW_TAG_compile_unit
DW_AT_name("")
DW_TAG_subprogram // notional parent function (foo) with no code range
DW_TAG_subprogram // of
Map GCN address spaces to the proposed DWARF address spaces defined by AMD at
https://llvm.org/docs/AMDGPUUsage.html#amdgpu-dwarf-address-class-mapping-table
gcc/
* config/gcn/gcn.c: Include dwarf2.h.
(gcn_addr_space_debug): New function.
(TARGET_ADDR_SPACE_DEBUG): New hoo
As size of address is bigger than registers in amdgcn, we are forced to use
DW_CFA_def_cfa_expression to make an expression that concatenates multiple
registers for the value of the CFA. This then prohibits us from using many
of the dwarf ops which expect CFA rule to be a single regsiter plus an o
Currently we don't get any call frame information for the amdgcn target.
This patch makes necessary adjustments to generate CFI that can work with
ROCGDB (ROCm 3.8+).
gcc/
* config/gcn/gcn.c (move_callee_saved_registers): Emit CFI notes for
prologue register saves.
(gcn_de
.
Hafiz Abid Qadeer (3):
[amdgcn] Update CFI configuration
[amdgcn] Use frame pointer for CFA expressions.
[amdgcn] Add hook for DWARF address spaces.
gcc/common/config/gcn/gcn-common.c | 2 +-
gcc/config/gcn/gcn.c | 171 +
gcc/config/gcn/gcn.h
Add support for architectures such as AMD GCN, in which the pointer size is
larger than the register size. This allows the CFI information to include
multi-register locations for the stack pointer, frame pointer, and return
address.
This patch was originally posted by Andrew Stubbs in
https://gcc
ChangeLog:
2021-04-11 Hafiz Abid Qadeer
* MAINTAINERS (Write After Approval): Add myself.
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 0fbbc0519d0..db25583b37b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -568,6 +568,7
pplying the patch.
It was in the collapse-1.c file. I have removed it now.
>
> With this removed and the other nits fixed: LGTM & thanks for the patch.
Updated patch attached. I will apply if there are no further comments and once I
get write access.
Thanks,
Abid
>From ecd9e83cce37
We have seen an ICE both on trunk and devel/omp/gcc-10 branches which can
be reprodued with this simple testcase. It occurs if an OpenACC loop has
a collapse clause and any of the loop being collapsed uses GT or GE
condition. This issue is specific to OpenACC.
int main (void)
{
int ix, iy;
i
ich should have been
CPPFLAGS="$CPPFLAGS $INCICONV"
OK to commit the attached patch?
2018-11-06 Hafiz Abid Qadeer
* config/iconv.m4 (AM_ICONV_LINK): Don't overwrite CPPFLAGS.
Append $INCICONV to it.
* gcc/configure: Regenerate.
* l
46 matches
Mail list logo
