From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.devel Subject: Re: a few proposed patches Date: Tue, 22 May 2012 10:17:27 +0200 Message-ID: <87k404y6i0.fsf@pobox.com> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1337674681 26562 80.91.229.3 (22 May 2012 08:18:01 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 22 May 2012 08:18:01 +0000 (UTC) Cc: guile-devel To: Ken Raeburn Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue May 22 10:17:58 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 1SWkHu-0006CV-E5 for guile-devel@m.gmane.org; Tue, 22 May 2012 10:17:50 +0200 Original-Received: from localhost ([::1]:53427 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWkHt-0006qk-Tg for guile-devel@m.gmane.org; Tue, 22 May 2012 04:17:49 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:51546) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWkHl-0006pL-FV for guile-devel@gnu.org; Tue, 22 May 2012 04:17:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SWkHd-0005GJ-SQ for guile-devel@gnu.org; Tue, 22 May 2012 04:17:41 -0400 Original-Received: from a-pb-sasl-sd.pobox.com ([74.115.168.62]:58113 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWkHd-0005FV-JL for guile-devel@gnu.org; Tue, 22 May 2012 04:17:33 -0400 Original-Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 0129485F5; Tue, 22 May 2012 04:17:31 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type:content-transfer-encoding; s=sasl; bh=eAURkl3Zr2Wk FaIFMJdAfTuuQ0g=; b=w6Rg/Z31OqL83TpSsFlpKMXnpdUPNFL7sb64w7iD4W9h 68pc9fkb8bpVNowkUM0VOCZRInqfDN1Fch/GfFxjxO/LfM2bNb4gXJbJQjdWi6Rx NZtvIWOe5LNqEzZfqjspVttbjJW8Br/IXJt8s8X7fw26w0gtzq0iEguMS0DwIRc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type:content-transfer-encoding; q=dns; s=sasl; b=NEdbhE k+HTrjzY4v4AH76dVvwGbUNb6aGOMBnM2WqC8fMelwmtcWLKd4TWc6i5DnlU3Zh6 hhPtwFeiS90PZgJnKoSxb1PvPfMdX9RP7zpOedGg4v1tixg4y+OEA0bBZOkptJa7 xWVAqOGJ2Rg8+ED3hETA8+zwSr9LvtkUMi8Ec= Original-Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id EDE8D85EC; Tue, 22 May 2012 04:17:30 -0400 (EDT) Original-Received: from badger (unknown [90.164.198.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 30F0685EB; Tue, 22 May 2012 04:17:30 -0400 (EDT) In-Reply-To: (Ken Raeburn's message of "Mon, 21 May 2012 01:45:50 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) X-Pobox-Relay-ID: 9317FA74-A3E6-11E1-B4EC-E981AF15ED39-02397024!a-pb-sasl-sd.pobox.com X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 74.115.168.62 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:14498 Archived-At: Hi Ken, On Mon 21 May 2012 07:45, Ken Raeburn writes: > * 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. > > * 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. These are related. Until recently, the intention was that 7.1 was the minimum version, though we supported compilation against 6.8, which is the version in Debian stable. As it is, the final 7.2 release was only made a couple weeks ago, which is too new, at least for stable-2.0. On the other hand, requiring 7.2 in master would probably be acceptable. Input from others is appreciated. I think at least for stable-2.0, some more targeted fix can be appropriate. > * 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)"), This is a very old and buggy compiler, AFAIK. Your system might also contain clang, which is probably better, if it works. > the performance seems to be quite poor; "guild compile" was showing > about a 4x penalty in CPU time. Well, in this case it is worth making a change. But can you try with newer clang to see what it does? I'd hate to turn it off for new compilers as well. > * 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. I don't recall what the end result was, but it could have been a bug in a libffi compiled by that libgc. Related: http://news.gmane.org/find-root.php?group=3Dgmane.lisp.guile.bugs&article= =3D5908 http://news.gmane.org/find-root.php?group=3Dgmane.lisp.guile.bugs&article= =3D6142 > 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=E2=80=A6. Good questions, these... Andy --=20 http://wingolog.org/