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.

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

[Flang] Segmentation fault in an assignment statement as an array with a subscript in FORALL construct #62981

Closed
ohno-fj opened this issue May 29, 2023 · 4 comments
Assignees
Labels
bug Indicates an unexpected problem or unintended behavior flang:ir

Comments

@ohno-fj
Copy link

ohno-fj commented May 29, 2023

Version of flang-new : 17.0.0(f6c4808d95221a5838e14474d95c6fe85bb1488a)
AArch64

An assignment statement using an array as an array index in the FORALL construct results in a segmentation fault.
Changing the array index from v (i) to i, as shown below, result in successful compilation.

  • Before the change
forall (i = 1: 5)
v (i) = i
b (v (i): v (i)) = mod 01 _ fun1 (a (v (i): v (i)))
end forall
  • After the change
forall (i = 1: 5)
b (i: i) = mod01 _ fun1 (a (i: i))
end forall

The following are the test program, results of Flang-new, GFortran and ifort compilation and execution.

snf95_120_2.f90:

program main
  call test01()
  print *,'pass'
end program main

module mod01
contains
  elemental function mod01_fun1(i) result(ifun)
    intent(in) :: i
    ifun=i
  end function mod01_fun1
end module mod01

subroutine test01()
  use mod01
  integer v(5),a(5),b(5)
  a=reshape((/(i,i=1,5)/),(/5/))
  b=0
  write(6,*) "a = ", a
  forall (i=1:5)
     v(i)=i
     b(v(i):v(i))=mod01_fun1(a(v(i):v(i)))
  end forall
  write(6,*) "b = ", b
  if (any(a.ne.b)) write(6,*) "NG"
end subroutine test01
$ flang-new -flang-experimental-exec snf95_120_2.f90; ./a.out
 a =  1 2 3 4 5
Segmentation fault (core dumped)
$
$ gfortran snf95_120_2.f90; ./a.out
 a =            1           2           3           4           5
 b =            1           2           3           4           5
 pass
$
$ ifort snf95_120_2.f90; ./a.out
 a =            1           2           3           4           5
 b =            1           2           3           4           5
 pass
$
@llvmbot
Copy link
Collaborator

llvmbot commented May 29, 2023

@llvm/issue-subscribers-flang-frontend

@klausler klausler added flang Flang issues not falling into any other category and removed flang:frontend labels May 31, 2023
@psteinfeld psteinfeld added the bug Indicates an unexpected problem or unintended behavior label Jun 2, 2023
@llvmbot
Copy link
Collaborator

llvmbot commented Jun 2, 2023

@llvm/issue-subscribers-bug

@luporl luporl self-assigned this Jun 13, 2023
@luporl
Copy link
Contributor

luporl commented Jun 21, 2023

@EugeneZelenko EugeneZelenko added flang:ir and removed flang Flang issues not falling into any other category labels Jun 21, 2023
@llvmbot
Copy link
Collaborator

llvmbot commented Jun 21, 2023

@llvm/issue-subscribers-flang-ir

@luporl luporl closed this as completed in c881f3e Jun 26, 2023
Chenyang-L pushed a commit to intel/llvm that referenced this issue Jul 11, 2023
Elemental procedures may need their array arguments to be passed by
address. This is done by setting ArrayExprLowering::semant to a
value that corresponds to this semantics. Later, member functions
such as applyPathToArrayLoad() read this variable to generate FIR
instructions that match the needed behavior. The problem is that
the semant variable also affects how array paths are lowered. Thus,
if an index of the path is an array element, this will cause its
address to be used instead of its value, which usually results in a
segmentation fault at runtime.

Example: b(i:i) = elem_func(a(v(i):v(i)))

To fix this, ArrayExprLowering::nextPathSemant was added. When it's
set, the next array path is handled with the semantics specified by
it, while the elemental argument retains its original semantics.

Fixes llvm/llvm-project#62981

Reviewed By: jeanPerier

Differential Revision: https://reviews.llvm.org/D153454
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Indicates an unexpected problem or unintended behavior flang:ir
Development

No branches or pull requests

6 participants