From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.smtpout.orange.fr (smtp-26.smtpout.orange.fr [80.12.242.26]) by sourceware.org (Postfix) with ESMTPS id 9CAED3858D28 for ; Fri, 3 Mar 2023 21:24:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9CAED3858D28 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orange.fr Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=orange.fr Received: from [192.168.1.16] ([86.215.161.51]) by smtp.orange.fr with ESMTPA id YCsppYUpClnofYCsvpZVrh; Fri, 03 Mar 2023 22:24:16 +0100 X-ME-Helo: [192.168.1.16] X-ME-Auth: bW9yaW4tbWlrYWVsQG9yYW5nZS5mcg== X-ME-Date: Fri, 03 Mar 2023 22:24:16 +0100 X-ME-IP: 86.215.161.51 Message-ID: <5b42f0b7-e217-555d-b1f2-4b623f3ae150@orange.fr> Date: Fri, 3 Mar 2023 22:24:07 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.2 From: Mikael Morin Subject: Re: [PATCH] Fortran: fix CLASS attribute handling [PR106856] To: sgk@troutmask.apl.washington.edu, Harald Anlauf via Fortran Cc: gcc-patches , tobias@codesourcery.com References: Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00,FREEMAIL_FROM,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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.