public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug lto/95677] New: undefined reference to `(anonymous namespace)::xx'
@ 2020-06-15 8:00 sujian.liu at huawei dot com
2020-06-15 8:12 ` [Bug c++/95677] " rguenth at gcc dot gnu.org
` (10 more replies)
0 siblings, 11 replies; 12+ messages in thread
From: sujian.liu at huawei dot com @ 2020-06-15 8:00 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/95677] undefined reference to `(anonymous namespace)::xx'
2020-06-15 8:00 [Bug lto/95677] New: undefined reference to `(anonymous namespace)::xx' sujian.liu at huawei dot com
@ 2020-06-15 8:12 ` rguenth at gcc dot gnu.org
2020-06-15 8:36 ` sujian.liu at huawei dot com
` (9 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-06-15 8:12 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/95677] undefined reference to `(anonymous namespace)::xx'
2020-06-15 8:00 [Bug lto/95677] New: undefined reference to `(anonymous namespace)::xx' sujian.liu at huawei dot com
2020-06-15 8:12 ` [Bug c++/95677] " rguenth at gcc dot gnu.org
@ 2020-06-15 8:36 ` sujian.liu at huawei dot com
2020-06-15 12:02 ` nathan at gcc dot gnu.org
` (8 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: sujian.liu at huawei dot com @ 2020-06-15 8:36 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/95677] undefined reference to `(anonymous namespace)::xx'
2020-06-15 8:00 [Bug lto/95677] New: undefined reference to `(anonymous namespace)::xx' sujian.liu at huawei dot com
2020-06-15 8:12 ` [Bug c++/95677] " rguenth at gcc dot gnu.org
2020-06-15 8:36 ` sujian.liu at huawei dot com
@ 2020-06-15 12:02 ` nathan at gcc dot gnu.org
2020-06-15 12:05 ` rguenth at gcc dot gnu.org
` (7 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: nathan at gcc dot gnu.org @ 2020-06-15 12:02 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/95677] undefined reference to `(anonymous namespace)::xx'
2020-06-15 8:00 [Bug lto/95677] New: undefined reference to `(anonymous namespace)::xx' sujian.liu at huawei dot com
` (2 preceding siblings ...)
2020-06-15 12:02 ` nathan at gcc dot gnu.org
@ 2020-06-15 12:05 ` rguenth at gcc dot gnu.org
2020-06-15 12:07 ` rguenth at gcc dot gnu.org
` (6 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-06-15 12:05 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/95677] undefined reference to `(anonymous namespace)::xx'
2020-06-15 8:00 [Bug lto/95677] New: undefined reference to `(anonymous namespace)::xx' sujian.liu at huawei dot com
` (3 preceding siblings ...)
2020-06-15 12:05 ` rguenth at gcc dot gnu.org
@ 2020-06-15 12:07 ` rguenth at gcc dot gnu.org
2020-06-15 12:28 ` nathan at gcc dot gnu.org
` (5 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-06-15 12:07 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/95677] undefined reference to `(anonymous namespace)::xx'
2020-06-15 8:00 [Bug lto/95677] New: undefined reference to `(anonymous namespace)::xx' sujian.liu at huawei dot com
` (4 preceding siblings ...)
2020-06-15 12:07 ` rguenth at gcc dot gnu.org
@ 2020-06-15 12:28 ` nathan at gcc dot gnu.org
2020-06-18 7:34 ` sujian.liu at huawei dot com
` (4 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: nathan at gcc dot gnu.org @ 2020-06-15 12:28 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/95677] undefined reference to `(anonymous namespace)::xx'
2020-06-15 8:00 [Bug lto/95677] New: undefined reference to `(anonymous namespace)::xx' sujian.liu at huawei dot com
` (5 preceding siblings ...)
2020-06-15 12:28 ` nathan at gcc dot gnu.org
@ 2020-06-18 7:34 ` sujian.liu at huawei dot com
2020-07-15 1:40 ` sujian.liu at huawei dot com
` (3 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: sujian.liu at huawei dot com @ 2020-06-18 7:34 UTC (permalink / raw)
To: gcc-bugs
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!
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/95677] undefined reference to `(anonymous namespace)::xx'
2020-06-15 8:00 [Bug lto/95677] New: undefined reference to `(anonymous namespace)::xx' sujian.liu at huawei dot com
` (6 preceding siblings ...)
2020-06-18 7:34 ` sujian.liu at huawei dot com
@ 2020-07-15 1:40 ` sujian.liu at huawei dot com
2020-09-16 8:11 ` sujian.liu at huawei dot com
` (2 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: sujian.liu at huawei dot com @ 2020-07-15 1:40 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/95677] undefined reference to `(anonymous namespace)::xx'
2020-06-15 8:00 [Bug lto/95677] New: undefined reference to `(anonymous namespace)::xx' sujian.liu at huawei dot com
` (7 preceding siblings ...)
2020-07-15 1:40 ` sujian.liu at huawei dot com
@ 2020-09-16 8:11 ` sujian.liu at huawei dot com
2020-09-23 17:41 ` nathan at gcc dot gnu.org
2020-10-07 14:35 ` nathan at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: sujian.liu at huawei dot com @ 2020-09-16 8:11 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/95677] undefined reference to `(anonymous namespace)::xx'
2020-06-15 8:00 [Bug lto/95677] New: undefined reference to `(anonymous namespace)::xx' sujian.liu at huawei dot com
` (8 preceding siblings ...)
2020-09-16 8:11 ` sujian.liu at huawei dot com
@ 2020-09-23 17:41 ` nathan at gcc dot gnu.org
2020-10-07 14:35 ` nathan at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: nathan at gcc dot gnu.org @ 2020-09-23 17:41 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/95677] undefined reference to `(anonymous namespace)::xx'
2020-06-15 8:00 [Bug lto/95677] New: undefined reference to `(anonymous namespace)::xx' sujian.liu at huawei dot com
` (9 preceding siblings ...)
2020-09-23 17:41 ` nathan at gcc dot gnu.org
@ 2020-10-07 14:35 ` nathan at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: nathan at gcc dot gnu.org @ 2020-10-07 14:35 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2020-10-07 14:35 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-15 8:00 [Bug lto/95677] New: undefined reference to `(anonymous namespace)::xx' sujian.liu at huawei dot com
2020-06-15 8:12 ` [Bug c++/95677] " rguenth at gcc dot gnu.org
2020-06-15 8:36 ` sujian.liu at huawei dot com
2020-06-15 12:02 ` nathan at gcc dot gnu.org
2020-06-15 12:05 ` rguenth at gcc dot gnu.org
2020-06-15 12:07 ` rguenth at gcc dot gnu.org
2020-06-15 12:28 ` nathan at gcc dot gnu.org
2020-06-18 7:34 ` sujian.liu at huawei dot com
2020-07-15 1:40 ` sujian.liu at huawei dot com
2020-09-16 8:11 ` sujian.liu at huawei dot com
2020-09-23 17:41 ` nathan at gcc dot gnu.org
2020-10-07 14:35 ` nathan at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).