From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#11604: USE_LISP_UNION_TYPE + USE_LSB_TAG cleanup. Date: Sat, 02 Jun 2012 10:31:19 +0300 Message-ID: <83k3zqcgqg.fsf@gnu.org> References: <4FC9522B.7050302@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: dough.gmane.org 1338622345 27919 80.91.229.3 (2 Jun 2012 07:32:25 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 2 Jun 2012 07:32:25 +0000 (UTC) Cc: 11604@debbugs.gnu.org To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jun 02 09:32:24 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1Saiow-0000Iq-SW for geb-bug-gnu-emacs@m.gmane.org; Sat, 02 Jun 2012 09:32:23 +0200 Original-Received: from localhost ([::1]:50729 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Saiow-0005nG-FR for geb-bug-gnu-emacs@m.gmane.org; Sat, 02 Jun 2012 03:32:22 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:47261) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Saiot-0005mp-U2 for bug-gnu-emacs@gnu.org; Sat, 02 Jun 2012 03:32:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Saios-00078j-1B for bug-gnu-emacs@gnu.org; Sat, 02 Jun 2012 03:32:19 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:44811) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Saior-00078f-TY for bug-gnu-emacs@gnu.org; Sat, 02 Jun 2012 03:32:17 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1SaiqX-0002Vb-R3 for bug-gnu-emacs@gnu.org; Sat, 02 Jun 2012 03:34:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 Jun 2012 07:34:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11604 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 11604-submit@debbugs.gnu.org id=B11604.13386223979582 (code B ref 11604); Sat, 02 Jun 2012 07:34:01 +0000 Original-Received: (at 11604) by debbugs.gnu.org; 2 Jun 2012 07:33:17 +0000 Original-Received: from localhost ([127.0.0.1]:54356 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Saipo-0002UU-Sq for submit@debbugs.gnu.org; Sat, 02 Jun 2012 03:33:17 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:54481) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Saipm-0002UG-A4 for 11604@debbugs.gnu.org; Sat, 02 Jun 2012 03:33:15 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0M4Z00700BIMEB00@a-mtaout21.012.net.il> for 11604@debbugs.gnu.org; Sat, 02 Jun 2012 10:31:23 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.210.75]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M4Z0071FBKA8ZB0@a-mtaout21.012.net.il>; Sat, 02 Jun 2012 10:31:23 +0300 (IDT) In-reply-to: <4FC9522B.7050302@cs.ucla.edu> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:60621 Archived-At: > Date: Fri, 01 Jun 2012 16:37:15 -0700 > From: Paul Eggert > > Tags: patch > > Here's a patch I'd like to install into the trunk soon, after testing > it on a few more platforms. It follows up on a recent discussion in > emacs-devel. Could you please explain this part: > + * w32heap.c (allocate_heap, init_heap): > + Pay no attention to USE_LISP_UNION_TYPE, as it's irrelevant here. In what way is it "irrelevant here"? Your changes don't remove USE_LISP_UNION_TYPE, do they? And using the union still limits the address space, doesn't it? Also, why did you change DECL_ALIGN to DCL_ALIGN? was something wrong with the previous name? The log entry doesn't mention this change, and the rest of lisp.h that uses DECL_ALIGN was not modified. Will this even compile? Re this: > + (union Lisp_Object): Don't worry about WORDS_BIGENDIAN; the > + code works fine either way, and efficiency is not a concern here. why isn't efficiency a concern? Re this: > + (LISP_MAKE_RVALUE, make_number) [USE_LISP_UNION_TYPE]: > + Use an inline function on all platforms, since this is simpler and > + 'static inline' (via gnulib) is portable now. I still see one instance of LISP_MAKE_RVALUE as a macro in lisp.h: > @@ -404,6 +373,7 @@ > > typedef EMACS_INT Lisp_Object; > #define LISP_MAKE_RVALUE(o) (0+(o)) > +#define LISP_INITIALLY_ZERO 0 > #endif /* USE_LISP_UNION_TYPE */ Also, which parts of gnulib make 'static inline' portable? If it isn't in a part that is used by the MS-Windows port, the MSVC build is still being screwed by these changes. The following changes are not mentioned in the log entry: > # define XSET(var, vartype, ptr) \ > - (eassert ((((uintptr_t) (ptr)) & ((1 << GCTYPEBITS) - 1)) == 0), \ > - (var).u.val = ((uintptr_t) (ptr)) >> GCTYPEBITS, \ > - (var).u.type = ((char) (vartype))) > + (eassert (((uintptr_t) (ptr) & ((1 << GCTYPEBITS) - 1)) == 0), \ > + (var).u.val = (uintptr_t) (ptr) >> GCTYPEBITS, \ > + (var).u.type = (vartype)) > > /* Some versions of gcc seem to consider the bitfield width when issuing > the "cast to pointer from integer of different size" warning, so the > @@ -563,7 +533,7 @@ > # define XSETFASTINT(a, b) ((a).i = (b)) > > # define XSET(var, vartype, ptr) \ > - (((var).s.val = ((intptr_t) (ptr))), ((var).s.type = ((char) (vartype)))) > + ((var).s.val = (intptr_t) (ptr), (var).s.type = (vartype)) What was the reason for removing this comment: > --- src/frame.c 2012-06-01 03:41:03 +0000 > +++ src/frame.c 2012-06-01 23:34:07 +0000 > @@ -1152,10 +1152,6 @@ > described for Fdelete_frame. */ > Lisp_Object > delete_frame (Lisp_Object frame, Lisp_Object force) > - /* If we use `register' here, gcc-4.0.2 on amd64 using > - -DUSE_LISP_UNION_TYPE complains further down that we're getting the > - address of `force'. Go figure. */ > - > { > struct frame *f; > struct frame *sf = SELECTED_FRAME (); ? It is again not mentioned in the log entry. Thanks.