Hi Mikael,
Am 09.08.23 um 22:21 schrieb Mikael Morin via Gcc-patches:
Hello,
I propose with this patchset a fix for the test value_9.f90 which has been
failing on 32 bits powerpc since it was added a few weeks back (see PR110360
and PR110419).
The problem is an argument type mismatch between a procedure declaration,
and the argument value for a call of that same procedure, in the specific
case of length one character dummy arguments with the value attribute.
Admittedly, our argument passing conventions [1] for those are currently
unspecified.
Before PR110360, character dummy arguments with value attribute were
arrays passed by value, but the actual argument was still passed as
reference. PR110360 changed that to pass length one dummies as bare
character (i.e. scalar integer), like in the bind(c) case (but with length
argument still present). However, the argument type in the function declaration
wasn't changed at the same time, so the test was failing on big-endian 32 bits
targets. Surprisingly, on most targets the middle-end, back-end and runtime
are happy to get a scalar value passed where a length one array is expected.
This can be fixed, either by reverting back to arguments represented as
arrays passed by value with calls fixed, or by keeping the new
representation with single characters for arguments and fixing the procedure
types accordingly.
I haven't really tried the first way, this is using the second one.
The first patch is a preliminary refactoring. The main change is the
second patch. It modifies the types of length one character dummy argsuments
with value attribute in the procedure declarations, so that they are scalar
integer types, consistently with how arguments are passed for calls.
The third patch is a change of error codes in the testcase.
I have regression tested this on x86_64-unknown-linux-gnu, and
powerpc64-unknown-linux-gnu (both -m32 and -m64).
OK for master?
this looks good to me.
There was only one thing I was uncertain what the right way is:
you chose to use mpz_cmp_ui in the length check in the new helper
function gfc_length_one_character_type_p, while in many other places
the length check uses mpz_cmp_si.
Admittedly, a negative (effective/declared) character length can never
occur, except maybe at intermediate times during resolution before this
is fixed up in accordance with the standard. So this is probably more
a cosmetic decision, and you can decide to use either variant.
Thanks for the patch!
Harald
[1] https://gcc.gnu.org/onlinedocs/gfortran/Argument-passing-conventions.html
Mikael Morin (3):
fortran: New predicate gfc_length_one_character_type_p
fortran: Fix length one character dummy arg type [PR110419]
testsuite: Use distinct explicit error codes in value_9.f90
gcc/fortran/check.cc | 7 +-
gcc/fortran/decl.cc | 4 +-
gcc/fortran/gfortran.h | 15 +++
gcc/fortran/trans-expr.cc | 39 ++++---
gcc/fortran/trans-types.cc | 5 +-
gcc/testsuite/gfortran.dg/bind_c_usage_13.f03 | 8 +-
gcc/testsuite/gfortran.dg/value_9.f90 | 108 +++++++++---------
7 files changed, 103 insertions(+), 83 deletions(-)
