From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by sourceware.org (Postfix) with ESMTPS id EB52B3838F0C; Tue, 13 Dec 2022 20:53:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EB52B3838F0C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmx.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmx.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1670964821; bh=C2P7Ii17IBOyGDnYqAoFMMwyndvWePDCfmwbkNBd/8E=; h=X-UI-Sender-Class:Date:Subject:To:References:From:In-Reply-To; b=LyEdLQbQ5So9YJrERaPiV75E5MLCKyzc49BLCkvMVXuCeaN10wHGagKlOp60rpfP4 VLmkwTBlmRHWz/YdekA3oHiFDyO67g1MjwLEwNwSZpp4UIsTtpAej0OqK08RDIYDZ+ c0/zo4KHB33Ewv+FxD1naY3BAhu7YlGub8ZZuZ9joxcbak5NQ6mwfYU6Cslip3sRZH vst93spMYaROVbLyW85M0/XW5WpRY+Qyr+vudOO8iw2CTEal53eufNL+T9OWVfnBag vfgmISfiIYUP1ElnlH6PvEWDpfUTI6OBti4IwUBQ9Drsa+oEn0YA6Nibw6Xtt0FUeu 4LzXtPeTqy4Bw== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from [192.168.178.29] ([93.207.80.163]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1McpNo-1oWPUl3Joo-00ZxTG; Tue, 13 Dec 2022 21:53:41 +0100 Message-ID: Date: Tue, 13 Dec 2022 21:53:40 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1 Subject: Re: [Patch, Fortran] libgfortran's ISO_Fortran_binding.c: Use GCC11 version for backward-only code [PR108056] Content-Language: en-US To: Tobias Burnus , gcc-patches , fortran Newsgroups: gmane.comp.gcc.patches,gmane.comp.gcc.fortran References: From: Harald Anlauf In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:iq/REgyIB/wE6/Ka2wJtGqFIKjBObz6JT3MnThRJi8UGJyz1mj8 F0yo65HQI5VJjDTAndUI69xBfGRgLaLrjO09OTxOo0gI7W5RWIwKh0AH9LODKvR+pY9ENn1 bkDf02zVT/iMGnicV+6luSfGtA6qz9OsWQpdZdg2rHAwcvujAEVgCXRn1Kza7cOMIyIx8ZX bj84RnuSMgqPp9/CGwByw== UI-OutboundReport: notjunk:1;M01:P0:TqB8Lp1ls34=;+PgCkVaa2zHbLuWMPdlXo/9wnqg 7GYzSNROAVgm95ncDJ5cJKz4VHMJ2KSSkgdrynn1O6WsgMGs3tgtUWTlQlR7A3+1iQv4jsjsY KmAgVIeNyeHNiWERywi3x1ZOEwYhU5z3kobi5vT86qvVf+sfMAeSJEm2SmxLeYBFKLn7KrAOZ 8TFJac71ISG0Lo6AyIy0uuze2CrCopAP2vdLLI+kCuUvscFrxlslp+S1RhTJxUR80wzwmAwxY RXKghigfmouBspcaQkOSyINBV+Kmu+kKroHNvlFk5NI2ewfKQ48vFOiEjjZsVwOmr4aLmZuxn 0DgqSNMcxqiI/Q18JLBny9oxdGTYa2tAI1ThnTjQoFz67ptEIQOdqeQP8OfkiL72Vnx6t2vWg FmKP443znLjoSSlwSYR/7RgofDcaj3ZbFj4aEtygT/PE3zowYWSaAWEd8I91OFHW4qztNL/Df NQicXbB3IHVAPMNVKOORcOtup3l0vAkC85pah32HGnP/V0CGv0IeA9/esG6evQ5s3iXBBrkfg tTmetKyJuYf6MLmxISQPf9oF8COzRbZh77JUS1cRE3BgMsk0YrcBCkV8Y25TtTNI88IfMpoeE kxWtzQUIFPG9vBOnoHe904ydVUmEuyVhsNZNEk+BacwgvlsWfUOqSQwuZSmLbgpXTrjYIqY+B YUU5nck2SvG4P64R5YyMNqiA0p7PESSbBQEpOhK1nUl5EaWRlw+3dQfQBz400JRXTopXBrKy9 fb19T6/var+HuzK4SDNstEUmMD2NgKBMOqwEicsZ0SAsV8YQOeDX0vlk4WCwvifjiMOn6lrPT 0oIVzIRXw1DfkdDDRmlJtxiJu2ovxLk2zsdl8iMWG2T+p8i52gDaA7cww0jmuEoOZSyXtIYb/ Fny2EgQBJGRRSQxtzIZ93+lhH6VK4SS6vJHp529y1ajDfZ5GQFkAgus38+OvZcUrbkN3F16Aj 1sQHj4/vyzZylVMKWUKA3TdyVBA= X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,NICE_REPLY_A,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Tobias, Am 13.12.22 um 17:29 schrieb Tobias Burnus: > This is a 12/13 regression as come changes to fix the GFC/CFI descriptor > that went into GCC 12 fail with the (bogus) descriptor passed via by a > GCC-11-compiled program. > > As later GCC 12 changes moved the descriptor to the front end, those > functions are only in libgomp.so to cater for old program. Richard > suggested in the PR that the best way is to move to the GCC 11 version, > such that libgfortran.so won't regress. that appears to be the most reasonable & practical way to go. > I now did so - except for three fixes (cf. changelog). See also > PR: https://gcc.gnu.org/PR108056 > > There is no testcase as it needs to be compiled by GCC <=3D 11 and then > run with linking (dynamically) to a GCC 12 or 13 libgfortran. I've verified that the testcase in the PR does not crash with the re-modified libgfortran. I've looked at the resulting ISO_Fortran_binding.c vs. the 11-branch version and am still trying to understand the resulting differences in the code, in what respect they might be relevant or not. Given that this is a somewhat delicate situation we're in, is there a set of tests that I could run *manually* (i.e. compile with gcc-11 and link with gcc-12/13) to verify that this best-effort fix should be good enough for the common user? Just a suggestion of a few "randomly" chosen tests? > OK for mainline and GCC 12? > > =C2=A0* * * > > Note: It is strongly recommended to use GCC 12 (or 13) with > array-descriptor > C interop as many issues were fixed. Like for the testcase in the PR; in > GCC 11 > the type arriving in libgomp is BT_ASSUME ('type(*)'). But as the effect= ive > argument is passed as array descriptor through out, the 'float' > (real(4)) type > info is actually preservable (as GCC 12 cf. testcase of comment 0 and my > comment > in the PR for the C part of the testcase).(*) Well, in the real world there are larger installations with large software stacks, and it is easier said to "compile each component with the same compiler version" than done... (I've just had another personal experience during my daytime job.) Thanks for your effort so far! Harald > Tobias > > ((*) This is not possible if using a scalar 'type(*)' or a > non-array-descriptor > array in between. I think GCC 12 uses 'CFI_other' in the > information-is-lost case.) > ----------------- > 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 Gesellschaft: M=C3=BCnchen; > Registergericht M=C3=BCnchen, HRB 106955