* externally_visible and resoultion file
@ 2010-05-26 16:03 Bingfeng Mei
2010-05-26 16:19 ` Richard Guenther
0 siblings, 1 reply; 12+ messages in thread
From: Bingfeng Mei @ 2010-05-26 16:03 UTC (permalink / raw)
To: gcc; +Cc: Richard Guenther
Hi, Richard,
With resolution file generated by GOLD (or I am going to hack gnu LD), is
externally_visible attribute still needed to annotate those symbols accessed
from non-LTO objects when compiling with -fwhole-program.
In theory, it shouldn't be needed since LTO has all information. But what
about current implementation. I checked relevant source files and can't
get immediate clue.
Thanks,
Bingfeng
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: externally_visible and resoultion file
2010-05-26 16:03 externally_visible and resoultion file Bingfeng Mei
@ 2010-05-26 16:19 ` Richard Guenther
2010-05-27 8:10 ` Jan Hubicka
0 siblings, 1 reply; 12+ messages in thread
From: Richard Guenther @ 2010-05-26 16:19 UTC (permalink / raw)
To: Bingfeng Mei; +Cc: gcc
On Wed, May 26, 2010 at 5:53 PM, Bingfeng Mei <bmei@broadcom.com> wrote:
> Hi, Richard,
> With resolution file generated by GOLD (or I am going to hack gnu LD), is
> externally_visible attribute still needed to annotate those symbols accessed
> from non-LTO objects when compiling with -fwhole-program.
Yes it is. We do not parse the complete resolution file but only the
entries we'll end up reading .o files with LTO information for.
> In theory, it shouldn't be needed since LTO has all information. But what
> about current implementation. I checked relevant source files and can't
> get immediate clue.
The current implementation has no idea of the external references
(though it's probably not too hard to implement).
Richard.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: externally_visible and resoultion file
2010-05-26 16:19 ` Richard Guenther
@ 2010-05-27 8:10 ` Jan Hubicka
2010-06-08 13:48 ` Bingfeng Mei
0 siblings, 1 reply; 12+ messages in thread
From: Jan Hubicka @ 2010-05-27 8:10 UTC (permalink / raw)
To: Richard Guenther; +Cc: Bingfeng Mei, gcc
> On Wed, May 26, 2010 at 5:53 PM, Bingfeng Mei <bmei@broadcom.com> wrote:
> > Hi, Richard,
> > With resolution file generated by GOLD (or I am going to hack gnu LD), Â is
> > externally_visible attribute still needed to annotate those symbols accessed
> > from non-LTO objects when compiling with -fwhole-program.
>
> Yes it is. We do not parse the complete resolution file but only the
> entries we'll end up reading .o files with LTO information for.
>
> > In theory, it shouldn't be needed since LTO has all information. But what
> > about current implementation. I checked relevant source files and can't
> > get immediate clue.
>
> The current implementation has no idea of the external references
> (though it's probably not too hard to implement).
Yep, this is also one of my TODO list items...
Honza
>
> Richard.
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: externally_visible and resoultion file
2010-05-27 8:10 ` Jan Hubicka
@ 2010-06-08 13:48 ` Bingfeng Mei
2010-06-08 14:05 ` Richard Guenther
0 siblings, 1 reply; 12+ messages in thread
From: Bingfeng Mei @ 2010-06-08 13:48 UTC (permalink / raw)
To: Jan Hubicka, Richard Guenther; +Cc: gcc
Hi,
Sorry for coming back to this issue after a while. I am still puzzled
by this. The following are two test files:
a.c
#include <string.h>
#include <stdio.h>
extern int foo(int);
void bar()
{
printf("bar\n");
}
extern int src[], dst[];
int vvvvvv;
int main()
{
int ret;
vvvvvv = 12;
ret = foo(20);
memcpy(dst, src, 100);
return ret + 3;
}
b.c
#include <stdio.h>
int src[100];
int dst[100];
extern int vvvvvv;
extern void bar();
int foo(int c)
{
printf("Hello world: %d\n", c);
bar();
return 1000 + vvvvvv;
}
I compiled with following steps
~/work/install-x86/bin/gcc -flto a.c -O2 -c
~/work/install-x86/bin/gcc b.c -O2 -c
ar cru libb.a b.o
~/work/install-x86/bin/gcc -flto a.o -L. -lb -O2 -fuse-linker-plugin -o f -fwhole-program -save-temps
Since you both mentioned that resolution file is not used to replace externally_visible attribute yet,
I expect there will be link errors regarding both vvvvvv and bar. Somehow, GCC doesn't complain at all.
However, looking at generated assembly code, GCC produces wrong code for calling bar, and vvvvvv is
linked correctly though.
0000000000400510 <foo>:
400510: 48 83 ec 08 sub $0x8,%rsp
400514: 89 fe mov %edi,%esi
400516: 31 c0 xor %eax,%eax
400518: bf 1c 06 40 00 mov $0x40061c,%edi
40051d: e8 56 01 00 00 callq 400678 <printf@plt>
400522: 31 c0 xor %eax,%eax
400524: e8 d7 fa bf ff callq 0 <__fini_array_end> <-------- should call bar.
400529: 8b 05 a1 17 00 00 mov 0x17a1(%rip),%eax # 401cd0 <vvvvvv>
40052f: 48 83 c4 08 add $0x8,%rsp
400533: 05 e8 03 00 00 add $0x3e8,%eax
400538: c3 retq
400539: 0f 1f 80 00 00 00 00 nopl 0x0(%rax)
Is this a bug? GCC should issue warning/error here. Why is vvvvvv linked correctly?
Shouldn't it be treated as static with -fwhile-program and without externally_visible?
My trunk is 160104 by the way.
Thanks,
Bingfeng
> -----Original Message-----
> From: Jan Hubicka [mailto:hubicka@ucw.cz]
> Sent: 27 May 2010 09:04
> To: Richard Guenther
> Cc: Bingfeng Mei; gcc@gcc.gnu.org
> Subject: Re: externally_visible and resoultion file
>
> > On Wed, May 26, 2010 at 5:53 PM, Bingfeng Mei <bmei@broadcom.com>
> wrote:
> > > Hi, Richard,
> > > With resolution file generated by GOLD (or I am going to hack gnu
> LD), is
> > > externally_visible attribute still needed to annotate those symbols
> accessed
> > > from non-LTO objects when compiling with -fwhole-program.
> >
> > Yes it is. We do not parse the complete resolution file but only the
> > entries we'll end up reading .o files with LTO information for.
> >
> > > In theory, it shouldn't be needed since LTO has all information.
> But what
> > > about current implementation. I checked relevant source files and
> can't
> > > get immediate clue.
> >
> > The current implementation has no idea of the external references
> > (though it's probably not too hard to implement).
>
> Yep, this is also one of my TODO list items...
>
> Honza
> >
> > Richard.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: externally_visible and resoultion file
2010-06-08 13:48 ` Bingfeng Mei
@ 2010-06-08 14:05 ` Richard Guenther
2010-06-08 14:22 ` Bingfeng Mei
0 siblings, 1 reply; 12+ messages in thread
From: Richard Guenther @ 2010-06-08 14:05 UTC (permalink / raw)
To: Bingfeng Mei; +Cc: Jan Hubicka, gcc, Cary Coutant
On Tue, Jun 8, 2010 at 3:01 PM, Bingfeng Mei <bmei@broadcom.com> wrote:
> Hi,
> Sorry for coming back to this issue after a while. I am still puzzled
> by this. The following are two test files:
>
> a.c
>
> #include <string.h>
> #include <stdio.h>
> extern int foo(int);
> void bar()
> {
> printf("bar\n");
> }
> extern int src[], dst[];
> int vvvvvv;
> int main()
> {
> int ret;
> vvvvvv = 12;
> ret = foo(20);
> memcpy(dst, src, 100);
> return ret + 3;
> }
>
> b.c
> #include <stdio.h>
> int src[100];
> int dst[100];
> extern int vvvvvv;
> extern void bar();
> int foo(int c)
> {
> printf("Hello world: %d\n", c);
> bar();
> return 1000 + vvvvvv;
> }
>
> I compiled with following steps
> ~/work/install-x86/bin/gcc -flto a.c -O2 -c
> ~/work/install-x86/bin/gcc b.c -O2 -c
> ar cru libb.a b.o
> ~/work/install-x86/bin/gcc -flto a.o -L. -lb -O2 -fuse-linker-plugin -o f -fwhole-program -save-temps
>
> Since you both mentioned that resolution file is not used to replace externally_visible attribute yet,
> I expect there will be link errors regarding both vvvvvv and bar. Somehow, GCC doesn't complain at all.
> However, looking at generated assembly code, GCC produces wrong code for calling bar, and vvvvvv is
> linked correctly though.
>
> 0000000000400510 <foo>:
> 400510: 48 83 ec 08 sub $0x8,%rsp
> 400514: 89 fe mov %edi,%esi
> 400516: 31 c0 xor %eax,%eax
> 400518: bf 1c 06 40 00 mov $0x40061c,%edi
> 40051d: e8 56 01 00 00 callq 400678 <printf@plt>
> 400522: 31 c0 xor %eax,%eax
> 400524: e8 d7 fa bf ff callq 0 <__fini_array_end> <-------- should call bar.
> 400529: 8b 05 a1 17 00 00 mov 0x17a1(%rip),%eax # 401cd0 <vvvvvv>
> 40052f: 48 83 c4 08 add $0x8,%rsp
> 400533: 05 e8 03 00 00 add $0x3e8,%eax
> 400538: c3 retq
> 400539: 0f 1f 80 00 00 00 00 nopl 0x0(%rax)
>
> Is this a bug? GCC should issue warning/error here. Why is vvvvvv linked correctly?
> Shouldn't it be treated as static with -fwhile-program and without externally_visible?
bar should be indeed eliminated which is what I see with not
using the linker plugin.
If you use the linker-plugin I see in the .optimized dump that
the were eliminated. But it seems that gold picks them up
from the original objects which seem to be retained somehow.
I guess this is a bug in the linker-plugin.
Richard.
> My trunk is 160104 by the way.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: externally_visible and resoultion file
2010-06-08 14:22 ` Bingfeng Mei
@ 2010-06-08 14:22 ` Richard Guenther
2010-06-08 14:58 ` Bingfeng Mei
0 siblings, 1 reply; 12+ messages in thread
From: Richard Guenther @ 2010-06-08 14:22 UTC (permalink / raw)
To: Bingfeng Mei; +Cc: Jan Hubicka, gcc, Cary Coutant
On Tue, Jun 8, 2010 at 4:15 PM, Bingfeng Mei <bmei@broadcom.com> wrote:
> Thanks. But why "vvvvv" is linked correctly here? Shouldn't it
> be treated as static with -fwhole-program?
Works for me without the linker plugin as well:
> gcc-4.5 -O2 -o t t1.o t2.o -flto -fwhole-program -B /abuild/rguenther/trunk-g/gcc
t2.o: In function `foo':
t2.c:(.text+0x15): undefined reference to `bar'
t2.c:(.text+0x1b): undefined reference to `vvvvvv'
collect2: ld returned 1 exit status
Richard.
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: externally_visible and resoultion file
2010-06-08 14:05 ` Richard Guenther
@ 2010-06-08 14:22 ` Bingfeng Mei
2010-06-08 14:22 ` Richard Guenther
0 siblings, 1 reply; 12+ messages in thread
From: Bingfeng Mei @ 2010-06-08 14:22 UTC (permalink / raw)
To: Richard Guenther; +Cc: Jan Hubicka, gcc, Cary Coutant
Thanks. But why "vvvvv" is linked correctly here? Shouldn't it
be treated as static with -fwhole-program?
Bingfeng
> -----Original Message-----
> From: Richard Guenther [mailto:richard.guenther@gmail.com]
> Sent: 08 June 2010 14:10
> To: Bingfeng Mei
> Cc: Jan Hubicka; gcc@gcc.gnu.org; Cary Coutant
> Subject: Re: externally_visible and resoultion file
>
> On Tue, Jun 8, 2010 at 3:01 PM, Bingfeng Mei <bmei@broadcom.com> wrote:
> > Hi,
> > Sorry for coming back to this issue after a while. I am still puzzled
> > by this. The following are two test files:
> >
> > a.c
> >
> > #include <string.h>
> > #include <stdio.h>
> > extern int foo(int);
> > void bar()
> > {
> > printf("bar\n");
> > }
> > extern int src[], dst[];
> > int vvvvvv;
> > int main()
> > {
> > int ret;
> > vvvvvv = 12;
> > ret = foo(20);
> > memcpy(dst, src, 100);
> > return ret + 3;
> > }
> >
> > b.c
> > #include <stdio.h>
> > int src[100];
> > int dst[100];
> > extern int vvvvvv;
> > extern void bar();
> > int foo(int c)
> > {
> > printf("Hello world: %d\n", c);
> > bar();
> > return 1000 + vvvvvv;
> > }
> >
> > I compiled with following steps
> > ~/work/install-x86/bin/gcc -flto a.c -O2 -c
> > ~/work/install-x86/bin/gcc b.c -O2 -c
> > ar cru libb.a b.o
> > ~/work/install-x86/bin/gcc -flto a.o -L. -lb -O2 -fuse-linker-plugin
> -o f -fwhole-program -save-temps
> >
> > Since you both mentioned that resolution file is not used to replace
> externally_visible attribute yet,
> > I expect there will be link errors regarding both vvvvvv and bar.
> Somehow, GCC doesn't complain at all.
> > However, looking at generated assembly code, GCC produces wrong code
> for calling bar, and vvvvvv is
> > linked correctly though.
> >
> > 0000000000400510 <foo>:
> > 400510: 48 83 ec 08 sub $0x8,%rsp
> > 400514: 89 fe mov %edi,%esi
> > 400516: 31 c0 xor %eax,%eax
> > 400518: bf 1c 06 40 00 mov $0x40061c,%edi
> > 40051d: e8 56 01 00 00 callq 400678 <printf@plt>
> > 400522: 31 c0 xor %eax,%eax
> > 400524: e8 d7 fa bf ff callq 0
> <__fini_array_end> <-------- should call bar.
> > 400529: 8b 05 a1 17 00
> 00 mov 0x17a1(%rip),%eax # 401cd0 <vvvvvv>
> > 40052f: 48 83 c4 08 add $0x8,%rsp
> > 400533: 05 e8 03 00 00 add $0x3e8,%eax
> > 400538: c3 retq
> > 400539: 0f 1f 80 00 00 00 00 nopl 0x0(%rax)
> >
> > Is this a bug? GCC should issue warning/error here. Why is vvvvvv
> linked correctly?
> > Shouldn't it be treated as static with -fwhile-program and without
> externally_visible?
>
> bar should be indeed eliminated which is what I see with not
> using the linker plugin.
>
> If you use the linker-plugin I see in the .optimized dump that
> the were eliminated. But it seems that gold picks them up
> from the original objects which seem to be retained somehow.
>
> I guess this is a bug in the linker-plugin.
>
> Richard.
>
> > My trunk is 160104 by the way.
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: externally_visible and resoultion file
2010-06-08 14:22 ` Richard Guenther
@ 2010-06-08 14:58 ` Bingfeng Mei
2010-06-08 14:59 ` Richard Guenther
0 siblings, 1 reply; 12+ messages in thread
From: Bingfeng Mei @ 2010-06-08 14:58 UTC (permalink / raw)
To: Richard Guenther; +Cc: Jan Hubicka, gcc, Cary Coutant
Yes, this is also what I saw without plugin. I just wonder why "vvvvv"
is linked with plugin if resolution file is not used to eliminate need
of externally_visible attribute here.
Thanks,
Bingfeng
> -----Original Message-----
> From: Richard Guenther [mailto:richard.guenther@gmail.com]
> Sent: 08 June 2010 15:18
> To: Bingfeng Mei
> Cc: Jan Hubicka; gcc@gcc.gnu.org; Cary Coutant
> Subject: Re: externally_visible and resoultion file
>
> On Tue, Jun 8, 2010 at 4:15 PM, Bingfeng Mei <bmei@broadcom.com> wrote:
> > Thanks. But why "vvvvv" is linked correctly here? Shouldn't it
> > be treated as static with -fwhole-program?
>
> Works for me without the linker plugin as well:
>
> > gcc-4.5 -O2 -o t t1.o t2.o -flto -fwhole-program -B
> /abuild/rguenther/trunk-g/gcc
> t2.o: In function `foo':
> t2.c:(.text+0x15): undefined reference to `bar'
> t2.c:(.text+0x1b): undefined reference to `vvvvvv'
> collect2: ld returned 1 exit status
>
> Richard.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: externally_visible and resoultion file
2010-06-08 14:58 ` Bingfeng Mei
@ 2010-06-08 14:59 ` Richard Guenther
2010-06-09 20:46 ` Cary Coutant
0 siblings, 1 reply; 12+ messages in thread
From: Richard Guenther @ 2010-06-08 14:59 UTC (permalink / raw)
To: Bingfeng Mei; +Cc: Jan Hubicka, gcc, Cary Coutant
On Tue, Jun 8, 2010 at 4:22 PM, Bingfeng Mei <bmei@broadcom.com> wrote:
> Yes, this is also what I saw without plugin. I just wonder why "vvvvv"
> is linked with plugin if resolution file is not used to eliminate need
> of externally_visible attribute here.
Probably because of the same linker-plugin bug that causes bar
to be resolved.
Richard.
> Thanks,
> Bingfeng
>
>> -----Original Message-----
>> From: Richard Guenther [mailto:richard.guenther@gmail.com]
>> Sent: 08 June 2010 15:18
>> To: Bingfeng Mei
>> Cc: Jan Hubicka; gcc@gcc.gnu.org; Cary Coutant
>> Subject: Re: externally_visible and resoultion file
>>
>> On Tue, Jun 8, 2010 at 4:15 PM, Bingfeng Mei <bmei@broadcom.com> wrote:
>> > Thanks. But why "vvvvv" is linked correctly here? Shouldn't it
>> > be treated as static with -fwhole-program?
>>
>> Works for me without the linker plugin as well:
>>
>> > gcc-4.5 -O2 -o t t1.o t2.o -flto -fwhole-program -B
>> /abuild/rguenther/trunk-g/gcc
>> t2.o: In function `foo':
>> t2.c:(.text+0x15): undefined reference to `bar'
>> t2.c:(.text+0x1b): undefined reference to `vvvvvv'
>> collect2: ld returned 1 exit status
>>
>> Richard.
>
>
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: externally_visible and resoultion file
2010-06-08 14:59 ` Richard Guenther
@ 2010-06-09 20:46 ` Cary Coutant
2010-06-10 2:29 ` Richard Guenther
2010-06-10 11:57 ` Bingfeng Mei
0 siblings, 2 replies; 12+ messages in thread
From: Cary Coutant @ 2010-06-09 20:46 UTC (permalink / raw)
To: Richard Guenther; +Cc: Bingfeng Mei, Jan Hubicka, gcc
>> Yes, this is also what I saw without plugin. I just wonder why "vvvvv"
>> is linked with plugin if resolution file is not used to eliminate need
>> of externally_visible attribute here.
>
> Probably because of the same linker-plugin bug that causes bar
> to be resolved.
Just to make sure I understand the problem:
- The IR file for a.c contains definitions for vvvvv and bar.
- The linker identifies that both symbols are referenced from outside
the LTO world (PREVAILING_DEF rather than PREVAILING_DEF_IRONLY), but
gcc isn't (yet) reading that info from the resolution file.
- WPA eliminates bar() and makes vvvvv static in the replacement object file.
- There are still references to those symbols in b.o, which was
compiled outside LTO.
- The linker should be complaining about undefined symbols in both
cases, but isn't (perhaps because it's still seeing defs left over
from the IR files). The symbol bar has a value of 0, while the
reference to vvvvv seems to have the right address.
Is that about right? What you're expecting is a link-time error
reporting both bar and vvvvv as undefined, right?
-cary
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: externally_visible and resoultion file
2010-06-09 20:46 ` Cary Coutant
@ 2010-06-10 2:29 ` Richard Guenther
2010-06-10 11:57 ` Bingfeng Mei
1 sibling, 0 replies; 12+ messages in thread
From: Richard Guenther @ 2010-06-10 2:29 UTC (permalink / raw)
To: Cary Coutant; +Cc: Bingfeng Mei, Jan Hubicka, gcc
On Wed, Jun 9, 2010 at 7:43 PM, Cary Coutant <ccoutant@google.com> wrote:
>>> Yes, this is also what I saw without plugin. I just wonder why "vvvvv"
>>> is linked with plugin if resolution file is not used to eliminate need
>>> of externally_visible attribute here.
>>
>> Probably because of the same linker-plugin bug that causes bar
>> to be resolved.
>
> Just to make sure I understand the problem:
>
> - The IR file for a.c contains definitions for vvvvv and bar.
> - The linker identifies that both symbols are referenced from outside
> the LTO world (PREVAILING_DEF rather than PREVAILING_DEF_IRONLY), but
> gcc isn't (yet) reading that info from the resolution file.
> - WPA eliminates bar() and makes vvvvv static in the replacement object file.
> - There are still references to those symbols in b.o, which was
> compiled outside LTO.
> - The linker should be complaining about undefined symbols in both
> cases, but isn't (perhaps because it's still seeing defs left over
> from the IR files). The symbol bar has a value of 0, while the
> reference to vvvvv seems to have the right address.
>
> Is that about right? What you're expecting is a link-time error
> reporting both bar and vvvvv as undefined, right?
That's correct.
Richard.
> -cary
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: externally_visible and resoultion file
2010-06-09 20:46 ` Cary Coutant
2010-06-10 2:29 ` Richard Guenther
@ 2010-06-10 11:57 ` Bingfeng Mei
1 sibling, 0 replies; 12+ messages in thread
From: Bingfeng Mei @ 2010-06-10 11:57 UTC (permalink / raw)
To: Cary Coutant, Richard Guenther; +Cc: Jan Hubicka, gcc
> -----Original Message-----
> From: Cary Coutant [mailto:ccoutant@google.com]
> Sent: 09 June 2010 18:43
> To: Richard Guenther
> Cc: Bingfeng Mei; Jan Hubicka; gcc@gcc.gnu.org
> Subject: Re: externally_visible and resoultion file
>
> >> Yes, this is also what I saw without plugin. I just wonder why
> "vvvvv"
> >> is linked with plugin if resolution file is not used to eliminate
> need
> >> of externally_visible attribute here.
> >
> > Probably because of the same linker-plugin bug that causes bar
> > to be resolved.
>
> Just to make sure I understand the problem:
>
> - The IR file for a.c contains definitions for vvvvv and bar.
> - The linker identifies that both symbols are referenced from outside
> the LTO world (PREVAILING_DEF rather than PREVAILING_DEF_IRONLY), but
> gcc isn't (yet) reading that info from the resolution file.
> - WPA eliminates bar() and makes vvvvv static in the replacement object
> file.
> - There are still references to those symbols in b.o, which was
> compiled outside LTO.
> - The linker should be complaining about undefined symbols in both
> cases, but isn't (perhaps because it's still seeing defs left over
> from the IR files). The symbol bar has a value of 0, while the
> reference to vvvvv seems to have the right address.
>
> Is that about right? What you're expecting is a link-time error
> reporting both bar and vvvvv as undefined, right?
>
> -cary
Yes, I expect link-time errors of undefined reference for both
bar and vvvvvv. Instead, bar is linked to a bogus one (address 0)
and vvvvvv is linked correctly.
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2010-06-10 9:33 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-05-26 16:03 externally_visible and resoultion file Bingfeng Mei
2010-05-26 16:19 ` Richard Guenther
2010-05-27 8:10 ` Jan Hubicka
2010-06-08 13:48 ` Bingfeng Mei
2010-06-08 14:05 ` Richard Guenther
2010-06-08 14:22 ` Bingfeng Mei
2010-06-08 14:22 ` Richard Guenther
2010-06-08 14:58 ` Bingfeng Mei
2010-06-08 14:59 ` Richard Guenther
2010-06-09 20:46 ` Cary Coutant
2010-06-10 2:29 ` Richard Guenther
2010-06-10 11:57 ` Bingfeng Mei
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).