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 759903858D20; Thu, 28 Sep 2023 11:00:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 759903858D20 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com X-CSE-ConnectionGUID: cTcCQXxSR/+dpZgW1ZkVRw== X-CSE-MsgGUID: LE7NgDybTvi5daZaydtGcg== X-IronPort-AV: E=Sophos;i="6.03,183,1694764800"; d="scan'208";a="20405423" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa1.mentor.iphmx.com with ESMTP; 28 Sep 2023 03:00:47 -0800 IronPort-SDR: ii5qjKxdn6UeI9WrTOHSKg3L1VhYsi7d6dlJCYLXWew40BtVyJmhaCkuNQDDYgU4/Z/DRGuO5J F71rv6NKhKj+BVamGnQJKRsnoWMu9hh+80ZGDSELob8T22dzlMI59dS2wx5hnCk0/IvZ2tBvne bQNsaf8iRoD0tAMByVX3NtC7DzqldN0r0gZ4G8F3s81Lfs2A6sBwVN8L3mOqe6/AdUAyvrw/Hd smoZA2tn7JSppGuCtEmLtreKkVpZjQ6a/VG5DRqRiciva11UWNH6EsRa0D9EfdfXo8DJfh2IxX 4Qw= Message-ID: <646f6454-8619-42cf-915a-4ffff01eb5b6@codesourcery.com> Date: Thu, 28 Sep 2023 13:00:41 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Test with an lto-build of libgfortran. Content-Language: en-US To: Jakub Jelinek CC: Richard Biener , Thomas Koenig , Toon Moene , gfortran , Jeff Law , gcc-patches References: <9e347fa4-1940-46c6-a5c9-899cf5a7ae85@moene.org> From: Tobias Burnus In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-15.mgc.mentorg.com (139.181.222.15) To svr-ies-mbx-12.mgc.mentorg.com (139.181.222.12) X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,KAM_SHORT,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: (replace gcc@ by gcc-patches@; see https://gcc.gnu.org/pipermail/gcc/2023-September/242591.html and other emails in that thread) On 28.09.23 11:51, Jakub Jelinek wrote: > On Thu, Sep 28, 2023 at 09:29:02AM +0200, Tobias Burnus wrote: >> On 28.09.23 08:25, Richard Biener via Fortran wrote: >> >>> This particular place in libgfortran has >>> >>> /* write_z, which calls xtoa_big, is called from transfer.c, >>> formatted_transfer_scalar_write. There it is passed the kind as >>> argument, which means a maximum of 16. The buffer is large >>> enough, but the compiler does not know that, so shut up the >>> warning here. */ ... >> I have replaced it now by the assert that "len <=3D 16", i.e. >> + if (len > 16) >> + __builtin_unreachable (); > Is it just that in correct programs len can't be > 16, or that it is real= ly > impossible for it being > 16? I mean, we have that artificial kind 17 fo= r > powerpc which better should be turned into length of 16, but isn't e.g. > _gfortran_transfer_integer etc. My understanding is that kind=3D17 only pops up on PowerPC for REAL variables as they represent __float128 in multiple ways. Having said that, the current call tree is: * xtoa_big: that's where the warning suppression was replaced by the unreachable. * Only caller is 'write_z' with calls it by passing its last argument ('len') as last argument ('len') * "internal_proto(write_z)" implies that it is not called from outside libgfortran. The internal only caller is: * formatted_transfer_scalar_write, which calls it as: case FMT_Z: ... #ifdef HAVE_GFC_REAL_17 if (type =3D=3D BT_REAL && kind =3D=3D 17) kind =3D 16; #endif write_z (dtp, f, p, kind); I am not aware of any logigal/integer/real(+comples)/character kind > 16, except for this PPC one. And complex numbers are pairs of BT_REAL. Thus, I think that patch should be fine - except: > Does anything error earlier if it is larger? I mean, say user calling > _gfortan_transfer_integer by hand with kind 1024? I think this will fail. We have various ways to deal with this in libgfortr= an; I see some cases where the switch "default:" sets the length to 0; we have other places where we use an "assert", I think we have other places were we run into UB. Thus, one option would be to either 'assert(len <=3D 16)' or 'assert((size_t)len < GFC_OTOA_BUF_SIZE - 1)' instead. Or we could handle it as len=3D0 and silently ignore the output or ... I am fine with either of the many options - except that I like something explicit involving 'len' and a comparison (unreachable, assert, regarding a= s len =3D 0) better than the existing warning suppression which is too indirect for me. (Besides: it does not work for LTO.) Preferences? 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