From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: USE_LSB_TAG and MS-DOS Date: 17 May 2004 12:22:15 -0400 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <2719-Sat15May2004150718+0300-eliz@gnu.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1084814841 17940 80.91.224.253 (17 May 2004 17:27:21 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 17 May 2004 17:27:21 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon May 17 19:27:14 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BPltS-0004yQ-00 for ; Mon, 17 May 2004 19:27:14 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BPltS-0000JL-00 for ; Mon, 17 May 2004 19:27:14 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BPl9S-0000QI-Rf for emacs-devel@quimby.gnus.org; Mon, 17 May 2004 12:39:42 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BPl8e-0000Ow-Bn for emacs-devel@gnu.org; Mon, 17 May 2004 12:38:52 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BPl87-0000Iv-AZ for emacs-devel@gnu.org; Mon, 17 May 2004 12:38:50 -0400 Original-Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BPksc-00068d-76; Mon, 17 May 2004 12:22:18 -0400 Original-Received: from asado.iro.umontreal.ca (asado.iro.umontreal.ca [132.204.24.84]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 4FD5A20D18; Mon, 17 May 2004 12:22:16 -0400 (EDT) Original-Received: by asado.iro.umontreal.ca (Postfix, from userid 20848) id 358828CA23; Mon, 17 May 2004 12:22:16 -0400 (EDT) Original-To: Eli Zaretskii In-Reply-To: Original-Lines: 38 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-0.904, requis 5, BAYES_30 -0.90) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:23590 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:23590 >> Can you compile with ENABLE_CHECKING and try again? >> And give me a backtrace? > Will try to do that soon. > By ``backtrace'' you meant a C-level backtrace inside GDB, yes? Yes. >> After all, all we need is to make sure pointers are multiples of 8. >> GNU malloc guarantees that AFAIK for malloced objects and DECL_ALIGN allows >> to get the same guarantee for static objects, so if we have both the only >> reasonf ro USE_LSB_TAG to fail is a bug, right? > Perhaps so, but, being unsure I know enough about the alignment > issues, I bother. For example, is stack alignment an issue? It shouldn't. The only places where I change the alignemnt are where I use DECL_ALIGN and in pure_alloc. In both cases the alignment should be increased ather than decreased, so it shouldn't cause any problem. Barring any bug, that is (of course). > And what about the default alignment used by GCC for code and data? > I also need to check whether the __attribute__((__align__)) thingy is > supported and does TRT in the DJGPP (a.k.a. MS-DOS) port of GCC. ENABLE_CHECKING should give you those answers pretty quickly since it checks that pointers are properly aligned before tagging them to make Lisp_Objects. > There was also talk about using memalign. I didn't follow that thread > closely, so I don't remember: is that relevant in any way to the case > in point? No, the code is currently not using memalign. The use of memalign would only be for cases where malloc is not known to return multiple-of-8 pointers. Stefan