Re: Fix PR 31903, type info for types in anonymous namespaces

[Geoffrey Keating <geoffk at apple dot com>]

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.

Attachment: smime.p7s
Description: S/MIME cryptographic signature