[Bug libgomp/109620] New: [OpenMP][Offloading] OMP_CANCELLATION ICV not mapped to device

2023-04-25 Thread frederik at gcc dot gnu.org via Gcc-bugs
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?

[Bug middle-end/109552] New: ICE with "cancel" directive in "taskloop" construct

2023-04-19 Thread frederik at gcc dot gnu.org via Gcc-bugs
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=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)".