[all-commits] [llvm/llvm-project] bbb7f0: [flang] Fix volatile attribute propagation on allo...

[Asher Mancinelli via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: bbb7f0148177d332df80b5cfdc7d161dca289056
      https://github.com/llvm/llvm-project/commit/bbb7f0148177d332df80b5cfdc7d161dca289056
  Author: Asher Mancinelli <ashermancinelli at gmail.com>
  Date:   2025-05-13 (Tue, 13 May 2025)

  Changed paths:
    M flang/lib/Lower/Bridge.cpp
    M flang/lib/Optimizer/Dialect/FIROps.cpp
    M flang/lib/Optimizer/HLFIR/IR/HLFIROps.cpp
    M flang/lib/Optimizer/Transforms/PolymorphicOpConversion.cpp
    M flang/test/Fir/invalid.fir
    M flang/test/Lower/volatile-allocatable.f90
    M flang/test/Lower/volatile-allocatable1.f90

  Log Message:
  -----------
  [flang] Fix volatile attribute propagation on allocatables (#139183)

Ensure volatility is reflected not just on the reference to an
allocatable, but on the box, too. When we declare a volatile
allocatable, we now get a volatile reference to a volatile box.

Some related cleanups:
* SELECT TYPE constructs check the selector's type for volatility when
creating and designating the type used in the selecting block.
* Refine the verifier for fir.convert. In general, I think it is ok to
implicitly drop volatility in any ptr-to-int conversion because it means
we are in codegen (and representing volatility on the LLVM ops and
intrinsics) or we are calling an external function (are there any cases
I'm not thinking of?)
* An allocatable test that was XFAILed is now passing. Making
allocatables' boxes volatile resulted in accesses of those boxes being
volatile, which resolved some errors coming from the strict verifier.
* I noticed a runtime function was missing the fir.runtime attribute.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications