a few proposed patches

[Ken Raeburn]

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…), 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….

Ken