On Sat, Oct 8, 2016 at 1:07 PM, Prathamesh Kulkarni <prathamesh.kulka...@linaro.org> wrote: > On 7 October 2016 at 17:49, David Malcolm <dmalc...@redhat.com> wrote: >> On Fri, 2016-10-07 at 10:33 +0530, Prathamesh Kulkarni wrote: >>> On 22 September 2016 at 23:15, Joseph Myers <jos...@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. >>> >> >> 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.
The C++ changes are also OK. Jason
