[cfe-dev] [LLVMdev] For alias analysis, It's gcc too aggressive or LLVM need to improve?
hfinkel at anl.gov
Sat Aug 9 15:07:06 PDT 2014
----- Original Message -----
> From: "Tim Northover" <t.p.northover at gmail.com>
> To: "Jonas Wagner" <jonas.wagner at epfl.ch>
> Cc: "cfe-dev Developers" <cfe-dev at cs.uiuc.edu>, "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
> Sent: Friday, August 8, 2014 6:54:50 AM
> Subject: Re: [cfe-dev] [LLVMdev] For alias analysis, It's gcc too aggressive or LLVM need to improve?
> > your C program invokes undefined behavior when it dereferences
> > pointers that
> > have been converted to other types. See for example
> > http://stackoverflow.com/questions/4810417/c-when-is-casting-between-pointer-types-not-undefined-behavior
> I don't think it's quite that simple.The type-based aliasing rules
> come from 6.5p7 of C11, I think. That says:
> "An object shall have its stored value accessed only by an lvalue
> expression that has one of
> the following types:
> + a type compatible with the effective type of the object,
> + an aggregate or union type that includes one of the
> types among its members [...]"
> That would seem to allow this usage: aa (effective type "int") is
> being accessed via an lvalue "ptr[i]->index" of type "int".
> The second point would even seem to allow something like "ptr[i] =
> ..." if aa was declared "int aa;", though that seems to be going
> too far. It also seems to be very difficult to pin down a meaning
> (from the standard) for "a->b" if a is not a pointer to an object
> the correct effective type. So the entire area is probably one that's
> open to interpretation.
> I've added cfe-dev to the list; they're the *professional* language
Coincidentally, this also seems to be PR20585 (adding Jiangning Liu, the reporter of that bug, to this thread too).
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory
More information about the cfe-dev