public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/21764] visibility attributes on namespace scope
       [not found] <bug-21764-365@http.gcc.gnu.org/bugzilla/>
@ 2005-11-04 13:05 ` pinskia at gcc dot gnu dot org
  2005-11-04 17:05 ` bkoz at gcc dot gnu dot org
                   ` (9 subsequent siblings)
  10 siblings, 0 replies; 14+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-11-04 13:05 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #4 from pinskia at gcc dot gnu dot org  2005-11-04 13:05 -------
*** Bug 24668 has been marked as a duplicate of this bug. ***


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21764


^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Bug c++/21764] visibility attributes on namespace scope
       [not found] <bug-21764-365@http.gcc.gnu.org/bugzilla/>
  2005-11-04 13:05 ` [Bug c++/21764] visibility attributes on namespace scope pinskia at gcc dot gnu dot org
@ 2005-11-04 17:05 ` bkoz at gcc dot gnu dot org
  2005-11-17 22:55 ` jason at gcc dot gnu dot org
                   ` (8 subsequent siblings)
  10 siblings, 0 replies; 14+ messages in thread
From: bkoz at gcc dot gnu dot org @ 2005-11-04 17:05 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #5 from bkoz at gcc dot gnu dot org  2005-11-04 17:05 -------
In addition to the current ability to put visibility attributes on file and
class scope, the ability to put visibility attributes on namespace scope is
desired.

The syntax is straight forward extension of existing visibility attribute
options.

namespace test __attribute__ ((visibility("hidden")))
{
  struct c1 
  {
    static int s;
    virtual void foo() { }
  };

  int c1::s;
}

Is an example.

What does this mean? For definitions within namespace scope, set the symbol
visibility to the nearest enclosing namespace attribute. Declarations are
unaffected.

Nested namespaces have the same semantics as nested classes. Ie, enclosing
scope. Therefore:

#define VIS_default __attribute__ ((visibility("default")))
#define VIS_hidden __attribute__ ((visibility("hidden")))

  struct c1 
  {
    static int s;
    virtual void foo() { }

    struct c2 
    {
      static int s;
      virtual void foo() { }
    } VIS_default;
  } VIS_hidden;

namespace test1 VIS_hidden
{
  struct c1 
  {
    static int s;
    virtual void foo() { }
  };

  int c1::s;

  namespace test2 VIS_default
  {
    struct c2 
    {
      static int s;
      virtual void foo() { }
    };

    int c2::s;
  }
}

In the above, struct c2 and test1::test2::c2 both have default visibility,
whereas c1 and test1::c1 both have hidden visibility.

Interactions between file, namespace, and class scope are handled sanely. Ie,
the same deal, nearest enclosing scope.

ie:

#pragma GCC visibility push(hidden)

namespace test1 VIS_default
{
  struct c1 
  {
    static int s;
    virtual void foo() { }
  };

  int c1::s;

  struct c2 
  {
    static int s;
    virtual void foo() { }
  } VIS_hidden;

  int c2::s;
}

#pragma GCC visibility pop

In the above, c1 would be default, c2 would be hidden.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21764


^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Bug c++/21764] visibility attributes on namespace scope
       [not found] <bug-21764-365@http.gcc.gnu.org/bugzilla/>
  2005-11-04 13:05 ` [Bug c++/21764] visibility attributes on namespace scope pinskia at gcc dot gnu dot org
  2005-11-04 17:05 ` bkoz at gcc dot gnu dot org
@ 2005-11-17 22:55 ` jason at gcc dot gnu dot org
  2005-11-17 23:53 ` bkoz at gcc dot gnu dot org
                   ` (7 subsequent siblings)
  10 siblings, 0 replies; 14+ messages in thread
From: jason at gcc dot gnu dot org @ 2005-11-17 22:55 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #6 from jason at gcc dot gnu dot org  2005-11-17 22:55 -------
Why do the examples want to have a namespace (or class) with default visibility
nested within one with hidden visibility?  The other way around makes sense,
but this seems nonsensical.  It seems to me that nested scopes ought to have
less or equal visibility to their enclosing scope.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21764


^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Bug c++/21764] visibility attributes on namespace scope
       [not found] <bug-21764-365@http.gcc.gnu.org/bugzilla/>
                   ` (2 preceding siblings ...)
  2005-11-17 22:55 ` jason at gcc dot gnu dot org
@ 2005-11-17 23:53 ` bkoz at gcc dot gnu dot org
  2005-11-18  6:15 ` jason at redhat dot com
                   ` (6 subsequent siblings)
  10 siblings, 0 replies; 14+ messages in thread
From: bkoz at gcc dot gnu dot org @ 2005-11-17 23:53 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #7 from bkoz at gcc dot gnu dot org  2005-11-17 23:53 -------

What do you mean, "less or equal visibility to their enclosing scope?"

My meta-goal is to try and give namespace and class scope visibilty attributes
similar meanings. Do you think this is worthwhile, possible, and do you think
this is a good idea?

Yeah, maybe default namespace with hidden nested makes more sense for the
examples. However, wouldn't both have to be supported, anyway? 

These kinds of "nonsensical" examples are possible with existing visibility
attributes on classes. I'm just trying to keep the other scoping mechanism in
mind (class scope) when thinking about how it applies to namespaces.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21764


^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Bug c++/21764] visibility attributes on namespace scope
       [not found] <bug-21764-365@http.gcc.gnu.org/bugzilla/>
                   ` (3 preceding siblings ...)
  2005-11-17 23:53 ` bkoz at gcc dot gnu dot org
@ 2005-11-18  6:15 ` jason at redhat dot com
  2005-11-18 19:39 ` geoffk at geoffk dot org
                   ` (5 subsequent siblings)
  10 siblings, 0 replies; 14+ messages in thread
From: jason at redhat dot com @ 2005-11-18  6:15 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #8 from jason at redhat dot com  2005-11-18 06:15 -------
Subject: Re:  visibility attributes on namespace scope

bkoz at gcc dot gnu dot org wrote:
> What do you mean, "less or equal visibility to their enclosing scope?"

Where default > protected > hidden > internal, if a class or namespace 
has a specified visibility, nested scopes should have the same 
visibility or something later in the above sequence.

> My meta-goal is to try and give namespace and class scope visibilty attributes
> similar meanings. Do you think this is worthwhile, possible, and do you think
> this is a good idea?

Yes, guess I should have said that before nitpicking the examples.

> Yeah, maybe default namespace with hidden nested makes more sense for the
> examples. However, wouldn't both have to be supported, anyway? 

Both would be supported by the simplest implementation, though we could 
enforce rules like the above if we wanted to.  Mostly I was just puzzled 
that the examples in both PRs seemed inside out, and wondered if I was 
missing some compelling use case.

Jason


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21764


^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Bug c++/21764] visibility attributes on namespace scope
       [not found] <bug-21764-365@http.gcc.gnu.org/bugzilla/>
                   ` (4 preceding siblings ...)
  2005-11-18  6:15 ` jason at redhat dot com
@ 2005-11-18 19:39 ` geoffk at geoffk dot org
  2005-12-02 22:16 ` jason at gcc dot gnu dot org
                   ` (4 subsequent siblings)
  10 siblings, 0 replies; 14+ messages in thread
From: geoffk at geoffk dot org @ 2005-11-18 19:39 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #9 from geoffk at geoffk dot org  2005-11-18 19:39 -------
Subject: Re:  visibility attributes on namespace scope


On 17/11/2005, at 10:15 PM, jason at redhat dot com wrote:

> ------- Comment #8 from jason at redhat dot com  2005-11-18 06:15  
> -------
> Subject: Re:  visibility attributes on namespace scope
>
> bkoz at gcc dot gnu dot org wrote:
>> What do you mean, "less or equal visibility to their enclosing  
>> scope?"
>
> Where default > protected > hidden > internal, if a class or namespace
> has a specified visibility, nested scopes should have the same
> visibility or something later in the above sequence.

Although this makes sense for classes, I'm not sure it does for  
namespaces:

namespace foo __attribute__((visibility("hidden"))) {
   void foo();
   void bar() __attribute__((visibility("default")));
}

This seems reasonable to me; the attribute on the namespace is  
setting a default, which is overridden on bar().


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21764


^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Bug c++/21764] visibility attributes on namespace scope
       [not found] <bug-21764-365@http.gcc.gnu.org/bugzilla/>
                   ` (5 preceding siblings ...)
  2005-11-18 19:39 ` geoffk at geoffk dot org
@ 2005-12-02 22:16 ` jason at gcc dot gnu dot org
  2005-12-13  6:46 ` jason at gcc dot gnu dot org
                   ` (3 subsequent siblings)
  10 siblings, 0 replies; 14+ messages in thread
From: jason at gcc dot gnu dot org @ 2005-12-02 22:16 UTC (permalink / raw)
  To: gcc-bugs



-- 

jason at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2005-09-30 05:18:21         |2005-12-02 22:16:52
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21764


^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Bug c++/21764] visibility attributes on namespace scope
       [not found] <bug-21764-365@http.gcc.gnu.org/bugzilla/>
                   ` (6 preceding siblings ...)
  2005-12-02 22:16 ` jason at gcc dot gnu dot org
@ 2005-12-13  6:46 ` jason at gcc dot gnu dot org
  2006-03-21  3:19 ` jason at gcc dot gnu dot org
                   ` (2 subsequent siblings)
  10 siblings, 0 replies; 14+ messages in thread
From: jason at gcc dot gnu dot org @ 2005-12-13  6:46 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #10 from jason at gcc dot gnu dot org  2005-12-13 06:46 -------
The semantics of this feature are pretty obvious for simple testcases.  But
since there's no One Definition Rule for namespaces, it's perfectly valid for
different chunks of the same namespace to have different attributes.

So, if you have:

namespace Foo __attribute ((visibility ("hidden"))
{
  void f();
}

namespace Foo
{
  void g();
}

what is the visibility of Foo::g?  Should the namespace extension inherit the
visibility of the previous namespace definition, or should visibility
attributes only affect declarations within that specific block?

If the former, should we only allow attributes on the first definition of a
particular namespace in a translation unit?  That was my initial assumption,
but then I realized that's not very composable.  On the other hand, perhaps if
we're going to specify visibility for a namespace, we want it to be applied
consistently to everything in the namespace.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21764


^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Bug c++/21764] visibility attributes on namespace scope
       [not found] <bug-21764-365@http.gcc.gnu.org/bugzilla/>
                   ` (7 preceding siblings ...)
  2005-12-13  6:46 ` jason at gcc dot gnu dot org
@ 2006-03-21  3:19 ` jason at gcc dot gnu dot org
  2006-03-21 16:32 ` pinskia at gcc dot gnu dot org
  2006-08-28 12:22 ` jakub at gcc dot gnu dot org
  10 siblings, 0 replies; 14+ messages in thread
From: jason at gcc dot gnu dot org @ 2006-03-21  3:19 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #11 from jason at gcc dot gnu dot org  2006-03-21 03:19 -------
Subject: Bug 21764

Author: jason
Date: Tue Mar 21 03:19:06 2006
New Revision: 112239

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112239
Log:
        PR c++/21764
        * c-pragma.c (visstack): Move out of handle_pragma_visibility.
        (push_visibility, pop_visibility): Likewise.
        * c-pragma.h: Declare them.
        * cp/name-lookup.h (struct cp_binding_level): Add has_visibility
        bitfield.
        * cp/name-lookup.c: Include c-pragma.h.
        (push_namespace_with_attribs): Split out from push_namespace.
        Push visibility if appropriate.  Set TREE_PUBLIC on namespaces.
        (leave_scope): Pop visibility if appropriate.
        * cp/parser.c (cp_parser_declaration, cp_parser_namespace_name): Allow
        attributes on namespace declarations.

        PR c++/19238
        * cp/decl.c (cp_finish_decl): Call determine_visibility later.
        (start_preparsed_function): Likewise.
        * cp/cp-tree.h (CP_TYPE_CONTEXT, TYPE_NAMESPACE_SCOPE_P): New macros.
        (TYPE_CLASS_SCOPE_P, TYPE_FUNCTION_SCOPE_P): New macros.
        * cp/decl2.c (determine_visibility_from_class): Split out from...
        (determine_visibility): ...here.  Handle function scope and
        nested classes.
        (import_export_decl): Move visibility handling to
        determine_visibility_from_class.

Added:
    trunk/gcc/testsuite/g++.dg/ext/visibility/local1.C
    trunk/gcc/testsuite/g++.dg/ext/visibility/namespace1.C
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/c-pragma.c
    trunk/gcc/c-pragma.h
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/cp-tree.h
    trunk/gcc/cp/decl.c
    trunk/gcc/cp/decl2.c
    trunk/gcc/cp/name-lookup.c
    trunk/gcc/cp/name-lookup.h
    trunk/gcc/cp/parser.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21764


^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Bug c++/21764] visibility attributes on namespace scope
       [not found] <bug-21764-365@http.gcc.gnu.org/bugzilla/>
                   ` (8 preceding siblings ...)
  2006-03-21  3:19 ` jason at gcc dot gnu dot org
@ 2006-03-21 16:32 ` pinskia at gcc dot gnu dot org
  2006-08-28 12:22 ` jakub at gcc dot gnu dot org
  10 siblings, 0 replies; 14+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2006-03-21 16:32 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #12 from pinskia at gcc dot gnu dot org  2006-03-21 16:32 -------
Fixed.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.2.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21764


^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Bug c++/21764] visibility attributes on namespace scope
       [not found] <bug-21764-365@http.gcc.gnu.org/bugzilla/>
                   ` (9 preceding siblings ...)
  2006-03-21 16:32 ` pinskia at gcc dot gnu dot org
@ 2006-08-28 12:22 ` jakub at gcc dot gnu dot org
  10 siblings, 0 replies; 14+ messages in thread
From: jakub at gcc dot gnu dot org @ 2006-08-28 12:22 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #13 from jakub at gcc dot gnu dot org  2006-08-28 12:22 -------
Subject: Bug 21764

Author: jakub
Date: Mon Aug 28 12:22:14 2006
New Revision: 116504

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116504
Log:
2006-03-20  Jason Merrill  <jason@redhat.com>

        PR c++/21764
        * c-pragma.c (visstack): Move out of handle_pragma_visibility.
        (push_visibility, pop_visibility): Likewise.
        * c-pragma.h: Declare them.
cp/
        PR c++/21764, c++/19238
        * decl.c (cp_finish_decl): Call determine_visibility later.
        (start_preparsed_function): Likewise.
        * cp-tree.h (CP_TYPE_CONTEXT, TYPE_NAMESPACE_SCOPE_P): New macros.
        (TYPE_CLASS_SCOPE_P, TYPE_FUNCTION_SCOPE_P): New macros.
        * name-lookup.h (struct cp_binding_level): Add has_visibility 
        bitfield.
        * name-lookup.c: Include c-pragma.h.
        (push_namespace_with_attribs): Split out from push_namespace.
        Push visibility if appropriate.  Set TREE_PUBLIC on namespaces.
        (leave_scope): Pop visibility if appropriate.
        * decl2.c (determine_visibility_from_class): Split out from...
        (determine_visibility): ...here.  Handle function scope and 
        nested classes.
        (import_export_decl): Move visibility handling to 
        determine_visibility_from_class.
        * parser.c (cp_parser_declaration, cp_parser_namespace_name): Allow
        attributes on namespace declarations.

Added:
    branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/local1.C
   
branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/namespace1.C
Modified:
    branches/redhat/gcc-4_1-branch/gcc/ChangeLog
    branches/redhat/gcc-4_1-branch/gcc/c-pragma.c
    branches/redhat/gcc-4_1-branch/gcc/c-pragma.h
    branches/redhat/gcc-4_1-branch/gcc/cp/ChangeLog
    branches/redhat/gcc-4_1-branch/gcc/cp/cp-tree.h
    branches/redhat/gcc-4_1-branch/gcc/cp/decl.c
    branches/redhat/gcc-4_1-branch/gcc/cp/decl2.c
    branches/redhat/gcc-4_1-branch/gcc/cp/name-lookup.c
    branches/redhat/gcc-4_1-branch/gcc/cp/name-lookup.h
    branches/redhat/gcc-4_1-branch/gcc/cp/parser.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21764


^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Bug c++/21764] visibility attributes on namespace scope
  2005-05-26  7:32 [Bug c++/21764] New: " bkoz at gcc dot gnu dot org
  2005-05-26 12:02 ` [Bug c++/21764] " giovannibajo at libero dot it
  2005-05-26 16:04 ` bkoz at gcc dot gnu dot org
@ 2005-05-26 20:12 ` pinskia at gcc dot gnu dot org
  2 siblings, 0 replies; 14+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-05-26 20:12 UTC (permalink / raw)
  To: gcc-bugs


------- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-26 20:10 -------
Confirmed.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2005-05-26 20:10:04
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21764


^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Bug c++/21764] visibility attributes on namespace scope
  2005-05-26  7:32 [Bug c++/21764] New: " bkoz at gcc dot gnu dot org
  2005-05-26 12:02 ` [Bug c++/21764] " giovannibajo at libero dot it
@ 2005-05-26 16:04 ` bkoz at gcc dot gnu dot org
  2005-05-26 20:12 ` pinskia at gcc dot gnu dot org
  2 siblings, 0 replies; 14+ messages in thread
From: bkoz at gcc dot gnu dot org @ 2005-05-26 16:04 UTC (permalink / raw)
  To: gcc-bugs


------- Additional Comments From bkoz at gcc dot gnu dot org  2005-05-26 15:57 -------

nested namespaces should work the same as nested classes.

:)

Since that that doesn't seem to be defined anywhere (am I wrong, or should I
open a tracker for that in bugzilla), I'd say:

case 1:
namespace outer __attribute__ ((visibility ("default") ))
{
  namespace inner __attribute__ ((visibility ("hidden") ))
  {
     struct A { int i; };
  }
}

case 2:
namespace outer __attribute__ ((visibility ("hidden") ))
{
  namespace inner __attribute__ ((visibility ("default") ))
  {
     struct B { int i; };
  }
}

Would have the following, easy (?) semantics: hidden makes all enclosed
namespaces hidden. Thus, it really doesn't make sense to nest hidden namespaces.

I think the only other reasonable alternative is to say that the nearest scope's
visibility attribute is the one in effect.

However, I've not really looked at the way nested classes are handled. Any
insights there? 

What ever is done, these two things should be treated consistently.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21764


^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Bug c++/21764] visibility attributes on namespace scope
  2005-05-26  7:32 [Bug c++/21764] New: " bkoz at gcc dot gnu dot org
@ 2005-05-26 12:02 ` giovannibajo at libero dot it
  2005-05-26 16:04 ` bkoz at gcc dot gnu dot org
  2005-05-26 20:12 ` pinskia at gcc dot gnu dot org
  2 siblings, 0 replies; 14+ messages in thread
From: giovannibajo at libero dot it @ 2005-05-26 12:02 UTC (permalink / raw)
  To: gcc-bugs


------- Additional Comments From giovannibajo at libero dot it  2005-05-26 10:18 -------
Please, explicitally specify how you would like this to work with nested 
namespaces.

Also, whoever implements this should also make sure it works correctly with 
namespace:

namespace N __attribute__((visibility ("hidden")))
{
   template <class T>
   struct B
   {
        B() {}
        ~B() {}
        void foo(void) {}
   };

   template <>
   struct B<int>;
}

template <>
struct ::N::B<int>
{
   void bar(void) {}    // still hidden!
}


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21764


^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2006-08-28 12:22 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <bug-21764-365@http.gcc.gnu.org/bugzilla/>
2005-11-04 13:05 ` [Bug c++/21764] visibility attributes on namespace scope pinskia at gcc dot gnu dot org
2005-11-04 17:05 ` bkoz at gcc dot gnu dot org
2005-11-17 22:55 ` jason at gcc dot gnu dot org
2005-11-17 23:53 ` bkoz at gcc dot gnu dot org
2005-11-18  6:15 ` jason at redhat dot com
2005-11-18 19:39 ` geoffk at geoffk dot org
2005-12-02 22:16 ` jason at gcc dot gnu dot org
2005-12-13  6:46 ` jason at gcc dot gnu dot org
2006-03-21  3:19 ` jason at gcc dot gnu dot org
2006-03-21 16:32 ` pinskia at gcc dot gnu dot org
2006-08-28 12:22 ` jakub at gcc dot gnu dot org
2005-05-26  7:32 [Bug c++/21764] New: " bkoz at gcc dot gnu dot org
2005-05-26 12:02 ` [Bug c++/21764] " giovannibajo at libero dot it
2005-05-26 16:04 ` bkoz at gcc dot gnu dot org
2005-05-26 20:12 ` pinskia at gcc dot gnu dot org

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