Question about pointer arithmetics in GIMPLE

Question about pointer arithmetics in GIMPLE

[Falk Hueffner]

Hi,

I'm trying to implement a tree pass that warns about bad array
accesses as suggested for PR 8268 by Jeff Law. However, I have trouble
with the following:

char digit_vector[5];
const char *ggc_alloc_string(int length) {
    return digit_vector + ((length - 17) * 2);
}

this translates to:

ggc_alloc_string (length)
{
  const char * D.1292;
  int D.1293;
  long unsigned int D.1294;
  char * D.1295;
  char * D.1296;

  D.1293 = length * 2;
  D.1294 = (long unsigned int) D.1293;
  D.1295 = (char *) D.1294;
  D.1296 = &digit_vector + -34B;     <-----------
  D.1292 = D.1295 + D.1296;
  return D.1292;
}

that is, a pointer is formed that wouldn't be legal to form from C,
and we end up with

  return (char *) (long unsigned int) (length * 2) + &digit_vector[-000000022];

producing a warning. Is that correct GIMPLE? If so, I fear it simply
isn't possible to do this kind of warnings after gimplification, and,
if at all possible, would have to be done in the front-end after all.

-- 
	Falk

Re: Question about pointer arithmetics in GIMPLE

[Jeffrey A Law]

On Sun, 2005-08-21 at 20:32 +0200, Falk Hueffner wrote:
> Hi,
> 
> I'm trying to implement a tree pass that warns about bad array
> accesses as suggested for PR 8268 by Jeff Law. However, I have trouble
> with the following:
> 
> char digit_vector[5];
> const char *ggc_alloc_string(int length) {
>     return digit_vector + ((length - 17) * 2);
> }
> 
> this translates to:
> 
> ggc_alloc_string (length)
> {
>   const char * D.1292;
>   int D.1293;
>   long unsigned int D.1294;
>   char * D.1295;
>   char * D.1296;
> 
>   D.1293 = length * 2;
>   D.1294 = (long unsigned int) D.1293;
>   D.1295 = (char *) D.1294;
>   D.1296 = &digit_vector + -34B;     <-----------
>   D.1292 = D.1295 + D.1296;
>   return D.1292;
> }
> 
> that is, a pointer is formed that wouldn't be legal to form from C,
> and we end up with
> 
>   return (char *) (long unsigned int) (length * 2) + &digit_vector[-000000022];
IIRC creating an invalid pointer is OK -- dereferencing the pointer is 
what's bad.  You need to focus on array accesses, pointer dereferences
and the like, not pointer generation.

Warning for pointer generation is going to be a *lot* harder and I 
suspect will always result in more false positives.


> producing a warning. Is that correct GIMPLE? If so, I fear it simply
> isn't possible to do this kind of warnings after gimplification, and,
> if at all possible, would have to be done in the front-end after all.
Putting these warnings in the front-end is IMHO wrong.  They
belong in the generic parts of the compiler.    



Jeff

Re: Question about pointer arithmetics in GIMPLE

[Daniel Berlin]

> Warning for pointer generation is going to be a *lot* harder and I 
> suspect will always result in more false positives.

In order to increase the accuracy of the data dependence analysis, i do,
at some point, plan on tracking the sizes of malloc sites, and giving an
upper bound on them (for cases of loops, etc) when possible

on an interprocedural basis, that should allow you to generate at least
"this is obviously wrong" warnings.