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
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
On Thu, Aug 22, 2013 at 4:56 PM, Paolo Carlini wrote:
> Ok, thanks!
Committed.
--
Tim Shen
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
Inspired by this mail: http://gcc.gnu.org/ml/libstdc++/2013-08/msg00131.html
Thanks!
--
Tim Shen
regex-locale.patch
Description: Binary data
. It's important.
I see.
Actually I find a mistake by this review /w\, thanks!
--
Tim Shen
regex-locale.patch
Description: Binary data
ay, it seems to take surprisingly short time to review; after
all, it's a huge patch.
--
Tim Shen
changelog
Description: Binary data
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
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
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
> 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
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
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
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
ted before committing.
Thanks!
--
Tim Shen
stateseq.patch
Description: Binary data
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
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
an AST-based formatter? Clang seems to
write a good one.
--
Tim Shen
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
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!
-
x27;t
specify it?
Tested under -m64. I'll do a full test before committing.
Thanks!
--
Tim Shen
a.patch
Description: Binary data
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
Just follow the standard :)
Booted and tested under -m32, -m64.
Thank you!
--
Tim Shen
a.patch
Description: Binary data
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
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
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
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
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
On Tue, Oct 1, 2013 at 1:32 AM, Paolo Carlini wrote:
> Ok, thanks.
Committed.
Thanks!
--
Tim Shen
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
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
> 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.
ork', up to you, but
> please adjust it.
Committed.
I learn that an implementation could be incorrect ;)
--
Tim Shen
a.patch
Description: Binary data
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
_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
Improved support for C++11, including support for <regex>.
>
--
Tim Shen
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
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.
>
Tested under -m32, -m64, however didn't do a bootstrap. Is that OK?
Thanks!
--
Tim Shen
a.patch
Description: Binary data
e non-defuault matcher
every 2-3 commits. Do we have a better solution?
Thanks!
--
Tim Shen
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
Stupid errors hidden in some large commit.
I don't think they will break boostrap?
Thanks!
--
Tim Shen
a.patch
Description: Binary data
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
On Sun, Oct 6, 2013 at 5:38 AM, Paolo Carlini wrote:
> Ok, thanks.
Committed :)
--
Tim Shen
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
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,
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
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
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
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
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
eep the assign(), because the ratio in regex could probably be more
than 25%.
--
Tim Shen
a.patch
Description: Binary data
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
This memory leak is because forgetting virtual destructor of the base
class _Executor.
Thanks!
--
Tim Shen
a.patch
Description: Binary data
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
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
On Wed, Oct 16, 2013 at 6:13 PM, Paolo Carlini wrote:
> Thank you!
Committed.
Thanks!
--
Tim Shen
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
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
...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
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
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
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
nder UTF-8
charset. Now it's hex format.
I also make the char handling simpler.
--
Tim Shen
a.patch
Description: Binary data
and committed.
By the way, UTF-8 *encoding* is a more accurate word, instead of
`charset`(which is Unicode).
--
Tim Shen
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
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'
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
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
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
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
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
+// 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
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
I did it wrong in r227289 - I ignored the "\n" special case in grep.
Turns out using code to handle special cases is error prone, so I
turned to use data (_M_grep_spec_char and _M_egrep_spec_char).
Bootstrapped and tested on x86_64-pc-linux-gnu.
Thanks!
--
Regards,
Tim S
On Mon, Feb 15, 2016 at 4:26 AM, Jonathan Wakely wrote:
> Those new members change the size of the type, so are an ABI change.
>
> Couldn't they be static members?
Ahh right. Since they are just used for once, use them in the line.
--
Regards,
T
...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
ns while in Stage 4.
...committed.
--
Regards,
Tim Shen
.
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
92r 191u
0s0mem0pf
After:
split.cc14r 14u
0s0mem0pf
split_bfs.cc78r 77u
0s0mem0pf
The cache obviously works.
--
Regards,
Tim Shen
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
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
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
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
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
n the pointer.
L396:
memory_resource* set_default_resource(memory_resource* __r) noexcept
{
if ( __r == nullptr)
{ __r = new_delete_resource(); }
memory_resource* __prev = get_default_resource();
memory_resource::s_default_resource.store(__r);
return __prev;
}
We shouldn't care if it's nullptr or not.
Your get-then-set may cause a data race. I think
std::atomic<>::exchange will work, but we should confirm with Jon.
--
Regards,
Tim Shen
On Sat, Jul 25, 2015 at 12:11 AM, Tim Shen wrote:
> It's not a very necessary refactoring, but simply can't resist. :)
>
> I'm not sure of the ::memcpy calls. It looks not very idiomatic, but
> std::copy on char* looks even more weird? :/
>
> Bo
Kinda important, since "[a-z0-9-]" may be a common case.
Bootstrapped and tested.
Guess it can also be backported to 5, or even 4.9?
Thanks!
--
Regards,
Tim Shen
On Sun, Jul 26, 2015 at 5:19 AM, Tim Shen wrote:
> Kinda important, since "[a-z0-9-]" may be a common case.
>
> Bootstrapped and tested.
Actual patch...
--
Regards,
Tim Shen
commit e0e6c2e3b722e1453d29ad3a56d0de80046453b0
Author: Tim Shen
Date: Sun Jul 26 04:37:45 201
On Mon, Jul 27, 2015 at 4:45 AM, Jonathan Wakely wrote:
> On 26/07/15 05:20 -0700, Tim Shen wrote:
>>
>> @@ -389,7 +391,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>> #endif
>> }
>>
>> - void
>> + _StringT
>> _M_add_collating_elem
On Tue, Jul 28, 2015 at 3:27 AM, Jonathan Wakely wrote:
> On 27/07/15 19:40 -0700, Tim Shen wrote:
>>
>> Done by s/_M_add_collating_element/_M_add_collate_element/.
>
>
> Great, thanks. OK for trunk and gcc-5-branch.
Committed. Is there no need for gcc-4_9-branch? What&
ent and size) are expected to be the
same, we can remove that template parameter (and all indentation
changes!); otherwise, is alignment more unlikely to change than size
the reason we always stick on alignof(std::function)?
--
Regards,
Tim Shen
#x27;d say medium importance, for [a-z0-9-] not working in POSIX
syntax (while ECMAScript seems to be more popular, which works
correctly).
If 4.9 is `stable` and expected to be experimetal, which by my
definition should only include important changes, we may leave it as
is?
--
Regards,
Tim Shen
ation.
Done.
Also change _Executor::_M_lookahead(_State<>) to
_Executor::_M_lookahead(_StateIdT __next_state).
--
Regards,
Tim Shen
commit 52c70e70bdbef15c787f81e83722bfc119543ff0
Author: Tim Shen
Date: Wed Jul 29 21:08:43 2015 -0700
* include/bits/regex_automaton.h (_
On Wed, Jul 29, 2015 at 9:21 PM, Tim Shen wrote:
> On Wed, Jul 29, 2015 at 2:15 AM, Jonathan Wakely wrote:
>> Yes, that makes sense. See the code in for how
>> to set the alignment of the buffer appropriately. You can use the size
>> and alignment of std::functio
tively we
can just make it a member.
Bootstrapped and tested.
Take your time. This isn't urgent. My plan is to finish them by the
next big release.
Thanks!
--
Regards,
Tim Shen
commit 007f04c627b0e0ea83b4e2e818354254f4ce649a
Author: Tim Shen
Date: Thu Aug 6 00:37:21 2015 -0700
* in
On Wed, Sep 16, 2015 at 10:38 AM, Jonathan Wakely wrote:
> On 12/09/15 01:57 +0000, Tim Shen wrote:
>>
>> Ok then, let's not appending dynamic location string, but only throw a
>> string literal pointer.
>
>
> This looks great, and a *huge* improvement on the
cutor::_M_dfs) into different smaller ones and fix mostly known
issues and standard conformance issues.
--
Regards,
Tim Shen
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
Bootstrapped and tested.
Thanks!
--
Regards,
Tim Shen
commit 95c73ab6280c1f8182d018ee29a44230965dd4ef
Author: timshen
Date: Sun Oct 19 15:14:55 2014 -0700
PR libstdc++/63497
include/bits/regex_executor.h (_Executor::_M_word_boundary): Remove
const qualifier
1 - 100 of 338 matches
Mail list logo
