[LLVMdev] Strange pointer aliasing behaviour

Jim Grosbach grosbach at apple.com
Thu Jun 17 09:54:12 PDT 2010

On Jun 17, 2010, at 9:42 AM, Pierre C wrote:

>>> Consider a case like the following:
>>> struct X { int a; int b[10]; };
>>> int f(struct X* a) { a->b[-1] = 1; return a->a; }
>>> This is technically illegal code, but various programs depend on
>>> constructs like this working.
> Actually if you want to do bit-casting in C the usual way is to very carefully use an union which informs the compiler that there will be aliasing...

Quite right. Unfortunately, Eli is correct that there is a large codebase out there that uses less friendly idioms. It's getting better over time as people fix the issues (perhaps wishful thinking on my part), but it is still a "gotcha" we need to be aware of and consider when we make more aggressive optimizations.

> Making such ugly things work means lots of optimizations can't be performed.
Exactly. To elaborate on my probably-too-curt initial response, I believe that optimizations should not be constrained by non-comformant code. That said, I also believe we should be as friendly as we can in helping people find and fix these issues. Tracking down a bug like that in user code is an absolute nightmare. Specifically, we should issue good diagnostics for problems of this sort, from the compiler and/or from the static analyzer, whenever possible.

> I wonder if llvm intentionnally generates this spurious alias (to make badly written code work) or is it just the optimizer not being smart enough yet ?...

I'm not 100% sure, but I suspect it's the latter.


More information about the llvm-dev mailing list