[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