Re: PR35503 - warn for restrict pointer

[Prathamesh Kulkarni <prathamesh.kulkarni@linaro.org>]

On 7 October 2016 at 17:49, David Malcolm <dmalcolm@redhat.com> wrote:
> On Fri, 2016-10-07 at 10:33 +0530, Prathamesh Kulkarni wrote:
>> On 22 September 2016 at 23:15, Joseph Myers <joseph@codesourcery.com>
>> wrote:
>> > On Thu, 22 Sep 2016, Prathamesh Kulkarni wrote:
>> >
>> > > Would that be acceptable ? I am not sure how to make %Z check if
>> > > the
>> > > argument has type vec<int> *
>> > > since vec<int> is not really a builtin C type.
>> > > Could you suggest me a better solution so that the format checker
>> > > will check
>> > > if arg has type vec<int> * instead of checking if it's just a
>> > > pointer ?
>> > > Also for testing, should I create a testcase in g++.dg since
>> > > gcc.dg/format/ tests are C-only ?
>> >
>> > If it's C++-only then it would need to be in g++.dg.
>> >
>> > The way we handle GCC-specific types in checking these formats is
>> > that the
>> > code using these formats has to define typedefs which the format
>> > -checking
>> > code then looks up.  In most cases it can just look up names like
>> > location_t or tree, but for HOST_WIDE_INT it looks up
>> > __gcc_host_wide_int__ which the user must have defined as a
>> > typedef.
>> > Probably that's the way to go in this case: the user must do
>> > "typedef
>> > vec<int> __gcc_vec_int__;" or similar, and the code looks up
>> > __gcc_vec_int__.
>> Thanks for the suggestions. To keep it simple, instead of vec<int>,
>> I made %Z take two args: int *v, unsigned len, and prints elements in
>> v having length == len.
>> Is that OK ?
>>
>> Bootstrapped+tested on x86_64-unknown-linux-gnu.
>> As pointed out earlier in the thread, the patch can give false
>> positives because
>> it only checks whether parameters are qualified with restrict, not
>> how
>> parameters
>> are used inside the function. For instance it warned for example 10
>> mentioned in n1570
>> under section 6.7.3.1 - "Formal definition of restrict".
>> Should we keep the warning in Wall or keep it in Wextra ?
>> The attached patch enables it with Wall.
>>
>> Thanks,
>> Prathamesh
>
> This needs a ChangeLog.
>
> The changes to diagnostic-core.h and diagnostic.c are OK for trunk,
> given a suitable ChangeLog (and could be split into a separate patch if
> you like).
Thanks, I committed diagnostic.c and diagnostic-core.h changes (with ChangeLog)
in r240891.

Thanks,
Prathamesh