From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Herbert J. Skuhra" Newsgroups: gmane.emacs.devel Subject: Re: USE_LSB_TAG not supported on this platform Date: Sun, 07 Feb 2016 17:52:43 +0100 Message-ID: <86a8ncmpic.wl-herbert@mailbox.org> References: <86powcjei0.wl-herbert@mailbox.org> <56B3F962.8010203@cs.ucla.edu> <86mvrejegc.wl-herbert@mailbox.org> <56B658E0.6090508@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Trace: ger.gmane.org 1454863998 21541 80.91.229.3 (7 Feb 2016 16:53:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 7 Feb 2016 16:53:18 +0000 (UTC) Cc: emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Feb 07 17:53:08 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aSSaB-0000Qc-Bu for ged-emacs-devel@m.gmane.org; Sun, 07 Feb 2016 17:53:07 +0100 Original-Received: from localhost ([::1]:36264 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aSSaA-0004Eq-Ud for ged-emacs-devel@m.gmane.org; Sun, 07 Feb 2016 11:53:06 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57468) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aSSZv-0004Eg-BY for emacs-devel@gnu.org; Sun, 07 Feb 2016 11:52:52 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aSSZs-0005V1-5J for emacs-devel@gnu.org; Sun, 07 Feb 2016 11:52:51 -0500 Original-Received: from mx2.mailbox.org ([80.241.60.215]:38490) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aSSZr-0005Uv-SW for emacs-devel@gnu.org; Sun, 07 Feb 2016 11:52:48 -0500 Original-Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx2.mailbox.org (Postfix) with ESMTPS id 7E98143583; Sun, 7 Feb 2016 17:52:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mailbox.org; h= content-type:content-type:mime-version:user-agent:references :in-reply-to:subject:subject:from:from:message-id:date:date :received; s=mail20150812; t=1454863965; bh=Oq+yg5eatQPgWYVBKb1y DlZPTfx6aVqXgBuXefjs9cw=; b=bZnPsKx+8K9hCqWqBO+Bztb86LrWGpkkNObJ kGeI8wFNwt1SjDSxt2sxu4IHQ+iSmfo/osRCFJMVuqRa+ywpmzBNhOBEVAEjCQZv egqYRH51jLYqyxiaDKLYVmkShXyR5oQWBJJw3D4N4DaTlglEY0UdzFBtSMC1Lhhd gI4N/wo7W9ar/c+lFu6vh4VeXbyKyxM2a/FPVM2/cXVmNDEUaPMAsuKOKNQLd7WH YYAnefLxQHaniOU8UeQ+hO0GaWD1u7Hw2dd0F+JCHU+tDkkYT78/VvS/ZoiqVDia JglwG1nphvswbwLnWlbFJb7IGUV3/4AG3L5TgEtfUo8ow8OEWw== X-Virus-Scanned: amavisd-new at heinlein-support.de Original-Received: from smtp1.mailbox.org ([80.241.60.240]) by hefe.heinlein-support.de (hefe.heinlein-support.de [91.198.250.172]) (amavisd-new, port 10030) with ESMTP id 2nonM-KFH_uX; Sun, 7 Feb 2016 17:52:45 +0100 (CET) In-Reply-To: <56B658E0.6090508@cs.ucla.edu> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.1 Mule/6.0 (HANACHIRUSATO) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 80.241.60.215 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:199447 Archived-At: On Sat, 06 Feb 2016 21:34:40 +0100, Paul Eggert wrote: > > Herbert J. Skuhra wrote: > > INTPTR_MAX=0x7fffffff > > EMACS_INT_MAX=0x7fffffffffffffffLL > > > > Before the commit mentioned above both are 0x7fffffff. > > Commit d6585a910ed3e9e0e43c093b5fbfeb6d56b703b4 should not have > affected EMACS_INT_MAX, and I don't see how it did. Before this commit I get: (EMACS_INT_MAX=0x7fffffff, INTPTR_MAX=0x7fffffff, NONPOINTER_BITS=0) After this commit: (EMACS_INT_MAX=0x7fffffffffffffffLL, INTPTR_MAX=0x7fffffff, NONPOINTER_BITS=3) I can fix the build by: --- a/configure.ac +++ b/configure.ac @@ -2123,7 +2123,7 @@ esac if test "${system_malloc}" != yes && test "${doug_lea_malloc}" != yes \ && test "${UNEXEC_OBJ}" = unexelf.o && test "${hybrid_malloc}" != no; then - hybrid_malloc=yes + hybrid_malloc=no fi (EMACS_INT_MAX=0x7fffffff, INTPTR_MAX=0x7fffffff, NONPOINTER_BITS=0) This does not work on later master checkouts. > I assume you are not configuring with --with-wide-int, so the reason > EMACS_INT_MAX has that large value is due to the following tests in > src/lisp.h: Enabling "--with-wide-int" does indeed fix the build. (EMACS_INT_MAX=0x7fffffffffffffffLL, INTPTR_MAX=0x7fffffff, NONPOINTER_BITS=3) > Is the value of NONPOINTER_BITS 0 on your platform, or 3? If 0, is > this correct? That is, does malloc ever return a pointer that, when > treated as an integer, is not a multiple of 8? If malloc always > returns a multiple of 8, then we should be able to work around the > problem by setting NONPOINTER_BITS to 0 on your platform. How can I tell? Without "--with-wide-int" I also get EMACS_INT_MAX=0x7fffffffffffffffLL, INTPTR_MAX=0x7fffffff, NONPOINTER_BITS=3 To be able to build master without "--with-wide-int" I have to apply: @@ -73,7 +76,7 @@ DEFINE_GDB_SYMBOL_END (GCTYPEBITS) 2. We know malloc returns a multiple of 8. */ #if (defined alignas \ && (defined GNU_MALLOC || defined DOUG_LEA_MALLOC || defined __GLIBC__ \ - || defined DARWIN_OS || defined __sun || defined __MINGW32__ \ + || defined __FreeBSD__ || defined DARWIN_OS || defined __sun || defined __MINGW32__ \ || defined CYGWIN)) # define NONPOINTER_BITS 0 #else (EMACS_INT_MAX=0x7fffffff, INTPTR_MAX=0x7fffffff, NONPOINTER_BITS=0) -- Herbert