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: a few proposed patches Date: Mon, 21 May 2012 01:45:50 -0400 Message-ID: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1337579173 22492 80.91.229.3 (21 May 2012 05:46:13 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 21 May 2012 05:46:13 +0000 (UTC) To: guile-devel Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon May 21 07:46:13 2012 Return-path: Envelope-to: guile-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 1SWLRc-0008UY-N1 for guile-devel@m.gmane.org; Mon, 21 May 2012 07:46:12 +0200 Original-Received: from localhost ([::1]:42456 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWLRc-00084j-59 for guile-devel@m.gmane.org; Mon, 21 May 2012 01:46:12 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:56007) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWLRY-00084W-Vy for guile-devel@gnu.org; Mon, 21 May 2012 01:46:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SWLRW-0004Jy-VC for guile-devel@gnu.org; Mon, 21 May 2012 01:46:08 -0400 Original-Received: from mail-qc0-f169.google.com ([209.85.216.169]:59550) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWLRW-0004Jn-Qa for guile-devel@gnu.org; Mon, 21 May 2012 01:46:06 -0400 Original-Received: by qcsd16 with SMTP id d16so3586787qcs.0 for ; Sun, 20 May 2012 22:46:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:content-transfer-encoding:date:subject:to :message-id:mime-version:x-mailer:x-gm-message-state; bh=Z0ziqBe8qhxcY1Zkyr6m7rJLpODcX+QwXDs6B4+Lfus=; b=QwAn5HgQpjfMDlMvx44BW0/+5oT78xfiPFEOM7kqTHqOlkrWLB10ba76tbTdYGEMCJ H7eegZZwozS9ZWl/h8ag/0Zgox5HQ6wx+It9CGWuiLhOi4/2X88keHSCvzL3+aPE6qse kYVCopREBZbUodISyN94P3zwcY9oKMvtMIPM/Cy8NYqAXKg1B/01VBIt+Laz8mhV1Z4Z hWPuPRMecbm+dXx6sq5fZ0vli/6whTennniuUmAc5Qm7+YTEpxuiSEVOPIrDWd0AhgTB WHs1cZqh1q1AmlSjaaycx9OiZp7aDaLFd/ML88AFDqyNlJiU9vJAORC3lnJG/TpFYh6o RvkA== Original-Received: by 10.229.69.97 with SMTP id y33mr9182309qci.79.1337579163757; Sun, 20 May 2012 22:46:03 -0700 (PDT) Original-Received: from [10.0.0.158] (c-66-31-202-94.hsd1.ma.comcast.net. [66.31.202.94]) by mx.google.com with ESMTPS id gw2sm37198151qab.10.2012.05.20.22.45.52 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 20 May 2012 22:45:52 -0700 (PDT) X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQnguRdHnUdJlNihfSAwv/j513IroRXpdSvLgAuLt93bdQ0D1fLqs5Aq1g80Yra2gf9Gqy2E X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.216.169 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:14492 Archived-At: After reading the "dynamic ffi and C struct" thread this weekend, I = started thinking, "I wonder if that's really done so as to handle X and = Y and Z, and if we're actually testing it well enough", and got the urge = to do another Mac build, which I hadn't done in a while. After = installing libgc 7.2 to get around flaky failures, and fighting with the = build system a bit (I have gmp installed via Macports, and that tree = also has libgc 7.1=85), and waiting hours for builds to finish and = looking into why, I have a few patches to propose. I've uploaded them = to the branch wip-raeburn-misc for review, since I'm not sure you'll = want to address the issues the same way. * Eliminate use of GC_PTR. Looks like it's a holdover from earlier = versions of libgc. Some versions don't define it, so we do. Apparently = the 7.2 release defines it, too, which resulted in bug #11500. It turns = out, too, that some of the casts weren't quite right (casting to GC_PTR = when GC_PTR* was needed), and only worked because GC_PTR is void* and = thus can be converted to the correct type; I've tried to fix up those = cases. The change discards some minor abstraction of the pointer = interface to libgc, but I don't think we really need an abstract name = for void* anyways. * Don't use addresses of code labels with LLVM, even if the compiler = supports them. At least with the version of LLVM GCC on my Mac ("gcc = version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)"), = the performance seems to be quite poor; "guild compile" was showing = about a 4x penalty in CPU time. (For psyntax-pp.go, it was 10 minutes = of CPU time vs 46 minutes.) Later/future versions may do better, so we = can update it with version-number checks, unless we want to build = performance tests into the configure script, which doesn't sound like a = great idea to me. Related to this, I made two more changes: Always = define statement labels in the VM code anyway, because vm-i-scheme.c = uses some of them unconditionally (which makes me wonder if any non-GCC = configs are getting tested); and report the time taken for each "guild = compile" command during the build. * Require libgc 7.2 or better. Too often the fix to flaky problems = seems to be "try updating to the latest libgc and see if that fixes it", = so let's just require it. Or is 7.1 really *that* consistently reliable = for our use cases on some platforms? I decided to go with a test in the = C code because I was having problems with include directory ordering for = a while on my system, with both 7.1 and 7.2 installed. A configure-time = check would work fine in addition, but the C check takes effect after = the various include directories for gmp, ffi, etc., are added, and using = the order as actually determined in the makefile for compilation, which = the configure script may or may not be consistent with. It would be = nice to catch a version error sooner, though. * Test FFI function calls with signed narrow arguments better -- both = positive and negative values. Currently the Mac port (with libffi = 3.0.10) fails these tests, and I'm not sure where the bug lies. This = just adds more, related failures to the ones we've already got. Let me know if (some of?) these look good and I'll merge them to master, = unless someone else wants to cherry-pick some of the changes first. I've also checked in on master a couple pretty straightforward-looking = fixes. I don't know if either would be applicable to the current = release. One thing still concerns me about the FFI struct size/alignment handling = code. It's written based on some assumptions from the SYSV ABI, and = thus may or may not be correct for other systems not based on that ABI. = But the tests are written in Scheme using the same assumptions; they = should be written to test against the actual C compiler. Otherwise we = may wind up with FFI tests passing but FFI code not actually working. = After the other stuff I've described above, I haven't had time to tackle = this yet=85. Ken=