[Patch] Fortran: Avoid SAVE_EXPR for deferred-len char types
Steve Kargl
sgk@troutmask.apl.washington.edu
Mon Feb 20 07:24:33 GMT 2023
On Mon, Feb 20, 2023 at 07:56:14AM +0100, Tobias Burnus wrote:
> On 17.02.23 17:27, Steve Kargl wrote:
> > On Fri, Feb 17, 2023 at 12:13:52PM +0100, Tobias Burnus wrote:
> > > OK for mainline?
> > Short version: no.
>
> Would you mind to write a reasoning beyond only a single word?
>
> > > subroutine foo(n)
> > > integer :: n
> > > integer :: array(n*5)
> > > integer :: my_len
> > > ...
> > > my_len = 5
> > > block
> > > character(len=my_len, kind=4) :: str
> > >
> > > my_len = 99
> > > print *, len(str) ! still shows 5 - not 99
> > > end block
> > > end
> > Are you sure about the above comment?
>
> Yes - for three reasons:
> * On the what-feels-right side: It does not make any sense to print
> any other value than 5 given that 'str' has been declared with len = 5.
> * On the GCC side, the SAVE_EXPR ensures that the length is evaluated
> early and then "saved" to ensure its original value is available
> * The quoted text from the standard implies that this is what
> should happen.
Your comment in the above code suggest to me that you
expected 99. Of course, the print statement should
produce 5 and that is what gfortran does. If your patch
only effects deferred character types, why are you including
a useless code example.
--
steve
More information about the Fortran
mailing list