llvm / llvm/llvm-project

[Flang] Spurious behavior for finalization when intrinsic assignments are executed for arrays with vector subscripts

Open
#209,939 0 comments 0 reactions 0 assignees View on GitHub
flang
Dominant language
LLVM
Stars
40.5k
Forks
18.7k
PR merge metrics
PR metrics pending

Description

## Summary

When intrinsic assignments are performed on arrays using vector subscripts, finalization does not occur. In addition, despite Flang's warning that arrays will be finalized by a non-elemental subroutine, this finalization does not actually happen.

* 7.5.6.3 When finalization occurs

> When an intrinsic assignment statement is executed (10.2.1.3), if the variable is not an unallocated allocatable variable, it is finalized after evaluation of expr and before the definition of the variable.

* 7.5.6.2 The finalization process

> Only finalizable entities are finalized. When an entity is finalized, the following steps are carried out in sequence.
> 1. If the dynamic type of the entity has a final subroutine whose dummy argument has the same kind type parameters and rank as the entity being finalized, it is called with the entity as an actual argument. Otherwise, if there is an elemental final subroutine whose dummy argument has the same kind type parameters as the entity being finalized, or a final subroutine whose dummy argument is assumed-rank with the same kind type parameters as the entity being finalized, it is called with the entity as an actual argument. Otherwise, no subroutine is called at this point.

### Reproducer

* test.f90

```fortran
MODULE mod
TYPE ty
INTEGER :: ii=100
CONTAINS
FINAL::final_routine
END TYPE

CONTAINS
SUBROUTINE final_routine(d)
TYPE(ty),INTENT(INOUT)::d(:)
PRINT*,'Final called'
PRINT*,d
END SUBROUTINE
END MODULE

PROGRAM MAIN
USE mod
TYPE(ty):: L(2)=[ty(1),ty(2)]
TYPE(ty):: R(2)=[ty(3),ty(4)]
INTEGER::v(2)=[1,2]
L(v)=R
END
```

* test2.f90

```fortran
MODULE mod
TYPE ty
INTEGER :: ii=100
CONTAINS
FINAL::final_routine
FINAL::elemental_final_routine
END TYPE

CONTAINS
SUBROUTINE final_routine(d)
TYPE(ty),INTENT(INOUT)::d(:)
PRINT*,'Final called'
PRINT*,d
END SUBROUTINE
IMPURE ELEMENTAL SUBROUTINE elemental_final_routine(d)
TYPE(ty),INTENT(INOUT)::d
PRINT*,'Final Elemental called'
PRINT*,d
END SUBROUTINE
END MODULE

PROGRAM MAIN
USE mod
TYPE(ty):: L(2)=[ty(1),ty(2)]
TYPE(ty):: R(2)=[ty(3),ty(4)]
INTEGER::v(2)=[1,2]
L(v)=R
END
```

* commands

```console
$ flang --version
flang version 23.0.0git (https://github.com/llvm/llvm-project.git 349542f7e122b8fda1d60f0b37c8f92ad65635d6)
Target: aarch64-unknown-linux-gnu
Thread model: posix
InstalledDir: /path/to/llvm/build/bin
Build config: +assertions
$ flang test.f90 && ./a.out
test.f90:21:3: portability: Variable 'l(__builtin_int(v,kind=8))' has a vector subscript and will be finalized by non-elemental subroutine 'final_routine' [-Wvector-subscript-finalization]
L(v)=R
^^^^
$ flang test2.f90 && ./a.out
Final Elemental called
1
Final Elemental called
2
```

According to the Fortran 2023 standard, non-elemental final subroutines should take precedence over elemental final subroutines. Considering these results, I suspect the portability warning is invalid or excessive. (Specifically, the warning might be generated when it's not applicable, or it might be omitted when it should be present.)

## Other Compilers

* GFortran
```console
$ gfortran --version
GNU Fortran (GCC) 15.2.0
Copyright (C) 2025 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gfortran test.f90 && ./a.out
Final called
1 2
$ gfortran test2.f90 && ./a.out
Final called
1 2
```

* Intel Fortran
```console
$ ifx --version
ifx (IFX) 2025.3.2 20260112
Copyright (C) 1985-2026 Intel Corporation. All rights reserved.

$ ifx -O0 test.f90 && ./a.out
#0 0x0000558dbdf59f87 f90_abort1 me_globals.c:0
#1 0x0000558dbdf44e5a (/path/to/intel/oneapi/compiler/2025.3/bin/compiler/xfortcom+0x39a6e5a)
#2 0x0000558dbdee0856 me_fill_dim_info (/path/to/intel/oneapi/compiler/2025.3/bin/compiler/xfortcom+0x3942856)
#3 0x0000558dbe00d782 fill_xdesc_qnca_from_non_qnca me_xdesc.c:0
#4 0x0000558dbe00cf0b me_make_and_fill_class_xdesc (/path/to/intel/oneapi/compiler/2025.3/bin/compiler/xfortcom+0x3a6ef0b)
#5 0x0000558dbdf38371 me_finalize_expr (/path/to/intel/oneapi/compiler/2025.3/bin/compiler/xfortcom+0x399a371)
#6 0x0000558dbde3db5d me_array_store (/path/to/intel/oneapi/compiler/2025.3/bin/compiler/xfortcom+0x389fb5d)
#7 0x0000558dbdf9e95e me_emit_store_stmt (/path/to/intel/oneapi/compiler/2025.3/bin/compiler/xfortcom+0x3a0095e)
#8 0x0000558dbdfa8e91 me_stmt (/path/to/intel/oneapi/compiler/2025.3/bin/compiler/xfortcom+0x3a0ae91)
#9 0x0000558dbdfa93c7 me_stmts (/path/to/intel/oneapi/compiler/2025.3/bin/compiler/xfortcom+0x3a0b3c7)
#10 0x0000558dbdfabfe7 emit_generic_prunit me_stmt.c:0
#11 0x0000558dbdfa8e91 me_stmt (/path/to/intel/oneapi/compiler/2025.3/bin/compiler/xfortcom+0x3a0ae91)
#12 0x0000558dbdfa626e emit_fortrn_stmt me_stmt.c:0
#13 0x0000558dbdfa8e91 me_stmt (/path/to/intel/oneapi/compiler/2025.3/bin/compiler/xfortcom+0x3a0ae91)
#14 0x0000558dbde34eed me_comp_prunit (/path/to/intel/oneapi/compiler/2025.3/bin/compiler/xfortcom+0x3896eed)
#15 0x0000558dbde3489f gem_xx_compile (/path/to/intel/oneapi/compiler/2025.3/bin/compiler/xfortcom+0x389689f)
#16 0x0000558dbe01b3cf main (/path/to/intel/oneapi/compiler/2025.3/bin/compiler/xfortcom+0x3a7d3cf)
#17 0x00007f4ba3fc51ca (/usr/lib/x86_64-linux-gnu/libc.so.6+0x2a1ca)
#18 0x00007f4ba3fc528b __libc_start_main (/usr/lib/x86_64-linux-gnu/libc.so.6+0x2a28b)
#19 0x0000558dbdc6c23e _start start.S:122

test.f90(21): error #5623: **Internal compiler error: internal abort** Please report this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of this error.
L(v)=R
--^
compilation aborted for test.f90 (code 3)
$ ifx -O0 test2.f90 && ./a.out
#0 0x0000562e6a0b9f87 f90_abort1 me_globals.c:0
#1 0x0000562e6a0a4e5a (/path/to/intel/oneapi/compiler/2025.3/bin/compiler/xfortcom+0x39a6e5a)
#2 0x0000562e6a040856 me_fill_dim_info (/path/to/intel/oneapi/compiler/2025.3/bin/compiler/xfortcom+0x3942856)
#3 0x0000562e6a16d782 fill_xdesc_qnca_from_non_qnca me_xdesc.c:0
#4 0x0000562e6a16cf0b me_make_and_fill_class_xdesc (/path/to/intel/oneapi/compiler/2025.3/bin/compiler/xfortcom+0x3a6ef0b)
#5 0x0000562e6a098371 me_finalize_expr (/path/to/intel/oneapi/compiler/2025.3/bin/compiler/xfortcom+0x399a371)
#6 0x0000562e69f9db5d me_array_store (/path/to/intel/oneapi/compiler/2025.3/bin/compiler/xfortcom+0x389fb5d)
#7 0x0000562e6a0fe95e me_emit_store_stmt (/path/to/intel/oneapi/compiler/2025.3/bin/compiler/xfortcom+0x3a0095e)
#8 0x0000562e6a108e91 me_stmt (/path/to/intel/oneapi/compiler/2025.3/bin/compiler/xfortcom+0x3a0ae91)
#9 0x0000562e6a1093c7 me_stmts (/path/to/intel/oneapi/compiler/2025.3/bin/compiler/xfortcom+0x3a0b3c7)
#10 0x0000562e6a10bfe7 emit_generic_prunit me_stmt.c:0
#11 0x0000562e6a108e91 me_stmt (/path/to/intel/oneapi/compiler/2025.3/bin/compiler/xfortcom+0x3a0ae91)
#12 0x0000562e6a10626e emit_fortrn_stmt me_stmt.c:0
#13 0x0000562e6a108e91 me_stmt (/path/to/intel/oneapi/compiler/2025.3/bin/compiler/xfortcom+0x3a0ae91)
#14 0x0000562e69f94eed me_comp_prunit (/path/to/intel/oneapi/compiler/2025.3/bin/compiler/xfortcom+0x3896eed)
#15 0x0000562e69f9489f gem_xx_compile (/path/to/intel/oneapi/compiler/2025.3/bin/compiler/xfortcom+0x389689f)
#16 0x0000562e6a17b3cf main (/path/to/intel/oneapi/compiler/2025.3/bin/compiler/xfortcom+0x3a7d3cf)
#17 0x00007f31a98e91ca (/usr/lib/x86_64-linux-gnu/libc.so.6+0x2a1ca)
#18 0x00007f31a98e928b __libc_start_main (/usr/lib/x86_64-linux-gnu/libc.so.6+0x2a28b)
#19 0x0000562e69dcc23e _start start.S:122

test2.f90(27): error #5623: **Internal compiler error: internal abort** Please report this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of this error.
L(v)=R
--^
compilation aborted for test2.f90 (code 3)
```

Contributor guide

Open the contributing guide

Research direction

Start by compiling and running the supplied test.f90 and test2.f90 reproductions with Flang, then compare the observed finalization and warning behavior with the cited Fortran 2023 rules. Done means vector-subscript intrinsic assignments perform the required finalization, issue appropriate diagnostics, and no longer trigger the reported compiler failure.

Written by the indexing model from the issue text.

Assessment

Tech stack
fortran
Domain
compilers
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.