Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[flang][openmp] Bad code for "private" directive with pointers and targets #102939

Open
psteinfeld opened this issue Aug 12, 2024 · 2 comments
Open

[flang][openmp] Bad code for "private" directive with pointers and targets #102939

psteinfeld opened this issue Aug 12, 2024 · 2 comments
Assignees
@ergawy
Labels
bug Indicates an unexpected problem or unintended behavior flang:openmp

Comments

@psteinfeld
Copy link
Contributor

Here's a test program:

program bug
  integer, pointer :: pvar
  integer, target :: tvar
  tvar = 2
  pvar => tvar
  !$omp parallel private (pvar, tvar)
  tvar = 1
  pvar => tvar
  !$omp end parallel
  if (pvar/=2) stop 'fail'
  print *, 'ok'
end program

I compile this program with flang-new -fopenmp bug.f90. When I execute it, I get the output:

Fortran STOP: fail
IEEE arithmetic exceptions signaled: INEXACT

When I compile and execute the same program with gfortran -fopenmp bug.f90, I get the output:

ok
@psteinfeld psteinfeld added bug Indicates an unexpected problem or unintended behavior flang:openmp labels Aug 12, 2024
@llvmbot
Copy link
Collaborator

llvmbot commented Aug 12, 2024

@llvm/issue-subscribers-bug

Author: Pete Steinfeld (psteinfeld)

Here's a test program: ``` program bug integer, pointer :: pvar integer, target :: tvar tvar = 2 pvar => tvar !$omp parallel private (pvar, tvar) tvar = 1 pvar => tvar !$omp end parallel if (pvar/=2) stop 'fail' print *, 'ok' end program ``` I compile this program with `flang-new -fopenmp bug.f90`. When I execute it, I get the output: ``` Fortran STOP: fail IEEE arithmetic exceptions signaled: INEXACT ``` When I compile and execute the same program with `gfortran -fopenmp bug.f90`, I get the output: ``` ok ```

@ergawy ergawy self-assigned this Aug 14, 2024
ergawy added a commit to ergawy/llvm-project that referenced this issue Aug 15, 2024
@ergawy
[MLIR][OpenMP] Handle privatization for global values in MLIR->LLVM t…
840faaa 
…ranslation

Fix for llvm#102939.

The issues occurs because the CodeExtractor component only collect inputs
(to the parallel regions) that are defined in the same function in which the
parallel regions is present. Howerver, this is problematic because if we are
privatizing a global value (e.g. a `target` variable which is emitted as a
global), then we miss finding that input and we do not privatize the
variable.

This commit attempts to fix the issue by adding a flag to the
CodeExtractor so that we can collect global inputs.
@ergawy ergawy mentioned this issue Aug 15, 2024
Merged
ergawy added a commit to ergawy/llvm-project that referenced this issue Aug 16, 2024
@ergawy
[MLIR][OpenMP] Handle privatization for global values in MLIR->LLVM t…
5d93023 
…ranslation

Fix for llvm#102939.

The issues occurs because the CodeExtractor component only collect inputs
(to the parallel regions) that are defined in the same function in which the
parallel regions is present. Howerver, this is problematic because if we are
privatizing a global value (e.g. a `target` variable which is emitted as a
global), then we miss finding that input and we do not privatize the
variable.

This commit attempts to fix the issue by adding a flag to the
CodeExtractor so that we can collect global inputs.
ergawy added a commit to ergawy/llvm-project that referenced this issue Aug 18, 2024
@ergawy
[MLIR][OpenMP] Handle privatization for global values in MLIR->LLVM t…
0dd676f 
…ranslation

Fix for llvm#102939.

The issues occurs because the CodeExtractor component only collect inputs
(to the parallel regions) that are defined in the same function in which the
parallel regions is present. Howerver, this is problematic because if we are
privatizing a global value (e.g. a `target` variable which is emitted as a
global), then we miss finding that input and we do not privatize the
variable.

This commit attempts to fix the issue by adding a flag to the
CodeExtractor so that we can collect global inputs.
ergawy added a commit to ergawy/llvm-project that referenced this issue Aug 22, 2024
@ergawy
[MLIR][OpenMP] Handle privatization for global values in MLIR->LLVM t…
2ce7998 
…ranslation

Fix for llvm#102939.

The issues occurs because the CodeExtractor component only collect inputs
(to the parallel regions) that are defined in the same function in which the
parallel regions is present. Howerver, this is problematic because if we are
privatizing a global value (e.g. a `target` variable which is emitted as a
global), then we miss finding that input and we do not privatize the
variable.

This commit attempts to fix the issue by adding a flag to the
CodeExtractor so that we can collect global inputs.
ergawy added a commit to ergawy/llvm-project that referenced this issue Aug 22, 2024
@ergawy
[MLIR][OpenMP] Handle privatization for global values in MLIR->LLVM t…
16f2d26 
…ranslation

Fix for llvm#102939.

The issues occurs because the CodeExtractor component only collect inputs
(to the parallel regions) that are defined in the same function in which the
parallel regions is present. Howerver, this is problematic because if we are
privatizing a global value (e.g. a `target` variable which is emitted as a
global), then we miss finding that input and we do not privatize the
variable.

This commit attempts to fix the issue by adding a flag to the
CodeExtractor so that we can collect global inputs.
ergawy added a commit to ergawy/llvm-project that referenced this issue Aug 26, 2024
@ergawy
[MLIR][OpenMP] Handle privatization for global values in MLIR->LLVM t…
66c94ea 
…ranslation

Fix for llvm#102939.

The issues occurs because the CodeExtractor component only collect inputs
(to the parallel regions) that are defined in the same function in which the
parallel regions is present. Howerver, this is problematic because if we are
privatizing a global value (e.g. a `target` variable which is emitted as a
global), then we miss finding that input and we do not privatize the
variable.

This commit attempts to fix the issue by adding a flag to the
CodeExtractor so that we can collect global inputs.
ergawy added a commit that referenced this issue Aug 26, 2024
@ergawy
[MLIR][OpenMP] Handle privatization for global values in MLIR->LLVM t…
a195e2d 
…ranslation (#104407)

Potential fix for #102939 and
#102949.

The issues occurs because the CodeExtractor component only collect
inputs (to the parallel regions) that are defined in the same function
in which the parallel regions is present. Howerver, this is problematic
because if we are privatizing a global value (e.g. a `target` variable
which is emitted as a global), then we miss finding that input and we do
not privatize the variable.

This commit attempts to fix the issue by adding a flag to the
CodeExtractor so that we can collect global inputs.
5c4lar pushed a commit to 5c4lar/llvm-project that referenced this issue Aug 29, 2024
@ergawy @5c4lar
[MLIR][OpenMP] Handle privatization for global values in MLIR->LLVM t…
5c183db 
…ranslation (llvm#104407)

Potential fix for llvm#102939 and
llvm#102949.

The issues occurs because the CodeExtractor component only collect
inputs (to the parallel regions) that are defined in the same function
in which the parallel regions is present. Howerver, this is problematic
because if we are privatizing a global value (e.g. a `target` variable
which is emitted as a global), then we miss finding that input and we do
not privatize the variable.

This commit attempts to fix the issue by adding a flag to the
CodeExtractor so that we can collect global inputs.
dmpolukhin pushed a commit to dmpolukhin/llvm-project that referenced this issue Sep 2, 2024
@ergawy @dmpolukhin
[MLIR][OpenMP] Handle privatization for global values in MLIR->LLVM t…
c525950 
…ranslation (llvm#104407)

Potential fix for llvm#102939 and
llvm#102949.

The issues occurs because the CodeExtractor component only collect
inputs (to the parallel regions) that are defined in the same function
in which the parallel regions is present. Howerver, this is problematic
because if we are privatizing a global value (e.g. a `target` variable
which is emitted as a global), then we miss finding that input and we do
not privatize the variable.

This commit attempts to fix the issue by adding a flag to the
CodeExtractor so that we can collect global inputs.
@tblah
Copy link
Contributor

tblah commented Sep 18, 2024

See https://discourse.llvm.org/t/rfc-openmp-fix-issue-in-mlir-to-llvmir-translation-for-delayed-privatisation/81225

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@ergawy ergawy

Labels
bug Indicates an unexpected problem or unintended behavior flang:openmp
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@ergawy @tblah @psteinfeld @llvmbot