From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 78AE33858C2C; Tue, 23 Jan 2024 10:54:59 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 78AE33858C2C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1706007299; bh=NDhMWXhY/buk1aX5YzpJA65q2HWMK2gMFnYoiz89q+g=; h=From:To:Subject:Date:In-Reply-To:References:From; b=vCF+o7eDuAjzE6CXY5eMDzbBCun7Es8B6bGnKcfpk6dqQnb2FM7upLE8/XVHCH38N rKt4TOhEIsqK2H8SAScwXBpOrhvxNDWt7sGDepQQF/20WU0W5RAym7NmTVQUVWSAto 4C/ACHuIIqRyjFNyxxmNwZWq2CxoGAQLSAGvgF2s= From: "gaiusmod2 at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug modula2/113511] lack of libm2 ABI compatibility on powerpc platforms Date: Tue, 23 Jan 2024 10:54:58 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: modula2 X-Bugzilla-Version: 14.0 X-Bugzilla-Keywords: ABI X-Bugzilla-Severity: normal X-Bugzilla-Who: gaiusmod2 at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: gaius at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D113511 --- Comment #2 from gaiusmod2 at gmail dot com --- "rguenth at gcc dot gnu.org" writes: > There's also the question on compatibility to libgm2 from GCC 13. indeed - I guess the -mabi could be retained for backward compatibility. > I suppose the frontend could simply not allow changing the M2 language > "long double" (however it is called) with -mabi=3D... (which really only > change the C language ABI!). Of course calls to libm are subject to the > C language ABI. ok yes. So m2's longreal data type uses ieeelongdouble throughout by default on powerpc - that would be clean. In principle could all the C interface from m2 code convert the longreal representation to glibc long double and visa versa? So for example in the case of libm.def change libm.def from a DEFINITION FOR "C" to an ordinary m2 definition module. Introduce libm.c which for non power platforms just passes calls though to C. On powerpc (without an IEEE128 glibc) it will convert __float128 onto the underlying long double representation. > Does the language standard have anything to say here? I suppose there's > no ABI documents for M2 for various targets, so eventually C interoperabi= lity > language in the standard directs at the common sense? It leaves much to be implementation defined :-) The gcc/m2/gm2-libs-iso/LowLong.def provides setMode which could be used to control the behaviour of the above conversions. The size of the set Modes and their meaning is implementation defined. Possibly it might be implemented: Bit 0: issue an error and abort if the underlying long double support in glibc does not match the longreal in m2. Bit 1: issue a single warning if the underlying long double support in glibc does not match the longreal in m2 and then attempt conversion. Bit 2: raise an exception if the underlying long double support in glibc does not match the longreal in m2. Bit 3: raise an exception if the conversion between longreal and glibc C long double representations exceeds range. Bit 4.. More bits to control conversion behaviour. [ as a start ]=