From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) by sourceware.org (Postfix) with ESMTPS id CDCA1385781F; Mon, 20 Feb 2023 12:46:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CDCA1385781F 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-x234.google.com with SMTP id a10so1116410ljq.1; Mon, 20 Feb 2023 04:46:57 -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=33Y9oV55quuT7Ch2YbnOR8+wzc31KinDKKgLKOzuchM=; b=XTLfAKxe2rWBcMxnqpY4TdPm+eassPlWJbDS/Sv8ykAcmnFgnuhbwVfbJyAzsA5cSh qEHV9oiRhTIsjc4rsfhSL/tsfAgFWyV/FgsIb9u+G4gcvLxQirwzSAZVSSU3ifVjIijd 3Ur2CaiA8vSHvJB6Cv6I9FU3y2Fj4CZuWisD5IC7YnBCFGG3LjjZT2IQA4af/NaEYr4i x/aHptx6QL8LYBg6Jev2J4sjS6NHIXJuNtcT5nra30RBJTv4FPRKAOo+xlXlUINX6aB8 QVMEXmhz+NaCCL0HRHQam6th8ZWZRKz+PtP3Nwm21AQ5moTsamyj/9M/bQrvuHvgoJv8 +Q2A== 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=33Y9oV55quuT7Ch2YbnOR8+wzc31KinDKKgLKOzuchM=; b=OmZftZovd/ATsfVc3WbmlCfuLjyPirGOX2FWmyh/NHh0tF5dPMVYqXor+QDyO99o1J 5koTGmrgNIITg7rJtLh0uumb98lp4Htg8+cWyJGSt2ySMXwA98q2qSG0fryWD8WlNS7V lS/UiRiDT2z9p5oNoW+eGxidjN/OAv9usnC7oCyrheDS5rYxPDfQLTZbSs0w3okenHj/ 1OcfvUcizHgR7+QzHaXs6pOuMltvuEiY5TiHxNPJR/ATpwofLiZOd/NinEBpe17+1Ki7 46U+DgkIkRnmE7tBc1MIV//1y/2z4Epf6rRqQ+tbXd6o+I9UYeF7YZiI0tEeC1gQHiQr Cv4w== X-Gm-Message-State: AO0yUKXJtPEyZeXvegmN7YEDxNOFtxOs/TDr/x7Erf+XQB4AJjkMyjaa BKEzuBivvGrfzcR/w1j8+5moi0YniMTF8l7uF2I= X-Google-Smtp-Source: AK7set/ojb4eZ+TCBgXTaLKwToGN8qFA93luf2VeGY/FkQ1dxBfg423lbV8Z5mm+XK7HE1zjDwWPEAp/6CkU4PlLO4A= X-Received: by 2002:a05:651c:201a:b0:293:5f96:ac3f with SMTP id s26-20020a05651c201a00b002935f96ac3fmr586723ljo.10.1676897216081; Mon, 20 Feb 2023 04:46:56 -0800 (PST) MIME-Version: 1.0 References: <27cd606a-f019-60b2-a9c8-0a570433b5eb@codesourcery.com> <34e0f9e6-ebb8-ce86-ea11-08b37e5be1f8@codesourcery.com> <8d3fae03-2638-9c6b-eccc-d0a31d1b9733@codesourcery.com> In-Reply-To: From: Richard Biener Date: Mon, 20 Feb 2023 13:46:43 +0100 Message-ID: Subject: Re: [Patch] Fortran: Avoid SAVE_EXPR for deferred-len char types To: Jakub Jelinek Cc: Tobias Burnus , 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.4 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 12:57 PM Jakub Jelinek wrote: > > On Mon, Feb 20, 2023 at 12:48:38PM +0100, Tobias Burnus wrote: > > On 20.02.23 12:15, Jakub Jelinek wrote: > > > On Mon, Feb 20, 2023 at 12:07:43PM +0100, Tobias Burnus wrote: > > > > As mentioned in the TODO for 'deferred', I think we really want > > > > to have NULL as upper value for the domain for the type, but that > > > > requires literally hundred of changes to the compiler, which > > > > I do not want to due during Stage 4, but that are eventually > > > > required.* =E2=80=94 In any case, this patch fixes some of the issu= es > > > > in the meanwhile. > > > Yeah, the actual len can be in some type's lang_specific member. > > > > Actually, I think it should be bound to the DECL and not to the TYPE, > > i.e. lang_decl not type_lang. > > > > I just see that, the latter already has a 'tree stringlen' (for I/O) > > which probably could be reused for this purpose. > > I'd drop the > && TREE_CODE (TYPE_SIZE (type)) =3D=3D SAVE_EXPR > and assert =3D=3D SAVE_EXPR part, with SAVE_EXPRs one never knows if they > are added around the whole expression or say some subexpression has > it and then some trivial arithmetics happens on the SAVE_EXPR tree. > > > > Anyway, for the patch for now, I'd probably instead of stripping > > > SAVE_EXPR overwrite the 2 sizes with newly built expressions. > > > > What I now did. (Unchanged otherwise, except that I now also mention > > GFC_DECL_STRING_LEN in the TODO.) > > > > OK for mainline? > > If Richard doesn't object. tree -gfc_get_character_type_len_for_eltype (tree eltype, tree len) +gfc_get_character_type_len_for_eltype (tree eltype, tree len, bool deferre= d) { tree bounds, type; bounds =3D build_range_type (gfc_charlen_type_node, gfc_index_one_node, = len); type =3D build_array_type (eltype, bounds); TYPE_STRING_FLAG (type) =3D 1; - + if (len && deferred && TREE_CODE (TYPE_SIZE (type)) =3D=3D SAVE_EXPR) + { + /* TODO: A more middle-end friendly alternative would be to use NULL= _TREE + as upper bound and store the value, e.g. as GFC_DECL_STRING_LEN. + Caveat: this requires some cleanup throughout the code to consiste= ntly + use some wrapper function. */ + gcc_assert (TREE_CODE (TYPE_SIZE_UNIT (type)) =3D=3D SAVE_EXPR); + tree tmp =3D TREE_TYPE (TYPE_SIZE (eltype)); ... you are probably breaking type sharing here. You could use build_array_type_1 and pass false for 'shared' to get around that. Note that there's also canonical type building done in case 'eltype' is not canonical itself. The solution to the actual problem is a hack - you are relying on re-evaluation of TYPE_SIZE, and for that, only from within accesses from inside the frontend? Since gimplification will produce the result into a single temporary again, re-storing the "breakage". So, does it _really_ fix things? Richard. > > Jakub >