Re: a few proposed patches

[Ken Raeburn]

On May 22, 2012, at 04:17, Andy Wingo wrote:
> 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.

Hm.  Okay.  Most of the advice I remembered seeing was to get the latest alpha 
of 7.something (didn't remember if that was 7.1 or 7.2).  But I thought I also 
ran across bug fixes mentioned as having been added since the alphas, that 
fixed bugs found running Guile.  Maybe it was since 7.1 alphas, I don't recall 
how old the report was, nor whether it was about stable-2.0 or master.  But 
supporting 6.8 seems kind of pointless, if we need 7.1 to function properly.  
And it looks to me like 7.2alpha2, at least, should pass the version test I 
used, and its timestamp is back in 2009.

> On the other hand, requiring 7.2 in master would probably be
> acceptable.  Input from others is appreciated.

It is on master where I was seeing sporadic failures during the build while 
using 7.1, which disappeared around the time I switched to 7.2.

> I think at least for stable-2.0, some more targeted fix can be
> appropriate.

I thought about looking to see if there was some additional version identifier 
(GC_ALPHA_VERSION?) that would distinguish versions that did define GC_PTR from 
those that don't, but since GC_PTR just looked like a holdover in need of 
deletion, it didn't seem worth it.

Is GC_PTR defined as void* in 6.8?  If so, the patch to remove GC_PTR would 
still work.  Though a configure test could probably be written to test whether 
the libgc header defines GC_PTR.

> 
>> * 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.

Hm, it's not what configure picks up by default, but yes, it's there.  I'll 
give it a try when I get a chance.

Ken