From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=p7iV=6N=troutmask.apl.washington.edu=sgk@sourceware.org>
Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21])
	by sourceware.org (Postfix) with ESMTPS id 64935385781F;
	Fri, 17 Feb 2023 16:27:32 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 64935385781F
Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=troutmask.apl.washington.edu
Authentication-Results: sourceware.org; spf=none smtp.mailfrom=troutmask.apl.washington.edu
Received: from troutmask.apl.washington.edu (localhost [127.0.0.1])
	by troutmask.apl.washington.edu (8.17.1/8.17.1) with ESMTPS id 31HGRPhI076115
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO);
	Fri, 17 Feb 2023 08:27:25 -0800 (PST)
	(envelope-from sgk@troutmask.apl.washington.edu)
Received: (from sgk@localhost)
	by troutmask.apl.washington.edu (8.17.1/8.17.1/Submit) id 31HGRPoC076114;
	Fri, 17 Feb 2023 08:27:25 -0800 (PST)
	(envelope-from sgk)
Date: Fri, 17 Feb 2023 08:27:25 -0800
From: Steve Kargl <sgk@troutmask.apl.washington.edu>
To: Tobias Burnus <tobias@codesourcery.com>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>, fortran <fortran@gcc.gnu.org>,
        Paul Richard Thomas <paul.richard.thomas@gmail.com>
Subject: Re: [Patch] Fortran: Avoid SAVE_EXPR for deferred-len char types
Message-ID: <Y++q7cf34jsOeRST@troutmask.apl.washington.edu>
Reply-To: sgk@troutmask.apl.washington.edu
References: <27cd606a-f019-60b2-a9c8-0a570433b5eb@codesourcery.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <27cd606a-f019-60b2-a9c8-0a570433b5eb@codesourcery.com>
X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org
List-Id: <gcc-patches.gcc.gnu.org>

On Fri, Feb 17, 2023 at 12:13:52PM +0100, Tobias Burnus wrote:
> Short version:
> 
> This fixes potential and real bugs related to 'len=:' character variables
> as for the length/byte size an old/saved expression is used instead of
> the current value. - That's fine but not for allocatable/pointer with 'len=:'.
> 
> 
> Main part of the patch: Strip the SAVE_EXPR from the size expression:
> 
>   if (len && deferred && TREE_CODE (TYPE_SIZE (type)) == SAVE_EXPR)
>     {
>       gcc_assert (TREE_CODE (TYPE_SIZE_UNIT (type)) == SAVE_EXPR);
>       TYPE_SIZE (type) = TREE_OPERAND (TYPE_SIZE (type), 0);
>       TYPE_SIZE_UNIT (type) = TREE_OPERAND (TYPE_SIZE_UNIT (type), 0);
>     }
> 
> 
> OK for mainline?

Short version: no.

> 
> * * *
> 
> Long version:
> 
> BACKGROUND:
> 
> 
> (A) VLA / EXPLICIT-SIZE ARRAYS + LEN=<expr|var> STRINGS
> 
> 
> C knows something like VLA (variable length arrays), likewise Fortran
> knows explicit size array and character length where the length/size
> depends on an variable set before the current scoping unit. Examples:
> 
> void f(int N)
> {
>   int vla[N*5];
> }
> 
> 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?  At the time 
that str is declared, it is given a kind type parameter
of len=5 and kind=4.  After changing my_len to 99
the kind type parameter of str does not change.


8.3 Automatic data objects

If a type parameter in a declaration-type-spec or in a char-length
in an entity-decl for a local variable of a subprogram or BLOCK
construct is defined by an expression that is not a constant
expression, the type parameter value is established on entry to a
procedure defined by the subprogram, or on execution of the BLOCK
statement, and is not affected by any redefinition or undefinition
of the variables in the expression during execution of the
procedure or BLOCK construct.

-- 
steve