From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings Newsgroups: gmane.emacs.devel Subject: Re: master 37889523278: Add new `swap` macro and use it Date: Sun, 28 Jan 2024 02:22:56 +0000 Message-ID: <37364cd16c3e66d03224@heytings.org> References: <170452579053.27998.16123231327386305897@vcs2.savannah.gnu.org> <20240106072311.28B8FC0034E@vcs2.savannah.gnu.org> <87plye9ahs.fsf@yahoo.com> <83o7dyua0d.fsf@gnu.org> <87le9297ei.fsf@yahoo.com> <87cyue92fx.fsf@yahoo.com> <877ckm8uzz.fsf@yahoo.com> <83v886sgtl.fsf@gnu.org> <4719da9bc2bbcffdb634@heytings.org> <87bk9o1ooo.fsf@yahoo.com> <83cyu4fl4o.fsf@gnu.org> <877ckc1gs9.fsf@yahoo.com> <83a5p8fehd.fsf@gnu.org> <83bk9mepkt.fsf@gnu.org> <9245debeed69c26665f0@heytings.org> <87h6jbwfu4.fsf@yahoo.com> <2f5a5ec4d5c204a5200d@heytings.org> <87il3flbxj.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6230"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , stefankangas@gmail.com, emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jan 28 03:23:51 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rTupq-0001PR-D2 for ged-emacs-devel@m.gmane-mx.org; Sun, 28 Jan 2024 03:23:50 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rTup5-0008TC-Ri; Sat, 27 Jan 2024 21:23:03 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rTup4-0008Sz-Ae for emacs-devel@gnu.org; Sat, 27 Jan 2024 21:23:02 -0500 Original-Received: from heytings.org ([95.142.160.155]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rTup2-0006Xh-Dj; Sat, 27 Jan 2024 21:23:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1706408577; bh=KGtj7xMF81JYp/iGl9tf3/6n2g7YtnfI39/jrguxiU8=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=jpMugYTi7QOVJvsMSgtqKzcuwXYOxATe69Bh1a811Ll3JZQJnElMCELIfYXMta+b6 SrPAwEQ3/cQfGhia1yc08RlTdN6oJnBvr1jhHbDEBUY3xXFWRoC8nEzC28XZilF6nu 3pI5fJRFindPzMuZneiwx2BTj6xM/P60PymkxtgeK9+EcymMRfn++CYmsHA0FjUBYd qMTv00q0woNyGMOnGlpOFNjjJnTyM8WbJEshLy7XUtjhXRY8X6QjUEPmA3FUwXXnFB LzFz3PvaKWTm9/LQjhqD8FPbF93YynWg847JzM7sp1DqYCch1Tzso7fHs2hFckwb4m Pdur/Ew8aaIDg== In-Reply-To: <87il3flbxj.fsf@yahoo.com> Received-SPF: pass client-ip=95.142.160.155; envelope-from=gregory@heytings.org; helo=heytings.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:315510 Archived-At: > > The errors in lisp.h are caused by your building Emacs with 4-byte > longs, hence "CPU". > This is almost becoming funny. You did not even look at the file I attached to my previous post. Of course, why would you do so, with a guiding principle that everyone is wrong? Looking at that file would have saved yourself from throwing more nonsense in this discussion. You would have seen that the error has nothing to do with 4-byte longs. The error is that Sun C 5.8 does not recognize the "alignas" keyword, which is a C11 construct that was introduced unconditionally in Emacs by e32a579975 in July 2012. It was made conditional only ten years later, by 1e2bc1bbf4 in December 2021 (to support builds with older version of TCC). Given that there has been a grand total of zero bug reports from Sun C 5.8 users about this, we can safely conclude that nobody compiled Emacs with Sun C 5.8 between July 2012 and December 2021, that is, Emacs 25 up to and including 28. Both "alignas" and "typeof" are supported by Sun 5.9, released two years after Sun C 5.8, in 2007. > > cc: Sun C 5.8 2005/10/13 > > that is 4 years out of date. Install: > > cc: Sun C 5.8 Patch 121015-07 2009/04/22 > These patches were released two years after Sun C 5.9, which was freely downloadable, at no charge. IOW, in 2009, an up to date Solaris system would have provided Sun C 5.9 for already two years, or even Sun C 5.10, which was released that year. In 2024, an up to date Solaris 10 system provides Sun C 5.11 or above. Your claim has now narrowed down to the following: Sun C 5.8, but only with some patches, and only on 64-bit platforms, can produce a working Emacs 29 build. I will not waste more of my time to check that claim in detail, but FTR I seriously doubt it is: my attempt at building Emacs 29 failed with '"alloc.c", line 692: type of struct member "__b" can not be derived from structure with flexible array member', for which the remedy is, according to a Google search, "upgrade your tools to Oracle Solaris Studio (previously Sun Studio) 12 [that is, Sun C 5.9] or something newer". But, even assuming that your claim is true, given that no-one compiled Emacs 25-28 with Sun C 5.8 in more than ten years, no-one suddenly needs to compile Emacs 29 with that compiler in 2024. Claiming the opposite is beyond absurd. > > The GCC build farm, Paul Eggert, and several other Emacs and Gnulib > developers have and routinely test on up-to-date Solaris 10 systems with > various versions of Sun Studio. For example, > > https://lists.gnu.org/archive/html/bug-gnulib/2023-10/msg00021.html > That link is irrelevant: it's about Gnulib, which is a different project with different constraints and different goals.