This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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

On 10/30/07, Geoffrey Keating <> wrote:

On 29/10/2007, at 6:41 AM, Richard Guenther wrote:

On 10/29/07, Richard Guenther <> wrote:
On 6/14/07, Geoffrey Keating <> 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.  */
          (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
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
      .quad   _ZTIN12_GLOBAL__N_13fooE
      .align 16
      .type   _ZTSN12_GLOBAL__N_13fooE, @object
      .size   _ZTSN12_GLOBAL__N_13fooE, 21
      .string "N12_GLOBAL__N_13fooE"
      .section        .rodata
      .align 16
      .type   _ZTIN12_GLOBAL__N_13fooE, @object
      .size   _ZTIN12_GLOBAL__N_13fooE, 16
      .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*

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

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]