public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Mikael Morin <morin-mikael@orange.fr>
To: sgk@troutmask.apl.washington.edu,
	Harald Anlauf via Fortran <fortran@gcc.gnu.org>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>, tobias@codesourcery.com
Subject: Re: [PATCH] Fortran: fix CLASS attribute handling [PR106856]
Date: Fri, 3 Mar 2023 22:24:07 +0100	[thread overview]
Message-ID: <5b42f0b7-e217-555d-b1f2-4b623f3ae150@orange.fr> (raw)
In-Reply-To: <ZAJROLZ2n2gnvin3@troutmask.apl.washington.edu>

Hello,

Le 03/03/2023 à 20:57, Steve Kargl via Fortran a écrit :
> On Thu, Mar 02, 2023 at 11:03:48PM +0100, Harald Anlauf via Fortran wrote:
>> -  if (attr->class_ok)
>> -    /* Class container has already been built.  */
>> +  /* Class container has already been built with same name.  */
>> +  if (attr->class_ok
>> +      && ts->u.derived->components->attr.dimension >= attr->dimension
>> +      && ts->u.derived->components->attr.codimension >= attr->codimension
>> +      && ts->u.derived->components->attr.class_pointer >= attr->pointer
>> +      && ts->u.derived->components->attr.allocatable >= attr->allocatable)
> 
> I suppose I'm a bit confused here.  dimension, codimension,
> pointer and allocatable are 1-bit bitfields in the attr
> struct.  These can have the values 0 and 1, so the above
> conditionals are always true.
> 
as I understand it, they aren't if attr has attributes that aren't 
already set in the class container's first component.
a >= b == !(a < b) and if a and b are boolean-valued, a < b == !a && b.
Admittedly, I haven't tested the logic like Harald has.

> The rest of the patch looks reasonable.  If Tobias has no
> objections or comments, it's ok to commit once the above
> is explained.
> 

I have two comments, one about the handling of as and sym->as, which I 
quite don't understand, but I haven't had time to write something about it.
The other is about this:
> +  else if (sym->ts.type == BT_CLASS
> +	   && sym->ts.u.derived->attr.is_class
> +	   && sym->old_symbol && sym->old_symbol->as == CLASS_DATA (sym)->as)
> +    sym->old_symbol->as = NULL;
Can this be avoided?  The management of symbol versions should not need 
any manual change.  In principle, either the modified symbols are 
committed, or (in case of error) the previous symbols are restored, but 
there shouldn't be any need for restoring a modified previous symbol.

I guess it's a matter of memory management, because 
gfc_build_class_symbol copies the AS pointer to the class descriptor, 
but I think using gfc_copy_array_spec there or adding the condition 
above to free_old_symbol would be preferable.

  parent reply	other threads:[~2023-03-03 21:24 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-02 22:03 Harald Anlauf
2023-03-03 19:57 ` Steve Kargl
2023-03-03 21:17   ` Harald Anlauf
2023-03-03 21:17     ` Harald Anlauf
2023-03-03 21:24   ` Mikael Morin [this message]
2023-03-03 22:18     ` Steve Kargl
2023-03-04 13:56     ` Mikael Morin
2023-03-04 16:02       ` [PATCH, v2] " Harald Anlauf
2023-03-04 16:02       ` Harald Anlauf
2023-03-04 16:02         ` Harald Anlauf
2023-03-04 16:06         ` Harald Anlauf
2023-03-04 16:06           ` Harald Anlauf
2023-03-04 17:09           ` Mikael Morin
2023-03-04 21:20             ` Harald Anlauf
2023-03-04 21:20               ` Harald Anlauf
2023-03-04 22:29               ` Mikael Morin
2023-03-05 20:21                 ` [PATCH, v3] " Harald Anlauf
2023-03-05 20:21                   ` Harald Anlauf

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=5b42f0b7-e217-555d-b1f2-4b623f3ae150@orange.fr \
    --to=morin-mikael@orange.fr \
    --cc=fortran@gcc.gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    --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).