From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.lisp.guile.devel Subject: more compilation failures: -DSCM_DEBUG_TYPING_STRICTNESS=2 Date: Tue, 1 Sep 2009 00:52:58 -0400 Message-ID: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v936) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1251842476 11271 80.91.229.12 (1 Sep 2009 22:01:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 1 Sep 2009 22:01:16 +0000 (UTC) To: guile-devel Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Sep 02 00:01:05 2009 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MibPU-00081H-ML for guile-devel@m.gmane.org; Wed, 02 Sep 2009 00:01:05 +0200 Original-Received: from localhost ([127.0.0.1]:43988 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MibPU-0005gD-66 for guile-devel@m.gmane.org; Tue, 01 Sep 2009 18:01:04 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MiLMd-0005VE-21 for guile-devel@gnu.org; Tue, 01 Sep 2009 00:53:03 -0400 Original-Received: from [199.232.76.173] (port=36013 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MiLMc-0005UD-DR for guile-devel@gnu.org; Tue, 01 Sep 2009 00:53:02 -0400 Original-Received: from biscayne-one-station.mit.edu ([18.7.7.80]:39142) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MiLMc-0003P7-0A for guile-devel@gnu.org; Tue, 01 Sep 2009 00:53:02 -0400 Original-Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id n814qx5K017067; Tue, 1 Sep 2009 00:52:59 -0400 (EDT) Original-Received: from [10.0.0.172] ([76.119.237.235]) (authenticated bits=0) (User authenticated as raeburn@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id n814qwXN027531 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 1 Sep 2009 00:52:59 -0400 (EDT) X-Mailer: Apple Mail (2.936) X-Scanned-By: MIMEDefang 2.42 X-Spam-Score: 0.00 X-detected-operating-system: by monty-python.gnu.org: Solaris 9 X-Mailman-Approved-At: Tue, 01 Sep 2009 18:00:53 -0400 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:9241 Archived-At: Compiling with SCM_DEBUG_TYPING_STRICTNESS=2 causes SCM to be defined as a union type (though the comments say a struct type), which enhances the type checking by making random conversions and casts to and from pointer and integer types not work without going through the correct conversion macros/functions. Problem is, we're doing some of those. It also means constant values for static initializers ("{ { BITS } }") have a different form from run-time expressions generating certain values ("scm_pack (BITS)" calls an inline function), and comparisons can't be done with "==" and "!=". (In fact, tags.h already says "SCM values can not be compared by using the operator ==", right above the definition of scm_is_eq.) Guess what we're also doing? :-) And I haven't even tried compiling Ludovic's bdw-gc-static-alloc branch yet, just master. I can clean some of this up trivially -- SCM_PACK/SCM_UNPACK as needed, change == to scm_is_eq. The initializers make it slightly less trivial, and I can imagine different courses of action. #1: We continue to not support static initialization. Move most of the initializations in the library to the per-file init functions, and for stuff like the ra_iproc tables in array-map.c we may want *one* internal initializer macro (SCM_I_UNSPECIFIED_INIT or SCM_I_UNDEFINED_INIT? maybe even something zero-valued) for filling in slots in static structures without getting compiler warnings about missing initializers. #1a: Extend #1 later with whatever internal macros are needed to provide the right initialization syntax for constructs used in bdw-gc- static-alloc based on the STRICTNESS setting. #1b: Try to supplement #1 with changes to SCM_PACK or SCM_MAKIFLAG to make it not considered a compile-time constant even with STRICTNESS<2 and thus SCM_UNSPECIFIED, SCM_BOOL_F, etc are never suitable for static initialization, catching this problem earlier in the future. I believe a use of a comma expression will suffice, but finding a form that doesn't generate compiler warnings and doesn't generate run-time code could be tricky. (Though, it becomes easier if we require only no performance impact when optimizing and with ... what, inline function support? gcc?) #1c: Try to supplement #1 by defaulting to STRICTNESS=2 on platforms where the union is passed and returned the same way as the pointer or integer in function calls, and where there isn't a significant performance impact. Probably selected via cpp macros in __scm.h, since an autoconf feature test would be difficult at best, and still specific to the compiler used for building libguile and not the one used to build the application. This helps us avoid the "==" and random casting part of the problem better in the future. Mac OS X (10.5, Intel) seems to use the same calling convention both ways in one simple test, though I haven't tried performance testing. #2: Drop STRICTNESS=2 support and really support static initialization with the current macros. #3: Keep STRICTNESS=2 support, and support static initialization, even for application code, with a bunch of new macros. Thoughts? My preference is for #1 now, and #1a/b/c when convenient or needed. Ken