[flang-commits] [flang] [flang] Fix `getTypeSizeAndAlignment` for packed/tail-padded `RecordType` and `TRANSFER` gate (PR #220377)

via flang-commits flang-commits at lists.llvm.org
Thu Sep 3 12:52:59 PDT 2026


================
@@ -8904,10 +8904,15 @@ IntrinsicLibrary::genTransfer(mlir::Type resultType,
         (fir::isa_trivial(sourceType) ||
          mlir::isa<fir::RecordType>(sourceType)) &&
         fir::isa_trivial(moldType)) {
+      // Use storeSizeOnly=true so that tail padding in RecordType sources is
+      // excluded: TRANSFER reinterprets raw data bits, so the comparison must
+      // be against the store size (data bytes), not the allocation size.
       auto sourceSizeAndAlign = fir::getTypeSizeAndAlignment(
-          loc, sourceType, builder.getDataLayout(), builder.getKindMap());
+          loc, sourceType, builder.getDataLayout(), builder.getKindMap(),
+          /*storeSizeOnly=*/true);
----------------
MattPD wrote:

The revised rationale still conflates distinct quantities. At `eabf68933226`, `STORAGE_SIZE(t2)` folds to 64 bits and `STORAGE_SIZE(t1)` folds to 128 bits. For the same two types, `storeSizeOnly` returns 5 and 10 bytes. Descriptors and `TransferImpl` use 8 and 16 bytes.

F2023 16.9.200 defines an array element's stored size. F2023 16.9.212 uses physical representation and does not define that representation in terms of `STORAGE_SIZE`.

Could the size that excludes outer tail padding get its own name and contract? These quantities would then stay independent: allocation extent, transferred representation width, descriptor element extent, runtime copy width, and address alignment.


https://github.com/llvm/llvm-project/pull/220377


More information about the flang-commits mailing list