This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, Fortran] pad char to int conversions with spaces instead of zeros (legacy)
- From: Fritz Reese <fritzoreese at gmail dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: mark dot eggleston at codethink dot co dot uk, fortran <fortran at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>, Jeff Law <law at redhat dot com>
- Date: Tue, 4 Dec 2018 12:04:40 -0500
- Subject: Re: [PATCH, Fortran] pad char to int conversions with spaces instead of zeros (legacy)
- References: <17e10b1f-a4a8-745a-0247-7bddfd90df7f@codethink.co.uk> <20181204151130.GB12380@tucnak>
On Tue, Dec 4, 2018 at 10:12 AM Jakub Jelinek <jakub@redhat.com> wrote:
>
> Just a couple of random comments.
> -fdec-pad-with-spaces option name doesn't look right, because it doesn't say
> what the option affects. So perhaps have transfer in the option name?
[...]
> Wouldn't it be better to allow specifying whatever character you want to pad
> with, so that users can choose something even different?
I concur with this. In that case some option like -ftransfer-pad-char=
may be a more appriopriate name, where -fdec may enable a default
transfer-pad-char of \x20 rather than \x00.
>
> > --- a/gcc/fortran/simplify.c
> > +++ b/gcc/fortran/simplify.c
> > @@ -7830,7 +7830,7 @@ gfc_simplify_transfer (gfc_expr *source, gfc_expr *mold, gfc_expr *size)
[...]
> This affects just the simplification when the argument is a known constant.
> Shouldn't we handle it also when it is not a constant?
Yes. Mark, you'll need to also patch iresolve.c (gfc_resolve_transfer)
to affect non-constant resolution.
> The tests look too much big-endian vs. little-endian dependent and
> ascii dependent. We have pdp-endian and doesn't s390x TPF use EBCDIC?
>
> Wouldn't it be better to compare transfer("ABCE", 1_8) with transfer("ABCE ", 1_8)
Agreed.
---
Fritz