From: Mikael Morin <morin-mikael@orange.fr>
To: Paul Richard Thomas <paul.richard.thomas@gmail.com>,
Mikael Morin <mikael@gcc.gnu.org>
Cc: fortran@gcc.gnu.org
Subject: Re: [PATCH 00/14] fortran: Use precalculated class container for deallocation [PR110618]
Date: Sun, 16 Jul 2023 19:09:20 +0200 [thread overview]
Message-ID: <9617dfb2-3f03-2311-7ac3-a1e5cebcf06a@orange.fr> (raw)
In-Reply-To: <f0b1ca88-cdac-52a8-b48b-65e84ad51837@orange.fr>
Le 15/07/2023 à 12:08, Mikael Morin a écrit :
> Le 15/07/2023 à 08:11, Paul Richard Thomas via Fortran a écrit :
>> That said, this is a big improvement to the finalization of variable
>> expressions. I can also confirm that the composite patch applies
>> cleanly and regtests without problems. Please either remove or
>> uncomment the line:
>> // gcc_assert (se.pre.head == NULL_TREE && se.post.head == NULL_TREE);
>>
>> I presume that it reflects some case where the assertion failed? If
>> so, it might be prudent to retain the assertion especially in light
>> of:
>> gcc_assert (tmp_se.post.head == NULL_TREE); a bit further down.
>>
> Honestly, I can't really say. I just carried it around unchanged, as it
> was originally, in patch 3/14. By the way, this makes me notice that
> the variable name should have been changed from se to tmp_se.
> As both pre and post blocks are copied to the final code block, I think
> the assertions are not useful and can just be removed.
>
I have had a more in detail look at this commented assert, and it
appears that you are actually the person who commented it out, in
revision r13-6747-gd7caf313525a46f200d7f5db1ba893f853774aee from last march.
Don't you remember any detail about it?
Before that, the assert was present from the start, when the function
was introduced.
Uncommenting it doesn't seem to bring any new testsuite failure, but
again I don't really see what it would protect against.
next prev parent reply other threads:[~2023-07-16 17:09 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-13 8:52 Mikael Morin
2023-07-13 8:52 ` [PATCH 01/14] fortran: Outline final procedure pointer evaluation Mikael Morin
2023-07-13 8:52 ` [PATCH 02/14] fortran: Outline element size evaluation Mikael Morin
2023-07-13 8:52 ` [PATCH 03/14] fortran: Outline data reference descriptor evaluation Mikael Morin
2023-07-13 8:52 ` [PATCH 04/14] fortran: Inline gfc_build_final_call Mikael Morin
2023-07-13 8:52 ` [PATCH 05/14] fortran: Add missing cleanup blocks Mikael Morin
2023-07-13 8:52 ` [PATCH 06/14] fortran: Reuse final procedure pointer expression Mikael Morin
2023-07-13 8:52 ` [PATCH 07/14] fortran: Push element size expression generation close to its usage Mikael Morin
2023-07-13 8:52 ` [PATCH 08/14] fortran: Push final procedure expr gen close to its one usage Mikael Morin
2023-07-13 8:52 ` [PATCH 09/14] fortran: Inline variable definition Mikael Morin
2023-07-13 8:52 ` [PATCH 10/14] fortran: Remove redundant argument in get_var_descr Mikael Morin
2023-07-13 8:52 ` [PATCH 11/14] fortran: Outline virtual table pointer evaluation Mikael Morin
2023-07-13 8:52 ` [PATCH 12/14] fortran: Factor scalar descriptor generation Mikael Morin
2023-07-13 8:52 ` [PATCH 13/14] fortran: Use pre-evaluated class container if available [PR110618] Mikael Morin
2023-07-13 8:52 ` [PATCH 14/14] fortran: Pass pre-calculated class container argument [pr110618] Mikael Morin
2023-07-14 5:55 ` Paul Richard Thomas
2023-07-14 7:43 ` Mikael Morin
2023-07-13 18:40 ` [PATCH 00/14] fortran: Use precalculated class container for deallocation [PR110618] Paul Richard Thomas
2023-07-15 6:11 ` Paul Richard Thomas
2023-07-15 10:08 ` Mikael Morin
2023-07-16 17:09 ` Mikael Morin [this message]
2023-07-17 6:12 ` Paul Richard Thomas
2023-07-17 17:43 ` Mikael Morin
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=9617dfb2-3f03-2311-7ac3-a1e5cebcf06a@orange.fr \
--to=morin-mikael@orange.fr \
--cc=fortran@gcc.gnu.org \
--cc=mikael@gcc.gnu.org \
--cc=paul.richard.thomas@gmail.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).