On Thu, Jul 10, 2014 at 12:57 AM, Paolo Carlini
wrote:
> On 07/10/2014 06:30 AM, Tim Shen wrote:
>>
>> Here's the sane patch :)
>
> Ok, thanks!
Tested and committed.
Thanks!
--
Regards,
Tim Shen
On 07/10/2014 06:30 AM, Tim Shen wrote:
Here's the sane patch :)
Ok, thanks!
Paolo.
On Wed, Jul 9, 2014 at 1:23 AM, Jonathan Wakely wrote:
> I can't actually reproduce the bug with trunk.
It's a BFS executor bug, so we need to #define
_GLIBCXX_REGEX_USE_THOMPSON_NFA (or use regex_search_debug instead)
and use styles other than ECMAScript.
I didn't notice that it's not a good id
On 9 July 2014 18:33, Mike Stump wrote:
> The other limit is how big the resulting program is. Too large, and it won’t
> test on a small memory system. Under a meg, and most people don’t care. As
> it climbs above that it starts mattering more.
If the test is driven by a data file containing
On Jul 9, 2014, at 12:48 AM, Paolo Carlini wrote:
>
> On 07/09/2014 03:53 AM, Tim Shen wrote:
>> +// This file is for general testcases in regex.
>> +// We use a single file for multiple testcases because it takes too long to
>> +// compile regex for each testcase in a single file.
>> +// Normal
On Wed, Jul 09, 2014 at 09:08:40AM +0100, Jonathan Wakely wrote:
> >Thus the plan would be *all* the regex testcases in a single file!?! If I
> >understand correctly, that certainly doesn't make sense. In any
>
> Jakub pointed out that there are lots of useful tests for regexes in
> the glibc test
On 09/07/14 10:10 +0200, Paolo Carlini wrote:
Hi,
On 07/09/2014 10:08 AM, Jonathan Wakely wrote:
All the 28_regex tests run as part of the same target:
normal7) \
dirs="`cd $$srcdir; echo 26_*/* 28_*/[c-z]*`";; \
I've tried moving the 26_numeric tests to a different target b
Hi,
On 07/09/2014 10:08 AM, Jonathan Wakely wrote:
All the 28_regex tests run as part of the same target:
normal7) \
dirs="`cd $$srcdir; echo 26_*/* 28_*/[c-z]*`";; \
I've tried moving the 26_numeric tests to a different target but it
doesn't make much difference, the regex
On 09/07/14 09:48 +0200, Paolo Carlini wrote:
Hi,
On 07/09/2014 03:53 AM, Tim Shen wrote:
+// This file is for general testcases in regex.
+// We use a single file for multiple testcases because it takes too long to
+// compile regex for each testcase in a single file.
+// Normal testcases in o
On 08/07/14 18:53 -0700, Tim Shen wrote:
+// libstdc++/61720
+void
+PR61720()
+{
+ bool test __attribute__((unused)) = true;
+
+ string test = R"("test\")";
Does this compile?
You've redeclared 'test'
Hi,
On 07/09/2014 03:53 AM, Tim Shen wrote:
+// This file is for general testcases in regex.
+// We use a single file for multiple testcases because it takes too long to
+// compile regex for each testcase in a single file.
+// Normal testcases in other files should be moved into this file in th
On Mon, Jul 7, 2014 at 1:24 AM, Paolo Carlini wrote:
> Bah... too bad we have to resort to this. Then please summarize the
> discussion at the beginning of the file: what the file is *exactly* for (an
> accidental contributor should be able to understand if and what should go in
> it) and why it d
Hi,
On 07/06/2014 08:20 PM, Tim Shen wrote:
I'd like to merge testcases to several huge files (char, wchar_t,
dg-do compile, locales, etc.) to (greatly) reduce duplicated
compilation.
We do not really care the fine-grained test report, do we? We hope
them all PASS.
Yes. As long as it's possib
On Sun, Jul 6, 2014 at 7:08 AM, Paolo Carlini wrote:
> Patch itself looks obvious to me, but I don't understand the
> general_testcases.cc idea, do we have something similar elsewhere in library
> or compiler?!? I would say, let's just add a normal testcase and close the
> bug (mainline and branch
Hi,
On 07/06/2014 10:56 AM, Tim Shen wrote:
This bug shouldn't be introduced, if I wrote clearer code last summer.
Sorry :(. The _Executor is a little bit messy. The _M_match_queue is
not cleared because it's treated `globally` between iterations (in
_M_main_dispatch(..., __bfs)).
Add a new fil
On Sun, Jul 6, 2014 at 1:56 AM, Tim Shen wrote:
> This bug shouldn't be introduced, if I wrote clearer code last summer.
> Sorry :(. The _Executor is a little bit messy. The _M_match_queue is
> not cleared because it's treated `globally` between iterations (in
> _M_main_dispatch(..., __bfs)).
>
>
16 matches
Mail list logo
