public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/40068] New: GCC fails to apply dllexport attribute to typeinfo.
@ 2009-05-08 11:52 dave dot korn dot cygwin at gmail dot com
2009-05-08 11:53 ` [Bug c++/40068] " dave dot korn dot cygwin at gmail dot com
` (6 more replies)
0 siblings, 7 replies; 14+ messages in thread
From: dave dot korn dot cygwin at gmail dot com @ 2009-05-08 11:52 UTC (permalink / raw)
To: gcc-bugs
Precisely as subject. All other class members and related data (e.g. vtables,
synthetic ctors) will be tagged dllexport if the class itself is dllexport, and
-export comments will be added listing their symbols in the .drectve section.
Typeinfo data alone will not receive the dllexport attribute, because it is not
a class member. (Theoretically, I think it counts as a static class data
member of type std::type_info, but internally) It is generated as a synthetic
POD data type, and hence does not appear to the i386 backend as belonging to
the class it represents.
The description in bug 17300 suggests that there could be a problem further
down the line with dllimporting such typeinfos, but right now they simply can't
be referenced outside the enclosing DLL at all, i.e. clients of a DLL can't
dynamically cast class pointers to the classes it implements, only routines
within the DLL which have local linkage to the typeinfo. This is a separate
problem, which I think can be resolved further down the toolchain using
pseudo-relocs; I don't think it's a reason not to make export work.
--
Summary: GCC fails to apply dllexport attribute to typeinfo.
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dave dot korn dot cygwin at gmail dot com
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40068
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug c++/40068] GCC fails to apply dllexport attribute to typeinfo.
2009-05-08 11:52 [Bug c++/40068] New: GCC fails to apply dllexport attribute to typeinfo dave dot korn dot cygwin at gmail dot com
@ 2009-05-08 11:53 ` dave dot korn dot cygwin at gmail dot com
2009-05-08 11:56 ` dave dot korn dot cygwin at gmail dot com
` (5 subsequent siblings)
6 siblings, 0 replies; 14+ messages in thread
From: dave dot korn dot cygwin at gmail dot com @ 2009-05-08 11:53 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-05-08 11:53 -------
Created an attachment (id=17826)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17826&action=view)
Simple testcase
It doesn't get much more trivial than this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40068
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug c++/40068] GCC fails to apply dllexport attribute to typeinfo.
2009-05-08 11:52 [Bug c++/40068] New: GCC fails to apply dllexport attribute to typeinfo dave dot korn dot cygwin at gmail dot com
2009-05-08 11:53 ` [Bug c++/40068] " dave dot korn dot cygwin at gmail dot com
@ 2009-05-08 11:56 ` dave dot korn dot cygwin at gmail dot com
2009-05-10 1:11 ` [Bug target/40068] " dave dot korn dot cygwin at gmail dot com
` (4 subsequent siblings)
6 siblings, 0 replies; 14+ messages in thread
From: dave dot korn dot cygwin at gmail dot com @ 2009-05-08 11:56 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from dave dot korn dot cygwin at gmail dot com 2009-05-08 11:55 -------
To reproduce the bug, compile the attached testcase
g++-4 -fpreprocessed -S vti.ii
and view the very end of the .s file emitted:
.section .drectve
.ascii " -export:_ZTV12XMLException,data"
.ascii " -export:_ZN12XMLExceptionD2Ev"
.ascii " -export:_ZN12XMLExceptionD1Ev"
.ascii " -export:_ZN12XMLExceptionD0Ev"
.ascii " -export:_ZN12XMLExceptionC1Ev"
.ascii " -export:_ZN12XMLExceptionC2Ev"
Everything gets exported except the typeinfo.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40068
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug target/40068] GCC fails to apply dllexport attribute to typeinfo.
2009-05-08 11:52 [Bug c++/40068] New: GCC fails to apply dllexport attribute to typeinfo dave dot korn dot cygwin at gmail dot com
2009-05-08 11:53 ` [Bug c++/40068] " dave dot korn dot cygwin at gmail dot com
2009-05-08 11:56 ` dave dot korn dot cygwin at gmail dot com
@ 2009-05-10 1:11 ` dave dot korn dot cygwin at gmail dot com
2009-05-10 5:01 ` dannysmith at users dot sourceforge dot net
` (3 subsequent siblings)
6 siblings, 0 replies; 14+ messages in thread
From: dave dot korn dot cygwin at gmail dot com @ 2009-05-10 1:11 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from dave dot korn dot cygwin at gmail dot com 2009-05-10 01:11 -------
Created an attachment (id=17841)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17841&action=view)
inherit dllexport from class to typeinfo
Now testing a solution based on the approach of adding the dllexport attribute
to the class' typeinfo object when the class is passed to
i386_pe_adjust_class_at_definition.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40068
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug target/40068] GCC fails to apply dllexport attribute to typeinfo.
2009-05-08 11:52 [Bug c++/40068] New: GCC fails to apply dllexport attribute to typeinfo dave dot korn dot cygwin at gmail dot com
` (2 preceding siblings ...)
2009-05-10 1:11 ` [Bug target/40068] " dave dot korn dot cygwin at gmail dot com
@ 2009-05-10 5:01 ` dannysmith at users dot sourceforge dot net
2009-05-10 11:18 ` dave dot korn dot cygwin at gmail dot com
` (2 subsequent siblings)
6 siblings, 0 replies; 14+ messages in thread
From: dannysmith at users dot sourceforge dot net @ 2009-05-10 5:01 UTC (permalink / raw)
To: gcc-bugs
------- Comment #4 from dannysmith at users dot sourceforge dot net 2009-05-10 05:01 -------
(In reply to comment #3)
> Created an attachment (id=17841)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17841&action=view) [edit]
> inherit dllexport from class to typeinfo
>
> Now testing a solution based on the approach of adding the dllexport attribute
> to the class' typeinfo object when the class is passed to
> i386_pe_adjust_class_at_definition.
>
Hello Dave,
Rather than use DLL linkage (and so force client to resort to auto-import
magic)
why not just always emit the RTTI with one-only comdat linkage.
* decl2.c (import_export_decl): Always emit RTTI with comdat linkage
rather than import if MULTIPLE_SYMBOL_SPACES.
Index: decl2.c
===================================================================
--- decl2.c (revision 147015)
+++ decl2.c (working copy)
@@ -2351,15 +2351,21 @@
{
class_type = type;
import_export_class (type);
- if (CLASSTYPE_INTERFACE_KNOWN (type)
- && TYPE_POLYMORPHIC_P (type)
- && CLASSTYPE_INTERFACE_ONLY (type)
- /* If -fno-rtti was specified, then we cannot be sure
- that RTTI information will be emitted with the
- virtual table of the class, so we must emit it
- wherever it is used. */
- && flag_rtti)
- import_p = true;
+ /* Do not import typeinfo if the class might be in a DLL.
+ Dllimports do not have a constant address at compile time,
+ causing problems for static initialization of tables with RTTI
+ fields. Set to comdat instead. */
+ if (MULTIPLE_SYMBOL_SPACES)
+ comdat_p = true;
+ else if (CLASSTYPE_INTERFACE_KNOWN (type)
+ && TYPE_POLYMORPHIC_P (type)
+ && CLASSTYPE_INTERFACE_ONLY (type)
+ /* If -fno-rtti was specified, then we cannot be sure
+ that RTTI information will be emitted with the
+ virtual table of the class, so we must emit it
+ wherever it is used. */
+ && flag_rtti)
+ import_p = true;
else
{
if (CLASSTYPE_INTERFACE_KNOWN (type)
--
dannysmith at users dot sourceforge dot net changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|unassigned at gcc dot gnu |dannysmith at users dot
|dot org |sourceforge dot net
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|0000-00-00 00:00:00 |2009-05-10 05:01:24
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40068
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug target/40068] GCC fails to apply dllexport attribute to typeinfo.
2009-05-08 11:52 [Bug c++/40068] New: GCC fails to apply dllexport attribute to typeinfo dave dot korn dot cygwin at gmail dot com
` (3 preceding siblings ...)
2009-05-10 5:01 ` dannysmith at users dot sourceforge dot net
@ 2009-05-10 11:18 ` dave dot korn dot cygwin at gmail dot com
2009-05-13 8:12 ` dannysmith at users dot sourceforge dot net
2009-06-25 15:37 ` dave dot korn dot cygwin at gmail dot com
6 siblings, 0 replies; 14+ messages in thread
From: dave dot korn dot cygwin at gmail dot com @ 2009-05-10 11:18 UTC (permalink / raw)
To: gcc-bugs
------- Comment #5 from dave dot korn dot cygwin at gmail dot com 2009-05-10 11:17 -------
(In reply to comment #4)
> Hello Dave,
Hi Danny!
> Rather than use DLL linkage (and so force client to resort to auto-import
> magic)
> why not just always emit the RTTI with one-only comdat linkage.
I have your patch in the cygwin distro compiler where it works fine, but I am
concerned about what unforeseeable problems could arise by violating ODR in
this way. I don't have any concrete evidence of any problem yet, it is just a
worry.
Also, I don't think this is necessarily an either-or situation; we could add
my patch and have the typeinfo exported from the DLL, and also add yours so
that clients could link a comdat copy (which would override the import stub)
until we have a better solution for importing from the DLL. Or I could follow
up with another patch that propagates dllimport attributes from class to
typeinfo.
There is of course this:
/* We leave typeinfo tables alone. We can't mark TI objects as
dllimport, since the address of a secondary VTT may be needed
for static initialization of a primary VTT. VTT's of
dllimport'd classes should always be link-once COMDAT. */
/* Do not import tinfo nodes if the class has dllimport attribute.
Dllimports do not have a constant address at compile time, so
static initialization of tables with RTTI fields is a problem.
Set to comdat instead. */
... but I do not see why this should be a problem in these days of auto-import
and pseudo-relocs; do you know more about what the actual problem is (or was)
here? Is this not basically the same situation as something like
----dll_A.c----
int foo;
int __attribute__ ((dllexport)) * bar = &foo;
----dll_B.c----
extern int __attribute__ ((dllexport)) * bar;
int __attribute__ ((dllexport)) * baz = &bar;
---------------
the example above?
If it's possible to solve either in the compiler or further down the
toolchain, I would very much like to do so.
Also, how come emitting the typeinfo .linkonce as we currently do isn't the
same as COMDAT for these purposes?
cheers,
DaveK
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40068
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug target/40068] GCC fails to apply dllexport attribute to typeinfo.
2009-05-08 11:52 [Bug c++/40068] New: GCC fails to apply dllexport attribute to typeinfo dave dot korn dot cygwin at gmail dot com
` (4 preceding siblings ...)
2009-05-10 11:18 ` dave dot korn dot cygwin at gmail dot com
@ 2009-05-13 8:12 ` dannysmith at users dot sourceforge dot net
2009-06-25 15:37 ` dave dot korn dot cygwin at gmail dot com
6 siblings, 0 replies; 14+ messages in thread
From: dannysmith at users dot sourceforge dot net @ 2009-05-13 8:12 UTC (permalink / raw)
To: gcc-bugs
------- Comment #6 from dannysmith at users dot sourceforge dot net 2009-05-13 08:12 -------
(In reply to comment #5)
> Also, I don't think this is necessarily an either-or situation; we could add
> my patch and have the typeinfo exported from the DLL, and also add yours so
> that clients could link a comdat copy (which would override the import stub)
> until we have a better solution for importing from the DLL.
Yes. I was just thinking out loud. I have no objection to your patch.
Perhaps MULTIPLE_SYMBOL_SPACES should be defined in terms of an
-mmultiple-symbol-spaces target option , since if we depend on auto-import than
we should treat dll imports thae same as static lib imports.
> Also, how come emitting the typeinfo .linkonce as we currently do isn't the
> same as COMDAT for these purposes?
>
I'm not sure I understand your question. In earlier versions of G++, both
vtables and typeinfo were always emitted with linkonce semantics, because of
the MULTIPLE_SYMBOL_SPACES define.
Regards
Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40068
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug target/40068] GCC fails to apply dllexport attribute to typeinfo.
2009-05-08 11:52 [Bug c++/40068] New: GCC fails to apply dllexport attribute to typeinfo dave dot korn dot cygwin at gmail dot com
` (5 preceding siblings ...)
2009-05-13 8:12 ` dannysmith at users dot sourceforge dot net
@ 2009-06-25 15:37 ` dave dot korn dot cygwin at gmail dot com
6 siblings, 0 replies; 14+ messages in thread
From: dave dot korn dot cygwin at gmail dot com @ 2009-06-25 15:37 UTC (permalink / raw)
To: gcc-bugs
------- Comment #7 from dave dot korn dot cygwin at gmail dot com 2009-06-25 15:37 -------
Hmm, I'm getting somewhere with this.
By compiling the g++ testsuite "ptrflags.C" case with --save-temps, manually
hacking all the superfluous typeinfo stuff out, and re-assembling and linking
it, I can turn a FAIL into a PASS, with all the typeinfo and related stuff
being imported from the DLL.
So I think typeinfo can be made to work, and work with both
__GXX_MERGED_TYPEINFO_NAMES and __GXX_TYPEINFO_EQUALITY_INLINE.
All I need to do is stop the compiler from emitting comdat definitions of
items with vague linkage when they are dllimported, or perhaps make the linker
prefer an import over a comdat section when the same symbol could be resolved
by either. Or perhaps both. I think the linker fix is what you were
suggesting when you said
> since if we depend on auto-import than
> we should treat dll imports thae same as static lib imports
More later.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40068
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug target/40068] GCC fails to apply dllexport attribute to typeinfo.
[not found] <bug-40068-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2013-09-13 7:52 ` mattyclarkson at gmail dot com
@ 2013-09-13 7:54 ` mattyclarkson at gmail dot com
5 siblings, 0 replies; 14+ messages in thread
From: mattyclarkson at gmail dot com @ 2013-09-13 7:54 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40068
--- Comment #13 from Matt Clarkson <mattyclarkson at gmail dot com> ---
Created attachment 30814
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30814&action=edit
missing dllexport on typeinfo output
Added an attachment for the full compiler output.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug target/40068] GCC fails to apply dllexport attribute to typeinfo.
[not found] <bug-40068-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2012-02-07 11:49 ` ktietz at gcc dot gnu.org
@ 2013-09-13 7:52 ` mattyclarkson at gmail dot com
2013-09-13 7:54 ` mattyclarkson at gmail dot com
5 siblings, 0 replies; 14+ messages in thread
From: mattyclarkson at gmail dot com @ 2013-09-13 7:52 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40068
Matt Clarkson <mattyclarkson at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mattyclarkson at gmail dot com
--- Comment #12 from Matt Clarkson <mattyclarkson at gmail dot com> ---
Did that patch resolve this bug? I'm using MinGW-builds-4.8.1-x64-posix-seh
and building a project and ended up with the following error:
value.hpp:33:31: error: external linkage required for symbol
'_ZTIN3udp8keystone6binary9arguments5ValueIZNS1_4Main17GetParsedArgumentERKSsE5DummyEE'
because of 'dllexport' attribute class UDP_KEYSTONE_DLL_PUBLIC Value final :
public ValueBase {
Which translates to missing 'dllexport' attribute on 'typeinfo for
udp::keystone::binary::arguments::Value'
But both my Value class and ValueBase classes are marked with
'UDP_KEYSTONE_DLL_PUBLIC' that expands to '__attribute__((dllexport))'
If this is a similar bug and not my error (which I presume it is) I will
resolve a test delta.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug target/40068] GCC fails to apply dllexport attribute to typeinfo.
[not found] <bug-40068-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2012-02-07 10:49 ` ktietz at gcc dot gnu.org
@ 2012-02-07 11:49 ` ktietz at gcc dot gnu.org
2013-09-13 7:52 ` mattyclarkson at gmail dot com
2013-09-13 7:54 ` mattyclarkson at gmail dot com
5 siblings, 0 replies; 14+ messages in thread
From: ktietz at gcc dot gnu.org @ 2012-02-07 11:49 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40068
--- Comment #11 from Kai Tietz <ktietz at gcc dot gnu.org> 2012-02-07 11:48:41 UTC ---
Author: ktietz
Date: Tue Feb 7 11:48:34 2012
New Revision: 183965
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183965
Log:
2012-02-07 Kai Tietz <ktietz@redhat.com>
Dave Korn <dave.korn.cygwin@gmail.com>
PR target/40068
* config/i386/winnt-cxx.c (i386_pe_adjust_class_at_definition):
Take care that typinfo gets dllexport-attribute.
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/config/i386/winnt-cxx.c
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug target/40068] GCC fails to apply dllexport attribute to typeinfo.
[not found] <bug-40068-4@http.gcc.gnu.org/bugzilla/>
2012-02-02 21:01 ` ktietz at gcc dot gnu.org
2012-02-07 10:47 ` ktietz at gcc dot gnu.org
@ 2012-02-07 10:49 ` ktietz at gcc dot gnu.org
2012-02-07 11:49 ` ktietz at gcc dot gnu.org
` (2 subsequent siblings)
5 siblings, 0 replies; 14+ messages in thread
From: ktietz at gcc dot gnu.org @ 2012-02-07 10:49 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40068
--- Comment #10 from Kai Tietz <ktietz at gcc dot gnu.org> 2012-02-07 10:49:20 UTC ---
Author: ktietz
Date: Tue Feb 7 10:49:14 2012
New Revision: 183963
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183963
Log:
2012-02-07 Kai Tietz <ktietz@redhat.com>
Dave Korn <dave.korn.cygwin@gmail.com>
PR target/40068
* config/i386/winnt-cxx.c (i386_pe_adjust_class_at_definition):
Take care that typinfo gets dllexport-attribute.
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/config/i386/winnt-cxx.c
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug target/40068] GCC fails to apply dllexport attribute to typeinfo.
[not found] <bug-40068-4@http.gcc.gnu.org/bugzilla/>
2012-02-02 21:01 ` ktietz at gcc dot gnu.org
@ 2012-02-07 10:47 ` ktietz at gcc dot gnu.org
2012-02-07 10:49 ` ktietz at gcc dot gnu.org
` (3 subsequent siblings)
5 siblings, 0 replies; 14+ messages in thread
From: ktietz at gcc dot gnu.org @ 2012-02-07 10:47 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40068
--- Comment #9 from Kai Tietz <ktietz at gcc dot gnu.org> 2012-02-07 10:46:06 UTC ---
Author: ktietz
Date: Tue Feb 7 10:45:59 2012
New Revision: 183962
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183962
Log:
2012-02-07 Kai Tietz <ktietz@redhat.com>
Dave Korn <dave.korn.cygwin@gmail.com>
PR target/40068
* config/i386/winnt-cxx.c (i386_pe_adjust_class_at_definition):
Take care that typinfo gets dllexport-attribute.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/winnt-cxx.c
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug target/40068] GCC fails to apply dllexport attribute to typeinfo.
[not found] <bug-40068-4@http.gcc.gnu.org/bugzilla/>
@ 2012-02-02 21:01 ` ktietz at gcc dot gnu.org
2012-02-07 10:47 ` ktietz at gcc dot gnu.org
` (4 subsequent siblings)
5 siblings, 0 replies; 14+ messages in thread
From: ktietz at gcc dot gnu.org @ 2012-02-02 21:01 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40068
Kai Tietz <ktietz at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ml@convergent-it.at
--- Comment #8 from Kai Tietz <ktietz at gcc dot gnu.org> 2012-02-02 21:00:41 UTC ---
*** Bug 50044 has been marked as a duplicate of this bug. ***
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2013-09-13 7:54 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-05-08 11:52 [Bug c++/40068] New: GCC fails to apply dllexport attribute to typeinfo dave dot korn dot cygwin at gmail dot com
2009-05-08 11:53 ` [Bug c++/40068] " dave dot korn dot cygwin at gmail dot com
2009-05-08 11:56 ` dave dot korn dot cygwin at gmail dot com
2009-05-10 1:11 ` [Bug target/40068] " dave dot korn dot cygwin at gmail dot com
2009-05-10 5:01 ` dannysmith at users dot sourceforge dot net
2009-05-10 11:18 ` dave dot korn dot cygwin at gmail dot com
2009-05-13 8:12 ` dannysmith at users dot sourceforge dot net
2009-06-25 15:37 ` dave dot korn dot cygwin at gmail dot com
[not found] <bug-40068-4@http.gcc.gnu.org/bugzilla/>
2012-02-02 21:01 ` ktietz at gcc dot gnu.org
2012-02-07 10:47 ` ktietz at gcc dot gnu.org
2012-02-07 10:49 ` ktietz at gcc dot gnu.org
2012-02-07 11:49 ` ktietz at gcc dot gnu.org
2013-09-13 7:52 ` mattyclarkson at gmail dot com
2013-09-13 7:54 ` mattyclarkson at gmail dot com
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).