Patchwork Cleanup comments in alias.c

login
register
mail settings
Submitter Dodji Seketeli
Date Oct. 15, 2012, 1:19 p.m.
Message ID <87hapvrhyw.fsf@redhat.com>
Download mbox | patch
Permalink /patch/191560/
State New
Headers show

Comments

Dodji Seketeli - Oct. 15, 2012, 1:19 p.m.
Hello,

While reading alias.c, it seemed to me that some comments could use
some cleanups.

OK for trunk?

Thanks.

gcc/

	* alias.c: Cleanup comments.
---
 gcc/alias.c | 27 +++++++++++++--------------
 1 file changed, 13 insertions(+), 14 deletions(-)
Richard Guenther - Oct. 15, 2012, 1:26 p.m.
On Mon, 15 Oct 2012, Dodji Seketeli wrote:

> Hello,
> 
> While reading alias.c, it seemed to me that some comments could use
> some cleanups.
> 
> OK for trunk?

Ok.

Thanks,
Richard.

> Thanks.
> 
> gcc/
> 
> 	* alias.c: Cleanup comments.
> ---
>  gcc/alias.c | 27 +++++++++++++--------------
>  1 file changed, 13 insertions(+), 14 deletions(-)
> 
> diff --git a/gcc/alias.c b/gcc/alias.c
> index 0c6a744..09aef11 100644
> --- a/gcc/alias.c
> +++ b/gcc/alias.c
> @@ -60,14 +60,13 @@ along with GCC; see the file COPYING3.  If not see
>     struct Z z2, *pz;
>  
>  
> -   py = &px1.y1;
> +   py = &x1.y1;
>     px2 = &x1;
>  
>     Consider the four questions:
>  
>     Can a store to x1 interfere with px2->y1?
>     Can a store to x1 interfere with px2->z2?
> -   (*px2).z2
>     Can a store to x1 change the value pointed to by with py?
>     Can a store to x1 change the value pointed to by with pz?
>  
> @@ -78,24 +77,24 @@ along with GCC; see the file COPYING3.  If not see
>     a store through a pointer to an X can overwrite any field that is
>     contained (recursively) in an X (unless we know that px1 != px2).
>  
> -   The last two of the questions can be solved in the same way as the
> -   first two questions but this is too conservative.  The observation
> -   is that in some cases analysis we can know if which (if any) fields
> -   are addressed and if those addresses are used in bad ways.  This
> -   analysis may be language specific.  In C, arbitrary operations may
> -   be applied to pointers.  However, there is some indication that
> -   this may be too conservative for some C++ types.
> +   The last two questions can be solved in the same way as the first
> +   two questions but this is too conservative.  The observation is
> +   that in some cases we can know which (if any) fields are addressed
> +   and if those addresses are used in bad ways.  This analysis may be
> +   language specific.  In C, arbitrary operations may be applied to
> +   pointers.  However, there is some indication that this may be too
> +   conservative for some C++ types.
>  
>     The pass ipa-type-escape does this analysis for the types whose
>     instances do not escape across the compilation boundary.
>  
>     Historically in GCC, these two problems were combined and a single
> -   data structure was used to represent the solution to these
> +   data structure that was used to represent the solution to these
>     problems.  We now have two similar but different data structures,
> -   The data structure to solve the last two question is similar to the
> -   first, but does not contain have the fields in it whose address are
> -   never taken.  For types that do escape the compilation unit, the
> -   data structures will have identical information.
> +   The data structure to solve the last two questions is similar to
> +   the first, but does not contain the fields whose address are never
> +   taken.  For types that do escape the compilation unit, the data
> +   structures will have identical information.
>  */
>  
>  /* The alias sets assigned to MEMs assist the back-end in determining
>

Patch

diff --git a/gcc/alias.c b/gcc/alias.c
index 0c6a744..09aef11 100644
--- a/gcc/alias.c
+++ b/gcc/alias.c
@@ -60,14 +60,13 @@  along with GCC; see the file COPYING3.  If not see
    struct Z z2, *pz;
 
 
-   py = &px1.y1;
+   py = &x1.y1;
    px2 = &x1;
 
    Consider the four questions:
 
    Can a store to x1 interfere with px2->y1?
    Can a store to x1 interfere with px2->z2?
-   (*px2).z2
    Can a store to x1 change the value pointed to by with py?
    Can a store to x1 change the value pointed to by with pz?
 
@@ -78,24 +77,24 @@  along with GCC; see the file COPYING3.  If not see
    a store through a pointer to an X can overwrite any field that is
    contained (recursively) in an X (unless we know that px1 != px2).
 
-   The last two of the questions can be solved in the same way as the
-   first two questions but this is too conservative.  The observation
-   is that in some cases analysis we can know if which (if any) fields
-   are addressed and if those addresses are used in bad ways.  This
-   analysis may be language specific.  In C, arbitrary operations may
-   be applied to pointers.  However, there is some indication that
-   this may be too conservative for some C++ types.
+   The last two questions can be solved in the same way as the first
+   two questions but this is too conservative.  The observation is
+   that in some cases we can know which (if any) fields are addressed
+   and if those addresses are used in bad ways.  This analysis may be
+   language specific.  In C, arbitrary operations may be applied to
+   pointers.  However, there is some indication that this may be too
+   conservative for some C++ types.
 
    The pass ipa-type-escape does this analysis for the types whose
    instances do not escape across the compilation boundary.
 
    Historically in GCC, these two problems were combined and a single
-   data structure was used to represent the solution to these
+   data structure that was used to represent the solution to these
    problems.  We now have two similar but different data structures,
-   The data structure to solve the last two question is similar to the
-   first, but does not contain have the fields in it whose address are
-   never taken.  For types that do escape the compilation unit, the
-   data structures will have identical information.
+   The data structure to solve the last two questions is similar to
+   the first, but does not contain the fields whose address are never
+   taken.  For types that do escape the compilation unit, the data
+   structures will have identical information.
 */
 
 /* The alias sets assigned to MEMs assist the back-end in determining