[Bug lto/95677] New: undefined reference to `(anonymous namespace)::xx'

[Bug lto/95677] New: undefined reference to `(anonymous namespace)::xx'

[sujian.liu at huawei dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95677

            Bug ID: 95677
           Summary: undefined reference to `(anonymous namespace)::xx'
           Product: gcc
           Version: lto
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
          Assignee: unassigned at gcc dot gnu.org
          Reporter: sujian.liu at huawei dot com
                CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 48731
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48731&action=edit
dejagnu/testsuite-7.3/g++.old-deja/g++.ns/extern1.C

When compile with lto,it will be reported the following error:

./riscv32-unknown-elf-gcc dejagnu/testsuite-7.3/g++.old-deja/g++.ns/extern1.C
-o extern1.exe -flto
                                                  
/home/lsj/gits/gcc_10_1_0/build/hcc_riscv32/riscv32_elf_build_dir/hcc_riscv32/bin/../lib/gcc/riscv32-unknown-elf/10.1.0/../../../../riscv32-unknown-elf/bin/ld:
/tmp/extern1.exe.m1gfd6.ltrans0.ltrans.o: in function `.L0 ':
<artificial>:(.text+0x6): undefined reference to `(anonymous namespace)::xx'
/home/lsj/gits/gcc_10_1_0/build/hcc_riscv32/riscv32_elf_build_dir/hcc_riscv32/bin/../lib/gcc/riscv32-unknown-elf/10.1.0/../../../../riscv32-unknown-elf/bin/ld:
<artificial>:(.text+0xa): undefined reference to `(anonymous namespace)::xx'
collect2: error: ld returned 1 exit status

It seems that lto can't deal with the extern variable in the namespace.

The testcase which is one of deja in testsuite-7.3 will be attached.

[Bug c++/95677] undefined reference to `(anonymous namespace)::xx'

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95677

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |lto, wrong-code
          Component|lto                         |c++
            Version|lto                         |10.1.0
                 CC|                            |hubicka at gcc dot gnu.org,
                   |                            |jason at gcc dot gnu.org,
                   |                            |nathan at gcc dot gnu.org

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
It's more likely the GENERIC / cgraph output by the C++ frontend is not correct
and works by accident without LTO.  Initial symbol table:

Initial Symbol table:

int {anonymous}::xx/3 (int {anonymous}::xx) @0x7f615d2d8180
  Type: variable
  Visibility: external
  References:
  Referring: _ZN12_GLOBAL__N_13fooEv/0 (write)
  Availability: not-ready
  Varpool flags:
main/2 (int main()) @0x7f615d421168
  Type: function definition analyzed
  Visibility: force_output no_reorder public
  Aux: @0x37a5000
  References: int {anonymous}::xx/1 (write)
  Referring:
  Function flags: body
  Called by:
  Calls:
int {anonymous}::xx/1 (int {anonymous}::xx) @0x7f615d2d8100
  Type: variable definition analyzed
  Visibility: force_output no_reorder
  Aux: @0x7f615d421168
  References:
  Referring: main/2 (write)
  Availability: not-ready
  Varpool flags: initialized
_ZN12_GLOBAL__N_13fooEv/0 (void {anonymous}::foo()) @0x7f615d421000
  Type: function definition analyzed
  Visibility: force_output no_reorder
  Aux: @0x7f615d2d8100
  References: int {anonymous}::xx/3 (write)
  Referring:
  Function flags: body
  Called by:
  Calls:

where you can see there are actually two 'xx' objects and the C++ FE
takes it up to the linker/assembler to resolve them.  But the symtab
code does not include such "resolving" step.

[Bug c++/95677] undefined reference to `(anonymous namespace)::xx'

[sujian.liu at huawei dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95677

--- Comment #2 from liusujian <sujian.liu at huawei dot com> ---
(In reply to Richard Biener from comment #1)
> It's more likely the GENERIC / cgraph output by the C++ frontend is not
> correct
> and works by accident without LTO.  Initial symbol table:
> 
> Initial Symbol table:
> 
> int {anonymous}::xx/3 (int {anonymous}::xx) @0x7f615d2d8180
>   Type: variable
>   Visibility: external
>   References:
>   Referring: _ZN12_GLOBAL__N_13fooEv/0 (write)
>   Availability: not-ready
>   Varpool flags:
> main/2 (int main()) @0x7f615d421168
>   Type: function definition analyzed
>   Visibility: force_output no_reorder public
>   Aux: @0x37a5000
>   References: int {anonymous}::xx/1 (write)
>   Referring:
>   Function flags: body
>   Called by:
>   Calls:
> int {anonymous}::xx/1 (int {anonymous}::xx) @0x7f615d2d8100
>   Type: variable definition analyzed
>   Visibility: force_output no_reorder
>   Aux: @0x7f615d421168
>   References:
>   Referring: main/2 (write)
>   Availability: not-ready
>   Varpool flags: initialized
> _ZN12_GLOBAL__N_13fooEv/0 (void {anonymous}::foo()) @0x7f615d421000
>   Type: function definition analyzed
>   Visibility: force_output no_reorder
>   Aux: @0x7f615d2d8100
>   References: int {anonymous}::xx/3 (write)
>   Referring:
>   Function flags: body
>   Called by:
>   Calls:
> 
> where you can see there are actually two 'xx' objects and the C++ FE
> takes it up to the linker/assembler to resolve them.  But the symtab
> code does not include such "resolving" step.


In other words, C++ is currently unable to deal with this scenario ? Or any
other problems cause the error?

[Bug c++/95677] undefined reference to `(anonymous namespace)::xx'

[nathan at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95677

--- Comment #3 from Nathan Sidwell <nathan at gcc dot gnu.org> ---
I think the testcase is should be formed.  it was ok in C++98, but that changed
when anonymous namespaces gave their contents internal linkage (rather than
external but with unpronounceable symbols).

[basic.link]/6 does not anticipate this issue.

[Bug c++/95677] undefined reference to `(anonymous namespace)::xx'

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95677

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to liusujian from comment #2)
> (In reply to Richard Biener from comment #1)
> > It's more likely the GENERIC / cgraph output by the C++ frontend is not
> > correct
> > and works by accident without LTO.  Initial symbol table:
> > 
> > Initial Symbol table:
> > 
> > int {anonymous}::xx/3 (int {anonymous}::xx) @0x7f615d2d8180
> >   Type: variable
> >   Visibility: external
> >   References:
> >   Referring: _ZN12_GLOBAL__N_13fooEv/0 (write)
> >   Availability: not-ready
> >   Varpool flags:
> > main/2 (int main()) @0x7f615d421168
> >   Type: function definition analyzed
> >   Visibility: force_output no_reorder public
> >   Aux: @0x37a5000
> >   References: int {anonymous}::xx/1 (write)
> >   Referring:
> >   Function flags: body
> >   Called by:
> >   Calls:
> > int {anonymous}::xx/1 (int {anonymous}::xx) @0x7f615d2d8100
> >   Type: variable definition analyzed
> >   Visibility: force_output no_reorder
> >   Aux: @0x7f615d421168
> >   References:
> >   Referring: main/2 (write)
> >   Availability: not-ready
> >   Varpool flags: initialized
> > _ZN12_GLOBAL__N_13fooEv/0 (void {anonymous}::foo()) @0x7f615d421000
> >   Type: function definition analyzed
> >   Visibility: force_output no_reorder
> >   Aux: @0x7f615d2d8100
> >   References: int {anonymous}::xx/3 (write)
> >   Referring:
> >   Function flags: body
> >   Called by:
> >   Calls:
> > 
> > where you can see there are actually two 'xx' objects and the C++ FE
> > takes it up to the linker/assembler to resolve them.  But the symtab
> > code does not include such "resolving" step.
> 
> 
> In other words, C++ is currently unable to deal with this scenario ? Or any
> other problems cause the error?

The C++ frontend creates two distinct objects for 'xx' (thus it does not know
they refer to the same object).  Not sure if it is possible to exploit this
fact to create a testcase that shows this fact even without LTO.  I guess
using constexpr and fail to constexpr evaluate a function using constexpr
'xx'?  Not sure if there can be a "extern" constexpr though ;)

As said the testcase "works" without LTO because both instances mangle
to the same symbol name so the assembler/linker figure they _are_ the same
object.  Just the C++ frontend doesn't know within this TU.

[Bug c++/95677] undefined reference to `(anonymous namespace)::xx'

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95677

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |accepts-invalid

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Nathan Sidwell from comment #3)
> I think the testcase is should be formed.  it was ok in C++98, but that

Should be ill-formed you wanted to say?  Even better.  Note with -std=c++98
we still would have the wrong-code issue.

> changed when anonymous namespaces gave their contents internal linkage
> (rather than external but with unpronounceable symbols).
> 
> [basic.link]/6 does not anticipate this issue.

[Bug c++/95677] undefined reference to `(anonymous namespace)::xx'

[nathan at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95677

Nathan Sidwell <nathan at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2020-06-15

--- Comment #6 from Nathan Sidwell <nathan at gcc dot gnu.org> ---
Ah, anonymous namespaces have internal linkage (and a program-wide unique
identifier).  Their contents have the linkage they have.  but because they're
within the anonumous namespace they cannot be named from elsewhere, so they
have internal linkage for implementation purposes.

when we actually gave anonymous namespaces there would be no collisions between
TUs for '<anon>::x'.  Now we give it a specific name and adjust the linkages of
their contents. 

The C++ FE should adjust the linkage of '<anon>::x' too.

[Bug c++/95677] undefined reference to `(anonymous namespace)::xx'

[sujian.liu at huawei dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95677

--- Comment #7 from liusujian <sujian.liu at huawei dot com> ---
Is this really a bug for the GCC when using LTO?
If so, is there any plan to fix this problem?

Thanks!

[Bug c++/95677] undefined reference to `(anonymous namespace)::xx'

[sujian.liu at huawei dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95677

--- Comment #8 from liusujian <sujian.liu at huawei dot com> ---
(In reply to Nathan Sidwell from comment #6)
> Ah, anonymous namespaces have internal linkage (and a program-wide unique
> identifier).  Their contents have the linkage they have.  but because
> they're within the anonumous namespace they cannot be named from elsewhere,
> so they have internal linkage for implementation purposes.
> 
> when we actually gave anonymous namespaces there would be no collisions
> between TUs for '<anon>::x'.  Now we give it a specific name and adjust the
> linkages of their contents. 
> 
> The C++ FE should adjust the linkage of '<anon>::x' too.

Hello, has there been any progress regarding the repair of this issue now?

[Bug c++/95677] undefined reference to `(anonymous namespace)::xx'

[sujian.liu at huawei dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95677

--- Comment #9 from liusujian <sujian.liu at huawei dot com> ---
After lto and as:

/home/lsj/dts/SDK_CPU_RISCV/output/hcc_riscv32/hcc_riscv32/bin/../lib/gcc/riscv32-unknown-elf/7.3.0/../../../../riscv32-unknown-elf/bin/as
-v --traditional-format -march=rv32imc -march=rv32imc -mabi=ilp32 -mabi=ilp32
-o extern2.exe.ltrans0.ltrans.o extern2.exe.ltrans0.s

We got the two symbols of _ZN12_GLOBAL__N_12xxE and _ZN12_GLOBAL__N_12xxE.lto:

./riscv32-unknown-elf-readelf -s extern2.exe.ltrans0.ltrans.o

Symbol table '.symtab' contains 21 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
     0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 00000000     0 FILE    LOCAL  DEFAULT  ABS <artificial>
     2: 00000000     0 SECTION LOCAL  DEFAULT    1
     3: 00000000     0 SECTION LOCAL  DEFAULT    3
     4: 00000000     0 SECTION LOCAL  DEFAULT    4
     5: 00000000    20 FUNC    LOCAL  DEFAULT    1 _ZN12_GLOBAL__N_13fooEv
     6: 00000000     0 NOTYPE  LOCAL  DEFAULT    1 .L0
     7: 00000006     0 NOTYPE  LOCAL  DEFAULT    1 .L0
     8: 00000010     0 NOTYPE  LOCAL  DEFAULT    1 .L0
     9: 00000014     0 NOTYPE  LOCAL  DEFAULT    1 .L0
    10: 00000000     0 SECTION LOCAL  DEFAULT    5
    11: 00000000     4 OBJECT  LOCAL  DEFAULT    5 _ZN12_GLOBAL__N_12xxE.lto
    12: 00000014     0 NOTYPE  LOCAL  DEFAULT    1 .L0
    13: 0000001a     0 NOTYPE  LOCAL  DEFAULT    1 .L0
    14: 0000002a     0 NOTYPE  LOCAL  DEFAULT    1 .L0
    15: 0000002e     0 NOTYPE  LOCAL  DEFAULT    1 .L0
    16: 00000000     0 SECTION LOCAL  DEFAULT    6
    17: 00000000     0 SECTION LOCAL  DEFAULT    7
    18: 00000000     0 SECTION LOCAL  DEFAULT    9
    19: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND _ZN12_GLOBAL__N_12xxE
    20: 00000014    26 FUNC    GLOBAL DEFAULT    1 main

We found that by GDB ,it renamed by the function of rename_statics in
gcc\lto\lto-partition.c. Here is the function body of rename_statics:
---------------------------------------------------------------------------
/* If NODE represents a static variable.  See if there are other variables
   of the same name in partition ENCODER (or in whole compilation unit if
   ENCODER is NULL) and if so, mangle the statics.  Always mangle all
   conflicting statics, so we reduce changes of silently miscompiling
   asm statements referring to them by symbol name.  */

static void
rename_statics (lto_symtab_encoder_t encoder, symtab_node *node)
{
  tree decl = node->decl;
  symtab_node *s;
  tree name = DECL_ASSEMBLER_NAME (decl);

  /* See if this is static symbol. */
  if (((node->externally_visible && !node->weakref)
      /* FIXME: externally_visible is somewhat illogically not set for
         external symbols (i.e. those not defined).  Remove this test
         once this is fixed.  */
        || DECL_EXTERNAL (node->decl)
        || !node->real_symbol_p ())
       && !may_need_named_section_p (encoder, node))
    return;

  /* Now walk symbols sharing the same name and see if there are any conflicts.
     (all types of symbols counts here, since we can not have static of the
     same name as external or public symbol.)  */
  for (s = symtab_node::get_for_asmname (name);
       s; s = s->next_sharing_asm_name)
    if ((s->real_symbol_p () || may_need_named_section_p (encoder, s))
        && s->decl != node->decl
        && (!encoder
            || lto_symtab_encoder_lookup (encoder, s) != LCC_NOT_FOUND))
       break;

  /* OK, no confict, so we have nothing to do.  */
  if (!s)
    return;

  if (symtab->dump_file)
    fprintf (symtab->dump_file,
            "Renaming statics with asm name: %s\n", node->name ());

  /* Assign every symbol in the set that shares the same ASM name an unique
     mangled name.  */
  for (s = symtab_node::get_for_asmname (name); s;)
    if ((!s->externally_visible || s->weakref)
        /* Transparent aliases having same name as target are renamed at a
           time their target gets new name.  Transparent aliases that use
           separate assembler name require the name to be unique.  */
        && (!s->transparent_alias || !s->definition || s->weakref
            || !symbol_table::assembler_names_equal_p
                 (IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (s->decl)),
                  IDENTIFIER_POINTER
                    (DECL_ASSEMBLER_NAME (s->get_alias_target()->decl))))
        && ((s->real_symbol_p ()
             && !DECL_EXTERNAL (s->decl)
             && !TREE_PUBLIC (s->decl))
            || may_need_named_section_p (encoder, s))
        && (!encoder
            || lto_symtab_encoder_lookup (encoder, s) != LCC_NOT_FOUND))
      {
        if (privatize_symbol_name (s))
          /* Re-start from beginning since we do not know how many
             symbols changed a name.  */
          s = symtab_node::get_for_asmname (name);
        else s = s->next_sharing_asm_name;
      }
    else s = s->next_sharing_asm_name;
}
---------------------------------------------------------------------------
The main problem of two symbols is whether it is externally_visible. It
determines whether the value of DECL_EXTERNAL (node->decl) is ture or false,
thereby determining whether to return this function.

Here is my patch to solve this problem:
---------------------------------------------------------------------------
diff -urpN a/gcc/lto/lto-partition.c b/gcc/lto/lto-partition.c
--- a/gcc/lto/lto-partition.c   2020-09-15 11:13:50.116566283 +0800
+++ b/gcc/lto/lto-partition.c   2020-09-15 17:10:36.951767726 +0800
@@ -1048,10 +1048,6 @@ rename_statics (lto_symtab_encoder_t enc

   /* See if this is static symbol. */
   if (((node->externally_visible && !node->weakref)
-      /* FIXME: externally_visible is somewhat illogically not set for
-        external symbols (i.e. those not defined).  Remove this test
-        once this is fixed.  */
-        || DECL_EXTERNAL (node->decl)
        || !node->real_symbol_p ())
        && !may_need_named_section_p (encoder, node))
     return;
@@ -1063,6 +1059,8 @@ rename_statics (lto_symtab_encoder_t enc
        s; s = s->next_sharing_asm_name)
     if ((s->real_symbol_p () || may_need_named_section_p (encoder, s))
        && s->decl != node->decl
+       && ((!DECL_EXTERNAL (s->decl) && !DECL_EXTERNAL (node->decl))
+           || (DECL_EXTERNAL (s->decl) && DECL_EXTERNAL (node->decl)))
        && (!encoder
            || lto_symtab_encoder_lookup (encoder, s) != LCC_NOT_FOUND))
        break;
---------------------------------------------------------------------------
what's your opinion about this?

[Bug c++/95677] undefined reference to `(anonymous namespace)::xx'

[nathan at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95677

Nathan Sidwell <nathan at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |nathan at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

--- Comment #10 from Nathan Sidwell <nathan at gcc dot gnu.org> ---
I think I'm on the path to fixing this as a side effect of getting local
externs dtrt.  This is a frontend bug

[Bug c++/95677] undefined reference to `(anonymous namespace)::xx'

[nathan at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95677

Nathan Sidwell <nathan at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #11 from Nathan Sidwell <nathan at gcc dot gnu.org> ---
fixed 4e62aca0e05