From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) by sourceware.org (Postfix) with ESMTPS id 12E7A3858400; Fri, 8 Oct 2021 19:11:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 12E7A3858400 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=googlemail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=googlemail.com Received: by mail-wr1-x42c.google.com with SMTP id m22so32792597wrb.0; Fri, 08 Oct 2021 12:11:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MX45opjXdPaUHaWtlnIA9cgBjRY1Z3QWLKexkMG17jk=; b=BHW/NMfg7XQPDF5E8ZWtYJXxeF1cBL5MUgJZdP3oQb2Z2/Aoe5406MoUOEduNw5kAg Mt3ZkusuuY6CXUbNzNKOAPD8bGV0b7kz89ARqPhDOD4mtw2KqM2O2lIrjtsCr6s44MUZ 4Y2Z5wmSlVXN4sR4qruLrDlPmHZ3WlKK9Cq1RZyVYxirNLGWeoQwpLS30oNTg41GPbJP g7x5kCrBuzuYOIdnzrwFGMtRtlwmHI1ku//x49jbtQlRqDZSEceHDfKlli/tb3H6EdvN 4mS+W0o7m+K5wUFXbq1nf1zXy7IUL8+bDFP895MPHvFG38o9Ss4UXcokATYtcE+LR+Eu IsdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MX45opjXdPaUHaWtlnIA9cgBjRY1Z3QWLKexkMG17jk=; b=I53jLAWzwCD/2R/yO7ubxwMfE7MkwDjMEPVdzeXw8bbmRe3giMyCEAIGoPCiseyte8 rm+tLCqOSmdapQvxUc1T3LpcJ6Q1wIxRmR1ikWjktnFYBo/mnpTQ0w5kA3OnSMV5zJ0n elHfSRo0oC7zlZxZJpsCRpd0NK7z5EOLSHkgi89ctgyqUPpC5LySo9ZJqMAGWzBt0x5L O6QXt7SQr+gm8l6zsYWDT0GQAGhyymqi8pypF72xnCT5QPeUPAzsmul1sSXOyj9zIyty /BwzDFY+FfNRJtnuohzoC/7GuE8XeAXyzM5nyKWhirTX+4WoILEca4uhbB6rDnUN8zp7 xVSw== X-Gm-Message-State: AOAM532Bn3BsE5+5gkDJt96QIWYymna7FIy44UkS4K05AwO0E6rBi/8N BO/2z5wBSzx63IDsBxZSNT0= X-Google-Smtp-Source: ABdhPJxZW2M7a/xjW2hNU4EQDfrB9SfsI3ObfR/egKdBa9awltRdIMRmON3fypPA7V3eqxHZQSvwEQ== X-Received: by 2002:adf:a1d7:: with SMTP id v23mr6298522wrv.171.1633720263091; Fri, 08 Oct 2021 12:11:03 -0700 (PDT) Received: from [192.168.1.214] (host81-138-1-83.in-addr.btopenworld.com. [81.138.1.83]) by smtp.googlemail.com with ESMTPSA id q12sm177883wrp.75.2021.10.08.12.11.01 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Oct 2021 12:11:02 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Subject: Re: libgfortran.so SONAME and powerpc64le-linux ABI changes From: Iain Sandoe In-Reply-To: <334901cf-72b6-d1d7-dae6-3ec45170cf95@netcologne.de> Date: Fri, 8 Oct 2021 20:11:00 +0100 Cc: Jakub Jelinek , Michael Meissner , fortran@gcc.gnu.org, GCC Development , Tobias Burnus , Segher Boessenkool , David Edelsohn , Paul Thomas Content-Transfer-Encoding: quoted-printable Message-Id: References: <20211004100754.GL304296@tucnak> <3dacfdf6-6b23-f307-969a-94265b506edb@netcologne.de> <20211007153306.GY304296@tucnak> <5533983c-f4d2-5041-75c9-9287e4e31f10@netcologne.de> <749ABCA1-5C3B-4EB8-8E4F-9B967A67AB07@googlemail.com> <334901cf-72b6-d1d7-dae6-3ec45170cf95@netcologne.de> To: Thomas Koenig X-Mailer: Apple Mail (2.3445.104.21) X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, 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@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: Fri, 08 Oct 2021 19:11:08 -0000 Hi Thomas, recognising that this is complex - the intent here is to see if there = are ways to partition the problem (where the pain falls does depend on the = choices made). perhaps: *A library (interface, name) *B compiler internals *C user-facing changes > On 8 Oct 2021, at 17:26, Thomas Koenig wrote: >=20 >> If one wanted to prioritize library SO name stability - then, = perhaps, the >> approach Jonathan mentioned has been used for libstdc++ (add new >> symbols for ieee128 with a different mangling to the existing r/c_16 = ..) >> would be preferable (the FE then has to choose the relevant symbol/ >> mangling depending on target). (A) the points here ^^ are: 1/ the SO name could be left as it is 2/ a target that defaulted to QP routines would still (perhaps under some command line flag be able to use the older implementation). I think both of those could be very helpful to end-users=E2=80=A6 > That's not all that would have to be changed. > Consider >=20 > write (*,*) 1.0_16 > end program >=20 > which is translated (using -fdump-tree-original) to >=20 >=20 > _gfortran_st_write (&dt_parm.0); > { > static real(kind=3D16) C.3873 =3D 1.0e+0; >=20 > _gfortran_transfer_real128_write (&dt_parm.0, &C.3873, 16); > } > _gfortran_st_write_done (&dt_parm.0); >=20 > so we actually pass a separate kind number as well (why, I'm not = sure). > We would have to go through libgfortran with a fine comb to find all > the occurrences. Probably some m4 hackery in iparm.m4 and = ifunction.m4. > So, doable from the library side, if some work. (B) This is the second area of interest, the fact that changes in the = compiler internals would be needed - and those take the time of the volunteers to implement = (believe me, I am painfully aware of how that pressure falls). > Things get interesting for user code, calling a routine compiled > for double double with newer IEEE QP will result in breakage. That would not happen with the proposal above, since the library would have different entry points for the two formats. > We cannot use the KIND number to differentiate, because we must > assume that people have used KIND=3D16 and selected_real_kind(30) > interchangably, and we certainly do not want to nail people to > the old double double precision on hardware for which IEEE QP > is available. =20 you don=E2=80=99t *have* to use the KIND number to differentiate to the = library or the compiler (although some alternate, more flexible, token would have to be = invented). (C) It=E2=80=99s the mapping between that internal token and the = user=E2=80=99s view of the world that needs to be defined in terms of what the combination of platform and = command line flags implies to the treatment of KIND=3DNN and selected_real_kind(). > So, KIND=3D15 for IEEE QP is out. (C) I must confess this kind of change is where things seem very tricky = to me. changing how the language represents things seems to be something that would benefit from agreement between compiler vendors > It's not an easy problem, unfortunately. no. it is not. Iain