On Tue, 2016-08-30 at 03:23 +0530, Prathamesh Kulkarni wrote:
> On 29 August 2016 at 19:59, Marek Polacek <pola...@redhat.com> wrote:
> > On Mon, Aug 29, 2016 at 04:25:25PM +0200, Tobias Burnus wrote:
> > > Prathamesh Kulkarni wrote:
> > > > Attachment: pr35503-3.txt
> > > 
> > > I tried the patch - and it found a bug in our code; nice!
> > > 
> > > 
> > > (a) Regarding the [-Werror] output:
> > > 
> > >    error: passing argument 24 to restrict qualified parameter
> > > aliases with argument 29 [-Werror]
> > > 
> > > Shouldn't that output "[-Werror=restrict]" instead of a bare "[
> > > -Werror]? Namely, instead of
> > > 
> > > +     warning_at (loc, 0,
> > > +                 "passing argument %u to restrict qualified
> > > parameter aliases with "
> > > +                 "argument %u", param_pos + 1, i + 1);
> > > 
> > > I think one gets this with
> > >         warning_at (loc, OPT_Wrestrict, ...
> > 
> > Yes, this needs to be fixed in the patch.
> Hi,
> Thanks for all the suggestions, I have tried to incorporate them in
> the attached version.
> To avoid duplicating the warnings for multiple aliased arguments,
> I am using TREE_VISITED to mark all the aliased arguments of the
> current
> arg, which makes diagnostic emitted only once per same set of
> aliases.
> Is using TREE_VISITED ok as in the patch ?
> 
> eg:
> void f(int *__restrict x, int *y, int *__restrict z, int *w);
> 
> void foo(int a, int b)
> {
>   f (&a, &b, &a, &a);
> }
> 
> Output:
> test-2.c: In function ‘foo’:
> test-2.c:5:6: warning: passing argument 1 to restrict-qualified
> parameter aliases with arguments 3, 4 [-Wrestrict]
>    f (&a, &b, &a, &a);
>        ^~
> 
> Using EXPR_LOCATION (arg), helps underline the argument for both C
> and C++
> as in the example above. However in case of variadic functions, it
> appears C++FE doesn't set EXPR_LOCATION,
> so I am falling back to using input_location if EXPR_LOCATION is
> unknown.

You may be able to use EXPR_LOC_OR_LOC for this.

> However it gives the location correctly for non-variadic functions.
> For setting locations correctly I will try the approach suggested by
> Jason in
> https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01987.html
> 
> I was wondering how to underline all the aliased arguments ?
> I would like to see the output for above eg as:
> 
> test-2.c: In function ‘foo’:
> test-2.c:5:6: warning: passing argument 1 to restrict-qualified
> parameter aliases with arguments 3, 4 [-Wrestrict]
>    f (&a, &b, &a, &a);
>        ^~        ~~   ~~
> 
> I would be grateful for suggestions for the same.
> Bootstrap+test in progress on x86_64-unknown-linux-gnu.


The above came through email a bit mangled; presumably you mean:

   f (&a, &b, &a, &a);
      ^~      ~~  ~~ 

(hopefully Evolution won't mangle the above).

Assuming you have the location_t values available, you can create a
rich_location for the primary range, and then add secondary ranges like
this:

  rich_location richloc (loc_of_arg1);
  richloc.add_range (loc_of_arg3, false);  /* false here = don't draw a
caret, just the underline */
  richloc.add_range (loc_of_arg4, false);
  warning_at_rich_loc (&richloc, OPT_Wrestrict, etc...

See line-map.h for more information on rich_location.

Currently we can only have up to 3 ranges in a rich_location; I have a
patch in one of my working copies that fixes that so we can have an
arbitrary number; I'll try to dig that out as it's clearly relevant
here.

It's a good idea to have a testcase that verifies the underlines.

Use:

  /* { dg-options "-fdiagnostics-show-caret" } */

and then use:

  /* { dg-begin-multiline-output "" }
quote the expected output here, omitting trailing dg-directives
     { dg-end-multiline-output "" } */

e.g.
  /* { dg-begin-multiline-output "" }
   f (&a, &b, &a, &a);
      ^~      ~~  ~~ 
     { dg-end-multiline-output "" } */

Please use identifiers that are longer than one char in such a test, since 
otherwise there's a chance that we're not properly underlining all of the 
pertinent range (i.e. testing the start != finish case).

Hope the above is helpful
Dave



Reply via email to