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