From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/15018 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Kolesa Newsgroups: gmane.linux.lib.musl.general Subject: Re: max_align_t mess on i386 Date: Sat, 14 Dec 2019 19:53:06 +0100 Message-ID: <17b0b2d0-caad-c64a-03b3-023ab2c39652@octaforge.org> References: <20191214181712.GX1666@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="196817"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux ppc64le; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 To: Rich Felker , musl@lists.openwall.com Original-X-From: musl-return-15034-gllmg-musl=m.gmane.org@lists.openwall.com Sat Dec 14 19:53:26 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1igCXc-000p5Q-VA for gllmg-musl@m.gmane.org; Sat, 14 Dec 2019 19:53:25 +0100 Original-Received: (qmail 32346 invoked by uid 550); 14 Dec 2019 18:53:22 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 32328 invoked from network); 14 Dec 2019 18:53:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=octaforge.org; h=subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm2; bh=K 9z7SnUxO8XGvv4DWth3fhj7YoAPviVLDMXmMMum2U8=; b=NFhPPSqln2J/W2ojA wAfg2D0vZ5PKiV4y6H8wmNe+ySmvV1R9ZVFnzR8nE8MmY0fGQJuOa2xZXvAcRbT/ 8zUSDHDKDhYyqkyIjYYZBVgw+h+LZXoXiKj2cNqDEnVSGHBFCJfKmXSXBepjJDVy W1nuqNNFwd99hCA+MkduNwWLwqlC0FbPVOCAOmR9CtWQodYoqXOTncGe6SUmcJyL cz/gxoP9R64RQaf5IaQxVw8sTvdSvLD8GgzZFye8wf6FrbT++45wnhgru3S6B3Zd 3uTG66G6kNpbXipWEsavhV6kbAldmcQJ8wIKrVE7mufQhrN2ptP8tKhjBD1an/3D TEWDw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=K9z7SnUxO8XGvv4DWth3fhj7YoAPviVLDMXmMMum2 U8=; b=Rt3VTdUqAd6TNwTG6D5wBdcxaDtqULCavBMq1ib+F9FWHSXleMQxjmsm6 lpvKIJthMXFnvFqJ++jrgzeFld2zISyarjarb+Pl30dk+F+uhkJQFC4H27rQ1kN1 eqXJaVOcqzj9Nt9Bo/WRrX/Tb4gzaNXhX4phbsmoWmkhFvhERwz6Bwi1DxYE9qk+ UEiKC7Kxplm3xEV5Wh+BKz8437AdY+QZu7baJ7vNiq4PYCSRfM0EBrUpE2bnd7aq iomPcPS/E1tLs9/q/YmNM24j0OEmyI5Eq/8dQ84K2f6NhNLksb0VPIcDd2DejtMA lrI0hvxfXFOorS4o9iEYXeU2nQyJw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvddtuddguddulecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtgfesth ejredttdefjeenucfhrhhomhepffgrnhhivghlucfmohhlvghsrgcuoegurghnihgvlhes ohgtthgrfhhorhhgvgdrohhrgheqnecuffhomhgrihhnpehsohhurhgtvgifrghrvgdroh hrghenucfkphepleegrdduuddvrdduvdekrddukeelnecurfgrrhgrmhepmhgrihhlfhhr ohhmpegurghnihgvlhesohgtthgrfhhorhhgvgdrohhrghenucevlhhushhtvghrufhiii gvpedt X-ME-Proxy: In-Reply-To: <20191214181712.GX1666@brightrain.aerifal.cx> Content-Language: en-US Xref: news.gmane.org gmane.linux.lib.musl.general:15018 Archived-At: On 12/14/19 7:17 PM, Rich Felker wrote: > On Sat, Dec 14, 2019 at 06:51:50PM +0100, Florian Weimer wrote: >> * Rich Felker: >> >>> However, whatever we do with i386, the option of using 8-byte >>> granularity remains open for all the other 32-bit archs, most of which >>> tend to be used with machines far more memory-constrained than i386. >> Note that powerpc has a similar issue, but with long double: >> >> >> >> But perhaps musl follows the old powerpc ABI, where double and long >> double are both binary64 (I have not checked, sorry). > We use the ld64 powerpc ABI. musl doesn't support non-IEEE-semantics > floating point types (stuff like IBM double-double) and quad was not > an option at the time, and if it's even supported now it's messy and > requires very recent tooling. > > BTW I know someone from our community doing both musl and glibc stuff > on powerpc is actually interested in continuing to use the ld64 ABI > (with the old compat symbols) on glibc due to problems with > double-double support in applications. Yes, that would be me. I've been looking into making my distribution use the old ld64 ABI for ppc (64le, 64, 32) but without much success. Technically, I did get it working for most part, thanks to glibc doing asm redirection, but there is still the edge case of people declaring math prototypes manually (which is allowed), which would result in the incorrect symbol being used, unless explicitly linked with -lnldbl_nonshared. So I put this effort on hold for the time being. As far as I know, glibc is going to add support for IEEE754 binary128 format (which distros like Fedora plan to use), which would require introduction of new symbol versions for stuff like math when built in that kind of configuration. However, this is only going to be available on platforms that support VSX (i.e. when built for POWER7 or better). I've been wondering if, while doing that, it would be possible to reintroduce support for the ld64 ABI in glibc, as in, the binary64 symbols would have the same version as the binary128 ones. Perhaps my thinking is wrong, but as I see it, it would mean no compatibility breakage then. Configurations using the IBM long double ABI would keep using their older versions, and configurations built to use the IEEE754 long double would use the newer versions, either binary128 (for VSX platforms) or binary64 (for the others). And that's what I would do as well; switch ppc64le+glibc to IEEE754 binary128, and have all musl variants plus ppc64 and ppc stick with binary64. Florian, since you seem to be familiar with this, would you mind telling me if I'm wrong and if I am, why? And is there any chance of upstream glibc potentially accepting such change? Daniel > > Rich >