This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] PR35503 - warn for restricted pointers


On Fri, 26 Aug 2016, Prathamesh Kulkarni wrote:

> Hi Richard,
> I was trying to have a look at PR35503.
> The attached patch tries to warn when an argument is passed to a
> restrict-qualified parameter
> and the argument could alias with other argument.
> 
> For the following test-case:
> int f2(int *restrict x, int *y);
> 
> void f(void)
> {
>   int a;
>   f2 (&a, &a);
> }
> 
> The patch warns:
> test-1.c: In function ‘f’:
> test-1.c:6:3: warning: Passing argument 1 to restrict-qualified
> parameter may alias with argument 2 [-Wrestrict]
>    f2 (&a, &a);
>    ^~~~~~~~~~~
> 
> However it gives false positives if arg is a string constant as in
> following case:
> int foo (char *restrict buf, char *restrict fmt, ...);
> 
> int f(void)
> {
>   char buf[10];
>   foo (buf, "%s-%s", buf, "hello");
> }
> 
> The patch gives false positives for argument 2:
> 
> test-3.c: In function ‘f’:
> test-3.c:6:3: warning: Passing argument 1 to restrict-qualified
> parameter may alias with argument 3 [-Wrestrict]
>    foo (buf, "%s-%s", buf, "hello");
>    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> test-3.c:6:3: warning: Passing argument 2 to restrict-qualified
> parameter may alias with argument 1 [-Wrestrict]
> test-3.c:6:3: warning: Passing argument 2 to restrict-qualified
> parameter may alias with argument 3 [-Wrestrict]
> test-3.c:6:3: warning: Passing argument 2 to restrict-qualified
> parameter may alias with argument 4 [-Wrestrict]
> 
> I am using compute_may_aliases() to obtain alias analysis info,
> and then using ptr_derefs_may_alias_p(arg, current_arg) to check if
> the arguments
> could potentially alias. Is that incorrect ?

Well, it is using conservative may-alias to produce warnings - that
is never a good idea due to the big amount of false positives
that will generate.

I'd simply implement this kind of warning in the FEs only checking
the args as they appear in unoptimized form.

For sth with flow-sensitivity / optimization in mind you'd need
to compute must-alias (which for pointers would need to be defined
in a sensible way - you are not looking at memory references after
all).

Richard.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]