Re: [Patch] Regex bracket matcher cache optimization

ementation may change (say add a new executor) later. Is that Ok? -- Regards, Tim Shen commit d9f47e783680a1cab86bd704e67236025cbdff18 Author: tim Date: Mon Jan 6 00:03:41 2014 -0500 2014-01-08 Tim Shen * bits/regex_automaton.tcc: Indentation fix. * bits/re

Re: [Patch] Regex bracket matcher cache optimization

l it definitely makes > sense, for compile-time performance too. I think we already said that some > time ago, but the issue seems more important now. Maybe it's really > unavoidable if we need template complexity for first class run-time > performance. After this patch I plan to instantiate _Compiler and _Executor. -- Regards, Tim Shen

Re: [Patch] Regex bracket matcher cache optimization

oticed that's so time consuming. I think reducing the compile time is possible (by templating several member functions instead of whole _Compiler<> class). -- Regards, Tim Shen Index: include/std/regex === --- include

Re: [Patch] Regex bracket matcher cache optimization

compile, mainly because now we have 4 times more _Compiler<> versions :) Booted and tested with -m32 and -m64 respectively. Thank you! -- Regards, Tim Shen commit 9dcc87dd782c7a09b5e075e746ceb3d0c6f1f4db Author: tim Date: Mon Jan 6 00:03:41 2014 -0500 2014-01-07 Tim Shen

Re: [Patch] Regex bracket matcher cache optimization

On Fri, Jan 3, 2014 at 9:35 PM, Tim Shen wrote: > The data structure _BracketMatcher (storing regex like [123a-z]) could > be quite slow mainly because of regex_traits. So a result of cache for > small range of inputs (char) sounds reasonable. It iterates all 256 > inputs and calcu

Re: [Patch] Regex bracket matcher cache optimization

92r 191u 0s0mem0pf After: split.cc14r 14u 0s0mem0pf split_bfs.cc78r 77u 0s0mem0pf The cache obviously works. -- Regards, Tim Shen

[Patch] Regex bracket matcher cache optimization

. Thanks! -- Regards, Tim Shen commit de1e43989be9c9dffebf488e118549cfe2987b9e Author: tim Date: Fri Jan 3 11:43:12 2014 -0500 2014-01-03 Tim Shen * include/bits/regex_compiler.h (_AnyMatcher<>::_AnyMatcher(), _AnyMatcher<>::operator(), _AnyMatcher

Re: [Patch] Add comments for future regex work

ns while in Stage 4. ...committed. -- Regards, Tim Shen

[Patch] Add comments for future regex work

...for optimization purpose. Should be done in one month. Thanks! -- Regards, Tim Shen commit cc7d58128e68455498d0257c4796cb70a9e24990 Author: tim Date: Mon Dec 2 15:49:15 2013 -0500 2013-12-02 Tim Shen * regex_compiler.h: Add todo comment. * regex_executor.tcc

Re: [v3 patch] Fix spelling in regex headers

On Wed, Nov 6, 2013 at 4:47 AM, Jonathan Wakely wrote: > This simply fixes s/boundry/boundary/, which I wanted to do first > before some more regex refactoring I'm planning. Thanks a lot Jonathan! -- Regards, Tim Shen

Re: [Patch] Regex comments

On Sun, Oct 27, 2013 at 9:26 PM, Jonathan Wakely wrote: > I'm happy for that latest patch to be committed, thanks for taking the > time to improve the comments. Committed. Thanks! -- Regards, Tim Shen

Re: [Patch] Regex comments

+// mean the same thing, and we need to choose the correct order under +// given greedy mode. -- Regards, Tim Shen commit b195603ee8d79d2afd5303bcae363c47e4c89fab Author: tim Date: Sun Oct 27 15:50:44 2013 -0400 2013-10-28 Tim Shen * regex_executor.tcc: Add comments. diff

Re: [Patch] Regex comments

the switch statement, where it should stay. -- Regards, Tim Shen commit 1f13761ba34b13a52b4f41d2ebdeba1114205bac Author: tim Date: Sun Oct 27 15:50:44 2013 -0400 2013-10-27 Tim Shen * regex_executor.tcc: Add comments. diff --git a/libstdc++-v3/include/bits/regex_executor.tcc

[Patch] Regex comments

Add comments for last regex commit. Thanks! -- Regards, Tim Shen commit b4aa16a08992866ca6fd60f40e422f551d0d6b2a Author: tim Date: Sun Oct 27 15:50:44 2013 -0400 2013- diff --git a/libstdc++-v3/include/bits/regex_executor.tcc b/libstdc++-v3/include/bits/regex_executor.tcc index

Re: [Patch] Change default executor to DFS in regex

On Sun, Oct 20, 2013 at 4:42 AM, Paolo Carlini wrote: > Ok with those changes. Committed. Thanks! -- Tim Shen a.patch Description: Binary data

Re: [Patch] Change default executor to DFS in regex

l_deque.h example. I can't > imagine any other simple (and conforming! eg, no additional template parms) > solution. I see. Here's the macro version. Thanks! -- Tim Shen a.patch Description: Binary data

Re: [Patch] Change default executor to DFS in regex

cases? Before we freeze the > next ABI we should keep open all the possibilities... It'll be great help to implement partial DFA compilation for all cases, though DFA cannot handle back-references neither. I need more time to investigate. Thanks! -- Tim Shen a.patch Description: Binary data

Re: [Patch] Change default executor to DFS in regex

On Fri, Oct 18, 2013 at 9:13 PM, Tim Shen wrote: > As the comment in this patch said, DFS approach is faster in simple > regex, but exponentially slower in complex(many quantifier) cases. Actually I suggest to use DFS where number of quantifiers < 2, to make this 'optimization'

[Patch] Change default executor to DFS in regex

As the comment in this patch said, DFS approach is faster in simple regex, but exponentially slower in complex(many quantifier) cases. DFA optimization could be added, but I'm afraid it needs rewriting regex_automaton.*. Tested under -m32 and -m64. Thanks! -- Tim Shen a.patch Descri

Re: [Patch] Fix wide char locale support(like CJK charset) in regex

and committed. By the way, UTF-8 *encoding* is a more accurate word, instead of `charset`(which is Unicode). -- Tim Shen

Re: [Patch] Fix wide char locale support(like CJK charset) in regex

nder UTF-8 charset. Now it's hex format. I also make the char handling simpler. -- Tim Shen a.patch Description: Binary data

[Patch] Fix wide char locale support(like CJK charset) in regex

The bug is because naively calling `map::count(__c)` where __c could be a wchar_t, and an implicit cast(a truncate?) happened. -m32 and -m64 tested. Thanks! -- Tim Shen a.patch Description: Binary data

Re: [Patch] Fix warnings in regex

On Thu, Oct 17, 2013 at 3:58 PM, Paolo Carlini wrote: > Please explain in the ChangeLog *which* warnings. Committed with attached patch. Thanks! -- Tim Shen a.patch Description: Binary data

Re: [Patch] Fix undefined behaviors in regex

nd it weird. That's my fault, I forgot that compiling code included from libstdc++ doesn't generate warnings. Then I try to get all warnings, and indeed get the missing-return-statement one. Thanks! -- Tim Shen

[Patch] Fix warnings in regex

...to prevent potential bugs. By the way, I execute `g++ -E file.cc > prep.cc && sed -i 's|^#.*$||' prep.cc && g++ -Wall prep.cc 2> log` to get all warnings. Do we have a better way? Bootstraps and tested under -m64 and -m32. Thanks! -- Tim Shen a.patch Description: Binary data

Re: [Patch] Fix undefined behaviors in regex

On Wed, Oct 16, 2013 at 6:42 PM, Paolo Carlini wrote: > On 10/17/2013 12:39 AM, Tim Shen wrote: >> >> On Wed, Oct 16, 2013 at 6:33 PM, Paolo Carlini >> wrote: >>> >>> By the way, please feel free to prepare a reduced testcase for the >>> -f

Re: [Patch] Fix undefined behaviors in regex

On Wed, Oct 16, 2013 at 6:33 PM, Paolo Carlini wrote: > By the way, please feel free to prepare a reduced testcase for the > -fsanitize people (Marek, Jakub?) Here it is. And we should get undefined behaviors before this commit(r203732). -- Tim Shen split.cc Description: Binary data

Re: [Patch] Fix undefined behaviors in regex

On Wed, Oct 16, 2013 at 6:13 PM, Paolo Carlini wrote: > Thank you! Committed. Thanks! -- Tim Shen

[Patch] Fix undefined behaviors in regex

It's detected by `clang++ -g -std=c++11 -fsanitize=undefined` but not detected by g++ with flags `g++ -g -std=c++11 -fsanitize=undefined -lpthread`. Am I on the right way? -m32 and -m64 tested :) Thanks! -- Tim Shen a.patch Description: Binary data

Re: [Patch] Fix PR58737

On Tue, Oct 15, 2013 at 11:01 AM, Jonathan Wakely wrote: > Great, if it passes the testsuite please commit it. It surely passed -m32 and -m64, and committed :) -- Tim Shen

[Patch] Fix PR58737

This memory leak is because forgetting virtual destructor of the base class _Executor. Thanks! -- Tim Shen a.patch Description: Binary data

Re: [Patch] Optimize _BFSExecutor in regex

On Mon, Oct 7, 2013 at 8:43 PM, Jonathan Wakely wrote: > OK, this latest patch looks good so please go ahead and commit it - thanks! Committed :) -- Tim Shen

Re: [Patch] Optimize _BFSExecutor in regex

eep the assign(), because the ratio in regex could probably be more than 25%. -- Tim Shen a.patch Description: Binary data

Re: [Patch] Optimize _BFSExecutor in regex

cost almost same time. When push more than that, v.assign() shall win. I do this because I need to use _M_clear() in this patch :) Anyway let's use v.assign(). Thanks! -- Tim Shen a.patch Description: Binary data

Re: [Patch] Optimize _BFSExecutor in regex

On Mon, Oct 7, 2013 at 1:40 PM, Tim Shen wrote: > while (!this->empty()) > this->pop(); Sorry it's this->_M_empty() and this->_M_pop(); -- Tim Shen

Re: [Patch] Optimize _BFSExecutor in regex

gt;empty()) this->pop(); ...will be executed only 3 times. I think it's cheaper than copying a long-enough and sparse-enough byte chunk? Or at least we should theck the density(_M_base.size() / _M_exists.size()) of _M_exists ? -- Tim Shen

Re: [Patch] Optimize _BFSExecutor in regex

On Mon, Oct 7, 2013 at 7:12 AM, Jonathan Wakely wrote: > On 6 October 2013 23:43, Tim Shen wrote: >> Here's a simple piece of code >> https://gist.github.com/innocentim/6849759 the reveals _BFSExecutor's >> inefficiency. Some optimizations are here to reduce the une

Re: [Patch] Optimize _BFSExecutor in regex

ing these 3 elements to false, rather than reseting the whole vector. Is this called "pay for what you get"? The ideal solution could be: void _M_clear() { if (__exists.size() < _BaseT::size() * CPU_WORD_LENGTH * some_factor) clear_one_by_one(); else reset_them_al

Re: [Patch] Optimize _BFSExecutor in regex

it's guaranteed that __exists[__u] is always in range, right? Of course. Otherwise vector's range checker will help, right? ------- Jonathan On 7 October 2013 14:31, Tim Shen wrote: > On Oct 7, 2013 7:12 AM,

[Patch] Optimize _BFSExecutor in regex

Here's a simple piece of code https://gist.github.com/innocentim/6849759 the reveals _BFSExecutor's inefficiency. Some optimizations are here to reduce the unecessary time complexity from O(n^2) to O(n). I'll do a bootstrap and full testing before committing. Thanks! -- Tim

Re: [Patch] Internal functions for testsuite in regex

On Sat, Oct 5, 2013 at 7:45 AM, Paolo Carlini wrote: > Patch looks great to me. If you don't get more comments over the next day or > so, please go ahead. Committed :) -- Tim Shen

Re: [Patch] Fix COMPILE error in regex and remove default parameter in function definition

On Sun, Oct 6, 2013 at 5:38 AM, Paolo Carlini wrote: > Ok, thanks. Committed :) -- Tim Shen

[Patch] Fix COMPILE error in regex and remove default parameter in function definition

Stupid errors hidden in some large commit. I don't think they will break boostrap? Thanks! -- Tim Shen a.patch Description: Binary data

Re: [Patch] Fix wrong backup variable initialization in regex

g > facility, > but I'm thinking that we should not. Yes I think we should keep secret, because the standard doesn't specify it. They only way to publish the switch to user is making a library extension(is that true?), but there's no obvious benefit to do that(is that true? I shall be humble). -- Tim Shen

Re: [Patch] Fix wrong backup variable initialization in regex

e non-defuault matcher every 2-3 commits. Do we have a better solution? Thanks! -- Tim Shen

[Patch] Fix wrong backup variable initialization in regex

Tested under -m32, -m64, however didn't do a bootstrap. Is that OK? Thanks! -- Tim Shen a.patch Description: Binary data

Re: [wwwdocs] Mention libstdc++-v3 in 4.9 changes.html

Committed. Thanks! On Wed, Oct 2, 2013 at 11:12 AM, Jonathan Wakely wrote: > On 2 October 2013 15:52, Tim Shen wrote: >> I feel little bit uncomfortable with "new ISO C++ standard, C++11", >> since C++14 is already there, so I removed it. > > Good idea. >

Re: [Patch] Fix incorrect behavior of "[[=a=]]" in regex

Committed. Thanks! On Wed, Oct 2, 2013 at 11:10 AM, Jonathan Wakely wrote: > On 2 October 2013 15:26, Tim Shen wrote: >> _BracketMatcher<>::_M_add_equivalence_class is misimplemented so I try >> `git blame regex_compiler.h`...that's me! >> >> Booted and t

Re: [wwwdocs] Mention libstdc++-v3 in 4.9 changes.html

Improved support for C++11, including support for <regex>. > -- Tim Shen

[Patch] Fix incorrect behavior of "[[=a=]]" in regex

_BracketMatcher<>::_M_add_equivalence_class is misimplemented so I try `git blame regex_compiler.h`...that's me! Booted and tested under -m32, -m64. Thanks ;) -- Tim Shen a.patch Description: Binary data

[wwwdocs] Mention libstdc++-v3 in 4.9 changes.html

retrieving revision 1.27 diff -r1.27 changes.html 136a137,140 > href="http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2011";> >Improved experimental support for the new ISO C++ standard, C++11, >including support for <regex>. > -- Tim Shen

Re: Announcing ?

ork', up to you, but > please adjust it. Committed. I learn that an implementation could be incorrect ;) -- Tim Shen a.patch Description: Binary data

Re: Announcing ?

> provide what we need in the public interface (if I understand the issue): > just say that implementing the function appears to require libc support + a > link to the message you sent a couple of weeks ago to the libstdc++-v3 > mailing list. > > Ok with the above changes.

Re: Announcing ?

from , described by [28.7.7]. More detailed, http://www.open-std.org/Jtc1/sc22/wg21/docs/papers/2003/n1429.htm offered what the function means. -- Tim Shen

Re: Announcing ?

On Mon, Sep 30, 2013 at 2:25 PM, Paolo Carlini wrote: > 3- Tweak the implementation status page > libstdc++/doc/xml/manual/status_cxx2011.xml (possibly clarify bits still > missing too) Here is the patch for this, along with some interface fixes. Thank you! -- Tim Shen a.patch De

Re: [Patch] Fix interval quantifier in lookahead subexpr in regex

On Tue, Oct 1, 2013 at 1:32 AM, Paolo Carlini wrote: > Ok, thanks. Committed. Thanks! -- Tim Shen

[Patch] Fix interval quantifier in lookahead subexpr in regex

Forget to let _M_clone and _M_eliminate_dummy follow _S_opcode_subexpr_lookahead, which also have _M_alt. Is it OK not to bootstrap it ? Tested under -m64 and -m32. Thanks! -- Tim Shen a.patch Description: Binary data

Re: [Patch] Let ordinary escaping in POSIX regex be valid

On Fri, Sep 27, 2013 at 4:30 PM, Paolo Carlini wrote: > Nah, only double check that the testcase you are un-xfail-ing uses > -std=gnu++11, otherwise will not pass ;) Committed :) Thanks! -- Tim Shen

Re: [Patch] Let ordinary escaping in POSIX regex be valid

gt; else > { > #ifdef __STRICT_ANSI__ > __throw_regex_error(regex_constants::error_escape); > #else >_M_token = _S_token_ord_char; >_M_value.assign(1, __c); > #endif > } Sorry for late >.< Do I need to bootstrap again? -- Tim Shen a.patch Description: Binary data

[Patch] Let ordinary escaping in POSIX regex be valid

o let's support it not to make users surprised. Booted and tested under -m32 and -m64 Thanks! -- Tim Shen a.patch Description: Binary data

Re: [Patch] Regex Fixes on constants and no-backref in extended

On Thu, Sep 26, 2013 at 5:37 PM, Jonathan Wakely wrote: > The ChangeLog entry says "stanard", with that fixed this is OK to > commit, thanks! Committed. -- Tim Shen

[Patch] Regex Fixes on constants and no-backref in extended

Just follow the standard :) Booted and tested under -m32, -m64. Thank you! -- Tim Shen a.patch Description: Binary data

Re: [Patch] match_results::format and regex_replace

On Sun, Sep 22, 2013 at 4:20 PM, Paolo Carlini wrote: > If testing goes well patch is Ok to commit. Tested under -m32 and -m64 and committed :) I'll learn how locale in glibc works. Thank you all! -- Tim Shen

[Patch] match_results::format and regex_replace

x27;t specify it? Tested under -m64. I'll do a full test before committing. Thanks! -- Tim Shen a.patch Description: Binary data

Re: [Patch] Implement regex_match and regex_search

On Tue, Sep 17, 2013 at 4:35 AM, Paolo Carlini wrote: > Great. Tim, please complete the testing on -m32 etc, if everything goes > well, just wait a day or so and commit. Tested under -m32, -m64 and check-debug, and committed, with changing the date of the new file to today. Thank you! -

Re: [Patch] Support assertions and greedy/ungreedy matching in regex

actually not a big fan of regex(but of NFA ;), or can I borrow some boost/libc++ testcases without making any licence trouble? Thanks! -- Tim Shen

Re: [Patch] Support assertions and greedy/ungreedy matching in regex

an AST-based formatter? Clang seems to write a good one. -- Tim Shen

Re: [Patch] Rewrite _StateSeq in regex

On Thu, Sep 5, 2013 at 10:07 AM, Paolo Carlini wrote: > On 09/04/2013 05:37 AM, Tim Shen wrote: > Thanks. Apparently there aren't further comments, thus please install it. Committed. Complete unmatched parentheses in last commit :) -- Tim Shen

Re: [Patch] Rewrite _StateSeq in regex

According to this email(http://gcc.gnu.org/ml/libstdc++/2013-09/msg5.html), I add a testcase. -- Tim Shen stateseq.patch Description: Binary data

[Patch] Rewrite _StateSeq in regex

ted before committing. Thanks! -- Tim Shen stateseq.patch Description: Binary data

Re: [Patch] Rewrite regex matchers

On Fri, Aug 30, 2013 at 10:04 PM, Tim Shen wrote: > I didn't use any tool to check that, but adjust it by hand. It > shouldn't break anything, but I'll test it again before committing. Tested under -m32, -m64 and debug mode and committed. -- Tim Shen

Re: [Patch] Rewrite regex matchers

On Fri, Aug 30, 2013 at 9:26 AM, Paolo Carlini wrote: > Hi, > > On 08/30/2013 02:05 PM, Tim Shen wrote: >> >> + const _TraitsT&_M_traits; >> + _FlagT _M_flags; >> + bool

[Patch] Rewrite regex matchers

Rewrite matchers using structs instead of closures. It's more clear and easy to maintain now. Tested under -m32, -m64 and debug mode. Thanks! -- Tim Shen matchers.patch Description: Binary data

Re: [Patch 2/2] Localization problem in regex

> Fixed. > > It's not fully tested. I just run the 28_regex testcases. I'll do a > full test before committing. Committed. -- Tim Shen changelog Description: Binary data regex-locale.patch Description: Binary data

Re: [Patch 2/2] Localization problem in regex

On Sat, Aug 24, 2013 at 1:51 AM, Stefan Schweter wrote: > Am Fri, 23 Aug 2013 17:17:41 +0800 > schrieb Tim Shen : > >> Inspired by this mail: >> http://gcc.gnu.org/ml/libstdc++/2013-08/msg00131.html >> >> Thanks! >> >> > > Hi Tim, > > I a

Re: [Patch 2/2] Localization problem in regex

ed > e.g. basic_regex::assign. Why don't we `svn blame`? By the way, do we seariously need to keep ChangeLog in files? Is it more like a tradition than a solution? After all, we have SVN or Git now. I remember a mail metioned this but cannot find it >.< -- Tim Shen changelog Description: Binary data

Re: [Patch 2/2] Localization problem in regex

On Fri, Aug 23, 2013 at 10:26 PM, Paolo Carlini wrote: > Great. But please but the names of the functions you are changing between > round brackets. You have tons of examples everywhere. ...like this? -- Tim Shen changelog Description: Binary data

Re: [Patch 1/2] Rewrite regex scanner

ay, it seems to take surprisingly short time to review; after all, it's a huge patch. -- Tim Shen changelog Description: Binary data

Re: [Patch 2/2] Localization problem in regex

. It's important. I see. Actually I find a mistake by this review /w\, thanks! -- Tim Shen regex-locale.patch Description: Binary data

[Patch 2/2] Localization problem in regex

Inspired by this mail: http://gcc.gnu.org/ml/libstdc++/2013-08/msg00131.html Thanks! -- Tim Shen regex-locale.patch Description: Binary data

Re: [Patch] Fix empty grouping problem in regex

On Thu, Aug 22, 2013 at 9:08 AM, Tim Shen wrote: > Booted and tested with -m32, -m64 and -m64 debug-mode under x86_64 > GNU/Linux and committed(r201914). ...and here's the patch committed. -- Tim Shen emptygroup.patch Description: Binary data

Re: [Patch] Replace spaces with tabs in regex files

On Thu, Aug 22, 2013 at 4:56 PM, Paolo Carlini wrote: > Ok, thanks! Committed. -- Tim Shen

Re: [Patch] Fix empty grouping problem in regex

Change vector::at() call to vector::operator[](). Booted and tested with -m32, -m64 and -m64 debug-mode under x86_64 GNU/Linux and committed(r201914). -- Tim Shen

Re: [regex] New enum type syntax_option_type

On Mon, Aug 19, 2013 at 10:26 PM, Tim Shen wrote: > Great, let's test it now, though I don't think that it breaks something. Committed. -- Tim Shen

Fwd: [regex] New enum type syntax_option_type

-- Forwarded message -- From: Tim Shen Date: Mon, Aug 19, 2013 at 10:26 PM Subject: Re: [regex] New enum type syntax_option_type To: Daniel Krügler Cc: libstdc++ On Sun, Aug 18, 2013 at 8:50 PM, Daniel Krügler wrote: > Due to Tim Shen's recent activities at regex impr

Re: [Patch] Fix empty grouping problem in regex

Here's the correct version of changelog. -- Tim Shen changelog Description: Binary data

Re: [Patch] Fix empty grouping problem in regex

committed files in this patch? -- Tim Shen

[Patch] Fix empty grouping problem in regex

Before this patch, it causes the executor into infinite loop. Tested under x86_64. I'll test -m32 and check-debug before committing. Thanks! -- Tim Shen changelog Description: Binary data emptygroup.patch Description: Binary data

Re: [Patch] Regex back-reference support

Bootstrap passed; tested under -m32, -m64, debug; ...and committed. -- Tim Shen

Re: Two testcases failing for check-debug

ap Passed, and testsuites with -D_GLIBCXX_DEBUG, with or without -m32 passed. Could you please commit this patch for me? I lost my SSH private key :( Thanks! -- Tim Shen a.patch Description: Binary data

Re: [Patch] Regex back-reference support

s fine for that). I have to use a vector, because I need to iterate it while manipulating it as a stack. -- Tim Shen backref.patch Description: Binary data

Re: [Patch] Regex back-reference support

logic is commented. Add another testcase. I'll test it again before final commit. -- Tim Shen changelog Description: Binary data backref.patch Description: Binary data

Re: [Patch] Regex back-reference support

On Sat, Aug 10, 2013 at 4:58 PM, Paolo Carlini wrote: > On 08/10/2013 10:37 AM, Tim Shen wrote: >> >> +regex_match(s, *(&s+1)-1, m, re); > > I don't like these *(&s+1)-1. As you wish :) -- Tim Shen changelog Description: Binary data backref.patch Description: Binary data

Re: [Patch] Regex back-reference support

On Sat, Aug 10, 2013 at 4:37 PM, Tim Shen wrote: > Nothing surprising here. > > Bootstrap passed and tested under x86_64 and i386 Linux. Changelog. -- Tim Shen changelog Description: Binary data

[Patch] Regex back-reference support

Nothing surprising here. Bootstrap passed and tested under x86_64 and i386 Linux. -- Tim Shen backref.patch Description: Binary data

Re: [Patch] Whole regex refactoring and current status

e -k check-target-libstdc++-v3 > RUNTESTFLAGS="--target_board='unix/\{-m32,-m64\}'" > > for sure there are other ways to obtain the same result. Committed. I entered `gcc-build/x86_64-unknown-linux-gnu/32/libstdc++-v3` then run `make check`. I see -m32 in test log. -- Tim Shen

Re: [Patch] Whole regex refactoring and current status

On Fri, Aug 9, 2013 at 12:51 AM, Tim Shen wrote: > So here's the change. It's under testing now, but could took several > hours. If someone has a faster machine, please tell the result :) Unfortuantely using `unsigned int => unsigned short` cannot work. Instead, I create

Re: [Patch] Whole regex refactoring and current status

x27;s under testing now, but could took several hours. If someone has a faster machine, please tell the result :) As a simple test, `g++ -m32 test.cc` didn't fail. -- Tim Shen a.patch Description: Binary data

Re: [Patch] Whole regex refactoring and current status

when I switch flag_type from unsigned int to, say, unsigned short, conflicts will appear in 16bit archtectures. -- Tim Shen

Re: [Patch] Whole regex refactoring and current status

On Thu, Aug 8, 2013 at 10:04 PM, Tim Shen wrote: > On Thu, Aug 8, 2013 at 8:53 PM, Paolo Carlini > wrote: >> Tim, please address this ASAP, otherwise we have to revert the whole thing. > > I'm trying to reproduce the compilation failures. There's a typedef in

<    1   2   3   4   >