public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug other/110885] New: "undefined reference" when using both "-fdebug-types-section" and "-gsplit-dwarf"
@ 2023-08-03 6:52 linh.lrd at gmail dot com
2023-08-03 8:00 ` [Bug debug/110885] " linh.lrd at gmail dot com
` (4 more replies)
0 siblings, 5 replies; 6+ messages in thread
From: linh.lrd at gmail dot com @ 2023-08-03 6:52 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110885
Bug ID: 110885
Summary: "undefined reference" when using both
"-fdebug-types-section" and "-gsplit-dwarf"
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: linh.lrd at gmail dot com
Target Milestone: ---
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug debug/110885] "undefined reference" when using both "-fdebug-types-section" and "-gsplit-dwarf"
2023-08-03 6:52 [Bug other/110885] New: "undefined reference" when using both "-fdebug-types-section" and "-gsplit-dwarf" linh.lrd at gmail dot com
@ 2023-08-03 8:00 ` linh.lrd at gmail dot com
2023-08-03 8:12 ` [Bug debug/110885] [10/11/12/13/14 Regression] "undefined reference" when using both "-fdebug-types-section" and "-gsplit-dwarf" and inline function as a template argument pinskia at gcc dot gnu.org
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: linh.lrd at gmail dot com @ 2023-08-03 8:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110885
--- Comment #1 from Ling Nguyen <linh.lrd at gmail dot com> ---
Consider this program:
struct X
{
static void foo() {}
};
struct Y
{
template<auto func>
static void bar() {}
};
int main()
{
Y::bar<X::foo>();
return 0;
}
If it's compiled using something like: gcc -gsplit-dwarf -fdebug-types-section.
the linker will complain: undefined reference to `X::foo()'
More details here: https://godbolt.org/z/qnj56e769
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug debug/110885] [10/11/12/13/14 Regression] "undefined reference" when using both "-fdebug-types-section" and "-gsplit-dwarf" and inline function as a template argument
2023-08-03 6:52 [Bug other/110885] New: "undefined reference" when using both "-fdebug-types-section" and "-gsplit-dwarf" linh.lrd at gmail dot com
2023-08-03 8:00 ` [Bug debug/110885] " linh.lrd at gmail dot com
@ 2023-08-03 8:12 ` pinskia at gcc dot gnu.org
2023-08-03 8:20 ` linh.lrd at gmail dot com
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-08-03 8:12 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110885
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Summary|"undefined reference" when |[10/11/12/13/14 Regression]
|using both |"undefined reference" when
|"-fdebug-types-section" and |using both
|"-gsplit-dwarf" |"-fdebug-types-section" and
| |"-gsplit-dwarf" and inline
| |function as a template
| |argument
Target Milestone|--- |11.5
Last reconfirmed| |2023-08-03
--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Simplified testcase:
```
inline void foo() {}
struct Y
{
template<void (*func)()>
static void bar() {}
};
int main()
{
Y::bar<foo>();
return 0;
}
```
Confirmed.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug debug/110885] [10/11/12/13/14 Regression] "undefined reference" when using both "-fdebug-types-section" and "-gsplit-dwarf" and inline function as a template argument
2023-08-03 6:52 [Bug other/110885] New: "undefined reference" when using both "-fdebug-types-section" and "-gsplit-dwarf" linh.lrd at gmail dot com
2023-08-03 8:00 ` [Bug debug/110885] " linh.lrd at gmail dot com
2023-08-03 8:12 ` [Bug debug/110885] [10/11/12/13/14 Regression] "undefined reference" when using both "-fdebug-types-section" and "-gsplit-dwarf" and inline function as a template argument pinskia at gcc dot gnu.org
@ 2023-08-03 8:20 ` linh.lrd at gmail dot com
2023-08-03 11:48 ` rguenth at gcc dot gnu.org
2024-03-07 23:26 ` law at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: linh.lrd at gmail dot com @ 2023-08-03 8:20 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110885
--- Comment #3 from Ling Nguyen <linh.lrd at gmail dot com> ---
Thanks for quick responses.
A further look into the issue:
I believe there is bug in this piece of code:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/dwarf2out.cc;h=fa0fe4c41bbd5b13aa5fe6cad6e7d39bbd82174a;hb=HEAD#l8501
It should probably be:
if (is_template_instantiation (c))
{
/* Instantiated templates do not need to be cloned into the
type unit. Just move the DIE and its children back to
the skeleton tree (in the main CU). */
remove_child_with_prev (c, prev);
generate_skeleton_ancestor_tree (parent);
add_child_die (parent->new_die, c);
c = prev;
}
Don't mean to teach a fish to swim here, because I'm no expert. Just want to
help to reduce the search space.
By the way, any chance for a fix (whenever it is) to land on gcc 10.2, as we
are fixed to it?
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug debug/110885] [10/11/12/13/14 Regression] "undefined reference" when using both "-fdebug-types-section" and "-gsplit-dwarf" and inline function as a template argument
2023-08-03 6:52 [Bug other/110885] New: "undefined reference" when using both "-fdebug-types-section" and "-gsplit-dwarf" linh.lrd at gmail dot com
` (2 preceding siblings ...)
2023-08-03 8:20 ` linh.lrd at gmail dot com
@ 2023-08-03 11:48 ` rguenth at gcc dot gnu.org
2024-03-07 23:26 ` law at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-08-03 11:48 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110885
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |wrong-debug
Version|unknown |13.2.0
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
There's probably a duplicate about this. I'll note that both -gsplit-dwarf and
more specifically -fdebug-types-section are unmaintained. As a workaround
you can use -gdwarf-3 it seems.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug debug/110885] [10/11/12/13/14 Regression] "undefined reference" when using both "-fdebug-types-section" and "-gsplit-dwarf" and inline function as a template argument
2023-08-03 6:52 [Bug other/110885] New: "undefined reference" when using both "-fdebug-types-section" and "-gsplit-dwarf" linh.lrd at gmail dot com
` (3 preceding siblings ...)
2023-08-03 11:48 ` rguenth at gcc dot gnu.org
@ 2024-03-07 23:26 ` law at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: law at gcc dot gnu.org @ 2024-03-07 23:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110885
Jeffrey A. Law <law at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |law at gcc dot gnu.org
Priority|P3 |P2
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2024-03-07 23:27 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-08-03 6:52 [Bug other/110885] New: "undefined reference" when using both "-fdebug-types-section" and "-gsplit-dwarf" linh.lrd at gmail dot com
2023-08-03 8:00 ` [Bug debug/110885] " linh.lrd at gmail dot com
2023-08-03 8:12 ` [Bug debug/110885] [10/11/12/13/14 Regression] "undefined reference" when using both "-fdebug-types-section" and "-gsplit-dwarf" and inline function as a template argument pinskia at gcc dot gnu.org
2023-08-03 8:20 ` linh.lrd at gmail dot com
2023-08-03 11:48 ` rguenth at gcc dot gnu.org
2024-03-07 23:26 ` law 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).