On Tue, 17 Jan 2012, Ian Lance Taylor wrote:
When COMP_TYPE_ATTRIBUTES was introduced, it was a macro which could be set in tm.h to check type attributes.Fri May 6 14:05:00 1994 Stephen R. van den Berg (b...@pool.informatik.rwth-aachen.de) * tree.h (TYPE_ATTRIBUTES): New macro. (struct tree_type): attributes, new field. (precision): Move this field up for better alignment. (attribute_list_{equal,contained}): Prototype for new functions. (build_type_attribute_variant): Prototype for new function. * c-parse.in: Rewrite attribute parsing; update the expected conflicts and state numbers. * tree.c (TYPE_HASH): Move definition to top of file. (make_node): Add support for SET_DEFAULT_TYPE_ATTRIBUTES. (build_type_attribute_variant): New function. (type_hash_lookup): Check if the attributes match. (attribute_list_{equal,contained}): New functions. * c-typeck.c (common_type): Add attribute merging. (comp_types): Use COMP_TYPE_ATTRIBUTES macro. * print-tree.c (print_node): Print attributes. * c-common.c (decl_attributes): Move the attribute recognition and rejection here from c-parse.in. (decl_attributes): Use VALID_MACHINE_ATTRIBUTE macro. This was before there was a affects_type_identity field. Given that, and given the assumption that most attributes were backend specific, a default of 1 made sense. The default has carried forward since then. The affects_type_identity field was added in March 2011 as part of the fix for PR 12171, in order to produce a better error message. Kai followed with a change to test affects_type_identity in the new comp_type_attributes function: http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01318.html At that point I think it would have made sense to change the default of TARGET_COMP_TYPE_ATTRIBUTES. Or, it should be renamed, since it is no longer simply serving as a comparison, but is now serving to handle the special case for which it was introduced, x86 calling convention attributes. So, no real answers here, but I agree that this is an area that could use some cleanup.
Thanks a lot for this detailed analysis, which explains much. I definitely should have looked at the history (though it wouldn't have been as clear as your explanation).
I am not sure what the right approach is. The current middle-end code as a speed optimization is strange. Other than that, there really is a problem only if we want to allow attributes that affect the type in other places than targets. If we don't, we can leave things as they are (possibly with a rename/comment). If we do, we would somehow need a way to specify which attributes are handled by the targets, either by adding a new property to attributes, or by making TARGET_COMP_TYPE_ATTRIBUTES return the attributes it doesn't know (or forward them to some generic comparison function).
The example I am considering is the extern "C" property of some function types in C++. It is a calling convention specifier, not specific to any target, although the current ABI says it has no effect. In my prototype patch for bug 2316, I reuse the minval field to store this property, and I then need to adapt quite a few functions to preserve it. Using an attribute seems to make sense and would reuse more existing mechanisms (though it may have drawbacks too).
-- Marc Glisse
