Fix PR 31903, type info for types in anonymous namespaces

Geoffrey Keating geoffk@apple.com
Tue Oct 30 19:25:00 GMT 2007


On 30/10/2007, at 11:39 AM, Richard Guenther wrote:

> On 10/30/07, Geoffrey Keating <geoffk@apple.com> wrote:
>>
>> On 29/10/2007, at 6:41 AM, Richard Guenther wrote:
>>
>>> On 10/29/07, Richard Guenther <richard.guenther@gmail.com> wrote:
>>>> On 6/14/07, Geoffrey Keating <gkeating@apple.com> wrote:
>>>>>
>>>>> In the 'else' clause right below the code I remove, there is:
>>>>>
>>>>>     else if (TREE_CODE (decl) == VAR_DECL && DECL_TINFO_P (decl))
>>>>>       {
>>>>>         /* tinfo visibility is based on the type it's for.  */
>>>>>         constrain_visibility
>>>>>           (decl, type_visibility (TREE_TYPE (DECL_NAME (decl))));
>>>>>       }
>>>>>
>>>>> which is more correct, and in the presence of the code I  
>>>>> deleted, is
>>>>> never used for type info of class types.
>>>>>
>>>>> Tested with 'make bootstrap', rebuilding libsdc++, and running the
>>>>> C++
>>>>> dejagnu testsuite on i386-apple-darwin9.
>>>>
>>>> This causes PR33871 and reverting the change still ends up with the
>>>> testcase
>>>> working.  On *-linux-gnu that is.  Any idea why?
>>>>
>>>> Please investigate.
>>>
>>> In fact, I think the new testcase should _fail_ now, but the  
>>> matching
>>> pattern doesn't
>>> fail on
>>>
>>>       .file   "anon4.C"
>>> .globl X
>>>       .section        .rodata
>>>       .align 8
>>>       .type   X, @object
>>>       .size   X, 8
>>> X:
>>>       .quad   _ZTIN12_GLOBAL__N_13fooE
>>>       .section
>>>        .gnu.linkonce.r._ZTSN12_GLOBAL__N_13fooE,"a",@progbits
>>>       .align 16
>>>       .type   _ZTSN12_GLOBAL__N_13fooE, @object
>>>       .size   _ZTSN12_GLOBAL__N_13fooE, 21
>>> _ZTSN12_GLOBAL__N_13fooE:
>>>       .string "N12_GLOBAL__N_13fooE"
>>>       .section        .rodata
>>>       .align 16
>>>       .type   _ZTIN12_GLOBAL__N_13fooE, @object
>>>       .size   _ZTIN12_GLOBAL__N_13fooE, 16
>>> _ZTIN12_GLOBAL__N_13fooE:
>>>       .quad   _ZTVN10__cxxabiv117__class_type_infoE+16
>>>       .quad   _ZTSN12_GLOBAL__N_13fooE
>>>       .ident  "GCC: (GNU) 4.3.0 20071029 (experimental)"
>>>       .section        .note.GNU-stack,"",@progbits
>>
>> Could you explain more about why you think it should fail?  I only  
>> see
>> one instance of '.globl' in this snippet of assembler and it's not  
>> the
>> one the testcase is checking for, which would look like
>>
>> .globl _ZTIN12_GLOBAL__N_13fooE
>>
>> (note that the testcase is trying to make sure that .globl does *not*
>> appear.)
>
> The symbols were weak before and are now not weak.

Of course they are not weak, only global symbols can be weak.

> I don't know what version is more "correct", but certainly you did  
> change
> behavior and that changed behavior broke numerous applications at
> link time.

It can't be that many, it took four months for anyone to report a  
problem.  Perhaps what you're seeing only happens with specific buggy  
versions of GNU ld?

>  So I ask you to provide either reasoning for the change
> (citing ABIs or whatever) or to restore the previous behavior to  
> unbreak
> applications.

What's unreasonable about "tinfo visibility is based on the type it's  
for"?

Let's continue this discussion in PR33871 where I provide additional  
explanation.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2462 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20071030/c281da4b/attachment.p7s>


More information about the Gcc-patches mailing list