From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) by sourceware.org (Postfix) with ESMTPS id ADF1A3885C2F; Mon, 20 Feb 2023 10:41:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org ADF1A3885C2F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-lj1-x22c.google.com with SMTP id f16so645404ljq.10; Mon, 20 Feb 2023 02:41:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=QnAQAm7AGJJUwyOtv4b09hnWF4b5NcIykngE5EgGho8=; b=ZyjPa7VwJlLAc/BW/U7l26B8U7JTgM9f1ZqTHmdZoct4fvDhK9//KNk0wgZY1MDsfc rwIwkEouzQeLRK73qYLZ+ij5B6zeNogrMAntNwjjm+8Hn0Koy4CStsZAZWb6ZvpJIkf4 ENHsKYDJkveN0XFAeXMjcqamVxDr5YJ5IinPxDV2Bd5amMQfn46rNlaiNueV55A2dD5Z 8WPgr7htU9vxyhyl4b5UTcizV1OGBPdgrfhPAZ9PkLmJk5BEKG/VaMH6Cw1stwqI+bmm 940HUJA4qUgW7V0a6klzGCDaKYta1ZZ5hIdgfqyJxzapTabdeyVvSfxOQbcsmVuhLzRq JmAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=QnAQAm7AGJJUwyOtv4b09hnWF4b5NcIykngE5EgGho8=; b=OA3S45mvnHYO3tAGpB4Ui06n9Uoe8UY2xdpELNJVDEuyHtwdtzjP8WlwM+kQGesorj kKYGSab3aeZ8d/e41lnimsqDVUukvptvfI5u6cgz8dNCci5wwnYuQZp0FbcC+lSsGwLr JfC0Fv/51tym1yIk6oxL50YqRYMUYTgebzI/7yha+vK2IZ1my6xrUsKtwlGlr6B6uYVO 8QRr/BU/K4eylG19/UgL0Ewt0qqLVAIVRzdWeyQTVjaRFaFFC2OtPfTId9xsr4b7NN/2 iSrTCnp+q07zNdVvcv8T8dN6GL4j7PEVRdddSkmM3hYtPnwrOjTlQ6gTfTg6JMRCq6yK oLFw== X-Gm-Message-State: AO0yUKUOr+45uQ8wbCjb3iZgCAD2fDV4Yl1GFLBbFbGScKLh6XW2Dcdv 1QEvu/7JSE+YWQ1P5pMv2hr/Ge18icE+/0wpuAc= X-Google-Smtp-Source: AK7set/O+WsyohXxfjZxyDej1oZPpD+ND+SShzroCkCHEqUQkLLdJDdFrpwhu4L7deJxbahr1KImPAr0vJ4ECxna8YI= X-Received: by 2002:a05:651c:b9b:b0:293:4ba5:f632 with SMTP id bg27-20020a05651c0b9b00b002934ba5f632mr564556ljb.10.1676889715001; Mon, 20 Feb 2023 02:41:55 -0800 (PST) MIME-Version: 1.0 References: <27cd606a-f019-60b2-a9c8-0a570433b5eb@codesourcery.com> In-Reply-To: From: Richard Biener Date: Mon, 20 Feb 2023 11:41:40 +0100 Message-ID: Subject: Re: [Patch] Fortran: Avoid SAVE_EXPR for deferred-len char types To: Tobias Burnus Cc: sgk@troutmask.apl.washington.edu, gcc-patches , fortran , Paul Richard Thomas Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Mon, Feb 20, 2023 at 11:05 AM Tobias Burnus wr= ote: > > 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 =3D 5 > >> block > >> character(len=3Dmy_len, kind=3D4) :: str > >> > >> my_len =3D 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 =3D= 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 Generally SAVE_EXPR is used to make sure an expression is only evaluated once. It's DECL_EXPR that ensures something is evaluated early and available. So generally "unwrapping" a SAVE_EXPR looks dangerous to me unless the SAVE_EXPR is really never necessary. Richard. > * The quoted text from the standard implies that this is what > should happen. > > Why do you think that printing "5" is wrong? GCC does so since > years; it still does so with my patch. > > Hence, can you elaborate? And also state which value you did expect inste= ad? > > * * * > > The patch itself is about *deferred* length parameters, i.e. > 'len=3D:', and thus for code like: > > character(len=3D:), pointer :: str > ... > allocate(character(len=3D4) :: str) > print *, len(str) ! should print 4 > ... > allocate(character(len=3D99) :: str) > print *, len(str) ! should now print 99 > ... > > Currently, the SAVE_EXPR causes that the original value might > get used, which is often 0 (by chance 0 initialized) or some > random value like 57385973, depending what on what was on the > stack before. - There are more issues with deferred strings, > but at least one is solved by not having a SAVE_EXPR for > deferred-length character strings. > > Tobias > > ----------------- > Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstra=C3=9Fe 2= 01, 80634 M=C3=BCnchen; Gesellschaft mit beschr=C3=A4nkter Haftung; Gesch= =C3=A4ftsf=C3=BChrer: Thomas Heurung, Frank Th=C3=BCrauf; Sitz der Gesellsc= haft: M=C3=BCnchen; Registergericht M=C3=BCnchen, HRB 106955