This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Compiling glibc-2.3.2 (-2.3.3?) snapshot 20031115 with gcc-3.4 snapshot 20031119
On Tue, Dec 02, 2003 at 03:21:23PM -0500, Daniel Jacobowitz wrote:
> > OK! The next question, then: do you assume that explicitly
> > providing a default visibility, and not providing a visibility at
> > all, are different? That is, would you expect
> > int foo (void) __attribute__((visibility ("hidden")));
> > int foo (void) __attribute__((visibility ("default"))) { return 137;
> > }
> > to behave differently than
> > int foo (void) __attribute__((visibility ("hidden")));
> > int foo (void) { return 137; }?
> >
> > (I hope the answer is no, and that default is just default. I know
> > how to make the compiler treat the two kinds of default differently,
> > but it'll be a little more expensive and convoluted.)
>
> But... wouldn't this be necessary if there was a switch to change the
> "default" visibility of compiler-generated symbols? Something which
> has been both requested and proposed in the past.
visibility ("default") is quite confusing if there is a switch to set
a different default. It can be either STV_DEFAULT, or the default chosen
by -fvisibility. But, if -fvisibility is used, then there must be some
attribute to request STV_DEFAULT, so I think what GCC should do is:
if a decl doesn't have visibility attribute, use the visibility set by
-fvisibility (or, if not present, STV_DEFAULT). But, this shouldn't
be done until the function or variable is actually emitted, so that
you can still merge without errors a decl without visibility
attribute with a decl with visibility attribute. Which implies
a 5 states (default, hidden, protected, internal and unspecified).
Jakub