* 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).