From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 5C361385840D for ; Thu, 7 Oct 2021 15:41:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5C361385840D Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-594-C_Lv7j7yPqK5UiTvXQoZrw-1; Thu, 07 Oct 2021 11:40:56 -0400 X-MC-Unique: C_Lv7j7yPqK5UiTvXQoZrw-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 69618B09851; Thu, 7 Oct 2021 15:33:13 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.193.109]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 95F0A8B97B; Thu, 7 Oct 2021 15:33:12 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.16.1/8.16.1) with ESMTPS id 197FX8vG3942546 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 7 Oct 2021 17:33:09 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 197FX7DE3942545; Thu, 7 Oct 2021 17:33:07 +0200 Date: Thu, 7 Oct 2021 17:33:06 +0200 From: Jakub Jelinek To: Michael Meissner , Thomas Koenig , fortran@gcc.gnu.org, gcc@gcc.gnu.org, Tobias Burnus , Segher Boessenkool , David Edelsohn Subject: Re: libgfortran.so SONAME and powerpc64le-linux ABI changes Message-ID: <20211007153306.GY304296@tucnak> Reply-To: Jakub Jelinek References: <20211004100754.GL304296@tucnak> <3dacfdf6-6b23-f307-969a-94265b506edb@netcologne.de> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=unavailable 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@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2021 15:41:02 -0000 On Thu, Oct 07, 2021 at 11:24:35AM -0400, Michael Meissner wrote: > On Thu, Oct 07, 2021 at 08:08:21AM +0200, Thomas Koenig wrote: > > On 07.10.21 05:35, Michael Meissner via Fortran wrote: > > > I tried this at one point. There are a lot of hidden assumptions that the kind > > > number is the number of bytes. I'm sure it can be tracked down, but the > > > problem is with these assumptions is you can't prove a negative (i.e. you never > > > know that you've missed some). > > > > So, summing up from the Fortran side, I'd say the best course of action > > is to > > > > - make KIND=16 into IEEE QP > > This is probably the right thing to do. Note, it will effectively mean that > any fortran users on BE systems will no longer be able to use KIND=16. Changing it on powerpc64le-linux doesn't imply we also have to change it for powerpc64-linux, or perhaps can change it later than in GCC 12. > It will also be a compatibility issue if users have code compiled on a LE > system with GCC 11 and earlier with KIND=16, it will not link with GCC 12. libgfortran ABI changed multiple times in the past already, e.g. the so.1 -> so.2 transition in 4.2 so.2 -> so.3 transition in 4.3 so.3 -> so.4 transition in 7 so.4 -> so.5 transition in 8 and users have coped. Jakub