https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102458
--- Comment #8 from Steve Kargl <sgk at troutmask dot apl.washington.edu> --- On Wed, Sep 22, 2021 at 09:17:18PM +0000, anlauf at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102458 > > anlauf at gcc dot gnu.org changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Attachment #51497|0 |1 > is obsolete| | > > --- Comment #7 from anlauf at gcc dot gnu.org --- > Created attachment 51498 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51498&action=edit > Revised patch including testcase > I think TRANSFER needs to be handled differently. >From the same section of the Fortran standard, TRANSFER is rejected if the following does not apply. (8) a reference to the intrinsic function TRANSFER where each argument is a constant expression and each ultimate pointer component of the SOURCE argument is disassociated, So, one should be able to do something like integer,parameter :: n = 4 integer,parameter :: x(transfer(n, n)) = 1 print *, x end which gfortran will give % gfortran10 -o z a.f90 % ./z 1 1 1 1 If you remove TRANSFER from the patch, it looks good to me. We can revisit TRANSFER when Gerhard breaks gfortran, again! ;-)
