[flang] Incorrect result for whole `SEQUENCE` component assignment with `EQUIVALENCE` aliasing

[MattPD]

Reproducer, alias_seq_assign:
https://flang.godbolt.org/z/5z9rnq5e9

Flang appears to miscompile a test program that uses SEQUENCE types and EQUIVALENCE and performs a whole‑component intrinsic assignment c%b = d%b where c and d are different SEQUENCE views of the same storage. Other compilers (multiple gfortran versions, ifort/ifx) also fail this same test, suggesting this may be a common issue with the abstract Fortran semantics for this pattern.

To my understanding this program is standard‑conforming: It uses SEQUENCE derived types and an EQUIVALENCE statement in ways allowed by Fortran 2018 (7.5.2.3/Sequence type and 8.10.1/EQUIVALENCE statement).

The assignment c%b = d%b is a whole‑object intrinsic assignment between two SEQUENCE components of the same type, and must be executed componentwise:

• According to Fortran 2018, 10.2.1.2/Intrinsic assignment statement, items (7)–(8), intrinsic assignment is permitted between c%b and d%b because they are compatible derived‑type variables with the same type and type parameters.
• 10.2.1.3/Interpretation of intrinsic assignments then specifies that execution of the intrinsic assignment c%b = d%b has the same effect as if the expression d%b were fully evaluated before any portion of c%b is defined.
• In this case, d%b is a SEQUENCE derived type with three integer components [1,2,3], so the final value of c%b must have those three component values, and hence the underlying equivalenced integer array e must end up as [1,1,2,3].

Expected semantics

Initial

After init_e (e = (/ (i, i=1,4) /)), we have e = [1,2,3,4].

Storage mapping via EQUIVALENCE:

• c storage: [c%a, c%b%e(1), c%b%e(2), c%b%f(1)] = [1,2,3,4]
• d storage: [d%b%e(1), d%b%e(2), d%b%f(1), d%a] = [1,2,3,4]

That is,

c%a is e(1)
c%b%e is e(2:3)
c%b%f(1) is e(4)

d%b%e is e(1:2)
d%b%f(1) is e(3)
d%a is e(4)

So d%b as a 3‑element SEQUENCE of integers is [1,2,3].

---

Right shift: c%b = d%b

The whole‑object intrinsic assignment c%b = d%b must copy those three original component values into c%b:

e(1) remains 1
c%b%e(1) = d%b%e(1) → e(2) = e(1)
c%b%e(2) = d%b%e(2) → e(3) = e(2)
c%b%f(1) = d%b%f(1) → e(4) = e(3)

Given e = [1,2,3,4] before right shift, the sequence is:

e(2) = e(1)
e(3) = e(2)
e(4) = e(3)

resulting in

e(1) unchanged = 1
e(2) = c%b%e(1) = 1
e(3) = c%b%e(2) = 2
e(4) = c%b%f(1) = 3

Thus the final e must be e = [1, 1, 2, 3] and check_right_shift should report no errors, printing: PASS alias_seq_assign.

Observed behavior

With flang (versions 21.1.8 - 22.0.0, checked as of commit 568b8e4), compiling with -O0 to -O3, the program results in a failure, and e contains values different from [1,1,2,3]:

2. Got e( 3 ) = 1 , expected 2
2. Got e( 4 ) = 1 , expected 3

What gives me pause is that other compilers (multiple gfortran versions, ifort/ifx) show similar failures on the same reproducer, so this appears to be a cross‑compiler corner case where the abstract semantics of whole‑object assignment in the presence of aliasing via EQUIVALENCE are not being respected.

However, CCE Fortran does result in correct compilation.
Interestingly, NVFortran 25.11 produces correct result for N=100, https://nvfortran.godbolt.org/z/sx6hEqd3d, but does result in a (different) failure for N=2: Got e( 4 ) = 2 , expected 3

Notes

A simpler test without EQUIVALENCE passes with flang; e and f are both copied. This suggests the bug is specific to the aliasing / equivalenced‑storage case, not to SEQUENCE assignment in general.

In a larger version of this test https://flang.godbolt.org/z/7WdoE7erj the generated FIR for c%b = d%b appears to only copy the e component of t. This may be an additional symptom of the same underlying issue (assignment in the presence of equivalenced host‑associated storage).

In particular, check_left_shift passes whereas check_right_shift fails.
Comparing HLFIR for both seems to show no major differences--however, FIR shows lowering for full assignment semantics for left_shift while FIR for right_shift is missing f.

This could indicate it's an HLFIR-to-FIR lowering problem?

[klausler]

I think that this is the test case:

program alias_seq_assign
  implicit none
  integer, parameter :: N = 2

  type t
    sequence
    integer :: e(N), f(N-1)
  end type t

  type t1
    sequence
    integer :: a
    type(t) :: b
  end type t1

  type t2
    sequence
    type(t) :: b
    integer :: a
  end type t2

  type(t1) :: c
  type(t2) :: d
  integer  :: e(2*N)
  integer  :: errors

  equivalence (c, d, e)

  errors = 0
  call init_e()
  call right_shift()
  call check_right_shift(errors)

  if (errors == 0) then
    print *, 'PASS alias_seq_assign'
  else
    print *, 'FAIL alias_seq_assign, errors = ', errors
  end if

contains

  subroutine init_e()
    integer :: i
    e = (/ (i, i=1,2*N) /)
  end subroutine init_e

  subroutine right_shift()
    c%b = d%b
  end subroutine right_shift

  subroutine check_right_shift(errors)
    integer, intent(inout) :: errors
    integer :: i

    if (e(1) /= 1) then
      print *, 'Got e(1) = ', e(1), ', expected 1'
      errors = errors + 1
    end if

    do i = 2, 2*N
      if (e(i) /= i-1) then
        print *, 'Got e(', i, ') = ', e(i), ', expected ', i-1
        errors = errors + 1
      end if
    end do
  end subroutine check_right_shift

end program alias_seq_assign

[klausler]

fir::factory::genRecordAssignment is failing to call genAssign for this aliasing case; genComponentByComponentAssignment assumes no aliasing. The runtime can detect and handle aliasing, and the test passes if one tweaks lowering to always call it.

[MattPD]

Thanks! I can confirm that v1 tweak (unconditionally calling genAssign instead of genComponentByComponentAssignment) does result in the pass. Now, the question is how to limit this for this and similar aliasing cases. I have a v2 tweak that can perhaps be a bit less conservative by adding a conditional check whether basesAreProvablyDisjoint. Let me know if such an approach makes sense and if so I can provide a patch in a PR:

/// Return true if we can prove the two bases do not alias.
/// Currently handles the common cases of distinct allocas and distinct globals.
/// Otherwise, be conservative (may alias).
static bool basesAreProvablyDisjoint(mlir::Value lhsBase, mlir::Value rhsBase) {
  if (lhsBase == rhsBase)
    return false;

  if (auto lhsAlloca = lhsBase.getDefiningOp<fir::AllocaOp>())
    if (auto rhsAlloca = rhsBase.getDefiningOp<fir::AllocaOp>())
      return lhsAlloca != rhsAlloca; // different stack slots => disjoint

  if (auto lhsAddr = lhsBase.getDefiningOp<fir::AddrOfOp>())
    if (auto rhsAddr = rhsBase.getDefiningOp<fir::AddrOfOp>())
      return lhsAddr.getSymbol() != rhsAddr.getSymbol(); // different globals

  // Anything else: be conservative.
  return false;
}

void fir::factory::genRecordAssignment(fir::FirOpBuilder &builder,
                                       mlir::Location loc,
                                       const fir::ExtendedValue &lhs,
                                       const fir::ExtendedValue &rhs,
                                       bool needFinalization,
                                       bool isTemporaryLHS) {
  assert(lhs.rank() == 0 && rhs.rank() == 0 && "assume scalar assignment");
  auto baseTy = fir::dyn_cast_ptrOrBoxEleTy(fir::getBase(lhs).getType());
  assert(baseTy && "must be a memory type");
  bool hasBoxOperands =
      mlir::isa<fir::BaseBoxType>(fir::getBase(lhs).getType()) ||
      mlir::isa<fir::BaseBoxType>(fir::getBase(rhs).getType());
  auto recTy = mlir::dyn_cast<fir::RecordType>(baseTy);
  assert(recTy && "must be a record type");

  // New: guard the fast path with an explicit "no-alias" proof.
  bool disjoint = basesAreProvablyDisjoint(fir::getBase(lhs), fir::getBase(rhs));

  if ((needFinalization && mayHaveFinalizer(recTy, builder)) ||
      hasBoxOperands || !recordTypeCanBeMemCopied(recTy) || !disjoint) {
    auto to = fir::getBase(builder.createBox(loc, lhs));
    auto from = fir::getBase(builder.createBox(loc, rhs));
    auto toMutableBox = builder.createTemporary(loc, to.getType());
    fir::StoreOp::create(builder, loc, to, toMutableBox);
    if (isTemporaryLHS)
      fir::runtime::genAssignTemporary(builder, loc, toMutableBox, from);
    else
      fir::runtime::genAssign(builder, loc, toMutableBox, from);
    return;
  }

  // Safe fast path: componentwise copy when we know the bases are disjoint.
  genComponentByComponentAssignment(builder, loc, lhs, rhs, isTemporaryLHS);
}

[MattPD]

I've been able to get this test to pass using fir::AliasAnalysis to produce the disjoint predicate; going to run tests and hopefully can open PR if this looks good?

void fir::factory::genRecordAssignment(fir::FirOpBuilder &builder,
                                       mlir::Location loc,
                                       const fir::ExtendedValue &lhs,
                                       const fir::ExtendedValue &rhs,
                                       bool needFinalization,
                                       bool isTemporaryLHS) {
  assert(lhs.rank() == 0 && rhs.rank() == 0 && "assume scalar assignment");
  auto baseTy = fir::dyn_cast_ptrOrBoxEleTy(fir::getBase(lhs).getType());
  assert(baseTy && "must be a memory type");
  // Box operands may be polymorphic, it is not entirely clear from 10.2.1.3
  // if the assignment is performed on the dynamic of declared type. Use the
  // runtime assuming it is performed on the dynamic type.
  bool hasBoxOperands =
      mlir::isa<fir::BaseBoxType>(fir::getBase(lhs).getType()) ||
      mlir::isa<fir::BaseBoxType>(fir::getBase(rhs).getType());
  auto recTy = mlir::dyn_cast<fir::RecordType>(baseTy);
  assert(recTy && "must be a record type");

  // Use alias analysis to guard the fast path.
  fir::AliasAnalysis aa;
  bool disjoint = aa.alias(fir::getBase(lhs), fir::getBase(rhs)) ==
                  mlir::AliasResult::NoAlias;

  if ((needFinalization && mayHaveFinalizer(recTy, builder)) ||
      hasBoxOperands || !recordTypeCanBeMemCopied(recTy) || !disjoint) {
    auto to = fir::getBase(builder.createBox(loc, lhs));
    auto from = fir::getBase(builder.createBox(loc, rhs));
    // The runtime entry point may modify the LHS descriptor if it is
    // an allocatable. Allocatable assignment is handle elsewhere in lowering,
    // so just create a fir.ref<fir.box<>> from the fir.box to comply with the
    // runtime interface, but assume the fir.box is unchanged.
    // TODO: does this holds true with polymorphic entities ?
    auto toMutableBox = builder.createTemporary(loc, to.getType());
    fir::StoreOp::create(builder, loc, to, toMutableBox);
    if (isTemporaryLHS)
      fir::runtime::genAssignTemporary(builder, loc, toMutableBox, from);
    else
      fir::runtime::genAssign(builder, loc, toMutableBox, from);
    return;
  }

  // Otherwise, the derived type has compile time constant size and for which
  // the component by component assignment can be replaced by a memory copy.
  // Since we do not know the size of the derived type in lowering, do a
  // component by component assignment. Note that a single fir.load/fir.store
  // could be used on "small" record types, but as the type size grows, this
  // leads to issues in LLVM (long compile times, long IR files, and even
  // asserts at some point). Since there is no good size boundary, just always
  // use component by component assignment here.
  genComponentByComponentAssignment(builder, loc, lhs, rhs, isTemporaryLHS);
}

[MattPD]

Update: There is some fallout after all--5 lowering tests:

Lower/OpenACC/acc-firstprivate-derived-pointer-component.f90
Lower/OpenACC/acc-firstprivate-derived-user-assign.f90
Lower/OpenACC/acc-firstprivate-derived.f90
Lower/array-elemental-calls-2.f90
Lower/derived-type-finalization.f90

Investigating... Edit: Rebasing on top of commit 802ca04, [flang][NFC] Converted five tests from old lowering to new lowering (part 6) #175485, does resolve the failure of "flang/test/Lower/array-elemental-calls-2.f90". Thus, it's possible that at least some of the failures are not caused by the patch per se.

[MattPD]

@klausler @jeanPerier Opened PR:
Use alias analysis in lowering record assignments
#176483

[llvmbot]

@llvm/issue-subscribers-flang-ir

Author: Matt (MattPD)

Details

Reproducer, `alias_seq_assign`: https://flang.godbolt.org/z/5z9rnq5e9

Flang appears to miscompile a test program that uses SEQUENCE types and EQUIVALENCE and performs a whole‑component intrinsic assignment c%b = d%b where c and d are different SEQUENCE views of the same storage. Other compilers (multiple gfortran versions, ifort/ifx) also fail this same test, suggesting this may be a common issue with the abstract Fortran semantics for this pattern.

To my understanding this program is standard‑conforming: It uses SEQUENCE derived types and an EQUIVALENCE statement in ways allowed by Fortran 2018 (7.5.2.3/Sequence type and 8.10.1/EQUIVALENCE statement).

The assignment c%b = d%b is a whole‑object intrinsic assignment between two SEQUENCE components of the same type, and must be executed componentwise:

• According to Fortran 2018, 10.2.1.2/Intrinsic assignment statement, items (7)–(8), intrinsic assignment is permitted between c%b and d%b because they are compatible derived‑type variables with the same type and type parameters.
• 10.2.1.3/Interpretation of intrinsic assignments then specifies that execution of the intrinsic assignment c%b = d%b has the same effect as if the expression d%b were fully evaluated before any portion of c%b is defined.
• In this case, d%b is a SEQUENCE derived type with three integer components [1,2,3], so the final value of c%b must have those three component values, and hence the underlying equivalenced integer array e must end up as [1,1,2,3].

Expected semantics

Initial

After init_e (e = (/ (i, i=1,4) /)), we have e = [1,2,3,4].

Storage mapping via EQUIVALENCE:

• c storage: [c%a, c%b%e(1), c%b%e(2), c%b%f(1)] = [1,2,3,4]
• d storage: [d%b%e(1), d%b%e(2), d%b%f(1), d%a] = [1,2,3,4]

That is,

c%a is e(1)
c%b%e is e(2:3)
c%b%f(1) is e(4)

d%b%e is e(1:2)
d%b%f(1) is e(3)
d%a is e(4)

So d%b as a 3‑element SEQUENCE of integers is [1,2,3].

---

Right shift: c%b = d%b

The whole‑object intrinsic assignment c%b = d%b must copy those three original component values into c%b:

e(1) remains 1
c%b%e(1) = d%b%e(1) → e(2) = e(1)
c%b%e(2) = d%b%e(2) → e(3) = e(2)
c%b%f(1) = d%b%f(1) → e(4) = e(3)

Given e = [1,2,3,4] before right shift, the sequence is:

e(2) = e(1)
e(3) = e(2)
e(4) = e(3)

resulting in

e(1) unchanged = 1
e(2) = c%b%e(1) = 1
e(3) = c%b%e(2) = 2
e(4) = c%b%f(1) = 3

Thus the final e must be e = [1, 1, 2, 3] and check_right_shift should report no errors, printing: PASS alias_seq_assign.

Observed behavior

With flang (versions 21.1.8 - 22.0.0, checked as of commit 568b8e4), compiling with -O0 to -O3, the program results in a failure, and e contains values different from [1,1,2,3]:

2. Got e( 3 ) = 1 , expected 2
2. Got e( 4 ) = 1 , expected 3

What gives me pause is that other compilers (multiple gfortran versions, ifort/ifx) show similar failures on the same reproducer, so this appears to be a cross‑compiler corner case where the abstract semantics of whole‑object assignment in the presence of aliasing via EQUIVALENCE are not being respected.

However, CCE Fortran does result in correct compilation.
Interestingly, NVFortran 25.11 produces correct result for N=100, https://nvfortran.godbolt.org/z/sx6hEqd3d, but does result in a (different) failure for N=2: Got e( 4 ) = 2 , expected 3

Notes

A simpler test without EQUIVALENCE passes with flang; e and f are both copied. This suggests the bug is specific to the aliasing / equivalenced‑storage case, not to SEQUENCE assignment in general.

In a larger version of this test https://flang.godbolt.org/z/7WdoE7erj the generated FIR for c%b = d%b appears to only copy the e component of t. This may be an additional symptom of the same underlying issue (assignment in the presence of equivalenced host‑associated storage).

In particular, check_left_shift passes whereas check_right_shift fails.
Comparing HLFIR for both seems to show no major differences--however, FIR shows lowering for full assignment semantics for left_shift while FIR for right_shift is missing f.

This could indicate it's an HLFIR-to-FIR lowering problem?

[eugeneepshteyn]

Unfortunately, the fix was reverted: #179901

Re-opening this issue.