Re: [Patch] Internal functions for testsuite in regex

2013-10-05 Thread Paolo Carlini 

On 10/05/2013 03:58 AM, Tim Shen wrote:

On Fri, Oct 4, 2013 at 12:30 PM, Paolo Carlini  wrote:

A completely different option, which I also like a lot in fact, would be
putting the new *_testsuite functions inside the already existing
testsuite/util/testsuite/regex.h. There you would use namespace __gnu_test,
would not require strict uglification, etc.

A good idea.
And excellent implementation ;) A few nits: I would not use "Abstract 
function...", because Abstract is a term of art in C++, something like 
Common is better; I would not use using namespace __detail in 
regex_match and regex_search, instead fully qualify (you never know with 
the damn name lookup issues (you know that in v3 as a general policy we 
always fully qualify in the implementation details)); _M_set_results is 
now smaller but it still includes a loop, let's keep it out of line; 
unrelated to the patch, I noticed for the first time that you have quite 
a few unsigned int and int, which always make me nervous, because the 
standards guarantee only 16 bits for those, thus unless you are sure 
that in practice only a few bits will be used, please consider using 
long and unsigned long instead.


Thanks!
Paolo.

Re: [Patch] Internal functions for testsuite in regex

2013-10-05 Thread Paolo Carlini 


Hi,

Tim Shen  ha scritto:
>Some are changed to size_t, some to long; some harmless ones are left.
>
>I'll do a bootstrap & full test before committing.

Patch looks great to me. If you don't get more comments over the next day or 
so, please go ahead.

Thanks!
Paolo

Re: Using gen_int_mode instead of GEN_INT minor testsuite fallout on MIPS

2013-10-05 Thread Oleg Endo 
On Fri, 2013-09-27 at 11:38 -0700, Mike Stump wrote:
> Can the sh people weigh in on this?  Are the PSI and PDI precisions 32 and 64?

PSI is used for representing FPSCR (floating point control register),
which has only max. 22 bits (as far as I know).

PDI is used on SH-5 for representing target address registers, which can
be anything between 32 and 64 bits (implementation defined, as far as I
understand).

> 
> On Sep 17, 2013, at 10:24 AM, Mike Stump  wrote:
> > On Sep 16, 2013, at 8:41 PM, DJ Delorie  wrote:
> >> m32c's PSImode is 24-bits, why does it have "32" in the macro?
> >> 
> >> /* 24-bit pointers, in 32-bit units */
> >> -PARTIAL_INT_MODE (SI);
> >> +PARTIAL_INT_MODE_NAME (SI, 32, PSI);
> > 
> > Sorry, fingers copied the wrong number.  Thanks for the catch.
> > 
> > 
>

[C++ Patch] PR 56060

2013-10-05 Thread Paolo Carlini 

Hi,

in this old (Jakub figured out it already existed in 2007!) ICE on 
invalid, the problem happens in type_dependent_expression_p: the code 
for unknown_type_node as TREE_TYPE of the expression doesn't handle 
EXPR_PACK_EXPANSION as TREE_CODE.


It seems to me that we simply have to look inside the expression via 
PACK_EXPANSION_PATTERN: in the testcase, for "bar ..." as expression 
the _PATTERN is a TEMPLATE_ID_EXPR which then is normally handled. 
Tested x86_64-linux.


Thanks,
Paolo.


/cp
2013-10-06  Paolo Carlini  

PR c++/56060
* pt.c (type_dependent_expression_p): Handle EXPR_PACK_EXPANSION.

/testsuite
2013-10-06  Paolo Carlini  

PR c++/56060
* g++.dg/cpp0x/variadic144.C: New.
Index: cp/pt.c
===
--- cp/pt.c (revision 203219)
+++ cp/pt.c (working copy)
@@ -20405,6 +20405,8 @@ type_dependent_expression_p (tree expression)
 
   if (BASELINK_P (expression))
expression = BASELINK_FUNCTIONS (expression);
+  else if (TREE_CODE (expression) == EXPR_PACK_EXPANSION)
+   expression = PACK_EXPANSION_PATTERN (expression);
 
   if (TREE_CODE (expression) == TEMPLATE_ID_EXPR)
{
Index: testsuite/g++.dg/cpp0x/variadic144.C
===
--- testsuite/g++.dg/cpp0x/variadic144.C(revision 0)
+++ testsuite/g++.dg/cpp0x/variadic144.C(working copy)
@@ -0,0 +1,15 @@
+// PR c++/56060
+// { dg-do compile { target c++11 } }
+
+template struct baz { };
+template T bar();
+
+template
+baz()(bar ...))>  // { dg-error "cannot be used" }
+foo();
+
+int main()
+{
+  foo(); // { dg-error "no matching" }
+  return 0;
+}

[Patch] Fix COMPILE error in regex and remove default parameter in function definition

2013-10-05 Thread Tim Shen 
Stupid errors hidden in some large commit.

I don't think they will break boostrap?

Thanks!


-- 
Tim Shen


a.patch
Description: Binary data