[Fortran/UnitTests] add 10 type finalization unit tests

[zbeekman]

Summary

This suite of tests was created originally by Wileam Phan, Damian Rouson,
and Brad Richardson as part of the Smart-Pointers library's test suite.

The original adaptation for inclusion in the llvm-test-suite can be found here:

• https://github.com/BerkeleyLab/llvm-test-suite/tree/damians-fortran-type-finalization SHA: 0268bcf0048e67cd1280f9ef65aebd2aa402130b
• https://github.com/BerkeleyLab/llvm-test-suite/tree/berkely-lab-damian-v0.1 SHA: 0268bcf0048e67cd1280f9ef65aebd2aa402130b

The test suite was then adapted to be made appropriate for inclusion
in a compiler test suite by Izaak Beekman.

A summary of the tests can be found in the README.md file added in the
Fortran/UnitTests/finalization subdirectory.

Co-Authored-by: Damian Rouson <[e-mail]>

[clementval]

Fortran/UnitTests/finalization/README.md

156–165

Is this the actual status for flang? I'm confused because on the PR you mentioned all tests were passing.

[zbeekman]

Shoot, yes I need to update this.

[zbeekman]

I have now updated the README.md file to reflect LLVM-flan's current status: All tests are passing.

[clementval]

LGTM but I was not really involved with the Fortran test suite integration so it would be good to have a reviewer to accept it before landing.

Is there any plan to increase the coverage of the finalization tests? I remember that couple of cases are not tested currently like finalization of polymorphic entities or finalization on automatic deallocation.

[zbeekman]

In D147804#4266457, @clementval wrote:

LGTM but I was not really involved with the Fortran test suite integration so it would be good to have a reviewer to accept it before landing.

Great! I looked at git blame to try to suggest who might make a good reviewer, only one name came up though. I added them when initially submitting the patch to phabricator, but I'm not sure how to go about getting another reviewer to take a look. I can try asking on the flang slack tomorrow if that would help.

Is there any plan to increase the coverage of the finalization tests? I remember that couple of cases are not tested currently like finalization of polymorphic entities or finalization on automatic deallocation.

Within the scope of the present work there is not currently a plan to add additional finalization tests, as far as I know. I will touch base with Damian Rouson and report back, however I think we should assume that this work is complete (pending any further reviewer feedback) and table the addition of further finalization tests for the future.

[clementval]

In D147804#4266500, @zbeekman wrote:

Within the scope of the present work there is not currently a plan to add additional finalization tests, as far as I know. I will touch base with Damian Rouson and report back, however I think we should assume that this work is complete (pending any further reviewer feedback) and table the addition of further finalization tests for the future.

Any additional tests can be added later. No need to change this patch.

[kiranchandramohan]

Tested on AArch64 and everything passes with llvm-flang. I have a couple of comments regarding other compilers.

Fortran/UnitTests/finalization/README.md

15

Could you add the Arm Compiler as well? It is available from https://developer.arm.com/downloads/-/arm-compiler-for-linux.

I see the following passes:
PASS: test-suite :: Fortran/UnitTests/finalization/finalize_on_deallocate.test (5 of 192)
PASS: test-suite :: Fortran/UnitTests/finalization/rhs_function_reference.test (72 of 192)
PASS: test-suite :: Fortran/UnitTests/finalization/lhs_object.test (114 of 192)
PASS: test-suite :: Fortran/UnitTests/finalization/allocatable_component.test (115 of 192)
PASS: test-suite :: Fortran/UnitTests/finalization/target_deallocation.test (137 of 192)
PASS: test-suite :: Fortran/UnitTests/finalization/block_end.test (182 of 192)
PASS: test-suite :: Fortran/UnitTests/finalization/finalize_on_end.test (184 of 192)

and the following failures:

test-suite :: Fortran/UnitTests/finalization/allocated_allocatable_lhs.test
test-suite :: Fortran/UnitTests/finalization/intent_out.test
test-suite :: Fortran/UnitTests/finalization/specification_expression_finalization.test

I guess one of the failures is due to the error message mismatch (i.e Fortran ERROR STOP vs ERROR STOP).

145–148

The AMD compiler uses the Classic Flang frontend (https://github.com/flang-compiler/flang) that the Arm compiler uses. Hence I am surprised that everything fails here.

Fortran/UnitTests/finalization/specification_expression_finalization.reference_output

1 ↗

(On Diff #513361)

Isn't the Fortran prefix specific to llvm/flang ? This would cause other compilers to mismatch this output. Is it possible to remove the Fortran prefix ?

[kiranchandramohan]

Having the same module name object_type_m compiling in the same directory from different files is problematic, since the module file contents can be overwritten. Is it possible to either rename the modules in different files or have a common module compiling only once?

[zbeekman]

In D147804#4273721, @kiranchandramohan wrote:

Having the same module name object_type_m compiling in the same directory from different files is problematic, since the module file contents can be overwritten. Is it possible to either rename the modules in different files or have a common module compiling only once?

Ah, yes, I temporarily forgot about this CMake idiosyncrasy: There is a race condition when compiling/producing the same module .mod file in parallel. To keep things simple is it OK if I continue to use the same approach (with include "object_type_m.f90") to inject common code at the top of each source file, but then give the module a unique name by declaring the module with module <test_name_m> so each test has a unique module? Or I could just eliminate the common code that gets included and retype it as a unique module in the source file for each test. What is your preference?

[zbeekman]

@clementval and @kiranchandramohan What do you think of my proposed approach outlined in the inlined comments and the comment I just added above responding to @kiranchandramohan?

I don't have access to all the compilers listed in the README and the support info per-compiler will get stale as new versions are released. Is it even worth including this information in the README? Maybe I should just get rid of the README. What do you think?

Thanks,
Zaak

Fortran/UnitTests/finalization/README.md

15

I will add this to the README.

145–148

Yeah, these are also out of date. I don't have access to the compiler at the moment to update it. If you want to run the tests I would be happy to report your findings in the README.

Fortran/UnitTests/finalization/object_type_m.f90

2

I will give this module a unique name based on the test name. Is it OK if I continue to keep common code in a file that gets included? Or should I inline the entire module with a unique name in each test, copying the common code by hand?

Fortran/UnitTests/finalization/specification_expression_finalization.reference_output

1 ↗

(On Diff #513361)

The only obvious way I can think of to accomplish this is to use CMake to configure the specification_expression_finalization.reference_output file based on the detected CMAKE_Fortran_COMPILER_ID. Would this be an acceptable approach?

[clementval]

In D147804#4284073, @zbeekman wrote:

@clementval and @kiranchandramohan What do you think of my proposed approach outlined in the inlined comments and the comment I just added above responding to @kiranchandramohan?

I don't have access to all the compilers listed in the README and the support info per-compiler will get stale as new versions are released. Is it even worth including this information in the README? Maybe I should just get rid of the README. What do you think?

Thanks,
Zaak

The README is not necessary for me. At least the different results. It would make sense if it was updated regularly but we know that it will fall behind quickly.

[kiranchandramohan]

In D147804#4284440, @clementval wrote:

In D147804#4284073, @zbeekman wrote:

@clementval and @kiranchandramohan What do you think of my proposed approach outlined in the inlined comments and the comment I just added above responding to @kiranchandramohan?

I don't have access to all the compilers listed in the README and the support info per-compiler will get stale as new versions are released. Is it even worth including this information in the README? Maybe I should just get rid of the README. What do you think?

Thanks,
Zaak

The README is not necessary for me. At least the different results. It would make sense if it was updated regularly but we know that it will fall behind quickly.

Yes, I think we can skip reporting on the status of various compilers. The Readme can contain a summary of the tests with a reference to the section in the standard.

Please add more details about the tests to the commit message or Summary.
Please add Damian as co-author by using the following format in the commit message or Summary.
Co-Authored-by: Damian Rouson <[e-mail]>

Fortran/UnitTests/finalization/object_type_m.f90

2

Do you mean that you move the line module object_type_m to the test files and rename it there and this file will only contain the contents of the module or its common part? Then that sounds fine to me.

Fortran/UnitTests/finalization/specification_expression_finalization.reference_output

1 ↗

(On Diff #513361)

Sounds OK to me. If this proves to be difficult then you skip this for the first patch.

[zbeekman]

I have made the requested changes and am uploading the patch now.

Fortran/UnitTests/finalization/object_type_m.f90

2

Yes

Fortran/UnitTests/finalization/specification_expression_finalization.reference_output

1 ↗

(On Diff #513361)

I have used cmake's configure_file() to accomplish this. It seems that the testing infrastructure expects a *.reference_output file in the source tree so *.reference_output.in gets configured by CMake to inject the leading "Fortran " when CMAKE_Fortran_COMPILER_ID matches LLVMFlang and the result (*.reference_output) gets placed in the source tree. I've added a .gitignore file so that it's not accidentally committed to the repository at a later date. I tried having the configured file put directly into the CMAKE_CURRENT_BINARY_DIR but the test infrastructure complained that it couldn't find a corresponding *.reference_output in the source tree.

[zbeekman]

• Overhauled the README
• Configured the specification expression reference output to only include the leading Fortran when the CMAKE_Fortran_COMPILER_ID matches LLVMFlang (other compilers don't have this text in their error stop statements)
• Ensured that parallel builds won't fail due to a CMake race condition when multiple .mod module files with the same name are produced (each test now has a unique module name).

[zbeekman]

@kiranchandramohan

I think I've addressed all of your points. I'm new to phabricator--does the commit message come from the summary that I type in? Please let me know how this looks. It would be great to land this patch soon.

Thanks,
Zaak

In D147804#4285696, @kiranchandramohan wrote:

In D147804#4284440, @clementval wrote:

In D147804#4284073, @zbeekman wrote:

@clementval and @kiranchandramohan What do you think of my proposed approach outlined in the inlined comments and the comment I just added above responding to @kiranchandramohan?

I don't have access to all the compilers listed in the README and the support info per-compiler will get stale as new versions are released. Is it even worth including this information in the README? Maybe I should just get rid of the README. What do you think?

Thanks,
Zaak

The README is not necessary for me. At least the different results. It would make sense if it was updated regularly but we know that it will fall behind quickly.

Yes, I think we can skip reporting on the status of various compilers. The Readme can contain a summary of the tests with a reference to the section in the standard.

Please add more details about the tests to the commit message or Summary.
Please add Damian as co-author by using the following format in the commit message or Summary.
Co-Authored-by: Damian Rouson <[e-mail]>

[kiranchandramohan]

In D147804#4316215, @zbeekman wrote:

@kiranchandramohan

I think I've addressed all of your points. I'm new to phabricator--does the commit message come from the summary that I type in? Please let me know how this looks. It would be great to land this patch soon.

Thanks,
Zaak

Thanks for making the changes.

Yes, the commit message comes from the summary if you fetch the patch using arc patch D147804. At the moment, the summary is quite big. Given that the info is contained in the Readme, you could consider shortening it.

I think the ERROR STOP issue is probably not fully solved. See inline for concern. But as I said in my previous reply, this is not important for a first patch. So you may choose to skip this.

LGTM.

Fortran/UnitTests/finalization/CMakeLists.txt

12

Gfortran error stop:
ERROR STOP finalize: intentional error termination to verify finalization
Classic Flang error stop:
ERROR STOP finalize: intentional error termination to verify finalization
llvm/flang error stop:
Fortran ERROR STOP: finalize: intentional error termination to verify finalization

As can be seen from the above, Flang also adds a colon after STOP. So not sure whether this will work fine for other compilers.

[zbeekman]

@kiranchandramohan @clementval I tweaked the configured test reference output so that the colon is also inject when LLVMFlang is detected but omitted otherwise. I have also shortened the commit message. Damian also pointed out that the NAG compiler was initially passing all of tests and amended the readme/commit message to reflect this.

I do not believe I have push access. If you approve these final changes please let me know what needs to happen next to land the patch.

Thanks!

[kiranchandramohan]

In D147804#4321976, @zbeekman wrote:

@kiranchandramohan @clementval I tweaked the configured test reference output so that the colon is also inject when LLVMFlang is detected but omitted otherwise. I have also shortened the commit message. Damian also pointed out that the NAG compiler was initially passing all of tests and amended the readme/commit message to reflect this.

I do not believe I have push access. If you approve these final changes please let me know what needs to happen next to land the patch.

Thanks!

@tarunprabhu Could you help with this?

[tarunprabhu]

In D147804#4322181, @kiranchandramohan wrote:

@tarunprabhu Could you help with this?

Sure.

@zbeekman, should I just use the patch summary as-is for the commit message or did you have anything else in mind?

[zbeekman]

In D147804#4326969, @tarunprabhu wrote:

In D147804#4322181, @kiranchandramohan wrote:

@tarunprabhu Could you help with this?

Sure.

@zbeekman, should I just use the patch summary as-is for the commit message or did you have anything else in mind?

@tarunprabhu I'm happy with the patch summary as-is for the commit message. LMK if there's anything else I can//should do to get this wrapped up and merged.

[zbeekman]

Fortran/UnitTests/finalization/CMakeLists.txt

22

@kiranchandramohan @tarunprabhu @clementval I just noticed this duplicate line can be deleted. Should I updated the patch or can you do that while merging?

[tarunprabhu]

Fortran/UnitTests/finalization/CMakeLists.txt

22

Please update the patch. It may be minor, but it's probably better to not have discrepancies between what is reviewed and what gets merged.

[zbeekman]

Fortran/UnitTests/finalization/CMakeLists.txt

22

@tarunprabhu Done.

Fortran/UnitTests/CMakeLists.txt

 # This file should only contain add_subdirectory(...) one for each test
 add_subdirectory(hello)
 add_subdirectory(fcvs21_f95) # NIST Fortran Compiler Validation Suite
+add_subdirectory(finalization)

Fortran/UnitTests/finalization/.gitignore

+# Configure the file below into the source tree with CMake so that the
+# testing infrastructure can find it.
+
+specification_expression_finalization.reference_output

Fortran/UnitTests/finalization/CMakeLists.txt

+include(CheckFortranCompilerFlag)
+
+# LLVMFlang prefixes error stop output to stdout/stderr with "Fortran"
+# and other compilers don't.
+# The `specification_expression_finalization.f90` test requires
+# examining the output of an `error_stop` statement.
+# Configure the expected results based on the Fortran compiler in use.
+
+set(MAYBE_LLVM_ERROR_STOP_PREFIX "")
+set(MAYBE_LLVM_ERROR_STOP_COLON "")
+if(CMAKE_Fortran_COMPILER_ID MATCHES "LLVMFlang")
+  set(MAYBE_LLVM_ERROR_STOP_PREFIX "Fortran ")
+  set(MAYBE_LLVM_ERROR_STOP_COLON ":")
+endif()
+
+configure_file(
+  specification_expression_finalization.reference_output.in
+  ${CMAKE_CURRENT_SOURCE_DIR}/specification_expression_finalization.reference_output
+  @ONLY)
+
+set(Source)
+list(APPEND Source
+  allocatable_component.f90
+  allocated_allocatable_lhs.f90
+  block_end.f90
+  finalize_on_deallocate.f90
+  finalize_on_end.f90
+  intent_out.f90
+  lhs_object.f90
+  rhs_function_reference.f90
+  specification_expression_finalization.f90
+  target_deallocation.f90)
+
+# set(FP_IGNOREWHITESPACE OFF)
+
+llvm_singlesource()
+
+file(COPY lit.local.cfg DESTINATION "${CMAKE_CURRENT_BINARY_DIR}")

Fortran/UnitTests/finalization/README.md

+Finalization Unit Tests
+=======================
+
+This suite of tests was created  originally by Wileam Phan, Damian Rouson,
+and Brad Richardson as part of the
+[[ https://github.com/sourceryinstitute/smart-pointers | Smart-Pointers ]]
+library's test suite.
+All compilers, except for NAG, did not initially have a working/correct
+implmentation of finalization.
+An all-in-one reproducer test was created to share with compiler
+teams that was easy to run (just compile a single file and run it).
+This is ideal for reporting bugs to compiler teams,
+but not appropriate for inclusion in a compiler test suite.
+
+The original adaptation for inclusion in the llvm-test-suite can be found here:
+
+* https://github.com/BerkeleyLab/llvm-test-suite/tree/damians-fortran-type-finalization
+  SHA: `0268bcf0048e67cd1280f9ef65aebd2aa402130b`
+* https://github.com/BerkeleyLab/llvm-test-suite/tree/berkely-lab-damian-v0.1
+  SHA: `0268bcf0048e67cd1280f9ef65aebd2aa402130b`
+
+The test suite was then adapted to be made appropriate for inclusion
+in a compiler test suite by Izaak Beekman.
+Broadly, this required:
+
+- Each test should be broken into in individual file.
+- Each test should have a corresponding expected output.
+- Use the compilers build system rather than a custom fortran driver program
+  (relying) on `execute_command_line`.
+- The tests should be incorporated following the conventions adopted by the
+  compiler project.
+- The README/documentation should be updated and made appropriate for keeping
+  in the compiler project's test suite repository.
+  - e.g., Describe the tests and how to use them
+  - Don't keep information about what version of which compiler works since
+    it will get stale quickly and be a maintainance headache.
+
+To run these finalization tests, and only these tests,
+first you must build a recent version of llvm flang.
+LLVM version d585a8afdf2f70159759dccb11d775cdf432aba4,
+from Fri Apr 7 18:12:12 2023 +0000 is known to work.
+Newer versions should work as well unless a regression is introduced.
+
+You can setup your directory structure as follows:
+
+```
+llvm-project           # llvm-project/llvm source code
+├── build              # Build directory for llvm-project/flang
+├── test-suite         # llvm-project/llvm-test-suite source code
+└── test-suite-build   # Build directory for test-suite
+```
+
+Flang is built in the `build` subdirectory.
+The test-suite-build directory is created by the user
+and is initially empty until running CMake for the teset-suite.
+To configure, build and run the tests once llvm/flang has been built,
+a command similar to the following can be used from within test-suite-build:
+
+``` shell
+cmake -DCMAKE_BUILD_TYPE=Release \
+  -DCMAKE_Fortran_COMPILER:FILEPATH=/home/users/<you>/llvm-project/build/bin/flang-new \
+  -DCMAKE_Fortran_FLAGS=-flang-experimental-exec \
+  -DTEST_SUITE_FORTRAN:BOOL=On \
+  -DTEST_SUITE_SUBDIRS=Fortran/UnitTests/finalization \
+  ../test-suite
+make -j 4
+../build/bin/llvm-lit Fortran/UnitTests/finalization
+```
+
+Summary of Tests
+----------------
+
+* [`allocatable_component.f90`]
+  * Finalizes an allocatable component object on deallocation of an intent out dymmy argument
+  * Test conformance with Fortran 2018 clause 7.5.6.3, para. 2 ("allocatable entity is deallocated")
+    + 9.7.3.2, para. 6 ("INTENT(OUT) allocatable dummy argument is deallocated")
+* [`allocated_allocatable_lhs.f90`]
+  * Finalizes an allocated allocatable LHS of an intrinsic assignment
+  * Test conformance with Fortran 2018 clause 7.5.6.3, paragraph 1 behavior:
+    "allocated allocatable variable"
+* [`block_end.f90`]
+  * Finalizes a non-pointer non-allocatable object at the end of a block construct
+  * Test conformance with Fortran 2018 clause  7.5.6.3, paragraph 4:
+    "termination of the BLOCK construct"
+* [`finalize_on_deallocate.f90`]
+  * Finalizes an object upon explicit deallocation
+  * Test conformance with Fortran 2018 clause 7.5.6.3, paragraph 2:
+    "allocatable entity is deallocated"
+* [`finalize_on_end.f90`]
+  * finalizes a non-pointer non-allocatable object at the END statement
+  * Test conformance with Fortran 2018 clause 7.5.6.3, paragraph 3:
+    "before return or END statement"
+* [`intent_out.f90`]
+  * Finalizes an intent(out) derived type dummy argument
+  * Test conformance with Fortran 2018 standard clause 7.5.6.3, paragraph 7:
+    "nonpointer, nonallocatable, INTENT (OUT) dummy argument"
+* [`lhs_object.f90`]
+  * Finalizes a non-allocatable object on the LHS of an intrinsic assignment
+  * Test conformance with Fortran 2018 clause 7.5.6.3, paragraph 1 behavior:
+    "not an unallocated allocatable variable"
+* [`rhs_function_reference.f90`]
+  * Finalizes a function reference on the RHS of an intrinsic assignment
+  * Test conformance with Fortran 2018 clause 7.5.6.3, paragraph 5 behavior:
+    "nonpointer function result"
+* [`specification_expression_finalization.f90`]
+  * Finalizes a function result in a specification expression
+  * Test compiler conformance with clause 7.5.6.3, paragraph 6 in the Fortran
+    Interpretation Document (https://j3-fortran.org/doc/year/18/18-007r1.pdf):
+    "If a specification expression in a scoping unit references
+    a function, the result is finalized before execution of the executable
+    constructs in the scoping unit."  (The same statement appears in clause
+    4.5.5.2, paragraph 5 of the Fortran 2003 standard.) In such a scenario,
+    the final subroutine must be pure.  The only way to observe output from
+    a pure final subroutine is for the subroutine to execute an error stop
+    statement.  A correct execution of this test will error-terminate and ouput
+    the text "finalize: intentional error termination to verify finalization".
+* [`target_deallocation.f90`]
+  * Finalizes a target when the associated pointer is deallocated
+  * Test conformance with Fortran 2018 clause 7.5.6.3, paragraph 2 behavior:
+    "pointer is deallocated"
+
+
+Common Code
+-----------
+
+* [`object_type_m.f90`]
+  * To reduce code duplication, yet allow each test to be treated by
+    CMake as a single source file, a small amount of common code is
+    `include`d from this file by each test file.
+  * Due to the way CMake handles `.mod` module files, it is important
+    that each of the test files uses unique module names, otherwise
+    CMake will encounter a race condition when building in parallel
+    wherein it might clobber a `.mod` module file or corresponding
+    timestamp when multiple `.mod` files are being created with the
+    same name.
+  * This file contains the main derived type object for testing and the
+    corresponding final subroutine, `count_finalizations` to verify that
+    finalization took pace (by counting finalizations in a public module
+    variable)
+
+[`allocatable_component.f90`]: ./allocatable_component.f90
+[`allocated_allocatable_lhs.f90`]: ./allocated_allocatable_lhs.f90
+[`block_end.f90`]: ./block_end.f90
+[`finalize_on_deallocate.f90`]: ./finalize_on_deallocate.f90
+[`finalize_on_end.f90`]: ./finalize_on_end.f90
+[`intent_out.f90`]: ./intent_out.f90
+[`lhs_object.f90`]: ./lhs_object.f90
+[`rhs_function_reference.f90`]: ./rhs_function_reference.f90
+[`specification_expression_finalization.f90`]: ./specification_expression_finalization.f90
+[`target_deallocation.f90`]: ./target_deallocation.f90
+[`object_type_m.f90`]: ./object_type_m.f90

Fortran/UnitTests/finalization/allocatable_component.f90

+module  allocatable_component_m
+  include "object_type_m.f90"
+
+  function allocatable_component() result(outcome)
+    !! Test conformance with Fortran 2018 clause 7.5.6.3, para. 2 ("allocatable entity is deallocated")
+    !! + 9.7.3.2, para. 6 ("INTENT(OUT) allocatable dummy argument is deallocated")
+    !! finalizes an allocatable component object
+    type(wrapper_t), allocatable :: wrapper
+    logical outcome
+    integer initial_tally
+
+    initial_tally = finalizations
+
+    allocate(wrapper)
+    allocate(wrapper%object)
+    call finalize_intent_out_component(wrapper)
+    associate(finalization_tally => finalizations - initial_tally)
+      outcome = finalization_tally==1
+    end associate
+
+  contains
+
+    subroutine finalize_intent_out_component(output)
+      type(wrapper_t), intent(out) :: output ! finalizes object component
+      allocate(output%object)
+      output%object%dummy = avoid_unused_variable_warning
+    end subroutine
+
+  end function
+
+end module allocatable_component_m
+
+program main
+  use allocatable_component_m, only : allocatable_component, report
+  implicit none
+  character(len=*), parameter :: description = "finalizes an allocatable component object"
+
+  write(*,"(A)") report(allocatable_component()) // description
+
+end program

Fortran/UnitTests/finalization/allocatable_component.reference_output

+Pass: finalizes an allocatable component object
+exit 0

Fortran/UnitTests/finalization/allocated_allocatable_lhs.f90

+module allocated_allocatable_lhs_m
+  include "object_type_m.f90"
+
+  function allocated_allocatable_lhs() result(outcome)
+    !! Test conformance with Fortran 2018 clause 7.5.6.3, paragraph 1 behavior:
+    !! "allocated allocatable variable"
+    !! finalizes an allocated allocatable LHS of an intrinsic assignment
+    type(object_t), allocatable :: lhs
+    type(object_t) rhs
+    logical outcome
+    integer initial_tally
+
+    rhs%dummy = avoid_unused_variable_warning
+    initial_tally = finalizations
+    allocate(lhs)
+    lhs = rhs ! finalizes lhs
+    associate(finalization_tally => finalizations - initial_tally)
+      outcome = finalization_tally==1
+    end associate
+  end function
+
+end module allocated_allocatable_lhs_m
+
+program main
+  use allocated_allocatable_lhs_m, only : allocated_allocatable_lhs, report
+  implicit none
+  character(len=*), parameter :: description = "finalizes an allocated allocatable LHS of an intrinsic assignment"
+
+  write(*,"(A)") report(allocated_allocatable_lhs()) // description
+
+end program

Fortran/UnitTests/finalization/allocated_allocatable_lhs.reference_output

+Pass: finalizes an allocated allocatable LHS of an intrinsic assignment
+exit 0

Fortran/UnitTests/finalization/block_end.f90

+module block_end_m
+  include "object_type_m.f90"
+
+  function block_end() result(outcome)
+    !! Test conformance with Fortran 2018 clause  7.5.6.3, paragraph 4:
+    !! "termination of the BLOCK construct"
+    !! finalizes a non-pointer non-allocatable object at the end of a block construct
+    logical outcome
+    integer initial_tally
+
+    initial_tally = finalizations
+    block
+      type(object_t) object
+      object % dummy = avoid_unused_variable_warning
+    end block ! Finalizes object
+    associate(finalization_tally => finalizations - initial_tally)
+      outcome = finalization_tally==1
+    end associate
+  end function
+
+end module block_end_m
+
+program main
+  use block_end_m, only : block_end, report
+  implicit none
+  character(len=*), parameter :: description = &
+       "finalizes a non-pointer non-allocatable object at the end of a block construct"
+
+  write(*,"(A)") report(block_end()) // description
+
+end program

Fortran/UnitTests/finalization/block_end.reference_output

+Pass: finalizes a non-pointer non-allocatable object at the end of a block construct
+exit 0

Fortran/UnitTests/finalization/finalize_on_deallocate.f90

+module finalize_on_deallocate_m
+
+  include "object_type_m.f90"
+
+  function finalize_on_deallocate() result(outcome)
+    !! Test conformance with Fortran 2018 clause 7.5.6.3, paragraph 2:
+    !! "allocatable entity is deallocated"
+    !! finalizes an object upon explicit deallocation
+    type(object_t), allocatable :: object
+    logical outcome
+    integer initial_tally
+
+    initial_tally = finalizations
+    allocate(object)
+    object%dummy = 1
+    deallocate(object)          ! finalizes object
+    associate(final_tally => finalizations - initial_tally)
+      outcome = final_tally==1
+    end associate
+  end function
+
+end module finalize_on_deallocate_m
+
+program main
+  use finalize_on_deallocate_m, only : finalize_on_deallocate, report
+  implicit none
+  character(len=*), parameter :: description = "finalizes an object upon explicit deallocation"
+
+  write(*,"(A)") report(finalize_on_deallocate()) // description
+
+end program

Fortran/UnitTests/finalization/finalize_on_deallocate.reference_output

+Pass: finalizes an object upon explicit deallocation
+exit 0

Fortran/UnitTests/finalization/finalize_on_end.f90

+module finalize_on_end_m
+
+  include "object_type_m.f90"
+
+  function finalize_on_end() result(outcome)
+    !! Test conformance with Fortran 2018 clause 7.5.6.3, paragraph 3:
+    !! "before return or END statement"
+    !! finalizes a non-pointer non-allocatable object at the END statement
+    logical outcome
+    integer initial_tally
+
+    initial_tally = finalizations
+    call finalize_on_end_subroutine() ! Finalizes local_obj
+    associate(final_tally => finalizations - initial_tally)
+      outcome = final_tally==1
+    end associate
+
+  contains
+
+    subroutine finalize_on_end_subroutine()
+      type(object_t) :: local_obj
+      local_obj % dummy = avoid_unused_variable_warning
+    end subroutine
+
+  end function
+
+end module finalize_on_end_m
+
+program main
+  use finalize_on_end_m, only : finalize_on_end, report
+  implicit none
+  character(len=*), parameter :: description = &
+       "finalizes a non-pointer non-allocatable object at the END statement"
+
+  write(*,"(A)") report(finalize_on_end()) // description
+
+end program

Fortran/UnitTests/finalization/finalize_on_end.reference_output

+Pass: finalizes a non-pointer non-allocatable object at the END statement
+exit 0

Fortran/UnitTests/finalization/intent_out.f90

+module intent_out_m
+
+  include "object_type_m.f90"
+
+  function intent_out() result(outcome)
+    !! Test conformance with Fortran 2018 standard clause 7.5.6.3, paragraph 7:
+    !! "nonpointer, nonallocatable, INTENT (OUT) dummy argument"
+    !! finalizes an intent(out) derived type dummy argument
+    logical outcome
+    type(object_t) object
+    integer initial_tally
+
+    initial_tally = finalizations
+    call finalize_intent_out_arg(object)
+    associate(finalization_tally => finalizations - initial_tally)
+      outcome = finalization_tally==1
+    end associate
+  contains
+    subroutine finalize_intent_out_arg(output)
+      type(object_t), intent(out) :: output ! finalizes output
+      output%dummy = avoid_unused_variable_warning
+    end subroutine
+  end function
+
+end module intent_out_m
+
+program main
+  use intent_out_m, only : intent_out, report
+  implicit none
+  character(len=*), parameter :: description = "finalizes an intent(out) derived type dummy argument"
+
+  write(*,"(A)") report(intent_out()) // description
+
+end program

Fortran/UnitTests/finalization/intent_out.reference_output

+Pass: finalizes an intent(out) derived type dummy argument
+exit 0

Fortran/UnitTests/finalization/lhs_object.f90

+module lhs_object_m
+
+  include "object_type_m.f90"
+
+  function lhs_object() result(outcome)
+    !! Test conformance with Fortran 2018 clause 7.5.6.3, paragraph 1 behavior:
+    !! "not an unallocated allocatable variable"
+    !! finalizes a non-allocatable object on the LHS of an intrinsic assignment
+    type(object_t) lhs, rhs
+    logical outcome
+    integer initial_tally
+
+    rhs%dummy = avoid_unused_variable_warning
+    initial_tally = finalizations
+    lhs = rhs ! finalizes lhs
+    associate(finalization_tally => finalizations - initial_tally)
+      outcome = finalization_tally==1
+    end associate
+  end function
+
+end module lhs_object_m
+
+program main
+  use lhs_object_m, only : lhs_object, report
+  implicit none
+  character(len=*), parameter :: description = &
+       "finalizes a non-allocatable object on the LHS of an intrinsic assignment"
+
+  write(*,"(A)") report(lhs_object()) // description
+
+end program

Fortran/UnitTests/finalization/lhs_object.reference_output

+Pass: finalizes a non-allocatable object on the LHS of an intrinsic assignment
+exit 0

Fortran/UnitTests/finalization/lit.local.cfg

+config.traditional_output = True
+config.single_source = True
+
+# Flang uses NO_STOP_MESSAGE to control the output of the STOP statement. If
+# it is present in the environment, we should forward it to the tests, otherwise
+# they might choke on warnings about signaling INEXACT exceptions.
+if 'NO_STOP_MESSAGE' in os.environ:
+  config.environment['NO_STOP_MESSAGE'] = os.environ['NO_STOP_MESSAGE']

Fortran/UnitTests/finalization/object_type_m.f90

+  !! This file gets `include "..."`-ed from each main program.
+  !! To prevent a CMake race condition, each main program also declares
+  !! a unique module name so that the .mod files don't clobber eachother.
+  !!
+  !! Common object type module to be included in the test that:
+  !! Define tests for each scenario in which the Fortran 2018
+  !! standard mandates type finalization.
+  implicit none
+
+  public !! Needed for declaring module procedures at the top of each main program
+  public :: report
+  private :: construct_object, count_finalizations, object_t, wrapper_t, finalizations, avoid_unused_variable_warning
+
+  type object_t
+    integer dummy
+  contains
+    !! Comment out the following line to prove the tests will fail
+    final :: count_finalizations
+  end type
+
+  type wrapper_t
+    private
+    type(object_t), allocatable :: object
+  end type
+
+  integer :: finalizations = 0
+  integer, parameter :: avoid_unused_variable_warning = 1
+
+contains
+
+  function construct_object() result(object)
+    !! Constructor for object_t
+    type(object_t) object
+    object % dummy = avoid_unused_variable_warning
+  end function
+
+  subroutine count_finalizations(self)
+    !! Destructor for object_t
+    type(object_t), intent(inout) :: self
+    finalizations = finalizations + 1
+    self % dummy = avoid_unused_variable_warning
+  end subroutine
+
+  pure function report(outcome)
+    logical, intent(in) :: outcome
+    character(len=:), allocatable ::  report
+    report = merge("Pass: ", "Fail: ", outcome)
+  end function
+
+  !! No end module statement since this will be `include`d from other source files

Fortran/UnitTests/finalization/rhs_function_reference.f90

+module rhs_function_reference_m
+
+  include "object_type_m.f90"
+
+  function rhs_function_reference() result(outcome)
+    !! Test conformance with Fortran 2018 clause 7.5.6.3, paragraph 5 behavior:
+    !! "nonpointer function result"
+    !! finalizes a function reference on the RHS of an intrinsic assignment
+    type(object_t), allocatable :: object
+    logical outcome
+    integer initial_tally
+
+    initial_tally = finalizations
+    object = construct_object() ! finalizes object_t result
+    associate(finalization_tally => finalizations - initial_tally)
+      outcome = finalization_tally==1
+    end associate
+  end function
+
+end module rhs_function_reference_m
+
+program main
+  use rhs_function_reference_m, only : rhs_function_reference, report
+  implicit none
+  character(len=*), parameter :: description = &
+       "finalizes a function reference on the RHS of an intrinsic assignment"
+
+  write(*,"(A)") report(rhs_function_reference()) // description
+
+end program

Fortran/UnitTests/finalization/rhs_function_reference.reference_output

+Pass: finalizes a function reference on the RHS of an intrinsic assignment
+exit 0

Fortran/UnitTests/finalization/specification_expression_finalization.f90

+module finalizable_m
+  !! This module supports the main program at the bottom of this file, which
+  !! tests compiler conformance with clause 7.5.6.3, paragraph 6 in the Fortran
+  !! Interpretation Document (https://j3-fortran.org/doc/year/18/18-007r1.pdf):
+  !! "If a specification expression in a scoping unit references
+  !! a function, the result is finalized before execution of the executable
+  !! constructs in the scoping unit."  (The same statement appears in clause
+  !! 4.5.5.2, paragraph 5 of the Fortran 2003 standard.) In such a scenario,
+  !! the final subroutine must be pure.  The only way to observe output from
+  !! a pure final subroutine is for the subroutine to execute an error stop
+  !! statement.  A correct execution of this test will error-terminate and ouput
+  !! the text "finalize: intentional error termination to verify finalization".
+  implicit none
+
+  private
+  public :: finalizable_t, component
+
+  type finalizable_t
+    private
+    integer, pointer :: component_ => null()
+  contains
+    !! Comment out the next line to make the tests fail
+    final :: finalize
+  end Type
+
+  interface finalizable_t
+    module procedure construct
+  end interface
+
+contains
+
+  pure function construct(component) result(finalizable)
+    integer, intent(in) :: component
+    type(finalizable_t) finalizable
+    allocate(finalizable%component_, source = component)
+  end function
+
+  pure function component(self) result(self_component)
+    type(finalizable_t), intent(in) :: self
+    integer self_component
+    if (.not. associated(self%component_)) error stop "component: unassociated component"
+    self_component = self%component_
+  end function
+
+  pure subroutine finalize(self)
+    type(finalizable_t), intent(inout) :: self
+    if (associated(self%component_)) deallocate(self%component_)
+    error stop "finalize: intentional error termination to verify finalization"
+  end subroutine
+
+end module
+
+program specification_expression_finalization
+  !! Test the finalization of a function result in a specification expression
+  use finalizable_m, only : finalizable_t, component
+  implicit none
+
+  call finalize_specification_expression_result
+
+contains
+
+  subroutine finalize_specification_expression_result
+    real tmp(component(finalizable_t(component=0))) !! Finalizes the finalizable_t function result
+    real eliminate_unused_variable_warning
+    tmp = eliminate_unused_variable_warning
+  end subroutine
+
+end program

Fortran/UnitTests/finalization/specification_expression_finalization.reference_output.in

+@MAYBE_LLVM_ERROR_STOP_PREFIX@ERROR STOP@MAYBE_LLVM_ERROR_STOP_COLON@ finalize: intentional error termination to verify finalization
+exit 1

Fortran/UnitTests/finalization/target_deallocation.f90

+module target_deallocation_m
+  include "object_type_m.f90"
+
+  function target_deallocation() result(outcome)
+    !! Test conformance with Fortran 2018 clause 7.5.6.3, paragraph 2 behavior:
+    !! "pointer is deallocated"
+    !! finalizes a target when the associated pointer is deallocated
+    type(object_t), pointer :: object_ptr => null()
+    logical outcome
+    integer initial_tally
+
+    allocate(object_ptr, source=object_t(dummy=0))
+    initial_tally = finalizations
+    deallocate(object_ptr) ! finalizes object
+    associate(finalization_tally => finalizations - initial_tally)
+      outcome = finalization_tally==1
+    end associate
+  end function
+
+end module target_deallocation_m
+
+program main
+  use target_deallocation_m, only : target_deallocation, report
+  implicit none
+  character(len=*), parameter :: description = "finalizes a target when the associated pointer is deallocated"
+
+  write(*,"(A)") report(target_deallocation()) // description
+
+end program

Fortran/UnitTests/finalization/target_deallocation.reference_output

+Pass: finalizes a target when the associated pointer is deallocated
+exit 0