Compile time Array Bounds Analysis in LLVM

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Compile time Array Bounds Analysis in LLVM

Eric Fiselier via cfe-dev
Hi
 I am working on analyzing arrays for dimensions and inferring iteration space.
While going through this i found example

int funct(){
int a[6][6][6];
return a[8][0][0];
}


Compiler did not warn about extended index in first dimension. Considering arrays are decayed
into pointer,  Will issuing this as error be false positive?
By looking at this it looks like easy problem to solve  at AST level. What is challenge in this analysis?

Thanks
Mahesh

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Compile time Array Bounds Analysis in LLVM

Eric Fiselier via cfe-dev
On 12/19/2017 8:51 PM, Mahesh Attarde via cfe-dev wrote:
Hi
 I am working on analyzing arrays for dimensions and inferring iteration space.
While going through this i found example

int funct(){
int a[6][6][6];
return a[8][0][0];
}


Compiler did not warn about extended index in first dimension. Considering arrays are decayed
into pointer,  Will issuing this as error be false positive?

No; a[8] is equivalent to *(a+8), and "a+8" is undefined behavior because it points outside the array.  -fsanitize=undefined will catch this at runtime.

By looking at this it looks like easy problem to solve  at AST level. What is challenge in this analysis?

Probably just an oversight in the checking code.  Briefly looking at it, it looks like there's a missing call to Sema::CheckArrayAccess?

-Eli
-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev