This fixes PR 83601.
Tested on x86_64-linux-gnu.
--
Regards,
Tim Shen
commit 01a85ea3ae77acc7ad03430a6982db1b2b8c8bc3
Author: Tim Shen <tims...@google.com>
Date: Fri Jan 12 22:22:45 2018 -0800
PR libstdc++/83601
* include/bits/regex.tcc (regex_replace): Fix es
On Mon, Sep 18, 2017 at 4:01 PM, Jonathan Wakely <jwak...@redhat.com> wrote:
> On 18/09/17 10:58 -0700, Tim Shen via libstdc++ wrote:
>>
>> On Mon, Sep 18, 2017 at 10:26 AM, Jonathan Wakely <jwak...@redhat.com>
>> wrote:
>>>>
>>>> We
an't we? It'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
4-linux-gnu.
Thanks!
--
Regards,
Tim Shen
commit a97b7fecd319e031ffc489a956b8cf3dc63eeb26
Author: Tim Shen <tims...@google.com>
Date: Mon Sep 4 03:19:35 2017 -0700
PR libstdc++/71500
* include/bits/regex_executor.tcc: Support icase in
regex_tratis<..
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:
>>
(__erased_dtor): Remove constexpr specifier and use _Destroy.
>
>
--
Regards,
Tim Shen
On Mon, May 29, 2017 at 11:29 PM, Tim Shen <tims...@google.com> 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.
--
Regard
e 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 <tims...@google.
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<remove_reference> only
because p0088r3 says decay_t.
--
Regards,
Tim Shen
On Mon, May 22, 2017 at 11:05 AM, Tim Shen <tims...@google.com> wrote:
> On Mon, May 22, 2017 at 6:21 AM, Jonathan Wakely <jwak...@redhat.com> 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.or
On Mon, May 22, 2017 at 6:21 AM, Jonathan Wakely <jwak...@redhat.com> 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
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 Shen
On Mon, Jan 9, 2017 at 2:52 AM, Jonathan Wakely <jwak...@redhat.com> wrote:
> On 08/01/17 22:49 -0800, Tim Shen wrote:
>>
>> On Tue, Jan 3, 2017 at 6:17 AM, Jonathan Wakely <jwak...@redhat.com>
>> wrote:
>>>
>>> On 01/01/17 04:17 -0800, Ti
On Tue, Feb 14, 2017 at 2:49 PM, Jonathan Wakely <jwak...@redhat.com> 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!
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 <tims...@google.com>
Date: Tue Feb 14 13:55:18 2017 -0800
2017-02-14 Tim Shen <tims...@g
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
commit
Add gcc-patches.
On Fri, Feb 10, 2017 at 5:48 PM, Tim Shen <tims...@google.com> 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
<ville.voutilai...@gmail.com> 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 <jwak...@redhat.com> wrote:
> On 01/01/17 04:17 -0800, Tim Shen via libstdc++ wrote:
>>
>> +#define _VARIANT_RELATION_FUNCTION_TEMPLATE(__op, __name) \
>> + template \
>> +constexpr bool operator __o
On Wed, Jan 4, 2017 at 7:16 PM, Tim Shen <tims...@google.com> 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 <tims...@google.com>
Date: Wed Jan 4 19:07:07 2017 -0800
2017-01-05 Tim Shen <tims...@google.com>
On Tue, Dec 6, 2016 at 6:37 AM, Jonathan Wakely <jwak...@redhat.com> 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:
>>&
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 probab
proach 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 <tims...@google.com>
Date: Thu Nov 24 00:56:08 2016 -0800
2016-11-26 Tim Shen <tim
Also see discussions from libstdc++/71500.
Bootstrapped and tested on x86_64-linux-gnu.
Thanks!
--
Regards,
Tim Shen
commit 6c862a2b84578a651d458b09572551c8391082e4
Author: Tim Shen <tims...@google.com>
Date: Sat Nov 26 12:36:20 2016 -0800
2016-11-26 Tim Shen <tims...@g
Tested on x86_64-linux-gnu.
Thanks!
--
Regards,
Tim Shen
commit 69c72d9bb802fd5e4f2704f0fe8a041f8b26d8bd
Author: Tim Shen <tims...@google.com>
Date: Mon Nov 21 21:29:13 2016 -0800
2016-11-22 Tim Shen <tims...@google.com>
PR libstdc++/78441
* include
On Tue, Nov 15, 2016 at 11:31 AM, Jonathan Wakely <jwak...@redhat.com> 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.
>>
>>
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 <tims...@google.com>
Date:
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 <tims...@google.com> 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 m
On Thu, Sep 22, 2016 at 3:03 AM, Jonathan Wakely <jwak...@redhat.com> 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
be a good idea.
>
> 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 <tims...@google.com> wrote:
> Hi, this patch fixes the following compilation failure:
For the record, the bug is found by Ville. Thank you Ville! :)
--
Regards,
Tim Shen
on x86_64-linux-gnu.
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 <tims...@google.com> 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).
>
trivially_default_constructible also
> depends on trivially destructible).
I checked for is_default_constructible, and all other sites are appropriate.
--
Regards,
Tim Shen
}
>
>union
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 <jwak...@redhat.com> wrote:
> OK for trunk, thanks.
Committed as r239794.
Thanks!
--
Regards,
Tim Shen
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 <jwak...@redhat.com> 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 treate
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,
Tim S
On Mon, Aug 22, 2016 at 10:35 AM, Jonathan Wakely <jwak...@redhat.com> 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 committe
for 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 <tims...@google.com>
Date: Sat Aug 20 03:14:40 2016 -0700
2016-08-20 Ti
Tested on x86_64-linux-gnu and checked in as r239590.
Thanks!
--
Regards,
Tim Shen
why that will happen.
>
>> diff --git a/libstdc++-v3/testsuite/experimental/variant/compile.cc
>> b/libstdc++-v3/testsuite/experimental/variant/compile.cc
>> new file mode 100644
>> index 000..5cc7738
>> --- /dev/null
>> +++ b/libstdc++-v3/testsuite/exper
__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 46d269bcf
Bootstrapped and tested on x86_64-pc-linux-gnu with debug macro.
Thanks!
--
Regards,
Tim Shen
commit b8e06b00162b9396e639f517d5cbde0cbd5932fc
Author: Tim Shen <tims...@google.com>
Date: Sat Jun 11 00:41:09 2016 -0700
2016-06-11 Tim Shen <tims...@google.com>
ay).
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 7f4f729d5dd80050ff966398e28909a40fb57932
Author
On Mon, Feb 15, 2016 at 4:26 AM, Jonathan Wakely <jwak...@redhat.com> 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,
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 <jwak...@redhat.com> 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
about the
other way around.
--
Regards,
Tim Shen
On Fri, Dec 11, 2015 at 10:08 PM, Tim Shen <tims...@google.com> 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
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 <tims...@google.com>
Date: Fri Dec
::_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 <jwak...@redhat.com> 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 *hug
ed char values) to cache 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 <jwak...@redhat.com> wrote:
> On 28/08/15 11:23 -0700, Tim Shen wrote:
>>
>> On Fri, Aug 28, 2015 at 8:59 AM, Jonathan Wakely <jwak...@redhat.com>
>> wrote:
>>>
>>> There seems to be no need to const
On Fri, Aug 28, 2015 at 11:23 AM, Tim Shen tims...@google.com 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
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 tims...@google.com
Date: Thu Aug 27 21:42:40 2015 -0700
PR libstdc++/67361
* include/bits/regex_error.h: Add __throw_regex_error that
supports
Bootstrapped and tested on x86_64-pc-linux-gnu.
Thanks!
--
Regards,
Tim Shen
commit e134e1a835ad15900686351cade36774593b91ea
Author: Tim Shen tims...@google.com
Date: Wed Aug 26 17:51:29 2015 -0700
PR libstdc++/67362
* include/bits/regex_scanner.tcc (_Scanner::_M_scan_normal
On Wed, Aug 26, 2015 at 6:41 PM, Tim Shen tims...@google.com 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 tims...@google.com wrote:
In next few weeks I'm gonna sending patches for refactoring regex.
The goal is to make the gigantic _Executor class into several smaller
ones and hopefully more readable. After that, there are several
correctness/performance
.
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 tims...@google.com
Date: Thu Aug 6 00:37:21 2015 -0700
* include/bits
be a different std::function specialization.
Done.
Also change _Executor::_M_lookahead(_State) to
_Executor::_M_lookahead(_StateIdT __next_state).
--
Regards,
Tim Shen
commit 52c70e70bdbef15c787f81e83722bfc119543ff0
Author: Tim Shen tims...@google.com
Date: Wed Jul 29 21:08:43 2015 -0700
On Wed, Jul 29, 2015 at 9:21 PM, Tim Shen tims...@google.com wrote:
On Wed, Jul 29, 2015 at 2:15 AM, Jonathan Wakely jwak...@redhat.com wrote:
Yes, that makes sense. See the code in ext/aligned_buffer.h for how
to set the alignment of the buffer appropriately. You can use the size
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::functionbool(char))?
--
Regards,
Tim Shen
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
On Tue, Jul 28, 2015 at 3:27 AM, Jonathan Wakely jwak...@redhat.com 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's the general
On Mon, Jul 27, 2015 at 4:45 AM, Jonathan Wakely jwak...@redhat.com 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_element(const _StringT __s)
{
auto
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 tims...@google.com 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 tims...@google.com
Date: Sun Jul 26 04
On Sat, Jul 25, 2015 at 12:11 AM, Tim Shen tims...@google.com 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? :/
Bootstrapped and tested.
Thanks
, but we should confirm with Jon.
--
Regards,
Tim Shen
()(__a.get(), nullptr);
+ return std::less_Tp_RE()(__a.get(), nullptr);
}
using _Tp_RE = typename shared_ptr_Tp::element_type;
--
Regards,
Tim Shen
conditionalis_array_Tp::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 tims...@google.com wrote:
On Wed, Nov 12, 2014 at 11:45 PM, Tim Shen tims...@google.com 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
On Mon, Apr 27, 2015 at 4:57 AM, Jonathan Wakely jwak...@redhat.com wrote:
OK for trunk.
Committed.
--
Regards,
Tim Shen
On Sat, Apr 25, 2015 at 1:10 AM, Tim Shen tims...@google.com 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 tims
On Tue, Feb 17, 2015 at 1:54 AM, Jonathan Wakely wrote:
On 16/02/15 22:10 +, 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
regex_constants::syntax_option_type::polynomial
On Fri, Mar 27, 2015 at 12:44 PM, Jonathan Wakely jwak...@redhat.com 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 testsuite_hooks.h,
Committed.
--
Regards,
Tim Shen
commit a1b32eec28442e38b830078ce3a9c142b1072647
Author
On Sun, Mar 15, 2015 at 11:27 PM, Tim Shen tims...@google.com wrote:
Here's the simple version of it.
Ping?
--
Regards,
Tim Shen
Wakely jwakely@gmail.com wrote:
On 15 March 2015 at 08:09, Tim Shen wrote:
Did a little bit refectoring on regex_constants, so that users won't
be polluted too much (they are not enum types anymore).
I think this is overengineered and unnecessary.
All it needs is something like:
enum
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 tims...@google.com
Date: Sat Mar 14 23:05:05
On Tue, Mar 10, 2015 at 7:24 AM, Jakub Jelinek ja...@redhat.com 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! :)
--
Regards,
Tim Shen
commit
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 tims...@google.com 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 tims...@google.com 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 tims...@google.com wrote:
Submitted version.
I think this patch fits 4.9 branch well?
--
Regards,
Tim Shen
-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
On Wed, Jan 21, 2015 at 9:08 PM, Tim Shen tims...@google.com wrote:
Fixed and committed.
Submitted version.
--
Regards,
Tim Shen
commit 62662ecc7defacdd82f9a9c6e62a563b4a094726
Author: timshen timshen@138bc75d-0d04-0410-961f-82ee72b054a4
Date: Thu Jan 22 05:02:38 2015 +
PR
On Wed, Jan 21, 2015 at 4:12 AM, Jonathan Wakely jwak...@redhat.com 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
1 - 100 of 328 matches
Mail list logo
