[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: a few proposed patches
From: |
Ken Raeburn |
Subject: |
Re: a few proposed patches |
Date: |
Tue, 22 May 2012 12:54:40 -0400 |
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