From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by sourceware.org (Postfix) with ESMTPS id DBF703858D37 for ; Sun, 11 Feb 2024 17:40:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DBF703858D37 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 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org DBF703858D37 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=128.95.76.21 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707673208; cv=none; b=s9a5LHn2lEOPoGsHg75aARMUcuhkkY0jg2aNrGZKBrZQA92vqGN4TGTV2CtLMLTbA5Sy2AZf7yin3/ykCxGSgAHu7ts0OdXblYjb3Wxd+Z0TWEX8Q4MsL70qdN+KZAjMJPK8Mf9+qBHgcs19q0MdLFkT5oZf0B/BEBf2Yj3tPFE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707673208; c=relaxed/simple; bh=o+Es63rblaiOskqdfysDabP2Mto8970wr7yA9yxs3wQ=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=WDkV7EyKhT6ZXPM0K7PBauviKOO6R+yaGhgUZKvjFMD5gekEudndW2pxi0c+iWYCKKvPeplWNDGfLREeKi029mB96LAKJQSOqjgH9IcSadaBWpPS7bczjeZ0XYB/roRfgImUvgMUBjn2ZxRxQXmkVpuvq7qgCORrJTDFsb7oKa8= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.17.1/8.17.1) with ESMTP id 41BHe4S1052667; Sun, 11 Feb 2024 09:40:04 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) DKIM-Filter: OpenDKIM Filter v2.10.3 troutmask.apl.washington.edu 41BHe4S1052667 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=troutmask.apl.washington.edu; s=troutmask; t=1707673204; bh=o+Es63rblaiOskqdfysDabP2Mto8970wr7yA9yxs3wQ=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=QlxvMzCIJ7FVvmJT0tB3zq5r+C/I3z0/Pf2kKae/NB6aSJIrRyvXqy1OA7GMIyEIA xqqmC0tEitRTOzqAzROYNfEpA856e3CUoI+aP2eIuz9Rlrh5WaZ16FVeVhhhtERHFl ziFhWFgmduE9ZbK9a5ywI45JqZM6UzZqu/itRCMZlb9fORhynOU8/+h5svq3UtxrQn 3q/LkhKWLrzkISW5R6qZk/xiufE6o/QJ7orbMnKLnYEolIANvX2UCs+YwBCP/Q3+EZ Mca+CtbWxcMD0/zhRp8f/6ffl0JKL3OfXZCGgGWyzDtYNov4YSuPdgOC7Uk3GuzW2e NctGyh5rmil8w== Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.17.1/8.17.1/Submit) id 41BHe49L052666; Sun, 11 Feb 2024 09:40:04 -0800 (PST) (envelope-from sgk) Date: Sun, 11 Feb 2024 09:40:04 -0800 From: Steve Kargl To: Mikael Morin Cc: fortran@gcc.gnu.org Subject: Re: Need a hint or more likely help Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,DKIM_INVALID,DKIM_SIGNED,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE,WEIRD_PORT 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: On Sun, Feb 11, 2024 at 11:56:52AM +0100, Mikael Morin wrote: > Hello, > > Le 11/02/2024 à 03:00, Steve Kargl a écrit : > > All, consider this simple code: > > > > module foo > > contains > > subroutine bar > > character(len=:), allocatable :: s(:) > > call bah(s) > > end subroutine bar > > end module foo > > > > If one compiles with -fdump-tree-original, one see (with some pruning) > > > > void bar () > > { > > integer(kind=8) .s; > > struct array01_character(kind=1) s; > > > > The above two lines seem to be ok. > > > > bitsizetype D.4319; > > sizetype D.4320; > > > > try > > { > > D.4319 = (bitsizetype) (sizetype) NON_LVALUE_EXPR <.s> * 8; > > D.4320 = (sizetype) NON_LVALUE_EXPR <.s>; > > s.data = 0B; > > s.dtype = {.elem_len=(unsigned long) .s, .version=0, .rank=1, .type=6}; > > bah ((character(kind=1)[0:][1:.s] * restrict) s.data, .s); > > } > > > > This is bad. .s is undefined. I've trace this to trans-array.cc:11531 > > > > if (sym->ts.type == BT_CHARACTER > > && !INTEGER_CST_P (sym->ts.u.cl->backend_decl)) > > { > > gfc_conv_string_length (sym->ts.u.cl, NULL, &init); > > gfc_trans_vla_type_sizes (sym, &init); > > > > The problem here is that sym->ts.u.cl->length == NULL. If I change > > the conditional to > > > > if (sym->ts.type == BT_CHARACTER > > && sym->ts.u.cl->length > > && !INTEGER_CST_P (sym->ts.u.cl->backend_decl)) > > > No, I think sym->ts.u.cl->length == NULL is correct for deferred length. > It is set only when there is an expression defining the length: > character(len=size(somevar)) :: s(:) Yes, you are correct. I spent some time reading gfc_conv_string_length() and does appear to address the NULL case. > > then the option -fdump-tree-original produces > > > > void bar () > > { > > integer(kind=8) .s; > > struct array01_character(kind=1) s; > > > > try > > { > > s.data = 0B; > > s.dtype = {.elem_len=(unsigned long) .s, .version=0, .rank=1, .type=6}; > > bah ((character(kind=1)[0:][1:.s] * restrict) s.data, .s); > > } > > > > which looks good except I don't know what the reference to .s here > > means. Is this correct or should we set .s to zero by artificially > > setting sym->ts.u.cl->length to, say, zero length? > > > Setting the variable .s to zero should be correct in any case, but it's not > the same as setting the expression. > I think you can use > if (sym->ts.deferred) > gfc_add_modify ( > &init, > sym->ts.u.cl->backend_decl, > build_zero_cst (TREE_TYPE (sym->ts.u.cl->backen_decl)) > ); > to set .s to zero. > > Actually, setting to any value should be correct (including -1), as the > value should not be used as long as the data pointer is NULL. > > What is not clear is whether the values of D.4319 and D.4320 need update > when memory is allocated for s. I think those variables are referenced in > the type of s (but it's not visible in the dump), and may need update when > the value of .s changes. > > I hope it helps. Indeed, the above appears to be the solution. I looked at the first 9 dumps from -fdump-tree-all, and by time we get to a.f90.022t.ssa the temp variables D.4310 and D.4320 seem to be optimized out/reaped. Thanks for the help. I tend to forget how the trans-* files work, and sometimes need a reminder. -- Steve