[Bug other/113317] New test case libgomp.c++/ind-base-2.C fails with ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113317 --- Comment #5 from jules at gcc dot gnu.org --- Hi, Unfortunately I no longer have access to any PowerPC machines, which limits my ability to help with this somewhat. I guess it's *something* like a CONVERT_EXPR/NOP_EXPR in an unexpected place, and is probably quite easy to fix with a suitable reproducer. Julian
[Bug other/113317] New test case libgomp.c++/ind-base-2.C fails with ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113317 jules at gcc dot gnu.org changed: What|Removed |Added CC||jules at gcc dot gnu.org --- Comment #2 from jules at gcc dot gnu.org --- I haven't been able to reproduce this with our local testing infrastructure on the powerpc64le machine available to me (i.e., the test works for me there). I'd be a bit surprised about a machine dependence at this early stage in parsing, but here we go! Let me know if there's any other information that might help track this down.
[Bug target/113331] New: AMDGCN: Compilation failure due to duplicate .LEHB/.LEHE symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113331 Bug ID: 113331 Summary: AMDGCN: Compilation failure due to duplicate .LEHB/.LEHE symbols Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jules at gcc dot gnu.org Target Milestone: --- Created attachment 57037 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57037&action=edit Test case The attached file fails to compile with AMD GCN offloading on current mainline. It also fails on GCC 13.2.0 as packaged in Debian, so this doesn't appear to be a regression. $ g++ -fopenmp -foffload=amdgcn-amdhsa -save-temps dup-syms.cc -o dup-syms ./dup-syms.xamdgcn-amdhsa.mkoffload.2.s:256:1: error: symbol '.LEHB0' is already defined .LEHB0: ^ ./dup-syms.xamdgcn-amdhsa.mkoffload.2.s:258:1: error: symbol '.LEHE0' is already defined .LEHE0: ^ ./dup-syms.xamdgcn-amdhsa.mkoffload.2.s:288:1: error: symbol '.LEHB1' is already defined .LEHB1: ^ ./dup-syms.xamdgcn-amdhsa.mkoffload.2.s:290:1: error: symbol '.LEHE1' is already defined .LEHE1: ^ The test case doesn't trigger with NVPTX offloading, but I don't think that definitely implies that this is something GCN-specific (vs. generically offload-related).
[Bug middle-end/113279] New: OpenMP 5 - Audit GOMP_MAP_FIRSTPRIVATE_REFERENCE handling for references to pointers to pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113279 Bug ID: 113279 Summary: OpenMP 5 - Audit GOMP_MAP_FIRSTPRIVATE_REFERENCE handling for references to pointers to pointers Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: jules at gcc dot gnu.org Target Milestone: --- The patch (approved and soon to be committed) to support "lvalue" parsing for C++ has a corner-case issue whereby references to pointers to pointers do not quite work interchangeably with pointers to pointers (i.e. when implicitly mapped). See the "ref2ptrptr_offset_decl_member_slice" functions in the libgomp test cases baseptrs-4.C and baseptrs-6.C. https://gcc.gnu.org/pipermail/gcc-patches/2024-January/641924.html It is possible that a slight semantic tweak to GOMP_MAP_FIRSTPRIVATE_REFERENCE handling in gimplify.cc or omp-low.cc might be able to repair these cases, if indeed that is required by the spec.
[Bug middle-end/113006] New: OpenMP 5 - lvalue parsing support for map/to/from clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113006
Bug ID: 113006
Summary: OpenMP 5 - lvalue parsing support for map/to/from
clause
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: jules at gcc dot gnu.org
Target Milestone: ---
The following test:
libgomp/testsuite/libgomp.c++/baseptrs-4.C
partly depends on the following in-review patches:
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629365.html
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629364.html
Tobias points out there is currently an unresolved OpenMP issue, 2618 ("Clarify
behavior of mapping lvalues on target construct"), which talks about whether
code like the following:
map(*p = 10)
map(x = 20)
map(x ? y[0] : p[1])
map(f(y))
is valid or not. He writes that the sentiment was to require that a 'map'
clause list item must have a base pointer or a base variable.
As far as I know, none of these "problematic" cases are permitted by the above
patches, but it might be worth following the OpenMP issue to make sure that
nothing diverges.
[Bug middle-end/113004] New: OpenMP 5 - structs are not mapped element-wise by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113004 Bug ID: 113004 Summary: OpenMP 5 - structs are not mapped element-wise by default Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: jules at gcc dot gnu.org Target Milestone: --- According to e.g. OpenMP 5.2, "5.8.2 Mapper Identifiers and mapper Modifiers": "A structure type T has a predefined default mapper that is defined as if by a declare mapper directive that specifies v in a map clause with the alloc map-type and each structure element of v in a map clause with the tofrom map-type." At present, a variable of struct type will be mapped as as a single block (the pre-OpenMP 5.0 legacy behaviour). This works fine most of the time, but for example fails in the case where one of the struct's members is a reference, demonstrated in the test case: libgomp/testsuite/libgomp.c++/target-49.C Once "declare mapper" support is committed, cases where a struct with an implicit default mapper should invoke a struct with a *non*-default mapper, will also probably be mishandled.
[Bug libgomp/108624] [OpenMP] Map(ptr, ptr[2:N-2]) will cause a segfault, 'map(ptr, ptr[0:N])'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108624 jules at gcc dot gnu.org changed: What|Removed |Added CC||jules at gcc dot gnu.org --- Comment #1 from jules at gcc dot gnu.org --- This works with the in-review series: https://gcc.gnu.org/pipermail/gcc-patches/2022-December/609031.html i.e. for the mapping: #pragma omp target map(ptr1[1:N-1]) map(ptr2[:N]) we get (gimplify): _1 = ptr1 + 4; map(tofrom:*_1 [len: 252]) map(firstprivate:ptr1 [pointer assign, bias: 4]) and for the mapping: #pragma omp target map(ptr1, ptr1[1:N-1]) map(ptr2[:N]) we get (gimplify): _4 = ptr1.2_3 + 4 map(tofrom:ptr1 [len: 8]) map(tofrom:*_4 [len: 252]) map(attach:ptr1 [bias: 4]) the test runs fine either way.
[Bug target/102856] New: [nvptx] Misaligned accesses with cheap vectorization enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102856 Bug ID: 102856 Summary: [nvptx] Misaligned accesses with cheap vectorization enabled Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jules at gcc dot gnu.org Target Milestone: --- Since revision 2b8453c401b699ed93c085d0413ab4b5030bcdb8 I am seeing several OpenMP tests fail with misaligned access errors: PASS -> FAIL: nvidia-1/libgomp.sum:libgomp.c++/../libgomp.c-c++-common/for-11.c execution test PASS -> FAIL: nvidia-1/libgomp.sum:libgomp.c++/../libgomp.c-c++-common/for-12.c execution test PASS -> FAIL: nvidia-1/libgomp.sum:libgomp.c++/../libgomp.c-c++-common/for-16.c execution test PASS -> FAIL: nvidia-1/libgomp.sum:libgomp.c++/../libgomp.c-c++-common/for-3.c execution test PASS -> FAIL: nvidia-1/libgomp.sum:libgomp.c++/../libgomp.c-c++-common/for-5.c execution test PASS -> FAIL: nvidia-1/libgomp.sum:libgomp.c++/../libgomp.c-c++-common/for-6.c execution test PASS -> FAIL: nvidia-1/libgomp.sum:libgomp.c++/../libgomp.c-c++-common/for-9.c execution test PASS -> FAIL: nvidia-1/libgomp.sum:libgomp.c/../libgomp.c-c++-common/for-11.c execution test PASS -> FAIL: nvidia-1/libgomp.sum:libgomp.c/../libgomp.c-c++-common/for-12.c execution test PASS -> FAIL: nvidia-1/libgomp.sum:libgomp.c/../libgomp.c-c++-common/for-16.c execution test PASS -> FAIL: nvidia-1/libgomp.sum:libgomp.c/../libgomp.c-c++-common/for-3.c execution test PASS -> FAIL: nvidia-1/libgomp.sum:libgomp.c/../libgomp.c-c++-common/for-5.c execution test PASS -> FAIL: nvidia-1/libgomp.sum:libgomp.c/../libgomp.c-c++-common/for-6.c execution test PASS -> FAIL: nvidia-1/libgomp.sum:libgomp.c/../libgomp.c-c++-common/for-9.c execution test These look like, e.g.: $ ./for-11.exe libgomp: cuCtxSynchronize error: misaligned address libgomp: cuMemFree_v2 error: misaligned address libgomp: device finalization failed I suspect the reason is that an operation that is now being vectorized (e.g. "st.v2.u64 [%frame], %r28;") requires higher alignment than the original scalar accesses it replaces. I haven't spotted an obvious culprit for the problem in the nvptx backend. This is OpenMP, so it could be the soft stack handling -- or it could be something else.
