Rename attribs.c to attributes.c

Rename attribs.c to attributes.c

[Nicola Pero]

[-- Attachment #1: Type: text/plain, Size: 1792 bytes --]

This patch renames attribs.c to attributes.c.

I can only imagine the short "attribs.c" name was picked many years ago
due to filename restrictions on certain systems ?  Nowadays, it seems
that we already have plenty of long filenames inside GCC, so there is
no reason to use cryptic, newbie-unfriendly, shortened names for files. ;-)

Bootstrapped with c,c++,objc,obj-c++,lto,java,fortran,ada,go on Linux i686.

OK to commit ?

Thanks

In gcc/:
2011-06-22  Nicola Pero  <nicola.pero@meta-innovation.com>

        * attribs.c: Renamed to attributes.c.
        * Makefile.in: Changed all occurrences of attribs.c and attribs.o
        to attributes.c and attributes.o.
        * langhooks.h: Updated comments to refer to attributes.c instead
        of attribs.c.
        * plugin.h: Likewise.
        * tree.h: Likewise.

In gcc/ada/:
2011-06-22  Nicola Pero  <nicola.pero@meta-innovation.com>

        * gcc-interface/Make-lang.in (ADA_BACKEND): Renamed attribs.o to
        attributes.o.

In gcc/cp/:
2011-06-22  Nicola Pero  <nicola.pero@meta-innovation.com>

        * Make-lang.in (CXX_C_OBJS): Renamed attribs.o to attributes.o.

In gcc/fortran/:
2011-06-22  Nicola Pero  <nicola.pero@meta-innovation.com>

        * Make-lang.in (f951$(exeext)): Replaced attribs.o with
        attributes.o.

In gcc/go/:
2011-06-22  Nicola Pero  <nicola.pero@meta-innovation.com>

        * Make-lang.in (go1$(exeext)): Rename attribs.o to attributes.o.

In gcc/java/:
2011-06-22  Nicola Pero  <nicola.pero@meta-innovation.com>

        * Make-lang.in (jc1$(exeext)): Renamed attribs.o to attributes.o.

In gcc/lto/:
2011-06-22  Nicola Pero  <nicola.pero@meta-innovation.com>

        * Make-lang.in (LTO_OBJS): Renamed attribs.o to attributes.o

[-- Attachment #2: patch.txt --]
[-- Type: text/plain, Size: 25085 bytes --]

Index: gcc/attribs.c
===================================================================
--- gcc/attribs.c	(revision 175285)
+++ gcc/attribs.c	(working copy)
@@ -1,485 +0,0 @@
-/* Functions dealing with attribute handling, used by most front ends.
-   Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001,
-   2002, 2003, 2004, 2005, 2007, 2008, 2009, 2010
-   Free Software Foundation, Inc.
-
-This file is part of GCC.
-
-GCC is free software; you can redistribute it and/or modify it under
-the terms of the GNU General Public License as published by the Free
-Software Foundation; either version 3, or (at your option) any later
-version.
-
-GCC is distributed in the hope that it will be useful, but WITHOUT ANY
-WARRANTY; without even the implied warranty of MERCHANTABILITY or
-FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
-for more details.
-
-You should have received a copy of the GNU General Public License
-along with GCC; see the file COPYING3.  If not see
-<http://www.gnu.org/licenses/>.  */
-
-#include "config.h"
-#include "system.h"
-#include "coretypes.h"
-#include "tm.h"
-#include "tree.h"
-#include "flags.h"
-#include "diagnostic-core.h"
-#include "ggc.h"
-#include "tm_p.h"
-#include "cpplib.h"
-#include "target.h"
-#include "langhooks.h"
-#include "hashtab.h"
-#include "plugin.h"
-
-static void init_attributes (void);
-
-/* Table of the tables of attributes (common, language, format, machine)
-   searched.  */
-static const struct attribute_spec *attribute_tables[4];
-
-/* Hashtable mapping names (represented as substrings) to attribute specs. */
-static htab_t attribute_hash;
-
-/* Substring representation.  */
-
-struct substring
-{
-  const char *str;
-  int length;
-};
-
-static bool attributes_initialized = false;
-
-/* Default empty table of attributes.  */
-
-static const struct attribute_spec empty_attribute_table[] =
-{
-  { NULL, 0, 0, false, false, false, NULL, false }
-};
-
-/* Return base name of the attribute.  Ie '__attr__' is turned into 'attr'.
-   To avoid need for copying, we simply return length of the string.  */
-
-static void
-extract_attribute_substring (struct substring *str)
-{
-  if (str->length > 4 && str->str[0] == '_' && str->str[1] == '_'
-      && str->str[str->length - 1] == '_' && str->str[str->length - 2] == '_')
-    {
-      str->length -= 4;
-      str->str += 2;
-    }
-}
-
-/* Simple hash function to avoid need to scan whole string.  */
-
-static inline hashval_t
-substring_hash (const char *str, int l)
-{
-  return str[0] + str[l - 1] * 256 + l * 65536;
-}
-
-/* Used for attribute_hash.  */
-
-static hashval_t
-hash_attr (const void *p)
-{
-  const struct attribute_spec *const spec = (const struct attribute_spec *) p;
-  const int l = strlen (spec->name);
-
-  return substring_hash (spec->name, l);
-}
-
-/* Used for attribute_hash.  */
-
-static int
-eq_attr (const void *p, const void *q)
-{
-  const struct attribute_spec *const spec = (const struct attribute_spec *) p;
-  const struct substring *const str = (const struct substring *) q;
-
-  return (!strncmp (spec->name, str->str, str->length) && !spec->name[str->length]);
-}
-
-/* Initialize attribute tables, and make some sanity checks
-   if --enable-checking.  */
-
-static void
-init_attributes (void)
-{
-  size_t i;
-  int k;
-
-  attribute_tables[0] = lang_hooks.common_attribute_table;
-  attribute_tables[1] = lang_hooks.attribute_table;
-  attribute_tables[2] = lang_hooks.format_attribute_table;
-  attribute_tables[3] = targetm.attribute_table;
-
-  /* Translate NULL pointers to pointers to the empty table.  */
-  for (i = 0; i < ARRAY_SIZE (attribute_tables); i++)
-    if (attribute_tables[i] == NULL)
-      attribute_tables[i] = empty_attribute_table;
-
-#ifdef ENABLE_CHECKING
-  /* Make some sanity checks on the attribute tables.  */
-  for (i = 0; i < ARRAY_SIZE (attribute_tables); i++)
-    {
-      int j;
-
-      for (j = 0; attribute_tables[i][j].name != NULL; j++)
-	{
-	  /* The name must not begin and end with __.  */
-	  const char *name = attribute_tables[i][j].name;
-	  int len = strlen (name);
-
-	  gcc_assert (!(name[0] == '_' && name[1] == '_'
-			&& name[len - 1] == '_' && name[len - 2] == '_'));
-
-	  /* The minimum and maximum lengths must be consistent.  */
-	  gcc_assert (attribute_tables[i][j].min_length >= 0);
-
-	  gcc_assert (attribute_tables[i][j].max_length == -1
-		      || (attribute_tables[i][j].max_length
-			  >= attribute_tables[i][j].min_length));
-
-	  /* An attribute cannot require both a DECL and a TYPE.  */
-	  gcc_assert (!attribute_tables[i][j].decl_required
-		      || !attribute_tables[i][j].type_required);
-
-	  /* If an attribute requires a function type, in particular
-	     it requires a type.  */
-	  gcc_assert (!attribute_tables[i][j].function_type_required
-		      || attribute_tables[i][j].type_required);
-	}
-    }
-
-  /* Check that each name occurs just once in each table.  */
-  for (i = 0; i < ARRAY_SIZE (attribute_tables); i++)
-    {
-      int j, k;
-      for (j = 0; attribute_tables[i][j].name != NULL; j++)
-	for (k = j + 1; attribute_tables[i][k].name != NULL; k++)
-	  gcc_assert (strcmp (attribute_tables[i][j].name,
-			      attribute_tables[i][k].name));
-    }
-  /* Check that no name occurs in more than one table.  */
-  for (i = 0; i < ARRAY_SIZE (attribute_tables); i++)
-    {
-      size_t j, k, l;
-
-      for (j = i + 1; j < ARRAY_SIZE (attribute_tables); j++)
-	for (k = 0; attribute_tables[i][k].name != NULL; k++)
-	  for (l = 0; attribute_tables[j][l].name != NULL; l++)
-	    gcc_assert (strcmp (attribute_tables[i][k].name,
-				attribute_tables[j][l].name));
-    }
-#endif
-
-  attribute_hash = htab_create (200, hash_attr, eq_attr, NULL);
-  for (i = 0; i < ARRAY_SIZE (attribute_tables); i++)
-    for (k = 0; attribute_tables[i][k].name != NULL; k++)
-      {
-        register_attribute (&attribute_tables[i][k]);
-      }
-  invoke_plugin_callbacks (PLUGIN_ATTRIBUTES, NULL);
-  attributes_initialized = true;
-}
-
-/* Insert a single ATTR into the attribute table.  */
-
-void
-register_attribute (const struct attribute_spec *attr)
-{
-  struct substring str;
-  void **slot;
-
-  str.str = attr->name;
-  str.length = strlen (str.str);
-
-  /* Attribute names in the table must be in the form 'text' and not
-     in the form '__text__'.  */
-  gcc_assert (str.length > 0 && str.str[0] != '_');
-
-  slot = htab_find_slot_with_hash (attribute_hash, &str,
-				   substring_hash (str.str, str.length),
-				   INSERT);
-  gcc_assert (!*slot);
-  *slot = (void *) CONST_CAST (struct attribute_spec *, attr);
-}
-
-/* Return the spec for the attribute named NAME.  */
-
-const struct attribute_spec *
-lookup_attribute_spec (const_tree name)
-{
-  struct substring attr;
-
-  attr.str = IDENTIFIER_POINTER (name);
-  attr.length = IDENTIFIER_LENGTH (name);
-  extract_attribute_substring (&attr);
-  return (const struct attribute_spec *)
-    htab_find_with_hash (attribute_hash, &attr,
-			 substring_hash (attr.str, attr.length));
-}
-\f
-/* Process the attributes listed in ATTRIBUTES and install them in *NODE,
-   which is either a DECL (including a TYPE_DECL) or a TYPE.  If a DECL,
-   it should be modified in place; if a TYPE, a copy should be created
-   unless ATTR_FLAG_TYPE_IN_PLACE is set in FLAGS.  FLAGS gives further
-   information, in the form of a bitwise OR of flags in enum attribute_flags
-   from tree.h.  Depending on these flags, some attributes may be
-   returned to be applied at a later stage (for example, to apply
-   a decl attribute to the declaration rather than to its type).  */
-
-tree
-decl_attributes (tree *node, tree attributes, int flags)
-{
-  tree a;
-  tree returned_attrs = NULL_TREE;
-
-  if (TREE_TYPE (*node) == error_mark_node)
-    return NULL_TREE;
-
-  if (!attributes_initialized)
-    init_attributes ();
-
-  /* If this is a function and the user used #pragma GCC optimize, add the
-     options to the attribute((optimize(...))) list.  */
-  if (TREE_CODE (*node) == FUNCTION_DECL && current_optimize_pragma)
-    {
-      tree cur_attr = lookup_attribute ("optimize", attributes);
-      tree opts = copy_list (current_optimize_pragma);
-
-      if (! cur_attr)
-	attributes
-	  = tree_cons (get_identifier ("optimize"), opts, attributes);
-      else
-	TREE_VALUE (cur_attr) = chainon (opts, TREE_VALUE (cur_attr));
-    }
-
-  if (TREE_CODE (*node) == FUNCTION_DECL
-      && optimization_current_node != optimization_default_node
-      && !DECL_FUNCTION_SPECIFIC_OPTIMIZATION (*node))
-    DECL_FUNCTION_SPECIFIC_OPTIMIZATION (*node) = optimization_current_node;
-
-  /* If this is a function and the user used #pragma GCC target, add the
-     options to the attribute((target(...))) list.  */
-  if (TREE_CODE (*node) == FUNCTION_DECL
-      && current_target_pragma
-      && targetm.target_option.valid_attribute_p (*node, NULL_TREE,
-						  current_target_pragma, 0))
-    {
-      tree cur_attr = lookup_attribute ("target", attributes);
-      tree opts = copy_list (current_target_pragma);
-
-      if (! cur_attr)
-	attributes = tree_cons (get_identifier ("target"), opts, attributes);
-      else
-	TREE_VALUE (cur_attr) = chainon (opts, TREE_VALUE (cur_attr));
-    }
-
-  /* A "naked" function attribute implies "noinline" and "noclone" for
-     those targets that support it.  */
-  if (TREE_CODE (*node) == FUNCTION_DECL
-      && attributes
-      && lookup_attribute_spec (get_identifier ("naked"))
-      && lookup_attribute ("naked", attributes) != NULL)
-    {
-      if (lookup_attribute ("noinline", attributes) == NULL)
-	attributes = tree_cons (get_identifier ("noinline"), NULL, attributes);
-
-      if (lookup_attribute ("noclone", attributes) == NULL)
-	attributes = tree_cons (get_identifier ("noclone"),  NULL, attributes);
-    }
-
-  targetm.insert_attributes (*node, &attributes);
-
-  for (a = attributes; a; a = TREE_CHAIN (a))
-    {
-      tree name = TREE_PURPOSE (a);
-      tree args = TREE_VALUE (a);
-      tree *anode = node;
-      const struct attribute_spec *spec = lookup_attribute_spec (name);
-      bool no_add_attrs = 0;
-      int fn_ptr_quals = 0;
-      tree fn_ptr_tmp = NULL_TREE;
-
-      if (spec == NULL)
-	{
-	  warning (OPT_Wattributes, "%qE attribute directive ignored",
-		   name);
-	  continue;
-	}
-      else if (list_length (args) < spec->min_length
-	       || (spec->max_length >= 0
-		   && list_length (args) > spec->max_length))
-	{
-	  error ("wrong number of arguments specified for %qE attribute",
-		 name);
-	  continue;
-	}
-      gcc_assert (is_attribute_p (spec->name, name));
-
-      if (spec->decl_required && !DECL_P (*anode))
-	{
-	  if (flags & ((int) ATTR_FLAG_DECL_NEXT
-		       | (int) ATTR_FLAG_FUNCTION_NEXT
-		       | (int) ATTR_FLAG_ARRAY_NEXT))
-	    {
-	      /* Pass on this attribute to be tried again.  */
-	      returned_attrs = tree_cons (name, args, returned_attrs);
-	      continue;
-	    }
-	  else
-	    {
-	      warning (OPT_Wattributes, "%qE attribute does not apply to types",
-		       name);
-	      continue;
-	    }
-	}
-
-      /* If we require a type, but were passed a decl, set up to make a
-	 new type and update the one in the decl.  ATTR_FLAG_TYPE_IN_PLACE
-	 would have applied if we'd been passed a type, but we cannot modify
-	 the decl's type in place here.  */
-      if (spec->type_required && DECL_P (*anode))
-	{
-	  anode = &TREE_TYPE (*anode);
-	  /* Allow ATTR_FLAG_TYPE_IN_PLACE for the type's naming decl.  */
-	  if (!(TREE_CODE (*anode) == TYPE_DECL
-		&& *anode == TYPE_NAME (TYPE_MAIN_VARIANT
-					(TREE_TYPE (*anode)))))
-	    flags &= ~(int) ATTR_FLAG_TYPE_IN_PLACE;
-	}
-
-      if (spec->function_type_required && TREE_CODE (*anode) != FUNCTION_TYPE
-	  && TREE_CODE (*anode) != METHOD_TYPE)
-	{
-	  if (TREE_CODE (*anode) == POINTER_TYPE
-	      && (TREE_CODE (TREE_TYPE (*anode)) == FUNCTION_TYPE
-		  || TREE_CODE (TREE_TYPE (*anode)) == METHOD_TYPE))
-	    {
-	      /* OK, this is a bit convoluted.  We can't just make a copy
-		 of the pointer type and modify its TREE_TYPE, because if
-		 we change the attributes of the target type the pointer
-		 type needs to have a different TYPE_MAIN_VARIANT.  So we
-		 pull out the target type now, frob it as appropriate, and
-		 rebuild the pointer type later.
-
-		 This would all be simpler if attributes were part of the
-		 declarator, grumble grumble.  */
-	      fn_ptr_tmp = TREE_TYPE (*anode);
-	      fn_ptr_quals = TYPE_QUALS (*anode);
-	      anode = &fn_ptr_tmp;
-	      flags &= ~(int) ATTR_FLAG_TYPE_IN_PLACE;
-	    }
-	  else if (flags & (int) ATTR_FLAG_FUNCTION_NEXT)
-	    {
-	      /* Pass on this attribute to be tried again.  */
-	      returned_attrs = tree_cons (name, args, returned_attrs);
-	      continue;
-	    }
-
-	  if (TREE_CODE (*anode) != FUNCTION_TYPE
-	      && TREE_CODE (*anode) != METHOD_TYPE)
-	    {
-	      warning (OPT_Wattributes,
-		       "%qE attribute only applies to function types",
-		       name);
-	      continue;
-	    }
-	}
-
-      if (TYPE_P (*anode)
-	  && (flags & (int) ATTR_FLAG_TYPE_IN_PLACE)
-	  && TYPE_SIZE (*anode) != NULL_TREE)
-	{
-	  warning (OPT_Wattributes, "type attributes ignored after type is already defined");
-	  continue;
-	}
-
-      if (spec->handler != NULL)
-	returned_attrs = chainon ((*spec->handler) (anode, name, args,
-						    flags, &no_add_attrs),
-				  returned_attrs);
-
-      /* Layout the decl in case anything changed.  */
-      if (spec->type_required && DECL_P (*node)
-	  && (TREE_CODE (*node) == VAR_DECL
-	      || TREE_CODE (*node) == PARM_DECL
-	      || TREE_CODE (*node) == RESULT_DECL))
-	relayout_decl (*node);
-
-      if (!no_add_attrs)
-	{
-	  tree old_attrs;
-	  tree a;
-
-	  if (DECL_P (*anode))
-	    old_attrs = DECL_ATTRIBUTES (*anode);
-	  else
-	    old_attrs = TYPE_ATTRIBUTES (*anode);
-
-	  for (a = lookup_attribute (spec->name, old_attrs);
-	       a != NULL_TREE;
-	       a = lookup_attribute (spec->name, TREE_CHAIN (a)))
-	    {
-	      if (simple_cst_equal (TREE_VALUE (a), args) == 1)
-		break;
-	    }
-
-	  if (a == NULL_TREE)
-	    {
-	      /* This attribute isn't already in the list.  */
-	      if (DECL_P (*anode))
-		DECL_ATTRIBUTES (*anode) = tree_cons (name, args, old_attrs);
-	      else if (flags & (int) ATTR_FLAG_TYPE_IN_PLACE)
-		{
-		  TYPE_ATTRIBUTES (*anode) = tree_cons (name, args, old_attrs);
-		  /* If this is the main variant, also push the attributes
-		     out to the other variants.  */
-		  if (*anode == TYPE_MAIN_VARIANT (*anode))
-		    {
-		      tree variant;
-		      for (variant = *anode; variant;
-			   variant = TYPE_NEXT_VARIANT (variant))
-			{
-			  if (TYPE_ATTRIBUTES (variant) == old_attrs)
-			    TYPE_ATTRIBUTES (variant)
-			      = TYPE_ATTRIBUTES (*anode);
-			  else if (!lookup_attribute
-				   (spec->name, TYPE_ATTRIBUTES (variant)))
-			    TYPE_ATTRIBUTES (variant) = tree_cons
-			      (name, args, TYPE_ATTRIBUTES (variant));
-			}
-		    }
-		}
-	      else
-		*anode = build_type_attribute_variant (*anode,
-						       tree_cons (name, args,
-								  old_attrs));
-	    }
-	}
-
-      if (fn_ptr_tmp)
-	{
-	  /* Rebuild the function pointer type and put it in the
-	     appropriate place.  */
-	  fn_ptr_tmp = build_pointer_type (fn_ptr_tmp);
-	  if (fn_ptr_quals)
-	    fn_ptr_tmp = build_qualified_type (fn_ptr_tmp, fn_ptr_quals);
-	  if (DECL_P (*node))
-	    TREE_TYPE (*node) = fn_ptr_tmp;
-	  else
-	    {
-	      gcc_assert (TREE_CODE (*node) == POINTER_TYPE);
-	      *node = fn_ptr_tmp;
-	    }
-	}
-    }
-
-  return returned_attrs;
-}
Index: gcc/java/Make-lang.in
===================================================================
--- gcc/java/Make-lang.in	(revision 175285)
+++ gcc/java/Make-lang.in	(working copy)
@@ -97,10 +97,10 @@ java-warn = $(STRICT_WARN)
 # String length warnings
 jvspec.o-warn = -Wno-error
 
-jc1$(exeext): $(JAVA_OBJS) $(BACKEND) $(LIBDEPS) attribs.o
+jc1$(exeext): $(JAVA_OBJS) $(BACKEND) $(LIBDEPS) attributes.o
 	rm -f $@
 	+$(LINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \
-		$(JAVA_OBJS) $(BACKEND) $(ZLIB) $(LIBICONV) $(LIBS) attribs.o $(BACKENDLIBS)
+		$(JAVA_OBJS) $(BACKEND) $(ZLIB) $(LIBICONV) $(LIBS) attributes.o $(BACKENDLIBS)
 
 jcf-dump$(exeext): $(JCFDUMP_OBJS) $(LIBDEPS)
 	rm -f $@
Index: gcc/java/ChangeLog
===================================================================
--- gcc/java/ChangeLog	(revision 175285)
+++ gcc/java/ChangeLog	(working copy)
@@ -1,3 +1,7 @@
+2011-06-22  Nicola Pero  <nicola.pero@meta-innovation.com>
+
+	* Make-lang.in (jc1$(exeext)): Renamed attribs.o to attributes.o.
+
 2011-06-21  Andrew MacLeod  <amacleod@redhat.com>
 
 	* builtins.c: Add sync_ or SYNC__ to builtin names.
Index: gcc/tree.h
===================================================================
--- gcc/tree.h	(revision 175286)
+++ gcc/tree.h	(working copy)
@@ -5517,7 +5517,7 @@ extern bool alloca_call_p (const_tree);
 extern bool must_pass_in_stack_var_size (enum machine_mode, const_tree);
 extern bool must_pass_in_stack_var_size_or_pad (enum machine_mode, const_tree);
 
-/* In attribs.c.  */
+/* In attributes.c.  */
 
 extern const struct attribute_spec *lookup_attribute_spec (const_tree);
 
Index: gcc/ChangeLog
===================================================================
--- gcc/ChangeLog	(revision 175286)
+++ gcc/ChangeLog	(working copy)
@@ -1,3 +1,13 @@
+2011-06-22  Nicola Pero  <nicola.pero@meta-innovation.com>
+
+	* attribs.c: Renamed to attributes.c.
+	* Makefile.in: Changed all occurrences of attribs.c and attribs.o
+	to attributes.c and attributes.o.
+	* langhooks.h: Updated comments to refer to attributes.c instead
+	of attribs.c.
+	* plugin.h: Likewise.
+	* tree.h: Likewise.
+	
 2011-06-21  Nicola Pero  <nicola.pero@meta-innovation.com>
 
 	* attribs.c (register_attribute): Added assert to check that all
Index: gcc/cp/Make-lang.in
===================================================================
--- gcc/cp/Make-lang.in	(revision 175285)
+++ gcc/cp/Make-lang.in	(working copy)
@@ -72,7 +72,7 @@ g++-cross$(exeext): g++$(exeext)
 
 # The compiler itself.
 # Shared with C front end:
-CXX_C_OBJS = attribs.o incpath.o \
+CXX_C_OBJS = attributes.o incpath.o \
 	$(C_COMMON_OBJS) $(CXX_TARGET_OBJS)
 
 # Language-specific object files for C++ and Objective C++.
Index: gcc/cp/ChangeLog
===================================================================
--- gcc/cp/ChangeLog	(revision 175285)
+++ gcc/cp/ChangeLog	(working copy)
@@ -1,3 +1,7 @@
+2011-06-22  Nicola Pero  <nicola.pero@meta-innovation.com>
+
+	* Make-lang.in (CXX_C_OBJS): Renamed attribs.o to attributes.o.
+
 2011-06-21  Jason Merrill  <jason@redhat.com>
 
 	PR c++/49172
Index: gcc/go/Make-lang.in
===================================================================
--- gcc/go/Make-lang.in	(revision 175285)
+++ gcc/go/Make-lang.in	(working copy)
@@ -64,9 +64,9 @@ GO_OBJS = \
 	go/types.o \
 	go/unsafe.o
 
-go1$(exeext): $(GO_OBJS) attribs.o $(BACKEND) $(LIBDEPS)
+go1$(exeext): $(GO_OBJS) attributes.o $(BACKEND) $(LIBDEPS)
 	$(CXX) $(ALL_CXXFLAGS) $(LDFLAGS) -o $@ \
-	      $(GO_OBJS) attribs.o $(BACKEND) $(LIBS) $(BACKENDLIBS)
+	      $(GO_OBJS) attributes.o $(BACKEND) $(LIBS) $(BACKENDLIBS)
 
 # Documentation.
 
Index: gcc/go/ChangeLog
===================================================================
--- gcc/go/ChangeLog	(revision 175285)
+++ gcc/go/ChangeLog	(working copy)
@@ -1,3 +1,7 @@
+2011-06-22  Nicola Pero  <nicola.pero@meta-innovation.com>
+
+	* Make-lang.in (go1$(exeext)): Rename attribs.o to attributes.o.
+
 2011-06-21  Andrew MacLeod  <amacleod@redhat.com>
 
 	* gogo-tree.cc (Gogo::define_builtin_function_trees): Change
Index: gcc/ada/ChangeLog
===================================================================
--- gcc/ada/ChangeLog	(revision 175285)
+++ gcc/ada/ChangeLog	(working copy)
@@ -1,3 +1,8 @@
+2011-06-22  Nicola Pero  <nicola.pero@meta-innovation.com>
+
+	* gcc-interface/Make-lang.in (ADA_BACKEND): Renamed attribs.o to
+	attributes.o.
+
 2011-06-18  Eric Botcazou  <ebotcazou@adacore.com>
 
 	* gcc-interface/decl.c (gnat_to_gnu_component_type): Use GNAT_TYPE
Index: gcc/ada/gcc-interface/Make-lang.in
===================================================================
--- gcc/ada/gcc-interface/Make-lang.in	(revision 175285)
+++ gcc/ada/gcc-interface/Make-lang.in	(working copy)
@@ -467,7 +467,7 @@ GNATBIND_OBJS = \
  ada/widechar.o
 
 # Language-independent object files.
-ADA_BACKEND = $(BACKEND) attribs.o
+ADA_BACKEND = $(BACKEND) attributes.o
 
 # List of target dependent sources, overridden below as necessary
 TARGET_ADA_SRCS =
Index: gcc/fortran/Make-lang.in
===================================================================
--- gcc/fortran/Make-lang.in	(revision 175285)
+++ gcc/fortran/Make-lang.in	(working copy)
@@ -97,9 +97,9 @@ gfortran-cross$(exeext): gfortran$(exeext)
 
 # The compiler itself is called f951.
 f951$(exeext): $(F95_OBJS) \
-		$(BACKEND) $(LIBDEPS) attribs.o
+		$(BACKEND) $(LIBDEPS) attributes.o
 	+$(LINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \
-		$(F95_OBJS) $(BACKEND) $(LIBS) attribs.o $(BACKENDLIBS)
+		$(F95_OBJS) $(BACKEND) $(LIBS) attributes.o $(BACKENDLIBS)
 
 gt-fortran-trans.h    : s-gtype; @true
 #\f
Index: gcc/fortran/ChangeLog
===================================================================
--- gcc/fortran/ChangeLog	(revision 175285)
+++ gcc/fortran/ChangeLog	(working copy)
@@ -1,3 +1,8 @@
+2011-06-22  Nicola Pero  <nicola.pero@meta-innovation.com>
+
+	* Make-lang.in (f951$(exeext)): Replaced attribs.o with
+	attributes.o.
+
 2011-06-21  Andrew MacLeod  <amacleod@redhat.com>
 
 	* trans-openmp.c: Add sync_ or SYNC__ to builtin names.
Index: gcc/langhooks.h
===================================================================
--- gcc/langhooks.h	(revision 175285)
+++ gcc/langhooks.h	(working copy)
@@ -397,10 +397,11 @@ struct lang_hooks
   HOST_WIDE_INT (*to_target_charset) (HOST_WIDE_INT);
 
   /* Pointers to machine-independent attribute tables, for front ends
-     using attribs.c.  If one is NULL, it is ignored.  Respectively, a
-     table of attributes specific to the language, a table of
-     attributes common to two or more languages (to allow easy
-     sharing), and a table of attributes for checking formats.  */
+     using attributes.c.  If one is NULL, it is ignored.
+     Respectively, a table of attributes specific to the language, a
+     table of attributes common to two or more languages (to allow
+     easy sharing), and a table of attributes for checking
+     formats.  */
   const struct attribute_spec *attribute_table;
   const struct attribute_spec *common_attribute_table;
   const struct attribute_spec *format_attribute_table;
Index: gcc/lto/Make-lang.in
===================================================================
--- gcc/lto/Make-lang.in	(revision 175285)
+++ gcc/lto/Make-lang.in	(working copy)
@@ -23,7 +23,7 @@
 # The name of the LTO compiler.
 LTO_EXE = lto1$(exeext)
 # The LTO-specific object files inclued in $(LTO_EXE).
-LTO_OBJS = lto/lto-lang.o lto/lto.o lto/lto-object.o attribs.o
+LTO_OBJS = lto/lto-lang.o lto/lto.o lto/lto-object.o attributes.o
 LTO_H = lto/lto.h $(HASHTAB_H)
 LINKER_PLUGIN_API_H = $(srcdir)/../include/plugin-api.h
 LTO_TREE_H = lto/lto-tree.h $(LINKER_PLUGIN_API_H)
Index: gcc/lto/ChangeLog
===================================================================
--- gcc/lto/ChangeLog	(revision 175285)
+++ gcc/lto/ChangeLog	(working copy)
@@ -1,3 +1,7 @@
+2011-06-22  Nicola Pero  <nicola.pero@meta-innovation.com>
+
+	* Make-lang.in (LTO_OBJS): Renamed attribs.o to attributes.o
+
 2011-06-11  Jan Hubicka  <jh@suse.cz>
 
 	PR lto/48246
Index: gcc/plugin.h
===================================================================
--- gcc/plugin.h	(revision 175285)
+++ gcc/plugin.h	(working copy)
@@ -61,7 +61,7 @@ invoke_plugin_callbacks (int event ATTRIBUTE_UNUSE
   return PLUGEVT_NO_CALLBACK;
 }
 
-/* In attribs.c.  */
+/* In attributes.c.  */
 
 extern void register_attribute (const struct attribute_spec *attr);
 
Index: gcc/Makefile.in
===================================================================
--- gcc/Makefile.in	(revision 175285)
+++ gcc/Makefile.in	(working copy)
@@ -1191,7 +1191,7 @@ C_COMMON_OBJS = c-family/c-common.o c-family/c-cpp
   c-family/c-semantics.o c-family/c-ada-spec.o
 
 # Language-specific object files for C and Objective C.
-C_AND_OBJC_OBJS = attribs.o c-errors.o c-decl.o c-typeck.o \
+C_AND_OBJC_OBJS = attributes.o c-errors.o c-decl.o c-typeck.o \
   c-convert.o c-aux-info.o c-objc-common.o c-parser.o tree-mudflap.o \
   $(C_COMMON_OBJS) $(C_TARGET_OBJS)
 
@@ -2229,7 +2229,7 @@ default-c.o: config/default-c.c $(CONFIG_H) $(SYST
 
 # Files used by all variants of C and some other languages.
 
-attribs.o : attribs.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(TREE_H) \
+attributes.o : attributes.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(TREE_H) \
 	$(FLAGS_H) toplev.h $(DIAGNOSTIC_CORE_H) output.h $(GGC_H) $(TM_P_H) \
 	$(TARGET_H) langhooks.h $(CPPLIB_H) $(PLUGIN_H)
 

Re: Rename attribs.c to attributes.c

[Richard Guenther]

On Wed, Jun 22, 2011 at 7:18 PM, Nicola Pero
<nicola.pero@meta-innovation.com> wrote:
> This patch renames attribs.c to attributes.c.
>
> I can only imagine the short "attribs.c" name was picked many years ago
> due to filename restrictions on certain systems ?  Nowadays, it seems
> that we already have plenty of long filenames inside GCC, so there is
> no reason to use cryptic, newbie-unfriendly, shortened names for files. ;-)
>
> Bootstrapped with c,c++,objc,obj-c++,lto,java,fortran,ada,go on Linux i686.
>
> OK to commit ?

Huh, I see no reason for this rename.  It'll just make patches across
releases harder.

Richard.

> Thanks
>
> In gcc/:
> 2011-06-22  Nicola Pero  <nicola.pero@meta-innovation.com>
>
>        * attribs.c: Renamed to attributes.c.
>        * Makefile.in: Changed all occurrences of attribs.c and attribs.o
>        to attributes.c and attributes.o.
>        * langhooks.h: Updated comments to refer to attributes.c instead
>        of attribs.c.
>        * plugin.h: Likewise.
>        * tree.h: Likewise.
>
> In gcc/ada/:
> 2011-06-22  Nicola Pero  <nicola.pero@meta-innovation.com>
>
>        * gcc-interface/Make-lang.in (ADA_BACKEND): Renamed attribs.o to
>        attributes.o.
>
> In gcc/cp/:
> 2011-06-22  Nicola Pero  <nicola.pero@meta-innovation.com>
>
>        * Make-lang.in (CXX_C_OBJS): Renamed attribs.o to attributes.o.
>
> In gcc/fortran/:
> 2011-06-22  Nicola Pero  <nicola.pero@meta-innovation.com>
>
>        * Make-lang.in (f951$(exeext)): Replaced attribs.o with
>        attributes.o.
>
> In gcc/go/:
> 2011-06-22  Nicola Pero  <nicola.pero@meta-innovation.com>
>
>        * Make-lang.in (go1$(exeext)): Rename attribs.o to attributes.o.
>
> In gcc/java/:
> 2011-06-22  Nicola Pero  <nicola.pero@meta-innovation.com>
>
>        * Make-lang.in (jc1$(exeext)): Renamed attribs.o to attributes.o.
>
> In gcc/lto/:
> 2011-06-22  Nicola Pero  <nicola.pero@meta-innovation.com>
>
>        * Make-lang.in (LTO_OBJS): Renamed attribs.o to attributes.o
>

Re: Rename attribs.c to attributes.c

[Nicola Pero]

> Huh, I see no reason for this rename.  It'll just make patches across
> releases harder.

Sure.  But any change will make "patches across releases harder" ... does
it mean we can't make any changes - not even in phase 1 ? :-(

The reason I'd like to change the name is that "attribs.c" is meaningless.
I never realized it contained code to deal with attributes until I opened
the file and read the code inside.  I always thought it contained some
sort of mysterious internal GCC data structure or pass.  Isn't that a good
enough reason to rename it ? :-)

Anyhow, if you want to keep the ugly name as it is, let's keep it that way.

My next step was going to be to add an "attributes.h" file, moving into it
the attributes functions (lookup_attribute(), is_attribute_p(), merge_attributes(),
etc) from tree.h (and moving the corresponding implementations into attributes.c).

The idea was to eventually have all the code dealing with attribute lists
in these two files, so that it's easy to change the internal representation.

And, there are few files actually accessing or manipulating attributes; only these
files would include attributes.h, while the other ones - which include tree.h - wouldn't
include or depend on the attribute functions.

Can I go ahead with this or is it a waste of time as the patch will be rejected ?

Presumably the new header file would need to be named "attribs.h", and I can't name it
"attributes.h" ?  Ouch.

Thanks

Re: Rename attribs.c to attributes.c

[Richard Guenther]

On Wed, Jun 22, 2011 at 8:36 PM, Nicola Pero
<nicola.pero@meta-innovation.com> wrote:
>> Huh, I see no reason for this rename.  It'll just make patches across
>> releases harder.
>
> Sure.  But any change will make "patches across releases harder" ... does
> it mean we can't make any changes - not even in phase 1 ? :-(

No, not in general.

> The reason I'd like to change the name is that "attribs.c" is meaningless.
> I never realized it contained code to deal with attributes until I opened
> the file and read the code inside.  I always thought it contained some
> sort of mysterious internal GCC data structure or pass.  Isn't that a good
> enough reason to rename it ? :-)

Hmm, attribs.c to me is a perfect abbreviation to attributes.c, so it isn't
unclear (to me) ... there are more confusing file names, like tree-dfa.c
or tree-flow*.[ch].

> Anyhow, if you want to keep the ugly name as it is, let's keep it that way.
>
> My next step was going to be to add an "attributes.h" file, moving into it
> the attributes functions (lookup_attribute(), is_attribute_p(), merge_attributes(),
> etc) from tree.h (and moving the corresponding implementations into attributes.c).

That sounds fine (then with the name attribs.h).

> The idea was to eventually have all the code dealing with attribute lists
> in these two files, so that it's easy to change the internal representation.
>
> And, there are few files actually accessing or manipulating attributes; only these
> files would include attributes.h, while the other ones - which include tree.h - wouldn't
> include or depend on the attribute functions.
>
> Can I go ahead with this or is it a waste of time as the patch will be rejected ?

No, that sounds good and is welcome.

> Presumably the new header file would need to be named "attribs.h", and I can't name it
> "attributes.h" ?  Ouch.

;)

Another maintainer may feel free to override my initial reaction.

Thanks,
Richard.

> Thanks
>
>

Re: Rename attribs.c to attributes.c

[Andrew MacLeod]

> Hmm, attribs.c to me is a perfect abbreviation to attributes.c, so it isn't
> unclear (to me) ... there are more confusing file names, like tree-dfa.c
> or tree-flow*.[ch].
>
I also can't imagine what else attrib.c would be other than attributes...

Re: Rename attribs.c to attributes.c

[Basile Starynkevitch]

On Wed, 22 Jun 2011 15:09:33 -0400
Andrew MacLeod <amacleod@redhat.com> wrote:

> 
> > Hmm, attribs.c to me is a perfect abbreviation to attributes.c, so it isn't
> > unclear (to me) ... there are more confusing file names, like tree-dfa.c
> > or tree-flow*.[ch].
> >
> I also can't imagine what else attrib.c would be other than attributes...

To me, who is not a native English speaker, it could also suggest
attributions, attributives, or even attraction or attrition or "at
tribe". (& it reminds me of "attrister" which mean "to sadden" in
French). And some people starting to hack in GCC don't even know of
attributes (which are a GCC extension that other C compilers might not
have.). So I do favor using long words in identifiers in file names. I
would like most of GCC major public identifiers & filenames made of
long English words (perhaps with a prefix for their module). Gtk naming
conventions is IMHO easier for newbies than GCC ones. 

I also agree that tree-dfa.c is more confusing than attribs.c, but I
still welcome the patch proposed by Nicola Pero.

Regards.
-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

Re: Rename attribs.c to attributes.c

[Joseph S. Myers]

On Wed, 22 Jun 2011, Andrew MacLeod wrote:

> > Hmm, attribs.c to me is a perfect abbreviation to attributes.c, so it isn't
> > unclear (to me) ... there are more confusing file names, like tree-dfa.c
> > or tree-flow*.[ch].
> > 
> I also can't imagine what else attrib.c would be other than attributes...

The *real* issue of ambiguity is that the term "attribute" means more than 
one thing in GCC - in this case it relates to __attribute__, but there are 
insn attributes as well.

There have been suggestions of putting GCC source files in many more 
subdirectories to reflect the logical modules, and if that were done then 
maybe renaming at the same time, so the file becomes tree/attributes.c or 
generic/attributes.c, would make sense - and the choice of directory would 
make clearer what sort of attributes are being referred to.  But creating 
such subdirectories requires a clear overall understanding of what the 
logical divisions of source files are - a design rather than just moving 
one file on its own.  (I've previously discussed what should go in common/ 
and common/config/, driver/ and driver/config/, and it's well-established 
that files built only for the target and associated build support should 
go in the toplevel libgcc/ directory.)

I don't think achieving a rearrangement of the host-side and build-side 
files in gcc/ would be particular hard - the changes would be mostly 
mechanical - but it does require careful thought about what we want the 
modules and their dependencies to be, and there would be plenty of 
followup changes later to try to reduce the undesired dependencies between 
the modules.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Rename attribs.c to attributes.c

[Joseph S. Myers]

On Wed, 22 Jun 2011, Nicola Pero wrote:

> > Huh, I see no reason for this rename.  It'll just make patches across
> > releases harder.
> 
> Sure.  But any change will make "patches across releases harder" ... does
> it mean we can't make any changes - not even in phase 1 ? :-(

I think moving files only makes sense where it makes the modular structure 
clearer - for example, the past move of C-family code to the c-family/ 
directory, or moving libgcc sources to the toplevel libgcc/ directory, or 
moving common code (see 
<http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01779.html> for my remarks 
on what to consider common) to the common/ directory.

That your patch needed to change so many places does show up a confusion 
about what sort of an object attribs.o is; it looks like it should go in 
the main OBJS list in Makefile.in and not in any of the other lists it's 
presently in.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Rename attribs.c to attributes.c

[Basile Starynkevitch]

On Wed, 22 Jun 2011 20:36:21 +0200 (CEST)
"Nicola Pero" <nicola.pero@meta-innovation.com> wrote:

> > Huh, I see no reason for this rename.  It'll just make patches across
> > releases harder.
> 
> Sure.  But any change will make "patches across releases harder" ... does
> it mean we can't make any changes - not even in phase 1 ? :-(
> 
> The reason I'd like to change the name is that "attribs.c" is meaningless.
> I never realized it contained code to deal with attributes until I opened
> the file and read the code inside.  I always thought it contained some
> sort of mysterious internal GCC data structure or pass.  Isn't that a good
> enough reason to rename it ? :-)


I agree with such renames and clean-ups, but I also sadly think there
are very difficult in the GCC community (because old-timers who could
approve that don't care, and don't like such patches).

In an ideal world, I would like many patches like this. In particular,
I would like some consistent naming conventions (that would contribute
to define what modules are in GCC - so far, we do have "modularity
efforts", but I still believe that we don't have yet modules: we cannot
name them, and we cannot even count them, so in my view they don't
exist yet; some nice old-timers have been upset because I told that GCC
is not modular, but since GCC modules are not counted nor named yet, I
still believe that GCC is not made of well defined modules - and that
is what I mean by "modularity"; for many GCC gurus, it is only a
relative qualification -unrelated to any set of modules-, and GCC is
indeed slowly improving in that aspect.).

An example of patches I dream about but would never dare submitting is
a patch consistently renaming every GCC optimization pass (of struct
opt_pass type, or its subtype). I feel that it would help a lot new
people (and even me) if consistently every pass whose name field is
"FOO" is named FOO_pass (or pass_FOO, I don't care about what
convention we use provided we use it consistently & systematically).
And for the same reasons your patch renaming "attribs.c" to
"attributes.c" is rejected, I believe such a patch (renaming
consistently passes) would also be rejected. It is very sad.

Many GCC gurus don't see the point to make GCC code easier to read to
newcomers (since such a change would temporarily make GCC code harder
to read & to patch for them). This is sad, but won't change. 

As a counter example, I do find GTK (& related libraries) a lot more
modular and more readable than GCC code - both coded in C; naming
conventions, separation of modules as different libraries, usability as
a library, documentation generated from code, younger age.... explain a
lot.

But GCC is too big and too important (and probably working well enough)
to change a lot. So while I do welcome a lot patches like the changing
of attribs.c to attributes.c advocated by Nicola Pero (and I admire his
courage), I sadly believe they won't happen (unless proposed by a very
select & closed circle of people).

Perhaps the long term goal of progressively rewrite GCC in C++ might
help (but I am a bit skeptical here too, I don't see lot of code on
this point.). I don't like C++, but I believe that it could perhaps
push such a rewrite (but I am pessimistic on the short run).

There is an economical explanation for this: no corporation (not even
the richest ones like Google, IBM, ...) is willing to spend money
paying GCC developers to re-factor or rewrite parts of GCC. And such a
massive effort won't happen freely (i.e. without investment). Besides,
some organizations or people knowing very well GCC have no interest in
such changes.  And indeed, few people could promise that such a
rewriting would improve GCC by a significant, predictable, & measurable
amount.  Sadly, GCC is almost nearly good enough for most corporations
investing in it (so they can invest only in "marginal" improvements,
even if "marginal" may mean several person-years to them!).

Cheers.

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

Re: Rename attribs.c to attributes.c

[Diego Novillo]

On Wed, Jun 22, 2011 at 15:03, Basile Starynkevitch
<basile@starynkevitch.net> wrote:
> On Wed, 22 Jun 2011 20:36:21 +0200 (CEST)
> "Nicola Pero" <nicola.pero@meta-innovation.com> wrote:
>
>> > Huh, I see no reason for this rename.  It'll just make patches across
>> > releases harder.
>>
>> Sure.  But any change will make "patches across releases harder" ... does
>> it mean we can't make any changes - not even in phase 1 ? :-(
>>
>> The reason I'd like to change the name is that "attribs.c" is meaningless.
>> I never realized it contained code to deal with attributes until I opened
>> the file and read the code inside.  I always thought it contained some
>> sort of mysterious internal GCC data structure or pass.  Isn't that a good
>> enough reason to rename it ? :-)
>
>
> I agree with such renames and clean-ups, but I also sadly think there
> are very difficult in the GCC community (because old-timers who could
> approve that don't care, and don't like such patches).

You keep overgeneralizing and I think it is misleading.

Existing reviewers will object to certain renames and/or cleanups when
they do not see a compelling value proposition.  If you think that
your change brings value, but the maintainer does not see it, it may
be a sign that you have not described the change properly.  Or it may
be simply a sign that your change is not as valuable as a cleanup as
you think it is.

In the end, some cleanups are a judgment call.  Different reviewers
will have different opinions.

> In an ideal world, I would like many patches like this. In particular,
> I would like some consistent naming conventions (that would contribute
> to define what modules are in GCC - so far, we do have "modularity
> efforts", but I still believe that we don't have yet modules: we cannot
> name them, and we cannot even count them, so in my view they don't
> exist yet; some nice old-timers have been upset because I told that GCC
> is not modular, but since GCC modules are not counted nor named yet, I
> still believe that GCC is not made of well defined modules - and that
> is what I mean by "modularity"; for many GCC gurus, it is only a
> relative qualification -unrelated to any set of modules-, and GCC is
> indeed slowly improving in that aspect.).

Do not expect these changes to show up in a sudden rush of modernity.
It will take time.  Some may never materialize (diminishing returns,
though we are still far from that point).


Diego.

Re: Rename attribs.c to attributes.c

[Basile Starynkevitch]

On Wed, 22 Jun 2011 16:41:36 -0400
Diego Novillo <dnovillo@google.com> wrote:
> 
> You keep overgeneralizing and I think it is misleading.
> 
> Existing reviewers will object to certain renames and/or cleanups when
> they do not see a compelling value proposition.  If you think that
> your change brings value, but the maintainer does not see it, it may
> be a sign that you have not described the change properly. 


I tend to agree, with an important caveat. Cosmetic changes (like
renaming attribs.c to attributes.c) have much more subjective value to
newcomers or GCC newbies than to GCC gurus.

Any person working for several years on GCC (and that includes even me)
don't care that much about attribs.c vs attributes.c, but a newbie will
care a big lot. For us, the change don't bring much, we all have read
the start of attribs.c files. For a newbie, the change will bring
value. This is subjective!

I am more near to "newbie" state that Richie or you Diego are. So I
probably understand more their particular feelings and not being a
native English speaker also helps a big lot :-)

BTW, GCC development favors small patches, and that is a big bias.

Cheers.

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***