This is an archive of the discontinued LLVM Phabricator instance.

[flang] Fix function result rewrite
ClosedPublic

Authored by peixin on Nov 2 2022, 3:20 AM.

Details

Summary

When the function result is type(c_ptr/c_funptr), and the function has
or does not have BIND(C) attribute, the function result is not taken as
the first argument of the function call in other compilers such as
gfortran and ifort. Fix it to be consistent with gfortran/ifort by
changing the abstract result type check.

Fix #58739.

Diff Detail

Event Timeline

peixin created this revision.Nov 2 2022, 3:20 AM
Herald added a project: Restricted Project. · View Herald TranscriptNov 2 2022, 3:20 AM
peixin requested review of this revision.Nov 2 2022, 3:20 AM
peixin added inline comments.Nov 2 2022, 3:26 AM
flang/lib/Optimizer/Dialect/FIRType.cpp
955

As Fortran 2018 C1553, if with BIND(C), the function result shall be an interoperable scalar variable. As Fortran 2018 18.3.4(1), the
interoperable scalar variable is not a coarray, has neither the ALLOCATABLE nor the POINTER attribute, and if it is of type character its length is not assumed or declared by an expression that is not a constant expression.

So, fir::SequenceType, fir::BoxType is fine here. The derived type needs more investigations and tests.

The semantic checks will come soon.

Thanks, @peixin. I have verified that this builds and tests correctly and, in combination with the fix in https://reviews.llvm.org/D137237, fixes the problem that I reported in #58739.

@jeanPerier , can you please verify that the changes to the generated FIR look correct?

Thank @peixin, that makes sense to me. I wonder if we are safe assuming that a struct {intptr} result will always have the same ABI as a ptr* result.... We may have to come with something a bit more clever with regards to C_PTR and C_FUNC_PTR in function interfaces, but your fix looks good for me now.

jeanPerier accepted this revision.Nov 3 2022, 1:56 AM
This revision is now accepted and ready to land.Nov 3 2022, 1:56 AM
peixin added a comment.Nov 3 2022, 4:14 AM

I wonder if we are safe assuming that a struct {intptr} result will always have the same ABI as a ptr* result....

Finally, it should be safe for a struct {integer, real, logical, complex, ...}. I only verified it on aarch64. Currently, I don't know if it is true on other archs. Will make it one intern project and share the results later.

This revision was automatically updated to reflect the committed changes.