From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ciao.gmane.io (ciao.gmane.io [116.202.254.214]) by sourceware.org (Postfix) with ESMTPS id E89153838F21 for ; Tue, 13 Dec 2022 20:53:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E89153838F21 Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=gmx.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=m.gmane-mx.org Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1p5CHb-0005rI-LR for gcc-patches@gcc.gnu.org; Tue, 13 Dec 2022 21:53:47 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gcc-patches@gcc.gnu.org From: Harald Anlauf Subject: Re: [Patch, Fortran] libgfortran's ISO_Fortran_binding.c: Use GCC11 version for backward-only code [PR108056] Date: Tue, 13 Dec 2022 21:53:40 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1 Content-Language: en-US In-Reply-To: Cc: fortran@gcc.gnu.org X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,KAM_SHORT,NICE_REPLY_A,SPF_HELO_NONE,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: Message-ID: <20221213205340.zVroN5ouP50vUyUZhRsHMRPOoeaz6_MG8BxEDU8zuD8@z> 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 <= 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? > >  * * * > > 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 effective > 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ße 201, > 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: > Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; > Registergericht München, HRB 106955