* trunk -D_GLIBCXX_DEBUG #include <regex> fails @ 2021-08-09 9:50 Stephan Bergmann 2021-08-09 10:05 ` Jonathan Wakely 0 siblings, 1 reply; 7+ messages in thread From: Stephan Bergmann @ 2021-08-09 9:50 UTC (permalink / raw) To: libstdc++, gcc-patches Not sure why I started to experience this now with a recent GCC/libstdc++ trunk build: > $ cat test.cc > #include <regex> > $ gcc/trunk/inst/bin/g++ -D_GLIBCXX_DEBUG -fsyntax-only test.cc > In file included from /home/sbergman/gcc/trunk/inst/include/c++/12.0.0/bits/regex_automaton.h:401, > from /home/sbergman/gcc/trunk/inst/include/c++/12.0.0/regex:60, > from test.cc:1: > /home/sbergman/gcc/trunk/inst/include/c++/12.0.0/bits/regex_automaton.tcc: In member function ‘std::__detail::_StateSeq<_TraitsT> std::__detail::_StateSeq<_TraitsT>::_M_clone()’: > /home/sbergman/gcc/trunk/inst/include/c++/12.0.0/bits/regex_automaton.tcc:197:12: error: ‘map’ is not a member of ‘std’ > 197 | std::map<_StateIdT, _StateIdT> __m; > | ^~~ [...] > In file included from /home/sbergman/gcc/trunk/inst/include/c++/12.0.0/regex:62, > from test.cc:1: > /home/sbergman/gcc/trunk/inst/include/c++/12.0.0/bits/regex_compiler.h: At global scope: > /home/sbergman/gcc/trunk/inst/include/c++/12.0.0/bits/regex_compiler.h:541:12: error: ‘vector’ in namespace ‘std’ does not name a template type > 541 | std::vector<_CharT> _M_char_set; > | ^~~~~~ [...] where neither the use of std::map in bits/regex_automaton.tcc nor the use of std::vector in bits/regex_compiler.h are in _GLIBCXX_DEBUG-only code (but compiling without -D_GLIBCXX_DEBUG succeeded). Anyway, what would apparently fix it for me is > diff --git a/libstdc++-v3/include/std/regex b/libstdc++-v3/include/std/regex > index 04fb8b2d971..29fd2956fd0 100644 > --- a/libstdc++-v3/include/std/regex > +++ b/libstdc++-v3/include/std/regex > @@ -42,6 +42,11 @@ > #include <stdexcept> > #include <string> > > +#if defined _GLIBCXX_DEBUG > +#include <map> > +#include <vector> > +#endif > + > #include <ext/aligned_buffer.h> > #include <ext/numeric_traits.h> > #include <bits/shared_ptr.h> ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: trunk -D_GLIBCXX_DEBUG #include <regex> fails 2021-08-09 9:50 trunk -D_GLIBCXX_DEBUG #include <regex> fails Stephan Bergmann @ 2021-08-09 10:05 ` Jonathan Wakely 2021-08-09 12:05 ` François Dumont 0 siblings, 1 reply; 7+ messages in thread From: Jonathan Wakely @ 2021-08-09 10:05 UTC (permalink / raw) To: Stephan Bergmann; +Cc: libstdc++, gcc Patches On Mon, 9 Aug 2021 at 10:51, Stephan Bergmann via Libstdc++ <libstdc++@gcc.gnu.org> wrote: > > Not sure why I started to experience this now with a recent > GCC/libstdc++ trunk build: > > > $ cat test.cc > > #include <regex> > > > $ gcc/trunk/inst/bin/g++ -D_GLIBCXX_DEBUG -fsyntax-only test.cc > > In file included from /home/sbergman/gcc/trunk/inst/include/c++/12.0.0/bits/regex_automaton.h:401, > > from /home/sbergman/gcc/trunk/inst/include/c++/12.0.0/regex:60, > > from test.cc:1: > > /home/sbergman/gcc/trunk/inst/include/c++/12.0.0/bits/regex_automaton.tcc: In member function ‘std::__detail::_StateSeq<_TraitsT> std::__detail::_StateSeq<_TraitsT>::_M_clone()’: > > /home/sbergman/gcc/trunk/inst/include/c++/12.0.0/bits/regex_automaton.tcc:197:12: error: ‘map’ is not a member of ‘std’ > > 197 | std::map<_StateIdT, _StateIdT> __m; > > | ^~~ > [...] > > In file included from /home/sbergman/gcc/trunk/inst/include/c++/12.0.0/regex:62, > > from test.cc:1: > > /home/sbergman/gcc/trunk/inst/include/c++/12.0.0/bits/regex_compiler.h: At global scope: > > /home/sbergman/gcc/trunk/inst/include/c++/12.0.0/bits/regex_compiler.h:541:12: error: ‘vector’ in namespace ‘std’ does not name a template type > > 541 | std::vector<_CharT> _M_char_set; > > | ^~~~~~ > [...] > > where neither the use of std::map in bits/regex_automaton.tcc nor the > use of std::vector in bits/regex_compiler.h are in _GLIBCXX_DEBUG-only > code (but compiling without -D_GLIBCXX_DEBUG succeeded). With that flag the container implementations are defined in namespace __gnu_cxx1998, and std::map is supposed to refer to __gnu_debug::map. But the debug map is declared in a header which isn't included by <regex> since I replaced <map> with <bits/stl_map.h>. > > Anyway, what would apparently fix it for me is > > > diff --git a/libstdc++-v3/include/std/regex b/libstdc++-v3/include/std/regex > > index 04fb8b2d971..29fd2956fd0 100644 > > --- a/libstdc++-v3/include/std/regex > > +++ b/libstdc++-v3/include/std/regex > > @@ -42,6 +42,11 @@ > > #include <stdexcept> > > #include <string> > > > > +#if defined _GLIBCXX_DEBUG > > +#include <map> > > +#include <vector> > > +#endif > > + I think we can do this instead: --- a/libstdc++-v3/include/std/regex +++ b/libstdc++-v3/include/std/regex @@ -63,6 +63,11 @@ #include <bits/regex.h> #include <bits/regex_executor.h> +#ifdef _GLIBCXX_DEBUG +# include <debug/map> +# include <debug/vector> +#endif + #if __cplusplus >= 201703L && _GLIBCXX_USE_CXX11_ABI namespace std _GLIBCXX_VISIBILITY(default) { I'll test it, thanks for the report. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: trunk -D_GLIBCXX_DEBUG #include <regex> fails 2021-08-09 10:05 ` Jonathan Wakely @ 2021-08-09 12:05 ` François Dumont 2021-08-09 14:27 ` Jonathan Wakely 0 siblings, 1 reply; 7+ messages in thread From: François Dumont @ 2021-08-09 12:05 UTC (permalink / raw) To: libstdc++ On 09/08/21 12:05 pm, Jonathan Wakely via Libstdc++ wrote: > On Mon, 9 Aug 2021 at 10:51, Stephan Bergmann via Libstdc++ > <libstdc++@gcc.gnu.org> wrote: >> Not sure why I started to experience this now with a recent >> GCC/libstdc++ trunk build: >> >>> $ cat test.cc >>> #include <regex> >>> $ gcc/trunk/inst/bin/g++ -D_GLIBCXX_DEBUG -fsyntax-only test.cc >>> In file included from /home/sbergman/gcc/trunk/inst/include/c++/12.0.0/bits/regex_automaton.h:401, >>> from /home/sbergman/gcc/trunk/inst/include/c++/12.0.0/regex:60, >>> from test.cc:1: >>> /home/sbergman/gcc/trunk/inst/include/c++/12.0.0/bits/regex_automaton.tcc: In member function ‘std::__detail::_StateSeq<_TraitsT> std::__detail::_StateSeq<_TraitsT>::_M_clone()’: >>> /home/sbergman/gcc/trunk/inst/include/c++/12.0.0/bits/regex_automaton.tcc:197:12: error: ‘map’ is not a member of ‘std’ >>> 197 | std::map<_StateIdT, _StateIdT> __m; >>> | ^~~ >> [...] >>> In file included from /home/sbergman/gcc/trunk/inst/include/c++/12.0.0/regex:62, >>> from test.cc:1: >>> /home/sbergman/gcc/trunk/inst/include/c++/12.0.0/bits/regex_compiler.h: At global scope: >>> /home/sbergman/gcc/trunk/inst/include/c++/12.0.0/bits/regex_compiler.h:541:12: error: ‘vector’ in namespace ‘std’ does not name a template type >>> 541 | std::vector<_CharT> _M_char_set; >>> | ^~~~~~ >> [...] >> >> where neither the use of std::map in bits/regex_automaton.tcc nor the >> use of std::vector in bits/regex_compiler.h are in _GLIBCXX_DEBUG-only >> code (but compiling without -D_GLIBCXX_DEBUG succeeded). > With that flag the container implementations are defined in namespace > __gnu_cxx1998, and std::map is supposed to refer to __gnu_debug::map. > But the debug map is declared in a header which isn't included by > <regex> since I replaced <map> with <bits/stl_map.h>. > > > >> Anyway, what would apparently fix it for me is >> >>> diff --git a/libstdc++-v3/include/std/regex b/libstdc++-v3/include/std/regex >>> index 04fb8b2d971..29fd2956fd0 100644 >>> --- a/libstdc++-v3/include/std/regex >>> +++ b/libstdc++-v3/include/std/regex >>> @@ -42,6 +42,11 @@ >>> #include <stdexcept> >>> #include <string> >>> >>> +#if defined _GLIBCXX_DEBUG >>> +#include <map> >>> +#include <vector> >>> +#endif >>> + > I think we can do this instead: > > --- a/libstdc++-v3/include/std/regex > +++ b/libstdc++-v3/include/std/regex > @@ -63,6 +63,11 @@ > #include <bits/regex.h> > #include <bits/regex_executor.h> > > +#ifdef _GLIBCXX_DEBUG > +# include <debug/map> > +# include <debug/vector> > +#endif > + > #if __cplusplus >= 201703L && _GLIBCXX_USE_CXX11_ABI > namespace std _GLIBCXX_VISIBILITY(default) > { > > > I'll test it, thanks for the report. > We are confident about the usage of those containers in the regex implementation, aren't we ? You can normally avoid the includes if you use for example _GLIBCXX_STD_C::map rather than std::map. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: trunk -D_GLIBCXX_DEBUG #include <regex> fails 2021-08-09 12:05 ` François Dumont @ 2021-08-09 14:27 ` Jonathan Wakely 2021-08-09 14:42 ` Jonathan Wakely 0 siblings, 1 reply; 7+ messages in thread From: Jonathan Wakely @ 2021-08-09 14:27 UTC (permalink / raw) To: François Dumont; +Cc: libstdc++ On Mon, 9 Aug 2021 at 13:05, François Dumont via Libstdc++ <libstdc++@gcc.gnu.org> wrote: > > On 09/08/21 12:05 pm, Jonathan Wakely via Libstdc++ wrote: > > On Mon, 9 Aug 2021 at 10:51, Stephan Bergmann via Libstdc++ > > <libstdc++@gcc.gnu.org> wrote: > >> Not sure why I started to experience this now with a recent > >> GCC/libstdc++ trunk build: > >> > >>> $ cat test.cc > >>> #include <regex> > >>> $ gcc/trunk/inst/bin/g++ -D_GLIBCXX_DEBUG -fsyntax-only test.cc > >>> In file included from /home/sbergman/gcc/trunk/inst/include/c++/12.0.0/bits/regex_automaton.h:401, > >>> from /home/sbergman/gcc/trunk/inst/include/c++/12.0.0/regex:60, > >>> from test.cc:1: > >>> /home/sbergman/gcc/trunk/inst/include/c++/12.0.0/bits/regex_automaton.tcc: In member function ‘std::__detail::_StateSeq<_TraitsT> std::__detail::_StateSeq<_TraitsT>::_M_clone()’: > >>> /home/sbergman/gcc/trunk/inst/include/c++/12.0.0/bits/regex_automaton.tcc:197:12: error: ‘map’ is not a member of ‘std’ > >>> 197 | std::map<_StateIdT, _StateIdT> __m; > >>> | ^~~ > >> [...] > >>> In file included from /home/sbergman/gcc/trunk/inst/include/c++/12.0.0/regex:62, > >>> from test.cc:1: > >>> /home/sbergman/gcc/trunk/inst/include/c++/12.0.0/bits/regex_compiler.h: At global scope: > >>> /home/sbergman/gcc/trunk/inst/include/c++/12.0.0/bits/regex_compiler.h:541:12: error: ‘vector’ in namespace ‘std’ does not name a template type > >>> 541 | std::vector<_CharT> _M_char_set; > >>> | ^~~~~~ > >> [...] > >> > >> where neither the use of std::map in bits/regex_automaton.tcc nor the > >> use of std::vector in bits/regex_compiler.h are in _GLIBCXX_DEBUG-only > >> code (but compiling without -D_GLIBCXX_DEBUG succeeded). > > With that flag the container implementations are defined in namespace > > __gnu_cxx1998, and std::map is supposed to refer to __gnu_debug::map. > > But the debug map is declared in a header which isn't included by > > <regex> since I replaced <map> with <bits/stl_map.h>. > > > > > > > >> Anyway, what would apparently fix it for me is > >> > >>> diff --git a/libstdc++-v3/include/std/regex b/libstdc++-v3/include/std/regex > >>> index 04fb8b2d971..29fd2956fd0 100644 > >>> --- a/libstdc++-v3/include/std/regex > >>> +++ b/libstdc++-v3/include/std/regex > >>> @@ -42,6 +42,11 @@ > >>> #include <stdexcept> > >>> #include <string> > >>> > >>> +#if defined _GLIBCXX_DEBUG > >>> +#include <map> > >>> +#include <vector> > >>> +#endif > >>> + > > I think we can do this instead: > > > > --- a/libstdc++-v3/include/std/regex > > +++ b/libstdc++-v3/include/std/regex > > @@ -63,6 +63,11 @@ > > #include <bits/regex.h> > > #include <bits/regex_executor.h> > > > > +#ifdef _GLIBCXX_DEBUG > > +# include <debug/map> > > +# include <debug/vector> > > +#endif > > + > > #if __cplusplus >= 201703L && _GLIBCXX_USE_CXX11_ABI > > namespace std _GLIBCXX_VISIBILITY(default) > > { > > > > > > I'll test it, thanks for the report. > > > We are confident about the usage of those containers in the regex > implementation, aren't we ? > > You can normally avoid the includes if you use for example > _GLIBCXX_STD_C::map rather than std::map. Yes, I have a patch to do that. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: trunk -D_GLIBCXX_DEBUG #include <regex> fails 2021-08-09 14:27 ` Jonathan Wakely @ 2021-08-09 14:42 ` Jonathan Wakely 2021-08-09 19:47 ` Jonathan Wakely 2021-08-10 7:24 ` Stephan Bergmann 0 siblings, 2 replies; 7+ messages in thread From: Jonathan Wakely @ 2021-08-09 14:42 UTC (permalink / raw) To: François Dumont; +Cc: libstdc++, gcc Patches [-- Attachment #1: Type: text/plain, Size: 3628 bytes --] On Mon, 9 Aug 2021 at 15:27, Jonathan Wakely wrote: > > On Mon, 9 Aug 2021 at 13:05, François Dumont via Libstdc++ > <libstdc++@gcc.gnu.org> wrote: > > > > On 09/08/21 12:05 pm, Jonathan Wakely via Libstdc++ wrote: > > > On Mon, 9 Aug 2021 at 10:51, Stephan Bergmann via Libstdc++ > > > <libstdc++@gcc.gnu.org> wrote: > > >> Not sure why I started to experience this now with a recent > > >> GCC/libstdc++ trunk build: > > >> > > >>> $ cat test.cc > > >>> #include <regex> > > >>> $ gcc/trunk/inst/bin/g++ -D_GLIBCXX_DEBUG -fsyntax-only test.cc > > >>> In file included from /home/sbergman/gcc/trunk/inst/include/c++/12.0.0/bits/regex_automaton.h:401, > > >>> from /home/sbergman/gcc/trunk/inst/include/c++/12.0.0/regex:60, > > >>> from test.cc:1: > > >>> /home/sbergman/gcc/trunk/inst/include/c++/12.0.0/bits/regex_automaton.tcc: In member function ‘std::__detail::_StateSeq<_TraitsT> std::__detail::_StateSeq<_TraitsT>::_M_clone()’: > > >>> /home/sbergman/gcc/trunk/inst/include/c++/12.0.0/bits/regex_automaton.tcc:197:12: error: ‘map’ is not a member of ‘std’ > > >>> 197 | std::map<_StateIdT, _StateIdT> __m; > > >>> | ^~~ > > >> [...] > > >>> In file included from /home/sbergman/gcc/trunk/inst/include/c++/12.0.0/regex:62, > > >>> from test.cc:1: > > >>> /home/sbergman/gcc/trunk/inst/include/c++/12.0.0/bits/regex_compiler.h: At global scope: > > >>> /home/sbergman/gcc/trunk/inst/include/c++/12.0.0/bits/regex_compiler.h:541:12: error: ‘vector’ in namespace ‘std’ does not name a template type > > >>> 541 | std::vector<_CharT> _M_char_set; > > >>> | ^~~~~~ > > >> [...] > > >> > > >> where neither the use of std::map in bits/regex_automaton.tcc nor the > > >> use of std::vector in bits/regex_compiler.h are in _GLIBCXX_DEBUG-only > > >> code (but compiling without -D_GLIBCXX_DEBUG succeeded). > > > With that flag the container implementations are defined in namespace > > > __gnu_cxx1998, and std::map is supposed to refer to __gnu_debug::map. > > > But the debug map is declared in a header which isn't included by > > > <regex> since I replaced <map> with <bits/stl_map.h>. > > > > > > > > > > > >> Anyway, what would apparently fix it for me is > > >> > > >>> diff --git a/libstdc++-v3/include/std/regex b/libstdc++-v3/include/std/regex > > >>> index 04fb8b2d971..29fd2956fd0 100644 > > >>> --- a/libstdc++-v3/include/std/regex > > >>> +++ b/libstdc++-v3/include/std/regex > > >>> @@ -42,6 +42,11 @@ > > >>> #include <stdexcept> > > >>> #include <string> > > >>> > > >>> +#if defined _GLIBCXX_DEBUG > > >>> +#include <map> > > >>> +#include <vector> > > >>> +#endif > > >>> + > > > I think we can do this instead: > > > > > > --- a/libstdc++-v3/include/std/regex > > > +++ b/libstdc++-v3/include/std/regex > > > @@ -63,6 +63,11 @@ > > > #include <bits/regex.h> > > > #include <bits/regex_executor.h> > > > > > > +#ifdef _GLIBCXX_DEBUG > > > +# include <debug/map> > > > +# include <debug/vector> > > > +#endif > > > + > > > #if __cplusplus >= 201703L && _GLIBCXX_USE_CXX11_ABI > > > namespace std _GLIBCXX_VISIBILITY(default) > > > { > > > > > > > > > I'll test it, thanks for the report. > > > > > We are confident about the usage of those containers in the regex > > implementation, aren't we ? > > > > You can normally avoid the includes if you use for example > > _GLIBCXX_STD_C::map rather than std::map. > > Yes, I have a patch to do that. This is what I'm testing. [-- Attachment #2: patch.txt --] [-- Type: text/plain, Size: 10842 bytes --] commit 28eae0a76a51bc39202a5f038e6327c640872fd2 Author: Jonathan Wakely <jwakely@redhat.com> Date: Mon Aug 9 11:49:09 2021 libstdc++: Include debug mode map and vector in <regex> The std::regex code uses std::map and std::vector, which means that when _GLIBCXX_DEBUG is defined it uses the debug versions of those containers. That no longer compiles, because I changed <regex> to include <bits/stl_map.h> and <bits/stl_vector.h> instead of <map> and <vector>, so the debug versions aren't defined, and std::map doesn't compile. Using std::map and std::vector is probably a mistake, and we should qualify them with _GLIBCXX_STD_C instead so that the debug versions aren't used. We do not need the overhead of checking our own uses of those containers, which should be correct anyway. The exception is the vector base class of std::match_results, which exposes iterators to users, so can benefit from debug mode checks for its iterators. For other accesses to the vector elements, match_results already does its own checks, so can access the _GLIBCXX_STD_C::vector base class directly. Signed-off-by: Jonathan Wakely <jwakely@redhat.com> libstdc++-v3/ChangeLog: * include/bits/regex.h (basic_regex::transform_primary): Use _GLIBCXX_STD_C::vector for local variable. * include/bits/regex.tcc (__regex_algo_impl): Use reference to _GLIBCXX_STD_C::vector base class of match_results. * include/bits/regex_automaton.tcc (_StateSeq:_M_clone): Use _GLIBCXX_STD_C::map and _GLIBCXX_STD_C::deque for local variables. * include/bits/regex_compiler.h (_BracketMatcher): Use _GLIBCXX_STD_C::vector for data members. * include/bits/regex_executor.h (_Executor): Likewise. * include/std/regex [_GLIBCXX_DEBUG]: Include <debug/vector>. diff --git a/libstdc++-v3/include/bits/regex.h b/libstdc++-v3/include/bits/regex.h index ac10fa184c6..b8a0ad251d8 100644 --- a/libstdc++-v3/include/bits/regex.h +++ b/libstdc++-v3/include/bits/regex.h @@ -257,7 +257,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11 // for details. typedef std::ctype<char_type> __ctype_type; const __ctype_type& __fctyp(use_facet<__ctype_type>(_M_locale)); - std::vector<char_type> __s(__first, __last); + _GLIBCXX_STD_C::vector<char_type> __s(__first, __last); __fctyp.tolower(__s.data(), __s.data() + __s.size()); return this->transform(__s.data(), __s.data() + __s.size()); } @@ -1697,6 +1697,8 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11 * [n+3] suffix */ typedef std::vector<sub_match<_Bi_iter>, _Alloc> _Base_type; + // In debug mode _Base_type is the debug vector, this is the unsafe one: + typedef _GLIBCXX_STD_C::vector<sub_match<_Bi_iter>, _Alloc> _Unchecked; typedef std::iterator_traits<_Bi_iter> __iter_traits; typedef regex_constants::match_flag_type match_flag_type; @@ -1773,7 +1775,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11 * @retval true The object has a fully-established result state. * @retval false The object is not ready. */ - bool ready() const noexcept { return !_Base_type::empty(); } + bool ready() const noexcept { return !_Unchecked::empty(); } /** * @name 28.10.2 Size @@ -1791,11 +1793,11 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11 */ size_type size() const noexcept - { return _Base_type::empty() ? 0 : _Base_type::size() - 3; } + { return _Unchecked::empty() ? 0 : _Unchecked::size() - 3; } size_type max_size() const noexcept - { return _Base_type::max_size() - 3; } + { return _Unchecked::max_size() - 3; } /** * @brief Indicates if the %match_results contains no results. @@ -1869,7 +1871,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11 { __glibcxx_assert( ready() ); return __sub < size() - ? _Base_type::operator[](__sub) + ? _Unchecked::operator[](__sub) : _M_unmatched_sub(); } @@ -2045,7 +2047,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11 // (plus additional objects for prefix, suffix and unmatched sub). void _M_resize(unsigned int __size) - { _Base_type::assign(__size + 3, sub_match<_Bi_iter>{}); } + { _Unchecked::assign(__size + 3, sub_match<_Bi_iter>{}); } // Set state to a failed match for the given past-the-end iterator. void @@ -2053,32 +2055,32 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11 { sub_match<_Bi_iter> __sm; __sm.first = __sm.second = __end; - _Base_type::assign(3, __sm); + _Unchecked::assign(3, __sm); } const_reference _M_unmatched_sub() const - { return _Base_type::operator[](_Base_type::size() - 3); } + { return _Unchecked::operator[](_Unchecked::size() - 3); } sub_match<_Bi_iter>& _M_unmatched_sub() - { return _Base_type::operator[](_Base_type::size() - 3); } + { return _Unchecked::operator[](_Unchecked::size() - 3); } const_reference _M_prefix() const - { return _Base_type::operator[](_Base_type::size() - 2); } + { return _Unchecked::operator[](_Unchecked::size() - 2); } sub_match<_Bi_iter>& _M_prefix() - { return _Base_type::operator[](_Base_type::size() - 2); } + { return _Unchecked::operator[](_Unchecked::size() - 2); } const_reference _M_suffix() const - { return _Base_type::operator[](_Base_type::size() - 1); } + { return _Unchecked::operator[](_Unchecked::size() - 1); } sub_match<_Bi_iter>& _M_suffix() - { return _Base_type::operator[](_Base_type::size() - 1); } + { return _Unchecked::operator[](_Unchecked::size() - 1); } _Bi_iter _M_begin; /// @endcond diff --git a/libstdc++-v3/include/bits/regex.tcc b/libstdc++-v3/include/bits/regex.tcc index 39ad3f0a4cc..c8bdd377c18 100644 --- a/libstdc++-v3/include/bits/regex.tcc +++ b/libstdc++-v3/include/bits/regex.tcc @@ -56,7 +56,7 @@ namespace __detail if (__re._M_automaton == nullptr) return false; - typename match_results<_BiIter, _Alloc>::_Base_type& __res = __m; + typename match_results<_BiIter, _Alloc>::_Unchecked& __res = __m; __m._M_begin = __s; __m._M_resize(__re._M_automaton->_M_sub_count()); @@ -66,7 +66,7 @@ namespace __detail && !__re._M_automaton->_M_has_backref)) { _Executor<_BiIter, _Alloc, _TraitsT, false> - __executor(__s, __e, __m, __re, __flags); + __executor(__s, __e, __res, __re, __flags); if (__match_mode) __ret = __executor._M_match(); else @@ -75,7 +75,7 @@ namespace __detail else { _Executor<_BiIter, _Alloc, _TraitsT, true> - __executor(__s, __e, __m, __re, __flags); + __executor(__s, __e, __res, __re, __flags); if (__match_mode) __ret = __executor._M_match(); else diff --git a/libstdc++-v3/include/bits/regex_automaton.tcc b/libstdc++-v3/include/bits/regex_automaton.tcc index 0977f778922..69f3ee5ba3c 100644 --- a/libstdc++-v3/include/bits/regex_automaton.tcc +++ b/libstdc++-v3/include/bits/regex_automaton.tcc @@ -194,8 +194,8 @@ namespace __detail _StateSeq<_TraitsT> _StateSeq<_TraitsT>::_M_clone() { - std::map<_StateIdT, _StateIdT> __m; - std::stack<_StateIdT> __stack; + _GLIBCXX_STD_C::map<_StateIdT, _StateIdT> __m; + std::stack<_StateIdT, _GLIBCXX_STD_C::deque<_StateIdT>> __stack; __stack.push(_M_start); while (!__stack.empty()) { diff --git a/libstdc++-v3/include/bits/regex_compiler.h b/libstdc++-v3/include/bits/regex_compiler.h index bf7dcc54dba..5b4f2ae3558 100644 --- a/libstdc++-v3/include/bits/regex_compiler.h +++ b/libstdc++-v3/include/bits/regex_compiler.h @@ -538,10 +538,10 @@ namespace __detail { } private: - std::vector<_CharT> _M_char_set; - std::vector<_StringT> _M_equiv_set; - std::vector<pair<_StrTransT, _StrTransT>> _M_range_set; - std::vector<_CharClassT> _M_neg_class_set; + _GLIBCXX_STD_C::vector<_CharT> _M_char_set; + _GLIBCXX_STD_C::vector<_StringT> _M_equiv_set; + _GLIBCXX_STD_C::vector<pair<_StrTransT, _StrTransT>> _M_range_set; + _GLIBCXX_STD_C::vector<_CharClassT> _M_neg_class_set; _CharClassT _M_class_set; _TransT _M_translator; const _TraitsT& _M_traits; diff --git a/libstdc++-v3/include/bits/regex_executor.h b/libstdc++-v3/include/bits/regex_executor.h index 014b4e83064..3422893371a 100644 --- a/libstdc++-v3/include/bits/regex_executor.h +++ b/libstdc++-v3/include/bits/regex_executor.h @@ -60,7 +60,7 @@ namespace __detail public: typedef typename iterator_traits<_BiIter>::value_type _CharT; typedef basic_regex<_CharT, _TraitsT> _RegexT; - typedef std::vector<sub_match<_BiIter>, _Alloc> _ResultsVec; + typedef _GLIBCXX_STD_C::vector<sub_match<_BiIter>, _Alloc> _ResultsVec; typedef regex_constants::match_flag_type _FlagT; typedef typename _TraitsT::char_class_type _ClassT; typedef _NFA<_TraitsT> _NFAT; @@ -215,7 +215,7 @@ namespace __detail _BiIter* _M_get_sol_pos() { return nullptr; } // Saves states that need to be considered for the next character. - vector<pair<_StateIdT, _ResultsVec>> _M_match_queue; + _GLIBCXX_STD_C::vector<pair<_StateIdT, _ResultsVec>> _M_match_queue; // Indicates which states are already visited. bool* _M_visited_states; // To record current solution. @@ -248,7 +248,7 @@ namespace __detail const _RegexT& _M_re; const _NFAT& _M_nfa; _ResultsVec& _M_results; - vector<pair<_BiIter, int>> _M_rep_count; + _GLIBCXX_STD_C::vector<pair<_BiIter, int>> _M_rep_count; _State_info<__search_mode, _ResultsVec> _M_states; _FlagT _M_flags; // Do we have a solution so far? diff --git a/libstdc++-v3/include/std/regex b/libstdc++-v3/include/std/regex index 04fb8b2d971..2c94fa306c2 100644 --- a/libstdc++-v3/include/std/regex +++ b/libstdc++-v3/include/std/regex @@ -55,6 +55,9 @@ #include <bits/stl_vector.h> #include <bits/stl_bvector.h> #include <bits/vector.tcc> +#ifdef _GLIBCXX_DEBUG +# include <debug/vector> +#endif #include <bits/regex_constants.h> #include <bits/regex_error.h> #include <bits/regex_automaton.h> ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: trunk -D_GLIBCXX_DEBUG #include <regex> fails 2021-08-09 14:42 ` Jonathan Wakely @ 2021-08-09 19:47 ` Jonathan Wakely 2021-08-10 7:24 ` Stephan Bergmann 1 sibling, 0 replies; 7+ messages in thread From: Jonathan Wakely @ 2021-08-09 19:47 UTC (permalink / raw) To: François Dumont; +Cc: libstdc++, gcc Patches On Mon, 9 Aug 2021 at 15:42, Jonathan Wakely <jwakely@redhat.com> wrote: > > On Mon, 9 Aug 2021 at 15:27, Jonathan Wakely wrote: > > > > On Mon, 9 Aug 2021 at 13:05, François Dumont via Libstdc++ > > <libstdc++@gcc.gnu.org> wrote: > > > > > > On 09/08/21 12:05 pm, Jonathan Wakely via Libstdc++ wrote: > > > > On Mon, 9 Aug 2021 at 10:51, Stephan Bergmann via Libstdc++ > > > > <libstdc++@gcc.gnu.org> wrote: > > > >> Not sure why I started to experience this now with a recent > > > >> GCC/libstdc++ trunk build: > > > >> > > > >>> $ cat test.cc > > > >>> #include <regex> > > > >>> $ gcc/trunk/inst/bin/g++ -D_GLIBCXX_DEBUG -fsyntax-only test.cc > > > >>> In file included from /home/sbergman/gcc/trunk/inst/include/c++/12.0.0/bits/regex_automaton.h:401, > > > >>> from /home/sbergman/gcc/trunk/inst/include/c++/12.0.0/regex:60, > > > >>> from test.cc:1: > > > >>> /home/sbergman/gcc/trunk/inst/include/c++/12.0.0/bits/regex_automaton.tcc: In member function ‘std::__detail::_StateSeq<_TraitsT> std::__detail::_StateSeq<_TraitsT>::_M_clone()’: > > > >>> /home/sbergman/gcc/trunk/inst/include/c++/12.0.0/bits/regex_automaton.tcc:197:12: error: ‘map’ is not a member of ‘std’ > > > >>> 197 | std::map<_StateIdT, _StateIdT> __m; > > > >>> | ^~~ > > > >> [...] > > > >>> In file included from /home/sbergman/gcc/trunk/inst/include/c++/12.0.0/regex:62, > > > >>> from test.cc:1: > > > >>> /home/sbergman/gcc/trunk/inst/include/c++/12.0.0/bits/regex_compiler.h: At global scope: > > > >>> /home/sbergman/gcc/trunk/inst/include/c++/12.0.0/bits/regex_compiler.h:541:12: error: ‘vector’ in namespace ‘std’ does not name a template type > > > >>> 541 | std::vector<_CharT> _M_char_set; > > > >>> | ^~~~~~ > > > >> [...] > > > >> > > > >> where neither the use of std::map in bits/regex_automaton.tcc nor the > > > >> use of std::vector in bits/regex_compiler.h are in _GLIBCXX_DEBUG-only > > > >> code (but compiling without -D_GLIBCXX_DEBUG succeeded). > > > > With that flag the container implementations are defined in namespace > > > > __gnu_cxx1998, and std::map is supposed to refer to __gnu_debug::map. > > > > But the debug map is declared in a header which isn't included by > > > > <regex> since I replaced <map> with <bits/stl_map.h>. > > > > > > > > > > > > > > > >> Anyway, what would apparently fix it for me is > > > >> > > > >>> diff --git a/libstdc++-v3/include/std/regex b/libstdc++-v3/include/std/regex > > > >>> index 04fb8b2d971..29fd2956fd0 100644 > > > >>> --- a/libstdc++-v3/include/std/regex > > > >>> +++ b/libstdc++-v3/include/std/regex > > > >>> @@ -42,6 +42,11 @@ > > > >>> #include <stdexcept> > > > >>> #include <string> > > > >>> > > > >>> +#if defined _GLIBCXX_DEBUG > > > >>> +#include <map> > > > >>> +#include <vector> > > > >>> +#endif > > > >>> + > > > > I think we can do this instead: > > > > > > > > --- a/libstdc++-v3/include/std/regex > > > > +++ b/libstdc++-v3/include/std/regex > > > > @@ -63,6 +63,11 @@ > > > > #include <bits/regex.h> > > > > #include <bits/regex_executor.h> > > > > > > > > +#ifdef _GLIBCXX_DEBUG > > > > +# include <debug/map> > > > > +# include <debug/vector> > > > > +#endif > > > > + > > > > #if __cplusplus >= 201703L && _GLIBCXX_USE_CXX11_ABI > > > > namespace std _GLIBCXX_VISIBILITY(default) > > > > { > > > > > > > > > > > > I'll test it, thanks for the report. > > > > > > > We are confident about the usage of those containers in the regex > > > implementation, aren't we ? > > > > > > You can normally avoid the includes if you use for example > > > _GLIBCXX_STD_C::map rather than std::map. > > > > Yes, I have a patch to do that. > > This is what I'm testing. Pushed to trunk now. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: trunk -D_GLIBCXX_DEBUG #include <regex> fails 2021-08-09 14:42 ` Jonathan Wakely 2021-08-09 19:47 ` Jonathan Wakely @ 2021-08-10 7:24 ` Stephan Bergmann 1 sibling, 0 replies; 7+ messages in thread From: Stephan Bergmann @ 2021-08-10 7:24 UTC (permalink / raw) To: Jonathan Wakely; +Cc: libstdc++, gcc Patches On 09/08/2021 16:42, Jonathan Wakely via Gcc-patches wrote: > This is what I'm testing. Thanks, that worked fine for my build of LibreOffice. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-08-10 7:24 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-08-09 9:50 trunk -D_GLIBCXX_DEBUG #include <regex> fails Stephan Bergmann 2021-08-09 10:05 ` Jonathan Wakely 2021-08-09 12:05 ` François Dumont 2021-08-09 14:27 ` Jonathan Wakely 2021-08-09 14:42 ` Jonathan Wakely 2021-08-09 19:47 ` Jonathan Wakely 2021-08-10 7:24 ` Stephan Bergmann
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).