Re: [C++ Patch] PR 53301

2012-05-12 Thread Paolo Carlini
On 05/12/2012 04:55 AM, Jason Merrill wrote: On 05/11/2012 06:03 AM, Paolo Carlini wrote: if (TYPE_PTR_P (type) && !TYPE_PTRFN_P (type) - && !TYPE_PTR_TO_MEMBER_P (type)) + && !TYPE_PTRMEM_P (type)) The check for !pointer to member is no longer necessary, since they don't use POINT

Re: [C++ Patch] PR 53301

2012-05-11 Thread Jason Merrill
On 05/11/2012 06:03 AM, Paolo Carlini wrote: if (TYPE_PTR_P (type) && !TYPE_PTRFN_P (type) - && !TYPE_PTR_TO_MEMBER_P (type)) + && !TYPE_PTRMEM_P (type)) The check for !pointer to member is no longer necessary, since they don't use POINTER_TYPE. OK with that ch

Re: [C++ Patch] PR 53301

2012-05-11 Thread Paolo Carlini
... for concreteness, this is something which actually boots and passes testing on x86_64-linux for the affected languages. I like it ;) Thanks, Paolo. Index: doc/generic.texi === --- doc/generic.texi(r

Re: [C++ Patch] PR 53301

2012-05-11 Thread Paolo Carlini
Hi, On 05/11/2012 06:41 AM, Jason Merrill wrote: On 05/10/2012 05:31 PM, Paolo Carlini wrote: Let's see if we can do something *now* ;) My concrete proposal would be: TYPE_PTRMEM_P rename to TYPE_PTRDATAMEM_P (consistent with TYPE_PTRMEMFUNC_P) TYPE_PTR_TO_MEMBER_P rename to TYPE_PTRMEM_P and

Re: [C++ Patch] PR 53301

2012-05-10 Thread Jason Merrill
On 05/10/2012 05:31 PM, Paolo Carlini wrote: Let's see if we can do something *now* ;) My concrete proposal would be: TYPE_PTRMEM_P rename to TYPE_PTRDATAMEM_P (consistent with TYPE_PTRMEMFUNC_P) TYPE_PTR_TO_MEMBER_P rename to TYPE_PTRMEM_P and then finally #define TYPE_PTR_OR_PTRMEM_P(NODE) \

Re: [C++ Patch] PR 53301

2012-05-10 Thread Paolo Carlini
Hi, Yes, please. It feels as if the names are based more on the underlying implementation of the macro than on anything else. Also, short names are nice, but using MEM instead of MEMBER is a bit too short. The same for OB for object and others. PTR_OR_PTRMEM sounds to me like "pointer or pointer

Re: [C++ Patch] PR 53301

2012-05-10 Thread Manuel López-Ibáñez
On 10 May 2012 17:02, Paolo Carlini wrote: > Hi, > >> On 05/10/2012 10:52 AM, Paolo Carlini wrote: >>> Was thinking: would it make sense to have a predicate for 'any' pointer >>> type? >> >> Something like TYPE_PTR_OR_PTRMEM_P would be fine. > > Good. > >> Hmm, I see that TYPE_PTRMEM_P only means

Re: [C++ Patch] PR 53301

2012-05-10 Thread Paolo Carlini
Hi, > On 05/10/2012 10:52 AM, Paolo Carlini wrote: >> Was thinking: would it make sense to have a predicate for 'any' pointer type? > > Something like TYPE_PTR_OR_PTRMEM_P would be fine. Good. > Hmm, I see that TYPE_PTRMEM_P only means pointer to data member, that's > unfortunate; the name doe

Re: [C++ Patch] PR 53301

2012-05-10 Thread Jason Merrill
On 05/10/2012 10:52 AM, Paolo Carlini wrote: Was thinking: would it make sense to have a predicate for 'any' pointer type? Something like TYPE_PTR_OR_PTRMEM_P would be fine. Hmm, I see that TYPE_PTRMEM_P only means pointer to data member, that's unfortunate; the name doesn't make that clear.

Re: [C++ Patch] PR 53301

2012-05-10 Thread Paolo Carlini
Hi, > On 05/09/2012 07:12 PM, Paolo Carlini wrote: >> shame on me. I think the patch almost qualifies as obvious. > > I think it does. OK. Good, later today I'll commit it (branch too). Was thinking: would it make sense to have a predicate for 'any' pointer type? I see tens of such || around

Re: [C++ Patch] PR 53301

2012-05-10 Thread Jason Merrill
On 05/09/2012 07:12 PM, Paolo Carlini wrote: shame on me. I think the patch almost qualifies as obvious. I think it does. OK. Jason

[C++ Patch] PR 53301

2012-05-09 Thread Paolo Carlini
Hi, shame on me. I think the patch almost qualifies as obvious. Tested x86_64-linux. Thanks, Paolo. // /cp 2012-05-10 Paolo Carlini PR c++/53301 * decl.c (check_default_argument): Fix typo (POINTER_TYPE_P instead of TYPE_PTR_P) in zero-as-null-poin