public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Mark Eggleston <mark.eggleston@codethink.co.uk>
Cc: Fritz Reese <fritzoreese@gmail.com>,
	fortran <fortran@gcc.gnu.org>,
	       gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH, Fortran] pad char to int conversions with spaces instead of zeros (legacy)
Date: Mon, 10 Dec 2018 17:12:00 -0000	[thread overview]
Message-ID: <20181210171229.GD12380@tucnak> (raw)
In-Reply-To: <642cbe8d-d03f-3582-e830-84dba6330ee0@codethink.co.uk>

On Mon, Dec 10, 2018 at 02:09:50PM +0000, Mark Eggleston wrote:
> 
> On 06/12/2018 10:20, Mark Eggleston wrote:
> > > Yes. Mark, you'll need to also patch iresolve.c (gfc_resolve_transfer)
> > > to affect non-constant resolution.
> > Thanks for the hint.
> 
> I've looked at gfc_resolve_transfer regarding handling of padding when a
> character variable is passed to transfer instead of a literal. This routine
> is not called so can't be where a variable would be handled.
> 
> Don't yet know where to make the change.

I think you want to change gfc_conv_intrinsic_transfer
For the scalar case, which is the one for which I've posted testcase, there
is:
  extent = fold_build2_loc (input_location, MIN_EXPR, gfc_array_index_type,
                            dest_word_len, source_bytes);
  extent = fold_build2_loc (input_location, MAX_EXPR, gfc_array_index_type,
                            extent, gfc_index_zero_node);
and later:
      tmp = build_call_expr_loc (input_location,
                             builtin_decl_explicit (BUILT_IN_MEMCPY), 3,
                             fold_convert (pvoid_type_node, tmp),
                             fold_convert (pvoid_type_node, ptr),
                             fold_convert (size_type_node, extent));
      gfc_add_expr_to_block (&se->pre, tmp);
I guess you want to add after this, guarded with flag_dec only,
code to compare (at runtime) if extent < dest_word_len and if so,
use fill_with_spaces to pad it with spaces at the end (from
that first memcpy's argument + extent dest_word_len - extent bytes),
with a comment why you are doing it.  Guess the array case will need
something similar.  But, for these runtime checks, guess you should start by
looking what the other compilers are exactly doing for the different kinds
of transfers, if they pad for non-constants at all, if they only pad if
transfer is from a character object to whatever, etc.

Looking at ifort on godbolt
function foo (e)
  integer(kind=8) :: foo
  character(len=4) :: e
  foo = transfer(e, 1_8)
end
I see it calls for_cpystr (..., 8, ..., 4, ...)
so I guess it uses standard library function to copy string into the
destination in that case, so essentially what gfc_trans_string_copy
does inline or our fstrcpy (internal library function).

	Jakub

  reply	other threads:[~2018-12-10 17:12 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-04 14:47 Mark Eggleston
2018-12-04 15:11 ` Jakub Jelinek
2018-12-04 17:04   ` Fritz Reese
2018-12-06  2:27     ` Jerry DeLisle
2018-12-06 10:50       ` Jakub Jelinek
2018-12-06 10:54         ` Mark Eggleston
2018-12-07  1:57         ` Jerry DeLisle
2018-12-06 10:34     ` Mark Eggleston
2018-12-10 14:09       ` Mark Eggleston
2018-12-10 17:12         ` Jakub Jelinek [this message]
2018-12-10 19:44           ` Fritz Reese
2018-12-12 11:37           ` Mark Eggleston
2018-12-12 11:53             ` Jakub Jelinek
2018-12-12 12:06               ` Mark Eggleston
2018-12-12 12:12                 ` Jakub Jelinek
2018-12-12 15:12                 ` Mark Eggleston
2018-12-06 10:23   ` Mark Eggleston

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181210171229.GD12380@tucnak \
    --to=jakub@redhat.com \
    --cc=fortran@gcc.gnu.org \
    --cc=fritzoreese@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=mark.eggleston@codethink.co.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).