This fixes PR 83601.
Tested on x86_64-linux-gnu.
--
Regards,
Tim Shen
commit 01a85ea3ae77acc7ad03430a6982db1b2b8c8bc3
Author: Tim Shen
Date: Fri Jan 12 22:22:45 2018 -0800
PR libstdc++/83601
* include/bits/regex.tcc (regex_replace): Fix escaping in sed
On Mon, Sep 18, 2017 at 4:01 PM, Jonathan Wakely wrote:
> On 18/09/17 10:58 -0700, Tim Shen via libstdc++ wrote:
>>
>> On Mon, Sep 18, 2017 at 10:26 AM, Jonathan Wakely
>> wrote:
>>>>
>>>> We need to rewrite this to check the lengths are equal first,
7;s similar
to the existing "if (_RAIters()) { ... }".
I'd expect the patches to be renaming the current implementations and
adding wrappers, instead of adding new implementations.
--
Regards,
Tim Shen
x86_64-linux-gnu.
Thanks!
--
Regards,
Tim Shen
commit a97b7fecd319e031ffc489a956b8cf3dc63eeb26
Author: Tim Shen
Date: Mon Sep 4 03:19:35 2017 -0700
PR libstdc++/71500
* include/bits/regex_executor.tcc: Support icase in
regex_tratis<...> for back reference m
Besides the changes on the comments, I also changed the definition of
_S_trivial_copy_assign and _S_trivial_move_assign to match what union
has. See [class.copy.assign]p9.
On Thu, Jun 1, 2017 at 8:13 AM, Jonathan Wakely wrote:
> On 30/05/17 02:16 -0700, Tim Shen via libstdc++ wrote:
>>
_cast.
> (__erased_dtor): Remove constexpr specifier and use _Destroy.
>
>
--
Regards,
Tim Shen
On Mon, May 29, 2017 at 11:29 PM, Tim Shen wrote:
> This patch implements
> <https://lichray.github.io/trivially_variant.html>, but with more
Actually, it didn't. The copy assign and move assign conditions are
wrong in the patch. Fixed those.
--
Regards
into these four structs. There aren't
functional changes except for more triviality.
Sorry for having a large patch. Do tell me if you want me to split it.
Tested on x86_64-linux-gnu.
Thanks!
--
Regards,
Tim Shen
commit a4db7d21c6e4223300861114931eb0ef78bef1a6
Author: Tim Shen
Date:
mediate parameter, not things used in forming it.
>
>
> Then the original patch is OK for trunk and gcc-7-branch.
>
> Thank you Tim and Tim for the explanations.
>
Committed. I didn't bother using remove_cv> only
because p0088r3 says decay_t.
--
Regards,
Tim Shen
On Mon, May 22, 2017 at 11:05 AM, Tim Shen wrote:
> On Mon, May 22, 2017 at 6:21 AM, Jonathan Wakely wrote:
> I suggest to cc a front-end person (Jason?) to take a look, as I
> suggested in the bug, and the example: https://godbolt.org/g/AxUv16.
See more discussion in pr80737. Basical
On Mon, May 22, 2017 at 6:21 AM, Jonathan Wakely wrote:
> On 19/05/17 22:40 -0700, Tim Shen via libstdc++ wrote:
>>
>> diff --git a/libstdc++-v3/include/std/variant
>> b/libstdc++-v3/include/std/variant
>> index 0e04a820d69..b9824a5182c 100644
>> --- a/libstdc+
This fixes PR libstdc++/80737.
I actually can't come up with a minimal test case, because I suspect
that there is a front-end bug in GCC. See discussions in the bug.
Tested on x86_64-linux-gnu.
Thanks!
--
Regards,
Tim Shen
commit 6f362991f025069328c4901d95b657d498aad250
Author: Tim
On Mon, Jan 9, 2017 at 2:52 AM, Jonathan Wakely wrote:
> On 08/01/17 22:49 -0800, Tim Shen wrote:
>>
>> On Tue, Jan 3, 2017 at 6:17 AM, Jonathan Wakely
>> wrote:
>>>
>>> On 01/01/17 04:17 -0800, Tim Shen via libstdc++ wrote:
>>>>
>>
On Tue, Feb 14, 2017 at 2:49 PM, Jonathan Wakely wrote:
> On 14/02/17 13:59 -0800, Tim Shen via libstdc++ wrote:
>>
>> This is an obvious missing std::forward. :)
>
>
> I was about to look into it, I assumed it would be something simple!
>
>> diff --git a/libst
This is an obvious missing std::forward. :)
Testing on x86_64-linux-gnu, but I expect it to pass.
--
Regards,
Tim Shen
commit 08235141a7e06db2b604b5869c9d8e4aaf8fa29b
Author: Tim Shen
Date: Tue Feb 14 13:55:18 2017 -0800
2017-02-14 Tim Shen
PR libstdc++/79513
Thanks Kostya for the fuzzing work!
Reduce it to a reasonably small number (but not too small), so that
libFuzzer doesn't find as many crashers (none in a short period of
time, actually) with a 8MB stack on a 64-bit machine.
Thanks!
--
Regards,
Tim Shen
c
Add gcc-patches.
On Fri, Feb 10, 2017 at 5:48 PM, Tim Shen wrote:
> Oops I attached a diff without the ChangeLog. Attach again.
>
> --
> Regards,
> Tim Shen
--
Regards,
Tim Shen
On Tue, Jan 10, 2017 at 2:19 PM, Ville Voutilainen
wrote:
> Cleanups based on review; there's no longer any public typedefs added
> to variant,
> and the test is greatly simpler with much less trickery.
Looks good to me.
Thanks!
--
Regards,
Tim Shen
On Tue, Jan 3, 2017 at 6:17 AM, Jonathan Wakely wrote:
> On 01/01/17 04:17 -0800, Tim Shen via libstdc++ wrote:
>>
>> +#define _VARIANT_RELATION_FUNCTION_TEMPLATE(__op, __name) \
>> + template \
>> +constexpr bool operator __op(cons
On Wed, Jan 4, 2017 at 7:16 PM, Tim Shen wrote:
> Since it's an obvious textual fix, I'm going to check it in directly.
Checked in with 80-columns limit respected. I have confusing tabstop
settings... :/
--
Regards,
Tim Shen
Since it's an obvious textual fix, I'm going to check it in directly.
--
Regards,
Tim Shen
commit b005916b043f52feed32b646f86ced80f3e5392b
Author: Tim Shen
Date: Wed Jan 4 19:07:07 2017 -0800
2017-01-05 Tim Shen
PR libstdc++/78996
* include/s
On Tue, Dec 6, 2016 at 6:37 AM, Jonathan Wakely wrote:
> On 06/12/16 12:49 +, Jonathan Wakely wrote:
>>
>> On 06/12/16 03:52 -0800, Tim Shen wrote:
>>>
>>> On Tue, Dec 6, 2016 at 2:30 AM, Jonathan Wakely wrote:
>>>>
>>>> This
On Tue, Dec 6, 2016 at 2:30 AM, Jonathan Wakely wrote:
> This looks good - OK for trunk, thanks!
Committed.
Thanks!
--
Regards,
Tim Shen
On Wed, Nov 30, 2016 at 8:27 AM, Jonathan Wakely wrote:
> On 26/11/16 21:38 -0800, Tim Shen wrote:
>>
>> This 4-patch series contains the following in order:
>>
>> a.diff: Remove uses-allocator ctors. They are going away, and removing
>> it reduces the maintena
On Wed, Nov 30, 2016 at 8:27 AM, Jonathan Wakely wrote:
> On 26/11/16 21:38 -0800, Tim Shen wrote:
>> + template>
>> struct _Uninitialized;
>
>
> I'm still unsure that is_literal_type is the right trait here. If it's
> definitely right then we should p
able
approach to achieve O(1) runtime cost even under -O0.
Bootstrapped and tested for each of them.
Thanks!
--
Regards,
Tim Shen
commit 638ecd4cf354d853bb12b089a356df99531f9afa
Author: Tim Shen
Date: Thu Nov 24 00:56:08 2016 -0800
2016-11-26 Tim Shen
* inc
Also see discussions from libstdc++/71500.
Bootstrapped and tested on x86_64-linux-gnu.
Thanks!
--
Regards,
Tim Shen
commit 6c862a2b84578a651d458b09572551c8391082e4
Author: Tim Shen
Date: Sat Nov 26 12:36:20 2016 -0800
2016-11-26 Tim Shen
PR libstdc++/71500
Tested on x86_64-linux-gnu.
Thanks!
--
Regards,
Tim Shen
commit 69c72d9bb802fd5e4f2704f0fe8a041f8b26d8bd
Author: Tim Shen
Date: Mon Nov 21 21:29:13 2016 -0800
2016-11-22 Tim Shen
PR libstdc++/78441
* include/std/variant: Propagate cv qualifications to types returned
On Tue, Nov 15, 2016 at 11:31 AM, Jonathan Wakely wrote:
> On 15/11/16 12:08 +, Jonathan Wakely wrote:
>>
>> On 12/11/16 12:11 -0800, Tim Shen wrote:
>>>
>>> At Issaquah we decided to remove the supports above.
>>
>>
>> OK with a suitable Ch
At Issaquah we decided to remove the supports above.
Bootstrapped and tested on x86_64-linux-gnu.
Thanks!
--
Regards,
Tim Shen
Index: libstdc++-v3/include/std/variant
===
--- libstdc++-v3/include/std/variant (revision 242337
This fixes libstdc++/78236. I'm surprised that this bug was not
revealed until now :P.
Bootstrapped and tested under x86_64-linux-gnu.
I'm happy with however many backports.
--
Regards,
Tim Shen
commit 8aee66b743b5b0ef09cbc9587ebbacf6665ba0cb
Author: Tim Shen
Date: Mon Nov 7 21:
could have used this for std::regex exceptions too.
--
Regards,
Tim Shen
On some platforms the compiler complains about __try and __catch not
defined. I hope is the right thing to include.
I'm bootstrapping the compiler under x86_64-linux-gnu, but it shouldn't fail.
Thanks!
--
Regards,
Tim Shen
a.diff
Description: Binary data
On Thu, Sep 22, 2016 at 3:36 AM, Tim Shen wrote:
> Then my question is, what about type traits uses like
> is_copy_constructible? I have seen non-qualified uses in std::any and
> std::optional and other places. Should all of them be qualified?
Ah never mind, I realized that *usuall
On Thu, Sep 22, 2016 at 3:03 AM, Jonathan Wakely wrote:
> On 22/09/16 01:49 -0700, Tim Shen wrote:
>>
>> Done. When writing the initial version, I was trying to save as much
>> qualifications as possible (as long as the semantic doesn't change)
>> for readabili
t;
> OK for trunk with that change, thanks for the quick fix.
>
>
Committed. Thanks!
--
Regards,
Tim Shen
On Thu, Sep 22, 2016 at 12:43 AM, Tim Shen wrote:
> Hi, this patch fixes the following compilation failure:
For the record, the bug is found by Ville. Thank you Ville! :)
--
Regards,
Tim Shen
.
Thanks!
--
Regards,
Tim Shen
a.diff
Description: Binary data
On Wed, Sep 21, 2016 at 1:52 AM, Jonathan Wakely wrote:
> THanks, OK for trunk.
Committed.
Thanks!
--
Regards,
Tim Shen
On Mon, Sep 19, 2016 at 1:06 PM, Tim Shen wrote:
> I believe that it's a "typo" from me - it should be
> is_trivially_destructible, not is_default_constructible (so that we
> can avoid using aligned_storage in the corresponding specialization).
> is_literal_type wor
s_trivially_default_constructible also
> depends on trivially destructible).
I checked for is_default_constructible, and all other sites are appropriate.
--
Regards,
Tim Shen
ion
Thanks for the patch! Tested on x86_64-linux-gnu and committed as r239996.
I changed std::__addressof to std::addressof since it's standardized
since C++11.
--
Regards,
Tim Shen
On Fri, Aug 26, 2016 at 3:09 AM, Jonathan Wakely wrote:
> OK for trunk, thanks.
Committed as r239794.
Thanks!
--
Regards,
Tim Shen
stsuite/libstdc++.log? I'll find an arm machine to
reproduce it.
> The reason it succeeds for Cortex-M3 is because
> '' includes '' and exception has the following code:
> #if (__cplusplus >= 201103L) && (ATOMIC_INT_LOCK_FREE > 1)
> #include
> #include
> #endif
>
> Which includes bits/exception_ptr.h and thus bits/exception_defines.h
> for targets with ATOMIC_INT_LOCK_FREE which is the case for Cortex-M3
> but not Cortex-M0.
--
Regards,
Tim Shen
On Wed, Aug 24, 2016 at 1:41 AM, Jonathan Wakely wrote:
> On 24/08/16 00:18 -0700, Tim Shen wrote:
>>
>> I didn't realized that we can actually escape a dash inside bracket
>> expression: R"([\-])", in which case the dash should be treated
>> literally.
I didn't realized that we can actually escape a dash inside bracket
expression: R"([\-])", in which case the dash should be treated
literally.
Tell me if you feel like we need more documentations. :P
Bootstrapped and tested on x86_64-linux-gnu.
Thanks!
--
Regards,
On Mon, Aug 22, 2016 at 10:35 AM, Jonathan Wakely wrote:
> On 20/08/16 03:28 -0700, Tim Shen wrote:
> OK for trunk with the more detailed changelog entry. Thanks!
Done. Tested on x86_64-linux-gnu (if I remember it correctly back to
several days ago) and committed as r239673.
--
Regard
reasons. We know that we are going to do better than the
inliner on complicated recursive functions, right? :)
Thanks!
--
Regards,
Tim Shen
commit d15f3ded9ca5133a23b511a1dbe127673609ce92
Author: Tim Shen
Date: Sat Aug 20 03:14:40 2016 -0700
2016-08-20 Tim Shen
Split
Tested on x86_64-linux-gnu and checked in as r239590.
Thanks!
--
Regards,
Tim Shen
to static_cast again when it's already a
> size_t? :-)
> Do we need either static_cast?
>
> constexpr size_t __magic_monostate_hash = -;
> return __magic_monostate_hash;
Done. I seriously have no idea why that will happen.
>
>&
+17.
__bool_constant is even better. :)
>
> Will this fix apply cleanly to the branches too?
>
For gcc6 yes; for gcc5 there needs more work. I guess it's OK for
backporting to gcc6?
Updated the patch according to the discussion in the libstdc++/71500 bug.
--
Regards,
Tim Shen
commit 46
Bootstrapped and tested on x86_64-pc-linux-gnu with debug macro.
Thanks!
--
Regards,
Tim Shen
commit b8e06b00162b9396e639f517d5cbde0cbd5932fc
Author: Tim Shen
Date: Sat Jun 11 00:41:09 2016 -0700
2016-06-11 Tim Shen
PR libstdc++/71500
* include/bits
yway).
Committed to trunk as r235382.
Thanks!
--
Regards,
Tim Shen
Bootstrapped and tested on x86-pc-linux-gnu debug.
It is a conformance fix, but I don't think it's very important. I'm
happy to backport it to gcc 5/4.9, but if it's not considered
necessary, I'm Ok as well.
Thanks!
--
Regards,
Tim Shen
commit 7f4f729d5dd80050ff9663
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
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, Dec 14, 2015 at 10:03 AM, Jonathan Wakely wrote:
> OK then I do understand it and it's definitely OK to commit :-)
>
> Thanks.
>
Committed to trunk, gcc 5 and gcc 4.9.
--
Regards,
Tim Shen
g before, creating a vector of
> default-constructed match results, that were not matched?
>
Yes, that's the case. I'm not sure why I missed this. Perhaps all I
was focusing on is to get the captures in the lookahead sub-expression
out of it, so later user can use it; but I didn't think about the
other way around.
--
Regards,
Tim Shen
On Fri, Dec 11, 2015 at 10:08 PM, Tim Shen wrote:
> This is a one-line quick fix for correctness.
>
> I bootstrapped trunk and tested on x86_64-pc-linux-gnu, but I wish I
> can backport it at least to gcc-5-branch.
>
Sorry, I didn't actually write the changelog :P. Updated
This is a one-line quick fix for correctness.
I bootstrapped trunk and tested on x86_64-pc-linux-gnu, but I wish I
can backport it at least to gcc-5-branch.
Thanks!
--
Regards,
Tim Shen
commit 46b13f280fcbec6293ad614fb8f30f5882c7106d
Author: Tim Shen
Date: Fri Dec 11 21:34:38 2015 -0800
cutor::_M_dfs) into different smaller ones and fix mostly known
issues and standard conformance issues.
--
Regards,
Tim Shen
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
ache the
smallest 256 results, regardless of the actual char type. It also
covers other char types and reduced the code complexity.
As for #ifdef _GLIBCXX_DEBUG, I think it's fine to delete them, since
they seem not catching any useful bugs.
--
Regards,
Tim Shen
On Mon, Sep 7, 2015 at 4:06 AM, Jonathan Wakely wrote:
> On 28/08/15 11:23 -0700, Tim Shen wrote:
>>
>> On Fri, Aug 28, 2015 at 8:59 AM, Jonathan Wakely
>> wrote:
>>>
>>> There seems to be no need to construct a std::string here, just pass a
>>> c
On Fri, Aug 28, 2015 at 11:23 AM, Tim Shen wrote:
> So is it good to have an owned raw pointer stored in runtime_error,
> pointing to a heap allocated char chunk, which will be deallocated in
> regex_error's dtor?
I just put a string member into regex_error, completely ignoring
need
dynamic allocation.
So is it good to have an owned raw pointer stored in runtime_error,
pointing to a heap allocated char chunk, which will be deallocated in
regex_error's dtor?
--
Regards,
Tim Shen
Bootstrapped and tested.
Thanks!
--
Regards,
Tim Shen
commit 53c1caff442e97a18652ec8b1d984341168fd98d
Author: Tim Shen
Date: Thu Aug 27 21:42:40 2015 -0700
PR libstdc++/67361
* include/bits/regex_error.h: Add __throw_regex_error that
supports string
Bootstrapped and tested on x86_64-pc-linux-gnu.
Thanks!
--
Regards,
Tim Shen
commit e134e1a835ad15900686351cade36774593b91ea
Author: Tim Shen
Date: Wed Aug 26 17:51:29 2015 -0700
PR libstdc++/67362
* include/bits/regex_scanner.tcc (_Scanner<>::_M_scan_
On Wed, Aug 26, 2015 at 6:41 PM, Tim Shen wrote:
> Bootstrapped and tested on x86_64-pc-linux-gnu.
Also plan to backport to 4.9 and 5.
--
Regards,
Tim Shen
On Thu, Aug 6, 2015 at 1:12 AM, Tim Shen wrote:
> In next few weeks I'm gonna sending patches for refactoring .
>
> The goal is to make the gigantic _Executor class into several smaller
> ones and hopefully more readable. After that, there are several
> correctness/performanc
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, 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
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 (_
#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
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
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&
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 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
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 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
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
<_Tp1, _Lp>& __r) noexcept
Why?
template
inline bool
operator<(const shared_ptr<_Tp>& __a, nullptr_t) noexcept
- {
+ {
using _Tp_RE = typename remove_extent<_Tp>::type;
- return std::less<_Tp_RE>()(__a.get(), nullptr);
+ return std::less<_Tp_RE>()(__a.get(), nullptr);
}
using _Tp_RE = typename shared_ptr<_Tp>::element_type;
--
Regards,
Tim Shen
me conditional::value,
> _Normal_deleter, _Array_deleter>::type;
Sadly std::default_delete doesn't support _Tp[N]. It will also works
to create a std::default_delete-ish helper trait, with _Tp[N]
specialized to `delete []` as well.
--
Regards,
Tim Shen
On Tue, Nov 25, 2014 at 12:46 AM, Tim Shen wrote:
> On Wed, Nov 12, 2014 at 11:45 PM, Tim Shen wrote:
>> Committed with comment fix and slight change on testcase
>> (VERIFY(false) at end of the try block -- must throw).
>
> Is it possible to backport this patch t
On Mon, Apr 27, 2015 at 4:57 AM, Jonathan Wakely wrote:
> OK for trunk.
Committed.
--
Regards,
Tim Shen
On Sat, Apr 25, 2015 at 1:10 AM, Tim Shen wrote:
> Bootstrapped and tested.
I didn't test with _GLIBCXX_DEBUG though. Updated the patch for
removing DFS restriction for ECMAScript.
--
Regards,
Tim Shen
commit 32cd325c4acffdcdf16caca4233a2455ea483d69
Author: Tim Shen
Date: Sat Apr
On Tue, Feb 17, 2015 at 1:54 AM, Jonathan Wakely wrote:
> On 16/02/15 22:10 +0000, Tim Shen wrote:
>>
>> Hi Jon,
>>
>> The Thompson NFA algorithm (BFS approach) in libstdc++ regex exists for a
>> while, and I do think we can add it to the standard as a flag
>&
On Fri, Mar 27, 2015 at 12:44 PM, Jonathan Wakely wrote:
> I forgot to say that for a { dg-do compile } test you don't need a
> 'test' variable and don't need to #include ,
Committed.
--
Regards,
Tim Shen
commit a1b32eec28442e38b830078ce3a9c142b1072647
Author: Tim S
On Sun, Mar 15, 2015 at 11:27 PM, Tim Shen wrote:
> Here's the simple version of it.
Ping?
--
Regards,
Tim Shen
a required functionality.
I did noticed that in other functions (operator bool, etc), but ignored these.
On Sun, Mar 15, 2015 at 6:13 AM, Jonathan Wakely wrote:
> On 15 March 2015 at 08:09, Tim Shen wrote:
>> Did a little bit refectoring on regex_constants, so that users won't
&
Did a little bit refectoring on regex_constants, so that users won't
be polluted too much (they are not enum types anymore).
Bootstrapped and tested.
Thanks!
--
Regards,
Tim Shen
commit 5cd86b408ef0a9cba1a21a3018c797d9e245d158
Author: Tim Shen
Date: Sat Mar 14 23:05:05 2015
On Tue, Mar 10, 2015 at 7:24 AM, Jakub Jelinek wrote:
> Ok for trunk.
Committed.
Thanks!
--
Regards,
Tim Shen
I guess this patch doesn't break abi compatibility, so if everything
is Ok, I'm gonna patch it to 4.9 too.
I'm not sure if this is a "regression fix" though; if it's
inappropriate for trunk, then I can simply wait.
Bootstrapped in trunk and tested.
Thanks! :)
talking about the first patch which fixes the forward
iterator problem, because it's already checked into 4.9; I'm
suggesting the last one, who fixes the first one :)
--
Regards,
Tim Shen
On Wed, Jan 21, 2015 at 9:08 PM, Tim Shen wrote:
> Fixed and committed.
I believe this one is also suitable for 4.9?
I guess we don't have a 'code freeze' for 4.9 branch as we do for 5.0
late stage?
--
Regards,
Tim Shen
On Fri, Jan 23, 2015 at 1:20 PM, Tim Shen wrote:
> I think this patch fits 4.9 branch well?
Ping.
--
Regards,
Tim Shen
On Wed, Jan 21, 2015 at 9:10 PM, Tim Shen wrote:
> Submitted version.
I think this patch fits 4.9 branch well?
--
Regards,
Tim Shen
On Wed, Jan 21, 2015 at 9:08 PM, Tim Shen wrote:
> Fixed and committed.
Submitted version.
--
Regards,
Tim Shen
commit 62662ecc7defacdd82f9a9c6e62a563b4a094726
Author: timshen
Date: Thu Jan 22 05:02:38 2015 +
PR libstdc++/64649
* include/bits/regex.tcc (regex_tra
On Wed, Jan 21, 2015 at 4:12 AM, Jonathan Wakely wrote:
> Could this use "digit" instead of "alpha" so it shifts to "chfhs"
> instead of something with non-alphabetic characters?
Fixed and committed.
--
Regards,
Tim Shen
k with that tweak to the changelog.
>
> (Any more non-regression regex bugs that get reported might have to
> wait for stage 1 and get fixed for the next release)
Fixed and committed.
--
Regards,
Tim Shen
1 - 100 of 338 matches
Mail list logo
