Compiling glibc-2.3.2 (-2.3.3?) snapshot 20031115 with gcc-3.4 snapshot 20031119

[Matt Austern]

On Dec 2, 2003, at 12:21 PM, Daniel Jacobowitz wrote:

> On Tue, Dec 02, 2003 at 12:15:13PM -0800, Matt Austern wrote:
>> On Dec 2, 2003, at 7:37 AM, Jakub Jelinek wrote:
>>
>>> On Tue, Dec 02, 2003 at 09:35:51AM -0800, Matt Austern wrote:
>>>> As you might have noticed from following the discussion on the
>>>> gcc list, the main reason I haven't fixed this yet is that we 
>>>> haven't
>>>> yet reached an agreement about what the semantics of the
>>>> visibility attribute should be when you've got multiple declarations
>>>> of the same symbol.
>>>>
>>>> What assumptions does the glibc source make about this, and how
>>>> tightly wedded are you to those assumptions?
>>>
>>> glibc assumes that if there is a decl without visibility attribute
>>> and decl with visibility attribute, that the visibility specified
>>> in the visibility attribute is used.
>>>
>>> Say:
>>> int foo (void) __attribute__((visibility ("hidden")));
>>> int bar (void);
>>> ...
>>> int foo (void) { return 1; }
>>> int __attribute__((visibility ("hidden"))) bar (void) { return 2; }
>>>
>>> then both foo and bar are hidden.
>>
>> 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.

Don't know.  Since there isn't currently such a switch, and there almost
certainly won't be such a switch in 3.4, I'm inclined to say that we 
should
postpone that discussion for later.

Given the feature set as it currently stands, is it reasonable to say 
that
the default is just default and that we don't need to distinguish 
between
default and unspecified?  Again, I hope so; we could always expand the
two-bit visibility field to three bits, but I'd rather not do that 
unless it's
really necessary.

			--Matt