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.

  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: link
Be 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).