This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[lto] PATCH: documentation fixes in lto.c


When I was reading this file, I noticed a number of typos in the comments. This fixes 'em. Already checked in as "obvious".

-Sandra


2006-08-22  Sandra Loosemore  <sandra@codesourcery.com>

	* gcc/lto/lto.c:  Documentation fixes.
Index: gcc/lto/lto.c
===================================================================
*** gcc/lto/lto.c	(revision 116299)
--- gcc/lto/lto.c	(working copy)
*************** typedef struct DWARF2_form_data
*** 89,95 ****
    union {
      /* If CL is DW_address, DW_lineptr, DW_loclistptr, DW_macptr, 
         or DW_rangelistptr, there is no additional data.  These forms
!        are not of interest to us for linke-time optimization.  */
      /* Used when CL is DW_cl_constant.  */
      uint64_t constant;
      /* Used when CL is DW_cl_block.  */
--- 89,95 ----
    union {
      /* If CL is DW_address, DW_lineptr, DW_loclistptr, DW_macptr, 
         or DW_rangelistptr, there is no additional data.  These forms
!        are not of interest to us for link-time optimization.  */
      /* Used when CL is DW_cl_constant.  */
      uint64_t constant;
      /* Used when CL is DW_cl_block.  */
*************** typedef struct lto_context
*** 133,139 ****
  } lto_context;
  
  /* We can't use DWARF_Internal_CompUnit because it does not track the
!    offset from the beginning of debug_info, which necessary for
     lookups of DW_FORM_ref_addr data.  */
     
  struct DWARF2_CompUnit
--- 133,139 ----
  } lto_context;
  
  /* We can't use DWARF_Internal_CompUnit because it does not track the
!    offset from the beginning of debug_info, which is necessary for
     lookups of DW_FORM_ref_addr data.  */
     
  struct DWARF2_CompUnit
*************** lto_cache_lookup_DIE (lto_info_fd *fd, c
*** 1039,1058 ****
  	 lto_read_child_DIES (fd, abbrev, context);
        }  
  
!    The set of attributes handle should include (at least) all the
!    attributes actually emitted by GCC.  Uinteresting attributes may
     simply be ignored, but they should be named.  Attributes that you
     know are important, but for which support has not yet been
     implemented, should be handled by calling
     lto_unsupported_attr_error.  As a special case, you do not need to
     handle DW_AT_sibling; this attribute is just a hint, and is ignored
!    everywhere.  LTO_{BEGIN,END}_READ_ATTRS will add a default case
     that issues about errors for unhandled attributes to help to
     enforce these rules.  
     
     These rules may seem in contrast to the normal rules for a DWARF
!    consumer which suggest that consumers should just ignore entries do
!    not understand.  However, in this situation, we can assume that the
     input files came from GCC itself (so we do not need to worry about
     extensions from other tools).  Furthermore, we must be concerned
     that ignoring entries might result in silent wrong-code generation.
--- 1039,1058 ----
  	 lto_read_child_DIES (fd, abbrev, context);
        }  
  
!    The set of attributes handled should include (at least) all the
!    attributes actually emitted by GCC.  Uninteresting attributes may
     simply be ignored, but they should be named.  Attributes that you
     know are important, but for which support has not yet been
     implemented, should be handled by calling
     lto_unsupported_attr_error.  As a special case, you do not need to
     handle DW_AT_sibling; this attribute is just a hint, and is ignored
!    everywhere.  LTO_{BEGIN,END}_READ_ATTRS add a default case
     that issues about errors for unhandled attributes to help to
     enforce these rules.  
     
     These rules may seem in contrast to the normal rules for a DWARF
!    consumer which suggest that consumers should just ignore entries they 
!    do not understand.  However, in this situation, we can assume that the
     input files came from GCC itself (so we do not need to worry about
     extensions from other tools).  Furthermore, we must be concerned
     that ignoring entries might result in silent wrong-code generation.
*************** lto_read_DIE (lto_info_fd *fd, lto_conte
*** 1572,1578 ****
  	  skip = false;
  	}
        else
! 	/* Aassume that all other tags matter, as we are otherwise at
  	   risk of silently generating wrong code.  If a tag can be
  	   safely ignored, it should be explicitly ignored above.  */
  	error ("DWARF tag " HOST_WIDEST_INT_PRINT_UNSIGNED " not "
--- 1572,1578 ----
  	  skip = false;
  	}
        else
! 	/* Assume that all other tags matter, as we are otherwise at
  	   risk of silently generating wrong code.  If a tag can be
  	   safely ignored, it should be explicitly ignored above.  */
  	error ("DWARF tag " HOST_WIDEST_INT_PRINT_UNSIGNED " not "

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]