> 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.
It actually is called through a function pointer (gfc_intrinsic_sym->resolve) in intrinsic.c (resolve_intrinsic), as with all intrinsics. You can find the backtrace by running f951 (`gfortran -print-prog-name=f951`) through gdb and setting a breakpoint on gfc_resolve_transfer. That being said... On Mon, Dec 10, 2018 at 12:12 PM Jakub Jelinek <ja...@redhat.com> wrote: > I think you want to change gfc_conv_intrinsic_transfer ... in this case Jakub is right. I hadn't looked at the body of the resolve function yet, but peeking at it tells me the transfer expression doesn't contain support for padding information, so you'd have to deal with it yourself in translation. > 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. Alternatively you could call BUILT_IN_MEMSET(&tmpdecl, '\x20', dest_word_len) just prior to the MEMCPY whenever flag_dec is set. Fritz
