[Bug ipa/92809] [10 regression] error: calls_comdat_local is set outside of a comdat group
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92809 Frederik Harwath changed: What|Removed |Added CC||frederik at gcc dot gnu.org --- Comment #2 from Frederik Harwath --- We see the same error with the same backtrace when compiling g++.dg/torture/pr59226.C for amdgcn.
[Bug fortran/92793] Fortran Location Data for Diagnostic lacks the column number – when passing on to ME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92793 --- Comment #4 from Frederik Harwath --- Author: frederik Date: Tue Dec 10 16:12:58 2019 New Revision: 279169 URL: https://gcc.gnu.org/viewcvs?rev=279169&root=gcc&view=rev Log: Add tests to verify OpenACC clause locations Check that the column information for OpenACC clauses is communicated correctly to the middle-end, in particular by the Fortran front-end (cf. PR 92793). 2019-12-10 Frederik Harwath gcc/testsuite/ * c-c++-common/goacc/clause-locations.c: New test. * gfortran.dg/goacc/clause-locations.f90: New test. Added: trunk/gcc/testsuite/c-c++-common/goacc/clause-locations.c trunk/gcc/testsuite/gfortran.dg/goacc/clause-locations.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug other/92901] new test case c-c++-common/goacc/clause-locations.c in r279169 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92901 --- Comment #1 from Frederik Harwath --- Author: frederik Date: Wed Dec 11 08:26:18 2019 New Revision: 279215 URL: https://gcc.gnu.org/viewcvs?rev=279215&root=gcc&view=rev Log: Fix PR92901: Change test expectation for C++ in OpenACC test clause-locations.c The columns of the clause locations that are reported for C and C++ are different and hence we need separate test expectations for both languages. 2019-12-11 Frederik Harwath PR other/92901 /gcc/testsuite/ * c-c++-common/clause-locations.c: Adjust test expectation for C++. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/goacc/clause-locations.c
[Bug other/92901] new test case c-c++-common/goacc/clause-locations.c in r279169 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92901 --- Comment #2 from Frederik Harwath --- Created attachment 47469 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47469&action=edit Committed fix
[Bug other/92901] new test case c-c++-common/goacc/clause-locations.c in r279169 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92901 Frederik Harwath changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Frederik Harwath --- See attached patch.
[Bug libgomp/93481] Do not fail with nowait clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93481 Frederik Harwath changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Frederik Harwath --- Fixed for GCC 10. See https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=001ab12e620c6f117b2e93c77d188bd62fe7ba03 author Frederik Harwath Thu, 13 Feb 2020 06:30:16 + (07:30 +0100) commit 001ab12e620c6f117b2e93c77d188bd62fe7ba03 openmp: ignore nowait if async execution is unsupported [PR93481] An OpenMP "nowait" clause on a target construct currently leads to a call to GOMP_OFFLOAD_async_run in the plugin that is used for offloading at execution time. The nvptx plugin contains only a stub of this function that always produces a fatal error if called. This commit changes the "nowait" implementation to ignore the clause if the executing device's plugin does not implement GOMP_OFFLOAD_async_run. The stub in the nvptx plugin is removed which effectively means that programs containing "nowait" can now be executed with nvptx offloading as if the clause had not been used. This behavior is consistent with the OpenMP specification which says that "[...] execution of the target task *may* be deferred" (emphasis added), cf. OpenMP 5.0, page 172. libgomp/ * plugin/plugin-nvptx.c: Remove GOMP_OFFLOAD_async_run stub. * target.c (gomp_load_plugin_for_device): Make "async_run" loading optional. (gomp_target_task_fn): Assert "devicep->async_run_func". (clear_unsupported_flags): New function to remove unsupported flags (right now only GOMP_TARGET_FLAG_NOWAIT) that can be be ignored. (GOMP_target_ext): Apply clear_unsupported_flags to flags. * testsuite/libgomp.c/target-33.c: Remove xfail for offload_target_nvptx. * testsuite/libgomp.c/target-34.c: Likewise.
[Bug middle-end/109552] New: ICE with "cancel" directive in "taskloop" construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109552 Bug ID: 109552 Summary: ICE with "cancel" directive in "taskloop" construct Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: frederik at gcc dot gnu.org Target Milestone: --- Created attachment 54882 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54882&action=edit C version of the test The following Fortran code produces an ICE in the middle-end when I compile it as a libgomp test (i.e. with -fopenmp; same error at different optimization levels): program test integer :: a integer :: i !$omp parallel !$omp taskloop do i = 1,10 !$omp cancel taskgroup if (a .eq. 1) call abort () end do !$omp end taskloop !$omp end parallel end program Error: FAIL: libgomp.fortran/cancel-taskloop.f90 -O (test for excess errors) Excess errors: during GIMPLE pass: ompexp ../../../../libgomp/testsuite/libgomp.fortran/cancel-taskloop.f90:6:16: internal compiler error: in verify_sese, at tree-cfg.cc:7654 0x7c0878 verify_sese(basic_block_def*, basic_block_def*, vec*) ../../gcc/tree-cfg.cc:7654 0x14d4958 move_sese_region_to_fn(function*, basic_block_def*, basic_block_def*, tree_node*) ../../gcc/tree-cfg.cc:7770 0x2606968 expand_omp_taskreg ../../gcc/omp-expand.cc:1444 0x260ca3f expand_omp_synch ../../gcc/omp-expand.cc:8659 0x260ca3f expand_omp ../../gcc/omp-expand.cc:10616 0x260c77c expand_omp ../../gcc/omp-expand.cc:10565 0x260c77c expand_omp ../../gcc/omp-expand.cc:10565 0x260e9fa execute_expand_omp ../../gcc/omp-expand.cc:10819 A canonical conversion of the test to C/C++ leads to the same error from gcc/g++. I am not sure if the code is valid according to the OpenMP spec, but the ICE is certainly wrong. The GCC build has been configured with "--enable-languages=fortran,c,c++ --enable-checking=all --disable-multilib --disable-bootstrap" and the version is "gcc version 14.0.0 20230419 (experimental) (GCC)".
[Bug libgomp/109620] New: [OpenMP][Offloading] OMP_CANCELLATION ICV not mapped to device
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109620
Bug ID: 109620
Summary: [OpenMP][Offloading] OMP_CANCELLATION ICV not mapped
to device
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: frederik at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
The value of the OMP_CANCELLATION ICV does not get copied to offloading
devices.
I have tested it by running the following test code both with nvptx and amgdcn
offloading as a part of the libgomp testsuite:
/* { dg-set-target-env-var OMP_CANCELLATION "true" } */
#include
int
main ()
{
__builtin_printf("OMP_CANCELLATION on host: %d\n",
omp_get_cancellation ());
#pragma omp target
{
__builtin_printf("OMP_CANCELLATION on device: %d\n",
omp_get_cancellation ());
}
return 0;
}
In both cases, the output was:
OMP_CANCELLATION on host: 1
OMP_CANCELLATION on device: 0
Does libgomp copy global ICVs to the device environment at all?
I did not find any tests that use cancellation in "target" regions. I think
there is no way for a user to enable it if the ICV is not forwarded.
But would it be supported in principle?
