From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) by sourceware.org (Postfix) with ESMTPS id 646B73858D1E; Tue, 21 Feb 2023 07:31:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 646B73858D1E 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-x231.google.com with SMTP id b18so3411560ljr.4; Mon, 20 Feb 2023 23:31:08 -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=MShV6RFP71428F6MSxFCsy/Y26sneweRVJStl+WS/LE=; b=V27D7ASu/wZtpuYsYYKShUMAYQqyoQW9QeoZkxD83TdSUlEHbVHkvikFCfBecvV045 cp4gP+rGWpT2PKkOYomdy8dP/K96+ioA9w9V0DVPnM47ChwOKvKYulGYoL89FH0dIJA+ ps+Q+7i3m8kN6tkyUAaCTltCTo8fJ1tFUtJHeCHOmRmDFO/fmiQP9Ef0C5alqDEGgzmg HK/fsu+ThgErGQ2wTMAtP4guZpZRZU8zbz3VRU5C96nvzrMQuSgiI7j9rEbIn8N0sA8w X/1MJUy+eEW6BkF1pBu6rCgNB5YLXmqdvY657+wG9NOg9qkMTy3fS8XM1NX/BpeRlHaC M6BQ== 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=MShV6RFP71428F6MSxFCsy/Y26sneweRVJStl+WS/LE=; b=5QGHaWOueEO1mPBoA9ok2tNNccHERiRGkV3RQXLzz/CmKRgIwTpMPHm+XPYdQy8ftJ XNiBb7uqVAmfIJPRS8pKuGhEWwg/mnsX0FgEHqkLh4q9hxjYRN9N9oVQxCqxODLmsijr UYBbLqk6aBjuh89VrZnuCvpKYxRb3ssRvYCPg4XIXdDeWIXcAAHE+y8yKQlnuHFlXe5u yDmBKrJB8svZ+C64pmFLYoAzmR4lcyeOdTVMEpQs8IdEt0G8MzONIWnIL8DVC/zT0Yga K6bKKJE9EX8GKi3ODIyuHSMfVsqVBSCcL9amfFHere3R1UVajkGQLy3PhZqA+68d45/q z2IQ== X-Gm-Message-State: AO0yUKWwYlud756uZvdqxsme/Tu6MUAjJoZibdoTyJ8FM6Lw/83angby 5DrNYYMiooN2BJf89vGl5FjJ/QWqORg7olS/A34= X-Google-Smtp-Source: AK7set8NdP9BykZOZyy3Yrs+Kus09piY4nTxzc/4ru63WmcmcBNoWkG+pI3u1uiqZ7CrPkcnp973/pqwH62NRGUmpE0= X-Received: by 2002:a05:651c:2c7:b0:294:5cfd:b437 with SMTP id f7-20020a05651c02c700b002945cfdb437mr1330896ljo.10.1676964666609; Mon, 20 Feb 2023 23:31:06 -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: Tue, 21 Feb 2023 08:30:50 +0100 Message-ID: Subject: Re: [Patch] Fortran: Avoid SAVE_EXPR for deferred-len char types To: Tobias Burnus Cc: Jakub Jelinek , 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 5:23 PM Tobias Burnus wro= te: > > Hi Richard, hi all, > > On 20.02.23 13:46, Richard Biener wrote: > > + /* 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_LE= N. > > + Caveat: this requires some cleanup throughout the code to cons= istently > > + 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. Not= e > > that there's also canonical type building done in case 'eltype' is not > > canonical itself. > > My feeling is that this is already somewhat broken. Currently, there > is one type per decl as each has its own artificial length variable. > I have no idea how this will be handled in the ME in terms of alias > analysis. And whether shared=3Dfalse makes sense here and what effect > is has. (Probably yes.) > > In principle, > integer(kind=3D8) .str., .str2; > character(kind=3D1)[1:.str] * str; > character(kind=3D1)[1:.str2] * str2; > have the same type and iff .str =3D=3D .str at runtime, they can alias. > Example: > str2 =3D str; > .str2 =3D .str; > > I have no idea how the type analysis currently works (with or without SAV= E_EXPR) > nor what effect shared=3Dfalse has in this case. alias analysis for array types looks only at the element type > > 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? > > I think this mostly helps with access inside the FE of the type 'size =3D > TYPE_SIZE_UNIT(type)', which is used surprisingly often and is often > directly evaluated (i.e. assigned to a temporary). that's what I thought > > Since gimplification will produce the result into a single temporary ag= ain, re-storing the "breakage". > > So, does it_really_ fix things? > > It does seem to fix cases which do 'size =3D TYPE_SIZE_UNIT (type);' in > the front end and then uses this size expression. Thus, there are fixed. > However, there are many cases where things go wrong - with and without > the patch. I keep discovering more and more :-( I guess test coverage isn't too great with this feature then ;) > * * * > > I still think that the proper way is to have NULL_TREE as upper value > would be better in several ways, except that there is (too) much code Yep. > which relies on TYPE_UNIT_SIZE to work. (There are 117 occurrences). > Additionally, there is more code doing assumptions in this area. > > Thus, the question is whether it makes sense as hackish partial solution > or whether it should remain in the current broken stage until it is > fixed properly. I wonder if it makes more sense to individually fix the places using TYPE_UNIT_SIZE in a wrong way? You'd also get only "partial" fixes, but at least those will be true and good? Otherwise I defer to frontend maintainers if they agree to put in a (partially working) hack like this. Richard. > Tobias, > > who would like to have more time for fixing such issues. > > ----------------- > 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