In elemental procedure lowering the passed object is always emboxed. The current code
was not correctly dealing with scalar derived-type used as passed object.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
flang/test/Lower/polymorphic.f90 | ||
---|---|---|
690 | Do you know which passBy this argument is being set to by the Fortran::lower::CallerInterface at https://github.com/llvm/llvm-project/blob/main/flang/lib/Lower/ConvertExpr.cpp#L2591 ? I did not test, but I find it weird that you have to deal with creating the box in convertWithSemantics(). It suggests to me that passBy may be set to PassBy::BaseAddressValueAttribute when I would expect it to be set to PassBy::Box. If the same were to happen with arrays or with type with type parameters, the length/shape would be unavailable at that point. |
flang/test/Lower/polymorphic.f90 | ||
---|---|---|
690 | In this particular example, it is correct. It's PassBy::Box. I'll update this patch with the correct example where it fails and double check the PassBy behavior. |
@jeanPerier The issue was actually in genElementalUserDefinedProcRef in the code added in D139537. When the arg is scalar the lowering was not correct.
Do you know which passBy this argument is being set to by the Fortran::lower::CallerInterface at https://github.com/llvm/llvm-project/blob/main/flang/lib/Lower/ConvertExpr.cpp#L2591 ?
I did not test, but I find it weird that you have to deal with creating the box in convertWithSemantics(). It suggests to me that passBy may be set to PassBy::BaseAddressValueAttribute when I would expect it to be set to PassBy::Box.
If the same were to happen with arrays or with type with type parameters, the length/shape would be unavailable at that point.