https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88947
--- Comment #7 from Tomalak Geret'kal ---
(In reply to Tim Shen from comment #5)
> For the original test case, have you tried regex_match() with "what.*"?
That behaves as I'd expect
(http://quick-bench.com/AKdMnnhA03T1vwfN9sf53xlbD6s).
> Do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88947
--- Comment #6 from Tim Shen ---
(In reply to Tomalak Geret'kal from comment #4)
> To be honest I'd expect this in less trivial circumstances too. If, at a
> given stage of processing, the only possible paths towards a match all
> require a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88947
--- Comment #5 from Tim Shen ---
(In reply to Tomalak Geret'kal from comment #4)
> To be honest I'd expect this in less trivial circumstances too. If, at a
> given stage of processing, the only possible paths towards a match all
> require a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88947
--- Comment #4 from Tomalak Geret'kal ---
To be honest I'd expect this in less trivial circumstances too. If, at a given
stage of processing, the only possible paths towards a match all require a
prefix that's already been ruled out, that should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88947
--- Comment #3 from Tim Shen ---
Thanks for reporting Tomalak.
Yes, I agree that "match from the first character" should be expressable in the
public interface, preferrably regex_search() with "^...". In fact, internally
regex_search is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88947
Jonathan Wakely changed:
What|Removed |Added
Keywords||missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88947
--- Comment #1 from Jonathan Wakely ---
(In reply to Tomalak Geret'kal from comment #0)
> (Apologies that I am not sufficiently familiar with libstdc++ version
> history to select an appropriate version number for this bug.)
Libstdc++ doesn't
