llvm dev - Aug 2014 - [LLVMdev] [cfe-dev] 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 aforementioned
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[2];", 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
with
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
lawyers.

Cheers.

Tim.

----- 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
>   aforementioned
> 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[2];", 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
> with
> 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
> lawyers.
Coincidentally, this also seems to be PR20585 (adding Jiangning Liu, the
reporter of that bug, to this thread too).

 -Hal
> 
> Cheers.
> 
> Tim.
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> 
-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

+aliasing people

I *think* this is valid, because the rules have always been described to me
in terms of underlying storage type, and not access path. These are all
ints, so all loads and stores can alias.


On Sat, Aug 9, 2014 at 3:07 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> ----- 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
> >   aforementioned
> > 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[2];", 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
> > with
> > 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
> > lawyers.
>
> Coincidentally, this also seems to be PR20585 (adding Jiangning Liu, the
> reporter of that bug, to this thread too).
>
>  -Hal
>
> >
> > Cheers.
> >
> > Tim.
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> >
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140811/d50aefc0/attachment.html>