[PATCH,c++] use XALLOCAVEC in the C++ front-end

[PATCH,c++] use XALLOCAVEC in the C++ front-end

[Nathan Froyd]

Just a minor cleanup noticed while browsing around.

There's still one call that seems like it ought to be replaceable: in
semantics.c:finish_asm_stmt, we have:

      oconstraints = (const char **) alloca (noutputs * sizeof (char *));

But changing this to:

      oconstraints = (const char **) XALLOCAVEC (char *, noutputs);

gives the error:

semantics.c: In function ‘finish_asm_stmt’:
semantics.c:1223:7: error: new ‘const’ qualifier in middle of multi-level non-const cast is unsafe [-Werror=cast-qual]

which I don't understand, because the cast is not in the "middle" of
anything.  Is this a bug in the cast checking?

Tested on x86_64-unknown-linux-gnu.  OK to commit?

	* call.c (build_call_n): Call XALLOCAVEC instead of alloca.
	(build_op_delete_call): Likewise.
	(build_over_call): Likewise.
	* cp-gimplify.c (cxx_omp_clause_apply_fn): Likewise.
	* pt.c (process_partial_specialization): Likewise.
	(tsubst_template_args): Likewise.

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 03d188b..9162a1d 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -282,7 +282,7 @@ build_call_n (tree function, int n, ...)
     return build_call_a (function, 0, NULL);
   else
     {
-      tree *argarray = (tree *) alloca (n * sizeof (tree));
+      tree *argarray = XALLOCAVEC (tree, n);
       va_list ap;
       int i;
 
@@ -4756,7 +4756,7 @@ build_op_delete_call (enum tree_code code, tree addr, tree size,
 	  /* The placement args might not be suitable for overload
 	     resolution at this point, so build the call directly.  */
 	  int nargs = call_expr_nargs (placement);
-	  tree *argarray = (tree *) alloca (nargs * sizeof (tree));
+	  tree *argarray = XALLOCAVEC (tree, nargs);
 	  int i;
 	  argarray[0] = addr;
 	  for (i = 1; i < nargs; i++)
@@ -5624,7 +5624,7 @@ build_over_call (struct z_candidate *cand, int flags, tsubst_flags_t complain)
   nargs = VEC_length (tree, args) + (first_arg != NULL_TREE ? 1 : 0);
   if (parmlen > nargs)
     nargs = parmlen;
-  argarray = (tree *) alloca (nargs * sizeof (tree));
+  argarray = XALLOCAVEC (tree, nargs);
 
   /* The implicit parameters to a constructor are not considered by overload
      resolution, and must be of the proper type.  */
diff --git a/gcc/cp/cp-gimplify.c b/gcc/cp/cp-gimplify.c
index f45d714..fb7daeb 100644
--- a/gcc/cp/cp-gimplify.c
+++ b/gcc/cp/cp-gimplify.c
@@ -981,7 +981,7 @@ cxx_omp_clause_apply_fn (tree fn, tree arg1, tree arg2)
     return NULL;
 
   nargs = list_length (DECL_ARGUMENTS (fn));
-  argarray = (tree *) alloca (nargs * sizeof (tree));
+  argarray = XALLOCAVEC (tree, nargs);
 
   defparm = TREE_CHAIN (TYPE_ARG_TYPES (TREE_TYPE (fn)));
   if (arg2)
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index b95fdf7..69e4816 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -3875,10 +3875,10 @@ process_partial_specialization (tree decl)
 
      or some such would have been OK.  */
   tpd.level = TMPL_PARMS_DEPTH (current_template_parms);
-  tpd.parms = (int *) alloca (sizeof (int) * ntparms);
+  tpd.parms = XALLOCAVEC (int, ntparms);
   memset (tpd.parms, 0, sizeof (int) * ntparms);
 
-  tpd.arg_uses_template_parms = (int *) alloca (sizeof (int) * nargs);
+  tpd.arg_uses_template_parms = XALLOCAVEC (int, nargs);
   memset (tpd.arg_uses_template_parms, 0, sizeof (int) * nargs);
   for (i = 0; i < nargs; ++i)
     {
@@ -3993,12 +3993,11 @@ process_partial_specialization (tree decl)
                   if (!tpd2.parms)
                     {
                       /* We haven't yet initialized TPD2.  Do so now.  */
-                      tpd2.arg_uses_template_parms 
-                        = (int *) alloca (sizeof (int) * nargs);
+                      tpd2.arg_uses_template_parms = XALLOCAVEC (int, nargs);
                       /* The number of parameters here is the number in the
                          main template, which, as checked in the assertion
                          above, is NARGS.  */
-                      tpd2.parms = (int *) alloca (sizeof (int) * nargs);
+                      tpd2.parms = XALLOCAVEC (int, nargs);
                       tpd2.level = 
                         TMPL_PARMS_DEPTH (DECL_TEMPLATE_PARMS (maintmpl));
                     }
@@ -8527,7 +8526,7 @@ tsubst_template_args (tree t, tree args, tsubst_flags_t complain, tree in_decl)
   tree orig_t = t;
   int len = TREE_VEC_LENGTH (t);
   int need_new = 0, i, expanded_len_adjust = 0, out;
-  tree *elts = (tree *) alloca (len * sizeof (tree));
+  tree *elts = XALLOCAVEC (tree, len);
 
   for (i = 0; i < len; i++)
     {

Re: [PATCH,c++] use XALLOCAVEC in the C++ front-end

[Jason Merrill]

On 06/06/2010 08:52 PM, Nathan Froyd wrote:
> Just a minor cleanup noticed while browsing around.
>
> There's still one call that seems like it ought to be replaceable: in
> semantics.c:finish_asm_stmt, we have:
>
>        oconstraints = (const char **) alloca (noutputs * sizeof (char *));
>
> But changing this to:
>
>        oconstraints = (const char **) XALLOCAVEC (char *, noutputs);
>
> gives the error:
>
> semantics.c: In function ‘finish_asm_stmt’:
> semantics.c:1223:7: error: new ‘const’ qualifier in middle of multi-level non-const cast is unsafe [-Werror=cast-qual]
>
> which I don't understand, because the cast is not in the "middle" of
> anything.  Is this a bug in the cast checking?

The error message is unclear, but the issue is that converting from 
char** to char const** is unsafe, while converting to char const*const* 
is safe.

Just use XALLOCAVEC(const char *, noutputs) with no extra cast.

Jason

Re: [PATCH,c++] use XALLOCAVEC in the C++ front-end

[Manuel López-Ibáñez]

On 8 June 2010 16:06, Jason Merrill <jason@redhat.com> wrote:
> On 06/06/2010 08:52 PM, Nathan Froyd wrote:
>>
>> Just a minor cleanup noticed while browsing around.
>>
>> There's still one call that seems like it ought to be replaceable: in
>> semantics.c:finish_asm_stmt, we have:
>>
>>       oconstraints = (const char **) alloca (noutputs * sizeof (char *));
>>
>> But changing this to:
>>
>>       oconstraints = (const char **) XALLOCAVEC (char *, noutputs);
>>
>> gives the error:
>>
>> semantics.c: In function ‘finish_asm_stmt’:
>> semantics.c:1223:7: error: new ‘const’ qualifier in middle of multi-level
>> non-const cast is unsafe [-Werror=cast-qual]
>>
>> which I don't understand, because the cast is not in the "middle" of
>> anything.  Is this a bug in the cast checking?
>
> The error message is unclear, but the issue is that converting from char**
> to char const** is unsafe, while converting to char const*const* is safe.

What does it mean unsafe in this context? I could produce a patch that
changes the message but I would like to be sure what to say.

semantics.c:1223:7: error: new ‘const’ qualifier in cast from 'char
**' to 'const char **' is unsafe [-Werror=cast-qual]

Cheers,

Manuel.

Re: [PATCH,c++] use XALLOCAVEC in the C++ front-end

[Jason Merrill]

On 06/08/2010 10:43 AM, Manuel López-Ibáñez wrote:
> On 8 June 2010 16:06, Jason Merrill<jason@redhat.com>  wrote:

>> The error message is unclear, but the issue is that converting from char**
>> to char const** is unsafe, while converting to char const*const* is safe.
>
> What does it mean unsafe in this context? I could produce a patch that
> changes the message but I would like to be sure what to say.
>
> semantics.c:1223:7: error: new ‘const’ qualifier in cast from 'char
> **' to 'const char **' is unsafe [-Werror=cast-qual]

Explanation from the C++ standard (4.4 [conv.qual]):

[ Note: if a program could assign a pointer of type T** to a pointer of 
type const T** (that is, if line #1 below were allowed), a program could 
inadvertently modify a const object (as it is done on line #2). For example,

   int main() {
     const char c = Â’cÂ’;
     char* pc;
     const char** pcc = &pc;// #1: not allowed
     *pcc = &c;
     *pc = Â’CÂ’; // #2: modifies a const object
   }
--end note ]

Re: [PATCH,c++] use XALLOCAVEC in the C++ front-end

[Manuel López-Ibáñez]

On 8 June 2010 18:14, Jason Merrill <jason@redhat.com> wrote:
> On 06/08/2010 10:43 AM, Manuel López-Ibáñez wrote:
>>
>> On 8 June 2010 16:06, Jason Merrill<jason@redhat.com>  wrote:
>
>>> The error message is unclear, but the issue is that converting from
>>> char**
>>> to char const** is unsafe, while converting to char const*const* is safe.
>>
>> What does it mean unsafe in this context? I could produce a patch that
>> changes the message but I would like to be sure what to say.
>>
>> semantics.c:1223:7: error: new ‘const’ qualifier in cast from 'char
>> **' to 'const char **' is unsafe [-Werror=cast-qual]
> Explanation from the C++ standard (4.4 [conv.qual]):
>
> [ Note: if a program could assign a pointer of type T** to a pointer of type
> const T** (that is, if line #1 below were allowed), a program could
> inadvertently modify a const object (as it is done on line #2). For example,
>
>  int main() {
>    const char c = ’c’;
>    char* pc;
>    const char** pcc = &pc;// #1: not allowed
>    *pcc = &c;
>    *pc = ’C’; // #2: modifies a const object
>  }
> --end note ]

So what do you think about the following message:

error: new ‘const’ qualifier in cast from 'char **' to 'const char **'
is unsafe [-Werror=cast-qual]
note: to be safe all intermediate pointers must be equally qualified

Cheers,

Manuel.

Re: [PATCH,c++] use XALLOCAVEC in the C++ front-end

[Gabriel Dos Reis]

On Wed, Jun 9, 2010 at 4:53 AM, Manuel López-Ibáñez
<lopezibanez@gmail.com> wrote:
> On 8 June 2010 18:14, Jason Merrill <jason@redhat.com> wrote:
>> On 06/08/2010 10:43 AM, Manuel López-Ibáñez wrote:
>>>
>>> On 8 June 2010 16:06, Jason Merrill<jason@redhat.com>  wrote:
>>
>>>> The error message is unclear, but the issue is that converting from
>>>> char**
>>>> to char const** is unsafe, while converting to char const*const* is safe.
>>>
>>> What does it mean unsafe in this context? I could produce a patch that
>>> changes the message but I would like to be sure what to say.
>>>
>>> semantics.c:1223:7: error: new ‘const’ qualifier in cast from 'char
>>> **' to 'const char **' is unsafe [-Werror=cast-qual]
>> Explanation from the C++ standard (4.4 [conv.qual]):
>>
>> [ Note: if a program could assign a pointer of type T** to a pointer of type
>> const T** (that is, if line #1 below were allowed), a program could
>> inadvertently modify a const object (as it is done on line #2). For example,
>>
>>  int main() {
>>    const char c = ’c’;
>>    char* pc;
>>    const char** pcc = &pc;// #1: not allowed
>>    *pcc = &c;
>>    *pc = ’C’; // #2: modifies a const object
>>  }
>> --end note ]
>
> So what do you think about the following message:
>
> error: new ‘const’ qualifier in cast from 'char **' to 'const char **'
> is unsafe [-Werror=cast-qual]
> note: to be safe all intermediate pointers must be equally qualified

that is OK; but I find the leading 'new' hard to parse.   Please, just
remove it.

Re: [PATCH,c++] use XALLOCAVEC in the C++ front-end

[Manuel López-Ibáñez]

On 9 June 2010 13:33, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
> On Wed, Jun 9, 2010 at 4:53 AM, Manuel López-Ibáñez
> <lopezibanez@gmail.com> wrote:
>> On 8 June 2010 18:14, Jason Merrill <jason@redhat.com> wrote:
>>> On 06/08/2010 10:43 AM, Manuel López-Ibáñez wrote:
>>>>
>>>> On 8 June 2010 16:06, Jason Merrill<jason@redhat.com>  wrote:
>>>
>>>>> The error message is unclear, but the issue is that converting from
>>>>> char**
>>>>> to char const** is unsafe, while converting to char const*const* is safe.
>>>>
>>>> What does it mean unsafe in this context? I could produce a patch that
>>>> changes the message but I would like to be sure what to say.
>>>>
>>>> semantics.c:1223:7: error: new ‘const’ qualifier in cast from 'char
>>>> **' to 'const char **' is unsafe [-Werror=cast-qual]
>>> Explanation from the C++ standard (4.4 [conv.qual]):
>>>
>>> [ Note: if a program could assign a pointer of type T** to a pointer of type
>>> const T** (that is, if line #1 below were allowed), a program could
>>> inadvertently modify a const object (as it is done on line #2). For example,
>>>
>>>  int main() {
>>>    const char c = ’c’;
>>>    char* pc;
>>>    const char** pcc = &pc;// #1: not allowed
>>>    *pcc = &c;
>>>    *pc = ’C’; // #2: modifies a const object
>>>  }
>>> --end note ]
>>
>> So what do you think about the following message:
>>
>> error: new ‘const’ qualifier in cast from 'char **' to 'const char **'
>> is unsafe [-Werror=cast-qual]
>> note: to be safe all intermediate pointers must be equally qualified
>
> that is OK; but I find the leading 'new' hard to parse.   Please, just
> remove it.
>

Anyway, this is the C FE. The C++ FE gives the following:

test.C:4:23: warning: invalid conversion from ‘char**’ to ‘const
char**’ [-fpermissive]

but the code is too intricate to give a clearer error in the case of
C++ or to factor out the common check.

Cheers,

Manuel.

Re: [PATCH,c++] use XALLOCAVEC in the C++ front-end

[Gabriel Dos Reis]

On Wed, Jun 9, 2010 at 6:53 AM, Manuel López-Ibáñez
<lopezibanez@gmail.com> wrote:
> On 9 June 2010 13:33, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
>> On Wed, Jun 9, 2010 at 4:53 AM, Manuel López-Ibáñez
>> <lopezibanez@gmail.com> wrote:
>>> On 8 June 2010 18:14, Jason Merrill <jason@redhat.com> wrote:
>>>> On 06/08/2010 10:43 AM, Manuel López-Ibáñez wrote:
>>>>>
>>>>> On 8 June 2010 16:06, Jason Merrill<jason@redhat.com>  wrote:
>>>>
>>>>>> The error message is unclear, but the issue is that converting from
>>>>>> char**
>>>>>> to char const** is unsafe, while converting to char const*const* is safe.
>>>>>
>>>>> What does it mean unsafe in this context? I could produce a patch that
>>>>> changes the message but I would like to be sure what to say.
>>>>>
>>>>> semantics.c:1223:7: error: new ‘const’ qualifier in cast from 'char
>>>>> **' to 'const char **' is unsafe [-Werror=cast-qual]
>>>> Explanation from the C++ standard (4.4 [conv.qual]):
>>>>
>>>> [ Note: if a program could assign a pointer of type T** to a pointer of type
>>>> const T** (that is, if line #1 below were allowed), a program could
>>>> inadvertently modify a const object (as it is done on line #2). For example,
>>>>
>>>>  int main() {
>>>>    const char c = ’c’;
>>>>    char* pc;
>>>>    const char** pcc = &pc;// #1: not allowed
>>>>    *pcc = &c;
>>>>    *pc = ’C’; // #2: modifies a const object
>>>>  }
>>>> --end note ]
>>>
>>> So what do you think about the following message:
>>>
>>> error: new ‘const’ qualifier in cast from 'char **' to 'const char **'
>>> is unsafe [-Werror=cast-qual]
>>> note: to be safe all intermediate pointers must be equally qualified
>>
>> that is OK; but I find the leading 'new' hard to parse.   Please, just
>> remove it.
>>
>
> Anyway, this is the C FE.

Yes, I know.

> The C++ FE gives the following:
>
> test.C:4:23: warning: invalid conversion from ‘char**’ to ‘const
> char**’ [-fpermissive]
>
> but the code is too intricate to give a clearer error in the case of
> C++ or to factor out the common check.

Removing the leading 'new' does not require any of that.

>
> Cheers,
>
> Manuel.
>

Re: [PATCH,c++] use XALLOCAVEC in the C++ front-end

[Gabriel Dos Reis]

On Wed, Jun 9, 2010 at 7:11 AM, Manuel López-Ibáñez
<lopezibanez@gmail.com> wrote:
> On 9 June 2010 14:08, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
>> On Wed, Jun 9, 2010 at 6:53 AM, Manuel López-Ibáñez
>> <lopezibanez@gmail.com> wrote:
>>> On 9 June 2010 13:33, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
>>>> On Wed, Jun 9, 2010 at 4:53 AM, Manuel López-Ibáñez
>>>> <lopezibanez@gmail.com> wrote:
>>>>> On 8 June 2010 18:14, Jason Merrill <jason@redhat.com> wrote:
>>>>>> On 06/08/2010 10:43 AM, Manuel López-Ibáñez wrote:
>>>>>>>
>>>>>>> On 8 June 2010 16:06, Jason Merrill<jason@redhat.com>  wrote:
>>>>>>
>>>>>>>> The error message is unclear, but the issue is that converting from
>>>>>>>> char**
>>>>>>>> to char const** is unsafe, while converting to char const*const* is safe.
>>>>>>>
>>>>>>> What does it mean unsafe in this context? I could produce a patch that
>>>>>>> changes the message but I would like to be sure what to say.
>>>>>>>
>>>>>>> semantics.c:1223:7: error: new ‘const’ qualifier in cast from 'char
>>>>>>> **' to 'const char **' is unsafe [-Werror=cast-qual]
>>>>>> Explanation from the C++ standard (4.4 [conv.qual]):
>>>>>>
>>>>>> [ Note: if a program could assign a pointer of type T** to a pointer of type
>>>>>> const T** (that is, if line #1 below were allowed), a program could
>>>>>> inadvertently modify a const object (as it is done on line #2). For example,
>>>>>>
>>>>>>  int main() {
>>>>>>    const char c = ’c’;
>>>>>>    char* pc;
>>>>>>    const char** pcc = &pc;// #1: not allowed
>>>>>>    *pcc = &c;
>>>>>>    *pc = ’C’; // #2: modifies a const object
>>>>>>  }
>>>>>> --end note ]
>>>>>
>>>>> So what do you think about the following message:
>>>>>
>>>>> error: new ‘const’ qualifier in cast from 'char **' to 'const char **'
>>>>> is unsafe [-Werror=cast-qual]
>>>>> note: to be safe all intermediate pointers must be equally qualified
>>>>
>>>> that is OK; but I find the leading 'new' hard to parse.   Please, just
>>>> remove it.
>>>>
>>>
>>> Anyway, this is the C FE.
>>
>> Yes, I know.
>>
>>> The C++ FE gives the following:
>>>
>>> test.C:4:23: warning: invalid conversion from ‘char**’ to ‘const
>>> char**’ [-fpermissive]
>>>
>>> but the code is too intricate to give a clearer error in the case of
>>> C++ or to factor out the common check.
>>
>> Removing the leading 'new' does not require any of that.
>
> Of course, it was a just a comment since consistency between C and C++
> is a goal, so we should always check for low hanging-fruit. Not this
> case unfortunately.
>
> I am bootstrapping this:
>
> Index: gcc/c-typeck.c
> ===================================================================
> --- gcc/c-typeck.c      (revision 160384)
> +++ gcc/c-typeck.c      (working copy)
> @@ -4493,9 +4493,12 @@
>          && !is_const)
>        {
>          int added = TYPE_QUALS (in_type) &~ TYPE_QUALS (in_otype);
> -         warning (OPT_Wcast_qual,
> -                  ("new %qv qualifier in middle of multi-level non-const cast "
> -                   "is unsafe"), added);
> +         if (warning_at (input_location, OPT_Wcast_qual,
> +                          "%qv qualifier in cast from %qT to %qT is unsafe",
> +                          added, in_type, in_otype))
> +              inform (input_location,
> +                      G_("to be safe all intermediate pointers"
> +                         " must be equally qualified"));
>          break;
>        }
>       if (is_const)
>
> There will be some testcases that need adjusting.
>

OK, thanks!

Re: [PATCH,c++] use XALLOCAVEC in the C++ front-end

[Manuel López-Ibáñez]

On 9 June 2010 14:08, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
> On Wed, Jun 9, 2010 at 6:53 AM, Manuel López-Ibáñez
> <lopezibanez@gmail.com> wrote:
>> On 9 June 2010 13:33, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
>>> On Wed, Jun 9, 2010 at 4:53 AM, Manuel López-Ibáñez
>>> <lopezibanez@gmail.com> wrote:
>>>> On 8 June 2010 18:14, Jason Merrill <jason@redhat.com> wrote:
>>>>> On 06/08/2010 10:43 AM, Manuel López-Ibáñez wrote:
>>>>>>
>>>>>> On 8 June 2010 16:06, Jason Merrill<jason@redhat.com>  wrote:
>>>>>
>>>>>>> The error message is unclear, but the issue is that converting from
>>>>>>> char**
>>>>>>> to char const** is unsafe, while converting to char const*const* is safe.
>>>>>>
>>>>>> What does it mean unsafe in this context? I could produce a patch that
>>>>>> changes the message but I would like to be sure what to say.
>>>>>>
>>>>>> semantics.c:1223:7: error: new ‘const’ qualifier in cast from 'char
>>>>>> **' to 'const char **' is unsafe [-Werror=cast-qual]
>>>>> Explanation from the C++ standard (4.4 [conv.qual]):
>>>>>
>>>>> [ Note: if a program could assign a pointer of type T** to a pointer of type
>>>>> const T** (that is, if line #1 below were allowed), a program could
>>>>> inadvertently modify a const object (as it is done on line #2). For example,
>>>>>
>>>>>  int main() {
>>>>>    const char c = ’c’;
>>>>>    char* pc;
>>>>>    const char** pcc = &pc;// #1: not allowed
>>>>>    *pcc = &c;
>>>>>    *pc = ’C’; // #2: modifies a const object
>>>>>  }
>>>>> --end note ]
>>>>
>>>> So what do you think about the following message:
>>>>
>>>> error: new ‘const’ qualifier in cast from 'char **' to 'const char **'
>>>> is unsafe [-Werror=cast-qual]
>>>> note: to be safe all intermediate pointers must be equally qualified
>>>
>>> that is OK; but I find the leading 'new' hard to parse.   Please, just
>>> remove it.
>>>
>>
>> Anyway, this is the C FE.
>
> Yes, I know.
>
>> The C++ FE gives the following:
>>
>> test.C:4:23: warning: invalid conversion from ‘char**’ to ‘const
>> char**’ [-fpermissive]
>>
>> but the code is too intricate to give a clearer error in the case of
>> C++ or to factor out the common check.
>
> Removing the leading 'new' does not require any of that.

Of course, it was a just a comment since consistency between C and C++
is a goal, so we should always check for low hanging-fruit. Not this
case unfortunately.

I am bootstrapping this:

Index: gcc/c-typeck.c
===================================================================
--- gcc/c-typeck.c      (revision 160384)
+++ gcc/c-typeck.c      (working copy)
@@ -4493,9 +4493,12 @@
          && !is_const)
        {
          int added = TYPE_QUALS (in_type) &~ TYPE_QUALS (in_otype);
-         warning (OPT_Wcast_qual,
-                  ("new %qv qualifier in middle of multi-level non-const cast "
-                   "is unsafe"), added);
+         if (warning_at (input_location, OPT_Wcast_qual,
+                          "%qv qualifier in cast from %qT to %qT is unsafe",
+                          added, in_type, in_otype))
+              inform (input_location,
+                      G_("to be safe all intermediate pointers"
+                         " must be equally qualified"));
          break;
        }
       if (is_const)

There will be some testcases that need adjusting.

Cheers,

Manuel.

Re: [PATCH,c++] use XALLOCAVEC in the C++ front-end

[Joseph S. Myers]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 457 bytes --]

On Wed, 9 Jun 2010, Manuel López-Ibáñez wrote:

> note: to be safe all intermediate pointers must be equally qualified

The requirement is not that they be equally qualified, it's that they be 
const-qualified.  (That is, if you are adding "volatile" qualifiers, 
"const" is still needed at intermediate levels; you can convert char ** to 
volatile char *const * but not to volatile char *volatile *.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH,c++] use XALLOCAVEC in the C++ front-end

[Manuel López-Ibáñez]

[-- Attachment #1: Type: text/plain, Size: 766 bytes --]

On 9 June 2010 22:35, Joseph S. Myers <joseph@codesourcery.com> wrote:
> On Wed, 9 Jun 2010, Manuel López-Ibáñez wrote:
>
>> note: to be safe all intermediate pointers must be equally qualified
>
> The requirement is not that they be equally qualified, it's that they be
> const-qualified.  (That is, if you are adding "volatile" qualifiers,
> "const" is still needed at intermediate levels; you can convert char ** to
> volatile char *const * but not to volatile char *volatile *.)

Bootstrapped and regression tested on x86_64-linux-gnu. OK for trunk?

2010-06-11  Manuel López-Ibáñez  <manu@gcc.gnu.org>

	* c-typeck.c (handle_warn_cast_qual): Add loc
	parameter. Improve warning message.
	(build_c_cast): Pass location to handle_warn_cast_qual.

[-- Attachment #2: wcast-qual.diff --]
[-- Type: text/plain, Size: 3028 bytes --]

Index: gcc/c-typeck.c
===================================================================
--- gcc/c-typeck.c	(revision 160464)
+++ gcc/c-typeck.c	(working copy)
@@ -4411,16 +4411,17 @@ build_compound_expr (location_t loc, tre
   return ret;
 }
 
 /* Issue -Wcast-qual warnings when appropriate.  TYPE is the type to
    which we are casting.  OTYPE is the type of the expression being
-   cast.  Both TYPE and OTYPE are pointer types.  -Wcast-qual appeared
-   on the command line.  Named address space qualifiers are not handled
-   here, because they result in different warnings.  */
+   cast.  Both TYPE and OTYPE are pointer types.  LOC is the location
+   of the cast.  -Wcast-qual appeared on the command line.  Named
+   address space qualifiers are not handled here, because they result
+   in different warnings.  */
 
 static void
-handle_warn_cast_qual (tree type, tree otype)
+handle_warn_cast_qual (location_t loc, tree type, tree otype)
 {
   tree in_type = type;
   tree in_otype = otype;
   int added = 0;
   int discarded = 0;
@@ -4449,19 +4450,19 @@ handle_warn_cast_qual (tree type, tree o
     }
   while (TREE_CODE (in_type) == POINTER_TYPE
 	 && TREE_CODE (in_otype) == POINTER_TYPE);
 
   if (added)
-    warning (OPT_Wcast_qual, "cast adds %q#v qualifier to function type",
-	     added);
+    warning_at (loc, OPT_Wcast_qual,
+		"cast adds %q#v qualifier to function type", added);
 
   if (discarded)
     /* There are qualifiers present in IN_OTYPE that are not present
        in IN_TYPE.  */
-    warning (OPT_Wcast_qual,
-	     "cast discards %q#v qualifier from pointer target type",
-	     discarded);
+    warning_at (loc, OPT_Wcast_qual,
+		"cast discards %q#v qualifier from pointer target type",
+		discarded);
 
   if (added || discarded)
     return;
 
   /* A cast from **T to const **T is unsafe, because it can cause a
@@ -4490,14 +4491,14 @@ handle_warn_cast_qual (tree type, tree o
       in_type = TREE_TYPE (in_type);
       in_otype = TREE_TYPE (in_otype);
       if ((TYPE_QUALS (in_type) &~ TYPE_QUALS (in_otype)) != 0
 	  && !is_const)
 	{
-	  int added = TYPE_QUALS (in_type) &~ TYPE_QUALS (in_otype);
-	  warning (OPT_Wcast_qual,
-		   ("new %qv qualifier in middle of multi-level non-const cast "
-		    "is unsafe"), added);
+	  warning_at (loc, OPT_Wcast_qual,
+		      G_("to be safe all intermediate pointers in cast from "
+			 "%qT to %qT must be %<const%> qualified"),
+		      otype, type);
 	  break;
 	}
       if (is_const)
 	is_const = TYPE_READONLY (in_type);
     }
@@ -4597,11 +4598,11 @@ build_c_cast (location_t loc, tree type,
 
       /* Optionally warn about potentially worrisome casts.  */
       if (warn_cast_qual
 	  && TREE_CODE (type) == POINTER_TYPE
 	  && TREE_CODE (otype) == POINTER_TYPE)
-	handle_warn_cast_qual (type, otype);
+	handle_warn_cast_qual (loc, type, otype);
 
       /* Warn about conversions between pointers to disjoint
 	 address spaces.  */
       if (TREE_CODE (type) == POINTER_TYPE
 	  && TREE_CODE (otype) == POINTER_TYPE

Re: [PATCH,c++] use XALLOCAVEC in the C++ front-end

[Joseph S. Myers]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 995 bytes --]

On Fri, 11 Jun 2010, Manuel López-Ibáñez wrote:

> On 9 June 2010 22:35, Joseph S. Myers <joseph@codesourcery.com> wrote:
> > On Wed, 9 Jun 2010, Manuel López-Ibáñez wrote:
> >
> >> note: to be safe all intermediate pointers must be equally qualified
> >
> > The requirement is not that they be equally qualified, it's that they be
> > const-qualified.  (That is, if you are adding "volatile" qualifiers,
> > "const" is still needed at intermediate levels; you can convert char ** to
> > volatile char *const * but not to volatile char *volatile *.)
> 
> Bootstrapped and regression tested on x86_64-linux-gnu. OK for trunk?
> 
> 2010-06-11  Manuel López-Ibáñez  <manu@gcc.gnu.org>
> 
> 	* c-typeck.c (handle_warn_cast_qual): Add loc
> 	parameter. Improve warning message.
> 	(build_c_cast): Pass location to handle_warn_cast_qual.

Remove the explicit G_(), which isn't needed in a call to warning_at.  OK 
with that change.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH,c++] use XALLOCAVEC in the C++ front-end

[Manuel López-Ibáñez]

On 11 June 2010 11:33, Joseph S. Myers <joseph@codesourcery.com> wrote:
> On Fri, 11 Jun 2010, Manuel López-Ibáñez wrote:
>
>> On 9 June 2010 22:35, Joseph S. Myers <joseph@codesourcery.com> wrote:
>> > On Wed, 9 Jun 2010, Manuel López-Ibáñez wrote:
>> >
>> >> note: to be safe all intermediate pointers must be equally qualified
>> >
>> > The requirement is not that they be equally qualified, it's that they be
>> > const-qualified.  (That is, if you are adding "volatile" qualifiers,
>> > "const" is still needed at intermediate levels; you can convert char ** to
>> > volatile char *const * but not to volatile char *volatile *.)
>>
>> Bootstrapped and regression tested on x86_64-linux-gnu. OK for trunk?
>>
>> 2010-06-11  Manuel López-Ibáñez  <manu@gcc.gnu.org>
>>
>>       * c-typeck.c (handle_warn_cast_qual): Add loc
>>       parameter. Improve warning message.
>>       (build_c_cast): Pass location to handle_warn_cast_qual.
>
> Remove the explicit G_(), which isn't needed in a call to warning_at.  OK
> with that change.

Committed revision 160601.