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
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=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=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 #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=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=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=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=80187
Tim Shen changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=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 #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 #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 #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 #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 #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 #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
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
--- 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=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
Tim Shen changed:
What|Removed |Added
CC||timshen at gcc dot gnu.org
--- Comment #5
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=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=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=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=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
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 #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=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=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 #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 #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
Tim Shen changed:
What|Removed |Added
CC||timshen at gcc dot gnu.org
--- Comment #2
||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=79539
Tim Shen changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |timshen at gcc dot
gnu.org
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=78723
Tim Shen changed:
What|Removed |Added
Status|ASSIGNED|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=79513
Tim Shen changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=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
||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=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
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=78723
Tim Shen changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |timshen at gcc dot
gnu.org
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=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=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
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=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=78236
Tim Shen changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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
CC||timshen at gcc dot gnu.org
--- Comment #2
||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=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
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=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=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=77356
Tim Shen changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77356
--- Comment #2 from Tim Shen ---
Author: timshen
Date: Sat Aug 27 02:03:23 2016
New Revision: 239794
URL: https://gcc.gnu.org/viewcvs?rev=239794&root=gcc&view=rev
Log:
PR libstdc++/77356
* include/bits/regex_compiler.tcc(_M_inser
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71614
--- Comment #3 from Tim Shen ---
(In reply to Andrew Pinski from comment #2)
> Two things, try -fno-strict-aliasing first.
> Since your main violates C aliasing rules.
> Second thing to try is -ffp-contract=off as I am suspecting:
> v = a*d;
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71614
--- Comment #1 from Tim Shen ---
> Suppose the attached file is a.c
s/a\.c/b.c
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: timshen at gcc dot gnu.org
Target Milestone: ---
Created attachment 38741
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38741&action=edit
reduced c file
The libgcc __gcc_qmul seems to be misc
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 #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
--- 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 #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
Tim Shen changed:
What|Removed |Added
CC||timshen at gcc dot gnu.org
--- Comment #2
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
||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
||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 ***
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 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||bisqwit at iki dot fi
--- Comment #18 from Ti
||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=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
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=68863
Tim Shen changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68863
--- Comment #4 from Tim Shen ---
Author: timshen
Date: Tue Dec 15 05:59:01 2015
New Revision: 231643
URL: https://gcc.gnu.org/viewcvs?rev=231643&root=gcc&view=rev
Log:
Backport from mainline
2015-12-15 Tim Shen
PR lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68863
--- Comment #3 from Tim Shen ---
Author: timshen
Date: Tue Dec 15 05:19:20 2015
New Revision: 231642
URL: https://gcc.gnu.org/viewcvs?rev=231642&root=gcc&view=rev
Log:
Backport from mainline
2015-12-15 Tim Shen
PR lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68863
--- Comment #2 from Tim Shen ---
Author: timshen
Date: Tue Dec 15 04:50:29 2015
New Revision: 231641
URL: https://gcc.gnu.org/viewcvs?rev=231641&root=gcc&view=rev
Log:
PR libstdc++/68863
* include/bits/regex_executor.tcc (_Execut
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68863
Tim Shen changed:
What|Removed |Added
CC||timshen at gcc dot gnu.org
--- Comment #1
||timshen at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #1 from Tim Shen ---
This is a known issue, that is the regex engine uses stack frame (through deep
recursion, rather than heap storage) to store data. I plan to fix it after a
series of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61582
Tim Shen changed:
What|Removed |Added
CC||kerukuro at gmail dot com
--- Comment #17 fro
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=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=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=67362
Tim Shen changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67362
--- Comment #3 from Tim Shen ---
Author: timshen
Date: Fri Aug 28 03:39:53 2015
New Revision: 227291
URL: https://gcc.gnu.org/viewcvs?rev=227291&root=gcc&view=rev
Log:
Backport from mainline
2015-08-28 Tim Shen
PR lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67362
--- Comment #2 from Tim Shen ---
Author: timshen
Date: Fri Aug 28 03:03:55 2015
New Revision: 227290
URL: https://gcc.gnu.org/viewcvs?rev=227290&root=gcc&view=rev
Log:
Backport from mainline
2015-08-28 Tim Shen
PR lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67362
--- Comment #1 from Tim Shen ---
Author: timshen
Date: Fri Aug 28 02:35:21 2015
New Revision: 227289
URL: https://gcc.gnu.org/viewcvs?rev=227289&root=gcc&view=rev
Log:
PR libstdc++/67362
* include/bits/regex_scanner.tcc (_Scanner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67361
Tim Shen changed:
What|Removed |Added
CC||timshen at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67212
--- Comment #2 from Tim Shen ---
This isn't an "infinite" recursion, but just a deep one. I haven't implement
heap allocation and manual recursion yet. In the mean time, you may compile
your code with -O2 (tail recursion elimination may help), se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61582
Tim Shen changed:
What|Removed |Added
CC||antialize at gmail dot com
--- Comment #16 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67212
Tim Shen changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66456
Tim Shen changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61582
Tim Shen changed:
What|Removed |Added
CC||morandidodo at gmail dot com
--- Comment #15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67015
--- Comment #12 from Tim Shen ---
Author: timshen
Date: Wed Aug 5 04:39:23 2015
New Revision: 226607
URL: https://gcc.gnu.org/viewcvs?rev=226607&root=gcc&view=rev
Log:
Backported from mainline
2015-07-29 Tim Shen
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67015
Tim Shen changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
--- Comment #8 from T
1 - 100 of 184 matches
Mail list logo