[Bug other/15000] New: Support setting the default symbol visibility for ELF

[Bug other/15000] New: Support setting the default symbol visibility for ELF

[bryner at brianryner dot com]

This is spun off from bug 9283.

It would be useful for gcc to support setting the default ELF symbol visibility
so that you can make symbols be hidden by default.  This can greatly benefit
code generation on ELF (for details, see Ulrich Drepper's excellent DSO paper at
http://people.redhat.com/~drepper/) but without the source-level intrusiveness
of specifying hidden visibility manually.  It also makes it so you can use
visibility("default") analogously to dllexport on Windows, which is good for
cross-platform projects.

-- 
           Summary: Support setting the default symbol visibility for ELF
           Product: gcc
           Version: 3.4.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P2
         Component: other
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: bryner at brianryner dot com
                CC: gcc-bugs at gcc dot gnu dot org,s_gccbugzilla at nedprod
                    dot com
  GCC host triplet: i686-pc-linux-gnu


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

[Bug other/15000] Support setting the default symbol visibility for ELF

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-04-18 03:42 -------
Confirmed, 
Some related things from the mailing lists:
<http://gcc.gnu.org/ml/gcc/2002-08/msg01203.html>.
<http://gcc.gnu.org/ml/gcc-bugs/2003-11/msg02213.html>.

And more too that are escaping me right now.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2004-04-18 03:42:52
               date|                            |


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

[Bug other/15000] Support setting the default symbol visibility for ELF

[bryner at brianryner dot com]

------- Additional Comments From bryner at brianryner dot com  2004-04-18 04:27 -------
(in response to bug 9283, comment #18):
> I also changed how visibility is taken into account when making a symbol local 
> which lets the compiler and optimiser work better. Basically anything which 
> doesn't have default visibility is made local. I also made all inlineable code 
> always the -fvisibility setting no matter what and a few other things.

I'm confused by your local_p change, actually.  I don't see how it changes the
current behavior at all... it appears to already be setting local_p=true for
decls with DECL_VISIBILITY != VISIBILITY_DEFAULT.


> No, I modified the function which creates a new decl to simply set the 
> visibility to whatever the command line arg specified. This causes all decls to 
> be that visibility by default which is just what we want. There are no knock-on 

If you treat a symbol in an external DSO as hidden visibility, the compiler will
not generate a PLT jump for that function call, and the linker will be forced to
generate a text section relocation.  I'm pretty sure that's bad (prevents
sharing of the text section across processes).  So I really think we need to
provide an easy way for the user to ensure that declarations of functions in
external DSOs are treated as default visibility.

Implementing -fvisibility-default _efficiently_ may be difficult.  We don't want
to have to generate the assembler name for each decl we encounter to check if
it's one with visibility overridden.  It would be better if we could generate a
lookup table from the symbol file which could be compared against the decl
without any additional string manipulation or allocations.  I think for C that
just means comparing the DECL_NAMEs; for C++ the DECL_NAME doesn't uniquely
identify the resulting symbol so we'd need to extract all of the relevant info
from the mangled symbol name.

One idea that _doesn't_ require implementing -fvisibility-default= is to
generate and use a precompiled header that brings in all of the declarations for
those functions and compile the header without -fvisibility=hidden.  Or, along
the same lines, implement some construct you can wrap #includes with to say that
the header declares functions that have default visibility.


-- 


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

[Bug other/15000] Support setting the default symbol visibility for ELF

[s_gccbugzilla at nedprod dot com]

------- Additional Comments From s_gccbugzilla at nedprod dot com  2004-04-19 02:36 -------
Well, I shake my head sometimes. I tried suggesting this enhancement before and 
was rather forcibly told it was too similar to PR 9283 and please go post there.

In the end, I don't give a toss how this is done, who gets the credit or 
anything else. I simply want the feature added in a timely fashion. I'm glad 
that people who were rubbishing the mere idea a few months ago have changed 
their tune. But this so called process is making me shake my head :(

> I'm confused by your local_p change, actually.  I don't see how it changes the
> current behavior at all... it appears to already be setting local_p=true for
> decls with DECL_VISIBILITY != VISIBILITY_DEFAULT.

No that was the behaviour before I altered it - now factors such as whether it 
was declared static, is a weak symbol etc. take precedence over visibility 
specification. This is required for correct operation.

> If you treat a symbol in an external DSO as hidden visibility, the compiler 
will
> not generate a PLT jump for that function call, and the linker will be forced 
to
> generate a text section relocation.  I'm pretty sure that's bad (prevents
> sharing of the text section across processes).  So I really think we need to
> provide an easy way for the user to ensure that declarations of functions in
> external DSOs are treated as default visibility.

They already are. If a symbol is merely declared and not defined (ie; 
TREE_PUBLIC() is true or DECL_EXTERNAL() is true), it is always non-local. I 
examined the assembler output during testing to ensure the various combinations 
were correct. However, I am not an expert with ELF nor GCC, so I may have made a 
mistake causing loss of efficiency (however I can guarantee the Boost.Python 
library as well as my own work far better and correctly with this patch enabled)
.

> Implementing -fvisibility-default _efficiently_ may be difficult.  We don't 
want
> to have to generate the assembler name for each decl we encounter to check if
> it's one with visibility overridden.  It would be better if we could generate 
a
> lookup table from the symbol file which could be compared against the decl
> without any additional string manipulation or allocations.  I think for C that
> just means comparing the DECL_NAMEs; for C++ the DECL_NAME doesn't uniquely
> identify the resulting symbol so we'd need to extract all of the relevant info
> from the mangled symbol name.

That is your baby. I don't think it's necessary right now as the GNU linker 
provides version scripts which are good enough for the time being.

> One idea that _doesn't_ require implementing -fvisibility-default= is to
> generate and use a precompiled header that brings in all of the declarations 
for
> those functions and compile the header without -fvisibility=hidden.  Or, along
> the same lines, implement some construct you can wrap #includes with to say 
that
> the header declares functions that have default visibility.

Again, we're getting off track here. Right now anyone trying to use a lot of 
template metaprogramming with GCC is really suffering because of GCC exporting 
far too many unnecessary symbols. Ask anyone using the Boost library regularly - 
hell, go ask Dave Abrahams himself.

I am no GCC hacker nor have any wish to become one - when this is integrated you 
won't be seeing more of me. However when the tools are not cutting the mustard 
you can either whine or do something about it.

The patch I have submitted fixes these woes right here right now. Other issues 
are important but they are other issues which can be solved at another time. 
What we need for this enhancement now is for someone expert with GCC internals 
to review the patch and if it's good to apply it to CVS head as soon as 
possible. Other related features and enhancements can come later.

(Sorry if I am being too brusque, but I'm getting the distinct feeling that the 
merry-go-round is rotating more than it should)

Cheers,
Niall


-- 


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

[Bug other/15000] Support setting the default symbol visibility for ELF

[s_gccbugzilla at nedprod dot com]

------- Additional Comments From s_gccbugzilla at nedprod dot com  2004-04-19 02:41 -------
You might also want to read:

http://aspn.activestate.com/ASPN/Mail/Message/C++-sig/2041976

Cheers,
Niall


-- 


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

[Bug other/15000] Support setting the default symbol visibility for ELF

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-04-19 02:52 -------
Niall,
The reason why we told you to post it with PR 9283 is that you had filed a bug which said that visibility 
was broken on classes and then you went on a rampage on how it was not a dup of your bug as it was 
not being default, you should have filed a seperate one like this one before this mess came about.  Also 
ELF has always had different linkage than windows file format (I forgot what is called) so the idea of 
everything exported was that way from the beginning, the idea it should be different is just recently.

-- 


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

[Bug other/15000] Support setting the default symbol visibility for ELF

[bryner at brianryner dot com]

------- Additional Comments From bryner at brianryner dot com  2004-04-19 15:01 -------
(In reply to comment #4)
> So I really think we need to
> > provide an easy way for the user to ensure that declarations of functions in
> > external DSOs are treated as default visibility.
> 

Local binding is not the same as hidden visibility.  Your patch changes the
default visibility for declarations.  Consider this simple test:

foo.c:
#include <stdlib.h>

int gtk_init (int *argc, char ***argv) __attribute__ ((visibility ("hidden")));

void foo ()
{
  gtk_init (NULL, NULL);
}

gcc -shared -fPIC -o libfoo.so foo.c `pkg-config --libs gtk+-2.0`

readelf -d libfoo.so|grep TEXTREL
 0x00000016 (TEXTREL)                    0x0

I expect if you run readelf -d on the library you compiled with this patch you
will notice the TEXTREL there as well.  If you read drepper's paper you'll see
that's something we want to avoid.  And to avoid that, we have to distinguish
between a declaration of a function that will be defined inside the same DSO as
the caller, and one that will be defined in a DSO that is linked against.

-- 


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

[Bug other/15000] Support setting the default symbol visibility for ELF

[s_gccbugzilla at nedprod dot com]

------- Additional Comments From s_gccbugzilla at nedprod dot com  2004-04-19 19:25 -------
> Local binding is not the same as hidden visibility.  Your patch changes the
> default visibility for declarations.  Consider this simple test:

No, that's the point of the DECL_VISIBILITYSPECIFIED() macro - it means the 
compiler can determine if a declaration specified its visibility or if it was 
inferred from the compiland default. Therefore if a declaration specifies a 
visibility which just happens to be identical to the compiland default, we know 
the difference.

Declarations sans definition are always global bound and default visibility. 
Unless their declaration specifies a non default visibility.

> I expect if you run readelf -d on the library you compiled with this patch you
> will notice the TEXTREL there as well.  If you read drepper's paper you'll see
> that's something we want to avoid.  And to avoid that, we have to distinguish
> between a declaration of a function that will be defined inside the same DSO 
as
> the caller, and one that will be defined in a DSO that is linked against.

I thought perhaps some hard examples will be useful here. I wrote this simple 
program:

#include <stdio.h>

extern "C" int printfExternal(const char *f);
extern "C" int printfHere(const char *f);

int printfHere(const char *s)
{
  return 0;
}

static int printfLocal(const char *s)
{
  return 0;
}

int foo(void)
{
  printf("Hello world\n");
  printfExternal("Hello world\n");
  printfHere("Hello world\n");
  printfLocal("Hello world\n");
  return 0;
}

In this, printfExternal() is a symbol defined in another DSO which we use in 
ours. printfHere() is a symbol defined for all objects in this DSO but not for 
use outside this DSO. And printfLocal() is local to this module only. I also 
included printf() from glibc for completeness' sake.

When compiled with normal GCC:

    65: 000007c2    10 FUNC    LOCAL  DEFAULT   10 _Z11printfLocalPKc
    69: 000007cc    85 FUNC    GLOBAL DEFAULT   10 _Z3foov
    71: 00000660     0 FUNC    GLOBAL DEFAULT    8 _init
    73: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND printfExternal
    74: 000007b8    10 FUNC    GLOBAL DEFAULT   10 printfHere
    76: 00000000    57 FUNC    GLOBAL DEFAULT  UND printf@@GLIBC_2.0

With -fvisibility=hidden:

    65: 00000762    10 FUNC    LOCAL  DEFAULT   10 _Z11printfLocalPKc
    66: 0000076c    85 FUNC    LOCAL  HIDDEN    10 _Z3foov
    72: 00000618     0 FUNC    GLOBAL DEFAULT    8 _init
    74: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND printfExternal
    68: 00000758    10 FUNC    LOCAL  HIDDEN    10 printfHere
    76: 00000000    57 FUNC    GLOBAL DEFAULT  UND printf@@GLIBC_2.0

As you can see, both visibility and local binding is correctly managed. Existing 
DSO's not compiled with support for this feature continue to be perfectly 
usuable. This requires symbols which are declared but not defined to be marked 
as global and default visibility.

If you are merely referring to text relocations in general and there being too 
many of them in general, I would argue that if a library does not manually 
specify visibility and does not use -fvisibility then that is an unfortunate 
consequence. The maintainers of such libraries should make it a priority to 
update their software rather than GCC introducing unnecessary complexity. 
However, in whichever case, that's a related feature which can be added at a 
later time - right now, this is good to go.

Cheers,
Niall


-- 


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

[Bug other/15000] Support setting the default symbol visibility for ELF

[bryner at brianryner dot com]

------- Additional Comments From bryner at brianryner dot com  2004-04-19 21:29 -------
And on that same program, what is the output of  readelf -d <binary>|grep
TEXTREL, with and without -fvisibility=hidden? (I don't have a build with your
patch handy)  Or are you saying that you're aware that this will introduce a
text relocation but you're not worried about it?


-- 


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

[Bug other/15000] Support setting the default symbol visibility for ELF

[s_gccbugzilla at nedprod dot com]

------- Additional Comments From s_gccbugzilla at nedprod dot com  2004-04-19 23:45 -------
(In reply to comment #9)

> And on that same program, what is the output of  readelf -d <binary>|grep
> TEXTREL, with and without -fvisibility=hidden? (I don't have a build with your
> patch handy)  Or are you saying that you're aware that this will introduce a
> text relocation but you're not worried about it?

No, I'm saying there are precisely as many text relocations with or without 
-fvisibility. In other words, this patch does nothing to reduce the number, but 
it also does nothing to increase the number.

I have a simple solution to your problem - all declarations which are global 
within the DSO but not available outside the DSO should be declared explicitly 
as visibility hidden. I have enhanced my previous patch to support this - now 
when you explicitly specify hidden, it always generates a locally bound 
reference.

MSVC has no such concept, but to not use this doesn't break code, it simply 
produces a less efficient binary. Therefore those coming from MSVC based code 
can quickly produce a near-optimal ELF binary but they'll need to put in a 
little more work to go all the way. Most importantly of all it transparently 
handles compatibility with older Unix libraries not specifying visibility.

You can see updated docs at http://www.nedprod.com/programs/gccvisibility.html

I've attached the new patch to this bug report. I still must review your newer 
patch, when I do I'll resubmit this newest patch to gcc-bugs.

Cheers,
Niall



-- 


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

[Bug other/15000] Support setting the default symbol visibility for ELF

[bryner at brianryner dot com]

------- Additional Comments From bryner at brianryner dot com  2004-04-20 06:29 -------
Ok, I see what you're saying now.  Your patch only changes the visibility for
functions which don't give an explicit visibility _and_ are defined within the
current source file.  Sorry for missing that earlier.  So this will indeed not
break anything.  Except, perhaps, for function-pointer-equality... consider
taking the address of printfHere from within the given .c file, and from another
.c file linked into the same .so -- I think the former will give the real
function address, while the latter will give the PLT slot address.

My main concern with this approach is that for C++, it's common to define only a
single class within a given source file.  This patch will avoid the PLT overhead
on calls to internal methods from inside that source file, but it does nothing
for calling methods on a class from another source file within the DSO -- unless
you explicitly annotate all of the method declarations with
visibility("hidden").  And at least for me that's a major thing I'd like to see
from this option - avoiding the PLT overhead for calls to methods in other
object files that are linked into the same DSO, _without_ adding a "hidden"
declaration to hundreds of class declarations.  Perhaps we're looking for
different things from this patch.

-- 


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

[Bug other/15000] Support setting the default symbol visibility for ELF

[s_gccbugzilla at nedprod dot com]

------- Additional Comments From s_gccbugzilla at nedprod dot com  2004-04-21 23:42 -------
(In reply to comment #13)
> Ok, I see what you're saying now.  Your patch only changes the visibility for
> functions which don't give an explicit visibility _and_ are defined within the
> current source file.  Sorry for missing that earlier.  So this will indeed not
> break anything. 

Spot on! Maybe I wasn't being clear earlier, but I did say that I had compiled 
the latest release of my library plus a Boost.Python based bindings library 
using this new facility with excellent success. This strongly implies I'd 
covered most of the bases.

> Except, perhaps, for function-pointer-equality... consider
> taking the address of printfHere from within the given .c file, and from 
another
> .c file linked into the same .so -- I think the former will give the real
> function address, while the latter will give the PLT slot address.

This could only happen if a PLT marked symbol suddenly became not PLT. Since the 
default is "everything is PLT until known otherwise" it fails safe good. I 
assume that GCC would get a function pointer by fetching it through the GOT if 
it needed to before comparison, therefore the pointers should be equal even if 
fetched from different DSO's.

However I'll rig up a test and check for sure. Question: aren't PLT symbols 
always marked with @PLT on the end so if you tried accessing that symbol with a 
mismatched idea of its binding the symbol lookup would surely fail?

> but it does nothing
> for calling methods on a class from another source file within the DSO -- 
unless
> you explicitly annotate all of the method declarations with
> visibility("hidden"). 

Yes, that's correct.

> And at least for me that's a major thing I'd like to see
> from this option - avoiding the PLT overhead for calls to methods in other
> object files that are linked into the same DSO, _without_ adding a "hidden"
> declaration to hundreds of class declarations.  Perhaps we're looking for
> different things from this patch.

No, I think it's a case of emphasis. With the patch, the situation is no worse 
than before and it's certainly a lot better. That to my mind means we can apply 
the patch now unless by doing so, we are permanently preventing another solution 
to the PLT overhead problem.

I don't think that's the case, so are we in accord to get this into CVS HEAD 
now?

Regarding your problem, I personally feel marking internal classes as hidden 
explicitly is a good idea. Why? Two reasons:

1. Well designed public header files usually only define public classes. They 
very occasionally define private ones though and in this situation, we must 
prevent the programmer thinking they can use internal classes as public ones (if 
they are using the header files as documentation as is unfortunately only too 
common). If they are explicitly marked as hidden, this does the job and 
documentation tools like doxygen could be modified to exclude completely 
anything explicitly marked as hidden.

2. Class visibility is an integral part of good design. By forcing programmers 
to specify visibility is thus in the same form as forcing programmers to specify 
throw() on declarations or public/protected/private. It aids readability, 
generates better quality code and is self-documenting.

However, I suppose it's best to give the programmer the choice of what to use. 
How about a new #pragma which for the declarations contained within it marks 
them all as local to the current DSO? I can patch in support for this relatively 
easy. What do you think?

Cheers,
Niall


-- 


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

[Bug other/15000] Support setting the default symbol visibility for ELF

[bryner at brianryner dot com]

------- Additional Comments From bryner at brianryner dot com  2004-04-22 02:42 -------
(In reply to comment #14)
> Regarding your problem, I personally feel marking internal classes as hidden 
> explicitly is a good idea.

In my case all of the public classes are already marked as exported (for
dllexport on msvc++).  Why should I then have to also mark all of my internal
classes (which in my case, vastly outnumber the public classes) as hidden?  It
uglifies the source as well (though not nearly as much once bug 9283 lands).

The difference, of course, is that in the system headers on Windows, all of the
functions exported by system libraries are explicitly marked dllexport.  If all
of the system headers on Linux marked exported functions as default visbility,
we could go ahead and give the default visibility to all declarations that don't
override it.  But as I said earlier, I think getting library authors to do this
will be difficult.

> However, I suppose it's best to give the programmer the choice of what to use. 
> How about a new #pragma which for the declarations contained within it marks 
> them all as local to the current DSO? I can patch in support for this relatively 
> easy. What do you think?

I think given gcc's trend towards removing use of #pragma there could be some
opposition to that approach.  However, I think it could be useful especially for
C, where there is no way to wrap up a bunch of functions together and mark them
hidden.  Headers which declare non-public functions could simply wrap them:

#pragma visibility hidden
void internal_function (...);
...
#pragma visibility default


-- 


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

[Bug other/15000] Support setting the default symbol visibility for ELF

[s_gccbugzilla at nedprod dot com]

------- Additional Comments From s_gccbugzilla at nedprod dot com  2004-04-22 18:16 -------
(In reply to comment #15)
> > Regarding your problem, I personally feel marking internal classes as hidden 
> > explicitly is a good idea.
> 
> In my case all of the public classes are already marked as exported (for
> dllexport on msvc++).  Why should I then have to also mark all of my internal
> classes (which in my case, vastly outnumber the public classes) as hidden? 

Because Windows and Unix behave fundamentally differently in how they implement 
shared libraries. Under Windows everything is default hidden unless specified 
otherwise. Under Unix it's the opposite. Good design demands you always specify 
when something is different to the default eg; you use public: when in a class 
or private: in a struct to change from the default. C++ is particularly bad for 
making you have to type more code to make better quality code.

Remember, you don't HAVE to specify all your internal classes as hidden. The DSO 
will work perfectly fine if you don't, however it will be suboptimal.

> It uglifies the source as well (though not nearly as much once bug 9283 lands)

It's not that bad. I know of no source which actually uses __declspec directly 
in the code, it's always via a macro. Similarly here DLLEXPORT and DLLPRIVATE 
are reasonable pseudonyms for that long __attribute__ spec. This I think 
actually aids readability, improves the interface contract and generally is a 
good thing (TM).

> The difference, of course, is that in the system headers on Windows, all of 
the
> functions exported by system libraries are explicitly marked dllexport.  If 
all
> of the system headers on Linux marked exported functions as default visbility,
> we could go ahead and give the default visibility to all declarations that 
don't
> override it.  But as I said earlier, I think getting library authors to do 
this
> will be difficult.

glibc I think already does the right thing here, but yes you're right, we have 
bad precedent against us. I think the people who originally implemented DSO's on 
Linux screwed up by failing to do the right thing (and insisting on 
non-compatibility with Solaris etc.). Windows has it correct here, and Unix is 
wrong - simple as that. However, things are as they are, so we forge ahead.
 
> > easy. What do you think?
> 
> I think given gcc's trend towards removing use of #pragma there could be some
> opposition to that approach.  However, I think it could be useful especially 
for
> C, where there is no way to wrap up a bunch of functions together and mark 
them
> hidden.  Headers which declare non-public functions could simply wrap them:
> 
> #pragma visibility hidden
> void internal_function (...);
> ...
> #pragma visibility default

There is only (valid) opposition because you can't form #pragma's in 
preprocessor magic. However I would have thought the same engine works behind 
#pragma as behind that pragma statement replacement (I forget the details) so it 
still kills both birds with one stone.

Apart from the issue regarding how to mark internal classes as hidden to remove 
the PLT overhead, are we in complete agreement about the form of this patch? Is 
your new patch and its use of the type decl instead of the class stack to store 
visibility a better solution here? I would have thought it makes things unclear 
for GCC maintainers as the symbol visibility is no longer stored with the symbol 
but rather with that symbol's type info which might cause some to get confused 
with the type info's visibility rather than that of which it describes?

Can you tell me what Jason Merrill's argument for storing it within the type 
decl instead was?

Cheers,
Niall


-- 


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

[Bug other/15000] Support setting the default symbol visibility for ELF

[bryner at brianryner dot com]

------- Additional Comments From bryner at brianryner dot com  2004-04-22 18:35 -------
(In reply to comment #16)
Is 
> your new patch and its use of the type decl instead of the class stack to store 
> visibility a better solution here? I would have thought it makes things unclear 
> for GCC maintainers as the symbol visibility is no longer stored with the symbol 
> but rather with that symbol's type info which might cause some to get confused 
> with the type info's visibility rather than that of which it describes?

I think the reasoning is just that we already have an appropriate place to store
this information, so why invent something new.  Note that the attribute stored
on the type decl is basically used the same way that DECL_VISIBILITYSPECIFIED is
in your patch.  DECL_VISIBILITY is still used for determining the actual
visibility of a symbol.  Also, the 'overrides' thing requires a linear search of
the overrides list every time you assign symbol visibility, so why not just do a
linear search of the attributes list of the decl instead.  There's something to
be said for simplicity as well, and the second patch is certainly much shorter
than the original.

Could you please elaborate on your changes related to inline and virtual functions?

-- 


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

[Bug other/15000] Support setting the default symbol visibility for ELF

[s_gccbugzilla at nedprod dot com]

------- Additional Comments From s_gccbugzilla at nedprod dot com  2004-04-22 20:19 -------
(In reply to comment #17)
> > Is 
> > your new patch and its use of the type decl instead of the class stack to 
store 
> > visibility a better solution here? 
> 
> I think the reasoning is just that we already have an appropriate place to 
store
> this information, so why invent something new.  Note that the attribute stored
> on the type decl is basically used the same way that DECL_VISIBILITYSPECIFIED 
is
> in your patch.  DECL_VISIBILITY is still used for determining the actual
> visibility of a symbol.  Also, the 'overrides' thing requires a linear search 
of
> the overrides list every time you assign symbol visibility, so why not just do 
a
> linear search of the attributes list of the decl instead.  There's something 
to
> be said for simplicity as well, and the second patch is certainly much shorter
> than the original.

Sounds spot on to me. I'll remake my patch based on your new one. This may 
happen tonight, depending on other factors.

> Could you please elaborate on your changes related to inline and virtual 
functions?

Yes. As Dave Abrahams pointed out in that link I posted previously, we must 
ensure that setting class member visibility follows the same semantics as MSVC 
or nasty problems creep in (and he should certainly know, he's an extremely 
capable programmer). To my knowledge, MSVC treats inlineable code as a 
non-external symbol because it assumes it'll be assembled at the point of use - 
therefore almost all templated code won't appear in the DLL's export table. This 
implies that instantiations of templates have one per DLL and that 
instantiations are not shared across DLL's. The exception to this obviously is 
virtual methods in templates as these *must* be shared across DLL boundaries to 
work correctly - though having just said that, I don't actually know if MSVC 
does this or not - I'll have to come up with a test.

I've followed this behaviour in my patch for GCC. It also comes with the 
significant benefit of totally removing all template generated symbols from the 
export table when compiled with -fvisibility=hidden which as template generated 
symbols tend to be very long, it very substantially reduces binary size and load 
times. The amazing thing is that the mangled symbol usually takes up more space 
than the code it represents so this is actually an optimisation!

All this said, my understanding of how inlining works in MSVC as against GCC may 
be imperfect so I suggest running the patch past Dave before committing. I need 
to remove a warning generated when Boost.Python is compiled with visibility 
support patched in just to give it a real professional air! :)

Are you happy with the pragma idea? Shall I implement that in the next patch?

Cheers,
Niall


-- 


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

[Bug other/15000] Support setting the default symbol visibility for ELF

[zack at codesourcery dot com]

------- Additional Comments From zack at codesourcery dot com  2004-04-22 20:36 -------
Subject: Re:  Support setting the default symbol visibility
 for ELF

>> #pragma visibility hidden
>> void internal_function (...);
>> ...
>> #pragma visibility default
>
> There is only (valid) opposition because you can't form #pragma's in
> preprocessor magic. However I would have thought the same engine
> works behind #pragma as behind that pragma statement replacement (I
> forget the details) so it still kills both birds with one stone.

_Pragma("string constant") where the contents of the string constant
are taken as the tokens after #pragma.

Note that pragmas which GCC makes up, i.e. ones that are not
implemented for compatibility with some other compiler, should have
the identifier GCC as the first token after #pragma.  In this case,

#pragma GCC visibility hidden

for example.

zw


-- 


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

[Bug other/15000] Support setting the default symbol visibility for ELF

[s_gccbugzilla at nedprod dot com]

------- Additional Comments From s_gccbugzilla at nedprod dot com  2004-04-23 04:56 -------
Brian, nested classes aren't inheriting visibility off their enclosing class 
with the new patch. I tried fixing this and failed because AFAICS in pushclass() 
the enclosing class hasn't processed attribute flags yet and so everything is 
always default visibility.

You know GCC better than I, so I'd appreciate it if you can find some solution. 
Thereafter I think I have everything else covered, including the new pragma.

Cheers,
Niall


-- 


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

[Bug other/15000] Support setting the default symbol visibility for ELF

[s_gccbugzilla at nedprod dot com]

------- Additional Comments From s_gccbugzilla at nedprod dot com  2004-04-28 18:24 -------
(In reply to comment #20)
> Brian, nested classes aren't inheriting visibility off their enclosing class 
> with the new patch. I tried fixing this and failed because AFAICS in 
pushclass() 
> the enclosing class hasn't processed attribute flags yet and so everything is 
> always default visibility.
> 
> You know GCC better than I, so I'd appreciate it if you can find some 
solution. 
> Thereafter I think I have everything else covered, including the new pragma.

If we're not moving ahead with this angle, I can try merging aspects of the new 
patch with the old patch and rerelease. However AFAICS the method of storing 
data in the typeinfo is incapable of supporting the mechanics required for 
-fvisibility unless anyone has any suggestions?

Cheers,
Niall


-- 


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

[Bug other/15000] Support setting the default symbol visibility for ELF

[bryner at brianryner dot com]

------- Additional Comments From bryner at brianryner dot com  2004-05-03 02:36 -------
(In reply to comment #20)
> Brian, nested classes aren't inheriting visibility off their enclosing class 
> with the new patch. I tried fixing this and failed because AFAICS in pushclass() 
> the enclosing class hasn't processed attribute flags yet and so everything is 
> always default visibility.
> 

I'd be surprised if that happens with the old patch, either... certainly it's
not something I've tested. (The old patch always initializes a new class on the
class stack with VISIBILITY_DEFAULT, so I don't see how the visibility would
come from anywhere other than the inner class's attributes).

I'm not really sure how to make it work, either... I'd need to think about it
some more.

-- 


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

[Bug other/15000] Support setting the default symbol visibility for ELF

[s_gccbugzilla at nedprod dot com]

------- Additional Comments From s_gccbugzilla at nedprod dot com  2004-05-03 04:18 -------
(In reply to comment #22)
> I'd be surprised if that happens with the old patch, either... certainly it's
> not something I've tested. (The old patch always initializes a new class on 
the
> class stack with VISIBILITY_DEFAULT, so I don't see how the visibility would
> come from anywhere other than the inner class's attributes).
> 
> I'm not really sure how to make it work, either... I'd need to think about it
> some more.

I could have sworn that my old test piece of code tested this and it worked 
(unfortunately I must have deleted it as I can't find it now). However testing 
my patch based on your old one shows that I am quite wrong and indeed the 
original patch didn't do it either. I must be getting old :(

Nevertheless the sentiment remains good I think - classes should inherit their 
visibility off their enclosing class when present. I'm a little busy right now 
but I intend to get onto this sometime this week. It seems to me that the 
visibility can't be stored in the typeinfo if that isn't available at the point 
of constructing nested class decls unless some (probably complex) machinery is 
used to propagate any class settings through all nested class' typeinfos too (I 
can't see how to easily obtain a list of nested classes other than iterate 
through everything which seems inefficient). If your thoughts yield anything, 
please do let me know lest we reinvent the wheel!

Cheers,
Niall


-- 


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

[Bug other/15000] Support setting the default symbol visibility for ELF

[s_gccbugzilla at nedprod dot com]

------- Additional Comments From s_gccbugzilla at nedprod dot com  2004-05-05 06:51 -------
It's definitely the case that attributes for classes are processed inside 
outwards so I've reverted back to the old patch which works in the opposite 
direction. I should have a new patch with the #pragma and nested classes 
inheriting visibility by tonight.

Cheers,
Niall


-- 


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

[Bug other/15000] Support setting the default symbol visibility for ELF

[bryner at brianryner dot com]

------- Additional Comments From bryner at brianryner dot com  2004-05-05 08:26 -------
(In reply to comment #24)
> It's definitely the case that attributes for classes are processed inside 
> outwards so I've reverted back to the old patch which works in the opposite 
> direction. I should have a new patch with the #pragma and nested classes 
> inheriting visibility by tonight.

The old patch also works "inside outwards".  That is, prehandle_attributes is
not going to be called for a class until the entire class has been parsed, which
implies that a nested class has already been finished off.  After the class
attributes are handled, it iterates over the member decls again (i.e.
check_field_decls) which allows the class attributes to be taken into account
for each member decl.

One reason for that, I think, is that attributes can come at the end of a
declaration, like this example from the documentation:

struct foo {
  int x;
  char a, b, c, d;
} __attribute__((packed));

You can see that in the analogous situation for visibility:

struct foo {
  struct bar {
     ...
  };
} __attribute__((visibility ("hidden")));

it would not be possible to know the outer class visibility when processing
foo::bar.

So I see a couple of ways to address this:

1. Say that the visibility attribute can only be at the beginning of a
class/struct declaration, and arrange to handle that attribute _before_ we begin
parsing class members.  I don't think there is any existing mechanism for
handling attributes at this stage, so we'd have to create something new.

2. Recursively reset DECL_VISIBILITY for members of inner classes once we reach
the end of a top-level class definition.


-- 


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

[Bug other/15000] Support setting the default symbol visibility for ELF

[s_gccbugzilla at nedprod dot com]

------- Additional Comments From s_gccbugzilla at nedprod dot com  2004-05-05 20:38 -------
> The old patch also works "inside outwards".

You're absolutely right. However I had hoped that because we get called at more 
opportunities than the new patch I could find some method. However, at the end 
of work last night I came to the realisation that the same method will be needed 
by other, therefore the newer is to be preferred.

> One reason for that, I think, is that attributes can come at the end of a
> declaration, like this example from the documentation:

My reading of this actually is that GCC needs to know the sizeof() things before 
it does much else. To know the size of a class requires parsing it from the most 
nested class outwards. I don't think this can be changed.

> it would not be possible to know the outer class visibility when processing
> foo::bar.

Agreed.

> 1. Say that the visibility attribute can only be at the beginning of a
> class/struct declaration, and arrange to handle that attribute _before_ we 
begin
> parsing class members.  I don't think there is any existing mechanism for
> handling attributes at this stage, so we'd have to create something new.
> 
> 2. Recursively reset DECL_VISIBILITY for members of inner classes once we 
reach
> the end of a top-level class definition.

Out of these two, the second seems to me the less work and the least intrusive. 
I tried the second last night, but there's a problem - the bit which parses and 
applies the attributes lives in C land which of course knows nothing about C++ 
and so can't have the class stack available (which makes things much easier). I 
tried an extern function, but I think they live in different binaries anyway so 
no good.

This means the only realistic solution is for handle_visibility_attribute() to 
see if it's being applied to a class/struct and if so, to traverse all children 
nodes to see if they are class/struct and if and only if they haven't had a 
visibility specified for them, overwrite that with the enclosing class 
visibility. For this we'll need visibility_specified back in the decl structure 
I think as I couldn't get C land to work with attributes in the TYPE_NAME(tree) 
when within handle_visibility_attribute(). But then I am very much out of my 
depth - I really am not sure of the mechanics underneath :(

BTW I have your pragma working fine, you can push and pop state from an internal 
stack too. I'll make a patch based on your new one with everything except nested 
class visibility setting and post it here, hopefully tonight.

Cheers,
Niall


-- 


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

[Bug other/15000] Support setting the default symbol visibility for ELF

[s_gccbugzilla at nedprod dot com]

------- Additional Comments From s_gccbugzilla at nedprod dot com  2004-05-06 03:21 -------
Please find attached merged patch of Brian's latest with all the new features 
I've added:

-fvisibility
#pragma GCC visibility
-fvisibility-inlines-hidden

What we don't have is nested classes inheriting the visibility setting from 
their enclosing classes. ANY HELP WITH THIS MUCH APPRECIATED AS I'VE GIVEN UP - 
I simply lack the familiarity with GCC's internals.

I've left the debug printing in as it'll aid anyone trying to do the nested 
classes problem. I'll not post this to gcc-patches until I've done more tests 
here ie; building Boost.Python and my library.

Another issue is how MSVC exports inlined code. It would seem that if a class is 
dllexport, all inlineable methods have a version of them generated and its entry 
made public in the export table. If it's not dllexport, it can obviously still 
be used outside its DLL as it'll get reinstantiated where it's used. With this 
patch, this behaviour is approximately emulated such that if something is marked 
as default visibility then it'll always appear in the export table. If not and 
-fvisibility=hidden is in effect, it'll get reinstantiated where it's used. I 
think I have this right now.

A final issue is when a declaration is explicitly marked default visibility but 
is defined within the current compiland. Should calls to that symbol from within 
the current compiland skip the PLT indirection? I'm thinking probably yes, but 
if anyone can think of why not then I won't. This would be a breaking change 
with previous versions of GCC however.

I've also added a test file I use to save you writing one. Best usage is to 
output as assembler and then you can study the assembler.

Cheers,
Niall



-- 


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

[Bug other/15000] Support setting the default symbol visibility for ELF

[s_gccbugzilla at nedprod dot com]

------- Additional Comments From s_gccbugzilla at nedprod dot com  2004-05-10 18:46 -------
Just to let you all know that I have produced a final version of the all 
inclusive patch complete with testsuite. I'll be posting it to gcc-patches 
tonight.

Also, I discovered that MSVC *doesn't* apply an enclosing class' 
declspec(dllexport) to its nested classes (I was most surprised to discover 
this). Therefore we don't need to implement this functionality (and if we did it 
would cause incompatibility).

Cheers,
Niall


-- 


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

[Bug other/15000] Support setting the default symbol visibility for ELF

[s_gccbugzilla at nedprod dot com]

------- Additional Comments From s_gccbugzilla at nedprod dot com  2004-05-12 21:58 -------
Thought it should be of public record that with -fvisibility=hidden support 
fully integrated, my TnFOX library exports 9435 symbols with GCC versus 9038 
with MSVC. That's pretty good and the difference can be traced to mostly 
differences between the MSVC and GCC RTTI implementation.

Some thoughts on my most recent patch:

It occurred to me in bed last night that it would be nice if GCC gave a warning 
if any of its base classes or data members did not have default visibility when 
it itself did. It would be slightly complex however because when inheriting off 
an instantiated template the base class could be entirely inlineable, in which 
case whether it has default visibility or not is an implementational choice and 
not something which will cause errors. Of course at final link you get these 
errors anyway, but what happens if the DSO is being loaded and managed manually?

The new -fvisibility-inlines-hidden isn't being aggressive enough in hiding 
inlines members and I don't know why. I'm using DECL_INLINE() which I think is 
correct? Any help here would be appreciated. Nevertheless, I'm seeing around a 
40% reduction which is respectable enough given it requires no source changes 
(60% reduction with -fvisibility=hidden).

Cheers,
Niall


-- 


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

[Bug other/15000] Support setting the default symbol visibility for ELF

[s_gccbugzilla at nedprod dot com]

------- Additional Comments From s_gccbugzilla at nedprod dot com  2004-05-28 22:24 -------
A slight revision to the existing patch - this improves the docs and adds a 
warning if the user tries to make global operator new or delete non-default 
visibility.

The copyright assignment paperwork I sent back to the US during the week, so it 
shouldn't be long now.

Cheers,
Niall


-- 


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

[Bug other/15000] Support setting the default symbol visibility for ELF

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-07-25 22:52 -------
Subject: Bug 15000

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	giovannibajo@gcc.gnu.org	2004-07-25 22:52:22

Modified files:
	gcc            : ChangeLog c-common.c c-decl.c c-opts.c 
	                 c-pragma.c c-pragma.h c.opt common.opt flags.h 
	                 opts.c tree.c tree.h varasm.c 
	gcc/cp         : ChangeLog class.c cp-tree.h decl.c method.c 
	                 optimize.c rtti.c 
	gcc/doc        : invoke.texi 
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/g++.dg/ext/visibility: 
	                                     fvisibility-inlines-hidden.C 
	                                     fvisibility-override1.C 
	                                     fvisibility-override2.C 
	                                     fvisibility.C memfuncts.C 
	                                     noPLT.C pragma-override1.C 
	                                     pragma-override2.C pragma.C 
	                                     staticmemfuncts.C virtual.C 
	                                     visibility-1.C 
	                                     visibility-2.C 
	                                     visibility-3.C 
	                                     visibility-4.C 
	                                     visibility-5.C 
	                                     visibility-6.C 
	                                     visibility-7.C 
	gcc/testsuite/gcc.dg: visibility-9.c visibility-a.c 
Removed files:
	gcc/testsuite/g++.dg/ext: visibility-1.C visibility-2.C 
	                          visibility-3.C visibility-4.C 
	                          visibility-5.C visibility-6.C 
	                          visibility-7.C 

Log message:
	PR c++/9283
	PR c++/15000
	* c-common.c (c_common_attribute_table): Allow
	handle_visibility_attribute to be called for types.
	(handle_visibility_attribute) When given a type, set the visibility
	bits on the TYPE_NAME.  When given a decl, don't set no_add_attrs
	so that we can check later whether the attribute was present. Added
	warning if attribute applied to non class type.
	* c-decl.c (diagnose_mismatched_decls): Updated rules for merging
	decls and checking that they are consistent.
	* common.opt: Added -fvisibility.
	* c.opt, c-opts.c: Added -fvisibility-inlines-hidden.
	* c-pragma.h, c-pragma.c: Added handle_pragma_visibility().
	* flags.h, tree.h: Added assorted support defines for overall patch
	* opts.c: Added parsing support for -fvisibility.
	* tree.c (build_decl): Set visibility for all decls to be whatever
	is in force at that time.
	* varasm.c (default_binds_local_p_1): Reworked logic determining
	when to make a symbol locally bound.
	* doc/invoke.texi: Added documentation for -fvisibility and
	-fvisibility-inlines-hidden.
	
	PR c++/15000
	PR c++/9283
	* class.c (check_field_decls): Apply hidden visibility if
	-fvisibility-inlines-hidden and inlined unless otherwise specified
	(build_vtable): Set vtable visibility to class visibility.
	(check_field_decls): Default static member visibility to class
	visibility.
	(check_methods): Default method visibility to class visibility.
	* cp-tree.h: Added CLASSTYPE_VISIBILITY and
	CLASSTYPE_VISIBILITY_SPECIFIED macro.
	* decl.c (duplicate_decls): New logic for merging definition decls
	with declaration decls. Added ignore & warning when non default
	applied to global operator new or delete.
	* method.c, optimize.c, rtti.c: Added setting of VISIBILITY_SPECIFIED
	wherever VISIBILITY was changed
	* rtti.c (get_tinfo_decl): Set typeinfo visibility to class
	visibility.
	(tinfo_base_init): Set typeinfo name visibility to class visibility.
	
	PR c++/9283
	PR c++/15000
	* gcc.dg/visibility-9.c, gcc.dg/visibility-a.c: New tests.
	* g++.dg/ext/visibility/: New directory.
	* g++.dg/ext/visibility-1.C, g++.dg/ext/visibility-2.C
	g++.dg/ext/visibility-3.C, g++.dg/ext/visibility-4.C,
	g++.dg/ext/visibility-5.C, g++.dg/ext/visibility-6.C,
	g++.dg/ext/visibility-7.C: Move to g++.dg/ext/visibility/.
	* g++.dg/ext/visibility/fvisibility.C,
	g++.dg/ext/visibility/fvisibility-inlines-hidden.C,
	g++.dg/ext/visibility/fvisibility-override1.C
	g++.dg/ext/visibility/fvisibility-override2.C
	g++.dg/ext/visibility/memfuncts.C
	g++.dg/ext/visibility/noPLT.C
	g++.dg/ext/visibility/pragma.C
	g++.dg/ext/visibility/pragma-override1.C
	g++.dg/ext/visibility/pragma-override2.C
	g++.dg/ext/visibility/staticmemfuncts.C
	g++.dg/ext/visibility/virtual.C: New tests.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.4685&r2=2.4686
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-common.c.diff?cvsroot=gcc&r1=1.541&r2=1.542
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-decl.c.diff?cvsroot=gcc&r1=1.545&r2=1.546
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-opts.c.diff?cvsroot=gcc&r1=1.122&r2=1.123
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-pragma.c.diff?cvsroot=gcc&r1=1.73&r2=1.74
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-pragma.h.diff?cvsroot=gcc&r1=1.40&r2=1.41
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c.opt.diff?cvsroot=gcc&r1=1.30&r2=1.31
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/common.opt.diff?cvsroot=gcc&r1=1.41&r2=1.42
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/flags.h.diff?cvsroot=gcc&r1=1.145&r2=1.146
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/opts.c.diff?cvsroot=gcc&r1=1.74&r2=1.75
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree.c.diff?cvsroot=gcc&r1=1.404&r2=1.405
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree.h.diff?cvsroot=gcc&r1=1.572&r2=1.573
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/varasm.c.diff?cvsroot=gcc&r1=1.435&r2=1.436
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4244&r2=1.4245
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/class.c.diff?cvsroot=gcc&r1=1.644&r2=1.645
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.h.diff?cvsroot=gcc&r1=1.1023&r2=1.1024
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gcc&r1=1.1262&r2=1.1263
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/method.c.diff?cvsroot=gcc&r1=1.303&r2=1.304
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/optimize.c.diff?cvsroot=gcc&r1=1.111&r2=1.112
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/rtti.c.diff?cvsroot=gcc&r1=1.190&r2=1.191
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/invoke.texi.diff?cvsroot=gcc&r1=1.491&r2=1.492
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4051&r2=1.4052
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility-1.C.diff?cvsroot=gcc&r1=1.1&r2=NONE
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility-2.C.diff?cvsroot=gcc&r1=1.1&r2=NONE
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility-3.C.diff?cvsroot=gcc&r1=1.1&r2=NONE
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility-4.C.diff?cvsroot=gcc&r1=1.1&r2=NONE
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility-5.C.diff?cvsroot=gcc&r1=1.1&r2=NONE
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility-6.C.diff?cvsroot=gcc&r1=1.1&r2=NONE
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility-7.C.diff?cvsroot=gcc&r1=1.1&r2=NONE
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/fvisibility-inlines-hidden.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/fvisibility-override1.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/fvisibility-override2.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/fvisibility.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/memfuncts.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/noPLT.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/pragma-override1.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/pragma-override2.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/pragma.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/staticmemfuncts.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/virtual.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/visibility-1.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/visibility-2.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/visibility-3.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/visibility-4.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/visibility-5.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/visibility-6.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/visibility-7.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/visibility-9.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/visibility-a.c.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug other/15000] Support setting the default symbol visibility for ELF

[s_gccbugzilla at nedprod dot com]

------- Additional Comments From s_gccbugzilla at nedprod dot com  2004-07-25 23:34 -------
As of the 25th July, this patch was applied against GCC v3.5 mainline.

http://gcc.gnu.org/ml/gcc-cvs/2004-07/msg01232.html

Brian, can you close this issue?

Cheers,
Niall


-- 


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

[Bug other/15000] Support setting the default symbol visibility for ELF

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-07-25 23:36 -------
Fixed in 3.5.0.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |3.5.0


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

[Bug other/15000] Support setting the default symbol visibility for ELF

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-07-25 23:57 -------
(In reply to comment #32)

> The new -fvisibility-inlines-hidden isn't being aggressive enough in hiding 
> inlines members and I don't know why. I'm using DECL_INLINE() which I
> think is correct? Any help here would be appreciated. 

You can try with DECL_DECLARED_INLINE. 

-- 


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

[Bug other/15000] Support setting the default symbol visibility for ELF

[s_gccbugzilla at nedprod dot com]

------- Additional Comments From s_gccbugzilla at nedprod dot com  2004-07-26 01:31 -------
(In reply to comment #38)
> (In reply to comment #32)
> 
> > The new -fvisibility-inlines-hidden isn't being aggressive enough in hiding 
> > inlines members and I don't know why. I'm using DECL_INLINE() which I
> > think is correct? Any help here would be appreciated. 
> 
> You can try with DECL_DECLARED_INLINE. 

Is this true when a member function has been defined in the class declaration? 
Is DECL_INLINE only true when the optimiser decides it, or is it true more or 
less often than DECL_DECLARED_INLINE?

Cheers,
Niall


-- 


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

[Bug other/15000] Support setting the default symbol visibility for ELF

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-08-17 03:06 -------
Subject: Bug 15000

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	csl-arm-branch
Changes by:	mmitchel@gcc.gnu.org	2004-08-17 03:06:33

Modified files:
	gcc            : ChangeLog.csl-arm c-common.c c-decl.c c-opts.c 
	                 c-pragma.c c-pragma.h c.opt common.opt flags.h 
	                 opts.c tree.c tree.h varasm.c 
	gcc/cp         : class.c cp-tree.h decl.c method.c optimize.c 
	                 rtti.c 
	gcc/doc        : invoke.texi 
Added files:
	gcc/testsuite/g++.dg/ext/visibility: 
	                                     fvisibility-inlines-hidden.C 
	                                     fvisibility-override1.C 
	                                     fvisibility-override2.C 
	                                     fvisibility.C memfuncts.C 
	                                     noPLT.C pragma-override1.C 
	                                     pragma-override2.C pragma.C 
	                                     staticmemfuncts.C virtual.C 
	                                     visibility-1.C 
	                                     visibility-2.C 
	                                     visibility-3.C 
	                                     visibility-4.C 
	                                     visibility-5.C 
	                                     visibility-6.C 
	                                     visibility-7.C 
	gcc/testsuite/gcc.dg: visibility-9.c visibility-a.c 
Removed files:
	gcc/testsuite/g++.dg/ext: visibility-1.C visibility-2.C 
	                          visibility-3.C visibility-4.C 
	                          visibility-5.C visibility-6.C 
	                          visibility-7.C 

Log message:
	Backport:
	2004-07-26  Niall Douglas  <s_fsfeurope2@nedprod.com>
	Brian Ryner  <bryner@brianryner.com>
	PR c++/9283
	PR c++/15000
	* c-common.c (c_common_attribute_table): Allow
	handle_visibility_attribute to be called for types.
	(handle_visibility_attribute) When given a type, set the visibility
	bits on the TYPE_NAME.  When given a decl, don't set no_add_attrs
	so that we can check later whether the attribute was present. Added
	warning if attribute applied to non class type.
	* c-decl.c (diagnose_mismatched_decls): Updated rules for merging
	decls and checking that they are consistent.
	* common.opt: Added -fvisibility.
	* c.opt, c-opts.c: Added -fvisibility-inlines-hidden.
	* c-pragma.h, c-pragma.c: Added handle_pragma_visibility().
	* flags.h, tree.h: Added assorted support defines for overall patch
	* opts.c: Added parsing support for -fvisibility.
	* tree.c (build_decl): Set visibility for all decls to be whatever
	is in force at that time.
	* varasm.c (default_binds_local_p_1): Reworked logic determining
	when to make a symbol locally bound.
	* doc/invoke.texi: Added documentation for -fvisibility and
	-fvisibility-inlines-hidden.
	
	2004-07-26  Niall Douglas  <s_fsfeurope2@nedprod.com>
	Brian Ryner  <bryner@brianryner.com>
	PR c++/15000
	PR c++/9283
	* class.c (check_field_decls): Apply hidden visibility if
	-fvisibility-inlines-hidden and inlined unless otherwise specified
	(build_vtable): Set vtable visibility to class visibility.
	(check_field_decls): Default static member visibility to class
	visibility.
	(check_methods): Default method visibility to class visibility.
	* cp-tree.h: Added CLASSTYPE_VISIBILITY and
	CLASSTYPE_VISIBILITY_SPECIFIED macro.
	* decl.c (duplicate_decls): New logic for merging definition decls
	with declaration decls. Added ignore & warning when non default
	applied to global operator new or delete.
	* method.c, optimize.c, rtti.c: Added setting of VISIBILITY_SPECIFIED
	wherever VISIBILITY was changed
	* rtti.c (get_tinfo_decl): Set typeinfo visibility to class
	visibility.
	(tinfo_base_init): Set typeinfo name visibility to class visibility.
	
	2004-07-26  Niall Douglas  <s_fsfeurope2@nedprod.com>
	Brian Ryner  <bryner@brianryner.com>
	PR c++/9283
	PR c++/15000
	* gcc.dg/visibility-9.c, gcc.dg/visibility-a.c: New tests.
	* g++.dg/ext/visibility/: New directory.
	* g++.dg/ext/visibility-1.C, g++.dg/ext/visibility-2.C
	g++.dg/ext/visibility-3.C, g++.dg/ext/visibility-4.C,
	g++.dg/ext/visibility-5.C, g++.dg/ext/visibility-6.C,
	g++.dg/ext/visibility-7.C: Move to g++.dg/ext/visibility/.
	* g++.dg/ext/visibility/fvisibility.C,
	g++.dg/ext/visibility/fvisibility-inlines-hidden.C,
	g++.dg/ext/visibility/fvisibility-override1.C
	g++.dg/ext/visibility/fvisibility-override2.C
	g++.dg/ext/visibility/memfuncts.C
	g++.dg/ext/visibility/noPLT.C
	g++.dg/ext/visibility/pragma.C
	g++.dg/ext/visibility/pragma-override1.C
	g++.dg/ext/visibility/pragma-override2.C
	g++.dg/ext/visibility/staticmemfuncts.C
	g++.dg/ext/visibility/virtual.C: New tests.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.csl-arm.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=1.1.2.4&r2=1.1.2.5
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-common.c.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=1.465.4.5&r2=1.465.4.6
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-decl.c.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=1.455.4.4&r2=1.455.4.5
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-opts.c.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=1.91.4.2&r2=1.91.4.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-pragma.c.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=1.64.4.3&r2=1.64.4.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-pragma.h.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=1.36.6.1&r2=1.36.6.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c.opt.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=1.17.6.1&r2=1.17.6.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/common.opt.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=1.20.4.3&r2=1.20.4.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/flags.h.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=1.126.4.3&r2=1.126.4.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/opts.c.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=1.44.4.5&r2=1.44.4.6
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree.c.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=1.336.4.3&r2=1.336.4.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree.h.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=1.450.2.3&r2=1.450.2.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/varasm.c.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=1.395.2.4&r2=1.395.2.5
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/class.c.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=1.581.2.5&r2=1.581.2.6
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.h.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=1.930.2.5&r2=1.930.2.6
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=1.1150.2.8&r2=1.1150.2.9
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/method.c.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=1.270.2.5&r2=1.270.2.6
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/optimize.c.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=1.101.4.3&r2=1.101.4.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/rtti.c.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=1.175.4.3&r2=1.175.4.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/invoke.texi.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=1.356.2.10&r2=1.356.2.11
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility-1.C.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=1.1.2.1&r2=NONE
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility-2.C.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=1.1.2.1&r2=NONE
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility-3.C.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=1.1.2.1&r2=NONE
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility-4.C.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=1.1.2.1&r2=NONE
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility-5.C.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=1.1.2.1&r2=NONE
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility-6.C.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=1.1.2.1&r2=NONE
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility-7.C.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=1.1.2.1&r2=NONE
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/fvisibility-inlines-hidden.C.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=NONE&r2=1.2.4.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/fvisibility-override1.C.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=NONE&r2=1.1.8.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/fvisibility-override2.C.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=NONE&r2=1.1.8.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/fvisibility.C.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=NONE&r2=1.2.4.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/memfuncts.C.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=NONE&r2=1.2.4.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/noPLT.C.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=NONE&r2=1.1.8.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/pragma-override1.C.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=NONE&r2=1.1.8.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/pragma-override2.C.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=NONE&r2=1.1.8.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/pragma.C.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=NONE&r2=1.2.4.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/staticmemfuncts.C.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=NONE&r2=1.2.4.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/virtual.C.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=NONE&r2=1.2.4.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/visibility-1.C.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=NONE&r2=1.2.4.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/visibility-2.C.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=NONE&r2=1.2.4.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/visibility-3.C.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=NONE&r2=1.2.4.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/visibility-4.C.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=NONE&r2=1.2.4.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/visibility-5.C.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=NONE&r2=1.2.4.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/visibility-6.C.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=NONE&r2=1.2.4.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/visibility-7.C.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=NONE&r2=1.2.4.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/visibility-9.c.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=NONE&r2=1.1.8.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/visibility-a.c.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=NONE&r2=1.1.8.1



-- 


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

[Bug other/15000] Support setting the default symbol visibility for ELF

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-08-18 22:50 -------
*** Bug 17089 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |craig dot lawson at centrify
                   |                            |dot com


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

[Bug other/15000] Support setting the default symbol visibility for ELF

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-09-01 16:21 -------
Subject: Bug 15000

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-3_4-rhl-branch
Changes by:	jakub@gcc.gnu.org	2004-09-01 16:21:00

Modified files:
	gcc            : ChangeLog varasm.c tree.h tree.c flags.h 
	                 c-opts.c c-pragma.h c-common.c c-decl.c c.opt 
	                 common.opt opts.c c-pragma.c 
	gcc/cp         : ChangeLog 
	gcc/testsuite  : ChangeLog 
	gcc/cp         : class.c optimize.c method.c decl.c rtti.c 
	                 cp-tree.h 
	gcc/doc        : invoke.texi 
Added files:
	gcc/testsuite/gcc.dg: visibility-9.c visibility-a.c 
	gcc/testsuite/g++.dg/ext/visibility: visibility-5.C virtual.C 
	                                     visibility-1.C 
	                                     visibility-7.C 
	                                     visibility-2.C 
	                                     staticmemfuncts.C 
	                                     pragma-override1.C 
	                                     fvisibility-override1.C 
	                                     fvisibility.C noPLT.C 
	                                     fvisibility-inlines-hidden.C 
	                                     pragma-override2.C 
	                                     visibility-6.C 
	                                     visibility-4.C pragma.C 
	                                     visibility-3.C memfuncts.C 
	                                     fvisibility-override2.C 
Removed files:
	gcc/testsuite/g++.dg/ext: visibility-5.C visibility-1.C 
	                          visibility-7.C visibility-2.C 
	                          visibility-6.C visibility-4.C 
	                          visibility-3.C 

Log message:
	2004-07-26  Niall Douglas  <s_fsfeurope2@nedprod.com>
	Brian Ryner  <bryner@brianryner.com>
	
	PR c++/9283
	PR c++/15000
	* c-common.c (c_common_attribute_table): Allow
	handle_visibility_attribute to be called for types.
	(handle_visibility_attribute) When given a type, set the visibility
	bits on the TYPE_NAME.  When given a decl, don't set no_add_attrs
	so that we can check later whether the attribute was present. Added
	warning if attribute applied to non class type.
	* c-decl.c (diagnose_mismatched_decls): Updated rules for merging
	decls and checking that they are consistent.
	* common.opt: Added -fvisibility.
	* c.opt, c-opts.c: Added -fvisibility-inlines-hidden.
	* c-pragma.h, c-pragma.c: Added handle_pragma_visibility().
	* flags.h, tree.h: Added assorted support defines for overall patch
	* opts.c: Added parsing support for -fvisibility.
	* tree.c (build_decl): Set visibility for all decls to be whatever
	is in force at that time.
	* varasm.c (default_binds_local_p_1): Reworked logic determining
	when to make a symbol locally bound.
	* doc/invoke.texi: Added documentation for -fvisibility and
	-fvisibility-inlines-hidden.
	cp/
	PR c++/15000
	PR c++/9283
	* class.c (check_field_decls): Apply hidden visibility if
	-fvisibility-inlines-hidden and inlined unless otherwise specified
	(build_vtable): Set vtable visibility to class visibility.
	(check_field_decls): Default static member visibility to class
	visibility.
	(check_methods): Default method visibility to class visibility.
	* cp-tree.h: Added CLASSTYPE_VISIBILITY and
	CLASSTYPE_VISIBILITY_SPECIFIED macro.
	* decl.c (duplicate_decls): New logic for merging definition decls
	with declaration decls. Added ignore & warning when non default
	applied to global operator new or delete.
	* method.c, optimize.c, rtti.c: Added setting of VISIBILITY_SPECIFIED
	wherever VISIBILITY was changed
	* rtti.c (get_tinfo_decl): Set typeinfo visibility to class
	visibility.
	(tinfo_base_init): Set typeinfo name visibility to class visibility.
	testsuite/
	PR c++/9283
	PR c++/15000
	* gcc.dg/visibility-9.c, gcc.dg/visibility-a.c: New tests.
	* g++.dg/ext/visibility/: New directory.
	* g++.dg/ext/visibility-1.C, g++.dg/ext/visibility-2.C
	g++.dg/ext/visibility-3.C, g++.dg/ext/visibility-4.C,
	g++.dg/ext/visibility-5.C, g++.dg/ext/visibility-6.C,
	g++.dg/ext/visibility-7.C: Move to g++.dg/ext/visibility/.
	* g++.dg/ext/visibility/fvisibility.C,
	g++.dg/ext/visibility/fvisibility-inlines-hidden.C,
	g++.dg/ext/visibility/fvisibility-override1.C
	g++.dg/ext/visibility/fvisibility-override2.C
	g++.dg/ext/visibility/memfuncts.C
	g++.dg/ext/visibility/noPLT.C
	g++.dg/ext/visibility/pragma.C
	g++.dg/ext/visibility/pragma-override1.C
	g++.dg/ext/visibility/pragma-override2.C
	g++.dg/ext/visibility/staticmemfuncts.C
	g++.dg/ext/visibility/virtual.C: New tests.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=2.2326.2.399.2.34&r2=2.2326.2.399.2.35
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/varasm.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.405.2.3.2.1&r2=1.405.2.3.2.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree.h.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.458.2.4.2.2&r2=1.458.2.4.2.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.342.2.3.2.2&r2=1.342.2.3.2.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/flags.h.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.127.4.1&r2=1.127.4.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-opts.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.96.4.7&r2=1.96.4.7.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-pragma.h.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.36.12.2&r2=1.36.12.2.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-common.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.476.4.6.2.2&r2=1.476.4.6.2.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-decl.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.470.4.13.2.3&r2=1.470.4.13.2.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c.opt.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.17.12.2&r2=1.17.12.2.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/common.opt.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.24.4.1&r2=1.24.4.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/opts.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.51.4.3&r2=1.51.4.3.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-pragma.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.66.2.1.2.1&r2=1.66.2.1.2.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.3892.2.99.2.8&r2=1.3892.2.99.2.9
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.3389.2.170.2.17&r2=1.3389.2.170.2.18
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/class.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.595.4.7.2.2&r2=1.595.4.7.2.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/optimize.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.103.4.2&r2=1.103.4.2.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/method.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.275.4.3.2.1&r2=1.275.4.3.2.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.1174.2.19.2.4&r2=1.1174.2.19.2.5
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/rtti.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.176.4.3.2.1&r2=1.176.4.3.2.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.h.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.946.4.11.2.3&r2=1.946.4.11.2.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/invoke.texi.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.390.2.24.2.5&r2=1.390.2.24.2.6
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/visibility-9.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=NONE&r2=1.1.12.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/visibility-a.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=NONE&r2=1.1.12.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility-5.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.1&r2=NONE
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility-1.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.1&r2=NONE
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility-7.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.1&r2=NONE
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility-2.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.1&r2=NONE
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility-6.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.1&r2=NONE
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility-4.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.1&r2=NONE
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility-3.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.1&r2=NONE
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/visibility-5.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=NONE&r2=1.2.8.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/virtual.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=NONE&r2=1.2.8.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/visibility-1.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=NONE&r2=1.2.8.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/visibility-7.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=NONE&r2=1.2.8.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/visibility-2.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=NONE&r2=1.2.8.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/staticmemfuncts.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=NONE&r2=1.2.8.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/pragma-override1.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=NONE&r2=1.1.12.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/fvisibility-override1.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=NONE&r2=1.1.12.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/fvisibility.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=NONE&r2=1.2.8.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/noPLT.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=NONE&r2=1.1.12.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/fvisibility-inlines-hidden.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=NONE&r2=1.2.8.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/pragma-override2.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=NONE&r2=1.1.12.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/visibility-6.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=NONE&r2=1.2.8.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/visibility-4.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=NONE&r2=1.2.8.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/pragma.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=NONE&r2=1.2.8.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/visibility-3.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=NONE&r2=1.2.8.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/memfuncts.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=NONE&r2=1.2.8.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/visibility/fvisibility-override2.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=NONE&r2=1.1.12.1



-- 


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