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 0656B385AC0A; Mon, 6 Sep 2021 19:29:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0656B385AC0A 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: +rCKyOORnKrTSUet71amO5b3ah1QeiO32ZQlB0MoLQv8FT/FmgJKpKYTFSZ3F/o1y4chlaZ3RK 7WCNdkoEJD3le6wRG9wwMdt+DZquoRYdxJaUU47dwngNXLFUYnI3WaeaEZyU1ErDGjui2yvJf8 y4OrjUnjKZqAxSuO2ZVhuQqt/2Uc/blQ4HeQpxWxC+zKEGmn1R+cfq0Fs6hf39UkMi1h1MDZUU VHt4dPzRc88bd5BZhQe1idI+/XKhckrCztpCTzNuXOOiJeZRjMs0Ru5QwL/kt2hYPRU29625vB Tnsc4jMYDMH2R/6wkKfq1dFM X-IronPort-AV: E=Sophos;i="5.85,273,1624348800"; d="scan'208";a="68045173" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa1.mentor.iphmx.com with ESMTP; 06 Sep 2021 11:29:21 -0800 IronPort-SDR: 8n1U7x3jofRaR1ostoEf8fRB1Hi24fsz+1XvLaem0ho7fhaUvU7YAXir8O0CqNwnoaXUidSB65 NE9HTBceGUkonUMVj+j6vHYEeMhuvZFyxWWteLAaF0pkIiS4GkR52cc++r6doB1UnqOk1jOM0P c4S7TfL6/gwhf+MCulSM8GA8C/DiGQdZ5yQsiZI4zlhHq8jMbbE3O59ujY3KyQFVR1oZNie+BG iE+90avFq1Ndpgkd1prU4v0qYOUSLhnCnadLkZKxbFaFK8+ca3laaiXuL6jwdktKJ+0ZIiJ5wR a3U= Subject: Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h To: Sandra Loosemore , "fortran@gcc.gnu.org" , "gcc-patches@gcc.gnu.org" References: From: Tobias Burnus Message-ID: <1f470569-df38-f8e1-2c10-7eef17f50c21@codesourcery.com> Date: Mon, 6 Sep 2021 21:29:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: 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-08.mgc.mentorg.com (139.181.222.8) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-6.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: Mon, 06 Sep 2021 19:29:24 -0000 On 19.08.21 04:57, Sandra Loosemore wrote: > This is a follow-up to commit fef67987cf502fe322e92ddce22eea7ac46b4d75: > https://gcc.gnu.org/git/?p=3Dgcc.git;a=3Dcommit;h=3Dfef67987cf502fe322e92= ddce22eea7ac46b4d75 > > > I realized last week that having multilib-specific versions of > ISO_Fortran_binding.h (generated by running the compiler to ask what > kinds it supports) was still broken outside of the test support; the > directory where it's being installed isn't on GCC's normal search > path. It seemed to me that it was better to try to find some other > solution for this problem than to venture down what appears to be a > rat hole. > > I've come up with this patch to return to a single > ISO_Fortran_binding.h file that uses preprocessor magic to identify > the Fortran kind corresponding to the standard C long double type and > the GCC extension types __float128 and int128_t. I haven't attempted > to undo the follow-up patches that fixed in-tree testing; the static > .h file is still copied to the build directory, and it can still be > referenced with <> syntax during testing. > > Any complaints about either the overall strategy here, or the logic to > infer the C type -> kind mapping? Or OK to commit? OK. [I think you need to fix the merge differences due to your https://gcc.gnu.org/g:93b6b2f614eb692d1d8126ec6cb946984a9d01d7 commit (regarding CFI_type_cfunptr) when applying the patch.] I believe that, at some point, we still want to have a multi-lib include directory, e.g. $(libsubdir)/include-multi/, for those include files which have to be split per multi lib (+ update GCC's include search paths). An example would be libgomp's omp.h (=E2=86=92 https://gcc.gnu.org/PR60670). However, that's a separate issue. If that's available, we can then still decide whether the new solution of __... feature tests is sufficient or whether it should be then changed back to multiple include files. In any case, this patch unbreaks https://sourceware.org/PR28183 which is surely a good thing :-) Thanks and sorry for the slow review. Tobias PS: One reason for the slow review was that I initially had planned to include bits of ISO_Fortran_binding.h in the compiler FE for constructing the CFI descriptor. However, the code started to be that convoluted and additional #defines were needed. Thus, I have now simply copied the definitions to gfortran.h + some hard-coded values in trans-type.c, where the CFI type is constructed. =E2=80=93 Thus, you patch = does not interfere with my CFI patch =E2=86=92 https://gcc.gnu.org/pipermail/gcc-patches/2021-September/578904.html ----------------- 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