Return to the
comp.compilers page.
Search the
comp.compilers archives again.
| Related articles |
|---|
| alias analysis vbrahmaiah@yahoo.com (brahmaiah vallabhaneni) (2002-03-31) |
| Re: alias analysis sabre@nondot.org (Chris Lattner) (2002-04-06) |
| Re: alias analysis journeyman@compilerguru.com (2002-04-06) |
| Alias analysis shreyas76@gmail.com (shrey) (2005-11-21) |
| Re: Alias Analysis ghiya@acaps.CS.McGill.CA (1995-11-30) |
| From: | Chris Lattner <sabre@nondot.org> |
| Newsgroups: | comp.compilers |
| Date: | 6 Apr 2002 23:20:32 -0500 |
| Organization: | University of Illinois at Urbana-Champaign |
| References: | 02-03-182 |
| Keywords: | optimize, storage |
| Posted-Date: | 06 Apr 2002 23:20:32 EST |
> [If your program gives different answers with alias analysis, it's
> almost certainly got bugs, wild pointers or the like. -John]
Although the bugs might just be invocations of "undefined behavior" in
otherwise ok code. For example, C defines a set of type based alias
rules that can trip up the unwary doing pointer arithmetic. GCC has
supported the -f[no-]strict-aliasing option since type based alias
analysis was introduced. From the documentation:
"In particular, an object of one type is assumed never to reside at
the same address as an object of a different type, unless the types
are almost the same. For example, an unsigned int can alias an int,
but not a void* or a double. A character type may alias any other
type."
For sufficiently low level code (eg the linux kernel), C TBAA has
broken otherwise good code.
-Chris
Return to the
comp.compilers page.
Search the
comp.compilers archives again.