public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/108636] C++20 undefined reference to `std::filesystem::__cxx11::path::_List::type(std::filesystem::__cxx11::path::_Type)' with -fkeep-inline-functions Date: Thu, 02 Feb 2023 13:46:53 +0000 [thread overview] Message-ID: <bug-108636-4-2rGOKszY6g@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-108636-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108636 Jonathan Wakely <redi at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> --- The problem with path::_List::type(_Type) is that it's only ever used by a private constructor of path, which is only ever called from within the library. But when you use -fkeep-inline-functions that private constructor gets compiled into your code even though you don't (and can't) ever use it. The fix is to move the definitions of those private constructors into the library too, so that they aren't compiled into your code even with -fkeep-inline-functions. diff --git a/libstdc++-v3/include/bits/fs_path.h b/libstdc++-v3/include/bits/fs_path.h index 1cbfaaa5427..0d7bb10c1a0 100644 --- a/libstdc++-v3/include/bits/fs_path.h +++ b/libstdc++-v3/include/bits/fs_path.h @@ -596,12 +596,7 @@ namespace __detail _Multi = 0, _Root_name, _Root_dir, _Filename }; - path(basic_string_view<value_type> __str, _Type __type) - : _M_pathname(__str) - { - __glibcxx_assert(__type != _Type::_Multi); - _M_cmpts.type(__type); - } + path(basic_string_view<value_type> __str, _Type __type); enum class _Split { _Stem, _Extension }; @@ -851,8 +846,7 @@ namespace __detail struct path::_Cmpt : path { - _Cmpt(basic_string_view<value_type> __s, _Type __t, size_t __pos) - : path(__s, __t), _M_pos(__pos) { } + _Cmpt(basic_string_view<value_type> __s, _Type __t, size_t __pos); _Cmpt() : _M_pos(-1) { } diff --git a/libstdc++-v3/src/c++17/fs_path.cc b/libstdc++-v3/src/c++17/fs_path.cc index 93149c4b415..aaea7d2725d 100644 --- a/libstdc++-v3/src/c++17/fs_path.cc +++ b/libstdc++-v3/src/c++17/fs_path.cc @@ -187,6 +187,19 @@ struct path::_Parser { return origin + c.str.data() - input.data(); } }; +inline +path::path(basic_string_view<value_type> __str, _Type __type) +: _M_pathname(__str) +{ + __glibcxx_assert(__type != _Type::_Multi); + _M_cmpts.type(__type); +} + +inline +path::_Cmpt::_Cmpt(basic_string_view<value_type> __s, _Type __t, size_t __pos) +: path(__s, __t), _M_pos(__pos) +{ } + struct path::_List::_Impl { using value_type = _Cmpt; The good news is this doesn't have any ABI impact, so can be backported to the release branches. For the other undefined symbols noted in comment 1, those require new symbols to be exported from the library. The good news there is that the comparisons with default_sentinel_t are new in GCC 13 and so we don't need to backport anything.
next prev parent reply other threads:[~2023-02-02 13:46 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-02-02 12:03 [Bug c++/108636] New: C++20 to " hnc at singularity dot fr 2023-02-02 12:11 ` [Bug libstdc++/108636] " redi at gcc dot gnu.org 2023-02-02 13:25 ` [Bug libstdc++/108636] C++20 " redi at gcc dot gnu.org 2023-02-02 13:46 ` redi at gcc dot gnu.org [this message] 2023-02-02 16:47 ` cvs-commit at gcc dot gnu.org 2023-02-02 17:12 ` [Bug libstdc++/108636] [10/11/12 Regression] " redi at gcc dot gnu.org 2023-02-21 0:48 ` cvs-commit at gcc dot gnu.org 2023-03-16 16:51 ` [Bug libstdc++/108636] [10/11 " cvs-commit at gcc dot gnu.org 2023-03-16 17:53 ` [Bug libstdc++/108636] [10 " cvs-commit at gcc dot gnu.org 2023-03-16 17:54 ` redi at gcc dot gnu.org 2024-01-31 22:23 ` Mark_B53 at yahoo dot com 2024-02-01 18:36 ` redi at gcc dot gnu.org 2024-02-02 10:35 ` cvs-commit at gcc dot gnu.org 2024-02-02 10:40 ` redi at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-108636-4-2rGOKszY6g@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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).