From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa1.mentor.iphmx.com (esa1.mentor.iphmx.com [68.232.129.153]) by sourceware.org (Postfix) with ESMTPS id 8B5FC3858002; Thu, 22 Jul 2021 07:54:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8B5FC3858002 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com IronPort-SDR: eVW3ijYsthfOqpK2jimwu4QkY2gD/QtEJLDirWPyszRh+fsomqv5uR30WIJ4AK27kbhukPNI9F NF8GaILsOaEazYAwbgIUPaDwilk6v1wGVgMvJSBM42vradtFVu6lMZyzyEPrvzWrNPPqTAUnG9 akYOFol1cws3WK2fIkb39FGNk7SZgfeqCr7kCzR9lQsIwMqn8vlSf1uBPFP9iKY78MYUAnecgs bj2AjgjnPml7oTi9IcCTen/D/OAFRgHryIgUyBZcHk91iKNEyTJ5wqKzABkA+voPmelOCOLsTC Rs12haJRHUymz9Rk21ZH67I3 X-IronPort-AV: E=Sophos;i="5.84,260,1620720000"; d="scan'208";a="66250058" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa1.mentor.iphmx.com with ESMTP; 21 Jul 2021 23:54:29 -0800 IronPort-SDR: avhgNRE2KYq7ydrv+RcRw8cYZyjvt3Rw887pMSgCjEBsB2nG/SNahxdlG224P0mB7GkgKIwCJp Cp8/+/82KQgyf5jxdgV25WP6onLJX8IVj/aMFJ2mC++B2C8RYIk23qB2fTC0qO347g3Pqrj6O8 srMUN2Wfo6dYKqZbsMtS3/eYRyi3ho7faLuBoKb3RtRJY2LkTMuLCk76TMgzM3MWHh2QxOuVg0 7YtiatN3kcPZwAYe5JlIqU26BPE17Kk1ZW2pB3ZYWuZvjM6///OQ/c9Uctx30ALEwddRAC5K/7 JdE= Subject: Re: [PATCH, Fortran] [PR libfortran/101317] Bind(c): Improve error checking in CFI_* functions To: Sandra Loosemore , "fortran@gcc.gnu.org" , "gcc-patches@gcc.gnu.org" References: <8fc3b97c-b122-9c2c-4657-4f98cf82973e@codesourcery.com> <1fd11074-9c32-37a6-a957-3fe3e329eb9e@codesourcery.com> From: Tobias Burnus Message-ID: Date: Thu, 22 Jul 2021 09:54:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <1fd11074-9c32-37a6-a957-3fe3e329eb9e@codesourcery.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_SHORT, NICE_REPLY_A, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2021 07:54:31 -0000 Hi Sandra, On 21.07.21 20:01, Sandra Loosemore wrote: > Hmmm. CFI_establish explicitly says that the elem_len has to be > greater than zero. It seems somewhat confusing that it's inconsistent > with the other functions that take an elem_len argument. Congratulation =E2=80=93 we have found a bug in the spec, which is also present in the current draft (21-007). I have now written to J3: https://mailman.j3-fortran.org/pipermail/j3/2021-July/013189.html > Ha! I noticed the same thing and already posted a separate patch for > that. :-P > https://gcc.gnu.org/pipermail/fortran/2021-July/056243.html :-) >> How about PRIiPTR + ptrdiff_t instead of %d + (int) cast? At least as >> positive value, extent may exceed INT_MAX. > Hmmm, there are similar problems in existing code in other functions > in this file (e.g., CFI_section). I think that you could fix as well. At least for size(array), it is not uncommon that this exceeds MAX_INT. On the other hand, I think it is unlikely to occur for a single dimension (=E2=86=92 extent). In particular, the most likely way to get a negative value is doing 'int' calculations with an overflow =E2=80=93 and t= hen assigning the result "array->dim[i].extent". But in that case, that (possibly negative) value fits into an int by construction. >>> + if (source->attribute =3D=3D CFI_attribute_other >>> + && source->rank > 0 >>> + && source->dim[source->rank - 1].extent =3D=3D -1) >>> + { >>> + fprintf (stderr, "CFI_setpointer: The source is a " >>> + "nonallocatable nonpointer object that is an " >>> + "assumed-size array.\n"); >> >> I think you could just check for assumed rank =E2=80=93 without >> CFI_attribute_other in the 'if' and 'nonallocatable nonpointer' in >> the error message. Only nonallocatable nonpointer variables can be of >> assumed size (in Fortran); I think that makes the message simpler >> (focusing on the issue) and if the C user passes an >> allocatable/pointer, which is assumed rank, it is also a bug. > > The wording of the message reflects the language of the standard: > "source shall be a null pointer or the address of a C descriptor for > an allocated allocatable object, a data pointer object, or a > nonallocatable nonpointer data object that is not an assumed-size array. I know =E2=80=93 but the wording is such that it permits all 'nonallocatabl= e nonpointer data object' =E2=80=93 with one exception. This does not mean that 'assumed-size array' is only invalid for 'nonallocatable nonpointer' =E2=80=93 it is also invalid for allocatables/pointers. The latter cannot occur for Fortran code as only deferred-shape arrays are permitted in that case, but from the C side, you can easily set it to the wrong value. Thus, by simplifying the wording, the error message is clearer (directly pointing to the issue) and it additionally catches another wrong use of the array descriptor, which can be (only) triggered from C. Tobias ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstra=C3=9Fe 201= , 80634 M=C3=BCnchen; Gesellschaft mit beschr=C3=A4nkter Haftung; Gesch=C3= =A4ftsf=C3=BChrer: Thomas Heurung, Frank Th=C3=BCrauf; Sitz der Gesellschaf= t: M=C3=BCnchen; Registergericht M=C3=BCnchen, HRB 106955