[all-commits] [llvm/llvm-project] 62a6f9: [flang][MIF] Fix COSHAPE and THIS_IMAGE(coarray) t...

[Kareem Ergawy via All-commits]

  Branch: refs/heads/users/ergawy/fix-coshare-type-mismatch
  Home:   https://github.com/llvm/llvm-project
  Commit: 62a6f96a24e66aa7211433cb9a79c2b0cb5feaad
      https://github.com/llvm/llvm-project/commit/62a6f96a24e66aa7211433cb9a79c2b0cb5feaad
  Author: ergawy <kareem.ergawy at gmail.com>
  Date:   2026-07-09 (Thu, 09 Jul 2026)

  Changed paths:
    M flang/lib/Optimizer/Builder/IntrinsicCall.cpp
    M flang/lib/Optimizer/Transforms/MIFOpConversion.cpp
    M flang/test/Fir/MIF/coshape.mlir
    M flang/test/Fir/MIF/this_image.mlir
    M flang/test/Lower/MIF/coshape.f90
    M flang/test/Lower/MIF/this_image.f90

  Log Message:
  -----------
  [flang][MIF] Fix COSHAPE and THIS_IMAGE(coarray) type mismatch for non-i64 kinds

Both COSHAPE and THIS_IMAGE(coarray [,team]) return integer arrays whose
element type is determined by the Fortran KIND argument (default: i32).
The lowering code was ignoring resultType in both cases and hardcoding i64,
which caused downstream type mismatches:

- COSHAPE: SimplifyHLFIRIntrinsics assertion in PRODUCT(COSHAPE(y)) when
  the product input type (i64) did not match the declared result type (i32).
- THIS_IMAGE(coarray): MLIR verifier error on arith.cmpi with mismatched
  operand types (i64 vs i32) in comparisons like THIS_IMAGE(a) /= [5,0,-7].

Fix: derive eleTy from resultType in both genCoshape and genThisImage and
propagate it into the mif.* op's result type. In MIFOpConversion, extract
a shared convertI64SeqToEleTy helper that post-converts the i64 scratch
buffer written by the PRIF runtime into the declared-element-type buffer
when the two types differ. Both MIFCoshapeOpConversion and
MIFThisImageOpConversion call this helper.

Co-authored-by: Claude Opus 4.7 <noreply at anthropic.com>



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