* std::basic_string<_Tp> constructor point of instantiation woes?
@ 2021-11-22 16:30 Stephan Bergmann
2021-12-03 22:38 ` Jonathan Wakely
0 siblings, 1 reply; 3+ messages in thread
From: Stephan Bergmann @ 2021-11-22 16:30 UTC (permalink / raw)
To: libstdc++; +Cc: gcc-patches
When using recent libstc++ trunk with Clang in C++20 mode,
std::u16string literals as in
> #include <string>
> int main() {
> using namespace std::literals;
> u""s;
> }
started to cause linker failures due to undefined
> _ZNSt7__cxx1112basic_stringIDsSt11char_traitsIDsESaIDsEE12_M_constructIPKDsEEvT_S8_St20forward_iterator_tag
After some head scratching, I found the more insightful
> $ cat test.cc
> #include <string>
> constexpr std::string s("", 0);
> $ clang++ -std=c++20 -fsyntax-only test.cc
> test.cc:2:23: error: constexpr variable 's' must be initialized by a constant expression
> constexpr std::string s("", 0);
> ^~~~~~~~
> ~/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/12.0.0/../../../../include/c++/12.0.0/bits/basic_string.h:620:2: note: undefined function '_M_construct<const char *>' cannot be used in a constant expression
> _M_construct(__s, __s + __n, std::forward_iterator_tag());
> ^
> test.cc:2:23: note: in call to 'basic_string(&""[0], 0, std::allocator<char>())'
> constexpr std::string s("", 0);
> ^
> ~/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/12.0.0/../../../../include/c++/12.0.0/bits/basic_string.h:331:9: note: declared here
> _M_construct(_FwdIterator __beg, _FwdIterator __end,
> ^
> 1 error generated.
and after some more head scratching found Clang to complain about the
reduced
> template<typename> struct S {
> constexpr void f();
> constexpr S() { f(); };
> };
> S<void> s1;
> template<typename T> constexpr void S<T>::f() {}
> constexpr S<void> s2;
(about which GCC does not complain). Not entirely sure who is right,
but what would help Clang is to move the definitions of the literal
operators in basic_string.h (which implicitly instantiate the
corresponding std::basic_string<_Tp> constructor) past the definition of
_M_construct (which is called from the constructor) in basic_string.tcc;
something like
> diff --git a/libstdc++-v3/include/bits/basic_string.h b/libstdc++-v3/include/bits/basic_string.h
> index 6e7de738308..871ca89e16e 100644
> --- a/libstdc++-v3/include/bits/basic_string.h
> +++ b/libstdc++-v3/include/bits/basic_string.h
> @@ -4304,55 +4304,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> struct __is_fast_hash<hash<u32string>> : std::false_type
> { };
>
> -#if __cplusplus >= 201402L
> -
> -#define __cpp_lib_string_udls 201304
> -
> - inline namespace literals
> - {
> - inline namespace string_literals
> - {
> -#pragma GCC diagnostic push
> -#pragma GCC diagnostic ignored "-Wliteral-suffix"
> -
> -#if __cpp_lib_constexpr_string >= 201907L
> -# define _GLIBCXX_STRING_CONSTEXPR constexpr
> -#else
> -# define _GLIBCXX_STRING_CONSTEXPR
> -#endif
> -
> - _GLIBCXX_DEFAULT_ABI_TAG _GLIBCXX_STRING_CONSTEXPR
> - inline basic_string<char>
> - operator""s(const char* __str, size_t __len)
> - { return basic_string<char>{__str, __len}; }
> -
> - _GLIBCXX_DEFAULT_ABI_TAG _GLIBCXX_STRING_CONSTEXPR
> - inline basic_string<wchar_t>
> - operator""s(const wchar_t* __str, size_t __len)
> - { return basic_string<wchar_t>{__str, __len}; }
> -
> -#ifdef _GLIBCXX_USE_CHAR8_T
> - _GLIBCXX_DEFAULT_ABI_TAG _GLIBCXX_STRING_CONSTEXPR
> - inline basic_string<char8_t>
> - operator""s(const char8_t* __str, size_t __len)
> - { return basic_string<char8_t>{__str, __len}; }
> -#endif
> -
> - _GLIBCXX_DEFAULT_ABI_TAG _GLIBCXX_STRING_CONSTEXPR
> - inline basic_string<char16_t>
> - operator""s(const char16_t* __str, size_t __len)
> - { return basic_string<char16_t>{__str, __len}; }
> -
> - _GLIBCXX_DEFAULT_ABI_TAG _GLIBCXX_STRING_CONSTEXPR
> - inline basic_string<char32_t>
> - operator""s(const char32_t* __str, size_t __len)
> - { return basic_string<char32_t>{__str, __len}; }
> -
> -#undef _GLIBCXX_STRING_CONSTEXPR
> -#pragma GCC diagnostic pop
> - } // inline namespace string_literals
> - } // inline namespace literals
> -
> #if __cplusplus >= 201703L
> namespace __detail::__variant
> {
> @@ -4369,7 +4320,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> { };
> } // namespace __detail::__variant
> #endif // C++17
> -#endif // C++14
>
> _GLIBCXX_END_NAMESPACE_VERSION
> } // namespace std
> diff --git a/libstdc++-v3/include/bits/basic_string.tcc b/libstdc++-v3/include/bits/basic_string.tcc
> index 6f619a08f70..2fd607ef50a 100644
> --- a/libstdc++-v3/include/bits/basic_string.tcc
> +++ b/libstdc++-v3/include/bits/basic_string.tcc
> @@ -1123,6 +1123,57 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> #endif // _GLIBCXX_USE_WCHAR_T
> #endif // _GLIBCXX_EXTERN_TEMPLATE
>
> +#if __cplusplus >= 201402L
> +
> +#define __cpp_lib_string_udls 201304
> +
> + inline namespace literals
> + {
> + inline namespace string_literals
> + {
> +#pragma GCC diagnostic push
> +#pragma GCC diagnostic ignored "-Wliteral-suffix"
> +
> +#if __cpp_lib_constexpr_string >= 201907L
> +# define _GLIBCXX_STRING_CONSTEXPR constexpr
> +#else
> +# define _GLIBCXX_STRING_CONSTEXPR
> +#endif
> +
> + _GLIBCXX_DEFAULT_ABI_TAG _GLIBCXX_STRING_CONSTEXPR
> + inline basic_string<char>
> + operator""s(const char* __str, size_t __len)
> + { return basic_string<char>{__str, __len}; }
> +
> + _GLIBCXX_DEFAULT_ABI_TAG _GLIBCXX_STRING_CONSTEXPR
> + inline basic_string<wchar_t>
> + operator""s(const wchar_t* __str, size_t __len)
> + { return basic_string<wchar_t>{__str, __len}; }
> +
> +#ifdef _GLIBCXX_USE_CHAR8_T
> + _GLIBCXX_DEFAULT_ABI_TAG _GLIBCXX_STRING_CONSTEXPR
> + inline basic_string<char8_t>
> + operator""s(const char8_t* __str, size_t __len)
> + { return basic_string<char8_t>{__str, __len}; }
> +#endif
> +
> + _GLIBCXX_DEFAULT_ABI_TAG _GLIBCXX_STRING_CONSTEXPR
> + inline basic_string<char16_t>
> + operator""s(const char16_t* __str, size_t __len)
> + { return basic_string<char16_t>{__str, __len}; }
> +
> + _GLIBCXX_DEFAULT_ABI_TAG _GLIBCXX_STRING_CONSTEXPR
> + inline basic_string<char32_t>
> + operator""s(const char32_t* __str, size_t __len)
> + { return basic_string<char32_t>{__str, __len}; }
> +
> +#undef _GLIBCXX_STRING_CONSTEXPR
> +#pragma GCC diagnostic pop
> + } // inline namespace string_literals
> + } // inline namespace literals
> +
> +#endif // C++14
> +
> _GLIBCXX_END_NAMESPACE_VERSION
> } // namespace std
>
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: std::basic_string<_Tp> constructor point of instantiation woes?
2021-11-22 16:30 std::basic_string<_Tp> constructor point of instantiation woes? Stephan Bergmann
@ 2021-12-03 22:38 ` Jonathan Wakely
2021-12-12 23:53 ` Jonathan Wakely
0 siblings, 1 reply; 3+ messages in thread
From: Jonathan Wakely @ 2021-12-03 22:38 UTC (permalink / raw)
To: Stephan Bergmann; +Cc: libstdc++, gcc Patches
On Mon, 22 Nov 2021 at 16:31, Stephan Bergmann via Libstdc++
<libstdc++@gcc.gnu.org> wrote:
>
> When using recent libstc++ trunk with Clang in C++20 mode,
> std::u16string literals as in
>
> > #include <string>
> > int main() {
> > using namespace std::literals;
> > u""s;
> > }
>
> started to cause linker failures due to undefined
>
> > _ZNSt7__cxx1112basic_stringIDsSt11char_traitsIDsESaIDsEE12_M_constructIPKDsEEvT_S8_St20forward_iterator_tag
>
> After some head scratching, I found the more insightful
>
> > $ cat test.cc
> > #include <string>
> > constexpr std::string s("", 0);
>
> > $ clang++ -std=c++20 -fsyntax-only test.cc
> > test.cc:2:23: error: constexpr variable 's' must be initialized by a constant expression
> > constexpr std::string s("", 0);
> > ^~~~~~~~
> > ~/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/12.0.0/../../../../include/c++/12.0.0/bits/basic_string.h:620:2: note: undefined function '_M_construct<const char *>' cannot be used in a constant expression
> > _M_construct(__s, __s + __n, std::forward_iterator_tag());
> > ^
> > test.cc:2:23: note: in call to 'basic_string(&""[0], 0, std::allocator<char>())'
> > constexpr std::string s("", 0);
> > ^
> > ~/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/12.0.0/../../../../include/c++/12.0.0/bits/basic_string.h:331:9: note: declared here
> > _M_construct(_FwdIterator __beg, _FwdIterator __end,
> > ^
> > 1 error generated.
>
> and after some more head scratching found Clang to complain about the
> reduced
>
> > template<typename> struct S {
> > constexpr void f();
> > constexpr S() { f(); };
> > };
> > S<void> s1;
> > template<typename T> constexpr void S<T>::f() {}
> > constexpr S<void> s2;
>
> (about which GCC does not complain). Not entirely sure who is right,
> but what would help Clang is to move the definitions of the literal
> operators in basic_string.h (which implicitly instantiate the
> corresponding std::basic_string<_Tp> constructor) past the definition of
> _M_construct (which is called from the constructor) in basic_string.tcc;
> something like
The .tcc files are something of an anachronism, as I think they were
supposed to have the non-inline function definitions which might be
subject to 'export' for separate compilation. Except that feature was
removed from C++11, and so now it's just a fairly pointless separation
between inline and non-inline functions ... except where we're muddied
the waters by changing some to 'inline' without moving them to the
other file (because why bother).
That said, all the one- or two-line inline functions like the literal
operators and to_string are all in basic_string.h and having to move
some arbitrary subset of them into the other file, after the
non-inline definitions, is a bit annoying.
I think this is https://bugs.llvm.org/show_bug.cgi?id=24128
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: std::basic_string<_Tp> constructor point of instantiation woes?
2021-12-03 22:38 ` Jonathan Wakely
@ 2021-12-12 23:53 ` Jonathan Wakely
0 siblings, 0 replies; 3+ messages in thread
From: Jonathan Wakely @ 2021-12-12 23:53 UTC (permalink / raw)
To: Stephan Bergmann; +Cc: libstdc++, gcc Patches
On Fri, 3 Dec 2021 at 22:38, Jonathan Wakely wrote:
>
> On Mon, 22 Nov 2021 at 16:31, Stephan Bergmann via Libstdc++
> <libstdc++@gcc.gnu.org> wrote:
> >
> > When using recent libstc++ trunk with Clang in C++20 mode,
> > std::u16string literals as in
> >
> > > #include <string>
> > > int main() {
> > > using namespace std::literals;
> > > u""s;
> > > }
> >
> > started to cause linker failures due to undefined
> >
> > > _ZNSt7__cxx1112basic_stringIDsSt11char_traitsIDsESaIDsEE12_M_constructIPKDsEEvT_S8_St20forward_iterator_tag
> >
> > After some head scratching, I found the more insightful
> >
> > > $ cat test.cc
> > > #include <string>
> > > constexpr std::string s("", 0);
> >
> > > $ clang++ -std=c++20 -fsyntax-only test.cc
> > > test.cc:2:23: error: constexpr variable 's' must be initialized by a constant expression
> > > constexpr std::string s("", 0);
> > > ^~~~~~~~
> > > ~/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/12.0.0/../../../../include/c++/12.0.0/bits/basic_string.h:620:2: note: undefined function '_M_construct<const char *>' cannot be used in a constant expression
> > > _M_construct(__s, __s + __n, std::forward_iterator_tag());
> > > ^
> > > test.cc:2:23: note: in call to 'basic_string(&""[0], 0, std::allocator<char>())'
> > > constexpr std::string s("", 0);
> > > ^
> > > ~/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/12.0.0/../../../../include/c++/12.0.0/bits/basic_string.h:331:9: note: declared here
> > > _M_construct(_FwdIterator __beg, _FwdIterator __end,
> > > ^
> > > 1 error generated.
> >
> > and after some more head scratching found Clang to complain about the
> > reduced
> >
> > > template<typename> struct S {
> > > constexpr void f();
> > > constexpr S() { f(); };
> > > };
> > > S<void> s1;
> > > template<typename T> constexpr void S<T>::f() {}
> > > constexpr S<void> s2;
> >
> > (about which GCC does not complain). Not entirely sure who is right,
> > but what would help Clang is to move the definitions of the literal
> > operators in basic_string.h (which implicitly instantiate the
> > corresponding std::basic_string<_Tp> constructor) past the definition of
> > _M_construct (which is called from the constructor) in basic_string.tcc;
> > something like
>
> The .tcc files are something of an anachronism, as I think they were
> supposed to have the non-inline function definitions which might be
> subject to 'export' for separate compilation. Except that feature was
> removed from C++11, and so now it's just a fairly pointless separation
> between inline and non-inline functions ... except where we're muddied
> the waters by changing some to 'inline' without moving them to the
> other file (because why bother).
>
> That said, all the one- or two-line inline functions like the literal
> operators and to_string are all in basic_string.h and having to move
> some arbitrary subset of them into the other file, after the
> non-inline definitions, is a bit annoying.
>
> I think this is https://bugs.llvm.org/show_bug.cgi?id=24128
Which is now https://github.com/llvm/llvm-project/issues/24502
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2021-12-12 23:53 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-11-22 16:30 std::basic_string<_Tp> constructor point of instantiation woes? Stephan Bergmann
2021-12-03 22:38 ` Jonathan Wakely
2021-12-12 23:53 ` Jonathan Wakely
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).