https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61601
--- Comment #10 from Tim Shen ---
(In reply to Eric Gallager from comment #9)
> (In reply to Tim Shen from comment #7)
> > (In reply to Maksymilian Arciemowicz from comment #6)
> > > > Do you have any other testcases?
> > >
> > > for trunk? mayb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57513
timshen at gcc dot gnu.org changed:
What|Removed |Added
CC||timshen at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58576
--- Comment #4 from Tim Shen ---
Author: timshen
Date: Tue Oct 1 15:26:50 2013
New Revision: 203067
URL: http://gcc.gnu.org/viewcvs?rev=203067&root=gcc&view=rev
Log:
2013-10-01 Tim Shen
PR libstdc++/58576
* include/bits/regex_automat
||timshen at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #17 from Tim Shen ---
Now regex is implemented. Should come with GCC 4.9 :)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58886
Tim Shen changed:
What|Removed |Added
CC||timshen at gcc dot gnu.org
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58886
--- Comment #4 from Tim Shen ---
(In reply to Paolo Carlini from comment #3)
> Do we have any idea about Visual C++ and clang++? If this kind of extension
> is really popular we may want to include it under gnu++11 only, like we did
> another time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88947
--- Comment #3 from Tim Shen ---
Thanks for reporting Tomalak.
Yes, I agree that "match from the first character" should be expressable in the
public interface, preferrably regex_search() with "^...". In fact, internally
regex_search is implemen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88947
--- Comment #5 from Tim Shen ---
(In reply to Tomalak Geret'kal from comment #4)
> To be honest I'd expect this in less trivial circumstances too. If, at a
> given stage of processing, the only possible paths towards a match all
> require a prefi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88947
--- Comment #6 from Tim Shen ---
(In reply to Tomalak Geret'kal from comment #4)
> To be honest I'd expect this in less trivial circumstances too. If, at a
> given stage of processing, the only possible paths towards a match all
> require a prefi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85472
Tim Shen changed:
What|Removed |Added
CC||timshen at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85472
--- Comment #2 from Tim Shen ---
My bad, I didn't realize that "(z)((a+)?(b+)?(c))*" is exactly an example
described in ECMAScript third edition 15.10.2.5. Therefore libstdc++ is not
conforming.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85472
--- Comment #3 from Tim Shen ---
Conclusively, yes it is a bug, but it is hard to fix without regressing normal
case performance.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85472
--- Comment #5 from Tim Shen ---
(In reply to Hans Åberg from comment #4)
> (In reply to Tim Shen from comment #1)
> > I know exactly how libc++ produces this result. It creates an empty
> > match_result during each repetition ("*" operator). It'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85472
--- Comment #9 from Tim Shen ---
Ah with the example it's clear, thanks!
> The last line gives for #1 the sub-string "z" , and for #2 "aacbbbcac".
This is not what ECMAScript produces either. for capture #2, ECMAScriptn
produces "ac", the last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85472
--- Comment #11 from Tim Shen ---
> The problem is that #4 has an earlier capture, making it impossible to see
> that it is left undefined later.
I wouldn't say it's impossible. libc++ implements it correctly at a cost.
Specifically, see
https:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85472
--- Comment #14 from Tim Shen ---
How fast does your prototype run on the following example?
((10)|(11)|(12)|...|(98)|(99))* matching "10111213141516...9899"
how about this:
((100)|(101)|(102)|...|(998)|(999))* matching "100101102...998999"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85472
--- Comment #16 from Tim Shen ---
(In reply to Hans Åberg from comment #15)
> (In reply to Tim Shen from comment #14)
> > How fast does your prototype run on the following example?
> > ((10)|(11)|(12)|...|(98)|(99))* matching "10111213141516...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85472
--- Comment #20 from Tim Shen ---
(In reply to Hans Åberg from comment #18)
> (In reply to Tim Shen from comment #14)
> > I have a C++ test case for this:
>
> I get segmentation fault on the regex_match line with g++ 7.3.0.
On Linux I set "ulim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80187
Tim Shen changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85824
--- Comment #5 from Tim Shen ---
(In reply to Jonathan Wakely from comment #4)
> Tim, I'll take care of checking errno in collate<>::_M_transform but could
> you advise what to do about the regex compiler? Maybe:
>
> --- a/libstdc++-v3/include/b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85824
--- Comment #6 from Tim Shen ---
(In reply to Tim Shen from comment #5)
> First of all, std::regex("[0-9]") shouldn't be locale sensitive, as
> regex_constants::collate is set.
Correction: as regex_constants::collate is *not* set.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83754
Tim Shen changed:
What|Removed |Added
CC||timshen at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83601
--- Comment #2 from Tim Shen ---
Author: timshen
Date: Sun Jan 14 00:48:30 2018
New Revision: 256654
URL: https://gcc.gnu.org/viewcvs?rev=256654&root=gcc&view=rev
Log:
PR libstdc++/83601
* include/bits/regex.tcc (regex_replace):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83601
Tim Shen changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89927
Tim Shen changed:
What|Removed |Added
CC||timshen at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84865
Tim Shen changed:
What|Removed |Added
CC||timshen at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84865
--- Comment #6 from Tim Shen ---
Will you able to provide a stack trace and/or ulimit information?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84865
--- Comment #9 from Tim Shen ---
I see. Can you show the ulimit *stack* information? I believe it's -s.
Also, try -O2 so that the functions are inlined.
As for the stack overflow, it's a known issue. To workaround this, please set a
bigger stac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63776
--- Comment #12 from Tim Shen ---
I'm not sure anymore about the meaning of pinging back end (my bad), but
> But this is (assuming wchar_t uses a unicode encoding):
The two pieces of code looks identical to me. :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69794
--- Comment #3 from Tim Shen ---
Author: timshen
Date: Wed Feb 17 03:33:02 2016
New Revision: 233482
URL: https://gcc.gnu.org/viewcvs?rev=233482&root=gcc&view=rev
Log:
2016-02-16 Tim Shen
PR libstdc++/69794
* include/bits/reg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69794
--- Comment #4 from Tim Shen ---
Author: timshen
Date: Wed Feb 17 04:38:15 2016
New Revision: 233483
URL: https://gcc.gnu.org/viewcvs?rev=233483&root=gcc&view=rev
Log:
Backport from mainline
2016-02-16 Tim Shen
PR lib
||timshen at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #5 from Tim Shen ---
Mark as fixed.
Thanks for reporting!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61582
Tim Shen changed:
What|Removed |Added
CC||bisqwit at iki dot fi
--- Comment #18 from Ti
||timshen at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #2 from Tim Shen ---
This is a known issue. I have a plan to fix it, but it's not going to be in GCC
6.
Thanks for reporting!
*** This bug has been marked as a duplicate of bug 61582 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61582
Tim Shen changed:
What|Removed |Added
CC||chaoskeeper at mail dot ru
--- Comment #19 fr
||timshen at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #2 from Tim Shen ---
This is a known issue. I plan to fix it, but it's not going to be in GCC 6.
Thanks for reporting!
*** This bug has been marked as a duplicate of bug 61582 ***
||2016-04-21
CC||timshen at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Tim Shen ---
Looking at the history I noticed that it was handled correctly, but later get
changed to the current incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70745
--- Comment #2 from Tim Shen ---
Author: timshen
Date: Sat Apr 23 03:58:37 2016
New Revision: 235382
URL: https://gcc.gnu.org/viewcvs?rev=235382&root=gcc&view=rev
Log:
PR libstdc++/70745
* include/bits/regex_executor.tcc (_Execut
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71500
Tim Shen changed:
What|Removed |Added
CC||timshen at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71500
--- Comment #4 from Tim Shen ---
(In reply to Michael Duggan from comment #3)
> regex re1 = regex("[T-f]+", regex::icase);
This regex actually doesn't compile in Boost, since boost interpret icase as
"transforming [T-f] to [t-f]", then throw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71500
--- Comment #6 from Tim Shen ---
(In reply to mwd from comment #5)
> All of the ECMAScript engines I have found work with this , and the
> ECMAScript specs seem to imply that this should work as well.
I think you are right.
According to ECMAScr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71500
--- Comment #8 from Tim Shen ---
(In reply to Michael Duggan from comment #7)
> Hmm... Okay. For the sake of argument, I am going to make the
> following claims:
Yeah, thanks for the arguments, we should at least get this clear.
> a) Ignorin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71500
Tim Shen changed:
What|Removed |Added
CC||john at johnmaddock dot co.uk
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71500
--- Comment #16 from Tim Shen ---
Author: timshen
Date: Mon Sep 11 19:02:34 2017
New Revision: 251982
URL: https://gcc.gnu.org/viewcvs?rev=251982&root=gcc&view=rev
Log:
PR libstdc++/71500
* include/bits/regex_executor.tcc: Suppor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80737
Tim Shen changed:
What|Removed |Added
CC||timshen at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80737
--- Comment #3 from Tim Shen ---
(In reply to TC from comment #1)
> Looks like the constraint on the convert-everything constructor needs to
> check for is_same, variant> first and short circuit if that's
> true.
I'm not quite sure whether we ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80737
--- Comment #4 from Tim Shen ---
(In reply to Tim Shen from comment #3)
> (In reply to TC from comment #1)
> > Looks like the constraint on the convert-everything constructor needs to
> > check for is_same, variant> first and short circuit if tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80737
--- Comment #6 from Tim Shen ---
(In reply to TC from comment #5)
> (In reply to Tim Shen from comment #3)
> > (In reply to TC from comment #1)
> > > Looks like the constraint on the convert-everything constructor needs to
> > > check for is_same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80737
--- Comment #7 from Tim Shen ---
Author: timshen
Date: Sun May 28 21:27:30 2017
New Revision: 248548
URL: https://gcc.gnu.org/viewcvs?rev=248548&root=gcc&view=rev
Log:
PR libstdc++/80737
* include/std/variant(variant::variant): SFINAE on is_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80187
--- Comment #2 from Tim Shen ---
(In reply to Tim Shen from comment #1)
> Assign to myself.
>
> Implementation idea:
> https://godbolt.org/g/ulh4V7
The experiment failed, therefore I posted a patch (see the list) to do the
4-layer inheritance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80187
--- Comment #5 from Tim Shen ---
(In reply to Ambroz Bizjak from comment #4)
> Oh wait sorry, that doesn't solve it (yet), the variant_storage_byte would
> still have a default copy constructor that copies the byte member.
Yeah, your solution se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80187
--- Comment #6 from Tim Shen ---
Author: timshen
Date: Tue Jun 27 18:19:03 2017
New Revision: 249706
URL: https://gcc.gnu.org/viewcvs?rev=249706&root=gcc&view=rev
Log:
PR libstdc++/80187
* include/std/variant (variant::variant, v
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: timshen at gcc dot gnu.org
Target Milestone: ---
Convenient link: https://godbolt.org/g/AEYMwC
The following C++ code is slow, since it's not turned into a jump table:
template
void Foo();
template
struct Ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78441
--- Comment #1 from Tim Shen ---
Author: timshen
Date: Sun Nov 27 00:32:04 2016
New Revision: 242892
URL: https://gcc.gnu.org/viewcvs?rev=242892&root=gcc&view=rev
Log:
PR libstdc++/78441
* include/std/variant: Propagate cv qualif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71500
--- Comment #13 from Tim Shen ---
Author: timshen
Date: Thu Dec 1 03:03:55 2016
New Revision: 243093
URL: https://gcc.gnu.org/viewcvs?rev=243093&root=gcc&view=rev
Log:
PR libstdc++/71500
* include/bits/regex.h (basic_regex::basi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78442
Tim Shen changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78723
Tim Shen changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |timshen at gcc dot
gnu.org
NCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: timshen at gcc dot gnu.org
Target Milestone: ---
#include
#include
#include
#include
int main() {
static_assert(sizeof(long double) == 16, "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78996
--- Comment #2 from Tim Shen ---
Author: timshen
Date: Thu Jan 5 03:18:17 2017
New Revision: 244092
URL: https://gcc.gnu.org/viewcvs?rev=244092&root=gcc&view=rev
Log:
2017-01-05 Tim Shen
PR libstdc++/78996
* include/std/vari
||timshen at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #3 from Tim Shen ---
Mark as fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61582
--- Comment #21 from Tim Shen ---
(In reply to Pádraig Brady from comment #20)
> Any status update on this. GCC7 is looming...
> Thanks.
Unfortunately I haven't get a chance to work on this. I plan to put up a
one-line tweak on the internal stat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79513
--- Comment #1 from Tim Shen ---
Author: timshen
Date: Wed Feb 15 07:38:20 2017
New Revision: 245474
URL: https://gcc.gnu.org/viewcvs?rev=245474&root=gcc&view=rev
Log:
PR libstdc++/79513
* include/std/variant (visit()): Forward v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79513
Tim Shen changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78723
--- Comment #4 from Tim Shen ---
Author: timshen
Date: Wed Feb 15 09:01:06 2017
New Revision: 245475
URL: https://gcc.gnu.org/viewcvs?rev=245475&root=gcc&view=rev
Log:
PR libstdc++/78723
* include/std/variant (operator<(), operat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78723
Tim Shen changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: timshen at gcc dot gnu.org
Target Milestone: ---
Lookahead is implemented in terms of non-memoized recursion, which may have
exponential behavior.
In __polynomial mode, we can add a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79539
Tim Shen changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |timshen at gcc dot
gnu.org
||2017-03-26
CC||timshen at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |timshen at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Tim Shen ---
Assign to myself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77469
Tim Shen changed:
What|Removed |Added
CC||timshen at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77356
Tim Shen changed:
What|Removed |Added
CC||alban...@baker-research.com
--- Comment #4 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77492
Tim Shen changed:
What|Removed |Added
CC||timshen at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77641
--- Comment #4 from Tim Shen ---
Author: timshen
Date: Thu Sep 22 03:15:58 2016
New Revision: 240340
URL: https://gcc.gnu.org/viewcvs?rev=240340&root=gcc&view=rev
Log:
PR libstdc++/77641
* include/std/variant (_Variant_storage::_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77944
--- Comment #1 from Tim Shen ---
Author: timshen
Date: Fri Oct 14 09:58:05 2016
New Revision: 241153
URL: https://gcc.gnu.org/viewcvs?rev=241153&root=gcc&view=rev
Log:
PR libstdc++/77944
* include/std/variant: include for __try
||timshen at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #2 from Tim Shen ---
Mark as fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78236
Tim Shen changed:
What|Removed |Added
CC||timshen at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78276
Tim Shen changed:
What|Removed |Added
CC||timshen at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78236
Tim Shen changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78442
Tim Shen changed:
What|Removed |Added
CC||timshen at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61227
--- Comment #5 from Tim Shen ---
Author: timshen
Date: Tue May 20 04:31:54 2014
New Revision: 210630
URL: http://gcc.gnu.org/viewcvs?rev=210630&root=gcc&view=rev
Log:
2014-05-20 Tim Shen
PR libstdc++/61227
* include/bits/regex_compil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61424
--- Comment #2 from Tim Shen ---
Sorry, the preference of results of "|" is actually arbitrary. I'll fix it
later.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61582
--- Comment #7 from Tim Shen ---
"(.*{100}{100}{100})" seems to be a stack overflow. It's because regex executor
uses recursion. It could be fixed (not segfault but memory exhaustion) by using
a std::stack and simulate recursion; IMH, however, di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61601
--- Comment #2 from Tim Shen ---
(In reply to Jonathan Wakely from comment #1)
> Tim, how hard would it be to hardcode limits somewhere for these cases?
It's easy. 6 lines. I'll propose a patch soon.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61582
--- Comment #9 from Tim Shen ---
(In reply to Maksymilian Arciemowicz from comment #8)
> (In reply to Tim Shen from comment #7)
> > "(.*{100}{100}{100})" seems to be a stack overflow. It's because regex
> > executor uses recursion. It could be fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64441
--- Comment #4 from Tim Shen ---
Author: timshen
Date: Tue Mar 10 18:41:46 2015
New Revision: 221330
URL: https://gcc.gnu.org/viewcvs?rev=221330&root=gcc&view=rev
Log:
PR libstdc++/64441
* include/bits/regex.h (match_results<>::size,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64441
Tim Shen changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65420
--- Comment #1 from Tim Shen ---
Author: timshen
Date: Sat Mar 28 04:17:12 2015
New Revision: 221750
URL: https://gcc.gnu.org/viewcvs?rev=221750&root=gcc&view=rev
Log:
PR libstdc++/65420
* include/bits/regex_constants.h: Use constexpr va
||2015-06-01
CC||timshen at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Tim Shen ---
Thanks for reporting! gcc 5.1 works fine to me:
~ % /usr/bin/g++ --version
g++ (GCC
iority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: timshen at gcc dot gnu.org
The following piece of code causes a gcc segmentation fault:
// test.cc
#pragma GCC optimize ("O2")
#include
template class std::basic_regex;
The backtrace info:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67361
--- Comment #3 from Tim Shen ---
Author: timshen
Date: Sat Sep 19 20:56:27 2015
New Revision: 227936
URL: https://gcc.gnu.org/viewcvs?rev=227936&root=gcc&view=rev
Log:
PR libstdc++/67361
* include/bits/regex_error.h: Add __throw_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68032
Tim Shen changed:
What|Removed |Added
CC||timshen at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68450
Tim Shen changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64441
--- Comment #1 from Tim Shen ---
Author: timshen
Date: Wed Dec 31 10:27:41 2014
New Revision: 219121
URL: https://gcc.gnu.org/viewcvs?rev=219121&root=gcc&view=rev
Log:
PR libstdc++/64441
* include/bits/regex.tcc (__regex_algo_impl): s/au
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64475
--- Comment #4 from Tim Shen ---
Author: timshen
Date: Fri Jan 2 22:33:04 2015
New Revision: 219151
URL: https://gcc.gnu.org/viewcvs?rev=219151&root=gcc&view=rev
Log:
PR libstdc++/64475
* include/bits/regex_executor.tcc (_Executor<>::_M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64239
--- Comment #8 from Tim Shen ---
Author: timshen
Date: Fri Jan 9 03:58:59 2015
New Revision: 219373
URL: https://gcc.gnu.org/viewcvs?rev=219373&root=gcc&view=rev
Log:
PR libstdc++/64239
* include/bits/regex.h (match_results<>::swap): Us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64239
--- Comment #9 from Tim Shen ---
Author: timshen
Date: Fri Jan 9 05:52:18 2015
New Revision: 219374
URL: https://gcc.gnu.org/viewcvs?rev=219374&root=gcc&view=rev
Log:
PR libstdc++/64239
Backported form mainline
2015-01-09 Tim Shen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64584
--- Comment #1 from Tim Shen ---
Author: timshen
Date: Mon Jan 19 22:56:04 2015
New Revision: 219865
URL: https://gcc.gnu.org/viewcvs?rev=219865&root=gcc&view=rev
Log:
PR libstdc++/64584
PR libstdc++/64585
* include/bits/regex.h (bas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64585
--- Comment #1 from Tim Shen ---
Author: timshen
Date: Mon Jan 19 22:56:04 2015
New Revision: 219865
URL: https://gcc.gnu.org/viewcvs?rev=219865&root=gcc&view=rev
Log:
PR libstdc++/64584
PR libstdc++/64585
* include/bits/regex.h (bas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64649
--- Comment #2 from Tim Shen ---
Author: timshen
Date: Mon Jan 19 23:00:13 2015
New Revision: 219866
URL: https://gcc.gnu.org/viewcvs?rev=219866&root=gcc&view=rev
Log:
PR libstdc++/64649
* include/bits/regex.tcc (regex_traits<>::lookup_c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64585
--- Comment #2 from Tim Shen ---
Author: timshen
Date: Mon Jan 19 23:09:07 2015
New Revision: 219868
URL: https://gcc.gnu.org/viewcvs?rev=219868&root=gcc&view=rev
Log:
PR libstdc++/64584
PR libstdc++/64585
* include/bits/regex.h (bas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64584
--- Comment #2 from Tim Shen ---
Author: timshen
Date: Mon Jan 19 23:09:07 2015
New Revision: 219868
URL: https://gcc.gnu.org/viewcvs?rev=219868&root=gcc&view=rev
Log:
PR libstdc++/64584
PR libstdc++/64585
* include/bits/regex.h (bas
1 - 100 of 184 matches
Mail list logo
