From: Richard Biener <richard.guenther@gmail.com>
To: Tobias Burnus <tobias@codesourcery.com>
Cc: Jakub Jelinek <jakub@redhat.com>,
sgk@troutmask.apl.washington.edu,
gcc-patches <gcc-patches@gcc.gnu.org>,
fortran <fortran@gcc.gnu.org>,
Paul Richard Thomas <paul.richard.thomas@gmail.com>
Subject: Re: [Patch] Fortran: Avoid SAVE_EXPR for deferred-len char types
Date: Tue, 21 Feb 2023 08:30:50 +0100 [thread overview]
Message-ID: <CAFiYyc2zc0-UG6OexqwZ1UqGc9NvcjkZZWdtbUXdJJgaq-PfaQ@mail.gmail.com> (raw)
In-Reply-To: <fb1010b7-5de8-5af0-1d54-80d76c9224b3@codesourcery.com>
On Mon, Feb 20, 2023 at 5:23 PM Tobias Burnus <tobias@codesourcery.com> wrote:
>
> 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_LEN.
> > + Caveat: this requires some cleanup throughout the code to consistently
> > + use some wrapper function. */
> > + gcc_assert (TREE_CODE (TYPE_SIZE_UNIT (type)) == SAVE_EXPR);
> > + tree tmp = 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.
>
> 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=false makes sense here and what effect
> is has. (Probably yes.)
>
> In principle,
> integer(kind=8) .str., .str2;
> character(kind=1)[1:.str] * str;
> character(kind=1)[1:.str2] * str2;
> have the same type and iff .str == .str at runtime, they can alias.
> Example:
> str2 = str;
> .str2 = .str;
>
> I have no idea how the type analysis currently works (with or without SAVE_EXPR)
> nor what effect shared=false 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 =
> 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 again, re-storing the "breakage".
> > So, does it_really_ fix things?
>
> It does seem to fix cases which do 'size = 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ße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
next prev parent reply other threads:[~2023-02-21 7:31 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-17 11:13 Tobias Burnus
2023-02-17 16:27 ` Steve Kargl
2023-02-20 6:56 ` Tobias Burnus
2023-02-20 7:24 ` Steve Kargl
2023-02-20 10:41 ` Richard Biener
2023-02-20 11:07 ` Tobias Burnus
2023-02-20 11:15 ` Jakub Jelinek
2023-02-20 11:48 ` Tobias Burnus
2023-02-20 11:56 ` Jakub Jelinek
2023-02-20 12:46 ` Richard Biener
2023-02-20 16:23 ` Tobias Burnus
2023-02-21 7:30 ` Richard Biener [this message]
2023-02-21 9:44 ` Jakub Jelinek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAFiYyc2zc0-UG6OexqwZ1UqGc9NvcjkZZWdtbUXdJJgaq-PfaQ@mail.gmail.com \
--to=richard.guenther@gmail.com \
--cc=fortran@gcc.gnu.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=paul.richard.thomas@gmail.com \
--cc=sgk@troutmask.apl.washington.edu \
--cc=tobias@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).