[Bug libstdc++/61601] C++11 regex resource exhaustion

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?

[Bug libstdc++/89927] Inconsistent behavior in std::regex when optimized

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

[Bug libstdc++/88947] regex_match doesn't fail early when given a non-matching pattern with a start-of-input anchor

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

[Bug libstdc++/88947] regex_match doesn't fail early when given a non-matching pattern with a start-of-input anchor

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

[Bug libstdc++/88947] regex_match doesn't fail early when given a non-matching pattern with a start-of-input anchor

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

[Bug libstdc++/63776] [C++11] Regex collate matching not working

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. :)

[Bug libstdc++/85824] regex constructor crashes under UTF-8 locale on Solaris SPARC when parsing a simple character class

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.

[Bug libstdc++/85824] regex constructor crashes under UTF-8 locale on Solaris SPARC when parsing a simple character class

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: > > ---

[Bug libstdc++/80187] C++ variant should be trivially copy constructible if possible

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80187 Tim Shen changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug libstdc++/85472] Regex match bug

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

[Bug libstdc++/85472] Regex match bug

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

[Bug libstdc++/85472] Regex match bug

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"

[Bug libstdc++/85472] Regex match bug

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

[Bug libstdc++/85472] Regex match bug

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

[Bug libstdc++/85472] Regex match bug

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).

[Bug libstdc++/85472] Regex match bug

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.

[Bug libstdc++/85472] Regex match bug

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.

[Bug libstdc++/85472] Regex match bug

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

[Bug libstdc++/84865] Regular expression regex_search falls into infinite loop causing segfault on crayxc machines

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

[Bug libstdc++/84865] Regular expression regex_search falls into infinite loop causing segfault on crayxc machines

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?

[Bug libstdc++/84865] Regular expression regex_search falls into infinite loop causing segfault on crayxc machines

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

[Bug libstdc++/83601] std::regex_replace C++14 conformance issue: escaping in SED mode

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83601 Tim Shen changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug libstdc++/83601] std::regex_replace C++14 conformance issue: escaping in SED mode

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=gcc=rev Log: PR libstdc++/83601 * include/bits/regex.tcc (regex_replace): Fix

[Bug libstdc++/83754] Segmentation fault in regex_search

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

[Bug libstdc++/71500] regex::icase only works on first character in a range

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=gcc=rev Log: PR libstdc++/71500 * include/bits/regex_executor.tcc: Support icase

[Bug libstdc++/80187] C++ variant should be trivially copy constructible if possible

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=gcc=rev Log: PR libstdc++/80187 * include/std/variant (variant::variant,

[Bug libstdc++/80187] C++ variant should be trivially copy constructible if possible

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

[Bug libstdc++/80187] C++ variant should be trivially copy constructible if possible

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

[Bug c++/80737] variant as class member resulting to compile errors

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=gcc=rev Log: PR libstdc++/80737 * include/std/variant(variant::variant): SFINAE on is_same

[Bug c++/80737] variant as class member resulting to compile errors

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

[Bug c++/80737] variant as class member resulting to compile errors

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

[Bug libstdc++/80737] variant as class member resulting to compile errors

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

[Bug libstdc++/80737] variant as class member resulting to compile errors

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

[Bug libstdc++/80187] C++ variant should be trivially copy constructible if possible

||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

[Bug libstdc++/79539] __polynomial mode lookahead still has an exponential behavior

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

[Bug libstdc++/79539] New: __polynomial mode lookahead still has an exponential behavior

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

[Bug libstdc++/78723] [variant] P0393r3: "Making variant greater equal again" is unimplemented

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78723 Tim Shen changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug libstdc++/78723] [variant] P0393r3: "Making variant greater equal again" is unimplemented

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=gcc=rev Log: PR libstdc++/78723 * include/std/variant (operator<(), operator>(),

[Bug libstdc++/79513] std::visit doesn't handle references

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79513 Tim Shen changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug libstdc++/79513] std::visit doesn't handle references

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=gcc=rev Log: PR libstdc++/79513 * include/std/variant (visit()): Forward variant

[Bug libstdc++/61582] C++11 regex memory corruption

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

[Bug libstdc++/78996] uses macro as name

||timshen at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from Tim Shen --- Mark as fixed.

[Bug libstdc++/78996] uses macro as name

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=gcc=rev Log: 2017-01-05 Tim Shen PR libstdc++/78996 *

[Bug libgcc/78759] New: __gcc_qadd could have been "more commutative" when a+c is infinity, but a+c+aa+cc is not

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, "

[Bug libstdc++/78723] [variant] P0393r3: "Making variant greater equal again" is unimplemented

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

[Bug libstdc++/78442] [variant] std::get<...>(Variant) is not constexpr.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78442 Tim Shen changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug libstdc++/71500] regex::icase only works on first character in a range

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=gcc=rev Log: PR libstdc++/71500 * include/bits/regex.h (basic_regex::basic_regex):

[Bug libstdc++/78441] [variant] variant_alternative doesn't allow cv qualifiers

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=gcc=rev Log: PR libstdc++/78441 * include/std/variant: Propagate cv qualifications

[Bug c++/78484] New: if-else chain is not turned into a local jump table

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 BarImpl

[Bug libstdc++/78442] [variant] std::get<...>(Variant) is not constexpr.

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

[Bug libstdc++/78236] regex_iterator constructor is incomplete and creates uninitialized values that may be used

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78236 Tim Shen changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug libstdc++/78276] regex_search is slow

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

[Bug libstdc++/78236] regex_iterator constructor is incomplete and creates uninitialized values that may be used

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

[Bug libstdc++/77944] FAIL: 20_util/variant/compile.cc (test for excess errors)

||timshen at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Tim Shen --- Mark as fixed.

[Bug libstdc++/77944] FAIL: 20_util/variant/compile.cc (test for excess errors)

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=gcc=rev Log: PR libstdc++/77944 * include/std/variant: include for __try and

[Bug libstdc++/77641] std::variant copy-initialization fails for type with non-trivial constexpr ctor

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=gcc=rev Log: PR libstdc++/77641 * include/std/variant

[Bug libstdc++/77492] std regex icase doesn't seem to work correctly.

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

[Bug libstdc++/77469] std::regex x("[b\\-a]") throws with message "Invalid range in bracket expression."

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77469 Tim Shen changed: What|Removed |Added CC||timshen at gcc dot gnu.org

[Bug libstdc++/77356] regex error for a ECMAScript syntax string

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77356 Tim Shen changed: What|Removed |Added CC||alban...@baker-research.com --- Comment #4

[Bug libstdc++/77356] regex error for a ECMAScript syntax string

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77356 Tim Shen changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug libstdc++/77356] regex error for a ECMAScript syntax string

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=gcc=rev Log: PR libstdc++/77356 *

[Bug middle-end/71614] ppc __gcc_qmul is mis-optimized not to be commutative

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; >

[Bug middle-end/71614] ppc __gcc_qmul is mis-optimized not to be commutative

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

[Bug middle-end/71614] New: ppc __gcc_qmul is mis-optimized not to be commutative

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=edit reduced c file The libgcc __gcc_qmul seems to be miscompiled. Supp

[Bug libstdc++/71500] regex::icase only works on first character in a range

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71500 Tim Shen changed: What|Removed |Added CC||john at johnmaddock dot co.uk --- Comment

[Bug libstdc++/71500] regex::icase only works on first character in a range

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)

[Bug libstdc++/71500] regex::icase only works on first character in a range

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

[Bug libstdc++/71500] regex::icase only works on first character in a range

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

[Bug libstdc++/71500] regex::icase only works on first character in a range

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

[Bug libstdc++/70745] Wrong handling of regex_constant::match_not_eow and regex_constant::match_not_bow

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=gcc=rev Log: PR libstdc++/70745 * include/bits/regex_executor.tcc

[Bug libstdc++/70745] Wrong handling of regex_constant::match_not_eow and regex_constant::match_not_bow

||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

[Bug libstdc++/70459] regex segfault on long sequences

||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 ***

[Bug libstdc++/61582] C++11 regex memory corruption

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61582 Tim Shen changed: What|Removed |Added CC||chaoskeeper at mail dot ru --- Comment #19

[Bug libstdc++/70411] Stack overflow with std::regex_match

||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 ***

[Bug libstdc++/61582] C++11 regex memory corruption

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

[Bug libstdc++/69794] [5/6 Regression] std::regex_search match failure with regex object with flags grep|icase

||timshen at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from Tim Shen --- Mark as fixed. Thanks for reporting!

[Bug libstdc++/69794] [5/6 Regression] std::regex_search match failure with regex object with flags grep|icase

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=gcc=rev Log: Backport from mainline 2016-02-16 Tim Shen

[Bug libstdc++/69794] [5/6 Regression] std::regex_search match failure with regex object with flags grep|icase

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=gcc=rev Log: 2016-02-16 Tim Shen PR libstdc++/69794 *

[Bug libstdc++/68863] Regular expressions: Backreferences don't work in negative lookahead

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68863 Tim Shen changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug libstdc++/68863] Regular expressions: Backreferences don't work in negative lookahead

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=gcc=rev Log: PR libstdc++/68863 * include/bits/regex_executor.tcc

[Bug libstdc++/68863] Regular expressions: Backreferences don't work in negative lookahead

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=gcc=rev Log: Backport from mainline 2015-12-15 Tim Shen

[Bug libstdc++/68863] Regular expressions: Backreferences don't work in negative lookahead

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=gcc=rev Log: Backport from mainline 2015-12-15 Tim Shen

[Bug libstdc++/68863] Regular expressions: Backreferences don't work in negative lookahead

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

[Bug libstdc++/68688] segmentation fault on regex matching long strings

||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

[Bug libstdc++/61582] C++11 regex memory corruption

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61582 Tim Shen changed: What|Removed |Added CC||kerukuro at gmail dot com --- Comment #17

[Bug libstdc++/68450] regex matching different from ECMAScript?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68450 Tim Shen changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed|

[Bug libstdc++/68032] std-c++-14: Regex fails to match

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

[Bug libstdc++/67361] std::regex_error::what() should say something about the error_code

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=gcc=rev Log: PR libstdc++/67361 * include/bits/regex_error.h: Add

[Bug libstdc++/67362] std::regex(((.), std::regex_constants::basic) throws

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67362 --- Comment #3 from Tim Shen timshen at gcc dot gnu.org --- Author: timshen Date: Fri Aug 28 03:39:53 2015 New Revision: 227291 URL: https://gcc.gnu.org/viewcvs?rev=227291root=gccview=rev Log: Backport from mainline 2015-08-28

[Bug libstdc++/67362] std::regex(((.), std::regex_constants::basic) throws

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67362 Tim Shen timshen at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED

[Bug libstdc++/67362] std::regex(((.), std::regex_constants::basic) throws

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67362 --- Comment #1 from Tim Shen timshen at gcc dot gnu.org --- Author: timshen Date: Fri Aug 28 02:35:21 2015 New Revision: 227289 URL: https://gcc.gnu.org/viewcvs?rev=227289root=gccview=rev Log: PR libstdc++/67362 * include/bits

[Bug libstdc++/67362] std::regex(((.), std::regex_constants::basic) throws

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67362 --- Comment #2 from Tim Shen timshen at gcc dot gnu.org --- Author: timshen Date: Fri Aug 28 03:03:55 2015 New Revision: 227290 URL: https://gcc.gnu.org/viewcvs?rev=227290root=gccview=rev Log: Backport from mainline 2015-08-28

[Bug libstdc++/67361] std::regex_error::what() should say something about the error_code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67361 Tim Shen timshen at gcc dot gnu.org changed: What|Removed |Added CC||timshen at gcc dot

[Bug libstdc++/67212] Infinite recurtion in std::regex_match

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67212 --- Comment #2 from Tim Shen timshen at gcc dot gnu.org --- 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

[Bug libstdc++/61582] C++11 regex memory corruption

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61582 Tim Shen timshen at gcc dot gnu.org changed: What|Removed |Added CC||morandidodo

[Bug libstdc++/66456] regex memory corruption on large input strings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66456 Tim Shen timshen at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED

[Bug libstdc++/67212] Infinite recurtion in std::regex_match

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67212 Tim Shen timshen at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED

[Bug libstdc++/61582] C++11 regex memory corruption

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61582 Tim Shen timshen at gcc dot gnu.org changed: What|Removed |Added CC||antialize at gmail

[Bug libstdc++/67015] ^[a-z0-9][a-z0-9-]*$, std::regex::extended is miscompiled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67015 --- Comment #12 from Tim Shen timshen at gcc dot gnu.org --- Author: timshen Date: Wed Aug 5 04:39:23 2015 New Revision: 226607 URL: https://gcc.gnu.org/viewcvs?rev=226607root=gccview=rev Log: Backported from mainline 2015-07-29

[Bug libstdc++/67015] ^[a-z0-9][a-z0-9-]*$, std::regex::extended is miscompiled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67015 Tim Shen timshen at gcc dot gnu.org changed: What|Removed |Added CC||redi at gcc dot

  1   2   >