-
Notifications
You must be signed in to change notification settings - Fork 13.5k
[flang] Semantic error on pure subroutine that compiles with gfortran and ifx #139129
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
Labels
Comments
@llvm/issue-subscribers-flang-frontend Author: None (R-Goc)
Hitting this issue when trying to compile fortran-stdlib ([issue there](https://github.com/fortran-lang/stdlib/issues/990)).
Other compilers accept this code. Compiling [stdlib-error.f90](https://github.com/fortran-lang/stdlib/blob/master/src/stdlib_error.fypp):
```
error: Semantic errors in src/CMakeFiles/fortran_stdlib.dir/stdlib_error.f90-pp.f90
/code/rbfx-new/standalone/batched-assembly/stdlib/build/src/stdlib_error.f90:245:14: error: Left-hand side of assignment is not definable
ierr_out = ierr
^^^^^^^^
/code/rbfx-new/standalone/batched-assembly/stdlib/build/src/stdlib_error.f90:245:14: because: 'ierr_out' is polymorphic in a pure subprogram
ierr_out = ierr
^^^^^^^^
/code/rbfx-new/standalone/batched-assembly/stdlib/build/src/stdlib_error.f90:239:56: Declaration of 'ierr_out'
class(state_type), optional, intent(inout) :: ierr_out
^^^^^^^^
```
This is the [function](https://github.com/fortran-lang/stdlib/blob/c14d599a7b9dabf8789be6ecc484339599f595c8/src/stdlib_error.fypp#L239):
```fortran
pure subroutine error_handling(ierr,ierr_out)
class(state_type), intent(in) :: ierr
class(state_type), optional, intent(inout) :: ierr_out
state_type is also extended by two methods: interface state_type
module procedure new_state
module procedure new_state_nowhere
end interface state_type which are defined here: pure type(state_type) function new_state(where_at,flag,a1,a2,a3,a4,a5,a6,a7,a8,a9,a10, &
a11,a12,a13,a14,a15,a16,a17,a18,a19,a20)
!> Location
character(len=*),intent(in) :: where_at
!> Input error flag
integer,intent(in) :: flag
!> Optional rank-agnostic arguments
class(*),optional,intent(in),dimension(..) :: a1,a2,a3,a4,a5,a6,a7,a8,a9,a10, &
a11,a12,a13,a14,a15,a16,a17,a18,a19,a20
! Init object
call new_state%parse(where_at,flag,a1,a2,a3,a4,a5,a6,a7,a8,a9,a10, &
a11,a12,a13,a14,a15,a16,a17,a18,a19,a20)
end function new_state
!> Error creation message, from N input variables (numeric or strings)
pure type(state_type) function new_state_nowhere(flag,a1,a2,a3,a4,a5,a6,a7,a8,a9,a10, &
a11,a12,a13,a14,a15,a16,a17,a18,a19,a20) &
result(new_state)
!> Input error flag
integer,intent(in) :: flag
!> Optional rank-agnostic arguments
class(*),optional,intent(in),dimension(..) :: a1,a2,a3,a4,a5,a6,a7,a8,a9,a10, &
a11,a12,a13,a14,a15,a16,a17,a18,a19,a20
! Init object
call new_state%parse(flag,a1,a2,a3,a4,a5,a6,a7,a8,a9,a10, &
a11,a12,a13,a14,a15,a16,a17,a18,a19,a20)
end function new_state_nowhere To reproduce compile stdlib using flang (disabling XDP and QDP might be needed cmake variables WITH_*DP) |
A more manageable test case:
|
klausler
added a commit
to klausler/llvm-project
that referenced
this issue
May 9, 2025
An assignment to a whole polymorphic object in a PURE subprogram that is implemented by means of a defined assignment procedure shouldn't be subjected to the same definability checks as it would be for an intrinsic assignment (which would also require it to be allocatable). Fixes llvm#139129.
klausler
added a commit
to klausler/llvm-project
that referenced
this issue
May 9, 2025
An assignment to a whole polymorphic object in a PURE subprogram that is implemented by means of a defined assignment procedure shouldn't be subjected to the same definability checks as it would be for an intrinsic assignment (which would also require it to be allocatable). Fixes llvm#139129.
klausler
added a commit
to klausler/llvm-project
that referenced
this issue
May 12, 2025
An assignment to a whole polymorphic object in a PURE subprogram that is implemented by means of a defined assignment procedure shouldn't be subjected to the same definability checks as it would be for an intrinsic assignment (which would also require it to be allocatable). Fixes llvm#139129.
klausler
added a commit
to klausler/llvm-project
that referenced
this issue
May 12, 2025
An assignment to a whole polymorphic object in a PURE subprogram that is implemented by means of a defined assignment procedure shouldn't be subjected to the same definability checks as it would be for an intrinsic assignment (which would also require it to be allocatable). Fixes llvm#139129.
klausler
added a commit
that referenced
this issue
May 13, 2025
An assignment to a whole polymorphic object in a PURE subprogram that is implemented by means of a defined assignment procedure shouldn't be subjected to the same definability checks as it would be for an intrinsic assignment (which would also require it to be allocatable). Fixes #139129.
llvm-sync bot
pushed a commit
to arm/arm-toolchain
that referenced
this issue
May 13, 2025
…#139186) An assignment to a whole polymorphic object in a PURE subprogram that is implemented by means of a defined assignment procedure shouldn't be subjected to the same definability checks as it would be for an intrinsic assignment (which would also require it to be allocatable). Fixes llvm/llvm-project#139129.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hitting this issue when trying to compile fortran-stdlib (issue there).
Other compilers accept this code. Compiling stdlib-error.f90:
This is the function:
state_type:
state_type is also extended by two methods:
which are defined here:
To reproduce compile stdlib using flang (disabling XDP and QDP might be needed cmake variables WITH_*DP)
The text was updated successfully, but these errors were encountered: