From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.smtpout.orange.fr (smtp-24.smtpout.orange.fr [80.12.242.24]) by sourceware.org (Postfix) with ESMTPS id A13963858D20 for ; Sun, 11 Feb 2024 10:56:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A13963858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=orange.fr Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=orange.fr ARC-Filter: OpenARC Filter v1.0.0 sourceware.org A13963858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=80.12.242.24 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707649022; cv=none; b=k/PyyKT6IpYItWZu28M8hrXhk7g9WO43BxbLwmp46lW/1JElvIj6klE46vY0lGS/OUXNweEwMBX8AyynLhtjuQMEfYXjlu74OJvCIdgLmZLquJRArlFyKId22OZ/KeiTr7GrnH26H01iF8Rhgh9gg9DR0U7lf47NwSfgE8MWPHg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707649022; c=relaxed/simple; bh=3/h7hd0Ibwn0qwJY0OJrB5W9iQkTuH2W5tHdB4c3wjE=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=lkHvKsZQK0MiF0ZzG0WLhAdIrPdNiWmII82jRAqN5/GIV5up+kOoh1mctXvoisa+aPH3a6Y7EPddJb4JXNn9NS0tWNCQuDxzRJMUe8MHCUu78fF3ppDG6oihLlpw9oodGAz0/Wooj94ECGxCpfpWn5hRtqCWhvURnf4OdLksXz4= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from [192.168.1.16] ([86.215.161.51]) by smtp.orange.fr with ESMTPA id Z7VzrWBHUKYLxZ7W5rlsKV; Sun, 11 Feb 2024 11:56:58 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1707649018; bh=EfS43oX2v8O4UheU28BTIUSvR1szwqDiuPCu78bF6P4=; h=Date:Subject:To:References:From:In-Reply-To; b=llM6jxRY4/m9fWcZYcq57vcRkWrnRrHeeax4yytFpUnL7rlzx7JZMrIHUe6Hnpd+a oYE5XZp9l1VOTaCIQ2B43oyUJdTVHBgDBtO+g4iJwswaxGHDxmAX9xuVQcTjuv93nm XyUcAhxuWlZLe8uzvU5/8J7hH8yWc9zGbH1SXWP0WmG82kMXV8Iy4t1AwnHX+mxp8O w0BXPCF5tB+EcSXUAC0WNYi3dYx9nIh7YJ0oFya/IOIigZfKKv5VuJECkIo8dayeAy /chcY0JCkPbwISayNtBNIutX6tRJVJT88gUzQzPd8rPRe8J+5ZsDfIi/TXU65v86BR OP5j94OlA/I/g== X-ME-Helo: [192.168.1.16] X-ME-Auth: bW9yaW4tbWlrYWVsQG9yYW5nZS5mcg== X-ME-Date: Sun, 11 Feb 2024 11:56:58 +0100 X-ME-IP: 86.215.161.51 Message-ID: Date: Sun, 11 Feb 2024 11:56:52 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Need a hint or more likely help To: sgk@troutmask.apl.washington.edu, fortran@gcc.gnu.org References: Content-Language: en-US From: Mikael Morin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE,WEIRD_PORT 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: 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(:) > 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. Mikael